devel

devel@lists.fedoraproject.org

123 participants
62520 discussions

Userspace VT consoles in copr
by Jocelyn Falempe 23 Apr '25

23 Apr '25

Hi, I've packaged 3 userspace consoles, on my copr repository for Fedora. They can replace fbcon (The default kernel-based console), have more features (like scrolling) and are more secure as they run in userspace. * Kmscon: https://copr.fedorainfracloud.org/coprs/jfalempe/kmscon/ * Cage/foot or Gnome-kiosk/Ptyxis: https://copr.fedorainfracloud.org/coprs/jfalempe/Userspacevt/ You can follow the instructions to install one of them, and set it as your default console for testing. You won't be able to launch a graphic environment from there (like startx) but you can still restart your main graphic environment if it has crashed. Also this won't replace the emergency console if there is an issue in your ramdisk, or to prompt for the disk encryption password (if not using plymouth). The long-term goal would be to deprecate fbcon, and use drm_log and userspace consoles to achieve a similar user experience, so that's a first step in that direction. Best regards, -- Jocelyn

4 18

Non-responsive maintainer check for dledford
by Davide Cavalca 23 Apr '25

23 Apr '25

Hi all, does anybody know how to contact Doug Ledford (FAS: dledford) ? I was about to needinfo https://bugzilla.redhat.com/show_bug.cgi?id=2321324 and that's when I noticed the account seems to be deactivated in Bugzilla, but they're listed as the primary maintainer for several packages: https://src.fedoraproject.org/user/dledford/ Cheers Davide

10 12

RFC: Lightweight stalled request process
by Michel Lind 23 Apr '25

23 Apr '25

Dear all, Over the past months FESCo has been considering my proposal to have a lighter weight process to get needed changes for Fedora packages (whether getting a PR merged and built, or a package branched, etc.) - since the alternatives up to now is just pinging a PR or bugzilla issue, or escalating and getting the maintainer declared non responsive. We think we have a suggested process that would work well - thank you to everyone in the committee for their inputs - but would like to get community feedback on this, since we’re only human and there might be something we miss. Hopefully this balances out the need to get fixes in, with not bypassing maintainers’ concerns (or surprising them with a fait accompli if they’re on vacation, busy at a conference, etc.). But please chime in and let us know of any improvement we can make to this before it lands. https://pagure.io/fesco/fesco-docs/pull-request/94 This is also cross-posted to Discourse: https://discussion.fedoraproject.org/t/rfc-lightweight-stalled-request-proc… Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

4 6

f42: hostname vs. sendmail (vs. systemd depsolver) bug?
by Gabriel Somlo 23 Apr '25

23 Apr '25

Trying to figure out what component to file this under, or whether I'm "in luck" and this is already a known problem and I can just add myself to the cc list... :) I have a f42 machine with a static DHCP lease and a DNS A record associated with its statically-leased IP address. When I boot the machine and immediately log into it via ssh, running `hostname` will keep returning "fedora" for 5-10 seconds, before starting to return the FQDN (e.g. "FOO.EXAMPLE.COM") if I keep retrying the `hostname` command. In the mean time, `sendmail.service` throws its hands up and enters "failed" state, complaining about "My unqualified host name (fedora) unknown; sleeping for retry", then eventually failing with a timeout. If I then restart `sendmail.service` (via `systemctl restart ...`), it works fine (now that `hostname` or whatever *it* talks to on the back end is finally caught up). I'm wondering what chain of dependencies is being missed, maybe systemd's `sendmail.service` should wait for whatever provides the host name (or maybe the latter should be part of whatever target sendmail.service already depends on, etc.)... Any advice on how to further debug this, or a BZ ticket ID for the already known bug would be much appreciated! Thanks, --Gabriel

9 13

lazy preemption mode is enabled in Fedora starting with kernel 6.14
by Chris Murphy 23 Apr '25

23 Apr '25

