Re: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Florian Weimer]

* Andrea Bolognani:

> Wouldn't changing -mabi effectively make the result a new Fedora
> architecture? IIUC, binaries built with -mabi=lp64d wouldn't be able
> to load libraries built with -mabi=lp64dv and vice versa.
>
> If that's correct, then we can't simply have a single "riscv64"
> architecture: instead, we need to call what we have today
> riscv64_lp64d, and be ready for riscv64_lp64dv as well as whatever
> comes next.

Right.

> It would be somewhat similar to existing architectures that can be
> used in both Little-Endian (ppc64le) and Big-Endian (ppc64) modes.

With different paths, it would be more like i686 and x86_64.  That is,
you can build and run software for both variants from the same operating
system image.  That's not the case for ppc64 and ppc64le.

> This is quite different from just bumping the ISA baseline, where
> existing binaries and libraries are still usable in the new
> environment.

Right, changing the vector calling convention may change the size of
jmp_buf, and then you have a new ABI even if use of the vector features
is optional.

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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Florian Weimer]

* David Abdurachmanov:

> We most likely will not have ABIs installed in parallel, but we might
> change ABI. Currently Linux distributions target "RV64GC", but we
> don't really want that for the future RISC-V. I keep telling folks
> that "RV64GC" is already "a legacy" (10+ years old), but that's the
> major target for the next few years. We are scheduled to see some
> RVA22 SBCs this year.
>
> RV64GC -> RVA20 -> RVA22 -> RVA23 -> RVA24.
>
> That's how things evolved. RVA23 most likely will be ratified soonish.
> RVA24 is most likely the next major RISC-V Profile from RVI point of
> view (TBD). Server specifications are based on RVA23 (and will be
> updated to RVA24 [most likely]). This defines baseline ISA, optional
> extensions, etc.

Is there really an ABI change, though?  That would only happen if the
set of callee-saved registers grows, to include vector registers.
Adding new registers has compatibility problems on its own.

Fedora might want to switch to an ISA baseline that is incompatible with
all currently available CPUs, but that's not necessarily an ABI break as
such.

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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Florian Weimer]

* Andrea Bolognani:

> On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote:
>> There are multiple PRs and patches floating around that make RISC-V use
>> the /usr/lib64 directory, like other 64-bit ports.  However, RISC-V
>> recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and
>> various upstream projects follow that.
>>
>> I think we should follow upstream, so that it's possible to use Fedora
>> to do upstream development without patching the sources, or elaborate
>> Fedora-specific configure invocations.  The other reasons is to
>> future-proof the Fedora port against the arrival of an alternative ABI
>> that is not fully backwards-compatible (the same reason why the official
>> RISC-V documentation requires use of these paths).
>
> I just checked in a Debian riscv64 chroot and they don't seem to
> follow this recommendation:
>
>   # cat /etc/ld.so.conf.d/riscv64-linux-gnu.conf
>   /usr/local/lib/riscv64-linux-gnu
>   /lib/riscv64-linux-gnu
>   /usr/lib/riscv64-linux-gnu
>
> This matches what Debian does on all architectures, that is, install
> libraries under fully arch-qualified paths. If Debian doesn't stray
> from its usual practices for RISC-V, I'm not convinced that Fedora
> needs to either.

Debian is really not a good example here because they have not
upstreamed their path layout.

I really don't think it's a good idea to clutter dozens of spec files
with changes for what's arguably just a toy architecture today, with
plenty of CPU-incompatible changes still coming.

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: Fedora RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Florian Weimer]

* Daniel P. Berrangé:

> On Fri, Apr 19, 2024 at 02:21:57PM +0200, Florian Weimer wrote:
>> There are multiple PRs and patches floating around that make RISC-V use
>> the /usr/lib64 directory, like other 64-bit ports.  However, RISC-V
>> recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and
>> various upstream projects follow that.
>> 
>> I think we should follow upstream, so that it's possible to use Fedora
>> to do upstream development without patching the sources, or elaborate
>> Fedora-specific configure invocations.
>
> I'm not convinced that using /usr/lib64/lp64d would lead to
> *less* patching.
>
> Apps targetting Fedora are long used to having to adapt from
> using /usr/lib to /usr/lib64.

But that's largely baked into the upstream defaults by now (unlike the
Debian multi-arch paths).

> Introducing the use of /usr/lib64/lp64d instead, just for RiscV, feels
> likely to break expectations resulting in apps which build fine on all
> Fedora arches except for RiscV

I don't want us to have RPM spec file hacks just to get RISC-V to
install in the correct locations.  The symbolic link evidently does not
cover all cases.

Whatever we do, it should be upstream.  Maybe convince RISC-V to adopt
/usr/lib64.  Or have the RISC-V folks implement automated detection of
path layout in autotools, Meson etc., so that out of the box, both paths
work.

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 RISC-V port needs to put shared objects into /usr/lib64/lp64d

[Florian Weimer]

There are multiple PRs and patches floating around that make RISC-V use
the /usr/lib64 directory, like other 64-bit ports.  However, RISC-V
recommends to use /usr/lib64/lp64d for the Fedora ABI variant, and
various upstream projects follow that.

I think we should follow upstream, so that it's possible to use Fedora
to do upstream development without patching the sources, or elaborate
Fedora-specific configure invocations.  The other reasons is to
future-proof the Fedora port against the arrival of an alternative ABI
that is not fully backwards-compatible (the same reason why the official
RISC-V documentation requires use of these paths).

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: Three steps we could take to make supply chain attacks a bit harder

[Florian Weimer]

* Kilian Hanich via devel:

> Am 02.04.24 um 10:22 schrieb Florian Weimer:
>>>   - Can some wrappers be developed to make it both easier and safer?
>> GCC already provides function multi-versioning/target clones as a
>> higher-level interface.
>
>
> Also, upstreams should by default properly mark their stuffs with
> restrictive visibilities.
>
> While we are a few decades to change the defaults, that doesn't mean
> that one can't choose the better option. So, by default one should
> choose -fvisibility=hidden and mark the public API with
> __attribute__((visibility("protected"))) or, if they really want a
> function to be interpositionable (by e.g. LD_PRELOAD) as
> __attribute__((visibility("default"))).

I think protected visibility is still broken on x86-64.  For function
symbols, it's more convenient to use -fno-semantic-interposition and
rely on LTO to do the heavy lifting.  For data symbols, it may be a
better longer term investment to add explicit export lists (maybe even
with symbol versioning), and again rely on LTO to make everything else
hidden.

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: Three steps we could take to make supply chain attacks a bit harder

[Florian Weimer]

* Lennart Poettering:

> On Sa, 30.03.24 18:56, Fedora Development ML (devel@lists.fedoraproject.org) 
> wrote:
>
>> > In systemd git main, libsystemd is only linked to libc, libcap,
>> > and libgcrypt + libgpg-error. A pull request to convert that that last
>> > pair to dlopen is under review.
>>
>> That helps somewhat (it would have prevented this backdoor from working),
>> but it also makes things even less transparent: How do we know whether some
>> random sd_foobarify() function or some random foobard linked against
>> libsystemd will (always or ever (and when?)) end up dlopening liblzma or
>> not?
>>
>> Distribution packagers tend to dislike dlopen due to the hidden dependencies
>> it introduces.
>
> Well, this is certainly a valid point, but the solution is not to make
> all deps hard ones. Instead, in order to just make these deps visible
> I see multiple better alternatives:
>
> 1. teach Linux/ELF something inspired by MacOS's weak deps. i.e. allow
>ELF programs declare that some symbols shall be backed by some lib,
>but make it a weak dep that is only resolved on demand, and
>gracefully is set to NULL if the library cannot be found. If we had
>that, we'd stop using dlopen() for systemd's deps, since all we do
>is basically reimplement this concept manually.

How exactly is this implemented?  Is the object loaded on the first
function call?  I'd be worried that this made initialization even more
complicated than it is today.

Loading the object unconditionally (prior to the function call) doesn't
make a difference for objects which are always installed on the system.
They would always be loaded.

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: Three steps we could take to make supply chain attacks a bit harder

[Florian Weimer]

* Gordon Messmer:

> Why doesn't dlopen() solve the problem?  As best I understand it,
> liblzma was able to steal one (or more) of the symbols from
> libcrypto.so.3 because it ran constructors at a point in time when the
> GOT was still writable.  After loading shared objects is complete,
> that table is made read-only.  If dlopen() is used after the program
> starts, then even if the library is loaded, it can't steal symbols in
> the table any more.

The rsa_pkcs1_ossl_meth variable that contains a function pointer to the
actual implementation resides in read-write memory:

static RSA_METHOD rsa_pkcs1_ossl_meth = {
"OpenSSL PKCS#1 RSA",
rsa_ossl_public_encrypt,
rsa_ossl_public_decrypt, /* signature verification */
rsa_ossl_private_encrypt,/* signing */
rsa_ossl_private_decrypt,
rsa_ossl_mod_exp,
BN_mod_exp_mont,/* XXX probably we should not use Montgomery
 * if e == 3 */
rsa_ossl_init,
rsa_ossl_finish,
RSA_FLAG_FIPS_METHOD,   /* flags */
NULL,
0,  /* rsa_sign */
0,  /* rsa_verify */
NULL,   /* rsa_keygen */
NULL/* rsa_multi_prime_keygen */
};

The missing “const” keyword is probably an oversight, but I don't think
it matters because the variable is not used directly.  All access
happens through deefault_RSA_meth:

static const RSA_METHOD *default_RSA_meth = _pkcs1_ossl_meth;

void RSA_set_default_method(const RSA_METHOD *meth)
{
default_RSA_meth = meth;
}

const RSA_METHOD *RSA_get_default_method(void)
{
return default_RSA_meth;
}

const RSA_METHOD *RSA_PKCS1_OpenSSL(void)
{
return _pkcs1_ossl_meth;
}

And that's clearly required to be read-write.  RSA_set_default_method is
a documented interface, too.  So I don't think GOT patching was required
to achieve the intended effect.

Furthermore, it's possible to undo the effect of RELRO with mprotect.

Using dlopen, liblzma would not have been loaded at run time, but it's
not clear if it had mattered because liblzma would still have been
loaded by RPM, both at build and install time.

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: Three steps we could take to make supply chain attacks a bit harder

[Florian Weimer]

* Richard W. M. Jones:

> I'm not pretending these will solve everything, but they should make
> attacks a little harder in future.
>
>
> (1) We should routinely delete autoconf-generated cruft from upstream
> projects and regenerate it in %prep.  It is easier to study the real
> source rather than dig through the convoluted, generated shell script
> in an upstream './configure' looking for back doors.
>
> For most projects, just running "autoreconf -fiv" is enough.
>
> Yes, there are some projects that depend on a specific or old version
> of autoconf.  We should fix those.  But that doesn't need to delay us
> from using autoreconf on many projects today.

Not shipping the m4 files and other artifacts required for regenerating
autoconf scripts is not exactly rare, unfortunately.  I have filed a
bunch of bugs because it's my understanding that this incomplete source
code is against Fedora policies, but in the end, there isn't much we can
do about it.

But I sympathize with this approach, we should build from sources as
much as we can.  Maybe not regenerate everything in %prep though, this
really belongs into %build.  It's invoking a compiler, after all.

> In the xz case this wouldn't have been enough, it turns out we would
> also have to delete m4/build-to-host.m4, which then autoreconf
> regenerates.  I don't fully understand why that is.

I would expect that's what the serial number is for?  But that's just a
guess.

> (2) We should discourage gnulib as much as possible.

Or use Git sources without bundled gnulib, and re-bundled at build time
using gnulib-devel.  It would make gnulib updates easier.  Such updates
are sometimes required because gnulib overrides glibc internals without
much coordination, and gnulib-using software may fail to build (or run)
until gnulib is updated to reflect the internal glibc changes.

However, while I don't particularly like autoconf and gnulib (they are
mainly there to support systems other than GNU/Linux, most of them
proprietary), I don't expect any steps we take there to stop anyone who
targets Fedora specifically.  Being different from other distributions
doesn't help at all if Fedora is the target.

> (3) We should have a "security path", like "critical path".

I think there is a strong overlap with a bootstrap package set that is
occasionally discussed.  And this leads to the main point I want to
make:

Stopping an attack that has already happened does not make much sense.
Given that we work in the open, preventing future attacks that target
Fedora specifically is likely impossible.  Therefore, the focus should
be on builder and buildroot integrity, and generic strategies for
restoring buildroot integrity after an incident.  In this particular
case, so far we considered it sufficient to merely downgrade one
package.  But the package in question was part of the default buildroot.
That means that in theory, it could have persisted itself outside the
confines of its own package.

> sshd is linked to a lot of libraries:
>
> /lib64/libaudit.so.1audit-libs
> /lib64/libc.so.6glibc
> /lib64/libcap-ng.so.0   libcap-ng
> /lib64/libcap.so.2  libcap
> /lib64/libcom_err.so.2  libcom_err
> /lib64/libcrypt.so.2libxcrypt
> /lib64/libcrypto.so.3   openssl-libs
> /lib64/libeconf.so.0libeconf
> /lib64/libgcc_s.so.1libgcc
> /lib64/libgssapi_krb5.so.2  krb5-libs
> /lib64/libk5crypto.so.3 krb5-libs
> /lib64/libkeyutils.so.1 keyutils-libs
> /lib64/libkrb5.so.3 krb5-libs
> /lib64/libkrb5support.so.0  krb5-libs
> /lib64/liblz4.so.1  lz4-libs
> /lib64/liblzma.so.5 xz-libs
> /lib64/libm.so.6glibc
> /lib64/libpam.so.0  pam-libs
> /lib64/libpcre2-8.so.0  pcre2
> /lib64/libresolv.so.2   glibc
> /lib64/libselinux.so.1  libselinux
> /lib64/libsystemd.so.0  systemd-libs
> /lib64/libz.so.1zlib / zlib-ng
> /lib64/libzstd.so.1 zstd
>
> Should we have a higher level of attention to these packages?  We
> already have "critical path", but that's a broad category now.  These
> seem like they are "security path" packages, an intentionally small
> subset associated with very secure services which are enabled by
> default.

The bootstrap set depends on SWIG, and SWIG pulls in language
implementations which are not bootstrapped from source using the
previous version.

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: Three steps we could take to make supply chain attacks a bit harder

[Florian Weimer]

* Richard W. M. Jones:

> That said, ifunc is a very complicated, fragile  but powerful mechanism
> and I'd like to know from the glibc developers what we should
> look out for.  For example:
>
>  - Is it ever valid for ifunc to take control of functions in another
>library?  Can this be detected by ld.so?

I'm not sure what you mean by “take control”.  The IFUNC resolver
returns an address that is used as the symbol value, for the specific
symbol the IFUNC resolver was associated with at build time.  It's not
expected to write to ld.so? data structures directly.

I have patches which make key ld.so? data structures read-only, but they
still have to be read-write during relocation processing, when IFUNC
resolvers run.  Under the defend-against-application-bugs model, that's
a reasonable trade-off because IFUNC resolvers are unlikely to have
vulnerabilities (currently, they cannot even access environment
variables reliably).  Of course, it doesn't work for IFUNC resolvers
written with malicious intent.  I don't think there is a reasonable
possibility to defend against that because any ld.so? defense we create
is out there for everyone to see, so they can work around that.

>  - Can some wrappers be developed to make it both easier and safer?

GCC already provides function multi-versioning/target clones as a
higher-level interface.

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: glibc32 in rawhide is now built from glibc

[Florian Weimer]

* Kevin Fenzi:

> However, our filter config is... quite possibly out of date. :)
>
> Currently it is: 
>
> filter_packages = [
> ("^.*$", {
> "*": ["glibc32", "libgcc32"],
> "s390x": ["rust-std-static-wasm*"],
> }),
> ('(Server)$', {
> '*': [
> 'kernel*debug*',
> 'kernel-kdump*',
> 'kernel-tools*',
> 'syslog-ng*',
> 'astronomy-bookmarks',
> 'generic*',
> 'GConf2-dbus*',
> 'bluez-gnome',
> 'java-11-openjdk',
> 'community-mysql*',
> 'jruby*',
> 'gimp-help-*',
> ]
> }),
> ]
>
> Does libgcc32 exist anymore?

I planned to bring this up later. 8-) I requested the addition of
libgcc32 because I thought it was needed.  But it turns out that all the
files that would be part of that package have always been gcc.x86_64.
This means that we don't need a libgcc32 subpackage after all.

I'll comment on the ticket as well.

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: glibc32 in rawhide is now built from glibc

[Florian Weimer]

* Kevin Fenzi:

> So, seems glibc32 was updated to update license headers?
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2024-cd577e1535
>
> So, it's in f40-updates-testing now. 
>
> It's not in rawhide or f40 composes because pungi filters it out, but
> it's currently not filtered in updates-testing. I can fix that, but...
> isn't this package just going to be retired/blocked now?

Uh-oh?  Does this mean that glibc32 (the binary package) will land in
updates-testing as well, each time we have glibc in gating?

I planned to retire glibc32 after my vacation, in early April, but I can
retire it now if that's better.

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: x86-64 -mtls-dialect=gnu2 change landed in rawhide

[Florian Weimer]

* Florian Weimer:

> This was originally approved as part of the Fedora 40 toolchain update,
> but we encountered a GCC/glibc ABI mismatch which we fixed in glibc.
>
> I couldn't do a full distribution rebuild test (and there was just one
> package that showed the ABI bug in the first run!), but I tested
> building bash, lua, libomp in a side tag before merging the
> redhat-rpm-config update.

So this didn't go as planned: there is another register clobber in the
glibc TLS implementation (#2269799).  I've put glibc-2.39.9000-8.fc41 in
gating, it should fix this issue.

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

glibc32 in rawhide is now built from glibc

[Florian Weimer]

Joseph Myers enhanced glibc.spec so that we no longer need the separate
glibc32 source package which its tarball of pre-built glibc binaries.

As part of the DNF5 adjustment to the removal of filelists, I believe
some reverse dependencies (including gcc) have been adjusted to use the
package name explicitly, as in:

%ifarch x86_64
BuildRequires: (glibc32 or glibc-devel(%{__isa_name}-32))
%endif

Most packages have dropped the glibc32 dependency because it was
unneeded (or should do so).

This new package only contains the glibc files needed to build gcc.
Other shared objects, such as libcrypt.so.2 or libgcc_s.so.1, are no
longer included.

There is a pungi configuration which is expected to filter out glibc32
from the compose.  We'll see how that works out.  The new glibc32
package does not have any ELF dependency information, so the risk of it
being installed by accident is reduced compared to the old one.

Once we have a compose without glibc32, I will retire the glibc32 source
package because we no longer need it.  Currently, glibc32 is still
tagged in, but it has a lower version than the glibc-built package, so
the latter is installed in the buildroot.

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

x86-64 -mtls-dialect=gnu2 change landed in rawhide

[Florian Weimer]

This was originally approved as part of the Fedora 40 toolchain update,
but we encountered a GCC/glibc ABI mismatch which we fixed in glibc.

I couldn't do a full distribution rebuild test (and there was just one
package that showed the ABI bug in the first run!), but I tested
building bash, lua, libomp in a side tag before merging the
redhat-rpm-config update.

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: Guiding co-dependent RPM packages to swap nicely

[Florian Weimer]

* Miro Hrončok:

> On my system, I have postgresql16 and postgresql16-plugin installed
> and I want to "upgrade" to postgresql20*.
>
> Using my distribution package manager, I would want to run something like:
>   dnf swap postgresql16 postgresql20
>
> However that will fail, as the package manager does not know I want to
> also swap postgresql16-plugin with postgresql20-plugin.
>
> Is there something I can do as a package maintainer to "guide" the
> co-dependent swap case?

Have you tried using “dnf shell” and entering both swap commands there/

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: Need help with incompatible pointer types on i686

[Florian Weimer]

* Orion Poplawski:

> It seems that numpy is defining a uint32_t type as long unsigned int
> on i686, while glibc(?) is defining it as unsigned int.  Now what
> puzzles me a little is that on i686 aren't these both 4-byte integers
> and no not incompatible at all?

The types int and long are distinct according to C rules.

The problem seems to be in h5py/api_types_ext.pxd:

from numpy cimport int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, 
int64_t, uint64_t

I think it should use the types from  instead, at least in the
global scope.  For certain Numpy functions, it may be required to
reference them as numpy.uint32_t etc.

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: Modern C failures in Haskell stack

[Florian Weimer]

* Richard W. M. Jones:

> We noticed that some ghc-* packages FTBFS with Modern C failures eg
> these two picked at random:
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
>
> I think what's happening here is that ghc is generating C FFI code
> which is fed to GCC 14.  The code being generated is buggy.
>
> So probably the fix for this is just in ghc itself.  I looked at
> upstream ghc and wasn't able to identify any commits which fix this
> (except maybe
> https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> But I didn't look especially hard and the code is very complicated.
>
> An alternative to fixing this in the compiler is to throw up our hands
> and add:
>
>   %global build_type_safety_c 0
>
> to every affected ghc-* package.

Please don't do this, it's unnecessary busy-work.

> eg This fixes ghc-readline:
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
>
> Any thoughts on this?

If GHC cannot be fixed properly, it should be trivial to teach it to
emit #pragma directives near the start of the generated files.  This is
what we currently do for Vala:



(The upstream submission has a Clang variant as well.)

Hopefully, GHC has a better understanding of the types and the control
flow of the code it generates than the Vala compiler, so this shouldn't
be necessary.

For the first issue, please try this GHC patch (only compile-tested with
the stage 0 compiler build this point):

diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
b/compiler/GHC/HsToCore/Foreign/C.hs
index 2164ded112..8beaa8986e 100644
--- a/compiler/GHC/HsToCore/Foreign/C.hs
+++ b/compiler/GHC/HsToCore/Foreign/C.hs
@@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
is_IO_res_ty cc
  ,   ppUnless res_hty_is_unit $
  if libffi
   then char '*' <> parens (ffi_cResType <> char '*') <>
-   text "resp = cret;"
+   text "resp = " <> parens ffi_cResType <> text "cret;"
   else text "return cret;"
  , rbrace
  ]

I'm not even sure if there is a better fix for this.  Perhaps emitting a
memcpy call to avoid the aliasing violation?

For the second build failure, GCC reports *genuine* bugs in the C code
in that package, leading to run-time crashes:

cbits/hslibxml-shim.c:44:21: error:
 warning: incompatible implicit declaration of built-in function ‘calloc’ 
[-Wbuiltin-declaration-mismatch]
   44 | user_data = calloc(1, sizeof(UserData));
  | ^~

That hasn't been valid C since 1986 or thereabouts.

As Jakub said, you really need to include the appropriate header files
to make this work.

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: x86-64 -mtls-dialect=gnu2 change needs to be postponed

[Florian Weimer]

* Stephen Smoogen:

> On Sun, 11 Feb 2024 at 09:35, Florian Weimer  wrote:
>
>  We've hit an ABI ambiguity/bug:
>
>gcc: -mtls-dialect=gnu2 produces wrong code on x86-64
><https://bugzilla.redhat.com/show_bug.cgi?id=2263739>
>
> Was this set for the Fedora 40 mass rebuild or something that was put
> in later? If it was put into the mass rebuild, what problems would it
> cause currently?

I couldn't get the testing done in time for the mass rebuild, so it
wasn't included.  It's fully interoperable, so an incremental transition
is okay (once we settled the ABI issue).

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

x86-64 -mtls-dialect=gnu2 change needs to be postponed

[Florian Weimer]

We've hit an ABI ambiguity/bug:

  gcc: -mtls-dialect=gnu2 produces wrong code on x86-64
  

Apart from that, support in the GNU toolchain seems to be quite good.
In particular, GDB handled the situation in the polymake crash quite
well (reporting TLS data as uninitialized for the thread before the
critical call, and producing the correct address for the variable
afterwards).

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: dnf-4.19.0 without filelists in Rawhide soon

[Florian Weimer]

* Jan Kolarik:

> From a Fedora user perspective, there won't be any changes in the way
> you operate the DNF package manager. The only difference is that
> typically there will be less metadata downloaded.  Since all packages
> in Fedora should have already eliminated file dependencies requiring
> filelists metadata, no issues with official repositories are
> anticipated.

What's the impact on mock and older chroots?  Just use bootstrap chroot?

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: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Florian Weimer]

* David Abdurachmanov:

> On Thu, Feb 1, 2024 at 3:24 PM Florian Weimer  wrote:
>> Please try this:
>>
>> diff --git a/glibc.spec b/glibc.spec
>> index 6116752..e4d5e44 100644
>> --- a/glibc.spec
>> +++ b/glibc.spec
>> @@ -1571,6 +1571,10 @@ for lib in lib lib64;  do
>> set +x
>> slbase=$(basename $sl)
>> sltarget=$(basename $(readlink $sl))
>> +   if test "$sltarget" = . ; then
>> +   # This is the lp64d symbolic link on riscv64, see above.
>> +   continue
>> +   fi
>> if ! test -r usr/$lib/$sltarget; then
>> echo "$sl: inferred $sltarget ($(readlink $sl)) missing"
>> exit 1
>>
> Hi Florian,
>
> The above worked. See the build:
> http://fedora.riscv.rocks/koji/buildinfo?buildID=281296
>
> Could you land this change to glibc.spec?

Applied in glibc-2.39-2.fc40.

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: FYI: AFL++ now builds a GCC plugin

[Florian Weimer]

* Richard W. M. Jones:

