Fedora 17 updates-testing report

[updates]

The following Fedora 17 Security updates need testing:
 Age  URL
 370  
https://admin.fedoraproject.org/updates/FEDORA-2012-10269/revelation-0.4.14-1.fc17
 182  
https://admin.fedoraproject.org/updates/FEDORA-2013-0455/fedora-business-cards-1-0.1.beta1.fc17
 110  
https://admin.fedoraproject.org/updates/FEDORA-2013-4234/stunnel-4.55-1.fc17
 105  
https://admin.fedoraproject.org/updates/FEDORA-2013-4501/libxslt-1.1.28-1.fc17
 102  
https://admin.fedoraproject.org/updates/FEDORA-2013-4581/libuser-0.57.6-2.fc17
  35  
https://admin.fedoraproject.org/updates/FEDORA-2013-10121/subversion-1.7.10-1.fc17
  24  
https://admin.fedoraproject.org/updates/FEDORA-2013-10940/tomcat6-6.0.37-1.fc17
  16  
https://admin.fedoraproject.org/updates/FEDORA-2013-11568/curl-7.24.0-10.fc17
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-12075/gegl-0.2.0-11.fc17
   5  
https://admin.fedoraproject.org/updates/FEDORA-2013-12441/gallery3-3.0.9-1.fc17
   5  
https://admin.fedoraproject.org/updates/FEDORA-2013-12421/zeroinstall-injector-2.3-1.fc17
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-12400/ansible-1.2.2-1.fc17
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-12745/seamonkey-2.19-1.fc17


The following Fedora 17 Critical Path updates have yet to be approved:
 Age URL
 322  
https://admin.fedoraproject.org/updates/FEDORA-2012-12509/PackageKit-0.7.6-1.fc17
 130  
https://admin.fedoraproject.org/updates/FEDORA-2013-3304/libvpx-1.2.0-1.fc17
   8  
https://admin.fedoraproject.org/updates/FEDORA-2013-12153/xulrunner-22.0-4.fc17
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-12371/nspr-4.10.0-3.fc17


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

dhcp-4.2.5-3.fc17
golang-1.1.1-5.fc17
libxc-2.0.2-1.fc17
seamonkey-2.19-1.fc17

Details about builds:



 dhcp-4.2.5-3.fc17 (FEDORA-2013-12724)
 Dynamic host configuration protocol software

Update Information:

This update fixes how dhclient sends DHCPRELEASE message.

ChangeLog:

* Wed Jul 10 2013 Jiri Popelka  - 12:4.2.5-3
- remove send_release.patch (#979510)

References:

  [ 1 ] Bug #979510 - dhclient: unable to release lease / DHCPRELEASE
https://bugzilla.redhat.com/show_bug.cgi?id=979510




 golang-1.1.1-5.fc17 (FEDORA-2013-12735)
 The Go Programming Language

Update Information:

Don't strip anymore, it breaks all manner of things
Try again at updating this package.
Use lua in pretrans
* Fix update problems (at least for pre-Fedora 19)
* Fix still-often-broken building
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Fix update problems (at least for pre-Fedora 19)
* Fix still-often-broken building
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Fix update problems (at least for pre-Fedora 19)
* Fix still-often-broken building
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
Use lua in pretrans
* Fix update problems (at least for pre-Fedora 19)
* Fix still-often-broken building
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Fix update problems (at least for pre-Fedora 19)
* Fix still-often-broken building
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Fix update problems (at least for pre-Fedora 19)
* Fix still-often-broken building
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Update to golang 1.1.1
Use lua in pretrans
* Fix update problems (at least for pre-Fedora 19)
* Fix still-often-broken building
* Make this package actually usable (sorry)
* Update to golang 1.1.1
* Make this package actually usable (sorry)
* Updat

Fedora 18 updates-testing report

[updates]

The following Fedora 18 Security updates need testing:
 Age  URL
 183  
https://admin.fedoraproject.org/updates/FEDORA-2013-0416/fedora-business-cards-1-0.1.beta1.fc18
 117  
https://admin.fedoraproject.org/updates/FEDORA-2013-3935/puppet-3.1.1-1.fc18
 110  
https://admin.fedoraproject.org/updates/FEDORA-2013-4243/stunnel-4.55-1.fc18
  97  
https://admin.fedoraproject.org/updates/FEDORA-2013-4823/microcode_ctl-2.0-3.fc18
  82  
https://admin.fedoraproject.org/updates/FEDORA-2013-6117/eucalyptus-3.2.2-1.fc18
  40  
https://admin.fedoraproject.org/updates/FEDORA-2013-9707/livecd-tools-18.16-2.fc18
  36  
https://admin.fedoraproject.org/updates/FEDORA-2013-9962/subversion-1.7.10-1.fc18
  17  
https://admin.fedoraproject.org/updates/FEDORA-2013-10713/openstack-keystone-2012.2.4-5.fc18
   9  
https://admin.fedoraproject.org/updates/FEDORA-2013-12108/gegl-0.2.0-11.fc18
   8  
https://admin.fedoraproject.org/updates/FEDORA-2013-12156/dbus-glib-0.100-3.fc18
   8  
https://admin.fedoraproject.org/updates/FEDORA-2013-12193/lldpad-0.9.45-4.fc18
   5  
https://admin.fedoraproject.org/updates/FEDORA-2013-12396/zeroinstall-injector-2.3-1.fc18
   5  
https://admin.fedoraproject.org/updates/FEDORA-2013-12424/gallery3-3.0.9-1.fc18
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-12394/ansible-1.2.2-1.fc18
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-12541/nagstamon-0.9.9-9.fc18
   1  
https://admin.fedoraproject.org/updates/FEDORA-2013-12653/file-roller-3.6.4-1.fc18
   0  
https://admin.fedoraproject.org/updates/FEDORA-2013-12711/seamonkey-2.19-1.fc18


The following Fedora 18 Critical Path updates have yet to be approved:
 Age URL
 151  
https://admin.fedoraproject.org/updates/FEDORA-2013-2192/nautilus-3.6.3-5.fc18
  32  
https://admin.fedoraproject.org/updates/FEDORA-2013-10428/NetworkManager-0.9.8.2-1.fc18,network-manager-applet-0.9.8.2-1.fc18
  10  
https://admin.fedoraproject.org/updates/FEDORA-2013-11959/procps-ng-3.3.3-6.20120807git.fc18
   9  https://admin.fedoraproject.org/updates/FEDORA-2013-12117/lcms2-2.5-1.fc18
   8  
https://admin.fedoraproject.org/updates/FEDORA-2013-12193/lldpad-0.9.45-4.fc18
   8  
https://admin.fedoraproject.org/updates/FEDORA-2013-12195/xulrunner-22.0-4.fc18
   7  
https://admin.fedoraproject.org/updates/FEDORA-2013-12263/samba-4.0.7-1.fc18,sssd-1.9.5-2.fc18,libtdb-1.2.12-1.fc18,libldb-1.1.16-1.fc18
   6  
https://admin.fedoraproject.org/updates/FEDORA-2013-12352/lxpanel-0.5.12-3.fc18
   5  
https://admin.fedoraproject.org/updates/FEDORA-2013-12374/ppp-2.4.5-30.fc18
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-12449/fuse-2.9.3-1.fc18
   4  
https://admin.fedoraproject.org/updates/FEDORA-2013-12445/exo-0.10.2-5.fc18
   3  
https://admin.fedoraproject.org/updates/FEDORA-2013-12570/strigi-0.7.8-1.fc18


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

cbmc-4.3-5.20130515svn.fc18
corosync-2.3.1-1.fc18
create-tx-configuration-0.3-1.fc18
drupal7-i18n-1.9-1.fc18
drupal7-mediawiki_api-1.0-0.8.beta3.fc18
ghc-system-filepath-0.4.7-1.fc18
golang-1.1.1-5.fc18
kde-plasma-applicationname-1.7-3.fc18
latexmk-4.37-1.fc18
libdeltacloud-0.9-7.fc18
libuv-0.10.12-1.fc18
libxc-2.0.2-1.fc18
mediawiki-1.19.7-2.fc18
nodejs-0.10.13-1.fc18
nodejs-i2c-0.1.4-1.fc18
nodejs-js-yaml-2.1.0-1.fc18
nodejs-packaging-3-1.fc18
oath-toolkit-2.2.0-1.fc18
owfs-2.9p1-4.fc18
perl-Module-Build-Tiny-0.024-1.fc18
python-pam-0.1.3-1.fc18
rubygem-rhc-1.10.7-1.fc18
seamonkey-2.19-1.fc18
spyder-2.2.1-1.fc18
zookeeper-3.4.5-6.fc18

Details about builds:



 cbmc-4.3-5.20130515svn.fc18 (FEDORA-2013-12713)
 Bounded Model Checker for ANSI-C and C++ programs

Update Information:

- fix build on s390x
Bounded Model Checker for ANSI-C and C++ programs
Bounded Model Checker for ANSI-C and C++ programs

References:

  [ 1 ] Bug #965570 - Review Request: cbmc - Bounded Model Checker for ANSI-C 
and C++ programs
https://bugzilla.redhat.com/show_bug.cgi?id=965570




 corosync-2.3.1-1.fc18 (FEDORA-2013-12742)
 The Corosync Cluster Engine and Application Programming Interfaces

Update Information:

This update improves stability and addresses several bugs

ChangeLog:

* Wed Jul 10 2013 Jan Friesse  - 2.3.1-1
- New upstream release
- Fix incorrect dates in specfile changelog section
* Mon Mar 25 2013 Jan Friesse  - 2.3.0-3
- Resolves: rhbz

Re: Second draft of revised final criteria, proposed criterion for partition resizing

[Adam Williamson]

On Wed, 2013-07-03 at 16:47 -0700, Adam Williamson wrote:
> Hi folks! Taking into account the feedback on the first draft of the 
> revised criteria, I've updated the draft page with a few changes:
> 
> https://fedoraproject.org/wiki/User:Adamwill/Draft_final_criteria_sandbox

(snip)

> I'd also like to consider adding a criterion that covers resizing, as 
> discussed in the long thread about dual-booting. I think we can add a 
> minimal criterion that's realistically enforceable if we word it right. 
> Let's make that a proposal here on the list, rather than part of the 
> 'revision' draft, though. So, here's my proposal:
> 
> 
> 
> Any installer mechanism for resizing storage volumes must correctly 
> attempt the requested operation.

As everyone seemed OK with these after the revisions, I've gone ahead
and put the rewritten criteria in place as
https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria , and I
am about to add the proposed resize criterion to it. Thanks for all the
feedback, folks!
-- 
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: user list

[Richard Vickery]

On Jul 9, 2013 11:40 PM, "John Morris"  wrote:
>
> On Tue, 2013-07-09 at 20:34 -0600, Stephen John Smoogen wrote:
>
> > This email was not helpful nor being excellent to each other. It also
shows
> > a biased view that shows that the user didn't even try the version that
> > shipped in at least alpha onward which does not use gestures but just a
> > space or return. Next time try to actually be useful.
>
> Agreed.  But then GNOME itself isn't too helpful and excellent hasn't
> been a word applicable to it for a couple of years now.  Ya know we
> wouldn't get ticked off at this stuff if we didn't care about it, and it
> bothers us that stuff that was good and useful for years is now unusable
> rubbish and it was (intentionally?) made impractical to even keep the
> old stuff that worked.  The whole bit with Cortez burning his ships
> might have worked out for him in the history books, but I bet his men
> didn't like it much at the time.  Good grief, now I can't just ditch
> GNOME and move on, I'm going to gave to replace gdm as well.
>
> But no, not an earlier copy of Fedora.  I installed the F19 release in a
> VM and banged away on the keyboard to no visible effect once it timed
> out and went to the tablet/phone style lock screen with the clock on it.
> Only the mouse would get a reaction from it.  Just retried it to avoid
> doubling down on stupid.  :)  Fired up the VM and worked through more
> email until the lock screen appeared.  Typed a character and the blanker
> did clear but my account name remained on the screen and that was as far
> as I could get without the mouse.
>
> Admitted that there are enough display/input bugs on F19 in a KVM
> (hosted on F18) that one could be biting me on this, but this doesn't
> look like a virtualization problem.  Until the username is pointed to it
> doesn't light up and if it isn't lit it doesn't receive keyboard input.
>
> --
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test

Please be careful with your use of the term "us", as this issue doesn't
really "bother" me at all; mine was necessarily only that of an observation
than anything resembling a complaint.

Thanks for the attention Mr. Smoogen,

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

Re: systemd depends so heavily on a files it can not reboot

[Adam Pribyl]

On Wed, 10 Jul 2013, John Morris wrote:


On Wed, 2013-07-10 at 14:09 +0200, Karel Volný wrote:

Dne středa, 10. července 2013 5:13:22 CEST, John Morris  napsal(a):
...

But then I remembered that if things have really went wrong you could boot
with init=/usr/bin/bash.


how do these advices help when the system is already so broken that it cannot 
reboot without help of sysrq or ctrl+alt+del combo?


If it is a remote system you really should look into IPMI.  If the
system is really broken you really can't depend on ctrl-alt-del, SysRq
or anything else to remaining working.  Tell IPMI to toggle reset and
hope the bootloader is still working, if it isn't repeat and boot rescue
media from CD/USB, etc.


All right, this is a next step - hard reset or power interruption.

Normally what you do is (with increasing possibility of damage caused by 
reboot):

1. try to login remotely and find what is going on -> reboot if necessary
2. try to login localy and find what is going on -> reboot if necessary
3. try to reboot localy if login is not possible
4. hard reset the machine if login and reboots are not possible

now what I experience is:
1. I could not login remotely (ssh was segfaultin, dono whyg)
2. I could not login localy, login just accepted my credentials and 
printed the login prompt again (systemd @getty was broken, could not be 
started)
3. I could not reboot localy (system @ctrl-alt-del was broken), system was 
running but absolutely no reaction to ctrl-alt-del 
4. I only could do hard reset (IMPI, button, remote UPS whatever)


In my opinion systemd should not ignore the option 3 completely. The 
keyboard input should at least attempt to 
TERM->KILL->sync->mount ro->halt. ATM if it has no ctrl-alt-del.target 
file it does nothing, just sits there leaving the system fully running, 
even thou local soft reset was requested and systemd knows that.


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

Re: systemd depends so heavily on a files it can not reboot

[Adam Pribyl]

On Wed, 10 Jul 2013, "Jóhann B. Guðmundsson" wrote:


On 07/10/2013 12:32 PM, Karel Volný wrote:
Dne úterý, 9. července 2013 16:57:22 CEST, "Jóhann B. Guðmundsson" 
napsal(a):
No need too, Bill will just close this WONTFIX and reach through the 
screen and smack you on the back of your head or Václav will just 
find you with something to throw at you, either way you need to find 
a helmet and start running 


I don't think that asking at least for a link to formal decision about 
the change deserves any smacking ... we're talking about Red Hat's 
Bugzilla, not about GNOME's instance




The fact is that Adam Pribyl has just been lucky not experiencing that 
with the other init system neither him nor you have ever pointed to the 
actual regression but I'm very eager to read you comparison on sysv init 
or upstart for that matter handling of a reboot situation when dealing 
with file corruption of their relevant files in comparison with systemd 
and how that is somehow being handled differently now then it has been 
in the past which is why his  ( Adam P ) bug report against systemd got 
closed wontfix any magic key combo wont fix corrupted system files no 
matter how you wish for it.


Please do not take me wrong, but I do not want magic key to fix a 
corrupted filesystem. It just looks weird to me, that pressing "magic key" 
with systemd could do absolutely nothing, which is not something I was 
used to. Also I argue for the "magic key" to do at least something like 
TERM and KILL or sync and reboot.


You are right there is no analysis of init vs. systemd in case of 
corruption, let me try a few points:


1. init has one inittab config (rc scripts are not a something init hard 
depends on), that was cached vs. systemd has a miriad of crossdependet 
units that are not cached. Init survives the damage of inittab (or rc 
scripts) without issue, systemd not (while it looses just some of its 
functions depending on a files beeing corrupted).


2. damage of binaries like reboot probably has no impact on init ability 
to send TERM and KILL signal to all processes efectively limiting any 
further writes to (any) filesystem. On systemd system all those files link 
to one binary - systemctl, not sure so far, how critical this is for 
systemd.


