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

[Paolo Bonzini]

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, many people are learning this only now, because things 
indeed have become tougher for people who prepare the RHEL rebuilds, but 
this is not new.  _Nothing_ in the service agreement or in any other 
legal document has changed since last week, the exact same terms have 
been applicable to the extended-support branches since the beginning of 
RHEL.  In fact, as Frank pointed out elsewhere, this is something that 
other companies have been doing for decades as well.


For all the people that are complaining only now that the free beer part 
is taken away, I can't help thinking that it's a bit disingenuous to 
make it about "free as in freedom", when that clause has existed forever.


(As an aside, the service agreement also mentions that any open source 
license overrides the service agreement if needed.  So by definition 
this might be void but it certainly is not a GPL violation).


Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

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
libraries if you link with glib's .a file but do not specify -static; but
that's not a good argument against having a Requires for the dependency in
my opinion, because it makes the .pc file not work out of the box. Perhaps
a weak dependency, but even that sounds strange.

As to glibc-static I think it's fair to say that whoever uses -static will
have to install it on their own, so it can be left out of glib2.spec.

Paolo


Il mar 26 lug 2022, 10:59 Daniel P. Berrangé  ha
scritto:

> Although listed in glib-2.0.pc, I didn't find any need for the
> sysprof-capture-static package, but it does need glibc-static
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

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 SIGABRT in file(1).

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

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

so, I'm not sure why Daniel concluded this needs a BuildRequires on
pcre-static, but the obvious thing to do would be to ask him, I
guess.


I think it could have been a missing requires of glib2-static,
because glib does use PCRE and therefore has it in the linker flags
for a static build. I will check next time I am at a computer.


glib2 switched to pcre2 in rawhide recently. Can you check if qemu needs 
to be updated for that now so that it BuildRequires pcre2-static instead?


Yep, that works.  I still think that pcre2-static and 
sysprof-capture-devel belong in glib2's spec file though, but I 
committed that as a stopgap measure.


Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Retiring the pcre package from Fedora

[Paolo Bonzini]

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 zlib-static
>
> so, I'm not sure why Daniel concluded this needs a BuildRequires on
> pcre-static, but the obvious thing to do would be to ask him, I guess.
>

I think it could have been a missing requires of glib2-static, because glib
does use PCRE and therefore has it in the linker flags for a static build.
I will check next time I am at a computer.

Paolo

-- 
> Adam Williamson
> Fedora QA
> IRC: adamw | Twitter: adamw_ha
> https://www.happyassassin.net
>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Paolo Bonzini]

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---since you
are at it).


However edk2 has other problems revealed probably by GCC 12, see:
https://kojipkgs.fedoraproject.org//work/tasks/4195/81484195/build.log


A valid warning, perhaps slightly overzealous depending on how Error is defined:

GenSec.c:1065:5: error: pointer used after 'fclose' [-Werror=use-after-free]
 1065 | Error(NULL, 0, 4001, "Resource", "memory cannot be allocated  of 
%s", InFileHandle);
  | 
^~~
GenSec.c:1064:5: note: call to 'fclose' here
 1064 | fclose (InFileHandle);
  | ^

But it seems more likely that the bug is real.  Maybe that %s should be %p,
or the function call is bogus in some other way.


openbios has a segfault somewhere during the FORTH bootstrap:
https://kojipkgs.fedoraproject.org//work/tasks/6090/81556090/build.log
I was not able to reproduce this one locally.


I would try reproducing with -O0 first.  It might be a dup of the QEMU bug
https://gcc.gnu.org/PR104067, even.  It's a problem with loop optimizations,
so it could be the kind of thing that can wreak havoc on a FORTH interpreter!
Once the fix for PR104067 hits Fedora, if it's not fixed I can take a look.

Thanks,

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Paolo Bonzini]

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 -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: gcc-12.0.0-0.4.fc36 in rawhide

[Paolo Bonzini]

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 to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

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

