=== freeflying_away is now known as freeflying === Mapley is now known as Mapley|group [04:28] Good morning [04:29] 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] 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] stgraber: ah, so the daemon's API would always be "relative" to the calling cgroup? [04:31] 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] pitti: correct [04:31] stgraber: thanks [04:32] 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] Can someone look into removing rhythmbox-radio-browser? It is pretty much non-functions due to rhythmbox api changes === brainwash_ is now known as brainwash [09:43] 10:40 < jibel> asac, confirmed: apt-get install libc6-amd64 && apt-get remove libc6-amd64 [09:43] 10:40 < jibel> and get a broken system for free [09:43] 10:42 < asac> jibel: thats on i386? [09:43] 10:43 < jibel> asac, amd64 with i386 enabled [09:43] hmm... doko not around :) [09:44] probably infinity [09:44] asac, doko has issues with his provider this morning [09:46] infinity: ^ (in case you are in a eur zone) [09:47] asac: infinity is sick today [09:48] I guess file a bug and assign him [09:51] 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] (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] 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] infinity, it was, until the emulator started pulling it in [09:52] infinity: right. i think for now didrocks just needs a good idea how to recover (e.g. what exactly is now wrong) [09:52] ogra_, that's the android emulator :p [09:52] the emulator deps should just be fixed [09:53] asac: agreed ;) [09:53] infinity: maybe just unpack libc6:amd64 ? [09:53] didrocks: have you /seen/ me try to use hangouts? [09:53] it cant even use any amd64 stuff ... [09:53] didrocks: oh, so you did that to sneak off vUDS hosting! [09:53] :P [09:53] asac: What's wrong is that /lib64/ld-linux-x86-64.so.2 is gone. [09:53] lol [09:53] seb128: clearly ;) [09:53] Laney, man, you and hangouts don't get along for some reason ;-) [09:53] asac: So no amd64 binaries will run. [09:53] yeah [09:54] asac: Recreating the symlink from a rescue CD would do the trick. [09:54] didrocks: ^ [09:54] yeah, no /lib64/ld-2.17.so binary [09:54] infinity, whats wrong is that a package that can only make use of libc6-i386 pulls in libc6-amd64 [09:54] infinity: the symlink is there, just not /lib64/ld-2.17.so [09:54] didrocks: /lib/x86_64-linux-gnu/ld-2.17.so [09:54] didrocks: The symlink should point to that. [09:54] i assume thats in libc6:amd64? so ifyou have that and can unpack it should be ther? [09:54] 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] which points to /lib/x86_64-linux-gnu/ld-2.17.so [09:55] right? [09:55] didrocks: No, just directly aim the symlink at /lib/x86_64-linux-gnu/ld-2.17.so [09:55] ok, trying that in my busybox [09:55] didrocks: /lib64/ld-2.17.so is only in libc6-amd64 [09:55] making sense [09:55] ogra_: That makes no sense. Why is an i386 package pulling in libc6-amd64? [09:56] infinity: android :) [09:56] infinity, thats what i'm saying [09:56] of course, I need to be root [09:56] (Not saying there isn't a massive glibc bug here, but installing libc6-amd64:i386 on amd64 is never a desired result) [09:56] and can't in this / busybox [09:56] so needing to reboot in initrd busybox [09:56] infinity, its the android-emulator package apparently [09:56] http://paste.ubuntu.com/6447333/ [09:56] thats the stuff in android-emulator [09:57] asac: That doesn't explain why it's forcing this weird set of packages to be installed. What are its deps? [09:57] infinity: it has emulator64 binaries in there [09:57] Oh, it explicitly depends on libc6-amd64 ... FUN. [09:57] 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] guess not :) [09:58] ... requires the i386 libs installed already [09:58] 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] Oh, wait. Can't do that. [09:58] Grr. [09:59] Of course, it could just be an amd64 package, period, which would solve the issue. [09:59] Just make it not available on i386. [09:59] heh, why so much hate for i386 users [09:59] 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] pull-lp-source: Downloading android_20131120-0225.orig.tar.xz from archive.ubuntu.com (191.659 MiB) [10:01] Gah. [10:02] dont cry ... that used to be 500M in the past [10:02] 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] Quite entertaining if we've been telling people to install this. [10:03] well ... https://wiki.ubuntu.com/Touch/Emulator [10:04] 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] we only offer it in trusty [10:05] 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] nah. that wouldnt work [10:05] I assume ricard tried to avoid carryuing a big delta there for the time being [10:06] 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] Aaand, it's an hour-long build. This'll be fun. [10:07] Oh well, can't sleep anyway with this cough. [10:09] Oh, derp. This means I'd have to build it twice, though. [10:09] Once per arch. [10:10] Oh, wait. You *can* depend on foo:arch. crossbuild-essential does it. === freeflying is now known as freeflying_away [10:16] didrocks1: managed to get past the point of no command? [10:16] * asac assumes that no news is good news for now [10:16] asac: well, I need to create an usb stick [10:16] Doing a test build of this blind change: http://paste.ubuntu.com/6447414/ [10:17] nice one :) [10:17] bahaha, I like that hack [10:19] asac: that will teach me to not always have a root terminal opened… [10:19] (to start busybox as root) [10:19] 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] 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] asac: seb128: maybe one of you can annotate the wiki with those infos (to not install the emulator on amd64 for now)? ^ [10:20] 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] especially if people wants to clean up their machine then :p [10:22] 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] 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] 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] infinity: libdrm is weird, most of the driver stuff is just a c wrapper for the kernel interface [10:25] https://launchpad.net/~ubuntu-x-swat/+archive/s-lts-backport [10:25] seb128, "don't uninstall libc6-amd64"? or "don't install libc6-amd64"? [10:25] Saviq: Yes. [10:25] Saviq: Don't install it, but if you have, uninstalling it is also dangerous. [10:25] Saviq, don't uninstall it if you have it installed [10:25] I think I created a bug for the pointer barriers specifically, but I didn't make one for pixman and libdrm yet. [10:25] seb128, so I can still try the emulator on amd64, just never uninstall it? ;D [10:26] ppa with all components at https://launchpad.net/~ubuntu-x-swat/+archive/s-lts-backport [10:26] Saviq, basically, or better wait for infinity to fix those stuff ;-) [10:26] 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] infinity: or finally implement cross-arch depends. :P [10:27] 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] mlankhorst: cross-arch deps work. [10:27] ok [10:28] I think I will make the metabug the bug for pixman/libdrm backporting too [10:28] mlankhorst: That doesn't solve this particular issue of people installing libc6-amd64:i386 on amd64. [10:28] Which explodes hilariously. [10:28] why have that? o.O [10:28] Maybe we just need a Multi-Arch: dont-even header. [10:29] Package: libc6-amd64 [10:29] I thought that was what the Architecture: field was for, just build it on amd64 only. :P [10:29] Multi-Arch: hahahahano [10:29] mlankhorst: Erm it's only built on i386. [10:29] oh [10:29] mlankhorst: But then people install an i386 package that depends on it. [10:29] 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] didrocks1: Just use dd. usb-creator is a steaming heap of needs a lot of love. [10:30] (I think there may even be a UDS session about that?) [10:30] infinity, was [10:30] infinity: yeah, I can testify this right now :) [10:30] Or was. :P [10:30] smb: How did that go? [10:30] infinity, I think we use something different [10:30] oh found the pointer barriers bug https://bugs.launchpad.net/ubuntu/+source/x11proto-input/+bug/1242633 [10:30] Ubuntu bug 1242633 in x11proto-input (Ubuntu) "unity pointer barriers sru bug" [High,In progress] [10:30] dd wrapped in a GTK dialog? [10:30] I'll open a metabug [10:31] 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] 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] infinity: right, was mostly kidding [10:32] 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] 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] I actually successfully used usb-creator in saucy still, it's sad that it broke down so quickly [10:32] pitti: It's been broken for several releases, success rates seem to vary from person to person and moon phase. [10:33] 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] LA LA LA, CAN'T SEE YOU, HANDWAVE, GOING FOR A DRINK. [10:34] Sadly coffee has not the desired effect... and at least its not ktb#1 time for me [10:35] 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] infinity, Yeah well, highly depends on your current location which often is hard to guess [10:36] smb: Calgary. I think. It's a bit hazy. [10:38] infinity, That might be true now but was not last(?) week. Which could probably be part of the issue, too [10:39] phew [10:39] thanks infinity, asac (et jibel for testing in a vm) [10:39] didrocks: All gooder? [10:39] yeah ;) [10:39] I really need to come up with a clever fix for that. [10:39] the longest was to download/create this usb stick… [10:40] 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] I'll build an initramfs dropping me in a busybox for next time :p [10:40] That's now fixed, but it would break on upgrades FROM precise... [10:40] So. Whee. [10:40] infinity: oh? interesting [10:41] Only mildly interesting. Mostly just annoying. [10:41] (but, can be epic between the version without the fixed dpkg and then) [10:41] 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] And I think I almost mapped out a clever fix in my head about an hour before you broke your computer. [10:42] But that could just be the drugs talking. [10:42] I'll need to commit it to code when I'm more aware of my surroundings and see if I'm drunk. [10:43] 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] infinity: https://bugs.launchpad.net/ubuntu/precise/+source/libdrm/+bug/1253041 [10:44] Ubuntu bug 1253041 in libdrm (Ubuntu Precise) "lts-saucy enablement in precise" [High,In progress] [10:45] didrocks: I might pull the emulator binaries from the archive for now. [10:45] * infinity does that. [10:45] Removing packages from trusty: [10:45] android-emulator 20131120-0225-0ubuntu1 in trusty i386 [10:45] Comment: High chance of breaking amd64 systems [10:45] Remove [y|N]? y [10:46] * infinity waves bubye. [10:46] If my test build goes okay, I'll upload that. [10:46] thx. let us know [10:47] 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] What fun that will be. [10:50] infinity: TBH, I won't test you hack today :p [10:50] 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] your* [10:51] right, I'm going to summarize what to do in case someone is broken? [10:51] seb128: The libc fix will take some more thinking. [10:51] didrocks, is that a question? yes please follow up on the list ;-) [10:51] seb128: And people installing the emulator might be removing it too. Which already puts them in this situation. [10:52] (Granted, very few people also do autoremove religiously) [10:54] isnt update-manager doing autoremove? [10:55] Oh, is it? Fun. [10:55] asac, not in normal update mode at least, maybe in dist-upgrader mode [10:55] not sure... asking :) [10:55] I didn't *think* it did. [10:56] (i have to admit that i got stuck in old apt-get habits) [10:56] I did autoremove religiously, not sure if one of our tool is doing that :) [10:56] seb128: right. i think dist upgrading does autoremove [10:56] not normal upgrades [10:56] dont think thats better though ... just makes the support bomb more intense :) [10:57] Nah, buys me time until April to fix it! [10:57] otoh, we can add arbitrary hackery to mitigate such issues in update-manager... [10:57] (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] 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] pitti: they include the same changes that you approved in the 331 series [11:06] tseliot: ah, the new libraries, yes; looking [11:06] thanks [11:21] pitti: thanks a lot! === _salem is now known as salem_ [11:31] hi guys, I have a recipe (https://code.launchpad.net/~ahasenack/+recipe/juju-deployer-daily) that started failing to build on trusty, [11:31] dpkg-source -i -I -b recipe-{debupstream}+bzr{revno}-0~{revno:packaging} [11:31] dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision [11:31] but my packaging branch has source format "3.0 (quilt)" [11:32] is this an artifact of how recipes are built in launchpad? [11:32] the same package builds on saucy, for example [11:32] maybe a flag was switched in trusty to make that a fatal error? [11:36] * Catch mismatches between version strings and format versions in [11:36] dpkg-source. Ensure that a 3.0 (quilt) package has a non-native version [11:36] and that a 3.0 (native) package has a native version. Closes: #700177 [11:36] ahasenack: New dpkg enforces this, yes. [11:36] ok, so it looks like launchpad recipe builds will break if your package is 3.0 (quilt)? [11:37] http://bazaar.launchpad.net/~ahasenack/juju-deployer/juju-deployer-packaging/view/head:/debian/source/format is what my recipe uses [11:37] 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] https://launchpadlibrarian.net/156978348/buildlog.txt.gz buildlog [11:38] StevenK: what's "pristine-tar information"? [11:39] ahasenack: pristine-tar allows you to regenerate any tarball you've made from the repository information, 'man pristine-tar' [11:39] StevenK: but there is no tarball on my side, it's a launchpad recipe, it builds the package from branches [11:39] StevenK: Oh, does pristine-tar actually allow recipes to DTRT here? Nice. [11:40] infinity: Yes [11:40] ahasenack: Yes, but pristin-tar is the glue that allows you to recreate the orig.tar.gz out of your branch. [11:40] infinity: Do you want to help ahasenack since it's like 2240 [11:40] 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] StevenK: Not really, it's 0440 here, and I'm sick. :P [11:40] oh boy :) [11:40] Haha [11:40] looks like you both need to be asleep [11:42] 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] 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] ahasenack: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177 [11:43] ahasenack: otherwise, you need original tarball, which you say you don't have. [11:43] Debian bug 700177 in dpkg-dev "dpkg-dev: please reject native/non-native version when building native/non-native source packages" [Wishlist,Fixed] [11:43] infinity: ah, debian [11:43] xnox: He can recreate an orig tarball with pristine-tar [11:43] xnox: it's a recipe build, I would think that LP would take care of it (generate the tarball) [11:43] do you guys use launchpad recipes? Maybe I'm barking at the wrong tree [11:44] StevenK: he wants to daily-build master crap no matter what it is, not generate orig tarball for each commit ;-) [11:44] ahasenack: so in {debupstream}+bzr{revno}-0~{revno:packaging}, remove the "-" =) [11:45] xnox: yeah, was going to paste [11:45] {debupstream}+bzr{revno}~{revno:packaging} maybe [11:45] or s/~/+/ [11:45] ahasenack: then your recipe will be native, no original tarball needed, and it will just build. [11:45] will have to think about it [11:45] ahasenack: that one will work too. [11:45] 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] I win. [11:46] ahasenack: i think "+" will be better. [11:46] yep [11:46] xnox: thanks [11:46] infinity: enlighten me about your winnings =) [11:47] and lp will still add ~ubuntu at the end [11:47] yes [11:47] ok, let's kick it [11:47] thanks again [11:48] xnox: Making your emulator stop pulling in libc6-amd64:i386 [11:49] infinity: patches welcome. [11:49] infinity: what should I do? =) [11:49] xnox: You can pull the patch from the archive shortly. :P [11:49] infinity: ah, even better. thanks for that. [11:50] Man, this source takes a while to re-pack on a rotary disk. [11:50] =) [11:51] xnox: http://paste.ubuntu.com/6447754/ FWIW. [11:52] xnox: With bonus guilt-induced tech-debt swap. [11:52] Also, I can't spell dirty. [11:52] * infinity doesn't upload. [11:52] 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] arun: Yes. [11:53] arun: yes, "*buntu" is protected. [11:54] infinity, your patch drops xz compression, doesnt it ? [11:54] arun: https://forms.canonical.com/trademark/ [11:54] Guys, where can we ask for it ? [11:54] ogra_: xz is default. see changelog entry above. [11:54] ogra_: Reading changelogs is hard? [11:54] bah, i only looked at the bottom :P [11:55] arun: see link infinity pasted. [11:55] xnox: Uploaded. [11:55] * infinity is going to see if he can nap for a few minutes before coughing himself awake again. [11:56] 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] and by the way , what is loCo ?/ [11:57] 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. === freeflying_away is now known as freeflying [11:57] 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] arun: LoCo = Local Community, i.e. local community groups representing ubuntu in their region. [11:58] xnox: oh [11:58] 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] https://wiki.ubuntu.com/LoCoTeams [11:58] Guys , does Canonical feeds Ubuntu devs ??? [11:59] arun, we have to feed ourselves [11:59] 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] arun: i'm sure there are plenty of people who can answer these generic questions about Ubuntu Project. [12:00] brendand: oh ok [12:00] xnox: ok thanks a lot ; I think I went off topic [12:02] Guys, is Unity based on Gnome 3 ? [12:18] hmz [12:18] MismatchError: True != False [12:18] but that statement is true :o === chuck__ is now known as zul === MacSlow is now known as MacSlow|lunch === dholbach_ is now known as dholbach [13:02] * jpds wonders why we have a super-old util-linux on Ubuntu. [13:04] infinity, lamont: Oh, hi. :) [13:06] Hi, I see bug 1253003 in the sponsoring queue. Any hint why that has not been auto-synced yet? [13:06] bug 1253003 in Ubuntu "Sync wxwidgets3.0 3.0.0-1 (universe) from Debian sid (main)" [Undecided,New] https://launchpad.net/bugs/1253003 [13:12] gilir: Hi, may I ask you to look at https://code.launchpad.net/~m-alaa8/ubuntu/saucy/pcmanfm/fix-for-993996/+merge/195625 please? === steveire_ is now known as steveire === MacSlow|lunch is now known as MacSlow [13:49] $ LANG= bzr branch ubuntu:systemd-shim [13:49] bzr: ERROR: Revision {package-import@ubuntu.com-20130502111419-gg4b0m966tgp1p72} ist nicht in »Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))« vorhanden. [13:49] err, what does that want to tell me? [13:49] any known workaround? [13:50] err, neither LANG, LC_ALL, LANGUAGE help -- says something like "... revision ... isn't present in Graph.." [13:52] pitti, it's telling you "stop using udd"? [13:52] lol [13:52] dunno about the specific error though :/ [13:52] 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] omg, a lesser spotted wednesday troll [13:52] ups, did I troll again? [13:52] * seb128 needs to stop that [13:53] yeah, not friday yet [13:53] haha [13:53] one of the few packages which don't have patches, and thus would be manageable with UDD>. [13:53] fix my firefox tooltip instead :P [13:58] [New] wxwidgets3.0_3.0.0-1 [13:58] No previous publications in Ubuntu [13:58] OK (Y/n)? y [13:58] * Trying to add wxwidgets3.0 ... [13:58] 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] mitya57: ^- that's why [13:59] mitya57: somebody needs to work out if those two changes need to be forward-ported to 3.0 [13:59] cjohnston: oh thanks, will reject the bug for now then [14:00] Bad xchat. [14:02] I should tee the output of auto-sync to a file on people or something [14:36] roaksoax, hallyn_: hey, did you guys upstream that avahi patch you uploaded to trusty? [14:46] slangasek, around ? [14:46] smoser: vUDS [14:46] would you think that bug 1235231 is fixable ? [14:46] bug 1235231 in plymouth (Ubuntu) "plymouth loses output to /dev/console (such as ci-info: messages)" [High,Confirmed] https://launchpad.net/bugs/1235231 [14:51] 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] seb128: oh, actually no we can't submit it to debian really, bc it relies on upstart [14:52] 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] 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] agreed [14:53] thanks [14:55] slangasek, i just added a comment there. [14:55] by "fixable" i meant "stop being broken". [14:55] plymouth is explicitly "supposed" to replay content it captures. its a clear bug that it does not do that. [14:55] seb128: sorry, it didn't occur to me yesterday that it depended on upstart. [14:55] (as are most dataloss issues :) [14:56] hallyn_, no problem, thanks for the reply to my questions! [14:57] 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] 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] smoser: replied [15:06] slangasek, yeah, but you didn't reply the way i wanted. [15:06] 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] there aren't going to be more upstart jobs [15:06] and half those overrides are niceties [15:17] ooooh! http://alioth.debian.org/ just came back [15:18] \o/ [15:19] yay [15:19] Yeah, it's on its way, I think they're still putting some pieces back together [15:20] ssh vasks works, at least, although the filesystem doesn't seem (fully) restored [15:20] Er [15:20] vasks is going away [15:20] It's being replaced by a new host [15:20] seb128: i didn't yet. [15:21] yeah, host key changed (understandably) [15:21] Laney: moszumanska now [15:21] I suggest waiting for an announcement from the alioth admins before pushing stuff [15:21] ah [15:21] I've been checking d-i-a [15:21] no news of that there [15:22] might still take a bit until it gets official, but I'm happy to see it alive again after two weeks [15:34] 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] oh [15:35] it *is* live-rootfs [15:35] livecd-rootfs [15:36] but ignore livecd.sh, use the live-build hooks there [15:36] https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html [15:36] *nod* === Sweetsha1k is now known as Sweetshark [16:04] mhall119, what circumstances make the 'Join hangout' link appear ? [16:04] I beleive the person who runs the session needs to provide summit with the link [16:04] 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] ah. its there now. [16:05] it must only appear after start of session (it should have a grace "join" period) [16:05] 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] also 4) you're not getting a stale page from the caching server sitting in front of summit.u.c [16:06] mhall119, well can i suggest that '1' be tweaked to include 10 or 15 minutes prior ? === brainwash_ is now known as brainwash [16:07] rbasak, smoser: do you want anyone from the server team to come to the Secure Boot session? [16:07] is that now ? [16:07] :-( [16:07] smoser: you can if you file a bug for it [16:07] lp:summit [16:07] tjaalton, tseliot, mlankhorst, coming to the xorg for t vUDS session? https://plus.google.com/hangouts/_/7ecpjg4e7ibk4vghv8fkul3tt8?authuser=0 [16:07] k [16:07]