| ScarFreewill | ogasawara I'm just curious about the timezone, you're in Canada right? Anyhow it seems to be working fullscreen in both the default kernel and the one I got from launchpad. | 00:35 |
|---|---|---|
| ogasawara | ScarFreewill: so your issue is resolved with the latest 2.6.32-19.28 kernel (ie you don't need the patches I built into the test kernel) | 00:36 |
| ogasawara | ScarFreewill: which bug do you fall under in https://bugs.edge.launchpad.net/ubuntu/+bug/533784/comments/14 ? | 00:38 |
| ubot3 | Malone bug 533784 in debian "[Radeon kernel module] drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command stream" [Unknown,Confirmed] | 00:38 |
| ScarFreewill | yeah both issues I had | 00:38 |
| ogasawara | ScarFreewill: as my patches only resolve issue #2 | 00:38 |
| ScarFreewill | drmRadeonCmdBuffer: -12 | 00:39 |
| ogasawara | ScarFreewill: well, I guess it doesn't hurt to post a comment to the bug that you no longer experience the issue with the stock 2.6.32-19.28 kernel. | 00:41 |
| ScarFreewill | yeah I will do that, just want to run one or two more tests to be really sure. | 00:42 |
| ogasawara | ScarFreewill: sounds good. thanks for testing. | 00:43 |
| ScarFreewill | no problem, thanks for the help | 00:44 |
| apw | RAOF, hi | 08:35 |
| RAOF | apw: Good morning to you. | 08:35 |
| apw | something something quirk something | 08:35 |
| RAOF | Yeah. A quirk for nouveau to disable acceleration on a couple of cards. | 08:36 |
| apw | RAOF, did you send it yet? | 08:36 |
| apw | i don't see it on my patch list yet | 08:37 |
| RAOF | Not yet; I'll do so now. | 08:37 |
| RAOF | By send it, you mean to kernel-team@, or attached to a bug lovingly tied with a ribbon with your name on it? | 08:37 |
| apw | kernel-team@ is where they get into our patch tracker | 08:38 |
| RAOF | Ok. I'll wrap it up in a git-format-patch and bundle it off. | 08:39 |
| apw | make sure it has the buglink: in it :) | 08:40 |
| RAOF | It'll have two. | 08:40 |
| cjwatson | hi, I don't have mail access right now, but could somebody apply http://paste.ubuntu.com/410932/ for lucid, assuming that we're going to include the xen-{blk,net}front udeb patch that smb sent to kernel-team@? | 10:27 |
| cjwatson | that would let us build a netboot image more or less suitable for xen | 10:28 |
| cjwatson | build-tested, seems to DTRT | 10:28 |
| apw | cjwatson, looking | 12:07 |
| apw | cjwatson, will sort that out ... | 12:08 |
| cjwatson | thanks | 12:08 |
| apw | sorry been reviewing 100 odd patches and not looking at irc | 12:10 |
| dmarkey | apw: re: [PATCH 1/1] UBUNTU: d-i -- enable udebs for generic-pae, when/where would i be able to get my hands on an image/install initrd, to test? | 13:16 |
| apw | dmarkey, heh ... you are quick ... | 13:16 |
| apw | dmarkey, if a new kernle image is all you need i can get you one of those pretty easy | 13:17 |
| apw | if you need real isos then they are hard to make and you'd have to wait for the kernel to go up | 13:17 |
| dmarkey | all im looking for is a kernel and an _inatall_ initrd | 13:18 |
| dmarkey | install* | 13:18 |
| dmarkey | for netboot | 13:18 |
| apw | dmarkey, not sure how one makes those special initrds | 13:19 |
| apw | cjwatson, do you know if its easy to make the installer initrds separatly from the iso's ? | 13:19 |
| amitk | 13:58 < ogra> well, on systems that dont use initramfs you dont want the package to forcefully create one | 13:19 |
| dmarkey | i know the netboot initrd is slightly different for the server/iso one | 13:20 |
| amitk | 13:59 < persia> Indeed. kernel-img.conf should always be respected, and every type of installer should create it. | 13:20 |
| amitk | apw: ^^^ what ogra said about initramfs | 13:20 |
| ogra | apw, was that changed in lucid ? | 13:20 |
| ogra | usually "do_initrd = yes" in /etc/kernel-img.conf rules if update-initramfs is run or not | 13:21 |
| apw | that file is used by the postinst etc isn't it? and none of that has changed | 13:21 |
| ogra | and the live image doesnt have a kernel-img.conf so if i install a kernel .deb it shouldnt run update-initramfs | 13:22 |
| ogra | yeah, i think there is a piece in the postinst that checks kernel-img.conf | 13:22 |
| ogra | some ugly perl cod iirc | 13:23 |
| apw | i am not sure we do anything with do_initrd though | 13:23 |
| apw | i actually cannot see any support for that variable doing anything, ever | 13:25 |
| apw | it doesn't seem to be honored in hardy even | 13:25 |
| ogra | weird | 13:25 |
| amitk | is this the first time we're try images w/o initramfs? | 13:25 |
| amitk | *trying | 13:26 |
| * apw isn't sure we've been able to do normal boots really without one | 13:26 | |
| ogra | i'm sure i didnt have installing a kernel .deb ever running update initramfs if no kernel-img.conf existed | 13:26 |
| apw | so i can see it wouldn't work quite easily | 13:26 |
| apw | the kernel understands the variable, parses it etc, and uses it for exactly nothing all the way back to hardy at least | 13:26 |
| ogra | amitk, we dont do images without initrd but we start to support systems without it or at least move towards that | 13:27 |
| ogra | the OSG team has installs without initrd | 13:27 |
| apw | perhaps /usr/sbin/update-initramfs is meant to understand it | 13:27 |
| ogra | the images will always need one | 13:27 |
| ogra | apw, well, but what calls update-initramfs at all now ? | 13:28 |
| apw | the kernel post inst for one | 13:28 |
| cjwatson | apw: I can do it | 13:28 |
| ogra | a simple dpkg -i linux-image*.deb didnt exec update-initramfs in the past | 13:28 |
| cjwatson | apw: only after I have the kernel bits though :) | 13:28 |
| cjwatson | apw: honestly, it's easier for dmarkey to be patient for a day or two more ... | 13:28 |
| apw | cjwatson, yeah i was thinking the same | 13:28 |
| cjwatson | dmarkey: it isn't quite that simple, the installer initrd expects to be able to load further udebs from the archive, usually | 13:29 |
| dmarkey | oh yes, which dont exist yet | 13:29 |
| apw | ogra, i cannot see how that could be, we unconditioanlly call initramfs creation based on $initrd which is unconditionally YES | 13:31 |
| ogra | weird | 13:32 |
| apw | same in hardy | 13:32 |
| cjwatson | https://wiki.ubuntu.com/FoundationsTeam/Grub2Efifb - results of discussions between Keybuk and me, if anyone would like to look over it from a kernel POV | 13:44 |
| cjwatson | the "Notes from pre-BoF" section is the interesting bit | 13:44 |
| dmarkey | cjwatson: but in userspace, the udebs can be the same as non-pae i386 archive | 13:45 |
| cjwatson | dmarkey: doesn't matter | 13:46 |
| cjwatson | dmarkey: not all the kernel udebs are built into the netboot initrd | 13:46 |
| dmarkey | i see, so supplemental modules etc | 13:47 |
| === bjf-afk is now known as bjf | ||
| apw | cjwatson, there doesn't seem to be much there for kernel really ... just a 'new kernel' | 16:04 |
| cjwatson | apw: and a config change, and the linked patch or similar | 16:05 |
| apw | we are likely to have .35 maybe even .36 ... | 16:05 |
| apw | the patch needs some love as it is being ripped to shreds in review | 16:05 |
| mjg59 | I'm really not clear on why this is preferable to vesafb | 16:12 |
| apw | cjwatson, so this udeb change, do you want me to expedite an upload with that so it ends up in an image sooner? though that might mean we do two not one upload before release ? | 16:12 |
| apw | i guess efi is the way of the future? | 16:14 |
| mjg59 | apw: If you're using efi, you generally don't have vesa | 16:15 |
| cjwatson | mjg59: it seems, frankly, a hell of a lot simpler | 16:15 |
| cjwatson | mjg59: efifb drawing is not dependent on efi, it's just a badly-named simple linear framebuffer | 16:15 |
| mjg59 | cjwatson: Yeah, but so's vesafb | 16:15 |
| cjwatson | which grub already knows how to program | 16:15 |
| cjwatson | existing code > hypothetical code | 16:15 |
| cjwatson | apw: no desperate rush, but I wouldn't want to be too squashed for time - is there an upload planned for shortly after beta-2? | 16:16 |
| mjg59 | Handoff between vesafb and kms is supposed to work | 16:16 |
| apw | i was planning on just one more early next week i guess. though i will be doing a pass to slurp up all the pending patches 'now' ... so i could push that too | 16:17 |
| cjwatson | why should I bother changing grub to set up vesafb rather than efifb, is what I want to know | 16:17 |
| cjwatson | what's the point | 16:17 |
| mjg59 | cjwatson: I don't understand | 16:17 |
| mjg59 | cjwatson: grub doesn't set anything up | 16:17 |
| cjwatson | that is false. | 16:17 |
| mjg59 | It sets a mode | 16:17 |
| mjg59 | There's a defined mechanism for passing video mode information to the kernel | 16:18 |
| cjwatson | and it feeds it into the screen_info structure and sets the word in the boot parameters that causes the kernel to use efifb | 16:18 |
| cjwatson | if you use gfxpayload=keep that is | 16:18 |
| cjwatson | this *all works right now*, aside from a tiny number of adjustments needed | 16:18 |
| cjwatson | I see no benefit in redesigning it ... | 16:18 |
| mjg59 | If screen_info is populated, then loading vesafb should just work | 16:18 |
| cjwatson | and so does loading efifb | 16:19 |
| cjwatson | which seems a lot more lightweight | 16:19 |
| mjg59 | As long as it's set to VIDEO_TYPE_VLFB | 16:19 |
| cjwatson | either way, we'd need to get fbcon to stop clearing the screen | 16:19 |
| cjwatson | so I don't see the difference | 16:19 |
| mjg59 | Ok. As far as I can tell, the only distinction in functionality here is whether grub passes VIDEO_TYPE_EFI or VIDEO_TYPE_VLFB | 16:20 |
| mjg59 | If grub is passing VIDEO_TYPE_EFI when it's not using EFI, then it's buggy | 16:20 |
| cjwatson | what I'm asking is why I should bother changing anything at all | 16:20 |
| cjwatson | given that efifb appears to work perfectly well | 16:20 |
| mjg59 | Things will then potentially break if we ever start supporting the EFI virtual machine and using EFI for modesetting under the kernel | 16:21 |
| cjwatson | is that at all likely? | 16:21 |
| mjg59 | Because the bootloader is lying to us about the hardwre capabilities | 16:21 |
| mjg59 | I worked on it for a while | 16:21 |
| mjg59 | But stopped when I found that no hardware I had supported the modesetting | 16:21 |
| mjg59 | I think that's starting to change now, though | 16:21 |
| mjg59 | I should actually check whether my current laptop does | 16:22 |
| cjwatson | does vesafb still completely screw suspend/resume? | 16:23 |
| cjwatson | or is that just a matter of vbe save/restore now? | 16:23 |
| mjg59 | Yes, but no more than efifb | 16:23 |
| mjg59 | You'll never get reliable suspend/resume without KMS | 16:23 |
| mjg59 | Oh, yeah | 16:23 |
| mjg59 | It's also worth noting that programming KMS from a vesa mode is basically untested | 16:24 |
| cjwatson | well of course, I just don't want to completely fuck it beyond redemption | 16:24 |
| cjwatson | well, except that several thousand people seem to have started using gfxpayload=keep in lucid against my recommendations | 16:24 |
| mjg59 | cjwatson: efifb and vesafb have identical properties from a suspend/resume point of view | 16:24 |
| cjwatson | ok | 16:24 |
| mjg59 | And both are irrelevant if you've done kms handoff | 16:24 |
| mjg59 | So, really, I'd recommend getting grub to pass the correct argument and just using vesafb | 16:25 |
| mjg59 | It's really a bug that efifb doesn't check efi_enabled before binding | 16:26 |
| cjwatson | I can probably manage to test that today | 16:26 |
| cjwatson | Scott already has most of the pieces set up | 16:26 |
| mjg59 | But in either case, you're likely to hit some number of cases where novueau/radeon/intel fail to go from vesa mode->native | 16:26 |
| mjg59 | I know that some people have trouble if they boot with vga=, which is equivalent | 16:26 |
| mjg59 | It ought to work, but like I said, it's less well tested | 16:27 |
| cjwatson | one possibility is to configure things this way only if KMS is there when you run update-grub | 16:27 |
| cjwatson | oh, that *is* KMS sorry | 16:27 |
| mjg59 | Right | 16:27 |
| mjg59 | It's all something of a mess | 16:27 |
| cjwatson | are those bugs typically moderately tractable? | 16:27 |
| mjg59 | Yeah, just generally not high priority | 16:27 |
| Keybuk | right, efifb vs. vesafb is just which one the kernel happens to pick | 16:28 |
| cjwatson | are there any references I could gather on what the problems tend to be? | 16:28 |
| mjg59 | Not that I can think of | 16:28 |
| mjg59 | Text mode on a given card is generally pretty standard | 16:28 |
| Keybuk | fwiw, we have a reasonable number of people using grub's gfxpayload=keep now without problems | 16:28 |
| mjg59 | But vendors may fiddle with what a given vesa mode on a card actually is | 16:28 |
| mjg59 | Keybuk: Right, like I said, it *should* work | 16:28 |
| cjwatson | I thought half the point of KMS was to reprogram from scratch | 16:29 |
| mjg59 | But there are some people for whom it doesn't | 16:29 |
| Keybuk | mjg59: do you have bug reports for these? | 16:29 |
| mjg59 | cjwatson: Yeah, but graphics hardware is hard | 16:29 |
| mjg59 | Keybuk: I don't generally follow the graphcis bugtrackers - this is from people popping up on IRC | 16:29 |
| mjg59 | I mean, it's worth you going for it | 16:29 |
| Keybuk | those people could be having issues with the buggy handover in .32 of course | 16:29 |
| apw | cjwatson, what do we gain in going graphics in grub, if we are in a non-native mode and have to mode switch and get a flicker from that? | 16:30 |
| mjg59 | But it's "simpler" to not show a graphical bootloader at all, and just stay in VGA text until you load a native driver | 16:30 |
| cjwatson | apw: smooth splash all the way from the bootloader, and slightly faster boot | 16:30 |
| mjg59 | The kernel will now avoid turning on the blinking text cursor if grub turns it off | 16:30 |
| Keybuk | mjg59: the trouble is that that means 45s of a black screen with a flashing text cursor | 16:30 |
| Keybuk | or even 45s of a plain black screen | 16:30 |
| Keybuk | setting some kind of mode and a logo in grub covers that | 16:30 |
| cjwatson | mjg59: is that recent? I saw that broken fairly recently | 16:30 |
| mjg59 | Well, for most modern hardware, grub can't set the native resolution | 16:30 |
| cjwatson | that may change | 16:31 |
| cjwatson | phcoder has been vaguely seriously talking about importing KMS code into grub | 16:31 |
| apw | yeah unless it can do native we may just get a new flicker | 16:31 |
| cjwatson | I think he's insane, but it's entirely possible he can do it | 16:31 |
| * apw hides from that | 16:31 | |
| mjg59 | cjwatson: Right, but that avoids the problem differently - a lot of KMS modes are tiled rather than linear | 16:31 |
| Keybuk | apw: this doesn't introduce any new flicker fwiw, just ensures that the time until the second one is colourful | 16:31 |
| mjg59 | So you can't use a trivial framebuffer anyway | 16:32 |
| apw | Keybuk, and that i concur has to be better | 16:32 |
| cjwatson | still, IMO not-black-screen is better than flicker-free | 16:32 |
| cjwatson | err | 16:32 |
| cjwatson | rearrange that until it makes sense | 16:32 |
| mjg59 | Heh | 16:32 |
| * apw gets totally pissed off with the gdm theme which will not update to the latest ... | 16:33 | |
| apw | who do i hastle to find out how to change it | 16:33 |
| Keybuk | it also means | 16:33 |
| Keybuk | fwiw | 16:33 |
| Keybuk | that we always have a relatively decent framebuffer | 16:33 |
| Keybuk | even if everything fucks up | 16:33 |
| Keybuk | which makes the failsafe X cleaner, since we can just always fall back to fbdev | 16:33 |
| cjwatson | mjg59: interesting, I wonder what to do about that | 16:33 |
| Keybuk | (which X does itself) | 16:33 |
| mjg59 | cjwatson: Hm. Actually, maybe we do attempt to ensure that you have a linear framebuffer, and then X changes over to tiled (without a modeset) | 16:34 |
| mjg59 | Not sure of that, though. | 16:34 |
| apw | Keybuk, i meant to ask, is the reason plymouth has a kms driver per kernel kms driver ... because the framebuffer is non-linear, ie. tiled | 16:34 |
| cjwatson | what I meant to say above is that I don't think it's vital that the mode in grub is always 100% absolutely guaranteed to be the same as the one we end up in | 16:34 |
| cjwatson | it would be *nice*, but the world won't end if it's not | 16:35 |
| mjg59 | Keybuk: d9b263528e01bfbaf716b51f38606b3dfe5ac1e9 | 16:35 |
| Keybuk | apw: no, it's because the kernel sucks | 16:35 |
| Keybuk | mjg59: neat | 16:35 |
| apw | heh nice | 16:35 |
| Keybuk | apw: Plymouth allocates its own buffers, and maps these to the individual heads of each card | 16:36 |
| mjg59 | Keybuk: There's some followup patches that then pass that to the vt layer | 16:36 |
| Keybuk | so each output is in the correct native mode, etc. | 16:36 |
| cjwatson | cursor> ok, that's good | 16:36 |
| Keybuk | (rather than painting over fbcon) | 16:36 |
| Keybuk | the API for doing that is different depending on which driver you're using | 16:36 |
| Keybuk | intel has its own API (GEMish) | 16:36 |
| Keybuk | nouveau has its own API (GEM on TTMish) | 16:36 |
| Keybuk | radeon has its own API (TTMish) | 16:36 |
| apw | heh yeah that debacle will run and run | 16:37 |
| apw | i thought that nouveau and radeon were meant to share ... obviously not | 16:37 |
| Keybuk | well | 16:39 |
| Keybuk | the code is basically the same | 16:39 |
| Keybuk | just s/nouveau/radeon/ | 16:39 |
| Keybuk | e.g. struct nouveau_bo becomes struct radeon_vo | 16:39 |
| Keybuk | apw: I'm not sure whether Plymouth deals with tiled vs. linear | 16:40 |
| mjg59 | Well | 16:40 |
| Keybuk | it looks like it mostly just uses memcpy() :p | 16:40 |
| mjg59 | We don't blank the screen when going to X | 16:41 |
| mjg59 | Which lets us fade from bootsplash to gdm | 16:41 |
| mjg59 | But I don't know what magic is involved there | 16:41 |
| Keybuk | mjg59: actually, that one line of yours is FAR MORE COMPLICATED than you could ever possibly imagine | 16:41 |
| mjg59 | Keybuk: In grub? I'm shocked | 16:41 |
| Keybuk | no, I mean in plymouth | 16:41 |
| mjg59 | Oh? Ha. | 16:41 |
| Keybuk | keeping the frame buffer contents locked while we start X turned out to be very non-trivial | 16:42 |
| mjg59 | But clearly, if the framebuffer is linear and X is tiled, there's a lot of magic there | 16:42 |
| cjwatson | so the problem with using vesafb is that we'd have to build it into the kernel | 16:42 |
| Keybuk | I think the magic is at X's end ;) | 16:42 |
| cjwatson | otherwise, no initramfs recovery | 16:42 |
| mjg59 | cjwatson: Upstream has never supported it being modular | 16:42 |
| cjwatson | IIRC, in the past, building vesafb into the kernel was a recipe for awfulness | 16:42 |
| cjwatson | does upstream support it being boot-time-configurable whether you use it? | 16:43 |
| mjg59 | It's always been a module just because of Debian's "Everything should be a module" crusade | 16:43 |
| cjwatson | because having it be kernel-build-time-configurable depending on hardware clearly ain't gonna work here | 16:43 |
| mjg59 | cjwatson: Upstream will use it if screen_info has VIDEO_TYPE_VLFB | 16:43 |
| mjg59 | And won't use it otherwise | 16:43 |
| cjwatson | ok | 16:43 |
| mjg59 | Same as efifb | 16:43 |
| cjwatson | so, in that case, I think grub will use it if it's built-in | 16:44 |
| cjwatson | it checks the boot parameters structure in the kernel image for that | 16:44 |
| mjg59 | ... | 16:44 |
| cjwatson | I *think*, I'm not following all of that | 16:44 |
| mjg59 | grub needs to stop being fucking insane | 16:44 |
| Keybuk | insmod sanity | 16:44 |
| cjwatson | it does need to know whether the thing it tries to pass is actually going to work, surely | 16:44 |
| mjg59 | It's like KDE - the assumption seems to be that the rest of the ecosystem is hostile and must be worked around | 16:44 |
| cjwatson | not really, grub is mostly fairly sane these days tbh | 16:45 |
| cjwatson | certainly a fucklot easier to work with than it used to be | 16:45 |
| mjg59 | Rather than working on having a sane interface | 16:45 |
| cjwatson | this is just a set of code paths few people use as yet, so it hasn't been polished much *shrug* | 16:46 |
| cjwatson | but that's what we're trying to fix here | 16:46 |
| Keybuk | well, | 16:48 |
| Keybuk | I guess GRUB has to know what kind of things the kernel is going to expect | 16:49 |
| Keybuk | that's probably how we're falling back to efifb right now | 16:49 |
| Keybuk | GRUB sees that the kernel supports that, but not vesafb, so passes it in screen info | 16:49 |
| Keybuk | if we built vesafb in as well, it'd pass vesafbishness in screen info instead | 16:49 |
| Keybuk | (unless really using EFI) | 16:49 |
| mjg59 | Keybuk: Yeah, which is bogus | 16:49 |
| Keybuk | of course, you could argue that GRUB should pass vesaishness regardless and penalise us for building the kernel ... incorrectly | 16:49 |
| mjg59 | Keybuk: If we ever fix efifb to only run on efi, grub suddenly tells the kernel not to reprogram text mode and everything breaks | 16:50 |
| Keybuk | that's the kind of thing i'd do <g> | 16:50 |
| mjg59 | Of course, the fact that we have three places that program modes is insane | 16:50 |
| mjg59 | (grub, kernel setup code, native framebuffer) | 16:50 |
| cjwatson | it's like a two-line patch to make grub always set up vesafb, so I really don't care, just need to put it all together | 16:52 |
| apw | cking, which mini model you got? | 16:57 |
| cking | hpmini1000 for the record | 16:58 |
| cjwatson | http://paste.ubuntu.com/411117/ should be all that's needed to adjust grub | 16:58 |
| cjwatson | bit more than two-line because I renamed _SIMPLE back while I was there | 16:59 |
| === sconklin is now known as sconklin-gone | ||
| === yofel_ is now known as yofel | ||
| Keybuk | apw: you know http://people.canonical.com/~apw/lp539730-lucid/ ? | 17:43 |
| dmarkey | apw: i see you've applied that patch, so, does that mean these udebs are being built in daily? | 17:43 |
| apw | Keybuk, hi | 17:44 |
| apw | dmarkey, it means that its applied to our tree only | 17:44 |
| Keybuk | apw: you know how you don't publish linux-source packages along side those? | 17:44 |
| apw | thats not in the archive yet, and so not builting yet | 17:44 |
| Keybuk | apw: I could sent you one of those Digital Economy Bill disconnection notices <g> | 17:44 |
| apw | Keybuk, heh i give you the patches and everything :) | 17:44 |
| apw | otherwise its a generic kernel and thats published already no? | 17:45 |
| Keybuk | apw: strictly speaking, I gave you the patch :p | 17:45 |
| apw | heh there is that too :) | 17:45 |
| apw | i just can't face the extra 50mb of upload for something noone uses | 17:45 |
| apw | rookery is already full up | 17:45 |
| apw | luckily any disconnects will go to the DC :) | 17:46 |
| apw | Keybuk, more importantly does that combination work ? | 17:48 |
| Keybuk | I'm trying to purge xorg-edgers from the system | 17:49 |
| Keybuk | this turns out to be HARD | 17:50 |
| apw | Keybuk, heh thought i might hear you complaining about that | 17:51 |
| dmarkey | apw: so i assume it has to pass some build tests, then what is the process, or is it published somewhere? | 17:51 |
| apw | its in our git tree only at the moment, i am incrementally adding all of the outstanding bits we have at the moment on our list | 17:52 |
| apw | i add a few ... build ... iterate | 17:52 |
| apw | once its done then i'll boot test it locally and maybe publish that | 17:52 |
| dmarkey | excellent, i assume its too late for beta2 | 17:53 |
| apw | probabally tommorrow am i am likely to upload the result so we have a few days to such on the fall out | 17:53 |
| Keybuk | ok | 17:53 |
| Keybuk | WFM | 17:53 |
| apw | dmarkey, too late was last tuesday a week back | 17:53 |
| apw | Keybuk, thanks | 17:53 |
| dmarkey | i see | 17:53 |
| apw | we freeze a week before a beta milestone | 17:53 |
| dmarkey | ah well, i'll have it well tested before beta3/rc1 | 17:53 |
| akgraner | apw, thank you!! my computer is on at 48C now woot woot!!! | 17:54 |
| akgraner | it's not frying me anymore! this is a good thing | 17:54 |
| apw | yeah mine too ... glad the same fix worked for yours | 17:54 |
| akgraner | awesome!! | 17:55 |
| akgraner | you all rock - when I grow up in open source I wanna be like the kernel team!! (well minus that pgraner :-D ) | 17:55 |
| JFo | :-/ | 17:59 |
| apw | akgraner, i am not sure i want to know what that menas :) | 18:05 |
| JFo | bug 557611 | 18:06 |
| ubot3 | Malone bug 557611 in linux "[KMS] please cherry-pick fix for Radeon RS4xx cards" [Undecided,New] https://launchpad.net/bugs/557611 | 18:06 |
| JFo | apw, have you seen that ^ | 18:06 |
| JFo | it is fresh <24hrs old | 18:06 |
| apw | JFo, you can pretty much assume no to that question always | 18:07 |
| JFo | :) | 18:07 |
| apw | do i need to care about it? | 18:08 |
| JFo | dunno | 18:08 |
| JFo | it is in Linus' tree, but not in the branch for the next RC | 18:08 |
| JFo | they are wanting a cherry pick (as you can see) | 18:08 |
| JFo | just up to you | 18:08 |
| JFo | but the issue and the patch have been confirmed | 18:08 |
| JFo | just matters whether or not you want to cherry pick it | 18:09 |
| * JFo is ambivalent ;-) | 18:09 | |
| JFo | brb | 18:09 |
| * apw shakes the tree to see if he can find some reviewers for the myriad of patches on kernel-team | 18:48 | |
| apw | JFo, ok it seems to be a patch people claim to fix the issue. i've got test kernels building | 18:49 |
| JFo | apw, cool | 18:52 |
| cnd | RAOF: you familiar with git send-email? | 20:22 |
| cnd | it will make sending patches easier | 20:22 |
| RAOF | cnd: I've found the git send-email documentation on the kernel wiki, but it doesn't seem to work properly for me. | 23:34 |
| cnd | RAOF: what goes wrong? | 23:34 |
| RAOF | No email gets to the list; I probably need to work out how to send it through an appropriate smtp server. | 23:36 |
| lifeless | RAOF: do you have local mail sending setup ? | 23:47 |
| RAOF | I've probably got postfix installed; ubuntu-dev-tools likes it. | 23:48 |
| lifeless | I didn't say installed :P | 23:48 |
| RAOF | That'd surely be a postfix bug, then. There's no reason it shouldn't just work, is there? | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!