devel-announce September 2007

devel-announce@lists.fedoraproject.org

9 participants
18 discussions

We are Frozen for Test3
by Jesse Keating 26 Sep '07

26 Sep '07

We froze for test3 early this morning. This also marks the Devel freeze for the remainder of the Fedora 8 development cycle. Builds from rawhide will continue to get the 'dist-f8' tag, and will be available in the buildroots to build against. However rawhide will compose from the 'dist-rawhide' tag, which inherits from 'f8-test3'. If you need to get a build into Fedora 8 Test3, please follow http://fedoraproject.org/wiki/ReleaseEngineering/TestFreezePolicy For schedule information, see http://fedoraproject.org/wiki/Releases/8/Schedule To see if your build made the freeze cut off, see http://koji.fedoraproject.org/koji/builds?tagID=27 or simply call 'koji latest-pkg f8-test3 <pkgname>' -- Jesse Keating Fedora -- All my bits are free, are yours?

1 0

Outage Notification - 2007-09-26 04:00 UTC (DB2)
by Mike McGrath 25 Sep '07

25 Sep '07

There will be an outage starting at 2007-09-26 04:00 UTC UTC, which will last approximately 5 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2007-09-26 04:00 UTC' Affected Services: Websites Buildsystem Database Unaffected Services: CVS / Source Control DNS Mail Torrent Ticket Link: https://hosted.fedoraproject.org/projects/fedora-infrastructure/ticket/163 Reason for Outage: DB2 is running out of disk space. This is a preventative maintenance to ensure that we don't completely run out. There are a couple of avenues I'm still examining but if they fail I'll be forced to rebuild db2 with more storage and that's the reason for the outage. Its possible the actual outage will only take an hour or two but just in case I've created a 5 hour block. Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage.

1 0

[Policy Change] Kernel Module packages no longer permitted
by Tom Callaway 22 Sep '07

22 Sep '07

At one point (pre Fedora 8), packages containing "addon" kernel modules were permitted. This is no longer the case. Fedora strongly encourages kernel module packagers to submit their code into the upstream kernel tree. Existing kernel module packages must be removed (or merged into the main kernel package) before Fedora 9. The reference documentation on how to package kernel modules in the "kmod" style has been preserved http://fedoraproject.org/wiki/Obsolete/KernelModules This change was ratified by FESCo. Thanks, ~spot

1 0

Proposed changes to F8 Freeze Process
by Warren Togami 20 Sep '07

20 Sep '07

September 20th, 2007 Fedora Engineering Steering Committee ratified these changes to the final F8 freeze process. http://fedoraproject.org/wiki/Releases/8/Schedule 1) CHANGE: At F8 Development freeze currently scheduled for October 4th, the tree will be unlocked for new builds to be automatically tagged into dist-f8. We will be treating this as an "honor system" freeze, where participants are expected to commit only bug fixes and NOT threaten the release with new features or risky changes. The purpose of this new "freeze" policy is an experiment to smoothen the process of getting last-minute fixes in F8 without creating a large workload on rel-eng. This should reduce confusion of built but not tagged packages like during past freezes. HOWEVER, peer policing of proper adherence to freeze guidelines is essential. We will be advertising loudly expectations of package maintainers of acceptable changes during the freeze period. 2) REMINDER: If you screw up and add something to F8 that shouldn't be (horribly broken new version, ABI change, so-name bump, new features, etc.) we will NOT roll-back your build if it has already hit a daily rawhide push. Your only option to recover from this mistake will be to increase the version number or Epoch. 3) CHANGE: Prior to Final Freeze (October 17th) devel/ CVS branch will build into dist-f8. Some package maintainers will want to begin building packages with risky changes (ABI, new features, etc.) in preparation for F9. At their option they may request per-package CVS branch to F-8/ so they may do so without risking F-8 stability. Then devel/ can be used to target dist-f9. 4) CHANGE: Due to the definition of "Development freeze" changing, we are moving up the Final freeze date a week to October 17th. At this point builds will no longer be automatically tagged dist-f8 and will require rel-eng approval to be included in the F8 release. All remaining devel/ will be branched to F-8/, and devel/ will target builds to dist-f9. Warren Togami wtogami(a)redhat.com

1 1

-D_FORTIFY_SOURCE=2 and C++
by Jakub Jelinek 18 Sep '07

18 Sep '07

Hi! Starting with gcc-4.1.2-25 and glibc-2.6.90-14 -D_FORTIFY_SOURCE=2 protects not only C code, but also C++. There have been several security issues already which would have been unexploitable if this checking was in place earlier. All the mem*, str* etc. routines that were previously protected in C will now do so in C++ as well, similarly *printf won't accept %n if format string is in writable memory, open{,at}{,64} functions are checked too (compile time detecteable O_CREAT with only 2 arguments (3 for openat{,64}) results in link time errors, if it is unclear whether oflag arg has O_CREAT or not at compile time and only 2 (resp. 3 for openat{,64}) args are provided, runtime checking is done). BTW, even for C open is no longer a function-like macro, while it is desirable to fix packages that don't allow open to be defined as function-like macro, it will no longer be a necessity for F8 to change this. If you see any bugs on the toolchain side (rather than newly discovered package bugs), please let us know in bugzilla ASAP. Thanks. Jakub

