devel January 2024

devel@lists.fedoraproject.org

163 participants
245 discussions

Enabling GOPROXY and GOSUMDB in Fedora
by Alejandro Saez Morollon 14 Jul '24

14 Jul '24

Hi everyone. TL;DR: Remove a patch we ship in Go that disables GOPROXY and GOSUMDB and follow upstream defaults, or keep it? Recently, I had a short conversation in a public forum about two Go features that we modified in Fedora. GOPROXY and GOSUMDB. As I prepare the Fedora 40 and Go 1.22 proposal, it is a great time to discuss it. You can see the conversation here, I think they bring really good points that we should consider: https://mas.to/@zekjur/111359951465906642 So first, what are these variables? - GOPROXY sets the server for fetching module-related information and dependencies. - GOSUMDB sets the checksum database URL to verify module downloads and ensure their integrity during module resolution. You can read them more in detail here: - https://go.dev/ref/mod#environment-variables - https://go.dev/ref/mod#authenticating - https://go.dev/ref/mod#module-proxy There are four approaches as I see this: 1. Keep it the way it is right now. 2. Remove the patch and follow upstream. 3. Create a way to ensure the users know that that option can be changed and leave one of the two previous options as default (by creating two packages, one with the default setting and another that applies the patch). 4. Have a GOPROXY service by Fedora. 1 and 2 are the easiest and most logical ones. 3rd is complex, and I'm not sure it brings any value. 4th would be ideal, but that means maintaining a service with all its costs and time.

10 12

Remove old GPG keys?
by Miroslav Suchý 25 Jun '24

25 Jun '24

I just stumbled upon https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-remov… with the nice link to: https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-from… And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we automate the removal of old keys? Mirek

16 30

F35 Change: Debuginfod By Default (Self-Contained Change proposal)
by Ben Cotton 05 Jun '24

05 Jun '24

https://fedoraproject.org/wiki/Changes/DebuginfodByDefault == Summary == Fedora users / developers who need to debug/trace distro binaries can make use of the recently activated elfutils-debuginfod servers to automatically fetch debugging data and source code, instead of having to use `# sudo dnf` commands. == Owner == * Name: [[User:fche| Frank Ch. Eigler]] * Email: fche(a)redhat.com == Detailed Description == Numerous fedora debugging-type tools have built-in capabilities to use the [https://sourceware.org/elfutils/Debuginfod.html debuginfod] protocol to fetch debuginfo/source code automatically. We would like to activate a setting so that Fedora's debuginfod servers are automatically used, rather than requiring hand-editing individual users' dot files. == Feedback == There has existed [https://www.spinics.net/lists/fedora-devel/msg279002.html broad interest] in a Fedora debuginfod server since the project was proposed / announced in 2020, and several distros already operate public servers of this nature. Some of the distros configure their installations by default to talk to those servers, some do not. Turning on this by default has some limited privacy implications. Some Debian users have [https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed concerns] that this facility "calls home" during debugging, so it may expose a limited amount of information about what a user is debugging. The information is limited to the build-id and source code file names of programs being debugged, and is only sent to the servers if their machine lacks locally installed debuginfo. Whether this should be opt-in or opt-out and how has been resolved there via an install-time query to the sysadmin. In contrast, on OpenSUSE Tumbleweed, it is [https://build.opensuse.org/request/show/879926 simply defaulted-on], and we have heard of no controversy. We anticipate discussing this topic on the mailing list, and noting it in the release notes either way. == Benefit to Fedora == This will improve developers' experience. It may reduce download server burden, as only individual ELF/DWARF/source files are downloaded rather than entire `-debuginfo` and `-debugsource` RPMs. It would help Fedora catch up to other distros who put up `debuginfod` servers already. :-) == Scope == * Proposal owners: The work could consist one extra parameter in the `elfutils.spec` `%configure`. Its effect is to arrange for the `elfutils-debuginfod-client` RPM to install an `/etc/profile.d` file that sets the `DEBUGINFOD_URLS` environment variable automatically to `https://debuginfod.fedoraproject.org/`. (At the time of this writing, the _staging_ server is getting ready for testing: `https://debuginfod.stg.fedoraproject.org/`.) * Other developers: None - relevant code has been previously upstreamed! * Release engineering: None - our team is operating the `debuginfod[.stg].fedoraproject.org` VMs. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == None. Note that these servers index all active Fedora releases (32-), all architectures, so users of those versions can already set `DEBUGINFOD_URLS` manually to take advantage. == How To Test == * Install `elfutils-debuginfod-client` * Open arbitrary fedora binary via gdb. ** Admire the immediate downloading of debuginfo and source code. * Run `eu-stack -v -p $pid` for an arbitrary process. ** Admire the immediate downloading of debuginfo to give precise file:line data. == User Experience == Primarily: users running debuggers, profilers, tracing tools on internet-capable machines can work immediately, without switching to privileged users and fragile manual `dnf` commands to install this data. == Dependencies == The `debuginfod` servers at `fedora-infra` need to be up. == Contingency Plan == * Contingency mechanism: change the elfutils-debuginfod-client subrpm to not set the default `DEBUGINFOD_URLS` environment variable for all users. In the case of a server outage, the debugger tools revert to debuginfo-less operation, prior to this feature. * Contingency deadline: shortly before freeze * Blocks release? No == Documentation == There is upstream documentation in the debugging tools as well as associated with the client code / cli tooling. What our Release Notes would focus on however is the _automatic activation_ of this facility via the environment variable. == Release Notes == TBD. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis

16 43

future of dual booting Windows and Fedora, redux
by Chris Murphy 28 May '24

28 May '24

Summary: Windows 10/11 increasingly enables Bitlocker (full disk encryption) out of the box with the encryption key sealed in the TPM. Two different issues result: 1. Fedora's installer, Anaconda, can't resize Bitlocker volumes. We could use better documentation to help the user perform the volume resize in Windows, before proceeding to booting our installation media. The documentation probably should be explicitly referenced by the Windows version of Fedora Media Writer. 2. The Bitlocker encryption key is unsealed only if the boot chain measurement by the TPM matches the expected values in a TPM PCR. When shim+GRUB are in the boot chain, as is the case in our default dual boot installation, the measurements are wrong, and this means the GRUB menu entry to boot Windows won't work. The user is dropped to a Windows Bitlocker recovery page. If they have their backup encryption key handy, it will work but to say the least this condition is unexpected and not user friendly - not least of which is many users won't have this backup key handy since they didn't take the action to enable Bitlocker in the first place. The bug report for this is https://bugzilla.redhat.com/show_bug.cgi?id=2049849 It was a Fedora 36 final release blocking bug, but considered a "difficult to fix" exceptional case, moving it to Fedora 37 final. Some of the options for consideration: a. Fix GRUB by giving it the ability to modify UEFI NRAM "bootnext" value, so that instead of chainloading the Windows bootloader from GRUB, GRUB will modify the system NVRAM such that the next boot (only) will directly boot the Windows bootloader. Thus far there's no interest by GRUB upstream. Whereas systemd-boot has implemented it. b. Add a user space utility modifies system NVRAM such that the next boot (only) will directly boot the Windows bootloader. And also remove the Windows boot entry in GRUB, on UEFI systems. (It would be retained on BIOS systems.) c. Change the release criterion. https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Windows_dua… Current: The installer must be able to install into free space alongside an existing clean Windows installation and install a bootloader which can boot into both Windows and Fedora. Replacement: The installer must be able to install into free space alongside an existing clean Windows installation, install and configure a bootloader that will boot Fedora. d. Consider the problem sufficiently difficult to fix that we need an extension to the exceptional case allowance, and wave the bug for another release. Thoughts? -- Chris Murphy

29 93

F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
by Aoife Moloney 19 Apr '24

19 Apr '24