>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113035034
>   https://bugzilla.redhat.com/show_bug.cgi?id=2262539
>
> The new AFL++ (American Fuzzy Lop, a fuzzing tool) in Rawhide appears
> to be building a GCC plugin, contained in one or all of these newly
> added files:
>
>   %global afl_helper_path %{_libdir}/afl
>   %{_bindir}/afl-gcc-fast
>   %{_bindir}/afl-g++-fast
>   %{afl_helper_path}/afl-gcc-cmplog-pass.so
>   %{afl_helper_path}/afl-gcc-cmptrs-pass.so
>   %{afl_helper_path}/afl-gcc-pass.so
>   %{afl_helper_path}/afl-gcc-rt.o
>   %{afl_helper_path}/injection-pass.so
>
> I'm going to guess this will introduce a dependency on the exact
> version of GCC (major only? or major.minor? not sure).  Just like
> annobin.  Which might require that this package is rebuilt when GCC is
> rebuilt (only major? or all rebuilds? again, don't know).

It depends on what the plugin does.  Not all plugins are as sensitive to
e.g. GCC options changes.  A precise NVR dependency might still make
sense.  It's easier to pull off here because there's no cyclic
dependency issue.

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: Figure out what killed an app (rhbz#2253099)

[Florian Weimer]

* Yanko Kaneti:

> On Sat, 2024-02-03 at 13:29 +0100, Ondrej Mosnáček wrote:
>> On Fri, 2 Feb 2024 at 17:52, Yanko Kaneti  wrote:
>> > 
>> > On Thu, 2024-02-01 at 09:44 +0100, Ondrej Mosnáček wrote:
>> > > On Thu, 1 Feb 2024 at 09:13, Milan Crha  wrote:
>> > > > The kernel tracing log for sig==9 shows:
>> > > > 
>> > > > gnome-terminal--2924[002] dN.2.  2520.462889: signal_generate:
>> > > > sig=9 errno=0 code=128 comm=alloc-too-much pid=3502 grp=1 res=0
>> > > > 
>> > > > There is no such thing (apart of the tracing log) when Evolution is
>> > > > suddenly killed, the logs are muted. That makes me believe it's not the
>> > > > OOM killer whom kills the application. I'm back at square 1; or maybe
>> > > > square 2, as I know possibly kernel sends it, but not why.
>> > > 
>> > > Try running `echo stacktrace >/sys/kernel/tracing/trace_options` (as
>> > > root) and then collect the kernel trace again. That should give you a
>> > > backtrace of kernel functions from the signal generation, which could
>> > > help you/us to figure out the reason the process was killed.
>> > 
>> > So, figured the easiest way to help trigger the kill here is to put load
>> > on the machine.
>> > 
>> >  $ stress-ng --cpu -1 --cpu-method all -t 5m --cpu-load 95
>> > 
>> > then starting evolution seems to do it almost every time shortly after
>> > start (I have around 200k messages in the folder its trying to display)
>> > 
>> > I've enabled the stacktrace tracing option and like Milan set a sig==9
>> > filter. And here is what I got in the trace buffer after it was killed
>> > 
>> > # tracer: nop
>> > #
>> > # entries-in-buffer/entries-written: 34/34   #P:16
>> > #
>> > #_-=> irqs-off/BH-disabled
>> > #   / _=> need-resched
>> > #  | / _---=> hardirq/softirq
>> > #  || / _--=> preempt-depth
>> > #  ||| / _-=> migrate-disable
>> > #   / delay
>> > #   TASK-PID CPU#  |  TIMESTAMP  FUNCTION
>> > #  | | |   | | |
>> >evolution-9096[002] d..1.  1207.016489: signal_generate: sig=9 
>> > errno=0 code=128 comm=evolution pid=9096 grp=1 res=0
>> >evolution-9096[002] d..1.  1207.016495: 
>> >  => trace_event_raw_event_signal_generate
>> >  => __send_signal_locked
>> >  => posix_cpu_timers_work
>> >  => task_work_run
>> >  => irqentry_exit_to_user_mode
>> >  => asm_sysvec_apic_timer_interrupt
>> 
>> So, browsing through the relevant kernel code, it seems the only cases
>> which could have led to this backtrace are:
>> 1. When a task's RT timeout goes over the RLIMIT_RTTIME hard limit
>> (see function check_thread_timers() in
>> kernel/time/posix-cpu-timers.c).
>> 2. When a task's CPU time goes over the RLIMIT_CPU hard limit (see
>> function check_process_timers() in kernel/time/posix-cpu-timers.c).
>> 
>> I may have missed some code path, but these resource limits should be
>> the next thing to check.
>
> Thanks a lot for diving it. This is probably it.
> The kernel killing the main evolution process which was set as having rt
> priority by some webkit coincidence.
>
> Running with rtkit-daemon stoped and masked prevents the main evo
> process being prioritized and consequently killed with higher load.
>
> The fact that the kernel kills the (main)thread without a beep anywhere
> in the logs is strange to me.

Interesting analysis, thanks!

I think it's not so unusual for the kernel not to log the SIGKILL.  This
does not seem to be purely an emergency measure like the OOM killer—it's
more like something that an application (set of processes) told the
kernel to do to itself.  As such, it's not unreasonable for the
application to do the logging.  On the other hand, I think it's
difficult for rtkit-daemon to arrange for that logging because it can't
monitor the target process directly.

Any idea why the signal is SIGKILL and not SIGXCPU?  To ensure that the
process actually terminates promptly, without running signal handlers or
generating a coredump?  SIGXCPU would point more directly to the cause.

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: Mounting USB Storage devices with "sync" option ?

[Florian Weimer]

* Barry Scott:

> As I understand it the kernel will request that writes are not
> cached. Which means that journaling file systems do in fact work well.

The kernel messages I get look like this:

kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
kernel: sd 0:0:0:0: [sda] 15814656 512-byte logical blocks: (8.10 GB/7.54 GiB)
kernel: sd 0:0:0:0: [sda] Write Protect is off
kernel: sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00
kernel: sd 0:0:0:0: [sda] No Caching mode page found
kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
kernel: sd 0:0:0:0: [sda] Attached SCSI removable disk

kernel: sd 0:0:0:0: Attached scsi generic sg0 type 0
kernel: sd 0:0:0:0: [sda] Spinning up disk...
kernel: sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
kernel: sd 0:0:0:0: [sda] 7814035456 512-byte logical blocks: (4.00 TB/3.64 TiB)
kernel: sd 0:0:0:0: [sda] 4096-byte physical blocks
kernel: sd 0:0:0:0: [sda] Write Protect is off
kernel: sd 0:0:0:0: [sda] Mode Sense: 53 00 10 08
kernel: sd 0:0:0:0: [sda] No Caching mode page found
kernel: sd 0:0:0:0: [sda] Assuming drive cache: write through
kernel: sd 0:0:0:0: [sda] Attached SCSI disk

I thought that ‘Assuming drive cache: write through’ means that no
barriers are used.

The second one is a standard SATA drive in an USB enclosure, and those
have write-reordering caches, as far as I understand it.

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: Mounting USB Storage devices with "sync" option ?

[Florian Weimer]

>> On 31 Jan 2024, at 11:41, Florian Weimer  wrote:
>> 
>> I think this is somewhat counteracted by Linux treating USB mass storage
>> devices as not having write caches (according to dmesg at least).
>> Doesn't this mean that those costly barriers won't be used?
>
> Isn’t that a reference to caches within the drive and not the buffer
> cache in the kernel?

Yes, the kernel assumes that there are no such caches, but I think in
practice there are.  I think this means that journaling file systems are
not working correctly, in the sense that you do not get just user data
loss if the device is unplugged prematurely, but also metadata
corruption.

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: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Florian Weimer]

* Richard W. M. Jones:

>> We will have to fix this again (and wrap-find-debuginfo.sh and as well)
>> once Fedora adopts the standard RISC-V paths.
>
> Shouldn't we adopt the normal Fedora paths instead?

No, we should use the official RISC-V paths because we might need them
if we want to adopt other RISC-V ABIs.

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: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

[Florian Weimer]

* David Abdurachmanov:

> Hi Florian,
>
> I was trying to build the latest glibc [0] in Fedora 40 for riscv64,
> but it failed. It seems to be related to your last commit.
>
> [..]
> + ln -s libBrokenLocale.so.1 usr/lib64/libBrokenLocale.so
> + for sl in `find $RPM_BUILD_ROOT/$pfx$lib -maxdepth 1 -type l`
> + set +x
> + ln -s . usr/lib64/lp64d
> ln: failed to create symbolic link 'usr/lib64/lp64d/.': File exists
> error: Bad exit status from /var/tmp/rpm-tmp.7qPZkS (%install)
> [..]
>
> Full log: 
> http://fedora.riscv.rocks/kojifiles/work/tasks/9391/1599391/build.log
> Build info: http://fedora.riscv.rocks/koji/taskinfo?taskID=1599391
>
> This is probably related to this:
> https://src.fedoraproject.org/rpms/glibc/blob/rawhide/f/glibc.spec#_1279
>
> Cheers,
> david
> - - -
> [0] 
> https://src.fedoraproject.org/rpms/glibc/c/0bd93c5697bc60e4f4a84f5b55c98f351883e689?branch=rawhide

That refers to:

%ifarch riscv64
# RISC-V ABI wants to install everything in /lib64/lp64d or /usr/lib64/lp64d.
# Make these be symlinks to /lib64 or /usr/lib64 respectively.  See:
# 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DRHT5YTPK4WWVGL3GIN5BF2IKX2ODHZ3/
for d in %{glibc_sysroot}%{_libdir} %{glibc_sysroot}/%{_lib}; do
mkdir -p $d
(cd $d && ln -sf . lp64d)
done
%endif

Please try this:

diff --git a/glibc.spec b/glibc.spec
index 6116752..e4d5e44 100644
--- a/glibc.spec
+++ b/glibc.spec
@@ -1571,6 +1571,10 @@ for lib in lib lib64;  do
set +x
slbase=$(basename $sl)
sltarget=$(basename $(readlink $sl))
+   if test "$sltarget" = . ; then
+   # This is the lp64d symbolic link on riscv64, see above.
+   continue
+   fi
if ! test -r usr/$lib/$sltarget; then
echo "$sl: inferred $sltarget ($(readlink $sl)) missing"
exit 1

We will have to fix this again (and wrap-find-debuginfo.sh and as well)
once Fedora adopts the standard RISC-V paths.

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

CI failure: Too many packages to install: 233 (threshold 100). Please use 'repository-file' artifact instead.

[Florian Weimer]

How can we fix this error?

  

I think it's related to the fact that glibc has many subpackages.  This
used to be a problem with slow tests timing out in Zuul, but it didn't
prevent any rpm-tmt-test subtests from running.

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: Mounting USB Storage devices with "sync" option ?

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> On Wed, Jan 31, 2024 at 06:43:00AM -, Abyss Ether via devel wrote:
>> I created a simple PoC udev rule to mount USB Storage devices with the "sync 
>> option.
>> Available here : 
>> https://github.com/larina3315/personal-stuff/blob/main/linux/10-usb-storage.rules
>> 
>> Currently, USB Storage devices are mounted without the "sync" option, 
>> causing their writes to be cached.
>> This causes an issue, especially with GUI file managers like GNOME Files, 
>> where after a file copy operation, it would notify the user that the 
>> operation has been completed. If the user then tries to unmount the USB 
>> Storage device, they get notified that data is still being written to disk 
>> and that they should not remove the USB Storage device from their 
>> PC/Laptop/device.
>
> 'sync' has some strong downsides though: various operations become
> painfully slow (this depends a lot on the hardware and its age, and
> the history of previous writes, etc.), write operations block read
> operations, and the total number of writes may be increased, leading
> to more wear on the hardware.

I think this is somewhat counteracted by Linux treating USB mass storage
devices as not having write caches (according to dmesg at least).
Doesn't this mean that those costly barriers won't be used?

Of course it also means that “sync” is not effective as we would like.

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

SWIG 4.2 Python transition

[Florian Weimer]

Quoting CHANGES from SWIG 4.2.0:

“
2023-12-20: wsfulton
#2190 Replace SWIG_Python_str_AsChar with 
SWIG_PyUnicode_AsUTF8AndSize.

SWIG_Python_str_AsChar has undefined behaviour when Py_LIMITED_API 
is defined
as it returns a pointer to a string in a PyBytes object that no 
longer exists.

SWIG_PyUnicode_AsUTF8AndSize is an efficient replacement, but 
requires a
different API and the caller to decrement the refcount on the 
intermediate
PyObject in the Py_LIMITED_API < 0x030A implementation. The 
alternative
would have required copying the returned char * string as was done 
in a
previous implementation requiring a call to the defunct 
SWIG_Python_str_DelForPy3
function.

*** POTENTIAL INCOMPATIBILITY ***
”

This function is somewhat widely used:

  

I tried to fix the ldns bindings like this:

diff --git a/contrib/python/ldns_rdf.i b/contrib/python/ldns_rdf.i
index 5d7448fd..60daf1a7 100644
--- a/contrib/python/ldns_rdf.i
+++ b/contrib/python/ldns_rdf.i
@@ -56,7 +56,11 @@
  */
 %typemap(arginit, noblock=1) const ldns_rdf *
 {
+#if SWIG_VERSION >= 0x040200
+  PyObject *$1_bytes = NULL;
+#else
   char *$1_str = NULL;
+#endif
 }
 
 /*
@@ -66,11 +70,17 @@
 %typemap(in, noblock=1) const ldns_rdf * (void* argp, $1_ltype tmp = 0, int 
res)
 {
   if (Python_str_Check($input)) {
+const char *argstr;
+#if SWIG_VERSION >= 0x040200
+argstr = SWIG_PyUnicode_AsUTF8AndSize($input, NULL, &$1_bytes);
+#else
 $1_str = SWIG_Python_str_AsChar($input);
-if ($1_str == NULL) {
+argstr = $1_str;
+#endif
+if (argstr == NULL) {
   %argument_fail(SWIG_TypeError, "char *", $symname, $argnum);
 }
-tmp = ldns_dname_new_frm_str($1_str);
+tmp = ldns_dname_new_frm_str(argstr);
 if (tmp == NULL) {
   %argument_fail(SWIG_TypeError, "char *", $symname, $argnum);
 }
@@ -90,10 +100,17 @@
  */
 %typemap(freearg, noblock=1) const ldns_rdf *
 {
+#if SWIG_VERSION >= 0x040200
+  if ($1_bytes != NULL) {
+/* Is not NULL only when a conversion form string occurred. */
+Py_XDECREF($1_bytes);
+  }
+#else
   if ($1_str != NULL) {
 /* Is not NULL only when a conversion form string occurred. */
 SWIG_Python_str_DelForPy3($1_str); /* Is a empty macro for Python < 3. */
   }
+#endif
 }
 
 %nodefaultctor ldns_struct_rdf; /* No default constructor. */

Submitted upstream as .
Maybe that will get some useful comments; I don't know much about SWIG.
(The core of the change above is the call to
SWIG_PyUnicode_AsUTF8AndSize and Py_XDECREF call for the bytes object.)

In the past, this kind of problem would have just compiled and resulted
in a run-time error when the Python extension module is loaded.  In some
cases, issues went completely unnoticed because the Python bindins were
unused.  But with GCC 14, it is necessary to fix calls to undeclared
functions.

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: Staled PRs at https://src.fedoraproject.org/rpms/

[Florian Weimer]

* Miroslav Suchý:

> I want to point to nice feature of Pagure - it can show you PR where
> you can act on:
>
> https://src.fedoraproject.org/user/msuchy/requests?type=actionable=open
>
> (your account icon -> My Pull Request -> PR I can act on)
>
> Please check it, maybe you will discover some PR that is waiting on
> your feedback and you are not aware of it.

