Late reminder, Fedora 10 Alpha (nonblocking) freeze tomorrow!
by Jesse Keating
We have our first development freeze of the Fedora 10 cycle tomorrow.
This is the alpha freeze, which is non-blocking. Release Engineering
will be making a freeze inside the buildsystem of tomorrow's rawhide
content. This will be the basis of the Fedora 10 Alpha release.
Rawhide will continue to move forward with new builds. Things which are
critical to have in Alpha should be brought to release engineering's
attention via our Trac queue: https://fedorahosted.org/rel-eng/newticket
Sorry for the late reminder!
--
Jesse Keating
Fedora -- Freedom² is a feature!
15 years, 9 months
Outage Notification - 2008-07-22 04:59 UTC (MAJOR)
by Mike McGrath
There will be an outage starting at 2008-07-22 04:59 UTC, which will last
approximately 10 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2008-07-22 04:59 UTC'
Affected Services:
Websites
Buildsystem
Database
Unaffected Services:
CVS / Source Control
DNS
Mail
Torrent
Fedora Hosted
Talk
Ticket Link:
https://fedorahosted.org/fedora-infrastructure/ticket/705
Reason for Outage:
Re-migrating db1 to its new hardware (memory issues have hopefully been
resolved). Moving koji database from db2 to a dedicated new server, db3.
The db1 outage will cause the wiki and smolt to be offline for no longer
then an hour.
The koji move will cause the buildsystem (and whatever depends on the
build system) to be down for between 8 and 10 hours. We haven't padded
the outage so if something goes wrong, we'll have to abort and re-schedule
it for another time. Likely the next night so be prepared. Also please
make sure any builds you complete any builds prior to the time of the
outage.
Contact Information:
Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.
15 years, 9 months
FUDCon Brno 2008
by Max Spevack
(re-sending from fedora-announce-list because I know there are a lot of
Fedora developers who don't read that list, and I want our contributors
in Europe to see this.)
----
The next FUDCon will take place in Brno, Czech Republic, from September
5 - 7, 2008.
The main conference day and social event will be on Saturday (to attract
the most people), with hackfest days on Friday and Sunday. FUDCon is
always free to attend, no matter where in the world it is located.
To sign up or get more information, please visit:
https://fedoraproject.org/wiki/FUDCon/FUDConBrno2008
If you cannot attend this FUDCon, do not despair! We expect to hold a
FUDCon somewhere in Asia or India later in 2008, and in multiple
locations worldwide in 2009.
--Max
15 years, 9 months
FESCo Elections open on July 15th
by Brian Pepple
Hi all,
Elections for the Fedora Engineering Steering Committee (FESCo) open at
0001 UTC on 15 July 2008. NOTE: this is a copy of the announcement that
was sent to the fedora-announce-list, for those not subscribed). The
voting system is available at: https://admin.fedoraproject.org/voting
The voting system uses the range voting method:
http://en.wikipedia.org/wiki/Range_voting
Any Fedora Account System (FAS) account holder who has completed the
CLA, and has an addition account (like ambassadors, art, cvs*,
fedorabugs, l10n-commits, web, etc.) in the FAS is eligible to vote.
Voting is open until Monday, July 21st, 2008 23:59 UTC. Election
results will be announced shortly afterward.
The nominees for the nine open seats, in alphabetical order, are:
1. Josh Boyer
2. Steve Dickson
3. Kevin Fenzi
4. Dennis Gilmore
5. Karsten Hopp
6. Christian Iseli
7. Jon Masters
8. Bill Nottingham
9. Brian Pepple
10. Jon Stanley
11. Jarod Wilson
12. David Woodhouse
The nominees have also placed some summary information about their
background and goals on the wiki nominations page:
https://fedoraproject.org/wiki/Extras/SteeringCommittee/Nominations
These summaries are also available from the "Info" link next to each
candidate's name in the voting system.
If you have any problems with voting, report them immediately in the
ticket system, at: https://admin.fedoraproject.org/tickets
Use the "elections" category when you file your ticket so that it is
directed quickly to the appropriate parties.
Thanks,
/B
--
Brian Pepple <bpepple(a)fedoraproject.org>
https://fedoraproject.org/wiki/User:Bpepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
15 years, 9 months
Release Engineering Email Trac Queue Disabled
by Jesse Keating
Until further notice the email to trac gateway for rel-eng has been
disabled. We've been unable to cope with the spam attacks and the
subsequent mail loops that have been created, and thus we have disabled
the gateway.
For the time being if you need release engineering to do something for
you, please use the web UI to file a ticket. It allows for anonymous
filing, but we would prefer you put in your email address so that you
get properly contacted when the task is complete.
https://fedorahosted.org/rel-eng/newticket
If anybody would like to help us take another stab at email to trac
submissions, feel free to contact us on rel-eng(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/rel-eng
or in #fedora-admin on freenode IRC.
--
Jesse Keating
Fedora -- Freedom² is a feature!
15 years, 9 months
Heads-up: brand new RPM version about to hit rawhide
by Panu Matilainen
At long last, we are about to get a brand new RPM version (alpha snapshot
at the moment) into rawhide. The list of changes from 4.4.2.x is massive
and a full summary needs a separate posting (will follow as time permits),
this is just a heads-up of immediate consequences for Fedora packagers and
rawhide consumers:
Users:
1) BACKUP YOUR RPMDB, NOW! We're not aware of any baby-eating bugs in rpm
but I'd be shocked if there were no new bugs at all... Better safe
than sorry - do something like this before updating to the new rpm:
# cp -avp /var/lib/rpm /var/lib/rpm-`date +%d%m%y`
2) Rebuilding the rpmdb is not a bad idea (if not strictly necessary):
# rpm --rebuilddb
3) Watch out for regressions and please report immediately if found.
Again, we're not aware of any baby-eating bugs but there has been an
enormous amount of changes in the codebase...
The python bindings are supposed to be entirely backwards compatible
but there are some small differences with returned types (notably
returning an empty list vs None) on tag data in some cases, this breaks
rpmlint (patch is trivial, will send to maintainer).
Packagers:
1) So-name bumb is involved, the API has changed a lot. Here's the list
of involved packages according to repoquery and status, I'll be sending
patches to package maintainers shortly:
- gdb (needs update to locate build-id patch)
- perl-RPM2 (needs some updating)
- apt (needs major work, but this is my headache)
- ruby-rpm (needs quite a bit of work)
- deltarpm (just needs a rebuild apparently)
- net-snmp (needs rebuild with -D_RPM_4_4_COMPAT)
- rpmreaper (needs rebuild with -D_RPM_4_4_COMPAT)
2) rpmbuild uses --fuzz=0 parameter to patch by default. This will "break"
many many packages as this is stricter than the default of patch
command itself. Two possibilities:
- Rediff your patches and check they're applying correctly. This is
the best thing to do, patches applied with fuzz can and do cause
strange and nasty bugs.
- As a temporary action, adding "%define _default_patch_fuzz 2"
to spec will force rpm to use fuzz level 2 which is the default for
patch itself.
3) %{_topdir} now defaults to $(HOME)/rpmbuild/, /usr/src/redhat/ is
no more.
4) BuildRoot from spec is ignored. Rpm now defaults to buildroot under
%{_topdir}/BUILDROOT/
5) Rpm now supports "arch dependencies", so eg. foo-devel dependencies can
be expressed correctly. Please wait for FPC recommendations on the
subject, this needs a mass rebuild to be usable.
6) Rpm now collects pkg-config and libtool dependencies automatically.
Initially only provides will be created to avoid creating unsolvable
dependencies though.
7) Two new macros, %{patches} and %{sources} are supported in rpmbuild.
In other words, you can now do things like:
for p in %{patches}; do
...
done
Just keep in mind that using these in your spec will make the it
incompatible with rpm 4.4.x versions.
P.S. The new rpm will be initially built against Berkeley DB 4.5.20 from
compat-db to ensure easy downgrade path to rpm 4.4.x should something
go terribly, horribly wrong. Newer BDB would require manual db
conversion to downgrade.
- Panu -
15 years, 9 months
Rawhide Orphanarium Purge: June 18th
by Warren Togami
Please review the following packages. This is roughly the list of
current orphans in rawhide. If they are not claimed by June 18th then
they may be removed from rawhide by the F10 Alpha freeze.
libical
python-libgmail
python-libgmail-docs
pygtkglext
system-summary
lipstik
rafkill
xdms
xeuphoric
skencil
emerald
connect-proxy
gnome-applet-tvn24
aasaver
kbiof
osmo
nautilus-share
ruby-amazon
PyOpenGL
AGReader
tripwire
emerald-themes
perl-Net-Telnet
multitail
gnome-ppp
fuse-gmailfs
libgringotts
Warren Togami
wtogami(a)redhat.com
15 years, 9 months
Red Hat (Fedora) Bugzilla 3.2 Upgrade on July 26th, 2008
by John Poelstra
I'm sending this on behalf of Dave Lawrence and the bugzilla team at Red
Hat. Fedora uses this instance of bugilla too.
Please forward this on to people or groups I missed.
Thank you,
John
-------------------------------
Greetings,
The Red Hat Bugzilla team is happy to announce that the release of the
next version of Red Hat Bugzilla will occur on July 26th, 2008. The next
version will be based on the upcoming upstream 3.2 code base soon to be
released.
For previewing the next release please go to:
https://partner-bugzilla.redhat.com
We encourage everyone to please go to the above site and provide any
final testing and feedback where possible. Please verify that the
features you have come to reply on day to day in our current Bugzilla
are still available and working properly. Please use the new UI and make
sure that you can accomplish the same tasks. Do not worry about making
changes, this is a test snapshot and is not live data. Also emails will
not be sent for changes so do what you like. Also please make sure your
stored queries/reports/whines still work and display as expected.
Some notable changes since 2.18:
Ajax optimizations on searching and displaying bug
Improved needinfo actor support
Changed guided bug entry
UI enhancements
XMLRPC API: New API plus compatibility with old API. (please verify your
scripts that use XMLRPC against the test system before the release date)
There are numerous other changes behind the scenes that we haven't
listed. The goal is to make sure that functionality that people have
come to expect in 2.18 is possible in the new system.
There are also numerous new features/fixes that are part of the upcoming
3.2 release provided by the upstream Bugzilla community. For more
detailed information on what has changed since the last release, check
out the Release Notes.
We have done extensive work at laying out what we feel the requirements
are to maintain feature parity with our current system as well as
compiled a list of feature enhancements that people would like to see in
the next release. Our goal is to deliver a working bugzilla with the
bare essential requirements similar to what is currently being used in
our current 2.18 system. After that we will begin work on enhancements
as time and resources permit. To view the final release requirements
list please refer to our Bugzilla 3 Tracking bug at
https://bugzilla.redhat.com/show_bug.cgi?id=406071.
Please file any enhancement requests or bug reports in our current
Bugzilla system at bugzilla.redhat.com. File them under the Bugzilla
product and relevant component with the version 3.2. Also send questions
to bugzilla-owner(a)redhat.com. With everyone's help we can make this a
great release.
Thanks The Red Hat Bugzilla Team
15 years, 10 months