[Test-Announce] 2013-12-23 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2013-12-23
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

We have a meeting slot on 12-23 - it's two days before Christmas, but
lots of keen cookies expressed an interest in having the meeting, so
let's do it. We can't do broad Fedora 21 planning at present, but we can
look at the Fedora 20 FedUp issue, and perhaps talk about storage
validation a bit. Please suggest any other topics for discussion!

This is a reminder of the upcoming QA meeting. Please add any topic
suggestions to the meeting wiki page:
https://fedoraproject.org/wiki/QA/Meetings/20131223

The current proposed agenda is included below.

== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. FedUp post-mortem
3. Storage validation 
4. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

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

2013-12-16 - Fedora QA Meeting - recap

[Adam Williamson]

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

Next meeting is scheduled for 2013-12-23 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/20131223. Thanks!

TOPIC: Previous meeting follow-up
===
* "adamw to draft a new test case and matrix row for validating
  cloud image checksums" - that was done[1]

TOPIC: Fedora 20 recap
===
* Fedora 20 is signed off - thanks to all testers!
* We dissected the then-known major bugs in the release
* All major known bugs were documented at Common_F20_bugs[2]

TOPIC: Fedora 21 planning
===

* Project-wide, planning is blocking on Fedora.next[3] until
  the WGs report to FESCo in January; this makes QA planning
  for Fedora 21 mostly impossible until then
* FESCo has declared that Fedora 21 will not be released any
  earlier than late August 2014 (may be later) 

TOPIC: Open floor
===
N/A

Action items
===
* adamw to push the sanity check proposal out, group seems to
  approve
* adamw to check F19 and F18 commonbugs for issues that should
  be copied to F20 

1. https://lists.fedoraproject.org/pipermail/test/2013-December/119513.html
2. https://fedoraproject.org/wiki/Common_F20_bugs
3. https://fedoraproject.org/wiki/Fedora.next
-- 
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 19 updates-testing report

[updates]

The following Fedora 19 Security updates need testing:
 Age  URL
  62  
https://admin.fedoraproject.org/updates/FEDORA-2013-19262/quassel-0.9.1-1.fc19
  55  
https://admin.fedoraproject.org/updates/FEDORA-2013-19963/openstack-glance-2013.1.4-1.fc19
  12  
https://admin.fedoraproject.org/updates/FEDORA-2013-22919/net-snmp-5.7.2-13.fc19
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-23141/python-setuptools-0.6.49-1.fc19
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-23315/libreswan-3.7-1.fc19
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-23432/openttd-1.3.3-1.fc19
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-23437/v8-3.14.5.10-3.fc19
   3  
https://admin.fedoraproject.org/updates/FEDORA-2013-23457/xen-4.2.3-12.fc19
   2  
https://admin.fedoraproject.org/updates/FEDORA-2013-23517/libgadu-1.12.0-0.2.rc1.fc19
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23653/kernel-3.12.5-200.fc19
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23635/perl-Proc-Daemon-0.14-9.fc19
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23567/ca-certificates-2013.1.95-1.fc19
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23592/rubygem-actionpack-3.2.13-3.fc19
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23601/seamonkey-2.23-1.fc19
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23622/ibus-chewing-1.4.4-1.fc19
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23615/gnupg-1.4.16-2.fc19


The following Fedora 19 Critical Path updates have yet to be approved:
 Age URL
  28  
https://admin.fedoraproject.org/updates/FEDORA-2013-21772/unzip-6.0-11.fc19
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-23155/langtable-0.0.23-1.fc19
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-23141/python-setuptools-0.6.49-1.fc19
   7  
https://admin.fedoraproject.org/updates/FEDORA-2013-23219/iscsi-initiator-utils-6.2.0.873-17.fc19
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-23305/libfm-1.1.4-1.fc19
   3  
https://admin.fedoraproject.org/updates/FEDORA-2013-23467/gupnp-0.20.9-1.fc19
   3  
https://admin.fedoraproject.org/updates/FEDORA-2013-22326/fedora-bookmarks-15-5.fc19
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23666/fedora-release-19-6


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

caja-actions-1.6.2-2.fc19
docker-io-0.7.2-1.fc19
drupal7-features-2.0-5.fc19
fedora-release-19-6
ghc-numbers-3000.2.0.0-1.fc19
gnupg-1.4.16-2.fc19
golang-github-syndtr-gocapability-0-0.3.git3454319.fc19
gust-antykwa-torunska-fonts-2.08-4.fc19
ibus-chewing-1.4.4-1.fc19
idle3-tools-0.9.1-1.fc19
kernel-3.12.5-200.fc19
mysql-utilities-1.3.6-1.fc19
opendkim-2.9.0-2.fc19
pcs-0.9.103-1.fc19
perl-Proc-Daemon-0.14-9.fc19
python-caja-1.4.0-4.fc19
python-flask-whooshee-0.0.6-2.fc19
qemu-1.4.2-15.fc19
rubygem-actionpack-3.2.13-3.fc19
seamonkey-2.23-1.fc19
sqlcli-2-3.fc19
subsurface-4.0-1.fc19
suricata-1.4.7-1.fc19
tuxcut-5.1-1.fc19
tzdata-2013i-1.fc19
vrq-1.0.97-1.fc19
wireshark-1.10.4-2.fc19
x2goclient-4.0.1.2-1.fc19

Details about builds:



 caja-actions-1.6.2-2.fc19 (FEDORA-2013-23628)
 Caja extension for customizing the context menu

