[03:31] <pitti> Good morning
[06:06] <didrocks> good morning
[06:22] <pitti> bonjour didrocks, ca va?
[06:23] <didrocks> pitti: ça va bien, et toi?
[06:23] <pitti> je vais bien!
[06:24] <pitti> J'ai mange glace!
[06:24] <pitti> (last night -> ENOFRENCH)
[06:28] <didrocks> ahah, j'ai eu peur que ce soit ce matin :)
[06:29] <pitti> nah, c'est ne heure pour la glace
[08:10] <seb128> hey desktopers
[08:10] <robru_> Hi seb128! ;-)
[08:11] <pitti> bonjour seb128
[08:11] <seb128> robru_, pitti: hey, how are you?
[08:11] <seb128> pitti, danke for the support on the whoopsie email ;-)
[08:11] <robru_> I am great!
[08:11] <pitti> seb128: je vais bien, merci!
[08:11] <pitti> seb128: de rien
[08:11] <robru_> I heard your flight sucked. But you are home safe now?
[08:12] <pitti> hey robru_
[08:12] <robru_> hey pitti
[08:12] <seb128> robru_, mine was a bit long for a trip from France to Spain but mostly ok, didrocks's one sucked (he missed a connecting flight)
[08:13] <robru_> ahhhh
[08:14] <robru_> it's 3AM here. I can't sleep. What are you guys working on?
[08:15]  * pitti is fixing bug 1032062 ATM
[08:15] <ubot2> Launchpad bug 1032062 in bake "No way to specify .gir namespace version" [Medium,Triaged] https://launchpad.net/bugs/1032062
[08:18] <pitti> Mutt: =ubuntu/ [Msgs:0]
[08:18] <pitti> \o/
[08:18]  * pitti wants to have a clean plate for going to holidays
[08:18] <robru_> oh man, haven't used mutt in years! that's awesome.
[08:18] <pitti> well, I was primarily pointing at the zero messages there :)
[08:18] <robru_> that's cool too ;-)
[08:23] <didrocks> salut seb128
[08:24] <seb128> didrocks, salut, ca va bien, et toi ?
[08:24] <didrocks> seb128: ça va bien :)
[08:24] <seb128> robru_, I'm still catching up on things that happened during GUADEC and I'm looking at some updates
[08:24] <didrocks> the hangout was surprisingly interesting like the one yesterday
[08:24] <seb128> didrocks, great!
[08:24] <didrocks> really happy about the feedback, good and solid material for the future :)
[08:25] <seb128> \o/
[08:25] <seb128> didrocks, will you summarize the feedback somewhere?
[08:27] <seb128> pitti, btw, njpatel fixed unity, it was sending dbus signal with a destination set and using them from another place, the eavedropping changes blocked that
[08:27] <seb128> pitti, so it means new dbus should be ready for upload rsn
[08:27] <pitti> seb128: yeah, I saw, great! so time to upload dbus?
[08:28] <seb128> pitti, I will upload to quantal-proposed in a bit
[08:28] <seb128> (using proposed in case there are any issue, I want a small round of feedback from there first)
[08:30] <didrocks> seb128: yeah, I'll write session notes on a wiki page and write a blog post to link to them
[08:30] <seb128> cool
[08:57] <pitti> org.gtk.vfs.MountTracker.listMountableInfo call failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "ListMountableInfo" with signature "" on interface "org.gtk.vfs.MountTracker" doesn't exist
[08:57] <pitti> new gvfs? I see this a lot since today
[09:07] <MCR1> Hi smspillaz :)
[09:11] <seb128> pitti, yes, it sucks a bit, restart your session (or gvfs)
[09:11] <pitti> aah
[09:12] <pitti> thanks
[09:12] <seb128> pitti, gvfs went from libdbus to gdbus
[09:12] <seb128> pitti, so restart of the service required
[09:12] <pitti> gone now, thanks
[09:12] <seb128> pitti, yw
[09:12] <seb128> not sure how to handle properly those...
[09:13] <pitti> no biggie
[09:14] <seb128> dpm, pitti: hey, do you know if there is another langpack update rounds planned before 12.04.1?
[09:14] <pitti> yes, dpm kindly agreed to rolling it
[09:14] <seb128> great
[09:14] <dpm> seb128, yeah, I started building the langpacks yesterday as planned, but I was blocked by a langpack bug
[09:15] <dpm> will resume today now that it's been fixed
[09:15]  * pitti hugs dpm
[09:15] <dpm> hey pitti :)
[09:15] <seb128> dpm, no worry, I'm asking because somebody sent an email to the translators list asking, they have a bug in greek langpacks causing nautilus to segfault
[09:16] <dpm> seb128, I'll have to investigate, then. I requested the LP export on Tuesday, and unless it's been fixed before that, it might be that the bug is still present
[09:17] <seb128> dpm, the bug suggests they fixed it on july 11
[09:18] <seb128> dpm, so it should be good
[09:18] <dpm> ah, cool
[09:18] <dpm> let me reply to him
[09:18] <seb128> thanks
[09:20] <seb128> brb, testing a lightdm update
[09:25] <mlankhorst> https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport/+packages fear
[09:26] <jokerdino> hey guys. i am in need of some help here..
[09:30] <jokerdino> i am trying to submit a bzr merge proposal to fix bug #771375 and i am failing miserably
[09:30] <ubot2> Launchpad bug 771375 in gnome-games "No Unity QuickList for gnomine" [Wishlist,Confirmed] https://launchpad.net/bugs/771375
[09:34] <jokerdino> i have submitted a bzr branch at https://code.launchpad.net/~barneedhar/gnome-games/ubuntu but i know it shouldn't be there. any help is much appreciated.
[10:20] <Sweetshark> seb128: IIRC correctly I send a mail to devel yesterday wrt to bug 1017125 with you in cc. did that one get lost in the tubes? Icant find it anymore.
[10:20] <ubot2> Launchpad bug 1017125 in df-libreoffice "LibreOffice crash in xmloff.Impress.XMLContentImporter::com::sun::star::document::XImporter" [Medium,Confirmed] https://launchpad.net/bugs/1017125
[10:22] <seb128> Sweetshark, I received it, but it seems -devel didn't ... maybe it's stucked in moderation? are you subscribed to the list?
[10:23] <Sweetshark> seb128: i just recently subscribed (right along with sending, so yeah, its in moderation).
[10:23] <Sweetshark> seb128: thanks.
[10:24] <seb128> Sweetshark, yw
[10:24] <didrocks> pitti: did you get how the bake test-runner is showing the verbose output without calling bake --verbose?
[10:25] <didrocks> pitti: I'm currently getting an issue when something shown in bake --verbose is not captured when running the global tests (and so the "expected" file is making the test failing)
[10:25] <pitti> didrocks: I don't know the magic for that, no
[10:26] <pitti> I'm calling bake --verbose, copy it into expected, and edit it there (it doesn't match 100%)
[10:26] <didrocks> yeah, it doesn't, that's my surprise
[10:26] <didrocks> and before it was showing something that it doesn't anymore
[10:29]  * thumper sighs
[10:29] <thumper> seb128: managed to get an awesome hard crash
[10:29] <seb128> thumper, oh?
[10:30] <thumper> seb128: google plus was calling me for new hangout, I went up to the sound indicator to mute it, got a repeating ring, no mouse or keyboard input, no vt switch, nothing
[10:32] <seb128> :-(
[10:33] <thumper> power button down for 5s :)
[10:46] <didrocks> oh
[10:46] <didrocks> I think I start to understand how this works
[10:46] <didrocks> if so, that will make the python3 support for bake way more work than expected
[10:48] <didrocks> \o/
[10:48] <didrocks> that's it!
[10:49] <pitti> didrocks: oh?
[10:51] <didrocks> pitti: yeah, so apart that python3 isn't supported (as bake only ships .pyc file in the same directory), in fact, when running the tests, python is even not called
[10:51] <didrocks> you have a fake python tool in test/src/python.vala
[10:51] <didrocks> which generates a python binary
[10:52] <didrocks> this one is called when using the test-runner for python
[10:52] <didrocks> and they both connect to a socket (the test-runner and the python fake tool)
[10:52] <didrocks> and it's that content which is checked for accurate matching
[10:52] <didrocks> nothing that bake is providing itself
[10:53] <didrocks> so I just created a python2.7 one generated from the same python.vala source
[10:53] <didrocks> as I added support for specifying a python version to bake
[10:53] <pitti> oh
[10:53] <didrocks> but for python3, I need to recreate another fake wrapper, which ships the compiled file in another directory (the pycache one)
[10:53] <pitti> I wonder why it has all these fakes
[10:54] <didrocks> I think he wants to totally isolate bake from the system
[10:54] <didrocks> which makes sense, if the system stays stable
[10:54] <didrocks> (otherwise tests can pass, but in production, this can fail)
[10:54] <didrocks> happy to have understand how his tests are working at least :)
[10:54] <didrocks> was scratching my head
[10:55] <didrocks> so basically bake was calling a script which didn't exist (python2.7)
[10:55] <didrocks> and it seems he doesn't fail
[10:55] <pitti> oh, that explains why g-ir-scanner keeps failing
[10:55] <didrocks> only the test catch it because the next output is not the expected one
[10:55] <pitti> yeah, same here; I'm fighting with that currently
[10:55] <pitti> baking my test manually works just fine
[10:55] <didrocks> I had exactly the same issue :)
[10:56] <didrocks> everything worked fine, even in the /tmp/ dir created by the bake test runner
[10:56] <didrocks> so you will need to provide a fake object I guess
[10:56] <pitti> yeah
[10:56] <dupondje> Hmz just noticing something here. An apport crash message doesn't seem to have an "entry" in gnome-shell. So if you switch to another window, you lose the message (untill you close all other screens).
[11:00] <pitti> it's a popup, not an application
[11:00] <pitti> you should be able to alt+tab to it, though?
[11:01] <didrocks> ok, time to run now that this mystery is solved. I'll try to add python3 support this afternoon (and ship .py files no matter what ;))
[11:01] <pitti> in unity it has a launcher icon, so it ought to appear in the running programs under shell somewhere
[11:18] <pitti> didrocks: yep, added g-ir-{scanner,compiler} dummies in my branch now; works fine
[11:32] <pitti> didrocks: do you have an opinion on https://bugs.launchpad.net/bake/+bug/1032062/comments/8 ?
[11:32] <ubot2> Ubuntu bug 1032062 in bake "No way to specify .gir namespace version" [Medium,Triaged]
[11:32] <pitti> didrocks: (just ignore me if you are not interested in the .c/.vala parts)
[11:34]  * pitti will stop on that now and revisit after holidays
[11:35] <robru> sorry for OT spam, but can I get some hardware recommendations here? I'm in the market for a new laptop and I want one that will work with only free drivers.
[11:35] <robru> the ubuntu certified hardware list I am finding very overwhelming.
[11:35] <pitti> robru: make sure it's got an intel wifi and intel or amd graphics
[11:36] <pitti> the rest doesn't matter driver-wise, and you can pick what you like
[11:36] <robru> oh, is that all? the certified hardware seems like it's full of crazy exceptions and maybes.
[11:39] <pitti> by and large yes; there might certainly be some quirks with webcams and such, of course
[11:40] <robru> webcams I am less concerned about. I *need* something that I can surf the web on with a default install and no special drivers, so that means working graphics and working network at least. so sick of installing ubuntu and having to plug in internet in order to install wireless drivers.
[11:42] <robru> oh, and what if I want to buy one that doesn't come with windows preinstalled? is that hopeless?
[11:44] <mlankhorst> system76 offers some
[11:45] <pitti> robru: FWIW, broadcom wifi (the proprietary driver) is supported OOTB if you click that checkbox in the installer
[11:46] <robru> oh, hmmmm. I had bad luck with that recently.
[11:46] <robru> it worked for a bit, but the signal was weak. I had to plug in the wired ethernet and then dist-upgrade and then reboot and then it started working properly. dunno. sick of broadcom in general.
[11:47] <seb128> system76 are nice
[11:47] <seb128> and they support ubuntu
[11:47] <seb128> pitti, didrocks, others: feel like trying dbus 1.6 from quantal-proposed and reboot at some point today? I would like an extra confirmation before copying it to quantal
[11:47] <pitti> sure
[11:47] <didrocks> seb128: ok, let's be crazy!
[11:48] <seb128> thanks ;-)
[11:48] <didrocks> pitti: just back from my shower/run. having a look
[11:48] <pitti> didrocks: not urgent, of course; this is all "play" :)
[11:56] <didrocks> pitti: hum, I don't really get in which case you need to separate the "|version" and "|soversion" and if we need, why we shouldn't base all include, pkgconfig, vapi on soversion rather?
[11:57] <pitti> because nobody does that
[11:57] <pitti> if include, pkgconfig etc. are versioned at all, it's usually by some notion of major series, not soname
[11:57] <pitti> soname tracks abi incompatibilities, not major series
[11:58] <didrocks> but shouldn't bake just require you have a new major serie everytime you break the ABI?
[11:58] <pitti> no, why?
[11:58] <pitti> it should require you to bump the soname
[11:58] <pitti> (well, it cannot really detect that, of course)
[11:59] <didrocks> but that would mean that the .so file just contains the soversion, not the version as it's already the case today?
[11:59] <pitti> oh, it could/would also contain the series
[11:59] <pitti> i. e. libfoo-1.0.so.5
[11:59] <pitti> if version is 1.0
[11:59] <pitti> and if you don't specify a version, just a soversion, it's libfoo.so.5
[11:59] <didrocks> ok, so some kind of clutter-like versionning
[12:00] <didrocks> for typelib, I guess that the ABI compatibility is done in the path with girepository-1.0
[12:00] <pitti> clutter|gtk|udev|qt|atk|libusb|... like
[12:00] <didrocks> and so it's just about the API, so the major version
[12:01] <pitti> kinda, yes; the .gir/.typelib specifies which library it is linked against
[12:01] <didrocks> so, in practice:
[12:02] <pitti> which is why e. g. gir1.2-gtk-3.0 links to libgtk-3-0 (>= 3.5.8)
[12:02] <didrocks> - I fix a bug in my lib without touching any interface: -> same version, same soname
[12:02] <didrocks> - I fix a bug but this one is breaking the abi -> same version, different soname
[12:02] <pitti> if gtk would bump ABI, it would become libgtk-3-1 (not that this would ever happen for gtk, but it does happen for other libs)
[12:03] <didrocks> ok, so this works that way :)
[12:03] <didrocks> - I add an API, but don't break the ABI -> same version, same soname (?)
[12:03] <didrocks> - I remove an API -> differrent version, different soname
[12:04] <pitti> right
[12:04] <pitti> the last one should happen rarely, though
[12:04] <pitti> e. g. for gtk 2 -> gtk 3
[12:04] <didrocks> yeah, version here is a major version
[12:04] <pitti> we probably should call it "series", not "version"
[12:04] <didrocks> right
[12:05] <didrocks> because if you add an API, you will need to bump version, and so same serie, same soname
[12:05] <didrocks> to require the right lib
[12:05] <didrocks> google scripts don't have a system of serie/soname
[12:05] <didrocks> they are just using one number
[12:05] <didrocks> if your new lib is compatible with the older one, keep the same
[12:05] <didrocks> if not, bump the number
[12:06] <pitti> didrocks: no, if you add API/ABI you don't need to bump anything
[12:06] <didrocks> but they only provide one version of the lib at any given time for each number
[12:06] <pitti> the minor soname version perhaps
[12:06] <pitti> s/perhaps/for sure/, sorry
[12:06] <pitti> but not the soname
[12:06] <didrocks> yeah, sorry, my wording wasn't clear but I intended that
[12:07] <didrocks> ok, I think that should be clear enough with that system then
[12:07] <didrocks> just providing clear example with the above cases would be good I think for developers ^
[12:07] <didrocks> like "I add an API, blablabla…"
[12:10] <didrocks> pitti: oh btw, did you try to add any string in a python module and build it with bake?
[12:10] <didrocks> I get an ENCODING failure
[12:11] <didrocks> and the tests, as not using the real object, can't really marshall it
[12:11] <pitti> didrocks: no, I didn't play with python projects yet
[12:11] <pitti> rebooting with dbus 1.6.4, brb
[12:14] <pitti> seb128: boot, graphics, device ACLs, sound, udisks, indicators, unity all working well with dbus 1.6.4
[12:15] <seb128> pitti, \o/, thanks for testing!
[12:15] <pitti> SHIP IT!
[12:15] <seb128> ;-)
[12:15] <seb128> yes sir! ;-)
[12:18]  * didrocks adds -proposed now
[12:19] <didrocks> pitti: ok, seems that python3 doesn't support at all just showing the .pyc without the source
[12:19] <didrocks> so I think that this idea of only shipping those is doomed to fail :)
[12:19] <pitti> didrocks: oh, I wasn't aware of this; but anyway, I think it's doomed anyway
[12:20] <pitti> didrocks: as usually you want to not depend on a particular python version
[12:20] <didrocks> I read that this morning: http://www.python.org/dev/peps/pep-3147/
[12:20] <didrocks> indeed
[12:20] <pitti> e. g. python 3.6 might change the .pyc format or so
[12:20] <didrocks> it's a different files on python3
[12:20] <didrocks> so you can still ship a compiled for a particular version
[12:21] <didrocks> the magic number (36 for 3.6) is encoded in the pyc filename
[12:22] <didrocks> ok, rebooting with newer dbus
[12:25] <didrocks> seb128: life sounds good!
[12:25] <seb128> didrocks, \o/
[12:25] <seb128> ok, that makes it work for 3 people, and tested on i386 and amd64 so I guess all good to copy
[12:25] <seb128> didrocks, pitti: thanks
[12:26] <didrocks> yw :)
[12:26] <didrocks> ok, let's continue some bakeries with python3 :)
[12:27] <pitti> didrocks: right, let's DoS Robert with patches and branches when he's back!
[12:29] <didrocks> \o/
[12:48] <didrocks> pitti: seems to me that bake doesn't really show the generated makefile on --expand
[12:48] <didrocks> pitti: like, for a python project, you get this: http://paste.ubuntu.com/1127010/
[12:49] <didrocks> but the last "test.pyc" target override the 2 previous ones a traditional makefile (just made a trial)
[12:51] <pitti> right; it's valid to have several dependency stanzas, but only one may have commands
[12:52] <didrocks> yeah, I think he doesn't generate this makefile in the end :)
[13:27] <seb128> kenvandine, hey, do you have any clue how to test geoclue? robert_ancell did the update to the new version but didn't upload because he was unsure how to test
[13:29] <kenvandine> seb128, i can't recall actually
[13:30] <kenvandine> there was a new version!
[13:30] <kenvandine> wow
[13:30] <kenvandine> there is a gui of some sort that lets you poke at stuff
[13:31] <seb128> kenvandine, I guess I will try with the indicator-datetime, with a test user, not have my current tz and see if it adds it to the locations
[13:31] <pitti> can we wrap whatever call it uses to determine the current IP address (fake ifconfig or so) and test it that way?
[13:31] <kenvandine> that assumes the indicator works :)
[13:32] <kenvandine> geoclue-examples
[13:32] <kenvandine> there is a test client in that package
[13:32] <seb128> pitti, you rather want to determine your location
[13:32] <seb128> kenvandine, thanks, let me try that
[13:35] <didrocks> ok, python3 support for bake here \o/
[13:36] <seb128> didrocks, well done!
[13:38]  * pitti hugs didrocks
[13:39] <didrocks> still have to write the test with the mock python lib though ;)
[13:44] <kenvandine> yay... i fixed the libunity-webapps tests, we can now enable them in the package build
[13:44] <kenvandine> MIR coming soon!
[13:48] <seb128> kenvandine, ;-)
[14:05] <pitti> time to end the day and start my two weeks of holiday
[14:05] <pitti> see you all in two weeks
[14:05] <pitti> have a nice weekend everyone
[14:07] <didrocks> bye bye pitti, enjoy (just for the form, even if he won't read it ;))
[14:55] <thumper> seb128: ping
[14:56] <seb128> thumper, hey
[14:56] <thumper> seb128: hey hey...
[14:56] <thumper> seb128: I hear you aren't too keen about unity 5.16 sru in 12.04.1
[14:56] <seb128> thumper, well, 12.04.1 freeze was yesterday...
[14:57] <seb128> thumper, it's not me, it's the calendar not playing in your favor
[14:57] <thumper> poop
[14:57] <thumper> seb128: so we'll just have to get it in asap after?
[14:57] <seb128> thumper, and it seems like a change that we would want to land in advance of the freeze line since it needs careful testing
[14:57] <thumper> seb128: we have some people waiting :)
[14:57] <seb128> thumper, yes, I don't feel comfortable rushing it
[14:57] <thumper> yes, I agree it needs careful testing
[14:57] <thumper> ok, I agree not to rush
[14:58] <thumper> we do what we can do
[14:58] <seb128> thumper, we can put it in a ppa for 2 weeks and then move it to precise-proposed
[14:58] <thumper> okie dokie
[15:02] <didrocks> thumper: seb128: maybe put it in -proposed a little bit later?
[15:02] <didrocks> as in case something bad is happening for .1, we maybe want to get a newer unity in -proposed which isn't 5.16
[15:53] <desrt> thumper: hey.  any word on that crasher in dconf?
[15:53] <desrt> did the patch fix it?
[15:57] <seb128> desrt, I asked him earlier, he said he didn't talk to the QA guys this week, he has been travelling for a ps sprint
[15:58] <desrt> nod.
[16:16] <didrocks> seb128: you wanted to read the notes from the hangout, I just put them on the wiki: https://wiki.ubuntu.com/Quickly/Reboot
[16:17] <seb128> didrocks, oh, great, thanks
[16:17] <didrocks> yw ;)
[16:59] <dpm> seb128, quick question if you're around. I've built and uploaded the 12.04.1 language packs as per pitti's instructions. However, I'm not sure whether there is any additional step to be done before they land in precise-proposed. The last thing I did was to run the script to upload the packages (here: http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/view/head:/doc/operator-guide.txt#L123 and here:http://bazaar.launchpad.net/~ubuntu-la
[16:59] <dpm> ngpack/langpack-o-matic/main/view/head:/packages ), but I can't figure out whether the upload was successful or where I can see whether the packages are being uploaded or not. Any ideas?
[16:59] <seb128> dpm, https://launchpad.net/ubuntu/precise/+queue?queue_state=1 suggests it worked
[17:01] <dpm> seb128, ah, cool. So I understand they are unapproved and I should get someone to approve them before they land in -proposed?
[17:01] <seb128> dpm, yes
[17:01] <seb128> dpm, try asking on #ubuntu-release
[17:02] <dpm> will do, thanks seb128 ;)
[17:02] <seb128> yw
[17:05] <ricotz> seb128, hi
[17:05] <seb128> hey ricotz, how are you?
[17:05] <ricotz> do you have a moment to sponsor this http://paste.debian.net/plain/181931
[17:06] <ricotz> i am fine, thank you
[17:06] <ricotz> seb128, how are you?
[17:06] <seb128> I'm good thanks
[17:08] <seb128> ricotz, uploaded
[17:09] <ricotz> seb128, thanks!
[17:09] <seb128> thank you for the fix!
[17:12] <didrocks> time for week-end! Enjoy everyone and see you on Monday ;)
[17:12] <dpm> have a nice one didrocks
[17:12] <didrocks> thanks, you too dpm :)
[17:58] <MCR1> bschaefer: Hi :) How can I speed up my fix for font-manager ?: https://code.launchpad.net/~mc-return/font-manager/font-manager.fix-961034/+merge/114991
[18:00] <bschaefer> MCR1, hmm it has to be merged by Jerry sooo im not sure :(
[18:01] <bschaefer> maybe sending a email, but there is no auto merger for the font manager as far as I know
[18:02] <MCR1> bschaefer: ok, thx - it is just that this bug bugs me since 10.04... ;)
[18:02] <bschaefer> MCR1, haha, well hopefully itll get merged soon!
[18:03] <MCR1> bschaefer: If Jerry is my man, I am happy as he reviewed it - I guess he'll merge it some time before 12.10 comes out...
[18:05] <bschaefer> MCR1, its his project from a quick glance sooo it would seem that way. (not sure his IRC name though...)
[18:06] <MCR1> bschaefer: Another question - I want to help speed up booting of Ubuntu for 12.10 - who is the best one to discuss my ideas with ?
[18:07] <bschaefer> MCR1, hmm Im not 100% sure, i've seen it discussed before in the channel but not sure who the go to person is :(
[18:07] <bschaefer> in this*
[18:08] <MCR1> bschaefer: ok, thx a lot. Sooner or later I'll find out.