Is there a way to merge PR lists from multiple packages into a single
backlog?  We try to keep an eye on the bug list for our components, but
that only works (to some extent …) because Bugzilla allows us to
consolidate everything into a single list.  If we had this for PRs, it
would really help, I think.

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: Another mass rebuild blocker: glibc qsort regression

[Florian Weimer]

* Florian Weimer:

> * Florian Weimer:
>
>> * Florian Weimer:
>>
>>> There's a regression in qsort that needs to be fixed before the mass
>>> rebuild can be restarted:
>>>
>>>   <https://bugzilla.redhat.com/show_bug.cgi?id=2259845>
>>>
>>> I'm going to work on this with priority.
>>>
>>> Posting this here because Fedora infrastructure is having authentication
>>> troubles.  Please relay as appropriate.
>>
>> I was wrong, just because qsort is on the stack trace doesn't mean it's
>> another qsort bug. 8-/
>>
>> It's back with Jakub for analysis from the GCC side.
>
> Sorry, still can't comment on the releng ticket—it's unclear at this
> point whether this bug impacts the mass rebuild.  (Probably not.)
> In any case, we don't have a fix yet.

It's a long-standing issue in ruby (I can reproduce it on Fedora 38).
It was merely exposed by a missed optimization in glibc.

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: GNOME package builds this cycle

[Florian Weimer]

* Kalev Lember:

> Just a quick heads up that it's David King (amigadave on IRC) and not
> me who's doing GNOME package builds in Fedora for the next 6 months or
> so - during the Fedora 40 / GNOME 46 release cycle. David has already
> started with GNOME 46.alpha builds in rawhide.

I think I fixed up the RPM spec files of the Vala packages that didn't
do the required rebuilds with Fedora's patched Vala compiler (roughly:
run touch **.vala, add BuildRequires: vala, as appropriate).  I changed
packages only if I saw build failures, so if rebases happen (or file
systems with different modification time resolution), it's possible that
more RPM spec files need to be adjusted to re-run the Vala compiler.

The latest upstream submission of the Vala workaround (5ed94310) has
Clang support:

   codegen: Emit diagnostics pragmata for GCC 14, Clang 16 compatibility 
   

But I don't think we need this in Fedora, so I haven't imported it yet.

> We also have a new person helping out and trying to learn how GNOME
> packaging works: Nieves Montero. If you see pull requests from her,
> please be nice and maybe say hi - she is new to Fedora and packaging
> in general.

Welcome! 8-)

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: Another mass rebuild blocker: glibc qsort regression

[Florian Weimer]

* Florian Weimer:

> * Florian Weimer:
>
>> There's a regression in qsort that needs to be fixed before the mass
>> rebuild can be restarted:
>>
>>   <https://bugzilla.redhat.com/show_bug.cgi?id=2259845>
>>
>> I'm going to work on this with priority.
>>
>> Posting this here because Fedora infrastructure is having authentication
>> troubles.  Please relay as appropriate.
>
> I was wrong, just because qsort is on the stack trace doesn't mean it's
> another qsort bug. 8-/
>
> It's back with Jakub for analysis from the GCC side.

Sorry, still can't comment on the releng ticket—it's unclear at this
point whether this bug impacts the mass rebuild.  (Probably not.)
In any case, we don't have a fix yet.

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: Another mass rebuild blocker: glibc qsort regression

[Florian Weimer]

* Florian Weimer:

> There's a regression in qsort that needs to be fixed before the mass
> rebuild can be restarted:
>
>   <https://bugzilla.redhat.com/show_bug.cgi?id=2259845>
>
> I'm going to work on this with priority.
>
> Posting this here because Fedora infrastructure is having authentication
> troubles.  Please relay as appropriate.

I was wrong, just because qsort is on the stack trace doesn't mean it's
another qsort bug. 8-/

It's back with Jakub for analysis from the GCC side.

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

Another mass rebuild blocker: glibc qsort regression

[Florian Weimer]

There's a regression in qsort that needs to be fixed before the mass
rebuild can be restarted:

  

I'm going to work on this with priority.

Posting this here because Fedora infrastructure is having authentication
troubles.  Please relay as appropriate.

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: Proposal: Eliminate buildroot overrides

[Florian Weimer]

* Stephen Gallagher:

> On Mon, Jan 22, 2024 at 1:55 PM Florian Weimer  wrote:
>>
>> * Stephen Gallagher:
>>
>> > I am unaware of any remaining use cases for buildroot overrides that
>> > are not covered by side tags. If you know of any, please speak up.
>>
>> The overrides are more discoverable:
>>
>>   <https://bodhi.fedoraproject.org/overrides/?expired=False>
>>
>
>> With side tags, you really have to know the name, or you won't be able
>> to find it.  On the other hand, you can just make your own and tag the
>> builds into it, so creating yet another one isn't that much of a problem
>> because they expire evenutally, just like overrides.
>
> What does that gain you, though? I'm not clear on the use-case here.
> Generally when there's a multi-packager effort going on for a
> side-tag, it's coordinated by mail or IRC between people. I'm not sure
> when you'd need to "discover" it.

It's been an issue once or twice when we relied more on ephemeral
channels such as IRC (or just.  But you are right, it does not matter
much these days.

(For rediscovering your own side tags, there is “koji list-sidetags
--mine”.)

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: Proposal: Eliminate buildroot overrides

[Florian Weimer]

* Stephen Gallagher:

> I am unaware of any remaining use cases for buildroot overrides that
> are not covered by side tags. If you know of any, please speak up.

The overrides are more discoverable:

  

With side tags, you really have to know the name, or you won't be able
to find it.  On the other hand, you can just make your own and tag the
builds into it, so creating yet another one isn't that much of a problem
because they expire evenutally, just like overrides.

I think I may have used a buildroot override fairly recently (or created
one for someone else to use), but I could have easily created a side tag
instead.  It just didn't occur to me.  All things consdier, the side tag
approach seems the way to go.

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: Proposal: Eliminate buildroot overrides

[Florian Weimer]

* blinxen:

>> I am unaware of any remaining use cases for buildroot overrides that
>   are not covered by side tags
>
> One use case that I sometimes encounter is requiring a newer version
> for a dependency, that is submitted to Bodhi with a side-tag. Since
> the build is in a side-tag, I can't access it without building into
> that specific side-tag. Also I can't stop the Bodhi Update just to add
> my own build. In this case, I need to create a buildroot override to
> be able to build my package in my own side-tag.

I think you can tag that build into your side tag?  This should require
provenpackager privileges, as far as I understand it.

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: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Florian Weimer]

* Panu Matilainen:

> Using something path-based will also exclude EVERYTHING started with a
> shebang. I guess we didn't want to optimize those
> Python/Perl/Ruby/whatnot scripts here?
>
> A path based approach isn't anywhere near worth the mess it creates. A
> humble opinion.

I'm not sure if it's necessary.  Most script interpreters (so things
that are typically used with shebangs) live in DSOs now, so they
wouldn't need the path-based optimization anyway.

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: AusweisApp2 build failed on rawhide/x86_64 (unsupported reloc 43)

[Florian Weimer]

* Julian Sikorski:

> AusweisApp2-2.0.3 build failed on rawhide/x86_64 with unsupported
> reloc 43 errors [1]. Other architectures have built fine, similarly to
> released branches. Is this a problem with rawhide ld.gold?
>
> Best regards,
> Julian
>
> [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=112033714

From the build log:

/usr/include/qt6/QtCore/qmetatype.h:1320: error: unsupported reloc 43
/builddir/build/BUILD/AusweisApp-2.0.3/src/workflows/base/controller/WorkflowController.cpp:17:
 error: unsupported reloc 43
/builddir/build/BUILD/AusweisApp-2.0.3/src/workflows/base/states/StateCheckRefreshAddress.cpp:400:
 error: unsupported reloc 43
/usr/include/qt6/QtCore/qsharedpointer_impl.h:704: error: unsupported reloc 43

Most likely a duplicate of bug 2259333.

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

[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
>   <https://gitlab.gnome.org/GNOME/vala/-/merge_requests/369>
>
> 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: 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
>   <https://gitlab.gnome.org/GNOME/vala/-/merge_requests/369>
>
> 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

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

Re: Schedule for Monday's FESCo Meeting (2024-01-15)

[Florian Weimer]

We still don't have approval for the toolchain updates that we need for
the mass rebuild (notably Changes/GNUToolchainF40).

How do we resolve this?  Do we delay the mass rebuild until we have
FESCo approval?  We can delay the GNU TLS descriptor change for x86-64
to Fedora 41, but doing that for the glibc 2.39 and GCC 14 updates would
be awkward (and substantial extra work for glibc).

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

-fcf-protection dropped from i686 compiler flags

[Florian Weimer]

This feature will never be implemented in the Linux kernel, so it does
not make sense to generate the additional support code for it.  Related
code has already been removed from rawhide glibc.

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: redhat-rpm-config now tied to Changes/GNUToolchainF40

[Florian Weimer]

* Florian Weimer:

> I pushed the changes that enable C type safety level handling once GCC
> 14 is merged and built it into the GCC 14 side tag (currently
> f40-build-side-81394).  I didn't add any conflicts with GCC 13 because
> the incompatibility is only present if a package lowers the C type
> safety level to 0.

So this warning didn't work and we have a new build with that change
tagged into f40.  I'll keep doing updates in f40 then, despite the
incompatibility with type safety level 0.

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

redhat-rpm-config now tied to Changes/GNUToolchainF40

[Florian Weimer]

I pushed the changes that enable C type safety level handling once GCC
14 is merged and built it into the GCC 14 side tag (currently
f40-build-side-81394).  I didn't add any conflicts with GCC 13 because
the incompatibility is only present if a package lowers the C type
safety level to 0.

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

Turning a XImage * into a Drawable for use with XRenderCreatePicture

[Florian Weimer]

The pcb-rnd package contains a call:

XRenderCreatePicture(display, lpm->img_scaled, XRenderFindVisualFormat(display, 
DefaultVisual(display, screen)), 0, 0);

The issue here is that lpm->img_scaled is an XImage *, but
XRenderCreatePicture expected a Drawable as its second argument.

Any idea how to turn an XImage into a Drawable?

Not sure how this currently works, but GCC 14 refuse to compile this, as
a C type error (using a pointer as an integer).

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: Packed relative ELF relocations (DT_RELR) enabled by default in rawhide

[Florian Weimer]

* Alessandro Astone:

> It also appears for aarch64.
> It is an issue because software may use `-Wl,--fatal-warnings` so this 
> warning breaks the build.
> As an example, pretty much the entire KDE software collection now fails to 
> compile on aarch64 and s390x: 
> https://invent.kde.org/frameworks/extra-cmake-modules/-/blob/04affb76a6af4ccbda50abfe264c62d7b7f60d84/kde-modules/KDECompilerSettings.cmake#L549

The redhat-rpm-config-274-1.fc40 update should have a workaround for
that.  It skips -z pack-relative-relocs on aarch64 and s390x.

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: ARM PAC on koji vs COPR

[Florian Weimer]

* Jarek Prokop:

> This spawns a few questions for me:
> 1. Since [1] the `-mbranch-protection=pac-ret` is needed in both
> CFLAGS and ASFLAGS, I am unsure how it interacts with the Fedora
> defaults,
> I see default CFLAGS contain `-mbranch-protection=standard` and the
> flag with pac-ret seems to be appended to libruby.so in the case of
> the upstream fix [2].
>
> From what I understand, it shouldn't cause problems to have these 2
> flags at the same time on the correct compilation artifacts, is that
> correct?

I wouldn't use both flags at the same time because the meaning is
unclear.  Is BTI still enabled if you do that?

Can't you put -mbranch-protection=standard into ASFLAGS?

The check is a bit weird:

diff --git a/configure.ac b/configure.ac
index 9286946fc15f4..18b4247991d42 100644
--- a/configure.ac
+++ b/configure.ac
@@ -830,7 +830,10 @@ AS_IF([test "$GCC" = yes], [
AS_FOR(option, opt, [-mbranch-protection=pac-ret 
-msign-return-address=all], [
 RUBY_TRY_CFLAGS(option, [branch_protection=yes], 
[branch_protection=no])
 AS_IF([test "x$branch_protection" = xyes], [
+# C compiler and assembler must be consistent for 
-mbranch-protection
+# since they both check `__ARM_FEATURE_PAC_DEFAULT` definition.
 RUBY_APPEND_OPTION(XCFLAGS, option)
+RUBY_APPEND_OPTION(ASFLAGS, option)
 break
 ])
 ])



The reliable way to do this would be to compile a C file and check
whether that enables __ARM_FEATURE_PAC_DEFAULT, and if that's the case,
define a *different* macro for use in the assembler implementation.
This way, you don't need to care about the exact name of the option.

> 2. Since files compiled with `-mbranch-protection=pac-ret` seem to end
> up in the .so library and Ruby binary extensions link against that
> solib, do the binary extensions also have to be compiled with that
> exact option?

It depends on how fiber handling is implemented.  If fiber switching
relies on code in header files or that is statically linked into Ruby
extensions, then yes, these extensions will need to be compiled with PAC
support as well.  But I expect that this isn't the case, but haven't
checked it.  The relevant code should be in the Ruby DSO only and be
linked dynamically.

It also seems unlikely that many C extensions would be aware of fiber
switching, but I haven't checked that, either.

> 3. If we do not fix this bug in Ruby 3.3.0 but wait with this for
> 3.3.1 where the fix will most probably land, will we by effect exclude
> a subset of ARM CPUs, that actually have the PAC capability, for that
> in-between period?

I think you should fix this with a backport.  It's going to impact quite
a few users.

> 4. Why do koji and copr have CPU flag set that differs so much? Is our
> koji infra OK?

It's different machines, so they are expect to have different
capabilities.  This isn't even aarch64-specific.

> 5. Why does it fail on copr and does not fail on koji? It seems the
> paca/pacg have to be present and set on the CPU flags for the
> segfaults to occur.

PAC is not process-switched on Linux.  If it is turned on at the
kernel/hypervisor level, it's currently impossible to turn off.  This is
not something the buildroot can control.  It's not actually a hardware
limitation, it's just how it has been implemented on Linux.  (Although
we would turn it on for the Fedora buildroots at this point.)

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: Packed relative ELF relocations (DT_RELR) enabled by default in rawhide

[Florian Weimer]

* Dan Horák:

> On Wed, 03 Jan 2024 10:47:12 +0100
> Florian Weimer  wrote:
>
>> This changed was originally planned and approved for Fedora 39.  It
>> reduces startup time somewhat for large objects with lots of function
>> and object pointers in global data.
>> 
>> It should be a transparent change, internal to the toolchain.  Within
>> glibc itself, we started using this linker feature in glibc 2.36 (Fedora
>> 37), and no issues surfaced.  A few dozen test rebuilds of core packages
>> did not show any issues, either.
>
> is
> /usr/bin/ld: warning: -z pack-relative-relocs ignored
> related? It seems to appear in s390x builds.

Yeah, it is, it did not occur to me to check that it was actually
enabled in the link editor on all architectures because the format is
portable.  I'll raise the gap with IBM.

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

Packed relative ELF relocations (DT_RELR) enabled by default in rawhide

[Florian Weimer]

This changed was originally planned and approved for Fedora 39.  It
reduces startup time somewhat for large objects with lots of function
and object pointers in global data.

It should be a transparent change, internal to the toolchain.  Within
glibc itself, we started using this linker feature in glibc 2.36 (Fedora
37), and no issues surfaced.  A few dozen test rebuilds of core packages
did not show any issues, either.

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] PR #11: Update Compress::Raw::Zlib for improved compatibility with zlib-ng

[Florian Weimer]

fweimer opened a new pull-request against the project: `perl` that you are 
following:
``
Update Compress::Raw::Zlib for improved compatibility with zlib-ng
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl/pull-request/11
--
___
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)

[Florian Weimer]

* 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

Re: RISC-V ABI issue with ULEB128

[Florian Weimer]

* 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

Re: Update on the Modern C initiative

[Florian Weimer]

* 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

[Florian Weimer]

* 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

Re: Update on the Modern C initiative

[Florian Weimer]

* Solomon Peachy via devel:

> On Fri, Dec 22, 2023 at 02:18:54PM +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.

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: Update on the Modern C initiative

[Florian Weimer]

* Richard W. M. Jones:

> On Thu, Dec 21, 2023 at 01:59:59PM +0100, Florian Weimer wrote:
>> Based on my records, all issues that can lead to silent miscompilation
>> because of altered configure probes (autoconf/CMake and a few others)
>> have been addressed, or there are at least Bugzilla bugs filed for them.
>> There could be some gaps due to lack of architecture capture, general
>> rawhide churn, or configure scripts running late during the build, which
>> we do not reach due to a previous build failure.  But these gaps should
>> fairly small, I hope.  It's also not a new problem—while fixing newly
>> introduced errors, we encountered cases where autoconf probes had
>> already been failing unexpectedly for a long time because of typos or
>> missing #include directives.
>> 
>> I originally wanted to fix the int-conversion issues next.  That package
>> set is fairly small (about 60 packages).
>
> Do you have a list of affected packages?

This is the list:

Maintainers by package:
BitchX   kme rdieter
adobe-afdko  petersen vishalvvr
autoconf fberat fjanus jnovy kasal praiskup ttomecek
ceph branto kkeithle ktdreyer
clearsilver  limb pwouters
curlftpfsaekoroglu
ffmpeg   asn ngompa rathann
fluent-bit   bkircher
foma vpv
glib2alexl caolanm mclasen rhughes rstrode
glusterfs-coreutils  anoopcs devos kkeithle
grassdevrim jonathanspw neteler
gtk-sharp2   caolanm laxathom rhughes rstrode tpokorra
gtk-v4l  huzaifas
gutenprint   jpopelka jridky twaugh zdohnal
java-1.8.0-openjdk-portable ahughes jandrlik jhuttana jvanek
libdbfjanus hhorak mmuzila pkubat
libfreenect  jkastner kathenas kwizart rmattes
libkdumpfile dcavalca salimma
libmpd   adrian nonamedotc
libprelude   fab limb totol
libskk   ueno
libsmi   jsafrane rvokal spot
libtrash kdudka lzaoral svashisht
libx86   jcpunk
linhpsdr jskarvad
mapserverdevrim jujens pali smani
opendbx  mdomsch
openhpi  rdossant sharkcz
openjfx  deamn
openscap evgenyz jcerny matyc mmarhefk rebus vpolasek wsato
paps tagoh
pcb-rnd  avigne
perl-XML-Barecicku eseyman
poke defolos mikelo2
python-axolotl-curve25519 principis
python-kadminlimb
python-multidict athmane carlwgeorge fab
python-poetry-core   churchyard thrnciar
python-pyopengl  swt2c
python-subvertpy fab
python3-postgresql   hhorak
raptor2  rdieter
rep-gtk  kimheino
ruby-gnome2  mtasaka
rubygem-glu  mtasaka
rubygem-serialport   aeperezt
rubygem-xmlparserschwicke
schedtooldcavalca drago01
skf  mtasaka
ski  sharkcz
squeak-vmjskarvad
ssmtpwolfy
tcl-signal   orion
totem-pl-parser  kalev nacho
xen  jforbes myoung
zbar limb mchehab slaanesh
zziplib  abbra jamartis

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: armadillo soname bump to version 12

[Florian Weimer]

* Florian Weimer:

> * Sandro Mani:
>
>> On 22.12.23 10:41, Florian Weimer wrote:
>>> * Ryan Curtin:
>>>
>>>> Hello there,
>>>>
>>>> I plan to bump the major version of the Armadillo linear algebra library
>>>> to version 12 for rawhide next week; this will be an ABI/API change.  I
>>>> will rebuild the package and its dependencies (looks like gdal and
>>>> mlpack only) in the side tag 'f40-build-side-79101'.
>>> Looks like this was partially merged into rawhide?
>>>
>>> | Failed to resolve the transaction:
>>> | No match for argument: 
>>> /usr/share/fonts/dejavu-sans-fonts/DejaVuSans-Bold.ttf
>>> | No match for argument: /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf
>>> | Problem: package gdal-devel-3.8.2-1.fc40.x86_64 requires 
>>> libgdal.so.34()(64bit), but none of the providers can be installed
>>> |   - package gdal-devel-3.8.2-1.fc40.x86_64 requires gdal-libs(x86-64) = 
>>> 3.8.2-1.fc40, but none of the providers can be installed
>>> |   - cannot install the best candidate for the job
>>> |   - nothing provides libarmadillo.so.10()(64bit) needed by 
>>> gdal-libs-3.8.2-1.fc40.x86_64
>>>
>>> Seen while trying to rebuild mapserver with unchanged sources.
>>
>> There is gdal-3.8.2-2.fc40 which is correctly built against
>> libarmadillo.so.12
>
> Huh.  Somehow that didn't make it into the compose?

Ahh, looks like 3.8.2-1 wasn't built in the side tag.  That explains it.

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: armadillo soname bump to version 12

[Florian Weimer]

* Sandro Mani:

> On 22.12.23 10:41, Florian Weimer wrote:
>> * Ryan Curtin:
>>
>>> Hello there,
>>>
>>> I plan to bump the major version of the Armadillo linear algebra library
>>> to version 12 for rawhide next week; this will be an ABI/API change.  I
>>> will rebuild the package and its dependencies (looks like gdal and
>>> mlpack only) in the side tag 'f40-build-side-79101'.
>> Looks like this was partially merged into rawhide?
>>
>> | Failed to resolve the transaction:
>> | No match for argument: 
>> /usr/share/fonts/dejavu-sans-fonts/DejaVuSans-Bold.ttf
>> | No match for argument: /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf
>> | Problem: package gdal-devel-3.8.2-1.fc40.x86_64 requires 
>> libgdal.so.34()(64bit), but none of the providers can be installed
>> |   - package gdal-devel-3.8.2-1.fc40.x86_64 requires gdal-libs(x86-64) = 
>> 3.8.2-1.fc40, but none of the providers can be installed
>> |   - cannot install the best candidate for the job
>> |   - nothing provides libarmadillo.so.10()(64bit) needed by 
>> gdal-libs-3.8.2-1.fc40.x86_64
>>
>> Seen while trying to rebuild mapserver with unchanged sources.
>
> There is gdal-3.8.2-2.fc40 which is correctly built against
> libarmadillo.so.12

Huh.  Somehow that didn't make it into the compose?

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: armadillo soname bump to version 12

[Florian Weimer]

* Ryan Curtin:

> Hello there,
>
> I plan to bump the major version of the Armadillo linear algebra library
> to version 12 for rawhide next week; this will be an ABI/API change.  I
> will rebuild the package and its dependencies (looks like gdal and
> mlpack only) in the side tag 'f40-build-side-79101'.

Looks like this was partially merged into rawhide?

| Failed to resolve the transaction:
| No match for argument: /usr/share/fonts/dejavu-sans-fonts/DejaVuSans-Bold.ttf
| No match for argument: /usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf
| Problem: package gdal-devel-3.8.2-1.fc40.x86_64 requires 
libgdal.so.34()(64bit), but none of the providers can be installed
|   - package gdal-devel-3.8.2-1.fc40.x86_64 requires gdal-libs(x86-64) = 
3.8.2-1.fc40, but none of the providers can be installed
|   - cannot install the best candidate for the job
|   - nothing provides libarmadillo.so.10()(64bit) needed by 
gdal-libs-3.8.2-1.fc40.x86_64

Seen while trying to rebuild mapserver with unchanged sources.

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: F40 Change Proposal: F40 Change Proposal: Unify /usr/bin and /usr/sbin (System-Wide)

[Florian Weimer]

* Aoife Moloney:

> == Detailed Description ==
> The split between `/bin` and `/sbin` is not useful, and also unused.

Programs in /usr/bin have their documentation in section 1 of the
manual, while programs /usr/sbin are documented in section 8.  (In
general, I deliberately used /usr/bin/ld.so although the manual page was
already called ld.so(8), without a program of this name existing.)

When moving programs, should we move the manual pages as well?  Or at
least add a link so that that section 1 references work?

Is there something we can do to help developers on Fedora systems to
write portable code (not just shell scripts) after this change is rolled
out?

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

Update on the Modern C initiative

[Florian Weimer]

Based on my records, all issues that can lead to silent miscompilation
because of altered configure probes (autoconf/CMake and a few others)
have been addressed, or there are at least Bugzilla bugs filed for them.
There could be some gaps due to lack of architecture capture, general
rawhide churn, or configure scripts running late during the build, which
we do not reach due to a previous build failure.  But these gaps should
fairly small, I hope.  It's also not a new problem—while fixing newly
introduced errors, we encountered cases where autoconf probes had
already been failing unexpectedly for a long time because of typos or
missing #include directives.

I originally wanted to fix the int-conversion issues next.  That package
set is fairly small (about 60 packages).  But it's more or less a coin
toss whether the compiler errors is due to a missing cast due to C type
system limitations, or indicative of a real problem (typically
manifesting as a crash at run time if the code is ever executed).  The
latter can be quite difficult to fix and may require domain-specific
knowledge.  Just adding the cast in both cases just obscures the crash
or misbehavior in the second case, and robs us of an opportunity to fix
this properly.  I see what I can do to fix packages, but it's unlikely
that it will going to be all of them.

Looking at the calendar and the projected time when GCC 14 will land in
the buildroot, I think we missed the window where a GCC 13 version with
a preview of these C front end changes would have been beneficial to
Fedora developers.  It would have also created an awkward issue where
__GNUC__ is 13, but the compiler behaves in part like GCC 14.  This is
relevant if it's necessary to suppress (or treat as warnings)
-Wreturn-mismatch diagnostics, which only exist in GCC 14.

This brings me to my final point.  We still don't have a solution for
Vala. I plan to look at valac soon and see what we can do to keep things
at least compiling with GCC 14 (after re-running valac).

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

Re: Making -Wmissing-include-dirs an error?

[Florian Weimer]

* Jonathan Wakely:

>> Missing an include directory isn't necessarily the problem though, it
>> is the missing headers that aren't present when they are included
>> that would be - and that should trigger a build error for the missing
>> file. What advantage does failing on this warning provide that the
>> failure on the include file missing doesn't?
>
> Typically, yes, I'd expect a failure. But it's possible for code to do:
>
> #if __has_include()
> # include 
> // use features in that header
> #else
> // roll your own inferior version
> #endif

I can see this might be a problem.

I wouldn't object if someone submitted a change proposal for this, but
they have to do the necessary work (full distribution rebuild to assess
the impact of the change, preferably with an instrumented/wrapped
toolchain to catch silently miscompiled autoconf probes).

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: goal: booting with an empty /etc

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

>> No, it would be the other way round.  We might have a
>> /usr/share/glibc/services which contains :include: /etc/services
>> somewhere in it.
>
> Ah, OK. I understand how the format would look, but I don't understand
> why you'd want to implement it rather than something simpler.
>
> /etc/services is essentially a flat file that is scanned from top to
> bottom until a matching entry is found. In the proposed syntax, it'd
> need to have ':include: /etc/services' at the very top, so that the local
> config in /etc/services has higher priority.
>
> Consider the following alternative: each of [/etc/services,
> /usr/etc/services] is scanned in order, if the file exists. This is
> simpler to implement and allows either of the files to exist
> independently of the other.  A stanza like ':include:' also opens the
> door for additional complications like different paths on different
> distros and include loops. It is _possible_, but the simpler scheme
> has the properties that we want.

I want to replace nss_wrapper with a simple set of environment
variables.  Once we have a multi-file search path, it's no longer so
simple because it's not clear if the default search path is amended or
replaced when the environment variable is set.

Loop detection on traditional file systems wouldn't be very difficult to
implement, except that we increasingly have file systems which have
dev_t/ino_t values that are not unique.  But that impacts any form of
loop detection, so I'm not overly concerned.

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: goal: booting with an empty /etc

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

> On Fri, Dec 08, 2023 at 05:23:08PM +0100, Florian Weimer wrote:
>> * Stephen Gallagher:
>> 
>> > That being said, there are files like /etc/nsswitch.conf, /etc/pam.d/*
>> > and /etc/fstab which are both API *and* sometimes see manual updates.
>> > These are some of the cases that are going to make getting to an empty
>> > /etc very hard to finish off. There's a lot of low-hanging fruit we
>> > can take care of in the meantime, but getting the last 1% of packages
>> > done is going to take a lot of inter-distro conversations.
>> 
>> We could add some sort of :include: processing to glibc, but that's
>> going to impact much more than just glibc in the end (Go has its own
>> parser for /etc/passwd, I believe others have their own for
>> /etc/nsswitch.conf).
>
> IIUC, you mean that e.g. /etc/services would still exist, but
> would contain ":include:/usr/etc/services". That's not a great answer,
> because you still need /etc/services to exist.

No, it would be the other way round.  We might have a
/usr/share/glibc/services which contains :include: /etc/services
somewhere in it.

> It's also a rather complex solution, because special parsing is
> needed… It's both easier and more powerful to say "check for
> /etc/services, and if doesn't exist, fall back to
> /usr/etc/services". It's:
> - simple to implement and understand,
> - backwards compatible in the sense that a local system that has
>   the file modified will work without changes,
> - and as discussed in another part of the thread, we can add
>   optionally add tmpfiles.d config to symlink /etc/services → 
> /usr/etc/services
>   on boot if there are other consumers that don't yet support the new
>   location.

Are you sure you mean check “for /etc/services, and if doesn't exist,
fall back to /usr/etc/services”?  That suggests that in order to edit
the file, you have to make a copy, and that means that the system won't
receive any services added to the system file.  “Look for the service in
/etc/services, and if it's not there, check /usr/etc/services” would
make more sense to me.  But that's not so far off from :include:
processing …

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: goal: booting with an empty /etc

[Florian Weimer]

* Stephen Gallagher:

> That being said, there are files like /etc/nsswitch.conf, /etc/pam.d/*
> and /etc/fstab which are both API *and* sometimes see manual updates.
> These are some of the cases that are going to make getting to an empty
> /etc very hard to finish off. There's a lot of low-hanging fruit we
> can take care of in the meantime, but getting the last 1% of packages
> done is going to take a lot of inter-distro conversations.

We could add some sort of :include: processing to glibc, but that's
going to impact much more than just glibc in the end (Go has its own
parser for /etc/passwd, I believe others have their own for
/etc/nsswitch.conf).

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: Proven to be sickened

[Florian Weimer]

* Kevin Kofler via devel:

> Michael J Gruber wrote:
>> I am sick of this. Really. I am so sick of this way of stomping on each
>> others' feet.
>
> My pet peeve is provenpackagers or comaintainers who add unwanted
> automagic (autorelease, autosetup, autochangelog) to my packages. I do
> not want any of that in my packages, it just makes my work harder (or
> in practice, just wastes my time for the revert that I am inevitably
> going to do).

If the package does not contain any patches yet, it's not really
possible to infer the maintainer intentions.  %setup vs %autosetup
doesn't matter much in that case, so it doesn't really tell us anything.
Likewise if the package uses %autosetup, but without -p1, and there are
no patches.  Does the maintainer really prefer those awkarward -p-less
patches?  We don't know.

Asking individual maintainers for trivial changes does not scale.  The
alternative would be not to address FTBFS and other build issues, maybe
file bugs, and rely on active maintainers instead.  But I don't think
that can work for Fedora, practically speaking.  Fedora lacks Debian's
ban on forcing packagers to do certain work.  In the past, FESCo has
used that to order that certain packagers must keep carrying out certain
work they do not want to do, but I think that only means anything if the
victim packager is a Red Hatter on certain teams, I think.  Others will
just quit if they disagree.

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: Update on the Modern C initiative

[Florian Weimer]

* Jakub Jelinek:

> On Tue, Dec 05, 2023 at 04:38:55AM +0100, Kevin Kofler via devel wrote:
>> Florian Weimer wrote:
>> > The final patches for GCC 14 are currently under upstream review and
>> > should land very soon.  Earlier, I had received feedback that the larger
>> > community desires just one transition, so we end up with the following
>> > warnings which turn into errors by default:
>> > 
>> >   -Wimplicit-function-declaration
>> >   -Wimplicit-int
>> >   -Wint-conversion
>> >   -Wreturn-mismatch (new, previously part of -Wreturn-types)
>> >   -Wdeclaration-missing-parameter-type (new, previously unnamed)
>> >   -Wincompatible-pointer-types
>> > 
>> > Only the first two were covered in the initial Fedora conversion work.
>> 
>> As much as I understand the point of -Werror=implicit-function-declaration 
>> (since implicit function declarations can cause several subtle bugs), and 
>> implicit int is obscure enough for its removal to not be a big problem (even 
>> though its potential for causing bugs is much lower), as much I have to 
>> wonder about the others. Especially the incompatible pointer types sound 
>> more like nitpicking than actual bugs (though I guess strict aliasing can 
>> cause issues with those, but then I would expect to see -Wstrict-aliasing 
>> warnings).
>
> Look at the gimp case, where a function prototype was expecting double *
> argument but caller was calling it with address of float.
> void foo (double *);
> void
> bar ()
> {
>   float f = 5.0f;
>   foo ();
> }

> While this resulted in a warning even without -Wall, clearly nobody noticed
> until this was made an error:

And this results in an out-of-bounds write and potential memory
corruption.

That's actually not uncommon for such bugs.  Here's a similar issue for
python-tables:

  
<https://github.com/PyTables/PyTables/commit/44168c0d8e4c059ea51c8bc98a10784a74454b54>

Although the critical type size mismatch happens on 32-bit architectures
and Windows only.  Problems like these are the reason why I don't think
the Clang approach of restricting to incompatible-function-pointer-types
only makes much sense.

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: Update on the Modern C initiative

[Florian Weimer]

* Richard W. M. Jones:

> On Sat, Dec 02, 2023 at 09:15:28PM +, Richard W.M. Jones wrote:
>> On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
>> > nbdkit   rjones
>> 
>> Can you help me to understand the build error in this log?
>> 
>> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdkit.log?ref_type=heads
>> 
>> I'm not exactly sure what / where the error is supposed to be.
>> 
>> Possibly it is complaining about this autoconf test, but I don't
>> understand what's wrong with the cast, since AFAIK making a pointer
>> "more const" should be fine:
>> 
>>   configure:20816: checking if environ is declared in header files
>>   configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
>> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
>> -Werror=implicit-function-declaration -Werror=implicit-int 
>> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS 
>> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
>> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic 
>> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
>> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
>>   conftest.c: In function 'test':
>>   conftest.c:62:22: error: initialization of 'const char **' from 
>> incompatible pointer type 'char **'
>>  62 |   const char **env = environ;
>> |  ^~~
>> 
>> (source: 
>> https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248a799485/configure.ac#L327)
>
> Fixed upstream here:
> https://gitlab.com/nbdkit/nbdkit/-/commit/32a9ee6650654469cd591a3ae26842c54f898392

Thanks.  Could you bring this into rawhide as well?

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: Update on the Modern C initiative

[Florian Weimer]

* Milan Crha:

> The a), an expected failure, is this one:
>  .../TryCompile-0C2YRH/src.c: In function ‘main’:
>  .../TryCompile-0C2YRH/src.c:11:37: warning: redundant redeclaration of 
> ‘__h_errno_location’ [-Wredundant-decls]
> 11 | int h_errno;
>| ^~~
>  /usr/include/netdb.h:59:13: note: previous declaration of 
> ‘__h_errno_location’ with type ‘int *(void)’
> 59 | extern int *__h_errno_location (void) __THROW __attribute__ 
> ((__const__));
>| ^~
>  .../TryCompile-0C2YRH/src.c:12:111: warning: passing argument 7 of 
> ‘gethostbyaddr_r’ from incompatible pointer type 
> [-Wincompatible-pointer-types]
> 12 | (void)gethostbyaddr_r 
> ("www.ximian.com", 14, AF_INET, , buffer, bufsize, _errno);
>|  
>  ^
>|  
>  |
>|  
>  int *
>  /usr/include/netdb.h:174:57: note: expected ‘struct hostent ** restrict’ 
> but argument is of type ‘int *’
>174 | struct hostent **__restrict __result,
>| ^~~~
>  .../TryCompile-0C2YRH/src.c:12:39: error: too few arguments to function 
> ‘gethostbyaddr_r’
> 12 | (void)gethostbyaddr_r 
> ("www.ximian.com", 14, AF_INET, , buffer, bufsize, _errno);
>|   ^~~
>  /usr/include/netdb.h:170:12: note: declared here
>170 | extern int gethostbyaddr_r (const void *__restrict __addr, 
> __socklen_t __len,
>|^~~
>  gmake[1]: *** [CMakeFiles/cmTC_3133a.dir/build.make:78: 
> CMakeFiles/cmTC_3133a.dir/src.c.o] Error 1
>  gmake[1]: Leaving directory '.../TryCompile-0C2YRH'
>  gmake: *** [Makefile:127: cmTC_3133a/fast] Error 2
>
> Note the `too few arguments to function ‘gethostbyaddr_r’` error
> follows the `incompatible pointer type` warning, which is going to be
> an error after the proposed change.

No, that's actually not changing, this is already an error and will
remain an error.  Only the -Wincompatible-pointer-types warning above is
upgraded to an error, but it does not alter the outcome of this check
because there already is another error (and the current GCC
instrumentation is able to detect this an not flag the
-Wincompatible-pointer-types issue).

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: Update on the Modern C initiative

[Florian Weimer]

* Richard W. M. Jones:

> On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
>> * Integrate a backport of the GCC 14 changes into the rawhide GCC 13
>>   version (rawhide only, not Fedora 39 or 38).  This will allow us
>>   to isolate these issues from GCC 14 issues that typically occur
>>   during the upcoming mass rebuild.
>
> Is there an RPM of GCC 14 / GCC 13 + these backports anywhere?

Jakub did a scratch build recently:

  gcc-14.0.0-0.2.fc40
  <https://koji.fedoraproject.org/koji/taskinfo?taskID=109799520>

Note that this is a development compiler.

For tracking down compatibility issues, you can also use mock with the
instrumented compiler repository:

  
<https://fedoraproject.org/wiki/Toolchain/PortingToModernC#Special_COPR_repository_with_instrumented_GCC>

This is based on GCC 13, so fewer moving parts.

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: Update on the Modern C initiative

[Florian Weimer]

* Richard W. M. Jones:

> On Thu, Nov 30, 2023 at 06:09:55PM +0100, Florian Weimer wrote:
>> nbdkit   rjones
>
> Can you help me to understand the build error in this log?
>
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/raw/main/logs/n/nbdkit.log?ref_type=heads
>
> I'm not exactly sure what / where the error is supposed to be.
>
> Possibly it is complaining about this autoconf test, but I don't
> understand what's wrong with the cast, since AFAIK making a pointer
> "more const" should be fine:
>
>   configure:20816: checking if environ is declared in header files
>   configure:20833: gcc -c -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
> -grecord-gcc-switches -pipe -Wall -Werror=format-security 
> -Werror=implicit-function-declaration -Werror=implicit-int 
> -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS 
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic 
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer   conftest.c >&5
>   conftest.c: In function 'test':
>   conftest.c:62:22: error: initialization of 'const char **' from 
> incompatible pointer type 'char **'
>  62 |   const char **env = environ;
> |  ^~~
>
> (source: 
> https://gitlab.com/nbdkit/nbdkit/-/blob/380f975bb9a07063f370835c51e1cd248a799485/configure.ac#L327)

The inner pointer is const, not the outer pointer.  The rule about
compatibility only applies to the outer const, not to any inner const.

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: Update on the Modern C initiative

[Florian Weimer]

* Vít Ondruch:

> Dne 01. 12. 23 v 11:40 Milan Crha napsal(a):
>> On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
>>> Again, some of these are false positives.
>>  Hi,
>> I think the errors from the configure time of the script are not always
>> problems, are they?
>
>
> This probably falls into the configuration bucket:
>
> https://gitlab.com/fweimer-rh/fedora-modernc-logs/-/blob/main/logs/r/rubygem-ruby-libvirt.log?ref_type=heads
>
> But I don't even know where GCC digs up the issues.

It looks like the GCC output lands in this file:

ruby-libvirt-0.7.1/usr/lib64/gems/ruby/ruby-libvirt-0.7.1/mkmf.log

I have not seen that one before, so the log dumper in the buildroot
instrumentation does not cover it, sorry.

The failures look like this:

“
LD_LIBRARY_PATH=.:/usr/lib64 "gcc -I/usr/include -I/usr/include/ruby/backward 
-I/usr/include -I. -O2 -flto=auto -ffat-lto-objects -fexceptions -g 
-grecord-gcc-switches -pipe -Wall -Werror=format-security 
-Werror=implicit-function-declaration -Werror=implicit-int 
-Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS 
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64   -mtune=generic 
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -fPIC  -m64  -c 
conftest.c"
conftest.c:8:16: error: initialization of ‘int’ from ‘char *’ makes integer 
from pointer without a cast
8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
  |^
In file included from /usr/include/libvirt/libvirt.h:35,
 from conftest.c:5:
conftest.c:8:16: error: initializer element is not computable at load time
8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
  |^
conftest.c:8:12: warning: ‘t’ defined but not used [-Wunused-variable]
8 | static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
  |^
checked program was:
/* begin */
1: #include "ruby.h"
2: 
3: #include "ruby.h"
4: 
5: #include 
6: 
7: /*top*/
8: static int t = VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES;
/* end */
”

Looking at the Ruby MakeMakefile documention:

<https://docs.ruby-lang.org/en/master/MakeMakefile.html#method-i-have_const>

I think you need to supply a type for these constants and call
have_const like this:

  have_const(["VIR_NODE_MEMORY_SHARED_MERGE_ACROSS_NODES",
  "const char *"], ["libvirt/virterror.h"])

Does this help?  I'm not a Ruby programmer, so I'm not even sure if I
got the list syntax right …

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: Update on the Modern C initiative

[Florian Weimer]

* Milan Crha:

> On Thu, 2023-11-30 at 18:09 +0100, Florian Weimer wrote:
>> Again, some of these are false positives. 
>
>   Hi,
> I think the errors from the configure time of the script are not always
> problems, are they? At least in the case of the evolution-data-server,
> it's half a problem and half expected.

Yes, we have definitely need an exception list for implicit function
declarations.

> Specifically, one "configure" (there is used CMake) check tries to
> figure out whether gethostbyname_r() has five arguments. It does not in
> Fedora, thus a) there are passed no enough arguments to the function;
> b) there are incompatible types passed to the function. Both are
> claimed by gcc. The second is due to the first. The result of this
> "source compiles" test is correct, the function does not have five
> arguments.

