Re: update some test cases

2015-01-20 Thread Lili Nie 

> From: "Adam Williamson" 
> To: "For testing and quality assurance of Fedora releases" 
> 
> Sent: Wednesday, January 21, 2015 6:50:04 AM
> Subject: Re: update some test cases
> 
> On Wed, 2015-01-14 at 23:59 -0500, Lili Nie wrote:
> > Hi Adam,
> > Thanks a lot for your great advice and help :)
> 
> No problem! I see you put the changes into place, I just went through
> the tests and cleaned up a bit more - I created the new template I
> suggested for the steps all the test cases shared, and tweaked the
> wording a bit in other places. 
  yeah,I thought I had received pretty much advice:)

 > Thanks again!
 you have grabbed my words,haha,Thanks a lot again.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> 
> --
> 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: OS X dual boot criterion problems

2015-01-20 Thread Chris Murphy 
On Tue, Jan 20, 2015 at 3:56 PM, Adam Williamson
 wrote:
> So, where would you say we are WRT the criteria for F22 right now?
> What would be a reasonable expectation?
>
> As of right now, we have these in the F22 Final criteria:
>
> Windows dual boot
>
> The installer must be able to install into free space alongside an
> existing clean Windows installation and install a bootloader which can
> boot into both Windows and Fedora.

On UEFI with Secure Boot enabled, the GRUB Windows menuentry fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1170245

This is working on openSUSE since ~2012 so it seems it ought to work
on Fedora by now. The criteria neither requires nor exempts us from
this behavior, so right now its ambiguous.

>
> OS X dual boot
>
> The installer must be able to install into free space alongside an
> existing OS X installation, install and configure a bootloader that
> will boot Fedora; if the boot menu presents OS X entries, they must
> boot OS X. Installing Fedora must not inhibit the system's ability to
> boot OS X from the UEFI boot manager.

I think this can safely be changed to just the first part before the
semi-colon. It seems like removing the OS X boot entries from being
created is a cosmetic change, it means grub2-mkconfig does less work.
Niftier would be a reminder that rebooting with Option key will bring
up the built-in boot manager from which OS X can be booted. I don't
know if that's a feature change though, since it'd be nice if it's
translated. But in any case it seems to me the criteria can be chopped
to 1/3, basically just saying "Fedora ought to install to and boot a
Mac, and that the installer expects free space to do that, i.e. no
resizing."



>
> We do not have any Linux dual boot criterion.
>
> Do we need to amend the OS X or Windows criteria to reflect technical
> reality in any way? Do we want to take another shot at adding a
> limited Linux dual/multi-boot criterion before we hit Alpha? If so we
> should revisit the F21-era proposals, agree on a wording, and run it
> by anaconda-devel-list ASAP.

Some people on desktop@ agree there should be a Secure Boot criteria,
at least for single boot (Fedora). Making this apply to chainloading
(per above) met with less assurance, but this was before I tracked
down that opensuse can do this. (Ubuntu fails with the same error we
have.) If we have concensus here, then maybe this ought to go to the
WG's. I suspect all three products want Secure Boot to work for their
products, or block. Workstation is the only one that cares about SB
and dual-boot.

As for dual boot linux, it'd be great if things were friendlier. Sadly
it doesn't appear to be a priority. Bootloaderspec has an upstream and
mjg59 variant, presently the GRUB bls module sufficiently departs from
both to be on its own set of rails, and I'm not aware of any
collective distro effort to settle this. It seems like a pretty small
collection of dual boot linux users and if we play the numbers game it
seems like not a whole heck of a lot really care. Therefore I don't
know it makes sense to put effort into this on the QA side as if we
can compel what amounts to a feature to just materialize from a
criterion.


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

Re: Release criterion proposal: "Package sets" (Alpha and Beta)

2015-01-20 Thread Mike Ruckman 
On Tue, Jan 20, 2015 at 12:46:34PM -0800, Adam Williamson wrote:
> Here's a ping on this (as I only got feedback from Mike before - 
> anyone else?) and a modification: I'd like to extend the Beta 
> criterion to read:
> 
> "When installing with a release-blocking dedicated installer image, 
> the default package set must be correct, and choosing a different 
> package set must work."
> 
> with a footnote something like:
> 
> "'work' means that the package set selection mechanism itself must 
> work; when used, the packages that form the chosen set must actually 
> be the ones marked for installation. Package issues that render one or 
> more selectable package sets un-installable do not constitute a 
> violation of this criterion, though they may be violations of other 
> criteria."
> 
> this is to cover things like 
> https://bugzilla.redhat.com/show_bug.cgi?id=1179362 , which I noticed 
> when filing it is a bit of a loophole in the proposed criteria.
> 
> Any more thoughts, folks? Thanks!
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net

