date:20120727

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to delete this alpha criterion:

'The rescue mode of the installer must start successfully and be able to
detect and mount an existing default installation'

Reason (according to Chris): There's been no work done on rescue mode
and it is highly unlikely that it does anything at all right now.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Serial console

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to delete this beta [2] criterion:

'The installer must be able to complete an installation using the serial 
console interface'

Reason (according to Chris): (This criterion) will need to be removed for this 
release, 
given that there will be no text mode interface temporarily.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Rescue mode

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to remove this beta criterion [2]:

'The rescue mode of the installer must be able to detect and mount
(read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and
software) installations'

Reason (according to Chris): There's been no work done on rescue mode
and it is highly unlikely that it does anything at all right now.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode

2012-07-27 Thread Chris Adams

Once upon a time, Petr Schindler pschi...@redhat.com said:
 Because of changes in new anaconda [1] and after short discussion with
 Chris Lumens, I propose to remove this beta criterion [2]:
 
 'The rescue mode of the installer must be able to detect and mount
 (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and
 software) installations'
 
 Reason (according to Chris): There's been no work done on rescue mode
 and it is highly unlikely that it does anything at all right now.

You've proposed removing rescue mode criteria from both alpha and beta;
is there going to be any requirement for a functional rescue mode for
this release?  That's a pretty critical thing to have completely missing
from a release; things that occasionally happen such as a broken boot
loader would render an install virtually unrecoverable for many users.

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Anaconda and network-attached storage devices

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to remove this final criterion [2]:

'The installer must be able to complete an installation using any 
network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)'

Reason (according to Chris): (This feature) will not be supported for this 
release, 
but will be back for F19. There's simply not the time to do this.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Anaconda and network-attached storage devices

2012-07-27 Thread Chris Adams

Once upon a time, Petr Schindler pschi...@redhat.com said:
 Because of changes in new anaconda [1] and after short discussion with
 Chris Lumens, I propose to remove this final criterion [2]:
 
 'The installer must be able to complete an installation using any 
 network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)'
 
 Reason (according to Chris): (This feature) will not be supported for this 
 release, 
 but will be back for F19. There's simply not the time to do this.

I understand anaconda is undergoing a significant and needed rewrite,
but is it wise to ship a release with a whole lot of installer
functionality removed?  Maybe F18 should wait until anaconda is ready.
-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Rescue mode

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to change this final criterion [2]:

'The installer must be able to complete an installation using all 
supported interfaces '

to

'The installer must be able to complete an installation using all
supported interfaces (graphical and VNC for F18)'

Reason (according to Chris): (Current criterion) again references 
multiple interfaces. For F18, it's really only going to be graphical and VNC.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

[criteria update] Interfaces

Because of changes in new anaconda [1] and after short discussion with
Chris Lumens, I propose to change this final criterion [2]:

'The installer must be able to complete an installation using all 
supported interfaces '

to

'The installer must be able to complete an installation using all
supported interfaces (graphical and VNC for F18)'

Reason (according to Chris): (Current criterion) again references 
multiple interfaces. For F18, it's really only going to be graphical and VNC.

Please, if you have some suggestions or notes reply to this thread. If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria



-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Anaconda and network-attached storage devices

It is a big problem. Lot of things will be broken (won't be in new
anaconda for F18, but should be again in next releases, hopefully). For
example, we use serial console a lot and for f18 it won't work. I'm here
only proposing changes because of the state of anaconda and I hope that
the discussion within this threads will lead to some action - for me it
would be better to wait, but it looks like we could wait another six
month.

On Pá, 2012-07-27 at 08:55 -0500, Chris Adams wrote:
 Once upon a time, Petr Schindler pschi...@redhat.com said:
  Because of changes in new anaconda [1] and after short discussion with
  Chris Lumens, I propose to remove this final criterion [2]:
  
  'The installer must be able to complete an installation using any 
  network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel)'
  
  Reason (according to Chris): (This feature) will not be supported for this 
  release, 
  but will be back for F19. There's simply not the time to do this.
 
 I understand anaconda is undergoing a significant and needed rewrite,
 but is it wise to ship a release with a whole lot of installer
 functionality removed?  Maybe F18 should wait until anaconda is ready.
 -- 
 Chris Adams cmad...@hiwaay.net
 Systems and Network Administrator - HiWAAY Internet Services
 I don't speak for anybody but myself - that's enough trouble.


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode

On Pá, 2012-07-27 at 08:53 -0500, Chris Adams wrote:
 Once upon a time, Petr Schindler pschi...@redhat.com said:
  Because of changes in new anaconda [1] and after short discussion with
  Chris Lumens, I propose to remove this beta criterion [2]:
  
  'The rescue mode of the installer must be able to detect and mount
  (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and
  software) installations'
  
  Reason (according to Chris): There's been no work done on rescue mode
  and it is highly unlikely that it does anything at all right now.
 
 You've proposed removing rescue mode criteria from both alpha and beta;
 is there going to be any requirement for a functional rescue mode for
 this release?  That's a pretty critical thing to have completely missing
 from a release; things that occasionally happen such as a broken boot
 loader would render an install virtually unrecoverable for many users.

It is about discussion to accept this change. If there will be lot of
opinions against this change, we will let it be as it is and anaconda
will have to make their best to bring rescue mod. We can also change
this criterion. It's on discussion. Note that those changes are
hopefully only for F18. In F19 there should be everything back.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode

2012-07-27 Thread Joe Wulf

Question:  Is there a 'deferred' state these kinds of issues can be moved to?
That might be an acceptable middle-ground so that issues are maintained, yet 
rational is provided for why they are not worked in this release.

Just a thought.

-Joe





 From: Petr Schindler pschi...@redhat.com
To: test@lists.fedoraproject.org 
Sent: Friday, July 27, 2012 10:14 AM
Subject: Re: [criteria update] Rescue mode
 
On Pá, 2012-07-27 at 08:53 -0500, Chris Adams wrote:
 Once upon a time, Petr Schindler pschi...@redhat.com said:
  Because of changes in new anaconda [1] and after short discussion with
  Chris Lumens, I propose to remove this beta criterion [2]:
  
  'The rescue mode of the installer must be able to detect and mount
  (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and
  software) installations'
  
  Reason (according to Chris): There's been no work done on rescue mode
  and it is highly unlikely that it does anything at all right now.
 
 You've proposed removing rescue mode criteria from both alpha and beta;
 is there going to be any requirement for a functional rescue mode for
 this release?  That's a pretty critical thing to have completely missing
 from a release; things that occasionally happen such as a broken boot
 loader would render an install virtually unrecoverable for many users.

It is about discussion to accept this change. If there will be lot of
opinions against this change, we will let it be as it is and anaconda
will have to make their best to bring rescue mod. We can also change
this criterion. It's on discussion. Note that those changes are
hopefully only for F18. In F19 there should be everything back.

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Anaconda and network-attached storage devices

2012-07-27 Thread R P Herrold


On Fri, 27 Jul 2012, Petr Schindler wrote:


It is a big problem. Lot of things will be broken (won't be in new
anaconda for F18, but should be again in next releases, 
hopefully).  ...

... and I hope that
the discussion within this threads will lead to some action - for me it
would be better to wait, but it looks like we could wait another six
month.


'hope is not a plan' -- Here's a use case discussion ...

A couple weeks ago, I had to do a system recovery on an older 
unit, where a partition containing the binaries one needed 
developed drive errors recently.  It was old enough (F12 era), 
I could use the trick of booting with:

init=/bin/sh
to get the unit up 'enough' that I could do FSCKs and fix 
libraries enough to get ssh and rsync running, and so suck off 
the content not covered by backups (a couple of weeks of 
delta) 'across the wire'.  The unit happened to be up at a 
datacenter, and so inconvenient to simply 'pull the drive' out 
of, for data recovery


With the cut to systemd, none of us has those kind of 'tricks' 
at hand yet, and a media boot into 'rescue mode' with a kernel 
'close' to what one is repairing, is pretty well mandatory. 
It is probably possible to do so via PXE, but would be 
extrordinarily cumbersome to document in the general case


