devel-announce February 2015

devel-announce@lists.fedoraproject.org

9 participants
16 discussions

Fedora 22 Alpha Freeze
by Dennis Gilmore 24 Feb '15

24 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Today's an important day on the Fedora 22 schedule[1], with several significant cut-offs. First of all today is the Bodhi activation point [2]. That means that from now all Fedora 22 packages must be submitted to updates-testing and pass the relevant requirements[3] before they will be marked as 'stable' and moved to the fedora repository. Today is also the Alpha freeze[4]. This means that only packages which fix accepted blocker or freeze exception bugs[5][6] will be marked as 'stable' and included in the Alpha composes. Other builds will remain in updates-testing until the Alpha release is approved, at which point the Alpha freeze is lifted and packages can move to 'stable' as usual until the Beta freeze. Today is also the Software String freeze[7], which means that strings marked for translation in Fedora-translated projects should not now be changed for Fedora 22. Finally, today is the 'completion deadline' Change Checkpoint[8], meaning that Fedora 22 Changes must now be 'feature complete or close enough to completion that a majority of its functionality can be tested'. Regards Dennis [1] https://fedoraproject.org/wiki/Releases/22/Schedule [2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling [3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release [4] https://fedoraproject.org/wiki/Milestone_freezes [5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy [8] https://fedoraproject.org/wiki/Changes/Policy -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJU7MHvAAoJEH7ltONmPFDRcIgQAI0i4FRbZFWtd2+LdoSS7vhJ e+18nhiBEjh3G+75+FajwMLYL9ptXhMXcdvk78y55dfp2K5cfEDRr8WkCn6QnzT7 T4tynbPMdN7jmOpb9zNPhqoTLzejzkVsSFW50NVId8l4NSh77wcQTvU/ZKU9mN7O WfpI4xp4lKeZsvooNYplAeVwKsoypY3pc+LgIT+U7PGRM7l74LidMkNTNGLdWd2/ Lks0qwXQSYh/iQ5XQJ2hW2IF+JmWUOxLMXEE23TVQD2AlBvncAJB4ZB3L8p4S+FB GP/ulYZSRofEzAOKHoUHCfbrLdc8y5/taac1SzGAtd48j1sqMnIWTtLu3c0rTqGY Sry/zmB6cugiEDrryFoNf/F/QmOAKc9m6PJ7HvHAZUIj5l6N9THa7nwGSg0dFvNv BpxeFmpo4EFb/Xw17E1uNXIGTaGRrTCse1p7yR3L6FJLSxOMSNIdFN5+DnILHdaP twm0HW1HpjYczq+Y1lwdDJoG3JYolEukz195xqOwzViikDNmxBWikSJ4wpgILiuK pCsmXa/I+ePbYmYTZJc/MEwEtIGTZwgwWzRiNhmZlBY3F+NeNBUgCOSMuUpLF0QI T9hXu3I9vfF1TljJg4H8NoBaTftkuCD2C1C9jH7l34b+82+E7o6RaMMIJ1WEkPHd JlelrtX35qPpaBhDgDAD =02J1 -----END PGP SIGNATURE-----

1 0

Fedora 22 Bugzilla Rawhide rebase
by Jaroslav Reznik 24 Feb '15

24 Feb '15

Greetings, This e-mail is intended to inform you about the upcoming Bugzilla changes happening March 3, 2015 (Rawhide bug rebase) and what you need to do, if anything. We will be automatically changing the version for most rawhide bugs to Fedora 22. This will result in regular bugs reported against rawhide during the Fedora 22 development cycle being changed to version ‘22' instead of their current assignment, ‘rawhide’. This is to align with the branching of Fedora 22 from rawhide and to more accurately tell where in the lineage of releases the bug was last reported. Note that this procedure does not apply to bugs that are open for the ‘Package Review’ component or bugs that have the ''FutureFeature'' or ''Tracking'' keywords set. These will stay open as rawhide bugs indefinitely. If you do not want your bugs changed to version ‘22‘, add the ''FutureFeature'' keyword. If you need help changing a large amount of bugs manually, we’d be glad to help. The process was re-approved by FESCo https://fedorahosted.org/fesco/ticket/1096. Jaroslav

1 0

F22 Self Contained Change: LXQt
by Jaroslav Reznik 24 Feb '15

24 Feb '15

= Proposed Self Contained Change: LXQt = https://fedoraproject.org/wiki/Changes/LXQt Change owner(s): Helio Chissini de Castro <heliocastro(a)fedoraproject.org>, Christoph Wickert <cwickert(a)fedoraproject.org> Package the LXQt desktop Environment for Fedora. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == LXQt [1] is the Qt port and the upcoming version of LXDE [2], the Lightweight Desktop Environment. It is the product of the merge between the LXDE-Qt and the Razor-qt projects: A lightweight, modular, blazing-fast and user-friendly desktop environment. == Scope == * Proposal owners: LXQt packages already approved and in the system. * 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://lxqt.org/ [2] https://fedoraproject.org/wiki/LXDE

