devel April 2014

devel@lists.stg.fedoraproject.org

237 participants
237 discussions

F21 Self Contained Change: Docker Cloud Image
by Jaroslav Reznik 20 May '14

20 May '14

= Proposed Self Contained Change: Docker Cloud Image = https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image Change owner(s): Cloud SIG / Sandro Mathys <red(a)fedoraproject.org> New Fedora product: Fedora Docker Cloud Image - Docker host ready to go. == Detailed Description == Fedora Cloud agreed to make a base image plus several tailored to specific purposes. This is one of the tailored ones — Docker host ready to go. While basically that simply means only just adding docker-io to the base image, this is (also) intended to be our response to CoreOS. Therefore, depending on further discussion and user input, we might also add etcd [1] and fleet [2] to the mix. Furthermore, the Cloud SIG considers this their most radical image, riding the very front of the leading edge. (Yeehaw!) Several approaches (read: bonus objectives) are under consideration but not crucial to the product itself: * Fedora Atomic Initiative [3] (aka rpm-ostree) to allow for atomic updates. We might further choose to remove yum/dnf from the image in favor of ostree. * Replace cloud-init with min-metadata-service, CoreOS' cloud-init or other alternatives. We'd like to find a leaner solution (read: less Requires) and one that is better (or easier) tailored to Fedora. * Remove Python from this image to reduce the footprint. Note, that this can only be achieved if yum/dnf AND cloud-init are replaced by other solutions as explained in the above points. It should be noted that most of these tools are currently under heavy construction but might be ready in time. If they are, it's still up to discussion whether they will be included. If they aren't, we might punt them to F22 or later. Either way, they won't impact the completion of this change's main goals and are only listed for completeness' sake. == Scope == * Proposal owners: Regarding the core objective, it's just about creating a new kickstart file (probably even %include-ing the base one) add some minor stuff and make sure it gets built into a new image. Also, for added security, we'd like to see Docker and SELinux integrate better. There's already work going on about this. ** The bonus objectives (i.e. leading edge approaches) further require: *** ostree to work with SELinux *** Creating a filesystem tree for ostree that equals the filesystem of the image as created by traditional means *** min-metadata-service to gain the ability to execute scripts just like cloud-init does *** CoreOS' cloud-init or other alternatives to be packages (and possibly tailored) for Fedora * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) [1] https://github.com/coreos/etcd [2] https://github.com/coreos/fleet [3] http://rpm-ostree.cloud.fedoraproject.org/ _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

6 6

trimming down Fedora installed size
by Marius A 16 May '14

16 May '14

Hi there, I've been struggling keeping a fedora 20 install on a "small" SSD, with 6gb / partition (/home is separate). Besides removing packages, I also found this useful: 1. remove /usr/share/docs 2. remove /usr/share/locale/* (all except en and en_US) 3. cleanup /var/log/journal, which seems it's not automatically rotated While this saves space, it also results in package upgrade warnings due to missing files. Are there any other disk space saving tips? What do you think about excluding docs by default in Fedora packages? And for docs either go online, or have a command to install/sync docs for all installed packages? (similar to ruby or npm packages install, not using rpm packages) I think less than 0.1% of users ever look into /usr/share/doc, but I don't have any data to back this up. As more folks switch to SSDs, it would benefit both for disk space saving and wearing to have less space occupied by default. Thanks

23 57

F21 System Wide Change: (A)Periodic Updates to Images
by Jaroslav Reznik 16 May '14

16 May '14

= Proposed System Wide Change: (A)Periodic Updates to Images = https://fedoraproject.org/wiki/Changes/%28A%29Periodic_Updates_to_Images Change owner(s): Cloud WG collectively, with Matthew Miller <mattdm(a)fedoraproject.org> as point of contact Responsible WG: Cloud We want to be able to release updated images not just at release time. Hope for a one-month regular cadence, plus emergency updates if needed. == Detailed Description == We need to be able to produce official updates to the Fedora Cloud images. Initially, we plan to release these updates monthly, but also need the ability to release an out-of-cycle update in the event of a severe security issue. This involves: 1. policy for level of security issue required for out-of-cycle updates 2. procedure for notification of security updates in images (as with rpm updates) 3. automated QA (at least smoketests) 4. documentation of QA expectations 5. release engineering process 6. mirroring of updated images 7. updates to web site for new download links and EC2 AMI IDs. Note that this will apply to the Cloud Base Image, the Docker Host Image, the Big Data Image, and the Docker Container Base Image. (The latter may need separate handling.) Ultimately, we would like to produce updates whenever a package on the image or the kickstart file for the image changes. This is a step towards that goal. == Scope == * Proposal owners: Create policies and procedures as outlined above. Will also assist with changes to release engineering. * Other developers: Contributions welcome! * Release engineering: Significant impact, obviously. Cloud WG will interact heavily with Release Engineering and work in concert. * Policies and guidelines: No changes to existing policies. _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

