Re: HEADSUP boost and tbb rebuilds starting in a side tag

[Dan Horák]

On Thu, 18 Jan 2024 22:15:18 +
Jonathan Wakely  wrote:

> On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely  wrote:
> >
> > I'll be building boost, tbb, and the packages that depend on them in
> > the f40-build-side-81691
> > side tag over the next few hours (in advance of the mass rebuild tomorrow).
> >
> > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > don't rebuild it in rawhide, we're building it in the side tag and
> > will merge it back to rawhide. If you need to update your package
> > before the mass rebuild, please let me and Patrick (CC'd) know and
> > your changes can be built in the side tag too.
> >
> > (Since there is overlap between the packages that depend on boost and
> > tbb I'm doing them all at once)
> > https://fedoraproject.org/wiki/Changes/F40Boost183
> > https://fedoraproject.org/wiki/Changes/F39TBB2020.3  
> 
> Most of the packages have now been rebuilt and will be merged to
> rawhide soon (I hope!).
> See https://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
> 
> The following packages failed to build, for the reasons shown. Some
> other packages that depend on these ones couldn't be built due to
> these failures. There are some others that weren't rebuild, like
> OpenImageIO and python-graph-tool, but the maintainers are aware.
> 
> 
> codeblocks
> needs non-existent squirrel-devel.i686

ah, we should have removed the dep after switching to the bundled
patched squirrel, fix in progress


Dan
--
___
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: Mass rebuild: git push --no-verify

[Michael J Gruber]

Am Do., 18. Jan. 2024 um 17:14 Uhr schrieb Jerry James :
>
> On Tue, Jan 16, 2024 at 3:32 PM Sérgio Basto  wrote:
> > You got mass rebuild script here [1] in massrebuildsinfo.py [2] you may
> > define what packages you are going to rebuild ,  in line 93 of mass-
> > rebuild.py [3] you got the list of packages that you go rebuild
> > and since line 132 [4] you have the commands that will run .
> > Is rpmdev-bumpspec that fails ?
>
> Thank you for the pointer, Sérgio.  I have opened
> https://pagure.io/releng/pull-request/11897.
>
> It is not rpmdev-bumpspec that fails.  That works just fine.  But any
> package that uses the %{fontpkgname1}, %{fontpkgname2}, ... macros
> requires --no-verify today when pushing to git, due to the referenced
> bug.  That's merely annoying for a human, but fatal to an automated
> build script that doesn't pass --noverify.

No, that's not the case. Please re-read the bug.

For *some* of the packages among those which use these macros (but
definitely not all), the python bindings to rpm do not expand that
macro whereas rpm itself does.

Since `spectool` uses the bindings, its check for the presence of all
source files fails if the source macro contains an unexpanded macro.
The packages build fine.

Whether it's the bindings' fault, or the spec files', or the
rpm-font-macros' is unclear at this point. In any case the check
*wrongly* indicates FTBFS.

Michael
--
___
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: -fcf-protection dropped from i686 compiler flags

[Florian Weimer]

* Michael Catanzaro:

> Unfortunately this is causing gating tests to fail for rawhide builds,
> e.g.:
>
> https://artifacts.dev.testing-farm.io/081ad2a3-76cd-4aa0-b95e-e870ff75a65c/
>
> Hardened: /usr/bin/pkcon: FAIL: cf-protection test because
> .note.gnu.property section did not contain the necessary flags

As Adam said, these reports should not alter the automatically
determined outcome of the gating process.  Updates for annobin are on
their way, to reduce confusion.

The -fcf-protection change did not change this because the markup was
gone before the change due to upstream glibc changes, which impact all
newly linked binaries due to their dependency on the statically linked
glibc startup code.

Thanks,
Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20240119.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20240117.n.0
NEW: Fedora-Rawhide-20240119.n.0

= SUMMARY =
Added images:9
Dropped images:  8
Added packages:  21
Dropped packages:6
Upgraded packages:   251
Downgraded packages: 0

Size of added packages:  133.25 MiB
Size of dropped packages:144.45 MiB
Size of upgraded packages:   16.39 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   57.81 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Sericea ociarchive aarch64
Path: Sericea/aarch64/images/Fedora-Sericea-Rawhide.20240119.n.0.ociarchive
Image: Silverblue ociarchive ppc64le
Path: 
Silverblue/ppc64le/images/Fedora-Silverblue-Rawhide.20240119.n.0.ociarchive
Image: Onyx ociarchive x86_64
Path: Onyx/x86_64/images/Fedora-Onyx-Rawhide.20240119.n.0.ociarchive
Image: Kinoite ociarchive x86_64
Path: Kinoite/x86_64/images/Fedora-Kinoite-Rawhide.20240119.n.0.ociarchive
Image: Silverblue ociarchive aarch64
Path: 
Silverblue/aarch64/images/Fedora-Silverblue-Rawhide.20240119.n.0.ociarchive
Image: Sericea ociarchive x86_64
Path: Sericea/x86_64/images/Fedora-Sericea-Rawhide.20240119.n.0.ociarchive
Image: LXDE live x86_64
Path: Spins/x86_64/iso/Fedora-LXDE-Live-x86_64-Rawhide-20240119.n.0.iso
Image: Silverblue ociarchive x86_64
Path: Silverblue/x86_64/images/Fedora-Silverblue-Rawhide.20240119.n.0.ociarchive
Image: Kinoite ociarchive aarch64
Path: Kinoite/aarch64/images/Fedora-Kinoite-Rawhide.20240119.n.0.ociarchive

= DROPPED IMAGES =
Image: Astronomy_KDE live x86_64
Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20240117.n.0.iso
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20240117.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20240117.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20240117.n.0.iso
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20240117.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20240117.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20240117.n.0.iso
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20240117.n.0.iso

= ADDED PACKAGES =
Package: foonathan-memory-0.7.3-1.fc40
Summary: STL compatible C++ memory allocator library
RPMs:foonathan-memory foonathan-memory-devel foonathan-memory-doc 
foonathan-memory-tools
Size:894.74 KiB

Package: python-snakemake-executor-plugin-cluster-generic-1.0.7-1.fc40
Summary: Generic cluster executor for Snakemake
RPMs:python3-snakemake-executor-plugin-cluster-generic
Size:22.78 KiB

Package: python-snakemake-interface-executor-plugins-8.1.3-2.fc40~bootstrap
Summary: Stable interface for interactions between Snakemake and its executor 
plugins
RPMs:python3-snakemake-interface-executor-plugins
Size:62.22 KiB

Package: python-snakemake-interface-storage-plugins-3.0.0-2.fc40~bootstrap
Summary: Stable interface for interactions between Snakemake and its storage 
plugins
RPMs:python3-snakemake-interface-storage-plugins
Size:42.76 KiB

Package: python-snakemake-storage-plugin-http-0.2.3-1.fc40
Summary: Snakemake storage plugin for downloading input files from HTTP(s)
RPMs:python3-snakemake-storage-plugin-http
Size:20.37 KiB

Package: python-snakemake-storage-plugin-s3-0.2.8-1.fc40
Summary: A Snakemake storage plugin for S3 API storage (AWS S3, MinIO, etc.)
RPMs:python3-snakemake-storage-plugin-s3
Size:22.06 KiB

Package: rocfft-6.0.0-2.fc40
Summary: ROCm Fast Fourier Transforms (FFT) library
RPMs:rocfft rocfft-devel rocfft-test
Size:2.46 MiB

Package: rocsolver-6.0.0-2.fc40
Summary: Next generation LAPACK implementation for ROCm platform
RPMs:rocsolver rocsolver-devel
Size:122.94 MiB

Package: rust-base32-0.4.0-1.fc40
Summary: Encoder/decoder for Rust
RPMs:rust-base32+default-devel rust-base32-devel
Size:22.21 KiB

Package: rust-bitfield0.13-0.13.2-1.fc40
Summary: Macros to generate bitfield-like struct
RPMs:rust-bitfield0.13+default-devel rust-bitfield0.13-devel
Size:31.08 KiB

Package: rust-fend-core-1.4.1-1.fc40
Summary: Arbitrary-precision unit-aware calculator
RPMs:rust-fend-core+default-devel rust-fend-core-devel
Size:120.36 KiB

Package: rust-mock_instant-0.3.1-1.fc40
Summary: Simple way to mock an std::time::Instant
RPMs:rust-mock_instant+default-devel rust-mock_instant+once_cell-devel 
rust-mock_instant+sync-devel rust-mock_instant-devel
Size:33.22 KiB

Package: rust-notify-debouncer-full-0.3.1-1.fc40
Summary: Notify event debouncer optimized for ease of use
RPMs:rust-notify-debouncer-full+crossbeam-channel-devel 
rust-notify-debouncer-full+crossbeam-devel 
rust-notify-debouncer-full+default-devel rust-notify

Vala workaround for C type errors now in rawhide

[Florian Weimer]

I patched the Vala compiler to generate pragmata to turn C type errors
into warnings again, basically restoring the GCC 13 behavior.  If Vala
packages regenerate their C sources using the Vala compiler, they should
now build again.

I submitted this patch upstream:

  codegen: Emit GCC diagnostics pragmata for GCC 14 compatibility
  

The pragma kludge isn't ideal, but I don't see an alternative.

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: HEADSUP boost and tbb rebuilds starting in a side tag

[Jonathan Wakely]

On Fri, 19 Jan 2024 at 01:27, Sérgio Basto  wrote:
>
> On Fri, 2024-01-19 at 00:21 +, Jonathan Wakely wrote:
> > On Fri, 19 Jan 2024 at 00:10, Jonathan Wakely 
> > wrote:
> > >
> > > On Wed, 17 Jan 2024 at 19:07, Jonathan Wakely 
> > > wrote:
> > > >
> > > > I'll be building boost, tbb, and the packages that depend on them
> > > > in
> > > > the f40-build-side-81691
> > > > side tag over the next few hours (in advance of the mass rebuild
> > > > tomorrow).
> > > >
> > > > If your package gets a "Rebuilt for Boost 1.83.0" comment, please
> > > > don't rebuild it in rawhide, we're building it in the side tag
> > > > and
> > > > will merge it back to rawhide. If you need to update your package
> > > > before the mass rebuild, please let me and Patrick (CC'd) know
> > > > and
> > > > your changes can be built in the side tag too.
> > >
> > > Please DO NOT build your package in rawhide if we're rebuilding it
> > > in
> > > the boost side tag. It will require another rebuild in the side tag
> > > and another bodhi update and delay the mass rebuild by several more
> > > hours while the gating tests run.
> >
> > OK, the side tag has been merged. Builds can be done in rawhide again
> > now.
>
>
> not yet , ttps://bodhi.fedoraproject.org/updates/FEDORA-2024-7c21b7afa2
> needs pass in all "Test Gating" or is running again "Test Gating" for
> new build(s)

(The new build that I think you caused btw!)

I'm not sure what's going on with the waiting status, but it's in
stable, and the new packages are in the buildroot and being used by
the mass rebuild.
--
___
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: Vala workaround for C type errors now in rawhide

[Florian Weimer]

* Florian Weimer:

> I patched the Vala compiler to generate pragmata to turn C type errors
> into warnings again, basically restoring the GCC 13 behavior.  If Vala
> packages regenerate their C sources using the Vala compiler, they should
> now build again.
>
> I submitted this patch upstream:
>
>   codegen: Emit GCC diagnostics pragmata for GCC 14 compatibility
>   
>
> The pragma kludge isn't ideal, but I don't see an alternative.

It has come to my attention that not all packages build from source even
if BuildRequires: vala is present.  You may have to add something like
this

  find -name '*.vala' -exec touch {} \;

to %prep to trigger recompilation.

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: Vala workaround for C type errors now in rawhide

[Michael Catanzaro]

Thank you!

--
___
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

SPDX Statistics - Lisa edition

[Miroslav Suchý]

Hot news:

https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_3 was approved.

I generated license analysis using scancode-toolkit for all remaining packages 
http://miroslav.suchy.cz/fedora/spdx-reports/

Now lets dive into numbers:

Two weeks ago we had:


* 23542 spec files in Fedora

* 30058license tags in all spec files

* 11715 tags have not been converted to SPDX yet

* 5266tags can be trivially converted using `license-fedora2spdx`

* Progress: 61,03% ░░ 100%

ELN subset:

290 out of 2457 packages are not converted yet (progress 88.20%)



Today we have:

* 23681 spec files in Fedora

* 30232license tags in all spec files

* 11697 tags have not been converted to SPDX yet

* 5264tags can be trivially converted using `license-fedora2spdx`

* Progress: 61,31% ░░ 100%

ELN subset:

250 out of 2439 packages are not converted yet (progress 89.75%)

Graph of these data with the burndown chart:

https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit?usp=sharing

The list of packages needed to be converted is here:

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final.txt

List by package maintainers is here

https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx-final-maintainers.txt

List of packages from ELN subset that needs to be converted:

https://pagure.io/copr/license-validate/blob/main/f/eln-not-migrated.txt

New version of fedora-license-data has been released. With 9 new licenses (plus some public domain declarations). 22 
licenses are waiting to be review by SPDX.org (and then to be added to fedora-license-data) 
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/?label_name%5B%5D=SPDX%3A%3Ablocked


Legal docs and especially

https://docs.fedoraproject.org/en-US/legal/allowed-licenses/

was updated too.


New projection when we will be finished is 2024-12-21 (+21 days from last 
report).  Pure linear approximation.

If your package does not have neither git-log entry nor spec-changelog entry mentioning SPDX and you know your license 
tag matches SPDX formula, you can put your package on ignore list


https://pagure.io/copr/license-validate/blob/main/f/ignore-packages.txt

Either pull-request or direct email to me is fine.


Why Lisa edition? On this day, in 1983 Apple released Apple Lisa - first personal computer with a GUI. Read about it on 
https://en.wikipedia.org/wiki/Apple_Lisa It is reminder that Apple was not always successful. And that revolutionary 
products does not mean economical success and can be obsoleted by products that are "good-enough".


Miroslav


--
___
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)

[Robert Marcano via devel]

On 12/28/23 1:25 PM, Robert Marcano wrote:

On 12/28/23 12:58 PM, Chris Adams wrote:

Once upon a time, Aoife Moloney  said:

Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)


Anything that depends on PATH entries is IMHO doomed to failure.  There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it.  Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.



Maybe replacing the /usr/bin related entries with a generic wrapper that 
launch the best binary from the per architecture directories.


Note: This may affect a few programs that use argv[0] for something 
meaningful.


The more I think about this, I am more convinced that /usr/bin installed 
binaries must do this redirection too even in the case the PATH is 
modified as this proposal states.


What about programs intentionally use absolute paths? These programs 
will not take advantage of the optimizations of the binary they are 
trying to start.


There many reasons for sometimes using an absolute path is agood idea, like:

1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation 
of the tool they call. I found a few on my installation, and their 
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo, 
CGI-BIN, etc.


Notice this PATH based optimization will only work when callers invoke 
the program by name only, relative paths will not get optimized either, 
a rare case but it could 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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Robert Marcano via devel]

