Testing files in dockyard-devel
Zackary Deems <[email protected]> Fri, 23 Apr 2004 06:55:31 -0400
| Newsgroups | gmane.linux.arklinux.devel |
|---|---|
| Organization | Ark Linux |
| Message-ID | <[email protected]> |
If you're not currently testing the new packages build in dockyard-devel, it might be a good idea to start (at least on a non-critical machine). If you use devel and test a new package, and it seems to work as you'd expect, or the fixed bug, or new feature is in fact fixed, or does work as described.. PLEASE go to the server and update the status of the package. We keep shooting ourselves in the foot by moving things to dockyard which work on the packager's machine, but weren't tested anywhere else, then end up causing huge headaches for the general populace. dockyard tools supports using a status flag to determine whether something has been tested. If we start using the status flags as they were intended, we should be able to prevent most of those problems. Requirements for updating the status of a package: 1) You must have an account on arklinux.org. If you do not, see me on internal and we'll get that fixed. (if you don't know what internal is, AND don't have an account, then this email isn't intended for you) 2) the package must NOT have been copied to dockyard yet. You can determine this two ways (which do completely different checks, mind you): /usr/local/sbin/getstatus -a <architecture> pkgname example: /usr/local/sbin/getstatus -a i586 XFree86 If the stable and unstable file versions are different, then it needs moving. To verify, run: needsmoving | grep pkgname example: needsmoving | grep XFree86 If it shows up in 'needsmoving', AND shows two different versions in getstatus, then we can proceed with updating the status of the package. The script which does the database updates is (for the moment) dydbupdate (dockyard database update). If you run it with no parameters, it will tell you what it wants to see. (bero has requested that I modify this to be simpler, and I will be looking at doing this sometime in the next two weeks). [[email protected] i586]$ dydbupdate Usage: dydbupdate --srpmkey parent [-b] [--tree contrib] [-s N|W|T] [--stable] rpmname [rpmname ..] -b batch (non-interactive) mode --srpm parent REQUIRED: name of the srpm which creates this / these RPM(s) -s N|W|T set the pakage status to one of: (N)ew (W)orking or (T)ested . (ignored if not configured with use_status_flag set to 'true') --tree contrib designates the build tree for the packages currently contrib and x86_64 are valid. --stable specifies to use the stable database -v Verbose output If the current status of the package shows as 'N' in getstatus, then you will update it to 'W'. If the current status is 'W' you will update it to 'T'. Good practice would be to only move packages with a status of 'T', meaning Tested. (Once a package is moved to dockyard, its status is set to 'S' for Stable) Yes, there are lots of cmdline options.. and it may seem confusing. BUT it's not that bad, really. To update all packages related to XFree86 to W, just use the following options: sudo /usr/local/sbin/dydbupdate -s W --srpmkey XFree86 XFree86 to update nvidia, which is in contrib, run: sudo /usr/local/sbin/dydbupdate -s W --srpmkey nvidia --tree contrib nvidia If everything works properly, you likely won't see any output without the -v option, but that's not a big deal. The only other peculiarity is: If for some reason getstatus shows no Stable version of the file, you'll need to set the status for it to 'S', and give it the --stable flag: sudo /usr/local/sbin/dydbupdate -s S --srpmkey nvidia --tree contrib --stable nvidia (Future versions may simply key off of the SRPM and update everything built by it, but that's NOT yet how dydbupdate works. dymv2stable DOES deal with the SRPM database which figures out what packages are associated with the one you're moving, and moves them too) If you need further instruction, please let me know. I'd like to get us to a point where we use this to help ourselves. Thanks guys (and boris) Z