On 01/28/2014 10:59 AM, Maros Zatko wrote:
> On 01/16/2014 12:54 PM, Martin Stransky wrote:
>> On 01/14/2014 07:12 PM, Maros Zatko wrote:
>>> On 01/14/2014 03:38 PM, H. Guémar wrote:
>>>> What's the point ?
>>> Personally, it's mainly about not throwing gnome 3 HIG at people.
>>>> There's absolutely no benefit in keeping Gtk+2 longer.
>>>> Gtk+ 2.24.0 has been released 3 years ago (january, 2011) and is only
>>>> receiving bugfix due to existing apps who didn't move to Gtk+3.
>>> Oh yes, Wayland.
>>>> By migrating more apps, we can drop Gtk+ 2.24 (at least from images),
>>>> firefox is one of the major application that prevents us to do so.
>>> Is it possible to keep current gtk 2 face as a different
>> No, but we can keep config flags for that in firefox.spec so you can
>> build your own package at copr. But it's realy a long term issue, a
>> first Firefox with Gtk3 support is Firefox 29.
> My question was if GTK2 face is going to be still available at least at
> the source level. (I know it's possible, since FF has different faces
> for win, osx and gtk.) Or you're going to "migrate" gtk2 face to gtk3
> (and completely obfuscate any attempt to use the older one; the same
> thing as we've seen with gnome 2.x related applications)?
I don't think mozilla is going to remove gtk2 support, the gtk2/gtk3
port shares the same files and directories.
Two of the libraries emitted by libxcb (for XKB and SYNC extension
support) have changed soname in 1.10. Sorry about that. Outside of
libxcb itself the only packages affected are qt5-qtbase, kde-workspace,
sddm, and weston; all have been rebuilt. Thanks to Rex Dieter for
helping work around the qt5 bootstrap issues.
This might be a viewed as a fire torch, but there is, IMO, a major
regression in BlueZ 5 which is shipped in Fedora 20. It doesn't support
HSP/HFP headset profiles, which enables the microphone on many bluetooth
headsets. It's already tracked in this BZ:
It seems a solution for BlueZ 5 isn't close, especially not for F20.
Upstream is looking at this issue, but not much news have been told yet:
Anyhow, not supporting HSP/HSP profiles is at least hitting my work
ability, and I doubt I'm alone in this situation.
Now, if I had known this before I started upgrading to F20, I wouldn't
have upgraded yet but stayed on F19 a bit longer. However, that's too
late now. This was first listed as a "common bug" about three weeks
after the release.
So, I wonder if it can be considered to enable a "downgrade path" for
bluez and depending packages, as described in the "Contingency Plan":
The other alternative is to tell users to re-install Fedora 19, which I
doubt is such a good alternative in the long run. But I need to
consider that if BlueZ isn't downgraded somehow.
As a side note, it also needs to be discussed how such a key feature of
the bluetooth stack could go unnoticed through QA, and how to avoid this
from happening again.
Take, for example, https://github.com/nfs-ganesha/nfs-ganesha/releases,
where there's a button for "Source code (tar.gz)" pointing at
Note V2.0.0.tar.gz versus nfs-ganesha-2.0.0.tar.gz.
If I click on that link the downloaded file is named
nfs-ganesha-2.0.0.tar.gz by virtue of the Content-Disposition http header.
Likewise if I use `curl -L ...` the downloaded file is named
But for my nfs-ganesha.spec file, if I use the github link shown above,
I have to load a file V2.0.0.tar.gz into the look-aside cache. Anything
else and rpm and rpmlint whine.
Is there a best practice here that I'm missing?
-----BEGIN PGP SIGNED MESSAGE-----
I wrote a systemd unit file to enable it, and to allow a user to disable the
feature if he wants.
# cat /usr/lib/systemd/system/selinux-checkreqprot.service
Description=SELinux check actual protection flags applied by kernel, rather
than checking what application requested.
ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT > /sys/fs/selinux/checkreqprot'
I would like to enable this service on the post install of a initial install
of libselinux. But I believe this will not happen with
How would I go about doing this?
I know there is one problem in the unit file, it will fail if
/sys/fs/selinux/checkreqprot, does not exist. Is their an easy check to just
exit if this file does not exist?
Also is using a unit file for this, the best way to handle this?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----