devel April 2014

devel@lists.fedoraproject.org

237 participants
237 discussions

F21 System Wide Change: Fedora 21 Make 4.0 Update
by Jaroslav Reznik 12 Jun '14

12 Jun '14

= Proposed System Wide Change: Fedora 21 Make 4.0 Update = https://fedoraproject.org/wiki/Changes/F21Make40 Change owner(s): Patsy Franklin <pfrankli(a)redhat.com> This change brings Make 4.0 to Fedora 21. == Detailed Description == The purpose of this update is to synchronize Fedora with the most recent Make release. Several new features, new command line options, new variables, and bug fixes have been implemented in Make 4.0. Improved error reporting may result in log file differences. If a recipe fails, the makefile name and linenumber of the recipe are shown. There is one backwards-incompatibility regarding the use of .POSIX. Make 4.0 will adhere to POSIX requirements for backshlash/newline handling. See the link included under Documentation for more details. A new subpackage make-devel will be created containing gnumake.h,a new file containing externally-visible content. == Scope == * Proposal owners: ** Rebase to make-4.0 ** 6 patches need to be updated to work with new sources ** 14 patches will be removed as they are already supported by the make-4.0 rebase ** make.spec will be updated ** local build and test (already completed for glibc and gcc) ** patch created and submitted ** build * Other developers: There are some minor error message changes that may show up as log file differences. If a package's makefile requires a specific version of make, the makefiles may need editing to include make 4.0. * Release engineering: There will be a new subpackage make-devel. * Policies and guidelines: N/A _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

6 6

F21 Self Contained Change: Remote Journal Logging
by Jaroslav Reznik 10 Jun '14

10 Jun '14

= Proposed Self Contained Change: Remote Journal Logging = https://fedoraproject.org/wiki/Changes/Remote_Journal_Logging Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek(a)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(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

17 55

Maybe it's time to get rid of tcpwrappers/tcpd?
by Lennart Poettering 06 Jun '14

06 Jun '14

Heya! I wonder whether it wouldn't be time to say goodbye to tcpwrappers in Fedora. There has been a request in systemd upstream to disable support for it by default, but I am not sure I want to do that unless we can maybe say goodbye to it for the big picture too. Why would we get rid of them? Well, to make things simpler, primarily. They have not seen any development since 2003 (that's 11 years I mind you, an eternity in IT). I doubt there are many people even using them anymore, firewalls are more comprehensive and a lot more powerful, and while every admin knows firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever actively make use of them... The API is awful, too, with lot's of open-coded structures, feature checks in the headers, fixed length strings, globally exported variables, non-namespaced symbols, really weird exported compatibility wrappers for OS calls... I'd propose we make a clear cut, and just start disabling it in all services that link to it, instead of letting rot on in Fedora for all eternity. It's bad code, little used, crufty. We have much better stuff now, and that enables us to say goodbye to the old mess... I figure there will be a bit of opposition to this change, thus I thought I start the discussion on the fedora ML first. Unless there are major concerns I will propose a feature about this in the next few days. If somebody wants to join me on this and put his name on the feature proposal I'd be delighted! Lennart -- Lennart Poettering, Red Hat

46 139

Re: F21 System Wide Change: Workstation: Enable Software Collections
by Kevin Kofler 05 Jun '14

05 Jun '14

Jaroslav Reznik wrote, on behalf of Matthias Clasen: > The Software Collections repositories will be enabled by default. So we now allow shipping the configuration for third-party repositories, even enabled by default? Is April 1st still not over yet? If you want those packages in Fedora, they need to get into the Fedora repository. Kevin Kofler

4 4

Mass bug: packages should not auto-enable systemd units
by Andrew Lutomirski 04 Jun '14

04 Jun '14

Hi everyone- This is a notice in accordance with the mass bug filing procedure. A number of packages install systemd units and enable them automatically. They should not. Please update these packages to use the macroized scriptlet (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd). If your package has an exception from FESCo permitting it to enable itself, please make sure that the service in question is listed in the appropriate preset file. There is a general exception described here: https://fedoraproject.org/wiki/Starting_services_by_default If your package falls under the general exception, then it is possible that no change is required. Nevertheless, if you are relying on the exception, please make sure that your rpm scripts are sensible. The exception is: In addition, any service which does not remain persistent on the system (aka, it "runs once then goes away"), does not listen to incoming connections during initialization, and does not require configuration to be functional may be enabled by default (but is not required to do so). An example of "runs once then goes away" service is iptables. Given that this issue can affect Fedora 20 users who install your package as a dependency, these bugs should be fixed in Fedora 20 and Rawhide. The tracker bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1090684 I created it early because three of the bugs are pre-existing. Next week, I'll file bugs against the packages below. If you fix your package in the mean time, please let me know. After three weeks, provenpackagers may step in and fix these issues. OpenIPMI at avahi avahi-dnsconfd bcfg2 bcfg2-server bwbar cronie deltacloud-core device-mapper-multipath dmapd fsniper gpm groonga hsqldb iscsi-initiator-utils jabberd libvirt libvirt-client lvm2 mailman mdadm monit openct opendkim openssh-server partimage rhnsd rinetd sendmail vdsm xrdp yum-updatesd It's possible that I'm missing some packages. I may follow up with an updated list. _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

