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

2024-03-22 Thread 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



Bug#1036214: Tracking gets confused by using copysrc on binnmu'ed packages

2024-02-23 Thread Raphael Hertzog
Hello,

On Wed, 17 May 2023, Christoph Berg wrote:
> Ever since, I've seen warnings from reprepro that the tracking
> database was missing references when copysrc'ing a new version into a
> distribution when the previous version in there had been binnmued. But
> since everything worked as expected, I didn't pay attention.
> 
> Now I have been inspecting the pool directory more closely, and I
> found a lot of +b1.deb files that should long have been removed since
> they were replaced by newer versions, e.g.:

We have the same problem in Kali, our mirror is growing in size due to
files that are not removed properly. Many of the files were bin-NMU but
not exclusively.

We also have the issue with the binary packages from android-platform-tools
for example. And looking at this source package we can see that there's
a mismatch between the source version and the binary version. The rules
files uses `dh_gencontrol -p$PKG -- -v1:$(DEB_VERSION)` to add an epoch
to the binary packages which is not present in the source package.

https://salsa.debian.org/android-tools-team/android-platform-tools/-/blob/master/debian/rules?ref_type=heads#L217

So the problem seems to be generalized to all packages that have a
different version compared to the source packages (a few more packages
affected on our side: binutils-bpf, binutils-arm-none-eabi, many more
binutils-* in fact, linux with bpftool, bsdutils, llvm-defaults, gcc,
etc.)

> The problem seems to never happen on *-pgdg-testing (which gets filled
> by processincoming), only on *-pgdg (which gets filled by copysrc), so
> I suspect the problem to be in that area.

On our side, we have a kali-rolling distribution that is built manually
out of kali-dev with many "reprepro copy" and "reprepro removefilter"
calls (the set of commands to run is built out of analysis of the current
distribution and the comparison with the "heidi" file generated by britney
which defines the desired end-state).

That it seems likely that the "copy" command is affected/involved as well.

In our case, both kali-rolling and kali-dev have "Tracking: minimal
includechanges includebyhand includebuildinfos" in conf/distributions.
kali-dev is updated with a "pull" rule that combines a mirror of debian
testing (created with an "update" rule) and of kali specific packages
(which are uploaded and installed via processincoming).

It would be nice to see this fixed. I'm happy to pitch a bounty or suggest
anyone to apply for https://salsa.debian.org/freexian-team/project-funding
to tackle a few long standing bugs/feature request on reprepro.

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



Bug#1060270: /lib/cryptsetup/askpass: coordinated move to /usr for DEP17

2024-02-17 Thread Raphael Hertzog
Hello,

On Tue, 23 Jan 2024, Guilhem Moulin wrote:
> On Tue, 23 Jan 2024 at 10:15:02 +0100, Raphael Hertzog wrote:
> > when do you plan to upload a cryptsetup moving the files to /usr?
> 
> I can have a look after the week-end or in early February.  There are
> other issues I'd like to fix in the next upload.

Small ping, we're now mid-February. Any updated ETA?

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#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

2024-02-14 Thread Raphael Hertzog
On Wed, 14 Feb 2024, Raphael Hertzog wrote:
> i.e. is the the file-loss triggered only by the bad path in the
> dpkg-divert call or is it triggered by the upgrade of dpkg between
> both dpkg-divert calls?
> 
> I thought it was the latter... and that would explain why OpenQA is not
> affected, it likely generates images against the release that it is
> testing.

I have confirmed this. The bad path is not problematic in itself,
dpkg-divert will move the file away and put it back as expected.

I believe it's because dpkg is removing /sbin/start-stop-daemon in favor
of /usr/sbin/start-stop-daemon that we are losing the diverted .REAL file.

Even though this file loss scenario is rare because you need to have
two specific dpkg version in bootstrap-base and pkgsel, it's still worth
fixing because the ineffective diversions means that any dpkg
upgrade in pkgsel will happily overwrite d-i's version of start-stop-daemon
and thus we might start seeing daemons running in the debian-installer
environment.

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



Bug#1063878: di-utils: chroot-setup.sh creates ineffective diversions (DEP17)

2024-02-14 Thread Raphael Hertzog
(Adding Colin as one of the debian-installer-utils comaintainers)

Hi,

On Tue, 13 Feb 2024, Helmut Grohne wrote:
> I also see that https://openqa.debian.net/ has recent successes. dpkg
> migrated to trixie about two weeks ago. I would have expected that this
> breaks an d-i. Do you have an explanation for why jobs still pass?

FTR, in the Kali bug the case is really special:
1/ a dpkg with /sbin/start-stop-daemon is installed by debootstrap
   (bootstrap-base step)
2/ a dpkg with /usr/sbin/start-stop-daemon is installed (upgraded)
   during the pkgsel step

Could it be possible that if you have the same dpkg version in the
image and in the network repository, then you would not be bitten by
the bug?

i.e. is the the file-loss triggered only by the bad path in the
dpkg-divert call or is it triggered by the upgrade of dpkg between
both dpkg-divert calls?

I thought it was the latter... and that would explain why OpenQA is not
affected, it likely generates images against the release that it is
testing.

> Raphael, can you link this bug to the Kali bug?

Done.

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



Bug#1060270: /lib/cryptsetup/askpass: coordinated move to /usr for DEP17

2024-01-23 Thread Raphael Hertzog
Hello Jonas & Guilhem,

when do you plan to upload a cryptsetup moving the files to /usr?

Jonas, you should also update cryptsetup-nuke-password at the same time
(cf #1060269). I can help if needed.

Looking forward to see those two bugs fixed.

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



Bug#1060897: Bug #1060897: furo: documentation generated with Debian's furo package doesn't work standalone

2024-01-19 Thread Raphael Hertzog
Control: reopen -1

On Fri, 19 Jan 2024, Debian Bug Tracking System wrote:
>  furo (2023.09.10+dfsg-3) unstable; urgency=medium
>  .
>* included the code from normalize.css into furo.css instead of
>  the include directive. Closes: #1060897

Thanks for this fix! Unfortunately, this only solves one of the two
problems that I reported in #1060897 (I know that I should have opened two
bugs...).

The other one was about the javascript in furo.js failing to execute (at
least in Firefox in unstable) with this error message:

Uncaught SyntaxError: import declarations may only appear at top level of a 
module

As I said in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1060897#10
that import statement is not present in a regular furo.js as built
by the upstream build system because the file is post-processed and
minified. Ex here:
https://pradyunsg.me/furo/_static/scripts/furo.js

So I assume we need to post-process the file in some similar way to get it
to work or tweak the way we import the code to allow the import statement
to work but I'm not a big fan of diverting too much from upstream and we
are doing this a lot here (but it's often unavoidable with all packages
relying on the node ecosystem in some way). :-(

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



Bug#1060897: standalone is permitted, when the local web server is in use

2024-01-19 Thread Raphael Hertzog
Hi,

On Thu, 18 Jan 2024, Georges Khaznadar wrote:
> On Thu, 18 Jan 2024 13:55:20 +0100 Raphael Hertzog  wrote:
> > [...] reported here and that you can see here:
> > https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html
> 
> when I browse this URL with the debugger's console active, I see that:
> 
> The resource from 
> “https://hertzog.pages.debian.net/javascript/normalize.css/normalize.css” was 
> blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: 
> nosniff).
> 
> Probably, it the webserver is configured to serve normalize.css as MIME
> type "text/css", the issue might be fixed.

No, this is unrelated. The URL you list is just not valid. This domain
is managed by GitLab Pages and anything generated by the CI must
be self-contained in 
https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/

The fact that you have hardcoded an absolute link to
"/javascript/normalize.css/normalize.css" (which might work on a default
installation of a Debian server) means the resource is now looked up
outside of its artifact directory, and there's just nothing there
that can understand the purpose of its URL. You could have received
an error 404 just as well but you got something else presumably because
GitLab Pages has a number of hardening features to avoid malicious
behaviour.

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



Bug#1060897: standalone is permitted, when the local web server is in use

2024-01-18 Thread Raphael Hertzog
Hi Georges,

On Thu, 18 Jan 2024, Georges Khaznadar wrote:
> Would you like to enable documents generated with furo to be usable even
> when accessed under a file:// scheme?

Yes, but I'd also like them to work when hosted on a random non-Debian 
webserver.
My use case is documentation generated out of git and hosted on Gitlab
pages.

This is how I manage https://freexian-team.pages.debian.net/debusine/ and
it works well, but when I tried to move that to furo I encountered the
issues that I reported here and that you can see here:
https://hertzog.pages.debian.net/-/debusine/-/jobs/5153568/artifacts/docs/_build/html/index.html

> (1) I made an ITP for furo and packaged it for Debian, primarily because
> I am maintaining the package sympy, and that once upon a time, it began
> build-depending on furo.

I assumed it was needed as a dependency and not your primary interest,
thanks for packaging it anyway! It's actually a nice theme.

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#1060897: furo: documentation generated with Debian's furo package doesn't work standalone

2024-01-16 Thread Raphael Hertzog
On Tue, 16 Jan 2024, Raphaël Hertzog wrote:
> - the dark/light theme switcher is hidden because I have a ".no-js" class
>   that is not removed by _static/scripts/furo.js because that script fails
>   on the first import line (Uncaught SyntaxError: import declarations may
>   only appear at top level of a module). This line has been patched
>   by the Debian packaging, but I'm not sure if the change is the source of
>   the problem.

FWIW the official version post-process the javascript file and there's no
visible import in the file there. So the issue seems to be that we are
copying javascript files without any post-processing.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   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

2024-01-07 Thread 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


Bug#1042989: ITP: Incus -- Powerful system container and virtual machine manager

2023-12-27 Thread Raphael Hertzog
Hello,

On Tue, 26 Dec 2023, Mathias Gibbens wrote:
> On Mon, 2023-12-25 at 12:52 +0100, Raphael Hertzog wrote:
> > I would really like to see incus in unstable/testing and even in
> > bookworm-backports at some point.
> 
>   Given the large number of new/updated dependencies for Incus, it
> would be a lot of work to properly prepare a release for bookworm-
> backports once Incus gets into unstable. Not saying that it couldn't be
> done, but I don't know if it would be worth the effort. If you would
> like to use Incus on bookworm right now, probably the best approach
> would be to install the package from Stéphane's repo:
> https://github.com/zabbly/incus.

If we want to run debusine on a DSA-managed servers, we need to have
packages available on official Debian repositories, hence
bookworm-backports as installing packages from testing/unstable is out of
question. :-|

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#1042989: ITP: Incus -- Powerful system container and virtual machine manager

2023-12-25 Thread Raphael Hertzog
Hello,

On Sat, 21 Oct 2023, Free Ekanayaka wrote:
> raft 0.17.7-1 is now in unstable, and I've uploaded cowsql 1.15.3-1,
> which is waiting in the NEW queue.

This one is available in unstable now. I would really like to see incus
in unstable/testing and even in bookworm-backports at some point.

We are considering to use LXD in the context of debusine[1] but given the
latest developments with Canonical, it would make sense for us to start
directly with incus.

I think it would make sense to upload current (non-LTS) versions in
unstable right ahead and then stick to the LTS version once they have
released it.

Cheers,

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



Bug#1054220: Off-by-one when selecting days in activity window

2023-11-15 Thread Raphael Hertzog
forwarded -1 https://github.com/projecthamster/hamster/issues/590

On Thu, 19 Oct 2023, Lee Garrett wrote:
> steps to reproduce:
> 
> - click on the + icon ("add activity") in the main window
> - on the start time, clik on the arrow next to the date
> - (a calendar pops up)
> - click on e.g. Wednesday, October 18
> - notice that the cmdline sets it to 2023-10-17, a whole day wrong

I believe this to be fixed in master, unfortunately no upstream release
happened in a very long time due to multiple issues.

https://github.com/projecthamster/hamster/commit/b3dc385c25c33ea5fac697e7e43cc2233234a64d

But there are possibly other related issues:
https://github.com/projecthamster/hamster/issues/627

I pinged upstream to try to get a new release.

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



Bug#1053488: ITP: django-jsonfield -- Reusable JSONField for Django Models

2023-10-13 Thread Raphael Hertzog
Hello Edward,

On Thu, 05 Oct 2023, Edward Betts wrote:
>   jsonfield is a reusable model field that allows you to store validated JSON,
>   automatically handling serialization to and from the database. It is
>   particularly useful when your app needs to be database-agnostic or when the
>   built-in JSONField's extended querying is not being leveraged.
> 
> This library is a dependancy of the django-bulk-update module.
> 
> I plan to maintain this package as part of the Python team.

It seems a bad idea to me to introduce this library into Debian. Django
has a native JSONField that is database agnostic for a few releases now:
https://docs.djangoproject.com/en/4.2/ref/models/fields/#jsonfield

And I used to maintain an external "jsonfield" already which I recently
removed for that precise reason:
https://tracker.debian.org/pkg/python-django-jsonfield

Thus I think that you should work with django-bulk-update upstream to
make it possible to use Django's native field.

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



Bug#839403: apt: define default pin priority for a source in sources.list directly

2023-10-05 Thread Raphael Hertzog
Hello,

On Sat, 01 Oct 2016, Raphaël Hertzog wrote:
> Hello I would like to be able to use something like this in my
> sources.list:
> 
> deb [pin-priority=500] http://ftp.debian.org/debian experimental main

Today I stumbled upon another case where something like this would have
been useful, to be able to tweak priorities of APT repositories injected
in autopkgtest test chroots with --add-apt-release:
https://salsa.debian.org/freexian-team/debusine/-/merge_requests/300#note_432326

This feature request doesn't seem super hard to implement, is there any
chance that someone could tackle it?

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



Bug#1053462: debian-security-support: merge .ended and .limited files together

2023-10-05 Thread Raphael Hertzog
On Wed, 04 Oct 2023, Santiago Ruano Rincón wrote:
> > We could have a single file per release with 3 fields:
> > 
> > * package (or package regexp)
> > * supported (true/false), trues implies limited support, false means not 
> > supported
> > * comment (should explain the limitation if supported == true)
[...]
> I like the above suggestion. Just wondering why don't keep the "latest
> version with support" and "Date when support ended or will end" fields
> currently found in "ended" files.

It's just an oversight, I forgot about those fields.

But to be honest, I'm not sure that the first one is actually useful: what
does "latest version with support" mean? Version X might be supported now
and might no longer be supported in one year. And how does it mesh with
backports?

The date one might be more useful indeed, when we decide to follow the
upstream support schedule for instance.

On the opposite, it might be useful to be able to say that the source
package is still supported but only when you use at least version X
because we have switched to a backport of a new upstream version compared
to the version initially provided (it would be a special case of limited
support? or maybe we need to have different types of entries in the file?)

(If we make those changes, it's probably also the right time to take care of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765452 with the
possibility to exclude some binary packages.)

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#975301: split security-support-limited into release specific files

2023-09-27 Thread Raphael Hertzog
Hi,

On Tue, 26 Sep 2023, Santiago Ruano Rincón wrote:
> > > Agreed, a split makes sense, it causes marginal additional overhead and 
> > > makes
> > > the whole setup more explicit.
> > 
> > cloning this bug once more so we don't forget about this.
> 
> (I think the moreinfo tag comes from the original bug)
> 
> I hope this MR correctly splits the limited support file:
> https://salsa.debian.org/debian/debian-security-support/-/merge_requests/17

As I commented on the MR, I think it would be a good move to merge "ended"
and "limited" files together. This will require more code changes but
gives a clearer overview of the restrictions affecting a given release.

We could have a single file per release with 3 fields:

* package (or package regexp)
* supported (true/false), trues implies limited support, false means not 
supported
* comment (should explain the limitation if supported == true)

We could keep an unversioned file (for unstable?) that would serve as
template when we have to create a new release.

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#1051785: gdm3 won't allow logins when a smarcard with a x.509 credential is plugged in

2023-09-14 Thread Raphael Hertzog
Hello,

On Tue, 12 Sep 2023, Paul Tagliamonte wrote:
> I upgraded my sid system, and post-upgrade gdm3 isn't showing my face
> when I reboot, and entering my username causes it to loop back to
> username entry again (no password prompt). After some help from smcv, I
> narrowed down the issue to the interactions between my smartcard
> development tools installed locally and gdm3.

In my case, I don't have any "smartcard development tools" (at least not
on purpose), I just have a smartcard inserted with a single GPG key used
for "authentication" (i.e. mainly for SSH logins).

$ gpg --card-status 
Reader ...: Alcor Micro AU9540 00 00
Application ID ...: D276000124010201000540DD
Application type .: OpenPGP
Version ..: 2.1
Manufacturer .: ZeitControl
[...]
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 32 32 32
PIN retry counter : 3 0 3
Signature counter : 0
Signature key : [none]
Encryption key: [none]
Authentication key: 1CAC 8718 CAA0 C7B9 1EC0  E907 F1CA EE10 6CE6 97F8
  created : 2022-01-19 08:31:51

> (I do not have libpam-sss installed - after I got this error I installed
>  it to see if I could unlock myself, but it didn't do much and I purged
>  it again).

At least after I installed libpam-sss, I got an error message asking me
to introduce another smartcard so we could indeed figure out that it was
related to the smartcard.

> My hunch is that I believe gdm-smartcard thinks it's supposed to kick
> into gear and authenticate my smartcard, but it isn't configured to do
> so (heck, it hasn't been told how to match my UPN/Email
> SAN/Subject/Serial to UID, nor an x.509 CA to use for user
> authentication). However, it kicking into gear has kicked me out of my
> ability to login :)

That's likely due to the fact that gdm-smartcard required dependencies
(at least libpam-sss) were missing. So yeah it seems like that
gdm-smartcard should have a better failure mode when its prerequisites are
missing.

Putting here the reportbug generated info for the computer where I
experienced the issue:

Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-security'), (500, 'unstable'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.4.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdm3 depends on:
ii  accountsservice   23.13.9-4
ii  adduser   3.137
ii  dbus [default-dbus-system-bus]1.14.10-1
ii  dbus-bin  1.14.10-1
ii  dbus-daemon   1.14.10-1
ii  dconf-cli 0.40.0-4
ii  dconf-gsettings-backend   0.40.0-4
ii  debconf [debconf-2.0] 1.5.82
ii  gir1.2-gdm-1.045~beta-1
ii  gnome-session [x-session-manager] 44.0-4
ii  gnome-session-bin 44.0-4
ii  gnome-session-common  44.0-4
ii  gnome-settings-daemon 45~rc-1
ii  gnome-shell   44.4-1
ii  gnome-terminal [x-terminal-emulator]  3.49.99-1
ii  gsettings-desktop-schemas 45~rc-1
ii  libaccountsservice0   23.13.9-4
ii  libaudit1 1:3.1.1-1
ii  libc6 2.37-7
ii  libcanberra-gtk3-00.30-10
ii  libcanberra0  0.30-10
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libgdm1   45~beta-1
ii  libglib2.0-0  2.78.0-1
ii  libglib2.0-bin2.78.0-1
ii  libgtk-3-03.24.38-5
ii  libgudev-1.0-0237-2
ii  libkeyutils1  1.6.3-2
ii  libpam-modules1.5.2-7
ii  libpam-runtime1.5.2-7
ii  libpam-systemd [logind]   254.1-3
ii  libpam0g  1.5.2-7
ii  librsvg2-common   2.54.7+dfsg-2
ii  libselinux1   3.5-1
ii  libsystemd0   254.1-3
ii  libx11-6  2:1.8.6-1
ii  libxau6   1:1.0.9-1
ii  libxcb1   1.15-1
ii  libxdmcp6 1:1.1.2-3
ii  metacity [x-window-manager]   1:3.49.1-1
ii  mutter [x-window-manager] 44.4-2
ii  polkitd   123-1
ii  procps2:4.0.3-1
ii  systemd-sysv  254.1-3
ii  ucf   3.0043+nmu1
ii  x11-common1:7.7+23
ii  x11-xserver-utils   

Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates

2023-08-19 Thread Raphael Hertzog
Hi,

Le samedi 19 août 2023, David Kalnischkies a écrit :
> > Agreed. It would be nice to document that we can use regex here and
> > that it actually makes sense to do so as most Debian release are actually
> > composed of multiple repositories.
> 
> The problem is that regex is NOT supported at the moment.

Urgh, and you did not complain that the release notes actually encourage
users to do that?

> It happens to work in most commands, but it e.g. doesn't in 'source'.
> 
> Before we could (leaving alone the question if we should) document it
> as supported, we would need to check all commands and fix those which do
> not work with it. Nobody did in the last couple of years.
> 
> So the only reasonable solution for this request so far is to document
> it explicitly as not supported… which helps exactly nobody.

Well, it's always nice to document the known limitations and thus invite
users to prefer explicit pinning over usage of APT::Default-Release which
is commonly used in a configuration file.

> Step back and question why you want to use the option. There are
> probably easier and simpler ways. Adding backports e.g. doesn't need
> pinning at all (it comes by default with 100). Adding unstable to stable
> might be a bad idea to begin with, but is certainly better dealt with
> a pin against unstable rather than trying to catch all your "good"
> "stable" repos in a regex to filter out the one bad "unstable" apple.

I understand that but in my mental model, it was more like "as soon as
you add other suites, make sure to document the preferred release with
APT::Default-Release" instead of the opposite (i.e. make sure to pin down the
repositories that you don't want to use by default).

Clearly I have often used that when I added a newer release in
sources.list (be it unstable/testing or just stable on an oldstable server
or similar).

Is there any difference of behaviour between reducing pin of alternate
releases to a value < 500 vs increasing the priority of the desired
release to 990?

> In preferences the regex actually works and is documented, which is the
> deeper reason behind APT::Default-Release working with regex or not as
> certain commands can rely on the preferences infrastructure while
> a command like 'source' can currently not and hence implements it
> differently without support for a lot of things possible elsewhere.

Maybe it can be documented as a limitation of the source command instead
of refusing to acknowledging what works and what's used?