7 13

Attempting to contact three unresponsive maintainers
by Toshio Kuratomi 15 May '14

15 May '14

Greetings, we've been told that the email addresses for three package maintainers are no longer valid. I'm starting the unresponsive maintainer policy to find out if they are still interested in maintaining their packages (and if so, have them update their email addresses in FAS). If they're not interested in maintaining or we can't locate them I'll have FESCo orphan the packages so that others can take them over. If you have a way to contact any of these maintainers, please let them know that we'd appreciate knowing what to do with their packages. Thanks! Maintainers: * awnuk -- former email address awnuk(a)redhat.com - comaintainer of dogtag-pki, dogtag-pki-theme, pki-console, pki-core, pki-ra, and pki-tps * llim -- Lawrence Lim -- former email address llim(a)redhat.com - Bugzilla owner of redhat-lsb * osier -- Osier Yang -- former email address jyang(a)redhat.com - comaintainer of libvirt If we get to the point of removing acls for these people, only redhat-lsb will need a new owner. The other packages just have these package maintainers as comaintianers. -Toshio

3 4

Python 3.4 to rawhide
by Matej Stuchlik 12 May '14

12 May '14

Good day folks, Python 3.4 is now [ready and tagged] in f21-python, so I'd like to ask you to make whatever modifications that may be necessary and [rebuild] your Python packages into the tag. Once we have sufficient fraction up and running, we'll merge with rawhide. Note that your spec file may require slight tweaks due to some file suffixes changing: * bytecode files from .cpython-33.py[co] to .cpython-34.py[co] * extension modules from .cpython-33m.so to .cpython-34m.so and .cpython-33dm.so to .cpython-34dm.so There's also an upstream guide to [porting to Python 3.4] you may find helpful. Finally, should you need help with your package, feel free to contact me and I'll do my best to help... :) Matt [ready and tagged] http://koji.fedoraproject.org/koji/taskinfo?taskID=6794120 [rebuild] with fedpkg build --target f21-python [porting to Python 3.4] https://docs.python.org/dev/whatsnew/3.4.html#porting-to-python-3-4

4 10

heads up: plist/usbmux/imobiledevice soname bumps
by Peter Robinson 10 May '14

10 May '14

Hi All, There's a new devel release of the above just landed. I'll be looking to get them into rawhide over the new couple of days but there's been quite some change so I'm going to deal with it all locally first to see what the impact is before I push it. Peter

2 8

F21 Self Contained Change: Playground repository
by Jaroslav Reznik 08 May '14

08 May '14

= Proposed Self Contained Change: Playground repository = https://fedoraproject.org/wiki/Changes/Playground_repository Change owner(s): Marcela Mašláňová <mmaslano(a)redhat.com>, Mirek Suchý <msuchy(a)redhat.com> Responsible WG: Env and Stacks WG The Playground repository gives contributors a place to host packages that are not up to the standards of the main Fedora repository but may still be useful to other users. For now the Playground repository contains both packages that are destined for eventual inclusion into the main Fedora repository and packages that are never going to make it there. Users of the repository should be willing to endure a certain amount of instability when using packages from there. To avoid any potential confusion, we want to make it clear that the Playground repository will not host packages that have bad licenses, include proprietary software or include patented software. == Detailed Description == We are still working on details but the main ideas are finished and described in the [1]. Packages for the repository are built in COPR. The COPR owner can propose the repository as a whole for inclusion into the Playground repository by marking it as such in COPR. Repositories/packages successfully built and satisfying the Playground repository's Policies are copied into the Playgroud repository. The one Playground repository includes many Copr repositories. Playground repository is only meant to provide packages for Fedora 21 and later versions. Initially, the repository will be provided as a Beta for a limited number of packagers and testers, so we'll be able to incrementally define the remaining details of the workings of the repository. To enable the repository, testers will need to use DNF along with its Copr plugin. == Scope == * Proposal owners: ** Document process, setting, guidelines (if any) ** Communicate with Copr developers * Other developers: ** Copr devs *** Ability to mark an individual COPR for inclusion in the Playground repository. *** Copr deployment that's considered reliable enough to build packages for this repo * Policies and guidelines: ** Packages must follow the Legal Guidelines. In particular, the license for all packages must be approved in the Legal Guidelines. ** Packages may violate other Fedora Packaging Guidelines. [1] https://fedoraproject.org/wiki/Env_and_Stacks/Playground_repository_(draft) _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

16 30

Fedora 20 Puppet update and SELinux policy
by Lukas Zapletal 06 May '14

06 May '14

