[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#845651: marked as done (lsb-release: --codename returns n/a on stretch without apt sources configured)

Your message dated Sun, 08 Jan 2017 19:35:13 +0000
with message-id <1483904113.7833.4.camel@gmail.com>
and subject line Re: Bug#845651: lsb-release: --codename returns n/a on stretch without apt sources configured
has caused the Debian Bug report #845651,
regarding lsb-release: --codename returns n/a on stretch without apt sources configured
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
845651: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845651
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: lsb-release
Version: 9.20161101
Severity: important
Tags: patch

Dear maintainer,

Currently lsb_release parses /etc/debian_version and figures out the
testing codename and stores it. But it never uses it unless apt can be
used, which depends on network access.
Without network access and apt sources downloaded, lsb_release -c on
stretch returns n/a. So a simple way to reproduce it is to comment out
all entries in sources.list(.d/*), apt-get update and running
lsb_release -c on stretch.

The fix is simple and just sets the codename after
parsing /etc/debian_release.
A simple patch is attached.

Thank you!

Kind regards,
Luca Boccassi


From c7de044f737f6df4ba8e6501fcb106aecc83e577 Mon Sep 17 00:00:00 2001
From: Luca Boccassi <lboccass@brocade.com>
Date: Fri, 25 Nov 2016 15:26:17 +0000
Subject: [PATCH] Fix detecting debian testing release without apt

Currently lsb_release parses /etc/debian_version and figures out the
testing codename and stores it. But it never uses it unless apt can
be used, which depends on network access.
Without network access and apt sources downloaded, lsb_release -c
on stretch returns n/a.
The fix is simple and just sets the codename after parsing
/etc/debian_release.
---
 lsb_release.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lsb_release.py b/lsb_release.py
index 221a321..f134518 100644
--- a/lsb_release.py
+++ b/lsb_release.py
@@ -273,6 +273,7 @@ def guess_debian_release():
             if release.rstrip('/sid').lower() != 'testing':
                 global TESTING_CODENAME
                 TESTING_CODENAME = release.rstrip('/sid')
+                distinfo['CODENAME'] = release.rstrip('/sid')
             distinfo['RELEASE'] = 'testing/unstable'
         else:
             distinfo['RELEASE'] = release
-- 
2.1.4

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
--- Begin Message --- 
On Sun, 2017-01-08 at 18:37 +0100, Didier 'OdyX' Raboud wrote:
> Control: tags -1 +wontfix 
> 
> Hi there Luca,
> 
> Le dimanche, 8 janvier 2017, 14.54:16 h CET Luca Boccassi a écrit :
> > Any chance this could be looked at before Stretch final freeze? Thank you!
> 
> tl;dr: unfortunately not.
> 
> I have thought about this issue for some time, and I think that the result is 
> actually correct. Let me explain:
> 
> When (as currently), stretch is the testing release, /etc/debian_version 
> contains "stretch/sid", as shipped by base-files. It is therefore impossible 
> to rely on that file to differentiate between a host running testing or 
> unstable without asking apt what is actually preferred when installing 
> packages (through parsing `apt-cache policy`). That's how `lsb-release --
> codename` returns "sid" _xor_ "stretch".
> 
> stretch's base-files is currently in version 9.7, and ships with "stretch/sid" 
> in /etc/debian_version. But if you look at base-files in the current stable 
> (8+deb8u6), its /etc/debian_version currently contains "8.6", and with that, 
> `lsb-release --codename` returns "jessie" consistently, and without relying on 
> apt.
> 
> base-files will be updated in stretch for the release, as happened for jessie:
> > * Release for jessie as stable:
> >   - Use "8" as version in /etc/issue and /etc/issue.net. As usual, this
> >     is never expected to change once that jessie is released as Debian 8.
> >   - Use 8.0 as version in /etc/debian_version. As usual, this is expected
> >     to change at every point release.
> 
> So, if you manually replace your /etc/debian_version's content by "9.0", you 
> should get "stretch" consistently, no matter what your apt configuration is.
> 
> That's all to say that this bug is (to my belief) actually expected behaviour; 
> and fixing it through forcing the codename to be interpreted as "stretch" when 
> apt-cache information is unavailable would be wrong. When /etc/debian_version 
> contains "potato/sid", the codename is either potato xor sid, and only apt-
> cache can discriminate a testing host from a sid host. Therefore, in such a 
> situation, the correct answer is actually "I can't tell", aka "n/a".

Hello Didier,

Thank you for your answer, it makes sense. We build only for testing
internally so I did not consider the unstable case at first but I
understand now, so closing the bug.

Kind regards,
Luca Boccassi

Attachment: signature.asc
Description: This is a digitally signed message part


--- End Message ---
Reply to: