Re: Discussion: unixODBC - move unversioned *.so files back to unixODBC-devel package

2020-09-11 Thread Florian Weimer
* Tom Hughes via devel: > On 11/09/2020 07:13, Ondrej Dubaj wrote: > >> There seemed to be no big reason for moving the libraries to the >> main package in the past, so I consider f34 as a good candidate for >> such a change. It would be great, if  you share your opinions and >> concerns for this

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

2020-09-10 Thread Florian Weimer
* Ben Cotton: > https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable > > == Summary == > Remove support for SELinux runtime disable so that the LSM hooks can > be hardened via read-only-after-initialization protections. > > Migrate users to using ''selinux=0'' if they

noarch packages only for some architecture composes

2020-09-07 Thread Florian Weimer
Is it possible to include a noarch package only in some of the composes? The background is that I added glibc-headers-x86.noarch to deal with a conflict between inconsistent composes (glibc-headers.i686 was sometimes in the x86_64 compose, sometimes it was not). glibc-headers-x86.noarch is

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-02 Thread Florian Weimer
* John M. Harris, Jr.: > On Tuesday, September 1, 2020 5:19:15 AM MST Florian Weimer wrote: >> * John M. Harris, Jr.: >> >> >> > Sure, those two companies will be thrilled, I'm sure. This is a huge >> > disservice to our users. Why in the world does syst

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-01 Thread Florian Weimer
* Roberto Ragusa: > Standard DNS has a hierarchical structure with roots and delegation. > The idea of asking somebody to do DNS resolution for you comes from > the widespread tendency to centralize everything (i.e. inability to > understand how the Internet was originally designed). DNS

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-01 Thread Florian Weimer
* John M. Harris, Jr.: > Sure, those two companies will be thrilled, I'm sure. This is a huge > disservice to our users. Why in the world does systemd try to force DNS > servers when none are configured? If no DNS servers are configured, there > should be no DNS servers in use. Acutally, the

Re: calculating process memory usage

2020-08-15 Thread Florian Weimer
* Samuel Sieb: > Since you've brought this up, this is a question I've had for a long > time. How do you get real memory+swap usage information for processes > or is that even possible? Looking in ps or top, the RES is way too > small and the VIRT/VSIZE is way too big. ps_mem is also way

Re: Lost ELF library auto-provides since mass rebuild