1 0

Xulrunner in Fedora 8
by Jesse Keating 18 Sep '07

18 Sep '07

A xulrunner build appeared in Fedora 8 buildroot and was pushed out to rawhide. This was a bit premature and as such we have untagged the build. There is no older build, nor any new build to immediately fix issues. Therefor xulrunner will not be available in buildroots and it will disappear from rawhide until the issues surrounding it are resolved (matching firefox build, ppc(64) support, no conflicting files). -- Jesse Keating Fedora -- All my bits are free, are yours?

1 0

Fedora 7 update data not valid, do not sync.
by Jesse Keating 18 Sep '07

18 Sep '07

Due to a configuration error, the content in the Fedora 7 updates directory got removed. If you have any automated processes that would sync Fedora 7 updates, it is advised that you turn them off for the time being. We are re-populating the content from the build system but this will take some time (hours). I will respond to this when it finishes (if I'm still awake) and it is safe to sync updates once more. No new updates will be processed until this is fixed. -- Jesse Keating Fedora -- All my bits are free, are yours?

1 2

REMINDER: Fedora 8 Test3 Freeze
by Jeremy Katz 17 Sep '07

17 Sep '07

The Fedora 8 Test 3 freeze is rapidly approaching! This is your last major chance for getting any bug fixes or other changes tested prior to the release of Fedora 8. The freeze date is next Tuesday, September 25. For full details of the schedule, as always, see http://fedoraproject.org/wiki/Releases/8/Schedule What does this mean? It means that it's probably a good time to go through and look through all of the bugs that are filed against your packages. And as much as possible, fixing those bugs which you deem important for Fedora 8 prior to the freeze date. Also, for tracking purposes, you might want to attach important bugs to one of the tracker bugs according to the criteria at http://fedoraproject.org/wiki/QA/ReleaseCriteria. A quick summary of the main tracking bugs are * F8Blocker (235703): This is for bugs which are very very bad. Bugs which the release team should consider slipping the release for. Note, you should not use this characterization lightly. And the final judgement on whether a bug is worth slipping the release will be made by the release team. * F8Target (235704): Bugs which are pretty important, but not slip-worthy. The release team will keep an eye on this list and would ultimately like the open bugs here to be as minimal as possible. Once we enter the freeze, changes for the test release will be approved according to the normal test freeze policy (http://fedoraproject.org/wiki/ReleaseEngineering/TestFreezePolicy). After Test3, we want to reduce the number of changes going in to help ensure that the final release has as few regressions as possible. So it's very important to get as many of the fixes as possible done prior to Test3. More complete details about the post-test3 procedure will be forthcoming as we reach that point in the schedule. Thanks for your hard work! Jeremy

1 0

EPEL and Fedora Extras build system down
by Dennis Gilmore 16 Sep '07

16 Sep '07

Hi All, The main build hub for the plague build system is currently down. It will remain down until we can get someone to look at it in the morning. Sorry for the short notice. Dennis

1 0

PackageDB 0.3.1 open for business
by Toshio Kuratomi 13 Sep '07

13 Sep '07

Greetings all, After an extended period of testing, I'm officially announcing the PackageDB as open for (some) business. == What can you do == * Add yourself as an owner * Request to be a comaintainer or added to the CC List * Remove yourself from the above * Approve or reject people requesting the above == What can't you do == * Add new packages. The plan is to add a way to enter the package information via a packagedb interface eventually. Once entered, the information will either be queued for a cvsadmin to look at (similar to how requests are handled currently in bugzilla) or the request will automatically happen if a simple test can detect that the review bug was approved. In talks with a limited number of people, the favorite is queueing for an admin. Please discuss this if you think it should happen automatically. [1]_ * Add a branch. This needs a UI created for it as well. I haven't discussed this yet but it seems that adding branches for currently active Fedora (and EPEL) releases should be done automatically when a maintainer requests it. [2]_ * Add another user to a package. Currently, the person has to request the permissions that they want on the package. Then one of the maintainers approves the permissions. I need to code an interface to allow the package maintainers to add another user directly [3]_ .. _[1]: https://hosted.fedoraproject.org/projects/packagedb/ticket/18 .. _[2]: https://hosted.fedoraproject.org/projects/packagedb/ticket/65 .. _[3]: https://hosted.fedoraproject.org/projects/packagedb/ticket/63 == What's Next == The next few weeks of effort will be quick bugfixes and making sure we're ready for the branching of packages that will be done near Fedora 8 release. -Toshio

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce September 2007