That addition to the proposed criteria sounds good to me. The definition
of 'work' makes sense as well.

-- 
// Mike 
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: OS X dual boot criterion problems

2015-01-20 Thread Adam Williamson 
On Sun, 2014-12-28 at 18:39 -0700, Chris Murphy wrote:
> On Thu, Dec 4, 2014 at 12:41 AM, Adam Williamson <
> adamw...@fedoraproject.org> wrote:
> > Hi, folks. Talking to cmurf, our resident OS X dual boot expert, 
> > on #fedora-qa, it's become clear that when we adopted the OS X 
> > dual boot criterion a few weeks back, we didn't have a good 
> > understanding of the current state of that code and particularly 
> > upstream grub's support for booting OS X via UEFI. Basically it 
> > seems that booting OS X from grub didn't work then and doesn't 
> > work now and we can't realistically fix it, so we shouldn't have 
> > put that criterion in place because it's not something we can 
> > actually viably achieve.
> > 
> > cmurf, roshi, kparal and I voted +1 to removing the criterion on 
> > that basis. I'm hoping cmurf will be kind enough to look at the 
> > issue again for the F22 cycle, in consultation with pjones if 
> > necessary, so we can put a realistic requirement in place before 
> > we get into F22 Alphas.
> > 
> > If no-one has any objections, we'll make the removal formal ahead 
> > of tomorrow's Go/No-Go meeting for 21. Thanks folks!
> 
> Gist: EFI GRUB still gets these legacy OS X boot options that were 
> designed to permit CSM-BIOS GRUB to EFI boot OS X. They don't work 
> from EFI GRUB though.
> 
> As far as I can tell there's no upstream bandwidth/interest in 
> fixing this; even if it means just suppressing the creation of the 
> entries, rather than chainloading the Apple bootloader. So I think 
> the issue is not a QA issue right now, but needs to be bounced back 
> to desktop@ for the Workstation WG to maybe use some recruitment 
> influence if they want to see this fixed.
> http://lists.gnu.org/archive/html/grub-devel/2014-10/msg00044.html
> 
> A challenge with grub2-mkconfig creating an entry to chainload 
> Apple's boot.efi, is with recent on-disk format changes in OS X 
> 10.10 since this last October. It means os-prober will need to 
> become aware that the boot.efi it's looking for is now on an Apple 
> Boot [1] partition. I'm not sure what's involved in doing that work 
> compared to just suppressing the creation of entries that don't work 
> anyway.

Thanks for the info, and sorry for the belated reply.

So, where would you say we are WRT the criteria for F22 right now? 
What would be a reasonable expectation?

As of right now, we have these in the F22 Final criteria:

Windows dual boot

The installer must be able to install into free space alongside an 
existing clean Windows installation and install a bootloader which can 
boot into both Windows and Fedora.

OS X dual boot

The installer must be able to install into free space alongside an 
existing OS X installation, install and configure a bootloader that 
will boot Fedora; if the boot menu presents OS X entries, they must 
boot OS X. Installing Fedora must not inhibit the system's ability to 
boot OS X from the UEFI boot manager.

We do not have any Linux dual boot criterion.

Do we need to amend the OS X or Windows criteria to reflect technical 
reality in any way? Do we want to take another shot at adding a 
limited Linux dual/multi-boot criterion before we hit Alpha? If so we 
should revisit the F21-era proposals, agree on a wording, and run it 
by anaconda-devel-list ASAP.

Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: update some test cases

2015-01-20 Thread Adam Williamson 
On Wed, 2015-01-14 at 23:59 -0500, Lili Nie wrote:
> Hi Adam,
> Thanks a lot for your great advice and help :)

No problem! I see you put the changes into place, I just went through 
the tests and cleaned up a bit more - I created the new template I 
suggested for the steps all the test cases shared, and tweaked the 
wording a bit in other places. Thanks again!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Fedora 20 updates-testing report

2015-01-20 Thread updates 
The following Fedora 20 Security updates need testing:
 Age  URL
 109  
https://admin.fedoraproject.org/updates/FEDORA-2014-11969/krb5-1.11.5-16.fc20
  62  
https://admin.fedoraproject.org/updates/FEDORA-2014-15371/rubygem-actionpack-4.0.0-5.fc20
  60  
https://admin.fedoraproject.org/updates/FEDORA-2014-15489/rubygem-sprockets-2.8.2-5.fc20
  39  
https://admin.fedoraproject.org/updates/FEDORA-2014-16494/mutt-1.5.23-4.fc20
  38  
https://admin.fedoraproject.org/updates/FEDORA-2014-16845/resteasy-3.0.6-3.fc20
  38  
https://admin.fedoraproject.org/updates/FEDORA-2014-16825/asterisk-11.14.2-1.fc20
  33  
https://admin.fedoraproject.org/updates/FEDORA-2014-17153/httpd-2.4.10-2.fc20
  29  
https://admin.fedoraproject.org/updates/FEDORA-2014-17089/aeskulap-0.2.2-0.20beta1.fc20,orthanc-0.8.5-2.fc20,dcmtk-3.6.1-1.fc20
  26  
https://admin.fedoraproject.org/updates/FEDORA-2014-17559/mapserver-6.2.2-1.fc20
  24  
https://admin.fedoraproject.org/updates/FEDORA-2014-17641/dokuwiki-0-0.23.20140929b.fc20
  11  
https://admin.fedoraproject.org/updates/FEDORA-2015-0451/docker-io-1.4.1-4.fc20
   7  
https://admin.fedoraproject.org/updates/FEDORA-2015-0577/strongswan-5.2.2-1.fc20
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-0633/chicken-4.9.0.1-3.fc20
   5  
https://admin.fedoraproject.org/updates/FEDORA-2015-0726/drupal7-context-3.6-1.fc20
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0790/python-django-1.6.10-1.fc20
   3  https://admin.fedoraproject.org/updates/FEDORA-2015-0773/arc-5.21p-5.fc20
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0753/qpid-cpp-0.30-5.fc20
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0792/suricata-2.0.6-1.fc20
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0804/python-django14-1.4.18-1.fc20
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0809/thunderbird-31.4.0-1.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0951/xdg-utils-1.1.0-0.35.rc3.fc20


The following Fedora 20 Critical Path updates have yet to be approved:
 Age URL
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0787/gnome-online-accounts-3.10.6-1.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0951/xdg-utils-1.1.0-0.35.rc3.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0890/gstreamer-plugins-base-0.10.36-7.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0948/gstreamer-0.10.36-7.fc20
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0959/redhat-rpm-config-9.1.0-55.fc20


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

NetworkManager-openconnect-0.9.8.6-1.fc20
RBTools-0.7-1.fc20
alexandria-0.6.9-10.fc20
bluedevil-2.1-2.fc20
bpython-0.13.2-1.fc20
cinnamon-2.4.6-1.fc20
claws-mail-3.11.1-3.fc20
csdiff-1.1.3-1.fc20
csmock-1.6.1-1.fc20
cswrap-1.2.1-1.fc20
dspam-3.10.2-14.fc20
gfal2-plugin-xrootd-0.3.4-1.fc20
golang-github-coreos-go-systemd-2-3.fc20
golang-github-skynetservices-skydns-0-0.3.git245a121.fc20
gstreamer-0.10.36-7.fc20
gstreamer-plugins-base-0.10.36-7.fc20
inadyn-mt-2.24.43-1.fc20
kde-plasma-nm-0.9.3.5-7.fc20
knot-1.6.1-3.fc20
libnm-qt-0.9.8.3-3.fc20
muffin-2.4.3-1.fc20
nemo-2.4.4-4.fc20
openconnect-7.03-1.fc20
pam_radius-1.4.0-1.fc20
php-pecl-solr2-2.1.0-1.fc20
python-execnet-1.2.0-4.fc20.1
python-jedi-0.8.1-1.fc20
python-pysb-1.0.1-1.fc20
quiterss-0.17.4-1.fc20
rebase-helper-0.4.0-2.fc20
redhat-rpm-config-9.1.0-55.fc20
rubygem-gettext-3.1.5-1.fc20
salt-2014.7.1-1.fc20
screengrab-1.2-1.fc20
spectrwm-2.6.1-1.fc20
xdg-utils-1.1.0-0.35.rc3.fc20

Details about builds:



 NetworkManager-openconnect-0.9.8.6-1.fc20 (FEDORA-2015-0494)
 NetworkManager VPN plugin for openconnect

