 |
Other languages Deutsch ; English ; français ; Nederlands ; |
| Synopsis: This page is intended to give some guidance for new members. It can be hard to know where to begin, especially when you have never come across a package before. This is a place where we can share our tips and tricks and make it easier for new members (and old!) to do QA testing for Mageia. If you can improve it then please do so. |
Contents
The wiki
The first place to look is right here on the wiki. You can find links to testing procedures through the QA Team portal. Ideally we should complete these more often, it could be made into a valuable resource. Only a few have been added so far, but if you are reading this and looking for a procedure then please consider adding it there when you find one. Anybody with a Mageia identity can edit the wiki, that means anybody who can log into the forums or bugzilla for example. A Mageia identity can be used to log in to any Mageia website.
Bugzilla - Man pages - Google
A good place to start when looking for a way to test a package is to search bugzilla to see how it was done previously. Not everything will be there of course but there are some packages which receive updates relatively frequently and looking back at previous updates usually gives a good idea how to go about testing this update too.
You can search for closed bugs relating to the package you want to test. It is easiest to do that by clicking the Search link on bugzilla rather than just entering it in the search box. Using the Simple Search just select closed as the status. You can also select Mageia for the Product, to narrow the search.
Also don't forget the man page and google.
$ man <package>
You will sometimes find that where a man page does not exist you can use the command you want to test with --help on the end. For example,
$ man --help
URPM-what?
Urpm tools are very powerful. There are many options available but only a small subset that we need to worry about in QA. You can find a lot of information here about various tools. It is well worth a read. You can also check the man pages for each of them
eg.
$ man urpmi
Useful aliases
Here are some aliases you might find useful when performing QA tasks.
These aliases should be placed inside the file /root/.bashrc
After adding them you will need to log out and back in again.
If you know of any more you think might be useful to others then please do add them!
# QA aliases for enabling, disabling and updating core, nonfree and tainted updates testing medias. alias ecupdt='echo -e "Enabling Core Updates Testing\n" && urpmi.update --no-ignore "Core Updates Testing"' alias dcupdt='echo -e "Disabling Core Updates Testing\n" && urpmi.update --ignore "Core Updates Testing"' alias cupdt='echo -e "Updating Core Updates Testing\n" && urpmi.update "Core Updates Testing"' alias enfupdt='echo -e "Enabling Nonfree Updates Testing\n" && urpmi.update --no-ignore "Nonfree Updates Testing"' alias dnfupdt='echo -e "Disabling Nonfree Updates Testing\n" && urpmi.update --ignore "Nonfree Updates Testing"' alias nfupdt='echo -e "Updating Nonfree Updates Testing\n" && urpmi.update "Nonfree Updates Testing"' alias etupdt='echo -e "Enabling Tainted Updates Testing\n" && urpmi.update --no-ignore "Tainted Updates Testing"' alias dtupdt='echo -e "Disabling Tainted Updates Testing\n" && urpmi.update --ignore "Tainted Updates Testing"' alias tupdt='echo -e "Updating Tainted Updates Testing\n" && urpmi.update "Tainted Updates Testing"'
Urpmq is your friend
$ urpmq -i <package>
Urpmq does not require root privileges. It can be run as a normal user, hence the $ sign, which you will see as your prompt in a console when logged in as a normal user. This is common notation and you will see it throughout the wiki. A command run as root will be preceded by a # sign, which is the root prompt.
This command shows useful information about a package, including a description, source rpm and architecture (i586, x86_64 or noarch) and the Group, which might give you some idea what it is used for.
$ urpmq –whatrequires <package>
Using –whatrequires will give you a list of packages which require the package you search for. This can be useful if there is no obvious way to directly test the package being updated. You can then use a package, which uses that package, to test it. This is often useful when testing lib's.
$ urpmq –whatrequires-recursive <package>
This one returns a list of packages which require the package you searched for and also all the packages which require them too. The list can be quite long! It can prove useful though.
urpmf is your friend too
It is not always clear exactly what commands a package contains. urpmf can be used in two ways. It can list the contents of packages and also find the package a particular file belongs to.
Use urpmf to search for commands installed by a package.
$ urpmf <package> | grep /usr/bin/
This lists all files installed by the package into /usr/bin/ which is where normal user commands go to. You can substitute for /usr/sbin or just bin or sbin. urpmf performs a fuzzy search for packages which means it will show results for anything containing your search term. eg. Searching for wireshark, also returns results for lib64wireshark-devel, wireshark-libvirt, wireshark-tools so take notice when you read the results.
If you need to find the source of a specific file, in this case for the urpmf application-wireshark-doc.png file the next package is wireshark.
$ urpmf /path/to/file
RPM is also your friend
There are times when you want to find if you have a package installed or not, or find out what packages you have installed and search them for a string.
Rpm can be used in these circumstances. The two examples below show firstly how you can see whether a particular package is installed and the second shows how you can search all your installed packages.
$ rpm -q <package> $ rpm -qa | grep <string>
Downgrade a package without removing half your desktop
During testing you sometimes need to revert back to the existing version of a package, if something is wrong and you need to check if it is a regression for example or if it causes problems elsewhere. Sometimes dependencies can be a problem, for instance you may want to remove something which is needed by half of your desktop. It will ask to remove half of your desktop!
Fear not. There is a way to downgrade it.
# urpmi --downgrade <package><target-version>
For example on a 64 bit system if you have been testing sudo-1.8.12-1 from the testing repo and wish to revert to the version in release, sudo-1.8.8-3, the command would be:
# urpmi --downgrade sudo-1.8.8-3.mga4.x86_64
An alternative is to the specify the repo containing the version to be downgraded to:
urpmi --downgrade --media "Core Release" sudo
or if the package has dependencies in another repo:
urpmi --downgrade --search-media "Core Release" sudo
You can use another, dirtier, way: force removal of a given RPM regardless of other RPMs that depend on it. This will leave your RPM database in an inconsistent state (do not reboot in that state) until you re-install the RPM in the wanted version.
# rpm -e --nodeps <package>
Downgrade everything from testing repos
To synchronise your system to only contain packages and versions from release and updates repositories.
- Read about this usage of DNF.
dnf offline-distrosync download --disablerepo=\*testing\* --allowerasing
Perl Modules
Perl modules are typically CamelCase and case sensitive and our packaged perl modules look something like perl-FileMineInfo or perl-DBD-SQLite so it can be difficult to guess the package name from the perl module require.
In a script, needed perl modules are usually listed near the top and look something like
use IO::Socket use Net::Patricia
If you find you are missing a perl module and need to find what it is or you know you need something like Net::Patricia and need to find which package provides that you can use either of the commands below..
$ urpmf --provides --literal 'perl(Net::Patricia)' perl-Net-Patricia:perl(Net::Patricia) or $ urpmq --whatprovides 'perl(Net::Patricia)' perl-Net-Patricia
Either of these would find the actual package required, in this case perl-Net-Patricia. The perl(Net::Patricia) is what is known as a virtual require or virtual dependency, as opposed to a normal require which would be a package name.
You will sometimes see confusing output such as below where it seemingly repeats itself, separated by |'s. It is actually listing available options which satisfy the virtual require. In this case it is listing two options which it has found several times in the repositories. It is listing items it finds in updates as well as release and so can list the same package a number of times.
$ urpmq --whatprovides 'perl(ExtUtils::Packlist)' perl-ExtUtils-Install|perl-ExtUtils-Install|perl|perl|perl
Gnome
As of Gnome 3.12 gnome no longer creates a /var/log/Xorg.0.log file for X logging. The information is now stored in the journal. You can use journalctl to recover the same information though and save it to a file which can be attached to a bug report.
# journalctl _COMM=X > /home/<YourUsername>/journal-xorg.txt # chown <YourUsername> /home/<YourUsername>/journal-xorg.txt
Obviously, when you do this, you need to replace <YourUsername> with your actual username.
Kernel Options
Kernel options can be used at the grub/grub2 boot stage to pass options to the kernel when it boots. This can be useful to work around GPU issues, ACPI issues, PCI issues, etc. It can even be used to blacklist certain drivers or force a breakpoint into the boot process.
See the kernel options page for further information.
Libraries used
lsof (list open files) can be used to list the shared libraries used by an application currently running.
For example, searching for libpixman with firefox :
# lsof | grep firefox | grep libpixman firefox 8801 user mem REG 8,2 707048 137291 /usr/lib64/libpixman-1.so.0.32.8 firefox 8801 8841 user mem REG 8,2 707048 137291 /usr/lib64/libpixman-1.so.0.32.8
