Re: Easy Debian Fremantle Beta Testing
 

Is /sbin in PATH?

Re: Easy Debian Fremantle Beta Testing
 

The link did it. Thanks a lot!
I guess I'll do a proper recompile some time in the future anyways.

Yes, it is.

Re: Easy Debian Fremantle Beta Testing
 

Armel version also doesn't have GIMP problems? I wonder, what causes them in our "old" image, then. Also, it would be interesting to see if gparted and chromium problems are manifesting themselves, but I understand, that you wanted to have working keyboard, first :D

Keep up that good work - again, things that you're trying now are (currently) far above my knowledge level, so if anyone reincarnate fully working ED, it would be you.

/Estel

Re: Easy Debian Fremantle Beta Testing
 

Sorry, my formulation was very ambiguous.
In my new armel image gimp crashes too. It's only armhf where it works fine.

gparted crashes in armhf too and chromium isn't even present in the non-x86 Debian repos anymore (my last attempt to compile it anyway failed due to missing make targets with which I didn't bother any more).
Not sure if that's an option for you but I found midori to be pretty useful in ED. xxxterm might also be worth a try, but I have no idea if that browser has a bright future in Debian (the project was renamed to xombrero ages ago but in Debian is still an outdated xxxterm version).

Thanks, I'll try. :)

If "fully working" for you means you want gparted then I think I'll have to disappoint you. I don't even know where to begin debugging.
But I intend to release a basic Wheezy/armhf image in the near future (pretty similar to my old Wheezy/armel image - but hopefully with fewer stupid bugs) that others can use to create more "end-user-friendly" images.
It always bothered me that I didn't actually understand the inner workings of qole-based images (all we have so far) and since I'd have to start over from scratch for an armhf transition anyway I thought this might be a good opportunity to dig deeper.

Oh, btw:
A good portion of that dissatifaction was due to (in my eyes) missing or hard-to-find documentation on how to create images from scratch.
So once I have an image up I intend to change that situation by putting all the necessary info into the wiki. Please feel free to needle me until everything is clear! Should I disappear (again), others should be able to continue right where I have stopped.

Re: Easy Debian Fremantle Beta Testing
 

By "fully working" I mean "without things that doesn't work for reasons that we can't pinpoint", like that glib things gparted complains about (remember, it's not about gparted version - so it may be sign of more serious problems with library in question, that can manifest itself in other cases. Although, it haven't done so yet, which buggs me...). Things like chromium or GIMP - which are, (now) clearly bugs in their code/build process, are of lesser importance, as effects are surely limited to those programs.

I think that your work to understand inner working of those images + documenting their creation from scratch is exactly thing that contributes to understanding possible problems, too. Kudos for your work, again :)

/Estel

Re: Easy Debian Fremantle Beta Testing
 

To be honest, I feel somewhat baffled by that. ARM is the future about as much as x86 is, if not more, and anyone silly enough to bury a popular package on that platform just because it does not build rather than getting their acts together and fixing it is IMO digging their own grave. That does not give me much confidence in the future of Debian as such.

Re: Easy Debian Fremantle Beta Testing
 

Just to get that straight, gparted doesn't crash on armel/hf in general. It works fine on my Cubieboard2 (armhf) and it worked fine in my qemu-arm installation (armel).
It only crashes in ED, no matter if armel or armhf.

For reference:
This is the error message which appears right after the GUI comes up, tries to scan available devices and crashes:strace doesn't reveal any further useful info (at least to my understanding) and google doesn't return any results.
As I said, I have no idea how to debug that, but then again I'm a very poor programmer (as in writing C(++) code). So if somebody else has any pointers (pun intended) I'd be happy to assist in tracking the problem down as good as I can.

Debian is around for more than 20 years now and it's the base for the vast majority of the distributions out there.
To my understanding, if Debian gets to the point where its future becomes questionable the whole FLOSS ecosystem is in big trouble.

Re: Easy Debian Fremantle Beta Testing
 

