[Debian] Continuing development of Debian on NITs
 

This is a development thread. For discussion about *using* Debian on the N8x0 please head over here: http://www.internettablettalk.com/fo...ghlight=debian .

I decided to start a thread for discussion about further development of Debian on the tablets. I realize that my documentation for how I actually put Debian on my N800 is somewhat lacking, but the truth is it was really an evolutionary effort, with lots of false starts and blind alleys. I'm going to redo my whole install over the next couple days, and do it *the right way* while documenting all my steps. That should give anyone interested in further development a better start.

Something else I'd like to discuss here is how to proceed. Is there enough interest in continuing to refine this that we should actually try and get a real project page setup? Who is interested in doing what, and how can I help you get started?

Thanks for all your support and interest! :D

-John

Re: Continuing development of Debian on NITs
 

I'd be happy to help on this project (I already have keymaps to contribute!).

A SF page would be great, and would provide hosting, IMO (Not my original idea, JohnX proposed it).

EDIT: Also, a way of charging while running Debian would be nice. Maybe it can be stolen from Maemo (I can't BELIEVE that they ditched APM!)?

EDIT2: And a custom kernel with modules people may find useful (such as USB-Ethernet chipsets, maybe USB-VGA drivers, while keeping it compatible with OS2008)

EDIT3 (last one, hopefully, for this post): And for right clicking, the GTK thing is unnecessary. The Zaurus world is using XBindKeys to do it.

Re: Continuing development of Debian on NITs
 

For using XBindKeys, see this post:

http://www.oesf.org/forum/index.php?...6&st=0&start=0

It's post #4.

Re: Continuing development of Debian on NITs
 

Ditched APM? This isn't x86, and doesn't have anything resembling a PC BIOS, so I'm pretty sure APM is completely irrelevant. I think bme is running anyway, but haven't checked; are you sure it's not charging?[/quote]

That's awesome, but really a completely independent project. I'm not thinking of any kernel modules that would be useful only under Debian, so this would have much broader utility than Debian.

Re: Continuing development of Debian on NITs
 

I applied for a Garage page. I'd like to get away from doing big "tarball" releases anyways, in favor of packages that can be added to a vanilla debian armel install to provide tablet specific support.

It does charge while Debian is running. bme runs from initfs. All of the functions normally handled by APM can be done some other way. This isn't really a big problem in the long run...

Packages with additional modules seem like a great idea. This kind of modular approach seems like the most sane idea going forward.

This is another reason I'd like to move away from a monolithic root tarball: Having packages that provide different ways to emulate right/middle click seem like a much better idea then trying to force one official way on people. As a N800 user, I don't really want to sacrifice two of my very limited selection of buttons when I can just tap and hold.

-John

Re: Continuing development of Debian on NITs
 

I agree that you should post a lean-and-mean setup as the core install. I would love to see a minimal bootable Debian system as a tarball / deb with add-on debs for various features / functionalities. The Garage is brutally restrictive when it comes to file sizes.

Having done a lot of Debian apt-get installs on the tablet that turn a 100MB rootfs into a 600+MB bloat-system, I've grown to appreciate how much of your initial development is getting that lean, bootable core with none of those bloaty, unecessary packages, but also including custom rebuilt packages from maemo / Nokia to support the hardware.

Over on our chroot discussion page, we've managed to get a minimal Debian rootfs to compress down to 28MB. I guess the problem is that you can't boot to a terminal, because killing the Xomap X server makes the device reboot. So I think your XFce route is still probably the best. If anything, you could go even more lean and not include any WM at all, just start a full-screen X-Term in the core package.

You could have a separate deb in the project downloads for device-specific (not available from Debian repos) window-manager addons.

Re: Continuing development of Debian on NITs
 

In the end what I'd like to do is just be providing a couple custom packages (or scripts the automatically build those packages). Users will just use debootstrap (or a script will use it for them), which will just go out to the debian servers, download some packages and assemble a rootfs. Maybe we'd provide a couple virtual/dummy packages to depend on sets of software, in the same way that "xfce4" depends on everything needed for a basic xfce4 desktop.

Of course, we or someone else could provide a nicely configured debian rootfs if they wanted, but I don't think that's an ideal situation. It makes upgrading as annoying as reflashing and is also hard on bandwidth.

Does all that seem reasonable?

-John

Re: Continuing development of Debian on NITs
 

Also, it's not clear to me (I haven't really looked :o) what, if any, files in the Debian rootfs are actually closed-source Nokia stuff; if any of those are there, it's technically a legal problem to distribute that rootfs. (Not practically a problem at this stage, but certainly something that should be cleared up.) Scripts to build any necessary packages containing limited-distribution stuff from your own firmware seem like a good solution here. But IANAL, of course.

Re: Continuing development of Debian on NITs
 

That is an excellent idea. The user already has those files, they'd be just copied over by the script to the correct places.

BTW: I found my debootstrap rootfs has a locale problem when I chroot to it and start installing stuff; what files do I copy over from ITOS to make the Debian apps shut up about not having the right locale configured?

Re: Continuing development of Debian on NITs
 

shouldn't you do "dpkg-reconfigure locales" ?