devel July 2023

devel@lists.fedoraproject.org

210 participants
230 discussions

CVE: Python-twisted a.o. needs update for F37 due to matrix-synapse security issue
by Marius Schwarz 31 Aug '23

31 Aug '23

Hi, due to an outdated(afaik) python-twisted version, it's not possible to build matrix-synapse in version 1.8x . Unlucky for all F37 users, matrix-synpase has 3 embargoed CVEs coming, which need fixing asap. As "releng" has shipped the last twisted update, I have no clue who could help here on the python side and upgrade the packages. Kai Hiller tries to cherry pick the required patches for synapse, but it would of course be better to build the newest synapse version for F37 too. ATM we can only workaround this by using the f38 packages for synapse and it's dependencies. AFAICT it's works without issues atm. This brings me to the question: whats the main issue for twisted here? best regards, Marius Schwarz

3 3

Intern Introduction & Goals (Open 3D Engine)
by Nicholas Frizzell 30 Aug '23

30 Aug '23

Hello, My name is Nicholas and I'm working this summer as an intern with Red Hat. My primary objective this summer is to improve support for the O3DE project (https://www.o3de.org/) in Fedora and eventually have it packaged and available for install through the official repositories. If anyone is interested in this topic or has any advice/suggestions to help this project along feel free to reach out.

3 3

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

RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism
by Fabio Valentini 17 Aug '23

17 Aug '23

