[rpms/perl-Sys-Virt-TCK] PR #1: SELinux policy for Libvirt-TCK

[Daniel P . Berrange]

berrange closed without merging a pull-request against the project: 
`perl-Sys-Virt-TCK` that you
are following.

Closed pull-request:

``
SELinux policy for Libvirt-TCK 
``

https://src.fedoraproject.org/rpms/perl-Sys-Virt-TCK/pull-request/1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Sys-Virt-TCK] PR #1: SELinux policy for Libvirt-TCK

[Daniel P . Berrange]

berrange commented on the pull-request: `SELinux policy for Libvirt-TCK ` that 
you are following:
``
Closing since this never merged upstream
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sys-Virt-TCK/pull-request/1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-Sys-Virt] PR #1: Package tests

[Daniel P . Berrange]

berrange commented on the pull-request: `Package tests` that you are following:
``
Why did you just merge this when I did not agree to it ?
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sys-Virt/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Sys-Virt] PR #1: Package tests

[Daniel P . Berrange]

berrange commented on the pull-request: `Package tests` that you are following:
``
I don't find this change desirable because it is impacting the user facing RPM 
packaging to satisfy non-user facing CI. I don't see much value in this CI 
either because it is just repeating tests that have already been run during the 
build, and can be re-run by Koschei when a dependancy changes.
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sys-Virt/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[rpms/perl-Sys-Virt-TCK] PR #1: SELinux policy for Libvirt-TCK

[Daniel P . Berrange]

berrange commented on the pull-request: `SELinux policy for Libvirt-TCK ` that 
you are following:
``
Thanks for this, however, we have a strictly upstream-first policy for libvirt, 
so can't take this kind of thing as a Fedora patch. Please can you send it 
upstream as a patch to the real libvirt-tck git repo.

``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Sys-Virt-TCK/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[rpms/perl-Glib-Object-Introspection] PR #1: Update to 0.048 (#1782378)

[Daniel P . Berrange]

berrange commented on the pull-request: `Update to 0.048 (#1782378)` that you 
are following:
``
Merged
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-Glib-Object-Introspection/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

[rpms/perl-Glib-Object-Introspection] PR #1: Update to 0.048 (#1782378)

[Daniel P . Berrange]

berrange closed without merging a pull-request against the project: 
`perl-Glib-Object-Introspection` that you
are following.

Closed pull-request:

``
Update to 0.048 (#1782378)
``

https://src.fedoraproject.org/rpms/perl-Glib-Object-Introspection/pull-request/1
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org

Re: koschei interpertation; was: Re: -z defs linker flag activated in Fedora rawhide

[Daniel P. Berrange]

On Tue, Jan 23, 2018 at 02:06:15PM -0500, R P Herrold wrote:
> On Tue, 23 Jan 2018, Daniel P. Berrange wrote:
> 
> > What needs to be done for this ?  I see my package "libvirt" present
> > in its UI
> > 
> >   https://apps.fedoraproject.org/koschei/package/libvirt
> > 
> > but it says
> > 
> >   "Package is currently ineligible for scheduling due to following reasons:
> 
> looking at the 'EPEL 7' tab, I see:
> 
>   Base buildroot for EPEL 7 is not installable. 
> 
> Dependency problems:
> nothing provides requested redhat-release-everything

EPEL is irrelevant for libvirt as it is shipped in base RHEL/CentOS, so
I've never touched anything related to EPEL branches. THe problems I
mention above were listed when I view the rawhide tab.


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Daniel P. Berrange]

On Tue, Jan 23, 2018 at 05:56:47PM +, Jonathan Wakely wrote:
> On 23/01/18 15:38 +0100, Florian Weimer wrote:
> > We could deactivate -z defs for F28 and reactivate it after the branch
> > for F29, giving packagers more time to fix issues.
> 
> I think that might be a good idea (given how late in the F28 process
> we are) but for many packages it will just mean we have the same
> problem at the next mass rebuild.
> 
> Lots of packages don't get rebuilt between releases, so the
> maintainers won't see any failure for F29 after -z defs becomes the
> default again, so they won't fix anything.
> 
> Every package known to have problems now should get added to koschei.

What needs to be done for this ?  I see my package "libvirt" present
in its UI

  https://apps.fedoraproject.org/koschei/package/libvirt

but it says

  "Package is currently ineligible for scheduling due to following reasons:

Package is not tracked
Package dependencies were not resolved yet"

but there's no info about what these reasons really mean, nor how I
would go about resolving them.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Daniel P. Berrange]

On Tue, Jan 23, 2018 at 02:04:26PM +0100, Florian Weimer wrote:
> On 01/23/2018 01:49 PM, Daniel P. Berrange wrote:
> > On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> > > I updated redhat-rpm-config to instruct ld to reject linking shared 
> > > objects
> > > with undefined symbols.  Such undefined symbols break symbol versioning
> > > because the are not necessarily bound to the correct symbol version at run
> > > time.  (rhbz#1535422)
> > > 
> > > ### Disable strict symbol checks in the link editor (ld)
> > > 
> > > By default, the link editor will refuse to link shared objects which
> > > contain undefined symbols.  In some cases (such as when a DSO is
> > > loaded as a plugin and is expected to bind to symbols in the main
> > > executable), undefined symbols are expected.  In this case, you can
> > > add
> > > 
> > >  %undefine _strict_symbol_defs_build
> > > 
> > > to the RPM spec file to disable these strict checks.  Alternatively,
> > > you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
> > > command line).  The latter needs binutils 2.29.1-12.fc28 or later.
> > 
> > This affects libvirt, because we have a tonne of dlopen()able modules
> > which have undefined symbols that get resolved against the binary
> > that's loading them:
> > 
> >https://kojipkgs.fedoraproject.org//work/tasks/4413/24394413/build.log
> > 
> > I'll add the "%undefine _strict_symbol_defs_build" stanza to the RPM
> > spec for now.
> 
> Some of these symbols are also defined in libvirt.so.0.  In fact, in the
> link failure above, I don't see a *single* symbol which isn't defined in
> libvirt.so.0.  And /usr/sbin/libvirtd has a DT_NEEDED entry for libvirt.so.0
> anyway, so it's not actually about loading libvirt.so.0.
> 
> This looks more like the new style of doing plug-ins, where the shared code
> is in a separate DSO which is linked from both the main application and the
> plug-ins.  In this case, maybe you can complete the transition and avoid
> quite a bit of duplicate by removing the definitions from the main program?

The stuff the modules depend on is probably all in libvirt.so, but
I'm not 100% that's the case for all our modules - the build failure
above stopped the build before getting onto many of our other modules.

I'll have a go at explicitly linking the plugins with libvirt.so upstream
though, to see if that's sufficient to kee the linker happy, and if so
add '-z defs' by default to upstream's build.

> If there is deliberate symbol interposition going on to alter the
> functionality of libvirt.so.0, then this will continue to work even if the
> plug-ins are linked explicitly against libvirt.so.0.

I don't think we do symbol interposition

> > I wonder if you can elaborate on what we should look out for wrt the
> > glibc vs tirpc symbol resolution problem mentioned.  libvirt uses
> > XDR APIs, so is potentially affected by this. In rawhide, we are
> > linking with an explicit "-ltirpc" line already though. Is that
> > enough to avoid the problems you describe wrt xdr_* symbols getting
> > incorrectly resolved ?
> 
> The xdr_* symbols should have TIRPC_* symbol version.  Then you are good.

Ok, thanks.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: -z defs linker flag activated in Fedora rawhide

[Daniel P. Berrange]

On Mon, Jan 22, 2018 at 04:24:31PM +0100, Florian Weimer wrote:
> I updated redhat-rpm-config to instruct ld to reject linking shared objects
> with undefined symbols.  Such undefined symbols break symbol versioning
> because the are not necessarily bound to the correct symbol version at run
> time.  (rhbz#1535422)
> 
> ### Disable strict symbol checks in the link editor (ld)
> 
> By default, the link editor will refuse to link shared objects which
> contain undefined symbols.  In some cases (such as when a DSO is
> loaded as a plugin and is expected to bind to symbols in the main
> executable), undefined symbols are expected.  In this case, you can
> add
> 
> %undefine _strict_symbol_defs_build
> 
> to the RPM spec file to disable these strict checks.  Alternatively,
> you can pass `-z undefs` to ld (written as `-Wl,-z,undefs` on the gcc
> command line).  The latter needs binutils 2.29.1-12.fc28 or later.

This affects libvirt, because we have a tonne of dlopen()able modules
which have undefined symbols that get resolved against the binary
that's loading them:

  https://kojipkgs.fedoraproject.org//work/tasks/4413/24394413/build.log

I'll add the "%undefine _strict_symbol_defs_build" stanza to the RPM
spec for now.

I wonder if you can elaborate on what we should look out for wrt the
glibc vs tirpc symbol resolution problem mentioned.  libvirt uses
XDR APIs, so is potentially affected by this. In rawhide, we are
linking with an explicit "-ltirpc" line already though. Is that
enough to avoid the problems you describe wrt xdr_* symbols getting
incorrectly resolved ?

We could potentially explore a change to our build system upstream
so add  "-z defs" only to libvirt.so (which uses the xdr_* APIs)
but *not* the loadable modules. IIUC, that would protect us for
the symbol resolution without triggered the undefined symbols
problem in other parts of our code.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [HEADS UP] Manging shebangs in Rawhide

[Daniel P. Berrange]

On Tue, Jan 23, 2018 at 08:55:03AM +, Richard W.M. Jones wrote:
> On Mon, Jan 22, 2018 at 05:36:56PM +0100, Igor Gnatenko wrote:
> > * Removes exectuable bit (and shows warning) for files where there are no
> > shebang
> 
> The way this is written implies that ordinary (eg ELF) executables
> will be broken by this change, which I'm assuming/hoping is not the
> case.
> 
> I'm concerned that your changes will break mingw-* files, where the
> executable bit is set on something which is neither a shebang script
> nor an ELF executable.  (There are other corner cases too,
> eg. programs which are meant to be run under qemu or wine).

In the PR it appears to filter on executuable  files with a detected
mime type 'text/*', and thus it should skip binary files whether ELF or
any other format. This looks like it should be safe for mingw files.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Daniel P. Berrange]

On Mon, Dec 18, 2017 at 01:19:26PM -0500, Stephen John Smoogen wrote:
> On 18 December 2017 at 13:08, Matthew Miller  wrote:
> > On Mon, Dec 18, 2017 at 09:55:26AM -0800, Adam Williamson wrote:
> >> I think we should be concerned by this kind of behaviour on the part of
> >> the supplier of our default desktop browser, and we should express that
> >> concern to them. Assuming Fedora-as-a-project shares my concern, do we
> >> have a channel to communicate with them about this, and request
> >> assurances that they understand the seriousness of this, and that they
> >> have changed policies so that nothing like it will happen in future?
> >
> > Is there a fundamental difference between this and, if, say, similar
> > functionality were in the FF 57 release itself?
> >
> >
> 
> I am not sure I understand your question enough to formulate what
> difference you are wanting. Since the addon was distributed POST
> install without user intervention, it would seem yes there is a big
> difference. If it were installed in FF57 then I wouldn't
> install/update to that version. If it is 'pushed' post install then it
> means that just using the software means that Mozilla can push addons
> to my desktop without my intervention or knowledge. This takes the
> browser from being my software to always being 'their' software which
> I am just using for their pleasure.

It occurred to me that Mozilla's view of this service is probably biased
the way they support non-Linux desktop platforms (Windows, OS-X, Android,
etc) where 95%+ of their users are. There the users have a direct interaction
with Mozilla as the distributor. Once they have downloaded Firefox for windows
from Mozilla's website, Mozilla can push out updates to their browser on
the fly, and for a large % of users this requires no intervention/approval.
There is no middle man "OS vendor" as you get with Linux distros (ok app
stores are a middle man, but that's more about rubber stamping the release,
not re-packaging & rebuilding firefox). So in this world, the ability to
push out code as add-ons without user intervention, doesn't feel significantly
different than their ability to push out the entire new browser verson
releases to users, largely without intervention.

None the less, if we consider Fedora maintainers to be adding value via the
packaging process, over having users get their browser direct from Mozilla,
then I do still think it is desirable to be able to opt-out of this feature
in Fedora builds.

Conversely though in a Flatpak world though, we would be moving much closer
the model of Windows/OS-X/Android where Mozilla has a more direct way to
push software to users, without a OS vendor arbitrarily rebuilding & repackaging
stuff.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Daniel P. Berrange]

On Mon, Dec 18, 2017 at 10:42:17AM -0800, Adam Williamson wrote:
> On Mon, 2017-12-18 at 12:34 -0600, Chris Adams wrote:
> > Once upon a time, Adam Williamson  said:
> > > As part of a tie-in with an American TV show, Mozilla thought it'd be a
> > > great idea to silently install a cryptically-named addon in all(?)
> > > Firefox deployments. Which can't be turned off.
> > 
> > I thought that this was actually a violation of the packaging policies,
> > but I can't seem to find it now; I only see the restriction on software
> > the requires downloads to be useful.
> 
> IIRC there used to be a stricter policy that was relaxed as it had
> become kinda untenable with the widespread acceptance of addons and
> extensions for things like browsers and desktops. I could be wrong,
> though.
> 
> >   I think simply requiring Mozilla
> > to change their policies is unacceptable, as this still depends on a
> > third party to properly enforce such policies (and not have any security
> > issue that could result in untrusted addons being installed).
> 
> Well, practically speaking we do have to have *some* degree of trust in
> our suppliers for apps as large and complex as a web browser or, say,
> an office app. Let's face it, practically speaking we're not really
> equipped to handle an adversarial relationship there. Even if we say
> "we're going to patch out this mechanism", that only really works if we
> trust the vendor at least to the degree that we don't believe they'd
> insert a harder-to-detect back channel to do the same thing, because
> practically speaking we just don't have the resources to audit the
> entire Firefox codebase (or even audit changes from some point in time
> we consider 'trustworthy' onwards) to ensure they haven't done this.

IMHO requesting support for a build flag to disable this ability to
remotely push executable code out to user's browser is not unreasonable,
and shouldn't make Fedora seem "adversarial", unless there's bigger
trust issues at play here.

> > IMHO such behavior needs to be disabled by default in any packages
> > shipped by Fedora for Fedora to remain a trustworthy distribution.  Are
> > there any other packages that can silently download and run non-Fedora
> > code?
> 
> I dunno about 'silently', but there are certainly other cases of this,
> yes. GNOME Software can install GNOME Shell extensions (which are code,
> and can do anything with the privileges of the user account running the
> shell) from a non-Fedora source (extensions.gnome.org), for instance.

It won't install random new extensions without the user having asked for
them. At most it would update previously installed extensions to newer
versions. Though if someone did compromise the GNOME extensions service,
that distinction is fairly academic from a security POV. IOW, a security
concious person would not want to allow an communication to the
extensions.gnome.org service at all to protect themselves.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Daniel P. Berrange]

On Mon, Dec 18, 2017 at 12:34:46PM -0600, Chris Adams wrote:
> Once upon a time, Adam Williamson  said:
> > As part of a tie-in with an American TV show, Mozilla thought it'd be a
> > great idea to silently install a cryptically-named addon in all(?)
> > Firefox deployments. Which can't be turned off.
> 
> I thought that this was actually a violation of the packaging policies,
> but I can't seem to find it now; I only see the restriction on software
> the requires downloads to be useful.  I think simply requiring Mozilla
> to change their policies is unacceptable, as this still depends on a
> third party to properly enforce such policies (and not have any security
> issue that could result in untrusted addons being installed).
>
> IMHO such behavior needs to be disabled by default in any packages
> shipped by Fedora for Fedora to remain a trustworthy distribution.  Are
> there any other packages that can silently download and run non-Fedora
> code?

It was brought up elsewhere that Chrome/Chromium in the past has done
something worse in scope, silently downloading an add-on to that turns
on & listens to your microphone. Ostensibly to detect the "ok google"
keyword, but since its a closed source add-on can you be sure that's all
it does...

 
https://www.privateinternetaccess.com/blog/2015/06/google-chrome-listening-in-to-your-room-shows-the-importance-of-privacy-defense-in-depth/

Fortunately, the Fedora builds of Chromium have explicitly disabled this
feature (enable_hotwording=false in chromium.spec)

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: -Wl,--as-needed by default (and glibc ldconfig file trigger)

[Daniel P. Berrange]

On Tue, Nov 21, 2017 at 05:22:32PM +0100, Stephan Bergmann wrote:
> On 11/21/2017 04:12 PM, David Tardon wrote:
> > On Tue, Nov 21, 2017 at 01:54:13PM +, Tomasz Kłoczko wrote:
> > > On 21 November 2017 at 10:43, Igor Gnatenko
> > >  wrote:
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > > 
> > > > On Tue, 2017-11-21 at 10:26 +, Tomasz Kłoczko wrote:
> > > > > So is it any final decision about start use by default --as-needed in
> > > > > linker options?
> > > > 
> > > > Can you link Change Proposal you (or someone else) submitted? I have 
> > > > not heard
> > > > anything about that.
> > > 
> > > https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/3
> > > 
> > > [..]
> > > > > In my opinion number of affected packages will be very low (few).
> > > > 
> > > > Counting numbers of affected packages by guessing is very bad idea.
> > > 
> > > Call it educated guess if you want.
> > 
> > You know, there is a way to get more reliable data: do scratch builds of
> > all Fedora packages and analyze the results. Then we'd know _exactly_
> > how many packages would need to be patched.
> 
> ...depending on how thoroughly the analysis is done, as the breakage caused
> by an erroneous --as-needed might, at least in principle, only happen at
> runtime, rather than at build time.

Pretty much all software in Fedora is already shipped in other distros
which have taken this linking approach for a long time. So it is pretty
reasonable to expect these kind of bugs have been identified & fixed
by maintainers in other distros already. There may be edge cases remaining
which no user has yet managed to tickle, but that's true of many aspects
of Fedora. eg when we introduced the hardened build flags, there were
places where we wouldn't know about breakage until much later. Requiring
perfection before making this kind of change effectively means never doing
the change.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: -Wl,--as-needed by default

[Daniel P. Berrange]

On Mon, Nov 13, 2017 at 11:52:14AM +0100, Björn 'besser82' Esser wrote:
> Am Montag, den 13.11.2017, 11:02 +0100 schrieb Igor Gnatenko:
> > Hello,
> > 
> > I'm interested why we still don't have this flag in our CFLAGS? It
> > seems that
> > other distributions like openSUSE enable it by default and it helps
> > in many
> > cases to avoid over-linking (for example, see thread about poppler).
> > 
> > Are there any reasons not to add it?
> 
> 
> Hello Igor,
> 
> that specific flag should be in LDFLAGS, but there are reasons, we do
> NOT have it in there, because it will likely break any binaries built
> from or containing FORTRAN sources.  They will simply SEGFAULT, because
> `-Wl,--as-needed` causes some needed runtime libraries NOT being linked
> with them, because the linker thinks they are not needed / would over
> link.

What % of our distro involves fortran though ? Could this be as simple as
enabling it by default, but having an easy way via an RPM macro to opt-out
of it in the handleful of packages that matter wrt fortran. 

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CUPS will change license since 2.3 version - now incompatible with GPLv2

[Daniel P. Berrange]

On Wed, Nov 08, 2017 at 04:17:20PM +0100, Hans de Goede wrote:
> Hi,
> 
> On 08-11-17 16:06, Solomon Peachy wrote:
> > On Wed, Nov 08, 2017 at 03:53:32PM +0100, Hans de Goede wrote:
> > > >I don't think static linking against libcups is common enough to be a
> > > >serious concern - CUPS is fairly ubiquitous and easily falls under 
> > > > the
> > > >"OS-supplied library" exception in the GPL 2.  And existing 
> > > > GPL-2-only
> > > >software that *does* statically link/copy CUPS code can continue to 
> > > > do
> > > >so with CUPS 2.2.x and earlier.
> > > 
> > > Someone should reply to that that the OS exception only applies when
> > > distributing binaries separate from said OS, not for binaries bundled
> > > with the OS, which all Linux distros are  (AFAIK, IANAL).
> > 
> > I'm willing to reply to this, but before I (or anyone else) does so, I
> > think it highly prudent to have fedora-legal weigh in first.
> 
> Right, good idea, as Michal Stahl pointed out:
> https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F
> indicates that fedora-legal does consider the "OS-supplied library" exception
> to apply to Fedora pkgs, so it seems I'm wrong here.

Well that page only refers to OpenSSL and even then it points out that other
distros have differing opinions. Personally I think it is dubious even for
OpenSSL, and if you start broadening it further to claim it applies to what
are effectively application level libiraries like libcups, where does it end ?
You could just claim it applies to any widely used library in Fedora, at which
point you're effectively just trying to nullify all licensing rules, whichs is
not acceptable IMHO.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CUPS will change license since 2.3 version - now incompatible with GPLv2

[Daniel P. Berrange]

On Wed, Nov 08, 2017 at 08:32:50AM -0500, Solomon Peachy wrote:
> On Wed, Nov 08, 2017 at 07:45:28AM -0500, Neal Gompa wrote:
> > It will. Previously, it was licensed under GPLv2 + LGPLv2 with Apple
> > exceptions. Now it is ASL 2.0 across the board. GPLv2 projects can not
> > link to the newer version.
> 
> That will seriously affect Gutenprint if applied strictly.
> 
> OTOH, Gutenprint is GPLv2+, so it could be considered GPLv3 for purposes 
> of linking to ASL2.0 CUPS..

Just make sure that Gutenprint doesn't link to any other 3rd party
libs that are GPLv2-only - everything it links to would need to
be v2-or-later (or otherwise GPLv3 compatible) to allow the combined
work  to be considered GPLv3


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Verifying sources against gpg signature during RPM build ?

[Daniel P. Berrange]

A number of packages that I maintain have GPG signatures provided alongside
the sources for new releases. Is there any best pratice approach / RPM macro
magic for verifying the GPG signature of sources during build, or are
packagers just (re)inventing the wheel each time ?  

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: are the armv7hl builders healthy?

[Daniel P. Berrange]

On Fri, Sep 01, 2017 at 08:17:11AM -0400, Kaleb Keithley wrote:
> 
> I'm trying to build ceph-12.2.0 for f28,  So far the build has failed twice 
> on armv7hl during %install trying to install a file that was seeminlyly 
> successfully built.
> 
> That's two different files. The first time it was cephfs-journal-tool, the 
> second time it was the one immediately after: cephfs-table-tool.
> 
> The other six archs builds are successful and building 12.1.4 a week ago 
> worked.
> 
> Am I running into quotas or some other file system space limitation?
> 
> The most recent build log is at 
> https://kojipkgs.fedoraproject.org//work/tasks/3484/21583484/build.log
> 
> The previous build log is at 
> https://kojipkgs.fedoraproject.org//work/tasks/7134/21537134/build.log
> 
> Any thoughts?

Is there any way to fix cmake or the ceph cmake rules so that they report
the real useful error message, instead of throwing it away & providing a
generic "cannot copy file" message with no details ?  Its hard to diagnose
without knowing the real error message from the OS

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass package change (python2- binary package renaming)

[Daniel P. Berrange]

On Wed, Aug 09, 2017 at 10:17:34PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Aug 09, 2017 at 04:08:35PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Aug 09, 2017 at 04:48:42PM +0100, Daniel P. Berrange wrote:
> > > On Tue, Aug 08, 2017 at 10:14:26PM +, Zbigniew Jędrzejewski-Szmek 
> > > wrote:
> > > > Hello Fedora Python package maintainers!
> > > > 
> > > > This is an announcement of a mass package renaming:
> > > > Python 2 binary packages will be renamed to python2-*.
> > > > 
> > > > This will happen soon after the F27 branching on August 15th.
> > > > 
> > > > 
> > > > Currently ~1330 source packages already generate a binary package with
> > > > the python2- prefix, and 835 remain to be updated. The spec files for
> > > > approximately 740 packages will be renamed, and 95 will be left for
> > > > fixing by maintainers or proven packagers.
> > > > 
> > > > 
> > > > At the end of this e-mail are two lists of maintainers and packages:
> > > > 
> > > > List 1. for those packages which will be taken care of by the mass 
> > > > remaining
> > > >Patches: https://in.waw.pl/~zbyszek/fedora/pyrename/
> > > > 
> > > >Maintainers don't have to do anything.
> > > 
> > > > Example:
> > > > +%package -n python2-atpy
> > > > +Summary: %summary
> > > > +Requires: numpy python-astropy
> > > > +%{?python_provide:%python_provide python2-atpy}
> > > > +# Remove before F30
> > > > +Provides: ATpy = %{version}-%{release}
> > > 
> > > This looks incomplete & broken to me.
> > > 
> > > The Provides satisfies any dependancies on the old name, but you're
> > > missing an Obsoletes to tell RPM the upgrade path. Trying to installing
> > > the new python2-libvirt RPM on an existing system fails because it
> > > clashes with libvirt-python.
> > Good catch. Obsoletes: python-libvirt is generated by %python_provide,
> > but I forgot to add Obsoletes: libvirt-python.
> > Thanks, I'll fix this and other packages in the same situation.
> I added that. New patches are in https://in.waw.pl/~zbyszek/fedora/pyrename/.
> 
> This new Obsoletes is generated with %{_isa}, and I also added
> %{_isa} to the matching Provides.
> 
> Zbyszek
> 
> > > A further flaw in your script is that its changed libvirt-python to
> > > python2-libvirt, but not changed libvirt-python3 to python3-libvirt,
> > > so the naming inconsistency is worse than before your proposed change.
> > Yeah, that was a conscious decision. In the draft I sent to fedora-devel
> > last week I asked if python3 subpackages should be renamed, but nobody
> > answered, so I assumed that people don't care that much either way.
> > My motivation for not touching this right now was to limit the number
> > of changes and potential for screwups.

IMHO, introducing this inconsistency between py2 and py3 package
naming is really awful.

I'm going to change the libvirt-python package myself because I
don't want such inconsistency, so please don't run your script
against it

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Mass package change (python2- binary package renaming)

[Daniel P. Berrange]

On Tue, Aug 08, 2017 at 10:14:26PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hello Fedora Python package maintainers!
> 
> This is an announcement of a mass package renaming:
> Python 2 binary packages will be renamed to python2-*.
> 
> This will happen soon after the F27 branching on August 15th.
> 
> 
> Currently ~1330 source packages already generate a binary package with
> the python2- prefix, and 835 remain to be updated. The spec files for
> approximately 740 packages will be renamed, and 95 will be left for
> fixing by maintainers or proven packagers.
> 
> 
> At the end of this e-mail are two lists of maintainers and packages:
> 
> List 1. for those packages which will be taken care of by the mass remaining
>Patches: https://in.waw.pl/~zbyszek/fedora/pyrename/
> 
>Maintainers don't have to do anything.

> Example:
> +%package -n python2-atpy
> +Summary: %summary
> +Requires: numpy python-astropy
> +%{?python_provide:%python_provide python2-atpy}
> +# Remove before F30
> +Provides: ATpy = %{version}-%{release}

This looks incomplete & broken to me.

The Provides satisfies any dependancies on the old name, but you're
missing an Obsoletes to tell RPM the upgrade path. Trying to installing
the new python2-libvirt RPM on an existing system fails because it
clashes with libvirt-python.

A further flaw in your script is that its changed libvirt-python to
python2-libvirt, but not changed libvirt-python3 to python3-libvirt,
so the naming inconsistency is worse than before your proposed change.

Also the %_description stuff is just ugly

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ceph build stuck in f27-pending for 12+ hours

[Daniel P. Berrange]

This ceph build finished building in koji 12+ hours ago:

  https://koji.fedoraproject.org/koji/buildinfo?buildID=942742

but it still in f27-pending.  Is there something stuck that prevents
it going into f27, and thus inherited into f27-build ?

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Recompiling/relinking dependent applications/libraries on DSO change

[Daniel P. Berrange]

On Fri, Jul 28, 2017 at 01:39:50PM +0200, Florian Weimer wrote:
> binutils 2.29 introduced an optimization which requires that in the
> general case, applications and libraries linking against a DSO will have
> to be rebuilt when the DSO change the implementation of functions (i.e.,
> changes to a function body can change ABI).  This is how many native
> programming languages (such as Ada, Haskell/GHC, Go, Rust) handle DSOs,
> but it's a material change for C and C++.

Can you elaborate on what sort of change in the function body would
affect the ABI and thus require relinking ?  Having to relink every
time the internal impl of an ABI changes would seem to throw away one
of the main benefits of using shared libs, over static libs and be
pretty unpleasant as a result.

Libvirt, for example, has never changed any existing public API contract
or definition in 10 years of releases, but we do often change the internal
impl of these APIs. Apps have never had to relink against libvirt.so upon
new release, so I would not want that to see that change.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: armv7hl builds running out of memory

[Daniel P. Berrange]

On Wed, Jul 26, 2017 at 12:57:32PM +0100, Peter Robinson wrote:
> On Wed, Jul 26, 2017 at 12:53 PM, Kaleb S. KEITHLEY  
> wrote:
> > trying to build ceph-12 on f27 armv7hl.
> >
> > It builds on everything x86_64, aarch64, s390x, and i686 (w/o java), but
> > on armv7hl the build fails, reporting out of memory.
> >
> > ...
> > [100%] Built target ceph-osd
> > cc1plus: out of memory allocating 11284160 bytes after a total of
> > 58859520 bytes
> > make[2]: *** [src/CMakeFiles/ceph-dencoder.dir/build.make:64:
> > src/CMakeFiles/ceph-dencoder.dir/test/encoding/ceph_dencoder.cc.o] Error 1
> > make[1]: *** [CMakeFiles/Makefile2:1626:
> > src/CMakeFiles/ceph-dencoder.dir/all] Error 2
> > make[1]: *** Waiting for unfinished jobs
> > ...
> >
> >
> > full log at
> > https://kojipkgs.fedoraproject.org//work/tasks/4038/20724038/build.log
> >
> > Is there any way to bump up swap on the builders? Or any trick to get
> > more memory or run on a particular machine that has more memory?
> 
> The ARM builders (both ARMv7 and aarch64) have 24 Gb of memory, which
> is more than all other arches which have 10Gb, so I suspect the issue
> is not in the build hardware but an issue with ceph itself using (or
> leaking) too much memory.

Strangely the error message is complaining about being unable to
allocate 10 MB, with a current total usage of 55 MB, so no where
near the GB of memory, unless there is some other process running
in parallel which is consuming it all.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Daniel P. Berrange]

On Mon, Jul 17, 2017 at 12:45:27PM +0200, Michael Stahl wrote:
> On 16.07.2017 14:10, Kevin Kofler wrote:
> > Debarshi Ray wrote:
> >> How about reliable online updates of running applications as a
> >> benefit?
> > 
> > Upgrading RPM applications online just works. I do it all the time. The KDE 
> > tools do not even implement offline updates (and IMHO that's a good thing). 
> > The worst that can happen is that some recalcitrant applications (by far 
> > the 
> > minority) need to be restarted after updating (or if you upgraded the whole 
> > desktop, then your session may need to be restarted after updating). Until 
> > you do that, the current session may be "hosed" to some extent, but 
> > restarting will fix it.
> 
> no, the worst case is this:
> 
> https://www.happyassassin.net/2016/10/04/x-crash-during-fedora-update-when-system-has-hybrid-graphics-and-systemd-udev-is-in-update/

I had this kind of fun problem upgrading F25 -> F26. I was lazy and didn't
want to reboot so I was just running dnf distro-sync in a gnome-terminal
session. I've upgrade this way since F6 and mostly it just works,  but
forgot to nohup it. About 1/3 of the way through installing new packages,
something causes gnome-terminal to die. I had to write a script to read
the dnf planned transaction log and finish installing and erasing remaining
packages, and manually run any %posttrans scripts.

So yeah, even with latest Fedora things can & do go horribly wrong if you
ignore the advice to not run upgrades from a live system.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Daniel P. Berrange]

On Sat, Jul 15, 2017 at 05:17:44PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jul 14, 2017 at 03:42:15PM +0100, Daniel P. Berrange wrote:
> > On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> > > On Mon, 2017-07-10 at 00:46 +0200, Kevin Kofler wrote:
> > > > Jaroslav Reznik wrote:
> > > > > = System Wide Change: Graphical Applications as Flatpaks =
> > > > > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Fl
> > > > > atpaks
> > > > > 
> > > > > Change owner(s):
> > > > > * Owen Taylor <otay...@redhat.com>
> > > > 
> > > > This change is leaving several questions unanswered:
> > > > 
> > > > * As I understand it, those Flatpaks are going to be built from RPMs.
> > > > Is the intent to ship both the original RPMs and the Flatpak or only
> > > > the Flatpak (or is this going to depend on the individual package)?
> > > > And if the former, are the shipped RPMs going to be the FHS-compliant 
> > > > version or the one relocated into Flatpak's proprietary prefix?
> > > 
> > > The rebuilt RPMs are really only interesting within Flatpaks - they
> > > will be available for download from Koji, but there would be no reason
> > > for a user to do so.
> > > 
> > > As for standard application RPMs, it's really going to be something
> > > we figure out over time. My vision is something like:
> > > 
> > >  F27: packagers are *able* to create Flatpaks of their application.
> > >   They must also maintain standard RPMs.
> > > 
> > >  F28: packagers (of graphical applications) are *encouraged* to create
> > >   Flatpaks of their applications along side standard RPM packaging.
> > >   They *may* drop the standard RPM packaging if there is good
> > >   reason to.
> > > 
> > >  F29: packagers (of graphical applications) must create Flatpaks of
> > >   their applications if possible. They *may* keep standard RPM
> > >   packaging.
> > > 
> > > But this is really highly dependent on how modularity work happens more
> > > widely in Fedora. "standard RPM packaging" assumes we still have
> > > a F tag in Koji where everything is built together with common
> > > coordinated dependencies.
> > 
> > If I look at this from my POV as the upstream maintainer of a graphical
> > application wishing to make it widely available to users of many distros.
> > The question is whether it is beneficial for me to join Fedora packaging
> > world to package my app, or whether to package it standalone as a flatpak
> > and never get involved in Fedora at all.
> > 
> > With the proposed F27 rule here, I would have less work todo if I just
> > built my app as a flatpak, as I can avoid creating RPMs and just build
> > a single flatpak that should work on all distros. IOW by mandating
> > continued creation of RPMs, alongside flatpaks, we would be discouraging
> > people from becoming Fedora maintainers. 
> > 
> > Thus could suggest more flexibility - require continued maint of RPMs
> > for *existing* applications in Fedora only, to give some grace period
> > where we figure out how to provide a seemless upgrade path for people
> > who have an existing RPM installed to magically replace it with flatpak.
> > Anyone wishing to package a *new* application in F27, however, should be
> > able to straight to flatpaks only as there's no upgrade path issue to
> > worry about.
> > 
> > This would encourage upstream app maintainers to join Fedora to make
> > use of the review, build & distribution mechanisms for flatpaks, without
> > forcing them todo extra work to create RPMs too.
> 
> This depends on how exactly flatpacks are built:
> - if first an rpm is built, and then flatpack is built out of rpms,
>   it's strictly more work (although there are benefits to users of installing
>   using flatpacks over plain rpms, so it's an actual benefit for users
>   and hence not pointless).
> 
> - if one is building a _leaf_ application, and all deps are available as
>   rpms, then the packager doesn't need to follow the strict rpm rules,
>   and if they only build a flatpack without the intermediate rpm,
>   some work is saved.
> 
> - if one is building an application that anything else depends on, things
>   get more complicated.
>   (Let's take inkscape as an example: it's a end-user graphical application,
>   but it has command-line mode where it converts svgs to

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Daniel P. Berrange]

On Sun, Jul 16, 2017 at 01:29:01PM +0200, Kevin Kofler wrote:
> Daniel P. Berrange wrote:
> > If I look at this from my POV as the upstream maintainer of a graphical
> > application wishing to make it widely available to users of many distros.
> > The question is whether it is beneficial for me to join Fedora packaging
> > world to package my app, or whether to package it standalone as a flatpak
> > and never get involved in Fedora at all.
> >
> > With the proposed F27 rule here, I would have less work todo if I just
> > built my app as a flatpak, as I can avoid creating RPMs and just build
> > a single flatpak that should work on all distros. IOW by mandating
> > continued creation of RPMs, alongside flatpaks, we would be discouraging
> > people from becoming Fedora maintainers.
> 
> From a user standpoint, what's the difference? What's the benefit from 
> having upstream deliver their software Flatpak-only under the Fedora 
> umbrella? It may as well come directly from upstream at that point. The 
> whole point of delivering software under the Fedora umbrella is to deliver 
> it as RPMs. If there is no RPM, delivering through Fedora is completely 
> useless.

Use of RPM is merely a particular historical choice of delivery mechanism,
and certainly not the defining characteristic of what it means to be the
Fedora distribution. For users consuming the Fedora desktop, the fact that
they're using RPM is hidden away as an implementation detail behind the
apps like GNOME software.

Upstream still has to choose what base layer(s) they build their application
flatpak on top of, and thus Fedora is a clearly choice there. Fedora also
still provides the infrastructure for building flatpaks, hosting to distribute
and mirror them, review of flatpak image manifests, quality testing before
release, and more. Essentially the things that Fedora already does for
software provided via RPMs, are still beneficial to at least some extent
when using flatpaks.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Daniel P. Berrange]

On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
> On Mon, 2017-07-10 at 00:46 +0200, Kevin Kofler wrote:
> > Jaroslav Reznik wrote:
> > > = System Wide Change: Graphical Applications as Flatpaks =
> > > https://fedoraproject.org/wiki/Changes/Graphical_Applications_as_Fl
> > > atpaks
> > > 
> > > Change owner(s):
> > > * Owen Taylor 
> > 
> > This change is leaving several questions unanswered:
> > 
> > * As I understand it, those Flatpaks are going to be built from RPMs.
> > Is the intent to ship both the original RPMs and the Flatpak or only
> > the Flatpak (or is this going to depend on the individual package)?
> > And if the former, are the shipped RPMs going to be the FHS-compliant 
> > version or the one relocated into Flatpak's proprietary prefix?
> 
> The rebuilt RPMs are really only interesting within Flatpaks - they
> will be available for download from Koji, but there would be no reason
> for a user to do so.
> 
> As for standard application RPMs, it's really going to be something
> we figure out over time. My vision is something like:
> 
>  F27: packagers are *able* to create Flatpaks of their application.
>   They must also maintain standard RPMs.
> 
>  F28: packagers (of graphical applications) are *encouraged* to create
>   Flatpaks of their applications along side standard RPM packaging.
>   They *may* drop the standard RPM packaging if there is good
>   reason to.
> 
>  F29: packagers (of graphical applications) must create Flatpaks of
>   their applications if possible. They *may* keep standard RPM
>   packaging.
> 
> But this is really highly dependent on how modularity work happens more
> widely in Fedora. "standard RPM packaging" assumes we still have
> a F tag in Koji where everything is built together with common
> coordinated dependencies.

If I look at this from my POV as the upstream maintainer of a graphical
application wishing to make it widely available to users of many distros.
The question is whether it is beneficial for me to join Fedora packaging
world to package my app, or whether to package it standalone as a flatpak
and never get involved in Fedora at all.

With the proposed F27 rule here, I would have less work todo if I just
built my app as a flatpak, as I can avoid creating RPMs and just build
a single flatpak that should work on all distros. IOW by mandating
continued creation of RPMs, alongside flatpaks, we would be discouraging
people from becoming Fedora maintainers. 

Thus could suggest more flexibility - require continued maint of RPMs
for *existing* applications in Fedora only, to give some grace period
where we figure out how to provide a seemless upgrade path for people
who have an existing RPM installed to magically replace it with flatpak.
Anyone wishing to package a *new* application in F27, however, should be
able to straight to flatpaks only as there's no upgrade path issue to
worry about.

This would encourage upstream app maintainers to join Fedora to make
use of the review, build & distribution mechanisms for flatpaks, without
forcing them todo extra work to create RPMs too.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Mingw RPM deps broken [Re: Fedora rawhide compose report: 20170708.n.0 changes]

[Daniel P. Berrange]

On Sat, Jul 08, 2017 at 02:40:42PM +, Fedora Rawhide Report wrote:

> Broken deps for x86_64
> --
> [mingw-atkmm]
>   mingw32-atkmm-2.24.2-3.fc26.noarch requires mingw32(libglibmm-2.4-1.dll)
>   mingw64-atkmm-2.24.2-3.fc26.noarch requires mingw64(libglibmm-2.4-1.dll)
> [mingw-freeimage]
>   mingw32-freeimage-3.17.0-7.fc26.noarch requires mingw32(libraw-16.dll)
>   mingw64-freeimage-3.17.0-7.fc26.noarch requires mingw64(libraw-16.dll)
> [mingw-gtkmm24]
>   mingw32-gtkmm24-2.24.5-2.fc26.noarch requires 
> mingw32(libgiomm-2.4-1.dll)
>   mingw32-gtkmm24-2.24.5-2.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-gtkmm24-2.24.5-2.fc26.noarch requires 
> mingw64(libgiomm-2.4-1.dll)
>   mingw64-gtkmm24-2.24.5-2.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-gtkmm30]
>   mingw32-gtkmm30-3.22.0-2.fc26.noarch requires 
> mingw32(libgiomm-2.4-1.dll)
>   mingw32-gtkmm30-3.22.0-2.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-gtkmm30-3.22.0-2.fc26.noarch requires 
> mingw64(libgiomm-2.4-1.dll)
>   mingw64-gtkmm30-3.22.0-2.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-gtkspellmm30]
>   mingw32-gtkspellmm30-3.0.5-2.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-gtkspellmm30-3.0.5-2.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-libglademm24]
>   mingw32-libglademm24-2.6.7-22.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
> [mingw-libvirt-glib]
>   mingw32-libvirt-glib-1.0.0-2.fc26.noarch requires mingw32(libvirt-0.dll)
>   mingw32-libvirt-gobject-1.0.0-2.fc26.noarch requires 
> mingw32(libvirt-0.dll)
>   mingw64-libvirt-glib-1.0.0-2.fc26.noarch requires mingw64(libvirt-0.dll)
>   mingw64-libvirt-gobject-1.0.0-2.fc26.noarch requires 
> mingw64(libvirt-0.dll)
> [mingw-libxml++]
>   mingw32-libxml++-2.40.1-3.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-libxml++-2.40.1-3.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-pangomm]
>   mingw32-pangomm-2.40.1-2.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-pangomm-2.40.1-2.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)
> [mingw-plotmm]
>   mingw32-plotmm-0.1.2-22.fc26.noarch requires 
> mingw32(libglibmm-2.4-1.dll)
>   mingw64-plotmm-0.1.2-22.fc26.noarch requires 
> mingw64(libglibmm-2.4-1.dll)

It appears that the /usr/lib/rpm/mingw-find-{requires,provides}.sh scripts
are broken. New builds are ending up with almost no provides lists, which
is in turn causing all dependant packages to report broken deps like this.

  https://bugzilla.redhat.com/show_bug.cgi?id=1468993

Early June was the last time I see this working correctly so far, so
potentially any mingw package built in rawhide since that time has
broken deps and will need a rebuild once this is fixed

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: floppy-support being retired (was: Retiring Packages with Broken Dependencies in branched (2017-06-26))

[Daniel P. Berrange]

On Wed, Jun 28, 2017 at 11:03:09AM +0200, Björn Persson wrote:
> t...@fedoraproject.org wrote:
> > floppy-support bruno  162 weeks ago 
> 
> So are floppies now definitely a thing of the past according to Fedora?

This message is simply Fedora is saying that the package is being retired
because it has broken dependencies, which the maintainer has not fixed in
a timely manner. Perhaps the maintainer doesn't care about the package any
more, or doesn't have time for it, or any number of other reasons. That's
just one maintainer though. If someone else cares about this package,
they could volunteer to become maintainer, and fix the package, at which
point there is no requirement for it to be retired.

Now if the kernel's 'floppy' module is removed from the build, that would
be an explicit statement that floppies are no longer supported, but AFAIK,
all we've done in the kernel is turn off auto-loading of 'floppy' - it can
still be loaded explicitly.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: /usr/bin/qemu-kvm symlink

[Daniel P. Berrange]

On Sat, Jun 17, 2017 at 05:25:18PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> 
> I was told [1] that /usr/bin/qemu-kvm is obsolete, and that the right
> thing is to use 'qemu-system-x86_64 -enable-kvm', and that Arch and
> Gentoo and qemu upstream don't support /usr/bin/qemu-kvm. Fedora provides
> /usr/bin/qemu-kvm as a shell wrapper on amd64 and i386 architectures.
> 
> My questions are:
> 1. do we plan to keep this wrapper indefinitely?

Probably, since there's plenty of installs from older Fedora that
reference that path.

> 2. wouldn't it make sense to convince upstream to provide /usr/bin/qemu-kvm
>which would mean "provide accelerated emulation of current architecture"?
>
> Non-accelerated qemu is unusable for many purposes..., and often you
> just want the current architecture, so it'd be nice to have a shortcut
> for that.

The way you configure QEMU for different architectures varies considerably,
so having a consistent binary doesn't really simply things to any great
degree, as you still have to know alot of architecture specific things to
provide a good configuration.

Tools like virt-install give a way to setup guests in a simpler manner
while hiding most of the architecture specific differences, as well as
defaulting to using KVM.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Rawhide: where for art thou? (why no rawhide composes recently)

[Daniel P. Berrange]

On Tue, Jun 13, 2017 at 07:11:21AM -0600, Kevin Fenzi wrote:
> Greetings.
> 
> Some folks may have noticed that there have been no completed rawhide
> composes in a while (13 days as of today).
> 
> This has been due to a variety of bugs and issues, along with pungi now
> failing composes that don't have all required release blocking items.
> 
> Here's a partial list:
> 
> 2017-06-01 - lorax traceback, bug 1457055
> 2017-06-02 - another lorax issue, bug 1457906
> 2017-06-03 - cloud base failed in anaconda, bug 1458509
> 2017-06-04 - ditto
> 2017-06-05 - ditto
> 2017-06-06 - pungi bug - https://pagure.io/pungi/issue/641
> 2017-06-07 - ditto
> 2017-06-08 - ditto
> 2017-06-09 - ditto
> 2017-06-10 - ditto
> 2017-06-11 - ditto
> 2017-06-12 - ditto
> 2017-06-12.1 - pungi bug fixed, but hit libgtop2 broken deps in metacity
> that failed the comppose. I fixed those (and control-center) last night.
> 2017-06-13 - still running, cross your fingers.

[snip]

> Anyhow, hopefully we will have a rawhide compose today, and if not I
> will keep poking it to get it going...

Unfortunately while the latest compose succeeded, actually trying to
use the installer resulted in a python traceback pretty much immediately

   https://bugzilla.redhat.com/show_bug.cgi?id=1461469

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: mp3 encoding now ok

[Daniel P. Berrange]

On Thu, May 04, 2017 at 09:07:25AM -0400, Christian Schaller wrote:
> Hi, not sure why Spot hasn't chimed in, but yes this
> has been run through legal. Tom and I where on the same
> email thread with the laywers.

For clarity someone with authority presumably ought to remove "MP3 Support"
from the list of Forbidden items that package reviewers are required to
check submissions against:

https://fedoraproject.org/wiki/Forbidden_items?rd=ForbiddenItems#MP3_Support

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Deprecated net-tools? Mass bug filing?

[Daniel P. Berrange]

On Tue, May 16, 2017 at 11:29:42PM +0100, James Hogarth wrote:
> Hi,
> 
> It was pointed out on IRC to me tonight that there are actually a
> reasonable number of packages that still depend on net-tools[0].
> 
> This has been deprecated for a long time now and we really should
> strive to have everything use iproute2 instead so that there is no
> longer a need to keep the deprecated package about, other than if
> someone explicitly really wants netstat or ifconfig for some reason.
> 
> Is the best way to handle this a mass bug filing?

Converting apps from nettools to iproute is often non-trivial piece
of work. As such isn't really something Fedora package maintainers
should look to undertake as the risk of introducing regressions is
non-negligible.  Bug reports really need to go the corresponding
upstream communities to get anything done. 


Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What is your opinion on "sudo pip" fix for Fedora 27?

[Daniel P. Berrange]

On Thu, Apr 27, 2017 at 11:48:06PM +1000, Nick Coghlan wrote:
> On 27 April 2017 at 23:04, Daniel P. Berrange <berra...@redhat.com> wrote:
> > On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote:
> >> Their approach means that any harm caused by "sudo pip install X" can
> >> subsequently be fully reversed by doing "sudo pip uninstall X".
> >>
> >> At this moment, this is NOT true for Fedora and derivatives. Instead,
> >> the remediation step here is "sudo pip uninstall X && sudo dnf
> >> reinstall " where you have to:
> >>
> >> 1. Figure out what "" needs to be
> >> 2. Hope that whatever you broke didn't affect your ability to run
> >> "sudo dnf reinstall"
> >
> > Yep, recovering the system python install to a pristine state after
> > 'devstack' has done its stuff is very painful right now :-(
> >
> > devstack was originally written for Ubuntu systems, so I guess they
> > don't suffer as much due to the Debian specific change you describe
> > above.
> >
> > Which location takes priority in Debian if the same module is installed
> > in both places ? The DPKG location, or the Pip location ? Presumably it
> > would have to be the pip version that takes priority if you want it to
> > be usable for updating the (likely older) distro provided versions.
> 
> Aye, /usr/local/lib has priority:
> 
> $ docker run --rm ncoghlan/debian-python python3 -m site
> sys.path = [
> '/',
> '/usr/lib/python3.4',
> '/usr/lib/python3.4/plat-x86_64-linux-gnu',
> '/usr/lib/python3.4/lib-dynload',
> '/usr/local/lib/python3.4/dist-packages',
> '/usr/lib/python3/dist-packages',
> ]
> USER_BASE: '/root/.local' (doesn't exist)
> USER_SITE: '/root/.local/lib/python3.4/site-packages' (doesn't exist)
> ENABLE_USER_SITE: True
> 
> User level package installs take priority over system level ones
> (regardless of distro), so the current container build use case for
> root level pip installations can typically be met equally well by
> running as a non-root user inside the container and doing "pip install
> --user ...". Unfortunately, as with the venv option, there are a *lot*
> of container build scripts out there that don't do that :(

It would be nice if openstack devstack didn't install anything with
sudo and instead kept it all isolated as a user, but I don't see
such a change happening. So anything we can do to reduce the damage
of "sudo pip" is welcome, particularly if it aligns with what Debian
already do.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What is your opinion on "sudo pip" fix for Fedora 27?

[Daniel P. Berrange]

On Thu, Apr 27, 2017 at 04:32:09PM +1000, Nick Coghlan wrote:
> On 27 April 2017 at 11:47, Nico Kadel-Garcia  wrote:
> > On Wed, Apr 26, 2017 at 7:13 AM, Charalampos Stratakis
> >> At the present time, running sudo pip3 in Fedora is not safe.
> >> Pip shares its installation directory with dnf, can remove
> >> dnf-managed files and generally break the Python 3 interpreter.
> >
> > This is true of every version of pip, not merely pip3. It was also
> > true of CPAN, and of many gradle, maven, and ant working environments
> > that semi-randomly collate the very latest versions of indeterminate
> > components and spray them on top of your system workspace with their
> > own quite distinct ideas about packaging and versioning.
> >
> > There is no solution to this problem, except to use tools like
> > "pyvenv" to set aside secluded workspaces for Python modules and their
> > dependencies assembly. So, for most developers, they *should not* use
> > "sudo pip". They should remain in user space, or possibly in shared
> > workspaces, to avoid overwriting system components.
> 
> Nothing is changing in terms of *recommended* practices. This change
> proposal is entirely about harm mitigation for the cases where users
> *do* run "sudo pip ...", either because that's their instinctive
> reaction to a permissions error, or because some misguided
> installation instructions for a 3rd party package advised them to do
> it.

FWIW, Openstack's  devstack script will use "sudo pip" to install
python bits required by openstack and thus often splatter any RPM
managed versions of the same modules.


> Debian and derivatives already mitigate the potential harm for these
> cases by requiring the "--install-layout=deb" option to be passed to
> get distutils to install into the system directories rather than doing
> it by default: https://wiki.debian.org/Python#Deviations_from_upstream
> 
> Their approach means that any harm caused by "sudo pip install X" can
> subsequently be fully reversed by doing "sudo pip uninstall X".
> 
> At this moment, this is NOT true for Fedora and derivatives. Instead,
> the remediation step here is "sudo pip uninstall X && sudo dnf
> reinstall " where you have to:
> 
> 1. Figure out what "" needs to be
> 2. Hope that whatever you broke didn't affect your ability to run
> "sudo dnf reinstall"

Yep, recovering the system python install to a pristine state after
'devstack' has done its stuff is very painful right now :-(

devstack was originally written for Ubuntu systems, so I guess they
don't suffer as much due to the Debian specific change you describe
above.

Which location takes priority in Debian if the same module is installed
in both places ? The DPKG location, or the Pip location ? Presumably it
would have to be the pip version that takes priority if you want it to
be usable for updating the (likely older) distro provided versions.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Daniel P. Berrange]

On Mon, Mar 20, 2017 at 01:16:56PM +, Tomasz Kłoczko wrote:
> On 20 March 2017 at 09:50, Daniel P. Berrange <berra...@redhat.com> wrote:
> 
> > > I've already described this multiple times trying to use different
> > > descriptions/analogies about well known *glibc NSS ABI issue*.
> > > You cannot fix this issue in *any libc implementation which is using
> > NSS*.
> >
> > Apps don't need to make use of the affected APIs in glibc and even if they
> > do the problem is not a show stopper as long as you keep the app build in
> > sync. So while this is a potential problem, it is not a blocking problem
> > that justifies throwing the baby out with the bath water.
> 
> 
> People are linking static binaries to not be forced to recompile and/or
> relink such binaries.
> In other words what you wrote is in contradiction with typical case when
> static binaries are used.
> 
> Try to write simple "hello_nss" program communicating over network
> establishing connectivity using host name.
> Such program will be using network NSS map to resolve host name to IP over
> "hosts" NSS map.
> When you will have static binary try to execute "strace -e trace=file
> ./hello_nss" and you will see loading by such program libnss_dns.so and
> libnss_files.so DSOs.
> Such risk from NSS area is probably biggest in context of some random Linux
> users trying to build and use 100% statically linked binaries.
> 
> Typical upgrade scenario with NSS issue which may hit hardly distribution
> however is with other NSS maps.
> In such upgrade scenario some programs are changing user and group during
> upgrade on just written to the fs tree new files.
> Such program will be using "passwd" and "group" NSS maps to resolve user
> names and groups to UIDs and GIDs.

I never said anything about either needing to upgrade or needing to resolve
hostnames / user names / group names.

I use Fedora to build statically linked binaries for certain embedded
devices I build and they have no network connectivity, nor need to have
user/group lookups. Nor do they receive yum updates. When I update the
software, I simply build it again on latest Fedora packages. So the
problem you describe are a non-issue in my usage of static libraries.

> > Other reasons are like constant changes in kernel<>userspace changes on
> > all
> > > unices are part of the problem as well.
> >
> > Linux doesn't constantly break kernel<->user ABI, so that's a non-issue.
> 
> 
> Really? Hmm .. [censored =8-O] so it must be something really, really new
> .. !!!
> (OKi .. quick unpack glibc source code and .. )
> 
> [tkloczko@domek glibc-2.25-80-ga10e9c4]$ ./configure --help
> `configure' configures GNU C Library (see version.h) to adapt to many
> kinds of systems.
> 
> [..]
> 
>   --enable-kernel=VERSION *compile for compatibility with kernel not older 
> than
>   VERSION*
> 
> So please explain why in glibc autoconf still is such option? Can you do
> this?

Some system calls are found to be broken by design & not extensible. In those
cases Linux may introduces new syscalls with improved design to replace them.
The old syscalls still exist in Linux. GLibc could try the new syscall, and
fallback to the old syscall if missing. The configure arg is just a way to
drop the fallback code if the platform doesn't need to care about running
with old kernels. Linux hasn't broken ABI compatibility here - on the contrary
it has intentionally maintained ABI compatibility by introducing a new syscall
in parallel with the existing syscall, instead of simply changing the original
syscall.


> So .. Daniel you are working in RedHat. So .. in RedHat probably still is
> working *Ulrich Drepper* who is glibc maintainer.

Ulrich hasn't worked for Red Hat for many many many years.

> Offer him free lunch to have opportunity to talk with him face about this
> subject (you can send me the bill after all :) ).
> You can do this because if not every day probably time to time you can have
> him on "normal beret throwing distance".
> (I'm in UK so I would be forced to use ballistic beret).
> 
> Please don't try to convince me. Rally forget about me. I'm probably one of
> the smallest beatles here.
> Just please sit down with him and try to convince *him* that there is no at
> all risk here.

I'm not saying there is no risk. No one has ever suggested it works perfectly
in all scenarios. I'm simply saying that there *are* valid usage scenarios
where it works just fine and thus deleting this support from Fedora is
wrong.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Daniel P. Berrange]

On Sun, Mar 19, 2017 at 01:38:31AM +, Tomasz Kłoczko wrote:
> On 18 March 2017 at 22:26, Richard W.M. Jones  wrote:
> 
> > I read through the whole thread and I still don't understand why
> > packaging glibc-static in Fedora is not a good thing.
> >
> 
> I've already described this multiple times trying to use different
> descriptions/analogies about well known *glibc NSS ABI issue*.
> You cannot fix this issue in *any libc implementation which is using NSS*.

Apps don't need to make use of the affected APIs in glibc and even if they
do the problem is not a show stopper as long as you keep the app build in
sync. So while this is a potential problem, it is not a blocking problem
that justifies throwing the baby out with the bath water.

> Other reasons are like constant changes in kernel<>userspace changes on all
> unices are part of the problem as well.

Linux doesn't constantly break kernel<->user ABI, so that's a non-issue.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Static libraries in Fedora distribution (Was: Re: [Help Wanted] PPC64LE build for thrift)

[Daniel P. Berrange]

On Wed, Mar 15, 2017 at 09:56:50AM -0700, Josh Stone wrote:
> On 03/14/2017 05:05 PM, Jonathan Wakely wrote:
> > If glibc-static was removed from Fedora and that change propagated to
> > RHEL I know of companies that might stop being customers of Red Hat.
> 
> Even if Fedora removed it, we could still make the business decision to
> add it back to RHEL.
> 
> > Being unable to statically link their applications would be a
> > showstopper for some, and would cause them to move to a different
> > distro.
> 
> This may still be a useful consideration for Fedora itself.  Would we
> alienate anyone if Fedora removed glibc-static?

Yes, you would prevent us from being able to build static binaries for
the QEMU system emulators in Fedora QEMU packages. This in turn prevents
them from being used to provide seemless execution from non-native
architecture chroots / containers. This is used for example, by flatpack
to allow non-native architecture compilation, or as well as by myself
for various personal projects needing non-native compilation environments.

I agree there are many reasons why static libraries are a bad idea in
general, particularly the security implications, but they are none the
less useful at times and not every usage scenario has the same security
requirements.

NB, throwing out all the -static RPMs doesn't magically remove static
compilation from Fedora. There are entire non-C language toolchains in
Fedora that are based on static compilation - eg OCaml and Go 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel P. Berrange]

On Wed, Mar 15, 2017 at 11:32:35AM -0400, Dusty Mabe wrote:
> 
> 
> On 03/15/2017 05:17 AM, Daniel P. Berrange wrote:
> > 
> > Sure, if udev maintainers are willing to ship the kvm rule by default,
> > that's fine with me for reason you suggest. I simply don't think it'll
> > have any effect on usage of /dev/kvm inside containers
> > 
> 
> Does that mean you assume my scenario I outlined is incorrect? The
> only reason we are having this discussion is because i found that
> changing the permissions of /dev/kvm on the host from 600 to 666 made
> it so that I could run libvirt inside a container, which would mean
> that if does have an effect on usage of /dev/kvm inside a container.

Oh, wait I think I see - you don't have qemu installed in the host
at all - you only installed it inside a docker image, but docker
is just copying the host permissions, and thus see the default
permissions from the kernel.

> I could be "using it wrong", but would like for you to tell me why
> what I'm doing is invalid.

While Docker copies the permissions from host devices, I don't think
that is something it is nice to rely on. Different operating systems
have different views on what default permissions are. So if you build
a Docker image that relies on the host OS having given /dev/kvm
particular permissions, your Docker image is going to be non-portable.

IOW while moving the udev rule out of the QEMU rpm into the udev RPM
would fix it for future Fedora, your docker image is going to be
unable to reliably run on other OS distros (whether older Fedora or
Debian which has restrictive /dev/kvm by default).

I don't see any way to force docker to give the device different
permissions when using the --device flag to launch a container.
In absence of that the only other option is to use an entrypoint
script to chmod the file when your container starts, but that
requires the container to run privileged which is bad. I think
ideally Docker would provide some way to give explicit permissions
so your container is isolated from decisions OS distros make about
default permissions in the host. 

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel P. Berrange]

On Tue, Mar 14, 2017 at 05:35:54PM -0400, Daniel J Walsh wrote:
> 
> 
> On 03/14/2017 05:18 PM, Dusty Mabe wrote:
> >
> > On 03/14/2017 05:15 PM, Daniel J Walsh wrote:
> >>
> >> On 03/14/2017 05:02 PM, Dusty Mabe wrote:
> >>> On 03/14/2017 04:56 PM, Daniel J Walsh wrote:
> >>>> On 03/14/2017 04:29 PM, Daniel P. Berrange wrote:
> >>>> I guess if you volume/bind mount the device into the container you could
> >>>> see an issue,
> >>>> but most containers that deal with /dev/kvm are going to be run as root,
> >>>> anyways.
> >>> I was running with --privileged, still got permission denied until I
> >>> changed permissions of /dev/kvm to 666.
> >>> ___
> >>> devel mailing list -- devel@lists.fedoraproject.org
> >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> >> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm
> >> crw-rw-rw-. 1 root 36 system_u:object_r:container_file_t:s0:c303,c737 10, 
> >> 232 Mar 14 21:12 /dev/kvm
> >> # chmod 600 /dev/kvm 
> >> # docker run -ti --device /dev/kvm fedora ls -lZ /dev/kvm 
> >> crw---. 1 root 36 system_u:object_r:container_file_t:s0:c281,c442 10, 
> >> 232 Mar 14 21:13 /dev/kvm
> >>
> >> So using --device to add the device to the container just maintains the 
> >> permission of the host
> >> for the device you added.  Whether it is volume mounted in or specified 
> >> via --device, at least
> >> from dockers point of view. 
> > I'm not sure of your point. I was just trying to say that whether i
> > was root or not did not seem to matter. I still got permission denied
> > if perms were 600 and not 666. I'm working off of memory here, so it's
> > possible somebody will prove me wrong.
>
> Most likely libvirt or whoever is launching the containers is not running
> as root, so it is being blocked access.

It is simpler than that. When you ask libvirt to assign a device to a
container it will simply mknod() in the container's private /dev, with
permissions 0700. If the container needs to make that available to
mon-privileged users inside the container, its "init" has to arrange
to set permissions further.

For Docker, I'm unclear whether it is also just doing a mknod in the
container's /dev, or whether it is bind mounting the host device node.
Either way, udev isn't involved inside the container.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel P. Berrange]

On Tue, Mar 14, 2017 at 11:38:51PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Mar 14, 2017 at 08:29:00PM +0000, Daniel P. Berrange wrote:
> > On Tue, Mar 14, 2017 at 08:09:00PM +, Richard W.M. Jones wrote:
> > > Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
> > > 
> > > Currently if you install a minimal-ish, non-"Virtualization Host"
> > > Fedora, then the permissions on the /dev/kvm device are:
> > > 
> > >   crw---. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> > > 
> > > (I believe this is because of some kernel defaults for the device.  In
> > > any case there seems to be no base install udev rule which applies a
> > > `MODE=' line explicitly for /dev/kvm).
> > > 
> > > There mere act of installing the qemu package adds a new udev rule
> > > which changes the permissions:
> > > 
> > >   [root@rawhide ~]# ll /dev/kvm 
> > >   crw---. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> > >   [root@rawhide ~]# dnf -y install qemu-system-x86
> > >   //...
> > >   [root@rawhide ~]# ll /dev/kvm
> > >   crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> > > 
> > > I don't have a problem with any of that and I'm not saying that the
> > > permissions should be more restrictive, but for balance I will note
> > > that in Debian /dev/kvm is more restrictive (see comment in the bug
> > > above).
> > > 
> > > The problem raised in the bug above is that with containers people
> > > will wish to install qemu or libvirt or other tools inside the
> > > containers, but not necessarily have qemu installed on the host.  In
> > > that case, they will always see /dev/kvm with mode 0600, ie. generally
> > > unusable for them.
> > 
> > I'm fuzzy about the issue faced with containers. Containers will usually
> > have a separate /dev that is populated by the container mgmt engine (whether
> > docker, libvirt, lxc or something else). That mgmt engine is responsible for
> > setting permissions of /dev/kvm in the container's /dev if the user asked 
> > for
> > /dev/kvm to be made available. udev should never run inside a container - it
> > is only supposed to run in host context. So any udev rules that manipulate
> > /dev/kvm permissions will only ever be used in host context and never have
> > any effect on containers.
> > 
> > The bug listed above doesn't actually describe any real problem with
> > containers & /dev/kvm - my reading is that the bug is just thinking
> > about a hypothetical  future problem, but since udev isn't involved
> > in containers' /dev mgmt, I don't think there's a bug that needs fixing
> > here.
> 
> This applies to any system where kvm is to be used by unprivileged users
> without qemu package being installed. It is possible to use kvm in this
> way, e.g. by using self-compiled qemu, or some alternative or whatever.
> So maybe we should move the rules for /dev/kvm to
> /usr/lib/udev/rules.d/50-udev-default.rules.

Sure, if udev maintainers are willing to ship the kvm rule by default,
that's fine with me for reason you suggest. I simply don't think it'll
have any effect on usage of /dev/kvm inside containers

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Default permissions on /dev/kvm

[Daniel P. Berrange]

On Tue, Mar 14, 2017 at 08:09:00PM +, Richard W.M. Jones wrote:
> Re: https://bugzilla.redhat.com/show_bug.cgi?id=1431876
> 
> Currently if you install a minimal-ish, non-"Virtualization Host"
> Fedora, then the permissions on the /dev/kvm device are:
> 
>   crw---. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> 
> (I believe this is because of some kernel defaults for the device.  In
> any case there seems to be no base install udev rule which applies a
> `MODE=' line explicitly for /dev/kvm).
> 
> There mere act of installing the qemu package adds a new udev rule
> which changes the permissions:
> 
>   [root@rawhide ~]# ll /dev/kvm 
>   crw---. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
>   [root@rawhide ~]# dnf -y install qemu-system-x86
>   //...
>   [root@rawhide ~]# ll /dev/kvm
>   crw-rw-rw-. 1 root root 10, 232 Mar 14 15:51 /dev/kvm
> 
> I don't have a problem with any of that and I'm not saying that the
> permissions should be more restrictive, but for balance I will note
> that in Debian /dev/kvm is more restrictive (see comment in the bug
> above).
> 
> The problem raised in the bug above is that with containers people
> will wish to install qemu or libvirt or other tools inside the
> containers, but not necessarily have qemu installed on the host.  In
> that case, they will always see /dev/kvm with mode 0600, ie. generally
> unusable for them.

I'm fuzzy about the issue faced with containers. Containers will usually
have a separate /dev that is populated by the container mgmt engine (whether
docker, libvirt, lxc or something else). That mgmt engine is responsible for
setting permissions of /dev/kvm in the container's /dev if the user asked for
/dev/kvm to be made available. udev should never run inside a container - it
is only supposed to run in host context. So any udev rules that manipulate
/dev/kvm permissions will only ever be used in host context and never have
any effect on containers.

The bug listed above doesn't actually describe any real problem with
containers & /dev/kvm - my reading is that the bug is just thinking
about a hypothetical  future problem, but since udev isn't involved
in containers' /dev mgmt, I don't think there's a bug that needs fixing
here.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages dropping anything in /etc/systemd/system

[Daniel P. Berrange]

On Tue, Mar 14, 2017 at 06:31:46AM -0400, Simo Sorce wrote:
> Hello,
> as per subject, what is the stance on dropping anything there from a
> rpm ? Either marked as %{config} or not ?
> 
> My naive reading of the Packaging guidelines is that nothing should be
> dropped in there by a package, but the guidelines only explicitly talk
> about not putting "service" files in there.

The packaging guidelines actually use 'unit file' as the term

  https://fedoraproject.org/wiki/Packaging:Systemd#Filesystem_locations

  "Packages with systemd unit files *must* put them into %{_unitdir}. 
   %{_unitdir} evaluates to /lib/systemd/system"

From that I'd say any RPM putting unit files into /etc/systemd/system is
not compliant, regardless of whether its a full unit file, or a override
unit file in a '.d' directory.

> There is now a debate with a package maintainer that is putting in the
> etc/systemd/system/<..> directory what he calls a "configuration file,
> not a unit file".

A unit file provides configuration for a service (or other type of
systemd resource). So saying 'configuration file, not a unit file'
doesn't make conceptual sense - they're one & the same thing.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: policy on changes in or introduction of new dependencies

[Daniel P. Berrange]

On Fri, Feb 24, 2017 at 04:24:16PM +0100, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 24 February 2017 at 15:31, Daniel P. Berrange wrote:
> > On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen wrote:
> > > On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
> > > <domi...@greysector.net> wrote:
> > > > On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
> > > 
> > > > I have nothing against delivering latest and greatest software to our
> > > > users and this proposal is not against that goal, either. However,
> > > > package maintainers are not supposed to simply take what upstream
> > > > releases and pass it on to the users without considering the impact.
> > > 
> > > I think that may be the differing of opinions in this discussion as I
> > > don't think there is a definitive answer. Some packagers believe that
> > > whatever upstream requires to get the software is what happens, other
> > > packagers believe that it isn't. Many packagers just want the XYZ
> > > package to be there so they can build the thing they really care about
> > > so if the upstream needed ten new dependencies.. we add 10 new
> > > dependencies.
> 
> And that's fine. Just don't make me jump through hoops to find out why.
> One sentence in the changelog or a pointer to upstream release notes is
> all I'm asking for. That and a little bit of consideration if such an
> update is really necessary in a stable release. Surely that's not much
> to ask. Or is it?

I question how useful that is going to be in practice. Realistically the
RPM changelog is going to say little more than

"Added new dependancy libfoo.so"

which isn't really adding any value IMHO. Explaining why a dependancy was
added is useful, but that needs packagers to potentally understand the
upstream app decision in significant detail, and such an explanation is
often not simple enough to explain in a useful level of detail in an
RPM changelog. Unless you want long paragraphs of text in the RPM changelog
which IMHO would not be appropriate.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: policy on changes in or introduction of new dependencies

[Daniel P. Berrange]

On Fri, Feb 24, 2017 at 08:48:43AM -0500, Stephen John Smoogen wrote:
> On 23 February 2017 at 12:24, Dominik 'Rathann' Mierzejewski
>  wrote:
> > On Thursday, 23 February 2017 at 14:23, Neal Gompa wrote:
> 
> > I have nothing against delivering latest and greatest software to our
> > users and this proposal is not against that goal, either. However,
> > package maintainers are not supposed to simply take what upstream
> > releases and pass it on to the users without considering the impact.
> 
> I think that may be the differing of opinions in this discussion as I
> don't think there is a definitive answer. Some packagers believe that
> whatever upstream requires to get the software is what happens, other
> packagers believe that it isn't. Many packagers just want the XYZ
> package to be there so they can build the thing they really care about
> so if the upstream needed ten new dependencies.. we add 10 new
> dependencies.

Upstream may not allow packagers to have any viable choices. If upstream
has added a new dependancy, there's no guarantee it is optional. So if the
new version is required in Fedora, then often there's no choice but to
accept the new dependancy. The alternative is to be stuck on the old
(possibly insecure) version forever, or fork the code, neither of which
are really acceptable options. Even if the dependancy is optional, disabling
it may cause Fedora to loose functionality vs the previously packaged
version, so it is in effect mandatory.

Any rules about adding new dependencies in Fedora will quickly come up
against these hard realities, when dealing with new upstream versions.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is it possible to manually insert shared library deps in an RPM?

[Daniel P. Berrange]

On Fri, Feb 03, 2017 at 02:45:08PM +, David Howells wrote:
> Hi,
> 
> gcc and cross-gcc currently dynamically load the isl-0.14 shared library -
> which means that rpm-build doesn't automagically detect a:
> 
>   libisl.so.13()(64bit)
> 
> but, rather, the gcc binary rpm must include a:
> 
>   Requires: isl = %{isl_version}
> 
> clause.
> 
> Is it possible to instead do something like:
> 
>   Requires: libisl.so.13()(64bit)
> 
> (though this doesn't work because it complains about an illegal char) so that
> it is pegged to the major version of the library rather than the specific isl
> version?

The automatic requires are added based on output of an external program.
You can override which program is used in the spec file. So you could
provide a custom script which calls the original script, and then also
output the extra missing library requires

See the section "requires filtering"

  https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies

instead of filtering you'd be augmenting, but that's fine.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: How to build both python 2 and 3 bindings from autotools?

[Daniel P. Berrange]

On Thu, Jan 26, 2017 at 09:10:30AM +1000, Peter Hutterer wrote:
> Before I start hacking up something nasty I figured it's better to ask: how
> do I build both py2 and py3 bindings from a package using autotools (i.e.
> AM_PATH_PYTHON)? 
> 
> So far my idea revolves around installing both python-devel packages and
> overriding PYTHON in each %build , etc. But maybe there's a
> simpler solution?
> 
> Package in question is evemu and yes, we are also the upstream maintainers
> so if there's a more sensible solution we can move that into upstream.

I'd suggest splitting the bindings out into a completely independant
source package and uploading that to PyPi. That facilitates people
using python virtualenvs to easily build the binding against arbitrary
python versions as many times as they like, as well as packaging it
against both py2+3 concurrently in Fedora. Bonus points if you can
make the python binding able to dynamically build against multiple
different versions of the C library. This is the approach we took for
libvirt when adding py3 support, rather than try to hack something up
with python in-tree to the main C library.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Is there something wrong with the Koji builders?

[Daniel P. Berrange]

On Wed, Jan 18, 2017 at 11:55:38AM -0700, Kevin Fenzi wrote:
> On Wed, 18 Jan 2017 07:22:49 -0500 (EST)
> Charalampos Stratakis  wrote:
> 
> > Python 3 started failing on i686, x86_64 and arm only.
> > 
> > https://koji.fedoraproject.org/koji/taskinfo?taskID=17313924
> > 
> > The failures come from the test_socket.py [0], test_aead_aes_gcm [1]
> > and more specifically this line [2] with the message: OSError: [Errno
> > 22] Invalid argument
> > 
> > This test is checking Python's interface for the kernel crypto API
> > (added in 3.6 [3]).
> > 
> > [0]
> > https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5473
> > [1]
> > https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5472
> > [2]
> > https://hg.python.org/cpython/file/3.6/Lib/test/test_socket.py#l5497
> > [3] http://bugs.python.org/issue27744
> 
> Thats nothing to do with the buildsystem. Or at least if it is, it's
> not any of the known issues I was working on. 
> 
> As far as I know now everything should be back to working/normal. 
> 
> There were 3 issues: 
> 
> 1. The buildvm's were updated and started crashing under load. They
> would spew oopses and finally reboot. This would result in builds on
> them getting restarted or dying in strange ways. This seems to be
> something particular to their hardware/setup that changed in later
> 4.8.x and early 4.9.x kernels. We are currently running 4.10rc4 on them
> and it's been stable (knock on wood). 
> 
> 2. Sometimes, very rarely dnf would fail downloading packages for the
> build root. We have worked around this by passing dnf via koji several
> mirrors where it can download from, so if it fails on one it should
> fall back to the next and so on. 
> https://pagure.io/fedora-infrastructure/issue/5689
> 
> 3. In some configurations (where there was more than I host to download
> from) koji would fail to download the src.rpm correctly and error out. 
> We are working around this now by just pointing koji at one place for
> these downloads for now until we can get things fixed. 
> https://pagure.io/fedora-infrastructure/issue/5694
> 
> Sorry for all the instability the last few days. 
> 
> If you see any further issues like the above, let me know.

I'm still seeing quite alot of problems today - randomly the arm7 or
ppc task will just sit there in "open" status doing nothing for hours.
If I cancel & rerun the build it works fine, presumably because it hit
a different build instance.

Now I've just seen some builds which succeeded in the build phase
get marked as failed because mock throws an exception handling the
results

https://kojipkgs.fedoraproject.org//work/tasks/1011/17331011/mock_output.log


Finish: run
ERROR: list index out of range
Traceback (most recent call last):
  File "/usr/libexec/mock/mock", line 885, in 
raise
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/libexec/mock/mock", line 704, in main
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.5/site-packages/mockbuild/buildroot.py", line 545, in 
finalize
self._unlock_buildroot()
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
89, in trace
result = func(*args, **kw)
  File "/usr/lib/python3.5/site-packages/mockbuild/mounts.py", line 162, in 
umountall
  File "/usr/lib/python3.5/site-packages/mockbuild/trace_decorator.py", line 
81, in trace
frame = inspect.getouterframes(inspect.currentframe())[1][0]
  File "/usr/lib/python3.5/inspect.py", line 1441, in getouterframes
frameinfo = (frame,) + getframeinfo(frame, context)
  File "/usr/lib/python3.5/inspect.py", line 1414, in getframeinfo
lines, lnum = findsource(frame)
  File "/usr/lib/python3.5/inspect.py", line 804, in findsource
if pat.match(lines[lnum]): break
IndexError: list index out of range

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Daniel P. Berrange]

On Thu, Jan 05, 2017 at 11:03:50AM -0500, Stephen Gallagher wrote:
> # Overview
> 
> For many years, Fedora has supported multilib by carrying parallel-installable
> libraries in /usr/lib[64]. This was necessary for a very long time in order to
> support 32-bit applications running on a 64-bit deployment. However, in 
> today's
> new container world, there is a whole new option.
> 
> I'd like to propose that we consider moving away from our traditional approach
> to multilib in favor of recommending the use of a 32-bit container runtime 
> when
> needed on a 64-bit host.
> 
> 
> ## Advantages
> 
> * Simplification of build-tree creation. We wouldn't have to maintain the 
> lists
> and hacks that are required to make sure that multilib packages land in the
> correct repositories.
> 
> * Less duplication of content in the mirror networks.
> 
> * It will be simpler to create module content without having to reimplement 
> all
> the multilib hacks of above. This is directly relevant to the Base Runtime
> module, whose prototype is today intentionally limited to the primary
> architecture (no multilib).
> 
> * Requires us to maintain and keep up-to-date the 32-bit container base 
> images.
> 
> 
> ## Disadvantages
> 
> * If we eliminate multilib entirely, all applications that use 32-bit libs 
> will
> have to either install a 32-bit host OS or install into a container. This may 
> be
> a difficult transition for some users.
>   * Mitigation: develop and maintain tools to ease this transition.
> 
> * It is unlikely that any clean upgrade path would exist. (We could make it
> *technically* possible, but likely not without breaking 32-bit software not
> installed by RPM.
> 
> * Requires us to maintain and keep up-to-date the 32-bit container base 
> images.
> (Yes, this is both an advantage and disadvantage.)

More work for the end user to keep their systems updated. Containers in
general are a retrograde step in this area, since instead of being able
todo a simple "dnf update" on the host and have everything updated, you
have to do "dnf update" and then figure out how to update each individual
container. Even if we assume the 32-bit container base image lets you use
dnf normally, this change has at least added an extra step for users
as they have to upgrade their 64-bit and 32-bit container via separate
"dnf update" command invokations.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Daniel P. Berrange]

On Thu, Jan 05, 2017 at 11:56:28AM -0500, Stephen Gallagher wrote:
> 
> It might be different if we could build 32-bit sub-packages in the 64-bit mock
> environment, but the tools are *really* not equipped to handle that today (in
> particular because Fedora doesn't do cross-compilation; we just spin up a
> builder of the actual hardware it should run on.)

NB, Fedora does do cross-compilation in some places - many of the QEMU
firmware blobs are cross-compiled, as is the Mingw32/64 toolchain.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Support for older kernels

[Daniel P. Berrange]

On Mon, Dec 19, 2016 at 11:19:06AM +0100, Florian Weimer wrote:
> Do we need to support running current Fedora releases in kernels which are
> older than the initial Fedora kernel for that release?

That is important if we wish to allow a Fedora container of version X
to be run on a host with Fedora version X-N, for some N. Or equivalently
allow a Fedora version X to run as a container on a non-Fedora host (Ubuntu/
RHEL/Debian/whatever) since they'll almost certainly have a different kernel
version to what Fedora initially ships and that can't be assumed to be newer.

> If yes, what are the kernel baselines?  We can go back to releases earlier
> than 3.2 on most architectures because that's the current glibc baseline
> (except x86_64 and i386, where the glibc baseline is 2.6.32).

To maximise container compatibility, we'd want to be quite conservative
in kernel baseline version.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Daniel P. Berrange]

On Tue, Dec 13, 2016 at 12:19:45PM +0200, Alexander Bokovoy wrote:
> On ti, 13 joulu 2016, Alexander Bokovoy wrote:
> > On ti, 13 joulu 2016, Vít Ondruch wrote:
> > > 
> > > 
> > > Dne 12.12.2016 v 16:02 Stephen Gallagher napsal(a):
> > > > On 12/12/2016 04:53 AM, Vít Ondruch wrote:
> > > > > So several questions:
> > > > > 
> > > > > 1) When I have 2 domains I login to with kerberos, how to really make 
> > > > > it
> > > > > work. I don't want to kswitch all the time. I am using Kerberos to
> > > > > authenticate my email client, so I want to keep it working all the 
> > > > > time.
> > > > > 
> > > > There are patches still coming that will switch the fedora packaging 
> > > > tools to
> > > > use GSSAPI rather than Kerberos directly, which will handle 
> > > > auto-selecting the
> > > > right TGT. I'm not sure what the status is on this, but Patrick 
> > > > Uiterwijk (CCed)
> > > > was looking into it.
> > > 
> > > I am probably missing something, but if I am not mistaken, the primary
> > > ticket depends on order of my kinit calls and I am using several apps
> > > which needs kerberos authentication, so I can hardly see how fedora
> > > packaging tools changes can solve the major issue, i.e. if I do kinit
> > > vondr...@fedoraproject.org, this ticket becomes the primary ...
> > The story is always more complex than it seems.
> > 
> > There is Kerberos protocol. There is also GSSAPI interface that allows
> > to wrap Kerberos use under a more general security exchange means. While
> > Kerberos tools can deal with multiple credential caches in the
> > collection only by addressing the currently selected credentials cache,
> > GSSAPI-aware applications enjoy ability to chose which credentials cache
> > from the collection to use based on the realm of the target service.
> > 
> > Koji with a patch to use python-gssapi will have ability to choose the
> > credentials cache automatically based on the realm of the target
> > service, regardless of what credentials cache is active right now in the
> > collection. The version in Fedora right now (1.11.0-1.fc25) is not yet
> > built with the patch to use python-gssapi.
> A small correction: koji 1.11.0-1.fc25 does use python-requests-kerberos which
> uses python-kerberos which is using GSSAPI C library. I verified that
> koji in Fedora 25 does work with credentials cache collections and
> properly chooses the credentials cache which is not the one currently
> active.
> 
> However, default Fedora 25 configuration[1] does not set the default ccache
> name to a collection, only FreeIPA client installer does this.
> 
> As result, if you have no
> 
> [libdefaults]
>   default_ccache_name = KEYRING:persistent:%{uid}
> 
> in your krb5.conf, you are using the defaults compiled into libkrb5
> which is 'FILE:/tmp/krb5cc_%{uid}'. The latter is not a credentials
> cache _collection_ and cannot store multiple credentials from multiple
> realms.
> 
> So, if you'd change default_ccache_name to a KEYRING:..-based version
> and re-logon, you'll be able to maintain multiple credentials caches at
> the same time.
> 
> [1] http://pkgs.fedoraproject.org/cgit/rpms/krb5.git/tree/krb5.conf?h=f25

Actually that's not quite right - if you look at krb5.spec you'll
see it then munges that krb5.conf to add

   default_ccache_name = KEYRING:persistent:%{uid}

so all F25 installs should get that by default - all of my fresh installs
do.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Some preliminary Fedora 25 stats — and future release scheduling

[Daniel P. Berrange]

On Tue, Dec 06, 2016 at 03:13:51PM -0500, Matthew Miller wrote:
> On Tue, Dec 06, 2016 at 09:11:06AM +0000, Daniel P. Berrange wrote:
> > I expect we'd also rebase the virtualization stack in any .1 release,
> > or even in the middle of a release if Fedora switched to a yearly
> > major release cycle. 6+ months is already a long time to wait to push
> > out new features to users, so making it longer is really not helpful
> > from KVM virt stack pov.
> 
> Would these updates just add new features or -- not counting accidental
> regressions -- do they sometimes remove or change existing
> functionality significantly? Would it be possible to reserve the latter
> for the full release?

As a general rule they'd always be adding new features. The only things
that get removed as stuff users are not likely to hit (eg support for
QEMU machine types that are 5+ years old which no one will seriously be
running anymore)

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Some preliminary Fedora 25 stats — and future release scheduling

[Daniel P. Berrange]

On Mon, Dec 05, 2016 at 06:41:27PM -0700, Chris Murphy wrote:
> On Mon, Dec 5, 2016 at 5:03 PM, Michael Catanzaro  
> wrote:
> > On Mon, 2016-12-05 at 16:10 -0500, Matthew Miller wrote:
> >> It was by design, though — for a while, when a schedule slipped, we
> >> planned the next schedule as 6 or 7 months from the actual release.
> >> This time, we tried to keep it to October even though the previous
> >> release had slipped, resulting in the short schedule. I'm the person
> >> who pushed for that (because of the value of calendar consistency),
> >> and
> >> I'm now saying it was a mistake.
> >
> > I still think it's a good idea for Workstation. We really need to be
> > seen as the leading GNOME distro: that's what gets GNOME people using
> > Workstation and recommending that other people install it, then those
> > people recommend it... I think it's part of the story behind our recent
> > rise in popularity. Right now we are that leading GNOME distro because
> > we usually follow about 1-2 months behind a GNOME release. It's a huge
> > advantage over, say, Ubuntu, where people complain about needing PPAs
> > to get the latest software and upstream has already moved on to newer
> > versions half a year ago. Right now this is one of our biggest
> > strengths as a distro, and your proposal would throw that away. So
> > there is real serious risk of changing this.
> >
> > Also, if we do one release per year, then I expect most of the Red Hat
> > developers who work on GNOME would start using some unstable copr to
> > get the latest GNOME; this means way fewer developers using and testing
> > the latest release, since it's too stale. (I dunno what I'd do myself,
> > stick around and use a GNOME copr, or try to go improve Tumbleweed...?)
> 
> I'd expect .1 or +1 would rebase on the most recent GNOME.

I expect we'd also rebase the virtualization stack in any .1 release,
or even in the middle of a release if Fedora switched to a yearly
major release cycle. 6+ months is already a long time to wait to push
out new features to users, so making it longer is really not helpful
from KVM virt stack pov.

If we get lots of stuff rebasing in a .1 release though, it seems that
the result is not dramatically different from what we're doing today
with 6 monthly releases. 


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: including EOL and vulnerable software in Fedora

[Daniel P. Berrange]

On Mon, Oct 10, 2016 at 11:32:43AM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Monday, 10 October 2016 at 11:07, Florian Weimer wrote:
> > On 10/07/2016 06:43 PM, Dominik 'Rathann' Mierzejewski wrote:
> > 
> > > I was made aware that EOL software with known security bugs that will
> > > not be fixed upstream (due to EOL status) was reviewed and accepted into
> > > Fedora recently.
> > 
> > Fedora relies on EOLed components pretty much across the system (including
> > critical security functionality), so one more such package really isn't the
> > end of the world.  I think new packages should not be held to tremendously
> > higher standards than existing packages.
> 
> I think times have changed enough to warrant this at least for new
> packages. I don't think it's acceptable to simply allow adding
> known-to-be-vulnerable software to our package repositories without
> additional review anymore.

History has shown that it is safe to assume that every single non-trivial
application contains multiple security vulnerabilities, at all times. We
may not have found them yet, but you can certainly bet there are some there.

If you have 2 packages proposed for Fedora, one with known security bugs,
and one without, this does not imply that the former is less secure / more
dangerous for Fedora.  It almost certainly just means that no one has looked
for security bugs in the other piece of "bug free" software. In some ways
the piece of software with known security bugs may be considered better,
because it is a sign that it has actually had some attention from security
researchers, and users of it have information to evaluate whether their
usage scenario is actually at risk or not.

So IMHO a rule that forbids addition of software with known security bugs
is far too crude a hammer and would just give us a false sense of security.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://entangle-photo.org   -o-http://search.cpan.org/~danberr/ :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF skipping packages with conflicts in koji

[Daniel P. Berrange]

On Thu, Sep 22, 2016 at 11:01:56AM +0200, Michael Šimáček wrote:
> Hi,
> 
> I recently got a few failed build alerts with suspicious errors about
> missing commands/libs in the buildroot, despite the builddep step had
> succeeded. The root.log always contains "Skipping packages with conflicts"
> listing packages that weren't installed. So DNF now silently skips
> installation of some packages in koji. That's a problem - there are packages
> (usually using autoconf) that enable/disable features based on what they see
> in the environment, so silently skipping package installations may result in
> sucessful build of package that is missing functionality.

IMHO best practice is to *always* pass all the --enable-XXX feature flags
to 'configure' that you expect the package to be building with, and not
rely on auto-detection. There's plenty of ways that auto-detection can
get broken, beyond DNF not installing some pre-reqs, so you want to have
a robust build that always fails upfront.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24, small backward steps

[Daniel P. Berrange]

On Tue, Sep 13, 2016 at 10:00:32AM -0500, Michael Catanzaro wrote:
> Hi,
> 
> To be clear, the problem is that a small handful of package maintainers
> (including Bastien) are collectively "responsible" for all of the GNOME
> and freedesktop components in Fedora (including fprintd), and it's
> simply not reasonable to expect them to read all the bugs that are
> assigned to them, let alone take the time to forward them upstream. If
> you use Red Hat Bugzilla, the right developers may never notice your
> bug report at all.
> 
> You have a much better chance filing bugs upstream. You should only use
> Red Hat Bugzilla for these components if you happen to know there is a
> specific maintainer who actually looks at the Red Hat bugs for that
> specific component, or if you're planning to propose it as a release
> blocker, or if you just don't care whether anybody sees your bug. If
> you have a packaging bug then it's the right place, but please ping
> someone to be sure it gets noticed.
> 
> Of course this is not how Bugzilla is intended to work, but it is how
> it actually works for GNOME stuff. It's unfortunate, but without some
> Launchpad-style automatic bug forwarding, this is going to remain the
> case indefinitely.

This is a truly awful experiance from POV of a Fedora user filing bugs :-(
We've set a silent trap for them with no warning of the fact that their
bug reports are going to be ignored until Fedora EOL procedure closes
them :-(

Even if we can't enhance Red hat Bugzilla, we can at least do more to
alert users to this so they stand a chance of doing the right thing.

eg, update the component description to tell user to file in GNOME
bugzilla instead, and have a bot that adds a comment to any new bugs
that are still filed, closing them WONTFIX and asking the user to
re-open against upstream GNOME bugzilla, instead of leaving the bug
open and ignored until Fedora EOL.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Proposed mass bug filing for webkitgtk/webkitgtk3 package removal

[Daniel P. Berrange]

On Tue, Sep 06, 2016 at 09:01:27AM +0100, Richard W.M. Jones wrote:
> On Fri, Sep 02, 2016 at 07:34:04AM -0500, Michael Catanzaro wrote:
> > Hi,
> > 
> > I propose to carry out a mass bug filing with the bug title: "Remove
> > webkitgtk/webkitgtk3 dependency" (depending on which package is
> > dependend on) and following text:
> > 
> > """
> > The webkitgtk/webkitgtk3 package will be removed from rawhide after
> > Fedora 26 is branched due to the high number of unfixed security
> > vulnerabilities. You must remove this dependency or your package will
> > not be present in Fedora 27.
> > 
> > Please refer to [1] for a FAQ on this matter and be advised that for
> > some packages this may require a substantial amount of work.
> > 
> > [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedorapro
> > ject.org/thread/AKVB363GFCHHJ5MTHGVYHYT6NLLTF5VM/
> > """
> 
> Is there a Perl binding of webkit2 in Fedora?

The webkitgtk4 packages include a gobject introspection typelib, so you
can likely use Glib::Object::Introspection to get access to the webkit2
APIs that way.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Maintainer notification of package-related activity (was: Re: Fedora Account System (FAS) security issue)

[Daniel P. Berrange]

On Tue, Aug 09, 2016 at 12:27:33PM +0200, Florian Weimer wrote:
> On 08/08/2016 09:23 PM, Paul W. Frields wrote:
> > For example, activities related
> > to package content in dist-git generate notices to maintainers, and
> > the discovered flaw would not allow an attacker to circumvent these or
> > other safeguards.
> 
> I don't see this for glibc.  How do I turn this on?
> 
> Currently, I only receive notification of builds I started, but that happens
> for packages where I'm not listed as a maintainer, so I assume it's an
> unrelated mechanism.

Try this site to configure email/irc notifications for pretty much anything
related to Fedora activity:

  https://apps.fedoraproject.org/notifications/

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Packaging FPGA bitstreams

[Daniel P. Berrange]

On Fri, Jul 29, 2016 at 02:19:49AM -0400, Nico Kadel-Garcia wrote:
> On Thu, Jul 28, 2016 at 10:54 PM, Solomon Peachy  wrote:
> > On Thu, Jul 28, 2016 at 10:19:07PM -0400, Nico Kadel-Garcia wrote:
> >> Still not reasonable for Fedora, I think. Red Hat, and RHEL, can
> >> manage registered licensing to build this binary blob. But binary
> >> blobs with no tool chain to build htem?
> >
> > So it's okay to ship opaque-but-redistributable binary blobs that don't
> > run on the host CPU (aka device firmware) without any source code (much
> > less a toolchain that can build it), but shipping something that comes
> > with fully redistributable (if not outright Free) source code is bad
> > because there's no Free toolchain to compile it?  That doesn't make
> > sense.
> >
> > I'm just trying to understand how FPGA "firmware" is any different than
> > regular device firmware, and how having source code code available
> > suddenly turns something from okay to include into something we can't.
> >
> >  - Solomon
> 
> I detest both. Rechecking the published standard at
> https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware, it
> doesn't specifically list "must be compilable by Fedora developers
> with Fedora tools", so you've a point.
> 
> It's still making me hold my nose and go "ee".

I think all involved really detest the situation and accept that it is
a horrible situation to be in. None the less, Fedora policy explicitly
allows opaque but redistributable firmware blobs. So unless someone wants
to push through a change to the policy I don't see a reason in Fedora policy
that would cause us to treat FPGA firmware differently from existing
firmware blobs we distribute.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: g++ __VA_ARGS__ error

[Daniel P. Berrange]

On Mon, Jul 11, 2016 at 02:09:24PM +0200, Jan Synacek wrote:
> Hello,
> 
> I'm trying to compile the latest version of Warzone2100 on rawhide,
> but I'm getting this error:
> 
> g++ -DHAVE_CONFIG_H -I. -I..  -DYY_NO_INPUT -D_REENTRANT
> -I/usr/include/SDL2  -I/usr/include/libpng16   -I/usr/include/AL
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DNDEBUG
> -DWZ_DATADIR="\"/usr/share/warzone2100\""
> -DLOCALEDIR="\"/usr/share/locale\"" -I.. -I../3rdparty
> -I../3rdparty/quesoglc -I/usr/include/libdrm-g -Wno-enum-compare
> -Wall -Wextra -Wno-unused-parameter -Wno-sign-compare -Wcast-align
> -Wwrite-strings -Wpointer-arith -Wno-format-security
> -I/usr/include/qt5/QtWidgets -I/usr/include/qt5
> -I/usr/include/qt5/QtGui -I/usr/include/qt5
> -I/usr/include/qt5/QtScript -I/usr/include/qt5
> -I/usr/include/qt5/QtCore -I/usr/include/qt5  -O2 -g -pipe -Wall
> -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector-strong --param=ssp-buffer-size=4
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -m64 -mtune=generic -fPIC -std=c++11 -fstack-protector -c -o
> geometry.o geometry.cpp
> In file included from ../lib/framework/frame.h:44:0,
>  from ../lib/framework/wzapp.h:24,
>  from frontend.cpp:27:
> frontend.cpp: In function 'void startCampaignSelector()':
> ../lib/framework/string_ext.h:178:74: error: format not a string
> literal and no format arguments [-Werror=format-security]
>  #define ssprintf(dest, ...) snprintf((dest), sizeof(dest), __VA_ARGS__)
> 
> Could someone who understands g++ please advise how to fix this? I
> don't quite understand why it doesn't work.

It means the code calling this ssprintf() macro is passing a variable,
instead of a literal string. This is potentially unsafe as the compiler
can't validate that the string data in this variable contains format
arguments that are compatible with the __VA_ARGS__ passed at the same
time.  This is quite commonly hit when people do not actually have any
variadic args at all, and just want to print out the string variable
as-is with no interpolation. The fix is usually to add a plain "%s"
format arg.

eg if you have a varaible  'char *somemsg' which contains the data
to print and you're calling ssprintf(somemsg), then you would want
to change it to ssprintf("%s", somemsg).  This avoids any danger if
'somemsg' could itself potentailly contain % format specifies


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Daniel P. Berrange]

On Thu, Jul 07, 2016 at 09:48:24AM -0400, Jeff Moyer wrote:
> "Daniel P. Berrange" <berra...@redhat.com> writes:
> 
> > More typical though is that you have a directory containing an fullish
> > install tree of a non-native architecture and you just want to chroot
> > into that. When doing such a chroot, the qemu-$ARCH emulator must be
> > present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
> > must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
> 
> Hi, Dan,
> 
> Is this work from James Bottomley at all relevant?
> 
> http://comments.gmane.org/gmane.linux.file-systems/105033
> http://blog.hansenpartnership.com/constructing-architecture-emulation-containers/

He's describing exactly the kind of approach that is common on other
distros and that I want to work on Fedora too. His instructions are
assuming use of a statically linked qem-$ARCH emulator too.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: i686 as secondary arch?

[Daniel P. Berrange]

On Tue, Jul 05, 2016 at 12:10:03PM +0100, Peter Robinson wrote:
> On Tue, Jul 5, 2016 at 11:56 AM, Florian Weimer  wrote:
> > On 07/05/2016 10:57 AM, Richard W.M. Jones wrote:
> >
> >> If you need to run an i686 virtual machine based on Rawhide, my
> >> experience is that it's more likely than not that it won't boot, and
> >> no one cares.
> >
> >
> > Well, that's independent for the state as primary vs secondary architecture.
> >
> > If we remove i686 as a primary architecture, we will not have i686 packages
> > in the x86_64 repository.  Is this what we want?
> 
> We're in the process of redefining what constitutes a secondary arch
> and this is part of that consideration. There's a bunch of proprietary
> common third party tools/apps that people rely on that still need i686
> around.

wine on x86_64 pulls in the i686 packages too, so it is not just closed
source stuff requiring i686. I don't see it being viable to drop support
for i686 on x86_64 any time soon.


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: autoconf test for deprecated readdir_r

[Daniel P. Berrange]

On Thu, Jun 30, 2016 at 11:30:38AM -0400, Kaleb KEITHLEY wrote:
> 
> Hi,
> 
> Does anyone have a good/working autoconf test for checking for
> deprecated readdir_r (for Fedora 25) ?
> 
> I'm not having much luck. (Have tried AC_COMPILE_IFELSE, among other
> things.)
> 
> Alternatively it would be nice if there was a some kind of feature test
> define in dirent.h.

Why bother testing for it at all. There was never any real compelling
reason to want to use readdir_r, given that it was less portable and
normal readdir() is perfectly safe to use if you have one DIR* per
thread. So given that you'll need to adapt the code to use readdir
anyway, there's little point keeping a conditional codepath to use
readdir_r IMHO.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Daniel P. Berrange]

On Thu, Jun 30, 2016 at 10:21:18AM +0200, Michal Schmidt wrote:
> On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > The change to introduce a qemu-binfmt package has small upgrade
> > implications since anyone with qemu-user installed today, will loose
> > the binary format rules unless they manually install qemu-binfmt.
> 
> Not if you add "Obsoletes: qemu-user < V-R" (where V-R is the first
> version-release that contains this change) to both qemu-binfmt and qemu-user.

Oh, nice tip, thanks.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Daniel P. Berrange]

On Wed, Jun 29, 2016 at 04:54:42PM +0200, Florian Weimer wrote:
> On 06/29/2016 12:34 PM, Daniel P. Berrange wrote:
> > On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> > > On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > > > Debian handles this by having several packages [1]
> > > > 
> > > >  - qemu-user - the dynamic linked qemu user binaries
> > > >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> > > >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> > > >   rules to register them. The static binaries all
> > > >   have -static suffix on their name
> > > 
> > > Debian builds static libraries and puts them into their -dev packages.
> > > Fedora does not do this systematically.  Are all the static libraries you
> > > need actually available in Fedora?
> > 
> > Yes, everything we need exists - as mentioned its only glibc-static,
> > glib2-static, zlib-static and pcre-static that we need for this.
> 
> In this case, linking statically is indeed an option.
> 
> We currently have little tooling for static libraries.  Strictly speaking,
> all statically linked libraries have to be rebuilt even for minor glibc
> updates because we do not provide ABI compatibility for static linking
> (there are no compatibility symbols, static binaries always get the most
> recent implementation).

Yep, I understand those caveats - the flipside is that most other Linux
distros already provide statically linked qemu user emulators with glibc
without suffering unduly. So while I accept there are potential problems,
it doesn't seem like they're frequent / severe enough to make this approach
unviable.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Daniel P. Berrange]

On Wed, Jun 29, 2016 at 06:45:36AM -0700, Neal Gompa wrote:
> On Wed, Jun 29, 2016 at 3:03 AM, Daniel P. Berrange <berra...@redhat.com> 
> wrote:
> > For those who aren't familiar, QEMU actually provides two completely
> > different sets of emulators
> >
> >  - system emulators - they emulate a full virtual machine and thus run
> >a full guest OS.
> >  - user emulators - they emulate the Linux userspace ABI letting you
> >run non-native arch executables directly.
> >
> > The user emulators are what I'm concerned with in this mail, so ignore
> > the system emulators.
> >
> > Currently all the user emulators are provided in the "qemu-user" RPM
> > which also includes files in /usr/lib/binfmt.d to register each emulator
> > binary as a binary format handler for its respective architecture.
> >
> > This is ok if you have a non-native arch binary that's statically linked
> > and you just want to run it from context of your main OS root filesystem.
> > Running dynamic linked binaries won't fly because if say running an arm
> > binary on x86_64 host, it'll look for /lib/libc.so and find the i386 one,
> > instead of the arm one. You can't set LD_LIBRARY_PATH to override this
> > as the env var will apply to both qemu-arm (an x86_64 binary) and the
> > binary it is trying to run (an arm binary).
> >
> > More typical though is that you have a directory containing an fullish
> > install tree of a non-native architecture and you just want to chroot
> > into that. When doing such a chroot, the qemu-$ARCH emulator must be
> > present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
> > must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
> > So again you have the potential problem of clashing libc.so in /usr/lib
> > It is a shame Fedora doesn't have full multi-arch support, instead of
> > merely multi-lib to avoid these clashing lib dirs across architecture
> > RPMs.
> >
> > The recommended way to deal with this for the qemu user emulator binaries
> > to be statically linked, so when copied inside the non-native arch chroot,
> > they never need to resolve any native arch libraries. Fedora's qemu user
> > binaries are all dynamic linked right now.
> >
> > Debian handles this by having several packages [1]
> >
> >  - qemu-user - the dynamic linked qemu user binaries
> >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> >   rules to register them. The static binaries all
> >   have -static suffix on their name
> >
> > NB, this means qemu-binfmt and qemu-user-static are mutually exclusive
> > since they both provide the same binfmt files. You can however have both
> > qemu-user and qemu-user-static installed as their binary names won't
> > clash, and in this case the static ones will be registered as binfmts
> >
> > This nice thing about this multiple package approach is that when you
> > copied the x86_64 build of the "qemu-arm-static" binary into your arm
> > chroot, you still then have the possibility of installing the arm build
> > of the "qemu-arm" binary inside that chroot without filename clash.
> >
> > An alternative simpler approach would be to just have one package,
> > qemu-user, which contains the static binaries and never ship any
> > dynamic linked qemu user binaries. This is slightly more restrictive
> > though, as explained in the previous paragraph, so I'd like to avoid
> > doing that.
> >
> >
> > I'd like to make using non-native arch chroots simple with Fedora without
> > people needing to manually build their own static QEMU binaries, or download
> > static binaries provided by another distro[2]. So I'm suggesting to make a
> > change to Fedora qemu packages to essentially copy the way Debian has done
> > things. Specifically I will
> >
> >  - Pull the binfmt registration files out of qemu-user and into a
> >new qemu-binfmt package which depends on qemu-user.
> >
> >  - Add static builds of qemu user emulators to a new qemu-user-static
> >package, along with binfmt registration files
> >
> > The static build of QEMU user emulators is moderately light on
> > dependancies, only requiring glib2-static, pcre-static, zlib-static
> > and glibc-static packages.
> >
> > The change to introduce a qemu-binfmt package has small upgrade
> > implications since anyone with qemu-user installed today, will loose
>

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

[Daniel P. Berrange]

On Wed, Jun 29, 2016 at 09:39:11AM -0400, Simo Sorce wrote:
> On Wed, 2016-06-29 at 11:34 +0100, Daniel P. Berrange wrote:
> > On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> > > On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > > > Debian handles this by having several packages [1]
> > > > 
> > > >  - qemu-user - the dynamic linked qemu user binaries
> > > >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> > > >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> > > >   rules to register them. The static binaries all
> > > >   have -static suffix on their name
> > > 
> > > Debian builds static libraries and puts them into their -dev packages.
> > > Fedora does not do this systematically.  Are all the static libraries you
> > > need actually available in Fedora?
> > 
> > Yes, everything we need exists - as mentioned its only glibc-static,
> > glib2-static, zlib-static and pcre-static that we need for this.
> > 
> > > An alternative would be to bind-mount the real file system into the chroot
> > > and run the native dynamic linker with a --library-path command line
> > > argument that specifies the library directories in the bind mount. (It's
> > > reasonable to specify --inhibit-cache as well.)  This would need some
> > > adjustments in the binfmt wrapper.
> > 
> > The binfmt registrations are global to the OS, so the same binfmt command
> > needs to work whether inside or outside the chroot. So a scheme which
> > requires us to pass special args to make the linker looks elsewhere when
> > inside the chroot is not so easy. We'd have to create a wrapper program
> > around the real qemu user binary that decides which args to pass to the
> > linker, and that wrapper would then have to be statically linked
> 
> Just an idea:
> 
> Would it make sense to build the qemu-user binary so that it looks in a
> different /lib directory (using rpath) like /lib/qemu-user-systemlib,
> and then symlink into that directory the libraries it needs from the
> host ?
> 
> That way if you use chroot and bind mount in that directory in the right
> place the qemu-user binary uses different libraries from the emulated
> binaries yet you do not have to resort to static linking.

I think you would need multiple levels of symlinking

On the host root

 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 /

Even if you do all that, you've now prevented installation of the
foreign arch's qemu-user RPM inside the chroot, as that will clash
with the one you've setup from the host. Also the way you deal with
cross-arch chroots is now different (and more complex) on Fedora, vs
every other Linux distro which just provides a static qemu-$ARCH you
can copy without needing to care about bind mounting extra dirs.

So yes, it is probably possible, but it is not very appealing IMHO

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

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

[Daniel P. Berrange]

On Wed, Jun 29, 2016 at 12:15:02PM +0200, Florian Weimer wrote:
> On 06/29/2016 12:03 PM, Daniel P. Berrange wrote:
> > Debian handles this by having several packages [1]
> > 
> >  - qemu-user - the dynamic linked qemu user binaries
> >  - qemu-binfmt - binfmt rules registering the dynamic linked binaries
> >  - qemu-user-static - the static linked qemu user binaries *and* binfmt
> >   rules to register them. The static binaries all
> >   have -static suffix on their name
> 
> Debian builds static libraries and puts them into their -dev packages.
> Fedora does not do this systematically.  Are all the static libraries you
> need actually available in Fedora?

Yes, everything we need exists - as mentioned its only glibc-static,
glib2-static, zlib-static and pcre-static that we need for this.

> An alternative would be to bind-mount the real file system into the chroot
> and run the native dynamic linker with a --library-path command line
> argument that specifies the library directories in the bind mount. (It's
> reasonable to specify --inhibit-cache as well.)  This would need some
> adjustments in the binfmt wrapper.

The binfmt registrations are global to the OS, so the same binfmt command
needs to work whether inside or outside the chroot. So a scheme which
requires us to pass special args to make the linker looks elsewhere when
inside the chroot is not so easy. We'd have to create a wrapper program
around the real qemu user binary that decides which args to pass to the
linker, and that wrapper would then have to be statically linked

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

RFC: static builds for user emulators in Fedora QEMU RPMs

[Daniel P. Berrange]

For those who aren't familiar, QEMU actually provides two completely
different sets of emulators

 - system emulators - they emulate a full virtual machine and thus run
   a full guest OS.
 - user emulators - they emulate the Linux userspace ABI letting you
   run non-native arch executables directly.

The user emulators are what I'm concerned with in this mail, so ignore
the system emulators.

Currently all the user emulators are provided in the "qemu-user" RPM
which also includes files in /usr/lib/binfmt.d to register each emulator
binary as a binary format handler for its respective architecture.

This is ok if you have a non-native arch binary that's statically linked
and you just want to run it from context of your main OS root filesystem.
Running dynamic linked binaries won't fly because if say running an arm
binary on x86_64 host, it'll look for /lib/libc.so and find the i386 one,
instead of the arm one. You can't set LD_LIBRARY_PATH to override this
as the env var will apply to both qemu-arm (an x86_64 binary) and the
binary it is trying to run (an arm binary).

More typical though is that you have a directory containing an fullish
install tree of a non-native architecture and you just want to chroot
into that. When doing such a chroot, the qemu-$ARCH emulator must be
present inside the chroot too. ie the x86_64 build of /usr/bin/qemu-arm
must be present inside at /my/chroot/for/fedora-arm/usr/bin/qemu-arm.
So again you have the potential problem of clashing libc.so in /usr/lib
It is a shame Fedora doesn't have full multi-arch support, instead of
merely multi-lib to avoid these clashing lib dirs across architecture
RPMs.

The recommended way to deal with this for the qemu user emulator binaries
to be statically linked, so when copied inside the non-native arch chroot,
they never need to resolve any native arch libraries. Fedora's qemu user
binaries are all dynamic linked right now.

Debian handles this by having several packages [1]

 - qemu-user - the dynamic linked qemu user binaries
 - qemu-binfmt - binfmt rules registering the dynamic linked binaries
 - qemu-user-static - the static linked qemu user binaries *and* binfmt
  rules to register them. The static binaries all
  have -static suffix on their name

NB, this means qemu-binfmt and qemu-user-static are mutually exclusive
since they both provide the same binfmt files. You can however have both
qemu-user and qemu-user-static installed as their binary names won't
clash, and in this case the static ones will be registered as binfmts

This nice thing about this multiple package approach is that when you
copied the x86_64 build of the "qemu-arm-static" binary into your arm
chroot, you still then have the possibility of installing the arm build
of the "qemu-arm" binary inside that chroot without filename clash.

An alternative simpler approach would be to just have one package,
qemu-user, which contains the static binaries and never ship any
dynamic linked qemu user binaries. This is slightly more restrictive
though, as explained in the previous paragraph, so I'd like to avoid
doing that.


I'd like to make using non-native arch chroots simple with Fedora without
people needing to manually build their own static QEMU binaries, or download
static binaries provided by another distro[2]. So I'm suggesting to make a
change to Fedora qemu packages to essentially copy the way Debian has done
things. Specifically I will

 - Pull the binfmt registration files out of qemu-user and into a
   new qemu-binfmt package which depends on qemu-user.

 - Add static builds of qemu user emulators to a new qemu-user-static
   package, along with binfmt registration files

The static build of QEMU user emulators is moderately light on
dependancies, only requiring glib2-static, pcre-static, zlib-static
and glibc-static packages.

The change to introduce a qemu-binfmt package has small upgrade
implications since anyone with qemu-user installed today, will loose
the binary format rules unless they manually install qemu-binfmt. I
think the number of people affected is probably quite small, and some
of them may well wish to use qemu-user-static instead anyway.

Obviously this would only be done in rawhide, not any existing stable
releases of Fedora.

Nothing will change about the rest of QEMU packaging - ie all system
emulators will continue to use dynamic linking

Regards,
Daniel

[1] https://wiki.debian.org/QemuUserEmulation
[2] 
https://rwmj.wordpress.com/2013/12/22/how-to-run-aarch64-binaries-on-an-x86-64-host-using-qemu-userspace-emulation/
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org

Re: First stage of glibc recvmsg/sendmsg ABI revert landed in rawhide

[Daniel P. Berrange]

On Mon, Jun 13, 2016 at 07:09:33AM +0200, Florian Weimer wrote:
> glibc upstream, during development of the 2.24 release, introduced new
> symbol versions recvmsg@GLIBC_2.24, sendmsg@GLIBC_2.24 (and
> recvmmsg@GLIBC_2.24, sendmmsg@GLIBC_2.24 on 64-bit architectures), in order
> to fix some minor POSIX compliance issue.  (POSIX and the Linux kernel
> disagree about the width of some fields in struct msghdr.)  These changes
> landed in rawhide as part of glibc-2.23.90-19.fc25.
> 
> This change caused quite a few issues (chrony stopped building, Address
> Sanitizer interception of these functions was affected, probably more).
> Considering that the deviation from POSIX was really minor, this was
> considered a poor trade-off, and the patch and ABI change was eventually
> reverted upstream.

Do you have a pointer to the glibc change, or specific details about
what exactly changed. It looks like the change broke libvirt usage
of SCM_RIGHTS, and despite fact that you're reverting it in glibc,
I'm wondering if there is non-standards compliant usage in libvirt
that we should be fixing regardless.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Hardened build breaks gperftools / tcmalloc on 32 bit ARM

[Daniel P. Berrange]

On Mon, Feb 29, 2016 at 01:41:20PM +, Richard W.M. Jones wrote:
> 
> Anyone understand what's going on here?  Any program at all (even
> trivial ones) linked to tcmalloc crash during startup on ARM 32 bit.
> 
>   https://bugzilla.redhat.com/show_bug.cgi?id=1312462
> 
> At Tom's recommendation, I have added a patch to dist-git that
> disables hardened build on 32 bit ARM builds of gperftools, but that's
> quite a big hammer, and neither of us understands the underlying
> problem very much.

Presumably the previous version 2.4 was working fine, so its something
introduced between then and 2.4.90 that causes the breakage. Since you
have a trivial reproducable test case, probably the easiest thing is to
take upstream git and run a bisect across it with your test case.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: GCC 6 -Wnonnull is too aggressive

[Daniel P. Berrange]

On Wed, Feb 17, 2016 at 05:43:51PM +0100, Petr Spacek wrote:
> Hello,
> 
> I'm facing problems with new behavior in GCC 6.
> 
> Let's assume we have trivial program like this:
> 
> $ cat assert.c
> #include 
> #include 
> 
> __attribute__((nonnull))
> int f(char *txt)  {
> assert(txt != NULL);
> 
> return 0;
> }
> 
> int main(int argc, char **argv) {
> 
> return 0;
> }
> 
> 
> And because upstream is paranoid, it is being compiled with:
> $ gcc -Werror -Wall
> 
> 
> This code does not compile anymore on Fedora 24:
> $ gcc -Werror -Wall assert.c
> In file included from assert.c:1:0:
> assert.c: In function ‘f’:
> assert.c:6:13: error: nonnull argument ‘txt’ compared to NULL 
> [-Werror=nonnull]
>   assert(txt != NULL);
>  ^
> 
> Did anyone met similar problem? What did you do with it?
> 
> __attribute__((nonnull)) is tremendously useful for static code analysis and
> helped to uncover a lot of (not-yet triggered) issues in the code, so just
> removing the attribute would not make me happy.
> 
> On the other hand, assert(var != NULL) checks are tremendously useful at
> run-time. They detects problems early/near the place when the problem occurred
> and makes debugging easier.

Instead of using __attribute__((nonnull)) directly in the code, define a
macro for it. When compiling normal builds with gcc, make the macro
expand to nothing, but when compiling with coverity or other static analysis
tools make it expand normally.

This is what we do in libvirt for a while, because we long ago hit the
problem that gcc kills your asserts() if it sees the nonnull annotation :-(

[quote $libvirt/src/internal.h]

/* gcc's handling of attribute nonnull is less than stellar - it does
 * NOT improve diagnostics, and merely allows gcc to optimize away
 * null code checks even when the caller manages to pass null in spite
 * of the attribute, leading to weird crashes.  Coverity, on the other
 * hand, knows how to do better static analysis based on knowing
 * whether a parameter is nonnull.  Make this attribute conditional
 * based on whether we are compiling for real or for analysis, while
 * still requiring correct gcc syntax when it is turned off.  See also
 * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308 */
#  ifndef ATTRIBUTE_NONNULL
#   if __GNUC_PREREQ (3, 3)
#if STATIC_ANALYSIS
# define ATTRIBUTE_NONNULL(m) __attribute__((__nonnull__(m)))
#else
# define ATTRIBUTE_NONNULL(m) __attribute__(())
#endif
#   else
#define ATTRIBUTE_NONNULL(m)
#   endif
#  endif

[/quote]


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Change Proposal Name NewRpmDBFormat

[Daniel P. Berrange]

On Wed, Jan 13, 2016 at 01:30:59PM +, Richard Hughes wrote:
> On 13 January 2016 at 13:13, Reindl Harald  wrote:
> > so there is no justification to declare one need to install from scratch
> > just because rpm which works for many years fine changes it's storage format
> 
> I don't think anyone said there was a need to reinstall from scratch.

Well the feature writeup is rather fuzzy on this.  It says that in Fedora
24 rpm will be able to read both old and new format, but it also says
that future RPM versions will drop support for the old format. So unless
there is a mandatory data format conversion during some Fedora upgrade,
then at some point RPM will cease to be able to read existing installs
with the old format which could imply a need to reinstall.

IMHO the feature proposal text needs to be more explicit about the upgrade
path and exactly when any data conversion will take place, to avoid leaving
existing installs with old format stuck with Fedora 25 rpm (or later) drops
BDB support entirely.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Changes in F24 schedule - two weeks slip

[Daniel P. Berrange]

On Tue, Jan 12, 2016 at 09:02:08AM -0500, Josh Boyer wrote:
> On Tue, Jan 12, 2016 at 8:58 AM, David Howells  wrote:
> > Jan Kurik  wrote:
> >
> >> let me inform you about changes in Fedora 24 schedule.
> >>
> >> There is a will to accommodate GCC6 compiler in F24 and use it to
> >> compile all the binaries delivered in this release [1].
> >
> > Do the cross-gcc packages also need moving to GCC6 immediately as I believe
> 
> It would be a good idea regardless...
> 
> > they're used to compile some bits too?
> 
> Which bits?  AFAIK, Fedora does not allow cross-compiling for official
> Fedora packages.

They're used to build some firmware blobs for QEMU/KVM, eg seabios
because we need to build x86 seabios code on ppc/arm/etc hosts for
example.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 Self Contained Change: Astronomy Spin

[Daniel P. Berrange]

On Mon, Jan 11, 2016 at 12:19:24PM +0100, Jan Kurik wrote:
> = Proposed Self Contained Change: Astronomy Spin =
> https://fedoraproject.org/wiki/Changes/Astronomy_Spin
> 
> Change owner(s):
> * Christian Dersch 
> 
> A Fedora Spin providing a complete toolchain for both amateur and
> professional astronomers.
> 
> == Detailed Description ==
> In both amateur and professional astronomy and astrophysics Linux is a
> very popular operating system. More and more data analysis is
> performed using Python, especially the astropy project is a quite new
> effort providing a professional toolchain. The Astronomy Spin provides
> a complete scientific Python environment (2 and 3) as well as the
> AstrOmatic software. For observational astronomy, KStars provides a
> complete solution for astrophotography using the INDI library. In
> addition to an astronomical collection of packages the spin also adds
> a menu for astronomy to make work more comfortable.

I'm struggling to see the point in doing this as a Fedora Spin, as
opposed to just providing a yum 'Astronomy' group that can be installed
on any Fedora deployment ? It would seem to be useful to a broader set
of users that way. Alternatively IIUC there is also already a Fedora
'Scientific' spin which seems to aim to bundle together scientific tools,
of which astronomy tools would seem to be a subset. So why not just bundle
astronomy tools into that spin giving users a much broader & more useful
set of functionality ?

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Do we need the Fedora 'virt' mailing list?

[Daniel P. Berrange]

On Wed, Sep 16, 2015 at 12:45:28PM +0100, Richard W.M. Jones wrote:
> 
> Crickets ... https://lists.fedoraproject.org/pipermail/virt/
> 
> The virt list has long been in an odd place.  Fedora has best in class
> virt support, because so many virt developers use it.  It also follows
> upstream very closely, with upstream packages like libvirt and qemu
> going straight into Rawhide without any significant patching.
> 
> So there isn't really much need for a Fedora+virt-specific list, since
> almost any question should go upstream to one of the following lists:
> 
>  - https://www.redhat.com/mailman/listinfo/virt-tools-list
>  - https://libvirt.org/contact.html#email
>  - http://wiki.qemu.org/MailingLists
>  - https://libosinfo.org/communicate/
>  - https://www.redhat.com/mailman/listinfo/libguestfs
> 
> Or as a last resort if it really is a rare virt integration issue that
> only affects to Fedora, then:
> 
>  - https://admin.fedoraproject.org/mailman/listinfo/users
>  - https://admin.fedoraproject.org/mailman/listinfo/devel
> 
> Can we kill the virt list?

At this point in time, I'd say yes.


FWIW, a little history many moons ago during development of the
Fedora Core 5 release, we created a fedora-...@redhat.com mailing
list. Virtualization was all new and shiny and a total pain to actually
get running and develop against. So the fedora-xen mailing list was
useful to avoid deluging other mailing lists with Xen related topics.
Later when KVM came along, we created a fedora-virt mailing list, so
we didn't tie discussions just to Xen. These later moved from redhat.com
to fedoraproject.org mailman. The x...@lists.fedoraproject.org mailing
list actually still exists too, and has even less traffic than virt one!

Fast-forward 10 years virtualization is mainstream, almost seemlessly
integrated in Fedora, pretty much everyone knows about it and can get
it working with little effort. Thus the original rationale for having the
Fedora virt mailing list has pretty much gone away IMHO. There's no reason
not to just use the main Fedora developer/user mailing lists, and/or the
appropriate project upstream lists at this point.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: Do we need the Fedora 'virt' mailing list?

[Daniel P. Berrange]

On Wed, Sep 16, 2015 at 01:20:49PM +0100, Daniel P. Berrange wrote:
> On Wed, Sep 16, 2015 at 12:45:28PM +0100, Richard W.M. Jones wrote:
> > 
> > Crickets ... https://lists.fedoraproject.org/pipermail/virt/
> > 
> > The virt list has long been in an odd place.  Fedora has best in class
> > virt support, because so many virt developers use it.  It also follows
> > upstream very closely, with upstream packages like libvirt and qemu
> > going straight into Rawhide without any significant patching.
> > 
> > So there isn't really much need for a Fedora+virt-specific list, since
> > almost any question should go upstream to one of the following lists:
> > 
> >  - https://www.redhat.com/mailman/listinfo/virt-tools-list
> >  - https://libvirt.org/contact.html#email
> >  - http://wiki.qemu.org/MailingLists
> >  - https://libosinfo.org/communicate/
> >  - https://www.redhat.com/mailman/listinfo/libguestfs
> > 
> > Or as a last resort if it really is a rare virt integration issue that
> > only affects to Fedora, then:
> > 
> >  - https://admin.fedoraproject.org/mailman/listinfo/users
> >  - https://admin.fedoraproject.org/mailman/listinfo/devel
> > 
> > Can we kill the virt list?
> 
> At this point in time, I'd say yes.

BTW, in case there was any doubt ...by 'kill the virt list', I would
expect that we set all existing subscribers to moderated, and set any
postings to get the get an auto-reply suggesting they use one of the
alternative lists Rich suggests above. We'd also turn off ability to
subscribe. The list would still actually exist, such that we preserve
the archives forever. IOW, we just disable use of the list but don't
delete it.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: Proposal to reduce anti-bundling requirements

[Daniel P. Berrange]

On Thu, Sep 10, 2015 at 11:25:00AM -0400, Stephen Gallagher wrote:
> On Thu, 2015-09-10 at 16:04 +0100, Peter Robinson wrote:
> > > > > I would like to propose that the no-bundled-libraries policy be
> > > > > amended  as follows: "Any package that has an existing
> > > > > mechanism to
> > > > > link against a shared system library and functions correctly
> > > > > when
> > > > > doing so must link against that library and not bundle it
> > > > > internally.
> > > > > Any package whose upstream releases cannot link against a
> > > > > shared
> > > > > system library (or are incompatible with the version in
> > > > > Fedora) may
> > > > > bundle that library (without requiring a special exemption) but
> > > > > MUST
> > > > > add Provides: bundled() =  in the spec file
> > > > > for
> > > > > each
> > > > > known bundled library.(This will allow us to track down the
> > > > > bundling
> > > > > when we need to). Package maintainers should continue attempt
> > > > > to
> > > > > engage upstream to support linking against shared system
> > > > > libraries
> > > > > wherever possible, due to the advantages it provides the
> > > > > package
> > > > > maintainer."
> > > > 
> > > > Is  the name of the SRPM which provides the system
> > > > version
> > > > of
> > > > the library?
> > > 
> > > Exact implementation TBD. I didn't want to get too far into the
> > > technical details. Assume it to be a generally agreed-upon format.
> > > 
> > > 
> > > > 
> > > > How do you propose to resolve symbol conflicts if both the system
> > > > library and the bundled library are loaded into the same process?
> > > >  The
> > > > current ELF linking scheme lacks good support for bundling
> > > > libraries
> > > > whose exported symbols have not been mangled in some way.
> > > > 
> > > 
> > > I expect such cases to be rare and dealt with on an as-needed
> > > basis.
> > > Generally, projects either bundle or don't. The fuzzy area might be
> > > with plugins, I guess.
> > 
> > It doesn't matter how rare they are, it'll only take a single bundled
> > library handled incorrectly to completely screw a running OS. I don't
> > think this is something that can just be swept under the carpet, it
> > needs to be addressed as a core part of the proposal and currently is
> > not.
> > 
> 
> 
> I think that's overstating the problem, Peter. Users are running
> hundreds of applications with bundled libraries today and are not
> obviously encountering this potential problem, which leads me to
> believe it's very uncommon and therefore not worth blocking progress
> on. Yes, it would be useful to have a plan in place for how to deal
> with it when it does happen. No, I don't think the plan has to be
> perfect before it can move forward.

Even if the problems did occur, the user is going to see it whether
they get the app from Fedora or from a 3rd party repo. I concur that
avoiding bundling is the most desirable scenario for apps in Fedora
but if that can't be achieved, a pragmatic approach benefits the users.
Chucking darktable out of Fedora due to bundling, isn't going to change
what users run. They will still run the exact same RPMs as they would
get from Fedora, but we'll have forced them to search out and enable
a copr / 3rd party repo. This hasn't helped users of darktable in any
way, just put an extra stumbling block in their way which will make
them less happy with the Fedora experiance overall :-(

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: Do you know how many 64-bit architectures Fedora has?

[Daniel P. Berrange]

On Mon, Aug 24, 2015 at 09:18:16AM -0400, Neal Gompa wrote:
 
 ​Oh, yes! I was trying to find something like this all weekend for my Copr
 for reprepro. I have to make a patch to access apt-methods in /usr/lib64 on
 64-bit systems, but on 32-bit systems it should remain /usr/lib.
 
 You just made my day. ​

You should not really assume that all 64-bit architectures use /usr/lib64
either - %{_libdir} expands to the right directory path per architecture.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: and legacy software Re: pyorbit

[Daniel P. Berrange]

On Wed, Jul 29, 2015 at 02:07:50PM +0200, Matěj Cepl wrote:
 On 2015-07-29, 10:47 GMT, Michael Schwendt wrote:
  As I have thought for some time,  I think we should have a team to keep
  packages and make migrations like gtk2 to gkt3, libgnome2, pyorbit,
  gnome-python2, pyhton2 to python3 , qt3 etc etc
 
  Wishful thinking. Porting from gtk2 to gtk3 is non-trivial or not even
  feasible in all cases (without dropping some features/implementations).
  Some developers are unhappy with gtk3. Others switch to Qt.
 
 I would say that the transition from Gtk2 to Gtk3 was pretty 
 much a disaster especially in terms of the 3rd part software.  

FWIW I found the port of Gtk3 pretty straightforward for
my Entangle application and find it quite alot nicer to work
with than Gtk2 in general, so has been a big plus overall.

I would *not* suggest that Fedora maintainers do any such
porting work though, as maintaining such a fork from upstream
would be seriously painful. Leave any porting work to the
upstream community to decide to do, or not.

 * GIMP of all programs (original software for which Gtk was 
   created) is still Gtk2.

The GTK3 port is on GIMP's roadmap for their 3.0 release
series, but they need to get their port to gegl finished
before that

  http://wiki.gimp.org/wiki/Roadmap

 * Actually, I have hard time to imagine which large 3rd party 
   projects did switch from Gtk2 to Gtk3.

As an alternative to random FUD, here's some actual data

 # dnf repoquery --whatrequires 'libgtk-3.so.0()(64bit)'

...plenty of significant apps/projects using Gtk3 there,
not least of all evolution, totem, evince, gnumeric,
ephinany, emacs

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: Hosting End-Of-Life Fedora Base images?

[Daniel P. Berrange]

On Tue, Jul 21, 2015 at 11:05:19AM -0500, Adam Miller wrote:
 On Mon, Jul 20, 2015 at 2:33 PM, Chris Murphy li...@colorremedies.com wrote:
  Isn't it true the install media ISOs are available indefinitely? And
  if so the security cat is already out of the bag, so that's not a very
  good argument. I'd say if we wanted to do something better it would be
  an image that's usable for both VM and containers, and would be the
  state of that version at the time it went EOL, i.e. it has all
  available updates baked into it. And then de-emphasize the original
  ISO as the way to run older versions of Fedora.
 
 It is true that install media ISOs are available forever, but we don't
 go backwards in time and create vagrant boxes or IaaS cloud qcow
 images of old EOL'd Fedora releases that went EOL before those
 technologies existed and/or became popular. I don't see why we would
 start doing so now for docker images.

The security downsides of officially distributed docker images for EOL
versions are already mentioned, and i think that alone should be enough
to kill the idea. Beyond that though, making these EOL images available
is going to consume a non-zero amount of maintainer time for at least
one person, thus inevitably diverting resources away from making current
non-EOL Fedora better.

Avoiding maintainer time being sucked up on old releases is why we EOL
them in the first place, and the rationale for existence of long term
support alternatives like RHEL  CentOS. So I don't think we should
consider cloud images any differently in that respect. Fedora is about
being at the cutting edge and that's where we should focus our limited
resources, even for cloud images.

If people want cloud images with older software versions than are in the
current supported Fedora, they should be looking for cloud images from
CentOS/RHEL instead.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

API change + soname bump of libvirt-sandbox 0.6.0

[Daniel P. Berrange]

The new libvirt-sandbox release 0.6.0 pushed to rawhide has a minor API
change and corresponding soname bump of the library.

I'll likely push this update to stable branches too, as it fixes a number
of problems and I think its unlikely there are downstream apps linking
to its library beyond the in-house virt-sandbox cli tool itself.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Net-DBus/f22] Update to 1.1.0 release

[Daniel P . Berrange]

Summary of changes:

  d06f9cb... Update to 1.1.0 release (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Net-DBus] Update to 1.1.0 release

[Daniel P . Berrange]

commit d06f9cb378e024e546fa5dea2faa0ca407251652
Author: Daniel P. Berrange berra...@redhat.com
Date:   Mon Mar 16 20:48:11 2015 +

Update to 1.1.0 release

 .gitignore |  6 --
 perl-Net-DBus.spec | 11 +++
 sources|  2 +-
 3 files changed, 12 insertions(+), 7 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index fd70cb5..e9dca05 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,4 @@
-Net-DBus-0.33.6.tar.gz
-/Net-DBus-1.0.0.tar.gz
+/Net-DBus-*.tar.gz
+*.rpm
+*.log
+x86_64/
\ No newline at end of file
diff --git a/perl-Net-DBus.spec b/perl-Net-DBus.spec
index b0f730d..9c87dfa 100644
--- a/perl-Net-DBus.spec
+++ b/perl-Net-DBus.spec
@@ -1,6 +1,6 @@
 Name:   perl-Net-DBus
-Version:1.0.0
-Release:10%{?dist}
+Version:1.1.0
+Release:1%{?dist}
 Summary:Use and provide DBus services
 License:GPLv2+ or Artistic
 Group:  Development/Libraries
@@ -11,7 +11,6 @@ BuildRequires:  dbus-devel  = 1.00, pkgconfig
 BuildRequires:  perl(Exporter)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(Time::HiRes)
-BuildRequires:  perl(XML::Grove)
 BuildRequires:  perl(XML::Parser)
 BuildRequires:  perl(XML::Twig)
 BuildRequires:  perl(XSLoader)
@@ -20,6 +19,7 @@ BuildRequires:  perl(Carp)
 BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Test::Pod) = 1.00
 BuildRequires:  perl(Test::Pod::Coverage) = 1.00
+BuildRequires:  perl(Test::CPAN::Changes)
 Requires:   perl(XSLoader)
 
 %{?perl_default_filter}
@@ -48,12 +48,15 @@ find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null 
\;
 make test
 
 %files
-%doc AUTHORS CHANGES README LICENSE examples/
+%doc AUTHORS Changes README LICENSE examples/
 %{perl_vendorarch}/auto/*
 %{perl_vendorarch}/Net*
 %{_mandir}/man3/*
 
 %changelog
+* Mon Mar 16 2015 Daniel P. Berrange berra...@redhat.com - 1.1.0-1
+- Update to 1.1.0 release
+
 * Fri Aug 29 2014 Jitka Plesnikova jples...@redhat.com - 1.0.0-10
 - Perl 5.20 rebuild
 
diff --git a/sources b/sources
index ab00692..d8d8a88 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b17e32976d1a3b56feb908ebd7fed7f1  Net-DBus-1.0.0.tar.gz
+da44a16f8abf1db76f5ccf50d9926944  Net-DBus-1.1.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Net-DBus-1.1.0.tar.gz uploaded to lookaside cache by berrange

[Daniel P. Berrange]

A file has been added to the lookaside cache for perl-Net-DBus:

da44a16f8abf1db76f5ccf50d9926944  Net-DBus-1.1.0.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Sys-Virt-1.2.13.tar.gz uploaded to lookaside cache by berrange

[Daniel P. Berrange]

A file has been added to the lookaside cache for perl-Sys-Virt:

80bd23071fbbe62c4c8c47c8770c48a9  Sys-Virt-1.2.13.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Sys-Virt] Update to 1.2.13 release

[Daniel P . Berrange]

commit 1f6dbba6c910217bf378fd8d94f72ac46559184d
Author: Daniel P. Berrange berra...@redhat.com
Date:   Fri Mar 6 10:45:57 2015 +

Update to 1.2.13 release

 perl-Sys-Virt.spec | 5 -
 sources| 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index 34d7005..941f92f 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,7 +1,7 @@
 # Automatically generated by perl-Sys-Virt.spec.PL
 
 Name:   perl-Sys-Virt
-Version:1.2.12
+Version:1.2.13
 Release:1%{?dist}%{?extra_release}
 Summary:Represent and manage a libvirt hypervisor connection
 License:GPLv2+ or Artistic
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Fri Mar  6 2015 Daniel P. Berrange berra...@redhat.com - 1.2.13-1
+- Update to 1.2.13 release
+
 * Tue Jan 27 2015 Daniel P. Berrange berra...@redhat.com - 1.2.12-1
 - Update to 1.2.12 release
 
diff --git a/sources b/sources
index b73b1fc..be51ad8 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-6b88d53b940998cc8bec755108d2cea5  Sys-Virt-1.2.12.tar.gz
+80bd23071fbbe62c4c8c47c8770c48a9  Sys-Virt-1.2.13.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-Sys-Virt/f22] Update to 1.2.13 release

[Daniel P . Berrange]

Summary of changes:

  1f6dbba... Update to 1.2.13 release (*)

(*) This commit already existed in another branch; no separate mail sent
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Firefox addon signing

[Daniel P. Berrange]

On Thu, Feb 12, 2015 at 12:47:27PM +0100, drago01 wrote:
 On Thu, Feb 12, 2015 at 11:15 AM, Nikos Roussos
 comzer...@fedoraproject.org wrote:
  On Thu, Feb 12, 2015 at 6:30 AM, Michael Cronenworth m...@cchtml.com
  wrote:
 
  I'm sure those that need to know, know, but for those that haven't heard[1]
  Mozilla's official Firefox build will enforce addons to contain a Mozilla
  signature without any runtime option to disable the check. Initially this
  prevents Fedora packaged addons since they are unsigned. The Mozilla signing
  process takes time and can't be part of a package building process. Is
  Fedora going to get authorization to build Firefox with a runtime disable
  option?
 
 
  If the only way is to completely disable this feature, I'd prefer we don't.
  I wouldn't like for us to ship a less secure build of Firefox.
 
 A better way would be to add a Fedora Signature in addition to
 mozilla's and use that for packaged extensions.
 But that would require work on the build system (koji) side.

The RPMs deploying the packaged extension are already signed and those
signatures are checked at time of package install. So it seems like
firefox merely needs to be taught that the pre-packaged extensions
deployed by RPM are pre-verified, so it can skip its verification
for those, while still doing verification for stuff that is live
downloaded

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
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: Firefox addon signing

[Daniel P. Berrange]

On Thu, Feb 12, 2015 at 09:54:16AM -0500, Miloslav Trmač wrote:
  or simply exempt signature checking if
  the extension is on disk. They should check on download only.
 
 That would defeat the entire purpose; malware is very commonly
 sideloading extensions.

If we only exempt extensions installed by RPM it is reasonable to assume
that our new package review process would have validated there is no
malware present. Our package review process is serving the same kind of
purpose as Mozilla's extension review  signing process.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Sys-Virt] Update to 1.2.12 release

[Daniel P . Berrange]

commit a946705bcb65263b7bf43dda6b80c57e94aefbaf
Author: Daniel P. Berrange berra...@redhat.com
Date:   Tue Jan 27 11:18:05 2015 +

Update to 1.2.12 release

 perl-Sys-Virt.spec |5 -
 sources|2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index f9a2835..34d7005 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,7 +1,7 @@
 # Automatically generated by perl-Sys-Virt.spec.PL
 
 Name:   perl-Sys-Virt
-Version:1.2.11
+Version:1.2.12
 Release:1%{?dist}%{?extra_release}
 Summary:Represent and manage a libvirt hypervisor connection
 License:GPLv2+ or Artistic
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Tue Jan 27 2015 Daniel P. Berrange berra...@redhat.com - 1.2.12-1
+- Update to 1.2.12 release
+
 * Mon Dec 15 2014 Daniel P. Berrange berra...@redhat.com - 1.2.11-1
 - Update to 1.2.11 release
 
diff --git a/sources b/sources
index ec1b60b..b73b1fc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-366672f8ac4abd2cc814a32fb10fa929  Sys-Virt-1.2.11.tar.gz
+6b88d53b940998cc8bec755108d2cea5  Sys-Virt-1.2.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Sys-Virt-1.2.12.tar.gz uploaded to lookaside cache by berrange

[Daniel P. Berrange]

A file has been added to the lookaside cache for perl-Sys-Virt:

6b88d53b940998cc8bec755108d2cea5  Sys-Virt-1.2.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Python 3 as a Default - Status

[Daniel P. Berrange]

On Tue, Jan 20, 2015 at 08:22:25AM -0500, Bohuslav Kabrda wrote:
 Hi all,
 since the Python 3 as a Default change [1] has been accepted a while ago 
 and is scheduled for F22, I'd like to share with you the status.
 
 The proposed change [1] mentions several goals that should be reached to 
 pronounce python3 the default:
 1) DNF is the default package manager instead of Yum, which only works with 
 Python 2
 2) Python 3 is the only Python implementation in the minimal buildroot
 3) Python 3 is the only Python implementation on the LiveCD
 4) Anaconda and all of its dependencies run on Python 3
 5) cloud-init and all of its dependencies run on Python 3

 5) cloud-init is a problem. Basically, Python 3 cloud-init is the only thing
 blocking the cloud images (*). Other packages are ready or being worked on.
 The problem here is that cloud-init upstream is really unresponsive about
 Python 3 porting (patch is submitted in their bug tracker [3]) - if someone
 knows these people, please help us by pinging them.

 [3] https://code.launchpad.net/~harlowja/cloud-init/py2-3/+merge/225240

I forwarded this request to Red Hat's openstack team to see if anyone
there has contacts with the cloud-init maintainers. I've heard back
that Ubuntu is in the same boat, also wanting a python3 compatible
cloud-init in the near future. The author of the patch you mention
is actually a cloud-init maintainer so could merge stuff himself,
but he really needs others to review his patches before doing that.
None the less, it sounds like there might be a bit of interest and
movement upstream to try to get this porting work finished.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[perl-Sys-Virt] Update to 1.2.11 release

[Daniel P . Berrange]

commit 66c057970a6e2c4c7951ed0391f1438e6ab2c7f5
Author: Daniel P. Berrange berra...@redhat.com
Date:   Mon Dec 15 15:39:00 2014 +

Update to 1.2.11 release

 perl-Sys-Virt.spec |5 -
 sources|2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Sys-Virt.spec b/perl-Sys-Virt.spec
index 6281558..f9a2835 100644
--- a/perl-Sys-Virt.spec
+++ b/perl-Sys-Virt.spec
@@ -1,7 +1,7 @@
 # Automatically generated by perl-Sys-Virt.spec.PL
 
 Name:   perl-Sys-Virt
-Version:1.2.9
+Version:1.2.11
 Release:1%{?dist}%{?extra_release}
 Summary:Represent and manage a libvirt hypervisor connection
 License:GPLv2+ or Artistic
@@ -59,6 +59,9 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Mon Dec 15 2014 Daniel P. Berrange berra...@redhat.com - 1.2.11-1
+- Update to 1.2.11 release
+
 * Thu Oct  2 2014 Daniel P. Berrange berra...@redhat.com - 1.2.9-1
 - Update to 1.2.9 release
 
diff --git a/sources b/sources
index 755ce5c..ec1b60b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-47327538e8a57cd78e8f16d2b503  Sys-Virt-1.2.9.tar.gz
+366672f8ac4abd2cc814a32fb10fa929  Sys-Virt-1.2.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

File Sys-Virt-1.2.11.tar.gz uploaded to lookaside cache by berrange

[Daniel P. Berrange]

A file has been added to the lookaside cache for perl-Sys-Virt:

366672f8ac4abd2cc814a32fb10fa929  Sys-Virt-1.2.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Poll: How users use DNF

[Daniel P. Berrange]

On Tue, Dec 09, 2014 at 12:28:54PM -0500, Radek Holy wrote:
 Please share with me the use cases, not the description of the install
 command. Think twice before you share something because I believe it's
 not as easy as it might seem. As an example I think it might be something
 like:
 
 - I call YUM install, because I want to get given packages into my system
and I don't care whether it requires an upgrade or downgrade or what. or
 - I want to get them there but it should protect me against dangerous
operations like downgrades or
 - I often make typos, so I expect that the program knows what I mean or
 - it would be nice if it would literally perform the installation; if any
of the packages cannot be installed because of any reason, it should fail.

OpenStack's  devstack.sh deployment script makes use of YUM for two
core tasks.

First it wants to ensure a set of packages exist on the host and wants
to see an error exit status if any of the packages requested are not
present after the command completes. Currently it uses 'install' for
this but has to grep stderr for No package to see if YUM claimed
success when it in fact failed to install some of the packages [1].

Second it wants to be able to be to ensure a package is not present
on a server. ie if the package is not installed currently that's fine,
but if it is installed it must be removed. It wants to have an error
status only if the package is installed and cannot be removed.

In both cases it needs to operate non-interactively with no user
prompting.

Regards,
Daniel

[1] https://bugzilla.redhat.com/show_bug.cgi?id=965567
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct