[03:10] <ohsix> hallyn: thanks for the movement on the cgroup stuff
[03:11] <hallyn> ohsix: np
[03:11] <ohsix> hallyn: fwiw re: the ktreadd thing, the default policy it moves them into could just mime the default in the kernel wrt to rt & limits
[03:11] <ohsix> then the config will have some contents but be a no-op
[03:12] <ohsix> and could contain a warning about kthreadd in particular & that other threads might be just as much trouble to mess with
[03:13] <hallyn> ohsix: i sort of like the idea of just refusing to move it into a cgrou pif it's called [.*].
[03:13] <hallyn> (and is parented by init)
[03:13] <ohsix> i'm pretty sure you can set it up to ignore kernel threads too
[03:13] <hallyn> yeah.  i think that's safer
[03:14] <hallyn> i just figure there are actual people who 'own' the code so i'll avoid stepping on toes.  I should go see if dhaval wants to do it
[03:14] <ohsix> ya
[03:15] <ohsix> if i moved the conf out of the way or made the daemon that moved threads not start i could have it installed, it just didn't do anything, it would be nice if the default config could be a jump off point
[03:17] <ohsix> (assuming no code changes)
[06:34] <evaluate> Hello.
[06:34] <evaluate> There is a pretty serious bug in ubuntu natty for the program 'clipit' which can be solved with a tiny patch. Is there any chance that such a patch might be included before the final release of natty?
[06:48] <RAOF> evaluate: It's in Universe, so: maybe.  At this point, though, it's basically an SRU.  https://wiki.ubuntu.com/NattyReleaseSchedule says “unseeded universe freeze” is today.
[06:48] <RAOF> evaluate: What is the bug?
[06:49] <evaluate> RAOF, bug #702316
[06:50] <evaluate> RAOF, and this is the needed patch: http://pastebin.com/pSkj0zvE
[06:51] <evaluate> If you say there's no chance for it making it before the release, I can do it the 'normal' way. That is, make a upload to Debian and then request a sync.
[06:57] <pitti> Good morning
[07:00] <RAOF> Morning pitti!
[07:01] <RAOF> evaluate: My IRC decided to timeout; could you throw up the bug again?
[07:01] <pitti> hey RAOF, how are you? had some nice holidays?
[07:01] <evaluate> RAOF, bug #702316
[07:01] <RAOF> pitti: One holiday too few; all the other Aussies have today off, too ;)
[07:02] <RAOF> But yeah.  Nice holidays.
[07:02] <RAOF> Featuring much lazing around in bed.
[07:02] <RAOF> And jml is down in Hobart, too, and we got to catch up.
[07:05] <pitti> RAOF: heh, I hardly got any sleep :)
[07:08] <RAOF> evaluate: That particular bug should be fixable, even post-release.  That patch looks like it'll leak objects, though?
[07:09] <RAOF> evaluate: A Debian upload + sync will get the fix in Oneric, though.
[07:09] <evaluate> RAOF, not sure, that's what tedg from #ayatana suggested for fixing the bug.
[07:10]  * RAOF has a sudden realisation that it's possible he should be patch piloting today.  Why has evolution not fired off a notification?
[07:10] <evaluate> RAOF, Oneric?
[07:10] <RAOF> evaluate: Natty+1; What we'll all be working on in ~3 days :)
[07:11] <evaluate> ohh.
[07:14] <RAOF> @pilot in
[07:26] <didrocks> good morning
[07:27] <RAOF> Howdie didrocks.  Good holidays?
[07:28] <didrocks> RAOF: yeah, only 3 days here, but was nice, thanks! :-) and you?
[07:28] <RAOF> Pretty good.
[07:28] <RAOF> A little bit annoyed that the other Aussies have today off, too :)
[07:29] <RAOF> But there was boardgames with jml, lazing around in bed, and general fun.
[07:45] <dholbach> good morning
[07:54] <pitti> hey dholbach
[07:54] <dholbach> hey pitti
[08:08] <Saamm> plz plz fix this nasty apt bug--> Bug #768901
[08:11] <dholbach> Saamm, it looks like your provider redirected you because they had some breakage somewhere - it's hardly xapian's fault that it can't parse a HTML file :)
[08:11] <dholbach> Saamm, try moving the file away to some other place and try again
[08:12] <Saamm> my provider does this whenever i am disconnected....4-5 time in 24 hours
[08:13] <dholbach> Saamm, can you try moving the file away to see if that makes it work again?
[08:13] <Saamm> there are six extras.ubuntu.com files...should i move them all?
[08:14] <RAOF> Yes.
[08:14] <Saamm> ok trying
[08:15] <tumbleweed> someone came into our loco channel yesterday, whose apt (on a headless server) was getting HTML because he'd entered an incorrect password in his DSL router. Providers are getting more user-friendly and software-unfriendly :/
[08:17] <Saamm> thanks guys you solved my problem...moving files helped :D
[08:17] <dholbach> the only solution for apt I can think of is to try to parse the file before saving it
[08:18] <Saamm> dholbach, yep that will work
[08:19] <dholbach> the question is what you should do if it's not parseable
[08:20] <tumbleweed> having users manually delete files in /var/lib/apt/lists is probably not that good an idea
[08:21] <tumbleweed> err, ... having to ...
[08:21] <dholbach> sure, totally - but depending on the frontend for apt you use you might want to have a different kind of notification/reaction
[08:21] <Saamm> dholbach, automatic correction notification ---> 'These files could not be parsed. Do you want to move them at a separate location? Apt will automatically recreate them and update your system'
[08:21] <dholbach> so it's not a "quick fix" that's going to work for all of them
[08:21] <Saamm> yes or no
[08:22] <dholbach> let's wait until mvo is here :)
[08:22] <Saamm> whos mvo?
[08:23] <dholbach> probably the guy who knows apt and friends best
[08:23] <Saamm> ok
[08:24] <slangasek> isn't that a non-issue for signed repositories?
[08:24] <slangasek> i.e., passing two html files to gpg won't get you an "ok" response
[08:25] <slangasek> so apt shouldn't be accepting those as valid Packages files anyway in such a case
[08:32]  * Hobbsee discovers the answer to the question of "what can possibly go wrong?" for an ubuntu install
[08:34] <StevenK> s/install/upgrade/
[08:34] <Hobbsee> Failure to bring up ethernet after dist-upgrade wasn't the answer I was expecting
[09:25] <janimo> @pilot in
[09:25] <janimo> @pilot out
[09:52] <RAOF> @pilot out
[10:16] <Ja23> Hello
[10:16] <Ja23> I just installed 11.04, but my shell is still GNOME not Unity... how can I change this?
[10:18] <pitti> Ja23: you can select the session type in the login screen after you select your user name
[10:18] <pitti> in the bottom panel
[10:19] <Ja23> pitti: Yeah, I tried that
[10:20] <Ja23> pitti: The "desktop edition"  is not there, I think it has something to do with ATI Radeon drivers, but I've installed all of them
[10:20] <pitti> Ja23: the session is "Ubuntu"
[10:23] <Ja23> in Italics
[10:23] <Ja23> or Ubuntu Classic
[10:23] <Ja23> not in italics
[10:25] <pitti> the one in italics is the default session
[10:51] <janimo> @pilot in
[10:51] <Ja23> Hello, I'm back
[10:52] <Ja23> No change
[10:56] <seb128> Ja23, what videocard and driver do you use?
[10:57] <Ja23> seb128: I have a Radeon HD 5600, I've installed the additional drivers
[10:58]  * dholbach hugs janimo
[10:58]  * janimo hugs dholbach 
[10:58] <dholbach> :)
[10:58] <Ja23> seb128:  When I first turned on my computer it gave me lots of errors about there being no 3d driver and that unity wouldn't work, but now that i've gottten the drivers how do I turn Unity back on?
[10:58] <seb128> Ja23, by selecting "Ubuntu" in the gdm screen
[10:59] <seb128> if it doesn't work it might mean that your videocard can't run it
[10:59] <seb128> did you restart your computer after installing the drivers?
[10:59] <pitti> my wife's ATI card (r6xx) runs unity just fine with the free drivers, too
[10:59] <Ja23> seb128: gdm screen?  I've chosen "ubuntu" on the login screen a couple times
[11:00] <Ja23> Hmm
[11:00] <seb128> ok, so it's likely your card doesn't support unity
[11:00] <RAOF> The binary fglrx drivers *were* having problems earlier in the cycle.
[11:00] <seb128> try running the unity_support_test helper by hand and see what it says
[11:01] <RAOF> And by "earlier" I mean "like a couple of weeks ago".  I'm not sure if we've got an updated fglrx since then.
[11:06] <Ja23> I tried running unity_support_test and got "segmentation fault"
[11:09] <seb128> Ja23, did you restart the computer since you installed fglrx?
[11:10] <seb128> Ja23, can you run it with gdb and pastebin the crash backtrace?
[11:11] <Ja23> I'm restarting just to find out
[11:15] <Ja23> restarted, still no unity
[11:24] <RAOF> Ja23: And unity_support_test still segfaults?
[11:25] <Ja23> yep
[11:25] <Ja23> RAOF: yep
[11:25] <seb128> could you pastebin a stacktrace?
[11:25] <seb128> https://wiki.ubuntu.com/Backtrace
[11:26] <seb128> well just basically run gdb ... and type run
[11:26] <seb128> then "bt" when it segfaults
[11:28] <Ja23> so I ran gdp
[11:32] <Ja23> but how do I run the program?
[11:32] <Ja23> unity_support_test
[11:33] <Ja23> I get "no executable file specified"
[11:33] <Ja23> better half is waiting, I have to go to dinner, leave me some advice, I'll be back to read it in a few hours
[11:33] <Ja23> Thanks so much for your help!
[11:44] <RAOF> Ja23: You want to run “gdb /usr/lib/nux/unity_support_test” and then type “run” at the gdb prompt to run the program.  Presumably it'll then crash, and you can type “bt” to grab the backtrace.
[12:26] <ogra_> hmm, using lzma for compressing the initrd in natty gets me weird results
[12:26] <ogra_> if i just use update-initramfs with COMPRESSION=lzma in the config, i cant boot at all
[12:27] <ogra_> if i use gzip as compression method, uncompress the initrd and recompress manually with lzma -z, all boots fine
[12:28] <ogra_> seems a bit like lzma behaves differently if something gets piped to it vs calling it with a filename to compress
[12:41] <ogra_> cjwatson, is there any reason we dont use initramfs-tools' lzma mode in livecd-rootfs (and instesad recompress a gzipped initrd) ?
[12:47] <cjwatson> ogra_: no idea
[12:47] <cjwatson> ogra_: it was years ago, maybe it didn't have that mode
[12:47] <ogra_> oh, i thought .lz inirds only came recently
[12:47] <ogra_> *initrds
[12:48] <ogra_> (on the live images i mean)
[12:48] <ogra_> i think there is a bug in initramfs-tools with it, lzma is called completely without options in mkinitrd
[12:49] <cjwatson> IIRC needing to use -S '' in some cases
[12:49] <cjwatson> or something like that
[12:49] <ogra_> well, livecd-rootfs uses -9c
[12:49] <ogra_> manually i just used -z ... in any case i cant boot anything that was rolled without options to lzma
[15:04] <ogra> cjwatson, heh, in streamed (piped) mode lzma doesnt add the filesize to the header so the kernel wont load the initrd, in non-streamed i have a size (according to file)
[15:12] <infinity> ogra: That does make a certain amount of sense.  Streams don't have filesizes.  Shame on the kernel for seemingly requiring that in its decompressor, though.
[15:14] <ogra> infinity, well, i'm playing with my own (tegra2) kernel ... might be my fault, though i took one of our distro configs as base and dont really think i'm missing anything
[15:14] <infinity> ogra: I can't imagine that there's a kernel config option that says "make my initrd require an obscure compression header", so I imagine the fault isn't yours. :P
[15:15] <ogra> heh, k :)
[15:15] <infinity> ogra: But if it's the case that initramfs-tools-generated lzma images don't work, while it's probably a kernel bug, we should fix it in initramfs too.  Conservative in what you create, liberal in what you accept, yadda, yadda.
[15:15] <chrisccoulson> SpamapS, could I have an ack for bug 770719? like the firefox bug you looked at last week, this one would go out via natty-security with the next firefox point-release (if there is one. if there isn't, then we'll just do the usual route through natty-proposed)
[15:15] <ogra> well, i see that livecd-rootfs seems to create a streamed lzma file and our live x86 images apparently work
[15:15] <chrisccoulson> i'm not sure why nobody picked this up earlier in the cycle :(
[15:16] <infinity> ogra: Hrm?  I thought you said livecd-rootfs was re-compressing a gzip initrd?
[15:16] <ogra> it does, but still from a stream
[15:16] <infinity> Oh, so the stream thing may be a red herring.
[15:16] <ogra> i can boot if i manually uncompress the gzipped file and use lzma on that ... i cant boot if i pipe to lzma
[15:17] <ogra> looking at both results with file shows me size info on one but not the other file
[15:17] <infinity> Kay, that seems like normal behaviour though.  Streams don't have sizes.
[15:18] <infinity> Nailing down what makes the initramfs-tools-generated one even more different would be nice.
[15:19] <JanC> not sure this came through before I lost my connection --> you mean the compressed size?  it obviously *can't* add that to a *header* when streaming...
[15:20] <infinity> JanC: Yes, as noted.
[15:20] <infinity> JanC: But it doesn't seem that's his problem anyway.
[15:21] <ogra> well, its non std HW with a non STD kernel and bootloader .. the worrying part is that i can boot one but not the other, the only real difference in creation is that one is streamed, the other isnt
[15:21] <ogra> and even when creating a streamed one manually it doesnt boot
[15:22] <JanC> maybe the kernel-implementation for lzma decompression requires the size ?
[15:23] <infinity> ogra: But if you zcat | lzma a gzip one, it works?
[15:23] <ogra> no
[15:23] <ogra> that creates a streamed file
[15:24] <infinity> Oh, kay.  I misread above where I thought you said that worked, but initramfs-tools didn't.
[15:24] <infinity> Kay.
[15:24] <infinity> But, on the other hand, the livecds use a pipe too.
[15:24] <ogra> if i zcat > <file> && lzma -z <file> it works
[15:24] <infinity> Are you using the same switches?
[15:24] <ogra> yes, thats what bothers me
[15:24] <infinity> zcat | lzma -9c
[15:24] <ogra> it also tried with the same switches, no go
[15:25] <infinity> *scratch head*
[15:25] <ogra> also tried -zc (which might be redundant)
[15:25] <ogra> as well as just -c and no option at all (the latter is what initramfs-tools uses)
[15:26] <infinity> Does the streamed and in-place compression result in a file of reasonably similar size?
[15:26] <infinity> Could be running into a hardware/firmware issue that's entirely unrelated to the kernel.
[15:26] <ogra> about 1-2 bytes difference
[15:26] <infinity> Kay, scratch that.
[15:27] <ogra> my bootloader tool would complain if its to big
[15:27] <infinity> ARM hardware?
[15:27] <ogra> if i flash it to the SD
[15:27] <ogra> yep
[15:27] <ogra> ac100 netbook, tegra2
[15:27] <infinity> Which bootloader does it use?
[15:27] <infinity> I wonder if it's one of the few that "cleverly" decompresses the initrd internally and passes a raw image to the kernel.
[15:28] <ogra> its something fastboot based
[15:28] <infinity> And maybe it's the bootloader's failure here, not the kernel.
[15:29] <ogra> reads the files from an SD partition where the binary bits have to live in certain places ...
[15:31] <infinity> ogra: Any chance you could experiment by stripping a driver or two our of the initrd, then recompressing?
[15:31] <infinity> ogra: I'm still tempted to blame size and call the streaming thing a red herring.
[15:31] <ogra> you mean make it smaller ?
[15:31] <infinity> Yes. :P
[15:31]  * ogra drops FRAMEBUFFER=y from the initrd options to drop plymouth 
[15:31] <infinity> That would do it.
[15:31] <ogra> that should gain me a few M
[15:34] <cjwatson> infinity: boot loader decompressing initrd> *boggle*
[15:35] <cjwatson> and people complain about GRUB having too many features
[15:35] <infinity> cjwatson: You've obviously not played much in the scary embedded world.  Bootloaders do all sorts of stupid things.
[15:36] <infinity> cjwatson: The only misfeature GRUB appears to have is failing entirely to boot my netbook on every 4th attempt.
[15:37] <ScottK> It's only a misfeature if upstream doesn't have it in for you personally.
[15:37] <ion> !away | bjf
[15:37] <ogra> infinity, wow, weird. seems to boot with the 1.8M streamed initrd
[15:38] <bjf> ion, mind your own business
[15:38] <infinity> ogra: Bingo.
[15:38] <cjwatson> infinity: score.  one of those things that's a pain to debug other than in person
[15:38] <ogra> it doesnt work with the 4.2M streamed one, but works with the 4.2M one thats non streamed
[15:38] <infinity> ogra: Not that this tells me yet where the bug lies, but it tells us the streaming thing was a red herring.
[15:39] <ogra> well, seems streaming has some influence if i get to the edge of things
[15:39] <ScottK> bjf: Personally I don't care about the away messages since I filter them, but that's an unreasonably hostile response as such requests are consistent with the channel's rules.
[15:39] <ogra> though 4.2 shouldnt actually hit the edge yet
[15:39] <infinity> ogra: Or, rather, the streaming thing is likely a data point that we were misinterpreting.  The header is irellevant, but decompression utilities need more memory to decompress streams.
[15:40] <ogra> ah, yeah, that might be it
[15:40] <infinity> ogra: So, even if the initrds are the same size, you may still be running into either a platform or kernel constraint with the streamed version.
[15:40] <ogra> well, then rolling it un-streamed from initramfs-tools still makes sense i think
[15:40] <infinity> ogra: Oh, I'd agree that changing the behaviour for both initramfs-tools and livecd-rootfs is a good idea here anyway, erring on the side of caution, but I'd be curious to nail the actual bug.
[15:41] <infinity> ogra: Do you have a kernel source tree lying around?
[15:41] <infinity> ogra: Ancient bug, and I'd like to THINK the fix was upstreamed, but can you check that some variation of the patch in https://dev.openwrt.org/ticket/3488 shows up in our source?
[15:42] <ogra> infinity, http://gitorious.org/ac100/  the marvin chromium tree from there
[15:42] <infinity> ogra: s/our/your/
[15:43] <kees> infinity: hi! nice to see you :)
[15:43] <infinity> ogra: Either way, though, even if the kernel is now doing sane and wonderful things (and I hope it is), there's only so much you can do on some of these embedded platforms to deal with early-boot memory constraints.  A lot of them really aren't keen on lighting up much/any of the system until later in the process.
[15:44] <infinity> kees: Oh hai.
[15:45] <sconklin> ScottK: can you point me to the channel rules?
[15:46] <ogra> infinity, yeah, on the ac100 its actually a shame ... i have two boot partitions (android kernel and android recovery) on an 8G MMC that the bootloader holds the partition table for ... i cant repartition at all (and there are several partitions on the device that are even hidden from the kernel completely
[15:46] <ogra> )
[15:46] <ScottK> There's a link to them when you /join.
[15:47] <SpamapS> chrisccoulson: reading now
[15:48] <sconklin> ScottK: All I get is the topic, which points to this: https://wiki.ubuntu.com/UbuntuDevelopment, which makes no mention of IRC rules
[15:48] <ScottK> OK.  In any case the request was a pretty standard one for Ubuntu channels.
[15:48]  * ScottK isn't an irc lawyering expert.
[15:49] <bjf> scottk, maybe i was a little harsh, i can accept that and i'm sorry, but i've been doing my nic this way for two years now and this is maybe the second time anyone has complained
[15:49] <james_w> https://wiki.ubuntu.com/IRC/Guidelines
[15:50] <bjf> ScottK, this is SOP for the kernel channel
[15:50] <ScottK> james_w: Thanks.
[15:50] <bjf> ScottK, and if it's a problem, then I can just drop this channel
[15:50] <ScottK> As I said, I just filter them, so it doesn't affect me either way.  I was more concerned about the harshness of the response.
[15:50] <ScottK> So don't leave on my account.
[15:50] <bjf> ScottK, now, i've taken up more of your and my time than is necessary for this
[15:51] <ScottK> Agreed.
[15:52] <SpamapS> chrisccoulson: I commented on the bug. Don't forget to subscribe ubuntu-sru after you upload to natty-proposed. :)
[15:52] <infinity> ogra: Can you file bugs on initramfs-tools and livecd-rootfs requesting a chance from piped to file-based compression?  It's probably a sane change even if it isn't the real bug at play here.
[15:52] <infinity> ogra: Saving a bit of RAM on boot is never a bad thing.
[15:53] <cjwatson> (as an #ubuntu-devel op) I think away nick changes are annoying and noisy, but I wouldn't ban people for them, and I more or less never even comment on them because it has an excellent chance of turning into this kind of meta-discussion which is more annoying than the original problem
[15:53] <ogra> infinity, will do, for my use case i can work around it in flash-kernel though
[15:53] <infinity> ogra: *nod*
[15:53] <infinity> cjwatson: Like what's happening right now? :)
[15:53] <cjwatson> well, quite so
[15:56] <sconklin> james_w: thanks
[16:06] <Ja23> Hello
[16:06] <Ja23> I've just installed Natty and Unity is not showing up for me, instead I still have GNOME
[16:07] <Ja23> When I try to run unity_support_test I get a segmentation fault
[16:07] <Ja23> When I backtrace it using gdb I get: #0  0x002c3824 in XF86DRIQueryExtension () from /usr/lib/fglrx/libGL.so.1
[16:07] <Ja23> #1  0x00165ae6 in ?? () from /usr/lib/i386-linux-gnu/libX11.so.6
[16:08] <seb128> Ja23: seems like fglrx is wrongly installed
[16:08] <Ja23> Ohh, Ok, uninstall and reinstall?
[16:08] <seb128> see bug #747286
[16:08] <Ja23> seb123: uninstall reinstall?
[16:18] <Ja23> seb123: The solution is to reset the xorg.conf file using :
[16:18] <Ja23>   $ aticonfig -f --initial
[16:18] <Ja23> seb123: what does this mean?
[16:19] <Ja23> seb123: what exactly does reset mean?
[16:19] <seb128> Ja23, dunno
[16:20] <seb128> but the issue seems to be that you are mixing 2 drivers
[16:20] <Ja23> Mmm
[16:20] <infinity> Ja23: (It's seb128, not seb123)
[16:21] <Ja23> Yeah, I just noticed that..
[18:13] <eitch0000> hi guys. Yesterday I asked about a problem with an application which crashes with error messages about wrong ELF class: ELFCLASS64. I tracked the problem to being that the application is actually compiled for 32 bit and thus can't load the 64 bit libraries. This same package worked in Maverick, is there something I can do, to get it to work? I've got the ia32-libs already installed.
[18:32] <mdz> bryceh, around?
[18:50] <infinity> eitch0000: You want to take your support questions to #ubuntu, ideally.
[18:53] <eitch0000> infinity, ok, thanks
[19:31] <bjf> ion, i do apologize for earlier, don't know why i was in such a bad mood
[19:39] <SpamapS> question.. is there somewhere definitive that defines the LP: #012345 format? /usr/share/perl5/Dpkg/Vendor/Ubuntu.pm seems like it would be de facto...
[19:42] <janimo> @pilot out
[19:57] <infinity> SpamapS: Since that's what creates the Launchpad-Bugs-Fixed header in .changes files (and everything else keys off that), it would be fair to call dpkg the authority.
[19:58] <infinity> SpamapS: But curiously, I couldn't readily find any docs in the wiki explaining it to people who didn't already know the syntax.
[19:58] <SpamapS> infinity: seems like something important to put in the packaging guide/policy
[19:58] <infinity> Guide, not policy.
[19:58] <infinity> But yes.
[19:58] <infinity> Pretty sure the Debian packaging guide mentions Closes: #NNN
[19:58] <infinity> Or the dev-ref, rather.
[19:59] <james_w> http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-source.html#s-dpkgchangelog
[19:59] <soren> SpamapS: does
[19:59] <soren> SpamapS: Whoops
[19:59] <soren> SpamapS: https://wiki.ubuntu.com/ClosingBugsFromChangelog
[19:59] <james_w> "Ubuntu: If this upload resolves bugs recorded in Launchpad, they may be automatically closed on the inclusion of this package into the Ubuntu archive by including the string: LP: #nnnnn in the change details.[20] This information is conveyed via the Launchpad-Bugs-Fixed field in the .changes file (see Launchpad-Bugs-Fixed, Section 5.6.23)."
[20:00] <soren> james_w: Ah, even better.
[20:00] <infinity> Oh, lookie there, it's in Policy.
[20:00] <infinity> I was looking in the packaging guide, since I didn't think it should be a policy thing. :P
[20:00] <SpamapS> There it is. Ok good. :)
[20:01] <SpamapS> Some things omit the required \s+ .. :-P
[20:04] <infinity> The LP regex sure is less sloppy than the Closes one.
[20:04] <infinity> I guess we decided to be more anal about format the second time around.
[20:06] <Factor-H> Anyone responsible for the wireless problem on nettops like the Aspire-One?
[20:07] <Factor-H> Because the problem is detected in the hardware initialization.
[20:08] <Factor-H> If the board is already initialized by windows, then Ubuntu 11.04 works fine
[20:08] <Factor-H> And only then
[20:35] <shadeslayer> nhandler: congrats btw :)
[20:39] <Factor-H> Another bug is feeding SKYPE with stereo MIC where SKYPE subtracts one channel from the other, witn no option to force a MONO input... resulting in no MIC sound in Skype EXCEPT if you use a declared external MIC.
[20:40] <Factor-H> This happens because for almost 2 years there is no way to force a MONO input in a stereo board with a channel only.
[20:44] <Factor-H> The sound recorder in Ubuntu works therefore properly (he assumes mono) were Skype expects what it is told (stereo MIC). Why the sound is reduced to near zero is a matter of the Skype internal choices, under the incorrect information from the sound system used by Ubuntu. This is noticed in the Aspire-One (again).
[21:01] <mick_laptop> hi everyone
[21:01] <mick_laptop> I'm trying to track down what I believe to be a kernel issue - is anyone around for me to poke if I have issues?
[21:02] <mick_laptop> in short when I copy a file (locally or over ethernet) after a certain percentage- my box freezes and my mouse etc becomes unresponsive
[21:02] <mick_laptop> I'm compiling a kernel from kernel.org (latest stable) to see if it might be a maintream or an ubuntu specific issue
[21:04] <mick_laptop> when I did: wget -c http://192.168.x.x/ubuntu.iso my box would freeze after 82%. When I did: unsquashfs on filesystem.squashfs (cp'ed from /casper on the install iso) - after 2% it always hangs
[21:06] <nhandler> shadeslayer: Thanks a lot (assuming GSoC) :)
[21:06] <mick_laptop> shit - while building the kernel it crashed :(
[21:06] <mick_laptop> i shouldn't have tried to install vim while it was working
[21:07] <mick_laptop> do i need to do a "make clean" or can i just run make again?
[21:07] <seb128> try #ubuntu-kernel?
[21:07] <mick_laptop> it has been running for a long time so far :(
[21:07] <mick_laptop> seb128: thanks
[21:08] <seb128> yw
[21:19] <lars_t_h> mick_laptop, you laptop may have a thermal design problem -  that is - it cannot cool itself good enough
[21:40] <mick_laptop> lars_t_h: it is a desktop - and no, that doesn't happen after 5 minutes of use in a cold room
[21:40] <lars_t_h> ok
[22:05] <mtaylor> if I'm getting a kernel panic on boot consistently with the latest natty kernel - what's the best way to capture/report that?
[22:24] <hallyn> mtaylor: a camera has become a pretty normal way
[22:25] <mtaylor> hallyn: really? ok. I'll go that next. file on ubuntu/+source/linux?
[22:25] <broder> mtaylor, hallyn: install linux-crashdump
[22:25] <broder> https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
[22:27] <hallyn> broder: neat
[22:27] <broder> obviously that requires that the panic isn't *too* early :-P
[22:28] <hallyn> (as mine tend to be)
[23:55] <jibel> TheMuso, Hi, can you help in testing ubuntu desktop and alternate powerpc images ?