[conspire] upgrade and grub

Fri Jun 29 15:39:52 PDT 2018

Quoting Paul Zander (paulz at ieee.org):

> Regarding Debian versions, I have been using "testing" for years.  I
> should have corrected you some emails back, but I was making progress
> on other issues. My apologies.

Ah, thanks for the clarification.  Upthread, it had emerged that you'd
originally (2015) installed 'jessie' when it was the Debian-testing branch, and
there was some question whether you'd re-synced it to the
rolling-release Testing package archive in recent times, given that you
said you had really old package versions.

I said then:

  You tell me: Is this a system on which you haven't done normal package 
  operations like...

  apt-get update
  apt-get dist-upgrade

  ...in quite a long time?

You didn't reply.

Next message, I reiterated:

  Adding to the uncertainties on my end, I'm still a bit unclear on
  whether you've done much in the way of routine software updating on this
  system since 2015.

You again made no comment.

At the time, I advised
(http://linuxmafia.com/pipermail/conspire/2018-June/009191.html) that
you could go forward either of two ways.  You could re-converge onto the
Stable branch, which is now 'stretch' what one might call jessie+1.  Or
you could remain with sources.list pointed to Testing, and do the
apt-get dance to update your system to _that_ track.

Immediately following my explaining that choice, you said something that
seemed to indicate you'd adopted choice #1, reconverging onto the Stable
branch.  Actually, was here: 
http://linuxmafia.com/pipermail/conspire/2018-June/009192.html

  Somehow, I am missing contrib and non-free from your suggestion.
  deb http://deb.debian.org/debian stable-updates main contrib non-free

To which I commented:

  I infer that you have now opted to re-converge onto Debian Stable.

And again you made no comment.

> Over the years, I have had various frustrations when the Debian
> version of some package was a year or more behind the current 
> release for other operating systems.

Specifically, you mean the version available on Debian-_Stable_.
Yes, this is widely noted, almost proverbial.  It's pretty much 
the most salient fact about Debian-Stable, except for the resulting
software stability within that release-oriented distribution.  
The package maintainers, prior to release, pick a version of each
particular piece of upstream software that they think will be stable and
maintainable for the lifetime of the release.  As bugs and security
problems emerge following release, either the package maintainers or the
Debian Security Team apply backported patches to the selected 'stable
version' of that software.  So, for example, the upstream version of
Firefox-ESR shipped in Debian 9 'stretch' is (Debian versioning string) 
52.9.0esr-1 -- based on Mozilla Inc's upstream version 52.9.0.  For the 
entire lifetime of Debian 9 'stretch', the offered version of Firefox
ESR will remain 52.9.0.   Only when Debian 10 'buster' gets released as
the replacement Debian-stable branch (and 'stretch' gets reassigned
to track name 'oldstable') will new upstream base code get used for the
(new) Debian-stable branch's package.

Incidentally, I've been trying, repeatedly, to coax you into recognising
that phrases like 'the Debian version of some package' is ambiguous.
There are three different things people commonly call 'Debian':

1.  Debian-stable, which is a release distribution
2.  Debian-testing, a rolling distribution
3.  Debian-unstable, a rolling distribution nearly identical
    to 'testing', except testing applies a quarantining script

So, sure, it's almost proverbial that the Debian-stable version of some
package is often a year or more behind the current release of other
operating systems.  By way of compensation, you get very rock-solid code 
and a guaranteed smooth upgrade path (to subsequent 'stable' releases).

The Debian-testing and Debian-unstable version of that same package will
reliably be close to bleeding edge -- with consequent disadvantages.

> As you said in a different email, "The downside of
> Debian-stable is that the software versions are... old. "
> So now I have the opposite situation, a particular package (openscad)
> is in stable, but not in testing.

For reasons I covered in detail.  One blocker is build errors on the
mipsel architecture.  If Debian cared only about x86_64, as many distros
do, it would not have those problems.  The other blocker as shown in the
Debian bug-tracking system (BTS) is that a TrueType font OpenSCAD
depends on has been orphaned and is no longer available.

When is the package maintainer going to fix that?  Is the package
maintainer going to fix that?  I don't know.  Could be as simple for him
as rebuilding his package to use the newer upstream code.

> I have two computers.  Both have now been well upgraded and have
> latest "testing" versions of dozens of other packages, including Firefox.
> OpensCAD installed and runs on one.  It won't install on the other
> because of some missing libraries. 

Upthread, I mentioned it being said on the developer page
(https://tracker.debian.org/pkg/openscad) that package openscad had been
removed from Debian-Testing on 2018-01-15 because of the two
above-mentioned errors.  That means apt-get will no longer install it
from the 'testing' track.  I infer that you installed the software on
one computer prior to 2018-01-15, and either didn't do so on the other
or did so but later removed it.

It's still in the packages pool, though.
https://mirrors.edge.kernel.org/debian/pool/main/o/openscad/
(I'm using one Debian mirror site at kernel.org for this example, but
there are many others.)

On the machine where OpenSCAD is installed and working, do 'dpkg -s
openscad'.  Note the package version for OpenSCAD as well as for all
the listed dependencies.   With reasonable luck, the only one of those
missing on the other machine is the openscad package itself (because
it's been removed from Testing).  So, in that case, you can delve into
https://mirrors.edge.kernel.org/debian/pool/main/o/openscad/ , find and
fetch the right .deb file for the desired release and your CPU
archicture, and then do 'dpkg -i [packagename]'.

Above you say something about 'missing libraries'.  I have no idea what
that refers to.   (But you do get to that.)

libs packages remain in the package pool even if, say, the Testing track
has removed them.  See the top of the pool tree at
https://mirrors.edge.kernel.org/debian/pool/main/ .  Notice that the
libraries package are _not_ under 'l' but rather are under liba, libb,
libc, etc.  However, this is tricky, because often libs packages are
stored under the main package to which they pertain.

   Computer 2 lists th
      Depends:  libcgal12 but it is not installable

This is a lib for CGAL (Computational Geometry Algorithms Library).
It's not findable in the
https://mirrors.edge.kernel.org/debian/pool/main/libc/ tree but rather
in https://mirrors.edge.kernel.org/debian/pool/main/c/cgal/

      Depends:  libqt5scintilla2-12v5  (>=2.8.4) but it is not
installable

Package is a lib for the Qt5 port of the Scintilla source code editing
widget.

Again, no luck under /debian/pool/main/libq/.  Found it in
https://mirrors.edge.kernel.org/debian/pool/main/q/qscintilla2/ .

You may have to do a bit of fiddling, collecting exactly the right
.deb package files and putting them in semi-manually using 'dpkg -i
packagename'.

(Anyone having easier ways feel welcome to speak up.)