on software updates
by Casey Jao
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 (
http://neugierig.org/software/chromium/notes/2011/08/zygote.html),
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.
6 years
mongodb.conf rename
by Marek Skalický
Hi,
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
(http://downloads-distro.mongodb.org/repo/redhat/os/x86_64/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...
Thanks,
Marek
6 years
F22 System Wide Change: Set sshd(8) PermitRootLogin=no
by Jaroslav Reznik
= Proposed System Wide Change: Set sshd(8) PermitRootLogin=no =
https://fedoraproject.org/wiki/Changes/SSHD_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
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
6 years
FESCo elections are open
by Jaroslav Reznik
Greetings,
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:
https://admin.fedoraproject.org/voting
Read more about Fedora elections at
https://fedoraproject.org/wiki/Elections
and about the new FESCo at
http://fedoraproject.org/wiki/Development/SteeringCommittee
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.
Jaroslav
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
6 years
Filing Bugs for Python 3 Switch
by Bohuslav Kabrda
Hi,
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 [1], I'd like to ask you to rebuild it with Python 3. Please see recommendations and notes at [2]. 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.
[1] http://fedoraproject.org/wiki/Changes/Python_3_as_Default
[2] https://fedoraproject.org/wiki/Packaging:Python#Guidelines
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.
Thanks,
Slavek
[A] https://bugzilla.redhat.com/show_bug.cgi?id=1186791
[B] https://bugzilla.redhat.com/show_bug.cgi?id=1186792
[C] http://fedoraproject.org/wiki/Changes/Python_3_as_Default
[D] https://fedoraproject.org/wiki/Changes/Python_3_as_Default#Scope
6 years
GStreamer (?) sound problems on 21
by Andreas Tunek
Hi everyone
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
Gnome.
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:
https://bugzilla.redhat.com/show_bug.cgi?id=1186032)?
/Andreas
6 years
F22: Merge yumdb for yum->dnf migration?
by Casey Jao
Hello,
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 (
http://dnf.baseurl.org/2014/04/23/how-groups-are-handled-in-modern-day-dnf/),
I'd be inclined to let dnf's version take precedence.
Best,
Casey
6 years
Testers needed: KDE kcm_touchpad libinput support
by Peter Hutterer
Please add this copr
https://copr.fedoraproject.org/coprs/whot/kcm_touchpad/
Please review this branch:
https://github.com/whot/kcm_touchpad/tree/wip/libinput-support
Please test this on F21 and F22
Please monitor and report issues in this bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1184713
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.
Cheers,
Peter
6 years
adding new driver to kernel src and building rpm
by Amadeus W.M.
I'm trying to do the following:
1) add the smi2021 driver for EasyCap Somagic usb frame grabbers into the
kernel tree
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:
https://github.com/jonjonarnearne/smi2021
then tried to follow these instructions:
https://fedoraproject.org/wiki/Building_a_custom_kernel
but the whole thing fails with this eror:
Patch100000: smi2021.patch
+ 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-
+ Arch=arm64
+ make ARCH=arm64 listnewconfig
+ grep -E '^CONFIG_'
+ '[' -s .newoptions ']'
+ cat .newoptions
CONFIG_VIDEO_SMI2021
+ 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
CONFIG_VIDEO_SMI2021=m
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
do
mv $i .config
Arch=`head -1 .config | cut -b 3-`
make ARCH=$Arch listnewconfig | grep -E '^CONFIG_' >.newoptions || true
%if %{listnewconfig_fail}
if [ -s .newoptions ]; then
cat .newoptions
exit 1
fi
%endif
rm -f .newoptions
make ARCH=$Arch oldnoconfig
echo "# $Arch" > configs/$i
cat .config >> configs/$i
done
# end of kernel config
%endif
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
make
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!
6 years