On Monday, January 25, 2021 7:50:08 PM CET Dan Čermák wrote: > Pavel Raiskup <praiskup@xxxxxxxxxx> writes: > > > On Monday, January 25, 2021 8:18:33 AM CET Panu Matilainen wrote: > >> On 1/22/21 8:19 PM, Adam Williamson wrote: > >> > On Fri, 2021-01-22 at 09:57 +0200, Panu Matilainen wrote: > >> >> On 1/21/21 8:37 PM, Adam Williamson wrote: > >> >>> On Thu, 2021-01-21 at 10:53 +0100, Kevin Kofler via devel wrote: > >> >>>> Florian Weimer wrote: > >> >>>>> With rpm-4.15.1-3.fc32.1.x86_64, I get this error: > >> >>>>> > >> >>>>> $ rpm -qip > >> >>>>> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm > >> >>>>> error: /var/tmp/rpm-tmp.6iU66n: signature hdr data: BAD, no. of > >> >>>>> bytes(88084) out of range error: > >> >>>>> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/m/ModemManager-debugsource-1.14.10-1.fc34.aarch64.rpm: > >> >>>>> not an rpm package (or package manifest) > >> >>>>> > >> >>>>> Is this expected? > >> >>>>> > >> >>>>> It seems that rpm-4.16.1.2-1.fc33.x86_64 can parse the RPM just fine. > >> >>>>> But rpm-4.14.3-4.el8.x86_64 does not like it, either. > >> >>>> > >> >>>> Considering that direct upgrades from F32 to F34 (n to n+2) are supposed to > >> >>>> be supported, this sounds like a blocker to me. > >> >>> > >> >>> openQA N+2 upgrade tests have indeed been running into this for a few > >> >>> days: > >> >>> > >> >>> https://openqa.fedoraproject.org/tests/759545#step/upgrade_run/20 > >> >>> > >> >>> I had been meaning to dig into it a bit more before filing a bug. > >> >>> > >> >> > >> >> Folks, when rpm starts spitting errors like that, don't think, just file > >> >> a bug. It's very, very very very unlikely that it's "ok" in any > >> >> imaginable meaning. > >> > > >> > It's not that I thought it was "OK", it's just that these days I tend > >> > to like filing a bug report with detailed cause analysis and stuff all > >> > wrapped up :) > >> > >> And that is certainly appreciated! > >> > >> But if there's even a wiff of a package generational bug, it's better to > >> act first and think later because those things are not entirely unlike a > >> virus outbreak, those buggers spread fast on every sneeze and stopping > >> it early is the key to damage control :D > > > > I'm curious how are we going to fix this? Mock started to complain now that it > > is not even able to install rawhide bootstrap chroot on F32: > > error: /var/lib/mock/fedora-rawhide-x86_64-bootstrap-1611584804.803151/root/var/cache/dnf/fedora-2d95c80a1fa0a67d/packages/python3-libs-3.9.1-3.fc34.x86_64.rpm: signature hdr data: BAD, no. of bytes(384156) out of range > > > > Does it imply rebuild of all affected packages, including Python3.9? > > No, I've been seeing this issue for the past week and thanks to Fabio > I've been able to solve it by running > mock -r /etc/mock/fedora-rawhide-x86_64.cfg --clean --scrub=all Cleaning caches would make sense if there was newer variant of that package in the repository. But in this case it wasn't. Rebuild was really needed to fix the bootstrap installation. Fortunately, according to Miro Hrončok, this was (Miro already rebuilt the package, and it is going to be added in the next compose) the only "broken" package affecting bootstrap installation so nothing else needs an immediate rebuild now. As I was informed, there is upcoming mass rebuild, so any residual packages would be fixed automatically very soon (in case anyone wants to have mock bootstrap disabled for any reason). What is IMO guaranteed to work-around this issue is to use mock --use-bootstrap-image feature. Pavel _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
