Re: Fedora 17’s unified filesystem (/usr-move)

[Harald Hoyer]

you forgot to convert with dracut before yum upgrade... right??
Am 30.01.2012 22:11 schrieb "Orion Poplawski" :

> On 01/30/2012 12:17 PM, Orion Poplawski wrote:
>
>> On 01/27/2012 06:10 AM, Harald Hoyer wrote:
>>
>>> Until the rawhide repository gets all the converted rpms, use the
>>> f17-usrmove
>>> repository to update the system after the filesystem conversion and
>>> disable
>>> rawhide in the file /etc/yum.repos.d/fedora-**rawhide.repo
>>>
>>> Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.**repo
>>> [f17-usrmove]
>>> name=Fedora $releasever - $basearch
>>> failovermethod=priority
>>> baseurl=http://koji.**fedoraproject.org/repos/f17-**
>>> usrmove/latest/$basearch
>>> enabled=1
>>> metadata_expire=1d
>>> gpgcheck=0
>>>
>>> # yum clean all
>>> # yum upgrade
>>>
>>
>> Looks like a no-go with multilib:
>>
>> Error: Protected multilib versions: libacl-2.2.51-5.fc17.x86_64 !=
>> libacl-2.2.51-3.fc17.i686
>> Error: Protected multilib versions: db4-4.8.30-7.fc17.x86_64 !=
>> db4-4.8.30-5.fc17.i686
>> Error: Protected multilib versions: nspr-4.9-0.2.fc17.beta3.1.x86_**64 !=
>> nspr-4.9-0.2.fc17.beta3.i686
>> Error: Protected multilib versions: krb5-libs-1.10-1.fc17.x86_64 !=
>> krb5-libs-1.10-0.fc17.beta1.2.**i686
>> Error: Protected multilib versions: libuuid-2.20.1-5.fc17.x86_64 !=
>> libuuid-2.20.1-4.fc17.i686
>> Error: Protected multilib versions: nss-softokn-3.13.1-19.fc17.**x86_64
>> !=
>> nss-softokn-3.13.1-17.fc17.**i686
>> Error: Protected multilib versions: libattr-2.4.46-5.fc17.x86_64 !=
>> libattr-2.4.46-3.fc17.i686
>> Error: Protected multilib versions: libselinux-2.1.9-6.fc17.x86_64 !=
>> libselinux-2.1.9-3.fc17.i686
>> Error: Protected multilib versions: nss-softokn-freebl-3.13.1-19.**
>> fc17.x86_64
>> != nss-softokn-freebl-3.13.1-17.**fc17.i686
>> Error: Protected multilib versions: libdb-5.2.36-4.fc17.x86_64 !=
>> libdb-5.2.36-2.fc17.i686
>>
>> I suppose I could add in the i386 repo...
>>
>>
> I added:
>
> [f17-usrmove-i386]
> name=Fedora $releasever - $basearch
> failovermethod=priority
> baseurl=http://koji.**fedoraproject.org/repos/f17-**usrmove/latest/i386
> enabled=1
> metadata_expire=1d
> gpgcheck=0
>
> And got the following errors:
>
>  Updating   : coreutils-8.15-5.fc17.x86_64  7/223
> /var/tmp/rpm-tmp.T9mWTk: line 1: /usr/bin/grep: No such file or directory
>
>  Updating   : filesystem-3-1.fc17.x86_64 23/223
> Error unpacking rpm package filesystem-3-1.fc17.x86_64
> error: unpacking of archive failed on file /bin: cpio: rename
> error: filesystem-3-1.fc17.x86_64: install failed
>
> error: filesystem-2.4.46-1.fc17.x86_**64: erase skipped
>
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kdesdk-okteta-4.8.0-1.fc17.**x86_64
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kdesdk-kompare-4.8.0-1.fc17.**x86_64
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kdesdk-kioslave-4.8.0-1.fc17.**x86_64
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kdesdk-cervisia-4.8.0-1.fc17.**x86_64
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kdesdk-kcachegrind-4.8.0-1.**fc17.x86_64
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kdesdk-umbrello-4.8.0-1.fc17.**x86_64
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kdesdk-kapptemplate-4.8.0-1.**fc17.x86_64
> Non-fatal POSTTRANS scriptlet failure in rpm package
> kdesdk-kuiviewer-4.8.0-1.fc17.**x86_64
>
> filesystem-2.4.46-1.fc17.x86_**64 was supposed to be removed but is not!
>
>
> Now I get:
>
> # ls -l /
> -bash: /bin/ls: No such file or directory
>
> Shutdown did not complete.  Boot now fails with:
>
> dracut: Switching root
> switch_root: failed to execute /etc/init: Permission denied
> Kernel panic - not syncing: Attempted to kill init!
>
> even with enforcing=0
>
>
> Anyone want any postmortem info before I reinstall the VM?
>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA, Boulder Office  FAX: 303-415-9702
> 3380 Mitchell Lane  or...@cora.nwra.com
> Boulder, CO 80301  http://www.cora.nwra.com
> --
> 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

2012-01-30 - Fedora QA Meeting - recap

[Adam Williamson]

As always, minutes and IRC transcript available on the wiki at
https://fedoraproject.org/wiki/QA/Meetings/20120130

Next meeting is scheduled for 2012-02-06 at 1600 UTC in #fedora-meeting.
If you have topics you think we should bring up at the meeting, please
add them to the Wiki page at
https://fedoraproject.org/wiki/QA/Meetings/20120206 . Thanks!

TOPIC: Previous meeting follow-up
===
* adamw filed a trac ticket[1] for getting arm into the
  criteria / validation process
* adamw made some progress on making sure all important old-UI
  bugs discovered in F16 validation have been bumped and
  prioritized F17
* adamw started a discussion with pjones/kparal/hongqing/
  robatino to decide how we want to use pjones' el torito boot
  checker (private mail)
* tflink was to contact lmacken re co-ordination between bodhi
  2.0 and autoqa: bodhi 2.0 will be backwards compatible, so
  autoqa should continue to work as before 

TOPIC: Fedora 17 status
===
* A manual install of rats #2 boot.iso works, DVD image does
  not boot[2], rats_install run hits a dracut / virt-install
  issue[3] with boot parameters
* Not clear if current nightly live images are generally
  bootable or not, j_dulaney has a kernel issue booting them
* Retrospective tasks are mostly completed or well-advanced

TOPIC: /usr move feature and testing
===
* Testing of rawhide with /usr move packages so far is
  positive: if we can compose a working / installable boot.iso
  with /usr move packages, the feature can be tagged into
  rawhide 

TOPIC: Upcoming QA events
===
* TC1 is due tomorrow (2012-01-31)
* Blocker bug review meeting #2 on Friday (2012-02-03)

TOPIC: AutoQA update
===
* mkrizek pushed a patch to make autoqa better retry failed /
  timed-out connections
* kparal refactored rats_install test and fixed many problems

TOPIC: Open floor
===
* F17 images so far are mysteriously smaller than F16, we're
  not sure of the cause 

ACTION ITEMS
===
* kparal to file a bug for the failure of rats #2 DVD image to
  boot
* tflink to test building a boot.iso with usrmove builds 

[1] http://fedorahosted.org/fedora-qa/ticket/277
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=785808
[3] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=785815
-- 
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: New criterion for installation with minimal set of packages

[Adam Williamson]

On Mon, 2012-01-30 at 21:56 -0500, Jon Stanley wrote:
> On Mon, Jan 30, 2012 at 8:49 PM, Adam Williamson  wrote:
> 
> > Yeah, this is kind of problematic, because I don't really want the
> > release criteria to prescribe exactly what the 'minimal' package set
> > should include. Perhaps we should just explicitly refer to 'the
> > installer's "minimal" package set' or something like that
> 
> True - come to think of it, I really don't believe that it is QA's
> domain to define the task list - but it should be somebody's. What I
> don't want is the feature creep of the "minimal" package set - next
> thing you know, GNOME will be part of that package set. But I don't
> think that QA is the appropriate place to address those concerns :)

Yeah. As far as QA is concerned, the key questions are 'is there a
minimal package set present, does an install with that package set
complete properly, does it boot'. What's *in* it is not really our
concern.
-- 
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: New criterion for installation with minimal set of packages

[Jon Stanley]