[Paolo Bonzini]

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 up with a noarch
> package, because the final firmware blob can be installed on any
> architecture too.
> 
> Here's my initial attempt:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=36861731
>   http://oirase.annexia.org/reviews/opensbi/opensbi.spec
> 
> I needed to use %global _binaries_in_noarch_packages_terminate_build 0
> to stop RPM complaining about:
> 
>   error: Arch dependent binaries in noarch package
> 
> SeaBIOS uses the same workaround:
> 
>   https://src.fedoraproject.org/rpms/seabios/blob/master/f/seabios.spec
> 
> But also it builds an empty seabios package and then builds the binary
> into seabios-bin.  Does anyone remember why that was needed?

It's just backwards compatibility.  seabios is a noarch package because
you can use it to run emulated x86 virtual machines on non-x86
architectures.  At the same time, we wanted the build to happen on an
x86 machine so that was done via the empty package + ExclusiveArch.

Fedora builds of seabios and other firmware support cross compilation
these days though, so you don't need the hack anymore.  You only need to
allow arch dependent binaries in noarch packages.  Also, please install
the binaries in /usr/share, not /usr/lib.

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages looking for new maintainers

[Paolo Bonzini]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaned packages that will be retired

[Paolo Bonzini]

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 devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Paolo Bonzini]

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 have separate source files for masm and
gas (yuck) and has standardized on nasm a few years ago.  If binutils
can support nasm syntax, I'd be happy to use it of course.

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Paolo Bonzini]

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:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
> 
> Note: If you received this mail directly you (co)maintain one of the
> affected
> packages or a package that depends on one. Please adopt the affected
> package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
> 
> See this in your web browser or curl it at:
> 
> https://churchyard.fedorapeople.org/orphans-2019-02-11.txt
> 
> Please grep it for your username.

I can maintain nasm if no one else wants to take it.

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[HEADS-UP] libiscsi soname bump

[Paolo Bonzini]

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 devel-le...@lists.fedoraproject.org

Re: i386 Xen PV support still needed?

[Paolo Bonzini]

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 still needed?  Can we drop it?
> What is the performance difference between running a regular glibc under
> Xen vs. this special one? I believe there may still be some value in
> running Fedora in a Xen i686 guest VM.

The performance difference was very significant, though like others I
cannot really give a figure.

However, it only applied if you were running in a 32-bit hypervisor.  I
think this set up is pretty much dead.  Even though Amazon and others
are using Xen and are still running paravirtualized guests, they're
using 64-bit hypervisors.  CCing Vitaly for confirmation.

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] Re: Recoll for EPEL ?

