List of long term FTBFS packages to be retired in February
by Miro Hrončok
Dear maintainers.
Based on the current fail to build from source policy, the following packages
will be retired from Fedora 34 approximately one week before branching (February
2021).
Policy:
https://docs.fedoraproject.org/en-US/fesco/Fails_to_build_from_source_Fai...
Note that some listed packages are orphaned and hence may be retired even sooner.
The packages in rawhide were not successfully built at least since Fedora 32.
This report is based on dist tags.
Packages collected via:
https://github.com/hroncok/fedora-report-ftbfs-retirements/blob/master/ft...
If you see a package that was built, please let me know.
If you see a package that should be exempted from the process, please let me
know and we can work together to get a FESCo approval for that.
If you see a package that can be rebuilt, please do so.
Package (co)maintainers Latest build
===============================================================================
VirtualGL gsgatlin Fedora 31
boo elsupergomez, orphan, tpokorra Fedora 31
gmpc orphan Fedora 31
jboss-servlet-2.5-api dmoluguw, orphan Fedora 31
js-html5shiv orphan Fedora 31
js-respond orphan Fedora 31
nodejs-info-symbol orphan Fedora 31
nodejs-interpret nodejs-sig, orphan Fedora 31
nodejs-net-browserify-alt orphan Fedora 31
nodejs-win-spawn nodejs-sig, orphan Fedora 31
rubygem-net-ssh-multi maxamillion, orphan, tdawson Fedora 31
sugar-flipsticks callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-getiabooks callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-infoslicer callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-labyrinth callkalpa, chimosky, pbrobinson Fedora 31
sugar-ruler callkalpa, chimosky Fedora 31
sugar-starchart callkalpa, chimosky, orphan Fedora 31
sugar-view-slides callkalpa, chimosky, pbrobinson, Fedora 31
tuxbrewr
sugar-visualmatch chimosky, orphan Fedora 31
sugar-yupana callkalpa, chimosky, orphan Fedora 31
The following packages require above mentioned packages:
Depending on: js-html5shiv (1)
copr-frontend (maintained by: clime, copr-sig, dturecek, frostyx, msuchy, praiskup)
copr-frontend-1.171-1.fc34.noarch requires js-html5shiv
Depending on: nodejs-info-symbol (2)
nodejs-log-utils (maintained by: orphan)
nodejs-log-utils-0.2.1-6.fc32.noarch requires npm(info-symbol)
nodejs-time-diff (maintained by: orphan)
nodejs-time-diff-0.3.1-7.fc32.src requires npm(info-symbol)
Depending on: nodejs-interpret (1)
nodejs-shelljs (maintained by: fab, nodejs-sig, patches)
nodejs-shelljs-0.8.4-2.fc33.noarch requires npm(interpret)
Affected (co)maintainers (directly and indirectly):
callkalpa: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
sugar-view-slides, sugar-infoslicer, sugar-starchart, sugar-getiabooks
chimosky: sugar-labyrinth, sugar-yupana, sugar-ruler, sugar-flipsticks,
sugar-view-slides, sugar-visualmatch, sugar-infoslicer, sugar-starchart,
sugar-getiabooks
clime: js-html5shiv
copr-sig: js-html5shiv
dmoluguw: jboss-servlet-2.5-api
dturecek: js-html5shiv
elsupergomez: boo
fab: nodejs-interpret
frostyx: js-html5shiv
gsgatlin: VirtualGL
maxamillion: rubygem-net-ssh-multi
msuchy: js-html5shiv
nodejs-sig: nodejs-win-spawn, nodejs-interpret
patches: nodejs-interpret
pbrobinson: sugar-labyrinth, sugar-flipsticks, sugar-view-slides,
sugar-infoslicer, sugar-getiabooks
praiskup: js-html5shiv
tdawson: rubygem-net-ssh-multi
tpokorra: boo
tuxbrewr: sugar-view-slides, sugar-infoslicer, sugar-getiabooks, sugar-flipsticks
10 hours, 3 minutes
Chromium built in rawhide does not render most strings
by Tom Callaway
Okay, this one has me stumped. Any chromium package I build through rawhide
refuses to render most of the strings.
At first, I thought this was gcc 11, but then I noticed that the first
build with this problem was built before GCC 11 landed in rawhide (the
compiler was the same n-v-r as the one in Fedora 33). Next, I thought it
must be due to a newer system component that Chromium uses dynamically, but
I was able to disprove that by installing the Fedora 33 build (same
version-release) into a Rawhide VM, and it works fine. Google Chrome also
works fine in rawhide.
It seems that this must be something that is contained within chromium,
that when built in rawhide, builds broken.
Here's a screenshot of what it looks like:
https://twitter.com/spotfoss/status/1338918235719299072/photo/1
Note that some text strings are rendering (in the UI, in the "search box"),
but most of them are not (the "HTML5Test" text below the icon, all of the
strings in the developer console).
Chromium has a lot of bundled components, so it is usually fairly resistant
to system changes. There are no differences between how Chromium builds
(within the RPM spec) on Fedora 33 and Rawhide. It also doesn't use
%{optflags}, so the compiler flags are equivalent.
Could this be due to some quirk of binutils in the way chromium gets linked
in rawhide? Is there something else unique to how packages are built in
rawhide right now? Are any other rawhide packages having similar string
issues?
Here are some builds for comparison:
Fedora 34: Chromium 87.0.4280.88 (built against GCC 11):
https://koji.fedoraproject.org/koji/taskinfo?taskID=57595738
Fedora 34: Chromium 87.0.4280.88 (built against GCC 10, same as Fedora 33):
https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 33: Chromium 87.0.4280.88 (build against GCC 10, but actually works
in rawhide):
https://koji.fedoraproject.org/koji/buildinfo?buildID=1655036
Fedora 34: Chromium 88.0.4324.27 (beta version of chromium, also broken)
https://koji.fedoraproject.org/koji/taskinfo?taskID=56977476
Thanks in advance,
~spot
1 day, 8 hours
Server Side Public License (SSPL) v1
by Tom Callaway
After review, Fedora has determined that the Server Side Public License
v1 (SSPL) is not a Free Software License.
It is the belief of Fedora that the SSPL is intentionally crafted to be
aggressively discriminatory towards a specific class of users.
Additionally, it seems clear that the intent of the license author is to
cause Fear, Uncertainty, and Doubt towards commercial users of software
under that license. To consider the SSPL to be "Free" or "Open Source"
causes that shadow to be cast across all other licenses in the FOSS
ecosystem, even though none of them carry that risk.
It is also worth nothing that while there is a draft for a "v2" of the SSPL:
A) It is not final.
B) It is not in use anywhere at this time (as far as we know).
C) The intent of the v2 draft text is not changed from the v1 license
currently in use.
We have updated our "Bad License" list to include SSPLv1. No software
under that license may be included in Fedora (including EPEL and COPRs).
Thanks,
Tom Callaway
Fedora Legal
4 days, 1 hour
Fedora 34 Change: Route all Audio to PipeWire (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DefaultPipeWire
== Summary ==
This change proposal is to route all audio from PulseAudio and JACK to
the PipeWire Audio
daemon by default.
== Owner ==
* Name: [[User:Wtaymans| Wim Taymans]]
* Email: wim.taymans(a)gmail.com
== Detailed Description ==
Currently, all desktop audio is handled by the PulseAudio daemon.
Applications make use of the
PulseAudio client library to communicate with the PulseAudio daemon
that mixes and manages the audio streams from the clients.
The desktop shell (gnome-shell) and the control panel
(gnome-control-panel) both use the
Pulseaudio client libraries to manage the volume and configuration of
the PulseAudio daemon.
This proposal is to replace the PulseAudio daemon with a functionally
compatible implementation
based on PipeWire. This means that all existing clients using the
PulseAudio client library
will continue to work as before, as well as applications shipped as Flatpak.
All PRO audio is handled with the JACK client library, which talks to
the JACK server. This
proposal will install a JACK client library replacement that talks
directly to PipeWire. All
existing PRO audio jack applications will then work on top of PipeWire.
For legacy ALSA clients, we will install an ALSA plugin that routes
the audio directly to
PipeWire.
With these 3 changes, all audio will be routed to PipeWire. There will
then be no more need to
install the PulseAudio and JACK daemons.
== Feedback ==
The owner of this proposal has been in context with both the
PulseAudio and JACK maintainers and community.
PipeWire is considered to be the successor of both projects.
== Benefit to Fedora ==
The end goal is to end up with one audio infrastructure for both
Desktop and Pro audio use cases.
This will end the fragmentation of the audio landscape.
Some of the benefits that PipeWire will bring:
* PRO Audio features
PipeWire can support both Desktop and PRO Audio use cases. PRO
Audio application tend to use
the JACK API and JACK daemon, which is hard to setup and integrates
poorly with the rest of
the system (and PulseAudio in particular).
With a replacement libjack library, PRO Audio application can run
directly on PipeWire and
integrate seamlessly with other ALSA and PulseAudio applications.
This would bring Fedora
closer to the experience of other operating systems.
* Flexibility/Integration
PipeWire is designed to be multiprocess. It separates the
processing of the multimedia graph
and the management into separate processes. This makes it possible
to better integrate with
the other system components or swap out the default policy for a
highly customized one (such as
for automotive or embedded). This is in contrast to PulseAudio,
which has all logic embedded
into the daemon with limited configuration options.
In the next phase we expect to greatly expand the user experience
and configuration of the
audio infrastructure with better integration throughout the system.
* Performance
PipeWire was designed for high performance and low-latency, using
much of the same design as
JACK. JACK application should run with comparable performance even
in low-latency situations.
* Security
PipeWire enforces per client security. Object visibility and the
actions on them can be
configured independently per client. This makes it possible to
enforce a security policy for
sandboxed applications (Flatpak) such as denying access to certain
audio capture devices or
block them from interfering with other applications.
* Maintainability
Both PulseAudio and JACK have very slow development cycles with few
new features. The more
flexible and distributed nature of the design of PipeWire should
encourage more new features
and use-cases.
== Scope ==
* Proposal owners:
We would make a pipewire-pulse package that provides the same features
as the pulseaudio (daemon) package.
We would only provide a drop-in replacement daemon, the pulseaudio
client libraries will remain unchanged.
The idea is that when installing pipewire-pulse, only the pulseaudio
package is removed and replaced by the
pipewire-pulse implementation. In the same way, installing the
pulseaudio package would remove the pipewire-pulse
package, making it possible to switch between implementations. This
will also allow for an easy rollback.
We also need to check and correct the dependencies of other packages.
As of this writing, some packages do
not state their dependencies correctly and get removed when pulseaudio
is removed. We also need to check the
JACK to make sure they still install with the replacement JACK client library.
The JACK client libraries will be installed in the same way, removing
the old JACK client libraries.
* Other developers:
The distribution needs to default to the pipewire-pulse package
instead of pulseaudio.
JACK applications need to install the pipewire-libjack client library.
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)
* Policies and guidelines:
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
The pulseaudio package will be uninstalled and pipewire-pulse will be installed.
pipewire-pulse does not yet implement all the features of pulseaudio
but it is expected that
comparable functionality will be implemented later. Most notable
features that are likely
not going to be available for fedora 34
* avahi network discovery and audio routing. This is not enabled by
default but can be activated
with paprefs. this includes TCP and RTP transport of audio.
* make devices available as UPNP media servers. Not enabled by
default, paprefs can be used.
* easy configuration of combining all sinks. Questionable feature but
possible via paprefs.
User scripts will still work but custom configurations of the
pulseaudio daemon will not be used
anymore.
Most of the JACK workflow of managing the JACK daemon is not going to
be needed anymore as things
will work out-of-the-box. As of this writing, these things are missing
from the JACK implementation,
we hope to implement them before fedora 34:
* latency reporting: useful to align streams
* freewheeling: used when rendering a project
* jackdbus: used by some tools to manage the graph
== How To Test ==
This change needs to be tested on as many different audio cards as
possible. The same test plan applies here as with PulseAudio.
To test, one needs to install the pipewire-pulse library (which
removes the pulseaudio package).
To test the JACK support, one needs to install pipewire-libjack, which
removes the original
JACK client and server.
After these changes, a restart is needed to make sure the new
pipewire-pulse daemon is running.
Audio functionality should be like it was before with the Pulseaudio
daemon. Some things to verify:
- patcl info should now list: Server Name: PulseAudio (on PipeWire 0.3.x)
- gnome-control-center: check the audio tab, check the volume sliders
and do the audio channel test. Change the card profile, plug/unplug
headphones and observe correct
switch.
- pavucontrol: check volumes in the input devices tabs and check the
microphone volumes
- firefox: check out a website with audio/video such as youtube and
verify that audio works as
usual. Check out a website with a video chat test page
(bluejeans.com/111).
- rhythmbox: check if playback works as expected
- bluetooth devices, connect as usual and verify working behaviour
with PipeWire. Check volume changes etc.
- Regular system usage and performance should not change.
- JACK tools such as catia, carla should run and can be used to
inspect the graph.
== User Experience ==
In general, users should not be able to see any change when using
PulseAudio applications.
The big change is when using JACK application:
- They will start without having to configure and start the daemon.
this includes
the period size and sample rates.
- All devices will be visible in the graph with meaningful names. Devices will
be automatically slaved when needed without needing any configuration.
- bluetooth devices will be usable as well.
== Dependencies ==
Other packages might need to have their requirements fixed to work
with the replacement packages
but this is under our control.
== Contingency Plan ==
* Contingency mechanism: Keep existing pulseaudio and JACK client
libraries as defaults
* Contingency deadline: beta freeze
* Blocks release? No
* Blocks product? No
== Documentation ==
[https://pipewire.org](PipeWire website)
[https://www.youtube.com/watch?v=8LZt4loZu64&t=14s](Video with Current status)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/INSTALL.md...
guide)
[https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/README.md]...
to use/test)
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
4 days, 2 hours
Fedora 34 Change: Enable spec file preprocessing (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Enable_Spec_File_Preprocessing
== Summary ==
This change should enable an opt-in spec file preprocessor in Fedora
infrastructure for the benefit of packagers. The preprocessor allows
some very neat tricks that were impossible before, for example
generate changelog and release automatically from git metadata or pack
the entire dist-git repository into an rpm-source tarball (effectively
allowing unpacked repos to live in DistGit).
== Owner ==
* Name: [[User:clime| Michal Novotný]]
* Email: clime(a)fedoraproject.org
== Detailed Description ==
There is a recently added feature into mock:
[https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preproce...
the rpkg preprocessor] which, if enabled, introduces an intermediate
step just before srpm building. This step consists of running the spec
file through a text preprocessing engine that includes an already
present library of macros designed specifically for rpm spec file
generation from git metadata. This library is called
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros]. The macros there allow packagers to have their
`%changelog`, `Release`, `Version`, `VCS` tag, or even `Source` fields
automatically generated from dist-git repository data and metadata.
The library can be easily extended in future to support more packager
use-cases or even a completely new library can be developed that
doesn't look at git metadata at all and instead, for example, analyses
already present tarball content to render spec file based on upstream
information. This doesn't mean it will happen but the framework is
generic enough to support that. There is also support for user-defined
macros that are loaded on-demand from a file placed alongside the
package sources, maintained by packager. This feature wouldn't be
enabled by this change from start but it's an example of freedom that
the preprocessing framework is able to provide. Enabling this change
should be very easy, basically adding:
<pre>
config_opts['plugin_conf']['rpkg_preprocessor_enable'] = True
</pre>
into mock configuration of Koji builders and using at least mock 2.7.
Some very minor change may be also needed in Koji regarding the spec
file lookup.
Even if the change is enabled on the infrastructure level like this,
the packager will still need to opt-in to use the preprocessor. The
opting-in is done by placing `rpkg.conf` file into the package
top-level directory with the following content:
<pre>
[rpkg]
preprocess_spec = True
</pre>
When this is done by a packager, the preprocessor will be finally
enabled for the given package.
Alongside, there is an ongoing work to add the preprocessor support
into the `rpkg` python library so that a packager can easily work with
the spec files containing the preprocessor (rpkg) macros:
https://pagure.io/rpkg/pull-request/530
The macros are supported since epel6 until the most latest Fedora
(preproc, rpkg-macros, and rpm-git-tag-sort packages are needed). The
spec preprocessing step in mock happens in a target chroot just before
the srpm build.
== Benefit to Fedora ==
This change offers solution to some long-standing issues in Fedora
around packaging (i.e. automatic release and changelog generation)
while also offering some interesting future options (for example
unpacked dist-git repos). The big advantage of this approach is that
it is explicit. Spec file stays the source of truth and by looking
inside one, you will be able to determine how the text will expand for
a certain git repository state.
== Scope ==
* Proposal owners:
For the very basic support, probably a small patch in Koji is needed
to be able to lookup not only `.spec` files but also `.spec.rpkg`
files (the `.spec.rpkg` extension explicitly states that the spec file
is a template). Also the `rpmdevtools/rpmdev-bumpspec` script should
be tweaked to be compatible with spec files using the macros.
* Other developers:
Some optional help with `rpmdevtools/rpmdev-bumpspec` changes would be welcome.
* Release engineering: [https://pagure.io/releng/issue/9910 #9910] (a
check of an impact with Release Engineering is needed)
Enabling the rpkg_preprocessor plugin in mock config for Koji builders.
* Policies and guidelines:
The new macro support should be mentioned or even described in the
packaging guidelines. We should decide if the full power of the
rpkg-macros library should be allowed from start (i.e. even unpacked
repos).
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Because of the opt-in nature on packager side, there should be no
compatibility issues.
== How To Test ==
Once the feature is enabled, one can test it by providing the
`rpkg.conf` file with the required content in a package repository and
use some rpkg macro in the spec file: e.g.
<pre>
Name: {{{ git_dir_name }}}
</pre>
to generate the name of the package from the repository name (this
should actually produce the original text as package names should be
the same as the repository basenames).
To try it out first without committing to dist-git, one can use `rpkg`
command-line tool from
https://copr.fedorainfracloud.org/coprs/clime/rpkg-util/ or even
fedpkg's koji scratch build after
[https://pagure.io/rpkg/pull-request/530 the work in the pyrpkg]
library is finished.
One can also currently use Copr's SCM "rpkg" build method where the
macros are enabled but the rpkg-macros there are in version 2 whereas
this change is about introducing the
[https://docs.pagure.org/rpkg-util/v3/macro_reference.html version 3
rpkg-macros]. However, while there are some differences between v2 and
v3, the idea and most of the working is the same.
== User Experience ==
This change is intended for packagers. It should help to make a bit of
their work easier and offer them some new interesting options.
== Dependencies ==
N/A
== Contingency Plan ==
Packagers can opt-out on individual basis by removing the `rpkg.conf`
file or just setting the `preproces_spec` property to `False`. On
infrastructure level, the rpkg_preprocessor plugin could be disabled
again.
== Documentation ==
- [https://github.com/rpm-software-management/mock/wiki/Plugin-rpkg-preproce...
Mock's rpkg_preprocessor plugin]
- [https://docs.pagure.org/rpkg-util/v3/macro_reference.html
rpkg-macros reference (the library of macros ready to be used in spec
files)]
== Release Notes ==
Currently N/A
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
5 days, 10 hours
Fedora 34 Change: Unify the GRUB configuration files location across
all supported architectures (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/UnifyGrubConfig
== Summary ==
This change makes the GRUB configuration files layout to be consistent
across all the supported architectures. Currently EFI is a special
case since the GRUB configuration file and environment variables block
are stored in the EFI System Partition (ESP) instead of the boot
partition (or `/boot` directory if no boot partition is used).
== Owner ==
* Name: [[User:Javierm|Javier Martinez Canillas]]
* Email: javierm(a)redhat.com
* Name: [[User:Gicmo|Christian Kellner]]
* Email: ckellner(a)redhat.com
== Detailed Description ==
The GRUB configuration files layout on EFI platforms is not consistent
with the other non-EFI platforms (e.g: x86 with legacy BIOS, ppc64le
with Open Firmware). On platforms using EFI the GRUB configuration
file (`grub.cfg`) and environment variables block (`grubenv`) are
stored in the EFI System Partition (ESP) while for non-EFI platforms
these are stored in the boot partition (or `/boot` directory if not
boot partition is used).
The reason for this is that the path where the GRUB bootloader
searches for its configuration file varies depending on the firmware
interface used. In most cases, GRUB searches for it in the path set in
the `$prefix` variable. The device is not specified in that case, GRUB
just searches for a configuration in this path for every detected
device. But on EFI, a special `$fw_path` variable is used instead.
This variable specifies both the device and path from where the GRUB
bootloader was loaded and these are used to search for the
configuration file. This is done for security reasons, to make sure
that the correct GRUB configuration file is used and not just the
first one found in one of the detected devices.
Since the GRUB binary is located in the ESP, it expects to find the
configuration file in that location as well. But this creates the
mentioned inconsistency, because the GRUB configuration file has to be
stored in `/boot/efi/EFI/fedora/grub.cfg` while for non-EFI platforms
it has to be stored in `/boot/grub2/grub.cfg`.
This leads to a GRUB configuration layout that is confusing for users
and error prone, since either the tools that are used to manage these
files have to be aware of the differences or symbolic links used to
hide the fact that the pats differ depending on the platform. Also, it
creates artificial constraints on the OS installation due the
differences in the configuration layout used. A system installed when
using EFI won't be bootable if the firmware configuration is changed
to boot using legacy BIOS instead, for example enabling the EFI
Compatibility Support Module or moving the disk to a BIOS machine.
The proposal is to always store the `grub.cfg` and `grubenv` files in
the `/boot/grub2/` directory, making `/boot/efi/EFI/fedora/grub.cfg`
to only be a small configuration file that sets a different `$prefix`
variable and loads the configuration file stored in
`/boot/grub2/grub.cfg`.
The `$prefix` variable will be set to the device partition where
`/boot/grub2/grub.cfg` is stored, using the partition filesystem's
Universally Unique IDentifier (UUID). That way the correct GRUB
configuration file will be loaded, making it as secure as the current
approach where the configuration file in the ESP is used.
A drawback of the new approach is that the GRUB configuration will now
depend on the boot partition (or `/boot` directory if no boot
partition is used). But since the kernel and initramfs images are
stored there too, the bootloader configuration already has this
dependency anyways.
Note that the proposed configuration files layout is already used by
the Fedora CoreOS Assembler (COSA) and OSBuild image builders. So this
will make the systems installed with Anaconda to be consistent with
the images generated by these.
== Benefit to Fedora ==
This change will not only simplify and make less confusing the GRUB
configuration but also allow the following improvements:
* To have a consistent configuration across all the architectures using GRUB.
* Allow the same installation to be booted with either EFI or legacy BIOS.
* Use the same documentation and commands for all architectures
instead of having EFI as a special case.
* Make GRUB configuration tools more robust by not relying on symbolic
links to be created and not having to handle platform specific cases.
* Align with images generated by COSA and OSBuild on how the GRUB
configuration files are used.
* Align with other Linux distributions on how the GRUB configuration
files are used.
== Scope ==
* Proposal owners:
** Modify Anaconda to generate the `grub.cfg` and `grubenv` files in
`/boot/grub2/` instead of `/boot/efi/EFI/fedora/` for EFI platforms.
** Make Anaconda to generate the minimal GRUB config file in the ESP
that sets the `$prefix` variable and loads the configuration file
located in `/boot/grub2/grub.cfg`.
** Modify the grub2 package scriptlets to not generate the
`/boot/grub2/grubenv` and `/etc/grub2-efi.cfg` symbolic links since
these will not be needed anymore.
** Make any changes needed in tools that use these configuration files
(`grubby`, `kernel-install` scripts, etc).
* Other developers:
** The Anaconda developers will need to review and merge the patches
to change where the GRUB configuration files are created.
** Test and watch for regressions.
* Release engineering:
** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List
of deliverables]]: N/A
* Policies and guidelines: The policies and guidelines do not need to
be updated.
* Trademark approval: No changes needed.
== Upgrade/compatibility impact ==
The changes will only be for new installations, existing systems will
not be impacted and will continue using the grub.cfg and grubenv files
that are located in the ESP.
== How To Test ==
* Install Fedora 34 and verify that the GRUB configuration is correct.
* Check that the `/boot/efi/EFI/fedora/grub{.cfg,env}` files are not present.
* Check that the `/boot/grub2/grub{.cfg,env}` files are present.
* Enter the GRUB prompt by pressing 'c' from the GRUB boot menu and
execute the following command:
<pre>echo $prefix</pre>
and verify that the prefix is set to the partition that contains the
`/boot/grub2` directory.
* Re-generate the GRUB configuration file with:
<pre>grub2-mkconfig -o /boot/grub2/grub.cfg</pre>
and verify that the GRUB configuration is still correct.
== User Experience ==
No visible changes are expected other than the configuration files
being present in a different path. This should improve the overall
user experience.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the Anaconda and grub2 package
scriptlets changes.
* Contingency deadline: Beta Freeze
* Blocks release? No
* Blocks product? None
== Documentation ==
* Fedora CoreOS assembler script that creates the GRUB config file for
EFI: https://github.com/coreos/coreos-assembler/blob/master/src/create_disk.sh
* OSBuild org.osbuild.grub2 stage that creates the GRUB config file
for EFI: https://github.com/osbuild/osbuild/blob/main/stages/org.osbuild.grub2
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
1 week, 4 days
Thoughts about packaging a standalone python-PyQt5-sip?
by Michel Alexandre Salim
Hi all,
Neal and I are looking at getting ButterManager packaged, and it
depends on sip and PyQt5-sip:
https://github.com/egara/buttermanager/blob/master/requirements.txt
Now, this is where things get a bit odd:
- the current sip (4.19.24) does not have autogenerated Python
provides, but sip5 does:
$ sudo dnf repoquery --provides sip
Last metadata expiration check: 1:48:00 ago on Wed 30 Dec 2020 02:50:53
PM PST.
sip = 4.19.24-1.fc33
sip(x86-64) = 4.19.24-1.fc33
sip-macros = 4.19.24-1.fc33
$ sudo dnf repoquery --provides sip5
Last metadata expiration check: 1:48:05 ago on Wed 30 Dec 2020 02:50:53
PM PST.
python-sip5 = 5.5.0-1.fc33
python3-sip5 = 5.5.0-1.fc33
python3.9-sip5 = 5.5.0-1.fc33
python3.9dist(sip) = 5.5
python3dist(sip) = 5.5
sip5 = 5.5.0-1.fc33
sip5(x86-64) = 5.5.0-1.fc33
- sip ships PyQt5 bindings with matching version, but sip 5 seems to no
longer do so
$ sudo dnf info python3-pyqt5-sip
Last metadata expiration check: 1:51:03 ago on Wed 30 Dec 2020 02:50:53
PM PST.
Installed Packages
Name : python3-pyqt5-sip
Version : 4.19.24
Release : 1.fc33
Architecture : x86_64
Size : 244 k
Source : sip-4.19.24-1.fc33.src.rpm
Repository : @System
From repo : fedora
Summary : SIP - Python 3/C++ Bindings Generator for pyqt5
URL : https://riverbankcomputing.com/software/sip/intro
License : GPLv2 or GPLv3 and (GPLv3+ with exceptions)
Description : This is the Python 3 build of pyqt5-SIP.
- https://pypi.org/project/PyQt5-sip/ has PyQt5-sip 12.8.1 but
https://pypi.org/project/sip/ has sip 5.5.0 which matches the sip5 in
Fedora (available since last month)
- there's a lot of packages that depend on python3-pyqt5-sip (though
none use the canonical python3dist(pyqt5-sip) unfortunately)
$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
'python3dist(pyqt5-sip)'
Last metadata expiration check: 0:15:20 ago on Wed 30 Dec 2020
04:28:29 PM PST.
$ sudo dnf repoquery --repo rawhide,rawhide-source --whatrequires
python3-pyqt5-sip
Last metadata expiration check: 0:15:30 ago on Wed 30 Dec 2020
04:28:29 PM PST.
calibre-0:4.23.0-3.fc34.x86_64
krita-0:4.4.1-1.fc34.i686
krita-0:4.4.1-1.fc34.x86_64
libarcus-0:4.8.0-1.fc34.src
mingw-python-qt5-0:5.15.0-4.fc34.src
pyqtwebengine-0:5.15.0-2.fc33.src
python-pyface-0:7.1.0-1.fc34.src
python-pynest2d-0:4.8.0-1.fc34.src
python-qt5-0:5.15.0-5.fc34.src
python3-arcus-0:4.8.0-1.fc34.x86_64
python3-arcus-lulzbot-0:3.6.21-8.fc34.x86_64
python3-poppler-qt5-0:0.75.0-6.fc33.x86_64
python3-pyqtchart-0:5.15.2-1.fc34.i686
python3-pyqtchart-0:5.15.2-1.fc34.x86_64
python3-qgis-0:3.16.1-2.fc34.i686
python3-qgis-0:3.16.1-2.fc34.x86_64
python3-qscintilla-qt5-0:2.11.5-1.fc34.x86_64
python3-qt5-base-0:5.15.0-5.fc34.i686
python3-qt5-base-0:5.15.0-5.fc34.x86_64
qhexedit2-0:0.8.9-2.fc33.src
scidavis-0:2.3.0-2.fc33.src
veusz-0:3.3.1-1.fc34.src
veusz-0:3.3.1-1.fc34.x86_64
Any idea what's the best way to handle this? and/or why PyQt5-sip's
versioning get so far ahead of sip?
Thanks,
--
Michel Alexandre Salim
profile: https://keyoxide.org/michel@michel-slm.name
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2
1 week, 5 days
Re: NeuroFedora review swaps
by Ankur Sinha
On Mon, Jan 28, 2019 15:47:00 +0100, J. Scheurich wrote:
>
> > I'd like to get this package reviewed please:
> >
> > - python-pyscaffold: https://bugzilla.redhat.com/show_bug.cgi?id=1669913#
> >
> > Would anyone like to swap reviews?
>
> I would review it for wdune sponsoring.
Sorry---I'm not current with the wdune scenario. I assumed you meant
that you'd review it unofficially as part of the work to get sponsored
to the packagers group:
https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_gro...
I'm not a sponsor yet so I cannot sponsor you to the group myself, but
once you've done a few reviews, a sponsor will be happy to take a look
at them and guide you through the sponsorship process.
If you've submitted a review ticket for wdune already, I will be happy
to review it and provide comments.
--
Thanks,
Regards,
Ankur Sinha
https://ankursinha.in
Time zone: Europe/London
1 week, 6 days