On Mon, Jan 30, 2012 at 8:49 PM, Adam Williamson  wrote:

> Yeah, this is kind of problematic, because I don't really want the
> release criteria to prescribe exactly what the 'minimal' package set
> should include. Perhaps we should just explicitly refer to 'the
> installer's "minimal" package set' or something like that

True - come to think of it, I really don't believe that it is QA's
domain to define the task list - but it should be somebody's. What I
don't want is the feature creep of the "minimal" package set - next
thing you know, GNOME will be part of that package set. But I don't
think that QA is the appropriate place to address those concerns :)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for installation with minimal set of packages

[Adam Williamson]

On Mon, 2012-01-30 at 19:57 -0500, Jon Stanley wrote:
> On Mon, Jan 30, 2012 at 7:38 PM, Adam Williamson  wrote:
> 
> > We could phrase it a little bit more similarly to the existing default
> > install criterion:
> >
> > "The installer must be able to complete package installation with the
> > default package set for each supported installation method"
> >
> > Perhaps:
> >
> > "The installer must be able to complete package installation with a
> > minimal usable set of packages"
> 
> Not to be pedantic, but what's the difference in these two? Are we
> actually suggesting that the default package set is *not* useful? :).

The first one is for the 'default' package set - the several GB you get
from the DVD, including X and GNOME and so on. The second is for the
'minimal' package set.

> I get what Petr is going for, but either of these wordings don't get
> it across to me. What I consider a "minimal usable set of packages"
> and what you do may be two entirely different things. What I would
> rather do is specify the minimal amount of function that the system
> must be able to perform, and to me, that reads something like:
> 
> "The installer must be able to install the minimum amount of packages
> required to obtain network connectivity via any supported means and
> install additional packages as the user sees fit"
> 
> Yes, I realize that this criterion, when applied, means that we can't
> install things like vim or openssh during such an installation, and
> that's fine with me. Remote access is not a requirement, nor is the
> ability to edit files (but if we want to add them, that's fine - we
> just need to explicitly define what tasks are able to be performed or
> not performed)

Yeah, this is kind of problematic, because I don't really want the
release criteria to prescribe exactly what the 'minimal' package set
should include. Perhaps we should just explicitly refer to 'the
installer's "minimal" package set' or something like 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: New criterion for installation with minimal set of packages

[Jon Stanley]

On Mon, Jan 30, 2012 at 7:38 PM, Adam Williamson  wrote:

> We could phrase it a little bit more similarly to the existing default
> install criterion:
>
> "The installer must be able to complete package installation with the
> default package set for each supported installation method"
>
> Perhaps:
>
> "The installer must be able to complete package installation with a
> minimal usable set of packages"

Not to be pedantic, but what's the difference in these two? Are we
actually suggesting that the default package set is *not* useful? :).
I get what Petr is going for, but either of these wordings don't get
it across to me. What I consider a "minimal usable set of packages"
and what you do may be two entirely different things. What I would
rather do is specify the minimal amount of function that the system
must be able to perform, and to me, that reads something like:

"The installer must be able to install the minimum amount of packages
required to obtain network connectivity via any supported means and
install additional packages as the user sees fit"

Yes, I realize that this criterion, when applied, means that we can't
install things like vim or openssh during such an installation, and
that's fine with me. Remote access is not a requirement, nor is the
ability to edit files (but if we want to add them, that's fine - we
just need to explicitly define what tasks are able to be performed or
not performed)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: New criterion for reporting failure of installer and accessing debug mode

[Adam Williamson]

On Mon, 2012-01-30 at 11:29 -0500, Petr Schindler wrote:
> I propose final criterion: 
> 
> "The installer must be able to handle the failure and report the
> issue. The installer must be also able to access debug mode."
> 
> We have test case for this - [1]. It's useful to have this feature.
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_traceback_debug_mode

Well, we already have a criterion for 'reporting a failure to Bugzilla'.
We also have some more test cases without matching criteria -
"QA:Testcase Anaconda save traceback to remote system" and
"QA:Testcase_Anaconda_save_traceback_to_disk". Perhaps we need a more
comprehensive approach here.

The existing criterion at Alpha is:

"The installer must be able to report failures to Bugzilla, with
appropriate information included"

So following that model, we could have:

"The installer must be able to enter debugging mode on encountering a
failure"

at Final. Not sure if we want to also add criteria for remote system and
disk, or if we want to downgrade those to non-blocking tests, but right
now they're marked as Alpha, so we should do something.
-- 
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: Change of release level of Mediakit ISO Size test case

[Adam Williamson]

On Mon, 2012-01-30 at 20:40 +, Andre Robatino wrote:
> Petr Schindler  redhat.com> writes:
> 
> > 
> > Test case [1] is marked as alpha release level in [2]. I propose to change 
> > it
> to beta. We have beta criterion
> > "The network installation image, DVD image, and live images for
> release-blocking desktops must meet
> > current size requirements" for this.
> > 
> > [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
> > [2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
> 
> I'd prefer that this test be left at alpha level, since if it fails, then 
> anyone
> who needs to use the corresponding media is blocked from any other testing as
> well. There's also the issue that having to reduce the size of the image at a
> later point runs the risk of causing further problems in deciding what to cut.
> If some media are considered less important than others, maybe there could be
> separate size tests for the different media.

We made this Beta not Alpha in the criteria on purpose, specifically
because we don't think it's a significant enough problem if the lives
are over-size at Alpha stage. It *may* be worth requiring at least the
DVD to meet size requirements at Alpha size, although even if it's over,
you can still test it in a VM or with a USB stick. I definitely think we
shouldn't make the live sizes mandatory at Alpha.
-- 
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: New criterion for Checksum

[Adam Williamson]

On Mon, 2012-01-30 at 18:02 +, Andre Robatino wrote:
> Petr Schindler  redhat.com> writes:
> 
> > I propose new final criterion: 
> > 
> > "There must be published correct checksum for each ISO media. Also if there 
> > is
> embedded checksum on ISO
> > media, it must be correct."  
> > 
> > I think we should check this. We have already test case [1]. I propose to
> change release level for this test
> > case to final.
> > 
> > [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums
> 
> I think that having a published correct checksum for each ISO should be Alpha
> level. If the ISO can't be verified, then the results of any other testing on 
> it
> are suspect. Also, publishing the correct checksums can be done without 
> altering
> the ISOs themselves, so it's easy to ensure that this test passes. Getting the
> embedded checksum correct is less important since an independent check is
> possible.

Yeah, I did think that too. It seems like the kind of thing that should
always be correct.
-- 
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: New test case for testing if services start properly

[Adam Williamson]

On Mon, 2012-01-30 at 11:37 -0500, Petr Schindler wrote:
> I propose new test cases [1]. This test case is related to final criterion:
> 
> "All services in a default install must start properly"
> 
> We don't have test case for this right now.
> 
> [1] 
> https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Services_start

I think the instructions are possibly a tad too tool-specific. Instead
of explicitly referring to alt-f2 and gnome-terminal, it may be more
future-proof to simply say:

'In a console, run the command {{command|systemctl --all --failed}}'

You can also drop the comma from "This test case tests, whether all
services start properly in a default install." It's not needed.
-- 
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: New testcase for installation without selinux

[Adam Williamson]

On Mon, 2012-01-30 at 11:36 -0500, Petr Schindler wrote:
> I propose new test case [1]. This test case is related to final criterion:
> 
> "The installed system must run normally if the user chooses to install 
> without SELinux"
> 
> There is no test case for this now.
> 
> I have one note on this. There is used noselinux option, but it doesn't work 
> now. I filled bug [2] there is another option with the same effect - 
> selinux=0 and this one works fine, but Anaconda have noselinux in 
> documentation, so it should work and they're working on it.
> 
> [1] 
> https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Install_without_selinux
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=784828

selinux=0 is intended as a temporary kernel parameter to completely
disable SELinux on a given boot of an installed system, really. It's
probably not exactly the best way to achieve an SELinux-free *install*,
though it may happen to have that effect at present. So yeah, I think it
makes more sense to get anaconda team to fix the 'noselinux' option.
-- 
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: Proposal for enhancement of criterion

[Adam Williamson]

On Mon, 2012-01-30 at 11:35 -0500, Petr Schindler wrote:
> I propose to enhance alpha criterion 
> 
> "The installer must be able to report failures to Bugzilla, with appropriate 
> information included"
> to 
> "The installer must be able to report failures to Bugzilla, remote system and 
> local disk, with appopriate information included"
> 
> Especially saving failures to disk is important for installation without net 
> access. There are test cases [1], [2] and [3] for testing this feature.
> 
> [1] 
> https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla
> [2] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_disk
> [3] 
> https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system

Ah, that's part of my last-reply-but-one. :) I think certainly adding
local disk at Alpha is reasonable. I'm not so sure about supporting
saving to a remote system via ssh at Alpha.
-- 
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: Proposal for removing Boot method efidisk test case

[Adam Williamson]

On Mon, 2012-01-30 at 11:33 -0500, Petr Schindler wrote:
> I propose to remove [1] test case as we don't need it anymore. EFI
> booting is handled by regular image.
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_efidisk.img

Ack. For F17, I believe, the plan is not to ship an efidisk.img image at
all.
-- 
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: New criterion for updates.img using

[Adam Williamson]

On Mon, 2012-01-30 at 11:28 -0500, Petr Schindler wrote:
> I propose new beta criterion: 
> 
> "The installer must be able to use updates.img obtained by any supported way"
> 
> I think, that this should be at criteria too. There are test cases which uses 
> this feature - [1], [2]
> 
> [1] 
> https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source
> [2] 
> https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media

Similar to previous:

"The installer must be able to retrieve and use an [[Anaconda/Updates|
installer update image]] by any supported method"

Though this may be too broad, and we may have the problem we had with
kickstarts in F16, where some really obscure retrieval method doesn't
work and we don't really want to block the release for that. We might
want to be more specific and only support more common updates.img
deployment channels.
-- 
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: New criterion for updates.img via URL

[Adam Williamson]

On Mon, 2012-01-30 at 11:26 -0500, Petr Schindler wrote:
> I propose new alpha criterion: 
> 
> "The installer must be able to download and apply updates.img file
> using a HTTP url and use it"

Small proofread suggestion:

"The installer must be able to download and use an [[Anaconda/Updates|
installer update image]] from an HTTP server"
-- 
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: New criterion for installation with minimal set of packages

