devel January 2023

devel@lists.fedoraproject.org

219 participants
291 discussions

Planning to start unifying native and mingw packages
by Sandro Mani 09 Mar '23

09 Mar '23

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/

9 35

webkitgtk6.0 soname bump season
by Michael Catanzaro 09 Mar '23

09 Mar '23

Hi, The webkitgtk6.0 package (for GTK 4, not GTK 3) will be doing several soname bumps over the next two months in preparation for stabilizing the GTK 4 API. I won't announce individual bumps since they will be frequent. I will handle rebuilds of the impacted packages: gnome-initial-setup, gnome-builder, evolution-data-server, and epiphany. (If I've missed anything, please yell.) These soname bumps will happen in both rawhide and also in F38 once it is branched. Sometime soon, hopefully in February but maybe early March, the API/ABI will become stable, as it already is for GTK 3, and the fun will then be over. Hopefully. Michael

1 2

Assess impact of package changes with the mass prebuilder
by Frederic Berat 08 Mar '23

08 Mar '23

Hello Fedora community, The Christmas period is coming, and soon after the Fedora mass rebuild will come and may lead to the creation of a bunch of FTBFS bugzillas. I'd like to share with you the availability of a tool that we started to develop this year, which aims to help developers to assess the impact a change in their component will have on other components that depend on them. I recently used it in order to prepare for the upcoming Autoconf 2.72 release, and with it uncovered about 84 build failures (out of 1197 packages depending on Autoconf) that would have been missed if I were following the "classical" workflow. This resulted in few bugs opened in corresponding components, and even upstream changes toward the Autoconf community, prior to the official 2.72 release. In the past weeks, it has also been used to assess the impact of porting Fedora to Modern C (by Florian Weimer) which tested about 10k packages and for the make 4.4 update (from DJ Delorie), which tested about 9k dependencies against this new version to look for breakage. Yet, the more users there will be, the more this tool will improve and be useful for the packagers. This tool is called the mass prebuilder. I've written a blog post for Red Hat a while ago, which already contains a lot of details about it: https://developers.redhat.com/articles/2022/09/26/find-errors-packages-thro… There is a COPR package available to ease installation: https://copr.fedorainfracloud.org/coprs/fberat/mass-prebuild/ And a detailed Howto available in the source README: https://gitlab.com/fedora/packager-tools/mass-prebuild/-/blob/main/README.md As of today, the tool provides most of the planned features, although it only uses COPR as a builder backend, whereas Koji is also planned on the long run (and likely others). Since the tool is fairly new, it lacks manpages, may miss features you would expect and is likely to have bugs (even if we tried to limit them as much as possible). Therefore, don't hesitate to open issues in the Gitlab repository if need be: https://gitlab.com/fedora/packager-tools/mass-prebuild/-/issues. Frédéric Bérat Senior Software Engineer, Platform Tools Red Hat <https://www.redhat.com> fberat(a)redhat.com <https://www.redhat.com>

1 1

OpenSSH: hardening hostkeys permissions
by Dmitry Belyavskiy 02 Mar '23

02 Mar '23