It may be that a live CD will turn the trick for rescue modes, 
but the reason one falls back to install media (and 'rescue 
mode') is for hardware and LV fixup/ drive detection, and 
finally being able to chroot into a sick drive ... that is, 
to perform the rescue


The absence of TUI rescue may be OK is RawHide (where it is 
permissible to eat kittens for breakfast), but not for a 
formal release, I would think ... perhaps a separate 'Recovery 
disk' ISO might be spun, with the F17 anaconda but F18 kernel, 
and ancillaries?  I 'get it' that it is cumbersome to maintain 
two paths, but without some way to address recovery, I have to 
think that well-advised folks will simply 'give a pass' to 
a 'risky' F18


- Russ herrold
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Rawhide file-conflict gnupg gnupg2

2012-07-27 Thread Frank Murphy


On 27/07/12 14:22, Kevin Martin wrote:

On 07/27/2012 04:37 AM, Frank Murphy wrote:

Transaction Check Error:
   file /usr/share/man/man1/gpg-zip.1.gz from install of 
gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
gnupg-1.4.12-2.fc18.i686


Do you need both gnupg and gnupg2 on the same system at the same time?


yum erase gnupg, will remove just gnupg
yum erase gnupg2 want's to erase a lot of pkgs.

so may erase gnupg, see what happens.

 What happens if you yum update with

--setopt=protected_multilib=false in the update line?

Kevin



yum update --setopt=protected_multilib=false
Loaded plugins: downloadonly, fastestmirror, langpacks, local, presto, 
refresh-

  : packagekit, refresh-updatesd, tidy-cache
Loading mirror speeds from cached hostfile
 * rawhide: vesta.informatik.rwth-aachen.de
Resolving Dependencies
-- Running transaction check
--- Package gnupg2.i686 0:2.0.19-2.fc18 will be updated
--- Package gnupg2.i686 0:2.0.19-3.fc18 will be an update
--- Package libGLEW.i686 0:1.6.0-2.fc17 will be updated
-- Processing Dependency: libGLEW.so.1.6 for package: 
glx-utils-7.10-7.20101028.fc18.i686

--- Package libGLEW.i686 0:1.7.0-3.fc18 will be an update
-- Finding unneeded leftover dependencies
Found and removing 0 unneeded dependencies
-- Running transaction check
--- Package libGLEW.i686 0:1.6.0-2.fc17 will be updated
--- Package libGLEW.i686 0:1.7.0-3.fc18 will be an update
-- Running transaction check
--- Package gnupg2.i686 0:2.0.19-2.fc18 will be updated
--- Package gnupg2.i686 0:2.0.19-3.fc18 will be an update
-- Finished Dependency Resolution

Packages skipped because of dependency problems:
libGLEW-1.7.0-3.fc18.i686 from koji

Dependencies Resolved


 Package   Arch   Version  Repository 
Size


Updating:
 gnupg2i686   2.0.19-3.fc18koji 
   1.4 M

Skipped (dependency problems):
 libGLEW   i686   1.7.0-3.fc18 koji 
   107 k


Transaction Summary

Upgrade1 Package
Skipped (dependency problems)  1 Package

Total size: 1.4 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test


Transaction Check Error:
  file /usr/share/man/man1/gpg-zip.1.gz from install of 
gnupg2-2.0.19-3.fc18.i686 conflicts with file from package 
gnupg-1.4.12-2.fc18.i686


Error Summary
-


--
Regards,
Frank
Jack of all, fubars
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Root priviledges needed to poweroff

2012-07-27 Thread ergodic


It is clear that different scenarios require different rules.
I have installed Fedora for three different friends.  All at different physical 
locations from my place.  These people have no computer knowledge, so giving 
them elevated permissions spells disaster.  However they must to be able to 
start the box and turn it off.  A different scenario is server box which 
requires different rules.

Thus why not make the choice configurable?  One of my many dislikes of 
Microsoft Windows has been its rigidity.

Furthermore, as it stands today be caught in a false sense of security. A 
reboot can be  executed immediately by any user regardless of whether anyone 
else is logged in  and with no warning issued.

- Original Message -
On Fri, Jul 27, 2012 at 11:09:03 +0200,
   Karel Volný kvo...@redhat.com wrote:

if the user is local then DO NOT ask for admin privileges (else
the user will just cut the power supply which is worse than
killing others' running processes)

I'd prefer to keep that option. A local user would be less likely to power 
off the machine than shut it down. (Which for some of my machines they 
shouldn't be doing.)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Rawhide file-conflict gnupg gnupg2

2012-07-27 Thread Tom London

On Fri, Jul 27, 2012 at 8:17 AM, Frank Murphy frankl...@gmail.com wrote:

 On 27/07/12 14:22, Kevin Martin wrote:

 On 07/27/2012 04:37 AM, Frank Murphy wrote:

 Transaction Check Error:
file /usr/share/man/man1/gpg-zip.1.**gz from install of
 gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
 gnupg-1.4.12-2.fc18.i686

  Do you need both gnupg and gnupg2 on the same system at the same time?


 yum erase gnupg, will remove just gnupg
 yum erase gnupg2 want's to erase a lot of pkgs.

 so may erase gnupg, see what happens.


  What happens if you yum update with

 --setopt=protected_multilib=**false in the update line?

 Kevin


 yum update --setopt=protected_multilib=**false
 Loaded plugins: downloadonly, fastestmirror, langpacks, local, presto,
 refresh-
   : packagekit, refresh-updatesd, tidy-cache
 Loading mirror speeds from cached hostfile
  * rawhide: 
 vesta.informatik.rwth-aachen.**dehttp://vesta.informatik.rwth-aachen.de
 Resolving Dependencies
 -- Running transaction check
 --- Package gnupg2.i686 0:2.0.19-2.fc18 will be updated
 --- Package gnupg2.i686 0:2.0.19-3.fc18 will be an update
 --- Package libGLEW.i686 0:1.6.0-2.fc17 will be updated
 -- Processing Dependency: libGLEW.so.1.6 for package:
 glx-utils-7.10-7.20101028.**fc18.i686
 --- Package libGLEW.i686 0:1.7.0-3.fc18 will be an update
 -- Finding unneeded leftover dependencies
 Found and removing 0 unneeded dependencies
 -- Running transaction check
 --- Package libGLEW.i686 0:1.6.0-2.fc17 will be updated
 --- Package libGLEW.i686 0:1.7.0-3.fc18 will be an update
 -- Running transaction check
 --- Package gnupg2.i686 0:2.0.19-2.fc18 will be updated
 --- Package gnupg2.i686 0:2.0.19-3.fc18 will be an update
 -- Finished Dependency Resolution

 Packages skipped because of dependency problems:
 libGLEW-1.7.0-3.fc18.i686 from koji

 Dependencies Resolved

 ==**==**
 
  Package   Arch   Version  Repository
 Size
 ==**==**
 
 Updating:
  gnupg2i686   2.0.19-3.fc18koji1.4 M
 Skipped (dependency problems):
  libGLEW   i686   1.7.0-3.fc18 koji107 k

 Transaction Summary
 ==**==**
 
 Upgrade1 Package
 Skipped (dependency problems)  1 Package

 Total size: 1.4 M
 Is this ok [y/N]: y
 Downloading Packages:
 Running Transaction Check
 Running Transaction Test



 Transaction Check Error:
   file /usr/share/man/man1/gpg-zip.1.**gz from install of
 gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
 gnupg-1.4.12-2.fc18.i686

 Error Summary
 -




Appears that a few packages depend on gnupg:

[root@tlondon ~]# yum remove gnupg
Loaded plugins: auto-update-debuginfo, presto, refresh-packagekit
Resolving Dependencies
-- Running transaction check
--- Package gnupg.x86_64 0:1.4.12-2.fc18 will be erased
-- Processing Dependency: gnupg for package:
monkeysphere-0.35-5.fc18.noarch
-- Processing Dependency: gnupg = 1.0.6 for package:
duplicity-0.6.18-2.fc18.x86_64
-- Running transaction check
--- Package duplicity.x86_64 0:0.6.18-2.fc18 will be erased
--- Package monkeysphere.noarch 0:0.35-5.fc18 will be erased
-- Finished Dependency Resolution

Dependencies Resolved


 Package Arch  Version Repository
Size

Removing:
 gnupg   x86_641.4.12-2.fc18   @18koji
5.0 M
Removing for dependencies:
 duplicity   x86_640.6.18-2.fc18   @18koji
2.0 M
 monkeyspherenoarch0.35-5.fc18 @18koji
257 k

Transaction Summary

Remove  1 Package (+2 Dependent packages)

Installed size: 7.2 M
Is this ok [y/N]: n
Exiting on user Command
Your transaction was saved, rerun it with:
 yum load-transaction /tmp/yum_save_tx.2012-07-27.09-33.NwKsoj.yumtx
[root@tlondon ~]#


tom
-- 
Tom London
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Rawhide file-conflict gnupg gnupg2

2012-07-27 Thread Frank Murphy


On 27/07/12 17:34, Tom London wrote:

On Fri, Jul 27, 2012 at 8:17 AM, Frank Murphy frankl...@gmail.com


Same error on koji kernel-build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4336751
http://kojipkgs.fedoraproject.org//work/tasks/6751/4336751/root.log



--
Regards,
Frank
Jack of all, fubars
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Rawhide file-conflict gnupg gnupg2

2012-07-27 Thread Kevin Martin

On 07/27/2012 10:17 AM, Frank Murphy wrote:
 On 27/07/12 14:22, Kevin Martin wrote:
 On 07/27/2012 04:37 AM, Frank Murphy wrote:
 Transaction Check Error:
file /usr/share/man/man1/gpg-zip.1.gz from install of 
 gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
 gnupg-1.4.12-2.fc18.i686

 Do you need both gnupg and gnupg2 on the same system at the same time?
 
 yum erase gnupg, will remove just gnupg
 yum erase gnupg2 want's to erase a lot of pkgs.
 
 so may erase gnupg, see what happens.
 
  What happens if you yum update with
 --setopt=protected_multilib=false in the update line?

 Kevin

 
 yum update --setopt=protected_multilib=false
 Loaded plugins: downloadonly, fastestmirror, langpacks, local, presto, 
 refresh-
   : packagekit, refresh-updatesd, tidy-cache
 Loading mirror speeds from cached hostfile
  * rawhide: vesta.informatik.rwth-aachen.de
 Resolving Dependencies
 -- Running transaction check
 --- Package gnupg2.i686 0:2.0.19-2.fc18 will be updated
 --- Package gnupg2.i686 0:2.0.19-3.fc18 will be an update
 --- Package libGLEW.i686 0:1.6.0-2.fc17 will be updated
 -- Processing Dependency: libGLEW.so.1.6 for package: 
 glx-utils-7.10-7.20101028.fc18.i686
 --- Package libGLEW.i686 0:1.7.0-3.fc18 will be an update
 -- Finding unneeded leftover dependencies
 Found and removing 0 unneeded dependencies
 -- Running transaction check
 --- Package libGLEW.i686 0:1.6.0-2.fc17 will be updated
 --- Package libGLEW.i686 0:1.7.0-3.fc18 will be an update
 -- Running transaction check
 --- Package gnupg2.i686 0:2.0.19-2.fc18 will be updated
 --- Package gnupg2.i686 0:2.0.19-3.fc18 will be an update
 -- Finished Dependency Resolution
 
 Packages skipped because of dependency problems:
 libGLEW-1.7.0-3.fc18.i686 from koji
 
 Dependencies Resolved
 
 
  Package   Arch   Version  Repository Size
 
 Updating:
  gnupg2i686   2.0.19-3.fc18koji1.4 M
 Skipped (dependency problems):
  libGLEW   i686   1.7.0-3.fc18 koji107 k
 
 Transaction Summary
 
 Upgrade1 Package
 Skipped (dependency problems)  1 Package
 
 Total size: 1.4 M
 Is this ok [y/N]: y
 Downloading Packages:
 Running Transaction Check
 Running Transaction Test
 
 
 Transaction Check Error:
   file /usr/share/man/man1/gpg-zip.1.gz from install of 
 gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
 gnupg-1.4.12-2.fc18.i686
 
 Error Summary
 -
 
 
my apologies on the multilib settingthat's to be used, I think, when you 
have the same rpm's installed but for i686 and x86_64
(happens sometimes when running a 32 bit package on a 64 bit system).

Kevin
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode


On 07/27/2012 02:14 PM, Petr Schindler wrote:

It is about discussion to accept this change. If there will be lot of
opinions against this change, we will let it be as it is and anaconda
will have to make their best to bring rescue mod. We can also change
this criterion. It's on discussion. Note that those changes are
hopefully only for F18. In F19 there should be everything back.


So what no text mode and no rescue mode this release?

From the looks of it we should just delay the new anaconda for F19 and 
re-use the release we used for F17 .


This topic should be added to the meeting agenda and voted upon.

JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Serial console

2012-07-27 Thread Scott Poore

- Original Message -
 Because of changes in new anaconda [1] and after short discussion
 with
 Chris Lumens, I propose to delete this beta [2] criterion:
 
 'The installer must be able to complete an installation using the
 serial console interface'
 
 Reason (according to Chris): (This criterion) will need to be removed
 for this release,
 given that there will be no text mode interface temporarily.

No text mode installs at all?  That seems like a pretty critical function to 
me.  

Is there some new functionality (sorry, I haven't looked into upcoming anaconda 
changes yet) that replaces this?

How can an admin install on a server they have to use a remote console system 
for?  Doesn't that also negate the use of iLO's, RSA's and the like?

Maybe I'm just missing something.  VNC maybe?

Couldn't that also affect current kickstart configs used for some testing 
automation?  Maybe not?

Regards,
Scott

 
 Please, if you have some suggestions or notes reply to this thread.
 If
 there won't be any objections I'll make changes during next week.
 
 Petr Schindler
 
 [1] https://fedoraproject.org/wiki/Features/NewInstallerUI
 [2] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria
 
 
 --
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Serial console

2012-07-27 Thread Robyn Bergeron

On 07/27/2012 11:11 AM, Scott Poore wrote:

- Original Message -

Because of changes in new anaconda [1] and after short discussion
with
Chris Lumens, I propose to delete this beta [2] criterion:

'The installer must be able to complete an installation using the
serial console interface'

Reason (according to Chris): (This criterion) will need to be removed
for this release,
given that there will be no text mode interface temporarily.

No text mode installs at all? That seems like a pretty critical function to me.

Is there some new functionality (sorry, I haven't looked into upcoming anaconda
changes yet) that replaces this?

How can an admin install on a server they have to use a remote console system
for? Doesn't that also negate the use of iLO's, RSA's and the like?

Maybe I'm just missing something. VNC maybe?

Couldn't that also affect current kickstart configs used for some testing
automation? Maybe not?
I think most of these questions got answered at the FESCo meeting where
the feature was approved.

http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-17.00.log.html
(search for 853, which is the ticket #)

Regards,
Scott

Please, if you have some suggestions or notes reply to this thread.
If
there won't be any objections I'll make changes during next week.

Petr Schindler

[1] https://fedoraproject.org/wiki/Features/NewInstallerUI
[2] https://fedoraproject.org/wiki/Fedora_17_Beta_Release_Criteria

--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode


On 07/27/2012 02:24 PM, Bryn M. Reeves wrote:

Generic rescue images would still work for most problems but I'd tend
to agree: a final release with a non-working rescue mode is pretty
uncool and seems like a bad precedent.


In any case if the plan is to extend installer initrd with the rescue 
mode or a have separate grub entry with rescue initrd we need testable 
one ASAP so we can test if that can work as an acceptable solution to 
use in F18 or if we should use the anaconda release that was used in F17 
instead and delay introducing the new anaconda til F19.


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Serial console

2012-07-27 Thread Scott Poore

- Original Message -
 From: Robyn Bergeron rberg...@redhat.com
 To: test@lists.fedoraproject.org
 Sent: Friday, July 27, 2012 1:15:27 PM
 Subject: Re: [criteria update] Serial console

 I think most of these questions got
 answered at the FESCo meeting where the feature was approved.

 http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-17.00.log.html
 (search for 853, which is the ticket #)

Robyn, that does answer most of my questions.  Thanks.

So, should a requirement be added to test install via VNC? 

And, could this one be listed as Deferred like mentioned in another anaconda 
thread?

Thanks,
Scott

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode

On Fri, 2012-07-27 at 18:02 +, Jóhann B. Guðmundsson wrote:
 On 07/27/2012 02:14 PM, Petr Schindler wrote:
  It is about discussion to accept this change. If there will be lot of
  opinions against this change, we will let it be as it is and anaconda
  will have to make their best to bring rescue mod. We can also change
  this criterion. It's on discussion. Note that those changes are
  hopefully only for F18. In F19 there should be everything back.
 
 So what no text mode and no rescue mode this release?
 
  From the looks of it we should just delay the new anaconda for F19 and 
 re-use the release we used for F17 .
 
 This topic should be added to the meeting agenda and voted upon.

The inclusion of newUI in itself is a Feature; the correct way to get it
delayed, if we decided we want that, would be to bring it up with FESCo
(by filing a FESCo ticket asking them to look at it). A vote of QA alone
isn't sufficient to mandate the removal of a feature.

The lack of rescue mode in a final release would be a bit worrying, I
agree.
-- 
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: [criteria update] Rescue mode

On Fri, 2012-07-27 at 07:19 -0700, Joe Wulf wrote:
 Question:  Is there a 'deferred' state these kinds of issues can be
 moved to?
 That might be an acceptable middle-ground so that issues are
 maintained, yet rational is provided for why they are not worked in
 this release.
 
 
 Just a thought.

As far as I remember, it's not something we've really done before -
we've waived specific bugs occasionally, with various degrees of process
hackery and hand-waving, but that's all.

However, there's no reason at all we can't do it. Actually I was going
to suggest something similar. If we decided it was the right thing to
do, it'd be pretty trivial to grey-out or strike-out a criterion, with a
note that it's suspended for the specific release in question.
-- 
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: [criteria update] Rescue mode

On Fri, 2012-07-27 at 15:59 +0200, Petr Schindler wrote:
 Because of changes in new anaconda [1] and after short discussion with
 Chris Lumens, I propose to change this final criterion [2]:
 
 'The installer must be able to complete an installation using all 
 supported interfaces '
 
 to
 
 'The installer must be able to complete an installation using all
 supported interfaces (graphical and VNC for F18)'
 
 Reason (according to Chris): (Current criterion) again references 
 multiple interfaces. For F18, it's really only going to be graphical and VNC.
 
 Please, if you have some suggestions or notes reply to this thread. If
 there won't be any objections I'll make changes during next week.

I think you applied the wrong Subject: line to this one. Could you send
it again with an appropriate Subject: line so things don't get confused?
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

Re: [criteria update] Rescue mode

On Fri, 2012-07-27 at 15:38 +0200, Petr Schindler wrote:
 Because of changes in new anaconda [1] and after short discussion with
 Chris Lumens, I propose to delete this alpha criterion:
 
 'The rescue mode of the installer must start successfully and be able to
 detect and mount an existing default installation'
 
 Reason (according to Chris): There's been no work done on rescue mode
 and it is highly unlikely that it does anything at all right now.
 
 Please, if you have some suggestions or notes reply to this thread. If
 there won't be any objections I'll make changes during next week.
 
 Petr Schindler
 
 [1] https://fedoraproject.org/wiki/Features/NewInstallerUI

I wouldn't be hugely worried about waiving rescue mode for Alpha, but as
others have said, it's more problematic if it's not going to come back
for Beta or at least Final. Has Chris said anything about that?
-- 
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: [criteria update] Rescue mode

On Fri, 2012-07-27 at 14:27 -0700, Adam Williamson wrote:
 On Fri, 2012-07-27 at 18:02 +, Jóhann B. Guðmundsson wrote:
  On 07/27/2012 02:14 PM, Petr Schindler wrote:
   It is about discussion to accept this change. If there will be lot of
   opinions against this change, we will let it be as it is and anaconda
   will have to make their best to bring rescue mod. We can also change
   this criterion. It's on discussion. Note that those changes are
   hopefully only for F18. In F19 there should be everything back.
  
  So what no text mode and no rescue mode this release?
  
   From the looks of it we should just delay the new anaconda for F19 and 
  re-use the release we used for F17 .
  
  This topic should be added to the meeting agenda and voted upon.
 
 The inclusion of newUI in itself is a Feature; the correct way to get it
 delayed, if we decided we want that, would be to bring it up with FESCo
 (by filing a FESCo ticket asking them to look at it). A vote of QA alone
 isn't sufficient to mandate the removal of a feature.
 
 The lack of rescue mode in a final release would be a bit worrying, I
 agree.

On this topic: the feature page explicitly states that there will be no
text interface for F18 - Finally, there will not be any available text
UI in the first Fedora with the new graphical UI. This is simply due to
a matter of time and manpower - there's not enough time to design and
implement a second interface at the same time. We are planning on having
this finished up for the next Fedora release, though.  The feature was
voted through by FESCo with that text included. So we can take that as
an implicit approval by FESCo for releasing F18 without a text interface
for the installer, and it would therefore make sense for us to waive
criteria involving text install mode.

However, the feature page does not mention any other missing features -
rescue mode, or any others. So if we're concerned about missing features
besides text mode, we should communicate this to anaconda team and FESCo
quickly, before newui is merged into Rawhide; once that happens it gets
very difficult to reject newui. We should clarify with anaconda team
whether rescue mode is expected to be in place for final, and if there
are any other major missing features that have not yet been discussed.
-- 
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: [criteria update] Serial console

On Fri, 2012-07-27 at 16:26 -0400, Scott Poore wrote:
 - Original Message -
  From: Robyn Bergeron rberg...@redhat.com
  To: test@lists.fedoraproject.org
  Sent: Friday, July 27, 2012 1:15:27 PM
  Subject: Re: [criteria update] Serial console
  
  I think most of these questions got
  answered at the FESCo meeting where the feature was approved.
  
  http://meetbot.fedoraproject.org/fedora-meeting/2012-05-14/fesco.2012-05-14-17.00.log.html
  (search for 853, which is the ticket #)
  
 
 Robyn, that does answer most of my questions.  Thanks.
 
 So, should a requirement be added to test install via VNC? 
 
 And, could this one be listed as Deferred like mentioned in another 
 anaconda thread?

We already do VNC testing:

https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_VNC
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_VNC_Vncconnect
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_User_Interface_VNC_Password

these are all listed as Alpha level tests, meaning they are required to
be performed for Alpha, Beta and Final validation testing.
-- 
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: [criteria update] Rescue mode


On 07/27/2012 09:27 PM, Adam Williamson wrote:

On Fri, 2012-07-27 at 18:02 +, Jóhann B. Guðmundsson wrote:

On 07/27/2012 02:14 PM, Petr Schindler wrote:

It is about discussion to accept this change. If there will be lot of
opinions against this change, we will let it be as it is and anaconda
will have to make their best to bring rescue mod. We can also change
this criterion. It's on discussion. Note that those changes are
hopefully only for F18. In F19 there should be everything back.

So what no text mode and no rescue mode this release?

  From the looks of it we should just delay the new anaconda for F19 and
re-use the release we used for F17 .

This topic should be added to the meeting agenda and voted upon.

The inclusion of newUI in itself is a Feature; the correct way to get it
delayed, if we decided we want that, would be to bring it up with FESCo
(by filing a FESCo ticket asking them to look at it). A vote of QA alone
isn't sufficient to mandate the removal of a feature.


I disagree the QA vote should be sufficient to deem the feature not 
complete thus Anaconda would be subjected to their contingency plan.


As I have mentioned before on this thread if the plan is to extend 
installer initrd with the rescue mode or a have separate grub entry with 
rescue initrd ( or rescue mode in some other form ) we need testable 
spin with that solution in the installer ASAP so we can test if that can 
work as an acceptable solution to use in F18 however if the plan is to 
drop it we can cast a vote on next meeting.


What we need now is to actually hear from the Anaconda team what they 
are planning to do...


JBG

JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Rescue mode

On Fri, 2012-07-27 at 21:51 +, Jóhann B. Guðmundsson wrote:
 On 07/27/2012 09:27 PM, Adam Williamson wrote:
  On Fri, 2012-07-27 at 18:02 +, Jóhann B. Guðmundsson wrote:
  On 07/27/2012 02:14 PM, Petr Schindler wrote:
  It is about discussion to accept this change. If there will be lot of
  opinions against this change, we will let it be as it is and anaconda
  will have to make their best to bring rescue mod. We can also change
  this criterion. It's on discussion. Note that those changes are
  hopefully only for F18. In F19 there should be everything back.
  So what no text mode and no rescue mode this release?
 
From the looks of it we should just delay the new anaconda for F19 and
  re-use the release we used for F17 .
 
  This topic should be added to the meeting agenda and voted upon.
  The inclusion of newUI in itself is a Feature; the correct way to get it
  delayed, if we decided we want that, would be to bring it up with FESCo
  (by filing a FESCo ticket asking them to look at it). A vote of QA alone
  isn't sufficient to mandate the removal of a feature.
 
 I disagree the QA vote should be sufficient to deem the feature not 
 complete thus Anaconda would be subjected to their contingency plan.

Well, to a certain extent it's academic. I suspect that if QA was
strongly of the opinion that the feature isn't sufficiently complete,
FESCo would give substantial weight to that input in making its
determination. But it's FESCo that owns the feature process, and
ultimately FESCo that makes the final determination of whether a feature
is meeting the requirements of the process - it's FESCo that has to say
'we declare this feature isn't meeting the process, and here's what we
plan to do about it'.

 As I have mentioned before on this thread if the plan is to extend 
 installer initrd with the rescue mode or a have separate grub entry with 
 rescue initrd ( or rescue mode in some other form ) we need testable 
 spin with that solution in the installer ASAP so we can test if that can 
 work as an acceptable solution to use in F18 however if the plan is to 
 drop it we can cast a vote on next meeting.
 
 What we need now is to actually hear from the Anaconda team what they 
 are planning to do...

Yeah, I'm asking at present. Chris is out until next Wednesday, though,
so we may not get definitive word before then.
-- 
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: [criteria update] Rescue mode


On 07/27/2012 09:55 PM, Adam Williamson wrote:

Well, to a certain extent it's academic. I suspect that if QA was
strongly of the opinion that the feature isn't sufficiently complete,
FESCo would give substantial weight to that input in making its
determination. But it's FESCo that owns the feature process, and
ultimately FESCo that makes the final determination of whether a feature
is meeting the requirements of the process - it's FESCo that has to say
'we declare this feature isn't meeting the process, and here's what we
plan to do about it'.


That's a bit backward logic as in the QA cant stop a feature if we deem 
it not ready for our end user base and arguably should be fixed in the 
feature process.


Fortunately for us we have a contingency plan should FESCO decide to 
push something forward that we deem too disruptive, to broken for our 
end user base.


JBG
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Rawhide file-conflict gnupg gnupg2

2012-07-27 Thread T.C. Hollingsworth

On Friday, July 27, 2012, Frank Murphy frankl...@gmail.com wrote:
 Transaction Check Error:
   file /usr/share/man/man1/gpg-zip.1.gz from install of
gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
gnupg-1.4.12-2.fc18.i686

Please file a bug against both these packages. File conflicts are forbidden
by the Fedora Packaging Guidelines.

-T.C.

 --
 Regards,
 Frank
 Jack of all, fubars
 --
 test mailing list
 test@lists.fedoraproject.org
 To unsubscribe:
 https://admin.fedoraproject.org/mailman/listinfo/test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Rawhide file-conflict gnupg gnupg2

2012-07-27 Thread Bruno Wolff III


On Fri, Jul 27, 2012 at 15:42:03 -0700,
  T.C. Hollingsworth tchollingswo...@gmail.com wrote:

On Friday, July 27, 2012, Frank Murphy frankl...@gmail.com wrote:

Transaction Check Error:
  file /usr/share/man/man1/gpg-zip.1.gz from install of

gnupg2-2.0.19-3.fc18.i686 conflicts with file from package
gnupg-1.4.12-2.fc18.i686

Please file a bug against both these packages. File conflicts are forbidden
by the Fedora Packaging Guidelines.


I did already and the maintainer already has a build which fixes the problem.
It should be in the next rawhide compose.
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Serial console

2012-07-27 Thread Fernando Cassia

On Fri, Jul 27, 2012 at 3:11 PM, Scott Poore spo...@redhat.com wrote:

 No text mode installs at all?  That seems like a pretty critical function to 
 me.

exactly, many ARM releases depend on interactive install using a rs232
connection as terminal.

FC
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [criteria update] Serial console