| zruty | Do I get a chance to edit the bug report before it gets sent? | 04:50 |
|---|---|---|
| RAOF | zruty: You mean, when sending a report via apport? | 04:55 |
| zruty | ubuntu-bug linux | 04:56 |
| RAOF | zruty: There is no report before it gets sent; what happens is the data gathered gets attached to the bug you create. There is not a way to edit that data before you've created the bug, though. | 04:56 |
| zruty | It collects all kinds of data which is fine, but does that also send what is the bug as experienced by me? | 04:56 |
| zruty | Okay, then I think I will do it a little differently, hoping that actual bug data will be included in that report | 04:57 |
| zruty | thanks! | 04:57 |
| RAOF | You should always describe your bug in the report; although the data attached should be useful, it doesn't contain all the context that you can provide (like ‘this happens each time I plug in my USB mouse’) | 04:58 |
| zruty | Yes exactly. And when I do ubuntu-bug linux I do not get a chance to add that before it gets sent | 05:04 |
| zruty | So I think I better crate the bug and then snd the report. | 05:07 |
| zruty | After the bug gets filed, can I add to it? | 05:07 |
| zruty | In launchpad somewhere, was it? | 05:07 |
| zruty | RAOF: ? | 05:26 |
| zruty | Now I am getting 'Can not connect to crash database, please check your internet connection. <urlopen error [ErrNo8]_ssl.c:503:EOF occured in violation of protocol> | 05:28 |
| zruty | Firefox can browse websites. | 05:28 |
| RAOF | zruty: Sorry. You can add to a report after filing it; running “apport-collect $BUGNUMBER” will attach all the information you would have got. | 05:30 |
| RAOF | zruty: Hm. You might want to try running ubuntu-bug again; maybe that error was transient? | 05:31 |
| zruty | OK | 05:31 |
| RAOF | What'll happen when you run ubuntu-bug is that it'll upload the data to a staging area and open a browser window at the "file a bug" page, with some of the fields pre-filled. | 05:34 |
| RAOF | After you create the bug, the data in the staging area will be attached to it. | 05:35 |
| zruty | Ah, that sounds good. | 05:35 |
| zruty | The upload progress bar is not moving.... | 05:40 |
| zruty | I have a running ping to my ISP's DNS server which replies nice and quick | 05:41 |
| RAOF | That's odd. Sorry, I don't think I'll be of much help. | 05:49 |
| zruty | Now I get a ErrNo32 broken pipe | 05:51 |
| zruty | I'll try it again another way | 05:51 |
| zruty | Yes, now it is working | 05:57 |
| zruty | Done. | 06:43 |
| * apw yawns | 07:36 | |
| * ppisati waves at apw | 07:46 | |
| apw | morning | 07:46 |
| ppisati | moin | 07:47 |
| * smb tries to open eyes... | 07:51 | |
| * jussi dumps a bucket of water over smb then hands him a coffee | 08:19 | |
| * smb appreciates the coffee but would rather have nicely warm water over and not in front of the keyboard... :-P | 08:25 | |
| * ppisati -> reboot | 08:35 | |
| === cking_ is now known as cking | ||
| cking | testing always takes me longer than I anticipate... | 09:32 |
| apw | cking, testing is never anticipated ... | 10:48 |
| davmor2 | apw: does that not make you like the spanish inquisition? | 10:49 |
| * apw smiles at davmor2 | 10:49 | |
| davmor2 | apw: I prefer the testing misquote from a popular Meatloaf Song... Object in the rear view mirror may appear more broken than they are..... | 10:53 |
| apw | heh | 10:53 |
| cking | tyhicks, you merged a bunch of my ecryptfs changes but seem to be missing the changes to allow for ext2, xfs and btrfs mount flags as well as a test for the clearing of ECRYPTFS_NEW_FLAG during truncate. can these be merged? | 11:24 |
| * apw goes splash about | 11:45 | |
| * ppisati -> conf call | 12:03 | |
| === smb` is now known as smb | ||
| tgardner | apw, what hacks did you want me to try on the encrypted LVM desktop ? | 13:07 |
| === bladernr_afk is now known as bladernr_ | ||
| apw | tgardner, ok so on the grub menu there is a bit ... /me gets the right wording | 13:28 |
| apw | tgardner, set gfxpayload=$linux_gfx_mode which i'd like changed to =text | 13:29 |
| apw | tgardner, and could you separatly retest to confirm removing vt.handoff=7 is not sufficient | 13:30 |
| apw | tgardner, and finally both in combination, and let me know which work | 13:30 |
| === kengyu_ is now known as kengyu | ||
| tgardner | apw, working on it.... | 13:36 |
| apw | tgardner, thanks | 13:36 |
| tgardner | apw: some discussion of hyperv on LKML that you might find interesting, though it a difficult post to parse: "Linux on Hyper-V -- use hv_storvsc instead of ata_piix to handle the IDE disks devices ( but not for the DVD-ROM / CD-ROM device handling) Fw: [PATCH RFC] ata_piix: ignore disks in a hyper-v guest" | 13:41 |
| tgardner | apw, oh, never mind. you're on the Cc: | 13:42 |
| apw | is that that V<sometign> guy ... if so i have read and replied to them all | 13:42 |
| smb | ogasawara, Are you planning to bundle up a new precise kernel today | 14:10 |
| === yofel_ is now known as yofel | ||
| ogasawara | smb: I wasn't planning one for today, still finishing up yesterday's upload. but I can if there is a fix you need uploaded. | 14:11 |
| smb | ogasawara, There will be a fix but its not that urgent that it requires desperate actions. Just wanted not to miss the next upload by seconds. :) | 14:12 |
| tyhicks | cking: Strange, I wonder how I missed those | 14:12 |
| tyhicks | cking: I'm working on merging them now | 14:13 |
| ogasawara | smb: I'll likely wait and upload again on Tuesday (which will be the last upload before Kernel Freeze) | 14:13 |
| smb | ogasawara, Ok, that works for me | 14:13 |
| tgardner | ogasawara, have you hassled anyone about NEWing your kernel? looks like itsready. | 14:14 |
| apw | ogasawara, i have some hyper-v changes in testing as well which i would like in the tuesday one | 14:14 |
| apw | tgardner, oh has powerpc finally made it | 14:14 |
| tgardner | last I checked | 14:14 |
| ogasawara | tgardner: yep, pitti new'd em for me earlier this morning | 14:14 |
| ogasawara | apw: ack | 14:15 |
| ogasawara | tgardner: and I've just uploaded lbm | 14:15 |
| tgardner | ogasawara, hopefully I've fixed all the build failures in LBM | 14:16 |
| ogasawara | tgardner: I did lbm test builds on amd64 and i386 and they all built ok | 14:16 |
| ogasawara | tgardner: I was also going to upload linux-firmware if that's ok with you? | 14:17 |
| tgardner | ogasawara, huh? | 14:17 |
| ogasawara | tgardner: I added the brcm firmware to the nic-firmware.lst udeb | 14:17 |
| tgardner | ogasawara, ah, ok - no problem | 14:18 |
| * ogasawara assumes I have upload rights for linux-firmware... I guess I'll find out | 14:18 | |
| tgardner | ogasawara, you might not if you haven't done it for precise | 14:19 |
| cking | tyhicks, thanks! | 14:28 |
| * ogasawara back in 20 | 14:29 | |
| tgardner | apw, as far as I can tell, the only thing that makes the LUKs prompt appear is by removing "splash". the password prompt _does_ however appear on VT 7 (which is not unexpected given the vt_handoff setting) | 14:42 |
| tgardner | apw, I suspect the right thing to do for a LUKs install is to remove both splash and vt.handoff | 14:44 |
| vanhoof | tgardner: ogasawara: also issues with luks + vt.handoff? | 14:54 |
| tgardner | vanhoof, with an nVidia setup that I have | 14:55 |
| vanhoof | tgardner: ogasawara: I was mulling over ideas of a creative way to not have vt.handoff added myself (for the cedarview/poulsbo case) where it also breaks things | 14:55 |
| tgardner | vanhoof, seems that its only on the desktop install | 14:55 |
| vanhoof | looks like a grub script looks for splash and adds vt.handoff by default | 14:55 |
| vanhoof | just not sure of the proper place to make such a change, plymouth, grub, etc | 14:55 |
| tgardner | vanhoof, dunno. could be a cjw question | 14:56 |
| apw | vanhoof, why does it break things, or more specifically in ways does it break things | 14:56 |
| vanhoof | apw: you never actually get to a login screen, why it breaks cedarview/poulsbo we're not sure yet | 14:57 |
| apw | vanhoof, and whats the | 14:57 |
| apw | vanhoof, and whats the bug number | 14:57 |
| vanhoof | apw: all that magic is in grub2's ubuntu_vt_handoff.patch | 14:58 |
| vanhoof | apw: theres a couple: 914311 and 899244 | 14:59 |
| apw | vanhoof, are they both binary only drivers ? | 14:59 |
| vanhoof | apw: psb_gfx is not | 14:59 |
| apw | and what is the total symptoms? b | 15:00 |
| apw | black/purple/other? | 15:00 |
| vanhoof | tseliot: ^^ what does it look like w/ vt.handoff added on cedarview? | 15:00 |
| vanhoof | Sarvatt: ^^ | 15:00 |
| * vanhoof doesnt have one in hand to tell ya :) | 15:01 | |
| vanhoof | just know its broken :) | 15:01 |
| apw | so very helpful indeed | 15:01 |
| tgardner | apw, ogasawara: in the https://wiki.ubuntu.com/KernelTeam/Specs/PreciseKernelDeltaReview Rationale section we reference v3.1 in a couple of places. I think we should update it to correctly reference v3.2 (with an appropriate statistics update) | 15:03 |
| tseliot | apw: not even Intel is sure as to why it breaks cedarview | 15:03 |
| ogasawara | tgardner: ack | 15:03 |
| ogasawara | tgardner: I'll rerun the scripts and update it | 15:04 |
| tgardner | ogasawara, cool | 15:04 |
| vanhoof | apw: on the machines we have, what we see is a long pause (from the purple screen) ~30-60 seconds, until it looks light lightdm respawns and takes over | 15:04 |
| apw | so you just don't see plymouth? you get bios, purple, lightdm | 15:05 |
| tseliot | apw: cedarview hardware + psb_gfx = black screen, I'm not even sure vt.handoff matters. As for cedarview hw + poulsbo + vt.handoff = I don't think lightdm gets you to the desktop at all | 15:06 |
| tseliot | but hey, maybe my machine is possessed by goblins ;) | 15:06 |
| apw | vanhoof, have you tried disabling vesafb ? vesafb._broken_=true or similar on the kernel command line | 15:06 |
| apw | that might not interact well with the new drivers if they arn't KMSd correctly | 15:07 |
| tseliot | apw: removing vesafb would automatically disable vt.handoff (which in turn depends on "splash"), right? | 15:07 |
| apw | tseliot, nope not at all, it just a potential fallback when a drm driver isn't found quickly enough, and then we rely on vesafb to new driver handover to work properly | 15:08 |
| apw | which its not been found to do well, and upstream said "don't do that, it smells" | 15:08 |
| tseliot | oh | 15:08 |
| apw | so it'd be good to know if vesafb is getting loaded when we might not want it to be | 15:09 |
| tseliot | ok | 15:09 |
| apw | and one way to find out is to disable it | 15:09 |
| tseliot | vanhoof, apw: I guess if bug #944929 is fixed, then we can boot into a non garbled screen and then we can install my cedarview package which can disable vt.handoff | 15:11 |
| ubot2 | Launchpad bug 944929 in linux "psb_gfx boot hang on Atom N2600 (GMA3600 Cedarview)" [High,Triaged] https://launchpad.net/bugs/944929 | 15:11 |
| vanhoof | tseliot: yeah I was hoping there would be something like grub-gfxpayload-lists where we could blacklist certain devices vs adding vt.handoff by default for anything that sees "splash" | 15:12 |
| apw | vanhoof, "for anything that sees splash | 15:13 |
| apw | " ? what does that mean. you can blacklist handoff for broken h/w in those -lists i believe | 15:14 |
| vanhoof | apw: http://paste.ubuntu.com/907349/ | 15:14 |
| apw | vanhoof, i know what vt.handoff is i wrote the code for it, but i don't understand you "remove it for splash" comment | 15:15 |
| apw | that makes no sense as they go together | 15:15 |
| apw | if your board doesn't work with handoff you can quirk that i beleieve so grub won't supply it | 15:16 |
| vanhoof | if you remove splash from /etc/default/grub vt.handoff is never added is what I was saying | 15:16 |
| apw | they go together indeed, it makes no sense to handoff without splash | 15:16 |
| tseliot | apw: how can you quirk it? | 15:16 |
| tseliot | apw: using the splash works fine here, as long as there's no vt.handoff | 15:17 |
| apw | right and thats not the depedancy its the other way, it makes no sense to handoff to splash when splash isn't there | 15:17 |
| tseliot | right | 15:18 |
| apw | if hwmatch \${prefix}/gfxblacklist.txt 3; then | 15:18 |
| apw | vanhoof, tseliot^^ that part there, that blacklist defines if you can use handoff, if not then it sets linux_gfx_payload to text which should stop the handoff being added i believe | 15:19 |
| apw | cirtainly worth trying adding there to see if ti fixes things | 15:20 |
| apw | ogasawara, i closed my penultimate work item | 15:21 |
| ogasawara | apw: \o/ | 15:21 |
| tseliot | apw: wait, wouldn't that also block vesafb? | 15:21 |
| apw | tseliot, no its unrelated to vesafb | 15:21 |
| tseliot | apw: and set linux_gfx_mode to "text"? | 15:21 |
| apw | tseliot, thats what the blacklist does, says 'keep' or 'text' which defines grubs part of handoff, whether it zaps the purple back to normal text, or stays graphical and uses handoff to maintain it through to splash | 15:22 |
| tseliot | apw: http://paste.ubuntu.com/907360/ | 15:23 |
| apw | tseliot, ? | 15:23 |
| tseliot | it's the whole patch | 15:23 |
| apw | yes | 15:24 |
| tseliot | apw: what I'm trying to say is that we need a graphical splash without vt.handoff, without having to switch plymouth's text plugin | 15:25 |
| tseliot | apw: is this what you're suggesting too? | 15:25 |
| apw | tseliot, no it just turns off handoff, the maintenance of purple until splash starts | 15:26 |
| apw | that is what it does, and why its there, its for bust hardware which doesn't handle handoff | 15:26 |
| apw | that osunds like your case to a tee | 15:26 |
| apw | if that doesn't fix you up we need to work out why as it should | 15:27 |
| tseliot | apw: ok, I think I know why I'm so confused about this. When I did it for Nvidia, it switched to text mode because Nvidia won't use the drm plugin. This driver, though, should use the drm plugin and avoid the whole handoff thing | 15:28 |
| apw | tseliot, that is my expectation yes, now there is a hint that perhaps grub is not going to do quite what we intended, and if so we need to fix that or the kernels handling but that would be a bug | 15:28 |
| tseliot | apw: ok, let me try here... | 15:29 |
| apw | tseliot, thanks | 15:30 |
| cking | bjf, looks like those two final changes were merged in ~1 hr ago | 15:40 |
| apw | sched: tg->se->load should be initialised to tg->shares | 15:41 |
| bjf | cking, let me dbl check, i just pulled and seeing the same failures | 15:42 |
| cking | lemme check too :-/ | 15:42 |
| bjf | cking, i see a mistake on my part | 15:43 |
| cking | bjf, ah ;-) | 15:43 |
| bjf | cking, stupid thing did what i told it not what i wanted | 15:44 |
| cking | bjf, now isn't that simply annoying | 15:45 |
| smb | cking, bzr is like tea on the heart of gold... very much like it but not the same | 15:48 |
| * apw shares and enjoys a beer with smb | 15:49 | |
| cking | bjf, just tried it out, works fine for ext2, xfs, etc | 15:50 |
| bjf | cking: yes, working better here as well | 15:51 |
| cking | \o/ | 15:51 |
| cking | hrm 4 machines all busy doing s4 cycles, what fun | 15:52 |
| apw | cking, time for a beer me thinks. and you only have 40m left | 15:55 |
| cking | yep | 15:55 |
| apw | tgardner, if you boot with the default options (on your encrypted lvm configuration) does double tapping ESC from the blank screen work ? | 16:00 |
| tgardner | apw, lemme try | 16:00 |
| apw | tgardner, all sorts of variants of this issue are popping out the woodwork, likely all nvidia | 16:00 |
| tgardner | apw, you're a genius | 16:02 |
| tgardner | pops right up | 16:02 |
| tgardner | it even accepts my password and boots right | 16:03 |
| apw | tgardner, ok good then your issue is the same as the others ... good | 16:04 |
| apw | tgardner, could you now try booting with plymouth:force-drm added to your command line | 16:07 |
| tgardner | apw, still needed to hit <ESC> | 16:10 |
| apw | tgardner, ok thanks | 16:10 |
| tgardner | apw, it looks like _without_ "sched: tg->se->load should be initialised to tg->shares" that load averages are much lower. dunno if thats a good thing, but I'm thinking not. | 16:17 |
| apw | tgardner, its interactibility that matters, though the time to complete a known job is interesting | 16:18 |
| apw | tgardner, perhaps this is a job for super-cking, he is very rigorous | 16:18 |
| tgardner | apw, I can't tell any difference in interactivity | 16:18 |
| tgardner | apw, I think he has all of his bits doing S4 testing | 16:18 |
| apw | yeah i am sure ... we'll i'll add it to my list | 16:19 |
| cking | yep, all my kit is glowing at the mo | 16:19 |
| tgardner | apw, so I'm doing a build without that patch and load averages appear to level out around 70. I'm pretty sure I've seen averages in the 150-200 range prior to this | 16:20 |
| apw | cking, heh ... i bet ... anyhow _you_ have 10m left | 16:20 |
| cking | such interactivity must be somehow testable, but darned if I can think of a way to easily automate that | 16:20 |
| apw | tgardner, that may be an accounting issue introduced by the patch though | 16:20 |
| tgardner | apw, right, my suspicion as well. guess I should be timing | 16:20 |
| apw | cking, well i'd think it would be things like "ask window to change, watch pixel till it does" | 16:20 |
| apw | tgardner, yeah, i am hoping it might improves some of the interactibility issues i am seeing | 16:21 |
| cking | here be the realms of subjectivity | 16:21 |
| apw | once i finally get this lvm poo on a CD so i can test my radeon box, which won't boot from USB!?!?!?! | 16:21 |
| apw | cking, well indeed, actually, latencytop is probabally the sort of thing we should defer to for interactibility | 16:21 |
| tgardner | jsalisbury, herton: rebooting tangerine for kernel update | 16:26 |
| jsalisbury | tgardner, ok, thanks for the heads up | 16:27 |
| * cking calls it a wrap | 17:16 | |
| apw | tgardner, ok all my intel and radeon testing of encrypted LVM is 'good' and so a bust from fixing the bug | 17:50 |
| tgardner | apw, hmm, well at least the workaround is simple. | 17:51 |
| tgardner | on nVidia | 17:51 |
| apw | tgardner, yeah, and we know what that does, it switches to text and back | 17:52 |
| tgardner | apw, has anyone dropped that gem on Gema ? | 17:52 |
| apw | tgardner, ... i think we might need some volunteers with nvidia to test so we can confirm its widespread with nvidia | 17:52 |
| apw | if so, i think we need to switch off handoff for nvidia en-toto when encrypting | 17:52 |
| apw | tgardner, heh ... not me | 17:52 |
| * tgardner goes in search of brain food | 17:58 | |
| === tgardner is now known as tgardner-lunch | ||
| * apw wanders to find self some boozage | 18:14 | |
| === tgardner-lunch is now known as tgardner | ||
| * tgardner -> EOD | 19:22 | |
| kees | ogasawara: two patches for precise (related to seccomp) sent to the list. | 20:20 |
| ogasawara | kees: ack | 20:21 |
| ogasawara | kees: applied | 20:44 |
| kees | ogasawara: thanks! | 20:54 |
| * bjf -> heads off to give blood | 21:15 | |
| === bjf is now known as bjf[afk] | ||
| === bjf[afk] is now known as bjf | ||
| Wrostek | Im trying to compile a kernel with 'fakeroot debian/rules binary-headers binary-generic' after around 20 minutes, sub-make returns error 2 while compiling 'LD [M] drivers/w1/wire.o' ... but there is no debug info... Is there a way to get the kernel build to be more descriptive? | 23:02 |
| Wrostek | ( i would disable Dallas Wire from the config, but you cant, its either built in or module, and I dont know how to fix the problem without debug ) | 23:03 |
| Wrostek | after making a git clone git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git , is it normal for the kernel build to not work? I had to turn off quit a few things from the menuconfig, not it is making it as far as wire.o, but there is no option to disable that... Am i missing something? | 23:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!