Hello, we are rolling out update of Puppet to 3.4.3 in Fedora 20 and Rawhide that adds one important change. We have found that puppet master was running unconfined, therefore the Puppet SELinux policy was not effective in Fedoras. The puppet package update fixes one little issue (missing runtime dependency) and corrects startup wrappers for systemd which puts Puppet Master into the correct SELinux domain puppetmaster_t. Since this has some security impact, we have decided to backport this change into Fedora 20 too. https://admin.fedoraproject.org/updates/puppet-3.4.3-3.fc20 Until now, puppet master was running unconfined (this is a regression), the update might need relabelling of the system (/etc/puppet, /var/lib/puppet) or checking out audit.log. Please help me with testing this update: yum --enablerepo=updates-testing update selinux-policy puppet puppet-server Thanks for help. -- Later, Lukas "lzap" Zapletal irc: lzap #theforeman

2 3

F21 System Wide Change: Java 8
by Jaroslav Reznik 06 May '14

06 May '14

= Proposed System Wide Change: Java 8 = https://fedoraproject.org/wiki/Changes/Java8 Change owner(s): Omair Majid <omajid(a)redhat.com> Make Java 8 (provided by OpenJDK 8 which is java-1.8.0-openjdk) the default Java runtime. The current default Java runtime (Java 7, provided by OpenJDK 7, java-1.7.0-openjdk) will be obsoleted and removed. This is essentially an upgrade to the latest Java and OpenJDK version. == Detailed Description == The current default Java 7 runtime in Fedora is OpenJDK 7. The latest version of OpenJDK, 8, was released on 18 March 2014. Given that Fedora 21 will not be released before August, it makes sense to include the latest version of OpenJDK in Fedora 21. OpenJDK 8 is a significant update to Java. It brings in significant new features to the Java language, including lambdas, a new javascript engine and lots of new library features. A complete list of features is available [1]. OpenJDK 8 is a backwards compatible update. Theoretically everything that worked against OpenJDK 7 should continue working against OpenJDK 8. There are a few exceptions: OpenJDK8 is much more strict when it comes to building javadocs. Many - javadoc package in Fedora fail to build. Those that are built should continue working just fine. Packages that rely on non-public OpenJDK API may fail to build/run. A complete list of incompatibilities is available [2]. The incompatibilities are source and behavioral only. It may be a good idea to mass rebuild Java packages against OpenJDK 8 to spot any source incompatibilities earlier. This is not required. == Scope == * Proposal owners: ** Deprecate/Obsolete java-1.7.0-openjdk ** Promote java-1.8.0-openjdk to a full java runtime status (fix provides in package) ** In case of a mass rebuild, supply/apply patches to fix build against OpenJDK 8 * Other developers: ** icedtea-web maintainers will need to update icedtea-web to run against OpenJDK 8 ** Other java packagers will need to apply patches to their java package to ensure they can build against OpenJDK 8 ** Everyone will need to test packages to verify that they work against OpenJDK 8 * Release engineering: ** Remove java-1.7.0-openjdk ** Possibly mass-rebuild (?) all Java packages. This is not strictly required to make OpenJDK 8 the default Java runtime. * Policies and guidelines: ** Many -javadoc packages fail to build. The OpenJDK 8 maintainers and the Java SIG are working on identifying a solution. The solution may require [3] guideline changes making -javadoc subpackages optional. [1] http://openjdk.java.net/projects/jdk8/features [2] http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366… [3] https://lists.fedoraproject.org/pipermail/devel/2014-March/196808.html _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

15 31

fedora-atomic discussion point: /usr/lib/passwd
by Colin Walters 05 May '14

05 May '14

For the fedora-atomic work, the only not-in-Fedora package is shadow-utils because it requires a patch, that still lives in my walters/rpm-ostree COPR. Patch is linked from my post here: http://lists.alioth.debian.org/pipermail/pkg-shadow-devel/2014-March/010099… Also, some discussion in the glibc bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16142 What I'd like to open is a discussion about whether /usr/lib/passwd is the right thing long term. I think it'd be very useful to support it short term, but it's not perfect. The main case where it breaks is when you have a daemon that runs as non-root and saves state, so you give it its own system user, but not a reserved uid. Daemons in this class will have their uids effectively ordered by package installation order =/ One way to fix this that goes with my general direction of moving things out of %post into systemd: a dynamic uid reservation system that saves state persistently. Crudely, this would be ExecStartPre=/usr/sbin/useradd -r ... except we'd wrap that with something that checked whether the user existed first. Then /etc/passwd would still be local system-persistent state, and OSTree still wouldn't need to run a %post. I think though it'd be good to still use /usr/lib/passwd in this model for daemons that *don't* save state persistently, like dbus. No need to pollute /etc/passwd with them. (Note, we'd also need to teach %systemd_preun to run some kind of ExecUninstall=, or skip spawning subprocesses and teach systemd how to modify the user database directly) Thoughts?

14 45

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 April 2014