There is a thread somewhere (by AapoRantalainen) about effort to update all Maemo packages to Squeezy, by resolving problems, one at a time, that arise during doing so. Considering where they are after some months (with many people participatingj, I'm not sure if it is doable idea - and it seems like only way to allow you installind *additional* packages from Squeeze. But, do not want to discourage you - you may want to search for that thread and cooperate with them, if you're still wanting to try

/Estel

Resolved:Problem with apt was caused by spurious entry in /etc/apt/apt.conf. Furthermore, it turned out, that reinstall isn't needed - see:
http://talk.maemo.org/showpost.php?p...postcount=2924

Yes, testing is not applicable to Wheezy. I removed it and after that apt worked fine. I think it was in one of the preferences files that confused apt but I don't remember which one. There aren't that many of them anyway, just have a look around.

You yourself mentioned that Chromium was broken in Wheezy because of some downstream bugs. I don't use Chromium so I never noticed.

Thanks, I'll try to find this myself. As for chromium, I'm talking about squeeze one, of course.

// Edit

OK; now I feel ashamed - offending entry about Testing was in /etc/apt/apt.conf. removing file (or it's content) did the trick.

Resolved:

It turned out, that I had spurious file /var/lock/qmount-complete in my ED backup image (which I used to extract ED from). Normally, this file would be deleted on closing chroot, but due to it's existence (and content, originating from using dedicated partition and mounting it as /.debian), qchroot got confused, and skipped whole part of script, responsible for mounting hardware, dbus, and friends.

In itself, it wouldn't be big deal, as spurious file would get deleted on closing chroot, and new one (with correct content) would be created on new start of ED (i closed and opened it many times). Hoever, here interfered effect of my stupid idea, to unpack ED into /home/.debian, yet, create symlink pointing to it, from /.debian - and use the latter as chroot dir.

Yea, I have no idea what I was thinking yesterday - this was completely unnecessary complication, and only reason for it, was that I was using /.debian as mount point for dedicated partition in past, and had it already in .chroot config file. Instead of just changing it to /home/.debian, I created mess by symlinking :stupid: (which was more work than just fixing it in config, anyway, especially, that I had to put "none" for IMG= in config, no matter what...)

Even leaving my stupid idea aside, it *should* work, and worked for most things, *except* for what it was intended for (Maemo knew about symlink, but ED couldn't from it's chroot jail, so, despite having all things mounted to /.debian/*, /home/.debian couldn't use it), *and* closechroot. Method of unmounting things in the latter isn't bulletproof enough to determine symlinks - it checks /proc/mounts for names containing path to chroot (which was symlink), while /proc/mounts have symlinks targets listed there, not symlinks themselves (obviously).

This left me with whole lotta mess of remaining "ghost mounts". I cleared all of it, got rid of symlink, and voila, everything works. Lesson earned - really think twice, before getting such stupid ideas s symlinking chroot dir :P
---

The plus is that, while searching for case, I went through reading all ED (and, generally, easy-chroot) components - refreshing my idea about what is there, and what isn't. It seems, that my knowledge raised much since last time I've seen them - this time, I wasn't having problems understanding what is going on and why (which explains, how pitifully low my level of understanding was back then, few months ago :P ).

As a result, I fixed some routines that were less-than-bulletproof, some trivialities, and added new functionality here or there (like ability to define custom string of filesystem options in .chroot config file, instead of hard-coding it into easy-chroot's guts, everytime we want to use dedicated partition with some optimized mount-time parameters.

IF autobuilder is going to ever start working again, I'll try packaging it up, and releasing first update to easy-debian main package in a years (wooho!). Of course, my little tweaking is just an addition - mostly, it will contain various bugfixes scattered around this thread (like the ones allowing to seamlessly using directory for chroot, instead of dedicated partition or IMG file.)

/Estel

How to get gprs working in ed??

Have you actually tried before asking this? It works out of the box, as soon as you enable it in Maemo. As long as ED is working as it should.

Estel & other devs: What about making a minimal image (max 1GB)? It'd contain only the must stuff (apt, lxde) but no gimps & etc. from Deb Squeeze (as it's latest stable on n900)

There is a barebone image (about 50 MB), just search the thread. I would look it up for you but I am typing this from my N900. Starting from that, I installed just Iceweasel and Office and grew to just around 300 MB. In a directory under /home. No extra partitions or whatever. There were some small issues, check a few pages back to see my solutions.

I'm using directory-based ED without any problems, but noticed funny glitch. The thing is that, I used to call "debbie exit" from /etc/event.d/ script at boot, just to have ED mounted all the time (and avoid partition mounting delay, when I want to do something in ED quickly). It worked flawlessly.

Now, using directory based ED, it *always* produce borked chroot - everything seems fine, except that no hardware/system is mount/bind. If i close ED and open it again (even via the same 'debbie exit'), it mounts just fine.

Not that it matters anymore, as using directory based chroot, there is 0 (zero) delay in ED startup, even if closed "to bare ground". I'm just curious - I wasn't able to find anything in qchroot scripts, that would explain different behavior when called from event.d, than executed normally. Or, why it acts differently, when using directory, instead of separate partition.

/Estel

My first instinct was timing but since you say it worked then that must be off. Except - your ED directory is somewhere under /home, right? Perhaps you try to automount ED before /home is mounted. It worked when ED was on its own partition because the timing didn't matter. Just a speculation, I'm sure you've considered that already.

I too was considering automounting ED on boot but decided against because of the mess it makes in mass storage mode.