[05:50] <pitti> Good morning
[06:40] <Mirv> Laney: re: bug #1429836 I don't see the upload or changes anywhere
[07:04] <didrocks> morning
[07:05] <mvo_> hey didrocks
[07:05] <mvo_> hm, no seb yet
[07:06] <didrocks> mvo_: yeah, he's back on his French schedule
[07:06] <didrocks> meaning, up late :)
[07:07] <pitti> bonjour didrocks et mvo_, comment allez-vous ?
[07:08] <mvo_> didrocks: heh :)
[07:08] <didrocks> pitti: ça peut aller, et toi ?
[07:08] <mvo_> hey pitti! good morning
[07:08] <pitti> didrocks: I can't tell you how much fun I have :)
[07:08] <pitti> didrocks: but otherwise good, cold is by and large gone
[07:08] <didrocks> pitti: so many issues?
[07:08] <didrocks> via the switch
[07:09] <didrocks> at least, health is good!
[07:09] <pitti> didrocks: well, and questions, etc.; but making good progress
[07:09] <pitti> tackling bug 1430479 now
[08:13] <mpt> desrt, larsu, mdeslaur: Specification updated. <https://wiki.ubuntu.com/Power?action=diff&rev2=69&rev1=68>
[08:37] <larsu> mpt: thanks! Don't know if you read all of the scrollback, but we were doubting the "switch meaning of the battery icon based on which devcice has least power" approach
[08:37] <larsu> well, I think I was the only one doubting it
[08:39] <seb128> good morning desktopers
[08:43] <mpt> larsu, there’s a bug report somewhere complaining that it shows unintelligent mice too often … Apart from that, what is your doubt?
[08:48] <larsu> mpt: I have the feeling it confuses people, because they expect their laptop's battery in that position and nothing else
[08:49] <larsu> also, I goubt that it's very helpful
[08:49] <larsu> for most aux devices, you don't need battery status all the time
[08:49] <larsu> and you can always get at it in the menu (and of course you get a notification when it is empty)
[08:50] <willcooke> morning desktoppers
[08:51] <larsu> hi willcooke!
[08:51] <seb128> hey willcooke
[08:53] <didrocks> morning willcooke
[08:55] <willcooke> is this anything to do with us:  https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1424263
[08:55] <willcooke> mlankhorst perhaps?
[08:56] <seb128> yes, that's one for mlankhorst
[08:58] <mvo_> seb128: hey, good morning!
[08:58] <mvo_> seb128: so your silo - I messed that up, sorry
[08:58] <seb128> mvo_, hey, no worry, feel free to wipe my changes and do another mp/silo
[08:59] <seb128> I just wanted to help moving things forward
[08:59] <seb128> I didn't expect click to be special in landing and having to use a devel staging
[09:00] <mvo_> seb128: sorry, I think your approach is fine for a single branch like this, but I reassigned to devel out of a reflex  and now I can not land it anymore (ci-train complains)
[09:00] <mvo_> seb128: so thanks and sorry
[09:01] <seb128> mvo_, no worry, do you fix it?
[09:01] <mvo_> seb128: not yet, I was wondering if there is a magic way to just reuse the existing silo/line etc
[09:03] <Laney> yo yo
[09:04] <willcooke> what up dawg
[09:04] <seb128> mvo_, let me have a look
[09:04] <seb128> Laney, hey
[09:05] <larsu> morning Lane!
[09:05] <larsu> y
[09:06] <seb128> mvo_,we can just delete the new branches I think
[09:06] <seb128> mvo_, let me try
[09:07] <seb128> mvo_, can you mark https://code.launchpad.net/~seb128/click/initctl-not-there/+merge/252479 as approveD?
[09:09] <mvo_> seb128: oh, nice
[09:09] <mvo_> seb128: yes
[09:10] <seb128> mvo_, landed
[09:10] <mvo_> seb128: \o/
[09:10] <mvo_> seb128: you rock
[09:10] <seb128> mvo_, thanks ;-)
[09:10] <Laney> Mirv: bah, the dput was the last thing I did before shutting down yesterday
[09:10] <Laney> wonder why it didn't go
[09:10] <Laney> hey seb128 willcooke larsu!
[09:12] <Laney> luckily I suspended instead of shutting down and I can see that I did indeed dput it right ...
[09:13]  * Laney gets suspicious
[09:28] <willcooke> FJKong, ping
[09:28] <willcooke> FJKong, free for a chat with me & dpm?
[09:28] <FJKong> willcooke: pong
[09:29] <FJKong> willcooke: yes
[09:29] <dpm> o/
[09:29] <willcooke> FJKong, dpm - please join #letschatwhynot
[09:38] <Laney> Mirv: there was some kind of outage, uploaded now
[09:38] <Laney> Mirv: Would be preferable to get this fixed properly in the upstream buildsystem and also applied in Debian, if you want to do either. :)
[09:40]  * Laney hadn't used dh --until / dh --remaining for quite a while
[09:40] <Laney> felt old skool
[09:44] <Mirv> Laney: thanks! yeah it'll be put to Debian at least
[09:46] <Laney> I just do it manually because qmake is hard
[09:49] <Mirv> Laney: oh, right, I'd think qmake QT_BUILD_PARTS+=tests would have worked
[09:50] <Laney> it was hard to find documentation
[09:50] <Laney> then you see that I had to give an import path to actually run them, and only the final installed tree worked
[09:50] <Laney> because the built one didn't have qmldir files maybe?
[09:51] <Laney> anyway, improve it if you can!
[09:54] <Mirv> been there, Qt having hard to find documentation. disabling pch was another thing that was really not documented anywhere but had an option like that.
[09:54] <Mirv> yes, those import paths are pretty normal, they are similar in the already test enabled Qt packages
[10:00] <seb128> willcooke, mlankhorst, https://bugs.launchpad.net/ubuntu/+source/mesa-lts-utopic/+bug/1429529 is another not-too-different issue
[10:00] <willcooke> seb128, mlankhorst is on a day off today
[10:00] <willcooke> I'll pick it up with him tomorrow
[10:00] <seb128> willcooke, ok oh, thanks
[10:00] <Laney> JohnLea_: hi, do you think the wallpapers could be attached to bug #1429011 today?
[10:00] <seb128> willcooke, was he off yesterday as well? he missed the meeting/was not around it seems
[10:01] <willcooke> oh - yeah, so he was
[10:01] <willcooke> using up leave
[10:01] <Laney> shame we don't have a holiday calendar any more
[10:02] <seb128> yeah
[10:03] <JohnLea_> Laney, can do, I sent the final assets to willcooke yesterday
[10:04] <willcooke> JohnLea_, no assets received
[10:05] <willcooke> seb128, Laney - looks like I couldn't be bothered to add it to the calendar
[10:05] <Laney> willcooke: we can't see that anyway
[10:05] <willcooke> ??
[10:05] <Laney> UE holiday calendar
[10:05] <willcooke> oh
[10:05] <Laney> I tried to add it a while ago, no go
[10:05] <willcooke> well thats silly
[10:05]  * willcooke goes to look for a fix
[10:06] <JohnLea_> willcooke, I've forwarded the email to you again just now so you should have them
[10:06] <JohnLea_> willcooke, let me know if I need to chase alex for a compressed version, if we can use the .png version then even better
[10:06] <willcooke> JohnLea_, oh, yeah - I got that one, but I think we're waiting for compressed ones, no?
[10:07] <willcooke> heh ^^^
[10:07] <JohnLea_> willcooke, do we need it?
[10:07] <JohnLea_> willcooke, if so no prob. of course
[10:07] <willcooke> Laney, 3.3MB default wallpaper - too big>?
[10:09] <Laney> -rw-r--r-- 1 root root 3.3M Sep 17 09:18 warty-final-ubuntu.png
[10:09] <Laney> seems on a par
[10:09] <Laney> if you can do it without losing quality then that's good though
[10:11] <willcooke> JohnLea_, if you could ask Alex to take a very quick look at compressing it, that would be worth spending 20 mins on.   I don't feel comfortable making a call on whether or not the compressed version would be acceptable, better done by the original artist I think
[10:20] <mlankhorst> seb128: just dupe it
[10:20] <seb128> mlankhorst, thanks
[10:20] <mlankhorst> with bug  1424466
[10:21] <willcooke> mlankhorst, run out of horse faeces to pick up? ;p
[10:21] <seb128> mlankhorst, seems like it didn't dup (yet?)
[10:21] <seb128> mlankhorst, is that something you are looking at?
[10:32] <JohnLea_> willcooke, compressed wallpaper sent, it's now 750kb
[10:32] <willcooke> sweet!  thanks for the MBs JohnLea_ :)
[10:33] <willcooke> the internet salutes you
[10:33] <JohnLea_> willcooke, ;-)  but our number of MB of ubuntu downloaded stat for the next ubuntu release won't look as good
[10:34] <willcooke> haha!
[10:34] <willcooke> I'll download it twice
[10:35] <JohnLea_> willcooke, as long a ubuntu continues to provide a legitimate use case for the use of torrents ;-)
[10:35] <willcooke> :D
[10:36] <willcooke> Laney, seb128 - uploaded
[10:36] <Laney> ty
[10:38] <seb128> willcooke, thanks
[10:50] <Laney> i'll do that in a little while
[11:17] <seb128> bah wifi timeout issues here, could be a buggy routeur but unsure how to debug where packets get lost
[11:31] <nessita_> tkamppeter, hi! would you know of any workaround for LP #1430561 ?
[11:33] <willcooke> seb128, try running a traceroute (or tracepath) to 8.8.8.8
[11:33] <seb128> willcooke, going to try next time it does it, thanks
[11:33] <willcooke> you can expect some "no response" along the way, but you should be able to see if it is the local router or not
[11:45] <tkamppeter> nessita_, do you have hplip-gui installed?
[11:46] <nessita_> tkamppeter, yes sir
[11:49] <nessita_> tkamppeter, latest version from vivid
[11:53] <tkamppeter> nessita_, "dpkg -S models.dat"?
[11:54] <mpt> larsu, maybe that expectation is just because other platforms don’t have the feature? That would be an unfortunate reason for us to drop it
[11:56] <nessita_> tkamppeter, libsane-hpaio: /usr/share/hplip/data/models/models.dat
[11:56] <nessita_> tkamppeter, I retry yesterday and got a new error, added it as a new comment in the bug
[12:00] <tkamppeter> nessita_, probably it is some Python3 transition problem. I have added a comment asking the HPLIP developers at HP to check it.
[12:03] <didrocks> phew, systemd-fsckd logic changed
[12:03] <didrocks> I hope this time upstream won't complain :)
[12:03] <nessita_> tkamppeter, do you know if I could dowload the driver file by hand and set it up in any way to make the printer work?
[12:07] <tkamppeter> nessita_, go to http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/ and download the file corresponding to your HPLIP version, for 15.04/Vivid currently http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/hplip-3.15.2-plugin.run. The do "sudo sh hplip-3.15.2-plugin.run".
[12:08] <tkamppeter> nessita_, tell in the bug report whether this works for you.
[12:09] <nessita_> tkamppeter, thanks much!
[12:40] <Mirv> right, so it's not just SDK having troubles on 14.04.2 hwe stack but other dev packages too and even (?) installing Steam?
[12:41] <Mirv> I wonder how 12.04.x avoided the dev package installation problem if eg. libsdl & friends are involved
[12:41] <Mirv> or did apt resolving regress for the use case..
[13:39] <larsu> mpt: I don't know, maybe. I suspect it's simply confusing in its own right to be honest
[13:39] <desrt> sal, karaj
[13:39] <larsu> hi desrt!
[13:40] <desrt> moin
[13:42] <seb128> hey desrt
[13:42] <larsu> desrt: are you in hamburg?
[13:42] <desrt> not today :)
[13:42] <desrt> (or ever, since you mention it) :)
[13:43] <larsu> desrt: do we have a convention for using g_autoptr with variables that should be returned?
[13:43] <desrt> yes
[13:43] <desrt> g_steal_pointer
[13:43] <larsu> not in my glib
[13:44] <desrt> then you must not have autoptr either
[13:44] <desrt> https://git.gnome.org/browse/glib/commit/?id=e668796c5a90a19bce0ff893794817af6aad4dc2
[13:44] <larsu> let me paraphrase: not documented in my glib
[13:44]  * larsu wonders why
[13:44] <desrt> oh look.  i forgot to update -sections.txt :)
[13:44] <larsu> hehe
[13:45] <larsu> this is awesome and exactly what I was looking for. Thanks!
[13:45] <desrt> anyway... this is made exactly for this purpose, as you can see by the code example in that documentation
[13:45] <desrt> yup :)
[14:00] <desrt> larsu: tsk tsk tsk g_list_store_new() made the list as well :)
[14:00] <desrt> (or failed to make the list)
[14:01] <larsu> oops, thank
[14:01] <larsu> *thanks
[14:02] <desrt> oh.  thanks to gtk-doc choking on G_DECLARE_FINAL_TYPE
[14:02] <desrt> sigh
[14:27] <Laney> didrocks / seb128: can you promote for https://bugs.launchpad.net/ubuntu/+source/qtquickcontrols-opensource-src/+bug/1429836 if you have a minute?
[14:28] <Laney> http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[14:28] <Laney> fcitx looks interesting there
[14:29] <seb128> Laney, interesting in which way?
[14:29] <Laney> build-depends that aren't yellow, i.e. the script doesn't think they have MIR
[14:30] <seb128> weird, I'm pretty sure we have approved MIRs for it
[14:30] <Laney> perhaps some of them were missed
[14:31] <seb128> I don't think so
[14:32] <Laney> ok
[14:32] <seb128> Laney, did promote the qt one
[14:32] <Laney> thanks
[14:32] <Laney> that means image builds for us again
[14:34] <seb128> mvo__, hum, seems like my click change didn't work, not sure why :/
[14:34] <seb128> chroot.py", line 540, in create initctl = "%s/sbin/initctl" % mount FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/schroot/chroots/click-ubuntu-sdk-15.04-armhf/sbin/initctl'
[14:35] <seb128> is that line buggy?!
[14:35] <seb128>         initctl = "%s/sbin/initctl" % mount
[14:35] <seb128>         if os.path.exists(initctl):
[14:35] <seb128> I don't understand what's going on
[14:37] <ochosi> larsu: your last changes fix the hover/focus-state when i grab and move the scale, not the hover of the scalebutton itself though
[14:38] <ochosi> and actually that part worked for me before
[14:38] <ochosi> so s/fix// :)
[14:39] <larsu> ochosi: what do you mean by scalebutton?
[14:39] <larsu> the slider that you can grab?
[14:39] <ochosi> well that circular button that sits on the trough
[14:39] <larsu> hm, that works fine for me
[14:40] <larsu> does it also not work with Adwaita for you?
[14:41] <ochosi> lemme try that
[14:42] <ochosi> hm, that also doesn't seem to make a difference, no hover-highlight on the circular button/slider
[14:44] <ochosi> and sorry, yeah, i just looked it up and you're totally right. it's called the slider :)
[14:45] <ochosi> larsu: if the slider's hover works for you, i'll try to re-test it again in a clean env/vbox. maybe i've messed around with this one too much...
[14:45] <larsu> ochosi: please do. I just tested it again and it works
[14:46] <ochosi> okeydokey, i'll let you know how it goes
[14:46] <larsu> thanks
[15:03] <larsu> desrt: g_autofree is also missing
[15:04] <desrt> larsu: i'm currently kicking gtk-doc's ass
[15:05] <desrt> the markdown parser stuff is extremely confused as to whether it's meant to be processing escaped or unescaped xml
[15:10] <Laney> https://launchpadlibrarian.net/199935937/buildlog_ubuntu_vivid_i386_ubuntu_BUILDING.txt.gz
[15:10]  * Laney screams
[15:15] <mvo__> seb128: oh? meh :/ is that the autopkgtest or a local test?
[15:15] <seb128> mvo__, trying to create framework env in qtcreator
[15:17] <happyaron> attente_, seb128, I think fcitx/fcitx-qimpanel parts in bug #1363150 are released already (as well), have I missed anything?
[15:18] <seb128> happyaron, I don't know, didn't follow much those, if they are please close the corresponding bug lines
[15:19] <happyaron> seb128: I'm just double checking if I've missed something, :)
[15:19] <Laney> happyaron: please could you chase getting that all promoted to main
[15:19] <attente_> happyaron: yeah, i think those can be closed. they're already upstream long ago i think
[15:19] <Laney> see that link I just pasted, it makes desktop builds now fail
[15:19]  * happyaron looking
[15:19] <happyaron> attente_: ok
[15:58] <didrocks> pitti: my proposal for bug #1428486, instead of the dropping in .wants.d/ would be to add [Install]\nWantedBy=nsf-server.service in rpc-statd.service and rpc-statd-notify.service, then disable it by default and do the one time Wants migration
[15:58] <didrocks> pitti: that way people would be able to still enable/disable the stats
[15:59] <didrocks> (without having to mask the unit)
[15:59] <didrocks> and of course, we patch the Wants=
[15:59] <pitti> didrocks: oh, you figured out an "automatic" way to determine when we actually need statd? nice!
[15:59] <pitti> (that's what an init system should do for you, after all :) )
[15:59] <didrocks> pitti: no, we still do the one time migration
[16:00] <didrocks> but then, at least, the admin would be able to activate/disable it with traditional systemd tools
[16:06] <didrocks> pitti: phrasing on the bug report, maybe that would make more sense
[16:15] <Laney> luverly new default wallpaper
[16:16] <Laney> coming soon to a distribution archive near you
[16:16] <didrocks> \o/
[16:16] <willcooke> \o/
[16:16] <Laney> the greyscale one is about to burn my eyes out
[16:41] <attente_> seb128: hey, i just filed this: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1430893, but i'm not sure if we want to do the depends on the meta package, or do the depends on u-c-c like we did with ibus
[16:42] <seb128> attente_, I don't think we want to install fcitx by default? maybe make language selector install it/part of the chinese langpacks?
[16:44] <attente_> oh, ok, that sounds better
[16:46] <didrocks> the langpacks dep sounds the best (worth telling it in the FFe I guess)
[16:46] <didrocks> but the wrong build-dep should be fixed first
[16:48] <attente_> didrocks: what's the build-dep issue? those packages are approved for main but not in main yet?
[16:50] <didrocks> attente_: no, there has been some additional build-dep since the MIR was approved that was added, but not in main
[16:50] <didrocks> happyaron is fixing it and removing them
[16:50] <didrocks> so you need to wait for that to be in before getting the FFe approved and packages promoted
[16:51] <Laney> the promoting can definitely happen independently
[16:51] <didrocks> Laney: well, I certainly don't promote packages which have build-dep in universe
[16:51] <didrocks> you never know what or when the next "fix upload" would happen
[16:51] <Laney> I didn't say now, I said independently
[16:51] <Laney> it's not tied to making it the default
[16:51] <Laney> u-s-d is already pulling fcitx into main
[16:53] <didrocks> as recommends, so at least, won't block image build (but it's a build-dep also, which worked through the train PPA :/)
[16:54] <didrocks> shouldn't the recommends be fcitx-data | ibus (>= 1.5.0), rather (or the other way around?)
[16:55] <didrocks> I didn't follow, that may have been discussed here already
[16:55] <Laney> https://launchpadlibrarian.net/199935937/buildlog_ubuntu_vivid_i386_ubuntu_BUILDING.txt.gz sure is blocking builds
[16:56] <happyaron> seb128: if we don't seed it, then users will get input method changed after installing langpacks, is that expected?
[16:56] <didrocks> Laney: I was talking about the build of u-s-s itself
[16:56] <seb128> happyaron, why would they?
[16:56] <seb128> happyaron, or do you mean chinese users only?
[16:57] <happyaron> seb128: yes, they'll get ibus after installed the system, and installing langpacks make it change to fcitx
[16:57] <happyaron> that's wired experience
[16:57] <seb128> don't we have a chinese iso?
[16:58] <happyaron> weird
[16:58] <Laney> didrocks: oh, misundersood because you said "image build"
[16:58] <happyaron> no we don't
[16:58] <Laney> anyway this is why it need to be promoted sooner rather than later
[16:59] <didrocks> Laney: no, I was talking about the package build (due to the ppa usage, that wasn't spotted), of course image build are screwed :/
[16:59] <seb128> happyaron, I don't think we should put ibus & fcitx on the iso
[17:01] <happyaron> seb128: with both of them it looks odd, but it doesn't waste space, things like ibus-pinyin (and its database) is replaced by fcitx ones, and the framework itself isn't large
[17:02] <seb128> happyaron, can you look at how much space difference we are talking about?
[17:02] <attente_> Laney: do we need a separate MIR for those packages? or could we just reuse the old one?
[17:03] <happyaron> seb128: sure
[17:04] <Laney> attente_: Don't know if it matters much, talk to a MIR guy :-)
[17:04] <Laney> sounded like happyaron was working on it though
[17:04] <attente_> oh, ok
[17:04] <seb128> happyaron, thanks
[17:05] <happyaron> attente_ Laney we don't need them, fcitx-qt5 is in -proposed, and I'm testing the presage patch atm
[17:06] <Laney> hope you're forwarding back :P
[17:09] <attente_> happyaron: but what about the other gclient packages?
[17:10] <attente_> libfcitx-gclient0, libfcitx-config4, libfcitx-utils0, fcitx-data
[17:10] <attente_> *fcitx packages
[17:11] <happyaron> attente_: they aren't using extra-cmake-modules, only fcitx-qt5 does
[17:11] <attente_> oh ok
[17:15] <didrocks> happyaron: attente_: seb128: Laney: I just calulated seeing the Recommends/Deps, I'm already at 6megs compressed
[17:15] <seb128> didrocks, yeah, I seemed to remember that it was quite some "to download" to apt-get install fcitx
[17:15] <didrocks> I don't think it's desirable to grow our target image size by 6%
[17:15] <didrocks> hum
[17:15] <didrocks> 0.6% :)
[17:16] <didrocks> (and it's packed, so more onced unpacked)
[17:16] <seb128> no, we don't want more than a few mbs
[17:16] <seb128> it seems wrong anyway to have 2 IM frameworks on the iso
[17:16] <didrocks> I think we should really have that optional in the code
[17:17] <attente_> sorry, what are our options again? make language-selector install it, or have the depends on language-pack-zh-*?
[17:17] <happyaron> didrocks: we'll remove ibus pinyin related stuff at the same time
[17:17] <didrocks> attente_: have the depends on language-pack-zh-*, and having u-c-c and other things pulling it having a fcitx | ibus
[17:18] <didrocks> happyaron: ok, so you are going to patch u-c-c, u-s-s and so on to remove the fcitx-data dep?
[17:19] <didrocks> (I only started from the u-s-s changes)
[17:19] <happyaron> didrocks: wait, did you count the space get freed after removing ibus-pinyin/libpyzy-1.0-0?
[17:20] <Laney> willcooke: did you see that someone is complaining about jpeg compression artifacts on the wallpaper?
[17:20] <Laney> is that legit if you compare to the original one?
[17:20] <willcooke> checking...
[17:20] <willcooke> design were happy with it, so.. ?
[17:21] <didrocks> happyaron: no, I didn't see that removal in the MP
[17:21] <didrocks> I really think as well though that both shouldn't be installed
[17:22] <Laney> Seems like language-selector should set it up for you
[17:22] <Laney> not sure how hard that would be to implement though
[17:22] <willcooke> Laney, hrm - yeah, it's suboptimal - I'll upload the big one
[17:22] <Laney> willcooke: ack
[17:22] <didrocks> attente_: is the code that entered as part of that landing is optional? like if -data isn't installed, the code will still run?
[17:23] <happyaron> didrocks: pinyin was seeded long ago when sabdfl was asked to include full Chinese support in default installation
[17:23] <attente_> didrocks: checking
[17:24] <willcooke> Laney, done
[17:25] <happyaron> didrocks: I prefer removing ibus-pinyin/libpyzy from cdimage, and add fcitx/fcitx-pinyin/fcitx-module-cloudpinyin instead
[17:25] <Laney> oh yeah, you can tell the difference
[17:25] <happyaron> fcitx-pinyin is much smaller than ibus-pinyin/libpyzy though
[17:25] <willcooke> JohnLea_, compressed version was sucky ^^^ ;)
[17:26] <seb128> happyaron, how would that work for ibus users?
[17:26]  * Laney tries a pngcrush on it
[17:27] <Laney> 2.8M \m/
[17:27] <happyaron> seb128: pinyin is only used to type Chinese, and we are seeking to change the default for Chinese
[17:29] <happyaron> also, people will probably tend to install ibus-sunpinyin if they really want use ibus to input Chinese for everyday life, but the database is even larger so not able to get included to cdimage
[17:30] <attente_> didrocks: no, it seems that we need fcitx-data because it provides the template file for fcitx' configuration
[17:31] <didrocks> happyaron: do you have a MP to remove ibus-sunpinyin and libpyzy-1.0-0 from the seeds?
[17:31] <didrocks> sounds like we are quite in a stuck situation, but let's focus on getting things fixed
[17:31] <didrocks> (not tonight for me anyway, but drop me an email if you need me to track it for tomorrow)
[17:32] <didrocks> still sounds suboptimal to have code depending on 2 IMs
[17:32] <happyaron> didrocks: I can propose a MP for the FFe
[17:32] <didrocks> sounds good, then, we'll see how much we win/loose on the image
[17:32] <didrocks> and decides from that what to do
[17:33] <happyaron> ok
[17:33] <didrocks> if the FFe is accepted
[17:33] <didrocks> attente_: I'm surprised that you hard-dep on fcitx-data as it's only a recommends
[17:33] <didrocks> attente_: shouldn't that be a dep then?
[17:34] <attente_> didrocks: this is in u-c-c, right?
[17:35] <didrocks> attente_: ah, I thought you talked about u-s-s
[17:35] <didrocks> ok, it's a dep in u-c-c
[17:35] <attente_> didrocks: it's only a recommends in u-s-d because it uses it only once for the migration which i guess is not a good enough reason to have a hard dep
[17:36] <didrocks> attente_: sounds ok then
[17:36] <attente_> but for u-c-c it's needed if the user is going to be able to edit their per-window options
[17:37] <didrocks> let's see once it's done how many space difference (with the unseeding) that's going to result in
[17:37] <didrocks> just fix the image build meanwhile (hoping it's the only remaining issue and we'll get an image tomorrow)
[17:37] <didrocks> and then, we'll refine :)
[17:38] <attente_> yes :)
[17:38] <didrocks> attente_: happyaron: just a warning, I think we'll go on war again on image size soon, and that one would probably be something to do
[17:38] <didrocks> only ship, per language, one IM
[17:38] <didrocks> and have some optional dep
[17:38] <didrocks> would have been great to do it from day 0
[17:39] <didrocks> so I hope you will ready once this happens :)
[17:39] <happyaron> didrocks: next cycle we'll decide on ibus vs fcitx, which is the only one to keep
[17:39] <didrocks> happyaron: ok, let's see then, do you already have a methodology to decide?
[17:40] <didrocks> like how to reach users from different cultures using different layouts?
[17:40] <happyaron> almost, as part of fcitx upstream we've done that for quite some time
[17:41] <didrocks> ok, let's plan on how you will post the results next cycle early enough
[17:41] <JohnLea_> willcooke, can we use the non-compressed version then?  bandwidth and storage is cheep and only getting cheeper ;-)
[17:42] <seb128> mvo, the click chroot seems to work now, I wonder if I had a staled instance or copy earlier...
[17:42] <seb128> didrocks, ^
[17:42] <happyaron> :)
[17:42] <didrocks> seb128: ah interesting, the error you pasted made no sense :)
[17:42] <didrocks> seb128: is there any chroot daemon, keeping old copy?
[17:43] <seb128> didrocks, indeed not
[17:43] <seb128> didrocks, I don't know enough about schroot/click to say
[17:43] <seb128> maybe mvo knows ;-)
[17:43] <didrocks> ps aux | grep click ? ;)
[17:50] <JohnLea_> willcooke, ping
[17:50] <willcooke> JohnLea_, :D
[17:50] <willcooke> JohnLea_, sorry - was otp
[17:50] <willcooke> back now
[17:50] <JohnLea_> willcooke; could we delay the default wallpaper submition until end of play Friday?
[17:50] <willcooke> Laney, ^^
[17:50] <willcooke> JohnLea_, we can always upload a newer one
[17:51] <JohnLea_> willcooke; marcus has decided there are a couple of things that need to change
[17:51] <willcooke> sure, no worries
[17:51] <Laney> It's already uploaded
[17:51] <willcooke> (I think)
[17:51] <Laney> also UserInterfaceFreeze is tomorrow
[17:51] <JohnLea_> willcooke; ok, I'll sent the updated version over on friday, many thanks!
[17:51] <Laney> ...but minor changes are probably okay...
[17:51] <seb128> those are bugfixes I guess :-)
[17:51] <willcooke> ha!Q
[17:51] <JohnLea_> Laney, it will only be subtle modifications to the wallpaper pattern, so changing this after won't impact documentation
[17:51] <willcooke> So as long as it's not more naked people, I think we'll be OK JohnLea_
[17:52] <Laney> okay
[17:52] <JohnLea_> willcooke; I'll pass on the no more naked people message to our visual designers ;-)
[17:52] <willcooke> lolz, please do :)
[18:11]  * Laney phases out
[18:16]  * willcooke -> EOD
[18:20] <GunnarHj> attente_: ping?
[18:20] <attente_> GunnarHj: hey
[18:22] <GunnarHj> attente_: Saw bug #1430893. It looks to me as if a couple of changes in pkg_depends would be sufficient.
[18:23] <attente_> GunnarHj: possibly. we just had a discussion about it, but we're waiting on some build failures to be resolved
[18:24] <GunnarHj> attente_: Ok.. Where did the discussion take place?
[18:24] <attente_> GunnarHj: this channel
[18:24] <GunnarHj> attente_: Thanks, will take a look.
[18:45] <happyaron> GunnarHj: updated the FFe just now
[19:15] <GunnarHj> happyaron: Is the plan to have fcitx *installed* on all machines, or just have it available on the CD for those who choose a Chinese locale at installation?
[19:15] <happyaron> GunnarHj: installed
[19:15] <GunnarHj> happyaron: In 15.04?
[19:15] <happyaron> GunnarHj: yep
[19:16] <happyaron> GunnarHj: installed, but only made default for Chinese locale
[19:16] <GunnarHj> happyaron: Ok, then I realize there is a need to reconsider a few things...
[19:16] <happyaron> :)
[19:59] <attente_> is there an alternative to ubuntu-desktop-next that works with systemd? can't seem to install it without upstart
[20:09] <seb128> attente_, what do you mean by alternative?
[20:09] <seb128> ubuntu-desktop-next should still work
[20:10] <seb128> we still install upstart for user sessions anyway even on unity7
[20:11] <attente_> seb128: it conflicts with systemd-sysv, no?
[20:12] <attente_> ubuntu-touch-customization-hooks seems to depend on upstart
[20:15] <Laney> desktop-next didn't switch yet
[20:17] <seb128> attente_, can you describe the issue/what you are trying to do exactly?
[20:18] <attente_> just trying to install ubuntu-desktop-next
[20:18] <seb128> why?
[20:19] <seb128> you rather want unity8-desktop-session-mir no?
[20:19] <seb128> desktop-next is an iso
[20:19] <seb128> if you want an unity8 session on your normal system just install that one?
[20:20] <attente_> ah, ok. that worked. thanks seb128!
[20:21] <seb128> yw
[22:14] <robert_ancell> tjaalton, did you reject the right SRU for lightdm to utopic?
[22:15] <robert_ancell> The email suggests you rejected 1.12.3-0ubuntu1 which should replace the current 1.12.2-0ubuntu1 in -proposed.
[22:15] <tjaalton> robert_ancell: there were two uploads of the same
[22:16] <robert_ancell> oh, weird
[22:16] <tjaalton> so I rejected the slightly older one
[22:16] <tjaalton> #1383321 from the old upload is still unverified
[22:17] <robert_ancell> tjaalton, ah, thanks
[22:18] <tjaalton> #1190344 too
[22:19] <robert_ancell> that one was only partially fixed in 1.12.2, it should be fully fixed in 1.12.3
[22:20] <tjaalton> ah
[22:54] <ochosi> larsu: a late re: sound indicator scale slider hover – it works! well done!