[edit: Well, that was tricky! ;) But I have the solution. More at the end of this post. ]

On a more serious note, I think I may be at the point of uploading an image, except for audio.
In general I try to avoid pulseaudio wherever I can. Here I can't and I don't know how to proceed.

steps in detail:

1. I recompiled pulseaudio with this patch [1] to account for Maemo's ancient PA version. (I did that for armel as well and the resulting packages work fine in my working armel image.)

2. I installed the following recompiled packages in my armhf image:3. To have the same starting point as in my working armel image I also installed these packages from the Debian repo (although I believe they aren't necessary at that point):4. I copied /etc/asound.conf from the armel image to the armhf image. It looks like this:5. dus (and dbus-x11) were already installed in the armhf image and as far as I can tell they work fine. roxterm doesn't complain about missing dbus and ps shows this output:6. According to [2] these mounts from the host system have to be present in the chroot:#1 and #4 were already there because ED mounts them by default.
#2 was not mounted in my case but it was an identical copy of the host system's directory which works fine in my armel image. Mounting it from the host system didn't change anything.
#3 was a tmpfs mount in the image, which also works fine in the armel image. Mounting it from the host didn't get pA working.

7. Mentioned in [2], and stressed in [3] one has to make sure that the machine_id is the same in the chroot as on the host. Since /var/lib/dbus is a bind-mount this is the case:The problem is, when I try to play an audio file from within the chroot via mplayer or moc I get this error:The problem seems to be that the PA in the chroot can't connect to the one on the host (possibly due to some dbus-related issue?).
This is what I get when I manually start PA as user in the chroot:This is as root:The first one says something about module-udev-detect, the second about module-console-kit. consolekit, udev and libudev0 are installed in the chroot.
What puzzles me is this line, as, according to Google, it usually seems to indicate a machine_id mismatch, which I've already ruled out (see step 7):
edit/solution:
In a default Debian installation /var/run is a symlink to /run. But in ED /var/run needs to be a real directory because /run will be empty at the beginning, which means /var/run/dbus and /var/run/pulse will be missing.
On the other hand we can't simply make both of them real directories since we need Maemo's contents of these directories at the beginning.
So the solution is to reverse the order. Make /var/run a real directory and /run a symlink to /var/run.



[1] http://talk.maemo.org/showpost.php?p...6&postcount=34
[2] http://www.freedesktop.org/wiki/Soft...FAQ/#index36h3
[3] http://blog.einval.com/2010/11/12

Re: Easy Debian Fremantle Beta Testing
 

Great work! Some ideas:

1. I suppose both Cubieboard2 and your pc with qemu-arm installation have newer kernels than 2.6.28? The reason I'm asking is I've seen in my past glibc crashes when specific combination of glibc version and kernel version, and quick googling returned some other case where a person with kernel 2.6.28 had "...gpartedbin: free(): invalid pointer..." error [1]. Are you able to install second kernel on your pc, preferably 2.6.28? Googling told me Cubieboard2 supports 3.something (3.4?) kernels only, so I guess downgrading that one is not possible.

2. Again very remote guess, but could you try running gparted from console with "LD_PRELOAD=/path/to/libstdc++.so" ? This is based again on some googling results, mostly one explanation of possible cause of "...free(): invalid pointer..." issues when some of the libraries are compiled with incorrect flags [2] and related ubuntu bug [3]. Maybe comparing "ldd /usr/sbin/gpartedbin" from Cubieboard2, from qemu-armel environment on pc and from n900 in both armel and armhf image would also show something suspicious or give any clues (it would be nice if you could also post them here for reference).

edit: 3. Posting strace would be nice, too (maybe it will provide some suspiciously looking data for some other community member, without the need to run the ED and gparted).

[1] http://ubuntuforums.org/archive/inde...t-1211516.html
[2] https://www.libavg.de/site/projects/...nvalid-pointer
[3] https://bugs.launchpad.net/ubuntu/+s...sa/+bug/259219

Re: Easy Debian Fremantle Beta Testing
 

Correct.
My CB2 runs a custom 3.4.67+ made by the Cubian folks, my PC runs the 3.2.51 Debian kernel.

I can try to do so in a VM. I remember having done something like that in the past with some troubles due to the age of the kernel, but I can't remember what exactly was the problem.
On the other hand my experience (with x86, arm and ppc) is, that when you get that close to the hardware level you can't simply abstract from one architecture to another. So I'm sceptic if x86-experiments are useful for arm.

Quite frankly, installing custom kernels on the CB2 is above my skills since it involves a lot of special tricks.
Kernels always have "just worked" for me. I've tried some occasional recompiles just for fun but I'm far away from actually being able to do any troubleshooting.

Here it is (wheezy/armhf image on the N900):strace outputs are attached.

edit:
At first I had outputs that contained Locale warnings and therefore might be misleading (pointer address changes etc.). I've reuploaded outputs without these problems.
/edit

You'll find outputs for the armel image, armhf image, CB2 and my PC (amd64) in the attached tar.gz archive.
My qemu machine doesn't exist anymore since I have the CB2.

Thanks for all the tips!

Re: Easy Debian Fremantle Beta Testing
 

That's what I thought - I suspect older kernel wouldn't even boot, as it requires some patches done by project Cubian.

Yeah, that's what I think, too, so I guess that's not needed.

Here it is (wheezy/armhf image on the N900):strace outputs are attached.[/QUOTE]

Thanks for all the updates, I don't see anything obvious in them either. What does the "file /usr/sbin/gpartedbin" say (could you post the output)? Maybe it doesn't support our kernel [1], which would be a suprise, but worth checking. On my virtual machine with a bit old Debian installation the minimal supported kernel for gparted is "2.6.26" which is quite close to N900's version...

By the way, while looking for glibc, libstdc++ and kernel combination bugs, I found interesting info - Maemo's default gcc's (4.2.1) libstdc++ (6.0.9) which is present on N900s has one known binary incomatibility with all older and newer versions - see [2] and relevant gcc bug report [3]. It's marked as fixed - I wonder if "our" 6.0.9 and gcc have this fix included by some patch or all "our" binaries are abi-incompatible with all other gcc/libstdc++ version :) That would make me a sad panda.

Edit: I also wonder what "--enable-kernel=2.X.Y" was passed when glibc was being compiled. Anyone know how to check that, so Sulu could do that?

Edit2: I found out that GNU C Library 2.17 is compatible with kernels 2.6.16 upwards [4] while GNU C Library 2.18 doesn't even state that info in annoucement [5]...

[1] http://stackoverflow.com/questions/6...active#tab-top
[2] http://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html search for "GCC 4.2.1: libstdc++.so.6.0.9" and read further note
[3] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678
[4] https://sourceware.org/ml/libc-annou.../msg00001.html
[5] https://sourceware.org/ml/libc-alpha.../msg00160.html

Re: Easy Debian Fremantle Beta Testing
 

from the armhf image:Sorry, I lack the concentration right now to do any actual thinking. I'll get back to your post later.

Re: Easy Debian Fremantle Beta Testing
 

Here's the first attempt of a Wheezy/armhf image:
http://netload.in/dateiKJ3z5OMsGg/ea..._armhf.tar.htm

Besides the image itself the archive also includes all of my recompiled pulseaudio packages (most of them should never be necessary) and afaik all the custom binaries and scripts that are still present in qole-based Easy Debian images.

edit:
the user's pasword (for sudo) is: user
the root password (for su) is: root

Here's a preliminary draft of a how-to to reproduce how I've created this image:
[1] http://debgen.simplylinux.ch/
[2] http://linux.koolsolutions.com/2009/...-debian-linux/
[3] http://talk.maemo.org/showpost.php?p...6&postcount=34
[4] http://www.thomas-krenn.com/de/wiki/...d_unter_Debian
[5] http://talk.maemo.org/showpost.php?p...4&postcount=23
[6] http://talk.maemo.org/showpost.php?p=425218&postcount=7
[7] http://talk.maemo.org/showpost.php?p...postcount=3040

Re: Easy Debian Fremantle Beta Testing
 

misiak, could you forward those findings to CSSU guys, and/or guy working on glibc updates for maemo (Aapo, IIRC)? I think it may be interesting outside ED, too.

Nice research, BTW!

/Estel

Re: Easy Debian Fremantle Beta Testing
 

I'm not sure, but I guess one of these kernel version numbers I've encountered during my Jessie tests in the Debian package source configuration [1] should take care of that:I think I remember that in the Wheezy source I haven't seen any check above 2.6.26 but my memory might be wrong and I was probably not as thorough as I was for Jessie.
I'll check that again when I have the time.

That reminds me of what I've read in the Debian changelogs. [2]


[1] http://talk.maemo.org/showpost.php?p...postcount=3030
[2] http://ftp-master.metadata.debian.or...7-97_changelog

Re: Easy Debian Fremantle Beta Testing
 

Here's a summary of kernel version mentions in Debian's eglibc source package [1]:

A full egrep output is attached.
This is what remains if all kernel versions <=2.6.28 and all lines explicitely only valid for other architectures are eliminated:And short contextual excerpts:

ChangeLog.17ports/sysdeps/unix/sysv/linux/arm/kernel-features.hdebian/debhelper.in/libc.preinstports/ChangeLog.armsysdeps/unix/sysv/linux/kernel-features.hsysdeps/unix/sysv/linux/sys/timex.h has only the comment from the egrep output and the rest of the code seems either totally irrelevant or totally relevant to me, so I'll attach the whole file.

Maybe someone can gather any insight from this.


[1] http://packages.debian.org/source/wheezy/eglibc

Re: Easy Debian Fremantle Beta Testing
 

And what is the maximal version the Fremantle kernel could be (theoretically upgraded)?

Re: Easy Debian Fremantle Beta Testing
 

As far a I understand you can't go beyond 2.6.28 (which is why KP still is 2.6.28, although heavily tweaked) because some of the non-free components (drivers, probably apps) would cease to work.

The Linux kernel infrastructure (modules) is highly version dependent. Have a look at /lib/modules and you'll see that there is a directory for every kernel!
Linux experiences frequent ABI changes, which means to be on the safe side you'll have to recompile all your kernel modules for every new minor revision (3rd number in 2.x kernels).
For that of course you need the code of these modules. Unfortunately we don't have this code for all the modules in the Maemo kernel, which means we can't move on.

This is why it's so important for the Neo900 to be as free (libre) as possible and identifying (easy) and replacing (hard?) non-free components is an important task for FPTF. In fact being able to use a newer kernel (3.x) is one of their main goals.

Re: Easy Debian Fremantle Beta Testing
 

Hmm... And did anyone try whether 2.6.32 works? I know that type of situation from the meecolay development. Everybody said - it won't work soft vs hard float but some of the apps worked even though. Maybe the ABI changes are not so big... :)

Or maybe it would be possible to use an analogical approach as with LD_PRELOAD?

But, we're not m68k, so we don't need the newer kernel, do we?

Re: Easy Debian Fremantle Beta Testing
 

306 pages is bloody long and the first page hasn't been updated for ages, so I'll ask a (stupid) newbie question.

I want to use EasyDebian when my N900 is working as a desktop (i.e. with external keyboard, mouse, TV as a monitor, ntfs hdd for additional storage). The main goal is to use OpenOffice, but it would also be nice to use IceWeasel or something else for browsing. The device will most likely be overclocked to 900MHz during that kind of operation.

Which image should I download from http://qole.org/files/ to suit my needs best? Any recommendations on Easy-Debian package version itself?

Re: Easy Debian Fremantle Beta Testing
 

Estel's!

http://talk.maemo.org/showthread.php...22#post1401322
http://talk.maemo.org/showthread.php...42#post1355842

Re: Easy Debian Fremantle Beta Testing
 

It really depends on what you're doing.

Estel's image is the most "rounded" one when it comes to beginner friendlyness due to the software it already includes, but all the images at qole.org suffer from being heavily outdated.
For example iceweasel in squeeze hasn't received any updates since december 2012 (the backports have version 10.0.12 but that's not really better). I haven't checked the implications of that, but I wouldn't use iceweasel from squeeze for online banking or any other stuff that requires me to login somewhere.

