Fedora 9 Release date slipping by two weeks (new date, May 13)
by Jesse Keating
At today's regularly scheduled meeting, the Fedora Engineering
Steering Committee (FESCo) decided that Fedora 9 release will be
slipping by exactly two weeks.
Because of other slippage, coupled with some technical difficulties
during this previous week, our Preview Release was unexpectedly
stalled. The Preview Release is where we expect to catch all manner
of last-minute bugs, do very heavy QA, and otherwise perform all the
final spit-and-polish. There needs to be sufficient time between the
PR and the release for testers to find and report issues.
There are less than two weeks remaining until the original target date
of April 29th. About a week before that date we have to have
everything locked and loaded for distribution by our mirrors. That
small a timeframe would then make the Preview Release -- normally a
very important part of our release schedule -- nearly useless.
This slip is not intended to make room for more changes, it is only
intended to make room for fixing the things we already know about, and
allowing new things to be found, and evaluated as release blocking, and
fixed. There are also a fair number of bugs we think we've already
fixed, but need wider audience testing to be sure.
The current blocker list is viewable at
https://bugzilla.redhat.com/showdependencytree.cgi?id=235706&hide_resolved=1 however since there is nothing preventing people from adding bugs to this list it will get culled from time to time from things that aren't actually blockers. A (rather longer) list of things we'd like to see fixes for can be seen https://bugzilla.redhat.com/showdependencytree.cgi?id=235705&hide_resolved=1 although this list does get less attention than the blocker list.
We deeply appreciate the value we get from our community in using our
development tree and testing our release attempts. Without your input,
our releases couldn't possibly be as good as they have been. Please
help us use these extra couple of weeks to make the already awesome
Fedora 9 even better!
--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
16 years, 2 months
GCC and pointer overflows
by Gianluca Sforna
I just read this news on LWN ( BTW, thanks to Jeff for providing me a
free subscription... )
Are our packages affected by this gcc "feature" ?
http://www.kb.cert.org/vuls/id/162289
In other words, do our default compilation flags lessen or nullify the
impact of that problem?
Cheers
Gianluca
16 years, 2 months
Rawhide issues
by Jesse Keating
Some of you may have noticed some "issues" with rawhide today. Many
(most) the packages reverted to unsigned versions, and then at some
point today, the content went back in time to yesterday. This is
because of a timing issue with trying to sign all the packages for
Fedora 9 release. A small thinko led to a big churn that I tried to cut
off before it got too far. I think I've recovered most of the damage,
and I've prevented rawhide from being composed again until we're done
signing packages, which hopefully will be at some point tomorrow.
Just wanted to keep you all informed of what's going on. Cheers!
P.S. Preview Release is also pending these signatures. It will happen,
eventually (:
--
Jesse Keating
Fedora -- All my bits are free, are yours?
_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce
16 years, 2 months
LWN subscription lottery reminder
by Jef Spaleta
A heads up for those of you who have already seen the announcement
over the weekend.
I'm at 33 requests, I'm looking for at least 75. If you are
interested but haven't sent in the details stop procrastinating and
get your requests in.
If you've forgotten what I'm talking about, refresh your memory here:
http://jspaleta.livejournal.com/#item19142
Please do not reply back to this thread. I'm guaranteed to lose the
request in the big inbox pile unless you do the following:
email jspaleta(a)fedoraproject.org
Subject: LWN subscription request
Include:
Your real name
Your fas accountname
your lwn accountname to be granted a subscription
-jef"You'd think giving away freebies would be easier"spaleta
16 years, 2 months
rpm-find-requires in Rawhide - prints nothing!
by Richard W.M. Jones
On my F-8 machine:
$ echo /bin/ls | /usr/lib/rpm/find-requires
libacl.so.1()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
librt.so.1()(64bit)
librt.so.1(GLIBC_2.2.5)(64bit)
libselinux.so.1()(64bit)
However on my Rawhide machine, updated to the latest version, the same
command prints nothing at all!
As a result rpmbuild is generating empty lists of requires for
anything I build.
$ rpm -qf /usr/lib/rpm/find-requires
rpm-build-4.4.2.3-1.fc9.i386
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
16 years, 2 months
Mono Package audit
by Toshio Kuratomi
Hey all,
We discovered that a few mono packages had issues with including
prebuilt binaries so I did a quick check of all the mono packages I
could find to see just how big the problem is. I used the
mono-detect.sh script I'm attaching to find mono using packages. It
might not be a complete list as I was unable to find one package that
everything depended on. (It really seems like everything should depend
on mono(System) or mono-core but they don't) If someone can come up
with a better check and make sure I found all the packages that would be
appreciated.
I then downloaded the tarballs for each of the packages and ran find .
'*.dll' to find prebuilt binaries. Where prebuilt binaries existed, I
looked to see if there was discernable source files. If I found none,
then I marked the package as binary in the attached mono-pkgs list. If
I found source the package was marked as unknown since someone has to
check if the files are rebuilt or included verbatim.
I also looked for packages which appeared to bundle third party library
source. This is the equivalent of linking against static libraries in
the C world so we want to fix these at some point as well. They are
marked 'bundled' in the mono-pkgs file.
What to do about these problems? It has been proposed that the programs
which contain binaries be blocked from going into F9 until the problems
have been resolved. This plan would still have to address what to do
with the "unknowns" on the list.
I'm also thinking of drafting a packaging guideline to delete all
prebuilt binaries from the spec file. This would make it quite plain
when a package is built from source and when it is not as opposed to
having to decipher whether timestamps have forced a rebuild. I think
this should be fine for any package already in Fedora (and not blocked
by the binary requirement). Some packages may need to be bootstrapped
in initially, though, so I'll have to think of some way to deal with that.
-Toshio
PS: spot has a patch for db4o so that's one down :-)
status can be clear, bundled, binary, or unknown
* binary implies bundled
* binary must be yanked
* bundled needs to be fixed
* unknown means you have to read the notes to know what's going on.
Note that the maintainers of the packages marked clear should still perform
their own audit of the code as I may not have caught every imported library.
status | package
----------+------------
clear | avahi
binary | banshee_
bundled | beagle_
clear | bless
unknown | boo_
clear | cdcollect
bundled | cowbell_
binary | db4o_
clear | dbus-sharp
clear | evolution-sharp
bundled | f-spot_
clear | gbrainy
clear | gecko-sharp2
clear | gmime
clear | gnome-do
clear | gnome-sharp
clear | graphviz
clear | gsf-sharp
clear | gtk-sharp
clear | gtk-sharp2
clear | gtksourceview-sharp
clear | ice_
binary | ikvm_
clear | ipod-sharp
unknown | log4net_
unknown | mono_
clear | mono-addins
unknown | mono-basic_
unknown | mono-debugger_
unknown | monodevelop_
bundled | monodoc_
clear | monosim
clear | mono-zeroconf
bundled | muine_
binary | nant_
clear | ndesk-dbus
clear | ndesk-dbus-glib
clear | podsleuth
clear | themonospot
bundled | tomboy_
clear | xsp
.. _banshee: Boo.dll files are in an Extras/Boo directory. May be able to
disable at buildtime. Note in spec that Boo does not build on ppc
.. _beagle: At least, TagLib-sharp, Snowball.Net and Lucene.Net. Possibly
others.
.. _boo: Ships with prebuilt Boo dlls. Package wouldn't build so I couldn't
check if those get rebuilt or not. It would be great if packages that
have prebuilt .dlls would rm -f the .dlls in the spec file so we
can check this easily.
.. _cowbell: taglib (different from TagLib-Sharp.): Note, taglib's upstream
may be dead and there might not be any other packages using
this. Pending verification of that, maybe it should be a
subpackage of cowbell.
.. _db4o: At least Cecil.FlowAnalysis, Mono.Cecil, Mono.GetOptions (mono-core)
.. _f-spot: At least, dbus-sharp, libgphoto2-sharp, gnome-keyring-sharp, Tao,
google-sharp, FlickrNet, semweb, (dbus-sharp-glib?), Mono.Cairo,
Mono.Addins
.. _ice: Ice is a little strange as it has several source tarballs and several
subpackages for different languages.
.. _ikvm: lib/IKVM.GNU.Classpath.dll, IKVM.AWT.WinForms.dll, IKVM.Runtime.dll
.exe's as well. Looks like there's either no source or source only
for the .exe's.
.. _log4net: This has some .dlls. It looks like they are removed and rebuilt
during the build. But we should really rm all dlls in the spec
file as otherwise you have to trust that what the build says is
happening is actually happening.
.. _mono: ships several binaries. Unknown whether these are rebuilt. Someone
please look into it. mcs.exe mscorlib.dll System.dll System.Xml.dll
Also, if these were used for bootstrapping, they should be removed
in the spec as we should be able to build from source with the mono
package itself.
.. _mono-basic: Has some dlls that look like they are just used in testing.
Has another dll that says it is for bootstrap. Similar to mono
bootstrap, this should not be necessary once the package is in
Fedora.
.. _mono-debugger: Has a prebuilt dll in a build directory. unkown if this is
rebuilt.
.. _monodevelop: Prebuilt nunit.core.dll nunit.framework.dll. Appears to have
source. Have not checked if they are rebuilt. Definitely has
bundled libraries. At least, Mono.Cecil and NUnit.
.. _monodoc: Bundles at least Lucene.Net
.. _muine: At least, dbus-sharp and dbus-sharp-glib
.. _nant: https://bugzilla.redhat.com/show_bug.cgi?id=441517
.. _tomboy: At least Mono.Addins
16 years, 2 months
[Fwd: Re: Fedora testing]
by Mohammed Omar
Hi all,
It is to inform you all that, The Fedora Testing work has been taken
over by Indhu durai from me. She will be the focal point from IBM side.
The main responsibility is to test development, GA releases along with
rawhides on IBM Hardware(system P).I appreciate the cooperation from
Joshua Boyer, James Laska, Will Woods, David WoodHouse, Dennis Gilmore
and all, expecting the same in future.
Lets welcome Her in the Fedora Community!!
--Best Regards
Omar M
16 years, 2 months