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!