On 1/19/24 12:58 PM, Robert Marcano wrote:

On 12/28/23 1:25 PM, Robert Marcano wrote:

On 12/28/23 12:58 PM, Chris Adams wrote:

Once upon a time, Aoife Moloney  said:

Systemd will be modified to insert the additional directories into the
`$PATH` environment variable (affecting all programs on the system)


Anything that depends on PATH entries is IMHO doomed to failure.  There
are way too many things that explicitly set PATH to "known" values (for
good and bad reasons) to be able to depend on extending it.  Heck, it
took a long time to get sudo just to include /usr/local/{bin,sbin}.



Maybe replacing the /usr/bin related entries with a generic wrapper 
that launch the best binary from the per architecture directories.


Note: This may affect a few programs that use argv[0] for something 
meaningful.


The more I think about this, I am more convinced that /usr/bin installed 
binaries must do this redirection too even in the case the PATH is 
modified as this proposal states.


What about programs intentionally use absolute paths? These programs 
will not take advantage of the optimizations of the binary they are 
trying to start.


There many reasons for sometimes using an absolute path is agood idea, 
like:


1. Security: avoid depending on a PATH that can be user manipulated.
2. Configuration files that allow to switch to alternate implementation 
of the tool they call. I found a few on my installation, and their 
defaults include /usr/bin absolute paths.
3. Programs that run inside PATH is reset for security like sudo, 
CGI-BIN, etc.


