Re: Red Hat & Fedora -- largely stepping out of this ecosystem

On 6/26/23 18:47, Jeff Law wrote: What Red Hat has done may be technically legal and perhaps good for its business. Something I'm having trouble with is Red Hat's position that you can choose to be a customer or to exercise your rights under the GPL, but you cannot be both. The thing is,

Re: Retiring the pcre package from Fedora

Due to static linking, not all functions will be included in the executable and therefore some simple "hello world" binaries will not need sysprof-capture-static. However, anything that used the .pc file will need it. Technically, you could also use glib's static library without dependent .a

Re: Retiring the pcre package from Fedora

On Tue, Jul 26, 2022 at 10:10 AM Kalev Lember wrote: > Does this look right to you? Do you want me to add them in other > branches as well or is rawhide sufficient for now? Rawhide is enough, for other branches QEMU is working around it by requiring pcre-static. Thanks! I'm now debugging the

Re: Retiring the pcre package from Fedora

On 7/24/22 15:42, Kalev Lember wrote: On Sun, Jul 24, 2022 at 8:58 AM Paolo Bonzini <mailto:pbonz...@redhat.com>> wrote: Il sab 23 lug 2022, 19:12 Adam Williamson mailto:adamw...@fedoraproject.org>> ha scritto: This of course begs a question: did qemu

Re: Retiring the pcre package from Fedora

Il sab 23 lug 2022, 19:12 Adam Williamson ha scritto: > This of course begs a question: did qemu also have a non-static pcre > requirement at the time? But it seems not: > > [adamw@xps13k qemu (f36 %)]$ git show 0835325:qemu.spec | grep pcre > BuildRequires: glibc-static pcre-static glib2-static

Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On 1/21/22 13:47, Richard W.M. Jones wrote: On Fri, Jan 21, 2022 at 01:30:38PM +0100, Paolo Bonzini wrote: On 1/21/22 10:49, Richard W.M. Jones wrote: Yes that works! Are you going to make the change? (For all of the QEMU firmware packages---edk2, openbios, seabios in addition to SLOF

Re: ppc64le: SLOF failed to rebuild: error: unrecognized argument in option '-mtune=generic'

On 1/21/22 10:49, Richard W.M. Jones wrote: Yes that works! Are you going to make the change? (For all of the QEMU firmware packages---edk2, openbios, seabios in addition to SLOF---since you are at it). Paolo ___ devel mailing list --

Re: gcc-12.0.0-0.4.fc36 in rawhide

On 1/17/22 12:32, Jakub Jelinek wrote: Perhaps Paolo Bonzini is familiar with both qemu and gcc... /me waves hands. This is now https://gcc.gnu.org/PR104067. Paolo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email

Re: seabios / seabios-bin split in Fedora - why?

On 08/08/19 16:14, Richard W.M. Jones wrote: > I'm trying to package OpenSBI RISC-V firmware for Fedora > (https://github.com/riscv/opensbi). It's a similar situation to > SeaBIOS and other architecture firmware. We have to cross-compile a > binary on potentially any Koji architecture, and end

Re: Orphaned packages looking for new maintainers

On 03/06/19 16:18, Miro Hrončok wrote: > > ipxe (maintained by: berrange, bonzini, crobinso, virtmaint-sig) >     ipxe-20190125-1.git36a4c85f.fc30.src requires mtools = > 4.0.18-16.fc30, syslinux = 6.04-0.8.fc28 I'll take a look at removing the dependency. Paolo

Re: Orphaned packages that will be retired

On 25/02/19 21:49, Miro Hrončok wrote: > bonzini: plexus-utils I have no idea what this is and how I became the maintainer. :) Paolo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 13/02/19 14:31, Richard W.M. Jones wrote: > Isn't the assembler syntax different or does gas now support > the nasm syntax (and macros plus a bunch of other stuff AIUI)? > If we require gas then I assume a whole bunch of asm would have > to be rewritten ... Indeed, for example edk2 used to

Re: Orphaned packages that will be retired (and everything will most likely burn)

On 11/02/19 17:57, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure > that the package should be retired, please do so now with a proper reason: >

[HEADS-UP] libiscsi soname bump

I've updated libiscsi in Rawhide to 1.18.0, soname is now version 8. QEMU is the only dependent package and I'll rebuild it soon. Paolo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to

Re: i386 Xen PV support still needed?

