devel-announce September 2014

devel-announce@lists.fedoraproject.org

7 participants
13 discussions

Planned Outage: Buildsystem/Pkgs reboots - 2014-10-01 21:00 UTC
by Kevin Fenzi 29 Sep '14

29 Sep '14

Planned Outage: Buildsystem/Pkgs reboots - 2014-10-01 21:00 UTC There will be an outage starting at 2014-10-01 21:00 UTC, which will last approximately 4 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2014-10-01 21:00 UTC' Reason for outage: We will be updating and rebooting the development side of Fedora Infrastructure, including build system (koji), pkgs server, builders, databases and associated machines to bring everything up to date on errata. Additionally, time permitting we may migrate the main koji database server to rhel7. Note that maintainers are advised to not start builds before the outage window that will not finish before the outage starts. Affected Services: Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Darkserver - https://darkserver.fedoraproject.org/ Unaffected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Calendar - https://apps.fedoraproject.org/calendar/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4547 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.

1 0

Announcing the release of Fedora 21 Alpha!
by Dennis Gilmore 23 Sep '14

23 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Fedora 21 Alpha release has arrived, with a preview of the latest free and open source technology under development. Take a peek inside! http://fedoraproject.org/get-prerelease *** What is the Alpha release? *** The Alpha release contains all the exciting features of Fedora 21's products in a form that anyone can help test. This testing, guided by the Fedora QA team, helps us target and identify bugs. When these bugs are fixed, we make a Beta release available. A Beta release is code-complete and bears a very strong resemblance to the third and final release. The final release of Fedora 21 is expected in December. We need your help to make Fedora 21 the best release yet, so please take some time to download and try out the Alpha and make sure the things that are important to you are working. If you find a bug, please report it – every bug you uncover is a chance to improve the experience for millions of Fedora users worldwide. Together, we can make Fedora a rock-solid distribution. We have a culture of coordinating new features and pushing fixes upstream as much as feasible and your feedback will help improve not only Fedora but Linux and free software on the whole. At the end of this announcement you can find more information on how to help. *** Changes *** Fedora prides itself on bringing cutting-edge technologies to users of open source software around the world, and this release continues that tradition. No matter what you do, Fedora 21 has the tools you need to help you get things done. To see how Fedora 21 is evolving from Fedora 20, see the accepted changes here: http://fedoraproject.org/wiki/Releases/21/ChangeSet == Fedora.Next and Fedora 21 Products == As part of the Fedora.next initiative, Fedora 21 will boast three products: cloud, server, and workstation. Note that for the Alpha release, the network installers act as generic, 'universal' installers, offering the entire set of Fedora package groups by default, rather than only the groups associated with the Product they are meant to represent. === Fedora 21 Base === Each of the products will build on the "base" set of packages for Fedora. For instance, each product will use the same packages for the kernel, RPM, yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora products, which includes the installer, compose tools, and basic platform for the other products. Base is not a full product intended for use on its own, but to be kept as a small, stable platform for other products to build on. === Fedora 21 Cloud === The Fedora Cloud Working Group and Special Interest Group (SIG) has been busy leading up to Fedora 21. Cloud is now a top-level product for Fedora 21, and will include images for use in private cloud environments like OpenStack, as well as AMIs for use on Amazon, and a new image streamlined for running Docker containers. ==== Modular Kernel Packaging for Cloud ==== Space is precious, and there's little reason to include any kernel modules that aren't used in the cloud. As part of the work for Fedora 21, the cloud SIG and kernel team split the kernel into two packages. One package contains the minimum modules for running in a virtualized environment, the other contains the larger set of modules for a more general installation. ==== Fedora Atomic Host ==== In early April, Red Hat announced Project Atomic, an effort to provide the tools and patterns for a streamlined operating system to run Docker containers. The Fedora 21 release will be the first to offer an "Atomic" host for Fedora, which includes a minimal set of packages and an image composed with rpm-ostree. While using the same RPMs as other Fedora offerings, the Atomic host will allow users to roll back updates (if necessary) as one atomic unit -- making update management much easier. For users and organizations looking to run Docker containers, the Atomic host will be ideal. === Fedora 21 Server === The Fedora Server product is a common base platform that is meant to run featured application stacks, which are produced, tested, and distributed by the Server Working Group. Want to use Fedora as a Web server, file server, database server, or platform for an Infrastructure-as-a-Service? Fedora 21 Server is for you. ==== Fedora Server Management Features ==== The Fedora Server product introduces new Server management features aimed at making it easier to install discrete infrastructure services. The Fedora Server will introduce three new technologies in Fedora to handle this task, rolekit, Cockpit and OpenLMI. * Rolekit is a Role deployment and management toolkit that provides a consistent interface to administrators to install and configure all the packages needed to implement a specific server role. Rolekit is at an early stage of development in Fedora 21 Alpha. * Cockpit is a user interface for configuring and monitoring your server or servers. It is accessible remotely via a web browser. * OpenLMI is a remote management system built atop DMTF-CIM. It can be used for scripting management functions across many machines as well as querying for capabilities and monitoring for system events. ==== Domain Controller Server Role ==== As part of the server role offerings available for Fedora 21, the server product ships with a role deployment mechanism. One of the roles offered in 21 is the Domain Controller Service. * The Domain Controller Service packages up the freeIPA integrated Identity and Authentication solution for Linux/UNIX networked environments. A FreeIPA server provides centralized authentication, authorization and account information by storing data about user, groups, hosts and other objects necessary to manage the security aspects of a network of computers. As with Rolekit itself, this role is at an early stage of development in Fedora 21 Alpha. === Fedora 21 Workstation === The Fedora Workstation product is a reliable, user-friendly, and powerful operating system for laptops and PC hardware. Fedora 21 Workstation is aimed at providing a platform for development of server side and client applications that is attractive to developers of all stripes. Whether you're a student or hobbyist, or a developer working in a corporate environment, Fedora Workstation is for you. ==== Latest GNOME ==== Fedora 21 Workstation includes the latest GNOME desktop. Fedora 21 is tracking GNOME 3.14, which is due to be released in late September. GNOME 3.14 includes many new features such as integration of Picasaweb and DNLA media server support in GNOME Photos, a new game called Hitori similar to Sudoku, and much more. ==== DevAssistant ==== Fedora 21 Worsktation includes the new DevAssistant tool by default. DevAssistant helps developers set up environments for their projects, so they can concentrate on writing code. For more information on DevAssistant, visit the website at http://devassistant.org. == Issues and Details == This is an Alpha release. As such, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the test mailing list or in #fedora-qa on freenode. As testing progresses, common issues are tracked on the Fedora wiki: https://fedoraproject.org/wiki/Common_F20_bugs For tips on reporting a bug effectively, read "How to File a Bug Report:" http://fedoraproject.org/wiki/How_to_file_a_bug_report . You can join the Fedora QA team mailing list here: https://lists.fedoraproject.org/mailman/listinfo/test == Release Schedule == The full release schedule is available on the Fedora wiki. The current schedule calls for a beta release in the end of October, and a final release in early December. These dates are subject to change, pending any major bugs or issues found during the development process. == Contributing == There are many ways to contribute beyond bug reporting. You can help translate software and content, test and give feedback on software updates, write and edit documentation, design and do artwork, help with all sorts of promotional activities, and package free software for use by millions of Fedora users worldwide. To get started, visit: http://join.fedoraproject.org today! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIbBAEBAgAGBQJUIX0xAAoJEH7ltONmPFDRWBQP9AnCsHkp1l+Z77yD+XqpxfLo /2m2U9N3YzwA4s1me85p60LBSI9ELgXYVMqWKTOSXlNwS0ZXs0b0L1YDJRAaz4bB nNBclaiwu8AEOS1frPiTdlxhWVCDOnsMooLcQCIEXu8R6ykvR3orWiRnqRInkyGj rw26Ia7ISI4YAYWW0C630hKMAf/BgfB3EwOQDtlOLoJvtnbOYNpPVlzGfX9cpRVk pjGVjQrVss79aguvUG5oUaXTqtTuLu7xi6Pzt9YwXhH3vwuFQwkvBF/0RvJ+dmwn GSyLJ1NjRjDEOki/mcCuu1M7Art3CgEIlCVazD8vlQ/lhVAPS+WtGaC8ol7BKpYe s6N7OPVVNEm0ln4OKi9JECIvCGigSBifoY5PVOWqK4+bc0kqEDZ8puBRJeC3Iifo YK4hRER7Nn8XbU7JfK2L8FFCOpmeodG3MQA9pOZfKuE9PVOU5HzVn7XYRFaVQOok 4UqlZ/Mt4K64N156cQBVQFekQ5XnFhLjniR02cD2Oak69GDlSFovpv1pSXlpjVSC yXtanbt0z7bO/f3Kj+aAikQJrjYVVuPdbKd2OjMiDf6oD0c+5ZQiRBn8efa+/8lC AX8jfcTYdnofwL19Hs7CP3Gu+6elrqW69Bx2YdKWi7maW2AHsM0FxFZQnxmL4J4i P1wJrfmSwLPm1QwwiJ4= =bVd0 -----END PGP SIGNATURE-----

2 1

Open Seats on the Fedora Packaging Committee
by Dominik 'Rathann' Mierzejewski 22 Sep '14

22 Sep '14

The Fedora Packaging Committee has two open seats and is accepting submissions from interested candidates to serve on the FPC. This position involves not only reviewing Packaging Guideline drafts submitted to the FPC for consideration, but also rewriting drafts (sometimes from scratch) to resolve the issue in a more acceptable fashion. Additionally, the FPC reviews bundling exceptions (and UID/GID soft static assignment). The FPC meets on IRC weekly, Wednesdays at 1600 UTC, for approximately an hour. FPC members serve for as long as they are willing, there are currently no term limits. All decisions are voted on using a +1 (for), 0 (abstain), and -1 (against) mechanism, and all decisions must be approved by a majority (+5). FPC Meetings do not happen if quorum (5) is not present. Candidates who are interested should provide the following details to the FPC for consideration, by emailing it directly to me (dominik(a)greysector.net) The FPC will consider all candidates, but strongly prefers candidates who have extensive experience packaging in Fedora. We will accept applications for the next week (deadline Wednesday Oct 1, 2014). Name: FAS Account: Provenpackager? (Yes/No): Main area of packaging interest/expertise: Reason(s) for willing to join the FPC: Thanks in advance, Dominik -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"

