I'm enthusiastic about the rPi which has Debian wheezy
as its default OS. But both programs that I tried to
install/port: dvtm, wily; failed.
I don't want to have to look into C and especially not C+,
but IIRC they failed because of missing libraries.
Apparently X86 *nix will have a mass of libraries, which
program authors, can just hook into, but ARM versions often
won't be available. So even with the C sources the program is
not installable under ARM. So the popularity curse rules again.
Is that right?
On Wednesday, April 17th, 2013, at 21:12:21h +0000,
Baas Chris Glur explained:
It is great to hear that you have still got the greatest enthusiasm
and confidence in the mission, but we all know that you have made
some very poor decisions recently.
How did you try to install them?
Why not? Are you allergice to C and C++ code?
If you cannot remember what you had for breakfast, what confidence
can the reader have that your are correctly remember the reason
for the failure?
No, not apparently: it does and that is a fact.
Why not? For user level programs, if the source code is available,
then the library can be compiled for the ARM processor.
Your logic is impeccably flawed as usual.
Because the herds of wart hogs and wildebeests have migrated
to Facebook and Twitter.
No, it is not right.
Before you can compile a program which requires external libraries,
you must install the related header files which are provided in
the development package related to the library.
When you ran the configure script for the software program, prior
to compilation, it will have indicated which libraries/header files
But you know all this already because of your superior intelligence
Please do tell all why you need wily,
"A work-alike of the Acme programming environment for Plan 9"
on a rPi? The world is listening in eager anticipation.
First off, did you see if those programs have already been ported?
If so, pull them in with the apt package manager, which will also pull in
their dependencies. Otherwise, make a list of the missing libraries and
try installing them with apt. Any that aren't available will need to be
downloaded, compiled and installed, but that's no more difficult than
compiling those programs: in fact the 'make' recipe for most libraries
will do all the work - just read the README and do what it says to
configure, compile and install the libraries. Then try compiling the
programs again. If there are still missing libraries rince, wash and
repeat. It can be a little tedious but its not difficult.
Most libraries compile and install without any difficulty. I can't
remember one that hasn't on the various Linux systems where I've done
Same applies to the RPi: when I installed microEmacs, my favourite text
editor, I found that libtermcap wasn't available for RPi's Debian Wheezy,
so I downloaded it from the Free Software Foundation as a source tarball.
That unpacked, compiled and installed without a problem. At that point I
imported /etc/termcap from my Fedora development box and compiled
microEmacs again. This time there were no problems and it ran first time.
That depends entirely on what you're trying to port to the RPi and what
its dependencies are. In my case libtermcap is very old and is mostly
supplanted by libterminfo, so I wasn't really surprised that I had to go
and get it.
Other stuff with mainstream dependencies should port without problems,
but the more the program you want differs from the stuff that has already
been ported by the RPi devs, the greater your dependency problems will
There should be some way of asking the devs to add what what you just
ported to the RPi Debian Wheezy distro and telling them what its
dependencies are. I don't know how that should be done, but if its likely
that others would find your port useful, you might want to get it
included in the distro.
martin@ | Martin Gregorie
gregorie. | Essex, UK
Anyone who wishes can donate time to recompiling standard Linux
sources for unusual architectures. Debian does better than most in
but it's down to 'boots on
the ground' as to how fast this proceeds.
There's probably a fair bit of work to do in this case, as ARM machine
code is very orthogonal, and not particularly congruent with that of
CISC machines such as X86, so quite a bit will need to be re-written to
optimise for the architecture. I did some ARM assembler work
twenty-something years ago, and it was much more reminiscent of the DG
Nova than of the (then) modern processors. It's almost writing in
If you're [also] a Windows person, you will know that hardly any
standard Windows software runs on RT. Windows has been x86 32/64
bit/Itanium for many years (I think NT 4.0 was the last Windows before
RT to run on another architecture), so they've got out of the habit of
writing for multiple architectures.
Third-party Windows authors have exactly the same problem of
re-compiling for a fairly alien architecture. Most aren't even willing
to port their software to other Windows versions, and few will be
willing to chance their ARMs on something quite different.
Did you try to install the Debian packages from the archive? "apt-get
install dvtm wily" should work.
Almost every Debian package is available for ARM (including libraries).
It is a supported architecture. The autobuilders take care of it except
when packages are restricted to certain achitectures (rare).
Not really. Gcc does an excellent job except for a few corner cases.
Almost all packages build on Debian's autobuilders without difficulty.
When there are problems it usually turns out to be a bug which simply
failed to manifest on other architectures. Remember that Debian
supports ten architectures and all packages are expected to build on all
of them unless there is a good reason why not. FTBS (Failed To Build
from Source) is a serious bug that cannot be fixed by merely deleting
the troublesome architecture.
On Wednesday, April 17th, 2013, at 17:27:48h -0500, John Hasler asked:
OOPS, my search earlier only found them in stable, but that search
was invalid, and lo and behold for Debian Bronchitis --
Package: dvtm (0.6-1) armel
Tiling window management for the console
Package: wily (0.13.41-7.2) armel
A work-alike of the Acme programming environment for Plan 9
So your suggestion is of course the sensible action to take, and because
it is the sensible and easiest course of action to take to resolve the
problem will be summarily dismissed as the wrong answer to the problem.
debian is a very large distro they have over 37000 packages for
the raspberry pi. Both dvtm and wily are in debiian, you can just
install the stock versions...
$ sudo aptitude install dvtm wily
No, if needed you can get sources for the libraries too and compile
and install them, often the library is abailable, and even already
installed, but to compile against it you need the matching headers
which are found in the dev package.
for libc libc-dev, for libncurses libncurses-dev, etc...
yeah, NT ran on DEC Alpha, but isn't Win-RT (internally) closer to Win-CE
than it is to win-8, and WinCE has been on ARM fo quite a while...
You can get mono for RPI - that'll run a lot of recent "windows
How would I easily see that?
I've had little experience with debian. Mainly because I don't like
aptitude. Mainly because it assumes a permanently on-line connection,
which I haven't got. I need to be in control, and not have systems that
try to go on-line by themselves.
Yea OK, apt[itude] has faced up to the fact that package-management
NEEDS heavy-artillery. My attitude is probably unrealistic, like people
who won't use `mc` to make life easier.
OK, I just don't won't to be a pioneer. I'd prefer to walk behind others.
Well, that can be a big job.
Without knowledge of such subtle details one may need much effort.
That's exactly my problem. Once you've used ETHOberon, you don't want
to go back to bobbing your head upNdown between kybrdNscreen; when you
Thanks, it will become easier as we accumulate contributed knowledge.
Use Aptitude to query available packages.
If you don't like Aptitude you'd better install another OS, or at least
one of the non-Debian derived Linuxes. AFAIK Aptitude does not need a
permanently online connection any more than yum, the RedHat package
manager, does. I've never seen that behavior on my RPi, but then again I
run mine headless and always via the command line.
RedHat's Fedora distro does have a graphical yum front end that scans by
default but its trivially easy to stop it doing that and I'd assume the
same applies to Aptitude. Like you, I don't like automatic updates, so if
my RPi had tried that on I would have disabled it.
You may be using some GUI tool that's scanning for updated packages,
which you can disable, or you may have a cron job installed that's doing
it and that you can delete.
martin@ | Martin Gregorie
gregorie. | Essex, UK
It's not very difficult to run aptitude without going to the
internet in real time. There are two packages that can make a
local mirror or cache:
apt-mirror makes a complete mirror of a repository. Set up a
simple webserver to serve your mirror locally and configure
aptitude to use 'localhost' as its source. I have set up
apt-mirror for speed and to solve the problem of hash-sum
mismatches with Ubuntu DEBs.
apt-cache caches packages as you download them. It wouldn't
be difficult to write a script that would take the name of
one package you want, then do a 'fake' download of that
package and all its dependencies. I did that for Tiny Core,
and doing the same thing for DEBs wouldn't be difficult.
If you need your target system to be entirely isolated from the
internet, set up another system with internet access to download
the packages, then transfer the files between systems via
sneakernet or whatever. If you want to transfer only the DEBs,
there's a package that can build a repository and stuff DEBs into
it. Unfortunately, that package's name slips my mind at the
OK thanks, that looks promising.
BTW I've been counting the 'get yourself a ding-dong' solutions: PLENTY.
The incremental method is effective for task solution:
start from a known good position and incrementally move towards your
target. gpm & mc are much more important for me than wily & dvtm, but
since I had already installed the latter from source to X86, I'd use them
to incrementally test installing more-complex-programs to rPi.
But this is starting to look like a canOworms:----
armel 4,120.2 kB 8,952.0 kB [list of files]
I need to sleep on that, before I buy.
The whole idea of moving towards a rPi is to escape the US infinite
frontier mentality, where the solution to every problem is 'use a BIGGER
Apparently aptitude is designed to handle the complexity of the
dependancies. But it assumes an on-line connection, which I lack.
The big-bang approach [vs. incremental, where the user has control] only
works for a uniform herd of users.
Recently I tore my guts out to install the current `festival`
And several posters wrote "what's yo problem, I installed it easy"
Only after I discovered that they had all installed an earlier version,
I install that too. Now the mail-list has admitted a problem in the new
I want to avoid any similar situation.
While the herd were all following each other 'mortgaging their house for
they were very confident. Now they are all squealing.
Inet promotes a herd mentality. Viral-ideas could collapse the boat.
armel 4,120.2 kB 8,952.0 kB
ls -l /usr/local/sbin/dvtm ==
-rwxr-xr-x 1 root root 31644 2012-06-29 13:44 /usr/local/sbin/dvtm
hexdump -c /usr/local/sbin/dvtm ==
0000000 177 E L F 001 001 001 \0 \0 \0 \0 \0 \0 \0 \0 \0
I haven't got access to rPi right now, but dvtm: a small program;
was chosen to test if/how problematic it is to extend/customise rPi.
We don't want to fall into a M$ type trap?
So dvtm's exec is only 32KB size; but it's dependant libc6 is a
4MB monster; but libc6 is used for 'everything'. So it must be installed
ALREADY. So perhaps I should test compile 'hello world' first.
But I don't want to know about C/C+ because it's such crap, compared to
ETHOberon. Being popular doesn't mean its good. Else M$ would be the best.
Linux has to piggyback on M$ [for the PC BIOS] and ETHOberon can
profitably piggyback on Linux for the large application base.
If a mere 32KB program is problematic, then it's not realistic
to hope to easily 'extend'/modify rPi's program suite.
On Friday, April 19th, 2013, at 08:29:12h +0000, Chris Glur explained:
You must surely be aware that the song "Ding Dong the Witch is dead"
has been played lots of times over the last week or so?
Of course, it is always best to start with something that works
and then gradually change things rather than changing everything
at once and then having to work through all the possibilities where
something has gone wrong.
It is quite straightforward to do this, but you must install the appropriate
development packages in order to have the necessary header files.
But are they in tomato sauce with a subtle basil flavoring?
If you do not buy the bush meat when the poacher is in the dorp
and selling, you might go hungry for a couple of days.
As opposed to the
"South African veldt, which is said to give a greater feeling
of infinity than the ocean even.?
You are out of touch: the current fashion is everything is smaller,
even watching movies on 2 inch screens.
No it does not. And if you do not like aptitude (neither do I in
fact), then use dselect instead.
Warthogs and wildebeests do not wear uniforms.
Was the local medicine man able to put them back?
As do we all.
Are you implying they should drink South African wine instead?
Or they could create a Botnet for fun and profit.
The full quote is "Don't force it, use a bigger hammer." That's
actually good advice, and appears in the workshop manuals for one of the
classic british motorbikes. So, probably not correct to blame the
Americans for it, and it's actually good advice, anyway.