Hi all, I'm opening this thread to trigger discussion of the roadmap for DNF5 in Fedora 39 - whether the switch still looks doable for this release, or whether it should be reverted for F39 and postponed to F40. This is also being tracked in a FESCo ticket: https://pagure.io/fesco/issue/3039 The DNF5 Change was approved with the condition that bits that are important to the distribution *MUST* work, but this does not seem to be the case yet, six months after this was initially approved - there's at least a few things that are still using dnf-3 or have been broken since the switch to dnf5: - rawhide mock / koji builds still default to dnf-3 (DNF 4) - Fedora CI has been partially broken since the switch to DNF5 (c.f. [fedora-ci/general#416](https://pagure.io/fedora-ci/general/issue/416)), making CI results for bodhi updates at least partially useless - fedora-review has been broken since the switch to DNF5 (c.f. [FedoraReview#482](FedoraReview/issue/482)), which is really hurting the rate at which new packages are getting reviewed and added to Fedora - (not an exhaustive list, feel free to mention other things, I will update the list to include them) We are now mere days before the Fedora 39 mass rebuild is scheduled to start, so I think it's time to start talking about the roadmap for getting missing pieces into place for Fedora 39, or if that is not possible within this timeframe, whether the contingency mechanism should be enacted. Fabio

16 27

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

F39 Change Proposal: Retire Modularity (Self Contained)
by Aoife Moloney 09 Aug '23

09 Aug '23

https://fedoraproject.org/wiki/Changes/RetireModularity 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 == Fedora will discontinue building [https://docs.fedoraproject.org/en-US/modularity/ modules] for Fedora Linux 39 and further in the Fedora infrastructure and shipping modular content to users. The fedora-repos-modular and fedora-repos-rawhide-modular packages will be retired and obsoleted. The modular repositories will no longer be composed. Once Fedora Linux 38 reaches the end of life, Fedora's [https://mbs.fedoraproject.org/ Module Build Service] will be terminated. Whether or not dnf(5) would still support modularity from 3rd party repository is out of the scope of this proposal. == Owner == * Name: [[User:Churchyard|Miro Hrončok]] * Name: [[User:Mcurlej|Martin Čurlej]] * Name: [[User:Ppisar|Petr Písař]] * Email: mhroncok(a)redhat.com, mcurlej(a)redhat.com, ppisar(a)redhat.com == Detailed Description == === Motivation === There are very few modules left in Fedora, nobody is developing modularity anymore and there is an everlasting infrastructure problem with building modules. Similarly to retiring a package that has no maintainers, we are retiring Modularity from Fedora, because it has no maintainers. The latest noticeable activity in [https://pagure.io/modularity pagure.io/modularity] was 3+ years ago. === What will happen === # After Fedora Linux 38 branches from Rawhide, we will disable building modules for Rawhide and future Fedora Linux 39 and later. # We will work with Release Engineering to disable composing of modular repositories, F39 Modular updates in Bodhi etc. # The fedora-repos-modular and fedora-repos-rawhide-modular subpackages of fedora-repos will be removed and obsoleted by fedora-repos and fedora-repos-rawhide. # Once Fedora Linux 38 reaches end of life, we will retire the Fedora instance of [https://mbs.fedoraproject.org/ Module Build Service]. === What might or might not happen === Whether or not the package manager in Fedora Linux (dnf and/or dnf5) will support modular repositories created by 3rd parties is not decided in this change proposal. It is up to the dnf maintainers to make this decision and we intentionally want to make the scope of this proposal as limited as possible. === For maintainers of modules === Please retire your modules appropriately, so users are migrated to suitable non-modular content. If you wish to continue shipping multiple different versions or editions of your packages, please follow [https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple '''Multiple packages with the same base name'''], as was [https://docs.fedoraproject.org/en-US/modularity/policies/#_requirements_for… a recommendation of the policy for many years]. == Feedback == === What will be offered as a replacement === We have been asked internally at Red Hat, what will be offered to users of Fedora Linux if we retire modularity. While we encourage anyone to share ideas they might have on the topic, we intentionally offer no ''new'' alternative to modularity as part of this change proposal. Replacing the retired modularity with something else is intentionally out of scope of this proposal. == Benefit to Fedora == Packager and Infra/Releng resources will not be wasted on Modularity. Instead, we can focus on delivering quality content to our users without it. == Scope == * Proposal owners: ** Work with releng to disable modular builds in f39+ ** Work with releng to disable composing and mirroring of modular repos for f39+ ** Work with Bodhi admins to disable F39+ Modular updates ** Submit changes to fedora-repos package to remove and obsolete the modular subpackages ** (once f38 is EOL) Work with infra to sunset MBS * Other developers: ** Modular packagers: *** Retire your modules *** Ideally package the content as nonmodular * Release engineering: [https://pagure.io/releng/issue/11480 #11480] ** Disable modular builds in f39+ ** Disable composing and mirroring of modular repos for f39+ * Policies and guidelines: N/A (not needed for this Change)  * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == An RPM scriptlet fedora-release might be necessary to deactivate all Fedora-provided modular streams when upgrading to Fedora Linux 39 and 40. This will only happen if all other means of properly EOLing the modules still block upgrades. == How To Test == === Has this landed? === # Check if fedora-repos-modular and fedora-repos-rawhide-modular are missing from the repository and Obsoleted. # Check if the modular repositories are missing from download.fedoraproject.org and mirrormanager. === Does it work? === # Check if upgrading from Fedora Linux 37/38 to 39/40 with enabled modular streams (from the Fedora repos) is still possible. == User Experience == Users of Fedora Linux 39+ will no longer have access to the Fedora modular repos. They can still install non-modular packages instead. == Dependencies == * [[Changes/FlatpaksWithoutModules]] * [[Changes/No_default_fedora-repos-modular]] == Contingency Plan == * Contingency mechanism: Revert the changes * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == Ideally, all references to Fedora-provided modular streams should be removed from docs.fedoraproject.org, except for docs.fedoraproject.org/en-US/modularity which should be clearly marked as obsolete/archived. == Release Notes == Users of Fedora Linux 39+ will no longer have access to the Fedora modular repos. They can still install non-modular packages instead. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

3 2

RFC authselect: mdns or mdns-minimal
by Pavel Březina 08 Aug '23

08 Aug '23

Hi Fedora, I have this ticket opened against authselect: https://github.com/authselect/authselect/issues/334 I am not user of mdns myself, so I wonder if non-minimal version of mdns is something used and if it should be included in the authselect profiles (or even replace the minimal version). mdns support is already complicated since there are mdns, mdns4 and mdns6 full and minimal versions of the module. Is it really required nowadays? In might opinion, it might be good to move the logic out of nsswitch into a configuration file. Thank you for your feedback, Pavel.

5 15

Restricting automounting of uncommon filesystems?
by Matthew Garrett 07 Aug '23

07 Aug '23

A discussion within Debian again brought up the problem that: 1) Automounting of removable media exposes the kernel to a lot of untrusted input 2) Kernel upstream are not terribly concerned with ensuring that kernel filesystems are resilient against deliberately malformed filesystems so are mostly not proactively looking for bugs there 3) Uncommonly used filesystems are less likely to be tested against adverse input in the real world and so are more likely to contain exploitable bugs There are various cases where people do need to make use of uncommon filesystems, but the majority of them aren't related to removable media. udisks2 supports setting the UDISKS_AUTO variable to 0 on devices that shouldn't be automounted, which means something like: SUBSYSTEM!="block", GOTO="udisks_insecure_fs_end" ENV{ID_FS_TYPE}=="hfs", ENV{UDISKS_AUTO}="0" # repeat as necessary for anything else that shouldn't be automounted LABEL="udisks_insecure_fs_end" ought to be enough. So: a) Does this seem like a good idea? b) If so, is dealing with it via udev rules the right approach? This way seems desktop-agnostic c) Where should it ship, and what should the process be for disabling it for people who need this functionality? Long-term I'd love to see more work put into having FUSE support for these and leaving the in-kernel fs to stuff we know is trustworthy, but that's rather more work.

