How difficult to port programs to ARM debian?

[Unknown]

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?

== TIA.

[J G Miller]

On Wednesday, April 17th, 2013, at 21:12:21h +0000,
Baas Chris Glur explained:

> I'm enthusiastic about the rPi

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.

> But both programs that I tried to install/port: dvtm, wily; failed.

How did you try to install them?

> I don't want to have to look into C and especially not C+

Why not? Are you allergice to C and C++ code?

> but IIRC they failed because of missing libraries.

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?

> Apparently X86 *nix will have a mass of libraries

No, not apparently: it does and that is a fact.

> which program authors, can just hook into, but ARM versions often
> won't be available.

Why not? For user level programs, if the source code is available,
then the library can be compiled for the ARM processor.

> So even with the C sources the program is not installable under ARM.

Your logic is impeccably flawed as usual.

> So the popularity curse rules again.

Because the herds of wart hogs and wildebeests have migrated
to Facebook and Twitter.

> Is that right?

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
were missing.

But you know all this already because of your superior intelligence
and knowledge.

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.

[Burkhard Ott]

The ARM architecture is RISC while x86 is CISC, so in the bes case you're
gonna have to recompile/x-compile your C source or whatever code you wann
run there. Same for the libraries.

cheers

[Martin Gregorie]

On Wed, 17 Apr 2013 21:12:21 +0000, Unknown wrote:

> 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.
>

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.

> I don't want to have to look into C and especially not C+,
> but IIRC they failed because of missing libraries.
>

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
this.

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.

> Is that right?
>
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
be.

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.

HTH


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

[Joe]

Yes.

Anyone who wishes can donate time to recompiling standard Linux
sources for unusual architectures. Debian does better than most in
this respect, (http://www.debian.org/ports/) 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
microcode.

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.

--
Joe

[John Hasler]

Unknown writes:
> But both programs that I tried to install/port: dvtm, wily; failed.

Did you try to install the Debian packages from the archive? "apt-get
install dvtm wily" should work.

> Apparently X86 *nix will have a mass of libraries, which program
>authors, can just hook into, but ARM versions often won't be available.

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).
--
John Hasler

[John Hasler]

> 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.

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.
--
John Hasler

[J G Miller]

On Wednesday, April 17th, 2013, at 17:27:48h -0500, John Hasler asked:

> Did you try to install the Debian packages from the archive? "apt-get
> install dvtm wily" should work.

OOPS, my search earlier only found them in stable, but that search
was invalid, and lo and behold for Debian Bronchitis --


<http://packages.debian.ORG/wheezy/dvtm>

Package: dvtm (0.6-1) armel

Tiling window management for the console


<http://packages.debian.ORG/wheezy/wily>

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.

[jeff g.]

On 04/17/2013 02:40 PM, J G Miller wrote:

no, he didn't, it was part of a quote he referred to...

> 21:12:21h +0000,

