Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
emerge glibc dies with 404 errors. [SOLVED]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 12:08 am    Post subject: emerge glibc dies with 404 errors. [SOLVED] Reply with quote

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
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 12:21 am    Post subject: Reply with quote

http://bugs.gentoo.org/show_bug.cgi?id=103296
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 12:30 am    Post subject: Reply with quote

evidently, this has been a problem before, and its a problem again:

http://forums.gentoo.org/viewtopic-t-364874.html
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
eradicator
Retired Dev
Retired Dev


Joined: 01 Apr 2003
Posts: 144
Location: Berkeley, CA

PostPosted: Mon Aug 22, 2005 3:56 am    Post subject: Reply with quote

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
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 4:35 am    Post subject: Reply with quote

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. :wink:

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
View user's profile Send private message
eradicator
Retired Dev
Retired Dev


Joined: 01 Apr 2003
Posts: 144
Location: Berkeley, CA

PostPosted: Mon Aug 22, 2005 7:01 am    Post subject: Reply with quote

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
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 9:11 am    Post subject: Reply with quote

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. :idea:


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.

:arrow: when i saw portage attempting to download the file from your devspace, i assumed that you were the responsible developer.

:arrow: 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.

:arrow: 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. :oops:
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
eradicator
Retired Dev
Retired Dev


Joined: 01 Apr 2003
Posts: 144
Location: Berkeley, CA

PostPosted: Mon Aug 22, 2005 9:52 am    Post subject: Reply with quote

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. :idea:


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.

:arrow: 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.

:arrow: 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.

:arrow: 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. :oops:


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
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 10:49 am    Post subject: Reply with quote

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
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Mon Aug 22, 2005 11:05 am    Post subject: Reply with quote

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
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 11:35 am    Post subject: Reply with quote

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. :wink:

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
View user's profile Send private message
nxsty
Veteran
Veteran


Joined: 23 Jun 2004
Posts: 1556
Location: .se

PostPosted: Mon Aug 22, 2005 11:38 am    Post subject: Reply with quote

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
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 5:54 pm    Post subject: Reply with quote

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
View user's profile Send private message
eradicator
Retired Dev
Retired Dev


Joined: 01 Apr 2003
Posts: 144
Location: Berkeley, CA

PostPosted: Mon Aug 22, 2005 7:44 pm    Post subject: Reply with quote

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
View user's profile Send private message
eradicator
Retired Dev
Retired Dev


Joined: 01 Apr 2003
Posts: 144
Location: Berkeley, CA

PostPosted: Mon Aug 22, 2005 7:59 pm    Post subject: Reply with quote

Bob P wrote:

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.


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
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Aug 22, 2005 8:15 pm    Post subject: Reply with quote

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
View user's profile Send private message
lostinspace2011
Apprentice
Apprentice


Joined: 09 Sep 2005
Posts: 188

PostPosted: Wed Jun 30, 2010 3:36 am    Post subject: Emerge GlibC fails with 404 Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
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