=== Guest32079 is now known as gusnan
=== nobuto_ is now known as nobuto
=== eam_ is now known as eam
[04:54] <rsalveti> infinity: opened bug 1436162 to track the issue, still investigating though
[04:55] <ubottu> bug 1436162 in pulseaudio (Ubuntu) "[pulsesink] abort at pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:118, function pa_mutex_unlock() with libc 2.21" [Undecided,Confirmed] https://launchpad.net/bugs/1436162
[05:38] <rsalveti> infinity: is there any sane way to bisect glibc?
[05:47] <hallyn> slangasek: hi, i'm out the next two days, but if you have time would you mind looking at / sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.36-3.dsc into sid
=== tmpRAOF is now known as RAOF
=== ara is now known as Guest58945
=== fabo_ is now known as fabo
[07:27] <happyaron> doko_: some of them, definitely not all
[07:35] <dholbach> good morning
=== doko_ is now known as doko
[08:27] <doko> happyaron, you need to seed these, or depend on these, or recommend these
=== dbarth_ is now known as dbarth-afk
[09:41] <infinity> rsalveti: The upstream project, sure, the package, slightly less so...
[10:02] <svenx> GunnarHj: ref langpack-locales; i'm trying to get my autoinstaller (FAI) to set up locales for both debian and ubuntu. debian's 'locales' package has its debconf locales/locales_to_be_generated multiselect. there doesn't seem to be anything similar for langpack-locales. say, when i need en_US.utf-8 and pl_PL.utf-8 on a system
[10:02] <svenx> GunnarHj: are there alternatives to debconf for this sort of config?
=== marcusto_ is now known as marcustomlinson
[10:15] <infinity> svenx: The traditional Ubuntu way to get en and pl locales is to install language-pack-{en,pl}
[10:16] <infinity> svenx: I do plan to bring the Ubuntu and Debian locale packaging a bit closer together, so it's less surprising moving between them, but that's generally the expected "normal" way to to do it in Ubuntu.
[10:17] <svenx> infinity: hm, okay. that's fair. i had hoped to avoid the 16 additional en_* locales, but it's not a big deal :)
[10:18] <svenx> i'll just install those packages for now
[10:18] <infinity> svenx: The other option is just a late_cmd to "locale-gen pl en" (or a subset)
[10:18] <infinity> svenx: "locale-gen en_US.UTF-8 pl_PL.UTF-8" would get you exactly what you want, for instance.
[10:19] <svenx> infinity: ahh, that's perfect. i had constructed a wrong locale-gen command, apparently. so it didn't work
[10:19] <svenx> this works much better
[10:19] <infinity> svenx: That said, if the machine intends to have users who use things locally, you kinda want langpacks to go with the locales anyway.
[10:19] <svenx> infinity: agreed
[10:19] <infinity> svenx: If this is a server that just needs the locales to be able to serve web content happily, then that's less interesting, I agree.
[10:20] <svenx> that's the case here. it's just a few admins with different workstation locales, so it's nice to avoid the warnings
[10:21] <infinity> svenx: Ahh, yeah.  I find Debian's "locales-all" package is the easiest way to avoid that pain, and I intend to make locales-all work in Ubuntu too, it just keeps taking a back seat to fixing actual bugs. :P
[10:28] <infinity> rsalveti: The core from the crash might be nice.
[10:29] <infinity> rsalveti: Lemme see if I can reproduce on shedir.
[10:37] <GunnarHj> svenx: Saw you got help. I was about to suggest
[10:37] <GunnarHj> sudo locale-gen en_US.UTF-8 pl_PL.UTF-8
[10:37] <GunnarHj> too.
[10:41] <svenx> GunnarHj: yep, it works nicely
=== rbasak_ is now known as rbasak
[11:25] <Riddell> no sweetshark this week?
[11:29] <mdeslaur> Riddell: he's in #ubuntu-desktop if you're looking for him
=== _salem is now known as salem_
[11:50] <strikov> jodh: hi James! rbasak told me that you may have some clue on the current state of upstart in vivid; i'm trying to install upstart to run some tests which were not ported to systemd yet; while upstart package installs w/o any issue i get 'Name "com.ubuntu.Upstart" does not exist' while trying to use upstart; should this work or it's completely broken now? Thanks
[11:52] <rbasak> strikov: are you rebooting into upstart after installing it? Or is systemd will in use there?
[11:53] <strikov> rbasak: few weeks ago upstart package removed systemd but now it doesn't; that might be the issue
[11:54] <strikov> rbasak: what do you mean by 'rebooting into upstart'; any cmd line changes? it worked just from the box few weeks ago
[11:54] <rbasak> strikov: I'm not sure exactly, but I'd expect things not to work unless upstart is actually your system init
[11:54] <rbasak> Is it possible that you're still using systemd?
[11:54] <rbasak> Maybe try /sbin/init --version to see
[11:55] <rbasak> (systemd gives an error; upstart reports itself)
[11:55] <strikov> rbasak: error, it looks like i need to manually remove systemd; hope i won't break the instance :)
[11:55] <didrocks> strikov: if you want to boot with upstart, you need now to install upstart-sysv
[11:55] <strikov> didrocks: thanks, trying
[11:56] <didrocks> (to boot it by default, note that you have a grub entry anyway to boot it if needed while keeping systemd as the default)
[11:56] <infinity> strikov: If your goal is replacing the system init, you want "upstart-sysv", we shuffled the packages around a bit.
[11:57] <infinity> strikov: Oh, didrocks said that. :P
[11:57] <strikov> I see. So 'upstart' package adds grub entry and upstart-sysv does complete switch. Is it right?
[11:57] <strikov> didrocks: infinity: thanks!
[11:57] <infinity> strikov: "upstart" does the same thing "systemd" is.  That is, installs a non-conflicting init system that doesn't take over all the conflicting binaries like /sbin/init
[11:57] <didrocks> strikov: yeah, upstart contains the binaries, upstart-sysv do what is necessary to set upstart as default
=== Kane is now known as Guest31837
[12:54] <dz0ny> fyi recovery mode(boot option) also expects upstart but is run with systemd. Enabling network then fails
[12:55] <dz0ny> also per spec if some critical unit fails to start it should put itself to systemd recovery/emergency target
[12:55] <dz0ny> but does not
[12:56]  * dz0ny had problems recovering from bad dkms build
[12:57] <didrocks> dz0ny: interesting, the fallback to emergency mode definitively work (can tell you that with messing a lot with system units), but I guess we never played with the recovery entry mode, mind filing a bug?
[13:01] <dz0ny> didrocks: sure just tell me where :)?
[13:02] <dz0ny> i mean to which package should i attach bug
[13:02] <didrocks> dz0ny: I would say systemd first, adding the systemd-boot tag please
=== dbarth-afk is now known as dbarth
=== marcusto_ is now known as marcustomlinson_
[13:20] <rsalveti> infinity: found the issue
[13:21] <rsalveti> infinity: https://bugs.launchpad.net/ubuntu/+source/gst-plugins-good1.0/+bug/1436162/comments/6
[13:21] <ubottu> Launchpad bug 1436162 in pulseaudio (Ubuntu) "[pulsesink] abort at pthread_mutex_unlock(&m->mutex) == 0' failed at pulsecore/mutex-posix.c:118, function pa_mutex_unlock() with libc 2.21" [Undecided,Confirmed]
[13:21] <rsalveti> infinity: we're basically disabling futex_atomic_cmpxchg_inatomic with latest glibc
[13:21] <rsalveti> because it gets built with an older kernel header
[13:23] <rsalveti> as a consequence, it can't really guarantee that more than one pcond_wait will result in the correct mutext count, when it gets a broadcast signal
[13:23] <rsalveti> checking now the minimal kernel that should, in theory, support futex_atomic_cmpxchg_inatomic for arm already
[13:50] <infinity> rsalveti: 3.14.3
[13:50] <rsalveti> infinity: SMP support for futex_atomic_cmpxchg_inatomic was added in 2.6.38, but it requires !CPU_USE_DOMAINS.
[13:51] <infinity> rsalveti: Right, which means we can't make assumptions.
[13:52] <rsalveti> the restriction for CPU_USE_DOMAINS was removed in 3.14.3
[13:52] <infinity> rsalveti: But if we had that on unconditionally before (however incorrectly) and no one complained, we can carry a local patch to return to that state.
[13:52] <rsalveti> infinity: the problem is that it's always disabled atm
[13:52] <rsalveti> even if you have a compatible kernel
[13:52] <infinity> rsalveti: The bigger question becomes, though, why things are breaking with that assumption in play.
[13:53] <infinity> rsalveti: Not always, I just assume you're testing on ancient Android kernels. :P
[13:53] <mardy> mvo: hi! Not sure if this is a bug, but if I run dpkg-architecture in an 14.04 armhf chroot, DEB_HOST_ARCH is armhf; if I run the same in a 14.10 chroot, I get amd64
[13:53] <rsalveti> infinity: always because this is a build time decision
[13:53] <rsalveti> and we're building with a kernel header that is old enough for the check to disable it completely
[13:53] <infinity> rsalveti: Oh, indeed.  Sorry.
[13:53] <infinity> rsalveti: No, we're not building with old kernel headers.
[13:54] <infinity> rsalveti: But we are building with an old minkver.
[13:54] <rsalveti> exactly, that is the one used
[13:54] <rsalveti> the define was  2.6.32
[13:54] <infinity> Right.
[13:54] <infinity> But that has nothing to do with headers, just saying.
[13:55] <rsalveti> sorry, thought it was getting that from the header, but you know better
[13:55] <infinity> Anyhow, those ASSUME defs are correct.  So, it would be nice to know why things break in that configuration.
[13:55] <infinity> But if we were incorrectly building with that on before, we can do so again.
[13:55] <infinity> rsalveti: YOu can tell which headers it was built against by running the libc6 binary.
[13:56] <rsalveti> got it
[13:56] <rsalveti> they break probably because pthread_cond_wait depends on atomic operations
[13:56] <rsalveti> and in this case we had more than one thread waiting on the same condition
[13:56] <infinity> Oh, no you can't.  Huh.  I wonder who pulled that out.
[13:57] <infinity> rsalveti: Well, that's the thing.  pthread_cond_wait should have a fallback implementation.
[13:57] <infinity> rsalveti: But, whatever.  Can hunt that later.  For now, I'll confirm that this is a regression in how we're building and locally patch it.
[13:57] <rsalveti> but would it be completely safe still even if not using the correct calls?
[13:58] <rsalveti> right
[14:02] <infinity> rsalveti: A safe implementation could be written, it would just be slow.  So, the fallback is obviously buggy.
[14:02] <rsalveti> right
[14:02] <rsalveti> it's still something we want to use if the kernel supports though
[14:03] <rsalveti> too bad it's a build time decision
[14:05] <mvo> mardy: it certainly sounds like one, let me reproduce
[14:05] <infinity> rsalveti: Making all those branches be runtime decisions would slow down libc a whole lot.
[14:06] <rsalveti> infinity: right, but sucks from a distro pov
[14:06] <rsalveti> I know we have other components requiring a newer kernel, not sure what is currently the minimal one to be supported by our release
[14:12] <infinity> rsalveti: For the most part, building for an older target isn't really a big deal.  We lost one or two syscalls and noone actually cares (and we can run in chroots on older kernels, which is handy).
[14:12] <infinity> rsalveti: But in this case, yeah.  Ick.  Seems we're damned if we do, damned if we don't right now.
[14:12] <mardy> mvo: sorry, my mistake: in the 14.10 chroot, I was inside a "maint" command; to get the env right, I need to use the "run" command
[14:12] <infinity> rsalveti: I'm not happy about reverting this (since it's correct), but less happy about spending the next week trying to fix the fallback to not be broken.
[14:13] <mvo> mardy: aha, ok. thanks
[14:13] <mardy> mvo: anyway, could click set the PKG_CONFIG_PATH?
[14:13] <infinity> rsalveti: Anyhow, I assume fixing this isn't blocking anyone from getting on with life, and I can land it after the beta?
[14:16] <infinity> rsalveti: (Also, I'd just been looking at those commits, which was why the "3.14.3" response popped off the top of my head so readily, heh)
[14:16] <infinity> rsalveti: But I couldn't reproduce the issue, so looking at the commit was as far as I'd gotten.
[14:23] <rsalveti> infinity: this is currently a critical issue for touch, so if could land sooner would be nice
[14:24] <rsalveti> we basically can't use multimedia at all
[14:24] <rsalveti> but I know we have the beta restrictions, so not sure
[14:25] <rsalveti> infinity: when is beta going to be released, tomorrow?
[14:25] <infinity> rsalveti: I have no urge to respin the beta images just for this, but I can prep it now, block it in -proposed, and let it through if something else forces a respin.
[14:25] <infinity> rsalveti: Otherwise, yeah, beta should happen tomorrow.
[14:25] <rsalveti> infinity: cool, sounds like a good plan
[14:28] <mvo> mardy: how should it be set?
[14:33] <mardy> mvo: whenever I open a "run" command, I type "export PKG_CONFIG_PATH=/usr/lib/arm-linux-gnueabihf/pkgconfig/:${PKG_CONFIG_PATH}"
[14:34] <mvo> mardy: ok, I think then that makes sense indeed
[14:34] <mardy> mvo: otherwise pkg-config only looks in /usr/lib/pkgconfig/, and there isn't much there
[14:37] <mvo> mardy: does https://bugs.launchpad.net/ubuntu/+source/click/+bug/1436368 look ok?
[14:38] <ubottu> Launchpad bug 1436368 in click (Ubuntu) "set PKG_CONFIG_PATH" [Undecided,New]
[14:39] <mardy> mvo: thanks, subscribed
[15:03] <dobey> mvo, mardy: that seems weird. is that because it's the x86 version of pkg-config command being run i guess?
[15:05] <mvo> dobey: yes
[15:06] <dobey> ok yeah, makes sense to set it then, but i think for the cross-chroots we probably want to make sure /usr/lib/x86_64-linux-gnu/pkgconfig isn't in the path as well
[15:36] <seb128> hum
[15:37] <seb128> cyphermox, https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1435714
[15:37] <ubottu> Launchpad bug 1435714 in ubiquity (Ubuntu Vivid) "Keyboard layout missing during install setup" [High,In progress]
[15:37] <infinity> seb128: Is that not fixed?
[15:37] <seb128> cyphermox, I'm unsure if that's the same issue, but with today's daily ubuntu-desktop amd64, installing in french give a /etc/default/keyboard which has XKBMODEL=""
[15:37] <cyphermox> seb128: yeah, are you saying it's still happening?
[15:38] <seb128> same for XKBLAYOUT and VARIANT and OPTIONS
[15:38] <cyphermox> ok
[15:38] <seb128> infinity, ^ I guess that means not fixed?
[15:38] <seb128> or the fr issue is a different one
[15:38] <infinity> seb128: Or cyphermox just hates the French.
[15:38] <cyphermox> does it happen with fr only?
[15:39] <seb128> cyphermox, I don't know, I just did a french install, can try another locale if you wanty
[15:39] <cyphermox> I don't know
[15:39] <seb128> let me try a german one
[15:39] <infinity> seb128: You're positive it was today's daily with that version of ubiquity?
[15:40] <cyphermox> can you check /usr/lib/ubiquity/console-setup/keyboard-configuration.postinst to see if it's good?
[15:40] <cyphermox> hopefully I have the right path
[15:40] <cyphermox> I have desktop-amd64 now, I can check it quick
[15:41] <seb128> infinity, let me check, I download this morning around 11 european time
[15:41] <infinity> My ISO will be here some day so I can check...
[15:41] <seb128> I'm booting it
[15:41] <seb128> can't check from the iso menu since that machine is uefi and I don't get the nice menu where I can do f1 to get info
[15:42] <seb128> infinity, cyphermox, no, that iso has ubiquity .16, sorry about that
[15:43] <seb128> http://cdimage.ubuntu.com/daily-live/current/vivid-desktop-amd64.manifest as well
[15:43] <seb128> infinity, cyphermox, we didn't get a respin with the new ubiquity?
[15:43] <infinity> seb128: Hrm, current might not be.
[15:43] <seb128> seems so
[15:43] <infinity> seb128: 20150325 has the right version.
[15:44] <seb128> bah, current is not current :-)
[15:44] <infinity> Hence why the ISO tracker references by build number, not the current directory.
[15:44] <cyphermox> it's not right
[15:44] <seb128> hehe
[15:44] <seb128> sorry for the noise
[16:39] <arges> infinity: hey, whats with the new pending-sru.html page? i see autopkgtest failures, how should i be resolving/handling these? if the failure is a test case-problem, is there a way of re-running / etc.
[16:39] <arges> infinity: not sure if I'll get to much today, but I just dont want to mess things up
[16:43] <infinity> arges: Right now, we're not gating on any of that, just providing it as extra info.  Use at your discretion, I guess.  I've been perusing some here and there to see if they relate to the package uploaded or appear to just be broken tests, etc.
[16:44] <arges> infinity: Ok, makes sense to me.
[16:44] <infinity> arges: I don't think we'll be able to fully gate on autopkgtest for SRUs like we do for devel until we clean up a LOT of tests (and also make the infra less wobbly), so right now, it's just there to help inform your promotion decisions.
[16:44] <arges> infinity: yea if i see a legit failure, i'll investigate / comment on bug. thanks
[16:45] <infinity> arges: As for how to retry them, click the internal link instead of the external link, log in, and retry.
[16:46] <arges> ack
[16:46] <infinity> arges: Any intersection of core-dev and "can get to that bit of the Canonical network" can retry.
[16:46] <infinity> arges: Obviously, I'd prefer that second restriction go away, but I think that'll require a move from Jenkins (*spit*) to something sensible.
[16:47] <arges> yea i understand how fragile jenkins is
[17:23] <Riddell> bdmurray: could you review bug 1436328 ?
[17:23] <ubottu> bug 1436328 in apport (Ubuntu) "FFe apport-kde qt5 port" [Undecided,New] https://launchpad.net/bugs/1436328
[17:25] <bdmurray> Riddell: I don't think I'm in the right team to actually do anything about an FFe.
[17:26] <bdmurray> Oh, I see your comment now though.
[17:28] <Riddell> happyaron: fcitx is in ubuntu unity? how come I still see ibus in the seeds for it?  what do I need to do to change kubuntu?
[17:33] <happyaron> Riddell: it's now default for zh_* locale, still using ibus for others. we're trying it to decide whether we can make it default for everyone in vivid+1
[17:33] <happyaron> Riddell: so what you want, the same as ubuntu unity, or make it default directly?
[17:35] <happyaron> doko: perhaps that's not happening in this cycle, they'll be pulled by language-selector in next cycle once fcitx replaces ibus for everybody
=== anthonyf is now known as Guest6628
[17:38] <doko> happyaron, ok, demoting
[17:39] <happyaron> ok
[18:12] <Riddell> happyaron: um I don't know, I was kindae hoping you'd know!
[18:16] <happyaron> Riddell: I tend to have fcitx default for everyone in Kubuntu, but let's discuss with GunnarHj, if we want a different setup (fcitx default for everyone) from unity then we need his help
[18:17] <GunnarHj> happyaron, Riddell: I'm here now. What's up?
[18:17] <happyaron> GunnarHj: hey, will it be harmful if we add im:${LANG}:fcitx:${pkgs} for non-zh languages?
[18:18] <happyaron> I think that's what we need to have fcitx default for everyone in Kubuntu (remove ibus from its seed)
[18:19] <GunnarHj> happyaron: Does Kubuntu want fcitx default for everyone in 15.04?
[18:19] <happyaron> GunnarHj: we are discussing that, :)
[18:19] <Riddell> GunnarHj: we want whatever works best but none of us kubuntu people know that
[18:21] <GunnarHj> happyaron, Riddell: As far as I can tell out of the box, the approach which has been implemented for Chinese is generic, and can be used for any language.
[18:22] <happyaron> GunnarHj: it's temporary solution for Ubuntu unity, I doubt if we need the process for Kubuntu. Fcitx itself has much better integration with plasma desktop
[18:22] <happyaron> i.e. kimpanel plasma widget, kcm module
[18:23] <GunnarHj> happyaron: Would it be necessary to remove ibus from the seed? What about people who upgrade their Kubuntu version and used ibus up to now?
[18:24] <Riddell> GunnarHj: the seed currently has ibus-qt4 and ibus-qt5 in it, they can be removed easily enough
[18:24] <happyaron> GunnarHj: yes removing is required, and otherwise nothing will change, like what we did in Ubuntu (don't touch existing installations)
[18:25] <GunnarHj> happyaron: Since im-config (now) has ibus as default you mean?
[18:26] <happyaron> yep
[18:26] <GunnarHj> happyaron: I see. Btw, upgrades won't probably be a problem for those using ibus and want to keep it. Upgrading shouldn't uninstall ibus.
[18:27] <happyaron> GunnarHj: yes, and we need a l-s change to suggest installations of fcitx packages when needed
[18:27] <happyaron> AFAIK check-language-support is used in Kubuntu
[18:29] <GunnarHj> happyaron: Hmm... check-language-support & friends are indeed used in all the flavors. Did you see what I just did in pkg_depends? I'm not sure how to handle different approaches in various flavors...
[18:31] <happyaron> no didn't see it, it's trapped in queue I guess?
[18:31] <GunnarHj> happyaron: You can look at the branch (linked from the bug report).
[18:32] <happyaron> ok I see
[18:32] <happyaron> GunnarHj: I wonder if it will harm to add lines like im:ja:fcitx:fcitx-anthy
[18:33] <happyaron> GunnarHj: this means only when fcitx is installed, fcitx-anthy is pulled in.
[18:33] <happyaron> or this will install fcitx for everyone? (by ubiquity?)
[18:34] <GunnarHj> happyaron: I don't think it would install fcitx (unless fcitx-anthy depends on it).
[18:35] <happyaron> GunnarHj: I'm a bit confused, fcitx is seeded in "live", will that make check-language-support returns fcitx packages for all languages specified?
[18:35] <GunnarHj> happyaron: Personally I tend to think it would be better to treat Japanese just like Chinese. But maybe they aren't ready.
[18:36] <happyaron> me too, but there's no agreement yet
[18:37] <GunnarHj> happyaron: Only for Chinese... Not sure what you asked.
[18:37] <happyaron> GunnarHj: I'm think if it's possible to have fcitx default for everyone for Kubuntu only, and that means check-language-support would need to be able to suggest fcitx packages for other languages
[18:38] <happyaron> but wonders if that will effectively make fcitx installed for everyone on Ubuntu
[18:38] <GunnarHj> happyaron: The "Kubuntu only" is a problem. I'm not sure how to deal with it.
[18:38] <happyaron> GunnarHj: then let's make it the same as Ubuntu unity
[18:39] <GunnarHj> happyaron: That would certainly be easiest.
[18:39] <happyaron> ok
[18:39] <GunnarHj> happyaron: Have you thought about the other flavors? Xubuntu, Lubuntu...
[18:40] <GunnarHj> happyaron: Probably their seeds should be changed as well.
[18:40] <happyaron> yep
[18:40] <GunnarHj> happyaron: Is it on your list? ;)
[18:40] <happyaron> let me make some MPs
[18:40] <happyaron> yes as of now, :)
[18:40] <GunnarHj> Great.
[18:44] <happyaron> GunnarHj: would you mind add im:${LANG}:kde-runtime:kde-config-fcitx to pkg_depends?
[18:46] <GunnarHj> happyaron: Do you mean im::kde-runtime:kde-config-fcitx ? (i.e. for any language)
[18:47] <happyaron> no, just zh-hans and zh-hant
[18:47] <GunnarHj> happyaron: Ok, will do.
[18:47] <happyaron> great
[18:54] <happyaron> Riddell: https://code.launchpad.net/~happyaron/ubuntu-seeds/kubuntu-1430893/+merge/254134
[18:59] <Riddell> happyaron: why is that only in the installer?
[18:59] <Riddell> happyaron: do you know who makes kde-config-fcitx ? it'll need a kde frameworks 5 port
[19:00] <happyaron> Riddell: kde-config-fcitx is made by fcitx upstream,
[19:00] <happyaron> will check with him for that
[19:01] <happyaron> Riddell: about the installer-only change, check-language-support will prevent them to be removed for languages that expects to have fcitx installed
[19:01] <happyaron> Riddell: other languages still use ibus, in vivid.
[19:01] <happyaron> this makes the situation in sync with Ubuntu unity
[19:03] <Riddell> happyaron: oh clever
[19:04] <happyaron> Riddell: do I need to propose another MP for kubuntu-plasma5.vivid?
[19:06] <Riddell> GunnarHj: happyaron: im::kde-runtime:kde-config-fcitx is fine for vivid but kde-runtime will go away in future, maybe change it to kio while we're here for plasma5?
[19:06] <Riddell> happyaron: no there is no kubuntu-plasma5 in vivid that was just temporary in utopic
[19:06] <happyaron> ok
[19:07] <GunnarHj> Riddell: So it's still kde-runtime in vivid?
[19:08] <Riddell> GunnarHj: kde-runtime is kdelibs4 which is in vivid but will go away in the future, kio is an equivalent package in kde frameworks 5 land
[19:09] <GunnarHj> Riddell: Right, but is kio present in vivid, so we could refer to it now? Or will that change have to wait?
[19:09] <Riddell> GunnarHj: yes it's present on vivid
[19:09] <Riddell> GunnarHj: so change now would be good
[19:09] <GunnarHj> Riddell: Ok, will do.
[19:25] <GunnarHj> happyaron, Riddell: Revision 312 and 313 are now in the upload queue, waiting for approval.
[19:25] <GunnarHj> https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/language-selector/vivid
[19:52] <happyaron> Riddell: kcm-fcitx's KF5 port is ready, I can upload that, can you handle the approval?
[20:04] <Riddell> happyaron: ooh yes please :)
[20:05] <Riddell> thanks GunnarHj :)
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[22:46] <bdmurray> xnox: Should bug 1066480 still be assigned to you?
[22:46] <ubottu> bug 1066480 in ubiquity (Ubuntu Vivid) "Installer doesn't show encrypted partitions" [Critical,Triaged] https://launchpad.net/bugs/1066480