2020-08-06 Thread Florian Weimer
* Daniel P. Berrangé: > This AC_LANG_PROGRAM call puts the code snippet inside a main() { ...} > so what configure was actually attempting to compile is: > > int > main () > { > >int f1() { } >int f2() { } >asm(".symver f1, f@VER1"); >

Re: Lost ELF library auto-provides since mass rebuild

2020-08-06 Thread Florian Weimer
* Daniel P. Berrangé: > This is in relation to this bug > > https://bugzilla.redhat.com/show_bug.cgi?id=1862745 > > The last but one build of libgphoto have auto-provides for the ELF > libraries: > > libgphoto2 = 2.5.24-2.fc33 > libgphoto2(x86-64) = 2.5.24-2.fc33 > libgphoto2.so.6()(64bit) >

Re: mpich always injects lto flags

2020-08-06 Thread Florian Weimer
* Christoph Junghans: > I am trying to rebuild espresso to adapt to the recent cmake changes, > when doing this I hit > https://github.com/espressomd/espresso/issues/3396, which prevents us > from compiling espresso with -lto, so I set _lto_cflags to %{nil}, > which works for the build with

Re: Test machines for s390x?

2020-08-06 Thread Florian Weimer
* Elliott Sales de Andrade: > Just like we have test machines for other less used architectures [1], > I am wondering if there is some way we can spin up a test machine for > s390x? Marist offers machine access for open-source development:

Re: Reminder: upcoming Fedora 33 deadlines & milestones

2020-08-05 Thread Florian Weimer
* J. Scheurich: > It lloks like boost.173 would require a future verson of gcc/g++ Why do you think that? According to Boost upstream, anything later than GCC 8 is untested, but I don't think this is actually true. Thanks, Florian ___ devel mailing

Re: OCaml + binutils 2.35 on i386

2020-08-05 Thread Florian Weimer
* Richard W. M. Jones: > On Tue, Aug 04, 2020 at 01:48:45PM -0600, Jerry James wrote: >> When ocamlopt is used with binutils 2.35 to link an executable, we now >> get warnings that look like this: >> >> /usr/bin/ld: tests/test_topsort.o: warning: relocation in read-only >> section `.text' >>

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

2020-08-04 Thread Florian Weimer
* Jeff Law: > Actually, isn't it "just" 234MB. Still I'm surprised why that failed. Do we > have more than one build running at a time on those boxes? It's a 32-bit build. I assume it's not the first large allocation. (FWIW, GDB always prints “virtual memory exhausted”, even if the malloc

Re: ARM: Installed (but unpackaged) file(s) found: /usr/bin/....gdb-index-9pY4kY

2020-08-04 Thread Florian Weimer
* Miro Hrončok: > Hello, I've got this failure I cannot really understand, it happens on > armv7hl only (aarch64 and s390x were cancelled): > > Checking for unpackaged file(s): /usr/lib/rpm/check-files > /builddir/build/BUILDROOT/prusa-slicer-2.2.0-4.fc33.arm > error: Installed (but unpackaged)

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

2020-08-04 Thread Florian Weimer
* Daniel P. Berrangé: > Taken from https://koji.fedoraproject.org/koji/taskinfo?taskID=48525923 Sorry, what would be more interesting is the linker invocation. The build log does not show this, only the libtool invocation. We don't really know what kind of transformations libtool does in this

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

2020-08-03 Thread Florian Weimer
* Daniel P. Berrangé: > If I run LD_DEBUG=all on a build /with/ LTO, there are no symbol lookups > at all for qemuProcessStartManagedPRDaemon. It looks very much like the > call was resolved and bound at link time when built with LTO. It's possible that the symbol extraction logic is confused by

Re: LTO vs LD_PRELOAD (libvirt FTBFS test suite failure)

2020-08-03 Thread Florian Weimer
* Daniel P. Berrangé: > Disabling LTO in the RPM spec confirms this and makes things pass > again. Hacking the makefiles to remove the -fno-lto option when > building the test suite binaries also fixes things. > > I don't see any mention of LD_PRELOAD being impacted by LTO in the > Fedora feature

Re: Another possible LTO failure in guestfish (or maybe readline)

2020-07-31 Thread Florian Weimer
* Richard W. M. Jones: > Here's another one: > > $ rpm -qf /usr/bin/guestfish /lib64/libreadline.so.8 > libguestfs-tools-c-1.43.1-2.fc33.x86_64 > readline-8.0-5.fc33.x86_64 > $ guestfish --version > Segmentation fault (core dumped) > > (gdb) bt > #0 0x in () > #1

Re: Can we use emulation of other architectures to run integration tests?

2020-07-30 Thread Florian Weimer
* Daniel P. Berrangé: >> For emulating 32-bit targets, we have a broken readdir/telldir/seekdir >> implementation in glibc on 64 bit host kernels because we try to use >> d_ino directly, which is 64 bit and does not fit into the long value recte: d_off >> that POSIX requires. A kernel patch

Re: Can we use emulation of other architectures to run integration tests?

2020-07-30 Thread Florian Weimer
* Daniel P. Berrangé: > I'm not familiar with what COPR is doing for s39x0 ? Is it using the > simple QEMU linux-user syscall emulation, or is it running a proper > QEMU s390x VM. > > I'm guessing probably the former. The linux-user syscall emulation is > truely amazing, but it is certainly not

Re: How do Fedora developers get access to devtoolset for testing.

2020-07-29 Thread Florian Weimer
* Jonathan Wakely: > It's not about devtoolset. Installing CentOS 7 RPMs on Fedora rawhide > is outlandish. It won't work in general, because the CentOS RPMs have > dependencies on CentOS packages, and Fedora has different versions. Steven has a point, though. For software not built by Red Hat,

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-07-27 Thread Florian Weimer
* Michael Catanzaro: > On Sun, Jul 26, 2020 at 6:15 pm, John M. Harris Jr > wrote: >> Please do not disable reading from /etc/resolv.conf. If you do so, >> please >> limit that to the Spins that it won't affect people on, such as >> Workstation, >> if you believe people there don't set their own

Re: Dropping elfutils-libelf-devel-static and elfutils-devel-static subpackages

2020-07-24 Thread Florian Weimer
* Mark Wielaard: > BTW. Can Obsoletes ever be removed? We have an Obsoletes: libelf <= > 0.8.2-2 on elfutils-libelf since the original cvsdist import of 2004 > because there used to be a different libelf implementation (with a dead > upstream these days). Can I remove that? Or is it better to

[EPEL-devel] Re: gcc-gnat

2020-07-14 Thread Florian Weimer
* Björn Persson: > In Fedora and earlier versions of RHEL/CentOS, gcc-gnat is a subpackage > of gcc. Adding it to EPEL would make it a separate package. I'm not > sure what complications might arise from that. The main problem is that /usr/bin/gcc does not have Ada support. It will not try to

Re: Can we do away with release and changelog bumping?

2020-07-06 Thread Florian Weimer
* Björn Persson: > The macro could be defined like this for example: > > %buildtag .%(date +%%s) Using time for synchronization is always a bit iffy. > It would be used in each spec like this: > > Release: 1%{?dist}%{?buildtag} We could put the Koji task ID directly into the %dist tag. We

Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-07-02 Thread Florian Weimer
* Nicolas Mailhot via devel: > Le 2020-07-02 09:59, Vitaly Zaitsev via devel a écrit : >> On 02.07.2020 07:35, Nicolas Mailhot via devel wrote: >>> The detached changelog is just one more file in SRPM sources, which is >>> modified by rpmbuild at `%build` time with other files rpmbuild >>>

Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

2020-07-02 Thread Florian Weimer
* Vít Ondruch: > I just met something which might be of similar nature. Recent FF > 78.0-1.fc33.x86_64 fails to start with older glibc: > > > ~~~ > > $ firefox > XPCOMGlueLoad error for file /usr/lib64/firefox/libxul.so: > /usr/lib64/firefox/libxul.so: undefined symbol: pthread_getattr_np, >

Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-07-02 Thread Florian Weimer
* Nicolas Mailhot: > Le 2020-07-02 09:52, Florian Weimer a écrit : >> * Nicolas Mailhot via devel: >> >>>> How do I let rpm generate the changelog automatically? >>> >>> This feature is not changelog generation, just changelog bumping on >>>

Re: [Fedora-packaging] RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-07-02 Thread Florian Weimer
* Nicolas Mailhot via devel: >> How do I let rpm generate the changelog automatically? > > This feature is not changelog generation, just changelog bumping on > build events. You still need some other method to put non-build events > in the changelog. What is “changelog bumping”? Why is it

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-02 Thread Florian Weimer
* Konstantin Kharlamov: > FWIW, I was just thinking about it, and I came up with example you > may like which shows exactly why BTRFS is bad for HDD. Consider > development process. It includes rewriting source files over and > over: you do `git checkout foo` and files are overwritten, you >

Re: rawhide - glibc/pthreads/... - broken pending mass rebuild?

2020-06-30 Thread Florian Weimer
* Alex Scheel: > Is Fedora Rawhide unstable at the moment, pending a mass rebuild? > > I've seen a lot of random problems related to pthreads at the > moment, such as: > > 16/78 Test #12: JSS_DER_Encoding_of_Enumeration_regression_test ...Child > aborted***Exception: 0.99 sec > FINE:

Re: The future of legacy BIOS support in Fedora.

2020-06-30 Thread Florian Weimer
* Jóhann B. Guðmundsson: > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > changes it beg the question if now would not be the time to stop > supporting booting in legacy bios mode and move to uefi only supported > boot which has been available on any common intel based x86

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-30 Thread Florian Weimer
* Steven Whitehouse: > On 27/06/2020 11:00, Florian Weimer wrote: >> * Josef Bacik: >> >>> As for your ENOSPC issue, I've made improvements on that area. I >>> see this in production as well, I have monitoring in place to deal >>> with the machine befo

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-29 Thread Florian Weimer
* Solomon Peachy: > On Mon, Jun 29, 2020 at 11:33:40AM +0200, Florian Weimer wrote: >> Just to be clear here, the choice of XFS here is purely based on >> performance, not on the reliability of the file systems, right? >> (So it's not “all the really important

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-29 Thread Florian Weimer
* Josef Bacik: > That being said I can make btrfs look really stupid on some workloads. > There's going to be cases where Btrfs isn't awesome. We still use xfs > for all our storage related tiers (think databases). Performance is > always going to be workload dependent, and Btrfs has built in

Re: User experience issue on btrfs

2020-06-29 Thread Florian Weimer
* Chris Adams: > Once upon a time, John M. Harris Jr said: >> XFS proved to be troublesome, and still is up to the latest of RHEL7. It's >> not >> uncommon to have to run xfs_repair on smaller XFS partitions, especially / >> boot. I'm not sure if btrfs has the same issue there? > > [citation

Re: Packaging firmwares

2020-06-28 Thread Florian Weimer
* Richard Hughes: > On Fri, 26 Jun 2020, 22:21 Florian Weimer, wrote: > > Is FirmwareUpdate.efi really firmware in Fedora's sense? Won't it run > on the host CPU? > > This is flashed hardware!? Can't mellanox just use the LVFS to > distribute firmware rather than having

Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Florian Weimer
* Josef Bacik: > As for your ENOSPC issue, I've made improvements on that area. I > see this in production as well, I have monitoring in place to deal > with the machine before it gets to this point. That being said if > you run the box out of metadata space things get tricky to fix. > I've

Re: Packaging firmwares

2020-06-26 Thread Florian Weimer
* Robert-André Mauchin: > I have a review request for a firmware: Boot firmware (ATF, UEFI...) for > Mellanox BlueField: > > https://bugzilla.redhat.com/show_bug.cgi?id=1846139 > > I would like some opinions on whether this is acceptable firmware. The > binary contains open source code for which

Re: undefined symbol: pthread_getattr_np, version GLIBC_2.32

2020-06-16 Thread Florian Weimer
* Igor Raits: > On Tue, 2020-06-16 at 18:39 +0800, 西木野羰基 wrote: >> Could please check what version of glibc has been installed during >> mock build? I can;t find the logs or the build artifacts. >> But by checking other build yesterday I can found that glibc in koji >> build is newer than the one

Re: undefined symbol: pthread_getattr_np, version GLIBC_2.32

2020-06-16 Thread Florian Weimer
* Igor Raits: > I built gitui in koji (f33) yesterday and tried to run it on my laptop > with Fedora Rawhide today and it does not work: > > gitui: symbol lookup error: gitui: undefined symbol: > pthread_getattr_np, version GLIBC_2.32 > > Did anybody see something similar in other applications?

Re: [fedora-java] Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

2020-06-15 Thread Florian Weimer
* Jiri Vanek: > Is there some replacemnt for this subpackage? At least theoretical? For the JDBC connector to SQLite, there's sqlite-jdbc and javasqlite. But the on-disk format will be different. For the key-value store, there is the je package, but again the on-disk format is different.

Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

2020-06-15 Thread Florian Weimer
* Ondrej Dubaj: > The problem is unknown runtime behaviour of libdb-java (build with > jdk-1.8, as it is unable to build with jdk-11) with JVM-11. Are you an > active user of libdb java ? I am not. Upon second thought, it doesn't seem to make sense to preserve libdb-java (although I expect that

Re: Announcement: Aim to remove libdb-java from Fedora-rawhide

2020-06-11 Thread Florian Weimer
* Ondrej Dubaj: > we are aiming to remove libdb-java package from Fedora-rawhide, as we > are currently preparing for jdk update from jdk-1.8 to jdk-11 in > Fedora rawhide. The problem is that we are unable to rebuild this > package with jdk-11. It is still possible to "hack" it and rebuild it >

Re: Is there an official Fedora for WSL?

2020-06-08 Thread Florian Weimer
* Iñaki Ucar: > On Mon, 8 Jun 2020 at 07:12, Gordon Messmer wrote: >> >> > - I found that [1] does a pretty good job replacing /usr/bin/systemctl >> > [1] https://github.com/gdraheim/docker-systemctl-replacement >> >> I only use WSL for an interactive shell, so I haven't needed to do much >> of

Re: devel Digest, Vol 196, Issue 58

2020-06-05 Thread Florian Weimer
* Jeff Law: > As we both know, GCC has had ABI bugs as well. Both compilers strive > to be ABI compatible with each other and we should continue to work > together to find and address such issues. SImilarly both compilers > are going to have codegen issues, or rejects-valid-code bugs. >

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-05 Thread Florian Weimer
* Ben Cotton: > https://fedoraproject.org/wiki/Changes/CompilerPolicy > > == Summary == > Fedora has historically forced packages to build with GCC unless the > upstream project for the package only supported Clang/LLVM. This > change proposal replaces that policy with one where compiler

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-05 Thread Florian Weimer
* Jeff Law: > I'm not suggesting switching the default. I'm suggesting the compiler > choice be made by the upstream projects. Some prefer LLVM, others > prefer GCC. Fedora should get out of the way and use the same tools > that the upstream projects are using. Do we know how many upstream

Re: Fedora 33 System-Wide Change proposal: CompilerPolicy Change

2020-06-05 Thread Florian Weimer
* Igor Raits: > From what I see, GCC supports it on x86, x86_64, s390x, riscv64, > ppc64le. So this just does not include ARM / AArch64 from Fedora > architectures. GCC has aarch64 support for stack-clash-protection, but it only works well with 64K pages (otherwise detection is not reliable).

Re: Has something changed with RPMS?

2020-06-02 Thread Florian Weimer
* Panu Matilainen: > Lets start with the basics: > - is sqlite even involved - it will only be used on rawhide builds if > mock bootstrap is used > - does it make a difference if you override _db_backend to bdb/sqlite > from mock config / cli define > - a reproducer please (eg, what package is

Re: Location of executable code

2020-05-22 Thread Florian Weimer
* Petr Viktorin: > Does "read-only architecture independent data" mean the files must not > be programs? Not according to the FHS. From the FHS perspective, /usr/share is just like RPM's noarch architecture: completely portable across all architectures. It can even be machine code if it does

Re: Problems with packages compiled with gcc 10.0

2020-05-19 Thread Florian Weimer
* Guido Aulisi: > I'm getting some strange errors from some packages built for f32 with > gcc 10.0 [0]. > Building with g++ 10.1 ardourd5 seems fine... > > It seems GCC 10.0 had some bugs that could be discovered only at > runtime. Did you have any similar problems? > > Ciao > Guido > FAS:

Re: Many packages unnecessarily link to libpython

2020-05-16 Thread Florian Weimer
* Charalampos Stratakis: > If your package links to libpython without requiring it, it won't be > possible to use the python3-debug binary with your python C extension, > unless you recompile the extension against it. Would it make sense to work around this by some other means? Thanks, Florian

Re: armv7l status?

2020-05-14 Thread Florian Weimer
* Peter Robinson: > armhfp is "Arm hard floating point" which covers the overall ARM 32 > bit architecture, there can be different variants in there, armv6, > armv7, armv7+NEON, armv8 (the 32 bit variant as opposed to aarch64) > and so on... Just to be clear here, armhfp is *not* the common

Re: armv7l status?

2020-05-14 Thread Florian Weimer
* Stephen John Smoogen: > When x86_64 splits into 48 bit memory path to some larger memory (60 > bit I think is discussed) sometime in the future, we will probably > still call it x86_64 but build x86_64b packages. This has already happened. You did not notice it because it did not require

Re: Is dist-git a good place for work?

2020-05-13 Thread Florian Weimer
* Stephen John Smoogen: > No because the things that backups and rsync do works in a slow way. > We can do the backup the look-aside cache with tar-balls in a couple > of hours. We can also rsync that in the same amount of time. It takes > that long or longer to do that with a couple of git trees

Re: Is dist-git a good place for work?

2020-05-07 Thread Florian Weimer
* Fabio Valentini: > In the rare occasion that I need to make downstream-only changes with > patches, I usually just explode the upstream tarball, run "git init", > then "git add .", "git commit -m import", apply my changes, and then > do "git diff --patch > ../00-my-changes.patch" (if it's just

Re: Is dist-git a good place for work?

2020-05-07 Thread Florian Weimer
* Pierre-Yves Chibon: > On Wed, May 06, 2020 at 08:39:19PM +0200, clime wrote: >> But I would like to note that exploded repos (or source-git repos) >> have at least two other advantages. >> >> 1) they consume less space than tarballs for each version because >> objects in git repo are

Re: sorting of git N-V-R tags in rpm package repositories

2020-05-06 Thread Florian Weimer
>> >> Tags can also be added retroactively and backdated. These things >> >> conflict with the advantages you list (in particular, with NVR >> >> auto-generation, git is not the sole source of truth). >> > >> > If the tag ordering function is done properly, I believe even >> > retroactive tagging

Re: Is dist-git a good place for work?

2020-05-05 Thread Florian Weimer
* Neal Gompa: > On Tue, May 5, 2020 at 1:33 PM Florian Weimer wrote: >> >> * Neal Gompa: >> >> > In the merged-source world, the packaging is an aspect of managing the >> > software codebase. This is common in Debian and ALT Linux, where the >> >

Re: Is dist-git a good place for work?

2020-05-05 Thread Florian Weimer
* Neal Gompa: > In the merged-source world, the packaging is an aspect of managing the > software codebase. This is common in Debian and ALT Linux, where the > standard practice with their tooling is to fork the codebase and > integrate the packaging files into the tree. Changes then are managed

Re: sorting of git N-V-R tags in rpm package repositories

2020-05-05 Thread Florian Weimer
> Hey Florian, > > On Mon, 4 May 2020 at 10:03, Florian Weimer wrote: >> >> > as part of https://hackmd.io/kIje9yXTRdWITwP7cFK2pA (annotated tags >> > pushed by package maintainers) effort, I revisited the sorting >> > algorithm that is used to determine

Re: will disappear from rawhide glibc soon

2020-05-05 Thread Florian Weimer
* Fabio Valentini: > On Wed, Apr 15, 2020 at 5:50 PM Florian Weimer wrote: >> >> This follows the removal of the system call from Linux 5.5. Having the >> header and function just confuses configure checks that assume that if >> the function is present, it will do som

Re: Is dist-git a good place for work?

2020-05-05 Thread Florian Weimer
* Tomas Tomecek: > Florian, a very good point. Yes, we are planning to support GitLab - > we have a GSoC project for it: > https://pagure.io/mentored-projects/issue/69 Is a GSoC project really the appropriate vehicle for this? Gitlab has one major advantage over Github: it is possible to

Re: Is dist-git a good place for work?

2020-05-04 Thread Florian Weimer
* Tomas Tomecek: > In the packit project, we work in source-git repositories. These are > pretty much upstream repositories combined with Fedora downstream > packaging files. An example: I recently added a project called nyancat > [n] to Fedora. I have worked [w] on packaging the project in the >

Re: Aarch64 build failure: hidden symbol `__aarch64_ldadd4_acq_rel' in /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by DSO

2020-05-04 Thread Florian Weimer
* Milan Crha: > out of the interest (no offense meant), would this not be caught by the > rawhide gating? I'd expect that this is something what the rawhide > gating would avoid. There is no simple way to run buildroot readiness tests in Fedora. One has to use weird scripts for that, and the

Re: sorting of git N-V-R tags in rpm package repositories

2020-05-04 Thread Florian Weimer
> as part of https://hackmd.io/kIje9yXTRdWITwP7cFK2pA (annotated tags > pushed by package maintainers) effort, I revisited the sorting > algorithm that is used to determine the "latest" tag for a given > package which is needed to determine correct package version. > Basically, if the current

Re: Backports of fixes from F32 -> F31?

2020-04-29 Thread Florian Weimer
* Alex Scheel: > Hi Florian, > > I've hit numerous bugs in GNOME in F31. Some of these are fixed in F32, > such as this one against mutter: > > https://bugzilla.redhat.com/show_bug.cgi?id=1770296 > > > Could we get some of these fixes backported? I've not heard from you on > this bug at all,

Re: ckermit?

2020-04-29 Thread Florian Weimer
* Steven A. Falco: > I'd like to request a rebuild for F32. Is it sufficient to request > that here, or is there some other procedure that I should use? I've merged the F33 change (dropping termcap-devel) and kicked off a new build. Please test the update and provide karma

Re: What CPU extensions can we assume are available by arch?

2020-04-27 Thread Florian Weimer
* Kevin Kofler: > Jun Aruga wrote: >> simde is a header files only library. It's not a binary. > > Then it is inherently unsuitable for automatic runtime selection, and > all the runtime selection still has to be done in the client program. > > GCC requires you to compile for separate vector

Re: cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++

2020-04-22 Thread Florian Weimer
* Jerry James: > On Wed, Apr 22, 2020 at 6:01 AM Richard W.M. Jones wrote: >> It turns out it comes from dune (the build tool), although I'm still >> unclear how and why. In any case I added a rather hacky workaround so >> I can get the build going again: > > No, it isn't dune; it's ocaml

Re: What CPU extensions can we assume are available by arch?

2020-04-22 Thread Florian Weimer
* Dominik Mierzejewski: > If upstream doesn't support runtime selection of SIMD-optimized code > paths based on CPU capabilities, you can build several versions and > have glibc handle that by putting each version in a special subdirectory > of /usr/lib64, e.g.: > /usr/lib64/haswell >

Re: What CPU extensions can we assume are available by arch?

2020-04-22 Thread Florian Weimer
* Peter Robinson: >> > What about VSX on ppc64le? >> >> Yes, but only the parts that are in POWER8. > > We on;y support POWER8 and later in Fedora for ppc64le. Yes, that's what I meant: you cannot assume POWER9 or -mfuture. (There is nothing earlier than POWER8 for ppc64le anyway, some earlier

Re: What CPU extensions can we assume are available by arch?

2020-04-22 Thread Florian Weimer
* Richard Shaw: > I'm working on packaging a project that makes use of AVX/AVX2/NEON to process > and > improve the quality of low bitrate human speech: > > https://github.com/mozilla/LPCNet > > I'm having trouble determining what the base CPU targets for Fedora can > accommodate. > > For

Re: will disappear from rawhide glibc soon

2020-04-18 Thread Florian Weimer
* Ron Olson: > Already fixed it and sending it to Rawhide now. Have you submitted the fix upstream? Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Matthew Miller: > On Thu, Apr 16, 2020 at 07:27:29PM +0200, Lennart Poettering wrote: >> > If there are no servers configured... Shouldn't it use no servers? >> Well, our assumption is that working DNS is better than DNS that >> doesn't work. > > I hope no one is using lack of configured DNS as

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering: > On Do, 16.04.20 17:14, Florian Weimer (fwei...@redhat.com) wrote: > >> > I don't think we can reliably determine whether people have deployed >> > things in a way that relies on /etc/resolv.conf only listing a fully >> > blown DNS ser

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Tomas Mraz: > On Wed, 2020-04-15 at 10:02 -0500, Michael Catanzaro wrote: >> On Wed, Apr 15, 2020 at 1:38 pm, Florian Weimer >> wrote: >> > Not sure if that's compatible with the new split DNS model because >> > VPN1 >> > could simply start pushi

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering: > On Do, 16.04.20 12:49, Florian Weimer (fwei...@redhat.com) wrote: > >> As explained elsewhere, NetworkManager-openvpn extracts the search list >> from OpenVPN parameters, passes that to NetworkManager, which I expect >> will pass ito to system

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering: > On Do, 16.04.20 12:53, Florian Weimer (fwei...@redhat.com) wrote: > >> > Meh. I mean /etc/resolv.conf here, of course, not /etc/nsswitch.conf. >> >> So if /etc/resolv.conf comes from somewhere else, then nss_resolve will >> still for

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Zbigniew Jędrzejewski-Szmek: > On Thu, Apr 16, 2020 at 12:53:48PM +0200, Florian Weimer wrote: >> * Lennart Poettering: >> >> > On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote: >> > >> >> On Mi, 15.04.20 15:

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering: > On Mi, 15.04.20 16:30, Lennart Poettering (mzerq...@0pointer.de) wrote: > >> On Mi, 15.04.20 15:50, Florian Weimer (fwei...@redhat.com) wrote: >> >> > * Lennart Poettering: >> > >> > > 1. If /etc/resolv.conf is a regular fi

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Michael Catanzaro: > On Wed, Apr 15, 2020 at 10:48 am, Florian Weimer > wrote: >> The second Kubernetes issue I worry about [1] is that the CoreDNS name >> server is installed first, and it does additional rule-based >> processing >> for in-cluster names. Externa

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Florian Weimer
* Lennart Poettering: > Long story short: if you experienced issues with DNSSEC on with > resolved today, then be assured that with DNSSEC off things are much > much better, and that's how we'd ship it in Fedora if it becomes the > default. Would you please clarify what switching DNSSEC off

Re: buildroot problems on rawhide i386, armv7hl ??

2020-04-15 Thread Florian Weimer
* Vít Ondruch: > Is this problem back? > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=43439516 > > https://koji.fedoraproject.org/koji/taskinfo?taskID=43439614 Yeah, sorry, I made a mistake, rebuilding with the broken source tarball. I realized my mistake as soon as I received mail

will disappear from rawhide glibc soon

2020-04-15 Thread Florian Weimer
This follows the removal of the system call from Linux 5.5. Having the header and function just confuses configure checks that assume that if the function is present, it will do something useful (it never did on aarch64, and it's been many years since it worked on Fedora kernels on other

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Michael Catanzaro: > On Wed, Apr 15, 2020 at 9:36 am, Florian Weimer > wrote: >> And we really need to move /etc/nsswitch.conf out of glibc. We spend >> some time on maintaining that file, when in fact it doesn't matter >> because too many scriptlets and progr

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Lennart Poettering: > On Mi, 15.04.20 10:09, Michael Catanzaro (mcatanz...@gnome.org) wrote: > >> You're right that continuing to use nss-dns would avoid any such problems >> while maintaining the other benefits of systemd-resolved. That could be a >> fallback plan if needed. > > So, it is my

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Lennart Poettering: > On Mi, 15.04.20 09:36, Florian Weimer (fwei...@redhat.com) wrote: > >> * Michael Catanzaro: >> >> > On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek >> > wrote: >> >> I guess the lesson here is the nsswitch.conf

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Lennart Poettering: > 1. If /etc/resolv.conf is a regular file, resolved will *consume* it >for DNS configuration, and never change it or modify it or replace >it. If this mode is selected arbitrary other programs that do DNS >will talk directly to the provided DNS servers, and

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Tom Hughes: > I'm not sure OpenVPN itself has any way to do DNS setup automatically > on linux but the NetworkManager integration might, I don't use that > though. Yes, the NetworkManager integration seems to mirror what happens on Windows, by looking at the foreign_option_* environment

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Tom Hughes: >· Single-label names are routed to all local interfaces capable of IP >multicasting, using the LLMNR protocol. Lookups for IPv4 addresses >are only sent via LLMNR on IPv4, and lookups for IPv6 addresses are >only sent via LLMNR on IPv6.

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Tom Hughes: > On 15/04/2020 09:08, Florian Weimer wrote: > >> I cannot find documentation of the systemd stub resolver behavior: how >> it handles search list processing, and how it decides which upstream >> name servers to query. > > As I understand the

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Ben Cotton: > Enable systemd-resolved by default. glibc will perform name resolution > using nss-resolve rather than nss-dns. Is this intended for Fedora Server and others as well, or just Workstation? I assume it's for everywhere. > systemd-resolved has been enabled by default in Ubuntu

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-04-15 Thread Florian Weimer
* Michael Catanzaro: > On Tue, Apr 14, 2020 at 8:48 pm, Zbigniew Jędrzejewski-Szmek > wrote: >> I guess the lesson here is the nsswitch.conf change should be >> clarified in the proposal. > > OK, I've just added it at the end of this part here: > > "systemd-libs currently has >

Re: The Chromium Dilemma

2020-04-15 Thread Florian Weimer
* Omair Majid: > (I was secretly hoping there was a way to bump rlim_cur past > the current value of rlim_max...) Current Fedora seems to set the hard limit to at least 4096 for all processes. Isn't that enough? Thanks, Florian ___ devel mailing list

Re: The Chromium Dilemma

2020-04-14 Thread Florian Weimer
* Omair Majid: > Florian Weimer writes: > >> * Jan Kratochvil: >> >>> gold is also limited by 'ulimit -S -n', I had to raise it while building >>> LLDB >>> (using -DLLVM_USE_LINKER=gold). >> >> gold should either do this upon start (l

Re: The Chromium Dilemma

2020-04-14 Thread Florian Weimer
* Jan Kratochvil: > On Mon, 13 Apr 2020 18:43:07 +0200, Tom Callaway wrote: >> The linker said: error adding symbols: Malformed archive. Searching leads >> me to translate that error to "too many open files". See: >> https://github.com/OSSystems/meta-browser/issues/194 >> >> Apparently, gold

Re: buildroot problems on rawhide i386, armv7hl ??

2020-04-09 Thread Florian Weimer
Sorry about your troubles. I have identified the problematic upstream change, and we will cease rawhide updates of glibc until that issue is fixed. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

  1   2   3   4   5   6   7   8   9   10   >