Re: F16 Alpha GRUB install failure
On Thu, Aug 25, 2011 at 10:59 PM, David Lehman dleh...@redhat.com wrote: On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote: Between TC1 and release of F16 Alpha, something must have changed to the worse with regard to installing GRUB to a partition's primary sector. Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3. Anaconda now reports failure to install, and I've found this on virtual console: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partitionj. This is a BAD idea.. /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub2-setup: error: will not proceed with blocklists. Bug or feature? Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742 I did Fedora 16 Respin iso install with all latest packages, including latest Anaconda package, and still had this issue. There were two ntfs partitions (Windows 7 + data partition) and 30 GB of free space. From 30GB free space I created /root # 200 MB, ext4 /swap # 2.5 GB, swap / # 8.0 GB, ext4 /home # 19 GB, btrfs grub2 install fails miserably :( Are there any updates regarding this bug? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Fri, Aug 26, 2011 at 12:20 AM, Adam Williamson awill...@redhat.com wrote: On Thu, 2011-08-25 at 15:59 -0500, David Lehman wrote: On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote: Between TC1 and release of F16 Alpha, something must have changed to the worse with regard to installing GRUB to a partition's primary sector. Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3. Anaconda now reports failure to install, and I've found this on virtual console: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partitionj. This is a BAD idea.. /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub2-setup: error: will not proceed with blocklists. Bug or feature? Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742 Also see: https://fedoraproject.org/wiki/Common_F16_bugs#grub2-partition-fail -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net This is a really mayor but and I don't understand it why it fails when I tried grub2-install --force then grub installs without issues :( This should have been a blocker Fedora bug. -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Mon, 2012-02-13 at 14:25 -0700, Chris Murphy wrote: On Feb 13, 2012, at 9:16 AM, valent.turko...@gmail.com wrote: I did Fedora 16 Respin iso install with all latest packages, including latest Anaconda package, and still had this issue. There were two ntfs partitions (Windows 7 + data partition) and 30 GB of free space. From 30GB free space I created /root # 200 MB, ext4 /swap # 2.5 GB, swap / # 8.0 GB, ext4 /home # 19 GB, btrfs grub2 install fails miserably :( Are there any updates regarding this bug? I think the problem is GRUB2's own install script/app, doesn't do a great job of accounting for disks partitioned where the 1st partition comes less than 35KB after the MBR, and as the core.img is too large it fails to install between the MBR and partition 1. Strangely though, anaconda manages to get it to install without a complaint. No, that's clearly not the problem here, because this thread is about installing grub to the front of a partition - *not* to the MBR. I'm not sure why it's failing for Valent when it does usually manage to do this successfully, but it's definitely not the issue with the post-MBR 'embedding area' being too small. That's an entirely separate issue. anaconda only calls grub2-install, with appropriate parameters, to install grub. It doesn't do anything particularly special or clever. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Mon, 2012-02-13 at 17:21 +0100, valent.turko...@gmail.com wrote: This is a really mayor but and I don't understand it why it fails when I tried grub2-install --force then grub installs without issues :( This should have been a blocker Fedora bug. anaconda already uses grub2-install --force, and installation to a partition does not *generally* fail - it's failing in your specific case for some reason I don't know, but it's not the case that *any* attempt to install grub2 to a partition with F16 fails. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Fwd: [Bug 727814] F16 Alpha TC1 installer crash | LUKSError: luks device not configured
https://bugzilla.redhat.com/show_bug.cgi?id=727814 --- Comment #8 from Tim Flink tfl...@redhat.com 2011-09-01 13:18:54 EDT --- Discussed in the 2011-08-26 blocker review meeting. Rejected as a Fedora 16 beta blocker because it doesn't violate any of the beta release criteria [1]. Accepted as NTH because it's annoying and a fix is ready. [1] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria I don't think we should mark any installer crashes as non-blockers when there is a good chance users would hit it. I believe this particular bug should have been an Alpha blocker: The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria Whether I do or don't provide the password to my existing encrypted partitions doesn't really matter, both ways are very probable, both ways should work. At least in my opinion. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Bug 727814] F16 Alpha TC1 installer crash | LUKSError: luks device not configured
On Fri, 2 Sep 2011 02:27:15 -0400 (EDT) Kamil Paral kpa...@redhat.com wrote: https://bugzilla.redhat.com/show_bug.cgi?id=727814 --- Comment #8 from Tim Flink tfl...@redhat.com 2011-09-01 13:18:54 EDT --- Discussed in the 2011-08-26 blocker review meeting. Rejected as a Fedora 16 beta blocker because it doesn't violate any of the beta release criteria [1]. Accepted as NTH because it's annoying and a fix is ready. [1] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria I don't think we should mark any installer crashes as non-blockers when there is a good chance users would hit it. I believe this particular bug should have been an Alpha blocker: The installer must be able to complete an installation using the entire disk, existing free space, or existing Linux partitions methods, with or without encryption or LVM enabled https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria Whether I do or don't provide the password to my existing encrypted partitions doesn't really matter, both ways are very probable, both ways should work. At least in my opinion. True, both ways should work but it doesn't really seem that common of a use case since (we thought) most people would be either ignoring all of their encrypted partitions or using them. As I read it, you have to enter a password for some but not all of your encrypted partitions. The question comes down to - would this bug be worth holding up the entire alpha release until it was fixed? If it was final, maybe but not alpha, in my opinion. Looking at the logs from the blocker review meeting when we decided to make it NTH instead of blocker - it's the same thing but since a fix is available, we didn't deliberate on it too much since that would be more academic than anything. It's reported to be fixed in anaconda 16.15-1 and should be fixed. Are you still hitting it? As a side note, you don't have to actually be at the blocker bug review meeting to vote. You can go through the blocker bugs and put your vote and concerns in the bug comments - we're trying to do that more anyways. Thanks, Tim signature.asc Description: PGP signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Bug 727814] F16 Alpha TC1 installer crash | LUKSError: luks device not configured
On Fri, 2 Sep 2011 08:34:49 -0600, TF (Tim) wrote: https://bugzilla.redhat.com/show_bug.cgi?id=727814 True, both ways should work but it doesn't really seem that common of a use case since (we thought) most people would be either ignoring all of their encrypted partitions or using them. As I read it, you have to enter a password for some but not all of your encrypted partitions. My bad. I've added a comment to the ticket. Cancelling all passphrase prompts _or_ filling in just one passphrase prompt made Anaconda crash. Only way to proceed has been to answer all passphrase prompts. -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc4.git0.0.fc16.x86_64 loadavg: 0.02 0.20 0.19 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Fri, Aug 26, 2011 at 12:52 PM, Michael Schwendt mschwe...@gmail.com wrote: On Fri, 26 Aug 2011 11:47:15 -0400, TH (Tom) wrote: # grub2-install --grub-setup=/bin/true '(hd0,3)' Installation finished. No error reported. AFAIK, this won't be bootable, unless grub-install has run successfully before, because that all that the above commands are doing is populating /boot/grub2/. it's from a comment in bz 728742 With warnings telling me something is not possible, I stopped reading them again and missed the Installation finished. No error reported. at the end. It simply got lost in the noise. No line prefix for the final status message. When using --force it is too late to warn about something that is UNRELIABLE and discouraged. As I said in my earlier email, unless grub-install has run successfully (which it has in your case because you used --force), using ...--grub-setup=/bin/true... will not install grub. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Sat, 27 Aug 2011 07:50:39 -0400, TH (Tom) wrote: On Fri, 26 Aug 2011 11:47:15 -0400, TH (Tom) wrote: # grub2-install --grub-setup=/bin/true '(hd0,3)' Installation finished. No error reported. AFAIK, this won't be bootable, unless grub-install has run successfully before, because that all that the above commands are doing is populating /boot/grub2/. it's from a comment in bz 728742 With warnings telling me something is not possible, I stopped reading them again and missed the Installation finished. No error reported. at the end. It simply got lost in the noise. No line prefix for the final status message. When using --force it is too late to warn about something that is UNRELIABLE and discouraged. As I said in my earlier email, unless grub-install has run successfully (which it has in your case because you used --force), using ...--grub-setup=/bin/true... will not install grub. I didn't mean to disagree. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, Aug 24, 2011 at 16:59:22 +, Andre Robatino robat...@fedoraproject.org wrote: http://lists.fedoraproject.org/pipermail/devel/2011-August/155799.html https://bugzilla.redhat.com/show_bug.cgi?id=731617 No progress in fixing it yet. Though I see roughly the same set of broken dependencies in Rawhide, the problem does not exist there. Rawhide is broken today (and has been for a few days now), with regard to gnome-shell. You can grab the latest gnome-shell built for F16 and things work. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
Bruno Wolff III bruno at wolff.to writes: I was getting dependency errors trying to reinstall gnome-panel (which brings in gnome-shell). That problem, I DO have - gnome-panel-3.1.5-3.fc17.x86_64 is one of the packages I couldn't install, and my current version is gnome-panel-3.0.2-3.fc16.x86_64 which I can't reinstall since it's not available from the repo (though it could be gotten manually from Koji, I suppose). -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Sat, Aug 27, 2011 at 19:49:54 +, Andre Robatino robat...@fedoraproject.org wrote: Bruno Wolff III bruno at wolff.to writes: I was getting dependency errors trying to reinstall gnome-panel (which brings in gnome-shell). That problem, I DO have - gnome-panel-3.1.5-3.fc17.x86_64 is one of the packages I couldn't install, and my current version is gnome-panel-3.0.2-3.fc16.x86_64 which I can't reinstall since it's not available from the repo (though it could be gotten manually from Koji, I suppose). I was able to install gnome-panel-3.1.5-3.fc17.i686 once I had gnome-shell-3.1.4-2.gite7b9933.fc16.i686 in a local repo. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Sat, Aug 27, 2011 at 10:47 AM, Michael Schwendt mschwe...@gmail.com wrote: On Sat, 27 Aug 2011 07:50:39 -0400, TH (Tom) wrote: On Fri, 26 Aug 2011 11:47:15 -0400, TH (Tom) wrote: # grub2-install --grub-setup=/bin/true '(hd0,3)' Installation finished. No error reported. AFAIK, this won't be bootable, unless grub-install has run successfully before, because that all that the above commands are doing is populating /boot/grub2/. it's from a comment in bz 728742 With warnings telling me something is not possible, I stopped reading them again and missed the Installation finished. No error reported. at the end. It simply got lost in the noise. No line prefix for the final status message. When using --force it is too late to warn about something that is UNRELIABLE and discouraged. As I said in my earlier email, unless grub-install has run successfully (which it has in your case because you used --force), using ...--grub-setup=/bin/true... will not install grub. I didn't mean to disagree. Sorry, misunderstood you. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On 08/25/2011 08:12 PM, Jonathan Corbet wrote: I've worked my way through this kind of mess a couple of times now, most recently yesterday. Here's my experience: - Do a big rawhide update - in this case, at least two weeks worth. A bit off topic, but I would personally encourage everybody to play with the F16 tree instead of rawhide at this point. When in the past rawhide was always what you'd get as the next upcoming Fedora release, this is now slightly different. In the past, updates to rawhide would slow down significantly when nearing a new release and the repo would be frozen for weeks at a time. Now, however, rawhide is a continuously flowing repo and releases are instead made of release branches. Fedora 16 (also called 'Branched') was branched off of rawhide a month ago. Since that time, most of the developers have switched from working on rawhide to working on the F16 branch. What this means is that: - rawhide gets much less love than usual during the F16 pre-Alpha - Final stages. Quite a lot of people want to get the new release polished up as good as possible and just don't pay much attention to rawhide bugs. - The Branched tree might actually get new goodies earlier than rawhide, because this is what people are mostly concentrating on. - Bug reports and general testing of the new Branched release is very valuable, and much more important than rawhide at this point. What I personally do is that I switch to Branched when it gets branched off of rawhide and stay on there until the release is out. After that, back to the rawhide train. Everybody wins -- I get better experience, newer goodies and a warm fuzzy feeling that I'm helping out with the new release; the distro gets my help of making the release better. -- Kalev -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, 2011-08-25 at 15:15 -0700, Adam Williamson wrote: yum --setopt=protected_multilib=0 blah blah blah which might help in situations where things are already deeply sideways. worth noting for the record that, as always when using 'force' type parameters to a package management system, when it breaks - as it inevitably will - you get a full refund of what you paid for it, and you get to keep both pieces. =) generally, when yum wants to do something really funky, the solution is not 'figure out how to let yum do it' but 'figure out why yum wants to do something funky, and fix that'. (this is obviously not aimed at seth, who knows it already, but at the thread in general.) turning off them protected multilib option is not a 'force type' option. All it does is allows yum to update one pkg w/o changing or matching the the compat arch of the same pkg, too. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Thu, 25 Aug 2011 15:20:54 -0700, AW (Adam) wrote:
On Thu, 2011-08-25 at 15:59 -0500, David Lehman wrote:
On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote:
Between TC1 and release of F16 Alpha, something must have changed to the
worse with regard to installing GRUB to a partition's primary sector.
Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3.
Anaconda now reports failure to install, and I've found this on virtual
console:
/usr/sbin/grub2-setup: warn: Attempting to install GRUB to a
partitionless disk or to a partitionj. This is a BAD idea..
/usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be
installed in this setup using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
/usr/sbin/grub2-setup: error: will not proceed with blocklists.
Bug or feature?
Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742
:) One step forward, two steps back ...
Also see:
https://fedoraproject.org/wiki/Common_F16_bugs#grub2-partition-fail
Doesn't work for me.
1st, quotes are missing:
# grub2-install --force (hd0,3)
-bash: syntax error near unexpected token `('
2nd, it still refuses to install:
# grub2-install --force '(hd0,3)'
/usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk
or to a partition. This is a BAD idea..
/usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be
installed in this setup by using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
Installation finished. No error reported.
3rd, GRUB 2 %doc NEWS file mentions the partition numbering scheme
has changed to count from 1 instead of 0. The Wiki should mention that
or recommend normal /dev/sdXY notation, which also fails, however (and
which is the reason why I don't try to edit the Wiki myself):
# grub2-install --force /dev/sda3
/usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk
or to a partition. This is a BAD idea..
/usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be
installed in this setup by using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
Installation finished. No error reported.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Fri, 26 Aug 2011 17:18:56 +0200 Michael Schwendt wrote: Installation finished. No error reported. Actually, it did work. Try doing the boot. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Fri, 26 Aug 2011 17:18:56 +0200, me wrote: Doesn't work for me. # grub2-install --grub-setup=/bin/true /dev/sda3 Installation finished. No error reported. # grub2-install --grub-setup=/bin/true '(hd0,3)' Installation finished. No error reported. -- Fedora release 16 (Verne) - Linux 3.0.1-3.fc16.x86_64 loadavg: 1.67 0.82 0.31 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Fri, Aug 26, 2011 at 11:37 AM, Michael Schwendt mschwe...@gmail.com wrote: On Fri, 26 Aug 2011 17:18:56 +0200, me wrote: Doesn't work for me. # grub2-install --grub-setup=/bin/true /dev/sda3 Installation finished. No error reported. # grub2-install --grub-setup=/bin/true '(hd0,3)' Installation finished. No error reported. AFAIK, this won't be bootable, unless grub-install has run successfully before, because that all that the above commands are doing is populating /boot/grub2/. It's grub2-setup that does the heavy lifting of embedding boot.img in the PBR and pointing at core.img from boot.img. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Fri, 2011-08-26 at 17:18 +0200, Michael Schwendt wrote:
On Thu, 25 Aug 2011 15:20:54 -0700, AW (Adam) wrote:
On Thu, 2011-08-25 at 15:59 -0500, David Lehman wrote:
On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote:
Between TC1 and release of F16 Alpha, something must have changed to the
worse with regard to installing GRUB to a partition's primary sector.
Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3.
Anaconda now reports failure to install, and I've found this on virtual
console:
/usr/sbin/grub2-setup: warn: Attempting to install GRUB to a
partitionless disk or to a partitionj. This is a BAD idea..
/usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only
be
installed in this setup using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
/usr/sbin/grub2-setup: error: will not proceed with blocklists.
Bug or feature?
Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742
:) One step forward, two steps back ...
Also see:
https://fedoraproject.org/wiki/Common_F16_bugs#grub2-partition-fail
Doesn't work for me.
1st, quotes are missing:
# grub2-install --force (hd0,3)
-bash: syntax error near unexpected token `('
2nd, it still refuses to install:
# grub2-install --force '(hd0,3)'
/usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless
disk or to a partition. This is a BAD idea..
/usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be
installed in this setup by using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
Installation finished. No error reported.
It is not refusing to install. It's just warning you that it thinks what
you are telling it to do is a bad idea. Notice that it says at the end
No error reported?
3rd, GRUB 2 %doc NEWS file mentions the partition numbering scheme
has changed to count from 1 instead of 0. The Wiki should mention that
Good idea.
or recommend normal /dev/sdXY notation, which also fails, however (and
which is the reason why I don't try to edit the Wiki myself):
# grub2-install --force /dev/sda3
/usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless
disk or to a partition. This is a BAD idea..
/usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be
installed in this setup by using blocklists. However, blocklists are
UNRELIABLE and their use is discouraged..
Installation finished. No error reported.
Again, this is not a failure.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Fri, 26 Aug 2011 11:47:15 -0400, TH (Tom) wrote: # grub2-install --grub-setup=/bin/true '(hd0,3)' Installation finished. No error reported. AFAIK, this won't be bootable, unless grub-install has run successfully before, because that all that the above commands are doing is populating /boot/grub2/. it's from a comment in bz 728742 With warnings telling me something is not possible, I stopped reading them again and missed the Installation finished. No error reported. at the end. It simply got lost in the noise. No line prefix for the final status message. When using --force it is too late to warn about something that is UNRELIABLE and discouraged. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On 08/24/2011 08:11 PM, seth vidal wrote: On Wed, 2011-08-24 at 13:09 -0400, Tom Horsley wrote: On Wed, 24 Aug 2011 17:26:44 +0100 Richard Hughes wrote: I'm seriously wondering if multilib is worth all this hassle... Oh I've never wondered that: It has clearly never been a good idea. Starting with the total lack of documentation about how the heck it actually works when (for instance) multilib rpms both contain /usr/bin binaries of the same name and going through all the problems it causes with updates (like these). It is documented it is just confusing When you have two pkgs sharing the same binary path - the pkg in the preferred/compat arch for that platform has its files installed. Except when you install them in the wrong order - and then rpm will cough out a conflict. This, I think, has been fixed in more recent changes but I'm not 100% certain of that. The conflict behavior should be consistent regardless of the order since rpm = 4.6.0, ie since F10. - Panu - -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 24 Aug 2011 11:08:52 -0400 Matthias Clasen mcla...@redhat.com wrote: Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. I've worked my way through this kind of mess a couple of times now, most recently yesterday. Here's my experience: - Do a big rawhide update - in this case, at least two weeks worth. - Somewhere in the middle, while I'm not looking, the update kills the running session and/or X server - I come back to a login screen. It used to be safe to run yum update from a terminal window, but, seemingly, not anymore. Not really a step in the right direction. - If I try to rerun the update, it will tell me to try yum-complete-transaction. Each time, actually trying that leads to an infinite loop printing dependency information. - If I just run yum update, I get the protected multilib versions message. What I have found in these cases is that there are *two* versions of the indicated library installed simultaneously (for the same architecture). In each case, simply removing the older version clears the problem. Once I've gotten past the gripes, the update actually works. Dunno if that helps anybody... never a dull moment... jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, 2011-08-25 at 11:12 -0600, Jonathan Corbet wrote: On Wed, 24 Aug 2011 11:08:52 -0400 Matthias Clasen mcla...@redhat.com wrote: Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. I've worked my way through this kind of mess a couple of times now, most recently yesterday. Here's my experience: - Do a big rawhide update - in this case, at least two weeks worth. - Somewhere in the middle, while I'm not looking, the update kills the running session and/or X server - I come back to a login screen. It used to be safe to run yum update from a terminal window, but, seemingly, not anymore. Not really a step in the right direction. - If I try to rerun the update, it will tell me to try yum-complete-transaction. Each time, actually trying that leads to an infinite loop printing dependency information. - If I just run yum update, I get the protected multilib versions message. What I have found in these cases is that there are *two* versions of the indicated library installed simultaneously (for the same architecture). In each case, simply removing the older version clears the problem. Once I've gotten past the gripes, the update actually works. Dunno if that helps anybody... never a dull moment... When upgrading rawhide from X - use screen. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote: Dunno if that helps anybody... never a dull moment... When upgrading rawhide from X - use screen. and also when upgrading from ssh. things have definitely gotten a lot more fragile over the last release or two. Dave -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
Jonathan Corbet (corbet...@lwn.net) said: - Somewhere in the middle, while I'm not looking, the update kills the running session and/or X server - I come back to a login screen. It used to be safe to run yum update from a terminal window, but, seemingly, not anymore. Not really a step in the right direction. There was a bug that caused dbus to get restarted when it should not have been. I believe this is in the process of having a fix pushed. Bill -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, 2011-08-25 at 14:28 -0400, Dave Jones wrote: On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote: Dunno if that helps anybody... never a dull moment... When upgrading rawhide from X - use screen. and also when upgrading from ssh. things have definitely gotten a lot more fragile over the last release or two. you can disable the multilib protection with: yum --setopt=protected_multilib=0 blah blah blah which might help in situations where things are already deeply sideways. -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 Alpha GRUB install failure
Between TC1 and release of F16 Alpha, something must have changed to the worse with regard to installing GRUB to a partition's primary sector. Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3. Anaconda now reports failure to install, and I've found this on virtual console: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partitionj. This is a BAD idea.. /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub2-setup: error: will not proceed with blocklists. Bug or feature? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote: Between TC1 and release of F16 Alpha, something must have changed to the worse with regard to installing GRUB to a partition's primary sector. Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3. Anaconda now reports failure to install, and I've found this on virtual console: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partitionj. This is a BAD idea.. /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub2-setup: error: will not proceed with blocklists. Bug or feature? Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, 2011-08-25 at 11:12 -0600, Jonathan Corbet wrote: On Wed, 24 Aug 2011 11:08:52 -0400 Matthias Clasen mcla...@redhat.com wrote: Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. I've worked my way through this kind of mess a couple of times now, most recently yesterday. Here's my experience: - Do a big rawhide update - in this case, at least two weeks worth. - Somewhere in the middle, while I'm not looking, the update kills the running session and/or X server - I come back to a login screen. It used to be safe to run yum update from a terminal window, but, seemingly, not anymore. Not really a step in the right direction. I don't think you could say it's ever been entirely *safe*; there's always the potential that some update could do something to kill the running session, and the more complex the definition of 'running session', the more likely it is. Obviously a fat desktop on X is more complex than a VT. I can only remember it happening to me once or twice, but I'm not sure it's fair to say it's more likely now than in The Golden Past. I suspect the 'real fix' for that is to run your yum updates in a screen session. I say 'suspect' because somehow I never quite get around to learning how to use screen...but it seems like just the ticket, as it would prevent the desktop going down from killing the yum update. What I have found in these cases is that there are *two* versions of the indicated library installed simultaneously (for the same architecture). In each case, simply removing the older version clears the problem. What I'd actually recommend in that situation is doing 'rpm -e --justdb --noscripts' on the 'old versions'; that will remove the entries from RPM's database without possibly removing files that are actually part of the newer one, or running scripts, which you don't want to happen. In any case, that's not what's causing the 'protected multilib' thing people are seeing in F16 now (or were yesterday), it's just an artefact of yum trying to work around missing deps when you use --skip-broken. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Thu, 2011-08-25 at 14:55 -0400, seth vidal wrote: On Thu, 2011-08-25 at 14:28 -0400, Dave Jones wrote: On Thu, Aug 25, 2011 at 02:20:12PM -0400, seth vidal wrote: Dunno if that helps anybody... never a dull moment... When upgrading rawhide from X - use screen. and also when upgrading from ssh. things have definitely gotten a lot more fragile over the last release or two. you can disable the multilib protection with: yum --setopt=protected_multilib=0 blah blah blah which might help in situations where things are already deeply sideways. worth noting for the record that, as always when using 'force' type parameters to a package management system, when it breaks - as it inevitably will - you get a full refund of what you paid for it, and you get to keep both pieces. =) generally, when yum wants to do something really funky, the solution is not 'figure out how to let yum do it' but 'figure out why yum wants to do something funky, and fix that'. (this is obviously not aimed at seth, who knows it already, but at the thread in general.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha GRUB install failure
On Thu, 2011-08-25 at 15:59 -0500, David Lehman wrote: On Thu, 2011-08-25 at 22:56 +0200, Michael Schwendt wrote: Between TC1 and release of F16 Alpha, something must have changed to the worse with regard to installing GRUB to a partition's primary sector. Partitioning hasn't changed. TC1 managed to install GRUB to /dev/sda3. Anaconda now reports failure to install, and I've found this on virtual console: /usr/sbin/grub2-setup: warn: Attempting to install GRUB to a partitionless disk or to a partitionj. This is a BAD idea.. /usr/sbin/grub2-setup: warn: Embedding is not possible. GRUB can only be installed in this setup using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. /usr/sbin/grub2-setup: error: will not proceed with blocklists. Bug or feature? Both? https://bugzilla.redhat.com/show_bug.cgi?id=728742 Also see: https://fedoraproject.org/wiki/Common_F16_bugs#grub2-partition-fail -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 alpha: SElinux relabel at first bootup?
I've seen this with all alpha RC's and now with F16 alpha. At first bootup a selinux targeted policy label is required. Is this as designed? Jurgen -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
will be installed --- Package libgphoto2.i686 0:2.4.11-1.fc16 will be installed --- Package libgudev1.i686 0:173-1.fc16 will be installed --- Package libieee1284.i686 0:0.2.11-10.fc15 will be installed --- Package libjpeg-turbo.i686 0:1.1.1-1.fc16 will be installed --- Package libpng.i686 2:1.2.46-1.fc16 will be installed --- Package libselinux.i686 0:2.1.4-2.fc16 will be installed --- Package libstdc++.i686 0:4.6.1-7.fc16 will be installed --- Package libtasn1.i686 0:2.7-2.fc15 will be installed --- Package libthai.i686 0:0.1.14-4.fc15 will be installed --- Package libtiff.i686 0:3.9.5-1.fc16 will be installed --- Package libtool-ltdl.i686 0:2.4-6.fc16 will be installed --- Package libudev.i686 0:173-1.fc16 will be installed --- Package libusb.i686 1:0.1.3-9.fc16 will be installed --- Package libusb1.i686 0:1.0.9-0.2.git212ca37c.fc16 will be installed --- Package libv4l.i686 0:0.8.5-1.fc16 will be installed --- Package libxcb.i686 0:1.7-3.fc16 will be installed --- Package libxml2.i686 0:2.7.8-6.fc16 will be installed --- Package ncurses-libs.i686 0:5.9-2.20110716.fc16 will be installed --- Package nspr.i686 0:4.8.8-4.fc16 will be installed --- Package nss.i686 0:3.12.10-6.fc16 will be installed --- Package nss-softokn.i686 0:3.12.10-4.fc16 will be installed --- Package nss-softokn-freebl.i686 0:3.12.10-4.fc16 will be installed --- Package nss-util.i686 0:3.12.10-1.fc16 will be installed --- Package openldap.i686 0:2.4.26-1.fc16.1 will be installed --- Package pango.i686 0:1.29.3-2.fc16 will be installed --- Package pixman.i686 0:0.22.2-1.fc16 will be installed --- Package polkit.i686 0:0.101-7.fc16 will be installed --- Package readline.i686 0:6.2-2.fc16 will be installed --- Package sane-backends-libs.i686 0:1.0.22-3.fc16 will be installed --- Package sqlite.i686 0:3.7.7.1-1.fc16 will be installed --- Package zlib.i686 0:1.2.5-4.fc16 will be installed -- Finished Dependency Resolution Packages skipped because of dependency problems: 1:control-center-3.1.5-3.fc16.x86_64 from updates-testing 1:control-center-filesystem-3.1.5-3.fc16.x86_64 from updates-testing empathy-3.1.5.1-1.fc16.x86_64 from updates-testing evolution-data-server-3.1.5-2.fc16.x86_64 from updates-testing 1:folks-0.6.0-5.fc16.x86_64 from updates-testing gnome-contacts-0.1.2-2.fc16.x86_64 from updates-testing gnome-keyring-3.1.4-1.fc16.x86_64 from updates-testing gnome-keyring-pam-3.1.4-1.fc16.x86_64 from updates-testing gnome-menus-3.1.5-2.fc16.x86_64 from updates-testing gnome-panel-3.1.5-2.fc16.x86_64 from updates-testing gnome-shell-3.1.4-2.gite7b9933.fc16.x86_64 from updates-testing libsocialweb-0.25.19-1.fc16.x86_64 from fedora libsocialweb-keys-0.25.19-1.fc16.noarch from fedora p11-kit-0.3-2.fc16.x86_64 from fedora p11-kit-0.4-1.fc16.x86_64 from updates-testing Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 This is on a clean install of F16 alpha. Jurgen -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 alpha: SElinux relabel at first bootup?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/24/2011 03:55 AM, Jurgen Kramer wrote: I've seen this with all alpha RC's and now with F16 alpha. At first bootup a selinux targeted policy label is required. Is this as designed? Jurgen no. It is a bug. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5U9DMACgkQrlYvE4MpobMFYwCeIodfCbls+REJfxaKa+zOZXz5 jkoAnisQqGt9JXgpfwyOZT6si+orBJ1j =f2tI -END PGP SIGNATURE- -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote: I have not seen any mention of this on the list so far so here it goes. I've been seeing gnome dep problems for the last few days (through alpha rc's and now alpha). Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. Matthias -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On 08/24/2011 11:08 AM, Matthias Clasen wrote: On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote: I have not seen any mention of this on the list so far so here it goes. I've been seeing gnome dep problems for the last few days (through alpha rc's and now alpha). Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. Matthias from https://admin.fedoraproject.org/updates/empathy-etc, etc, etc kiilerix - 2011-08-24 10:29:37 (karma 0) oldfart: the multilib error is a combination of yum bug 728147 and an unfortunate lack of arch in many dependencies -- Regards, OldFart -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On 24 August 2011 16:08, Matthias Clasen mcla...@redhat.com wrote: Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. I'm seriously wondering if multilib is worth all this hassle... Richard -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
http://lists.fedoraproject.org/pipermail/devel/2011-August/155799.html https://bugzilla.redhat.com/show_bug.cgi?id=731617 No progress in fixing it yet. Though I see roughly the same set of broken dependencies in Rawhide, the problem does not exist there. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 24 Aug 2011 17:26:44 +0100 Richard Hughes wrote: I'm seriously wondering if multilib is worth all this hassle... Oh I've never wondered that: It has clearly never been a good idea. Starting with the total lack of documentation about how the heck it actually works when (for instance) multilib rpms both contain /usr/bin binaries of the same name and going through all the problems it causes with updates (like these). Seems to me the problem should always have been fixed by simply packaging the rpms correctly with shared noarch bits in one rpm, /lib bits in another, /lib64 bits in another, and /bin bits in yet another. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 13:09 -0400, Tom Horsley wrote: On Wed, 24 Aug 2011 17:26:44 +0100 Richard Hughes wrote: I'm seriously wondering if multilib is worth all this hassle... Oh I've never wondered that: It has clearly never been a good idea. Starting with the total lack of documentation about how the heck it actually works when (for instance) multilib rpms both contain /usr/bin binaries of the same name and going through all the problems it causes with updates (like these). It is documented it is just confusing When you have two pkgs sharing the same binary path - the pkg in the preferred/compat arch for that platform has its files installed. Except when you install them in the wrong order - and then rpm will cough out a conflict. This, I think, has been fixed in more recent changes but I'm not 100% certain of that. Seems to me the problem should always have been fixed by simply packaging the rpms correctly with shared noarch bits in one rpm, /lib bits in another, /lib64 bits in another, and /bin bits in yet another. that doesn't fix the problem, though.; -sv -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
Matthias Clasen (mcla...@redhat.com) said: On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote: I have not seen any mention of this on the list so far so here it goes. I've been seeing gnome dep problems for the last few days (through alpha rc's and now alpha). Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. That error is just a side-effect of how --skip-broken is working right now. While that can be fixed, the real problem is that not everything is rebuilt properly against the current versions of e-d-s and libgnome-keyring. Bill -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 alpha: SElinux relabel at first bootup?
On Wed, 2011-08-24 at 08:53 -0400, Daniel J Walsh wrote: On 08/24/2011 03:55 AM, Jurgen Kramer wrote: I've seen this with all alpha RC's and now with F16 alpha. At first bootup a selinux targeted policy label is required. Is this as designed? Jurgen no. It is a bug. It doesn't seem to be a general one, I didn't see that with any of my RC5 test installs. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 11:08 -0400, Matthias Clasen wrote: On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote: I have not seen any mention of this on the list so far so here it goes. I've been seeing gnome dep problems for the last few days (through alpha rc's and now alpha). Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. This particular one is just an odd artefact of --skip-broken trying to workaround the dep problems from the *non* --skip-broken run. It sometimes does some fairly odd things to try and work around the dep issues. Usually it's not worth worrying about the oddness, in this case, just focus on resolving the problems noted in the non --skip-broken run. (Which just look like the Evo update didn't hit the reporter's mirror yet). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 14:02 -0400, Bill Nottingham wrote: Matthias Clasen (mcla...@redhat.com) said: On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote: I have not seen any mention of this on the list so far so here it goes. I've been seeing gnome dep problems for the last few days (through alpha rc's and now alpha). Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. That error is just a side-effect of how --skip-broken is working right now. While that can be fixed, the real problem is that not everything is rebuilt properly against the current versions of e-d-s and libgnome-keyring. Just about everything actually is, but it was done in fits and starts and the Bodhi update edited over time, so not everything has made it to every mirror yet. If you're particularly impatient you can set up a side repo and stock it up from Koji to get the update done. That's what I did. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 12:01 -0700, Adam Williamson wrote: On Wed, 2011-08-24 at 14:02 -0400, Bill Nottingham wrote: Matthias Clasen (mcla...@redhat.com) said: On Wed, 2011-08-24 at 11:35 +0200, Jurgen Kramer wrote: I have not seen any mention of this on the list so far so here it goes. I've been seeing gnome dep problems for the last few days (through alpha rc's and now alpha). Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 I have no idea what these errors mean or how to fix them. Any advice would be appreciated. Actually, this one is kind of understandable, but I have also seen 'protected multilib' stuff where both sides of the != were the same arch, which left me wondering. That error is just a side-effect of how --skip-broken is working right now. While that can be fixed, the real problem is that not everything is rebuilt properly against the current versions of e-d-s and libgnome-keyring. Just about everything actually is, but it was done in fits and starts and the Bodhi update edited over time, so not everything has made it to every mirror yet. If you're particularly impatient you can set up a side repo and stock it up from Koji to get the update done. That's what I did. It looks like the giganto-GNOME-update needs to be combined with the e-d-s/dependencies update, too, as various bits of the giganto-GNOME update are built against the newer e-d-s. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 12:08 -0700, Adam Williamson wrote: Just about everything actually is, but it was done in fits and starts and the Bodhi update edited over time, so not everything has made it to every mirror yet. If you're particularly impatient you can set up a side repo and stock it up from Koji to get the update done. That's what I did. It looks like the giganto-GNOME-update needs to be combined with the e-d-s/dependencies update, too, as various bits of the giganto-GNOME update are built against the newer e-d-s. Everything in the gnome update has been built against the new eds. But I somewhat disagree with the notion that we need to keep sucking up more and more into this one update, making it ever harder to get any karma. Can't people just wait until their mirrors sync and install the evo update before they install the gnome update ? I mean, library deps still work as they always did ? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 16:52 -0400, Matthias Clasen wrote: On Wed, 2011-08-24 at 12:08 -0700, Adam Williamson wrote: Just about everything actually is, but it was done in fits and starts and the Bodhi update edited over time, so not everything has made it to every mirror yet. If you're particularly impatient you can set up a side repo and stock it up from Koji to get the update done. That's what I did. It looks like the giganto-GNOME-update needs to be combined with the e-d-s/dependencies update, too, as various bits of the giganto-GNOME update are built against the newer e-d-s. Everything in the gnome update has been built against the new eds. But I somewhat disagree with the notion that we need to keep sucking up more and more into this one update, making it ever harder to get any karma. Can't people just wait until their mirrors sync and install the evo update before they install the gnome update ? I mean, library deps still work as they always did ? the problem is if either update gets karma and gets pushed before the other, it puts the repo into a broken state. And since they're inter-dependent, it causes confusion like people -1ing the gnome-shell update because they don't have the packages from the e-d-s update; in a way, having them separate is making it *harder* for you to get karma. But yeah, I can see the problems with Enormo-Updates as well. I'm not sure there's a really great way to handle updating such a giant mass of inter-dependent packages, but if Luke or anyone else has any suggestions... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 17:21 -0500, Michael Cronenworth wrote: Adam Williamson wrote: more or less, each package added to the update exponentially increases the likelihood of false negative karma from someone whose local mirror doesn't have one of the packages, or who hit a really tiny bug which shouldn't be a case for a -1. The first part sounds like a mirror problem that bodhi could never solve. If a mirror doesn't have all of the RPM files how could the yum repo data it provides possibly be valid? How could bodhi solve this? It can't. Weird stuff happens to mirrors. This is all I know. =) The second part leaves me scratching my head. Minor dependencies should be just as important as large ones. If it is a dependency it needs to be linked and if it introduces bugs it should be important to fix them. I didn't say anything about dependencies. People file negative karma on stuff like 'Obscure Menu Item Z doesn't work', or 'there's a typo in the docs'. The more packages there are in an update, the more likely this is to happen, and the more likely bad negative karma will hold up 75 other packages... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
Adam Williamson wrote: I didn't say anything about dependencies. People file negative karma on stuff like 'Obscure Menu Item Z doesn't work', or 'there's a typo in the docs'. The more packages there are in an update, the more likely this is to happen, and the more likely bad negative karma will hold up 75 other packages... You kept mentioning adding more packages to updates causes problems. Typically adding packages is due to a dependency. If you're not talking about dependencies, what are you talking about? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On 08/25/2011 04:06 AM, Michael Cronenworth wrote: You kept mentioning adding more packages to updates causes problems. Typically adding packages is due to a dependency. If you're not talking about dependencies, what are you talking about? Bodhi has the ability to bundle several updates together even when they are not direct dependencies. He is referring to that Example: https://admin.fedoraproject.org/updates/kde-l10n-4.6.5-1.fc14,kdeaccessibility-4.6.5-1.fc14,kdeadmin-4.6.5-1.fc14,kdeartwork-4.6.5-1.fc14,kdebase-4.6.5-1.fc14,kdebase-runtime-4.6.5-1.fc14,kdebase-workspace-4.6.5-2.fc14,kdebindings-4.6.5-1.fc14,kdeedu-4.6.5-1.fc14,kdegames-4.6.5-1.fc14,kdegraphics-4.6.5-3.fc14,kdelibs-4.6.5-1.fc14,kdemultimedia-4.6.5-2.fc14,kdenetwork-4.6.5-1.fc14,kdepimlibs-4.6.5-1.fc14,kdeplasma-addons-4.6.5-1.fc14,kdesdk-4.6.5-1.fc14,kdetoys-4.6.5-1.fc14,kdeutils-4.6.5-2.fc14,oxygen-icon-theme-4.6.5-1.fc14 Rahul ] Rahul -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 17:36 -0500, Michael Cronenworth wrote: Adam Williamson wrote: I didn't say anything about dependencies. People file negative karma on stuff like 'Obscure Menu Item Z doesn't work', or 'there's a typo in the docs'. The more packages there are in an update, the more likely this is to happen, and the more likely bad negative karma will hold up 75 other packages... You kept mentioning adding more packages to updates causes problems. Typically adding packages is due to a dependency. If you're not talking about dependencies, what are you talking about? Um, exactly what you quoted. Larger updates tend to get more false negative feedback. That's the main problem developers cite with them. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 24 Aug 2011 15:43:59 -0700 Adam Williamson wrote: Um, exactly what you quoted. Larger updates tend to get more false negative feedback. That's the main problem developers cite with them. Then it seems like the problem is the negative feedback, not the size of the update. Maybe it should take more negative feedback to stop a large update than a small one. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
Rahul Sundaram wrote: Bodhi has the ability to bundle several updates together even when they are not direct dependencies. He is referring to that Yes, I understand Bodhi can link any group of packages together. Example: https://admin.fedoraproject.org/updates/kde-l10n-4.6.5-1.fc14,kdeaccessibility-4.6.5-1.fc14,kdeadmin-4.6.5-1.fc14,kdeartwork-4.6.5-1.fc14,kdebase-4.6.5-1.fc14,kdebase-runtime-4.6.5-1.fc14,kdebase-workspace-4.6.5-2.fc14,kdebindings-4.6.5-1.fc14,kdeedu-4.6.5-1.fc14,kdegames-4.6.5-1.fc14,kdegraphics-4.6.5-3.fc14,kdelibs-4.6.5-1.fc14,kdemultimedia-4.6.5-2.fc14,kdenetwork-4.6.5-1.fc14,kdepimlibs-4.6.5-1.fc14,kdeplasma-addons-4.6.5-1.fc14,kdesdk-4.6.5-1.fc14,kdetoys-4.6.5-1.fc14,kdeutils-4.6.5-2.fc14,oxygen-icon-theme-4.6.5-1.fc14 So there are items in this list that could be shipped in a separate update without any negative side-effects? I'm not a KDE expert, but I don't see a package that could be left off. If there are cases where package A and B are in an update and don't relate to each other and would run without crashing in separate updates then they should be in separate updates. I don't see that being the case in this thread unless I'm drinking cool-aid, which I very well might be doing. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On 08/25/2011 04:23 AM, Michael Cronenworth wrote: So there are items in this list that could be shipped in a separate update without any negative side-effects? I'm not a KDE expert, but I don't see a package that could be left off. If there are cases where package A and B are in an update and don't relate to each other and would run without crashing in separate updates then they should be in separate updates. I don't see that being the case in this thread unless I'm drinking cool-aid, which I very well might be doing. Obviously noone would try to bundle completely unrelated packages in a single update. So I am not really what you are arguing about exactly. Rahul -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
On Wed, 2011-08-24 at 17:53 -0500, Michael Cronenworth wrote: Rahul Sundaram wrote: Bodhi has the ability to bundle several updates together even when they are not direct dependencies. He is referring to that Yes, I understand Bodhi can link any group of packages together. Example: https://admin.fedoraproject.org/updates/kde-l10n-4.6.5-1.fc14,kdeaccessibility-4.6.5-1.fc14,kdeadmin-4.6.5-1.fc14,kdeartwork-4.6.5-1.fc14,kdebase-4.6.5-1.fc14,kdebase-runtime-4.6.5-1.fc14,kdebase-workspace-4.6.5-2.fc14,kdebindings-4.6.5-1.fc14,kdeedu-4.6.5-1.fc14,kdegames-4.6.5-1.fc14,kdegraphics-4.6.5-3.fc14,kdelibs-4.6.5-1.fc14,kdemultimedia-4.6.5-2.fc14,kdenetwork-4.6.5-1.fc14,kdepimlibs-4.6.5-1.fc14,kdeplasma-addons-4.6.5-1.fc14,kdesdk-4.6.5-1.fc14,kdetoys-4.6.5-1.fc14,kdeutils-4.6.5-2.fc14,oxygen-icon-theme-4.6.5-1.fc14 So there are items in this list that could be shipped in a separate update without any negative side-effects? I'm not a KDE expert, but I don't see a package that could be left off. If there are cases where package A and B are in an update and don't relate to each other and would run without crashing in separate updates then they should be in separate updates. I don't see that being the case in this thread unless I'm drinking cool-aid, which I very well might be doing. No, you're not. By all policy, the GNOME update should be one super-mega-giganto update, which it now is. We were just discussing the reasons maintainers aren't very fond of those updates. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: persistent gnome dep problems (F16 alpha rc3-5, alpha), --skip-broken wants to haul in 32-bit libs
Rahul Sundaram wrote: Obviously noone would try to bundle completely unrelated packages in a single update. So I am not really what you are arguing about exactly. Adam wanted to discuss Enormo-Updates and I think we just did. *shrugs* -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
which repos should be enabled in F16 Alpha?
It seems the Fedora repo and the Updates Testing repo, but not the Updates repo, are enabled for F16 Alpha. What is strange is that I enabled Updates (and disabled Updates-Testing) and got a bunch of different updates from what is in Updates-Testing (which currently has broken deps). /etc/yum.repos.d/fedora.repo:enabled=1 /etc/yum.repos.d/fedora.repo:enabled=0 /etc/yum.repos.d/fedora.repo:enabled=0 /etc/yum.repos.d/fedora-updates.repo:enabled=0 /etc/yum.repos.d/fedora-updates.repo:enabled=0 /etc/yum.repos.d/fedora-updates.repo:enabled=0 /etc/yum.repos.d/fedora-updates-testing.repo:enabled=1 /etc/yum.repos.d/fedora-updates-testing.repo:enabled=0 /etc/yum.repos.d/fedora-updates-testing.repo:enabled=0 I had to do this to get any Updates-Testing to install at all on x86_64: yum --skip-broken update \*.x86_64 The remaining updates that won't install are: Packages skipped because of dependency problems: 1:control-center-3.1.5-1.fc16.x86_64 from updates-testing 1:control-center-filesystem-3.1.5-1.fc16.x86_64 from updates-testing empathy-3.1.5-1.fc16.x86_64 from updates-testing evolution-3.1.5-1.fc16.x86_64 from updates-testing evolution-NetworkManager-3.1.5-1.fc16.x86_64 from updates-testing evolution-data-server-3.1.5-1.fc16.x86_64 from updates-testing 1:folks-0.6.0-2.fc16.x86_64 from updates-testing gnome-contacts-0.1.2-1.fc16.x86_64 from updates-testing gnome-keyring-3.1.4-1.fc16.x86_64 from updates-testing gnome-keyring-pam-3.1.4-1.fc16.x86_64 from updates-testing gnome-panel-3.1.5-2.fc16.x86_64 from updates-testing libsocialweb-0.25.19-1.fc16.x86_64 from fedora libsocialweb-keys-0.25.19-1.fc16.noarch from fedora 1:nautilus-sendto-3.0.0-7.fc16.x86_64 from updates-testing p11-kit-0.3-2.fc16.x86_64 from fedora Error: Protected multilib versions: gnome-panel-libs-3.1.5-2.fc16.x86_64 != gnome-panel-libs-3.0.2-3.fc16.i686 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: which repos should be enabled in F16 Alpha?
On Sun, Aug 21, 2011 at 11:57:01 -0400, Chuck Anderson c...@wpi.edu wrote: It seems the Fedora repo and the Updates Testing repo, but not the Updates repo, are enabled for F16 Alpha. What is strange is that I enabled Updates (and disabled Updates-Testing) and got a bunch of different updates from what is in Updates-Testing (which currently has broken deps). The updates repo is empty. That is normal for branched releases. Stuff goes from updates-testing into the rlease, rather than updates. There are some oddities of timing as the release doesn't get rebuilt at the same time as updates-testing. So that packages can disappear for a bit when moving from updates-testing to the release repo. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Experiences with F16/Alpha/RC4/Live
If using F16/Alpha/RC4/live for install to harddisk, (I selected an extended partition for that), the installer fails on writing bootloader to partititon, so I can't boot that installed F16. See BZ 730915). -- Joachim Backes joachim.bac...@rhrk.uni-kl.de http://www.rhrk.uni-kl.de/~backes smime.p7s Description: S/MIME Cryptographic Signature -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 alpha rc4 hangs at grub boot - BZ# 730124
I've just tried F16 alpha rc4. Installation went without a hitch but unfortunately the system still hangs when grub tries to boot. BZ# 730124. Any pointer how to get past this would be appreciated. Jurgen -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 Alpha TC4 blockdev error messages
Hi, booting the 32 Bit Gnome Live CD drops to textmode. blockdev invalid format on line 1 of table on stdin command failes Usage: blockdev -v -q . invalid format on line 1 of table on stdin command failes ln: failes to create symbolic link '/dev/root': File exists dracut Wanung: No root device live:/dev/disk/by-uudi/14fb-8f17 found Dropping to debug shell sh: can't access tty; job control turned off dracut:/# last entries from dmesg show the detection (/dev/sdc) of the usb-device he booted from and following these messages is the same dracut no root device from above. cu romal -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 alpha rc4 hangs at grub boot - BZ# 730124
On 08/16/2011 01:16 PM, Jurgen Kramer wrote: I've just tried F16 alpha rc4. Installation went without a hitch but unfortunately the system still hangs when grub tries to boot. BZ# 730124. Any pointer how to get past this would be appreciated. Jurgen If you have another installation you can boot then create a grub entry in that grub.conf for the F16 distro, boot that and then, as root: grub2-install --force /dev/your /boot partition device If you don't have another bootable distro, boot the DVD and use rescue mode and the chroot option and then do the grub2-install -- Regards, OldFart -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 Alpha RC5 incoming
Hey, folks. Just a quick heads-up to expect F16 Alpha RC5 within the next hour or two. We have the go/no-go meeting (again) tomorrow so we're really squeezed for time in validating this, if people could help out with testing that'd be great. The official announcement on test-announce will have all the details, just wanted to let everyone know it was coming. thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 Alpha RC3 USB install
Two things: 1) I used livecd-iso-to-disk to create an install USB and it worked until anaconda got to examining storage devices (bz#728883), I don't want to have to keep burning DVDs to test 2) Is there a way to activate wireless networking in anaconda? My only network connection is wireless (Belkin USB 54g) -- Fedora, Ubuntu and Slackware user Linux counter #386175 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha RC3 USB install
On 08/11/2011 08:41 PM, Timothy Davis wrote: Two things: 1) I used livecd-iso-to-disk to create an install USB and it worked until anaconda got to examining storage devices (bz#728883), I don't want to have to keep burning DVDs to test 2) Is there a way to activate wireless networking in anaconda? My only network connection is wireless (Belkin USB 54g) -- Fedora, Ubuntu and Slackware user Linux counter #386175 Oh so that could be the bug that hit me then! I also did livecd-iso-to-disk on both F15 alpha and F16. F15 worked, and F16 stopped after I picked new install. The wifi selection to report the bug however worked (but couldn't report). I hope this is helpful. Fred -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha RC3 USB install
On Thu, Aug 11, 2011 at 09:19:27PM +0800, Frederic Muller wrote: On 08/11/2011 08:41 PM, Timothy Davis wrote: Two things: 1) I used livecd-iso-to-disk to create an install USB and it worked until anaconda got to examining storage devices (bz#728883), I don't want to have to keep burning DVDs to test I tried using unetbootin and the netinstall. It progressed through formatting the partitions and choosing where to install the bootloader, then died with an unhandled exception. (This is on an Asus EEE PC 1000HE. 2) Is there a way to activate wireless networking in anaconda? My only network connection is wireless (Belkin USB 54g) In my case, it automatically activated wireless (which I didn't want) and ignored the wired. When setting the host name, there's an option to configure network, though, where you can go in and change things with the NM interface. I hate that interface and do my best to avoid it, but I realize that the fact that I don't like it doesn't mean it's bad. Sometimes though, I think it's a battle between my generation and the smartphone generation. -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Spike: If every vampire who said he was at the Crucifixion was actually there it would've been like Woodstock. I was at Woodstock. I fed off a flower person and I spent six hours watching my hand move. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha RC3 USB install
On Thu, 2011-08-11 at 10:04 -0400, Scott Robbins wrote: On Thu, Aug 11, 2011 at 09:19:27PM +0800, Frederic Muller wrote: On 08/11/2011 08:41 PM, Timothy Davis wrote: Two things: 1) I used livecd-iso-to-disk to create an install USB and it worked until anaconda got to examining storage devices (bz#728883), I don't want to have to keep burning DVDs to test I tried using unetbootin and the netinstall. It progressed through formatting the partitions and choosing where to install the bootloader, then died with an unhandled exception. (This is on an Asus EEE PC 1000HE. unetbootin is never supported for writing Fedora images; any problems you have with it, really, report to unetbootin. Writing Fedora lives to USB with dd or livecd-iso-to-disk (or livecd-creator) is supported. Writing DVD/boot.iso to USB, with either method, is...somewhat less supported, and may sometimes require special configuration. When reporting issues like this it's really important to note if you're using a USB stick, and if so, what you used to write it, and what image you actually wrote - live, DVD or boot.iso. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha RC3 USB install
On 08/11/2011 10:04 PM, Scott Robbins wrote: When setting the host name, there's an option to configure network, though, where you can go in and change things with the NM interface. I hate that interface I have to add 2 things: 1. in dual head mode (my specific configuration at least) the back/next button didn't appear on the screen 2. when configuring the wifi, the password box has no border and no blinking cursor, took me about 2 minutes to realize where to actually type the password. I believe it to be a theming issue though. -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
F16 Alpha ATI Radeon issues?
In an F16 Alpha install done via an upgrade from F15 final, I get various rendering issues in GNOME Shell, such as http://mschwendt.fedorapeople.org/tmp/screenshot-f16-alpha-damage1.png Not always, but at random times. Also: - perceived lag (compared with F15) - areas of the screen not getting refreshed in time, staying blank until I touch the window or move a GTK slider, e.g. individual mailbox subject lines in Claws Mail summary view - once, a few large black rectangular areas have appeared around an xterm window when moving it above a pair of Emacs and Firefox - lines of output in gnome-terminal and/or xterm don't appear and are displayed only when moving the window or hitting Enter once more Is anyone aware of such issues? Is it likely to be a driver issue or specific to the GNOME Shell? (dunno whether trying out a different WM would be a sufficient test) http://bugz.fedoraproject.org/xorg-x11-drv-ati lists 177 tickets. Where can I find a guide on how to report the right stuff? -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha ATI Radeon issues?
On Wed, 10 Aug 2011 13:00:34 +0200 Michael Schwendt mschwe...@gmail.com wrote: Not always, but at random times. Also: - perceived lag (compared with F15) - areas of the screen not getting refreshed in time, staying blank until I touch the window or move a GTK slider, e.g. individual mailbox subject lines in Claws Mail summary view Just FYI, I've been seeing some of this in rawhide on my Radeon for a while. Claws does seem to be especially prone to the partial update thing, but emacs shows it too. I've not had the time to even begin to track it down. I see the partial updates with the 3.0 kernel. When I run kernel-3.1.0-0.rc0.git21.1.fc17.x86_64 instead, what I see, in addition, is horrific performance. GNOME shell achieves a new level of pain there, but even fallback mode hurts. I've not had any time to try to figure out what's going on there either. jon -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha ATI Radeon issues?
On 08/10/2011 11:00 AM, Michael Schwendt wrote: In an F16 Alpha install done via an upgrade from F15 final, I get various rendering issues in GNOME Shell, such as http://mschwendt.fedorapeople.org/tmp/screenshot-f16-alpha-damage1.png Not always, but at random times. Also: - perceived lag (compared with F15) - areas of the screen not getting refreshed in time, staying blank until I touch the window or move a GTK slider, e.g. individual mailbox subject lines in Claws Mail summary view - once, a few large black rectangular areas have appeared around an xterm window when moving it above a pair of Emacs and Firefox - lines of output in gnome-terminal and/or xterm don't appear and are displayed only when moving the window or hitting Enter once more Is anyone aware of such issues? Is it likely to be a driver issue or specific to the GNOME Shell? (dunno whether trying out a different WM would be a sufficient test) http://bugz.fedoraproject.org/xorg-x11-drv-ati lists 177 tickets. Where can I find a guide on how to report the right stuff? Seeing issue here as well M880G [Mobility Radeon HD 4200] Not sure thou if it's X driver to blame or Gnome-Shell Oh and the fan is constantly on JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha ATI Radeon issues?
On Wed, 2011-08-10 at 13:00 +0200, Michael Schwendt wrote: In an F16 Alpha install done via an upgrade from F15 final, I get various rendering issues in GNOME Shell, such as http://mschwendt.fedorapeople.org/tmp/screenshot-f16-alpha-damage1.png Not always, but at random times. Also: - perceived lag (compared with F15) - areas of the screen not getting refreshed in time, staying blank until I touch the window or move a GTK slider, e.g. individual mailbox subject lines in Claws Mail summary view - once, a few large black rectangular areas have appeared around an xterm window when moving it above a pair of Emacs and Firefox - lines of output in gnome-terminal and/or xterm don't appear and are displayed only when moving the window or hitting Enter once more Is anyone aware of such issues? Is it likely to be a driver issue or specific to the GNOME Shell? (dunno whether trying out a different WM would be a sufficient test) I'm seeing similar stuff with nouveau; it seems mostly to be some kind of buffering issue, window content is not being updated when it should, and I wind up with old content still there, or apparently blank areas. Ben was of the opinion it may well be in the Shell stack somewhere (probably clutter, if I had to guess). I'm meant to test with LXDE or KDE or something to see if that 'fixes' it, but haven't got around to it yet. I haven't seen the out-and-out corruption in your first screenshot, though, so I think that's something different. http://bugz.fedoraproject.org/xorg-x11-drv-ati lists 177 tickets. Where can I find a guide on how to report the right stuff? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2011-08-12 @ 17:00 UTC - F16 Alpha Blocker Bug Review #5
# F16 Alpha Blocker Review meeting #3 # Date: 2011-08-12 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net The Fedora 16 alpha release has been pushed back a week, so we get another blocker bug review meeting for alpha! The next Fedora 16 Alpha go/no_go meeting will be on August 17 [2]. The fifth Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the Alpha release criteria [3] and should stay on the list 2. Whether they are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_processp Thanks, Tim == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the release date * If your bug is in MODIFIED ... please make sure a build with the fix exists Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * Help test Fedora 16 alpha ... https://fedoraproject.org/wiki/Category:Fedora_16_Alpha_RC_Test_Results [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2011-08-05 @ 17:00 UTC - F16 Alpha blocker bug review #4
# F16 Alpha Blocker Review meeting #4 # Date: 2011-08-05 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net Mark your calendars ... the fourth Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers this Friday. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers (also attached to this mail). We'll be reviewing the bugs to determine ... 1. whether they meet the Alpha release criteria [3] and should stay on the list 2. are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the release date * If your bug is in MODIFIED ... please make sure a build with the fix exists, and a bodhi update has been submitted Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * Help test Fedora 16 TC1 https://fedoraproject.org/wiki/Category:Fedora_16_Alpha_TC_Test_Results Thanks, James [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria == Approved Blockers == The following list of bugs are approved blockers that must be resolved. There are 6 bugs affecting 6 components. * gnome-python2 - http://bugzilla.redhat.com/show_bug.cgi?id=726743 (MODIFIED) - gnome-python2-bonobo has missing deps * lorax - http://bugzilla.redhat.com/show_bug.cgi?id=723901 (ON_QA) - pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install * lvm2 - http://bugzilla.redhat.com/show_bug.cgi?id=723144 (MODIFIED) - lvcreate not creating device nodes as needed * microcode_ctl - http://bugzilla.redhat.com/show_bug.cgi?id=690930 (ASSIGNED) - microcode_ctl loops, impossible to boot * pyorbit - http://bugzilla.redhat.com/show_bug.cgi?id=726744 (MODIFIED) - at-spi-python has broken deps * systemd - http://bugzilla.redhat.com/show_bug.cgi?id=724928 (POST) - Reboot ends with kernel panic on systemd abort() == Proposed Blockers == The following list of bugs are not yet approved to block the release. There are 10 bugs affecting 9 components. For guidance on reviewing the following bugs, refer to [[QA:SOP_blocker_bug_process]]. * NetworkManager - http://bugzilla.redhat.com/show_bug.cgi?id=727501 (ASSIGNED) - [regression] Changes to ifcfg files are not handled properly * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=723475 (NEW) - anaconda-16.12 - Unable to activate networking in anaconda (stage2) * distribution - http://bugzilla.redhat.com/show_bug.cgi?id=727401 (MODIFIED) - repoclosure failure in 16-Alpha.TC1 DVDs * distribution - http://bugzilla.redhat.com/show_bug.cgi?id=727428 (NEW) - Unable to read group information from repositories * fedora-release - http://bugzilla.redhat.com/show_bug.cgi?id=726977 (ON_QA) - fedora-release-16-0.7 not updated for Branched * gnome-session - http://bugzilla.redhat.com/show_bug.cgi?id=723160 (NEW) - Gnome-shell presents enormous warning dialog * grubby - http://bugzilla.redhat.com/show_bug.cgi?id=725185 (NEW) - grubby doesn't add the initrd line at the kernel update * kate - http://bugzilla.redhat.com/show_bug.cgi?id=727402 (MODIFIED) - fileconflicts failure in 16-Alpha.TC1 DVDs - kate/kdesdk * kde-settings - http://bugzilla.redhat.com/show_bug.cgi?id=727514 (MODIFIED) - Package Verne theming/branding for KDE * libreport - http://bugzilla.redhat.com/show_bug.cgi?id=727583 (NEW) - fileconflicts failure in 16-Alpha.TC1 DVDs - report/libreport == Approved NICE-TO-HAVE == The following list of of bugs are approved nice-to-have. Fixes for nice-to-have bugs will be accepted during the freeze. There are 0 bugs affecting 0 components. == Proposed NICE-TO-HAVE == The following list of bugs are not yet approved nice-to-have issues. Only fixes for approved nice-to-have bugs will be accepted during the freeze. There are 5 bugs affecting 2 components. For guidance on reviewing the following bugs, refer to [[QA:SOP_nth_bug_process]]. * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=727933 (ASSIGNED) - Installing onto an EFI system from an EFI USB stick fails when trying to use /boot/efi from the USB * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=727951 (ASSIGNED) - nm-connection-editors shows eth0 and Wired connection 1 * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=728007 (ASSIGNED) - EFI install fails with traceback - TypeError: '_sre.SRE_Match' object is not subscriptable
[Test-Announce] 2011-08-05 @ 17:00 UTC - F16 Alpha blocker bug review #4
# F16 Alpha Blocker Review meeting #4 # Date: 2011-08-05 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net Mark your calendars ... the fourth Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers this Friday. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers (also attached to this mail). We'll be reviewing the bugs to determine ... 1. whether they meet the Alpha release criteria [3] and should stay on the list 2. are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the release date * If your bug is in MODIFIED ... please make sure a build with the fix exists, and a bodhi update has been submitted Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * Help test Fedora 16 TC1 https://fedoraproject.org/wiki/Category:Fedora_16_Alpha_TC_Test_Results Thanks, James [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria == Approved Blockers == The following list of bugs are approved blockers that must be resolved. There are 6 bugs affecting 6 components. * gnome-python2 - http://bugzilla.redhat.com/show_bug.cgi?id=726743 (MODIFIED) - gnome-python2-bonobo has missing deps * lorax - http://bugzilla.redhat.com/show_bug.cgi?id=723901 (ON_QA) - pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install * lvm2 - http://bugzilla.redhat.com/show_bug.cgi?id=723144 (MODIFIED) - lvcreate not creating device nodes as needed * microcode_ctl - http://bugzilla.redhat.com/show_bug.cgi?id=690930 (ASSIGNED) - microcode_ctl loops, impossible to boot * pyorbit - http://bugzilla.redhat.com/show_bug.cgi?id=726744 (MODIFIED) - at-spi-python has broken deps * systemd - http://bugzilla.redhat.com/show_bug.cgi?id=724928 (POST) - Reboot ends with kernel panic on systemd abort() == Proposed Blockers == The following list of bugs are not yet approved to block the release. There are 10 bugs affecting 9 components. For guidance on reviewing the following bugs, refer to [[QA:SOP_blocker_bug_process]]. * NetworkManager - http://bugzilla.redhat.com/show_bug.cgi?id=727501 (ASSIGNED) - [regression] Changes to ifcfg files are not handled properly * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=723475 (NEW) - anaconda-16.12 - Unable to activate networking in anaconda (stage2) * distribution - http://bugzilla.redhat.com/show_bug.cgi?id=727401 (MODIFIED) - repoclosure failure in 16-Alpha.TC1 DVDs * distribution - http://bugzilla.redhat.com/show_bug.cgi?id=727428 (NEW) - Unable to read group information from repositories * fedora-release - http://bugzilla.redhat.com/show_bug.cgi?id=726977 (ON_QA) - fedora-release-16-0.7 not updated for Branched * gnome-session - http://bugzilla.redhat.com/show_bug.cgi?id=723160 (NEW) - Gnome-shell presents enormous warning dialog * grubby - http://bugzilla.redhat.com/show_bug.cgi?id=725185 (NEW) - grubby doesn't add the initrd line at the kernel update * kate - http://bugzilla.redhat.com/show_bug.cgi?id=727402 (MODIFIED) - fileconflicts failure in 16-Alpha.TC1 DVDs - kate/kdesdk * kde-settings - http://bugzilla.redhat.com/show_bug.cgi?id=727514 (MODIFIED) - Package Verne theming/branding for KDE * libreport - http://bugzilla.redhat.com/show_bug.cgi?id=727583 (NEW) - fileconflicts failure in 16-Alpha.TC1 DVDs - report/libreport == Approved NICE-TO-HAVE == The following list of of bugs are approved nice-to-have. Fixes for nice-to-have bugs will be accepted during the freeze. There are 0 bugs affecting 0 components. == Proposed NICE-TO-HAVE == The following list of bugs are not yet approved nice-to-have issues. Only fixes for approved nice-to-have bugs will be accepted during the freeze. There are 5 bugs affecting 2 components. For guidance on reviewing the following bugs, refer to [[QA:SOP_nth_bug_process]]. * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=727933 (ASSIGNED) - Installing onto an EFI system from an EFI USB stick fails when trying to use /boot/efi from the USB * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=727951 (ASSIGNED) - nm-connection-editors shows eth0 and Wired connection 1 * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=728007 (ASSIGNED) - EFI install fails with traceback - TypeError: '_sre.SRE_Match' object is not subscriptable
F16 Alpha
Downloaded the x86_64 iso and wrote it to a jump drive with Live USB creator. Was unable to install from this image. Better luck was had with a dvd-rw. The basic storage checker throws an unhandled exception apparently when it sees sda. Sda contains several bootable systems. I got past that by using specialized storage devices and installing to a different drive. Both desktop and development choices failed dependency tests. I was able to do a minimal install. No network, no X. Not too useful. A bit of local testing might be in order before the next alpha spin. -- Chuck Forsberg WA7KGX N2469R c...@omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc The High Reliability Software 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: F16 Alpha
on 08/02/2011 10:01 PM, Chuck Forsberg WA7KGX N2469R wrote: The basic storage checker throws an unhandled exception apparently when it sees sda. Sda contains several bootable systems. I may have same problem. In my case anaconda crashes after host name setup menu. I used empty ext4 formatted disk. Anyway, I filled a bug report for this. https://bugzilla.redhat.com/show_bug.cgi?id=727573 Cheers, -- /* * Masami Ichikawa * gmail: masami...@gmail.com * Fedora project: mas...@fedoraproject.org */ -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
2011-07-29 - F16 Alpha blocker bug review #3 - recap
Minutes: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-29/f16-alpha-blocker-review.2011-07-29-17.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-29/f16-alpha-blocker-review.2011-07-29-17.00.txt Log: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-29/f16-alpha-blocker-review.2011-07-29-17.00.log.html #fedora-bugzappers: F16-Alpha-blocker-review Meeting summary --- * Roll Call (jlaska, 17:00:22) * Why are we here? (jlaska, 17:03:21) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (jlaska, 17:03:48) * LINK: https://fedoraproject.org/wiki/Current_Release_Blockers (jlaska, 17:04:02) * LINK: https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria (jlaska, 17:04:29) * LINK: http://bugzilla.redhat.com/show_bug.cgi?id=723475 (jlaska, 17:06:04) * anaconda-16.12 - Unable to activate networking in anaconda (stage2) (jlaska, 17:06:09) * AGREED: 723475 - pending updated testing from TC1, issue may have magically fixed itself (jlaska, 17:11:29) * will address additional possible bugs when TC1 arrives (jlaska, 17:11:44) * http://bugzilla.redhat.com/show_bug.cgi?id=726744 (jlaska, 17:12:17) * at-spi-python has broken deps (jlaska, 17:12:22) * AGREED: 726744 - AcceptedBlocker for Alpha - impacts Alpha repoclosure criteria and preventing ISO compose (jlaska, 17:14:39) * http://bugzilla.redhat.com/show_bug.cgi?id=723526 (jlaska, 17:14:46) * firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot (jlaska, 17:14:51) * firstboot-16.1-2.fc16 destined for TC1 compose ... should resolve this issue (jlaska, 17:18:09) * AGREED: 723526 - Move to VERIFIED, leave open pending TC1 branch compose (jlaska, 17:18:14) * http://bugzilla.redhat.com/show_bug.cgi?id=725566 (jlaska, 17:18:21) * firstboot doesn't default to enabled after rawhide/F16 install (jlaska, 17:18:25) * impacts alpha criteria - In most cases (see Blocker_Bug_FAQ), a system installed according to any of the above criteria (or the appropriate Beta or Final criteria, when applying this criterion to those releases) must boot to the 'firstboot' utility on the first boot after installation, without unintended user intervention. This includes correctly accessing any encrypted partitions when the correct passphrase is supplied. The (jlaska, 17:20:07) * AGREED: 725566 - AcceptedBlocker for Alpha - impacts Alpha firstboot criteria, fix VERIFIED, will move to CLOSED when TC1 arrives (jlaska, 17:21:33) * http://bugzilla.redhat.com/show_bug.cgi?id=725040 (jlaska, 17:21:39) * rawhide installs generic-release package, instead of fedora-release (jlaska, 17:21:44) * AGREED: 725040 - move to VERIFIED, will move to CLOSED pending TC1. Unclear impact on Alpha, but a valid rawhide fix (jlaska, 17:25:09) * while the impact to the Alpha isn't fully understood ... since the issue is resolved the group decided acceptance as a blocker isn't required (jlaska, 17:26:17) * http://bugzilla.redhat.com/show_bug.cgi?id=726743 (jlaska, 17:26:22) * gnome-python2-bonobo has missing deps (jlaska, 17:26:26) * Alpha criteria affected - There must be no file conflicts (cases where the files in some packages conflict but the packages have explicit Conflicts: tags are acceptable) or unresolved package dependencies during a media-based (DVD) install (jlaska, 17:27:29) * AGREED: 726743 - AcceptedBlocker for Alpha - preventing ISO creation (jlaska, 17:28:20) * ACTION: adamw [was] volunteered to contact desktop@ regarding 726743 (jlaska, 17:28:57) * http://bugzilla.redhat.com/show_bug.cgi?id=723160 (jlaska, 17:29:01) * Gnome-shell presents enormous warning dialog (jlaska, 17:29:06) * if we can't get a reliable reproducer of some kind, we nack it as a blocker (jlaska, 17:42:14) * AGREED: 723160 - Unable to determine full impact, leave in proposed pending additional testing to isolate failure scenario (jlaska, 17:42:21) * http://bugzilla.redhat.com/show_bug.cgi?id=711489 (jlaska, 17:42:29) * atl1c: transmit queue timeout (ASUS 522) (jlaska, 17:42:33) * AGREED: 711489 - RejectedBlocker - nasty, but impacts limited hardware and has a workaround. May re-evaluate if new information surfaces (jlaska, 17:48:14) * http://bugzilla.redhat.com/show_bug.cgi?id=723901 (jlaska, 17:48:34) * pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install (jlaska, 17:48:38) * AGREED: 723901 - AcceptedBlocker for Alpha based on perceived impact to branched composes - fix available, pending TC1 testing (jlaska, 17:52:20) * http://bugzilla.redhat.com/show_bug.cgi?id=724928 (jlaska, 17:52:30) * Reboot ends with kernel panic on systemd abort
[Test-Announce] 2011-07-29 @ 17:00 UTC - F16 Alpha blocker bug review #3
# F16 Alpha Blocker Review meeting #3 # Date: 2011-07-29 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net It's once again time for everyone's favorite activity - blocker bug review meeting time !! Fedora 16 has branched and the first Alpha test composes should be arriving shortly and Fedora 16 Alpha is coming up fast (Aug 10 for go/no_go meeting) [2]. The third Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the Alpha release criteria [3] and should stay on the list 2. Whether they are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_processp Thanks, Tim == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the release date * If your bug is in MODIFIED ... please make sure a build with the fix exists Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * Help test rawhide ... https://fedoraproject.org/wiki/Category:Fedora_16_Pre-Alpha_Test_Results [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
2011-07-22 - F16 Alpha blocker bug review #2 - recap
Minutes: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-22/f16-blocker-review.2011-07-22-17.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-22/f16-blocker-review.2011-07-22-17.00.txt Log: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-22/f16-blocker-review.2011-07-22-17.00.log.html Meeting summary --- * Roll Call (jlaska, 17:00:17) * Basic information (jlaska, 17:03:23) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (jlaska, 17:03:26) * LINK: https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria (jlaska, 17:03:30) * LINK: https://fedoraproject.org/wiki/Current_Release_Blockers (jlaska, 17:03:35) * http://bugzilla.redhat.com/show_bug.cgi?id=722963 (jlaska, 17:05:36) * TypeError: %d format: a number is required, not str (jlaska, 17:05:46) * AGREED: 722963 - AcceptedBlocker for F16Final - appears to involve manual partition scenarios where the partition is not within the size limits for the format selected (jlaska, 17:11:31) * Patch out for review on anaconda-devel, likely will be fixed well before F16Final (jlaska, 17:11:45) * http://bugzilla.redhat.com/show_bug.cgi?id=723144 (jlaska, 17:12:03) * anaconda 16.12 crashed after the partition process (jlaska, 17:12:09) * ACTION: jlaska will propose rewording Alpha release criteria for paritioning to include [X] Use LVM? (jlaska, 17:14:34) * AGREED: 723144 - AcceptedBlocker - Impacts default partition scenario and Alpha partition criteria (jlaska, 17:15:42) * https://bugzilla.redhat.com/show_bug.cgi?id=723345 (jlaska, 17:16:35) * Rescue mode fails - TypeError: progressWindow() takes exactly 4 arguments (6 given) (jlaska, 17:16:40) * affects the Alpha criteria - The rescue mode of the installer must start successfully and be able to detect and mount an existing default installation (jlaska, 17:16:51) * AGREED: 723345 - AcceptedBlocker for F16Alpha - impacts rescue mode Alpha criteria (jlaska, 17:18:36) * Already fixed in anaconda-16.13-1 (jlaska, 17:18:57) * http://bugzilla.redhat.com/show_bug.cgi?id=723475 (jlaska, 17:19:09) * anaconda-16.12 - Unable to activate networking in anaconda (stage2) (jlaska, 17:19:15) * group debated whether workaround of booting with asknetwork is acceptable for Alpha (jlaska, 17:32:22) * AGREED: 723475 - unable to determine if workaround is acceptable for Alpha, review blocker status again next week with more details on failure (jlaska, 17:40:40) * http://bugzilla.redhat.com/show_bug.cgi?id=725040 (jlaska, 17:41:17) * rawhide installs generic-release package, instead of fedora-release (jlaska, 17:41:21) * AGREED: 725040 - AcceptedNTH for F16Alpha - leave on proposed blocker list until we can confirm this does not impact artwork (jlaska, 17:54:58) * adamw noted this bug may impact more than just artwork ... further investigation needed (jlaska, 17:56:15) * http://bugzilla.redhat.com/show_bug.cgi?id=723526 (jlaska, 17:56:27) * firstboot always runs even with RUN_FIRSTBOOT=NO in /etc/sysconfig/firstboot (jlaska, 17:56:40) * AGREED: 723526 - Need more information to confirm whether bug exists after a *fresh* install (jlaska, 18:03:40) * ACTION: need confirmation whether firstboot is activated after a *fresh* install (jlaska, 18:03:55) * http://bugzilla.redhat.com/show_bug.cgi?id=718722 (jlaska, 18:04:16) * Mismatched or corrupt version of stage1/stage2 (jlaska, 18:04:21) * AGREED: 718722 - AcceptedBlocker for F16Beta, CommonBugs? - only impacts upgrades from F15 which is covered by beta criteria (jlaska, 18:09:51) * pjones plans to investigate and we'll revisit if the severity increases (jlaska, 18:11:11) * https://bugzilla.redhat.com/show_bug.cgi?id=723901 (jlaska, 18:11:14) * pre-release anaconda compose is disabling 'rawhide' repo ... leaves no repos available for install (jlaska, 18:11:19) * likely related to generic-release vs fedora-release troubles (jlaska, 18:19:27) * AGREED: 723901 - revisit next meeting - impacts rawhide installs now, but unclear whether this will affect Branched (f16) media installs too (jlaska, 18:21:12) * http://bugzilla.redhat.com/show_bug.cgi?id=690930 (jlaska, 18:21:23) * microcode_ctl loops, impossible to boot (jlaska, 18:21:34) * LINK: http://yum.baseurl.org/wiki/CompareProviders -- jlaska might want to add this to info for the previous bug (pjones, 18:23:57) * AGREED: 690930 - AcceptedBlocker - bootable AMD systems favored over intel microcode update support for Alpha ... if no fix available, re-apply broken fix to allow AMD systems to boot (jlaska, 18:29:00) * http://bugzilla.redhat.com/show_bug.cgi?id=720034 (jlaska, 18:30:43) * AGREED: 720034 - request updated status in bug and revisit/retest before next meeting (jlaska, 18:33:56) *
[Test-Announce] 2011-07-22 @ 17:00 UTC - F16 Alpha blocker bug review #2
# F16 Alpha Blocker Review meeting #2 # Date: 2011-07-22 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net !!! ALL-CAPS RED-ALERT OMG LOL !!! Fedora 16 Alpha test compose is less than *one* week away (Jul 26) and F16 Alpha isn't far behind (Aug 10 for go/no_go meeting) [2]. This is the difficult transition from the chaos of rawhide, to a releasable Alpha. To have any hope of shipping F16 Alpha on time ... we need to identify as many Alpha criteria [3] blockers as possible, which means rawhide test feedback is needed. !!! ALL-CAPS RED-ALERT OMG LOL !!! Mark your calendars ... the second Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers (also attached to this mail). We'll be reviewing the bugs to determine ... 1. whether they meet the Alpha release criteria [3] and should stay on the list 2. are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the release date * If your bug is in MODIFIED ... please make sure a build with the fix exists Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * Help test rawhide ... https://fedoraproject.org/wiki/Category:Fedora_16_Pre-Alpha_Test_Results [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria Thanks, James == Approved Blockers == The following list of bugs are approved blockers that must be resolved. There are 2 bugs affecting 2 components. * glibc - http://bugzilla.redhat.com/show_bug.cgi?id=720034 (NEW) - Error: unsupported locale setting * kernel - http://bugzilla.redhat.com/show_bug.cgi?id=714478 (NEW) - CPU lockup during boot == Proposed Blockers == The following list of bugs are not yet approved to block the release. There are 8 bugs affecting 5 components. For guidance on reviewing the following bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process * abrt - http://bugzilla.redhat.com/show_bug.cgi?id=723376 (NEW) - Package abrt-plugin-bugzilla is obsoleted by libreport-plugin-bugzilla, but obsoleting package does not provide for requirements * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=722963 (POST) - TypeError: %d format: a number is required, not str * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=723144 (ASSIGNED) - anaconda 16.12 crashed after the partition process * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=723345 (MODIFIED) - Rescue mode fails - TypeError: progressWindow() takes exactly 4 arguments (6 given) * anaconda - http://bugzilla.redhat.com/show_bug.cgi?id=723475 (NEW) - anaconda-16.12 - Unable to activate networking in anaconda (stage2) * grub - http://bugzilla.redhat.com/show_bug.cgi?id=718722 (NEW) - Mismatched or corrupt version of stage1/stage2 * microcode_ctl - http://bugzilla.redhat.com/show_bug.cgi?id=690930 (ASSIGNED) - microcode_ctl loops, impossible to boot * report - http://bugzilla.redhat.com/show_bug.cgi?id=723320 (NEW) - file conflicts: file /usr/lib64/python2.7/site-packages/report/__init__.py conflicts between attempted installs of report-0.23-0.fc16.x86_64 and libreport-python-2.0.5-1.fc16.x86_64 == Approved NICE-TO-HAVE == The following list of of bugs are approved nice-to-have. Fixes for nice-to-have bugs will be accepted during the freeze. There are 0 bugs affecting 0 components. == Proposed NICE-TO-HAVE == The following list of bugs are not yet approved nice-to-have issues. Only fixes for approved nice-to-have bugs will be accepted during the freeze. There are 0 bugs affecting 0 components. For guidance on reviewing the following bugs, refer to https://fedoraproject.org/wiki/QA:SOP_nth_bug_process signature.asc Description: This is a digitally signed message part ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1 - REMINDER
- Original Message - # F16 Alpha Blocker Review meeting #1 # Date: 2011-07-15 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net Just a reminder that the first Fedora 16 Alpha blocker bug review meeting starts in under 1 hour. Come join us in #fedora-bugzappers to expedite reviews, or comment in any bugs prior to the meeting. https://fedoraproject.org/wiki/Current_Release_Blockers Thanks, James Hard to believe, but the vacation is over. Fedora 16 Alpha test compose is a few weeks away (Jul 26) and the Alpha is about a month away (Aug 10 for go/no_go meeting). In an effort to reduce last minute bug scramble, the blocker review meetings will be starting up again [2]. Each Friday, between now and the Alpha release, a blocker review will take place in #fedora-bugzappers. Mark your calendars ... the first Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers (also attached to this mail). We'll be reviewing the bugs to determine ... 1. whether they meet the Alpha release criteria [3] and should stay on the list 2. are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the F16 Alpha release date * If your bug is in MODIFIED ... please make sure a build with the fix exists, and is available as a bodhi update. Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * If a bug is in ON_QA ... please take a moment to apply the update, and post karma feedback (doesn't apply to rawhide at the moment) [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria Thanks, James -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
2011-07-15 - F16 Alpha blocker bug review #1 - recap
#fedora-bugzappers: F16-Alpha Blocker Review Minutes: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-15/f16-alpha-blocker.2011-07-15-17.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-15/f16-alpha-blocker.2011-07-15-17.00.txt Log: http://meetbot.fedoraproject.org/fedora-bugzappers/2011-07-15/f16-alpha-blocker.2011-07-15-17.00.log.html Meeting summary --- * Roll Call (jlaska, 17:01:06) * Why are we here? (jlaska, 17:04:09) * We'll be walking through the proposed, accepted blockers and NTH bugs listed at http://fedoraproject.org/wiki/Current_Release_Blockers (jlaska, 17:04:34) * LINK: http://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria (jlaska, 17:04:46) * LINK: http://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (jlaska, 17:05:05) * All proposed systemd Alpha blockers (jlaska, 17:06:06) * LINK: http://lists.fedoraproject.org/pipermail/test/2011-July/101332.html (jlaska, 17:07:04) * AGREED: all the sysv-to-systemd conversion bugs should not be handled by the release blocker review process but the feature process, so 713562 is rejected as a blocker (adamw, 17:09:39) * https://bugzilla.redhat.com/show_bug.cgi?id=714478 (jlaska, 17:14:38) * CPU lockup during boot (jlaska, 17:14:54) * The fix has been posted to lkml, but is not yet in Linus' tree. (jlaska, 17:17:12) * AGREED: 714478 - AcceptedBlocker - causes boot failures for i686 kernel (jlaska, 17:22:23) * https://bugzilla.redhat.com/show_bug.cgi?id=718722 (jlaska, 17:22:47) * Mismatched or corrupt version of stage1/stage2 (jlaska, 17:22:54) * LINK: http://fedoraproject.org/wiki/Features/Grub2 (brunowolff, 17:27:57) * AGREED: 718722 - leave on the list pending rawhide acceptance install results. Will reevaluate next week (jlaska, 17:28:10) * https://bugzilla.redhat.com/show_bug.cgi?id=720034 (jlaska, 17:28:20) * unsupported locale setting (jlaska, 17:28:31) * ACTION: jlaska - check-in w/ pjones for grub assistance on 718722 (jlaska, 17:29:22) * impacts Alpha criteria - The installer must boot (if appropriate) and run on all primary architectures from default live image, DVD, and boot.iso install media (jlaska, 17:30:52) * AGREED: 720034 - AcceptedBlocker - appears to prevent all live installs (jlaska, 17:31:20) * https://bugzilla.redhat.com/show_bug.cgi?id=722466 (jlaska, 17:31:38) * creating 32 bit isos fails when there is 2 kernels (jlaska, 17:31:44) * AGREED: 722466 RejectedBlocker - Does not prevent Alpha installs and can be manually installed after anaconda. May consider as a F16Blocker (jlaska, 17:38:08) * Open Discussion - your bug here (jlaska, 17:40:57) * discussion on reducing blocker meeting length (jlaska, 17:43:37) * LINK: https://fedorahosted.org/fedora-qa/ticket/221 (jlaska, 17:43:49) * Still searching for ways to reduce blocker meeting length (jlaska, 17:51:49) * Open Discussion - last call (jlaska, 18:02:11) Meeting ended at 18:03:32 UTC. Action Items * jlaska - check-in w/ pjones for grub assistance on 718722 Action Items, by person --- * jlaska * jlaska - check-in w/ pjones for grub assistance on 718722 * **UNASSIGNED** * (none) People Present (lines said) --- * jlaska (157) * adamw (59) * tflink (41) * Viking-Ice (41) * brunowolff (34) * j_dulaney (33) * rbergeron (8) * buggbot (5) * zodbot (4) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Wed, 2011-07-13 at 20:58 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 08:11 PM, James Laska wrote: Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? It's the one held on 15 June. See this thread on -devel [1] also note that FESCO accepted the feature [2] on the bases that native systemd unit files will be accepted up to beta after that no more native systemd service files will be introduced in the release during it's lifetime. Developers will need to convert the old sysvinit init scripts to native systemd ones and/or review and use ones that have been provided to them and package them as per packaging guidelines which can be found here http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd with sample scriptlet snippet which can be found here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd no later then beta for inclusions in the release. 1.http://lists.fedoraproject.org/pipermail/devel/2011-June/152780.html 2.http://fedoraproject.org/wiki/Features/SysVtoSystemd Thanks, that's all I could find too. I don't read that as meaning anything sysvinit-systemd gets a free ride as an automatic blocker. I read that as FESCO has approved the sysvinit-systemd feature to continue developing beyond the feature freeze. Thanks, James signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Wed, 2011-07-13 at 18:36 -0700, Adam Williamson wrote: On Wed, 2011-07-13 at 19:25 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 07:17 PM, James Laska wrote: Your ideas are consistent with how we've handled this before, I don't think I could have articulated nearly as well though:) My understanding is that FESCO is the right place to discuss whether a feature should block a release or not. They already did and decided that what's on core + base + base-x would become alpha blockers which later got extended to included services we ship on the live cd. I think we could still talk to them about tweaking that process, though. I could easily be misinterpreted here, so I'll try to be precise... We've set up this whole blocker bug process that works quite smoothly to achieve what it sets out to achieve: validate the quality of the release. We have the release criteria and the blocker bug SOP and the system of bugs and meetings to carry it all out. That's great. Ultimately what the process achieves is QA's sign-off on the release: if there are no blocker bugs we say 'this release meets Fedora's quality standards'. Now, it should always be true that if there are any blocker bugs, the release cannot go out. *But*, crucially, the converse is not true: it is not inevitably be the case that if there are _no_ blocker bugs, the release _must_ go out. All it means is that we - the QA group - sign off on the release and say as far as we're concerned, it's okay to go out. QA isn't the *only* group that signs off on releases. FESCo does too. As I see it, it'd be perfectly fine for FESCo to say 'well, even though it meets all the quality standards, we do not want to sign off on this release until Feature X is done'. As I see it, that's a _separate_ process from the blocker bug / release validation process. FESCo does not need to use the blocker bug process to manage its decision to sign off on the release, and I think it would actually be better if they didn't. I'm dancing on pin heads here to some extent - the practical result is going to be the same whether we use the blocker process to manage FESCo's decisions on the feature process or whether we decide to come up with a different process for that - but I think it helps to have processes that are clearly and strictly defined: I think if we use blocker bugs to manage some specific aspect of the feature process, it dilutes both processes. I fully agree. The net result is the same, I just don't think we should start tracking incomplete features as blocker bugs. I think it'd actually work out better if there were a separate mechanism by which FESCo managed its choice of whether or not to sign off on the release due to issues in the feature process. Thoughts? Should I talk to FESCo about this? Might be good to raise awareness, so they know we don't plan to automatically accept any features (delayed or approved) as blocker bugs. We do list a goal for the Alpha to Test accepted features of Fedora 16. While that may on the face seem to indicate we should hold the release for all accepted features, I believe we intentionally listed this as a goal, and not a requirement. To fit this into our existing criteria vernacular, I would probably suggest that FESCO agrees to delay acceptance of the SysVinit-systemd feature until after Alpha. Acceptance would be revisited after Alpha and would pertain only to the proposed livecd scope. If the proposed changes are completed at that time, the feature would be accepted. Anyway, like you said, semantics. I'm just trying to make sure we're true to our criteria. Long story short, I agree it makes sense to keep this separate from the blocker process. Thanks, James signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/14/2011 11:16 AM, James Laska wrote: On Wed, 2011-07-13 at 20:58 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 08:11 PM, James Laska wrote: Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? It's the one held on 15 June. See this thread on -devel [1] also note that FESCO accepted the feature [2] on the bases that native systemd unit files will be accepted up to beta after that no more native systemd service files will be introduced in the release during it's lifetime. Developers will need to convert the old sysvinit init scripts to native systemd ones and/or review and use ones that have been provided to them and package them as per packaging guidelines which can be found here http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd with sample scriptlet snippet which can be found here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd no later then beta for inclusions in the release. 1.http://lists.fedoraproject.org/pipermail/devel/2011-June/152780.html 2.http://fedoraproject.org/wiki/Features/SysVtoSystemd Thanks, that's all I could find too. I don't read that as meaning anything sysvinit-systemd gets a free ride as an automatic blocker. I read that as FESCO has approved the sysvinit-systemd feature to continue developing beyond the feature freeze. I never said it was a blocker what I said was that it was aggreed to that service in +core + base + base -X plus what service are on the live cd would be alpha blockers see the meeting logs and the the thread on devel for that discussion. Once we are passed alpha I will do assessment on the conversion process and discuss with Fesco what ( if any ) next goal should be ( potential beta blockers ) . JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/14/2011 11:28 AM, James Laska wrote: Long story short, I agree it makes sense to keep this separate from the blocker process. Agreed as well The sysv to systemd feature is a special case and should not be mixed into the standard QA workflow. The QA community should be aware of how important that it is that we convert and ship as many native systemd unit in one release cycle and potential issues we have to deal with if we dont and should perhaps help things move along anyway that said it's up to Fesco to evaluate on per sysv legacy init script bases when the time comes if they should be blockers or not since there might be substantial code writing/rework that needs to be done to properly integrate that service to systemd which for example might be the case with Audit. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Thu, 2011-07-14 at 11:31 +, Jóhann B. Guðmundsson wrote: On 07/14/2011 11:16 AM, James Laska wrote: On Wed, 2011-07-13 at 20:58 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 08:11 PM, James Laska wrote: Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? It's the one held on 15 June. See this thread on -devel [1] also note that FESCO accepted the feature [2] on the bases that native systemd unit files will be accepted up to beta after that no more native systemd service files will be introduced in the release during it's lifetime. Developers will need to convert the old sysvinit init scripts to native systemd ones and/or review and use ones that have been provided to them and package them as per packaging guidelines which can be found here http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd with sample scriptlet snippet which can be found here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd no later then beta for inclusions in the release. 1.http://lists.fedoraproject.org/pipermail/devel/2011-June/152780.html 2.http://fedoraproject.org/wiki/Features/SysVtoSystemd Thanks, that's all I could find too. I don't read that as meaning anything sysvinit-systemd gets a free ride as an automatic blocker. I read that as FESCO has approved the sysvinit-systemd feature to continue developing beyond the feature freeze. I never said it was a blocker what I said was that it was aggreed to that service in +core + base + base -X plus what service are on the live cd would be alpha blockers see the meeting logs and the the thread on devel for that discussion. Perhaps I'm misinterpreting your use of the word blocker. Regardless, it sounds like we are all in agreement. We are concluding that they won't be considered as blocker *bugs* (alpha or otherwise). Unless of course the absence, or presence, of the updated systemd script does somehow cause any of the Alpha criteria to fail. They won't be considered blocker bugs, but FESCO has the right to delay release of any milestone (alpha, beta or final) should they decide a late/inprogress feature is a must for a particular milestone. Once we are passed alpha I will do assessment on the conversion process and discuss with Fesco what ( if any ) next goal should be ( potential beta blockers ) . To make sure I'm understanding, do you mean the next goal would be to determine the status of the SysV-systemd feature and whether it will be on track for a Beta TC1 target? If it isn't ... FESCO must decide whether to hold the release, or drop the feature. Thanks, James signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/14/2011 12:11 PM, James Laska wrote: To make sure I'm understanding, do you mean the next goal would be to determine the status of the SysV-systemd feature and whether it will be on track for a Beta TC1 target? If it isn't ... FESCO must decide whether to hold the release, or drop the feature. Think more of it in milestone such as number of @groups have not been completely converted and or all legacy sysv init script we ship on the DVD or the milestone of converting every sysv init scripts etc... and Fesco deciding if it will hold off the release or rather the beta release since no unit files will be introduced into the release after beta. This feature wont be dropped per say but rather moved into next release and the work continued from there converting what we did not manage to convert during this release cycle. This feature is of completely different nature and magnitude then introducing a new component into the release. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
[Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
# F16 Alpha Blocker Review meeting #1 # Date: 2011-07-15 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net Hard to believe, but the vacation is over. Fedora 16 Alpha test compose is a few weeks away (Jul 26) and the Alpha is about a month away (Aug 10 for go/no_go meeting). In an effort to reduce last minute bug scramble, the blocker review meetings will be starting up again [2]. Each Friday, between now and the Alpha release, a blocker review will take place in #fedora-bugzappers. Mark your calendars ... the first Alpha blocker review meeting starts at 17:00 UTC in #fedora-bugzappers. We'll review proposed and accepted F16 Alpha blocker bugs. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers (also attached to this mail). We'll be reviewing the bugs to determine ... 1. whether they meet the Alpha release criteria [3] and should stay on the list 2. are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process == Suggested Meeting Preparation == Maintainers ... * If your bug is *not* MODIFIED ... this issue is at risk of slipping the F16 Alpha release date * If your bug is in MODIFIED ... please make sure a build with the fix exists, and is available as a bodhi update. Testers ... * If you REPORT a bug ... please be responsive to any requests for additional information. * If a bug is in ON_QA ... please take a moment to apply the update, and post karma feedback (doesn't apply to rawhide at the moment) [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [3] https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria Thanks, James == Approved Blockers == The following list of bugs are approved blockers that must be resolved. There are 0 bugs affecting 0 components. == Proposed Blockers == The following list of bugs are not yet approved to block the release. There are 108 bugs affecting 106 components. For guidance on reviewing the following bugs, refer to [[QA:SOP_blocker_bug_process]]. * 389-admin - http://bugzilla.redhat.com/show_bug.cgi?id=695741 (NEW) - Providing native systemd file * 389-ds-base - http://bugzilla.redhat.com/show_bug.cgi?id=695736 (NEW) - Providing native systemd file * Ajaxterm - http://bugzilla.redhat.com/show_bug.cgi?id=657565 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * BackupPC - http://bugzilla.redhat.com/show_bug.cgi?id=699441 (ASSIGNED) - Providing native systemd file for upcoming F15 Feature Systemd * NetworkManager - http://bugzilla.redhat.com/show_bug.cgi?id=714702 (NEW) - Legacy SysV initscript file must go into an optional subpackage. * NetworkManager - http://bugzilla.redhat.com/show_bug.cgi?id=716904 (NEW) - Legacy SysV initscript file must go into an optional subpackage. * Pound - http://bugzilla.redhat.com/show_bug.cgi?id=720448 (NEW) - Provide native systemd unit file * aiccu - http://bugzilla.redhat.com/show_bug.cgi?id=656886 (NEW) - provide native aiccu.service systemd file * am-utils - http://bugzilla.redhat.com/show_bug.cgi?id=658116 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * amavisd-new - http://bugzilla.redhat.com/show_bug.cgi?id=695589 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * amavisd-new - http://bugzilla.redhat.com/show_bug.cgi?id=695597 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * apmd - http://bugzilla.redhat.com/show_bug.cgi?id=716970 (NEW) - Provide native systemd unit file * apt - http://bugzilla.redhat.com/show_bug.cgi?id=699293 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * argus - http://bugzilla.redhat.com/show_bug.cgi?id=699292 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * arm4 - http://bugzilla.redhat.com/show_bug.cgi?id=699289 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * at - http://bugzilla.redhat.com/show_bug.cgi?id=714642 (NEW) - Legacy SysV initscript file must go into an optional subpackage. * audit - http://bugzilla.redhat.com/show_bug.cgi?id=617321 (NEW) - Providing native systemd file for upcoming F14 Feature Systemd * autofs - http://bugzilla.redhat.com/show_bug.cgi?id=718701 (NEW) - Provide native systemd unit file * avahi - http://bugzilla.redhat.com/show_bug.cgi?id=714649 (NEW) - Legacy SysV initscript file must go into an optional subpackage. * bacula - http://bugzilla.redhat.com/show_bug.cgi?id=657216 (NEW) - Providing native systemd file for upcoming F15 Feature Systemd * bind - http://bugzilla.redhat.com/show_bug.cgi?id=719419
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/13/2011 07:17 PM, James Laska wrote: Your ideas are consistent with how we've handled this before, I don't think I could have articulated nearly as well though:) My understanding is that FESCO is the right place to discuss whether a feature should block a release or not. They already did and decided that what's on core + base + base-x would become alpha blockers which later got extended to included services we ship on the live cd. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Wed, 2011-07-13 at 19:25 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 07:17 PM, James Laska wrote: Your ideas are consistent with how we've handled this before, I don't think I could have articulated nearly as well though:) My understanding is that FESCO is the right place to discuss whether a feature should block a release or not. They already did and decided that what's on core + base + base-x would become alpha blockers which later got extended to included services we ship on the live cd. Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? /me pulling up old meeting minutes Thanks, James signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/13/2011 08:11 PM, James Laska wrote: Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? It's the one held on 15 June. See this thread on -devel [1] also note that FESCO accepted the feature [2] on the bases that native systemd unit files will be accepted up to beta after that no more native systemd service files will be introduced in the release during it's lifetime. Developers will need to convert the old sysvinit init scripts to native systemd ones and/or review and use ones that have been provided to them and package them as per packaging guidelines which can be found here http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd with sample scriptlet snippet which can be found here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd no later then beta for inclusions in the release. 1.http://lists.fedoraproject.org/pipermail/devel/2011-June/152780.html 2.http://fedoraproject.org/wiki/Features/SysVtoSystemd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Wed, 2011-07-13 at 19:25 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 07:17 PM, James Laska wrote: Your ideas are consistent with how we've handled this before, I don't think I could have articulated nearly as well though:) My understanding is that FESCO is the right place to discuss whether a feature should block a release or not. They already did and decided that what's on core + base + base-x would become alpha blockers which later got extended to included services we ship on the live cd. I think we could still talk to them about tweaking that process, though. I could easily be misinterpreted here, so I'll try to be precise... We've set up this whole blocker bug process that works quite smoothly to achieve what it sets out to achieve: validate the quality of the release. We have the release criteria and the blocker bug SOP and the system of bugs and meetings to carry it all out. That's great. Ultimately what the process achieves is QA's sign-off on the release: if there are no blocker bugs we say 'this release meets Fedora's quality standards'. Now, it should always be true that if there are any blocker bugs, the release cannot go out. *But*, crucially, the converse is not true: it is not inevitably be the case that if there are _no_ blocker bugs, the release _must_ go out. All it means is that we - the QA group - sign off on the release and say as far as we're concerned, it's okay to go out. QA isn't the *only* group that signs off on releases. FESCo does too. As I see it, it'd be perfectly fine for FESCo to say 'well, even though it meets all the quality standards, we do not want to sign off on this release until Feature X is done'. As I see it, that's a _separate_ process from the blocker bug / release validation process. FESCo does not need to use the blocker bug process to manage its decision to sign off on the release, and I think it would actually be better if they didn't. I'm dancing on pin heads here to some extent - the practical result is going to be the same whether we use the blocker process to manage FESCo's decisions on the feature process or whether we decide to come up with a different process for that - but I think it helps to have processes that are clearly and strictly defined: I think if we use blocker bugs to manage some specific aspect of the feature process, it dilutes both processes. I think it'd actually work out better if there were a separate mechanism by which FESCo managed its choice of whether or not to sign off on the release due to issues in the feature process. Thoughts? Should I talk to FESCo about this? -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
