[04:26] <pitti> Good morning
[05:27] <jbicha> pitti: did you see my comment on https://code.launchpad.net/~jbicha/apport/rename-desktop/+merge/178157 ?
[05:28] <jbicha> I think Unity is having trouble with the apport icon after the rename
[05:28] <pitti> jbicha: hm, we don't have an icon for "apport-gtk-mime" either
[05:28] <pitti> jbicha: for calibre, renaming the icon to "calibre-gui" as well helped
[05:29] <pitti> but it's not the same situation in apport
[06:28] <Mirv> hmm, I'd like to know why my saucy is not shutting down blazingly fast. how could I see which processes are "stuck" as it halts at the "Terminating remaining processes" part?
[07:02] <sil2100> Morning!
[07:06] <sil2100> Mirv: whoops, I see SDK broke some gallery-app tests?
[07:06] <sil2100> Mirv: since SDK has some failures from the apps
[07:06] <sil2100> Mirv: are you dealing with platform and sdk now? Or should I take action?
[07:07] <sil2100> Mirv: since we agreed with Florian that we'll be issuing a bug and pinging upstream as soon as there is an issue
[07:07] <sil2100> Mirv: in the meantime, I'll re-run platform, ok?
[07:08] <sil2100> Since there seemed to be a transient error on ATI
[07:12] <Mirv> sil2100: I've rerun it already, was waiting for the previous one to finish
[07:12] <Mirv> since it was blocked
[07:12] <sil2100> Ah
[07:13] <sil2100> Mirv: anyway, I'll fill out a bug about the gallery-app issues
[07:13] <sil2100> Since it seems it hasn't been introduced recently
[07:13] <sil2100> The thing is, the Apps stack tests are using the previous ui-toolkit version
[07:13] <sil2100> And it still fails
[07:13] <sil2100> So I'll leave upstream to handle that
[07:14] <Mirv> ok, then.
[07:14] <Mirv> and I see you also published the platform already
[07:27] <Sweetshark> Moin!
[07:43] <sil2100> Yay for the new apartment \o/
[07:43] <didrocks> sil2100: waow, how is it?
[07:45] <sil2100> didrocks: we just moved the basic things, so I still don't have my own desk, but it's much better than the previous one - this one has been furnitured by some designer, so looks much better
[07:45] <didrocks> oh, excellent!
[07:45] <didrocks> is it big/small?
[07:47] <sil2100> Not too big, but bigger than the previous one
[07:47] <sil2100> didrocks: btw. you still in IoM? ;)
[07:48] <didrocks> sil2100: yeah, I'm back tommorrow :)
[07:48] <didrocks> less meetings today, so I'll probably hang out a little bit later with you :)
[07:48] <didrocks> and Mirv
[07:49] <sil2100> \o/
[07:50] <sil2100> Awesome! We just jump out for something to eat to the local store, since we only have butter in our fridge
[07:51] <seb128> sil2100, hey
[07:51] <seb128> sil2100, I'm retrying to gsettings stack if you didn't yet
[07:51] <seb128> sil2100, the armhf build failed on what looks like  pandaboard issue
[07:58] <Sweetshark> seb128: Bonjour! Was looking for you here exactly two minutes before you showed up ;) -- wrote you (and Benjamin) a mail instead summarizing all the SRU and sponsoring packages.
[07:58] <seb128> Sweetshark, hey, thanks, just saw that, I'm going to look at the saucy upload in a bit
[07:59] <Sweetshark> hmm, porter-armel still barfs in my face with a MITM warning ...
[07:59] <Laney> morning
[07:59] <Sweetshark> Laney: GoooOOOood morning!
[08:00] <Laney> happy friday to you!
[08:00] <Mirv> didrocks: :)
[08:02] <seb128> Laney, good morning, happy "before holidays friday" to you ;-)
[08:02] <Laney> \o/
[08:03] <Sweetshark> oh!
[09:12] <Mirv> sil2100: please tell when you've apps (gallery) published so I can rerun sdk
[09:12] <Mirv> now that the fix was merged
[09:20] <didrocks> hum, seems nobody is publishing the settings stack
[09:20] <didrocks> doing so
[09:21] <didrocks> same for webapps
[09:21] <didrocks> webcreds*
[09:22] <didrocks> publishing phone stack as well as the sdk isn't guilty
[09:23] <didrocks> and media
[09:25] <seb128> didrocks, I retried the settings, did that fail?
[09:26] <didrocks> seb128: manual publishing
[09:26] <seb128> ah, so build worked
[09:26] <didrocks> you had an extremeeeee packaging change :)
[09:26] <seb128> didrocks, this morning the armhf failed on a buggy panda
[09:26] <didrocks> seb128: yeah yeah, just needed 20s of work of publishing :)
[09:26] <didrocks> yeah, I saw it
[09:26] <seb128> looking
[09:26] <didrocks> I hoped it would have been relaunched by then
[09:26] <didrocks> seb128: oh, it's done
[09:26] <darkxst> seb128, hey!
[09:27] <darkxst> seb128, so are we ready to start testing g-s-d update?
[09:28] <seb128> darkxst, hey
[09:29] <seb128> darkxst, we should finish the ibus 1.5/indicator-keyboard transition first ... maybe next week?
[09:32] <darkxst> seb128, ok
[09:34] <darkxst> seb128, can you merge https://code.launchpad.net/~darkxst/ubuntu/saucy/gnome-control-center/lp1196196/+merge/176577
[09:34] <seb128> darkxst, I will have a look
[09:34] <darkxst> (before the next g-c-c update)
[09:35] <seb128> darkxst, sure, let's add it to the vcs
[09:35] <darkxst> seb128, thanks
[09:35] <seb128> yw
[10:07] <seb128> Laney, should be an easy to approve if you have a minute: https://code.launchpad.net/~seb128/ubuntu-system-settings/sound-split-js-helper/+merge/178124
[10:08] <Laney> yeah i'll do reviews shortly
[10:08] <Laney> trying my hardest to get this gst stuff to build
[10:10] <Laney> might be stuck now though
[10:10] <seb128> Sweetsha1k, libreoffice is depwaiting on lp-solve, did you sort out with mterry whether that one can be promoted?
[10:10] <seb128> tkamppeter_, hey, do you plan to upload that cups-filters for new poppler?
[10:20] <Sweetsha1k> seb128: mterry said 'approved' on irc as its the same version we are supporting in main on lucid.
[10:25] <lifeless> :q
[10:25] <Laney> > _
[10:47] <Mirv> seb128: had a chance to look at the u1db-qt again? I can also ping didier on monday
[10:48] <seb128> Mirv, oh, I forgot about it ... I'm away some 15 min for lunch and then I can have a look
[10:50] <Mirv> ok, thanks again
[10:51] <Mirv> sil2100: reran sdk stack successfully
[11:02] <darkxst> pitti, hi!
[11:03] <pitti> hello darkxst
[11:05] <darkxst> pitti, so right now I am scraping /var/lib/apt/lists/ to generate a package list for ppa and then manually download dbg packages and generate a local-Contents file
[11:05] <didrocks> sil2100: back?
[11:05] <darkxst> but that seems horribly hackish, can you think of a better way to do it?
[11:07] <seb128> didrocks, do you think sil2100 locked himself out of his new appartement this morning and didn't manage to get back? ;-)
[11:07] <didrocks> it seems so :)
[11:07] <didrocks> seb128: ok, I'll publish the apps stack I guess myself
[11:07] <seb128> 4 hours breakfast
[11:07] <seb128> I should do that too!
[11:07] <Laney> haha
[11:07] <pitti> darkxst: hm, Contents lookup seems to be somewhat of a corner case anyway; is that really breaking that many retraces?
[11:07] <didrocks> seb128: 4 hours *for now* :p
[11:08] <darkxst> pitti, something is really breaking most retraces
[11:08] <pitti> darkxst: you could replace scraping of /var/lib/apt/lists with some python API, but I guess all that is in some separate helper script anyway which you just call from time to time to get an updated Contents.gz?
[11:08] <pitti> darkxst: hm, that doesn't sound good; that sounds like a more fundamental error in a-retrace or sandbox building then
[11:09] <darkxst> pitti, and from what I can tell the required .ddebs are not getting installed
[11:09] <pitti> darkxst: contents.gz is supposed to be only a last-resort thing if the transitive depends: didn't install the package
[11:09] <darkxst> (packages are listed in Dependencies.txt however)
[11:09] <pitti> darkxst: ah, that smells like a bug then, which might just be hidden because of the contents.gz lookup on ubuntu
[11:11] <pitti> darkxst: so I think your script should be a sufficient workaround for the lack of PPA Contents.gz, if you run this once a day or so?
[11:11] <pitti> darkxst: do you have a log of a retrace which shows the missing ddebs?
[11:13] <darkxst> pitti, http://paste.ubuntu.com/5939699/
[11:13] <sil2100> Grrr
[11:13] <seb128> Mirv, u1db-qt looks good to me
[11:13] <sil2100> Back
[11:13] <seb128> sil2100, hey
[11:13] <sil2100> Had some key problems indeed ;)
[11:13] <seb128> sil2100, did you really lock ourself out? ;-)
[11:13] <seb128> yourself*
[11:14] <sil2100> In a way yes, heh, had to re-make the keys since the pair I closed my home with seemed flacky, been struggling with one lock for a while
[11:14] <pitti> darkxst: ugh, it does an apt-get update four times
[11:14] <sil2100> I left the original pair at home
[11:15] <didrocks> hum, xorg-server depends on tomorrow version of mir
[11:15] <darkxst> pitti, that might be more than one retrace in that log
[11:15] <Mirv> seb128: thanks!
[11:15] <pitti> darkxst: ah, it's from crash-digger, not from apport-retrace
[11:15] <Mirv> sil2100: hmm :)
[11:15] <darkxst> pitti, yes
[11:15] <sil2100> Darn gerda locks
[11:15] <didrocks> Laney: I think the safest anyway for now is to pin it in proposed, mind blocking xorg-server? (in case someone do the Mir MIR promotion during the week-end)
[11:16] <Laney> didrocks: background?
[11:16]  * sil2100 backlogs
[11:16] <didrocks> Laney: xorg-server with Mir support is coming
[11:16] <didrocks> well, it's already build-depending
[11:16] <didrocks> but apparently, the version set is tomorrow's Mir version
[11:16] <pitti> darkxst: that looks a bit odd, missing all the crash-digger logs; but anyway, let me try here with some stuff
[11:16] <didrocks> (which should be blocked through the week-end anyway as Mir is in universe, not promoted yet)
[11:17] <didrocks> but as the Mir MIR was acked
[11:17] <didrocks> maybe someone will promote during the week-end
[11:17] <sil2100> Mirv: it seems not every key-making kiosk can duplicate them well, good thing the kind woman made 2 additional ones for me for free
[11:17] <seb128> Laney, in case you put a lock, I guess other release team members can unlock it while you are away?
[11:17] <didrocks> and I prefer to avoid having that pushed and we miss seeing side-effects
[11:17] <Laney> yes
[11:17] <tkamppeter> seb128, I will issue cups-filter 1.0.36 with the Poppler fix in the next days. I am still trying to fix bug 1207203, but did not succeed to reproduce it yet.
[11:17] <ubot2`> Launchpad bug 1207203 in cups (Ubuntu) "cups-browsed hangs at 100% CPU" [Undecided,New] https://launchpad.net/bugs/1207203
[11:17] <didrocks> Laney: do you mind adding a # ping didrocks comment?
[11:17] <didrocks> :)
[11:17] <didrocks> (ping, not "hurt" please)
[11:18] <Laney> why don't you just put the MIR on hold until monday?
[11:18] <seb128> tkamppeter, can you upload the patch on the current version, in saucy, today? it's the only package missing in the poppler transition (with libreoffice that has been uploaded) and it would be better to not have to wait some extra days
[11:18] <didrocks> Laney: how would we do that? it's just a comment and people can make mistakes
[11:19] <didrocks> (low probability as we are just 2 promoting to Main)
[11:19] <seb128> Laney, it's going to show in component mismatch and the bug is approved, you can't rule out somebody just pressing the button
[11:19] <didrocks> but I would sleep better ;)
[11:19] <pitti> darkxst: ah, I can indeed see some strange behaviour here wrt. not downloading debs and ddebs for some dependencies
[11:20] <Laney> I find that a weird argument, but whatever
[11:20] <Laney> if you have people randomly promoting stuff that's a problem
[11:20] <Laney> I'll do it for you
[11:21] <didrocks> thanks Laney :)
[11:21] <seb128> Laney, yeah, I think it's just being on the paranoid side
[11:21] <didrocks> right
[11:21] <didrocks> I learnt to be paranoid :)
[11:21]  * seb128 wonders why that xorg was uploaded on a friday to start with
[11:21] <Laney> indeed
[11:22] <darkxst> pitti, right!
[11:23] <sil2100> seb128: http://10.97.0.1:8080/view/cu2d/view/Head/view/Unity/job/cu2d-unity-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_unity-lens-friends_0.1.3+13.10.20130802-0ubuntu1.diff <- does this look ok to you? To me it makes sense, as now it's building that .la which we don't want to install
[11:23] <seb128> sil2100, +1
[11:24]  * didrocks would have prefer a -X.la to dh_install
[11:24] <didrocks> but I think this can be addressed later on, no need to block on it :)
[11:24] <seb128> that works as well
[11:25] <didrocks> if one day we rename lens, it will be more reliable
[11:25] <didrocks> (as -f will be silent)
[11:25] <didrocks> sil2100: mind proposing that in a follup MP? ^
[11:26] <sil2100> didrocks: ah, makes sense, doing that now - it's much cleaner this way indeed, but sometimes it's hard to remember all the helpers in debhelper
[11:27] <didrocks> sil2100: no worry, it's when doing that it's getting better ;)
[11:27] <didrocks> nice to see unity passing!
[11:27] <didrocks> let's hope with compiz, it will stay the same
[11:29] <seb128> didrocks, sil2100: oh, ibus tests issues are resolved?
[11:30] <didrocks> seb128: seems sooo, (we have 25 failures, a little bit higher, but already way better!)
[11:30] <seb128> great
[11:30] <didrocks> awesome even ;)
[11:30] <didrocks> I was fearing this 1.5 ibus way more
[11:31] <seb128> didrocks, I've to admit it was making me a bit nervous as well, glad it didn't create too much work
[11:32] <didrocks> yeah, it's a nice EOWish result!
[11:37] <pitti> darkxst: oh, found it; it was actually an intended optimization, but that would make life much harder for you
[11:42]  * pitti waits for the test suite to finish
[11:43] <sil2100> didrocks: I'm dogfooding the new compiz since yesterday morning and it's all running smooth
[11:44] <sil2100> No hickups, no glitches, no incompatibilities
[11:44] <sil2100> So I guess we could give it a try next week
[11:44] <pitti> darkxst: ok, http://bazaar.launchpad.net/~apport-hackers/apport/trunk/revision/2680 should make your life a lot easier
[11:44] <pitti> darkxst: you are using an lp:apport checkout, not the packages, right?
[11:45] <darkxst> pitti, yes
[11:51] <darkxst> pitti, thanks, I about to head out now, but will test when I get back
[12:05] <darkxst> pitti, it is now downloading half of ubuntu!
[12:06] <darkxst> but atleast it is picking up the ddebs it would seem
[12:08] <sil2100> seb128: what do you think? https://code.launchpad.net/~sil2100/unity-lens-friends/dh_install_rm/+merge/178278
[12:11] <seb128> sil2100, +1
[12:21] <pitti> darkxst: yeah, transitive deps FTL :/
[12:22] <pitti> darkxst: now it's downloading way more than necessary, which is why I added the optimization back then to only grab stuff from /proc/pid/maps and map it to packages
[12:22] <pitti> darkxst: but that needs Contents.gz
[12:22] <pitti> darkxst: my gut feeling is that with a permanent cache and /tmp on tmpfs the overhead is bearable
[12:26] <seb128> pitti, wouldn't it make sense to keep the optimization for the archive retracers?
[12:28] <pitti> seb128: yes, we'd need some clever way of detecting that
[12:28] <seb128> pitti, or a command line option...
[12:28] <pitti> perhaps if Package/Dependencies do not contain "[origin: ]" then we use the reduced approach
[12:28] <seb128> or config option
[12:39] <pitti> seb128: done in r2681
[12:39] <seb128> pitti, great!
[12:40] <pitti> darkxst: r2681 does "best of both worlds" now, please let me know that it still works for you; if that breaks it, keep the r2680 checkout until I'm back from vac :)
[12:53] <sil2100> didrocks: I still see mirslave red ;) This time it's missing xserver-xorg-xmir <- should I take care of that or is that a known issue?
[12:54] <didrocks> sil2100: no, everything is on hold until Monday
[12:54] <didrocks> we have those dep-waiting in proposed
[12:54] <didrocks> now, it's too late to take risks
[12:57] <sil2100> didrocks: ok
[13:12] <desrt> Laney: jbicha: new gtk upload would be good: https://git.gnome.org/browse/gtk+/commit/?h=gtk-3-8&id=1e93ed963022d82936f1bfccfab8d8a8b3f9d4cc
[13:12] <desrt> should fix https://bugs.launchpad.net/ubuntu/+source/gdk-pixbuf/+bug/1205562
[13:12] <ubot2`> Ubuntu bug 1205562 in gtk+3.0 (Ubuntu) "[background] wallpapers in grid are too small, take long time to load" [Medium,Triaged]
[13:13] <Laney> desrt: https://launchpadlibrarian.net/146439597/gtk+3.0_3.8.2-3ubuntu4_3.8.2-3ubuntu5.diff.gz
[13:13] <desrt> oh.  nice :)
[13:13] <Laney> yup
[13:13] <Laney> is there a glib test fix? :P
[13:13] <desrt> well, it's upstream now as well, fyi ;p
[13:14] <desrt> no.  didn't get a chance yet.
[13:14] <desrt> just disable it for now?
[13:14] <desrt> (guadec is busy)
[13:14] <Laney> if you think it's the test and not glib itself then sure
[13:31] <tkamppeter> seb128, I will do an upload of the current snapshot today.
[13:32] <seb128> tkamppeter, thanks
[13:43] <seb128> Laney, kenvandine: hey, do you guys know if I can do something like that
[13:43] <seb128> settingsKey = [ settingsId.key0, settingsId.key1]
[13:43] <seb128> settingsKey[0] = value
[13:43] <seb128> (that's in qml)
[13:44] <seb128> to set settingsId.key0
[13:44] <seb128> if I do "settingsKey[0]" that's going to replace the first element of the list, not set the value of the key
[13:44] <seb128> you see what I mean?
[13:44] <seb128> Saviq, ^
[13:46] <kenvandine> seb128, i'm not sure
[13:46] <Laney> I don't think so
[13:46] <seb128> :-(
[13:46] <Laney> you might have to use eval() but that seems grim
[13:46] <seb128> can I do a dynamic alias ?
[13:47] <seb128> I tried "property alias soundKey: (index == 0) ? id.key0 : id.key1
[13:47] <seb128> but it doesn't like it
[13:47] <Saviq> seb128, if you used the real property value
[13:48] <Saviq> s/value/type/
[13:48] <seb128> Saviq, you mean?
[13:48] <seb128> atm I'm doing stuff like
[13:48] <seb128>             if (soundType == 0)
[13:48] <seb128>                 soundSelector.selectedIndex = Utilities.indexSelectedFile(soundFileNames, soundSettings.incomingCallSound)
[13:48] <seb128>             else if (soundType == 1)
[13:48] <seb128>                 soundSelector.selectedIndex = Utilities.indexSelectedFile(soundFileNames, soundSettings.incomingMessageSound)
[13:48] <Saviq> seb128, i.e. bool / var / whatever instead of "alias"
[13:48] <seb128> Saviq, well, then it's not an alias anymore and doesn't get updates from my object?
[13:49] <Saviq> seb128, doesn't have to be an alias to get updates
[13:49] <seb128> or I need to "onChanged: customproperty = new value"
[13:49] <Saviq> seb128, alias is just a way to save memory
[13:49] <Saviq> seb128, "property type a: b"
[13:49] <Saviq> seb128, a will always be equal b (but a copy)
[13:49] <Saviq> seb128, "property alias a: b" means "a is b"
[13:50] <Saviq> seb128, that's a binding, it will always update
[13:50] <Saviq> seb128, unless that binding gets broken
[13:50] <Laney> do you want a dynamic binding?
[13:50] <Saviq> seb128, but then you can use Binding { }, too
[13:50] <Laney> there's Qt.binding
[13:50] <seb128> let me look at that
[13:50] <seb128> I'm a bit lost
[13:50] <Saviq> and that ↑
[13:50] <seb128> all I want is to do
[13:50] <Laney> which lets you create bindings in js
[13:50] <seb128> key = value
[13:50] <Saviq> Qt.binding ~= Binding { }
[13:51] <Laney> instead of assigning a static value
[13:51] <Saviq> seb128, that's assignment
[13:51] <seb128> where key is a different gsettings key
[13:51] <Saviq> seb128, not binding
[13:51] <Saviq> key = Qt.binding(function() { return value })
[13:51] <Saviq> is a binding
[13:51] <Saviq> as is a "property var key: value"
[13:52] <Saviq> and Binding { target: something; property: "key"; value: object.value }
[13:53] <jbicha> yay, Friday Unity upload :)
[13:53] <seb128> Saviq, Laney: basically I have that: http://paste.ubuntu.com/5940132/
[13:53] <seb128> Saviq, Laney: and I want to replace the onSelectedIndexChanged if cases
[13:54] <seb128> just do at the start
[13:54] <seb128> key = gsettings.<Keyname>
[13:54] <seb128> and use key = "value" later
[13:54] <seb128> that page is a component
[13:54] <seb128> so I want to be able to push the page with "key = incomingSound" or "key = messageSound"
[13:56] <Saviq> seb128, Binding { target: soundSettings; property: soundType == 1 ? "incomingMessageSound" : "incomingCallSound"; value: "value" }
[13:57]  * seb128 wants pointers :p
[13:58] <ogra_> <-
[13:58] <ogra_> ->
[13:58] <Saviq> lol
[13:58] <ogra_> there you go
[13:58] <Saviq> seb128, if you don't want assignments, that's what you need to do
[13:58] <seb128> Saviq, thanks, I'm going to play with that, that just seems tedious, I've several snippets in that source using the key
[13:58] <seb128> I'm pondering just doing a cp of the .qml and not use it as a component at this point
[13:58] <seb128> and sed the keyname in each copy
[13:58] <seb128> that's going to be easier ;-)
[13:59] <Saviq> seb128, so that's why you wanted "property alias: true ? a : b"
[13:59] <seb128> Saviq, yes
[13:59] <Saviq> seb128, now I got it and yeah, would make sense
[13:59] <Saviq> seb128, but I don't think possible
[13:59] <seb128> :-(
[14:00] <Saviq> seb128, that's because aliases need to be resolved very early
[14:00] <Saviq> I'd say
[14:01] <seb128> Saviq, I guess you can do "keys = [ id.key0, id.key1] and use *keys[index], e.g something that say "use the object in that index of the list"?
[14:01] <Laney> eval(keys[i] + " = " + value)
[14:01] <Laney> :(
[14:02] <seb128> e.g having a way to do "keys[0] = "value"" doing "id.key0 = value"
[14:02] <seb128> Laney, that seems hackish
[14:02] <seb128> I'm just going to keep those if/else, it's only 3 places in the file
[14:03] <Laney> it is a hackish approach
[14:03] <seb128> it's not elegant but that seems the easiest option
[14:03] <seb128> Laney, would you prefer the if/else or the eval hack?
[14:03] <Saviq> or the Binding { } ;)
[14:05] <Laney> the binding seems nice
[14:05] <Laney> I guess you can update the value dynamically
[14:06] <seb128> let me try to wrap my head around that binding stuff
[14:07] <Laney> I think it's like the dynamic alias that you want
[14:07] <Laney> but you'd do binding.value = blah
[15:07] <tkamppeter> seb128, fixed cups-filters uploaded.
[15:08] <seb128> tkamppeter, thanks
[15:30] <mfisch> seb128: is there a tool that does what dpkg -S does except for source files in source packages?
[15:30] <seb128> mfisch, google? ;-)
[15:30] <Laney> apt-file
[15:30] <jbicha> mfisch: http://codesearch.debian.net/
[15:31] <Laney> packages.ubuntu.com if it's up to date
[15:31] <mfisch> google is a good one ;)
[15:31] <jbicha> oh, codesearch is a bit different
[15:31] <mfisch> jbicha: code search is great, but doesn't have Phablet code
[15:31] <mfisch> Laney: doh I forgot about packages
[15:31] <Laney> doesn't have saucy atm :-)
[15:32] <jbicha> mfisch: build your own! http://packages.qa.debian.org/codesearch :)
[15:32] <mfisch> Laney: how often does it update?
[15:32] <Laney> don't know, sorry
[15:47] <seb128> Laney, kenvandine: https://code.launchpad.net/~seb128/ubuntu-system-settings/sound-store-sound-config/+merge/178329
[15:47] <seb128> I would appreciate review/comments
[15:48] <seb128> I spent my afternoon on that, it's not perfect, but I feel frustrated enough that I don't want to spend much more time on it today
[15:49] <seb128> Laney, the Binding{} stuff worked fine btw, but I needed several bindings and ran into property cycles ... at the end I find the if/else version of the code easier to read
[15:49] <seb128> if somebody wants to patch over that to change how things are done, that works for me ;-)
[15:51] <Laney> cool
[15:51] <bschaefer> hey, so something interesting, ibus-anthy is no longer showing up under available input engines. ibus-setup->Input Methods->Japanese
[15:52] <Laney> kenvandine: you fancy reviewing that? :P
[15:52] <Laney> I'm trying to get glib uploadable atm
[15:57] <kenvandine> Laney, i will in a few
[15:57] <kenvandine> seb128, ^^
[15:57] <seb128> kenvandine, thanks
[15:58] <attente> bschaefer, what ibus version are you running?
[15:59] <bschaefer> attente, 1.5.3
[16:05] <pitti> au revoir mes amis ! je commence mes vacances maintenant :)
[16:05] <Laney> have fun pitti!
[16:35] <attente> bschaefer, i'm not sure what it is, but possibly it's '/usr/lib/ibus/ibus-engine-anthy' aborting that's the problem?
[16:35] <seb128> kenvandine, thanks
[16:35] <seb128> ups
[16:36] <seb128> kenvandine, story, "up, enter" on the wrong screen
[16:36] <bschaefer> attente, hmm I get this: http://paste.ubuntu.com/5940701/
[16:36] <bschaefer> hangul ran fine
[16:37] <attente> bschaefer, yep, getting the same problem with Anthy
[16:38] <bschaefer> attente, very strange
[16:38] <attente> possibly fixing this will make it appear again in the engines list, but not 100% sure on this
[16:39] <bschaefer> yeah, that would be a good start, I think it broke sometime last week? Or the beginning of this one...
[16:40] <bschaefer> the last change was on july 14th though, in the changelog
[16:41] <bschaefer> that was moving to ibus 1.5, and i've had ibus-anthy working with ibus 1.5 ... strange
[16:55] <jbicha> bschaefer: there was a new ibus-anthy upload on Tuesday
[17:01] <bschaefer> jbicha, hmm that could be what ended up breaking it...though im not sure :)
[17:21]  * Laney waves
[17:21] <Laney> will be back later to upload glib but if people aren't around, have a good week or two
[17:21] <Laney> o/
[17:22] <seb128> Laney, thanks, you too, have good holidays and have fun a Debconf
[17:22] <seb128> Laney, are you at Debconf on Canonical's time?
[17:22] <seb128> Laney, e.g can we email you about stuff that week if needed? ;-)
[19:47] <bschaefer> attente, ping
[19:53] <attente> bschaefer, pong
[19:54] <bschaefer> attente, hey, soo the problem with the ibus-anthy failing to run is due to Anthy-9000.typelib only being installed into the arch folder
[19:54] <bschaefer> as it should be getting installed here: /usr/lib/girepository-1.0/Anthy-9000.typelib
[19:54] <bschaefer> attente, soo it seems to be a packaging error...
[19:55] <attente> oh. the location changed recently?
[19:55] <bschaefer> attente, it seems, its only getting installed here for me:
[19:55] <attente> (is the 9000 suffix an issue too?)
[19:55] <bschaefer>  /usr/lib/i386-linux-gnu/girepository-1.0/Anthy-9000.typelib
[19:55] <bschaefer> attente, nope, I linked it to the other folder and it worked
[19:56] <bschaefer> attente, as python doesn't support multiarch import
[19:56] <attente> interesting
[19:56] <attente> after making the link, does it appear again in the engines list?
[19:56] <bschaefer> but linking it over, and then anthy engine runs
[19:56] <bschaefer> I've not rebooted yet and should go double check that
[19:56] <bschaefer> but restarting the ibus daemon and stuff doesn't seem to work :(
[19:57]  * bschaefer reboots
[19:57] <attente> hmm...
[19:59] <bschaefer> attente, still nothing :(, soo that wasn't the problem it seems...i've actually never ran into ibus not finding installed engines before
[20:00] <attente> bschaefer, yeah, it's a strange issue. it finds skk and mozc just fine..
[20:00] <bschaefer> yeah...as this is going to be a problem for anthy users if they cant use ibus...
[20:06]  * bschaefer digs some more
[20:11] <bschaefer> also if you try to manually force anthy for ibus:
[20:11] <bschaefer> (process:3506): IBUS-WARNING **: ibus_bus_call_sync: org.freedesktop.IBus.SetGlobalEngine: GDBus.Error:org.freedesktop.DBus.Error.Failed: Can not find engine anthy.
[20:11] <bschaefer> with: ibus engine anthy
[20:26] <bschaefer> attente, hmm now anthy is working...and all I did was mess around with an xml file but even when reverting it back to the orig anthy still works
[20:26] <attente> bschaefer, i just rebuilt it and now it appears :/
[20:26] <attente> ha...
[20:27] <bschaefer> attente, well what I noticed is in /usr/share/ibus/component/ only anthy has the 1.5.3 version
[20:27] <bschaefer> all the other onces, pinyin and hangul are still 1.4.0 soo I moved anthy to that, restarted ibus and it worked but now I can't get it to not work
[20:27] <bschaefer> attente, well maybe it just needed a rebuild?
[20:28]  * bschaefer wonders if there was some sort of cache somewhere?
[20:28] <attente> i rebuilt ibus, not ibus-anthy
[20:28] <bschaefer> o just ibus?
[20:28] <bschaefer> attente, well thats strange, and you kept the ibus-anthy install to default?
[20:29] <bschaefer> ie. you didn't copy the Anthy-9000 over?
[20:29] <attente> bschaefer, it's still the same ibus-anthy, but i do have the link in the non-arch lib
[20:29] <bschaefer> attente, hmm well I think that needs to be addressed, as im not sure if that fixed it, but the engine should at lease start :)
[20:30] <attente> bschaefer, i think you're right
[20:30]  * bschaefer still lacks a lot of packaging knowledge :)
[20:30] <attente> if it's moved to the proper location, it should fix the name in the list too
[20:30] <bschaefer> yeah, I think that is what fixed it...but I think its sometimes hard to get ibus read correctly...
[20:31] <bschaefer> attente, it was also mostly bregma figuring it out :)
[20:37] <attente> bschaefer, so i guess in debian/rules we should just add --with-anthygobject-typelibsdir=${prefix}/lib/girepository-1.0
[20:38] <bschaefer> attente, that sounds right, so it'll install it there along in its arch folder still...
[20:38] <bschaefer> though it would also be nice if python looked for multiarch when importing
[20:45] <attente> bschaefer, so i adjusted the debian/rules to install it in the proper location, but it's still broken :(
[20:46] <bschaefer> attente, so its not showing up in the engine list? Also doing this gives an error? "ibus engine anthy"
[20:47] <bschaefer> attente, so, why did rebuilding ibus fix that hmm
[20:47] <attente> bschaefer, no idea, but it's definitely still broken despite the typelib being in the correct place
[20:48] <bschaefer> :(
[20:49]  * bschaefer removes the typeliib and tries to get anthy to work
[20:52] <bschaefer> attente, as soon as I removed the typelib anthy stopped working...
[20:53] <attente> it's supposed to be in /usr/lib/girepository-1.0/Anthy-9000.typelib, right?
[20:53] <bschaefer> yup
[20:54] <attente> i didn't make a mistake of some sort when installing..
[20:54] <bschaefer> thats the one I removed
[20:54] <bschaefer> attente, ibus is a mean program
[20:54] <attente> haha
[20:55] <bschaefer> and I bet if i add it back into that dir it still wont work
[20:55] <attente> ok
[20:55] <attente> i've got something new
[20:55] <attente> ImportError: No module named anthyprefs
[20:56] <bschaefer> attente, well i put it back and it worked
[20:56] <bschaefer> wth...
[20:56] <bschaefer> thats very strange, do you have the full error?
[20:56] <attente> http://pastebin.ubuntu.com/5941506/
[20:57] <attente> this is when launching ibus-daemon manually
[20:57] <bschaefer> attente, did you also do a ibus restart?
[20:57] <bschaefer> o
[20:57] <bschaefer> attente, i usually let ibus-setup launch the daemon
[20:58] <bschaefer> soo removed the typelib, it works until I do an ibus restart, but after that it stops working
[20:58] <bschaefer> then adding it back in, and restarting again it works...but now im getting confused ...
[20:59] <attente> bschaefer, indeed, me too. i can't replicate it again :S
[21:01] <bschaefer> attente, urg...hmm
[21:01] <bschaefer> attente, you added that to the ibus-anthy debian/rules?
[21:02] <attente> bschaefer,
[21:02] <attente> yes
[21:02] <bschaefer> attente, but your /usr/lib/ibus/ibus-engine-anthy is not working right?
[21:02]  * bschaefer forgot to read the error
[21:02] <attente> bschaefer, yes, still not working
[21:02] <attente> AnthyPrefs is missing
[21:03] <bschaefer> it would be nice if we had the same error...
[21:03] <bschaefer> attente, so at this point you've install ibus-anthy your self from apt-get source?
[21:03] <attente> this error might've been introduced by the changes to debian/rules
[21:03] <bschaefer> with new deb ruls?
[21:04] <bschaefer> attente, otherwise im unsure how you edited the deb rules
[21:04] <attente> i'm building from lp:ubuntu/ibus-anthy
[21:04] <bschaefer> attente, hmm that should be the same package...one would think
[21:04] <attente> my bzr diff looks like this:
[21:05] <attente> http://paste.ubuntu.com/5941543/
[21:05] <attente> bschaefer, ibus-engine-anthy runs just fine for you though?
[21:05] <attente> after moving the typelib
[21:05] <attente> ?
[21:06] <bschaefer> attente, right, only when I ln over the one from my arch folder
[21:07] <bschaefer> attente, hmm you're diff seems to be odd looking to me...
[21:07] <bschaefer> the only change I see is
[21:07] <bschaefer> --- debian/ibus-anthy.install	2013-07-14 01:01:12 +0000
[21:07] <bschaefer> +++ debian/ibus-anthy
[21:07] <bschaefer> possibly things aren't getting installed now?
[21:07] <bschaefer> o thats weird...dam pastebin
[21:08] <bschaefer> attente, try also installing it to the arch folder as well
[21:08] <bschaefer> which should mean keeping this line: -usr/lib/*/girepository-1.0/*
[21:09] <bschaefer> attente, and hmm possibly dropping this line as well: --with-anthygobject-typelibsdir=/usr/lib/girepository-1.0
[21:09] <bschaefer> if its installed in both places, it should find it in the non-arch folder
[21:09] <bschaefer> but that might be the only way it gets installed there :(
[21:10] <attente> bschaefer, you mean to basically install the unmodified ibus-anthy?
[21:11] <attente> you're asking me to drop the two changes i made :P
[21:11] <bschaefer> haha...
[21:11] <bschaefer> attente, well because for me: /usr/lib/i386-linux-gnu/libanthygobject-1.0.so
[21:11] <bschaefer> attente, and it seems it might only be getting installed to the non-arch folder...
[21:12] <bschaefer> if its only in the non-arch folder it might not be able find the that lib? /me is unsure
[21:12] <bschaefer> attente, im also don't know much about deb rule files :)
[21:13] <bschaefer> well a bit, but that line you added, im not sure if it forces it to only install in the non-arch or both
[21:14] <attente> bschaefer, it only moves it to the non-arch
[21:14] <bschaefer> hmm is it possible to install it in both places?
[21:14] <bschaefer> attente, let me remove the one from my arch folder and see if I get the same error as you..
[21:15] <bschaefer> attente, or we need to install the libs in the non-arch folders...but we might also want to poke the maintainer of ibus-anthy...
[21:15] <bschaefer> as I think this multi arch support is new
[21:15] <bschaefer> as the changelog says:   * Multi-arch updates etc.
[21:18] <bschaefer> hmm that didn't get the same error as you...why...do you get that error... hmm
[21:18] <attente> bschaefer, let me clean things up and re-install
[21:19] <bschaefer> attente, alright ... i could be adding to this confusion as well :)
[21:22] <bschaefer> attente, also if that doesn't work, possibly revert that last update and trying that?
[21:24] <attente> ok, so the link alone doesn't fix it
[21:24] <attente> this is with archive's ibus and ibus-anthy
[21:26] <attente> but the link does fix ibus-engine-anthy
[21:26] <attente> so we definitely need to move it
[21:31] <attente> installing ibus from trunk adds anthy back in the list
[21:31] <bschaefer> attente, hmm cause bregma and I are getting anthy work just fron linking it...
[21:31] <bschaefer> attente, sorry, was on the phone
[21:31] <bschaefer> hmm
[21:32] <bschaefer> attente, is there some sort of ABI break?
[21:32] <bschaefer> though we should see that when running it..
[21:33] <bregma> I doubt it's an ABI break, it really sounds more like an improperly installed file, 'salll
[21:33] <attente> bregma, for some reason linking alone isn't enough for it to appear for me
[21:33] <attente> i have to actually re-install ibus
[21:33] <bschaefer> attente, well you are also getting an odd error...
[21:34] <attente> ibus has a postinst script, but i don't think it's doing anything that would fix it
[21:35] <bregma> I did have to reboot before everything started working, so perhaps there's some config stored in memory?
[21:35] <bschaefer> there is a .cache/ibus files
[21:35] <bschaefer> but im not sure if that matters...thers also ~/.anthy
[21:36]  * bschaefer also rebooted before it started working
[21:42] <attente> rebooting didn't fix it for me :(
[21:42] <bschaefer> attente, how about an "ibus restart" ? :(
[21:43] <bschaefer> you would think a reboot would do that, and then some
[21:44] <attente> bschaefer, nope
[21:44]  * bschaefer curses at ibus
[21:44] <attente> i genuinely think it needs a re-installation of ibus...
[21:44] <bschaefer> attente, hmm well that might be touching files that makes ibus re-load files?
[21:45] <attente> bschaefer, it basically wipes its old dconf db and does a new update
[21:45] <attente> you know
[21:45] <attente> ok, one sec, let me confirm this
[21:45] <bschaefer> attente, could you attempt to touch all the files in  /usr/share/ibus/component/?
[21:45] <bschaefer> attente, alright, sounds like you are onto something waay better then what I was thinking :)
[21:47] <attente> bschaefer, arg, nope, updating the dconf db didn't work either
[21:48] <bschaefer> :(
[21:48] <attente> bschaefer, going to touch all the files
[21:48] <bschaefer> attente, cause thats what I was messing around with right before it started working
[21:48] <bschaefer> i had just moved the anthy.xml file
[21:48] <bschaefer> then "ibus engine anthy" worked
[21:49] <attente> bschaefer, touching them all worked :)
[21:49] <bschaefer> attente, haha...
[21:49] <attente> lol...
[21:49] <bschaefer> well thats strange...
[21:49] <bschaefer> as I think ibus was saving it all in "ibus read-cache"
[21:50] <bschaefer> or rather that was showing ibus was saving it all
[21:51] <attente> ok, so where does this leave us
[21:51] <attente> move the typelib basically?
[21:52] <bschaefer> yeah...but how do we get the xml files to be updated...
[21:52] <attente> but also touch anthy.xml
[21:52] <bschaefer> right
[21:52] <attente> hmm :/
[21:52] <bschaefer> hmm is correct ... hmm
[21:53] <attente> i don't know if dpkg does something smart like leave a file alone if it isn't changed between versions
[21:53] <bschaefer> I think thats what it does, cause it wont re-install something if the usr manually removed it
[21:54] <bschaefer> attente, could we add like a new line to it or something haha...
[21:54] <attente> haha
[21:54]  * attente looks left
[21:54]  * attente looks right
[21:54] <bschaefer> then the next update remove it?
[21:55] <attente> possibly..
[21:55] <attente> well, let me see if that'll work at all first
[21:55] <bschaefer> there has to be a better answer though...
[22:07] <bschaefer> attente, there is also "ibus write-cache" which might update the cache... (which should be the xml files...)
[22:08] <bschaefer> attente, all trying restarted the ibus-daemon manually might make it update the cache?
[22:08] <bschaefer> attente, as bregma didn't have to touch the components at all to get anthy working, soo we must have a workaround but not the correct way to do this
[22:09] <attente> bschaefer, sorry, i'm just running into problems with the original AnthyPrefs error again
[22:09] <bschaefer> :( dam you ibus, dam you
[22:10] <bschaefer> attente, well reading the man pages on ibus-daemon it looks like you should be able to do this to re-read the cache
[22:11] <attente> ibus-daemon -t?
[22:11] <bschaefer> yeah
[22:11] <bschaefer> with a -r
[22:11] <bschaefer> after you don't have that AnthyPref problem..
[22:12] <attente> i've only ever gotten the AnthyPrefs problem after installing the ibus-anthy which fixes the location of the typelib
[22:13] <bschaefer> attente, which i wonder if we are installing that correctly? .. hmm
[22:13] <bregma> attente, did you try building the package with "dh_auto_configure -- --libexecdir=/usr/lib/ibus --with-anthygobject-libdir=/usr/lib" in the debian/rules file?
[22:13] <attente> --with-anthygobject-libdir=/usr/lib/girepository-1.0, yes
[22:14] <bregma> --with-anthygobject-typelibsdir=/usr/lib/girepository-1.0
[22:15] <attente> er, yes, sorry
[22:15] <attente> should we be setting libdir instead?
[22:16]  * bschaefer doesn't even know what that command does
[22:16]  * bschaefer looks it up
[22:17] <bregma> I think --libdir should be left alone (it's set by debhelper for multiarch support)
[22:18] <bregma> setting --with-anthygobject-typelibsdir should force the Anthy-9000.typelib to be installed in the rightplace
[22:19] <attente> right, this works
[22:19] <bregma> which is all I did my manually creating the link on my system (which eventually started working, with a couple of reboots in between)
[22:19] <attente> but we're left with two problems
[22:19] <attente> missing AnthyPrefs error and getting ibus to recognize that the component was updated
[22:20] <bschaefer> the error: http://paste.ubuntu.com/5941543/
[22:20] <bschaefer> opps
[22:20] <bschaefer> thats the diff :)
[22:21] <bschaefer> http://pastebin.ubuntu.com/5941506/
[22:24] <bschaefer> attente, hmm I seem to get the AnthyPrefs error when I try to manually import it
[22:25] <bschaefer> soo something in that file must be including/setting some path...hmm
[22:25] <attente> bschaefer, what if you run /usr/lib/ibus/ibus-engine-anthy manually? still good?
[22:25] <bschaefer> attente, yup
[22:26] <bschaefer> soo it exists, but on some strange path...
[22:27] <bschaefer> hmm
[22:27] <bschaefer> I wish I knew python just a bit more :)
[22:28] <attente> :)
[22:28] <bschaefer> so these are together:
[22:28] <bschaefer> sys.path.append(path.join(config.PKGDATADIR, 'setup'))
[22:28] <bschaefer> from anthyprefs import AnthyPrefs
[22:28] <bschaefer> in the engine.py file
[22:29] <bschaefer> so it seems to be appending the setup to the system path file...
[22:29]  * bschaefer looks for the AnthyPref file
[22:29] <attente> i wonder if that's at all related to 'IBUS_ANTHY_PKGDATADIR=${prefix}/share/ibus-anthy'
[22:29] <bschaefer> wheres that at?
[22:30] <attente> oh... this makes sense...
[22:30] <attente> the script at /usr/lib/ibus/ibus-engine-anthy is setting it
[22:30]  * bschaefer looks
[22:30] <bschaefer> hmm mine does not set that...
[22:31] <bschaefer> this is my script: http://paste.ubuntu.com/5941795/
[22:31] <attente> D:
[22:31] <bschaefer> attente, but I found anthypref.py
[22:31] <bschaefer> /usr/share/ibus-anthy/setup/
[22:32] <bschaefer> attente, do you have that file there?
[22:32] <attente> http://paste.ubuntu.com/5941800/ <- my /usr/lib/ibus/ibus-engine-anthy
[22:32] <bschaefer> attente, what if there is an option that enables/disables the setup files from being installed?
[22:32] <bschaefer> very strange...what are ours different
[22:32] <bschaefer> s/what/why
[22:33] <attente> bschaefer, i do have /usr/share/ibus-anthy/setup/anthyprefs.py
[22:33] <bschaefer> but it looks like you are looking in
[22:33] <attente> bschaefer, i am building from trunk
[22:33] <bschaefer> /usr/share/ibus-anthy
[22:33] <bschaefer> but
[22:33] <bschaefer> urg...it should append setup to that
[22:33] <bschaefer> and find it!
[22:33] <bschaefer> attente, if that fails try my ibus-engine-anthy file :)
[22:34] <attente> this is assuming config.PKGDATADIR is the same variable
[22:34] <attente> which i guess it's not
[22:34] <bschaefer> attente, wait...now mine says the same thing
[22:34] <bschaefer> wtf
[22:34] <attente> lol
[22:34] <bschaefer> haha
[22:34] <attente> welcome to my world...
[22:35] <bschaefer> ok...i don't understand this... imust have my paths messed up
[22:35] <bschaefer> cause on 1 terminal I get your script, and on a different one I get a different scirpt
[22:35] <bschaefer> haha
[22:35] <bschaefer> attente, your world i scary
[22:36] <bschaefer> is*
[22:37] <bschaefer> attente, alright so this is super weird, if im in the directory /usr/lib/ibus and open the file im missing those exports
[22:37] <bschaefer> if I open file from another dir then I have those exports
[22:37] <attente> the dir wasn't removed at some point, right?
[22:38] <bschaefer> nope
[22:38] <bschaefer> so in my home dir: vi /usr/lib/ibus/ibus-engine-anthy I get your script
[22:38] <bschaefer> if I do cd /usr/lib/ibus/
[22:38] <bschaefer> then vi ibus-engine-anthy I get different scripts...
[22:39]  * bschaefer doesn't think matters but is slightly confused
[22:39] <attente> bschaefer, i get the same thing either way
[22:40] <bschaefer> attente, they have the same inode....so its the same file
[22:40] <attente> :S
[22:40] <bschaefer> i might be going a bit crazy haha, (joking)
[22:41] <bschaefer> attente, alright, soo what happens if you add a print statement in the engine.py?
[22:41] <bschaefer> before the import anthypref to print out the path it gets?
[22:42] <bschaefer> attente, alright, its back to normal
[22:42]  * bschaefer closed all the terminals
[22:42] <bschaefer> that was super strange...
[22:42]  * bschaefer must have had an old one cached in the background that was being opened
[22:43] <attente> bschaefer, yeah, not sure what happened there...
[22:43] <attente> anyways, my config.PKGDATADIR is wrong
[22:43] <attente> it's pointing to ../local/...
[22:43] <attente> /usr/local/share/ibus-anthy
[22:44] <bschaefer> attente, o well, that could be a problem...
[22:44]  * bschaefer is back on track
[22:44]  * attente too
[22:44] <bschaefer> mine only points to : /home/bschaefer/staging/lib/pkgconfig
[22:44] <bschaefer> my well PKG_CONFIG_PATH
[22:45] <bschaefer> attente, also what was going on is I was reading ibus-setup-anthy...geez
[22:45] <bschaefer> my config.PKGDATADIR == /usr/share/ibus-anthy
[22:46] <attente> ok, so that's one problem we can solve at least
[22:46] <bschaefer> yeah
[22:46] <attente> i'm not sure about the refresh though
[22:46] <attente> postinst script that executes ibus-daemon -r -t refresh?
[22:46] <bschaefer> attente, we might have to let the user restart the ibus-daemon on there own...
[22:46] <bschaefer> if they kill it, and like ibus-setup restart it...
[22:47]  * bschaefer doesn't like forcing that on the users though
[22:47] <attente> bschaefer, you might be right
[22:48] <attente> fixing the first problem might fix this problem
[22:48] <bschaefer> attente, right, who knows it might actually update that file...if  bug gets filed we can let them know they have to re-cache ibus-daemon
[22:48] <bschaefer> as this is really ibus's design...
[22:49] <bschaefer> attente, also someone also might come up with a better idea in the meantime :)
[22:49] <attente> bschaefer, i'm wondering if the only reason it didn't update was because ibus-engine-anthy was crashing because of the AnthyPrefs
[22:49] <bschaefer> attente, that could be, though I wasn't running into that...and I accidentally edited the *.xml file...
[22:50] <bschaefer> which caused it to re-cache, and bregma only had to restart the daemon
[22:50] <attente> true
[22:50] <attente> ok, guess we'll know in about 10 minutes
[22:51] <bschaefer> haha, you can push an update that fast?
[22:51] <attente> well, no, just build and run it locally :)
[22:51] <bschaefer> attente, o :), well that makes sense
[22:51] <bschaefer> i was thinking you were pushing to main
[23:03] <attente> sorry bschaefer, i've hit a bit of a snag, might take a bit more time to resolve
[23:03] <bschaefer> attente, no worries, I also don't want to push you to far into the night :)
[23:04] <bschaefer> as its only 4 pm here, but most people are gone for the day
[23:04] <attente> ah, where are you?
[23:04] <bschaefer> Seattle
[23:05] <bschaefer> or rather West Coast, Washington State :)
[23:11] <bschaefer> attente, ill be back in ~10-15 min
[23:11] <attente> bschaefer, no worries, i'll keep you posted
[23:15] <bregma> some people don't know the meaning of "Friday night"
[23:24] <attente> ok, think that worked
[23:36] <attente> bschaefer, hey
[23:36] <attente> so it worked
[23:36] <bschaefer> attente, yay!
[23:37] <attente> i've pushed a branch
[23:37] <bschaefer> thats good to hear...so I don't think thats too demanding on the users, but I don't really use ibus regularly so im not sure if its common to restart it
[23:37] <bschaefer> awesome, thanks for helping look into this :)
[23:38] <attente> bschaefer, not sure either, but hopefully if someone files a report, we can answer them definitively
[23:38] <bschaefer> attente, yup!
[23:39] <bschaefer> attente, and hopefully they wont even encounter this
[23:39] <attente> ideally
[23:39] <attente> i'm going to assign you the reviewer
[23:39] <bschaefer> attente, the only way someone is going to run into this is if they have updated anthy on saucy recently
[23:39] <bschaefer> sounds good
[23:39] <bschaefer> attente, do you have a link?
[23:39] <attente> thanks bschaefer
[23:39] <bschaefer> np!
[23:39] <attente> just proposing it now :)
[23:40] <bschaefer> o, well Ill wait then haha
[23:42] <attente> bschaefer, done: https://code.launchpad.net/~attente/ubuntu/saucy/ibus-anthy/move-typelib/+merge/178402
[23:43]  * bschaefer looks
[23:43] <bschaefer> hm I wonder if Im allowed to globally approve this
[23:44] <attente> bschaefer, is that disabled for you?
[23:44] <bschaefer> attente, yes it is
[23:44] <bschaefer> well I can locally do it anyway :)
[23:45]  * bschaefer isn't special enough
[23:45] <attente> mm.. guess we need someone else to do it
[23:46] <bschaefer> yeeah...and no one will be on until Monday, at lease that I would know
[23:46] <bschaefer> possibly bregma can :)
[23:46] <bschaefer> ?
[23:46] <bregma> nope
[23:47] <bschaefer> well we will have to wait for didrocks or seb128 i suppose
[23:47] <bregma> find a MOTU, they can probably do it
[23:47] <bschaefer> and mterry is gone...dang
[23:48] <bschaefer> attente, well someone will get to it, hopefully it doesn't annoy any users over the weekend :), thanks again!
[23:48] <bregma> there should probably be a bug opened in launchpad to track the problem, and link it with a bug in the BTS so the fix goes upstream
[23:48] <attente> yep, thanks bschaefer! thanks bregma!
[23:48] <bschaefer> yup, I was just about to make one
[23:49] <bregma> just so we are good free software citizens
[23:49] <attente> upstream to debian?
[23:49]  * bregma hates the rep Ubuntu has for not doing that
[23:49] <bschaefer> well im just doing the bug on ubuntu/ibus-anthy
[23:53] <bregma> hmmm, looks like Ubuntu imports from a different source than Debian does
[23:53] <bregma> interesting
[23:53] <jbicha> bregma: you mean Debian experimental?
[23:53] <bschaefer> feel free to fix it up how you see fit: https://bugs.launchpad.net/ubuntu/+source/ibus-anthy/+bug/1207921
[23:53] <ubot2`> Ubuntu bug 1207921 in ibus-anthy (Ubuntu) "ibus-anthy does not install typelib Anthy correctly, causing ibus-anthy to not work" [Undecided,New]
[23:53]  * bschaefer links branck
[23:54] <attente> thanks bschaefer
[23:54] <bregma> debian PTS: http://packages.qa.debian.org/i/ibus-anthy.html shoes the package sources as http://anonscm.debian.org/gitweb/?p=pkg-ime/ibus-anthy.git
[23:54] <bschaefer> np!
[23:54] <bregma> Ubuntu pulls from https://github.com/phuang/ibus-anthy
[23:55] <bschaefer> hmm i wonder how different it is...
[23:56] <bregma> very different, but it's misleading, because Ubuntu actually synchs with Debian directly
[23:56] <attente> their experimental is 1.5.3 though
[23:56] <bregma> the problem is the upstream project link is incorrect in the Ubuntu project, that's all
[23:56] <jbicha> bregma: where do you see that?
[23:57] <bregma> jbicha, I was chasing pointers through launchpad
[23:58] <bregma> but what really matters is the package in Debian is broken, too, so a bug should be files in the BTS and linked to the launchpad bug
[23:58] <jbicha> attente: what's with the extra line in debian/rules
[23:58] <jbicha> attente: better question...what's with the - before the rm?
[23:59] <sarnold> doesn't - before rules in Makefiles cause errors to be ignored?