Hi, folks - it's time to start bugging you all about Beta blockers! This
post will list out all the current blockers and give a quick status note
and action request (if any) for each.
We're in freeze for Beta but blockers remain unaddressed so we are not
building RCs yet. The Go/No-Go is scheduled for Thursday 2012-11-01. To
have any hope of making that we need all known blockers addressed by
Monday or Tuesday, and the new upgrade tool in decent shape.
The current blocker list can be viewed at
(thanks to Tim Flink for the awesome new blocker tracking webapp).
Action item checklist
Will - keep working on the upgrade tool. Especially focus on stuff that
needs to be prepared within the F18 frozen package set, if anything.
There is a week's wiggle time post-go/no-go to work on stuff that
doesn't need to be in the frozen set.
Anyone - provide karma for these updates:
Blocker status voters, there will be a mini blocker review during QA
meeting on Monday (15:00 UTC in #fedora-meeting). Proposed blockers can
be seen on the blocker list page.
anaconda developers, please take care of these bugs:
and possibly these proposed blockers:
KDE team / Apper devs, please take care of this bug:
Dan and Miroslav, please keep investigating this bug:
Lennart and Kay, please look into this bug:
Detailed analysis of bugs follows.
1. http://bugzilla.redhat.com/show_bug.cgi?id=855526 -
"f18a tc6 anaconda cannot connect to a protected wireless network"
This one's a bit of a mess at the moment; technically it's 'fixed' as
network connections can now be configured during installation, but
testers had various problems that make it clear the functionality is
very fragile. Radek, time is tight here: please make it clear how you'd
like the remaining issues reported, and work on fixing them. It would
also be useful to know what's going to be done about network
configuration in live images - I recall there was an idea to disable
network configuration in liveinst on the basis you should just do it
from the host desktop.
2. http://bugzilla.redhat.com/show_bug.cgi?id=862613 "ValueError: cannot
initialize a disk that has partitions"
We have a bit of a problem here; anaconda team believes this is probably
fixed but the reporter cannot check for sure because he runs into
another bug, http://bugzilla.redhat.com/show_bug.cgi?id=869185 .
anaconda team, it would help if you could provide a patch for that bug
so we can check whether this one is resolved.
3. http://bugzilla.redhat.com/show_bug.cgi?id=866519 "BIOS RAID is not
shown on harddrive screen"
David Lehman has been working on this one constantly, and we have two
people able to test patches quickly, so we just need to keep working on
4. http://bugzilla.redhat.com/show_bug.cgi?id=866486 "Apper: cannot
perform system update"
The symptoms here seem to be solidly established and KDE team is aware
of the bug, we just need them to do whatever's necessary to fix it ASAP.
5. http://bugzilla.redhat.com/show_bug.cgi?id=864765 "mkfs.btrfs SIGABRT
at OS install time"
This one looks pretty solidly fixed by now and we just need karma on the
update so it can be pushed stable and this can be closed out.
We'll vote on all these in the meeting on Monday.
1. http://bugzilla.redhat.com/show_bug.cgi?id=868834 "can't use package
section in kickstart"
There's a patch for this one, so if it's accepted we should be able to
get a fix in soon. It does appear to violate the cited criterion so it's
likely to be accepted as a blocker.
2. http://bugzilla.redhat.com/show_bug.cgi?id=869839 "AttributeError:
'NoneType' object has no attribute 'format'"
This is a fairly easily reproducible crasher in custom partitioning.
We're still twiddling with the partitioning criteria so it's not
entirely clear if it will be accepted as a blocker, but it would be good
if anaconda team could look at a fix in case.
3. http://bugzilla.redhat.com/show_bug.cgi?id=870268 "livecd-tools must
require hfsplus-tools to ensure generated images are Mac bootable"
This seems a reasonably clear blocker as it prevents our live images
being bootable on a target platform (Intel Macs). A fix is available and
4. http://bugzilla.redhat.com/show_bug.cgi?id=844167 "Error in PREIN
scriptlet in rpm package libvirt-daemon-0.9.11.4-3.fc17.x86_64"
This is a very long-standing bug which may possibly affect upgrades even
with the new tool, which is why it's been proposed as a blocker forever.
We can't really decide if it's a blocker till we know for sure if the
new tool is affected by it. The selinux folks have been looking into it
for a while, we just need them to continue to do so.
5. http://bugzilla.redhat.com/show_bug.cgi?id=869061 "No output to
journal after double-switch-root"
If I'm understanding this correctly, it's preventing the new upgrade
tool from logging its process during the 'second stage' (when it
actually performs the upgrade operation in a dracut environment). In
determining blocker status on this it would be very useful to know from
Will or Tim whether we actually need to fix this within the frozen F18
package set or not.
Thanks for reading and helping out with getting these issues cleared up,
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
25M 2012-10-26 14:21 firefox-16.0.2-1.fc17.x86_64.rpm
13M 2012-10-26 14:21 xulrunner-16.0.2-1.fc17.x86_64.rpm
well, to test this packages from koji a thunderbird-build
is needed if someone uses FF and TB
I've created a review request for compat-guile1.8:
Once the compat package lands in rawhide, I will leave some time for the
transition (I may work on the required patches if time allows me). After that,
guile (now version 1.8) will become 2.0.x.
I've already tried patching a few packages and there seem to be no real
problems, unlike patching the old apps for the new guile.
Software Engineer, BaseOS team Brno, Red Hat
I've built libotr3 as a compat package in rawhide and f18/f17 to prepare
for the API change between libotr-3 and libotr-4.
Applications using libotr that have not been ported to the new libotr-4
should change their Requires: libotr to Requires: libotr3, so they won't
break when libotr, now at 3.2.1 will be upgraded to 4.0.0.
If you want me to handle this for your package that uses otr, you can
add me (pwouters) as co-maintainer. I will contact the people who have
packages that depend on libotr that won't have made the changes in the
next week or so.
So the Big LVM Autopart Controversy has been kicked upstairs to FESCo:
If they say 'go with LVM', we'll have to do that.
I have no idea what FESCo will decide, but we should cover our bets
either way, I think, so it will do no harm to do some testing of the LVM
autopart stuff over the weekend rather than wait till after FESCo makes
up its mind.
So, for those doing validation testing, if you could run a few test
installs with LVM autopart and make sure everything's okay that'd be
great. There's nowhere formal to report results - just yell on the list
if you find a bug that doesn't affect ext4 autopart.
I have a couple of updates.imgs available:
http://adamwill.fedorapeople.org/updates-lvm.img against 18.19 (TC6)
http://adamwill.fedorapeople.org/updates-lvm-1821.img against 18.21
(smoke12, possibly TC7)
The first is for anaconda 18.19 - what's in TC6. The second is for
anaconda 18.21 - what's in smoke12 and would possibly be in TC7. If more
anaconda builds show up, I'll provide updates.img for them following the
same name scheme.
All you really have to do to test is use these updates.imgs and do a
regular old autopart install. Two things should happen - the install
shouldn't explode (unless you hit some unrelated bug, of course) and you
should get LVs for your system partitions (not /boot) by default, just
as you did with F17 and earlier. If you hit a problem, do test *without*
the updates.img too before pulling the fire alarm, just in case it's not
anything to do with the LVM change.
You can also test autopart-within-custom-partitioning if you like. The
button in custom part that says something like 'create partitions
automatically'. It should also give you LVM-based partitioning with this
patch. (It does for me, I checked).
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
test-announce mailing list
I have tried to contact the coq and emacs-common-proofgeneral package
maintainers directly, but have not had much luck. If any of those
maintainers can shoot me an email, that would be great.
Benjamin R Kreuter
UVA Computer Science
"If large numbers of people are interested in freedom of speech, there
will be freedom of speech, even if the law forbids it; if public
opinion is sluggish, inconvenient minorities will be persecuted, even
if laws exist to protect them." - George Orwell
I used to be annoyed by the long device names generated by LVM and didn't
see myself as needing the complexity on a desktop. Over the years, I've
found it to be more and more useful to be able to revisit partitioning
choices without a whole song-and-dance.
So, when I was installing F18 TC3 on my new laptop, I thought I'd try
setting up a custom partitioning scheme with LVM. It took me a bit to find
where I could do that (I needed to check "I don't need help", I think), but
then when I tried anaconda crashed, and then the thing to autofile a bug
crashed. Soooo, I rebooted and did it again without LVM and it didn't crash.
If that had crashed, I probably would have filed a bug. But it didn't, so I
just moved on. I *did* make a mental note to test this again in VMs when the
beta is actually released.
Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ <mattdm(a)fedoraproject.org>