=== sconklin is now known as sconklin-gone [00:58] * 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.. === bjf is now known as bjf-afk [01:16] 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:19] wgrant, boot from the livecd in text mode, install the lvm2 package, mount the filesystem, chroot into it and reinstall grub [01:20] psusi: Interesting. I've tried that, but it still complains that there's no mapping for my root LV. [01:20] wgrant: failing how ? [01:20] wgrant: do you mean failing to boot, or failing to install grub ? [01:20] wgrant, did you put a mapping for it in /boot/grub/devices.map? [01:20] Failing to install GRUB. Sounds like a different failure mode. [01:21] 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] psusi: No -- should I need to? [01:21] I should try a recent installer and see if it works. [01:21] wgrant, I dunno, I do... [01:21] psusi: and is lvm in the initramfs ? [01:21] psusi: can you do lvm pvscan ? [01:21] lifeless, yes... it's just grub that breaks [01:21] Karmic and Lucid ~alpha2 both hate something about my VG and fail to install GRUB2. [01:22] lifeless, don't need to, once I get grub fixed the system boots fine [01:22] psusi: uhm, if lvm is in the initramfs, and it boots to the intiramfs busybox shell, its not grub thats the problem. [01:22] lifeless, I meant I get a grub rescue prompt, not busybox shell [01:25] 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:30] 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 === bjf is now known as bjf-afk [01:39] psusi: FWIW you should not need /boot/grub/device.map at all right now [01:40] cjwatson, well, I do since I'm actually booting from sdc ;) [01:40] 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] psusi: you still shouldn't need it if everything is working as specified [01:40] 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:41] 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] cjwatson, how's it know which disk to install to then? [01:41] psusi: but it might be going wrong when called in some other path, for some reason [01:41] grub-pc/install_devices should be a /dev/disk/by-id/ path equivalent to /dev/sdc [01:41] (in debconf) [01:41] cjwatson: is it not possible to just include all the modules ? [01:42] lifeless: it's not a good idea because there are size constraints [01:42] first cylinder? [01:42] yes [01:42] mmm [01:42] 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] has anyone considered having a grub partition [01:43] yes, it's been done [01:43] we set it up that way by default on GPT - but not everyone has the partition [01:43] ok [01:43] 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] and stressing the partition table algorithms with an extra partition by default on DOS partition tables is a pain for other reasons [01:43] what machiens ship with EFI at the moment, just macs ? [01:43] 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] lifeless: GPT != EFI [01:43] cjwatson: I thought that EFI was needed to boot GPT though ? [01:43] slangasek: sounds ok, there or cdimage [01:44] lifeless: no [01:44] cjwatson: ok [01:44] cjwatson: ah [01:44] it would be nice if it just built all modules in when installing on gpt with the grub partition [01:44] that's a lie the EFI manufacturers tell you [01:44] heh :) [01:44] cjwatson: ok; so - what BIOSes boot GPT in consumer machines ? [01:44] lifeless, all of them... the bios just blindly loads sector 0 [01:44] 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:45] lifeless: the GPT spec includes a legacy MBR [01:45] gotcha [01:45] sorry, "protective MBR" [01:45] psusi: wouldn't go quite that far - some BIOSes check for a valid MBR partition table [01:45] 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] which is why GPT specifies the PBMR [01:45] *PMBR argh [01:45] :) [01:46] cjwatson, well, true... but when they find it they load an execute, don't care if a gpt table follows ;) [01:46] psusi: right, *if* they find it. :-) [01:46] just saying, there does have to be something there that looks enough like an MBR to fool some BIOSes [01:48] cjwatson, so edit grub-install and add a -x to the shbang line? [01:48] or set -x on its own line? [01:48] psusi: better to put 'set -x' somewhere just below [01:48] k [01:49] wgrant: I fixed at least one cause of that in grub2 1.98-1ubuntu2. of course there may be others. [01:49] wgrant: you do have to have /proc and /sys mounted when upgrading grub-pc, in case that isn't stating the obvious ... === dendrobates is now known as dendro-afk [01:50] yea, looks like it isn't running it when I reinstall grub-pc after reconfiguring it to empty the list of devices [01:51] of course grub-pc explicitly warns in that configuration [01:51] but I'm sure some people are clever and ignore the warning ;-) [01:52] still, I'd prefer it didn't break in that case [01:52] then again, when I put sdc back in the device list, I don't get anything either [01:52] 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] cjwatson: I'm booted normally, so yes, they are mounted. Do I have to do anything to force it to update its mappings? [01:53] wgrant: you shouldn't - it should work it out automatically [01:53] Because still I get http://pastebin.ubuntu.com/410329/ [01:53] wgrant: it might be worth just deleting /boot/grub/device.map (keep a copy for later analysis) [01:53] I upgraded about half an hour ago. [01:53] * wgrant tries. [01:53] it shouldn't normally need it any more [01:53] psusi: no [01:53] RTFM :-) [01:54] oops, it wiped out the -x when I reinstalled the package ;) [01:54] yea, verbose output, looks like it's detecting it when I put the device back in the auto install list with reconfigure [01:55] I'm not interested in that [01:55] well, probably not [01:55] the strange thing is that I'm pretty sure the list was empty before so it never should reinstall [01:55] "never reinstall" is a bit of a myth with grub2 right now [01:55] ? [01:56] it often updates the stuff in /boot/grub/ anyway [01:56] btw, how does that get populated on a normal install? and what if the block device changes? [01:56] 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] grub-install populates it, normally [01:56] if the block device changes, grub-pc.postinst should notice and reask [01:57] could the conf be subtly different when I empty the list after populating it vs its default state before? [01:58] I don't see how [01:58] hard data would help to reduce the need for speculation. :-) [01:58] because I don't recall ever answering that question before today [01:59] I'm trying to reproduce it to get some hard data, but now I can't make it fail ;) [01:59] I think you must be mistaken. It's really very careful indeed to forcibly ask you if that question is left blank [01:59] I could be wrong, but ... [01:59] when I originally installed I was not using lvm and I don't recall being asked that question [01:59] installed with ubiquity before without lvm, then migrated to lvm [01:59] oh, sure, it's set on initial installation [02:00] but I don't see how it could end up blank [02:00] and you explicitly said above: [02:00] 01:43 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] were you misremembering up there? [02:00] 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:01] well, not sure I can help then - I guess I'll need to wait for somebody who can reproduce it [02:01] 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] it's asked when disks change, and in some cases on upgrade from karmic [02:01] (the cases that can't be worked out reliably automatically) [02:02] I suppose you no longer have a raw copy of what the variable was before, via something like debconf-show [02:02] hrm.. I did add the SSD then have lvm migrate the root fs over and reinstalled grub to boot from it... [02:04] but that was a manual grub-install, not reinstalling the package, so no debconf [02:04] 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] aha [02:04] should've asked on the first upgrade of grub-pc though [02:05] but perhaps there wasn't one [02:05] ahh, so it stores the /dev/disk/by-id value too so it can check if it has changed? [02:06] it stores only the by-id value [02:06] what it shows you in the UI is a different matter [02:06] hrm.... because the by-id didn't change when I migrated the fs to the new ssd [02:07] I don't believe you [02:07] do you mean by-uuid? [02:07] by-id is tied to the hardware [02:07] either one I think [02:07] not for lvm [02:07] at least I don't think it is [02:08] oh, right [02:08] but you just said you were installing to sdc, not to the LVM [02:09] yea, I set (hd0) to be sdc in devices.map [02:09] so why does the by-id for the LVM bits matter? [02:10] good point... so if it stored the by-id before, then I changed hd0 in devices.map, could that confuse it? [02:10] because before the ssd hd0 was /dev/mapper/nvidia_blah [02:10] 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:11] hehehe, you got that right ;) [02:11] the packaging should be *completely ignoring* hd0 etc. [02:11] hell, at one point I even tried booting using an lvm snapshot as the root [02:11] there's no way that stuff can be made reliable, so we don't use it any more [02:12] 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] which probably means the fs isn't usable either [02:13] 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:14] grub's built-in LVM support probably doesn't understand snapshots? [02:14] 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] but if it does, ignoring snapshots is probably the right fix, otherwise weirdness will probably ensue [02:15] 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:17] seeing as the boot image needs to be in sync with /boot/grub/, I'd rather it just ignored snapshots [02:17] that seems more likely to be useful [02:17] what do you mean needs to be in sync with /boot/grub? [02:18] the ABI between grub's kernel image installed to the boot record and the modules in /boot/grub is not stable [02:18] if they end up at different versions, you often get hosed [02:18] ohh [02:22] 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] 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] 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] so you have to be somewhat careful about consistency when using grub on multiple-disk systems [02:23] 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:24] 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:39] lamont: what's an 8-letter word in ia64 for "return"? :) (bug #555127) [02:39] Launchpad bug 555127 in xulrunner-1.9.2 "build failure on ia64" [High,Confirmed] https://launchpad.net/bugs/555127 [02:40] psusi: so I suppose something like http://paste.ubuntu.com/410341/ [02:42] cjwatson, might be easier to check the status bits... o gets set on the origin and s on the snapshot [02:44] psusi: that appears to be only in lvs output and the like, which isn't available to grub [02:45] it has to work with the raw metadata header [02:45] but if I've missed something, patch welcome :-) [02:45] ahh, figured there was a flags dword somewhere in the nitty gritty [02:45] doesn't seem to be, the display code does stuff like [02:45] else if (lv_is_origin(lv)) [02:45] repstr[0] = 'o'; [02:45] 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:46] so in fact I think I'm checking the wrong thing there [02:46] cjwatson, and what's lv_is_origin do? [02:46] cody-somerville: is preseeding involved? [02:46] Yes. [02:47] psusi: lots of indirection :) [02:47] cody-somerville: do I get to see? [02:47] also logs? [02:48] cjwatson, https://pastebin.canonical.com/30185/ [02:48] 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:49] cjwatson, https://launchpad.net/bugs/466616 [02:49] Error: Could not parse data returned by Launchpad: list index out of range (https://launchpad.net/bugs/466616) [02:57] cody-somerville: odd. any local modifications to the installer here? [02:58] hello. question regarding pam-config, should all possible modules be stackable? want to know before i file a bug for that on samba. [02:59] the current winbind pam-config prevents modules of lower priority from stacking. [02:59] Terminus: they should, there's a bug, I've just fixed this in the Debian package's svn - please file a bug report [03:00] I didn't realize it would affect any modules in practice, or I would've filed it [03:00] slangasek: basically change requisite to [success=end default=ignore] right? [03:00] yep [03:00] cjwatson, It is a custom d-i build (just to include a few udebs), but no modifications to the partman udebs [03:01] slangasek: well, i don't know if it would affect any other modules either... this is only for common-password btw. [03:01] everything else seems to stack properly. [03:01] cody-somerville: ok, I ask because I can't find any calls to sfdisk anywhere in partman [03:01] Terminus: yep, I know [03:01] okidokie then. bug report it is. [03:02] Terminus: when it's filed, please throw me the bug number :) [03:02] cjwatson, Ah, interesting. I think I might know what that is. [03:02] cody-somerville: oh? [03:03] cjwatson, custom recovery installer stuff. I assumed this build Steve tested didn't have it but it appears it does. [03:03] cjwatson, I'll get QA to test a standard Ubuntu image with that preseed file and see if they can reproduce. [03:03] ah. y'all broke it then? :-) [03:04] cjwatson, in the case Steve tested, most likely. [03:04] 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:06] slangasek: filed. bug #556996 [03:06] 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] cjwatson, Sorry. I should have spotted that myself. Thanks for taking a look. [03:06] nice. [03:06] !botsnack [03:07] Yum! Err, I mean, APT! [03:08] slangasek: don't suppose this would be the cause of bug 556785 too? [03:09] 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] seems a stretch, but ... [03:09] cjwatson: unlikely; that's probably a duplicate of the bug ttx fixed in the samba update this morning [03:10] which is related, except for the part where it's already fixed [03:10] ok [03:11] 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] right [03:12] while we're talking about this, pam_mkhomedir.so isn't suitable for inclusion in the winbind pam-config, right? [03:20] Terminus: I wouldn't think so, since a) not everyone necessarily wants it, b) pam_winbind supports its own mkhomedir option [03:21] Terminus: I think it would be better for libpam-modules to ship a (disabled-by-default) profile for pam_mkhomedir [03:23] slangasek: yeah, that would be nice. only difference between mkhomedir and pam_mkhomedir.so is that the latter uses /etc/skel... [03:26] ah [03:26] could you file a wishlist bug on pam for this, too? [03:27] slangasek: sure. which package though? [03:27] 'pam' :) [03:28] ok. hehe [03:32] still have another bug to file about libpam-mount having problems creating directories. keep on forgetting this one. >_< [05:09] 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] Launchpad bug 556239 in libpam-mount "mounting cifs uses uid and gid options by default" [Undecided,New] https://launchpad.net/bugs/556239 [05:09] Launchpad bug 557025 in libpam-mount "pam_mount.so chown to user when creating directory fails" [Undecided,New] https://launchpad.net/bugs/557025 [05:54] 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 [06:04] 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. [07:00] Good morning [07:05] Ah i'm afternoon [08:17] good morning [08:19] good morning pitti and dholbach [08:20] hey geser! :) [08:20] hey geser, how are you? [08:20] I'm fine [08:23] morning all; any sponsors around to have a look at a patch for lucid regression in bash-completion? === radoe_ is now known as radoe [08:54] could some one have a look at bug #549234 please? [08:54] Launchpad bug 549234 in hellanzb "Please sync hellanzb (0.13-6) from debian unstable" [High,Confirmed] https://launchpad.net/bugs/549234 === almaisan-away is now known as al-maisan [09:21] hello [09:21] mvo: hi [09:22] 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:23] zyga: cool [09:35] mvo: I did one cool thing yesterday though, I rewrote command-not-found to be a dbus service [09:35] mvo: it's super fast and responsive now [09:35] zyga: err [09:35] zyga: why?! [09:36] lifeless: because it stays in memory [09:36] 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] lifeless: and python startup time is no longer an issue [09:36] lifeless: responsiveness == startup time mostly [09:36] lifeless: now it's giving you output in 0.021 seconds [09:36] uhm [09:36] lifeless: previously it was 0.5 + [09:36] command not found is 3 python files [09:37] lifeless: yeah but it opens several files, reads databases [09:37] lifeless: talks to apt [09:37] lifeless: all in all it's not free [09:37] the databases are not python startup time though [09:37] zyga: how much memory does it use [09:37] lifeless: true [09:37] lifeless: let me check [09:38] there are good algorithms for fast string match search (where fast == examine a smal fraction of your database) [09:38] lifeless: I'll upload the package to my ppa though [09:38] lifeless: I know, I measured what's long [09:38] I think it would be a _much_ better idea to use those, than to waste memory. [09:38] lifeless: python startup [09:38] lifeless: database initialization (cold cache, stating lots of files) [09:38] lifeless: and the minor part was actually giving you the output [09:39] zyga: sure; thats why I'm saying change the algorithms in the db you use. [09:39] search requires an appropriate data structure. [09:39] 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] lifeless: the database is good, really [09:39] geser: yes; well, the default mode is "unstable" [09:39] zyga: then why are you stating lots of files? [09:39] lifeless: it's gdbm, there is just one lookup really [09:39] lifeless: python stats ~500s files on startup [09:40] lifeless: I stat 10 files to find the database and configuration [09:40] zyga: it can, depending on what layout you have [09:40] getting rid o the eff [09:40] and the package would help [09:40] go to a single module [09:40] lifeless: I encourage you to try to see how old c-n-f worked [09:40] eff? [09:40] possibly even get rid of the python library altogether [09:40] lifeless: it's best to rewrite the client in C [09:40] sorry, fingers haven't quite learnt this keyboard yet [09:40] egg [09:41] 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:42] zyga: I have looked ;) [09:42] lifeless: the new code is in lp:command-not-found, do check it out too [09:43] 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] zyga: I'll have a browse round the new code tomorrowish [09:43] lifeless: the service closes after period of inactivity [09:43] zyga: does it ever get called twice in a row anyway ? [09:43] lifeless: huh? [09:44] 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] lifeless: I know that having a warm cache is helpful [09:44] lifeless: but new code is much more responsive anyway [09:44] lifeless: next step is to rewrite the client into pure C [09:44] zyga: its not clear to me /how/ it can be more responsive. [09:45] lifeless: and finally (maybe) integrate into bash [09:45] cold cache it has to start the service up as well as do what it was doing before. [09:45] lifeless: because cold cache is not everything [09:45] lifeless: python + apt [09:45] 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:46] lifeless: yes, the initial startup time is same [09:46] lifeless: but after that it's only better [09:46] hmm [09:46] I wrote the code yesterday and did some benchmarks [09:46] ok [09:46] and it's really there [09:46] lifeless: I encourage fixes though [09:46] 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] lifeless: my goal is fast small and lean program [09:47] persia: it doesn't work like that [09:47] zyga: I would be interessted in the figure for C client without dbus [09:47] persia: database is the most difficult thing in the whole program [09:47] zyga: benchmark figures [09:47] mvo: I'll try to make them (it's in line with my new job anyway) [09:47] zyga: Hrm? How does it work then, because it fails completely for armel and powerpc last I checked. [09:47] zyga: I'm not sure that dbus is worth it, its a good experiment, but it just does not feel right [09:47] persia: ask mvo :-) [09:48] mvo: why? [09:48] 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] persia: its currently running on rookery [09:48] persia: all that is really needed is a mirror then those can be integrated [09:49] mvo: actually [09:49] mvo: current code does more, the service loads apt.cache [09:49] mvo: and gives you the summary of the package [09:49] zyga: a basic C client prototype should be pretty quick, no? [09:49] mvo: yes, I'll get to that [09:49] mvo: So UnifiedDataExtractor/mirror/do-mirror isn't the place to fix this? [09:49] mvo: first the client, finally the service [09:50] persia: that would work too, just requires a bit of disk-space and bandwidth [09:51] persia: there is some room for improvement [09:51] mvo: (do you have the time to run the script I sent you some time ago?) [09:51] zyga: still not sorry :( [09:51] mvo: ok [09:51] zyga: I hope by the time beta-2 comes out [09:52] mvo: cool, no rush [09:52] mvo: OK. That makes sense. Same issue as madison/rmadison in some ways. Thanks :) [09:53] persia: there is a spec to include it during the build process [09:53] persia: but it did not finish for lucid, maybe lucid+1, if LP makes it [09:54] 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:56] persia: well, it would be nice to have it for lucid [09:56] persia: at least for armel [09:56] 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:58] mvo, persia, lifeless: I have .deb files if you are interested in checking this [09:59] lifeless: 29M res, 49M virtual [10:00] thats quite a bit for a netbook or smaller machines [10:00] lifeless: it's not different to what c-n-f had [10:00] lifeless: old version consumed the same amount of memory each time you made a typo [10:00] lifeless: (I work on a netbook all the time BTW) [10:01] lifeless: it's not perfect (especially for embeded) [10:01] yes, but the memory is freed after [10:01] lifeless: but it's not worse really [10:01] if you want to work on lower memory footprint, we could do that [10:01] lifeless: if you work in the shell it doesn't matter - the memory will be taken again in a moment [10:02] lifeless: I think that as long as your terminal is open c-n-f keeps starting and stopping all the time [10:02] lifeless: the service makes the process cheaper [10:02] lifeless: but to make one point clear - the new code can run without the service [10:02] lifeless: it's not that the interface requires the service ;-) [10:03] lifeless: on my machine empathy takes more memory [10:03] lifeless: then mono [10:03] lifeless: I'll try to tweak gc settings today, maybe we can get the memory level even lower [10:04] lifeless: (not counting firefox obviously - it takes all the memory) [10:06] lifeless: if we disable apt.cache() (it's a new feature) the service uses 9MB of memory [10:28] 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] Launchpad bug 552548 in fglrx-installer "fglrx broken after update to 2:8.721-0ubuntu7" [Medium,Triaged] https://launchpad.net/bugs/552548 [10:30] tseliot: for a falure like this it would be helpful to get /var/log/dpkg.log and /var/log/apt/term.log [10:31] mvo: ok, I'll ask users to attach those files to the report, thanks [10:31] tseliot: thanks [10:32] 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:35] 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:37] 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] tseliot: thanks, I let it in for now [10:38] mvo: Alternately, could we maybe run it on the primary archive server *before* the mirror split? [10:38] persia: arch does not matter as long as the debs are all there [10:38] persia: I guess so, I don't have access to this machine though afaik [10:38] mvo: Do you need real access, or just to run a cronjob? [10:40] persia: just a cron job [10:41] * persia checks for the archive-admin-of-the-day [10:41] cjwatson: Do you know if the pre-split mirror has disk/processor to spare for such a cronjob? [10:42] Would add support for armel/ia64/powerpc/sparc to command-not-found [10:42] it's pretty locked-down, I'd rather not run more code on it [10:42] and there'd be an issue with getting the results off [10:43] but ask IS? [10:48] mvo: it looks like support for SSE is back in -173 so you can remove it from your blacklist [10:51] pitti: around? [10:53] hi bdrung [10:54]