[00:03] <slangasek> Noskcaj: test all of its reverse-dependencies for buildability and usability? :)
[00:04] <Noskcaj> i'll take that as a "Someone will do it eventually"
[00:08] <stgraber> hallyn_, slangasek: updated version: http://paste.ubuntu.com/6532431/
[00:08]  * stgraber prepares an email to upstream
[00:11] <hallyn_> stgraber: one more thing though, the %m may be misleading in your error msg
[00:11] <hallyn_> you say 'unable to open /proc/self/loginuid' but the errno is for uid_map open
[00:12] <stgraber> hallyn_: hmm, yeah, I should probably just hardcode "Permission denied" in there instead
[00:15] <sarnold> stgraber: what happens if the uid_map file contains e.g. "         0          0 4" (no newline)
[00:18] <hallyn_> sarnold: well if it's a count of 4 then you're in a non-init userns
[00:19] <hallyn_> the procfile always gives you a newline
[00:19] <stgraber> sarnold: so that value isn't supposed to be possible since the \n is guaranteed by the kernel if the file exists, but if for some weird reason that were to happen, the pam plugin will fail and prevent the session from opening
[00:19] <sarnold> hallyn_,stgraber, thanks :)
[00:37] <slangasek> stgraber: note the inconsistent style of checking fd < 0 in one place, fd != -1 in another; suggest making the second one fd >= 0
[00:37] <slangasek> stgraber: otherwise LGTM
[00:48] <stgraber> slangasek: ok, did that change and sent the e-mail upstream. I tried to subscribe to their list but I apparently need approbation for that, so it may be a few days before my e-mail actually hits the list...
=== kirb_ is now known as Guest59073
[01:04] <xnox> tarpman: .... and we do provide opencl-icd / libopencl1 packages already..... (with most dependencies correct these days, there might be some left)
=== emma_ is now known as emma
[01:36] <tarpman> xnox: no idea about his particular issue... just trying to be helpful. bug 763457 still shows fglrx as affected, maybe it's out of date.
[01:36] <ubottu> bug 763457 in nvidia-graphics-drivers (Ubuntu) "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
[05:05] <hallyn_> infinity: oh goodie, pmaydell thinks the amd64 patchset should be upstream in a month or two (and suggests waiting for that)
[05:10] <infinity> hallyn_: arm64, surely. ;)
[05:17] <Noskcaj> Can someone take a look at lp:~noskcaj/ubuntu/trusty/php5/merge and tell me what i'm doing wrong?
[05:17] <Noskcaj> please
[05:19] <hallyn_> infinity: lol, yes.
[05:19] <hallyn_> technically aarch64, as that's what the binary will be called apparently
[05:20] <infinity> hallyn_: Bah.  Fine. :P
[05:24] <hallyn_> hey - less chance of me mis-typing amd64 :)
=== sunweave1 is now known as sunweaver
[08:44] <cjwatson> slangasek: http://lists.debian.org/debian-dak/2013/12/msg00003.html FYI
[08:49] <slangasek> cjwatson: \o/
=== doko_ is now known as doko
=== bdrung_ is now known as bdrung
=== Ursinha is now known as Ursinha-afk
[14:13] <voldyman> hey guys, where can i get in touch with indicator applet developers ?
[14:16] <ekarlso> what is a good practice for packaging up java stuff ?
[14:19] <brainwash> voldyman: try #ubuntu-desktop
[14:20] <voldyman> thanks brainwash
=== freeflying is now known as freeflying_away
[18:28] <Noskcaj> I'm trying to merge php5, can someone tell me what i've done to cause http://paste.ubuntu.com/6536413/ ?
[19:38] <infinity> Noskcaj: Did you talk to rbasak before trying to merge it?  He's been maintaining and merging it in Ubuntu.
[19:39] <Noskcaj> infinity, xnox has said "please take" on MoM, i'll leave it for rbasak if he wants to
[19:40] <infinity> Noskcaj: I've said it before, but I'll point it out again.  Submitting complex merges for review/sponsorship is a bit of a waste of time, as your sponsor needs to do the work all over again just to verify it was done correctly.
[19:40] <Noskcaj> ok
[19:41] <Noskcaj> I don't think i've ever heard that, makes sense though
[20:18] <slangasek> stgraber: so the other day, you said that cgmanager would mount /sys/fs/cgroup.  Why is that?  We already mount it today via mountall
[20:28] <stgraber> slangasek: cgmanager will potentially start before mountall (our only dependencies are /proc, /sys and /etc), besides we need to care about distros that don't have mountall (android being the one I have to care about with my LXC upstream hat on).
[20:29] <stgraber> it's certainly reasonable to check if it's already writable though, so if something beats us to mounting a tmpfs on it, we'd just use that
[20:29] <Noskcaj> because of bug 76983 can we drop add-apt-key from the archives?
[20:29] <ubottu> bug 76983 in gnupg (Ubuntu) "Doesn't create settings correctly on first start" [Medium,Fix released] https://launchpad.net/bugs/76983
[20:29] <sveinse> I'm working on testing some embedded debootstrapped image (in qemu). What is the minimal packages needed for i386/amd64 to boot?  grub2 + kernel?
[20:30] <slangasek> stgraber: why should cgmanager /need/ to start before virtual-filesystem?
[20:31] <stgraber> slangasek: it doesn't have to start before virtual-filesystem but it could since its requirements are the same as upstart's own requirements (and therefore it doesn't need anything mountall mounts). So given that, why not have it start before mountall, therefore allowing very early boot jobs to use cgroups too?
[20:33] <slangasek> stgraber: because we said that upstart would handle queuing cgroup-using jobs until cgmanager was available... so there's no reason to worry about starting cgmanager any earlier than virtual-filesystem
[20:35] <slangasek> there are no early boot jobs earlier than mountall
[20:35] <stgraber> slangasek: did we actually agree on doing the queueing? I thought we agreed that this would come with a ton of problems and that we agreed to just block all jobs until cgmanager is ready (unless upstart isn't built with cgroup support or is started with --no-cgroup)
[20:35] <slangasek> blocking all cgroup-using jobs
[20:35] <slangasek> but the only job that needs to start is mountall
[20:35] <slangasek> which won't use cgroups
[20:35] <slangasek> so your order is upstart->mountall->virtual-filesystem->cgmanager->everything else
[20:36] <stgraber> anyway, that's nitpick and I don't particularly care. In the end, cgmanager will always attempt to mount /sys/fs/cgroup as a tmpfs if it's not writable as we need that for other distros. Whether Ubuntu uses that specific code path or not isn't very important.
[20:36] <slangasek> and I would much prefer this over adding mount handling to other jobs
[20:36] <slangasek> ok
[20:37] <slangasek> right, it's fine for cgmanager to /have/ mount support, but it's important that the mount handling in Ubuntu not be spread out in difficult-to-diagnose ways
[20:38] <stgraber> the cgroupfs mounts themselves will be done by cgmanager in any case, so there'll always be a bit of difficult-to-diagnose with cgmanager, but yeah, I don't really care who ends up mounting /sys/fs/cgroup itself
[20:44] <Noskcaj> asac, Can you update ModemManager in debian to 1.0.0
[21:48] <hallyn_> slangasek: stgraber good news, I think I've got userns cnonectiosn over dbus working.
[21:48] <hallyn_> (going afk again now - ttyl)
[21:48] <slangasek> whoo :)
[21:58] <slangasek> hallyn_: right, and the reason adding it to your message bus .conf doesn't help is because you're not using the bus :)
=== funkyHat1 is now known as funkyHat
[23:48] <hallyn_> slangasek: right :)