Re: Easy Debian Fremantle Beta Testing
 

Not really. You're right, I should have set my locales to EN as well. But I just didn't think that it might actually be of public interest. I thought qole would use it as a template for a completely new image.

The only thing you should make sure is that it contains no compromising data like your personal VPN login data or something similar.

Another good idea to minimize the size of the compressed image would be to nullify all the empty space in the image. It just did it by creating a file from /dev/zero inside of the image and deleting it. But there's also the Debian package zerofree which should do that even more comfortably.

Re: Easy Debian Fremantle Beta Testing
 

Thanks! What about the:

(probably, You've started to write, before I edited)

/Estel

Re: Easy Debian Fremantle Beta Testing
 

Absolutely agree with you.

Re: Easy Debian Fremantle Beta Testing
 

@sulu
i was failed install libre office and i'v got this:

root@m5sulu: /]dpkg --configure -a
dpkg: failed to open package info file `/var/lib/dpkg/updates/0017' for reading: Stale NFS file handle

please tell me how to solve this problem..
thank you

Re: Easy Debian Fremantle Beta Testing
 

Yes, the orientation script goes to /usr/bin/ and is executed from within ED.
The LDXE, HLXDE and XLXDE directories are lxpanel configurations and go to: /home/user/.config/lxpanel/

If you have a look at the orientation script you'll see that every time the orientation of the desktop is changed another panel profile gets loaded since I found it useful to always have the panel on the short side of the screen. Just like my entire image I considered these profiles to be an example of how the lxpanel might be influenced by the orientation. So if you copy these profiles to your image you'll have my panel layout as well and I'm not sure if that's what you want because it differs quite a lot from the Easy Debian default panel.
The LXDE profile is my panel for the landscape desktop. HLXDE (H from horizontal) is basically the same panel for the portrait desktop, and XLXDE is the HLXDE profile plus an xvkbd keyboard plus a "dummy panel" (width=1px) to prevent other windows from covering xvkbd (or being covered by it).
Unfortunately each of those profiles has to be edited separately, so if you want to add another icon to your panel you have to do it in all three profiles if you want them do be consistent. And the positioning of the xvkbd window depends on your panel layout.
So I suggest to not simply copy my profiles but adjust them to a default panel layout.
Edit: And then there is this orientation.desktop file which creates a (more or less) nice icon (I'm sure one can find a better one, I was to lazy to search) and goes to: /usr/share/applications/

I think it's a good idea.
I haven't tested (nor checked for backdoors) them yet but I think these two additions for chromium respectively iceweasel might be useful:
http://www.chromeextensions.org/appe...g/chrometouch/
https://addons.mozilla.org/en-US/fir...grab-and-drag/

I appreciate your trust in me but frankly I can't guarantee that I'd be constantly available as a developer or even host of Easy Debian. Everything I've contributed so far is just what I've done for myself. So I'll be happy to continue giving further support but I don't really want to be in charge of a project.

I'm sorry, in my experience this is a very nasty error which I've not been able to fix yet. Whenever this occured to me I just restored my (hopefully up to date) backup image and started over again.
Usually this error only happens when the watchdog reboots the N900 during a software installation because it thinks it's frozen due to a runaway process. To prevent this always start processes which are going to occupy the CPU for a long time with nice, e.g.:This way the watchdog will always get the CPU priority when it thinks it's time to check if everything is still alright.

Edit:
just a thought:
With Debian introducing the new armhf (hf= hard float) architecture and the N900's Cortex A8 supporting this architecture might it be possible to re-base Easy Debian on it? I've read about performance increases of up to 40% in special situations (although mostly it won't even be noticeable). If it works this won't happen anytime soon (maybe in a year or two), but I'd like to have some thoughts of people who are more familiar with this topic than I am.

Re: Easy Debian Fremantle Beta Testing
 

Not sure about this, but if you compile the whole system (easy debian in this case) with HF you might also need an adapted kernel (unless the interface between libc and kernel is independent of the architecture/ABI, which is probably not the case).

Some day we'll be able to boot an HF-compiled debian with an upstream kernel, but it'll take some time until that happens..

Re: Easy Debian Fremantle Beta Testing
 

Since I believe* the existing Maemo kernel makes best use of the hardware, it should already be armhf compatible. No idea if that's actually necessary or if an armhf-compatible libc would suffice, but if it is necessary that shouldn't be a problem.

Well I think recompiling the whole Easy Debian software doesn't make much sense. If that's what you want to do I think Arch or Gentoo would be better distributions. Plus, recompiling every binary with armhf support would practically mean to create a new architecture on our own. I have thought about that earlier but I didn't find it practical then and I don't think so now.
That's where the Debian's official armhf port comes in handy now. Theoretically we could start building armhf images right away. The reason why I think there will be a delay of over a year is that it doesn't make much sense to base Easy Debian on Testing or even Unstable since it's supposed to be useable for everybody, not just for Debian experts (heck, I don't even consider myself to be one). Therefore I think the Wheezy freeze is the first date that might make an armhf Easy Debian useful.

*) read: I have absolutely no clue but it would be wise

Re: Easy Debian Fremantle Beta Testing
 

I second this!

Re: Easy Debian Fremantle Beta Testing
 

Thanks a lot Sulu, some nice suggestions here.

As for chromium extensions - I've already incorporated "Scrollbars anywhere", which is (AFAIK) most customizable "touch scroll" thing for Chromium. Using it, I was able to enable "drop and drag" (also on text/images), while still retaining capability to select text/drop page elements/whatever. I'm pretty sure everyone will find fancy customization mix for own liking. I also checked it for backdoors, at least as much as my limited skills permit ;)

Of course, such editing can be done from (ED) desktop itself, not only by editing config files by hand? I'm going to check it myself, of course, but I think that writing answer here may be useful for further readers.
---

armhf seems to be great idea, yet I agree, that we should wait a little for at least some* maturity from HF versions. Of course, if someone want to volunteer, and prepare such images ASAP, I'll be glad to test them, nevertheless.

*not that I have a clue about kernel support for it, or whatever ;)

/Estel

Re: Easy Debian Fremantle Beta Testing
 

I don't think our kernel was compiled with hardfp, as obviously this would have implied that the whole of Maemo would have also been compiled like that.

If we somehow were to replace all packages (incl. glibc) with recompiled versions using hard-float then the kernel would have to be made aware of that (unless the kernel uses a specific, EABI-independent, calling convention for system calls, which I don't think is the case).

Well, despite posting in this thread, I did not talk about Easy Debian itself, but debian in general. Heck, I don't even use Easy Debian, but run something similar (used debootstrap for that).

At least my plan is/was to use debootstrap to install the armhf debian port, but then if my guess about the kernel is right, it would not work under chroot, but would need its own kernel (should be no problem thanks to u-boot). But then you can forget about all the maemo things that work while in a chroot, such as making phone calls :)

Re: Easy Debian Fremantle Beta Testing
 

Re. HardFP

If anyone has time and wants to play around. Make a new partition (or loop-mounted file), and try following this:

http://wiki.debian.org/ArmHardFloatChroot

Report your findings :)

Re: Easy Debian Fremantle Beta Testing
 

I've finished preparing my ED partition for uploading. It contains all discussed tweaks (LibreOffice instead of Open Office, Chromium instead of Iceweasel, fixed pulseaudio) + few more. I'm now tar.gz'ing it.

I've spent few hours adjusting GUI settings and panel configurations, including portrait ones (which is quite funny, as I don't think I'll ever use that, but, whatever...). sulu's panels were totally depending on his applications (no offense, as he never stated, that it's looking otherwise) - on my image, being qole's v3e, dist-upgraded to Squeeze, with tweaks mentioned before - only 3 icons were pointing to existing things ;) so I decided to re-create them from scratch.
---

In between, I got an idea, that allow us to save precious screen space, and have it all (namely, 800x480 pixels) available for programs, *without* sacrificing existence of panels. Configured to automatically hide, when setup properly, they pop-up on tapping just *outside* the screen. They're perfectly functional, and just disappear when not needed - popping up, they're also on top, so aren't covered by any application, despite it use all available screen.

It require (very) little practice, and, overall, getting used to, but works great. Added benefit, is that we can have larger icons (etc) in panels, to the point of (almost) finger-friendly - popping up and hiding on request, their size doesn't matter.

Honestly, it turned out to work so good (after little tweaking), that it feels just like having 2 new buttons outside N900 screen :) It may be hard to describe by writing, but You'll get what I mean. Just remember, to tap a little bit "outside" screen, on panel's side (tapping need to be a little bit stronger than usual).

Rationale:
Technically, we're using characteristic of resistive touchscreen - it's much less responsible on edges, so tapping "outside", result unavoidably on (registered) short, yet quick "swipe" from inside screen to the edge. Normally, it may be considered con, but in our case, it emulates moving mouse cursor "to the very edge".

On portrait with "docked" xvkbd, I've set top panel to be always visible - it use space from xvkbd head's border (not used for anything), so no reason to hide it.
---

I wasn't able to find sulu's orientation.desktop anywhere, so I created one from scratch, using CSSU's image from orientation-lock applet - it fits perfectly as icon for rotating. Of course it's placed on top panel, being easily reachable.

The only glitch I've found, is that after rotation, desktop background doesn't refresh properly (I've set it up a way, that it *should* look good on both landscape [no change here] and portrait) - after "forcing" refresh (by changing desktop display setting, and changing it back), it looks OK, but fail to do so automatically.

Of course, it's *very* minor thing, yet, if someone know good way to force desktop's image refresh in LXDE (kill? What to kill?), I can still update orientation script inside tar.gz to do so.
---

I'll upload it as tar.gz - so, perfectly ready for unpacking in dedicated ED partition (will post appropriate command + which file tweak to make chroot look @ for partition, not image file). I can also create image file, if someone tell me how to prepare one accepted by ED, step by step (never used images, and I'm not interested in doing so, due to *high* performance loss when using partition images vs real partition)

/Estel

Re: Easy Debian Fremantle Beta Testing
 

Would it? As far as I understand it an armhf kernel should be able to execute programs compiled for armel. That would mean that the userland doesn't have to be recompiled necessarily, but it would benefit from it.

That was my idea too. But unfortunately I won't have time for that until late next week. So if you have any plans of doing it, please do it!
btw: Do you have any application in mind that might be a good benchmark for an armel vs. armhf performance test (ideall without having to install an X server in the chroot)? I guess video encoding might be a good benchmark).

Sounds familiar. ;)

That tapping outside thing sounds ingenious if it works as you described (not sure if the screens of all the N900s are equally responding). That would actually allow to have four panels, one on each screen edge.

You would have found it in /usr/share/applications of my image. However, whatever .desktop file you created it's surely better than mine since mine was really just made quick&dirty.

Try calling:I don't know if it works but that's what's written in the manpage.
If it works, add that command to the orientation script. I never bothered with that since I use no wallpaper.

Example for a 4GB image:Then just mount the file and copy your data.

Re: Easy Debian Fremantle Beta Testing
 

I´m waiting for Estel new image to trie it opfully with instruction to make a partition or image that I´ve allways used
Thanks

Re: Easy Debian Fremantle Beta Testing
 

I'm using a debian sid armhf chroot on my N9, and its running fine.
It does not have all squeeze packages yet, but I already installed all the devel environmnent, qt, pidgin and so on.

Harmattan itself is hard float abi.

Re: Easy Debian Fremantle Beta Testing
 

I'm trying sulu's suggestions now (thanks, sulu!), so in meantime - to use ED on dedicated partition, You need to - obviously - have dedicated partition ;) You can just create one on microSD card, but best approach - performance wise - is to left microSD for swap, and create partition for ED on eMMC.

Rationale:
The worst things for performance, when talking about swap on flash medium, are I/O collisions. Having swap and /home/ + opt in the same (physical) storage is bad. Having /home/ + opt on one medium, and swap + ED on another is better, but You still generate I/O conflicts, while using ED.

On the other hand, having /home/ + opt and ED on one device, while swap on another is *much* better - normally, You would not create many I/O conflicts between /home + opt and ED (most likely, you won't be doing intensive I/O from both Maemo and ED), and even if, it still doesn't affect SWAP, which sit on microSD (another medium).

As for repartitioning eMMC, there is wiki article about it - basically, it's bets to install backupmenu or backupmenu-multiboot (if You don't have it yet...), then connect N900 in backupmenu's mass-storage mode (read&write) to linuxbox - it may be any system run with linux liveCD. Then, You change partition layout using GUI tools.

Recommended size for Squeeze-based Ed is as least 3GB. It should be sufficient, but if You plan to install plentora of huge things (on top of already installed LibreOffice, GIMP etc), You may think about 4GB. I'm using 3GB and I'm still using only 1,8 GB ;)
---

When You have free partition ready, installation would be as simple as untar'ing one (big) file, and modifying small ED script.

/Estel

Re: Easy Debian Fremantle Beta Testing
 

Guess what, it works :)

I would say "ready for prime time", but I've noticed strange, worrying issue. Many times (most), after tapping the screen, LXDE register it as "still clicked", despite fact, that stylus isn't touching screen anymore. Thus, it enables "right-click" when not asked for (cause long-press works like that).

It's not very easy to notice it at beginning, but there is easy way of testing it - open xvkbd, terminal, and try to write something, by taping on virtual keyboard. Tap any letter, then, without touching screen any more, wait for a while. In my case, letter auto-repeat, just because cursor is still "over" letter on vkb.

Sulu, could You check, if it also happens in Your case? Any way, ideas what may be causing this, anyone?

Of course, I've tried restarting LXDE, closing ED image etc, to no avail. I don't remember facing this issue before - it *might* have appeared, after installing patched server xephyr. Yet, don't quote me on it, as it's quite hard to notice. Most of the times, you think that long-press menu appeared by accident, and while I was irritated by it few times today, I acknowledged bug only, when, accidentally, deleted top panel and canceled "this dialog is needed to gain keyboard focus in LXDE", so I was forced to use terminal and xvkbd to properly shutdown LXDE. Writing on virtual keyboard clearly indicated bug, by auto-repeating letters (they auto-repeat on moderate speed, when letter is keep pressed), that's why I suggested checking it this way.

On 2 devices that I've tested, it works flawlessly - 100% of times - by tapping every edge of the screen. 4 panels are 100% possible - it's just me, who use 2 panels and still have much free space on them - my invention on filling it with content seems small :p

/Estel

Re: Easy Debian Fremantle Beta Testing
 

I can't confirm this. Starting a terminal and clicking a letter in xvkbd doesn't produce any other letters afterwards.
I'm not sure what might cause this bug but it kind of reminds me of the ctrl button issue that I encountered after my dist-upgrade (see regressions list in ED wiki article). I didn't pay attention to it anymore but now that I checked it sems to be gone. No idea if it has to do with the xephyr backport.
However, can you please try if pressing ctrl stops writing further letters? Just to make sure it's not a coincidence if it works, please try Shift too.
It might also be interesting to know what xev says when this happens.

I can confirm that it works for me too.
But I noticed one minor problem: If there is an icon in the panel where the mouse cursor will be placed, that icon will be launched. So you'll have to take care to click only areas where no icons are in the panel.

Four panels might be overkill, but I think three could be useful:
The two long sides for an application launcher panel with big icons and a task bar panel. One of the short sides for status indicators like a clock or notification area.

Have you been able to test the iceweasel/chromium touchscreen addons yet?

Re: Easy Debian Fremantle Beta Testing
 

@Estel
So are we seeing your new ED img. soon?

Re: Easy Debian Fremantle Beta Testing
 

I've tested ctrl, shift, and blue arrow (also thought about it) - bug still exist.

Yet, thanks to Your suggestion with xev, I've noticed something, which makes this bug even more strange. Xev doesn't have anything to tell about it - just like it doesn't happen (register one click). Then, trying it again with xvkbd, it seems that I was wrong initially - it *isn't* long-press. Long press looks different - xvkbd key becomes "black" (virtually pushed down), and keys repeat quite fast.

In case of my bug, after initial press, xvkbd doesn't look pressed at all, and keys keep repeating at quite slow rate (I called it "moderate" in last post). It looks, like just having cursor over xvkbd key, makes it repeat.

On the other hand, if I *really* long-press some xvkbd key (making it repeat quickly), and then lift stylus (stop it, not touching screen anymore), keys are *not* repeating - of course, until I tap on other key. So, long press before, negates strange "repeating" presses.

I have no fckn clue about what is happening here...

BTW - on other parts that xvkbd, it isn't 100% reproducible - most times, tapping is recognized properly (as one click) - yet, when I try some clicks repeatedly (for example, switching between 4 available LXDE desktops), it start to appear as long-press (submenu appear 0.5 second or so after tap).

Trying the same on xvkbd, I can *never* make it to register "real" long-press wrongly (i.e, key *never* look like pressed - black, pushed down, etc) - of course, unless i long-press it really.

Very strange, but, overall, for other scenarios that using xvkbd, it isn't entirely critical, so I'm going to publish my image - I wonder what other people reports will be. Still, any clues *highly* appreciated.

So, I'm using Scrollbars Anywhere (Chromium) from the very beginning, and it's working great. As for Iceweasel, I haven't tested it - I'm not using it any longer.

Re: Easy Debian Fremantle Beta Testing
 

HOLY SH*T!

Quote from Easy Debian wiki:
*facepalm* Ok, this was "oh sh*t!" moment, after trying to hammer this "bug" for few hours. No idea why it turned on, and I came across wiki mentioning it by pure accident (luck).

So, latest known bug was hammered, I'm creating image and uploading it...

BTW, sulu, do You know any way to enable clipboard sharing between Maemo and ED? It' really PITA, not being able to ctrl +c on ED and paste on Maemo, or the opposite.

/Estel

// Edit

After some practice, it becomes natural to bring panel without clicking icon, even if it's just under the cursor - matter of lifting stylus on the correct moment :p

Re: Easy Debian Fremantle Beta Testing
 

Hi Estel, I'm not at home right now, but when you get your image ready (please localize for US and include any /home/user files) post it and I'll upload it to qole.org and add it to the installer. If it works for others, I'll put it at the top of the list.

I think it would be a great idea to start a new thread around Estel's image.

Re: Easy Debian Fremantle Beta Testing
 

Thanks, qole! I localized it to US, packed image with lzma and uploaded, but (as I did it before reading Your post) I'm not sure about the (non-image inclusive) files from '/home/user/'. Only two relevant things that I've found are .chroot and .xbindkeysrc - both are highly modified to my liking (.chroot pointing out to dedicated ext4 partition and with temp size changed from 6MB to 30MB; .xbindkeysrc without TAB and ESC, as I've them binded via Maemo's RX-51). Should I add "vanilla" copies of these to image and repack it? Or have I missed something, and You're talking about other files?
---

Anyway, for adventurous ones, here it is:
http://lorienart.pl/cover/ed-squeeze-final.ext3.lzma

BIG FAT WARNING! Despite filename, it may not be "final" yet - minor things like (mentioned in this post) files from Maemo's /home/user/ may be missing. No big deal for advanced ED users, but everyone else - please wait for possible final "polishing" in line with qole's advices
---

qole, or sulu - if any of You recall out-of-image files, that I possibly missed, and/or test this image and find lacking things, I'll gladly fix it, re-pack and reupload image. Of course, if anyone is willing to fix it her/himself and repack/reupload instead of me, it's perfectly fine.

/Estel

Re: Easy Debian Fremantle Beta Testing
 

I certainly can't keep up with all the wonderful developements on this thread. Special thanks to Estel, Maartenmk, and Sulu. Couple of questions:

1)In regards to dedicated partition: I just partitioned my mircoSD to have ext3,ext4 and the rest fat32 using a live gparted I happened to have discovered on a linux demo disc I had. First time I ever did anything like this so I was quite pleased until I read Estel's recommendation that it is better to make a dedicated partition on eMMC and create swap space on microSD. So could anyone comment on the improved performance, in a quantitative way, if one goes this route. For example, maartenmk got nearly a factor of two improvement when using dedicated partition on SDcard (see post 2324). Can I expect much better improvement having dedicated partition on eMMC. It would be nice to have similar benchmarks for eMMc case. Anyways, if I followed Estels suggestion, I'd have to do some major house cleaning so I'm reluctant at this point. But significant performance improvement will persuade me to try sooner rather than later...

2)In regards to how Estel's image is packaged with extra files and so forth, I would suggest that all this be done such that it as consistent with current form of Easy Debian. It might help to merge some of Estels changes in chroot and .xbindkeysrc but perhaps, if possible, keep them as comments that ppl can incorporate as desired. For example not everyone will have ext4 (either on eMMC or microSD). Anyways, just a suggestion, Perhaps doing things this way is taking too many steps backwards... Maybe what I need is Easy Estel!

3)Getting back to partitions, When using the Synaptic Pkg Mg, that came with Easy Debian, I happen to notice, in the Debian repositories, the presence of gparted! Has anyone actutally tried this on the N900? I downloaded it and noticed that it needs a superuser password to use but that is circumvented by using the sudo command. It would be interesting if, using ED on microSD that you could treat it as a live gparted to repartition the N900 or if ED is on eMMC that you could repartition a microSD. I will certainly give the latter a try tonight.

Re: Easy Debian Fremantle Beta Testing
 

I have successfully installed Gparted, working fine on a standard ED image after enabling squeeze repo and forcing update using apt-get, also installed dosfstools to enable fat/fat32. Added a link to the Maemo menu to call it directly.

Re: Easy Debian Fremantle Beta Testing
 

Mscion, while my measurements were accurate, I believe I did not have swap on SD yet. If you do, your ED running from an image on eMMC could well be already faster than what I started with, and therefore you may not see as big a difference.
After switching my swap to SD I have not done any new benchmarks, but I am almost sure ED became slower, for the reason Estel explained.
Moving ED to eMMC should solve that, so I am guessing you will see similar or slightly better performance to what I had when doing the measurements.
I just reflashed, and I don't have ED re-installed yet (I was waiting for news on Estel's image), so I can't check atm.
But I do intend to install it again, and since these measurements are pretty much the only useful thing I have to contribute, I will try to do some new ones.

Re: Easy Debian Fremantle Beta Testing
 

I can confirm it works! Repartioning my microSD was real easy using the debian Gparted on N900. I remember being so impressed that I could compile and run c and fortran codes using Easy Debian on N900. Now this! Awesome!

Question:

If you use easy Debian from the microSD can you then run Gparted to repartion eMMC? My guess is that it is much more complicated than I think but could someone chime in and explain why... Thanks!

Re: Easy Debian Fremantle Beta Testing
 

Why not?

# gparted /dev/mmcblk0

(assuming that your /dev/* is copied/bind-mounted on ED).

Re: Easy Debian Fremantle Beta Testing
 

Re: Easy Debian Fremantle Beta Testing
 

While moving from ED-on-SD to swap-on-sd:ED-on-EMMC, as a rule of thumb, I would not expect *as much* improvement in performance, as with moving from image file to dedicated partition. Yet, if You're still using swap on eMMC, by moving it to microSD You're going to feel overall increase in performance for *whole* device, so it's definitely worth the effort. Especially, if You'll also add to this customization of few swap related settings.

In Your situation, as a quick&dirty improvement, I would just "cut" 768 MB from microSd fat32, and create swap there (so, use both Ed and swap on microSD). When time permits, and You'll be able to "clean" some thing on eMMC, You can always "kick" Your dedicated partition into eMMC.

:o Thanks, but it wouldn't be possible without sulu messing with dist-upgrade and it complications (I could not fix pulseaudio etc issues in thousand of years...) and of course, qole bringing us ED and easy chroot as whole, on first place.

Anyway, no worries. Image that I've uploaded is (well, at least *should*) be independent of any "personal" tweaks in .chroot and .xbindkeysrc. Also, image was mkfs'ed as ext3, so it can be used by people without kernel-power as well, while still regaining possibility to mount is as ext4 - yet, keep in mind, that some 'special' ext4 benefits aren't available when doing so, see wikipedia article about ext filesystem. I concluded, that people using ext4 will be (most likely) sitting on dedicated partition anyway, so they can copy content of image file to any filesystem they feel fancy.

Nice catch. Well, I'm pretty sure that it wont work if You want to repartition Ed partition from it ;) but I'm sure You know it already. I would also not risk repartitioning that include /home + opt (/dev/mmcblk0p2) - remember, we're still in chroot, so AIUI, it would be almost like repartitioning ED from within ED.

On the other hand, I don't see much reason, why we shouldn't be able to cut&slize /dev/mmcblk0p1 (MyDocs), or MicroSD as a whole. Just be sure, that it doesn't involve moving/resizing mentioned /home/ + opt. Also, be sure to disable swap on microSD, before messing with SD.

Repartitioning with GUI independant from other device would be great, but for full solution, we would need some thing like u-boot loading kernel from microSD + ArchLinux from microSD. Doable, yet I think no one tried this up to date.

/Estel

// Edit

As You all have probably noticed, the file I uploaded is image packed as .lzma - just like any other ED image files. You need to unpack it first (can be done via tar -xf --lzma <file>) - warning, on device, it's prone to same things, that haunted images provided by qole, i.e. device can get unresponsive during unpacking. In my case - using swap on microSD and tweaked settings, there is no such problem - it unpacks gracefully, and device is 100% responsive during unpacking (yet, unpacking takes 100% of CPU, so other programs aren't blazing fast), but in other setup's it may be better to first unpack it on other machine. AFAIK, it's safe to do so under any OS - may be even windoze + 7zip (unpacked image file won't suffer due to windows filesystems not handling permissions - for the same reasons, image file can be held on MyDocs).

While unpacking on device - no matter of setup - it may be good to do it with nice command, so (for example) 'nice 19 tar -xf --lzma ed-squeeze-final.ext3.lzma' - of course, if You already cd'ed to directory, where You want to see unpacked image.
---

After un-lzma'ing, image can be used directly with ED (just remember, to change 'ext2' to 'ext3' in /home/user/.chroot). It's content can be also moved to dedicated partition - to do so, just trivially mount image somewhere ('mount -o loop <imagefile> <mounpoint>), and 'cp -a' it's content to desired place (dedicated partition). Then, modify /home/user/.chroot, to make it point to Your dedicated partition, instead of image file.
---

When qole will review my questions about files from /home/user/, and image will be confirmed to working fine for few brave folks testing it, I'll land on ED installation, as "first" choice. I've also prepared .desktop files for Maemo (to easy launch LibreOffice or Chromium), so maybe I'll be also time for small update of package - if not, .desktop files can be also downloaded separately.

Re: Easy Debian Fremantle Beta Testing
 

Hello Estel, thanks a lot for making your ED image available and all the work you did. Same goes out to qole and the other ED contributors.

I fail at extracting the lzma archive directly on the n900 through lzma. I think it's not a problem related to your image, but I thought I'd post it here.

When trying to extract the archive the following error shows up: lzma: SetDecoderProperties() error.
The command "xzf" forces tar to use gzip, but it should work with "xf". Lzma seems to be broken or wrong configured on my n900.
Though it works with p7zip to extract the archive after renaming to .7z.

I'm running CSSU kernel-power49 and have testing and devel repositorys activated.

Re: Easy Debian Fremantle Beta Testing
 

a tip for people who aren't so technically inclined with linux (i am one of them :)).

download the file manually, copy it to a laptop and extract it there. it is soooooooooo much faster. then copy it back and edit the easy debian config (/home/user/.chroot) file and you're done in a jiffy.

Re: Easy Debian Fremantle Beta Testing
 

@eight
Thanks for pointing that out, of course my tar noobines was showing - I've corrected command to not include -z. I wonder why You have this error at all - image was created via aptosid's tar, so maybe it's some version mismatch. If that is the case, I'm probably doomed to PITA lzma'ing on device. Which will probably take a two days or so ;)

In any case, I'm glad that You've found a way to decompress it on device.

By the way - I've used --lzma, as it creates ~450 MB image, vs 650 MB image of gzip - yet, the latter is *much*, much faster, for both compressing, and decompressing, especially on device. What do You think people - it's the 1/3 size save worth the effort?

@Everyone who tested it already - does it work for You as it should? Also, remember, that if You do not like "hiding" panels (again, the easiest way to pop-up them, is to tap (a little harder than usual) just *outside* the screen, at corresponding edge - it's just like having more hardware buttons on N900 ;) ), this feature can be disabled via right-click (or long-press) on panel, then, in last tab, unchecking "hide panel". Their sizes can be also easily adjusted - I use relatively big panels, as they're hiding when unneeded anyway, and big ones are easy to click, even with fingers. Yet, everything is customizable.

/Estel

Re: Easy Debian Fremantle Beta Testing
 

I get the error:

my old ED image runs normal. I unzip it with 7zip on w7.

Re: Easy Debian Fremantle Beta Testing
 

You're trying to mount it via /home/user/.chroot, or via hand? If first option is true, have You modified .chroot to mount as ext3, not ext2? If both true, Could You post here Your .chroot file?

Anyone else having this problem?

/Estel

Re: Easy Debian Fremantle Beta Testing
 

I have exactly the same problem, mounting by hand also failed. Here's my .chroot

Re: Easy Debian Fremantle Beta Testing
 

Got stuck at the same point.

And I did some research on the lzma error. Tested a lzma archive from qole.org which extracts without the error.



Edit:
Well, this reboot problem below was caused by setting smartrefex (vdd1 sr) enabled in qcpufreq.
Disabled VDD1 and now works well, even overclocked.



*-----------------------------------------------------------------------------------------------------------------------------------------------------*

But then the N900 reboots after a few seconds till minutes after starting lzma extraction.
If this happens /dev/mmcblk0p1 (MyDocs) gets read-only. Mount looks normal but dmesg shows it and you'll get an error like this:.

If this happens at your N900 you can fix it this way:
- umount /dev/mmcblk0p1
- fsck and repair /dev/mmcblk0p1
- remount it to MyDocs

This reboot even happens with nice -n 19 [command]. First I thought it could be due to overclocking, but happens also at 600 Mhz.

Re: Easy Debian Fremantle Beta Testing
 

It seems, that archive get somehow corrupted during upload - my local copy works, but when I downloaded it, I'm also unable to unpack. Doing so like eight described result in false-positive unpacking, but image is unmountable.

Sorry for inconvenience - will upload again, yet, this time, I'm going to download it myself and check, before dropping link here ;)

/Estel

Re: Easy Debian Fremantle Beta Testing
 

I repeated the tests I did in posts 2324&2329 (opening a file in OOCalc directly from Maemo, editing a minimal amount, and closing OOCalc again), now concentrating on the locations of both swap & ED partitions. The setup is as similar as possible, but can't be fully compared of course.
Each test was run 3 times. The numbers behind each line are the times in seconds:

- Swap on emmc, ED on sd: 95,105,90
- swap on emmc, ED on emmc: 95,75,75
- swap on sd, ED on sd:95,80,75
- swap on sd, ED on emmc: 80,70,65

I then overclocked to 900mhz, and ran the last test twice more:80,60

So as expected 'swap on sd & ED on emmc' is the fastest, and overclocking helps, but not a lot.
I can't really explain the second place for both on emmc though. I am also surprised about the bad performance of the first setup. But the conclusion is clear enough for me.

When Estel's image is back up, I can try the same sequence again, so we will have some idea on the performance of Libre-office.

Re: Easy Debian Fremantle Beta Testing
 

I got pissed a little by incompatibilities between aptosid tar --lzma and Maemo tar --lzma implementations, so I decided to do everything on device. I'm already during cp -a everything to image file. Then, I'm going to --lzma it, so it will probably take a week or so :P (seriously though, I expect it to be finished tomorrow). After that, I'll upload it again, then download, unpack, and test. If correct, will drop info here.

/Estel