[Paolo Bonzini]

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 on this.  [They may have branched after
> you sent this email or maybe a while before.. I don't know.] So it
> looks like it is in progress of occurring

I initially packaged recoll for EPEL6 as a favor to a colleague of mine
that was using RHEL6 at the time.  I have never upgraded the package to
RHEL7, but I can do that if there is request.  I've now requested
creation of the EPEL7 branch.

Thanks,

Paolo

>> I am the developper for Recoll, a full-text search application, which has
>> been packaged for Fedora for a long time.
>>
>> I have a small but steady rivulet of users asking for CentOS or Enterprise
>> Linux Recoll packages. In consequence, there are some CentOS 7 packages on
>> the Recoll web site. It would be easier for the users and and for me if the
>> Fedora package was maintained for EPEL instead.
>>
>> Any possibility that this could happen ?
>>
>> Cheers,
>>
>> J.F. Dockes
>>
>> ___
>> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
>> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> 
> 
> 
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: future of official optical media support in Fedora

[Paolo Bonzini]

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 table [2],
>>> overall we burn 6 DVDs and perform 12 optical installation (BIOS +
>>> UEFI) for every release candidate published. We allow non-complete
>>> (yet still substantial) coverage for Alpha and Beta, but 100%
>>> coverage for Final for each candidate compose. That is quite time
>>> consuming, both burning and installation from optical media take a
>>> long time, it requires bare metal testing, and we can't use the
>>> machines for anything else during that time.
>>
>> Why not boot VM with virtual optical drive? You can choose BIOS/UEFI,
>> 32/64bit and do not require bare metal hardware for it.
> 
> It's not a sufficient test. We have had real bugs in the past where a
> VM would boot from an ISO image, but real systems would not boot from
> the same ISO image burned to a real optical disc.
> 
> Virtual machines are great for convenience, but they are not real
> hardware and we cannot in good conscience release our product without
> testing it on real machines with real media.

It's still a good test to do.  For example, Server and netinst ISO
images are used a lot for VMs, but not for bare metal.

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Non-responsive maintainer: ke4qqq

[Paolo Bonzini]

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 requested package ownership but did not get any answer.

He seems to be somewhat active on Twitter, but his last commit to a
Fedora package is from 2012 and, since then, the packages have only been
updated for mass rebuilds.

If someone knows how to get in touch with David, please let me know how.
 Otherwise, in 1 week I will open a FeSCo ticket to take over sheepdog.

Thanks,

Paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Missing qemu deps on ppc64le

[Paolo Bonzini]

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.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 (updates)
>>> DEBUG util.py:421: Requires: edk2-ovmf
>>>
>>> While installing qemu on ppc64le Fedora.
>>> Any ETA on fixing it?
>>
>> The reason for this is documented in edk2.spec.
>>
>> # actual firmware builds support cross-compiling.  edk2-tools
>> # in theory should build everywhere without much trouble, but
>> # in practice the edk2 build system barfs on archs it doesn't know
>> # (such as ppc), so lets limit things to the known-good ones.
>> ExclusiveArch:  %{ix86} x86_64 %{arm} aarch64
>>
>> I suppose that QEMU should not require edk2 on architectures other than
>> ARM and x86.
> 
> edk2-* packages are noarch. Secondary architectures should imho import
> built binary packages into repository.

It's still a hack to require specific arches to build noarch packages.
For the most important firmware packages (seabios, OVMF, SLOF), we use
cross-compilation so that secondary architectures just work.  Some
packages are missing and relying on the firmware exception, but that
should not be done when possible.

The case of edk2 is ugly because the build tools (not the firmware)
require specific architectures.  I guess we could easily port them to
PPC64LE, but s390 would still be a mess because they have no testsuite,
unlike for example the ACPI tools where the testsuite helped developing
patches for big-endian support (initially based on Debian and then
fixing things as they came up).

Paolo

> Qemu allows you to emulate several architectures on many architectures -
> basically any Fedora supported one (primary or secondary) on any of them.
> qemu-system-{x86,aarch64,arm,x86-64} may use UEFI binary to run VM.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Missing qemu deps on ppc64le

[Paolo Bonzini]

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 (updates)
> DEBUG util.py:421: Requires: edk2-ovmf
> 
> While installing qemu on ppc64le Fedora.
> Any ETA on fixing it?

The reason for this is documented in edk2.spec.

# actual firmware builds support cross-compiling.  edk2-tools
# in theory should build everywhere without much trouble, but
# in practice the edk2 build system barfs on archs it doesn't know
# (such as ppc), so lets limit things to the known-good ones.
ExclusiveArch:  %{ix86} x86_64 %{arm} aarch64

I suppose that QEMU should not require edk2 on architectures other than
ARM and x86.

paolo
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Paolo Bonzini]

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.
>> > 
>> > Then in the chroot you would need to bind mount the host root into
>> > /usr/lib/qemu-user-root, to override the symlink that would otherwise
>> > point back to /
> Why do you need 2 symlinks ?
> 
> I was thinking you'd have
> symlink: /usr/lib/qemu-user-lib-x86_64/ -> /usr/lib
> 
> In the chroot you just bind mount the host's /usr/lib
> as  /usr/lib/qemu-user-lib-x86_64
> 
> This assuming x86-64, you can bind mount in the appropriate arch-target
> dir on other arches.
> 

This only works if all symlinks in /usr/lib are relative.  Even then,
there are some cases where /usr/lib/foo.so symlinks to
../../lib/foo.so.1, so you'd need to:

1) bind-mount /usr/lib into /usr/lib/qemu-user-root/usr/lib

2) create a symlink /usr/lib/qemu-user-root/lib to
/usr/lib/qemu-user-root/usr/lib.

It seems a bit brittle.
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

libiscsi 1.15.0 soname bump

[Paolo Bonzini]

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?

[Paolo Bonzini]

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 that from the distro.

For Coverity I used this wrapper instead:

#! /bin/bash
case $* in
   *--version*|*--help*) $@  | sed 's,version 5\.1,version 4\.10,g' ;;
   *) $@ 2 (sed 's,version 5\.1,version 4\.10,g') ;;
esac

either directly or through CCACHE_PREFIX.

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?

[Paolo Bonzini]

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
 instead of gcc, you don't need any hacks for that from the distro.
 
 For Coverity I used this wrapper instead:
 
 #! /bin/bash
 case $* in
*--version*|*--help*) $@  | sed 's,version 5\.1,version 4\.10,g' ;;
*) $@ 2 (sed 's,version 5\.1,version 4\.10,g') ;;
 esac
 
 either directly or through CCACHE_PREFIX.

Hmm, nope.  It cannot find headers in /usr/lib.  I guess I'll build a
4.10-hacked GCC myself.

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?

[Paolo Bonzini]

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

Kernels older than 3.18 don't build, which is a pain if you're bisecting
a kernel bug introduced before 3.18.

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

GCC 5 compatibility problems: GCC 4.10?

[Paolo Bonzini]

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 about the C compiler.  This is because the C++
compiler wants a matching libstdc++, and most C++ packages need the GCC
5 libstdc++ (maybe because of the ABI changes, I don't know).

Is it outrageous to ask for a compatibility GCC package that declares
itself as 4.10?  This is similar to how kernel 3.0 was initially
packaged as 2.6.40.  Or perhaps there is another possibility that I
haven't thought of?

Thanks,

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: [Fedora-packaging] bundling of jemalloc

[Paolo Bonzini]

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 this recorded in the RPM provides (and why is there no mention
 of jemalloc in
 http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries)?  Are
 there any other known cases outside Mozilla products?  I found bug
 788500 about unbundling jemalloc from redis.
 
 If jemalloc would be its own package, we would probably use that for 
 nfs-ganesha too. Currently glibc/malloc is used, but jemalloc is well 
 tested by the nfs-ganesha community and could have some benefits. I have 
 not checked the sources of jemalloc, so I can not say if I would be 
 a suitable maintainer for it.

nfs-ganesha is already using jemalloc, repoquery says:

$ repoquery --whatrequires 'libjemalloc.so.1()(64bit)'
...
nfs-ganesha-0:2.1.0-11.fc21.x86_64
nfs-ganesha-fsal-ceph-0:2.1.0-11.fc21.x86_64
nfs-ganesha-fsal-gluster-0:2.1.0-11.fc21.x86_64
...

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

bundling of jemalloc

[Paolo Bonzini]

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
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries)?  Are
there any other known cases outside Mozilla products?  I found bug
788500 about unbundling jemalloc from redis.

Thanks,

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: kvm: vcpu unhandled rdmsr:

[Paolo Bonzini]

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?

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: kvm: vcpu unhandled rdmsr:

[Paolo Bonzini]

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 wraparound

should be downgraded to KERN_DEBUG severity.

 [ 4011.896698] kvm: zapping shadow pages for mmio generation wraparound
 [ 4046.744577] kvm [4706]: vcpu0 unhandled rdmsr: 0xc0010112
 [ 4046.815794] kvm [4706]: vcpu0 unhandled rdmsr: 0xc001100d
 [ 4046.949092] kvm [4706]: vcpu0 unhandled rdmsr: 0xc0010001
 [ 4046.962165] kvm [4706]: vcpu1 unhandled rdmsr: 0xc001100d
 
 Both Fedora 21 x64 host  Fedora 21 x64 guest are hosed, hard reset is must.

It should not be hosed because of the rdmsr.

What processor do you have in the host?  Can you include the output of
ps | grep qemu?

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: Dash as default shell

[Paolo Bonzini]

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 use bashisms, and falls back to POSIX
shell constructs if it cannot use them.  The non-POSIX constructs are
usually faster because they do not need to fork() the shell.  Autoconf
does the same.  dash rejects some of these constructs, and accept others.

