packages you want to see in raspbian

[asb]

I can understand why an Armel version might be useful, as explained by Plugwash (as a bug handling mechanism) but it creates incompatible versions of the software and division and further work. If the effort of the foundation is concentrated on Raspbian then amazing progress will inevitably be made and developers will know what to start writing against.

Effort is being spent on 1) packaging and 2) configuration and selection of packages on an SD card image. This is equally applicable to Raspbian. Trust me, I have absolutely no desire for community effort to be split.

Hi asb,

thank you for the clarification, I can understand completely that you don't want to create a split community and I think everyone would agree with you on that point.

Effort is being spent on 1) packaging and 2) configuration and selection of packages on an SD card image. This is equally applicable to Raspbian. Trust me, I have absolutely no desire for community effort to be split.

I think Raspbian will be at a point, very soon, where you will just as easily be able to produce a Hard Float and Armel version of Wheezy.

The benefit being that it should be relatively easy to test and compare. The packaging and selection of of applications should be equivalent in both releases as you suggested. And your effort in one should support the creation of the other.

This will give the foundation an excellent method to determine if Raspbian is the way to go for the default operating system selection for the Pi. I think there is an excellent opportunity for collaboration.

[asb]

I think Raspbian will be at a point, very soon, where you will just as easily be able to produce a Hard Float and Armel version of Wheezy.

The benefit being that it should be relatively easy to test and compare. The packaging and selection of of applications should be equivalent in both releases as you suggested. And your effort in one should support the creation of the other.

Yes, that is exactly the plan.

If you're talking about need to be build for Raspbian (rather than installed in a base image) then I REALLY could use:

yaml-cpp ( http://code.google.com/p/yaml-cpp/ )

It's like the ONLY remaining package I need to get ROS installed on Raspbian. I've tried building from source but I have no idea what I'm doing with CMake and it's giving me errors so I'm a tad lost.

[plugwash]

It doesn't seem to be in debian either

Could we bring in the squeeze chromium-browser source and build it? It really is the best all-round browser at the moment.

With Hexxeh's help I made changes to the Debian source package for chromium to hopefully build correctly for Raspbian. The updated source files are now in the build queue so hopefully it will emerge in a few days. chromium is one of those packages that takes days to build so if it still fails, it could take a while longer for it to appear. I'm crossing my fingers we nailed the parameters to get it to build on the first try.

Any news, did it build ok? or is it still going?

[mpthompson]

Any news, did it build ok? or is it still going?

Sorry about not posting an update. Unfortunately the build failed about 24 hours into the build with syntax errors in one of the files. If you care to review the error, the log file can be found here:

http://archive.raspbian.org/raspbian/lo ... rowser.log

Right now we're busy with trying to wrap up the build of the remaining few hundred Wheezy armhf packages. Investigating the failure of chromium to build will have to wait a while until we can free up some server resources once the remaining builds are complete.

Sorry about not posting an update. Unfortunately the build failed about 24 hours into the build with syntax errors in one of the files. If you care to review the error, the log file can be found here:

http://archive.raspbian.org/raspbian/lo ... rowser.log

Right now we're busy with trying to wrap up the build of the remaining few hundred Wheezy armhf packages. Investigating the failure of chromium to build will have to wait a while until we can free up some server resources once the remaining builds are complete.

well, i was bored so i had a look at it...
the error is:

Code: Select all

Unpacking libdbus-1-3:armhf (from .../libdbus-1-3_1.5.12-1_armhf.deb) ...
E: Sub-process /usr/bin/dpkg exited unexpectedly


so i tried to find a log for the libdbus, didn't see it in http://archive.raspbian.org/raspbian/logs/main/libd/ only logs for libdbusmenu-qt and libdbusmenu, but both of them also used the same version of libdbus... so it shouldn't be a problem with libdbus itself...
so maybe it's the package coming after libdbus thats throwing the problem (thats not in the log)? that should be libavahi-client3 if i interpret the log correctly... but no, libdbusmenu also uses that package successfully...

sorry, i'm a gentoo user myself and not used to debian install logs... is that all logs you have? or is there a more verbose log, detailing the reason for the exit of dpkg? (as you explicitly wrote "syntax error", where did you get that info?)

[mpthompson]

sorry, i'm a gentoo user myself and not used to debian install logs... is that all logs you have? or is there a more verbose log, detailing the reason for the exit of dpkg? (as you explicitly wrote "syntax error", where did you get that info?)

Oops, the original log has been replaced with a later one that where I aborted the build process in the middle of the install of dependent packages. I didn't want a build that I knew was going to fail to occupy one of our build servers for another 24 hours. Unfortunately, that log was swept up and replaced the log with the actual build failure.

Although you can't see it any longer, chromium isn't very verbose in what it outputs so the log is rather spartan. In such instances, you really have to do a local build of the package to understand what the failure may mean. With chromium, it's a 24 hour build just to get to the failure...

How about adapting xbmc on raspbian?
I'm curious about the hardware accelerated xbmc running mkv 1080p videos.

http://www.deb-multimedia.org/dists/uns ... ary-armhf/ don't know if these packages can be loaded? Will try today when I come home.

Greets,

Acid

In such instances, you really have to do a local build of the package to understand what the failure may mean.

ok, so i'll wait for my raspi to turn up and then maybe take a look again at it again...

[plugwash]

A Pi won't help you much , it simply doesn't have enough ram. Even the 1GB we have on our autobuilers isn't really enough leading to massive swapping.

A Pi won't help you much , it simply doesn't have enough ram. Even the 1GB we have on our autobuilers isn't really enough leading to massive swapping.

hehehe, ok, so since i don't want to replace my gentoo system and i am just too lazy right now to set up a debian/raspbian vm, i'll let it go for the time being *g*

I would love to get valgrind in Raspbian. Would help immensely in looking for places of optimization in programs I'm developing.

[mpthompson]

I would love to get valgrind in Raspbian. Would help immensely in looking for places of optimization in programs I'm developing.

Toad King, valgrind is building with armv7 contamination and won't run on the Raspberry Pi. I edited the Debian configuration file to change the -march=armv7-a to -march=armv6, but some of the modules still build as armv7. It's going to take more of a porting effort than I'm able to put into it at this time. I suspect the build process notices it's being built on an armv7 CPU and assumes it's safe to use armv7 instructions in some the code it assembles. When I get some time, I'll try building on a Raspberry Pi rather than my armv7 build system to see if I can shake the final bits of armv7 code from the build in case it is autodetecting the CPU its being built on.

If you are motivated, I would encourage you to check the source code out from our repository 'apt-get source valgrind' and try building it on your own. If you find the combination of config flags that get it to build, I'll incorporate those into the package so we can get it built and others can use it.

Hi, I've installed Raspbian for the first time this evening. It's working very nicely -- excellent job. It's nice to have some of the more recent Wheezy packages.

Is openjdk-7-jdk in your queue of packages still to be built? It's one of the few that I was using on the Debian Squeeze distribution that I haven't been able to find yet on Raspbian.

Cheers,
Chris

[mpthompson]

chrisg, I noticed that the openjdk-7 built with armv7 code in many of the modules and it would likely not run on the Raspberry Pi. Plugwash put the changes into openjdk-6 and I looked at what he did with that package, but where the armv7 code was appearing looked different between openjdk-6 and openjdk-7. This will have to go into the queue of things that we'll be looking at to get fixed.

chrisg, I noticed that the openjdk-7 built with armv7 code in many of the modules and it would likely not run on the Raspberry Pi.

Thanks. Although I haven't tried, I think it should be possible to make a build of openjdk-7 just supporting the Zero VM -- named because it has zero platform specific code. This will be slow, but no different to the openjdk-7 running on the Debian Squeeze distribution.

http://openjdk.java.net/projects/zero/

This may be a situation where by running the build on an armv7 machine, the build decides by default to bring in the armv7 optimisations. I'll put taking a closer look on my to do list.

[mpthompson]

This may be a situation where by running the build on an armv7 machine, the build decides by default to bring in the armv7 optimisations. I'll put taking a closer look on my to do list.

Thanks. Any guidance you could provide here would be great. The files that openjdk-7 installs that are armv7 dirty are the following:

/usr/lib/jvm/java-7-openjdk-armhf/jre/lib/arm/jamvm/libjvm.so
/usr/lib/debug/usr/lib/jvm/java-7-openjdk-armhf/jre/lib/arm/server/libjvm.so
/usr/lib/jvm/java-7-openjdk-armhf/jre/lib/arm/server/libjvm.so

I know that in openjdk-6, plugwash just disabled the building of the jamvm shared library, but I'm not sure about the other shared libraries. If these files in the armel version of openjdk-7 also contain armv7 code, then it does look like it would be an instance where armv7 optimizations are brought in dynamically at runtime. I'll check on this and post back.

[plugwash]

/usr/lib/jvm/java-7-openjdk-armhf/jre/lib/arm/jamvm/libjvm.so
/usr/lib/debug/usr/lib/jvm/java-7-openjdk-armhf/jre/lib/arm/server/libjvm.so
/usr/lib/jvm/java-7-openjdk-armhf/jre/lib/arm/server/libjvm.so

Basically the same as what I encountered in openjdk-6

I know that in openjdk-6, plugwash just disabled the building of the jamvm shared library

That wasn't the only change I made, I also had to make a change to arm_port/hotspot/src/cpu/zero/vm/cppInterpreter_arm.S to get the main libjvm.so file to come out clean.

Thank you for all your work, I now have a fully working Raspbian which contains nearly everything I need.

Last think I would love is a xbmc package, switching sd cards is such a pain, launching it directly from Raspbian would be wonderful.

Last think I would love is a xbmc package, switching sd cards is such a pain, launching it directly from Raspbian would be wonderful.

That shouldn't be to hard I guess. XBMC already builds and runs for the rpi. You would only need to know if the "standard" XBMC-source needs any patching and where you could get this patch or patched source. What I'm interested in is if the libraby's from raspbmc and openelec are armhf. Maybe somebody from raspbmc or openelec could comment on this?

I would really like to have node.js and npm available.
For nodejs there are packages for sid with amd64 armel armhf i386 as architectures so it looks as if it would be possible at least. npm have [b]all[b] as architecture so that should not be impossible as soon as nodejs is working.

http://packages.debian.org/sid/nodejs
http://packages.debian.org/sid/npm

Code: Select all

Package unrar is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'unrar' has no installation candidate

Can we get unrar included?

Code: Select all

The following packages have unmet dependencies:
 xserver-xorg-video-dummy : Depends: xorg-video-abi-11 but it is not installable
E: Unable to correct problems, you have held broken packages.

How about xserver-xorg-video-dummy for easy headless x11vnc usage?