1 0

Fedora 21 Alpha status is Go, release on September 23, 2014
by Jaroslav Reznik 18 Sep '14

18 Sep '14

At the Fedora 21 Alpha Go/No-Go Meeting #3 that just occurred, it was agreed to Go with the Fedora 21 Alpha by Fedora QA, Release Engineering and Development. Fedora 21 Alpha will be publicly available on Tuesday, September 23, 2014. "That's one small step for mankind but one giant leap for Fedora" - the first release on the way towards Fedora.Next! Meeting details can be seen here: Minutes: http://bit.ly/1pkIobe Log: http://bit.ly/XpyZIO Thanks everyone! Jaroslav

1 0

Fedora 21 Alpha Go/No-Go Meeting #3, Sep 18 @ 17:00 UTC
by Jaroslav Reznik 17 Sep '14

17 Sep '14

Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 21 Alpha. Thursday, September 18, 2014 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." Release Candidate (RC) availability and good QA coverage are prerequisites for the Go/No-Go meeting. This is the first time for F21 Alpha Go/No-Go we have RC available (RC1). If you want to help with RC testing, follow these instructions: https://lists.fedoraproject.org/pipermail/kde/2014-September/013881.html For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 21 Alpha Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist Jaroslav

1 0

F22 Self Contained Change: BIND version 9.10
by Jaroslav Reznik 16 Sep '14

16 Sep '14

