devel-announce November 2015

devel-announce@lists.fedoraproject.org

6 participants
17 discussions

F24 System Wide Change: Systemd file triggers
by Jan Kurik 18 Nov '15

18 Nov '15

= Proposed System Wide Change: Systemd file triggers = https://fedoraproject.org/wiki/Changes/systemd_file_triggers Change owner(s): Zbigniew Jędrzejewski-Szmek <zbyszek AT in DOT waw DOT pl> systemd daemon-reload is invoked once or twice per rpm transaction. == Detailed Description == Instead of having every package which carries a systemd unit call systemctl daemon-reload on its own, systemd is reloaded just once after installation of all packages, using rpm file triggers on /usr/lib/systemd/system, /etc/systemd/system. Packages still have to call systemctl preset as necessary, and try-restart on their own unit if appropriate. RPM macros provided by systemd are modified to remove all calls to daemon-reload from them. No changes to packages using those macros are required, but a rebuild is necessary to remove the calls to systemctl daemon-reload. == Scope == Proposal owners: * Update the macros provided by systemd and add appropriate file triggers. Other developers: potentially rebuild some packages. Release engineering: N/A List of deliverables: N/A Policies and guidelines: N/A Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

F24 System Wide Change: GHC 7.10
by Jan Kurik 18 Nov '15

18 Nov '15

= Proposed System Wide Change: GHC 7.10 = https://fedoraproject.org/wiki/Changes/GHC_7.10 Change owner(s): Jens Petersen <petersen AT redhat DOT com > Update Fedora's version of the GHC Haskell compiler to version 7.10. == Detailed Description == GHC 7.10 is major new version of the de facto standard Haskell compiler released in 2015. This change involves updating ghc and associated packages and updating and rebuilding all the Haskell packages in Fedora built with ghc. == Scope == Proposal owners: * Create a Koji f24-ghc side tag for building all the packages, including also secondary architectures * Update ghc and ghc-rpm-macros * Update and rebuild all the Haskell packages in the side tag * Once building is complete move all the side tag builds to Rawhide (before F24 branches) Other developers: None * A few packages outside the Haskell SIG may need an update to build with ghc-7.10, but the Haskell SIG can provide assistance if needed. Release engineering: * Sidetag and secondary architecture building will need assistance from release-engineering. List of deliverables: * N/A (not a System Wide Change) Policies and guidelines: * None Trademark approval: * N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

Elections November/December 2015 - Nomination period is now open
by Jan Kurik 16 Nov '15

16 Nov '15

