getdelta.sh does not support the "url -> file" feature of portage. For example, if getdelta.sh is in your FETCHCOMMAND you can never download x11-misc/googleearth-4.3.7284.3916 because getdelta.sh does not know about the filename it should create. I attach a patch which fixes getdelta.sh to take an optional filename as a second argument.
Created attachment 167093 [details, diff] Patch to make getdelta.sh work with EAPI=2 The attached patch allows getdelta.sh to be used with FETCHCOMMAND="/usr/bin/getdelta.sh \"\${URI}\" \"\${FILE}\"" (if you use this patch in the ebuild note that also the einfo message of the ebuild should have to be changed correspondingly; the old method would still work but of course still break with EAPI=2. Note that the above FETCHCOMMAND is also quoted more carefully than the original suggestion - in fact, in the patch I also fixed some missing quotes in the script). The user must also add FETCHNAME="$FETCH -O" (after the definition of FETCH) to /etc/deltup/getdelta.rc, or he must let getdelta.sh recreate that file.
Created attachment 167251 [details, diff] Previous patch with small typo fixed Sorry, a later test showed me that I quoted too much in the first patch. Corrected patch is appended.
another little fix to 0.7.8: Str. 697 - QUERY_URL=$(GENTOO_MIRRORS="" emerge -fOp =${CATEGORY}/${PF} 2>&1 | sed -e "s/ /\\n/g" | egrep "(http|ftp)://" | grep "${NEW_FILE}" | tail -n 1) +QUERY_URL=$(export GENTOO_MIRRORS="" emerge -fOp =${CATEGORY}/${PF} 2>&1 | sed -e "s/ /\\n/g" | egrep "(http|ftp)://" | grep "${NEW_FILE}" | tail -n 1) getdelta.sh freeze without _export GENTOO_MIRRORS_
(In reply to comment #3) > export GENTOO_MIRRORS="" emerge -fOp =${CATEGORY}/${PF} 2>&1 This is not the proper fix - this is just a syntax error. The reason why emerge hangs is because it is called recursively and thus waits that the mother process removes the lock. This is something which must be fixed in portage. And in fact, zac has already written a patch for portage: bug 245231
*** Bug 285902 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > The user must also add > FETCHNAME="$FETCH -O" > (after the definition of FETCH) to /etc/deltup/getdelta.rc, this way works > or he must > let getdelta.sh recreate that file. this way doesn't , letting getdelta.sh recreate getdelta.rc set the variable FETCHNAME="-O" and with this setting I get : /usr/bin/getdelta.sh: line 835: -O: command not found
Created attachment 205456 [details] getdelta-0.7.9.ebuild ebuild for getdelta 0.7.9 (0.7.8 plus Martin's patch) I had to set SRC_URI="http://linux01.gwdg.de/~nlissne/${PN}-0.7.8.tar.bz2" because the source for 0.7.9 doesn't exist. Should this version be named 0.7.8-r1 or 0.7.9?
Created attachment 205457 [details] getdelta-eapi2.patch a little fix to Martin's patch : as said into comment 6 the getdelta.rc automatically creation has an error , the problem is the line (introduced by patch) : add_to_configfile FETCHNAME "$FETCH -O" "command to use for downloading; first parameter is the filename, second the url" it should be : add_to_configfile FETCHNAME "\$FETCH -O" "command to use for downloading; first parameter is the filename, second the url" otherwise during creation of getdelta.rc bash thinks he has to put the FETCH variable but it should put EXACTLY $FETCH. @Martin : could you please mark your last patch as obsolete ?
why not in portage or new version yet ? this works flawlessly and there are more EAPI=2-ebuilds coming. maybe there are some problems ? it would be a real bummer for our Internet pipes without deltas.
(In reply to comment #7) > Created an attachment (id=205456) [details] > getdelta-0.7.9.ebuild > > ebuild for getdelta 0.7.9 (0.7.8 plus Martin's patch) > I had to set SRC_URI="http://linux01.gwdg.de/~nlissne/${PN}-0.7.8.tar.bz2" > because the source for 0.7.9 doesn't exist. > Should this version be named 0.7.8-r1 or 0.7.9? > It should be the former, as a version 0.7.9 doesn't exist. Plus, all we're doing is patching 0.7.8
Created attachment 232297 [details] Slightly improved ebuild Changed the example included to actually use the ${FILE} parameter since this whole update was to make it actually support it. :)
Created attachment 233785 [details] Small fix to my previous ebuild
Created attachment 244655 [details, diff] Newest getdelta-eapi2.patch Fixed getdelta-eapi2.patch Realy work!
Created attachment 244765 [details, diff] Fix previous patch Some changes to the previous patch: I do not understand why you reverted the change NEW_FILE=$2 This is the crucial point of the patch so that an optional second argument $FILE is honored (if the local name should differ from the URL name supplied by upstream). Also, Marcello's fix to the patch is not included. Finally, instead of $FETCH "${DELTUP_SERVER}${query}" -O ${best_candidate}-${NEW_FILE}.dtu one should use $FETCHNAME command (and the last argument deserves quoting).
Created attachment 244785 [details, diff] Tested and working getdelta-eapi2.patch New version with bugs killed (I hope).
Created attachment 244945 [details, diff] getdelta-eapi2.patch
Created attachment 244965 [details, diff] getdelta-eapi2.patch The latest version of the patch. Sorry for flooding.
emerge-ing gnome-extra/nautilus-dropbox with getdelta.sh failed. The getdelta-eapi2.patch fixed the download and allowed the emerge to continue.
Been using the latest patch successively for several months. Any reason it's not incorporated in the current ebuild?
It's working fine for me, as well. Is there anything we can do to nudge it along?
With deltup failing to build now it's hard to test *sigh*
+ 19 Mar 2012; Patrick Lauer <patrick@gentoo.org> +files/getdelta-0.7.9.patch, + +getdelta-0.7.9.ebuild: + Bump and fix for #239439 I hope that does the trick :)
