Hey folks! So, the branch event for Fedora 29 recently happened. That
means we now have a Fedora 29 branch and Rawhide is now what will
eventually become F30.
If you were on Rawhide but you want to follow F29 development, and not
stay on Rawhide, the instructions for switching can be found here:
"Q: How do I get out of Rawhide again? I want to switch to the Branched
release or a stable release.
A: Remove the fedora-repos-rawhide package and/or disable the 'rawhide'
repository (su -c 'dnf config-manager --set-disabled rawhide'), enable
the 'fedora' and optionally 'updates' and 'updates-testing'
repositories (su -c 'dnf config-manager --set-enabled
fedora(,updates,updates-testing)') and perhaps run su -c 'dnf --
releasever=(version) distro-sync'. The farther the branch to which you
want to switch is behind Rawhide, the more trouble you might have with
A possible problem is that you might miss the branching point, and your
system has already a bunch of post-branch Rawhide packages installed.
In that case, the dnf distro-sync will help you to get everything back
on the right track."
Also, quick note on state for anyone using either branch: if you're on
Rawhide, you will likely have issues with package signing. These should
be resolved when we get a new Rawhide compose completed and synced out
to mirrors, unfortunately the 20180818.n.0 compose failed; releng is
looking into that.
F29 should be mostly working OK at this point. If you install it from
scratch, or reinstall the bootloader for some reason, you may run into
https://bugzilla.redhat.com/show_bug.cgi?id=1618928 , where grub prints
a bunch of stuff on boot (not sure if this actually indicates there was
some kind of error, or just someone left some kind of verbose debugging
switch turned on by mistake): if you just page through all the output
(by pressing space) then boot will proceed. That grub build has now
been tagged into Rawhide too, so this may also affect fresh Rawhide
installs when we get a new compose, if it doesn't get fixed first.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
Which is the proper component for this problem?
A user departs from the OS in a way that requires the OS to exit all of the apps. Usually that's by shutdown or reboot, but it might be logoff or some other method. Each app may have to clean itself up and so each app might need time. This could take so long that the user gets frustrated or the computer could freeze because of an app's misbehavior that a forced quit could have prevented, so a time limit may be forced. But if the time is thus too short, data or apps may get damaged. Powering off could damage even more data and apps. People involved with Firefox said that insufficiency of time is a problem. I posted a feature request for Fedora 28 to give the user control over the time allocated to cleanup and assigned this to a component. In answer, I was told that the component was wrong but that which component it is happens to be unknown, so far.
If you can select a better component, please do: https://bugzilla.redhat.com/show_bug.cgi?id=1611040
armadillo 9.100.5 was released this week. The previous stable release was
8.600.5. So we a major version bump from 8 to 9.
According to both the release notes and an email exchange with the upstream
maintainer "There are no API breakages, but there are subtle behavioural
differences, mainly with the solve() and inv_sympd() functions."
In essence any well-behaved program should work with no changes.
I intend to update the package in rawhide and branched F29.
# dnf --disablerepo=\* --enablerepo=rawhide repoquery --whatrequires armadillo
reveals that the only packages that require armadillo are:
FWIW this is the same for all the supported fedora versions.
I will take care of the rebuilds.
I will also contact the owners (point of contact) of those packages to update
armadillo in F28, F27 and epel.