[06:05] <pitti> Good morning
[06:50] <didrocks> good morning!
[07:12] <pitti> ça va didrocks, comment vas-tu ?
[07:15] <didrocks> pitti: ça va bien, et toi ?
[07:16] <pitti> je vais bien aussi
[07:17] <didrocks> pitti: do you plan to go to the systemd hackfest?
[07:17] <didrocks> (at FOSDEM)
[07:17] <pitti> didrocks: yes, I do
[07:17] <pitti> you too?
[07:18] <didrocks> pitti: yeah :)
[07:18] <didrocks> pitti: I'm eager to add the topic about how to handle all our use-cases with presets, but I'm afraid for that to be quite late for vivid
[07:19] <pitti> didrocks: that's ok, I think; we can do that for jessie+1/vivid+1
[07:19] <didrocks> pitti: meaning that our first implementation with purge/remove and so on would be broken, right?
[07:19] <didrocks> I'm unsure how much bad press that would have, probably less for us than for jessie (and it's too late for jessie)
[07:20] <pitti> didrocks: most probably none at all -- nobody complained about it in Debian so far
[07:20] <didrocks> ok then :)
[07:20]  * didrocks subscribed to the event and will add the topic
[08:23] <mlankhorst> morning
[08:29] <seb128> good morning desktopers
[08:29] <didrocks> hey mlankhorst, seb128
[08:31] <pitti> bonjour seb128
[08:31] <pitti> hey mlankhorst
[08:32] <seb128> hey didrocks pitti mlankhorst
[08:33] <mlankhorst> g'day
[08:40] <didrocks> pitti: is there a simple way to rerun some tests when adt-run failed? (I want to have the same environment wrapper to have the PPID magic when rebooting the vm
[08:40] <didrocks> pitti: I sshed into the env
[08:41] <pitti> didrocks: you used -s?
[08:41] <didrocks> yeah
[08:41] <pitti> didrocks: adt-run shows you the directory where the package is in the testbed (/tmp/adt-run.XXXX/...)
[08:41] <pitti> didrocks: cd there, and call debian/tests/foo (perhaps with sudo if the test needs root)
[08:42] <didrocks> pitti: ok, no wrapper needed, nothing magic?
[08:42] <didrocks> (even for reboots)
[08:43] <didrocks> I'm asking because it doesn't seem that the call for rebooting the testbed works when directly executing like in sudo python3 debian/tests/display-managers
[08:44] <pitti> didrocks: if your test needs $ADTTMP, you need to set that; but that's about the only thing
[08:44] <pitti> didrocks: it should
[08:44] <didrocks> or maybe 'autopkgtest-reboot boot-systemd' only works under upstart?
[08:44] <pitti> didrocks: oh wait -- rebooting kills your ssh session, of course
[08:44] <pitti> didrocks: no, it works under any init
[08:45] <didrocks> pitti: well, it doesn't do anything, like if it ignored the subprocess call
[08:45] <pitti> didrocks: ah right, sorry
[08:45] <didrocks> and run all the tests, but without rebooting in between (only when I sshed to it, working well under adt-run)
[08:45] <pitti> didrocks: so yes, manually running a test like this with reboot isn't going to work
[08:45] <didrocks> ah ;)
[08:45] <pitti> didrocks: what you can do is to reboot, and call your test with ADT_REBOOT_MARK=whatever
[08:46] <pitti> didrocks: that's the same effect as what adt-run does
[08:46] <pitti> didrocks: I mean autopkgtest-reboot
[08:46] <pitti> didrocks: so run your test, reboot manually, re-run with ADT_REBOOT_MARK=whatever
[08:46] <didrocks> pitti: well, the reboot is in the middle of the tests, so not going to work
[08:46] <didrocks> as I prepared the test setup
[08:46] <didrocks> reboot
[08:46] <pitti> didrocks: autopkgtest-reboot will at least kill the test at the right time
[08:46] <didrocks> and check status
[08:47] <pitti> didrocks: otherwise, it seems way easier to just comment out all other tests from debian/tests/control and run with adt-run
[08:47] <didrocks> pitti: but rebooting during one test isn't supported from what you told? (even with adt-run)
[08:48] <pitti> didrocks: sure it is, that's the whole point of it
[08:48] <pitti> didrocks: it's just tricker to do if you run a test manually
[08:48] <pitti> didrocks: so, what happens:
[08:48] <pitti> - test gets started
[08:48] <pitti> - test calls autopkgtest-reboot; that SIGKILLs its parent (i. e. your test)
[08:49] <didrocks> yeah
[08:49] <pitti> - [*] adt-run sees that the test was killed, and that there is a reboot marker set
[08:49] <pitti> - [*] adt-run reboots the test bed and re-runs the test with ADT_REBOOT_MARK=whatever
[08:49] <pitti> - your test starts again, checks $ADT_REBOOT_MARK and resumes at the right place
[08:49] <pitti> didrocks: if you run a test manually, you need to do the steps [*] manually
[08:49] <pitti> didrocks: i. e. reboot, and re-run test with ADT_REBOOT_MARK set
[08:50] <didrocks> pitti: will be a little bit harder as I'm rebooting inside some unittests tests (not sure what you use as a terminology for this)
[08:50] <didrocks> so basically, I have
[08:50] <didrocks> class FooTests:
[08:50] <didrocks>     def test_1(self):
[08:50] <didrocks>        doing some stuff
[08:50] <didrocks>        reboot()
[08:50] <didrocks>        check
[08:50] <didrocks> same for def test_2(selfà…
[08:50] <pitti> didrocks: yeah, I guess you can't use the simple unittest.main(), but might need to load individual classes depending on where you are in the reboot state
[08:50] <pitti> didrocks: alternatively you can skip the whole class with
[08:51] <pitti> @unittest.skipUnless(os.environ.get('ADT_REBOOT_MARK') == 'stage3')
[08:51] <meetingology> pitti: Error: "unittest.skipUnless(os.environ.get('ADT_REBOOT_MARK')" is not a valid command.
[08:51] <pitti> oh, shut up meetingology :)
[08:51] <didrocks> ahah :)
[08:51] <pitti> didrocks: or your main() needs to look like
[08:51] <didrocks> pitti: I wonder if then, it's not cleanup/more effective to investigate in nsspawn?
[08:51] <didrocks> s/cleanup/more clean/
[08:52] <pitti> if 'ADT_REBOOT_MARK' not in os.environ:
[08:52] <pitti>    # run initial tests/setup
[08:52] <didrocks> yeah, I see what you mean :)
[08:52] <pitti> elif os.environ['ADT_REBOOT_MARK'] == 'stage1':
[08:52] <pitti>    # run stage 1 tests
[08:52] <pitti> elif os.environ['ADT_REBOOT_MARK'] == 'stage2':
[08:52] <pitti>    # run stage 2 tests
[08:52] <pitti> etc.
[08:53] <pitti> didrocks: maybe, but I thought you wanted to have a full end-to-end test
[08:53] <didrocks> pitti: actually, I'm starting to fake the dm services in the end
[08:53] <pitti> didrocks: note that you can also split your test into multiple .py files, and the "master" test script just runs the right one according to the reboot mark
[08:53] <didrocks> pitti: because we want to test the service (eventually created from sysvinit) state
[08:53] <didrocks> pitti: not the dm scripts which are going to change
[08:54] <didrocks> yeah, the thing is that I will have ~10 of them
[08:56] <pitti> didrocks: oh, I thought you wanted to install three DMs and check that they behave as expected
[08:56] <pitti> i. e. end-to-end test
[08:57] <didrocks> pitti: there are multiple combinations, like one systemd dm, multiple systemd dms, one init-only dm, one init + one systemd dm and different /etc/X11/d-d-m states
[08:58] <pitti> didrocks: they would reflect as different test cases then? either autopkgtest tests, or unittest tests; the former takes longer but is isolated, the latter also checks that purging a DM works right and is fater
[08:58] <pitti> faster
[08:59] <didrocks> pitti: I was thinking implementing them thanks to an unittest class, piloting those scenarios (to avoid code duplication between multiple tests)
[08:59] <didrocks> as 90% is just about "dropping some files, reboot, check systemd state"
[09:04] <pitti> didrocks: if you don't actually install DMs, do you actually need to reboot?
[09:04] <pitti> didrocks: instead of just re-running the generators and checking the results?
[09:05] <didrocks> pitti: I'm checking the active unit state (as it's really what matters from systemd side), that means I need systemd to boot to that target
[09:06] <pitti> didrocks: ah, ok; so reboot ladder then?
[09:06] <pitti> ifelse ladder or @unittest.skipUnless
[09:07] <didrocks> pitti: I can maybe systemctl isolate default.target?
[09:07] <pitti> I don't know what that does
[09:08] <didrocks> it's equivalent to systemctl default, meaning: "build the default job transaction" (as during boot) and stop everything that isn't part of it
[09:41] <didrocks> hum, isolate doesn't enable to restart ssh from adt-run, that's weird…
[09:48] <didrocks> pitti: I wonder if there is any magic in the way you are starting ssh from the testbed? ^
[09:49] <pitti> didrocks: how do you mean?
[09:49] <pitti> didrocks: unless you build-depend on it, ssh isn't even guaranteed to be installed
[09:49] <pitti> didrocks: I think it is for our cloud VMs, but adt isn't using that
[09:49] <pitti> err, test-depend, not build-depend
[09:49] <didrocks> pitti: I think isolate default is killing the ssh that you start up so that we can access to it with -s
[09:50] <didrocks> daemon*
[09:50] <pitti> didrocks: aah, that
[09:50] <pitti> didrocks: well, then don't use ssh, use minicom or netcat (although their terms suck a lot for doing actual work)
[09:50] <pitti> but at least it should be enough to bring ssh back up
[09:50] <didrocks> pitti: yeah, will do that then, not trying to restart it myself :)
[09:51] <pitti> didrocks: btw, how is it easier/more efficient to run with -s and manually start the test 5 times than just using adt-run?
[09:52] <pitti> didrocks: if you comment out all other tests, and perhaps build a VM with your test deps already pre-installed (so that you don't have to wait for apt for long), it seems a lot easier to just run the whole thing?
[09:52] <pitti> rebooting should take 20 s or os
[09:52] <pitti> "so"
[09:52] <didrocks> pitti: I already commented all other tests a long time ago :)
[09:52] <didrocks> pitti: it's just to look at the FHS status isn't the one I expected
[09:53] <didrocks> if*
[09:53] <didrocks> minicom is enough anyway for that
[11:21] <willcooke> urgh
[11:21] <willcooke> That took a lot longer than I expected.
[11:21] <willcooke> Only just got to London
[13:11] <desrt> good morning linux distribution desktop environment team chat room
[13:12] <larsu> good morning software library maintainer
[13:12] <seb128> hey desrt
[13:13] <desrt> hi hi
[13:15] <didrocks> good morning desrt!
[13:17] <desrt> seems like a slow morning :)
[13:24] <larsu> desrt: how can mardy take a ref on an unowned hash table in vala
[13:25] <desrt> create a non-unowned version of the variable and assign it
[13:25] <larsu> he says that throws an error
[13:25] <desrt> that seems curious.
[13:25] <larsu> error: Reference transfer not supported for this  expression
[13:25] <desrt> ?!
[13:25] <larsu> ya...
[13:25] <desrt> there's something else wrong there
[13:26] <larsu> probably. He says it's no big deal, he was just wondering if we have a quick solution
[13:26] <larsu> (and I don't)
[13:26] <desrt> is he getting the generics right?
[13:26] <desrt> 'show me the code'?
[13:27] <larsu> don't have it
[13:27] <larsu> should work in a return, no=?
[13:28] <desrt> show him this as an example of something that works: http://ur1.ca/iza0d
[13:28] <larsu> ok
[13:28] <larsu> thanks
[13:28]  * desrt loves this broken telephone game :)
[13:28]  * larsu doesn't
[13:29] <larsu> desrt: did you check whether it calls g_hash_table_ref()
[13:29] <desrt> it does
[13:29] <desrt> here's the C: http://ur1.ca/iza0o
[13:29] <desrt> (warning to children and the faint of heart: don't look)
[13:29] <larsu> err, why?
[13:29] <larsu> it's not _that_ bas
[13:29] <larsu> *bad
[13:30] <desrt> it's pretty ugly :)
[13:30] <larsu> hm, you mean it would be cool if vala spat out code that could have been written by a human?
[13:31] <larsu> I don't see what purpose that would serve
[13:31] <larsu> other than easier debugging, mybe
[13:31] <larsu> I wonder why it needs the ref0 version
[13:31] <desrt> porting to C when you eventually get pissed off with vala :)
[13:31] <larsu> haha. Which you will eventually
[13:35] <mardy> larsu, desrt: that worked, thanks (declaring a local HashTable)
[13:36] <larsu> mardy: hm? I thought you tried that before?
[13:36] <larsu> in any case, nice that it works now :)
[14:41] <tedg> larsu, desrt, can we have a "dbus_escape_string" or some such in GLib to avoid cut-and-pasting code to do it around?
[14:42] <tedg> Or worse, people rewriting it.
[14:43] <larsu> tedg: yes, I've been meaning to write one for a while
[14:43] <larsu> for object paths, you mean, right?
[14:45] <tedg> Yeah, just to handle the dbus naming requirements.
[14:45] <tedg> And the matching unescape of course.
[14:45] <larsu> yep
[14:45] <tedg> I think that I've personally written it once for GLib, once for std::string and once for QString.
[14:46] <tedg> Because… it's so much fun…
[14:46] <larsu> \o/
[14:46]  * tedg does it for the LOLs
[14:51] <mardy> desrt: hi! in Vala, given a Variant of type a{sv}, is there any shorter way to get a string out of it, than data.lookup_value("key", null).get_string()?
[15:00] <desrt> yes
[15:01] <desrt> you can '.lookup_value ("key", null) as string'
[15:01] <desrt> or you can, if it is more convenient, do:
[15:01] <desrt> string x;
[15:01] <desrt> .lookup ("key", "s", out x);
[15:02] <desrt> there is not anything like data["key"] if that's what you mean
[15:09] <mardy> desrt: yes, I was looking for that, or at least for a way to not specify the VariantType (the GLib method accepts null there, so I hoped that there was a way to avoid passing anything at all, in Vala)
[15:10] <desrt> ah.  right.
[15:10] <desrt> the lookup ("key", "s", out  ...) thing is your best approach then
[15:10] <desrt> returns boolean if successful (and you have a string) or false otherwise
[15:11] <desrt> the trouble is that you don't know what type of thing might be in that dictionary, so you really do need to check it...
[15:12] <desrt> (the APIs strongly suggest the recommended convention of treating an existing-but-wrongly-typed value as if it was missing)
[15:17] <mardy> seb128: I attached a branch to bug 1382843, with an updated 06_uoa.patch which should fix the issue
[15:17] <mardy> seb128: I tested it with Facebook, Flickr and Picasa
[16:26] <seb128> mardy, great, thanks for looking at that one! I can upload that and take care of the SRUs ;-)
[16:45] <sil2100> Hey! Does anyone know if Didier will be around today still?
[16:55] <willcooke> sil2100, I think he had an appointment this afternoon - probably wont be back until tomorrow.  Probably just email him?
[16:56] <sil2100> willcooke: hey, we had an emergency, but we were able to sort it out with the help of #webops
[16:56] <sil2100> Thanks for the info!
[16:56] <willcooke> ah cool
[16:57] <willcooke> no worries sil2100
[18:01]  * willcooke -> Train
[19:36] <Noskcaj> seb128, The lintian change was from lp:ubuntu/ to lp:~ubuntu-desktop/ it mustn't have been added when the bzr was most recently updated
[19:53] <seb128> Noskcaj, k