[00:00] <slangasek> james_w: heh
[00:02] <james_w> slangasek, so, I think it's that you deleted .bzr-builddeb/default.conf and left .bzr-builddeb, and similar for if-up.d
[00:02] <slangasek> james_w: ah, hmm
[00:02] <james_w> and the source package didn't conatin the dirs either
[00:03] <slangasek> because the package won't contain empty dirs, I guess
[00:03] <james_w> yeah
[00:03] <james_w> I think this can go in the "immaterial differences" pile
[00:06] <infinity> slangasek: Sure, and so do you.
[00:07] <james_w> bug 810218
[00:07] <slangasek> infinity: I mean the kind of mangling that lets you recover from a broken chroot; I obviously have access to do the frontend mangling ;)
[00:08] <infinity> slangasek: Well, do you mean "kicking buildd hardware violently" (if so, then no), or "abusing chroots in unpleasant ways"?
[00:08] <infinity> slangasek: If the latter, we can both do it, even if you weren't entirely aware you could. ;)
[00:08] <slangasek> infinity: abusing chroots to recover from sysvinit-utils being broken in some fashion I have yet to discern
[00:08] <slangasek> infinity: heh
[00:08] <infinity> Then yes, we both can do that. ;)
[00:09] <infinity> But I'm happy to drive for you once you figure out what you want done.
[00:09] <infinity> (After I eat some food)
[00:11] <slangasek> infinity: lamont is on it at the moment, but he has a hard cutoff in 2h; maybe you can grab him after food for him to bring you in the loop?
[00:13] <slangasek> infinity, lamont: sysvinit 2.88dsf-13.10ubuntu3 is the package we need to get build to unbreak the chroots; and sysvinit-utils needs to be put on hold in each of them to get it built
[00:15] <directhex> will builds which failed due to chroot problems automatically be rescheduled?
[00:16] <ScottK> All except yours, since you asked.
[00:17] <lamont> infinity: you wanna come hang in -release for a bit?
[02:05] <chowder> hi, I know this isn't the place for support but I've been asking the same question on various Ubuntu related channels and no one seems to have a straight answer. Is it at all possible to have Ubuntu 11.04 running as a dom0 vm under xen?
[02:06] <persia> It ought be, if not, please file a bug.  Precisely how is not something likely to be answered here.  If you aren't getting realtime support, try askubuntu.com
[02:06] <infinity> chowder: Yes, but not with Ubuntu kernels.
[02:06] <chowder> infinity, so I'd have to compile my own kernel? wouldn't that cause a lot of issues or make Ubuntu behave in weird ways?
[02:07] <infinity> chowder: Not so much.  Get some sources with the Xen patches applied, apply the Ubuntu config to it, flip on Xen bits, build, profit.
[02:07] <infinity> chowder: The hypervisor and tools are packaged in the archive, just not a usable dom0 kernel.
[02:08] <infinity> chowder: Thankfully, this should not be the case from oneiric and onward, now that Xen is mainline.
[02:08]  * infinity crosses his fingers.
[02:09] <chowder> I wish there was a how-to on this. I've messed with the kernel config before and I just remember it being this monstrous collection of options. Enough options to make your head spin
[02:09] <infinity> chowder: Simplest way is to copy your running config (/boot/config-`uname -r`) to your source tree as ".config", and then run "make menuconfig".
[02:10] <infinity> chowder: Don't touch anything except to find the Xen stuff and enable it.
[02:10] <infinity> chowder: Then either "make; make install" if you're old skool and hate package managers, or read up on make-kpkg to roll it into a reasonably usable deb.
[02:11] <chowder> infinity, that sounds simple enough. I'm on a fresh install and I was dreading having to install another linux distro
[02:11] <infinity> I really should roll dom0 kernels in a PPA or something.
[02:12] <infinity> But I've just been doing dom0 on hardy, and waiting on the glory of Linux 3.0 in oneiric.
[02:12] <chowder> the thing is that I need windows for my uni but virtualbox is about as fast as taffy. So here I am.
[02:12] <infinity> (And that's another option, if you don't mind using "old" software on your dom0, hardy is still a supported LTS, with perfectly workable dom0 kernels in the archive)
[02:13] <infinity> Isn't virtualbox just a wrapper around kvm?
[02:13] <persia> No, it's a separate virtualisation implementation
[02:13] <infinity> Or maybe I'm thinking of something else.  I dunno.
[02:14] <infinity> chowder: But that's option 3.  KVM is less hip and cool than Xen with people like me, but it's fast and works on any modern machine.
[02:14] <chowder> infinity, would I be able to run windows as efficiently on KVM as xen?
[02:15] <infinity> Should do.
[02:16] <infinity> And there should be a ton of HOWTOs and guides and such dealing with KVM on the Ubuntu wiki and docs site.
[02:16] <infinity> Since it's what all the young'uns are using.
[02:16] <infinity> And no kernel futzing.
[02:18] <chowder> idk, I'm doing all of this for school so I'm basically building a production environment. I don't wanna use KVM and then regret it for w/e reason
[02:20] <infinity> Plenty of people use KVM in production.
[02:20] <infinity> I'm just not one of them. :P
[02:20] <persia> Every virtualisation environment is annoying for one reason or another.  Today, kvm probably has the best documentation available.
[02:21] <infinity> persia: Xen's not annoying to anyone who grew up on IBM kit.
[02:26] <chowder> I'm looking into kvm now. its like an epic battle between KVM and Xen. THERE CAN BE ONLY ONE!
[02:29] <persia> infinity, Not annoying in *any* way?  Not even a little?
[02:43] <infinity> persia: Well, it fails to annoy me.  And everything annoys me.
[02:45] <persia> infinity, Given comparative search results for "virtualbox annoying", "xen annoying", and "kvm annoying", I think you're special.
[02:45] <infinity> Hahaha.
[02:46] <nigelb> heh
[02:46] <infinity> persia: They're all close enough to discount variance as statistically insignificant. :P
[02:47] <persia> Right, so if you find one more annoying than another, then you're not following statistical norms, hence "special"
[02:47] <infinity> persia: Besides, I also had the "if you grew up with IBM VM" qualifier, which is a pretty small subset of people.
[02:47] <infinity> persia: Most of whom likely don't blog.
[02:48] <lifeless> internet, whats that?
[02:48] <infinity> Ed Zachary.
[02:48] <persia> That could be interpreted to indicate that "Xen annoying" is underrepresented, but I choose not to so interpret it, as I don't believe you'd undermine your argument that way.
[02:49] <infinity> persia: Other way around; I'd say that old farts who don't blog are likely to find virtualbox and kvm annoying, but not whine about it publically.
[02:49] <persia> Oh my.  With "IBM VM $virtualisation_tool Annoying", KVM loses by a factor of two, compared with Xen and virtualbox.
[02:50] <infinity> Besides, we all know the Internet is just for IRC: http://www.youtube.com/watch?v=O2rGTXHvPCQ
[02:50] <nigelb> infinity: Oh god, is that the num3rs one?
[02:50] <nigelb> hah, yes.
[02:51] <infinity> Yup. :)
[02:52] <nigelb> The 1337 bits in that annoys me more than the "primite chat program" bit :/
[02:52] <infinity> Luckily, I speak l33t!
[02:53] <nigelb> *primitive
[03:07] <bryceh> whew, they got a screenshot
[03:13] <infinity> bryceh: It was touch and go there for a bit.
[04:18] <pitti> Goodm orning
[04:20] <RAOF> Good morning, pitti
[04:21] <bryceh> pitti, orning to you too
[04:21] <pitti> bryceh: 'ow are you?
[04:21] <pitti> hey RAOF
[04:21] <bryceh> pitti, ood!
[04:21] <pitti> meh, what happened to the Windows key?
[04:22] <pitti> ah, nevermind, keyboard fail
[04:22] <RAOF> Heh.
[04:24] <pitti> bdmurray: will do, thanks!
[04:43] <pitti> slangasek: impressive sysvinit merge changelog!
[04:55] <slangasek> pitti: s/impressive/eye-bleeding/ :)
[04:56] <pitti> ah, just recovered from a reboot
[04:56] <pitti> slangasek: it seems to break ecryptfs once again :/
[04:56] <slangasek> oh, really?
[04:56] <slangasek> how does it do that?
[04:56] <pitti> slangasek: it stumbles upon -EACCESS on /dev/shm/
[04:56] <slangasek> hmmm
[04:56] <pitti> it seems that /dev/shm is now root:root 755
[04:57] <pitti> moving it to 777 temporarily fixes things again
[04:57] <pitti> was it 777 before?
[04:57]  * pitti boots an older live CD to check
[04:57] <slangasek> pitti: eh, it was meant to be a symlink to /run/shm
[04:58] <pitti> hm, /run/shm/ looks fine indeed
[04:58] <pitti> the other thing that I found is
[04:58] <pitti> none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
[04:58] <pitti> none on /run/shm type tmpfs (rw,nosuid,nodev)
[04:58] <pitti> tmpfs-on-tmpfs, but that's merely a curiosity right now
[04:58] <pitti> slangasek: do you know what is responsible for setting up /dev/shm? udev, initramfs, mountall?
[04:58] <slangasek> deliberate
[04:59] <pitti> ah, /run/shm needs to be "exec"?
[04:59] <slangasek> does it?
[04:59] <slangasek> do you have /dev/shm as a symlink to /run/shm, or is it still a real directory for you?
[04:59] <pitti> I don't know, but different mount options seems like the reason for doing this?
[04:59] <slangasek> ah
[05:00] <slangasek> no, the reason is the different write perms
[05:00] <pitti> it's a real dir
[05:00] <slangasek> /run/shm is world-writable, as is /run/lock for historical reasons; /run must be root-only to avoid DoSes
[05:00] <slangasek> right, I see what went wrong with /dev/shm
[05:00] <slangasek> it should be in the initscripts umountroot script... I failed to include that when I migrated stuff from mountall startup to initscripts shutdown
[05:02] <pitti> (phone, brb)
[05:04] <pitti> slangasek: well, mere access permissions wouldn't need a mount-on-mount, but different mount options certainly do
[05:04] <pitti> e. g. /run/shm/ needs "dev", while /run/lock certainly should be "nodev" as it's world writable
[05:04] <slangasek> pitti: no, they absolutely do need mount-on-mount because there's no quotas on tmpfs
[05:05] <pitti> anyway, so the mount-on-mount seems to be on purpose then
[05:06] <slangasek> uploaded a fix for the /dev/shm bit
[05:06] <slangasek> (sysvinit ubuntu4)
[05:06] <pitti> merci beaucoup! that was fast
[05:08] <slangasek> pitti: well as soon as you asked me what's responsible for setting it up, I realized my bug ;)
[05:10] <slangasek> hmm, actually, that's an incorrect/incomplete fix... I need to poke mountall
[05:15] <slangasek> pitti: ok, now I'm really puzzled... I just realized /dev/shm is a symlink here and I don't know *how*
[05:15] <slangasek> so I may be piling on irrelevant kludges at this point
[05:15] <pitti> sheer willpower from your side?
[05:16] <slangasek> that seems unlikely, since I largely ignore /dev/shm anyway :)
[05:16]  * pitti snatches the built debs from LP and installs
[05:16] <slangasek> but /dev is not persistent, being a devtmpfs
[05:16] <slangasek> so something is creating the directory for you at boot time
[05:16] <slangasek> and something created a *symlink* for *me* at boot time
[05:16] <slangasek> and I can't find what the 'something' is in either case
[05:18] <pitti> I'll reboot with new sysvinit, and if it still doesn't work, go through my system with a fine comb and see what creates /dev/shm
[05:20] <pitti> ok, so sysvinit ubuntu4 didn't help
[05:20] <slangasek> right
[05:20] <slangasek> it "helps" in the unusual case that /dev is not actually a devtmpfs
[05:21] <slangasek> ... which is unsupported, so
[05:21] <slangasek> pitti: you have mountall 2.29 as well?
[05:21] <pitti> yep
[05:21] <pitti> oneiric up to date
[05:22] <pitti> ok, so the only match of "shm" in /etc/init/ is ecryptfs-utils-*, which only touches files in /dev/shm/
[05:22]  * slangasek nods
[05:22] <pitti> oh, wait
[05:22] <pitti> ./schroot/buildd/fstab:tmpfs/dev/shmtmpfsdefaults00
[05:23] <pitti> no, that's only for within a schroot
[05:24] <slangasek> so, if you had the old mountall installed, that would account for /dev/shm being mounted with the traditional perms (rwxrwxrwxt)
[05:24] <slangasek> with the new packages, I can't account for *anything* creating /dev/shm, as either a symlink or a dir
[05:24] <pitti> might it be possible that it's just part of a standard devtmpfs?
[05:24] <slangasek> that seems unlikely to me
[05:24] <pitti> sudo mount -t devtmpfs none /mnt
[05:25] <pitti> $ ls -ld /mnt/shm/
[05:25] <pitti> drwxrwxrwt 2 root root 120 2011-07-14 07:20 /mnt/shm/
[05:25] <pitti> so it is part of devtmpfs, but with correct permissions
[05:25] <slangasek> hmm
[05:25] <broder> ugh, that sounds like a race condition waiting to happen...
[05:25] <pitti> devtmpfs tries to be "clever" enough to provide everything you need even in an init=/bin/bash session
[05:25] <slangasek> "with correct permissions" - nah, permissions on the symlink don't matter
[05:26] <pitti> slangasek: no, it's a dir in standard devtmpfs
[05:26] <pitti> so we now need to look for what changes the permissions
[05:26] <slangasek> pitti: oh, actually, I think mounting multiple copies of devtmpfs just gives you a mirror of the same fs :)
[05:26] <pitti> ah, perhaps
[05:26] <slangasek> pitti: because when I mounted it *here*, I got shm -> /run/shm again :)
[05:26] <pitti> slangasek: ok, rebooting again into init=/bin/bash and checking it there
[05:27] <slangasek> broder: what race condition?
[05:27] <broder> slangasek: if there's a window between when /dev/shm exists and when it gets changed to a symlink
[05:29] <slangasek> broder: yeah, there's not meant to be one because it's not meant to exist except as a symlink
[05:36] <pitti> ok, no /dev/shm/ with just init=/bin/bash
[05:37] <pitti> it's not created in the initramfs either
[05:37] <broder> i wonder if, like, libc somehow creates it or something equally hideous
[05:38] <pitti> doesn't seem to be udev, just grepped its source
[05:41] <pitti> slangasek: which bit would make it a symlink to /run/shm?
[05:41] <slangasek> pitti: that's just it, I don't see one anywhere
[05:42] <slangasek> I don't see what creates it as a directory either
[05:43] <pitti> I'm done checking /etc/ and /lib
[05:43] <pitti> and udev sources
[05:43]  * persia thought /dev/shm was a virtual directory provided by the kernel
[05:44] <slangasek> well, http://en.wikipedia.org/wiki/Shared_memory tells me the kernel provides it by default on Ubunut
[05:44] <slangasek> Ubuntu
[05:44] <slangasek> so if wikipedia says so... :P
[05:44] <pitti> hm, maybe it's created by a module, which isn't loaded yet in init=/bin/bash?
[05:45] <slangasek> persia: except that mountall was previously set up to mount /dev/shm as a tmpfs on boot
[05:45] <persia> slangasek, Do you happen to know *when* that was introduced?  /dev/shm used to be a tmpfs, but I don't think it has been since at least maverick.
[05:46] <persia> Hrm, but my memory doesn't match the output of `mount` on a natty system :(
[05:46] <slangasek> persia: when what was introduced?  the mountall handling?
[05:46] <pitti> persia: /dev/ itself is a devtmpfs, so it doesn't need to be a mount on top of it
[05:46] <pitti> I upgrade my oneiric VM, to avoid having to reboot so often
[05:46] <pitti> and snapshots FTW
[05:47] <pitti> persia: you are right indeed
[05:47] <pitti> none on /dev/shm type tmpfs (rw,nosuid,nodev) in alpha-2, so it was indeed mount-on-mount
[05:47] <persia> That's the mount from mountall
[05:47] <pitti> right
[05:48] <slangasek> frankly, I can't work out from this why we have /dev/shm at all
[05:48] <slangasek> the justification I've always heard was "filesystem exposure of SHM for IPC"
[05:48] <slangasek> but I see nothing that ties this to the POSIX SHM APIs
[05:48] <RAOF> Doesn't libc use it to provide the SHM API?
[05:49] <broder> glibc's implementation requires /dev/shm to be a tmpfs for shm_open et al to work
[05:49] <slangasek> ah
[05:49] <broder> also for the semaphore API to work, i think?
[05:49] <broder> but it turns out that shm_open(foo) is actually just open("/dev/shm" foo)
[05:49] <slangasek> right, I wasn't thinking that the mapping would happen in libc; I thought there were syscalls for shm/sem
[05:49] <persia> "everything is a file" :)
[05:50] <lifeless> even things that really shouldn't be
[05:51] <persia> So, I could be mistaken, but I believe that mm/shmem.c triggers the creation of /dev/shm when devtmpfs is initialised (assuming that SHM support is configured in the kernel)
[05:52] <slangasek> hmm
[05:52] <slangasek> why the blazes did Debian move this to /run at all then
[05:53] <broder> persia: if that's the case then why did mountall need to mount /dev/shm?
[05:53] <persia> Right, and ./drivers/base/devtmpfs has dev_mkdir("shm", 01755); in __init int devtmpfs_init(void)
[05:54] <persia> broder, I think that predated devtmpfs, but that's just a guess.
[05:54] <persia> broder, And it has been a bug since we started using devtmpfs, but nobody cared in practice, because it doesn't really matter *why* /dev/shm is a tmpfs
[05:55] <broder> huh, i guess that's an ubuntu special? i have lxr pulled up and was skimming upstream and don't see that mkdir
[05:56] <pitti> I upgraded my clean alpha-2 instlal oneiric VM, and I also get /dev/shm 755 as a dir
[05:56] <pitti> not 1755
[05:56] <persia> broder, It's from <1241097822.2516.3.camel@poy>, from linux-kernel@vger
[05:56] <pitti> so it seems our previous mountall just papered over the broken devtmpfs permissions then?
[05:56] <broder> persia: uh, that's not in our kernel
[05:57] <slangasek> persia: but it does matter that the perms aren't 755...
[05:57] <broder> http://paste.ubuntu.com/643796/ is Ubuntu-2.6.38-9.43:drivers/base/devtmpfs.c
[05:57] <broder> (easiest tag to grab)
[05:57] <persia> slangasek, Found it: in Debian kernels, # CONFIG_DEVTMPFS_MOUNT is not set and in Ubuntu kernels CONFIG_DEVTMPFS_MOUNT=y (at least on a randomly selected pair of my systems)
[05:58] <pitti> yes, and that's fine IMHO
[05:59] <slangasek> persia: I also can't find this dev_mkdir() call in the current kernel
[05:59] <persia> pitti, Should be fine, but it might explain why things are different in Ubuntu/Debian
[06:00]  * persia grabs current kernel sources, rather than trusting memory and mail logs
[06:00] <pitti> so you reckon devtmpfs creates /dev/shm the first time a program tries to access devtmpfs?
[06:00] <slangasek> I don't see how it would
[06:00] <broder> CONFIG_DEVTMPFS_MOUNT affects automatically mounting of /dev itself, not /dev/shm
[06:00] <pitti> still doesn't explain why slangasek gets a symlink for it
[06:02] <slangasek> fwiw, the timestamp on the symlink exactly matches that of the other nodes created at boot
[06:02] <slangasek> created 3 seconds before /dev/sda, actually
[06:03] <pitti> oh, that's an interesting point
[06:03] <pitti> in my VM, all nodes are from 2011-07-14 07:55, i. e. when I booted
[06:03] <pitti> but /dev/shm is from 2011-06-28 19:12
[06:04] <pitti> which might be when I created that VM
[06:04] <broder> devtmpfs doesn't bleed through what's under it, does it?
[06:04] <pitti> perhaps it does something crazy like that?
[06:05] <pitti> either that, or an init script "restores" /dev/shm from somewhere else
[06:05] <slangasek> well, I checked for that with mount -obind / /mnt
[06:06] <slangasek> /mnt/dev/ was completely empty here
[06:06] <pitti> mine isn't, I have a fairly well populated one
[06:06] <pitti> but there /dev/shm is root:root 0755 (same perms) but 2011-07-05 11:30
[06:06] <pitti> i. e. yet another date, which is in between
[06:07] <slangasek> right, no idea then
[06:07] <broder> wait, what do you guys have in /lib/udev/devices?
[06:07] <pitti> broder: you rock
[06:08] <pitti> /lib/udev/devices/shm 2011-06-28 19:12 0755
[06:08] <pitti> that very timestamp, that permission
[06:08] <broder> the udev package ships /lib/udev/devices/shm
[06:08] <pitti> slangasek: ^ is that a symlink for you by any chance?
[06:09] <slangasek> pitti: nope :/
[06:09] <pitti> broder: I thought I got rid of all these a while ago, apparently I missed some
[06:10] <pitti> udev (093-0ubuntu13) edgy; urgency=low
[06:10] <pitti>   * Make sure that net, pts and shm sub directories exist under
[06:10] <pitti>     /lib/udev/devices in the package.  Ubuntu: #57436.
[06:10] <broder> that still doesn't explain where slangasek's symlink is coming from, of course
[06:11] <pitti> no, but at least explains the other half of the story
[06:11] <persia> slangasek, Have you had a /run/shm/shm directory?
[06:12] <pitti> when I remove /lib/udev/devices, I now don't have a /dev/shm/ at all any more
[06:12] <slangasek> let's chalk my symlink up to somnoclavicism for the moment
[06:12] <pitti> and with devtmpfs /lib/udev/devices should be entirely obsolete
[06:12] <slangasek> pitti: after a reboot, or it disappears immediately?
[06:12] <pitti> slangasek: after reboot
[06:12] <slangasek> persia: no
[06:14] <pitti> slangasek: udevd does that on startup
[06:14] <pitti> (copy /lib/udev/devices/* to /dev/)
[06:14] <jbicha> y'all's shm problems broke my Chromium! ;-)
[06:15] <slangasek> pitti: k
[06:15] <pitti> I'd prefer to fix udev to remove /lib/udev/devices/ entirely; it's time to get rid of this hack
[06:15] <pitti> question is now, what should create /dev/shm -> /run/shm ?
[06:15] <slangasek> pitti: well, /etc/init/mounted-dev.conf probably should
[06:15] <pitti> (or why did we move it in the first place)
[06:16] <slangasek> I was halfway to uploading that when I realized I didn't know what was going on
[06:16] <pitti> oh dear, this thing _also_ copies /lib/udev/devices
[06:16] <broder> looks like /etc/init.d/mountdevsubfs.sh does it in debian-land? so mounted-dev seems like it makes sense
[06:16] <slangasek> oh, hah
[06:16] <pitti> slangasek: as udevd already does that, this bit should go away then
[06:17] <pitti> slangasek: but will that be early enough? i. e. initramfs stuff trying to use /dev/shm ?
[06:17] <slangasek> pitti: tell you what, it's late here, how about if I leave it in your hands to decide what to do with it :)
[06:17] <broder> pitti: it would have to be - nothing would mount /dev/shm in the initramfs previously, right?
[06:17] <pitti> broder: correct
[06:17] <pitti> it only works now because of that /lib/udev/devices/ uglyness, and as the initramfs is all root processes, they don't midn the permissions
[06:18] <pitti> slangasek: ok, will do; sleep well then!
[06:18] <slangasek> thanks :)
[06:18] <slangasek> pitti: eh, where would it get /lib/udev/devices inside the initramfs though?
[06:19] <slangasek> I think it's more likely that nothing in the initramfs has ever cared about shm
[06:19] <pitti> $ zcat /initrd.img | cpio -t|grep udev/devices
[06:19] <pitti> indeed, nothing copies it
[06:19] <pitti> slangasek: so much the better :)
[06:20] <broder> and if anything ever was expecting there to be a /dev/shm that early in the boot, it'd be a poster child for why we need /run in thef irst place
[06:20] <slangasek> pitti: btw, if you get that licked, I have one other bug I've noticed... I think the udev/initramfs-tools changes have broken the use of /dev/.initramfs to transfer pid info from the initramfs to the rootfs for upstart
[06:21] <pitti> ah, that seems to be in the code
[06:22] <persia> Aha.  So the kernel used to, and no longer generates /dev/shm (apparently there was some dispute about whether everyone wanted it that way).  The current kernel devtmpfs stuff only creates 0755 directories for things that define devnode sensibly, for real nodes, meaning that distributors are required to create /dev/pts and /dev/shm manually
[06:22] <pitti> persia: thanks!
[06:22] <persia> (the rest of /lib/udev/devices ought be obsolete with devtmpfs, as those have real nodes)
[06:22] <pitti> ok, so I think I now have everything together to fix this
[06:22] <pitti> - remove /lib/udev/devices/ for good, and clean up on upgrades (udev)
[06:23] <pitti> - remove the copying in /etc/init/mounted-dev.conf (mountall)
[06:23] <pitti> - have mountall upstart script create the symlink to /run/ (mountall)
[06:26] <persia> pitti, And mountall mounts /dev/pts (devpts), and /run/shm (tmpfs)?
[06:27] <broder> mountall upstart script> you mean mounted-dev.conf, right?
[06:27] <pitti> broder: I'm not actually sure, as /dev/ already gets mounted by the kernel
[06:28] <pitti> ideally mounted-dev.conf wouldn't even run, except for a kind of "coldplugging" run
[06:28] <broder> pitti: mountall emits mounted events for fs's that were mounted before it runs
[06:28] <pitti> persia: yes, see /lib/init/fstab
[06:28] <persia> Also compatibility for folks who don't have devtmpfs for some reason.
[06:28] <pitti> broder: it's easy enough to test
[06:28] <pitti> persia: does that even work still?
[06:29] <broder> pitti: look at mark_mounted in src/mountall.c
[06:29] <persia> pitti, That says "/dev/shm": should it say "/run/shm"?
[06:30] <pitti> /lib/init/fstab:none            /run/shm                  tmpfs           nosuid,nodev
[06:30] <persia> pitti, I haven't tested it, but /etc/init/mounted-dev.conf still has compatibility code in it.
[06:30] <pitti> /lib/init/fstab:none            /dev/pts                  devpts          noexec,nosuid,gid=tty,mode=0620   0 0
[06:30] <pitti> persia: yes, I'll keep that minimal bit
[06:30]  * persia updates that chroot
[06:30] <broder> hmm...actually, should the /dev/shm symlink get created on mounted MOUNTPOINT=/run/shm ?
[06:31] <pitti> broder: in theory that'd race with mounting of /dev
[06:31] <pitti> in the case when devtmpfs isn't mounted by the kernel
[06:31] <pitti> Ubuntu kernels do, so it's not a problem there
[06:31] <broder> bah. fine - mounted MOUNTPOINT=/run/shm and mounted MOUNTPOINT=/dev
[06:31] <pitti> but I think it's safer to create the link in mounted-dev
[06:32] <persia> I don't think we care if /run/shm is mounted when the symlink is created.
[06:33] <pitti> right
[06:40] <broder> hmm...i'm not actually convinced that glibc will handle /dev/shm-as-a-symlink correctly. i wonder if anybody's tested this
[06:41] <pitti> I fixed my vm with /dev/shm -> /run/shm, and /run/shm/ has the pulse stuff now
[06:41] <broder> i'm probably just misreading the code
[06:41] <pitti> but for the sake of avoiding the symlink lookup every time, eglibc should probably be changed to use /run/shm/ right away?
[06:45] <broder> based on http://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2BAC8-dev.2BAC8-shm it looks like debian isn't planning to change eglibc yet
[06:45] <broder> "If we do eventually deprecate /dev/shm in favour of /run/shm"
[06:45] <pitti> ah, good
[06:50] <cjwatson> symlink lookups will be lost in the noise, I expect
[06:53] <pitti> cjwatson: good morning
[06:53] <pitti> cjwatson: while I'm at it, would you mind if I change udev-udeb's lib/debian-installer/start-udev script away from mounting a tmpfs on /dev and doing mknod?
[06:53] <pitti> cjwatson: as the kernel mounts a devtmpfs anyway, and in the installer environment we can rely on an Ubuntu kernel, we could in theory drop it altogether
[06:54] <pitti> but I'm happy to do a "mountpoint /dev || mount -t devtmpfs devtmpfs /dev" kind of thing instead
[06:57] <pitti> or if "mountpoint" availability is questionable, just
[06:57] <pitti> [ -e /dev/null ] || mount ...
[06:59] <pitti> cjwatson: http://paste.ubuntu.com/643841/
[07:00] <infinity> pitti: Pretty common when bootstrapping on weird new subarches to not always have an Ubuntu kernel handy, pretty please don't assume the kernel will DTRT based on Ubuntu configs. :)
[07:01] <pitti> infinity: right, see pastebin: it still mounts it manually
[07:05] <tjaalton> cjwatson: re: grub blacklist> is it necessary to run update-grub after adding a new entry, and does it matter which device is listed there? (I'd assume it's checking the graphics chip)
[07:08] <pitti> broder: ... and ecryptfs seems happy with the symlink, too
[07:09] <pitti> (if it weren't, I couldn't talk to you in the first place :) )
[07:19] <cjwatson> pitti: you're guaranteed not to have 'mountpoint' in the installer
[07:20] <cjwatson> pitti: shrug, I guess - seems plausible enough
[07:20] <pitti> http://paste.ubuntu.com/643841/ uses [ -e /dev/null ]
[07:20] <pitti> cjwatson: ok, thanks; I'll upload that, and test tomorrow's alternate
[07:21] <cjwatson> tjaalton: you need to run update-grub-gfxpayload, but not update-grub.  It matches any PCI device with class 3
[07:24] <tjaalton> cjwatson: ok, thanks
[07:25] <pitti> kirkland: if you get reports about ecryptfs breaking today, please point people at udev 172-0ubuntu3 and mountall 2.30
[07:26] <pitti> $HOME, sweet $HOME
[07:27] <dholbach> good morning
[07:27] <pitti> hey dholbach *hug*
[07:31]  * dholbach hugs pitti back
[07:38] <MacSlow> anybody with some Mono/autotools experience here?
[07:39] <MacSlow> I wonder why NotifyOSD's configure can find "Mono 2.0 GAC Mono.Posix.dll" although it's certainly installed
[07:43] <RAOF> MacSlow: Got a pastebin?  It's likely that it should instead be trying to find a 4.0 GAC Mono.Posix.dll.
[07:45] <MacSlow> RAOF, just tired the same with 4.0... didn't fix it
[07:45] <MacSlow> RAOF, what do you want to see pasted... configure.in, error-message, config.log?
[07:45] <RAOF> error message and configure.{in,ac}, I guess.
[07:46] <RAOF> Or I could just grab the source package, I guess - is it in the archive?
[07:48] <MacSlow> RAOF, bzr branch lp:notify-osd
[07:50] <MacSlow> RAOF, make sure to call it with like ./autogen.sh --with-examples=mono
[07:51] <MacSlow> RAOF, I've both (2.0, 4.0) version of libmono-posix-cil installed
[07:51] <RAOF> I suspect you need to install libmono-cil-dev; that's what contains mono.pc.
[07:53] <MacSlow> RAOF, there' no corresponding -dev for libmono-posix2.0/4.0-cil
[07:54] <RAOF> That's correct; it's a mono corelib.
[07:54] <MacSlow> RAOF, I'll try installing all mono-related -dev packages
[07:55] <RAOF> You should *only* need libmono-posix$SOMETHING and libmono-cil-dev.
[07:55] <RAOF> I'm just hunting down the other build-depends that I don't have, like libwnck-3-dev :)
[07:57] <MacSlow> RAOF, libnotify0.4-cil and libnotify-cil-dev you'll need too
[07:57] <RAOF> So, it works for me with libmono-cil-dev and libmono-posix2.0-cil.
[07:58] <MacSlow> RAOF, here too now
[07:58] <MacSlow> RAOF, at least it compiles... I'll to my usual testing then... thanks!
[08:28] <pitti> cjwatson: fixing yelp binary overrides (last CD build failure)
[08:33] <pitti> jbicha: thanks for this!
[09:16] <jml> what ho!
[09:33] <apw> i have just updated oeniric as of this morning and libyelp0 installation breaking colliding with libyelp ?
[09:33] <apw> is this a known issue, or do i need to report same
[09:39] <jbicha> apw: known issue, bug 810258
[09:39] <persia> apw, Yelp was last pushed 3 days ago, and I don't see anything listed in NBS that should still need the old one.
[09:50] <Daviey> apw: Out of interest, have you rebooted following the update?
[09:51] <apw> Daviey, nope, i have just apt-get install -f 'd my way to a completed install
[09:51] <apw> Daviey, should i be scared, as i would now reboot
[09:51] <Daviey> apw: so, i hit the same yelp bug.. but didn't -f install.. power died, and not it's failing to boot.
[09:52] <Daviey> It's not registering as a successfull boot after waiting, as hard powercycle is showing grub menu.
[09:52] <Daviey> (not a kernel issue tho, as prior ones are working)
[09:52] <Daviey> are NOT working rather
[09:52] <jbicha> yelp being broken won't mess up your boot
[09:52] <apw> Daviey, wekk t
[09:53] <apw> Daviey, well the first two things it did after the -f were mountall and libdbus
[09:53] <Daviey> jbicha: well yes.. but the reason i was asking was because i thought apw would be running the same archive snapshot as me.
[09:53] <apw> so i'll reboot and see if the completed install works
[09:53] <apw> its a machine i can live without
[09:54] <Daviey> wish i could say the same :)
[09:54] <jbicha> oh, I've had trouble with installs not completing and it can break things pretty badly, apt-get -f install fixed it though
[09:55] <apw> Daviey, ok so mine rebooted and logged in just fine, so you will need to complete the install
[09:55] <apw> Daviey, can you select recovery boot from the menu?  that should give you the option to fix it i think
[09:57] <Daviey> apw: reovery isn't working either... nor networking.  It's not getting that far, but userspace does seem to start.  I'll chroot in.
[09:58] <apw> yeah i suspect its mountall
[09:59] <Daviey> super
[10:22] <pitti> jdstrand: do you have some time to look at the apparmor part of bug 810270? should that go into some upstream-ish vcs? (affects Debian, too)
[10:25] <brendand> doing dist-upgrade today:
[10:25] <brendand> Errors were encountered while processing:
[10:25] <brendand>  /var/cache/apt/archives/libyelp0_3.1.1-0ubuntu1_i386.deb
[10:25] <brendand> E: Sub-process /usr/bin/dpkg returned an error code (1)
[10:29] <cjwatson> brendand: see scrollback
[11:00] <brendand> just upgraded my Oneiric and now I can't log in
[11:00] <anthony_dev> how I can make image in project to be embedded in my app? (currently I load it using gtk_image_new_from_file)
[11:01] <brendand> trying to roll back lightdm, but struggling to figure out the Pin: version i need to give
[11:01] <cjwatson> brendand: more precise symptoms?
[11:01] <brendand> there's this https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/810271
[11:02] <brendand> the reporter worked around it by using xdm
[11:02] <brendand> which i haven't tried yet, but if i try gdm then it complains about ICEauthority
[11:02] <cjwatson> if I wanted to roll something back, I'd download the .deb from Launchpad and dpkg -i it, rather than using pins (which likely won't help given that the old version will probably have been garbage-collected)
[11:02] <cjwatson> brendand: bug 809776 too, perhaps
[11:03] <cjwatson> brendand: is your liblightdm-gobject-0-0 package at an older version than lightdm?
[11:03] <cjwatson> or rather, than lightdm-greeter-example-gtk
[11:03] <brendand> cjwatson - no
[11:03] <brendand> all at 0.4.3-0ubuntu1
[11:04] <cjwatson> ok, don't know then
[11:05] <cjwatson> 0.4.3-0ubuntu1 worked for me, might be some deeper problem
[11:05] <cjwatson> with no logs, who can say
[11:06] <Riddell> from the new packaging guide "Note however that it is considered bad practice to add a patch system
[11:06] <Riddell> to a package that does not already have one." this seems incorrect to me, I'd rather add a patch system than have to edit files directly
[11:06] <Riddell> dholbach: agree?
[11:06] <cjwatson> Riddell: that's been standard advice in Ubuntu for as long as I've been around.
[11:07] <brendand> where should i look for older versions of lightdm?
[11:07] <cjwatson> it's inherited from the best practice in Debian that you don't muck about with packaging when NMUing; and the reason to carry that over into Ubuntu is that it makes it easier to forward patches to Debian
[11:07] <dholbach> Riddell, I'd personally try to go with whatever the package already has
[11:07] <cjwatson> brendand: https://launchpad.net/ubuntu/+source/lightdm
[11:07] <brendand> .deb files
[11:07] <pitti> Riddell, cjwatson: hopefully more and more obsoleted with 3.0 (quilt) packages these days
[11:08] <cjwatson> (and makes Debian developers less likely to flame us when they look at the diff in Ubuntu)
[11:08] <cjwatson> pitti: yes
[11:08] <cjwatson> 3.0 (quilt) is nearing 50% adoption now
[11:09] <pitti> oh, wow
[11:09] <pitti> incidentally, I'm just converting cups from dpatch to quilt :)
[11:09] <pitti> bit of an exercise, as we have two ubuntu specific patches
[11:09] <pitti> debian/patches/ubuntu.series is not quite what I need
[11:10] <pitti> I'm pondering an extra quilt call in debian/rules for dpkg-vendor --is ubuntu
[11:10] <cjwatson> ubuntu.series is awkward IME, you have to duplicate the whole series
[11:10] <pitti> right
[11:10] <cjwatson> tempting to autogenerate it somehow ...
[11:11] <cjwatson> (but I have seen packages that make use of the fact that you can leave out Debian patches from ubuntu.series)
[11:18] <kirkland> pitti: hum, okay; is that about the /dev -> /run change?
[11:18] <pitti> kirkland: yes
[11:20] <dpm> hi cjwatson, shall I approve the live-helper.pot and live-build.pot templates in LP? Are they supposed to be delivered through language packs?
[11:23] <cjwatson> dpm: I believe so
[11:27] <dpm> cjwatson, thanks, approved and marked as translations in langpacks
[12:18] <dupondje> https://launchpad.net/ubuntu/+source/gnome-shell/3.0.2-1svn2build1
[12:18] <dupondje> could somebody rebuild this ?
[12:18] <dupondje> should build fine now
[12:19] <dupondje> (just tested in pbuilder and its fine)
[12:21] <micahg> dupondje: given back, thanks
[12:23] <dupondje> thanks micahg
[12:23] <dupondje> Installing my new laptop, and gnome3 refused to install :P
[12:24] <dupondje> mmm
[12:24] <dupondje> but it failed again on i386
[12:26] <ogra_> use arm
[12:30] <jdstrand> pitti: the /var/run -> /run symlink has caused a big mess with apparmor beyond isc-dhcp
[12:30] <jdstrand> (and cups)
[12:30] <jdstrand> pitti: I'm going through all the profiles now and adding them to the bug
[12:30] <dupondje> The following packages have unmet dependencies: gir1.2-clutter-1.0 : Depends: gir1.2-json-1.0 but it is not going to be installed
[12:30] <dupondje> but WHY oh WHY :)
[12:31] <pitti> jdstrand: yeah, the /run transition has been "fun", breaking keyboards/mouses, ecryptfs, apparmor, etc :)
[12:31] <pitti> but Debian already did it, so I hope it's not too much left
[12:32] <jdstrand> it just would have been nice to coordinate it. I hadn't planned on fixing all these today and am having to juggle a bunch of things as a result...
[12:33] <pitti> jdstrand: yeah, I'm not sure what happened exactly; from what I heard, there were staged changes in base-files, which someone uploaded prematurely, and then the rest of it was by and large done "under the gun"
[12:34] <jdstrand> meh
[12:34] <jdstrand> ok
[12:35] <dupondje> the launchpad builders always have up-to-date packages no? or is there some lagg ?
[12:35] <pitti> dupondje: they (by and large) see what archive.u.c. has, i. e. they are also subject to publisher runs
[12:36] <dupondje> weird it can't find gir1.2-json-1.0 :s
[12:36] <pitti> it does
[12:36] <pitti> it's just uninstallable
[12:37] <pitti> or, rather, was
[12:37] <dupondje> https://launchpadlibrarian.net/75228082/buildlog_ubuntu-oneiric-amd64.gnome-shell_3.0.2-1svn2build1_FAILEDTOBUILD.txt.gz
[12:38] <pitti> probably unfortunate timing
[12:38] <pitti> as it's not on http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html right now, I'd just try a rebuild
[12:38] <dupondje> well micahg did that 14:21 :s
[12:38] <pitti> oh, hmm
[12:38] <ogra_> publisher race ?
[12:43] <dupondje> would be cool if it builded :) then I could install gnome3 again.
[12:45] <jdstrand> pitti: this is going to need a release note
[12:45] <jdstrand> pitti: for people upgrading who have custom profiles
[12:45] <jdstrand> pitti: has one been started?
[12:46] <pitti> yes, a change of that magnitude should go there indeed
[12:46] <pitti> jdstrand: AFAIUI, it's derived from TechnicalOverview at beta/release time
[12:46] <pitti> before that we track news and upgrade issues in one document
[12:46] <jdstrand> skaet: ^ where should we add this?
[13:04] <pitti> jdstrand: hm, was going to snatch some updates from you, but apparently with the new LP I can't reassign ubuntu tasks any more
[13:04] <pitti> ah, nevermind, just the ajaxy thing; the task expander still works
[13:05] <jdstrand> pitti: this is the change I did for gdm-guest-session:
[13:05] <jdstrand> -  /var/run/** rmwkix, # necessary for writing to sockets, etc.
[13:05] <jdstrand> +  /{,var/}run/** rmwkix, # necessary for writing to sockets, etc.
[13:05] <pitti> ah, you did already? assigning back then
[13:05] <jdstrand> pitti: well, I haven't uploaded yet, but was going to very soon
[13:06] <jdstrand> pitti: I think I've got a handle on it
[13:06] <jdstrand> pitti: thanks
[13:07] <pitti> jdstrand: I can help out with some other packages; just toss me some?
[13:07] <pitti> since I got sucked into that /run thing anyway, may just as well finish it off :)
[13:07] <pitti> cups built, upload coming
[13:08] <pitti> tkamppeter_: ^ that also updates to 1.4.7, FYI
[13:08] <jdstrand> pitti: well, libvirt needs code changes. how about I take apparmor, libvirt, isc-dhcp and clamav, and you take the rest?
[13:08] <jdstrand> (I'll also take gdm-guest-session)
[13:09]  * pitti grabs bind9, ntp, openldap for now
[13:10] <pitti> can do mysql as well after these
[13:10] <jdstrand> pitti: fyi: sed -i 's#/var/run#/{,var/}run#' <profile>
[13:10] <pitti> but let's start with the smaller ones
[13:10] <pitti> yep
[13:11] <pitti> jdstrand: var/lock, too, right?
[13:14] <jdstrand> pitti: yes, it is: sed -i 's#/var/lock#/{run,var}/lock#' <profile>
[13:16] <micahg> jdstrand: don't forget about /run/shm in apparmor/libvirt (should I add that to the bug)?
[13:17] <ximion> hi! Could someone please restart the builds of "easymp3gain" on Oneiric for me? (builds FTBFS due to dependency issues months ago)
[13:18] <jdstrand> micahg: hmmm, good point
[13:18] <jdstrand> micahg: yes please
[13:18] <pitti> (FTR, checking for shm as well)
[13:18] <jdstrand> pitti: it looks like /dev/shm is still hagning around, but as 0755. should this point to /run/shm as well?
[13:18] <Riddell> dholbach: ok if I set bug 702006 back to confirmed?  the guy hasn't done anything since february
[13:18] <pitti> jdstrand: right; bug which breaks ecryptfs, I fixed it this morning
[13:18] <pitti> jdstrand: latest udev and mountall
[13:18] <jdstrand> k
[13:19] <micahg> jdstrand: updated title
[13:19]  * jdstrand looks for /dev/shm as well
[13:20] <Riddell> mok0: is bug 704845 still in progress?
[13:21] <brendand> pitti - ecryptfs got broken?
[13:21] <pitti> brendand: well, it failed with -EPERM on /dev/shm/
[13:22] <pitti> brendand: that's fixed now
[13:22] <pitti> no data loss or anything of that sort :)
[13:23] <pitti> http://cdimage.ubuntu.com/daily-live/20110714.1/
[13:23] <pitti> hooray! and it only took 10 days
[13:23] <pitti> jdstrand: ^ (another victim of /run transition :) )
[13:23] <jdstrand> heh
[13:24]  * ogra_ hugs pitti 
[13:24] <pitti> but 30 MB oversized now (a2 was 15)
[13:24]  * pitti sighs deeply
[13:24] <pitti> how hard can it be to not grow fat!
[13:24]  * ogra_ looks down and notices he would like to know that too 
[13:25] <pitti> 35 MB oversized, even
[13:29] <pitti> meh, and something broke isoinfo on antimony
[13:30] <pitti> ah, nevermind, that was user error
[13:30] <pitti> just a confusing error message ("cannot open SCSI driver" - meh?)
[13:31] <dholbach> Riddell, sounds good, yes
[13:31] <dupondje> dunno if somebody could have a look at https://launchpad.net/ubuntu/+source/gnome-shell/3.0.2-1svn2build1 . It doesn't build on launchpad for some obvious reason. In a local pbuilder it builds fine.
[13:32] <pitti> dupondje: did you try retrying the build already?
[13:32] <sladen> dupondje: "The following packages have unmet dependencies:"
[13:32] <pitti> before doing anything else, I'd do that after the next publisher finishes..
[13:32] <pitti> when we have such transient uninstallability
[13:33] <sladen> dupondje: do have a locally-built dependency that isn't yet built/in the archive?
[13:33] <dupondje> pitti: micahg tried it an hour ago. Maby we can try again, but I don't have such permissions :)
[13:33] <pitti> dupondje: kicked
[13:33] <dupondje> sladen: nope, pbuilder-dist which is up-to-date
[13:34] <pitti> if it fails again, someone needs a oneiric chroot and investigate
[13:34] <pitti> but it installed here just fine
[13:34] <pitti> and g-shell is universe, so it's not a component-mismatches issue
[13:35] <dupondje> failed again :(
[13:35] <sladen> "invoke-rc.d: policy-rc.d denied execution of start." ... is that anything to do with slangasek breaking initscripts yesterday?
[13:36] <dholbach> Riddell, thanks for the update on merge proposal - if barry can give his go-ahead, feel free to merge
[13:36] <dholbach> (I'm not 100% up to date it seems :-))
[13:36] <pitti> sladen: sorry for the obvious question, but is that a chroot? do you actually have a policy-rc.d?
[13:36] <pitti> sladen: or is the error message just horribly wrong?
[13:37] <dholbach> barry, I was talking about Riddell's ubuntu-packaging-guide MP
[13:38] <sladen> pitti: https://launchpadlibrarian.net/75228003/buildlog_ubuntu-oneiric-i386.gnome-shell_3.0.2-1svn2build1_FAILEDTOBUILD.txt.gz
[13:38] <pitti> yeah, failed again
[13:39] <pitti> sladen: oh, you mean that error message? that's fine, buildd chroots have an "all-no" policy-rc.d
[13:39] <sladen> pitti: the message about the denied execution appears about halfway down
[13:39] <sladen> pitti: ah, groovy
[13:42] <dupondje> its really weird
[13:42] <dupondje> can't try with sbuild tho locally
[13:46] <maxb> Hello. Yesterday the UDD package-to-branch importer was changed to use its own launchpad account rather than freeloading on james_w's credentials. Unfortunately no-one thought to make the robot account, ~package-import, a member of ~ubuntu-branches.
[13:46] <james_w> oops
[13:47] <maxb> Please could a member of the Ubuntu Technical Board remedy that omission?
[13:47] <maxb> (pitti?)
[13:49] <pitti> maxb: should I remove james_w, or keep him?
[13:49] <pitti> well, james should already have the rights now by way of u-core-dev membership of ~package-import
[13:49] <maxb> I think a rollback of the importer configuration is unlikely, but I'll let james_w clarify whether he should be in there for other reasons
[13:50] <pitti> same as cjwatson
[13:50] <pitti> but I leave it at this for now
[13:50] <anthony_dev> I'm sorry for asking this question here, but #ubuntu-app-devel is not answering... guys, if in windows we had resource files, what we have in linux? how images, icons and all data stored in linux apps?
[13:50] <james_w> it's useful for the occasional fixup, but not crucial
[13:51] <pitti> james_w: oh, nevermind, I read it wrongly; ~package-import is a core-dev
[13:51] <pitti> it's not a team which includes core-dev
[13:56] <maxb> Thanks, the importer is back in business and processing the backlog successfully
[14:00] <james_w> thanks pitti, maxb
[14:00] <dupondje> mmm sbuild seems also broken on natty
[14:00] <pitti> cjwatson: sorry to bother you, but I don't know where else to look: why is ibus-pinyin still on the CD, and for that matter, in main?
[14:00] <smoser> i'm looking at a watch file for python-boto
[14:00] <smoser> using google code redirector
[14:00] <smoser> http://googlecode.debian.net/p/boto
[14:00] <pitti> cjwatson: checkrdepends has zero rdepends in main, grepping http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/ has no hits at all
[14:00] <smoser> uscan thinks that boto-2.0rc1.tar.gz > boto-2.0.tar.gz
[14:01] <smoser> how can i mangle that so that its right
[14:01] <pitti> cjwatson: and yet it lands in the current desktop squashfs
[14:01] <dupondje> damn :)
[14:01] <pitti> smoser: it is -- it should have been named 2.0~rc1.tar.gz :(
[14:01] <smoser> uscan has some way to mangle things .. but it wasn't obvious if this case would be covered.
[14:02] <smoser> the ~ is a hint though
[14:03] <pitti> jdstrand: meh, mysql failed to build as it fails some tests :/
[14:04] <pitti> SpamapS, zul: ^ halp, please?
[14:04] <skaet> jdstrand,  I'll switch the Tech Overview to the A3 context in the next couple of days,  then putting a note in there is probably a reasonable way to make sure its communicated.
[14:04] <pitti> I was doing an upload to quick-fix the armada of broken apparmor profiles for the /run transition, but apparently mysql doesn't like me :(
[14:06] <jdstrand> pitti: wild guess-- something related to 0.9.x to 1.0.0 openssl. probably need the server team involved
[14:06] <jdstrand> Daviey: ^ would you mind looking at (or having someone) look at the mysql-5.1 ftbfs ^
[14:06] <pitti> jdstrand: given the plethora of "SSL Connection error", that seems likely
[14:07] <jdstrand> skaet: ack
[14:07] <pitti> it's the first oneiric upload
[14:07] <pitti> presumably mysql-5.1 needs some merging with Debian
[14:07] <jdstrand> cool
[14:07] <jdstrand> well, not cool, but 'ok'
[14:08] <jdstrand> :)
[14:08] <pitti> as Debian's demonstrably builds against openssl 1.0.0
[14:11] <jdstrand> zul: do you typically do mysql merges? ^
[14:12] <zul> yep
[14:13] <jdstrand> zul: when you have time, could you do/coordinate a mysql merge (be sure to snag ubuntu5 from oneiric)
[14:13] <jdstrand> ?
[14:15] <zul> jdstrand: yeah sorry just got off the phone
[14:16] <jdstrand> zul: thanks! :)
[14:16] <zul> jdstrand: we were going to merge mysql 5.5 but i think it might be too late and it seems to be stuck
[14:16] <Daviey> jdstrand / zul: So SpamapS was looking at the merge intially... but we were looking to get 5.5 into Debian (from our work), as the DM is overwelmed aiui.
[14:17] <micahg> dupondje: gnome-shell fixed, BTW
[14:17] <Daviey> jdstrand: so we hadn't sync'd before that, as we were expecting 5.5 to be in already.
[14:17]  * jdstrand has no opinion other than that we need a buildable mysql :)
[14:17] <Daviey> SpamapS: What is the current progress with 5.5?
[14:18] <zul> Daviey: i think we should merge the mysql 5.1 now because its getting kind of stale and then wait again for 5.5
[14:18] <zul> Daviey: it was having some debian/copyright issues last time i saw
[14:18] <Daviey> zul: How long did the last merge that you did take?
[14:19] <zul> Daviey: the actual merge doesnt take too long its just running the testsuite
[14:19] <Daviey> zul: Okay.. shoot for it then! :)
[14:27] <bdmurray> pitti: I'm working on tagging apport-kerneloops reports with information regarding the driver where the Oops occurred.  In apport it looks like data/kernel_oops is the right place to do this.  Is that correct?
[14:28] <dupondje> micahg++
[14:28] <dupondje> :)
[14:30] <dupondje> didn't notice that build-dep :)
[14:31] <pitti> bdmurray: I think so, but please check with the kernel team; as we now also have kerneloops, oopses might actually be caught by that one now
[14:32] <bdmurray> pitti: if you mean the kerneloops package they are piped from it to apport
[14:32] <pitti> ah, bood
[14:32] <pitti> "goodÄ
[14:32] <pitti> bah, keyboard fail
[14:32] <pitti> "good"
[14:47] <cjwatson> pitti: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/latest/livecd-20110714.2-i386.out doesn't mention ibus-pinyin - are you sure it's still on the CD?
[14:47] <cjwatson> pitti: cdimage@antimony:~/cdimage/www/full/daily-live/current$ grep ibus-pinyin *.manifest
[14:47] <cjwatson> cdimage@antimony:~/cdimage/www/full/daily-live/current$ grep ibus-pinyin *.list
[14:47] <cjwatson> cdimage@antimony:~/cdimage/www/full/daily-live/current$
[14:50] <SpamapS> Daviey: 5.5 needs an updated copyright file and then should be accepted into Debian
[14:50] <SpamapS> ah, as zul explained.. ;)
[14:50] <SpamapS> agreed that we should at this point merge 5.1, as 5.5 is lagging and the transition will take quite a while.
[14:51] <brendand> seems like ecryptfs-mount-private no longer wants to work for me
[14:51] <brendand> i get permission denied when running it
[14:54] <brendand> open: Permission denied
[14:54] <brendand> just like that
[14:54] <brendand> this is after upgrading oneiric today
[14:54] <brendand> pitti - is that what you were talking about earlier?
[14:54] <cjwatson> that'll be the apparmor problems I expect
[14:55] <brendand> aha - any workaround?
[14:55] <brendand> or bug number?
[14:56] <cjwatson> bug 810270
[15:01] <jdstrand> actually, aiui, that is a result of the /dev/shm -> /run/shm change
[15:01] <brendand> so i have to update something in apparmor.d?
[15:01] <jdstrand> brendand: you should just be able to dist-upgrade and get the new mountall, etc
[15:02] <brendand> jdstrand - i'm all upgraded out
[15:02] <jdstrand> I am fixing the apparmor stuff, but ecryptfs isn't confined by apparmor, so that shouldn't be it
[15:03] <jdstrand> brendand: ecryptfs may need code changes for /dev/shm -> /run/shm
[15:03] <jdstrand> brendand: I'd file a new bug on that
[15:03] <jdstrand> well, actually
[15:03] <jdstrand> brendand: yes, a new bug
[15:07] <pitti> brendand: correct, that's the bug fixed by latest udev and mountall
[15:07] <pitti> related to /dev/shm/ permissions (or, being the wrong one)
[15:07] <pitti> brendand, jdstrand: the ecryptfs prob has nothing to do with apparmor
[15:07]  * jdstrand nods
[15:08] <brendand> pitti - my udev is at 172?
[15:08] <pitti> brendand: you need udev 172-0ubuntu3 and mountall 2.30
[15:08] <brendand> i don't
[15:08] <brendand> been dist-upgrade'ing
[15:08] <pitti> brendand: workaround:
[15:08] <pitti> sudo rm -r /dev/shm
[15:08] <pitti> sudo ln -s /run/shm /dev/shm
[15:08] <pitti> (works until reboot)
[15:09] <brendand> pitti - ok , thanks
[15:09]  * brendand is wondering why he's not getting the new udev and mountall yet
[15:09] <brendand> are the deb packages somewhere?
[15:11] <pitti> outdated mirror?
[15:11] <pitti> brendand: they are on archive.u.c.
[15:11] <brendand> i'll check sourcs.list
[15:12] <brendand> s/sourcs/sources/
[15:14] <brendand> thank you pitti :)
[15:14] <pitti> you're welcome; sorry for the breakage
[15:14] <pitti> came a bit unexpected
[15:14] <brendand> i'm quite happy i don't need to re-install
[15:15] <pitti> nah, it's not that broken, and it wouldn't even have helped
[15:27] <bdmurray> pitti: https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/tag-oopses-with-driver/+merge/67979
[15:35] <dholbach> Ubuntu Developer Week Day 4 starting in 25 minutes in #ubuntu-classroom (https://wiki.ubuntu.com/UbuntuDeveloperWeek)
[15:45] <SpamapS> pitti: I'd love to get your guidance on the libreoffice upload to natty-proposed. It seems rather large for an SRU ...
[15:49] <SpamapS> mvo: on the recent upload tof software-center to natty-proposed, the RELEASE was changed from 11.04 to 11.10, I don't think that was intentional...
[15:58] <mvo> SpamapS: indeed, sorry for that. could you please reject?
[15:59] <SpamapS> mvo: no problem. Done.
[16:02] <pitti> SpamapS: right; I discussed that with Sweetshark before; it's essentially a new upstream microrelease
[16:02] <pitti> SpamapS: it fixes three handful of rather important bugs, like a broken -base, crashes, etc.
[16:02] <SpamapS> pitti: I didn't see anything "scary" .. its just a ton of tiny tweaks..
[16:03] <pitti> yeah
[16:03] <SpamapS> pitti: but I wanted to confer w/ you... as its not a "slam dunk" :)
[16:03] <pitti> I don't expect this to go into -updates after just 7 days, it'll need some thorough testing
[16:04] <pitti> SpamapS: the libreoffice-build/NEWS diff is probably the best summary
[16:05] <pitti> I sponsored it, but didn't want to accept it just by myself, as with being desktop team I might be a bit biased
[16:05] <SpamapS> pitti: the only other concern I had was that it fixed a ton of bugs but there were only two launchpad bugs mentioned.
[16:05] <pitti> SpamapS: but it looks bearable to me; I think we should have it in -proposed, and then gather some people for testing
[16:08] <SpamapS> pitti: alright, given that context, I'll give it another look.
[16:09] <pitti> ok, thanks
[16:11] <pitti> bdmurray: nice one! doing the merge now
[16:12] <bdmurray> pitti: great, thanks!
[16:17] <didrocks> jdstrand: hey, it seems that you didn't push the unity upload to lp:~ubuntu-desktop/unity/ubuntu (see the Vcs-Bzr tag), can you please fix this and ensure it's upstreamed as well?
[16:18] <jdstrand> didrocks: I didn't, I also mentioned this in irc to you yesterday:
[16:18] <jdstrand> 09:03 < jdstrand> didrocks: hey. I uploaded the fix for unity for bug #805938. I could not apply to the Vcs branch because bzr kept crashing on me. I put my debdiff in the bug if you want to apply it to your tree
[16:18] <mvo> SpamapS: fixed and re-uploaded
[16:19] <didrocks> jdstrand: I was at some conferences, hence the fact I wasn't connected on IRC. Can you ensure there is a branch proposed for njpatel?
[16:20] <jdstrand> didrocks: well, that gets back to bzr crashing
[16:20] <didrocks> jdstrand: I try to avoid messing up the branch (as we use merge-upstream with upstream vcs) and push fixes upstream first, the bzr merge :)
[16:20] <didrocks> jdstrand: right, just ensure that njpatel is aware of the bug to merge
[16:20] <didrocks> (if it's not already the case)
[16:21] <jdstrand> didrocks: I think between my bug comments and all his references here, njpatel is probably aware :)
[16:21] <jdstrand> njpatel: please see https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/805938/comments/14
[16:21] <didrocks> jdstrand: we never ping Neil enough :-) Thanks a bunch!
[16:21] <jdstrand> sure!
[16:21] <jdstrand> didrocks: sorry I couldn't do it myself
[16:21] <didrocks> jdstrand: no worry ;-)
[16:23] <SpamapS> mvo: ack, will re-check shortly
[16:23] <mvo> thanks
[16:24] <chrisccoulson> jdstrand, i guess your bzr crash is the same as the one i see (which is bug 807076)
[16:58] <lamont> ok.  wtf does natty hate my daughter's wireless?
[16:59] <infinity> ath9k?
[16:59] <lamont> 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
[17:00] <infinity> Oh, then no idea.  Maybe natty's just sexist.
[17:00] <lamont> went the system -> admin -> additional drivers route, it claims "no proprietary drivers"
[17:01] <directhex> isn't that wired, not wireless?
[17:02] <lamont> bah
[17:02] <infinity> directhex: Sure looks like it, yeah.  :P
[17:02] <lamont> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
[17:02] <lamont> let's go with that one
[17:03] <infinity> lamont: Well, now I'm even more confused then, because IPW is usually insanely well-supported (and, in fact, I have that very same wireless in this laptop)
[17:03] <lamont> iwlist scan sees aps, but network mangler declines to believe in wireless, now that I dig deeper
[17:03] <infinity> lamont: Define "hate"... Oops, panic, randomly just stops being useful?
[17:03] <lamont> declines to configure
[17:04] <jpds> lamont: You could check the NM bits with cyphermox.
[17:04] <infinity> lamont: No manual configs in /etc/network/interfaces that are making NM ignore/skip the interface, I assume?
[17:06] <cyphermox> lamont: /var/log/syslog will tell everything we need
[17:06] <lamont> wtf.  thanks infinity
[17:08] <lamont> (static config in interfaces, for reasons unknown)
[17:08] <lamont> oh haha.  reasons suspected
[17:08] <cyphermox> oh
[17:08] <cyphermox> lamont: glad to know it's under control then :)
[17:09] <infinity> lamont: "because it's been near lamont" or "because lamont's daughters are even more hackish than he is?"
[17:11] <lamont> infinity: because at one specific magic point in the past, wlan0 was the default-route possessing interface, and some automagic happened
[17:11] <slangasek> sladen: the new invoke-rc.d message is a change merged from upstream (Debian); the only delta was a more verbose error message, it shouldn't cause any failures.  If it does, yell. :-)
[17:12] <lamont> infinity: IOW, I know what the root cause is now, and it's (unfortunately) me.
[17:29] <cjwatson> pitti: general thoughts on lp:~cjwatson/ubuntu/oneiric/ubuntu-defaults-builder/image ?  it's really mostly a sketch right now - it does successfully build a squashfs, but the ISO image build step will fail until we have syslinux-themes-ubuntu-* packages, and keyring handling is pretty bustsed
[17:29] <cjwatson> *busted
[17:46] <mdz> pitti, hi! do we have a TB meeting in 15m as my calendar says, and are you chairing?
[17:50] <cjwatson> mdz: that's my belief, at least for the former
[17:53] <mdz> cjwatson, I see apologies from pitti, sabdfl and Keybuk in https://lists.ubuntu.com/archives/technical-board/2011-July/000973.html
[17:53] <mdz> kees, around?
[17:54] <mdz> cjwatson, unless kees is attending, we won't have quorum
[17:58] <cjwatson> mdz: I shan't complain, I have an appointment with the pub
[17:58] <cjwatson> but much though I love beer I suppose the TB needs to take precedence :-)
[17:59] <cjwatson> $ sudo strace -etrace=umount,oldumount umount `pwd`/proc
[17:59] <cjwatson> oldumount("/proc")                      = -1 EBUSY (Device or resource busy)
[17:59] <cjwatson> dear util-linux, what exactly do you think you're doing?
[17:59] <cjwatson> (no, `pwd` is not /)
[17:59] <geser> mdz: "kees | heya, i'll be a few minutes late..." (from #ubuntu-meeting)
[17:59] <mdz> geser, oh thanks, hadn't seen that
[18:41]  * SpamapS bites the bullet and upgrades main laptop to oneiric..
[19:12] <Daviey> cjwatson: Did you see bug #806231?  Is this a bug that can be fixed, considering it's valid to configure to run these daemons on different ports?
[19:16] <dupondje> weird
[19:16] <dupondje> I just installed oneiric, but gnome3 doesn't start
[19:17] <dupondje> can't find applications.menu, but gnome-menus is installed
[19:17] <dupondje> but the file doesn't exist
[19:20] <dupondje> aha
[19:20] <dupondje> that looks like a bug :)
[21:00] <micahg> how did the SRU for libreoffice for natty get in w/out the dev release getting updated?
[21:02] <micahg> SpamapS: ^^
[21:20] <infinity> micahg: Because it's only in -proposed right now?
[21:20] <infinity> micahg: When it makes it to -updates, it'll be copied to oneiric if it's still newer.
[21:21] <micahg> infinity: yes, but that's generally only done at the beginning of the cycle, also, it doesn't build it with the newer toolchain
[21:21] <infinity> micahg: Well, if you're asking for a different source version, that's a different request.
[21:22] <infinity> micahg: But to the other concern, no, we can (and do) copy from natty-updates to oneiric any time.
[21:23] <micahg> infinity: I know it can be made right :), was just wondering why it wasn't built with the oneiric toolchain in the first place (hasn't been yet), it also impacts transitions in oneiric
[21:23] <infinity> micahg: (Which is exactly what happened for the last libreoffice upload)
[21:24] <infinity> 1:3.3.2-1ubuntu5 went to natty-proposed, then to natty-updates and oneiric in May.
[21:27] <dupondje> lool: Does Xterm icon gets updated? It really looks .. well UGLY :)
[21:36]  * micahg retracts the part about transitions, but it's still weird WRT not using the new toolchain
[21:38]  * micahg retracts his retraction :)
[21:43] <bdmurray> cjwatson: did you write a wiki page regarding bug 442941?
[21:45] <bdmurray> cjwatson: and actually isn't bug 349469 related to 442941?
[21:49] <SpamapS> micahg: we're allowed to accept into -proposed before the dev release is updated. Its just not going to go into -updates
[21:50] <micahg> SpamapS: then it's not versioned correctly
[21:51] <SpamapS> micahg: right, I understand what you mean, it should be 5.1 instead of 6 ... this can be handled by making sure the oneiric upload (if there is one) is 7.
[21:52] <dupondje> Are we going to have something like Bumblebee in 11.10 ?
[21:52] <micahg> SpamapS: the upload is for a new upstream version, ubuntu1 was used instead of either ubuntu1~natty1 or ubuntu0.11.04.1
[21:53] <SpamapS> micahg: yes, I understand. The oneiric upload can still supersede it, even if dch -i won't do it automatically.
[21:53] <micahg> SpamapS: yes, I know it's possible, just wondering why it happened to begin with...
[21:56] <SpamapS> micahg: its a *slight* issue in a very complicated and important bugfix release that needs testing ASAP.
[21:56] <infinity> SpamapS: Yeah, I'm inclined to agree with micahg that if you intended to do two source uploads, the versioning is "wrong".  I assumed you just intended to copy from -updates to oneiric (which would be fine).
[21:57] <infinity> Though the argument for building with the current toolchain supports two uploads.
[21:57] <micahg> SpamapS: I'm just wondering if it was an active decision at acceptance time or it wasn't flagged as problematic
[21:57]  * infinity shrugs.
[21:57] <SpamapS> micahg: I flagged it but not as an egregious error since there had been no actual upload to oneiric yet.
[21:58] <infinity> Yeah, if the oneiric upload is -1ubuntu2, we can just pretend -1ubuntu1 was done long ago. :P
[21:58] <ohsix> nm
[21:59] <ohsix> oops
[22:02] <micahg> SpamapS: ok, just wanted to make sure it wasn't slipping through the cracks :)
[22:41] <v1z_> hi there
[22:42] <v1z_> I would like to develop focus follows mouse in unity
[22:43] <v1z_> do you know if this has already been done *fully*?
[22:44] <v1z_> b/c it becomes impossible to access the menu for an application if the mouse hits a window behind it
[22:44] <v1z_> ?
[22:45] <v1z_> a more direct queston: what would you read to do this? gnome devel docs and gtk tutorials? any good refs?
[22:46] <v1z_> assuming I already know c very well, autotools, git
[23:00] <v1z_> thanx anyways
[23:05] <persia> v1z_, It's a more systemic issue: what *should* happen for FFM with indicator-appmenu installed?  It needs design work before coding.
[23:06] <persia> Most of the FFM users I know have removed that package, and use menus embedded in the applications.  This is less ideal if there are few pixels on the screen.  Finding the right answer for everyone is hard.
[23:22] <v1z_> persia: ok cool.. removing ffm gives menus embedded in the apps
[23:23] <v1z_> yes, i imagine it to be hard to find the right answer for everyone, that is why configuration exists
[23:24] <v1z_> btw I really believe the default in ubuntu 11.04 is very good for most ppl
[23:24] <v1z_> and the space saving is great
[23:26] <v1z_> perhaps there is a design idea for ffm plus unity
[23:26] <v1z_> (sorry I meant removing unity not ffm above)
[23:27] <v1z_> persia: "removing the above package" refers to unity?
[23:28] <v1z_> so you mean like logging to ubuntu classic?
[23:34] <v1z_> so I am willing to put some real dev and design effort into this if needed
[23:35] <v1z_> unless its already being taken care of etc
[23:36] <v1z_> okay so I might be thinking out loud, I apologize,
[23:37] <v1z_> but rereading what persia said, uninstalling indicator-appmenu should do it for FFM users
[23:38] <v1z_> right? I will give it a try tomorrow
[23:38] <v1z_> thanks!
[23:40] <persia> v1z_, Removing indicator-appmenu
[23:40] <persia> I don't know of anyone engaged in the design work.  The only idea I heard on the subject was to have another package that would only give the  indicator-appmenu behaviour if a window was maximised.
[23:41] <persia> But that was from someone who didn't code much.
[23:41] <persia> Anyway, once you've done the design work, you probably want to look at indicator-appmenu as a basis for how such a thing could be implemented.
[23:42] <persia> Then you probably want to discuss your ideas with the folk in #ubuntu-desktop for help on how to allow your new package to be an alternate way to handle menus in the indicator, and how to integrate most smoothly with the rest of the unity experience.
[23:44] <v1z_> persia: thanks a lot.. i will keep this possible contrib in mind
[23:48] <v1z_> seems like indicator-appmenu is simple enough; small code and just make install it
[23:48] <v1z_> (I keep talking cuz the channel is quiet anyways)
[23:54] <lool> dupondje: Eh at least I can distinguish it easily  ;-)