= Proposed Self Contained Change: BIND version 9.10 = https://fedoraproject.org/wiki/Changes/BIND_9.10 Change owner(s): Tomas Hozza <thozza(a)redhat.com> BIND (Berkeley Internet Name Domain) version 9.10 is the latest stable major update of the widely used DNS server. Besides new features, some settings defaults have changed since the previous major version (9.9). == Detailed Description == FULL BIND 9.10 RELEASE NOTES [1] === New features === * New zone file format, "map", stores zone data in a format that can be mapped directly into memory, allowing significantly faster zone loading. * New tool "delv" (domain entity lookup and validation) with dig-like semantics for looking up DNS data and performing internal DNSSEC validation has been added. * New "prefetch" option improving the recursive resolver performance has been added. * Improved EDNS processing allowing better resolver performance. * Substantial improvements have been made in response-policy zone (RPZ) performance. * ACLs can now be specified based on geographic location using the MaxMind GeoIP databases. * The statistics channel can now provide data in JSON format as well as XML. * The new "in-view" zone option allows zone data to be shared between views, so that multiple views can serve the same zones authoritatively without storing multiple copies in memory. * Native PKCS#11 API has been added. This allows BIND 9 cryptography functions to use the PKCS#11 API natively, so that BIND can drive a cryptographic hardware service module (HSM) directly instead of using a modified OpenSSL as an intermediary (Native PKCS#11 is known to work with the Thales nShield HSM and with SoftHSM version 2 from the Open DNSSEC project.). * New tool "named-rrchecker" can be used to check the syntax of individual resource records, and optionally to convert them to the format used for unknown record types. * New tool "dnssec-importkey" allows "offline" DNSSEC keys (i.e., keys whose private data is not stored on the system on which named is running) to be published or deleted on schedule using automatic DNSKEY management. * Network interfaces are re-scanned automatically whenever they change. Use "automatic-interface-scan no;" to disable this feature. ** Added "rndc scan" to trigger an interface scan manually. * New "max-zone-ttl" option enforces maximum TTLs for zones. If loading a zone containing a higher TTL, the load fails. DDNS updates with higher TTLs are accepted but the TTL is truncated. * Multiple DLZ databases can now be configured, and are searched in order to find one that can answer an incoming query. * "named-checkzone" and "named-compilezone" can now read journal files. === Feature changes === * The version 3 XML schema for the statistics channel, including new statistics and a flattened XML tree for faster parsing, is no longer optional. The version 2 XML schema is now deprecated. * "named" now listens on IPv6 as well as IPv4 interfaces by default. * The internal and export versions of the BIND libraries (libisc, libdns, etc) have been unified so that external library clients can use the same libraries as BIND itself. * The default setting for the -U option (setting the number of UDP listeners per interface) has been adjusted to improve performance. * Adaptive mutex locks are now used on systems which support them. * "rndc flushtree" now flushes matching records from the address database and bad cache as well as the DNS cache. (Previously only the DNS cache was flushed.) * The isc_bitstring API is no longer used and has been removed from the libisc library. * The timestamps included in RRSIG records can now be read as integers indicating the number of seconds since the UNIX epoch, in addition to being read as formatted dates in YYYYMMDDHHMMSS format. == Scope == * Proposal owners: Rebase the package to the latest 9.10 minor version and resolve possible packaging issues. (Also rebuild all currently existing dependent packages listed below) * Other developers: Rebuild dependent packages (dhcp, dnsperf, bind-dyndb- ldap) ** Owner of this feature is co-maintainer of all dependent packages. He will do the necessary rebuilds himself in cooperation with dependent packages owners. * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) [1] http://ftp.isc.org/isc/bind9/9.10.0-P2/RELEASE-NOTES-BIND-9.10.0-P2.txt

1 0

Fedora 21 Alpha to slip by one week
by Jaroslav Reznik 11 Sep '14

11 Sep '14

Today at Go/No-Go meeting it was decided to slip Fedora 21 Alpha release by one week due to unresolved blocker bugs [1] and no release candidate available. More details in meeting minutes [2]. Quoting Adam, we are moderately optimistic we could possibly actually be done next week if the netinst stuff works out. As a result, ALL MAJOR MILESTONES, and their dependent tasks, will be pushed out by one week [3]. The next Go/No-Go meeting is on Thursday, Sep 18, the same time at #fedora-meeting-2 channel. [1] http://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist [2] http://bit.ly/1su0JIx [3] https://fedoraproject.org/wiki/Releases/21/Schedule

1 0

Reminder: Fedora 21 Alpha Go/No-Go Meeting #2, today @ 17:00 UTC
by Jaroslav Reznik 11 Sep '14

11 Sep '14

Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 21 Alpha. Thursday, September 11, 2014 17:00 UTC (1 PM EDT, 10 AM PDT, 19:00 CEST) "Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting." "Verifying that the Release criteria are met is the responsibility of the QA Team." Release Candidate (RC) availability and good QA coverage are prerequisites for the Go/No-Go meeting. As we do not have RC yet, this meeting will be aiming on coordination of missing pieces for Alpha. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 21 Alpha Blocker list: http://qa.fedoraproject.org/blockerbugs/milestone/21/alpha/buglist Jaroslav

1 0

FMN Announcement: Plans for a (near) future
by Ralph Bean 08 Sep '14

08 Sep '14