Before Autoconf started doing this, dash was indeed quite a bit faster
than bash on configure scripts.  So your estimate of 50% is valid for
projects on which Autoconf has last been run 7-8 years ago.

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: Dash as default shell

[Paolo Bonzini]

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
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: New Group Calls For Boycotting Systemd

[Paolo Bonzini]

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 mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: HEADSUP: json-c SONAME BUMP

[Paolo Bonzini]

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 various packages
 that have to do this.

In this particular case, maybe it's possible to add back the symbols so
that the ABI is preserved.

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: fedoras default cflags clang

[Paolo Bonzini]

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.

https://fedorahosted.org/fesco/ticket/847
http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-17.00.log.html


FWIW, the IRC meeting log mentioned the famous page about better clang 
diagnostics.  That page is comparing clang against GCC 4.2 (Fedora 8 or so).


As of 2014, I only know two cases where clang is still better: more 
complete caret diagnostics, and better recovery from invalid types 
(clang provides suggestions and uses it for the rest of the compilation 
to avoid cascaded error messages).


As of 2014, clang's main strength over GCC is the static analyzer, not 
the diagnostics or the optimization.


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: F21 System Wide Change: BerkeleyDB 6

[Paolo Bonzini]

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 for some other reason and are not on v6
when it's a licensing problem. ;(



(Sorry for the late reply).

It's not just packagers, it's also users.  If a dependent package 
switches from GPL (any release) to AGPL, users will have to add the get 
sources button to their code when the AGPL conditions apply.  If they 
are not able to distribute sources at all, they will have a problem (of 
course the same happens for say GPLv2+ - GPLv3+ switches, but then it 
only affects redistribution and not usage).


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: RFC - Downgrade BlueZ to v4.101 in Fedora 20

[Paolo Bonzini]

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 handsfree profile working.


From the BlueZ 5.0 release notes:

Remove internal support for telephony (HFP and HSP) profiles. They 
should be implemented using the new Profile interface preferably by the 
telephony subsystem of choice (e.g. oFono which already supports this)


For Fedora this means PulseAudio.

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: [HEADS UP] libtool + %global _hardened_build 1 = no full hardening

[Paolo Bonzini]

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 libtool
mailing list(s)... O:-)

Is there at least a Fedora BZ for this?

Paolo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fwd: Thursday is Spice Test Day!

[Paolo Bonzini]

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
 https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#SDL_Graphics

 This might be a bug, or it might be that you don't have a video device
 available (are you running this at the text console or over ssh?)

 SDL works pretty reliably for me though, but if you can't get it to
 work you should file a bug with detailed information about versions
 and how to reproduce it.
 
 But what about this one?
 https://bugzilla.redhat.com/show_bug.cgi?id=880152#c3

That's a RHEL bug.  For what it's worth, in RHEL you're not even
supposed to invoke qemu-kvm, it's in /usr/libexec.

Paolo

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: git rebase master

[Paolo Bonzini]

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 the actual _point_ of the commands you're using in the
 intended git workflow.

Interestingly, git itself is developed the other way round: you first do
the fixes in the oldest applicable branch and git merge upwards (from
f18 to f19, from f19 to master in the Fedora case).

Paolo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Arduino firmware permissible to include?

