[09:25] <apw> RAOF (N,BFTL), I _always_ need a dose of bees
[10:24] <yossarianuk> apw: sorry not sent a bug report yet about lack of oss modules yet - however I found an old post regarding it  - http://ubuntuforums.org/showthread.php?t=1656193
[10:24] <yossarianuk>  SNDDMA_Init: Could not mmap /dev/dsp. 
[10:25] <yossarianuk> - similar error for padsp
[10:25] <yossarianuk> anyway - regarding rebuilding the ubuntu kernel source - I have found out what is causing the fail....
[10:26] <apw> yes?
[10:27] <apw> yossarianuk, ^
[10:34] <yossarianuk> (sorry @ work..)
[10:34] <yossarianuk> ill be a few secs..
[10:35] <yossarianuk> ok - it builds fine as long as I don't add CONFIG_LOCALVERSION:
[10:35] <yossarianuk> i.e - append to kernel release
[10:36] <yossarianuk> if I add anything in that - i.e 'test1' the kernel goes through the entire build process then fails 
[10:36] <yossarianuk> if I leave that blank it builds the linux-image package fine
[10:37] <apw> yossarianuk, sounds about right indeed.  you should add something to debian.master/changelog, to the top entry'
[10:37] <apw> +test1 to the end of the version number on that line
[10:38] <yossarianuk> apw: ah - i.e the dch command ?
[10:38] <yossarianuk> or just manual edit ?
[10:38] <yossarianuk> i'll give it a go
[10:38] <yossarianuk> thanks
[10:38] <yossarianuk> This documentation should be updated.....
[10:38] <yossarianuk> https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
[10:39] <apw> manual edit i would recommend
[10:39] <yossarianuk> thanks - i'll try that !
[10:39] <yossarianuk> regarding the OSS snd issue - the apps are 32bit (on a 64bit system)
[10:39] <yossarianuk> I should have the right deps though
[10:39] <yossarianuk> and also it works 100% with a compiled kernel with oss mods...
[10:39] <yossarianuk> I will make a bug report ...
[10:42] <apw> yossarianuk, yep, community member edited that document to add that section which is, wrong ... sigh
[10:46] <yossarianuk> well not wrong - just not complete.
[10:47] <yossarianuk> You just can't get the staff.........
[10:47] <apw> yossarianuk, no blatently wrong, using CONFIG_LOCALVERSION (as you found out) breaks the build
[10:48] <apw> yossarianuk, though i am slightly supprised that the config-check didn't implode for that and stop you
[10:48] <yossarianuk> apw: ah - so when I re-test should I just add to debian.master/changelog or do I add to debian.master/changelog as well as CONFIG_LOCALVERSION  ?
[10:49] <apw> just add it to debian.master/changelog, nothing else
[10:49] <yossarianuk> apw: thanks
[10:49] <apw> the rest should come out in the wash as the build system runs
[10:49] <yossarianuk> I can see if I have edit rights and change this ?
[10:49] <apw> yossarianuk, i have already updated it
[10:49] <yossarianuk> (want to test first anyway..)
[10:50] <yossarianuk> nice one!
[10:51] <apw> it is a wiki, it is easy to edit, which is both good and bad
[10:51] <apw> depending on how knowledgable the editor
[10:52] <yossarianuk> yeah - you sometimes get people (trolls) on purposely adding 'bad data'
[11:02] <yossarianuk> apw:  just to confirm I should change the first line in debian.master/changelog
[11:02] <apw> yes
[11:02] <apw> linux (3.19.0-3.3) UNRELEASED; urgency=low
[11:02] <apw> linux (3.19.0-3.3+test1) UNRELEASED; urgency=low
[11:02] <apw> like that sort of thing
[11:02] <yossarianuk> great cheers
[11:03] <yossarianuk> i'll let you know if that works ....
[11:54] <yossarianuk> apw: cheers - worked fine!
[14:53] <Odd_Bloke> I'm hitting this error when running the kernel tests: http://paste.ubuntu.com/9806187/
[14:54] <Odd_Bloke> I tried running them with sudo (i.e. sudo ./runner qa) which did address this, but other tests fail if they're run as root.
[14:54] <Odd_Bloke> I can poke at fixing it myself, but didn't want to do so if someone could point me in the right direction. :)
[15:04] <apw> Odd_Bloke, doesn't that show it running that failing sub comamnd as root ?
[15:04] <apw> Odd_Bloke, ie with a sudo ?
[15:11] <Odd_Bloke> apw: No, ./runner is being run as the ubuntu user.
[15:11] <Odd_Bloke> I think it isn't logging what is failing.
[15:11] <apw> Odd_Bloke, but the commands which are run have sudo on them in a lot of cases, perhaps the failing one needs it adding
[15:12] <apw> Odd_Bloke, rather than running the whole of runner as root
[15:12] <apw> Odd_Bloke, as clearly it expects to need to do that
[15:13] <Odd_Bloke> apw: The failure happens in the call to shutil.copytree, which is within runner (i.e. the only way to get that particular line to be privileged is to run runner as root).
[15:13] <apw> Odd_Bloke, do we know where it is trying to copy too ?
[15:14] <Odd_Bloke> apw: I believe the three elements of the tuple in the shutil.Error line are from, to and error text.
[15:17] <Odd_Bloke> Let me pull down that directory and see what does end up in there.
[15:20] <Odd_Bloke> Oh, of COURSE it worked this time.
[15:36] <apw> Odd_Bloke, oh good :<
[15:39] <Odd_Bloke> I'm trying another full run, in case that's what triggered it.
[15:39] <apw> yeha its going to be like first date nurves or something
[20:54] <hallyn> apw: do you know of any firmware bug in recent sru which sould have prevented a desktop system from mounting some drives/filesystems?  
[21:28] <sforshee> hallyn: which release? I think the only recent firmware SRU was some intel wireless updates.
[21:30] <hallyn> sforshee: 2015-01-19 20:33:12 upgrade linux-firmware:all 1.127.10 1.127.11
[21:30] <sforshee> hallyn: yeah, that one was only updates for iwlwifi
[21:31] <hallyn> there was also a libc6 and multiarch update, maybe those are more likely
[21:32] <sforshee> I suspect so. That would be some bad wireless firmware if it caused mount issues.
[21:34] <hallyn> well, or a bad grub-update or something?
[22:08] <infinity> hallyn: Blaming glibc for being unable to mount some filesystems seems far-fetched too.  What's the exact symptom?
[22:10] <hallyn> infinity: i didn't say i blamed it for not mounting the fs.  all we know is it didn't get to mounting filesystems
[22:10] <hallyn> the bug was reported third-hand, and machine owner does not speak english
[22:10] <hallyn> bug reporter and victim machine (and its owner) are on differnet sides of whatever country they are in
[22:11] <infinity> hallyn: Brilliant.
[22:11] <hallyn> hm, what's your lp id actually?
[22:12] <infinity> hallyn: So, it's hard to say without seeing the exact symptoms, but the bug/misfeature I run into all the time (just had to fix it on the ppc porter a few days ago) is that if fstab references a mountpoint that doesn't exist, mountall can hang.  Which is something you never notice until a reboot.
[22:12] <infinity> hallyn: adconrad
[22:12] <infinity> hallyn: A boot with init=/bin/sh and grubbing around in fstab can often be enlightening.
[22:13] <hallyn> infinity: yeah that appears to be impossible, though iiuc maybe after feb 7 he can d oit.  sigh
[22:13] <hallyn> (subscribed you to the bug :)
[22:13] <infinity> hallyn: #?
[22:13] <hallyn> the reason it interested me is bc it seemed similar to a container bug stgraber was seeing, where he is guessing that upstart's reexec failed
[22:13] <hallyn> 1412671
[22:14] <infinity> hallyn: Oh.  Weird.  Kay, if downgrading fixed it, it's not the mountall thing.
[22:15] <hallyn> yeah, i really think if they'd powered it down and back up it would have been fine, just reexec failed.  
[22:15] <infinity> hallyn: Err, but the bug is that it fails *on boot*.
[22:15] <infinity> hallyn: Not on upgrade.
[22:16] <infinity> hallyn: Really tempted to blame cgmanager. :P
[22:16] <hallyn> yeah, well, i'll try to reproduce in a kubuntu vm i guess
[22:16] <hallyn> who knows, maybe it *is* cgmanager
[22:18] <infinity> Then again, I don't speak fluent nih_, but I don't see how the 7.1->7.2 delta could make things more broken.
[22:19] <hallyn> or more importantly how cgmanager could block the system booting.  
[22:19] <infinity> Yeah, that.
[22:20] <infinity> hallyn: The upgrades/downgrades may well be a red herring, and he may just have a racy boot that's showing an intermittent mountall or upstart bug.
[22:20] <hallyn> chuckle.  good point
[22:21] <infinity> hallyn: But yeah, without the ability to do some good back-and-forth, it's kinda dead in the water until Feb7 anyway.
[22:21] <hallyn> asked fo ra few more reboots :)
[22:22] <hallyn> one would expect more such reports if this was a real sru regression