Bug#1067490: tracker.debian.org: Display release-team blocks more prominently

[Raphael Hertzog]

Hi,

top-posting and leaving quite some context because the main point of my
message is to actually share your bug report to the release team.
If I remember correctly, tracker.debian.org is not doing any fancy
treatment. We are just turning some YAML into HTML:
https://release.debian.org/britney/excuses.yaml

We copy the lines from "excuses" as-is so if you want to change the order
here, it needs to happen on the britney side.

Feel free to reassign this to release.debian.org or any other suitable
package if you want.

Have a nice day!

On Fri, 22 Mar 2024, Guillem Jover wrote:
> Currently when a package is blocked by a release-team block hint, that
> appears at the end of the "Issues preventing migration" list, which
> can easily be missed if there are also lots of autopkgtest issues,
> (see the current dpkg tracker page).
[...]
> The block seems like the most important information there, because
> even if everything else gets solved that still requires active action
> by the release-team. So I think it would be better to place it as the
> first item, also so that it does not get drown by autopkgtest entries
> that can be many. Also perhaps the autopkgtest entries should be
> nested? As in:
> 
> ,---
> ∙ ∙ Status for autopkgtest:
> ∙ ∙ ∙ ceilometer/blocked-on-ci-infra: i386: Ignored failure
> ∙ ∙ ∙ chrony/4.5-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ 
> (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, 
> ppc64el: Pass, s390x: Pass
> ∙ ∙ ∙ dash/0.5.12-6: amd64: Pass, arm64: Pass, armel: Regression or new test 
> ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Pass, 
> ppc64el: Pass, s390x: Pass
> ∙ ∙ ∙ dpkg/1.22.6: amd64: Pass, arm64: Pass, armel: Pass, armhf: Pass, i386: 
> Pass, ppc64el: Pass, s390x: Pass
> ∙ ∙ ∙ gsocket/1.4.41-1: amd64: Pass, arm64: Pass, armel: Regression or new 
> test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: 
> Pass, ppc64el: Pass, s390x: Pass
> ∙ ∙ ∙ lintian/2.117.0: amd64: Regression or new test ♻ (reference ♻), arm64: 
> Regression or new test ♻ (reference ♻), armel: Regression or new test ♻ 
> (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: 
> Regression or new test ♻ (reference ♻), ppc64el: Regression or new test ♻ 
> (reference ♻), s390x: Regression or new test ♻ (reference ♻)
> `---
> 
> Which would remove repetition and make it visually easier to see?
> 
> (This has come up recently, I think multiple times, as I've got multiple
> private queries, and some public ones, where it looks like people missed
> the main reason for why dpkg is not migrating.)
> 
> (Also as an aside, perhaps autopkgtest entries that are all-pass,
> should appear in the “Additional info” part instead?)
> 
> Thanks,
> Guillem
> 

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Issue with appstream hints: severity missing for a tag?

[Raphael Hertzog]

Hello Matthias,

the issue disappeared since January 27th. Thank you for your help!

Cheers,

On Sat, 27 Jan 2024, Matthias Klumpp wrote:
> Hi Raphael!
> 
> The issue should be gone for a few days already, do you still see it
> or is it resolved?
> 
> Best,
> Matthias
> 
> Am Do., 25. Jan. 2024 um 16:59 Uhr schrieb Matthias Klumpp
> :
> >
> > Hi Raphael!
> >
> > Am Do., 25. Jan. 2024 um 10:30 Uhr schrieb Raphael Hertzog 
> > :
> > >
> > > Hello Matthias,
> > >
> > > I recently opened my ow...@tracker.debian.org mailbox and I found
> > > hundreds of errors:
> > >
> > > 
> > > Task UpdateAppStreamStatsTask failed with the following traceback.
> > >
> > > KeyError
> > > 'asv-cid-contains-hyphen'
> > > [...]
> >
> > So the issue is that this tag has been removed/renamed, but Debian
> > still has a bunch of components cached that have emitted it.
> > The most trivial solution, given that a tag rename/removal is rather
> > rare, is to simply reprocess all data to make sure the old tag isn't
> > used anymore.
> >
> > I will kickstart a full reprocessing of the whole archive (well, the
> > sid component) today, then this issue should go away.
> >
> > Thank you for letting me know!
> > Cheers,
> > Matthias
> >
> > --
> > I welcome VSRE emails. See http://vsre.info/
> 
> 
> 
> -- 
> I welcome VSRE emails. See http://vsre.info/
> 

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Issue with appstream hints: severity missing for a tag?

[Raphael Hertzog]

Hello Matthias,

I recently opened my ow...@tracker.debian.org mailbox and I found
hundreds of errors:


Task UpdateAppStreamStatsTask failed with the following traceback.

KeyError
'asv-cid-contains-hyphen'

Traceback (most recent call last):
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/core/tasks/base.py", 
line 378, in run_task
task.execute()
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/core/tasks/base.py", 
line 256, in execute
call_methods_with_prefix(self, 'execute_')
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/core/utils/misc.py", 
line 44, in
call_methods_with_prefix
method(*args, **kwargs)
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 889,
in execute_main
self._load_appstream_hint_stats(component, arch, all_stats)
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 755,
in _load_appstream_hint_stats
severity = self._tag_severities[e['tag']]

Exception Type: KeyError
Exception Value: 'asv-cid-contains-hyphen'


Did you have any idea of what's wrong here? Is it a problem in the data
that you generate? Or is an update needed on tracker's side?

Thank you in advance!
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1060192: tracker.debian.org: SSL connection extremely slow and sometimes timing out

[Raphael Hertzog]

On Sun, 07 Jan 2024, Helge Kreutzmann wrote:
> Package: tracker.debian.org
> Severity: important
> 
> Yesterday and today connections to packages.debian.org is *extremely*

packages.debian.org is entirely unrelated to tracker.debian.org. It's
managed by the web team AFAIK.

That said if the issue was at the TLS connection level, it's likely
the DSA team that can help... but since the issue is gone, I wonder
whether we shouldn't just close the bug, in particular since the DSA
team doesn't use the bug tracker.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Appstream data not in UTF-8?

[Raphael Hertzog]

On Thu, 07 Dec 2023, Raphael Hertzog wrote:
> tracker.debian.org has been failing to import the appstream metadata for a
> while (since November 26th) with this exception:

Quick correction. The first time it failed that way was on November 19th
at 08:13 UTC.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Appstream data not in UTF-8?

[Raphael Hertzog]

Hello Matthias,

tracker.debian.org has been failing to import the appstream metadata for a
while (since November 26th) with this exception:

Task UpdateAppStreamStatsTask failed with the following traceback.

Traceback (most recent call last):
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/core/tasks/base.py", 
line 378, in run_task
task.execute()
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/core/tasks/base.py", 
line 256, in execute
call_methods_with_prefix(self, 'execute_')
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/core/utils/misc.py", 
line 44, in
call_methods_with_prefix
method(*args, **kwargs)
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 889,
in execute_main
self._load_appstream_hint_stats(component, arch, all_stats)
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/vendor/debian/tracker_tasks.py",
 line 728,
in _load_appstream_hint_stats
hints_json = get_resource_text(url, force_update=self.force_update)
  File 
"/srv/tracker.debian.org/distro-tracker/distro_tracker/core/utils/http.py", 
line 356, in
get_resource_text
return content.decode(encoding)

Exception Type: UnicodeDecodeError
Exception Value: 'utf-8' codec can't decode byte 0xcc in position 990416: 
invalid continuation byte
Request data not supplied


Can you look into this and fix the data? (the precise position of the
error in the stream varied over the days, here you have the position as of
today, December 7th 09:36 UTC)

This refers to those two lines:
url = 'https://appstream.debian.org/hints/sid/{}/Hints-{}.json.gz' \
  .format(section, arch)
hints_json = get_resource_text(url, force_update=self.force_update)

arch is "amd64", an section is likely "main" but it's not impossible that
it's in one of the other sections.

Thank you in advance for your help!
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Review of debusine's lintian related API

[Raphael Hertzog]

Hello Axel, Bastien, Lucas, and other members of the lintian and QA teams,

it's been a long time that I have been interested in building some
infrastructure to manage scheduling and distribution of Debian-related
build, QA and data collection tasks to a network of worker machines. I
called this project debusine:
https://salsa.debian.org/freexian-team/debusine/

It has been started a while ago but thanks to external funding, its
development pace is about to increase significantly. It is being developed
by Freexian with the intention of giving people access to a range of
pre-configured tools and workflows running on remote hardware.

We want to make it easy for Debian contributors to leverage all the great
QA tools that Debian provides. We want to improve and modernize Debian's
build infrastructure, while also enabling distribution-wide experiments,
custom package repositories and custom workflows with advanced package
reviews.

Analyzing lintian results is an important step in any serious package
review workflow and as such, our current milestone plans to make it
possible to run lintian on debusine workers. As lintian and QA experts, we
would love to have your feedback on our plans, in particular on the public
interface that we have designed.

To give a bit more context, as a debusine user with an API key, you can
submit "work requests". Each work request has a "task" assigned to it
(e.g. sbuild, autopkgtest, lintian) and some JSON data that gives more
details about the specific task. The structure of the JSON data varies
from task to task but it basically defines the public API that lets users
schedule work requests to debusine. The result of the work request
(including any artifact generated) will then be stored in the database and
made available for consumption by the user through the API.

As an example, here's how the data could look like for a simple lintian
work request:

{
"input": {
"source_artifact_id": 1234,  # References the source package to analyze
"binary_artifact_id": 1235,  # References the set of binary packages to 
analyze
},
"target_distribution": "debian:unstable",
"lintian_version": "2.116.3",  # Or minimal_lintian_version ?
"fail_on_severity": "error",
}

We are currently drafting the expected structure of that JSON data for
lintian (and autopkgtest) work requests in this merge request and we would
appreciate if you could review it:
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300

I have left some open questions in the document and there are some
unresolved review threads that have interesting questions too.

We are aware that this duplicates work made by Lucas in the context of
UDD, but we are trying to achieve a high level of integration and sharing
worker setups across different QA tools, and duplication seems unavoidable
in that context. We are certainly eager to cooperate and make it easy for
UDD and debusine to work hand-in-hand. A future milestone will make it
easier to export distribution-wide summary of data collected through such
work requests.

We plan to provide a debusine.debian.net/org instance accessible to all
Debian developers in the near future, so you will be able to experiment
and make use of the API that you will have helped to shape.

If you have questions about debusine, don't hesitate to ask. If you are
interested to follow along and/or help, you are more than welcome to:
https://freexian-team.pages.debian.net/debusine/devel/contributing.html

Have a nice day,
  Raphaël.

PS: You might find it useful to browse the documentation to learn more about the
goals and the high level concepts:
https://freexian-team.pages.debian.net/debusine/devel/why.html
https://freexian-team.pages.debian.net/debusine/design/index.html

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1040757: dose: (W)CudfAdd: package ncurses-base:amd64 (= 6.4-4) is not associate with an integer in the given universe

[Raphael Hertzog]

Hello Ralf,

Le samedi 15 juillet 2023, Ralf Treinen a écrit :
> In fact it is not related to dose-distcheck being outdated on quantz, I
> get the same error with dose-distcheck on sid.
> 
> Since I do not have time to dig further into this atm (leaving for vacation)
> I have now desactivated the unstable_main scenario, which is the only
> one where the error is occurring.

That scenario seems to be the one that tracker.debian.org relies on
to provide "debcheck" information. I have been getting failures in tracker
cron tasks:
requests.exceptions.HTTPError: 404 Client Error: Not Found for url: 
https://qa.debian.org/dose/debcheck/unstable_main/latest/each.txt

It would be nice if it could be revived. :) Do you have an idea when you
will be able to dig further? 

Cheers,
-- 
Raphaël Hertzog

Bug#1041523: tracker.debian.org: displays autopkgtest for other src:package on same page

[Raphael Hertzog]

Hello,

On Thu, 20 Jul 2023, Martin-Éric Racine wrote:
> The tracker at  shows autopkgtest 
> results for both this src:package and for another src:package.

I see no autopkgtest results at all. They are only shown when something
fails... and in that case, it only shows results of the current package.
Ex here:
https://tracker.debian.org/pkg/android-platform-frameworks-base

If you are referring to information shown in the "testing migrations"
panel, then I'm afraid that this is meant to replicate information output
by britney and it is expected that it shows autopkgtest results of reverse
dependencies.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1038121: tracker.debian.org: debian/patches check vs. single-debian-patch in debian/source/local-options

[Raphael Hertzog]

Hello,

On Thu, 15 Jun 2023, Thorsten Glaser wrote:
> Unsure if this is the right pseudopackage; if not, please reassign.
> 
> The “new” Debian tracker shows:
> 
>  debian/patches: 1 patch to forward upstream
> 
> The package however uses the single-debian-patch mechanism
> to let a diff be autogenerated from the patched source in
> VCS. This is therefore not a diff that could possibly be
> forwarded, and possibly contains Debian-local diffs only.
> 
> (This is basically using 3.0 (quilt) like 1.0, and very valid.)

The tracker uses data exported by UDD so I believe that it's up
to UDD to not mark that patch as to be forwarded... but UDD is doing
its analysis based on the pseudo-headers available in the patch.

So maybe it's dpkg-source that needs to be tweaked so that such patches
have a field "Forwarded: not-needed" and an explanation that the patch
is an auto-generated mess that can't be forwarded as is.

Can you name a sample package affected by this please?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1028615: tracker.debian.org: tracker.d.o should display results of reproducible rebuilds, not just reproducible CI results

[Raphael Hertzog]

Hello Holger,

On Fri, 14 Apr 2023, Holger Levsen wrote:
> On Fri, Jan 13, 2023 at 06:49:48PM +0100, Holger Levsen wrote:
> > since some years, tracker.d.o is thankfully showing results from
> > https://tests.reproducible-builds.org/debian - which was and is awesome!
> > However, these are just continious integration test results and
> > not based on the binaries we publish on ftp.debian.org
> [...]
> > The data is available in json format here:
> > - https://rebuild.notset.fr/debian/results/debian_unstable.json
> > - https://rebuild.notset.fr/debian/results/debian_bookworm.json
> > - https://rebuild.notset.fr/debian/results/debian_bullseye.json
> > It would be great, if tracker.d.o could display both kind of results, CI 
> > *and*
> > rebuild results.
> 
> friendly ping on this. Also if there's anything we can do...!?!

My bandwidth for tracker.debian.org is quite limited and it seems unlikely
that I will tackle this on my own. That said the codebase is rather
sane and it should not be too hard for someone else to implement this...

It has even become much simpler since I implemented the ImportExternalData
mixin that makes it easy to download json and create action items (cf
181db12111b35f9f54e5ed07654d34cff604feb3 as an example).

I would suggest to only import the data from unstable, or at least to
only generate action items for packages in unstable. 

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#1031780: tracker.debian.org: add information about patches

[Raphael Hertzog]

Hi Guillem & Holger,

On Sun, 26 Feb 2023, Guillem Jover wrote:
> The links for diaspora do not seem to be working though, as at least
> the «+» in the version string is not getting encoded, and UDD gives:

Duh, I forgot to urlencode the parameters, fixed. (That thought actually
popped up in my mind during my night... :-))

On Mon, 27 Feb 2023, Holger Levsen wrote:
> from #debian-qa a few minutes ago:
> 
> < h01ger> buxy: tracker.d.o/debian-edu-config says debian/patches: low
> < h01ger> Among the None debian patch available in version 2.12.31 of the 
> package, we noticed the following issues:
> < h01ger> while the package has no debian/patches/ ...

Fixed to properly skip packages using other source formats where UDD
puts "null" values in JSON instead of the 0 that the code expected.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1031780: tracker.debian.org: add information about patches

[Raphael Hertzog]

Hello Paul,

On Mon, 27 Feb 2023, Paul Wise wrote:
> On Sun, 2023-02-26 at 17:02 +0100, Raphael Hertzog wrote:
> 
> > I added the required support in tracker.debian.org
> 
> Personally I think we should replace the Ubuntu panel with a patches
> panel, as I have done for the old PTS some years ago:
> https://packages.qa.debian.org/g/glibc.html
> 
> This bug lists some ideas for doing that on the tracker:
> https://bugs.debian.org/779400

I don't find your nudges to be really helpful. One thing that could help
to motivate me to implement some of your many wishes would be to
officially stop the old PTS. It's been more than one year that I have
been getting daily cron errors from the old PTS and you claimed that you
would fix them and you didn't.

I hesitated more than once to declare it unmaintained and deactivate it
and setup redirects.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#1031780: tracker.debian.org: add information about patches

[Raphael Hertzog]

Hi,

On Wed, 22 Feb 2023, Lucas Nussbaum wrote:
> UDD now includes data about patches (see
> https://lists.debian.org/debian-qa/2023/01/msg2.html ). This data is
> already exposed on https://udd.debian.org/patches.cgi and
> https://udd.debian.org/dmd/ (see the Patches column in
> https://udd.debian.org/dmd/?email1=pkg-ruby-extras-maintainers%40lists.alioth.debian.org=html#bugs

Thank you for working on this. I'm glad someone implemented
it finally!

I added the required support in tracker.debian.org, you can see the
result:
https://tracker.debian.org/pkg/diaspora
https://tracker.debian.org/pkg/asciiart

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1030734: link to upstream bug tracker and repository

[Raphael Hertzog]

Hi,

On Sat, 25 Feb 2023, Jelmer Vernooij wrote:
> > FWIW, I don't plan to work on this (at least not in the short term) but
> > I'll happily review MR and answer questions.
> 
> I might spend some time on this, but would appreciate any further hints
> on where to add this if the information is available in UDD.

The first step would be to make this data available in a JSON file that we
can download from UDD. Lucas usually add some .cgi exporting the data
on request.

Then it's a matter of adding a Task that fetches the file and generates
whatever we want. I just implemented something similar adding links
for debian/patches metadata. So you could have a look at the approach taken
in 
https://salsa.debian.org/qa/distro-tracker/-/commit/181db12111b35f9f54e5ed07654d34cff604feb3

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1031393: tracker.debian.org: .dsc links to debian/pool/updates broken

[Raphael Hertzog]

Control: forcemerge 850409 -1

Hello,

On Thu, 16 Feb 2023, Holger Levsen wrote:
>  the links to the .dsc files for (at least) stable-sec and stable-p-u 
> on https://tracker.debian.org/pkg/spip are 404
>  yeah those paths are broken
>  debian/pool/updates isn't a thing
>  either debian/pool/{main,etc} or debian-security/pool/updates

I entirely forgot about it... it's actually a very old bug (cf #850409).

However, that bug would go away if the difference of path would no longer
exist between security.debian.org and the normal mirror.

Now that we use "bullseye-security" instead of "bullseyes/updates" why
are the Sources/Packages files still using "pool/updates/" instead of "pool/"?

I checked the Sources files on security.debian.org and it contains this:

Directory: pool/updates/main/s/spip

Both path are working because pool/{main,contrib,non-free} are symlinks
into updates/{main,contrib,non-free}.

Dear ftpmasters, can we change those paths in the "Directory" and
"Filename" fields to be coherent with the new naming scheme?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#1030734: link to upstream bug tracker and repository

[Raphael Hertzog]

Hello,

On Mon, 06 Feb 2023, Jelmer Vernooij wrote:
> A large number of Debian packages now has upstream metadata, including links 
> to
> upstream repositories (Repository-Browse) and bugtrackers (Bug-Database /
> Bug-Submit). Would it be possible to link to those from tracker?

It's of course possible but is there something already extracting all
those values and making them available in a convenient way? Maybe UDD?

Otherwise we first need to implement something like that which can be a
bit of a pain.

Usually the tracker fetches some external file and turns it into PackageData
entries that can then be easily displayed for example with a
LinksPanel.ItemProvider to add links in the "Links" panel on the right.

If we have to extract the upstream metadata on our own, then we should
modify distro_tracker/extract_source_files/ to extract it and add some
new Task to parse those files after they have been extracted (or do it
directly in extract_source_files but that would be a scope expansion for
that Django application).

FWIW, I don't plan to work on this (at least not in the short term) but
I'll happily review MR and answer questions.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1030748: tracker.debian.org doesn't display the correct linux kernel rc upstream version

[Raphael Hertzog]

Hello,

On Tue, 07 Feb 2023, xevilstar wrote:
> I have noticed that on https://tracker.debian.org/pkg/linux the new
> upstream version takes ages to update.

How long is "ages" for you?

> for example now it displays "A
> new upstream version is available: 6.2~rc6" while on 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> and
> https://kernel.org/
> the latest upstream rc version is mainline:   6.2-rc7 2023-02-05

The tracker is not responsible of detecting the new upstream releases.
It just uses information provided by UDD (Ultimate Debian Database).

But with >3 source packages to monitor, we're not able to verify new
releases each hour. It's a process that is spread over a longer period...

I'm ccing the UDD maintainer so that he can decide whether there's
something to be made here.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Lowering the barrier to entry/adoption and (mass) svn-to-git migration

[Raphael Hertzog]

Hello,

On Fri, 27 Jan 2023, Jelmer Vernooij wrote:
> I agree, I think anything that reduces the complexity of the ecosystem
> is great and the lowers the barrier for entry. As pretty anything uses
> Git now, I think migrating more things from SVN to Git would be great.

I will not forbid anyone to work on this but IMO the time to handle mass
migration is long past. Anything that still has subversion listed
in its VCS is effectively unmaintained.

If I were to take over one of those packages I would just use "gbp
import-dscs" to recreate some partial history based on snapshot.debian.org
and I would not put any more effort than this.

Even if I wanted to take care of all those packages as QA work to
increase their chance of someone taking over, I would do the same
and move the new repositories in the debian namespace.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Appstream hints no longer available

[Raphael Hertzog]

Hi,

On Sun, 08 Jan 2023, Matthias Klumpp wrote:
> Happy new year!

Best wishes to you too!

> > It looks like that the files required for the tracker.debian.org
> > integration have disappeared since mid-December. Can you add them back?
> > Shall I disable/remove the integration for now?
> 
> Eww! The problem is not the files disappearing, but them never having
> existed in the first place, since the "non-free-firmware" component is
> new.

Indeed. I sent my mail quite quickly and I didn't even realize that it
referred to the nem "non-free-firmware" section. Indeed I added that
section in the tracker config in mid-december...

> I've added it now via
> https://salsa.debian.org/pkgutopia-team/debian-asgen-config/-/commit/4382a6c3aece0eef0c6f2c05279d61aa667ab601
> , so this issue should resolve itself very soon!

Thank you!

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Appstream hints no longer available

[Raphael Hertzog]

Hello Matthias,

I recently opened my ow...@tracker.debian.org mailbox and I found
hundreds of errors:


Task UpdateAppStreamStatsTask failed with the following traceback.

HTTPError
404 Client Error: Not Found for url:
https://appstream.debian.org/hints/sid/non-free-firmware/Hints-amd64.json.gz


It looks like that the files required for the tracker.debian.org
integration have disappeared since mid-December. Can you add them back?
Shall I disable/remove the integration for now?

Thank you in advance!
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1021728: tracker.debian.org: Please include the new "non-free-firmware" section

[Raphael Hertzog]

Hello Gunnar,

On Thu, 13 Oct 2022, Gunnar Wolf wrote:
> Last week I uploaded raspi-firmware to non-free-firmware (and was
> promptly processed through NEW, whee!).
> 
> Two days ago, it successfully migrated to Texting.
> 
> I am now building the Raspberry Pi images for Bookworm , and
> raspi-firmware is correctly downloaded from non-free-firmware.
> 
> However, tracker.debian.org misleadingly shows the package as if it
> was removed from Debian («package is gone. This package is not in any
> development repository. (...)», and no longer lists it for testing and
> unstable.

Please update me on the official plans... will this section be entirely
disjoint from non-free? Or will packages from non-free-firmware also
appear in non-free?

Will we move all firmwares from non-free in that new section before
the release of bookworm?

In any case, I have tweaked the configuration of tracker.debian.org
so that it knows (and monitors) that new section in
bookworm/sid/experimental at this point. Hopefully that should
be sufficient to fix this initial issue. We will have to monitor this
for other possible side-effects.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: Debian Package Tracker not updating?

[Raphael Hertzog]

Hello,

On Wed, 14 Dec 2022, Holger Levsen wrote:
> On Wed, Dec 14, 2022 at 11:31:29AM -0500, Scott Talbert wrote:
> > Yes, that's exactly the problem.
> 
> https://bugs.debian.org/1026049 is about the same issue.

the cron job that updates everything has been stuck since December 10th. I
killed it and I restarted it.

Sorry for the delay.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Revival of lintian.d.o (sort of)

[Raphael Hertzog]

Hello Lucas,

On Sun, 03 Jul 2022, Lucas Nussbaum wrote:
> Seeing that lintian got adopted, I got motivated into looking if I could
> help on the lintian.d.o side, that is, provide up-to-date archive-wide
> up to date to developers.

Thanks for working on this!

> Since the architecture of lintian.d.o seemed quite complicated, I
> instead decided to follow what worked for other UDD-based data importers
> (such as the one that scans for new upstream versions). So my plan is
> the following:
> - use a UDD postgresql table for data storage
> - use UDD to decide which packages need to be analyzed
> - coordinate the analysis from UDD, but do the analysis itself on a
>   third-party 'worker' machine (since the process is quite CPU intensive)
> - provide visualisation directly on https://udd.debian.org (similar
>   to https://udd.debian.org/dmd/ or https://udd.debian.org/bugs/)
> - work with data consumers on how to best export the data from UDD to
>   them
> 
> I know it feels a bit like NIH, but I believe the simpler design will
> help in the long term...

At least it helps to have something running in the short term. But there
are really parts that I'd like to move to something more standardized
that we can use for multiple tasks in the context of Debian.

Paul already hinted at it but debusine is clearly meant to help with:
- scheduling tasks
- running tasks on multiple workers

https://salsa.debian.org/freexian-team/debusine/

At this point, debusine is not doing much yet but I hope that we have laid
out some good initial architecture to be able to share the workload on
multiple workers. Currently the only "Task" that it knows how to run
is "sbuild" and we don't have any data storage yet (i.e. the generated
artifacts are not stored anywhere, it's up to the caller to pass some
--post-build-commands to make something with the result).

Storing data is the next milestone that we will work on.

Maybe it's a bit early to try to use it for your use case, but if you want
to give it a try, you are more than welcome to. Feel free to open tickets
and ask questions too.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1004256: messages to dispatch+aide_cont...@tracker.debian.org get multiplied

[Raphael Hertzog]

Hi,

On Sun, 23 Jan 2022, Marc Haber wrote:
> I regularly use pack...@packages.debian.org as Maintainer address for my
> packages. Having an implicit mailing list for package maintenance issues
> is extremele helpful and I appreciate that features.
> 
> Since a few weeks, messages to those addresses get multiplied inside the
> tracker, namely ticharich.debian.org, between five and ten times. I see
> this, and other members of the teams I am on see it as well.

This was due to a subscriber of the aide package being known under two
different emails varying only on the case. I don't know how this happened
because all the code should identify emails case-insensitively and not
create a second instance of the same email.

The email sending code assumes that we have a single UserEmail object
associated and it raises an exception when it tries to send the mail to
that address. Thus the email to forward was stuck in the "temporary failure"
case and was retried a few times until giving up, hence the multiple
copies for the the other subscribers.

Let me know if the problem persists. I will leave the ticket open to
remind me to improve the code to cope with the multiple unexpected
UserEmail objects for a single email...

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1002458: "version in VCS newer than in repository" might be a bit overzealous

[Raphael Hertzog]

On Mon, 27 Dec 2021, Christoph Berg wrote:
> Re: Raphael Hertzog
> > Christoph, would it be possible to export a supplementary flag showing
> > when the changes in NEW or COMMITS contain only changes to
> > debian/changelog?
> 
> The proper first step is to change "plz upload now" to a more neutral
> "there are pending changes in VCS".

It's phrased as question, not as you say. And I can certainly change the
wording but then it's no longer an "action item" and I find it hard to
keep the entry in its current place. Thus I prefer to restrict the cases
where we show it, rather than entirely changing the wording.

For your request, maybe we should add some NEW flag near the VCS entry in
the left panel, just informing that there are changes in the VCS and not
asking any specific action.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1002462: "build log checks report 1 warning" dated a year and 9 uploads ago

[Raphael Hertzog]

Hi,

On Wed, 22 Dec 2021, Marc Haber wrote:
> for sudo, on https://tracker.debian.org/pkg/sudo, I see an "action
> needed" Build log checks report 1 warning". This warning is shown as
> having been created on 2020-12-21, while the link points to build logs
> from last week. Is this intended?

Yes, each action item has a date of creation and a date of last update.
Its content is regularly refreshed as long as the action item persists.

> And, the link points to build issues for non-release archs, and it looks
> like there is nothing that the package can do to make the issue go away
> (or I am too stupid, why don't the issues don't surface for release
> arches?).

On the tracker side, I only get a count of issues:
https://qa.debian.org/bls/logcheck.txt

I use the first 3 fields as name, errors and warnings.

There's no distinction between release architecture and non-release
architecture.

> While I agree that it is important to make things easy for non-release
> arches, showing issues that a package cannot do anything about and that
> only appear for non-release arches in the package tracker might be a bit
> over the top. It masks away issues that are occurring in release arches.
> 
> In the current form, this action item is not helpful for a mere package
> maintainer who has not the deepest insight into Debian's QA processes.

I would argue that this should be fixed on the "bls" side.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1002461: actions needed should show affected version

[Raphael Hertzog]

Hi,

On Wed, 22 Dec 2021, Marc Haber wrote:
> in sudo's tracker page, I see that lintian reports 29 errors and 5
> warnings. The link leads me to https://lintian.debian.org/sources/sudo
> which tells me that the linan reports are from vresion 1.9.6-1~exp2 and
> the lintian run was a month ago.
> 
> Maybe it would be a good idea to show in the expanded pane of the action
> item which version of the package was used to create this item so that
> one can immediately see that this might be obsolete information.

Yeah, but it would be even better if lintian provided up-to-date data.
The tracker only fetches this file:
https://lintian.debian.org/static/qa-list.txt

And it doesn't have those information to show.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1002458: "version in VCS newer than in repository" might be a bit overzealous

[Raphael Hertzog]

Hi,

On Wed, 22 Dec 2021, Marc Haber wrote:
> when I upload a package (for example, foo 1.0-1), I immediately create a
> new changelog stanza for a new version foo 1.0.2~1 so that noone
> accidentally makes a commit that might end up in the changelog for the
> already-uploaded version 1.0-1.
> 
> This causes the tracker to always show the "version in VCS is newer than
> in repository, is it time to upload?" hint for all my packages.
> 
> I'd therefore like to be able to either switch this "action needed" item
> off, or it to be smarter, for example by ignoring commits that only
> touch the changelog.

The package tracker uses the vcswatch data at
https://qa.debian.org/data/vcswatch/vcswatch.json.gz and it doesn't
provide me this data AFAIK.

Christoph, would it be possible to export a supplementary flag showing
when the changes in NEW or COMMITS contain only changes to
debian/changelog?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1001190: tracker.debian.org: news: emails: show Message-ID header, link to lists.d.o/msgid-search

[Raphael Hertzog]

Hi,

On Tue, 07 Dec 2021, Paul Wise wrote:
> Not necessarily, there are several options for this that would make it
> a very generic feature, some ideas:
> 
> When the List-Archive header exists and contains a URL, the link could
> be to that URL. This works for Debian lists and mailman lists and
> probably other types of lists too.

The tracker doesn't receive emails via mailing lists, it gets sent a
direct copy from the various services.

> distro-tracker could have a list of domains that are known to have
> Message-ID search URLs and then map the List-Id to those URLs.

What's the "domain" of an email message? The one from the sender?

> For domains that have no Message-ID search URLs but do have archive
> links for the Maintainer field, the link could be to just the top-level
> archive link used for the Maintainer field.

I don't see how this can be helpful if you have to look up the message on
your own.

> Once #1001254 is implemented, then the link could be to the DPT
> Message-ID search, in a similar way to how lists.d.o links to its
> Message-ID search from the Message-ID field in its archives.

This, however, is something that is clearly more in line with the logic
of distro tracker. I agree that a query to lookup a message-id could be
useful.

(And actually I am interested in tracking message-id of everything that
went through distro-tracker to be able to drop duplicates easily and/or
present other summary views to the respective maintainers)

> I think the options I presented above are generic enough to have a low
> enough cost. For cases not covered by them I think as a compromise, it
> would be reasonable to just show the Message-ID header with no link.

This is also reasonable, indeed.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#1001190: tracker.debian.org: news: emails: show Message-ID header, link to lists.d.o/msgid-search

[Raphael Hertzog]

Hi,

On Mon, 06 Dec 2021, Paul Wise wrote:
> In the news emails, please show the Message-ID header and make the
> value inside the angled brackets <> a link to the Debian lists
> msgid-search. For example [1] should link to [2].
> 
>    1. 
> https://tracker.debian.org/news/1284147/accepted-purple-discord-0920211124gitde899b3-1-source-into-unstable/
>    2. 
> https://lists.debian.org/msgid-search/e1mu1fi-0006i4...@fasolo.debian.org
> 
> This would be useful when doing an upload and then wanting a link to
> the mail about it for copying into blog posts or work reports etc.

Why do you want a lists.debian.org link when you already have a
tracker.debian.org link pointing to the same content?

Also there's no guaranty that all news are properly recorded in a Debian
mailing lists. I assume testing migration mails aren't for example.

And this would be a feature that is really specific to Debian too, while
the news feature is very generic and cleanly mixing both would require
again some abstraction to add a vendor-specific behaviour in a generic
part.

In short, I find the cost really high for a relatively small value added.

Regards,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#993678: Fails to produce PDF output when using scale.by.width - produces broken lstlisting/lstcode options

[Raphael Hertzog]

Control: tags -1 + patch

Le samedi 04 septembre 2021, Daniel Leidert a écrit :
> While building a PDF we stumbled upon an issue. Some of our XML files contain
> screen elements with non UTF-8 characters. When we enable scaling for listing
> elements:
> 
> scale.by.width
> 
> dblatex fails. The produced .tex files then contain line such as:
> 
> \begin{lstcode}[escapeinside={<:}{:>}][scale=false,firstnumber=1,escapeinside={}{},moredelim={**[is][\bfseries]{}{}},moredelim={**[is][\itshape]{}{}},]

Upstream has provided a patch in 
https://sourceforge.net/p/dblatex/bugs/_discuss/thread/6efb34bd22/7a8a/attachment/rawverb.patch

Can you test it and report back whether it helps? If you can send your
feedback directly to upstream that would be great:
https://sourceforge.net/p/dblatex/bugs/129/

Thank you in advance.
-- 
Raphaël Hertzog

Bug#993678: Fails to produce PDF output when using scale.by.width - produces broken lstlisting/lstcode options

[Raphael Hertzog]

Control: forwarded -1 https://sourceforge.net/p/dblatex/bugs/129/

Hello,

I have forwarded this bug to the upstream bug tracker and I pinged
the upstream author by email to try to draw his attention to this issue.

Cheers,
-- 
Raphaël Hertzog

Re: Bug#960154: Feed UDD with just-in-time packaging hints from Lintian

[Raphael Hertzog]

Hi,

On Wed, 14 Apr 2021, Lucas Nussbaum wrote:
> I think that in Debian, we would aim for a better separation between:
> 
> A/ QA tools development, focused on getting the good tools to analyze
> packages (output: tools, as Debian packages)
> 
> B/ infrastructure that mass-process the archive using QA tools. (output:
> current status of each package in Debian, analyzed with the latest
> version of a given tool, as a parsable file)
> 
> C/ infrastructure that gathers the current status from all instances of
> (B) and exposes it per-package, per-maintainer, per-team, etc.
> 
> (C) could even be split into:
>   (C.1) infrastructure that gathers the status and stores it into a
>   common DB;
>   (C.2) infrastructure that uses (C.1) to provide useful
>   per-package/per-maintainer frontends (views).

Fully agreed on this. tracker.debian.org is clearly in the scope
of (C) but started to move into (B), but once I realized this I decided
that it would be better to have a separate project, that's how I ended
up designing "debusine".

See 
https://salsa.debian.org/freexian-team/debusine/-/blob/master/docs/devel/why.rst

As I announced a few days ago, I will invest Freexian's money
in this project so you're welcome to watch the project (in gitlab speak,
aka enable notifications) so that you can contribute to its design.

The first milestone will be oriented towards package building,
not lintian processing but I'm happy to include this in the roadmap
at some point.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Contribute to debusine's design

[Raphael Hertzog]

Hello,

some of you might have already heard of "debusine". It aims to be
a software factory tailored for the needs of Debian. At some point,
it might become a replacement for wanna-build and the buildd, it might
also be useful to run archive wide QA tasks (hence the two lists
debian-qa@lists.debian.org and debian-wb-t...@lists.debian.org).

So far, debusine only existed as a concept with some initial design ideas
but Freexian will invest resources to turn this into something real. I
would love if debusine could become really useful for Debian so I'd like
you to join the design discussions that we will soon have so that you can
chime in and share your experiences, your needs, etc.

This will happen in the salsa project so please watch the project if you
want to follow along and ensure it can meet your needs:
https://salsa.debian.org/freexian-team/debusine 

Cheers,

PS: It looks like salsa has some issues[1] with the "pages" hosting so the
documentation links are broken, you should look into the git repository
directly or through the latest artifact:
https://salsa.debian.org/freexian-team/debusine/-/tree/master/docs
https://freexian-team.pages.debian.net/-/debusine/-/jobs/1573081/artifacts/public/index.html

[1] https://salsa.debian.org/salsa/support/-/issues/256
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: 1.0 format with direct changes in diff (Was: Debian Trends updated)

[Raphael Hertzog]

On Fri, 09 Apr 2021, Raphael Hertzog wrote:
> "debian-single-patch" option (that you can put in debian/source/options)

"single-debian-patch", sorry

https://manpages.debian.org/buster/dpkg-dev/dpkg-source.1.en.html#Format:_3.0_(quilt)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: 1.0 format with direct changes in diff (Was: Debian Trends updated)

[Raphael Hertzog]

Hello,

On Thu, 08 Apr 2021, Bastian Blank wrote:
> How do you export changes?  And no, creating separate patches breaks as
> soon as the history is not linear, like after merging a new upstream
> release.  Sure, you could rease, but that is not an automatic process.

As Mattia pointed out, the "3.0 (quilt)" format supports the
"debian-single-patch" option (that you can put in debian/source/options)
which makes it behave like source format 1.0 and auto-generates/updates a
single patch in the series based on the changes you made compared to
upstream.

I don't think there's a valid technical reason to not use a newer format.
Some dislike the choices made and the fact that many new features are
coupled to the new format, but there's really nothing that you could do
with the old format than you can't do now with new ones.

(Except using a version with a Debian revision with a native package)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#984999: sso.debian.org is deprecated

[Raphael Hertzog]

Hi,

On Fri, 12 Mar 2021, Mattia Rizzolo wrote:
> Incidentally, the fact that the salsa admins decided to not force
> account names with -guest anymore, also means that you can't easily
> associate salsa accounts to DDs anymore, and AFAIK there is no good way
> to establish that as of now (the nm API is not publicly advertising the
> salsa accounts details of DDs ATM (that's part of a private API for
> salsa only though), and of course the salsa admins don't fancy patching
> gitlab to expose that detail).
> So, even if you implemented the above thing, associating everybody's
> salsa "identities" to their already existing tracker.d.o accounts would
> prove incredibly difficult.  Good luck.

Actually, tracker.debian.org is very much e-mail centric. Does signon
return a list of authenticated emails associated to the identity ?

And tracker.debian.org has currently no special privileges for Debian
developers... except that when you have a debian.org email, you are
forced to use the SSO (IIRC).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#984999: sso.debian.org is deprecated

[Raphael Hertzog]

Hi,

On Thu, 11 Mar 2021, Antoine Beaupre wrote:
> According to the sso.debian.org wiki page, the service is
> "deprecated":
> 
> > If you are a service admin please look into using Salsa for this
> > purpose. 
> 
> It seems to me that tracker.debian.org should follow this deprecation
> and stop using sso.debian.org as a single sign on source, especially
> now that Firefox in stable (78, buster) does not support the 
> tag (dropped from Firefox 69) which makes enrolling client certs
> particularly painful.

Yeah, but I don't see a reason to disable this until someone has
contributed OIDC authentication with salsa.debian.org.

I haven't even looked at what it entails. We don't seem to have
pyoidc in Debian (https://github.com/rohe/pyoidc) and I don't see
any other Python implementation.

I wonder what nm.debian.org uses for this.

> Apparently, you can still generate client-sides certs with "web
> crypto", whatever that means... But that's kind of out of scope here. 

I managed to renew my certificate by following the instructions
on sso.debian.org at least.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#981910: tracker.debian.org: please display key status for packages

[Raphael Hertzog]

Hi,

On Fri, 05 Feb 2021, Carles Pina i Estany wrote:
> I'm a bit new in the internals of tracker and around. Would this be the
> best source for the list of "key" packages?
> https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

Yes, since it's referenced from the release team web page:
https://release.debian.org/

FWIW this is cleary a Debian specific feature so would have to
be implemented in distro_tracker/vendor/debian/ in some way.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#981241: tracker.debian.org: please update uscan

[Raphael Hertzog]

Hello,

On Thu, 28 Jan 2021, Paolo Greppi wrote:
> For yarnpkg: https://tracker.debian.org/pkg/node-yarnpkg
> tracker.debian.org reports:
> 
>   uscan had problems while searching for a new upstream version:
>   unrecognized option ctype=nodejs
> 
> The option was added with devscripts 2.20.5:
> https://lists.debian.org/debian-perl/2020/11/msg00047.html
> 
> Please upgrade devscripts so that uscan works reliably for packages that use 
> the option.

tracker.debian.org relies on the information exported by UDD here:
https://udd.debian.org/cgi-bin/upstream-status.json.cgi

So this needs to be fixed on the UDD side. Putting Lucas in copy.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Re: (fwd) Debian Mailing lists ...

[Raphael Hertzog]

Hello Hanno & Mag,

I double checked and I confirm that m...@bloss.io was the email used by
the package tracker. But that email is no longer subscribed to any package
right now.

mag.nils...@bloss.io is entirely unknown to the package tracker.

Regards,

On Wed, 09 Dec 2020, Hanno 'Rince' Wagner wrote:
> Hi everybody,
> 
> Mag contacted us listmasters since he is unable to unsubscribe from
> the tracker-System. As far as I can see he is using the mailaddress
> m...@bloss.io for the subscription, but he claims that mailaddress is
> invalid.
> 
> Can you help him check his subscriptions and - if needed - unsubscribe
> him?
> 
> best regards, Hanno Wagner, Listmaster of the day
> -- 
> |  Hanno Wagner  | Member of the HTML Writers Guild  | Rince@IRC  |
> | Eine gewerbliche Nutzung meiner Email-Adressen ist nicht gestattet! |
> | 74 a3 53 cc 0b 19 - we did it!  |Generation @   |
> #"Windows'95 ist ein Schoenwetterbetriebssystem - das sieht man
> # schon an der Packung. Aber was ist, wenn es durch die 95 offenen
> # Fenster hereinregnet?"

> Date: Wed, 9 Dec 2020 13:34:44 +0800
> From: Mag Nilsson 
> To: Alexander Wirt 
> Cc: listmas...@lists.debian.org
> Subject: Debian Mailing lists ...
> X-Mailer: Apple Mail (2.3445.104.17)
> Message-Id: 
> 
> Hi Alex,
> 
> Thanks for helping out yesterday.
> 
> Frustratingly, this is still occurring:
> 
> This arrived today.
> 

> Date: Wed, 09 Dec 2020 04:39:06 +
> From: Debian testing watch 
> To: gnome-sh...@packages.debian.org
> Subject: gnome-shell 3.38.2-1 MIGRATED to testing
> Message-Id: 
> 
> FYI: The status of the gnome-shell source package
> in Debian's testing distribution has changed.
> 
>   Previous version: 3.38.1-2
>   Current version:  3.38.2-1
> 
> -- 
> This email is automatically generated once a day.  As the installation of
> new packages into testing happens multiple times a day you will receive
> later changes on the next day.
> See https://release.debian.org/testing-watch/ for more information.

> 
> 
> At the bottom of the the raw header, it says:
> 
> “List-Unsubscribe: 
> "
> 
> If I do that mailto: , I get this:
> 

> Date: Wed, 09 Dec 2020 05:27:30 -
> From: ow...@tracker.debian.org
> To: Mag Nilsson 
> Subject: Re: Your mail
> Message-ID: <160749165022.9552.6466151069949655...@ticharich.debian.org>
> 
> > unsubscribe gnome-shell
> Error: mag.nils...@bloss.io is not subscribed, you can't unsubscribe.

> 
> 
> Looks like I can never unsubscribe …..
> 
> M.



-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#974344: don't display "Debci reports failed tests" for outdated package versions

[Raphael Hertzog]

Hi,

On Wed, 11 Nov 2020, Matthias Klose wrote:
> https://tracker.debian.org/pkg/bambam shows failed tests, and following the 
> link
> shows:
>unstable   testingstable
> amd64  1.0.1+dfsg-1 fail  1.0.2+dfsg-2 pass  No test data
> 
> The test result for the unstable test is out-of-date. Accoding to #debci, the
> reason for the outdated test is:
> 
>  doko: because that's the latest test result available; if britney
> didn't schedule a "pure unstable" test, then you don't get one. due to 
> capacity
> limitations we stopped scheduling pure unstable tests automatically
> 
> In this case, the tracker should not display the link to the failed tests.

Right we should filter out results that do not apply to the latest version
in each suite.

If anyone wants to have a look, it's in
distro_tracker/debci_status/tracker_tasks.py (in
UpdateDebciStatusTask.update_action_item and/or execute_main).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#973277: tracker.debian.org: Please provide the relevant links to debcheck

[Raphael Hertzog]

Control: reassign -1 release.debian.org
Control: retitle -1 britney should indicate the unsatisfiable dependency

On Wed, 28 Oct 2020, handsome_feng wrote:
> My package ukui-system-monitor blocked when testing migrations, and the 
> excuses
> only says ukui-system-monitor/ppc64el has unsatisfiable dependency, without
> specific error messages, and I asked it on #debian-mentors to get that the
> actual problem is on
> https://qa.debian.org/debcheck.php?dist=unstable=ukui-system-monitor.
> 
> So, I think it is better for tracker to include the relevant links to 
> debcheck?

The tracker is just an intermediary here, it displays the output of the
britney tool. Thus that ought to be fixed at the britney level.
When britney says "ukui-system-monitor/ppc64el has unsatisfiable
dependency" it should say which dependency is unsatisfiable.

And if this appears in the excuses output, then the package tracker will
also display it.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#967086: Empty pages when authenticated

[Raphael Hertzog]

On Thu, 06 Aug 2020, Stéphane Glondu wrote:
> Le 05/08/2020 à 14:36, Raphael Hertzog a écrit :
> >> tracker.debian.org does not seem to respond or responds always empty
> >> pages (no error) when I use a client certificate.
> > 
> > I don't have the issue with my own certificate.
> > 
> > I see this in the error log:
> > [Wed Aug 05 11:17:05.798925 2020] [ssl:error] [pid 31979:tid 
> > 140564909500160] [client 80.227.5.106:40019] AH02039: Certificate 
> > Verification: Error (66): EE certificate key too weak
> > [Wed Aug 05 11:59:09.029731 2020] [ssl:error] [pid 31979:tid 
> > 140565890987776] [client 80.227.5.106:9418] AH02039: Certificate 
> > Verification: Error (66): EE certificate key too weak
> 
> This is not my IP address.

Looking at your mail headers, I found 152.81.9.54 and I got similar logs:
hertzog@ticharich:~$ grep 152.81.9.54 
/var/log/apache2/tracker.debian.org-error.log
[Thu Aug 06 07:57:16.520838 2020] [ssl:error] [pid 29597:tid 140564724860672] 
[client 152.81.9.54:55460] AH02039: Certificate Verification: Error (66): EE 
certificate key too weak
[Thu Aug 06 07:57:48.093622 2020] [ssl:error] [pid 29597:tid 140564909500160] 
[client 152.81.9.54:55462] AH02039: Certificate Verification: Error (10): 
certificate has expired

> When I first encountered the error, I realised my certificate was
> expired. Then, I generated a new certificate. I still get the
> undesirable behaviour with the new certificate.

I'm not sure what else I can do to help you here. I'm putting DSA in copy
in case they know what's going on here. I never had such an issue.

Did you drop you old certificate and restart your browser?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#967086: Empty pages when authenticated

[Raphael Hertzog]

Hi,

On Tue, 04 Aug 2020, Stéphane Glondu wrote:
> tracker.debian.org does not seem to respond or responds always empty
> pages (no error) when I use a client certificate.

I don't have the issue with my own certificate.

I see this in the error log:
[Wed Aug 05 11:17:05.798925 2020] [ssl:error] [pid 31979:tid 140564909500160] 
[client 80.227.5.106:40019] AH02039: Certificate Verification: Error (66): EE 
certificate key too weak
[Wed Aug 05 11:59:09.029731 2020] [ssl:error] [pid 31979:tid 140565890987776] 
[client 80.227.5.106:9418] AH02039: Certificate Verification: Error (66): EE 
certificate key too weak

So maybe get a new certificate?

I don't think that I can change anything in the configuration on my side.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#963887: UDD: 'duck' importer broken since 2020-05-25

[Raphael Hertzog]

On Mon, 29 Jun 2020, Baptiste BEAUPLAT wrote:
> > Indeed, creating a dedicated service for this does not seem a good idea.
> 
> I would love to have this feature integrated directly with
> distro-tracker. However, I'm wondering about the load that would case
> for the service.

Network request do not generate much "load", such processes spend the bulk
of their time waiting on the network.

> The duck worker has to process around 46 urls (only counting
> Homepage) in less than 24h.

How do you get to that figure? We don't have that many source package
and even if you consider multiple URL for each source package due to
changes over time (in multiple releases), that makes way too many URLs
per source package.

> I'm not sure that can done properly using
> the distro-tracker tasks (parallel workers are needed to work around
> timeout). Obviously that can be optimized (different check delay for
> different results) but that's still bulk network related tasks.

Nothing forbids parallel workers and in any case, I welcome any
improvement to the task mechanism to make that kind of parallelism easier
to handle.

There are other tasks that could benefit from this (and in general I want
to merge more of such features in distro-tracker to make them available to
derivatives too).

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#963887: UDD: 'duck' importer broken since 2020-05-25

[Raphael Hertzog]

Hi,

On Sun, 28 Jun 2020, Bastian Blank wrote:
> > Baptiste (CCed) volunteered to write it over again, but for now there is
> > no clear timeline as for when the new project will be started.
> 
> Maybe you could add that to vcswatch?

or distro-tracker?

Indeed, creating a dedicated service for this does not seem a good idea.

https://qa.pages.debian.net/distro-tracker/contributing.html
https://qa.pages.debian.net/distro-tracker/devel/design.html#tasks-framework

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#962000: Duplicated news for php-horde-image

[Raphael Hertzog]

Control: forcemerge 884933 -1

On Mon, 01 Jun 2020, s3v wrote:
> I have noticed that tracker.debian.org reports duplicated news for
> php-horde-image package [1] and others packages in php-horde ecosystem
> (php-horde-data, php-horde-cache, php-horde-crypt, et al.).

This was already documented in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884933
but I pushed some improvement in git that should only generate the news for
the email that we just received (and not for all packages that we can
identify within the mail).

And since dak should be smarter nowadays (#884931 is fixed), this should be 
fixed.

I must still do something to get rid of old duplicate news items.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#959931: qa.debian.org: udd.debian.org/dmd no more able to display HTML report

[Raphael Hertzog]

Hi,

On Wed, 13 May 2020, Xavier wrote:
> can someone take a look to this issue ? It becomes difficult to manage
> JS Team package without having a view on what to do

I can suggest an alternative which is working fine:
https://tracker.debian.org/teams/debian-javascript/

:-)

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#819136: Bugs included in #819136 patches

[Raphael Hertzog]

Hello,

On Fri, 09 Jun 2017, Elliott Mitchell wrote:
> Guess I should give at least a partial list of the extra bugfixes
> included in the #819136 patch series:

I was looking at bugs with patchs and saw this one. I believe most of the
patches are obsolete, the only thing that should remain is the part where
you try to generate a separate .deb.

Are we actually allowed to build a .deb and distribute the firmware
directly in a .deb? I haven't checked but I guess that it's "no",
otherwise we would likely ship the firmware ourselves in non-free...

I saw you contributed regularly to the package. What about getting a salsa
account and taking over package maintenance?

In any case, an update on this bug would be appreciated.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#955339: tracker.debian.org: improper bounce-process

[Raphael Hertzog]

Hello Tom,

On Mon, 30 Mar 2020, Thomas Dickey wrote:
>* yesterday, I received multiple messages from ow...@tracker.debian.org
>  notifying me that my subscription was cancelled.

I saw them.

>* on the next activity (a followup for byacc) I _immediately_ received 
> again
>  multiple messages, cancelling all subscriptions.

Meaning that all the messages sent to you triggered a bounce over multiple
days. We have a system that is tolerant for occasional bounces but not for
systematic bounces.

>* None of the messages provide useful information, aside from a summary
>  message which lists the URLs which were cancelled.
> 
>  Other than that, there's no indication on why the bounces were triggered,
>  nor any discernable way to repair the problem.

Yes, there's no such feature. You're welcome to submit merge request
implementing the desired behaviour.

As far as you are concerned, here's a sample bounce that you are
generating. As long as you will be generating such bounces, there's
no point in trying to subscribe again.


This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  tom@localhost


Reporting-MTA: dns; prl-debianold-64.jexium-island.net

Action: failed
Final-Recipient: rfc822;tom@localhost
Status: 5.0.0


Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#955213: Version information on tracker.d.o in many cases wrong

[Raphael Hertzog]

Control: forcemerge 901500 -1

On Sun, 29 Mar 2020, Daniel Leidert wrote:
> Today I found several packages for which the version and release information 
> is
> completely wrong. rmadison and the tracker report different releases for the
> same versions. Examples:
> 
> ruby-capistrano-colors
> ruby-cal-heatmap-rails
> ruby-algorithm-diff
> ruby-albino
> 
> I'll probably find more. But this looks like a general issue...?

It's a general issue affecting packages that have been removed from
Debian or from a subset of releases.

Notice how the pages that you linked indicate that "Package is gone" from
unstable.

There's also #948244 and #901500 that are related. I don't think that your
bug is reporting anything new. bershelf is case of #901500 and those
above are a case of #948244 AFAIK.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: distro-tracker quick-setup failed

[Raphael Hertzog]

On Sun, 23 Feb 2020, Steven Robbins wrote:
> On Sunday, February 23, 2020 2:23:14 A.M. CST Raphael Hertzog wrote:
> 
> > In the mean time, we should possibly update the documentation to explain
> > that the quick setup is broken. Willing to submit a MR for this?
> 
> What should the documentation suggest to do after ignoring the
> error in quick-setup.sh?

Actually the documentation already covers the manual setup. In the same
bullet point it says:
> If you have more time and want to learn more about the configuration of
> distro tracker, follow the steps in the sections Setting up Distro
> Tracker and Setting up the package repositories.

The two links in that paragraph are relevant.

What you are lacking after the failed quick-setup.sh is:
- "./manage.py migrate" to create the database
- "./manage.py loaddata distro_tracker/core/fixtures/debian-repositories.xml" to
  configure the package repositories to monitor
- "./manage.py tracker_update_repositories" to scan the repositories and
  add packages. This is the minimum if you want to have packages
  available. But there are many more things that you will be lacking
  if you do only this. If you want everything, you should instead
  run "./manage.py tracker_run_all_tasks".

> In my case, I have a Debian Package Tracker instance on my local machine, but 
> I don't know what to do with it now.  There is a package search box, but I 
> haven't been able to find any packages.
> 
> Maybe it would be better to instead disable downloading the database?

Yes, and (propose to) run the above steps instead...

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: distro-tracker quick-setup failed

[Raphael Hertzog]

Hi,

On Sat, 22 Feb 2020, Steven Robbins wrote:
> >>> Downloading a pre-built sample database file
> Traceback (most recent call last):
>   File "bin/sample-database-url", line 20, in 
> download_url = td.parent.findChild('a', class_='btn-build')['href']
> TypeError: 'NoneType' object is not subscriptable

The generation of the pre-built database has been broken for a while due
to new limits imposed by the salsa admins. The jobs is failing because it
takes more than 3 hours:
https://salsa.debian.org/qa/distro-tracker/pipelines
https://salsa.debian.org/qa/distro-tracker/-/jobs/575655

We should look into running it from some alternate place or find way to
optimize the execution time.

In the mean time, we should possibly update the documentation to explain
that the quick setup is broken. Willing to submit a MR for this?

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: duck.debian.net down

[Raphael Hertzog]

Ping ? I still have failures on my side (and I get a mail every 30
minutes...).

Cheers,

On Tue, 21 Jan 2020, Raphael Hertzog wrote:
> Hi,
> 
> On Sun, 19 Jan 2020, Simon Kainz wrote:
> > thanks for the ping - it seems we have some uplink issues at work. Will
> > report back on monday.
> 
> What's up? I still get failures from distro-tracker.
> 
> Cheers,
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
>   ⣾⠁⢠⠒⠀⣿⡁
>   ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
>   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS



-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: duck.debian.net down

[Raphael Hertzog]

Hi,

On Sun, 19 Jan 2020, Simon Kainz wrote:
> thanks for the ping - it seems we have some uplink issues at work. Will
> report back on monday.

What's up? I still get failures from distro-tracker.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Bug#945206: tracker.debian.org: Broken binaries link in glibc page

[Raphael Hertzog]

Hello,

On Thu, 21 Nov 2019, Alexandros Prekates wrote:
> Visiting https://tracker.debian.org/pkg/glibc
> i noticed many dead links in the binaries section
> of the page.

Those are binary packages that the glibc source package can build but that
it only builds on non-release architectures... so indeed the binary
packages are unknown by packages.debian.org which only knows about
packages available on official mirrors.

And the list of binary packages is currently taken from the "Binary" field
in the .dsc and there we don't have any detail about architecture support,
etc.

The tracker also doesn't scan all architectures currently (for performance
reasons) so it doesn't know which binary packages do really exist across
all architectures.

Basically, there's no easy fix currently.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#931516: tracker.debian.org: fixtures reference testing/updates instead of testing-security

[Raphael Hertzog]

Hi,

On Sun, 07 Jul 2019, Paul Wise wrote:
> The fixtures reference testing/updates but with bullseye that suite has
> been renamed to testing-security. The fixtures in the code need to be
> updated and then updated on the live server. I've no idea how to do the
> latter, which is why I'm filing this issue.

I updated the fixture now. I did update the live server soon after the
release, but for reference, to update it you have to login into the
administrative web interface (you need your user to be super-user) and
update manually the list of repositories.

On all the existing repositories, you edit them only to update the
"suite" field. Then you create new repositories for the new testing.
Eventually you drop some of the repositories that are no longer useful.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#930521: tracker.d.o: during freezes dont complain about packages only in experimental

[Raphael Hertzog]

Hi,

On Mon, 17 Jun 2019, Paul Wise wrote:
> I believe these are the appropriate changes:
> 
>  * ask to migrate non-RC/beta/etc to unstable when not in the freeze
>  * don't ask to package versions that are already in experimental
> 
> Does that sound reasonable Raphael?

Yes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Raphael Hertzog]

On Sat, 15 Jun 2019, Raphael Hertzog wrote:
> I also don't know why you picked this bug report to start your journey
> into distro-tracker. It's not a trivial issue to fix and the added value
> is relatively low compared to other missing features.
> 
> I took the time to highlight easy bugs with the newcomer tag,
> maybe you should start with some of those?

Ah, I see the bug was tagged as newcomer by Paul in fact. I suggest
you first deal with all the requests in this bug except the last
idea to display who approved the DM right... the rest should be relatively
easy.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Raphael Hertzog]

On Sat, 15 Jun 2019, Paul Wise wrote:
> On Fri, 2019-06-14 at 16:13 -0300, Herbert Fortes wrote:
> 
> > Should dm.txt file be downloaded and read once a day?
> > (to update/save new info)
> 
> I note there is already code in RetrieveDebianMaintainersTask that
> downloads and processes dm.txt so perhaps that should be used.

Definitely, and you also don't want to use urlopen() in any web request,
that doesn't scale... we would be hammering ftp-master to retrieve the
same information over and over.

And we have our own code to retrieve data over HTTP (get_resource_text)
so we don't use urlopen().

Herbert, you need to come up with a good design before you get into
coding.

Here are some rough guidelines:
1/ you want to handle all the processing of the dm.txt file in
   RetrieveDebianMaintainersTask, you want to parse the "dd_fpr"
   variable that we already extract
2/ you want to come up with a way to store that data in the database,
   I would probably opt to add a JSONField to the DebianContributor model
   so that you can store a hash associating "package => granted_by".
3/ then you need to modify the template and the associated context to
   display that information

I also don't know why you picked this bug report to start your journey
into distro-tracker. It's not a trivial issue to fix and the added value
is relatively low compared to other missing features.

I took the time to highlight easy bugs with the newcomer tag,
maybe you should start with some of those?
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=tracker.debian.org;tag=newcomer
https://salsa.debian.org/qa/distro-tracker/issues?label_name%5B%5D=newcomer

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Raphael Hertzog]

Hi,

On Thu, 13 Jun 2019, Herbert Fortes wrote:
> I found where to make the change. But the information about
> who gave the permission I do not know where it is at *debian.org.
> 
> In distro_tracker/vendor/debian/rules.py file:
> 
> _add_dm_entry function - extra.append({'display': 'dm'})
> 
> 'link': "https://ftp-master.debian.org/dm.txt;
> 'description': "Debian Maintainer upload allowed by Andreas Henriksson"

In https://ftp-master.debian.org/dm.txt behind each package, there's a
fingerprint between parenthesis. This fingerprint is the fingerprint
of the key who signed the addition of the DM right. So if you can map
that back to a name, then you're good.

There's some code doing that already with the help of the GPG keyring
that we have configured, see verify_signature() in
distro_tracker/core/utils/__init__.py (in particular
ctx.get_key(...)).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Distro Tracker tests

[Raphael Hertzog]

On Wed, 12 Jun 2019, Herbert Fortes wrote:
>  - tox | tee log.txt
>http://paste.debian.net/1087635/

Ah, those errors are unrelated to the functional tests. This is a
requirement of the multiprocessing module, it needs to have working
semaphore support and for this you need to have /dev/shm mounted with
proper rights.

You're lacking this in your chroot.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Distro Tracker tests

[Raphael Hertzog]

Hi,

On Tue, 11 Jun 2019, Herbert Fortes wrote:
> I put everything inside a chroot jail and run tox. Selenium worked after 
> 'xhost' command.  But there is a problem.
> 
> Have I done something wrong?

I don't know... you don't show a lot of context with your pasted logs...
and I don't know what the "Function not implemented" refers to.

When you run the functional tests with tox, it runs them with "xvfb-run"
in a dedicated fake X server. Are you using that? What version of
chrome/chromium are you using?

In any case, being able to run the functional tests is not a hard
requirement to contribute to distro-tracker.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Requirements to show something as action item on tracker.debian.org

[Raphael Hertzog]

Hello,

while discussing with Johannes Schauer on
https://salsa.debian.org/qa/distro-tracker/merge_requests/74
I questioned the use of an action item that would appear
on 50% of all packages.

Please have a look at the discussion above and let us know
your thoughts on the topic. Should we be liberal and accept
many action items even if they appear on many packages and if many
maintainers are likely unable to do anything about it?

If not, what are the requirements?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#928808: tracker.debian.org: automatic filing bugs

[Raphael Hertzog]

Hi,

On Sat, 11 May 2019, Dmitry Bogatov wrote:
> would it be possible to automatically file bugs with issues, already
> detected by tracker?

Right now, there's no email notification and I certainly agree
that there should be some email notification about new upstream releases.
Wouldn't that be sufficient? Do you really want a bug filed?

> Question is access-control. Probably, only maintainer/uploader of
> package can make decision, whether bugs should be auto-reported.
> I see it as something like this:

While we have a mailbot, I see it mainly as legacy, the control interface
for such a feature would likely be on the web interface.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#926684: tracker.debian.org: Outdated team information (here debian-tryton)

[Raphael Hertzog]

Hi,

On Tue, 09 Apr 2019, Mathias Behrle wrote:
> > It's in the «Update team» link:
> > https://tracker.debian.org/teams/debian-tryton/+update/
> > 
> > But only the team owner has access to this. Are you the team owner? (the
> > one who created it?)
> 
> No, I am not. It was created automatically (I guess). How can I become the 
> team
> owner?

It was not created automatically, no.

In [2]: t = Team.objects.get(slug='debian-tryton')

In [3]: t.owner
Out[3]: 

So you should consider joining your two accounts together or using your
other account to do this task.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#926684: tracker.debian.org: Outdated team information (here debian-tryton)

[Raphael Hertzog]

Hi,

On Tue, 09 Apr 2019, Mathias Behrle wrote:
> URL: http://tryton.alioth.debian.org/
> Maintainer email: maintain...@debian.tryton.org
> 
> I couldn't find a way to update that information via 'Manage team'. 
> Could you please fix that or point me to where to fix it to

It's in the «Update team» link:
https://tracker.debian.org/teams/debian-tryton/+update/

But only the team owner has access to this. Are you the team owner? (the
one who created it?)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#926336: tracker.debian.org: changing the sphinx theme from default to sphinx_rtd_theme

[Raphael Hertzog]

Hi,

On Wed, 03 Apr 2019, Salman Mohammadi wrote:
> Dear Maintainer,
> 
> It would be nice if we changed the documentation (sphinx) theme from
> *default* to *sphinx_rtd_theme*. I suppose it is more visually appealing.

Why do you say "I suppose"?

Do you find it more visually appealing or not? Did you compare?
Can you show us an example of the result so that we can compare ?

Honestly, I'm not opposed to changing the theme but it would be much
better if someone developed a theme with some Debian branding...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#926074: RSS-Feed: Server ignores 'Last-Modified' date

[Raphael Hertzog]

Hi,

On Sun, 31 Mar 2019, Christian Buhtz wrote:
> As developer of a RSS/Atom newsreader I found problems with the RSS-Feed 
> offerd
> by Debian-Tracker.
> 
> The 'Last-Modified' date is ignored when used in a second request in the 'If-
> Modified-Since' field.
> When there are only some seconds between two requests, the expected behaviour,
> when using the date from the first request directly, is that in the second
> request should no feed entries.
> 
> In my newsreader I use Pythons 'aiohttp' package but in that example below I
> use 'feedparser' for easier handling. The problem is reproducable with both.
> 
> Side note: I know (and do) that as a workaround I can check the "published"
> dates of each entry and delete them if my newsreader still have them. But this
> is Debian and I am hopefull that this can be improved.

We are relying on a Django object to implement the feed so if anything,
this should be improved at this level:
https://docs.djangoproject.com/en/1.11/ref/contrib/syndication/

I would suggest to file your suggestion to the Django developers.

Unless Django expects us to setup a ConditionGETMiddleware to replace
the answer by a NotModified answer:
https://docs.djangoproject.com/en/1.11/ref/middleware/#module-django.middleware.http

We could enable this but I wonder if it would have other unexpected
side-effects in other parts of the code.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#756954: subscription by uploaders

[Raphael Hertzog]

Hello Afif,

sorry for the delay.

On Sun, 03 Feb 2019, Afif Elghraoui wrote:
> The way I was hoping this could work is that Uploaders are automatically
> subscribed. I don't know of any reason why an Uploader should not be
> following their packages. I think it would also motivate people who
> really don't co-maintain a package to get themelves removed from the
> Uploaders list, thereby correcting the package metadata.

Uploaders should be following their packages but they might already be
following their packages in some other way: through a (tracker-)team
subscription. Or through a mailing list that is referenced in the
Maintainer field.

So maintainers should be able to opt-out from this automatic subscription
or at least blacklist some packages (so that a manual unsubscription is
not followed by an automatic subscription because of the Uploaders field).

> I think this would also be simpler to implement than subscription
> keywords in d/control (as mentioned in the OP). If it's still too far
> out of you way, I'd be willing to implement a patch, but would
> appreciate a tip about where to look in the code-base. I looked around
> it and couldn't find a good starting point in the file hierarchy.

I believe this feature is important and it would be nice to have it
working in the not too distant future but I'm unfortunately not actively
working on the tracker lately (just look at how much time it took me to
respond to your mail!).

A good start would be to modify the database so that we can record the
origin of each subscription. I imagine it would be a simple text value
associated to the subscription: "manual:web" or "manual:email" for a
manual subscription from the web interface or from the email interface. Or
"auto:uploaders" for this new feature.

You will have to modify the Subscription model in
distro_tracker/core/models.py and you probably want to create a new
task in distro_tracker/core/retrieve_data.py (or modify an existing one?)
to create/delete the subscriptions as appropriate.

You will have to review the places where the subscriptions are created
and add the required origin value.

The task should be smart enough to detect when the given email already
gets the package notifications through a tracker team or through a pre-existing
(manual) subscription or through an alternate email associated to the same
user.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#920024: Doesn't parse package architectures correctly when any-amd64 is used (etc.)

[Raphael Hertzog]

On Mon, 21 Jan 2019, Steve McIntyre wrote:
> I've just been looking at the details for sbsigntool
> (https://tracker.debian.org/pkg/sbsigntool) It looks like the tracker
> code is confused by the architecture list for sbsigntool:
> 
>   Architecture: any-amd64 any-i386 arm64 armhf
> 
> and is just showing 
> 
>   arch: arm64 armhf
> 
> which is quite confusing!

Yeah, the data model includes a list of architectures by source package
and the parsing keeps only entries which are real architectures, the
architecture wildcards are just not handled.

Extract from distro_tracker/core/retrieve_data.py:

# Convert the parsed data into corresponding model instances
if 'architectures' in entry:
# Map the list of architecture names to their objects
# Discards any unknown architectures.
entry['architectures'] = Architecture.objects.filter(
name__in=entry['architectures'])

I think we don't have any code in the tracker to handle architecture wildcard
and try to do any mapping or expansion. Given the data model, that's we should
aim to do here. Creating all the possible wildcards would be wrong, instead we
want to process the list of architectures that the tracker knows of and see
whether it matches the wildcards listed in the source package field.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#916675: tracker.debian.org: Please show info from ftp.debian.org bugs

[Raphael Hertzog]

On Tue, 18 Dec 2018, Uwe Kleine-König wrote:
> > This is already the case. Here's a current example:
> > https://tracker.debian.org/pkg/janest-core
> > 
> > => «  RM: This package has been requested to be removed. »
> 
> then I wonder why it didn't show up for linux-igd. Even 12h after the RM
> request it wasn't notice

Distro Tracker fetches the data every 3 hours from
https://qa.debian.org/data/bts/wnpp_rm and that file seems to be updated
every hour.

The script data/bts/bts-wnpp_rm uses Devscripts::Debbugs::select to fetch
bug data.

In short, I have no idea what went wrong for this case. It might have been
a delay somewhere or Devscripts::Debbugs::select having a cache ?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#756117: Resurrecting patch-tracker.d.o

[Raphael Hertzog]

Hi,

On Thu, 08 Nov 2018, Petter Reinholdtsen wrote:
> What about linking to the patches like packages.qa.debian.org is doing
> it, ie via https://sources.debian.org/patches/ ?  See for example
> https://packages.qa.debian.org/c/conv-tools.html > for a package
> with the patches linked to from the info page.

Merge request, welcome. ;-)

See https://qa.pages.debian.net/distro-tracker/contributing.html

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#908828: tracker.debian.org appears to report that the source package is to be removed, even though it's just the binary

[Raphael Hertzog]

Control: reassign -1 qa.debian.org
Control: affects -1 tracker.debian.org

On Fri, 14 Sep 2018, Daniel Kahn Gillmor wrote:
> https://tracker.debian.org/pkg/knot-resolver shows:
> 
>  RM: This package has been requested to be removed.
[...]
> however, #908755 only requests removal of the *binary* package for
> knot-resolver on one architecture (arm64).  The source package itself

This is shown because the RM bug is listed in
https://qa.debian.org/data/bts/wnpp_rm

We don't have any detail about the RM bug. Arguably this file should not
list removal requests for binaries. But this is not under
tracker.debian.org's territory so I'm just reassigning the bug.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#792566: tracker.debian.org: please show source (and binary) dependency satisfaction problems

[Raphael Hertzog]

Hi,

On Thu, 13 Sep 2018, Johannes Schauer wrote:
> if this is desired, then I can do the same thing for source package package
> build dependencies, yes.
> 
> I just didn't want to do all at once because I didn't know how this feature
> would be received.
> 
> Would you like me to make another merge request for source package build
> dependencies?

Yes, please. And mark this bug as closed in your commit message. :)

I assume you will do it only for unstable and for release architectures.
And that it will not complain of unsatisfiable dependencies on unsupported
architectures when the package is architecture-specific.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#792566: tracker.debian.org: please show source (and binary) dependency satisfaction problems

[Raphael Hertzog]

Hi,

On Thu, 16 Jul 2015, Johannes Schauer wrote:
> at qa.d.o/dose, daily dependency satisfaction tests are performed on all
> packages in Debian unstable and testing for main, contrib and non-free
> each for binary packages as well as for source packages.
> 
> It would be great if any issues about dependency satisfaction problems
> (source packages that cannot satisfy their build dependencies anymore
> and binary packages that cannot satisfy their binary dependencies
> anymore) would show up in the "action needed" list on the tracker.

You just implemented it for binary packages. Do you plan to do the same
for source package and build-dependencies?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: What criterion is used for "has autopkgtest and migrates to testing in 2 days"?

[Raphael Hertzog]

On Wed, 12 Sep 2018, Paul Gevers wrote:
> Hi
> 
> On 12-09-18 18:35, Niels Thykier wrote:
> > We should probably have *some* marker in tracker for this case.
> 
> I think tracker is just slow at picking up new packages for excuses.
> https://qa.debian.org/excuses.php?package=r-cran-snakecase should always
> up-to-date within the hour.

tracker is now fetching excuses every hour as well, so the problem here
is that excuses is really not showing the fact that the test failed...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#908457: bug counter wrong

[Raphael Hertzog]

Control: severit -1 minor
Control: forcemerge 904841 -1

On Mon, 10 Sep 2018, Jörg Frings-Fürst wrote:
> the all counter add the bugs from the patch counter.
> Patch is only a tag and the bug is also counted in one
> of the severities counters.

Already reported in #904841. A simple fix for anyone who wants to try to
contribute... Are you interested?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#907923: tracker.debian.org: team pages: action needed title field includes HTML tags

[Raphael Hertzog]

Hi,

On Tue, 04 Sep 2018, Paul Wise wrote:
> I noticed that on team pages the title field of the "action needed"
> tags in the VCS column include bold HTML tags but browsers do not
> render these as bold in the popup that appears on mouse hover,
> instead they show the literal HTML from the field.

In Firefox 61, I do see the content rendered as bold (see attached
picture).

What's your browser? Or is it due to lack of javascript?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Bug#907338: tracker.debian.org: confusion between keyword and keywordall

[Raphael Hertzog]

Hi,

On Tue, 28 Aug 2018, shirish शिरीष wrote:
> The point being I didn't know for what packages I have I have
> what subscriptions.
> 
> For e.g. I like dpkg, apt and some packages and like to know
> what bugs have been caught there etc. but not necessarily all others.

You may want to use the web interface. It will show all that quite
nicely. The email interface is good to make some changes but really
not made to review all your subscriptions.

See https://tracker.debian.org/accounts/subscriptions/

> What would have been a lot better if possible to have a list of all
> the packages with subscriptions on it.  I dunno if it's on the roadmap,
> if not will file a wishlist bug for it.

Well, "which" gives you your list of subscriptions and then you can
use "keyword " on all of them in a loop if you really want
to stick to the email interface.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#907338: tracker.debian.org: confusion between keyword and keywordall

[Raphael Hertzog]

Hi,

On Sun, 26 Aug 2018, shirish शिरीष wrote:
> According to https://qa.pages.debian.net/distro-tracker/usage/mailbot.html
> one can interact with the tracker via email, while some parts work,
> some parts don't .
>
> I tried using keywordall but for some reason that didn't work. Is this
> to be used by a team or by a user, it's not clear :(

In fact the command "keywordall" doesn't exist at all. This is a left-over
from the documentation of the former implementation of the package
tracker. I dropped it from the doc.

> 2. keyword [email id] - This one worked as well and sent me a list of
> all the keywords I'm accepting, unfortunately it tole me I'm accepting
> all the keywords.

Why "unfortunately"?

> Now I tried various methods to just have 'summary' for all the
> packages I'm subscribed to.

You won't get much with just this keyword.

> The one which worked was -
> 
> keyword [myemailid] = summary

That's the correct way, yes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#856282: ARIA should be used to communicate the status of collapsable content under the Action Needed heading to assistive technologies

[Raphael Hertzog]

Control: tag -1 + moreinfo

Hello,

On Mon, 27 Feb 2017 08:22:52 -0500 am_d...@fastmail.fm wrote:
> Currently, when selecting the Toggle Details buttons with a screen
> reader like gnome-orca, nothing is spoken as the content after these
> buttons in the DOM expands or collapses. I suggest adding the
> aria-expanded attribute to all of these buttons. All of the collapsed
> elements should be set to aria-expanded="false" and all of the expanded
> elements should be set to aria-expanded="true". When the button is
> selected by the user, the state of the aria-expanded attribute should be
> changed as the content expands or collapses. This will cause the correct
> expanded and collapsed notifications to be fired to assistive
> technologies by web browsers.

In the mean time, we changed the rendering of those action items
to use the  tag which is standard HTML5. Is something like
this still required?

I would expect standard HTML to be friendly with screen readers and
other assistive tools. But I might be wrong.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#906963: keyword subscription does not always work

[Raphael Hertzog]

On Sun, 26 Aug 2018, Raphael Hertzog wrote:
> Are you observing the same thing?

I identified the problem. It's in the javascript, the code
is badly using jquery to find out the list of keywords. I have
a fix locally but I want to polish it further before releasing
it and I'd like to add a non-regression test because it's not
the first time we break it without noticing.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#906963: keyword subscription does not always work

[Raphael Hertzog]

Control: severity -1 important

Hi,

On Wed, 22 Aug 2018, Marc Haber wrote:
> I would like to get the vcs messages, so I click on "Modify Keywords",
> and am surprised that everything is ticket there. Regardless on which
> change I make here, after clicking on "Save changes", nothing changes,
> neither in the overview view nor in the "Choose keywords" dialog.
> 
> Is this broken, or am I doing things wrong?

Do you have multiple emails configured in your account?

I do have two emails configured. For the packages subscribed to the first
email appearing on https://tracker.debian.org/accounts/subscriptions/
the "modify keyword" button seems to show the correct set of keywords.

But for the second email, it effectively looks likes that the checked
keywords do not match the real keywords.

However in both cases, clicking the "Save changes" button does modify
the associated keywords, they are however not refreshed in the current
page. You have to reload the entire page to see the change.

Are you observing the same thing?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#893995: Include searchable provides data alongside binaries in tracker

[Raphael Hertzog]

Hi,

On Sun, 25 Mar 2018, Pirate Praveen wrote:
> Currently provides data is missing from tracker.Debian.org
> 
> For example ruby-flipper provides ruby-flipper-active-record but this
> information is missing currently from tracker.Debian.org

Can you be more specific in your request?

provides is data about a binary package and the tracker is centered
around source package.

Do you mean that provided packages should be considered when you search
for a package?

Or do you want to display this information somewhere?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#907075: tracker.debian.org: please report outstanding merge requests if Vcs- fields point to salsa

[Raphael Hertzog]

Control: tag -1 + confirmed

On Thu, 23 Aug 2018, Daniel Kahn Gillmor wrote:
> I just noticed that some debian packaging projects i've worked on that
> are hosted on salsa are starting to accumulate merge requests via the
> gitlab interface.
> 
> https://tracker.debian.org does a good job of collecting outstanding
> work under the "action needed" box.
> 
> I think if a source package has a Vcs- field that points to salsa, the
> tracker could take a look at the number of outstanding merge requests
> open on the project's gitlab repo, and report if the number is greater
> than 0.

Good idea, marking the bug as "confirmed" just so that it stands out in
the list of wishlist. That's one that I would really like to see
implemented.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Bug#847125: https://www.debian.org/doc/manuals/developers-reference/ch04.en.html#pkg-tracker-commands doesn't seem to be anymore :(

[Raphael Hertzog]

Hi Shirish,

you sent your email to a completely unrelated bug report. I'm replying
on the debian-qa mailing list to avoid polluting the bug report.

On Fri, 24 Aug 2018, shirish शिरीष wrote:
> https://www.debian.org/doc/manuals/developers-reference/ch04.en.html#pkg-tracker-commands
> doesn't seem to be anywhere :(

That's because I dropped most of the content and I kept only this:
https://www.debian.org/doc/manuals/developers-reference/ch04.en.html#pkg-tracker

The rest is now in the distro-tracker documentation itself:
https://qa.pages.debian.net/distro-tracker/

> IIUC, there is a new distro tracker in works which will take
> responsibilities of the current  tracker.
[...]
> It would be nice to have some info. on how things are going to forward
> and we as users could contribute to testing the same (if possible) .

It's now a "new" distro tracker, we're speaking of new features available
in distro-tracker. I sent some news about all this on
debian-devel-announce not so long ago:
https://lists.debian.org/debian-devel-announce/2018/07/msg1.html

The developed features are live but we will continue to expand them.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#906954: tracker.debian.org: incorrect DUCK last update time

[Raphael Hertzog]

Hi,

On Wed, 22 Aug 2018, Christian Göttsche wrote:
> The URL(s) for this package had some recent persistent issues low
> DUCK reports some issues concerning upstream URLs defined for this package.
> Created: 2018-06-10 Last update: 2018-08-22 15:01
>
> But when visiting the issues link, the page shows the last run
> happened on 2018-07-28 (so not 2018-08-22 15:01).

The "Last update" is the time when tracker.d.o last updated its
own data, i.e. the last time we fetched the data from DUCK.

And the data we fetch from DUCK is limited to a list of source packages:
http://duck.debian.net/static/sourcepackages.txt

So we can't give more details.

Not sure where to go from here.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#816733: PTS doesn't understand RFS bugs

[Raphael Hertzog]

Control: retitle -1 tracker.debian.org: RFS entries are hidden by other WNPP 
entries

On Tue, 21 Aug 2018, Paul Wise wrote:
> > I think this bug does not apply to tracker.debian.org.
> 
> Actually, it does (although the summary message is less severe):

Hum, before doing this I checked a few packages listed on
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=sponsorship-requests;dist=unstable

For example https://tracker.debian.org/pkg/raphael or
https://tracker.debian.org/pkg/cplay

So it seems that the ITA or O entry is taking precedence and is hiding the
RFS one. Just confirmed this in the source code:

package_name, wnpp_type, bug_id = line.split('|')[0].split()

We only take into account the first entry of each line
in https://qa.debian.org/data/bts/wnpp_rm

So there are actually two issues here. I just fixed the fact that RFS is unknown
but the other issue is still pending.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#816733: PTS doesn't understand RFS bugs

[Raphael Hertzog]

Control: severity -1 wishlist
Control: retitle -1 tracker.debian.org: please show sponsorship requests

On Fri, 04 Mar 2016, Jakub Wilk wrote:
> https://packages.qa.debian.org/o/openfst.html says:
> > The WNPP database contains an entry for this package, but it is unclear
> > what kind of entry it is. This is probably an error. Please see bug
> > number #814852 for more information.
> 
> But #814852 is not a wnpp bug, it's an RFS.

I think this bug does not apply to tracker.debian.org. Thus changing
this bug into a wishlist to actually show the sponsorship requests. Those
are RFS bugs filed against the sponsorship-requests package:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=sponsorship-requests

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#899405: tracker: Default documentation is not user-oriented

[Raphael Hertzog]

Hi,

On Thu, 24 May 2018, Raphael Hertzog wrote:
> Definitely! This is now even more needed because we have a few interesting
> team-oriented features that really need to be documented.
> 
> I would like https://qa.pages.debian.net/distro-tracker/ to provide
> user-oriented documentation (as well as developer/contributor docs)
> so the plan is to merge what is in the developers reference
> into the distro-tracker doc, expand it, and then replace the section
> in the developer's reference with a link to the distro-tracker
> documentation.

I did that a while ago. Closing the bug. The documentation can always
be expanded of course.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#904694: tracker.debian.org: don't complain about outdated S-V for packages only in <= stable

[Raphael Hertzog]

Control: tag -1 + newcomer

Hi Adam,

thanks for the report.

On Thu, 26 Jul 2018, Adam D. Barratt wrote:
> https://tracker.debian.org/pkg/postgresql-9.6 reports both that the
> package is "not in any development repository", and that "[t]he package
> is severely out of date with respect to the Debian Policy".
> 
> It seems silly (and apparently confusing to at least some users) to
> complain about the outdated S-V for a package that only exists in
> (old)stable, where the package won't be tracking updates to Policy.

Right. For anyone looking to fix this, the right place to look at is
distro_tracker/stdver_warnings/tracker_tasks.py

One way to fix this would be to look package.main_entry and see if the
associated repository is the default repository and generate the action
item only in this case.

Ideally a corresponding unit test would be added in
distro_tracker/stdver_warnings/tests.py.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#904634: tracker.debian.org: no href target in link for "NN bugs tagged patch in the BTS" action

[Raphael Hertzog]

Hi,

On Thu, 26 Jul 2018, Paul Wise wrote:
> The href target for the link in the "NN bugs tagged patch in the BTS"
> action is empty. Here is an example from glibc:
> 
> 45 bugs tagged patch in the BTS
> 
> https://tracker.debian.org/pkg/glibc
> 
> Since the link is present in another part of the page, I have tagged
> the bug as suitable for a newcomer to fix by copy-pasting the link.

I wonder if this not a regression due to the recent refactoring made by
Arthur (in copy) on the way we handle bugs data. I'll let him have a look
as I don't have the time right now.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: debci configuration is inconsistent, disrupts package migration

[Raphael Hertzog]

Hi,

moving this to debian...@lists.debian.org. debian-qa is of no help here.

Thanks.

On Tue, 17 Jul 2018, Drew Parsons wrote:
> The configuration of ci.debian.org is not consistent.   A failing test
> of deal.ii is marked on 
> https://ci.debian.net/packages/d/deal.ii/testing/amd64/ 
> as triggered by petsc/3.9.3+dfsg1-2, but the test log shows that in
> fact libpetsc-real3.8-dev is used for the test 
> (i.e. petsc/3.8.4+dfsg1-2+b2).  So unsurprisingly the test fails, which
> disrupts migration of the new petsc 3.9 (throwing it out to 10 days
> instead of 5). The failure itself occurs since the different petsc were
> built against different openmpi.
> 
> Drew
> 
> 

-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Re: Bug#903155: tracker.debian.org: cripples Firefox 61.0

[Raphael Hertzog]

Hi,

On Sat, 07 Jul 2018, Dmitry Smirnov wrote:
> > Do the following commands work faster ?
> > 
> > curl https://tracker.debian.org/static/css/dense.css
> > or
> > wget https://tracker.debian.org/static/css/dense.css
> 
> Yes they do work faster however it is not the same as browser requests. 
> Browser fetches few URLs concurrently and if it hits black hole with larger 
> packet(s) then in turn it may affect smaller requests. I guess something 
> happens during TLS negotiation which affects subsequent requests...

Well, mtr is certainly not a browser request. It's merely a ping on
intermediate hosts. So it's easy to reproduce.

So I'm not sure that you are on the right track.

> > Probably, but you're most likely not speaking to the right person.
> 
> I wish I knew the right person to speak to...

https://dsa.debian.org/

For a more interactive discussion, they are at #debian-admin on OFTC.
But I have a hard time believing that the Debian infrastructure is at
fault here.

If you want to go further, you should probably also seek the help of
Firefox developers since it's behaving badly compared to chromium in the
same (possibly problematic) network environment.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#903155: tracker.debian.org: cripples Firefox 61.0

[Raphael Hertzog]

Hello Dmitry,

On Sat, 07 Jul 2018, Dmitry Smirnov wrote:
> For a while I thought that "tracker.debian.org" is just immature
> but some time ago I've noticed that from some other networks
> Firefox load pages from tracker.debian.org just fine.
> Now I'm suspecting that somewhere we may have something like
> misconfigured router with black hole problem (i.e. silently
> dropping large packets). It might be something else but here
> is what I get when I run `mtr tracker.debian.org`:

So this really looks like a network problem... and something that
I have no control over as tracker.debian.org maintainer.

This bug should thus be closed and you should get in touch with your
network administrator. Maybe people in #debian-admin on OFTC can help you
troubleshoot the network problem but I would not count too much on it.

Have you tried to figure out whether you have a forced/transparent proxy
which is dropping the answer to some requests? (Though this would seem
strange given we use https everywhere, except if they masquerade HTTPS
with a certificate of their own)

In particular, can you pin-point some specific GET request that is
not working... you mentionned this:

> It takes 38_500 ms. just to load "dense.css" which is only 805 bytes.

Do the following commands work faster ?

curl https://tracker.debian.org/static/css/dense.css
or 
wget https://tracker.debian.org/static/css/dense.css

> I hope there is an explanation to this and hopefully remedy.

Probably, but you're most likely not speaking to the right person.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#902438: tracker.debian.org: broken links in VCS field

[Raphael Hertzog]

Hi,

On Tue, 26 Jun 2018, Sven Joachim wrote:
> In the VCS field on https://tracker.debian.org/pkg/$package there are
> three new links labeled changelog_distribution, changelog_version and
> package_version.  Unfortunately they are all 404 compliant.

Yeah, a mistake that I already reported here:
https://salsa.debian.org/qa/distro-tracker/issues/29

Introduced by Arthur Del Esposte, I'm waiting his fix. :)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#902262: tracker.debian.org: incorrect data for owncloud removal

[Raphael Hertzog]

Hi,

On Sun, 24 Jun 2018, Paul Wise wrote:
> The removals news items for owncloud differ from the PTS:
> 
> https://packages.qa.debian.org/o/owncloud.html
> 
> [2017-05-06] Removed 7.0.4+dfsg-4~deb8u4 from stable (None)
> [2016-04-26] Removed 7.0.13~dfsg-1 from unstable (None)
> [2016-04-15] owncloud REMOVED from testing (Britney)
> 
> https://tracker.debian.org/pkg/owncloud
> 
> [2016-04-26] Removed 7.0.13~dfsg-1 from unstable (Debian FTP Masters)
> [2016-04-26] Removed 7.0.13~dfsg-1 from unstable (Debian FTP Masters)
> [2016-04-15] owncloud REMOVED from testing (Debian testing watch)
> 
> The tracker data appears to have duplicated the removal from unstable
> and dropped the removal from stable.

The duplicate entry is unrelated to the removal of the version from
stable. The duplicate entry has been created right from the start.
Possibly because ftpmaster was sending the mail to the package tracker
twice, through two different channels. This is likely fixed nowadays,
it mails only @packages.d.o.

As for the lack of the news about the removal from stable, it's not clear
why it's missing. I don't see any reason for the code to skip the message
so it likely did not receive it altogether.

Maybe for a reason similar to #792600. I don't think there's much
actionable in this report.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/