Pi ist genau 3

tl;dr: app-portage/tatt now also does keywording bugs and includes bugbrowser code stolen from arch-tools.

It had been a while since I last worked on my arch testing tool tatt.  In the meantime Pawel’s arch-tools have gained momentum. Since I like to do archtesting from time to time, but felt too busy to develop tatt any further, last fall I thought of switching.  I have now abandoned that plan. Pawel’s and my workflow just seem very different and I think it is good to have two different approaches to automated arch testing. In the end this will mean more issues identified, because different tests are carried out. Tatt’s design is very centered around the individual bug (though this may change in the future). I think of it as “Give it a bugnumber and it will create all the scripts for automated testing and committing”.  Here’s how I currently use it:

# tatt -b ${bugnumber}

This will create a couple of scripts for USE-flag testing, rdep-testing, commit, clean-up, and also unmask the packages found in the title of the bug. When run with the -b option, the bug title is searched for package atoms. If there is a list of packages to be stabilized, I dump this list into a file and call tatt with

# tatt -b ${bugnumber} -f ${file-with-packages}

In this case it will use all the packages found in the file and write a single scripts that does testing for all of them.  When the scripts have been created, I run them

# sh ${something}-useflags.sh

# sh ${something}-rdeps.sh

The something is a jobname, automatically determined from the filename with -f, or the packagename with just -b, or passed on to tatt with the -j option. These scripts will run various emerge commands and protocol the output in  ${something}.report.  If everthing went well, I then do all the manual testing which may include running the program for a couple of hours. This part is very important especially for packages in the games-* category! If something did not work, then comes the manual investigation, so let’s assume that everything is fine for now. In this case I commit the stabilization to CVS by running the commit-script:

# sh ${something}-commit.sh

(Actually, since the test machine is virtual and I try to keep it tidy, I mirror the script to my dev-machine and commit from there, but you get the point). Once the commit is done, I clean-up the bug using

# tatt -r ${bugnumber} -m “Funny message”

This will comment on the bug with your funny message and remove your arch alias from CC. You can also pass the -c option which will close the bug as fixed. For all this bugzilla-automagic your pybugz should be logged into bugzilla or at least not ask for the password all the time. You have to take care of that yourself, for instance by making “bugz” an alias.

All this is long implemented.  What’s new: tatt now automatically determines whether the current job is a stable or keywording bug and writes the correct commit scripts. I also shamelessly merged some of Pawels bugbrowser code into tatt, so you can try this experimental feature using the -o option. Instead of passing a bugnumber, you would select the bug from the ncurses-browser, but again. My workflow is somehow different.

So much for now, let me know if you tried tatt and I would be delighted to receive pull requests on github.

tl;dr: app-portage/tatt now also does keywording bugs and includes bugbrowser code stolen from arch-tools. It had been a while since I last worked on my arch testing tool tatt.  In the meantime Pawel\'s arch-tools have gained momentum. Since I like to do archtesting from time to time, but felt too busy to develop tatt any ...