1 0

F22 System Wide Change: Legacy implementations of the Java platform in Fedora
by Jaroslav Reznik 24 Feb '15

24 Feb '15

= Proposed System Wide Change: Legacy implementations of the Java platform in Fedora = https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora Change owner(s): Jiri Vanek <jvanek(a)redhat.com> Currently Fedora supports one main Java runtime and Java Development Kit (JDK) and from time to time one future JDK as a tech preview. This change should be set of rules, which will enable community to maintain legacy JDKs. Please note, people are bugging main JDK maintainers pretty often with this, and to allow them to maintain legacy JDKs is a step in right direction. * This Change is announced after the Change Submission Deadline as an exception to the process. May not be approved for proposed Fedora release. * == Detailed Description == This is no real work proposal. The result of this proposal is set of rules, which will allow community maintainers to pack any legacy jdk and will be ensuring that this JDKs will not conflict by any other JDK and will smoothly integrate to system. The results are summarized here, and pledged for discussion until final resolution is done. === Proposed rules === 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. This must remain clear''' ==== option one - introducing new packages - preferred ==== 1. main jdk is proclaimed as dead as it was until now. The new jdk is derived as new package prviousName-legacy 1. so from killed java-1.7.0-openjdk will become new package java-1.7.0- openjdk-legacy 2. next main jdk do Obsolete previous one as usually 2. new package '''must''' not do any virtual provides (aka java,java-devel)... (protection against random pull by as dependence) 1. it provides only itself by name 3 its priority '''must''' be kept on less digits (right now it would be 5) then main jdk (protection against winning in alternatives after update) 1. the automated check as https://bugzilla.redhat.com/show_bug.cgi?id=1189084 are '''mandatory''' 4. at least one of the main-jdk's members '''must''' be set as comaintainer (to watch the commits and save the world if necessary) 5. new package '''should''' to follow both original jdk (ideally not change at all (except source updates and necessary)) and current main jdk as close as possibly 1. here it requires some common sense and a lot of testing if integration with system is as expected 6. as it is generally not new package, the review process '''should''' be only formal - to know maintainer and to create cvs repo 1. this is quite important, otherwise the new maintainer can become really frustrated, and we are forcing the "dead" package over"orpahned" so the full review (especially in alignment with rule 5) really should not be forced. 2. on the contrary, rules agreed here '''must''' be checked. (even the number 5) 7. all depending packages '''must''' keep requiring java-headless or java (and BuildRequires java-devel). Requirements on any exact jdk - or even worse on any exact legacy jdk are forbidden and needs FESCO exception. This option is forcing maintainers to fight with the name x current setup of alternatives. However, the work should be minimal. But it makes the update path pretty clear and it keeps users well protected against legacy jdk. ==== option two - orphaning legacy jdks and ensure update path ==== 1. main JDK is only orphaned when new main JDK landed 1. it do '''not''' Obsolate previous jdk 2. other rules (2-7) are same This is making life of legacy JDK maintainers a bit simpler. But I don't know, how to ensure proper "obsolete" implementation in this case. == Scope == * Proposal owners: are responsible for initial setup of those guidelines. The FESCO, the owners and pssible legacy JDKs maintainers have to agree on those rules. New legacy JDK can be then added anytime in Fedora lifecycle. * Other developers: no developers * Release engineering: in ideal case, no release engineer needed * Policies and guidelines: The proposal may split to proposal and "Legacy JDKs in Fedora guidelines" pages

1 0

Rebuild in Rawhide for Fedora 23 Change Harden all packages with position-independent code
by Till Maas 21 Feb '15

21 Feb '15

Hi, I started rebuilding about 260 select packages for the following Fedora 23 Change: https://fedoraproject.org/wiki/Changes/Harden_all_packages_with_position-in… I only rebuilt packages that were installed on a test system and not yet built with the harden build flags. The remaining packages will be taken care of in the full mass rebuild that will happen because of the GCC5 Change for Fedora 23. Kind regards Till

1 0

New Upstream Release Monitoring Systems
by Ralph Bean 20 Feb '15

20 Feb '15

I'm proud to announce that the Infrastructure team has finished deploying the first iteration of our replacement for the older, wiki-based Upstream Release Monitoring tools this week. You can read about the details of the trio of systems[1] now used to coordinate upstream release monitoring on the same old wiki page. Names of systems: - pkgdb is the familiar Fedora Package DB https://admin.fedoraproject.org/pkgdb It provides some flags used by the other systems. - anitya is the web app running at https://release-monitoring.org It is responsible for scraping upstream release sites looking for new releases. - the-new-hotness is a backend daemon that responds to fedmsg messages about upstream releases. The bugs filed in bugzilla look much the same as they did before, but for packagers there is one thing to note: the process of getting your package(s) registered for upstream release monitoring has changed. Please see the instructions[2] on the wiki page. Old packages that were listed on the wiki page have been imported to release-monitoring.org and have had their monitoring flag set in pkgdb. New packages added to Fedora now have their monitoring flag set to True by default and a script attempts to map them to an upstream project in release-monitoring.org automatically. If you want new upstream releases monitored for your package(s), you must: - Add the upstream project to anitya[3]. - Map the upstream project to a Fedora package in anitya[3]. - Enable the monitoring flag for that Fedora package in pkgdb2[4]. Note also that it is now possible to get notifications about upstream releases without bugs being filed in bugzilla. To do this, add your projects to release-monitoring.org and configure your Fedora Notifications (FMN)[5] account while leaving the monitor flag set to False in pkgdb[4]. If you encounter bugs or have requests for enhancement, as always please do file them[6][7][8].. and if you're having problems with a particular package there is a place to list those[8] also on the wiki page. [1] https://fedoraproject.org/wiki/Upstream_release_monitoring#Details [2] https://fedoraproject.org/wiki/Upstream_release_monitoring#TLDR.3B_Get_Pack… [3] https://release-monitoring.org [4] https://admin.fedoraproject.org/pkgdb [5] https://apps.fedoraproject.org/notifications [6] https://github.com/fedora-infra/anitya [7] https://github.com/fedora-infra/pkgdb2 [8] https://github.com/fedora-infra/the-new-hotness [9] https://fedoraproject.org/wiki/Upstream_release_monitoring#Requesting_Help

1 0

All packagers to be added to the new notifications system
by Ralph Bean 18 Feb '15

18 Feb '15

As previously announced[1], the infrastructure team is going to be adding all of the members of the packager group to the new fedmsg notifications system (FMN)[2]. It is currently an opt-in system, and this event will just invert things to make it opt-out; you can still disable notifications from it in the web interface. The cut-over will happen next week on Wednesday, February 11th. Thank you, Ralph Bean [1] https://lists.fedoraproject.org/pipermail/devel-announce/2014-September/001… [2] https://apps.fedoraproject.org/notifications/

2 1

Planned Outage: pkgs.fedoraproject.org - 2015-02-19 09:00 UTC
by Kevin Fenzi 17 Feb '15

17 Feb '15

Planned Outage: Migration to gitolite3 - 2015-02-19 09:00 UTC There will be an outage starting at 2015-02-19 09:00 UTC, which will last approximately 3 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2015-02-19 09:00 UTC' Reason for outage: We will be upgrading our dist-git setup from gitolite2 to gitolite3 and from RHEL6 to RHEL7. The ssh host keys should be preserved in this migration. Uploads to lookaside cache, commits or checkouts of pkgs git and official builds that use git will be down during the outage. Affected Services: Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Secondary Architectures Unaffected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ Darkserver - https://darkserver.fedoraproject.org/ 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 Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Contact Information: pingou, kevin Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4651 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above.

1 0

Fedora 22 Changes Completion deadline in one week - 2015-02-24
by Jaroslav Reznik 17 Feb '15

17 Feb '15

Greetings! Fedora 22 Change Checkpoint: Completion deadline (testable) is in one week - 2015-02-24 [1] and we're getting closer to this date. Other important milestones are scheduled for this date: * Alpha Freeze * Software String Freeze * Bodhi activation point At this point, all accepted changes should be substantially complete, and testable. Additionally, if a change is to be enabled by default, it must be so enabled at Change Completion deadline. Change tracking bug should be set to the MODIFIED state to indicate it achieved completeness. Fedora 22 is strictly time based release and we want to adhere to the schedule. Incomplete and non testable Changes will be reported to FESCo for 2015-02-25 meeting. Contingency plan for System Wide Changes, if planned for Alpha (or in case of serious doubts regarding Change completion), will be activated. [1] https://fedoraproject.org/wiki/Releases/22/Schedule Jaroslav

1 0

Fedora 22 Mass Branching
by Peter Robinson 10 Feb '15

10 Feb '15

Hi All, Fedora 22 has been branched, please be sure to do a git pull --rebase to pick up the new branch, as an additional reminder rawhide/f23 has had inheritance cut off from previous releases, so this means that anything you do for f22 you also have to do in the master branch and do a build there. This is the same as we did for previous Fedora releases Peter

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce February 2015