I don't see this.  The evolution-data-server-3.50.2-1.fc39 and
evolution-data-server-3.50.2-1.fc40 have this:

-- Performing Test HAVE_I_CAL_EMAIL_PARAMETER
-- Performing Test HAVE_I_CAL_EMAIL_PARAMETER - Success

While my test build has:

-- Performing Test HAVE_I_CAL_EMAIL_PARAMETER
-- Performing Test HAVE_I_CAL_EMAIL_PARAMETER - Failed

So the test outcome is altered by the new error.

Furthermore, in the YAML log, I don't see the second error about the
mismatching parameter count:

“
…-build/CMakeFiles/CMakeScratch/TryCompile-HmYCHv/src.c: In function ‘main’:
…-build/CMakeFiles/CMakeScratch/TryCompile-HmYCHv/src.c:5:39: error: assignment 
to ‘icalparameter *’ {aka ‘struct icalparameter_impl *’} from incompatible 
pointer type ‘ICalParameter *’
5 | param = 
i_cal_property_get_first_parameter (NULL, I_CAL_EMAIL_PARAMETER);
  |   ^
…-build/CMakeFiles/CMakeScratch/TryCompile-HmYCHv/src.c:6:60: error: passing 
argument 1 of ‘i_cal_parameter_get_email’ from incompatible pointer type
6 | i_cal_parameter_get_email (param);
  |^
  ||
  |