Notice this PATH based optimization will only work when callers invoke 
the program by name only, relative paths will not get optimized either, 
a rare case but it could happen.


I have a counter proposal without modifying $PATH:

With the already defined directories 
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ add two new ones:


  /usr/bin/glibc-hwcaps/x86-64
  /usr/bin/glibc-hwcaps/x86-64-dynamic

Applications with optimized binaries will continue to install them on 
/usr/bin/glibc-hwcaps/x86-64-v{2,3,4}/ but the non optimized version 
isn't installed on /usr/bin but on /usr/bin/glibc-hwcaps/x86-64.


/usr/bin/glibc-hwcaps/x86-64-dynamic will be a read only overlayfs 
mounted by systemd, stacked with x86-64v4 on top and x86-64 on the bottom.


There will not be /usr/bin binaries for the optimized packages but 
symlinks to /usr/bin/glibc-hwcaps/x86-64-dynamic


Advantages for systemd based environment:

1. The optimized binaries are available to all the system, without 
worrying about applications that reset $PATH, or executions by relative 
or absolute paths and not only by name.


2. Imagine if and application like Firefox (only an example) get a boost 
by having the main binary optimized. /usr/bin/firefox currently is a 
shell script, there is no way optimize it with the current proposal, 
only if the script duplicates the microachitecture selection logic. With 
this proposal, modifying /usr/lib64/firefox/firefox to point to 
/usr/bin/glibc-hwcaps/x86-64-dynamic/firefox could work to. In reality 
it can work for all binaries outside of $PATH.


There are two downsides I could find:

1. Fedora Container images must be build with 
/usr/bin/glibc-hwcaps/x86-64-dynamic being a symlink to 
/usr/bin/glibc-hwcaps/x86-64 in order to non optimized binaries to be 
the default. This current proposal doesn't optimize either for 
containers runtimes that don't run systemd inside the container. Maybe 
in the future if this kind of layout get adoption on other 
distributions, container runtimes could do the overlay mount by themselves


2. In the case of trying to rescue the system, the process to create a 
chroot from the installation media will need and extra bind mount for 
/usr/bin/glibc-hwcaps/x86-64-dynamic pointing to 
/usr/bin/glibc-hwcaps/x86-64


Note aside: I think that the Live CD image should get an script 
available that do the same rescue boot option when trying to build the 
disk tree on /mnt/sysimage, if that script were available on LiveCD, 
rescue operations would be easier.

--
___
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: fedora-distro-aliases - The easiest way to get numbers of active Fedora releases

[Stephen Gallagher]

On Thu, Jan 18, 2024 at 10:32 AM Stephen Gallagher  wrote:
>
> On Wed, Jan 17, 2024 at 5:58 AM Jakub Kadlcik  wrote:
> >
> > Hello,
> > I just wanted to quickly announce a small project I did in collaboration 
> > with the Packit folks.
> >
> > Do you have some tools or services that perform actions on all currently 
> > active Fedora releases? And do you have to manually update their list every 
> > time a new Fedora release is branched or EOLed? The fedora-distro-aliases 
> > will make your life easier.
> >
> > https://github.com/rpm-software-management/fedora-distro-aliases
> >
> > It defines aliases such as `fedora-stable`, `epel-all`, `fedora-latest`, 
> > etc. To evaluate them, it queries Bodhi, so they are always up-to-date (but 
> > the tradeoff is that it requires an internet connection). There are 
> > multiple examples in the project README but the usage is simple, e.g.:
> >
> > >>> from fedora_distro_aliases import get_distro_aliases
> > >>> aliases = get_distro_aliases()
> > >>> [x.namever for x in aliases["fedora-all"]]
> > ['fedora-38', 'fedora-39', 'fedora-rawhide']
> >
> > The package is already in Fedora, give it a shot,
>
> Thanks! I'll look into updating
> https://github.com/sgallagher/get-fedora-releases-action with this.