> If you can come up with a list of use cases for that option (personally,
> I don't see a good one) without too much by-catch we might be able to
> implement a transition notice like I did for non-free-firmware.
> Too late, too little, but at least it would prevent future misuse.

Maybe you should deprecate the option in the configuration file and
invite users to switch to preferences?

I don't know what's best. It would still be nice to have a simple syntax
that would match the -security repo, the -updates repo and the main repo
for a given release... but maybe it should rely on a new "PartOfRelease"
field in the various "Release" files or something like that.

Cheers,
-- 
Raphaël Hertzog


signature.asc
Description: PGP signature


Bug#1041708: apt: Manpages have wrong advice on APT::Default-Release preventing security updates

2023-08-18 Thread Raphael Hertzog
Hello,

Le samedi 22 juillet 2023, Daniel Gröber a écrit :
> > (eventually an update/security fix will be part of stable via a point
> >  release, so such a setting considerably delays the updates, but doesn't
> >  prevent them as such. While I wouldn't recommended it, there might be
> >  people who desire exactly this behaviour…)
> 
> Ah, I didn't realise this is something that can be relied on. In that case
> the problem is a lot less concerning indeed.

This holds true only for the first 3 years where there are point releases
that are generated. Afterwards, the security updates stay in the
security repository and are never merged. So we can't really rely on this
only.

> > As you may have noticed, the 'stable' doesn't include 'stable-updates'
> > either and that isn't new – and also part of the reason for this funny
> > regex. I was surprised then I discovered that entry the first time in
> > the release notes as we were never asked about it.
> 
> Looking at the apt.conf and apt_preference manpages there is still no
> mention of the regex support, perhaps this should be documented there?

Agreed. It would be nice to document that we can use regex here and
that it actually makes sense to do so as most Debian release are actually
composed of multiple repositories.

Cheers,
-- 
Raphaël Hertzog



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

2023-08-17 Thread 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

2023-07-20 Thread 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#1026408: cryptsetup-nuke-password: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

2023-07-06 Thread Raphael Hertzog
Hello Paulo,

thank you for your NMU. I imported the NMU in Git. In the future,
it would be best if you could submit a merge request straight away
instead of sharing a debdiff (or even commit directly your changes).

Cheers,

On Mon, 19 Jun 2023, Paulo Henrique de Lima Santana wrote:
> Hi,
> 
> I uploaded a NMU to 10-day/delay queue. Feel free to cancel this
> upload if needed.
> 
> The debian/changelog is:
> 
> cryptsetup-nuke-password (4+nmu1) unstable; urgency=medium
> 
>   * Non-maintainer upload.
>   * Update po file into Brazilian Portuguese translation. (Closes: #1026408)
>   * Update po file into Italian translation. (Closes: #1017486)
>   * Update po file into Portuguese translation. (Closes: #1028253)
>   * debian/control
> + Bump Standards-Version 4.6.2
> 
> I attached a debdiff.


-- 
  ⢀⣴⠾⠻⢶⣦⠀   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#1038121: tracker.debian.org: debian/patches check vs. single-debian-patch in debian/source/local-options

2023-06-16 Thread 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#1036661: hamster-time-tracker: missing dependency on python3-gi-cairo

2023-06-09 Thread Raphael Hertzog
Control: tag -1 + pending

On Wed, 24 May 2023, Gerald Jansen wrote:
> see https://github.com/projecthamster/hamster/issues/722

Thanks for the report. I committed a fix in the repository. Now waiting
for the next upstream release that shouldn't be too far in the future
from what I saw in recent activities :-)

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



Bug#1035972: isc-dhcp EOL'ed

2023-05-12 Thread Raphael Hertzog
Hello Santiago,

On Thu, 11 May 2023, Santiago Ruano Rincón wrote:
> ISC is not longer maintaing any of the components of isc-dhcp (client,
> relay or server):
> https://lists.isc.org/pipermail/dhcp-users/2022-October/022786.html
> https://www.isc.org/blogs/isc-dhcp-eol/
> 
> I propose to mark it as unsupported. Or at least, limited, if we still
> have hope in those security update exceptions they claim they could do.

We are speaking of packages that are installed in the vast majority of
Debian systems:
https://qa.debian.org/popcon.php?package=isc-dhcp

It's not a service to our users to claim that we will not support them.
This is a reason for us to start moving away from them in
unstable/testing (but who will do that? You might want to raise the
discussion on -devel and get some bugs filed).

But I'm afraid that we will have to keep maintaining those for the benefit
of our stable/oldstable (and even ELTS) users. I'm pretty sure that all
the other distributions will also continue to maintain those packages for
the lifetime of their respective releases so that we will have
opportunities to share the workload and patches.

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#1034875: kitty: Should not handle application/x-sh mime type by executing the script

2023-04-26 Thread Raphael Hertzog
Package: kitty
Version: 0.26.5-4
Severity: serious
Tags: security
X-Debbugs-Cc: Debian Security Team 

Hello,

I was reading https://lists.debian.org/20230425190728.ga1471...@subdivi.de
in mutt and that mail contains 3 shell scripts as attachments
(application/x-sh). I wanted to have a look at the scripts and thus I
"opened" those attachments... that open operation has been handled by
Kitty due its MimeType declaration in
/usr/share/applications/kitty-open.desktop [1] and the shell script has
thus been fed to "kitty +open 

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

2023-04-17 Thread 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

2023-02-27 Thread 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

2023-02-27 Thread 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

2023-02-26 Thread 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

2023-02-26 Thread 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

2023-02-25 Thread 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

2023-02-25 Thread 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#1028310: hamster-time-tracker: please make the build reproducible

2023-02-25 Thread Raphael Hertzog
Control: tag -1 + pending

Hi,

On Mon, 09 Jan 2023, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> hamster-time-tracker could not be built reproducibly.
> 
> This is because it varied depending on whether it was built with a
> 32- or 64-bit kernel. This resulted in a different value for defs.LIB_DIR.
> 
> However, I don't believe this definition is actually used (it seems to
> be just one of many pre-populated fields from a generic build system),
> so the attached proof-of-concept patch simply removes the line from
> defs.py.in.

Thanks, I applied your patch to git but I will not make a new release
given that we are in a freeze.

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

2023-02-07 Thread 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



Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

2023-02-02 Thread Raphael Hertzog
(Adding Colin Watson as he might have feedback on Ubuntu's uses
 of the various Release fields and on the likeliness to fix/change them)

Hello,

On Wed, 01 Feb 2023, Paul Gevers wrote:
> > I fear I've probably forgotten most of these details, so please pardon
> > me for this response… Wasn't the problem for Ubuntu that 'Pin: release
> > foo' also applies to foo-proposed too? I think 'Pin: release
> > foo-proposed' will work as intended though, right?  Is the latter what
> > we'll start generating with this? Seeing some example generated pins
> > (before / after the patch) would be great to help reason about this.
> 
> The patch also removes the "a=" from the pinning for the default release (at
> 990) and I think that will break Ubuntu's setup as the packages from the
> proposed pocket will suddenly satisfy this pin too. What you (Iain)
> discussed above works for the pocket/foo-proposed part, but I think Raphael
> needs the other part too. I fear that without additional options, we can't
> really fix this.

At this point I need neither part because I have added "Suite" names in
Kali. But I think this behaviour is still entirely unlogical and will bite
others in the future.

I would suggest to:
- apply the first hunk of my patch since this one seems to be fine
- skip the change for the default release
- document the limitation in --apt-default-release that it will only
  match packages from archives where "Suite" or "Archive" has this value
  (and maybe point back to this bug to find the context)

> > I guess a test covering this for all of the Ubuntu, Debian & Kali cases
> > would be helpful in terms of confidence both with this change and making
> > any future changes here. The one thing I do remember is that it's hairy,
> > like all the pinning stuff in autopkgtest. :-)
> 
> Yes. In the same area; for Debian I once had a proposal to set the
> Default-Release instead of using the pinning, but that broke Ubuntu's case.

Indeed, as I shared in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002819#10
Default-Release is actually implemented with the same code as the
suggested pinning.

> It would have reduced another hairy part of autopkgtest tremendously, where
> a lot of sed/awk/grep-ing happens in the testbed to figure out which version
> of the source to install for the test. But alas, autopkgtest needs to
> support the Ubuntu archive.

To be fair, the set of available fields to describe a repository are not
very good, not very well documented and not easy to grasp.

In my experience, Codename is the reference field that gives a canonical
name. Suite is an alias that can move. And Archive is never used.

The Ubuntu usage is not consistent with the above practice and they seem
to use "Codename" as some sort of "Parent-Repository" or
"Reference-Repository". There's no such field really and yet it would make
sense to have one when you want to target all repositories that are
compatible with a given release.

I doubt that there's any chance that Ubuntu will fix their use of the
Codename field but I'm putting Colin Watson in CC in case he can shed some
light here.

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#893083: hello: Packaging should be hosted on salsa.debian.org

2022-12-27 Thread Raphael Hertzog
On Mon, 26 Dec 2022, Santiago Vila wrote:
> So, suppose that someone has a package requiring the above for "gbp 
> buildpackage" to work.
> Does the package have a disclaimer somewhere saying "plain dpkg-buildpackage 
> is not supported
> here" or something alike?

You can document any discrepancy in debian/README.source in general.

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



Bug#893083: hello: Packaging should be hosted on salsa.debian.org

2022-12-26 Thread Raphael Hertzog
Hello,

On Fri, 23 Dec 2022, Santiago Vila wrote:
> For example, this one:
> 
> I have just imported version 2.10-2. Now dpkg-buildpackage
> does not work because it expects some timestamps to be the ones in the
> orig.tar.gz where upstream maintainer already ran autoconf and friends.
> 
> I know that autoreconf may help here, but I would prefer not to be forced
> to use it. What are my options?
>
> Is there some git-buildpackage specific solution for this?

Yes, I think so. Use --git-export-dir=../build-area/ (many persons
have it in their ~/.gbp.conf).

$ cat ~/.gbp.conf
[DEFAULT]
pristine-tar = True
cleaner = /bin/true

[buildpackage]
sign-tags = True
export-dir = ../build-area/
ignore-branch = True
ignore-new = True

[import-orig]
filter-pristine-tar = True

[pq]
patch-numbers = False

[dch]
multimaint-merge = True
ignore-branch = True


That way git-build-package will run the build in a fresh tree where
all the files will have the same timestamp.

> Related to the above: Is it acceptable/desirable to put a package in git when 
> it may not
> be compiled from git yet? Or maybe I should start the git history in a point 
> where such build
> from git is actually possible? Should I add a warning somewhere that only the 
> latest
> version is expected to work, or maybe that's already implicit?

It's certainly OK if the initial import does not work and if only the
latest version is really working. It would be surprising that the checkout
of the released tag does not work but it would not be a big deal either.

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



Bug#1026802: python3.10: Should be built with --with-ssl-default-suites=openssl

2022-12-21 Thread Raphael Hertzog
Package: python3.10
Version: 3.10.9-1
Severity: wishlist
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: de...@kali.org

Hello Mathias (and other Python maintainers),

it would be nice if python3.10 (and future versions) could be built with
--with-ssl-default-suites=openssl.

Starting with Python 3.10, with the default configuration
("--with-ssl-default-suites=python"), Python not only enforces its own
cipher list but also requires TLS1.2 as a minimal protocol version.

This is certainly a sensible thing to do in the context of Python upstream
where you don't know much about the rest of the environment but in the
context of Debian, it makes sense to not duplicate such restrictions at
all levels and leave that to the sane defaults that are regularly reviewed
in the openssl source package itself (which currently sets
OPENSSL_TLS_SECURITY_LEVEL=2).

This also means that it's possible for users to actually override the
system wide defaults through changes to /etc/ssl/openssl.cnf and we are
actually making this possible in Kali to reduce the security level and
make it possible to access old insecure servers. However despite our
changes, the Python applications are not able to use old TLS versions,
due to the restrictions imposed by Python itself.

Credit goes to Adrian Vollmer who reported this to Kali here:
https://bugs.kali.org/view.php?id=8097

Let me know if you are open to this idea, and if you want a merge request.

Cheers,

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3.10 depends on:
ii  libpython3.10-stdlib  3.10.9-1
ii  media-types   8.0.0
ii  mime-support  3.66
ii  python3.10-minimal3.10.9-1

python3.10 recommends no packages.

Versions of packages python3.10 suggests:
ii  binutils 2.39.50.20221208-5
ii  python3.10-doc   3.10.9-1
pn  python3.10-venv  

-- no debconf information

-- 
Raphaël Hertzog



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

2022-12-16 Thread 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



Bug#1020056:

2022-11-02 Thread Raphael Hertzog
Hello,

Le jeudi 13 octobre 2022, Thomas Braun a écrit :
> so I think it should be as easy as adding cppzmq-dev to the build
> dependencies.
> 
>  $diff -Nur control control.new
> --- control 2022-10-13 16:19:07.384578078 +0200
> +++ control.new 2022-10-13 16:19:03.972578004 +0200
> @@ -7,6 +7,7 @@
> default-libmysqlclient-dev,
> libcos4-dev,
> libzmq5-dev | libzmq3-dev,
> +   cppzmq-dev,
> omniidl,
> po-debconf
>  Build-Depends-Indep: doxygen,

FWIW, there's also a related MR here:
https://salsa.debian.org/science-team/tango/-/merge_requests/3

That MR replaces the "libzmq5-dev | libzmq3-dev" build dep with
cppzmq-dev. But the CI in the MR failed, though it seems to be for
unrelated reasons.

Adrian, I see you tagged this bug as pending. Why? I don't see any
fix pushed to git yet.

Cheers,
-- 
Raphaël Hertzog



Bug#1010660: Got the error in Kali too

2022-10-04 Thread Raphael Hertzog
Hello,

we have been bitten by this in Kali too. In our case Arnaud Rebillout
worked around it by adding a hint. Here's what he said:


The issue was a circular dependency between
`libnginx-mod-http-lua/1:0.10.22-2` and `lua-resty-core/0.1.24-2`. It was
solved with the following hints:

# 2022-10-04
easy libnginx-mod-http-lua/1:0.10.22-2 lua-resty-core/0.1.24-2 nginx/1.22.0-3
force-badtest squid/5.6-1

The force-badtest on squid was needed to let nginx pass, which was in turn
required to let libnginx-mod-http-lua pass.

Now britney is happy again, and I could remove the autohinter patch.


Cheer,
-- 
Raphaël Hertzog



Bug#1018288: waagent: Debian specific patch breaks kali support

2022-10-04 Thread Raphael Hertzog
Hello,

Le lundi 29 août 2022, Bastian Blank a écrit :
> On Sun, Aug 28, 2022 at 12:38:21PM +0200, Raphaël Hertzog wrote:
> > Please re-add the import statement. There's a merge request lying around
> > since one year:
> > https://salsa.debian.org/cloud-team/waagent/-/merge_requests/3
> 
> This will be fixed this way: https://github.com/Azure/WALinuxAgent/pull/2660

Unfortunately, that pull request has been declined upstream. Can we have a
simpler fix in the mean time?

Cheers,
-- 
Raphaël Hertzog



Bug#1012563: wireplumber: right click broken in firefox 100.0.2-1

2022-09-19 Thread Raphael Hertzog
Hello Dylan,

On Tue, 13 Sep 2022, Dylan Aïssi wrote:
> Do you have a special audio configuration?

No.

> > So somehow, wireplumber + pipewire-pulse is not properly
> > detected as something that can be controlled with the "pulse-rust" audio
> > backend when it likely should be that way...
> 
> May I ask you to give wireplumber a second chance to check if you can
> reproduce this issue?
> Just install wireplumber, this will remove pipewire-media-session. No
> need to remove the
> "with-pulseaudio" file. After a reboot I hope everything will be fine.

It seems to work now with firefox 104.0-1 and wireplumber 0.4.11-4.

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



Bug#1019259: devscripts: The command uscan with the option 'dehs' doesn't always generate valid XML ouput

2022-09-07 Thread Raphael Hertzog
Control: tags -1 - moreinfo

Hello Yadd,

Please keep the bug submitter on copy, otherwise you can't expect to get
replies.

Le mardi 06 septembre 2022, Yadd a écrit :
> uscan generates a valid XML on STDOUT and displays messages on STDERR. Use
> `uscan --dehs 2>/dev/null`

That was my expectation also but I double checked and it doesn't display
messages on STDERR:

┏t14-buxy:~/deb/pkg/zim (master)
┗(freexian,534)$ uscan --dehs --upstream-version 0.74 >/dev/null
┏t14-buxy:~/deb/pkg/zim (master)
┗(freexian,535)$ uscan --dehs --upstream-version 0.74 2>/dev/null

uscan: Newest version of zim on remote site is 0.74.3, local version is 0.74
uscan:  => Newer package available from:
=> https://zim-wiki.org/downloads/zim-0.74.3.tar.gz
Leaving ../zim_0.74.3.orig.tar.gz where it is.
zim
0.74
0.74
0.74.3
https://zim-wiki.org/downloads/zim-0.74.3.tar.gz
newer package available
zim_0.74.3.orig.tar.gz
../zim_0.74.3.orig.tar.gz
Not downloading, using existing file: zim-0.74.3.tar.gz




Cheers,
-- 
Raphaël Hertzog



Bug#1018878: live-build: dealing with firmware files provided by multiple packages

2022-09-01 Thread Raphael Hertzog
Package: live-build
Version: 1:20220505
Severity: normal
User: de...@kali.org
Usertags: origin-kali

Looking closely at the issue that I reported in #1018873, I realize that
the Contents file have those entries:
lib/firmware/nvidia/470.141.03/gsp.bin  
non-free/kernel/nvidia-kernel-support,non-free/kernel/nvidia-tesla-470-kernel-support
lib/firmware/nvidia/510.85.02/gsp.bin   
non-free/kernel/nvidia-tesla-510-kernel-support,non-free/kernel/nvidia-tesla-kernel-support

But live-build only tries to install "nvidia-tesla-470-kernel-support" and
"nvidia-tesla-kernel-support" so the last packages mentionned on each
line. It completely ignores the first package...

But given that two packages providing the same file are conflicting, we
can't install both packages. But we have no hints on which package
is most appropriate either.

This sounds like sub-optimal packaging on the nvidia side.

But the problem is real and I believe that live-build should do something
when it detects it instead of randomly picking one or the other.

My suggestion is "skip the line entirely and put a warning in the log".

What do you think?

-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages live-build depends on:
ii  debootstrap  1.0.127

Versions of packages live-build recommends:
ii  apt-utils   2.5.2
ii  bzip2   1.0.8-5
ii  cpio2.13+dfsg-7
ii  cryptsetup  2:2.5.0-2
ii  file1:5.41-4
ii  live-boot-doc   1:20220505
ii  live-config-doc 11.0.3
ii  live-manual-html [live-manual]  2:20151217.2
ii  rsync   3.2.5-1
ii  systemd-container   251.4-1
ii  wget1.21.3-1+b2
ii  xz-utils5.2.5-2.1

Versions of packages live-build suggests:
ii  e2fsprogs  1.46.5-2
ii  mtd-utils  1:2.1.4-1+b1
ii  parted 3.5-1

-- no debconf information

-- 
Raphaël Hertzog



Bug#1018873: live-build --firmware-chroot option is broken due to nvidia-tesla{-470,}-kernel-support

2022-09-01 Thread Raphael Hertzog
Package: nvidia-tesla-kernel-support
Version: 510.85.02-1
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com, Andreas Beckmann 
, sop...@offensive-security.com
Control: affects -1 live-build

Hello,

if you run live-build with non-free enabled and with "--firmware-chroot true"
then you will get this failure:


[2022-09-01 03:02:53] lb chroot_install-packages install
P: Begin installing packages (install pass)...
Reading package lists...
Building dependency tree...
Reading state information...
util-linux-extra is already the newest version (2.38.1-1).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 nvidia-tesla-kernel-support : Depends: nvidia-tesla-alternative (= 
510.85.02-1) but it is not installable
   Depends: nvidia-tesla-alternative--kmod-alias
E: Unable to correct problems, you have held broken packages.


The issue is that "lb chroot_firmware" identifies all the firmware packages
by the fact that they provide files in /lib/firmware/ and as such it
identifies nvidia-tesla-470-kernel-support and nvidia-tesla-kernel-support
and adds both to the list of packages to install.

You will get the exact same error as above with:
# apt install nvidia-tesla-470-kernel-support nvidia-tesla-kernel-support

So both packages are not co-installable, the packages themselves should be
co-installable, but some of the dependencies aren't in particular
nvidia-tesla-470-alternative and nvidia-tesla-alternative:
# apt install nvidia-tesla-470-alternative nvidia-tesla-alternative
[...]
The following packages have unmet dependencies:
 nvidia-tesla-470-alternative : Breaks: nvidia-tesla-alternative (> 0) but 
510.85.02-1 is to be installed
E: Unable to correct problems, you have held broken packages.


I'm not sure what's the best way forward. It seems to me that live-build
is doing the right thing by trying to include as many firmware as possible
but at the same time it should likely also be able to exclude a firmware
package that is not installable. But checking installability is a
significant penalty and complexity.

So I would certainly prefer if the nvidia packages providing firmwares
could be co-installable. If that's really not possible, then it would be
nice to add some sort of flag to mark the firmware package that should not
be installed by default.

Would it be possible for example to move nvidia-tesla-470-alternative and
nvidia-tesla-alternative into Recommends instead of Depends ?

Or move the firmware files to some common package without the problematic
dependencies?

Thank you for looking into this issue.

-- Package-specific info:

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages live-build depends on:
ii  debootstrap  1.0.127

Versions of packages live-build recommends:
ii  apt-utils   2.5.2
ii  bzip2   1.0.8-5
ii  cpio2.13+dfsg-7
ii  cryptsetup  2:2.5.0-2
ii  file1:5.41-4
ii  live-boot-doc   1:20220505
ii  live-config-doc 11.0.3
ii  live-manual-html [live-manual]  2:20151217.2
ii  rsync   3.2.5-1
ii  systemd-container   251.4-1
ii  wget1.21.3-1+b2
ii  xz-utils5.2.5-2.1

Versions of packages live-build suggests:
ii  e2fsprogs  1.46.5-2
ii  mtd-utils  1:2.1.4-1+b1
ii  parted 3.5-1

-- no debconf information

-- 
Raphaël Hertzog



Bug#1018288: waagent: Debian specific patch breaks kali support

2022-08-29 Thread Raphael Hertzog
Hello Bastian,

On Mon, 29 Aug 2022, Bastian Blank wrote:
> On Sun, Aug 28, 2022 at 12:38:21PM +0200, Raphaël Hertzog wrote:
> > Please re-add the import statement. There's a merge request lying around
> > since one year:
> > https://salsa.debian.org/cloud-team/waagent/-/merge_requests/3
> 
> This will be fixed this way: https://github.com/Azure/WALinuxAgent/pull/2660

Thanks for this upstream pull request!

Can you upload a temporary fix in Debian until the next upstream version
gets released?

If you don't want to handle it, I'm happy to propose a non-maintainer upload
with just the import fix in the mean time.

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com



Bug#601203: Released fix in git

2022-08-05 Thread Raphael Hertzog
Control: tags -1 + pending

Hello,

I fixed this issue in git now:
https://salsa.debian.org/images-team/debian-cd/-/commit/8513b237afbdb59a4a59d1bc707d37f0aa9138f7

This was on top of a first cleanup where I turned $add_rec and $add_sug
into global variables:
https://salsa.debian.org/images-team/debian-cd/-/commit/c9489cd926f9b09b1359c17cc651a7a664e537a7

I think it would be great if we could make a new debian-cd upload as we
have some important fixes in git by now.

Steve, do you want to review my latest changes and do an upload?

Let me know if you need help for the upload.

Cheers,
-- 
Raphaël Hertzog ◈ Offensive Security ◈ Kali Linux Developer



Bug#1016090: python-django breaks lots of autopkgtests

2022-08-02 Thread Raphael Hertzog
Hi,

On Mon, 01 Aug 2022, Chris Lamb wrote:
> Regardless of that though, I think we have two options:
> 
> a) Revert back to the 3.2.14 LTS version in Debian unstable.
> 
> b) Wait for the 4.x stream to become designated LTS. I believe this
>should happen with version 4.2, due for release in about 6 or 7
>months:

