devel January 2015

devel@lists.fedoraproject.org

257 participants
264 discussions

Heads-up: python{,3}-sphinx-latex subpackage in Rawhide
by Michel Alexandre Salim 06 Feb '15

06 Feb '15

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

2 3

F22 System Wide Change: Systemd Package Split
by Jaroslav Reznik 05 Feb '15

05 Feb '15

= 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 17

on software updates
by Casey Jao 05 Feb '15

05 Feb '15

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.

12 21

mongodb.conf rename
by Marek Skalický 05 Feb '15

05 Feb '15

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

3 3

F22 System Wide Change: Set sshd(8) PermitRootLogin=no
by Jaroslav Reznik 05 Feb '15

05 Feb '15

= 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

38 105

FESCo elections are open
by Jaroslav Reznik 03 Feb '15

03 Feb '15

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

8 11

Filing Bugs for Python 3 Switch
by Bohuslav Kabrda 03 Feb '15

03 Feb '15

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

11 26

GStreamer (?) sound problems on 21
by Andreas Tunek 02 Feb '15

02 Feb '15

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

3 5

patch(1) no longer applies patches for symbolic links with ".." components in the target
by Tim Waugh 02 Feb '15

02 Feb '15

Last week, patch-2.7.3 was released fixing CVE-2015-1196. Both Fedora 20 and Fedora 21 have testing updates: https://admin.fedoraproject.org/updates/FEDORA-2015-1165 https://admin.fedoraproject.org/updates/FEDORA-2015-1134 The fix prevents patches applying if they are for symbolic links with a target containing the ".." pathname component: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775901#13 Please be aware that some legitimate patches may fail as a result, until a better fix can be found. Tim. */

1 1

F22: Merge yumdb for yum->dnf migration?
by Casey Jao 02 Feb '15

02 Feb '15

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

5 7

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel January 2015