Update Information:

Update to OpenConnect 7.03 (#1179681)
OpenConnect fixes for plasma-nm

ChangeLog:

* Fri Jan  9 2015 David Woodhouse  - 0.9.8.6-1
- Update to 0.9.8.6 + later patches for libopenconnect5 support

References:

  [ 1 ] Bug #1177566 - Openconnect dialog confusing, missing functionality in 
kde-plasma-nm
https://bugzilla.redhat.com/show_bug.cgi?id=1177566
  [ 2 ] Bug #1179681 - connection fails when IP address changes
https://bugzilla.redhat.com/show_bug.cgi?id=1179681




 RBTools-0.7-1.fc20 (FEDORA-2015-0897)
 Tools for use with ReviewBoard

Update Information:

Fedora 21 updates-testing report

2015-01-20 Thread updates 
The following Fedora 21 Security updates need testing:
 Age  URL
  62  
https://admin.fedoraproject.org/updates/FEDORA-2014-15342/rubygem-actionpack-4.1.5-2.fc21
  61  
https://admin.fedoraproject.org/updates/FEDORA-2014-15413/rubygem-sprockets-2.12.1-3.fc21
  39  
https://admin.fedoraproject.org/updates/FEDORA-2014-16782/mutt-1.5.23-7.fc21
  38  
https://admin.fedoraproject.org/updates/FEDORA-2014-16833/asterisk-11.14.2-1.fc21
  33  
https://admin.fedoraproject.org/updates/FEDORA-2014-17195/httpd-2.4.10-15.fc21
  29  
https://admin.fedoraproject.org/updates/FEDORA-2014-17139/aeskulap-0.2.2-0.20beta1.fc21,orthanc-0.8.5-2.fc21,dcmtk-3.6.1-1.fc21
  26  
https://admin.fedoraproject.org/updates/FEDORA-2014-17567/mapserver-6.2.2-1.fc21
  24  
https://admin.fedoraproject.org/updates/FEDORA-2014-17635/dokuwiki-0-0.23.20140929b.fc21
  13  https://admin.fedoraproject.org/updates/FEDORA-2015-0264/gcab-0.4-7.fc21
   7  
https://admin.fedoraproject.org/updates/FEDORA-2015-0594/strongswan-5.2.2-1.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-0667/python-pillow-2.6.1-2.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-0620/chicken-4.9.0.1-3.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-0660/libsndfile-1.0.25-14.fc21
   5  
https://admin.fedoraproject.org/updates/FEDORA-2015-0714/python-django-1.6.10-1.fc21
   5  
https://admin.fedoraproject.org/updates/FEDORA-2015-0717/drupal7-context-3.6-1.fc21
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0727/suricata-2.0.6-1.fc21
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0750/binutils-2.24-30.fc21
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0831/qpid-cpp-0.30-4.fc21
   3  https://admin.fedoraproject.org/updates/FEDORA-2015-0754/arc-5.21p-5.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0937/kernel-3.18.3-201.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0938/android-tools-20141219git8393e50-2.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0954/xdg-utils-1.1.0-0.35.rc3.fc21


The following Fedora 21 Critical Path updates have yet to be approved:
 Age URL
  13  
https://admin.fedoraproject.org/updates/FEDORA-2015-0312/gupnp-av-0.12.7-1.fc21,gssdp-0.14.11-1.fc21,gupnp-0.20.13-1.fc21
  12  
https://admin.fedoraproject.org/updates/FEDORA-2015-0357/setup-2.9.0-3.fc21
  11  https://admin.fedoraproject.org/updates/FEDORA-2015-0440/lz4-r127-1.fc21
  10  
https://admin.fedoraproject.org/updates/FEDORA-2015-0493/rest-0.7.92-6.fc21
   6  
https://admin.fedoraproject.org/updates/FEDORA-2015-0672/libical-1.0-9.fc21
   5  
https://admin.fedoraproject.org/updates/FEDORA-2015-0725/langtable-0.0.29-1.fc21
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0845/gnome-online-accounts-3.14.3-1.fc21
   3  
https://admin.fedoraproject.org/updates/FEDORA-2015-0750/binutils-2.24-30.fc21
   3  https://admin.fedoraproject.org/updates/FEDORA-2015-0765/libffi-3.1-7.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0914/hwdata-0.274-1.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0896/librepo-1.7.12-1.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0954/xdg-utils-1.1.0-0.35.rc3.fc21
   0  
https://admin.fedoraproject.org/updates/FEDORA-2015-0933/gnutls-3.3.12-1.fc21


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

RBTools-0.7-1.fc21
alexandria-0.6.9-10.fc21
android-tools-20141219git8393e50-2.fc21
bpython-0.13.2-1.fc21
calamares-0.17.0-8.20150119git5c6a302112cee.fc21
cinnamon-2.4.6-1.fc21
claws-mail-3.11.1-3.fc21
clipper-2.1-25.20140911.fc21
csdiff-1.1.3-1.fc21
csmock-1.6.1-1.fc21
cswrap-1.2.1-1.fc21
dspam-3.10.2-14.fc21
freeradius-3.0.4-4.fc21
gfal2-plugin-xrootd-0.3.4-1.fc21
ghc-rpm-macros-1.2.18-1.fc21
gnome-chemistry-utils-0.14.10-2.fc21
gnutls-3.3.12-1.fc21
golang-github-coreos-go-systemd-2-3.fc21
golang-github-skynetservices-skydns-0-0.3.git245a121.fc21
gstreamer-0.10.36-11.fc21
gstreamer-plugins-base-0.10.36-12.fc21
hwdata-0.274-1.fc21
inadyn-mt-2.24.43-1.fc21
kde-plasma-nm-0.9.3.5-7.fc21
kernel-3.18.3-201.fc21
knot-1.6.1-3.fc21
libdwarf-20150115-1.fc21
libnm-qt-0.9.8.3-3.fc21
libreoffice-4.3.5.2-11.fc21
librepo-1.7.12-1.fc21
mapdb-1.0.6-1.fc21
nfs-utils-1.3.1-6.0.fc21
opencc-1.0.2-2.fc21
pam_radius-1.4.0-1.fc21
perl-autodie-2.25-3.fc21
php-pecl-solr2-2.1.0-1.fc21
php-phpunit-PHP-TokenStream-1.4.0-1.fc21
php-phpunit-PHPUnit-4.4.2-1.fc21
python-dateutil15-1.5-7.fc21
python-gmpy2-2.0.5-1.fc21
python-jedi-0.8.1-1.fc21
python-pygal-1.6.1-1.fc21
python-pysb-1.0.1-1.fc21
quiterss-0.17.4-1.fc21
rebase-helper-0.4.0-2.fc21
rubygem-gettext-3.1.5-1.fc21
salt-2014.7.1-1.fc21
screengrab-1.2-1.fc21
ssm-1.4-1.fc21
sssd-1.12.3-3.fc21
systemd-216-16.fc21
ua-parser-java-1.3.0-1.fc21
webkitgtk4-2.

Re: Release criterion proposal: "Package sets" (Alpha and Beta)

2015-01-20 Thread Adam Williamson 
On Tue, 2014-12-23 at 10:21 -0800, Adam Williamson wrote:
> The "Package sets" criterion for Alpha currently reads:
> 
> "When doing a graphical install using the dedicated installer 
> images, the installer must be able to install each of the release 
> blocking desktops, as well as the minimal package set."
> 
> This was drafted prior to Product-ization. It has a bug - you can't 
> do that from the Server DVD, and that's intended - and two problems -
> it's too focused on desktops for the new Product-y world, and the 
> 'graphical' restriction seems arbitrary (TUI should work regarding 
> package sets too). It also is missing something: there's no
> requirement about what the *default* package set should be.
> 
> I propose we re-word the Alpha criterion to:
> 
> "When installing with a release-blocking dedicated installer image, 
> the installer must be able to install the default package set."
> 
> and add a Beta criterion:
> 
> "When installing with a release-blocking dedicated installer image, 
> the default package set must be correct."
> 
> with an explanatory note that 'correct' means the package set 
> intended by the group responsible for the image - Product WG, FESCo 
> or whoever.
> 
> I'm not sure whether we need a requirement for non-default package 
> sets. Note that the case for offline media is already covered by 
> Alpha criterion "No broken packages":
> 
> "There must be no errors in any package on the release-blocking 
> images which cause the package to fail to install."
> 
> network installs using updates media don't really need to block on 
> package set issues, as they can be fixed. That leaves the question 
> of whether we'd want to block the release if, say, there was a bug 
> which meant that if you tried to netinst KDE without the updates 
> repos enabled, it failed. What do folks think about that?

Here's a ping on this (as I only got feedback from Mike before - 
anyone else?) and a modification: I'd like to extend the Beta 
criterion to read:

"When installing with a release-blocking dedicated installer image, 
the default package set must be correct, and choosing a different 
package set must work."

with a footnote something like:

"'work' means that the package set selection mechanism itself must 
work; when used, the packages that form the chosen set must actually 
be the ones marked for installation. Package issues that render one or 
more selectable package sets un-installable do not constitute a 
violation of this criterion, though they may be violations of other 
criteria."

this is to cover things like 
https://bugzilla.redhat.com/show_bug.cgi?id=1179362 , which I noticed 
when filing it is a bit of a loophole in the proposed criteria.

Any more thoughts, folks? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: [Test-Announce] Urgent F21 testing request: libhif and PackageKit

2015-01-20 Thread Adam Williamson 
On Tue, 2015-01-20 at 10:18 +, Richard Hughes wrote:
> On 20 January 2015 at 06:30, Chris Murphy  
> wrote:
> > Unfortunately these updates don't fix Bug 1178978 - offline update 
> > fails due
> > to separate /var volume mounting too late
> > https://bugzilla.redhat.com/show_bug.cgi?id=1178978
> 
> Right. This isn't actually a PackageKit bug as you correctly 
> deduced. I think systemd-update just needs to wait for /var, 
> although I don't know the magic required for that unfortunately.

There's a 'RequiresMountsFor' directive used by several of the 
services in /usr/lib/systemd/system ; I'd bet that's it.

