devel March 2023

devel@lists.fedoraproject.org

156 participants
287 discussions

Outage Notification - 2009-07-01 01:00 UTC
by Mike McGrath 24 Aug '23

24 Aug '23

There will be an outage starting at 2009-07-01 01:00 UTC, which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2009-07-01 01:00 UTC' Affected Services: Buildsystem CVS / Source Control Unaffected Services: Database DNS Fedora Hosted Fedora People Fedora Talk Mail Mirror System Torrent Translation Services Websites Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/1496 Reason for Outage: Final migration step for new cvs server. It will hopefully be offline for only 30-45 minutes. The additional time is for some further tuning if needed and some verification steps. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. _______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce

2 1

Thoughts welcome: interface between automated test gating and the "critical path"
by Adam Williamson 16 Aug '23

16 Aug '23

Hi folks! I have one of those definitional quandaries and I figured I'd throw it at the lists for some input. Right now, we kind of take advantage of the "critical path" concept for automated update testing and gating via openQA. openQA does not test all updates, only critical path updates plus updates containing any package on a short allowlist. Bodhi and Greenwave do not gate all updates on the openQA tests since not all updates are tested; again we use the critpath definition. If an update is critical path, it gets gated on the openQA tests. If it isn't, it doesn't. If you've been paying attention, that means there's a bit of a hole: the packages on the 'allowlist'. These are tested, but not gated. What's on the allowlist? Basically, FreeIPA-related packages. We have a good set of FreeIPA tests in openQA, and both I and the FreeIPA team wanted relevant updates to be tested with them. But those packages are not on the critical path. So I set up this 'allowlist' mechanism. However, the lack of gating kinda sucks. I would much prefer if we could gate these updates as well as just testing them. The obvious thing to do is add the FreeIPA-related packages to the critical path, but that really is not supported by the critical path definition: https://fedoraproject.org/wiki/Critical_path_package which defines it as packages required to "perform the most fundamental actions on a system", with a list of specific areas, none of which is "run a domain server". So...what to do? I can think of I guess four options: 1. Broaden the definition of the "critical path" somehow. We could just write in that it includes FreeIPA functionality, I guess, though that seems special purpose. We could broaden it to include any functionality covered by the release criteria, which would be quite a big increase but seems like a reasonable and concise definition. Or we could write in that it includes any functionality that is exercised by the gating openQA tests, though that seems a bit arbitrary - there's no particularly great organizing principle to the openQA tests we choose to run on updates, if I'm honest, it's a sort of grab bag I came up with. 2. Keep the current "critical path" concept but define a broader group of "gated packages" somewhere (could be comps or somewhere else). This would require engineering work - we'd have to touch probably the openQA scheduler, Bodhi, and greenwave configs. It's also another maintenance burden. 3. Add gating config to each allowlisted package repo's gating.yml one by one. I don't really like this option. It'd be a chunk of work to do initially, and multiples the maintenance required when the list of tests to gate on changes for some reason. 4. Do nothing, just keep only gating things that are "critical path" on the current definition. In a utopian future, we'd manage to deploy openQA in the cloud or get a giant pile of super fast servers so we could test and gate *every* update, and this wouldn't be an issue any more. What do folks think? Any preferences? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

10 22

Packaging a cross-compilation environment (wasi-libc)
by Jan Staněk 10 Aug '23

10 Aug '23

Hi list, in order to be able to compile WASM natively on Fedora, I'm trying to package wasi-libc[1] to provide the Web Assembly System Interface. [1]: https://github.com/WebAssembly/wasi-libc My trouble is that this is in essence a cross-compilation environment, and I have zero experience in trying to package these. Also, I did not have much luck in trying to find any related documentation. Some issues I have run into so far: - This is a libc implementation, which would probably conflict with the glibc package by default. Looking at musl, the solution seems to be to install into `/usr/{target}` prefix (i.e. `/usr/wasm32-wasi/include`). Not really sure how this works, any pointers appreciated. - Clang seems to have issue with `-fstack-clash-protection` flag for the `wasm32-wasi` target. What's the proper way to adjust these? Any additional tips on cross-compilation support in Fedora would also be appreciated :) Thanks in advance for any help! -- Jan Staněk Software Engineer, Red Hat jstanek(a)redhat.com irc: jstanek

