So 2 devel cycles ago we had this whole discussion
about how forcing people to choose strong passwords in anaconda
was making live hard for testers / test-installs and this
decision was reverted.
So now here I'm doing a F25 Fedora ARM test install, end up
in the gnome-ified first-time-setup wizzard and cannot continue
until I make my test-user password strong enough. UGH.
So can we get this fixed please, or do we need to escalate
this all the way up to FESco again ?
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
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 
- 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
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. 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
|: 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 :|
While checking out the SPEC file of python, it seems there were some packages that, while separate at some point, they got included in python's stdlib and then obsoleted as standalone packages (thus to cope with the change, python was obsoleting these packages and providing them as well in the SPEC). So every package that currently (Build)Requires any of these packages will essentially drag python with it.
I will remove these provides soon, since the packages were orphaned long time ago, but the packages that still require them, will need to be fixed and (Build)Require python instead.
Here is a github commit with these changes from a testing repo:
And a list of the provided packages and the affected ones
Depending on feedback here I will follow (or not) the mass bug filling procedure so maintainer fix their packages.
The reasoning behind this change, at the current time, is that I intent to rename python to python2 soon, which will lead to a re-review of python, so at the moment trying to have things as clear and consistent as possible. Plans for that change is only for rawhide (although it would be nice for f25 as well).
Associate Software Engineer
Python Maintenance Team, Red Hat
I messed up the change proposal for Boost 1.61 in F25, which means it
isn't on the schedule.
Given the huge amount of work involved in every Boost update, I'm not
going to be too upset if I don't have to do it!
How upset will other people be if F25 ships with Boost 1.60 (same as
in F24)? Then F26 would get an update, possibly skipping 1.61 and going
straight to 1.62 which should be out by then.
Boost 1.61 adds four new libraries: Boost.Compute, Boost.DLL,
Boost.Hana and Boost.Metaparse.
Full 1.61 release notes:
I want to contribute to sssd project. I have builded and installed source code on my VM
These are my queries:
1. I tried to pick up a easyfix bug at https://fedorahosted.org/sssd/query?status=new&status=reopened&keywords=~...
But all bugs are owned by someone or else.
Though in filters I have selected .. Status new or reopened
2. Is there any documentation(Steps) for new comers to start with.
On Wednesday, September 21, 2016 12:16:39 PM CEST buildsys(a)fedoraproject.org wrote:
> vim-syntastic has broken dependencies in the rawhide tree:
> On aarch64:
> vim-syntastic-lisp-3.7.0-6.fc26.noarch requires clisp
> On aarch64:
> vim-syntastic-cs-3.7.0-6.fc26.noarch requires mono-core
> On aarch64:
> vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc
> On armhfp:
> vim-syntastic-d-3.7.0-6.fc26.noarch requires ldc
> Please resolve this as soon as possible.
What's should packager do in such case? Recap: noarch package depends on
arch-dependant package, which is not available everywhere.
Hello, I'd like understand how groups of package are now detect ,
specially in 3rd repo packages which can't use comps.xml.
-------- Forwarded Message --------
From: Sérgio Basto <sergio(a)serjux.com>
Subject: Re: [Fedora-packaging] Re: why the Group tag is obsolete ?
Date: Sun, 28 Aug 2016 07:24:58 +0100
On Seg, 2016-08-01 at 09:17 -0600, Dave Johansen wrote:
> On Sun, Jul 31, 2016 at 9:23 PM, Sérgio Basto <sergio(a)serjux.com>
> > Hi,
> > A year ago, I learned that Group tag is obsolete  I remember ask
> > the
> > reason and is something about comps.xml that I don't remember
> > neither
> > find on google , but for projects that still use repoview, Group
> > tag is
> > needed. So the questions are, have we any replacement for repoview
> > ? or
> > another way to show one repo content ? and why the Group tag is
> > obsolete ? can someone remind me why. And how we now the group of
> > one
> > package ? .
> > Thanks.
> >  https://bugzilla.redhat.com/show_bug.cgi?id=1239067#c1
> Here's the FPC ticket about it:
Thanks I was able to find the reason:
RPM in Fedora 18 does not require the presence of the Group tag in the
spec file. If the tag is defined, it will be ignored. The package
groups of the yum application are used on a Fedora 18 system as the
relevant source of information on which group is the package a part
I remembered in one thread of devel mailing list on create hawaii group
and bingo found the link:
So now, how I know the group of the package (via yum or dnf) ? seems to
me many packages will not have group ... and 3rd-part software ?
Also /usr/bin/gnome-software how find the group of the package ?
Well this is not a very important matter , but I'd like try organize
packages in groups , via repoview.
Sérgio M. B.
Sérgio M. B.
OCaml 4.03 has been out for a while.
I'm intending to add it to Fedora Rawhide once a side tag has been
This will require rebuilding every OCaml package, which I normally do
using a script, but probably there will be manual rebuilds necessary
A few issues that may affect people:
(1) There is a new ppc backend upstream, and I intend to switch to this.
For years we have maintained our own out-of-tree ppc64 & ppc64le
backends. I want to switch to the upstream ppc backend (which
supports, in theory, ppc 32 bit, ppc64 and ppc64le). However when I
actually tried this I found it to be rather buggy, it couldn't even
compile many basic OCaml packages. This time I intend to switch, and
we'll deal with the bugs.
(2) There is a new s/390x backend upstream. This should enable us to
compile all s/390x packages as native code.
It also means that all supported architectures (yes, even riscv64)
will support native compilation for OCaml.
(3) The real reason I'm doing this now is because partners have asked
us to update the OCaml compiler in RHEL 7.4. This will be a binary
ABI break -- it's unfortunately unavoidable -- and will require all
OCaml-using programs to be recompiled, and of course that will affect
CentOS and any other RHEL derivatives.
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
I kinda hate kicking off discussions like this without having a solid
solution to propose or being able to promise to work on one, but this
really seems important. Unfortunately I can't claim I'm gonna have time
to do any concrete work on it, though I'd really *like* to. But I
thought it would be worthwhile to kick around still; perhaps someone
else will be inspired.
I just read Hedayat's review of Fedora 25 Beta:
and this really jumped out at me:
"And, if you care about your internet usage, make sure that you disable
both dnf makecache timer, and stop PackageKit from downloading updates
automatically. I don’t allow a new Fedora installation to access
internet before doing these, as it might just eat a considerable amount
There's two things I think are somewhat unfortunate here:
1) Both dnf and GNOME Software / PackageKit default to performing
fairly data-hungry transactions in the background, out of the box,
without telling you about it. GNOME's is particularly bad, as it will
happily download available updates in the background, which can be
gigabytes worth of data. DNF only updates its metadata caches (on a
systemd timer), but even that could be behaviour that users in certain
circumstances really really do not want.
2) There is no particularly obvious or visible mechanism for a 'typical
user' (or, if you prefer, many of the target 'personas' for our
flavors) to configure this behaviour...and you have to figure out two
completely *different* configuration mechanisms in order to shut off
I think this is kind of poor behaviour on our part and we should make
it better. Do I have a specific concrete proposal? No. But I do have
some vague ideas.
* We could have some kind of configuration interface appear on install
/ first boot. This would require integration with anaconda and/or
initial-setup and gnome-initial-setup.
* We could invert the defaults and have the apps ask the user if they
want to enable data-hungry background operations on first interaction:
the first time you use dnf (without -y) it could say 'hey, do you want
to turn on background cache refreshes?' Similarly, the first time you
run GNOME Software or click on an update notification, it could say
'hey, do you want to turn on background update downloads'?
* We could at least make both of them respect one single config setting
for 'do data hungry background operations' (this is kinda one small
part of the bigger issue that is 'dnf and PK-based stuff don't share
any configuration aside from repo definitions').
Anyone have thoughts on this? Any DNF or Software devs want to say I'm
totally wrong and an idiot? Anyone inspired to do something more
concrete than a mailing list post? :)
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net