icalparameter * {aka struct icalparameter_impl *}
In file included from /usr/include/libical-glib/i-cal-parameter.h:28,
 from /usr/include/libical-glib/i-cal-component.h:27,
 from /usr/include/libical-glib/libical-glib.h:34,
 from …-build/CMakeFiles/CMakeScratch/TryCompile-HmYCHv/src.c:2:
/usr/include/libical-glib/i-cal-derived-parameter.h:399:71: note: expected 
‘const ICalParameter *’ but argument is of type ‘icalparameter *’ {aka ‘struct 
icalparameter_impl *’}
  399 | const gchar *   i_cal_parameter_get_email   (const 
ICalParameter *param);
  |  
~^
”

The instrumented GCC can backpropagate certain errors and suppress the
logging of otherwise critical errors (even if they occurred earlier in
the file), including in some cases if there are too many function
arguments.  However, this suppression heuristic is presently incomplete.
But I don't think it matters here because there is no such error in the
CMake probe.

> Another "configure" check used incorrect arguments in error. I
> corrected it for the development version [1], which should be released
> at the beginning of the next year.

> [1] 
> https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/8d3c23e68aada59c5deb59a664aea263f075

Ahh, sorry, I think I looked at this error because that's the only one
that makes it into the critical error log. 8-)

The first one you mentioned has probably been suppressed by the
heuristic.  Still sending this message because it might be helpful to
show how this works.

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: Update on the Modern C initiative

[Florian Weimer]

* Vít Ondruch:

>> Build logs with results from the instrumentation are available here;
>>
>>
>>
>> We delete logs from that repository as packages get fixed.
>
>
> How often this happens? It seems that there might be upstream fix for
> rubygem-curb, so if I update the package, how soon I'll know it
> helped?

You can build against the COPR repository to test:

  


I don't have a rechecking schedule, it depends on whether I find a way
to improve the GCC instrumentation.

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

Update on the Modern C initiative

[Florian Weimer]

This message is realted to:

  
  

The final patches for GCC 14 are currently under upstream review and
should land very soon.  Earlier, I had received feedback that the larger
community desires just one transition, so we end up with the following
warnings which turn into errors by default:

  -Wimplicit-function-declaration
  -Wimplicit-int
  -Wint-conversion
  -Wreturn-mismatch (new, previously part of -Wreturn-types)
  -Wdeclaration-missing-parameter-type (new, previously unnamed)
  -Wincompatible-pointer-types

Only the first two were covered in the initial Fedora conversion work.

I've done another round of test builds with an instrumented GCC for all
errors, and the numbers of problematic packages I have today are:

  autoconf
  all only
  implicit-function-declaration53   21
  implicit-int  20
  int-conversion   99   33
  return-mismatch  132
  declaration-missing-parameter-type00
  incompatible-pointer-types  374   50
  487   89

(I've updated the change page to describe those diagnostics briefly.)

The numbers don't add up because one package can have multiple issues.
Some of the reported issues are false positives, although the GCC
instrumentation is a bit better than it used to be.

The autoconf column covers packages which are particularly at risk for
silent miscompilation because of incorrect detection of build system
features.  This is based on file name heuristics and includes more than
just autoconf proper.

As you can see, the incompatible-pointer-types issues are a bit of a
problem.  We fixed over 800 packages during the first round, and now it
looks like we are only two thirds done.

It is unlikely that I will be able to work on all these issues
myself or with help from the people around me.  I just suggested to GCC
upstream that we may have to reconsider including this change in the GCC
14 release.

Consequently, my priorities are as follows:

* Try to resolve the autoconf issues in packages, to reduce the risk of
  silent miscompilation.

* Integrate a backport of the GCC 14 changes into the rawhide GCC 13
  version (rawhide only, not Fedora 39 or 38).  This will allow us
  to isolate these issues from GCC 14 issues that typically occur
  during the upcoming mass rebuild.

* Produce the final redhat-rpm-config integration, using -fpermissive
  for _build_type_safety_c 0, and -Wno-error= options for the higher
  type safety levels.  This obviously depends on -fpermissive and and
  the new warning names becoming available in rawhide, which is another
  reason for the GCC 13 backport.

* Come up with a way to resolve the Vala situation, likely by embedded
  “#pragma GCC diagnostic” in the generated C source files.  Vala is
  currently not able to generate type-safe C, and is unlikely that this
  going to change soon.  (The numbers above do not include packages
  which have failures in Vala code only.)  In some cases, there is
  nothing that can be done about this on the Vala source code side.  Not
  all of these type errors are harmless, of course, but I don't see a
  way to deal with this except by telling GCC to be less picky.

I'm attaching package maintainer lists, generated using the
find-package-maintainers script from fthe
 repository, for both
the full package set, and the autoconf-impacted package set.

Build logs with results from the instrumentation are available here;

  

We delete logs from that repository as packages get fixed.

Again, some of these are false positives.  The second link at the start
has instructions for a COPR repository if you want to verify things
locally (sadly the Koji build target is currently not in working order).

Thanks,
Florian
Maintainers by package:
0ad  kalev pcpa pwalter
389-ds-base  abbra jamiechap mreynolds spichugi tbordaz vashirov
3proxy   rathann
BibTool  mjg orion
BitchX   kme rdieter
Cython   churchyard ignatenkobrain nbecker stevetraylen
EMBOSS   spot
Io-language  limb
MagicPoint   jwrdegoede
ORBit2   alexl caolanm danw limb rhughes rstrode
OpenIPMI branto jridky pcahyna
SDL_imagejwrdegoede limb
TeXmacs  jnovy orion
Xaw3djwrdegoede orion
adobe-afdko  petersen vishalvvr
afflib   kwizart rebus
afpfs-ng rebus
ags  rathann
alfont   jwrdegoede
algol68g ol
alienarena   spot
alsa-tools   perex timj
anjuta   kalev limb
annobin

Re: libxml2 2.12.0 (and 2.12.1) in rawhide, with some API breaks

[Florian Weimer]

* Petr Pisar:

> Well abidiff for createrepo_c
> 
> complains:
>
>   underlying type 'xmlParserCtxt*' changed:
> in pointed to type 'typedef xmlParserCtxt' at tree.h:40:1:
>   underlying type 'struct _xmlParserCtxt' at parser.h:181:1 
> changed:
> type size changed from 3840 to 3968 (in bits)
> 4 data member insertions:
>   'unsigned int maxAmpl', at offset 3840 (in bits) at 
> parser.h:323:1
>   'xmlParserNsData* nsdb', at offset 3872 (in bits) at 
> parser.h:325:1
>   'unsigned int attrHashMax', at offset 3904 (in bits) at 
> parser.h:326:1
>   'xmlAttrHashBucket* attrHash', at offset 3936 (in bits) at 
> parser.h:327:1
> 1 data member changes (5 filtered):
>   type of 'int* attallocs' changed:
> in pointed to type 'int':
>   type name changed from 'int' to 'unsigned int'
>   type size hasn't changed
>
> While most (all?) libxml2 functions pass a pointer to xmlParserCtxt, a
> definition of the xmlParserCtxt structure is open to anybody in
> . That means an application built against old libxml2 can
> construct a different structure than libxml2 expects. That is called
> an ABI breakage.

I don't think the API allows you to bring your own xmlParserCtxt object
(stack-allocated or heap-allocated).  The new members are added at the
end, so this is probably fine.

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: How can I delete a rawhide Bodhi update?

[Florian Weimer]

* Mattia Verga via devel:

> Il 23/11/23 16:40, Florian Weimer ha scritto:
>> I've got an update that I don't see pushed to stable.  How do I make
>> sure that doesn't happen?
>>
>> As it's for rawhide, I didn't create the Bodhi update, and I don't see
>> an option to delete it.
>>
> There's no option to delete Bodhi updates. It can only be done by 
> hacking the database directly, but it is usually never necessary.
>
> I assume you're referring to 
> https://bodhi.fedoraproject.org/updates/FEDORA-2023-13783978e8. That 
> update will never be pushed to stable, since it is gated by failed 
> tests.

Half a dozen people can waive those tests, and there have been incorrect
waivers before. 8-/

I just want to make sure the update  doesn't proceed because I'm not
entirely confident that the fix I have is logically correct.

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

How can I delete a rawhide Bodhi update?

[Florian Weimer]

I've got an update that I don't see pushed to stable.  How do I make
sure that doesn't happen?

As it's for rawhide, I didn't create the Bodhi update, and I don't see
an option to delete it.

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: Can we assume all chroots follow UsrMove?

[Florian Weimer]

* John Reiser:

> For instance, I have a recipe for an "embedded" Docker
> that will have to add the symlink.

Interesting.  Do you have public reference for it?

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

Can we assume all chroots follow UsrMove?

[Florian Weimer]

A while back, we made /lib64 a symbolic link to /usr/lib64:

  

Is it safe to assume that this symbolic link exists in all chroots?
This includes the initial ramdisk, recovery environments, and chroots
for confining services.

If we can assume that, we can tell glibc to stop searching for shared
objects in /lib64 in addition to /usr/lib64.  It will avoid an
additional failing openat system call if the application calls dlopen
with a shared object name that the system cannot find.

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: DNF5: Checking signatures of packages installed out of a repository?

[Florian Weimer]

* Michael Catanzaro:

> On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher
>  wrote:
>> I think for the sake of security, it'd be better if this were on by
>> default, and you just had to specify the --nogpgcheck
>> For convenience, the error message should probably say "Error: GPG
>> check FAILED (try again with '--nogpgcheck' to ignore)"
>> I don't think this use case is so important that everybody's security
>> should be lowered to avoid the minor inconvenience of passing a simple
>> flag.
>
> Thing is, when manually installing RPMs that don't come from a
> repository, 98% of the time they are not expected to be signed by a
> GPG key that you have installed, so the check is expected to fail. GPG
> check is just not the right thing to do in this case. If we enable GPG
> checking when not appropriate, ***we will train users to reflexively
> ignore GPG errors.***

We already trained them to use -y, which can automatically enroll new
keys.  I'm not sure if a trust boundary is crossed in that case, but if
there isn't, why is user confirmation even needed?

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: Making -Wmissing-include-dirs an error?

[Florian Weimer]

* Neal Gompa:

> Hey all,
>
> Recently, one of the folks working on packaging stuff in Fedora KDE
> nearly missed an issue caused by GCC emitting a warning about missing
> include dirs:
>
>> cc1plus: warning: /usr/include/qt6/QtCore/6.5.3: No such file or directory 
>> [-Wmissing-include-dirs]
>> cc1plus: warning: /usr/include/qt6/QtCore/6.5.3/QtCore: No such file or 
>> directory [-Wmissing-include-dirs]
>
> I did manage to figure out this meant we needed an additional build
> dependency (qt6-qtbase-private-devel, FYI), but it made me think if
> there's a reason this shouldn't be an error.

Was there a subsequent build failure due to the missing headers?  Could
you share a link to the full build log?

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: Help running centpkg

[Florian Weimer]

* Stephen Smoogen:

> could you add how you got it and how you ran it? I am trying to figure
> out why a el8 config was pulled into a f38 system?

This does it for me:

$ mock -r c8s-x86_64 --init

Even after:

$ mock -r c8s-x86_64 --scrub all

Package versions:

mock-core-configs-39.1-1.fc38.noarch
mock-filesystem-5.2-1.fc38.noarch
mock-5.2-1.fc38.noarch

> I have cut everything but lines causing the problems 
>
>  
>  config_opts['root'] = 'c8s-x86_64'
>  config_opts['yum.conf'] = '
>  
> [main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n#
>  repos\n\n
>  
> [build]\nname=build\nbaseurl=https://kojihub.stream.centos.org/kojifiles/repos/c8s-build/latest/x86_64\nmodule_hotfixes=1\n'
>  
>  config_opts['macros']['%dist'] = 
> '%{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0,
>  do print("%{?distprefix" .. i .."}") 
> end}}.el8%{?with_bootstrap:%{__bootstrap}}'
>
> This looks like a config from either the CentOS Stream koji or for
> EPEL-next-8.

