[04:28] <pitti> Good morning
[04:29] <pitti> stgraber: what I didn't understand yet: why do we conceptually need a daemon for the cgroup management anyway? why can't this just be a library which does proper locking to avoid cgroup fs write conflicts?
[04:30] <stgraber> pitti: because it's unsafe to allow a container to mount cgroupfs, so we want to let a container alter only a sub-section of the hierarchy
[04:30] <pitti> stgraber: ah, so the daemon's API would always be "relative" to the calling cgroup?
[04:31] <stgraber> a container wouldn't be able to access cgroupfs directly but would have access to the daemon's socket which will let it write only in its sub-section of the hierarchy
[04:31] <stgraber> pitti: correct
[04:31] <pitti> stgraber: thanks
[04:32] <stgraber> so we can do any level of nesting and user switch (with userns) without ever having to grant access to cgroupfs and therefore preventing any of the containers from escaping their limits
[05:39] <Noskcaj> Can someone look into removing rhythmbox-radio-browser? It is pretty much non-functions due to rhythmbox api changes
[09:43] <asac> 10:40 < jibel> asac, confirmed: apt-get install libc6-amd64 && apt-get remove libc6-amd64
[09:43] <asac> 10:40 < jibel> and get a broken system for free
[09:43] <asac> 10:42 < asac> jibel: thats on i386?
[09:43] <asac> 10:43 < jibel> asac, amd64 with i386 enabled
[09:43] <asac> hmm... doko not around :)
[09:44] <Laney> probably infinity
[09:44] <jibel> asac, doko has issues with his provider this morning
[09:46] <asac> infinity: ^ (in case you are in a eur zone)
[09:47] <didrocks> asac: infinity is sick today
[09:48] <Laney> I guess file a bug and assign him
[09:51] <infinity> asac: There's already a bug for that.  I was just trying to think up a clever fix right now, while I can't sleep.
[09:52] <infinity> (Not a new bug, it's been like this since precise, but it's very rare for people to install libc6:amd64 and libc6-amd64 on the same machine)
[09:52] <didrocks> Laney: yeah, I guess you will volonteer in hosting vUDS session btw as I can't start anything on my machine now :p
[09:52]  * ogra_ would blame the package that installs it ... 
[09:52] <seb128> infinity, it was, until the emulator started pulling it in
[09:52] <asac> infinity: right. i think for now didrocks just needs a good idea how to recover (e.g. what exactly is now wrong)
[09:52] <seb128> ogra_, that's the android emulator :p
[09:52] <ogra_> the emulator deps should just be fixed
[09:53] <didrocks> asac: agreed ;)
[09:53] <asac> infinity: maybe just unpack libc6:amd64 ?
[09:53] <Laney> didrocks: have you /seen/ me try to use hangouts?
[09:53] <ogra_> it cant even use any amd64 stuff ...
[09:53] <seb128> didrocks: oh, so you did that to sneak off vUDS hosting!
[09:53] <Laney> :P
[09:53] <infinity> asac: What's wrong is that /lib64/ld-linux-x86-64.so.2 is gone.
[09:53] <seb128> lol
[09:53] <didrocks> seb128: clearly ;)
[09:53] <seb128> Laney, man, you and hangouts don't get along for some reason ;-)
[09:53] <infinity> asac: So no amd64 binaries will run.
[09:53] <asac> yeah
[09:54] <infinity> asac: Recreating the symlink from a rescue CD would do the trick.
[09:54] <infinity> didrocks: ^
[09:54] <didrocks> yeah, no /lib64/ld-2.17.so binary
[09:54] <ogra_> infinity, whats wrong is that a package that can only make use of libc6-i386 pulls in libc6-amd64
[09:54] <didrocks> infinity: the symlink is there, just not /lib64/ld-2.17.so
[09:54] <infinity> didrocks: /lib/x86_64-linux-gnu/ld-2.17.so
[09:54] <infinity> didrocks: The symlink should point to that.
[09:54] <asac> i assume thats in libc6:amd64? so ifyou have that and can unpack it should be ther?
[09:54] <didrocks> ah ok, so lrwxrwxrwx    1 root     root            10 Nov 20 09:41 /lib64/ld-linux-x86-64.so.2 -> ld-2.17.so
[09:55] <didrocks> which points to /lib/x86_64-linux-gnu/ld-2.17.so
[09:55] <didrocks> right?
[09:55] <infinity> didrocks: No, just directly aim the symlink at /lib/x86_64-linux-gnu/ld-2.17.so
[09:55] <didrocks> ok, trying that in my busybox
[09:55] <infinity> didrocks: /lib64/ld-2.17.so is only in libc6-amd64
[09:55] <didrocks> making sense
[09:55] <infinity> ogra_: That makes no sense.  Why is an i386 package pulling in libc6-amd64?
[09:56] <asac> infinity: android :)
[09:56] <ogra_> infinity, thats what i'm saying
[09:56] <didrocks> of course, I need to be root
[09:56] <infinity> (Not saying there isn't a massive glibc bug here, but installing libc6-amd64:i386 on amd64 is never a desired result)
[09:56] <didrocks> and can't in this / busybox
[09:56] <didrocks> so needing to reboot in initrd busybox
[09:56] <ogra_> infinity, its the android-emulator package apparently
[09:56] <asac> http://paste.ubuntu.com/6447333/
[09:56] <asac> thats the stuff in android-emulator
[09:57] <infinity> asac: That doesn't explain why it's forcing this weird set of packages to be installed.  What are its deps?
[09:57] <asac> infinity: it has emulator64 binaries in there
[09:57] <infinity> Oh, it explicitly depends on libc6-amd64 ... FUN.
[09:57] <asac> can the package say: libc6:amd64 | libc6-amd64 ?
[09:58]  * ogra_ has never used the package, i build it from the tree ... which 
[09:58] <asac> guess not :)
[09:58] <ogra_> ... requires the i386 libs installed already
[09:58] <infinity> xnox: Want to make android-emulator depend on libc6:amd64 and libstdc++6:amd64 instead, and just make it not work without multiarch?
[09:58] <infinity> Oh, wait.  Can't do that.
[09:58] <infinity> Grr.
[09:59] <infinity> Of course, it could just be an amd64 package, period, which would solve the issue.
[09:59] <infinity> Just make it not available on i386.
[09:59] <seb128> heh, why so much hate for i386 users
[09:59] <infinity> Or if it has i386 and amd64 bits, build one on one, one on the other, and have a metapackage that pulls in -i386 and -amd64 bits.
[10:01] <infinity> pull-lp-source: Downloading android_20131120-0225.orig.tar.xz from archive.ubuntu.com (191.659 MiB)
[10:01] <infinity> Gah.
[10:02] <ogra_> dont cry ... that used to be 500M in the past
[10:02] <infinity> I'm all for people reminding me that I have a glibc bug that really needs fixing, but I'm not sure this was the way to do it. :P
[10:02] <infinity> Quite entertaining if we've been telling people to install this.
[10:03] <ogra_> well ... https://wiki.ubuntu.com/Touch/Emulator
[10:04] <infinity> Okay, so it's already arch-restricted to i386... Splitting it to an i386 and amd64 bit wouldn't be rocket science.  And we already seem to be assuming users of this will have multiarch enabled.
[10:04] <ogra_> we only offer it in trusty
[10:05] <asac> I am pretty sure its not rocket science, but I assume that the android build system will have to be taught to build things separated by archs :)
[10:05] <ogra_> nah. that wouldnt work
[10:05] <asac> I assume ricard tried to avoid carryuing a big delta there for the time being
[10:06] <infinity> asac: No need to tell it to break things up.  Just find the i386 binaries and put them in emulator-i386, do the same for the amd64 binaries, and package it up.
[10:07] <infinity> Aaand, it's an hour-long build.  This'll be fun.
[10:07] <infinity> Oh well, can't sleep anyway with this cough.
[10:09] <infinity> Oh, derp.  This means I'd have to build it twice, though.
[10:09] <infinity> Once per arch.
[10:10] <infinity> Oh, wait.  You *can* depend on foo:arch.  crossbuild-essential does it.
[10:16] <asac> didrocks1: managed to get past the point of no command?
[10:16]  * asac assumes that no news is good news for now
[10:16] <didrocks1> asac: well, I need to create an usb stick
[10:16] <infinity> Doing a test build of this blind change: http://paste.ubuntu.com/6447414/
[10:17] <asac> nice one :)
[10:17] <Laney> bahaha, I like that hack
[10:19] <didrocks1> asac: that will teach me to not always have a root terminal opened…
[10:19] <didrocks1> (to start busybox as root)
[10:19] <mlankhorst> sabdfl: hey since we now lack a TB, can you make a decision on the MRE's I requested on technical-boards@lists.ubuntu.com ? https://lists.ubuntu.com/archives/technical-board/2013-October/001737.html
[10:19] <infinity> I'll see if I can fix the actual linker switcheroo mess in 2.18 (I was looking at that earlier anyway), but either way, we shouldn't be encouraging people to install the multilib stuff.
[10:20] <didrocks1> asac: seb128: maybe one of you can annotate the wiki with those infos (to not install the emulator on amd64 for now)? ^
[10:20] <infinity> mlankhorst: A one-time version bump like that isn't really a standing MRE that the TB should have to worry about anyway, the SRU team can probably take that in hand.
[10:21] <didrocks1> especially if people wants to clean up their machine then :p
[10:22] <mlankhorst> infinity: I just want to move things forward soon if possible. Pixman is the one I'm most worried about. But libdrm seems to require a bump every release, so it sort of would need a standing MRE. :P
[10:23] <infinity> mlankhorst: Sure, libdrm could use a standing MRE (or, though the versions make it look like "micro" releases, they're clearly not, and it probably needs something more like the firefox exception), but it's never had one before, so we can live without for a bit.
[10:24] <infinity> mlankhorst: Is this all well tested in a PPA somewhere?  Do you have a placeholder HWE SRU bug that you can attach tasks for all these packages to and detail the testing done and subscribe the SRU team?
[10:25] <mlankhorst> infinity: libdrm is weird, most of the driver stuff is just a c wrapper for the kernel interface
[10:25] <mlankhorst> https://launchpad.net/~ubuntu-x-swat/+archive/s-lts-backport
[10:25] <Saviq> seb128, "don't uninstall libc6-amd64"? or "don't install libc6-amd64"?
[10:25] <infinity> Saviq: Yes.
[10:25] <infinity> Saviq: Don't install it, but if you have, uninstalling it is also dangerous.
[10:25] <seb128> Saviq, don't uninstall it if you have it installed
[10:25] <mlankhorst> I think I created a bug for the pointer barriers specifically, but I didn't make one for pixman and libdrm yet.
[10:25] <Saviq> seb128, so I can still try the emulator on amd64, just never uninstall it? ;D
[10:26] <mlankhorst> ppa with all components at https://launchpad.net/~ubuntu-x-swat/+archive/s-lts-backport
[10:26] <seb128> Saviq, basically, or better wait for infinity to fix those stuff ;-)
[10:26] <infinity> I wonder if I could work around this hackishly by providing a libc6-amd64 on amd64 that just Depends: libc6.
[10:26]  * infinity shudders a bit at the ickiness of that.
[10:27] <mlankhorst> infinity: or finally implement cross-arch depends. :P
[10:27] <infinity> mlankhorst: If you could just do up a meta bug for "lts-s backports" and detail what needs review, and what's been tested and how, then we can point any discussion there.
[10:27] <infinity> mlankhorst: cross-arch deps work.
[10:27] <mlankhorst> ok
[10:28] <mlankhorst> I think I will make the metabug the bug for pixman/libdrm backporting too
[10:28] <infinity> mlankhorst: That doesn't solve this particular issue of people installing libc6-amd64:i386 on amd64.
[10:28] <infinity> Which explodes hilariously.
[10:28] <mlankhorst> why have that? o.O
[10:28] <infinity> Maybe we just need a Multi-Arch: dont-even header.
[10:29] <infinity> Package: libc6-amd64
[10:29] <mlankhorst> I thought that was what the Architecture: field was for, just build it on amd64 only. :P
[10:29] <infinity> Multi-Arch: hahahahano
[10:29] <infinity> mlankhorst: Erm it's only built on i386.
[10:29] <mlankhorst> oh
[10:29] <infinity> mlankhorst: But then people install an i386 package that depends on it.
[10:29] <infinity> On their amd64 system.
[10:29]  * didrocks1 wonders why usb-creator doesn't want to finish the current usb stick creation… will go with dd if this continues…
[10:29] <infinity> didrocks1: Just use dd.  usb-creator is a steaming heap of needs a lot of love.
[10:30] <infinity> (I think there may even be a UDS session about that?)
[10:30] <smb> infinity, was
[10:30] <didrocks1> infinity: yeah, I can testify this right now :)
[10:30] <infinity> Or was. :P
[10:30] <infinity> smb: How did that go?
[10:30] <smb> infinity, I think we use something different
[10:30] <mlankhorst> oh found the pointer barriers bug https://bugs.launchpad.net/ubuntu/+source/x11proto-input/+bug/1242633
[10:30] <pitti> dd wrapped in a GTK dialog?
[10:30] <mlankhorst> I'll open a metabug
[10:31] <infinity> pitti: Well, the reason for usb-creator (the only valid reason, other than the pretty GUI) is that it knew how to set up the weird partition scheme required for persistence.  dd alone can't pull that off.
[10:31] <smb> infinity, Actually there seems to be a more interesting issue on the side about having something that works with uefi and secure boot but not wasting most of your usb key
[10:31] <pitti> infinity: right, was mostly kidding
[10:32] <smb> infinity, Plus I thought there was an issue at least with older bioses of not booting an iso fs on a usb key
[10:32] <infinity> But for 99% of people who just want an installer USB key and don't give a crap about persistence, yeah, usb-creator really could just fork dd.
[10:32] <pitti> I actually successfully used usb-creator in saucy still, it's sad that it broke down so quickly
[10:32] <infinity> pitti: It's been broken for several releases, success rates seem to vary from person to person and moon phase.
[10:33] <smb> amd64 being better that trying to do i386 images in my experience
[10:33]  * infinity shields his eyes from all the code duplication he sees zipping past in this Android build log.
[10:33] <infinity> LA LA LA, CAN'T SEE YOU, HANDWAVE, GOING FOR A DRINK.
[10:34] <smb> Sadly coffee has not the desired effect... and at least its not ktb#1 time for me
[10:35] <infinity> smb: Choice of beverage really doesn't matter to me right now.  I should be either asleep or at a doctor's office, and I'm neither, so I'm failing at life.
[10:35] <smb> infinity, Yeah well, highly depends on your current location which often is hard to guess
[10:36] <infinity> smb: Calgary.  I think.  It's a bit hazy.
[10:38] <smb> infinity, That might be true now but was not last(?) week. Which could probably be part of the issue, too
[10:39] <didrocks> phew
[10:39] <didrocks> thanks infinity, asac (et jibel for testing in a vm)
[10:39] <infinity> didrocks: All gooder?
[10:39] <didrocks> yeah ;)
[10:39] <infinity> I really need to come up with a clever fix for that.
[10:39] <didrocks> the longest was to download/create this usb stick…
[10:40] <infinity> I was going to use dpkg diversions when I first found this issue in precise, but dpkg-divert had a bug that prevented it...
[10:40] <didrocks> I'll build an initramfs dropping me in a busybox for next time :p
[10:40] <infinity> That's now fixed, but it would break on upgrades FROM precise...
[10:40] <infinity> So.  Whee.
[10:40] <didrocks> infinity: oh? interesting
[10:41] <infinity> Only mildly interesting.  Mostly just annoying.
[10:41] <didrocks> (but, can be epic between the version without the fixed dpkg and then)
[10:41] <infinity> I can either bury my head in the sand and pretend the bug doesn't exist until 14.10 and fix it with diversions when I can do it safely.  Or come up with a more clever hack to work around it now.
[10:42] <infinity> And I think I almost mapped out a clever fix in my head about an hour before you broke your computer.
[10:42] <infinity> But that could just be the drugs talking.
[10:42] <infinity> I'll need to commit it to code when I'm more aware of my surroundings and see if I'm drunk.
[10:43] <didrocks> infinity: heh, sounds like a good plan, meanwhile, le'ts put an info in the wiki for the emulator, as I guess it's the main case for people getting into that bug
[10:44] <mlankhorst> infinity: https://bugs.launchpad.net/ubuntu/precise/+source/libdrm/+bug/1253041
[10:45] <infinity> didrocks: I might pull the emulator binaries from the archive for now.
[10:45]  * infinity does that.
[10:45] <infinity> Removing packages from trusty:
[10:45] <infinity> 	android-emulator 20131120-0225-0ubuntu1 in trusty i386
[10:45] <infinity> Comment: High chance of breaking amd64 systems
[10:45] <infinity> Remove [y|N]? y
[10:46]  * infinity waves bubye.
[10:46] <infinity> If my test build goes okay, I'll upload that.
[10:46] <asac> thx. let us know
[10:47] <infinity> With a nasty side-effect that people who *did* install the broken version of the emulator might get libc6-amd64 autoremoved and land in your situation...
[10:47] <infinity> What fun that will be.
[10:50] <didrocks> infinity: TBH, I won't test you hack today :p
[10:50] <seb128> infinity, asac, didrocks: since that was announced on the list (https://lists.launchpad.net/ubuntu-phone/msg05195.html) I guess we can count on quite some people installing/trying it... would be better to not autobrick their systems with the update (e.g maybe fix the libc side if we can before updating the emulator)
[10:50] <didrocks> your*
[10:51] <didrocks> right, I'm going to summarize what to do in case someone is broken?
[10:51] <infinity> seb128: The libc fix will take some more thinking.
[10:51] <seb128> didrocks, is that a question? yes please follow up on the list ;-)
[10:51] <infinity> seb128: And people installing the emulator might be removing it too.  Which already puts them in this situation.
[10:52] <infinity> (Granted, very few people also do autoremove religiously)
[10:54] <asac> isnt update-manager doing autoremove?
[10:55] <infinity> Oh, is it?  Fun.
[10:55] <seb128> asac, not in normal update mode at least, maybe in dist-upgrader mode
[10:55] <asac> not sure... asking :)
[10:55] <infinity> I didn't *think* it did.
[10:56] <asac> (i have to admit that i got stuck in old apt-get habits)
[10:56] <didrocks> I did autoremove religiously, not sure if one of our tool is doing that :)
[10:56] <asac> seb128: right. i think dist upgrading does autoremove
[10:56] <asac> not normal upgrades
[10:56] <asac> dont think thats better though ... just makes the support bomb more intense :)
[10:57] <infinity> Nah, buys me time until April to fix it!
[10:57] <asac> otoh, we can add arbitrary hackery to mitigate such issues in update-manager...
[10:57] <infinity> (I'll make it a priority right after 2.18 is otherwise ready, unless the answer comes to me while I'm at the doctor's in the morning)
[11:04] <tseliot> pitti: sorry to bother you again but the binaries for nvidia-graphics-drivers-304 and its -updates flavour are stuck in NEW (trusty)
[11:04] <tseliot> pitti: they include the same changes that you approved in the 331 series
[11:06] <pitti> tseliot: ah, the new libraries, yes; looking
[11:06] <tseliot> thanks
[11:21] <tseliot> pitti: thanks a lot!
[11:31] <ahasenack> hi guys, I have a recipe (https://code.launchpad.net/~ahasenack/+recipe/juju-deployer-daily) that started failing to build on trusty,
[11:31] <ahasenack>  dpkg-source -i -I -b recipe-{debupstream}+bzr{revno}-0~{revno:packaging}
[11:31] <ahasenack> dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision
[11:31] <ahasenack> but my packaging branch has source format "3.0 (quilt)"
[11:32] <ahasenack> is this an artifact of how recipes are built in launchpad?
[11:32] <ahasenack> the same package builds on saucy, for example
[11:32] <ahasenack> maybe a flag was switched in trusty to make that a fatal error?
[11:36] <infinity>   * Catch mismatches between version strings and format versions in
[11:36] <infinity>     dpkg-source. Ensure that a 3.0 (quilt) package has a non-native version
[11:36] <infinity>     and that a 3.0 (native) package has a native version. Closes: #700177
[11:36] <infinity> ahasenack: New dpkg enforces this, yes.
[11:36] <ahasenack> ok, so it looks like launchpad recipe builds will break if your package is 3.0 (quilt)?
[11:37] <ahasenack> http://bazaar.launchpad.net/~ahasenack/juju-deployer/juju-deployer-packaging/view/head:/debian/source/format is what my recipe uses
[11:37] <StevenK> You need pristine-tar information in the branch for the recipe to construct a tarball, otherwise it will override your recipe to 3.0 (native)
[11:38] <ahasenack> https://launchpadlibrarian.net/156978348/buildlog.txt.gz buildlog
[11:38] <ahasenack> StevenK: what's "pristine-tar information"?
[11:39] <StevenK> ahasenack: pristine-tar allows you to regenerate any tarball you've made from the repository information, 'man pristine-tar'
[11:39] <ahasenack> StevenK: but there is no tarball on my side, it's a launchpad recipe, it builds the package from branches
[11:39] <infinity> StevenK: Oh, does pristine-tar actually allow recipes to DTRT here?  Nice.
[11:40] <StevenK> infinity: Yes
[11:40] <infinity> ahasenack: Yes, but pristin-tar is the glue that allows you to recreate the orig.tar.gz out of your branch.
[11:40] <StevenK> infinity: Do you want to help ahasenack since it's like 2240
[11:40] <ahasenack> infinity: and what do I do with it? I have to upload it to the ppa manually first, then recipes will work, or what's the idea?
[11:40] <infinity> StevenK: Not really, it's 0440 here, and I'm sick. :P
[11:40] <ahasenack> oh boy :)
[11:40] <StevenK> Haha
[11:40] <ahasenack> looks like you both need to be asleep
[11:42] <ahasenack> infinity: that bug number from the changelog snippet you pasted seems wrong, btw, it's about "os-prober failed to detect both Windows bootable partition" ;)
[11:42] <xnox> ahasenack: the answer to your troubles, is to modify the recipe version used for the package, such that it is a native one.
[11:43] <infinity> ahasenack: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
[11:43] <xnox> ahasenack: otherwise, you need original tarball, which you say you don't have.
[11:43] <ahasenack> infinity: ah, debian
[11:43] <StevenK> xnox: He can recreate an orig tarball with pristine-tar
[11:43] <ahasenack> xnox: it's a recipe build, I would think that LP would take care of it (generate the tarball)
[11:43] <ahasenack> do you guys use launchpad recipes? Maybe I'm barking at the wrong tree
[11:44] <xnox> StevenK: he wants to daily-build master crap no matter what it is, not generate orig tarball for each commit ;-)
[11:44] <xnox> ahasenack: so in {debupstream}+bzr{revno}-0~{revno:packaging}, remove the "-" =)
[11:45] <ahasenack> xnox: yeah, was going to paste
[11:45] <ahasenack> {debupstream}+bzr{revno}~{revno:packaging} maybe
[11:45] <ahasenack> or s/~/+/
[11:45] <xnox> ahasenack: then your recipe will be native, no original tarball needed, and it will just build.
[11:45] <ahasenack> will have to think about it
[11:45] <xnox> ahasenack: that one will work too.
[11:45] <infinity> Depends: libstdc++6:amd64 (>= 4.1.1), libc6 (>= 2.15), libc6:amd64 (>= 2.15), libgcc1 (>= 1:4.1.1), libgl1-mesa-glx, libstdc++6 (>= 4.6), libx11-6
[11:45]  * ahasenack ponders upgrades and all that stuff
[11:45] <infinity> I win.
[11:46] <xnox> ahasenack: i think "+" will be better.
[11:46] <ahasenack> yep
[11:46] <ahasenack> xnox: thanks
[11:46] <xnox> infinity: enlighten me about your winnings =)
[11:47] <ahasenack> and lp will still add ~ubuntu<release-number> at the end
[11:47] <xnox> yes
[11:47] <ahasenack> ok, let's kick it
[11:47] <ahasenack> thanks again
[11:48] <infinity> xnox: Making your emulator stop pulling in libc6-amd64:i386
[11:49] <xnox> infinity: patches welcome.
[11:49] <xnox> infinity: what should I do? =)
[11:49] <infinity> xnox: You can pull the patch from the archive shortly. :P
[11:49] <xnox> infinity: ah, even better. thanks for that.
[11:50] <infinity> Man, this source takes a while to re-pack on a rotary disk.
[11:50] <xnox> =)
[11:51] <infinity> xnox: http://paste.ubuntu.com/6447754/ FWIW.
[11:52] <infinity> xnox: With bonus guilt-induced tech-debt swap.
[11:52] <infinity> Also, I can't spell dirty.
[11:52]  * infinity doesn't upload.
[11:52] <arun> hello guys I had a question !!! should we ask any sort of permission on developing a distro based on UBuntu named as Obuntu under the support of Obuntu group ?
[11:53] <infinity> arun: Yes.
[11:53] <xnox> arun: yes, "*buntu" is protected.
[11:54] <ogra_> infinity, your patch drops xz compression, doesnt it ?
[11:54] <infinity> arun: https://forms.canonical.com/trademark/
[11:54] <arun> Guys, where can we ask for it ?
[11:54] <xnox> ogra_: xz is default. see changelog entry above.
[11:54] <infinity> ogra_: Reading changelogs is hard?
[11:54] <ogra_> bah, i only looked at the bottom :P
[11:55] <xnox> arun: see link infinity pasted.
[11:55] <infinity> xnox: Uploaded.
[11:55]  * infinity is going to see if he can nap for a few minutes before coughing himself awake again.
[11:56] <xnox> infinity: .... thanks. it doesn't help any other packages that build-depend on gcc-multilib though. Or would this be solved by builders having multiarch enabled?
[11:56] <arun> and by the way , what is  loCo ?/
[11:57] <infinity> xnox: There aren't many packages that actually end up depending on libc6-amd64/libc6-i386, but you're right, this won't help those that do.
[11:57] <infinity> xnox: I still need to fix the libc bug that causes that situation to explode, but depending on biarch libs is generally wrong regardless, IMO.
[11:57] <xnox> arun: LoCo = Local Community, i.e. local community groups representing ubuntu in their region.
[11:58] <arun> xnox: oh
[11:58] <xnox> arun: typically they are known and participate in the Ubuntu community and thus are registered with Ubuntu Project and receiving sponsorship (e.g. free CDs & marketing materials) to promote Ubuntu.
[11:58] <ogra_> https://wiki.ubuntu.com/LoCoTeams
[11:58] <arun> Guys , does Canonical feeds Ubuntu devs ???
[11:59] <brendand> arun, we have to feed ourselves
[11:59] <xnox> arun: there are girls here as well. and these sort of questions you are asking are not related to development of ubuntu core itself. Maybe you can take this conversation to #ubuntu instead?
[12:00] <xnox> arun: i'm sure there are plenty of people who can answer these generic questions about Ubuntu Project.
[12:00] <arun> brendand: oh ok
[12:00] <arun> xnox: ok thanks a lot ; I think I went off topic
[12:02] <arun> Guys, is Unity based on Gnome 3 ?
[12:18] <mlankhorst> hmz
[12:18] <mlankhorst> MismatchError: True != False
[12:18] <mlankhorst> but that statement is true :o
[13:02]  * jpds wonders why we have a super-old util-linux on Ubuntu.
[13:04] <jpds> infinity, lamont: Oh, hi. :)
[13:06] <mitya57> Hi, I see bug 1253003 in the sponsoring queue. Any hint why that has not been auto-synced yet?
[13:12] <mitya57> gilir: Hi, may I ask you to look at https://code.launchpad.net/~m-alaa8/ubuntu/saucy/pcmanfm/fix-for-993996/+merge/195625 please?
[13:49] <pitti> $ LANG= bzr branch ubuntu:systemd-shim
[13:49] <pitti> bzr: ERROR: Revision {package-import@ubuntu.com-20130502111419-gg4b0m966tgp1p72} ist nicht in »Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))« vorhanden.
[13:49] <pitti> err, what does that want to tell me?
[13:49] <pitti> any known workaround?
[13:50] <pitti> err, neither LANG, LC_ALL, LANGUAGE help -- says something like "... revision ... isn't present in Graph.."
[13:52] <seb128> pitti, it's telling you "stop using udd"?
[13:52] <mdeslaur> lol
[13:52] <seb128> dunno about the specific error though :/
[13:52] <pitti> seb128: probably :/ I wanted to give it another try for developing some autopkgtests, but I guess I'll just go the classical way
[13:52] <Laney> omg, a lesser spotted wednesday troll
[13:52] <seb128> ups, did I troll again?
[13:52]  * seb128 needs to stop that
[13:53] <ogra_> yeah, not friday yet
[13:53] <Laney> haha
[13:53] <pitti> one of the few packages which don't have patches, and thus would be manageable with UDD>.
[13:53] <ogra_> fix my firefox tooltip instead :P
[13:58] <cjwatson> [New] wxwidgets3.0_3.0.0-1
[13:58] <cjwatson> No previous publications in Ubuntu
[13:58] <cjwatson> OK (Y/n)?  y
[13:58] <cjwatson>  * Trying to add wxwidgets3.0 ...
[13:58] <cjwatson> wxwidgets3.0_3.0.0-1 is trying to override modified binary wx-common_2.8.12.1-14ubuntu2.  OK (y/N)?  n
[13:58] <cjwatson> mitya57: ^- that's why
[13:59] <cjwatson> mitya57: somebody needs to work out if those two changes need to be forward-ported to 3.0
[13:59] <mitya57> cjohnston: oh thanks, will reject the bug for now then
[14:00] <mitya57> Bad xchat.
[14:02] <cjwatson> I should tee the output of auto-sync to a file on people or something
[14:36] <seb128> roaksoax, hallyn_: hey, did you guys upstream that avahi patch you uploaded to trusty?
[14:46] <smoser> slangasek, around ?
[14:46] <slangasek> smoser: vUDS
[14:46] <smoser> would you think that bug 1235231 is fixable ?
[14:51] <hallyn_> seb128: we could try submitting it to debian...  i'm not sure it's appropriate.  it's a workaround for lack of user namespaces, and i'm not very happy with it
[14:51] <hallyn_> seb128: oh, actually no we can't submit it to debian really, bc it relies on upstart
[14:52] <slangasek> smoser: what do you mean, "fixable"?  I already said in the bug log that the cloud images should just override plymouth to stop it from running
[14:52] <seb128> hallyn_, hum, k, next time it would be nice to put those details in the patch header to make work easier for whoever is looking e.g at merging that package next
[14:53] <hallyn_> agreed
[14:53] <seb128> thanks
[14:55] <smoser> slangasek, i just added a comment there.
[14:55] <smoser> by "fixable" i meant "stop being broken".
[14:55] <smoser> plymouth is explicitly "supposed" to replay content it captures. its a clear bug that it does not do that.
[14:55] <hallyn_> seb128: sorry, it didn't occur to me yesterday that it depended on upstart.
[14:55] <smoser> (as are most dataloss issues :)
[14:56] <seb128> hallyn_, no problem, thanks for the reply to my questions!
[14:57] <slangasek> smoser: don't count on a fix for that any time soon.  Workaround is known, and we don't have resources to fix all the plymouth issues any time soon
[14:57] <smoser> ok. well, then i would appreciate your thoughts as to my comment 19 there, and i'll look to get this in sooner rather than later.
[15:03] <slangasek> smoser: replied
[15:06] <smoser> slangasek, yeah, but you didn't reply the way i wanted.
[15:06] <smoser> i'd much rather have the disabler package close to plymouth, so that when/if a new upstart job is added its obvious it needs ot be fixed.
[15:06] <slangasek> there aren't going to be more upstart jobs
[15:06] <slangasek> and half those overrides are niceties
[15:17] <pitti> ooooh! http://alioth.debian.org/ just came back
[15:18] <tseliot> \o/
[15:19] <mlankhorst> yay
[15:19] <cjwatson> Yeah, it's on its way, I think they're still putting some pieces back together
[15:20] <Laney> ssh vasks works, at least, although the filesystem doesn't seem (fully) restored
[15:20] <cjwatson> Er
[15:20] <cjwatson> vasks is going away
[15:20] <cjwatson> It's being replaced by a new host
[15:20] <roaksoax> seb128: i didn't yet.
[15:21] <pitti> yeah, host key changed (understandably)
[15:21] <pitti> Laney: moszumanska now
[15:21] <cjwatson> I suggest waiting for an announcement from the alioth admins before pushing stuff
[15:21] <Laney> ah
[15:21] <Laney> I've been checking d-i-a
[15:21] <Laney> no news of that there
[15:22] <pitti> might still take a bit until it gets official, but I'm happy to see it alive again after two weeks
[15:34] <shadeslayer> cjwatson: uhm, stupid question, there was this package which had a script to build your own ubuntu live cd ( not live-rootfs ), do you know which one it was?
[15:35] <shadeslayer> oh
[15:35] <shadeslayer> it *is* live-rootfs
[15:35] <cjwatson> livecd-rootfs
[15:36] <cjwatson> but ignore livecd.sh, use the live-build hooks there
[15:36] <cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
[15:36] <shadeslayer> *nod*
[16:04] <smoser> mhall119, what circumstances make the 'Join hangout' link appear ?
[16:04] <jcastro> I beleive the person who runs the session needs to provide summit with the link
[16:04] <smoser> http://summit.ubuntu.com/uds-1311/meeting/22045/servercloud-1311-maas/ has hangout details, and i'm logged in, but id ont see it.
[16:05] <smoser> ah. its there now.
[16:05] <smoser> it must only appear after start of session (it should have a grace "join" period)
[16:05] <mhall119> smoser: 1) it's within the slot's start & end times, 2) the user is logged in, 3) the user is marked as attending the UDS
[16:06] <mhall119> also 4) you're not getting a stale page from the caching server sitting in front of summit.u.c
[16:06] <smoser> mhall119, well can i suggest that '1' be tweaked to include 10 or 15 minutes prior ?
[16:07] <slangasek> rbasak, smoser: do you want anyone from the server team to come to the Secure Boot session?
[16:07] <smoser> is that now ?
[16:07] <smoser> :-(
[16:07] <mhall119> smoser: you can if you file a bug for it
[16:07] <mhall119> lp:summit
[16:07] <seb128> tjaalton, tseliot, mlankhorst, coming to the xorg for t vUDS session? https://plus.google.com/hangouts/_/7ecpjg4e7ibk4vghv8fkul3tt8?authuser=0
[16:07] <smoser> k
[16:07] <slangasek> smoser: yep
[16:08] <smoser> k.
[16:08] <seb128> RAOF, ^ up? or is it still night time for you?
[16:09] <smoser> slangasek, joining
[16:11] <smoser> slangasek, can you give me a link ?
[16:11] <slangasek> https://plus.google.com/hangouts/_/72cpj2k5dn4bjr053d5ehn1lpo
[16:20] <smoser> anyone interested, http://pad.ubuntu.com/lower-third
[16:20] <smoser> thats my "howto" for vuds and lower third
[16:21] <josepht> smoser++
[16:26] <tedg> stgraber, I couldn't come to the Upstart session, but do you expect the cgroup to be created for pre-start or only when executing the job.
[16:28] <stgraber> tedg: I think we decided to go with consistency with other limit stanzas, so pre-start would also be put in the cgroup
[16:29] <tedg> stgraber, So then would pre-start be able to configure the cgroup?  i.e. this group can only use 100MB of RAM
[16:29] <stgraber> tedg: yes but it shouldn't cgroup limits should be applied through the cgroup stanza
[16:30] <tedg> stgraber, Ah, okay.  I thought the stanza only created, didn't realize the limits could be there.
[16:31] <stgraber> anyway, I'm planning to send a mail to upstart-devel later today with the suggested implementation
[16:31] <tedg> stgraber, K, I'll wait for that before I get confused :-)
[16:35] <seb128> it seems that powerpc-porter is still down, do we have any alternative solution to debug ppc issues?
[16:36] <cjwatson> I used the "machine in infinity's house" solution last time I needed it
[16:37] <dholbach> jibel, congratulations! finally! :)
[16:37] <pitti> jibel: oh, got your membership?
[16:37] <highvoltage> tedg: it's ok, you can spawn your own upstart session :p
[16:37] <ogra_> jibel, whee !
[16:38] <seb128> jibel, congrats!
[16:38] <seb128> cjwatson, thanks, we did that last time as well for indicators issues, might need to do it again...
[16:39] <seb128> infinity, ^
[16:39] <cjwatson> seb128: or you could get the package cross-building
[16:40] <seb128> I guess that's an option, less easy to set up though
[16:41] <tedg> highvoltage, I'm partially responsible for *everyone's* upstart session ;-)
[16:41] <seb128> would be nice if we had a porter box available :/
[16:41] <tedg> seb128, You can probably get a PlayStation 3 cheap :-)
[16:42] <cjwatson> we desupported those rather a long time ago :)
[16:42] <seb128> tedg, funny that you speak, the issues are indicators one, I could just get you to fix your stuff... ;-)
[16:42] <seb128> tedg, if you buy a ps3 for that, fine by me :p
[16:43] <tedg> seb128, Heh, it's a lot more than just indicators.  Webbrowser, upstart-app-launch, etc.
[16:43] <ogra_> heh
[16:44] <seb128> tedg, do we have an idea if that's a toolchain issue or what?
[16:44] <seb128> cyphermox, ^
[16:44] <tedg> It seems a lot of them are actually dependency waits.
[16:44] <seb128> oh, indicators are failing tests
[16:44] <tedg> So some false positive just looking at the icons.
[16:45] <tedg> I'm curious if it's not starting the X wrapper or something like that.
[16:45] <seb128> google test hiding the output sucks :/
[16:45] <seb128> tedg, e.g https://launchpadlibrarian.net/156991211/buildlog_ubuntu-trusty-powerpc.dbus-test-runner_14.04.0%2B14.04.20131120-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:45] <seb128> the log is pretty much useless
[16:45] <Laney> blame automake not google
[16:46] <seb128> https://launchpadlibrarian.net/156995004/buildlog_ubuntu-trusty-powerpc.hud_13.10.1%2B14.04.20131120-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:46] <seb128> is interesting
[16:46] <seb128> *** stack smashing detected ***
[16:47] <tedg> Yeah, it is odd.
[16:47] <tedg> Seems like a common thread is Python?
[16:47] <seb128> I've seen similar stack smash errors in one of the indicators
[16:47] <tedg> Some of the tests that use python was failing, and the dbusmock tests obviously use python.
[16:48] <seb128> doko, ^ is there a known issue with python3 on ppc on trusty?
[16:49] <tedg> *** stack smashing detected ***: python3 terminated
[16:50] <doko> seb128, updated python3 yesterday, so it could be possible
[16:50] <seb128> didrocks, cyphermox, tedg: when did those tests issues start?
[16:51] <cyphermox> two or three days ago. I'm not sure
[16:51] <cyphermox> I don't think this is python issues
[16:51] <doko> python3 changed yesterday
[16:51] <seb128> ok :/
[16:51] <tedg> Not sure either.  I just updated dbus-test-runner to use dbus-mock, so we've started using more of it as a result.
[16:51] <cyphermox> I'll get the logs shortly, there's a build running for powerpc now
[16:52] <cyphermox> tedg: seb128: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5249058
[16:52] <seb128> cyphermox, well, e.g https://launchpadlibrarian.net/156995004/buildlog_ubuntu-trusty-powerpc.hud_13.10.1%2B14.04.20131120-0ubuntu1_FAILEDTOBUILD.txt.gz has smashed stack python errors
[16:52] <cyphermox> well, yeah, but that might well be something different
[16:52] <cyphermox> I'd like to know for sure, and that we can get with full logs.
[16:58] <marrabld> I have a few questions about packaging.  I used to package an App in my ppa.  But since Ubuntu moved where it keeps the QT libraries my recipes have failed for modern versions of Ubuntu.  So I have to take another look at my packaging scripts.  I am going to separate my packaging scripts from the code repo (currently in the same repo as the code).
[16:58] <marrabld> So my first question is, should I put my debian directory in a separate branch and then get my recipe to merge the branches or should I put them in a separate repo.?
[17:00] <seb128> cyphermox, tedg, doko: https://launchpadlibrarian.net/157024833/buildlog_ubuntu-trusty-powerpc.indicator-messages_13.10.1%2B14.04.20131120.0-0ubuntu2_FAILEDTOBUILD.txt.gz
[17:00] <seb128> *** stack smashing detected ***
[17:01] <seb128> seems like a ppc toolchain issue
[17:01] <seb128> test-gactionmuxer is having the same problem than python
[17:01]  * tedg blames the stack for allowing itself to get smashed
[17:02] <tedg> Yeah, thinking so.
[17:02] <tedg> Not sure what, I guess we'd need a valgrind run to get some clues on what is happening.
[17:02] <seb128> doko, ^ did the ppc toolchain change recently? any idea about that?
[17:05] <smoser> anyone interested, http://paste.ubuntu.com/6449132/
[17:05] <smoser> thats a hacky script that reads a vuds link and makes nicely formated list of links to Hangout, Etherpad, IRC ...
[17:10] <hikenboot> hello I have saucy and am wondering if there is packages for gmp mpfr and mpc (prepackaged version for this version of ubuntu)
[17:11] <hikenboot> trying to consistently compile gcc correctly a package would be helpful
[17:12] <jtaylor> hikenboot: sure all build depends of gcc are packaged
[17:12] <jtaylor> apt-get build-dep gcc
[17:12] <jtaylor> also gets you ppl cloog etc
[17:12] <hikenboot> ah awsome ok didnt see that one coming but should have!
[17:13] <cjwatson> well, "apt-get build-dep gcc-4.8" is more likely to be useful
[17:13] <cjwatson> gcc -> just the defaults links
[17:14] <jtaylor> right different source :/
[17:14] <hikenboot> thanks a bunch..its really appreciated!
[17:45] <pitti> jibel: how difficult is it to fix britney/the test scripts to run newly uploaded autopkgtests?
[17:45] <pitti> jibel: e. g. I just added tests to systemd-shim, and it got promoted without running the new tests
[17:45] <pitti> s/promoted/propagated/
[17:58] <jamespage> doko, hey are you OK to attend at least the first part of the juju activities for trusty session - specifically to discuss golang support in main
[17:58] <doko> jamespage, sorry no
[17:59] <jamespage> mwhudson, ^^ any chance you could attend as doko v2?
[18:04] <doko> seb128, ?
[18:17] <Saviq> Mirv, still around?
[18:23] <Mirv> Saviq: following the sessions for a bit still
[18:23] <Mirv> what's up?
[18:24] <Saviq> Mirv, when you have a minute (doesn't have to be today) - any reason why http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/qtdeclarative-opensource-src/trusty/view/head:/debian/patches/qtquick_delegate_creation_range_itemviews.patch is dropped from 5.2?
[18:24] <seb128> does anyone know how to debug "invoke-rc.d: initscript dbus, action "start" failed." issues (happening in a chroot)
[18:25] <seb128> unping, dbus is not needed to debug that build issue (though still happening when those happen)
[18:25] <Mirv> seb128: /var/lib/dpkg/info/dbus.postscript?
[18:25] <seb128> Mirv, postscript? postinst you mean?
[18:26] <seb128> Mirv, well, ideally the start job wouldn't fail which is real issue
[18:26] <seb128> Mirv, but yeah, it can be hacked around by hacking the postinst or the init job
[18:26] <Mirv> seb128: exactly :) I've removed the failing lines when installing packages in chroot
[18:27] <Mirv> Saviq: probably it didn't apply or I thoight it's merged upstream
[18:27] <seb128> Mirv, ideally we would make the install work in a chroot rather than ask everyone to workaround it though ;-)
[18:28] <Saviq> Mirv, yeah, we'd need to port it, that one is something we're carrying ourselves, unfortunately
[18:28] <Mirv> Saviq: ah, ok
[18:30] <Mirv> seb128: sure.. I've thought it'd probably work with enough bind mounts (/dev, /sys etc) but I haven't bothered to automate those although there are tools for that too
[18:31] <infinity> seb128: My chroots all have a policy-rc.d in them that prevents daemon startup.
[18:31] <infinity> seb128: mk-sbuild does this for you.
[18:40] <seb128> thanks, I was mostly trying to help one of the Debian guys who wants to look at the smashed stack trusty issues
[18:43] <xnox> seb128: mk-sbuild is in debian.
[18:43] <xnox> seb128: "sudo apt-get install ubuntu-dev-tools; mk-sbuild trusty; schroot -u root -c trusty-amd64/i386" works on debian.
[18:43] <seb128> xnox, yeah, I don't know what he's using, he was just hitting dbus not installing because of that error
[18:44] <seb128> but that's fine, he forced over it and that's good enough for debugging the issue
[18:46] <seb128> Laney, mardy: just for info, e-d-s upstream reply about uoa/calendar
[18:46] <seb128> "I think I know what's wrong: I forgot to update the UOA .service files for
[18:46] <seb128> Google's OAuth-based CalDAV interface.  Just need to find time to test it."
[19:04] <pitti> zul: python-misaka tests fail with "ImportError: No module named 'misaka': https://jenkins.qa.ubuntu.com/job/trusty-adt-python-misaka/1;
[19:05] <pitti> zul: sorry, email notifications are broken since the CI lab change, thus playing relay..
[19:06] <zul> pitti:  crap ill fix it up
[19:06] <pitti> zul: thanks (probably just a missing test dep)
[19:07] <zul> pitti:  yeah :(
[19:08] <slangasek> mlankhorst: are you able to join the session for hwe planning for 14.04?
[19:08] <slangasek> mlankhorst: https://plus.google.com/hangouts/_/72cpi5mshd3mujd9pk5te8c50s
[19:14] <lool> cjwatson, slangasek: If either of you feels like joining the Go session, that might be useful for packaging related questions
[19:14] <slangasek> lool: can't, running another session; cjwatson?
[19:15] <cjwatson> yeah
[19:20] <smoser> bdrung, thoughts? https://bugs.launchpad.net/ubuntu/+source/distro-info/+bug/1253208
[19:53] <mwhudson> jamespage: send me email but probably not, i am on leave in an inconvenient timezone :)
[20:33] <ogra_> cjwatson, is there some config file that needs editing to get ubuntu-touch onto http://people.canonical.com/~ubuntu-archive/germinate-output/ ?
[20:54] <cjwatson> ogra_: script, but yes - edited snakefruit:~ubuntu-archive/bin/update-germinate, so that should appear for you on the next run
[20:55] <ogra_> thanks !
[20:55] <ogra_> pmcgowan always asks me weird questions why a package is in the image ... that might help a bit :)
[20:55] <pmcgowan> thanks
[20:55] <cjwatson> Yep, indeed
[20:56] <cjwatson> My oversight that it wasn't there already
[22:21] <bdrung> smoser: hi, i am happy to accept patches.
[22:22] <bdrung> smoser: returning a dict has the drawback that it could be hard to support if we want to change the internal
[22:22] <bdrung> smoser: we could add functions instead that take a series and return the fullname/version/etc
[22:24] <xnox> cjwatson: I get "dpkg-checkbuilddeps: Unmet build dependencies: libdbus-1-dev:native (>= 1.4) libexpat1-dev:native (>= 2.0.0)" when i did $ sbuild --host armhf, on just pushed lp:ubuntu/libnih
[22:25] <xnox> cjwatson: that's using trusty chroot, am I missing something? should i use some specific build-deps resolver in sbuild?
[22:39] <mlankhorst> slangasek: sorry I was eating at that time :(
[22:39] <mlankhorst> and had to be somewhere at 9, evenings are terrible
[22:39] <slangasek> mlankhorst: eating, in the middle of UDS?  surely not
[22:44] <barry> kirkland: LP: #1253458
[22:48] <pero> can anyone help me get back the unity webapps extension in chromium? it somehow disappeared and i'm at a loss on how to get it back
[23:11] <mlankhorst> oh well night