Outage Notification - 2007-09-26 04:00 UTC (DB2)
by Mike McGrath
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.
16 years
[Policy Change] Kernel Module packages no longer permitted
by Tom Callaway
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
16 years
Proposed changes to F8 Freeze Process
by Warren Togami
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
16 years
-D_FORTIFY_SOURCE=2 and C++
by Jakub Jelinek
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
16 years
Xulrunner in Fedora 8
by Jesse Keating
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?
16 years
Fedora 7 update data not valid, do not sync.
by Jesse Keating
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?
16 years
REMINDER: Fedora 8 Test3 Freeze
by Jeremy Katz
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
16 years
EPEL and Fedora Extras build system down
by Dennis Gilmore
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
16 years
PackageDB 0.3.1 open for business
by Toshio Kuratomi
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
16 years