Please use side tags for backwards-incompatible bumps of major
packages, not buildroot overrides
by Adam Williamson
I found quite a big mess today, caused by an attempt to bump perl to
5.34.1 in Fedora 36:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-cea638ebd4
Because some packages depend on the exact perl interpreter version, the
maintainer made a buildroot override for perl:
https://bodhi.fedoraproject.org/overrides/perl-5.34.1-486.fc36
and rebuilt them. Okay.
The problem with this is, we have lots of perl modules. People build
them all the time. And buildroot overrides apply to *everything*.
So, while the buildroot override has been valid, multiple *other* perl
modules have been unwittingly built against it:
perl-Scalar-List-Utils:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1936732
perl-Parallel-Pipes:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1937527
perl-PPIx-Regexp:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1937522
perl-Crypt-SSLeay:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1937521
perl-Crypt-OpenSSL-PKCS10:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1937471
...and those are just the ones I found so far. Because they were built
against 5.34.1, all of those builds require
"perl(:MODULE_COMPAT_5.34.1)" , which means they require perl-5.34.1
from updates-testing. They cannot be installed with perl-5.34.0 from
stable. But the maintainers likely had no idea about this - buildroot
overrides are not at all discoverable, there is zero indication your
package is building against one when you build it - and have created
separate updates for those packages:
https://bodhi.fedoraproject.org/updates/FEDORA-2022-cb1170abf2
https://bodhi.fedoraproject.org/updates/FEDORA-2022-d83d0ba901
https://bodhi.fedoraproject.org/updates/FEDORA-2022-fac98e635f
https://bodhi.fedoraproject.org/updates/FEDORA-2022-c2203f1964
https://bodhi.fedoraproject.org/updates/FEDORA-2022-0990e3309e
Users testing those updates will likely not notice the problem, because
they'll have *all* of updates-testing enabled when they update, and
perl-5.34.1 will be pulled in. But if any of those updates is pushed
stable before the perl update is pushed stable, it will fail to install
for anyone who does not have updates-testing enabled.
This is quite a mess. I'm going to try and clean it up, but it'll be a
bit ugly (there are a couple of ways I can do it, but both will involve
doing bumps-and-rebuilds of the affected packages with no changes).
I've been worried about this sort of thing happening for a while due to
the undesirable properties of buildroot overrides. This is the biggest
real-world case I've seen, but it could certainly happen again. It
might even have happened without anyone noticing exactly what was going
on (just mysterious dependency issues that magically went away after a
bit).
So: now we have convenient self-service side tags, *please use them*.
Especially for something as major as a bump of perl that changes
dependencies of packages built against it like this. Side tags avoid
this mess entirely. Using the mechanism to produce an update from a
side tag also makes it easier to make sure all the right packages are
in the update and they don't get incorrectly submitted as separate
updates.
Thanks folks!
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
2 years
VERY late notification emails
by Richard Shaw
I almost wrote this a week ago but decided not to as it's been recently
discussed but this is really annoying. 6 days later is more than useless.
Previously it was blamed, at least partially, on the mass rebuild, but
clearly that should no longer be an issue by now?
I know I can turn them off, but I actually LIKE the messages if they were
delivered promptly.
Is there really nothing we can do about this?
Thanks,
Richard
---------- Forwarded message ---------
From: <notifications(a)fedoraproject.org>
Date: Sun, Feb 27, 2022 at 6:09 PM
Subject: hobbes1069's mingw-fltk-1.3.8-1.fc36 completed
To: <hobbes1069(a)gmail.com>
Notification time stamped 2022-02-21 13:42:00 UTC
hobbes1069's mingw-fltk-1.3.8-1.fc36 completed
http://koji.fedoraproject.org/koji/buildinfo?buildID=1921324
2 years
Do we have any policy for disabling inactive users
by Mattia Verga
Just being paranoid here: do we have any policy / automatism for
disabling "power" users (in packager group or like) which have been
inactive for long time?
I'm no security expert, but an inactive user account may be hacked
without noticing and if such account have powers like being in the
packager group may inject bad things in the distribution.
I also imagine the case where a user no more use their email address and
that become available to someone else. The new user may easily reset the
password and gain access to the old Fedora account (provided that the
old user didn't use 2fa).
Does it make sense to start thinking to prune inactive packagers without
waiting someone to start the "unresponsive maintainer policy"? Maybe a
script could check user activities in src.fedoraproject.org and send a
warning email if no activity is made in one year?
Mattia
2 years
Donate 1 minute of your time to test upgrades from F35 to F36
by Miroslav Suchý
Do you want to make Fedora 36 better? Please spend 1 minute of your time and try to run:
# Run this only if you use default Fedora modules
# next time you run any DNF command default modules will be enabled again
sudo dnf module reset '*'
dnf --releasever=36 --setopt=module_platform_id=platform:f36 \
--enablerepo=updates-testing \
$(rpm -q fedora-repos-modular >/dev/null && echo --enablerepo=updates-testing-modular) \
--assumeno distro-sync
This command does not replace `dnf system-upgrade`, but it will reveal potential problems.
You may also run `dnf upgrade` before running this command.
The `--assumeno` will just test the transaction, but does not make the actual upgrade.
In case you hit dependency issues, please report it against the appropriate package.
Or against fedora-obsolete-packages if that package should be removed in Fedora 36. Please check existing reports against
fedora-obsolete-packages first:
https://red.ht/2kuBDPu
and also there is already bunch of "Fails to install" (F36FailsToInstall) reports:
https://bugzilla.redhat.com/buglist.cgi?bug_id=1992487&bug_id_type=anddep...
Thank you
Miroslav
2 years
RFI/RFC: Fedora Linux graphical recovery environment
by Neal Gompa
Hey all,
Earlier this week, the Fedora Workstation WG discussed a ticket
brought to us asking for a GUI-based rescue/recovery environment[1].
While we all agreed in principle that such a thing would be a very
good thing to have, we don't really know how to achieve such a thing.
Additionally, we're not really sure what the scope of things should be
provided in said recovery environment and what kind of things people
would expect to be able to fix in there.
So I come to y'all to ask about this and give us some feedback on the
idea, how to do it, and what kinds of things you expect people to need
a recovery environment for.
[1]: https://pagure.io/fedora-workstation/issue/288
--
真実はいつも一つ！/ Always, there's only one truth!
2 years
Re: Dropping wine from ARM
by Neal Gompa
On Wed, Mar 30, 2022 at 10:44 AM NightStrike <nightstrike(a)gmail.com> wrote:
>
>
>
> On Wed, Mar 30, 2022, 08:34 Michael Cronenworth <mike(a)cchtml.com> wrote:
>>
>> Hi,
>>
>> Fedora currently ships Wine 7.3 released February 25th, 2022.
>>
>> Wine 7.4, released March 11th, started to require a 'llvm-mingw' compiler for ARM64
>> builds. Fedora ships the 'mingw-w64' gcc-based MinGW environment and does not ship
>> the 'llvm' MinGW environment. Unlike the WineMono package, which bundles a
>> 'llvm-mingw' compiler (that is removed and mingw-w64 is used), the Wine package does
>> not bundle one and does not allow for an alternative compiler.
>>
>> I will need to drop ARM from Wine in order to continue shipping new updates. I do
>> not have the bandwidth to package the llvm-mingw compiler toolchain, nor do I have
>> the time right now to discuss this with upstream.
>
>
> That is an unfortunate decision on the part of wine. Gcc is a very robust compiler.
>
I'm not surprised, honestly. I suspect the primary motivation for
Clang is that Microsoft contributed support for PDB to LLVM, but
nobody brought it into GCC as far as I know. That said, we don't have
any debug infrastructure for PDB, only DWARF (which is what GCC uses
in Fedora).
--
真実はいつも一つ！/ Always, there's only one truth!
2 years
Koji down?
by Ron Olson
I submitted some builds yesterday and didn’t get any emails, and at least as of 6:18 CDT every link I click on the main webpage replies with “server is offline”.
2 years