I am not a systemd hater, I am just triing to point to something that is a 
systemd weaknes and could be somehow fixed (e.g. by caching the unit files 
or implementing failover magic key). It looks to me, that as systemd is 
accumulating more and more functions, it is getting a bigger single point 
of failure.



JBG



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

Re: systemd depends so heavily on a files it can not reboot

[John Morris]

On Wed, 2013-07-10 at 14:09 +0200, Karel Volný wrote:
> Dne středa, 10. července 2013 5:13:22 CEST, John Morris  napsal(a):
> ...
> > But then I remembered that if things have really went wrong you could boot
> > with init=/usr/bin/bash.
> 
> how do these advices help when the system is already so broken that it cannot 
> reboot without help of sysrq or ctrl+alt+del combo?

If it is a remote system you really should look into IPMI.  If the
system is really broken you really can't depend on ctrl-alt-del, SysRq
or anything else to remaining working.  Tell IPMI to toggle reset and
hope the bootloader is still working, if it isn't repeat and boot rescue
media from CD/USB, etc.


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

Re: ABRT shows a problem with google-chrome-unstable Google Wallet Service...

[Adam Williamson]

On Wed, 2013-07-10 at 11:50 -0500, Kevin Martin wrote:

> Or maybe this from the not-reportable file (a message, by the way, that makes 
> no sense at the point where it says "free and Nouveau
> driver"):
> 
> Your problem seems to be caused by NVIDIA graphics driver
> 
> The NVIDIA graphics drivers are proprietary, and many kernel developers
> consider this driver to violate the GPL license of the kernel. Fedora
> does not include proprietary software.
> 
> Fedora Suggests: Consider using the free and Nouveau driver instead or use
> a graphics adapter from Intel or AMD or any other manufacturer that provides
> full specifications and/or source code.
> 
> 
> Those are the only files in the abrt directory that even mention nVidia.  
> Does this help?

I was meaning the message the abrt GUI app shows you.
-- 
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: user list

[Adam Williamson]

On Wed, 2013-07-10 at 11:36 -0500, John Morris wrote:
> > Works fine here. What you're describing does not sound like the normal 
> > lock screen at all, to me. The lock screen has the user name and a 
> > password text entry box beneath it. Anything you type shows up in that 
> > box.
> 
> Boot up, push the mouse away from the center of the screen and wait.
> Once the lock screen shows up try getting anywhere without the mouse.
> It certainly won't let me in.  The blue lock screen did vanish but no
> keyboard activity would make my name vanish and a password prompt
> appear.  Name remains in the Emo theme... dark grey text on a black
> screen.

Wait, are you talking about the lock screen *during gdm*? If so I think
the issue with it not working as well as the lock screen *during a user
session* is known and reported upstream.
-- 
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: user list

[John Morris]

> Works fine here. What you're describing does not sound like the normal 
> lock screen at all, to me. The lock screen has the user name and a 
> password text entry box beneath it. Anything you type shows up in that 
> box.

Boot up, push the mouse away from the center of the screen and wait.
Once the lock screen shows up try getting anywhere without the mouse.
It certainly won't let me in.  The blue lock screen did vanish but no
keyboard activity would make my name vanish and a password prompt
appear.  Name remains in the Emo theme... dark grey text on a black
screen.


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

Re: ABRT shows a problem with google-chrome-unstable Google Wallet Service...

[Adam Williamson]

On 2013-07-10 7:18, Kevin Martin wrote:

On 07/09/13 23:03, Ankur Sinha wrote:

On Tue, 2013-07-09 at 21:17 -0500, Kevin Martin wrote:

So how should I report this?  Is there some way to force ABRT to
report this?


Chrome? I thought ABRT only reports issues for Fedora packages? You 
may

be able to save the ABRT log and manually file a bug wherever chrome's
bug tracker is, but I really don't think ABRT will let you file a bug 
at

Fedora's bugzilla for this package.

The exact ABRT error message would be helpful too.




In retrospect, it appears that what abrt caught was "Process
/opt/google/chrome/chrome was killed by signal 6 (SIGABRT)" which
probably occurred as a result of my closing chrome but then logging
out of X, most likely before all of the chrome processes had
completely shut down.  The thing that bugs me most is that the method
by which abrt determines nVidia vs nouveau is obviously flawed
as I'm not using nVidia (at this time).  That needs to be worked fixed.


Please, as someone asked, post the precise message. It may be that what 
it actually says is that your kernel is tainted by a binary driver, *for 
instance* the NVIDIA driver (as that's the one most people tend to be 
using).

--
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: [Fedora QA] #389: Proposed Test Day - AD trusts with POSIX attributes in AD and support for old clients (was: Proposed Test Day - AD trusts with POSIX attributes in AD and support of old clients)

[Fedora QA]

#389: Proposed Test Day - AD trusts with POSIX attributes in AD and support for
old clients
---+---
  Reporter:  dpal  |  Owner:  adamwill
  Type:  task  | Status:  assigned
  Priority:  major |  Milestone:  Fedora 19
 Component:  Test Day  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+---

Comment (by martix):

 Here it is:
 
https://fedoraproject.org/wiki/Test_Day:2013-07-25_AD_trusts_with_POSIX_attributes_in_AD_and_support_for_old_clients

 Note for Fedora QA guys: I created table for tracking "after final release
 Test Days":
 https://fedoraproject.org/wiki/QA/Fedora_19_test_days#After_final_release
 We can use it for testing major updates like rolling releases (kernel,
 KDE, ...)

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: ABRT shows a problem with google-chrome-unstable Google Wallet Service...

[Kevin Martin]

On 07/09/13 23:03, Ankur Sinha wrote:
> On Tue, 2013-07-09 at 21:17 -0500, Kevin Martin wrote:
>> So how should I report this?  Is there some way to force ABRT to
>> report this?
> 
> Chrome? I thought ABRT only reports issues for Fedora packages? You may
> be able to save the ABRT log and manually file a bug wherever chrome's
> bug tracker is, but I really don't think ABRT will let you file a bug at
> Fedora's bugzilla for this package.
> 
> The exact ABRT error message would be helpful too.
> 
> 
> 
In retrospect, it appears that what abrt caught was "Process 
/opt/google/chrome/chrome was killed by signal 6 (SIGABRT)" which
probably occurred as a result of my closing chrome but then logging out of X, 
most likely before all of the chrome processes had
completely shut down.  The thing that bugs me most is that the method by which 
abrt determines nVidia vs nouveau is obviously flawed
as I'm not using nVidia (at this time).  That needs to be worked fixed.

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

The heroes of Fedora updates testing in Q2 2013

[Kamil Paral]

Thanks anyone involved. You can see the write-up here:

https://kparal.wordpress.com/2013/07/10/the-heroes-of-fedora-updates-testing-in-q2-2013/
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: systemd depends so heavily on a files it can not reboot

[Jóhann B. Guðmundsson]

On 07/10/2013 12:32 PM, Karel Volný wrote:
Dne úterý, 9. července 2013 16:57:22 CEST, "Jóhann B. Guðmundsson"  
napsal(a):
No need too, Bill will just close this WONTFIX and reach through the 
screen and smack you on the back of your head or Václav will just 
find you with something to throw at you, either way you need to find 
a helmet and start running 


I don't think that asking at least for a link to formal decision about 
the change deserves any smacking ... we're talking about Red Hat's 
Bugzilla, not about GNOME's instance




For the first the enablement of sysrq  has been discussed before ( check 
mailing list archives and bugzilla )  which btw Bill rejected at least 
once himself secondly  ( and looking at the bug now has done so again ) 
and you did not even bother to backup your acclaimed "regression" when 
you reopen the bug and wanted every to get in their flamesuit


"Ctrl+Alt+Del has worked in the past

now that doesn't work

this is a regression"


The fact is that Adam Pribyl has just been lucky not experiencing that 
with the other init system neither him nor you have ever pointed to the 
actual regression but I'm very eager to read you comparison on sysv init 
or upstart for that matter handling of a reboot situation when dealing 
with file corruption of their relevant files in comparison with systemd 
and how that is somehow being handled differently now then it has been 
in the past which is why his  ( Adam P ) bug report against systemd got 
closed wontfix any magic key combo wont fix corrupted system files no 
matter how you wish for it.


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

Re: systemd depends so heavily on a files it can not reboot

[Karel Volný]

Dne úterý, 9. července 2013 16:57:22 CEST, "Jóhann B. Guðmundsson"  napsal(a):
No need too, Bill will just close this WONTFIX and reach 
through the screen and smack you on the back of your head or 
Václav will just find you with something to throw at you, either 
way you need to find a helmet and start running 


I don't think that asking at least for a link to formal decision about the 
change deserves any smacking ... we're talking about Red Hat's Bugzilla, not 
about GNOME's instance

K.

--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp ka...@jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: systemd depends so heavily on a files it can not reboot

[Adam Pribyl]

Thanks to all for their opinion.

Now the last question: Could init sent on ctr-alt-del at least TERM and 
KILL to all processes in case, everything else failed ?

Could systemd do that?

My answers are YES and NO, but I may be wrong.

For systemd I saw (after power interruption) in the log this:
Jul  6 11:46:51 server systemd[1]: Failed to enqueue ctrl-alt-del.target 
job: Unit ctrl-alt-del.target failed to load: Not a directory. See system logs and 'systemctl status 
ctrl-alt-del.target' for details.

This is the only response to ctrl-alt-del.

You can of course "see" nothing, you can not login localy because:
Jul  6 11:45:42 server systemd[1]: getty@tty1.service holdoff time over, 
scheduling restart.


Adam Pribyl


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

Re: systemd depends so heavily on a files it can not reboot

[Karel Volný]

Dne středa, 10. července 2013 5:13:22 CEST, John Morris  napsal(a):
If you want sysrq and understand the implications you can enable it 

...

But then I remembered that if things have really went wrong you could boot
with init=/usr/bin/bash.


how do these advices help when the system is already so broken that it cannot 
reboot without help of sysrq or ctrl+alt+del combo?

K.

--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp ka...@jabber.cz
:: "Never attribute to malice what can
::  easily be explained by stupidity."
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

systemd-cryptsetup - crypttab -keyfile F20

[Frank Murphy]

Have glanced at:
http://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html


I have a keyfile for all luks, excluding /root which is passphrase.
keyfiles is stored in /root
The /root is the only luks-foo listed in /etc/grub2.cfg
Has worked up to recently.

How can I force systemd to use /etc/crypttab, and ignore itself
(systemd-cryptsetup), if that is the ideal option.

-- 
Regards,
Frank - I check for new mail app. 20min
www.frankly3d.com
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: user list

[Adam Williamson]

On 2013-07-09 23:40, John Morris wrote:

On Tue, 2013-07-09 at 20:34 -0600, Stephen John Smoogen wrote:

This email was not helpful nor being excellent to each other. It also 
shows
a biased view that shows that the user didn't even try the version 
that
shipped in at least alpha onward which does not use gestures but just 
a

space or return. Next time try to actually be useful.


Agreed.


...

  But then GNOME itself isn't too helpful and excellent hasn't

been a word applicable to it for a couple of years now.  Ya know we
wouldn't get ticked off at this stuff if we didn't care about it, and 
it
bothers us that stuff that was good and useful for years is now 
unusable

rubbish and it was (intentionally?) made impractical to even keep the
old stuff that worked.


...and then you went and did it some more.

Please. Stop. We won't have this kind of pointless bashing and 
ridiculous conspiracy theorizing on test@. Take it elsewhere. Or keep it 
under your hat.


I installed the F19 release in a

VM and banged away on the keyboard to no visible effect once it timed
out and went to the tablet/phone style lock screen with the clock on 
it.

Only the mouse would get a reaction from it.  Just retried it to avoid
doubling down on stupid.  :)  Fired up the VM and worked through more
email until the lock screen appeared.  Typed a character and the 
blanker
did clear but my account name remained on the screen and that was as 
far

as I could get without the mouse.

Admitted that there are enough display/input bugs on F19 in a KVM
(hosted on F18) that one could be biting me on this, but this doesn't
look like a virtualization problem.  Until the username is pointed to 
it

doesn't light up and if it isn't lit it doesn't receive keyboard input.


Works fine here. What you're describing does not sound like the normal 
lock screen at all, to me. The lock screen has the user name and a 
password text entry box beneath it. Anything you type shows up in that 
box.

--
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