8 15

libarrow (Apache Arrow) soname bump in Rawhide
by Kaleb Keithley 26 Jul '23

26 Jul '23

Hi, Apache Arrow 10.0.0 has been released. At present nobody is using libarrow except Ceph. (Which I am the maintainer of.) I will be rebasing libarrow to 10.0.0 within the next couple of days. -- Kaleb

4 7

Proposal: drop delta rpms (for real this time)
by Matthew Miller 04 Jul '23

04 Jul '23

I was asked to weigh in on https://pagure.io/releng/issue/7215 as a priority. Last time we talked about this we didn't really get anywhere... https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… ... and that ticket hasn't moved, because fixing it isn't trivial. What we're doing now — as has been the case for several years, already noted in the previous discussion — has very little end-user value. Also as noted in that thread (as in the ticket)... that's unfortunate, because it did bring some real benefits (and could possibly do even more.) But, I think it's time to move on. We have ostree and various container-delta approaches. We should focus on those — and give DeltaRPMs a sad, fond farewell. -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

32 77

F36 Change: Default To Noto Fonts (System-Wide Change proposal)
by Ben Cotton 01 Jul '23

01 Jul '23

https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts == Summary == Changing the default fonts for various languages to Noto Fonts as much as possible, to make consistency on the text rendering. == Owner == * Name: [[User:Tagoh|Akira TAGOH]] * Email: <tagoh(a)redhat.com> == Detailed Description == For a long time we have used DejaVu fonts as the default font for European and other language scripts. On the other hand some language scripts are not covered by DejaVu and hence have other default fonts. (A few languages like Chinese, Japanese and Korean, as well as Gurmukhi, Sinhala, and emoji are already using Noto fonts by default for some time.) This situation leads to inconsistencies in text rendering on applications and desktops, particularly when mixing different character sets. Further Noto fonts bring some further advantages: the fonts are generally higher quality and support variable fonts for most scripts, making them more compact. This change aims to provide better experience and consistent text rendering across more languages by replacing DejaVu with Noto as the general system default set of fonts. The following packages will be installed by default to replace DejaVu's coverage: * google-noto-sans-vf-fonts * google-noto-serif-vf-fonts * google-noto-sans-mono-vf-fonts * google-noto-sans-arabic-vf-fonts * google-noto-sans-cherokee-vf-fonts * google-noto-sans-thaana-vf-fonts * google-noto-sans-hebrew-vf-fonts * google-noto-rashi-hebrew-vf-fonts * google-noto-sans-math-vf-fonts * google-noto-sans-armenian-vf-fonts * google-noto-serif-armenian-vf-fonts * google-noto-sans-canadian-aboriginal-vf-fonts * google-noto-sans-georgian-vf-fonts * google-noto-serif-georgian-vf-fonts * google-noto-sans-lao-vf-fonts * google-noto-serif-lao-vf-fonts * google-noto-serif-gurmukhi-vf-fonts * google-noto-serif-sinhala-vf-fonts And you can check [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table] to see what languages will be affected by this change. == Benefit to Fedora == We would get better text rendering on applications and desktops. Also this change should save about 6MB on the fresh install. <pre> $ rpm -qlv dejavu-sans-fonts dejavu-serif-fonts dejavu-sans-mono-fonts | awk 'BEGIN{a=0}{a+=$5}END{print a}' 10789272</pre> <pre> $ rpm -qlv google-noto-sans-vf-fonts google-noto-serif-vf-fonts google-noto-sans-mono-vf-fonts google-noto-sans-arabic-vf-fonts google-noto-sans-cherokee-vf-fonts google-noto-sans-thaana-vf-fonts google-noto -sans-hebrew-vf-fonts google-noto-rashi-hebrew-vf-fonts google-noto-sans-math-vf-fonts google-noto-sans-armenian-vf-f onts google-noto-serif-armenian-vf-fonts google-noto-sans-canadian-aboriginal-vf-fonts google-noto-sans-georgian-vf-f onts google-noto-serif-georgian-vf-fonts google-noto-sans-lao-vf-fonts google-noto-serif-lao-vf-fonts google-noto-serif-gurmukhi-vf-fonts google-noto-serif-sinhala-vf-fonts | awk 'BEGIN{a=0}{a+=$5}END{print a}' 4753340 </pre> == Scope == * Proposal owners: ** Update google-noto-fonts and dejavu-fonts to change the priority for fontconfig config. ** Update langpacks to update the dependency. ** Update comps to make Noto fonts default. ** Update lorax templates related to DejaVu. ** Update fontconfig to change the order of fonts in the builtin config. * Other developers: ** Packagers who owns packages implicitly expects DejaVu is installed by default will needs to update the dependency for them. * Release engineering: [https://pagure.io/releng/issue/10492 #10492] * 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 == The migration will be done by updating langpacks. after upgrading and rebooting, the default font will be Noto instead of DejaVu. Since this change aims to switch non-variable fonts to variable fonts, it may not works with legacy applications as expected such as missing some variants. in that case, you can install non-variable fonts packages. the package name will be similar and simply drop `-vf` from the variable fonts packages. == How To Test == * This change can be simply tested by `fc-match` command like `fc-match sans:lang=<your langauge>`, `fc-match serif:lang=<your language>` and `fc-match monospace:lang=<your language>`. You can check the expected result from [https://tagoh.fedorapeople.org/fonts/noto/f36-noto.html the table]. * Test the text rendering in your favorite application, which use the system default font. == User Experience == Users will see the default font is changed to Noto by this change except for some languages which has much better quality of fonts. == Dependencies == Only dejavu-fonts, langpacks, and fontconfig are required to update. Other packages which explicitly has a dependency to dejavu-fonts are basicaly optional to update. == Contingency Plan == * Contingency mechanism: Revert the relevant packages updated. * Contingency deadline: Beta freeze * Blocks release? No == Documentation == None. == Release Notes == The default fonts for most languages will be Google Noto fonts instead of DejaVu, to keep consistency on the text rendering and to provide better quality among languages. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