I tried to adress this by uploading a minimal wheezy-based image some posts ago [2], but as I've seen just now the link is dead.
I will upload an updated before easter, maybe this evening (CEST), maybe tomorrow.*
I also included instructions that are hopefully detailed enough to reproduce my work. So if you have any decent armel/hf machine (> Raspberry PI; in which case you'll likely have some slightly advanced knowledge about debian) you could build your own image as well.


*) I'd appreciate hint's on any sharehosters that don't essentially require me to add an nsfw warning to my link due to their advertising.
Otherwise I'm considering on signing up at linuxtracker.org, in which case you'd have to bear with my quite stable but slow connection.

[1] http://metadata.ftp-master.debian.or...6-20_changelog
[2] http://talk.maemo.org/showthread.php...&page=306#3053

Re: Easy Debian Fremantle Beta Testing
 

I've just uploaded an updated version of my minimal Wheezy/armhf image. [1]
The md5sums are as follows:Apart from updating the packages there is no change compared to the previous one, so there's no need for you to switch if you've keept the last one up to date.
And as always: If you feel like mirroring this image on your own webspace, feel free to do that! In fact I'd be grateful.

@FlashInTheNight86:
In case you use kernel power [2] (required for armhf) you can use this image, install iceweasel and libreoffice on your own and you should be ready to go.


