[08:43] <|MA|> hi all
[08:43] <|MA|> I have a kernel buil related issue
[08:44] <|MA|> http://paste.ubuntu.com/376717/
[08:44] <|MA|> any thoughts how i can fix it ?
[08:45] <smb> Install ncurses-dev
[08:46] <|MA|> libncurses5-dev is already the newest version.
[08:46] <|MA|> 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
[08:47] <ghostcube> smb: i send him here cause i didnt know how to help any firther :)
[08:47] <ghostcube> further even
[08:48] <smb> Maybe some other headers it does not complain about... 
[08:48] <smb> Like complete build-essentials...
[08:49] <|MA|> E: Couldn't find package build-essentials
[08:49] <smb> Err, sorry without s at the end
[08:49] <smb> build-essential
[08:50] <|MA|> build-essential is already the newest version.
[08:50] <|MA|> 0 upgraded, 0 newly installed, 0 to remove and 15 not upgraded.
[08:50] <|MA|> I did even build the kernel 2 days back
[08:50] <smb> Is your pastebin output all that gets out? Tried "make V=1 menuconfig"
[08:50] <|MA|> running that too ... Linux manu-04 2.6.31.6-ma3 #1 SMP Sat Feb 13 14:16:22 GST 2010 x86_64 GNU/Linux
[08:51] <|MA|> since yesterday, it is behaving thus
[08:52] <smb> Is /usr/include/ncurses.h still there?
[08:52] <|MA|> ok, here it is: http://paste.ubuntu.com/376736/
[08:53] <|MA|> http://paste.ubuntu.com/376737/
[08:53] <|MA|> It is there, yes
[08:57] <smb> For me that would be a link (which could be broken) but to get the real error you might temporarily edit linux-source-2.6.31/scripts/kconfig/lxdialog/check-lxdialog.sh
[08:58] <smb> and remove the 2>/dev/null in that line $cc -xc - -o $tmp 2>/dev/null <<'EOF'
[08:59] <|MA|> I will temporarily comment it out
[09:00] <smb> The line itselfs must be there
[09:00] <|MA|> http://paste.ubuntu.com/376741/
[09:01] <smb> Sounds like you did the wrong thing to the script
[09:01] <|MA|> only the 2> ... ?
[09:01] <|MA|> let me try again
[09:02] <smb> check() {
[09:02] <smb>         # $cc -xc - -o $tmp 2>/dev/null <<'EOF'
[09:02] <smb>         $cc -xc - -o $tmp <<'EOF'
[09:02] <smb> or like that
[09:03] <|MA|> wow, it comes up again.. let me but paste you the output
[09:04] <|MA|> http://paste.ubuntu.com/376742/
[09:04] <|MA|> thanks
[09:05] <smb> Hm, not really what we wanted
[09:05] <smb> In theory this should just let the error messages go past
[09:05] <|MA|> but it now works at least
[09:05] <smb> Can you do a make clean and then a make with V=1 again?
[09:05] <|MA|> sure, moment
[09:08] <|MA|> here it is: http://paste.ubuntu.com/376746/
[09:09] <|MA|> this is with the commented out stuff in the kernel build script
[09:12] <smb> Hm, now your lines between check() and the include might be interesting. But one other thing, I saw you do a sudo. Might it be you just have a permissions problem? Like written the directory as root?
[09:13] <|MA|> not a permissions problem. Was doing everything with sudo
[09:13] <|MA|> except for the one in between
[09:14] <smb> Ok (though feels a bit dangerous to me, but then not the problem). Can you paste me your lines of the check script then? Should only be three or four so the channel is ok
[09:16] <|MA|> here it is : http://paste.ubuntu.com/376750/
[09:18] <smb> Its quite weird, the change only should make the error messages from the check script go to stderr instead of being suppressed. And the check itself looks at the error code from the call, which should be unaffected. So between before and after it still should fail the same.
[09:19] <|MA|> but now it works for me
[09:19] <smb> Does changing the cc line into "$cc -xc - -o $tmp 2>/tmp/check.log <<'EOF'" make a difference?
[09:19] <|MA|> you mean reverting back ?
[09:20] <smb> Partially. Instead of writing to /dev/null write to /tmp/check.log
[09:20] <smb> Which brings up a weird thought. What does 'ls -la /dev/null' produce?
[09:21] <|MA|> manu@manu-04:/usr/src/linux-source-2.6.31$ ls -la /dev/null
[09:21] <|MA|> crw-rw-rw- 1 root root 1, 3 2010-02-15 00:13 /dev/null
[09:21] <smb> Ok, nothing wrong with that
[09:21] <|MA|> ok, works as well, with the changed script
[09:22] <smb> I bet, if you change it back to how it was, it works as well
[09:22] <|MA|> nothing in /tmp/check.log though
[09:23] <smb> And actually, when I look at your initial posting:
[09:23] <smb> manu@manu-04:/usr/src/linux-source-2.6.31$ make menuconfig
[09:23] <smb> ^ no sudo there
[09:24] <|MA|> uh
[09:25] <|MA|> dang
[09:25] <smb> :)
[09:25] <|MA|> but :
[09:25] <|MA|> changed back
[09:26] <|MA|> http://paste.ubuntu.com/376756/
[09:26] <|MA|> same old thing
[09:27] <|MA|> should i change it back to /tmp/foobar ?
[09:27] <|MA|> eargh .... /me goes nuts
[09:28] <smb> Seems like a very odd thing that writing to /dev/null would fail while other tings work
[09:29] <|MA|> I am out of my wits end
[09:29] <smb> And its probably something not too many try out as root. Most are to paranoid to have the compile run as root
[09:31] <|MA|> my machine is a devel machine, where i err .. work on some drivers ... I am not too paranoid ... There were much more things to be paranoid such as HDD's getting fscked etc etc
[09:31] <|MA|> -were +are
[09:32] <|MA|> If i could get this thing up at the earliest i could get back to my work on some shiny new drivers ..
[09:33] <|MA|> :)
[09:34] <smb> True. And I usually have the tree not that way, so I would not notice oddness. I can try out to have it that way. One thing in general, have you ever tried to get the sources with "apt-get source linux-image-2.6.31-x-generic"? That way you also have the debian build environment with it and the default configs...
[09:34] <smb> I'll try whether having the tree as root shows the same problems here
[09:34] <|MA|> that's what I did initially, but I had to tweak some settings such as MSI-X and some others
[09:35] <|MA|> as well as some more kernel hacks
[09:36] <|MA|> that would be great. Thanks a lot
[09:36] <|MA|> at least I am able to get back to get it up at least
[09:37] <|MA|> Other than that, I am  a bit annoyed with the nvidia post install script as well. kernel install failed earlier, then i had to remove the nvidia-common package
[09:37] <|MA|> which helped me to get the kernel installed
[09:37] <|MA|> so many new hassles introduced ... wasting a lot of precious time
[09:38] <smb> Yes, I'd probably use the /tmp/foo variant. You could base on apt-get source version for your work and make tweaks to debian.master/config 
[09:38] <|MA|> also applications such as acroread doesn't work. You know: evince and such applications do not open all the PDF file formats, that's to add to the yuck's
[09:39] <smb> Not sure what the problem with the post install is. But usually most things are set to work with the .debs produced by compiling the debian way.
[09:39] <|MA|> all these made me pull out my hair a lot, it took me 2 days to get the system up, as opposed to a few hours as of earlier versions
[09:40] <smb> And acroread, well... Seems to work for me, which is likely not much help
[09:40] <|MA|> well anyway, I got to get it going with a virtual host machine and used acrobat reader there. No other alternative ...
[09:41] <|MA|> since some of the document would open there alone, due to security reasons
[09:45] <smb> security reasons? So a make menuconfig works for me here. Could it be you got some security framework active that might be over restrictive?
[09:46] <|MA|> by security reasons, I mean protected documents from some people that i receive. Those documents seem to open only with acroread and hence.
[09:46] <smb> ahh ok, misunderstanding there, then
[09:47] <|MA|> some nastiness in those docs. They are sometimes password protected; then you can't copy/paste etc
[09:48] <|MA|> so regular pdf readers don't handle all those stuff
[09:48] <|MA|> and hence the document in some cases don't open up, or look like some Martian languages, like fully clobbered up
[09:49] <|MA|> in short, if you seriously use PDF docs, acroread is in some case unavoidable
[09:49] <smb> Had something like this. But in my case evince was able but acroread wasn't (due to fonts). But in generall acroread works on this system
[09:49] <|MA|> unless other apps catch up
[09:50] <smb> As well as I cannot reproduce your strange problem with the compile.
[09:50] <|MA|> I have been going through real weirdness. Don't just remind me of it
[09:51] <|MA|> and that too, when you just want to get something moving really fast
[09:51] <smb> Unfortunately that happens usually whenever you want something done fast... :/
[09:52] <|MA|> true: murphy is there to strike at will
[09:52] <smb> One thing you could check is apparmour_status. Not really expecting something there, but...
[09:53] <|MA|> I had disabled apparmour completely
[09:53] <|MA|> not wanting to have such stuff on a development machine
[09:53] <|MA|> i would more or less term it as an open frame machine ... ;-)
[09:54] <|MA|> where i can swap the hardware, cards in really fast
[09:55] <smb> Well, that should be possible with or without apparmor. :) But at least without it it cannot be any reason for strangeness
[09:55] <|MA|> yup :)
[09:55] <smb> Just for a test. When you are root. Can you do a echo bla >/dev/null?
[09:55] <|MA|> sec
[09:56] <|MA|> yes, i can 
[09:56] <|MA|> manu@manu-04:~$ sudo echo blahblah >/dev/null
[09:56] <|MA|> [sudo] password for manu:
[09:56] <|MA|> manu@manu-04:~$
[09:57] <smb> No, do the sudo -i before
[09:57] <smb> That way null is opened as the user
[09:58] <|MA|> yup
[09:58] <|MA|> root@manu-04:~# echo blahblah >/dev/null
[09:58] <|MA|> root@manu-04:~#
[09:59] <smb> Then I must admit, I cannot really help as I have no clue what might be wrong, sorry.
[09:59] <|MA|> but anyway, you have been a big help. At least I can get going on it
[09:59] <|MA|> thanks again
[10:00] <smb> Yeah, at least some workaround. Though it feels like "quick backup all your work, this machine is odd"...
[10:01] <|MA|> I have all my work, except for the kernel builds on a completely separate hdd
[10:01] <|MA|> even in case something causes a freeze and fscks my /
[10:02] <smb> Ok, very reasonable for a development box. :)
[19:44] <crimsun> ooh, exmap is fixed