12 22

JPEGXL SONAME Bump
by Robert-André Mauchin 19 Jun '23

19 Jun '23

Hello everyone, I am planning a soname bump of jpegxl to 0.8.1 next week Saturday the 25th. Some of you will be affected by these changes. Fedora side we have: geeqie gthumb seamonkey vips I can take care of these one as a PP in a side tag RPMFusion side, the following packages are affected: libheif xine-lib I would like to have RPMFusion maintainers help to be able to update them in a RPMFusion side tag too. I will specify to you when the Fedora side tag has been merged. Hopefully, with your cooperation, everything will go smoothly. Please send any question you may have regarding this change. Thanks to everyone! Best regards, Robert-André (eclipseo)

7 12

Plan / proposal: enable openQA update testing and potentially gating on Rawhide updates
by Adam Williamson 18 Jun '23

18 Jun '23

Hi folks! We've had openQA testing of updates for stable and branched releases, and gating based on those tests, enabled for a while now. I believe this is going quite well, and I think we addressed the issues reported when we first enabled gating - Bodhi's gating status updates work more smoothly now, and openQA respects Bodhi's "re-run tests" button so failed tests can be re-triggered. A few weeks ago, I enabled testing of Rawhide updates in the openQA lab/stg instance. This was to see how smoothly the tests run, how often we run into unexpected failures or problems, and whether the hardware resources we have are sufficient for the extra load. So far this has been going more smoothly than I anticipated, if anything. The workers seem to keep up with the test load, even though one out of three worker systems for the stg instance is currently out of commission (we're using it to investigate a bug). We do get occasional failures which seem to be related to Rawhide kernel slowness (e.g. operations timing out that usually don't otherwise time out), but on the whole, the level of false failures is (I would say) acceptably low, enough that my current regime of checking the test results daily and restarting failed ones that don't seem to indicate a real bug should be sufficient. So, I'd like to propose that we enable Rawhide update testing on the production openQA instance also. This would cause results to appear on the Automated Tests tab in Bodhi, but they would be only informational (and unless the update was gated by a CI test, or somehow otherwise configured not to be pushed automatically, updates would continue to be pushed 'stable' almost immediately on creation, regardless of the openQA results). More significantly, I'd also propose that we turn on gating on openQA results for Rawhide updates. This would mean Rawhide updates would be held from going 'stable' (and included in the next compose) until the gating openQA tests had run and passed. We may want to do this a bit after turning on the tests; perhaps Fedora 37 branch point would be a natural time to do it. Currently this would usually mean a wait from update submission to 'stable push' (which really means that the build goes into the buildroot, and will go into the next Rawhide compose when it happens) of somewhere between 45 minutes and a couple of hours. It would also mean that if Rawhide updates for inter-dependent packages are not correctly grouped, the dependent update(s) will fail testing and be gated until the update they depend on has passed testing and been pushed. The tests for the dependent update(s) would then need to be re- run, either by someone hitting the button in Bodhi or an openQA admin noticing and restarting them, before the dependent update(s) could be pushed. In the worst case, if updated packages A and B both need the other to work correctly but the updates are submitted separately, both updates may fail tests and be blocked. This could only be resolved by waiving the failures, or replacing the separate updates with an update containing both packages. All of those considerations are already true for stable and branched releases, but people are probably more used to grouping updates for stable and branched than doing it for Rawhide, and the typical flow of going from a build to an update provides more opportunity to create grouped updates for branched/stable. For Rawhide the easiest way to do it if you need to do it is to do the builds in a side tag and use Bodhi's ability to create updates from a side tag. As with branched/stable, only critical path updates would have the tests run and be gated on the results. Non-critpath updates would be unaffected. (There's a small allowlist of non-critpath packages for which the tests are also run, but they are not currently gated on the results). I think doing this could really help us keep Rawhide solid and avoid introducing major compose-breaking bugs, at minimal cost. But it's a significant change and I wanted to see what folks think. In particular, if you find the existing gating of updates for stable/branched releases to cause problems in any way, I'd love to hear about it. Thanks folks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