Update Information:

- update for rename caja in f21

ChangeLog:

* Wed Dec 18 2013 Wolfgang Ulbrich  - 1.6.2-2
- update for rename caja in f21




 docker-io-0.7.2-1.fc19 (FEDORA-2013-23602)
 Automates deployment of containerized applications

Update Information:

upstream release bump to v0.7.2
updating to upstream 0.7.1

ChangeLog:

* Wed Dec 18 2013 Lokesh Mandvekar  - 0.7.2-1
- upstream release bump to v0.7.2
* Fri Dec  6 2013 Vincent Batts  - 0.7.1-1
- upstream release of v0.7.1

References:

  [ 1 ] Bug #1044373 - docker-io-0.7.2 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1044373




 drupal7-features-2.0-5.fc19 (FEDORA-2013-23595)
 Provides feature management for Drupal

Update Information:

Quote from the page of Features 
Plumber(https://drupal.o

Fedora 18 updates-testing report

[updates]

The following Fedora 18 Security updates need testing:
 Age  URL
  26  
https://admin.fedoraproject.org/updates/FEDORA-2013-21875/389-ds-base-1.3.0.9-1.fc18
  12  
https://admin.fedoraproject.org/updates/FEDORA-2013-22949/net-snmp-5.7.2-7.fc18
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-23122/firefox-26.0-2.fc18,xulrunner-26.0-1.fc18
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-23140/python-setuptools-0.6.49-1.fc18
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-23291/thunderbird-24.2.0-2.fc18
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-23299/libreswan-3.7-1.fc18
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-23378/openttd-1.3.3-1.fc18
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-23401/v8-3.14.5.10-3.fc18
   3  
https://admin.fedoraproject.org/updates/FEDORA-2013-23466/xen-4.2.3-12.fc18
   2  
https://admin.fedoraproject.org/updates/FEDORA-2013-23504/quagga-0.99.21-6.fc18
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23591/seamonkey-2.23-1.fc18
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23646/perl-Proc-Daemon-0.14-9.fc18
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23575/ca-certificates-2013.1.95-1.fc18
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23662/rubygem-actionpack-3.2.8-4.fc18
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23663/ibus-chewing-1.4.4-1.fc18
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23678/gnupg-1.4.16-2.fc18


The following Fedora 18 Critical Path updates have yet to be approved:
 Age URL
 313  
https://admin.fedoraproject.org/updates/FEDORA-2013-2192/nautilus-3.6.3-5.fc18
  12  https://admin.fedoraproject.org/updates/FEDORA-2013-22918/opus-1.1-1.fc18
  12  
https://admin.fedoraproject.org/updates/FEDORA-2013-22917/colord-1.0.5-1.fc18
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-23122/firefox-26.0-2.fc18,xulrunner-26.0-1.fc18
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-23140/python-setuptools-0.6.49-1.fc18
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-23291/thunderbird-24.2.0-2.fc18
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-23312/dracut-029-1.fc18.3
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-23306/abrt-2.1.10-1.fc18,libreport-2.1.10-1.fc18,satyr-0.12-1.fc18
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-23297/libfm-1.1.4-1.fc18
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-23381/cryptsetup-1.6.3-1.fc18
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23598/fedora-release-18-6
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-23575/ca-certificates-2013.1.95-1.fc18


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

caja-actions-1.6.2-2.fc18
fedora-release-18-6
g2clib-1.4.0-3.fc18
ghc-numbers-3000.2.0.0-1.fc18
gnupg-1.4.16-2.fc18
ibus-chewing-1.4.4-1.fc18
opendkim-2.9.0-2.fc18
perl-Proc-Daemon-0.14-9.fc18
python-caja-1.4.0-4.fc18
rubygem-actionpack-3.2.8-4.fc18
seamonkey-2.23-1.fc18
tuxcut-5.1-1.fc18
tzdata-2013i-1.fc18
vrq-1.0.97-1.fc18
youtube-dl-2013.12.17.2-1.fc18

Details about builds:



 caja-actions-1.6.2-2.fc18 (FEDORA-2013-23649)
 Caja extension for customizing the context menu

Update Information:

- update for rename caja in f21

ChangeLog:

* Wed Dec 18 2013 Wolfgang Ulbrich  - 1.6.2-2
- update for rename caja in f21




 fedora-release-18-6 (FEDORA-2013-23598)
 Fedora release files

Update Information:

- fix up urls
- reenable 7d metadat cache expiry for fedora repo
- add f20 gpgkeys and update symlinks

ChangeLog:

* Wed Dec 18 2013 Dennis Gilmore  - 18-6
- actually commit all the changes
* Wed Dec 18 2013 Dennis Gilmore  - 18-5
- add to git the archmap file
* Wed Dec 18 2013 Dennis Gilmore  - 18-4
- fix up urls
* Wed Dec 18 2013 Dennis Gilmore  - 18-3
- reenable 7d metadat cache expiry for fedora repo
* Wed Dec 18 2013 Dennis Gilmore  - 18-2
- add f20 gpgkeys and update symlinks

References:

  [ 1 ] Bug #1040689 - GPG keys for F19 and F20 needed for upgrades
https://bugzilla.redhat.com/show_bug.cgi?id=1040689




 g2clib

Re: Recommended system requirements for f20 not sufficient?

[Lars Seipel]

On Thu, Dec 19, 2013 at 04:34:43PM -0800, Adam Williamson wrote:
> During Alpha, that's normal, it's been that way for 2-3 releases. Modern
> debug kernels are very slow and inefficient; installing with a debug
> kernel seems to exhaust 1GB of RAM quite easily. That's a separate
> issue, though, and not relevant to final release.

Yep, you're right. Just checked it and the F20 final release installs
without a problem with 1 GiB of memory. For text mode, that is.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Recommended system requirements for f20 not sufficient?

[Adam Williamson]

On Fri, 2013-12-20 at 01:10 +0100, Lars Seipel wrote:
> On Wed, Dec 18, 2013 at 11:03:36AM -0800, Adam Williamson wrote:
> > Well, I did some testing during F20 cycle which seems to indicate F20
> > Shell takes up a lot more memory than F19 when using llvmpipe. We're not
> > sure exactly what's going on yet,
> 
> It's not just Gnome Shell's fault I think.

No, it really is a Shell/llvmpipe specific issue. I checked.

>  At least for some time during
> Alpha/Beta even kickstarted text-only installs (virt-install pointed to
> an install tree over HTTP) locked up due to lack of memory.  That's with
> 1 GiB and no swap. Increase that to 1.5 GiB and the install process
> completed.

During Alpha, that's normal, it's been that way for 2-3 releases. Modern
debug kernels are very slow and inefficient; installing with a debug
kernel seems to exhaust 1GB of RAM quite easily. That's a separate
issue, though, and not relevant to final release.
-- 
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: Recommended system requirements for f20 not sufficient?

[Lars Seipel]

On Wed, Dec 18, 2013 at 11:03:36AM -0800, Adam Williamson wrote:
> Well, I did some testing during F20 cycle which seems to indicate F20
> Shell takes up a lot more memory than F19 when using llvmpipe. We're not
> sure exactly what's going on yet,

It's not just Gnome Shell's fault I think. At least for some time during
Alpha/Beta even kickstarted text-only installs (virt-install pointed to
an install tree over HTTP) locked up due to lack of memory.  That's with
1 GiB and no swap. Increase that to 1.5 GiB and the install process
completed.

I'll probably retest that with final F20 later, now that the set of
components used for installation doesn't potentially change from one
attempt to the next.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: any report of fedup f19->f20?

[Gavin Flower]

On 20/12/13 12:50, Gavin Flower wrote:

On 20/12/13 12:51, Adam Williamson wrote:

On Fri, 2013-12-20 at 12:44 +1300, Gavin Flower wrote:

Can there be anything more important than the correct way to make
tea???

Sure - vim versus emacs!

Possibly a close second...

Then again, some people might consider /the correct direction to turn 
the teapot in the Southern Hemisphere/, or /precisely how to hold one's 
finger when drinking from a teacup/, as being more important than /vim 
versus emacs arguments/!
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: any report of fedup f19->f20?

[Gavin Flower]

On 20/12/13 12:51, Adam Williamson wrote:

On Fri, 2013-12-20 at 12:44 +1300, Gavin Flower wrote:

Can there be anything more important than the correct way to make
tea???

Sure - vim versus emacs!

Possibly a close second...

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

Re: any report of fedup f19->f20?

[Adam Williamson]

On Fri, 2013-12-20 at 12:44 +1300, Gavin Flower wrote:
> Can there be anything more important than the correct way to make
> tea???

Sure - vim versus emacs!
-- 
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: any report of fedup f19->f20?

[Patrick O'Callaghan]

On Thu, Dec 19, 2013 at 9:39 PM, Gavin Flower  wrote:

> long time. It wasn't frozen. The update ran well last time. But I
> probably would run it when I had to be away from it anyway. You see,
> in America we have a saying: "A watched teapot never boils."
>
> It's an old English saying in fact :)
>
>  Even an unwatched *teapot* should not boil!
>
> You mean a *kettle*?
>
> I am English born.
>


"A watched pot never boils" is the way I've always heard it.

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

Re: any report of fedup f19->f20?

[Gavin Flower]

Can there be anything more important than the correct way to make tea???

On 20/12/13 12:39, Philippe LeCavalier wrote:

Are you guys overtired or something? ;)

Thanks, Phil




On Thu, Dec 19, 2013 at 6:21 PM, Adam Williamson > wrote:


On Fri, 2013-12-20 at 10:39 +1300, Gavin Flower wrote:
> On 20/12/13 06:38, Adam Williamson wrote:
>
> > On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:
> [...]
> > long time. It wasn't frozen. The update ran well last time. But I
> > probably would run it when I had to be away from it anyway.
You see,
> > in America we have a saying: "A watched teapot never boils."
> > It's an old English saying in fact :)
> Even an unwatched teapot should not boil!
>
> You mean a kettle?
>
> I am English born.

I'd actually always heard it as "A watched pot never boils" - not a
teapot, just a pot in general.
--
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: any report of fedup f19->f20?

[Gavin Flower]

On 20/12/13 12:21, Adam Williamson wrote:

On Fri, 2013-12-20 at 10:39 +1300, Gavin Flower wrote:

On 20/12/13 06:38, Adam Williamson wrote:


On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:

[...]

long time. It wasn't frozen. The update ran well last time. But I
probably would run it when I had to be away from it anyway. You see,
in America we have a saying: "A watched teapot never boils."
It's an old English saying in fact :)

Even an unwatched teapot should not boil!

You mean a kettle?

I am English born.

I'd actually always heard it as "A watched pot never boils" - not a
teapot, just a pot in general.

Adam,  I think you are right!

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

Re: any report of fedup f19->f20?

[Philippe LeCavalier]

Are you guys overtired or something? ;)

Thanks, Phil




On Thu, Dec 19, 2013 at 6:21 PM, Adam Williamson wrote:

> On Fri, 2013-12-20 at 10:39 +1300, Gavin Flower wrote:
> > On 20/12/13 06:38, Adam Williamson wrote:
> >
> > > On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:
> > [...]
> > > long time. It wasn't frozen. The update ran well last time. But I
> > > probably would run it when I had to be away from it anyway. You see,
> > > in America we have a saying: "A watched teapot never boils."
> > > It's an old English saying in fact :)
> > Even an unwatched teapot should not boil!
> >
> > You mean a kettle?
> >
> > I am English born.
>
> I'd actually always heard it as "A watched pot never boils" - not a
> teapot, just a pot in general.
> --
> 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: any report of fedup f19->f20?

[Adam Williamson]

On Fri, 2013-12-20 at 10:39 +1300, Gavin Flower wrote:
> On 20/12/13 06:38, Adam Williamson wrote:
> 
> > On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:
> [...]
> > long time. It wasn't frozen. The update ran well last time. But I
> > probably would run it when I had to be away from it anyway. You see,
> > in America we have a saying: "A watched teapot never boils."
> > It's an old English saying in fact :)
> Even an unwatched teapot should not boil!
> 
> You mean a kettle?
> 
> I am English born.

I'd actually always heard it as "A watched pot never boils" - not a
teapot, just a pot in general.
-- 
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: any report of fedup f19->f20?

[Temlakos]

On 12/19/2013 04:39 PM, Gavin Flower wrote:

On 20/12/13 06:38, Adam Williamson wrote:

On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:

[...]

long time. It wasn't frozen. The update ran well last time. But I
probably would run it when I had to be away from it anyway. You see,
in America we have a saying: "A watched teapot never boils."
It's an old English saying in fact :)

Even an unwatched _*teapot*_ should not boil!

You mean a _*kettle*_?

I am English born.


Cheers,
Gavin




Yes, I meant a kettle.

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

Re: any report of fedup f19->f20?

[Frank Murphy]

On Fri, 20 Dec 2013 10:39:04 +1300
Gavin Flower  wrote:
eapot never boils."
> > It's an old English saying in fact :)
> Even an unwatched _*teapot*_ should not boil!
> 

My Dad used boil it, crude oil yeuk!

-- 
Regards,
Frank 
www.frankly3d.com

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

Re: Sugar tweaked on desktop validation matrix

[Dan Mossor]

On 12/19/2013 12:32 AM, Adam Williamson wrote:

Hi, folks. As satellit's been asking me to help him with for ages, I've
changed the desktop validation matrix template page:

https://fedoraproject.org/w/index.php?title=QA:Desktop_validation_results_template&diff=365178&oldid=353762

to better reflect the right way to test Sugar. Sugar's quite different
from other desktops, and satellit regularly tests it against a set of
test cases from the Sugar wiki. It seemed like the best way to represent
this was a separate table for Sugar with a link to those test cases, so
that's what I did. It didn't seem worth the usual draft/review cycle,
since it's really mostly satellit who does the Sugar stuff, so I just
checked he was OK with it then went ahead. If anyone sees any issues or
a better way to do it, please yell!

Ideally it might be nice to write up the upstream test cases a bit more
cleanly in the upstream wiki so we can link to them better, but for now
this'll do, I think. It's a non-blocking desktop anyway, so it's not
hugely important.



Since Sugar is aimed at kids, I'm going to let my kids (9 and 6 years 
old) test it. I'll use as many of the test cases as I can from the 
matrix, and between the three of us we may come up with more.


--
Dan Mossor
Systems Engineer at Large
Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx
San Antonio, Texas, USA
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Recommended system requirements for f20 not sufficient?

[Felix Miata]

On 2013-12-19 15:26 (GMT-0600) Dan Mossor composed:


When there is
storage media besides RAM available, you can run F20 on as little as the
512MB that Ralf is using.


Yesterday I did a HTTP F20 minimal install with .5G RAM and 1.13GHz Piii. The 
second GUI page was taking a long time to finish the two sections I always 
let settle before attempting to proceed with HD selection. Neither init nor 
Anaconda had made use of the swap partition, so I turned it on. That failed 
to speed things along, so I rebooted. Before my first click in second 
Anaconda start I went to tty2 and turned on swap. From there everything 
seemed to move right along nicely, including upping to F21 with Yum during 
second boot and getting KDE started.


Actually using KDE to do anything without crashing failed until I turned off 
X compositing (globally in xorg.conf*), kscreen and nepomuk/strigi.

--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: any report of fedup f19->f20?

[Gavin Flower]

On 20/12/13 06:38, Adam Williamson wrote:

On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:

[...]

long time. It wasn't frozen. The update ran well last time. But I
probably would run it when I had to be away from it anyway. You see,
in America we have a saying: "A watched teapot never boils."
It's an old English saying in fact :)

Even an unwatched _*teapot*_ should not boil!

You mean a _*kettle*_?

I am English born.


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

Re: Recommended system requirements for f20 not sufficient?

[Dan Mossor]

On 12/18/2013 01:21 PM, Akshay Vyas wrote:

On Thu, Dec 19, 2013 at 12:43 AM, Ralf Corsepius  wrote:

On 12/18/2013 08:03 PM, Adam Williamson wrote:


On Wed, 2013-12-18 at 15:03 +0100, Dennis Jacobfeuerborn wrote:


Hi,
i just booted the live iso in a VM with 1G of memory and after I start
"Software" the VM locks up completely after a few seconds. Having "top"
open while starting "Software" shows very little free/cached RAM left
over before the system dies so I upped the RAM of the VM to 2G and with
that the problem disappears.

It looks like the 1G of RAM recommended on http://fedoraproject.org/
really aren't sufficient to run the basic stuff and this should be
updated to probably 1.5-2G RAM or at least 1G RAM + some swap.



Well, I did some testing during F20 cycle which seems to indicate F20
Shell takes up a lot more memory than F19 when using llvmpipe. We're not
sure exactly what's going on yet, I need to find time to circle back and
investigate, but I suspect '1GB in a VM' and '1GB on metal' will be
somewhat different experiences. 1GB is getting a bit thin for the
default desktop with the current typical requirements of GNOME, FF and
LO, though, yeah.



FWIW: F20 runs without many problems on 512k RAM:

# cat /proc/meminfo
MemTotal: 508392 kB
MemFree:  127952 kB

# cat /etc/fedora-release
Fedora release 20 (Heisenbug)

However, this is a system on which Fedora was installed long time ago
gradually upgraded to f20.

Ralf


I tested all Desktop environments on my old PC with 1G (DDR1) and
found out that all DE's are working fine
except GNOME(Default DE) and KDE which gave me some issues(slows down
or freezes) when running Firefox,Chrome,GIMP etc



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






Keep in mind that he's specifically addressing the LIVE iso - since it 
has to load it's entire environment into a RAMDisk, it only makes sense 
that we should be advising 2GB+ for live environments. When there is 
storage media besides RAM available, you can run F20 on as little as the 
512MB that Ralf is using.


--
Dan Mossor
Systems Engineer at Large
Fedora QA Team Volunteer FAS: dmossor IRC: danofsatx
San Antonio, Texas, USA
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: any report of fedup f19->f20?

[Adam Williamson]

On Thu, 2013-12-19 at 13:39 -0500, Temlakos wrote:
> On 12/19/2013 12:38 PM, Adam Williamson wrote:
> > On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:
> >
> >
>  The newest version of fedup available to me (not using
>  updates-testing) is 0.7. ne
> 
>  Is someone going to push fedup version 0,8 to updates (stable) soon?
>  Do I wait for that? Or enable updates-testing and run an update before
>  I proceed?
> >>> It's on its way to stable updates ATM so if you wait you won't have to
> >>> wait long, but it's perfectly safe to grab it from u-t if you want to
> >>> upgrade right now.
> >> I'm not in that kind of hurry. I saw a statement about known issues
> >> with updating. The official line seems to be: fedup version 0.7 will
> >> not work, so don't try it. Either wait, or enable u-t just long enough
> >> to grab version 0.8. (And if one does try it, the new fedup needs
> >> workarounds to clean up the garbage.)
> >>
> >> Since fedora-release also is at issue (for GPG signature checking),
> >> I'll watch the system updates closely for the new fedup.
> > It went to stable for f19 last night, should be making it to mirrors by
> > now. f18 seems to be a bit behind.
> >
> >> My last experience with fedup was instructive. Plymouth ran well with
> >> it, but showed me a very small progress bar that appeared frozen for a
> >> long time. It wasn't frozen. The update ran well last time. But I
> >> probably would run it when I had to be away from it anyway. You see,
> >> in America we have a saying: "A watched teapot never boils."
> > It's an old English saying in fact :)
> 
> OK, the current version of fedup made it out, and I now have it.
> 
> But: shouldn't I also wait for fedup-dracut and fedup-plymouth-dracut to 
> update also? They're still on Version 0.7.

No, you don't need to. Those packages aren't really used on your system,
they're used to generate the special update initramfs you download from
the servers as part of the upgrade process.
-- 
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: xserver fails to resume from suspend (f20)

[Neal Becker]

Adam Williamson wrote:

> On Thu, 2013-12-19 at 07:09 -0500, Neal Becker wrote:
> 
>> Remember I first saw this with nvidia blob - so it's not a nouveau issue.
>> 
>> Here is another strange data point.
>> 
>> It seems to happen 100% of the time when I close laptop and transport to/from
>> work.  But last night tested 3 times close - wait till light is flashing
>> indicating sleep, then open - and no failures.
>> 
>> Then closed it for the night and checked in the morning.  It had failed.
>> 
>> So strange as it may seem - it appears that it has to be shut for more than a
>> short time to fail.
> 
> That's not the case for me, a short suspend or VT switch still triggers
> it. Hmm, maybe we don't have the same thing after all. I still didn't
> get time to look at mine in detail, though, been doing F20 release
> stuff; I'll try and get around to it today...

I'd be extremely surprised if these two very similar sounding failures, 
occurring on the same update, were not closely related 

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

Re: any report of fedup f19->f20?

[Temlakos]

On 12/19/2013 12:38 PM, Adam Williamson wrote:

On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:



The newest version of fedup available to me (not using
updates-testing) is 0.7. ne

Is someone going to push fedup version 0,8 to updates (stable) soon?
Do I wait for that? Or enable updates-testing and run an update before
I proceed?

It's on its way to stable updates ATM so if you wait you won't have to
wait long, but it's perfectly safe to grab it from u-t if you want to
upgrade right now.

I'm not in that kind of hurry. I saw a statement about known issues
with updating. The official line seems to be: fedup version 0.7 will
not work, so don't try it. Either wait, or enable u-t just long enough
to grab version 0.8. (And if one does try it, the new fedup needs
workarounds to clean up the garbage.)

Since fedora-release also is at issue (for GPG signature checking),
I'll watch the system updates closely for the new fedup.

It went to stable for f19 last night, should be making it to mirrors by
now. f18 seems to be a bit behind.


My last experience with fedup was instructive. Plymouth ran well with
it, but showed me a very small progress bar that appeared frozen for a
long time. It wasn't frozen. The update ran well last time. But I
probably would run it when I had to be away from it anyway. You see,
in America we have a saying: "A watched teapot never boils."

It's an old English saying in fact :)


OK, the current version of fedup made it out, and I now have it.

But: shouldn't I also wait for fedup-dracut and fedup-plymouth-dracut to 
update also? They're still on Version 0.7.


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

Re: xserver fails to resume from suspend (f20)

[Adam Williamson]

On Thu, 2013-12-19 at 07:09 -0500, Neal Becker wrote:

> Remember I first saw this with nvidia blob - so it's not a nouveau issue.
> 
> Here is another strange data point.
> 
> It seems to happen 100% of the time when I close laptop and transport to/from 
> work.  But last night tested 3 times close - wait till light is flashing 
> indicating sleep, then open - and no failures.
> 
> Then closed it for the night and checked in the morning.  It had failed.
> 
> So strange as it may seem - it appears that it has to be shut for more than a 
> short time to fail.

That's not the case for me, a short suspend or VT switch still triggers
it. Hmm, maybe we don't have the same thing after all. I still didn't
get time to look at mine in detail, though, been doing F20 release
stuff; I'll try and get around to it today...
-- 
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: any report of fedup f19->f20?

[Adam Williamson]

On Thu, 2013-12-19 at 05:08 -0500, Temlakos wrote:


> > > The newest version of fedup available to me (not using
> > > updates-testing) is 0.7. ne
> > > 
> > > Is someone going to push fedup version 0,8 to updates (stable) soon?
> > > Do I wait for that? Or enable updates-testing and run an update before
> > > I proceed?
> > It's on its way to stable updates ATM so if you wait you won't have to
> > wait long, but it's perfectly safe to grab it from u-t if you want to
> > upgrade right now.
> 
> I'm not in that kind of hurry. I saw a statement about known issues
> with updating. The official line seems to be: fedup version 0.7 will
> not work, so don't try it. Either wait, or enable u-t just long enough
> to grab version 0.8. (And if one does try it, the new fedup needs
> workarounds to clean up the garbage.)
> 
> Since fedora-release also is at issue (for GPG signature checking),
> I'll watch the system updates closely for the new fedup.

It went to stable for f19 last night, should be making it to mirrors by
now. f18 seems to be a bit behind.

> My last experience with fedup was instructive. Plymouth ran well with
> it, but showed me a very small progress bar that appeared frozen for a
> long time. It wasn't frozen. The update ran well last time. But I
> probably would run it when I had to be away from it anyway. You see,
> in America we have a saying: "A watched teapot never boils."

It's an old English saying in fact :)
-- 
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: Proposed validation test case: root on LVM thinp

[Adam Williamson]

On Thu, 2013-12-19 at 08:43 -0500, Kamil Paral wrote:
> > > I wrote
> > > https://fedoraproject.org/wiki/QA:Testcase_anaconda_lvmthinp_rootfs ,
> > > and I propose we add it to the installation validation matrix for F21
> > 
> > I am concerned by this sentence:
> > "Proceed with installation, leaving all other settings at default where
> > possible, using sensible values for anything you must select or fill in "
> > 
> > When I do these kind of test cases (file systems), I usually choose minimal
> > install, because it's fastest and the installed package set doesn't really
> > matter. The installer needs not to crash and the system needs to boot,
> > that's it. I also combine it with other appropriate test cases, like nfs
> > repo and vnc or similar.
> > 
> > If we include requirements like this, we will have a bit higher certainty
> > that everything worked correctly and no other choices interfered, but we
> > will be much less productive. And anaconda test cases drain 90% of our time
> > already.
> > 
> > I think that as long as we execute these test cases manually, combining
> > multiple test cases in a single pass (or picking non-default but fastest
> > methods l
> 
> (Damn Ctrl+Enter)
> 
> I think that as long as we execute these test cases manually, combining 
> multiple test cases in a single pass (or picking non-default but fastest 
> methods like minimal install) is a necessary evil. Once we do it via 
> automation, we can of course try to keep all different variables separated 
> and execute hundreds and hundreds of test runs to cover possible combination. 
> (That will also hit its limit, btw. But adding processing power is easier 
> than adding people.)

I didn't really mean to preclude the use of a minimal package set, I'm
just trying to exclude the problems we've been having whereby the test
cases and criteria are kind of getting 'gamed' with odd choices =) I'll
see if I can find a happy medium...
-- 
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: Proposed validation test case: root on LVM thinp

[Kamil Paral]