Dear colleagues, Many years ago we implemented the patch https://src.fedoraproject.org/rpms/openssh/c/1ddd0ee5 Unfortunately, as it was 11 years ago, we can't find the exact explanation where the requirement came from. We think that we intended to increase security, but it probably caused more confusion than gain of the security over the years. The patch allows more relaxed permissions for the private keys than upstream OpenSSH permits - 0640 instead of 0600, and the key file must belong to the ssh_keys group. The ssh_keysign utility was simultaneously changed from suid root to sgid ssh_keys. The side effect of this solution is that ssh with host based auth (HBA) started to fail after changing group ID ( with newgrp, etc.). In the case of HBA ssh invokes ssh-keysign that does a lot of sanity checks including group checks. The workaround is returning setuid bit instead of sgid, and we recommend it to our clients. Some more information is available in https://bugzilla.redhat.com/show_bug.cgi?id=1498845 As this problem affects several clients, and it is a deviation from upstream (the similar patch was rejected by upstream), we want to drop this downstream patch in Fedora. We also can get rid of a designated ssh_keys group The problem we expect is that after reverting the patch we can lose the remote access to the hosts because sshd will reject starting because of group reading permissions. This should be covered by the upgrade scriptlet, though we still may come across some issues, especially if you use host keys in non-standard locations. How do we properly implement this feature to avoid customers' negative feedback? Current upgrade scriptlet covers standard key locations/names and works well enough at the 1st glance. The proposed changes are available https://src.fedoraproject.org/rpms/openssh/pull-request/37 A separate question is whether we want to publish this announcement as a Fedora change and at what level. For me it looks like a self-contained change. -- Dmitry Belyavskiy

4 6

F38 proposal: IPP-USB as a weak dependency of CUPS and sane-airscan (Self-Contained Change proposal)
by Ben Cotton 19 Feb '23

19 Feb '23