7 10

F21 Self Contained Change: Docker Container Image
by Jaroslav Reznik 03 Jun '14

03 Jun '14

= Proposed Self Contained Change: Docker Container Image = https://fedoraproject.org/wiki/Changes/Docker_Container_Image Change owner(s): Lokesh Mandvekar <lsm5(a)fedoraproject.org>, Dennis Gilmore <dennis(a)ausil.us> This is Fedora running inside Docker. Currently, there are non-official images in the docker index, but we'd like them to really come out of release engineering. == Detailed Description == The public docker registry [1] hosts many fedora images [2] including an unprefixed (semi-official) image [3]. However, this image doesn't have rel-eng approval which would be required for a fully official image. == Scope == * Proposal owners: The proposal owner needs to build the image tarballs with the official kickstart scripts and make them available to docker's stackbrew repo, which is used by the Docker maintainers to build unprefixed images. Release Engineering approval/intervention would be needed at some point (details still TBD) * Other developers: N/A (not a System Wide Change) * Release engineering: Official Release Engineering image approval. Process still TBD. * Policies and guidelines: N/A (not a System Wide Change) [1] http://index.docker.io/ [2] https://index.docker.io/search?q=fedora [3] https://index.docker.io/_/fedora/ _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

3 2

F21 System Wide Change: cron to systemd time units
by Jaroslav Reznik 28 May '14

28 May '14

= Proposed System Wide Change: cron to systemd time units = https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units Change owner(s): Jóhann B. Guðmundsson <johannbg AT gmail DOT com> Fix dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units. == Detailed description == Add dependency on crontab in packages containing cron jobs as well as migrate cron jobs that are applicable to native systemd timer units in packages that already depend on systemd. == Scope == * Policies and guidelines: ** Adjust packaging guidelines to fix dependency in cron packages [Package Cron Files 1] DONE ** Adjust packaging guidelines to mention migration of cron jobs to timer units for packages that already depend on systemd * Fix spec files in packages that are not applicable for migration [Fix Cron Dependency Tracking Bug 2] * Review and migrate if applicable cron jobs shipped in packages that already depend on systemd [Timer Migration Tracking Bug 3] * Update systemd wikipage to contain timer units example [1] https://fedoraproject.org/wiki/Packaging/CronFiles [2] https://bugzilla.redhat.com/show_bug.cgi?id=947037 [3] https://bugzilla.redhat.com/show_bug.cgi?id=991679 _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

7 12

Reinstalling the bootloader
by Andrew Lutomirski 28 May '14

28 May '14

Once upon a time (Fedora 15? -- I've lost track), it was possible to reinstall the bootloader using grub-install. Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is there a way to reinstall it without reinstalling the world? Would it make sense to split the whole bootloader thing out of Anaconda such that it would be possible to re-run it? I can access my install just fine using chroot. FWIW, the same question applies to upgrading the bootloader. Somehow I'm on Fedora 20 using grub 0.97. --Andy

8 31

gcc build with -O0 results in corrupted -debuginfo package
by Petr Spacek 28 May '14

28 May '14

Hello list, I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb". I did the simplest possible thing - edited the original spec file (see spec.diff) and built the package: $ rpmbuild -ba bind.spec The package builds and BIND itself seems to work. The problem is that new debuginfo package is missing 118 out of 283 header files in /usr/src/debug/bind-9.9.4-P2. It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem. I would be glad if anyone can give me advice how to debug this. Original packages from Fedora 20 (with all headers in /usr/src/debug): http://koji.fedoraproject.org/koji/buildinfo?buildID=502596 Packages built with -O0 -ggdb (scratch build): http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483 Thank you for your time! -- Petr^2 Spacek

6 12

F21 System Wide Change: BerkeleyDB 6
by Jaroslav Reznik 27 May '14

27 May '14

= Proposed System Wide Change: BerkeleyDB 6 = https://fedoraproject.org/wiki/Changes/BerkeleyDB_6 Change owner(s): Jan Staněk <jstanek(a)redhat.com> Add BerkeleyDB v. 6, which changed license from previous releases (GPLv2+ to AGPLv3+), to Fedora while keeping the older version for packages which cannot use BerkeleyDB with the new license. == Detailed Description == The BerkeleyDB, used between others by rpm [1], changed license between versions 5.* and 6.* to AGPLv3+ from GPLv2+. As those two licenses are not compatible, packages using the BerkeleyDB either has to change its license to AGPLv3+ compatible, keep on using the older BerkeleyDB or use another DB entirely. Target of this change is to create new set of packages from current libdb [2], which contains the v5 version, and keep it alongside the latest BerkeleyDB. == Scope == * Proposal owners: Create new set of packages and introduce proper versioning in order to not confuse the dynamic linker. * Other developers: Packages dependent on libdb would have to specify which version they want to use (specify version in the spec Requires: field). Rebuilds of dependent packages will be necessary. * Release engineering: None * Policies and guidelines: None [1] https://apps.fedoraproject.org/packages/rpm [2] https://apps.fedoraproject.org/packages/libdb _______________________________________________ devel-announce mailing list devel-announce(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce

10 19

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