always update the bootloader during major upgrades
by Chris Murphy
Hi,
This is not a formal proposal, this is for discussion and identifying
liabilities. This email has an x86 GRUB bias only because that's the
bootloader regime I'm most familiar with. I think it should apply to
other archs as well, i.e. their bootloaders shouldn't be permitted to
become stale.
Short version: Fedora should take responsibility for the bootloader
being up to date, by updating it during major version upgrades. This
is already the case on UEFI with conventional installations. I'd like
to make sure it always happens on major version upgrades for BIOS
installations. What's the problem? This would step on any custom
bootloader configuration a user has for multiboot. There is no
reasonable mechanism on BIOS systems to determine if the bootloader is
a Fedora bootloader, and somehow only update a Fedora bootloader and
not touch any other bootloader.
Fedora should be responsible for keeping the bootloader it installs in
~80% of the use cases up-to-date; and ignore the fallout from the ~20%
who have a custom setup that would be stepped on by a forced
bootloader update. The former is a feature and security risk, by
allowing the bootloader to go stale over time. The latter is an
inconvenience.
Longer version:
terms:
bootloader - this is the pre-boot bootloader binaries; on BIOS it's
embedded in the MBR, and the MBR gap or BIOS Boot partition, and
modules found in /boot/grub2 on Fedora. On UEFI, this is the
/EFI/fedora/shimx64.efi and /EFI/fedora/grubx64.efi which in the
typical installation are built and signed by the Fedora build system.
Other bootloaders have different names but generally follow a similar
convention, the point here is to distinguish between the "bootloader"
which runs in the pre-boot environment, and the installed package
containing user space tools that are used to install (or contain) the
bootloader.
Fedora bootloader - this is a bootloader that is derived from Fedora
packages and effort; as contrasted to merely upstream GRUB, or
Ubuntu's GRUB, etc. as these derivatives can actually be substantially
different from each other.
Discussion:
Both gnome-software (pk-offline-update), and dnf system-upgrade, on
BIOS firmware x86 computers, do not update the bootloader. That is, we
do not run 'grub2-install' either before starting an upgrade, or as a
post install operation following an upgrade. Therefore the bootloader
will become stale if the user does not manually run 'grub2-install'
periodically.
On conventional Fedora installations on UEFI computers, the bootloader
is included in the shim and grub2 packages as a file, and is therefore
updated. This happens sporadically within a Fedora release, not only
at major upgrade time. This updating of the bootloader files doesn't
happen on Silverblue on UEFI, so it ends up being subject to the same
problem under discussion.
In the most recent release, Fedora 30, we saw quite a lot of people
run into a problem we knew about before release, directly related to
the bootloader becoming stale. And it only affected BIOS systems (and
Silverblue on both firmware types).
https://fedoraproject.org/wiki/Common_F30_bugs#blscfg-fail
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=1652806
In the bug, you can find some dups as well but also quite a bit of
user aggravation. I'd like to avoid this going forward.
Windows and macOS never involved users in this stuff. They always
asserted complete and total domain over the bootloader, there wasn't
even an option to avoid updating it. And I think Fedora needs to do
the same. Just update it. That benefits most users. It's the
responsible thing to do. And those who need custom setups, can still
do that. It would only get stepped on at major upgrade time. And it's
decently likely we can warn them in advance.
There are some gotchas I'm already thinking of: MBR gap is too small,
there are multiple drives and it's ambiguous which one should get the
bootloader, and so on. I think it's sane to have a test for reasonable
certainty we can and should update the bootloader, and warn and not
update it in the cases that fail that test.
Thoughts?
--
Chris Murphy
4 years, 9 months
[HEADS-UP] po4a-0.56 built on rawhide
by Sérgio Basto
Hi,
I just submit po4a-0.56 to rawhide, po4a don't have any so-name bump
but is wildly used , so some attention is advised .
Thanks
--
Sérgio M. B.
4 years, 9 months
Fedora and Free Science meetup at Flock
by Ankur Sinha
Hello!
Science, like Free/Open Source software should be open for all to use,
modify, explore, learn, and share. This is especially important to
ensure that the results from scientific work are not merely limited to
"academia", but are easily understandable by people in other walks of
life also. Further, science should not be limited to "academia".
Everyone should have access to the data, the tools, the knowledge.
With this in mind, we started the NeuroFedora SIG that focusses on
Neuroscience (mostly because my field is neuroscience):
https://neuro.fedoraproject.org
However, there's a lot of work that can be done to enable all scientific
fields, not just neuroscience. So, we're hoping to meet at Flock to
discuss how we can better use Fedora's resources to enable Free Science.
We've applied for a hackathon at the minute. If we're unable to get a
slot, we'll meet informally over beers ;)
https://pagure.io/flock/issue/220
The session is open to everyone, of course, and we'd love for more
people to join in. There's a lot of science to be learned, and there's a
lot of FOSS to be learned too, so we need people from both sides!
https://pagure.io/neuro-sig/NeuroFedora/issue/242
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
4 years, 9 months
Automating R package dependencies
by Elliott Sales de Andrade
Hi R-interested packagers and others,
Recently, I've been looking at how RPM can automatically determine
Provides and Requires [1]. I have since implemented this for R using
an R script [2] and some file attributes [3]. Following other
languages' Provides, I have namespaced them as R(packageName). It then
adds corresponding Requires, Suggests, and Enhances.
Additionally, R package versions commonly contain dashes. In order to
work in RPM, these are replaced with dots. For the automated
Provides/Requires, I have used the *real* versions instead.
So now the question is how to apply this. I expect there are social
concerns, i.e., discussing with the R maintainer, making a
Self-contained Change, etc. But for this email, I am mostly concerned
with the technical aspects:
1. Is R-devel the right place to put the script and RPM attribute file
(all R packages would normally depend on this)?
2. Does this namespacing make sense?
3. Are dashes in *namespaced* versions going to be a problem?
4. Python had a flag to enable the automatic generator; do we need
this for R, and how was it implemented?
5. I expect this would need a rebuild of all packages to get the
dependencies right (because the regular rebuild is unordered); would
this need a side tag? Or would leaving it for the normal mass rebuild
just be fine?
6. R only has two levels of dependencies (hard-require or suggested,
but not installed by default). Thus both build- and runtime-optional
packages are in Suggests; do we care about the extra Suggests?
[1] https://rpm.org/user_doc/dependency_generators.html
[2] https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R-deps.R
[3] https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R.attr
--
Elliott
4 years, 9 months
[Python 3 migration] Heads up: Retiring the Obnam stack and
gnumed-server
by Michel Alexandre Salim
Hi all,
With Python 2 slated to be removed, I'm going to retire these packages
where upstream has either stopped development (Obnam's dependencies) or
is moving too slow to get a stable Python 3-based release out
(gnumed-server). Also, I've been helping out with gnumed (the client)
but never officially maintained it, and that package is already retired
in Rawhide due to being orphaned - so there's no reason to keep the
server around.
List of packages as follows, I'll hold off until Friday before retiring
them if someone wants to take over these packages and get them built. If
you take over gnumed-server you should take over gnumed and unretire it too.
gnumed:
gnumed-server
Obnam stack:
- cmdtest
- genbackupdata
- python-cliapp
- python-coverage-test-runner
- python-larch
- python-tracing
- python-ttystatus
- summain
Thanks,
--
Michel Alexandre Salim
profile: https://keybase.io/michel_slm
GPG key: 96A7 A6ED FB4D 2113 4056 3257 CAF9 AD10 ACB1 BEF2
4 years, 9 months
CMake Error: file INSTALL cannot find
by Martin Gansser
Hi,
when compiling olive [1] on F30, i get this error message:
Install the project...
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: ""
-- Installing: /home/martin/rpmbuild/BUILDROOT/olive-0.1.0-0.4.20190703git85b5bbd.fc30.x86_64/usr/bin/olive-editor
CMake Error at app/cmake_install.cmake:57 (file):
file INSTALL cannot find
"/home/martin/rpmbuild/BUILD/olive-85b5bbd5d6fb97ef215efd118b3fc156ebfba9bd/app/effects/internal/cornerpin.frag".
Call Stack (most recent call first):
cmake_install.cmake:42 (include)
[1] https://martinkg.fedorapeople.org/ErrorReports/olive/olive.spec
Regards
Martin
4 years, 9 months
[SO-NAME BUMP] jsoncpp-1.9.0
by Björn 'besser82' Esser
Hello,
jsoncpp-1.9.0 has been released recently, and I'm planning to update the
package during today, which includes a so-name bump.
I'll take care of rebuilding all its consumers, which are:
cmake
libjson-rpc-cpp
minetest
orthanc
paraview
passenger
qpid-proton
vfrnav
vrpn
vtk
Cheers
Björn
4 years, 9 months
Fedora 31 System-Wide Change proposal: IBus 1.5.21
by Ben Cotton
https://fedoraproject.org/wiki/Changes/IBus_1.5.21
== Summary ==
IBus 1.5.21 will extend the current compose typing.
# IBus will extend the compose key sequences less than 255 characters.
# IBus will extend the compose outputs more equal than one characters.
== Owner ==
* Name: [[User:Fujiwara| Takao Fujiwara]]
* Email: fujiwara [at] redhat [dot] com
== Detailed Description ==
The current IBus accepts the compose key sequences less than 7
characters due to the internal fixed buffer size, E.g. Multi_key-O-R
are three characters and the sequence can output "®" but
Multi_key-Multi_key-o-i-i-i-n-t are eight characters and the sequence
is not enabled in IBus. This release will extend this limitation to
255 characters.
The current IBus outputs one compose character only and size is
limited in 16bits. E.g. "®" is one character and it can be output and
"🗼" is one character but the size is extended the upper limit of
16bits and the output is not enabled in IBus. This release will delete
the limitation of the character lengths and the size will be extended
to 32bits.
== Benefit to Fedora ==
The users won't have to mind those compose limitations above and X11
compose does not have the limitations.
== Scope ==
* Proposal owners:
* Other developers: N/A
* Release engineering: [https://pagure.io/releng/issue/8503 #8503]
* Policies and guidelines: N/A
* Trademark approval: N/A (not needed for this Change)
== How To Test ==
# Create `$HOME/.config/ibus/Compose` with the following context [1]
# Restart ibus-daemon
# Launch gedit and type Multi_key-t-o-w-e-r
"🗼" is output.
[1]: <pre>
<Multi_key> <t> <o> <w> <e> <r> : "🗼"
</pre>
== User Experience ==
Users can reuse the user compose file of X11 to IBus.
The X11 system compose file has been loaded by the desktop locale
since the previous IBus version.
== Dependencies ==
This change effects all IBus engines but rebuilds are not needed.
== Contingency Plan ==
* Contingency mechanism: Drop the feature in Fedora 31 and postpone it
to Fedora 32
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
TBD
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 9 months
Fedora 31 System-Wide Change proposal: Langpacks-core for i18n functionality
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Langpacks-core
== Summary ==
Add `langpacks-core-*` subpackages to `langpacks` for easier
installation of minimal core i18n support for a language
(locale, default font, and any default input-method if needed).
== Owner ==
* Name: [[User:Petersen|Jens Petersen]]
* Email: petersen(a)redhat.com
* Name: [[User:pnemade|Parag Nemade]]
* Email: pnemade(a)redhat.com
* Name: [[User:mfabian|Mike Fabian]]
* Email: mfabian(a)redhat.com
== Detailed Description ==
In Fedora 30 we replaced the remaining Yum language-support groups in
Comps by extending the `langpacks` meta packages to handle the
installation of fonts (and input-methods) required for a language, in
addition to locale and translation package weak dependencies.
However this all or nothing approach can be too heavy for some use
cases, since the old language-support groups did not pull in
translation langpacks.
With this Change we want to refine the approach to allow finer-grained
installation of language support.
So users who only want basic support installed for a language (without
translation langpacks and additional fonts for example)
can install `langpacks-core-XY` to get just the default font,
locale(s) and a weak dependency for any default input method.
Note: in this proposal `XY` stands just for the ISO language code (eg
`es` for Spanish).
Users who want general default Fedora international support should
continue to install `@fonts`, `@input-methods`, and
`glibc-all-langpacks` (as they are already in Fedora Workstation, etc).
Later we may consider whether to separate the input methods into
separate meta langpacks subpackages.
== Benefit to Fedora ==
This allows more flexibility for users who want to do custom
installations/Spins, or starting from minimal images/installs.
They will be able to add basic i18n support for one or more specific
language in a predictable standard way without pulling in
additional langpacks for translations and extra fonts which may not be
required for each added languages.
Users wanting full support for a language can continue to install the
`langpacks-XY` package for their language.
== Scope ==
* Proposal owners:
** Add `langpacks-core-*` subpackages to langpacks for core i18n functionality:
*** default font
*** glibc locale
*** weak dependency on ibus IME if needed
** Other langpacks weak deps and additional fonts will remain in `langpacks-XY`.
** `langpacks-XY` will require `langpacks-core-XY`.
** glibc locales subpackages weak dependencies will be updated to
depend on `langpacks-core-XY`
* Other developers: No other changes should be needed - current
package translation langpacks will continue to depend on
`langpacks-xx`.
** Policies and guidelines: No major changes here
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of
Fedora installed and are updated to the version containing this
change? Will anything require manual configuration or data migration?
Will any existing functionality be no longer supported? -->
No impact - the design is fully backwards compatible: `langpacks-XY`
will pull in the new `langpacks-core-XY`.
== How To Test ==
* dnf list langpacks-*
* dnf install langpacks-core-XY
* dnf install langpacks-XY
== User Experience ==
Fedora users will have more flexibility with installation of i18n
support packages and langpacks.
== Dependencies ==
glibc.spec needs to be updated with `s/langpacks/langpacks-core/` once
`langpacks` has implemented `langpacks-core`.
No other packages should be directly affected by the current proposal.
== Contingency Plan ==
* Contingency mechanism: Proposal owners will revert to F30
`langpacks` and glibc
* Contingency deadline: Beta freeze
* Blocks release? No
* Blocks product? N/A
== Documentation ==
No additional documentation at this stage.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 9 months
