F21 System Wide Change: SCL
= Proposed System Wide Change: SCL = https://fedoraproject.org/wiki/Changes/SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com SCL - Software Collections - are popular packaging format above rpm. Let's enable them for Fedora. More details on upstream page [1]. == Detailed Description == My first draft [2] is obsoleted by current state of SCL, Copr... I would keep the SCL workflow simple as possible. Playground repo 1. Build SCL in Copr 2. Add SCL into Playground repo Fedora main repo 0. Build SCL in Copr (or use existing SCL) 1. Do standard package review 2. Upload packages into git - specific branch based on Fedora version and name of collection. For stable repo we must be able to replicate builds from git repo, which Fedora own. 3. Build SCL in koji or magically add SCL builds from Copr (depends on preference of releng) SCL living on Copr can be good candidates for inclusion in Fedora. Maintainer of such SCL must be able create Change proposal for his collection. Review of packages in the collection should depend on repository (Playground - almost no rules, Fedora - standard guidelines). == Scope == * Proposal owners: 0. Approve SCL guidelines by FPC 1. Include one collection into Fedora Playground repository or into main Fedora repository (probably the one wanted by Cloud WG). It might be this one rebuild for Fedora [3]. Updates of some gems or addition of other gems might be needed. Review by Cloud projects is needed. * Other developers: If SCL is in Fedora, maybe some other project can use it for their work. * Release engineering: Magically add SCLs builds into compose or set up koji for SCLs. * Policies and guidelines: https://fedorahosted.org/fpc/ticket/339 https://fedoraproject.org/wiki/User:Toshio/SCL_Guidelines_%28draft%29 [1] https://www.softwarecollections.org/en/ [2] https://fedoraproject.org/wiki/User:Mmaslano/SCLinFedora [3] http://copr.fedoraproject.org/coprs/rhscl/ruby193/ ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
F21 Self Contained Change: Move to ImageFactory For Cloud Image Creation
= Proposed Self Contained Change: Move to ImageFactory For Cloud Image Creation = https://fedoraproject.org/wiki/Changes/Move_to_ImageFactory_For_Cloud_Image_Creation Change owner(s): Ian McLeod imcl...@redhat.com, Dennis Gilmore dgilm...@fedoraproject.org Create images using Anaconda in Koji rather than appliance-creator. Allows non-scratch builds with fedmsg integration for upload service, and also could produce official Docker images. == Detailed Description == Jay Greguske recently added a feature to koji that allows it to create full system disk images using Image Factory. These images can be output both as raw and qcow2 disk images, as well as OVA/OVF bundles compatible with OVirt, VMWare and RHEV-M. They are created by running Anaconda kickstart installs in virt containers and then packaging/encapsulating the results. == Scope == * Proposal owners: The Image Factory support in Fedora koji has already landed and images are already being built using this technique. The work for F21 should mainly involve making sure that the existing cloud kickstart files work when run directly by Anaconda and making any chances needed to ensure that they do. * 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) ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
F21 Self Contained Change: Remote Journal Logging
= Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Systemd journal can be configured to forward events to a remote server. Entries are forwarded including full metadata, and are stored in normal journal files, identically to locally generated logs. == Detailed Description == Systemd's journal currently provides a replacement for most functionality offered by traditional syslog daemons, with two notable exceptions: arbitrary filtering of messages and forwarding of messages over the network. This Change targets the latter. The high-level goal is to have a mechanism where journal logging can be extended to keep a copy of logs on a remote server, without requiring any maintenance, done fairly efficiently and in a secure way. Two new daemons are added as part of the systemd package: * on the receiver side systemd-journal-remote accepts messages in the Journal Export Format [1]. The export format is a simple serialization of journal entries, supporting both text and binary fields. This means that the messages are transferred intact, apart from the cursors, which specify the location in the journal file. Received entries are stored in local journal files underneath /var/log/journal. Those files are subject to normal journald rules for rotation, and the older ones will be removed as necessary to stay within disk usage limits. Once entries have been written to the journal file, they can be read using journalctl and the journal APIs, and are available to all clients, e.g. Gnome Logs [2]. * on the sender side systemd-journal-upload is a journal client, which exports all available journal messages and uploads them over the network. The (local) cursor of the last message successfully forwarded is stored on disk, so when systemd-journal-upload is restarted (possibly after a reboot of the machine), it will send all recent messages found in the journal and then new ones as they arrive. The communication between the two daemons is done over standard HTTPS, following rather simple rules, so it is possible to create alternate implementations without much work. For example, curl can be easily used to upload journal entries from a text file containing entries in the export format. Basically, the data are sent in an HTTP POST to /upload with Content- Type: application/vnd.fdo.journal. When doing live forwarding, the size of the transfer cannot be known in advance, so Transfer-Encoding: chunked is used. All communication is encrypted, and the identity of both sides is verified by checking for appropriate signatures on the certificates. == Scope == * Proposal owners: The code in systemd for systemd-journal-remote and systemd-journal-upload will have to be added. The first is done, and has already been released in the latest Rawhide systemd package. The second is mostly done, and will be submitted upstream soon. Necessary units will have to be created, and a location with suitable permissions will have to be created so that systemd- journal-remote can run unprivileged. This means that systemd-journal-remote should probably be packaged as a separate subpackage, similarly to systemd- journal-gatewayd. systemd-journal-upload uses libcurl, and thus should be also packaged as a separate subpackage to avoid introducing a new dependency for systemd. Suitable defaults for timeouts for transfers and maximum accepted entry sizes have to be chosen. A port will have to be picked: systemd-journal-gatewayd uses 19531, so systemd-journal-remote should probably use 19532. Two new users will have to be created when the packages are installed. * 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] http://www.freedesktop.org/wiki/Software/systemd/export/ [2] https://wiki.gnome.org/Apps/Logs ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
F21 Self Contained Change: SDDM as the default KDE display manager instead of KDM
= Proposed Self Contained Change: SDDM as the default KDE display manager instead of KDM = https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM Change owner(s): Martin Briza mbr...@redhat.com KDE SIG Retire KDM as the default display manager of the KDE Fedora Spin in favor of SDDM. == Detailed Description == As described in many articles and discussions, KDM is nearing its end of life and it's time we decided upon the successor. I'm proposing to switch to SDDM, which is a new project that suits our needs perfectly despite its immaturity: As of July 2013, KDM's maintenance consists of bugfixes for the most painful bugs, consisting of only about 20 actual commits to the repository in last two years (excluding translation, themes and merges), adding many new features would require major changes to a lot of the code and there is no active maintainer. SDDM is written in C++11/Qt5 (compared to the bits of XDM in KDM), compilable against Qt4, supports QtQuick theming and its upstream is quite active. Compared to the current DM, KDM, it currently lacks a few features (such as XDMCP) but adds some other ones (QtQuick themes) or is currently adding them (Keyboard layout switching in the greeter). == Scope == * Proposal owners: ** Create sddm and sddm-kcm packages. ** Change kde-settings and the spin-kickstarts to provide SDDM package instead of KDM ** (eventually) exclude KDM from the kde-workspace package * 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) ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
F21 System Wide Change: Ruby193 in SCL
= Proposed System Wide Change: Ruby193 in SCL = https://fedoraproject.org/wiki/Changes/Ruby193_in_SCL Change owner(s): Marcela Mašláňová mmasl...@redhat.com Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. Let's provide Ruby and Rails in SCL even for Fedora. Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of the SCL. == Detailed Description == Ruby 1.9.3 with Rails 3.2.8 is still commonly used by many projects. This change aims to provide Ruby 1.9.3 and Rails 3.2.8. Rails depends on exact v8 version, which means v8 3.14 must have also their own SCL as part of this change. == Scope == * Proposal owners: Marcela ** create the actual collections, at start in Copr and on SCL upstream [1] * Other developers: Cloud WG ** test SCL with their apps * Release engineering: ** create branches in dist-git ** add Ruby193 packages into compose [1] https://www.softwarecollections.org/en/ ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
