Devuan bug report logs - #172
apt-get dist-upgrade or aptitude full-upgrade on VM with Default-Release set to ascii results in attempt to update kernel to ceres version

Full log

Message #10 received at 172@bugs.devuan.org (full text, mbox, reply):

Received: (at 172) by bugs.devuan.org; 6 Jan 2018 17:50:06 +0000
Return-Path: <OmegaPhil@startmail.com>
Delivered-To: devuanbugs@dyne.org
Received: from tupac3.dyne.org [195.169.149.119]
	by fulcanelli with IMAP (fetchmail-6.3.26)
	for <debbugs@localhost> (single-drop); Sat, 06 Jan 2018 18:50:06 +0100 (CET)
Received: from smx-7fb.smtp.startmail.com (smx-7fb.smtp.startmail.com [37.153.204.247])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by vm6.ganeti.dyne.org (Postfix) with ESMTPS id AA796F615A9
	for <172@bugs.devuan.org>; Sat,  6 Jan 2018 18:50:09 +0100 (CET)
Authentication-Results: vm6.ganeti.dyne.org;
	dkim=pass (2048-bit key; unprotected) header.d=startmail.com header.i=@startmail.com header.b="wudmLkNP";
	dkim-atps=neutral
Received: from smx-8a9.int1.startmail.com (smx-8a9.int1.startmail.com [10.1.137.139])
	by smx-7fb.smtp.startmail.com (Postfix) with ESMTPS id E975EB7A8E
	for <172@bugs.devuan.org>; Sat,  6 Jan 2018 18:49:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=startmail.com;
	s=dkim; t=1515260994;
	bh=CiQxSL+WEgtlvikECRBLfrmojPPXEYgtuAx8tOq7+WU=;
	h=Subject:To:References:From:Date:In-Reply-To:From;
	b=wudmLkNPaEfPM3MAOwO5Q1KprKmkcvrkWLPW2Ffsk0673bwL/+vCLFNiktxF+4esN
	 AieiK598avtCPLqX4ccnk5d5y2g7yyGGEig+3WWA+QBn/gQ0q7G6pduuJ2II1Ns0fx
	 K2oH0TDFSC3U9MAW65E91n2/QYi6tPND/hunP9FGVyAWIPJVRi0VW8rxRUalkc4aRu
	 FV+Sk8+HSrBRJ3zCaTLv0aZkBJ4GoiBrGSLgG8IodXgb7FiO278QK0+UieU4Id7meA
	 ibNpVLBzIN3L+7YmX/zLKGdTVPEgCQQPFzBQWmsZHblSfok34T6xlh6oUCbE3cz8eK
	 8TsJsPJjDqPhw==
Subject: Re: bug#172: Acknowledgement (apt-get dist-upgrade or aptitude
 full-upgrade on VM with Default-Release set to ascii results in attempt to
 update kernel to ceres version)
To: 172@bugs.devuan.org
References: <c7825801-ccb9-7be3-b005-32f837e29cdc@startmail.com>
 <handler.172.B.15151746053481.ack@bugs.devuan.org>
From: OmegaPhil <OmegaPhil@startmail.com>
Message-ID: <2a2a8c7f-fa6a-9fd1-74f4-86e968bfa95b@startmail.com>
Date: Sat, 6 Jan 2018 17:49:40 +0000
Mime-Version: 1.0
In-Reply-To: <handler.172.B.15151746053481.ack@bugs.devuan.org>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="Io7cIUtpGVU5JnCzT0xUnoY6pvAvTqY61"
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS,WEIRD_PORT
	autolearn=disabled version=3.4.1
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tupac3.dyne.org

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, attachment)]

Send a report that this bug log contains spam.