On 01/08/2017 23:38, Dominik 'Rathann' Mierzejewski wrote: > On Tuesday, 01 August 2017 at 14:19, Florian Weimer wrote: >> We still build a special glibc variant for Xen which avoids certain >> segment-relative accesses which are difficult to emulate with >> paravirtualization.. >> >> Is this

[EPEL-devel] Re: Recoll for EPEL ?

On 25/04/2017 16:03, Stephen John Smoogen wrote: > On 25 April 2017 at 04:28, Jean-Francois Dockes wrote: >> Hi, >> >> My apologies in advance if this is the wrong place. >> > > No this is as good as any. The package looks to be branched for EPEL > by pbonzini who I have cc'd

Re: future of official optical media support in Fedora

On 06/12/2016 18:11, Adam Williamson wrote: > On Tue, 2016-12-06 at 15:00 +, Marcin Juszkiewicz wrote: >> W dniu 06.12.2016 o 14:43, Kamil Paral pisze: >> >>> All of that is, of course, motivated by trying to spend QA time more >>> effectively. You can see the current coverage e.g. in this

Non-responsive maintainer: ke4qqq

Hi, I have been trying to contact user ke4qqq (David Nalley) about sheepdog (which is years out of date and, anyway, segfaults out of the box). I opened https://bugzilla.redhat.com/show_bug.cgi?id=1396430 on November 18th according to the non-responsive package maintainer policy. I also

Re: Missing qemu deps on ppc64le

On 10/10/2016 16:53, Marcin Juszkiewicz wrote: > W dniu 10.10.2016 o 16:34, Paolo Bonzini pisze: >> On 10/10/2016 13:30, Sandro Bonazzola wrote: > >>> just seen: >>> DEBUG util.py:421: Error: Package: >>> 2:qemu-system-aarch64-2.6.1-1.fc24.

Re: Missing qemu deps on ppc64le

On 10/10/2016 13:30, Sandro Bonazzola wrote: > Hi, > just seen: > DEBUG util.py:421: Error: Package: > 2:qemu-system-aarch64-2.6.1-1.fc24.ppc64le (updates) > DEBUG util.py:421: Requires: edk2-aarch64 > DEBUG util.py:421: Error: Package: > 2:qemu-system-x86-2.6.1-1.fc24.ppc64le

Re: RFC: static builds for user emulators in Fedora QEMU RPMs

On 29/06/2016 16:27, Simo Sorce wrote: >> > symlink: /usr/lib/qemu-user-root -> / >> > dir: /usr/lib/qemu-user-host-lib >> > symlink: /usr/lib/qemu-user-host-lib/libc.so -> >> > /usr/lib/qemu-user-root/lib/libc.so >> > >> > And build qemu-$ARCH with rpath to /usr/lib/qemu-user-root/lib.

libiscsi 1.15.0 soname bump

The only dependent package is QEMU. I'll do the QEMU build today as well. Paolo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: GCC 5 compatibility problems: GCC 4.10?

On 11/05/2015 15:44, Jakub Jelinek wrote: I bet it is the linux/include/compiler*.h stuff. In any case, supposedly you can just use gcc -U__GNUC__ -U__GNUC_MINOR__ -U__GNUC_PATCHLEVEL__ -D__GNUC__=4 -D__GNUC_MINOR__=10 -D__GNUC_PATCHLEVEL__=0 instead of gcc, you don't need any hacks for

Re: GCC 5 compatibility problems: GCC 4.10?

On 20/06/2015 10:27, Paolo Bonzini wrote: On 11/05/2015 15:44, Jakub Jelinek wrote: I bet it is the linux/include/compiler*.h stuff. In any case, supposedly you can just use gcc -U__GNUC__ -U__GNUC_MINOR__ -U__GNUC_PATCHLEVEL__ -D__GNUC__=4 -D__GNUC_MINOR__=10 -D__GNUC_PATCHLEVEL__=0

Re: GCC 5 compatibility problems: GCC 4.10?

On 09/05/2015 05:34, Rex Dieter wrote: I'm encountering a few problems with GCC 5 due to code that fails to work with GCC major releases above 4. In particular, there are at least problems with the kernel fedora's kernel builds, can you be more specific about the problems you're

GCC 5 compatibility problems: GCC 4.10?