what time format is this (I'm UTC deprived)?

[Aragorn]

On Thursday 18 April 2013 02:08, jeff g. conveyed the following to
alt.os.linux.debian...

I am guessing hh:mm:ss, and +0000 indicates GMT.

--
= Aragorn =
GNU/Linux user #223157 - http://www.linuxcounter.net

[John Hasler]

jeff g. writes:
> no, he didn't, it was part of a quote he referred to...

> 21:12:21h +0000,

> what time format is this (I'm UTC deprived)?

man date
--
John Hasler

[Jasen Betts]

On 2013-04-17, Unknown <d...@gmail.com> wrote:
> 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.

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

> 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?

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...


--
⚂⚃ 100% natural

[Jasen Betts]

On 2013-04-17, Joe <j...@jretrading.com> wrote:

> 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),

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
software".


--
⚂⚃ 100% natural

[Unknown]

On Wed, 17 Apr 2013 21:45:06 +0000, Martin Gregorie wrote:

> On Wed, 17 Apr 2013 21:12:21 +0000, Unknown wrote:
>
>> 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.
>>
> First off, did you see if those programs have already been ported?
>

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.

> 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.
>

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.

>> I don't want to have to look into C and especially not C+, but IIRC
>> they failed because of missing libraries.
>>
> 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
> this.
>

OK, I just don't won't to be a pioneer. I'd prefer to walk behind others.

> 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.
>

Well, that can be a big job.

>> Is that right?
>>
> 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.
>

Without knowledge of such subtle details one may need much effort.

> 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 be.
>

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
can fly-head-up.

> There should be some way of asking the devs to add 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.
>
> HTH

Thanks, it will become easier as we accumulate contributed knowledge.

[Martin Gregorie]

On Thu, 18 Apr 2013 19:54:19 +0000, Unknown wrote:

> On Wed, 17 Apr 2013 21:45:06 +0000, Martin Gregorie wrote:
>
>> On Wed, 17 Apr 2013 21:12:21 +0000, Unknown wrote:
>>
>>> 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.
>>>
>> First off, did you see if those programs have already been ported?
>>
> How would I easily see that?
>

Use Aptitude to query available packages.

> 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.
>

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.

[Richard Kettlewell]

Martin Gregorie <mar...@address-in-sig.invalid> writes:
> On Thu, 18 Apr 2013 19:54:19 +0000, Unknown wrote:
>> On Wed, 17 Apr 2013 21:45:06 +0000, Martin Gregorie wrote:
>>> On Wed, 17 Apr 2013 21:12:21 +0000, Unknown wrote:

>>>> 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.
>>>>
>>> First off, did you see if those programs have already been ported?
>>>
>> How would I easily see that?
>>
> Use Aptitude to query available packages.

Or apt-cache, or synaptic, if you prefer.

>> 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.
>>
> 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.

Indeed, none of these tools require permanent connectivity.

--
http://www.greenend.org.uk/rjk/

[Unknown]

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:----
http://packages.debian.ORG/wheezy/wily
dep: [46]libc6 (>= 2.4) [armel, armhf, powerpc, s390]
http://packages.debian.ORG/wheezy/libc6
[64]armel 4,120.2 kB 8,952.0 kB [[65]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
hammer'.

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`
TextToSpeech system.
And several posters wrote "what's yo problem, I installed it easy"
Only after I discovered that they had all installed an earlier version,
did
I install that too. Now the mail-list has admitted a problem in the new
version.
I want to avoid any similar situation.
While the herd were all following each other 'mortgaging their house for
beer',
they were very confident. Now they are all squealing.
===
Inet promotes a herd mentality. Viral-ideas could collapse the boat.

[Unknown]

On Wed, 17 Apr 2013 22:40:26 +0000, J G Miller wrote:

> On Wednesday, April 17th, 2013, at 17:27:48h -0500, John Hasler asked:
>
>> Did you try to install the Debian packages from the archive? "apt-get
>> install dvtm wily" should work.
>
> OOPS, my search earlier only found them in stable, but that search was
> invalid, and lo and behold for Debian Bronchitis --
>
>
> <http://packages.debian.ORG/wheezy/dvtm>
>
> Package: dvtm (0.6-1) armel
>
> Tiling window management for the console

> 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.

http://packages.debian.ORG/wheezy/wily
dep: [46]libc6 (>= 2.4) [armel, armhf, powerpc, s390]
http://packages.debian.ORG/wheezy/libc6
[64]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.

[J G Miller]

On Friday, April 19th, 2013, at 08:29:12h +0000, Chris Glur explained:

> BTW I've been counting the 'get yourself a ding-dong' solutions: PLENTY.

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?

> The incremental method is effective for task solution:

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.

> since I had already installed the latter from source to X86, I'd use them
> to incrementally test installing more-complex-programs to rPi.

It is quite straightforward to do this, but you must install the appropriate
development packages in order to have the necessary header files.

> But this is starting to look like a canOworms

But are they in tomato sauce with a subtle basil flavoring?

> I need to sleep on that, before I buy.

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.

> The whole idea of moving towards a rPi is to escape the US infinite
> frontier mentality

As opposed to the

"South African veldt, which is said to give a greater feeling
of infinity than the ocean even.”

> where the solution to every problem is 'use a BIGGER hammer'.

You are out of touch: the current fashion is everything is smaller,
even watching movies on 2 inch screens.

<http://www.liliputing.com/>

> Apparently aptitude is designed to handle the complexity of the
> dependancies. But it assumes an on-line connection

No it does not. And if you do not like aptitude (neither do I in
fact), then use dselect instead.

> The big-bang approach [vs. incremental, where the user has control] only
> works for a uniform herd of users.

Warthogs and wildebeests do not wear uniforms.

> Recently I tore my guts out

Was the local medicine man able to put them back?

> I want to avoid any similar situation.

As do we all.

> While the herd were all following each other
> 'mortgaging their house for beer',

Are you implying they should drink South African wine instead?

> Viral-ideas could collapse the boat.

Or they could create a Botnet for fun and profit.

[Raymond Wiker]

Unknown <d...@gmail.com> writes:

> 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
> hammer'.

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.

[Martin Gregorie]

While I was having a mouse round the apt-get/cron nexus today, I found
that on mine that by default there's a daily cron job that does an auto
update. I don't run my RPi overnight, which is why I haven't seen it do
anything. I'd like to disable it, but can't find anything in the man
pages apart the preferred way to do that. I can always hack into the
'apt' script would prefer not to. I'm a Fedora user by default, so the RPi
is my first real exposure to the Debian world.

So, can anybody point me at a description of the Aptitude package
management organisation and, on particular where to find where stuff like
APT::Periodic::Auto can be found and how to change its settings? On my
box it is *NOT* in /etc/apt/ - I've looked.

[The Natural Philosopher]

easire is to remove the script that does it out of the cron directories
try /etc/cron.daily




--
Ineptocracy

(in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers.

[J G Miller]

le vendredi, 19 avril, 2013, á 19:40:46h +0000, Martin Gregorie a écrit:

> While I was having a mouse round the apt-get/cron nexus today, I found
> that on mine that by default there's a daily cron job that does an auto
> update.

Yes it does an update of available packages, but the preferred way of
doing unattended upgrades is with the related cron-apt package.

The daily cron job does significantly more than just update the available
packages so it would be most unwise to follow the advice of the uninformed
and just delete the cron job file.

> So, can anybody point me at a description of the Aptitude package
> management organisation and, on particular where to find where stuff like
> APT::Periodic::Auto can be found and how to change its settings? On my
> box it is *NOT* in /etc/apt/ - I've looked.

But did you look under /etc/apt/apt.conf.d where all the files for
tweaking the different aspects of apt live?

ls -1 /etc/apt/apt.conf.d/

01autoremove
05aptitude
10periodic
15update-stamp
20apt-show-versions
20archive
20changelog
20dbus
20listchanges
20packagekit
35dhelp
40dselect
50unattended-upgrades
70debconf
90autoclean
90showupgraded
99update-notifier


cat 10periodic

//***************************************************************************//
//|
//| file : /etc/apt/apt.conf.d/10periodic
//|
//*-------------------------------------------------------------------------*//
//
APT::Periodic::AutocleanInterval "0";
//
APT::Periodic::Download-Upgradeable-Packages "0";
//
APT::Periodic::Update-Package-Lists "1";
//
//***************************************************************************//



A quick primer for package management dpkg

dpkg -p package_name tells you package details

dpkg -L package_name tells you list of files installed from package

dpkg -S path_to_file tells you the name of the package to which the file belongs
you can just list part of the path which may results in multiple
package names being returned

dpkg --purge package_name remove the package and all of its configuration files



If you want a simpler interface to dpkg as well as combining with apt-get functions,
install wajig (silly name) but it makes command line editing recall manipulations simpler.

apt-get install wajig

[Martin Gregorie]

On Fri, 19 Apr 2013 09:29:46 +0000, Unknown wrote:

> 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'.
>

.... because it contains all the common C bindings for the kernel APIs.

Linux replaced the 'bigger hammer' with code reuse, often in the form of
code libraries, which works really well, but at a cost: an application's
dependencies on a set of libraries. clib is a good example and, as very
many language compilers are effectively a preprocessor that front-ends
the C compiler, many program language's compiled code depends on clib too.

> So it must be installed
> ALREADY.
>

And *IS*. There is no Linux distro that I know of that doesn't include
clib.

> So perhaps I should test compile 'hello world' first.
>

Not necessary - for C anyway, but a good learning exercise for getting up
to speed with almost any other language's runtime system regardless if
whether the language is compiled, interpreted or requires a language-
specific VM.

> 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.
>

But - are you sure that the ETHOberon Linux compiler isn't just another
front end for gcc? Very many other language compilers work that way:
COBOL, Fortran, C++, some Java flavours and at least one Ada
implementation all work that way in the Linux environment.

[The Natural Philosopher]

On 19/04/13 21:23, J G Miller wrote:
> le vendredi, 19 avril, 2013, á 19:40:46h +0000, Martin Gregorie a écrit:
>
>> While I was having a mouse round the apt-get/cron nexus today, I found
>> that on mine that by default there's a daily cron job that does an auto
>> update.
> Yes it does an update of available packages, but the preferred way of
> doing unattended upgrades is with the related cron-apt package.
>
> The daily cron job does significantly more than just update the available
> packages so it would be most unwise to follow the advice of the uninformed
> and just delete the cron job file.

but its a good idea to actually delete the /etc/cron.daily/ XXX fiile
that deals with automatic updates ONLY.
You need to know a little of how cron works of course to know that here
is such a file. And in general its one task per file.

But that's the difference between being informed, and checking the
contents of that directory and its files rather than being a smartass
and shooting your mouth off.

[John Hasler]

Martin Gregorie a écrit:
> While I was having a mouse round the apt-get/cron nexus today, I found
> that on mine that by default there's a daily cron job that does an auto
> update.

Which means that you installed cron-apt, an optional package.
--
John Hasler

[Martin Gregorie]

Actually, changing the value of APT::Periodic::Auto from 1 to 0 would be
easiest if I knew where that variable is defined and/or if there's a
script or utility that can edit the file. Easier because the change would
be trivially easy to reverse should I want to do so and is unlikely to be
stomped on by an upgrade to /etc/cron.daily/apt

[Martin Gregorie]

Not knowingly or deliberately. It was either pre-installed on my SD card
image or got pulled in as part of my usual weekly package update run.

[Richard Kettlewell]

Martin Gregorie <mar...@address-in-sig.invalid> writes:
> On Fri, 19 Apr 2013 19:46:44 -0500, John Hasler wrote:
>> Martin Gregorie a écrit:

>>> While I was having a mouse round the apt-get/cron nexus today, I found
>>> that on mine that by default there's a daily cron job that does an auto
>>> update.
>>
>> Which means that you installed cron-apt, an optional package.
>>
> Not knowingly or deliberately. It was either pre-installed on my SD card
> image or got pulled in as part of my usual weekly package update run.

$ dpkg -S /etc/cron.daily/apt
apt: /etc/cron.daily/apt

i.e. the script is part of the apt package, not cron-apt.

--
http://www.greenend.org.uk/rjk/

[Richard Kettlewell]

Martin Gregorie <mar...@address-in-sig.invalid> writes:
> Actually, changing the value of APT::Periodic::Auto from 1 to 0 would be
> easiest if I knew where that variable is defined and/or if there's a
> script or utility that can edit the file.

The version in sid has a comment at the top telling you where to put it:

$ head -10 /etc/cron.daily/apt
#!/bin/sh
#set -e
#
# This file understands the following apt configuration variables:
# Values here are the default.
# Create /etc/apt/apt.conf.d/02periodic file to set your preference.
#
# Dir "/";
# - RootDir for all configuration files
#

> Easier because the change would be trivially easy to reverse should I
> want to do so and is unlikely to be stomped on by an upgrade to
> /etc/cron.daily/apt

conffiles are not blindly overwritten on upgrade in Debian. If you have
modified it then you will get a prompt asking whether you want to keep
the old or new version (among other possibilities). If you choose to
keep the old version then the new version is stored as a separate file
next to it for reference; similarly if you do choose to install the new
version then a backup is kept of the old version.

--
http://www.greenend.org.uk/rjk/

[Martin Gregorie]

On Sat, 20 Apr 2013 12:16:33 +0100, Richard Kettlewell wrote:

> Martin Gregorie <mar...@address-in-sig.invalid> writes:
>> Actually, changing the value of APT::Periodic::Auto from 1 to 0 would
>> be easiest if I knew where that variable is defined and/or if there's a
>> script or utility that can edit the file.
>
> The version in sid has a comment at the top telling you where to put it:
>
> $ head -10 /etc/cron.daily/apt #!/bin/sh #set -e #
> # This file understands the following apt configuration variables: #
> Values here are the default.
> # Create /etc/apt/apt.conf.d/02periodic file to set your preference.
> #
> # Dir "/";
> # - RootDir for all configuration files #
>

OK, to test my understanding: if I create a file called
/etc/apt/apt.conf.d/02periodic which contains the single line:

APT::Periodic::Enable "0";

this will prevent auto updates from happening. True?

>> Easier because the change would be trivially easy to reverse should I
>> want to do so and is unlikely to be stomped on by an upgrade to
>> /etc/cron.daily/apt
>
> conffiles are not blindly overwritten on upgrade in Debian. If you have
> modified it then you will get a prompt asking whether you want to keep
> the old or new version (among other possibilities). If you choose to
> keep the old version then the new version is stored as a separate file
> next to it for reference; similarly if you do choose to install the new
> version then a backup is kept of the old version.
>

OK, understood. What you describe is essentially the same as yum does in
a RedHat system.

What I was referring to as 'getting stomped on' was quick and dirty
changes made to the /etc/cron.daily/apt script, not the config files.

[Jasen Betts]

On 2013-04-18, Unknown <d...@gmail.com> wrote:
> On Wed, 17 Apr 2013 21:45:06 +0000, Martin Gregorie wrote:
>
>> On Wed, 17 Apr 2013 21:12:21 +0000, Unknown wrote:
>>
>>> 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.
>>>
>> First off, did you see if those programs have already been ported?
>>
> How would I easily see that?
> I've had little experience with debian. Mainly because I don't like
> aptitude.

you have to work with apt somehow, either apt-get (to install)
and apt-cache (to search) or aptitude (CUI tool) or synaptic (GUI tool)

there's also dselect which is a cui tool a bit like aptitude but
doesn't download anything itself - IIRC you run
"apt-get dselect-upgrade" to activate the selections, it's pretty
old-school, I don't think many people remeber how to use it.
IIRC you had to untangle any dependancy problems manually.
Aptitude has a dependancy solver that almost always works.

> 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.

It's only going to want to download stuff if you ask it to

> OK, I just don't won't to be a pioneer. I'd prefer to walk behind others.
>
>> 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.
>>
> Well, that can be a big job.

Hmm, I've never used micro-emacs on a computer with more than 100Mib RAM.
(largest was some sort of SUN4 sparcsserver in the early 90s)
why not just use the real thing?

the following emacs-like editors are available in debian

* jed;
* jove and xjove;
* mg;
* ng-cjk, ng-cjk-canna and ng-latin;
* qemacs and qemacs-nox; and
* zile

--
⚂⚃ 100% natural

[Richard Kettlewell]

Martin Gregorie <mar...@address-in-sig.invalid> writes:
> OK, to test my understanding: if I create a file called
> /etc/apt/apt.conf.d/02periodic which contains the single line:
>
> APT::Periodic::Enable "0";
>
> this will prevent auto updates from happening. True?

That looks right.

>>> Easier because the change would be trivially easy to reverse should I
>>> want to do so and is unlikely to be stomped on by an upgrade to
>>> /etc/cron.daily/apt
>>
>> conffiles are not blindly overwritten on upgrade in Debian. If you have
>> modified it then you will get a prompt asking whether you want to keep
>> the old or new version (among other possibilities). If you choose to
>> keep the old version then the new version is stored as a separate file
>> next to it for reference; similarly if you do choose to install the new
>> version then a backup is kept of the old version.
>
> OK, understood. What you describe is essentially the same as yum does in
> a RedHat system.
>
> What I was referring to as 'getting stomped on' was quick and dirty
> changes made to the /etc/cron.daily/apt script, not the config files.

/etc/cron.daily/apt is a conffile.
You can check this with ‘dpkg -s apt’.

--
http://www.greenend.org.uk/rjk/

[Martin Gregorie]

On Sun, 21 Apr 2013 10:25:44 +0100, Richard Kettlewell wrote:

> Martin Gregorie <mar...@address-in-sig.invalid> writes:
>> OK, to test my understanding: if I create a file called
>> /etc/apt/apt.conf.d/02periodic which contains the single line:
>>
>> APT::Periodic::Enable "0";
>>
>> this will prevent auto updates from happening. True?
>
> That looks right.
>

Many thanks. Added to my RPi installation, tested and working.

>
> /etc/cron.daily/apt is a conffile.
> You can check this with ‘dpkg -s apt’.
>

Thanks again. I've now found the information sources I needed to
understand how apt works: the Debian Reference and (especially) Debian
Policy manuals.

To the OP
=========
If you're still following this thread, by now it should be obvious that
that apt/aptitude doesn't and never did require 'always on' connectivity
and you'll now know how to disable the overnight package update cron job.

You should now know also enough to check whether disabling the cron job
also stopped automatic upgrades from being done by aptitude and/or any
GUI pagkage management tool you may be using.

[Unknown]

On Fri, 19 Apr 2013 21:04:37 +0100, The Natural Philosopher wrote:

> On 19/04/13 20:40, Martin Gregorie wrote:
>> On Fri, 19 Apr 2013 08:58:25 +0100, Richard Kettlewell wrote:
>>

>>>>>> First off, did you see if those programs have already been ported?
>>>>>>
>>>>> How would I easily see that?
>>>>>
>>>> Use Aptitude to query available packages.
>>> Or apt-cache, or synaptic, if you prefer.
>>>
>>>>> 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.
>>>>>
>>>> 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.
>>> Indeed, none of these tools require permanent connectivity.
>>>
>> While I was having a mouse round the apt-get/cron nexus today, I found
>> that on mine that by default there's a daily cron job that does an auto
>> update. I don't run my RPi overnight,

WTF !!
How can you have your computer going on-line out-of-your-control?

[Martin Gregorie]

Try reading what I wrote: nothing has been happening I didn't know about.
The auto-update (that I've now disabled BTW) is a daily cron job. Since
you claimed to have used Linux, you should know very well that daily cron
jobs run around 03:00 by default. Since I don't leave mine running
overnight and the atd daemon isn't running, I know very well that the
auto update has never run.

Now, look at the rest of thread, use the information in it to disable the
auto-update on yours and be happy.

BTW, Debian org is clear that you might want to disable auto-update for
'unstable' but that its probably not necessary for 'wheezy'. If you're as
paranoid as I am, you might disable it anyway, but if you do, you should
be careful to regularly run a manual update, preferably immediately after
a backup run. At least, that's what I do. I also keep my source version
control repository on a separate machine.

[Rob]

Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> Try reading what I wrote: nothing has been happening I didn't know about.
> The auto-update (that I've now disabled BTW) is a daily cron job. Since
> you claimed to have used Linux, you should know very well that daily cron
> jobs run around 03:00 by default. Since I don't leave mine running
> overnight and the atd daemon isn't running, I know very well that the
> auto update has never run.

Many modern Linux systems use a more advanced method of running daily
jobs, that also works when the system is not on 24h/day.

[Jasen Betts]

"anacron" also avaialble in rasbpian


--
⚂⚃ 100% natural

[Nick Leverton]

In article <kkqv8m$9pf$1...@dont-email.me>, Unknown <d...@gmail.com> wrote:
>
>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.

Excuse the late reply (I only dip into c.s.r-pi) but have you looked
at apt-offline ? I haven't used it myself but it's designed to allow
installing and updating via APT on a non-connected host. Generally
speaking it should save you lots of effort in building the libraries
you need, as you can just install the existing libXXX-dev package to
get the required headers and libs to link against.

Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996