SPDX Statistics - Public Christmas Tree edition
Hot news: We added new license LicenseRef-Fedora-Firmware that we use for firmware that does not have clear license declarations and only "Redistributable..."-like declarations. https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/460/diffs The process of adding the licenses on list is still very slow. We come to conclusion how to handle LicenseRef-KDE-Accepted-* licenses https://gitlab.com/fedora/legal/fedora-legal-docs/-/merge_requests/265/diffs We are working on phase 3 and phase 4 proposals. But they are not yet ready. https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_3 https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 Now lets dive into numbers: Two weeks ago we had: * 23479 spec files in Fedora * 29970license tags in all spec files * 11999 tags have not been converted to SPDX yet * 6587tags can be trivially converted using `license-fedora2spdx` This was error, that was: 5412 tags can be trivially converted using `license-fedora2spdx` * Progress: 59.96% ░█ 100% ELN subset: 327 out of 2444 packages are not converted yet (progress 86.62%) Today we have: * 23562 spec files in Fedora * 30067license tags in all spec files * 11907 tags have not been converted to SPDX yet * 5370tags can be trivially converted using `license-fedora2spdx` * Progress: 60,04% ░░ 100% ELN subset: 507 out of 3734 packages are not converted yet (progress 86.42%) Graph of these data with the burndown chart: https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing The list of packages needed to be converted is here: https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt List by package maintainers is here https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt List of packages from ELN subset that needs to be converted: https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt New version of fedora-license-data has been released. With 4 new licenses (plus some public domain declarations). 20 licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked Legal docs and especially https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ was updated too. And the table there was simplified. New projection when we will be finished is 2024-11-14 (+20 days from last report). Pure linear approximation. If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license tag matches SPDX formula, you can put your package on ignore list https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt Either pull-request or direct email to me is fine. Why Public Christmas Tree? On today's date at 1919 Czech writer and poet Rudolf Těsnohlídek discovered abandoned girl, aged seventeen months, in danger of freezing. They rescued the girl and give her name Liduška. I was unable to find the published information in English so I translated what Těsnohlídek wrote (translation with the help of DeepL)" "We found it last year on Christmas Eve under a lone spruce tree in the forests of Bílovy," the writer recalls. "We went looking for a Christmas tree, a tiny little fir. The lights were already on in the village, as everywhere was being busily cleaned up for the holidays. We fell into a valley through which thousands of hikers pass on summer Sundays. No one was passing through today. The only one returning was the gamekeeper, who had lingered behind to procure a crib for the church. We set off, so as not to get quite dark in the woods, to the nearest coppice on the steep hillside. We laboured our way over the frosty ground to the middle of the hillside, where it was flatter and where we could have taken a more vigorous step, but here the cry of the forest arrested the steps of the three of us. It was a few crows, which, cawing a warning to the others, had fallen on the opposite hillside. They swooped down to await death as always. We stood in human, unsparing curiosity, and then the wind blew a faint moan towards us. It was a poignant wail, a defenceless, dying, farewell to the world. So the deer one wails when mortally wounded. We wanted to shorten her agony and headed across the undergrowth to the supposed doe. How many small suitable Christmas trees there were, but we didn't spot a single one. All we could see in front of us at that moment was a sprawling spruce tree. Approaching it, we realized that the groan was the fading cry of a child. We froze in surprise. We imagined her standing there in her flimsy rags, wearing a thin skirt, waiting. Perhaps the mother had placed it here in the lee of the thicket to wait until it had gathered the brushwood, and it was afraid of the dark and the coming night, and therefore
Re: How to clone subpackages during koji build stage
Hi Frank! This is awesome! I can review your PR because ProcDump is not so friendly in systems that are rpm based. On Thu, Dec 21, 2023 at 3:49 PM Frank R Dana Jr. wrote: > > I just submitted that PR I mentioned, to support use of a system libbpf > instead of immediately diving into ExternalProject_Add(): > > https://github.com/Sysinternals/ProcDump-for-Linux/pull/225 > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Julio Red Hat Kernel Team -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Mailman3 web components for EPEL 9 now in Bodhi!
On Thu, Dec 21, 2023 at 02:13:26PM -0600, Michel Lind wrote: > Dear all, > > I'm happy to be able to provide this holiday present to the infra team > (and other interested parties) - after chasing through tens of > dependencies, going through multiple stalled EPEL requests, and evolving > ebranch to automate some of these pain points, the `mailman3` web > components are now built for EPEL 9 and available to test! > > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4c6b819c9c > Thanks in particular to Neal Gompa and Kevin Fenzi for all the assistance and coordination in getting blockers dealt with. -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Mailman3 web components for EPEL 9 now in Bodhi!
Dear all, I'm happy to be able to provide this holiday present to the infra team (and other interested parties) - after chasing through tens of dependencies, going through multiple stalled EPEL requests, and evolving ebranch to automate some of these pain points, the `mailman3` web components are now built for EPEL 9 and available to test! https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4c6b819c9c This is a follow-up to `mailman3` itself that entered EPEL 9 two months ago: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f022c8f3ad There are probably some missing plugins etc. that have not been branched and built for EPEL 9 yet, let me know if you have a list and I'm happy to get to them next. Happy holidays, -- Michel Lind (né Salim) identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2 signature.asc Description: PGP signature -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: How to clone subpackages during koji build stage
I just submitted that PR I mentioned, to support use of a system libbpf instead of immediately diving into ExternalProject_Add(): https://github.com/Sysinternals/ProcDump-for-Linux/pull/225 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Update on the Modern C initiative
On Thu, Dec 21, 2023 at 01:59:59PM +0100, Florian Weimer wrote: > Based on my records, all issues that can lead to silent miscompilation > because of altered configure probes (autoconf/CMake and a few others) > have been addressed, or there are at least Bugzilla bugs filed for them. > There could be some gaps due to lack of architecture capture, general > rawhide churn, or configure scripts running late during the build, which > we do not reach due to a previous build failure. But these gaps should > fairly small, I hope. It's also not a new problem—while fixing newly > introduced errors, we encountered cases where autoconf probes had > already been failing unexpectedly for a long time because of typos or > missing #include directives. > > I originally wanted to fix the int-conversion issues next. That package > set is fairly small (about 60 packages). Do you have a list of affected packages? Rich. > But it's more or less a coin > toss whether the compiler errors is due to a missing cast due to C type > system limitations, or indicative of a real problem (typically > manifesting as a crash at run time if the code is ever executed). The > latter can be quite difficult to fix and may require domain-specific > knowledge. Just adding the cast in both cases just obscures the crash > or misbehavior in the second case, and robs us of an opportunity to fix > this properly. I see what I can do to fix packages, but it's unlikely > that it will going to be all of them. > > Looking at the calendar and the projected time when GCC 14 will land in > the buildroot, I think we missed the window where a GCC 13 version with > a preview of these C front end changes would have been beneficial to > Fedora developers. It would have also created an awkward issue where > __GNUC__ is 13, but the compiler behaves in part like GCC 14. This is > relevant if it's necessary to suppress (or treat as warnings) > -Wreturn-mismatch diagnostics, which only exist in GCC 14. > > This brings me to my final point. We still don't have a solution for > Vala. I plan to look at valac soon and see what we can do to keep things > at least compiling with GCC 14 (after re-running valac). > > Thanks, > Florian > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
On Thu, Dec 21, 2023 at 06:58:37PM +0100, Florian Weimer wrote: > * Aoife Moloney: > > > == Detailed Description == > > The split between `/bin` and `/sbin` is not useful, and also unused. > > Programs in /usr/bin have their documentation in section 1 of the > manual, while programs /usr/sbin are documented in section 8. (In > general, I deliberately used /usr/bin/ld.so although the manual page was > already called ld.so(8), without a program of this name existing.) > > When moving programs, should we move the manual pages as well? Or at > least add a link so that that section 1 references work? The manual sections have historical meaning: https://en.wikipedia.org/wiki/Man_page#Manual_sections eg. 1 = general commands 8 = system administration So unless the tools themselves are changing their purpose or are in the wrong section now, the manual sections should stay the same. Rich. > Is there something we can do to help developers on Fedora systems to > write portable code (not just shell scripts) after this change is rolled > out? > > Thanks, > Florian > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
Hi,
On Thu, 2023-12-21 at 16:08 +, Gary Buhrmaster wrote:
> On Thu, Dec 21, 2023 at 2:49 PM Tom Hughes via devel
> wrote:
> >
> > On 21/12/2023 14:33, Steven A. Falco wrote:
> > > On 12/21/23 08:53 AM, Neal Gompa wrote:
> > > > On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott
> > > >
> > > > wrote:
> > > > >
> > > > > I'm -1 for this change, it shouldn't be enabled by default as
> > > > > it will
> > > > > cause issues for users using router mac filtering.
If you configure the devices MAC addresses on your router, you have a
somewhat established procedure how to do that. E.g. when a family
member gets a new notebook.
The upgrade to Fedora 40, will be a one time event, where you have to
do that again (or you opt out from the change).
> > > >
> > > > What this seems to state is that the MAC address would be
> > > > unique for
> > > > each SSID, but once it's picked, it would be locked in. That
> > > > should
> > > > still make router-level MAC filtering possible, since the MAC
> > > > address
> > > > would be stable for that network.
> > >
> > > What would happen on a network where I've set up the DHCP server
> > > in my
> > > router to map mac addresses to static IP addresses? Sounds like
> > > I'd
> > > have to disable the feature, at least on my home network.
> >
> > Either that or you would make a one off change to your DHCP server
> > to use the new per-network MAC address instead of the old one.
>
> Would it not have to be done every time
> one reinstalls their system?
Yes. Unless you copy over /etc/machine-id and
/var/lib/NetworkManager/secret_key.
These 2 files are the identity of your machine. If you lose them during
re-install, you get a different machine. The same already applies with
`ipv6.addr-gen-mode`, which defaults to "stable-privacy" to get RFC7217
IPv6 interface identifiers (meaning, you'll get a different IPv6
address after reinstall).
> And on
> each SSID one connects to (so connect
> to your HOME-5G (for your 5GHz AP),
> and HOME-2.4G (for your 2.4GHz AP),
> wifi networks would get different MAC
> addresses as the SSID is different?)
for the two profiles of your home network, you most likely would do
for PROFILE in HOME-5G HOME-2.4G ; do
nmcli connection modify "$PROFILE" \
connection.stable-id "my-home-wifi" \
wifi.cloned-mac-address stable
done
(or `wifi.cloned-mac-address permanent`).
With Wi-Fi we commonly have many profiles (Hotels, public Wi-Fis). Only
a small number are our home networks, where we might care about the MAC
address. You can select the best behavior for those selected few
profiles, but getting a more reasonable default ("stable-ssid") for all
other profiles.
To be clear, I also use "stable" MAC at home. For most cases, there is
little reason to use the MAC address of their hardware. Yes, I somewhat
care that for the most time I get the same IP address from my DHCP
server. If that IP address changes once after upgrade to Fedora 40, I
don't care. And it's not even said, that the IP address is going to
change. NetworkManager has the DHCP lease stored on disk, it will ask
the server to hand out the same IP address.
>
> (side note: some DHCP servers may
> not like assigning different MACs to
> the same IP address to allow individuals
> to choose their own access point
> frequency range based SSID).
>
> While doing so as an individual would
> probably be minorly annoying, for some
> orgs, "re-imaging" a system is the
> standard practice for repair (or
> redeployment, or for each reboot
> for guest systems) and having a stable
> MAC address (whether wired or wireless)
> is necessary for institutional requirements.
Would a company network really care about the MAC address? It doesn't
seem to scale, that new devices need to be registered.
Seems such an org is also pre-deploying configuration on the machine.
The profiles can be pre-deployed with "wifi.cloned-mac-address
permanent".
Or just a
$ touch /etc/NetworkManager/conf.d/22-wifi-mac-addr.conf
to disable all what this change brings.
>
> And for some orgs with advanced 802.1x
> network access controls, changing MAC
> addresses may result in even more
> additional tasks across different parts
> of the organization (yes, one should not
> use mac authentication alone for
> 802.1x, but that is a different topic).
>
> For orgs with a more sophisticated
> process, updating their ansible
> provisioning scripts to change the
> NetworkManager to use the hardware
> address may be possible, although for
> others, that will be one more step for
> tech support to have to do manually
> (and, of course, occasionally forget to
> do, as they are always overworked),
If you company tech support expects a call if the MAC address of the
users notebook changes, they can also expect a call when they use a
different notebook. That is asking for work.
> but
> at the very least the proposal should
> probably call out that change
> requirement more explicitly for such
>
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
* Aoife Moloney: > == Detailed Description == > The split between `/bin` and `/sbin` is not useful, and also unused. Programs in /usr/bin have their documentation in section 1 of the manual, while programs /usr/sbin are documented in section 8. (In general, I deliberately used /usr/bin/ld.so although the manual page was already called ld.so(8), without a program of this name existing.) When moving programs, should we move the manual pages as well? Or at least add a link so that that section 1 references work? Is there something we can do to help developers on Fedora systems to write portable code (not just shell scripts) after this change is rolled out? Thanks, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: EPEL-ANNOUNCE Incompatible update of llhttp in EPEL9
I have pushed this update to stable. This is the final announcement prescribed by the EPEL Incompatible Upgrades Policy, https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ On 12/13/23 08:43, Ben Beasley wrote: I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4b1b8b8b25, which updates llhttp from 8.1.1 to 9.1.3 in EPEL9. This is an ABI-incompatible update, and the SONAME version changes. There are also some minor API changes. The only package in EPEL9 that uses llhttp is python-aiohttp, and the update also compatibly updates it from 3.8.5 to its latest release, 3.9.1. Together, these updates fix a number of security issues, including CVE-2023-47627, CVE-2023-49081, and CVE-2023-49082. A COPR impact check in https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/ indicates there should be no impact on any dependent packages in EPEL9. If you have software not packaged in EPEL9 that depends directly on llhttp, you will need to rebuild it due to the ABI changes. It is possible that source code changes may be required if (like python-aiohttp) you use almost the entire API of llhttp, or if you have very thorough tests that reveal small changes in llhttp’s behavior. Straightforward uses of llhttp are likely to recompile without modification. If you have software not packaged in EPEL9 that depends directly on python-aiohttp, you should not need to do anything, but you might choose to review the changelogs for releases 3.8.6, 3.9.0, and 3.9.1 here for full details on the changes included in this update: https://github.com/aio-libs/aiohttp/blob/v3.9.1/CHANGES.rst#391-2023-11-26 I have no plans to attempt a build of llhttp or any update of python-aiohttp in EPEL8. This is an incompatible update under the EPEL Incompatible Upgrades Policy, https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/. It was approved by the EPEL Steering Committee: https://pagure.io/epel/issue/262. -- ___ epel-announce mailing list -- epel-annou...@lists.fedoraproject.org To unsubscribe send an email to epel-announce-le...@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/epel-annou...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Incompatible update of llhttp in EPEL9
I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4b1b8b8b25, which updates llhttp from 8.1.1 to 9.1.3 in EPEL9. This is an ABI-incompatible update, and the SONAME version changes. There are also some minor API changes. The only package in EPEL9 that uses llhttp is python-aiohttp, and the update also compatibly updates it from 3.8.5 to its latest release, 3.9.1. Together, these updates fix a number of security issues, including CVE-2023-47627, CVE-2023-49081, and CVE-2023-49082. A COPR impact check in https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/ indicates there should be no impact on any dependent packages in EPEL9. If you have software not packaged in EPEL9 that depends directly on llhttp, you will need to rebuild it due to the ABI changes. It is possible that source code changes may be required if (like python-aiohttp) you use almost the entire API of llhttp, or if you have very thorough tests that reveal small changes in llhttp’s behavior. Straightforward uses of llhttp are likely to recompile without modification. If you have software not packaged in EPEL9 that depends directly on python-aiohttp, you should not need to do anything, but you might choose to review the changelogs for releases 3.8.6, 3.9.0, and 3.9.1 here for full details on the changes included in this update: https://github.com/aio-libs/aiohttp/blob/v3.9.1/CHANGES.rst#391-2023-11-26 I have no plans to attempt a build of llhttp or any update of python-aiohttp in EPEL8. This is an incompatible update under the EPEL Incompatible Upgrades Policy, https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/. It was approved by the EPEL Steering Committee: https://pagure.io/epel/issue/262. -- ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
On Wed, Dec 20, 2023 at 7:51 PM Chris Adams wrote: > > Once upon a time, Aoife Moloney said: > > Enable IPv4 Address Conflict Detection by default in NetworkManager. > > Huh, I didn't realize NM didn't already do this... ye olde > network-scripts did. > As I recall, depending on configuration(s), systemd-networkd has done so for quite some time. Off hand I do not recall its various values, but it might make sense to align the settings. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
Once upon a time, Beniamino Galvani said:
> network-scripts do [1]:
>
> /sbin/arping -c 2 -w ${ARPING_WAIT:-3} -D -I ${REALDEVICE} ${ipaddr[$idx]}
>
> which waits 2 seconds by default.
Ahh, sorry, that's what I get for depending on memory. :)
> In the original RFC, the duration of the ACD process is between 4 and
> 7 seconds (depending on randomization), which is clearly too long on
> modern hardware.
Definitely agree.
> In the Fedora change proposal, the default ACD interval in NM is set
> to up to 3 seconds and is subject to the same randomization; in
> practice it would be between ~1.7 and 3 seconds. Perhaps that's still
> too much, and we can safely decrease it to e.g. 1 second max to reduce
> the activation delay.
Yeah, I think sending 2-3 requests separated by maybe 0.2 seconds, and
waiting another 0.2 seconds for a reply (so a total of 0.8 seconds) is
sufficient for modern networks. A number of DHCP servers do a ping
before issue as well (although there's no good way for a DHCP client to
tell), so it's just adding to the amount of time before the network
becomes usable.
DAD/ACD is a good thing, I'd just like to see the impact minimized. The
time taken at boot is not a big deal (as users have to log in and start
applications and such), but the time taken on resume from sleep is more
noticable (open the notebook lid, unlock, then... wait).
Thinking about servers... this would happen before network-online.target
is triggered, right? Any services that try to bind to configured IPs or
the like need to still work.
--
Chris Adams
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Enable IPv4 Address Conflict Detection (Self-Contained)
On Wed, Dec 20, 2023 at 01:51:01PM -0600, Chris Adams wrote:
> Once upon a time, Aoife Moloney said:
> > Enable IPv4 Address Conflict Detection by default in NetworkManager.
>
> Huh, I didn't realize NM didn't already do this... ye olde
> network-scripts did.
>
> > To the rescue comes [https://www.rfc-editor.org/rfc/rfc5227 RFC 5227]
> > (“IPv4 Address Conflict Detection”) which provides a mechanism to
> > detect address conflicts. A host implementing Address Conflict
> > Detection (from now on “ACD”) sends ARP probes for each IP address it
> > wants to use; if another host replies, the address is already in use
> > and can’t be configured on the interface.
>
> How does NM handle a duplicate address if there are multiple addresses
> configured on the interface? Does it continue with the non-dupe
> addresses or deconfigure the whole interface?
It continues with only the non-duplicate addresses. A warning will be
visible in the journal telling what address(es) failed ACD, and what
is the MAC address of the conflicting host(s).
If all the IPv4 addresses are found to be duplicate, the IPv4 address
family fails. Normally, NetworkManager also tries IPv6, but that
depends on other connection parameters such as 'ipv6.method',
'ipv4.may-fail'.
> When there are multiple addresses configured, does NM run DAD in series
> or parallel?
The probe is done in parallel for all addresses at the same time.
> > This change aims at enabling ACD by default in Fedora 40, by setting
> > the default value to 3000ms.
>
> 3 seconds seems kind of high (IIRC network-scripts used 1 second).
network-scripts do [1]:
/sbin/arping -c 2 -w ${ARPING_WAIT:-3} -D -I ${REALDEVICE} ${ipaddr[$idx]}
which waits 2 seconds by default.
In the original RFC, the duration of the ACD process is between 4 and
7 seconds (depending on randomization), which is clearly too long on
modern hardware.
In the Fedora change proposal, the default ACD interval in NM is set
to up to 3 seconds and is subject to the same randomization; in
practice it would be between ~1.7 and 3 seconds. Perhaps that's still
too much, and we can safely decrease it to e.g. 1 second max to reduce
the activation delay.
Beniamino
[1]
https://github.com/fedora-sysv/initscripts/blob/10.19/network-scripts/ifup-eth#L296
signature.asc
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On Thu, Dec 21, 2023 at 2:49 PM Tom Hughes via devel wrote: > > On 21/12/2023 14:33, Steven A. Falco wrote: > > On 12/21/23 08:53 AM, Neal Gompa wrote: > >> On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott > >> wrote: > >>> > >>> I'm -1 for this change, it shouldn't be enabled by default as it will > >>> cause issues for users using router mac filtering. > >> > >> What this seems to state is that the MAC address would be unique for > >> each SSID, but once it's picked, it would be locked in. That should > >> still make router-level MAC filtering possible, since the MAC address > >> would be stable for that network. > > > > What would happen on a network where I've set up the DHCP server in my > > router to map mac addresses to static IP addresses? Sounds like I'd > > have to disable the feature, at least on my home network. > > Either that or you would make a one off change to your DHCP server > to use the new per-network MAC address instead of the old one. Would it not have to be done every time one reinstalls their system? And on each SSID one connects to (so connect to your HOME-5G (for your 5GHz AP), and HOME-2.4G (for your 2.4GHz AP), wifi networks would get different MAC addresses as the SSID is different?) (side note: some DHCP servers may not like assigning different MACs to the same IP address to allow individuals to choose their own access point frequency range based SSID). While doing so as an individual would probably be minorly annoying, for some orgs, "re-imaging" a system is the standard practice for repair (or redeployment, or for each reboot for guest systems) and having a stable MAC address (whether wired or wireless) is necessary for institutional requirements. And for some orgs with advanced 802.1x network access controls, changing MAC addresses may result in even more additional tasks across different parts of the organization (yes, one should not use mac authentication alone for 802.1x, but that is a different topic). For orgs with a more sophisticated process, updating their ansible provisioning scripts to change the NetworkManager to use the hardware address may be possible, although for others, that will be one more step for tech support to have to do manually (and, of course, occasionally forget to do, as they are always overworked), but at the very least the proposal should probably call out that change requirement more explicitly for such orgs. Given the unknown impact on larger organization customers (rather than individuals taking their own devices to an overpriced coffee shop), I am currently leaning on the -1 side. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On 21/12/2023 14:33, Steven A. Falco wrote: On 12/21/23 08:53 AM, Neal Gompa wrote: On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote: I'm -1 for this change, it shouldn't be enabled by default as it will cause issues for users using router mac filtering. What this seems to state is that the MAC address would be unique for each SSID, but once it's picked, it would be locked in. That should still make router-level MAC filtering possible, since the MAC address would be stable for that network. What would happen on a network where I've set up the DHCP server in my router to map mac addresses to static IP addresses? Sounds like I'd have to disable the feature, at least on my home network. Either that or you would make a one off change to your DHCP server to use the new per-network MAC address instead of the old one. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On 12/21/23 08:53 AM, Neal Gompa wrote: On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote: I'm -1 for this change, it shouldn't be enabled by default as it will cause issues for users using router mac filtering. What this seems to state is that the MAC address would be unique for each SSID, but once it's picked, it would be locked in. That should still make router-level MAC filtering possible, since the MAC address would be stable for that network. What would happen on a network where I've set up the DHCP server in my router to map mac addresses to static IP addresses? Sounds like I'd have to disable the feature, at least on my home network. Steve -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott wrote: > > I'm -1 for this change, it shouldn't be enabled by default as it will cause > issues for users using router mac filtering. What this seems to state is that the MAC address would be unique for each SSID, but once it's picked, it would be locked in. That should still make router-level MAC filtering possible, since the MAC address would be stable for that network. -- 真実はいつも一つ！/ Always, there's only one truth! -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)
I'm -1 for this change, it shouldn't be enabled by default as it will cause issues for users using router mac filtering. -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255477] CVE-2023-47100 perl: Perl security bypass [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2255477 Michal Josef Spacek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |CLOSED Last Closed||2023-12-21 13:37:32 --- Comment #2 from Michal Josef Spacek --- *** This bug has been marked as a duplicate of bug 2251622 *** -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255477 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255477%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2251622] CVE-2023-47038 perl: Write past buffer end via illegal user-defined Unicode property [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2251622 Michal Josef Spacek changed: What|Removed |Added Blocks||2255476 (CVE-2023-47100) --- Comment #10 from Michal Josef Spacek --- *** Bug 2255477 has been marked as a duplicate of this bug. *** Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2255476 [Bug 2255476] CVE-2023-47100 perl: Perl security bypass -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2251622 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251622%23c10 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2251625] CVE-2023-47038 perl:5.36/perl: Write past buffer end via illegal user-defined Unicode property [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2251625 Michal Josef Spacek changed: What|Removed |Added Blocks||2255476 (CVE-2023-47100) --- Comment #2 from Michal Josef Spacek --- *** Bug 2255479 has been marked as a duplicate of this bug. *** Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2255476 [Bug 2255476] CVE-2023-47100 perl: Perl security bypass -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2251625 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251625%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255479] CVE-2023-47100 perl:5.36/perl: Perl security bypass [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2255479 Michal Josef Spacek changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |DUPLICATE Last Closed||2023-12-21 13:34:37 --- Comment #2 from Michal Josef Spacek --- *** This bug has been marked as a duplicate of bug 2251625 *** -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255479 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255479%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2251624] CVE-2023-47038 perl:5.34/perl: Write past buffer end via illegal user-defined Unicode property [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2251624 Michal Josef Spacek changed: What|Removed |Added Blocks||2255476 (CVE-2023-47100) --- Comment #3 from Michal Josef Spacek --- *** Bug 2255478 has been marked as a duplicate of this bug. *** Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=2255476 [Bug 2255476] CVE-2023-47100 perl: Perl security bypass -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2251624 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251624%23c3 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255478] CVE-2023-47100 perl:5.34/perl: Perl security bypass [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=2255478 Michal Josef Spacek changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |DUPLICATE Last Closed||2023-12-21 13:32:54 --- Comment #2 from Michal Josef Spacek --- *** This bug has been marked as a duplicate of bug 2251624 *** -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255478 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255478%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Update on the Modern C initiative
Based on my records, all issues that can lead to silent miscompilation because of altered configure probes (autoconf/CMake and a few others) have been addressed, or there are at least Bugzilla bugs filed for them. There could be some gaps due to lack of architecture capture, general rawhide churn, or configure scripts running late during the build, which we do not reach due to a previous build failure. But these gaps should fairly small, I hope. It's also not a new problem—while fixing newly introduced errors, we encountered cases where autoconf probes had already been failing unexpectedly for a long time because of typos or missing #include directives. I originally wanted to fix the int-conversion issues next. That package set is fairly small (about 60 packages). But it's more or less a coin toss whether the compiler errors is due to a missing cast due to C type system limitations, or indicative of a real problem (typically manifesting as a crash at run time if the code is ever executed). The latter can be quite difficult to fix and may require domain-specific knowledge. Just adding the cast in both cases just obscures the crash or misbehavior in the second case, and robs us of an opportunity to fix this properly. I see what I can do to fix packages, but it's unlikely that it will going to be all of them. Looking at the calendar and the projected time when GCC 14 will land in the buildroot, I think we missed the window where a GCC 13 version with a preview of these C front end changes would have been beneficial to Fedora developers. It would have also created an awkward issue where __GNUC__ is 13, but the compiler behaves in part like GCC 14. This is relevant if it's necessary to suppress (or treat as warnings) -Wreturn-mismatch diagnostics, which only exist in GCC 14. This brings me to my final point. We still don't have a solution for Vala. I plan to look at valac soon and see what we can do to keep things at least compiling with GCC 14 (after re-running valac). Thanks, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora rawhide compose report: 20231221.n.0 changes
OLD: Fedora-Rawhide-20231220.n.0 NEW: Fedora-Rawhide-20231221.n.0 = SUMMARY = Added images:1 Dropped images: 8 Added packages: 4 Dropped packages:0 Upgraded packages: 96 Downgraded packages: 0 Size of added packages: 180.73 KiB Size of dropped packages:0 B Size of upgraded packages: 8.49 GiB Size of downgraded packages: 0 B Size change of upgraded packages: 24.99 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20231221.n.0.iso = DROPPED IMAGES = Image: Kinoite dvd-ostree x86_64 Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20231220.n.0.iso Image: Workstation live ppc64le Path: Workstation/ppc64le/iso/Fedora-Workstation-Live-ppc64le-Rawhide-20231220.n.0.iso Image: Silverblue dvd-ostree x86_64 Path: Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20231220.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20231220.n.0.iso Image: Robotics live x86_64 Path: Labs/x86_64/iso/Fedora-Robotics-Live-x86_64-Rawhide-20231220.n.0.iso Image: Silverblue dvd-ostree ppc64le Path: Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20231220.n.0.iso Image: Sericea dvd-ostree x86_64 Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231220.n.0.iso Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20231220.n.0.iso = ADDED PACKAGES = Package: python-flask-session-0.5.0-1.fc40 Summary: Server side session extension for Flask RPMs:python3-flask-session Size:23.22 KiB Package: rust-as-raw-xcb-connection-1.0.1-1.fc40 Summary: Trait to facilitate interoperatibility with libxcb C API RPMs:rust-as-raw-xcb-connection+alloc-devel rust-as-raw-xcb-connection+default-devel rust-as-raw-xcb-connection-devel Size:28.70 KiB Package: rust-jiter-0.0.4-1.fc40 Summary: Iterable JSON parser RPMs:rust-jiter+default-devel rust-jiter+python-devel rust-jiter-devel Size:101.73 KiB Package: rust-rustix-openpty-0.1.1-1.fc40 Summary: Safe Rust bindings to openpty and related functions RPMs:rust-rustix-openpty+default-devel rust-rustix-openpty-devel Size:27.08 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: EMBOSS-6.6.0-26.fc40 Old package: EMBOSS-6.6.0-25.fc39 Summary: The European Molecular Biology Open Software Suite RPMs: EMBOSS EMBOSS-devel EMBOSS-libs libeplplot libeplplot-devel Size: 303.07 MiB Size change: -210.83 KiB Changelog: * Wed Dec 20 2023 Tom Callaway - 6.6.0-26 - fix pcre2 patch (no more segfaults, hopefully) - update license tag Package: QXlsx-1.4.7-1.fc40 Old package: QXlsx-1.4.6-9.fc40 Summary: Excel/XLSX file reader/writer library for Qt RPMs: QXlsx QXlsx-devel Size: 1.74 MiB Size change: -773 B Changelog: * Wed Dec 20 2023 Gwyn Ciesla - 1.4.7-1 - 1.4.7 Package: R-littler-0.3.19-1.fc40 Old package: R-littler-0.3.18-4.fc39 Summary: littler: R at the Command-Line via 'r' RPMs: R-littler R-littler-examples Size: 473.85 KiB Size change: 6.20 KiB Changelog: * Tue Dec 19 2023 Mattias Ellert - 0.3.19-1 - New upstream release 0.3.19 Package: algobox-1.1.1-1.fc40 Old package: algobox-1.0.3-8.fc39 Summary: Algorithmic software RPMs: algobox Size: 1.76 MiB Size change: -88.17 KiB Changelog: * Wed Dec 20 2023 Nicolas Chauvet - 1.1.1-1 - Update to 1.1.1 Package: alsa-sof-firmware-2023.12-1.fc40 Old package: alsa-sof-firmware-2023.09.2-1.fc40 Summary: Firmware and topology files for Sound Open Firmware project RPMs: alsa-sof-firmware alsa-sof-firmware-debug Size: 4.34 MiB Size change: -22.42 KiB Changelog: * Wed Dec 20 2023 Jaroslav Kysela - 2023.12-1 - Update to v2023.12 Package: ardour8-8.2.0-1.fc40 Old package: ardour8-8.1.0-6.fc40 Summary: Digital Audio Workstation RPMs: ardour8 Size: 64.43 MiB Size change: 1.21 MiB Changelog: * Wed Dec 20 2023 Nils Philippsen - 8.2.0-1 - Update to version 8.2.0 Package: armadillo-12.6.6-1.fc40 Old package: armadillo-10.8.2-5.fc39 Summary: Fast C++ matrix library with syntax similar to MATLAB and Octave RPMs: armadillo armadillo-devel Size: 10.88 MiB Size change: -148.07 KiB Changelog: * Wed Dec 06 2023 Ryan Curtin - 12.6.6-1 - Update to latest stable version. Package: brltty-6.6-9.fc40 Old package: brltty-6.6-8.fc40 Summary: Braille display driver for Linux/Unix RPMs: brlapi brlapi-devel brlapi-java brltty brltty-at-spi2 brltty-docs brltty-dracut brltty-espeak brltty-espeak-ng brltty-minimal brltty-speech-dispatcher brltty-xw ocaml-brlapi python3-brlapi tcl-brlapi Size: 17.61 MiB Size change: 50.15 KiB Changelog: * Wed Dec 20 2023 Gwyn Ciesla - 6.6-9
Last Day to Vote in F39 Elections is Today!
Hi all, Today is the last day to vote in the F39 elections. Please make sure you do so, in particular for FESCo where the number of candidates exceed the open seats. To vote please visit the Elections App https://elections.fedoraproject.org/ Kind regards, Aoife Aoife Moloney Fedora Operations Architect -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255496] perl-Business-ISBN-Data-20231220.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255496 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Business-ISBN-Data-202 ||31220.001-1.fc40 Resolution|--- |ERRATA Last Closed||2023-12-21 10:57:10 --- Comment #2 from Fedora Update System --- FEDORA-2023-a90a5bf306 has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255496 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255496%23c2 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255496] perl-Business-ISBN-Data-20231220.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255496 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-a90a5bf306 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2023-a90a5bf306 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255496 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255496%23c1 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2255496] New: perl-Business-ISBN-Data-20231220.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255496 Bug ID: 2255496 Summary: perl-Business-ISBN-Data-20231220.001 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Business-ISBN-Data Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 20231220.001 Upstream release that is considered latest: 20231220.001 Current version/release in rawhide: 20231215.001-1.fc40 URL: https://metacpan.org/dist/Business-ISBN-Data/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/2674/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Business-ISBN-Data -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255496 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255496%23c0 -- ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
Dne 21. 12. 23 v 10:20 Vít Ondruch napsal(a): Dne 20. 12. 23 v 20:53 Aoife Moloney napsal(a): ** Adjust `%_sbindir` in `/usr/lib/rpm/macros` (part of `rpm` package). Packages will be updated automatically during the mass rebuild. Isn't the ultimate goal to drop the `%_sbindir` all together? Shouldn't at minimum the packaging guidelines be updated? We could probably drop the `%_sbindir` automatically in near future. Of course even dropping the directories instead of linking them would be nice ... Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)
Dne 20. 12. 23 v 20:53 Aoife Moloney napsal(a): ** Adjust `%_sbindir` in `/usr/lib/rpm/macros` (part of `rpm` package). Packages will be updated automatically during the mass rebuild. Isn't the ultimate goal to drop the `%_sbindir` all together? Shouldn't at minimum the packaging guidelines be updated? We could probably drop the `%_sbindir` automatically in near future. Vít OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