[Paolo Bonzini]

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
 (http://arduino.cc/en/Main/ArduinoWiFiShield).  The Arduino source
 bundles include the binary firmware.  Source code for the firmware is
 also included, but there are no build scripts, and the firmware is not
 built when the IDE itself is built.
 
 Is it permissible to include this firmware in the Fedora packages?  My
 impression is that it's not firmware in the sense described at
 https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware, because
 it's not firmware for hardware on which Fedora runs.  Rather, I believe
 that it is content
 (https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content).
 
 Without access to the build scripts (which the GNU GPL2specifically says
 must be included), do we even have a licence to redistribute the firmware?

The firmware is merely aggregated to the IDE, so the GNU GPLv2 doesn't
matter here.

The firmware license is definitely not free.  I don't know if you can
get an exception because it doesn't run on the CPU.  The safest bet is
to ask FESCo.

Paolo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: when startup delays become bugs

[Paolo Bonzini]

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 where the kernel
 takes 1.9 seconds. Off hand this doesn't seem reasonable, especially
 sendmail. If the time can't be brought down by a lot, can it ship
 disabled by default?
 
 FWIW, I found your results here interesting, so I did a little test of
 my own. I did default DVD installs of F17, F18 and F19 Beta TC4, ran
 through firstboot, rebooted, then rebooted again and ran systemd-analyze
 (to let prelink kick in). Results are that F18's slightly slower than
 F17 and F19 is somewhat slower again. My numbers are way way faster than
 your numbers overall, though; VMs do seem to perform very quickly on
 this box for whatever reason.

Can you include here the QEMU command line or libvirt XML definition?

Unless you have something like cache=none or cache='none' in it
(respectively for QEMU and libvirt), chances are that you're using the
host memory as a very fast and large disk cache for your VM. :)

(VMs tend to be fast in the initramfs anyway, because they do not have
much hardware to initialize, especially graphics cards).

Paolo

 F17
 ---
 
 Startup finished in 493ms (kernel) + 794ms (initramfs) + 2751ms
 (userspace) = 4039ms
 
446ms udev-settle.service
345ms NetworkManager.service
268ms systemd-logind.service
266ms ip6tables.service
262ms avahi-daemon.service
261ms iptables.service
173ms mcelog.service
170ms nfs-lock.service
145ms udev-trigger.service
136ms udev.service
135ms abrt-ccpp.service
122ms spice-vdagentd.service
117ms sendmail.service
114ms sm-client.service
110ms media.mount
106ms sys-kernel-debug.mount
105ms fedora-loadmodules.service
105ms dev-hugepages.mount
103ms dev-mqueue.mount
100ms sys-kernel-security.mount
 98ms rsyslog.service
 91ms remount-rootfs.service
 90ms dbus.service
 86ms sys-kernel-config.mount
 84ms systemd-vconsole-setup.service
 84ms acpid.service
 77ms boot.mount
 62ms systemd-tmpfiles-setup.service
 56ms abrt-vmcore.service
 53ms fedora-storage-init.service
 53ms systemd-user-sessions.service
 49ms sshd.service
 47ms auditd.service
 44ms systemd-remount-api-vfs.service
 41ms colord.service
 41ms systemd-sysctl.service
 38ms bluetooth.service
 32ms fedora-storage-init-late.service
 28ms fedora-readonly.service
 28ms lvm2-monitor.service
 27ms systemd-readahead-collect.service
 25ms colord-sane.service
 18ms udisks2.service
 18ms mdmonitor-takeover.service
 13ms upower.service
 13ms accounts-daemon.service
 11ms rtkit-daemon.service
 10ms rpcbind.service
  9ms fedora-wait-storage.service
 
 F18
 ---
 
 Startup finished in 521ms (kernel) + 616ms (initramfs) + 3348ms
 (userspace) = 4485ms
 
742ms iscsid.service
607ms firewalld.service
460ms systemd-udev-settle.service
372ms chronyd.service
369ms restorecond.service
321ms gdm.service
292ms abrt-ccpp.service
279ms ksmtuned.service
231ms accounts-daemon.service
208ms spice-vdagentd.service
208ms auditd.service
182ms systemd-logind.service
174ms avahi-daemon.service
167ms rtkit-daemon.service
163ms sm-client.service
116ms fedora-readonly.service
110ms fedora-loadmodules.service
109ms systemd-udev-trigger.service
104ms NetworkManager.service
101ms mcelog.service
 95ms systemd-udevd.service
 87ms sendmail.service
 84ms sys-kernel-debug.mount
 82ms dev-hugepages.mount
 82ms dev-mqueue.mount
 79ms iscsi.service
 74ms systemd-remount-fs.service
 64ms sys-kernel-config.mount
 56ms systemd-vconsole-setup.service
 52ms colord.service
 42ms fedora-storage-init.service
 41ms systemd-user-sessions.service
 35ms udisks2.service
 34ms ksm.service
 34ms polkit.service
 29ms systemd-tmpfiles-setup.service
 28ms rpcbind.service
 26ms bluetooth.service
 24ms fedora-storage-init-late.service
 23ms sshd.service
 16ms abrt-vmcore.service
 15ms upower.service
 15ms lvm2-monitor.service
 15ms systemd-sysctl.service
 13ms systemd-modules-load.service
 13ms mdmonitor-takeover.service
 10ms boot.mount
  4ms tmp.mount
 
 F19
 ---
 
 Startup finished in 411ms (kernel) + 745ms (initrd) + 4.704s (userspace)
 = 5.861s
 
   2.745s plymouth-quit-wait.service
   2.389s NetworkManager-wait-online.service
   1.078s accounts-daemon.service
   1.026s firewalld.service
   1.007s restorecond.service
