[00:00] hloeung: Apparently, nihal needs filecache-default scrubbed. [00:00] hloeung: However... [00:00] hloeung: Before you do that, a copy of it might be nie. [00:00] nice, too. [00:00] infinity: just filecache-default? or the build-*'s as well? [00:01] hloeung: Are there more than one build-*? [00:01] infinity: yes, there's 3 actually [00:01] Oh. [00:01] Fun. [00:02] hloeung: In that case, yeah. Stop lp-buildd, clear out the whole mess. But I'd like a backup of filecache-default, if you could? [00:03] infinity: yep, taring up filecache-default [00:03] hloeung: On lillypilly or chinstrap, or somewhere I can get to it readily. [00:06] * infinity wonders if anyone in the Bay Area wants to bring him a power cord for his laptop, since he stupidly forgot his at home. [00:06] Don't all speak up at once. [00:19] is there a reason that language-pack-en-base Recommends firefox-locale-en ? [00:19] its really only an annoyance, but installing a language pack on a server then pulls in firefox packages [00:19] (well, not really firefox packages, but firefox-locale-xx) [00:20] You could install with --no-install-recommends [00:20] you mean you didn't configure that as the default? ;) [00:21] But the relationships for langpacks have always been a bit sketchy, because it's hard to adequately represent what we want to happen there. [00:21] Partly it's because IIRC that used to be in language-pack-en but was split out. [00:22] Mozilla locales have always been separate. Unless you meant the dependency used to be elsewhere. [00:22] At least, I think they always have been... [00:23] But really, no amount of Enhances or Recommends magic can make it DTRT for all people. [00:23] I may just be misremembering. [00:23] The per-package mini langpack spec would solve the issue, but I so think it would cause more problems than it solves. :P [00:24] cjwatson, you pointed at python-apt earlier, do you know if i can use it to tell me if a package is installed without having cache available ? [00:24] You generally need to instantiate a cache to find out much of anything. Why don't you want to? [00:24] You could just use dpkg... [00:24] (or dpkg-query) [00:25] dpkg's own interfaces for this are actually kind of crappy, so I understand preferring to ask apt. [00:25] Forking dpkg is going to still be less painful than spinning up an apt cache, if you didn't need the latter. [00:25] $ time python -c 'import apt; cache = apt.Cache()' [00:25] real 0m0.900s [00:26] Though it would be nice for libapt/python-apt to be able to give dpkg status info with no cache built... [00:26] $ time dpkg-query -W man-db [00:26] man-db 2.6.1-1 [00:26] real 0m1.882s [00:26] I'd use apt if I were you :-P [00:26] cjwatson: I'm unconvinced that benchmark is linearly true on slower hardware. [00:26] Possibly, but dpkg has never been very quick to parse its own status file. [00:26] No, true. [00:27] apt takes nearly a minute to rebuild a cache here, though. [00:27] (assuming a fresh invalidation, ie: apt-get update) [00:28] Oh, actually, most of that is probably unzipping lists. So, I guess it depends on smoser's definition of "no cache". [00:28] "no cache" really meant no /var/lib/apt/lists [00:29] I suppose you could use python-debian to parse /var/lib/dpkg/status if you were desperate [00:29] and i'd really hope to be able to query "is a package installed" in less than a second. [00:29] smoser: Well, nothing there at all? In that case, building a cache as per cjwatson's code above would just build one with dpkg/status. [00:29] Or python-apt might have a way to do that too which might be faster, I forget [00:29] infinity, right. thats what i'm seeing. [00:29] smoser: Do you need to query more than one? [00:30] in this caase i'm only after if a package is installed. dont eed to query more than once. [00:30] Then none of the options will be significantly faster as far as I can think of. [00:31] If you're prepared to hardcode things about the packages you could check for a file they're known to ship. [00:31] Ew? [00:31] Or possibly check for the existence of /var/lib/dpkg/info/$pkg.list. But if you do that you need to be very clear on how/whether multiarch will affect you; that's an implementation detail. [00:31] I mean, .list files are an implementation detail. [00:32] Surely, higher level abstractions of dpkg/status are the sane way to go... [00:32] Yes. As I say, I'd use python-apt. [00:33] so.. the general idea here is this (feel free to tell me any portion of this is wrong) [00:33] Because normally it's already done the work of parsing the status file into a more quickly loadable cache format, that being a lot of the point of the cache. [00:33] * bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/859814 shows the issue we're trying to address (and links to other bugs there too) [00:33] Launchpad bug 859814 in cloud-init (Ubuntu) "Locale issues with beta-1/2 cloud-images" [Medium,In progress] [00:34] * cloud-images have not in the past had a language pack installed, resulting in stderr output when someone ssh's in with other than en_US.UTF-8 [00:34] * cloud-init has long had this support for setting a default host locale, and only now have we found that that didn't really make sense without installing language-pack-XX [00:35] * so we're looking to install language-pack-en in the default images, and if the user asks cloud-init for "configure my default locale to french" we'll want to install language-pack-fr === eights is now known as Guest66747 [00:35] If you're trying to test whether a given locale is installed, the right way to do it is: [00:35] import locale [00:35] i want to ask "do i have language-pack-fr" installed before doing an apt-get update and 'apt-get install language-pack-fr' [00:35] smoser: Now, this is a slightly different direction, but do these VMs typically actually need a langpack installed? Cause if it's just about annoying error messages from shell/perl/etc, you could localegen the world. :P [00:35] try: [00:36] infinity, you can't just use localegen. [00:36] locale.setlocale(locale.LC_ALL, '') # or a specific locale as the second argument if you don't want to take it from the environment [00:36] unfortunately. :) [00:36] except locale.Error: [00:36] # take steps to install the locale [00:36] https://bugs.launchpad.net/ubuntu/+source/postgresql-9.1/+bug/969462 [00:36] Launchpad bug 969462 in postgresql-9.1 (Ubuntu) "fails to start after install if invalid locale is set" [Undecided,New] [00:37] smoser: Since when? I do it all the time. Doesn't buy you translations (obviously), bet gets you a valid locale. [00:37] so you could easily touch the apt cache only in the locale.Error slow path there [00:37] well, ok. maybe you can do that i guess. [00:37] infinity is correct too [00:37] hm.. [00:37] cjwatson: And, of course, your code is tripped up by people like me, since it's testing for a locale as a key to installing a langpack, the two are only loosely related. [00:37] generating locales manually is explicitly supported [00:38] so it is OK to localgen even if i dont have the language-pack-xx installed ? [00:38] sure [00:38] Of course. [00:38] there're special arrangements to remember which ones you've locale-gen'ed manually vs. via language packs [00:39] the manual ones will end up in /var/lib/locales/supported.d/local [00:40] smoser: Of course, if you really do want translations as well as valid locales, you need to go the langpack route. [00:40] infinity, yeah. so i think i'll go the quick 'imporet locale' route to test, and if thats not there, then install the package. [00:40] soren: ping - need some assistance with preseeding. I have the same preseed for 3 different systems, and I am getting two different errors in partman. [00:40] allowing for the case when i've been trick'ed by you, infinity [00:40] smoser: And I really see no reason that can't just be a shell 2-liner of dpkg-query && apt-get install. [00:40] s/allowing/ignoring/ [00:41] Or anyone else that wants to jump into my preseed nightmare. [00:41] smoser: My trickery is fine. If I'm generating locales by hand, it's because I don't want the langpack, so that seems a sane thing. [00:41] infinity, yeah, the reason i'm concerned is this happens on first boot. [00:41] infinity: or even just apt-get install --no-upgrade [00:41] and its generallyhappening serially. [00:42] but, indeed, I don't really see what installing the package is going to buy you, from your description. [00:42] it's strictly more than you actually want. [00:42] http://paste.ubuntu.com/912292/ for anyone that wants to look. [00:42] so i dont really want to postpone boot by .5 seconds or more. [00:42] and language-pack-en take significantly longer, since it will generally have to generate rather more locales. [00:42] *will take [00:42] right [00:42] even discounting having to download and unpack it and its -base pair. [00:42] Yeah, the localgen in langpack-en is painful. [00:43] so maybe doing localgen is enough. [00:43] I just had a perverse idea. [00:43] pam module that checks the starting ENV and forks localegen for uninstalled locales. [00:44] Please pretend I didn't just say that. [00:44] Thanks. [00:44] yeah. i sort of looked there. [00:44] (It's quite easily doable...) [00:44] what we have now is a profile.d message that informs the user how to make the environment usable if they do want their locale [00:45] And would once and for all end the "I sshed from my desktop to my server, and Perl whines at me, HALP" bugs. [00:45] well, thtas sort of what i was addressing here. [00:46] GrueMaster: suggestion for you in bug 971608, assuming that this is the same thing. [00:46] Launchpad bug 971608 in partman-auto-lvm (Ubuntu) "Unable to create blank lvm volume in preseed install" [Undecided,New] https://launchpad.net/bugs/971608 [00:46] It's not really any uglier than pam_userdir and other such one-time violence. [00:46] but i thikn i'm good enough at this point to just locale-gen, and inform the user on how to fix the issue. [00:46] In fact, less so, because it doesn't need to keep track of priv bouncing, it would just be a pre-session root deal. [00:47] Anyhow, not suggesting this as the solution for your bug in the next few weeks before release. [00:47] But now the gears are turning in my mind. :P [00:47] cjwatson: Yes, I have that in my current preseed for both panda and armada systems. Pandas are now complaining about not mounting /boot, armada is complaining about blank lvm. [00:47] Preseeds are identical. [00:47] the "locale_warn" branch is at https://code.launchpad.net/~utlemming/cloud-init/cloud-init.profile.d/+merge/100262 [00:47] GrueMaster: I need the precise text of the complaints in order to help [00:47] paraphrasing means I can't grep for it [00:48] infinity, just in case you care. and it might be updated with what i learned here. thank you cjwatson and infinity [00:48] panda: The attempt to mount a file system with type ext3 in SCSI1 (0,0,0), partition [00:48] #1 (sda) at /boot failed. [00:48] Armada: No file system is specified for partition #1 of LVM VG eilt0, LV Test1. [00:48] I don't see method_only in http://paste.ubuntu.com/912292/ or in your bug report from earlier, by the way. [00:48] GrueMaster: Not ext4? [00:49] I added the method_only after filing that bug report (found it at noon PST). [00:49] infinity: Which? /boot? u-boot doesn't understand ext4. [00:50] GrueMaster: And the message you quote for Armada will be silenced by preseeding partman-basicmethods/method_only. Please check again that you really preseeded it. [00:51] The u-boot case might want to be something like method{ format } use_filesystem{ } filesystem{ uboot } instead. [00:52] Oh, except partman-uboot is still dove-only, unless ogra fixed that ... [00:52] So maybe not. That's unrelated to the blank partition problem, anyway, I think [00:52] * cjwatson -> really crash [00:54] partman-uboot was dove only. [00:56] ok.. [00:56] i'm doing an automated install. [00:56] i watch the installer get up and do some downloading of the installer packages. [00:56] and i'm seeding this to use a squid-deb-proxy [00:58] heres a snippet of my squid proxy logs [00:58] http://paste.ubuntu.com/912304/ [00:58] why is the installer doing 10 requests for Pakcages.gz ? [00:58] groan. To add to my issues, it would appear that my most recent preseed was clobbered due to stale vi swap. Fortunately, I have a copy on another system. retrying. [00:58] and then it dies complaining about it being corrupt [00:58] but i'm validating it manually locally, and it has identical checksum as reported by Release [00:59] hloeung: Did you restart lp-buildd on nihal when you were done tidying? [01:00] earlier today we thought this issue was https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/971820 , but that change has been applied locally [01:00] Launchpad bug 971820 in squid-deb-proxy (Ubuntu) "squid-deb-proxy needs special handling of Release, Packages, Source" [Undecided,In progress] [01:00] infinity: I've stopped it now. Am going through cleaning up build-* and the filecache-default [01:00] and will start it back up when done [01:00] hloeung: Ahh, okay. I was just being impatient then, nevermind. ;) [01:01] Well, this is...different. cjwatson: New pastebin. http://paste.ubuntu.com/912305/ [01:01] infinity: heh sorry, I'm also uploading a copy of the filecache which doesn't help. Each command is taking quite some time to send over [01:01] What is the local port for mount.cifs? [01:01] hloeung: No rush, I'm about to head out for food anyway, and one dead Panda won't kill the rebuild. [01:02] hloeung: Just poke me on IRC when it's all done, and I'll look at things when I get back. [01:02] Now I still get the same failures as above, but on different systems. 2 pandas and armada fail to mount /boot, 1 panda now fails with "!! ERROR: No root file system [01:02] " [01:02] filecache-default.tar.bz2 31% 137MB 94.2KB/s 53:55 ETA [01:02] infinity: ^ [01:02] so it'll probably be done when you return... [01:02] hloeung: Err, are you bouncing it from your home connection? [01:02] infinity: yep [01:03] hloeung: You could have just put it in ~buildd/public_html/ and grabbed it from another host in the DC. :P [01:03] errr... why didn't you tell me that earlier? ;-) [01:03] Well, not from just any host, but some have firewall rules to allow it (nusakan, lillypilly, etc) [01:04] And lillypilly would be a fine choice. [01:04] infinity: ah, I'll remember that for next time. [01:05] anyways, launchpad-buildd bounced on nihal [01:05] Danke. [01:12] Design Capacity: 22 Wh, Energy when Full: 27 Wh. [01:13] This is one heck of a battery. [01:16] infinity: any chance of helping me to get https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+build/3377300 going on roseapple? [01:23] micahg: You expect it to magically not fail there? [01:23] infinity: hoping :) [01:24] infinity: I got it to build locally in a 32 bit chroot [01:25] Yeah, the 64-bit kernel might "fix" it. [01:25] But, uhm. That's not really fixing it. Just sayin. ;) [01:26] infinity: yeah, there's something weird going on in that build, <= natty takes a lot of memory/space, oneiric+ takes very little (relatively) [01:26] infinity: I'd rather just get it built now and figure that out later [01:27] Already on it. [01:28] It's ridiculous how long that PNG optimising stuff takes. [01:28] pitti: ^-- Is it really that hard, or is the code just that bad? [01:29] infinity: also, would you mind copying chromium-browser lucid, maverick, and oneiric from ubuntu-security-proposed to -proposed [01:30] micahg: Can you ask me to do that after I've eaten? ;) [01:30] micahg: (the build is on roseapple, though) [01:30] infinity: thanks, sure, I'm heading out for a bit, will ping when I return [01:30] Kay. [01:31] * infinity goes to wander the streets of SF aimlessly until he smells something good. [02:13] bug #919281 appears to be the result of some kind of error spinning the server cd and leaving out kernel modules. What's the correct package that should be assigned to? [02:13] Launchpad bug 919281 in Ubuntu "Ubuntu installation image Fake RAID" [Undecided,Confirmed] https://launchpad.net/bugs/919281 [02:14] lifeless, around ? [02:16] smoser: hi, sure. [02:16] https://bugs.launchpad.net/ubuntu/+source/squid-deb-proxy/+bug/971820 [02:16] Launchpad bug 971820 in squid-deb-proxy (Ubuntu) "squid-deb-proxy needs special handling of Release, Packages, Source" [Undecided,In progress] [02:16] i'm desparate [02:17] i'im hoping that you could tell me some magic "the right way" to run a squid proxy for apt. [02:18] i had an issue earlier today, we opened that bug, and hoped it had been addressed, but with the suggested lines: [02:18] refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz)$ 0 0% 0 [02:18] refresh_pattern \/Release(|\.gpg)$ 0 0% 0 [02:18] you can at best work around things; apt archives are not HTTP safe. [02:18] I've still got a squid proxy that has cached a bad version of http://archive.ubuntu.com/ubuntu/dists/precise/main/binary-i386/Packages.gz [02:19] well, i'm very interestedin your input on the best possible configuration. [02:19] the thing is that the constant-named files have no safe cache semantics should of must-revalidate [02:19] s/should/short/ [02:21] well, honestly, i'd greatly prefer horrendous waste of network badwidth to the pain of a bad cache'd value. [02:21] blacklist Releases/Sources/Packages then [02:22] sorry, I don't have a good canned answer for you [02:22] caching debs is fine, anything that we replace the content on has a race window *if* any other file is coordinated with it [02:22] infinity: chinstrap:~hloeung/filecache-default.tar.bz2 [02:23] at scale, any size race is exploitable [02:23] lifeless, as in 'cache deny PACKAGES' [02:23] yah [02:23] IIRC you can force must-revalidate as well, which would be a little more efficient [02:24] "force must-revalidate" would be doc'd here http://www.squid-cache.org/Doc/config/refresh_pattern/ ? [02:24] *note* though that you will *still* hit these races: our mirror update scripts reduce the window down to subsecond, *but* different mirrors update up to 15 minutes apart, or more. [02:25] smoser: IIRC last we looked at this we determined your squid was using multiple upstreams ? [02:25] this one is not. [02:26] we have had that issue in other cases. [02:26] but this one has a pinned IP somewhere for me. [02:26] smoser: what version of squid are you using ? [02:26] 3.1.19-1ubuntu1 (precise archive) [02:26] so - re the upstream bug [02:26] http://www.squid-cache.org/Doc/config/balance_on_multiple_ip/ [02:27] I think the thing is that squid by default is much more sticky [02:27] lifeless, fwiw, the mirror update scripts window is not subsecond. [02:27] even in a single mirror, its well above that. [02:27] but that probably it only takes a single failure to trigger a rotate [02:27] might be worth adding that to the bug [02:27] smoser: really? How long does the critsection take? [02:27] its bad. [02:28] i dont have numbers in front of me, but we hit it way too often for it to be sub second. [02:28] smoser: and the mirrors are using the three-run rsync approach ? [02:28] they're canonical run mirrors [02:28] i dont really know. [02:28] hmm [02:28] https://code.launchpad.net/~smoser/+junk/check-archive/ [02:28] I can look into that [02:28] that script, run it in a loop (on canonistack if you'd like) [02:28] you'll hit single inconsistent mirrors way to often [02:29] (and by "in a loop", i mean with a 1 or 2 minute sleep) [02:29] smoser: so the thing is, that either a) apt needs to send appropriate paranoid cache-busting headers, or b) apt needs to retry on inconsistent results (with appropriate headers) or c) we have to change the apt disk format. [02:29] lifeless, yeah. [02:29] smoser: you're really at the edge of the fixes that can be done for dealing with live repositories [02:29] i have a list of apt greivences against apt. [02:30] other mirroring scripts might be able to force it to subsecond, but even then, as discussed, at scale, it will be hit. [02:30] and server team hopes to have some session on that at uds-q, and we would love to have your expertise there. [02:30] i'd like to address it where it can be fixed for good. [02:31] we want to tell people to install packages and provision things in an automated fashion. [02:31] and when doing so, at least for the development release, the archive is the most likely cause of failure. [02:31] smoser: the root cause is to fix apt's disk format: it needs to depend on only a single file being updated atomically at a time, not two files. [02:32] well, N files. [02:32] 1 [02:32] multiple Packages.gz and Source.gz have to be in sync with Release [02:32] at the moment, Packages.gz <- Release [02:32] and separately [02:32] Sources.gz <- Release [02:33] but this is a meaningless difference in model; the key thing is that to be safe in the absence of caching, the archive has to be fully readable at any given state, including when only one file of a group has been updated. [02:33] right. [02:34] To be safe in the presence of caching the archive has to be fully readable with the old versions of a file at each url. [02:34] the way I would approacho it, if I were to work on it, would be to ditch Packages.gz and Sources.gz and the other similar fixed-name metadata files; [02:35] use hash or otherwise uniquely generated names for them and reference those from Release [02:35] and inline-sign Release [if its not already] [02:36] this would make mirror pushes atomic - write the new debs & source packages, new packages/sources/contents, new releases, and as each release is written it becomes visible. [02:37] until a client sees the new releases, it will happily read the old packages.gz and debs etc [02:38] sign is separate now, but i'm told that in-line is done or soon to be done. [02:38] smoser: I'd be delighted to write up something somewhere, but I can't commit to implementing :) [02:38] we could publish both styles in parallel quite cheaply, and new clients would be more robust. [02:40] above, how would you atomically handle Releases ? [02:40] ie, that would still be a single path, right? [02:42] You don't need to, you just make sure you mirror Releases last. [02:43] (In lifeless's scenario) [02:43] The old Release file will remain valid for the old hashed Packages files, you get new hashes on disk, mirror new Release, maintain consistency. [02:43] It's elegant enough. Probably not wildly difficult to implement. Does make archives less human-navigable, though. [02:44] Perhaps a small price to pay. [02:44] (And fixable by making Packages.gz a symlink to the most recent hash, for people who prefer the fixed names for non-apt uses) [02:45] yeah. [02:45] lifeless: Can you write this up as an apt bug? I suspect mvo and I would both be interested in looking into it further. [02:45] lifeless: Doing it on the LP side is borderline trivial (or possibly even "for free", with an apt-ftparchive upgrade), but the apt side will take some thought. [02:46] sure [02:54] slangasek, why is plymouth not in the initramfs normally? I could have sworn it was supposed to be.. that would eliminate the gui vs text console early boot failure problem woudln't it? [02:55] psusi: it's not in the initramfs normally because it slows down the boot when it is, since you can't get out of the initramfs then until the video driver has loaded [02:55] (so the system waits, making no use of either cpu nor disk, while the video card is initialized) [02:55] * slangasek trades a negation for a vowel [02:56] psusi: I am increasingly thinking that we should just stick it in the initramfs and try to make up the boot speed impact elsewhere, but it's a bit late to be pondering this for 12.04 :/ [02:56] hrm... so it did used to be there? and to speed boot, it was removed because loading the video driver was wasting too much time? [02:56] video driver is kind of required for text mode console as well isn't it? ;) [02:56] psusi: it was only there for a short short time in the 10.04 dev cycle [02:57] maybe you had the cryptsetup packaged installed previously or something [02:58] how long does it take to init the video card anyhow? and doesn't it have to do that anyhow when you don't pass the quiet splash boot options? [02:59] which is certainly possible, as it gets installed in support of encrypted swap if you choose the encrypted homedir option in the installer [02:59] psusi: depends on the video card and driver and and; but it may be as much as a couple of seconds [02:59] (in various common cases) [02:59] wow! [02:59] yes, you have to init the video card anyway, but when you *don't* have to do it in the initramfs, you're not stuck *waiting* for it [02:59] You need to do all sorts of output probing, running BIOS scripts, etc. [03:00] RAOF, just to load the dri driver and not even switch video modes? [03:01] Yes, because loading the dri driver generally implies switching video modes. [03:01] :) [03:01] not any more... we have gfxpayload=keep [03:02] heh [03:02] The dri driver doesn't know that it's not going to switch video modes or bring up new outputs until it's probed all the outputs. [03:02] so... the video driver is still in the initramfs and loaded, just doesn't block switching to the real root? or you're saying it isn't even loaded until after the root is mounted? [03:02] yeah; gfxpayload=keep just means the framebuffer is passed to the kernel, it doesn't mean the drm driver is smart enough to *use* it [03:03] no, the video driver isn't included in the initramfs at all [03:03] unless you've asked for it to be [03:03] umm... then how is initramfs rescue recovery ever possible at all? [03:04] ohh, it's only possible when the kernel comes up still in VGA text mode? [03:04] that's no good at all... [03:05] this might tie into something else I was thinking of the last time I worked on ureadahead... why doesn't it start in the initramfs... if you're doing readahead while loading the video driver that should fix the slow down problem without breaking initramfs recovery [03:06] psusi: yes, precisely - and if you're booting in rescue mode, you *are* coming up in text mode, that's one of the differences between the main boot option and the fallback one [03:07] slangasek, of course, on macs or whatnot that don't have vga text boot and require fbcon, then you're screwed? [03:07] psusi: How do you propose we readahead before we have a rootfs to read ahead on? [03:08] psusi: what kind of macs are we talking here? [03:08] UEFI has its own framebuffer [03:08] infinity, you obviously mount the root fs first, but you can start the readahead and video driver load in parallel, all before you actually run-init the real root fs [03:08] and we're supposed to be using that, but I have certainly seen bug reports about it not working [03:09] psusi: you can't start the readahead until you have the root filesystem mounted to find the ureadahead pack data [03:09] psusi: If we've found the rootfs, we should be pivoting ASAP, there's no reason to stay in the initrd. [03:09] infinity, if you're still waiting for the video to init, you can at least start the readahead... [03:10] slangasek: To be fair, I'm not sure we can guarantee every device will have a usable text mode. We're only saved on ARM by building every subarch individually and building in framebuffers, that can't last if we ever have a unified ARM kernel. [03:10] if you do that, then delaying the pivot for a second or two doesn't matter since all you'd be doing after is waiting for the readahead anyhow [03:10] infinity: sure; we might prefer to special-case the initramfs video handling on different architectures then [03:11] anyway, as I said, I think we should bite the bullet and put the video in the initramfs - just not for 12.04 [03:11] oh, also, aren't we getting rid of initramfs on arm, making this a moot point ;) [03:11] slangasek: On some ARM machines, perhaps, I doubt we are on all. [03:11] it would be so freaking nice to have the splash up 1.5 seconds into the boot instead of 7 seconds when the desktop starts at 8 so you barely see it, but yeah cairo in the initrd, 20mb+ extra initrd size on proprietary drivers, etc.. [03:12] slangasek: And hey, if someone makes uBoot suck less, we won't really need to at all. [03:12] Sarvatt, exactly.. [03:12] psusi: so I think what I would prefer is to put the video drivers in the initramfs unconditionally, but *not* block the initramfs waiting for plymouth to start unless we know cryptsetup is in use [03:12] I thought most of the proprietary driver bulk was the xorg user mode driver part, not the kernel module? [03:12] slangasek: Though, really, any machine that doesn't NEED an initrd shouldn't have one. uBoot isn't the only bootloader that sucks at loading things from disks. [03:12] the kernel module is like 10mb last i checked for nvidia [03:13] what the crap? [03:14] wow... I guess fglrx_updates.ko is 4.3M... wow... [03:15] 17M /var/lib/dkms/nvidia-current/295.33/build/nvidia.ko [03:17] jesus... what the hell are they shoving in there? it wasn't that long ago that debian netinst came on two 1.44 MB floppies and that was the whole linux kernel plus root fs [03:18] no, no... it was that long ago :) [03:19] * psusi corrects himself... damn old misnomer... 1440K floppies, which is not 1.44 MB ;) [03:20] slangasek, so wait... can you even flip it back to vga text mode without the driver loaded? [03:21] well, *I* haven't managed to yet [03:21] I wouldn't think you could... [03:21] well [03:21] you should be able to do it as raw VGA [03:21] not using a kernel fb driver [03:21] infinity: or slangasek: could one of you copy chromium-browser lucid-oneiric from ubuntu-security-proposed to *-proposed* [03:21] but I haven't found the right tool for it yet [03:21] right, but you need something to modeset it back to vga mode don't you? [03:22] micahg: If you ask really nicely. [03:24] psusi: maybe? :) [03:24] micahg: (looking at it right now) [03:25] infinity: please.....with visions of bunnies and kittens [03:31] micahg: I assume we don't care about the oneiric build failures? [03:31] infinity: not enough to block the rollout [03:31] Alright. [03:32] LP is grinding, but it'll be done "soon". [03:40] micahg: Finally done. Double-check after the next publisher that it's all sane? [03:40] infinity: yep, thanks [03:42] smoser: infinity: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/972077 [03:42] Launchpad bug 972077 in apt (Ubuntu) "apt repository disk format has race conditions" [Undecided,New] [03:43] thanks. [03:45] lifeless: Danke. [03:48] infinity: I've elaborated a little, perhaps. Its likely we need to do some dance around mirror pushes to really hammer that down, but thats orthogonal - push mirrors are already pretty tightly synced, and the new format will self-correct as soon as they have all pushed (which the current one does not) [03:48] smoser: if you have a session on this @ UDS and you want me there - I'm attending remotely. [03:48] smoser: so feel free to put me in as mandator or whatever, but I can't make the first 2-3 hours of each day [03:49] lifeless, do not pretend to be mortal by implying you have to sleep [03:49] thanks for your help./ [03:49] I suspect mvo and I might want to take it upstream a bit, but a UDS session isn't out of the question. [03:49] right. upstream is correct, but we can have a good plan in ubuntu. [03:49] * infinity nods. [03:50] upstream honour patches :) [03:50] you can call the file Releases.lifeless if you want to give me cred :P [03:51] lifeless, are you opposed to forwarding that to upstream ? [03:51] Well, we already have InRelease (the inline signed version) [03:51] LinRelease? Lifeless's Inline Release? :P [03:51] smoser: I think its totally appropriate to be upstream [03:51] right. [03:52] (I'm sure we can do it in the existing InRelease withough adding a new file) [03:52] smoser: I think we need to resource doing it ourselves. Upstream doesn't move at our pace, nor have our cloud adoption, so won't be seeing it anywhere near as much. [03:52] Given that old clients verify from Packages->Release (not the other way). [03:52] lifeless, do you mind filing upstream? [03:52] lifeless: Some of us *are* upstream. [03:53] infinity: (InRelease) - cool : I didn't want to make assumptions about all the clients out there [03:53] But yeah, I think we could implement it in the current InRelease without breaking the world. [03:53] smoser: I think someone likely to be doing it should file it upstream. [03:54] I'll talk to mvo about it a bit, and then we can file upstream. [03:54] smoser: I'm really just applying my HTTP + doing whacky shit databases with filesystems knowledge here :) [03:54] lifeless, thats fine. [03:54] Or just implement it as a fait accomplis. [03:54] The more I think about it, the more it actually doesn't sound hard. [03:54] its clearly a valid bug wether or not we're going to work on it. [03:55] smoser: it is, but also the symptoms are already reported upstream [03:55] no, its not that hard. just different filenames. [03:55] smoser: No, I mean the client implementation. [03:55]