[00:44] Hi folks / devs, why does Ubuntu not have the "common" way of storing keymaps? like in https://gist.github.com/anonymous/9752563 [00:46] Because the old console-data thing was awful - it required maintaining all keymaps twice, once for the console and once for X [00:46] And they inevitably got out of sync [00:46] So now we autogenerate from XKB instead [00:47] cjwatson, sounds nice. I try to come to grips with the new concept. Why?! ..because I build custom initramfs with a keymap selction menu on boot [00:48] they used to use the old keymaps style (arch, gentoo). now I port to ubuntu [00:48] could you explain to me how keymap selection in ubuntu works? [00:50] I know how "loadkeys /path/to/keymap/file" works [00:50] XKB* variables in /etc/default/keyboard [00:50] how is the new way done? [00:50] console-setup reads those and generates a keymap which is fed to loadkeys [00:51] setupcon is the thing that does the hard work there [00:51] what will I need to set a keymap manually? what tools and what directories? === _salem is now known as salem_ === salem_ is now known as _salem [00:52] well basically you need to set the right things in /etc/default/keyboard and run setupcon [00:53] it has some options if all you need to do is save the cached keymap rather than load it immediately [00:53] cjwatson, no way in "interactively" switching the keymap? [00:54] sure, you can "loadkeys LAYOUT:VARIANT" [00:54] e.g. "loadkeys gb" or "loadkeys us:dvorak" [00:55] nice. [00:55] that calls ckbcomp under the hood, which is the thing that actually compiles an xkb keymap into Linux console-speak so that loadkeys can deal with it [00:55] What tools will my "initramfs" need? only "loadkeys" as usual? Or "setupcon" as well? [00:56] setupcon also uses ckbcomp; setupcon is quite a short script, you can read it [00:56] I guess I have to strace all the tools? [00:56] or is "ckbcomp" and "loadkeys" all I need? [00:56] if you need to generate keymaps then you'll need ckbcomp and all its bits [00:57] and the XKB files [00:57] you might consider reading those off the target root filesystem instead though [00:57] rather than bloating the initramfs with them [00:57] /usr/share/X11/xkb/ ...any other directories I need? [00:57] I can't give you a complete manifest, it's 1am and I haven't looked at this stuff in some time. [00:58] cjwatson, naw, thats totaly cool. I can take it from here. Thank you tons for giving me some insight. [00:59] might also be worth looking into console-setup-mini, though it conflicts with console-setup so you may not be able to use it directly on Ubuntu; you could have a look at its source [00:59] I vaguely recall it relies on somewhat more precompilation [01:00] like I say it's been a while ... [01:00] cjwatson, do you know, by chance, any other distro that uses this new KBD concept? [01:00] I haven't kept track of whether Debian uses it by default nowadays, but we borrowed it from there [01:01] as in it was Debian that developed it to start with [01:01] we adopted it a bit more enthusiastically and did a good deal of work on it [01:01] I don't know if anyone outside the Debian ecosystem has picked it up [01:02] I ll try to come to grips with it. Maybe arch-linux likes it :D [01:03] it's apparently one of the few things not in the Gentoo portage tree [01:03] Maybe everyone can move to console/xkb map consolidation just in time for us to do away with xkb entirely and move on to something else. ;) [01:03] :D nice one [01:11] cjwatson, any idea what I migth be doing wrong? https://gist.github.com/anonymous/9753468 [01:14] latenite: keymap names don't map exactly; there's no XKB layout "us" variant "qwerty" [01:15] latenite: there's an index of sorts in /usr/share/X11/xkb/rules/xorg.lst or /usr/share/X11/xkb/rules/xorg.xml as you prefer, or you could look things up directly in /usr/share/X11/xkb/symbols/ [01:19] Keyboard/xmlreader in the console-setup source package parses xorg.xml and dumps out a Perl module with all the layouts and variants [01:20] hmm, how can I set a "us qwerty" layout with loadkeys then? [01:21] that's just "loadkeys us" [01:22] without a variant name you get the default variant for the given layout, which is almost certainly what you mean here [01:22] Is it standard for LTS releases to be released as development releases one month prior to the official launch? [01:22] yes [01:23] insofar as a development series is "released" [01:23] by which I mean, what we're doing at the moment (in-development, final beta shortly) is entirely standard for our LTS releases [01:23] Interesting. I thought someone made a mistake. [01:24] As in, I get a prompt to upgrade if I do do-release-upgrade -c -d [01:24] you are passing it -d which specifically tells it to upgrade to unreleased series [01:27] saiarcot895: What stgraber said, "-d" means "development series". [01:27] cjwatson, is there any way to generate a list of "LAYOUT and VARIANT" choices *without* parsing the /usr/share/X11/xkb/rules/xorg* files? I mean by parsing actual files/data not the indexes [01:28] saiarcot895: When we're on the ball, that works to upgrade to the next devel series literally hours after we release the previous one as stable. [01:29] latenite: I expect you could implement enough of an xkb parser to parse the symbols files directly but that seems like pointless self-infliction of pain [01:29] infinity: so even without the -d switch, it can prompt to upgrade to non-LTS releases? [01:29] there are indexes, you might as well use them [01:30] saiarcot895: I'm not sure what you mean. Without -d, it will only prompt to upgrade to stable releases. [01:30] saiarcot895: depends on what you're upgrading from. normally we wouldn't switch on upgrades without -d from an LTS until the next LTS has had its .1 [01:30] saiarcot895: Whether that's normal release or LTS is defined in /etc/update-manager/release-upgrades [01:30] as in 12.10, 13.04, 13.10, etc (after release) [01:31] cjohnston, I realy might want to do that. What is a symbol file? Could you give an example of a symbol file. [01:31] infinity: ah, ok [01:31] saiarcot895: the way this is actually implemented is with the meta-release* files on /usr/share/console-setup-mini/keyboard-configuration.config [01:31] latenite: just don't ask me for help, I'm not interested in that work :) [01:31] latenite: /usr/share/X11/xkb/symbols/* [01:31] sure ok. [01:32] cjwatson: Fantastic cross-talk in your paste there. :) [01:32] infinity: hm? [01:32] 19:31 < cjwatson> saiarcot895: the way this is actually implemented is with the meta-release* files on /usr/share/console-setup-mini/keyboard-configuration.config [01:33] Two conversations for the price of one. [01:33] oops! [01:33] saiarcot895: on http://changelogs.ubuntu.com/ that is [01:33] that probably makes slightly more sense [01:34] cjwatson: Perhaps someone should send you to bed. [01:34] (or you could fix some grub bugs...) [01:35] I was failing to understand the geda-gaf/armhf build failure, mostly [01:35] Which builds fine on a porter box, although I did "ulimit -u 500" it just in case I hit https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724922 [01:35] Debian bug 724922 in src:geda-gaf "geda-gaf: FTBFS: dh_auto_test fork bombs" [Critical,Open] [01:36] cjwatson: Would be hard to hit that bug, given that the testsuite is disabled... [01:36] Or, so bdale's changelog claims. [01:36] yeah, but just in case the disabling was broken [01:36] (which it doesn't seem to be) [01:37] Oh, the lack of log for the build on LP is annoying. [01:38] Is it actually KILLING highbank nodes? :/ [01:38] I assume it must be [01:39] But it signally failed to kill shedir ... [01:39] Failing to kill a Panda while killing a highbank is a whole new failure mode... [01:39] And entirely backwards. [01:41] This talk of killing Pandas had me concerned until I recovered context. === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [05:36] Good morning [05:37] Noskcaj: how do you mean "taken from somewhere"? I wrote the test and sent it to Debian as a bug [05:40] pitti, i don't know. I won't up around 5 minutes before i replied, and my work on that package was months ago [06:13] zul, Mind if i proposed a fix to the kazoo build failure, or is it easier if you fix it yourself? It should just be a missing nose depend [06:17] never mind, it also requires a java depend and some extra commands [07:16] good morning === doko__ is now known as doko [08:02] test rebuilds finished \o/ [08:03] doko: nice! you started them yesterday? [08:04] arm64 still has some catching up to do [08:05] hey, creation of Ubuntu Beta2 image failed with apparmor-easyprof : Depends: python3-apparmor but it is not installable [08:05] could someone have a look? [08:07] yep, it's on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt [08:07] jibel: I'll promote the binary [08:07] pitti, thanks [08:32] good morning [08:32] * zyga has a lot of TODOs today [09:16] Argh. [09:17] click is being pulled into images AGAIN. [09:18] https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1297034 [09:18] Launchpad bug 1297034 in indicator-sound (Ubuntu) "Do I really need 17 click or phone related packages on a Desktop install?" [Undecided,New] [09:20] infinity, hum, how did that happen? https://launchpadlibrarian.net/170569869/indicator-sound_12.10.2%2B14.04.20140320-0ubuntu1_12.10.2%2B14.04.20140324-0ubuntu1.diff.gz doesn't seem to have new interesting depends [09:20] + unity-greeter-session-broadcast, [09:20] seb128: ^ [09:21] that doesn't make sense that this one depends on click though [09:21] seb128: It depends on upstart-app-launch [09:22] Recommends: unity-control-center | gnome-control-center | ubuntu-system-settings | pavucontrol, [09:22] + unity-greeter-session-broadcast, [09:22] + accountsservice, [09:22] seb128: We either need a hard revert on indicator sound, or someone to surgically remove that one feature for now until it's done click-free. [09:22] seb128: Or drop that Recommends to a Suggests. [09:22] i guess the session-broadcast thing is the issue [09:23] ogra_, read backlog [09:23] oops [09:23] ogra_: you're lagging :) [09:23] infinity, I pinged thostr on another channel [09:23] seb128: Sooner rather than later, so I can spin images, ideally. :P [09:23] seb128: I pinged him 25 minutes ago though on something else and didn't get an answer… [09:23] infinity, I would go for a revert [09:23] we can just seed it directly in touch [09:23] +1 [09:24] just drop the recommends [09:24] seb128: Well, if it's a Recommends, it obviously should work without it, so just dropping to Suggests would make the world happy for now. [09:24] ogra_, are you sure it's not going to create runtime issues on desktop? [09:24] If it created runtime issues to not have it, it would be a Depends. [09:24] seb128, no idea, it is for the infographics on the phone greeter though [09:24] Unless the people doing the packaging don't understand dependencies. :P [09:24] i would suspect it is a no-op on desktop [09:25] infinity, if you want to do that sure, I've to admit I'm annoyed enough at this landing/the level of changes it has/how late that I want to drop it, but that might not be the best option :p [09:25] ogra_, it has nothing to do with infographics [09:25] seb128: I'll just lower it to a suggests for now to make the archive happy. [09:25] ogra_, it's to share sound controls/play song/etc to the greeter [09:26] seb128, well, thats part of the usermetrics/infographics stuff [09:26] ogra_, no it's not, we use the same mechanism on desktop to make the greeter display your bg image [09:26] i dont think thats an expected desktop feature [09:27] there is no such thing than desktop != phone, convergence [09:27] the current desktop greeter doesn't use those infos, but that's not the point [09:27] atm there is :) [09:27] it could, they are stored in accountsservice, that's where unity-greeter reads the background image on desktop [09:27] it could also read the play song and display it if we wanted [09:27] right, it could [09:27] those mps have nothing to do with phone [09:27] they just publish info in a store [09:28] seb128: Uploaded. [09:28] then whether the greeters use the info is orthogonal [09:28] infinity, thanks [09:28] infinity, can you mp that back to lp:indicator-sound? ;-) [09:28] seb128: Nope. I'm exercising the excellent support they have for re-integrating distro uploads. :P [09:29] infinity, that would be me (or somebody else who care about indicator) mp your change back for you [09:29] seb128: That's not how it's meant to work. The system is meant to flag an archive upload and make people act on it. [09:30] seb128: If that's not happening, it's fundamentally broken. [09:32] infinity, it's working, happening ... it's just that if you mp yourself you are a better citizen than if you wait for one of co-worker to do the work for you ;-) [09:32] same as using packaging vcs-es when there is one [09:32] seb128: An MP is a waste of time. If I can commit to that branch directly, I will. An MP isn't much better than you just applying the debdiff as a commit yourself. [09:33] the trunks can be pushed to directly for such cases [09:33] * infinity checks this theory. [09:33] in fact, there is no other way for this direction [09:33] infinity, maybe that's ok [09:34] I only go through CI since we have it [09:34] infinity: I did that for autopilot several times to integrate archive uploads [09:34] if you're in $team, which not all core-devs are [09:34] ... why am I only getting 5k/s from code.lp.net? :( [09:34] Laney: Which they should be... [09:35] pitti, well, the other way is "mp the archive diff" and add that to next landing ask [09:35] Anyhow, not feeling like criticizing process tonight. Just want to fix the package. [09:35] seb128: but that would entail an upload and a review again, both of which have alreayd happened? [09:36] pitti, right, you don't really have a choice if you don't have commit access to the trunk though [09:36] *nod* [09:36] infinity, yeah, let's move on [09:37] seb128: on that topic, I think I already asked, but I forgot: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [09:37] seb128: could indicator-datetime maybe stop having indicator-applet as preferred alternative? [09:37] Already annoyed enough that I only just noticed this and I'll have to respin xubuntu and a couple of others. [09:37] as that pulls in all the old gnome 2 stuff [09:38] pitti, it's not the issue there I think [09:38] seb128: I think back then I proposed "Depends: unity | indicator-applet | indicator-renderer"? [09:38] seb128: Right, what pitti said would work. We looked at this the other day. [09:38] pitti, other indicators do the same things and are not listed in there [09:39] seb128: Which other indicator does the same thing? [09:39] infinity, indicator-session for example? [09:39] -power has the same as recommends, hmm [09:39] or power [09:39] Huh. That's... Weird. [09:40] perhaps c-m only takes the first rdepends into account? [09:40] or indicator-messages [09:40] and -datetime is asciibetically first [09:40] hm, not asciibetically, that would be indicator-appmenu [09:40] pitti, indicator-appmenu is before [09:40] right [09:41] which has the same recommends [09:41] so perhaps first out of the randomly ordered set [09:41] well, I'm not against changing those to "unity | indicator-renderer" [09:41] but that's weird only one indicator has the problem [09:41] would it be because unity is not installable on some arch? [09:42] (it used to be because it was missing/not built on some archs, but that's not the case anymore) [09:42] seb128: last time you mentioned it was due to unity not yet being built on ppc64 [09:42] right [09:42] that has been fixed though [09:42] seb128: but why would that be an arch specific issue for only one indicator? [09:42] yeah, doesn't make sense [09:42] e. g. power and datetime are both built on all our arches [09:43] oh no, datetime is missing on arm64 [09:44] Right, let's revisit this one after we fix up some more build failures. [09:44] I've been expertly ignoring c-m for that for a while anyway. :P [09:45] Oh, FFS, after that 5k/s checkout from LP, I realised the debian/control was wrong, and I checked out the raring branch of indicator-sound. I give up. It's almost 4am. [09:46] seb128: Please merge my tiny debdiff. :P [09:46] infinity, ok [09:51] seb128: I'll work with Ted to get https://bugs.launchpad.net/ubuntu/+source/indicator-sound/+bug/1297034 fixed/eased up [09:51] Launchpad bug 1297034 in indicator-sound (Ubuntu) "Do I really need 17 click or phone related packages on a Desktop install?" [Undecided,New] [09:52] thostr_, thanks, infinity demoted the recommends to a suggests meanwhile, which we think should be good enough to resolve the issue [09:52] Hey, neat, the testsuite segfaults. [09:52] but still good to check with ted once he's up [09:52] Love this code. [09:53] seb128: yes, the less the better [09:55] * infinity head->desk. [09:55] thostr_: So, your testsuite segfaults on i386. [09:55] https://launchpadlibrarian.net/170654716/buildlog_ubuntu-trusty-i386.indicator-sound_12.10.2%2B14.04.20140324-0ubuntu2_FAILEDTOBUILD.txt.gz [09:56] pitti: You're the test king, the above mean much to you? [09:56] infinity, thostr_: that update also has a regression https://bugs.launchpad.net/bugs/1297078 [09:56] Launchpad bug 1297078 in The Sound Menu "/usr/lib/x86_64-linux-gnu/indicator-sound/indicator-sound-service:11:g_str_hash:g_hash_table_lookup_node:g_hash_table_lookup:media_player_list_greeter_iterator_real_next_value:indicator_sound_service_update_preferred_players" [High,Confirmed] [09:57] shrug [09:57] infinity, we should maybe have reverted :p [09:57] no need to past tense there [09:57] infinity: no off-hand idea I'm afraid; I've never seen these indicator tests [09:57] seb128: ted is on that already [09:58] thostr_, right, but that landed just before beta freeze, are we going to get the fix in beta and are we stucked with the buggy version until after the freeze ends?* [09:58] that's why we don't take on so much code changes late in the cycle usually :/ [09:58] seb128: Feel free to revert instead. [09:59] I'm pondering it [09:59] Bonus points if the revert fixes the i386 segv. :/ [09:59] Half our flavours are sort of blocked on producing click-free images until this is sorted one way or another. [10:00] sounds like revert is in order; that won't slow down ted or thostr_ in any way [10:01] pitti: I'm ok in reverting for now [10:01] Do it, I can accept/respin when that happens if infinity wants to go to bed [10:01] piany reason for a pretty critical bug going 4 days without attention ? [10:01] https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1295873 [10:01] Launchpad bug 1295873 in biosdevname (Ubuntu) "biosdevname messes up interface names from emX to renameX" [Undecided,New] [10:02] I can't configure my network reliably with that happening [10:02] ekarlso: There are lots of bugs. Personal attachment to one doesn't make it any more special. [10:02] But yes, that bug should be fixed by release, IMO. [10:03] well atm for me trusty is useless on 3/4 servers because it doesn't name interfaces as expected.. [10:03] I dunno how to work around it either as all the things I've done seems to not fix it [10:03] infinity: sorry, we just discovered that yesterday's langpack uploads miss a lot of files; I know why, but I'll need another full rebuild [10:03] guess i'll do Precise instead for now [10:03] infinity: I can handle it, ok if I do it now and do the queue accepts, etc? [10:04] infinity: ETA about 6 hours until everything is prepared, uploaded, built, and in the archive [10:04] pitti: Yeah, go to town. This current set of images is a wash anyway. [10:04] * didrocks does the revert [10:04] pitti: I can do respins in the morning, if people have gotten me a less crap indicator-sound by then too. [10:04] didrocks: Thanks. [10:04] infinity: I have a script for it now :) [10:04] didrocks, thanks [10:05] didrocks: pull-lp-source $pkg $oldver && apply changelog delta && dch -i? [10:06] ekarlso: biosdevname=0 should work around it [10:06] infinity: not far from that, but it handles multiple packages and so on [10:06] cjwatson: I thought we don't do biosdevname yet? [10:06] pitti: Evidently, we do. [10:06] although I recently had a bug report that claimed that lubuntu or so installs it by default [10:06] And it seems a bit goofy. [10:07] pitti: it depends on the platform [10:07] pitti: https://lists.ubuntu.com/archives/ubuntu-devel/2012-August/035670.html [10:07] bug 1293633 [10:07] bug 1293633 in biosdevname (Ubuntu) "alternate install sets up biosdevname by default" [Undecided,New] https://launchpad.net/bugs/1293633 [10:07] cjwatson: ah, thanks [10:07] well I fought against it but the server folks made me [10:08] so above bug is by design then [10:08] I don't have time to sort it out, maybe the people who made me make this change can do so. [10:08] cjwatson: Why did the server folks want it? [10:08] I've never quite grasped how it was an improvement. [10:08] the list post above should have references, maybe upthread [10:08] well it's easier to identify nic's... [10:08] if it actually works... [10:09] grrr, I'm stupid, I used the wrong version to revert to… [10:09] ekarlso: I'm not sure there's any scheme that makes it easier to identify 16 ports across 4 cards, but I'll take your word for it. :) [10:10] * infinity has always been mostly happy with the 70-persistent-names thing, so I can just make it how I want it, and it literally never changes. [10:12] Laney: Don't worry about driving my respin-fest. pitti's langpack-respin-of-doom won't be done until I'm awake again anyway. [10:12] Yeah, no worries [10:13] ok, reverted with the weirder name ever [10:13] (due to the typo in version when reverting the first time) [10:13] Do I want to look? [10:14] infinity: if you have 1 embedded card with 4 ports, and say 2*2*10gb cards [10:14] it'll be em1-4, p0pX, p1pX depending on the order in the pci [10:14] 12.10.2+14.04.20140324.is.12.10.2+14.04.20140324-0ubuntu1 ... rly? [10:14] infinity: It makes device naming deterministic even without 70-persistent-net-blah. This is pretty handy when you're doing unattended installations en masse. [10:14] didrocks: You didn't need to do that, since the previous version was never accepted... [10:14] infinity: yeah, did forget about the queue ;) [10:14] ok, doing the right version now [10:15] where to set biosdevname=0 btw ? [10:15] ekarlso: kernel cmdline. [10:15] ekarlso: Kernel command line [10:15] kk [10:15] let me try it [10:20] infinity: If you get a hundred servers at a time with (at least) two different ethernet cards, how would you make sure to assign the correct ethX to each port without biosdevname? [10:21] soren: Dumb luck? ;) [10:21] infinity: I've recently exhausted my supply of dumb luck. [10:21] (honestly, I'd probably just prefer a simple d-i thing that named the first interface with a physical link "eth0", and let the rest fall out) [10:24] infinity: I'll admit that one of the interfaces can reasonably straight forward to identify, since probably only one will be able to get an address by DHCP. [10:24] infinity: ..and if you're clever you can probably figure out the rest based on that. [10:25] infinity: Like, say, knowing that the first port on a specific card is the one connected to the DHCP-enabled network, so the subsequent 3 ethX's is probably the other ports on the same card. [10:25] infinity: ..and the remaining two are the ports on the other card. Or whatever. [10:25] infinity: ...but biosdevname really makes this much more of a no-brainer. [10:26] soren: When it works. :) [10:26] infinity: When it works. [10:27] infinity: I really wonder about the eth0->em1, eth2->em3, and eth3->em2 renaming. They're being reordered. [10:27] infinity: Well, as long as it's consistent, it's cool. [10:27] soren: Yeah. Looked like the sort of thing that would happen in an attempt to unwind a rename loop, and it got stuck part way through. === FJKong_afk is now known as FJKong [10:28] soren: That's my best guess anyway. udev used to suffer similar problems with 70-persistent if you gave it a Really Hard problem to solve (where "really hard" for udev is, like, 3 operations and short break for tea) [10:28] infinity: Yeah. I'm not particularly envious of whomever has to fix that bug. I foresee much hair pulling. [10:29] It's basically just towers of hanoi. [10:29] Which is proof that Kai never took a CS degree. [10:29] Cause every useless CS student has written a hanoi solver. [10:32] My lack of CS degree probably explains my reluctance to dig into it. [10:36] hi [10:37] anyone knows what kernel ubuntu 14.04 will use? 3.13 or 3.14? [10:37] or is that not yet decided? [10:39] ncopa: 3.13 [10:39] ok. thanks [11:25] pitti: Want to give me a poke when all your langpack stuff is done and in the release pocket? [11:25] * infinity heads to bed for a bit. === _salem is now known as salem_ [11:41] infinity: yep, will do [11:46] ev: Does 'Send a report automatically if a problem prevents login' do anything inside whoopsie? [11:48] hi, I was wondering if anyone here has some experience with shipping PAM modules [11:48] more specifically, this pam module needs to be loaded/executed by lightdm [11:49] was reading this https://wiki.ubuntu.com/PAMConfigFrameworkSpec , but I can't figure out how to make lightdm load the pam module [11:49] slangasek: ^^ [11:51] l === MacSlow is now known as MacSlow|lunch [12:08] RAOF, hi, awaiting review of gtk2/gtk3 from https://launchpad.net/ubuntu/precise/+queue?queue_state=1 === hggdh_ is now known as hggdh [12:22] Laney: nope, not yet [12:23] ev: okay, I'm going to hide that in alm then [12:23] doing some poking there [12:23] Laney: feel free to implement it :-P [12:25] oh look, a squirrel ... [12:59] why does ubuntu-restricted-addons still depend on gstreamer0.10-plugins-ugly as well as gstreamer1.0-plugins-ugly ? [13:04] Riddell: sounds wrong to me :) [13:04] Riddell: or, could be that ubuntu ships with purple on the image [13:08] doko: hey, just a heads, up, I have some ideas what's going on with bzr but I won't have time to work on that until checkbox and derivatives are all in trusty and we can be sure that the code works okay, we're still working on getting the last bits into the archive and that has priority over any work over bzr [13:08] doko: though I *really* want to work on bzr so I will try to find some time in the evening to test my theory === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [13:24] cjwatson, or xnox do you know if this was ever successfull ? [13:24] http://comments.gmane.org/gmane.linux.ubuntu.devel.discuss/14419 [13:25] i try to [13:25] kexec --type multiboot-x86 --load /mnt/boot/grub/i386-pc/core.img [13:25] and it says: [13:25] Cannot determine the file type of /mnt/boot/grub/i386-pc/core.img [13:33] hi [13:34] I would like to find someone having knowledge related to the localisation process, because I met with a strange issue, in an edition (custom) having both English and French. does someone logged in now have insights on how the locales are displayed in a given environement? [13:35] pitti, hey, any idea how to work around bug #1297276 ? [13:35] bug 1297276 in apport (Ubuntu) "apport-cli miscalculates free space and prevents from sending a report" [Undecided,New] https://launchpad.net/bugs/1297276 [13:36] melodie, hey, what do you mean? language selector has a ranking of the languages [13:36] hi seb128 [13:36] I will describe it [13:37] Saviq: in meeting, bbl [13:37] seb128 http://pastebin.fr/33138 [13:37] the description of the issue [13:40] seb128 have you seen? [13:41] and above, 'mbchk' seems to think the provied core.img is just fine http://paste.ubuntu.com/7151224/ [13:41] melodie, yeah, we would need to get details on the environment LC_ALL/LANG/LANGUAGE from that installation [13:43] seb128 I see [13:43] I can restart a vm [13:44] seb128 firing it now [13:48] seb128 environment: http://pastebin.archlinux.fr/499255 [13:49] what's the preferred way to upgrade to trusty ? [13:49] I used do-release-upgrade -d but now I'm not sure it was the best thing to do [13:50] melodie, what about echo $LANG and "locale"? [13:50] http://pastebin.archlinux.fr/499257 [13:50] this is locale [13:50] and [13:50] $ echo $LANG [13:50] en_US.UTF-8 [13:50] I'll add a screenshot of what I see [13:52] Saviq, bfiller: https://bugs.launchpad.net/unity8/+bug/1296777/comments/1 [13:52] Launchpad bug 1296777 in Unity 8 "avatar displayed incorrectly in notification" [High,New] [13:53] for some reason I have more than 300 packages being kept [13:53] seb128: I think that this is a follow up to the issue I had when I upgraded & opened a bug [13:53] MacSlow: so the same image is successfully shown in the dialer-app call log and the messaging menu [13:53] seb128 http://meets.free.fr/images/USC-en-fr.png [13:54] MacSlow: maybe look there to see how they dispay it [13:54] bfiller, can you attach the image used to the bug maybe? [13:54] Saviq: sure [13:55] MacSlow: just take a picture with the camera of yourself. It will live in ~/Pictures dir [13:55] bfiller, fwiw I can't set an image in the contacts app... it's stuck in "Loading" apparently [13:55] bfiller, Saviq: got to start the camera-app... will try to replicate bfiller's described way too now [13:56] Saviq, regarding the shell in image 259... have you seen taps on the dash just being ignored? [13:56] Saviq: hmnn, which image? everthing got released yesteday but needs a new gallery-app from the store which should have been updated in the default image [13:56] melodie, is apt-cache show gparted displaying things in english? [13:56] I will look [13:57] melodie, http://askubuntu.com/questions/313105/where-does-ubuntu-software-center-store-its-language-settings [13:57] bfiller, 258 here, was same on 256 [13:58] seb128 yes, it is in English [13:58] Saviq: strange, working for me on 256 [13:58] bfiller, can you install unity8-autopilot and run: [13:59] python3 /usr/lib/python3/dist-packages/unity8/shell/emulators/create_interactive_notification.py --icon ~/Pictures/... [13:59] melodie, ok, I don't know then [13:59]