The Django and Debian releases are not well aligned. The 4.2 release
is planned in April 2023 so a bit late given the freeze. If the number of
reverse dependencies was lower, it could argued to try to have some sort
of exceptions and offering extra work to help fix/migrate the reverse
dependencies.

But unfortunately I assume that most of the important reverse dependencies
track mainly the LTS releases and the upstream fixes for 4.x compatibility
will only materialize once Django 4.2 is released and we would have to
commit to too much work to be able to push Django 4.x (including 4.2~rc1
or similar) in bookworn.

As such, as much as I hate it, I think than only (a) is realistic.

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



Bug#1016090: python-django breaks lots of autopkgtests

2022-08-01 Thread Raphael Hertzog
On Tue, 26 Jul 2022, Paul Gevers wrote:
> Source: python-django
> Control: found -1 python-django/2:4.0.6-1

I'm surprised that we uploaded an non-LTS release to unstable.

Chris, why did you do that? 

> I note that the changelog has this:
> "This security release mitigates the issue, but we have identified
> improvements to the Database API methods related to date extract and
> truncate that would be beneficial to add to Django 4.1 before it's final
> release. This will impact 3rd party database backends using Django 4.1
> release candidate 1 or newer, until they are able to update to the API
> changes. We apologize for the inconvenience."
> 
> I guess that means that these breakages might be intentional, but even if
> all this is to be expected, it would be good to add a *versioned* Breaks to
> python-django3 for all the packages that it really breaks (not just the
> autopkgtest).

I don't think that the above changelog entry is relevant. The issue is
broader, it's more likely that we moved from 3.2 to 4.0 and that many
packages have not been prepared for that switch.

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#1013493: python-django-jsonfield: FTBFS: ImportError: cannot import name 'ugettext_lazy' from 'django.utils.translation' (/usr/lib/python3/dist-packages/django/utils/translation/__init__.py)

2022-07-30 Thread Raphael Hertzog
Hello,

On Fri, 24 Jun 2022, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Thanks but I will not fix this bug. Intsead I have asked to remove
this package from unstable since it has been superseded by a native
field provided by Django:
https://docs.djangoproject.com/en/3.2/ref/models/fields/#jsonfield

Removal bug: https://bugs.debian.org/1016370

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



Bug#1015174: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0

2022-07-26 Thread Raphael Hertzog
Control: tags -1 + patch
Control: user de...@kali.org
Control: usertags -1 + kali-patch

On Sun, 17 Jul 2022 05:50:20 +0200 Cyril Brulebois  wrote:
> I suppose the journal bits could be patched out for the udeb build (right
> now, configure ends up defining SYSTEMD_JOURNAL_SUPPORT to 1 there), but
> I'm not sure what consequences disabling APP_MACHINEID_SUPPORT in the udeb
> could have for arrays built at installation time (the function call itself
> is already guarded within an #ifdef/#endif block, so it seems somewhat
> optional already).

I confirm that a build with this patch gets rid of the libsystemd0
dependency in the udeb:

diff --git a/debian/rules b/debian/rules
index f1a9df9bd..bef9b2df3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -71,6 +71,8 @@ define CONFARGS.udeb
--with-pool=none
--disable-readline
--disable-selinux
+   --disable-app-machineid
+   --disable-systemd-journal
 endef
 
 BUILDS :=

