Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

* Kevin Fenzi: > Isn't this an ideal use case for copr? I don't know. I could piece together the Koji API fairly easily, and had hoped to reuse some of the script logic. Or does COPR have direct support this? Can I tell it directly to report rawhide in a special buildroot? Is there a programm

Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

* Kevin Kofler via devel: > Florian Weimer wrote: >> Eventually, we'll have to fix the Fedora packages if there's no upstream >> release with the fixes. > > We just have to add -Wno-error=implicit-function-declaration to the build > flags of the offending pac

Re: Long-running side tag for porting Fedora to C99 (no implicit decls)

* Neal Gompa: > Seems like a worthy effort to me. Though instead of having branches > for redhat-rpm-config, you could add macros to flag it on and off by > default, and have releng configure a side-tag for you that turns it on > for package builds (we can have macros set for build tags). Is it p

Long-running side tag for porting Fedora to C99 (no implicit decls)

I would like to create a long-running rawhide side tag for preparing Fedora for the removal of implicit function declarations from the GCC defaults. This is a change that happened in the C99 version of the language, but GCC could not adopt at the time because too much software was broken by it. E

Re: Unexpected /patches VERIFY result from rpminspect

* Aleksei Bavshin: > On 11/4/21 09:17, Florian Weimer wrote: >> Why is this VERIFY? The patch was generated as if by “git show”, and I >> do not see anything wrong with it. > > rpminspect thinks that the patch is suspiciously large and asks you to > confirm that it is in

Unexpected /patches VERIFY result from rpminspect

I've got an rpminspect failure I don't understand. Looking at https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/rpminspect-pipeline/job/master/54461/testReport/(root)/tests/_patches/ the relevant result seems to be this: |25) glibc-upstream-2.34-18.patch touches 26 files and as many

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

* Luca Boccassi: >> * Zbigniew Jędrzejewski-Szmek: >> >> >> The general case of any statically linked code. It could be libgcc, >> startup files, the non-shared bits of glibc, static-only libraries, or >> header-only C++ libraries. > This would be indeed useful, but quite harder to do automagi

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

* Steve Grubb: > Hello, > > On Wednesday, November 3, 2021 10:00:05 AM EDT David Sastre wrote: >> I assume that the people who worked on it looked into various different >> possibilities for its implementation and decide on the current one, but I >> have a few questions: >> >>- Since there ar

Re: F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)

* Zbigniew Jędrzejewski-Szmek: > I read the mythbuster page, and I still don't understand if removing > the file has any effect or not. Will there be any difference in builds > (for package builds and end-user builds)? As far as I understand it, linking with static libraries using libtool will no

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

