[04:50] <pitti> Good morning
[06:59] <dholbach> good morning
[08:53] <Mirv> I wonder if others are getting the graphical apt icon from time to time claiming KeyError "The cache has no package named 'ubuntu-emulator-runtime'" and if there's something that would need fixing. I think the package was this i386 only package?
[08:53] <Mirv> sometimes I don't have it, but I remember having it already a month ago or so
[08:54] <Mirv> right, from the 'android' source
[10:57] <rbasak> mvo_: have you seen bug 1341320? There's also http://askubuntu.com/questions/496199/hwe-support-status-does-not-tell-me-how-to-upgrade-to-12-04-5 which I think is the same thing.
[11:00] <mvo_> rbasak: no, haven't see it, thanks for the notificiation
[14:27] <rharper> hallyn: I rebuilt qemu with the debdiff for the mknod kvm stuff -- it didn't build qemu-keymap -- so my upgrade of packages is failing ... what am I missing?
[14:27] <hallyn> rharper: i'm probably pushing to archive soon.  but, qemu-keymap is obsoleted
[14:27] <hallyn> it'll get removed when you upgrade
[14:28] <rharper> hrm, ok, maybe I'll just uninstall it
[14:28] <rharper> just trying to confirm that the upstart job does create the node file inside a container
[14:28] <hallyn> the packaging should mamke it uninstall
[14:28] <rharper> it didn't
[14:28] <hallyn> pkg is built at ppa:serge-hallyn/virt
[14:28] <hallyn> you can jsut add that and dist-upgrade
[14:28] <rharper> ok, lemme give that a try then
[14:29] <hallyn> ok then i'll wait for your report before pushing to utopic
[14:32] <rharper> hallyn: is that utopic only or should trusty versions be in there?  I added and updated, but I don't see a qemu 2.1 via showpkg for qemu-system-x86
[14:33] <hallyn> rharper: utopic only
[14:33] <hallyn> i don't think we can sru that to trusty
[14:33] <hallyn> it's tiny, but stlil a feature
[14:33] <rharper> urg
[14:33] <rharper> that's fair
[14:33] <rharper> hallyn: lemme try on utopic then
[14:34] <aliljet> hi!  I was wondering if there's an up to date ubuntu-recommender repo?
[15:31] <slangasek> doko: fwiw I'm giving back freetype for ppc64el, this doesn't look like a freetype bug there's no error output from the compiler
[15:34] <barry> doko: webob retry succeeded
[15:35] <doko> barry, good, can you look at the other python-* ftbfs too?
[15:36] <barry> doko: yep, it's one of my background tasks
[15:37]  * barry likes test suites that take 20m to run
[15:58] <doko> slangasek, freetype, looks like an issue with -fPIC only ... libtool sends this output happily to /dev/null
[15:58] <doko> afk
[16:00] <slangasek> doko: what an absurd thing for libtool to do!
[16:10] <Mirv> compiz would like to have core-dev ack for the dependency changes https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/8/artifact/packaging_changes_compiz_1%3A0.9.12+14.10.20140918-0ubuntu1.diff
[16:19] <flexiondotorg> slangasek, Me again. We been testing full disk encryption using Ubuntu 14.10 daily with mixed results.
[16:20] <camako> pitti, ping! Will you be releasing a new version of umockdev? We (in the mir team) are looking forward to the O_TMPFILE fix...
[16:20] <flexiondotorg> slangasek, I can reliably reproduce installing a fresh 14.10 daily with full disk encryption enabled and then on first boot Plymouth will display just a black screen.
[16:20] <flexiondotorg> If I switch to vt1 and back to vt7 I see the Plymough graphical theme and pass phrase entry but Plymouth will not accept my pass phrase.
[16:21] <flexiondotorg> This is using hardware with open source radeon driver.
[16:21] <flexiondotorg> However, doing the same on hardware with Intel integrated chipset, everything works fine.
[16:29] <slangasek> flexiondotorg: ok, useful info; I'm not sure if I have a radeon system here to test on but I'll try to figure that out
[16:30] <flexiondotorg> What we have also discovered is if we disable vt_handoff. Everything appears to work correctly.
[16:30] <flexiondotorg> slangasek, Have tested that theory extensively but so far a busted system can be made to work.
[16:31] <flexiondotorg> s/Have/Have not/
[16:56] <doko> slangasek, freetype is an include issue ... /home/doko/tmp/freetype-2.5.2/freetype-2.5.2/include/freetype.h:33:28: fatal error: ftconfig.h: No such file or directory
[16:56] <doko>  #include FT_CONFIG_CONFIG_H
[16:56] <doko>                             ^
[16:57] <doko> -I ./builds/unix is on the command line, but it should be -I ../builds/unix
[18:42] <Chipaca> in 14.04.1 a package has MultiArch: foreign, and i can depend on it on an i386 package and install it on amd64 and everything works
[18:42] <Chipaca> in 14.10 it has no MultiArch, and I can't
[18:42] <Chipaca> is that a bug?
[18:45] <jtaylor> which package?
[19:06] <flexiondotorg> slangasek, Back from my run if you have any questions regarding Plymouth.
[19:06] <flexiondotorg> Or rather the testing we've been doing.
[19:10] <smoser> cjwatson, do yo uhave  aminute ?
[19:11] <smoser> i'm trying to figure out what d-i does in install on ppc64el that i'm not doing
[19:17] <smoser> i'm prety sure its doing something to get /boot/grub/grub or /boot/grub/powerpc-ieee1275/core.elf onto /dev/sdb1 (the EFI system partition)
[19:17] <smoser> but it is moderately different
[19:18] <smoser> heres what the installed d-i system looks like : http://paste.ubuntu.com/8374462/
[19:21] <slangasek> flexiondotorg: mostly it's down to me laying hands on a radeon machine, I think
[19:22] <flexiondotorg> I'd send you one of mine but as I unerstand we are separated by some many thousands of miles 😞
[19:23] <zul> barry: ping https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907 is there we can do anything about this?
[19:23] <flexiondotorg> slangasek, Just used todays image and no need to vt switch but I still can't get Plymouth to accept the pass phrase.
[19:25] <slangasek> flexiondotorg: I'm reasonably certain that there are radeon machines closer to hand, yes
[19:27] <flexiondotorg> slangasek, I've asked a couple of the other guys to join us here to explain what they have doscovered using virtualisation platforms such as Vbox and QEMU.
[19:27] <flexiondotorg> Not sure if they will take the bait and join though.
[19:30] <slangasek> flexiondotorg: results in virtualized environments don't tell us why it's not working on radeon; VMs have different video drivers, and have been mostly-broken for a while with most of the VM video options
[19:31] <flexiondotorg> slangasek, Fair enough. But in some virtualised environment it works and others it doesn't. I thought it might be an easier way to gather some test data?
[19:31] <slangasek> flexiondotorg: well, that would be useful data to have, but it still wouldn't help us for radeon
[19:32] <flexiondotorg> slangasek, Agreed. But I don't think this problem is specific to radeon.
[19:35] <flexiondotorg> The following bug reports maybe relevant.
[19:35] <flexiondotorg> https://bugs.freedesktop.org/show_bug.cgi?id=80553
[19:35] <flexiondotorg> https://bugs.gentoo.org/show_bug.cgi?id=517572
[19:37] <infirit> flexiondotorg, not sure how much you told so let me know what you need me to elaborate on
[19:41] <mwhudson> sigh
[19:41] <mwhudson> i need someone to sit me down and explain to me what the modules/abi checking in the kernel build process is all about
[19:41] <mwhudson> in terms that i won't forget again
[19:46] <flexiondotorg> infirit, Basically can you tell slangasek what virtualised environment can be used to demonstrate the problem and those that work fine.
[19:47] <flexiondotorg> infirit, I explained the on real hardware radeon open source driver do not allow Plymouth the accept the decryption pass phrase where as Intel drivers do.
[19:47] <infirit> virtualbox 4.3.14 does it for me
[19:48] <flexiondotorg> Sadly, I don't have an Nvidia system I can test on.
[19:48] <flexiondotorg> infirit, Virtualbox does what, work or not work?
[19:48] <flexiondotorg> I know, I know the answer but slangasek doesn't 😃
[19:48] <infirit> But also qemu 2.1.1 in virt-manager/libvirt
[19:49] <infirit> flexiondotorg, slangasek none of those work for me once installed.
[19:49] <infirit> I have not tried vmware
[19:50] <infirit> Only when removing the handover it works in these 2
[19:50] <infirit> But hat may just be working around another problem
[20:06] <barry> slangasek: can you retry python-concurrent.futures: https://launchpad.net/ubuntu/+archive/test-rebuild-20140914/+build/6375254
[20:07] <slangasek> barry: retried
[20:08] <barry> thanks
[20:16] <Chipaca> jtaylor: realpath
[20:17] <jtaylor> ?
 20:45:50> which package?