https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Add `ipp-usb` as a weak dependency of packages which provide support for driverless printing (`cups`), driverless scanning (`sane-airscan`) and driverless fax for USB devices capable of using driverless functionality (how to find out whether your USB device is driverless [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to… here]), so such devices will work without a specific driver. `ipp-usb` design conflicts with the way how drivers work with the device, so a user intervention is required after upgrade. == Owner == * Name: [[User:Zdohnal | Zdenek Dohnal]] * Email: zdohnal(a)redhat.com == Detailed Description == Nowadays most printers and scanners from common vendors provide a way how to work without a specific driver. This way relies on driverless standards implemented in device's firmware and their support in the operating system user has. At first (in 2010) network driverless standards were implemented in devices and widely spread, such as AirPrint, [https://www.pwg.org/ipp/everywhere.html IPP Everywhere] for printers or eSCL (sometimes called AirScan) and WSD (Windows Service Discovery) for scanners. Those network driverless standards and others are already supported in `cups` (for printing) and `sane-airscan` packages. Two years later USB devices got their own driverless standard - [https://robots.org.uk/IPPOverUSB?action=AttachFile&do=view&target=IPP+USB+S… IPP over USB] - which is now implemented by `ipp-usb`. The package itself has been in Fedora for more than two years available for users to opt-in USB driverless support. The `ipp-usb` package contains `ipp-usb` daemon, which works as an HTTP proxy over the claimed USB devices, provides printing (via [http://ftp.pwg.org/pub/pwg/standards/std-ipp20-20151030-5100.12.pdf IPP 2.0+] protocol), scanning (via eSCL) and fax (via [http://ftp.pwg.org/pub/pwg/candidates/cs-ippfaxout10-20140618-5100.15.pdf IPP Faxout]) support and advertises them on localhost by mDNS protocol. mDNS is the key feature for automatic discovery, but it is not required to use it - the virtual printer device provided by `ipp-usb` can be accessed at URI `ipp://localhost:60000/ipp/print` and the URI can be used for permanent queue installation - [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/#_how_to… here] is the manual. However if mDNS is enabled, the virtual device shared by `ipp-usb` can be automatically picked up by other services (as `cups` or `sane-airscan`), so no further configuration is required to get the device installed. The feature is called ''temporary queue'' in CUPS and it is supported in applications using the up-to-date CUPS API or toolkits using up-to-date CUPS API - f.e. GTK3+ based applications, Libreoffice and Firefox. The fax functionality is available at URI `ipp://localhost:60000/ipp/faxout`, but the automatic installation doesn't work for it and it has to be installed manually. As mentioned above, the `ipp-usb` daemon claims the USB interface of the device which supports IPP over USB standard. This behavior conflicts with the previous driver approach, where the discovery mechanism only scans USB ports for available devices, but doesn't try to claim the USB interface, which is unavailable because `ipp-usb` has claimed it already. The result is the device can be discovered by classic driver tools, but it won't work once user wants to print, scan or fax. In such cases user intervention is needed, where user has to make a decision whether to use driverless USB support or classic support with drivers. The way how to do it will be explained later in this proposal. Based on the current `ipp-usb` design the following specific setups aren't expected to work, because they are not common with USB device usage: * combining driverless and classic driver's support doesn't work on the same device - driverless or classic driver has to be used for whole device's functionality. * if user has several devices of the same model, all of them has to be supported by a single solution - driverless or classic driver - because quirks and SANE backends use model name, vendor ID or product ID, which are the same for all devices of the same model, for denying the support. * if scanner backend does not support disabling support for a specific device (f.e. `hpaio`, `pixma` are such backends), the whole backend can be disabled to prevent discovering broken scanners - it results in the scanner support provided by the backend will be disabled for all other devices which are in the user's environment - both network and USB. To provide a possibility to opt-out from driverless USB printing the `ipp-usb` package will be added as a weak dependency of `cups` and `sane-airscan`, so it can be uninstalled without losing the rest of the printing and scanning stack, and `ipp-usb check` will be added into `%post` scriptlet of `ipp-usb` package for users to see whether they have a device claimed by `ipp-usb` during upgrade process. == Feedback == I've investigated possible solutions for two biggest concerns which adding `ipp-usb` has raised and consulted it upstream: 1. The current design of claiming the interface of IPP-over-USB device and not releasing it until `ipp-usb` daemon stops and whether it can be changed - I talked with upstream about it at [https://github.com/OpenPrinting/ipp-usb/issues/50#issuecomment-1122248609 upstream issue] - the reason for it is to prevent potential race conditions/bugs in device's firmware, which is sometimes flaky and updates are not coming to it in regular manner, due combined access for printing or scanning. 2. The design makes impact to an existing setups as well, so the upgrade path has to be taken into consideration - this was mentioned in the [https://github.com/OpenPrinting/ipp-usb/issues/50 upstream ticket] too. Based on the following expectations regarding devices: * might have firmware bugs * might have lesser functionality than classic driver and the expectations above differ from device to device, we can't automatically prefer one solution over the other at the moment and user manual intervention after upgrade is needed. This feature will explain how to create a quirk for the `ipp-usb` daemon to ignore the device or disable them in classic drivers to reduce this conflict. == Benefit to Fedora == Modern USB devices will work out of the box without a specific driver, so users don't need to install a driver or the device at all. == Scope == * Proposal owners: The proposal owner will add `Recommends: ipp-usb` to `cups` and `sane-airscan` packages, `ipp-usb check` call into `%post` scriptlet of `ipp-usb` and rebuild all changed packges. The owner will update Fedora Quick Docs with the manual how to create the `ipp-usb` quirk and how to disable the device in classic drivers if possible. * Other developers: * Release engineering: * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == `ipp-usb` is incompatible with classic printing and scanning drivers for IPP-over-USB devices, so a manual intervention depending on user's choice is required after upgrade. The steps which users have to do are described below. Choices: # IPP-USB # Classic drivers === Prerequisites: Checking the IPP-over-USB device and its capabilities === * update device's firmware if possible * stop and disable `cups-browsed` service if it is not used for installing printers from remote print server (which means `BrowsePoll <server>` is used in `/etc/cups/cups-browsed.conf`) * check if the device is recognized by `ipp-usb`: <pre> $ sudo ipp-usb check Configuration files: OK IPP over USB devices: Num Device Vndr:Prod Model 1. Bus 001 Device 005 04a9:2823 "Canon MF440 Series" </pre> * if the device has a printing functionality: :* check whether the device is seen by CUPS among existing destinations, but not among installed printers (''Canon_MF440_Series_USB'' is the CUPS temporary queue for IPP-over-USB device called ''Canon MF430''): <pre> $ lpstat -e Canon_MF440_Series_USB Canon_MF440_Series $ lpstat -a Canon_MF440_Series accepting requests since Wed 16 Mar 2022 11:27:02 AM CET </pre> ::'''Note''': If the ''Canon_MF440_Series_USB'' is shown here, but not in your application, report the issue to the application. :* check whether it provides the options you use during printing: <pre> $ ipptool -tv ipp://localhost:60000/ipp/print get-printer-attributes.test $ lpoptions -p Canon_MF440_Series_USB -l </pre> ::'''Note''': `ipptool` command will return all IPP attributes which the device supports - currently common PPD options are generated from some of the attributes, so if your printing option is present in IPP response, but not in `lpoptions` output, then it is a CUPS issue. `lpoptions` returns available PPD options, which are used by print dialogs in most cases. * If the device has a scanning functionality: :* check whether the device is seen by `airscan` backend (the HP LaserJet MFP M130fw device here is used for illustration, it does not show its real IPP-over-USB compatibility or its real options shared via AirScan from `ipp-usb`): <pre> $ scanimage -L ... device `airscan:e0:HP LaserJet MFP M130fw (E700D6)' is a eSCL HP LaserJet MFP M130fw (E700D6) ip=127.0.0.1 </pre> :* check the device capabilities: <pre> $ scanimage --help -d 'airscan:e0:HP LaserJet MFP M130fw (E700D6)' ... Options specific to device `airscan:e0:HP LaserJet MFP M130fw (E700D6)': Standard: --resolution 75|150|200|300|600|1200dpi [300] Sets the resolution of the scanned image. --mode Color|Gray [Color] Selects the scan mode (e.g., lineart, monochrome, or color). --source Flatbed|ADF [Flatbed] Selects the scan source (such as a document-feeder). Geometry: -l 0..215.9mm [0] Top-left x position of scan area. -t 0..297.011mm [0] Top-left y position of scan area. -x 0..215.9mm [215.9] Width of scan-area. -y 0..297.011mm [297.011] Height of scan-area. Enhancement: --brightness -100..100% (in steps of 1) [0] Controls the brightness of the acquired image. --contrast -100..100% (in steps of 1) [0] Controls the contrast of the acquired image. --shadow 0..100% (in steps of 1) [0] Selects what radiance level should be considered "black". --highlight 0..100% (in steps of 1) [100] Selects what radiance level should be considered "white". --analog-gamma 0.0999908..4 [1] Analog gamma-correction --negative[=(yes|no)] [no] Swap black and white ... </pre> * if the device has a fax functionality and user requires it: :* check its capabilities via `ipptool` command: <pre> $ ipptool -tv ipp://localhost:60000/ipp/faxout get-printer-attributes.test </pre> User can see the available printing, scanning and fax capabilities with the commands above and can decide which solution - '''driverless''' or '''classic drivers''' - he wants to use. The recommendation is to use driverless if it provides the set of options required by user - the device is not bound to a driver being available in the distribution and, if mDNS works, the device is automatically installed and no other intervention will be needed in the future, when classic drivers will be covered by printer applications and permanent queues will turn into printer profiles on desktops. === Choice 1: IPP-USB is chosen to support the device === * if the device has a printing functionality: :* Remove any existing printers installed for the device in the past: ::* find out the printer name: <pre> $ lpstat -a Canon_MF440_Series accepting requests since Wed 16 Mar 2022 11:27:02 AM CET </pre> ::* remove the printer: <pre> $ lpadmin -x Canon_MF440_Series </pre> * if the device has a scanning functionality: :* Disable the device in a SANE backend, disable the backend as whole or uninstall the driver: <pre> $ scanimage -L device `hpaio:/usb/laserjet_mfp_m129-m134?serial=XXXX' is a Hewlett-Packard laserjet_mfp_m129-m134 all-in-one device `airscan:e0:HP LaserJet MFP M130fw (E700D6)' is a eSCL HP LaserJet MFP M130fw (E700D6) ip=127.0.0.1 $ sudo sed -i 's,^\s*hpaio$,#hpaio,' /etc/sane.d/dll.d/hpaio # disables backend </pre> * if the device has a fax functionality: :* remove the old fax queue if exists: <pre> $ lpadmin -x <fax_queue> </pre> :* install a new fax queue: <pre> $ lpadmin -p <fax_name> -v ipp://localhost:60000/ipp/faxout -m driverless-fax:ipp://localhost:60000/ipp/faxout -E </pre> After this user is able to send fax via `lp` command and the chosen fax queue. === Choice 2: A classic driver is chosen to support the device === * create a quirk for `ipp-usb`: :* get device's model name: <pre> $ sudo ipp-usb check $ sudo ipp-usb check Configuration files: OK IPP over USB devices: Num Device Vndr:Prod Model 1. Bus 001 Device 005 04a9:2823 "Canon MF440 Series" </pre> :* use the name in new quirk file at `/etc/ipp-usb/quirks` directory. The `.conf` suffix is required. <pre> $ cat /etc/ipp-usb/quirks/canon.conf [Canon MF440 Series] blacklist = true </pre> :* restart `ipp-usb` service: <pre> $ sudo systemctl restart ipp-usb </pre> This quirk will deny device's support in `ipp-usb` and classic drivers will work. == How To Test == USB device capable of supporting IPP-over-USB is required to test this change. `ipp-usb` starts once IPP-over-USB device is connected and then do the following steps: * follow prerequisites mentioned in the [https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency#Upgrade/… Upgrade/compatibility impact] and choose IPP-over-USB support, * open a document in applications you use for printing/scanning/fax * check whether the device is seen in the application (in print dialog, or in scanner list) - if the device is not seen, report the issue to the application's bugzilla component, * check which options are available in the dialog/settings - if some required (for your use cases) options are missing in comparison to `lpoptions` and `scanimage` outputs (details how to find out device's capabilities in [https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency#Upgrade/… Upgrade/compatibility impact]), report the issue to the application's bugzilla component, * try the actions you usually do on your device (print/scan/fax) with your common options set: :* in case of printers and fax if the printout is not in expected format, do report the issue to `cups` bugzilla component together with additional info (described [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-probl… here]), :* in case of problem with scanning output do report the issue to `sane-airscan` bugzilla component together with additional info acquired by following steps from this [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-probl… link], * once you disable the device or backend for scanning, check whether one scanner's disappeared from scanner application's dialog (`simple-scan`, `xsane`, `scanimage`) In case user chooses to have classic driver support instead of driverless because driverless support does not work or it misses some options which user requires, it would be great if the user reported such case by filing an issue to `golang-github-openprinting-ipp-usb` bugzilla component, explaining which required options are missing or whether driverless does not print/scan at all and it will reviewed by the component's maintainer. If the model has the driverless support broken in general, the model can be disabled in `ipp-usb` on system level by quirk, which is located in `/usr/share/ipp-usb/quirks`. Once the quirk is set and `ipp-usb` restarted, previously installed printers and scanners will work as before - the printing/scanning/fax will end with error otherwise. == User Experience == A new printer and a new scanner will appear in applications and settings for IPP-over-USB devices by default. Previously installed printer and discovered scanner for the device will stop working and manual intervention is required to remove the broken instances, or to create a quirk for `ipp-usb`. == Dependencies == == Contingency Plan == * Contingency mechanism: N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == * Printing and scanning [https://docs.fedoraproject.org/en-US/quick-docs/cups-terminology/ terminology] * [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-printing-probl… Printing] debugging * [https://docs.fedoraproject.org/en-US/quick-docs/how-to-debug-scanning-probl… Scanning] debugging * [https://docs.fedoraproject.org/en-US/quick-docs/cups-useful-tricks/ Tips and tricks] * [https://docs.fedoraproject.org/en-US/quick-docs/cups-known-issues/ Known issues] == Release Notes == Driverless USB printing/scanning/fax support is present by default with printing and scanning packages, providing the support for devices capable of using IPP-over-USB. The manual intervention is required after upgrade, which is described [https://fedoraproject.org/wiki/Changes/IPPUSBasPrintScanDependency#Upgrade/… here]. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

5 9

IMA testing, Re: Fedora Linux 37 Beta Released
by Frank Ch. Eigler 18 Feb '23

18 Feb '23

bcotton wrote: > [...] > ## Beta Release Highlights > [...] > # RPM content is now signed with IMA signatures How can one observe this? Even with rpm-plugin-ima installed, steps in: https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents#How_To_Test produce no output for any of the files I tried in a f37-beta install. The appropriate "publiccert.der" file does not seem to be available either. - FChE

3 2

Willing to unretire package: rust-starship
by Mauricio Teixeira 18 Feb '23

18 Feb '23

Hello folks, Following up on the steps provided by the documentation [1], I would like to announce that I am willing to unretire the package rust-starship [2]. I use this app on a daily basis, and it seems like the previous maintainer is no longer interested in keeping the package, so I would like to take over the ownership. I will follow up on the remaining steps within the next few hours. Please, let me know if there is anything else I should know about. Thank you. [1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement… [2] https://src.fedoraproject.org/rpms/rust-starship

5 7

Fedora 38 mass rebuild is finished
by Tomas Hrcka 17 Feb '23

17 Feb '23

Hi all, Per the Fedora Linux 38 schedule[1] we started a mass rebuild for Fedora Linux 38 on 1. 18, 2023. We did a mass rebuild for Fedora 38 for: https://fedoraproject.org/wiki/Changes/Add_FORTIFY_SOURCE%3D3_to_distributi… https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer https://fedoraproject.org/wiki/Changes/GNUToolchainF38 As per the maintainer's request[4] we have skipped all Haskell packages from this rebuild. The mass rebuild was done in a side tag (f38-rebuild) and moved over to f38. Failures can be seen at https://kojipkgs.fedoraproject.org/mass-rebuild/f38-failures.html Things still needing rebuilding https://kojipkgs.fedoraproject.org/mass-rebuild/f38-need-rebuild.html 20996 builds have been tagged into f38, there are currently 840 failed builds that need to be addressed by the package maintainers. FTBFS bugs will be filed shortly. Please be sure to let releng know if you see any bugs in the reporting. You can contact releng in #fedora-releng on libera.chat, by dropping an email to our list[2], joining #releng:fedoraproject.org on Matrix, or filing an issue in pagure[3] Regards, Tomas Hrcka Fedora Release Engineering [1] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/ [3] https://pagure.io/releng/ [4] https://pagure.io/releng/issue/11217 _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

21 42

SPECfiles - conditionals with EOLed Fedora releases - any value in keeping them ?
by Michal Schorm 16 Feb '23

16 Feb '23

Hello, While playing around with Sourcegraph, which indexed all Fedora package repositories, I was able to craft a query listing all '%if' conditionals referencing Fedora releases that reached EOL. https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraprojec… I don't believe such conditions have any value and I think we can remove them right away. I think the removal shouldn't affect neither Fedora nor derived operating systems. If removed, they will be preserved in the git history anyway, for anyone seeking historical code. In some cases the conditionals hold patches that could be removed with them: https://sourcegraph.com/search?q=context:global+repo:%5Esrc%5C.fedoraprojec… -- Do you agree it would be safe to remove such conditionals and the code they hold ? Do you agree that removing obsolete code such as this brings value to the package codebase ? Would you see a value in e.g. some kind of a robot reminding maintainers of such obsolete code? (e.g. new RPMinspect or ZUUL CI check) Michal -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat --

10 13

Small rant: installer environment size
by Adam Williamson 14 Feb '23

14 Feb '23

Hi folks! Today I woke up and found https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me down a bit of an "installer environment size" rabbit hole. As of today, with that new dep in webkitgtk, Rawhide's network install images are 703M in size. Here's a potted history of network install image sizes: Fedora Core 8: 103.2M (boot.iso 9.2M + stage2.img 94M) Fedora 13: 208M Fedora 17: 162M (last "old UI") Fedora 18: 294M (first "new UI") Fedora 23: 415M Fedora 28: 583M Fedora 33: 686M Fedora 37: 665M Fedora Rawhide: 703M The installer does not really do much more in Rawhide than it did in FC8. Even after the UI rewrite in F18, we were only at 294M. Now the image is well over 2x as big and does...basically the same. Why does this matter? Well, the images being large is moderately annoying in itself just in terms of transfer times and so on. But more importantly, AIUI at least, the entire installer environment is loaded into RAM at startup - it kinda has to be, we don't have anywhere else to put it. The bigger it is, the more RAM you need to install Fedora. The size of the installer environment (for which the size of the network install image is more or less a perfect proxy) is one of the two key factors in this, the other being how much RAM DNF uses during package install. So, I did a bit of poking about into *what* is taking up all that space. There's a variety of answers, but there's two major culprits: 1. firmware 2. yelp (which pulls in webkitgtk and its deps) I've been using du and baobab (the GNOME visual disk usage analyzer, which is great) to examine the filesystems, but I ran a couple of test builds to confirm these suspects, especially after the impact of compression (it's hard to check the *compressed* size of things in the installer environment directly). I did a scratch build of lorax which does not pull in firmware packages, and had openQA build a netinst using that lorax. It came out at 489M - 214M smaller than current netinsts, a size we last managed in Fedora 26. I did a scratch build of anaconda with its requirement of yelp dropped (which would break help pages), and built a netinst with that; it came out at 662M - 41M smaller than current images. I haven't run a combined test yet, but it ought to come out around 448M, around the size of Fedora 24. Even then we'd still be about 50% larger than the Fedora 18 image, for not really any added functionality. I've moaned about the sheer amount and size of firmware blobs in other forums before, but 214M compressed is *really* obnoxious. We must be able to do something to clean this up (further than it's already cleaned up - this is *after* we dropped low-hanging fruit like enterprise switch 'firmwares' and garbage like that; most of the remaining size seems to be huge amounts of probably-very-similar firmware files for AMD graphics adapters and Intel wireless adapters). I know some folks were trying to work on this (there was talk that we could drop quite a lot of files that would only be loaded by older kernels no longer in Fedora); any news on how far along that effort is? Other obvious things that take up a lot of space: 1. /usr/lib/locale/locale-archive , from glibc-all-langpacks - this is 224M uncompressed. A quick test just compressing the file with xz on my system shows it compresses to around 11M, though, so that's probably all it adds up to after compression (the image is an xz-compressed squashfs) 2. /usr/lib64/libLLVM-15.so, which is 114M on its own, compresses to 23M. We are, I think, basically stuck with this for mesa-dri-drivers , but does it have to be so *big*? 3. libicudata.so.71.1 - 30.4M, compresses to 7M. This is in the webkitgtk dep chain but seems to still be pulled in without it, not sure what else is requiring it. 4. /usr/share/locale - 112M in total (uncompressed, not sure how much compressed) of translated strings from a ton of packages. No idea how many of these are really *needed* in the installer environment. We can maybe come up with a way to have lorax strip some, if we can come up with a viable way to figure out which. Obviously-fairly-large ones are from gnupg2 and libgweather4. I do recall we have some logic somewhere to decide which languages have a certain level of translation in anaconda; perhaps we could only include the strings for these languages? -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

26 105

← Newer
1
2
3
4
5
6
7
8
...
30
Older →

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 January 2023