[02:48] <jbicha> pitti: argyll doesn't really need to recommend consolekit right?
[03:14] <RAOF> Yay unbumped SONAMEs.
[03:53] <pitti> Good morning
[03:53] <pitti> sil2100_: pong
[04:02] <Mirv> morning
[04:47] <pitti> robert_ancell: hey Robert, how are you?
[04:47] <robert_ancell> pitti,  hello
[04:48] <pitti> robert_ancell: I have a question about https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-lightdm/
[04:48] <pitti> robert_ancell: the package currently defines no tests (debian/tests/control is commented out), but has an XS-Testsuite: header
[04:49] <pitti> robert_ancell: do you plan to re-add/fix the autopkgtest soon? If not, could we drop XS-Testsuite: for now, to avoid the noise?
[04:49] <robert_ancell> pitti, I'm just fixing (hopefully) the last bug so the tests should work. The last but is due to your guest session wrapper patch :)
[04:49] <pitti> oh, sweet
[04:49] <pitti> robert_ancell: what's broken with that one?
[04:49] <robert_ancell> pitti, I don't know what the XS-Testsuite thing is supposed to do though
[04:50] <pitti> robert_ancell: it effectively signals jenkins "I have autopkgtests, please run me"
[04:50] <robert_ancell> pitti, it tries to run the wrapper from the installed location, but of course it's not installed at build time
[04:50] <robert_ancell> which = make check for autotools?
[04:50] <pitti> robert_ancell: err, autopkgtests are supposed to run the installed version
[04:50] <robert_ancell> no, I don't have any of those
[04:51] <pitti> robert_ancell: right, my question is about the autopkgtest, not the upstream test
[04:51] <pitti> i. e. not the "make check" one run during package build
[04:51] <robert_ancell> I don't know who added that line
[04:52] <robert_ancell> so feel free to remove it
[04:52] <pitti> there's also a debian/tests/control with commented-out tests
[04:52] <pitti> ok
[04:52] <pitti> robert_ancell: do you use a packaging branch, or just apt-get source or lp:ubuntu/lightdm ?
[04:52] <robert_ancell> the latter
[04:52] <pitti> ack, thanks
[04:53] <pitti> Packaging branch status: OUT-OF-DATE
[04:53] <robert_ancell> though for jenkins we are using lp:~lightdm-team/lightdm/trunk-packaging
[04:53] <robert_ancell> so not sure which one you are referring to there
[04:53] <pitti> well, whichever you use to do saucy uploads
[04:53] <robert_ancell> lp:ubuntu/lightdm
[04:53] <pitti> Most recent Ubuntu version: 1.7.0-0ubuntu4
[04:53] <pitti> Packaging branch version: 1.6.0-0ubuntu2.1
[04:54] <pitti> that's broken
[04:54] <pitti> so I guess apt-get source it is :)
[04:54] <robert_ancell> yeah
[04:54] <robert_ancell> where are you looking at that gives you that?
[04:55] <pitti> robert_ancell: "bzr branch ubuntu:lightdm"
[04:55] <robert_ancell> and that's different from lp:ubuntu/lightdm?
[04:56] <pitti> no, it's just a shorter alias
[04:56] <robert_ancell> isn't that supposed to automerge from dputs?
[04:56] <pitti> yes, but UDD is behind/broken really often :/
[04:56] <robert_ancell> ok
[04:56] <pitti> i. e. if people consistently use it and push first, then upload, it's fine of course
[04:57] <pitti> but the auto-imports are quite buggy
[04:57] <pitti> during my last sponsoring shift, about a third of them were out of date
[04:57] <pitti> robert_ancell: so do you mind if I do an upload to drop XS-Testsuite: ?
[04:57] <robert_ancell> nope
[04:57] <pitti> or are you going to do an upload soon anyway?
[04:59] <robert_ancell> not super soon
[04:59] <pitti> ok, done; thanks!
[05:03] <RAOF> pitti: Oh, colord 1.0.0 is going to wait until I know how the ABI break is going to be resolved.
[05:11] <pitti> RAOF: oh, changing ABI without bumping soname?
[05:11] <RAOF> Indeed.
[05:14] <didrocks> thanks pitti!
[05:14] <didrocks> and good morning :)
[05:14] <pitti> bonjour didrocks
[05:14] <pitti> didrocks: thanks for what?
[05:14] <didrocks> pitti: I'll retry a gdrive build once published
[05:15] <didrocks> the vala cherry-pick :)
[05:15] <pitti> oh, vala?
[05:15] <didrocks> oh, it FTBFS
[05:15] <pitti> this annoys me to no end
[05:15] <pitti> yeah, it was building fine in sbuild and locally
[05:15] <pitti> I uploaded https://launchpad.net/ubuntu/+source/vala-0.18/0.18.1-0ubuntu6
[05:15] <pitti> and now I see it fails again; wtf
[05:15] <didrocks> pitti: see mhr3's magic? He already did that to me!
[05:15] <pitti> I guess my file system has subsecond resolution, but the buildd's doesn't
[05:15] <didrocks> I see there is some magic on his patches :)
[05:16] <didrocks> pitti: do we build vala in parallel?
[05:16] <pitti> well, whenever we patch the .vala source, we also must patch the corresponding .c source and then ensure it is newer
[05:17] <pitti> right now the build on the buildd is trying to call vala to regenerate them
[05:17] <didrocks> pitti: yeah, I always ended up that way when having vala lenses
[05:17] <didrocks> patching both :/
[05:17] <pitti> why?
[05:17] <pitti> for vala lenses you should/could just have a valac build pde
[05:17] <pitti> dep
[05:17] <pitti> but for vala itself that's nasty
[05:18] <didrocks> pitti: I agree it shouldn't be needed, but in practice (warning, it was 3 years ago), the timestamp wasn't rechecked and we didn't get a reliable behavior to rebuild the .c files while patching a .vala file
[05:19] <pitti> right, same problem
[05:28] <pitti> vala-0.18 ubuntu7; third time's the charm!
[05:32] <didrocks> \o/
[05:46] <didrocks> pitti: great! as soon as it migrates to the release pocket, I'll trigger a gdrive rebuild
[05:46] <pitti> still waiting for arm to finish
[05:47] <Mirv> didrocks: are the automatic daily builds stopped btw and you're running stacks manually, or are things just delayed from the normal schedule?
[05:54] <didrocks> Mirv: yeah, see my email yesterday on ubuntu-devel, everything is in manual mode and daily release blocked
[05:54] <didrocks> Mirv: I want that we publish to saucy a known good state :)
[05:54] <didrocks> Mirv: btw, the ppa (apart from google drive scope) should be fine
[05:55] <didrocks> Mirv: mind updating from the daily-build ppa?
[05:55] <didrocks> the more testing we have, the better we'll be :)
[05:58] <Mirv> right, I read that, must re-read :)
[05:58]  * Mirv updates
[05:59] <didrocks> Mirv: thanks! restart your session if you can and yell if anything ugly happens :)
[05:59] <didrocks> Mirv: btw, I've relaunch the hud stack for your libcolumbus patch :)
[06:21] <jibel> good morning
[06:29] <didrocks> salut jibel, ça va?
[06:30] <jibel> salut didrocks , ça va et toi, bien reposé ?
[06:32] <didrocks> jibel: ça va bien, prêt pour aujourd'hui! ça s'annonce pas trop mal pour l'instant :)
[06:33] <jibel> didrocks, great, I reran OIF and indicators yesterady evening but indicators failed again
[06:33] <didrocks> jibel: yeah, but it's on the testing side
[06:33] <jibel> didrocks, yes
[06:34] <didrocks> jibel: I rerun indicators with videos to have a better view
[06:34] <didrocks> I rerun HUD as well, rebuild some components…
[06:34] <didrocks> we are really close!
[06:34] <didrocks> jibel: do you know why the container couldn't start?
[06:34] <Mirv> so far so good (daily-build)
[06:35] <didrocks> Mirv: have you restarted your session?
[06:35] <Mirv> didrocks: yes
[06:35] <didrocks> \o/
[06:35] <jibel> didrocks, because aufs directory didn't umount cleanly. It leaked 2 loop devices and broke the mountpoint rootfs/
[06:35] <didrocks> Mirv: let's continue crossing fingers! :)
[06:35] <didrocks> jibel: interesting, I noticed nothing in the previous run
[06:35] <jibel> didrocks, in that case the only solution is to create a new container or reboot the machine
[06:35] <didrocks> yep
[06:36] <didrocks> well, we have the setup job, so good enough IMHO if this reproduce again
[06:36] <jibel> didrocks, you can check if you're in this situation by simply doing an "ls  rootfs/" and it fails with a message like "Stale NFS filesystem"
[06:37] <didrocks> jibel: yeah, maybe we can try that as a first jenkins job step?
[06:37] <didrocks> and show an according message?
[06:55] <jibel> didrocks, yes, that's what I planned to do but I'd like to understand why it happens in the first place
[06:55] <didrocks> sure
[06:57] <pitti> RAOF: hm, is ssh://git.debian.org/git/collab-maint/colord.git still the correct VCS for colord?
[06:57] <pitti> RAOF: this has 0.1.31, I thought 1.0.x was in git already
[06:58] <pitti> RAOF: i. e. if I were to commit the autopkgtest fixes, where would I do that?
[06:58] <RAOF> pitti: Looks right, but I very definitely pushed 1.0.0 (but without any changelog) to alioth
[06:58] <pitti> ooh, no changelog
[06:58] <pitti> ack, thanks
[06:59] <pitti> and you already pushed the two autopkgtest fixes, thanks
[06:59] <pitti> although bf787c2417572bc2fb4a5502a5d09b6c0f2661b1 looks odd, that patches inline, not by debian/patches
[07:03] <pitti> RAOF: I took the liberty to fix the Depends: syntax (being collab-maint and a trivial patch)
[07:04] <RAOF> pitti: You're welcome.
[08:05] <Laney> hey
[08:15] <pitti> hey Laney, how are you?
[08:15] <pitti> valac-0.18 | 0.18.1-0ubuntu7 |         saucy | amd64, armhf, i386, powerpc
[08:15] <pitti> didrocks: ^ FYI
[08:16] <Laney> not so bad thanks pitti!
[08:16] <Laney> and yourself?
[08:16] <didrocks> pitti: yeah, we are already on it! Big thanks :)
[08:16]  * didrocks hugs pitti
[08:16] <didrocks> hey Laney!
[08:16]  * pitti hugs didrocks back
[08:16] <pitti> Laney: quite fine, thanks!
[08:16] <didrocks> ok, the other "urgency" crash has just been dealt
[08:16] <didrocks> just the gdrive scope one linked to this new vala is left to check :)
[08:16] <pitti> some minor bumps from yesterday's Taekwondo, but nothing serious
[08:46] <seb128> good morning desktoper (I was there earlier but I don't think I said hi ;-)
[08:53] <didrocks> seb128: you were slacking! admit it :-)
[08:53]  * didrocks hugs seb128
[08:59]  * seb128 hugs didrocks, you know me sir :p
[09:00] <didrocks> heh
[09:29] <didrocks> pitti: ok, something is weird, mhr3_ applied the patch himself manually and it worked for him
[09:29] <didrocks> mhr3_: you mean, the vala file is needed as well? I think pitti embeeded it in his first try
[09:29] <pitti> but not with the archive's vala package?
[09:30] <didrocks> pitti: yeah, we still get the segfault
[09:30] <didrocks> (with libunity rebuilt against it)
[09:30] <pitti> yes, ubuntu7 only ships the updated .c file, it doesn't apply the .vala patch
[09:30] <didrocks> pitti: maybe some parts are overwritten during the build process, I wonder
[09:30] <pitti> I tried that 5 times, it always FTBFSes on teh buildds
[09:30] <didrocks> pitti: I used to ship both
[09:30] <mhr3_> pitti, it needs both, scouring the buildlog shows it builds the from the .vala files too
[09:30] <mhr3_> after the compiler builds
[09:31] <pitti> didrocks: vala-0.18 doesn't have vala installed, so it can't update the .c file
[09:31] <pitti> ah, it does a two-pass build?
[09:31] <mhr3_> yep
[09:31] <didrocks> roh
[09:31] <didrocks> that's that's… horrible
[09:31] <pitti> hm, I guess then we need some kind of "sleep 1.5; touch girblabla.c" hack in debian/rules
[09:32] <mhr3_> that's a compiler :)
[09:32] <didrocks> pitti: IIRC, at some point, we made vala build-dep against vala (but not proud of it)
[09:32] <pitti> didrocks: well, it's standard practice to bootstrap compilers with itself
[09:32] <seb128> can't you build with valac 0.20?
[09:32] <pitti> didrocks: yes, that's what I was trying to avoid
[09:32] <seb128> is the bug fixed in that version?
[09:32] <pitti> ok, I'll re-add the .vala patches and instead touch the changed files in debian/rules
[09:32] <didrocks> pitti: sounds "good"
[09:33] <pitti> *grumle* *mumble* *effing unreproducible in sbuild* *mumble*
[09:33] <Laney> touch -t might be better than sleep?
[09:33] <seb128> what about using a newer vala?
[09:33] <Laney> or that ...
[09:33] <didrocks> seb128: not sure we want to pile up another transition on top of what we have TBH, but I guess it's more for mhr3_ to answer
[09:34] <Laney> I've been vaguely hoping to sync up with Debian on that; they default to 0.20 and removed 0.18
[09:34] <seb128> didrocks, that's not really a transition, if it builds with 0.20
[09:34] <Laney> but that's something which can be done later
[09:34] <mhr3_> seb128, no, there are other issues with 0.20
[09:34] <seb128> ok
[09:34] <seb128> ignore that then
[09:39] <mhr3_> pitti, quick test that the patching works - http://paste.ubuntu.com/5738265/
[09:39] <pitti> mhr3_: thanks, that's helpful
[09:41] <seb128> Laney, pitti: one of you on intel with the unity stack from saucy who can affort to close your session?
[09:41] <Laney> nvidia, sorry
[09:41] <seb128> Laney, pitti: starting software-center makes Xorg abort() here pretty regularly
[09:41] <pitti> yes/yes/can do
[09:41] <seb128> didrocks just confirmed
[09:41] <seb128> can you try if that happens to you as well?
[09:42] <Laney> mlankhost might be a better person to try that :P
[09:42] <pitti> anything I need to do in s-c?
[09:42] <Laney> with correct spelling
[09:42] <pitti> I started it 5 times without a problem, and clicked through the top buttons
[09:42] <seb128> Laney, I'm asking on #ubuntu-x as well
[09:42] <Laney> cool
[09:42] <seb128> pitti, no, just starting it there is enough, I get http://paste.ubuntu.com/5738268/
[09:43] <seb128> pitti, thanks for testing
[09:47] <seb128> bah, got it again, I can reproduce quite easy in a guest session
[09:47] <seb128> pitti, can you try to start a guest session, click on most of the icons in the launcher (s-c, u1, firefox) and use the unity dash with letting stuff open
[09:48] <seb128> like type "london" or something in the dash
[09:50] <pitti> (sec, doing vala testing)
[09:50] <seb128> pitti, no hurry
[09:50] <pitti> dput vala-0.18_0.18.1-0ubuntu8_source.changes
[09:50] <seb128> pitti, vala first, we need to unblock didrocks&co
[09:50] <pitti> mhr3_: ^ passes your test, thanks
[09:50] <pitti> now let's hope the "sleep 2; touch" trick is enough for our buildds
[09:53] <mhr3_> pitti, coolio, sil2100 ^ libunity needs to be built with that
[09:54] <didrocks> pitti: mind pushing it to the ubuntu-unity/daily-build ppa? (not sure you can though, I will just pick it, sign back and dput)
[09:55] <sil2100> mhr3_: what was the problem that it didn't work before?
[09:55] <mhr3_> sil2100, the patch wasn't really applied
[09:55] <pitti> didrocks: it's already building; shouldn't we let it build and then copy with binaries?
[09:55] <didrocks> will do that
[09:55] <pitti> didrocks: if you want to copy the source only, sure
[09:56] <sil2100> \o/
[09:56] <pitti> didrocks: is that much faster than just letting it publish in saucy?
[09:56] <didrocks> pitti: not sure, the migration to the release pocket delayed by one hour on the previous run
[09:57] <pitti> yes, the arm build missed the publisher by 4 minutes
[09:57] <didrocks> mhr3_: then, only libunity needs to be rebuilt, not all the scopes?
[09:57] <mhr3_> didrocks, right
[09:57] <pitti> let's see whether it builds on amd64/i386, and if so, you can copy it including the binaries?
[09:57] <mhr3_> didrocks, it affects just python, and that is dynamic enough :)
[09:58] <didrocks> pitti: yeah, I'll do that :)
[09:59] <didrocks> mhr3_: static building, no shared library seems the safest! :-)
[09:59] <mhr3_> but it's desrt's fault, he likes to change glib to throw crashes at us instead of nice warnings :P
[09:59] <pitti> F***! FTBFS
[09:59] <didrocks> it's always the fault of the desert :p
[09:59] <didrocks> argh
[10:00] <seb128> /bin/bash: valac: command not found
[10:00] <seb128> just make it build-depends on itself to get it to build?
[10:00] <pitti> seb128: I tried really hard to avoid that, but *shrug*
[10:01] <pitti> it's not like we have another architecture to bootstrap anytime soon
[10:01] <mhr3_> pitti, i guess patching the .vala invalidates the .c files
[10:01] <pitti> mhr3_: well, I patch the corresponding .c file also
[10:01] <mhr3_> you'd need to patch the .stamp file too
[10:01] <mhr3_> eh, touch
[10:02] <pitti> ./codegen/codegen.vala.stamp ?
[10:02] <mhr3_> yep
[10:05] <mhr3_> pitti, eh, ./codegen/valac.vala.stamp
[10:06] <mhr3_> damn
[10:06] <mhr3_> no, nevermind me
[10:06] <pitti> I don't have thaht
[10:06] <mhr3_> yours is correct
[10:06] <pitti> I did a find *.stamp
[10:06] <pitti> ok
[10:06] <pitti> local test build finished
[10:06] <mhr3_> compiler and codegen is too similar :)
[10:07] <pitti> local test success
[10:10] <pitti> seb128: I do notice some screen corruption every now and then though, particularly in firefox
[10:10] <pitti> https://launchpad.net/ubuntu/+source/vala-0.18/0.18.1-0ubuntu9, feed the hamsters
[10:10] <pitti> seb128: doing the guest session test now; what should I watch out for, crashes?
[10:11] <seb128> pitti, your session closing :p
[10:12] <pitti> hm, guest session doesn't even start
[10:12] <seb128> pitti, doing that Xorg abort() easily here
[10:12] <seb128> pitti, :-(
[10:12] <seb128> pitti, test user session?
[10:13] <pitti> lightdm doesn't seem to play along; let me reboot
[10:19] <pitti> seb128: confirmed, whoopsying ATM
[10:19] <pitti> uploaded
[10:19] <seb128> pitti, thanks
[10:19] <seb128> didrocks, ^ not the new unity stack then
[10:20] <pitti> didrocks: https://launchpad.net/ubuntu/+source/vala-0.18/0.18.1-0ubuntu9
[10:20] <didrocks> should we wait for the driver fix?
[10:20] <pitti> \o/
[10:20] <didrocks> pitti: \o/
[10:20]  * didrocks hugs pitti
[10:20] <pitti> didrocks: so feel free to copy whatever now
[10:20] <seb128> didrocks, no, the driver bug is already in saucy, I guess it's not that common if you don't use s-c
[10:20] <didrocks> pitti: yeah, doing that
[10:20] <didrocks> seb128: I didn't get it yet
[10:20] <didrocks> without s-c
[10:20] <davidcalle> pitti, didrocks, mhr3_ : issue fixed, segfault gone
[10:20] <seb128> same here
[10:21] <seb128> didrocks, and I'm building a test package with an -intel patch
[10:21] <seb128> didrocks, don't worry about that one, I'm handling it
[10:21] <didrocks> thanks seb128 :)
[10:21] <didrocks> davidcalle: great!
[10:21] <mhr3_> davidcalle, great, thx for testing, and thx pitti for fixing :)
[10:22] <davidcalle> sil2100 ^
[10:23] <pitti> mhr3_: no worries, thanks for the actual fix
[10:23] <seb128> pitti, why is that touch needed btw? wouldn't be listing the .c after the .vala in the patch be enough to have it updated after and have a newer timestamp?
[10:26] <pitti> seb128: yeah, I forgot to take it out; it's a leftover from the "sleep 2" that I added and now removed again
[10:26] <pitti> seb128: before that I thought the patches were applied too fast, and make didn't see the .c as newer than the .vala one
[10:29] <pitti> seb128: bug 1188123
[10:29] <ubot2`> Launchpad bug 1188123 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in OsAbort()" [Undecided,New] https://launchpad.net/bugs/1188123
[10:29] <pitti> (I just filed it)
[10:31] <seb128> pitti, thanks
[10:31] <seb128> tjaalton, mlankhorst: ^
[10:32] <seb128> tjaalton, ok, I backported the patch you pointed
[10:32] <seb128> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/src/sna/sna_accel.c?id=c4ad7b14ca71b95af83864b05793ea357f48bb88
[10:33] <seb128> with
[10:33] <seb128> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/src/sna/sna_accel.c?id=f6c35e58c1bb94ccfa04723db76d7164d5772f11
[10:33] <seb128> before
[10:33] <seb128> so the other one would apply
[10:33] <seb128> tjaalton, that seems to fix the issue ... do you want me to upload with those 2? or do you plan to update the driver later today anyway?
[10:33]  * pitti hugs seb128, our new X maintainer
[10:33] <seb128> nooooooo
[10:33] <tjaalton> seb128: thanks for testing, yeah we'll just push 2.21.9 once it's released
[10:33]  * seb128 runs away from pitti
[10:34] <seb128> pitti, following that logic Laney maintains libreoffice
[10:34] <seb128> I guess I can deal with -intel if that's the case :p
[10:34] <Laney> RM: libreoffice -- RoM: full of bees
[10:34] <seb128> ;-)
[10:35] <pitti> hm, apport retraced it, but the stack trace is worthless
[10:35] <pitti> (not really apport's faul this time)
[10:35] <pitti> https://launchpadlibrarian.net/141783460/Stacktrace.txt
[10:35] <seb128> Laney, speaking of packages long to build, I was going to look at the new webkit (seems like ricotz and jbicha got in ready in a ppa) ... or did you want to do that?
[10:35] <Laney> no, feel free
[10:35] <Laney> pochu was working on it in debian too
[10:36] <seb128> Laney, right, I think they worked together
[10:36] <seb128> I will throw it to the desktop team ppa for testing
[10:37] <mlankhorst> well, laney always looked like a libreoffice maintainer to me
[10:38] <seb128> pitti, no worry for the stacktrace, I got one locally and confirmed that it's fixed upstream by one of the commit the intel guys pointed as a potential fix
[10:38] <Laney> mlankhorst: :(
[10:38] <Laney> I use LaTeX for documents :P
[10:39] <pitti> Laney++
[10:40] <Laney> \o/
[10:41] <didrocks> I used LaTeX for books :-)
[10:41]  * seb128 used latex at school
[10:41] <seb128> didn't since
[10:42] <seb128> but I didn't really write documents since
[10:42] <didrocks> seb128: that's why you can't even spell it! :-)
[10:42] <didrocks> it's a shame :p
[10:42] <seb128> I mostly write emails and tomboy notes :p
[10:42] <seb128> didrocks, roh
[10:42]  * seb128 looks at the calendar, not friday yet!
[10:42] <didrocks> almost
[10:42] <didrocks> unity landing soon
[10:42] <didrocks> touch landing soon
[10:42] <didrocks> I'll consider then being on Friday :p
[10:43] <mlankhorst> seb128: work 4 days a week :D
[10:43] <seb128> didrocks, well, I guess if you count the work hours you did, it's saturday morning for you and you are still working :p
[10:43] <didrocks> seb128: yeah, maybe afternoon even! :)
[10:43] <didrocks> so I'll start working back on my Monday on Friday evening
[10:43] <didrocks> waow, the week-end went so fast! :)
[10:44] <seb128> ;-)
[10:45] <sil2100> \o/
[10:51] <mlankhorst> there's been enough proof that working >40 hours a week is counter productive though
[13:17] <desrt> mhr3_: what's my fault this time? :)
[13:17] <kenvandine> didrocks, good morning... have you noticed that gir1.2-dee-1.0 is broken?
[13:17] <kenvandine> i'm wondering if your latest commit to dee was an attempt to fix the gi.overrides
[13:17] <kenvandine> but even with your commit Dee.py is getting installed to the wrong place
[13:18] <seb128> Laney, pitti: did you get the evolution-calendar-factory segfault reported/debugged? seems like I get it as well
[13:21] <mhr3_> desrt, same old, same old, everything is :)
[13:21] <desrt> mhr3_: glad to hear, i guess
[13:22] <mhr3_> yesterday i saw the patch that moves the private data to the beginning.. scary stuff
[13:24] <pitti> seb128: reported, yes; debugged, no
[13:24] <pitti> bug 1154822
[13:24] <ubot2`> Launchpad bug 1154822 in evolution-data-server (Ubuntu) "evolution-calendar-factory crashed with SIGABRT: double free or corruption" [Medium,Confirmed] https://launchpad.net/bugs/1154822
[13:25]  * pitti back in 30 mins
[13:34] <seb128> pitti, ok, same issue here
[13:44] <tedg> seb128, Is there a way to turn of the UOA integration in Evolution?
[13:45] <seb128> tedg, ask mardy on #ubuntu-devel, he did that work
[13:45] <seb128> tedg, or at list looked at it
[13:46] <Laney> I suppose it would be possible to put that stuff in a separate package
[13:46] <tedg> K, I'm surprised it's not in the plugin list.
[13:46] <Laney> it needs to ship a desktop file for it
[14:01] <seb128> Laney, cyphermox, didrocks, ...: settings metting?
[14:01] <Laney> coming, 1s, need to fetch yubikey
[14:02] <cyphermox> yup
[14:23] <didrocks> Laney: argh, new glib :(
[14:23] <didrocks> Laney: and new deprecations
[14:23] <didrocks> dee is failing
[14:23] <didrocks> kenvandine: ^
[14:23] <kenvandine> sigh
[14:24] <didrocks> Laney: we should really coordinate when we have big landing to avoid that to happen and have more issues to fix
[14:24] <desrt> STOP USING -WERROR FOR DEPRECATIONS
[14:25] <seb128> didrocks, you guys .. what desrt said
[14:25] <didrocks> desrt: it's all your fault!
[14:25] <didrocks> seb128: well, tell that upstream
[14:25] <didrocks> not me
[14:25] <seb128> mhr3_, ^
[14:25] <didrocks> I'm just suffering from it
[14:25] <desrt> -Wno-error=deprecated-declarations
[14:25] <desrt> it's your friend
[14:25] <desrt> use it
[14:25] <Laney> indeed
[14:26] <kenvandine> the automake changes turned out to be what was killing me last week
[14:27] <didrocks> kenvandine: ahah :)
[14:29] <didrocks> kenvandine: hum
[14:29] <didrocks> interesting
[14:29] <mhr3_> seb128, easy fix, let's revert to stable glib :P
[14:29] <didrocks> building right now doesn't have python 3.3 directory
[14:29] <didrocks> mhr3_: +1
[14:29] <didrocks> but let's not start this discussion :p
[14:30] <didrocks> kenvandine: if you remove the 3.3 dir
[14:31] <didrocks> kenvandine: should be fine, right?
[14:31] <didrocks> as I'm seeing that we have only a python3 dir if I do rebuild locally
[14:31] <kenvandine> didrocks, when i rebuilt it locally it got installed in the 3.3 dir
[14:31] <kenvandine> at least it did last night :)
[14:31] <didrocks> interesting, not here
[14:32] <didrocks> kenvandine: let me give you a branch
[14:32] <kenvandine> i think that's the problem
[14:32] <kenvandine> all the others are in python3
[14:32] <kenvandine> and this one is going in python3.3
[14:32] <sil2100> mterry: ping
[14:32] <didrocks> kenvandine: lp:~didrocks/dee/move_override_3.3
[14:35] <kenvandine> mv: cannot stat ‘debian/tmp/usr/lib/python3.3/site-packages’: No such file or directory
[14:35] <kenvandine> sigh
[14:35] <kenvandine> last night it was putting it there...
[14:38] <didrocks> kenvandine: same here
[14:39] <didrocks> kenvandine: ok, let's remove it
[14:39] <mhr3_> seb128, and i was wrong, not even kazam works on saucy... yey
[14:39] <kenvandine> didrocks, ok... i think a rebuild of trunk with the deprecations change works now...
[14:39] <kenvandine> sigh
[14:39] <didrocks> kenvandine: yeah, I'm going to propose for review after rebuilding
[14:40] <kenvandine> thx
[14:44] <didrocks> kenvandine: https://code.launchpad.net/~didrocks/dee/move_override_3.3/+merge/167772
[14:44] <didrocks> kenvandine: I'll rebuild dee with this
[14:46] <kenvandine> i'm looking now
[14:47] <kenvandine> s/looking/trying
[14:47] <mhr3_> seb128, uh oh gsd crashed on standard raring :(
[14:47] <seb128> mhr3_, :-(
[14:50] <pitti> c'est l'heure du glace ! à bientôt
[14:52] <seb128> pitti, bonne glace
[15:25] <thotz> Hello Desktop-Team! Can anyone help me with bug #1153934. I don't know if the developers of gvfs have the full information and on the other side many people are affected by this bug since Ubuntu Raring and also in Saucy.
[15:25] <ubot2`> Launchpad bug 1153934 in gvfs "Some radio streams which used to play OK don't play after updating to rhythmbox 2.98 or higher due a gvfs bug" [Medium,Confirmed] https://launchpad.net/bugs/1153934
[15:29] <kenvandine> seb128, didrocks: tomorrow mardy is going to rename the settings panel for accounts, which is part of the settings stack.  after he does that i'll get the stack published in saucy
[15:29] <kenvandine> so probably late tomorrow
[15:29] <didrocks> ok :)
[15:29] <kenvandine> it's ready for saucy, just don't want to land a package that needs a rename
[15:30] <kenvandine> uoa-setup-touch is a terrible name...
[15:30] <thotz> someone from ubuntu-bugs told me to ask here.
[15:30] <seb128> kenvandine, great
[15:31] <kenvandine> didrocks, once your dee branch lands, mind if i kick off a build for just that in the unity stack?
[15:31] <kenvandine> once it is built in the PPA i should be able to get the friends CI builds to pass again
[15:32] <kenvandine> so we can merge Laney's eds branch... which is what has been holding up the stack
[15:32] <Laney> w00t
[15:32] <didrocks> kenvandine: I'll do it, no worry :)
[15:32] <kenvandine> didrocks, ok... thanks :)
[15:32] <kenvandine> can you ping me when you do?
[15:32] <didrocks> kenvandine: I'm playing a trick for having it running without having the full integration tests running
[15:33] <didrocks> kenvandine: sure
[15:33] <kenvandine> Laney, the good news is your branches passes with saucy... just now with the PPA :)
[15:33] <Laney> as long as it's not my fault :-)
[15:33] <kenvandine> didrocks, thanks... once that is done i should be able to get the friends stack unclogged
[15:33] <kenvandine> Laney, nope... it's all dee's fault :)
[15:34] <didrocks> great :)
[15:34] <didrocks> kenvandine: we are not going to publish it today though
[15:34] <didrocks> kenvandine: tomorrow morning (european time)
[15:38] <kenvandine> didrocks, that is fine, the stack works with what is in saucy, it's just the broken dee in daily-build breaks current CI
[15:38] <kenvandine> so all i care about the is the PPA for today :)
[15:39] <didrocks> kenvandine: ok :)
[15:53] <didrocks> kenvandine: dee building in the ppa!
[15:53] <kenvandine> didrocks, thanks
[15:53]  * kenvandine watches
[15:53] <kenvandine> actually... i'll go to lunch and assume it'll be done when i get back :)
[15:53]  * kenvandine waves
[15:55] <didrocks> heh
[15:55] <didrocks> kenvandine: enjoy!
[15:59] <Laney> what PPA is the system settings container app in?
[16:00] <didrocks> Laney: should be in the next ppa
[16:00] <didrocks> Laney: ~ubuntu-unity/next
[16:00] <Laney> didrocks: thanks
[16:03] <Laney> bah, saucy only
[16:03] <seb128> Laney, it's easy enough to build
[16:04] <seb128> Laney, bzr branch lp:ubuntu-system-settings
[16:04] <Laney> yeah, I did it on my desktop
[16:04] <seb128> bzr bd
[16:04] <Laney> less easy than a PPA though :P
[16:04] <seb128> right
[16:34] <didrocks> Laney: not using saucy?
[16:34] <Laney> not on the n7
[16:34] <didrocks> it's coming! :)
[16:34] <Laney> so I hear
[16:37] <Laney> then I'll report / work on these weird bugs :P
[16:37] <Laney> like searching for 't' in the applications lens launches a random icon
[16:37] <Laney> s/icon/app/
[16:38] <didrocks> Laney: because it guessed the one you wanted! :)
[16:38] <Laney> yeah I *totally* wanted the camera and not the terminal ;-)
[16:38] <didrocks> see… it works!
[16:39] <didrocks> it's a "recommendation" :)
[16:39] <Laney> ubuntu hacked my mind :o
[16:39] <didrocks> quick quick, a post on $random_blog
[16:39]  * Laney decides to do this on the desktop instead
[16:40] <Laney> poor old maliit is quite buggy there too
[16:42] <didrocks> cyphermox: btw, it seems the indicator stack on raring is stuck (libappindicator), did you ping anyone on soyuz to kill the build?
[16:42] <didrocks> cyphermox: and free the daily build job meanwhile :p
[16:43] <cyphermox> I did not, I'm still fighting this polkit mess with NM on the phone
[16:53] <pitti> didrocks: is that a PPA build, or distro builder? I can kill the former
[16:55] <didrocks> pitti: it's a distro builder
[17:03] <cyphermox> didrocks: build killed
[17:03] <didrocks> cyphermox: thanks!
[17:11] <noodle> can anyone tell me where to go to get help with Lucid Grub rescue unknown filesystem error after a update?
[17:20]  * didrocks waves good evening
[18:07] <kenvandine> Laney, can you please merge this branch into your eds branch and push it?
[18:07] <kenvandine> lp:~ken-vandine/friends/eds_libaccounts_update
[18:08] <kenvandine> now the merger is failing because of the libaccounts-glib vapi file rename...
[18:08] <kenvandine> i won't be able to get my branch through the merger because of the eds changes needed :)
[18:08] <kenvandine> so lets suck that into your branch and then the merger will work
[18:25] <Laney> kenvandine: ok, push0rized
[18:26] <kenvandine> Laney, thanks!
[18:41] <kenvandine> Laney, i don't know if the saying "going postal" means anything outside of the US... but i am about to go postal!
[18:41] <kenvandine> Laney, surely not your fault :)
[18:41] <kenvandine> getting shit merged has been killing me... for 2 weeks now... failures all over the place
[18:42] <kenvandine> so now your eds branch failed because it didn't like the dee version
[18:42] <kenvandine> or rather it had the broken dee version... which just simply shouldn't be the case...
[18:42] <kenvandine> grrr
[18:53] <bcurtiswx> going postal sounds western european.. im surprised it's US created
[18:57] <kenvandine> dude... the package built in the daily-build PPA has the same breakage as before didrock's fix
[19:02] <jbicha> kenvandine: does the daily build ppa build against -proposed ?
[19:03] <kenvandine> i was just looking at that :)
[19:03] <kenvandine> it doesn't
[19:03] <kenvandine> is there a fix for that site-packages dir in -proposed?
[19:04] <jbicha> perhaps https://launchpad.net/~ubuntu-unity/+archive/daily-build/+edit-dependencies
[19:07] <kenvandine> i'll see if that fixes dee
[19:07] <kenvandine> maybe python-defaults
[19:34] <kenvandine> jbicha, that made no difference... wtf
[19:36] <kenvandine> pbuilder build puts it in python3.3 dir too
[19:36] <kenvandine> humm
[19:39] <jbicha> kenvandine: no I didn't know of a fix in -proposed
[19:39] <kenvandine> jbicha, what do you have in /usr/lib/python3.3/site-packages/gi/overrides/
[19:40] <kenvandine> well, this can't just be something broken on my box... because it breaks the CI and autolanding too
[19:40] <kenvandine> the Dee override is just installed in the wrong place
[19:42] <jbicha> I don't have a /usr/lib/python3.3/site-packages/ but I get enough PPA fun out of the GNOME3 PPAs so I don't have Unity 7 here (until tomorrow :) )
[19:42] <kenvandine> i have to be losing my mind... a local build from lp:~didrocks/dee/move_override_3.3 works
[19:42] <kenvandine> it installs in /usr/lib/python3/dist-packages/gi/overrides/Dee.py
[19:42] <kenvandine> but a local build from trunk
[19:43] <kenvandine> puts it in /usr/lib/python3.3/site-packages/gi/overrides/
[19:43] <kenvandine> however... a bzr diff --old lp:dee
[19:43] <kenvandine> says they are the same
[19:43] <kenvandine> sigh...
[20:14] <jbicha> kenvandine: I get /usr/lib/python3.3/site-packages/ for both of those branches
[20:14] <kenvandine> i've figured it out
[20:14] <kenvandine> it needs build depends for python3-gi
[20:15] <kenvandine> the check for the overrides fails so it falls back to that
[20:18] <kenvandine> that was so annoying...  no idea why this wasn't broken before
[20:22] <kenvandine> ah, i know why it worked before
[20:22] <kenvandine> the fallback was correct before
[20:22] <kenvandine> now the fallback has changed
[20:22] <kenvandine> so it always failed... we were just lucky it worked :)
[20:32] <jbicha> kenvandine: what is autopilot-desktop? (from gnome-control-center-signon-autopilot)
[20:32] <kenvandine> the desktop version of autopilot
[20:32] <kenvandine> there is also autopilot-touch
[20:33] <kenvandine> for the touch apps
[20:34] <jbicha> oh I see, that's quite a changelog in the ppa for it