gregoa's blog

RCBW (Release Critical Bugs of the Week) work flow

as regular readers of planet debian probably know, I try to contribute to the RCBW initiative. I thought I might publish my work flow, which is very similar but not identical to zack's procedure mentioned above. – please note that this is mostly about FTBFS (fails to build from source) bugs.

preparation

0. find a nice bug from UDD's bug list; I usually check the ones which are present in both testing & unstable, at least 2 weeks old, & not yet fixed/done/pending. – often there are also ready-to-use patches available (created by some tireless bug fixers and/or forwarded from Ubuntu).
1. do a bit more research: look at the source package's BTS page (maybe there are other RC bugs), look at its PTS page (which may show Ubuntu patches which haven't been forwarded yet, or show that there's a newer version at mentors, or that the package is orphaned, etc.)
2. get the package:

   $ pushd ~/src/NMUs/
   $ mdcd dasher                                         # [0]
   $ apt-get source dasher                               # [1]
   $ cd dasher-4.11/
   $ dch --nmu --closes 643371,615705                    # [2]
   

3. build without any further changes to reproduce the problem.

bug fix

4. download/write patch(es), make sure to use the package's patch system (if any), build, check, rinse, repeat, finalise the changelog, build a last time, of course in a chroot, ...

checks

5. do the usual checks you would also do with your own package: lintian (you might learn about new tags you haven't seen before), debc (what does the content look like), ...
6. finally two specific checks:

   $ cd ..
   $ lintian -F dasher_4.11-1.1_i386.changes             # [3]
   $ cdebdiff dasher_4.11-1.dsc dasher_4.11-1.1.dsc      # [4]
   

upload / BTS

7. if everything looks good so far:

   $ dput -e 2 dasher_4.11-1.1_i386.changes              # [5]
   $ cd dasher-4.11/
   $ nmudiff --delay 2
   

8. take a note about the bug number(s) somewhere, in case you want to publish your work on your blog or somewhere else :)

tolimar kindly pointed out that subscribing to the package (via the PTS web frontend or pts-subscribe) after an NMU is a good idea – thanks for the addition!

footnotes

[0]

$ type mdcd
mdcd is a function
mdcd () 
{ 
    mkdir -p "$1";
    cd "$1"
}

[1] apt-get source also tells about a VCS where the package is maintained; in my experience with long-standing RC bugs without a maintainer reply those VCSes usually also don't contain any changes.

[2] to make sure that the first build has a new version, & the original source package is untouched. we need it again later.

[3] ftp-masters auto-reject

[4] check what you really have changed, & that it is as minimal as possible.

$ type cdebdiff
cdebdiff is a function
cdebdiff () 
{ 
    debdiff "$@" | colordiff
}

[5] I always upload to DELAYED/2, even if the release team has opened 0-day NMUs under specific circumstances, to give others a chance to catch errors.

gregoa, 2011-12-04, 2011-12-09