987ms avahi-daemon.service
479ms iprupdate.service
385ms iprinit.service
356ms systemd-udev-settle.service
  

Re: F19 DVD over size - what to drop?

[Paolo Bonzini]

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 images. Apple, before dropping DVD's with new
 computers, went with two DVD's for a period, even though they had
 hardware that supported DVD/DL. There's precedent. If it's going to
 cause aneurisms figuring out what to drop, just use two images.

Apple used DVD/DL as soon as they added DL burning hardware, I think
that was 10.4 (Tiger).

Paolo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of Hardened Packages

[Paolo Bonzini]

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 [qemu-1.4.0-5.fc20.x86_64]
 with hardening flags enabled.  It seems to be working OK so far ...

QEMU's own configure script takes care of enabling PIE and relro, at
least on x86/Linux and x86/OpenBSD.  Testers are welcome for other
architectures!

Paolo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of Hardened Packages

[Paolo Bonzini]

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
 mailto:sgr...@redhat.com wrote:
   On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote:
_hardened_build rpm spec macro can be used to harden a package.
   
For an example, see
http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec
  
   This flag is overly aggressive. We have a list of programs that
 need PIE
   enabled and doing more isn't necessarily constructive.
 
  Why exactly it isn't necessarily constructive?  If you have hard
 data,
  please share :)
 
 Because PIE is only supposed to be on long running apps and setuid
 apps. If
 its on everything, it will slow the system down too much and then
 you have the
 knee jerk reaction to remove it from anything. We want it applied
 when needed
 and otherwise not.
 
 
 How much does it slow things down? I'm fairly certain you don't have any
 good data on this point. Dhiru is working out how to best figure out FWIW.
 
 I'm willing to agree that PIE on x86 is going to be very slow due to
 register pressure.

Yes, but not on x86-64 which has %rip-relative addressing.  It is
probably a wash there.

Also, it is not really _that_ slow.  The same register pressure issue
exists with PIC.  It was that bad, we would have problems for all the
code we run from shared libraries.

Paolo

 However, we should consider revisiting what we want
 built as PIE. Is Firefox a long running process? It is on my system.
 Revisiting our current list and trying to understand our needs is never
 a bad thing to do. Existing architectures are different now than they
 were when that list was created, no harm comes from talking about it.
 
 -- 
 JB
 
 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: the need of Offline Updates

[Paolo Bonzini]

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 transaction-checks
 tp prevent one package is overwriting files of
 a different one, has no package-deps over the
 complete system

Windows actually tracks files, registry keys, extension-program
associations and a bunch of other things individually.

Of course Windows doesn't control (almost) all packages like Fedora
does, and many vendors misuse that.  And the binary compatibility of
DLLs is much harder than with Linux sonames.  Still, updates coming from
Microsoft are in general pretty solid.

Paolo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Virtio RNG

[Paolo Bonzini]

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 in the
 cryptographic language I'm used to.
 
 Ah, according to this:
 http://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdrand-and-rdseed
 RDRAND doesn't output random numbers, only pseudorandom numbers. I
 suppose that's what you meant.

Yes, you're right.

Paolo

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Virtio RNG

