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
