On Fri, Jan 22, 2021 at 02:41:52PM +0100, Clement Verna wrote: > 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. Sorry, but I disagree with the evaluation that this is OK. It seems fairly obvious to me that nobody knew about the bug, and it wouldn't have been enabled if the bug was discovered beforehand. But even with the absence of known bugs, for complicated changes like this, there is always a risk of bugs and the potential to disrupt other people's work. It is better to assume that there will be bugs. The official package build system is not CI for unapproved projects. Yes, at some point we need to flip the switch and enable the new thing, but this should be done *after* being agreed on and announced, not before, and not silently. > +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. Yes, this is one good outcome. Zbyszek _______________________________________________ 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