Important process note: we are experimenting with using Fedora Discussion as part of the Changes process. Change announcements (like the one you are reading right now) will still be sent to the devel-announce mailing list, but the conversation about each change will take place on Fedora Discussion at https://discussion.fedoraproject.org/t/f40-change-request-privacy-preservin… This will follow the same process as before, just with discussion in a different format https://docs.fedoraproject.org/en-US/program_management/changes_policy/ You can subscribe to and interact with these conversations by email. See https://discussion.fedoraproject.org/t/guide-to-interacting-with-this-site-… for detailed instructions. To make sure you do not miss anything, make sure that you have the Change Proposal category set to “Watching” — or, if you just want to get notified about new changes but not every reply in the conversation, to “Watching First Post”. (Click on the little bell icon at the top right of the category page.) The below 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 == The Red Hat Display Systems Team (which develops the desktop) proposes to enable limited data collection of anonymous Fedora Workstation usage metrics. Fedora is an open source community project, and nobody is interested in violating user privacy. We do not want to collect data about individual users. We want to collect only aggregate usage metrics that are actually needed to achieve specific Fedora improvement objectives, and no more. We understand that if we violate our users' trust, then we won't have many users left, so if metrics collection is approved, we will need to be very careful to roll this out in a way that respects our users at all times. (For example, we should not collect users' search queries, because that would be creepy.) We believe an open source community can ethically collect limited aggregate data on how its software is used without involving big data companies or building creepy tracking profiles that are not in the best interests of users. Users will have the option to disable data upload before any data is sent for the first time. Our service will be operated by Fedora on Fedora infrastructure, and will not depend on Google Analytics or any other controversial third-party services. And in contrast to proprietary software operating systems, you can redirect the data collection to your own private metrics server instead of Fedora's to see precisely what data is being collected from you, because the server components are open source too. Keep in mind this Fedora change proposal is just that: a proposal. It must undergo community review and must be approved by the community-elected Fedora Engineering Steering Committee (FESCo) before it can be implemented, just like any other Fedora change proposal. We welcome community participation and fully expect this proposal may need to be modified significantly depending on Fedora community feedback. == Owner == * Name: [[User:catanzaro|Michael Catanzaro]] * Email: <mcatanzaro(a)redhat.com> == Detailed Description == We intend to deploy the Endless OS metrics system. [https://blogs.gnome.org/wjjt/2023/07/05/endless-oss-privacy-preserving-metr… This blog post] contains a description of how the system works. We do not plan to deploy the eos-phone-home component in Fedora. === How will data collection be approved? === The proposal owners feel it is essential to ensure the Fedora community has ultimate oversight over metrics collection. Community control is required to maintain user trust. If this change proposal is approved, then we'll need new policies and procedures to ensure community oversight over metrics collection and ensure Fedora users can be confident that our metrics collection does not violate their privacy. We can say "we would never collect personally-identifiable data" and write software that really doesn't collect any such data, but this alone will never be enough to ensure user confidence. We will need a metrics collection policy that describes what sort of data may be collected by Fedora (anonymous, non-invasive), and what sort of data may not be collected. Such a policy does not exist currently. We will also want to ensure the Fedora community has ultimate control over which particular metrics are collected. One option is that each metric to be collected should be separately approved by FESCo. Collection of particular metrics in a particular data format is ultimately an engineering decision, and therefore FESCo seems like an appropriate approval point. Because FESCo members are elected regularly by the Fedora community, this also provides the community with ultimate control over metrics collection via the election process. But other oversight and approval structures would work too. === What data might we collect? === We are not proposing to collect any of these particular metrics just yet, because a process for Fedora community approval of metrics to be collected does not yet exist. That said, in the interests of maximum transparency, we wish to give you an idea of what sorts of metrics we might propose to collect in the future. One of the main goals of metrics collection is to analyze whether Red Hat is achieving its goal to make Fedora Workstation the premier developer platform for cloud software development. Accordingly, we want to know things like which IDEs are most popular among our users, and which runtimes are used to create containers using Toolbx. Metrics can also be used to inform user interface design decisions. For example, we want to collect the clickthrough rate of the recommended software banners in GNOME Software to assess which banners are actually useful to users. We also want to know how frequently panels in gnome-control-center are visited to determine which panels could be consolidated or removed, because there are other settings we want to add, but our usability research indicates that the current high quantity of settings panels already makes it difficult for users to find commonly-used settings. Metrics can help us understand the hardware we should be optimizing Fedora for. For example, our boot performance on hard drives dropped drastically when systemd-readahead was removed. Ubuntu has maintained its own readahead implementation, but Fedora does not because we assume that not many users use Fedora on hard drives. It would be nice to collect a metric that indicates whether primary storage is a solid state drive or a hard disk, so we can see actual hard drive usage instead of guessing. We would also want to collect hardware information that would be useful for collaboration with hardware vendors (such as Lenovo), such as laptop model ID. Other Fedora teams may have other metrics they wish to collect. For example, Fedora localization wishes to count users of particular locales to evaluate which locales are in poorer shape relative to their usage. This is only a small sample of what we might want to know; no doubt other community members can think of many more interesting data points to collect. But note the purpose of all of the above metrics is to inform specific design decisions, not to build tracking profiles. We only need to collect data in aggregate, and have no need to associate the data we collect with particular users. === Metrics transparency === Transparency is required to provide confidence that Fedora metrics collection is not creepy or invasive. Since Fedora is open source, a developer can review the source code to verify exactly what it is doing and what data is being collected. But most Fedora users are not software developers, and few software developers have time or inclination to review the source code of the operating system to see what it is doing. To retain user trust, we need an easy way for users to understand exactly what data we are collecting. We propose to maintain a documentation page showing the current metrics database schema, so users can see exactly which fields are in the database and what example data looks like. Experienced users may gain additional confidence by building and running their own metrics collection server; all of the components of the server (discussed below) are open source, and we will provide instructions for how to run a simple server yourself and view its metrics database. You can redirect metrics from Fedora's server to your own by changing a URL in a configuration file. === User control === A new metrics collection setting will be added to the privacy page in gnome-initial-setup and also to the privacy page in gnome-control-center. This setting will be a toggle that will enable or disable metrics collection for the entire system. We want to ensure that metrics are never submitted to Fedora without the user's knowledge and consent, so the underlying setting will be off by default in order to ensure metrics upload is not unexpectedly turned on when upgrading from an older version of Fedora. However, we also want to ensure that the data we collect is meaningful, so gnome-initial-setup will default to displaying the toggle as enabled, even though the underlying setting will initially be disabled. (The underlying setting will not actually be enabled until the user finishes the privacy page, to ensure users have the opportunity to disable the setting before any data is uploaded.) This is to ensure the system is opt-out, not opt-in. This is essential because we know that opt-in metrics are not very useful. Few users would opt in, and these users would not be representative of Fedora users as a whole. We are not interested in opt-in metrics. To make this a little more confusing, metrics collection is actually separate from uploading. Collection is always initially enabled, while uploading is always initially disabled. The graphical toggle enables or disables both at the same time. That is, a newly-installed Fedora system will always collect metrics locally at first, but the collected metrics will be deleted and never submitted to Fedora if the user disables the metrics collection toggle on the privacy page. If the user leaves the toggle enabled, then the collected metrics may be submitted only after finishing the privacy page. Metrics uploading will be opt-in for users who upgrade from previous versions of Fedora Workstation, because we don't yet have a mechanism to ask the user to consent to data collection after a system upgrade like we do for new installations, but metrics collection will be opt-out. That is, your upgraded system will collect metrics locally but will never submit them to Fedora. If you visit the privacy page in gnome-control-center, then both collection and uploading will be either enabled or disabled depending on the user's selection. Unlike gnome-initial-setup, the switch in gnome-control-center will default to off if the user has not seen the switch in gnome-initial-setup and has not previously selected a value for the setting. This might sound complicated, but it is consistent. If the user has not yet made a decision whether to allow telemetry, we collect it locally so that it's ready to submit if the user approves telemetry in the future, but we never upload it. Once the user makes a decision, then we either upload it or delete it and stop collecting. === GDPR === It is Fedora Legal's obligation to ensure our data collection complies with legal requirements in the jurisdictions in which Red Hat operates. This is not an obligation of the Fedora community, so there is no need to discuss GDPR rules on our mailing lists. The proposal owners will not respond to mailing list posts that discuss GDPR or similar legal obligations during this change proposal discussion. In short, let's keep discussion focused on what Fedora SHOULD or SHOULD NOT do, rather than what we MUST or MUST NOT do. That said, Fedora Legal has determined that if we collect any personally-identifiable data, the entire metrics system must be opt-in. Since we are only interested in opt-out metrics due to the low value of opt-in metrics, we must accordingly never collect any personally-identifiable data. We must also not collect any data that could become personally-identifiable if combined with other data, which notably means IP addresses must not be stored. We only want to collect anonymous data anyway, but we need to be especially mindful of the possibility that combining two "anonymous" data points could result in the data no longer being anonymous. === Fedora data collection policy === Fedora Legal requires that we publish a Fedora data collection policy separate from the existing [https://fedoraproject.org/wiki/Legal:PrivacyPolicy Fedora Privacy Policy], which is designed to address usage of Fedora websites. This is currently a work in progress that we're not quite ready to share yet. You can expect it to be very short and very generic. === Metrics server infrastructure === We propose to deploy Azafea, the open source metrics collection server used by Endless OS. An Azafea deployment consists of five components: an nginx proxy server, [https://github.com/endlessm/azafea-metrics-proxy azafea-metrics-proxy], redis, [https://github.com/endlessm/azafea azafea itself], and a Postgres database. nginx proxies HTTP requests to azafea-metrics-proxy, which is itself a simple HTTP server that adds metrics into the redis database, where they will be fetched by Azafea and stored into Postgres. We will provide instructions on how to set up your own server and see for yourself what data gets collected. === Metrics client infrastructure === The client side consists of [https://github.com/endlessm/eos-metrics eos-metrics], [https://github.com/endlessm/eos-event-recorder-daemon eos-event-recorder-daemon], and [https://github.com/endlessm/eos-metrics-instrumentation eos-metrics-instrumentation]. eos-metrics is a D-Bus interface that applications and services may use to record events, plus a GObject library that provides a simple API around the D-Bus interface. eos-event-recorder-daemon is the service that actually implements this interface: it collects incoming metrics, batches them together, and sends them to the metrics server at predefined intervals. eos-metrics-instrumentation is the component that actually collects specific metrics. Originally, we had planned to not use this component and instead write our own fedora-metrics-instrumentation that would collect only a few particular metrics that are approved via Fedora community process. However, currently we are planning to ship eos-metrics-instrumentation and instead ensure that it is not collecting more metrics than would be acceptable to the Fedora community. A review process to decide which metrics to collect and which metrics to disable will be required. === Data set considerations === Although we assume the metrics server administrator is not malicious and will not actively attempt to deanonymize users, we will still take reasonable precautions to make it difficult to correlate metrics to a particular user, starting by not storing any IP address information in the metrics database. Additionally, each metric that we collect will be considered individual, non-correlatable data by default, unless approved to be correlated with particular other metrics via future Fedora community process. That is, if a user submits two data points, we usually don't want the ability to know that these data points were both submitted by the same user. Each metric is stored in the database with a Unix timestamp indicating when it was generated on the client. If abused, this timestamp could allow correlation of data points that are collected at the same time as each other, or at a fixed time offset to other events. For example, if the system were designed to collect two metrics exactly 300 seconds after the system were booted, then just looking at the timestamps would be enough to determine that both metrics recorded at the same time were submitted by the same user. Accordingly, we should consider modifying the metrics server to reduce timestamp granularity at least somewhat. === History === Currently Fedora's only form of metrics collection is [https://fedoraproject.org/wiki/Changes/DNF_Better_Counting DNF Better Counting], but this only counts Fedora installations. That is useful, but we want to count more than just how many users we have. Fedora's first metrics collection attempt was [https://en.wikipedia.org/wiki/Smolt_(Linux) Smolt], a precursor to hw-probe which collected data on user hardware. The current proposal is different from Smolt because it will collect more than just hardware data, and also because Smolt collected only opt-in data. The current proposal would be opt-out, not opt-in. This change proposal will likely be compared to the Ubuntu spyware complaints from a decade ago, when Ubuntu desktop users' search queries were sent to Amazon by default. Let's not do that. == Feedback == We will endeavor to update this section of the change proposal to include a summary of Fedora community discussion of this proposal. == Benefit to Fedora == The main benefit to Fedora is that we will be able to use collected metrics to inform design decisions. It is very common for developers to wish to know something about how Fedora software is used, and we will finally have a way to answer such questions. Occasionally, Red Hat might need to collect specific metrics to justify additional time spent on contributing to Fedora or additional investment in Fedora. == Scope == * Proposal owners: This change requires substantial technical and nontechnical work from the change owners. Most notably, we will need to package eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation properly for Fedora; they are currently packaged in a copr. We also still need to modify eos-metrics-instrumentation so that it does not send events not approved for use in Fedora, as we expect to collect less data than Endless OS. * Other developers: This proposal will require substantial effort by Community Platform Engineering (CPE) to host the metrics server infrastructure. * Release engineering: [https://pagure.io/releng/issues/11514 #11514] * Policies and guidelines: New processes and guidelines are proposed above under the section "How will data collection be approved?" * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: This change does not align with any current [https://docs.fedoraproject.org/en-US/project/initiatives/ Fedora Initiatives], which are very limited in scope. That said, one of the main purposes of metrics collection is to determine whether we are achieving other objectives not listed on the wiki page. For example, we want Fedora Workstation to become the premier developer workstation operating system. To that end, we want to know how many of our users are using particular IDEs. == Upgrade/compatibility impact == We would like to enable metrics upload for upgraded systems, but this isn't trivial because we want to obtain user consent before enabling metrics upload. This would require us to design a user interface that would run on upgraded systems and present the setting to users. We have not yet created such a user interface, so for now metrics upload will need to default to disabled for systems upgraded from older versions of Fedora. Since the underlying setting will be off by default, we don't need to do anything special to achieve this. == How To Test == The ultimate goal is to see metrics appear in the Postgres database of a metrics server, but configuring and running the server is not trivial. Accordingly, we propose to publish a separate document detailing how to set up and configure a metrics server for testing purposes, how to redirect metrics to the custom server, and how to force the client to immediately submit metrics to ease testing. Although we don't actually expect many community members to seriously run their own metrics servers, we still want to document the steps involved so that interested developers can see exactly how it works. == User Experience == A new metrics collection setting will be added to the privacy page in gnome-initial-setup and also to the privacy page in gnome-control-center. This setting will be a simple toggle that will enable or disable all metrics upload for the entire system. Users who do not want any metrics upload should feel confident that uploading can be disabled with a simple toggle. Fedora users should be confident that Fedora metrics collection respects their privacy and collects only limited, anonymous usage data. == Dependencies == Any package that wishes to collect a metric would need to depend on eos-metrics. For example, if we were to collect statistics on which system settings panels are used most frequently, then the gnome-control-center package would need to depend on eos-metrics in order to send a metric to eos-event-recorder-daemon. == Contingency Plan == * Contingency mechanism: We would need to remove the eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation packages from the workstation-product comps group, and rebuild any packages that gained a dependency on eos-metrics. * Contingency deadline: Beta freeze * Blocks release? Yes, if the change is incomplete, it will need to be reverted before release. == Documentation == This feature will depend on several different upstream projects with varying amounts of documentation. The client side consists of eos-metrics, eos-event-recorder-daemon, and eos-metrics-instrumentation. The best documentation of eos-metrics available online is its [https://github.com/endlessm/eos-metrics/blob/master/data/com.endlessm.Metri… D-Bus interface XML]. eos-metrics also contains normal API documentation that will be built and installed in a docs subpackage, but this is not currently available online. The eos-event-recorder-daemon and eos-metrics-instrumentation components do not appear to have any online documentation. On the server end, the metrics server consists of azafea-metrics-proxy feeding metrics into redis, where they will be pulled by azafea and then added to a Postgres database. Documentation for [https://github.com/endlessm/azafea-metrics-proxy/tree/master/docs/source azafea-metrics-proxy] and [https://github.com/endlessm/azafea/tree/master/docs/source azafea] can be reviewed online. [https://azafea.readthedocs.io/en/latest/events.html Events recognized by the server are documented here.] Note that this documentation is currently focused on use by Endless OS rather than by Fedora, and includes documentation of many events that are no longer sent by Endless OS. This change proposal does not propose to enable sending any particular events in Fedora. == Release Notes == Release Notes are not required for initial proposal. We need to write the release notes before change freeze. -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford _______________________________________________ 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

