On Fri, 22 Jan 2021 at 00:06, Kevin Fenzi <ke...@scrye.com> wrote: > On Thu, Jan 21, 2021 at 08:04:42PM +0000, Zbigniew Jędrzejewski-Szmek > wrote: > > On Thu, Jan 21, 2021 at 12:43:35PM +0100, Fabio Valentini wrote: > > > On Thu, Jan 21, 2021 at 12:39 PM Panu Matilainen <pmati...@redhat.com> > wrote: > > > > > > > > On 1/21/21 1:27 PM, Fabio Valentini wrote: > > > > > On Thu, Jan 21, 2021 at 12:22 PM Panu Matilainen < > pmati...@redhat.com> wrote: > > > > >> > > > > >> On 1/21/21 9:56 AM, 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? > > > > >>> > > > > >> > > > > >> Certainly not. > > > > >> > > > > >>> 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. > > > > >> > > > > >> Based on a quick random sampling, this would appear to be a very > recent > > > > >> thing, the only affected packages I could find (which doesn't mean > > > > >> others couldn't exist) were built in the last few days, such as > the > > > > >> above and these: > > > > >> > > > > >> > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/n/net-snmp-debugsource-5.9-4.fc34.aarch64.rpm > > > > >> > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/debug/tree/Packages/n/NetworkManager-debugsource-1.30.0-0.2.fc34.aarch64.rpm > > > > >> > > > > >> ...which were all built on Jan 18th. The only recent change to > rpm is > > > > >> the DWARF-5 support but based on changelogs that seems to have > landed > > > > >> the day after, so I dunno. > > > > > > (snip) > > > > > > > > Is it possible that this was triggered by switching on signed RPM > contents? > > > > > If I understand the implementation correctly, it messes with the > RPM headers. > > > > > > > > Oh, I wasn't aware the file signing proposal had been approved, much > > > > less enabled. I thought I raised "some objections" on the enablement > of > > > > the feature from rpm maintainer perspective. > > > > > > It has *not* been approved (yet). Which is why I grumbled about > > > enabling the signing in production infra during yesterday's FESCo > > > meeting. > > > > Oh, I didn't fully understand your comment at the time. I automatically > assumed > > that "enabled in production" only means that the *code* is there, i.e. > that > > the version of rpm has been updated in preparation. Actually enabling > this > > while the proposal is being discussed is definitely NOT OK. It makes > > mockery of the whole Change process and deliberation on fedora-devel and > > the fesco ticket. > > I tried to explain this at the meeting, but I guess I was too terse. > > First, let me say that I (and I am pretty sure everyone involved) was > unaware of the rpm bug. I hope Patrick will chime in, by my > understanding is that rpm specs said they changed this to 64MB, but the > commit involved only changed it to 64k. :( > > This is unfortunate and I am sorry it happened. > > We don't currently have a signing setup in staging that allows testing > this, and wanting to make sure everything worked we put it in place. > I did not know that it would cause this issue or I would not have > allowed it to be deployed. On the other hand, we now know about this > issue instead of learning about it after the mass rebuild is over. >
+1 I think we should actually be celebrating the fact that we have enabled this early and found a problem before the mass rebuild. That's the whole point behind continuous integration and getting early feedback. > > We can disable it before the mass rebuild if desired easily enough. > > Note that in the past we have, multiple times, changed the rpm format in > ways that are not compatible with the current rhel versions of rpm. We > have in the past always gotten rpm maintainers to update rhel (at least > the most recent ones) to accomodate this. > > I don't think this is a "mockery" of the change process, I think it's a > case where early testing caught issues before the item landed. > > Anyhow, I accept full blame, please send your pitchforks and torches my > way... > > Now back to trying to get armv7 builders stable before mass rebuild. > > kevin > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
