View previous topic :: View next topic |
Author |
Message |
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Mon Aug 22, 2005 12:08 am Post subject: emerge glibc dies with 404 errors. [SOLVED] |
|
|
has anyone else encountered a problem in emerging glibc today?
Code: | tux / # emerge glibc -v
Calculating dependencies ...done!
>>> emerge (1 of 1) sys-libs/glibc-2.3.5-r1 to /
>>> Downloading http://gentoo.osuosl.org/distfiles/glibc-2.3.5-patches-1.8.tar.bz2
--23:59:25-- http://gentoo.osuosl.org/distfiles/glibc-2.3.5-patches-1.8.tar.bz2
=> `/usr/portage/distfiles/glibc-2.3.5-patches-1.8.tar.bz2'
Resolving gentoo.osuosl.org... 140.211.166.134
Connecting to gentoo.osuosl.org[140.211.166.134]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
23:59:26 ERROR 404: Not Found.
>>> Downloading http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/glibc-2.3.5-patches-1.8.tar.bz2
--23:59:26-- http://www.ibiblio.org/pub/Linux/distributions/gentoo/distfiles/glibc-2.3.5-patches-1.8.tar.bz2
=> `/usr/portage/distfiles/glibc-2.3.5-patches-1.8.tar.bz2'
Resolving www.ibiblio.org... 152.2.210.80
Connecting to www.ibiblio.org[152.2.210.80]:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/glibc-2.3.5-patches-1.8.tar.bz2 [following]
--23:59:28-- http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles/glibc-2.3.5-patches-1.8.tar.bz2
=> `/usr/portage/distfiles/glibc-2.3.5-patches-1.8.tar.bz2'
Resolving distro.ibiblio.org... 152.2.210.109
Connecting to distro.ibiblio.org[152.2.210.109]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
23:59:29 ERROR 404: Not Found.
>>> Downloading http://gentoo.netnitco.net/distfiles/glibc-2.3.5-patches-1.8.tar.bz2
--23:59:29-- http://gentoo.netnitco.net/distfiles/glibc-2.3.5-patches-1.8.tar.bz2
=> `/usr/portage/distfiles/glibc-2.3.5-patches-1.8.tar.bz2'
Resolving gentoo.netnitco.net... 216.176.132.235
Connecting to gentoo.netnitco.net[216.176.132.235]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
23:59:29 ERROR 404: Not Found.
>>> Downloading http://dev.gentoo.org/~eradicator/glibc/glibc-2.3.5-patches-1.8.tar.bz2
--23:59:29-- http://dev.gentoo.org/%7Eeradicator/glibc/glibc-2.3.5-patches-1.8.tar.bz2
=> `/usr/portage/distfiles/glibc-2.3.5-patches-1.8.tar.bz2'
Resolving dev.gentoo.org... 134.68.220.30
Connecting to dev.gentoo.org[134.68.220.30]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
23:59:30 ERROR 404: Not Found.
!!! Couldn't download glibc-2.3.5-patches-1.8.tar.bz2. Aborting.
tux / # |
_________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Last edited by Bob P on Mon Aug 22, 2005 8:16 pm; edited 1 time in total |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
|
Back to top |
|
|
eradicator Retired Dev
Joined: 01 Apr 2003 Posts: 144 Location: Berkeley, CA
|
Posted: Mon Aug 22, 2005 3:56 am Post subject: |
|
|
Actually, your portage seems old. 2.3.5-r1 has been using the 1.9 version of the patchset for the past 11 days. Please always emerge --sync and try again before posting bugs.
As for the 404, somebody rolled a release of the glibc patchset and put it on the mirrors, but didn't update the SRC_URI to put it in their devspace before it hit the mirrors. I don't know why you're 404ing on it as it certainly was moved to the mirrors... but that doesn't matter as you'll use the 1.9 tarball when you --sync. _________________ Gentoo Developer: amd64, sparc, sound, toolchain, accessibility |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Mon Aug 22, 2005 4:35 am Post subject: |
|
|
eradicator wrote: | As for the 404, somebody rolled a release of the glibc patchset and put it on the mirrors, but didn't update the SRC_URI to put it in their devspace before it hit the mirrors. I don't know why you're 404ing on it as it certainly was moved to the mirrors... |
well, it appears that i'm 404-ing on it because the patch file was deleted from your ~eradicator devspace.
Code: | >>> Downloading http://dev.gentoo.org/~eradicator/glibc/glibc-2.3.5-patches-1.8.tar.bz2
--23:59:29-- http://dev.gentoo.org/%7Eeradicator/glibc/glibc-2.3.5-patches-1.8.tar.bz2
=> `/usr/portage/distfiles/glibc-2.3.5-patches-1.8.tar.bz2'
Resolving dev.gentoo.org... 134.68.220.30
Connecting to dev.gentoo.org[134.68.220.30]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
23:59:30 ERROR 404: Not Found. |
notice that the required patch file is conspicuously absent:
Code: | Index of /~eradicator/glibc
Icon Name Last modified Size Description[DIR] Parent Directory -
[ ] c_stubs-2.1.2.tar.bz2 16-Feb-2005 04:17 10K
[ ] emul-linux-x86-glibc-1.2-lt.tar.bz2 02-Feb-2005 00:00 3.3M
[ ] emul-linux-x86-glibc-1.2-nptl.tar.bz2 01-Feb-2005 23:48 4.5M
[ ] emul-linux-x86-glibc-1.2-nptlonly.tar.bz2 01-Feb-2005 23:44 3.3M
[ ] emul-linux-x86-glibc-2.3.5-lt.tar.bz2 12-Jul-2005 08:40 7.7M
[ ] emul-linux-x86-glibc-2.3.5-nptl.tar.bz2 12-Jul-2005 08:45 9.0M
[ ] emul-linux-x86-glibc-2.3.5-nptlonly.tar.bz2 12-Jul-2005 09:28 6.9M
[ ] glibc-2.3.4-patches-1.0.tar.bz2 05-Feb-2005 23:45 31K
[ ] glibc-2.3.4-patches-1.1.tar.bz2 07-Feb-2005 06:36 31K
[ ] glibc-2.3.4-patches-1.2.tar.bz2 16-Feb-2005 03:46 31K
[ ] glibc-2.3.4-patches-1.3.tar.bz2 19-Feb-2005 20:08 31K
[ ] glibc-2.3.4-patches-1.4.tar.bz2 04-Mar-2005 10:35 32K
[ ] glibc-2.3.4-patches-1.5.tar.bz2 07-Mar-2005 11:24 32K
[ ] glibc-2.3.4-patches-1.6.tar.bz2 15-Mar-2005 12:45 33K
[ ] glibc-2.3.4-patches-1.7.tar.bz2 15-Mar-2005 23:02 37K
[ ] glibc-2.3.5-patches-1.0.tar.bz2 11-Apr-2005 23:43 31K
[ ] glibc-2.3.5-patches-1.1.tar.bz2 12-Apr-2005 03:06 31K
[ ] glibc-2.3.5-patches-1.2.tar.bz2 14-Apr-2005 07:24 31K
[ ] glibc-2.3.5-patches-1.4.tar.bz2 30-Jul-2005 03:56 19K
[ ] glibc-2.3.5-patches-1.5.tar.bz2 15-Jul-2005 20:23 19K
[ ] glibc-2.3.5-patches-1.6.tar.bz2 22-Jul-2005 19:24 20K
[ ] glibc-2.3.5-patches-1.7.tar.bz2 26-Jul-2005 19:58 21K
[ ] glibc-2.3.5-patches-1.9.tar.bz2 11-Aug-2005 09:37 24K
[ ] glibc-fedora-20041219T2331.tar.bz2 04-Mar-2005 10:30 744K
[ ] glibc-fedora-20050524T1606.tar.bz2 14-Jul-2005 08:18 748K
[ ] glibc-infopages-2.3.4-r1.tar.bz2 10-Feb-2005 23:07 1.2M
[ ] glibc-infopages-2.3.5.tar.bz2 25-Jul-2005 19:39 1.2M
[ ] glibc-manpages-2.3.4-r1.tar.bz2 07-Feb-2005 06:36 22K
[ ] glibc-manpages-2.3.5.tar.bz2 11-Apr-2005 23:43 22K
Apache Server at dev.gentoo.org Port 80
|
yes, my portage snapshot is locked on 20050808. from a multiple platform development perspective, a portage lockdown sync'd to a snapshot that has been determined to be stable by testing is an absolute requirement -- so that corruptions are not introduced into the system by instabilities in the portage tree. this logic, of course, falls apart if instability is injected into portage when patches that work properly are silently removed from the portage tree and backward compatibility is ~eradicated. maybe that wasn't such a great idea, but i guess i'll find a way to deal with it.
thanks for identifiying the source of the problem.
personally, i think it would be easier to supply the missing file to people who need it than it would be to compel them to start over and do things your way. in my case, its easier for me to just supply the missing file on my own than it is to follow your advice and completely re-invent the entire series of Jackass! 2005.1 tarballs and ask the testing team to start testing them all over again. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
eradicator Retired Dev
Joined: 01 Apr 2003 Posts: 144 Location: Berkeley, CA
|
Posted: Mon Aug 22, 2005 7:01 am Post subject: |
|
|
Bob P wrote: | eradicator wrote: | As for the 404, somebody rolled a release of the glibc patchset and put it on the mirrors, but didn't update the SRC_URI to put it in their devspace before it hit the mirrors. I don't know why you're 404ing on it as it certainly was moved to the mirrors... |
well, it appears that i'm 404-ing on it because the patch file was deleted from your ~eradicator devspace.
|
Uhm, it never was in my devspace. I didn't make it. Whoever did make it did not update the URL in the file to the correct location.
Quote: |
personally, i think it would be easier to supply the missing file to people who need it than it would be to compel them to start over and do things your way. in my case, its easier for me to just supply the missing file on my own than it is to follow your advice and completely re-invent the entire series of Jackass! 2005.1 tarballs and ask the testing team to start testing them all over again.
|
Well as I said, I didn't make the file, and I don't know where it is, so there's no way for me to place it in my devspace to make that url valid. _________________ Gentoo Developer: amd64, sparc, sound, toolchain, accessibility |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Mon Aug 22, 2005 9:11 am Post subject: |
|
|
eradicator wrote: | Bob P wrote: | eradicator wrote: | As for the 404, somebody rolled a release of the glibc patchset and put it on the mirrors, but didn't update the SRC_URI to put it in their devspace before it hit the mirrors. I don't know why you're 404ing on it as it certainly was moved to the mirrors... |
well, it appears that i'm 404-ing on it because the patch file was deleted from your ~eradicator devspace.
|
Uhm, it never was in my devspace. I didn't make it. Whoever did make it did not update the URL in the file to the correct location. |
you asked why i filed a bug report. well, if portage is corrupted and it is pointing to a URL that is not the actual location of the patch files, then that seems like a reasonable reason to file a bug report to me.
Quote: | Well as I said, I didn't make the file, and I don't know where it is, so there's no way for me to place it in my devspace to make that url valid. |
i don't mean to belabor this point. i realize that its futile. i guess that i am just way off base and making erroneous assumptions.
when i saw portage attempting to download the file from your devspace, i assumed that you were the responsible developer.
when i saw versions of glibc-2.3.5 patches on your devspace that were sequentially numbered from version 2.3.4-1.0 all of the way up to 2.3.5-1.9, i assumed that you were the responsible developer.
when i saw that all of the versions of the patch file were present in your devspace except for 2.3.5-1.8, i mistakenly assumed that you had inadvertently deleted the file from your devspace.
evidently i'm wrong, and someone else is responsible for all of these files on the ~eradicator devspace, and someone else ~eradicated the missing file. even if that's the case, it would be interesting to know who is responsible for that file and where it has gone.
sorry for the trouble. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
eradicator Retired Dev
Joined: 01 Apr 2003 Posts: 144 Location: Berkeley, CA
|
Posted: Mon Aug 22, 2005 9:52 am Post subject: |
|
|
Bob P wrote: |
you asked why i filed a bug report. well, if portage is corrupted and it is pointing to a URL that is not the actual location of the patch files, then that seems like a reasonable reason to file a bug report to me.
|
Right, but it isn't an issue any more. Please do not file a bug report without checking first if it is still a problem.
Quote: |
i don't mean to belabor this point. i realize that its futile. i guess that i am just way off base and making erroneous assumptions.
when i saw portage attempting to download the file from your devspace, i assumed that you were the responsible developer.
I understand that, but your assumption is wrong. Someone else just updated the ebuild and did not change the URL.
when i saw versions of glibc-2.3.5 patches on your devspace that were sequentially numbered from version 2.3.4-1.0 all of the way up to 2.3.5-1.9, i assumed that you were the responsible developer.
when i saw that all of the versions of the patch file were present in your devspace except for 2.3.5-1.8, i mistakenly assumed that you had inadvertently deleted the file from your devspace.
evidently i'm wrong, and someone else is responsible for all of these files on the ~eradicator devspace, and someone else ~eradicated the missing file. even if that's the case, it would be interesting to know who is responsible for that file and where it has gone.
sorry for the trouble. |
I am responsibe for the files in ~eradicator. That is my devspace. I never made a 1.8 tarball. 1.8 is not in my devspace becasue I never made it. Someone else made it and did not change the ebuild to point to the right location, and additionally I guess your mirror deleted the file from its distfiles. Try a different mirror. _________________ Gentoo Developer: amd64, sparc, sound, toolchain, accessibility |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Mon Aug 22, 2005 10:49 am Post subject: |
|
|
eradicator wrote: | Someone else made it and did not change the ebuild to point to the right location, and additionally I guess your mirror deleted the file from its distfiles. Try a different mirror. |
try a different mirror?!? that has to be the mother of all wild-goose-chase recommendations. if the file isn't on OSUOSL or IBIBLIO (mirrors that i checked in the initial post), then i'm confident that its not on any mirror that is up to date.
i'm looking at the CVS information to see who's been tinkering with the ebuilds. does this give any clues as to who the "mystery developer" who is responsible might be?
http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-libs/glibc/glibc-2.3.5-r1.ebuild?rev=1.21&view=log
Code: | gentoo-x86: sys-libs/glibc/glibc-2.3.5-r1.ebuild
Default branch: MAIN
Bookmark a link to HEAD: (view) (download)
Revision 1.21 - (view) (download) (annotate) - [select for diffs]
Sun Aug 21 09:13:28 2005 UTC (26 hours, 13 minutes ago) by matsuu
Branch: MAIN
CVS Tags: HEAD
Changes since 1.20: +2 -2 lines
Diff to previous 1.20
Stable on sh.
(Portage version: 2.0.51.22-r2)
Revision 1.20 - (view) (download) (annotate) - [select for diffs]
Sun Aug 21 04:25:11 2005 UTC (31 hours, 2 minutes ago) by eradicator
Branch: MAIN
Changes since 1.19: +4 -1 lines
Diff to previous 1.19
Force builds of x86 glibc on amd64 to ignore /emul.
(Portage version: 2.0.51.22-r2)
Revision 1.19 - (view) (download) (annotate) - [select for diffs]
Wed Aug 17 00:36:34 2005 UTC (5 days, 10 hours ago) by vapier
Branch: MAIN
Changes since 1.18: +2 -1 lines
Diff to previous 1.18
Make sure we filter all -O flags before we lock down to -O2 #77264.
(Portage version: 2.0.51.22-r2)
Revision 1.18 - (view) (download) (annotate) - [select for diffs]
Tue Aug 16 01:30:46 2005 UTC (6 days, 9 hours ago) by eradicator
Branch: MAIN
Changes since 1.17: +2 -2 lines
Diff to previous 1.17
Stable on amd64 and x86 to address issues which cropped up since 2.3.5 went stable. This fixes bugs #52374, #85718, #100190.
(Portage version: 2.0.51.22-r2)
Revision 1.17 - (view) (download) (annotate) - [select for diffs]
Sat Aug 13 03:54:31 2005 UTC (9 days, 7 hours ago) by vapier
Branch: MAIN
Changes since 1.16: +2 -1 lines
Diff to previous 1.16
fake out a usr symlink so that --with-sysroot works with gcc
(Portage version: 2.0.51.22-r2)
Revision 1.16 - (view) (download) (annotate) - [select for diffs]
Wed Aug 10 22:27:46 2005 UTC (11 days, 12 hours ago) by eradicator
Branch: MAIN
Changes since 1.15: +2 -3 lines
Diff to previous 1.15
Fixed USE=profile support... bug #100092.
(Portage version: 2.0.51.22-r2)
Revision 1.15 - (view) (download) (annotate) - [select for diffs]
Wed Aug 10 01:46:40 2005 UTC (12 days, 9 hours ago) by vapier
Branch: MAIN
Changes since 1.14: +2 -2 lines
Diff to previous 1.14
add some patches from Debian
(Portage version: 2.0.51.22-r2)
Revision 1.14 - (view) (download) (annotate) - [select for diffs]
Sun Aug 7 04:14:33 2005 UTC (2 weeks, 1 day ago) by vapier
Branch: MAIN
Changes since 1.13: +2 -2 lines
Diff to previous 1.13
configure option is profile not profiling #100092 by R Hill
(Portage version: 2.0.51.22-r2)
Revision 1.13 - (view) (download) (annotate) - [select for diffs]
Thu Aug 4 19:36:30 2005 UTC (2 weeks, 3 days ago) by azarah
Branch: MAIN
Changes since 1.12: +2 -2 lines
Diff to previous 1.12
Fix typo, bug #101374.
(Portage version: 2.0.51.22-r2)
Revision 1.12 - (view) (download) (annotate) - [select for diffs]
Sun Jul 31 06:42:23 2005 UTC (3 weeks, 1 day ago) by matsuu
Branch: MAIN
Changes since 1.11: +2 -2 lines
Diff to previous 1.11
Added ~sh to KEYWORDS.
(Portage version: 2.0.51.22-r2)
Revision 1.11 - (view) (download) (annotate) - [select for diffs]
Fri Jul 29 23:25:21 2005 UTC (3 weeks, 2 days ago) by vapier
Branch: MAIN
Changes since 1.10: +2 -2 lines
Diff to previous 1.10
Add patches for SuperH.
(Portage version: 2.0.51.22-r2)
Revision 1.10 - (view) (download) (annotate) - [select for diffs]
Fri Jul 29 22:28:41 2005 UTC (3 weeks, 2 days ago) by eradicator
Branch: MAIN
Changes since 1.9: +1 -16 lines
Diff to previous 1.9
Fix cross-compilation RDEPENDs
(Portage version: 2.0.51.22-r2)
Revision 1.9 - (view) (download) (annotate) - [select for diffs]
Tue Jul 26 23:17:53 2005 UTC (3 weeks, 5 days ago) by eradicator
Branch: MAIN
Changes since 1.8: +2 -2 lines
Diff to previous 1.8
Remove a nested function from iconvconfig to make it play nicer for hardened users. Closes bug #85718.
(Portage version: 2.0.51.22-r2)
Revision 1.8 - (view) (download) (annotate) - [select for diffs]
Tue Jul 26 22:20:42 2005 UTC (3 weeks, 5 days ago) by vapier
Branch: MAIN
Changes since 1.7: +8 -10 lines
Diff to previous 1.7
fix retarded cross-compile depends
(Portage version: 2.0.51.22-r2)
Revision 1.7 - (view) (download) (annotate) - [select for diffs]
Sun Jul 24 20:01:56 2005 UTC (4 weeks ago) by azarah
Branch: MAIN
Changes since 1.6: +11 -4 lines
Diff to previous 1.6
Add the stripping of the dynamic linker from the snapshot ebuilds, else we
cannot set breakpoints in shared libraries. Make sure we only move actual
files and not symlinks to the tmp directory.
(Portage version: 2.0.51.22-r2)
Revision 1.6 - (view) (download) (annotate) - [select for diffs]
Sun Jul 24 07:10:44 2005 UTC (4 weeks, 1 day ago) by corsair
Branch: MAIN
Changes since 1.5: +2 -2 lines
Diff to previous 1.5
added ~ppc64
(Portage version: 2.0.51.22-r1)
Revision 1.5 - (view) (download) (annotate) - [select for diffs]
Sat Jul 23 20:07:50 2005 UTC (4 weeks, 1 day ago) by eradicator
Branch: MAIN
Changes since 1.4: +3 -3 lines
Diff to previous 1.4
Changed CHOST->CTARGET for 486/586 linuxthreads workaround. Set keywords in 2.3.5-r1 to ~amd64 ~sparc ~x86 in prep to remove from package.mask.
(Portage version: 2.0.51.22-r2)
Revision 1.4 - (view) (download) (annotate) - [select for diffs]
Fri Jul 22 19:40:39 2005 UTC (4 weeks, 2 days ago) by eradicator
Branch: MAIN
Changes since 1.3: +4 -4 lines
Diff to previous 1.3
Readded 1040_all_2.3.3-localedef-fix-trampoline.patch which got lost during a glibc bump. Shoud address bug #85718. Also, let --with-__thread be controlled by linuxthread-tls instead of !glibc-compat20.
(Portage version: 2.0.51.22-r2)
Revision 1.3 - (view) (download) (annotate) - [select for diffs]
Sun Jul 17 11:16:32 2005 UTC (5 weeks, 1 day ago) by eradicator
Branch: MAIN
Changes since 1.2: +2 -2 lines
Diff to previous 1.2
Workaround for bug #90236 in 2.3.5. Bump of infopages in 2.3.5-r1.
(Portage version: 2.0.51.22-r1)
Revision 1.2 - (view) (download) (annotate) - [select for diffs]
Fri Jul 15 21:04:52 2005 UTC (5 weeks, 2 days ago) by eradicator
Branch: MAIN
Changes since 1.1: +2 -5 lines
Diff to previous 1.1
Removed the PDEPEND on emul-glibc for amd64 as this release (and all future releases) are masked on 2004.3 for amd64.
(Portage version: 2.0.51.22-r1)
Revision 1.1 - (view) (download) (annotate) - [select for diffs]
Fri Jul 15 20:54:27 2005 UTC (5 weeks, 2 days ago) by eradicator
Branch: MAIN
Revision bump to address bugs #52374, #82424, and #95351.
(Portage version: 2.0.51.22-r1)
|
this missing patch file has been available all month, but stopped being available today. is it coincidental that the emergence of this file suddenly began to fail commensurate with your modification of the ebuild 31 hours ago?
just in case anyone else is in need of the file, it is available here:
http://mysite.verizon.net/res8b0x8/gentoo/glibc-2.3.5-patches-1.8.tar.bz2
i disagree with your suggestion in the bug report that the problem is no longer an issue if an emerge --sync can be performed. multiple-platform development and testing has to be standardized on a stable portage snapshot. thorough and complete testing for stability (admittedly, a foreign concept in some circles) takes more than 10 days, and developers who perform responsible QA cannot be expected to be syncing and rebuilding their projects on a daily basis.
on the subject of QA, the integrity of gentoo and the portage system absolutely requires that somebody isn't going to inappropriately and erroneously start deleting patch files just because they are over 10 days old.
the bottom line is that this file was inappropriately and erroneously removed from a perfectly functional portage tree by some unnamed mystery developer who wants to remain anonymous because he/she wasn't paying attention to the trouble that could be caused by indiscriminately deleting files. even worse, whoever is responsible hasn't yet stepped up to accept responsibility for the problem, and with dismissal of the bug report as "invalid" [sic] the situation is being obfuscated so that users are having difficulty elucidating the nature of the problem.
i have recovered the file and made it available to anyone else who might need it. now that the file is available, i think that any further disucssion about who caused the problem is actually moot. the CVS document seems to speak for itself anyway.
Edit: specific information for 2.3.5-r1 ebuild _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Last edited by Bob P on Mon Aug 22, 2005 11:32 am; edited 1 time in total |
|
Back to top |
|
|
nxsty Veteran
Joined: 23 Jun 2004 Posts: 1556 Location: .se
|
Posted: Mon Aug 22, 2005 11:05 am Post subject: |
|
|
Bob P wrote: | i disagree with your suggestion in the bug report that the problem is no longer an issue if an emerge --sync can be performed. multiple-platform development and testing has to be standardized on a stable portage snapshot. thorough and complete testing for stability (admittedly, a foreign concept in some circles) takes more than 10 days, and developers who perform responsible QA cannot be expected to be syncing and rebuilding their projects on a daily basis.
on the subject of QA, the integrity of gentoo and the portage system absolutely requires that somebody isn't going to inappropriately and erroneously start deleting patch files just because they are over 10 days old.
the bottom line is that this file was inappropriately and erroneously removed from a perfectly functional portage tree by some unnamed mystery developer who wants to remain anonymous because he/she wasn't paying attention to the trouble that could be caused by indiscriminately deleting files. even worse, whoever is responsible hasn't yet stepped up to accept responsibility for the problem, and with dismissal of the bug report as "invalid" [sic] the situation is being obfuscated so that users are having difficulty elucidating the nature of the problem. |
Then why didn't you download all distfiles then when you took the portage snapshot, if it's now such important? There is no guarantee that the mirrors will keep old distfiles if the ebuilds are updated.
And btw, the cvs changelog you have linked to and included in your post is for the wrong ebuild. The one you are trying to emerge is 2.3.5-r1 but the ebuild you have linked to is 2.3.5. |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Mon Aug 22, 2005 11:35 am Post subject: |
|
|
Quote: | Then why didn't you download all distfiles then when you took the portage snapshot, if it's now such important? There is no guarantee that the mirrors will keep old distfiles if the ebuilds are updated. |
well, i did in fact download all of the distfiles that were relevant to our project. that is how i was able to recover them after they had disappeared from the portage tree.
Quote: | And btw, the cvs changelog you have linked to and included in your post is for the wrong ebuild. The one you are trying to emerge is 2.3.5-r1 but the ebuild you have linked to is 2.3.5. |
thank you for pointing out that error. the quoted material has been updated, but none of the identities have changed, nor has the timecourse of the updates changed, as both ebuilds were updated in parallel. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
nxsty Veteran
Joined: 23 Jun 2004 Posts: 1556 Location: .se
|
Posted: Mon Aug 22, 2005 11:38 am Post subject: |
|
|
Bob P wrote: | thank you for pointing out that error. the quoted material has been updated, but none of the identities have changed, nor has the timecourse of the updates changed, as both ebuilds were updated in parallel. |
This is the change you are looking for. It's done by vapier and changes PATCH_VER from 1.8 to 1.9.
Quote: | Revision 1.15 - (view) (download) (annotate) - [select for diffs]
Wed Aug 10 01:46:40 2005 UTC (12 days, 9 hours ago) by vapier
Branch: MAIN
Changes since 1.14: +2 -2 lines
Diff to previous 1.14
add some patches from Debian
(Portage version: 2.0.51.22-r2) |
|
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Mon Aug 22, 2005 5:54 pm Post subject: |
|
|
nxsty wrote: | This is the change you are looking for. It's done by vapier and changes PATCH_VER from 1.8 to 1.9.
Quote: | Revision 1.15 - (view) (download) (annotate) - [select for diffs]
Wed Aug 10 01:46:40 2005 UTC (12 days, 9 hours ago) by vapier
Branch: MAIN
Changes since 1.14: +2 -2 lines
Diff to previous 1.14
add some patches from Debian
(Portage version: 2.0.51.22-r2) |
|
thanks. that Repository Markup that you've cited does indeed show that vapier changed the patch version from 1.8 to 1.9.
what i think is more insteresting though, is that the previous Repository Markup 1.14 shows that the 1.8 patchset for glibc is supposed to reside at the gentoo devspace of the developer maintaining that ebuild:
http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-libs/glibc/glibc-2.3.5-r1.ebuild?rev=1.14&view=markup
clearly, the 1.8 version of the patch file used to reside at http://dev.gentoo.org/~eradicator/glibc/ but it was inappropriately removed. according to the standards listed in the Repository Markup, the patch file is supposed to remain persistent, just as the previous 10 patch files have remained persistent:
Quote: | # GENTOO_TOOLCHAIN_BASE_URI
# This sets the base URI for all gentoo-specific patch files. Note
# that this variable is only important for a brief period of time,
# before your source files get picked up by mirrors. However, it is
# still highly suggested that you keep files in this location
# available. |
and Quote: | GENTOO_TOOLCHAIN_BASE_URI="http://dev.gentoo.org/~eradicator/glibc"
get_glibc_src_uri() {
# This variable should be set to the devspace of whoever is currently
# maintaining GLIBC. Please dont set this to mirror, that would just
# make the files unavailable until they get mirrored.
local devspace_uri="http://dev.gentoo.org/~eradicator/glibc/"
|
- the issue isn't who made the update to the ebuild to use patchset 1.9 instead of 1.8 -- we know who did that.
- the issue isn't who's devspace the file is supposed to be located on -- we know that, too.
- the issue is that an important patch file that is supposed to remain on the devspace is Missing In Action and the bug report about it was resolved as invalid because this file is claimed never to have existed.
my intent in pursuing this is not to place blame on anyone. its only to gather enough interest from a responsible party to put a critical patch file back on the devspace where it belongs.
i think we've pretty clearly identified that the file did exist, that it does exist today, and where it is supposed to reside on the Gentoo devspace. it would be very pleasing if someone who has the capability of depositing the file in its appropriate place would follow the guidelines regarding the maintenance of files, rather than just dismissing the bug as invalid and suggesting that everyone in the world resync and start their projects over.
this is an example of how Gentoo becomes unnecessarily b0rken. an approach that involved admitting little mistakes and correcting them would make Gentoo alot more user friendly than claiming that verified complaints are invalid. but that's just my personal take on the subject.
hopefully this file will find its way back to where it belongs, as i think that people who need it are more likely to find it there than on my personal webspace.
thanks for your help. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
eradicator Retired Dev
Joined: 01 Apr 2003 Posts: 144 Location: Berkeley, CA
|
Posted: Mon Aug 22, 2005 7:44 pm Post subject: |
|
|
Bob P wrote: |
i'm looking at the CVS information to see who's been tinkering with the ebuilds. does this give any clues as to who the "mystery developer" who is responsible might be?
this missing patch file has been available all month, but stopped being available today. is it coincidental that the emergence of this file suddenly began to fail commensurate with your modification of the ebuild 31 hours ago?
|
If you care, look at the individual changes to see who added the 1.8 tarball and get mad at them. As it is, I don't care because there's nothing more I can do. You found the tarball, so I've put it in my devspace to make it available. Beyond that, there's nothing for me to do! And frankly, they were OK in what they did because they put it on the mirrors... You should talk to infra about why it was removed from the mirrors. THAT is the problem.
Quote: |
i disagree with your suggestion in the bug report that the problem is no longer an issue if an emerge --sync can be performed. multiple-platform development and testing has to be standardized on a stable portage snapshot. thorough and complete testing for stability (admittedly, a foreign concept in some circles) takes more than 10 days, and developers who perform responsible QA cannot be expected to be syncing and rebuilding their projects on a daily basis.
|
Ok... well how would you expect me to fix it for you when it is already fixed?
Quote: |
on the subject of QA, the integrity of gentoo and the portage system absolutely requires that somebody isn't going to inappropriately and erroneously start deleting patch files just because they are over 10 days old.
|
I agree. Talk to infra.
Quote: |
the bottom line is that this file was inappropriately and erroneously removed from a perfectly functional portage tree by some unnamed mystery developer who wants to remain anonymous because he/she wasn't paying attention to the trouble that could be caused by indiscriminately deleting files. even worse, whoever is responsible hasn't yet stepped up to accept responsibility for the problem, and with dismissal of the bug report as "invalid" [sic] the situation is being obfuscated so that users are having difficulty elucidating the nature of the problem.
i have recovered the file and made it available to anyone else who might need it. now that the file is available, i think that any further disucssion about who caused the problem is actually moot. the CVS document seems to speak for itself anyway.
Edit: specific information for 2.3.5-r1 ebuild
|
Great, thanks. I've made it available in my devspace, too, so now that URL is valid. _________________ Gentoo Developer: amd64, sparc, sound, toolchain, accessibility |
|
Back to top |
|
|
eradicator Retired Dev
Joined: 01 Apr 2003 Posts: 144 Location: Berkeley, CA
|
Posted: Mon Aug 22, 2005 7:59 pm Post subject: |
|
|
What part of my statement do you not get?! IT WAS NEVER THERE!!! Before 10 seconds ago, I never had that tarball, but since you dug it up, I added it to my devpsace to make that URL valid for you. Whoever updates teh patch tarball needs to update that URL to the valid location. That didn't happen. It never was at my devspace in the first place. vapier made it but didn't add it to a valid SRC_URI other than the mirrors. Talk to him if you care, but this conversation is getting old, so I'm out!
Quote: |
according to the standards listed in the Repository Markup, the patch file is supposed to remain persistent, just as the previous 10 patch files have remained persistent:
Quote: | # GENTOO_TOOLCHAIN_BASE_URI
# This sets the base URI for all gentoo-specific patch files. Note
# that this variable is only important for a brief period of time,
# before your source files get picked up by mirrors. However, it is
# still highly suggested that you keep files in this location
# available. |
and Quote: | GENTOO_TOOLCHAIN_BASE_URI="http://dev.gentoo.org/~eradicator/glibc"
get_glibc_src_uri() {
# This variable should be set to the devspace of whoever is currently
# maintaining GLIBC. Please dont set this to mirror, that would just
# make the files unavailable until they get mirrored.
local devspace_uri="http://dev.gentoo.org/~eradicator/glibc/"
|
|
Yes, and I agree with that policy. Hell, I WROTE that statement which is why I keep all the patch tarballs THAT I MAKE available in http://dev.gentoo.org/~eradicator/glibc/ I can't be held responsible for another developer not updating those variables when they bump the patch version.
Quote: |
- the issue isn't who made the update to the ebuild to use patchset 1.9 instead of 1.8 -- we know who did that.
|
http://www.gentoo.org/cgi-bin/viewcvs.cgi/sys-libs/glibc/glibc-2.3.5-r1.ebuild?r1=1.10&r2=1.11
Quote: |
- the issue isn't who's devspace the file is supposed to be located on -- we know that, too.
- the issue is that an important patch file that is supposed to remain on the devspace is Missing In Action and the bug report about it was resolved as invalid because this file is claimed never to have existed.
|
And it never did! Stop insinuating that I'm a liar. You got it from a mirror, not my devspace. Because you just provided it to me, however, I've added it to my devspace. If you want to discuss this further, go talk to vapier. I don't have time to waste on this issue further.
Quote: |
my intent in pursuing this is not to place blame on anyone. its only to gather enough interest from a responsible party to put a critical patch file back on the devspace where it belongs.
|
It was never ON my devspace. See previous statements.
Quote: |
i think we've pretty clearly identified that the file did exist, that it does exist today, and where it is supposed to reside on the Gentoo devspace. it would be very pleasing if someone who has the capability of depositing the file in its appropriate place would follow the guidelines regarding the maintenance of files, rather than just dismissing the bug as invalid and suggesting that everyone in the world resync and start their projects over.
|
See previous statements. I never had the file to begin with, how is it supposed to be in my devspace. The "guidelines" in the file you refer to are correct, but the developer making the patch didn't update the URL to the place he put the patch tarball.
Quote: |
this is an example of how Gentoo becomes unnecessarily b0rken. an approach that involved admitting little mistakes and correcting them would make Gentoo alot more user friendly than claiming that verified complaints are invalid. but that's just my personal take on the subject.
|
No, this is an example of how you could've gotten results a lot better by simply asking me to include a tarball on my devspace because it was deleted from the mirrors, but instead you get me angry at you because you call me a liar.
Quote: |
hopefully this file will find its way back to where it belongs, as i think that people who need it are more likely to find it there than on my personal webspace.
thanks for your help. |
_________________ Gentoo Developer: amd64, sparc, sound, toolchain, accessibility |
|
Back to top |
|
|
Bob P Advocate
Joined: 20 Oct 2004 Posts: 3355 Location: Jackass! Development Labs
|
Posted: Mon Aug 22, 2005 8:15 pm Post subject: |
|
|
i'm not calling anyone a liar, and i apologize if i've offended you. all that i am interested in doing is helping to solve a problem by providing a file that belongs in your devspace.
i understand that the situation can be frustrating if somebody is making changes and not passing files along to you. if the left hand doesn't know what the right hand is doing, then it becomes a difficult situation to resolve.
my only purpose in filing the bug report was to attempt to solve a problem by offering a file that was missing from the patch library. i even gave you a heads-up about the problem via e-mail when i opened the bug report so that you could aid in the solution, and posted the missing file where you could find it. i thought i was being a pretty good Boy Scout, all things considered.
in response, my bugzilla report was closed three times this morning, twice with the status of resolved/invalid and once with the status of resolved/needinfo, even though all of the necessary information was provided in exacting detail. looking at the bug report, its hard to understand why the problem was not being taken seriously. it was obvious that nobody was actually paying attention to the details and that the bug report was being summarily dismissed with a recommendation to resync -- until the documentation about the nature of the problem became overwhelming. from a user's perspective, an incredibly well-documented and confirmed problem was repeatedly being summarily dismissed as invalid. that was pretty frustrating.
again, i apologize if i've offended you. that wasn't my intent. i was just trying to alert you to the problem and to provide you with the necessary solution. now that someone's taken enough time to actually consider the problem in detail, i'm happy to see that the problem has been resolved.
thanks again for your help, and again my apologizes for having offended you. _________________ .
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks |
|
Back to top |
|
|
lostinspace2011 Apprentice
Joined: 09 Sep 2005 Posts: 230
|
Posted: Wed Jun 30, 2010 3:36 am Post subject: Emerge GlibC fails with 404 |
|
|
I hate to open old wounds, but since this morning I am not able to update glibc. I tried on two different systems and have the same issue on both. The glibc patch seems to be missing. I had a look and found this thread as well as the associated bug report. I have already updated my portage tree (emerge --sync) on both system, but the problem is still there.
Quote: | >>> Downloading 'http://dev.gentoo.org/~azarah/glibc/glibc-2.11.2-patches-2.tar.bz2'
--2010-06-30 11:30:59-- http://dev.gentoo.org/~azarah/glibc/glibc-2.11.2-patches-2.tar.bz2
Resolving dev.gentoo.org... 140.211.166.183
Connecting to dev.gentoo.org|140.211.166.183|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2010-06-30 11:31:00 ERROR 404: Not Found. |
Any pointers to what you did last time this happened ?
Thanks in advance. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|