As announced on their Web site (http://www.transmissionbt.com/): "Version 1.40 Released! Posted by Charles Kerr on 09/11/08" I tested it, seems to work fine so I'm attaching my ebuild files (with minor changes to what I attached for version 1.34).
Created attachment 171587 [details] Changelog, config file, init script, and ebuild file. Archive contains the files that change in /usr/local/portage/net-p2p/transmission/: transmission-1.40.ebuild, ChangeLog, files/transmission, files/transmission-confd. Of course the /local/ is only for local ebuilds, when it is released it should go into /usr/portage/...
Thanks for submitting your version update! Assigning to maintainers.
bump to 1.4 is needed because of bug in 1.3x http://trac.transmissionbt.com/ticket/1305 (Transmission losing data)
A couple of notes/corrections to .ebuild file : 1. I wrongly added a dependency to intltool because I saw the build fail (with USE="-gtk"), later I saw that the dependency was already there, correctly under the build dependencies (not run dependency) but was only used when gtk was used... so it looks that the new version now depends on intltool always. 2. As reported on Transmission's forum, there can be a problem when libcurl is build without ssl support, the problem is only seen when using trackers through https. Curl can be build with 3 sets of USE options: "ssl,-nss,-gnutls" or "-ssl,-nss,gnutls" or "-ssl,nss,-gnutls"... I tried adding that restriction but ebuild flags it as a syntax error, I don't know why. Also I used only the first form of the flags since we already have a run time dependency on openssl. So my current (NON WORKING) changes to the ebuild file are: $ diff -Naur transmission-1.40.ebuild transmission-1.40.ebuild.new --- transmission-1.40.ebuild 2008-11-11 20:15:19.328125000 -0600 +++ transmission-1.40.ebuild.new 2008-11-16 14:44:03.921250000 -0600 @@ -14,8 +14,7 @@ IUSE="gtk libnotify" RDEPEND=">=dev-libs/glib-2.16 - >=net-misc/curl-7.15.0 - >=dev-util/intltool-0.23 + >=net-misc/curl-7.15.0[ssl,-nss,-gnutls] >=dev-libs/openssl-0.9.8 gtk? ( >=x11-libs/gtk+-2.6 >=dev-libs/dbus-glib-0.72 ) @@ -23,7 +22,7 @@ DEPEND="${RDEPEND} sys-devel/gettext >=dev-util/pkgconfig-0.19 - gtk? ( >=dev-util/intltool-0.35 )" + >=dev-util/intltool-0.23" src_compile() { Perhaps somebody can see what the problem with the addition of USE flag requirements is, and beat me to post a better .ebuild file.
(In reply to comment #4) > A couple of notes/corrections to .ebuild file : > > 1. I wrongly added a dependency to intltool because I saw the build fail (with > USE="-gtk"), later I saw that the dependency was already there, correctly under > the build dependencies (not run dependency) but was only used when gtk was > used... so it looks that the new version now depends on intltool always. > > 2. As reported on Transmission's forum, there can be a problem when libcurl is > build without ssl support, the problem is only seen when using trackers through > https. Curl can be build with 3 sets of USE options: "ssl,-nss,-gnutls" or > "-ssl,-nss,gnutls" or "-ssl,nss,-gnutls"... I tried adding that restriction but > ebuild flags it as a syntax error, I don't know why. Also I used only the > first form of the flags since we already have a run time dependency on openssl. > > So my current (NON WORKING) changes to the ebuild file are: > > $ diff -Naur transmission-1.40.ebuild transmission-1.40.ebuild.new > --- transmission-1.40.ebuild 2008-11-11 20:15:19.328125000 -0600 > +++ transmission-1.40.ebuild.new 2008-11-16 14:44:03.921250000 -0600 > @@ -14,8 +14,7 @@ > IUSE="gtk libnotify" > > RDEPEND=">=dev-libs/glib-2.16 > - >=net-misc/curl-7.15.0 > - >=dev-util/intltool-0.23 > + >=net-misc/curl-7.15.0[ssl,-nss,-gnutls] > >=dev-libs/openssl-0.9.8 > gtk? ( >=x11-libs/gtk+-2.6 > >=dev-libs/dbus-glib-0.72 ) > @@ -23,7 +22,7 @@ > DEPEND="${RDEPEND} > sys-devel/gettext > >=dev-util/pkgconfig-0.19 > - gtk? ( >=dev-util/intltool-0.35 )" > + >=dev-util/intltool-0.23" > > src_compile() { > > Perhaps somebody can see what the problem with the addition of USE flag > requirements is, and beat me to post a better .ebuild file. > Here's a snippet of code from the dev-db/phpmyadmin-3.0.1.1 ebuild: pkg_setup() { webapp_pkg_setup if ! PHPCHECKNODIE="yes" require_php_with_use crypt ctype pcre session unicode \ || ! PHPCHECKNODIE="yes" require_php_with_any_use mysql mysqli ; then eerror eerror "${PHP_PKG} needs to be re-installed with all of the following" eerror "USE flags enabled:" eerror eerror "ctype pcre session unicode" eerror eerror "as well as any of the following USE flags enabled:" eerror eerror "mysql or mysqli if using dev-lang/php-5" eerror die "Re-install ${PHP_PKG}" fi } So my reasoning is that you can do this: if ! require_curl_with_use ssl Etc, etc. Mind you, I'm no ebuild specialist, I just figured this might help.
(In reply to comment #4) > 2. As reported on Transmission's forum, there can be a problem when libcurl is > build without ssl support, the problem is only seen when using trackers through > https. Curl can be build with 3 sets of USE options: "ssl,-nss,-gnutls" or > "-ssl,-nss,gnutls" or "-ssl,nss,-gnutls"... I tried adding that restriction but > ebuild flags it as a syntax error, I don't know why. Also I used only the > first form of the flags since we already have a run time dependency on openssl. Based on this thread... http://forum.transmissionbt.com/viewtopic.php?f=9&p=31013 ...unpatched 1.40 ought to work with curl built against gnutls, which matches Gentoo's preference, so i'd say adding the following to the ebuild should do the trick (extrapolated from x11-wm/openbox)... pkg_setup() { if ! built_with_use net-misc/curl gnutls; then eerror "Please rebuild net-misc/curl with the gnutls USE flag enabled." die "net-misc/curl needs gnutls USE flag" fi } ...(to be inserted before src_compile() Your non-working attempt looks like it might be okay for ebuilds conforming to a more recent EAPI, and i may try to update it myself, as i'm playing with a fairly major re-write ATM, including extra USE-flags not currently available - BUT i'm no ebuild-expert either...
(In reply to comment #6) Thanks for the tip! I also tought that the syntax I used (copied from a current ebuild but not documented in ebuild's manual) depended on the version of ebuild; I've spent time looking to clarify this, with no result. Your code seems the correct way to proceed, I only changed that either openssl or gnutls is good for us (we don't care which one, just that one of those was used to build curl). So I'm attaching a new version of the .ebuild file. Note that the forum thread, which is the one I mentioned in the beginning, has bad info at one point, then the correct procedure with respect to building curl.
Created attachment 172748 [details] Added check for curl built with ssl/gnutls. Two changes, described before: - Corrected dependency with intltool, its a build dependency and this version of transmission seems to require it always; - Added check to curl built with either openssl or gnutls. Reports noted that transmission will fail if using https with a tracker and libcurl was not built using either ssl/gnutls/nss.
Created attachment 172749 [details] Corrected typo in a comment. files/transmission-confd (which ends up on /etc/conf.d/transmission) had a typo on one of the comments, no other changes.
(In reply to comment #7) > I also thought that the syntax I used (copied from a current ebuild but not > documented in ebuild's manual) depended on the version of ebuild; I've spent > time looking to clarify this, with no result. I'm having similar fun finding guides to the areas i'm looking to amend... > Your code seems the correct way to proceed, I only changed that either openssl > or gnutls is good for us (we don't care which one, just that one of those was > used to build curl). The thread i linked previously intimated that the use of gnutls corrected an error still present with openssl-support in curl, but i may be misunderstanding the relative posts, so your edit looks good to me (the error may also be version-related - see below). Just FYI, openssl as a dependency of transmission itself is nothing to do with url's, it's because bittorrent uses the SHA1 algorithm for hashing/checking, and the sha1.h header-file used by every client i've looked at is part of openssl. On another note, i think RDEPEND ought to be more like this... RDEPEND=">=net-misc/curl-7.16.3 >=dev-libs/openssl-0.9.4 gtk? ( >=x11-libs/gtk+-2.6 >=dev-libs/glib-2.15.5 >=dev-libs/dbus-glib-0.70 libnotify? ( >=x11-libs/libnotify-0.4.4 ) )" Note that glib is only required if building the gtk-client, and the optional libnotify support is nested under gtk also - though i suppose someone with a gnome desktop might want to use the CLI-client and still get popups, i rather doubt it. I haven't figured out yet if this is enough to block the pulling-in of libnotify and it's deps (gtk, glib, dbus-glib), or if an edit is also required in src_compile()... Also note the minimum-versions, most notably curl - these are taken directly from transmission-1.40's configure.ac file, which might also relate to the https problems being encountered here but not in 1.34..? I've been looking at adding USE-flags to enable/disable the CLI-client and the daemon, but the source might be slightly broken - the web-interface gets installed even when the daemon/remote-client isn't, which seems wrong to me, but feel free to correct me if you know better.
(In reply to comment #10) > The thread i linked previously intimated that the use of gnutls corrected an > error still present with openssl-support in curl, but i may be misunderstanding One of the messages in that thread is clearly wrong, the one that says he used --with-openssl --with-gnutls, curl's site documents that clearly, those are mutually exclusive options. > the relative posts, so your edit looks good to me (the error may also be > version-related - see below). > > Just FYI, openssl as a dependency of transmission itself is nothing to do with > url's, it's because bittorrent uses the SHA1 algorithm for hashing/checking, > and the sha1.h header-file used by every client i've looked at is part of > openssl. That doesn't change a thing with respect to curl. Anyway libssl is linked to the daemon, so we have it already, my point was that gnutls is not necessary, but we really shouldn't care one way or the other, just that libcurl works for any possible use. Besides, isn't libcrypt the one with the sha1 function? > On another note, i think RDEPEND ought to be more like this... > > RDEPEND=">=net-misc/curl-7.16.3 > >=dev-libs/openssl-0.9.4 > gtk? ( >=x11-libs/gtk+-2.6 > >=dev-libs/glib-2.15.5 > >=dev-libs/dbus-glib-0.70 > libnotify? ( >=x11-libs/libnotify-0.4.4 ) )" > > Note that glib is only required if building the gtk-client, and the optional I don't agree. As I answered in the 1.34 thread (on this bugzilla), glibc brings libresolv so it is needed always (run time of course). > libnotify support is nested under gtk also - though i suppose someone with a > gnome desktop might want to use the CLI-client and still get popups, i rather > doubt it. I haven't figured out yet if this is enough to block the pulling-in > of libnotify and it's deps (gtk, glib, dbus-glib), or if an edit is also > required in src_compile()... You are right, I didn't check the original setting of IUSE (which has gtk and libnotify). I also didn't check how those dependencies interact... but I now see that "libnotify 0.0.4 (optional, and only needed by the GTK+ gui)", so a new, improved ebuild follows (after I test it) with only the gtk use flag. > Also note the minimum-versions, most notably curl - these are taken directly > from transmission-1.40's configure.ac file, which might also relate to the > https problems being encountered here but not in 1.34..? Again, you may be right. The version numbers I used are from the build page, http://www.transmissionbt.com/development.php, which might be out of date. > I've been looking at adding USE-flags to enable/disable the CLI-client and the > daemon, but the source might be slightly broken - the web-interface gets > installed even when the daemon/remote-client isn't, which seems wrong to me, > but feel free to correct me if you know better. I don't understand what you say, the Web client is built inside the daemon (since version 1.3x -- Clutch doesn't exist anymore), you can't have one without the other. If you want to disable building of transmission-cli, it should be easy but I see no point in that. If you want the GUI and nothing more... I don't know, just making configure run with --disable-daemon --disable-cli should do it. But I haven't tested and perhaps weird things happen, as you say, and some of the files (Web client files) get installed. In the later case, that would be a bug, then this conversation should be continued on their forum, or their bug tracking site.
Created attachment 172783 [details] Fixed dependencies. Several fixes as per previous thread comments: - Deleted libnotify from USE flags. Its use is implicit when gtk is requested. - Fixed minimum version of glibc and curl. - Put libnotify dependency inside gtk's list. Did simple testing, build with and without USE="-gtk", all OK.
(In reply to comment #11) > > Note that glib is only required if building the gtk-client, and the optional > > I don't agree. > > As I answered in the 1.34 thread (on this bugzilla), glibc brings libresolv so > it is needed always (run time of course). This is dev-libs/glib, you're confusing it with sys-libs/glibc, another animal entirely. I can confirm that building from the command-line with './configure --disable-gtk --enable-libnotify' does _NOT_ require the libnotify deps and ignores the useless option, so the current src_compile() function should be sufficiently idiot-proof with just the nested RDEPEND from my previous post. Will update once i've confirmed this thru portage... (In reply to comment #12) > Created an attachment (id=172783) [edit] > Fixed dependencies. > > Several fixes as per previous thread comments: > > - Deleted libnotify from USE flags. Its use is implicit when gtk is requested. > - Fixed minimum version of glibc and curl. > - Put libnotify dependency inside gtk's list. > > Did simple testing, build with and without USE="-gtk", all OK. (The reply to comment #11 collided with comment #12, so i'll combine both replies) I think libnotify should stay as a USE-option, but be nested as per my previous post - as currently written, it's functionality is _REQUIRED_ by the gtk-client when it should be _OPTIONAL_.
Created attachment 172796 [details] Fixed dependencies. Returned USE flag for libnotify. Corrected version for dev-libs/glib, put it inside gtk's list of dependencies.
(In reply to comment #14) > Created an attachment (id=172796) [edit] > Fixed dependencies. > > Returned USE flag for libnotify. > > Corrected version for dev-libs/glib, put it inside gtk's list of dependencies. > I've tested my own edit (same logic as your latest revision, but with irrelevant textual differences) against every USE-flag combination on a system WITHOUT libnotify previously installed, and they all build as expected (though i'm yet to actually use them...). The only thing i haven't done is rebuild curl WITHOUT ssl/tls support to check the pkg_setup() function - sorry. Thanks for your industry - the only tiny revision that might be needed to get it into portage would be to revert all ARCHES to 'keyword-masked' (~x86 ~amd64) in line with the rest of the current tree...
(In reply to comment #15) > I've tested my own edit (same logic as your latest revision, but with > irrelevant textual differences) against every USE-flag combination on a system > WITHOUT libnotify previously installed, and they all build as expected (though > i'm yet to actually use them...). The only thing i haven't done is rebuild curl > WITHOUT ssl/tls support to check the pkg_setup() function - sorry. Thank you for all the help. > Thanks for your industry - the only tiny revision that might be needed to get > it into portage would be to revert all ARCHES to 'keyword-masked' (~x86 ~amd64) > in line with the rest of the current tree... I changed those after testing it, a long time ago (starting with version 1.34), I have tested 'make check' and in operation in both kind of architectures. I don't know if that's enough to unmask the build, I wish the Gentoo maintainer would comment about it. Anyway, for now, since people has to put these under their own /usr/local/portage builds, I think it doesn't really matter, is just a convenience (to avoid using ACCEPT_KEYWORD which could cause versions of other packages, the dependencies, to install... and those could be really untested or worse).
(In reply to comment #16) > > Thanks for your industry - the only tiny revision that might be needed to get > > it into portage would be to revert all ARCHES to 'keyword-masked' (~x86 ~amd64) > > in line with the rest of the current tree... > > I changed those after testing it, a long time ago (starting with version 1.34), > I have tested 'make check' and in operation in both kind of architectures. > > I don't know if that's enough to unmask the build, I wish the Gentoo maintainer > would comment about it. Anyway, for now, since people has to put these under > their own /usr/local/portage builds, I think it doesn't really matter, is just > a convenience (to avoid using ACCEPT_KEYWORD which could cause versions of > other packages, the dependencies, to install... and those could be really > untested or worse). > Add "net-p2p/transmission ~x86" (or ~amd64 depending on your ARCH) to /etc/portage/package.keywords (create if necessary) and unwanted dependency updates will be avoided - see 'man 5 portage' for full explanation and extra sexy features.
(In reply to comment #17) > Add "net-p2p/transmission ~x86" (or ~amd64 depending on your ARCH) to > /etc/portage/package.keywords (create if necessary) and unwanted dependency > updates will be avoided - see 'man 5 portage' for full explanation and extra > sexy features. Yes, I know, but that also unmasks previous (and future) versions of transmission which I did not test... only on the specific computer of course. But that's one reason why I do it the other way, and that's also why I added to the Changelog that I had actually tested it myself. I don't know how much actual data is needed to unmask a distributed package.
(In reply to comment #18) > (In reply to comment #17) > > Add "net-p2p/transmission ~x86" (or ~amd64 depending on your ARCH) to > > /etc/portage/package.keywords (create if necessary) and unwanted dependency > > updates will be avoided - see 'man 5 portage' for full explanation and extra > > sexy features. > > Yes, I know, but that also unmasks previous (and future) versions of > transmission which I did not test... only on the specific computer of course. > But that's one reason why I do it the other way, and that's also why I added to > the Changelog that I had actually tested it myself. Ah, i see - i think that if you put a tilde in front of it and a version on the end (~net-p2p/transmission-1.40 ~x86), it only unmasks that version and any revisions to the same (1.40, 1.40-r1, etc). While it's in an overlay it won't be accidentally upgraded by anything except an official revision of the same version (if that makes sense) and i can't imagine how it could get downgraded either - check that manpage to be sure. > I don't know how much actual data is needed to unmask a distributed package. > Me neither. The assignee hasn't been very vocal, and isn't on the CC-list for email-updates, so whether he gets notified as a 'To' recipient or hasn't heard anything about this bug-report, i'm at a loss to know - maybe he's on holiday? From what little i've seen in the past, once a bug-report gets a handful of successful-build confirmations it seems to go into the tree (keyword-masked, initially) - but this isn't an especially popular package yet, so it might take a while to filter out into the testing community...
*** This bug has been marked as a duplicate of bug 238260 ***
Duplicate? They are different versions, 1.34 and 1.40.
Then make a note of that on the relevant bug... We could end up with dozens of bugs describing one simple bump. *** This bug has been marked as a duplicate of bug 238260 ***
