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