Hello everyone! The nomination period for the Elections November/December 2015 is now open. We will be electing seats to the following teams: * FESCo (Engineering) (5 seats) [1] * Fedora Council (1 seat) [2] * Env and Stacks (4 seats) [3] * FAmSCo (7 seats) [4] If you are interested in these roles, please add yourself to the lists of nominees (check the links [1], [2], [3], [4]) before 23:59:59 UTC on November 23rd, 2015! If you wish to nominate someone else, please consult with that person ahead of time. If you know someone who would be a good candidate, now is a great time to make sure they're thinking about it. If you have questions you'd like to ask candidates, please add them to the Elections Questionnaire wiki page [5]. Nominees will hopefully answer these questions and publish these answers during campaign period on Community blog. Elections schedule: * Nomination period: Tue 2015-11-17 ... Mon 2015-11-23 * Campaign period: Tue 2015-11-24 ... Mon 2015-11-30 * Voting period: Tue 2015-12-01 ... Mon 2015-12-07 * Result Announcement: Tue 2015-12-08 For more information please visit the Election wiki page [6]. You might also be interested in the blog post I published on the Community blog [7]. [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations [2] https://fedoraproject.org/wiki/Council/Nominations [3] https://fedoraproject.org/wiki/Env_and_Stacks/Nominations [4] https://fedoraproject.org/wiki/FAmSCo_nominations [5] https://fedoraproject.org/wiki/Elections/Questionnaire [6] https://fedoraproject.org/wiki/Elections [7] https://communityblog.fedoraproject.org/fedora-elections-novemberdecember-2… -- Jan Kuřík

1 0

Reminder: Fedora 21 end of life on 2015-12-01
by Kevin Fenzi 10 Nov '15

10 Nov '15

Greetings. This is a reminder email about the end of life process for Fedora 21. Fedora 21 will reach end of life on 2015-12-01, and no further updates will be pushed out after that time. Additionally, with the recent release of Fedora 23, no new packages will be added to the Fedora 21 collection. Please see https://fedoraproject.org/wiki/DNF_system_upgrade for more information on upgrading from Fedora 21 to a newer release. kevin

1 0

Migration of the mailing-lists to Mailman3 and HyperKitty
by Aurelien Bompard 10 Nov '15

10 Nov '15

Dear list users, The Fedora Engineering team has been working on a new system for our mailing lists. Mailman 3 came out earlier this year and it has a new shiny web UI: HyperKitty. The Fedora Hosted lists will be migrated on November 16th, and the Fedora project lists later in the week. After migration you should be able to use the new hyperkitty UI to post and read the lists if you choose or continue to get emails in the traditional way. There may be some changes in some headers, so if you filter your list emails be ready to adjust your filters. See wiki page below for details: http://fedoraproject.org/wiki/Mailman3_Migration Some lists using mailman2 features not yet available in mailman3 will be migrated later. More information as well as current lists migrated, being migrated and deferred for migration can be found at: http://fedoraproject.org/wiki/Mailman3_Migration/Status If you have any questions, feel free to ask on the infrastructure list: infrastructure(a)lists.fedoraproject.org. If you find a problem or issue, please file a fedora infrastructure ticket and we will work to fix things for your case or bug: https://fedorahosted.org/fedora-infrastructure/ The Fedora Infrastructure team

1 0

[Guidelines change] Changes to the packaging guidelines
by Jason L Tibbitts III 09 Nov '15

09 Nov '15

Here are the recent changes to the packaging guidelines. ----- The guidelines were updated to reflect the current policy that Fedora packages are no longer permitted to carry SysV-style initscripts. The relevant guidelines page has been moved to the EPEL hierarchy. * https://fedoraproject.org/wiki/Packaging:Guidelines#Initscripts * https://fedoraproject.org/wiki/EPEL:SysVInitScript * https://fedorahosted.org/fpc/ticket/577 ----- Until sufficient support exists in the build system and package manager, rich/Boolean dependencies are not permitted in Fedora. * https://fedoraproject.org/wiki/Packaging:Guidelines#Rich.2FBoolean_dependen… * https://fedorahosted.org/fpc/ticket/559 ----- The MPI packaging guidelines were updated to handle python3 packages. * https://fedoraproject.org/wiki/Packaging:MPI * https://fedoraproject.org/w/index.php?title=Packaging%3AMPI&diff=427683&old… * https://fedorahosted.org/fpc/ticket/563

1 0

F24 Self Contained Change: Product Definition Center
by Jan Kurik 03 Nov '15

03 Nov '15

= Proposed Self Contained Change: Product Definition Center = https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter Change owner(s): Ralph Bean <rbean at redhat dot com> The Product Definition Center (PDC) is a webapp and API designed for storing and querying product metadata. We want to stand up an instance in Fedora Infrastructure and automatically populate it with data from our existing releng tools/processes. It will enable us to develop more sane tooling down the road for future releases. == Detailed Description == We need something more sophisticated than we have now to model releng processes. Right now, we have a collection of shell scripts, python bits, and koji tasks that all know "how to do" whatever it is that needs to be done. Whatever artifacts they produce, is what we produce. When we introduced new types of artifacts (server/cloud/workstation, vagrant, docker, atomic, etc..) as requirements for releng in the past few years, we started to strain the existing processes. Those scripts became much more complicated and difficult to debug. Long term, we would like to move to a more structured architecture for releng workflow, one that uses basic software engineering paradigms, like MVC. To start on that journey, we're looking to deploy something which can serve just as the M there (the Model). With such a thing, we could rewrite some of our scripts to behave dynamically in response to state of the model. In the best case scenario (read: utopia), we would simply define a new variant of a deliverable in the model, and our tools would produce it. (Of course, things will involve more work than that). == Scope == Note that this change should not affect any other development efforts. It does not require new instrumentation of any of our existing tools and so, should it fail as a project, there is no need for a contingency plan to back things out -- we can just abandon it. * Proposal owners: - Set up a devel instance of PDC (already done here). - Write pdc-updater, the daemon that updates PDC with data from our existing toolchain (via fedmsg). - Write an audit script that checks that PDC's data is consistent. - Set up and deploy staging and production instances of PDC and pdc-updater in fedora-infra. - Run the audit scripts to ensure that PDC's knowledge is consistent with the actual state of our release infra. - Install the audit script in cron (or something) and attach it to a nagios alert, so we're made aware of inconsistencies. * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * List of deliverables: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) -- Jan Kuřík Platform & Fedora Program Manager Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce November 2015