I looked up the impact of --disable-app-machineid and I concluded that it
should be safe to use it even if the non-udeb build has it enabled.

The option only adds a supplementary source (named "appmachineid") for lvm
to get a "system_id". The DEFAULT_SYSTEM_ID_SOURCE is "none" and it's not
overriden by what we ship as Debian configuration files. Given that it was
non-existent up-to-now, we can be pretty sure that d-i is not overriding
the lvm configuration to set global/system_id_source to "appmachineid".

man lvmsystemid has some explanation about the feature related to
"systemid" and from a quick check on my system, it looks like that
VG created by d-i do not set any system id.

Bastian, do you agree with the above assessment? If yes, can you upload
a fixed package please?

Cheers,
-- 
Raphaël Hertzog



Bug#1014837: distro-info-data: update ELTS data

2022-07-13 Thread Raphael Hertzog
Hi,

On Tue, 12 Jul 2022, Thorsten Glaser wrote:
> 10   Busterbuster2017-06-17  2019-07-06  2022-08-14  
> 2024-06-30  2026-06-30
> 11   Bullseye  bullseye  2019-07-06  2021-08-14  2024-08-14
> 
> However, ELTS support got prolonged: see
> https://deb.freexian.com/extended-lts/docs/debian-8-support/ and
> https://deb.freexian.com/extended-lts/docs/debian-9-support/ for more.
> 
> change jessie eol-elts to 2025-06-30
> change stretch eol-elts to 2027-06-30
> 
> We don’t know about buster ELTS yet, nor if the other LTS data changed,
> but Raphaël would know ☻

For buster, the dates are well aligned with the half-year so we 
will continue with end of LTS as already documented (2024-06-30)
and end of ELTS will be 2029-06-30 (~10 years of support).

For bullseye, things are not defined yet. 

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com



Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea

2022-07-08 Thread Raphael Hertzog
On Wed, 06 Jul 2022, Bernhard Schmidt wrote:
> > As such I really believe that this git snapshot should have stayed in
> > experimental. Why was it uploaded to unstable before its upstream
> > release?
> 
> I respectfully disagree. This is what unstable/testing is for. 2.6 is to be
> released really soon, it contains breaking changes which we need to iron out
> / document with both upstream and Debian packaging. This can't wait until
> the last minute before the freeze. The 2.6 upload was influenced by OpenSSL
> 3.0, but this was definitely not the only reason to do this.

If you were aware of regressions to iron out, it would have made sense to
file an RC bug to avoid the migration to testing until it has matured in
unstable.

I understand it's always a trade off and that not all Debian developers
put the bar at the same level, but keeping testing "constantly usable"
has been something of a goal for a long time.

> This could be discussed with upstream.

I certainly encourage you to discuss with upsream on whether they believe
a git snapshot ought to be delivered to unstable/testing (and thus
ultimately ubuntu too).

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com



Bug#997818: [Pkg-utopia-maintainers] Bug#997818: wireplumber: Failed to preset unit, file /etc/systemd/user/pipewire-session-manager.service already exists

2022-06-10 Thread Raphael Hertzog
Hi,

On Sat, 30 Oct 2021 01:37:53 +0200 Michael Biebl  wrote:
> 
> Am 30.10.2021 um 01:21 schrieb Laurent Bigonville:
> > That also looks RC to me, leaving a dangling symlink is never good, not 
> > too sure how to fix this.
> 
> This preserves the enablement state of the service, similar to how 
> conffiles are removed on "apt remove".
> Only if you purge a package, its conffiles are removed (and its systemd 
> enablement state)
> 
> Are you saying this is not the correct way?

I think we are not speaking of the same thing. The error message
refers to "/etc/systemd/user/pipewire-session-manager.service" and this
one is just a side-effect of the "Alias" directive.

The broken symlink that preserves the "enablement" state of the service
is /etc/systemd/user/pipewire.service.wants/pipewire-media-session.service
and this one doesn't get complained about.

To me it looks like that the symlinks created for the "alias" entries
should be removed when you remove the package if they point to the
alternative provided by the current package and it should be done
automatically by debhelper stuff. We should not have to tweak packages to
do that...

Or, probably better, the setup scripts should detect that the symlink for
the "alias" directive is currently broken and that it should take it over.
I filed this suggestion to systemd:
https://github.com/systemd/systemd/issues/23694

But in the mean time, it's certainly a good idea to manually clean it up
in pipewire-media-session preinst's "remove" to avoid this ugly error:

Paramétrage de wireplumber (0.4.10-2) ...
Failed to preset unit, file 
"/etc/systemd/user/pipewire-session-manager.service" already exists and is a
 symlink to "/lib/systemd/user/pipewire-media-session.service".
/usr/bin/deb-systemd-helper: error: systemctl preset failed on 
wireplumber.service: No such file or directory

Cheers,
-- 
Raphaël Hertzog



Bug#1011063: scp: Received message too long 1163022927

2022-05-19 Thread Raphael Hertzog
On Mon, 16 May 2022 07:44:26 -0400 Stefano Rivera  wrote:
> Now that openssh 1:9.0p1-1 uses the SFTP protocol by default, uploads to
> services using scp are broken.

Note that not all uploads are broken. They are broken when the server side
has a forced command that is expecting scp usage. I have this for example:


#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
scp\ *)
exec scp -p -d -t /srv/deb.freexian.com/extended-lts/incoming
;;
chmod\ *)
find /srv/deb.freexian.com/extended-lts/incoming -user 
$(whoami) -type f | xargs --no-run-if-empty chmod 0644
exit 0
;;
*)
echo "ERROR: Forbidden command: $SSH_ORIGINAL_COMMAND"
echo "This SSH access can only be used to upload Debian 
packages."
exit 1
;;
esac


But without the "-O" option, scp will now call /usr/lib/sftp-server and
the case will match the third case generating unexpected noise for the
SFTP protocol.

There's no good way to tweak that script to force sftp-server to be
restricted to a specific directory.

So either you switch to always "sftp" and do some other setup to restrict
sftp (with the Chroot directive), or you switch to "always plain scp"
by passing -O when you call scp.

Cheers,
-- 
Raphaël Hertzog



Bug#815189: sftp uploader uses wrong user name ordering

2022-04-19 Thread Raphael Hertzog
Control: tags -1 + patch

Hello,

On Fri, 19 Feb 2016 21:55:21 +0100 Michael Kuhn  wrote:
> When using the sftp uploader, the user name from the SSH configuration
> is always preferred, that is, the order is currently: login name, dput
> profile, SSH configuration. This is backwards because one might want to
> override the user name in the dput profile.
> 
> The attached patch fixes the problem by changing the order as follows:
> login name, SSH configuration, dput profile

I have been very surprised by this behaviour too. Mattia, can we get this patch
applied please?

Cheers,
-- 
Raphaël Hertzog



Bug#1008773: ftpsync: Using commands with parameters as hooks breaks ftpsync on bullseye/debian 11

2022-04-01 Thread Raphael Hertzog
Control: tags -1 + patch

I have prepared a merge request with a fix for this issue:
https://salsa.debian.org/mirror-team/archvsync/-/merge_requests/4

(Note that there's another outstanding merge request there that you might
want to merge too)

I'm attaching the patch as well.
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
>From e714ee57d5ee639e0726829114b2f913f1e8941b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 1 Apr 2022 09:48:29 +0200
Subject: [PATCH] Properly quote HOOKSCR assignations

