[03:23] <pitti> Good morning
[05:59] <balloons> elfy pong, though I guess you've gone
[06:32] <elfy> balloons: didn't miss that by much :p
[06:33] <elfy> I think I'm ok now - was wondering how I got access to package tracker as an admin - I believe that's xubuntu-release - I'm going to be assisting Studio in getting QA going for them so will be wanting to do the same for them as for us
[06:36] <balloons> elfy, ahh yes indeed
[06:36] <balloons> elfy, they'll need a similar team and we can grant access
[06:37] <elfy> a similar QA team? or release team?
[06:37] <elfy> I 'think' they have -release but not sure
[06:53] <balloons> elfy, either or
[06:54] <elfy> balloons: ok cheers :) have a good day
[06:54] <balloons> elfy, you as well..
[06:55] <elfy> :)
[08:42] <DanChapman> Good Morning
[09:16] <balloons> good morning DanChapman
[09:30] <DanChapman> hey balloons how's it going in malta?
[09:31] <balloons> DanChapman, excellent. It's nice to have everyone here and be able to speed up work on things requiring everyone
[10:46] <rbasak> pitti: any thoughts on parameterising tests in debian/tests/control? I want to call the same breaks-testbed test twice, but with a different parameter each time.
[10:46] <rbasak> pitti: the only way I can think of doing it is with a wrapper for each test.
[10:47] <pitti> rbasak: yes, I think I saw that in some packages; they have a debian/tests/do-test and a "test1" calling "do-test foo", and a "test2" calling "do-test bar"
[10:48] <rbasak> pitti: seems a bit ugly, but OK. Is a wishlist item of being able to do that directly from debian/tests/control acceptable?
[10:48] <rbasak> I'm not sure what the syntax would be
[10:49] <pitti> rbasak: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741330 vaguely goes into the same direction, but it's not the same
[10:49] <rbasak> Even if it were one per stanza maybe.
[10:49] <rbasak> Tests: foo
[10:49] <rbasak> Parameters: a b c
[10:49] <pitti> rbasak: yeah, not sure either; it probably will require a lot of extra syntax which doesn't make the whole thing significantly easier..
[10:49] <rbasak> would run "foo a", "foo b", "foo c"
[10:49] <rbasak> Tests: foo bar
[10:49] <rbasak> Parameters: a b
[10:49] <rbasak> could run "foo a", "bar a", "foo b", "bar b"
[10:50] <pitti> rbasak: then the next person will want this to have shell syntax, pass multiple arguments, pass outputs of other commands, etc. :0
[10:50] <pitti> so, I'm certainly not avert to the idea, I just wonder if it will make things significantly easier and clearer
[10:50] <rbasak> autopkgsh :)
[10:51] <pitti> rbasak: the above could just as well be read as "invoke foo with arguments "a b"
[10:51] <rbasak> "Why doesn't /etc/shells include autopkgsh? I want to use it as my login shell."
[10:52] <rbasak> pitti: OK, then multiple Parameters: lines for each parameterisation
[10:52] <rbasak> Anyway, yes, I agree it could get complicated.
[10:52] <pitti> rbasak: so Parameters-foo: a b
[10:52] <pitti> Parameters-bar: c d
[10:53] <pitti> TBH I don't find it clearer than a shell script that just does what it wants, and it has a lot more flexibility
[10:53] <pitti> debian/tests/foo
[10:53] <pitti> #!/bin/sh
[10:53] <rbasak> It just means that I have to clutter the directory with a ton of one-line wrappers
[10:53] <pitti> do-test `dpkg --print-architecture` bar $ADTTMP/xx
[10:53] <rbasak> I'd like to at least put those one liners into the control file somehow
[10:53] <pitti> rbasak: yeah, I think that's actually a better suggestion
[10:54] <pitti> rbasak: i. e. provide a syntax which puts the shell command to call directly into debian/tests/control
[10:54] <rbasak> That would certainly be significantly better.
[10:54] <pitti> Tests: "debian/tests/do-test foo"
[10:54] <rbasak> Right
[10:55] <pitti> and it's simple enough to be told apart
[10:56] <pitti> rbasak: now we can get into a long and deep argument about whether ".." or (..) or `..` quoting is better and clearer :)
[10:56] <rbasak> :)
[10:57] <rbasak> http://xkcd.com/1172/
[10:57]  * pitti votes for ⋑..⋐ which is very simiple to type, right?
[10:57] <rbasak> "My test had a " character in it and your new feature broke it"
[10:59] <pitti> rbasak: well, the definition thankfully excludes that already
[10:59] <pitti> Test names are separated by whitespace and should contain only
[10:59] <pitti>     characters which are legal in package names. It is permitted, but
[10:59] <pitti>     not encouraged, to use upper-case characters as well.
[10:59] <pitti> a lawyer would certainly read it as "anything goes", but we can turn this into "must only contain ... plus (discouraged) upper-case letters"
[11:00] <rbasak> RFC2119 section 3 :)
[11:01] <pitti> oh right, RFCs how to write RFCs
[14:48] <elopio> rpadovani: I'm sorry, we better wait for tomorrow because my branches on reminders have not landed.
[14:48] <elopio> I'll try to push them before EOD today.
[15:37]  * cgoldberg lolz at "spacebar heating"
[16:56] <gQuigs> are their not daily images of trusty?
[16:57] <elfy> not anymore
[16:58] <elfy> trusty is released
[17:00] <slickymasterWork> gQuigs: at the most you could get the source images containing the source code used to build Ubuntu
[17:00] <gQuigs> elfy: we still do daily images for precise: http://cdimage.ubuntu.com/precise/
[17:00] <slickymasterWork> gQuigs: http://cdimage.ubuntu.com/source/pending/source/
[17:00] <gQuigs> how else will we test the point releases?
[17:00] <elfy> gQuigs: good point
[17:01]  * elfy is in non lts mode already :)
[17:02] <elfy> balloons: what are the plans for Trusty dailies?