[00:00] james_w: heh [00:02] 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] james_w: ah, hmm [00:02] and the source package didn't conatin the dirs either [00:03] because the package won't contain empty dirs, I guess [00:03] yeah === mnepton is now known as mneptok [00:03] I think this can go in the "immaterial differences" pile [00:06] slangasek: Sure, and so do you. [00:07] bug 810218 [00:07] Launchpad bug 810218 in Ubuntu Distributed Development "spurious collisions when empty dirs are left in the branch with dpkg-source v1" [Undecided,New] https://launchpad.net/bugs/810218 [00:07] 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] slangasek: Well, do you mean "kicking buildd hardware violently" (if so, then no), or "abusing chroots in unpleasant ways"? [00:08] slangasek: If the latter, we can both do it, even if you weren't entirely aware you could. ;) [00:08] infinity: abusing chroots to recover from sysvinit-utils being broken in some fashion I have yet to discern [00:08] infinity: heh [00:08] Then yes, we both can do that. ;) [00:09] But I'm happy to drive for you once you figure out what you want done. [00:09] (After I eat some food) [00:11] 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] 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] will builds which failed due to chroot problems automatically be rescheduled? [00:16] All except yours, since you asked. [00:17] infinity: you wanna come hang in -release for a bit? === poolie_ is now known as poolie === slangasek changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [02:05] 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] 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] chowder: Yes, but not with Ubuntu kernels. [02:06] 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] 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] chowder: The hypervisor and tools are packaged in the archive, just not a usable dom0 kernel. [02:08] 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] 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] 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] chowder: Don't touch anything except to find the Xen stuff and enable it. [02:10] 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] infinity, that sounds simple enough. I'm on a fresh install and I was dreading having to install another linux distro [02:11] I really should roll dom0 kernels in a PPA or something. [02:12] But I've just been doing dom0 on hardy, and waiting on the glory of Linux 3.0 in oneiric. [02:12] the thing is that I need windows for my uni but virtualbox is about as fast as taffy. So here I am. [02:12] (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] Isn't virtualbox just a wrapper around kvm? [02:13] No, it's a separate virtualisation implementation [02:13] Or maybe I'm thinking of something else. I dunno. [02:14] 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] infinity, would I be able to run windows as efficiently on KVM as xen? [02:15] Should do. [02:16] And there should be a ton of HOWTOs and guides and such dealing with KVM on the Ubuntu wiki and docs site. [02:16] Since it's what all the young'uns are using. [02:16] And no kernel futzing. [02:18] 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] Plenty of people use KVM in production. [02:20] I'm just not one of them. :P [02:20] Every virtualisation environment is annoying for one reason or another. Today, kvm probably has the best documentation available. [02:21] persia: Xen's not annoying to anyone who grew up on IBM kit. [02:26] I'm looking into kvm now. its like an epic battle between KVM and Xen. THERE CAN BE ONLY ONE! [02:29] infinity, Not annoying in *any* way? Not even a little? [02:43] persia: Well, it fails to annoy me. And everything annoys me. [02:45] infinity, Given comparative search results for "virtualbox annoying", "xen annoying", and "kvm annoying", I think you're special. [02:45] Hahaha. [02:46] heh [02:46] persia: They're all close enough to discount variance as statistically insignificant. :P [02:47] Right, so if you find one more annoying than another, then you're not following statistical norms, hence "special" [02:47] persia: Besides, I also had the "if you grew up with IBM VM" qualifier, which is a pretty small subset of people. [02:47] persia: Most of whom likely don't blog. [02:48] internet, whats that? [02:48] Ed Zachary. [02:48] 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] 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] Oh my. With "IBM VM $virtualisation_tool Annoying", KVM loses by a factor of two, compared with Xen and virtualbox. [02:50] Besides, we all know the Internet is just for IRC: http://www.youtube.com/watch?v=O2rGTXHvPCQ [02:50] infinity: Oh god, is that the num3rs one? [02:50] hah, yes. [02:51] Yup. :) [02:52] The 1337 bits in that annoys me more than the "primite chat program" bit :/ [02:52] Luckily, I speak l33t! [02:53] *primitive [03:07] whew, they got a screenshot [03:13] bryceh: It was touch and go there for a bit. === emma is now known as em [04:18] Goodm orning [04:20] Good morning, pitti [04:21] pitti, orning to you too [04:21] bryceh: 'ow are you? [04:21] hey RAOF [04:21] pitti, ood! [04:21] meh, what happened to the Windows key? [04:22] ah, nevermind, keyboard fail [04:22] Heh. [04:24] bdmurray: will do, thanks! [04:43] slangasek: impressive sysvinit merge changelog! [04:55] pitti: s/impressive/eye-bleeding/ :) [04:56] ah, just recovered from a reboot [04:56] slangasek: it seems to break ecryptfs once again :/ [04:56] oh, really? [04:56] how does it do that? [04:56] slangasek: it stumbles upon -EACCESS on /dev/shm/ [04:56] hmmm [04:56] it seems that /dev/shm is now root:root 755 [04:57] moving it to 777 temporarily fixes things again [04:57] was it 777 before? [04:57] * pitti boots an older live CD to check [04:57] pitti: eh, it was meant to be a symlink to /run/shm [04:58] hm, /run/shm/ looks fine indeed [04:58] the other thing that I found is [04:58] none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) [04:58] none on /run/shm type tmpfs (rw,nosuid,nodev) [04:58] tmpfs-on-tmpfs, but that's merely a curiosity right now [04:58] slangasek: do you know what is responsible for setting up /dev/shm? udev, initramfs, mountall? [04:58] deliberate [04:59] ah, /run/shm needs to be "exec"? [04:59] does it? [04:59] do you have /dev/shm as a symlink to /run/shm, or is it still a real directory for you? [04:59] I don't know, but different mount options seems like the reason for doing this? [04:59] ah [05:00] no, the reason is the different write perms [05:00] it's a real dir [05:00] /run/shm is world-writable, as is /run/lock for historical reasons; /run must be root-only to avoid DoSes [05:00] right, I see what went wrong with /dev/shm [05:00] 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] (phone, brb) [05:04] slangasek: well, mere access permissions wouldn't need a mount-on-mount, but different mount options certainly do [05:04] e. g. /run/shm/ needs "dev", while /run/lock certainly should be "nodev" as it's world writable [05:04] pitti: no, they absolutely do need mount-on-mount because there's no quotas on tmpfs [05:05] anyway, so the mount-on-mount seems to be on purpose then [05:06] uploaded a fix for the /dev/shm bit [05:06] (sysvinit ubuntu4) [05:06] merci beaucoup! that was fast [05:08] pitti: well as soon as you asked me what's responsible for setting it up, I realized my bug ;) [05:10] hmm, actually, that's an incorrect/incomplete fix... I need to poke mountall [05:15] pitti: ok, now I'm really puzzled... I just realized /dev/shm is a symlink here and I don't know *how* [05:15] so I may be piling on irrelevant kludges at this point [05:15] sheer willpower from your side? [05:16] that seems unlikely, since I largely ignore /dev/shm anyway :) [05:16] * pitti snatches the built debs from LP and installs [05:16] but /dev is not persistent, being a devtmpfs [05:16] so something is creating the directory for you at boot time [05:16] and something created a *symlink* for *me* at boot time [05:16] and I can't find what the 'something' is in either case [05:18] 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] ok, so sysvinit ubuntu4 didn't help [05:20] right [05:20] it "helps" in the unusual case that /dev is not actually a devtmpfs [05:21] ... which is unsupported, so === dendrobates is now known as dendro-afk [05:21] pitti: you have mountall 2.29 as well? [05:21] yep [05:21] oneiric up to date [05:22] 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] oh, wait [05:22] ./schroot/buildd/fstab:tmpfs/dev/shmtmpfsdefaults00 === _LibertyZero is now known as LibertyZero [05:23] no, that's only for within a schroot [05:24] so, if you had the old mountall installed, that would account for /dev/shm being mounted with the traditional perms (rwxrwxrwxt) [05:24] with the new packages, I can't account for *anything* creating /dev/shm, as either a symlink or a dir [05:24] might it be possible that it's just part of a standard devtmpfs? [05:24] that seems unlikely to me [05:24] sudo mount -t devtmpfs none /mnt [05:25] $ ls -ld /mnt/shm/ [05:25] drwxrwxrwt 2 root root 120 2011-07-14 07:20 /mnt/shm/ [05:25] so it is part of devtmpfs, but with correct permissions [05:25] hmm [05:25] ugh, that sounds like a race condition waiting to happen... [05:25] devtmpfs tries to be "clever" enough to provide everything you need even in an init=/bin/bash session [05:25] "with correct permissions" - nah, permissions on the symlink don't matter [05:26] slangasek: no, it's a dir in standard devtmpfs [05:26] so we now need to look for what changes the permissions [05:26] pitti: oh, actually, I think mounting multiple copies of devtmpfs just gives you a mirror of the same fs :) [05:26] ah, perhaps [05:26] pitti: because when I mounted it *here*, I got shm -> /run/shm again :) [05:26] slangasek: ok, rebooting again into init=/bin/bash and checking it there [05:27] broder: what race condition? [05:27] slangasek: if there's a window between when /dev/shm exists and when it gets changed to a symlink [05:29] broder: yeah, there's not meant to be one because it's not meant to exist except as a symlink [05:36] ok, no /dev/shm/ with just init=/bin/bash [05:37] it's not created in the initramfs either [05:37] i wonder if, like, libc somehow creates it or something equally hideous [05:38] doesn't seem to be udev, just grepped its source [05:41] slangasek: which bit would make it a symlink to /run/shm? [05:41] pitti: that's just it, I don't see one anywhere [05:42] I don't see what creates it as a directory either [05:43] I'm done checking /etc/ and /lib [05:43] and udev sources [05:43] * persia thought /dev/shm was a virtual directory provided by the kernel [05:44] well, http://en.wikipedia.org/wiki/Shared_memory tells me the kernel provides it by default on Ubunut [05:44] Ubuntu [05:44] so if wikipedia says so... :P [05:44] hm, maybe it's created by a module, which isn't loaded yet in init=/bin/bash? [05:45] persia: except that mountall was previously set up to mount /dev/shm as a tmpfs on boot [05:45] 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] Hrm, but my memory doesn't match the output of `mount` on a natty system :( [05:46] persia: when what was introduced? the mountall handling? [05:46] persia: /dev/ itself is a devtmpfs, so it doesn't need to be a mount on top of it [05:46] I upgrade my oneiric VM, to avoid having to reboot so often [05:46] and snapshots FTW [05:47] persia: you are right indeed [05:47] none on /dev/shm type tmpfs (rw,nosuid,nodev) in alpha-2, so it was indeed mount-on-mount [05:47] That's the mount from mountall [05:47] right [05:48] frankly, I can't work out from this why we have /dev/shm at all [05:48] the justification I've always heard was "filesystem exposure of SHM for IPC" [05:48] but I see nothing that ties this to the POSIX SHM APIs [05:48] Doesn't libc use it to provide the SHM API? [05:49] glibc's implementation requires /dev/shm to be a tmpfs for shm_open et al to work [05:49] ah [05:49] also for the semaphore API to work, i think? [05:49] but it turns out that shm_open(foo) is actually just open("/dev/shm" foo) [05:49] right, I wasn't thinking that the mapping would happen in libc; I thought there were syscalls for shm/sem [05:49] "everything is a file" :) [05:50] even things that really shouldn't be [05:51] 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] hmm [05:52] why the blazes did Debian move this to /run at all then [05:53] persia: if that's the case then why did mountall need to mount /dev/shm? [05:53] Right, and ./drivers/base/devtmpfs has dev_mkdir("shm", 01755); in __init int devtmpfs_init(void) [05:54] broder, I think that predated devtmpfs, but that's just a guess. [05:54] 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] 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] I upgraded my clean alpha-2 instlal oneiric VM, and I also get /dev/shm 755 as a dir [05:56] not 1755 [05:56] broder, It's from <1241097822.2516.3.camel@poy>, from linux-kernel@vger [05:56] so it seems our previous mountall just papered over the broken devtmpfs permissions then? [05:56] persia: uh, that's not in our kernel [05:57] persia: but it does matter that the perms aren't 755... [05:57] http://paste.ubuntu.com/643796/ is Ubuntu-2.6.38-9.43:drivers/base/devtmpfs.c [05:57] (easiest tag to grab) [05:57] 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] yes, and that's fine IMHO === Igorot is now known as Knightlust [05:59] persia: I also can't find this dev_mkdir() call in the current kernel [05:59] 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] so you reckon devtmpfs creates /dev/shm the first time a program tries to access devtmpfs? [06:00] I don't see how it would [06:00] CONFIG_DEVTMPFS_MOUNT affects automatically mounting of /dev itself, not /dev/shm [06:00] still doesn't explain why slangasek gets a symlink for it [06:02] fwiw, the timestamp on the symlink exactly matches that of the other nodes created at boot [06:02] created 3 seconds before /dev/sda, actually [06:03] oh, that's an interesting point [06:03] in my VM, all nodes are from 2011-07-14 07:55, i. e. when I booted [06:03] but /dev/shm is from 2011-06-28 19:12 [06:04] which might be when I created that VM [06:04] devtmpfs doesn't bleed through what's under it, does it? [06:04] perhaps it does something crazy like that? [06:05] either that, or an init script "restores" /dev/shm from somewhere else [06:05] well, I checked for that with mount -obind / /mnt [06:06] /mnt/dev/ was completely empty here [06:06] mine isn't, I have a fairly well populated one [06:06] but there /dev/shm is root:root 0755 (same perms) but 2011-07-05 11:30 [06:06] i. e. yet another date, which is in between [06:07] right, no idea then [06:07] wait, what do you guys have in /lib/udev/devices? [06:07] broder: you rock [06:08] /lib/udev/devices/shm 2011-06-28 19:12 0755 [06:08] that very timestamp, that permission [06:08] the udev package ships /lib/udev/devices/shm [06:08] slangasek: ^ is that a symlink for you by any chance? [06:09] pitti: nope :/ [06:09] broder: I thought I got rid of all these a while ago, apparently I missed some [06:10] udev (093-0ubuntu13) edgy; urgency=low [06:10] * Make sure that net, pts and shm sub directories exist under [06:10] /lib/udev/devices in the package. Ubuntu: #57436. [06:10] that still doesn't explain where slangasek's symlink is coming from, of course [06:11] no, but at least explains the other half of the story [06:11] slangasek, Have you had a /run/shm/shm directory? [06:12] when I remove /lib/udev/devices, I now don't have a /dev/shm/ at all any more [06:12] let's chalk my symlink up to somnoclavicism for the moment [06:12] and with devtmpfs /lib/udev/devices should be entirely obsolete [06:12] pitti: after a reboot, or it disappears immediately? [06:12] slangasek: after reboot [06:12] persia: no [06:14] slangasek: udevd does that on startup [06:14] (copy /lib/udev/devices/* to /dev/) [06:14] y'all's shm problems broke my Chromium! ;-) [06:15] pitti: k [06:15] I'd prefer to fix udev to remove /lib/udev/devices/ entirely; it's time to get rid of this hack [06:15] question is now, what should create /dev/shm -> /run/shm ? [06:15] pitti: well, /etc/init/mounted-dev.conf probably should [06:15] (or why did we move it in the first place) [06:16] I was halfway to uploading that when I realized I didn't know what was going on [06:16] oh dear, this thing _also_ copies /lib/udev/devices [06:16] looks like /etc/init.d/mountdevsubfs.sh does it in debian-land? so mounted-dev seems like it makes sense [06:16] oh, hah [06:16] slangasek: as udevd already does that, this bit should go away then [06:17] slangasek: but will that be early enough? i. e. initramfs stuff trying to use /dev/shm ? [06:17] 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] pitti: it would have to be - nothing would mount /dev/shm in the initramfs previously, right? [06:17] broder: correct [06:17] 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] slangasek: ok, will do; sleep well then! [06:18] thanks :) [06:18] pitti: eh, where would it get /lib/udev/devices inside the initramfs though? [06:19] I think it's more likely that nothing in the initramfs has ever cared about shm [06:19] $ zcat /initrd.img | cpio -t|grep udev/devices [06:19] indeed, nothing copies it [06:19] slangasek: so much the better :) [06:20] 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] 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] ah, that seems to be in the code [06:22] 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] persia: thanks! [06:22] (the rest of /lib/udev/devices ought be obsolete with devtmpfs, as those have real nodes) [06:22] ok, so I think I now have everything together to fix this [06:22] - remove /lib/udev/devices/ for good, and clean up on upgrades (udev) [06:23] - remove the copying in /etc/init/mounted-dev.conf (mountall) [06:23] - have mountall upstart script create the symlink to /run/ (mountall) [06:26] pitti, And mountall mounts /dev/pts (devpts), and /run/shm (tmpfs)? [06:27] mountall upstart script> you mean mounted-dev.conf, right? [06:27] broder: I'm not actually sure, as /dev/ already gets mounted by the kernel [06:28] ideally mounted-dev.conf wouldn't even run, except for a kind of "coldplugging" run [06:28] pitti: mountall emits mounted events for fs's that were mounted before it runs [06:28] persia: yes, see /lib/init/fstab [06:28] Also compatibility for folks who don't have devtmpfs for some reason. [06:28] broder: it's easy enough to test [06:28] persia: does that even work still? [06:29] pitti: look at mark_mounted in src/mountall.c [06:29] pitti, That says "/dev/shm": should it say "/run/shm"? [06:30] /lib/init/fstab:none /run/shm tmpfs nosuid,nodev [06:30] pitti, I haven't tested it, but /etc/init/mounted-dev.conf still has compatibility code in it. [06:30] /lib/init/fstab:none /dev/pts devpts noexec,nosuid,gid=tty,mode=0620 0 0 [06:30] persia: yes, I'll keep that minimal bit [06:30] * persia updates that chroot [06:30] hmm...actually, should the /dev/shm symlink get created on mounted MOUNTPOINT=/run/shm ? [06:31] broder: in theory that'd race with mounting of /dev [06:31] in the case when devtmpfs isn't mounted by the kernel [06:31] Ubuntu kernels do, so it's not a problem there [06:31] bah. fine - mounted MOUNTPOINT=/run/shm and mounted MOUNTPOINT=/dev [06:31] but I think it's safer to create the link in mounted-dev [06:32] I don't think we care if /run/shm is mounted when the symlink is created. [06:33] right [06:40] 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] I fixed my vm with /dev/shm -> /run/shm, and /run/shm/ has the pulse stuff now [06:41] i'm probably just misreading the code [06:41] but for the sake of avoiding the symlink lookup every time, eglibc should probably be changed to use /run/shm/ right away? [06:45] 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] "If we do eventually deprecate /dev/shm in favour of /run/shm" [06:45] ah, good [06:50] symlink lookups will be lost in the noise, I expect [06:53] cjwatson: good morning [06:53] 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] 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] but I'm happy to do a "mountpoint /dev || mount -t devtmpfs devtmpfs /dev" kind of thing instead [06:57] or if "mountpoint" availability is questionable, just [06:57] [ -e /dev/null ] || mount ... [06:59] cjwatson: http://paste.ubuntu.com/643841/ [07:00] 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] infinity: right, see pastebin: it still mounts it manually [07:05] 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] broder: ... and ecryptfs seems happy with the symlink, too [07:09] (if it weren't, I couldn't talk to you in the first place :) ) [07:19] pitti: you're guaranteed not to have 'mountpoint' in the installer [07:20] pitti: shrug, I guess - seems plausible enough [07:20] http://paste.ubuntu.com/643841/ uses [ -e /dev/null ] [07:20] cjwatson: ok, thanks; I'll upload that, and test tomorrow's alternate [07:21] tjaalton: you need to run update-grub-gfxpayload, but not update-grub. It matches any PCI device with class 3 [07:24] cjwatson: ok, thanks [07:25] kirkland: if you get reports about ecryptfs breaking today, please point people at udev 172-0ubuntu3 and mountall 2.30 [07:26] $HOME, sweet $HOME [07:27] good morning [07:27] hey dholbach *hug* [07:31] * dholbach hugs pitti back [07:38] anybody with some Mono/autotools experience here? [07:39] I wonder why NotifyOSD's configure can find "Mono 2.0 GAC Mono.Posix.dll" although it's certainly installed [07:43] MacSlow: Got a pastebin? It's likely that it should instead be trying to find a 4.0 GAC Mono.Posix.dll. [07:45] RAOF, just tired the same with 4.0... didn't fix it [07:45] RAOF, what do you want to see pasted... configure.in, error-message, config.log? [07:45] error message and configure.{in,ac}, I guess. [07:46] Or I could just grab the source package, I guess - is it in the archive? [07:48] RAOF, bzr branch lp:notify-osd [07:50] RAOF, make sure to call it with like ./autogen.sh --with-examples=mono [07:51] RAOF, I've both (2.0, 4.0) version of libmono-posix-cil installed [07:51] I suspect you need to install libmono-cil-dev; that's what contains mono.pc. [07:53] RAOF, there' no corresponding -dev for libmono-posix2.0/4.0-cil [07:54] That's correct; it's a mono corelib. [07:54] RAOF, I'll try installing all mono-related -dev packages [07:55] You should *only* need libmono-posix$SOMETHING and libmono-cil-dev. [07:55] I'm just hunting down the other build-depends that I don't have, like libwnck-3-dev :) [07:57] RAOF, libnotify0.4-cil and libnotify-cil-dev you'll need too [07:57] So, it works for me with libmono-cil-dev and libmono-posix2.0-cil. [07:58] RAOF, here too now [07:58] RAOF, at least it compiles... I'll to my usual testing then... thanks! === calc is now known as Guest38036 [08:28] cjwatson: fixing yelp binary overrides (last CD build failure) [08:33] jbicha: thanks for this! === daker_ is now known as daker [09:16] what ho! [09:33] i have just updated oeniric as of this morning and libyelp0 installation breaking colliding with libyelp ? [09:33] is this a known issue, or do i need to report same [09:39] apw: known issue, bug 810258 [09:39] Launchpad bug 810258 in yelp (Ubuntu) "package libyelp0 3.1.1-0ubuntu1 failed to install/upgrade: trying to overwrite /usr/lib/libyelp.so.0.0.0, which is also in package yelp 3.0.3-0ubuntu2" [Undecided,Confirmed] https://launchpad.net/bugs/810258 [09:39] 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] apw: Out of interest, have you rebooted following the update? [09:51] Daviey, nope, i have just apt-get install -f 'd my way to a completed install [09:51] Daviey, should i be scared, as i would now reboot [09:51] apw: so, i hit the same yelp bug.. but didn't -f install.. power died, and not it's failing to boot. [09:52] It's not registering as a successfull boot after waiting, as hard powercycle is showing grub menu. [09:52] (not a kernel issue tho, as prior ones are working) [09:52] are NOT working rather [09:52] yelp being broken won't mess up your boot [09:52] Daviey, wekk t [09:53] Daviey, well the first two things it did after the -f were mountall and libdbus [09:53] 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] so i'll reboot and see if the completed install works [09:53] its a machine i can live without [09:54] wish i could say the same :) [09:54] 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] Daviey, ok so mine rebooted and logged in just fine, so you will need to complete the install [09:55] Daviey, can you select recovery boot from the menu? that should give you the option to fix it i think [09:57] 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] yeah i suspect its mountall [09:59] super [10:22] 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:22] Launchpad bug 810270 in isc-dhcp (Ubuntu Oneiric) "AppArmor profiles need updates for /var/run → /run" [High,Triaged] https://launchpad.net/bugs/810270 [10:25] doing dist-upgrade today: [10:25]