08/23/11 20:28:37< bertagaz> hi sylvestre__
08/23/11 20:29:07< sylvestre__> hi
08/23/11 20:29:13< lucas> hi
08/23/11 20:29:25< lucas> plb: around?
08/23/11 20:29:41< plb> hi
08/23/11 20:30:49< lucas> good
08/23/11 20:30:53< lucas> hi everybody
08/23/11 20:30:59< lucas> I think we can start
08/23/11 20:31:02< bertagaz> hello lucas
08/23/11 20:31:20< lucas> so, the goal today is to get your hands dirty filing RC bugs ;)
08/23/11 20:32:10< lucas> I've just created a pad on ietherpad.com: http://ietherpad.com/archivetesting
08/23/11 20:32:21< lucas> it contains the content of the http://wiki.debian.org/qa.debian.org/ArchiveTesting
08/23/11 20:32:31< lucas> the goal is to try to improve the wiki page while talking
08/23/11 20:33:09< sylvestre__> ok
08/23/11 20:33:28< lucas> I've done an archive rebuild yesterday evening, so we have fresh logs to process
08/23/11 20:33:46< lucas> the first step is to install the required tools
08/23/11 20:34:11< lucas> if you did that step during the bof at debconf, please start with: rm -rf /usr/local/lib/site_ruby/1.8/collab-qa*
08/23/11 20:34:23< lucas> I've created a basic debian package for collab-qa-tools
08/23/11 20:34:42< lucas> to install it locally:
08/23/11 20:34:44< lucas> svn checkout svn+ssh://svn.debian.org/svn/collab-qa
08/23/11 20:34:44< lucas> cd collab-qa/collab-qa-tools ; dpkg-buildpackage -us -uc ; sudo debi
08/23/11 20:35:21< lucas> please tell me when you are done, and don't hesitate to shout if you run into issues
08/23/11 20:35:28< lucas> I don't expect everything to work fine ;)
08/23/11 20:35:53< bertagaz> is it possible to use git svn or will it break something?
08/23/11 20:36:02< lucas> it should work
08/23/11 20:36:10< bertagaz> trying
08/23/11 20:36:39< lucas> ah what are your alioth logins?
08/23/11 20:36:45< lucas> I need to add you to collab-qa
08/23/11 20:36:51< sylvestre__> sylvestre
08/23/11 20:36:53< bertagaz> bertagaz-guest
08/23/11 20:37:01< plb> plb-guest
08/23/11 20:37:14< dunetna> dunetna-guest
08/23/11 20:37:42< lucas> ok, thanks. doing it now. in the meantime, please do an anonymous checkout
08/23/11 20:37:58< bertagaz> I'm lagging a bit behind a Tor connection, so don't wait too much for me :)
08/23/11 20:38:31 * plb has installed the package
08/23/11 20:39:43-!- gio [~gio@ppp-49-154.29-151.libero.it] has quit [Ping timeout: 480 seconds]
08/23/11 20:41:14< lucas> once you have installed the package, go to collab-qa/archive-rebuilds/
08/23/11 20:41:22< lucas> that directory contains one directory per rebuild
08/23/11 20:41:43< lucas> then go to 2011-08-22-lsid64-amd64, which is the latest one
08/23/11 20:41:47< lucas> and look at README
08/23/11 20:43:21< plb> lucas: the folder 2011-08-22-lsid64-amd64 doesn't seems to exist.
08/23/11 20:43:26< sylvestre__> idem
08/23/11 20:44:25< CIA-4> collab-qa: lucas * r1987 /archive-rebuilds/2011-08-22-lsid64-amd64/ (5 files): rebuild results for 2011-08-22, no bugs filed yet
08/23/11 20:44:30< lucas> should be better now ;)
08/23/11 20:44:45< plb> yep
08/23/11 20:44:55< sylvestre__> indeed
08/23/11 20:44:55< CIA-4> collab-qa: lucas * r1988 /archive-rebuilds/fetch-and-process-results.rb: also generate README with more info
08/23/11 20:45:33< lucas> please retrieve the logs using one or the other method, and tell me when you are done
08/23/11 20:46:46< bertagaz> still fetching... :/
08/23/11 20:47:23< lucas> bertagaz: are you fetching the whole history using git svn? you might want to only fetch the latest rev (which is 1988)
08/23/11 20:49:20< plb> lucas: We need to merge old results (from others archive-rebuild) to avoid filling bugs twice ?
08/23/11 20:49:56< lucas> yes. the whole process revolves around filing a "failed.XXX.txt" file, which we first need to generate
08/23/11 20:49:58< bertagaz> lucas: no, I've switched to plain svn, to go faster during this session
08/23/11 20:50:38< lucas> that file only needs to be generated once per rebuild. I'll do it.
08/23/11 20:50:39-!- themill [~stuart@themill.user.oftc.net] has quit [Ping timeout: 480 seconds]
08/23/11 20:51:12< CIA-4> collab-qa: lucas * r1989 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: add failed.2011-08-22.txt
08/23/11 20:51:17< lucas> I did:
08/23/11 20:51:19< lucas> $ ../merge-results.rb ../2011-07-27-lsid64-amd64/failed.2011-07-27.txt failed.2011-08-22.tmp > failed.2011-08-22.txt
08/23/11 20:51:48< lucas> it means "take all the failures in failed.2011-08-22.tmp, and for each of them, look if it's an already known failure in ../2011-07-27-lsid64-amd64/failed.2011-07-27.txt.
08/23/11 20:52:27< lucas> you can wdiff/meld/whatever failed.2011-08-22.tmp and failed.2011-08-22.txt to see what it does
08/23/11 20:53:31< lucas> (interestingly, meld doesn't display anything useful)
08/23/11 20:54:04< lucas> kdiff3 does better
08/23/11 20:54:32< lucas> ok so far? did I lose you? :)
08/23/11 20:54:47< plb> lucas: what does the tag 'RECHECK' mean ?
08/23/11 20:54:47< sylvestre__> the wget takes forever 
08/23/11 20:55:11< lucas> sylvestre__: use rsync? ;)
08/23/11 20:55:47< sylvestre__> I haven't configured the key of this laptop on the debian server, I am doing it 
08/23/11 20:56:08< lucas> you can fetch http://people.debian.org/~lucas/logs/2011/08/22.tgz
08/23/11 20:56:15< lucas> it will be much faster
08/23/11 20:56:52< sylvestre__> ta
08/23/11 20:57:00< lucas> plb: RECHECK is kind-of useless. It means "it's still failing, maybe you should check again"
08/23/11 20:57:24< lucas> (check again the log)
08/23/11 20:58:17< plb> ok
08/23/11 20:58:34-!- bertagaz [~bertagaz@83TAACWF2.tor-irc.dnsbl.oftc.net] has quit [Remote host closed the connection]
08/23/11 20:59:32< lucas> do you have a local copy of the logs?
08/23/11 20:59:52< sylvestre__> yes
08/23/11 20:59:59< plb> lucas: nop
08/23/11 21:00:11< plb> eta 2m30
08/23/11 21:00:17< lucas> ok
08/23/11 21:00:20< lucas> let's wait :)
08/23/11 21:03:02< plb> bertagaz left ?
08/23/11 21:03:15< sylvestre__> lag => the tor effect
08/23/11 21:03:23< lucas> yup, apparently tor was up to the task ;)
08/23/11 21:03:50< plb> lucas: ok I've a local of the logs
08/23/11 21:03:56< lucas> ok
08/23/11 21:04:00< plb> s/local/local copy/
08/23/11 21:04:04< lucas> the next step is to go the where you have all the logs
08/23/11 21:04:07< lucas> and run cqa-scanlogs
08/23/11 21:04:15< lucas> it should go through each log and display a summary
08/23/11 21:04:19< lucas> does it work for you?
08/23/11 21:04:31< sylvestre__> it does
08/23/11 21:05:06< plb> idem
08/23/11 21:05:20< lucas> good. currently cqa-scanlogs scans all the logs, which is a bit useless. it's better to just scan the ones for which no bug has been filed yet
08/23/11 21:05:36< lucas> for that, you need to point to the failed.XXX.txt file that was created earlier (you might need to svn up)
08/23/11 21:05:40-!- themill [~stuart@themill.user.oftc.net] has joined #debian-qa
08/23/11 21:06:00< lucas> *** lucas@beothuk:/tmp/cqa.amd64.2011-08-22$ export TODOFILE=~/dev/collab-qa/archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt
08/23/11 21:06:01< lucas> *** lucas@beothuk:/tmp/cqa.amd64.2011-08-22$ cqa-scanlogs -t $TODOFILE
08/23/11 21:06:14-!- bertagaz [~bertagaz@82VAADD2E.tor-irc.dnsbl.oftc.net] has joined #debian-qa
08/23/11 21:06:38< lucas> bertagaz: re ;)
08/23/11 21:06:39< bertagaz> sorry, bad swicth had troubles
08/23/11 21:07:08< sylvestre__> cqa-scanlogs -t $TODOFILE returns nothing
08/23/11 21:07:10< sylvestre__> is it normal ?
08/23/11 21:07:22< lucas> sylvestre__: no
08/23/11 21:07:34< sylvestre__> and yes, TODOFILE points to the right one
08/23/11 21:08:27< lucas> mmh, what would possibly go wrong...
08/23/11 21:09:38< lucas> TODOFILE is pointing to the .txt file, not the .tmp file ?
08/23/11 21:10:36< sylvestre__> I did a copy and paste of your path (I just have a /debian dir after dev/)
08/23/11 21:10:45< sylvestre__>  /home/sylvestre/dev/debian/collab-qa/archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt
08/23/11 21:11:09< lucas> grep TODO $TODOFILE | wc => 284 lines?
08/23/11 21:11:52< sylvestre__> indeed
08/23/11 21:12:38< lucas> strange
08/23/11 21:13:01< bertagaz> bad switch + Tor makes life difficult :)
08/23/11 21:13:15< dunetna> I've the same problem
08/23/11 21:13:29< plb> it works for me
08/23/11 21:13:38< dunetna> I mean sylvestre's problem
08/23/11 21:14:05< lucas> http://blop.info/pub/cqa-scanlogs
08/23/11 21:14:09< plb> cqa-scanlogs -t $TODOFILE produces to stdout 284 lines.
08/23/11 21:14:10< lucas> can you try with this version?
08/23/11 21:14:54< sylvestre__> works for me with this one
08/23/11 21:15:07< sylvestre__> 286 lines
08/23/11 21:15:55< lucas> ok, what's displayed on stdout?
08/23/11 21:15:57< lucas> stderr
08/23/11 21:16:38< dunetna> ["ada-reference-manual", "amphetamine", "ant1.7", "aspectj", "asymptote", "autogen", ...
08/23/11 21:17:12< lucas> very strange. the only difference is added debugging output
08/23/11 21:17:34< lucas> can you diff it with the one in your path?
08/23/11 21:17:58< lucas> (to make sure it's not an old copy or sthing)
08/23/11 21:18:04< sylvestre__> -w from the start
08/23/11 21:18:21< sylvestre__> http://paste.debian.net/127164/
08/23/11 21:18:41< lucas> that's crazy :)
08/23/11 21:18:57< sylvestre__> Ruby ? :p
08/23/11 21:19:22< bertagaz> don't feed the troll :D
08/23/11 21:19:36< sylvestre__> ;)
08/23/11 21:19:42< plb> ;)
08/23/11 21:19:51< lucas> ruby --version
08/23/11 21:19:52< lucas> ?
08/23/11 21:19:54< dunetna> I¡ve the same output
08/23/11 21:20:11< dunetna> ruby 1.8.7 (2011-06-30 patchlevel 352) [i486-linux]
08/23/11 21:20:12< plb> ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
08/23/11 21:20:23< sylvestre__> ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
08/23/11 21:20:26< sylvestre__> \o/
08/23/11 21:20:35< lucas> ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
08/23/11 21:21:05< sylvestre__> In fact, it is a qa session about ruby :p
08/23/11 21:21:11< sylvestre__> (désolé lucas ;)
08/23/11 21:21:12< lucas> ok, let's move on, and see if other tools also break
08/23/11 21:21:12< bertagaz> hehe
08/23/11 21:21:38< ana> it seems like murphy is also attending :D
08/23/11 21:21:48< lucas> then, we will file bugs. but sometimes, bugs are already filed on the BTS. so, the tool gets a local copy of possible bug candidates
08/23/11 21:21:58< lucas> for that, do cqa-fetchbugs -t $TODOFILE
08/23/11 21:22:07< lucas> it takes a while (SOAP interface is quite slow)
08/23/11 21:22:15< sylvestre__> [21:20:44][sylvestre@losinj] ~/dev/debian/collab-qa$ cqa-fetchbugs -t $TODOFILE
08/23/11 21:22:15< sylvestre__> [21:22:06][sylvestre@losinj] ~/dev/debian/collab-qa$ 
08/23/11 21:22:20< sylvestre__> once more, sorry :p
08/23/11 21:22:22< lucas> ok, that's what I feared. :)
08/23/11 21:22:36< lucas> can you re-add -w a the top?
08/23/11 21:22:41< lucas> at
08/23/11 21:22:50< lucas> it's not supposed to change anything, but ... :)
08/23/11 21:22:57< sylvestre__> it does not
08/23/11 21:23:03< lucas> where is your local copy of the logs?
08/23/11 21:23:41< sylvestre__> ok, i switched directory
08/23/11 21:23:54< sylvestre__> (If i may, you should add a warning)
08/23/11 21:23:56< bertagaz> should maybe do a tarball of the build logs to speed up the download
08/23/11 21:24:09< lucas> sylvestre__: can you elaborate?
08/23/11 21:24:13< sylvestre__> <lucas> you can fetch http://people.debian.org/~lucas/logs/2011/08/22.tgz
08/23/11 21:24:27< bertagaz> :P
08/23/11 21:24:30< sylvestre__> lucas, I was in a wrong directory, I switched to /tmp/cqa*/ and it worked
08/23/11 21:24:40< dunetna> idem...
08/23/11 21:24:42< lucas> how come cqa-scanlogs worked, then? :)
08/23/11 21:24:50< lucas> (with -t)
08/23/11 21:25:00< lucas> err without
08/23/11 21:26:16< sylvestre__> well, it worked when I used the one you provided after
08/23/11 21:26:27< lucas> from the same dir?
08/23/11 21:26:43< sylvestre__> from ~/dev/debian/collab-qa
08/23/11 21:27:35< lucas> err, I don't get it.
08/23/11 21:27:46< lucas> anyway, if it works for everybody now, let's move on
08/23/11 21:27:50< sylvestre__> me neither 
08/23/11 21:27:55< lucas> does cqa-fetchbugs -t $TODOFILE works?
08/23/11 21:28:44< sylvestre__> when I am in the directory with the logs, it does work
08/23/11 21:28:51< lucas> $ cqa-scanlogs 
08/23/11 21:28:52< lucas> No (matching) log files found in current directory.
08/23/11 21:28:57< lucas> better like that?
08/23/11 21:29:03< sylvestre__> t'assure!
08/23/11 21:29:27< CIA-4> collab-qa: lucas * r1990 /collab-qa-tools/bin/cqa-scanlogs: add message when no log files are found in current dir
08/23/11 21:30:18< lucas> so, everybody is fine and doing cqa-fetchbugs -t $TODOFILE ?
08/23/11 21:30:24< lucas> (which is expected to take some time)
08/23/11 21:30:28< plb> yep
08/23/11 21:30:45< dunetna> 103/284... (slow connection here :-( )
08/23/11 21:31:14< sylvestre__> bertagaz, is at about 1/284 :p
08/23/11 21:31:20< lucas> the next step (which you can do in parallel) is to make sure that you can send mail from your machine, using mutt
08/23/11 21:31:32< bertagaz> sylvestre__: :D
08/23/11 21:31:40< bertagaz> actually I'm catching up
08/23/11 21:32:07< lucas> I use nullmailer as a simple relay (to avoid a full MTA installation)
08/23/11 21:32:42< sylvestre__> http://paste.debian.net/127166/
08/23/11 21:32:48< sylvestre__> sounds familiar ?
08/23/11 21:33:17< lucas> sylvestre__: start it again (it doesn't re-download everything)
08/23/11 21:33:27< lucas> SOAP interface is slow and sometimes crashes ;)
08/23/11 21:33:32< sylvestre__> ok
08/23/11 21:33:52< plb> lucas: the scripts need a mta or mutt will suffice ?
08/23/11 21:34:08< lucas> the scripts call mutt, currently
08/23/11 21:34:32< bertagaz> mutt can't so smtp alone
08/23/11 21:34:43< lucas> mutt needs a /usr/sbin/sendmail
08/23/11 21:34:55< lucas> if you don't have a MTA currently, I recommend nullmailer
08/23/11 21:35:07< lucas> which just does local queuing + relay to a SMTP server
08/23/11 21:35:11< bertagaz> maybe this could be something configurable (which mailer to use)
08/23/11 21:35:28< bertagaz> I use msmtp-queue, works fine too
08/23/11 21:35:28< lucas> but I haven't looked at alternatives for the last 4 or 5 years ;)
08/23/11 21:36:13< bertagaz> :)
08/23/11 21:36:23< jcristau> mutt has $smtp_url to talk smtp instead of using sendmail
08/23/11 21:36:24< bertagaz> fetching bugs now
08/23/11 21:36:34< bertagaz> oh really?
08/23/11 21:36:35< lucas> bertagaz: fetch http://blop.info/pub/bugs-cache.tgz
08/23/11 21:36:48< bertagaz> lucas: nice, thx
08/23/11 21:36:53< lucas> bertagaz: it contains what cqa-fetchbugs fetches
08/23/11 21:37:05< plb> lucas: mutt can send mail via smtp !
08/23/11 21:37:12< plb> set smtp_url=...
08/23/11 21:37:17< bertagaz> great, cause it just died
08/23/11 21:37:18< jcristau> plb: way ahead of you.
08/23/11 21:37:42< lucas> ok, as long as you can send mail somehow, it's fine
08/23/11 21:37:43< bertagaz> a lot of docs about needs to be updated then
08/23/11 21:38:17< bertagaz> ok, fetched
08/23/11 21:38:36< lucas> with nullmailer, I like the fact that mails get queued locally. It happened a few times that I removed mails from the local queue because it was a wrong bug or something.
08/23/11 21:39:38< lucas> plb, sylvestre__, dunetna: ok too?
08/23/11 21:39:46< lucas> (cqa-fetchbugs done?)
08/23/11 21:39:48< plb> ok
08/23/11 21:39:49< sylvestre__> yes
08/23/11 21:40:11< dunetna> 278/284... almost!
08/23/11 21:40:17< lucas> ok, the next step is to file bugs ;)
08/23/11 21:40:32< lucas> first, you need to set the DATE environment variable. e.g export DATE=2011/07/22
08/23/11 21:40:41< lucas> that's the date of the directory on people.d.o, not the current date
08/23/11 21:40:55< lucas> export  DATE=2011/08/22
08/23/11 21:40:59< lucas> in our cases (typo above)
08/23/11 21:41:49< lucas> then, the process is a loop. find a subset of bugs that can be filed using cqa-scanlogs -t $TODOFILE, then file with cqa-annotate -t $TODOFILE -r regexp
08/23/11 21:42:31< lucas> as you can see, there are tags in the cqa-scanlogs output. the easier ones are GCC_ERROR, then LD_ERROR, then BUILDDEPS, then all the other
08/23/11 21:43:57< lucas> apparently, there's a few pkgs failing with errors related to ppd_file_t. I will file those as an example
08/23/11 21:44:09< lucas> 1) cqa-scanlogs -t $TODOFILE |grep GCC_ERROR |grep ppd_file
08/23/11 21:44:39< lucas> => check that the number of failing packages is limited. if 200 packages are failing for the same thing, it might be better to investigate further: it might not be those packages' fault
08/23/11 21:44:57< lucas> 2) cqa-annotate -t $TODOFILE -r ppd_file
08/23/11 21:45:26< lucas> that's the bug filing script. -r specifies a regexp
08/23/11 21:48:22< lucas> for each matching failure, the script prompt for an action, which can be:
08/23/11 21:48:26< lucas> s => skip that failure
08/23/11 21:48:43< lucas> 1,2,3,4... indicate that the bug is one of those already filed
08/23/11 21:48:45< lucas> r => report a bug
08/23/11 21:49:09< lucas> so, all, please start cqa-annotate -t $TODOFILE -r ppd_file   (after setting DATE)
08/23/11 21:50:02< lucas> then, file one bug. dunetna => 'xpp' package. sylvestre__ => scribus-ng. plb => scribus. bertagaz => gtklp
08/23/11 21:50:07< sylvestre__> k
08/23/11 21:50:32< plb> ok
08/23/11 21:50:55< lucas> when you type 'r', it opens mutt, you can edit the mail, and then send it
08/23/11 21:53:44< CIA-4> collab-qa: lucas * r1991 /collab-qa-tools/bin/cqa-annotate: improve cqa-annote: error out if DATE not set ; display package name before prompt
08/23/11 21:53:54< plb> lucas: in this case, the error is quite basic. So we just need so check the mail and send it ?
08/23/11 21:54:12< lucas> yes
08/23/11 21:54:30< lucas> when you file the first bug, it's good to check that the link to the build log works
08/23/11 21:55:42< dunetna> I think it's not working for me :-( http://paste.debian.net/127172/
08/23/11 21:55:55< dunetna> is it normal?
08/23/11 21:56:01< lucas> that's ok. it's a "silent" prompt :-)
08/23/11 21:56:04< lucas> just type s
08/23/11 21:56:28< lucas> s<enter> (to skip the failure)
08/23/11 21:56:45< dunetna> and this: TOO MANY LINES?
08/23/11 21:57:16< lucas> it's an indication that the log excerpt has a lot of lines, and that you might want to trim it before sending the mail
08/23/11 21:57:29< lucas> so, in mutt, you would edit the log
08/23/11 21:57:48< dunetna> ok :-)
08/23/11 21:59:34< lucas> tell me when you have filed 'your' bug
08/23/11 22:00:00< sylvestre__> I did but I forgot to configure my mutt
08/23/11 22:00:10< sylvestre__> So, the sender address was a bit weird :p
08/23/11 22:00:37 * bertagaz hold his breath while reviewing 5 times the email :)
08/23/11 22:01:33< plb> lucas: and then after sending mail, cqa-annotate proposes to edit TODOFILE. It's to report the bug number ?
08/23/11 22:01:36< bertagaz> ok send
08/23/11 22:01:47< lucas> plb: yes, just press enter
08/23/11 22:01:55< lucas> (to confirm)
08/23/11 22:02:05< plb> ls
08/23/11 22:02:10 * plb oups
08/23/11 22:02:30< lucas> after filing your bug, if you look at $TODOFILE, you see NNN on the line of your package instead of TODO
08/23/11 22:02:59< lucas> this is used later by cqa-importbugsnumbers to fill in the file using the bug numbers from the BTS
08/23/11 22:03:51< dunetna> sent
08/23/11 22:04:12< bertagaz> that's magic!
08/23/11 22:04:15< plb> how cqa-importbugsnumbers find the right bug number ?
08/23/11 22:04:34< lucas> by looking at the usertag
08/23/11 22:04:39< lucas> 22:03 < BTS> Opened #639031 (serious) in src:scribus by Philippe Le Brouster  <plb@nebkha.net> «scribus: FTBFS: cupsoptions.cpp:77:2: error:  'ppd_file_t' was not declared in this scope».  http://bugs.debian.org/639031
08/23/11 22:04:40< lucas> :-)
08/23/11 22:05:21< lucas> ok, questions?
08/23/11 22:05:46< bertagaz> hmmm, not really at the moment
08/23/11 22:05:57< bertagaz> think I get the basics
08/23/11 22:06:15< lucas> so, the next step is just to file lots of bugs
08/23/11 22:06:18< bertagaz> might need some more to make abetter idea
08/23/11 22:06:20< dunetna> me too :-)
08/23/11 22:06:21< sylvestre__> I have one question
08/23/11 22:06:24< lucas> to coordinate a bit:
08/23/11 22:06:48< sylvestre__> If I am aware that a package is failing, how can I get cqa-annotate -t $TODOFILE to point me directly to the specific package ?
08/23/11 22:06:58< sylvestre__> (I did quagga with my right email address)
08/23/11 22:07:17< lucas> 1) svn up, rebuild collab-qa-tools, and install the new version. it now shows the package name after the log excerpt
08/23/11 22:07:31< lucas> 2) svn switch to a svn+ssh checkout, so you can commit
08/23/11 22:07:47< lucas> sylvestre__: you can use -r packagename. it matches the package name too
08/23/11 22:08:08< sylvestre__> yes but I don't see why it goes throuh the whole list
08/23/11 22:08:20< lucas> 22:06 < BTS> Opened #639032 (serious) in src:gtklp 1.2.7-2.1 by bertagaz  <bertagaz@ptitcan...> «gtklp: FTBFS: gtklp.h:99:1: error: unknown type  name 'ppd_file_t'». http://bugs.debian.org/639032
08/23/11 22:08:20< lucas> 22:06 < BTS> Opened #639033 (serious) in src:xpp 1.5-cvs20050828-1.1 by Mònica  Ramírez Arceda <monica@probeta...> «xpp: FTBFS: xpp.h:101:3: error:  'ppd_file_t' does not name a type». http://bugs.debian.org/639033
08/23/11 22:08:36< lucas> sylvestre__: could be a feature request ;)
08/23/11 22:08:48< bertagaz> now another maintainer will hate me
08/23/11 22:08:54< dunetna> XDD
08/23/11 22:09:08< dunetna> I have one question (maybe silly)
08/23/11 22:09:09< sylvestre__> bertagaz, I am sure it is the reason we are all here tonight ;) 
08/23/11 22:09:14< bertagaz> hehe
08/23/11 22:09:21< bertagaz> qa cabal!
08/23/11 22:09:28< dunetna> how can we coordinate not to send the same bugs?
08/23/11 22:09:36< bertagaz> good one
08/23/11 22:09:57< lucas> sylvestre__: as a hack, you could do something like cqa-annotate -t <(grep quagga $TODOFILE)
08/23/11 22:10:06< plb> lucas: when do we use cqa-importbugsnumbers ? when the bug is opened ?
08/23/11 22:10:18< lucas> plb: usually, I do it when all the bugs are opened
08/23/11 22:10:22< plb> ok
08/23/11 22:10:40< lucas> [coordination] I'm not sure. currently, the best is to "take locks" by synchronizing on IRC
08/23/11 22:10:53< sylvestre__> it is going to be messy, don't you think ?
08/23/11 22:11:12< lucas> it depends on how many people file bugs on a regular basis
08/23/11 22:11:43< sylvestre__> it depends also on how often you rebuild everything
08/23/11 22:11:55< lucas> if it's 2 persons, it's easy to coordinate. 5 is harder
08/23/11 22:12:21< lucas> once every two or three weeks works well. not too many new failures.
08/23/11 22:12:39< lucas> also, the other big part is installation testing. I don't have time to process those logs at the moment
08/23/11 22:12:48< lucas> (all the tools are the same)
08/23/11 22:13:02< bertagaz> ah that kinf of test exists?
08/23/11 22:13:29< lucas> yes. I rewrote something similar to piuparts, but more suitable to analyze lots of logs in an automated way
08/23/11 22:13:59< bertagaz> ah ok, I misunderstood I think
08/23/11 22:14:02< bertagaz> begin to be tired
08/23/11 22:14:53< bertagaz> maybe we can go on in the next future as we did this time, contact us by mail to define a date for qa meetings
08/23/11 22:15:05< CIA-4> collab-qa: plb-guest * r1992 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: Filed a bug (tutorial session).
08/23/11 22:15:11< bertagaz> so that you can start the builds according to it
08/23/11 22:15:37< lucas> yes. who wants to file some bugs tonight?
08/23/11 22:15:43< sylvestre__> lucas, did you see any of scribus-ng, zsh, quagga or netcdf ?
08/23/11 22:15:54< lucas> sylvestre__: no
08/23/11 22:15:55< sylvestre__> (maybe my mta hates me)
08/23/11 22:15:56< sylvestre__> ok
08/23/11 22:16:10< lucas> (#debian-devel-changes)
08/23/11 22:16:10< bertagaz> I guess there is a qa mailing list, maybe this kind of meetings should be advertides there too, ti try to motivate other people
08/23/11 22:16:29< lucas> yes, please all subscribe to debian-qa@lists.debian.org
08/23/11 22:17:23< bertagaz> I don't have much power left, I won't be able to stay too much longer tonight
08/23/11 22:17:54< dunetna> I subscribed yesterday and saw this meeting :-)
08/23/11 22:18:27< dunetna> reverse-Murphy
08/23/11 22:18:31< lucas> for today, I propose to 'split' the list into sublists of a-d, e-h, i-l, etc.
08/23/11 22:18:38< bertagaz> dunetna: :)
08/23/11 22:19:01< lucas> (a-d being "packages starting with a to d")
08/23/11 22:20:30< dunetna> I can't do it tonight but I can do it tomorrow, if you give me the letters :-)
08/23/11 22:21:34< lucas> I think that it's safe to assume that you can come here and ask if someone else is failing bugs, and then coordinate
08/23/11 22:21:46< dunetna> ok
08/23/11 22:21:55< lucas> filing*
08/23/11 22:22:43< lucas> usually, it's good not to way for too long before filing the bugs, because some DDs often find the failures by themselves, and fix them before you file the bugs
08/23/11 22:22:44< bertagaz> I guess there's no real deadline wether he age of this buildlogs, the more we wait to fill bugs against them, the more we have to check if a new package have been uploaded?
08/23/11 22:22:50< lucas> not to wait* (rah)
08/23/11 22:22:50< plb> yep and announcing on #debian-qa when starting to file  bugs from an archive rebuild.
08/23/11 22:23:35< lucas> bertagaz: the script does that check if you apt-get update before (it just runs apt-cache showsrc)
08/23/11 22:23:44< bertagaz> nice :)
08/23/11 22:24:03< bertagaz> I won't be able to attend here before friday I think, not much spare time before
08/23/11 22:24:18< jwilk> Yay for fresh blood in the QA team. :)
08/23/11 22:25:28< bertagaz> k, will have to shutdown before completely screewing up my battery
08/23/11 22:25:31< lucas> don't get discouraged if you file a "wrong" bug. that happens. it's all about a compromise between finding real issues and losing DD time by filing wrong bugs
08/23/11 22:25:38< bertagaz> thanks for the usefull course lucas
08/23/11 22:25:47< lucas> <2% wrong bugs is probably OK ;)
08/23/11 22:25:53< bertagaz> hehe
08/23/11 22:26:18< bertagaz> see you
08/23/11 22:26:22< lucas> see you
08/23/11 22:26:26< dunetna> lucas: thanks :-)
08/23/11 22:26:55-!- bertagaz [~bertagaz@82VAADD2E.tor-irc.dnsbl.oftc.net] has quit [Quit: Leaving.]
08/23/11 22:27:50< plb> lucas: thanks too :).
08/23/11 22:28:50< lucas> you're welcome :)
08/23/11 22:29:55< plb> So I'm going to file some bugs now. the GCC_ERROR for the letter 'c'
08/23/11 22:30:35< lucas> ok
08/23/11 22:32:50< lucas> dunetna: your $DATE is wrong (08 instead of 07).
08/23/11 22:33:10< CIA-4> collab-qa: lucas * r1993 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: imported bug numbers
08/23/11 22:33:11< dunetna> aaaggghh.... sorry :-(
08/23/11 22:33:18< lucas> no big deal
08/23/11 22:33:36< lucas> I noticed because the usertag is wrong, so I couldn't import the bug number
08/23/11 22:33:56< lucas> I'm filing BUILDDEPS matching libtiff4-dev
08/23/11 22:34:53< dunetna> I wanted to restart the debconf XDD
08/23/11 22:34:53< plb> lucas: before reporting a bug, how cqa-annotate filters the bug list for a given package ?
08/23/11 22:35:14< plb> (to check if the bug is already reported)
08/23/11 22:35:33< lucas> it looks at .bugs.packagename in the current directory
08/23/11 22:35:39< lucas> ah, it only lists lines with TODO
08/23/11 22:37:01< plb> and cqa-annotate proposes all the opened bug in the bts ?
08/23/11 22:37:31< lucas> no, only those matching a regexp
08/23/11 22:37:46< lucas> next if (not ['serious', 'grave', 'critical'].include?(v.severity)) and v.subject !~ /ftbfs/i and v.subject !~ /piuparts/i and v.subject !~ /installation/i and v.subject !~ /(post|pre)(rm|inst)/i and v.subject !~ /buil(d|t)/i and v.subject !~ /remov/i and v.subject !~ /purge/i and v.subject !~ /upgrade/i and v.subject !~ /prompt/ and v.subject !~ /conffile/
08/23/11 22:37:49< lucas> (in cqa-fetchbugs)
08/23/11 22:39:05< plb> ok
08/23/11 22:41:30< CIA-4> collab-qa: lucas * r1994 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: more bugs filed
08/23/11 22:42:47< lucas> interesting. gcc 4.6 seems to have the concept of "fatal error"
08/23/11 22:44:42< lucas> sylvestre__: congrats ;)
08/23/11 22:44:53< sylvestre__> \o/
08/23/11 22:45:40< plb> lucas: is it possible that a GCC_ERROR reason found by cqa-scanlog is wrong ?
08/23/11 22:45:52< lucas> plb: yes. which bug log?
08/23/11 22:46:08< lucas> (or which package)
08/23/11 22:46:10< plb> choosewm
08/23/11 22:46:37< lucas> ah yes, it fails during configure. that's hard to parse correctly
08/23/11 22:48:07< plb> also for the human :)
08/23/11 22:50:59< plb> the right error is at line 471 ?
08/23/11 22:52:13< lucas> configure: error: "Could not find gtk/gtk.h. Calling ./configure with CPPFLAGS containing -I/usr/include/gtk-2.0 and -I/usr/lib/gtk-2.0/include might help.
08/23/11 22:52:16< lucas> that's the one
08/23/11 22:52:45< plb> yep this is the error i found.
08/23/11 22:53:16< plb> but my line number come from the mail template...
08/23/11 22:57:35< CIA-4> collab-qa: lucas * r1995 /collab-qa-tools/ (3 files in 3 dirs): handle the new gcc 4.6 'fatal error'
08/23/11 22:58:34< lucas> I'm doing UNKNOWN lines matching "fatal error". they don't show up as GCC_ERROR in the version of cqa-scanlogs you are using. but they will if you update your collab-qa-tools package.
08/23/11 22:58:46< lucas> (so it's better if you refrain from updating right now)
08/23/11 23:02:51< CIA-4> collab-qa: lucas * r1996 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: more bugs filed
08/23/11 23:05:11< CIA-4> collab-qa: lucas * r1997 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: manually mark some bugs NNN to avoid dupe filings
08/23/11 23:07:21< CIA-4> collab-qa: plb-guest * r1998 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: more bugs filed
08/23/11 23:08:33< plb> I'm doing GCC_ERROR from d to n
08/23/11 23:08:59< lucas> ack
08/23/11 23:09:13< lucas> I'm going to bed ;)
08/23/11 23:09:47< lucas> when you are done:
08/23/11 23:09:49< lucas> cqa-importbugnumbers debian-qa@lists.debian.org qa-ftbfs-20110822 < failed.2011-08-22.txt > failed.2011-08-22.txt2 ; mv failed.2011-08-22.txt2 failed.2011-08-22.txt
08/23/11 23:10:03< plb> ok
08/23/11 23:27:33< CIA-4> collab-qa: plb-guest * r1999 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: more bugs filed
08/23/11 23:54:27< CIA-4> collab-qa: plb-guest * r2000 /archive-rebuilds/2011-08-22-lsid64-amd64/failed.2011-08-22.txt: more bug filed + cqa-importbugnumbers