[00:14] <xnox_> YokoZar: all reviews end up on the sponsorship queue report http://reqorts.qa.ubuntu.com/reports/sponsoring/
[00:14] <xnox_> YokoZar: which ubuntu core devs and motu patch pilot, review and upload.
[00:15] <xnox_> YokoZar: the implications of setting that in launchpad, is to avoid spamming people with messages comming from "contact this user"
[00:15] <xnox_> (bug subscriptions, merge review requests etc. as there is no good way to "opt-out" of team received mail, unless it's redirected to a mailing-list / email address)
[00:36] <YokoZar> xnox: ahh, sensible.
[04:33] <Noskcaj> doko_, https://code.launchpad.net/~noskcaj/ubuntu/trusty/torque/merge . And if you have any merges you want me to do, just say
[04:36] <manchicken_> Did anybody on the Synaptic side ever work around the deprecation of InstallProtect in apt-pkg?
[04:37] <manchicken_> I'm trying to figure out how to get around that for libqapt, but I am finding exactly zero documents explaining the deprecation and what one could do differently now that this method is deprecated.
[04:49] <Noskcaj> Can someone please review https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-session/light-locker/+merge/196436 ? It's kinda important for xubuntu
[07:16] <sarnold> pitti: good morning :) I just ran my laptop down to two minutes battery life, then suspended, then plugged into power; when I returned, my laptop was awake and running. Is this expected?
[07:22] <pitti> sarnold: no, certainly not
[07:22] <pitti> good morning
[07:23] <pitti> sarnold: you mean plugging in AC woke up the laptop?
[07:23] <pitti> sarnold: might that be a BIOS/EFI setting?
[07:23] <sarnold> pitti: I believe that's what happened.
[07:23] <sarnold> pitti: could be.
[07:23] <sarnold> I've never pushed my luck down to two minutes before. :)
[07:45] <BrotherBrick> morning
[08:00] <dholbach> good morning
[08:30] <infinity> pitti: Does ddebs need to learn about new arches, or does it just DTRT (I ask this every time, don't I?)
[08:30] <pitti> infinity: they do need to learn about new arches
[08:31] <infinity> pitti: Alright.  ppc64el me, then.
[08:31] <pitti> infinity: trusty only, I take it?
[08:32] <infinity> pitti: No current plans for time travel, no.
[08:32] <pitti> infinity: http://bazaar.launchpad.net/~pitti/+junk/ddeb-retriever/revision/108
[08:32] <infinity> pitti: A scrape should get you eglibc and binutils ddebs, so far.
[08:32] <pitti> infinity: I'll re-fetch ddebs from the last 7 days
[08:33] <pitti> $ for d in 2013121{1,2,3,4,5,6,7}; do ~/ddeb-retriever/ddeb-retriever $d; done
[08:33] <pitti> (just in case you need to do it yourself at some time)
[08:36] <pitti> that's not yet it, I take it: libc6-ppc64-dbgsym_2.17-93ubuntu4_powerpc.ddeb
[08:36] <pitti> (just a foreign arch build)
[08:36] <infinity> pitti: Yeah, that's not it. :)
[08:37] <infinity> pitti: Of course, if it scrapes in DB index order, it'll hit the ppc64el buildd dead last, since it was the last one added...
[08:37] <pitti> scrapes by day, currently at Nov 15
[08:38] <infinity> Dec, I hope.
[08:38] <pitti> and eglibc was built on 16
[08:38] <pitti> err, yes
[08:38] <infinity> It's in the 20131217 directory, actually.
[08:38] <infinity> Must have finished right after 1200 UTC.
[08:39] <pitti> oh, and binutils right now
[08:40]  * infinity waits like an excited puppy to see them publish to http://ddebs.
[08:41] <pitti> meh, seems some apache on some buildd is hanging again
[08:41] <infinity> Can you tell which one?
[08:41]  * pitti enables debugging
[08:43] <pitti> infinity: ddebs are in pool/ now (postal01 retrieval works)
[08:43] <pitti> infinity: indexes will refresh automatically in a few hours (or I can start that now if you are eager)
[08:43] <infinity> pitti: Yay!
[08:43] <infinity> pitti: Nope, don't need the indexes, just want to make sure it's all working right.
[08:45] <pitti> as for "hanging", any buildd which isn't on http://paste.ubuntu.com/6587836/
[08:45]  * pitti sorts and diffs
[08:46] <infinity> Hrm, beebe and birch look suspiciously absent.
[08:46] <pitti> beebe just finished
[08:47] <pitti> birch still hanging
[08:47] <pitti> that's all
[08:47] <infinity> Let me see if birch is dead.
[08:47] <infinity> It's not the most reliable hardware.
[08:47] <infinity> I have to stab it in the face every day or two.
[08:48] <infinity> Oh, yeah, it's 6 hours into an apt-get.  It's dead. :P
[09:04] <jamespage> mwhudson, I expect it not to be particularly security friendly but we could use spidermonkey as the scripting engine for archs that don't have v8 support yet
[09:04] <jamespage> (context mongodb packages)
[09:05] <jamespage> mwhudson, I suspect that's how upstream are supporting solaris deployments
[09:07] <mwhudson> jamespage: err
[09:07] <mwhudson> oh
[09:07] <jamespage> mwhudson, upstream still ship that with the mongodb source package and it has broader arch support I think
[09:08] <mwhudson> they do?
[09:08] <jamespage> mwhudson, yup - js-1.7 under thirdparty
[09:08] <jamespage> enabled using --usesm
[09:08] <mwhudson> jamespage: hm, not there in git
[09:09] <jamespage> mwhudson, ah - I think maybe its been dropped for the next stable release series - 2.6.x
[09:09] <jamespage> its still in the 2.4 source tree
[09:09] <jamespage> mwhudson, https://github.com/mongodb/mongo/tree/v2.4/src/third_party
[09:10] <mwhudson> ah interesting
[09:10] <mwhudson> oh ok
[09:10] <mwhudson> so spidermonkey doesn't build on arm64 either :)
[09:10] <mwhudson> but it's probably much easier
[09:10] <infinity> Doesn't it?
[09:11] <mwhudson> infinity: https://launchpadlibrarian.net/155832603/buildlog_ubuntu-trusty-arm64.mozjs17_17.0.0-1_FAILEDTOBUILD.txt.gz
[09:11] <infinity>  libmozjs185-1.0 | 1.8.5-1.0.0+dfsg-4ubuntu1 | trusty/universe  | amd64, arm64, armhf, i386, powerpc
[09:11] <jamespage> mwhudson, this might be a suitable stop-gap
[09:11] <mwhudson> infinity: ah
[09:11] <infinity> Not actually sure if 185 or 17 is newer.  Very confusing versioning.
[09:11] <infinity> But 185 builds. :P
[09:12] <mwhudson> ok
[09:12] <jamespage> mwhudson, ignore me on the solaris support - looks like v8 does support solaris
[09:12] <mwhudson> i now realise that i was confused earlier because i didn't have universe enabled properly in my chroot
[09:35] <menace>  Hi, i have several files in /usr which belong to root:root. And they are user- and group-writeable. Now i think i can remember about exploits, which only give you group-root-privileges. Wouldn't it be more secure, that files which belong to root:root only be writeable for user root? or does that hinder any functionality?
[09:51] <tseliot> pitti: is nvidia-prime 0.5 still in trusty-proposed (for some reason)?
[09:52] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[09:52] <pitti> tseliot: ^ yes
[09:52] <pitti> tseliot: because it doesn't build for the ports any more
[09:52] <tseliot> pitti: I made it arch specific
[09:52] <pitti> tseliot: seems it previously was arch:all?
[09:53] <tseliot> pitti: yep
[09:53] <pitti> ok, let me remove the binaries for the other arches
[09:53] <tseliot> thanks
[09:54] <pitti> tseliot: done, should migrate in about an hour
[09:54] <tseliot> pitti: thanks a lot :)
[10:36] <doko> Noskcaj, feel free to grab everything from universe =)
[10:42] <xnox> stgraber: so it seems I'm not using "ssh-agent" but rather the gnome-keyring provided ssh-agent, and there is no upstart jobs to start that up properly / re-export environment variables for the correct SSH_AUTH_SOCK
[10:43] <xnox> is ssh-agent really the default one? or it happens that gnome-keyring takes over the default where available?
[10:54] <xnox> LoganCloud: only upload boost-mpi-source if there is a matching version boost upload. the two packages are the same source but are split across main and universe, thus if they are version mismatched they get stuck in -proposed.
[10:55] <xnox> LoganCloud: and usually it's best to ask last uploader / usual uploaders of non-trivial packages.
[11:21] <dholbach> @pilot in
[11:22] <xnox> infinity: with proposed (eglibc2.18) there is a cross-build (amd64->armhf) failure that is not seen with just release pocket http://paste.ubuntu.com/6588304/ is it uhub bug or pthreads/armhf cross-compilation bug?
[11:24] <infinity> xnox: Could be a uhub bug, could also be that our cross toolchain needs updating to use glibc2.18 for its private libs.
[11:25] <infinity> xnox: Note that the complaining library is /lib/arm-linux-gnueabihf/libpthread.so.0, the cross-base one, not the multiarch one.
[11:25] <happyaron> wonders if our grub menu can show localized texts?
[11:25] <infinity> xnox: I could see having a cross-base at 2.17 and libc6:armhf at 2.18 could be an issue.
[11:27] <xnox> infinity: ack =/ for now I just told to not use -proposed when cross-compiling. Too much arch skew visible anyway.
[11:40] <mlankhorst> hey, can some archive admin move libdrm from NEW into -proposed ?
[11:40] <mlankhorst> https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=
[11:47] <mlankhorst> I'm guessing it's the same bug as before, libdrm-nouveau2 wasn't in precise, so it libdrm was accepted into NEW. it exists in precise-updates though...
[12:06] <jamespage> mwhudson, built OK with spidermonkey but failed a couple of tests (JS ones...)
[12:06] <jamespage> I'll poke at that later
[12:21] <infinity> mlankhorst: Sorted.
[12:21] <mlankhorst> thanks
[12:46] <dholbach> can somebody please reject https://code.launchpad.net/~logan/ubuntu/trusty/mutagen/1.22-1ubuntu1/+merge/198129? It was already merged by somebody else
[12:47] <dholbach> ah no, I can do it myself
[12:47] <dholbach> nevermind
[13:36] <pitti> stgraber: FYI, I moved your WIs on https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming to alpha-2
[13:36] <pitti> (too late now for alpha-1)
[14:28] <dholbach> @pilot out
[14:28] <dholbach> (will do some more piloting tomorrow)
[14:36] <maxiaojun> there is no way to uninstall a manually installed deb using USC?
[14:48] <maxiaojun> ?
[14:51] <dobey> tjaalton: hi. i'm trying to figure out how to work around the fact that glx isn't working under xvfb, and i came across https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1100312 which you marked as fix released for raring. however "xvfb-run -a glxinfo" (or running anything that requires glx) prints some errors from libGL about not being able to load the swrast driver
[14:53] <dobey> tjaalton: any idea how to get around that and use xvfb to run things that require glx on headless?
[14:55] <dobey> swrast_dri.so is in the place it looks to load it, and LIBGL_DEBUG=verbose doesn't add any extra useful data to the output :(
[15:50] <Sarvatt> dobey: xvfb-run -s "-screen 0 640x480x24" glxinfo
[15:53] <dobey> Sarvatt: wtf? why does that work?
[15:53] <Sarvatt> xvfb defaults to 8bpp, no glx support at 8bpp
[16:05] <jdstrand> cjwatson: hey, can you think otoh how to determine at runtime what the gnu triplet is without using dpkg-architecture? I've not looked terribly hard but only thought of readlink -e'ing /lib/ld-linux*so* then getting it from the path. obviously, I kinda don't like that
[16:06] <jdstrand> cjwatson: if not otoh, I'll keep looking
[16:06] <cjwatson> jdstrand: best way I know of is to compute it at build time and build it into the binary
[16:06] <jdstrand> cjwatson: yeah, this is for click-apparmor, which is arch all, so that doesn't work
[16:07] <cjwatson> I'm not aware of a run-time-only method, so you'll need an arch any component
[16:07] <jdstrand> (it is for aa-exec-click to set QML_IMPORT_PATH and LD_LIBRARY_PATH for fat
[16:07] <cjwatson> it's small, you could just make the whole thing arch any and substitute
[16:08] <jdstrand> I guess that's true
[16:08] <jdstrand> that feels kind icky though
[16:08] <jdstrand> cjwatson: ok, thanks
[16:08] <cjwatson> np
[16:34] <pitti> barry, doko: does this ring a bell? ImportError: No module named 'answer_0i04jl'
[16:35] <doko> no
[16:35] <barry> pitti: whuhhh?
[16:35] <pitti> barry, doko: I get random faults like those in PPA builds
[16:35] <pitti> https://launchpadlibrarian.net/160026669/buildlog_ubuntu-trusty-i386.python-dbusmock_0.6~171~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
[16:35] <pitti> https://launchpadlibrarian.net/160026641/buildlog_ubuntu-saucy-i386.python-dbusmock_0.6%2B171~ubuntu13.10.1_FAILEDTOBUILD.txt.gz
[16:35] <pitti> I retried a few times, and each time it seems to fail differntly
[16:35] <barry> pitti: i have *never* seen that before
[16:35] <barry> objmgr_40664_
[16:36] <pitti> barry, doko: ok, thanks; just wanted to check if it's known already
[16:36] <barry> pitti: could those be some kind of dbus generated fake modules?
[16:36] <pitti> barry: yeah, those suffixes seem to be some random number
[16:36] <barry> pitti: well, on the bright side, that'll be fun to track down :)
[16:37] <pitti> I newer saw it locally either
[16:37] <pitti> or on the distro builders, just now on the PPA builders; so plausibly related to running in qemu
[17:33] <ogra_> pitti, hey, i'm trying to get client mdns support to work on my phone, is it not possible to install the libnss-mdns package alone ? (i only want the client resolution, not to run the avahi daemon, but it seems there is a hard dependency)
[17:34] <ogra_> (pinging you because i remember you did a lot avahi stuff in the past)
[17:46] <pitti> ogra_: "a lot" is a bit of an exaggeration, but you do need the avahi daemon, yes; the PAM module doesn't talk to the network
[17:46] <ogra_> ah, k
[17:46] <ogra_>   avahi-daemon bind9-host libavahi-core7 libbind9-90 libdaemon0 libdns99
[17:46] <ogra_>   libgeoip1 libisc95 libisccc90 libisccfg90 liblwres90 libnss-mdns
[17:46] <ogra_> its is a lot (on the phone) :)
[17:47] <pitti> ogra_: the protocol works so that computers regularly broadcast their info, and the daemon picks it up; the daemon doesn't actively "ask" AFAIK
[17:47] <pitti> ogra_: so the latency would be way too high
[17:47] <ogra_> oh, ok
[17:47] <pitti> ogra_: err, not PAM of course, the DNS module
[17:47] <ogra_> yeah
[17:47] <ogra_> nss
[17:48] <ogra_> pitti, lennarts documentation makes it sound like it would work alone http://0pointer.de/lennart/projects/nss-mdns/
[17:48] <cjwatson> that's only about 1.5MB of .deb size though
[17:48] <ogra_> thats what confused me
[17:48] <cjwatson> not that much despite the package count
[17:48] <pitti> ogra_: well, I could be wrong
[17:49] <pitti> ogra_: that is written in bold: "Thus, nss-mdns will not work unless Avahi is running! That makes Avahi essentially a hard dependency of nss-mdns. "
[17:49] <ogra_> pfft ... thats buried in a whoole bold paragraph, how am i supposed to notice
[17:49] <ogra_> :P
[17:49] <ogra_> pitti, thanks !
[17:49] <ogra_> :)
[17:51] <ogra_> cjwatson, 1.5MB on the phone will cost me a lot of whisky to bribe pmcgowan_ :)
[17:51] <cjwatson> you could call it a qt update and nobody would notice :P
[17:51] <ogra_> lol
[17:52] <cjwatson> I'd be more worried whether avahi-daemon chews battery
[17:52] <ogra_> yeah
[17:52] <pmcgowan_> what more packages!
[17:52] <cjwatson> or memory
[17:52] <ogra_> thats why i tried to install the client bit alone
[18:04] <kees> doko: does arm64's gcc say "warning: -fstack-protector not supported for this target" ? (i.e. can I autodetect this condition?)
[18:05] <doko> kees, not anymore ;-P but the glibc bits are not yet there
[18:06] <kees> doko: is there a bug # for it to track?
[18:07] <doko> I think there is one for linaro. sorry have to run now. back in a few hours
[18:17] <xnox> cjwatson: ogra_: as far as I remmeber avahi doesn't work out of the box on the nexus kernel, and needs a config option change to get enabled properly (missing capabilities)
[18:17] <xnox> cjwatson: ogra_: should i file that as a bug against kernel?
[18:17] <xnox> or are we gona tweak conffiles on the phone?
[18:21] <cjwatson> don't know, I was just driving-by
[18:22] <kees> doko: anyway, I've pulled the ubuntu delta, so you can just sync hardening-wrapper 2.5 once it's built in debian
[18:23] <shadeslayer> Does software-properties-gtk only check if a package is installed to see if it's in use? Because AFAIK you can install nvidia proprietary drivers and nouveau side by side
[18:24] <shadeslayer> ( the driver manager part )
[19:10] <tjaalton> dobey: I see Sarvatt replied already, good :)
[19:10] <dobey> yeah
[19:10] <dobey> not sure why 24bpp isn't default though. it's not 1995 any more :)
[19:12] <tjaalton> noone cares enough
[19:15] <dobey> push a patch upstream and it should land easy then :)
[19:15] <tjaalton> what makes you think _I_ care ;)
[19:15]  * tjaalton runs
[19:16] <tjaalton> dobey: what's the usecase?
[19:17] <dobey> tjaalton: qmltestrunner
[19:18] <dobey> tjaalton: ie, running tests that depend on glx, under an isolated display with xvfb
[19:19] <tjaalton> right
[19:19] <tjaalton> maybe file a new bug and we'll see
[19:19] <tjaalton> doesn't sound hard to fix
[19:22] <tjaalton> hum, xvfb-run is a wrapper from debian
[19:22] <tjaalton> XVFBARGS="-screen 0 640x480x8"
[19:22] <tjaalton> so, maybe just change that
[20:57] <Logan_> doko: What is the status on arm64 config.{guess,sub} updates? Should we be creating deltas in Ubuntu to do them locally with autotools-dev, or should we just be reporting to Debian?
[21:12] <Logan_> ScottK: Would you mind taking a look at Bug 1261084?
[22:11] <brainwash> bug 1261863
[22:11] <brainwash> can we sync the latest version of xscreensaver from debian?
[22:23] <Noskcaj> brainwash, not even slightly
[22:24] <Noskcaj> To sync, debian has to have all the changes at https://launchpad.net/ubuntu/+source/xscreensaver/5.15-3ubuntu1
[22:24] <Noskcaj> So what you do here, is ping infinity
[22:25] <brainwash> well, upgrade the version it is
[22:25] <Noskcaj> The word you are looking for is "merge"
[22:26] <Noskcaj> run "bzr branch lp:ubuntu/xscreensaver && cd xscreensaver && bzr merge lp:debian/xscreensaver" the resolve all conflicts and check all the changes are applied
[22:27] <brainwash> nice to know, I'll try that
[23:08] <GunnarHj> slangasek: ping?
[23:10] <slangasek> GunnarHj: hi
[23:10] <GunnarHj> slangasek: Hello, Steve!
[23:10] <GunnarHj> slangasek: Do you have any comments on https://lists.ubuntu.com/archives/ubuntu-devel/2013-December/037899.html ? Partly asking because of your PAM proficiency.
[23:14] <slangasek> GunnarHj: I haven't had a chance to think about it in any detail; there are tradeoffs regardless, profile only applies to shells and /etc/environment /etc/default/locale ~/.pam_environment only apply to PAM sessions.
[23:17] <GunnarHj> slangasek: Ok. Maybe it would better to not state a 'recommended' way, but rather try to explain the differences.