Bug 135715 - media-fonts/{font-misc-misc,encodings,font-misc-misc}-1.0.0 - upstream changed tarballs
|
Bug#:
135715
|
Product: Gentoo Linux
|
Version: 1.0
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: critical
|
Priority: P1
|
|
Resolution: FIXED
|
Assigned To: x11@gentoo.org
|
Reported By: b.ohnsorg@freenet.de
|
|
Component: Ebuilds
|
|
|
URL:
https://bugs.freedesktop.org/show_bug.cgi?id=7124
|
|
Summary: media-fonts/{font-misc-misc,encodings,font-misc-misc}-1.0.0 - upstream changed tarballs
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-06-05 22:57 0000
|
When emerging media-font/encodings emerge states, that file already exists and
no download necessary and complains in the next line about "Cannot download
media-font/encodings-1.0.0.tar.bz2". I've looked it up and can find it under
/usr/portage/distfiles/, has proper rights and owner/group and when I remove
it,
the same thing happens again (download occurs first, finishes correctly and
then
emerge complains again "Cannot download...")
I also had a look at equery depends media-font/encodings and got not a single
referer, description's not the best, too. So what is this package at least for?
This happens, when emerging xorg-x11 (modular)
Portage : 2.1_rc4-r2
glibc : 2.3.6-r3
gcc : 3.3.6
kernel : 2.6.16-r3
gentoo-base: 1.6.14
*** Bug 135716 has been marked as a duplicate of this bug. ***
*** Bug 135717 has been marked as a duplicate of this bug. ***
Sigh, they did it again... upstream--
:=(
*** Bug 135695 has been marked as a duplicate of this bug. ***
other packages this applies too media-fonts/font-misc-misc and font-cursor-misc
I'd say this is a serious problem, when I look at the amount of duplicate bugs
and a certain frequency, these bugs occur. Maybe there should be a big fat
warning
or a better testing scenario. It doesn't seem to common knowledge, that for
example ftp works in text- and binary mode. One adjusts linefeeds and
encodings,
to a certain extent, and one transfers bits, not characters.
I can work around it when using --resume and --skip-first, but sometimes it's
not possible and there'll be no consistency at all. Won't do the portage-dev
scripts this job, create all the necessary checksums by downloading the tarball
once? Maybe this should be added somewhere, before committing an ebuild, test
it
automatically, if checksums match, --fetch followed by a md5sum-call compared
to the portage-functions. Help necessary? I got some dependency-checker too, to
control revdep-rebuild (find executables and libraries, compare them to
installed
ebuilds or list ebuilds and find necessary files, incl. some basic ldd-check)
Fixed, thanks!
If you have an issue with the digest process, Onkobu, please file a separate
bug.
What was the resolution to fix this? Were the digests updated somehow? Were
the files that we download replaced?
*** Bug 135812 has been marked as a duplicate of this bug. ***
*** Bug 135878 has been marked as a duplicate of this bug. ***
Me 'ave no problem wit digest process. But I'd say it's a common problem and
happens on and on again. So there should be a bit more improvement than fixing
digests. Maybe all ebuilds must pass a fetch-only/checksum testcase, before
becoming available to the masses or getting a '+' (stable).
If it is a problem of the upload process (which may happen automatically) or if
it's caused by the project owners (who change tarballs after releasing) this
should be discussed (to keep problems away from gentoo's responsibility).
Only an idea, nothing serious...