Scratch that, it appears that `pip3 install fedora_distro_aliases`
requires installing krb5 devel packages (and compiling it) on the
target system before it can be used. This had the effect in my testing
of increasing the time spent running my Action from ~10s to ~240s,
which is too big of an increase. Is there a good reason why you're
using the complete BodhiClient interface instead of just doing simple
HTTP requests against https://bodhi.fedoraproject.org/releases ?
--
___
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

Cancel build from mass rebuild?

[David Bold]

I noticed a while ago that bout++ is currently FTBFS, and one of the tests with 
mpich on s390x seems to get stuck in a dead lock, openmpi and other arches are 
having no issues.
I haven't managed to find a fix, and forgot to push a workaround that disables 
the tests. It seems I cannot cancel the build from the mass rebuild [1].

Can some one cancel the build for me? I think the timeout is quite late, and I 
do not want a stuck build waste all the compute time ...

Any hints on how to debug mpich related issues on s390x would of course also be 
appreciated :-)

Best,
David

[1] https://koji.fedoraproject.org/koji/buildinfo?buildID=2348630
--
___
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: Vala workaround for C type errors now in rawhide

[Florian Weimer]

* Florian Weimer:

> I patched the Vala compiler to generate pragmata to turn C type errors
> into warnings again, basically restoring the GCC 13 behavior.  If Vala
> packages regenerate their C sources using the Vala compiler, they should
> now build again.
>
> I submitted this patch upstream:
>
>   codegen: Emit GCC diagnostics pragmata for GCC 14 compatibility
>   
>
> The pragma kludge isn't ideal, but I don't see an alternative.