43 105

Golang bundled() Provides generator
by Maxwell G 02 Apr '24

02 Apr '24

Hi Fedorians, A recent PR reminded me that I never properly announced the new (well, four months old) bundled() Provides generator for Golang projects[1]. This can be used to simplify generating these Provides when bundling is justified in Fedora[2] or for (EP)EL. Simply mark the vendor/modules.txt file generated by `go mod vendor` with `%license` and the generator will take care of the rest. This removes the need for long lists of Provides that clutter specfiles and have to be updated after each upstream release. It's up to package maintainers to inspect the Provides for correctness when opting in to this generator. Please let us know if you find any bugs. The generator is available in all Fedora branches and on EPEL 9 (part of go-rpm-macros-epel that shadows RHEL's go-rpm-macros). go-rpm-macros has been updated in c9s, so I'll remove the generator from go-rpm-macros-epel when the next RHEL 9 minor release comes out. [1]: https://pagure.io/go-rpm-macros/c/226596177c63c3dc180b5aeda45fe3b18706e877?… and https://pagure.io/go-rpm-macros/c/c32fbbd25bbcedee8c0b898d3653255b18a0d30e?… [2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_bundled_… -- Maxwell G (@gotmax23) Pronouns: He/Him/His

3 2

some man pages have bugs, can't be grep'd
by Chris Murphy 27 Mar '24

