I can't open the page http://eix.berlios.de anymore. Is the new homepage https://github.com/vaeth/eix ?
Yes, BerliOS has closed its doors and apparently will not open them again. Not only the homepage but also the tarball is no longer available. Development takes now only place on github.com, so this is the location of the homepage, the bugpage and the only public repository. I hope that the tarball can be hosted on some gentoo dev space (since I would like to avoid putting ./configure and friends under git control). Perhaps, this can wait until eix release? (Which, however, is perhaps not so soon, unless we want to force it: Currently, there are only a few cosmetical changes since the last release, so no "real" reason for a new release yet)
Just FYI, github allows to attach tarballs to release tags, too.
(In reply to Christoph Junghans from comment #2) > Just FYI, github allows to attach tarballs to release tags, too. Unfortunately, github does not allow to "attach" any tarball: It automatically generates tarballs from tagged releases. However, this means that all the autotools/gettext files (like ./configure etc) need to be stored in the repository. The contrib/release.sh script of eix is already prepared to store these in a separate branch and to tag this branch. Nevertheless, this will make cloning the git repository very inconvenient, since the repository will then contain effectively all previous tarballs. Thus, I would like to avoid to pollute the repository with release tarball data. Another possibility might be to open a separate eix-tarball repository on eix (that is, a separate repository instead of a separate branch). This will make releasing a bigger task, since I have to clone this huge tarball repository after a while, and actually there is no reason for keeping ancient tarballs. Maybe, for both alternatives there are some possibilities with shallow clones, but I am not familiar enough with git to understand these: AFAIK, pushing with a shallow clone is not supported by git, so some git magic would be needed. Hosting on gentoo dev space would not need many resources. There is no reason to keep ancient tarballs; only a few releases would need to be kept, taking altogether less than 5 megabytes. Summarizing, there are three variants: github separate branch, github separate repository, or gentoo dev space. Just let me know which version you think I should should choose. I am really unsure about the "correct" solution.
I'm sure myself and/or the other proxy maintainers can host tarballs as they are released. At this point, all tarballs for ebuilds in the tree are on gentoo mirrors and will remain so until those ebuilds are removed, so there's nothing strictly that needs to be done for current ebuilds. Next release, if you can get the tarball to us, we will host it on our dev space (or worst case, push it directly to the mirrors)
(In reply to Martin Väth from comment #3) > (In reply to Christoph Junghans from comment #2) > > Just FYI, github allows to attach tarballs to release tags, too. > > Unfortunately, github does not allow to "attach" any tarball: > It automatically generates tarballs from tagged releases. I meant this feature they added a while ago: <https://github.com/blog/1547-release-your-software> This allows to attach addition tarballs to tags. > > However, this means that all the autotools/gettext files (like ./configure > etc) need to be stored in the repository. The contrib/release.sh script of > eix is already prepared to store these in a separate branch and to tag this > branch. Couldn't we run autoreconf in ebuild, too? (In reply to Ian Stakenvicius from comment #4) > I'm sure myself and/or the other proxy maintainers can host tarballs as they > are released. At this point, all tarballs for ebuilds in the tree are on > gentoo mirrors and will remain so until those ebuilds are removed, so > there's nothing strictly that needs to be done for current ebuilds. Next > release, if you can get the tarball to us, we will host it on our dev space > (or worst case, push it directly to the mirrors) That is even better!
In reply to Christoph Junghans from comment #5) > I meant this feature they added a while ago: I had guessed that you meant a new feature, and so I had tried with a freshly created test-repository before I had replied: When choosing "Draft a New Release", I was able to add a text and to upload the file, but it turned out that this file has to be an image format (possibly hidden in a ZIP-file), but a tarball was refused. In other words, unless I misunderstood something, this feature is only meant to ornament the download page with some text and pictures, but not to upload the tarball itself. I was not very surprised about this, since the ideas of a "release tarball" and of a "git repository" are somewhat orthogonal to each other. If you think that I just misunderstood something with github (which might be possible, of course), please write me correct usage through pm or on this bug. > Couldn't we run autoreconf in ebuild, too? One could, and for most packages I would say that this is the best idea. However, I try hard that eix works on any reasonable architecture, and it would be a pity if some architecture would now be excluded only due to autotools requirements (automake requires perl, and gettext has even more severe requirements). >>(In reply to Ian Stakenvicius from comment #4) >> I'm sure myself and/or the other proxy maintainers can host tarballs >That is even better! Actually, Ian and I had agreed tentatively on this quite a while ago through pm when BerliOS announced to close, so I am happy that everybody still agrees.
eix-0.30.3 is the first tarball hosted on gentoo dev space and with the new HOMEPAGE. I guess this bug can be closed when all earlier versions are removed from the tree.
@axs: tarballs for eix-{0.25.5,0.29.3} are still on the mirrors, so you could copy them to ~axs/distfiles, too?
(In reply to Christoph Junghans from comment #8) > @axs: tarballs for eix-{0.25.5,0.29.3} are still on the mirrors, so you > could copy them to ~axs/distfiles, too? No need, if they're on the mirrors. And they'll remain on the mirrors until the ebuilds are dropped from the tree (at which point they won't be needed anymore)
Looks like there is nothing more for us to do here.