It's generated with this command and lightly edited (to keep refering to
the latest buildroot):

$ koji -p stream mock-config --target c8s-candidate --arch x86_64

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: Help running centpkg

[Florian Weimer]

* Michael Dawson:

> I'm trying to build https://gitlab.com/redhat/centos-stream/rpms/nodejs using 
> centpkg but am running into errors.
>
> I'm using Fedora 37 and get this error when I run centpkg mockbuild 
> --with=bundled in the directory where I've cloned the 
> https://gitlab.com/redhat/centos-stream/rpms/nodejs respository and switched 
> to the stream-nodejs-18-rhel-8.10.0 branch.
>
> I'm getting this error:
>
> Total 
>3.7 MB/s |  50 MB 00:13 
> Running transaction check
> Transaction check succeeded.
> Running transaction test
> Error: Transaction test error:
>   file /usr/sbin/alternatives from install of chkconfig-1.19.2-1.el8.x86_64 
> conflicts with file from package alternatives-1.24-1.fc38.x86_64

I get a similar error when using a custom configuration generated by
various EL Koji instances, only for EL8.  The error occurs after this
one:

[…]
| INFO: Package manager dnf detected and used (fallback)
| INFO: Bootstrap image not marked ready
| Start(bootstrap): installing dnf tooling
| No matches found for the following disable plugin patterns: local, spacewalk, 
versionlock
| Last metadata expiration check: 0:00:11 ago on Mon Oct  9 10:53:57 2023.
| Package python3-dnf-4.17.0-6.fc38.noarch is already installed.
| Dependencies resolved.
| 
|  Problem: problem with installed package dnf-4.17.0-6.fc38.noarch
|   - package dnf-4.7.0-13.el8.noarch from build requires python3-dnf = 
4.7.0-13.el8, but none of the providers can be installed
|   - package dnf-4.7.0-14.el8.noarch from build requires python3-dnf = 
4.7.0-14.el8, but none of the providers can be installed
[…]

This suggests that mock has copied the DNF configuration for EL8 into
the bootstrap image, which is of course not likely to work.

The mock configuration is not very remarkable as far as I can tell:

config_opts['basedir'] = '/var/lib/mock'
config_opts['chroot_setup_cmd'] = 'groupinstall build'
config_opts['chroothome'] = '/builddir'
config_opts['dnf_warning'] = False
config_opts['package_manager'] = 'dnf'
config_opts['root'] = 'c8s-x86_64'
config_opts['rpmbuild_networking'] = False
config_opts['rpmbuild_timeout'] = 86400
config_opts['target_arch'] = 'x86_64'
config_opts['use_host_resolv'] = False
config_opts['yum.conf'] = 
'[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n#
 
repos\n\n[build]\nname=build\nbaseurl=https://kojihub.stream.centos.org/kojifiles/repos/c8s-build/latest/x86_64\nmodule_hotfixes=1\n'

config_opts['plugin_conf']['ccache_enable'] = False
config_opts['plugin_conf']['root_cache_enable'] = False
config_opts['plugin_conf']['yum_cache_enable'] = False

config_opts['macros']['%_host'] = 'x86_64-koji-linux-gnu'
config_opts['macros']['%_host_cpu'] = 'x86_64'
config_opts['macros']['%_rpmfilename'] = 
'%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm'
config_opts['macros']['%_topdir'] = '/builddir/build'
config_opts['macros']['%dist'] = 
'%{!?distprefix0:%{?distprefix}}%{expand:%{lua:for i=0, do 
print("%{?distprefix" .. i .."}") end}}.el8%{?with_bootstrap:%{__bootstrap}}'
config_opts['macros']['%distribution'] = 'Koji Testing'
config_opts['macros']['%packager'] = 'Koji'
config_opts['macros']['%vendor'] = 'Koji'


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

-fstack-clash-protection needs to be disabled on riscv64 (#2242327)

[Florian Weimer]

I had to revert part of this commit:

commit 0676a754f0508957f289eac5eda01091778cebc2
Author: David Abdurachmanov 
Date:   Wed Jul 10 16:21:32 2019 +0300

rpmrc: update optflags for riscv64

Match other architectures by adding missing flags:

-fasynchronous-unwind-tables -fstack-clash-protection

This is already in Fedora/RISCV for 1+ year.

Signed-off-by: David Abdurachmanov 

because GCC generates bad code with -fstack-clash-protection that breaks
signal handling.  There's no target backend support for the option, so
-fstack-clash-protection really can't be used at present.  Jeff Law as
the original upstream author of -fstack-clash-protection concurs.

There's some disassembly in the bug in case you are interested:

  redhat-rpm-config: Disable -fstack-clash-protection on riscv64
  

We'll bring this back to f38 at least.  Do we need f37 as well?

I do not know if this is sufficient to get decent valgrind support on
riscv64.  I strongly suggest to keep riscv64 out of %valgrind_arches at
least until riscv64 support has been merged upstream.

(Note that this message is an exception, riscv64 is still not covered by
the tools team.)

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: spec file with aarch64 specific Fortran build flags

[Florian Weimer]

* Tulio Magno Quites Machado Filho:

> Have you already reported this issue upstream?

To close the loop here, Sébastien has reported this as:

  -fstack-protector-strong FLAG causes compiler error on aarch64
  

I find the upstream decision not to backport this a bit questionable.
Can't this happen for valid code on logically unreachable code paths?

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: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide

[Florian Weimer]

* Stephen Gallagher:

> On Wed, Sep 27, 2023 at 12:59 PM Ron Olson  wrote:
>>
>> I mean this sincerely: Where is the excellent documentation? I admit that 
>> I’ve been frustrated that web searches leads me all over the place, 
>> sometimes the documentation is obsolete, or it’s someone’s blog post, etc. 
>> I’ve been surprised again and again there’s a macro for this or that which 
>> could have made the job much easier, but I had no idea until I asked here or 
>> in IRC.
>>
>
> The documentation he's referring to is the
> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md
>
> Indeed, we probably should figure out a way to make that link more
> prominent on the Packaging Guidelines pages, though.

I couldn't figure out the contribution process for the documentation (it
probably has changed since), but I did file
 a while back.

Making a copy is disappointing because it will bit-rot fairly quickly.
Every Fedora release will change some build flags.  And ideally, you'd
consult the documentation for the Fedora release you are working on.
The on-the-side documentation wouldn't be versioned per Fedora release.

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: -Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide

[Florian Weimer]

* Mattia Verga via devel:

> Il 27/09/23 19:01, Stephen Gallagher ha scritto:
>> On Wed, Sep 27, 2023 at 12:59 PM Ron Olson  wrote:
>>> I mean this sincerely: Where is the excellent documentation? I admit that 
>>> I’ve been frustrated that web searches leads me all over the place, 
>>> sometimes the documentation is obsolete, or it’s someone’s blog post, etc. 
>>> I’ve been surprised again and again there’s a macro for this or that which 
>>> could have made the job much easier, but I had no idea until I asked here 
>>> or in IRC.
>>>
>> The documentation he's referring to is the
>> https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/buildflags.md
>>
>> Indeed, we probably should figure out a way to make that link more
>> prominent on the Packaging Guidelines pages, though.
>
> As I recently noticed because of a package of mine started to FTB, there 
> are no defaults for CPPFLAGS and that env variable is not set 
> automatically in each specfile section.
>
> Is because it is useless to have some defaults set? (BTW I've fixed my 
> package FTB by export CPPFLAGS = CXXFLAGS as I don't have any knowledge 
> what to set there...)

Traditionally, CPPFLAGS refer to preprocessor flags, not C++ compiler
flags.  (See the make manual, for example.)  We don't use CPPFLAGS in
our standard build environment.

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

-Werror=implicit-int -Werror=implicit-function-declaration coming to rawhide

[Florian Weimer]

redhat-rpm-config-267-1.fc40 activates the first phase of compiler flags
to avoid regressions in the Fedora C99 port.  Implicit ints and implicit
function declarations will be rejected by default.  The recommended way
to opt out is to set %build_type_safety_c to 0.  See the buildflags.md
documentation.

I tried very hard to bring the number of build failures to 0, but in the
end, every time I got close, some other package popped up that failed to
build.  So I have now made the switch in the knowledge that some
packages will still fail to build.

The discussion regarding this topic at the GNU Tools Cauldron last
weekend was quite positive, and it is likely that GCC 14 will make a
similar change by default.

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: The new Change discussion process is painful

[Florian Weimer]

* Pierre-Yves Chibon:

> On Wed, Sep 13, 2023 at 10:46:04AM +0200, Vít Ondruch wrote:
>> If nothing else, the announcements were previously send to devel-announce
>> with devel in CC, while the CC is not included anymore. IOW can we have
>> devel back in CC, please?
>
> I'm pretty sure devel is subscribed to devel-announce, so email sent to
> devel-announce will/should land on devel as well.

This doesn't work with Gmail because it will eat one of the copies.  If
you filter into different folders based on To: addresses, you get the
message only into two folders if the subscription isn't implicit, or
maybe the message to the devel list arrives before the one to
devel-announce for some reason.

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: zlib-ng as a compat replacement for zlib

[Florian Weimer]

* Richard W. M. Jones:

> I tested the speed of decompression using:
>
>   $ hyperfine 'qemu-img convert -W -m 16 -f qcow2 test.qcow2.XXX -O raw 
> test.out'
>   (qemu 8.0.0-4.fc39.x86_64)
>
>   $ hyperfine 'nbdkit -U - --filter=qcow2dec file test.qcow2.XXX --run 
> '\''nbdcopy --request-size "$uri" test.out'\'' '
>   (nbdkit-1.35.11-2.fc40.x86_64)

How realistic is that?  Larger cluster sizes will make random access
perform noticeably worse is some cases.  Think about reading a few bytes
towards the end of the cluster.  It makes a difference whether you have
to decompress 64 KiB bytes for that, or 2 MiB.  As far as I understand
it, the above commands use all data decompressed, so they don't suffer
from this issue (particularly with read-ahead to deal with unfortunate
cluster boundaries).

Time to first HTTP request served after boot or something like that
might be a better comparison.

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: zlib-ng as a compat replacement for zlib

[Florian Weimer]

* Richard W. M. Jones:

> On Thu, Aug 31, 2023 at 11:05:55AM +0200, Kevin Wolf wrote:
>> Unfortunately, we seem to build the RHEL packages with --disable-zstd
>> (I suppose just because we tend to disable everything nobody explicitly
>> asked for). Maybe we should check other distros. If zstd is commonly
>> enabled, we could still make it the default upstream (because honestly,
>> it probably does makes sense from an upstream perspective). Of course,
>> for RHEL this would mean that images out there are likely to use zstd
>> soon, so it might need to enable zstd in newer versions, too.
>
> Oh that is bad actually.  We really should enable zstd support in RHEL :-/

The zstd package was added to RHEL 8 only after its release, so it's not
that you had much choice initially.

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: AVX extensions not detected properly on a Zen 2 CPU?

[Florian Weimer]

* Przemek Klosowski via devel:

> Nevermind, my mistake---I have
> dl_hwcap2=0x0

I think you mean dl_hwcaps_subdirs_active=0x4.  That's actually the
relevant line.

The dl_hwcap2 difference is about FSGSBASE support, which requires
kernel enablement, but doesn't have an XCR0 bit, so support information
is carried in the (software-only) auxiliary vector.

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: AVX extensions not detected properly on a Zen 2 CPU?

[Florian Weimer]

* Julian Sikorski:

> Am 28.08.23 um 14:39 schrieb Florian Weimer:
>> * Julian Sikorski:
>> 
>>> I have noticed the following message in my kernel log today after I
>>> attempted to decrypt my veracrypt external hard drive:
>>>
>>> [20542.328594] AVX2 instructions are not detected.
>>> [20542.382731] AVX or AES-NI instructions are not detected.
>>> [20542.404097] AVX or AES-NI instructions are not detected.
>>> [20542.560078] AVX2 instructions are not detected.
>>>
>>> My CPU (AMD Ryzen 5 4500U) supports aes, avx and avx2 according to
>>> /proc/cpuid. Is this a bug?
>> What does ld.so --list-diagnostics show?  Is this a virtual machine?
>
> It is not a VM, bare metal Fedora 38 install. It is a ZenBook UM425IA
> laptop.
>
> $ ld.so --list-diagnostics
> dl_dst_lib="lib64"
> dl_hwcap=0x2
> dl_hwcap_important=0x6
> dl_hwcap2=0x2
> dl_hwcaps_subdirs="x86-64-v4:x86-64-v3:x86-64-v2"
> dl_hwcaps_subdirs_active=0x6

That indicates that userspace has access to AVX2 CPU capabilities.
So this must some kernel thing.  Sorry, no idea what is going on.

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