On Fri, 22 Jan 2021 at 00:06, Kevin Fenzi <kevin@xxxxxxxxx> 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 <pmatilai@xxxxxxxxxx> wrote:
> > >
> > > On 1/21/21 1:27 PM, Fabio Valentini wrote:
> > > > On Thu, Jan 21, 2021 at 12:22 PM Panu Matilainen <pmatilai@xxxxxxxxxx> 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@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
_______________________________________________ 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