It's documented as:

"Takes a space-separated list of absolute paths. Automatically adds 
dependencies of type Requires= and After= for all mount units required 
to access the specified path."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

Re: [Test-Announce] Urgent F21 testing request: libhif and PackageKit

2015-01-20 Thread Michel Alexandre Salim 
On Tue Jan 20 2015 at 3:20:41 AM Adam Williamson 
wrote:

> It would be great if folks could, as a matter of urgency, test this
> update:
>
> https://admin.fedoraproject.org/updates/PackageKit-1.0.4-1.fc21,libhif-
> 0.1.8-1.fc21
>
> Please install the updated packages, reboot (or at least restart the
> packagekit service), run 'pkcon repair' as root, reboot again, and
> then test regular use of GNOME Software and pkcon as much as possible -
>

pkcon repair shows my database is fine, but I've been using dnf
exclusively. pkcon update works fine (it prompts for confirmation about
installing new packages -- the list of packages tallies with that provided
by dnf), and GNOME Software works fine installing new apps.

Regards,

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

Re: [Test-Announce] Urgent F21 testing request: libhif and PackageKit

2015-01-20 Thread Richard Hughes 
On 20 January 2015 at 06:30, Chris Murphy  wrote:
> Unfortunately these updates don't fix Bug 1178978 - offline update fails due
> to separate /var volume mounting too late
> https://bugzilla.redhat.com/show_bug.cgi?id=1178978

Right. This isn't actually a PackageKit bug as you correctly deduced.
I think systemd-update just needs to wait for /var, although I don't
know the magic required for that unfortunately.

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

Re: [Test-Announce] Urgent F21 testing request: libhif and PackageKit

2015-01-20 Thread Richard Hughes 
On 20 January 2015 at 09:50, Tim Waugh  wrote:
> But: will all Fedora 21 users need to run 'pkcon repair' manually, or
> can that be made automatic?

It shouldn't be required, unless someone has rpmdb index corruption
and doesn't want to reboot.

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

Re: [Test-Announce] Urgent F21 testing request: libhif and PackageKit

2015-01-20 Thread Tim Waugh 
On Mon, 2015-01-19 at 12:20 -0800, Adam Williamson wrote:
> Please install the updated packages, reboot (or at least restart the 
> packagekit service), run 'pkcon repair' as root, reboot again, and 
> then test regular use of GNOME Software and pkcon as much as possible -
> try installing and removing packages, running offline updates, and so 
> on. If your package set is up to date you can try downgrading a 
> package in order to test offline updates - try 'yum downgrade 
> devassistant', for instance, if you have it installed, then check for 
> updates in GNOME Software.

The fixes work fine for me. Updates are installed normally, journal for
the offline update boot looks good.

But: will all Fedora 21 users need to run 'pkcon repair' manually, or
can that be made automatic?

Tim.
*/



signature.asc
Description: This is a digitally signed message part
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test