[Adam Williamson]

On Mon, 2012-01-30 at 11:25 -0500, Petr Schindler wrote:
> I propose new beta criterion: 
> 
> "The installer must be able to install system with minimal usable set of 
> packages."
> 
> There is test case [1] associated with alpha, I'd change it to beta release 
> level.
> 
> [1] 
> https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Install

We could phrase it a little bit more similarly to the existing default
install criterion:

"The installer must be able to complete package installation with the
default package set for each supported installation method"

Perhaps:

"The installer must be able to complete package installation with a
minimal usable set of 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: New criterion for Memory test

[Adam Williamson]

On Mon, 2012-01-30 at 11:23 -0500, Petr Schindler wrote:
> I propose new final criterion: 
> 
> "The installer must be able to run memory test." 
> 
> This feature is very useful and should work. We have test case for
> this yet [1]. I'd move it to final release level.
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Memtest86

Well, it's not actually the installer. memtestx86 is a completely
standalone thing which we just put on the images, with a boot menu
option: if you pick it, nothing Fedora-ish at all actually runs.

Perhaps:

"All release media must include a standalone memory test utility. A boot
menu option to launch this utility must be present and must work
correctly."
-- 
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: New criterion for Checksum

[Adam Williamson]

On Mon, 2012-01-30 at 11:23 -0500, Petr Schindler wrote:
> I propose new final criterion: 
> 
> "There must be published correct checksum for each ISO media. Also if
> there is embedded checksum on ISO media, it must be correct."

Small grammar fixes:

"A correct checksum published for each official release image. In the
case of any release image(s) which have embedded checksums, these
checksums must be correct."

> I think we should check this. We have already test case [1]. I propose
> to change release level for this test case to final.
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums

That sounds okay.
-- 
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: Change of release level of Kickstart Http Server test case

[Adam Williamson]

