test July 2014

test@lists.fedoraproject.org

67 participants
252 discussions

[Fedora QA] #152: Test Cases Management
by fedora-badges 28 Jan '15

28 Jan '15

#152: Test Cases Management ---------------------------+------------------------------------------------ Reporter: rhe | Owner: rhe Type: enhancement | Status: new Priority: major | Milestone: Fedora 15 Component: Wiki | Version: Keywords: retrospective | ---------------------------+------------------------------------------------ = problem = We've been using mediawiki to manage tests and record results, though it's easy to approach, it has limitations such as managing, tracking and querying cases+results. So is it time for us to consider another solution such as TCMS? = analysis = Here I quoted the suggestion from Victer Chen: some advantages of TCMS: * Better to record, track and query test results, * Allow user focus on test contents instead of document maintenance. * Share test cases However, it couldn't be flexible as wiki. I think the most important things need balance are below: - Barriers Fedora should provide very low barriers. TCMS could be configured to allow anonymous user login and limit it's permission. Also, we can consider using fedora account to login TCMS. - Safety Wiki provides the ability to rollback content easily, while TCMS couldn't. What TCMS can do is recording all the history and allow user recovery it manually. But if we configure the permission well, it should not be a big problem. = enhancement recommendation = Work with TCMS team and package it to Fedora. Set up the system and use it in a small scale first. If it turns out good, enlarger the scale. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/152> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

4 25

[Fedora QA] #81: Add i18n release criteria
by fedora-badges 28 Jan '15

28 Jan '15

#81: Add i18n release criteria ---------------------------+------------------------------------------------ Reporter: jlaska | Owner: Type: enhancement | Status: new Priority: major | Milestone: Fedora 14 Component: Wiki | Version: Keywords: retrospective | ---------------------------+------------------------------------------------ = problem = See [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=571900 RHBZ#571900 - Keyboard mapping not correct (USA instead of Belgium) when first login after install Fedora 13 Alpha] = analysis = * Currently we don't have i18n installation cases, so local language install is not tested as a demand. Untranslated pages are still existing after RC test. Such cases needed be added in test as well as release criteria. * Does the Fedora i18n team have any release criteria to propose? * RHBZ #571900 pointed out the need for a better understanding of how the language and keymap installer selections impact the installed system. = enhancement recommendation = Recommend reviewing the release criteria to ensure expectations are captured around propagating language and keymap settings from install to desktop login (/etc/sysconfig/i18n, image:Package-x-generic-16.pnggdm etc...). It may also be advised to coordinate with the installer team so that bugs can be filed for any missing functionality. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/81> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 8

[Fedora QA] #61: make VirtioSerial Test cases clearer
by fedora-badges 28 Jan '15

28 Jan '15

#61: make VirtioSerial Test cases clearer ----------------------+----------------------------------------------------- Reporter: liam | Owner: Type: defect | Status: new Priority: major | Milestone: Component: Test Day | Version: Keywords: | ----------------------+----------------------------------------------------- we have VirtioSerial Test cases here: https://fedoraproject.org/wiki/Test_Day:2010-04-08_Virtualization_VirtioSer… but during test day, none of these cases was executed. I think testers did not know how to run these cases, so Amit, could you like to rewrite these cases with template and make it clearer? The good cases can help make VirtioSerial better and better,it also can involve more fedora people in virtio.Thanks in advance. These cases that are written with template for your reference: https://fedoraproject.org/wiki/QA:Fedora_13_Install_Results_Template#Test_M… Or if you don't know how to use template, just write the test step more specific and send the cases to me, I will convert them to standard format. -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/61> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 4

[Fedora QA] #46: Write Test cases for LXDE components.
by fedora-badges 27 Jan '15

27 Jan '15

#46: Write Test cases for LXDE components. ----------------------+----------------------------------------------------- Reporter: johannbg | Owner: johannbg Type: task | Status: new Priority: major | Milestone: Component: Test Day | Version: Keywords: | ----------------------+----------------------------------------------------- An ticket to keep track on LXDE components that need test cases and how to debug pages * PCManFM: File manager, provides desktop icons * LXPanel: Feature-rich desktop panel * LXSession: Standard-compliant X11 session manager with shutdown/reboot/suspend support via HAL ( FEI https://fedoraproject.org/wiki/Features/HalRemoval ) * LXSession-edit: GUI to configure what’s automatically started in LXDE * lxde-settings-daemon: XSettings Daemon * LXInput: Keyboard and mouse settings dialog * LXRandR: Configuration tool for monitors and external projectors * LXAppearance: Feature-rich GTK+ theme switcher able to change GTK+ themes, icon themes, and fonts * LXTask: Lightweight task manager derived from xfce4 task manager * LXTerminal: Desktop-independent VTE-based terminal emulator * LXLauncher: Open source replacement for the Asus Launcher on the EeePC * LXShortcut: Small utility to edit application shortcuts, used by lxpanel and lxlauncher * LXNM (still under development): Lightweight network manager for LXDE supporting wireless connections (not yet in Fedora ) * LXRandR (still under development): Monitor configuring tool * Openbox: Lightweight, standard-compliant, and highly-configurable window manager. * GPicView: A very simple, fast, and lightweight image viewer featuring immediate startup * Leafpad: Lightweight and simple text editor * XArchiver: Lightweight, fast, and desktop-independent gtk+-based file archiver * LXDM: Display manager -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/46> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 7

mount -t nfs delayed
by Felix Miata 23 Oct '14

23 Oct '14

For several weeks, maybe several months, most of my Rawhide installations generate an error trying to mount noauto nfs items in fstab: Job for rpc-statd.service failed. See 'systemctl status rpc-statd.service' and 'journalctl -xn' for details. Output from those: [start]rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled) Active: failed (Result: exit-code) since Thu 2014-05-29 00:41:00 EDT; 3min 12s ago Process: 691 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE) May 29 00:40:00 g5eas systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... May 29 00:40:00 g5eas rpc.statd[692]: Version 1.3.0 starting May 29 00:40:00 g5eas rpc.statd[692]: Flags: TI-RPC May 29 00:41:00 g5eas rpc.statd[692]: failed to create RPC listeners, exiting May 29 00:41:00 g5eas systemd[1]: rpc-statd.service: control process exited, code=exited status=1 May 29 00:41:00 g5eas systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. May 29 00:41:00 g5eas systemd[1]: Unit rpc-statd.service entered failed state. -- Logs begin at Sat 2014-03-22 18:49:34 EDT, end at Thu 2014-05-29 00:41:00 EDT. -- May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6 May 29 00:40:00 g5eas systemd[1]: Started RPC bind service. -- Subject: Unit rpcbind.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpcbind.service has finished starting up. -- -- The start-up result is done. May 29 00:40:07 g5eas systemd[1]: Starting Stop Read-Ahead Data Collection... -- Subject: Unit systemd-readahead-done.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-readahead-done.service has begun starting up. May 29 00:40:07 g5eas systemd[1]: Started Stop Read-Ahead Data Collection. -- Subject: Unit systemd-readahead-done.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-readahead-done.service has finished starting up. -- -- The start-up result is done. May 29 00:41:00 g5eas rpc.statd[692]: failed to create RPC listeners, exiting May 29 00:41:00 g5eas systemd[1]: rpc-statd.service: control process exited, code=exited status=1 May 29 00:41:00 g5eas systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. -- Subject: Unit rpc-statd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpc-statd.service has failed. -- -- The result is failed. May 29 00:41:00 g5eas systemd[1]: Unit rpc-statd.service entered failed state. May 29 00:41:00 g5eas rpc.statd[709]: Version 1.3.0 starting May 29 00:41:00 g5eas rpc.statd[709]: Flags: TI-RPC [end] I see no similar problem in Factory or Cauldron using identical fstab entries and mount syntax. What needs to be done to eliminate this delay? -- "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/

3 12

NM controlled bridge turns on netfilter
by Paul Knox-Kennedy 05 Oct '14

05 Oct '14

I have a host recently updated to f20, with virtual machines using bridged networking. When I switch to NetworkManager controlled networking, the virtual machines' DHCP requests failed. After much messing around, I have found that when NM is on, by the time the system has booted, bridge-nf-call-iptables, bridge-nf-call-ip6-tables and bridge-nf-call-arptables have all been set to 1, so something has overriden the setting from /usr/lib/sysctl.d/00-system.conf. Is there some setting I am missing here? Thanks Paul NOTICE & DISCLAIMER This email including attachments (this "Document") is confidential and may contain legally privileged information. If you have received this Document in error please notify the sender immediately and delete this Document from your system without using, copying, disclosing or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of this Document. The information contained in this Document is provided solely for information purposes on an "as is" basis without warranty of any kind, either express or implied, including without limitation any implied warranty of satisfactory or merchantable quality, fitness for a particular purpose or freedom from error or infringement. The user relies on the information contained herein, and its accuracy or otherwise, entirely at their own risk. Any opinions expressed in this Document are those of the author and do not necessarily reflect the opinions of Telsis. We will not accept responsibility for any commitments made by our employees outside the scope of our business.

7 11

Interesting debugging experiences Fedora 21 on real hardware
by Chuck Forsberg WA7KGX 12 Sep '14

12 Sep '14

Recent yum updates to my omen.com server have resulted in an unstable system. At first the problem appeared to be related to the Tigervnc server. VNC sessions would fail quickly. I ended up force installing Tigervnc from the Heisenbug tree. With VNC apparently settled down, I saw hard disk errors on various drives. The solution for that was to fall back to 3.16.0-0.rc4.git2.1.fc21.x86_64. Omen.com now seems stable. Meanwhile Fedora 21 and rawhide installs on my test machines ceased to boot into a graphical desktop. I tried both Gnome and Xfce. I could get a text console but no desktop. The current F21 anaconda didn't get to a desktop screen either. I then replaced the Nvidia FTX 460 on my spare test machine and F21 anaconda started working. 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. -- Chuck Forsberg WA7KGX caf(a)omen.com www.omen.com Developer of Industrial ZMODEM(Tm) for Embedded Applications Omen Technology Inc "The High Reliability Software" 10255 NW Old Cornelius Pass Portland OR 97231 503-614-0430

3 2

Criterion revision proposal: KDE default applications
by Adam Williamson 10 Sep '14

10 Sep '14

It was clear at the Go/No-Go meeting today that KDE SIG does not consider this release criterion applicable/desired: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria#Default_app… jreznik says they consider the live image their 'polished product' where everything must work, while the DVD install is more of a grab-bag - they install a whole bunch of stuff, and don't think it's the end of the world if one or two bits are broken. Given that, I propose re-wording as follows: "All applications that can be launched using the standard graphical mechanism of a release-blocking live image after an installation of that image must start successfully and withstand a basic functionality test." So, that doesn't just apply to KDE. True, but I actually think it's a reasonable revision for GNOME as well. It makes sense to see the live images as defining what our 'polished core desktops' consist of, and the DVD as more of a grab-bag of packages. The lives will (should) always contain the bits the desktop SIGs think are absolutely key pieces of the desktop. And I think we could generally do with a bit of criteria watering-down; we're starting to do a lot of fudges and waives, which indicates the criteria are currently too tight for us to realistically enforce. Things are better when we can stand solidly behind the criteria without fudging stuff. CCing KDE and desktop lists. If folks feel that we should restrict this change to KDE only, please do yell, but I'm kinda liking the simple version. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

18 37

the tragedy of Fedora Live USB conversion and what we can do about it
by Kamil Paral 29 Aug '14

29 Aug '14

It's a well-known fact in our circles that third-party USB conversion tools (like UNetbootin or Universal USB Installer) can't create Fedora Live USB correctly. Unfortunately, it is not well known among our users (I see it very often on test list, IRC, or local fedora.cz website/forums) and even journalists. This is an article that was published yesterday showcasing difficulties of Fedora installation process (translated from Czech by google translate): https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=cs&ie=… The purpose of that article is to highlight the fact that Linux has made a lot of progress in the last years, but the results are still a bit like a Russian roulette. Fedora, in this case, is shown as the negative example. The website itself is not known for high quality articles here in CZ, but they are quite popular and have a large reader base. They are mainly Windows-focused, but with the recent advancement of Linux on all fronts (mainly in gaming), they're clearly willing to provide more Linux coverage - and they picked Fedora as their second option right after Ubuntu, which is great. Provided they're able to install it in the first place... The result of Live USB boot attempt is often this (from the article): http://www.zive.cz/uploadedfiles/38598240.png I wonder, is there something we can do to improve the situation? * We have no control over third-party USB conversion tools. * Even if we file bug reports, they are often ignored (Adam Williamson said he tried to communicate with UNetbootin, unsuccessfully). * Third-party USB installers fail for many distributions, like OpenSUSE <http://en.opensuse.org/SDB:Live_USB_stick> or Arch <https://wiki.archlinux.org/index.php/USB_Flash_Installation_Media#Using_UNe…>. * Still, they are hugely popular, because Ubuntu and its derivatives dominate the market and those tools usually work fine for them. * The users simply don't know that those tools shouldn't be used, and some others should be used instead. I don't known the technical details about USB conversion process, but maybe we could collectively think of some changes that would improve the current state at least a bit? Some ideas: 1. First and foremost, we should obviously consider whether we can make some compose changes that would make the image more compatible with third-party USB installers. That's very technical, but I hope relevant people could provide some comments here. 2. Second, we could make USB conversion instructions more visible on our pages. If you look at http://fedoraproject.org/, there's a big Download Now! button, which gives you the ISO, but you'll never encounter any suggestions what to do with it. That's only available at http://fedoraproject.org/en/get-fedora#desktops in the right column (which is nice and quite visible, I think). Could we provide the same information on the front page? 3. Third, if everything goes wrong and you end up in a dracut shell, could we at least advise our users what went wrong and what to do with it? Because the current output is very scary and very hard to decipher by a general user: http://www.zive.cz/uploadedfiles/38598240.png So what if we detected that we failed to find a partition having "Fedora-Live" in its name (thus most probably an incorrectly created LiveUSB), and in that case printed out something like this? ******************************************************************************* * It seems Fedora Live image could not have been accessed. This often happens * * when Live USB media is incorrectly created by a third-party USB installer. * * Please refer to official documentation on fedoraproject.org for proper * * instructions. * ******************************************************************************* (native speakers will surely make it sound better) This would help our users a lot to understand what's wrong and how to fix it. Also, it would be much easier to google out the problem. If we included the same text on our LiveUSB instructions page <https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB>, it could receive a very good position in online search results. So, what do you think? From my experience, the inability to boot USB is very common and I'd even say it's one of the major problems why new users walk away from Fedora. Because, understand, they don't even know something is wrong on their end. That scary dracut error looks like a problem in Fedora, and therefore often their conclusion is "Fedora is so broken it can't even boot". If we try to mitigate the problem at least with clear explanations, we will not only discourage less users, but also decrease the number of negative reviews by journalists.

5 8

[Fedora QA] #445: Proposed Test Day - Wayland
by fedora-badges 26 Aug '14

26 Aug '14

#445: Proposed Test Day - Wayland ----------------------+------------------------ Reporter: vbenes | Owner: Type: task | Status: new Priority: major | Milestone: Fedora 21 Component: Test Day | Version: Keywords: | Blocked By: Blocking: | ----------------------+------------------------ I would like to schedule a test day for Wayland. Anytime between alpha and beta -- Ticket URL: <https://fedorahosted.org/fedora-qa/ticket/445> Fedora QA <http://fedorahosted.org/fedora-qa> Fedora Quality Assurance

1 5

← Newer
1
2
3
4
5
6
7
8
...
26
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

test July 2014