emerge-delta-webrsync this morning deleted a lot of nodes. Checked in some mirrors for portage-20061019.tar.bz2: his size is only 6.2M
It seems like a critical copy command in our snapshot creation script failed to copy all of the files for some reason. I was able to reproduce the problem by running the script manually. After replacing the cp command with an rsync command, I was able to successfully create the snapshots. The should reach the main mirror in about 15 minutes I think.
(In reply to comment #1) > After replacing the cp command with an rsync > command, I was able to successfully create the snapshots. The should reach > the main mirror in about 15 minutes I think. and so did it, yet something must have gone wrong, as after a renewed emerge-webrsync emerge -u world tries to downgrade alsa to 1.0.11 (yesterday it updated to 1.0.12...) wassup? -- Marek Lewandowski ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl my gallery: http://www.pbase.com/mareklew my kind-of-a-blog: http://lockaphoto.stufftoread.com
(In reply to comment #2) > and so did it, yet something must have gone wrong, as after a renewed > emerge-webrsync emerge -u world tries to downgrade alsa to 1.0.11 (yesterday it > updated to 1.0.12...) That could be completely unrelated to this bug.
The new snapshot breaks the update path for delta users? Or how is the new delta file generated?
(In reply to comment #3) > > and so did it, yet something must have gone wrong, as after a renewed > > emerge-webrsync emerge -u world tries to downgrade alsa to 1.0.11 > > (yesterday it > > updated to 1.0.12...) > That could be completely unrelated to this bug. could be, I just assumed, that wrong ebuild file was picked on the way and if it happened once, it could happen somewhere else too. I don't know, how the generation script of portage snapshot works. Yet, the coincidence - if it is coincidence - felt strange too me, as the alsa-1.0.12 was just put on x86 on Wednesday this week, also yesterday's snapshot was the first one to include it and today's - first one to drop it... whatever. -- Marek Lewandowski ICQ#/GG#: ask per mail. mail: locust[X]poczta/onet/pl my gallery: http://www.pbase.com/mareklew my kind-of-a-blog: http://lockaphoto.stufftoread.com
(In reply to comment #2) > and so did it, yet something must have gone wrong, as after a renewed > emerge-webrsync emerge -u world tries to downgrade alsa to 1.0.11 (yesterday it > updated to 1.0.12...) That shouldn't be related to this bug. Just updated to new portage tree ad all alsa packages are still marked stable for version 1.0.12 (I assumed you have ACCEPT_KEYWORDS="x86" in your /etc/make.conf). Run "emerge -p media-libs/alsa-lib" to see which version would be merged. Maybe you have some package installed depending on alsa <1.0.12; in this case, if you downgrade alsa, when you later run "emerge -u world" probably alsa will be upgraded again (it happened to me in the past with some other package). Try to run "emerge -puDt world" and if necessary fill a new bug.
(In reply to comment #6) > [... good advice...] > Try to run "emerge -puDt world" and if necessary fill a new bug. I'll try it on Monday (it's a production machine at work) and if the result differs from your predictions, I'll try nailing it down. Thanks. Marek Lewandowski
*** Bug 152067 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > The new snapshot breaks the update path for delta users? Or how is the new > delta file generated? I used the exact same script to generate them that normally does it. Here's the command that it should have used (effectively): differ -f bdelta portage-20061018.tar portage-20061019.tar snapshot-20061018-20061019.patch I've heard reports of the delta path being broken in cases such as this before, but I don't understand why that would occur (assuming that the source tarballs are the correct ones).
(In reply to comment #4) > The new snapshot breaks the update path for delta users? Or how is the new > delta file generated? I've just noticed that I have misunderstood the delta creation process. Now I see the patches should be created as follows: differ -f bdelta snapshot-20061017-20061018.patch portage-20061019.tar snapshot-20061018-20061019.patch I've removed the faulty snapshot-20061018-20061019.patch.bz2 from the master mirror and will work on creating a new one.
(In reply to comment #10) > I've just noticed that I have misunderstood the delta creation process. Actually, comment #9 was accurate and I've understood it correctly all along. Please let me know the details if you have problems with emerge-delta-webrsync. The snapshot failed again for the most recent snapshots. This time, the script bailed out when running rsync (which I had used to replace the cp command that was apparently failing silently). Here's the error from the log: Invalid checksum length -1610612734 [sender] rsync error: protocol incompatibility (code 2) at io.c(960) [sender=2.6.8] rsync: writefd_unbuffered failed to write 78 bytes [generator]: Broken pipe (32) rsync error: error in rsync protocol data stream (code 12) at io.c(1121) [generator=2.6.8] I'm not sure what that means (If anybody has a clue, please comment). Anyway, I'm going to look into eliminating the copy step all together, because it's inefficient.
(In reply to comment #10) > I've removed the faulty snapshot-20061018-20061019.patch.bz2 from the master > mirror and will work on creating a new one. The faulty snapshot-20061018-20061019.patch.bz2 you are referring is the one present when I filled this bug? I have updated portage just before my comment #6 using emerge-delta-webrsync and it worked.
(In reply to comment #12) > I have updated portage just before my comment #6 using emerge-delta-webrsync > and it worked. Great, thanks for the feedback. I had already realized that the delta was created correctly (afaik) and put it back again. There's a 20061019-20061020 delta up there now too (at least on the master mirror by now).
I'm still not quite sure what caused the issues with cp and rsync. Anyway, I've fixed the snapshot creation script so that it creates the tar file directly (without an intermediate copy). It seems to be working alright.
Just suggestion... You can add sanity check before signature, so if the size of the new snapshot tar ball size is different by more than X percent from the previous one, it needs manual intervention. X=20% is unlikely to be a result of Gentoo developers commit activity. And could have detected this flow. Regards,
(In reply to comment #15) > Just suggestion... You can add sanity check before signature, so if the size > of the new snapshot tar ball size is different by more than X percent from the > previous one, it needs manual intervention. Thanks for the suggestion. It's now implemented so that a 20% decrease in size will automatically cause the script to bail out. The script that removes old deltas actually uses the size of the latest snapshot in it's calculation of how many deltas to keep, which adds more importance to this sanity check. Since the 20061019 snapshot was so small, an abnormal number of deltas were removed. That may be what comment #4 was about.