Hi all, I'm encountering a few problems with GCC 5 due to code that fails to work with GCC major releases above 4. In particular, there are at least problems with the kernel and with Coverity. Unfortunately, downgrading to Fedora 21's GCC 4.9 is very hard in Fedora 22, unless you only care

Re: [Fedora-packaging] bundling of jemalloc

On 21/03/2015 20:00, Niels de Vos wrote: On Sat, Mar 21, 2015 at 02:31:03PM +0100, Paolo Bonzini wrote: Firefox and xulrunner are bundling their own copy of jemalloc (try strings /usr/lib64/xulrunner/xulrunner |grep jemalloc, or similarly with /usr/lib64/firefox/firefox-bin). Why isn't

bundling of jemalloc

Firefox and xulrunner are bundling their own copy of jemalloc (try strings /usr/lib64/xulrunner/xulrunner |grep jemalloc, or similarly with /usr/lib64/firefox/firefox-bin). Why isn't this recorded in the RPM provides (and why is there no mention of jemalloc in

Re: kvm: vcpu unhandled rdmsr:

On 19/12/2014 22:56, poma wrote: cpu mode='host-model' model fallback='allow'/ /cpu host-model is buggy (I'd say a failed experiment). Can you try host-passthrough? That said, crashing the host is not something that should happen. Can you get a vmcore or at least an abrt report?

Re: kvm: vcpu unhandled rdmsr:

On 19/12/2014 16:44, poma wrote: Mister Bonzini, what are these errors? They are harmless. Typically it means that the VM is trying to access registers for performance counters or machine check exceptions. Instead, this: [ 125.880384] kvm: zapping shadow pages for mmio generation

Re: Dash as default shell

Il 02/10/2014 11:04, Zdenek Kabelac ha scritto: It used to give significant boost for automake libtool based software - however at some point libtool started to use bashisms and so you cannot just replace /bin/sh - dash - as build will fail. This is wrong. libtool detects whether you can

Re: Dash as default shell

Il 04/10/2014 18:17, Zdenek Kabelac ha scritto: And yes - with UsrMove we lost distinction between what are system tools and what are usr tools. What you call system tools is simply the content of the initramfs. Paolo -- devel mailing list devel@lists.fedoraproject.org

Re: New Group Calls For Boycotting Systemd

Il 07/09/2014 20:04, Reindl Harald ha scritto: on http://comments.gmane.org/gmane.linux.redhat.fedora.devel/199113 *you* complain about systemd-readahead - guess what - if a virtual machine is detected it is skipped And why is it a good idea to skip it on a virtual machine? Paolo -- devel

Re: HEADSUP: json-c SONAME BUMP

Il 28/07/2014 18:02, Miloslav Trmač ha scritto: No, that would completely defeat the point of the soname. If upstream won’t use sonames or symbol versioning, it’s better for Fedora to patch the software to use them properly, even if it means having to continue to patch it. IIRC we do have

Re: fedoras default cflags clang

Il 30/05/2014 11:03, Jakub Jelinek ha scritto: Many folks like to use clang as their primary compiler for various reasons, is there anyone who knows a workaround or fix? I think FPC (and/or FESCO) should decide on whether we want to allow/disallow using clang for official Fedora rpms.

Re: F21 System Wide Change: BerkeleyDB 6

Il 24/04/2014 16:50, Kevin Fenzi ha scritto: Well, in the current plan (make libdb5 compat package and updating the libdb to v6), after the mass rebuild the packages would start using v6. Yeah, which makes technical sense... but the concern is packagers who aren't paying attention rebuild

Re: RFC - Downgrade BlueZ to v4.101 in Fedora 20

Il 24/01/2014 14:05, David Sommerseth ha scritto: FWIW, the HFP/HSP support is missing in PulseAudio, not in BlueZ for F20. Can you please shed some more light on this. From what I could grasp out of the freedesktop bug, it was a bluez bug. And PulseAudio says bluez4 is needed to get the

Re: [HEADS UP] libtool + %global _hardened_build 1 = no full hardening

Il 26/06/2013 17:39, Björn Esser ha scritto: # dirty hack to force immediate binding with hardenend build having # autocrap's libtool pass the need gcc-specs to linker. sed -i -e 's! \\\$compiler_flags !\\\$CFLAGS \\\$LDFLAGS !' libtool Weird, I didn't see any mention of this on the autocrap's

Re: Fwd: Thursday is Spice Test Day!

Il 31/05/2013 17:04, poma ha scritto: On 31.05.2013 16:34, Richard W.M. Jones wrote: On Fri, May 31, 2013 at 04:20:00PM +0200, poma wrote: In addition to your method, 'qemu-kvm -sdl' is only able to produce Could not initialize SDL(No available video device) - exiting despite guidance at

Re: git rebase master

Il 27/05/2013 23:11, Adam Williamson ha scritto: As soon as your f19 build diverges from master at all, merging becomes inappropriate (and probably impossible) and you should instead use 'cherry-pick'. It helps to have at least a vague overview of how git is designed to be used, and what is

Re: Arduino firmware permissible to include?

Il 23/05/2013 15:25, Peter Oliver ha scritto: Arduino is an electronics prototyping board, and also a GNU GPL2-licenced IDE for writing and uploading code to such boards. Fedora has packages for the IDE. Recent versions of the IDE include WiFi firmware for Arduino

Re: when startup delays become bugs

Il 15/05/2013 05:43, Adam Williamson ha scritto: On Tue, 2013-05-14 at 15:51 -0600, Chris Murphy wrote: But firewalld goes from 7 seconds to 18 seconds? Why? avahi-daemon, restorecond, all are an order of magnitude longer on F19 than F18. It's a 3+ minute userspace hit on the startup time

Re: F19 DVD over size - what to drop?

Il 02/05/2013 18:08, Chris Murphy ha scritto: On May 2, 2013, at 6:40 AM, Bruno Wolff III br...@wolff.to wrote: This is pretty much what happened with CD images. Eventually this will change, but it isn't clear to me that this is the right time to make that change. CentOS 6 uses two DVD

Re: Expanding the list of Hardened Packages

Il 29/03/2013 23:10, Richard W.M. Jones ha scritto: Qemu is surely a good candidate for this. Although it's not network- accessible, it is accessible from the guests that it runs via its huge and ill-specified surface of emulated devices. I'm running my own modified qemu package

Re: Expanding the list of Hardened Packages

Il 04/04/2013 04:05, Josh Bressers ha scritto: On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb sgr...@redhat.com mailto:sgr...@redhat.com wrote: On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote: On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb sgr...@redhat.com

Re: the need of Offline Updates

Il 05/02/2013 16:58, Reindl Harald ha scritto: 2) Modern Windows updates are safer than RPM, speaking broadly jokingly? show me a upgrade of production machines from F9 to F17 without end in a inconsistent system on windows - you can't, i have been there windows is missing anything like