27 Mar '24

I've been seeing this since clean installing Fedora 30. I don't recall ever seeing it before, including on a Fedora 29 -> Fedora 30 upgraded system (is now the clean installed system). [chris@flap ~]$ man rpm | grep -C 10 rpmverbosity <standard input>:176: warning [p 3, 0.8i]: cannot adjust line [chris@flap mantest]$ man rpm >rpm.stdout 2>rpm.stderr [chris@flap mantest]$ ll -rw-rw-r--. 1 chris chris 62 Jul 16 14:24 rpm.stderr -rw-rw-r--. 1 chris chris 28498 Jul 16 14:24 rpm.stdout Is this a bug that should be reported against rpm or something else? I'm certain I've seen it in other man pages, but offhand I can't find another example. -- Chris Murphy

4 6

just to let you know FESCo agreed to a preliminary injunction while we consider this issue
by Sérgio Basto 20 Mar '24

20 Mar '24

Link to the FESCo ticket: https://pagure.io/fesco/issue/3165 and I'm very upset -- Sérgio M. B.

36 142

Announcement: Retiring zlib and minizip-compat from Rawhide
by Tulio Magno Quites Machado Filho 14 Mar '24

14 Mar '24

The zlib-ng-compat and minizip-ng-compat packages have been in Rawhide for more than a month. Considering things have been working well, we believe it's time to retire the zlib and minizip-compat packages. This step should not cause any changes, because zlib-ng-compat and minizip-ng-compat already obsoleted them. However, if you find any issues, please contact us. [1] https://fedoraproject.org/wiki/Changes/ZlibNGTransition [2] https://fedoraproject.org/wiki/Changes/MinizipNGTransition -- Tulio Magno

4 3

looking for a maintainer for package remind
by Kurt Keller 05 Mar '24

05 Mar '24

Remind (https://dianne.skoll.ca/projects/remind/) is a terminal based reminder utility (with optional Tk GUI frontend). It's kind of a supercharged version of the calendar utility. Remind has been in the fedora packages for many years, but the last update to it has happened in fc24 and after fc29 it got orphaned and disappeared. Installing the fc29 RPM on current fedora versions still works flawlessly but is, by now, somewhat out of date. I'd like to see the package back in the software channels and have updated the SPEC file for fc38 and version 04.02.06 of remind and created a pull request (https://src.fedoraproject.org/rpms/remind/pull-request/2) A request to unretire the package has been made ( https://pagure.io/releng/issue/11740) Doing so I learnt a bit more about the fedora software package world. I'm happy to help and support a package maintainer keeping things up to date and learn more along the way, but taking on the role as maintainer of the package is over the top of my head and my current abilities. So I'd like to ask if somebody was willing to take over the role as official maintainer for the remind package. Thanks, Kurt PS: An update to the recently released version 04.02.07 is already waiting in my fork: https://src.fedoraproject.org/fork/kkeller/rpms/remind/commits/remind_04.02… but unless somebody is willing to take over maintainership I don't see much use creating another pull request.

2 3

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 2024