[Paolo Bonzini]

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 the host, and it does make host-side 
 exhaustion more likely. There's not a lot that can be done about that 
 other than providing other sources of entropy, and long-term this is 
 going to be fixed once everyone's moved to Ivy Bridge and has an 
 unprivileged instruction to hand out entropy.

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.  We plan to add QEMU support for
using RDRAND directly (with whitening, similar to rngd), but it is not
in yet.  Right now what you do is use rngd in the host to feed
/dev/random with random numbers from RDRAND, connect /dev/random to
virtio-rng.

In either case, in the end the guest will have to run rngd to feed the
entropy into virtio-rng.

BTW, virtio-rng really only works well if you have a hardware RNG in the
host.  Otherwise, the host kernel will take too much time (a few
minutes) before producing enough entropy to feed the FIPS tests in the
guest, and during this time the host will be entropy-starved.

Paolo

 Given FIPS paranoia about RNG sources, does this have knock-on effects in
 the FIPS compliance of guests depending on how it's fed in the host?
 
 I'm not convinced that you could currently claim with a straight face 
 that guests meet any sort of FIPS standard for random numbers.
 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: libcacard can never be installed

[Paolo Bonzini]

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 never be installed

 Is there a reason that qemu ships a bundled version of libcacard?
 What's the difference between the two of them? Can qemu use the
 unbundled version or are they essentially two completely different
 libraries with the same name?
 
 It looks as if the qemu source contains the one canonical copy of
 libcacard.  The separate 'libcacard' package has the following sources
 file:
 
 $ cat sources 
 189bc5b87281a72f8c72a0f7ebaa6d00  qemu-1.2.1.tar.bz2

Yes, I noticed this a month ago and suggested that Alon would merge the
packages and orphan libcacard.  He forgot to do the second step
apparently. :)

Paolo

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Problems with Automake 1.13 and 1.13.1

[Paolo Bonzini]

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 message.The  maintainer is new and really didn't
listen to the community telling him not to do this.

With my (former) Autotools developer hat on, I believe this is a
horrible mistake and it will be a big hassle for everyone involved in
distro packaging.  Deprecation is okay, but in this case the macros
were not providing any feature and as such were largely unnoticed.
Myself, I had never bothered replacing them in my projects.

Automake 1.13.1 is already in rawhide and we need to do something about
it before a F19 mass rebuild starts.

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 nightmare.
From a very small collection of ~20 autoconfiscated packages
whose fedpkg prep output I have ready on my machines, I get 4 hits:

$ grep AM_CONFIG_H */*/configure.ac
irqbalance/irqbalance-1.0.3/configure.ac:AM_CONFIG_HEADER(config.h)
lsscsi/lsscsi-0.25/configure.ac:AM_CONFIG_HEADER(config.h)
sed/sed-4.2.1/configure.ac:AM_CONFIG_HEADER(config.h:config_h.in)
udisks/udisks-1.0.4/configure.ac:AM_CONFIG_HEADER(config.h)

3) reintroducing the macros in Fedora's 1.13.1 version.  My favorite.


Any other opinions?

Paolo

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Problems with Automake 1.13 and 1.13.1

[Paolo Bonzini]

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 nightmare.
 From a very small collection of ~20 autoconfiscated packages
 whose fedpkg prep output I have ready on my machines, I get 4 hits:

 $ grep AM_CONFIG_H */*/configure.ac
 irqbalance/irqbalance-1.0.3/configure.ac:AM_CONFIG_HEADER(config.h)
 lsscsi/lsscsi-0.25/configure.ac:AM_CONFIG_HEADER(config.h)
 sed/sed-4.2.1/configure.ac:AM_CONFIG_HEADER(config.h:config_h.in)
 udisks/udisks-1.0.4/configure.ac:AM_CONFIG_HEADER(config.h)

 3) reintroducing the macros in Fedora's 1.13.1 version.  My favorite.
 
 4) Submit a patch upstream restoring the macros and ask representatives
 from various distros to help champion its inclusion.

Of course (BTW the Automake maintainer now confirmed to me privately
that he'd accept such a patch), though it would probably would make
sense to put it in Fedora even before 1.13.2.

I'll try to put together the patch tomorrow, unless anyone beats me.

Paolo
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel