http://dvdisaster.net/downloads/dvdisaster-0.72.5.tar.bz2 0.72 pl5 Fixes a problem which may result in CD/DVD/BD drives being not detected if more than 10 devices are connected to a GNU/Linux or FreeBSD system. Thanks to Bill Eisele for reporting this. (11-Oct-2013) Reproducible: Always
Version already up to 0.79.5: http://dvdisaster.net/downloads/dvdisaster-0.79.5.tar.bz2
Are you willing to proxy maintain this? https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
(In reply to Pacho Ramos from comment #2) > Are you willing to proxy maintain this? > https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers Sure, why not :-)
I will CC the team then, thanks for volunteering
Hello, Can you please provide and test working ebuild for this version bump as a new proxy maintainer? If you have any questions you can contact us on irc #gentoo-proxy-maint or by email proxy-maint@gentoo.org. Thank you for you contribution. Amy
Created attachment 426022 [details] dvdisaster-0.79.5.ebuild New ebuild. Website and download location change ancd a few small other changes and license changed to GPL-3
Hi, a few quick points: - You should update the copyright year to 2016 - When we bump a package, we usually need to mark the new version as unstable. So you should have KEYWORDS="~amd64 ~ppc ~x86" instead. You can find more information about this on our devmanual: https://devmanual.gentoo.org/keywording/index.html#keywording-on-upgrades - It may be better to go over the dependencies once more. I see the following in the configure file: if ! EXECUTE_PROGRAM "gdk-pixbuf-csource --help" gdk_pixbuf_csource ; then echo "* gdk-pixbuf not installed" echo "* or path to gdk-pixbuf-csource is missing." exit 1 fi But I don't see a corresponding dependency on x11-libs/gdk-pixbuf. I also see: ./tools/pngio.h:24:#include <png.h> Good luck
Created attachment 426094 [details] dvdisaster-0.79.5.ebuild second try @ Göktürk Yüksek: Checked the updated the dependencies again, however I am wondering if the gdk-pixbuf explicit dependency is required as gdk-pixbuf is already in the COMMON_DEPEND of gtk+:2 which we also depend on. zlib is also another depency that is already required by freetype which in turn is required by cairo which is required by gtk+:2 How is this handled in general? Are dependencies like bzip2 required in general? (I don't think those are runtime dependencies, I think they were only for unpacking the source..) I didn't get your last point (./tools/pngio.h:24:#include <png.h> ) , there is no tools folder anymore in 0.79.5. Did you check the right version?
(In reply to Daniel Kenzelmann from comment #8) > Created attachment 426094 [details] > dvdisaster-0.79.5.ebuild second try > however I am wondering if the gdk-pixbuf explicit dependency is required as > gdk-pixbuf is already in the COMMON_DEPEND of gtk+:2 which we also depend on. > zlib is also another depency that is already required by freetype which in > turn is required by cairo which is required by gtk+:2 > How is this handled in general? > if ! EXECUTE_PROGRAM "gdk-pixbuf-csource --help" gdk_pixbuf_csource etc. is saying the need for x11-libs/gdk-pixbuf is conditional, so it's a case of whether it need NOT be system installed to suit. I have not gleaned the configure file myself. If those are pulled in by the deps they are pulled in. done. > Are dependencies like bzip2 required in general? (I don't think those are > runtime dependencies, I think they were only for unpacking the source..) > Basically check to see if they belong to @system, so ofcourse if within @system it is not required as a dep. Unpacking ofc means it's required only in DEPEND. > I didn't get your last point (./tools/pngio.h:24:#include <png.h> nor did I. > ) , there is no tools folder anymore in 0.79.5. Did you check the right > version?
(In reply to Ian Delaney from comment #9) > (In reply to Daniel Kenzelmann from comment #8) > > Created attachment 426094 [details] > > dvdisaster-0.79.5.ebuild second try > > > however I am wondering if the gdk-pixbuf explicit dependency is required as > > gdk-pixbuf is already in the COMMON_DEPEND of gtk+:2 which we also depend on. > > zlib is also another depency that is already required by freetype which in > > turn is required by cairo which is required by gtk+:2 > > How is this handled in general? > > > Normally, if your package explicitly states the dependency (in configure etc.) you want to list it in your ebuild. Depending on other packages to indirectly pull in your dependencies is a bad idea because they may drop the dependency in later versions without you ever noticing it. There are exceptions of course. > if ! EXECUTE_PROGRAM "gdk-pixbuf-csource --help" gdk_pixbuf_csource > etc. > > is saying the need for x11-libs/gdk-pixbuf is conditional, so it's a case of > Based on my limited understanding of the shell language, I think calling 'exit 1' in a script terminates it completely. So, if I am reading this correctly, this configure script will terminate if it can't run gdk-pixbuf-csource. I suppose one can argue that gdk-pixbuf is a special case and gtk+ will always pull it forever until the end of time, in which case not specifying this dep in the ebuild would be ok. > whether it need NOT be system installed to suit. I have not gleaned the > configure file myself. If those are pulled in by the deps they are pulled > in. done. > > > Are dependencies like bzip2 required in general? (I don't think those are > > runtime dependencies, I think they were only for unpacking the source..) > > > I believe the older versions did use it in the runtime. I don't see it in this version of the sources. @system dependencies are listed in 'profiles/base/packages' in the gentoo tree. No need to specify them. > Basically check to see if they belong to @system, so ofcourse if within > @system it is not required as a dep. Unpacking ofc means it's required only > in DEPEND. > > > I didn't get your last point (./tools/pngio.h:24:#include <png.h> > > nor did I. > > > ) , there is no tools folder anymore in 0.79.5. Did you check the right > > version? Sorry about that. Never trust the bug title saying "dvdisaster-0.72.6 version bump" :)
Created attachment 426264 [details] dvdisaster-0.79.5.ebuild third try Ok, third time's the charm, now this should be a working ebuild :-) So, the changes from the 0.72.4 version: - Changed description - Changed license - Keywords unstable - changed glib and gtk+ required versions as per configure - Conditional gettext and libintl dependency ("nls" use flag) - remove bzip2 dependency (already in @system) - (not added gdk-pixbuf dep because we depend on gtk+:2, and I don't think the dependency will change within the :2 slot of gtk+) - cleaned up src_install (no tools folder anymore) - added libpng:1.5 as allowed slot as per CHANGELOG (did not remove it because its dependency from gtk+ is not as direct as with gdk-pixbuf)
Nice work, getting there. Description is it is, 111 chars long. The actual text in between " " need be <= 80 chars. This needs reducing substantially. Given there are no prefix keywords, "${ED}"/usr/ need be "${D}"usr/ which I thought I had mentioned previously. Note also the trailing slash in not required with "${D}" . Then can you also edit the metadata.xml and include as a separate attachment to add yourself as the proxy (or proxied) maintainer. See the sample in https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers for a template. Consider this optional. If you don't we will do it for you. The final point however is to ask to submit, intead of a whole ebuild, a unified diff style patch. We will use this to generate the whole ebuild, converting dvdisaster-0.72.4.ebuild -> dvdisaster-0.79.5.ebuild. Good work so far.
(In reply to Daniel Kenzelmann from comment #11) > Created attachment 426264 [details] > dvdisaster-0.79.5.ebuild third try > > Ok, third time's the charm, now this should be a working ebuild :-) > That's what I tell myself every time. Never managed to make it happen though :) > So, the changes from the 0.72.4 version: > - Changed description > - Changed license It's actually GPL-3+, not GPL-3. The '+' implies that later versions of GPL can also be used. From dvdisaster.c: * dvdisaster is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. > - Keywords unstable > - changed glib and gtk+ required versions as per configure > - Conditional gettext and libintl dependency ("nls" use flag) I believe gettext is a build time dependency, but not runtime. As such, it should be moved from RDEPEND to DEPEND. > - remove bzip2 dependency (already in @system) > - (not added gdk-pixbuf dep because we depend on gtk+:2, and I don't think > the dependency will change within the :2 slot of gtk+) > - cleaned up src_install (no tools folder anymore) > - added libpng:1.5 as allowed slot as per CHANGELOG (did not remove it > because its dependency from gtk+ is not as direct as with gdk-pixbuf) I'm not quite sure about the libpng dependency. I'm looking at the output of 'scanelf -n' on the dvdisaster binary: TYPE NEEDED FILE ET_EXEC libgtk-x11-2.0.so.0,libgdk-x11-2.0.so.0,libgdk_pixbuf-2.0.so.0,libpango-1.0.so.0,libgobject-2.0.so.0,libglib-2.0.so.0,libm.so.6,libpthread.so.0,libc.so.6 dvdisaster From the output, I can only see the dependencies for gtk+ and glib. It is not linking against libpng. Also there are no include statements for png.h in the source code. The changelog item that you mention, I believe, is almost 3 years old. I grepped the sources for 'png' and didn't get much out of it. The same goes for zlib as well. I'm having a bit of time-management mess these days but I'll try to take a thorough look at it tomorrow. Assuming a dev beats me to it and merges this, that is :)
Created attachment 426464 [details, diff] ebuild diff dvdisaster-0.72.4 -> dvdisaster-0.79.5 Patch attached. - made description fit within 80 characters - changed LICENSE to GPL-3+ - Removed png and zlib dependency - moved gettext and libintl to DEPEND - changed "${ED}"/ to "${D}" Regarding the metadata.xml I don't know what to specify for <remote-id> in <upstream> as the project seems to not be hosted on sourceforge anymore (the version there is from 2010) What should be specified instead if there is no repository, just the tarball download? Do we remove the <upstream> part?
(In reply to Daniel Kenzelmann from comment #14) > Created attachment 426464 [details, diff] [details, diff] > ebuild diff dvdisaster-0.72.4 -> dvdisaster-0.79.5 > > Patch attached. > - made description fit within 80 characters > - changed LICENSE to GPL-3+ > - Removed png and zlib dependency > - moved gettext and libintl to DEPEND Sorry for constantly making you do small edits. gettext is a build time dependency, but intl is runtime. Here is an example: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-cdr/cdrtools/cdrtools-3.02_alpha06.ebuild The idea is that you use gettext tools during build time to prepare the strings for i18n, and libintl takes care of the runtime. If you ever get curious, gettext page has a diagram for all this: https://www.gnu.org/software/gettext/manual/gettext.html#Overview > - changed "${ED}"/ to "${D}" > > > Regarding the metadata.xml I don't know what to specify for <remote-id> in > <upstream> as the project seems to not be hosted on sourceforge anymore (the > version there is from 2010) > What should be specified instead if there is no repository, just the tarball > download? Do we remove the <upstream> part? Upstream part is optional I believe, especially given that there is no remote-id. One can use a <maintainer> tag inside <upstream>, but that would only allow you to specify name and email, not URL. What's more important is to put the package maintainer information in there. There is an example in the proxy maintainers wiki page: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers#How_proxy_maintainership_works Since your debug flag enables a certain functionality (enables memdebug), which from what I can tell performs a memory leak check before exiting, you should document that in your metadata with a <use> tag. Here's an example with a <use> tag: https://gitweb.gentoo.org/repo/gentoo.git/tree/app-admin/lastpass-cli/metadata.xml
(In reply to Ian Delaney from comment #12) > Nice work, getting there. > Description is it is, 111 chars long. The actual text in between " " need be > <= 80 chars. This needs reducing substantially. > > Given there are no prefix keywords, > "${ED}"/usr/ need be "${D}"usr/ > which I thought I had mentioned previously. Note also the trailing slash in > not required with "${D}" According to the PMS: (https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12200011.1.3) "Note that the behaviour of offset-prefix aware and agnostic is the same when EPREFIX is set to the empty string in offset-prefix aware EAPIs." I think going from ${ED} to ${D} is a bit backwards thinking. For non-prefix arches, ${ED} should effectively evaluate to ${D}. But since the ebuild is already modified for ${D}, I guess there's no need to revert it. ${ED} will have to be put back if this package gains prefix support though.
(In reply to Daniel Kenzelmann from comment #11) > - (not added gdk-pixbuf dep because we depend on gtk+:2, and I don't think > the dependency will change within the :2 slot of gtk+) Hi Daniel, excellent work so far. Looks like you are in good hands here. Just wanted to add in a short comment. (In reply to Göktürk Yüksek from comment #10) > Normally, if your package explicitly states the dependency (in configure > etc.) you want to list it in your ebuild. Depending on other packages to > indirectly pull in your dependencies is a bad idea because they may drop the > dependency in later versions without you ever noticing it. There are > exceptions of course. > > I suppose one can argue that gdk-pixbuf is a special case and gtk+ will > always pull it forever until the end of time, in which case not specifying > this dep in the ebuild would be ok. I have to agree with this statement, gdk-pixbuf should be included as a standalone dependency. I am the maintainer of MATE Desktop Environment and this is standard practice for us. You'll see GNOME and other gtk+ ebuilds follow it too.
well yes indeed to all ^^ gokturk && Daniel, re I think going from ${ED} to ${D} is a bit backwards thinking I was drilled for months to substitute ${ED} to ${D} years ago on becoming dev. With all due respect gokturk, for the sake of decisiveness, leave it at ${D} with NO trailing slash. I was told substitute ${ED} to ${D} was forward movement back then and EAPIs have not been edited to reverse this. ${ED} will have to be put back if this package gains prefix support though. So let it be. As it stands, ${D} suffices and is both apt and works. if this package gains prefix support is in practice of remote likelihood, and if it ever does occur, so be it. We do not set ${D} to ${ED} based on the anticipation of future possibilities. Stay with the here and now. The ebuild has no prefix arches, period.
Created attachment 426686 [details, diff] dvdisaster-0.79.5.patch - added gdk-pixbuf as direct dependency - moved libintl to RDEPEND
Created attachment 426688 [details, diff] metadata.xml.patch removed upstream repo reference added myself as proxy maintainer added debug use flag description
Thank you very much for your patience and contributions. I have committed your changes to the tree with a minor modification where you had an extra white space after the 'nls' USE flag in the dependency specification. I officially welcome you to the proxy-maintainers project. Good Job! commit dffc139569249ab2a87b53c74179184912113c00 Author: Amy Winston <amynka@gentoo.org> Date: Fri Feb 26 21:44:58 2016 +0100 app-cdr/dvdisaster: add proxy-maintainer Package-Manager: portage-2.2.26 commit bbf7ae487ae87da584b70295909aec0367bde9d9 Author: Amy Winston <amynka@gentoo.org> Date: Fri Feb 26 21:40:27 2016 +0100 app-cdr/dvdisaster: version bump 0.79.5 bug #493916 Package-Manager: portage-2.2.26
