On 05/01/18 18:03, Devuan bug Tracking System wrote:
> Thank you for the problem report you have sent regarding Devuan.
> This is an automatically generated reply, to let you know your message has
> been received.  It is being forwarded to the developers mailing list for
> their attention; they will reply in due course.
> 
> Your message has been sent to the package maintainer(s):
>  owner@bugs.devuan.org
> 
> If you wish to submit further information on your problem, please send
> it to 172@bugs.devuan.org (and *not* to
> submit@bugs.devuan.org).
> 
> Please do not reply to the address at the top of this message,
> unless you wish to report a problem with the bug-tracking system.
> 
> Devuan Bugs Owner
> (administrator, Devuan bugs database)


Right, finally figured it out. The error:

========================================================================

E: The value 'ascii' is invalid for APT::Default-Release as such a
release is not available in the sources

========================================================================

is a red herring that only happens after you change the URLs associated
with apt repos.

In libapt-pkg5.0/apt-1.4.8/apt-pkg/policy.cc:pkgPolicy::pkgPolicy, if a
Default-Release has been specified, the code loops through all package
cache files (cached versions of the repo release files) looking for one
which has an archive (suite), codename or version that matches the
Default-Release.

When you change all repo URLs, these caches are invalidated and only the
/var/lib/dpkg/status package cache file remains - which has archive
'now' and little else. So when you do 'aptitude update', the loop checks
just this file and then says 'nope, no matching repo found'. The release
files are then downloaded from the relevant repos and turned into
caches, naturally the next command that needs to run (e.g. aptitude
full-upgrade) finds the relevant archive/codename and is happy.

The next problem, that apt was attempting to install a ceres kernel, is
related to the archive/codenames being exposed - investigating an
affected package:

========================================================================

apt-cache policy linux-headers-amd64
linux-headers-amd64:
  Installed: 4.9+80+deb9u3
  Candidate: 4.14+89
  Version table:
     4.14+89 500
        500 http://pkgmaster.devuan.org/merged ceres/main amd64 Packages
 *** 4.9+80+deb9u3 500
        500 http://pkgmaster.devuan.org/merged ascii-security/main amd64
Packages
        100 /var/lib/dpkg/status
     4.9+80+deb9u2 990
        990 http://pkgmaster.devuan.org/merged ascii/main amd64 Packages
     3.16+63 500
        500 http://pkgmaster.devuan.org/merged jessie/main amd64 Packages

========================================================================

Here we have the package installed from ascii-security (which is unusual
for me since I'm trying to update to get away from the Spectre crap),
you'll notice the pin level is only 500 on ascii-security compared to
990 on ascii.

Back in policy.cc:

CreatePin(pkgVersionMatch::Release,"",DefRel,990);

So, apt basically thinks that the ascii-security repo 'is not ascii'.

Through 'apt-cache policy':

========================================================================

 500 http://10.1.0.3:3142/pkgmaster.devuan.org/merged
ascii-security/non-free amd64 Packages
     release
v=2.0,a=testing-security,n=ascii-security,l=Devuan-Security,c=non-free,b=amd64
     origin 10.1.0.3

========================================================================

a = archive, n = codename - both of these aren't 'ascii', nor 'testing'
(for argument's sake), so this repo isn't pinned.

Spinning up a Debian Stable VM, I can see that their security repo
works, but their updates repo has a similar issue (perhaps on purpose?):

========================================================================

 500 http://10.1.0.3:3142/ftp.uk.debian.org/debian stable-updates/main
amd64 Packages
     release
o=Debian,a=stable-updates,n=stretch-updates,l=Debian,c=main,b=amd64
     origin 10.1.0.3
 990 http://10.1.0.3:3142/security.debian.org stable/updates/main amd64
Packages
     release
v=9,o=Debian,a=stable,n=stretch,l=Debian-Security,c=main,b=amd64
     origin 10.1.0.3
 990 http://10.1.0.3:3142/ftp.uk.debian.org/debian stable/main amd64
Packages
     release v=9.3,o=Debian,a=stable,n=stretch,l=Debian,c=main,b=amd64
     origin 10.1.0.3

========================================================================

I have no experience here, but this suggests that Devuan's security repo
should be have an archive of 'ascii' rather than 'ascii-security'.

Aside from the usual way of specifying 'ascii' or 'testing' in
Default-Release, I could almost use '2.0' since both ascii and
ascii-security use this, but ascii-updates uses '2.0.0'...