On Mon, 2012-01-30 at 11:21 -0500, Petr Schindler wrote:
> Test case [1] is associated with alpha release level in [2]. I propose to 
> change it to beta level, where is criterion: "The installer must be able to 
> use all kickstart delivery methods."
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Kickstart_Http_Server_Ks_Cfg
> [2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Ack!

In case you weren't aware, note that there are templates for the
validation pages:

https://fedoraproject.org/wiki/QA:Fedora_17_Install_Results_Template
https://fedoraproject.org/wiki/QA:Desktop_validation_results_template
https://fedoraproject.org/wiki/QA:Base_validation_results_template

So changes like this should be made to the template pages.
-- 
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: Change of release level of Mediakit ISO Size test case

[Adam Williamson]

On Mon, 2012-01-30 at 11:20 -0500, Petr Schindler wrote:
> Test case [1] is marked as alpha release level in [2]. I propose to change it 
> to beta. We have beta criterion "The network installation image, DVD image, 
> and live images for release-blocking desktops must meet current size 
> requirements" for this.
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
> [2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

Ack!
-- 
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: Installation from USB-written images (5/5): DVD.iso + Livecd-iso-to-disk

[Adam Williamson]

On Mon, 2012-01-30 at 08:17 -0500, Josef Skladanka wrote:
> This testcase [1] should ensure, that if the user uses USB stick and 
> transfers the DVD.iso to it using Livecd-iso-to-disk, the installation can be 
> successfully finished.
> Installer should be able to use the DVD local package source options, but 
> this is caused by the way LITD writes the image to the USB stick.
> 
> I propose this as a Alpha verification testcase.
> 
> ---
> 
> = Description =
> 
> This test verifies that Fedora DVD Image can be booted & installed from USB 
> stick
> 
> There are more methods to create the DVD.iso USB stick, this test covers 
> Livecd-iso-to-disk. 
> 
> == Setup ==
> 
> * Prepare the DVD ISO image and USB stick.
> * Copy the DVD.iso to the USB stick using Livecd-iso-to-disk.  [3]
> 
> == How to test ==
> 
> * Insert the USB stick containing DVD.iso, and boot the system under test
> * Proceed with the installation the usual way. 
> 
> == Expected Results ==
> 
> * Graphical boot menu is displayed for users to select install options. 
> Navigating the menu and selecting entries must work. If no option is 
> selected, the installer should load after a reasonable timeout
> * Installer boots into loader and prompts for language, keymap
> * Installer transitions to anaconda without error
> * Installer should be able to use the DVD local package source options 

We could make this a bit clearer - something like 'the installer should
not require you to configure a package repository, it should be able to
install using the packages present on the USB stick'.

> * ??? Installer does not offer the USB stick as a target for bootloader 
> and/or partitioning 

We could probably add bits to the 'how to test' section for this,
something like. For instance, ask the user to boot the installed system
without the USB stick plugged in, to ensure the bootloader was installed
to the hard disk, not the USB stick.
-- 
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: Installation from USB-written images (1/5): Live.iso + dd

[Adam Williamson]

On Mon, 2012-01-30 at 07:58 -0500, Josef Skladanka wrote:
> This testcase [1] should ensure, that if the user uses dd to transfer the 
> Fedora Live.iso to USB stick, the boot process works 'as expected'.
> 
> I propose this as a Alpha verification testcase.
> 
> ---
> 
> = Description =
> 
> This test verifies that Fedora Live Image can be booted from USB stick.
> 
> There are more methods to create the Live USB stick, this test covers dd.
> 
> == Setup ==
> 
> * Prepare the Live ISO image and USB stick.
> * Copy the Live.iso to the USB stick using dd [1] 
> 
> == How to test ==
> 
> * Insert the USB stick containing Live.iso, and boot the system under test
> * At the boot prompt, interrupt the automatic boot sequence by pressing any 
> key. Then select the menu option Boot. 
> 
> == Expected Results ==
> 
> * A graphical boot menu is displayed and the graphics look reasonably good. 
> While hi-res images aren't supported in the boot menu, the graphics should 
> not look extremely pixelated.
> * Upon selecting Boot, the Live image boots successfully. 
> 
> ---
> 
> 
> 
> [1] 
> https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_Live_dd

Thanks for your work on this!

For the three test cases that cover writing live images to USB,
including this one, we want to test not just that the image *boots*, but
that an installation can be successfully performed using the stick.
Could you extend the test cases to cover this?
-- 
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: /usrmove Nightlies Testing?

[Adam Williamson]

On Mon, 2012-01-30 at 11:18 +, Frank Murphy wrote:
> Any idea on when /usrmove nightlies.
> Might be ready for testing.

Nightlies won't include the /usr move stuff until it's tagged into
Rawhide, but tflink is trying to build a special boot.iso with the /usr
move packages included. So far he's having trouble.
-- 
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: F17's usrmove and rpmfusion?

[Josh Boyer]

On Mon, Jan 30, 2012 at 4:07 PM, Bill Nottingham  wrote:
> Josh Boyer (jwbo...@gmail.com) said:
>> On Mon, Jan 30, 2012 at 3:52 PM, Bill Nottingham  wrote:
>> > Rob Healey (robheal...@gmail.com) said:
>> >> Can anyone tell me if rpmfusion's rawhide packages have been updated yet
>> >> for rpm guard?
>> >
>> > Given that, at best, rpmfusion builds against rawhide/branched Fedora,
>> > and that the converted packages only live in the side repository at the
>> > moment... no.
>> >
>> > It's not even clear that any rpmfusion packages would need modified.
>>
>> Harald has a patch to kernel.spec to install modules in /usr/lib/modules/
>> instead of /lib/.  When that goes in, I would think the rpmfusion kmods would
>> need a similar adjustment.
>
> As long as /lib redirects to /usr/lib... it shouldn't be *required*.

Then the patch to kernel.spec shouldn't be either.  My tiny brain says that if
one switches, the rest should too.

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

Re: Fedora 17’s unified filesystem (/usr-move)

[Orion Poplawski]

On 01/30/2012 12:17 PM, Orion Poplawski wrote:

On 01/27/2012 06:10 AM, Harald Hoyer wrote:

Until the rawhide repository gets all the converted rpms, use the f17-usrmove
repository to update the system after the filesystem conversion and disable
rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo

Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo
[f17-usrmove]
name=Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch
enabled=1
metadata_expire=1d
gpgcheck=0

# yum clean all
# yum upgrade


Looks like a no-go with multilib:

Error: Protected multilib versions: libacl-2.2.51-5.fc17.x86_64 !=
libacl-2.2.51-3.fc17.i686
Error: Protected multilib versions: db4-4.8.30-7.fc17.x86_64 !=
db4-4.8.30-5.fc17.i686
Error: Protected multilib versions: nspr-4.9-0.2.fc17.beta3.1.x86_64 !=
nspr-4.9-0.2.fc17.beta3.i686
Error: Protected multilib versions: krb5-libs-1.10-1.fc17.x86_64 !=
krb5-libs-1.10-0.fc17.beta1.2.i686
Error: Protected multilib versions: libuuid-2.20.1-5.fc17.x86_64 !=
libuuid-2.20.1-4.fc17.i686
Error: Protected multilib versions: nss-softokn-3.13.1-19.fc17.x86_64 !=
nss-softokn-3.13.1-17.fc17.i686
Error: Protected multilib versions: libattr-2.4.46-5.fc17.x86_64 !=
libattr-2.4.46-3.fc17.i686
Error: Protected multilib versions: libselinux-2.1.9-6.fc17.x86_64 !=
libselinux-2.1.9-3.fc17.i686
Error: Protected multilib versions: nss-softokn-freebl-3.13.1-19.fc17.x86_64
!= nss-softokn-freebl-3.13.1-17.fc17.i686
Error: Protected multilib versions: libdb-5.2.36-4.fc17.x86_64 !=
libdb-5.2.36-2.fc17.i686

I suppose I could add in the i386 repo...



I added:

[f17-usrmove-i386]
name=Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/i386
enabled=1
metadata_expire=1d
gpgcheck=0

And got the following errors:

  Updating   : coreutils-8.15-5.fc17.x86_64 
 7/223

/var/tmp/rpm-tmp.T9mWTk: line 1: /usr/bin/grep: No such file or directory

  Updating   : filesystem-3-1.fc17.x86_64 
23/223

Error unpacking rpm package filesystem-3-1.fc17.x86_64
error: unpacking of archive failed on file /bin: cpio: rename
error: filesystem-3-1.fc17.x86_64: install failed

error: filesystem-2.4.46-1.fc17.x86_64: erase skipped

Non-fatal POSTTRANS scriptlet failure in rpm package 
kdesdk-okteta-4.8.0-1.fc17.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package 
kdesdk-kompare-4.8.0-1.fc17.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package 
kdesdk-kioslave-4.8.0-1.fc17.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package 
kdesdk-cervisia-4.8.0-1.fc17.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package 
kdesdk-kcachegrind-4.8.0-1.fc17.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package 
kdesdk-umbrello-4.8.0-1.fc17.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package 
kdesdk-kapptemplate-4.8.0-1.fc17.x86_64
Non-fatal POSTTRANS scriptlet failure in rpm package 
kdesdk-kuiviewer-4.8.0-1.fc17.x86_64


filesystem-2.4.46-1.fc17.x86_64 was supposed to be removed but is not!


Now I get:

# ls -l /
-bash: /bin/ls: No such file or directory

Shutdown did not complete.  Boot now fails with:

dracut: Switching root
switch_root: failed to execute /etc/init: Permission denied
Kernel panic - not syncing: Attempted to kill init!

even with enforcing=0


Anyone want any postmortem info before I reinstall the VM?

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office  FAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: F17's usrmove and rpmfusion?

[Bill Nottingham]

Josh Boyer (jwbo...@gmail.com) said: 
> On Mon, Jan 30, 2012 at 3:52 PM, Bill Nottingham  wrote:
> > Rob Healey (robheal...@gmail.com) said:
> >> Can anyone tell me if rpmfusion's rawhide packages have been updated yet
> >> for rpm guard?
> >
> > Given that, at best, rpmfusion builds against rawhide/branched Fedora,
> > and that the converted packages only live in the side repository at the
> > moment... no.
> >
> > It's not even clear that any rpmfusion packages would need modified.
> 
> Harald has a patch to kernel.spec to install modules in /usr/lib/modules/
> instead of /lib/.  When that goes in, I would think the rpmfusion kmods would
> need a similar adjustment.

As long as /lib redirects to /usr/lib... it shouldn't be *required*.

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

Re: F17's usrmove and rpmfusion?

[Josh Boyer]

On Mon, Jan 30, 2012 at 3:52 PM, Bill Nottingham  wrote:
> Rob Healey (robheal...@gmail.com) said:
>> Can anyone tell me if rpmfusion's rawhide packages have been updated yet
>> for rpm guard?
>
> Given that, at best, rpmfusion builds against rawhide/branched Fedora,
> and that the converted packages only live in the side repository at the
> moment... no.
>
> It's not even clear that any rpmfusion packages would need modified.

Harald has a patch to kernel.spec to install modules in /usr/lib/modules/
instead of /lib/.  When that goes in, I would think the rpmfusion kmods would
need a similar adjustment.

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

Fedora 15 updates-testing report

[updates]

The following Fedora 15 Security updates need testing:

https://admin.fedoraproject.org/updates/FEDORA-2012-0888/curl-7.21.3-13.fc15

https://admin.fedoraproject.org/updates/FEDORA-2012-0939/moodle-1.9.16-1.fc15
https://admin.fedoraproject.org/updates/FEDORA-2012-0917/znc-0.204-3.fc15
https://admin.fedoraproject.org/updates/FEDORA-2012-0916/bip-0.8.8-2.fc15
https://admin.fedoraproject.org/updates/FEDORA-2011-16284/krb5-1.9.2-4.fc15
https://admin.fedoraproject.org/updates/FEDORA-2012-0987/mysql-5.5.20-1.fc15
https://admin.fedoraproject.org/updates/FEDORA-2012-0752/jetty-6.1.26-7.fc15

https://admin.fedoraproject.org/updates/FEDORA-2012-0826/BackupPC-3.2.1-7.fc15

https://admin.fedoraproject.org/updates/FEDORA-2012-0849/polipo-1.0.4.1-6.fc15

https://admin.fedoraproject.org/updates/FEDORA-2011-17233/tor-0.2.1.32-1500.fc15

https://admin.fedoraproject.org/updates/FEDORA-2012-0353/pdns-2.9.22.5-1.fc15

https://admin.fedoraproject.org/updates/FEDORA-2011-16980/asterisk-1.8.7.2-1.fc15


The following Fedora 15 Critical Path updates have yet to be approved:

https://admin.fedoraproject.org/updates/FEDORA-2012-0987/mysql-5.5.20-1.fc15

https://admin.fedoraproject.org/updates/FEDORA-2012-0997/rsyslog-5.8.7-1.fc15

https://admin.fedoraproject.org/updates/FEDORA-2012-0929/rpm-4.9.1.2-3.fc15.3

https://admin.fedoraproject.org/updates/FEDORA-2012-0943/system-config-printer-1.3.8-2.fc15

https://admin.fedoraproject.org/updates/FEDORA-2012-0762/redhat-rpm-config-9.1.0-16.fc15

https://admin.fedoraproject.org/updates/FEDORA-2012-0659/virtuoso-opensource-6.1.4-4.fc15

https://admin.fedoraproject.org/updates/FEDORA-2011-13190/phonon-backend-gstreamer-4.5.90-2.fc15,phonon-4.5.57-1.20110914.fc15

https://admin.fedoraproject.org/updates/FEDORA-2011-11955/evolution-mapi-3.0.3-2.fc15,evolution-exchange-3.0.3-1.fc15,evolution-3.0.3-1.fc15,evolution-data-server-3.0.3-1.fc15,gtkhtml3-4.0.2-1.fc15


The following builds have been pushed to Fedora 15 updates-testing

haproxy-1.4.19-1.fc15
kicad-2012.01.19-1.rev3256.fc15
kile-2.1.1-1.fc15
pcmanx-gtk2-1.1-1.fc15
perl-Sub-WrapPackages-2.0-6.fc15
picocom-1.6-4.fc15
spice-xpi-2.7-1.fc15
system-config-printer-1.3.8-2.fc15

Details about builds:



 haproxy-1.4.19-1.fc15 (FEDORA-2012-1041)
 HA-Proxy is a TCP/HTTP reverse proxy for high availability environments

Update Information:

Update to latest upstream version 1.4.19

ChangeLog:

* Sun Jan 29 2012 Jeremy Hinegardner  - 1.4.19-1
- Update to 1.4.19

References:

  [ 1 ] Bug #773639 - haproxy update to 1.4.19
https://bugzilla.redhat.com/show_bug.cgi?id=773639




 kicad-2012.01.19-1.rev3256.fc15 (FEDORA-2012-1029)
 Electronic schematic diagrams and printed circuit board artwork

Update Information:

New upstream stable release

ChangeLog:

* Sun Jan 29 2012 Alain Portal  
2012.01.19-1.rev3256
- New upstream release
- Add doxygen as build requirement
- Add bulgarian language
- Add it and pl tutorials
- Update versioning patch
- Add patch to fix python syntax in bom-in-python (Gerd v. Egidy 
)
- Add a new patch to fix a new link time error
- Fix a PS plotting scale bug
- Move junction button close to no connexion button
- Fix thermal relief gap calculation for circular pads in pcbnew
- Add undo/redo support for Pcbnew auto place, auto move, and auto route 
features.
- Make CvPcb correctly preview the selected component footprint if one has 
already been assigned.
- Fix a bug in pcb calculation
- Width tuning (width correction) for PS plotting of tracks, pads and vias




 kile-2.1.1-1.fc15 (FEDORA-2012-1047)
 (La)TeX source editor and TeX shell

Update Information:

An update of Kile to the latest upstream bugfix release, version 2.1.1.

Fixes:
- Restore the behaviour of LaTeX environment completion to what it was in 
version 2.0 (Patch by Holger Danielsson)
- Ensure that Kile can be offered as application to open LaTeX documents in 
Nautilus, for instance (kde#275438)
- Avoid crashes when closing Kile with two (or more) opened projects (Patch by 
Eugene Shal

Fedora 16 updates-testing report

[updates]

The following Fedora 16 Security updates need testing:

https://admin.fedoraproject.org/updates/FEDORA-2012-0913/moodle-2.0.7-1.fc16
https://admin.fedoraproject.org/updates/FEDORA-2012-0921/znc-0.204-3.fc16
https://admin.fedoraproject.org/updates/FEDORA-2012-0941/bip-0.8.8-2.fc16
https://admin.fedoraproject.org/updates/FEDORA-2012-0730/jetty-6.1.26-8.fc16
https://admin.fedoraproject.org/updates/FEDORA-2012-0972/mysql-5.5.20-1.fc16

https://admin.fedoraproject.org/updates/FEDORA-2012-0825/BackupPC-3.2.1-7.fc16

https://admin.fedoraproject.org/updates/FEDORA-2012-0840/polipo-1.0.4.1-6.fc16
https://admin.fedoraproject.org/updates/FEDORA-2012-1028/sudo-1.8.3p1-2.fc16

https://admin.fedoraproject.org/updates/FEDORA-2011-14691/tomcat6-6.0.32-19.fc16


The following Fedora 16 Critical Path updates have yet to be approved:

https://admin.fedoraproject.org/updates/FEDORA-2012-1028/sudo-1.8.3p1-2.fc16

https://admin.fedoraproject.org/updates/FEDORA-2012-1031/coreutils-8.12-6.fc16

https://admin.fedoraproject.org/updates/FEDORA-2012-1025/alsa-lib-1.0.25-1.fc16
https://admin.fedoraproject.org/updates/FEDORA-2012-0972/mysql-5.5.20-1.fc16
https://admin.fedoraproject.org/updates/FEDORA-2012-0984/lvm2-2.02.86-6.fc16
https://admin.fedoraproject.org/updates/FEDORA-2012-0934/strigi-0.7.7-1.fc16

https://admin.fedoraproject.org/updates/FEDORA-2012-0820/schroedinger-1.0.11-1.fc16

https://admin.fedoraproject.org/updates/FEDORA-2012-0689/virtuoso-opensource-6.1.4-4.fc16

https://admin.fedoraproject.org/updates/FEDORA-2012-0590/qrencode-3.2.0-1.fc16

https://admin.fedoraproject.org/updates/FEDORA-2011-15301/lxpanel-0.5.8-1.fc16,lxinput-0.3.1-1.fc16,lxsession-edit-0.2.0-1.fc16,lxrandr-0.1.2-1.fc16,lxpolkit-0.1.0-1.fc16,lxterminal-0.1.11-1.fc16,lxshortcut-0.1.2-1.fc16


The following builds have been pushed to Fedora 16 updates-testing

cifs-utils-5.3-1.fc16
coreutils-8.12-6.fc16
culmus-fonts-0.121-1.fc16
haproxy-1.4.19-1.fc16
kicad-2012.01.19-1.rev3256.fc16
kile-2.1.1-1.fc16
libguestfs-1.16.2-1.fc16
pcmanx-gtk2-1.1-1.fc16
perl-Cairo-1.090-1.fc16
perl-Sub-WrapPackages-2.0-7.fc16
php-channel-horde-1.0-1.fc16
picocom-1.6-4.fc16
spice-xpi-2.7-1.fc16
sssd-1.7.0-1.fc16
sudo-1.8.3p1-2.fc16
system-config-printer-1.3.8-2.fc16

Details about builds:



 cifs-utils-5.3-1.fc16 (FEDORA-2012-1037)
 Utilities for mounting and managing CIFS mounts

Update Information:

This update adds the cifscreds utility to cifs-utils. That
utility requires a v3.3 kernel, and so should be usable once
F16 gets that kernel version.

ChangeLog:

* Sat Jan 28 2012 Jeff Layton  5.3-1
- update to 5.3




 coreutils-8.12-6.fc16 (FEDORA-2012-1031)
 A set of basic GNU tools commonly used in shell scripts

Update Information:

- output the correct ownership in chown -v (upstream bug #10636)
- do not use shebang in sourced colorls.csh
- su: fix shell suspend in tcsh (#597928)
- variable "u" should be static in uname processor type patch
- various multibyte patch fixes:
  - fix cut output-delimiter option
  - prevent infinite loop in sort when ignoring chars
  - prevent using unitialized variable in cut
  - fix pr -c and pr -v segfault with multibyte locales
  - fix stack smashing, buffer overflow and invalid output of pr (#772172)

ChangeLog:

* Mon Jan 30 2012 Kamil Dudka  - 8.12-6
- do not use shebang in sourced colorls.csh
- su: fix shell suspend in tcsh (#597928)
- variable "u" should be static in uname processor type patch
- various multibyte patch fixes:
  - fix cut output-delimiter option
  - prevent infinite loop in sort when ignoring chars
  - prevent using unitialized variable in cut
  - fix pr -c and pr -v segfault with multibyte locales
  - fix stack smashing, buffer overflow and invalid output of pr (#772172)
* Sun Jan 29 2012 Kamil Dudka  - 8.12-5
- output the correct ownership in chown -v (upstream bug #10636)
* Mon Oct 24 2011 Ondrej Vasik  - 8.12-4
- require at least pam >= 1.1.3-7 (#748215)
* Fri Jul 29 2011 Ondrej Vasik  - 8.12-3
- use acl_extended_file_nofollow() if available (#692823)

References:

  [ 1 ] Bug #597928 - shell suspend won't work
https://bugzilla.redhat.com/show_bug.cgi?id=597928
  [ 2 ] Bug #772172 - pr command failed on multibyte test
https://bugzilla.

Re: Fedora 17’s unified filesystem (/usr-move)

[Bill Nottingham]

Martin Langhoff (martin.langh...@gmail.com) said: 
> On Mon, Jan 30, 2012 at 3:47 PM, Bill Nottingham  wrote:
> > Assuming /bin -> /usr/bin link is packaged, yes.
> 
> Wow, it follows the symlink created by a 3rd package.

Technically, the link doesn't even need to be packaged; as long as /bin
exists in the RPM db (as a dir or as a symlink), RPM will follow the link
and resolve the dependency.

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

Re: F17's usrmove and rpmfusion?

[Bill Nottingham]

Rob Healey (robheal...@gmail.com) said: 
> Can anyone tell me if rpmfusion's rawhide packages have been updated yet
> for rpm guard?

Given that, at best, rpmfusion builds against rawhide/branched Fedora,
and that the converted packages only live in the side repository at the
moment... no.

It's not even clear that any rpmfusion packages would need modified.

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

Re: Fedora 17’s unified filesystem (/usr-move)

[Bill Nottingham]

Jef Spaleta (jspal...@gmail.com) said: 
> On Mon, Jan 30, 2012 at 10:17 AM, Orion Poplawski  wrote:
> > I suppose I could add in the i386 repo...
> 
> Is this just a side effect of the special repository structure?  For
> rawhide itself, once tagged in, would the 32bit packages be available
> on the 64bit system without additional intervention? Or is there a
> defect in the specfiles?

It's a side-effect of the special repo structure - koji repos aren't multilib. 

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

Re: Fedora 17’s unified filesystem (/usr-move)

[Bill Nottingham]

Martin Langhoff (martin.langh...@gmail.com) said: 
> On Fri, Jan 27, 2012 at 8:10 AM, Harald Hoyer  wrote:
> > Fedora 17 will locate the entire base operating system in /usr. The 
> > directories
> > /bin, /sbin, /lib, /lib64 will only be symlinks:
> >  /bin → /usr/bin
> 
> Interesting!
> 
> Do we need to teach rpm / yum about the equivalence, when resolving
> dependencies?
> 
> For a trivial example -- if package A depends on /bin/foo, will yum &
> rpm be satisfied with /usr/bin/foo?

Assuming /bin -> /usr/bin link is packaged, yes.

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

Change of release level of Mediakit ISO Size test case

[Andre Robatino]

Petr Schindler  redhat.com> writes:

> 
> Test case [1] is marked as alpha release level in [2]. I propose to change it
to beta. We have beta criterion
> "The network installation image, DVD image, and live images for
release-blocking desktops must meet
> current size requirements" for this.
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
> [2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test

I'd prefer that this test be left at alpha level, since if it fails, then anyone
who needs to use the corresponding media is blocked from any other testing as
well. There's also the issue that having to reduce the size of the image at a
later point runs the risk of causing further problems in deciding what to cut.
If some media are considered less important than others, maybe there could be
separate size tests for the different media.




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

Re: Fedora 17’s unified filesystem (/usr-move)

[Jef Spaleta]

On Mon, Jan 30, 2012 at 10:17 AM, Orion Poplawski  wrote:
> I suppose I could add in the i386 repo...

Is this just a side effect of the special repository structure?  For
rawhide itself, once tagged in, would the 32bit packages be available
on the 64bit system without additional intervention? Or is there a
defect in the specfiles?

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

Re: Fedora 17’s unified filesystem (/usr-move)

[Orion Poplawski]

On 01/27/2012 06:10 AM, Harald Hoyer wrote:

Until the rawhide repository gets all the converted rpms, use the f17-usrmove
repository to update the system after the filesystem conversion and disable
rawhide in the file /etc/yum.repos.d/fedora-rawhide.repo

Add f17-usrmove in the file /etc/yum.repos.d/f17-usrmove.repo
  [f17-usrmove]
  name=Fedora $releasever - $basearch
  failovermethod=priority
  baseurl=http://koji.fedoraproject.org/repos/f17-usrmove/latest/$basearch
  enabled=1
  metadata_expire=1d
  gpgcheck=0

# yum clean all
# yum upgrade


Looks like a no-go with multilib:

Error: Protected multilib versions: libacl-2.2.51-5.fc17.x86_64 != 
libacl-2.2.51-3.fc17.i686
Error: Protected multilib versions: db4-4.8.30-7.fc17.x86_64 != 
db4-4.8.30-5.fc17.i686
Error: Protected multilib versions: nspr-4.9-0.2.fc17.beta3.1.x86_64 != 
nspr-4.9-0.2.fc17.beta3.i686
Error: Protected multilib versions: krb5-libs-1.10-1.fc17.x86_64 != 
krb5-libs-1.10-0.fc17.beta1.2.i686
Error: Protected multilib versions: libuuid-2.20.1-5.fc17.x86_64 != 
libuuid-2.20.1-4.fc17.i686
Error: Protected multilib versions: nss-softokn-3.13.1-19.fc17.x86_64 != 
nss-softokn-3.13.1-17.fc17.i686
Error: Protected multilib versions: libattr-2.4.46-5.fc17.x86_64 != 
libattr-2.4.46-3.fc17.i686
Error: Protected multilib versions: libselinux-2.1.9-6.fc17.x86_64 != 
libselinux-2.1.9-3.fc17.i686
Error: Protected multilib versions: nss-softokn-freebl-3.13.1-19.fc17.x86_64 
!= nss-softokn-freebl-3.13.1-17.fc17.i686
Error: Protected multilib versions: libdb-5.2.36-4.fc17.x86_64 != 
libdb-5.2.36-2.fc17.i686


I suppose I could add in the i386 repo...

--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office  FAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for Checksum

[Andre Robatino]

Petr Schindler  redhat.com> writes:

> I propose new final criterion: 
> 
> "There must be published correct checksum for each ISO media. Also if there is
embedded checksum on ISO
> media, it must be correct."  
> 
> I think we should check this. We have already test case [1]. I propose to
change release level for this test
> case to final.
> 
> [1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums

I think that having a published correct checksum for each ISO should be Alpha
level. If the ISO can't be verified, then the results of any other testing on it
are suspect. Also, publishing the correct checksums can be done without altering
the ISOs themselves, so it's easy to ensure that this test passes. Getting the
embedded checksum correct is less important since an independent check is
possible.




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

New test case for testing if services start properly

[Petr Schindler]

I propose new test cases [1]. This test case is related to final criterion:

"All services in a default install must start properly"

We don't have test case for this right now.

[1] 
https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Services_start
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New testcase for installation without selinux

[Petr Schindler]

I propose new test case [1]. This test case is related to final criterion:

"The installed system must run normally if the user chooses to install without 
SELinux"

There is no test case for this now.

I have one note on this. There is used noselinux option, but it doesn't work 
now. I filled bug [2] there is another option with the same effect - selinux=0 
and this one works fine, but Anaconda have noselinux in documentation, so it 
should work and they're working on it.

[1] 
https://fedoraproject.org/wiki/User:Pschindl/Draft_QA_Testcase_Install_without_selinux
[2] https://bugzilla.redhat.com/show_bug.cgi?id=784828
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Proposal for enhancement of criterion

[Petr Schindler]

I propose to enhance alpha criterion 

"The installer must be able to report failures to Bugzilla, with appropriate 
information included"
to 
"The installer must be able to report failures to Bugzilla, remote system and 
local disk, with appopriate information included"

Especially saving failures to disk is important for installation without net 
access. There are test cases [1], [2] and [3] for testing this feature.

[1] 
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_bugzilla
[2] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_disk
[3] 
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_save_traceback_to_remote_system
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Proposal for removing Boot method efidisk test case

[Petr Schindler]

I propose to remove [1] test case as we don't need it anymore. EFI booting is 
handled by regular image.

[1] https://fedoraproject.org/wiki/QA:Testcase_Boot_Methods_efidisk.img
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for reporting failure of installer and accessing debug mode

[Petr Schindler]

I propose final criterion: 

"The installer must be able to handle the failure and report the issue. The 
installer must be also able to access debug mode."

We have test case for this - [1]. It's useful to have this feature.

[1] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_traceback_debug_mode
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for updates.img using

[Petr Schindler]

I propose new beta criterion: 

"The installer must be able to use updates.img obtained by any supported way"

I think, that this should be at criteria too. There are test cases which uses 
this feature - [1], [2]

[1] 
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_installation_source
[2] 
https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_local_media
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for updates.img via URL

[Petr Schindler]

I propose new alpha criterion: 

"The installer must be able to download and apply updates.img file using a HTTP 
url and use it"

We have test cases for this [1], but no criterion. I think it's pretty 
importing -> alpha.

[1] https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for installation with minimal set of packages

[Petr Schindler]

I propose new beta criterion: 

"The installer must be able to install system with minimal usable set of 
packages."

There is test case [1] associated with alpha, I'd change it to beta release 
level.

[1] 
https://fedoraproject.org/wiki/QA:Testcase_Package_Sets_Minimal_Package_Install
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for Memory test

[Petr Schindler]

I propose new final criterion: 

"The installer must be able to run memory test." 

This feature is very useful and should work. We have test case for this yet 
[1]. I'd move it to final release level.

[1] https://fedoraproject.org/wiki/QA:Testcase_Memtest86
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for Memory test

[Petr Schindler]

I propose new final criterion: 

"The installer must be able to run memory test." 

This feature is very useful and should work. We have test case for this yet 
[1]. I'd move it to final release level.

[1] https://fedoraproject.org/wiki/QA:Testcase_Memtest86
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New criterion for Checksum

[Petr Schindler]

I propose new final criterion: 

"There must be published correct checksum for each ISO media. Also if there is 
embedded checksum on ISO media, it must be correct."  

I think we should check this. We have already test case [1]. I propose to 
change release level for this test case to final.

[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Checksums
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Change of release level of Kickstart Http Server test case

[Petr Schindler]

Test case [1] is associated with alpha release level in [2]. I propose to 
change it to beta level, where is criterion: "The installer must be able to use 
all kickstart delivery methods."

[1] https://fedoraproject.org/wiki/QA:Testcase_Kickstart_Http_Server_Ks_Cfg
[2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Change of release level of Mediakit ISO Size test case

[Petr Schindler]

Test case [1] is marked as alpha release level in [2]. I propose to change it 
to beta. We have beta criterion "The network installation image, DVD image, and 
live images for release-blocking desktops must meet current size requirements" 
for this.

[1] https://fedoraproject.org/wiki/QA:Testcase_Mediakit_ISO_Size
[2] https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New testcases, criteria and modifications of present ones proposal

[Petr Schindler]

Hi,

as an output of my work on [1] I'd like to propose some new testcases, criteria 
and some modifications of present ones. It would be great if you look at them 
and whether you will have some suggestions, please let me know (on mailing 
list).

Regards
Petr Schindler

[1] https://fedorahosted.org/fedora-qa/ticket/151
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedora 17’s unified filesystem (/usr-move)

[Daniel J Walsh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2012 05:33 PM, Michel Alexandre Salim wrote:
> On 01/27/2012 04:08 PM, Daniel J Walsh wrote:
>> On 01/27/2012 08:10 AM, Harald Hoyer wrote:
>>> The packages, which are about to land in rawhide, are at this 
>>> moment available via the ‘f17-usrmove’ koji tag. They are
>>> ready for testing now. Any tests, preferably in virtual
>>> machines or snapshots, where failures are acceptable, are more
>>> than welcome, and any feedback is greatly appreciated.
> 
> ..
>>> SELinux relabelling should take effect after you rebooted your
>>>  updated system and can take a long time (at least in a VM it 
>>> takes insanely long and is still not finished). We are
>>> currently investigating, what seem to take so long, so you
>>> might consider to test with SELinux disabled for now.
> 
>> WHy not do this with enforcing=0 rather then selinux=0, then the
>>  relabel should not be required.
> 
> 
> I can report that on my laptop (Sony Vaio SA3), starting from a
> clean Fedora 16 x86_64 install and pulling kernel, kernel-devel and
> gcc from updates-testing (I have to compile acpi_call to turn off
> my new "fusion" AMD card), the upgrade went without a hitch.
> 
> Answering Dan's SELinux suggestion -- I tried doing the migration
> with enforcing=0 -- at the next boot it still tries to relabel the
> filesystem (I aborted once and booted with selinux=0 to verify
> everything is working, and am now doing the relabeling).
> 
> Does the usrmove script have to be modified, perhaps?
> 
Yes
grep autorelabel /usr/lib/dracut/modules.d/30usrmove/*
/usr/lib/dracut/modules.d/30usrmove/usrmove-convert.sh:echo "Set
autorelabel flag."
/usr/lib/dracut/modules.d/30usrmove/usrmove-convert.sh:>
"$ROOT/.autorelabel"
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk8mqQAACgkQrlYvE4MpobPiQwCgn5M5yzSZoUrJXKzkvYk964Hi
F2sAnRAKxSlREAzk1v+Z3tBlFElK2ln7
=GcyP
-END PGP SIGNATURE-
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Installation from USB-written images (5/5): DVD.iso + Livecd-iso-to-disk

[Josef Skladanka]

This testcase [1] should ensure, that if the user uses USB stick and transfers 
the DVD.iso to it using Livecd-iso-to-disk, the installation can be 
successfully finished.
Installer should be able to use the DVD local package source options, but this 
is caused by the way LITD writes the image to the USB stick.

I propose this as a Alpha verification testcase.

---

= Description =

This test verifies that Fedora DVD Image can be booted & installed from USB 
stick

There are more methods to create the DVD.iso USB stick, this test covers 
Livecd-iso-to-disk. 

== Setup ==

* Prepare the DVD ISO image and USB stick.
* Copy the DVD.iso to the USB stick using Livecd-iso-to-disk.  [3]

== How to test ==

* Insert the USB stick containing DVD.iso, and boot the system under test
* Proceed with the installation the usual way. 

== Expected Results ==

* Graphical boot menu is displayed for users to select install options. 
Navigating the menu and selecting entries must work. If no option is selected, 
the installer should load after a reasonable timeout
* Installer boots into loader and prompts for language, keymap
* Installer transitions to anaconda without error
* Installer should be able to use the DVD local package source options 
* ??? Installer does not offer the USB stick as a target for bootloader and/or 
partitioning 

---

[1] 
https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_DVD_litd
[2] https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
[3] 
http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Run_livecd-iso-to-disk_script
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Installation from USB-written images (4/5): DVD.iso + dd

[Josef Skladanka]

This testcase [1] should ensure, that if the user uses USB stick and transfers 
the DVD.iso to it using dd, the installation can be successfully finished.
Even though this technically is DVD.iso, we do not require anaconda to 
successfully use the DVD local package source options (F17 Alpha Release 
Criterion #7).

I propose this as a Alpha verification testcase.

---

= Description =

This test verifies that Fedora DVD Image can be booted & installed from USB 
stick

There are more methods to create the DVD.iso USB stick, this test covers dd.

== Setup ==

* Prepare the DVD ISO image and USB stick.
* Copy the DVD.iso to the USB stick using dd [3]

== How to test ==

* Insert the USB stick containing DVD.iso, and boot the system under test
* Proceed with the installation the usual way. 

== Expected Results ==

* Graphical boot menu is displayed for users to select install options. 
Navigating the menu and selecting entries must work. If no option is selected, 
the installer should load after a reasonable timeout
* Installer boots into loader and prompts for language, keymap
* Installer transitions to anaconda without error
* ??? Installer does not offer the USB stick as a target for bootloader and/or 
partitioning 

---

[1] 
https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_DVD_dd
[2] https://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
[3] 
http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Using_dd_for_a_direct_copy
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Installation from USB-written images (3/5): Live.iso + LiveCD-tools

[Josef Skladanka]

This testcase [1] should ensure, that if the user uses LiveCD tools to transfer 
the Fedora Live.iso to USB stick, the boot process works 'as expected'.

I propose this as a Alpha verification testcase.

---

= Description =

This test verifies that Fedora Live Image can be booted from USB stick.

There are more methods to create the Live USB stick, this test covers 
Livecd-tools. 

== Setup ==

* Prepare the Live ISO image and USB stick.
* Copy the Live.iso to the USB stick using LiveCD tools [2]

== How to test ==

* Insert the USB stick containing Live.iso, and boot the system under test
* At the boot prompt, interrupt the automatic boot sequence by pressing any 
key. Then select the menu option Boot.

== Expected Results ==

* A graphical boot menu is displayed and the graphics look reasonably good. 
While hi-res images aren't supported in the boot menu, the graphics should not 
look extremely pixelated.
* Upon selecting Boot, the Live image boots successfully.

---



[1] 
https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_Live_dd
[2] 
http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Check_livecd-tools
-- 
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

Installation from USB-written images (1/5): Live.iso + Livecd-iso-to-disk

[Josef Skladanka]

This testcase [1] should ensure, that if the user uses Livecd-iso-to-disk to 
transfer the Fedora Live.iso to USB stick, the boot process works 'as expected'.

I propose this as a Alpha verification testcase.

---

= Description =

This test verifies that Fedora Live Image can be booted from USB stick.

There are more methods to create the Live USB stick, this test covers 
Livecd-iso-to-disk. 

== Setup ==

* Prepare the Live ISO image and USB stick.
* Copy the Live.iso to the USB stick using Livecd-iso-to-disk [2]

== How to test ==

* Insert the USB stick containing Live.iso, and boot the system under test
* At the boot prompt, interrupt the automatic boot sequence by pressing any 
key. Then select the menu option Boot. 

== Expected Results ==

* A graphical boot menu is displayed and the graphics look reasonably good. 
While hi-res images aren't supported in the boot menu, the graphics should not 
look extremely pixelated.
* Upon selecting Boot, the Live image boots successfully. 

---



[1] 
https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_Live_litd
[2] 
http://fedoraproject.org/wiki/How_to_create_and_use_Live_USB#Run_livecd-iso-to-disk_script
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Installation from USB-written images (1/5): Live.iso + dd

[Josef Skladanka]

This testcase [1] should ensure, that if the user uses dd to transfer the 
Fedora Live.iso to USB stick, the boot process works 'as expected'.

I propose this as a Alpha verification testcase.

---

= Description =

This test verifies that Fedora Live Image can be booted from USB stick.

There are more methods to create the Live USB stick, this test covers dd.

== Setup ==

* Prepare the Live ISO image and USB stick.
* Copy the Live.iso to the USB stick using dd [1] 

== How to test ==

* Insert the USB stick containing Live.iso, and boot the system under test
* At the boot prompt, interrupt the automatic boot sequence by pressing any 
key. Then select the menu option Boot. 

== Expected Results ==

* A graphical boot menu is displayed and the graphics look reasonably good. 
While hi-res images aren't supported in the boot menu, the graphics should not 
look extremely pixelated.
* Upon selecting Boot, the Live image boots successfully. 

---



[1] 
https://fedoraproject.org/wiki/User:Jskladan/Draft_QA_Testcase_USB_stick_Live_dd
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

New testcases proposal - Installation from USB-written images (0/5)

[Josef Skladanka]

Hello,

as per [1] and [2], I'd like to propose five new testcases, which focus on 
testing the ability to boot/install Fedora using USB stick as the 
installation/boot medium. Even though, there is no Release Criterion specifying 
the supported installation media, the [2] mentions 'Common Boot media / Common 
Installation sources' (Alpha verifiacation) and 'All Boot media / All 
Installation sources'. These IMHO support the need for new USB-centric 
testcases.

Please be informed, that these proposals based on the already existing 
testcases, and I will be really happy to change/update these according to your 
input.

Regards

Joza

[1] https://fedorahosted.org/fedora-qa/ticket/260
[2] https://fedoraproject.org/wiki/QA:Fedora_17_Install_Test_Plan#Test_Priority
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Fedora 17’s unified filesystem (/usr-move)

[Joel Rees]

On Fri, Jan 27, 2012 at 10:10 PM, Harald Hoyer  wrote:
> Hello Testers and rawhide Users,
>
> Fedora 17 will locate the entire base operating system in /usr.
> [...]

You guys really are going to do this?

If it were I, instead of combining, I'd be working through the list of
what is where and starting to move things out of /bin, et. al., that
don't belong there, and starting to split /usr even further.

I guess this is what you get when you start using ACLs.

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

rawhide report: 20120130 changes

[Rawhide Report]

Compose started at Mon Jan 30 08:15:10 UTC 2012

Broken deps for x86_64
--
[aunit]
aunit-2010-3.fc16.i686 requires libgnat-4.6.so
aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit)
[autotrust]
autotrust-0.3.1-7.fc17.x86_64 requires libunbound.so.2()(64bit)
[banshee]
banshee-meego-2.2.1-3.fc17.x86_64 requires mutter-meego
[blender]
1:blender-2.61-1.fc17.x86_64 requires 
libOpenCOLLADAStreamWriter.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires 
libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires 
libOpenCOLLADAFramework.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires 
libOpenCOLLADABaseUtils.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires libMathMLSolver.so.svn863()(64bit)
1:blender-2.61-1.fc17.x86_64 requires 
libGeneratedSaxParser.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libOpenCOLLADAStreamWriter.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libOpenCOLLADAFramework.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libOpenCOLLADABaseUtils.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libMathMLSolver.so.svn863()(64bit)
1:blenderplayer-2.61-1.fc17.x86_64 requires 
libGeneratedSaxParser.so.svn863()(64bit)
[comoonics-cdsl-py]
comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py
[comoonics-cluster-py]
comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py
[compat-gcc-34]
compat-gcc-34-c++-3.4.6-23.fc17.x86_64 requires libstdc++ < 0:4.7.0
[compiz]

compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.i686 
requires libboost_serialization-mt.so.1.47.0

compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 
requires libboost_serialization-mt.so.1.47.0()(64bit)

compiz-gtk-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64
 requires libboost_serialization-mt.so.1.47.0()(64bit)

compiz-kde-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64
 requires libboost_serialization-mt.so.1.47.0()(64bit)
[compiz-fusion-extras]
compiz-fusion-extras-0.9.5.92-1.fc17.x86_64 requires 
libboost_serialization-mt.so.1.47.0()(64bit)
[compiz-fusion-unsupported]
compiz-fusion-unsupported-0.9.4-6.fc17.x86_64 requires 
libboost_serialization-mt.so.1.47.0()(64bit)
[compiz-plugins-main]
compiz-plugins-main-0.9.5.92-1.fc17.x86_64 requires 
libboost_serialization-mt.so.1.47.0()(64bit)
[contextkit]
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
[couchdb]
couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit)
[curry]
curry-0.9.11-7.fc12.x86_64 requires libgmp.so.3()(64bit)
[derelict]
derelict-AL-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-AL-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-FT-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-FT-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-GL-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-GL-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-IL-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-IL-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-ODE-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-ODE-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-Ogg-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-Ogg-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-PA-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-PA-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-SDL-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-SDL-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-SFML-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-SFML-devel-2-20.2006svn593.fc17.x86_64 requires 
derelict-Util-static
derelict-allegro-devel-2-20.2006svn593.fc17.i686 requires 
derelict-Util-static
derelict-allegro-devel-2-20.2006svn593.fc17.x86_64 requires 
derel

/usrmove Nightlies Testing?

[Frank Murphy]

Any idea on when /usrmove nightlies.
Might be ready for testing.

--
Regards,

Frank Murphy, friend of fedoraproject
UTF_8 Encoded
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test