> > I wrote
> > https://fedoraproject.org/wiki/QA:Testcase_anaconda_lvmthinp_rootfs ,
> > and I propose we add it to the installation validation matrix for F21
> 
> I am concerned by this sentence:
> "Proceed with installation, leaving all other settings at default where
> possible, using sensible values for anything you must select or fill in "
> 
> When I do these kind of test cases (file systems), I usually choose minimal
> install, because it's fastest and the installed package set doesn't really
> matter. The installer needs not to crash and the system needs to boot,
> that's it. I also combine it with other appropriate test cases, like nfs
> repo and vnc or similar.
> 
> If we include requirements like this, we will have a bit higher certainty
> that everything worked correctly and no other choices interfered, but we
> will be much less productive. And anaconda test cases drain 90% of our time
> already.
> 
> I think that as long as we execute these test cases manually, combining
> multiple test cases in a single pass (or picking non-default but fastest
> methods l

(Damn Ctrl+Enter)

I think that as long as we execute these test cases manually, combining 
multiple test cases in a single pass (or picking non-default but fastest 
methods like minimal install) is a necessary evil. Once we do it via 
automation, we can of course try to keep all different variables separated and 
execute hundreds and hundreds of test runs to cover possible combination. (That 
will also hit its limit, btw. But adding processing power is easier than adding 
people.)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Proposed validation test case: root on LVM thinp

[Kamil Paral]

> I wrote
> https://fedoraproject.org/wiki/QA:Testcase_anaconda_lvmthinp_rootfs ,
> and I propose we add it to the installation validation matrix for F21

I am concerned by this sentence:
"Proceed with installation, leaving all other settings at default where 
possible, using sensible values for anything you must select or fill in "

When I do these kind of test cases (file systems), I usually choose minimal 
install, because it's fastest and the installed package set doesn't really 
matter. The installer needs not to crash and the system needs to boot, that's 
it. I also combine it with other appropriate test cases, like nfs repo and vnc 
or similar.

If we include requirements like this, we will have a bit higher certainty that 
everything worked correctly and no other choices interfered, but we will be 
much less productive. And anaconda test cases drain 90% of our time already.

I think that as long as we execute these test cases manually, combining 
multiple test cases in a single pass (or picking non-default but fastest 
methods l


> and later, with release level Beta, as it matches this criterion:
> 
> https://fedoraproject.org/wiki/Fedora_20_Beta_Release_Criteria#Guided_partitioning
> 
> "When using the guided partitioning flow, the installer must be able
> to: ... Complete an installation using any combination of disk
> configuration options it allows the user to select"
> 
> LVM thinp is now one of the options on the 'filesystem type' dropdown on
> the Installation Options screen, which is what 'disk configuration
> options' in that criterion is talking about.
> 
> Anyone have feedback on the test case, or the proposed inclusion in the
> matrices? I based the test case on the ext4 rootfs one but tidied it up
> somewhat, and placed stronger restrictions on changing other
> configuration during the test; I will probably go through all the
> filesystem-y test cases and propose similar changes, if we think that's
> a good idea. We should try to make the whole set consistent.
> --
> 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: xserver fails to resume from suspend (f20)

[Neal Becker]

Adam Williamson wrote:

> On Wed, 2013-12-18 at 20:18 -0500, Neal Becker wrote:
>> Adam Williamson wrote:
>> 
>> > On Wed, 2013-12-18 at 11:56 -0800, Adam Williamson wrote:
>> >> On Wed, 2013-12-18 at 07:33 -0500, Neal Becker wrote:
>> >> > Neal Becker wrote:
>> >> > 
>> >> > > Just updated f19->f20.  Now resume from suspend is broken.
>> >> > > 
>> >> > > First tried with nvidia blob.  On resume just got blank screen.  Could
>> >> > > switch vt, but couldn't wake up display.
>> >> > > 
>> >> > > Then removed nvidia back to nouveau.  This time, on resume I just see
>> >> > > the fedora
>> >> > > boot splash.  Cannot get any response to keys, except ctrl-alt-bs
>> >> > > (could switch vt).
>> >> > > 
>> >> > 
>> >> > Nothing interesting found in /var/log/messages or
>> >> > /var/log/Xorg.0.log.old, but one note: I'm using kde (kdm)
>> >> 
>> >> That's fun - I'm seeing something similar on F21 (and had it
>> >> intermittently with late F20) but on GNOME. On GNOME, restarting the
>> >> Shell with alt-f2, r makes everything work.
>> >> 
>> >> Do you have a cursor when you see the bootsplash? Can you move it, and
>> >> does it change shape in the places you'd expect it to? I suspect the
>> >> same thing's happening to us both...
>> > 
>> > Just noticed something interesting - I just switched VTs, and saw the
>> > same bug (when I came back to VT1, the bootsplash was showing, and I
>> > needed alt-f2, r to get Shell back). Does that happen to you too?
>> 
>> I have a cursor I can move.  Didn't notice it change shape - I'll check next
>> time.
>> 
>> Don't quite understand the 2nd phenomenon you're describing.  Is this when
>> it's
>> locked up on resume that you see this?  Or just any time you switch VTs? 
>> Don't quite understand how you triggered it - all I have to do is open the
>> laptop lid and I'm looking at a bootsplash and have to kill xserver.
> 
> Just switching VTs with no suspend involved seems to trigger it here,
> now. I don't get much in the system logs, though. I'll have to
> investigate with drm.debug , see if it's a nouveau issue.

Remember I first saw this with nvidia blob - so it's not a nouveau issue.

Here is another strange data point.

It seems to happen 100% of the time when I close laptop and transport to/from 
work.  But last night tested 3 times close - wait till light is flashing 
indicating sleep, then open - and no failures.

Then closed it for the night and checked in the morning.  It had failed.

So strange as it may seem - it appears that it has to be shut for more than a 
short time to fail.

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

Re: Thoughts about Travis-CI integration

[Alexander Todorov]

На 18.12.2013 20:09, Tim Flink написа:

On a side note, it might be interesting to find out what percentage of
packages are running things in %check. I don't know what we would do
with that metric, but I think it would be interesting :)



I have something in the works which can be modified to extract this info. It 
should be fairly easy to make a good guesstimate of the presence/non presence of 
test suites as well.  I think I'll start from here.



Does Fedora have its own CI infrastructure coupled with Koji ?


That depends on what you consider CI to be, I guess. I consider both
autoqa and taskotron to be forms of CI but not the exact same thing as
travis or jenkins.

Both autoqa and taskotron are designed to run various things based on a
package's state in either koji or bodhi.



Thanks, I have to look into these. I gave Travis as example because it is well 
known and because somebody else decided to make use of it in python-bugzilla.





I'm still unclear on what you're looking to do. Are you talking about
looking for test suites in package upstreams and running those tests,
regardless of whether they're run in %check during build? Are you
talking about creating and maintaining an out-of-band set of unit tests
for packages without an upstream unit test suite? Are you talking about
creating a set of package-specific functional/integration test suites
that are run when packages are built?



Pretty much all of these in the long term but I wanted to get a general feeling 
so I can concentrate the effort on something specific.



* For packages which have upstream test suites (e.g. parted) - contribute more 
tests where necessary; Ideally covering bugs reported against Fedora or RHEL for 
which there isn't a test case.


* For packages without upstream test suite my preference is to create one and 
contribute it back upstream. If upstream doesn't accept it and the package is 
critical enough maybe maintain that in the Fedora branch.


* Functional/integration test suites (e.g. using Beaker tasks) are less priority 
goal for the moment but also need to be considered. For some packages these are 
more suitable (e.g. anaconda), for others maybe not (e.g. pykickstart seems to 
have fairly good amount of unit tests).



Whatever the test suite(s) come out to be we need an environment(or 
environments) where to execute them and a method of starting the suite. I can 
see how some test cases are part of %check and can halt the build process and 
others are started async after the build and are left for Fedora QA and devel to 
investigate.


In the case of Travis, test runs are triggered by git commits and Travis is not 
connected to any build infrastructure from what I know. It provides the results 
to whoever is interested in them.







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

Re: any report of fedup f19->f20?

[Temlakos]

On 12/18/2013 09:20 PM, Adam Williamson wrote:

On Wed, 2013-12-18 at 18:58 -0500, Temlakos wrote:

On 12/18/2013 06:50 PM, Philippe LeCavalier wrote:


   * I don't actually know one way or another but it feels like
 it might just be similar in my case since I've confirmed I'm
 using 0.8 and it's no different. Has anyone else *not* fixed
 this with the suggested update?

Thanks, Phil






On Wed, Dec 18, 2013 at 6:08 PM, Bruno Medeiros 
wrote:
 BrunoJCM
 (Enviado do Tablet)
 Em 17/12/2013 13:13, "Neal Becker" 
 escreveu:
 >
 > success/failure?
 
 I had this one, I reported on this list a few weeks ago:

 https://bugzilla.redhat.com/show_bug.cgi?id=1038863
 
 fedup 0.8 also fixed the problem for me.
 
 Thanks,
 
 --

 Bruno Medeiros
 
 
 --

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





The newest version of fedup available to me (not using
updates-testing) is 0.7. ne

Is someone going to push fedup version 0,8 to updates (stable) soon?
Do I wait for that? Or enable updates-testing and run an update before
I proceed?

It's on its way to stable updates ATM so if you wait you won't have to
wait long, but it's perfectly safe to grab it from u-t if you want to
upgrade right now.


I'm not in that kind of hurry. I saw a statement about known issues with 
updating. The official line seems to be: fedup version 0.7 will not 
work, so don't try it. Either wait, or enable u-t just long enough to 
grab version 0.8. (And if one /does/ try it, the new fedup needs 
workarounds to clean up the garbage.)


Since fedora-release also is at issue (for GPG signature checking), I'll 
watch the system updates closely for the new fedup.


My last experience with fedup was instructive. Plymouth ran well with 
it, but showed me a /very/ small progress bar that appeared frozen for a 
long time. It wasn't frozen. The update ran well last time. But I 
probably would run it when I had to be away from it anyway. You see, in 
America we have a saying: "A watched teapot never boils."


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

Re: Rawhide heads up - password auth for ssh and selinux

[Chuck Forsberg WA7KGX]

On 12/18/2013 07:59 PM, Bruno Wolff III wrote:
It seems that selinux-policy-3.13.1-10.fc21 is blocking password 
authentication for sshd. Authorized_keys authentication still works. I 
use both together and got a surprise after doing an update and could 
access a system remotely. Using permissive mode works around the 
problem. I have filed bug 1044808 for the issue.
I don't know if this is the same problem:  I did a fresh net install of 
64 bit

Heisenbug Wednesday on my server.  After several hours thunderbird
could not could not fetch mail through Dovecot.  One or the other
had forgotten the required password.  I confirmed that the password
had not changed and restarted Dovecot to no avail.  Finally I rebooted
Heisenbug and all is well.

--
 Chuck Forsberg WA7KGX   c...@omen.com   www.omen.com
Developer of Industrial ZMODEM(Tm) for Embedded Applications
  Omen Technology Inc  "The High Reliability Software"
10255 NW Old Cornelius Pass Portland OR 97231   503-614-0430

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