Planning to start unifying native and mingw packages
by Sandro Mani
Hi
Following recent discussions and to reduce the maintenance burden, I'm
planning to start merging native and mingw packages. Initially, I'll be
looking at these packages where I maintain both variants:
eigen3 mingw-eigen3
enchant2 mingw-enchant2
freeimage mingw-freeimage
gdal mingw-gdal
GeographicLib mingw-GeographicLib
geos mingw-geos
giflib mingw-giflib
gtkspell3 mingw-gtkspell3
gtkspellmm30 mingw-gtkspellmm30
jxrlib mingw-jxrlib
leptonica mingw-leptonica
libgeotiff mingw-libgeotiff
libimagequant mingw-libimagequant
libkml mingw-libkml
librttopo mingw-librttopo
libspatialite mingw-libspatialite
libwebp mingw-libwebp
openjpeg2 mingw-openjpeg2
OpenSceneGraph mingw-OpenSceneGraph
osgearth mingw-osgearth
podofo mingw-podofo
proj mingw-proj
python-pillow mingw-python-pillow
qtspell mingw-qtspell
shapelib mingw-shapelib
svg2svgt mingw-svg2svgt
tesseract mingw-tesseract
uriparser mingw-uriparser
I'm performing test builds here [1]. Once I've got them all building
there, if there are no objections, I plan to push to F37 and retire all
the corresponding mingw repos.
Sandro
[1] https://copr.fedorainfracloud.org/coprs/smani/mingw-unified-spec/builds/
1 year, 1 month
FESCo wants to know what you use i686 packages for
by David Cantrell
Hi,
Our most recent FESCo meeting involved discussing the proposal to drop i686
builds of jdk8,11,17 from Fedora 37 onward. The topic quickly changed to the
larger question of "what do people use i686 packages for?"
Rather than guess, we wanted to ask the community what you use i686 packages
for in Fedora. There are no wrong answers here. We are seeking information.
Why? Since the removal of the i686 kernel in Fedora, we want to reduce the
number of i686 packages provided in the repo. As time marches on, the ability
to build a lot of things for i686 becomes unrealistic or even impossible.
Remember it goes beyond providing builds...providing support, bug fixes, and
security fixes for those packages too. Maybe some things using i686 packages
now can move to x86_64 packages. We do not know yet, but a goal is to figure
out what packages, if anything, can drop their i686 builds.
NOTE: Nothing is changing now. We are in an information gathering phase.
~~~~~~~~~~~~~~~~~~~~~~~~
If you use i686 packages for something now, please respond to this thread.
Thanks,
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
1 year, 3 months
"rescue" boot entry files are not updated on OS upgrades
by Chris Murphy
Summary----------
Most all Fedora variants (except Cloud) have a GRUB menu entry
containing the word "rescue". This kernel+initramfs pair are never
updated for the life of a Fedora installation. And they quickly become
stale as a Fedora installation ages. This kernel's modules are
eventually deleted, and if selected at boot time, the typical user
experience is a dracut shell.
Basic background-------------
(skip this section if you know how it works)
During a new installation, a single kernel version is installed. e.g.
vmlinuz-5.17.0-0.rc4.96.fc36.x86_64 which is then duplicated as e.g.
vmlinuz-0-rescue-3a86878de5d649a983916543ece7bb7e.
Each of those (identical) kernels has an initramfs file:
initramfs-5.17.0-0.rc4.96.fc36.x86_64.img
initramfs-0-rescue-3a86878de5d649a983916543ece7bb7e.img
The sole difference is the first one is a smaller host-only initramfs,
the second one is a larger no host-only initramfs created with `dracut
-N`. The bigger one just contains a bunch of extra kernel modules and
dracut scripts, ostensibly to make it more likely to boot a system
with some change in hardware that the host-only initramfs doesn't
contain. The size of this rescue initramfs is around 100 MiB, with the
common day to day "host only" initramfs being around 33 MiB. [1]
As the system is updated, additional kernel versions are installed.
dnf.conf contains installonly_limit=3, which results in a maximum of
three kernel versions being installed at a time. Once a fourth kernel
is installed, the first kernel and its modules are removed from
/usr/lib/modules. The rescue kernel+initramfs pair are never updated
or upgraded, even during system upgrades.
Observations------------
This has been discussed by the Workstation working group [2] but since
this functionality is present in all of Fedora, we're moving the
discussion for greater visibility.
There's two separate complaints, if you will: (a) that the
kernel+initramfs pair are never update or upgraded for the life of the
installation; and (b) that even during one release cycle, the user
experience when booting the rescue entry, changes, i.e. when the
matching /usr/lib/modules for the rescue entry are present early on,
you do get a full runtime behavior, you will get to a graphical
environment. But then once the version matched /usr/lib/modules are
removed, you get a completely different behavior when booting the
rescue entry.
An important note from that ticket from Justin Forbes, the Fedora
kernel maintainer: " Remember, the only real purpose of the rescue
kernel is to get your system out of something completely unusable. It
isn't meant to be a full runtime."
Questions------------
* Considering the very narrow purpose of the entry, maybe the current
behavior is adequate?
* Does the rescue entry reliably get users to a dracut prompt, rather
than indefinite hang? I don't know whether it does.
* Is there any way to improve the situation without increasing the
risk that the rescue entry becomes totally non-functional?
* The chosen kernel version needs to be based on one that is known
to boot. Currently we know the kernel+initramfs pair work because it's
the same version used to boot the installation media when doing the
initial provisioning. We don't actually know an updated replacement
"no host-only" initramfs will work until it's tried. Is it possible to
automate this? And is it worth the risk, or even figuring out how to
assess the risk?
* At Flock 2021, Zbyszek proposed "Building Initrd Images from
RPMs" to reduce the complexity of building initramfs, maybe there's a
role for it here? More: https://www.youtube.com/watch?v=GATg_bqmASc
* What happens if we accept some scope creep, and go for many
improvements that make the extra work worth it?
* What about the unsigned nature of the initramfs? Should we be
creating initramfs's in Fedora infra and signing them?
* Stuff a graphical rescue environment into the initramfs? (This
might be ten leaps too far, but it's intended to encourage thinking
with a vivid imagination.)
[1] both values from a recent Fedora 36 Workstation installation
[2] https://pagure.io/fedora-workstation/issue/259
--
Chris Murphy
1 year, 3 months
Orphaned X11 packages
by Adam Jackson
The following packages, previously owned by xgl-maint, are now up for grabs:
xorg-x11-xfs
xorg-sgml-doctools
xorg-x11-drv-v4l
xorg-x11-xsm
xorg-x11-twm
xorg-x11-drv-sisusb
xorg-x11-xdm
xorg-x11-docs
Upstream development on all of these is pretty much nil, so if you're
serious about picking up any of these you may also wish to take on the
module upstream:
https://gitlab.freedesktop.org/xorg
- ajax
1 year, 3 months
fedpkg clone fails with Permission denied (publickey).
by Richard Shaw
Long story short I lost my home directory where I do all of my packager
activities (separate from my main user) so I'm setting things up from
scratch.
I created new ssh keys and uploaded the public key to
admin.fedoraproject.org and pasted into pagure.io. It's been over an hour
and I'm still getting:
$ fedpkg clone hamlib
Cloning into 'hamlib'...
hobbes1069(a)pkgs.fedoraproject.org: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Could not execute clone: Failed to execute command.
I've also updated my API tokens, which is STILL not well documented. I
pasted them in the appropriate spot in "/etc/rpkg/fedpkg.conf" which isn't
real intuitive.
Thanks,
Richard
1 year, 4 months
F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from
f37 onwards (System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Drop_i686_JDKs
== Summary ==
java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk and
java-latest-openjdk packages will no longer build i686 subpackages
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: <jvanek(a)redhat.com>
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)(which no longer exists)
=== Expected schedule ===
* during march, drop i686 builds from all jdks in fedora rawhide
== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* java-17-openjdk (LTS)
* java-latest-openjdk (STS, jdk18).
All those builds on all architectures except jdk8, where arm32 with
jit is built by different package.
Unluckily, the i686 bit builds of jdk are rotten in upstream. The
recent breakage of i686 JIT just before branching nearly killed jdk17
as system jdk feature.
The rotting have main visibility with newer GCCs. If GCC bump, and it
does, it always triggers new issues in i686 JIT, and there is less and
less people to somehow workaround them. Unluckily, there is probably
no longer anyone willing to really fix them
== Benefit to Fedora ==
The i686 builds are rotten in usptream, and to patch them localy had
become pain. We may be introducing very bugy i686 jdk. Better then to
do so, we would rather not ship that at all.
This will untie hands of both JDK and GCC developers, who will no
longer need to dive into nasty legacy code.
== Scope ==
==== Change owners ====
* we will simiply stop building i686 pkg in rawhide
==== Other developers ====
* may notice the multilib i686 java missing.
* it is up to them to drop i686 builds or to povide workaround (if possible)
==== Other ====
* Release engineering: https://pagure.io/releng/issue/10686
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
* The upgrade on multilib systems will lead to autoremoval of i686 javastack
* which should be minimum - 99% of javastack is noarch
== How To Test ==
install i686 java will result to not packages found
== User Experience ==
User experience on multilib systems will be bad. Bad reasonable.
== Dependencies ==
There are is unknown number of multilib java consumers. I expect some
of them may rise voice, but that will have to handled one by one.
== Contingency Plan ==
* Contingency mechanism: return i686 packages
* Contingency date: (not provided)
== Documentation ==
Will be neded...
== Release Notes ==
None yet...
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 9 months