=== dendro-afk is now known as dendrobates === bjf is now known as bjf[afk] === tkamppeter_ is now known as tkamppeter === fta_ is now known as fta [00:55] slangasek: ok I have a little time [01:03] lifeless: hey there [01:04] hey [01:04] so tell me now, tell me true [01:04] lifeless: so the process I've been using for package merges is bzr co lp:ubuntu/$package; cd $package; bzr merge-package lp:debian/sid/$package; fwibble-fwibble; bzr commit [01:05] lifeless: and if I look at my local directory afterwards with 'bzr log -n0' or 'bzr tags', the upstream-$version tag is there [01:05] lifeless: and if I do a fresh checkout from lp:ubuntu/$package, the tag is *not* there [01:05] well [01:05] are you pushing back to lp:ubuntu/$package afterwards ? [01:05] oh [01:06] I see [01:06] uhm [01:06] workaround - don't checkout. [01:06] make a branch [01:06] then do 'bzr push :parent' after committing [01:06] workaround, yes :) [01:06] where should I file the bug? [01:06] please file a bug on bzr saying 'bzr commit in a heavyweight checkout does not propogate new tags' [01:06] thanks [01:06] ok [01:13] lifeless: bug #603395 [01:13] Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propogate new tags" [Undecided,New] https://launchpad.net/bugs/603395 [01:13] thanks [01:16] thanks slangasek, lifeless [01:18] de nada [01:18] its a one liner [01:18] but I doubt I'll get to it :( [01:18] EATADBUSY [01:21] eat a dbus? [01:21] E a tad busy [01:21] ohh [01:22] :-) [01:22] but I like your parsing too [01:23] I'm using the live cd and installing it. apparently there's a serious kernel problem. i'm gonna let the installer finish and update and find out what happens next === fta_ is now known as fta [02:22] I'm having a bit of trouble with DBus. It's spawning a Polkit-1 helper binary as root, but all the locale environment vars end up set as C [02:22] rather than the system locale [02:23] whereas starting the helper in a root shell results in the locale environment vars being the system locale [02:24] Is there anything I can do short of parsing /etc/default/locale to get the system locale? [04:00] if i did a 'bzr add foo' and then decide i don't want to commit foo, how do i remove it from the list of things to be committed? [04:01] bzr revert foo [04:02] lifeless: yuck. that actually undid my changes to foo. :( [04:02] achiang: they will be stored in a ~ backup file [04:02] i wanted to do the equivalent of git reset, aka unstage [04:02] achiang: are you perhaps a git user ? [04:02] lifeless: yes [04:02] struggling with bzr [04:02] bzr, like *every other VCS on the planet* has no staging area. [04:03] you might like the 'bzr shelve' and 'bzr unshelve' commands [04:03] lifeless: don't yell at me because git did it correctly [04:03] :P [04:03] they can take a change that you haven't committed and put it to the side for you [04:03] and restore it [04:03] lifeless: but thank you for pointing out the ~ backup files, that helped [04:04] achiang: I'd like you to get the most out of bzr; assuming it works the same way as git won't get you that :( [04:05] lifeless: i mean, point taken re: the tools work differently. i just would have expected that the inverse of 'add' wouldn't actually change the file [04:06] if the file was added, revert would have unadded it. [04:06] that expectation came from the fact that 'add' and 'commit' are two separate steps [04:06] Well, “bzr add” doesn't even do what you think it does — bzr commit will commit *all* changes, so you only need to add new files. [04:06] if the file was previously versioned, revert puts it back to the previously versioned state [04:07] (ie: the state of the versioned files on disc and the state of the tree that will be recorded by a commit is the same, barring selective commits via “bzr commit $FILE”) [04:07] RAOF: right, i've discovered that bzr commit wants to commit everything, so in my workflow, i've had to manually add the files i changed, and then manually commit them [04:08] lifeless: Incidentally, I didn't notice any colocated branches NEWS in the bzr 2.2 beta 4 notes - has that slipped from 2.2? [04:08] RAOF: maybe i don't need that separate add step ; i can just say: bzr commit foo bar baz [04:08] achiang: that doesn't make any sense to me - in git you might say that but in bzr 'bzr add' something that is already added is a no-op. [04:08] right [04:08] you just say 'bzr commit foo' if you want to commit just foo. [04:09] lifeless: right, that is just a git-ism. i was assuming that there was an index of some sort in bzr [04:09] * achiang stands corrected [04:09] There is, kinda - “bzr shelve” [04:09] achiang: There is no stage concept in bzr. [04:09] But it works the right way around - ie: by default, you commit your changes :) [04:10] thanks for the education. i appreciate it [04:11] bzr shelve is well worth exploring. It's tremendously useful if you want to separate out a bunch of changes into multiple commits. [04:11] do i need a plugin for that, or does it work out of the box? [04:11] Or just want to keep some debugging kruft uncommitted. [04:11] Out of the boz. [04:11] Ahem. Box. [04:11] cool [04:12] so, in git, i can say, "git show " which will show me the changelog and the patch. [04:12] is there an equivalent for bzr? to look at revnos? [04:13] bzr log -p -r X === fta_ is now known as fta [04:14] To expand on lifeless' comment, run “bzr alias show="log -p -n0 "”, then you can “bzr show -r$REVNO”, or just “bzr show” to get the full log. [04:15] yep, i was just about to add an alias [04:15] thanks lifeless, RAOF [04:15] oh! a bzr alias! [04:15] not a bash alias [04:15] Indeed. [04:15] neat [04:15] bzr is full of love. === emma_ is now known as emma [05:43] Good morning [05:43] robbiew: hello [05:44] pitti: hi [05:44] pitti: can't remember what I wanted...but I answered it anyway :) [05:44] hehe, the best kind === Amaranth_ is now known as Amaranth [06:19] uh, what happened to our buildds.. === fta_ is now known as fta [07:24] good morning [07:24] hey dholbach, wie gehts? [07:25] pitti: sehr gut - und dir? [07:25] dholbach: prima, danke [07:26] :-) [07:28] is this the part where you three all have a hug and a beer and pout about losing to spain? [07:28] * pitti hands dholbach a beer and hugs him over the loss [07:29] maco: great idea! [07:29] maco: although 8:30 in the morning is a little early for the beer part [07:29] hmm good point [07:29] * maco looks at mvo [07:29] a cup of tea? [07:29] * dholbach hugs pitti back [07:29] pitti: give that beer to mvo instead :-P === \vish is now known as vish [08:51] can somebody let rebuild https://launchpad.net/ubuntu/+source/bug-buddy/2.30.0+dfsg-1 ? [08:51] it builds fine now :) [08:52] didrocks: have you seen the banshee bugs regarding the netbook interface? [08:53] ScottK, NCommander: I'd appreciate if you could ack bug 603480 soon, so that we can coordinate the new binarymangler rollout next week; I'll take the responsibility and blame [08:53] Launchpad bug 603480 in lucid-backports "Please backport pkgbinarymangler 70 to lucid" [Undecided,New] https://launchpad.net/bugs/603480 [08:53] bug #602759 and bug #602760 [08:53] Launchpad bug 602759 in banshee (Ubuntu) ""Media" header makes no sense" [Undecided,New] https://launchpad.net/bugs/602759 [08:53] Launchpad bug 602760 in banshee (Ubuntu) "Doesn't display application menu in netbook mode" [Undecided,New] https://launchpad.net/bugs/602760 [08:53] didrocks: ^^ [09:02] can someone look at https://launchpad.net/ubuntu/+source/xine-lib/1.1.18.1-4ubuntu1 this needs also a rebuild [09:05] grant dupondje access on 'rebuild button' [09:05] :) [09:10] ricotz: it'll build now? [09:11] pitti, there seemed to be a problem with the archive it is building fine in my ppa [09:11] pitti, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1226883/+listing-archive-extra [09:11] ah, I'll retry [09:12] ricotz: done [09:19] pitti: https://launchpad.net/ubuntu/+source/bug-buddy/2.30.0+dfsg-1 => builds also now === fta_ is now known as fta === almaisan-away is now known as al-maisan [09:29] hie! is there a good place to find more information about Ubuntu udev implementation or its variance from Debian? [09:46] * psurbhi looking at debian/changelog in ubuntu and debian's udev package.. shall get back if needs more [09:58] https://launchpad.net/builders => we stop building for sparc ? [10:04] dupondje: do you miss it? [10:04] * pitti shakes hand with the new voluntary sparc maintainer [10:04] ack, powerpc too? [10:05] pitti: don't miss it no :) just wondering :) [10:05] powerpc is still an official port [10:05] sparc and ia64 were about to be removed [10:06] ah phew, just saw the powerpc builders were disabled too [10:06] that will fix alot of ftbfs ;) [10:07] no, there just seems to be something generally wrong ATM; half of the buildss are broken [10:13] There was a networking glitch earlier. [10:13] Probably just needs someone to flip the disabled switch on LP [10:16] cjwatson, i seem to remember saying "my machine isn't suspending every time i close the lid" and you mentioned some bug or other with perhaps pmutils, can you remember/point me at it again? [10:23] https://launchpad.net/ubuntu/+source/openbios-ppc/1.0+svn640-1/+build/1729379/+files/buildlog_ubuntu-maverick-i386.openbios-ppc_1.0+svn640-1_FAILEDTOBUILD.txt.gz => can we force to build it on PPC ? as thats why its ftbfs :) [10:24] dupondje, there's no way to say arch-all packages have specific build-arch requirements. this is a loooong standing issue which only affects, like, 3 packages [10:25] ok :) [10:26] is there a specific channel for xorg releated questions, something in the line of XorgOnTheEdge? I want to compile/configure/install llvmpipe, preferabley just install. [10:27] #ubuntu-x, llvmpipe is in libgl1-mesa-dri-gallium in xorg-edgers though [10:28] awesome thanks [10:28] apw: pm-utils is pretty much the userspace side of power management these days, but I know very little more about it than that [10:29] cjwatson, must have been someone else, no worries [10:32] cjwatson, so this pretty grub work ... whats the next step. i am getting close to cleanish set of patches here, not sure if they will ever be acceptible upstream but at least they are small and self contained [10:33] i assume we're not ready for them to be in the kernel yet, so perhaps we need a PPA with the bits in? so people can test ? === amitk is now known as amitk-afk [10:40] apw: can we at least try to get them upstream? it would make it easier to get the corresponding grub changes upstream [10:40] apw: due to an upstream conversation I'm currently working on writing a no-probe simple linear framebuffer device for the kernel [10:41] apw: sort of like efifb but guaranteed never to do anything firmware-specific [10:41] if i am honest i suspect noone would accept the current approach [10:41] apw: I thought it was all nicely tunable now and switched off by default [10:41] the "correct" approach probabally is a frame buffer which knows its already filled in like plymouth does [10:41] apw: we need both [10:41] the framebuffer device can't help when fbcon just goes and clears the screen [10:41] which picks up the contents and handles it, and then us not moving over to VT7, ie X on VT1 [10:42] no no no no nooooo [10:42] i am telling you what they are going to say [10:42] I don't see why [10:42] what we are doing now is just ignoring the kernels desire to clear and update the VT until we switch to VT7 [10:42] there's no intrinsic reason X needs to move to vt1, and it breaks so much documentation [10:42] which is at vest vile [10:43] yes its all configurable, but what it does is utterly underhand [10:43] so, wait, I didn't ask for no updates [10:43] I only asked for no clearing [10:43] which I think is much less underhand and much simpler [10:43] the only thing that occurs is the clearing though [10:43] oh and not turn [10:43] and not turning on the cursor [10:44] yeah, but that's already upstream [10:44] I really don't see that disabling the screen-clear until boot is finished is all that underhand [10:44] well except that what you want is not showing the cursor randomly while we are on VT1 the first time, but on for the second time [10:44] i am even struggling to put the semantics down in english! [10:45] the problem with this not going upstream is that we have no other way to reserve the flags bit [10:45] and not having a flags bit for it is really pretty nasty in grub, as I mentioned [10:45] in the failure to upstream case we could submit a 'bootloader specific' bit or something [10:46] or 'distro specific' [10:46] shouldn't be distro-specific [10:46] why don't we have the upstream conversation rather than giving up before we start? :) [10:46] oh we will, but they won't take sensible patches i suspect they will puke when they see what we have done [10:47] this is *neater* than the no-cursor stuff which already went upstream [10:47] and they will gladly tell you to confuse all your users to make things clean in the code [10:47] (which turns it off permanently, and requires horrible hacks in the login binary to turn it on again per-VT ...) [10:47] really? i don't think it is nice at all, it has horrible semantics [10:48] necessary semantics perhaps, well only cause we want to switch VTs [10:48] depends on your point of view I suppose [10:48] right, i am a sensible person and can see we might need to do it, but that doesn't stop it pegging my vile meter [10:48] but I think the fact that the no-cursor patch already went upstream, and the fact that folks were working on plymouth/X framebuffer handover, indicates that it isn't just us interested in this [10:48] I don't mind if we end up with something different that meets the same basic requirements [10:49] what I don't want is to have to have fundamentally distro-specific code in the linux loader in grub [10:49] all understandable [10:49] i am just warning you that i think we're on for a beating [10:49] because that introduces some real problems - the same linux loader is used for booting Ubuntu and booting other detected OSes [10:50] which had better ignore unknown bits me thinks [10:50] * mvo hugs dholbach [10:50] I'd actually welcome a discussion about the semantics; I agree they're grotty as it stands and perhaps somebody can come up with better ones [10:51] I'm hoping that this is an example of "post wrong code on the internet and somebody will suggest right code" [10:51] at least get the discussion going ... [10:51] * dholbach hugs mvo back [10:51] heh indeed. well it needs some more shining before its ready for that, but its close [10:52] actually, surely there's only *one* screen-clear we need to kill [10:52] the one when fbcon starts [10:52] do we have to care about vt switching or any of that gubbins? just remember whether it's the first screen-clear or not ... [10:53] cjwatson, no cause you don't want the vt switch to smack you either right [10:53] which vt switch? [10:53] from vt1 to vt7 [10:53] the one to X is already handled in other ways, or at least it was [10:53] X is supposed to snarf the framebuffer contents on its way up [10:53] we don't need to solve that problem again [10:54] (I think it snarfs the contents before the vt switch) [10:54] perhaps this is still doing more than it needs to suceed [10:54] will poke some more [10:54] the switch from vt1 to vt7 takes place when we start plymouth [10:55] tseliot, before or after plymouth actually starts [10:55] therefore when X starts we're already on vt7 [10:55] that was more my belief too [10:56] tseliot: are you certain about that? I thought we changed that in lucid [10:56] so we have VT1 init which clears, VT1 -> VT7 switch which repaints a blank screen too [10:56] apw: but again, there's no need to address the latter problem in the kernel [10:56] apw: if it exists, plymouth can deal with it the same way X does - snarf the framebuffer contents before the VT switch [10:57] hrm [10:57] cjwatson: yes, I'm pretty sure. X simply doesn't clear the framebuffer when it starts on the same vt as plymouth [10:58] tseliot: ok, well in that case do you agree that plymouth can solve this problem? [10:58] apw: I think we tell plymouth to use vt7, let me check the code [10:58] I think you're right, from the changelogs, I'm just misremembering [10:58] cjwatson: what's the problem again? I think I've missed part of the discussion [10:59] tseliot: trying to eliminate black screens between grub and plymouth [10:59] cjwatson, the problem then becomes is how does plymouth get the framebuffer contents, when the VT isn't even in framebuffer mode [10:59] apw: you mean KD_GRAPHICS? [10:59] cjwatson, indeed [11:00] now maybe thats what we should be doing, putting VT1 into KD_GRAPHICS instead [11:00] cjwatson: the problem is that plymouth clears the screen when it starts [11:00] tseliot, that is simply a bug though right ? [11:00] tseliot: userspace problems are shallow :) [11:00] (in this context) [11:01] tseliot: I'm trying to figure out exactly what we need to change at the interface between grub and the kernel [11:01] tseliot: we know that, at minimum, we need to stop fbcon init from clearing the screen [11:01] cjwatson, so now i wonder what would happen if we simply dropped VT1 into graphics mode based on your bit [11:01] tseliot: what else do we need to change in the kernel? [11:01] apw, cjwatson: yes, it's something that can be fixed in plymouth. The only problem is that is that if you copy the fb content from a framebuffer that uses a different resolution, the result is ugly [11:02] actually [11:02] I'm entirely happy for plymouth to repaint the whole screen, it's going to do that anyway (based on the theme) and there's a possibility of a resolution change here which is something I'm prepared to cope with (one problem at a time!) [11:03] all I want is for it to be a clean switch [11:03] as in, no flicker to black === smb is now known as smb-afk [11:03] tseliot, what interface does X use to read the framebuffer contents [11:03] so I guess it doesn't have to read the framebuffer contents [11:03] well, what I was trying to say is that plymouth clears the screen with a big black rectangle first and then draws the splash [11:04] tseliot: ok, does it have to have the foreground vt before it does that? [11:04] tseliot, why the HECK would one do that [11:04] 'i am going to write over the whole screen with a splash, lets waste my time and make it shiney first' ??? [11:04] apw: in case the resolution doesn't match [11:05] as long as it's doing all this to a non-displayed framebuffer, I really don't care if it puts polka-dots on there first [11:05] er, a non-displayed buffer [11:05] cjwatson: would you like to vtswitch only when the splash is ready? [11:05] yes [11:05] I'm not sure it's possible [11:05] graphics mode is raw isn't it [11:06] ie when a mode is GRAPHICS, then you can't write unless you are the 'current' vt [11:06] or, at minimum, at least prepare a suitable buffer and blit it over at once after the vt switch [11:06] but then the kernel probably will clear the screen, so still not idea [11:06] *ideal [11:07] not sure it will from <-> to GRAPHICS [11:07] apw: yes, something weird would happen [11:07] looking at X [11:07] as far as I can tell, it actually doesn't read the framebuffer contents at all [11:07] cjwatson, why do we need to VT switch? this is just to make peoples fingers happy that we are on VT7 yes ? [11:07] it just refrains from clearing them [11:08] cjwatson, what if we just told the kernel that the default VT was 7 [11:08] cjwatson: we can copy the content of fbcon (if the resolution matches) [11:08] the web is full of documentation that says "when stuff going wrong, you can get a login prompt with ctrl-alt-f1" [11:08] apw: that would break server boots. I'd really rather not go there [11:08] cjwatson, right ... happy with that ... what if we made the default VT-7 [11:08] why would it break server boots [11:09] they get the same graphics poop we do, then they do something to get the login prompt yes? [11:09] cjwatson: right, X simply creates a root window with no background which makes it possible to see what the framebuffer left [11:09] a vt switch to 1 i assume ? [11:09] well, not necessarily, a lot of server people disable the splash [11:09] right and without splash you'll go back to textual grub and not pass me the bit right ? [11:09] no, splash is just a word in the command line [11:09] grub refrains from trying to parse that stuff, it isn't generic [11:10] cjwatson, can i just say you are making this hard :) [11:10] system design back 20 years is making this hard [11:10] I'm just trying not to break it [11:10] surley we can jsut put a login on VT-7 for server :) [11:10] if you think it's hard to get the rest of this upstream, try getting a change of the default VT upstream [11:11] cjwatson, i was proposing to make the default change only on a bit asking for it, or a command line option asking for it [11:11] can we separate out these two problems? [11:11] actually a command line option would work with server well as well [11:11] I'm not trying to solve everything at once [11:11] avoiding the clear on fbcon init would be brilliant for now [11:12] and I don't mind if it takes longer to sort out the rest [11:12] indeed, but the point is there are two issues... that init clears stuff is bad, that the VT switch will too is bad [11:12] sure, but I think they need different solutions [11:12] and the latter is much less intrusive anyway [11:12] cjwatson: I assume that you want to use the fb that grub provides. Am I right? [11:12] init clearing stuff leaves us with a black screen for multiple seconds [11:12] the VT switch to plymouth will be at most a flickere [11:12] *flicker [11:13] well perhaps without some idea of how we are going to resolve it may change how we resolve the other issues [11:13] ok [11:13] tseliot: well - grub will program an fb in order that we have something, but I expect it to be reprogrammed by the switch to KMS [11:14] all I'm really trying to get round here is the several seconds of black screen before plymouth starts [11:14] cjwatson: right but some flicker would still happen if the resolution changes [11:14] papering over the join is tricky, but as long as all of the images are as identical as we can make them (modulo resolution) then it will be an improvement over what we have today [11:14] I don't want the perfect to be the enemy of the good here [11:14] still better thana black screen for sure though [11:14] than [11:14] we can sit here all day saying that we can't make it perfect, but there are definitely improvements we can make [11:15] * tseliot nods === amitk-afk is now known as amitk [11:15] and I don't think it can ever be exactly right unless (a) grub gets support for programming native panel resolutions or (b) the native panel resolutions are loaded into the vbe bios [11:16] the former seems more realistic to me ;) [11:16] (whether (b) would result in a flicker is still questionable, apparently the kernel does have to switch off the panel briefly right now but mjg59 doesn't seem to think that's an intrinsic problem) [11:16] ah [11:17] something to do with changing the panel scaler [11:20] apw, cjwatson: so, to sum up, would it be useful if I made plymouth copy whatever it's in fbcon when it starts? [11:20] tseliot, what does 'in fbcon' mean ... and how and where do you get to it [11:21] tseliot: is it possible if the vt is in KD_TEXT mode? [11:21] tseliot: I actually don't think it would be useful, though, thinking about it [11:22] tseliot: we want to inhibit the screen-clear [11:22] tseliot: but that may be partly in the kernel and partly in plymouth [11:22] cjwatson, as you know what is in there anyhow right, its in /boot/grub/logo.png [11:22] right, well ultimately I was going to try to get that dynamically from the plymouth logo [11:22] but yes [11:22] apw: if grub puts something in the framebuffer, I can copy its content by mapping the framebuffer [11:23] (the approach I gave you is resolution-specific) [11:23] tseliot: is this significantly different from not clearing to black and just drawing it again, though? [11:23] cjwatson: not much [11:24] remind me, when does the switch to kms happen? it's before plymouth starts, isn't it? [11:24] but it can take a while before you see the splash [11:24] kms happens when the driver loads [11:24] or rather, it's before plymouth-splash starts [11:24] yes, as plymouth's drm plugin requires kms [11:24] (kernel driver) [11:24] so what happens to existing framebuffer contents when we switch to kms? [11:24] right [11:24] they'll be cleared, won't they? [11:25] cjwatson, well they get redrawn, from the VT contents [11:25] apw: VT text contents, or the prior framebuffer contents? [11:25] apw: if the latter, presumably they aren't rescaled (they couldn't be since there may have been text drawn on top) [11:25] if its in text mode the text contents [11:26] (i can't see how it could do anytning else) [11:26] what if it's in graphics mode? [11:26] then i believe the kernel asks the mode owner to redraw it [11:27] that's if it's VT_PROCESS too, presumably [11:27] you can be KD_GRAPHICS && !VT_PROCESS, IIRC [11:28] and indeed if we were doing something where the kernel starts in KD_GRAPHICS, you'd have to be [11:31] so I suppose grub does have to be made to know whether there's going to be a splash screen [11:31] if there isn't, then it may well want to keep the better mode (people tend to like big framebuffers as long as they aren't too slow), but it shouldn't preserve the screen contents [11:31] cjwatson, vt relies on being able to tell someone to redraw on a resize as far as i can see [11:32] whether that is fbcon or X [11:32] oh, and as regards clearing the screen in plymouth, some time ago I spoke with upstream and they told me that: [11:32] I can only find the text-mode vt resize code [11:32] with drm modesetting plymouth gets its own "screen" that it swaps in [11:32] so it's not really clearing the screen, just detaching it and putting a new on in place [11:32] but the initial contents of that "screen" is black [11:33] tseliot: in that case it should be easy to draw the splash before swapping it in, if it doesn't do so already [11:34] I guess it's not as fast as ideally it should be then, if we can see the black screen [11:34] apw: anyway, when Scott and I tested this a few months back, there seemed to be some plymouth bug that broke things on resize, but aside from that the duration of the flicker on resolution change wasn't particularly long IIRC [11:35] cjwatson, and you were testing with the patch i started from ? [11:35] IIRC yes [11:36] and that patch simply turned off all VT updates in text mode [11:36] apw: would setting the vt to KD_GRAPHICS on initialisation be enough to inhibit the screen-clear from fbcon_init? [11:36] cjwatson: it would take some restructuring but it would definitely be possible to do what you suggest by making plymouth render the 1st frame of the splash so that we could have that instead of the black screen [11:37] apw: if KD_GRAPHICS + VT_AUTO works at all, and if it has that effect, I think it might well be what we want [11:37] cjwatson, it not clear you have failure tollerance in that case, or indeed if it would survive the KMS mode change [11:38] let's ignore the latter, it's not obvious it's soluble at that point [11:38] failure tolerance? you mean things like the ability to display oopses? [11:38] or indeed to switch to VT-1 to see the text that the kernel put on it yes [11:38] I think the solution for that is "disable splash", isn't it? [11:39] yes, it's not nice to leave things in KD_GRAPHICS is something goes wrong [11:39] if [11:39] ok, so maybe KD_GRAPHICS won't fly [11:40] in that case simply inhibiting the initial clear seems like the only kernel change that's particularly viable right now? [11:40] * Ignore all switches in KD_GRAPHICS+VT_AUTO mode [11:41] that's probably not good [11:41] cjwatson, our KMS story is going to look bad i suspect if its going to clear when kms loads [11:41] apw: it will look better than it does now :-) [11:41] we don't start plymouth till after ureadahear on spinning media i think right? [11:41] so we'll still get 10s of black [11:43] ureadahead is 'start on starting mountall' [11:43] plymouth is 'start on (starting mountall or [other stuff])' [11:43] plymouth-splash is 'started on started plymouth and [got a graphics device]' [11:44] I don't know if there's something that explicitly serialises ureadahead before plymouth, but if there is I can't find it [11:44] cjwatson, cirtianly on my machine i have black for most of the time ureadahead is runnign [11:45] but its hard to know if thats kms not loaded yet or what [11:45] my suspicion is that that is Keybuk's intention but is not guaranteed, but that's just my reading of the job graph [11:45] well - udev is 'start on virtual-filesystems' [11:46] udevtrigger is 'start on (startup and started udev)' [11:46] and virtual-filesystems is emitted by mountall [11:46] so you won't get the kms event until ureadahead is done [11:46] I mean, userspace won't notice [11:47] if it were KD_GRAPHICS + VT_AUTO, then theoretically we could rescale the existing framebuffer contents [11:47] cjwatson, who can ? [11:48] it would have to be the kernel [11:48] deep joy [11:48] yeah, I know. I can't think of any other way to do it [11:49] cjwatson, ever played with the fbcon logo ? [11:49] no, although it did occur to me just a few minutes ago [11:49] is that scalable? [11:49] cjwatson, if i am honest i have no idea what it even is [11:50] though i have seen a penguin drawn on boot in videos so it could be that [11:51] I bet it's not themeable in the ways we'd need [11:51] I think I played with it in about 19198 [11:51]