[1] http://freakshare.com/files/m8yq5o6h....img.lzma.html
[2] http://wiki.maemo.org/Kernel_Power

Re: Easy Debian Fremantle Beta Testing
 

Great image clean fast and not bloated with alot of stuff thanks

Re: Easy Debian Fremantle Beta Testing
 

i dont know if i am doing something but when i try to install iceweasel or synaptic i get this error

[\u@chroot: \w]apt-get install iceweasel
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libevent-2.0-5 libhunspell-1.3-0 libmozjs24d
xulrunner-24.0
Suggested packages:
fonts-stix otf-stix fonts-oflb-asana-math fonts-mathjax
mozplugger libgnomeui-0 libcanberra0
Recommended packages:
hunspell-en-us hunspell-dictionary myspell-dictionary
The following NEW packages will be installed:
iceweasel libevent-2.0-5 libhunspell-1.3-0 libmozjs24d
xulrunner-24.0
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/20.7 MB of archives.
After this operation, 41.6 MB of additional disk space will be used.
Do you want to continue [Y/n]? y
dpkg: unrecoverable fatal error, aborting:
syntax error: unknown group 'crontab' in statoverride file
E: Sub-process /usr/bin/dpkg returned an error code (2)
[\u@chroot: \w]

Re: Easy Debian Fremantle Beta Testing
 

I can't reproduce this, but your prompt looks funny.

Can you give more details please?
Where does your shell come from? Is it from within LXDE or via debbie?
Also I'd like to see the output of mount from Maemo.
May your image be corrupted?

Edit:
Was this your first attempt to install something in this image?

Re: Easy Debian Fremantle Beta Testing
 

I've had something like that once. With trepidation, I removed the offending entry from the file, tried again and it worked. Can't say I'd recommend it though since I didn't really know what I was doing.

Re: Easy Debian Fremantle Beta Testing
 

I don't have my N900 at hand now, but iirc there's a group 'cron' or 'crontab' with the gid 102 in the image's /etc/group.
It doesn't cause any problems for me, but it might still be a bad idea to have it there. If removing this entry solves your problem, please let me know and I'll upload another image with the group removed.

As for your prompt, I believe the problem might be that Easy Debian by default bind-mounts Maemo's /home/user into the image. I consider this to be a bad idea since it messes Maemo's home up with stuff that doesn't belong there.
Therefore I've disabled this bind-mount long time ago and I honestly can't say what happens if it's still there.
I'll give it a try though and see if I can fix it.

Re: Easy Debian Fremantle Beta Testing
 

mayhem, groupadd crontab will fix it

Re: Easy Debian Fremantle Beta Testing
 

if you can please upload it on uppit.

Re: Easy Debian Fremantle Beta Testing
 

there was no /etc/groups file in this image so this fix it thanks!

Re: Easy Debian Fremantle Beta Testing
 

sulu, I'll try your latest image then...

As far as I understand, you recommend LibreOffice over OpenOffice. Is it faster or any otherwise better?

Re: Easy Debian Fremantle Beta Testing
 

I tried. But on my first two attempts the upload stalled at about 40MB and when I finally succeeded the link generation failed.
So I assume the image is up there somewhere, but I don't have a link to present.

/etc/groups? - I guess that's a typo.
/etc/group is in the image:It's in the Debian repos, OpenOffice is not (anymore). Therefore you'd probably save a lot of trouble compared to finding an armel/hf version of OO or compiling it on your own.

Re: Easy Debian Fremantle Beta Testing
 

than why i had this error?i didn't install any software when i was trying and i tried both from chroot and lxde.

Re: Easy Debian Fremantle Beta Testing
 

I have no idea.

Edit:
I just tried on my secondary device, which apart from running CSSU thumb is almost naked (Easy Debian, rootsh, conky and the default Nokia stuff that came with it.)
Easy Debian is in it's vanilla shape, the only change is the image path that points to my image.
And I have no problems installing Iceweasel.

Re: Easy Debian Fremantle Beta Testing
 

Mirrored at http://debian.keithdunnett.net/~sulu...armhf.img.lzma, md5sum verified.

Hosted on my UK-based VPS - no CAPTCHAs, no adverts, wget and curl friendly if you want to download on your N900. Note that decompressing it on the N900 takes a good few minutes.

Re: Easy Debian Fremantle Beta Testing
 

I found a bug in my latest image:
It contains a file /etc/resolv.conf which will prevent you from establishing any network connection from within the image, unless you happen to use the same nameserver ip I do.

To fix this just delete the file from your image, or use the fixed image I uploaded [1]. The md5sums are as follows:This image also contains a file /etc/dhclient-enter-hooks with this content:According to [2] this should prevent /etc/resolv.conf from ever being written again and therefore might save trouble in the future.

@magick777:
Thanks a lot for mirroring the image! Could you host the new one instead please?


[1] http://freakshare.com/files/09z2uj21....img.lzma.html
[2] http://www.cyberciti.biz/faq/dhclien...olvconf-hooks/

Re: Easy Debian Fremantle Beta Testing
 

Latest image:

http://debian.keithdunnett.net/~sulu...armhf.img.lzma

Re: Easy Debian Fremantle Beta Testing
 

sulu, how you rate chances for any (upstream?) fixes re bugs that you've reported against things in wheezy? Frankly, I lost all hope for it (because it seems to only affect very specific cases, like our armel/armhf implementation), and it made me to revert back to Squeeze-only ED, despite possible security flaws in things you've described..

/Estel

Re: Easy Debian Fremantle Beta Testing
 

If not through sheer luck I'd say the chances are exactly zero.

Considering that chromium was removed from armel/hf after my bug report and that the gimp and gparted issues only seem to occur on the N900 I don't see us in a position to fix these bugs, since at least to me they don't seem to be Debian bugs but N900/Fremantle bugs.

I still have a little hope that some fundamental updates to Fremantle might happen if fremangordon succeeds in his attempt to update the kernel.
Otherwise I believe the future of ED might be in jeopardy alltogether since getting a jessie image to run won't be possible through a simple debootstrap but requires a patched glibc.
This means that it will become more likely for software in jessie to break.