Re: slow koji downloads?
On 04/14/2016 10:18 PM, Ed Greshko wrote: On 04/15/16 11:00, Chris Murphy wrote: Firefox is estimating 3+ hours for the latest ISO. https://kojipkgs.fedoraproject.org/compose/branched/Fedora-24-20160411.n.1/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-24-20160411.n.1.iso I vaguely recall there isn't an alternate for koji downloads? I've opened a ticket. https://fedorahosted.org/fedora-infrastructure/ticket/5239 FWIW, I'm in Taiwan and just issued a wget for that URL and it looks like the download will finish in about 12 minutes. yeah, took me ~14 minutes for the KDE nightly on a /very/ unstable AT Uverse connection. -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Ambassador | Fedora CommOps FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
Re: problems with redhat bugzilla?
On 10/01/2015 07:24 AM, Sérgio Basto wrote: Hello, On Qua, 2015-09-30 at 14:41 +0200, Karel Volný wrote: Hi, just FTR, what FTR means ? FTR means "For The Record" -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: The most recent kernel: Plague of Fives, and fatally inefficient networking
On 09/24/2015 02:27 PM, Temlakos wrote: Everyone: 1. The kernel, once again, is prone to an annoying flaw: it produces a Plague of Fives. Any time a text box opens up, a string of repeated digits 5 appears. The only way to shut it off is to type "5" again. /No/, kernel group! Do /not/ tell me I have a problem with a sticking 5 key. If that were the problem, then pressing Shift would change "555..." to 55%%..." It doesn't. More to the point, the Plague of Fives tended to go away with the next iteration of the kernel. Temlakos Huh, and here I thought my "refurbished" Logitech Wave wireless keyboard wasn't fully refurbished. I had a weird problem with the 5 key a while ago - the only way to stop it was to hit "5" on the number row. No other key would stop it, and shift didn't change it. But it's gone now. I think. -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: Kernel 4.0.1/4.0.2
On 05/08/2015 11:27 AM, Mike Chambers wrote: Has anyone gotten the above kernels from subject to boot with a nouveau video driver and/or with plasma 5? The latest kernel that works is 4.0.0-1, and with latest libdrm that has the latest fixed. I get debug menu when plasma tries to load on those 2 kernels and not sure which is the problem, video or kde/plasma? As I said on the KDE list, My Asus G55VW with discrete NVIDIA GeForce GTX 660M GPU boots just fine with: kernel-4.0.1-300.fc22.x86_64 xorg-x11-drv-nouveau-1.0.11-2.fc22.x86_64 libdrm-2.4.60-1.fc22.x86_64 kf5-plasma-5.9.0-1.fc22.x86_64 plasma-workspace-5.3.0-3.fc22.x86_64 sddm-0.10.0-4.fc22.x86_64 -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: fc22-tc2 VTs unusable
On 05/07/2015 12:37 PM, Neal Becker wrote: This is a new Lenovo X1 Carbon (v3). I booted up Fedora-Live-KDE-x86_64-22-TC2.iso It boots OK, but on switching to VT (alt-ctrl-f2), the screen starts flashing and is unusable. The video is 00:02.0 VGA compatible controller: Intel Corporation Broadwell-U Integrated Graphics (rev 09) Don't the X1 systems have the function keys remapped in BIOS to actual functions, as opposed to F1-12? IIRC, there's either a setting in the firmware or a (soft) switch on the keyboard somewhere to turn this off. Dan -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: FC22 KDE5 Application Edit
On 05/07/2015 08:23 AM, Adrian wrote: 'Edit Applications' from left click on K button popup menu item does not function ? Anyone alse seeing this ? Cannot edit KDE menu. Adrian ... vk4tux Works for melatest F22 package set (as of this morning). Dan -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: F22 Beta: mouse is very very slow
On 05/04/2015 02:37 PM, Adam Williamson wrote: On Mon, 2015-05-04 at 11:31 -0500, Dan Mossor wrote: I can confirm this using a Logitech MX510 mouse with the Logitech 2.4GHz Unifying Receiver. Mouse is, for all intents and purposes, unusable. The keyboard (Logitech K350) glitches are far enough apart to be usable, but the mouse is a no-go. As you're using entirely different hardware but not *all* hardware is affected (my wired Logitech mouse is fine), this is very likely to be two different issues you should file separately. Just to close this outI moved my USB receiver from the back of the tower case where it was ~1m away from the mouse and keyboard and not LOS to the front of the tower where it is now LOS and ~.5m away, and my issues have cleared up. Looks like faulty Logitech hardware in my case (as my Wireless Performance MX mouse works just fine within 30m of the receiver). -Dan -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: KDE, spins, and minimal install are nonproduct?
On 05/05/2015 08:34 PM, Chris Murphy wrote: Is KDE workstation product or nonproduct? What about minimal install? I'm hitting this bug with a minimal install Fedora 21 and using fedup --product=nonproduct https://bugzilla.redhat.com/show_bug.cgi?id=1214255 The only Fedora products, now flavors, are Workstation, Server, and Cloud. With that out of the way, the _only_ release that the --product switch is supported on for fedup is on Fedora 20. If you are on Fedora 21 already, your release flavor is already listed in /etc/os-release - or, it was supposed to be. I don't see it anymore in any of my F21 or F22 systems. -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: F22 Beta: mouse is very very slow
On 05/03/2015 08:27 AM, Robert M. Albrecht wrote: Hi, never has this problem: F22 beta installs and runs great. But my mouse is slow as hell. Booting F21 on the same machines: everything ok. I have no clue where to have a peek. No visible bugs in xorg.log, dmessage, ... Chaning mouse properties in control center has no effect. Any ideas ? cu romal I can confirm this using a Logitech MX510 mouse with the Logitech 2.4GHz Unifying Receiver. Mouse is, for all intents and purposes, unusable. The keyboard (Logitech K350) glitches are far enough apart to be usable, but the mouse is a no-go. -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Suggestion: end sending meeting minutes to test@
On 05/04/2015 05:43 PM, Adam Williamson wrote: Hey folks! Just a quick mail to suggest we stop sending minutes from the QA and blocker bug review meetings to test@. There is a system in place now which automatically sends minutes to the dedicated mailing list, meetingminutes - you can see that both QA and blocker bug meetings are present in the archives there: https://lists.fedoraproject.org/pipermail/meetingminutes/2015 -May/date.html you can also find the minutes directly in meetbot: http://meetbot.fedoraproject.org/teams/fedora-qa/ http://meetbot.fedoraproject.org/fedora-blocker-review/ and I still update the wiki page with links to the QA minutes: https://fedoraproject.org/wiki/QA/Meetings so I think it's well enough covered. Would anyone miss the minutes if they weren't sent to test@ any more? Thanks! No, I wouldn't miss them. +1 -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: Annoying bug in NM1.0.0-8
On 04/21/2015 01:31 PM, Chris Murphy wrote: It may be some weir interaction between the router and NM. I'm using dd-wrt on the router. What about you, danofsatx? Chris Murphy My router is a Motorola NVG589 Uverse Gateway. I tracked my issue down - it is a change in how firewalld processed my direct rules. I'm not exactly sure what happened during fedup, but I stopped firewalld, flushed the IPTables rules, and restarted firewalld, and it appears to have reprocessed my rules properly. -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Annoying bug in NM1.0.0-8
On 04/19/2015 05:54 PM, Scott Robbins wrote: On Sun, Apr 19, 2015 at 03:36:11PM -0600, Chris Murphy wrote: On Sun, Apr 19, 2015 at 2:57 PM, Dan Mossor danofs...@gmail.com wrote: I've noticed something else,also - I can't get F22 to see my wired interface to compare with wireless to see if I can narrow it down some more. The GUI applet simply won't activate the interface, and nmcli tells me Error: Connection activation failed: Connection 'Home' is not available on the device enp4s0 at this time. I'm not having that problem, I can connect to wired but it's not used. The laptop continues to use wireless unless I turn wireless off, then it falls back to wired. But this behavior isn't new, as far as I know it's always worked this (incorrrect) way. Isn't that a NetworkManager, rather than Fedora, thing? DISCLAIMER--I usually remove NetworkManager and then, if I have a machine that uses both wired and wireless, don't set my network to start on boot as what I want to use changes, depending upon the situation. NetworkManager has come a long way since the days of randomly resetting your connections. I thought it was fairly solid at the 0.9 release, and use it on just about every system now including my servers. The Cockpit integration with NetworkManager has made it dead easy and nearly failproof, and nmcli is in a powerful tool in it's own right. However, the usefulness of 1.0 is suspect at this point. I can only get to half of the internet, which is basically useless (IMHO). -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: Annoying bug in NM1.0.0-8
On 04/19/2015 02:21 PM, Chris Murphy wrote: On Sun, Apr 19, 2015 at 9:20 AM, Dan Mossor danofs...@gmail.com wrote: Greetings, folks. I and at least one other individual have noticed an annoying bug with NetworkManager-1.0.0-8.fc22.x86_64 but we aren't sure of the root cause so we can't legitimately file a BZ on it yet. The issue we're seeing is that with a fully updated Fedora 22 Beta system, once NM is in operation for a bit it starts to loose connectivity. Not total connectivity, but partial. I'm having the same experience, which is sometimes networking works for some thing some of the time sometimes. Google searches work, logging in to sites like outlook.com works, but then hangs when email is to be downloaded or sent. If I reboot the same hardware to OS X the problems don't happen. If I reboot Fedora 22, it might be fixed for a short while, or it might misbehave right away. I can't figure out the pattern. I've rebooted this machine many, many times due to unrelated kded5 crashes, but the problem has not once gone away since it appeared. I've noticed something else,also - I can't get F22 to see my wired interface to compare with wireless to see if I can narrow it down some more. The GUI applet simply won't activate the interface, and nmcli tells me Error: Connection activation failed: Connection 'Home' is not available on the device enp4s0 at this time. So, I seem to have a multitude of issues, the core component of which seems to be NetworkManager. -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Annoying bug in NM1.0.0-8
On 04/19/2015 10:20 AM, Dan Mossor wrote: Greetings, folks. I and at least one other individual have noticed an annoying bug with NetworkManager-1.0.0-8.fc22.x86_64 but we aren't sure of the root cause so we can't legitimately file a BZ on it yet. The issue we're seeing is that with a fully updated Fedora 22 Beta system, once NM is in operation for a bit it starts to loose connectivity. Not total connectivity, but partial. For example, I can run a search on Google for anything and get back the usual tens or hundreds of results. but on a single page of results I can only successfully open 2 or 3 of them. Specifically, a few sites I'm noticing I can no longer reach: https://www.happyassassin.net/ http://docs.kde.org http://mirrors.rpmfusion.org http://rsyslog.org However, all Fedora Project, Red Hat CentOS and GNOME links work just fine. Pages from the Stack Exchange family of sites are hit and miss, but mostly miss. Also, it is only http traffic - I can hit these sites with ftp, ssh or rsync where supported. I have tried using Chrome, Firefox, Konquerer, ReKonq, wget and curl and get the same result every time. To aid in troubleshooting, I am providing a link to the pcap [0] of my wget attempt against the RPM Fusion mirror site - it's disappointing, really. The only commonality I've discovered among the affected systems is that they are using Intel wireless adapters. Specifically in my case, a Centrino 2230 and a Centrino 2200. The other user I mentioned earlier indicated that he believed the fault may lie in the routing tables, but I have not confirmed or ruled this out yet - I'm still shooting in the dark. I know it is not network issues at large, as on this network I have other devices - Android, ChromeOS, and Windows 8.1 devices - that all work fine. In fact, on one of my affected systems, it was working just fine on F21 and NM 0.9.10 before I updated it to F22 last night with fedup. This points directly to F22 being at fault, but like I mentioned, I don't know if it is NetworkManager or Intel Wireless drivers. Thoughts? Concerns? Criticisms? Dan [0] http://goo.gl/qG76ey - a shortened link to Google Drive, full link: https://drive.google.com/open?id=0ByM4hcGUETFIS0RBLW8wMU5UOFUauthuser=0 Ok, my wired networking problem has been hashed out - it was a physical layer issue. That led me to discovering that the problem is worse than I feared, it exists on wired networking also, and can't be tied to Intel drivers since both systems I tested this on have either a Qualcomm Atheros or Realtek gigabit ethernet NIC. I have filed a bug. https://bugzilla.redhat.com/show_bug.cgi?id=1213194 -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice FAS: dmossor IRC: danofsatx San Antonio, Texas, USA -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Annoying bug in NM1.0.0-8
Greetings, folks. I and at least one other individual have noticed an annoying bug with NetworkManager-1.0.0-8.fc22.x86_64 but we aren't sure of the root cause so we can't legitimately file a BZ on it yet. The issue we're seeing is that with a fully updated Fedora 22 Beta system, once NM is in operation for a bit it starts to loose connectivity. Not total connectivity, but partial. For example, I can run a search on Google for anything and get back the usual tens or hundreds of results. but on a single page of results I can only successfully open 2 or 3 of them. Specifically, a few sites I'm noticing I can no longer reach: https://www.happyassassin.net/ http://docs.kde.org http://mirrors.rpmfusion.org http://rsyslog.org However, all Fedora Project, Red Hat CentOS and GNOME links work just fine. Pages from the Stack Exchange family of sites are hit and miss, but mostly miss. Also, it is only http traffic - I can hit these sites with ftp, ssh or rsync where supported. I have tried using Chrome, Firefox, Konquerer, ReKonq, wget and curl and get the same result every time. To aid in troubleshooting, I am providing a link to the pcap [0] of my wget attempt against the RPM Fusion mirror site - it's disappointing, really. The only commonality I've discovered among the affected systems is that they are using Intel wireless adapters. Specifically in my case, a Centrino 2230 and a Centrino 2200. The other user I mentioned earlier indicated that he believed the fault may lie in the routing tables, but I have not confirmed or ruled this out yet - I'm still shooting in the dark. I know it is not network issues at large, as on this network I have other devices - Android, ChromeOS, and Windows 8.1 devices - that all work fine. In fact, on one of my affected systems, it was working just fine on F21 and NM 0.9.10 before I updated it to F22 last night with fedup. This points directly to F22 being at fault, but like I mentioned, I don't know if it is NetworkManager or Intel Wireless drivers. Thoughts? Concerns? Criticisms? Dan [0] http://goo.gl/qG76ey - a shortened link to Google Drive, full link: https://drive.google.com/open?id=0ByM4hcGUETFIS0RBLW8wMU5UOFUauthuser=0 -- Dan Mossor, RHCSA Systems Engineer Fedora Server WG | Fedora KDE WG | Fedora QA Team Fedora Infrastructure Apprentice 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: Yum SIGSEGV
On 03/28/2015 12:49 PM, Russel Winder wrote: Hi, I have a workstation and three laptops running Fedora Rawhide. I did my daily update just now (I point to the Kent mirror rather than the Fedora mirrors so as to ensure all machines see the same repository, it updates mid-afternoon +00:00). Workstation and two laptops upgraded fine. One laptop is having troubles with the packages: gdm.x86_641:3.16.0.1-2.fc23 rawhide openmpi.x86_641.8.4-6.20150324gitg9ad2aa8.fc23 rawhide openmpi-devel.x86_64 1.8.4-6.20150324gitg9ad2aa8.fc23 rawhide trying to install them causes yum to fail: … Total size: 9.0 M Is this ok [y/d/N]: y Downloading packages: Running transaction check Running transaction test Segmentation fault (core dumped) though I am, not sure where the core is dumped to, it isn't . It happens if I do gdm individually, the other two enforce each other so come as a pair, and they have the same problem. I have no idea how to work out what is going wrong here so as to fix it, this is clearly a fault on the one laptop. Any help tracking this down would be most welcome… Rawhide should be using DNF exclusively. Please try again using dnf and let us know the results from that. Dan -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Convert nonproduct to productX
On 02/19/2015 07:48 AM, Stephen Gallagher wrote:
On Wed, 2015-02-18 at 20:11 -0700, Chris Murphy wrote:
On Wed, Feb 18, 2015 at 3:53 PM, Stephen Gallagher sgall...@redhat.com wrote:
On Feb 18, 2015, at 5:46 PM, Pete Travis li...@petetravis.com wrote:
Good question, let's kick it up to someone who can answer authoritatively.
Stephen, is this group intended for user consumption? If yes, how; if no,
can you hide it please?
Fedora Server is an environment group. It's used to pick the Fedora Server
product when using the network install.
I'm referring to it being visible with 'yum/dnf group list' – where
there's a huge pile of groups that aren't listed unless 'yum/dnf group
list hidden' is used. So why visible if we'd like to discourage
sidegrades?
Yum/DNF always displays all Environment Groups. There's no hidden
option for them.
Wondering out loud.since the list is starting to grow rather large,
should an RFE be submitted for dnf grouplist {environments,groups} or
something to that effect?
--
Dan Mossor, RHCSA
Systems Engineer at Large
Fedora Plasma Product WG | Fedora QA Team | Fedora Server WG
Fedora Infrastructure Apprentice
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: Convert nonproduct to productX
On 02/18/2015 04:45 PM, Chris Murphy wrote: On Wed, Feb 18, 2015 at 12:33 PM, Adam Williamson adamw...@fedoraproject.org wrote: I'd agree with Pete that this isn't *really* something we intend to 'support'; you're supposed to pick a product by, well, installing that product (and, as a one-time thing, on fedup from 21). You're not really supposed to 'convert' installs like this. OK. From this page: https://fedoraproject.org/wiki/FedUp I can't actually tell what the default behavior is for --product if it's not specified. Does the user get a nonproduct upgrade or do they get workstation? If the former, then it's possible there are people will want a means to get a product specific side grade (same version, different product). IIRC, if you don't supply --product, it returns a Usage error, IOW the --product specifier is required. Otherwise, see if you can glean any pertinent info from the cloud-to-server code[0]. It appears to work splendidly. [0] https://github.com/Rorosha/cloudtoserver/blob/master/cloudtoserver -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: [Test-Announce] Fedora 22 Rawhide 20150203 nightly compose nominated for testing
On 02/03/2015 06:13 PM, Adam Williamson wrote: On Tue, 2015-02-03 at 18:27 -0500, Joerg Lechner wrote: Hi, silly question: I would like to test now F22-Rawhide i.e. LXDE. My system ist a fast laptop with Win 8.1 and Fedora on an external disk. I don't want to test in a sandbox. Is in this stage of development of F22-Rawhide danger that Fedora could damage the windows installation? F22-Rawhide will be on a seperate spare external disk connected via USB to the Windows laptop. Kind Regards Nothing's 100% guaranteed, but if you don't select the internal drive as a target disk during installation, it's very unlikely that installing F22 to the external drive will affect your existing Windows install in any way. However, Fedora has been known to modify UEFI boot settings in such a way that the system will not boot at all without that external drive attached. [1] 1- https://fedoraproject.org/wiki/User:Dmossor/uefi-recovery -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: criterion update: add switch user to Shutdown, reboot, logout
On 01/27/2015 05:34 AM, Kamil Paral wrote: Hello, yesterday we have discussed whether user switching should be included in our criteria. We agreed that Beta is a good target for it, and accepted this bug as a blocker: https://bugzilla.redhat.com/show_bug.cgi?id=1184933 https://bugzilla.gnome.org/show_bug.cgi?id=719418 Now we need to adjust this criterion: https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Shutdown.2C_reboot.2C_logout Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. Work? [hide] Similar to the Alpha criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware. Logging out must return the user to the environment from which they logged in, working as expected. I propose this change: title: Shutdown, reboot, logout, switch Shutting down, rebooting, logging out and user switching must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. Work? [hide] Similar to the Alpha criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware. Logging out must return the user to the environment from which they logged in, working as expected. User switching must allow multiple users to perform live switching between their sessions, working as expected. What do you think? Sounds good to me, so +1 from here. -- Dan Mossor, RHCSA Systems Engineer at Large Fedora Plasma Product WG | Fedora QA Team | Fedora Server WG Fedora Infrastructure Apprentice 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: [Test-Announce] Fedora 21 Final Go/No-Go Meeting, Thursday, December 04 @ 17:00 UTC
On 12/01/2014 11:03 AM, Jaroslav Reznik wrote: Join us on irc.freenode.net in #fedora-meeting-2 for this important meeting, wherein we shall determine the readiness of the Fedora 21. Thursday, December 04, 2014 17:00 UTC (12 AM EST, 9 AM PST, 18:00 CET) Just to pick nits, 12AM EST is 9PM PST. We've already had one confused individual inquiring about the timings. For the record, the meeting is at 1700UTC - 1800CET, 1200EST, 0900PST and so on. -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Proposal to CANCEL: 2014-11-17 Fedora QA Meeting
On 11/17/2014 01:55 AM, Tim Flink wrote: The usual suspects for leading the QA meeting are going to be out at meeting time tomorrow and I'm not up to date enough with the possible topics to put together a good agenda, so I propose that we cancel the QA meeting tomorrow. Of course, if there are topics that need discussion, I'm happy to facilitate or if someone else wants to lead the meeting, that also works. However, if there are no replies to this email saying otherwise, consider the QA meeting canceled. Tim Well, some minor glitches have been discovered with fedup that will need to be addressed for GA, specifically in regards to packages that are newer in F20 than are in the F21 installation repo. With freeze coming tomorrow, I foresee a lot of Freeze Exceptions to resolve this issue for release - unless we're willing to freeze F20, also. Dan -- Dan Mossor, RHCSA Systems Engineer at Large Fedora Plasma Product WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Server issues
On 11/16/2014 12:06 PM, Ralf Corsepius wrote: On 11/17/2014 06:19 PM, Mike Chambers wrote: Have a few issues that are now having, but think they are all related.. Had a desktop (using as mini server) that was running Fedora 20. I used yum to upgrade to latest on F21, both main and testing repos, and upgraded without a hitch (no errors that I saw). Now, I can't mount my nfs partitions, email client can't connect, no ftp, no http. I can connect to the server via ssh but that's it. I can ping out to the internet from the server with no issues. I am struggling with similar issues - manually nfs mounting works, but autofs mounting nfs doesn't ;) Sooo, is that kernel causing a problem, Unlikely. or some other service that might be related that didn't start on boot? systemd, rsp. services ;) One issue I had, was nfs-server.service not being started. Seems as if it was renamed from nfs.service in f20 to nfs-server.service in f21, but this renamer not having been taken into account on updates. Some port issue or something related that has to do with all of the issues? Possible. Check your firewalld setting and the nfs-related settings in your SELinux-setup. Both seem to require manual tweaks to get them working. Ralf Ralf is close - if you watched closley, an .rpmnew file was droped for nfs stated. Some changes were made to the nfs service for F21, so I would recommend double checking all of your config files against the new man pages. Also, firewalld for F21 includes new zones - FedoraWorkstation (for the workstation product) and FedoraServer (for the server product). These zones become the default for NetworkManager, and start off with only a few services enabled. Server, for instance, defaults to only ssh and cockpit being open - you have to tweak everything else. Workstation has a few more services allowed, but NFS is not one of those. Dan -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Security Lab - Dependencies
On 11/04/2014 09:24 PM, Ed Greshko wrote: Using the latest, and greatest, Beta. In doing a KDE install from the net-install I added Security Lab as one of the Software Selections. It fails with dependencies problems. Known issue? I realize this is way late, but Security Lab runs on the XFCE DE. It will pull XFCE and all of it's deps in with it. -- Dan Mossor Systems Engineer at Large Fedora KDE WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Interesting debugging experiences Fedora 21 on real hardware
On 07/24/2014 05:59 PM, Mike Chambers wrote: On Wed, 2014-07-23 at 22:56 -0700, Chuck Forsberg WA7KGX wrote: Since my ultimate goal is to get a (relatively) clean F21 on my server, I started experimenting using the Heisenbug netinst.iso with a specified repository of http://mirrors.kernel.org/fedora/development/21/x86_64/os It would be most useful to be able to specify a copy of the repository on a local HD: /dev/sdd1/fc21/os- but in the meantime I will have to install over the net at a more leisurely pace. Do you not already mirror anything in Fedora at all locally? If not, you may think about setting up rsync or something to do that onto a local server/HD of some time, one that you can always have access to, via http, ftp, nfs, etc.. You can then set it up to check however many times a day/week/month you want so it's always up to do. It does make installs/upgrades/etc..a lot faster and you don't need internet access while doing it. This is what I do. The full tree for 19, 20, 21, and rawhide plus updates-testing is only using approx. 250GB. I don't grab the source or delta rpms, and I've excluded many of the games. Makes netinstalls a breeze. -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice 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: QA Testing Results
On 08/09/2014 10:58 AM, Adam Williamson wrote: I'll add Server and Desktop pages if I have the time. According to dgilmore, there are no nightly Server builds. Unless you want to track a Server load from the nightly boot.iso, this would be a waste of your time. -- Dan Mossor Systems Engineer at Large Fedora Plasma Pruduct WG | Fedora QA Team | Fedora Server SIG Fedora Infrastructure Apprentice 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: Self-Introduction: John Osborne
On 08/08/2014 10:23 PM, John Osborne wrote: Hi Everyone, I'm a 45-year old wannabe programmer. I just completed my B.S.C.S. from an online university, and while I think I understand (mostly) the theory of programming, I don't have much of a feel for the actual practice. My background is in electronics - I spent 20 years in the US Navy, and am now a field-service engineer with a small microwave communications company. I'm looking to get my feet wet with just about anything. Having finished with school (at least for now), I find myself with lots of free time that I'd prefer not to use sitting in front of the TV. Best, John (aka TheGeekWhoLived) Ahoy, Shipmate! Glad to have you onboard. To be fair, not all of QA requires programming knowledge. It helps when tracking down solutions, but it doesn't take much more than determination to find the bugs ;) I spent 10 years in the Navy as a DS, then they made me an ET and I got injured, so I left to double my salary as a contractor. Now I run networks, and test for Fedora. -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice 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: Consistent names changed yet again?
On 08/06/2014 03:23 PM, Felix Miata wrote: On 2014-08-06 11:43 (GMT-0500) Kevin Martin composed: Hmm, I have biosdevname installed (and always have) and have never put net.ifnames=0 anywhere that I'm aware of. I've included net.ifnames=0 on installer cmdline for every distro I've installed for over a year. NAICT, Anaconda ignores it. I don't remember exactly how on Fedora I get eth0, possibly as a result of editing and renaming /etc/sysconfig/network-scripts/ifcfg- to ifcfg-eth0, but from earlier installations carried forward into my Rawhides I do have the following also: -rw-rw-r-- 1 root root 0 Oct 4 2013 /etc/udev/rules.d/80-net-name-slot.rules I see on http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ that that name has inexplicably been replaced for systemd v209 up by 80-net-setup-link.rules. For the record, nmcli will do this without breaking a sweat. For example: [root@g55 ~]# nmcli con edit ed0fea4d-ed28-4fdb-9a8c-c131bd78d030 ===| nmcli interactive connection editor |=== Editing existing '802-3-ethernet' connection: 'ed0fea4d-ed28-4fdb-9a8c-c131bd78d030' Type 'help' or '?' for available commands. Type 'describe [setting.prop]' for detailed property description. You may edit the following settings: connection, 802-3-ethernet (ethernet), 802-1x, ipv4, ipv6 nmcli print connection ['connection' setting values] connection.id: p3p1 connection.uuid: ed0fea4d-ed28-4fdb-9a8c-c131bd78d030 connection.interface-name: -- connection.type:802-3-ethernet connection.autoconnect: no connection.timestamp: 1407336689 connection.read-only: no connection.permissions: connection.zone:home connection.master: -- connection.slave-type: -- connection.secondaries: connection.gateway-ping-timeout:0 nmcli set connection.id eth0 nmcli set connection.interface-name eth0 nmcli save Connection 'eth0' (ed0fea4d-ed28-4fdb-9a8c-c131bd78d030) sucessfully saved. nmcli quit [root@g55 ~]# reboot when that is done, it will now be eth0 forever and ever, amen. A word of caution, however - do not do this if you have already set up other connections that depend on it, because they will still be looking for the former devname - which brings up a feature request. Maybe NetworkManager should have bridge, bond, and VPN connection masters and/or slaves either use the UUID for the identifier, or update the link in the underlying DB when IDs are changed. -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice 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: Blocker bug process proposal: make FESCo blockers automatic
On 07/10/2014 03:54 PM, Adam Williamson wrote:
Hi folks! So, we have this Alpha release criterion:
https://fedoraproject.org/wiki/Fedora_21_Alpha_Release_Criteria#FESCo_blocker_bugs
it was added back in 2013 -
https://lists.fedoraproject.org/pipermail/test/2013-June/116531.html -
to provide a documented process by which FESCo could designate bugs as
blocking the release. Practically, FESCo has always been able to do
this, but we didn't used to have a way of keeping track of it.
It occurs to me that there's really no reason for FESCo-designated
blockers to go through the review process: there's really nothing to be
discussed, if FESCo says we designate this bug as a blocker, then it's
a blocker. We don't need to propose and review it. So I suggest we
should amend the Automatic Blockers policy:
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Automatic_blockers
with this additional bullet:
* Bugs designated as release blockers by FESCo (see [[{{FedoraVersion|
long|next}}_Alpha_Release_Criteria#FESCo_blocker_bugs]])
does this make sense to you all? Thanks!
Makes sense. Make it so.
--
Dan Mossor, RHCSA
Systems Engineer at Large
Fedora QA Team | Fedora KDE SIG | Fedora Server SIG
Fedora Infrastructure Apprentice
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: was there some weird issue with the second last rawhide kernel? [DIAGNOSED?]
On 06/20/2014 11:34 AM, poma wrote: On 20.06.2014 18:27, poma wrote: On Thu, 2014-06-19 at 06:46 -0400, Robert P. J. Day wrote: and as long as i disconnect HDMI first, my asus G74S laptop boots just fine, and i can plug in the monitor afterwards and all is well. rday dmesg? GTX 560M GDDR5? IGP Intel HD Graphics 3000 To which is connected HDMI? poma On the Asus G Series laptops, the Intel graphics are disabled. It uses the discrete Nvidia GPU exclusively. -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice 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: was there some weird issue with the second last rawhide kernel? [DIAGNOSED?]
On 06/20/2014 01:32 PM, Robert P. J. Day wrote: just finished another yum update to get the 3.16.0-0.rc1.git3.1.fc21.x86_64 kernel, which is still showing the exact same symptoms -- if i boot my ASUS G74S with HDMI connected to my external ASUS VE228H monitor, after i get the fedora infinity symbol for a couple seconds, total hang ... black displays, no virtual consoles, need to power cycle. if, however, i simply unplug the external monitor from HDMI, no problem, and i can plug in the monitor after booting. oh, and as before, once i'm running under this new (but clearly broken) kernel, when i go to shut down, massive kernel panic and stack trace. i can do more testing tomorrow, but this has now been an issue for the last three rawhide kernel releases. is no one else seeing something like this? more later ... rday I suspect it's a regression in Nouveau. See this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1044304 -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice 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: was there some weird issue with the second last rawhide kernel? [DIAGNOSED?]
On 06/20/2014 02:12 PM, poma wrote: nouveau_drv.so is X.Org X11 video module nouveau.ko is kernel module Why did you choose Component: xorg-x11-drv-nouveau(nouveau_drv.so) and not Component: kernel(nouveau.ko)? poma Because that's what the devs in #nouveau told me to file it against. -- Dan Mossor Systems Engineer at Large Fedora QA Team | Fedora KDE SIG | Fedora Server SIG Fedora Infrastructure Apprentice 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: Releng dashboard updates
On 04/08/2014 08:51 AM, Ralph Bean wrote: In yesterday's meeting[1], the release engineering dashboard[2] was discussed. I fixed the issues that were raised and put out a new release: - There is now a loading indicator to show that data is being gathered. - The Live CD and Appliance entries now have links to directly download the image (.iso, .raw.xz, and .qcow2). - The section headers now have inline anchor tags so you can link someone directly to the LiveCD section, for instance. Please do file issues on github if other things need work[3]. Cheers- -Ralph [1] - http://meetbot.fedoraproject.org/fedora-meeting/2014-04-07/fedora-qa.2014-04-07-15.00.html [2] - https://apps.fedoraproject.org/releng-dash/ [3] - https://github.com/fedora-infra/fedora-releng-dash/issues Thanks Ralph - it looks a *LOT* better now. Much easier to find the Rawhide ISOs. Regards, Dan -- Dan Mossor Systems Engineer at Large Fedora QA Team Volunteer Fedora Infrastructure Apprentice 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: Introduction
On 04/01/2014 12:04 AM, Amita Sharma wrote: Hi, I am Amita, 29 years old female from Pune,India. I am contributing in 389 Directory Services as a SQA in RH for 3 years now. So I know Linux, 389, 389 DS-Admin Console, LDAP, Windows AD-DS sync, bugzilla, beaker, shell scripting and learning python. Thanks and Regards, Amita Sharma SQA, Red Hat Amita - Welcome aboard! We're thrilled to have you; at least I am. I'd love to pick your brain on the 389, LDAP and AD-DS stuff. One way I think you could contribute to the testing arena for those is to come up with some testing plans to help us understand normal use cases for those particular applications and how to configure them for testing. More info can be found at: https://fedoraproject.org/wiki/QA/Join#create-testcases Regards, Dan -- 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: Adventures with Rawhide
On 02/20/2014 07:42 PM, Chuck Forsberg WA7KGX wrote: A few days ago I installed Rawhide from my local rsync. The Asmedia USB ports now work. The Display would not go above 1600 with the Nvidia gtx670 and Dell 30 incher. The rpmfusion xorg-x11-drv-nvidia did install and all was well. ... until the kernel was updated and now no X. So I re-installed rawhide and now the rpmfusion driver won't work. I really do miss running my 30 inch at full res. Are you getting the dreaded Unknown opcode error? https://bugzilla.redhat.com/show_bug.cgi?id=1044304 Blocker bug for F21. -- 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: rfc: expectations for partitioning, Fedora.next
On 02/19/2014 10:59 PM, Chris Murphy wrote: On Feb 19, 2014, at 6:07 PM, Adam Williamson awill...@redhat.com wrote: On Wed, 2014-02-19 at 16:55 -0700, Chris Murphy wrote: If the bar is going to be raised, Just as a sidebar, I'm not sure you're entirely on track with this assessment - I haven't quite read the same 'undertone' into the .next discussions. I don't have a way to qualify the magnitude of the raising. So whether it's static or is raised, and if raised then by how much, is something sufficiently open ended right now that it needs to be made more clear. Or I need remedial attention. then my instinct is to be even more aggressive with how the installer should only present recommended or at least sane outcomes to users. It probably shouldn't ever crash. snip for clarity We probably should have *one* file system option for Guided partitioning, which is the recommended layout, and the user gets to choose a couple of variations: encryption, and a way to reuse an existing /home. Based on the last discussion on anaconda-devel, I'm not sure we can get down to one, but I think there is some leeway for cutting it down from four. This definitely needs to be proposed to the anaconda devs, though. I would be in favor of at least cutting it down from the current set. I think there's inherent value in the project saying this is the layout we recommend wen it comes to the guided path. It's not much of a guide to have four massively different partition schemes: one of which was a surprising new comer that didn't work at all up until beta and then imploded at the last second before ship. One of which at the time was still labeled experimental in the kernel, but that status wasn't revealed to the user, they had to go read tea leaves or visit the water cooler in the 5th floor stair well to know that. So I'd push for one and maybe we get two. *shrug* I'm well aware that suggesting greater conservatism on the guided path very well might mean Btrfs gets booted, even though I'd pick it as easier to learn and manage than LVM. So really, I'm fairly convinced at this point that what's needed is feature chop, it's just a matter of how much which depends on what quality level expectations the WGs decide upon. What's your plan for moving forward with this? No plan. But I question whether WG members really understand the state of the installer: how many outcomes it enables; how many QA resources go into testing it as a percentage of all testing; and yet despite that, as a percentage of outcomes, how QA likely isn't testing even a majority of Manual partitioning outcomes; and the perception of Fedora users expecting that these outcomes have at least been attempted by QA. I think there's a disconnect. And I'm happy to be totally wrong about that, but when I look at other installers, I can't help but think they're successful not because of what they can do, but what they refuse to do. And yeah, we aren't going to ever have an installer that only produces 5 or 6 outcomes, it'll probably always be several dozen at a minimum. But several dozen right now would be an f'n godsend compared to what we've got. So I think the factual information of the installer state of affair, user perception and WG expectations for the installer need better qualification. Chris Murphy I've been pondering this, and I have an idea that I borrowed from the enemy (M$). When you install anything in Windows land - including the OS, IIRC - you are given a choice: default install, or custom. Why can't we set anaconda up this way, say, at the initial boot where you're given the choice to check the media or install. Set one more option there, let the options be: Install Fedora to this system (default, guided installation) Install Fedora to this system (custom, manual selection *WARNING - AT YOUR OWN RISK*) Check this media and install Fedora to this system (default, guided installation). Then in the easy path, the user is given two choices - standard partitions or LVM (or btrfs if Chris gets his way). We test these as the #1 critical must work selections. Anything in the manual path is either in between or bonus. Dan -- 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: [Fwd: Summary/Minutes from today's FESCo Meeting (2014-02-19)]
On 02/19/2014 02:03 PM, Adam Williamson wrote: There's some significant stuff in this week's FESCo minutes, so I thought it wouldn't hurt to forward it to make people aware. Among the key bits: AGREED: Open up F21 for ordinary Change proposals _now_, and continue the conversation about adapting the process for .next in the mean time. wait - am I reading too much into this by interpreting that statement as there may be an F21 before Fedora.next? -- 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: Adventures with Rawhide
On 02/21/2014 10:19 AM, Dan Mossor wrote: On 02/20/2014 07:42 PM, Chuck Forsberg WA7KGX wrote: A few days ago I installed Rawhide from my local rsync. The Asmedia USB ports now work. The Display would not go above 1600 with the Nvidia gtx670 and Dell 30 incher. The rpmfusion xorg-x11-drv-nvidia did install and all was well. ... until the kernel was updated and now no X. So I re-installed rawhide and now the rpmfusion driver won't work. I really do miss running my 30 inch at full res. Are you getting the dreaded Unknown opcode error? https://bugzilla.redhat.com/show_bug.cgi?id=1044304 Blocker bug for F21. My previous email was in haste...I meant to also point out that NVIDIA drivers contain a bug that disables them in x.org 13+ - I forget what the precise issue was, but what it boiled down to for me was that I could not run rawhide (with a 3.13+ kernel) on my laptop with an NVIDIA GeForceGTX660m GPU. With the 3.12 kernel tree, it was working, but what was the point of running rawhide if I was stuck with kernel 3.12? What it boils down to is that neither nouveau or NVIDIA support rawhide with GTX GPUs - yet. -- 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: Vmware Workstation 10.0.1 will not compile with kernel 3.13.2-200.fc
On 02/17/2014 10:32 PM, Jonathan Calloway wrote: Dan, You may want to dump that into a shell script, as all kernel updates moving forward will “break” VMWare workstation again. JC On Feb 17, 2014, at 8:41 PM, Dan Mossor dan.mos...@outlook.com wrote: On 02/14/2014 07:56 PM, Jonathan Calloway wrote: Lawrence, You know, now that I think about it, I used to run VMWare Player in Fedora. I always had trouble getting it to compile. I found a thread somewhere that provided a way of modifying a config file so that it thought the version of Fedora it was running on was an older version, or something along those lines. I got it to work for a little while, but updating always seemed to break it. It has to do with the the kernel updates, which tend to cause VMWare Player and Workstation not to be able to compile on launch. Honestly (and this is probably not the place to say this!) I would suggest not running VMWare Workstaiton inside Fedora. Peronally, I’m running Fedora VM’s in ESXi. It’s free, but a separate piece of hardware will require an investment. Hope this helps! JC On Feb 14, 2014, at 8:38 PM, Lawrence E Graves lgrave...@gmail.com wrote: 2014-02-14T18:30:08.415-07:00| vthread-3| I120: Invoking modinfo on vmnet. 2014-02-14T18:30:08.420-07:00| vthread-3| I120: /sbin/modinfo exited with status 256. 2014-02-14T18:30:08.573-07:00| vthread-3| I120: Setting destination path for vmnet to /lib/modules/3.13.2-200.fc20.x86_64/misc/vmnet.ko. 2014-02-14T18:30:08.573-07:00| vthread-3| I120: Extracting the vmnet source from /usr/lib/vmware/modules/source/vmnet.tar. 2014-02-14T18:30:08.603-07:00| vthread-3| I120: Successfully extracted the vmnet source. 2014-02-14T18:30:08.603-07:00| vthread-3| I120: Building module with command /usr/bin/make -j2 -C /tmp/modconfig-hjL5Vs/vmnet-only auto-build HEADER_DIR=/lib/modules/3.13.2-200.fc20.x86_64/build/include CC=/usr/lib64/ccache/gcc IS_GCC_3=no 2014-02-14T18:30:14.215-07:00| vthread-3| W110: Failed to build vmnet. Failed to execute the build command. -- All things are workable but don't all things work. Prov. 3:5 6 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test I snipped the original message to only include the pertinent bits ;) I ran into this issue this evening, and it took me a while to get it sorted out. It turns out the problem isn't with Kernel 3.13 per se, but with the netfilter hooks compiled into it. My first forays out into the world wild web this afternoon to solve it were less than productive. but I finally found the complete, full answer over on the Arch Wiki, https://wiki.archlinux.org/index.php/VMware That page goes into much more detail than what we need, so here's the cut and paste of the important part: sudo su - curl http://pastie.org/pastes/8672356/download -o /tmp/vmware-netfilter.patch cd /usr/lib/vmware/modules/source tar -xvf vmnet.tar patch -p0 -i /tmp/vmware-netfilter.patch tar -cf vmnet.tar vmnet-only rm -r vmnet-only vmware-modconfig --console --install-all That little snippit above will solve the VMware module compilation errors on F20 with a 3.13 kernel. -- 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 This shouldn't break with future kernel updates - like I said, the problem wasn't with the kernel itself, it was with the fact the netfilter was compiled into the kernel. The change I noted above updates the vmnet compiler to take that into account. At least VMware works with netfilter - I was just reading on the xenproject website, and they say that netfilter has to be disabled for xen. However, everything would be much simpler if virt-manager wouldn't wig out on us when trying to create a bridge with it... -- 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: Vmware Workstation 10.0.1 will not compile with kernel 3.13.2-200.fc
On 02/14/2014 07:56 PM, Jonathan Calloway wrote: Lawrence, You know, now that I think about it, I used to run VMWare Player in Fedora. I always had trouble getting it to compile. I found a thread somewhere that provided a way of modifying a config file so that it thought the version of Fedora it was running on was an older version, or something along those lines. I got it to work for a little while, but updating always seemed to break it. It has to do with the the kernel updates, which tend to cause VMWare Player and Workstation not to be able to compile on launch. Honestly (and this is probably not the place to say this!) I would suggest not running VMWare Workstaiton inside Fedora. Peronally, I’m running Fedora VM’s in ESXi. It’s free, but a separate piece of hardware will require an investment. Hope this helps! JC On Feb 14, 2014, at 8:38 PM, Lawrence E Graves lgrave...@gmail.com wrote: 2014-02-14T18:30:08.415-07:00| vthread-3| I120: Invoking modinfo on vmnet. 2014-02-14T18:30:08.420-07:00| vthread-3| I120: /sbin/modinfo exited with status 256. 2014-02-14T18:30:08.573-07:00| vthread-3| I120: Setting destination path for vmnet to /lib/modules/3.13.2-200.fc20.x86_64/misc/vmnet.ko. 2014-02-14T18:30:08.573-07:00| vthread-3| I120: Extracting the vmnet source from /usr/lib/vmware/modules/source/vmnet.tar. 2014-02-14T18:30:08.603-07:00| vthread-3| I120: Successfully extracted the vmnet source. 2014-02-14T18:30:08.603-07:00| vthread-3| I120: Building module with command /usr/bin/make -j2 -C /tmp/modconfig-hjL5Vs/vmnet-only auto-build HEADER_DIR=/lib/modules/3.13.2-200.fc20.x86_64/build/include CC=/usr/lib64/ccache/gcc IS_GCC_3=no 2014-02-14T18:30:14.215-07:00| vthread-3| W110: Failed to build vmnet. Failed to execute the build command. -- All things are workable but don't all things work. Prov. 3:5 6 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test I snipped the original message to only include the pertinent bits ;) I ran into this issue this evening, and it took me a while to get it sorted out. It turns out the problem isn't with Kernel 3.13 per se, but with the netfilter hooks compiled into it. My first forays out into the world wild web this afternoon to solve it were less than productive. but I finally found the complete, full answer over on the Arch Wiki, https://wiki.archlinux.org/index.php/VMware That page goes into much more detail than what we need, so here's the cut and paste of the important part: sudo su - curl http://pastie.org/pastes/8672356/download -o /tmp/vmware-netfilter.patch cd /usr/lib/vmware/modules/source tar -xvf vmnet.tar patch -p0 -i /tmp/vmware-netfilter.patch tar -cf vmnet.tar vmnet-only rm -r vmnet-only vmware-modconfig --console --install-all That little snippit above will solve the VMware module compilation errors on F20 with a 3.13 kernel. -- 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: Introduction
On 02/13/2014 04:23 PM, Jonathan Calloway wrote: I am new to testing and QA, but not new to Linux. I first began to work on UNIX/Linux in 2002, when I did some web server administration on a Solaris system. I have used UNIX/LInux in several capacities ever since, including system administration. I taught Fedora and CentOS on the vocational/college level for 5 years. Now I am ready to contribute to an open source project. So, let me introduce myself. My name is Jonathan Calloway. I am 37 years old, and live near Chattanooga, Tennessee. I have a wide range of experiences, including first and second level end user support so graphic and web design to system administration, technical writing, and process improvement. Thanks! Jonathan Calloway calloway jonathancallo...@gmail.com Welcome to the club, Jonathon! I haven't been very active lately, but we are a (mostly) pleasant bunch that doesn't bite (too much). Happy to have you on board and ready to squish bugs. Dan -- 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: Did anyone's F20 system randomly reboot after updating from updates-testing just recently?
On 01/16/2014 01:10 AM, Ankur Sinha wrote:
There's something off somewhere. I just fresh installed from the Alpha USB
stick I had. I ran a dnf update which went OK, other than the usbmuxd
scriptlet failure which iirc is a known issue. After that, I got down to
installing my other packages and I get quite a few scriptlet failures now:
1 warning: %post(perl-libs-4:5.18.2-289.fc20.x86_64) scriptlet failed,
exit status 127
Snipped
I ran into this problem yesterday myself on a fresh install. It first
cropped up during the update to KDE 4.12, and I asked Rex Dieter in the
KDE channel about it. I managed to copy the output from the sddm
install, and this is our brief convo about it. He seems to think it is a
systemd problem:
[12:05] danofsatx Non-fatal POSTIN scriptlet failure in rpm package
sddm-0.2.0-16.20130914git50ca5b20,fc29,x86_64
[12:05] * rdieter checks sddm packaging
[12:06] danofsatx warning:
%post(sddm-0.2.0-16.20130914git50ca5b20,fc29.x86_64) scriptlet failed,
exit status 127
[12:06] rdieter odd, looks like systemd's fault
[12:06] rdieter it just has: %systemd_post sddm.service
[12:07] rdieter hrm, maybe missing runtime dep
[12:07] rdieter nope, %{?systemd_requires}
[12:08] rdieter wierd
I did a final update last night to bring everything up to speed with the
updates-testing repo enabled, and got this output - it's too much to
paste in the email so it's on paste.fedora:
http://paste.fedoraproject.org/68957/89881516/
Summarization: I'm getting A LOT of scriptlet failures with exit status
127. Any clues what that exit status means, and what's broken?
--
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: Did anyone's F20 system randomly reboot after updating from updates-testing just recently?
On 01/16/2014 08:49 AM, Chris Murphy wrote:
On Jan 16, 2014, at 7:44 AM, Chris Murphy li...@colorremedies.com wrote:
On Jan 16, 2014, at 7:14 AM, Dan Mossor dan.mos...@outlook.com wrote:
On 01/16/2014 01:10 AM, Ankur Sinha wrote:
There's something off somewhere. I just fresh installed from the Alpha USB
stick I had. I ran a dnf update which went OK, other than the usbmuxd
scriptlet failure which iirc is a known issue. After that, I got down to
installing my other packages and I get quite a few scriptlet failures now:
1 warning: %post(perl-libs-4:5.18.2-289.fc20.x86_64) scriptlet failed,
exit status 127
Snipped
I ran into this problem yesterday myself on a fresh install. It first cropped
up during the update to KDE 4.12, and I asked Rex Dieter in the KDE channel
about it. I managed to copy the output from the sddm install, and this is our
brief convo about it. He seems to think it is a systemd problem:
[12:05] danofsatx Non-fatal POSTIN scriptlet failure in rpm package
sddm-0.2.0-16.20130914git50ca5b20,fc29,x86_64
[12:05] * rdieter checks sddm packaging
[12:06] danofsatx warning:
%post(sddm-0.2.0-16.20130914git50ca5b20,fc29.x86_64) scriptlet failed, exit status 127
[12:06] rdieter odd, looks like systemd's fault
[12:06] rdieter it just has: %systemd_post sddm.service
[12:07] rdieter hrm, maybe missing runtime dep
[12:07] rdieter nope, %{?systemd_requires}
[12:08] rdieter wierd
I did a final update last night to bring everything up to speed with the
updates-testing repo enabled, and got this output - it's too much to paste in
the email so it's on paste.fedora:
http://paste.fedoraproject.org/68957/89881516/
Summarization: I'm getting A LOT of scriptlet failures with exit status 127.
Any clues what that exit status means, and what's broken?
Me too. It can't be systemd-208-11 because I don't have that installed, I still
have the original one F20 installs with which is 208-9. I haven't tracked down
what's causing this but it must be something in u-t.
Who having this problem has *NOT* been using dnf?
Chris Murphy
I forgot to mention that - I haven't typed the letters dnf at all on
this system until I wrote this email.
Yum is what I know, yum is what I use.
Also forgot to mention that I have systemd-208-9.fc20.x86_64
--
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: Scriptlet errors (Was: Did anyone's F20 system randomly reboot after updating from updates-testing just recently?)
On 01/16/2014 10:11 AM, Ankur Sinha wrote: On Fri, 2014-01-17 at 03:03 +1100, Ankur Sinha wrote: It definitely isn't dnf mucking up. This is the second time I've fresh installed today, and I haven't used dnf at all. I installed my apps, updated, and I got a bunch of scriptlet failures: More: sudo yum -d 10 install mpd --rpmverbosity=debug -e 1 ... ... ... 35 D: == +++ jack-audio-connection-kit-1.9.9.5-3.fc20 x86_64-linux 0x2 36 D: Expected size: 543348 = lead(96)+sigs(1284)+pad(4)+data(541964) 37 D: Actual size: 543348 38 D: jack-audio-connection-kit-1.9.9.5-3.fc20.x86_64: Header V3 RSA/SHA256 Signature, key ID 246110c1: OK 39 D: install: jack-audio-connection-kit-1.9.9.5-3.fc20 has 31 files 40 D: %pre(jack-audio-connection-kit-1.9.9.5-3.fc20.x86_64): scriptlet start 41 D: %pre(jack-audio-connection-kit-1.9.9.5-3.fc20.x86_64): execv(/bin/sh) pid 13704 42 D: %pre(jack-audio-connection-kit-1.9.9.5-3.fc20.x86_64): waitpid(13704) rc 13704 status 7f00 43 error: %pre(jack-audio-connection-kit-1.9.9.5-3.fc20.x86_64) scriptlet failed, exit status 127 44 error: jack-audio-connection-kit-1.9.9.5-3.fc20.x86_64: install failed 45 D: == +++ mpd-1:0.18-0.1.git0e0be02.fc20 x86_64-linux 0x2 46 D: Expected size: 272248 = lead(96)+sigs(1284)+pad(4)+data(270864) 47 D: Actual size: 272248 48 D: mpd-1:0.18-0.1.git0e0be02.fc20.x86_64: Header V3 RSA/SHA256 Signature, key ID ae688223: OK 49 D: install: mpd-1:0.18-0.1.git0e0be02.fc20 has 20 files 50 D: %pre(mpd-1:0.18-0.1.git0e0be02.fc20.x86_64): scriptlet start 51 D: %pre(mpd-1:0.18-0.1.git0e0be02.fc20.x86_64): execv(/bin/sh) pid 13705 52 D: %pre(mpd-1:0.18-0.1.git0e0be02.fc20.x86_64): waitpid(13705) rc 13705 status 7f00 53 error: %pre(mpd-1:0.18-0.1.git0e0be02.fc20.x86_64) scriptlet failed, exit status 127 history info [asinha@eng051125 ~]$ I've switched on whatever flags I could find in yum. More hints? Odd that you're getting it on %pre and I'm getting it on %post - according to my tests, I'm hitting on on ldconfig, but you hit it on /bin/sh - the only common thing is the execv and waitpid portions of the scriptlet. Something isn't passing a value back into the scriptlet. I installed a local RPM using rpm -Uvvh - this is the pertinent output of that: D: %post(kde-connect-0.4.2-1.fc20.x86_64): scriptlet start D: %post(kde-connect-0.4.2-1.fc20.x86_64): execv(/sbin/ldconfig) pid 4414 D: %post(kde-connect-0.4.2-1.fc20.x86_64): waitpid(4414) rc 4414 status 7f00 warning: %post(kde-connect-0.4.2-1.fc20.x86_64) scriptlet failed, exit status 127 -- 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: Scriptlet errors (Was: Did anyone's F20 system randomly reboot after updating from updates-testing just recently?)
On 01/16/2014 10:33 AM, Chris Murphy wrote:
On Jan 16, 2014, at 9:03 AM, Ankur Sinha sanjay.an...@gmail.com wrote:
It definitely isn't dnf mucking up. This is the second time I've fresh
installed today, and I haven't used dnf at all. I installed my apps,
updated, and I got a bunch of scriptlet failures:
1. I just did a rollback to a bit over 2 weeks ago and simply did yum update.
Half the proposed updates are from u-t.
2. During updating, there are two dozen items:
warning: group root- does not exist - using root
Otherwise the update completes without errors.
3. Reboot, download and install kernel 3.13 rc8 (which is what I was originally
having scriplet errors with) and it installs fine.
So I can't reproduce the problem with yum. So I have no idea what's causing
this.
Chris Murphy
Chris, the error was narrowed down to
selinux-policy-targeted-3.12.1-116. See
https://bugzilla.redhat.com/show_bug.cgi?id=1054350
selinux was denying rpm access, but wasn't logging it for some reason. I
saw no output in any of the logs while reproducing the error.
selinux-policy{-targeted}-3.12.1-117 fixes the problem at hand, and can
only be applied with selinux in permissive mode. while in enforcing, the
update fails.
--
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: '10 Years of Fedora' t-shirt
On 01/11/2014 02:53 PM, Richard Vickery wrote: On Sat, Jan 11, 2014 at 12:13 PM, Mailga mai...@fedoraonline.it wrote: Hello guys, Please wait. In the next days we will re-send a mail with link to the module to fill for those didn't fill yet. The ones that are not signed in the wikipage have to talk with Adam because that list is up to him. If Adam will submit other people, the submitted ones will receive a mail asking their postal address. But Adam knows that there are a limit about quantity. Thanks to Adam for the great job he's doing and for the reminder. Greetings. Mailga ___ Gabriele Trombini Fedora Ambassador FedoraOnLine staff member Il giorno 11/gen/2014, alle ore 19:20, Felix Miata mrma...@earthlink.net ha scritto: On 2014-01-11 17:32 (GMT) Frank Murphy composed: On Sat, 11 Jan 2014 09:15:23 -0800 Richard Vickery wrote: Is it possible to get this mail sent out again? I missed it and would like a t-shirt as well. When did the email come out? Perhaps I will merely go to that date and time and reply. Check is your name on the list to begin with: https://fedoraproject.org/wiki/F20_anniversary_tshirt you may not have received an earlier email if not (on it). I don't recall such an email. My name is in the list, but I don't remember ever submitting a snail mail address to the project. Where would that need to be submitted? -- 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/ -- In this case, Adam, can I get on the list except in the case that there are not enough shirts (perhaps I might want to be on the list at any rate). I don't need a shirt, but if there are enough, I would like to have one. Why not sell them to us and recoup the costs? Therefore, you can provide all of us with one. Richard Adam - I'd LOVE to get a Fedora shirt, but I'm not on the list since I just recently joined the QA team at the F20 Alpha stage. If there are enough shirts, I'd take a size large - and if there aren't enough freebies to go around, where can the poor souls such as myself purchase one? -- 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: Hello Everyone,
On 01/06/2014 01:20 PM, Chris A. Roberts wrote: Hi Everyone, I am looking to help out the QA team with testing. Handsome Pirate has helped me learn the testing process with easy karma and has sponsored me in the group. I am looking forward to helping out and getting to know everyone. my irc nick is croberts. As far as programming I have Java experience Chris Roberts Fedora Marketing/Websites/Videos/Infrastructure Team https://fedoraproject.org/wiki/User:Chrisroberts Welcome to the nuthouse, Chris! -- 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: Proposal: let's just use the FAS group already
On 12/20/2013 11:51 AM, Kamil Paral wrote: as discussed, being in the group is not intended to be actually necessary for any QA tasks, we're just going to have it to allow you to get voting rights and fedorapeople space and as a handy-but-probably-incomplete list of people involved with QA. no plans to change any of our current tasks or processes to depend on group membership in any way. oh, and group membership gives you 'editbugs' privs in Bugzilla, so you can do triage. I like the change with qa group in general. I have a few concerns as well: 1. Since we give people editbugs privileges (I assume that means that you can freely edit any item in any bug report), we should only accept people we trust and they should be aware of their powers and what to do (not to do) with them. Since there is no description box for the group in FAS, we should probably create a wiki page where we describe the granted powers and responsibilities and link to that. Also there should be a section with guidelines for sponsors, so that they can easily decide whether to accept an application. 2. Currently the Rules for Application: feels like free voting rights! free online space! free hot dogs!. I think it should clearly explain that we don't grant the membership to everyone, we grant it only to people that we see around often, we know that they do good work, and we know that they won't abuse their new powers. (Hm, I wonder whether we really want to grant editbugs privs to every single person who performed a reasonable amount of testing for Fedora. Should these two things be coupled together? If somebody reported a few bugs, I think it's OK to reward him with voting rights and such, but he should not get editbugs privs, yet.) 3. I have some experience with translator teams in the past. We also used a group for giving people extra powers (revert translations and such). I have a bad experience with free-to-apply groups. I spent a lot of time explaining people that no, you don't need to be in the group just to translate software, this is for additional permissions, and we can add you once you've been around for some time and see that you do good work over and over again. It helped us so much to have a short clear description (explicitly stating that they can do any translator work without being in this group, this is sooo important) and having it invite-only (a lot of people don't read descriptions when they see a big Join button). If someone is eligible to be added, you usually know him, he knows you, and it's easy for him to ping you and ask for a group membership. I advise here to do the same. Regarding concern #2 - How about a system wherein folks are admitted to the QA FAS group pretty much freely, but have to remain an active member of the QA team for a period of time, say 30 days, to be sponsored into the fedorabugs FAS group? The QA group itself does not have the editbugs privilege, whereas the fedorabugs group exists solely to give members of other groups those editbugs privileges. I know this sounds too much like the hierarchy we're trying to avoid, but is anarchy the correct answer? There has to be a happy medium somewhere. -- 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: xserver fails to resume from suspend (f20)
On 12/19/2013 06:09 AM, Neal Becker wrote: 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. When I was on F20, I was experiencing this with nouveau. Switching to the nvidia blob fixed that and many other video related issues (with KDE - gnome is perpetually broken). I was never able to track down a reason for that because I wasn't ready to become a tester yet when this problem first occurred. However, I am now using F21 and nouveau, and the problem is back. And yet, mine is still slightly different from both of the other cases - my system is 90% unresponsive. I say 90% because I can ssh into it, but it takes forever to authenticate and run any commands. The pipe eventually breaks and kicks me out. If I can manage to get in again (which is rare) I can try to reboot it from command line, but more often than not I have to do a hard shutdown since the system is unresponsive, even to the power button being pushed. The screen itself - whether the laptop screen or an external monitor connected via HDMI - never activates. Upon rebooting today, though. ABRT had caught a race condition on CPU2, tied directly to nouveau and drm. I am currently working through those two ABRT bugs and will attach them to bz 1044304 because my gut feeling at this point is that it is tied together through the unknown opcode error, and is a much farther-reaching problem than I first thought. -- 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: 3.12 kernels get stuck midway and do not get to gdm
On 12/20/2013 06:57 PM, Ankur Sinha wrote: Hi, Is anyone else having trouble with 3.12 kernels? Both of them stop at the Fedora bubble for me. They just stop. Here are screens-hots that I took: http://ankursinha.fedorapeople.org/kernel-3.12-failures/2013-12-21% 2011.31.27.jpg http://ankursinha.fedorapeople.org/kernel-3.12-failures/2013-12-21% 2011.32.22.jpg http://ankursinha.fedorapeople.org/kernel-3.12-failures/2013-12-21% 2011.34.07.jpg It only saved journalctl logs for one of these failed boots: http://ankursinha.fedorapeople.org/kernel-3.12-failures/journalctl-previous-boot.log It seems to stop at initrd.service starting up (line 1203). I don't have enough data to decide if it's a kernel issue or something else, but it comes up with both 3.12 kernels. I've filed a bug here[1]. Should I give the 3.12 kernels negative karma for this? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1045662 I am booting fine with 3.12.5-301.fc20.x86_64 and nouveau, but I can't even get to the password for the encrypted disks stage with 3.13.0-0.rc4.git1.1.fc21.x86_64. This issue is apparently fixed in rc5, but that hasn't made it into rawhide yet. -- 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?
On 12/18/2013 01:21 PM, Akshay Vyas wrote: On Thu, Dec 19, 2013 at 12:43 AM, Ralf Corsepius rc040...@freenet.de 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: Sugar tweaked on desktop validation matrix
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_templatediff=365178oldid=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: Proposal: let's just use the FAS group already
On 12/16/2013 03:35 PM, Jóhann B. Guðmundsson wrote: On mán 16.des 2013 21:00, Adam Williamson wrote: Even though we don't really have a lot of use for the FAS group, None what so ever. Fedora as a whole is set up such that 'being a member of a FAS group' is a bar to entry for some things, Not with us and never should be. so it seems like we're putting ourselves at a disadvantage by not putting our members in our FAS group. No we are not and we are putting ourselves in advantage by not doing so. JBG I may be misinterpreting, but what do you have against volunteers? Especially since Fedora is a volunteer-driven project? -- 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: Fedora 21 and 22 trackers created
On 12/13/2013 08:22 PM, Adam Williamson wrote: Hey folks - just a quick note, I've created the F21 and F22 blocker/FE tracker bugs and updated https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers . The F21 tracker bugs have the 'non-versioned' aliases (AlphaBlocker, BetaBlocker etc etc) now, so you can propose F21 blocker/FEs easily. everyone ready to upgrade to Rawhide? :) Yep! That's my Christmas present! The kids are getting tablets, momma's getting tickets to a show, and daddy's getting Rawhide. -- 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: Not able to install F20 over IPv6
Subject: Re: Not able to install F20 over IPv6 From: awill...@redhat.com To: test@lists.fedoraproject.org Date: Mon, 9 Dec 2013 19:34:19 -0800 On Mon, 2013-12-09 at 19:10 +0100, A.J. Werkman wrote: On 12/09/2013 05:36 PM, Kevin Fenzi wrote: On Mon, 09 Dec 2013 09:08:51 +0100 A.J. Werkman aj.werk...@digifarma.nl wrote: Adam, You asked people to test F20 with IPv6. I do agree that works fine. But the problems I see is getting F20 installed IPv6 only. In my experience as soon as you involve IPv4 somehow, things work. My testcase is a IPv6 only network, without IPv4-DHCP. Wether you supply IPv6 address on the boot command line or you supply addresses in the opening network screen after boot, F20 crashes. Even kickstarting with installation from local media makes F20 crash. I agree that it would be good to support this case... but I'm not sure we have any specific 'ipv6 only' test cases/criteria, so it's not been something on the radar much... Perhaps something to propose for next release? kevin +1 for me. I proposed this some time ago. At that point there was not much enthousiasme for it. But if Fedora wants to be, as it always claims, on the cutting edge, you should have IPv6-only in QA. One thing you would immediatly run into is the fact that bugzilla.redhat.com does not resolve to an IPv6 address. So sending crash reports from anaconda isn't possible at the moment from IPv6. Instead of proposing that somebody writes a test case, perhaps write a test case and propose that? It's generally going to get you to your goal faster. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net I'm running into a lot of issues with IPv6 that I've isolated to my F20 installations. All other systems on the network are working fine (Windows, Android, embedded OS). I intend to start running intensive IPv6 tests with a stable system as a control to ensure I know where the problems lie, but I suspect that IPv6 isn't as robust as we would like it to be. I'll start working on the test cases later today. -- 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: [Test-Announce] Fedora 20 Final Test Compose 5 (TC5) Available Now!
Date: Thu, 5 Dec 2013 19:05:13 -0600 From: mike To: test@lists.fedoraproject.org Subject: Re: [Test-Announce] Fedora 20 Final Test Compose 5 (TC5) Available Now! On 12/05/2013 03:30 PM, Andre Robatino wrote: NOTE: The 64-bit Desktop Live is over its size limit. As per the Fedora 20 schedule [1], Fedora 20 Final Test Compose 5 (TC5) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5808#comment:13 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. The installer art contains the Fedora 17 mascot. http://i.imgur.com/vKLioXB.png Otherwise, installation and general usage work without a problem including 3D acceleration in VBox. That's been in there since Alpha. It's a scrolling slide show that has a bunch of different graphics. I don't think it's an issue. Dan Mossor Systems Engineer at large San Antonio, TX -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
RE: Seeking a candidate for the Server Working Group
If I were more well versed in the workings of Fedora SIGs, I'd be willing to contribute as servers are my primary focus, and something I'd love to be using Fedora for instead of CentOS. - Dan Mossor Systems Engineer at large San Antonio, TX Subject: Re: Seeking a candidate for the Server Working Group From: awill...@redhat.com To: test@lists.fedoraproject.org Date: Tue, 26 Nov 2013 21:37:23 -0800 On Tue, 2013-11-26 at 13:24 -0500, Stephen Gallagher wrote: The Server Working Group is a team focused on the development of a server-OS built from the Fedora Project. Recently, the chair held by Jóhann B. Guðmundsson was vacated. At today's Working Group meeting[1], we agreed that we would like to approach Fedora QA first for someone to fill this chair. If you feel that you are able and willing to represent the interests of Fedora QA in the Server Working Group, please respond and we will consider you. Thank you very much in advance. I guess I could step up, though I could really do without three days in a row of early morning meetings... -- 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
Self-introduction: Dan Mossor
Howdy y'all! I am very excited about finally giving back to the Fedora community by joining the Bug Zappers team. I have been using some form of Unix and Linux since my first station in the US Navy where I maintained an HPUX network. I started with RH and Slackware at home back in '96, and moved to Fedora Core 2 in 2004. I've dabbled here and there with my systems at home, but keep coming back to Fedora. At work, I maintain at least one system from each branch (RHEL, Debian, BSD) as well as a Windows Active Directory network. I've never quite gotten Open LDAP to integrate fully with it, but I'm getting there. I live in San Antonio, TX, USA, where I work in the network and information security field. At home, I have a few systems with various OSs, but will be concentrating my testing and QA efforts on making Fedora a formidable mobile operating system with my laptop, an ASUS G55VW. I will be hanging out on Freenode when I can at danofsatx - feel free to find me there or here on the list and let me know what I can do to help! Regards, Dan Mossor -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