Re: Proposed F19 Feature: Virtio RNG

Il 02/02/2013 14:49, Björn Persson ha scritto: Paolo Bonzini wrote: If you're talking about RDRAND, it doesn't hand out entropy. That's RDSEED, which will only come with Haswell. RDRAND only hands out random numbers. Huh? Random numbers is pretty much synonymous to entropy

Re: Proposed F19 Feature: Virtio RNG

Il 02/02/2013 00:40, Matthew Garrett ha scritto: This patchset means that there's a /dev/hwrng available in the guest, so you still need to run something like rngd to mix that into the kernel's entropy pool. You're right that the total amount of entropy is still limited to that available on

Re: libcacard can never be installed

Il 29/01/2013 10:03, Richard W.M. Jones ha scritto: On Tue, Jan 29, 2013 at 08:57:11AM +, Peter Robinson wrote: On Tue, Jan 29, 2013 at 8:52 AM, Richard W.M. Jones rjo...@redhat.com wrote: I have a filed a bug about this: https://bugzilla.redhat.com/show_bug.cgi?id=905345 libcacard can

Problems with Automake 1.13 and 1.13.1

As of the original 1.13 release two macros where removed from Automake: AM_PROG_CC_STDC (replaced by AC_PROG_CC as provided by autoconf) and AM_CONFIG_HEADER (replaced by AC_CONFIG_HEADERS). These were later reintroduced in 1.13.1, but not with the original behavior---they just give an error

Re: Problems with Automake 1.13 and 1.13.1

Il 14/01/2013 16:10, Stephen Gallagher ha scritto: Choices are: 1) introducing automake-1.12: I believe distros should agree on _not_ introducing an automake-1.12 or similar package and get the Automake maintainer to fix his mess. 2) fixing all packages individually: sounds like a