[20:22] <jtaylor> oh thats the one that got absorbed into coreutils right?
[20:22] <jtaylor> might be a bug due to the change
[20:23] <jtaylor> oh its one big package, thats probably why
[20:31] <Chipaca> jtaylor: what does that mean?
[20:32] <Chipaca> oh, in U it's in coreutils?
[20:32] <Chipaca> so it's a bug in the dummy transitional package i guess
[20:32] <jtaylor> though coreutils is M-A: foreign so it should work
[20:32] <jtaylor> maybe, the transitional is not m-a
[20:32] <Chipaca> exactly, and that breaks it
[20:33] <Chipaca> hm, can i depend on coreutils >x.y.z | realpath ?
[20:33] <jtaylor> I think so
[20:37] <Chipaca> worked in U, let's see on T
[20:37] <jtaylor> filing a bug should not harm either
[20:38] <Chipaca> yup
[20:38] <jtaylor> assuming m-a works for transitionals
[20:38]  * Chipaca files
[20:39] <Chipaca> https://bugs.launchpad.net/ubuntu/+source/realpath/+bug/1371303
[20:40] <jtaylor> hm it should be filed against coreutils that contains the transitional
[20:40] <Chipaca> now to see if it'll work in 12.04 too :)
[20:45] <Chipaca> jtaylor: thanks for reassigning it
[21:02] <Noskcaj> Could someone please look at bug 1371309
[21:24] <Noskcaj> cjwatson, You did the most recent change to the seed, is bug bug 1371309 alright?
[21:37] <doko> rbasak, jamespage: why is mysql built sequentially?
[22:32] <smoser> well, cjwatson if you come around. this is d-i install: http://paste.ubuntu.com/8375494/ . and this is curtin install: http://paste.ubuntu.com/8375494/
[22:43] <smoser> bah. d-i : http://paste.ubuntu.com/8374462/
[23:13] <slangasek> doko: so for the record, it's not libtool that's suppressing the output, freetype is invoking libtool with >/dev/null 2>&1 and I can't figure out where in the build system this is happening <grr>
[23:14] <slangasek> doko: also, I am skeptical of this "include issue"; why would freetype have regressed in its ability to find its own headers, and why would it have regressed only on ppc64el?
[23:14] <doko> it is libtool
[23:14] <doko> or the generated Makefile, once building with, and then without -fPIC
[23:16] <slangasek> doko: freetype's build system is crazy and I can find no generated Makefile like you describe - which file are you seeing this in?
[23:25] <doko> slangasek, no, it is libtool itself calling the compiler twice, once without -fPIC, and then with it
[23:26] <slangasek> doko: ah; so it's libtool redirecting gcc's output?
[23:26] <slangasek> do you know how to override that?
[23:30] <infinity> smoser: At a glance, I'm not actually seeing a problem with the difference between those two pastes.  I assume that the curtin one doesn't boot, however?
[23:31] <doko>       # Allow error messages only from the first compilation.
[23:31] <doko>       if test "$suppress_opt" = yes; then
[23:31] <doko>         suppress_output=' >/dev/null 2>&1'
[23:31] <doko>       fi
[23:31] <slangasek> hmm, -no-suppress apparently
[23:31] <slangasek> doko: yeah, just got there, thanks
[23:31] <slangasek> this is of course not documented in libtool --help
[23:31] <doko> slangasek, libtool -no-suppress
[23:32] <slangasek> apparently not
[23:32] <slangasek> needs to go after the --mode argument
[23:35] <slangasek> doko: ok; this is what I get for output now, doesn't say anything about an include problem? http://paste.ubuntu.com/8375838/
[23:36] <doko> hmm
[23:36] <infinity> slangasek: That's an -O3 problem.
[23:36] <doko> does this go away with -O2?
[23:36] <slangasek> probably ;)
[23:37] <infinity> slangasek: Or, rather, a sketchy code being optimised to oblivion with -O3.
[23:37] <slangasek> I just wanted to confirm that this wasn't the include problem you were seeing
[23:37] <slangasek> I'll chase it down from here