Re: [oss-security] The GNU C Library security advisories update for 2024-04-17: GLIBC-SA-2024-0004/CVE-2024-2961: ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence

* Adhemerval Zanella Netto: > The following security advisories have been published: > > GLIBC-SA-2024-0004: > === > ISO-2022-CN-EXT: fix out-of-bound writes when writing escape sequence For those who haven't prepared/shipped updates yet: we've got a fix for a stack-based buffer

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

Re: Updated Sourceware infrastructure plans

* Jason Merrill: > On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote: > > > "Frank" == Frank Ch Eigler writes: > > >> [...] I suggest that a basic principle for such a system is that it > >> should be *easy* to obtain and maintain a local copy of the history > >> of all pull requests.

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

Re: [PATCH 1/1] Replace macro "ARCH_HAVE_EXTRA_ELF_NOTES" with kconfig

* Vignesh Balasubramanian: > diff --git a/include/linux/elf.h b/include/linux/elf.h > index c9a46c4e183b..5c402788da19 100644 > --- a/include/linux/elf.h > +++ b/include/linux/elf.h > @@ -65,7 +65,7 @@ extern Elf64_Dyn _DYNAMIC []; > struct file; > struct coredump_params; > > -#ifndef

Re: memcpy is leaking secret data through ZMM vector registers

* Mikulas Patocka: > On Fri, 19 Apr 2024, Zack Weinberg wrote: > >> On Fri, Apr 19, 2024, at 4:15 PM, Mikulas Patocka wrote: >> > On Fri, 19 Apr 2024, Zack Weinberg wrote: >> >> ... the copy >> >> of round_keys in the vector registers *won't* get erased -- the exact >> >> problem being discussed

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

