http://prefix.gentooexperimental.org/ returns host not found Reproducible: Always
Yeah. The machine this vserver runs on seems to have fallen over. I've informed the hoster, waiting for a reply. Let's hope a reboot fixes things ...
thanks Patrick
is there just one prefix site i can use if the site is down?
atm basically yes :(
Any news from the hoster ?
What services are people looking for the most? I'll admit I don't really have a DR copy of the existing data on prefix.ge.o, but I do have a machine that I can host stuff on for the time being. I copied the last state of the rsync tree there already, just need to setup stuff for that to actually serve it. Now wondering what people need the most for prioritising...
I need to be able to emerge --sync and then start emerging packages again.
rsync8.prefix.bitzolder.nl should be ready, although not updated yet.
Patrick - how come the priority got put back to normal ??? The machine is down, how can that be normal ???
How about hosting the prefix stuff on Gentoo infrastructure? It is a mature Gentoo project so it should be here!
Sounds good to me, Fabian ?
I've heard infra say this a couple of times, it never got off the ground though.
Sort of update: I hope prefix.ge.o comes up within reasonable time so I can at least copy the latest versions of the script and mercurial repos off of it. I've been very stupid by not maintaining an up-to-date copy of it somewhere. This also stops me from bringing up an alternative rsync server quickly. It would save me great efforts if I could access the files, so I'm putting my hopes on that the machines somehow comes to live again. If that happens, I will make sure I have DR, and perhaps even run live-live to make the impact of these kind of things less.
Wow, anyone thought of changing hosting company if it takes this long to reboot a box ?
we got this one for free ...
Patrick, any updates from the hoster? Fabian, oh the mercurial tree and rsyncd are on the same host.
(In reply to Benda Xu from comment #16) > Patrick, any updates from the hoster? > > Fabian, oh the mercurial tree and rsyncd are on the same host. Yes, that's why I'm so hoping that we can at least rescue the data somehow.
@prefix team. Unfortunately, the latest commit in my local mercury is in January 2014. Let's have a bid: who has the most recent local clone of the whole tree?
I'm pretty sure I'm pretty much up-to-date, and due to the nature of DVCS, it's no problem what clone we put live, as people simply have to re-push to the "new" clone and perhaps do a merge here and there. This holds for the main repo, but we had more hosted there, and for them I'm not sure.
(In reply to Fabian Groffen from comment #6) > What services are people looking for the most? I know this is being worked on as fast as possible given the circumstances, but the highest priority for me is the ability to rsync.
Josephs-MacBook-Pro:gentoo joe$ cat ./usr/portage/metadata/timestamp Sun Oct 5 16:11:10 UTC 2014 Josephs-MacBook-Pro:gentoo joe$ cat ./usr/portage/metadata/timestamp.x 1412525470 Sun Oct 5 16:11:10 2014 UTC Josephs-MacBook-Pro:gentoo joe$ cat ./usr/portage/metadata/timestamp.chk Sun, 05 Oct 2014 16:11:10 +0000 Josephs-MacBook-Pro:gentoo joe$
I'm working on a temporary replacement server, which should be up tomorrow at the latest. > I've heard infra say this a couple of times, it never got off the ground > though. I'll take up the job of getting all of prefix's stuff infra-hosted.
I already have a server, with repos, but that's not the biggest problem here :(
On #gentoo-prefix, ilovezfs_ shared that working prefix tree: https://bitbucket.org/lmnd/prefix-tree-cropped/src wget https://bitbucket.org/lmnd/prefix-tree-cropped/get/dca1772c15b1.zip unzip -p dca1772c15b1.zip | sha512sum c470baba6f61f80f3808d3c4fd6fed02d5397929a143f009e41b7f99d12c6219b8e2ae39ceba634ba0de74e94848117ef31ae377172e2cfd52c163ffcfceec86 -
Not sure what you're trying to do there. If you just want to update your portage tree, try pointing it at rsync8.prefix.bitzolder.nl.
I need to bootstrap a new gentoo-prefix from scratch (don't need bootstrap-bash.sh, just bootstrap-prefix.sh, or a manual bootstrapping procedure into EPREFIX from an alternative server).
(In reply to Fabian Groffen from comment #25) I tried to set SYNC="rsync://rsync8.prefix.bitzolder.nl" in my make.conf, but rsync failed with the message: @ERROR: Unknown module 'metadata'
For lack of a better place, I've put a tarball of my prefix portage tree in my Google Drive. You can get it at: https://drive.google.com/file/d/0B1i7rl7h16wPVkJWSHp0M3E2N28/view?usp=sharing
Sorry, forgot to mention, that tree is from Sep 30, 2014. I created the tarball from a prefix on OS X.
BTW, here are the m5sum and sha1sum for that file, if you care about that. $ md5sum prefix-portage-093014.tar.bz2 e56e21d6e21bd73330b5051bb12ce70f prefix-portage-093014.tar.bz2 $ sha1sum prefix-portage-093014.tar.bz2 3808fcc11dad22d23c016bae7034c87b0495cba4 prefix-portage-093014.tar.bz2
We should really get our packages merged into gx86 (see bug #315803) to avoid this kind of problems in the future. Last I looked, there were only about 115 packages left.
(In reply to Guilherme Amadio from comment #27) > (In reply to Fabian Groffen from comment #25) > > I tried to set SYNC="rsync://rsync8.prefix.bitzolder.nl" in my make.conf, > but rsync failed with the message: > > @ERROR: Unknown module 'metadata' To use that rsync server set the following: SYNC="rsync://rsync8.prefix.bitzolder.nl/gentoo-portage-prefix"
Comment #25 from Fabian Groffen: > Not sure what you're trying to do there. Only try to share links that I have seen on #gentoo-prefix I do that again now. I am hosting a copy of https://drive.google.com/file/d/0B1i7rl7h16wPVkJWSHp0M3E2N28/view?usp=sharing at http://sf.net/projects/gentooandroid/files/bug524618/prefix-portage-093014.tar.bz2/download (with "permission" of its owner via #gentoo-prefix) Just in case it helps someone else.
See also http://rsync8.prefix.bitzolder.nl/hg/prefix-tree
Bootstrapping on an old Centos 6.3 box (x86_64), partially by hand, works up to a point. I installed the snapshot tarball hosted by Guilherme Amadio and Daa Jaa, and commented out the portion of the bootstrap script that tries to download it from the old server. The script at first complained that EAPI 5 in the profile wasn't supported: !!! Unable to parse profile: '${EPREFIX}/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '${EPREFIX}/usr/portage/profiles/default/linux/eapi' !!! Unable to parse profile: '/opt/salt/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '${EPREFIX}/usr/portage/profiles/default/linux/eapi' !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and !!! --version. However, I was able to get around this by: cd ${EPREFIX}/usr/portage/profiles ; find . -name eapi -exec sed -i "s/5/4/" {} \; Unfortunatley the bootstrap build fails with bash, so I'll have to investigate how to proceed further.
Additional progress (gentoo-prefix on centos 6.3 x86_64). I had to copy the sytem /bin/bash to ${EPREFIX}/bin/bash, and make an ${EPREFIX}/bin/sh symlink. This fixed some 'missing /bin/sh' errors, allowing some dependencies to build, but bash still failed with undefined 'rl_filename_rewrite_hook' errors. emerge -pv revealed: [ebuild N ] app-shells/bash-4.2_p50::gentoo USE="net (readline) -afs -bashlogger -examples -mem-scramble -nls -plugins -vanilla" 0 kB I tried emerge readline and the other dependencies by hand, and while they emerged fine, this error continued to manifest. I finally attempted to emerge an older bash, and was successful in getting bash_4.0p41 to install (it installs ${EPREFIX}/bin/bash-4.0 only). I then removed the system copy of bash in ${EPREFIX}/bin/bash, and made it a symlink to ${EPREFIX}/bin/bash-4.0, preserving the ${EPREFIX}/bin/sh symlink as well. finally I reran the bootstrap script. With bash installed, it got a lot further. Most problems arose from (1) no EAPI 5 support (this ironically made installing gentoo-prefix on an existing gentoo box difficult enough that I gave up, EAPI 5 kept coming in despite having removed it from all the profiles under ${EPREFIX}), (2) "too-new" version of bash, (3) lack of automatic symlink creations of bin/bash and bin/sh in ${EPREFIX} (again, because of the behavior of bash-4 ebuilds). Systematically working through these seems to have cleared the bottleneck, and while stage3 is still running, gcc-4.7.3 has just installed. I'll update with any further manual interventions that are required (if any).
Created attachment 386776 [details] bootstrap-prefix.sh This is the bootstrap script I used to create my latest OS X prefix; I thought it might be useful for other people too.
(In reply to Jean-Michel Smith from comment #36) Please ignore my previous 2 comments. I was inadvertantly using an experimental bootstrap not intended for public consumption. If you download and use the bootstrap script included in the prefix-portage-093014.tar.bz2 tarball, it works pretty well: 1. run bootstrap-prefix.sh when it starts endlessly trying to download the latest tarball, ctrl-c out and cd to $EPREFIX/usr, then untar prefix-portage-093014.tar.bz2 and touch ${EPREFIX}/usr/portage/.unpacked Finally, rerun the script again. Voila! Many thanks to everyone on #gentoo-prefix for the help.
FWIW, I've converted&uploaded prefix-tree from mercurial to git: https://github.com/haubi/prefix-overlay
(In reply to Ruud Koolen from comment #22) > I'm working on a temporary replacement server, which should be up tomorrow > at the latest. > > > I've heard infra say this a couple of times, it never got off the ground > > though. > I'll take up the job of getting all of prefix's stuff infra-hosted. I'd love to have rsync infrastructure on gentoo hardware. An initial copy off rsync8 (the real rsync0 at the moment) would work for the short term. Long term goal would be like Christoph mentions in comment #31, migrate everything to gx86, such that we don't need our own rsync image. Next to this I would like to have a machine that can serve snapshots generated from the rsync tree. rsync8 does this now, but I have some reservations about the possible bandwidth implications this brings.
(In reply to Michael Haubenwallner from comment #39) > FWIW, I've converted&uploaded prefix-tree from mercurial to git: > https://github.com/haubi/prefix-overlay Can you update it to rsync8.prefix.bitzolder.nl/hg/prefix-tree? Your SSH-key should work to push there as well (replace hostname in the prefix.ge.org setup).
Add my two cents to this issue. I think this would be a good chance to change our development model to utilize sites like github and bitbucket. People can contribute by send PR to the main repo, which is much easier than attach a patch or ebuild file on b.g.o. The DVCS repo can then sync to the main RSYNC site manually or automatically. See how much contributors project like homebrew get: https://github.com/Homebrew/homebrew/graphs/contributors
(In reply to yegle from comment #42) > utilize sites like github and bitbucket. People can contribute by send PR to > the main repo, which is much easier than attach a patch or ebuild file on The "main repo" is the Gentoo Linux repository, so everyone is dependent on that.
(In reply to Jeremy Olexa (darkside) from comment #43) > (In reply to yegle from comment #42) > > > utilize sites like github and bitbucket. People can contribute by send PR to > > the main repo, which is much easier than attach a patch or ebuild file on > > The "main repo" is the Gentoo Linux repository, so everyone is dependent on > that. I'm referring the github/bitbucket repo as the "main repo". For the Gentoo Linux repo, the only way to contribute to that repo for those who is not a Gentoo developer, is to file a bug and leave patch/ebuild in bugs.gentoo.org (correct me if I'm wrong). I'm not sure if that repo uses any DVCS like git/hg, but the development model is definitely not in a distributed manner.
(In reply to yegle from comment #44) > (In reply to Jeremy Olexa (darkside) from comment #43) > > (In reply to yegle from comment #42) > > > > > utilize sites like github and bitbucket. People can contribute by send PR to > > > the main repo, which is much easier than attach a patch or ebuild file on > > > > The "main repo" is the Gentoo Linux repository, so everyone is dependent on > > that. > > I'm referring the github/bitbucket repo as the "main repo". For the Gentoo > Linux repo, the only way to contribute to that repo for those who is not a > Gentoo developer, is to file a bug and leave patch/ebuild in bugs.gentoo.org > (correct me if I'm wrong). > > I'm not sure if that repo uses any DVCS like git/hg, but the development > model is definitely not in a distributed manner. This is something for the larger of Gentoo to decide, like Jeremy pointed out, only some last remaining bits are in the prefix overlay. This is not something that the Prefix project can solve/use.
(In reply to Fabian Groffen from comment #41) > (In reply to Michael Haubenwallner from comment #39) > > FWIW, I've converted&uploaded prefix-tree from mercurial to git: > > https://github.com/haubi/prefix-overlay > > Can you update it to rsync8.prefix.bitzolder.nl/hg/prefix-tree? Your > SSH-key should work to push there as well (replace hostname in the > prefix.ge.org setup). Yep, SSH-key works. It turns out that I don't have anything newer though.
Patrick got me a dump of the prefix.gentooexperimental.org server, which I used to reconstruct all its functions on a temporary server which can take things over for now while we work out a longer-term solution.
I'm not sure if I understand why this happened, but dns re-pointing prefix.ge.org to an outdated server is not cool. Why did this have to happen???
Sorry, I hadn't noticed that you pushed lots of new stuff to the bitzolder server. I have synced them now.
... so rsync8.prefix.bitzolder.nl now has significantly different (more up to date?) content on it than prefix.ge.o - are these systems supposed to now be mirrors of each other, or is prefix.ge.o intended to be behind? (Or, on the other hand, has bz.nl forked and moved ahead?)
(In reply to Stuart Shelton from comment #50) > ... so rsync8.prefix.bitzolder.nl now has significantly different (more up > to date?) content on it than prefix.ge.o - are these systems supposed to now > be mirrors of each other, or is prefix.ge.o intended to be behind? > > (Or, on the other hand, has bz.nl forked and moved ahead?) I have no control over prefix.ge.o, I do have rsync8, so I recovered things on rsync8, see comment #8. Later in the process prefix.ge.o was pointed to another server, see comment #47. To me, rsync8 now hosts the one and only true source. At the moment, the original prefix.ge.o came back online, but it isn't available over DNS, I think (?)
I've been using the snapshots from prefix.gentooexperimental.org. Are these available from rsync8.prefix.bitzolder.nl? Do I understand correctly that the tree at rsync8.prefix.bitzolder.nl is an overlay, and that the snapshots at prefix.gentooexperimental.org were of the overlay merged into the main tree? If so, how do I convert my portage tree to use the main tree + overlay?
rsync8 provides what prefix.ge.o used to provide, no changes necessary. In the meantime, rsync5.prefix.bitzolder.nl is the old prefix.ge.o, and you can use that one too.
and it seems like prefix.ge.org points to the original server again, so more or less everything is back to "normal"
Server is back. Mercurial pushes should go to rsync8.prefix.bitzolder.nl. No user visible changes.
Any chance we can move to git and/or keep a copy of the repo on GitHub? I have no means to contribute right now other than attach patches to the bugs I find/report...