* Zbigniew Jędrzejewski-Szmek: > On Wed, Oct 27, 2021 at 09:38:35AM +0200, Florian Weimer wrote: >> * Ben Cotton: >> >> > https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects >> > >> > == Summary == >> > All binaries (exec

Re: F36 Change: Package information on ELF objects (System-Wide Change proposal)

* Ben Cotton: > https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects > > == Summary == > All binaries (executables and shared libraries) are annotated with an > ELF note that identifies the rpm for which this file was built. This > allows binaries to be identified when they ar

Re: why is my package failing annocheck pie test?

* Matthew Miller: > It looks like %build_cflags is (literally defined as) %optflags, but I'm > missing the latter. Is this documented in the packaging guidelines? Documentation is in /usr/share/doc/redhat-rpm-config/buildflags.md. Thanks, Florian ___

Re: Fedora 💔 Java: The Death of Two SIGs

* Kevin Kofler via devel: > Florian Weimer wrote: > >> * Kevin Kofler via devel: >> >>> (And for the record, I also think that Go and Rust should not work >>> that way either! It is possible to build shared libraries of Go code, >>> at least one

Re: Fedora 💔 Java: The Death of Two SIGs

* Kevin Kofler via devel: > (And for the record, I also think that Go and Rust should not work > that way either! It is possible to build shared libraries of Go code, > at least one Go toolchain supports it.) There is no stable Go ABI. Even minor updates change ABI because type sizes and struct

Re: Fedora 💔 Java: The Death of Two SIGs

* Christopher: > My main point here was that treating the community as a single SIG > makes no more sense than treating all packages whose software is > written in C as a single "C SIG" community. It's too overwhelming for > people to be able to know how to step in and help. I'm not sure this is

Re: Fedora ? Java: The Death of Two SIGs

* Fabio Valentini: > On Mon, Sep 27, 2021 at 1:07 PM Richard W.M. Jones wrote: >> >> A question about this which is semi-related to your email. >> >> For some C library packages we have Java bindings, eg: >> https://github.com/libguestfs/libguestfs/tree/master/java >> >> These have been disabled

Re: Naming convention

* Dominik Mierzejewski: > On Thursday, 23 September 2021 at 09:52, Filip Janus wrote: >> Hi all, >> I am wondering about the right name for Autoconf compact package. I need to >> add the latest release of autoconf into EPEL so I need a package with a >> different name. Currently, there are in fedo

Re: Free Pascal and the new glibc

* Dan Horák: > Florian, can the patch go upstream as it is or are there any side > effects when the resulting binary would run on system with glibc < 2.34? ELF constructors for the main program will not run on glibc < 2.34. But I don't think there will be immediate crashes. Whether the missing E

Re: Free Pascal and the new glibc

* Dan Horák: > On Mon, 20 Sep 2021 13:36:33 - > "Artur Frenszek-Iwicki" wrote: > >> Back in July, during the F35 Mass Rebuild, the Free Pascal Compiler package >> failed to build [1] because of linking issues on aarch64, i686 and ppc64le, >> related to the new glibc 2.34. x86_64 and arm we

Re: [Heads-up] Introduction of OpenSSL 3.0.0 in F36

* Sandro Mani: > Anyone encountered this one? Google just gives a single hit for > ERR_OSSL_EVP_UNSUPPORTED, which is a rhbz bug [1]. This is kinda fatal for > nodejs/webpack development :S MD4 has been deprecated since about 1995. It should be possible to re-activate these old algorithms:

Re: Introducing ABI changes in libolm

* Vitaly Zaitsev via devel: > Hello. > > libolm 3.2.6 introduces ABI changes without a SOVERSION bump. > > Upstream's answer: > >> The purpose of bumping the SOVERSION is so that things that are >> compiled against it don't suddenly break. If we're removing things >> that nobody is using (and nobo

Re: FF builds

* Neal Gompa: > On Thu, Sep 9, 2021 at 12:55 PM Demi Marie Obenour > wrote: >> Can the Firefox build be distributed among multiple machines? >> > > We'd need icecream[1] support enabled in Koji. I am not even sure Mock > (the build engine) supports icecream right now. I think for Firefox, what's

Re: Disable locale forwarding in OpenSSH

* Iñaki Ucar: > This would work... if the target system has a properly configured > locale, which is not the case many times. E.g., [1] is still > unresolved. > > [1] https://github.com/CentOS/sig-cloud-instance-images/issues/154 Right, this looks like an inconsistent /etc/locale.conf setting. I

Disable locale forwarding in OpenSSH

There is a movement towards C.UTF-8 for small images (containers and VMs). C.UTF-8 has both size and performance improvements over the more traditional en_US.UTF-8 locale. (The performance improvement is currently in upstream glibc only, but we plan to bring it to rawhide and Fedora 35 shortly.)

Re: Wine MinGW system libraries

* Zebediah Figura: > (2) If we use dynamic libraries, should dependencies be included in > the main wine package, or packaged separately? Aren't many of them already packages separately? For example mingw32-libpng and mingw32-gnutls? Thanks, Florian _

Re: I think we should stop building i686 packages we're not shipping

* Demi Marie Obenour: > On 9/1/21 1:32 PM, Neal Gompa wrote: >> On Wed, Sep 1, 2021 at 1:24 PM Demi Marie Obenour >> wrote: >>> >>> On 9/1/21 8:15 AM, Vitaly Zaitsev via devel wrote: On 01/09/2021 10:47, Dominik 'Rathann' Mierzejewski wrote: > Also, there are tons of old closed-source i

Re: Running ldconfig after the RPM transaction

* Dan Čermák: > Hi Florian, > > Florian Weimer writes: > >> * Dan Čermák: >> >>> it has been recently proposed to switch openSUSE to run ldconfig via a >>> %transfiletriggerin/-un scriptlet instead of manually in %post & %postun >>> the sa

Re: Running ldconfig after the RPM transaction

* Daniel P. Berrangé: > It has always struck me that ldconfig's impl isn't a great match for > RPMs use case. IIUC ldconfig scans all files in all registered > library directory paths, since it doesn't know what files might have > changed since its last run (or does it check mtime at all to optimi

Re: Running ldconfig after the RPM transaction

* Richard W. M. Jones: > On Wed, Sep 01, 2021 at 11:01:01AM +0200, Florian Weimer wrote: >> There are some packages that install f[ile]s into /etc/ld.so.conf.d, and >> such packages still have to run ldconfig explicitly. (We should perhaps >> move those shared objec

Re: Running ldconfig after the RPM transaction

* Dan Čermák: > it has been recently proposed to switch openSUSE to run ldconfig via a > %transfiletriggerin/-un scriptlet instead of manually in %post & %postun > the same way as Fedora does it at the moment. > > However, an interesting issue has been raised: what happens if package A > gets upgr

Re: I think we should stop building i686 packages we're not shipping

* Justin Forbes: > On Tue, Aug 31, 2021 at 12:14 PM Florian Weimer wrote: >> >> * Matthew Miller: >> >> > This is an off-shoot thought of the 32-bit ARM conversation. Right now, we >> > build stuff like libreoffice for i686, but then (mostly) don

Re: I think we should stop building i686 packages we're not shipping

* Matthew Miller: > This is an off-shoot thought of the 32-bit ARM conversation. Right now, we > build stuff like libreoffice for i686, but then (mostly) don't ship it. > This seems like a waste of resources and time. > > I know it's somewhat complicated (for example, there's actually a library >

Re: Any recent changes to the arm builders?

* Neal Gompa: > On Fri, Aug 20, 2021 at 12:45 AM Florian Weimer wrote: >> >> * Neal Gompa: >> >> > On Thu, Aug 19, 2021 at 8:59 AM Dennis Gilmore wrote: >> >> >> >> On Wed, Aug 18, 2021 at 3:11 PM Florian Weimer wrote: >> >> &g

Re: Maintanenace of redhat-rpm-macros

* Kevin Fenzi: > I'd also be happy to help, but that said... I wonder if we couldn't ask > the FPC to take it over? Or would that be too slow/too many people to > get things done? Just thinking that they should know the pending > guidelines and what macros make sense, etc. I have been unable to

Re: Any recent changes to the arm builders?

* Neal Gompa: > On Thu, Aug 19, 2021 at 8:59 AM Dennis Gilmore wrote: >> >> On Wed, Aug 18, 2021 at 3:11 PM Florian Weimer wrote: >> > >> > * Dennis Gilmore: >> > >> > > We intentionally never looked at enabling that and always had no plans

Re: Any recent changes to the arm builders?

* Dennis Gilmore: > We intentionally never looked at enabling that and always had no plans > to support multi-lib on Arm It's not multilib. Buildroots aren't multilib. I'm pretty sure no one but Fedora is building 32-bit Arm binaries on 32-bit Arm kernels. It's very much a dead end. Debian us

Re: Any recent changes to the arm builders?

* Jeremy Linton: > Hi, > > On 8/17/21 2:06 AM, Florian Weimer wrote: >> * Jeremy Linton: >> >>> That said, there as you mention various rpm/package build/etc problems >>> caused by `uname -m` returning armv8. >> Is this something that can b

Re: Any recent changes to the arm builders?

* Colin Walters: > On Sun, Aug 15, 2021, at 6:43 PM, Demi Marie Obenour wrote: >> >> Mark kojid as non-killable by setting its OOM score to -1000? Adding >> swap might also help, but then the build is by no means guaranteed to >> finish in a reasonable amount of time. > > If Koji wasn't a cluste

Re: Any recent changes to the arm builders?

* Jeremy Linton: > That said, there as you mention various rpm/package build/etc problems > caused by `uname -m` returning armv8. Is this something that can be changed with setarch? It works on other architectures (at least on x86 and POWER). Thanks, Florian

Re: Any recent changes to the arm builders?

* Neal Gompa: > ARM is the only remaining non-embedded 32-bit architecture in common use. Where do you see 32-bit Arm being used in a non-embedded way? With “non-embedded” I mean use for general-purpose computation, where the end user installs software of their own choice, and not some fixed set

Re: Any recent changes to the arm builders?

* Kevin Fenzi: > On Sun, Aug 15, 2021 at 01:51:16PM +0200, Florian Weimer wrote: >> * Kevin Fenzi: >> >> > Yes. They were mistakenly running the normal kernel (so they had ~3GB >> > memory available). I moved them back to the lpae kernel (so they see &

Re: Any recent changes to the arm builders?

* Kevin Fenzi: > Yes. They were mistakenly running the normal kernel (so they had ~3GB > memory available). I moved them back to the lpae kernel (so they see > 40GB memory), but this causes > > https://bugzilla.redhat.com/show_bug.cgi?id=1920183 > > basically OOM kills kojid, which restarts kojid

Re: The Death of Java (packages)

* Vitaly Zaitsev via devel: > Building Java apps in your home directory with Internet access is a > trivial task. The official Fedora builds has no network access, so you > need to unbundle all dependencies into a separate packages first. This > is the main problem. In the build-on-demand Java c

Re: Free Pascal and F35 Mass Rebuild

* Mattia Verga via devel: > I've added your suggestion and a reference to this thread to the fpc > forum post. > > However, your proposed patch is not enough to fix the build failure: a > scratch build [¹] shows it will still fail with some "undefined > reference" errors. The startup code changed

Re: Rawhide CMake broken?

* Richard Shaw: > On Mon, Aug 2, 2021 at 10:42 PM Tom Stellard wrote: > > On 8/2/21 8:38 PM, Richard Shaw wrote: > > I'm trying to fix vigra to work with OpenEXR 3 via the CONFIG method. > > > > In the OpenEXR config it has a "find_dependency(Threads REQUIRED)" and > there's > no complaint

Re: Free Pascal and F35 Mass Rebuild

* Mattia Verga via devel: > So, I still haven't seen anything posted in gitlab or mailing lists, so I've > posted to the FPC forums: > https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html You left out the most useful piece of advice (the .quad 0 suggestion). Would you please add a r

Re: rawhide in mirrors.fedoraproject.org

* Carol Bouchard: > I have test scripts upstream which runs UTs and valgrind checks for rawhide. > Recently they > broke due to the following error and similar with mirrors.fedoraproject.org: > > Fedora rawhide openh264 (From Cisco) - x86_64 0.0 B/s | 0 B 00:00 - Curl > error (6): > Couldn't re

Re: should leveldb have had an soname bump, and the associated notice?

* Kaleb Keithley: > ah, I missed that. I looked, but not hard enough apparently, and I presumed > it was related > to changes in the code. > > > > but I expect upstream does not care about ABI. > > Maybe the other way would be to patch that cha

Re: should leveldb have had an soname bump, and the associated notice?

* Kaleb Keithley: > in f35 leveldb-1.22's libleveldb.so.1.22 has, among others, the following: > > # nm -D libleveldb.so.1.22 | grep Logger | grep leveldb > 000367f0 T _ZN7leveldb6LoggerD0Ev > 00036740 T _ZN7leveldb6LoggerD1Ev > 00036740 T _ZN7leveldb6LoggerD2Ev > 0

Re: IceCat build error: no matching function for call to ‘ArrayEnd(uint8_t [])’

* Antonio T.: > I need help for failed builds of IceCat bacause of this error (in > x86_64 and i386 architectures only): > > 18:10.81 > /builddir/build/BUILD/icecat-78.13.0/security/sandbox/linux/launch/SandboxLaunch.cpp:496:28: > > error: no matching function for call to ‘ArrayEnd(uint8_t [])’

Re: Rawhide CMake broken?

* Tom Stellard: > On 8/2/21 8:38 PM, Richard Shaw wrote: >> I'm trying to fix vigra to work with OpenEXR 3 via the CONFIG method. >> In the OpenEXR config it has a "find_dependency(Threads REQUIRED)" >> and there's no complaint, but then building fails[1] with no such >> library as "Threads::Threa

Re: Is OpenSSL 3.0 still planned for Fedora 35?

* Neal Gompa: > For reasons that are unclear to me, it seems that all the work for > this feature happened in CentOS Stream 9 development[1] instead of > Rawhide. OpenSSL developers were under the impression that the Alpha snapshots could not be imported into rawhide for policy reasons. And in t

Re: f35 missing header files in kernel-headers-5.14.0-0.rc3.git0.1.fc35.x86_64.rpm package

* Martin Gansser: > I need the two plugins (dvbhddevice and dvbsddevice) for my > Technotrend TV card (TT DVB-S2 6400) in order to be able to watch HDTV > or SD channels. The two plugins now need the header files audio.h > osd.h and video.h, which are missing since the kernel change to 5.14 > rc3.

Re: F35 mass rebuild is finished

* Michael Cronenworth: > This is affectting many different packages that use the %cmake3 macro > and try to enter its build directory. I traced the root of it. > > The %cmake3 macro calls the %_vpath_builddir macro to set its build directory > name. > > F35 - %_vpath_builddir: "%{_vendor}-%{_targ

Re: f35 missing header files in kernel-headers-5.14.0-0.rc3.git0.1.fc35.x86_64.rpm package

* Martin Gansser: > Hi, > > i want to compile vdr [1] on f35, but this fails with: > > + for plugin in dvbhddevice dvbsddevice rcu skincurses > + /usr/bin/make -O -j8 V=1 VERBOSE=1 -C PLUGINS/src/dvbhddevice > VDRDIR=/builddir/build/BUILD/vdr-2.4.7 > PLGCFG=/builddir/build/BUILD/vdr-2.4.7/bundle

Re: Fedora rawhide compose report: 20210727.n.0 changes

* Petr Pisar: > V Tue, Jul 27, 2021 at 03:03:36PM +0200, Michael Schwendt napsal(a): >> Something in grep/sed/rpm is broken since today or yesterday. >> >> On July 24th, a %global definition in a spec file still worked. >> It still works with a local Mock build for Rawhide/F35. >> It fails in koj

Re: apitrace: undefined reference to `__libc_dlopen_mode', `__libc_dlsym'

* Nicholas Miell: > On 7/25/21 4:28 AM, Florian Weimer wrote: >> * Sandro Mani: >> >>> I'd need help with the following issue with apitrace, which failed the >>> mass rebuild with: >>> >>> apitrace-9d42f667e2a36a6624d92b9bd697de097c

Re: Free Pascal and F35 Mass Rebuild

y for the other architectures. You can use this glibc commit for reference purposes: commit 035c012e32c11e84d64905efaf55e74f704d3668 Author: Florian Weimer Date: Thu Feb 25 12:10:57 2021 +0100 Reduce the statically linked startup code [BZ #23323] Note that if these changes are applied

Re: apitrace: undefined reference to `__libc_dlopen_mode', `__libc_dlsym'

* Sandro Mani: > I'd need help with the following issue with apitrace, which failed the > mass rebuild with: > > apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym.cpp:70: > undefined reference to `__libc_dlopen_mode' > apitrace-9d42f667e2a36a6624d92b9bd697de097cc4e619/wrappers/dlsym

Re: glibc 2.34 vs firefox in rawhide vs mass build rebuild

This is now resolved in rawhide. Thanks to all who have helped to get us to this point. Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://

Re: problem to compile fedora kernel: BTF/pahole

* Marius Schwarz: > while trying to recompiling  fedora 5.12.17 kernel, I got a final error: > > scripts/link-vmlinux.sh: Line 214: 273523 Killed > LLVM_OBJCOPY="${OBJCOPY}" ${PAHOLE} -J ${1} Check the journal/dmesg. Maybe it's just an out-of-memory error? Thanks, Florian __

Re: glibc 2.34 vs firefox in rawhide vs mass build rebuild

* Florian Weimer: > Firefox in rawhide hasn't been built successfully since > firefox-89.0-1.fc35 (built 2021-06-02). Unfortunately that version does > not treat the clone3 system call correctly in its sandbox, so it won't > work with future glibc 2.34 snapshots. > &g

glibc 2.34 vs firefox in rawhide vs mass build rebuild

Firefox in rawhide hasn't been built successfully since firefox-89.0-1.fc35 (built 2021-06-02). Unfortunately that version does not treat the clone3 system call correctly in its sandbox, so it won't work with future glibc 2.34 snapshots. I fixed the issues to get firefox building again and attach

Re: F35 Change: Remove SHA-1 from Sqlite (Self-Contained Change proposal)

* Ben Cotton: > == Detailed Description == > The use of SHA-1 is no longer permitted for Digital Signatures or > authentication in RHEL-9. Due to this reason, there is a need to > remove SHA-1 extension from sqlite in RHEL-9 and therefore also > Fedora. The removal of the extension was discussed w

Re: guile22 -> gnutls -> lots of virt packages

* Stephen John Smoogen: > On Wed, 7 Jul 2021 at 11:45, Florian Weimer wrote: >> >> * Stephen John Smoogen: >> >> > C) This proposal was reviewed and pushed again for F35 even if it is >> > 'too late' because well this just doesn't sit w

Re: guile22 -> gnutls -> lots of virt packages

* Stephen John Smoogen: > C) This proposal was reviewed and pushed again for F35 even if it is > 'too late' because well this just doesn't sit well. This doesn't make sense to me—what is “this proposal”, and how it was “pushed again”? Thanks, Florian _

Re: Guile & Fesco requiring package maintenance work

* Ben Cotton: > It wouldn't have even come up in a meeting except there were a couple > of FESCo members opposed to it. If we're going to change processes, > perhaps the better change is to explicitly invite people to the > meeting when their Change proposal is on the agenda. It probably would ha

Re: guile22 -> gnutls -> lots of virt packages

* Daniel P. Berrangé: > What's notable to me is that, generally speaking, maintainers use > their own discretion as to which optional features they enable > or disable with a package built in Fedora. I'd expect that in most > cases similar to this a maintainer will just disable the feature, > do a

Re: guile22 -> gnutls -> lots of virt packages

* Fabio Valentini: > If it turns out that really actually nobody uses this, why not drop it > upstream, and have the guile support removal come with the next GNU > toolchain Change for Fedora? Guile support in GNU packages is a goal of the GNU project, I think. Where Guile is used as a scripting

Guile & Fesco requiring package maintenance work (was: Re: guile22 -> gnutls -> lots of virt packages)

* Hans de Goede: > Hi, > > On 7/7/21 1:08 PM, Florian Weimer wrote: >> * Neal Gompa: >> >>> Wait, why don't we have guile 3.0? >> >> We have a mandate from Fesco that the core toolchain must depend on >> Guile. Naturally that makes updat

Re: guile22 -> gnutls -> lots of virt packages

* Neal Gompa: > On Wed, Jul 7, 2021 at 7:08 AM Florian Weimer wrote: >> >> * Neal Gompa: >> >> > Wait, why don't we have guile 3.0? >> >> We have a mandate from Fesco that the core toolchain must depend on >> Guile. Naturally that makes upda

Re: guile22 -> gnutls -> lots of virt packages

* Neal Gompa: > Wait, why don't we have guile 3.0? We have a mandate from Fesco that the core toolchain must depend on Guile. Naturally that makes updates rather difficult. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To uns

Re: F35 Change: GNU Toolchain update (gcc 11, glibc 2.34, binutils 2.37, gdb 10.2) (System-Wide Change proposal)

* Carlos O'Donell: > On Tue, Jun 29, 2021 at 2:14 PM Ben Cotton wrote: >> >> On Tue, Jun 29, 2021 at 2:07 PM Ben Cotton wrote: >> > >> > == Contingency Plan == >> > * Contingency mechanism: If glibc 2.34 provides too disruptive to >> > compiling the distribution we could revert to 2.33, but give

Re: Auto-generated dependencies for builds against rawhide glibc snapshots

* Richard W. M. Jones: > On Sun, Jun 27, 2021 at 08:54:20PM +0200, Florian Weimer wrote: >> I've pushed a new glibc build to rawhide (glibc-2.33.9000-29.fc35) that >> auto-generates versioned dependencies on glibc if symbols within the >> under-development symbol versi

Re: GNOME on Wayland does not work on latest Rawhide

* Mohan Boddu: > On Mon, Jun 28, 2021 at 3:20 PM Florian Weimer wrote: >> >> * Mohan Boddu: >> >> > Not sure if its related, but bolt is also having an issue: >> >> What's your glibc version? glibc-2.33.9000-25.fc35 is the first build >> w

Re: GNOME on Wayland does not work on latest Rawhide

* Mohan Boddu: > Not sure if its related, but bolt is also having an issue: What's your glibc version? glibc-2.33.9000-25.fc35 is the first build with the (then downstream-only) fix. boltd issues have been reported as well, but I'm not sure if we have verified that they went away with the fix f

Auto-generated dependencies for builds against rawhide glibc snapshots

I've pushed a new glibc build to rawhide (glibc-2.33.9000-29.fc35) that auto-generates versioned dependencies on glibc if symbols within the under-development symbol version are used, where the ELF-derived RPM dependencies are inaccurate. Given the change to the startup code, this affects all prog

Re: Dependency generators and Koji builds

* Florian Weimer: > As far as I know, my dependency generator is determinstic, so this > really should not happen. (Note that not all builds are expected to > carry this dependency, but everything that contains an ELF main program > should.) Sorry, false alarm, I think I found

Dependency generators and Koji builds

What steps are required to get RPM dependency generators to run in Koji? I have added a dependency generator to the glibc-devel package: A scratch build of lua shows that this glibc version is

Re: use unit names in systemd output by default?

* Colin Walters: > On Fri, Jun 25, 2021, at 6:21 AM, Zbigniew Jędrzejewski-Szmek wrote: >> Hi, >> >> systemd has systemd.status_unit_format= / [Manager].StatusUnitFormat= >> / -Dstatus-unit-format-default= option to use unit names instead of the >> Description in messages on the kernel console an

Re: Fedora Source-git SIG report #1 (June 2021)

* Zbigniew Jędrzejewski-Szmek: > I think we should try to push upstream to sign git tags, instead or in > addition to tarballs. For upstreams, this is actually much easier > (just 'git tag' → 'git tag -s' and you're done) compared to e.g. signing > a tarball on github which requires some interacti

Re: GNOME on Wayland does not work on latest Rawhide

* Florian Weimer: > We could use some basic GNOME SHell debugging help here. Ideally, we'd > like to run GNOME Shell in such a way that it does not perform X > fallback and does not re-exec itself, and uses a specified VT (so that > we can launch it over an SSH session). >

Re: GNOME on Wayland does not work on latest Rawhide

We could use some basic GNOME SHell debugging help here. Ideally, we'd like to run GNOME Shell in such a way that it does not perform X fallback and does not re-exec itself, and uses a specified VT (so that we can launch it over an SSH session). (This is about bug 1974970.) Thanks, Florian _

Re: RFC: Banning bots from submitting automated koji builds

* Matthew Miller: > On Sun, Jun 20, 2021 at 09:48:15AM -0700, Adam Williamson wrote: >> We've talked about various concerns around this in the past (the >> technicalities of exactly how to implement it, and the concern that not >> enough composes actually meet the requirements so we'd wind up with

Re: Fwd: glibc gconv package split

* Miro Hrončok: > On 22. 06. 21 4:48, Siddhesh Poyarekar wrote: >> This may result in testing failures when >> applications try to test uncommon character set conversions. The fix >> to get that working again is to add a build dependency on >> glibc-gconv-extra. > > Could you please add "glibc-gc

Re: GNOME on Wayland does not work on latest Rawhide

* Igor Raits: > Hello, > > Seems with some latest updates in Rawhide (tbh I haven't updated for a > ~month) I can't get > Wayland working on my laptop anymore. I've tried to downgrade mesa, mutter, > gnome-shell, kernel and a few other packages but no luck. > > Is it just my laptop that's somehow

Re: Fwd: glibc gconv package split

* Zbigniew Jędrzejewski-Szmek: >> glibc-gconv-extra is recommended by glibc, so a regular update or >> default installation should pull in glibc-gconv-extra and there should >> be no noticeable change unless a user explicitly removes >> glibc-gconv-extra at some point. > > To preserve compatibilit

Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

* Tom Stellard: > Instead of doing two scratch builds, I just added: > %global __brp_check_rpaths time /usr/lib/rpm/check-rpaths to the spec file > and did a scratch build[1]. > > The results on x86_64 were: > > real 13m51.517s > user 8m53.216s > sys 7m34.105s > > Overall build time for the sc

Re: x86_64-v2 in Fedora

* przemek klosowski via devel: > I'm missing something---I get identicaloutput on my v3 Core i7-4810MQ Why do you expect different output? > Is this supposed to run HWCAP and show the result, or just show the > HWCAP configuration and possible choices? It shows capabilities (as defined by the h

Re: x86_64-v2 in Fedora

* Neal Gompa: > On Wed, Jun 16, 2021 at 8:57 AM Vitaly Zaitsev via devel > wrote: >> >> On 16.06.2021 14:45, Frantisek Zatloukal wrote: >> > We'll at least gather information about capabilities of Fedora users >> > hardware. >> >> Telemetry is evil. It must not be allowed. >> > > So how do you pr

Re: x86_64-v2 in Fedora

* Stephen John Smoogen: > I used this > https://unix.stackexchange.com/questions/631217/how-do-i-check-if-my-cpu-supports-x86-64-v2 > to see what cpu instructions are at each level > > ``` > #!/usr/bin/awk -f > > BEGIN { > while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1 > if (/

Re: Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9

glibc-2.33.9000-18.fc35 with the first set of changes has been tagged into Fedora rawhide. Thanks, Florian > TL;DR: glibc 2.34 snapshots are coming. libpthread as a separate library > creates problems, so we are removing it. There may be some > hickups. Full updates with “dnf update” are recomme

Re: x86_64-v2 in Fedora

* Neal Gompa: > Some cursory examination of the new x86_64 sublevels seem to indicate > that x86_64-v2 goes back to roughly 2007~2008, merely cutting off the > first couple of generations of x86_64 CPUs from Intel and AMD. I > personally don't have any computers that don't have support for > x86_6

Re: x86_64 and -mcx16

* Orion Poplawski: > I recently acquired a cheap wintel toy tablet/laptop (a Kano PC), > which has a Celeron N4000 processor. > Looking at the build logs of openmpi-4.1.0-5.fc34.x86_64, I see that > it has been compiled with the -mcx16 flag detected by configure. > However, because the instructi

Bringing glibc 2.34 snapshots to Fedora 35 and CentOS Stream 9

TL;DR: glibc 2.34 snapshots are coming. libpthread as a separate library creates problems, so we are removing it. There may be some hickups. Full updates with “dnf update” are recommended. We expect that we will soon be able to import glibc upstream snapshots regularly into Fedora 35 and CentOS

Re: [fedora-arm] Disable annobin on 32 bit Arm while an issue is investigated?

* Peter Robinson: > On Tue, May 18, 2021 at 5:52 PM Arjun Shankar wrote: >> >> Hello, devel and arm lists! >> >> We recently ran into a testsuite failure when building glibc for >> Rawhide on armv7hl: >> https://bugzilla.redhat.com/show_bug.cgi?id=1951492 >> >> The test program experienced a hang

Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

* Charalampos Stratakis: > On Mon, May 10, 2021 at 5:08 PM Florian Weimer wrote: > > * Charalampos Stratakis: > > > I think these rules make sense for RUNPATH, and we should outright ban > > RPATH. > > > > I'd agree here as well, however this

Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

* Charalampos Stratakis: > I think these rules make sense for RUNPATH, and we should outright ban > RPATH. > > I'd agree here as well, however this could be a future fedora change > as I would deem it too disruptive to outright ban RPATH for now. I don't agree because of this: > I think we al

Re: F35 Change: Broken RPATH will fail rpmbuild (System-Wide Change proposal)

* Ben Cotton: > Another problem of a hardcoded RPATH is security. When an ELF object > contains an RPATH pointed to a directory not managed by the system, > where some malicious actor has write permissions to, it's relatively > easy to execute arbitrary code. > > Performance can be also affected,

Disappearing and re-appearing i686 packages in the x86_64 compose

Historically, we had an issue with i686 packages appearing and disappearing from the x86_64 compose. Particularly problematic is the case when packages are in the GA repo, but not in the updates repo. Has this issue been fixed? I implemented a workaround

<    1   2   3   4   5   6   7   8   9   10   >