Dear all, We would like to invite you to take a closer look at the Fedora Notification service: https://apps.fedoraproject.org/notifications/ This service will allow you to customize the notifications you receive, you may ask it to send you IRC notification for successfull koji builds and email notifications for failed koji builds. You may ask it to send you pkgdb notifications only via IRC and even to wait a little after receiving the first pkgdb notification before sending it to you (thus allowing it to batch your notifications into a digest). We have already mentioned this service in an email on the devel list few months ago[1] and we now are getting to that point that we want to turn off email notifications from pkgdb. Bodhi2 which is planned in the coming months will also not have email notifications. All information will be going through fedmsg and you will be able to receive them (or not) via FMN. This is thus a head-up about what will happen in a very near future. As a packager, it is important that you are notified about a number of actions happening on the packages you maintain. We looked at who is currently using FMN vs who is in the packager group: 1566 packagers 160 users in FMN 1453 packagers do not have a FMN account Here's what we're going to be doing (soon): - All the packagers that do not have a FMN account (ie: never logged in) will have an account created automatically with the default rules that everyone has when they log in for the first time (these rules should provide the same level of notification as one currently has with the different systems). - We have code in place that will automatically create a FMN account for users added to the packager group that do not already have an account there. So please, have a look at it or if you are a packager, we will create you an account automatically in the next few weeks. Finally, if you have any comments or questions, feel free to open a ticket at: https://github.com/fedora-infra/fmn/ Thanks for your attention, - Ralph on behalf of the Fedora Infrastructure team [1] https://lists.fedoraproject.org/pipermail/devel/2014-July/201118.html

1 0

Future changes in the new package and new branch processes
by Pierre-Yves Chibon 05 Sep '14

05 Sep '14

Dear all, In the last months, Till and I together with infrastructure and release-engineering have been thinking and working on how we could improve the current workflow for new package and new branch. To give you an idea, this is the current workflow: Current new-package procedure: ============================== * packager opens a review-request on bugzilla * reviewer sets the fedora-review flag to ? * reviewer does the review * reviewer sets the fedora-review flag to + * packager creates the scm-request and set fedora-cvs flag to ? * cvsadmin checks the review (check reviewer is a packager, check if reviewee required a sponsor or not, check if there was a review) * cvsadmin processes the scm-request: - Create git repo - Create package in pkgdb * cvsadmin sets fedora-cvs flag to + We thought that a number of these steps could be automated. For example, creating the git repos themselve could be automated using information from pkgdb. Our idea has been to port part of this procedure to pkgdb itself. This is our proposal: New procedure ============= * packager opens a review-request on bugzilla * reviewer sets the fedora-review flag to ? * reviewer does the review * reviewer sets the fedora-review flag to + * packager goes to pkgdb2 to request new package and specifies: - package name - package summary - package branches - link to review on bugzilla => requests added to the scm admin queue * cvsadmin checks the review (check reviewer is a packager¹) * cvsadmin approves the creation of the package in pkgdb => package creation broadcasted on fedmsg * git adjusted automatically What are the main changes: - More work for the packager that asks for the package to be created directly in pkgdb instead of using the SCM request mechanism in bugzilla - No more use of the fedora-cvs flag in bugzilla - Simplied work for releng that just checks the review and approves/denies in pkgdb Similarly, for new-branch: Current new-branch procedure: ============================= * packager find the original package review ticket / opens a new ticket * packager make the change request and sets fedora-cvs flag to ? * cvsadmin checks the request/package (check if user is a packager, check if package exists in the RHEL for EPEL branch request) * cvsadmin processes the scm-request: - Adjust git repo - Adjust package in pkgdb * cvsadmin sets fedora-cvs flag to + New new-branch procedure: ========================= * packager requests new branch in pkgdb (2 clicks) => requests added to the scm admin queue * cvsadmin checks the request/package (check if package exists in the RHEL for EPEL branch request - check if the user is a packager done in pkgdb itself) * cvsadmin approves the creation of the new branch in pkgdb => branch creation broadcasted on fedmsg * git adjusted automatically Currently, we are working towards these workflows but of course they are not set in stone and we would like to discuss them as early as possible to be sure we're not going in a completely wrong direction. Thanks for your feedbacks, Pierre and Till ¹ We should be able to automate the check if the reviewee/reviewer are packagers or not.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce September 2014