| === Guest32079 is now known as gusnan | ||
| === nobuto_ is now known as nobuto | ||
| === eam_ is now known as eam | ||
| rsalveti | infinity: opened bug 1436162 to track the issue, still investigating though | 04:54 |
|---|---|---|
| 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 | 04:55 |
| rsalveti | infinity: is there any sane way to bisect glibc? | 05:38 |
| 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 | 05:47 |
| === tmpRAOF is now known as RAOF | ||
| === ara is now known as Guest58945 | ||
| === fabo_ is now known as fabo | ||
| happyaron | doko_: some of them, definitely not all | 07:27 |
| dholbach | good morning | 07:35 |
| === doko_ is now known as doko | ||
| doko | happyaron, you need to seed these, or depend on these, or recommend these | 08:27 |
| === dbarth_ is now known as dbarth-afk | ||
| infinity | rsalveti: The upstream project, sure, the package, slightly less so... | 09:41 |
| 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? | 10:02 |
| === marcusto_ is now known as marcustomlinson | ||
| infinity | svenx: The traditional Ubuntu way to get en and pl locales is to install language-pack-{en,pl} | 10:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| infinity | rsalveti: The core from the crash might be nice. | 10:28 |
| infinity | rsalveti: Lemme see if I can reproduce on shedir. | 10:29 |
| 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:37 |
| svenx | GunnarHj: yep, it works nicely | 10:41 |
| === rbasak_ is now known as rbasak | ||
| Riddell | no sweetshark this week? | 11:25 |
| mdeslaur | Riddell: he's in #ubuntu-desktop if you're looking for him | 11:29 |
| === _salem is now known as salem_ | ||
| 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:50 |
| rbasak | strikov: are you rebooting into upstart after installing it? Or is systemd will in use there? | 11:52 |
| strikov | rbasak: few weeks ago upstart package removed systemd but now it doesn't; that might be the issue | 11:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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 | 11:57 |
| === Kane is now known as Guest31837 | ||
| dz0ny | fyi recovery mode(boot option) also expects upstart but is run with systemd. Enabling network then fails | 12:54 |
| 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:55 |
| * dz0ny had problems recovering from bad dkms build | 12:56 | |
| 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? | 12:57 |
| dz0ny | didrocks: sure just tell me where :)? | 13:01 |
| 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 | 13:02 |
| === dbarth-afk is now known as dbarth | ||
| === marcusto_ is now known as marcustomlinson_ | ||
| rsalveti | infinity: found the issue | 13:20 |
| 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:21 |
| 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:23 |
| 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:50 |
| infinity | rsalveti: Right, which means we can't make assumptions. | 13:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| rsalveti | right | 13:58 |
| 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:02 |
| rsalveti | too bad it's a build time decision | 14:03 |
| 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:05 |
| 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:06 |
| 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:12 |
| 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:13 |
| 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:16 |
| rsalveti | infinity: this is currently a critical issue for touch, so if could land sooner would be nice | 14:23 |
| rsalveti | we basically can't use multimedia at all | 14:24 |
| rsalveti | but I know we have the beta restrictions, so not sure | 14:24 |
| 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:25 |
| mvo | mardy: how should it be set? | 14:28 |
| mardy | mvo: whenever I open a "run" command, I type "export PKG_CONFIG_PATH=/usr/lib/arm-linux-gnueabihf/pkgconfig/:${PKG_CONFIG_PATH}" | 14:33 |
| 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:34 |
| mvo | mardy: does https://bugs.launchpad.net/ubuntu/+source/click/+bug/1436368 look ok? | 14:37 |
| ubottu | Launchpad bug 1436368 in click (Ubuntu) "set PKG_CONFIG_PATH" [Undecided,New] | 14:38 |
| mardy | mvo: thanks, subscribed | 14:39 |
| dobey | mvo, mardy: that seems weird. is that because it's the x86 version of pkg-config command being run i guess? | 15:03 |
| mvo | dobey: yes | 15:05 |
| 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:06 |
| seb128 | hum | 15:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| seb128 | infinity, cyphermox, no, that iso has ubiquity .16, sorry about that | 15:42 |
| 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:43 |
| 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 | 15:44 |
| 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:39 |
| 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:43 |
| 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:44 |
| infinity | arges: As for how to retry them, click the internal link instead of the external link, log in, and retry. | 16:45 |
| 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:46 |
| arges | yea i understand how fragile jenkins is | 16:47 |
| 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:23 |
| bdmurray | Riddell: I don't think I'm in the right team to actually do anything about an FFe. | 17:25 |
| bdmurray | Oh, I see your comment now though. | 17:26 |
| 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:28 |
| 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:33 |
| 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 | 17:35 |
| === anthonyf is now known as Guest6628 | ||
| doko | happyaron, ok, demoting | 17:38 |
| happyaron | ok | 17:39 |
| Riddell | happyaron: um I don't know, I was kindae hoping you'd know! | 18:12 |
| 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:16 |
| 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:17 |
| happyaron | I think that's what we need to have fcitx default for everyone in Kubuntu (remove ibus from its seed) | 18:18 |
| 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:19 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| GunnarHj | happyaron: Since im-config (now) has ibus as default you mean? | 18:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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:31 |
| happyaron | ok I see | 18:32 |
| happyaron | GunnarHj: I wonder if it will harm to add lines like im:ja:fcitx:fcitx-anthy | 18:32 |
| 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:33 |
| GunnarHj | happyaron: I don't think it would install fcitx (unless fcitx-anthy depends on it). | 18:34 |
| 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:35 |
| happyaron | me too, but there's no agreement yet | 18:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| happyaron | GunnarHj: would you mind add im:${LANG}:kde-runtime:kde-config-fcitx to pkg_depends? | 18:44 |
| GunnarHj | happyaron: Do you mean im::kde-runtime:kde-config-fcitx ? (i.e. for any language) | 18:46 |
| happyaron | no, just zh-hans and zh-hant | 18:47 |
| GunnarHj | happyaron: Ok, will do. | 18:47 |
| happyaron | great | 18:47 |
| happyaron | Riddell: https://code.launchpad.net/~happyaron/ubuntu-seeds/kubuntu-1430893/+merge/254134 | 18:54 |
| 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 | 18:59 |
| happyaron | Riddell: kde-config-fcitx is made by fcitx upstream, | 19:00 |
| happyaron | will check with him for that | 19:00 |
| 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:01 |
| Riddell | happyaron: oh clever | 19:03 |
| happyaron | Riddell: do I need to propose another MP for kubuntu-plasma5.vivid? | 19:04 |
| 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:06 |
| GunnarHj | Riddell: So it's still kde-runtime in vivid? | 19:07 |
| 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:08 |
| 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:09 |
| 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:25 |
| happyaron | Riddell: kcm-fcitx's KF5 port is ready, I can upload that, can you handle the approval? | 19:52 |
| Riddell | happyaron: ooh yes please :) | 20:04 |
| Riddell | thanks GunnarHj :) | 20:05 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| 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 | 22:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!