[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp

https://bugs.kde.org/show_bug.cgi?id=485487 --- Comment #8 from Florian Weimer --- The ELN glibc scratch build succeeded: https://src.fedoraproject.org/rpms/glibc/pull-request/92#comment-194579 There's a TMT failure, but it's unrelated (potential kernel robust mutex issue). This test does

[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp

https://bugs.kde.org/show_bug.cgi?id=485487 --- Comment #4 from Florian Weimer --- Based on a further suggestion from H.J., I put the strcmp implementation posted here into glibc and ran its strcmp test suite against it. It passes. For such a simple implementation it should have really good

[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp

https://bugs.kde.org/show_bug.cgi?id=485487 --- Comment #3 from Florian Weimer --- H.J. suggests to use the implementation from <https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/i386/i686/strcmp.S;h=e71d97f2a63a2d3c31e4c1be395c1a1f5e0200ff;hb=HEAD> (adapted for x86-64). I can

[valgrind] [Bug 485487] glibc built with -march=x86-64-v3 does not work due to ld.so strcmp

https://bugs.kde.org/show_bug.cgi?id=485487 Florian Weimer changed: What|Removed |Added CC||fwei...@redhat.com --- Comment #2 from

[valgrind] [Bug 485487] New: glibc built with -march=x86-64-v3 does not work due to ld.so strcmp

https://bugs.kde.org/show_bug.cgi?id=485487 Bug ID: 485487 Summary: glibc built with -march=x86-64-v3 does not work due to ld.so strcmp Classification: Developer tools Product: valgrind Version: 3.23 GIT Platform:

Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE

* Sergey Bugaev: > We could define EXEC_PAGESIZE to some conservative value on > aarch64-gnu too, if it turns out that this little workaround is really > required. But it seems cleaner to make sure we don't need to, as > Roland's email suggests, and introducing a new port that doesn't have > a

Re: [RFC] Linux system call builtins

* Alexander Monakov: > On Mon, 8 Apr 2024, Florian Weimer via Gcc wrote: > >> * Matheus Afonso Martins Moreira via Gcc: >> >> > + It's stable >> > >> > This is one of the things which makes Linux unique >> > in the ope

Re: [RFC] Linux system call builtins

* Matheus Afonso Martins Moreira via Gcc: > + It's stable > > This is one of the things which makes Linux unique > in the operating system landscape: applications > can target the kernel directly. Unlike in virtually > every other operating system out there, the

Re: Sourceware mitigating and preventing the next xz-backdoor

* Guinevere Larsen via Overseers: > Beyond that, we (GDB) are already experimenting with approved-by, and > I think glibc was doing the same. The glibc project uses Reviewed-by:, but it's completely unrelated to this. Everyone still pushes their own patches, and there are no technical

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: [PATCH] libquadmath: printf: fix misaligned access on args

* Simon Chopin: > On x86, this compiles into movdqa which segfaults on unaligned access. > > This kind of failure has been seen when running against glibc 2.39, > which incidentally changed the printf implementation to move away from > alloca() for this data to instead append it at the end of an

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

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

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

Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE

* Florian Weimer: > * Sergey Bugaev: > >> diff --git a/elf/dl-support.c b/elf/dl-support.c >> index 2f502c8b..6375dc95 100644 >> --- a/elf/dl-support.c >> +++ b/elf/dl-support.c >> @@ -135,7 +135,11 @@ void *_dl_random; >> #include >> #inclu

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)$', { > '*': [ >

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

[valgrind] [Bug 484002] Add suppression for invalid read in glibc's __wcpncpy_avx2() via wcsxfrm()

https://bugs.kde.org/show_bug.cgi?id=484002 Florian Weimer changed: What|Removed |Added CC||fwei...@redhat.com -- You are receiving

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 the fir

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

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,

Re: Builtin for consulting value analysis (better ffs() code gen)

* Andrew Cooper via Gcc: > Anyway - is there a way of doing this that I've managed to overlook? Use __builtin_ffs? I think there's some concern for GCC that some of the alternative x86-64 implementations do not follow the AMD and Intel behavior. Thanks, Florian

[Fedora-legal-list] Re: AI/ML Model and Pre-Trained Weight Packaging in Fedora

* Tim Flink: > 4. Is it acceptable to package code which downloads pre-trained weights from > a non-Fedora source upon first use post-installation by a user if that model > and its associated weights are >a. For a specific model? >b. For a user-defined model which may or may not exist

Re: [RFC PATCH 03/23] Allow glibc to be compiled without EXEC_PAGESIZE

* Sergey Bugaev: > diff --git a/elf/dl-support.c b/elf/dl-support.c > index 2f502c8b..6375dc95 100644 > --- a/elf/dl-support.c > +++ b/elf/dl-support.c > @@ -135,7 +135,11 @@ void *_dl_random; > #include > #include > > -size_t _dl_pagesize = EXEC_PAGESIZE; > +size_t _dl_pagesize > +#ifdef

Re: [RFC PATCH 00/23] aarch64-gnu port

* Joseph Myers: > On Wed, 3 Jan 2024, Sergey Bugaev wrote: > >> To build this, you need an aarch64-gnu toolchain (binutils, GCC, MIG), >> and GNU Mach headers for AArch64. I have posted the patches for >> binutils, GCC, and GNU Mach to the bug-hurd mailing list; no patches >> are required to

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

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

Re: [dns-operations] Destination-adjacent source address spoofed DNS queries

* John Kristoff: > This seems DNS operationally relevant and I hope no one will mind the > plug. It was fun to write up a small piece on some curious spoofed DNS > queries we observed. Something that probably would have been overlooked > otherwise. We could probably do this 24x7. :-) > >

Re: TrueType/OpenType and anti-circumvention laws

* Walter Landry: > Paul Wise writes: >> On Fri, 2024-02-02 at 20:16 -0500, P. J. McDermott wrote: >>> Ping?  Any thoughts on whether a font DRM modification tool would be >>> legal to distribute and use in Debian given that the DRM is a simple bit >>> field rather than an "effective" TPM such as

[PATCH wwwdocs COMMITTED] gcc-14: Fix unintentional error in -Wimplicit-int example

diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index bbbaa25a..901a1653 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html @@ -92,7 +92,7 @@ below). In the example below, the type of s should be write_string (fd, s) { -write (1,

[PATCH wwwdocs] gcc-14: Some very common historic Autoconf probes that no longer work

--- htdocs/gcc-14/porting_to.html | 43 +++ 1 file changed, 43 insertions(+) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index 123b5e9f..ab65c5e7 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html

[PATCH wwwdocs] gcc-14: Add code examples for -Wreturn-mismatch

--- htdocs/gcc-14/porting_to.html | 46 --- 1 file changed, 43 insertions(+), 3 deletions(-) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index bbbaa25a..123b5e9f 100644 --- a/htdocs/gcc-14/porting_to.html +++

[PATCH wwwdocs] CSS: Color markup for /

In addition to underlines and strikethroughs. This makes it easier to spot the differences in example code changes. --- htdocs/gcc.css | 4 1 file changed, 4 insertions(+) diff --git a/htdocs/gcc.css b/htdocs/gcc.css index 77d01ee0..e32c4b93 100644 --- a/htdocs/gcc.css +++

Re: New feature: -fdump-gimple-nodes (once more, with feeling)

* Andi Kleen via Gcc: >> ***This is NodeNumber0 >> (0x7f12e13b0d00) NodeNumber0 >> tree_code: function_decl >> tree_code_class: tcc_declaration > > My suggestion if you go this route would be to generate > some standard format like YAML or JSON that other tools >

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

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Gerald Pfeifer: > On Fri, 2 Feb 2024, Florian Weimer wrote: >> +Certain warnings are now errors > > That's quite a nice description, thank you, Florian! > >> +The initial ISO C standard and its 1999 revision removed support for > > May I suggest to wrap paragraphs

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Gerald Pfeifer: > On Fri, 2 Feb 2024, Florian Weimer wrote: >> htdocs/gcc-14/porting_to.html | 465 >> ++ >> 1 file changed, 465 insertions(+) >> + >> +Using pointers as integers and vice versa >> (-Werr

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Gerald Pfeifer: >> This mostly happens in function definitions >> +that are not prototypes > > Naive questions: Can definitions really be prototypes (in C)? Yes, I think so: definitions can be declarations, and function prototypes are declarations. The standard uses the phrase “function

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Sam James: > It's fine if you leave this out, but consider mentioning the common > pitfall of autoconf projects not including config.h consistently before > all inclues. We could also mention AC_USE_SYSTEM_EXTENSIONS. I added: “ Alternatively, projects using using Autoconf could enable

Re: [PATCH] Notes on the warnings-as-errors change in GCC 14

* Jonathan Wakely: >>+To fix the remaining int-conversions issues, add casts >>+to an appropriate pointer or integer type. On GNU systems, the >>+standard (but generally optional) types > > I know what you mean here, but I'm not sure the parenthesis adds > clarity for anybody who doesn't already

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

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

[PATCH] m4: Pointer types for pthread_spinlock_init, pthread_mutex_timedlock

Without this change, these probes fail unconditionally with GCC 14 because they do not use the correct argument types. --- m4/pthread-spin.m4| 2 +- m4/pthread_mutex_timedlock.m4 | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/m4/pthread-spin.m4

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

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

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

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

Re: Update on GCC 14 C type safety changes/warnings as errors

* Martin Jambor: > Given you probably have the most experience with it, can you please also > suggest an entry to https://gcc.gnu.org/gcc-14/porting_to.html that > would describe this change? (I was thinking of proposing something > myself, but I don't really know just how much verbose such an

[PATCH] Notes on the warnings-as-errors change in GCC 14

--- htdocs/gcc-14/porting_to.html | 465 ++ 1 file changed, 465 insertions(+) diff --git a/htdocs/gcc-14/porting_to.html b/htdocs/gcc-14/porting_to.html index 3e4cedc3..4c8f9c8f 100644 --- a/htdocs/gcc-14/porting_to.html +++ b/htdocs/gcc-14/porting_to.html

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't be us

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

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

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

[tboot-devel] [PATCH] Suppress GCC 14 allocation size warning in lcptools-v2/pconf_legacy.c

As far as I can tell, this warning is both technically correct and harmless. The called generate_composite_hash hash function only writes SHA1_DIGEST_SIZE bytes and uses byte accesses. Thanks, Florian diff --git a/lcptools-v2/pconf_legacy.c b/lcptools-v2/pconf_legacy.c index

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

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

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

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

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 because F

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

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

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

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

Re: Limited/Broken functionality of ASLR for Libs >= 2MB

* Matthew Wilcox: > I received a suggestion off-list that we only do the PMD alignment on > 64-bit, which seems quite reasonable to me. After all, I don't care > about performance on 32-bit just as much as I don't care about security > on 32-bit. Perhaps we can we repurpose MAP_DENYWRITE to

Bug#1061266: [PATCH] sgmls: Fix type of signal handlers for C89 compatibility

Package: linuxdoc-tools Version: 0.9.82-1 Tags: upstream patch This is another fallout from GCC 14 porting of Fedora. Without this change, the outcome of two tests are altered due to compiler errors: -#define HAVE_EXTENDED_PRINTF 1 +/* #define HAVE_EXTENDED_PRINTF 1 */ -/* #define

Re: AusweisApp2 build failed on rawhide/x86_64 (unsupported reloc 43)

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

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

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

Vala workaround for C type errors now in rawhide

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

Re: -fcf-protection dropped from i686 compiler flags

* 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

[Fedora-legal-list] Re: IBM non-free patent notice

* Richard Fontana: > I think the only complication here is that there is currently no > active contributor to glibc from IBM, This is not accurate, several people from IBM are regularly contributing to glibc. IBM is very active in the GNU toolchain in general, and I don't see this changing

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

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

-fcf-protection dropped from i686 compiler flags

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

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

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

* Mathieu Desnoyers: > On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote: >> This commit >> commit 8abddb187b33480d8827f44ec655f45734a1749d >> Author: Andrew Burgess >> Date: Sat Aug 5 14:31:06 2023 +0200 >> libgcc: support heap-based trampolines

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

* Mathieu Desnoyers: > On 2024-01-13 07:49, Florian Weimer via lttng-dev wrote: >> This commit >> commit 8abddb187b33480d8827f44ec655f45734a1749d >> Author: Andrew Burgess >> Date: Sat Aug 5 14:31:06 2023 +0200 >> libgcc: support heap-based trampolines

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

* Iain Sandoe: >> On 15 Jan 2024, at 15:35, Florian Weimer wrote: >> >> * Carlos O'Donell: >> >>> I agree. TLS should be seen more like .bss/.data rather than something >>> that is allocated with malloc(). >> >> There wasn't consensus

Re: New TLS usage in libgcc_s.so.1, compatibility impact

* Iain Sandoe: >> On 15 Jan 2024, at 15:35, Florian Weimer wrote: >> >> * Carlos O'Donell: >> >>> I agree. TLS should be seen more like .bss/.data rather than something >>> that is allocated with malloc(). >> >> There wasn't consensus

Re: New TLS usage in libgcc_s.so.1, compatibility impact

* Carlos O'Donell: > I agree. TLS should be seen more like .bss/.data rather than something > that is allocated with malloc(). There wasn't consensus regarding this in 2014. See below. > If we leak memory via TLS that is a glibc bug that we can deal with, This is something that libgcc_s.so.1

Re: [lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

* Carlos O'Donell: > I agree. TLS should be seen more like .bss/.data rather than something > that is allocated with malloc(). There wasn't consensus regarding this in 2014. See below. > If we leak memory via TLS that is a glibc bug that we can deal with, This is something that libgcc_s.so.1

redhat-rpm-config now tied to Changes/GNUToolchainF40

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,

New TLS usage in libgcc_s.so.1, compatibility impact

This commit commit 8abddb187b33480d8827f44ec655f45734a1749d Author: Andrew Burgess Date: Sat Aug 5 14:31:06 2023 +0200 libgcc: support heap-based trampolines Add support for heap-based trampolines on x86_64-linux, aarch64-linux, and x86_64-darwin. Implement the

[lttng-dev] New TLS usage in libgcc_s.so.1, compatibility impact

This commit commit 8abddb187b33480d8827f44ec655f45734a1749d Author: Andrew Burgess Date: Sat Aug 5 14:31:06 2023 +0200 libgcc: support heap-based trampolines Add support for heap-based trampolines on x86_64-linux, aarch64-linux, and x86_64-darwin. Implement the

Re: The default java.library.path on Linux does not include the library paths in the mulitarch-spec

* Glavo: > I wish OpenJDK would parse the /etc/ld.so.conf to get the full library > path list so it would be consistent with the behavior of ld. Can > anyone consider this suggestion? Parsing /etc/ld.so.conf is the wrong approach. Even glibc itself does not look at that file at run time, it's

Integrated: 8323078: Incorrect length argument to g_utf8_strlen in pango.c

On Fri, 5 Jan 2024 17:52:03 GMT, Florian Weimer wrote: > 8323078: Incorrect length argument to g_utf8_strlen in pango.c This pull request has now been integrated. Changeset: 366b062c Author: Florian Weimer Committer: Kevin Rushforth URL: https://git.openjdk.org/jfx/com

  1   2   3   4   5   6   7   8   9   10   >