Jump to content
  • Announcements

    • spinynorman

      Mandriva Official Documentation

      Official documentation for extant versions of Mandriva can be found at doc.mandriva.com.   Documentation for the latest release may take some time to appear there. You can install all the manuals from the main repository if you have Mandriva installed - files are prefixed mandriva-doc.
    • paul

      Forum software upgrade   10/29/17

      So you may have noticed the forum software has upgraded !!!
      A few things that have changed. We no longer have community blogs (was never really used) We no longer have a portal page.
      We can discuss this, and decide whether it is needed (It costs money) See this thread: Here
Sign in to follow this  
aru

IM-12: HowTo Participate in the MDK Cooker Project

Recommended Posts

Browse: [About the FAQ Forum] [Table of Contents] [FAQs] [Contribute] [IM: Installing and Configuring Mandrake]

 

IM-12: HowTo Participate in the MDK Cooker Project

 

Post contents taken from MandrakeLinux.SA

 

Release 10.1 in Progress

 

10.0 is the current stable release for Mandrakelinux. Cooker is under active development for the next Mandrake release scheduled for September of 2004.

 

Background

 

One of the most common criticisms of the Mandrakelinux 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 Mandrake Community about how the Cooker process works. The truth of the matter is that the Mandrake 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 Mandrakelinux release earlier in the release timeline. This will allow feedback from those users to make it back to the Mandrake 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

 

MandrakeSoft's development version of the next Mandrakelinux release is called Cooker. The purpose of Cooker is to improve the Mandrakelinux distribution by permitting a better interaction between the development team and the Mandrakelinux 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 and ideas.

 

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.

 

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

 

Via FTP from a Public Mirror

 

Make a boot disk from the network.img file available on any of the public Cooker mirrors. The file should be located within the cooker/i586/images/ directory of the mandrake-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 rawwrite utility to make the boot disk in DOS or Windows. This utility is normally located in the /cooker/i586/dosutils directory of the mandrake-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 Mandrakelinux 10.1 can be found here, but can be summarized as:

  • Cooker Snapshot - mid July
     
  • Beta 1 - End of July
     
  • Beta 2 - Begining of August
     
  • Release Candidate 1 - Mid August
     
  • Release Candidate 2 - end of August
     
  • Final - Begining of Setptember

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 mandrake-iso subdirectory of most Mandrake 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 MandrakeClub 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 Mandrake 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.mandrakesoft.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/install/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


     
    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.mandrakesoft.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 (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 MakeCD

     

    MakeCD is a wrapper script that runs mkcd, and it will create a set of iso's for you to burn to CD. If you have a local Cooker mirror, it is quite easy to make you own set of disk's.

     

    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)

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 Mandrakelinux distribution is the easy urpmi script that was written by Oliver Thauvin. It can be found at http://urpmi.org/easyurpmi/index.php

 

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

 

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

 

Bugzilla is the master database for bug reporting In order to make a bug report, you need to get a valid Bugzilla account, which is very easy. You just navigate with your browser to qa.mandrakesoft.com and click on the "Open a new Bugzilla account" link and enter the information requested.

 

Normal accounts have privileges to add bugs, add comments to existing bugs and change the status of bugs that weere created with that account. Before a new bug is posted, Bugzilla will perform a search of the database looking for similar bugs and will prompt you make sure you want to post a new bug.

 

How Bugzilla Works

 

The web interface is the way most users interact with Bugzilla. The Mandrake Bugzilla is located at http://qa.mandrakesoft.com

 

There is a mail interface to Bugzilla that makes it easy to add additional comments or change the status of bugs if you have the appropriate level of access.

 

What the Various Bug Statuses Mean

These define the state the bug report is in.

  • UNCONFIRMED - the bug is new and no developer or other user has confirmed it yet; until then, it stays unconfirmed
     
  • NEW - the bug is new
     
  • NEEDINFO - a developer has asked more details to the reporter in order to understand what's going on with this bug
     
  • FIXED - the bug has been fixed
     
  • INVALID - the bug was considered not "real"
     
  • WONTFIX - for whatever reason, hopefully explained well in the comments, this bug will not be fixed (often considered non important, or we can't fix it)
     
  • LATER - the bug has been acknowledged, but is not going to be addressed until sometime later in the development process
     
  • REMIND -
     
  • WORKSFORME - no one could reproduce the problem, we see normal behaviour, so we can't do much about it...
     
  • OLD - a bug in this status is no longer relevant either because the software package in question has been updated, or because the package has been removed from the distro.

Voting for Bugs

 

Bugzilla maintains a voting system for helping users validate bug reports. It is supposed to be used so that people can indicate that they have duplicated a bug and feel it is important, while hopefully reducing duplicate bug reports.

 

The Cooker Mailing List

 

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. Searchable archives are available at http://marc.theaimsgroup.com/ and http://gmane.org . 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.

 

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.

 

If you cannot follow cooker but still want some insight of the discussion, you should see the CookerWeeklyNews. But if you run cooker, you should follow cooker, at least search the archives when you have a problem ( http://archives.mandrakelinux.com/ )

 

TestZilla

 

Through the Testzilla pages on Bugzilla, you can follow procedures to report successes or bugs on Bugzilla components.

 

To be able to perform hardware testing, you must first upload your system configuration to TestZilla. To do so, install the hwdb-clients package and run hwdb_add_system <bugzilla account>. Then you will have access to the various hardware validation procedures from the Testzilla pages.

 

Consult TestZilla if you want to contribute procedures or see how the whole system works.

 

Contributing Patches

 

If you develop a patch that corrects a bug in one of the Mandrake developed tools, send your patch to the Cooker mailing list and to the maintainer of the package.

 

If you develop a patch for a software application that is packaged and included in the Mandrakelinux distribution, send your patch to the maintainer of the package and also submit it upstream to the software project itself. Mandrake packagers often patch sources to fix major bugs, but the sources themselves should be fixed by the project. Not all software projects have MandrakeSoft employees that work on CVS, so submitting a patch to Mandrake 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 Mandrake software and no updates can be made to packages except for major bugfixes.
     
  • Deep Freeze - Only showstopper bugfixes and security flaws can be upgraded.

Other references are:

Edited by Tuxiscool

Share this post


Link to post
Share on other sites
Sign in to follow this  

×