MEPIS Community Forum

Hi Just noticed this ref to kernelcheck and wondered if you'd heard about this problem with it?

>>>
Testing your network connection...
Connection found.
have not read
read feed
Traceback (most recent call last):
File "/usr/share/kernelcheck/scripts/main.py", line 502, in get_data
patch_url, patch, stable, stable_url, OldKernelList, OldKernelLinks, prepatch, prepatch_url = self.kernelinfo()
File "/usr/share/kernelcheck/scripts/main.py", line 126, in kernelinfo
KPParser.close()
File "/usr/lib/python2.5/HTMLParser.py", line 112, in close
self.goahead(1)
File "/usr/lib/python2.5/HTMLParser.py", line 164, in goahead
self.error("EOF in middle of construct")
File "/usr/lib/python2.5/HTMLParser.py", line 115, in error
raise HTMLParseError(message, self.getpos())
HTMLParser.HTMLParseError: EOF in middle of construct, at line 7, column 11
>>>

I had a look around and downloaded some script (.py) patches but the errors are more or less the same once 1.2.5-3 is patched.
The errors I've just typed in are from running the repo version 1.2.5-4mlrepo3(mepis). Pity as I find it's a very useful util.:(

The same problem seems to affect Ubuntu users, too.

Good news is that the developer is active again and may have a new 1.5 version soon. And the revised do-it-yourself version in the Mepis wiki also works well; I just patched and built the latest 2.6.33 Liquorix kernel using that method an hour ago.

Unfortunately, my week off ended today :(.

I also doubt the 1.5 version will be out for a few more months - but it looks great so far - besides the actual compiling part. I'm currently working on patching 1.2.5... again. Hopefully Scott can pick up any pieces I leave behind if I go inactive again.

The version in trunk is now fixed - just issues with the application menu again but I think Steve had a patch for that in his version.

Thanks--I will try a rebuild from the trunk source...since the 1.5 version requires Python 2.6, and I got a failure trying to port that back to Mepis, that's good news.

Has any thought been given to having kernelcheck use fakeroot to build the kernel as a regular user in the user's $HOME instead of in /usr/src? The Debianites strongly suggested that on their user forums, and I changed our wiki here to that method, same as used on the Ubuntu wiki. When I do it, the build and source links in /lib/modules always come out pointing to the build folder, whether it's /usr/src/linux with kernelcheck or someplace in my home folder if manually done...so i just run a little scriplet to point them to the kernel header folders. It only seems to be an issue for the person that built the debs; other machines get the header links correct upon install. I know you'd have to switch to root access to install the kernel and modules after the build.

I've actually changed the Master Kernel Thread to add $USER to the src group which has write access to /usr/src and compile the kernel with fakeroot. I just have to figure out a way to su to the USER while still maintaining access in the script. Possibly su -c, but I need to find a better way.

OK...but you can compile the kernel debs without any root access at all if you build with fakeroot inside the user's home folder someplace instead of usr/src. It's no different than how we build deb packages for our repository using fakeroot. I can see that access will still be needed to install the kernel build-depends...but I wonder if there's some way to use fakeroot to also build external kernel modules. Those are getting pretty scarce now, anyway, with dkms building modules automatically as soon as the kernels and headers are installed.

Come to think of it, I'd rather have the kernelcheck deb depend on the kernel building tools instead of having the program do an apt update and make sure they are installed every time. They would have to be if the package depends on them, and then kernelcheck would not need root access to do that. Users that use the raw setup.py file can take a look at the README file to see what they need to install.

OK, I've done a pull from the bzr trunk and repackaged it, the source files and arch-independent deb are here. It ought to work on 8.0 and 8.5, and has fixed the bug.

Link: https://sites.google.com/site/stevosfilehideaway/Home/more-files/kernelcheck-fixed-16_april_2010.zip

I moved this discussion to it's own thread since it has little to do with the wiki review any longer.