Since Mozilla switched to the new rapid release model, Firefox in Fedora
is no longer fun: Every 6 weeks a new major version hits our stable
release and breaks Firefox horribly:
* My favorite extensions (and actually the only thing that keeps
me using FF) stop working. In the last 7 weeks I had to pitch in
three times and update packages to get things working again.
Sometimes there is not even an update available upstream.
* Firefox falls back to English as there is no language pack
provided. I have to go go the FTP server and download and
install the XPI file manually.
We have ratified very strict guidelines for updates in the stable
releases and we allow one of the critical path applications to break
So what can we do to improve the situation?
1. Can we bring back the language packs as part of the packages?
2. Can the FF maintainers make sure that all maintainers of
extensions get notified of changes *before* release of a new
3. Can someone (I'm looking at you, QA) make sure all extensions
are still compatible?
More ideas or suggestions?
I've got 3 packages languishing in the review queue that I need for a
package update. Would someone swap reviews with me for these?
flocq - Formalization of floating point numbers for Coq
gappalib-coq - Coq support library for gappa (requires flocq)
apron - Numerical abstract domain library
The first two should be dead easy. From Fedora's point of view,
they're just data packages; no libraries or binaries are involved.
The third one is a bit complex. I had to tweak a lot of pathnames to
match existing Fedora practice, as well as do some violence to the
Makefiles to eliminate unused direct shared library dependencies and
undefined non-weak symbols. So please swap me for 2 easy and one hard
review of your own. :-)
[meant to go out last night but failed thanks to internet connection
Yes, it's episode three of the blockbuster 'Remaining F16 blockers'
trilogy - thanks for lining up all week, folks, have a complimentary
As mentioned last time, we span a TC3 image for testing while we try to
zap the remaining blockers:
It has the rebuilt glibc and all affected packages rebuilt against that
glibc. See the TC3 announce for more details. Onto the main event!
1. http://bugzilla.redhat.com/show_bug.cgi?id=749661 "repoclosure
failure on 16.TC3 DVD - PackageKit-zif-0.6.19-3.fc16 requires zif >=
This is new in TC3, but it's straightforward and should be easy to solve
for the next compose. No action really needed.
2. http://bugzilla.redhat.com/show_bug.cgi?id=736893 "New Install of
Fedora 16 TC1 on iBFT iSCSI NIC fails on first reboot"
We've got more data on this one since last time; given that data it'll
likely get dropped from the blocker list, but we'll poke it a bit more
first to make sure.
3. https://bugzilla.redhat.com/show_bug.cgi?id=731245 "KDE fails to
start inside a VM , large amount of memory [@ miCopyRegion]"
We've had some progress on this one today but it still needs work; with
qxl driver, KDE no longer crashes, but has serious rendering problems.
We also determined the issue with the cirrus driver (which is used in
older KVM configs, and 32-bit VMs) is separate and needs to be addressed
separately. Soren says he hopes to have this fixed early tomorrow.
4. http://bugzilla.redhat.com/show_bug.cgi?id=749618 "Mimetype tree is
not a DAG!" errors + crashes when using SMI 0.91"
This causes crashes in some KDE apps, it's already fixed, so the only
action is to pull in the fixed build for the next compose.
5. http://bugzilla.redhat.com/show_bug.cgi?id=749647 "KDE fails to start
in side a VM using the cirrus driver and 'raster' Qt renderer"
This is the cirrus KDE bug: we need X developers to fix this if
possible. I've tried to contact all who may be able to work on it,
6. http://bugzilla.redhat.com/show_bug.cgi?id=748920 "Setting back time
We've worked out more stuff about this one since yesterday; we may be
able to declare it not a blocker based on the various workarounds
available, but we could really do with input from Lennart on why systemd
apparently doesn't provide the emergency mode sometimes when
7. http://bugzilla.redhat.com/show_bug.cgi?id=748747 "Totem doesn't
display video when using software 3D rendering"
We're still really waiting on ajax (or anyone)... to fix this one. We've
confirmed that every test case we've tried with no hardware-accelerated
3D rendering causes broken gstreamer video.
8. http://bugzilla.redhat.com/show_bug.cgi?id=749516 "date doesn't set
This is newly proposed and could do with more info, but may well not
really be serious enough to take as a blocker.
We're obviously pushing the F16 schedule quite hard at this point, but
we can still stay on track if we manage to get all the blockers
addressed tomorrow; we will try to get all validation tests done against
TC3 so we can be reasonably sure there are no other blockers lurking,
and that should give us a reasonable chance at spinning an RC1 with the
extra fixes that passes testing on the first try.
Please, help out with any of the above bugs you can. Thanks everyone!
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list
Curious to know, I am thinking about getting a Yubikey to use on FAS and
other related logins. I seen you must burn the key. I am concidering getting
the Yubikey with the Lasspass subscription included. The question is, if I
burn the key first then is it still usuable on Lastpass? I am assuming that
it will still be ok. Also what is your opinion on the Yubikey? I read a
little on a LWN article that on a Fedora devel mailing list there was a
debate on the security issue of the YK.