CONFIG_PREEMPT_LAZY=y has been enabled in Fedora's 6.14 kernel for x86 and riscv. I'm uncertain about the availability for other archs. This applies to all Fedora variants. Fedora 42 shipped with kernel 6.14. And it's currently in the updates-testing repo for Fedora 40 & 41. Note also that CONFIG_PREEMPT_DYNAMIC=y is also still enabled so users can still enable a preemption mode more suitable for their use case. Use grubby to add one of the following kernel parameters. preempt=none preempt=voluntary preempt=full e.g. # grubby --args="preempt=full" --update-kernel=ALL For those who have been using a kernel parameter to set a preemption mode, nothing will change unless you remove the kernel parameter in which case you will get lazy preemption. If you wish to test or revert to lazy preemption mode, also use grubby. e.g. # grubby --remove-args="preempt=full" --update-kernel=ALL See also: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… -- Chris Murphy

1 0

F43 Change Proposal: Modular GnuPG packaging (self-contained)
by Aoife Moloney via devel-announce 23 Apr '25

23 Apr '25

Wiki - https://fedoraproject.org/wiki/Changes/Modular_GnuPG_Packaging Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-modular-gnupg-pa… This is a proposed Change for Fedora Linux. 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 == Currently GnuPG is packaged in a way that puts almost all tools and services into a single, monolithic RPM package. However, only few tools from the gnupg2 package are actually used by other tools and users. With this change, core tools and optional utilities are split off into separate packages. == Owner == * Name: [[User:Decathorpe| Fabio Valentini]] * Email: <decathorpe AT gmail DOT com> * Name: [[User:Jjelen| Jakub Jelen]] * Email: <jjelen AT redhat DOT com> == Detailed Description == Currently GnuPG is packaged as a monolithic RPM that contains all tools and services (except the S/MIME support, which is in gnupg2-smime, but which is also pulled in by default). This Change proposes to split the tools provided by the monolithic gnupg2 package into different subpackages, in part based on in how GnuPG 2.4 is packaged in debian: * gnupg2: gpg executable * gnupg2-dirmngr: certificate management service * gnupg2-g13: encrypted file system containers * gnupg2-gpgconf: core configuration utilities * gnupg2-gpg-agent: cryptographic agent * gnupg2-keyboxd: public key material service * gnupg2-scdaemon: SmartCard daemon * gnupg2-smime: S/MIME support * gnupg2-wks: Web Key Service (WKS) client and server * gnupg2-utils: non-essential utilities * gnupg2-verify: gpgv executable By default, all new subpackages except those for WKS client/server (`-wks`) will get installed when gnupg2 is installed -- with non-essential utilities in `-utils` being a weak dependency, like the existing S/MIME `-smime` package. This results in fewer unused programs and / or services being installed and running, and would allow a more minimal install for scenarios where only `gpg` or `gpgv` are needed, for example, for signature verification during package builds. Additionally, it allows swapping out the actual GnuPG implementation with the one based on Sequoia-PGP, which only depends on `gpgconf` and `gpg-agent` being present, but can otherwise function as a drop-in replacement for `gpg` and `gpgv` (even via the GPGME library). Draft implementation of this change is available in pull request: https://src.fedoraproject.org/rpms/gnupg2/pull-request/23 Test builds are available in COPR: https://copr.fedorainfracloud.org/coprs/decathorpe/gnupg2-split/ == Feedback == N/Y == Benefit to Fedora == This change results in fewer unused executables and running services being installed by default, making more components optional. It also allows users to swap the gpg implementation on the system based on their needs. == Scope == * Proposal owners: Packaging changes to the `gnupg2` package to introduce new subpackages. Adapt packages that require utilities that have moved to other subpackages of gnupg2 (TBD), file pull requests. * Other developers: Review and merge pull requests. * Release engineering: N/A (not a System-Wide Change) * Policies and guidelines: N/A (not a System-Wide Change) * Trademark approval: N/A * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == On upgrade to Fedora 43, some non-essential GnuPG utilities will no longer be available by default, and instead moved to the optional `gnupg2-g13`, `gnupg2-utils`, and `gnupg2-wks` packages. Alternatively, these optional packages could get pulled in on upgrade, but not for "fresh" installs. == How To Test == After upgrading to a Fedora version that has this change implemented, most `gnupg2-` subpackages should get installed, except for those noted in "Upgrade/compatibility impact" above. OpenPGP related functionality of the system should continue working as expected (note that this does *not* impact package management, which no longer uses GnuPG in any way). == User Experience == This Change should not affect most users. On a default install, some non-essential GnuPG tools will no longer be included by default. == Dependencies == N/A == Contingency Plan == * Contingency mechanism: The Change Owners will revert the changes to the gnupg2 package and ensure an upgrade path for users who have already have the new subpackages installed on their systems. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == The previously monolithic GnuPG package (`gnupg2`) was modularized, with several tools and non-essential utilities having been split into separate subpackages. The non-essential utilities (in `gnupg2-utils`) and some services that are unused on most systems are no longer installed by default. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ 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

