Development/Howto/Participate
From Mandriva
Current Status: Development in progress
2007 is the current stable release for Mandriva Linux. Cooker is under active development for the next Mandriva Linux release.
Background
One of the most common criticisms of the Mandriva Linux development process is that there is not enough time during the beta testing process for users to get involved in the process before the next release is rushed out the door. After much discussion of this subject on the Cooker mailing list, it quickly became apparent that there is a lack of understanding in the general Mandriva Community about how the Cooker process works. The truth of the matter is that the Mandriva beta testing period is almost three months long, but most users don't get involved until the very end of the process, and therefore are under the impression that the testing phase is too short.
The purpose of this document is to give interested ordinary users the information they need to get involved in testing the next Mandriva Linux release earlier in the release timeline. This will allow feedback from those users to make it back to the Mandriva developers within a timeframe that is useful.
Invariably, users install the second release candidate, and then post all kinds of messages for the Cooker mailing list and into the Bugzilla database requesting (sometimes demanding) new features for the current release. Unfortunately, at that point it is far too late to add features or new applications to the distro. If that decribes you, then the information in this document will be very helpful to you.
What Cooker Is
Mandriva's development version of the next Mandriva Linux release is called Cooker. The purpose of Cooker is to improve the Mandriva Linux distribution by permitting a better interaction between the development team and the Mandriva Linux users, both for debugging and adding new features. It is an entire distribution unto itself, that is constantly in progress and sometimes cannot even be installed because it is broken itself because of incompatibilities.
Be careful: the term Cooker is used interchangeably for the Cooker Mailing List (as discussed on Cooker), the Cooker Distribution (I'm running Cooker), the RPM repository (that package is in Cooker) and the Cooker Way of Life (I'm a Cooker, which may lead to an early demise due to the bleeding edge style).
What Cooker Isn't
Cooker is not the place to get all the latest releases of software for the stable release. You should not try to install Cooker packages on a stable release. Cooker RPMs are incompatible because they are compiled against libraries that are not available on your stable release installation. In addition to being incompatible, many of the packages may be very buggy because of packaging errors or the software itself.
Ways To Participate
There are many ways in which one can participate in the Cooker project. The most common way is to install one of the ISO releases during the beta test cycle, but you may also contribute software, translations to your language (see [[TranslationTask][Translating]]) and ideas.
You will also certainly enjoy to [[1][subscribe]] the Cooker discussion mailing-list, the changelog mailing-list, or one of the various mailing-lists related to a specific development or topic such as AMD64, i18n, server and so on.
Expectations
First of all, you need to remember that Cooker is a development distribution that is not well tested and is likely not to run properly most of the time. If you run it, it may mess up data, configurations, etc. It is not meant for a production environment. You have been warned.
!! A typical example in which upgrading to cooker means losing configuration is the kernel update. In such upgrade you need to rebuild your third party drivers. The most INVALID reported bug is about video cards (NVIDIA first of all), since the linux kernel is growing up and changing interfaces quickly, the most common problem is that you cannot rebuild your old drivers, and since we are in developer phase you should ask to third party developers for patches.
Running Cooker is exciting, though, because you get to be the first to see the new enhancements that are being introduced into the distribution. If you give feedback on your experiences with running Cooker, either through bug reporting or through the Cooker mailing list, you will be influencing the development of the next Mandriva Linux release.
Installing Cooker
The first step in participating in the Cooker is to get it installed, and as with any GNU/Linux distribution, there are multiple ways of doing this. You can even use a [[CookerOnVMHowTo][virtual machine installation]].
Via FTP from a Public Mirror
Make a boot disk from the network.img file available on any of the public CookerMirrors. The file should be located within the cooker/i586/images/ directory of the mandriva-devel tree on the mirror. If you are already running Linux, you can use dd to copy it to a floppy disk.
$ dd if=network.img of=/dev/fd0
If you are not already running Linux, you can use the rawrite utility to make the boot disk in DOS or Windows. This utility is normally located in the /cooker/i586/dosutils directory of the mandriva-devel tree.
If your system has no floppy drive, you can burn the image (network.img, pcmcia.img, or whatever) onto a bootable CD-ROM.
$ mkdir image $ cp network.img image $ mkisofs -b network.img image > network.iso $ cdrecord dev=0,0,0 network.iso $ rm -fr image
Installing from ISO Release
ISO releases (disk images of Cooker that can be burned to CDROM) are snapshots of Cooker that start coming out about 3 months before Cooker is considered stable and forked into the next release. The first release is generally referred to as the Cooker Snapshot. Following the Cooker Snapshot release, every two weeks or so a new set of iso's are created and released for testing up through the final release date. The approximate schedule for the next mandrivalinux distribution [[ReleaseInfo][can be found here]].
Many people like to install and test from these ISO releases, which is why they exist. If you test from the ISO releases, though, make sure you're testing the latest version.
Also, it is possible that an additional release candidate will be released if there is still work to be done to get the release stable. 9.1 and 9.2 had 2 release candidates and 9.0 had 3.
You can get the ISO images from the mandriva-iso subdirectory of most Mandriva Linux mirrors, or by using BitTorrent, you can download them from everybody else in peer-to-peer fashion. Check the Main page for a link to the official BitTorrent file and instructions on how to download beta iso images. If you are having trouble with BitTorrent, check out the Bittorrent FAQ over at the Mandriva Club site.
Keeping Your ISO's Up to Date Without Re-Downloading
When you test the ISO releases, you are unfortunately faced with the task of downloading a new set of ISO images every two weeks. This can take up a lot of bandwidth, and is absolutely out of the question for dial-up users. You can drastically reduce the amount of bandwidth your iso downloads take by synching the images using a protocol known as rsync.
I'll edit and incorporate this document later, but for now, here is a link to it: Using rsync to update Mandriva Linux ISO Images
From a Local Mirror
If you have about 6GB of diskspace available, it is faster and easier to install from a local mirror on your hard disk or on a local server. There are even scripts available to make a set of ISO images that can be burned to CD to install in the traditional way. Use fmirror or rsync to create a local mirror and keep it up to date.
Add stuff here about how to use fmirror or rsync
To install the rpmsync utility for Cooker:
# urpmi rpmsync
Running gendistrib
If you keep a local mirror, often times the hdlists get screwed up, so it is a good idea to run a script called gendistrib before you update your urpmi sources. To run the script, you must have write access to the directory tree that contains the dist tree. Navigate to the directory that contains the root of the dist tree and then type:
$ gendistrib --distrib
Via NFS Over the Local Network
Use the network.img image to create a boot floppy using one of the methods described above and select NFS instead of ftp.
Via Hard Disk Install (from a local mirror)
If your local mirror is on a partition that is on the machine you intend to install Cooker on, use the hd_grub.img floppy image to create a boot floppy using one of the methods described above (get it from the install/images directory of a mirror). Then, follow the instructions from http://qa.mandriva.com/hd_grub.cgi to create a GrUB menu.
Via Hard Disk or Network with No Floppy or CD-ROM
Some machines nowadays do not have a floppy drive or a CD-ROM drive. We have found a solution for that too.
Copy the necessary files from the isolinux directory to /boot/
$ cd /path/to/mirror/isolinux/alt0/ $ cp vmlinuz /boot/vmlinuz-all $ cp all.rdz /boot
Make an entry in /etc/lilo.conf if you use LILO or /boot/grub/menu.lst if you use GrUB
Example entry for LILO bootloader
image=/boot/vmlinuz-all
label=all-install
root=/dev/ram3
initrd=/boot/all.rdz
append="ramdisk_size=32000"
vga=791
read-only
Note that with Mandrakelinux 10.1beta2 you have to increase the ramdisk_size parameter to install it from Hard Disk. I've set it to 700000 "to be sure" and it worked.
As always, after you have finished editing /etc/lilo.conf, you need to run /sbin/lilo before your changes take effect.
Example entry for GrUB bootloader
title all-install
kernel (hd0,0)/boot/vmlinuz-all root=/dev/ram3 ramdisk_size=32000 vga=791
initrd (hd0,0)/boot/all.rdz
Via Hard Disk Install (from ISO images)
The disk install can also use ISO images from a local hard disk (put all ISO images in the same directory). There are many ways to use these ISO images:
- you can get install/images/boot.iso from a mirror, burn it to CD and boot on it
- you can copy the install/isolinux/ directory from a mirror to a local hard disk, then use http://qa.mandriva.com/hd_grub.cgi to create a GrUB boot disk (see Via Hard Disk Install)
- if you already have a linux system, you can add a bootloader entry to boot on the installer.
To mount the ISO image on a directory, as root, just do the following example :
$ mount -t iso9660 mandrakelinux-10.0-CD1.i586.iso /mnt/iso/ -o loop
(see Via Hard Disk or Network with No Floppy or CD-ROM)
Once the installer is started, it will ask the hard disk, the partition and the directory were the ISO images are located. If this directory contains more than one bootable ISO image, the installer will ask which one it should use.
Making CD's with mkcd
mkcd is the Mandriva program which creates distribution CDs. To creste a set of ISO files, run mkcd -a /cooker_path/, if you have a local Cooker mirror, it is quite easy to make you own set of disk's.
Note: MakeCD is now deprecated with the new install layout.
See: MkcdHowto.
If boot floppies don't contain your driver
Two main problems (maybe others): first, if you have an old SCSI adapter, we might have not included the driver in the boot floppies, so if you can't boot off the CDROM (old SCSI bios don't provide booting capability) you're trapped; second, if you need a proprietary SCSI driver or network driver (nvnet.o for example). That problem is solved that way:
- create a traditional boot floppy (cdrom.img if you plan to install from cdrom, network.img from network, etc)
- also create an ext2 floppy with command:
# mke2fs /dev/fd0
- find your driver and copy it (uncompressed) on the ext2 floppy with the command or its equivalent for another driver:
$ zcat /lib/modules/<kernel-version>BOOT/kernel/3rdparty/dc395x_trm/dc395x_trm.o.gz \ > /mnt/floppy/dc395x_trm.o
- also copy (uncompressed) the dependencies for that module (such as scsi_mod.o for example; there might be others, check in the modules.dep file)
- boot the traditional boot floppy, hit F1 and then type "linux expert", it will allow you, a while later, to put the other floppy and load the modules from there, in dependencies order of course (scsi_mod.o first, etc)
Via an USB Key
Since 27/01/2005 (not present in 10.2 beta2), a new image is available to boot on a usb key.
The file all.img is a fat16 image to dd on a partition (probably sda1 for most USB key). There are some caveats:
- it seems some bioses don't use the code on MBR (sda), or at least skip it when it's blanked
$ dd if=/dev/zero of=/dev/sda bs=1 count=446"
- some bioses need it. Pixel had some luck installing package extipl and using:
$ dd if=/usr/lib/extipl/aldebaran.bin of=/dev/sda
Via PXE boot
Probably one of the easiest way for admin. you must have recent network card (PXE1.5 or greater) PXE<=1 can be used but this is a pain for some of them. Install a PXE server, mandriva has some packages, but backup your dhcp.conf. In the pxelinux.cfg/default file, add the line:
label 10-1-OE
KERNEL vmlinuz
APPEND initrd=all.rdz ramdisk_size=128000 acpi=ht vga=788
and add the vmlinuz and all.rdz in your tftp server
Via urpmi
Probably the only way to avoid rebooting, having cd/floppy reader and stop watching tv/listening music.
You need first to add the Main and Contrib source in your current distribution (with urpmi) :
# urpmi.removemedia -a
Go on http://easyurpmi.zarb.org, select the cooker distribution, and follow the steps, then copy/paste the generated lines in you root console
And install the cooker distribution :
# mount --bind /proc /mnt/your_new_root/proc # urpmi --root=/mnt/your_new_root basesystem locales-XX urpmi kernel # urpmi --root=/mnt/your_new_root all_package_you_want # chroot /mnt/your_new_root [copy paste the urpmi.addmedia lines of cooker there] # exit
Setup the new distribution (remember to edit the cooker's /etc/fstab to swap the devices corresponding to / and the /mnt/your_new_root mount point):
# cp /etc/fstab /mnt/your_new_root/etc/
Add the kernel in lilo's owner distribution :
# cp /mnt/your_new_root/boot/vmlinuz /boot/vmlinuz-cooker # cp /mnt/your_new_root/boot/initrd.img /boot/initrd-cooker.img
If the /mnt/your_new_root/boot/initrd.img doesn't exist, just do the following step. If you need some special modules to be able to access hard disk contempt, add --preload module_name to mkinitrd command.
# chroot /mnt/your_new_root # KVERSION=$(ls /boot/vmlinuz-* | cut -c 15- | head -n 1); mkinitrd /boot/initrd-$KVERSION.img $KVERSION # exit # cp /mnt/your_new_root/boot/initrd.img /boot/initrd-cooker.img
Then add the following config lines in lilo.conf file :
image=/boot/vmlinuz-cooker label="linux-cooker" root=/dev/your_new_root_dev_file initrd=/boot/initrd-cooker.img append="PROFILE=default"
Then run lilo to store the config :
# lilo
You are now able to boot your cooker, do not forget to install the packages needed to have internet in (ppp-pppoe and rp-pppoe for example), xorg and other before rebooting. ;)
Keeping Your Cooker Installation Up to Date
URPMI is Your Friend
Defining a cooker urpmi source
One of the most useful tools developed for the Mandriva Linux distribution is the easy urpmi script that was written by Oliver Thauvin. It can be found at http://easyurpmi.zarb.org.
You can also use a GUI, called urpmi.setup. Install the package urpmi.setup, and launch it. It will query the list of mirror on a website, and then allow you to choose the mediums to add to urpmi. In order to save bandwidth, you should use a rsync enabled mirror (their url begins with rsync://).
If you have a favorite mirror that is not listed in the easyurpmi script, or if you have a local mirror, you can create the command line yourself with the following syntax:
# urpmi.addmedia <name> <source> with <relative path to hdlist>
You can find a complete list of the up-to-date and broken mirrors at http://manu.agat.net/mandrake/mirrors_state.html
Once you have urpmi sources set up for your Cooker installation, you can keep the package lists in the individual repositories updated by running the urpmi.update command. This is handy for the stable releases when the only thing that changes is the updates repository. Try:
# urpmi.update <repository name>
It is easier on a Cooker system, where all the repositories change daily, to keep all of them up to date by running urpmi.update with the -a switch. This updates all package sources.
# urpmi.update -a
This updates your urpmi configuration files with the updated hdlist.cz files that will be available on the mirrors. If you do not do this step, urpmi will not know about any of the package changes that have taken place on the mirror and you may get an error like "everything already installed" even thought you know there were lots of package changes on the mirrors.
Once the sources are updated, run:
# urpmi --auto-select
to update all installed packages. Essentially, urpmi checks all installed packages and determines if there is a newer package in one of the source repositories. If a newer version of the package exists, it will be installed along with any required dependencies that may have been created.
Starting with version 4.4, urpmi supports transactions. This means that packages are downloaded and installed in small related groups, instead of all at once. You will no longer have to resort to dirty tricks when you have a small /var partition. Also, since version 4.4-41mdk, urpmi updates itself first and restarts before updating any other packages.
You can also use the --auto and --no-uninstall switch ( on a recent urpmi version, > 4.3-13mdk ) to do a fully automated upgrade. Nothing will be uninstalled, and all questions will be skipped ( with a good default answer ).
The kernel-source package is used to be upgraded automatically but to update your kernel you have to run:
# urpmi kernel
This is required because the name of each kernel is unique so a previous kernel is never uninstalled when installing a new one.
The last step is to update the configuration. During the update several* .rpmnew files might have been created (you normally get a warning, but one easily misses those). etc-update can help you updating those config files.
Good Bug Reporting
If you think you have found a bug, there are some steps to take before reporting it into the Bugzilla database.
First, make sure that you are up to date with Cooker for the relevant packages, this will allow you to see if it has already been fixed. Cooker changes daily, so if you think you find a bug in beta2, and it is a week post release, there is a good chance that the package has been updated several times since the iso release. The easiest way to update to the latest packages is to make sure you have your urpmi sources set up properly and and either urpmi packagename, or make sure the entire system is current with urpmi --auto-select. Detailed instructions on this are contained in the previous paragraphs.
Second, make sure it is a reproducible problem. The developers will often dismiss a reproducible problem as a user error or a configuration problem. Therefore, if you can reproduce the problem, even on another machine, it will be very helpful in getting your bug report looked at.
Third, search through the Cooker mailing list archives and Bugzilla to see if the bug has already been reported. If it has been reported, you can add additional information to the existing report to help sort it out. There is no sense in adding a duplicate bug report to the database.
As for the role of the Cooker mailing list in comparison with the role of Bugzilla, use the Cooker mailing list to discuss whether something is a bug or not, use Bugzilla to report it.
Good bug report etiquette states that you need to be precise in bug reporting. Putting "Package XYZ is broken!" without giving a clear description is not wise. Give the failing package's name, a brief description of the problem, and some revelant information about your host, and anything that we need to do to reproduce the problem on our boxes. Also provide whatever other information that you may think is useful, including, but not limited to, configuration files of the package.
How to Use Bugzilla
Consult the Bugzilla Howto wiki page.
The Cooker Mailing List
The List is where discussions take place on how to implement things, the results of testing or whether something is a bug or not. Bug reports themselves should be reported in Bugzilla.
Because the cooker mailing list is a very high volume mailing list (it will often get over 1000 messages a day late in the development cycle) it is important that you be careful about how and when you post to the list. To reduce the noise level, it is a good idea to search the list archives for your issue prior to posting. To maximize the chances of your message being seen, help minimize the level of noise on the list by keeping idle chatter down and restraining yourself from making offtopic posts.
Consult the Development Mailinglists wiki page for details.
Testzilla Howto
Through Testzilla, you can follow procedures to report successes or bugs on Bugzilla components.
Consult the Testzilla Howto wiki page for details.
Contributing Patches
If you write a patch to fix a bug in one of the tools developed by Mandriva, send your patch to the Cooker mailing list and to the maintainer of the package.
If you write a patch for a software application that is packaged and included in the Mandriva Linux distribution, send your patch to the maintainer of the package and also submit it upstream to the software project itself. mandriva packagers often patch sources to fix major bugs, but the sources themselves should be fixed by the project. Not all software projects have Mandriva employees that work on CVS, so submitting a patch to Mandriva does not guarantee that the fix will find its way into the project sources.
Glossary of Terms
- Alpha Release - Also referred to as a cooker snapshot. It is probably broken and most likely quite badly but would really like you to test it as an assembly (distinct from testing the parts). The developers are still willing to make significant changes (bumping versions etc) to make everything work well, so now is the time to squawk loudly if your pet package or feature looks like being left out.
- Beta Release - a beta is an ISO release of Cooker that is meant to test the functionality that has been or is being added to various components of the distribution. It's probably got some serious bugs, so you don't want to use it in production but please feel free to use it for light duties. At this point, the package maintainers are generally unwilling to nudge package versions but will do so to fix problems. Minor problems that a lot of effort to be fixed and/or may upset other things in the fixing are now at risk of being left as they are.
- Release Candidate - a release candidate, or RC, is an ISO release of the distribution that is released for the purpose of finding show-stopper bugs in the features and packages that have been included. During the release candidate phase, no new packages or features may be added, but bug fixes may be committed if they are major. Please subject it to very heavy testing. If it works well, it will be blessed and submitted to the publisher for manufacturing the boxed sets and the iso images and distribution tree will posted to the mirrors for immediate download. The package maintainers won't nudge versions at all except as necessary to fix a showstopper. We won't fix anything if it's much less than a showstopper or security update unless it's dead easy and carries no risk of breaking anything else. It is useless to make a feature request at this time as *no new features can be added.*
- Contrib - packages that are not part of the main distro, but that are important because someone has packaged them and contributed them.
- Freeze - no feature adds can be made to any mandriva software and no updates can be made to packages except for major bugfixes.
- Deep Freeze - Only showstopper bugfixes and security flaws can be upgraded.
