... I have found a solution that seems to be working great, at least for my Enlightenment environment, however I am fairly confident it would work under IceWM, etc...
Create the r-mouse and l-mouse scripts As root, create a /usr/bin/r-mouse file that contains:
PHP Code:
#!/bin/sh
/usr/bin/xmodmap -e "pointer = 1 2 3"
and as root, create a /usr/bin/l-mouse file that contains:
PHP Code:
#!/bin/sh
/usr/bin/xmodmap -e "pointer = 3 2 1"
Hi, psykosis,
I really like the look of your solution. I would prefer to use the + key, but the big question I have is:
If you're using xmodmap already (like we're doing for IceWM and the N810 keyboard), will this hack interfere with your already-loaded keymap? I'm hoping that each time you run xmodmap in your click-scripts it will only affect the mouse buttons, but if it erases the other mappings, I'll have to steer clear of this...
To undo the process, will uninstalling the easy-deb-chroot be enough?
Yes. Oh, and deleting your big image file (if that's what you're using). Especially with this new version; there's no dependencies so there's no messy overhead
Well, there's one thing I've been wondering about, - The Debian chroot project(s) and patches have same problems as the bootable Debian for tablets - that we distribute around big tar.gzs (which we don't do anymore) and such and add patches manually and stuff.
I just want to clarify something about my Debian chroot project.
The big image file is purely for the convenience of folks who don't know how to format or mount a partition, and don't want to be bothered doing the apt-get installs for themselves. I have found the image file to be an inferior way to run apps, myself. It is significantly slower than a dedicated partition, and, to keep it more newbie-friendly, I have to keep it quite small, so it is very close to running out of space.
I consider my project to be mainly about the chroot scripts and the little tweaks we can do to integrate the Debian and maemo environments. That's why Benson and I have been working towards making our scripts work well with whatever version of Debian you have. I personally use a dedicated partition and only switch to the image file when I need to test something out for someone with a problem or question.
I would welcome someone from the bootable Debian camp having a go at making the chroot scripts (/sbin/debian especially) completely "bootable Debian beta4 friendly". I want to be able to chroot into a bootable partition without damaging it in any way.
I especially would like to find an elegant way to make sure that the root and user accounts are aligned with maemo upon chrooting without trashing any extra accounts (such as the mpd user from beta3).
I would welcome someone from the bootable Debian camp having a go at making the chroot scripts (/sbin/debian especially) completely "bootable Debian beta4 friendly". I want to be able to chroot into a bootable partition without damaging it in any way.
I especially would like to find an elegant way to make sure that the root and user accounts are aligned with maemo upon chrooting without trashing any extra accounts (such as the mpd user from beta3).
I will try this as soon as I get a stable Beta4 setup and running. In all honesty it shouldn't be too hard.. biggest problem will be users, like you mention, because the new installer creates the users at install time and the UID/GID's are now totally different than the default maemo.. where-as in beta3 most all the accounts were the same except a few were missing and there was 2 unneccesary accounts with different UID's.
Now the actual chroot/iceWM launching shouldn't be a problem.. the only issues I really see is maybe dbus related for permissions, or sharing files between the maemo and the debian side; because of permissions.
Qole - just a thought.. what exactly is the point to copying the /etc/passwd and group files from maemo?? That doesn't actually fix any permissions on the filesystem...
in beta3 you notice no difference because user already has the same 10000 UID as on maemo.. so it's unnecessary and does nothing but break mpd and any other unique users.
in beta4 or any other OS.. if your /home/user was created with a different UID.. say 148, and you copy /etc/passwd from maemo to /debian you will still be unable to access /home/user.. the permissions will show UID/GID 148:148 on the directory instead of saying user..
passwd and group really just give easy names to UID/GID matches.. changing the names to a different UID doesn't actually change any permissions.. only new ones created.. which would create for a rather unstable environment..
Qole - just a thought.. what exactly is the point to copying the /etc/passwd and group files from maemo?? ... if your /home/user was created with a different UID.. say 148, and you copy /etc/passwd from maemo to /debian you will still be unable to access /home/user...
The chroot script mounts maemo /home/user over the Debian one, plus several other maemo system folders (including /tmp); we need to synch permissions so maemo and Debian play nice together.
The chroot script mounts maemo /home/user over the Debian one, plus several other maemo system folders (including /tmp); we need to synch permissions so maemo and Debian play nice together.
Ohhhh right... I forgot about those.. I really need to reload your newer scripts.. i've completely slashed the crap out of the other ones for unique situations lol.
OK .. so I understand the point now when dealing with /home.. I left my /home in tact in the debian side because I made changes to files in there when I was booted into it.. I wanted to make a completely seamless environment whether I was booted or chrooted into the debian side.
* Get DEBUSER from $CHROOT/etc/tablet_user, as we don't rely on user being
'user', and store choice of tablet user in /etc/tablet_user.
* Mount sysfs on $CHROOT/sys
* mkdir -p $CHROOT/media/mmc{1,2},usb
* Mount /home/user onto /home/$DEBUSER instead
* Don't copy /etc/hosts - it's not needed, we have a perfectly good one in
Debian
* I have some doubts regarding /etc/resolv.conf - as it seems to overwrite
the link made by resolvconf .. but I haven't got proper WLAN here in the
mountains (only GPRS over BT, and my Debian isn't set up for that just yet..)
* Do not copy group, passwd. When we install debian the tablet user will
have uid 29999 and gid 29999 and things should go fairly smoothly after
that?
* Do not copy calibration, instead run our x-server-prepare script which
sets up pointercal - this should probably be some thing where it only
installs a new one if the user has set another screen calibration than the
default model ones..
The default user created currently in nit-debian is with UID/GID 1000 and I have no user with 29999 in my /etc/passwd file...
I was thinking of running something similar to removing the mount of the home directory altogether.. and running something like this:
$DEBGRP = `cat $CHROOT/etc/group | grep user: | cut -d: -f3`
find /tmp -user user -exec chgrp $DEBGRP {}\;
find /tmp -type f -user user -exec chmod g+rw {}\;
find /tmp -type d -user user -exec chmod g+rwx {}\;
That would take all "user" owned files in maemo in the /tmp and give them group readable/writable to the "joe" group on the debian side.
The problem I think in mount /home/user over /home/$DEBUSER(joe) without changing the debian /etc/passwd file is that the user "joe" will have UID/GID 1000 (on my debian) while /home/joe will have UID/GID 29999.. so the Debian will think the the "joe" user does not have rights to his own home directory. If we don't mount over the top of /home/joe .. and give r/w permissions to whatever /tmp files necessary for him to interact with the display and dbus.. it should work...
Only downside is the inter-operability between maemo and debian.. IE if a user makes a change to XCHAT in maemo, and the home drives are linked, then the change will take effect in Debian if the user launches xchat.. as an example..
The other option is to change the nit-debian installer to manually set the UID/GID on user creation.. and create the user with UID/GID 29999 .. this way they will match on maemo and debian and no tricks will be necessary for the user to read/write home and /tmp files.
