[00:10] <desrt> robert_ancell: gnome-calculator seems not to be building in jhbuild....
[00:11] <desrt> robert_ancell: presumably because it's taking the stable branch of vala but master of gnome-calculator
[00:33] <robert_ancell> desrt, I'm not maintaining that anymore
[00:33] <robert_ancell> desrt, but yeah, I think they're using bleeding edge vala
[04:55] <pitti> Good morning
[04:58] <pitti> Laney: I think the properties need to be added to the introspection XML for that, which doesn't currently happen (it's not trivial to do, at least when I tried last)
[04:58] <pitti> Laney: but it's a real issue indeed
[05:43] <pitti> Laney: some nitpicks in https://code.launchpad.net/~laney/ubuntu-system-settings/tests-mock-upower/+merge/198625
[07:04] <didrocks> hey robru, still awake?
[08:58] <ricotz> Laney, hello :), please take a look at accountsservice which is currently broken while the typelib is installed in the wrong place due the multiarching http://paste.debian.net/plain/70639
[09:02] <Laney> hey
[09:02] <Laney> ricotz: can you tell xnox?
[09:02] <Laney> pitti: I haxed the xml in Introspect() and it works correctly for properties with python types, but breaks when you add them over the dbus interface
[09:03] <Laney> & will look/address the issues you found, thanks
[09:03] <pitti> Laney: good morning
[09:03] <pitti> Laney: thanks
[09:03] <Laney> 'breaks' → they get 'v'
[09:03] <pitti> Laney: your upower template update is in sid, waiting for autosync
[09:03] <Laney> yay
[09:04] <Laney> oh, assert raises is nice!
[09:05] <Laney> the 'v' thing is probably due to the signature in AddMethod on the bus
[09:05] <Laney> guess_method(dbus.String('foo')) gives you 's', which is correct
[09:10] <pitti> Laney: I don't much like the testtools assertions, they are too verbose for my taste
[09:10] <pitti> but it seems they are autopilot style
[09:10] <pitti> Laney: standard unittest is self.assertRaises(FooError, function, arg1, arg2, ...)
[09:10] <pitti> (just FYI)
[09:10] <Laney> aha
[09:10] <Laney> I did look in the autopilot docs for something like that
[09:11] <pitti> it's testtools
[09:11] <Laney> yeah
[09:11] <Laney> got it
[09:11] <Laney> so, for this 'v' problem, I bet it would go away if we could unpack the variant by one level
[09:11] <pitti> I don't remember the details any more what was hard about adding dynamic properties to introspection
[09:12] <Laney> it might have been that dbus-python just doesn't do it?
[09:12] <seb128> good morning desktops, happy friday!
[09:12] <Laney> there's some patches that never got committed
[09:12] <Laney> hey seb128, happy friday to you
[09:15] <pitti> Laney: it also doesn't do it for methods AFAIR, dbusmock has to do that by itself
[09:15] <Laney> Yeah, there's something there that I didn't fully understand
[09:15] <pitti> Laney: but dbusmock knows the signature of methods
[09:15] <Laney> nod
[09:15] <pitti> bonjour seb128
[09:17] <seb128> pitti, salut, ça va ?
[09:19] <pitti> seb128: ça va bien, merci ! j'attends comment utiliser TRIM avec LVM :)
[09:19] <pitti> err, "j'apprends"
[09:19] <pitti> seb128: as-tu vu mon nouveau radio ?
[09:20] <seb128> pitti, oui, j'ai vu ça, original comme calendrier ;-)
[09:20] <pitti> ssssh -- "ma nouvelle radio"
[09:20] <pitti> (quoi est feminine dans une radio ???)
[09:21] <seb128> elle chante bien ?
[09:21] <seb128> ;-)
[09:23] <pitti> héhé
[09:25] <pitti> seb128: c'est un bon moyen à souvenier
[09:25] <pitti> souvenir
[09:58] <Mirv> didrocks: if you happen to time today, preNEW reviewing lp:properties-cpp would be welcome. no worries if not, I'll ask someone else.
[09:59] <didrocks> Mirv: I've already other NEWing, but will see if I have some time
[09:59] <didrocks> as you understood in the hangouts, it's really not the day ;)
[09:59] <Mirv> didrocks: no problem
[10:07] <seb128> didrocks, Mirv: I can review properties-cpp
[10:07] <didrocks> seb128: that will be a big help, thanks!
[10:07] <seb128> didrocks, yw ;-)
[10:10] <Mirv> seb128: thanks, great!
[10:10] <Mirv> it's pretty identical in packaging to process-cpp
[10:11] <Mirv> meanwhile, back to qt 5.2
[10:11] <Laney> phew
[10:11] <Laney> found a weird workaround
[10:11] <Laney> can haz mocked properties in introspection now
[10:12] <seb128> nice
[10:12] <seb128> Mirv, didrocks: I'm not going to be picky about that, but why do we put simple CMakeLists.txt we write under GPL when all the sources in the project are LGPL? would it make sense to use the license (or no license, those are simple build file)
[10:13] <didrocks> +1 on using the same license (so nothing written preferably)
[10:14] <Mirv> tvoss: can you answer that ^?
[10:15] <Mirv> I know the loaned cmake files elsewhere are GPL
[10:15] <seb128> Mirv, it's weird to have a "library" package not providing an actual lib
[10:15]  * seb128 wonders wth there ;-)
[10:16] <tvoss> Mirv, seb128 happy to remove licenses from the build files
[10:17] <tvoss> seb128, it's header-only, not sure how to name the package
[10:17] <seb128> tvoss, I guess lib is fine, from the descriptionI was expecting an actual lib/.so ;-)
[10:17] <tvoss> seb128, sure :) I might adjust that to header-only library
[10:17] <seb128> tvoss, thanks for the licences, it makes thing easier (if we have GPL sources otherwise we need to update copyright/ship the license, etc)
[10:18] <seb128> Mirv, tvoss: otherwise package looks fine for NEW
[10:18] <tvoss> seb128, ack, gimme a few and I will have an MP up
[10:18] <Mirv> seb128: ok, thanks for these I'll wait for tvoss's MP and continue then
[10:19] <Mirv> seb128: was it now that you could be also asked to refresh the whitelist of allowed packages to be copied from cu2d to archives? properties-cpp is already in the cu2d-config
[10:19] <Mirv> we need this again while did_rocks is away
[10:19] <seb128> Mirv, sure, can do that
[10:19] <Mirv> great!
[10:20] <seb128> Mirv, done
[10:20] <seb128> Mirv, did you try to build the package in a pbuilder/ppa yet?
[10:22] <Mirv> seb128: yes, built yesterdat https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3722961/+listing-archive-extra
[10:22] <seb128> Mirv, great, so I don't need to test that ;-)
[10:22] <seb128> thanks
[11:21] <pitti> Laney: ah, so I even had a disabled test case for that already
[11:21] <Laney> yup
[11:21] <pitti> Laney: many thanks for working on this! /me reviews
[11:21] <Laney> np, sorry for the weird workarounds
[11:24] <Laney> adding support for explicitly specifying the type would probably be decent to be able to avoid the guessing
[11:25] <pitti> Laney: yeah, but would break the API
[11:25] <pitti> or we need an AddPropertyType
[11:25] <pitti> (i. e. new method)
[11:25] <Laney> yep
[11:26] <Laney> I suppose one way around the type guessing thing would be to write our own function to do it that works with both dbus.foo and the python types
[11:26] <pitti> wrt. the branch, this reminds me that we don't have a test case for introspection of properties added in python
[11:26] <pitti> (this should already work, as you said)
[11:27] <Laney> with the XML adding thing, yeah
[11:30] <pitti> Laney: btw, https://launchpad.net/ubuntu/+source/python-dbusmock/0.9.2-1
[11:30] <pitti> that should unblock your MP?
[11:30] <pitti> Laney: you should bump the dbusmock dep there
[11:30] <Laney> oh yes, nice
[11:30] <Laney> will do
[11:34] <pitti> Laney: ah right, it can't guess signatures from empty dicts/arrays
[11:34] <Laney> yeah, something like that, I didn't fully analyse it
[11:36] <pitti> Laney: why the read-only? in the mock you can change all properties at any time
[11:36] <Laney> I semi-arbitrarily chose it because it's what your test-case was going to look for. ;-)
[11:36] <Laney> can fix both to be readwrite instead
[11:37] <pitti> Laney: can do during merging
[11:37] <Laney> ok
[11:37] <pitti> Laney: I change ET → ElementTree already anyway
[11:37] <Laney> nod
[11:37] <pitti> (hope it doesn't hurt your feelings :) )
[11:37] <Laney> nope, that's just a habit of mine
[11:37] <Laney> I think I picked it up from the docs
[11:40] <Laney> it amuses me to see autopilot's cursor get stuck on the pointer barrier for a bit
[11:44] <pitti> Laney: et voilà, d-feet now shows mock properties \o/
[11:44] <seb128> I wish autopilot tests were not that slow
[11:44] <seb128> the ~30 basic tests from u-s-s take already like 3 minutes
[11:45] <Laney> I'm sure it's not necessary to close and open the settings each time
[11:45] <seb128> which would be alright if running those was not blocking your computer
[11:45] <pitti> <jedi wave>use autopilot-sandbox-run --xephyr
[11:46] <seb128> learning every day ;-)
[11:46] <seb128> pitti, thanks for the trick, I didn't know that exists
[11:46]  * seb128 tries
[11:46] <pitti> by default it uses xvfb, which is nice for automatic tests during build etc.
[11:46] <Laney> oh neat, it does work
[11:46] <pitti> but with Xephyr you can see what's going on, but it's more isolated
[11:47] <Laney> ah, just needed to merge trunk for the hotplugging test
[11:47] <Laney> nice when things work
[11:47] <pitti> Laney: merged; how soon do you need this in trusty?
[11:47] <seb128> pitti, thanks for the trick, that's very useful ;-)
[11:48] <Laney> pitti: Well, I'm writing some tests which use it right now, but I don't necessarily have to get them in right away
[11:48] <Laney> thanks for merging :-)
[11:49] <Laney> it means that you can write tests which use QDbusInterface::property against dbusmocked interfaces
[11:52] <pitti> Laney: ok, let me know when you need  this uploaded; I'm working on some ofono template ATM
[11:52] <Laney> oh, yeah, I forgot - timedated templates coming up :P
[11:53] <Laney> so whenever you have a suitable batch of stuff
[11:54] <pitti> Laney: I just don't want to over-do the Debian uploads, and I like landing them in testing
[11:54] <pitti> urgency=medium helps a lot with that, though
[11:54] <Laney> sure, 5 days is fine
[11:55] <Laney> indeed, medium-by-default is quite nice
[11:55] <Laney> I actually forgot until I checked the pts
[12:00] <pitti> Laney: approved; can't top-approve, though
[12:00] <Laney> woot, thanks
[12:00] <Laney> seb128 can do that
[12:18] <seb128> Laney, pitti: done
[12:19] <Laney> merci
[12:20] <seb128> de rien ;-)
[14:05] <seb128> dpm, pitti: do you know how to debug/figure out why launchpad didn't import an updated template from a build?
[14:08] <pitti> I'm sorry, no
[14:11] <seb128> pitti, is the pot supposed to be collected on the buildds in the translations tarball?
[14:11] <seb128> same as the .po for langpacks ?
[14:11] <seb128> or is that a different process?
[14:12] <pitti> seb128: yes, it is; if the .pot is not built during packge build, it can't be imported
[14:12] <seb128> pitti, it's gtk+3.0 in that case and the pot is shipped with the source
[14:12] <seb128> yet https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports doesn't have the upload from this week
[14:13] <seb128> https://launchpadlibrarian.net/159463876/buildlog_ubuntu-trusty-i386.gtk%2B3.0_3.10.6-0ubuntu2_UPLOADING.txt.gz
[14:13] <seb128> pkgstriptranslations: no translation files, not creating tarball
[14:13] <seb128> ok
[14:14] <seb128> hum, no, wrong line
[14:15] <seb128> pkgstriptranslations: preparing translation tarball gtk+3.0_3.10.6-0ubuntu2_i386_translations.tar.gz...dpkg-distaddfile: warning: File::FcntlLock not available; using flock which is not NFS-safe
[14:15] <seb128> done
[14:15] <seb128> Publishing chroot-autobuild/build/buildd/gtk+3.0_3.10.6-0ubuntu2_i386_translations.tar.gz for rosetta.
[14:15] <seb128> so it seems that worked
[14:16] <seb128> but it doesn't tell us the content
[14:16] <seb128> pitti, do you know if I can download that file somewhere?
[14:17] <pitti> oh, it's not linked from soyuz?
[14:17] <pitti> hang on
[14:17] <seb128> oh, maybe, let me check
[14:17] <pitti> ah, seems not
[14:17] <seb128> https://launchpad.net/ubuntu/+source/gtk+3.0/3.10.6-0ubuntu2/+build/5323322 doesn't have it at least
[14:21] <pitti> >>> trusty = lp.distributions['ubuntu'].getSeries(name_or_version='trusty')
[14:21] <pitti> >>> list(trusty.getPackageUploads(custom_type='raw-translations-static', name='gtk+3.0'))
[14:21] <pitti> []
[14:21] <pitti> hmm
[14:21] <pitti> seb128: ah sorry, -static is for doc builds
[14:21] <seb128> that would explain it
[14:21] <Laney> hmm
[14:22] <Laney> dbusmock> can I use AddProperty to add properties whose values change?
[14:22] <Laney> e.g. timedated's Timezone property being updated by SetTimezone
[14:22] <pitti> Laney: yes, you can change any property at any time
[14:23] <Laney> pitti: http://paste.ubuntu.com/6566928/ what am I missing?
[14:23] <pitti> seb128: http://paste.ubuntu.com/6566929/
[14:24] <pitti> Laney: looks fine to me, what is wrong with that?
[14:25] <seb128> pitti, that has the pot :/
[14:26] <Laney> I just get the default back
[14:27] <seb128> pitti, thanks for the help, I pinged wgrant on #ubuntu-devel, seems like it could be a lp bug...
[14:27] <pitti> Laney: oh, of course
[14:28] <pitti> Laney: yes, mock.timezone isn't automagically considered the property value
[14:28] <pitti> Laney: i. e. AddProperty() doesn't do some kind of reference to it,it just takes the current value
[14:29] <pitti> Laney: so what you want to do in e. g. SetTimezone is self.Set()
[14:29] <Laney> ah, yeah, that's what I was after
[14:30] <Laney> yep, that works - thanks!
[14:31] <Laney> muhahaha, timedatectl believes my lies
[14:31] <seb128> ;-)
[14:31] <pitti> Laney: nice :)
[14:31] <seb128> pitti's tools are made of awesome ;-)
[14:31] <pitti> Laney: that's in fact the very tool you should use for the tests for that
[14:32] <Laney> yeah I was copying the logind tests
[14:32] <pitti> Laney: similarly, I use loginctl, upower, nm-cli etc.
[14:32] <pitti> right
[14:32] <Laney> next question will be if there's a way to mock changing the time
[14:32] <Laney> guess this one will be a bit more tricky
[14:32] <pitti> Laney: with timedatectl?
[14:33] <pitti> isn't that the very same?
[14:33] <pitti> Laney: you mean because tools don't usually ask timedatectl for the time, they just use it to set it?
[14:34] <Laney> Right, they use whatever time.h function or equivalent
[14:34] <pitti> LD_PRELOAD FTW :)
[14:34] <Laney> :-)
[14:35] <pitti> Laney: actually, apt-get install faketime
[14:35] <dpm> seb128, I'm not sure I can add more to that. When we used to have problems with imports, we generally checked first if the translations tarball contained the .pot locally https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/RecipeVerifyingTranslationUploads and then looked at the imports queue for the package if it did. If it's an LP bug, then yes, wgrant is the one who could help :/
[14:35] <Laney> ooh
[14:35] <desrt> happy troll^Wfriday!
[14:35] <Laney> I've not heard of faketime, exciting
[14:35] <seb128> dpm, thanks, see #ubuntu-devel
[14:35] <Laney> guess that will be useful
[14:35] <seb128> desrt, hey, happy friday!
[14:35] <pitti> Laney: similar hack as fake{root,chroot}
[14:35] <Laney> hey desrt
[14:35] <pitti> Laney: I've seen it being used in some tests
[14:35] <dpm> seb128, yeah, looking at the imports queue now
[14:36] <pitti> yo desrt, are you a paraskavedekatriaphobia ?
[14:36] <desrt> Laney: you think we're going to have packages in debian that allow you to pretend to be root and allow you to pretend to be fsync()ing but not allow you to lie to your programs about the time? :)
[14:36] <Laney> I hope it supports setting too
[14:36] <seb128> dpm, https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports you mean?
[14:36] <Laney> haha
[14:36] <seb128> dpm, it's also weird that this url doesn't like any of the po files for those uploads
[14:36] <Laney> how deep do the lies go?
[14:36] <desrt> pitti: you'll have to excuse me... i'm having difficulty parsing that on account of not being german
[14:36] <pitti> Laney: I think so far umockdev is the culmination :)
[14:37] <desrt> oh!  today is friday the 13th!
[14:37] <pitti> desrt: it's supposedly latinscienglish
[14:37] <Laney> laney@iota> fakeconsciousness am_i_alive && echo $?
[14:37] <Laney> 0
[14:37] <pitti> desrt: got it from http://owad.de/check.php4?id=3429&choice=5&sid=1371626 :)
[14:37] <desrt> pitti: but it's massively long and compound-wordy
[14:37]  * desrt was having difficulty determining the word boundries
[14:38] <pitti> like everyone else in the world
[15:26] <seb128> nice
[15:27] <seb128> gvfs upstream merged our/Debian changes to use a private library for backends rather than static linking in each binary
[15:27] <seb128> one less patch there ;-)
[15:27] <Laney> nice
[15:28] <pitti> niice!
[15:28] <seb128> seems there is a new maintainer as well
[15:28] <pitti> that always has been an icky one
[15:28] <seb128> quite some good work/bug fixes getting in
[15:28] <seb128> good for the LTS
[15:28] <seb128> he also improve the sftp copy performance by copying what openssh is doing
[15:28] <seb128> they have performance close from the command line with the new version
[15:29] <seb128> https://git.gnome.org/browse/gvfs/commit/?id=7890d2801a7f3998b336452fadc8ad0d01d06e60
[15:30] <pitti> sweeet
[15:34] <attente> is there an issue with fonts in plymouth recently? i only get rectangles for glyphs
[15:35] <seb128> attente, hey, somebody on #ubuntu-unity is pointed out what looks like a bug in u-g-m, http://sourceforge.net/p/geany/bugs/1013/
[15:35] <seb128> attente, is that known?
[15:35] <seb128> attente, basically eating "_" in menus (you can reproduce by opening an image in inkscape which has a "_" in its name)
[15:36] <seb128> attente, @plymouth: not that I know/have noticed, maybe a font issue? did you change you local/install-uninstall fonts?
[15:37] <attente> seb128, didn't notice that problem, sounds easy to fix
[15:37] <attente> haven't done anything special with the fonts, but plymouth changed dependencies from ttf-dejavu-core to fonts-dejavu-core
[15:37] <seb128> attente, I'm trying to get him to file a bug
[15:38] <seb128> attente, you might want to ask on #ubuntu-devel, slangasek&co might know better
[15:38] <seb128> https://launchpad.net/ubuntu/+source/plymouth/+bugs?orderby=-id&start=0 doesn't have any similar reports
[15:58] <seb128> shrug
[15:59] <seb128> new glib made libdbusmenu gtk2 tests unhappy
[16:00] <seb128> oh, another g_source_remove() fun
[16:00] <Laney> that change!
[16:03] <seb128> tedg, we need somebody to take https://bugs.launchpad.net/ubuntu/+source/libdbusmenu/+bug/1260779 I guess, would that be you?
[16:03] <ubot2> Launchpad bug 1260779 in libdbusmenu (Ubuntu) "Test issues in trusty (g_source_remove invalid use warnings), fails to build" [Undecided,New]
[16:04] <tedg> Uhm, sure.
[16:04] <seb128> tedg, thanks
[16:04] <tedg> We need to stop upgrading glib :-)
[16:04] <seb128> haha
[16:14] <seb128> attente, btw, did you get the osk to work on new versions? any news about enabling back those options Bill listed in his email?
[16:15] <attente> seb128, sorry, i'll get to it today
[16:15] <seb128> attente, no worry, I was mostly wondering if you tried again the osk/if your issues were resolved
[16:53] <seb128> attente, I've tried to make sense of the modifier-tweaks compiz merge request, but I don't have the motivation to read all the comments ... is MCReturn blocking stuff because he wants to fix the gsettings integration mess and ccsm and settings all together?
[16:54] <seb128> attente, or is there a practical issue with the changes?
[16:55] <attente> seb128, it's a lot of yak shaving, but there is one concern which i think is legitable
[16:55] <attente> *legitimate
[16:56] <westfale> 70
[16:56] <seb128> attente, I just commented asked him to not block fixes on "we need to fix the world or we don't land anything"
[16:56] <seb128> attente, which one?
[16:56] <attente> that we can't currently do something like "right control and left shift"
[16:57] <seb128> why not?
[16:57] <attente> because the merge only considers something like left shift with a control modifier pressed
[16:58] <attente> we need to consider extra state if we want to handle that case
[16:58] <attente> and we need to converge on a format for writing out such a shortcut
[16:59] <attente> because shortcuts currently only allow at most one keysym
[17:00] <seb128> ok
[17:00] <attente> i only wrote that MP with the intention of fixing the <Modifier>Mod_KeySym case
[17:00] <seb128> well, it seems like extra cases to handle later
[17:00] <attente> yeah
[17:00] <seb128> but the current changes should be an improvement and not create any new issue
[17:00] <seb128> so I think we should still get that in ;-)
[17:00] <seb128> anyway I commented on there saying that
[17:00] <seb128> let's see how it goes
[17:00] <attente> seb128, thanks :)
[17:00] <seb128> don't worry too much about it
[17:01] <seb128> if he's unreasonable, just put that on the side after holidays
[17:01] <attente> seb128, i'm trying to figure out a way to get it to work without that MP
[17:01] <seb128> ok...
[17:01] <seb128> well, don't spend too much efforts on finding workaround
[17:01] <seb128> if you think that mp is the right think, let's just convince him
[17:02] <attente> ok
[17:02] <attente> i don't want to antagonize him though because we will need more changes soon
[17:03] <seb128> right
[17:03] <seb128> let's be civilized but try to have him to agree than fixing one issue is better than fixing none
[17:03] <seb128> even if the fix is not perfect, we can iterate ;-)
[17:03] <attente> btw, did you see his comment about integrating ccsm into g-c-c/u-c-c?
[17:04] <seb128> yeah, that doesn't seem something we want to do
[17:05] <seb128> but I don't want an argument over it
[17:05] <seb128> just tell him to open a wishlist bug about it and that we would need to get design input
[18:02] <Laney> ok, off now
[18:02] <Laney> happy weekend and holidays if you're starting them now!
[18:18] <seb128> Laney, thanks, have a good w.e, good luck for next week! you can always drop me emails if there are issue, I might read a few next week (still not to book travel for the desktop week at least)
[18:44] <kenvandine> seb128, i'm heading out to lunch, in case i miss you... have a great holiday!
[18:44] <seb128> kenvandine, thanks, you too!
[18:45] <kenvandine> the sad part of this time of year... people go offline for too long :)
[18:45] <kenvandine> seb128, you'll be missed :)
[18:45] <seb128> kenvandine, I'm going to miss you guys as well
[18:45] <seb128> it's good that there is a week off for everyone in the middle
[18:46] <kenvandine> Laney, give me a shout if i don't respond quick enough to your merge proposals :)
[18:46] <seb128> I would really feel like out of the loop otherwise
[18:46] <kenvandine> seb128, indeed
[18:46]  * kenvandine waves, bbiab
[18:46] <seb128> bye!
[21:03] <Laney> oh crap, I forgot to review attente's one
[21:03] <Laney> SORRY!
[21:04] <attente> ?
[21:12] <Laney> was going to look at the language mp
[21:15] <attente> oh, no worries Laney
[21:15] <attente> it can wait till next week