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

Bug#1025405: marked as done (UDD: how-can-i-help.json.gz - kbtin testing-autorm also lists colorized-logs binary but kbtin in testing has no colorized-logs binary)

Your message dated Fri, 23 Dec 2022 11:07:28 +0100
with message-id <Y6V94GYV7w20cpb0@xanadu.blop.info>
and subject line Re: Bug#1025405: UDD: how-can-i-help.json.gz - kbtin testing-autorm also lists colorized-logs binary but kbtin in testing has no colorized-logs binary
has caused the Debian Bug report #1025405,
regarding UDD: how-can-i-help.json.gz - kbtin testing-autorm also lists colorized-logs binary but kbtin in testing has no colorized-logs binary
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.)


-- 
1025405: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1025405
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: qa.debian.org
Severity: normal
User: qa.debian.org@packages.debian.org
Usertags: udd

The listing of the kbtin testing-autorm also lists the colorized-logs
binary package but kbtin in testing has no colorized-logs binary since
it was split out of the kbtin source between stretch and buster.

Looking at the code, I am guessing this is because the script extracts
all binary packages from the database regardless of source version.

So the solution is probably to query just the binary packages in
testing for the testing-autorm check and just the binary packages in
unstable for the no-testing check and similar for other checks.

$ curl -s https://udd.debian.org/how-can-i-help.json.gz | zcat | jq '.[] | select(.source=="kbtin")'
{
  "type": "testing-autorm",
  "hash": "33c26617f7b9ebd82a87625b33bfa9de",
  "source": "kbtin",
  "packages": [
    "kbtin",
    "colorized-logs"
  ],
  "removal_time": 1672164726,
  "bugs": []
}

$ rmadison -a source,amd64 kbtin colorized-logs | grep -E ' (old)?oldstable'
colorized-logs | 1.0.17-1      | oldoldstable    | amd64
colorized-logs | 2.4-1         | oldstable       | source, amd64
kbtin          | 1.0.17-1      | oldoldstable    | source, amd64
kbtin          | 1.0.19-2      | oldstable       | source, amd64

$ apt-get changelog kbtin | grep -C4 colorized-logs

kbtin (1.0.18-1) unstable; urgency=medium

  * New upstream release.
  * Drop colorized-logs, it's a separate source now.
  * Check the tarball's signature.

 -- Adam Borowski <kilobyte@angband.pl>  Sun, 22 Oct 2017 02:15:20 +0200

kbtin (1.0.17-1) unstable; urgency=medium

  * New upstream release.
  * Split out ansi2html, ansi2txt, ttyrec2ansi, (new) pipetty to a new
    package "colorized-logs".

 -- Adam Borowski <kilobyte@angband.pl>  Mon, 29 Aug 2016 17:12:51 +0200

kbtin (1.0.16-2) unstable; urgency=medium

$ grep -A4 'srcs =' scripts/generate-how-can-i-help 
srcs = {}
dbget("select distinct package, source from packages_summary").each do |r|
  srcs[r['source']] ||= []
  srcs[r['source']] << r['package']
end

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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


--- End Message ---
--- Begin Message --- 
Hi,

On 04/12/22 at 13:58 +0800, Paul Wise wrote:
> Package: qa.debian.org
> Severity: normal
> User: qa.debian.org@packages.debian.org
> Usertags: udd
> 
> The listing of the kbtin testing-autorm also lists the colorized-logs
> binary package but kbtin in testing has no colorized-logs binary since
> it was split out of the kbtin source between stretch and buster.
> 
> Looking at the code, I am guessing this is because the script extracts
> all binary packages from the database regardless of source version.

Fixed in 4b18bb84feb286755046211161fa3434fdcb2424, by restricting to
experimental/sid/testing/stable when mapping packages.

If I remember correctly, this is used on the client side to identify
which are the relevant hints for a specific Debian installation, so it
makes sense to be inclusive (but not too inclusive, as you noticed).

Lucas

--- End Message ---
Reply to: