Re: Mock Configs v39.3 released - DNF5 used for F40+ builds
On pondělí 18. prosince 2023 10:08:06 CET Pavel Raiskup wrote:
> On pátek 1. prosince 2023 15:04:10 CET Pavel Raiskup wrote:
> > Hello maintainers!
> >
> > Let me announce a new release of Mock Core Configs v39.3, aka
> > the configuration files for Mock, the chroot build environment manager
> > for building RPMs.
> >
> > The notable change in this release is that we are switching the default
> > package_manager from DNF4 to DNF5, according to the F40 change:
> > https://fedoraproject.org/wiki/Changes/BuildWithDNF5
> > Full release notes:
> >https://rpm-software-management.github.io/mock/Release-Notes-Configs-39.3
> >
> > We plan to push this update into Fedora Copr to get some early testing
> > next week. Then, depending on the releng team, we might push this into
> > Koji soon. The Bodhi updates links are here:
> >
> > F39 https://bodhi.fedoraproject.org/updates/FEDORA-2023-0a947db1d0
> > F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-6ef1e12930
> > F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-cd9c489f40
> > EL9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-c2c4082053
> > EL8 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-eab5217f46
> >
> > Note that we **will not** push these updates into Fedora stable earlier
> > than on Monday 2023-12-18 (but very likely we'll wait till the next
> > year, depending on the feedback).
>
> And the push eventually happened, despite that I did not want it to
> happen, yet. I probably messed up the Bodhi updates (I thought I
> disabled the stable-by-time feature). Sorry, folks.
>
> The builds often just work. But there are two issues that blocks us
> from letting this update go to Fedora Copr at least:
>
> - the builddep globbing issue
> https://github.com/rpm-software-management/dnf5/pull/1088 which is
> going to be fixed by a new release (just a new DNF5 release into
> Rawhide means the problem is fixed)
>
> - the weird hangs against Fedora Copr repositories
> https://github.com/fedora-copr/copr/issues/3067 - this will probably
> not hit you locally, but I am not sure yet.
>
> In any case, if you need to - stay with DNF4 for a while - either do
>
> $ cat ~/.config/mock/fedora-rawhide-x86_64.cfg
> include("/etc/mock/fedora-rawhide-x86_64.cfg")
> config_opts["package_manager"] = "dnf"
>
> ... or stay with the `mock-core-configs v39.2` a bit longer please.
Just a quick update, we already have DNF5 5.1.10 submitted for Fedora
Rawhide repos (should be in mirrors tomorrow). This DNF5 release has no
known "blocker" issues.
I just wanted to give you a quick heads-up that I plan to enable the
BuildWithDNF5 change in Fedora Copr as soon as the new Rawhide compose
gets distributed to mirrors.
Pavel
signature.asc
Description: This is a digitally signed message part.
--
___
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: Optimized Binaries for the AMD64 Architecture (System-Wide)
On 12/31/23 18:27, Dominique Martinet wrote: John Reiser wrote on Sun, Dec 31, 2023 at 02:52:53PM -0800: Additional paths will be inserted into the search path used for executables on systems which have a compatible CPU. Searching $PATH is a slow operation. It is so slow that a shell script which typically processes many files using utilities from packages coreutils and/or binutils often factors-out the PATH search by using shell variables: CP=$(which cp) ... $(CP) $file.in $file.out (getting slighly off topic, sorry) That hasn't been needed for as long as I've used a compter, all^W most shells already do this for you. (It's obvious in interactive mode when you need to use hash/rehash built-ins after moving a binary that you ran once, but it's true as well when running scripts: if you e.g. strace for stat() calls a script that calls cp twice you'll see it only looks through PATH once. This is true of at least bash, zsh, dash, and even busybox ash... Interestingly fish doesn't seem to do it, I'm a bit surpised here) Some programs DO search $PATH because they use execlp() or execvp() or execvpe(). Example of /usr/bin/rpm searching for "sh": = [edited for clarity] $ echo $PATH /A:/B:/usr/local/bin:/usr/bin: ... $ strace -f -e trace=newfstatat rpm --install -p zip-3.0-37.fc38.src.rpm 19792 newfstatat(AT_FDCWD, "/A/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/B/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/usr/local/bin/sh", 0x7fff8c204840, 0) = -1 ENOENT 19792 newfstatat(AT_FDCWD, "/usr/bin/sh", ...}, 0) = 0 = That's with rpm-4.18.2-1.fc38.x86_64 and glibc-2.37-16.fc38.x86_64. -- ___ 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: Optimized Binaries for the AMD64 Architecture (System-Wide)
Hi,
On 12/28/23 10:12, Aoife Moloney wrote:
Wiki ->
https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Additional paths will be inserted into the search path used for
executables on systems which have a compatible CPU.
Those additional paths will mirror the AMD64 "microarchitecture
levels" supported by the glibc-hwcaps mechanism: `x86-64-v2`,
`x86-64-v3`, `x86_64-v4`.
Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)
and the equivalent internal mechanism in `systemd` (affecting what
executables are used by services).
Individual packages can provide optimized libraries via the
(trimming)
Glibc-hwcaps together with the new feature in systemd provide a
generic mechanism. It will be up to individual packages to actually
provide code which makes use of it. Individual package maintainers are
encouraged to benchmark their packages after recompilation, and
provide the optimized variants if useful. (I.e. the code in question
is measureably faster '''and''' the program is ran often enough for
this to make a difference.)
The Change Owners will implement the packaging changes for a few
packages while developing the general mechanism and will submit those
as pull requests. Other maintainers are asked to do the same for their
packages.
Optimized variants of programs and libraries MAY be packaged in a
separate subpackage. The general packaging rules should be applied,
i.e. a separate package or packages SHOULD be created if it is files
are large enough.
Available benchmark results [2,4] are narrow and not very convincing.
We should plan an evaluation of results after one release. If it
turns out that the real gains are too small, we can scrap the effort.
On the other hand, we should also consider other architectures. For
example, microarchitecture levels `z{14,15}` for `s390x` or
`power{9,10}` for `ppc64le`. Other architectures are not included in
this Change Proposal to reduce its scope.
While I realize this is intended as an amd64 specific change, I'm
interested in helping to assure the infrastructure is in place for
similar testing of aarch64 packages, since we have similar problems.
There remains a desire to support arm v8.0 machines (ex: the rpi4) into
the foreseeable future, but significant uplifts exist for some
packages/workloads with newer arch revisions. In most cases those
features are currently being enabled at runtime but have perf hits for
operations that traditionally are just part of the instruction stream.
Outline-atomics, which leverage the v8.2 atomics are one such example,
but also SVE (vectors, used for crypto, regex, etc), and more recently
the v8.8 CPY (memcpy) should all ideally be inline.
So, while some other organizations have moved their platform/OSs to a
v8.2 baseline, it would be nice to have another fedora tool that can be
utilized to remain perf competitive.
== Feedback ==
== Benefit to Fedora ==
The developers who are interested in this kind of optimization work
can perform it within Fedora, without having to build separate
repositories. The users who have the appropriate hardware will gain
performance benefits. Faster code is also more energy-efficient. The
change will be automatic and transparent to users.
Note that other distributions use higher microarchitecture levels. For
example RHEL 9 uses x86-64-v2 as the baseline, RHEL 10 will use
x86-64-v3, and other distros provide optimized variants (OpenSUSE,
Arch Linux). We implement the same change in Fedora in a way that is
scoped more narrowly, but should provide the same performance and
energy benefits.
== Scope ==
* Proposal owners:
** Extend systemd to set the executable search path using the same
criteria as the dynamic linker.
** Implement packaging changes for at least one package with a library
and at least one package with executables and submit this as pull
requests.
** Provide a pull request for the Packaging Guidelines to describe the
changes listed in Description above.
* Other developers:
** Do benchmarking and implement packaging changes for other packages
if beneficial.
* Release engineering: [https://pagure.io/releng/issue/11864 #11864]
* Policies and guidelines: TBD.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
No impact.
== How To Test ==
* Use `/usr/bin/ld.so --help` to check which hwcaps are supported by the system.
* Install one or more packages which provide optimized code.
* Restart the system or re-login to reinitialize `$PATH`.
* Check that appropriate
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-60e0cc89b7 perl-Spreadsheet-ParseExcel-0.6600-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing rpki-client-8.8-1.el7 Details about builds: rpki-client-8.8-1.el7 (FEDORA-EPEL-2024-a6dd6ba515) OpenBSD RPKI validator to support BGP Origin Validation Update Information: # rpki-client 8.8- A failed manifest fetch could result in a `NULL` pointer dereference or a use after free. - Reject non-conforming RRDP delta elements that contain neither publish nor a withdraw element and fall back to the RRDP snapshot. - Refactoring and minor bug fixes in the warning display functions. ChangeLog: * Tue Jan 2 2024 Robert Scheck 8.8-1 - Upgrade to 8.8 (#2256244) References: [ 1 ] Bug #2256244 - rpki-client-8.8 is available https://bugzilla.redhat.com/show_bug.cgi?id=2256244 -- ___ 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
[Bug 2255608] perl-SQL-Translator-1.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255608 --- Comment #4 from Fedora Update System --- FEDORA-2024-1af96a979b has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1af96a979b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1af96a979b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255608 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255608%23c4 -- ___ 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 2256265] perl-bignum-0.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256265 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-bignum-0.67-1.fc40 Resolution|--- |ERRATA Last Closed||2024-01-02 21:24:12 --- Comment #2 from Fedora Update System --- FEDORA-2024-4676f827aa 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=2256265 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256265%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 2256150] perl-XML-Parser-2.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256150 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version||perl-XML-Parser-2.47-1.fc40 Status|MODIFIED|CLOSED Last Closed||2024-01-02 21:21:12 --- Comment #2 from Fedora Update System --- FEDORA-2024-e41a9aa5c6 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=2256150 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256150%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 2256265] perl-bignum-0.67 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256265 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-4676f827aa has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-4676f827aa -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2256265 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256265%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 2256150] perl-XML-Parser-2.47 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256150 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-e41a9aa5c6 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-e41a9aa5c6 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2256150 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256150%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
Re: Non responsive maintainer check for marxin
Thank you ! Em ter., 2 de jan. de 2024 às 17:05, Sandro escreveu: > On 02-01-2024 20:28, Priscila Gutierres wrote: > > Does any package depend on python-pebble? > > I could not find anything running repoquery --whatrequires python-pebble > > You need to query for `python3-pebble`. > > $ dnf repoquery --whatrequires python3-pebble > Last metadata expiration check: 0:04:03 ago on Tue 02 Jan 2024 20:57:02. > cvise-0:2.8.0-1.fc39.x86_64 > python3-bluepyopt-0:1.14.3-1.fc39.x86_64 > python3-bluepyopt-0:1.14.6-5.fc39.x86_64 > > I use `fedrq` these days. > > $ fedrq wr -s python3-pebble > cvise-2.9.0-1.fc40.src > python-bluepyopt-1.14.6-5.fc40.src > > -- Sandro > > -- > ___ > 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 > -- ___ 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: Non responsive maintainer check for marxin
On 02-01-2024 20:28, Priscila Gutierres wrote: Does any package depend on python-pebble? I could not find anything running repoquery --whatrequires python-pebble You need to query for `python3-pebble`. $ dnf repoquery --whatrequires python3-pebble Last metadata expiration check: 0:04:03 ago on Tue 02 Jan 2024 20:57:02. cvise-0:2.8.0-1.fc39.x86_64 python3-bluepyopt-0:1.14.3-1.fc39.x86_64 python3-bluepyopt-0:1.14.6-5.fc39.x86_64 I use `fedrq` these days. $ fedrq wr -s python3-pebble cvise-2.9.0-1.fc40.src python-bluepyopt-1.14.6-5.fc40.src -- Sandro -- ___ 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: Non responsive maintainer check for marxin
Does any package depend on python-pebble? I could not find anything running repoquery --whatrequires python-pebble On Tue, Jan 2, 2024 at 2:56 PM Ankur Sinha wrote: > Hi folks, > > Would anyone know how to contact @marxin? They only maintain the one > package, python-pebble, but it doesn't look like they've been active in > a while. The package did not see to have been updated at all since the > initial import: > > https://bugzilla.redhat.com/show_bug.cgi?id=2227456 > > and there are now new pending bugs that have not seen responses too: > https://bugzilla.redhat.com/show_bug.cgi?id=2250914 > > We've waited for responses to PRs in the past and then had to use proven > packager rights to update and maintain the package: > > https://src.fedoraproject.org/rpms/python-pebble/pull-request/2 > https://src.fedoraproject.org/rpms/python-pebble/commits/rawhide > > Since a Neuro-SIG package depends on it, we're happy to take it over. > > Here's what I could get from fedora-active-user: > > python fedora_active_user.py --user marxin --email mli...@suse.cz > --nofas > Last action on koji: >Fri, 15 Sep 2023 tag_package_owners entry created by humaton [still >active] > >Last package update on bodhi: > 2020-06-29 07:10:30 on package python-pebble-4.5.3-1.fc33 > Last actions performed according to fedmsg: > > Last email on mailing list: > ERROR:active-user:name 'mailinglist' is not defined > > > Here's the tracker bug: > https://bugzilla.redhat.com/show_bug.cgi?id=2256491 > > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > -- > ___ > 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 > -- ___ 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
Non responsive maintainer check for marxin
Hi folks, Would anyone know how to contact @marxin? They only maintain the one package, python-pebble, but it doesn't look like they've been active in a while. The package did not see to have been updated at all since the initial import: https://bugzilla.redhat.com/show_bug.cgi?id=2227456 and there are now new pending bugs that have not seen responses too: https://bugzilla.redhat.com/show_bug.cgi?id=2250914 We've waited for responses to PRs in the past and then had to use proven packager rights to update and maintain the package: https://src.fedoraproject.org/rpms/python-pebble/pull-request/2 https://src.fedoraproject.org/rpms/python-pebble/commits/rawhide Since a Neuro-SIG package depends on it, we're happy to take it over. Here's what I could get from fedora-active-user: python fedora_active_user.py --user marxin --email mli...@suse.cz --nofas Last action on koji: Fri, 15 Sep 2023 tag_package_owners entry created by humaton [still active] Last package update on bodhi: 2020-06-29 07:10:30 on package python-pebble-4.5.3-1.fc33 Last actions performed according to fedmsg: Last email on mailing list: ERROR:active-user:name 'mailinglist' is not defined Here's the tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=2256491 -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 7:20 PM Peter Robinson wrote:
>
> On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov
> wrote:
> >
> > On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson wrote:
> > >
> > > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov
> > > wrote:
> > > >
> > > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer
> > > > wrote:
> > > > >
> > > > > * David Abdurachmanov:
> > > > >
> > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones
> > > > > > wrote:
> > > > > >>
> > > > > >>
> > > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to
> > > > > >> raise it here to get the attention of the Fedora toolchain team ...
> > > > > >>
> > > > > >> Here's the bug:
> > > > > >>
> > > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179
> > > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41
> > > > > >> objects
> > > > > >>
> > > > > >> It refers to this change in binutils 2.41:
> > > > > >>
> > > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > > > > >>
> > > > > >> As far as I understand the issue (which is not too far) this mainly
> > > > > >> affects shipped *.o and *.a files (ie. static libraries and
> > > > > >> similar)
> > > > > >> which were compiled with binutils < 2.41, which either won't link
> > > > > >> correctly or will give a linker error when using GNU ld from
> > > > > >> binutils 2.41.
> > > > > >
> > > > > > Correction. This is broken in <= 2.41 (incl. the current stable
> > > > > > binutils release).
> > > > > >
> > > > > >>
> > > > > >> Unclear if it also affects *.so files (which would be a much more
> > > > > >> serious ABI break), and also if it affects most binaries or just a
> > > > > >> few. I initially thought this only affected programs using 128 bit
> > > > > >> ints, so didn't think it was too important, but after reading the
> > > > > >> commit I'm not sure that is really true.
> > > > > >
> > > > > > Nelson Chu committed (5 days ago) a change:
> > > > > >
> > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc
> > > > > >
> > > > > > This will accept whatever is produced by <= 2.41 and the final
> > > > > > binary
> > > > > > will be correct. There is also a new ld flag (--check-uleb128) which
> > > > > > can produce a warning if it detects an issue.
> > > > > >
> > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would
> > > > > > happen
> > > > > > before I start mass rebuilding, and that should fix this.
> > > > >
> > > > > Cc:ing Nick and Siddhesh for awareness.
> > > > >
> > > > > The current plan is to use binutils 2.41 for the mass rebuild.
> > > >
> > > > In Fedora/RISCV we typically end up using the latest available
> > > > binutils. We are slightly different from upstream/normal Fedora.
> > >
> > > Which is fine when you're an out of mainline architecture but these
> > > sorts of things need to be resolved well and truly before any
> > > incorporation can happen.
> >
> > 100% true. We have plenty of stuff that isn't yet submitted to the
> > official dist-git.
>
> Is that delta easily viewable somewhere?
Kinda.
If you list all the builds for the f40 tag in Fedora/RISCV Koji, and
then look for the .X.riscv64 pattern before %{?dist} you will get a
list of packages that are modified in some way. Today that's around
~277 packages. A good portion of those are easy fixes (e.g. a lot of
packages assume that valgrind is available on just any arch, and never
check %{valgrind_arches}). Some of the changes are bigger, like full
ports, that for one or another reason were not accepted upstream
(yet).
Not all the changes are good to for a PR. Thus some definitely need
some refinement to do the correct thing.
Then actual changes are here: http://fedora.riscv.rocks:3000/rpms/
Typically this should have a branch with "-riscv64" suffix, e.g.,
f38-riscv64 or main-riscv64.
I hope to reduce that to a minimum during Fedora 40, but I am not
making any promises.
Cheers,
david
>
> > I have been considering not going for 2.42 for Fedora 40, but we will
> > do this again one more time (hopefully it's the last time, but you
> > never know).
> >
> > > --
> > > ___
> > > 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
> > --
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
Re: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 5:15 PM David Abdurachmanov wrote: > > On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson wrote: > > > > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov > > wrote: > > > > > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer wrote: > > > > > > > > * David Abdurachmanov: > > > > > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones > > > > > wrote: > > > > >> > > > > >> > > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > > > > >> raise it here to get the attention of the Fedora toolchain team ... > > > > >> > > > > >> Here's the bug: > > > > >> > > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 > > > > >> objects > > > > >> > > > > >> It refers to this change in binutils 2.41: > > > > >> > > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > >> > > > > >> As far as I understand the issue (which is not too far) this mainly > > > > >> affects shipped *.o and *.a files (ie. static libraries and similar) > > > > >> which were compiled with binutils < 2.41, which either won't link > > > > >> correctly or will give a linker error when using GNU ld from > > > > >> binutils 2.41. > > > > > > > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > > > > binutils release). > > > > > > > > > >> > > > > >> Unclear if it also affects *.so files (which would be a much more > > > > >> serious ABI break), and also if it affects most binaries or just a > > > > >> few. I initially thought this only affected programs using 128 bit > > > > >> ints, so didn't think it was too important, but after reading the > > > > >> commit I'm not sure that is really true. > > > > > > > > > > Nelson Chu committed (5 days ago) a change: > > > > > > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > > > > > > > This will accept whatever is produced by <= 2.41 and the final binary > > > > > will be correct. There is also a new ld flag (--check-uleb128) which > > > > > can produce a warning if it detects an issue. > > > > > > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > > > > > before I start mass rebuilding, and that should fix this. > > > > > > > > Cc:ing Nick and Siddhesh for awareness. > > > > > > > > The current plan is to use binutils 2.41 for the mass rebuild. > > > > > > In Fedora/RISCV we typically end up using the latest available > > > binutils. We are slightly different from upstream/normal Fedora. > > > > Which is fine when you're an out of mainline architecture but these > > sorts of things need to be resolved well and truly before any > > incorporation can happen. > > 100% true. We have plenty of stuff that isn't yet submitted to the > official dist-git. Is that delta easily viewable somewhere? > I have been considering not going for 2.42 for Fedora 40, but we will > do this again one more time (hopefully it's the last time, but you > never know). > > > -- > > ___ > > 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 > -- > ___ > 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 -- ___ 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 6:26 PM Peter Robinson wrote: > > On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov > wrote: > > > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer wrote: > > > > > > * David Abdurachmanov: > > > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones > > > > wrote: > > > >> > > > >> > > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > > > >> raise it here to get the attention of the Fedora toolchain team ... > > > >> > > > >> Here's the bug: > > > >> > > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > > > >> > > > >> It refers to this change in binutils 2.41: > > > >> > > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > >> > > > >> As far as I understand the issue (which is not too far) this mainly > > > >> affects shipped *.o and *.a files (ie. static libraries and similar) > > > >> which were compiled with binutils < 2.41, which either won't link > > > >> correctly or will give a linker error when using GNU ld from binutils > > > >> 2.41. > > > > > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > > > binutils release). > > > > > > > >> > > > >> Unclear if it also affects *.so files (which would be a much more > > > >> serious ABI break), and also if it affects most binaries or just a > > > >> few. I initially thought this only affected programs using 128 bit > > > >> ints, so didn't think it was too important, but after reading the > > > >> commit I'm not sure that is really true. > > > > > > > > Nelson Chu committed (5 days ago) a change: > > > > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > > > > > This will accept whatever is produced by <= 2.41 and the final binary > > > > will be correct. There is also a new ld flag (--check-uleb128) which > > > > can produce a warning if it detects an issue. > > > > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > > > > before I start mass rebuilding, and that should fix this. > > > > > > Cc:ing Nick and Siddhesh for awareness. > > > > > > The current plan is to use binutils 2.41 for the mass rebuild. > > > > In Fedora/RISCV we typically end up using the latest available > > binutils. We are slightly different from upstream/normal Fedora. > > Which is fine when you're an out of mainline architecture but these > sorts of things need to be resolved well and truly before any > incorporation can happen. 100% true. We have plenty of stuff that isn't yet submitted to the official dist-git. I have been considering not going for 2.42 for Fedora 40, but we will do this again one more time (hopefully it's the last time, but you never know). > -- > ___ > 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 -- ___ 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 2:05 PM David Abdurachmanov wrote: > > On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer wrote: > > > > * David Abdurachmanov: > > > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones > > > wrote: > > >> > > >> > > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > > >> raise it here to get the attention of the Fedora toolchain team ... > > >> > > >> Here's the bug: > > >> > > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > > >> > > >> It refers to this change in binutils 2.41: > > >> > > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > >> > > >> As far as I understand the issue (which is not too far) this mainly > > >> affects shipped *.o and *.a files (ie. static libraries and similar) > > >> which were compiled with binutils < 2.41, which either won't link > > >> correctly or will give a linker error when using GNU ld from binutils > > >> 2.41. > > > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > > binutils release). > > > > > >> > > >> Unclear if it also affects *.so files (which would be a much more > > >> serious ABI break), and also if it affects most binaries or just a > > >> few. I initially thought this only affected programs using 128 bit > > >> ints, so didn't think it was too important, but after reading the > > >> commit I'm not sure that is really true. > > > > > > Nelson Chu committed (5 days ago) a change: > > > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > > > This will accept whatever is produced by <= 2.41 and the final binary > > > will be correct. There is also a new ld flag (--check-uleb128) which > > > can produce a warning if it detects an issue. > > > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > > > before I start mass rebuilding, and that should fix this. > > > > Cc:ing Nick and Siddhesh for awareness. > > > > The current plan is to use binutils 2.41 for the mass rebuild. > > In Fedora/RISCV we typically end up using the latest available > binutils. We are slightly different from upstream/normal Fedora. Which is fine when you're an out of mainline architecture but these sorts of things need to be resolved well and truly before any incorporation can happen. -- ___ 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: rpmbuild core dumps
Florian Weimer writes: * Sam Varshavchik: > Stephen Smoogen writes: > >>https://github.com/rpm-software-management/rpm/issues/ >>2826>https://github.com/rpm-software-management/rpm/issues/2826 >> >> >> And thanks for opening a bug. I will watch to see what happens. > > I'm genuinely curious. Am I really the only one seeing this? The bug > seems fairly clear cut to me. What the heck. I suspect most of us package only files from one user, so the cache never needs evicting? You know, I think you're right. You need to put files into rpms that have different user and group ownership. Nearly all packages likely %defattr away all files to the same user and group id the race condition never gets triggered. The race condition occurs when the next file that gets added to the rpm is specified to have a different user or group ownership from the previous file. pgpehJrVvEXHx.pgp 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: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Fri, Dec 29, 2023 at 03:20:45PM -0600, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > But building packages is just one thing. Those packages would need > > to be distributed, causing additional load on mirrors and archives. > > Our mirrors would not be keen on seeing this increase. > > You're adding binaries, so you're either increasing the size of existing > packages or adding alternate packages. The size increase will be there > either way; the difference is that with separate packages, not everybody > will be downloading all the content (so easier on the mirrors than just > bigger packages containing multiple binaries). > > So if distribution is a concern, separate packages is a plus, not a > minus. We don't have a mechanism in dnf/rpm to mix & match, i.e. to select from one microarchitecture if available and from a different one otherwise. So if we were to provide e.g. a -v2 variant, then it'd have to provide _all_ packages. In the proposed scheme, we only provide additional packages for select packages. > > And then there's a question of how those packages would be consumed: > > firstly, the installer would need to be modified to pick the variant > > at installation time, and secondly, such an installation could never > > be used with a different CPU, the initial choice would be locked in. > > It's not like we haven't had this before. Yes, it was annoying, but it > wasn't THAT big of an issue. There is certainly more than one way to skin this particular cat. I don't expect most users to know which microarchitectures are supported by their CPU. We are always trying to make the installer as simple as possible so we shouldn't add a very complex technical question. One of the advantages of the proposed scheme is that we should be able to make it work transparently and automatically for the end users. I know that my approach is different then what other distros have tried: CentoOS/RHEL simply upgraded to a higher baseline and lost support for some CPUs, OpenSUSE/Ubuntu/Arch provide alternative repos which need to be explicitly selected by users. If the proposal gets accepted, we will be able to compare. Zbyszek -- ___ 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 2256130] perl-autodie-2.37 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256130 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version||perl-autodie-2.37-1.fc40 Status|MODIFIED|CLOSED Last Closed||2024-01-02 16:06:11 --- Comment #2 from Fedora Update System --- FEDORA-2024-06ae13815a 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=2256130 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256130%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 2256130] perl-autodie-2.37 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256130 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-06ae13815a has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-06ae13815a -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2256130 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256130%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
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee
Dear all, You are kindly invited to the meeting: EPEL Steering Committee on 2024-01-03 from 16:00:00 to 17:00:00 US/Eastern At fedora-meet...@chat.fedoraproject.org The meeting will be about: https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org This is the weekly EPEL Steering Committee Meeting. A general agenda is the following: #topic aloha #topic EPEL Issues https://pagure.io/epel/issues * https://pagure.io/epel/issues?tags=meeting=Open #topic Old Business (if needed) #topic General Issues / Open Floor Source: https://calendar.fedoraproject.org//meeting/9854/ -- ___ 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: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, 2 Jan 2024 at 10:24, Vít Ondruch wrote:
>
> Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
>
>
>
> On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote:
>
>>
>> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>>
>> The dynamic linker already has the `glibc-hwcaps` mechanism to load
>> optimized implementations of ''shared objects'' [3]. This means that
>> packages can provide optimized libraries and they linker will be
>> automatically load them from separate directories if appropriate.
>> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>>
>>
>>
>> Is this something specific to x86_64 that the libs needs to be nested in
>> a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use
>> e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
>> universal.
>>
>>
> Adding directories to the /usr sub-space generally gets bogged down into
> 'You are polluting my name-space' arguments which get no-where because some
> of the people getting angry is having to live with some 3rd party rules and
> regulations which stipulated how things look and will only get updated once
> a decade or so. [The same goes with subdirectories in /usr/bin etc where it
> causes similar problems.] There tends to be no 'general' case which works
> unless it gets 'agreed' upon by some outside of the distro body that
> publishes 'versioned' standards.
>
>
> Checking what Debian does, they have paths such as
> `/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
>
Do they have /usr/bin/{arch} directories also? I thought they did the
/usr/lib/{arch-os-type}/ for libraries to deal with multiarch (aka x86_32,
x86_64, etc) libs . the main item will be if we are following
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s04.html or if there
is enough variation in
https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html
to allow subdirectories in /usr/bin.
It would seem that in the freedesktop version /usr/lib/{arch-id} is
acceptable and I think in the FHS-3.0, then /usr/lib{qualifier} is ok.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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 2256485] perl-DateTime-Format-RFC3339-1.6.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256485 --- Comment #2 from Upstream Release Monitoring --- the-new-hotness/release-monitoring.org's scratch build of perl-DateTime-Format-RFC3339-1.6.0-1.fc38.src.rpm for rawhide completed http://koji.fedoraproject.org/koji/taskinfo?taskID=96144 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2256485 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256485%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 2256485] perl-DateTime-Format-RFC3339-1.6.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256485 --- Comment #1 from Upstream Release Monitoring --- Created attachment 2006849 --> https://bugzilla.redhat.com/attachment.cgi?id=2006849=edit Update to 1.6.0 (#2256485) -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2256485 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256485%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 2256485] New: perl-DateTime-Format-RFC3339-1.6.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256485 Bug ID: 2256485 Summary: perl-DateTime-Format-RFC3339-1.6.0 is available Product: Fedora Version: rawhide Status: NEW Component: perl-DateTime-Format-RFC3339 Keywords: FutureFeature, Triaged Assignee: xav...@bachelot.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, xav...@bachelot.org Target Milestone: --- Classification: Fedora Releases retrieved: 1.6.0 Upstream release that is considered latest: 1.6.0 Current version/release in rawhide: 1.4.0-1.fc40 URL: http://search.cpan.org/dist/DateTime-Format-RFC3339/ 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/2798/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-DateTime-Format-RFC3339 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2256485 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256485%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: Optimized Binaries for the AMD64 Architecture (System-Wide)
Dne 02. 01. 24 v 13:42 Stephen Smoogen napsal(a):
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote:
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
The dynamic linker already has the `glibc-hwcaps` mechanism to load
optimized implementations of ''shared objects'' [3]. This means that
packages can provide optimized libraries and they linker will be
automatically load them from separate directories if appropriate.
(For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Is this something specific to x86_64 that the libs needs to be
nested in a place such as
`/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
`/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
universal.
Adding directories to the /usr sub-space generally gets bogged down
into 'You are polluting my name-space' arguments which get no-where
because some of the people getting angry is having to live with some
3rd party rules and regulations which stipulated how things look and
will only get updated once a decade or so. [The same goes with
subdirectories in /usr/bin etc where it causes similar problems.]
There tends to be no 'general' case which works unless it gets
'agreed' upon by some outside of the distro body that publishes
'versioned' standards.
Checking what Debian does, they have paths such as
`/usr/lib/x86_64-linux-gnu/`. So we would not be alone.
Vít
Vít
--
___
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
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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
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
[Bug 2241294] perl-Authen-Krb5-1.9-42.fc40 FTBFS: Krb5.xs:492:15: error: implicit declaration of function ‘krb5_gen_portaddr’
https://bugzilla.redhat.com/show_bug.cgi?id=2241294 Miro Hrončok changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2024-01-02 15:17:13 --- Comment #2 from Miro Hrončok --- Automation has figured out the package is retired in rawhide. If you like it to be unretired, please open a ticket at https://pagure.io/releng/new_issue?template=package_unretirement -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2241294 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202241294%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 2255972] perl-Math-BigInt-GMP-1.7000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255972 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|MODIFIED|CLOSED Fixed In Version||perl-Math-BigInt-GMP-1.7000 ||-1.fc40 Last Closed||2024-01-02 15:12:11 --- Comment #4 from Fedora Update System --- FEDORA-2024-5c2c0dec43 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=2255972 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255972%23c4 -- ___ 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 2255972] perl-Math-BigInt-GMP-1.7000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255972 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-2024-5c2c0dec43 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-5c2c0dec43 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255972 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255972%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 2255963] perl-Math-BigInt-FastCalc-0.5016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255963 Fedora Update System changed: What|Removed |Added Status|MODIFIED|CLOSED Fixed In Version||perl-Math-BigInt-FastCalc-0 ||.501.600-1.fc40 Resolution|--- |ERRATA Last Closed||2024-01-02 14:57:18 --- Comment #2 from Fedora Update System --- FEDORA-2024-7c93466804 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=2255963 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255963%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 2255963] perl-Math-BigInt-FastCalc-0.5016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255963 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-7c93466804 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c93466804 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255963 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255963%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 2255972] perl-Math-BigInt-GMP-1.7000 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255972 Bug 2255972 depends on bug 2255925, which changed state. Bug 2255925 Summary: perl-Math-BigInt-2.003001 is available https://bugzilla.redhat.com/show_bug.cgi?id=2255925 What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255972 -- ___ 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 2255925] perl-Math-BigInt-2.003001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255925 Fedora Update System changed: What|Removed |Added Fixed In Version||perl-Math-BigInt-2.0030.01- ||1.fc40 Status|MODIFIED|CLOSED Resolution|--- |ERRATA Last Closed||2024-01-02 14:24:11 --- Comment #2 from Fedora Update System --- FEDORA-2024-0cdbd2e721 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=2255925 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255925%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 2255925] perl-Math-BigInt-2.003001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255925 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-0cdbd2e721 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-0cdbd2e721 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255925 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255925%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
Re: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 3:54 PM Florian Weimer wrote: > > * David Abdurachmanov: > > > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones wrote: > >> > >> > >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to > >> raise it here to get the attention of the Fedora toolchain team ... > >> > >> Here's the bug: > >> > >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > >> > >> It refers to this change in binutils 2.41: > >> > >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > >> > >> As far as I understand the issue (which is not too far) this mainly > >> affects shipped *.o and *.a files (ie. static libraries and similar) > >> which were compiled with binutils < 2.41, which either won't link > >> correctly or will give a linker error when using GNU ld from binutils 2.41. > > > > Correction. This is broken in <= 2.41 (incl. the current stable > > binutils release). > > > >> > >> Unclear if it also affects *.so files (which would be a much more > >> serious ABI break), and also if it affects most binaries or just a > >> few. I initially thought this only affected programs using 128 bit > >> ints, so didn't think it was too important, but after reading the > >> commit I'm not sure that is really true. > > > > Nelson Chu committed (5 days ago) a change: > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > > > This will accept whatever is produced by <= 2.41 and the final binary > > will be correct. There is also a new ld flag (--check-uleb128) which > > can produce a warning if it detects an issue. > > > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > > before I start mass rebuilding, and that should fix this. > > Cc:ing Nick and Siddhesh for awareness. > > The current plan is to use binutils 2.41 for the mass rebuild. In Fedora/RISCV we typically end up using the latest available binutils. We are slightly different from upstream/normal Fedora. Cheers, david > > 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
[Bug 2255608] perl-SQL-Translator-1.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255608 --- Comment #3 from Fedora Update System --- FEDORA-2024-1af96a979b has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-1af96a979b -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255608 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255608%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 2255608] perl-SQL-Translator-1.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255608 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version||perl-SQL-Translator-1.64-1. ||fc40 Status|MODIFIED|CLOSED Last Closed||2024-01-02 14:03:11 --- Comment #2 from Fedora Update System --- FEDORA-2024-33afa9d836 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=2255608 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255608%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
Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
* Vít Ondruch:
> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>
>
> The dynamic linker already has the `glibc-hwcaps` mechanism to load
> optimized implementations of ''shared objects'' [3]. This means that
> packages can provide optimized libraries and they linker will be
> automatically load them from separate directories if appropriate.
> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>
> Is this something specific to x86_64 that the libs needs to be nested
> in a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not
> use e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something
> more universal.
The path layout was chosen so that ldconfig can auto-detect the
directories and process their contents, without having to know which
subdirectories are recognized by the dynamic loader (and in fact,
arbitrary directories can be added using ld.so --glibc-hwcaps-prepend).
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
[Bug 2255608] perl-SQL-Translator-1.64 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2255608 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2024-33afa9d836 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-33afa9d836 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2255608 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202255608%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
Re: RISC-V ABI issue with ULEB128
* David Abdurachmanov: > On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones wrote: >> >> >> I'm not sure exactly the effect on RISC-V binaries, but I wanted to >> raise it here to get the attention of the Fedora toolchain team ... >> >> Here's the bug: >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=31179 >> RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects >> >> It refers to this change in binutils 2.41: >> >> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc >> >> As far as I understand the issue (which is not too far) this mainly >> affects shipped *.o and *.a files (ie. static libraries and similar) >> which were compiled with binutils < 2.41, which either won't link >> correctly or will give a linker error when using GNU ld from binutils 2.41. > > Correction. This is broken in <= 2.41 (incl. the current stable > binutils release). > >> >> Unclear if it also affects *.so files (which would be a much more >> serious ABI break), and also if it affects most binaries or just a >> few. I initially thought this only affected programs using 128 bit >> ints, so didn't think it was too important, but after reading the >> commit I'm not sure that is really true. > > Nelson Chu committed (5 days ago) a change: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > This will accept whatever is produced by <= 2.41 and the final binary > will be correct. There is also a new ld flag (--check-uleb128) which > can produce a warning if it detects an issue. > > I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen > before I start mass rebuilding, and that should fix this. Cc:ing Nick and Siddhesh for awareness. The current plan is to use binutils 2.41 for the mass rebuild. 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
[rpms/perl-SQL-Translator] PR #3: 1.64 bump (rhbz#2255608)
jplesnik merged a pull-request against the project: `perl-SQL-Translator` that you are following. Merged pull-request: `` 1.64 bump (rhbz#2255608) `` https://src.fedoraproject.org/rpms/perl-SQL-Translator/pull-request/3 -- ___ 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
[rpms/perl-SQL-Translator] PR #3: 1.64 bump (rhbz#2255608)
jplesnik opened a new pull-request against the project: `perl-SQL-Translator` that you are following: `` 1.64 bump (rhbz#2255608) `` To reply, visit the link below https://src.fedoraproject.org/rpms/perl-SQL-Translator/pull-request/3 -- ___ 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: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, Jan 2, 2024 at 1:20 PM Vít Ondruch wrote:
>
>
> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>
> The dynamic linker already has the `glibc-hwcaps` mechanism to load
> optimized implementations of ''shared objects'' [3]. This means that
> packages can provide optimized libraries and they linker will be
> automatically load them from separate directories if appropriate.
> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>
>
> Is this something specific to x86_64 that the libs needs to be nested in a
> place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
> `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more universal.
IIRC this is not specific to x86_64 (other arches can also use it).
This is specific to glibc implementation (implemented 4 years ago
IIRC). The paths glibc dynamic loader looks for shared libraries does
not change, but it will check specific subdirectories based on your
hardware capabilities.
I believe openSUSE already ships optional architecture optimized
packages, which use exactly this glibc feature.
david
>
> Vít
>
> --
> ___
> 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
--
___
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
flrig: C++ warning help
While it's only a warning, I would like to "fix" it. When building flrig I'm seeing the following: widgets/font_browser.cxx: In member function '__ct_base .constprop': widgets/font_browser.cxx:202:52: warning: argument 1 value '18446744073709551615' exceeds maximum object size 9223372036854775807 [-Walloc-size-larger-than=] 202 | font_pairs = new font_pair[numfonts]; |^ The code can be found here: https://sourceforge.net/p/fldigi/flrig/ci/master/tree/src/widgets/font_browser.cxx#l201 Any hints would be appreciated. Thanks, Richard -- ___ 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: RISC-V ABI issue with ULEB128
On Tue, Jan 2, 2024 at 1:09 PM Richard W.M. Jones wrote: > > > I'm not sure exactly the effect on RISC-V binaries, but I wanted to > raise it here to get the attention of the Fedora toolchain team ... > > Here's the bug: > > https://sourceware.org/bugzilla/show_bug.cgi?id=31179 > RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects > > It refers to this change in binutils 2.41: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc > > As far as I understand the issue (which is not too far) this mainly > affects shipped *.o and *.a files (ie. static libraries and similar) > which were compiled with binutils < 2.41, which either won't link > correctly or will give a linker error when using GNU ld from binutils 2.41. Correction. This is broken in <= 2.41 (incl. the current stable binutils release). > > Unclear if it also affects *.so files (which would be a much more > serious ABI break), and also if it affects most binaries or just a > few. I initially thought this only affected programs using 128 bit > ints, so didn't think it was too important, but after reading the > commit I'm not sure that is really true. Nelson Chu committed (5 days ago) a change: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc This will accept whatever is produced by <= 2.41 and the final binary will be correct. There is also a new ld flag (--check-uleb128) which can produce a warning if it detects an issue. I plan/hope to use binutils 2.42 in Fedora/RISCV 40. That would happen before I start mass rebuilding, and that should fix this. > > There's been discussion about adding an ELF tag, but that seems very > problematic to me: > https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/414 Yeah. I doubt we need a tag. I don't think it solves anything. Nelson commit (i.e. workaround) + mass rebuild should resolve any inconveniences AFAIK. Cheers, david > > Rich. > > -- > 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 -- ___ 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: Optimized Binaries for the AMD64 Architecture (System-Wide)
On Tue, 2 Jan 2024 at 06:21, Vít Ondruch wrote:
>
> Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
>
> The dynamic linker already has the `glibc-hwcaps` mechanism to load
> optimized implementations of ''shared objects'' [3]. This means that
> packages can provide optimized libraries and they linker will be
> automatically load them from separate directories if appropriate.
> (For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
>
>
>
> Is this something specific to x86_64 that the libs needs to be nested in a
> place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use e.g.
> `/usr/x86-64-v{2,3,4}/lib`
> directories instead? Or something more universal.
>
>
Adding directories to the /usr sub-space generally gets bogged down into
'You are polluting my name-space' arguments which get no-where because some
of the people getting angry is having to live with some 3rd party rules and
regulations which stipulated how things look and will only get updated once
a decade or so. [The same goes with subdirectories in /usr/bin etc where it
causes similar problems.] There tends to be no 'general' case which works
unless it gets 'agreed' upon by some outside of the distro body that
publishes 'versioned' standards.
> Vít
> --
> ___
> 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
>
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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: 20240102.n.0 changes
OLD: Fedora-Rawhide-20240101.n.0 NEW: Fedora-Rawhide-20240102.n.0 = SUMMARY = Added images:5 Dropped images: 2 Added packages: 5 Dropped packages:0 Upgraded packages: 36 Downgraded packages: 0 Size of added packages: 3.20 MiB Size of dropped packages:0 B Size of upgraded packages: 1.80 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -66.67 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Container_Minimal_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20240102.n.0.ppc64le.tar.xz Image: Workstation live aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-Rawhide-20240102.n.0.iso Image: Workstation live-osbuild x86_64 Path: Workstation/x86_64/iso/Fedora-Workstation-Live-osb-Rawhide-20240102.n.0.x86_64.iso Image: Jam_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Jam_KDE-Live-x86_64-Rawhide-20240102.n.0.iso Image: Workstation live-osbuild aarch64 Path: Workstation/aarch64/iso/Fedora-Workstation-Live-osb-Rawhide-20240102.n.0.aarch64.iso = DROPPED IMAGES = Image: KDE live aarch64 Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240101.n.0.iso Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20240101.n.0.iso = ADDED PACKAGES = Package: krdp-5.27.80~git20231227.4931015-1.fc40 Summary: Library for creating an RDP server RPMs:krdp krdp-devel krdp-server Size:770.71 KiB Package: python-esbonio-0.16.3-1.fc40 Summary: A Language Server for Sphinx projects RPMs:python3-esbonio python3-esbonio+dev python3-esbonio+test python3-esbonio+typecheck Size:328.23 KiB Package: python-geodatasets-2023.12.0-1.fc40 Summary: Spatial data examples RPMs:python3-geodatasets Size:43.72 KiB Package: python-types-pygments-2.17.0.0-1.fc40 Summary: Typing stubs for Pygments RPMs:python3-types-pygments Size:30.24 KiB Package: zimpl-3.5.3-1.fc40 Summary: Zuse Institut Mathematical Programming Language RPMs:libzimpl libzimpl-devel zimpl Size:2.05 MiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: alglib-4.01.0-1.fc40 Old package: alglib-4.00.0-2.fc39 Summary: A numerical analysis and data processing library RPMs: alglib alglib-devel alglib-doc Size: 9.57 MiB Size change: 678.34 KiB Changelog: * Mon Jan 01 2024 Sandro Mani - 4.01.0-1 - Update to 4.01.0 Package: atasm-1.23-1.fc40 Old package: atasm-1.09-6.fc39 Summary: 6502 cross-assembler RPMs: atasm Size: 328.94 KiB Size change: 51.46 KiB Changelog: * Mon Jan 01 2024 Dan Hor??k - 1.24-1 - update to 1.23 from an active fork Package: catch-3.5.1-1.fc40 Old package: catch-3.5.0-1.fc40 Summary: Modern, C++-native, header-only, framework for unit-tests, TDD and BDD RPMs: catch catch-devel Size: 2.88 MiB Size change: -11.34 KiB Changelog: * Mon Jan 01 2024 Tom Hughes - 3.5.1-1 - Update to 3.5.1 upstream release Package: contour-terminal-0.4.1.6292-1.fc40 Old package: contour-terminal-0.4.0.6245-1.fc40 Summary: Modern C++ Terminal Emulator RPMs: contour-terminal Size: 2.15 MiB Size change: -412 B Changelog: * Wed Dec 20 2023 Maja Massarini - 0.4.0.6245-2 - Add upstream_tag_template in .packit.yaml * Wed Dec 20 2023 topazus - 0.4.0.6245-3 - remove the duplicate packit config file * Mon Jan 01 2024 topazus - 0.4.0.6245-4 - fix for unexisted file with new release 0.4.1.6292 * Mon Jan 01 2024 Packit - 0.4.1.6292-1 - [packit] 0.4.1.6292 upstream release - Resolves rhbz#2256368 Package: edgar-1.37-1.fc40 Old package: edgar-1.36-3.fc39 Summary: A platform game RPMs: edgar Size: 489.71 MiB Size change: -4.14 KiB Changelog: * Mon Jan 01 2024 Andrea Musuruane - 1.37-1 - Updated to new upstream release Package: ghostwriter-24.01.85-1.fc40 Old package: ghostwriter-23.08.2-1.fc40 Summary: Cross-platform, aesthetic, distraction-free Markdown editor RPMs: ghostwriter Size: 7.90 MiB Size change: 2.94 MiB Changelog: * Sat Dec 30 2023 Marie Loise Nolden - 24.01.85-1 - 24.01.85 Package: ginga-4.1.1-1.fc40 Old package: ginga-4.0.1-4.fc39 Summary: A scientific image viewer and toolkit RPMs: ginga python3-ginga python3-ginga+qt5 python3-ginga+recommended python3-ginga-examples Size: 7.66 MiB Size change: 3.81 KiB Changelog: * Tue Jan 02 2024 Sergio Pascual - 4.1.1-1 - Update to 4.1.1 - Using SPDX license name Package: gmsh-4.12.0-1.fc40 Old package: gmsh-4.11.1-7.fc40 Summary: A three-dimensional finite element mesh generator RPMs: gmsh gmsh-common gmsh-devel gmsh-doc gmsh-libs gmsh-mpich gmsh-mpich-devel gmsh-mpich-libs gmsh-openmpi gmsh-openmpi-devel gmsh-openmpi-libs python3-gmsh Size: 63.92 MiB Size change: 546.67 KiB
[Bug 2256405] perl-DateTime-Format-RFC3339-1.4.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256405 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Fixed In Version||perl-DateTime-Format-RFC333 ||9-1.4.0-1.fc40 Status|MODIFIED|CLOSED Last Closed||2024-01-02 11:42:11 --- Comment #4 from Fedora Update System --- FEDORA-2024-6392418c77 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=2256405 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256405%23c4 -- ___ 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 2256405] perl-DateTime-Format-RFC3339-1.4.0 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2256405 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #3 from Fedora Update System --- FEDORA-2024-6392418c77 has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-6392418c77 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2256405 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202256405%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
Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)
Dne 28. 12. 23 v 17:12 Aoife Moloney napsal(a):
The dynamic linker already has the `glibc-hwcaps` mechanism to load
optimized implementations of ''shared objects'' [3]. This means that
packages can provide optimized libraries and they linker will be
automatically load them from separate directories if appropriate.
(For AMD64, this is `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`.)
Is this something specific to x86_64 that the libs needs to be nested in
a place such as `/usr/lib64/glibc-hwcaps/x86-64-v{2,3,4}/`? Why not use
e.g. `/usr/x86-64-v{2,3,4}/lib` directories instead? Or something more
universal.
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
RISC-V ABI issue with ULEB128
I'm not sure exactly the effect on RISC-V binaries, but I wanted to raise it here to get the attention of the Fedora toolchain team ... Here's the bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31179 RISC-V: The SET/ADD/SUB fix breaks ABI compatibility with 2.41 objects It refers to this change in binutils 2.41: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=73d931e560059a87d76f528fafbb4270a98746bc As far as I understand the issue (which is not too far) this mainly affects shipped *.o and *.a files (ie. static libraries and similar) which were compiled with binutils < 2.41, which either won't link correctly or will give a linker error when using GNU ld from binutils 2.41. Unclear if it also affects *.so files (which would be a much more serious ABI break), and also if it affects most binaries or just a few. I initially thought this only affected programs using 128 bit ints, so didn't think it was too important, but after reading the commit I'm not sure that is really true. There's been discussion about adding an ELF tag, but that seems very problematic to me: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/414 Rich. -- 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: rpmbuild core dumps
On 1/2/24 11:49, Florian Weimer wrote: * Sam Varshavchik: Stephen Smoogen writes: https://github.com/rpm-software-management/rpm/issues/ 2826>https://github.com/rpm-software-management/rpm/issues/2826 And thanks for opening a bug. I will watch to see what happens. I'm genuinely curious. Am I really the only one seeing this? The bug seems fairly clear cut to me. What the heck. I suspect most of us package only files from one user, so the cache never needs evicting? Indeed. Technically the "thread-unsafe" bug has been there since rpm 4.15 which was the first version to parallelize the package generation. It's just that 4.19 eliminates some code that has previously managed to more or less mask it it seems. It could've manifested as silent user/group name corruption before this AFAICS. - Panu - -- ___ 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
* Solomon Peachy via devel: > On Fri, Dec 22, 2023 at 10:27:55PM +0100, Florian Weimer wrote: >> >> gutenprint jpopelka jridky twaugh zdohnal >> > ...FWIW as of a few minutes ago this should be resolved upstream. >> >> Thanks, I can confirm this fixes the issue for the Fedora package as >> well. Should I push this to rawhide? It makes tracking easier for us. > > Yes please! > > There's no good reason for not having rawhide track Gutenprint upstream. > > IMO it should get pulled into current Fedora versions too; the first > thing I tell anyone reporting an issue is to rebuild from current > sources. (Granted most of those users are on EL/LTS-type distros..) Oh, I meant to backport just this one fix. I'll look into that later this week. 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
Re: rpmbuild core dumps
* Sam Varshavchik: > Stephen Smoogen writes: > >>https://github.com/rpm-software-management/rpm/issues/ >>2826>https://github.com/rpm-software-management/rpm/issues/2826 >> >> >> And thanks for opening a bug. I will watch to see what happens. > > I'm genuinely curious. Am I really the only one seeing this? The bug > seems fairly clear cut to me. What the heck. I suspect most of us package only files from one user, so the cache never needs evicting? 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