Otherwise ftpsync is failing with bash 5.1 with errors like this:
ftpsync: line 276: local: `hook-parameter': not a valid identifier

Closes: #1008773
---
 bin/ftpsync | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bin/ftpsync b/bin/ftpsync
index 99a2ceb..25cefe5 100755
--- a/bin/ftpsync
+++ b/bin/ftpsync
@@ -591,7 +591,7 @@ fi
 
 HOOK=(
 HOOKNR=1
-HOOKSCR=${HOOK1}
+HOOKSCR="${HOOK1}"
 )
 hook $HOOK
 
@@ -651,7 +651,7 @@ while [[ -e ${UPDATEREQUIRED} ]]; do
 
 HOOK=(
 HOOKNR=2
-HOOKSCR=${HOOK2}
+HOOKSCR="${HOOK2}"
 )
 hook $HOOK
 
@@ -720,7 +720,7 @@ while [[ -e ${UPDATEREQUIRED} ]]; do
 
 HOOK=(
 HOOKNR=3
-HOOKSCR=${HOOK3}
+HOOKSCR="${HOOK3}"
 )
 hook $HOOK
 done
@@ -739,7 +739,7 @@ fi
 
 HOOK=(
 HOOKNR=4
-HOOKSCR=${HOOK4}
+HOOKSCR="${HOOK4}"
 )
 hook $HOOK
 
@@ -782,7 +782,7 @@ if [[ ${HUB} = true ]]; then
 
 HOOK=(
 HOOKNR=5
-HOOKSCR=${HOOK5}
+HOOKSCR="${HOOK5}"
 )
 hook $HOOK
 fi
-- 
2.35.1



Bug#1008772: xrdp: Please integrate NMUs and gitlab MR

2022-04-01 Thread Raphael Hertzog
Source: xrdp
Version: 0.9.17-2
Severity: wishlist
Tags: patch
User: de...@kali.org
Usertags: origin-kali

Hello,

I have just uploaded an NMU prepared by a Kali contributor (in the NM
queue). Please find the relevant "git am" patches attached. (The two
patches by Arnaud are also in https://salsa.debian.org/arnaudr/xrdp)

It fixes CVE-2022-23613 and nothing else.

I noticed that you have open MR on Gitlab that it would be good to handle.
There's a former NMU that was never acked and that doesn't appear in
debian/changelog.

https://salsa.debian.org/debian-remote-team/xrdp/-/merge_requests


-- System Information:
Debian Release: bookworm/sid
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.16.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Raphaël Hertzog
>From 6b20339946d23bae9848c00533d006a35ba16990 Mon Sep 17 00:00:00 2001
From: Arnaud Rebillout 
Date: Fri, 1 Apr 2022 08:25:06 +0700
Subject: [PATCH 1/3] Import upstream patch to fix CVE-2022-23613 (Closes:
 #1005304)

---
 debian/patches/cve-2022-23613.diff | 47 ++
 debian/patches/series  |  1 +
 2 files changed, 48 insertions(+)
 create mode 100644 debian/patches/cve-2022-23613.diff

diff --git a/debian/patches/cve-2022-23613.diff b/debian/patches/cve-2022-23613.diff
new file mode 100644
index ..0a5ebdf1
--- /dev/null
+++ b/debian/patches/cve-2022-23613.diff
@@ -0,0 +1,47 @@
+From: matt335672 <30179339+matt335...@users.noreply.github.com>
+Date: Wed, 2 Feb 2022 10:39:50 +
+Subject: [PATCH] Add lower bound to sesman data input size check
+Origin: upstream, https://github.com/neutrinolabs/xrdp/commit/4def30ab
+
+---
+ sesman/sesman.c | 8 +---
+ 1 file changed, 5 insertions(+), 3 deletions(-)
+
+diff --git a/sesman/sesman.c b/sesman/sesman.c
+index a85769053..e2b057e6a 100644
+--- a/sesman/sesman.c
 b/sesman/sesman.c
+@@ -276,6 +276,7 @@ sesman_close_all(void)
+ static int
+ sesman_data_in(struct trans *self)
+ {
++#define HEADER_SIZE 8
+ int version;
+ int size;
+ 
+@@ -283,9 +284,9 @@ sesman_data_in(struct trans *self)
+ {
+ in_uint32_be(self->in_s, version);
+ in_uint32_be(self->in_s, size);
+-if (size > self->in_s->size)
++if (size < HEADER_SIZE || size > self->in_s->size)
+ {
+-LOG(LOG_LEVEL_ERROR, "sesman_data_in: bad message size");
++LOG(LOG_LEVEL_ERROR, "sesman_data_in: bad message size %d", size);
+ return 1;
+ }
+ self->header_size = size;
+@@ -302,11 +303,12 @@ sesman_data_in(struct trans *self)
+ return 1;
+ }
+ /* reset for next message */
+-self->header_size = 8;
++self->header_size = HEADER_SIZE;
+ self->extra_flags = 0;
+ init_stream(self->in_s, 0); /* Reset input stream pointers */
+ }
+ return 0;
++#undef HEADER_SIZE
+ }
+ 
+ /**/
diff --git a/debian/patches/series b/debian/patches/series
index ecf3e815..a3757c8a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ pulse-debian.patch
 var-run.diff
 document-certs.diff
 fix-environment.diff
+cve-2022-23613.diff
-- 
2.35.1

>From a0e029b28413f8900845e9e7135c252885b6d5ae Mon Sep 17 00:00:00 2001
From: Arnaud Rebillout 
Date: Fri, 1 Apr 2022 09:34:56 +0700
Subject: [PATCH 2/3] Update changelog for 0.9.17-2.1 release

---
 debian/changelog | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 5773a467..527cfa87 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+xrdp (0.9.17-2.1) unstable; urgency=medium
+
+  * Import upstream patch to fix CVE-2022-23613 (Closes: #1005304)
+
+ -- Arnaud Rebillout   Fri, 01 Apr 2022 09:34:47 +0700
+
 xrdp (0.9.17-2) unstable; urgency=medium
 
   * Initialise the environment properly (Closes: #996418, #984782)
-- 
2.35.1

>From 9f4ac4afcee73ce567e5734ba2cacfd1789fb23c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Fri, 1 Apr 2022 08:44:24 +0200
Subject: [PATCH 3/3] Add non-maintainer upload to changelog entry.

---
 debian/changelog | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/changelog b/debian/changelog
index 527cfa87..1a502830 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 xrdp (0.9.17-2.1) unstable; urgency=medium
 
+  * Non-maintainer upload.
   * Import upstream patch to fix CVE-2022-23613 (Closes: #1005304)
 
  -- Arnaud Rebillout   Fri, 01 Apr 2022 09:34:47 +0700
-- 
2.35.1



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

2022-01-26 Thread 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#1003478: python-django: cannot import name 'RequestSite' from partially initialized module 'django.contrib.sites.requests' (most likely due to a circular import)

2022-01-13 Thread Raphael Hertzog
On Thu, 13 Jan 2022, Chris Lamb wrote:
> This should be fixed in bullseye-backports in 2:3.2.10-2~bpo11+2 and
> in bullseye itself via 2:2.2.26-1~deb11u1 (see #1003659 for the unblock
> request).

Thank you Chris!

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



Bug#992536: libasound2-udeb: missing /usr/share/alsa/ctl

2022-01-11 Thread Raphael Hertzog
Hi alsa maintainers,

having this bug unfixed in unstable/testing for so long is a bit of a
pity.

Can you consider uploading a fixed version please?

If not, do you want an NMU?

Thank you in advance.

Le jeudi 19 août 2021, Samuel Thibault a écrit :
> Source: alsa-lib
> Version: 1.2.5.1-1
> Severity: important
> Tags: a11y d-i patch
> 
> Hello,
> 
> As of version 1.2.5.1-1, speech synthesis is broken in the debian
> installer, amixer itself complains that it does not have
> /usr/share/alsa/ctl, as the attached snapshot shows.
> 
> Installing it as the attached patch does indeed fixes the issue.
> 
> Samuel
-- 
Raphaël Hertzog



Bug#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

2022-01-01 Thread Raphael Hertzog
Hi,

On Fri, 31 Dec 2021, Paul Gevers wrote:
> > Otherwise I would like to suggest to create two entries, one with
> > "Pin: release a=foo" and one with "Pin: release n=foo" so that
> > we are sure to match on any of the 3 fields.
> 
> I'll have to check and think about this. I remember that I had lots of
> issues with coming up with changes to autopkgtest that also worked for
> Ubuntu, as they use the same Codename for the real Suite and the *-proposed
> Suite (which they call pocket). I don't recall if that was with respect to
> pinning or other aspects of autopkgtest and it's requirement to manipulate
> where packages should be installed from. Before committing your proposal I
> need to understand that I'm not breaking existing valid configurations too.

I saw a comment mentionning this, but it was related to the "--apt-pocket"
option and I didn't change that part, which still uses the "a=foo" syntax.

https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/lib/adt_testbed.py#L1263

And indeed in http://archive.ubuntu.com/ubuntu/dists/jammy-proposed/Release you 
have
 
 Suite: jammy-proposed
 Codename: jammy

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#1002819: autopkgtest: --pin-packages assumes that the release has a "Suite" name

2021-12-29 Thread Raphael Hertzog
Control: tags -1 + patch
Control: user de...@kali.org
Control: usertag -1 + kali-patch

On Wed, 29 Dec 2021, Raphaël Hertzog wrote:
> I noticed that /etc/apt/preferences.d/autopkgtest-default-release uses
> another syntax that seems to cover more cases:
> 
> Package: *
> Pin: release kali-rolling
> Pin-Priority: 990
> 
> However that syntax doesn't seem to be documented in apt_preferences.
> If it's correct and allows to check on either of the 3 fields, then
> we should likely use the same syntax in both files.

I got confirmation from David Kalnischkies that this syntax is supported
and means exactly this:

12:54  buxy: yeah, its supported and means "Archive/Suite: or
Codename is X". One example in the manpage actually includes it (release
unstable), but it is never explained it seems. It is also the backbone of
commandline flag -t X. Code is in apt-pkg/versionmatch.cc, but its not
much to see.

So I recommend to use this same syntax in files generated for
--pin-packages.

Suggested patch is attached.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
>From 9946e61ed4821aa9c03d42393ea6887dc9337ea7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Wed, 29 Dec 2021 13:23:27 +0100
Subject: [PATCH] Fix APT pinning for --pin-packages to also match on codenames
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

By using “Pin: release foo” instead of “Pin: release a=foo” we match
against all 3 relevant fields (Codename/Suite/Archive) whereas the
latter only matches against Suite and Archive.

Closes: #1002819
---
 lib/adt_testbed.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/adt_testbed.py b/lib/adt_testbed.py
index b37eef4..225eb1f 100644
--- a/lib/adt_testbed.py
+++ b/lib/adt_testbed.py
@@ -1235,10 +1235,10 @@ Description: satisfy autopkgtest test dependencies
 
 # prefer given packages from series, but make sure that other packages
 # are taken from default release as much as possible
-script += 'printf "Package: $PKGS\\nPin: release a=%(release)s\\nPin-Priority: 995\\n" > /etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
+script += 'printf "Package: $PKGS\\nPin: release %(release)s\\nPin-Priority: 995\\n" > /etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
 {'release': release}
 for default in default_releases:
-script += 'printf "\nPackage: *\\nPin: release a=%(default)s\\nPin-Priority: 990\\n" >> /etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
+script += 'printf "\nPackage: *\\nPin: release %(default)s\\nPin-Priority: 990\\n" >> /etc/apt/preferences.d/autopkgtest-%(release)s; ' % \
 {'release': release, 'default': default}
 self.check_exec(['sh', '-ec', script])
 self._set_default_release()
-- 
2.34.1



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

2021-12-27 Thread 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

2021-12-27 Thread 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

2021-12-27 Thread 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

2021-12-27 Thread 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

2021-12-07 Thread 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

2021-12-06 Thread 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#998319: tryton-server: Should provide a ready-to-use production-grade server config

2021-11-03 Thread Raphael Hertzog
Hi,

On Tue, 02 Nov 2021, Mathias Behrle wrote:
> A robust production grade setup will run the Tryton server not only behind a
> reverse proxy, but inside a wsgi server.
> 
> My prefered concept for the solution would be two additional packages:
> 
> tryton-server-uwsgi
> tryton-server-nginx
> 
> which would also need some changes to the tryton-server package itself to
> integrate well.

I don't have any strong preference. In distro-tracker, I provide vhosts
for apache and for nginx. I think it's useful to support both as you might
want to install on a server where something is already running.

However, the WSGI server is really open. For distro-tracker I opted to use
gunicorn with nginx and libapache2-mod-wsgi-py3 with apache.

> Documentation only has some problems:
> 
> - Often it is not read.
> - It is difficult to provide solutions matching different needs. At the end 
> you
>   get the question again: What to do with reverse proxy only, what to do with
>   wsgi backend, which backends to choose, etc.?
>   The mentioned packages would/should at least provide a basic working start
>   setup without too much manual steps.

Make some sane default choices and make it easy to follow your choices. If
users want something else, they can always override and change the setup.

Regards,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com


signature.asc
Description: PGP signature


Bug#994275: Reverting breaking changes in debianutils

2021-11-02 Thread Raphael Hertzog
On Mon, 01 Nov 2021, Sean Whitton wrote:
> Of course we should be exploring the new avenues that you mention.  But
> becoming more willing to break unstable/testing than we are at present
> might also be good for our project.

Maybe, maybe not. What are you basing your assertion on?

From my (limited) point of view, Debian testing/unstable is used by many
derivatives because it's largely usable and stable, and we do get many
contributions due to this.

I for one contribute many fixes to Debian because Kali is built on Debian
testing. At some point it was based on Debian stable and I was largely not
able to contribute to Debian, and if we did break testing/unstable more
often, the net result would likely that Kali would switch back to stable.

I don't really see any scenario where breaking unstable/testing helps us
in any way. Except if the breakage is really limited in time, and if the
breakage does not affect upgrade paths, etc. But then I would no longer
call that "breaking unstable/testing".

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#994275: Reverting breaking changes in debianutils

2021-10-29 Thread Raphael Hertzog
On Sun, 24 Oct 2021, Clint Adams wrote:
> > In any case, a message saying that which is deprecated when in fact
> > `which` will stay around (but maintained in another packages) is not
> > helpful.
> 
> Tell me, what would be helpful?

A coordinated take over of the binary with a proper transition as
recommended by the tech-ctte.

I have sympathy with your reasoning and I can certainly relate to things
that we did 20 years ago, where we happily broke unstable after a release
but we have changed.

Yes, on some aspects we have become more conservative. I certainly wish
to change that, but not by going backwards, but by providing new avenues
to experiment and make large-scale changes without breaking unstable/testing.

> On Mon, Oct 18, 2021 at 11:50:32AM -0700, Sean Whitton wrote:
> > As Raphael has mentioned, it's unlikely that when debianutils' which(1)
> > has been replaced with one in another essential or transitively
> > essential package that the new which(1), whether it's the same code or
> > something else, will print deprecation warnings.  And then it seems odd
> > to print them for a while and then stop printing them.
> 
> I find this to be a curious statement.  This implies a contract of
> future behavior that does not exist.

Right, but that's we are doing in Debian when we discuss together and make
plans for further changes and then try to stick to the plan. You seem to
consider Debian as a more "organic entity" that is not controllable and
that you have no chance to influence.

And as often, the reality is somewhere in the middle.

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



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

2021-10-28 Thread 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#997522: logidee-tools: FTBFS: make[2]: kpsepath: No such file or directory

2021-10-26 Thread Raphael Hertzog
Control: tag -1 + wontfix

On Sat, 23 Oct 2021, Lucas Nussbaum wrote:
> Source: logidee-tools
> Version: 1.2.19
> 
> During a rebuild of all packages in sid, your package failed to build
> on amd64.

Note that I requested removal of this package so I will not handle this
bug. See https://bugs.debian.org/996776

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



Bug#994040: "SystemError: initialization of _psycopg raised unreported exception" when running under WSGI

2021-10-21 Thread Raphael Hertzog
Hello,

Le dimanche 03 octobre 2021, Sébastien Helleu a écrit :
> In my case, setting "WSGIApplicationGroup" to "%{GLOBAL}" doesn't help much.
> 
> But I found another solution, by enabling Daemon mode, as recommended by the
> Django docs:
> https://docs.djangoproject.com/en/3.2/howto/deployment/wsgi/modwsgi/#using-mod-wsgi-daemon-mode
> 
> So I added these two lines in each site (with appropriate domain name) and it
> works fine:
> 
> WSGIDaemonProcess example.com
> WSGIProcessGroup example.com

When we upgraded tracker.debian.org to bullseye, we were already using
"daemon mode" as recommended by the documentation but we still had the
above issue and setting "WSGIApplicationGroup" to "%{GLOBAL}" did
indeed fix the issue for us.

Adrian Bunk thinks that it could be fixed by
https://github.com/GrahamDumpleton/mod_wsgi/commit/9509e178e0583435a800b006b410df74e405e2b9

It would be nice if someone could double check that... we don't want to
use tracker.debian.org for that kind of test.

Cheers,
-- 
Raphaël Hertzog



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

2021-10-18 Thread 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



Bug#995445: logidee-tools: creates incorrect TeX code, breaks other packages via autopkgtests

2021-10-18 Thread Raphael Hertzog
Hello,

On Fri, 01 Oct 2021, Norbert Preining wrote:
> The failed autopkgtest can be boiled down to the following example (all
> the code is as taken from the logidee-tools generated code):

Sorry that logidee-tools created issues for you. For the record, I have
just requested the removal of that package since I'm no longer using
it and in fact nobody else is using it either.

RM bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996776

Hopefully the package will be removed soon.

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



Bug#994275: Draft resolution for reverting changes in debianutils

2021-10-18 Thread Raphael Hertzog
Hi,

On Wed, 13 Oct 2021, David Bremner wrote:
> >The which(1) program must not print any deprecation warnings.
> 
> I remain to be convinced on this point. If I understand the issue
> correctly the problem is with autopkgtests failing because they were not
> expecting output on stderr. I don't think people are really entitled to
> expect which(1) to never print to stderr. Even when debian-policy
> recommended 'which' it apparently recommended redirecting stderr.
> 
> I also don't see failures of autopkgtests as directly impacting users in
> the same way a failure to build or a failure to install does.

There have been other reports of failures due to the message on stderr,
autopkgtest is not the only one (wookey mentionned a build failure).

In any case, a message saying that which is deprecated when in fact
`which` will stay around (but maintained in another packages) is not
helpful.

> I understand that people find the message annoying, and perhaps not that
> useful, but I don't think that rises the level justifying overriding a
> maintainer.

I think it does.

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



Bug#993204: Bug#996079: gnome-shell-timer: does not declare compatibility with GNOME Shell 41

2021-10-17 Thread Raphael Hertzog
Control: forcemerge 993204 996079

Le dimanche 10 octobre 2021, Simon McVittie a écrit :
> Package: gnome-shell-timer
> 
> The metadata.json for this extension doesn't declare compatibility with
> GNOME 41. I don't know whether the actual code will need changes or not:
> the conservative assumption is that it probably will (so please test).
> gnome-shell 41 should be available in experimental soon.

FWIW, you had already filed #993204 for the same issue (but for GNOME 40).
In any case, I have just filed a RM request to get this package removed
from Debian.

(I'm saying that so that nobody invest time into those RC bugs)

Cheers,
-- 
Raphaël Hertzog



Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang

2021-09-23 Thread Raphael Hertzog
Control: severity -1 serious
Control: tags -1 + patch

Hello,

I have been bitten by this bug for multiple months without having a clue
of what was going on... when I resumed my laptop without wifi, the GNOME
session would be blocked for a minute or so.

With the patch in https://salsa.debian.org/debian/gnupg2/-/merge_requests/9
I no longer have this issue.

But I'm not sure if the patch is fully correct, the manual page is not
clear whether --check-options foo is a subset of --check-programs. However
the output format of both command is exactly the same.

BTW I believe this issue needs to be fixed in bullseye too.

Cheers,
-- 
Raphaël Hertzog



Bug#994808: upgrade issue

2021-09-23 Thread Raphael Hertzog
Hi,

On Wed, 22 Sep 2021, Andreas B. Mundt wrote:
> If I don't hear back from you, I'll upload the package with the fix 
> later today in the early evening.

Thanks for the quick upload!

> Concerning the autopkgtests: Can you point me to a package that
> implements a test to detect these kind of errors early?

I don't have any specific example in mind but I was expecting that
any test suite that would rely on the daemon running with the parameters
defined in /etc/default/atftpd would detect the issue... either
because the daemon fails to run or because it runs with options that
don't match what was supplied through debconf.

> [1] This covers also the case I had here:  After the faulty line, I had
> a correct line, which made the test: 
> 
>  $ if ! . /etc/default/atftpd_save ; then echo "Remove broken 
> /etc/default/atftpd"; fi
>  bash: 69: command not found
>  $ 
> 
> slightly confusing …

Note that the test had "2>/dev/null" to avoid this confusing output. But
it's irrelevant now.

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



Bug#994808: upgrade issue

2021-09-22 Thread Raphael Hertzog
Hello,

Le mardi 21 septembre 2021, Andreas B. Mundt a écrit :
> I have to investigate further, but does it really work for you?

Thanks for testing. Unfortunately, our testing was not sufficient indeed.
We tested in a chroot (thus without systemd) and the code path is
really different there: the "prerm upgrade" fails while trying to stop
the service with "invoke-rc.d atftpd stop" and thus the "prerm failed-upgrade"
triggers correctly.

However with systemd, there's no failure in the prerm, and the snippet we
added is thus useless: we have to also do the same check in "preinst
upgrade" instead.

We will come up with an additional MR later today.

Cheers,
-- 
Raphaël Hertzog



Bug#992243: buster-pu: package psmisc/23.2-1+deb10u1

2021-09-04 Thread Raphael Hertzog
Hello,

On Sat, 04 Sep 2021, Adam D. Barratt wrote:
> On Mon, 2021-08-16 at 12:02 +0200, Raphael Hertzog wrote:
> > I would like to update "psmisc" in buster to fix a regression in
> > "killall". The bug https://bugs.debian.org/912748 was never fixed in
> > that release and "killall command-longer-than-15-char" is thus not
> > working at all in buster
> 
> Please go ahead.

Thanks, uploaded.

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com



Bug#993204: gnome-shell-timer: does not declare compatibility with GNOME Shell 40

2021-08-28 Thread Raphael Hertzog
Control: severity -1 serious

Hi,

On Sat, 28 Aug 2021, Simon McVittie wrote:
> When we do the GNOME 40 transition, hopefully soon, we will have to
> either update this extension or remove it from testing. It would be
> useful to get a fixed version into experimental.

This extension is effectively unmaintained upstream. I will likely
request its removal from Debian unless someone is willing to take it
over in Debian and as upstream. Let's get it removed from testing right
now as way to alert potential users.

FWIW I have switched to https://github.com/blackjackshellac/kitchenTimer
but I'm not sure that I have the time and willingness to package it.

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



Bug#993141: simple-cdd: default.downloads is missing packages used by debian-installer

2021-08-27 Thread Raphael Hertzog
Package: simple-cdd
Version: 0.6.8
Severity: important
User: de...@kali.org
Usertags: origin-kali
X-Debbugs-Cc: raph...@offensive-security.com, debian...@lists.debian.org

While diagnosing a failure to boot an encryted install, I discovered that
simple-cdd was not properly adding cryptsetup-initramfs and I fixed that
directly:
https://salsa.debian.org/debian/simple-cdd/-/commit/eb0d1d8960e22dd1c087b15a505b1503d76088a3

FWIW, I fixed a similar issue in debian-cd:
https://salsa.debian.org/images-team/debian-cd/-/commit/8d2bd4aa2e29fedbf9e224e6ce56bb6feae2b36a

However when I analyzed debian-cd's sort_deps.amd64.log I noticed that the
mirror generated by simple-cdd is lacking other packages that debian-cd
tries to include for the benefits of debian-installer with multiple lines
like those:
WARNING: 'cryptsetup-initramfs' does not appear to be available ... (ignored)

Among the missing packages I believe you might want to add those:
- pcmciautils
- discover
- dosfstools
- btrfs-progs
- open-iscsi
- multipath-tools-boot
- wireless-tools
- ppp
- pppoeconf
- pptp-linux
- wpasupplicant
- rdnssd
- installation-report
- alsa-utils
- brltty
- espeakup
- grub-efi-amd64-signed
- shim-signed

The following are also reported as missing but they no longer exist in
unstable so they are not really relevant:

- btrfs-tools
- ufsutils
- zfsutils
- loop-aes-utils
- apt-transport-https
- linux-image-2.6-amd64

Those might be candidates to be dropped from debian-cd's listings?
(cc to debian...@lists.debian.org)

-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.35
ii  lsb-release 11.1.0
ii  python3 3.9.2-3
ii  python3-simple-cdd  0.6.8
ii  reprepro5.3.0-1.2
ii  rsync   3.2.3-4
ii  wget1.21-1+b1

Versions of packages simple-cdd recommends:
ii  dose-distcheck  6.0.1-2

Versions of packages simple-cdd suggests:
ii  qemu-system-x86 [qemu-kvm]  1:5.2+dfsg-11

-- no debconf information

-- 
Raphaël Hertzog



Bug#992966: simple-cdd: fails to validate Release file with a good signature and a signature that can't be checked

2021-08-25 Thread Raphael Hertzog
Control: severity -1 important

Bumping the severity on suggestion of #debian-release.

On Wed, 25 Aug 2021, Raphaël Hertzog wrote:
> Right now if you try to use simple-cdd on a stretch or buster system (to
> build stretch/buster images), you get failures like this one:

I was a bit to quick in my assertion. The problem is limited to stretch
because buster's debian-archive-keyring has been updated a while ago (but
my buster chroot was not up-to-date):
https://tracker.debian.org/news/1236764/accepted-debian-archive-keyring-20191deb10u1-source-all-into-proposed-updates-stable-new-proposed-updates/

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com



Bug#992243: buster-pu: package psmisc/23.2-1+deb10u1

2021-08-16 Thread Raphael Hertzog
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: raph...@freexian.com csm...@debian.org

Hello,

I would like to update "psmisc" in buster to fix a regression in
"killall". The bug https://bugs.debian.org/912748 was never fixed in that
release and "killall command-longer-than-15-char" is thus not working at
all in buster

It seems to me to fall in the "important regression" that ought to be
fixed by a point release and I'm surprised that nobody hit this earlier.

This was reported to me by a Freexian customer that did not understand why
his script was no longer working with Debian 10.

The upstream patch that I backported is in use in bullseye and newer
(though there might be further upstream changes on top since we are at
23.4 now). I have tested the resulting package and it now successfully
kills processes with long command names.

Craig, I have pushed this upload in a "buster" branch on salsa. Your
review is welcome.

https://salsa.debian.org/debian/psmisc/-/tree/buster
https://salsa.debian.org/debian/psmisc/-/commit/e34a294a95895f5ef7e9f8d532dd5e0ba2a0f372

Cheers,
-- 
Raphaël Hertzog
>From e34a294a95895f5ef7e9f8d532dd5e0ba2a0f372 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Mon, 16 Aug 2021 11:07:34 +0200
Subject: [PATCH] Backport upstream patch to also match on 16 char
 TASK_COMM_LEN

At some point before the buster release, killall changed its COMM_LEN to
64 to cope with an (expected?) similar change in the kernel. But this
change is not present in buster's kernel and in fact, in none of the
other newer kernels AFAIK (likely due to the kernel "no-user-space
breakage" rule). And due to this mismatch, killall is not able to
identify process with names bigger than 15 characters.

Newer versions of killall thus learned to handle both possible lenghts
and this commit just backports the corresponding patch to fix this
regression in Debian 10.
---
 debian/changelog|   9 ++
 debian/patches/match-on-16-char-commlen | 122 
 debian/patches/series   |   1 +
 3 files changed, 132 insertions(+)
 create mode 100644 debian/patches/match-on-16-char-commlen

diff --git a/debian/changelog b/debian/changelog
index 734542f..02b57c0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+psmisc (23.2-1+deb10u1) buster; urgency=medium
+
+  * Team upload.
+  * Fix regression in killall not matching process with names bigger than 15
+characters by backporting the upstream patch that restores the check
+that works on kernels that have TASK_COMM_LEN set to 16. Closes: #912748
+
+ -- Raphaël Hertzog   Mon, 16 Aug 2021 11:17:53 +0200
+
 psmisc (23.2-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/patches/match-on-16-char-commlen b/debian/patches/match-on-16-char-commlen
new file mode 100644
index 000..5037bd0
--- /dev/null
+++ b/debian/patches/match-on-16-char-commlen
@@ -0,0 +1,122 @@
+From 1188315cd037d73bf946a0003b70c6423cc330d2 Mon Sep 17 00:00:00 2001
+From: Craig Small 
+Date: Wed, 7 Nov 2018 20:13:09 +1100
+Subject: [PATCH] killall: match on 16 character commlen too
+
+The comm length increase meant killall could accommodate the
+larger comm name given out by newer kernels but it meant that
+if a user relied on the previous 16 character truncation then
+processes that used to match would fail.
+
+killall now checks to see if the comm is the old COMM_LEN
+length and the given name is longer than old COMM_LEN and does
+a truncated match as well.
+
+Bug-Debian: https://bugs.debian.org/912748
+Origin: upstream, https://gitlab.com/psmisc/psmisc/-/commit/1188315cd037d73bf946a0003b70c6423cc330d2 https://gitlab.com/psmisc/psmisc/-/commit/e2cf9f3e83e0fc0278ff39a4dfc8e3f2730eebca
+---
+diff --git a/src/killall.c b/src/killall.c
+index 2715515..09212a4 100644
+--- a/src/killall.c
 b/src/killall.c
+@@ -492,6 +492,49 @@ create_pid_table(int *max_pids, int *pids)
+ return pid_table;
+ }
+ 
++#define strcmp2(A,B,I) (I? strcasecmp((A),(B)):strcmp((A),(B)))
++#define strncmp2(A,B,L,I) (I? strncasecmp((A),(B),(L)):strncmp((A),(B),(L)))
++static int match_process_name(
++const char *proc_comm,
++const int comm_len,
++const char *proc_cmdline,
++const char *match_name,
++const int match_len,
++const int got_long
++ )
++{
++/* process is old length but matching longer */
++if (comm_len == OLD_COMM_LEN - 1 && match_len >= OLD_COMM_LEN - 1)
++{
++if (got_long)
++{
++return (0 == strncmp2 (match_name, proc_cmdline, OLD_COMM_LEN - 1,
++   ignore_case));
++} else {
++return (0 == strncmp2 (match_name, proc_comm, OLD_COMM_LEN - 1,
++   ignore_case));
++}
++}
++
++if (comm_len == COMM_LEN - 1 && match_len >= COMM_LEN - 1)
++{

Bug#991166: ftpsync: Contents* and dep11/* metadata are incorrectly updated in stage1

2021-07-16 Thread Raphael Hertzog
Control: tags -1 + patch

I have prepared a MR for this:
https://salsa.debian.org/mirror-team/archvsync/-/merge_requests/2

Changes are trivial but they are currently untested.

Cheers,
-- 
Raphaël Hertzog ◈ Offensive Security ◈ Kali Linux Developer



Bug#990426: www.debian.org: Clarify status of list of old TC decisions

2021-07-08 Thread Raphael Hertzog
Hi,

On Mon, 28 Jun 2021, Sean Whitton wrote:
> -NB that decisions from before the 1st of April 2002 are not yet
> -recorded here.
> +NB that no decisions from before the 1st of April 2002 are yet recorded
> +here yet.

That wording doesn't seem correct for me. Maybe:
« Note that no decisions from before the 1st of April 2002 are recorded
here. »
or 
« Note that decisions from before the 1st of April 2002 have not been
recorded here. »

>  Formal nontechnical and procedural decisions
>  
> @@ -337,8 +337,8 @@ recorded here.
>  
>  
>  
> -NB that decisions from before the 31st of January 2002 are not yet
> -recorded here.
> +NB that no decisions from before the 31st of January 2002 are recorded 
> here
> +yet.

Same here.

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#888831: NS_ERROR_NET_INADEQUATE_SECURITY error on armhf/arm64 at least

2021-07-07 Thread Raphael Hertzog
Control: severity -1 serious
Control: found -1 firefox-esr/78.11.0esr-1
Control: tag -1 + bullseye

Hello,

it looks like this issue resurfaced again and it happens in bullseye
right now (with firefox-esr 78.11.0esr-1 and libnss3 2:3.61-1).
If you upgrade to the version of libnss3 in unstable (2:3.67-2)
then the issue goes away.

This has been reproduced in Kali on an rpi (armhf) and on the Lenovo Yoga
C630 (arm64).

The simplest fix is thus to let nss migrate into bullseye.

Cheers,
-- 
Raphaël Hertzog



Bug#988658: RFP: python3-pyupgrade -- Automatically upgrade syntax for newer versions of the Python language

2021-05-17 Thread Raphael Hertzog
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: python3-pyupgrade
  Version : 2.16.0
  Upstream Author : Anthony Sottile 
* URL : https://github.com/asottile/pyupgrade
* License : BSD
  Programming Lang: Python
  Description : Automatically upgrade syntax for newer versions of the 
Python language

This helper script can help you normalize your Python source code
by rewriting parts of your code to use the latest syntax improvements.

Some examples from the README:

set([])  # set()

'{0} {1}'.format(1, 2)# '{} {}'.format(1, 2)

x is 5  # x == 5

'{foo} {bar}'.format(foo=foo, bar=bar)  # f'{foo} {bar}'


I discovered this tool by reading some documentation and I'd like
it to be available in Debian so that I can try it and use it :-)

ccing debian-pyt...@lists.debian.org in the hope to catch the attention of
someone with more time than me.

Thank you!

-- 
Raphaël Hertzog



Bug#962290: smuxi-frontend-gnome: freezes when I click on the channel with a recent notification

2021-04-27 Thread Raphael Hertzog
Control: tags -1 - moreinfo unreproducible

Hello,

Le mercredi 10 février 2021, Raphael Hertzog a écrit :
> > Can you please open a terminal and run Smuxi in debug mode like this:
> > smuxi-frontend-gnome -d
> 
> I'll try to get you this soon.

Finally I reproduced the issue!

Here's the end of the log:

2021-04-27 23:28:15,511 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
GroupChatView.AddPerson(person = )
2021-04-27 23:28:57,065 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:29:57,095 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:30:57,153 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:31:24,501 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
GroupChatView.AddPerson(person = )
2021-04-27 23:31:24,502 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
MainWindow.UpdateTitle(chatView = <#kali-linux>, protocolStatus = (null))
2021-04-27 23:31:57,212 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:32:57,243 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:33:57,300 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:34:57,357 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:35:57,388 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:36:57,419 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:37:57,476 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:38:25,246 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:38:25,248 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:38:57,534 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:39:27,423 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:39:27,426 [LastSeenHighlightQueue()] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] ChatView.OnMessageTextViewMessageHighlighted(sender 
= (null), e = (null))
2021-04-27 23:39:27,458 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:39:57,566 [FrontendManagerCheckerQueue] DEBUG TRACE - 
[smuxi-frontend-gnome.exe] Frontend.CheckFrontendManagerStatus()
2021-04-27 23:40:14,953 [Main] DEBUG Smuxi.Frontend.Gnome.MessageTextView - 
OnMotionNotifyEvent(): at url tag
2021-04-27 23:40:14,961 [Main] DEBUG Smuxi.Frontend.Gnome.MessageTextView - 
OnMotionNotifyEvent(): not at url tag
2021-04-27 23:40:16,355 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
MainWindow.OnFocusInEvent(sender = Smuxi.Frontend.Gnome.MainWindow, e = 
Gtk.FocusInEventArgs)
2021-04-27 23:40:16,355 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#kali-linux>)
2021-04-27 23:40:16,357 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
StatusIconManager.OnMainWindowFocusInEvent(sender = 
Smuxi.Frontend.Gnome.MainWindow, e = Gtk.FocusInEventArgs)
2021-04-27 23:40:16,357 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
NotifyManager.OnMainWindowFocusInEvent(sender = 
Smuxi.Frontend.Gnome.MainWindow, e = Gtk.FocusInEventArgs)
2021-04-27 23:40:16,384 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatViewManager.OnTreeViewSelectionChanged(sender = Gtk.TreeSelection, e = 
System.EventArgs)
2021-04-27 23:40:16,384 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
MessageTextView.UpdateMarkerline()
2021-04-27 23:40:16,384 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
Notebook.OnSwitchPage(sender = Smuxi.Frontend.Gnome.Notebook, e = 
Gtk.SwitchPageArgs)
2021-04-27 23:40:16,384 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:40:16,386 [Main] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
ChatTreeView.Render(chatView = <#debian-qa>)
2021-04-27 23:40:16,387 [SwitchPage] DEBUG TRACE - [smuxi-frontend-gnome.exe] 
Notebook.OnSwitchPage(sender = (null), e = (null))
2021-04-27 23:40:16,387 [Main] DEBUG TRACE - [smuxi-engine.dll] Config.Save()
2021-04-27 23:40:16,387 [Main] DEBUG Smuxi.Engine.Config - Saving config
2021-04-27 23:40:16,388 [Main] DEBUG TRACE - [smuxi-engine.dll] Config.Save()
2021-04-27 23:40:16,388 [Main] DEBUG Smuxi.Engine.Config - Saving config
2021-04-27 23:40:16,389 [Mai

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

2021-04-20 Thread 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



Bug#962290: smuxi-frontend-gnome: freezes when I click on the channel with a recent notification

2021-04-16 Thread Raphael Hertzog
On Fri, 26 Feb 2021 10:10:19 +0100 Raphael Hertzog  wrote:
> On Thu, 11 Feb 2021, Mirco Bauer wrote:
> > Can you please open a terminal and run Smuxi in debug mode like this:
> > smuxi-frontend-gnome -d
> 
> I did that for multiple days but it looks like the issue is gone or its
> frequency decreased really dramatically. Feel free to close the bug.

I had the issue again today but I was not running in debug mode. I have
started to run again in debug mode but it seems really hard to
reproduce...

Cheers,
-- 
Raphaël Hertzog



Bug#943989: command-not-found: "Sorry, command-not-found has crashed!"

2021-04-03 Thread Raphael Hertzog
So the latest version doesn't have the same error message (with "cnf"
variable being unbound) but it still doesn't fail gracefully when
the database is not available.

Instead of asking to file bug reports, it should tell them to run "apt
update". This bad behaviour is now generating quite some noise in the
Debian bug tracker because we have enabled command-not-found in Kali
and when they get it installed during upgrade (as opposed to during a
fresh installation), the database is not created during the same apt
run and they get this error message when they run a missing command:

> $ lsio
> 
> Sorry, command-not-found has crashed! Please file a bug report at:
> http://www.debian.org/Bugs/Reporting
> Please include the following information with the report:
> 
> command-not-found version: 0.3
> Python version: 3.9.2 final 0
> Distributor ID: Kali
> Description:Kali GNU/Linux Rolling
> Release:2021.1
> Codename:   kali-rolling
> Exception information:
> 
> unable to open database file
> Traceback (most recent call last):
>   File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, in 
> crash_guard
> callback()
>   File "/usr/lib/command-not-found", line 90, in main
> cnf = CommandNotFound.CommandNotFound(options.data_dir)
>   File "/usr/share/command-not-found/CommandNotFound/CommandNotFound.py", 
> line 79, in __init__
> self.db = SqliteDatabase(dbpath)
>   File "/usr/share/command-not-found/CommandNotFound/db/db.py", line 12, in 
> __init__
> self.con = sqlite3.connect(filename)
> sqlite3.OperationalError: unable to open database file

This is clearly counter-productive. 

I would either suggest to ignore the failure entirely and behave as if
command-not-found was not installed, or to print a better error message
driving users towards "apt update".

And maybe if it's run as root, then directly propose to run "apt update".

Cheers,
- 
Raphaël Hertzog



Bug#986213: RM: ansible/2.9.16+dfsg-1.1

2021-04-01 Thread Raphael Hertzog
Hello,

On Wed, 31 Mar 2021, Lee Garrett wrote:
> Unfortunately 2.10 didn't make it into bullseye in time (#984557). I tried
> getting the unit tests from 2.9.16 to work with python 3.9, but I had to give
> up. I don't feel comfortable with maintaining such a large package over the
> lifecycle of bullseye without unit tests, official py3.9 support, and security
> support running out in a few months, so please remove ansible from bullseye.

I know everybody is trying to do their best, in one side with ansible
maintainance and on the other side with release management but this
outcome is really not desirable.

Shipping bullseye without a core system administration tool like ansible
is not something that we should do. Our users are the clear losers of this
situation (and thus Debian as a whole).

Graham, can you please reconsider your position in #984557? Maybe have
some broader discussion within the release team on whether an exception
is to be made?

I know exceptions are the doors to more arbitrary unblock requests but
in general I have the feeling that we are too strict with such requests.

It is important for maintainers of software that don't have intractable
reverse dependencies to be able to push the last upstream release that can
be reallistically supported for 5 years even when the release schedule is
not 100% aligned with Debian (IMO sometimes we should even encourage the
packaging of release candidates with the right to push the final releases
through a stable update soon after).

And when the upstream release schedule is not at fault, but something else
is at fault, instead of punishing the maintainer that failed to act on
time, maybe have some "recovery" mechanism where X DD can support the
fact that having the (updated) package is important. By doing so they
would sign up to help if anyhing goes wrong with this update during the
release process.

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



  1   2   3   4   5   6   7   8   9   10   >