6 14

Future of BIOS RAID support in the installer
by Vojtech Trefny 17 Jun '23

17 Jun '23

Hi, I am planning to change how we support BIOS RAID (sometimes also called Firmware or Fake RAID) in the installer in the future. I plan to go through the official Fedora change process for Fedora 38, but I'd like to get some feedback first. We are currently using dmraid to support these types of RAIDs in blivet[1] (storage library the Anaconda installer uses) and we would like to replace it with mdadm. The main reason is that dmraid is no longer actively maintained, but it will also mean one less dependency for the installer (we use mdadm for the software RAID support) and one less service running during boot (dmraid-activation.service). The potential issue here is that mdadm doesn't support all BIOS RAID types. mdadm supports only Common RAID Disk Data Format standard[2] (DDF) and Intel Matrix Storage Technology (IMSM) so by switching to mdadm we would remove support for some of the older formats that existed before DDF was standardized. I am not sure how many people are still using these older RAIDs and the main reason for sending this email is to find out. So if you are using a BIOS RAID on your system, can you check what kind? You can find out simply by checking the filesystem type on the underlying disk(s) reported by for example `lsblk -f`. Types supported by mdadm are "ddf_raid_member" and "isw_raid_member". Types supported only by dmraid are "adaptec_raid_member", "hpt***_raid_member", "jmicron_raid_member", "lsi_mega_raid_member", "nvidia_raid_member", "silicon_medley_raid_member" and "via_raid_member". So if you have one of the latter ones and you'd be impacted by this change, please let me know so we can reconsider this change. Note that this would affect only the installation process, I know some external and NAS drives use BIOS RAID and these won't be affected, dmraid is not being removed from the repositories (at least I am not aware of this right now, some distributions are already planning to remove dmraid completely). [1] https://github.com/storaged-project/blivet [2] https://www.snia.org/tech_activities/standards/curr_standards/ddf Regards Vojtech Trefny vtrefny(a)redhat.com

4 3

RISC-V -- are we ready for more, and what do we need to do it?
by Matthew Miller 11 Jun '23

11 Jun '23

Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk. In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck). So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that. But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time? * see http://fedora.riscv.rocks/koji/ -- Matthew Miller <mattdm(a)fedoraproject.org> Fedora Project Leader

20 40

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