= Proposed Self Contained Change: IBus Emoji Typing =
* Takao Fujiwara <tfujiwar [at] redhat [dot] com>
The IBus core will provide the Emoji Unicode typing with the IBus XKB engines.
== Detailed Description ==
IBus has already provided Unicode hex codes tying with Ctrl-Shift-u and now we
think the similar implementation for the Emoji typging. With IBus XKB engines,
Emoji typing will be provided with the Emoji annotations  following Ctrl-
== Scope ==
* Proposal owners:
- IBus core provide the dictionary of the Emoji typing.
- IBus XKB engines load the Emoji dictionary.
* Other developers: N/A
* Release engineering: N/A
- List of deliverables: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
So far my idea of maintaining Fedora's iproute package was to do full
version updates only in Rawhide and backport patches selectively to
stable versions on behalf of bug reports.
But since stable versions indeed receive full kernel updates (not just
backported patches), there is an understandable amount of frustration
amongst users when the shiny new kernel that comes with e.g. F22
provides features userspace does not support.
Especially since upstream iproute2 does not really have a concept of
stable versions, I'm in a bit of a dilemma here: update to keep in sync
with the kernel or not update to not unnecessarily destabilize the
Any comments/advice are highly appreciated.
Some time back there was discussion of being able to rollback yum updates via
btrfs snapshotting. As I recall, it turned out that the default btrfs install
was not setup correctly to make this feasible (I had briefly tested it on my
machine). I haven't heard anything since - this seems like a great idea.
-- Those who don't understand recursion are doomed to repeat it
I am asking if anyone knows anything about the whereabouts of Fedora developer Kalpa Welivitigoda? He is the maintainer of unetbootin package. Bug 1229874 would need fixing, but it seems that he is not responding to the bug comments anymore. I tried to ask him about that matter via Facebook as well last Tuesday, but he doesn't seem to respond there either.
– Iiro Laiho
As I'm sure everyone is well aware gstreamer-0.10 is obsolete and has been replaced
by gstreamer-1.0. An upstream release for gst-0.10 has not been made in over 4
years. Last month there were a handful of security vulnerabilities disclosed and
upstream no longer maintains the 0.10 series. While we could patch and update our
Fedora packages this is a perfect opportunity to retire it.
Here is an approximate list of packages depending on gst-0.10. They themselves
should be considered obsolete or retirement material as their upstreams may not have
adopted gst-1.0. If the package doesn't have a gst-1.0 equivalent there may be some
cases where we could patch in support for gst-1.0. Are there any non-Fedora software
that would prevent retirement from being possible?
I'm preparing the shapelib-1.4.0 update, which bumped the soname. There
are no API changes, it was just to synchronize with the debian soname.
Dependent packages are:
I'll need help rebuilding the above packages.
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 :|
Kernel 4.9 was officially released yesterday, December 11. This kernel is
being built for rawhide today. The plan for bringing this kernel into
F24/F25 is going to follow roughly the same schedule as in the past.
This means pushing the new rebase when we think it's stable enough.
In the past, this has happened around the .2 stable release (so 4.9.2
in this case). Given the holidays, this won't be happening until 2017
but we'll be monitoring closely. I'll update with more information
once it gets closer. As always, please let us know if you have any
On Wed, Dec 21, 2016 at 12:18 AM, Miro Hrončok <mhroncok(a)redhat.com> wrote:
> Hi all,
> We've recently tried to rebuild all Python packages with Python 3.6.
> However, we currently have bunch of packages that simply fail to build.
> As the list contains >200 packages, it would be very helpful, if you
> (package maintainers) could help us solve the issues, as we cannot go one by
> one to investigate the issue.
> I've attached the list of failed packages (failed.txt). You can search Koji
> to find out, what went wrong. Sometimes, it's just missing dependency. That
> dependency should be on this list as well. If it is not, maybe we lost it,
> please tell us if that's the case. Maybe the dependency is circular and
> something needs to be bootstrapped. If you need provenpackager powers, let
> me know.
I've fixed python-smartcols and python-behave..
Attaching current rawhide/koji packages which depend on python 3.5
instead of 3.6 still.