Warning: long post ahead.
Are there any plans to let packages specify that they do not require a
total system reboot to be updated?
The other day, Gnome software prompted me to reboot just to update google
chrome. Given that nothing depends on chrome, and also that the Linux
version of chrome is specifically designed to tolerate having its files on
disk overwritten (
rebooting the whole system seems overkill to ensure a successful update.
Presenting users with an option to restart only the affected processes and
not their whole computer would improve security by reducing the friction
when applying software updates. While restarting a browser is no big deal
because it takes no more than a few seconds to complete and all your tabs
are restored, restarting the computer is far more disruptive. The latter
procedure not only takes much longer but also closes all the other windows
the user has open, and the state of those windows is typically not
preserved across reboots. The average users would likely put off updating
their web browser if they were asked to quit everything they are doing.
On OS X and Windows, user-facing apps typically manage their own updates,
and the well-designed apps make the experience quite painless. For example,
both Firefox and Chrome on OS X download new versions in the background and
prompt the user to relaunch the browser once the update is fully prepared.
The user transitions to the new version seamlessly.
On Ubuntu, Firefox is updated by the system package manager but prompts the
user to relaunch the program if it is running. This is probably
ubuntu-specific behavior and I don't know how it is accomplished or how
robust it is, but that would seem a nice example to follow, at least in
terms of UX, if it could be implemented using general methods.
Just a stupid idea: perhaps one can specify some dbus method that
that applications declaring support for online updates could implement.
Prior to initiating the update process, Gnome software could 1) check to
see if all the applications in the queue have declared support for online
updates (say, in their appdata manifest), and 2) call said method to warn
each app that it is about to be updated. Each app would then decide how to
proceed; for instance, it could do nothing, ask the user to save and quit
temporarily, or trigger some session-saving mechanism.
In the long term, this issue will undoubtedly be addressed as part of the
push toward frameworks and a clearly defined "base platform". In that
future, the software updater could prompt the user to reboot for framework
updates while giving applications the option to handle some aspects of
their update process.
But is there anything planned for the interim? Prompting users to restart
the system to update a browser seems less than, and the last thing we want
to do is condition users to postpone updates indefinitely like they grew
accustomed to doing on Windows.
in Fedora Rawhide there is a new major version of mongoDB 2.6. With this
new version names of mongoDB configuration files will be changed - to
reflect names used in upstream rpms
mongodb.conf -> mongod.conf
mongodb-shard.conf -> mongos.conf
In Fedora mongodb.conf is used from version 12.
If this change should be a problem, please contact me...
= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
Change owner(s): P J P <pjp(a)fedoraproject.org> and Fedora Security Team
To disable remote root login facility in sshd(8) by default.
== Detailed Description ==
Sshd(8) daemon allows remote users to login as 'root' by default. This
provides remote attackers an option to brute force their way into a system.
Empirically it is observed that many users use their systems via 'root' login,
without creating non-root user and often have weak passwords for this mighty
account. sshd_config(5) has an option 'PermitRootLogin=yes|no' which controls
sshd(8) behaviour; it is set to be 'Yes' by default. Disabling remote root
login by setting PermitRootLogin=no would help to harden Fedora systems,
moving it an inch closer towards 'secure by default' future. Users can have
non-root accounts with weak passwords too, yet disabling remote root login
keeps an attacker a step away from getting full control on a system. There is
another option of disabling user login via password and require usage of
cryptographic keys for the same. But that could a next step in future.
Please see -> https://lists.fedoraproject.org/pipermail/devel/2014-November/204530.html
== Scope ==
* Proposal owners: to communicate with the Fedora maintainers of packages:
Anaconda, OpenSSH, GNOME, etc.
* Other developers: packages like Anaconda, GNOME etc. need to update their
workflow to enable compulsory non-root user account creation and ensure good
password strength for it.
* Release engineering: installer needs to ensure creation of non-root user
account with strong password. Similarly, all Fedora images must be created
with a non-root user account.
* Policies and guidelines: unknown yet.
devel-announce mailing list
FESCo elections are now open and we're looking for five new
committee members. Elections closes promptly at 23:59 UTC
on February 3rd. Don't forget to vote!
To cast your vote, go to:
Read more about Fedora elections at
and about the new FESCo at
We use range voting in this process — vote for as many or as
few candidates as you like on a sliding scale.
Note: we were planning Env and Stacks WG elections too but
as number of candidates was the same as open seats, Env and
Stacks group decided not to run elections this time and
accept all candidates as committee members. See the announce-
ment from Honza Horak.
The Fedora Magazine interviews got delayed as we were waiting
for more questions being asked from the community. If you
need it to make your decision, please check magazine later.
devel-announce mailing list
I just filed 2 bugs [A], [B] for the Python 3 switch [C] and I realized that I should probably follow the mass bug filing policy.
As I've said previously, we've already had both Python 2 and Python 3 on LiveCDs for few releases, so it makes sense to move as much as possible to Python 3. My intention is to mass file bugs only for "applications" (see the second item in second list at [D]) - in short, these are packages for which it doesn't make sense to introduce python3- subpackage, but it only makes sense to rebuild them with Python 3.
The mass bug filing policy suggests providing text of the bug for review, so here it is:
Since your package requires Python and is considered an application as per , I'd like to ask you to rebuild it with Python 3. Please see recommendations and notes at . Note: this switch should only be done assuming you need to do none or very little downstream patching of upstream source. If upstream source doesn't work with Python 3, it's ok to stay with Python 2.
Some general notes:
If your package depends on Python because of a Python script that has /usr/bin/python in hashbang, you need to change this to /usr/bin/python3. All "Requires" and "BuildRequires" on Python extension modules have to be changed from "python-foo" to "python3-foo" in order for this change to work. If your package is an "application" (let's call it "foo") and it also generates a subpackage with Python bindings (i.e. "python-foo" or "foo-python"), you should provide a python3 subpackage ("python3-foo" or "foo-python3") and use that as dependency of other subpackages.
If everyone agrees, I'll send a mail to devel-announce, saying that we're switching to Python 3 and all maintainers should rebuild with it, assuming that upstream sources are Python 3 compatible. After a week or so I'll file bugs for the remaining components. I haven't yet determined the number of affected packages, since I'm mostly interested in packages that are on LiveCD/cloud images - there are ~10 of these that don't have bugs filed.
I'll wait a while before sending the mail to devel-announce so that everyone has time to comment on this.
This is a bug but I am unsure how to report it. Anyway the problem is
that I do not get any sound from Rhythmbox and Totem. I get sound from
Gnome shell, the gnome terminal, mplayer and the speaker test in
As far as I know Rhythmbox, Totem and Gnome use Gstreamer, so it
should not be problem there. Or is this incorrect?
Does anyone else have similar problems? Or could this be something
special on my computer (I have a hw bug about sound here:
Currently dnf and yum have their own yumdb's, under /var/lib/dnf/yumdb and
/var/lib/yum/yumdb respectively. Among other things, these databases
record whether a package was explicitly installed by the user or pulled in
automatically as a dependency of another package. This information is used
by the "dnf autoremove" and "yum autoremove" routines to determine which
additional packages can be safely removed. As Packagekit currently writes
to yum's yumdb, "dnf autoremove" will not work correctly when run on
packages that were installed using Gnome software, and vice versa.
Thus we should consider merging the yumdb's as part of the F22 transition
to a unified dnf/hawkey package management backend. From a brief
inspection, the two yumdb's on my system appear to have the same structure.
All that would need to be done is decide how to proceed in the rare event
when the same package appears in both yumdb's. On my machine, make and
pkgconfig show up in both yumdb's with the install reason marked as "group"
by dnf and "dep" by yum. Since dnf knows more than yum due to its tracking
of groups (
I'd be inclined to let dnf's version take precedence.
Please add this copr
Please review this branch:
Please test this on F21 and F22
Please monitor and report issues in this bug here:
Please send beer. No? oh well, was worth a try... :)
Anwyay, I've tested this on F21 and with xorg/libinput bits equiv to
rawhide and it works for both. As I point out in the bug:
"Note that we need to keep supporting both synaptics and libinput. libinput
has less knobs to tweak, so a large portion of the UI is now disabled.
Long-term upstream KDE should reconsider the design of the kcm_touchpad
module to accommodate for both drivers, but for now I think this will do.
Also note that disable-while-typing is disabled because libinput does it
automatically (or something very similar anyway).
Also note that the Fedora 20 libinput version does not support switching
scroll methods, so that'll be permanently disabled in the GUI (but enabled
on the touchpad). And edge scrolling is only available on single-touch
touchpads, so that's permanently disabled in the GUI too."
So this is the classic 90% case to make things work. A bit of polish is
needed but I'd like for upstream to help out with that.
I'm trying to do the following:
1) add the smi2021 driver for EasyCap Somagic usb frame grabbers into the
2) compile the kernel with smi2021 as a module
3) build the rpm.
I got the driver from Jon Arne Jorgensen's kernel branch on github:
then tried to follow these instructions:
but the whole thing fails with this eror:
+ case "$patch" in
+ patch -p1 -F1 -s
+ chmod +x scripts/checkpatch.pl
+ touch .scmversion
+ mkdir configs
+ for i in '*.config'
+ mv kernel-3.17.8-aarch64.config .config
++ head -1 .config
++ cut -b 3-
+ make ARCH=arm64 listnewconfig
+ grep -E '^CONFIG_'
+ '[' -s .newoptions ']'
+ cat .newoptions
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.sASN4F (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.sASN4F (%prep)
So I spent a lot of time trying to figure this out and I know why it happens
but I don't know how to fix it.
The smi2021.patch being applied above is the diff between the kernel trees
with and without the driver. The patch succeeds. The problem is that in
order to have the module compiled I did make oldconfig and so I ended up with
in the kernel-3.17.8-x86_64 **ONLY**. Then the kernel.spec has some code
that runs oldconfig over **ALL** the kernel*.config files:
for i in *.config
mv $i .config
Arch=`head -1 .config | cut -b 3-`
make ARCH=$Arch listnewconfig | grep -E '^CONFIG_' >.newoptions || true
if [ -s .newoptions ]; then
rm -f .newoptions
make ARCH=$Arch oldnoconfig
echo "# $Arch" > configs/$i
cat .config >> configs/$i
# end of kernel config
Of course, none of the other config files (for other architectures then
x86_64) have the CONFIG_VIDEO_SMI2021 options, hence the error.
So the key question is what is the proper way to add a new driver to the
kernel tree and run
rpmbuild -bb --target=$(uname -m) kernel.spec
on it? Do I put CONFIG=VIDEO_SMI2021=m in SOURCES/config-local, or what?
For what it's worth, I am able to do
make oldconfig # picks up the option for the new driver
in the kernel tree with the new code in it and it goes through without errors.
So if I want to run the new kernel with the new driver, I can, but I'd rather
do this by building the custom rpm, as I don't know when or if this driver
will be included in the vanilla kernel.
Please help, I'm at the end of my wits. Thanks!