devel April 2022

devel@lists.fedoraproject.org

201 participants
367 discussions

"rescue" boot entry files are not updated on OS upgrades
by Chris Murphy 04 Jan '23

04 Jan '23

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

6 7

Orphaned X11 packages
by Adam Jackson 24 Dec '22

24 Dec '22

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

3 2

[apt-cacher-ng] Resurrect dead package
by Frédéric Pierret 23 Dec '22

23 Dec '22

Hi, I've resurrected `apt-cacher-ng` on my fork: https://src.fedoraproject.org/fork/fepitre/rpms/apt-cacher-ng/c/06340bafbb2… with successful builds on my testing COPR repository for F32+ and EPEL8: https://copr.fedorainfracloud.org/coprs/fepitre/fedora/build/1879178/. I plan to (already) use this package for my current work on reproducible builds. Is the procedure described in https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers?r… still available for such case? Thank you. Best regards, Frédéric Pierret

3 3

fedpkg clone fails with Permission denied (publickey).
by Richard Shaw 26 Nov '22

26 Nov '22

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

5 10

nodejs-electron
by Andreas Schneider 19 Sep '22

19 Sep '22

Hello! Over the past 8 month, I've been working on getting Electron [1] built on Fedora. Yesterday I was finally able to do the first working build for Fedora Rawhide [2]. This was possible because we finally have ffmpeg [3] in Fedora. My use for Electron is that I want to run signal-desktop [4] on Fedora. You can get electron and signal-packages packages for it at [5]. Is there interest to bring nodejs-electron into Fedora and if yes, would someone be interested to maintain it? I don't have the time to maintain it but I'm happy to help as a co-maintainer. Best regards Andreas [1] https://www.electronjs.org/ [2] https://build.opensuse.org/package/show/network:im:signal/nodejs-electron [3] https://src.fedoraproject.org/rpms/ffmpeg/ [4] https://build.opensuse.org/package/show/network:im:signal/signal-desktop [5] https://download.opensuse.org/repositories/network:/im:/signal/ Fedora_Rawhide/x86_64/

8 26

F37 Change: Drop i686 builds of jdk8,11,17 and latest (18) rpms from f37 onwards (System-Wide Change)
by Ben Cotton 13 Jul '22

13 Jul '22

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

8 13

Claim delve
by Alejandro Saez Morollon 29 Jun '22

29 Jun '22

Hi there, folks. Delve[0] (a Golang debugger) was retired due to the impossibility of building a new version of delve for dependencies issues. I would like to claim the package and fix the situation. I already have one of the dependencies[1] in the works. I already talked with the original maintainer (he's in cc) and he is OK with it. Thanks. [0] https://src.fedoraproject.org/rpms/delve [1] https://src.fedoraproject.org/rpms/golang-starlark

2 2

[HEADS UP] -Wl,--as-needed is added in rawhide
by Igor Gnatenko 26 Jun '22

26 Jun '22

It's in redhat-rpm-config-118-1.fc30. If it causes any problems for you - let me know. In the meantime, you can use `%undefine _ld_as_needed` to disable it. Thanks for attention! -- -Igor Gnatenko

4 4

Wine MinGW system libraries
by Zebediah Figura 11 Jun '22

11 Jun '22

Hello all, I'm a contributor to the Wine project. To summarize the following mail, Wine needs special versions of some of its normal dependencies, such as libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm sending out a mail to major distributions in order to get some feedback from our packagers on how these should be built and packaged. For a long time Wine has built all of its Win32 libraries (DLLs and EXEs) as ELF binaries. For various reasons related to application compatibility, we have started building our binaries as PE instead, using the MinGW cross-compiler. It is our intent to expand this to some of our dependencies as well. The list of dependencies that we intend to build using MinGW is not quite fixed yet, but we expect it to include and be mostly limited to the following: * libvkd3d * libFAudio * libgnutls * zlib (currently included via manual source import) * libmpg123 * libgsm * libpng * libjpeg-turbo * libtiff * libfreetype * liblcms2 * jxrlib and dependencies of the above packages (not including CRT dependencies, which Wine provides). There is currently some internal discussion about how these dependencies should be built and linked. There are essentially three questions I see that need to be resolved, and while these resolutions have a significant impact on the Wine building and development process, they also have an impact on distributions, and accordingly I'd like to get input from our packagers to ensure that their considerations are accurately taken into account. (1) Should we build via source import, or link statically, or dynamically? Static linking and source imports are dispreferred by Fedora [1] [2], as by many distributions, on the grounds that they cause duplication of libraries on disk and in memory, and make it harder to update the libraries in question (see also question 2). They also make building and bisecting harder. Note however that if they are linked dynamically, we need to make sure that we load our packages instead of MinGW builds of open-source libraries with applications ship with. Accordingly we need each library to be renamed, and to link to renamed dependencies. For example, if application X ships with its own copy of libfreetype-6.dll, we need to make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and winezlib.dll. I think, although I haven't completely verified yet, that this can be done just with build scripts (i.e. no source patches), by using e.g. --with-zlib=/path/to/winezlib.dll. Accordingly, although static linking and source imports are generally disprefered, it may quite likely be preferable in our case. We don't get the benefits of on-disk deduplication, since Wine is essentially the only piece of software which needs these libraries. (2) If we use dynamic libraries, should dependencies be included in the main wine package, or packaged separately? This is mostly a question for packagers, although it also relates to (3). I expect that Fedora (and most distributions) want to answer "packaged separately" here, on the grounds that this lets them update (say) Wine's libgnutls separately, and in sync with ELF libgnutls, if some security fix is needed. There is a snag, though: we need libraries to be copied into the prefix (there's some internal effort to allow using something like symlinks instead, but this hard and not done yet). Normally we perform this copy every time Wine is updated, but if Wine and its dependencies aren't updated on the same schedule, we may end up loading an old version of a dependency in the prefix, thus missing the point of the update. (3) If dependencies are packaged separately, should Wine build them as part of its build tree (e.g. using submodules), or find and link (statically or dynamically) to existing binaries? Linking to existing binaries is generally preferable: it avoids duplication on disk; it reduces compile times when compiling a single package from source (especially the first time). However, we aren't going to benefit from on-disk duplication. And, most importantly, unlike with ELF dependencies, there is no standardized way to locate MinGW libraries—especially if it comes to Wine-specific libraries. We would need a way for Wine's configure script to find these packages—and ideally find them automatically, or else fall back to a submodule-based approach. If we rely on distributions to provide our dependencies, the best idea I have here would be something like a x86_64-w64-mingw32-pkg-config. And if we use shared libraries rather than static, things get worse: we need to know the exact path of each library and its dependencies so that we can copy (or symlink) them into a user's WINEPREFIX. For what it's worth, the current proposed solution (which has the support of the Wine maintainer) involves source imports and submodules. There's probably room for changing our approach even after things are committed, but I'd still like to get early feedback from distributions, and make sure that their interests are accurately represented, before we commit. In short, it's not clear whether distributions want their no-static-library policies to apply to us as well, or whether we're enough of a special case and would be enough of a pain to package that they'd rather we deal with the hard parts, and I don't want us to make any assumptions. ἔρρωσθε, Zebediah [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static… [2] https://fedoraproject.org/wiki/Bundled_Libraries

9 28

What to do with packages that fail to install since Fedora 34 but BZs are ASSIGNED?
by Miro Hrončok 10 Jun '22

10 Jun '22

Hello, during the Fedora 34 development cycle a year ago, I've reported the following buzgillas about packages that don't install: https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&f1=blocked&f2=b… They were set to ASSIGNED by their maintainers but since then, they still don't install on Fedora 34, Fedora 35 or Fedora 36. I see no point in keeping such packages in the repositories, yet the policy does not currently allow to do anything other than keep them. Should I take some steps, or do we keep building and shipping the broken packages forever? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

5 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel April 2022