18 38

Summary/Minutes from today's FESCo Meeting (2023-07-27)
by Tom Stellard 07 Aug '23

07 Aug '23

===================================== #fedora-meeting-2: FESCO (2023-07-27) ===================================== Meeting started by tstellar at 17:00:28 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2023-07-27/fesco.2023-07… . Meeting summary --------------- * init process (tstellar, 17:01:13) * #3039 RFC: Roadmap for DNF5 in Fedora 39 / invoking the Contingency Mechanism (tstellar, 17:04:33) * AGREED: APPROVED(+7,0,-0) The switch to DNF5 will be postponed (likely to Fedora 41, to be determined by the Change Owners) and reverted in Rawhide for the time being (i.e. dnf 4 will provide /usr/bin/dnf again). (tstellar, 17:27:21) * #3035 Change: Build JDKs once, repack everywhere (tstellar, 17:28:30) * AGREED: APPROVED(+5,0,-3) (tstellar, 17:43:10) * Next week's chair (tstellar, 17:45:22) * ACTION: decathorpe will chair next meeting (tstellar, 17:48:46) * Open Floor (tstellar, 17:48:56) * ACTION: nirik will update fesco meeting location in the calendar. (tstellar, 17:59:50) Meeting ended at 18:01:04 UTC. Action Items ------------ * decathorpe will chair next meeting * nirik will update fesco meeting location in the calendar. Action Items, by person ----------------------- * decathorpe * decathorpe will chair next meeting * nirik * nirik will update fesco meeting location in the calendar. * **UNASSIGNED** * (none) People Present (lines said) --------------------------- * tstellar (53) * decathorpe (37) * nirik (32) * mhroncok (29) * dcantrell (18) * zodbot (16) * Eighth_Doctor (14) * jmracek (12) * sbueno (5) * sgallagh (4) * salimma (1) * zbyszek (0) * mhayden (0) * Conan_Kudo (0) * Pharaoh_Atem (0) * Son_Goku (0) * King_InuYasha (0) * Sir_Gallantmon (0) Generated by `MeetBot`_ 0.4

5 5

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel July 2023