5 10

Summary/Minutes from today's FESCo Meeting (2025-04-22)
by Michel Lind 23 Apr '25

23 Apr '25

Meeting summary --------------- * TOPIC: Init Process (@salimma:fedora.im, 17:01:08) * TOPIC: #3385 Change: Java25 And No More System JDK (@salimma:fedora.im, 17:06:18) jvanek, the Change Proposal author, attended to answer questions. FESCo's concern is that the Change Proposal is confusing for us to read as is, and will probably also be confusing to Fedora users. Apart from clarifying questions we ask during the meeting, we agree to ask follow up questions in the Discourse discussion for this change: https://discussion.fedoraproject.org/t/f43-change-proposal-java25-and-no-mo… pboy agreed to help updating the Java packaging guidelines which will hopefully help clarify things as well. * TOPIC: #3391 Exemption for deprecated Aspell dependency (@salimma:fedora.im, 17:57:06) * ACTION: decathorpe to file a PR with FPC (@decathorpe:fedora.im, 18:01:04) * TOPIC: #3388 DOCUMENTATION_URL is 404 (@salimma:fedora.im, 18:01:39) There is no ideal solution at the moment, so the agreed action explicitly states that this is a stop-gap solution * AGREED: APPROVED (+9, 0, -0) Set DOCUMENTATION_URL to https://docs.fedoraproject.org/en-US/fedora/fNN/ This link SHOULD be available at the launch of GA, but if it's delayed, it does not block release. This link will be updated to the same document, but using a language-aware link once that becomes available (@salimma:fedora.im, 18:29:24) * ACTION: sgallagh will update the DOCUMENTATION_URL in os-release (@salimma:fedora.im, 18:29:43) * TOPIC: Open Floor (@salimma:fedora.im, 18:29:49) * ACTION: zbyszek will merge https://pagure.io/fesco/fesco-docs/pull-request/100 (@salimma:fedora.im, 18:34:56) * ACTION: https://pagure.io/fesco/fesco-docs/pull-request/101 will be closed as it lacks support (@salimma:fedora.im, 18:37:31) * LINK: https://discussion.fedoraproject.org/t/rfc-lightweight-stalled-request-proc… (@salimma:fedora.im, 18:40:31) * ACTION: salimma will follow up on the mailing list questions and then rebase the PR and address any additional comments later this week (@salimma:fedora.im, 18:51:11) * TOPIC: next chair (@salimma:fedora.im, 18:51:24) * ACTION: fale will chair next meeting (@salimma:fedora.im, 18:53:30) Meeting ended at 2025-04-22 18:53:51 Action items ------------ * decathorpe to file a PR with FPC * sgallagh will update the DOCUMENTATION_URL in os-release * zbyszek will merge https://pagure.io/fesco/fesco-docs/pull-request/100 * https://pagure.io/fesco/fesco-docs/pull-request/101 will be closed as it lacks support * salimma will follow up on the mailing list questions and then rebase the PR and address any additional comments later this week * fale will chair next meeting People Present (lines said) --------------------------- * @salimma:fedora.im (155) * @jvanek:matrix.org (100) * @nirik:matrix.scrye.com (76) * @sgallagh:fedora.im (76) * @decathorpe:fedora.im (67) * @zbyszek:fedora.im (36) * @zodbot:fedora.im (30) * @conan_kudo:matrix.org (27) * @pboy:fedora.im (19) * @fale:fale.io (10) * @emma:rory.gay (7) * @meetbot:fedora.im (3) * @dcantrell:fedora.im (3) * @brakoose:matrix.org (2) * @humaton:fedora.im (2) Full minutes available at https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2025-04-… Best regards, -- _o) Michel Lind _( ) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 README: https://fedoraproject.org/wiki/User:Salimma#README

4 3

rpm-ostree/bootc uid/gid drift problem
by Zbigniew Jędrzejewski-Szmek 23 Apr '25

23 Apr '25

Hi folks, [I'm writing this on Colin's suggestion, to introduce more people to the discussion and hopefully get some new ideas how to solve the problem. Apologies for the length.] The problem: when packages have files owned by a user or group that are part of the package contents ("owned files" for short), and the uid/gid is allocated dynamically [1], the uid/gid can change between builds of an image from that package ("uid/gid drift") and then in a deployment, after an upgrade, the numeric uid/gid that is stored in the local system database might be different then the numer used in the image, causing files to be owned by the wrong user/group. This was a known problem for rpm-ostree systems, and was handled ad-hoc when problems were reported, but is becoming a bigger problem for bootc systems. There are a few options possible: avoid using any "owned files" in packages, use tmpfiles.d to adjust ownership dynamically, switch back to soft-static uid/gid assignments, completely change how we do deployments, stop upgrading image-based deployments… We need to do _something_, but it's not clear at this point what the best course of action is. ** Details of the problem ** I know the summary above is dense. Let's go through an example: - Package opencryptoki defines group pkcs11. This group uses "dynamic allocation", i.e. the specific numeric gid is selected when the package is installed, taking the first unused number. - The package has a file in the %files payload owned by the group: %attr(,,pkcs11) /etc/opencryptoki/strength.conf - When an rpm-ostree or bootc image is built with this package, the accounts are created in the local user/group database and some numeric uids/gids are selected, for example 999. The filesystem stores ownership as numbers, so that gid is used for /etc/opencryptoki/strength.conf in the filesystem. - The user makes a deployment using this image; in the local installation the gid is used for /etc/opencryptoki/strength.conf. - A new version of the rpm-ostree or bootc image is built, but this time numeric uids/gids are different, e.g. we get 998 for pkcs11. - The user upgrades, and the file in the image is owned by a gid that maps to a different group in the local database or to no group and is listed as unowned. Note that the package installation order is deterministic and stable. So when we rebuild an image with the same package set, we're always going to get the same numeric uids/gids. But we can get different assignments if the package installation order changes, for example because of some dependency change, or more/less packages are installed, or when one of the packages defines a new user/group. In general, we can expect the uid/gid assignments to change regularly. The consequences of such wrong ownership can vary: in the most benign case this is just a cosmetic issue in 'ls' output. The case that is actually reported by users is when the service fails to start because it cannot access some file. But then there's also some silent group of cases where the wrong ownership creates a security vulnerability or an information leak. This problem exists primarily in "image-based" deployments. In traditional "package-based" deployments, uids/gids might be assigned differently between systems, but on a given installation, the uid/gid assignment remains stable. The problem only appears when the local user database is wiped between image builds. This problem is now primarily visible for rpm-ostree and bootc, but would appear also for any image-based system where the image is built "remotely" (with a independent user/group database, even if the build happens on the same machine), and the creation of local system accounts is allowed. One example is ParticleOs [6], where this issues is solved by _not_ allowing any "owned files" in the image and using tmpfiles.d snippets instead. "Owned files" also create a problem for image *building*, if this is done unprivileged. Mkosi [7] makes 'chown' a noop during unprivileged image builds, which means that "owned files" in the image don't work, files end up being owned by root. ** UID/GID assignment strategies ** See [1] for a longer discussion, but the tl;dr is that we used to assign uids/gids statically, but moved to dynamic assignment about 15 years ago. The uid/gid range for system accounts is limited, nowadays 1-999, in the past 1-499, but we still support upgraded systems with the old range. Above that range, we have "user accounts", starting at 1000 (or 500 on old systems). Soft-static uids/gids are taken from the bottom of this range, while dynamic uids/gids are taken from the top. Accounts can be created by packages, but also by the local admins. See [3] for the list of current assignments. The "soft" part in soft-static is because we never override a uid/gid that was assigned locally. Thus if the local admin either used a uid/gid for a different purpose, or created the user/group with a different uid/gid than our allocation, we honour that. The soft-static allocations are needed for the case where the assignment is shared between systems. In the past this was used with some file sharing protocols like nfs/ceph/gluster, where some files owned by the system user or group would be shared on the network. But nowadays the is mostly used for the initrd: files in /dev or /run are owned by various groups to provide unprivelged access, and then after the transition to the host system, those file systems are moved over, so we need to maitain stability of uids/gids. In F42+ we have changed the user creation *mechanism* from traditional scriptlets which called useradd/groupadd/usermod/groupmod/gpasswd to declarative sysusers.d files, which are then executed by calling systemd-sysusers [4]. This changes the mechanism, but doesn't change the problem with uid/gid drift. systemd-sysusers intentionally implements the same soft-static and dynamic allocation strategies described in [1]. Arguably, the biggest change is increased visibility. We have 372 unique names in sysusers files in packages in Fedora rawhide (for users or groups), and 163 static allocations in setup. ** Potential solutions ** Please note that for the problem to manifest, two conditions are necessary: the uid/gid must use dynamic allocation, and the package must have "owned files". (Files owned by the user/group but created after installation are not a problem.) Thus the first solution is not to have any owned files. This is the recommended approach. It also aligns nicely with the "hermetic /usr" initiative, where packages only contain files under /usr. Those files must be treated as immutable, and it doesn't make sense for them not to be publicly readable, so naturally they are not owned. It also aligns nicely with unprivileged builds. (rpm-ostree/bootc docs recommend systemd's DynamicUser=true. Those users are created at runtime with no fixed uid/gid assignement and packages which use such users cannot have any owned files. This obviously solves the problem too.) A second "solution" is to keep files "unowned", i.e. owned by root in the package payload, but chown them at runtime after installation. This can be implemented fairly easily using tmpfiles.d. But it's actually quite a bit of work and bother to do correctly. The initial ownership must be by root, so that the file does not appear with a "wrong" uid/gid after initial installation. Then the ownership needs to be adjusted before the service is started, i.e. the service must be ordered after a systemd-tmpfiles run. We call systemd-tmpfiles via a filetrigger, so normally the case where the package is installed on a running system would be handled correctly, i.e. the files would be correctly owned after dnf finishes. But this is still fairly fragile. The third solution is to use soft-static assignment. The most recent example of a package where this was added for the purposes of rpm-ostree is polkit. In principle we have some space: there aren't that many packages with owned files, so we could add static assignments for those packages. Apart from the problem of potentially exhausting the available range, soft-static assignments are not great also because they require bureaucracy and coordination between different setup and various maintainers. This would be a big change to the existing policy and would require quite a bit of work to implement and would be of no benefit to users of package-based systems. Upgraded systems would not get the new assignments, so we would not be able to rely on the new static allocations. Nevertheless, even if we were to switch to soft-static allocations for packages, soft-static assignment cannot cover users created by non-distro packages and outside of packages. With bootc, it is easy for a user to create some user or group in the image (via 'RUN groupadd -r foo' or by installing some 3rd-party package). So this becomes a bigger problem then previously, see [5]. In fact, we'd probably need to convert _all_ distro packages to soft-static allocation, so that those uids/gids are taken from the bottom of the range, to keep the top of the range clear for unassigned allocations by users using bootc. Even then, users would need to carefully maintain the order of operations in their image definitions to avoid uid/gid drift. In the past I suggested some solution where the user/group database would be kept betwen rpm-ostree builds. We might have been hard but feasible for rpm-ostree, where builds were done in our infra, but it's not even feasible for bootc, with many uncoordinated definitions. We could also consider some bigger changes, like not using numeric uids/gids for bootc images, and making the assignment only during installation, similarly to how rpm does this… At this point, I think the approach of combining the first two solutions, i.e. minimizing the number of "owned files" and judiciously using tmpfiles.d to adjust ownership at runtime is a feasible and relatively painless option. To solve the problems for rpm-ostree/bootc, we'd need to make this into an official policy and adjust some packages. Comments/ideas? [1] https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/#_… [2] https://github.com/uapi-group/specifications/issues/76 [3] https://src.fedoraproject.org/rpms/setup/blob/rawhide/f/uidgid [4] https://fedoraproject.org/wiki/Changes/RPMSuportForSystemdSysusers [5] https://issues.redhat.com/browse/RHEL-77146 [6] https://github.com/systemd/particleos [7] https://github.com/systemd/mkosi

