[02:45] <bitplane> Hi, is this the correct place for all UX queries / bug discussion?
[02:46] <bitplane> including gnome and the theme, or just Unity itself?
[05:39] <hyperair> is there a way to programmatically pop open indicator menus?
[05:39] <hyperair> (short of patching unity-panel-service or similar)
[06:44] <maxiaojun> What's the future plan of Ubuntu's CJKV inputting stack?
[07:14] <maxiaojun> anyone?
[07:18] <tsdgeos> maxiaojun: just ask, don't ask to ask
[07:19] <maxiaojun> What's the future plan of Ubuntu's CJKV inputting stack?
[07:20] <tsdgeos> Saviq: paulliu: ↑↑ ?
[07:23] <paulliu> maxiaojun: Hi.
[07:23] <maxiaojun> hi
[07:52] <Saviq> maxiaojun, hey, did you get your answer?
[08:04] <maxiaojun> Thank you, I'm talking with paulliu
[08:19] <Saviq> ooh storage...
[08:19]  * Saviq just got 2x4TB drives to stop thing complaining about ENOSPC
[08:20]  * Saviq loves the sound of the delivery man in the morning :F
[08:23] <tsdgeos> :D
[08:41] <seb128> Trevinho, hey
[09:02] <Saviq> mhr3, what was the resolution of the hud vs. libunity vs. valac issue, btw?
[09:03] <mhr3> Saviq, broken version of valac was in the archive yesterday, got fixed
[09:04] <Saviq> mhr3, so in theory I should just upgrade valac-0.18 and should be fine?
[09:04] <mhr3> Saviq, yep, you can now
[09:04] <seb128> Trevinho, the ping was about https://bugs.launchpad.net/bamf/+bug/1188518
[09:04] <Saviq> mhr3, 0.18.1-0ubuntu9, right?
[09:04] <mhr3> Saviq, indeed, ubuntu7 was broken
[09:05] <sil2100> Mirv: ping :)
[09:05] <mhr3> didrocks, any update on status of pushing to S?
[09:06] <didrocks> mhr3: we got some issues due to intrusive changes at the last minute
[09:06] <didrocks> mhr3: tests are rerunning with the revert
[09:06] <didrocks> (upstart session for unity-panel-service and bamf changes)
[09:07] <mhr3> didrocks, i see, keep me posted pls
[09:07] <didrocks> all tests were failing, and even dogfooding, we are getting a bunch of segfault
[09:07] <sil2100> uuuh
[09:07] <didrocks> mhr3: right now, the revert seems to work, unity tests are still running
[09:08] <Mirv> sil2100: pong
[09:09] <mhr3> wow, notify-osd crashed on S, haven't seen that for quite a while
[09:10] <Saviq> mhr3, yeah, had that once or twice on S already
[09:10] <Saviq> and apport doesn't send bug reports for me :/
[09:10] <mhr3> works for others - https://errors.ubuntu.com/?release=Ubuntu%2013.10&package=notify-osd&period=day
[09:11] <mhr3> MacSlow, ^
[09:29] <didrocks> mhr3: indicators and unity passed, starting publishing in a few
[09:32] <didrocks> mhr3: thanks for your fix btw :)
[09:32] <didrocks> sil2100: FYI ^
[09:32] <didrocks> Mirv: ^
[09:34] <mhr3> didrocks, kinda embarassing that we didn't notice it :/
[09:34] <didrocks> mhr3: well, I'm more embarassed with the intrusive changes that were taken with it TBH
[09:34] <didrocks> (the upstart change)
[09:35] <sil2100> Passed ;p ?
[09:35] <didrocks> yep :)
[09:35]  * sil2100 only saw an aborted build
[09:35] <sil2100> ;)
[09:35] <didrocks> sil2100: right, that's my fault, I pushed the wrong button :p
[09:35] <didrocks> sil2100: but tests are fine
[09:36] <sil2100> \o/
[09:36] <sil2100> didrocks: awesome! Thanks ;)
[09:36] <mhr3> didrocks, btw releasing on friday, are we this confident in the testing stack these days? :)
[09:36] <didrocks> apps published
[09:36] <didrocks> hud published
[09:36] <sil2100> ;p
[09:36] <didrocks> mhr3: I am ;)
[09:36] <sil2100> mhr3: we have no other choice!
[09:36] <didrocks> mhr3: see, it got the bamf segfault!
[09:37] <mhr3> didrocks, let's see on monday what it didn't get :)
[09:37] <didrocks> mhr3: quite true :)
[09:37] <didrocks> sil2100: unity_gtk_module tests are failing btw
[09:37] <didrocks> sil2100: you will check that with attente?
[09:38] <sil2100> didrocks: yes, I saw those
[09:38] <sil2100> didrocks: will do that once he starts his day
[09:38] <didrocks> thanks :)
[09:39] <didrocks> indicators published
[09:41] <didrocks> media stack published
[09:42] <didrocks> oif published
[09:43] <didrocks> platform stack published
[09:46] <didrocks> qa stack published
[09:46] <sil2100> \o/
[09:46]  * sil2100 waits for unity
[09:46] <davidcalle> *the ground shakes*
[09:48] <didrocks> sdk stack published
[09:50] <nic-doffay> Saviq, trying to run on device after the new changes, getting this: ./run: 56: ./run: ./builddir/unity8: not found
[09:50] <Saviq> nic-doffay, means it didn't build
[09:51] <nic-doffay> Saviq, both build -s and build completed
[09:51] <Saviq> nic-doffay, yeah, that doesn't mean they built fine
[09:51] <Saviq> nic-doffay, I'm doing some tweaks to the scripts now
[09:51] <Saviq> nic-doffay, to have better errors
[09:52] <Saviq> nic-doffay, but verify that ./build went fine
[09:52] <Saviq> nic-doffay, and pastebin the log if not
[09:52] <nic-doffay> Saviq, it's fine from here.
[09:53] <Saviq> nic-doffay, what does `make -C builddir` say/
[09:53] <Saviq> nic-doffay, might want to try ./build --clean
[09:57] <Saviq> greyback, you resubmitting the wm refactor and test? or am I?
[09:57] <greyback> Saviq: 1 test is failing somehow, I need to fix it
[09:57] <Saviq> greyback, ok
[09:58] <greyback> I sweat the f***er worked 2 days agao
[09:58] <greyback> swear even
[10:00] <Saviq> mhr3, nic-doffay and how did you make HUD to build with valac-0.18?
[10:00] <didrocks> and unity stack finally published \o/
[10:00] <mhr3> Saviq, builds fine with ubuntu9
[10:00] <nic-doffay> Saviq, an update sorted that out.
[10:01] <mhr3> Saviq, maybe you have some leftover from previous build?
[10:01] <mhr3> leftover == the .gir file
[10:01] <Saviq> mhr3, nope, I scrapped the whole build dir
[10:01] <sil2100> \o/
[10:01] <sil2100> I think we need someone to modify the topic ;)
[10:01] <didrocks> now, NEW machinery and promoition
[10:01] <didrocks> sil2100: far from being done :p
[10:01] <mhr3> Saviq, we saw yesterday with nic-doffay that that isn't enough in some cases
[10:02] <sil2100> I jump out for a moment, brb
[10:02] <Saviq> mhr3, ah, wrong
[10:02] <Saviq> mhr3, that's people lens that's not building
[10:02] <Saviq> mhr3, it complains about Gee
[10:03] <mhr3> ah, yea, can be, we're getting rid of it anyway, aren't we?
[10:03] <nic-doffay> hmm Saviq build didn't complete this time.
[10:03] <mhr3> but now that you mention it, there's a patch for the issue with gee
[10:03] <Saviq> mhr3, I can has?
[10:03] <mhr3> Saviq, https://code.launchpad.net/~mhr3/libunity/clean-up-deps/+merge/160085
[10:03] <Saviq> mhr3, thanks
[10:03] <mhr3> Saviq, feel free to +1, pstolowski is holidaying today
[10:04] <Saviq> mhr3, so it's an issue in libunity, not people lens/
[10:05] <mhr3> it's wrong deps defined for libunity, so if you try to use new gee in your app and libunity brings in old gee, it barfs on two gees
[10:06] <Saviq> mhr3, k
[10:06] <MacSlow> mhr3, looking...
[10:07] <MacSlow> mhr3, hm...
[10:07] <Saviq> nic-doffay, log?
[10:07] <nic-doffay> Saviq, I'm getting a fresh branch now.
[10:07] <Trevinho> seb128: oh,, sure I saw the mail... I'll check that soon
[10:07] <MacSlow> mhr3, I'm just in the middle of updating on of my machines to saucy
[10:08] <mhr3> MacSlow, glib is in S crashy when you try to do something on and unreffed object, that will be the core issue
[10:08] <MacSlow> mhr3, ah ok
[10:08] <mhr3> (as in G_IS_OBJECT) may crash
[10:08] <tsdgeos> Saviq: about the clipping for "our" listview and section headers, been thinking about it and to be honest i think it's better we keep doing it the way we do it at the moment
[10:09] <seb128> Trevinho, thanks, unity segfaults every 5 minutes here with that bamf version, didrocks reverted the recent commits meanwhile since that was blocking the saucy landing which is being prepared for a week
[10:09] <Saviq> tsdgeos, might be
[10:09] <Trevinho> seb128: mh... Which commit caused it?
[10:09] <mhr3> Saviq, btw if you're changing the build scripts, it'd be nice to make also libunity build in the builddir that everything else uses
[10:09] <Saviq> mhr3, will do
[10:09] <Trevinho> seb128: have you tried the trunk version (gdbus based)?
[10:09] <Saviq> tsdgeos, otherwise we'd have to wrap each category in its own clipper, right?
[10:10] <mhr3> Saviq, you know how that works with autotools-based stuff?
[10:10] <tsdgeos> Saviq: because if i have to implement it in the listview, i have to end up doing the same we already do in qml but in the C++ part
[10:10] <seb128> Trevinho, likely r537 or 538
[10:10] <tsdgeos> so doesn't really give us much
[10:10] <tsdgeos> just more code in the c++ side
[10:10] <tsdgeos> which i'd like to avoid :D
[10:10] <seb128> Trevinho, that's the version which has the issue
[10:10] <Saviq> tsdgeos, yeah, we're only clipping the single top item anyway, right
[10:10] <seb128> Trevinho, I tried r539
[10:10] <Saviq> mhr3, any special tips? :)
[10:10] <seb128> Trevinho, r536 seems to not have the issue
[10:10] <seb128> Trevinho, so something in your recent refactoring
[10:11] <Trevinho> 537 as well I guess
[10:11] <mhr3> Saviq, base idea - mkdir build; cd build; ../autogen.sh
[10:11] <Saviq> mhr3, yeah
[10:11] <seb128> Trevinho, I can try getting more infos if you want
[10:11] <Saviq> mhr3, the usual
[10:11] <Trevinho> seb128: mh, weird as it worked well both to me on raring and to andyrock / bschaefer since a week or more
[10:11] <seb128> Trevinho, you need a valgrind I guess?
[10:12] <Trevinho> seb128: probably. however why reverting trunk instead of reverting only for packaging?
[10:12] <Mirv> wow, the flow of packages \o/
[10:13] <seb128> Trevinho, because didrocks didn't want to change and redeploy the landing config, we really want to land in saucy today and went to the easier solution as a workaround
[10:13] <seb128> Trevinho, sorry about the revert, it's just a workaround to get things out
[10:13] <Trevinho> seb128: mh, ok... but I don't like it too much as it makes getting things back dirty :)
[10:14] <didrocks> Trevinho: well, we had to take actions, especially when intrusive change making a lot of segfault are introduced on the release day :)
[10:14] <seb128> Trevinho, I guess we could just push --overwrite back to r536
[10:14] <seb128> Trevinho, and then push back the 3 other commits after the landing
[10:14] <didrocks> Trevinho: instead of releasing at 6h30, we are releasing almost 6h later and have a lot of stuff to deal with to make it landing in saucy still :(
[10:14] <didrocks> Trevinho: so I hope you can understand we have to make things moving
[10:14] <Trevinho> seb128: I was thinking to that... but we can't lose the history
[10:15] <Trevinho> didrocks: oh, sure... don't worry for that, I didn't want to block at all... I wouldn't have merged these branches if I knew this
[10:15] <didrocks> Trevinho: you are not reading the ubuntu-devel ML?
[10:15] <Trevinho> didrocks: yes, I am
[10:15] <didrocks> should be there ;)
[10:16] <didrocks> Trevinho: but yeah, sorry for the history on bzr blame
[10:16] <didrocks> I prefered that than a commit --overwrite which would have screwed as well when you want to merge back
[10:16] <Trevinho> didrocks: yes, I read that ... I meant if I knew they were segfaulting
[10:16] <Trevinho> didrocks: and this seems pretty weird here...
[10:17] <Trevinho> didrocks: ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh, damn it I know what it's causing it on saucy, probably one line change, as always
[10:17] <didrocks> Trevinho: we should really avoid making that intrusive changes close to release anyway :)
[10:18] <Trevinho> didrocks: right, sorry...
[10:18] <Trevinho> didrocks: I asked to cyphermox about distro review, but I wasn't thinking that it could have blocked the ongoing release, my bad...
[10:18] <didrocks> Trevinho: no worry
[10:19] <seb128> Trevinho, do you need debug infos then or ...?
[10:20] <Trevinho> seb128: can you try to remove the if (g_object_is_floating (view)) line on bamf-factory.c?
[10:21] <Trevinho> seb128: it shjould be inside an if (matched_view) { } statement
[10:21] <seb128> Trevinho, hum, should I drop the if or add the it(matched_view) around it?
[10:22] <Trevinho> seb128: only comment out the "if (g_object_is_floating (view))" line
[10:22] <Trevinho> seb128: it should ref_sink always...
[10:23] <Trevinho> (not really actually, but this is a problem that there's also in old versions and that I'm refactoring in these days)
[10:23] <Saviq> mhr3, still getting http://pastebin.ubuntu.com/5741485/ :/
[10:23] <Saviq> mhr3, might it be that it's not reading the thing from the prefix
[10:23] <Saviq> mhr3, but from system installation?
[10:24] <mhr3> Saviq, maybe, but iirc the make rule for the .deps sucks, if you only merged the branch and run make it wouldn't update
[10:24] <seb128> Trevinho, did something change between raring and saucy that makes the bug happen only on saucy?
[10:24] <mhr3> Saviq, so try to find -name "unity.deps"
[10:24] <mhr3> and rm it
[10:24] <mhr3> then run make again
[10:25] <Trevinho> seb128: yes because in saucy the BAMF_IS_* crashes things if the pointer is invalid
[10:25] <seb128> oh, ok
[10:25] <Trevinho> seb128: that could be...
[10:25] <seb128> same as mhr3 was saying about G_IS_OBJECT a bit earlier
[10:26] <mhr3> Saviq, if that doesn't help, feel free to change your system unity.deps in /usr/share/vala/vapi/ - as i said it's extra and shouldn't have been there in the first place
[10:26] <mhr3> i mean the gee dependency there is extra
[10:26] <Trevinho> seb128: yes... Actually the problem there is an ureffing issue, that I should look further, but this is the best way to prevent it, also if not really a good thing for other reasons (that will be fixed later)
[10:27] <Saviq> mhr3, yeah, it picks up the system-wide one
[10:27] <seb128> didrocks, Trevinho: that 1 liner change fixes the issue indeed
[10:28] <mhr3> Saviq, the clean solution to that is passing modified XDG_DATA_DIRS when building people lens
[10:28] <Saviq> mhr3, indeed
[10:28] <Saviq> uh
[10:28] <Trevinho> seb128: I knew I should have re-sent it before... I discovered it yesterday but I forgot to push
[10:29] <mhr3> Saviq, but maybe just disable people lens building instead?
[10:29] <seb128> Trevinho, it would have been nice, would have spent confusions and revert this morning ... oh well, it's done, glad you figure it out already though ;-)
[10:29] <Saviq> mhr3, yeah, I know :P
[10:29] <Trevinho> didrocks: are we still in time to overwrite that change?
[10:29] <Saviq> mhr3, I'm just "as long as it's easy to fix, let's have it"
[10:29] <Saviq> mhr3, but yeah, it's going away pretty soon
[10:30] <mhr3> sounds like a good motto :)
[10:31] <Saviq> mhr3, huh... http://pastebin.ubuntu.com/5741512/
[10:31] <Saviq> mhr3, and still fails, from a clean checkout
[10:31] <Saviq> fook it
[10:31] <mhr3> wth
[10:33] <dednick> Saviq: is unity8 going to go into raring? you probably know this, but run_on_device -s doesnt work anymore.
[10:33] <didrocks> Trevinho: no, it's released now
[10:33] <didrocks> Trevinho: so push is as a regular revert + fix
[10:33] <Saviq> dednick, no it's not gonna go into raring, but run_on_device should work, /me will check
[10:34] <dednick> Saviq: 'build-dep unity8' failed
[10:34] <Trevinho> didrocks: overwriting + importing the release change is too bad?
[10:34] <Saviq> dednick, yeah, will fix
[10:34] <Saviq> dednick, shouldn't have been like that anyway
[10:34] <didrocks> Trevinho: no no, please don't overwrite
[10:34] <Trevinho> mh ok
[10:34] <didrocks> Trevinho: there is the merge back happening now
[10:34] <dednick> Saviq: ok. ta
[10:34] <Trevinho> didrocks: not now, I can wait..
[10:43] <dednick> Saviq: something strange seems to be happening when running trunk on my phone. Unity starts up for a few seconds, but then it gets replaced with the /usr version.
[10:44] <Saviq> dednick, yeah, it's the "qml-phone-shell" vs. "unity8" issue again
[10:44] <Saviq> dednick, will fix, too
[10:44] <dednick> Saviq: but it doesnt seem to be crashing. And it works when running under gdb
[10:44] <dednick> Saviq: ah. ok
[10:45] <mhr3> Saviq, ah, folks deps on old gee too, that's why it doesn't build
[10:45] <Saviq> kenvandine, noooooo!
[10:45] <Saviq> :P
[10:45] <Saviq> mhr3, nvm, dropped people lens already
[10:45] <dednick> Saviq: that a problem in the device-services file? getting replaced by qml-phone-shell?
[10:45] <Saviq> dednick, yes
[10:46] <Saviq> dednick, just drop qml-phone-shell from the file manually
[10:46] <dednick> Saviq: yup. doing now
[10:47] <mhr3> Saviq, eh, no, folks deps on new gee, but the lens on old... simple bump to people lens to build with new gee fixes it (plus the libunity patch)
[10:48] <Saviq> mhr3, orly? doing, then :)
[10:50] <Saviq> mhr3, hrm, where do I do that? debian/control has no version?
[10:50] <mhr3> also, why the hell is gee-0.8 *newer* than gee-1.0?
[10:51] <Saviq> :)
[10:51] <mhr3> Saviq, i just bumped gee dep in src/Makefile.am and configure.ac
[10:51] <Saviq> mhr3, to what? I see gee-1.0 here, should be newer?
[10:51] <Saviq> mhr3, aah
[10:51] <mhr3> Saviq, yea, cause gee-0.8 is newer :)
[10:52] <Saviq> right! of course!
[10:52] <mhr3> makes total sense
[10:53] <dednick> Saviq: the FORM_FACTOR config var was removed from the session-manager a couple of weeks ago. Do you know if it was moved elsewhere?
[10:53] <Saviq> dednick, nope
[10:54] <dednick> Saviq: ok, i will follow up with foundations.
[10:54] <Saviq> dednick, just make that a property on the indicators model maybe?
[10:54] <Saviq> dednick, I'm just thinking later we'll need to dynamically switch between them
[10:54] <dednick> Saviq: sure, but i need to set it somewhere ("phone" or "desktop")
[10:54] <Saviq> potentially
[10:54] <Saviq> dednick, yeah, just hardcode "phone" for now
[10:55] <Saviq> dednick, unity8 is only phone for now
[10:55] <dednick> Saviq: ok.
[11:09] <Saviq> mhr3, https://code.launchpad.net/~saviq/libunity/phablet.clean-up-deps/+merge/168016 :)
[11:10] <dednick> Saviq: should all mp's be to unity/8.0 now?
[11:10] <Saviq> dednick, yes
[11:10] <Saviq> dednick, if you have a branch you'd like to move
[11:10] <Saviq> dednick, I can try and replay the history on top of it
[11:11] <mhr3> Saviq, we were just talking with seb that this might not work during runtime (one lib trying to use 0.8 and one 1.0), so if people lens starts crashing now... we know why
[11:11] <Saviq> dednick, but if there's a lot of merges it might be better to just flatten (bzr diff > diff; patch -0 < diff)
[11:11] <mhr3> but anyway, acked
[11:11] <Saviq> mhr3, aarhg
[11:12] <Saviq> mhr3, it doesn't build for me anyway
[11:12] <Saviq> mhr3, "Cannot convert from `GLib.CompareFunc<Folks.Individual>' to `GLib.CompareDataFunc<Folks.Individual>?'
[11:12] <Saviq> mhr3, so that' final, I'm dropping it :P
[11:12] <mhr3> Saviq, k, let's forget it
[11:12] <dednick> Saviq: i think it'll be a tough one to replay
[11:12] <Saviq> dednick, which one? indicators?
[11:12] <dednick> Saviq: ya
[11:13] <Saviq> dednick, it's almost all green (at least was)
[11:13] <Saviq> dednick, so let's try - which branch?
[11:13] <dednick> Saviq: https://code.launchpad.net/~nick-dedekind/unity/phablet-indicators-client/+merge/165409
[11:13] <Saviq> dednick, k, gimme 15
[11:21] <nic-doffay> Saviq, attempted some more fixes, runs on desktop but not the phone.
[11:21] <Saviq> nic-doffay, I'm fixing the build scripts now, will have things in 10
[11:21] <nic-doffay> Saviq, ok great because I'm not seeing any glaring errors in the output.
[11:23] <Saviq> nic-doffay, lp:~unity-team/unity/8.fix-build-scripts
[11:23] <Saviq> nic-doffay, you can help me verify that this works
[11:23] <nic-doffay> Saviq, sure.
[11:25] <mhr3> Saviq, what's the plan on pawel's branches? will you review those? or are those ready to land today?
[11:30] <Saviq> mhr3, I didn't manage to look at them yet
[11:30] <Saviq> mhr3, but yes, I will review them
[11:31] <Saviq> nic-doffay, need to fix
[11:31] <mhr3> Saviq, np, just trying to get a rough estimate on when will that land
[11:31] <Saviq> mhr3, I hope next week
[11:32] <mhr3> k
[11:41] <Saviq> nic-doffay, pushed
[11:44] <Saviq> nic-doffay, https://code.launchpad.net/~unity-team/unity/8.fix-build-scripts/+merge/168029 btw
[11:44] <Saviq> dednick|lunch, you, too ^
[11:56] <dandrader> Saviq,  run_on_device just didn't work yesterday with latest unity & phablet image. does your merge proposal fix it?
[11:56] <Saviq> dandrader, it's about to
[11:56] <dandrader> nice
[12:02] <didrocks> sil2100: do you have the branch with pocketsphinx with tests disabled on powerpc?
[12:12] <Saviq> dandrader, nic-doffay, dednick, the MR for the build scripts is ready
[12:14] <nic-doffay> Saviq, looking through the diff.
[12:14] <nic-doffay> Saviq, build works.
[12:14] <Saviq> dednick, https://code.launchpad.net/~unity-team/unity/8.indicators-client/+merge/168022 is ready, too
[12:15] <Saviq> dednick, the difference between this and https://code.launchpad.net/~nick-dedekind/unity/phablet-indicators-client/+merge/165409 seems to be that you removed and added the files
[12:15] <Saviq> dednick, whereas git understood that as moving
[12:27] <olli> team, I just noticed that bug #1154229 is fix released!
[12:27] <olli> thx everyone involved
[12:29] <didrocks> hum, sil2100 doesn't seem here, Mirv, do you have a minute for a quick task?
[12:29] <sil2100> Darn internet
[12:29] <didrocks> ah :)
[12:29] <didrocks> he is now ;)
[12:29] <sil2100> didrocks: what's up? ;)
[12:29] <didrocks> 14:02:36   didrocks | sil2100: do you have the branch with pocketsphinx with tests disabled on powerpc?
[12:29] <sil2100> Ah, I can pastebin the debdiff
[12:29] <didrocks> yes please :)
[12:29] <sil2100> Since I used the source package that got uploaded
[12:29] <didrocks> I'll then sponsor
[12:30] <didrocks> it seems the only thing that is under component mismatch
[12:30] <didrocks> (between main and universe)
[12:30] <didrocks> sil2100: it's uploaded?
[12:30] <sil2100> didrocks: the one here: https://launchpad.net/ubuntu/+source/pocketsphinx
[12:30] <sil2100> It's in proposed it seems?
[12:30] <sil2100> 0.8.0+real-0ubuntu3
[12:31] <sil2100> didrocks: http://paste.ubuntu.com/5741769/
[12:31] <sil2100> Wait, wrong!
[12:31] <sil2100> Don't look at that!
[12:31] <sil2100> ;)
[12:31] <didrocks> :p
[12:31] <didrocks> ah so 0.8.0+real-0ubuntu4, that's what I want :)
[12:32] <sil2100> The heck... ;) Redoing the debdiff
[12:32] <didrocks> ah sponsored
[12:32] <dednick> Saviq: thanks. i did some moving without bzr by mistake.
[12:32] <didrocks> ah no, colin uploaded
[12:32] <Saviq> dednick, actually there's one more thing I need to fix, minor
[12:33] <sil2100> http://paste.ubuntu.com/5741779/
[12:34] <sil2100> didrocks: ^ this should be ok
[12:34] <didrocks> sil2100: see #ubuntu-devel
[12:34] <dednick> Saviq:  +1 on build script. built from fresh flash.
[12:35] <Saviq> dednick, thanks
[12:35] <dednick> Saviq: ready for approve?
[12:38] <Saviq> dednick, you tell me :D
[12:38] <Saviq> dednick, but I've no other things to do there
[12:39] <dednick> Saviq: ok, then good to go.
[12:45] <didrocks> sil2100: hud recommends julius-voxforge
[12:45] <didrocks> sil2100: did we have a MIR for it?
[12:50] <cyphermox> Trevinho: oh, right. I didn't think of that either
[12:51] <Mirv> didrocks: o/
[12:51] <cyphermox> I mean, your merge blocking the current releases
[12:51] <didrocks> Mirv: hey! do you have time to create a small MIR? pyruntest is needed by gtester2xunit
[12:52] <didrocks> (it's a build-dep)
[12:52] <Mirv> didrocks: pyruntest MIR, ok trying to do that still
[12:52] <didrocks> Mirv: thanks!
[12:52] <Saviq> dednick, 8.indicators-client ready
[12:52] <Saviq> dednick, had to do some rebasing and overwriting, but it's good now
[12:53] <Saviq> now..
[12:53] <Saviq> reviews! my favourite :D
[12:53] <dednick> Saviq: :) thanks
[12:54] <sil2100> Recommends!
[12:55] <sil2100> didrocks: checking, but I don't think so, doing that (and checking it properly)
[12:55] <didrocks> thanks!
[12:56] <didrocks> sil2100: yeah, as a recommends, it won't break the iso at least :p
[12:57] <Mirv> didrocks: interestingly, there's a 'won't fix' MIR for pyruntest from March, should I simply resurrect it perhaps?
[12:57] <Mirv> https://bugs.launchpad.net/ubuntu/+source/pyruntest/+bug/1130859
[12:58] <didrocks> Mirv: more are more package are using gtester2xunit, so better to have the test suite now I guess
[12:58] <didrocks> Mirv: so yeah, resurect with this rationale, please :)
[12:58] <didrocks> good catch btw!
[12:59] <Mirv> didrocks: ok, thnks
[13:01] <greyback> oh sweet jebus, s/mouse/touch/ was all I needed in my failing test. Gah!
[13:06] <Saviq> greyback, ouch, right, dandrader just merged stage drag recently...
[13:06] <Saviq> I love it when the travel agent comes back with "Wow. This is a great itinerary." after they've sent me some idiotic ones and I spend 5 minutes on the interwebs...
[13:07] <Saviq> yes, we need you people, of course :/
[13:07] <greyback> Saviq: that was 4 hours of me going gently nuts. Can we please have a mail sent to the team about things like how DirectionalDragArea doesn't respond to mouse events, so use touch
[13:07] <sil2100> didrocks: hm, julius-voxforge recommends julius on the other hand - should I also add it to Main?
[13:07] <sil2100> Since it's in universe
[13:08] <sil2100> didrocks: julius seems to be safe dependency-wise
[13:08] <didrocks> sil2100: look at the size of it
[13:08] <Saviq> greyback, yeah, we should communicate that better, sorry :/
[13:08] <Saviq> greyback, and then you were using ./run where it worked fine, probably
[13:08] <Saviq> greyback, because we wanted to make it transparent...
[13:08] <greyback> Saviq: yep, especially confusing
[13:08] <Saviq> too transparent...
[13:09] <Saviq> dandrader, ↑↑
[13:09] <greyback> only when I added debug statements to DDA did I notice something strange was happening
[13:10] <Mirv> didrocks: reopened the bug, gave rationale and made a MP to fix a packaging problem as there was an open bug about a such thing
[13:10] <greyback> Saviq: anyway, refactor-wm-and-test is up for review. I guess mzanetti can look when he gets back, he already did half the review
[13:10] <Mirv> cyphermox: https://code.launchpad.net/~timo-jyrinki/pyruntest/depend_on_pythontesttools/+merge/168052 for your bug
[13:10] <Saviq> greyback, yeah, I won't be taking over other people's reviews
[13:11] <didrocks> Mirv: perfect! do you mind pinging mterry (or sent him an email) about it?
[13:11]  * greyback goes to see if there's anything edible in the kitchen
[13:11] <cyphermox> Mirv: aye, thanks
[13:12] <paulliu> Saviq: will we rebase lp:unity/phablet-mods to lp:unity some time? I need some new headers from UnityCore.
[13:12] <sil2100> didrocks: binary packages weight around 1.4MB, source 1.6MB
[13:12] <Saviq> paulliu, you shouldn't be looking at lp:unity/phablet-mods at all
[13:12] <Saviq> paulliu, you are to use lp:unity directly
[13:12] <didrocks> sil2100: sounds good to me if deps and build-deps for it is good as you told
[13:12] <paulliu> Saviq: ok.
[13:13] <Saviq> paulliu, we're dropping the people lens for the time being, it needs more design work etc.
[13:13] <Saviq> paulliu, so once we switch to 100scopes we'll be moving to all the upstreams
[13:13] <paulliu> Saviq: ok.
[13:13] <Mirv> didrocks: ok, doing
[13:14] <Saviq> paulliu, so you should be working on top of lp:~unity-team/unity/8.new-libunity already
[13:15] <mhr3> didrocks, ehm, new unity in S already? cause i just dist-upgraded and unity segfaults on startup
[13:15] <Saviq> jeez I'm gonna get OCD from compiz crashing all the time...
[13:15] <Saviq> oh, I won't
[13:15] <Saviq> ...dist-upgrade, then
[13:17] <didrocks> mhr3: apt-cache policy unity
[13:17] <mhr3>   Installed: 7.0.0daily13.04.18~13.04-0ubuntu1
[13:17] <mhr3>   Candidate: 7.0.0daily13.04.18~13.04-0ubuntu1
[13:17] <mhr3>   Version table:
[13:17] <mhr3>  *** 7.0.0daily13.04.18~13.04-0ubuntu1 0
[13:17] <mhr3>         500 http://gb.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
[13:17] <mhr3>         100 /var/lib/dpkg/status
[13:17] <didrocks> mhr3: you are still on the old one apparently
[13:18] <didrocks> mhr3: maybe there is a break missing with new HUD or something like that
[13:18] <didrocks> mhr3: or libunity? as it's already in main :p
[13:18] <greyback> Saviq: have you upstart restarting compiz?
[13:18] <Saviq> greyback, yes
[13:18] <mhr3> didrocks, fwiw backtrace just gives the usual abi-mismatch crap
[13:18] <greyback> Saviq: does it make it tolerable?
[13:18] <Saviq> greyback, it works nice, only problem is when compiz doesn't actually die
[13:19] <Saviq> greyback, depends
[13:19] <didrocks> mhr3: yeah, some mismatch and a missing break IMHO. Should we fixed once unity published
[13:19] <Saviq> greyback, it's fine for hours
[13:19] <didrocks> mhr3: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[13:19] <Saviq> greyback, and then it crashes 10 times within 10 minutes
[13:19] <greyback> Saviq: here too
[13:19] <didrocks> mhr3: it's telling unity is a candidate for replacement
[13:19] <sil2100> Damn, now even firefox is making problems ;/
[13:19] <greyback> Saviq: I switch to metacity for those 10 minutes :)
[13:19] <didrocks> mhr3: so just a question of a publisher run
[13:19] <greyback> Saviq: I swear the qmltests run faster in metacity
[13:20] <Saviq> greyback, I wouldn't be surprised
[13:20] <Saviq> greyback, compiz is slowing things down a lot
[13:20] <mhr3> didrocks, i see, though kinda sucks that you can still upgrade into a non-working unity
[13:20] <didrocks> mhr3: a breaks: was missing
[13:20] <didrocks> apparently
[13:20] <mhr3> didrocks, where's a test for that? ;P
[13:21] <didrocks> mhr3: I wonder what upstream is doing! :p
[13:21] <didrocks> mhr3: seriously, apart from documenting it in the FAQ to add the breaks
[13:21] <didrocks> I don't really know
[13:21] <didrocks> it's good we deliver a "stack"
[13:21] <didrocks> in sync
[13:21] <didrocks> but the publisher can't force this being a stack while publishing
[13:21] <sil2100> didrocks: https://bugs.launchpad.net/ubuntu/+source/julius/+bug/1188611
[13:21] <didrocks> (and so we need those helpers)
[13:22] <didrocks> sil2100: mind adding it to the new line?
[13:22] <didrocks> in the spreadsheet
[13:22] <didrocks> thanks!
[13:22] <didrocks> Mirv: you as well ^
[13:22]  * Saviq is actually going to try and use git-bzr-ng for daily work :P
[13:23] <mhr3> didrocks, i'm just installing a mind-worm for you, maybe you'll figure out something at some point
[13:24] <didrocks> mhr3: I'm seeing that! Right now, I'm already documenting that in the FAQ :p
[13:25] <greyback> Saviq: cheeky :)
[13:25] <Saviq> greyback, after having fought with the rebases I'm quite confident it works :)
[13:26] <Saviq> tsdgeos, do you remember what I need to do to get GTK themes in Qt apps? fresh install here and my Qt apps are ugly ;/
[13:26] <tsdgeos> hmm, gtkqtstyle, but afaik that's part of the default install
[13:34] <olli> bregma, ping
[13:35] <olli> bregma, on #1187500, do you know when we can expect a fix
[13:35] <Saviq> coming, sorry
[13:35]  * bregma checks
[13:35] <Saviq> tsdgeos, start without me please, no mumble
[13:35] <Saviq> will join asap
[13:35] <tsdgeos> nic-doffay: standup?
[13:37] <bregma> olli, either (1) a Nux fix that was released to Saucy today fixes it and it could be backported or (2) since the only change that went in to raring was a new intel video driver, someone who knows video drivers will need to take a look
[13:37] <olli> bregma, if (2) mind pushing that with the mesa maintainers?
[13:37]  * olli is on intel too
[13:38] <olli> so far I blamed chromium/ggtalkplugin
[13:38] <bregma> I have Intel hardware, but not that particular video chip
[13:39] <didrocks> mhr3: unity published
[13:39] <sil2100> \o/
[13:40] <didrocks> so 4 hours from stack publishing, NEWing, MIRing and so on
[13:40] <nic-doffay> tsdgeos, whoa slipped my mind
[13:46] <Cimi> so this is my problem http://paste.ubuntu.com/5741911/
[13:47] <Cimi> sometimes data.date seems undefined
[13:48] <Cimi> without seems, sometimes *is* undefined
[13:48] <Cimi> like it didn't create the object yet
[13:53] <tsdgeos> Saviq: do we still need the stacked thing when pushing?
[13:53] <Saviq> tsdgeos, yes :/
[13:54] <tsdgeos> Saviq: can someone remind me the syntax? it disappeared from my shell history :D
[13:55] <Saviq> tsdgeos, --stacked-on=bzr+ssh://bazaar.launchpad.net/+branch/unity/8.0
[13:56] <Saviq> tsdgeos, or /unity/phablet if you have the old thing still
[13:57] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity/UseC++LVWPH if you want to give it a go
[13:57] <tsdgeos> i'm still missing the showHeader implementation
[13:57] <tsdgeos> and need to add the tests
[13:58] <Cimi> guys ^ pls
[13:59] <tsdgeos> Cimi: do you have a self contained example? i.e. something that doesn't need calendar.
[13:59] <Cimi> no
[14:00] <Saviq> tsdgeos, that's against phablet or 8.0?
[14:00] <tsdgeos> Saviq: 8.0
[14:00] <Cimi> warning printed QWARN  : qmltestrunner::Calendar::test_maximumDate(row 0) file:///home/cimi/Development/indicators-client/system-components/SystemComponents/SettingsComponents/Calendar/Calendar.qml:123: TypeError: Cannot call method 'getFullYear' of undefined
[14:00] <Cimi> the data.date is undefined
[14:01] <Cimi> I could fix not creating the object in the _data
[14:01] <Cimi> and like passing numbers or days/year
[14:01] <Cimi> but still sucks!
[14:03] <Saviq> Cimi, the Date is probably destroyed
[14:03] <Saviq> Cimi, as soon as the function returns
[14:03] <Cimi> mmm
[14:03] <Cimi> ah ok
[14:03] <Cimi> Saviq, works sometimes
[14:04] <Cimi> Saviq, sometimes not
[14:04] <Saviq> Cimi, yeah, as you said - race
[14:04] <Cimi> ok
[14:04] <tsdgeos> garbage collector?
[14:04] <Saviq> Cimi, it's not garbage collected
[14:04] <Saviq> Cimi, so just add it to a list that's a property of some object
[14:05] <Saviq> tsdgeos, new dep on the private headers is needed
[14:05] <tsdgeos> right
[14:05] <tsdgeos> didn't try building it yet
[14:05] <tsdgeos> with anything other than ./build i mea
[14:05] <tsdgeos> n
[14:07] <Saviq> tsdgeos, qtdeclarative5-private-dev and libqt5v8-5-private-dev
[14:08] <tsdgeos> yep
[14:08] <Saviq> tsdgeos, and dude you're not pedantic ;)
[14:08] <tsdgeos> Saviq: it's not me
[14:08] <tsdgeos> it's qt
[14:08] <Saviq> tsdgeos, yeah just saw :D
[14:08] <tsdgeos> did a few fixes
[14:08] <Saviq> we'll need -Wno-error=pedantic for the time being
[14:08] <Saviq> and fix that upstream
[14:08] <tsdgeos> https://codereview.qt-project.org/#change,58274 and https://codereview.qt-project.org/#change,58273
[14:09] <tsdgeos> hmmm where do we errror?
[14:09] <tsdgeos> in pkg building?
[14:10] <Saviq> tsdgeos, CMakeLists
[14:10] <tsdgeos> and why it builds here¿?
[14:10] <greyback> tsdgeos: uh oh, segv here
[14:11] <tsdgeos> ah maybe because i'm doing a debug build?
[14:11] <tsdgeos> greyback: wops :D
[14:11] <tsdgeos> greyback: can you give me a bt?
[14:12] <greyback> tsdgeos: looks like it's not your fault
[14:13] <tsdgeos> better :D
[14:19] <Saviq> tsdgeos, "error: no matching function for call to ‘qBound(double, qreal&, qreal)’ ?
[14:19] <Saviq> tsdgeos, that's on the device
[14:19] <tsdgeos> ok
[14:19] <tsdgeos> haven't built on the device yet
[14:19] <Saviq> tsdgeos, on desktop it built fine
[14:20] <tsdgeos> but yeah it's the damn qreal is double or float depending who you are
[14:20] <tsdgeos> need to check where the first double comes from
[14:20] <Saviq> right
[14:20] <tsdgeos> Saviq: that's line 528 and 209?
[14:20] <Saviq> tsdgeos, +1
[14:22] <Saviq> tsdgeos, looks nice, initially I thought there's some flickering, but it seems it's my display (/eyes)
[14:22] <Saviq> tsdgeos, that's why wanted to build on device
[14:23] <tsdgeos> there may be some flickering
[14:23] <tsdgeos> i haven't seen it
[14:23] <tsdgeos> but i'm not very sensible to it
[14:24] <Saviq> tsdgeos, nah, it's the same on trunk (I think)
[14:24] <sil2100> !
[14:24] <Saviq> tsdgeos, question, does a ListView.visible = false unload all its delegates?
[14:24] <greyback> Saviq: this look familiar to you: WARN  2013-06-07 15:23:15 unity.dash.lens.filesystem FilesystemLenses.cpp:236 Unable to read lens file /home/gerry/dev/phablet/unity_build/build/share/unity/lenses/applications/applications.lens: Error opening file: No such file or directory
[14:24] <greyback> Saviq: looking in wrong place for lens files
[14:24] <Saviq> greyback, that's the right place
[14:24] <tsdgeos> Saviq: in the ListViewWithPageHeader ?
[14:25] <Saviq> tsdgeos, no, just generally
[14:25] <tsdgeos> Saviq: can't tell without checking tbh
[14:25] <Saviq> tsdgeos, I know we can make it so in LVWPH
[14:25] <Saviq> we'll have to see
[14:25] <greyback> well I'm still segv, but with a lens complaint http://pastebin.ubuntu.com/5742044/
[14:25] <bregma> whoopie, Unity on start with today's Saucy upgrade, looks like an ABI break
[14:26] <Saviq> greyback, you sure you're linking to the custom unity?
[14:26] <Saviq> greyback, rm -R builddir
[14:26] <Saviq> well, yeah it looks that way
[14:27] <Saviq> greyback, but anyway, don't you have the apps lens installed? did you upgrade to smart scopes?
[14:27] <Saviq> greyback, if that's so, drop the .lens link from there
[14:27] <Saviq> greyback, leave just the mock ones (but the mocks will stop working with smart scopes, too)
[14:29] <greyback> Saviq: well  I've nothing in /usr/share/unity/lenses/applications
[14:29] <greyback> I did an update a few hours ago, maybe smart scopes landed?
[14:29] <Saviq> greyback, yes they did
[14:30] <Saviq> greyback, didn't you see didrocks and mhr3 and sil2100 going \o/
[14:30] <greyback> Saviq: still getting crash however
[14:30] <greyback> true :)
[14:30] <greyback> I gotta run for an hour or so
[14:31] <greyback> will dig when back
[14:31] <Saviq> greyback, try lp:~unity-team/unity/8.new-libunity then :)
[14:32] <mhr3> greyback, reinstall unity-common
[14:33] <mhr3> but otherwise yea, 100scopes in, might be related :)
[14:36] <mhr3> actually, yea, you seem to have new unity-common, and old unity-core doesn't like that
[14:37] <om26er> Trevinho, andyrock Could we have someone look into this issue please? bug 1158161
[14:37] <om26er> we thought it was fixed at one stage but seems it was not as people have still been seeing this issue
[14:39] <sil2100> \o/
[14:43] <andyrock> om26er, not today (eod in few minutes)
[14:43] <om26er> andyrock, monday then ;)
[14:54] <Saviq> tsdgeos, re --stacked-on, it seems that having a separate project (or being the focus of development, of course) is the only way to get rid of that...
[14:54] <tsdgeos> Saviq: oka
[14:54] <Saviq> tsdgeos, separate project has some more advantages
[14:54] <Saviq> tsdgeos, so didrocks wants us to discuss going for that next week
[14:55] <tsdgeos> i see
[15:03] <Cimi> I cannot run make alltests because the quick creation/deletion of bamf windows makes unity segfaults, cool.
[15:03] <Cimi> so I am having hard times reproducing the race
[15:10] <tsdgeos> Cimi: yeah same here, that's why i stopped using unity :D
[15:11] <tsdgeos> too many fast windows kills it
[15:11] <nic-doffay> Saviq, do we MP to unity/8.0 ?
[15:11] <nic-doffay> or phablet?
[15:12] <tsdgeos> 8.0
[15:15] <nic-doffay> tsdgeos, ta
[15:15] <tsdgeos> anyone knows what the " clipListView: !previewLoader.onScreen" in DashVideos.qml is supposed to do?
[15:16] <nic-doffay> Review up for grabs for anyone who's familiar with the shell: https://code.launchpad.net/~nicolas-doffay/unity/orientation/+merge/168100
[15:31] <tedg> pete-woods, It seems like "CMAKE_INSTALL_DATADIR" is getting resolved to "share/" in HUD.  Do you know why it wouldn't be "/usr/share" ?  Do we need to add a prefix?
[15:31] <tedg> pete-woods, Basically if you call hud-gtk in the current package it can't find its .ui file.
[15:32] <pete-woods> tedg: something I've not quite worked out about cmake is that it refers to the make style directories in a relative manner
[15:33] <pete-woods> seems like when you do file "confifguration / substituion you must have to get the absolute version or something like that
[15:34] <tedg> pete-woods, In automake it's a different macro.  abs_ on the front.
[15:37] <jbicha> why does my dash home not look like http://www.omgubuntu.co.uk/wp-content/uploads/2013/06/lenses.jpg
[15:40] <Cimi> tsdgeos, lp:~cimi/indicators-client/system-components
[15:41] <Cimi> tsdgeos, can you run make alltest
[15:41] <Cimi> s
[15:41] <Cimi> and tell me if they pass?
[15:41] <Cimi> sorry pushing now...
[15:41] <Cimi> pushed rev 30
[15:42] <tsdgeos> let me reboot, something broke in here and can't branch
[15:57] <lgdx> hi
[15:57] <lgdx> can someone help me to drawray from player to touched position?
[16:00] <Saviq> lgdx, this channel is about Unity the desktop environment in ubuntu
[16:01] <Saviq> lgdx, I think you want a different Unity
[16:01] <lgdx> oh
[16:01] <lgdx> hahahah
[16:01] <lgdx> sorry
[16:01] <lgdx> :)
[16:01] <Saviq> lgdx, no problem :)
[16:01] <lgdx> byez!!
[16:01] <lgdx> ;)
[16:02] <Saviq> jbicha, it's probably not in the repos yet
[16:05] <Saviq> jbicha, should be in saucy-proposed, though
[16:06] <Saviq> or at least coming to
[16:06] <jbicha> Saviq: the new Unity is in Saucy; it's just missing that feature
[16:11] <mterry> pete-woods1, heyo.  So your Infographic API work, are you also working to get it integrated into lightdm?
[16:11] <Saviq> jbicha, well, not in mine saucy :/, sorry, can't help
[16:25]  * bregma does a little happy dance of joy over 100 scopes running on saucy
[16:31] <pete-woods1> mterry: that's what I've been told to do, yes
[16:31] <pete-woods1> mterry: first I'm implementing a library with all the functionality in, though
[16:32] <pete-woods1> mterry: then we'll expose it through lightdm
[16:32] <mterry> pete-woods1, OK, cool.  I just realized that such integration is now a pre-req to splitting the greeter process out
[16:33] <mterry> (just because we can't build against current lightdm headers without infographic support)
[16:34] <pete-woods1> mterry: that is a good point, I should be able to make good progress on this thing now that I'm freed up from the Action API work
[16:57] <davidcalle> sil2100, ping
[17:00] <sil2100> davidcalle: pong!
[17:00] <davidcalle> sil2100, regarding the big needs-packaging bug for 100scopes, what should we do with it?
[17:04] <sil2100> davidcalle: nothing :) It's approved currently
[17:04] <sil2100> davidcalle: ah, needs-packaging
[17:04] <sil2100> davidcalle: that one we can hm, invalidate I guess? For now let's leave it as it is
[17:04] <sil2100> davidcalle: as we didn't really need that for scopes
[17:05] <davidcalle> sil2100, ok :)
[17:10] <seb128> bregma, hey, there?
[17:12] <bregma> seb128, yo?
[17:12] <seb128> bregma, hey
[17:12] <seb128> bregma, sooo, the new libgrip that landed in saucy today makes eog segfault on start for me :/
[17:12] <bregma> mmm
[17:12] <bregma> I'll look
[17:13] <seb128> bregma, http://paste.ubuntu.com/5742492/
[17:14] <bregma> seb128, I can repro that, did you open a bug?
[17:15] <seb128> bregma, not yet, doing that
[17:15] <bregma> thanks
[17:16] <seb128> bregma, https://bugs.launchpad.net/ubuntu/+source/libgrip/+bug/1188693
[17:20] <seb128> bregma, it also "breaks" the background color of evince, not sure if that's the same issue
[17:20] <seb128> bregma, e.g if you run "evince" without opening a document
[17:21] <seb128> it's supposed to be standard gtk grey and it's not with the new libgrip0
[17:21] <bregma> I doubt it, but it can't be ruled out
[17:21] <seb128> k, that's a minor issue since rendering of pdfs work
[17:21] <seb128> I will open a bug if that's still there once the segfault is fixed
[17:21] <seb128> thanks
[17:52] <seb128> bregma, so, it's getting late on friday and I would prefer to not let eog broken during the w.e ... do you think you will have a patch soon or should we consider reverting a commit or building eog without libgrip as a workaround?
[17:55] <bregma> seb128, it always takes me a while to dig in to this old code, but i can always upload a new package in a few hours if that doesn;t break all that fancy autolanding stuff
[17:56] <seb128> bregma, don't worry about the autolanding much, if you upload you should just make sure your diff get commited to the vcs as well
[17:56] <seb128> bregma, including debian changelog
[17:56] <seb128> bregma, you are sure you will fix it today one way or another?
[17:57] <bregma> I can't be sure until I find the cause
[18:00] <seb128> bregma, I will build eog without libgrip, so we have no hurry to fix it today
[18:00] <seb128> ok?
[18:00] <bregma> sure, given libgrip has been broken for 6 months, few will notice
[18:02] <seb128> k