is gone from rawhide

With the update to glibc-2.41.9000-11.fc43, is no longer there, and some historic terminal-related baggage is no longer included in . These terminal interfaces were alread obsolete when Linux was first released, so glibc upstream did not issue a formal deprecation issue. If something includes ,

Re: F43 Change Proposal RPM 6.0 (system-wide)

> * The most noticeable change is that RPM now refuses to install > packages whose signature hasn't been positively verified, whether due > to being unsigned, missing key or otherwise. This can be worked around > by supplying `--nosignature` on the command line, or more permanently, > changing the

Re: How to do structure initialization with gcc 15

* Orion Poplawski: > https://www.x.org/releases/X11R7.7/doc/libXt/intrinsics.html > > Describes: > > typedef struct _XtActionsRec { > String string; > XtActionProc proc; > } XtActionsRec, *XtActionList; > > being initialized with: > > > XtActionsRec actionTable[] = { > {"Set", Set}, > {"Unset", Un

Re: retiring basesystem package

* Zbigniew Jędrzejewski-Szmek: > Indeed. Apparently I was too hasty with the retirement. The package is > being unretired, so this be resolved soon. Do we need to add back the glibc dependency? Thanks, Florian -- ___ devel mailing list -- devel@lists

Re: retiring basesystem package

* Zbigniew Jędrzejewski-Szmek: > On Fri, Feb 07, 2025 at 03:53:04PM +0100, Florian Weimer wrote: >> glibc depends on basesystem: >> >> Requires(pre): basesystem >> Requires: basesystem >> >> So the buildroot is currently broken. > > It shouldn'

Re: retiring basesystem package

* Florian Weimer: > * Zbigniew Jędrzejewski-Szmek: > >> On Thu, Feb 06, 2025 at 01:49:57PM +0100, Ondrej Vasik wrote: >>> Hi Zbigniew, >>> yes, basesystem is there just to ensure installation order and it could >>> probably be achieved by that PR. >>&g

Re: retiring basesystem package

* Zbigniew Jędrzejewski-Szmek: > On Thu, Feb 06, 2025 at 01:49:57PM +0100, Ondrej Vasik wrote: >> Hi Zbigniew, >> yes, basesystem is there just to ensure installation order and it could >> probably be achieved by that PR. >> There is one more benefit from the retirement - as there are >> occasiona

Re: glibc issues: undefined symbol: _ZGVbN4v_cosf

* Iñaki Ucar: > Are there any issues with glibc in rawhide? I see build failures with > this error message in x86_64 and aarch64. See > https://koji.fedoraproject.org/koji/taskinfo?taskID=128414652 I'm looking into it. It now reproduces on rawhide as well, not just ELN. Thanks, Florian -- ___

Re: perl XS failures with GCC 15

* Jakub Jelinek: > On Wed, Jan 22, 2025 at 04:57:40PM -0700, Jerry James wrote: >> On Wed, Jan 22, 2025 at 4:43 PM Chuck Anderson wrote: >> > It looks like most (all?) perl XS packages ('C' implementations of Perl >> > functions) are FTBFS with GCC 15. I'm trying to fix >> > perl-Term-ReadLine

Re: Proposal for vendoring/bundling golang packages by default

* Gerd Hoffmann: >> We would also need to consider what our committement is to security >> updates when apps are bundling stuff, as the same reasons that make >> unbundling huard, also make fixing security issues hard. > > Note that in the go/rust world the unbundling does *not* make security > up

Re: Proposal for vendoring/bundling golang packages by default

* Mikel Olasagasti: > Go-SIG has raised a ticket with FESCo [1] to propose a significant > shift in Fedora's packaging approach for Go dependencies: moving to > vendoring/bundling by default. This would represent a major departure > from our current guidelines [2]. > [1] https://pagure.io/fesco/i

Re: FTB due to 'too many arguments to function'

* Artur Frenszek-Iwicki: >> indi-3rdparty-drivers: >> error: expected ‘;’, identifier or ‘(’ before ‘bool’ >> Looks like the syntax 'typedef enum { FALSE, TRUE } bool;' is no more >> accepted, but searching in the net it was perfectly fine. > > Looking at the build logs, it seems that while a sta

Re: GCC 15 for Fedora 42 in a side-tag

* Iñaki Ucar: > On Wed, 15 Jan 2025 at 19:40, Florian Weimer wrote: > >> * Iñaki Ucar: >> >>>> Add -std=gnu17 to CFLAGS of whatever packages you want to use it as >>>> workaround (but don't forget to look at it back before Fedora 42 is >>>

Re: GCC 15 for Fedora 42 in a side-tag

* Iñaki Ucar: >> Add -std=gnu17 to CFLAGS of whatever packages you want to use it as >> workaround (but don't forget to look at it back before Fedora 42 is >> released). > > I was actually planning to keep it until the next R release, which is > in April. Would that be a problem? Would this flag

Re: bin-sbin merge rebuild

* Zbigniew Jędrzejewski-Szmek: > On Fri, Jan 10, 2025 at 10:13:31AM +, Zbigniew Jędrzejewski-Szmek wrote: >> On Fri, Jan 10, 2025 at 08:58:32AM +0100, Florian Weimer wrote: >> > * Zbigniew Jędrzejewski-Szmek: >> > >> > > glibc >> > >>

Re: bin-sbin merge rebuild

* Zbigniew Jędrzejewski-Szmek: > glibc If we rebuild glibc, should we do a second rebuild into your side tag? Thanks, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.o

Re: Non-responsive maintainer ngompa

* Richard W. M. Jones: > That could easily because Pagure doesn't reliably send emails out (or > it could be that these emails are sent, but then spam filtered, I'm > not ruling out gmail).. I've missed many PRs because of this. > > I have to ask people to ping me via side channels if a PR is > i

Chromium developer contacts

Do we have contacts among the Chromium developers? I would appreciate if someone could give this thread a nudge and bring it to the attention of the right people. Reducing dependencies on glibc internals in sandbox/linux/services/namespace_sandbox.cc, ForkWithFlags

Re: On revoking provenpackager

* Adam Williamson: > Fedora is open by default. Everything is supposed to happen in the open > unless there is a specific reason for it to be done otherwise. This is > why we have ticket trackers for everything, public meetings, public > chat rooms, public forums, public package repos, a public bu

Re: rpminspect failing with coredump

* David Cantrell: > On 12/15/24 01:32, Florian Weimer wrote: >> I'm getting this output: >> >> Cloning https://src.fedoraproject.org/rpms/glibc.git (branch: f41)... >> No rpminspect.yaml in the repository... >> No rpminspect.json in the repository... &

rpminspect failing with coredump

I'm getting this output: Cloning https://src.fedoraproject.org/rpms/glibc.git (branch: f41)... No rpminspect.yaml in the repository... No rpminspect.json in the repository... No rpminspect.dson in the repository... Segmentation fault (core dumped) running in TMT, wrote /var/ARTIFACTS/work-rpminsp

Re: EDQUOT lurks in most apps

* John Reiser: > The C runtime library (package glibc) implementation of exit() > could help by calling close_range() of low-numbered output > [not input!] file descriptors, especially stdout, and checking > for errors. ENOSPC also has this problem. We would have to fsync (after the implicit ffl

Re: Proposed qemu-srpm-macros

* Daniel P. Berrangé: > On Fri, Nov 29, 2024 at 03:48:02PM +, Richard W.M. Jones wrote: >> On Fri, Nov 29, 2024 at 04:36:14PM +0100, Florian Weimer wrote: >> > * Daniel P. Berrangé: >> > >> > > I think I'd prefer to stay away from redhat-rpm-c

Re: Proposed qemu-srpm-macros

* Daniel P. Berrangé: > I think I'd prefer to stay away from redhat-rpm-config. Not because it > is a problem in Fedora, but because it will cause us pain downstream > to deal with RHEL development process bureaucracy to commit changes > into a package we don't directly own as virt maintainers. H

Re: Proposed qemu-srpm-macros

* Richard W. M. Jones: > One question is whether it's better to add this as a sub-package of > qemu, or as a new source package. Using a new source package means we > won't be introducing awkward circular build dependencies, or a > heavyweight build dependency on qemu for non-virt packages. The

Re: find-debuginfo failing with objcopy Permission denied error

* Richard W. M. Jones: > This is a weird one: > > https://koji.fedoraproject.org/koji/taskinfo?taskID=125988419 > > + /usr/bin/find-debuginfo -j48 --strict-build-id -m -i --build-id-seed > 1.55.2-1.fc42 --unique-debug-suffix -1.55.2-1.fc42.x86_64 > --unique-debug-src-base libguestfs-1.55.2-1.fc4

Re: Schedule for Tuesday's FESCo Meeting (2024-11-19)

* Josh Boyer: >> * TOPIC: Next Week's Chair (@sgallagh:fedora.im, 17:34:58) >> * INFO: 2024-11-26 meeting is CANCELED due to lack of expected >> quorum (@sgallagh:fedora.im, 17:39:34) >> * INFO: F42/F43 Election questions will be reviewed and approved >> async using the FastTrack process (

Obtaining the RPM_ARCH etc. environment variables

Is eval `rpm --eval %___build_pre_env` the canonical way to obtain definitions of these environment variables, or is there a better alternative? Thanks, Florian -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email

Re: Thunderbird FTBFS on ppc64le

* Florian Weimer: > * Eike Rathke: > >> Hi, >> >> In the last weeks, Thunderbird updates evolved a behaviour that they >> FTBFS on ppc64le. >> >> It first started with v128.3.2 on 2024-10-17 on f42, >> https://koji.fedoraproject.org/koji/taskin

Re: Thunderbird FTBFS on ppc64le

* Eike Rathke: > Hi, > > In the last weeks, Thunderbird updates evolved a behaviour that they > FTBFS on ppc64le. > > It first started with v128.3.2 on 2024-10-17 on f42, > https://koji.fedoraproject.org/koji/taskinfo?taskID=124917502 > unhelpfully with > https://koji.fedoraproject.org/koji/taskin

Re: Tcl/Tk 9.0.0 rebase

* Garry T. Williams: > On Saturday, 2 November 2024 23:24:50 EDT Garry T. Williams wrote: >> I am trying to port deal to tcl 9.0.0 and I am stuck. >> >> My package required many changes mostly changing certain int variables >> to type Tcl_Size (aka long). I got down to only one error compiling >

Re: What is the status of i686 in Fedora?

* Stephen Gallagher: > We still have i686 in Fedora for multilib use-cases. There's no > expectation for i686 to be an install target, so maybe it would be > acceptable to only build the docs on %java_arches and just exclude > them on i686? Koji broadcasts noarch packages built on a subset of arc

Re: Slower builds on non-x86_64 arches - number of cores?

* Kevin Fenzi: > On Mon, Oct 28, 2024 at 05:49:56PM +0100, Florian Weimer wrote: >> * Kevin Fenzi: >> >> > On Mon, Oct 28, 2024 at 09:07:59AM +0100, Florian Weimer wrote: >> >> * Kevin Fenzi: >> >> >> >> > As a side note, I remo

Re: Slower builds on non-x86_64 arches - number of cores?

* Kevin Fenzi: > On Mon, Oct 28, 2024 at 09:07:59AM +0100, Florian Weimer wrote: >> * Kevin Fenzi: >> >> > As a side note, I removed s309x from the noarch_arches when that was >> > going on, but I have readded it a while back. (So noarch builds could >> &g

Gating failure: Guest couldn't be provisioned: Artemis resource ended in 'error' state

We're getting a test failure on a glibc rawhide update with this error message: [2024-10-28 13:59:52] [+] [worker_0] [artemis] [047a0fb2-c07a-486e-b097-cd0483c1447a] guest event log: https://artifacts.dev.testing-farm.io/2bde30f4-6c08-4f8d-8272-59b4bb061333/work-ciltnyfm1l/047a0fb2-c07a-486e-b09

glibc Features/UsrMove transition

We received a downstream report that our glibc debuginfo is broken because we never implemented Features/UsrMove: Move all to /usr So far, we relied on the symbolic links in the filesystem package to to produce the correct paths upon installat

Re: Slower builds on non-x86_64 arches - number of cores?

* Kevin Fenzi: > As a side note, I removed s309x from the noarch_arches when that was > going on, but I have readded it a while back. (So noarch builds could > also happen on s390x). Also, changes in koji 1.35 meant that srpm build > tasks just use noarch_arches, so they too can happen on s390x. I

Re: Using /usr/etc/services as a fallback for /etc/services (and other NSS files)

* Colin Walters: > On Fri, Sep 27, 2024, at 11:31 AM, Florian Weimer wrote: >> Do you see any problems if glibc starts using /usr/etc/services if >> /etc/services does not exist? > > Please avoid having projects unconditionally read `/usr/etc` > because on ostree based sy

Using /usr/etc/services as a fallback for /etc/services (and other NSS files)

Do you see any problems if glibc starts using /usr/etc/services if /etc/services does not exist? Same for /usr/etc/protocols, /usr/etc/rpc and so on. It's already used on openSUSE, apparently. And alternative proposal was to use /usr/share/services (which I really dislike), or /usr/share/nss/ser

Re: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

* Peter Pentchev: > On Thu, Aug 22, 2024 at 05:06:53PM +0200, Florian Weimer wrote: >> * Lennart Poettering: >> > You don't really have to live with such a limitation. In systemd we >> > have code that works around this limitation via O_PATH. i.e. when >> &g

Re: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

* Lennart Poettering: > On Mi, 07.08.24 13:09, Vít Ondruch (vondr...@redhat.com) wrote: > >> With new RPM, I hit the limit in two packages: >> >> https://koschei.fedoraproject.org/package/rubygem-abrt >> >> https://koschei.fedoraproject.org/package/rubygem-pg >> >> >> I have read: >> >> https://un

Re: Is it possible for Copr to use Bodhi build overrides?

* Peter Lemenkov: > Hello All! > I have a few Bodhi build overrides and I love to use them in Copr. Is > it possible? At least is it possible to enable updates-testing > repository? You can request a side tag and reference its repository in the Copr configuration. The repositories have URLs like

Re: collect2: fatal error: cannot find ‘ld’

* Sérgio Basto: > BTW and regarding this topic, should we start avoid build with golden > linker ? i.e for example, qt5-qtwebengine [2] should we add > BuildRequires: binutils-gold or should we try built with other linker > (ldd IIRC) ?  I suggest building with BFD ld first (the defaul

Re: bin-sbin merge planned for next week

* Zbigniew Jędrzejewski-Szmek: > What will happen next week: > > 0. I'll create a side tag for the builds described below. Where are we in this process? Has the side tag been created? Do builds for testing already exist? Thanks, Florian -- ___ deve

Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

* Miroslav Suchý: > Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a): >> >> Could you make the comment something like this? >> >>   # Automatically converted from old format: GPLv2 >>   # TODO check if there are other licenses to be listed >>   License: GPL-2.0-only > > We (the Change owners) di

Re: F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)

* Vitaly Zaitsev via devel: > On 19/06/2024 19:45, Jonathan Steffan wrote: >> While it does *feel* better, both options effectively remove any UEFI >> Secure boot protections. > > Another option is to package the nvidia-kmod-open module into Fedora > and sign it with Fedora key. > > Starting with

Re: Guidance on individual packages requiring x86_64-v2 baseline ?

* Daniel P. Berrangé: > On Wed, Jun 12, 2024 at 09:59:25AM -0400, Stephen Gallagher wrote: >> OK, that's a situation that will lead to annoying and unresolvable bug >> reports. Would it be possible to put something in place that would >> check processor capabilities early in execution before hitti

DT_RELR enabled in rawhide for aarch64 as well

Rawhide binutils recently gained DT_RELR (packed relative relocation) support on aarch64 as well, so redhat-rpm-config-293-1.fc41 enables it there as well. The only architecture missing is now s390x. I built a few thousand packages with this change and the most recent binutils, and did not see an

Re: RPM_* env variables vs macros

* Vít Ondruch: > Dne 04. 06. 24 v 8:11 Panu Matilainen napsal(a): >> On 6/3/24 17:18, Eike Rathke wrote: >>> Hi Panu, >>> >>> On Monday, 2024-06-03 15:55:09 +0300, Panu Matilainen wrote: >>> or better yet, ${RPM_BUILD_ROOT}. >>> >>> Why better? >> >> In general, the RPM_* environment variable

BuildRequires: glibc-utils now required for libc_malloc_debug.so.0

For various reasons (mostly: people don't like debugging tools in production), it's now necessary to add BuildRequires: glibc-utils to RPM spec files if you use LD_PRELOAD=libc_malloc_debug.so.0 in package test suites during the build (we already discourage linking against libc_malloc_debug.so.0)

Re: Spec file using github repo - not tarball

* Kenneth Goldman: > Is it possible for a .spec file to clone a github.com repo rather than > download a tarball? Can someone link to a working example? There is Packit, which I think can be configured in such a way that you can work with sources directly. The service pushes auto-generated com

Re: OCaml flambda optimizations causing a compilation slow down

* Richard W. M. Jones: > On Mon, May 06, 2024 at 10:16:45AM +0200, Florian Weimer wrote: >> * Richard W. M. Jones: >> >> > This email is mostly to notify that this is happening. I'm not sure >> > if a single package slowing down compilation means we need t

Re: OCaml flambda optimizations causing a compilation slow down

* Richard W. M. Jones: > This email is mostly to notify that this is happening. I'm not sure > if a single package slowing down compilation means we need to do > anything here, but if anyone else sees similar symptoms, let us know. What blocks you from profiling it and fixing the performance iss

Is glibc32 retired?

I didn't have a dist-git token for fedpkg, so retiring failed after doing some work the first time. Is the package actually retired? This command koji list-history --package=glibc32 does not show any recent activity. I would expect something to untag it from the buildroot. (Bonus question:

, glibc ABI updates coming to Fedora releases

The types defined in and contain seconds-since-epoch fields. Historically, those fields are 32 bits wide. There are two issues with that: 1. The field width incorrectly changed to 64 bits on i686 when building with _TIME_BITS == 64 (an unusual configuration for Fedora builds). This is wr

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

* Andrea Bolognani: > On Tue, Apr 30, 2024 at 08:19:41AM GMT, Richard W.M. Jones wrote: >> On Mon, Apr 29, 2024 at 02:21:56PM +0200, Florian Weimer wrote: >> > > What cases aren't covered by the symlink? We have a full, working >> > > Fedora/RISC-V distro

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

* Richard W. M. Jones: > On Mon, Apr 29, 2024 at 02:21:56PM +0200, Florian Weimer wrote: >> * Richard W. M. Jones: >> >> >> I don't want us to have RPM spec file hacks just to get RISC-V to >> >> install in the correct locations. The symbolic l

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

29, 2024 at 08:22 Florian Weimer wrote: > > * Richard W. M. Jones: > > >> 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. > > &

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

* Richard W. M. Jones: >> 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. > > What cases aren't covered by the symlink? We have a full, working > Fedora/RISC-V distro using it at the m

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

* 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" > architectu

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

* 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

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

* 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 t

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

* 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/lp6

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

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 poss

Re: Three steps we could take to make supply chain attacks a bit harder

* 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, upstream

Re: Three steps we could take to make supply chain attacks a bit harder

* 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. >>

Re: Three steps we could take to make supply chain attacks a bit harder

* 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 t

Re: Three steps we could take to make supply chain attacks a bit harder

* 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

Re: Three steps we could take to make supply chain attacks a bit harder

* 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 detect

Re: glibc32 in rawhide is now built from glibc

* 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*d

Re: glibc32 in rawhide is now built from glibc

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

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

glibc32 in rawhide is now built from glibc

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 e

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

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, l

Re: Guiding co-dependent RPM packages to swap nicely

* 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

Re: Need help with incompatible pointer types on i686

* 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 distin

Re: Modern C failures in Haskell stack

* 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

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

* 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 Fedor

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

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 (reportin

Re: dnf-4.19.0 without filelists in Rawhide soon

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

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

* 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 li

Re: FYI: AFL++ now builds a GCC plugin

* 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 f

Re: Figure out what killed an app (rhbz#2253099)

* 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 sh

Re: Mounting USB Storage devices with "sync" option ?

* 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 logi

Re: Mounting USB Storage devices with "sync" option ?

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

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

* 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 oth

Re: "noarch sysroot subpackages" commit breaks glibc compile on riscv64

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

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

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.

Re: Mounting USB Storage devices with "sync" option ?

* 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.ru

SWIG 4.2 Python transition

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 obje

Re: Staled PRs at https://src.fedoraproject.org/rpms/

* 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&status=open > > (your account icon -> My Pull Request -> PR I can act on) > > Please check it, maybe you will discover s

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>

Re: GNOME package builds this cycle

* 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

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

Re: 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: > > <https://bugzilla.redhat.com/show_bug.cgi?id=2259845> > > I'm going to work on this with priority. > > Posting this here

Another mass rebuild blocker: glibc qsort regression

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 appr

Re: Proposal: Eliminate buildroot overrides

* 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. &g

Re: Proposal: Eliminate buildroot overrides

* 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 k

Re: Proposal: Eliminate buildroot overrides

* 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 a

Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

* 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'

  1   2   3   4   5   6   7   8   9   10   >