I had to disable int-conversion errors as well, via vala-0.56.14-3.fc40.
They occur when enums are used with generic types.

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: Cancel build from mass rebuild?

[Miro Hrončok]

On 19. 01. 24 20:39, David Bold wrote:

I noticed a while ago that bout++ is currently FTBFS, and one of the tests with 
mpich on s390x seems to get stuck in a dead lock, openmpi and other arches are 
having no issues.
I haven't managed to find a fix, and forgot to push a workaround that disables 
the tests. It seems I cannot cancel the build from the mass rebuild [1].

Can some one cancel the build for me? I think the timeout is quite late, and I 
do not want a stuck build waste all the compute time ...


Done.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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

Do you see any recent/new Segmentation faults when building your packages?

[Miro Hrončok]

I have *just* started seeing Segmentation faults when building Python in 
rawhide Koji. They weren't happening 2 hours ago.


I bisected the problem to:

Upgrading:
 binutils x86_64 2.41-28.fc40 local   26.4 MiB
   replacing binutils x86_64 2.41-26.fc40 fedora  26.4 MiB

And I reported https://bugzilla.redhat.com/2259285

However, is anything else impacted?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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 40 mass rebuild has begun

[Samyak Jain]

Hi all,

Per the Fedora Linux f40 schedule [1] we started a mass rebuild on
2024-01-17 for Fedora f40 but due to various reasons such as dnf
issues, and other side-tags not getting merged we had to stop it.
But we finally managed to overcome those, and we fired the mass rebuild today
We are running this mass rebuild for the changes listed in:

https://pagure.io/releng/issues?status=Open&tags=mass+rebuild&tags=f40&tags=changes

This mass rebuild is done in a side tag (f40-rebuild) and merged
when completed.

Failures can be seen
https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html


Things still need rebuilding
https://kojipkgs.fedoraproject.org/mass-rebuild/f40-need-rebuild.html


FTBFS (Fails To Build From Source) bugs will be filed after the
mass rebuild is complete.

Please let releng know if you see any bugs in the reporting.
You can contact releng in the #releng:fedoraproject.org room on Matrix,
by dropping an email to our list [2] or filing an issue in pagure [3].

This email template is also in https://pagure.io/releng if you wish to
propose improvements or changes to it.

Regards,
Samyak Jain
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[2] https://lists.fedoraproject.org/admin/lists/rel-eng.lists.fedoraproject.org/
[3] https://pagure.io/releng/
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@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