6 15

Inactive packagers removal for the F42 release cycle
by Mattia Verga via devel-announce 23 Apr '25

23 Apr '25

In accordance with FESCo's Inactive Packager Policy[1], packagers that have been identified as inactive during the F42 development cycle have been submitted for being removed from the packagers group. [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ For the curious, here are the stats from today's run: ### Pagure returned 103 users to check a second time and 7 users ready for removal ### ### These users agreed to be removed from packagers: ### - arnd - brenton - davanum - deekej - jfsaucier - mkosek - terrycloth ### These 92 users didn't reply and are going to be removed from packagers: ### - acui - adobes - affix - aglitke - ajmitchell - akasko - alphacc - astepano - bilelmoussaoui - brouhaha - bskeggs - chedi - cooperlees - dachary - damien-lemoal - davem - davidx - dcbw - diaasami - djuran - dlehman - dmurphy18 - dprince - dwysocha - edward-evans-aiven - ellio167 - fsimonce - gtiwari - hanoglu - hguemar - icon - ikedas - irina - jkaluza - jlanda - joev - jolsa - jsafrane - juergh - kasong - ksiddiqu - labbott - lchilton - lkiesow - lucab - lucarval - lucilanga - lupinix - major - malmond - mangelajo - markuss - martstyk - mcbeeffx - murphyp - nickboldt - nim - nkondras - nyoxi - phuzion - pmyers - poros - psalaba - puiterwijk - quintela - ravindrakumar - rerickso - reznik - rlescak - rpeterso - saakla - scoady - sdyroff - sfroemer - shoracek - snecker - spotlesstofu - stbenjam - szidek - tlavocat - toshio - totol - victortyau - vishalvvr - vmakarov - vponcova - yahmad - yashn - yizhengxie - yunyings - zaitcev - zvetlik ### These 4 users resumed activity: ### - jschmidb - kanitha - law - siddharthvipul1 -- _______________________________________________ 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

3 3

[Fedocal] Reminder meeting : ELN SIG
by yselkowitz＠fedoraproject.org 23 Apr '25

23 Apr '25

Dear all, You are kindly invited to the meeting: ELN SIG on 2025-04-24 from 15:00:00 to 16:00:00 US/Eastern At meeting(a)fedoraproject.org The meeting will be about: Source: https://calendar.fedoraproject.org//meeting/11018/

1 0

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