[02:33] <Logan_> hey infinity, are you around to fix a couple more ppc64el packages manually? :P
[02:33] <Logan_> specifically, https://launchpad.net/ubuntu/+source/gst-plugins-ugly0.10/0.10.19-2ubuntu1 and https://launchpad.net/ubuntu/+source/gst-plugins-ugly1.0/1.2.2-1ubuntu1 are both failing, even with an autoreconf
[02:38] <xnox> Logan_: well, despite running dh_autoreconf it didn't run libtoolize.
[02:38] <Logan_> and why
[02:38] <xnox> Logan_: (no lines with libtoolize: jibberish)
[02:38] <xnox> Logan_: and checking whether the gcc linker (/usr/bin/ld -m elf64ppc) supports shared libraries... no
[02:38] <Logan_> but why didn't it run libtoolize?
[02:39] <xnox> Logan_: because autoreconf decided not to run libtool, as it doesn't blindly do it, but rather tries to detect if a particular tool is used and only then updates stuff....
[02:39] <xnox> Logan_: i wish I knew why autoreconf is so careful =)
[02:39] <Logan_> is there any way to force a libtoolize using dh_autoreconf without using a script?
[02:41] <xnox> Logan_: first of all the ltmain.sh patch should be dropped, and instead --as-needed autoreconf option should be used... lets see what else.
[02:45] <xnox> Logan_: test-building a fix here.
[02:45] <Logan_> great, thanks!
[02:45] <Logan_> feel free to upload if you find a fix
[02:48] <xnox> Logan_: something like that - http://paste.ubuntu.com/6688530/
[02:49] <xnox> Logan_: uploaded that. let's see if it builds.
[03:08] <xnox> Logan_: that worked.
[03:34] <cjwatson> sbeattie: It's almost certainly a bug if a package tries to use /usr/bin/libtool (libtool-bin's only useful content) at build time.  Only a handful of packages with broken build systems do that.  You're meant to have your configure script generate a libtool script in your build tree at build time.
[03:36] <cjwatson> sbeattie: cf. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682045
[03:37] <cjwatson> (we seem to have a different solution than advocated at the end there, but it still has the basic rationale for why no build ought to need /usr/bin/libtool)
[05:47] <Logan_> xnox: beautiful, thank you
[05:52] <sbeattie> cjwatson: yeah, I realized that. It's a bug in an ancient copy-n-wasted script. I'm fixing it upstream.
[10:35] <vrga> 'lo folks, i'm using a ubuntu core 13.10 rootfs for fiddling with my arm tablet.
[10:36] <vrga> due to some obvious issues, i need to install some packages from a chroot before i can run the thing natively.
[10:36] <vrga> i got the chroot to run through qemu-user and stuff, but apparently it has no network connectivity to the outside world.
[10:36] <vrga> or at least, thats what running apt-get update indicates.
[10:37] <vrga> so, erm, i'm kinda stuck for the moment.
[10:41] <Fudge> hi, cpufreqd bug #11621q60 has a simple work around but wondering if it can be fixed in the package for trusty before a freeze takes place? the same version from raring is in trusty 2.4.2-2
[10:42] <vrga> kill me. just needed resolv.conf
[10:42] <Fudge> #1162160 should I say
[10:44] <maxiaojun> Fudge: an 'outsider' here, I guess you should try contacting the debian maintainer as cpufreqd is a universe package?
[10:44] <maxiaojun> http://packages.qa.debian.org/c/cpufreqd.html
[10:45] <Fudge> oh right, thanks maxiaojun  had not considered that :D
[10:48] <infinity> Fudge: Also, the "workaround" is silly, when there's an actual upstream patch to fix the real bug.
[10:48] <Fudge> still in git ?
[10:50] <infinity> Fudge: Yeah, I'll just pull the git patch and test it now.
[10:50] <Fudge> :)
[10:51] <maxiaojun> where is the upstream git?
[10:53] <infinity> Looks to be mirrored a few places, but I yanked the patch from http://git.taihen.jp/cgi-bin/gitweb.cgi?p=cpufreqd.git;a=patch;h=b5b23525edcc09898288360c48e92b4a6c9cb0ee
[10:53] <infinity> Anyhow, building now, will test the binary and upload in a second.
[10:54] <Fudge> you can find stuff faster than me :D
[10:54] <tkamppeter> OdyX, thank you very much, I will look into this soon.
[10:54] <infinity> Fudge: It was referenced in the bug report. :P
[10:54] <Fudge> thats what I thought, but my FF is being a bit strange at the moment, only just switched to Trusty and its a bit flakey with Orca for some reason
[10:55] <infinity> Uploaded to trusty.
[10:56] <Fudge> nice
[11:02] <infinity> Fudge: And forwarded to Debian for completeness (since it's probably irresponsible to fix a buffer overflow locally without pushing it to them).
[11:03] <Fudge> infinity:  thanks so much for jumping on that so fast mate
[11:03] <infinity> NP.
[11:04] <Fudge> now how can I get my 4 workspaces to go loL
[11:11] <maxiaojun> Fudge: you mean the workspace icon in launcher?
[11:12] <Fudge> maxiaojun:  it is not there
[11:12] <maxiaojun> you want it to be there?
[11:14] <Fudge> maxiaojun:  I read that in system preferences, appearance, behaviour you can set the 2x2 grid for workspaces which is what I want, I use keyboard shortcuts to move around workspaces. but the behaviour screen is not completely intuative to me with Orca. I see some settings have been changed by an external program, hit the button and have something saying left, top left, etc and a slider with 0.2 through to 8.0. But do not understand 
[11:15] <maxiaojun> ok, i do not know a bit about Orca :(
[11:16] <Fudge> it is just some of the information on the screen that is not being read, is that where the collum/rows are configured?
[11:16] <infinity> Fudge: In unity, a 2x2 grid would be the default anyway.
[11:17] <Fudge> mm, maybe the shortcut is not set then, let me look there instead
[11:17] <tkamppeter> OdyX, I have synced CUPS now.
[11:18] <infinity> Fudge: The slider orca's reading to you is a slider for launcher reveal sensitivity.  There's nothing to select grid size (it defaults to 2x2, and can only be changed by deeper settings abuse, like ccsm)
[11:18] <infinity> Fudge: In that system settings panel you're on, there's a tickbox for "Enable workspaces".  If that's off, you'd be gridless.
[11:19] <OdyX> tkamppeter: cool.
[11:19] <Fudge> infinity:  thank yo uso much, that is a very clear explanation, I'll see if those items can present themselves a bit better maybe with TheMuso
[11:19] <infinity> Fudge: Also, if Orca's failing to read the label on that "Reveal sensitivity" thing, please file a bug against Unity for labelling it in a non-friendly manner. :/
[11:20] <infinity> (Or bug TheMuso, sure) :)
[11:22]  * infinity misses the days of text-only UNIX and braille terminals, it was so much harder to fuck that up.
[11:23] <Fudge> :D I hear ya bud, I use console a lot, speech is so fast and responsive for me
[11:25] <maxiaojun> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1164252
[11:26] <maxiaojun> filed just before 13.04 release, forgot during 13.10 cycle, hope that i won't forget it again
[11:29] <Fudge> oops
[11:43] <Fudge> strange, totems desktop file has name Videos, I just changed  mine back to Movie Player how I like it.
[12:02] <tester56> is it possible with ubuntuone to sync only changes of a truecrypt container, so that the container does not have to be uploaded every time?
[12:20] <maxiaojun> Fudge: https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1108977
[12:20] <sladen> tester56: u1sync would need to understand the internal structure first
[12:20] <sladen> tester56: file a feature request
[12:23] <maxiaojun> Fudge: https://git.gnome.org/browse/totem/commit/data/totem.desktop.in.in.in?id=9dc401b1213aa9fec2f5274d0e6cb8dcefba486f
[12:25] <tester56> sladen: that measn: currently not supported?
[12:26] <sladen> tester56: correct (to the best of my knowledge), but I would suggest Googling
[12:27] <sladen> tester56: to see whether there are any other similiar requests/work being done
[12:27] <tester56> sladen: googling does not lead to any valueable information in this case (at least I was not able to get valueable information, that is actual)
[12:27] <sladen> tester56: make sure that the request regarding truecrypt container is recorded in Launchpad somewhere
[12:28] <sladen> tester56: and then the next person will hopefully find it, and dicussion can be focused in one place
[12:40] <tester56> sladen: done: https://bugs.launchpad.net/ubuntuone-filesync/+bug/1266021
[13:07] <mitya57> doko: I think jtaylor was looking at nee numpy, maybe he was looking at scipy as well
[13:08] <mitya57> doko__: having a scipy built for 3.4 will indeed fix some other packages
[13:09] <mitya57> My pandas upload anyway FTBFS on powerpc because statsmodels didn't build there, I've pinged yoh about that
[13:09] <jtaylor> I'm almost done with numpy
[13:09] <jtaylor> then scipy can be synced
[13:09] <mitya57> Great!
[13:09] <mitya57> ... The pandas can be put in sync as well
[13:10] <jtaylor> pandas will get a new update soon
[13:10] <jtaylor> required for new scipy
[13:13] <mitya57> I thought pandas depends on scipy, not vice versa
[13:47] <jtaylor> yes but scipy breaks it
[13:47] <jtaylor> 0.13
[14:04] <infinity> jtaylor: Hrm?  What needed doing with numpy?  Didn't I already upload that for 3.4 support?
[14:04] <jtaylor> new upstream
[14:05] <infinity> Ahh, fair enough.
[14:11] <OdyX> tkamppeter: Any opposition to switch cups to openssl (instead of GnuTLS) ? (See #714492)
[14:14] <OdyX> tkamppeter: also; has the colord-per-queue patch been submitted to cups.org ?
[14:56] <sladen> tester56: excellent!
[15:18] <maxiaojun> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1164252
[15:18] <maxiaojun> anyone?
[15:24] <OdyX> tkamppeter: uploaded 1.7.0-2 fwiw
[15:36] <tkamppeter> OdyX, have you seen that the bug tracker on cups.org is back? So you can report all bug fixes which are now domne by distro patches upstream.
[15:38] <OdyX> tkamppeter: yeah, saw it; I begun to report some.
[15:39] <OdyX> tkamppeter: but each one his owns; the colord is more yours than mine: :-)
[18:19] <jtaylor> hm the python3.4-dbg debug symbols do not match the source
[18:20] <jtaylor> how can that be?
[18:22] <doko> ?
[18:22] <jtaylor> the line numbers are off
[18:25] <doko> strange
[18:36] <TJ-> which package contains the UEFI "/EFI/BOOT/BOOTx64.EFI" firmware image installed to the ISOs, or generates it?
[18:51] <doko> jtaylor, were you working on a new cffi upload?
[18:53] <jtaylor> no zmq
[19:04] <stgraber> TJ-: on current (secureboot enabled) images, that'd be shim-signed
[19:08] <TJ-> stgraber: So, is "BOOTx64.EFI" a generate or renamed file from the shim* packages? I'm having 'issues' and trying to figure out where the files originate
[19:15] <TJ-> I've looked for mentions of "bootx64" in live-build, livecd-rootfs, shim and shim-signed so far. There's one mention in shim/shim.c where it tries to get the image from the UEFI itself. Not clear yet how it gets onto the liveCD image though
[19:20] <stgraber> TJ-: it's a copy of the signed shim.efi
[19:22] <TJ-> stgraber: OK, so some script is renaming it to that expect by the EFI simple file-system protocol?
[19:23] <TJ-> s/expect/expected/
[19:45] <xnox> TJ-: correct, the path for removable devices UEFI firmware.
.EFI
[20:00] <TJ-> xnox: Yeah, I've been working with the OVMF and qemu to test out ways of recovering a physical system that has become confused
[20:01] <xnox> TJ-: well there is a packaged version of OVMF and extensive guides on working with it https://wiki.ubuntu.com/SecurityTeam/SecureBoot
[20:02] <xnox> TJ-: i found that OVMF can be easily confused and it doesn't have persistent storage beyond the lifecycle of the VM.
[20:02] <xnox> (e.g. for secureboot keys, etc)
[20:02] <TJ-> xnox: OVMF is fine, I'm using it to work out a way to fix a physical install
[20:03] <TJ-> xnox: Was trying to get my head around how the UEFI works differently with removable media (simple file system) as opposed to fixed media which require entries in the UEFI nvram's boot list
[22:26] <Logan_> What is the easiest way to submit the entire Ubuntu delta to Debian? submittodebian just seems to do the latest Ubuntu revision based on the revision before it, even if that was also an Ubuntu revision.
[22:33] <jtaylor> just run debdiff and email it is not very hard
[22:34] <PublicStaticVoid> SO may I ask politely.. Why was the decision made to go for Mir and not Wayland?
[22:34] <PublicStaticVoid> When all future WM's and DE's are going to be depending on Wayland..
[22:34] <PublicStaticVoid> 95% of Distros are moving to Wayland..
[22:41] <PublicStaticVoid> k..
[23:05] <Logan_> jtaylor: But submittodebian makes it so easy. :P Alright.
[23:13] <Fudge> hey infinity, the workspace switcher check box is unavailable and gets not tab focus with orca. GF could not click it.
[23:32] <Fudge> infinity:  thank you for fixing cpufreqd