The ebuild media-sound/ardour-3.4 has been converted to fetch from a git source. I am behind a company firewall and can not connect to any git:// URLs. Replacing git:// with http:// in the ebuild's EGIT_URI and setting http_proxy and https_proxy environment variables solved the problem for me. However, if new versions of this package continue to use git:// URIs I'll be forced to tweak each and every new ebuild. For me, it would be better if the ebuild used http:// or https:// instead of git:// in first place.
Why does it use git at all? That's so costly at both ends of the fetch.
ebuild ardour-3.4.ebuild clean prepare Appending /newaches/gentoo/cvs/gentoo-x86 to PORTDIR_OVERLAY... * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] >>> Unpacking source... Cloning into bare repository '/world/distfiles/egit-src/ardour.git'... fatal: unable to connect to git.ardour.org: git.ardour.org[0: 54.235.123.47]: errno=Connection timed out * ERROR: media-sound/ardour-3.4::gentoo failed (unpack phase): * git-2_initial_clone: can't fetch from git://git.ardour.org/ardour/ardour.git * * Call stack: * ebuild.sh, line 93: Called src_unpack * environment, line 3510: Called git-2_src_unpack * environment, line 2293: Called git-2_fetch * environment, line 2060: Called git-2_initial_clone * environment, line 2153: Called die * The specific snippet of code: * [[ -n ${EGIT_REPO_URI_SELECTED} ]] || die "${FUNCNAME}: can't fetch from ${EGIT_REPO_URI}" * * If you need support, post the output of `emerge --info '=media-sound/ardour-3.4::gentoo'`, * the complete build log and the output of `emerge -pqv '=media-sound/ardour-3.4::gentoo'`. * The complete build log is located at '/keeps/gentoo/emergelogs/wim/media-sound:ardour-3.4:20130913-143451.log'. * For convenience, a symlink to the build log is located at '/home/jer/portage/media-sound/ardour-3.4/temp/build.log'. * The ebuild environment file is located at '/home/jer/portage/media-sound/ardour-3.4/temp/environment'. * Working directory: '/home/jer/portage/media-sound/ardour-3.4/work' * S: '/home/jer/portage/media-sound/ardour-3.4/work/ardour-3.4'
There is some kind of a paywall on the normal ardour source tarballs, even if it is GPL. I respect the developer and thought about a fetch restriction initially. And honestly even if I donated something for each ebuild that I bumped, I've had a bad conscience uploading the tarball to the mirrors! The git tree is open but has no support officially upstream (that we haven't had anyway). So I decided to switch and allow 9999 versions in the same time. It's new to me that it also works through an http URL and I will switch it as soon as I'll get the chance to test it properly, just to make you happy! :-) https or http? What do you guys prefer? Maybe I should also add an elog message to get people to donate upstream...!?
(In reply to Andreas Schürch from comment #3) > Maybe I should also add an elog message to get people to donate upstream...!? Don't use git for release ebuilds, that's not good for several reasons in addition to the problems already seen. Upstream can do things like shift their tags, move their git repo, convert to different vcs, etc. Please revert to using mirrored tarballs.
=media-sound/ardour-3.5.14= is still using git (with http:// URL at least)...
(In reply to Volkmar Glauche from comment #5) > =media-sound/ardour-3.5.14= is still using git (with http:// URL at least)... ...and the fetch fails, consequently: * ERROR: media-sound/ardour-3.5.14::gentoo failed (unpack phase): * git-2_initial_clone: can't fetch from http://git.ardour.org/ardour/ardour.git While trying the abovementioned URL in a browser it asks for a username and a password...
(In reply to Jouni Rinne from comment #6) > (In reply to Volkmar Glauche from comment #5) > > =media-sound/ardour-3.5.14= is still using git (with http:// URL at least)... > > ...and the fetch fails, consequently: > > * ERROR: media-sound/ardour-3.5.14::gentoo failed (unpack phase): > * git-2_initial_clone: can't fetch from > http://git.ardour.org/ardour/ardour.git > > While trying the abovementioned URL in a browser it asks for a username and > a password... Could not reproduce here. Cloning into bare repository '/usr/portage/distfiles/egit-src/ardour.git'... remote: Counting objects: 128103, done. remote: Compressing objects: 100% (24188/24188), done. remote: Total 128103 (delta 107185), reused 124365 (delta 103582) Receiving objects: 100% (128103/128103), 71.05 MiB | 5.43 MiB/s, done. Resolving deltas: 100% (107185/107185), done. GIT NEW clone --> repository: http://git.ardour.org/ardour/ardour.git at the commit: 3fca0306032486736dd575907c640a1702e8531f commit: 3.5.14 branch: master storage directory: "/usr/portage/distfiles/egit-src/ardour.git" checkout type: bare repository Cloning into '/var/tmp/portage/media-sound/ardour-3.5.14/work/ardour-3.5.14'... done. Switched to a new branch 'tree-3.5.14' I do not plan to switch back to mirrored tarballs as I wouldn't find it ethically correct to let the users fetch a tarball that was payed (or donated) for just once! Another option would be to fetch the zip that gets generated automatically on the github clone... But that would even be two steps more in the chain that could potentially break! And I honestly don't think that upstream is going to switch their vcs or shift tags or something any time soon, as they also have a github clone... And that would probably be an adjustment of a few lines compared to the manual act of down and uploading the tarball for each version bump (where they really switched the naming convention and I had to reflect that at least once in the past already).
git (live) ebuilds can be in tree only with empty KEYWORDS="" or package.masked, so there seems to be a violation in the tree currently
Should be added to this block in profiles/package.mask, starting with: # Diego E. Pettenò <flameeyes@gentoo.org> (08 Aug 2009) # on behalf of QA Team # # Mass-masking of live ebuilds; we cannot guarantee working state of # live ebuilds, nor the availability of the server hosting them. As # per QA team policy, all these need to be kept masked by default, if # available in the tree. [ .. ]
older versions of ardour ebuilds did it correctly, by downloading the tarball and uploading it to Gentoo mirrors
(In reply to Samuli Suominen from comment #10) > older versions of ardour ebuilds did it correctly, by downloading the > tarball and uploading it to Gentoo mirrors Yeah, but since there is a paywall upstream, this is certainly not doable (or the right way to go) anymore with the vanilla tarballs! I will switch the ebuild to the autogenerated zips on github now, as it seems the only (tolerated) way! I know it's not nice also, but still better than a fetch restriction or a mask IMHO...
(In reply to Andreas Schürch from comment #11) > (In reply to Samuli Suominen from comment #10) > > older versions of ardour ebuilds did it correctly, by downloading the > > tarball and uploading it to Gentoo mirrors > > Yeah, but since there is a paywall upstream, this is certainly not doable > (or the right way to go) anymore with the vanilla tarballs! so what? the paywall is *meaningless*, the package's license is GPL-2 without any restrictions just grab the tarball and put it to dev.gentoo.org /space/distfiles/ ... like done before > I will switch the ebuild to the autogenerated zips on github now, as it > seems the only (tolerated) way! I know it's not nice also, but still better > than a fetch restriction or a mask IMHO...
(In reply to Samuli Suominen from comment #12) > (In reply to Andreas Schürch from comment #11) > > (In reply to Samuli Suominen from comment #10) > > > older versions of ardour ebuilds did it correctly, by downloading the > > > tarball and uploading it to Gentoo mirrors > > > > Yeah, but since there is a paywall upstream, this is certainly not doable > > (or the right way to go) anymore with the vanilla tarballs! > > so what? the paywall is *meaningless*, the package's license is GPL-2 > without any restrictions > just grab the tarball and put it to dev.gentoo.org /space/distfiles/ ... > like done before > (In reply to Samuli Suominen from comment #12) > (In reply to Andreas Schürch from comment #11) > > (In reply to Samuli Suominen from comment #10) > > > older versions of ardour ebuilds did it correctly, by downloading the > > > tarball and uploading it to Gentoo mirrors > > > > Yeah, but since there is a paywall upstream, this is certainly not doable > > (or the right way to go) anymore with the vanilla tarballs! > > so what? the paywall is *meaningless*, the package's license is GPL-2 > without any restrictions > just grab the tarball and put it to dev.gentoo.org /space/distfiles/ ... > like done before > The word "Wall" means - You'll not get a download link without donating! And I consider the opt-out through email (each time) isn't suitable for the use within a distribution! > > I will switch the ebuild to the autogenerated zips on github now, as it > > seems the only (tolerated) way! I know it's not nice also, but still better > > than a fetch restriction or a mask IMHO... I'm fighting now with the revision number that is used by waf and isn't in the github-zip... :-/
(In reply to Andreas Schürch from comment #13) > The word "Wall" means - You'll not get a download link without donating! > And I consider the opt-out through email (each time) isn't suitable for the > use within a distribution! you do it once for a version, get the tarball in your HDD, open sftp/scp to dev.gentoo.org, upload the file, wait half an hour (or use your devspace on dev.gentoo.org) and commit the bumped ebuild it's perfectly suitable for a distribution, the maintainer does the job for the user so there is no inconvinience (In reply to Andreas Schürch from comment #13) > I'm fighting now with the revision number that is used by waf and isn't in > the github-zip... :-/ a problem you wouldn't have when using proper release tarballs...
(In reply to Samuli Suominen from comment #14) > (In reply to Andreas Schürch from comment #13) > > The word "Wall" means - You'll not get a download link without donating! > > And I consider the opt-out through email (each time) isn't suitable for the > > use within a distribution! > > you do it once for a version, get the tarball in your HDD, open sftp/scp to > dev.gentoo.org, upload the file, wait half an hour (or use your devspace on > dev.gentoo.org) and commit the bumped ebuild > it's perfectly suitable for a distribution, the maintainer does the job for > the user so there is no inconvinience > I've done that already in the past a few times and had no problem with donating, as I used ardour myself... But I haven't used it myself lately and I'm not willing to donate for each bump "in the name of our users". And honestly I would not like to beg via email either! > (In reply to Andreas Schürch from comment #13) > > I'm fighting now with the revision number that is used by waf and isn't in > > the github-zip... :-/ > > a problem you wouldn't have when using proper release tarballs... Sure, but Christmas is over and the gpl doesn't mean it is free as beer necessarily. So if we would play the rules that upstream would like us to play, vcs would be the way to go! -Ok, there are no redistribution-comments as far as I've seen in the tarball itself, but reading the download pages one should really have a bad conscience!
(In reply to Andreas Schürch from comment #15) > I've done that already in the past a few times and had no problem with > donating, as I used ardour myself... But I haven't used it myself lately and > I'm not willing to donate for each bump "in the name of our users". > And honestly I would not like to beg via email either! Oh my. You are maintaining this package, so you are representing Gentoo as a distro when communicating with upstream. Certainly there's no need to "beg". You could try to work out some scheme with upstream for future version bumps. That could either mean obtaining a URL for download, or a tarball that can be put on our mirrors (if it's GPL then redistribution is no problem). If that doesn't work, you could still make your own snapshot tarball from a git checkout and put it on mirrors.
(In reply to Ulrich Müller from comment #16) > Oh my. You are maintaining this package, so you are representing Gentoo as a > distro when communicating with upstream. Certainly there's no need to "beg". > > You could try to work out some scheme with upstream for future version > bumps. That could either mean obtaining a URL for download, or a tarball > that can be put on our mirrors (if it's GPL then redistribution is no > problem). > I already asked upstream what they would like us to do a few weeks back via mail, but never got an answer. I'll try to reach someone again! (but I already know that at least the lib-unbundling isn't what they like :) > If that doesn't work, you could still make your own snapshot tarball from a > git checkout and put it on mirrors. Yeah, sure, but I tried to avoid manual stuff altogether, so that a version bump could be done (or tested at least) easily by anyone who is probably faster than me :-) And if all that is needed to get the github-zip working is a version string, I'll try that in the meantime.
(In reply to Andreas Schürch from comment #17) > And if all that is needed to get the github-zip working is a version string, > I'll try that in the meantime. Ok, this is commited now.
(In reply to Andreas Schürch from comment #18) > (In reply to Andreas Schürch from comment #17) > > And if all that is needed to get the github-zip working is a version string, > > I'll try that in the meantime. > Ok, this is commited now. There is no tarball available? Otherwise you forgot app-arch/unzip from DEPEND
(In reply to Samuli Suominen from comment #19) > There is no tarball available? Otherwise you forgot app-arch/unzip from > DEPEND Uh, thanks for the catch! That is also done now.
(In reply to Samuli Suominen from comment #19) > (In reply to Andreas Schürch from comment #18) > > (In reply to Andreas Schürch from comment #17) > > > And if all that is needed to get the github-zip working is a version string, > > > I'll try that in the meantime. > > Ok, this is commited now. > > There is no tarball available? Otherwise you forgot app-arch/unzip from > DEPEND There is (github works the same everywhere) and you really should be using the tarball version instead.
ok, with the 3.5.143 bump i moved to the github tarball now. Hope everyone is happy now.
