| === sconklin is now known as sconklin-gone | ||
| * psusi wishes he could figure out what package upgrade keeps reinstalling his grub wrong... default install works, but some upgrade keeps reinstalling it without the lvm module.. doesn't look like kernel upgrades reinstall grub.. | 00:58 | |
| === bjf is now known as bjf-afk | ||
| wgrant | psusi: How do you work around that? My grub upgrades have been failing for a couple of weeks due to apparently missing LVM support. | 01:16 |
|---|---|---|
| psusi | wgrant, boot from the livecd in text mode, install the lvm2 package, mount the filesystem, chroot into it and reinstall grub | 01:19 |
| wgrant | psusi: Interesting. I've tried that, but it still complains that there's no mapping for my root LV. | 01:20 |
| lifeless | wgrant: failing how ? | 01:20 |
| lifeless | wgrant: do you mean failing to boot, or failing to install grub ? | 01:20 |
| psusi | wgrant, did you put a mapping for it in /boot/grub/devices.map? | 01:20 |
| wgrant | Failing to install GRUB. Sounds like a different failure mode. | 01:20 |
| psusi | lifeless, I don't even get anything that indicates that grub is being reinstalled... just don't boot because it can't find the lv... get a rescue shell and thats it... ls shows no lvm lvs | 01:21 |
| wgrant | psusi: No -- should I need to? | 01:21 |
| wgrant | I should try a recent installer and see if it works. | 01:21 |
| psusi | wgrant, I dunno, I do... | 01:21 |
| lifeless | psusi: and is lvm in the initramfs ? | 01:21 |
| lifeless | psusi: can you do lvm pvscan ? | 01:21 |
| psusi | lifeless, yes... it's just grub that breaks | 01:21 |
| wgrant | Karmic and Lucid ~alpha2 both hate something about my VG and fail to install GRUB2. | 01:21 |
| psusi | lifeless, don't need to, once I get grub fixed the system boots fine | 01:22 |
| lifeless | psusi: uhm, if lvm is in the initramfs, and it boots to the intiramfs busybox shell, its not grub thats the problem. | 01:22 |
| psusi | lifeless, I meant I get a grub rescue prompt, not busybox shell | 01:22 |
| psusi | so it appears that something rebuilds the grub core image without the lvm module then installs it... I reinstall grub and its fine... at first I was manually rebuilding the core image with the lvm module thinking it was a problem with grub-install not detecting lvm was in use, but it isn't... it correctly detects it and builds it in when I Just run grub-install '(hd0)' | 01:25 |
| psusi | I reconfigured the grub package which appeared to reinstall it and that was fine too.... reinstalled last kernel package, also fine... but something I just upgraded in the last few days broke it | 01:30 |
| === bjf is now known as bjf-afk | ||
| cjwatson | psusi: FWIW you should not need /boot/grub/device.map at all right now | 01:39 |
| psusi | cjwatson, well, I do since I'm actually booting from sdc ;) | 01:40 |
| cjwatson | psusi: grub-install not including the lvm module would be because it fails to detect it as the appropriate abstraction module - I'd recommend putting 'set -x' at the top of /usr/sbin/grub-install, then capturing a log of the upgrade where it goes wrong | 01:40 |
| cjwatson | psusi: you still shouldn't need it if everything is working as specified | 01:40 |
| cjwatson | grub2 is meant to be entirely free of dependencies on device ordering now, and if that's not the case I want to fix it | 01:40 |
| psusi | cjwatson, thing is, it isn't... grub-install works fine... correctly detects lvm and puts in the module... I can see this because it worked, and also I turned on verbose mode for grub-mkimage when it calls it and its output indicated it put the lvm module in | 01:41 |
| psusi | cjwatson, how's it know which disk to install to then? | 01:41 |
| cjwatson | psusi: but it might be going wrong when called in some other path, for some reason | 01:41 |
| cjwatson | grub-pc/install_devices should be a /dev/disk/by-id/ path equivalent to /dev/sdc | 01:41 |
| cjwatson | (in debconf) | 01:41 |
| lifeless | cjwatson: is it not possible to just include all the modules ? | 01:41 |
| cjwatson | lifeless: it's not a good idea because there are size constraints | 01:42 |
| lifeless | first cylinder? | 01:42 |
| cjwatson | yes | 01:42 |
| lifeless | mmm | 01:42 |
| psusi | cjwatson, you know, maybe that's the problem... I think my grub debconf before had an EMPTY list of devices to install to | 01:42 |
| lifeless | has anyone considered having a grub partition | 01:42 |
| cjwatson | yes, it's been done | 01:43 |
| cjwatson | we set it up that way by default on GPT - but not everyone has the partition | 01:43 |
| lifeless | ok | 01:43 |
| psusi | cjwatson, I think I left it blank initially because I didn't want any auto reinstalling.... but maybe an empty list causes it to go wrong? | 01:43 |
| cjwatson | and stressing the partition table algorithms with an extra partition by default on DOS partition tables is a pain for other reasons | 01:43 |
| lifeless | what machiens ship with EFI at the moment, just macs ? | 01:43 |
| slangasek | cjwatson: do you think ubuntu-archive-tools would be an ok place to add a new script for batch-adding EC2 AMIs to the ISO tracker? | 01:43 |
| cjwatson | lifeless: GPT != EFI | 01:43 |
| lifeless | cjwatson: I thought that EFI was needed to boot GPT though ? | 01:43 |
| cjwatson | slangasek: sounds ok, there or cdimage | 01:43 |
| cjwatson | lifeless: no | 01:44 |
| slangasek | cjwatson: ok | 01:44 |
| lifeless | cjwatson: ah | 01:44 |
| psusi | it would be nice if it just built all modules in when installing on gpt with the grub partition | 01:44 |
| cjwatson | that's a lie the EFI manufacturers tell you | 01:44 |
| slangasek | heh :) | 01:44 |
| lifeless | cjwatson: ok; so - what BIOSes boot GPT in consumer machines ? | 01:44 |
| psusi | lifeless, all of them... the bios just blindly loads sector 0 | 01:44 |
| cjwatson | psusi: yes, it's possible that could break it; that's why I'm asking for a log of the *upgrade* where it breaks with set -x in grub-install, not just of a single grub-install run | 01:44 |
| cjwatson | lifeless: the GPT spec includes a legacy MBR | 01:45 |
| lifeless | gotcha | 01:45 |
| cjwatson | sorry, "protective MBR" | 01:45 |
| cjwatson | psusi: wouldn't go quite that far - some BIOSes check for a valid MBR partition table | 01:45 |
| psusi | hrm... I'll see if I can empty the list back out with a reconfigure and see if that replicates the problem.... and I'll get the log | 01:45 |
| cjwatson | which is why GPT specifies the PBMR | 01:45 |
| cjwatson | *PMBR argh | 01:45 |
| lifeless | :) | 01:45 |
| psusi | cjwatson, well, true... but when they find it they load an execute, don't care if a gpt table follows ;) | 01:46 |
| cjwatson | psusi: right, *if* they find it. :-) | 01:46 |
| cjwatson | just saying, there does have to be something there that looks enough like an MBR to fool some BIOSes | 01:46 |
| psusi | cjwatson, so edit grub-install and add a -x to the shbang line? | 01:48 |
| psusi | or set -x on its own line? | 01:48 |
| cjwatson | psusi: better to put 'set -x' somewhere just below | 01:48 |
| psusi | k | 01:48 |
| cjwatson | wgrant: I fixed at least one cause of that in grub2 1.98-1ubuntu2. of course there may be others. | 01:49 |
| cjwatson | wgrant: you do have to have /proc and /sys mounted when upgrading grub-pc, in case that isn't stating the obvious ... | 01:49 |
| === dendrobates is now known as dendro-afk | ||
| psusi | yea, looks like it isn't running it when I reinstall grub-pc after reconfiguring it to empty the list of devices | 01:50 |
| cjwatson | of course grub-pc explicitly warns in that configuration | 01:51 |
| cjwatson | but I'm sure some people are clever and ignore the warning ;-) | 01:51 |
| cjwatson | still, I'd prefer it didn't break in that case | 01:52 |
| psusi | then again, when I put sdc back in the device list, I don't get anything either | 01:52 |
| psusi | set -x makes the shell stop and tell you what it is about to do and ask you to confirm and single step throuhg the script right? | 01:52 |
| wgrant | cjwatson: I'm booted normally, so yes, they are mounted. Do I have to do anything to force it to update its mappings? | 01:52 |
| cjwatson | wgrant: you shouldn't - it should work it out automatically | 01:53 |
| wgrant | Because still I get http://pastebin.ubuntu.com/410329/ | 01:53 |
| cjwatson | wgrant: it might be worth just deleting /boot/grub/device.map (keep a copy for later analysis) | 01:53 |
| wgrant | I upgraded about half an hour ago. | 01:53 |
| * wgrant tries. | 01:53 | |
| cjwatson | it shouldn't normally need it any more | 01:53 |
| cjwatson | psusi: no | 01:53 |
| cjwatson | RTFM :-) | 01:53 |
| psusi | oops, it wiped out the -x when I reinstalled the package ;) | 01:54 |
| psusi | yea, verbose output, looks like it's detecting it when I put the device back in the auto install list with reconfigure | 01:54 |
| cjwatson | I'm not interested in that | 01:55 |
| cjwatson | well, probably not | 01:55 |
| psusi | the strange thing is that I'm pretty sure the list was empty before so it never should reinstall | 01:55 |
| cjwatson | "never reinstall" is a bit of a myth with grub2 right now | 01:55 |
| psusi | ? | 01:55 |
| cjwatson | it often updates the stuff in /boot/grub/ anyway | 01:56 |
| psusi | btw, how does that get populated on a normal install? and what if the block device changes? | 01:56 |
| cjwatson | so if you tell it to never reinstall, it can get out of sync. that's why it's NOT RECOMMENDED IN BIG LETTERS unless you really know what you're doing. | 01:56 |
| cjwatson | grub-install populates it, normally | 01:56 |
| cjwatson | if the block device changes, grub-pc.postinst should notice and reask | 01:56 |
| psusi | could the conf be subtly different when I empty the list after populating it vs its default state before? | 01:57 |
| cjwatson | I don't see how | 01:58 |
| cjwatson | hard data would help to reduce the need for speculation. :-) | 01:58 |
| psusi | because I don't recall ever answering that question before today | 01:58 |
| psusi | I'm trying to reproduce it to get some hard data, but now I can't make it fail ;) | 01:59 |
| cjwatson | I think you must be mistaken. It's really very careful indeed to forcibly ask you if that question is left blank | 01:59 |
| cjwatson | I could be wrong, but ... | 01:59 |
| psusi | when I originally installed I was not using lvm and I don't recall being asked that question | 01:59 |
| psusi | installed with ubiquity before without lvm, then migrated to lvm | 01:59 |
| cjwatson | oh, sure, it's set on initial installation | 01:59 |
| cjwatson | but I don't see how it could end up blank | 02:00 |
| cjwatson | and you explicitly said above: | 02:00 |
| cjwatson | 01:43 <psusi> cjwatson, I think I left it blank initially because I didn't want any auto reinstalling.... but maybe an empty list causes it to go wrong? | 02:00 |
| cjwatson | were you misremembering up there? | 02:00 |
| psusi | then today after it botched up again, I ran dpkg-reconfigure and the list appeared to have no devices checked, so I checked sdc and now everything seems fine... even when I uncheck it again | 02:00 |
| cjwatson | well, not sure I can help then - I guess I'll need to wait for somebody who can reproduce it | 02:01 |
| psusi | I assumed I had done it on purpose since it was blank... but now that I think about it I don't think I ever saw that question before, and shouldn't have unless I ran a reconfigure before right? | 02:01 |
| cjwatson | it's asked when disks change, and in some cases on upgrade from karmic | 02:01 |
| cjwatson | (the cases that can't be worked out reliably automatically) | 02:01 |
| cjwatson | I suppose you no longer have a raw copy of what the variable was before, via something like debconf-show | 02:02 |
| psusi | hrm.. I did add the SSD then have lvm migrate the root fs over and reinstalled grub to boot from it... | 02:02 |
| psusi | but that was a manual grub-install, not reinstalling the package, so no debconf | 02:04 |
| cjwatson | well, in that case the old by-id values would have been invalid when you ran dpkg-reconfigure, and it would have discounted the old values, making it appear empty | 02:04 |
| psusi | aha | 02:04 |
| cjwatson | should've asked on the first upgrade of grub-pc though | 02:04 |
| cjwatson | but perhaps there wasn't one | 02:05 |
| psusi | ahh, so it stores the /dev/disk/by-id value too so it can check if it has changed? | 02:05 |
| cjwatson | it stores only the by-id value | 02:06 |
| cjwatson | what it shows you in the UI is a different matter | 02:06 |
| psusi | hrm.... because the by-id didn't change when I migrated the fs to the new ssd | 02:06 |
| cjwatson | I don't believe you | 02:07 |
| cjwatson | do you mean by-uuid? | 02:07 |
| cjwatson | by-id is tied to the hardware | 02:07 |
| psusi | either one I think | 02:07 |
| psusi | not for lvm | 02:07 |
| psusi | at least I don't think it is | 02:07 |
| cjwatson | oh, right | 02:08 |
| cjwatson | but you just said you were installing to sdc, not to the LVM | 02:08 |
| psusi | yea, I set (hd0) to be sdc in devices.map | 02:09 |
| cjwatson | so why does the by-id for the LVM bits matter? | 02:09 |
| psusi | good point... so if it stored the by-id before, then I changed hd0 in devices.map, could that confuse it? | 02:10 |
| psusi | because before the ssd hd0 was /dev/mapper/nvidia_blah | 02:10 |
| cjwatson | messing about with device.map is certainly not recommended. I don't know that I see how it could have confused it in this case, but it sounds like you've been doing some pretty odd things. | 02:10 |
| psusi | hehehe, you got that right ;) | 02:11 |
| cjwatson | the packaging should be *completely ignoring* hd0 etc. | 02:11 |
| psusi | hell, at one point I even tried booting using an lvm snapshot as the root | 02:11 |
| cjwatson | there's no way that stuff can be made reliable, so we don't use it any more | 02:11 |
| cjwatson | the only effect of it is to cause there to be a different value in the fallback 'set root=' commands in grub.cfg, which isn't used anyway unless there's some catastrophe that makes UUIDs unusable | 02:12 |
| cjwatson | which probably means the fs isn't usable either | 02:12 |
| psusi | yea... I've been wondering about that... what happens to search when there's more than one fs found with the same uuid? like if you have an lvm snapshot? | 02:13 |
| cjwatson | grub's built-in LVM support probably doesn't understand snapshots? | 02:14 |
| psusi | it seems to see the snapshot, but not understand the exception list so it just looks like a duplicate of the original, iirc | 02:14 |
| cjwatson | but if it does, ignoring snapshots is probably the right fix, otherwise weirdness will probably ensue | 02:14 |
| psusi | I've been thinking of looking into fixing that since it would be nice if you could snapshot then upgrade and have the choice of which version to boot until you know it works | 02:15 |
| cjwatson | seeing as the boot image needs to be in sync with /boot/grub/, I'd rather it just ignored snapshots | 02:17 |
| cjwatson | that seems more likely to be useful | 02:17 |
| psusi | what do you mean needs to be in sync with /boot/grub? | 02:17 |
| cjwatson | the ABI between grub's kernel image installed to the boot record and the modules in /boot/grub is not stable | 02:18 |
| cjwatson | if they end up at different versions, you often get hosed | 02:18 |
| psusi | ohh | 02:18 |
| cjwatson | normally this is not too much of a problem since it's grub-install that updates the modules in /boot/grub/ - the master copies live under /usr/lib/grub/ | 02:22 |
| cjwatson | BUT, if you have grub installed to one device and then grub-install to some different device, the grub kernel image on the first device and /boot/grub/ may then be out of sync | 02:22 |
| psusi | right... but if you did that in a snapshot, it would update only the snapshot copy, then modify the core, which may not be able to then use the original /boot | 02:22 |
| cjwatson | so you have to be somewhat careful about consistency when using grub on multiple-disk systems | 02:22 |
| cjwatson | indeed, and I don't think that the case for installing grub on snapshots is particularly compelling (note that this is independent from *booting* the snapshot, which you can do with just grub.cfg changes) | 02:23 |
| psusi | yea, just have to point it to the snapshot root to load the kernel image from, and change the root parameter to the kernel | 02:24 |
| slangasek | lamont: what's an 8-letter word in ia64 for "return"? :) (bug #555127) | 02:39 |
| ubottu | Launchpad bug 555127 in xulrunner-1.9.2 "build failure on ia64" [High,Confirmed] https://launchpad.net/bugs/555127 | 02:39 |
| cjwatson | psusi: so I suppose something like http://paste.ubuntu.com/410341/ | 02:40 |
| psusi | cjwatson, might be easier to check the status bits... o gets set on the origin and s on the snapshot | 02:42 |
| cjwatson | psusi: that appears to be only in lvs output and the like, which isn't available to grub | 02:44 |
| cjwatson | it has to work with the raw metadata header | 02:45 |
| cjwatson | but if I've missed something, patch welcome :-) | 02:45 |
| psusi | ahh, figured there was a flags dword somewhere in the nitty gritty | 02:45 |
| cjwatson | doesn't seem to be, the display code does stuff like | 02:45 |
| cjwatson | else if (lv_is_origin(lv)) | 02:45 |
| cjwatson | repstr[0] = 'o'; | 02:45 |
| cody-somerville | cjwatson, You wouldn't happen to know off the top of your head the partman bug where if you have a sdcard drive that always shows up as /dev/sdb regardless if theres a card or not in it and then you boot from a usb device (which will show up as /dev/sdc) partman will fail looking for /dev/sdb1? | 02:45 |
| cjwatson | so in fact I think I'm checking the wrong thing there | 02:46 |
| psusi | cjwatson, and what's lv_is_origin do? | 02:46 |
| cjwatson | cody-somerville: is preseeding involved? | 02:46 |
| cody-somerville | Yes. | 02:46 |
| cjwatson | psusi: lots of indirection :) | 02:47 |
| cjwatson | cody-somerville: do I get to see? | 02:47 |
| cjwatson | also logs? | 02:47 |
| cody-somerville | cjwatson, https://pastebin.canonical.com/30185/ | 02:48 |
| cjwatson | cody-somerville: (TBH I'd rather you filed new bugs rather than trying to find existing bugs - I can always mark them as duplicates) | 02:48 |
| cody-somerville | cjwatson, https://launchpad.net/bugs/466616 | 02:49 |
| ubottu | Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/466616) | 02:49 |
| cjwatson | cody-somerville: odd. any local modifications to the installer here? | 02:57 |
| Terminus | hello. question regarding pam-config, should all possible modules be stackable? want to know before i file a bug for that on samba. | 02:58 |
| Terminus | the current winbind pam-config prevents modules of lower priority from stacking. | 02:59 |
| slangasek | Terminus: they should, there's a bug, I've just fixed this in the Debian package's svn - please file a bug report | 02:59 |
| slangasek | I didn't realize it would affect any modules in practice, or I would've filed it | 03:00 |
| Terminus | slangasek: basically change requisite to [success=end default=ignore] right? | 03:00 |
| slangasek | yep | 03:00 |
| cody-somerville | cjwatson, It is a custom d-i build (just to include a few udebs), but no modifications to the partman udebs | 03:00 |
| Terminus | slangasek: well, i don't know if it would affect any other modules either... this is only for common-password btw. | 03:01 |
| Terminus | everything else seems to stack properly. | 03:01 |
| cjwatson | cody-somerville: ok, I ask because I can't find any calls to sfdisk anywhere in partman | 03:01 |
| slangasek | Terminus: yep, I know | 03:01 |
| Terminus | okidokie then. bug report it is. | 03:01 |
| slangasek | Terminus: when it's filed, please throw me the bug number :) | 03:02 |
| cody-somerville | cjwatson, Ah, interesting. I think I might know what that is. | 03:02 |
| cjwatson | cody-somerville: oh? | 03:02 |
| cody-somerville | cjwatson, custom recovery installer stuff. I assumed this build Steve tested didn't have it but it appears it does. | 03:03 |
| cody-somerville | cjwatson, I'll get QA to test a standard Ubuntu image with that preseed file and see if they can reproduce. | 03:03 |
| cjwatson | ah. y'all broke it then? :-) | 03:03 |
| cody-somerville | cjwatson, in the case Steve tested, most likely. | 03:04 |
| cjwatson | AFAICS the only things in d-i that call sfdisk are grub-installer and lilo-installer, both of which run rather later than partman | 03:04 |
| Terminus | slangasek: filed. bug #556996 | 03:06 |
| ubottu | Launchpad bug 556996 in samba "winbind pam-config potentially breaks stacking with modules of lower priority in common-passwd" [Undecided,New] https://launchpad.net/bugs/556996 | 03:06 |
| cody-somerville | cjwatson, Sorry. I should have spotted that myself. Thanks for taking a look. | 03:06 |
| Terminus | nice. | 03:06 |
| Terminus | !botsnack | 03:06 |
| ubottu | Yum! Err, I mean, APT! | 03:07 |
| cjwatson | slangasek: don't suppose this would be the cause of bug 556785 too? | 03:08 |
| ubottu | Launchpad bug 556785 in shadow "Passwd in Ubuntu Lucid has started giving errors since last update" [Undecided,New] https://launchpad.net/bugs/556785 | 03:09 |
| cjwatson | seems a stretch, but ... | 03:09 |
| slangasek | cjwatson: unlikely; that's probably a duplicate of the bug ttx fixed in the samba update this morning | 03:09 |
| slangasek | which is related, except for the part where it's already fixed | 03:10 |
| cjwatson | ok | 03:10 |
| Terminus | slangasek: ah... the passwd problem? filed a bug on that one too with the comment on stacking as well but it was marked duplicate. | 03:11 |
| slangasek | right | 03:11 |
| Terminus | while we're talking about this, pam_mkhomedir.so isn't suitable for inclusion in the winbind pam-config, right? | 03:12 |
| slangasek | Terminus: I wouldn't think so, since a) not everyone necessarily wants it, b) pam_winbind supports its own mkhomedir option | 03:20 |
| slangasek | Terminus: I think it would be better for libpam-modules to ship a (disabled-by-default) profile for pam_mkhomedir | 03:21 |
| Terminus | slangasek: yeah, that would be nice. only difference between mkhomedir and pam_mkhomedir.so is that the latter uses /etc/skel... | 03:23 |
| slangasek | ah | 03:26 |
| slangasek | could you file a wishlist bug on pam for this, too? | 03:26 |
| Terminus | slangasek: sure. which package though? | 03:27 |
| slangasek | 'pam' :) | 03:27 |
| Terminus | ok. hehe | 03:28 |
| Terminus | still have another bug to file about libpam-mount having problems creating directories. keep on forgetting this one. >_< | 03:32 |
| Terminus | slangasek: i see you're also subscribed to bugs for libpam-mount. i've filed two bug reports there if you're interested, bug #556239 and bug #557025 | 05:09 |
| ubottu | Launchpad bug 556239 in libpam-mount "mounting cifs uses uid and gid options by default" [Undecided,New] https://launchpad.net/bugs/556239 | 05:09 |
| ubottu | Launchpad bug 557025 in libpam-mount "pam_mount.so chown to user when creating directory fails" [Undecided,New] https://launchpad.net/bugs/557025 | 05:09 |
| slangasek | Terminus: I'm afraid I'm unlikely to be much help on those; the XML config file format gives me the heebie-jeebies, I'm only subscribed to libpam-mount to keep track of any fallout from the pam-auth-update integration | 05:54 |
| Terminus | slangasek: ah... yes. it's not exactly the most beautiful config file. i also see you've seen the mkhomedir wishlist. forgot about the default. | 06:04 |
| pitti | Good morning | 07:00 |
| Pslam | Ah i'm afternoon | 07:05 |
| dholbach | good morning | 08:17 |
| geser | good morning pitti and dholbach | 08:19 |
| dholbach | hey geser! :) | 08:20 |
| pitti | hey geser, how are you? | 08:20 |
| geser | I'm fine | 08:20 |
| m4rtin | morning all; any sponsors around to have a look at a patch for lucid regression in bash-completion? | 08:23 |
| === radoe_ is now known as radoe | ||
| bigon | could some one have a look at bug #549234 please? | 08:54 |
| ubottu | Launchpad bug 549234 in hellanzb "Please sync hellanzb (0.13-6) from debian unstable" [High,Confirmed] https://launchpad.net/bugs/549234 | 08:54 |
| === almaisan-away is now known as al-maisan | ||
| zyga | hello | 09:21 |
| zyga | mvo: hi | 09:21 |
| zyga | mvo: I'll try to fix the other bug today, I had update my know-how with dbus to get into that code properly | 09:22 |
| mvo | zyga: cool | 09:23 |
| zyga | mvo: I did one cool thing yesterday though, I rewrote command-not-found to be a dbus service | 09:35 |
| zyga | mvo: it's super fast and responsive now | 09:35 |
| lifeless | zyga: err | 09:35 |
| lifeless | zyga: why?! | 09:35 |
| zyga | lifeless: because it stays in memory | 09:36 |
| lifeless | zyga: I don't see why a dbus service has any reason to be faster, unless its using up memory for no purpose | 09:36 |
| zyga | lifeless: and python startup time is no longer an issue | 09:36 |
| zyga | lifeless: responsiveness == startup time mostly | 09:36 |
| zyga | lifeless: now it's giving you output in 0.021 seconds | 09:36 |
| lifeless | uhm | 09:36 |
| zyga | lifeless: previously it was 0.5 + | 09:36 |
| lifeless | command not found is 3 python files | 09:36 |
| zyga | lifeless: yeah but it opens several files, reads databases | 09:37 |
| zyga | lifeless: talks to apt | 09:37 |
| zyga | lifeless: all in all it's not free | 09:37 |
| lifeless | the databases are not python startup time though | 09:37 |
| lifeless | zyga: how much memory does it use | 09:37 |
| zyga | lifeless: true | 09:37 |
| zyga | lifeless: let me check | 09:37 |
| lifeless | there are good algorithms for fast string match search (where fast == examine a smal fraction of your database) | 09:38 |
| zyga | lifeless: I'll upload the package to my ppa though | 09:38 |
| zyga | lifeless: I know, I measured what's long | 09:38 |
| lifeless | I think it would be a _much_ better idea to use those, than to waste memory. | 09:38 |
| zyga | lifeless: python startup | 09:38 |
| zyga | lifeless: database initialization (cold cache, stating lots of files) | 09:38 |
| zyga | lifeless: and the minor part was actually giving you the output | 09:38 |
| lifeless | zyga: sure; thats why I'm saying change the algorithms in the db you use. | 09:39 |
| lifeless | search requires an appropriate data structure. | 09:39 |
| geser | pitti: do I read it from the TB meeting log correctly that it is yet undecided if maverick is going to sync from testing or unstable (pending a discussion on the ubuntu-devel mailing list)? | 09:39 |
| zyga | lifeless: the database is good, really | 09:39 |
| pitti | geser: yes; well, the default mode is "unstable" | 09:39 |
| lifeless | zyga: then why are you stating lots of files? | 09:39 |
| zyga | lifeless: it's gdbm, there is just one lookup really | 09:39 |
| zyga | lifeless: python stats ~500s files on startup | 09:39 |
| zyga | lifeless: I stat 10 files to find the database and configuration | 09:40 |
| lifeless | zyga: it can, depending on what layout you have | 09:40 |
| lifeless | getting rid o the eff | 09:40 |
| lifeless | and the package would help | 09:40 |
| lifeless | go to a single module | 09:40 |
| zyga | lifeless: I encourage you to try to see how old c-n-f worked | 09:40 |
| zyga | eff? | 09:40 |
| lifeless | possibly even get rid of the python library altogether | 09:40 |
| zyga | lifeless: it's best to rewrite the client in C | 09:40 |
| lifeless | sorry, fingers haven't quite learnt this keyboard yet | 09:40 |
| lifeless | egg | 09:40 |
| geser | pitti: ok, will wait on the results from this discussion for how to set the default for requestsync for maverick (if the result doesn't come to late) | 09:41 |
| lifeless | zyga: I have looked ;) | 09:42 |
| zyga | lifeless: the new code is in lp:command-not-found, do check it out too | 09:42 |
| lifeless | zyga: anyhow, I really question the benefit of a continually running service, for something needed very rarely and only taking 0.5s today. | 09:43 |
| lifeless | zyga: I'll have a browse round the new code tomorrowish | 09:43 |
| zyga | lifeless: the service closes after period of inactivity | 09:43 |
| lifeless | zyga: does it ever get called twice in a row anyway ? | 09:43 |
| zyga | lifeless: huh? | 09:43 |
| lifeless | zyga: note that a second call is going to have nearly no python startup time anyway, because all the stuff being stated has its dentries in cache | 09:44 |
| zyga | lifeless: I know that having a warm cache is helpful | 09:44 |
| zyga | lifeless: but new code is much more responsive anyway | 09:44 |
| zyga | lifeless: next step is to rewrite the client into pure C | 09:44 |
| lifeless | zyga: its not clear to me /how/ it can be more responsive. | 09:44 |
| zyga | lifeless: and finally (maybe) integrate into bash | 09:45 |
| lifeless | cold cache it has to start the service up as well as do what it was doing before. | 09:45 |
| zyga | lifeless: because cold cache is not everything | 09:45 |
| zyga | lifeless: python + apt | 09:45 |
| lifeless | zyga: yes, but if the service *is not running* its still doing the same work, as the version in lucid at the moment, right ? | 09:45 |
| zyga | lifeless: yes, the initial startup time is same | 09:46 |
| zyga | lifeless: but after that it's only better | 09:46 |
| lifeless | hmm | 09:46 |
| zyga | I wrote the code yesterday and did some benchmarks | 09:46 |
| lifeless | ok | 09:46 |
| zyga | and it's really there | 09:46 |
| zyga | lifeless: I encourage fixes though | 09:46 |
| persia | zyga: Whilst you're fiddling with command-not-found, might you be able to make it also work when Contents.gz is on ports.ubuntu.com rather than archive.ubuntu.com? | 09:46 |
| zyga | lifeless: my goal is fast small and lean program | 09:46 |
| zyga | persia: it doesn't work like that | 09:47 |
| mvo | zyga: I would be interessted in the figure for C client without dbus | 09:47 |
| zyga | persia: database is the most difficult thing in the whole program | 09:47 |
| mvo | zyga: benchmark figures | 09:47 |
| zyga | mvo: I'll try to make them (it's in line with my new job anyway) | 09:47 |
| persia | zyga: Hrm? How does it work then, because it fails completely for armel and powerpc last I checked. | 09:47 |
| mvo | zyga: I'm not sure that dbus is worth it, its a good experiment, but it just does not feel right | 09:47 |
| zyga | persia: ask mvo :-) | 09:47 |
| zyga | mvo: why? | 09:48 |
| mvo | persia: right, it does not work for them, there is a data-collector running that builds the db and it needs access to a mirror | 09:48 |
| mvo | persia: its currently running on rookery | 09:48 |
| mvo | persia: all that is really needed is a mirror then those can be integrated | 09:48 |
| zyga | mvo: actually | 09:49 |
| zyga | mvo: current code does more, the service loads apt.cache | 09:49 |
| zyga | mvo: and gives you the summary of the package | 09:49 |
| mvo | zyga: a basic C client prototype should be pretty quick, no? | 09:49 |
| zyga | mvo: yes, I'll get to that | 09:49 |
| persia | mvo: So UnifiedDataExtractor/mirror/do-mirror isn't the place to fix this? | 09:49 |
| zyga | mvo: first the client, finally the service | 09:49 |
| mvo | persia: that would work too, just requires a bit of disk-space and bandwidth | 09:50 |
| zyga | persia: there is some room for improvement | 09:51 |
| zyga | mvo: (do you have the time to run the script I sent you some time ago?) | 09:51 |
| mvo | zyga: still not sorry :( | 09:51 |
| zyga | mvo: ok | 09:51 |
| mvo | zyga: I hope by the time beta-2 comes out | 09:51 |
| zyga | mvo: cool, no rush | 09:52 |
| persia | mvo: OK. That makes sense. Same issue as madison/rmadison in some ways. Thanks :) | 09:52 |
| mvo | persia: there is a spec to include it during the build process | 09:53 |
| mvo | persia: but it did not finish for lucid, maybe lucid+1, if LP makes it | 09:53 |
| persia | Oh, cool. In that case I'll delete my local branch, since there's no point in having it on my todo list if it's better done in LP. | 09:54 |
| mvo | persia: well, it would be nice to have it for lucid | 09:56 |
| mvo | persia: at least for armel | 09:56 |
| mvo | persia: all I need is a server to run the extraction on that has a lucid mirror of archive.ubuntu.com and ports.ubuntu.com | 09:56 |
| zyga | mvo, persia, lifeless: I have .deb files if you are interested in checking this | 09:58 |
| zyga | lifeless: 29M res, 49M virtual | 09:59 |
| lifeless | thats quite a bit for a netbook or smaller machines | 10:00 |
| zyga | lifeless: it's not different to what c-n-f had | 10:00 |
| zyga | lifeless: old version consumed the same amount of memory each time you made a typo | 10:00 |
| zyga | lifeless: (I work on a netbook all the time BTW) | 10:00 |
| zyga | lifeless: it's not perfect (especially for embeded) | 10:01 |
| lifeless | yes, but the memory is freed after | 10:01 |
| zyga | lifeless: but it's not worse really | 10:01 |
| lifeless | if you want to work on lower memory footprint, we could do that | 10:01 |
| zyga | lifeless: if you work in the shell it doesn't matter - the memory will be taken again in a moment | 10:01 |
| zyga | lifeless: I think that as long as your terminal is open c-n-f keeps starting and stopping all the time | 10:02 |
| zyga | lifeless: the service makes the process cheaper | 10:02 |
| zyga | lifeless: but to make one point clear - the new code can run without the service | 10:02 |
| zyga | lifeless: it's not that the interface requires the service ;-) | 10:02 |
| zyga | lifeless: on my machine empathy takes more memory | 10:03 |
| zyga | lifeless: then mono | 10:03 |
| zyga | lifeless: I'll try to tweak gc settings today, maybe we can get the memory level even lower | 10:03 |
| zyga | lifeless: (not counting firefox obviously - it takes all the memory) | 10:04 |
| zyga | lifeless: if we disable apt.cache() (it's a new feature) the service uses 9MB of memory | 10:06 |
| tseliot | mvo: do you know what happened in bug #552548 ? It looks like dpkg made a backup of the files in /etc/ati but didn't install the new files there e.g. they have amdpcsdb.default.dpkg-bak but no amdpcsdb.default | 10:28 |
| ubottu | Launchpad bug 552548 in fglrx-installer "fglrx broken after update to 2:8.721-0ubuntu7" [Medium,Triaged] https://launchpad.net/bugs/552548 | 10:28 |
| mvo | tseliot: for a falure like this it would be helpful to get /var/log/dpkg.log and /var/log/apt/term.log | 10:30 |
| tseliot | mvo: ok, I'll ask users to attach those files to the report, thanks | 10:31 |
| mvo | tseliot: thanks | 10:31 |
| mvo | tseliot: speaking of video drivers, update-manager has a check for SSE support before uprading nvidia-glx from hardy. that is still needed, right? for -173, 180, 185? | 10:32 |
| tseliot | mvo: let me check, I think they added back the support for SSE but I don't know to what driver. I'll let you know | 10:35 |
| persia | mvo: I have such a server, but would need somewhere to post the results. Does the architecture of the server matter (my armel mirror is on a powerpc machine, but I can netmount, etc.) | 10:37 |
| mvo | tseliot: thanks, I let it in for now | 10:37 |
| persia | mvo: Alternately, could we maybe run it on the primary archive server *before* the mirror split? | 10:38 |
| mvo | persia: arch does not matter as long as the debs are all there | 10:38 |
| mvo | persia: I guess so, I don't have access to this machine though afaik | 10:38 |
| persia | mvo: Do you need real access, or just to run a cronjob? | 10:38 |
| mvo | persia: just a cron job | 10:40 |
| * persia checks for the archive-admin-of-the-day | 10:41 | |
| persia | cjwatson: Do you know if the pre-split mirror has disk/processor to spare for such a cronjob? | 10:41 |
| persia | Would add support for armel/ia64/powerpc/sparc to command-not-found | 10:42 |
| cjwatson | it's pretty locked-down, I'd rather not run more code on it | 10:42 |
| cjwatson | and there'd be an issue with getting the results off | 10:42 |
| cjwatson | but ask IS? | 10:43 |
| tseliot | mvo: it looks like support for SSE is back in -173 so you can remove it from your blacklist | 10:48 |
| bdrung | pitti: around? | 10:51 |
| pitti | hi bdrung | 10:53 |
| mvo | tseliot: supports or requires? the check I have in update-manager is to ensure that the CPU has SSE support if the nvidia driver is in use (173,180,185). is that still a valid check? or will it fallback to some non-sse code if the cpu does not support it? | 10:54 |
| bdrung | pitti: can you un-blacklist pwdhash? asac and chrisccoulson agreed on it. | 10:55 |
| pitti | sure, I can; I'm just curious about the rationale? | 10:55 |
| chrisccoulson | pitti - bdrung has volunteered to maintain it ;) | 10:55 |
| asac | ack. bdrung is committed to maintain it and upstream is very responsive | 10:56 |
| pitti | right, but I thought the point was that it's much easier to use Firefox' automatic plugin upgrades than having to maintain it for three years in universe? | 10:56 |
| tseliot | mvo: right, I meant to say that they support non-sse cpus in 173 again (i.e. you can remove it from your list). You might want to add 195 to the blacklist instead (and keep the other versions) | 10:57 |
| pitti | asac, chrisccoulson, bdrung: unblacklisted | 10:58 |
| bdrung | pitti: but there are many benefits of having a package instead | 10:58 |
| chrisccoulson | thanks | 10:58 |
| bdrung | pitti: thanks | 10:58 |
| zyga | persia: if you and mvo manage to harvest the data for other arches | 10:58 |
| zyga | persia: do let me know | 10:58 |
| zyga | persia: I want to run a simple script on the archive to improve the quality of the harvested data in maverick and beyond | 10:59 |
| zyga | persia: also if you harvest the data with current technology please send me the scan.data file | 10:59 |
| persia | zyga: What sort of script? I can certainly generate local data, etc. | 11:00 |
| zyga | persia: let me dig it up | 11:00 |
| zyga | persia: the biggest quality problem with current c-n-f data is update-alternatives | 11:01 |
| zyga | persia: if you read the code you'll see what hackery we did to get some of that data out of the install scripts | 11:01 |
| zyga | persia: but it's time to fix the problem once and for all, we need more package metadata | 11:01 |
| zyga | persia: this metadata can be added over time but we need to know _all_ packages that use update-alternatives | 11:02 |
| zyga | persia: eventually I will file a bug for each package and add some data to the control file that says what update-alternatives are provided by each package | 11:02 |
| zyga | persia: then c-n-f will have perfect data and will never lie or miss a package | 11:03 |
| persia | XB-Alternatives-Provided: or similar? | 11:03 |
| zyga | persia: yes, something like that - does it already exists? | 11:03 |
| zyga | exist | 11:03 |
| persia | That's something you *definitely* want to discuss in Debian (or we miss ~14000 packages) | 11:03 |
| persia | It doesn't exist to my knowledge: that's just the format that would let it work without a policy bump. | 11:03 |
| zyga | persia: I realize that, I hope to meet some people at the next UDS, I'm not really sure how to approach this on the political/debian-and-ubuntu front | 11:04 |
| zyga | persia: I still believe in plain technology, I'll write a spec for this metadata, fix all the packages in ubuntu and hope debian syncs back | 11:05 |
| persia | zyga: It's not so much political/debian-and-ubuntu it's that such a change ought be done *in Debian*. We aren't going to be able to sensibly maintain that delta. | 11:05 |
| zyga | persia: right, I want debian to adopt the changes, I don't really know how debian syncs changes from ubuntu nowdays | 11:05 |
| persia | You really want to start in Debian for that. The chances you can get all those patches accepted is staggeringly low. | 11:05 |
| zyga | persia: I suspect that about 1000 packages could be using alternatives today so it's not an easy target | 11:06 |
| asac | pitti: so you already did the blacklisting/removing based on chrisccoulson extension list? nice. | 11:06 |
| zyga | persia: even if it's harmless one-liner per package? | 11:06 |
| pitti | asac: yes, yesterday | 11:06 |
| pitti | asac: might avoid a few people installing beta-2 and unsuported extension packages ;) | 11:06 |
| pitti | and likewise, I think u-m will clean up removed packages | 11:07 |
| persia | zyga: Yes, because that suddenly means that Ubuntu Developers have to manually merge every Debian upload for those 1000 packages, so it's something on the order of 500 developer-hours per cycle. | 11:07 |
| persia | Which is roughly equivalent to one person spending 20 hours a week doing nothing else at all. | 11:07 |
| zyga | persia: I see, well that does suck - I don't deny that | 11:07 |
| zyga | persia: as I said I hope to talk with some people to know how to execute this best, I'm not really familiar with debian | 11:08 |
| zyga | persia: and how to approach them to make this happen | 11:08 |
| asac | very good | 11:08 |
| zyga | persia: ultimately this could require updating debian packaging standards | 11:08 |
| persia | zyga: I'd suggest starting by contacting the Debian Maintainer of command-not-found, who likely can help develop a strategy. | 11:09 |
| zyga | persia: does debian have command-not-found today? | 11:09 |
| persia | (and yes, it will eventually need a policy bump if it's mandatory) | 11:09 |
| zyga | any debian devs around? ;-) | 11:09 |
| persia | zyga: Yes, in squeeze and sid. | 11:09 |
| zyga | persia: cool, let me check that package | 11:09 |
| cjwatson | the best way to make this work in Debian would be to figure out a way to solve Debian #43720 that's compellingly correct enough to overcome historical problems with its interface (cf. Debian #45614), and have it emit the appropriate headers somehow | 11:12 |
| ubottu | Debian bug 43720 in debhelper "add support for alternatives somehow (and other redundant requests)" [Wishlist,Open] http://bugs.debian.org/43720 | 11:13 |
| ubottu | Debian bug 45614 in debhelper "debhelper: dh_alternatives scripts?" [Wishlist,Open] http://bugs.debian.org/45614 | 11:13 |
| cjwatson | or, even better, add declarative alternatives to dpkg | 11:13 |
| tseliot | cjwatson, mvo: do you know why this user reproduced bug #555837 (getting an Exec format error) ? The script has a hashbang | 11:13 |
| ubottu | Launchpad bug 555837 in nvidia-common "package linux-image-2.6.32-19-generic 2.6.32-19.28 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/nvidia-common exited with return code 1" [Undecided,New] https://launchpad.net/bugs/555837 | 11:13 |
| cjwatson | tseliot: probably bug 430958 | 11:13 |
| ubottu | Launchpad bug 430958 in sigmundr "Merge the documentation branch with the docs series" [High,Fix released] https://launchpad.net/bugs/430958 | 11:13 |
| cjwatson | err | 11:14 |
| cjwatson | bug 512096 | 11:14 |
| ubottu | Launchpad bug 512096 in dpkg "[MASTER] Exec format error : package failed to install/remove : installation/removal script returned error exit status 2" [High,Fix released] https://launchpad.net/bugs/512096 | 11:14 |
| cjwatson | or else perhaps filesystem corruption. get them to send you a copy of that file | 11:14 |
| zyga | persia: found him, thanks for the suggestion | 11:15 |
| tseliot | cjwatson: ok, thanks | 11:15 |
| dyllan | anybody else having a problem with the network manager applet not working properly? | 11:15 |
| lifeless | you could also get that with a wrong-arch binary being called | 11:15 |
| lifeless | e.g. the interpreter, or something invoked, was actually amd64 on an i386 kernel | 11:16 |
| persia | lifeless: That actually works just fine if you have qemu-kvm-extras-static installed (but most folk don't) | 11:17 |
| pitti | lool: your recent logcheck sync added a "mimeconstruct" dependency, which is in universe, and also pulls in a whole slew of new perl modules (also in universe); should we revert the dependency or do the MIRs? | 11:26 |
| bdrung | pitti: pwdhash is uploaded and sits now in NEW | 11:34 |
| pitti | bdrung: thanks; will be processed during regular archive days | 11:35 |
| bdrung | what's the easiest way to get the source package name for a binary package name? | 11:39 |
| bdrung | (of a not possible installed package) | 11:39 |
| pitti | apt-cache show pkgname | 11:40 |
| pitti | Source: | 11:40 |
| pitti | (if that field is not there, it's identical to the binary name) | 11:40 |
| persia | PKG=foo apt-cache show $PKG | grep Source: | cut -d: -f2 || echo $PKG ? | 11:44 |
| bdrung | thanks | 11:44 |
| lifeless | bdrung: apt-get source pkg, ctrl-C | 11:47 |
| persia | apt-get --dry-run source plg ? | 11:47 |
| bdrung | lifeless: not a good idea | 11:47 |
| lifeless | bdrung: how so? | 11:47 |
| lifeless | persia: +1 | 11:48 |
| bdrung | k, --dry-run would work, but then i have to parse the output | 11:49 |
| lifeless | bdrung: you didn't specify machine-processable | 11:49 |
| lifeless | machine processable, a python script is probably best | 11:49 |
| bdrung | forgot to mention: for scripting ;) | 11:50 |
| wgrant | mdt bin2src! | 11:50 |
| persia | That works lovely, but has more dependencies :) | 11:51 |
| bdrung | wgrant: ? | 11:53 |
| wgrant | multidistrotools has a handy utility, but that's only really practical if you are using mdt for other purposes. | 11:53 |
| mvo | tseliot: thanks, so I make it check for 180, 185, 195 and SSE, correct? | 12:03 |
| tseliot | mvo: yes, that's correct. Thanks | 12:03 |
| mvo | tseliot: great, thanks. code is updated | 12:04 |
| tseliot | great :-) | 12:04 |
| === MacSlow is now known as MacSlow|lunch | ||
| apw | i have a couple of machine which have been updates as of today, and unlike a new install still have the bright light from above background instread of the new purple background in gdm | 12:33 |
| apw | does anyone know what package i am missing | 12:33 |
| arand | apw: plymouth, mayhaps? | 12:38 |
| apw | i get plymouth ok, its nice [sic] and purple, but then i get the older downlight on transition to X, not the default background | 12:38 |
| james_w | as part of gdm? | 12:39 |
| persia | apw: Are you sure you don't have some leftover setting? I had to manually change my preferred theme from (purged) human to the new one to get the new background. | 12:41 |
| === Tonio__ is now known as Tonio_ | ||
| === kdelogger is now known as apachelogger | ||
| apw | persia, no this machine is not customised as far as i know | 12:45 |
| apw | i try and keep it as virgin as possible while still being useful, so that i catch these sorts of things | 12:45 |
| persia | apw: I hadn't thought I'd set the background manually either :) | 12:45 |
| apw | its not the main background, as that is ok, its just in gdm | 12:45 |
| persia | Might be a bug in the detect-if-the-user-changed-something code though. | 12:45 |
| apw | just in that middle ground | 12:46 |
| apw | persia, any idea how i might change it | 12:46 |
| persia | apw: Actually, no. The way I used to know how to do it doesn't exist anymore. | 12:46 |
| apw | hrumph | 12:51 |
| * apw throws hit toys out of his pram ... "i want purple" | 12:51 | |
| persia | Dunno why precisely. That background makes my eyes hurt, being just ever so slightly out-of-focus | 12:52 |
| apw | persia, its not designed to be looked at ... silly | 12:54 |
| apw | persia, i have to agree its nasty on the eye if you stare at it | 12:55 |
| persia | What's the point of having the default interface be something that's not designed to be looked at again? | 12:55 |
| apw | its particularly vile behind this touchscreen which gives it a slightly sparkly feel | 12:55 |
| apw | persia, heh ... i'd ask the design team that | 12:55 |
| apw | but they never answer me | 12:55 |
| persia | If it was about it being interesting and artistic, I'll support it, but if it's specifically designed to make people want to change it, I question the motives. | 12:56 |
| lool | pitti: Argh, sorry about that; I guess we need to patch logcheck to use something else | 12:58 |
| lool | pitti: It's three calls to a /usr/bin helper to send emails in src/logcheck | 12:58 |
| apw | pitti, i have no idea what we are going to do about your lid thingy | 12:58 |
| lool | pitti: If you have suggestions for a replacement apart of sendmail, I'm happy to hear about them! | 12:58 |
| * lool needs to run now | 12:58 | |
| pitti | apw: at this point it's probably between moving the logic into xorg, or fixing non-native resolutions, or refining the lid logic in the kernel; but I have no idea which of those is easier | 12:59 |
| apw | lid matching is just plain broken on a huge number of systems, so upstream has pulled back from the lid detection in the kernel as unworkable | 12:59 |
| pitti | seb128: you are running with a docked laptop, too, right? does it still work with current kernel? | 12:59 |
| pitti | apw: right, understood | 12:59 |
| seb128 | pitti, define work | 12:59 |
| apw | it seems windows doesn't need the initial state, so most bioses are broken wrt to the initial value | 13:00 |
| pitti | seb128: my DVI screen just switches off as soon as X starts | 13:00 |
| apw | pitti, is it _off_ or blank | 13:00 |
| pitti | apw: off | 13:00 |
| apw | why would it ever be off if its there | 13:00 |
| seb128 | pitti, I don't have that issue with -19 | 13:00 |
| pitti | in very technical terms, the standby light is yellow, not green | 13:00 |
| seb128 | I do get screen being blank after user switch though | 13:00 |
| seb128 | and no way to turn it back on until xorg restart | 13:01 |
| pitti | seb128: you get the correct resolution on the DVI? is the internal screen on as well (in gdm)? | 13:01 |
| seb128 | no | 13:01 |
| apw | i would expect you to find your lcd is on, and so is your dvi and that your desktop is spread over both | 13:01 |
| seb128 | I get some 1024 instead of 1900 | 13:01 |
| apw | not what you want either but, that is what i'd expect | 13:01 |
| seb128 | but I fix it with the gnome capplet | 13:01 |
| seb128 | sorry time for a phone interview, be back in a bit | 13:01 |
| pitti | apw: if it just affects my particular system, it's probably not such a biggie (I can put an xrandr configuration into gdm's home dir), but at this point I don't know how many systems are affected | 13:02 |
| apw | pitti, i suspect its more than you ... | 13:02 |
| apw | am testing myself here as wel speak | 13:02 |
| pitti | apw: in karmic both monitors had 1024x768, which was ugly, but at least it worked (that also worked with KMS; lots of mode switches, but *shrug*) | 13:02 |
| seb128 | pitti, I do boot with laptop lid close though | 13:03 |
| seb128 | not sure if that makes a difference | 13:03 |
| pitti | seb128: yes, I keep it closed all the time | 13:03 |
| ion | persia: The blurry font rendering Ubuntu uses nowadays don’t bother you, though? | 13:03 |
| pitti | seb128: in fact, opening and closing again fixes it, since that triggers the lid actions in X | 13:03 |
| apw | pitti, do you get gdm on both? | 13:03 |
| pitti | apw: on the internal one; DVI is off | 13:03 |
| apw | pitti, yeah thats what upstream found, open/close transitions work everywhere but initial 'is open/closed' is completely bust | 13:03 |
| apw | i wonder how win7 does it as it clearly doesn't use that | 13:04 |
| pitti | apw: if I open the lid and close it again, X's lid actions fix the LVDS first, and then DVI | 13:04 |
| persia | ion: I use a low enough DPI (72) that it's not so bad for me. | 13:04 |
| apw | pitti, do you even get grub on DVI ? | 13:04 |
| pitti | apw: yes, grub/plymouth/VTs work | 13:05 |
| persia | ion: If someone optimises for beauty over number of simultaneous elements on the screen, you may have found a kindred soul. | 13:05 |
| pitti | apw: but as soon as X wants to switch to 1024x768, DVI goes off | 13:05 |
| ion | Not having bothered to make a real solution, i just run sudo perl -i -pwe 's/\000\Klcddefault\000/lcdlegacy\000\000/g' '/usr/lib/gnome-settings-daemon-2.0/libxsettings.so after g-s-d updates. :-P | 13:05 |
| pitti | apw: during boot (grub/plymouth/VTs), DVI is in 1280x800 (which is the LVDS's resolution) | 13:05 |
| apw | pitti, i get all that _and_ gdm on my VGA port with the lid closed | 13:06 |
| pitti | apw: X has never liked 1280x800, and seems to pick 1024x768 as a "compromise" for both displays | 13:06 |
| apw | heh yeah this is a squarer one so i get more native looking res | 13:06 |
| pitti | apw: I'm just building some postgresql updates, but after that I can try booting with VGA instead of DVI | 13:07 |
| apw | pitti, ok with the lid closed i get desktop out on VGA | 13:07 |
| pitti | apw: also on LVDS? | 13:07 |
| apw | its gone into mirror mode by default it seems | 13:07 |
| pitti | right | 13:07 |
| apw | when i open the lid, its on both the same | 13:07 |
| pitti | that's what it has done here until karmic | 13:07 |
| apw | which is not what i expected | 13:07 |
| pitti | apw: I still see whether the screen is on or off when the lid is closed (there's a small gap to look through) | 13:08 |
| apw | unfortuanatly it doesn't have anything better, dvi or hdmi | 13:08 |
| apw | pitti, it looked to be black on mine | 13:08 |
| pitti | how wonderfully consistent all this stuff is :-) | 13:08 |
| apw | ahh both on 1024x768 as you conjectured | 13:09 |
| pitti | apw: mind putting up your /var/log/Xorg.0.log somewhere while gdm is up after booting (with the lid closed)? | 13:09 |
| apw | non-native for both ... gah | 13:09 |
| apw | pitti, ahh its a x800 here too, so same mangling | 13:09 |
| pitti | apw: so I guess moving the lid logic into X will just lead to the very same problems then, and wouldn't help at all | 13:10 |
| apw | who chose to mirror i wonder | 13:10 |
| * apw isn't sure he would expect the kernel to be making that decision | 13:10 | |
| pitti | apw: X, I mean | 13:10 |
| pitti | but without the lid state it's not that obvious | 13:11 |
| ion | This was discussed here recently. bryce knew about the X logic that applies. | 13:11 |
| pitti | if you attach a beamer and have the lid open, you certainly want cloning by default | 13:11 |
| pitti | with an external monitor you'd rather want only that, in full resolution | 13:11 |
| apw | i used to gfind VGA and HDMI did differnt things, one mirrored by default and one extended desktop by default | 13:12 |
| persia | Just as a minor complication: consider "convertible" devices where the lid state can be "closed" and the display still viewable (which often triggers a landscape/portrait change in other environments). | 13:12 |
| apw | but i think i found they all extended by default after | 13:12 |
| pitti | back in karmic I used to have an xorg.conf which forced resolution; I might just dig that back out of my bzr tree then.. | 13:12 |
| pitti | but it doesn't help for the broken live system boot, of course | 13:13 |
| apw | pitti, well we need to know if its different for DVI than VGA, if so then its likely not right | 13:14 |
| apw | pitti, OH have you tried disabling you LVDS by default? | 13:14 |
| pitti | apw: how? | 13:15 |
| apw | you need to know the name of the LVDS as known to drm | 13:15 |
| pitti | apw: that's in the kernel log and easy to find out | 13:15 |
| apw | kernel boot line video=LVDS-1:d | 13:15 |
| pitti | apw: with a kernel option? | 13:15 |
| pitti | right | 13:15 |
| apw | you can also see it in /sys/class/drm | 13:15 |
| apw | be interested to know if that could help | 13:15 |
| pitti | /sys/class/drm/card0-LVDS-1 | 13:15 |
| apw | so LVDS-1 is the right name i am told ... never tried it myself (as yet) | 13:16 |
| apw | actually will do it now as i have a test setup | 13:16 |
| pitti | apw: I guess xorg.conf is a better solution, though, since it also works in undocked mode | 13:16 |
| pitti | if I undock, I actually do want to use the LVDS :) | 13:16 |
| pitti | apw: but I'll try that for completeness | 13:16 |
| pitti | c'mon psql, build faster | 13:16 |
| apw | pitti, yeah be nice to know if then open close enables it as i would expect | 13:17 |
| apw | pitti, i am concerned that KMS generally leads us to a need to have default options settable for video things in the kernel | 13:18 |
| apw | pitti, and wonder if we are getting to where the user tools need to know that and how to do it | 13:18 |
| apw | pitti, ok video=LVDS-1:d made my VGA come up as the only screen and as the native resolution | 13:19 |
| pitti | apw: ok, trying the video= option and VGA instead of DVI now | 13:21 |
| apw | pitti, not been able to get the LVDS back as yet | 13:21 |
| seb128 | re | 13:22 |
| seb128 | pitti, sorry I had a phone call, back | 13:22 |
| seb128 | pitti, do you need me for any testing? | 13:22 |
| seb128 | pitti, in summary I'm usually working with lid close + dvi screen and booting docked | 13:23 |
| seb128 | pitti, gdm resolution is lower that what it should, desktop config has an xrandr config | 13:23 |
| seb128 | pitti, I don't have issue on boot but dvi cut after user switch and doesn't come back until xorg restart | 13:23 |
| seb128 | pitti, resuming undocked after a docked suspend leads to no active screen too until I switch between vts which bring the screen back on too | 13:25 |
| === MacSlow|lunch is now known as MacSlow | ||
| apw | pitti, i wonder if specifying the native res for the dvi might work | 13:32 |
| apw | pitti, doesn't seem to ... hrm | 13:34 |
| pitti | seb128: did you get the full resolution in gdm with -18 and earlier? | 13:45 |
| seb128 | no | 13:45 |
| pitti | apw: sorry, back now; took a while, my BIOS is going mad (unrelated to the screen issue) | 13:45 |
| pitti | apw: so disabling LVDS works, as expected; haven't tried VGA yet (that's when BIOS acted up and stopped booting at all) | 13:46 |
| pitti | I'll continue trying this later on; I need to run out for some 1.5 hours now for an appointment | 13:46 |
| apw | pitti, ok ... not managed to work out how to re-enable the LVDS which is sucky | 13:47 |
| pitti | apw: anyway, the xorg.conf resolution workaround seems better in that case anyway; X ignores it when there's only the internal LVDS | 13:47 |
| lamont | Setting up irqbalance (0.55+20091017-3ubuntu2) ... | 13:47 |
| lamont | start: Unknown job: irqbalance | 13:47 |
| lamont | I'm guessing iz bug? | 13:47 |
| jdstrand | mvo: hi! do you have the kern.log for bug #556343? | 13:56 |
| ubottu | Launchpad bug 556343 in bind9 "upgrade error on 8.04 -> 10.04 " [High,Incomplete] https://launchpad.net/bugs/556343 | 13:56 |
| jdstrand | mvo: I don't think it is apparmor, but want to be sure | 13:57 |
| mvo | jdstrand: I can provide it, its a VM that I just need to fire up | 13:57 |
| jdstrand | mvo: thanks | 13:57 |
| === sconklin-gone is now known as sconklin | ||
| === mathiaz_ is now known as mathiaz | ||
| Keybuk | barry: please don't unmark bugs as "Fix Released" just because one person, with clearly different symptoms, is still having issues | 15:07 |
| Keybuk | those people should file new bugs, since their problem is unrelated | 15:07 |
| MacSlow | pedro_, not really a rb-bug... but related... https://bugs.launchpad.net/bugs/451086 is about to be fixed today... just wanted to mention it, should it happen to come up tomorrow (rb bug day) | 15:12 |
| ubottu | Launchpad bug 451086 in notify-osd "Rhythmbox Notification Bubble shows wrong cover art" [Medium,In progress] | 15:12 |
| pedro_ | MacSlow, thanks, i'll make sure to communicate that to the triagers | 15:13 |
| MacSlow | tseliot, do you know now much work it would be to compile an xorg 1.7.4 for lucid from package-sources? | 15:15 |
| tseliot | MacSlow: the whole x stack or only the xserver? | 15:17 |
| MacSlow | tseliot, mostly just the xserver... as ATI/AMD fglrx driver for the 5870 only works with 1.7.4 and below... I couldn't get it to like 1.7.6 which comes with Lucid | 15:18 |
| === bjf-afk is now known as bjf | ||
| tseliot | MacSlow: is this bug #554191? i.e. X segfaults with fglrx | 15:19 |
| ubottu | Launchpad bug 554191 in fglrx-installer "fglrx causes X to segfault" [Medium,Triaged] https://launchpad.net/bugs/554191 | 15:19 |
| slytherin | can any of the archive admins please approve jboss binaries from new queue? It is one of those packages which was removed from archive because of FTBFS. | 15:19 |
| MacSlow | tseliot, no... the issue I get with trying fglrx is an undefined DPMSEnabledSwitch() being reported in /var/log/Xorg.0.log | 15:20 |
| tseliot | MacSlow: can you file a bug report about it, please? I can report it to upstream and maybe get the fix in time for Lucid | 15:21 |
| MacSlow | tseliot, ok | 15:21 |
| tseliot | thanks | 15:21 |
| lepagee | Today'S ISO image does not boot | 15:27 |
| pitti | apw: so, no difference for me with VGA vs. DVI; I'll follow up in the bug report | 15:27 |
| cjwatson | lepagee: we produce lots of daily builds, you need to be more specific | 15:28 |
| lepagee | http://cdimage.ubuntu.com/daily-live/current/ | 15:28 |
| lepagee | this one, now | 15:28 |
| cjwatson | which architecture? | 15:29 |
| lepagee | it say: "BUG: soft lockup - CPU#0 stuck for 61s! [event 0:6]" | 15:30 |
| lepagee | 32 bit | 15:30 |
| lepagee | on a pentium 4 | 15:30 |
| cjwatson | http://iso.qa.ubuntu.com/ records some successful tests, so it is not happening for everyone | 15:30 |
| cjwatson | that's a kernel bug then | 15:30 |
| cjwatson | #ubuntu-kernel, or file a bug on the 'linux' package in Ubuntu | 15:31 |
| lepagee | all other Ubuntu since 4.10 run fine | 15:31 |
| lepagee | cjwatson: #ubuntu-kernel is a private channal | 15:31 |
| cjwatson | doesn't look private to me | 15:32 |
| cjwatson | anyway, like I say, it's a kernel issue, you can file a bug about that | 15:33 |
| ogra | cjwatson, i think -kernel wasnt migrated after the freenode update, you cant speak if you are not identified | 15:36 |
| cjwatson | ah | 15:37 |
| cjwatson | subtly different from private, that | 15:37 |
| cjwatson | anyone can identify | 15:37 |
| ogra | indeed | 15:37 |
| === lepagee is now known as Elv13_ | ||
| ccheney | is it expected (or a bug) that when using the human theme that checkmarks in menus are white on beige, it seems very hard to see them | 15:44 |
| === Elv13_ is now known as Elv1313 | ||
| user0 | something really needs to be done about the partitioner during installation of karmic | 15:54 |
| user0 | it's one thing to say "commit changes to disk" and another to format a partition without confirmation | 15:55 |
| slytherin | can any of the archive admins please approve jboss binaries from new queue? It is one of those packages which was removed from archive because of FTBFS. | 15:56 |
| jdstrand | cjwatson: hi. is the ordering of devices listed by /proc/mdstat supposed to be consistent with a raid1 install? I ask because if I use ext4, I have 'active raid1 vdb5[1] vda5[0]' but with ext3 I have 'active raid1 vda1[0] vdb1[1]' | 15:59 |
| jdstrand | cjwatson: notice vda and vdb are listed in a different order | 15:59 |
| cjwatson | jdstrand: I thought it was basically whatever mdadm felt like, or maybe the kernel's md subsystem | 16:00 |
| cjwatson | does it matter? | 16:00 |
| jdstrand | I think http://testcases.qa.ubuntu.com/Install/ServerRAID1 depends on the ordering used with ext4 | 16:00 |
| apw | ogra, ais the kernel channel meant to have migrated somehow, something we are meant to have done? | 16:00 |
| jdstrand | at least, that is my theory as to why following that works with ext4 and doesn't work with ext3 | 16:01 |
| jdstrand | (steps 16 and 17 are where things go awry) | 16:02 |
| jdstrand | well, really 16.5, since I shutdown the machine, add the disk then boot | 16:02 |
| cjwatson | jdstrand: that I don't know - pretty surprised that it would make any kind of difference though | 16:03 |
| ogra | apw, i think so, dont ask me what has to be done though | 16:03 |
| jdstrand | cjwatson: maybe it the ordering doesn't, but something is weird. I'l keep poking at it. thanks | 16:03 |
| jdstrand | s/it// | 16:03 |
| Damascene | hello, please what we can do about this? https://bugs.launchpad.net/vte/+bug/263822/ | 16:03 |
| ubottu | Launchpad bug 263822 in vte "RTL (right to left) support in terminal (BiDi)" [Low,Triaged] | 16:03 |
| Damascene | no one is responding | 16:04 |
| Damascene | we want to install mlterm for rtl languages but no help from any | 16:04 |
| jdstrand | kees: you seem to have written most of http://testcases.qa.ubuntu.com/Install/ServerRAID1. can you read backscroll from the last 5 minutes and comment? | 16:07 |
| jdstrand | kees: make that 8 minutes | 16:07 |
| === al-maisan is now known as almaisan-away | ||
| soren | jdstrand: The order in which they're listed depends on the order in which they're discovered at boot (and thus added to the md device), doesn't it? | 16:13 |
| soren | jdstrand: The number in the brackets denote the ordering in the RAID set, I think. | 16:14 |
| jdstrand | soren: that would make sense, so as such, it shouldn't matter... hmmm... | 16:16 |
| soren | jdstrand: I can't find any docs on the format of mdstat, but if I'm reading the code correctly, both my statements above are true. | 16:23 |
| soren | jdstrand: Does it fail in any way? | 16:24 |
| * dholbach hugs soren | 16:25 | |
| * soren hugs dholbach | 16:25 | |
| dholbach | :-) | 16:25 |
| soren | dholbach: Hey, man :) | 16:25 |
| dholbach | how are you doing? :) | 16:25 |
| soren | I'm doing great! Having fun at $NEWJOB and all that. Good times. | 16:26 |
| dholbach | :-) | 16:26 |
| dholbach | great | 16:26 |
| jdstrand | soren: it isn't that it fails per se, it is that with ext3 after shutting down, adding the first disk back and rebooting, both disks are active (ie there is no sync). this causes fsck to fail hugely | 16:27 |
| soren | jdstrand: Erk. | 16:28 |
| soren | jdstrand: I'd classify that as failing :) | 16:28 |
| jdstrand | soren: well, yes, but I don't know if it is a test case issue or an actual failure | 16:28 |
| * soren reads it again | 16:29 | |
| jdstrand | soren: as I move from 16 to 17, I have to do some stuff that isn't listed (ie, shutdown, then add the disk and start up) | 16:29 |
| jdstrand | what I affectionately call '16.5' | 16:29 |
| jdstrand | I'm going to try ext4 again | 16:30 |
| jdstrand | it worked once, whereas ext3 has failed 3 times | 16:31 |
| === deryck is now known as deryck[lunch] | ||
| soren | Yeah, there's certainly a step missing in the test case, IMO. | 16:31 |
| soren | At any rate, if two disks turn up that belong to the same RAID set, but they're not in sync.. Man, I don't know. This is why I've never liked the boot degraded raid stuff. | 16:34 |
| jdstrand | ok, if '16.5' becomes 'shutdown the system, add both disks, start the system' | 16:40 |
| jdstrand | then with ext4 when I start up, I don't need to -a the disk, but cat /rpoc/mdstat shows it is recovering (ok) | 16:40 |
| * jdstrand tries ext3 again | 16:41 | |
| === dendro-afk is now known as dendrobates | ||
| soren | jdstrand: Which one takes precedence in that case? | 16:42 |
| soren | jdstrand: Whichever one is discovered first? | 16:42 |
| jdstrand | soren: well, mdstat gave me: | 16:43 |
| * soren shudders at the thought | 16:43 | |
| jdstrand | active raid1 vda1[2] vdb1[1] | 16:43 |
| soren | Really, this is exactly what is wrong with "boot degraded raid". | 16:43 |
| jdstrand | 1464256 blocks [2/1] [_U] | 16:43 |
| jdstrand | hmm | 16:44 |
| soren | If you've got flaky hardware such that the disk that happens to work on boot alternates, there is /no/ way you will not have data loss. | 16:44 |
| jdstrand | my swap has 'vda5[0] vdb5[1]' | 16:44 |
| jdstrand | notice that for '/' we have vda1[2] | 16:45 |
| soren | Ah, so [0] is no more? | 16:45 |
| jdstrand | soren: correct | 16:45 |
| psusi | jdstrand: wait, you remove one of the legs of the mirror, then add it back later and it's now out of sync and you're getting bad data from the out of sync disk? | 16:46 |
| jdstrand | soren: actually, it seems to have fixed itself after syncing | 16:46 |
| jdstrand | psusi: I am follwoing http://testcases.qa.ubuntu.com/Install/ServerRAID1 | 16:46 |
| jdstrand | psusi: I do step 16. then I make up step 16.5 (shutdown, add missing disk back, boot) and proceed to 17 | 16:47 |
| jdstrand | (17 isn't needed with ext4) | 16:49 |
| psusi | oh dear, this seems to say to boot degraded on one disk, then boot degraded on the other disk, so now both are out of sync with each other | 16:49 |
| jdstrand | psusi: yes it does | 16:50 |
| jdstrand | psusi: which is why I was thinking it may be a faulty test case as opposed to a bug | 16:51 |
| psusi | ok, so yea, when you reboot with both disks mdadm should decide one is failed and you have to manually re-add it, which is step 17... and at that point is when you run a fsck and fail? | 16:51 |
| soren | jdstrand: If I'm brutally honest, I'd say the test case is right. The "feature" is wrong :) | 16:52 |
| jdstrand | psusi: I have not had to do step 17 | 16:52 |
| psusi | no... test case is rather pedantic, but should work.... | 16:52 |
| jdstrand | psusi: with ext4, it just showed up and started syncing | 16:52 |
| psusi | ohh, yuo mean when you reboot with both disks again, mdadm just picks them both up and thinks everything is fine and in sync? | 16:52 |
| jdstrand | psusi: with ext3, yes. with ext4 it syncs first | 16:53 |
| soren | The test case exercises the feature correctly, I think. | 16:54 |
| soren | (apart from the missing step 16.5) | 16:54 |
| psusi | hrm... that's odd... wonder why the fs makes a difference.... afaik, mdadm should see that both disks have the other disk marked as failed, so you have to do step 17 to manually re-add one, at which point it will resync the whole disk | 16:54 |
| soren | psusi: Do you know which one it will favour? I've been trying to work that out. I'm assuming the one with the most recent timestamp. | 16:55 |
| psusi | I think it just takes the first one it detects | 16:55 |
| soren | Hmm... Well, no. | 16:55 |
| soren | Yeah, I was just about to say. | 16:55 |
| soren | It will have ot. | 16:55 |
| soren | to, even. | 16:55 |
| psusi | so when it finds the first disk, it should activate the array with one failed disk... when it finds the second disk, it should fail to activate it since that disk says the other already active disk is failed | 16:57 |
| soren | One would hope. | 16:57 |
| psusi | so when you use ext4 and it does the resync, it resyncs correctly and everything is fine right? | 17:00 |
| jdstrand | psusi: yes | 17:01 |
| psusi | but with ext3 it skips the resync for some reason, and fsck fails | 17:01 |
| soren | Spectacular. | 17:01 |
| jdstrand | I need to redo my ext3 install-- seems something went wrong as grub wasn't installed to the 2nd disk | 17:01 |
| * jdstrand tries for the 5th time | 17:01 | |
| mpt | tremolux, hi, how's the bug-fixing going? | 17:11 |
| tremolux | mpt: hiya! it's going well I think | 17:11 |
| tremolux | mpt: did you have any particular bugs you are thinking about? | 17:11 |
| mpt | tremolux, no, not really -- I have personal bugbears, but they're not the same as the most important bugs | 17:12 |
| tremolux | mpt: yeah, I know the feeling | 17:12 |
| mpt | mvo, how's work going for you? Are you still concentrating on upgrade stuff? | 17:17 |
| === dendrobates is now known as dendro-afk | ||
| === amitk is now known as amitk-afk | ||
| jdstrand | soren, psusi, kees: ok. confirmed on a fresh install with ext3/raid1 that after both have been removed (step 16), adding the disk back results fsck complaining wildly about /dev/md0 containing errors | 17:44 |
| jdstrand | I'm going to file a bug | 17:44 |
| mpt | mvo, in bug 347256 pgadmin was given a lovely vector icon, but in USC it still shows the crusty bitmap. Is that just because app-install-data-ubuntu needs updating? | 17:48 |
| ubottu | Launchpad bug 347256 in pgadmin3 "pgadmin3 has ugly icon" [Undecided,Fix released] https://launchpad.net/bugs/347256 | 17:48 |
| === amitk-afk is now known as amitk | ||
| === deryck[lunch] is now known as deryck | ||
| === ogra__ is now known as ogra_cmpc | ||
| === beuno is now known as beuno-lunch | ||
| psusi | jdstrand: and by add back you mean just plug the disk in, not mdadm add right? | 18:05 |
| jdstrand | psusi: yes | 18:06 |
| jdstrand | psusi: shutdown, add disk, boot. boom | 18:06 |
| jdstrand | bug #557429 | 18:08 |
| ubottu | Launchpad bug 557429 in linux "booting out of sync RAID1 array fails with ext3 (comes up as already in sync)" [High,New] https://launchpad.net/bugs/557429 | 18:08 |
| psusi | jdstrand: can you boot from another disk and mdadm -E each component disk just before the failure? | 18:10 |
| jdstrand | psusi: the failure is very early in boot -- when it tries to bring up '/' | 18:11 |
| psusi | jdstrand: hence boot from another disk ;) | 18:11 |
| jdstrand | psusi: maybe I misunderstand? | 18:11 |
| psusi | i.e. livecd | 18:11 |
| jdstrand | let me try | 18:12 |
| chrisccoulson | directhex - libevolution5.0-cil should still be in the archive shouldn't it? | 18:13 |
| directhex | chrisccoulson, probably not. doesn't work. no life from upstream in making it work with modern e-d-s | 18:14 |
| chrisccoulson | directhex - oh, ok. i was going to disable the mozilla plugin in beagle, but i need libevolution5.0-cil (unless i turn off the evolution support too) | 18:15 |
| directhex | we've been turning off evolution support globally in mono packages | 18:16 |
| directhex | beagle we have some crashers which is why it's not been updated in debian | 18:16 |
| chrisccoulson | directhex, am i ok to just turn it off in the current version then, or should i just leave it for now? | 18:17 |
| directhex | chrisccoulson, frankly, beagle is dead upstream. do what you like to it | 18:17 |
| smoser | cjwatson, i wonder if you would consider having the ssh installer drop the user into a screen session that was running d-i rather than directly attached to d-i. (i also wonder if you're the right person to ask). | 18:17 |
| chrisccoulson | directhex - ok, thanks :) | 18:17 |
| === yofel_ is now known as yofel | ||
| === blueyed_ is now known as blueyed | ||
| kees | jdstrand: are you waiting for resync to finish? | 18:34 |
| jdstrand | kees: you are referring to my raid issue? | 18:35 |
| kees | jdstrand: yup, based on scrollback | 18:35 |
| jdstrand | kees: if so, see my newly filed bug #557429 | 18:35 |
| ubottu | Launchpad bug 557429 in linux "booting out of sync RAID1 array fails with ext3 (comes up as already in sync)" [High,New] https://launchpad.net/bugs/557429 | 18:35 |
| kees | jdstrand: ... wow. | 18:37 |
| kees | jdstrand: that's an intense regression in md. I lack the imagination to understand how it involves the filesystem, though. | 18:37 |
| jdstrand | kees: I have no idea. I just happened to notice it | 18:38 |
| jdstrand | (lucky me) | 18:38 |
| kees | jdstrand: pretty weird. perhaps the problem is that neither drive is seen to "fail", just go missing. still, odd. | 18:40 |
| jdstrand | psusi: superblocks.txt attached to the bug | 18:44 |
| jdstrand | kees: notice that even with ext4 'sudo mdadm -a /dev/md0 /dev/MISSING-DEVICE' is not needed | 18:45 |
| jdstrand | kees: it just comes up as out of sync and starts doing stuff (see psusi's explanation in backscroll) | 18:45 |
| jdstrand | kees: I also updated step 17 in http://testcases.qa.ubuntu.com/Install/ServerRAID1 to explictly poweroff, reconnect the disk (so both are there) and poweron the system | 18:46 |
| jdstrand | kees: I left your 'sudo mdadm -a...', even though it doesn't seem to be required | 18:46 |
| kees | jdstrand: yeah, that's the step that makes no sense -- it should stay "ejected". | 18:47 |
| kees | this is a change in md behavior. | 18:47 |
| * jdstrand nods | 18:49 | |
| psusi | jdstrand: wait, this is taken after you booted from each individual disk, but just before reconnecting both? | 18:49 |
| jdstrand | psusi: no. it is from after reconnecting both | 18:49 |
| jdstrand | psusi: would you prefer just before? | 18:50 |
| psusi | jdstrand: ahh, what's it look like just before, yea ;) | 18:50 |
| jdstrand | psusi: ok, hold on | 18:50 |
| jdstrand | (thank goodness for snapshots) | 18:50 |
| psusi | at that point they both SHOULD say degraded with the other disk marked as failed... which SHOULD prevent them from both being activated when you reconnect both... | 18:51 |
| kusum | cjwatson: Hello | 18:51 |
| kusum | I had a little problem understanding how after grub loaded , ubuntu starts to run as if dual boot | 18:52 |
| === almaisan-away is now known as al-maisan | ||
| Caesar | cjwatson: is it accurate that it's not possible to preseed a more complex disk layout that involves two LVM PVss/VGs ? | 18:59 |
| psusi | jdstrand: that looks right... what about disk2 after booting with disk2 alone? | 19:05 |
| jdstrand | psusi: getting it now... | 19:06 |
| psusi | jdstrand: so did I see that test procedure had you use debconf to configure mdadm to automatically activate the degraded array, instead of passing the kernel command line to force it? I wonder if that has something to do with it | 19:08 |
| jdstrand | psusi: I answered yes to the debconf question | 19:09 |
| jdstrand | (booting degraded) | 19:09 |
| jdstrand | psusi: disk2 superblock attached | 19:09 |
| psusi | yep... that's what it should look like alright... | 19:10 |
| jdstrand | psusi: would it be useful if I attached both disks, booted into the live cd and grabbed the superblocks at that point? | 19:12 |
| jdstrand | (ie without booting off those disks) | 19:13 |
| psusi | jdstrand: maybe.... booting from the livecd should not automatically activate the arrays, so the superblocks should not change, but you might try manually activating the array and see if it properly detects the failure or if it screws the pooch | 19:14 |
| === MacSlow is now known as MacSlow|afk | ||
| === sconklin is now known as sconklin-lunch | ||
| psusi | jdstrand: when you boot with one disk, you get the warning abut being degraded and are given 15 seconds to abort activating degraded or not, right? | 19:18 |
| jdstrand | psusi: I don't see a warning cause of plymouth, but there is a pause yes | 19:19 |
| jdstrand | (I assume cause of plymouth) | 19:19 |
| psusi | hrm... I thought plymouth was supposed to show you important things like that... | 19:19 |
| psusi | jdstrand: can you boot with nosplash and noquiet boot options to disable that? after plugging both disks back in, the udev script tries to do an incremental build when it detects each disk. That should fail for both disks, then eventually after a timeout, the fallback script should try to do the degraded activate... at that point only one disk should be activated and the other ignored | 19:23 |
| akgraner | davidm, ping | 19:23 |
| davidm | hi akgraner | 19:25 |
| akgraner | davidm, mind a pm? | 19:25 |
| davidm | akgraner, not at all, welcome to call also if need be | 19:26 |
| akgraner | call would be better | 19:26 |
| === beuno-lunch is now known as beuno | ||
| jdstrand | psusi: I didn't get to grub in time, but after a long pause it flashed a screen at me very clearly stating I am booting in degraded mode (each time with disk1 and disk2 removed) | 19:31 |
| psusi | jdstrand: long pause like 3 minutes? | 19:32 |
| jdstrand | psusi: no, 15 seconds or so | 19:32 |
| psusi | ohh, right, I think the 3 minute timeout got removed and now it just dose a udevadm settle then falls back if it can't find the root | 19:33 |
| psusi | jdstrand: did you still get that timeout and message about degraded when you reconnect the second disk? or does it just plod along happily like nothing is wrong at all? | 19:34 |
| psusi | until the fsck fails of course | 19:34 |
| jdstrand | I don't think I got the timeout, let me check | 19:34 |
| jdstrand | I can make the VM available if desired | 19:35 |
| jdstrand | or just follow the Install/ServerRAID1 guide | 19:35 |
| jdstrand | psusi: no pause. straight to file system errors | 19:36 |
| psusi | ok, then the error seems to be when udev does the --incremental | 19:37 |
| psusi | that SHOULD only activate the first disk | 19:37 |
| psusi | well, actually it should fail to activate in degraded mode | 19:38 |
| psusi | then the fallback should only activate the first disk after the 15 second timeout and warning | 19:38 |
| === Amaranth_ is now known as Amaranth | ||
| jdstrand | psusi: I'm going to have to move along atm. I'm sure this is reproducible by following the instructions in the bug (it happened here many times) | 19:43 |
| jdstrand | psusi: I updated the bug with everything | 19:44 |
| psusi | k | 19:44 |
| jdstrand | psusi: thanks for looking into it :) | 19:44 |
| === dendro-afk is now known as dendrobates | ||
| psusi | jdstrand,kees: wow, it does it under karmic as well... after activating and modifying each leg of the mirror degraded alone, mdadm --incremental happily inserts the second one back into the running array as if it were clean, no resync, so you get a munged fs with random chunks from each disk | 20:54 |
| jdstrand | erk | 20:55 |
| jdstrand | I wonder why ext4 works then | 20:57 |
| soren | jdstrand: It's possible that ext4's fsck just doesn't see any problems. | 21:03 |
| soren | jdstrand: Don't know if it's plausible, though. | 21:03 |
| soren | jdstrand: Oh, right, you say it actually syncs when you're doing ext4? | 21:03 |
| jdstrand | soren: no-- when I boot in with ext4, the disks are syncing | 21:03 |
| * jdstrand nods | 21:03 | |
| soren | Ok. | 21:04 |
| psusi | hrm... weird.. I used ext4 just now testing it on karmic and it didn't sync | 21:07 |
| highvoltage | slangasek: howdy, do you perhaps know which version of the edubuntu seeds was used to build http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/edubuntu-dvd/20100407/livecd-20100407-i386.out ? | 21:13 |
| highvoltage | slangasek: latest is revision 774 but it seems that an older one is used, since it still contains ubiquity-slideshow-ubuntu | 21:14 |
| slangasek | highvoltage: it should have used whatever was current - however, seeds that correspond to tasks have to go through two publishing cycles before they're reflected in the archive | 21:20 |
| nemo | I'd like to get Hedgewars 0.9.13 officially into Lucid - will avoid nag messages for Ubuntu players and a generally empty server. I should just go ahead and file a bug noting the existing debian package? | 21:21 |
| highvoltage | slangasek: ah yes, right | 21:21 |
| slangasek | jibel: I'm concerned that the bug pattern you've added for 553745 may be too broad; I've seen a lot of backtraces that are the same, but I've also seen some that don't match despite segfaulting in the same function | 21:24 |
| jibel | slangasek, hm, no chance to identify the pattern before the retracer then ? | 21:25 |
| slangasek | jibel: I don't think so. OTOH, it's possible that we have a large enough sample size now that it won't matter | 21:26 |
| jibel | slangasek, I remove that pattern for now. ping me if you want to reenable it later. | 21:29 |
| nemo | heh. there's no lucid-backports section yet. Should I be waiting until launchpad has one? (was taking my cue off of https://bugs.launchpad.net/karmic-backports/+bug/485168) | 21:30 |
| ubottu | Launchpad bug 485168 in karmic-backports "Please backport Hedgewars 0.9.12 to Karmic" [Undecided,Fix released] | 21:30 |
| slangasek | jibel: cheers | 21:33 |
| rickspencer3 | slangasek, hi | 21:36 |
| slangasek | rickspencer3: hi | 21:36 |
| rickspencer3 | slangasek, I just sent a note to ubuntu-devel about default search provider in 10.04 | 21:37 |
| * slangasek nods | 21:37 | |
| rickspencer3 | it's a it of a last minute change | 21:37 |
| rickspencer3 | I am concerned about documentation and translations folks | 21:37 |
| rickspencer3 | I was wondering if you could suggest a way or otherwise help me connect to these folks so I can see if there is any kind of support I can provide | 21:37 |
| slangasek | rickspencer3: ubuntu-doc, ubuntu-translations lists are the normal way to contact them | 21:39 |
| asac | rickspencer3: ask ubuntu-doc@lists... | 21:39 |
| asac | heh | 21:39 |
| rickspencer3 | thanks slangasek | 21:39 |
| slangasek | translations? translators, maybe | 21:39 |
| sebner | rickspencer3: I'm curious, mind explaining the switch back to google? | 21:39 |
| rickspencer3 | sebner, well | 21:40 |
| rickspencer3 | there are a lot of parties involved | 21:40 |
| rickspencer3 | so I can't be as transparent as I'd like | 21:40 |
| rickspencer3 | sebner, don't you think it's for the best, though? | 21:40 |
| sebner | rickspencer3: sure, I always prefered google of yahoo but you posted quite a lot reasons about the switch to yahoo so I was wondering why you switch back | 21:41 |
| rickspencer3 | mmm | 21:42 |
| rickspencer3 | well, I hate to have to be coy about it | 21:42 |
| rickspencer3 | but I can say that, on balance, I think it's best for everybody, including Ubuntu itself | 21:42 |
| sebner | rickspencer3: np, I understand when you can reveal it | 21:42 |
| sebner | *can't | 21:42 |
| rickspencer3 | I can only be transparent about the fact that I can't be transparent ;) | 21:42 |
| sebner | heh | 21:43 |
| sebner | nvm :) | 21:43 |
| ajmitch | rickspencer3: you know it'll spawn all sorts of gossip & conspiracy theories :) | 21:46 |
| rickspencer3 | ajmitch, what can I do? | 21:46 |
| sebner | well ... | 21:46 |
| sebner | €€€€€€€€€€€€€€€€€€ | 21:46 |
| ajmitch | sit back & enjoy some of the wilder ideas? | 21:46 |
| rickspencer3 | right | 21:46 |
| rickspencer3 | it is what it is | 21:46 |
| sebner | ajmitch: I guess 99% will say €€€€€€ | 21:46 |
| slangasek | ajmitch: I think it's clear: the only reason Ubuntu would stop sending search results to Yahoo and put money in Microsoft's pocket is because Microsoft now controls Google and we just don't know it yet | 21:47 |
| rickspencer3 | just so you guys know, after the mobs storm my house, my heart was in the right place | 21:47 |
| ajmitch | sebner: right, most likely | 21:47 |
| rickspencer3 | slangasek, I'm afraid that's the last we'll hear from you | 21:47 |
| slangasek | :) | 21:47 |
| rickspencer3 | somewhere in redmond a little light on a control board lit up just now | 21:47 |
| * sebner waves goodbye to slangasek | 21:47 | |
| ajmitch | slangasek: just what I needed for submitting to slashdot! | 21:48 |
| * sebner thinks google replaced "Ubuntu" with "Windows 7" in the search results so Ubuntu had to switch back | 21:48 | |
| psusi | say, anyone got a second to do a quick bzr merge, push, and dput? bug #534743 just has a one liner change to fix a critical fail to boot error for dmraid users I'd like to get in for beta 2 | 21:48 |
| ubottu | Launchpad bug 534743 in dmraid "dmraid causes udev event feedback loop in Lucid" [High,Triaged] https://launchpad.net/bugs/534743 | 21:48 |
| james_w | psusi: the start of a long night... :-) | 21:48 |
| sebner | rickspencer3: can I assume that Yahoo is now pretty p*ssed off? | 21:49 |
| psusi | better to get it in for beta 2 and run into trouble than slipping it in after and running into trouble at release ;) | 21:49 |
| psusi | and I REALLY hope this serious regression doesn't make it into release | 21:50 |
| james_w | psusi: "a second [...] quick [...] one liner [...]" makes me nervous ;-) | 21:52 |
| psusi | well I've been trying to get it in all week now so it wouldn't be last minute, but ;) | 21:53 |
| james_w | I'm not sure there are any more respins planned anyway | 21:53 |
| james_w | and you haven't answered Scott's question in the bug | 21:55 |
| slangasek | james_w: there are not | 21:57 |
| slangasek | it could still be uploaded in anticipation of the freeze lift, though | 21:57 |
| psusi | james_w: ohh, we discussed it a bit on irc while he posted that.. as I explained in the initial description, the change event is created by dmraid removing the partitions the kernel detected on the physical disk | 21:57 |
| james_w | psusi: well, please update the bug | 21:58 |
| james_w | there's too much uncertainty there for me to upload it given my unfamiliarity right now | 21:58 |
| psusi | well, he asked a question that was already answered previously, but ok ;) | 21:58 |
| james_w | and given that it won't be in beta 2 anyway I don't feel the need to do it now | 21:59 |
| psusi | doh | 22:01 |
| * psusi crosses fingers for rc | 22:03 | |
| nxvl | lamont: ping | 22:04 |
| lamont | sup? | 22:05 |
| cjwatson | smoser: I don't think I object, but it's not a component I know well and I don't expect to have time to implement it. It should probably be raised as a wishlist upstream | 22:06 |
| smoser | fair enough | 22:06 |
| cjwatson | Caesar: I thought that was perfectly possible - there's an in_vg specifier and such - but I'm not in front of my laptop to check right now | 22:07 |
| cjwatson | kusum: sorry, not really sure I understand the question | 22:07 |
| lamont | sup? <-- nxvl | 22:07 |
| nxvl | lamont: Ng just ping me about terminator, i already have the package but got a few request from my debian sponsor, POX is quite nitpicky and want some man pages fixes first, for ubuntu i was waiting for it to land in debian, but Ng told me he talked to you about uploading it | 22:08 |
| lamont | nxvl: yeah - I wants it for lucid | 22:15 |
| nxvl | lamont: should i just upload to the ubuntu archive or do i need to do somethng special? | 22:15 |
| lamont | and if the nitpicky issues are sufficient, we'll just have to make Ng do an SRU for it then | 22:15 |
| lamont | it needs a bug report, and the pain | 22:15 |
| lamont | https://wiki.ubuntu.com/FreezeExceptionProcess <-- nxvl | 22:16 |
| nxvl | lamont: the issues i've been asked to fix are an issue that has been forever with the manpage (a really huge line that needs to be that way but lintian complains) and a minor really easy to fix issue with a "-" | 22:17 |
| Laney | so it won't take long to fix and sync ;) | 22:18 |
| === bjf is now known as bjf-afk | ||
| lamont | ah, those are minor imo | 22:18 |
| nxvl | Ng: ^^ | 22:18 |
| lamont | though if you committed the issue with the "-" for Ng before he pushes 0.92, that'd be lovelish | 22:19 |
| nxvl | Ng: can you please start with the bugs and stuff and i will ack and upload afterwards? | 22:19 |
| Ng | yep, I'm just tidying up the release and then I'll file the bug | 22:19 |
| nxvl | lamont: I: terminator: hyphen-used-as-minus-sign usr/share/man/man1/terminator.1.gz:74 | 22:19 |
| cjwatson | you should be able to suppress the groff warning about the long line too | 22:22 |
| cjwatson | something like .na and .ad around the line in question, or words to that effect. see 'info groff' for more details | 22:23 |
| highvoltage | man I wish Launchpad had a way to moderate comments on a bug | 22:24 |
| CRASHME | :DCC SEND "a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a" 1370673706 3500 4 | 22:26 |
| === al-maisan is now known as almaisan-away | ||
| lamont | highvoltage: but if anyone can moderate..... :-( | 22:33 |
| highvoltage | lamont: well, maybe a troll button and if 10 people mark someone as a troll in a thread it just blocks them from commenting further | 22:35 |
| Vbitz | why would a nornal boot prosess spawn a root prompt | 22:36 |
| highvoltage | Vbitz: running and old Lucid alpha? | 22:36 |
| Vbitz | nope only got the iso about 3mounths back | 22:37 |
| Vbitz | a problem with filesystem mounting created a root prompt | 22:37 |
| cjwatson | if it can't mount the root filesystem for some reason, there's not a whole lot else it can do | 22:38 |
| Vbitz | then after it displayed the prompt and i typed some random command to test the input it booted fine after that | 22:39 |
| lamont | Vbitz: sounds like maybe the disk too > 30 seconds to show up? | 22:39 |
| lamont | I have machines like that | 22:39 |
| Vbitz | so the disk took to long to mount causing a problem that created a root prompt | 22:40 |
| cjwatson | there's a rootdelay= boot parameter, IIRC | 22:40 |
| lamont | cjwatson: yep. my machine in question has it set to something like 90, takes about 52 seconds to show up | 22:40 |
| Vbitz | that is a major exploit problem | 22:40 |
| cjwatson | no it's not | 22:40 |
| Vbitz | would any key at startup cause that | 22:41 |
| cjwatson | you have physical access - that implies root | 22:41 |
| lamont | Vbitz: if Ihave physical access to the console and can boot the machine, I own the box | 22:41 |
| Vbitz | good point | 22:41 |
| lamont | most notably, adding 'break' to the end of the kernel boot parameters.... | 22:41 |
| lamont | or better yet, boot a recovery kernel; | 22:41 |
| Vbitz | is there any dangers to switching runlevel | 22:46 |
| Vbitz | when i did it once it made my screen glow and heat up | 22:46 |
| highvoltage | Vbitz: heh, I repasted that to my lug channel | 22:49 |
| Vbitz | where | 22:50 |
| === sconklin-lunch is now known as sconklin-gone | ||
| fooscript | Hi! :) Does "kubuntu-dev? exist... or have been ever ? | 22:55 |
| fooscript | okey... maybe something easier... While compiling kdelibs :"CMake Error at cmake/modules/MacroEnsureOutOfSourceBuild.cmake:17 (MESSAGE): kdelibs requires an out of source build. Please create a separate build directory and run 'cmake path_to_kdelibs [options]' there." I do not understand. Could anybody explain me in simple words? I came do kdelibs, mkdir build, cd build, cmake .. and... no result :/ What is this path_to_kdelibs? | 23:00 |
| fooscript | aah.. .bashrc is taken from KDE building tutorial. Anybody? | 23:00 |
| Laney | there is #kubuntu-devel I believe | 23:03 |
| fooscript | Laney: Whoops. .<idiot> I tried #kubuntu-dev ... Sorry :) | 23:04 |
| fooscript | bye | 23:08 |
| slangasek | kirkland: kqemu in release notes - as this was in universe, I probably won't put it in the release notes unless you think it's going to be a common concern | 23:16 |
| Ng | lamont: nxvl: https://bugs.launchpad.net/ubuntu/+bug/557671 - not super useful, but it gets the ball rolling | 23:19 |
| ubottu | Launchpad bug 557671 in ubuntu "Update Terminator to 0.92" [Undecided,New] | 23:19 |
| Ng | nxvl: you should note that the Depends have changed since the previous version | 23:20 |
| nxvl | kees: does mk-sbuild-lv changed name? | 23:20 |
| Ng | err, not Depends, Recommends. | 23:20 |
| nxvl | Ng: is that on trunk? | 23:20 |
| Ng | nxvl: yep, right now trunk and 0.92 are exactly identical | 23:21 |
| nxvl | ok | 23:21 |
| nxvl | Ng: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567967 | 23:23 |
| ubottu | Debian bug 567967 in terminator "do not recommend python-xdg" [Normal,Open] | 23:23 |
| === dendrobates is now known as dendro-afk | ||
| nxvl | i'm fixing that | 23:24 |
| Ng | nxvl: hrm, yeah fair bug | 23:26 |
| kees | nxvl: it is named "mk-sbuild" now | 23:29 |
| nxvl | ohhh | 23:29 |
| nxvl | ok, i have that | 23:29 |
| lamont | Ng: afk about 90 min then will look | 23:53 |
| Ng | lamont: cool. I'll be away from consciousness by then. I hope all goes well :) | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!