initscripts
by poma
Lukáš 'Allo 'Allo
I see that some people are trying to "modernize" Fedora.
But what about RHEL relictum - initscripts, particularly now that we have NetworkManager/ModemManager and systemd-networkd,
when will this package "fall off"?
poma
9 years, 2 months
Heads-up: python{,3}-sphinx-latex subpackage in Rawhide
by Michel Alexandre Salim
Hi all,
>From python-sphinx-1.2.2-6.fc22 onwards support for building LaTeX
documentation using Sphinx has been split off into the -latex subpackage
(so that Sphinx can be installed without pulling in TeXLive).
(There's also a bug discovered when doing this split -- the python3 build
wasn't shipping with locale files).
As we're not doing a mass rebuild this time round, this change should have
minimum impact.
For maintainers of packages that use Sphinx for building documentation,
please check if you're generating PDFs -- and if so, add a BR on
python-sphinx-latex.
Hat tip to Robert Kuska for the suggestion and feedback.
Best regards,
--
Michel Alexandre Salim
9 years, 2 months
F22 System Wide Change: Systemd Package Split
by Jaroslav Reznik
= Proposed System Wide Change: Systemd Package Split =
https://fedoraproject.org/wiki/Changes/SystemdPackageSplit
Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl>
Split systemd-units out of the main systemd package
== Detailed Description ==
Systemd contains many binaries and depends on a fairly large number of
libraries. Packages which carry systemd units currently have to depend on
systemd (through %post, %preun, %postun macros used to install and uninstall
systemd units), which grows the dependency tree and increases the size of
minimal installs.
With this proposal systemd-units subpackages will be split out again:
systemd-units
This subpackage will contain the directories and binaries necessary to satisfy
%post, %preun, %postun macros for packages containing systemd units
(systemctl, systemd-escape, systemd-sysusers, udevadm, journalctl), and config
information (pkg-config files).
The main systemd package would require this package so it will be pulled in on
all existing systems. All packages which have BuildRequires:systemd will also
pull it in transitively.
Systemd previously had a -units subpackage and ~150 packages still depend on
it. Those packages would start using the reduced subpackage immediately. Other
packages wishing to use the reduced dependency, would have to change the
BuildRequires and Requires to systemd-units.
== Scope ==
* Proposal owners: Create the subpackage, test that macros work as expected.
* Other developers: Change the BuildRequires and Requires to systemd-units if
wanted.
* Release engineering: None
* Policies and guidelines: s/systemd/systemd-units/ in the appropriate places.
== Contingency Plan ==
* Revert the packaging change and rebuild systemd. Main systemd package would
provide systemd-units, as it does now, so no other changes should be
necessary.
* Contingency deadline: should be possible at any time.
* Blocks release? No.
* Blocks product? No.
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
9 years, 2 months
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.
9 years, 2 months
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
9 years, 2 months
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
9 years, 2 months
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
9 years, 2 months
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
9 years, 2 months
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
9 years, 2 months