Bug#1070077: [Pkg-privacy-maintainers] Bug#1070077: ships files directly in /usr/onionprobe

[Antoine Beaupré]

On 2024-04-30 08:25:55, Georg Faerber wrote:
> On 24-04-29 16:19:21, Antoine Beaupre wrote:
>> Package: onionprobe
>> Version: 1.0.0+ds-2.1+deb12u1
>> Severity: serious
>> 
>> The Debian package shipped in bookworm right now changed the path to
>> the examples/ directory. It used to be:
>> 
>> /usr/lib/python3/dist-packages/onionprobe/examples/tpo.py
>> 
>>  and now seems to be:
>> 
>> /usr/onionprobe/examples/tpo.py
>> 
>> Apart from the gratuitous change, this seems to be a violation of the
>> FHS policy, packages shouldn't ship their own stuff directly under
>> /usr like this...
>
> Indeed -- I wasn't aware, or probably forgot, that bookworm is affected.
> Given the severity, this might warrant a bookworm-pu, I guess?

Honestly, I'm not sure. It's relatively minor because it's just the
examples files, and the rest of the package is functional. I've patched
our puppet manifests to workaround the issue over here...

>> I haven't checked in unstable to see if this is fixed.
>
> This was reported via #1025508 and fixed in unstable via 1.1.2+ds-1.

Oh, I didn't realize that, good job! :)

-- 
It is capitalism and government which stand for disorder and
violence. Anarchism is the very reverse of it; it means order without
government and peace without violence.
- Alexander Berkman

Bug#1067290: marked as pending in pymeeus

[Antoine Beaupré]

Control: tag -1 pending

Hello,

Bug #1067290 in pymeeus reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/python-team/packages/pymeeus/-/commit/17a5c3310920d3f86bcdca25a033160598693ded


Fix pytest 7.2+ support and FTBFS in test suite (Closes: #1067290)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1067290

Bug#1042262: cumin: FTBFS: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

[Antoine Beaupré]

On 2023-07-27 13:04:22, Riccardo Coccioli wrote:
> I've checked the issue and opened a bug upstream to pyparsing [1] as this
> is indeed a regression.
> Running CI on cumin I've also found that pylint is reporting new issues
> related to pyparsing code, for which I've opened a separate bug upstream
> [2].
>
> [1] https://github.com/pyparsing/pyparsing/issues/502
> [2] https://github.com/pyparsing/pyparsing/issues/501

Hi!

Thanks for this! It looks like those are fixed upstream, do we need to
update pyparsing to 3.1.2 to fix this bug or what's the next step?

(upstream 502 is fixed in 3.1.1, in unstable, but 501 is only in
3.1.2...)

a.

-- 
Sous le projecteur, on ne voit pas les autres.
- Félix Leclerc

Bug#1062325: [Pkg-puppet-devel] Bug#1062325: leatherman: NMU diff for 64-bit time_t transition

[Antoine Beaupré]

On 2024-02-01 03:27:23, Steve Langasek wrote:

[...]

> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

Hey Steve!

I don't have any concerns with the patch at the moment and, in fact,
it's a bit over my head.

But I just wanted to say a big loud THANK YOU FOR YOUR WORK! This is
thankless, hard, complicated, multi-party work that Debian really,
really needs people to do, and I'm glad someone is doing it.

So, again, thank you.

a.

-- 
Il est sage de nous réconcilier avec notre adolescence ; haїr, mépriser,
nier ou simplement oublier l’adolescent que nous fûmes est en soi une
attitude adolescente.
- Daniel Pennac, Comme un roman

Bug#1059222: src:pv: fails to migrate to testing for too long: FTBFS on armhf

[Antoine Beaupré]

Hi Andrew!

This is a quick word to let you know that I've disabled valgrind tests
on armhf in the Debian package. They were failing since the 1.8.5 upload
(but possibly not in 1.8.0!), you can see a log here:

https://buildd.debian.org/status/fetch.php?pkg=pv=armhf=1.8.5-1=1700453788=0

Unfortunately, the failed build doesn't show the valgrind output, so
it's unclear exactly what's going on...

I might be able to get an armhf box to test this if you can't, let me
know how we should move ahead on this. For now, it seems better to
unblock the package so it trickles down to testing, considering how
slightly more flacky those tests are...

let me know!

a.

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

On 2023-12-12 15:39:24, Patrick Matthäi wrote:

[...]

>> It doesn't *quite* fix it just yet. For platforms where the ucode is
>> *not* provided (e.g. in my case it's the pcengines APU that don't have
>> firmware upgrades), this *still* yields a UNKNOWN warning. After a brief
>> discussion in the issue tracker, I decided to submit *another* PR as
>> such:
>>
>> https://github.com/liske/needrestart/pull/290
>>
>> ... and I think we should ship this in Debian as well.
>>
>> I also think we should make a stable update for this. This affects a
>> bunch of machines on our end and we need this fixed in bookworm.
>>
>> So I'll file a bug with the release team and prepare a stable
>> update.
>>
>> Patrick: objections?
>>
>> A.
>
> I will upload this patch now with 3.6-7. I am fine with a stable update 
> and would welcome it if you could do it in this case (I am a bit busy 
> these weeks)

I believe the update proposed in #1056358 fixes this. It's unclear to me
why it missed the 12.3 window - maybe I should have just uploaded it
already - but alas, this is where we're at now. :(

a.
-- 
O gentilshommes, la vie est courte.
Si nous vivons, nous vivons 
pour marcher sur la tête des rois.
- William Shakespeare

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

Control: reopen -1
Control: subscribe -1

On 2023-11-15 15:46:24, Antoine Beaupré wrote:
> Control: tags -1 +patch
>
> On 2023-11-15 14:54:26, Antoine Beaupré wrote:
>> On 2022-06-20 13:54:38, Nick Lewycky wrote:
>>> Package: needrestart
>>> Version: 3.6-1
>>> Severity: normal
>>>
>>> `sudo needrestart -w` always prints "Failed to check for processor
>>> microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.
>>
>> [...]
>>
>> There's now a PR for this upstream:
>>
>> https://github.com/liske/needrestart/pull/285
>>
>> People suffering from this issue are encouraged to test this and report
>> back upstream (or here, if you can't upstream).
>
> I tested it and it doesn't work. It only *seemed* to work because the
> author tested with -v, which *does* work around the issue.
>
> I found the issue, and sent this PR upstream to fix it:
>
> https://github.com/liske/needrestart/pull/288
>
> Patch attached, people are again encouraged to test and report back.
>
> I also attach upstream commit v3.6-9-ge85bfe3 which also seem necessary
> to fix firmware checks on my end...

It doesn't *quite* fix it just yet. For platforms where the ucode is
*not* provided (e.g. in my case it's the pcengines APU that don't have
firmware upgrades), this *still* yields a UNKNOWN warning. After a brief
discussion in the issue tracker, I decided to submit *another* PR as
such:

https://github.com/liske/needrestart/pull/290

... and I think we should ship this in Debian as well.

I also think we should make a stable update for this. This affects a
bunch of machines on our end and we need this fixed in bookworm.

So I'll file a bug with the release team and prepare a stable
update.

Patrick: objections?

A.

-- 
All governments are run by liars and nothing they say should be
believed.
   - I. F. Stone

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

Control: tags -1 +patch

On 2023-11-15 14:54:26, Antoine Beaupré wrote:
> On 2022-06-20 13:54:38, Nick Lewycky wrote:
>> Package: needrestart
>> Version: 3.6-1
>> Severity: normal
>>
>> `sudo needrestart -w` always prints "Failed to check for processor
>> microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.
>
> [...]
>
> There's now a PR for this upstream:
>
> https://github.com/liske/needrestart/pull/285
>
> People suffering from this issue are encouraged to test this and report
> back upstream (or here, if you can't upstream).

I tested it and it doesn't work. It only *seemed* to work because the
author tested with -v, which *does* work around the issue.

I found the issue, and sent this PR upstream to fix it:

https://github.com/liske/needrestart/pull/288

Patch attached, people are again encouraged to test and report back.

I also attach upstream commit v3.6-9-ge85bfe3 which also seem necessary
to fix firmware checks on my end...

a.

-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker
>From b073fb6d9969597173daa8c511a85bae9b03ed37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Wed, 15 Nov 2023 15:20:37 -0500
Subject: [PATCH] fix AMD ucode checking in non-debug mode

It looks like the assignment when the ucode exist was not
done *unless* `debug` (`-v`) was set. Therefore, all AMD microcode
checks were returning UNKNOWN, including in Nagios checks, unless the
`-v` ("verbose", but actually `debug`) was passed.

Closes: #249
---
 perl/lib/NeedRestart/uCode/AMD.pm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/perl/lib/NeedRestart/uCode/AMD.pm b/perl/lib/NeedRestart/uCode/AMD.pm
index 638e68d..6daad8f 100644
--- a/perl/lib/NeedRestart/uCode/AMD.pm
+++ b/perl/lib/NeedRestart/uCode/AMD.pm
@@ -185,8 +185,8 @@ sub nr_ucode_check_real {
 if ( exists( $_ucodes->{cpuid}->{$cpuid} ) ) {
 my $prid = $_ucodes->{cpuid}->{$cpuid};
 if ( exists( $_ucodes->{prid}->{$prid} ) ) {
-$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} ),
-		print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
+$vars{AVAIL} = sprintf( "0x%08x", $_ucodes->{prid}->{$prid} );
+print STDERR "$LOGPREF #$info->{processor} found ucode $vars{AVAIL}\n" if ($debug);
 	}
 }
 
-- 
2.39.2

>From e85bfe33b595b88cc8052a7815d13612ecc2a841 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Stefan=20B=C3=BChler?= 
Date: Sun, 28 May 2023 17:42:28 +0200
Subject: [PATCH] [uCode] fix uninitialized value in logging of processor index

This got broken in f8c2609f8d5a0e10bd988497b8ea9815a7bb2fa8.

Before that it would have effectively logged
`$processors{$pid}->{processor}`, but the `processor` entry
is also the key in `%processors`, i.e. equals `$pid`.
---
 perl/lib/NeedRestart/uCode.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/perl/lib/NeedRestart/uCode.pm b/perl/lib/NeedRestart/uCode.pm
index 6251339..db81375 100644
--- a/perl/lib/NeedRestart/uCode.pm
+++ b/perl/lib/NeedRestart/uCode.pm
@@ -148,7 +148,7 @@ sub nr_ucode_check {
 }
 $ui->progress_step;
 
-my $nstate = compare_ucode_versions( $debug, $processors{processor}, @nvars );
+my $nstate = compare_ucode_versions( $debug, $pid, @nvars );
 if ( $nstate > $state ) {
 ( $state, @vars ) = ( $nstate, @nvars );
 }
-- 
2.39.2

Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Antoine Beaupré]

On 2022-06-20 13:54:38, Nick Lewycky wrote:
> Package: needrestart
> Version: 3.6-1
> Severity: normal
>
> `sudo needrestart -w` always prints "Failed to check for processor
> microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.

[...]

There's now a PR for this upstream:

https://github.com/liske/needrestart/pull/285

People suffering from this issue are encouraged to test this and report
back upstream (or here, if you can't upstream).

I've also bumped the severity of this bug. For us it leads to alert
fatigue and creates security and reliability issues.

a.
-- 
Je viens d'un pays où engagé veut dire que tu t'es trouvé une job.
- Patrice Desbiens

Bug#1042356: rapid-photo-downloader: FTBFS: make: *** [debian/rules:8: clean] Error 25

[Antoine Beaupré]

Control: tags -1 +patch

There's a patch posted in this thread for this bug:

https://discuss.pixls.us/t/patch-for-newer-python-setuptools/36593

Actual link to the patch on Arch:

https://build.opensuse.org/request/show/1078462
-- 
The odds are greatly against you being immensely smarter than everyone
else in the field. If your analysis says your terminal velocity is
twice the speed of light, you may have invented warp drive, but the
chances are a lot better that you've screwed up.
- Akin's Laws of Spacecraft Design

Bug#1028212: proposed stable release update

[Antoine Beaupré]

I have filed #1055115 to update the package in bookworm.

a.
-- 
Nothing in life is to be feared, it is only to be understood.
Now is the time to understand more, so that we may fear less.
 - Marie Curie

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

Control: tags -1 +pending

On 2023-10-13 09:17:49, Kyle Fazzari wrote:
> I don't entirely agree, but disagreement is okay. I do at least 
> recommend accompanying this with a cache age statistic, as we discussed 
> earlier.

Both of those have been done upstream, and I've uploaded a new snapshot
taking those into account.

I'm also planning on doing a stable update once this reaches
testing. Testers and feedback welcome!

-- 
Je viens d'un pays où engagé veut dire que tu t'es trouvé une job.
- Patrice Desbiens

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 11:40:17, Antoine Beaupré wrote:

[...]

> What's the magic setting to make apt check those updates on its own? I
> often get confused between unattended-upgrades and apt there...

Answering my own question, again, on my Debian bookworm machine, there's
a `/etc/cron.daily/apt-compat` script (for systemd-less systems) and a
`apt-daily.service` service. The latter does
`/usr/lib/apt/apt.systemd.daily update` which, if
`APT::Periodic::Update-Package-Lists` is set in apt-config(8), will
periodically update the package list.

I believe that is the canonical and normal way of doing this.

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 11:59:23, Antoine Beaupré wrote:
> severity 1028212 serious
> tags 1028212 +patch

[...]

> From 3b17a4dcb8caa56191c5be523c874a7f470bd04a Mon Sep 17 00:00:00 2001

[...]

> diff --git a/apt_info.py b/apt_info.py
> index eb1a642..9b1b675 100755
> --- a/apt_info.py
> +++ b/apt_info.py

[...]

>  registry = CollectorRegistry()
>  _write_pending_upgrades(registry, cache)
>  _write_held_upgrades(registry, cache)

That patch doesn't actually apply cleanly on bookworm because upstream
did some refactoring, the attached patch should work better.

A.
-- 
C'est avec les pierres de la loi qu'on a bâti les prisons,
et avec les briques de la religion, les bordels.
- William Blake
>From 28c179ddfd3d7e0f5bc49b93f924f0dffba5b71d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Fri, 13 Oct 2023 12:29:48 -0400
Subject: [PATCH] do not run apt update or simulate apt dist-upgrade
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is causing all sorts of problems. The first of which is that
we're hitting our poor mirrors every time the script is ran, which, in
the Debian package configuration, is *every 15 minutes* (!!).

The second is that this locks the cache and makes this script
needlessly stumble upon a possible regression in APT from Debian
bookworm and Ubuntu 22.06:

https://bugs.launchpad.net/ubuntu/+source/apt/+bug/2003851

That still has to be confirmed: it's possible that `apt update` can
hang for a long time, but that shouldn't concern us if we delegate
this work out of band.

I also do not believe actually performing the `dist-upgrade`
calculations is necessary to compute the pending upgrades at all. I've
done work with python-apt for other projects and haven't found that to
be required: the cache has the necessary information about pending
upgrades.

Closes: #179

Signed-off-by: Antoine Beaupré 
---
 apt_info.py | 9 -
 1 file changed, 9 deletions(-)

diff --git a/apt_info.py b/apt_info.py
index 59f3ad7..81a276b 100755
--- a/apt_info.py
+++ b/apt_info.py
@@ -9,7 +9,6 @@
 
 import apt
 import collections
-import contextlib
 import os
 
 _UpgradeInfo = collections.namedtuple("_UpgradeInfo", ["labels", "count"])
@@ -90,14 +89,6 @@ def _write_reboot_required():
 def _main():
 cache = apt.cache.Cache()
 
-# First of all, attempt to update the index. If we don't have permission
-# to do so (or it fails for some reason), it's not the end of the world,
-# we'll operate on the old index.
-with contextlib.suppress(apt.cache.LockFailedException, apt.cache.FetchFailedException):
-cache.update()
-
-cache.open()
-cache.upgrade(True)
 _write_pending_upgrades(cache)
 _write_held_upgrades(cache)
 _write_autoremove_pending(cache)
-- 
2.39.2

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 09:17:49, Kyle Fazzari wrote:

[...]

> I don't entirely agree, but disagreement is okay. I do at least 
> recommend accompanying this with a cache age statistic, as we discussed 
> earlier.

Right, that would be a better way of going around doing that. I have a
separate upstream issue about this, and we can track that problem
there:

https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/issues/180

We might be able to squeeze that metric along with the hotfix here, that
said, we just need to make sure of the better way of reporting that
metric.

a.
-- 
I've got to design so you can put it together out of garbage cans. In
part because that's what I started from, but mostly because I don’t
trust the industrial structure—they might decide to suppress us
weirdos and try to deny us the parts we need.
   - Lee Felsenstein

Bug#1028212: prometheus-node-exporter-collectors: APT update deadlock - prevents unattended security upgrades

[Antoine Beaupré]

On 2023-10-13 09:05:35, Kyle Fazzari wrote:
> On 10/13/23 08:26, Julian Andres Klode wrote:
>> Also please do not run apt update in the background or try to
>> calculate dist upgrades, that is evil and you're breaking stuff.
>> If you want to check for updates, make sure the periodic apt service
>> is configured to run. You are entitled to one run per day. If you
>> do not operate the mirror infrastructure please do not run your own
>> updates out of band.
>
> A fair critique, although as I mentioned in an earlier email, this 
> collector cannot do its job if it's running on a significantly 
> out-of-date cache. At the same time, if feels out of scope for this 
> Debian package to ensure the periodic apt service is configured to run. 
> Feels like a rock and a hard place. Thoughts?

I think this is a deployment issue. People who provision this package
should *not* expect it to run `apt update`: I certainly didn't, and the
previous (shell) implementation didn't either.

We have other tools that continuously pull mirrors, and as jak stated,
APT can be configured to do so as well (although I'm not sure what the
canonical way of doing so).

So let's not do this here.

-- 
A developed country is not a place where the poor have cars. It's
where the rich use public transportation.
- Gustavo Petro 

Bug#1053483: hash-slinger: diff for NMU version 3.1-1.2

[Antoine Beaupré]

On 2023-10-05 16:46:01, Ondřej Surý wrote:
> Go ahead and add yourself to maintainers and do a proper release if you care 
> about the packages. It would be appreciated 

Right now I'm about 4 yaks down in this stack, so adding myself to
maintainers is not part of my priorities right now.

As of all packages we use at torproject.org however, we will try to fix
issues like this when we find them. :) We can't, unfortunately, add
ourselves as maintainers for them any time we fix one of those issues.

Sorry!

A.

PS: should I understand I shouldn't delay the upload any further, otherwise?

-- 
If builders built houses the way programmers built programs,
The first woodpecker to come along would destroy civilization.
- Gerald Weinberg

Bug#1053483: Acknowledgement (tlsa can produce invalid records)

[Antoine Beaupré]

Control: forwarded -1 https://github.com/letoams/hash-slinger/issues/45
Control: tags -1 +patch

I submitted this patch upstream to fix this issue:

https://github.com/letoams/hash-slinger/pull/46

Attached as well.

-- 
Antoine Beaupré
torproject.org system administration
>From e3bec6e2a6b1bda7c52b4c585474fd7cc23ab643 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Charaoui?= 
Date: Wed, 4 Oct 2023 22:05:26 -0400
Subject: [PATCH] fix generic TLSA record generation

It seems like the calculation for the TLSA record never really worked,
as we're doing float division here on the `len()` field. In our case,
that field returned `35.0` which is not valid in our environment.

Doing an integer division gives the correct result in most cases, I
believe.

Closes: #45
---
 tlsa | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tlsa b/tlsa
index cea7230..ec97150 100755
--- a/tlsa
+++ b/tlsa
@@ -513,7 +513,7 @@ class TLSARecord:
 	def getRecord(self, generic=False):
 		"""Returns the RR string of this TLSARecord, either in rfc (default) or generic format"""
 		if generic:
-			return '%s IN TYPE52 \# %s %s%s%s%s' % (self.name, (len(self.cert)/2)+3 , self._toHex(self.usage), self._toHex(self.selector), self._toHex(self.mtype), self.cert)
+			return '%s IN TYPE52 \# %s %s%s%s%s' % (self.name, (len(self.cert)//2)+3 , self._toHex(self.usage), self._toHex(self.selector), self._toHex(self.mtype), self.cert)
 		return '%s IN TLSA %s %s %s %s' % (self.name, self.usage, self.selector, self.mtype, self.cert)
 
 	def _toHex(self, val):
-- 
2.39.2

Bug#1053483: tlsa can produce invalid records

[Antoine Beaupré]

Package: hash-slinger
X-Debbugs-Cc: lavam...@torproject.org
Version: 3.1-1.1~bpo11+1
Severity: grave

On Debian bullseye, running the following command here generates an
invalid DNS record:

pauli# ./tlsa --create --usage=3 --selector=1 --mtype=1 --certificate 
/srv/puppet.torproject.org/from-letsencrypt/cdn-fastly-backend.torproject.org.crt
 --port 443 cdn-fastly-backend.torproject.org --output=generic
Got a certificate for cdn-fastly-backend.torproject.org. with Subject:
/CN=cdn-fastly-backend.torproject.org
_443._tcp.cdn-fastly-backend.torproject.org. IN TYPE52 \# 35.0 
030101e86cb4aa5bec41b44c5e78c0b3b05992ab276d540376aca18eb494d8e229cd4c

Notice the float (35.0) there? That, of course, crashes bind with:

Notice: /Stage[main]/Dnsextras::Entries/Exec[rebuild torproject.org
zone]/returns: dns_rdata_fromtext:
/srv/dns.torproject.org/puppet-extra/include-torproject.org:945: near
'35.0': not a valid number

I suspect this wasn't caught by other users because it happens when the
len() of the cert string is an odd number, which, oddly, I guess it is
here.

I believe this is a release critical bug that should be fixed in
bookworm because it keeps the server from functioning at all. 

For a little background, we used hash-slinger as a replacement for
"swede" here (not packaged) that wasn't ported to Python 3. It *almost*
worked but crashed on some records with the above error, taking down our
main DNS server...

This was also reported in:

https://github.com/letoams/hash-slinger/issues/45

And is being tracked on our side at:

https://gitlab.torproject.org/tpo/tpa/team/-/issues/41350

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages hash-slinger depends on:
ii  ca-certificates20210119
ii  dns-root-data  2021011101
ii  openssh-client 1:8.4p1-5+deb11u1
ii  python33.9.2-3
ii  python3-dnspython  2.0.0-1
ii  python3-gnupg  0.4.6-1
ii  python3-m2crypto   0.37.1-2
ii  python3-unbound1.13.1-1+deb11u1

hash-slinger recommends no packages.

hash-slinger suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/bin/tlsa (from hash-slinger package)

-- 
Antoine Beaupré
torproject.org system administration

Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='

[Antoine Beaupré]

On 2023-06-26 10:27:37, Antoine Beaupré wrote:

[...]

> I guess the first step is to wait for the package to transition to
> trixie and then do the -pu? I suspect it will be hard to test this in
> trixie since you'd need to upgrade from buster to trixie, right?

I meant bullseye here of course, sorry.

I, for one, will be glad to have a few releases not starting with `b`
for a while. :P

-- 
L'homme construit des maisons parce qu'il est vivant, mais il écrit des
livres parce qu'il se sait mortel.
- Daniel Pennac, Comme un roman

Bug#1038935: schleuder: fails to upgrade buster -> bullseye -> bookworm: NoMethodError: undefined method `preparable='

[Antoine Beaupré]

On 2023-06-24 22:38:38, Andreas Beckmann wrote:

[...]

>> I'll prepare a ruby-activerecord proposed-update targeting bookworm.
>
> This needs to be fixed in sid first.
>
> Adding the Conflicts against ruby-arel in ruby-activerecord requires
> changes in src:ruby-premailer-rails, too, since that (directly)
> build-depends on ruby-arel and indirectly on ruby-activerecord.
> Maybe dropping the B-D: ruby-arel is already sufficient.
> These changes need to be backported to bookworm-pu as well.
> If that is fixed, ruby-arel can be removed from sid (and it could be
> considered to remove it from bookworm as well).

Just to make sure, someone still is working on this to make sure it's
fixed in bookworm?

I guess the first step is to wait for the package to transition to
trixie and then do the -pu? I suspect it will be hard to test this in
trixie since you'd need to upgrade from buster to trixie, right?

thanks!

Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

I can confirm that trashing the eln-cache and restarting emacs with
`markdown` in the block list works.

-- 
Le monochrome, c'est pour ceux qui s'intéressent (encore) au contenu.
Usenet dans ces conditions, c'est comme le web avec lynx, on prend
trop conscience du vide, c'est déprimant.
- JLC dans le Guide du linuxien pervers:
  "Coup de cafard..."

Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

On 2023-06-11 14:45:19, Nicholas D. Steeves wrote:
> Hi,
>
> Here is a way to work around this bug (whether in Emacs or in markdown-toc).
>
> To test:
> emacs --eval="(setq native-comp-deferred-compilation-deny-list 
> '(\"markdown-toc\"))"
>
> To make permanent:
> (setq native-comp-deferred-compilation-deny-list '("markdown-toc"))
>
> That said, I'm not convinced that a workaround like this should be
> inserted into Debian's markdown-toc (or any package)...

Oh wow, thanks!

That said it doesn't actually work! I have tried both the `--eval` and
the `setq` and neither fix the crash.

Debugger entered--Lisp error: (wrong-type-argument consp nil)
  markdown-imenu-create-nested-index()
  markdown-toc-generate-toc(nil)
  funcall-interactively(markdown-toc-generate-toc nil)
  command-execute(markdown-toc-generate-toc record)
  execute-extended-command(nil "markdown-toc-generate-toc" nil)
  funcall-interactively(execute-extended-command nil 
"markdown-toc-generate-toc" nil)
  command-execute(execute-extended-command)

I'm not sure this is related to native compilation, is it really?

I thought it was some imenu thing, maybe it doesn't get autoloaded properly?

a.

-- 
Si Dieu existe, j'espère qu'Il a une excuse valable
- Daniel Pennac

Bug#1036359: crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

On 2023-06-05 12:16:28, Antoine Beaupré wrote:
> Is there something out there that takes a markdown doc as input and
> outputs a TOC?

Answering my own question, this does what I want:

md_toc github -o .  < tpa-rfc-36-gitolite-gitweb-retirement.md

... and what I want in many cases is actually:

md_toc github -o .  < tpa-rfc-36-gitolite-gitweb-retirement.md | sed 
's/](#.*//;s/ \[/ /'

which is just an ordered list of items, without markdown links.

md_toc is part of `python3-md-toc`.

Bug#1036359: crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

On 2023-06-03 20:41:40, Nicholas D. Steeves wrote:
> Nicholas D Steeves  writes:
>
>> I also confirmed that both the patched version (in the staging branch)
>> and unpatched version (in bookworm) work correctly with
>>
>>  
>> https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-36-gitolite-gitweb-retirement.md
>>
>> when one loads markdown-toc and generates the toc before native comp
>> kicks in.
>
> Sorry for not being clear.  What I mean is that I believe that this bug
> is triggered by native compilation, and that it's unlikely that I'll
> find enough time figure out what the upstream issue is before the
> autoremoval.  Also, upstream hasn't seen any activity since 2021...
>
> Feel free to forward this bug and/or adopt this package (I don't use
> it).

You seem to have pasted a link to the TPA GitLab wiki here... Did you
mean to paste some other bug report or link there?

I think I'm okay with the package being removed from bookworm if we
can't find a quick fix here. The release date is just too close. We can
always fix this in a point release or get a backport going.

Interestingly, it's not marked as autoremoval here though:

https://tracker.debian.org/pkg/markdown-toc-el

Alternatively, I wonder if there's a way to make a simpler module that
would defer the TOC generation to an external command...

Is there something out there that takes a markdown doc as input and
outputs a TOC?

Cheers,

a.

-- 
Power is always dangerous.
Power attracts the worst and corrupts the best.
- Edward Abbey

Bug#1036359: crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

On 2023-05-19 14:39:14, Nicholas D Steeves wrote:
> Control: tag -1 confirmed upstream fixed-upstream pending
> Antoine Beaupre  writes:
>
>> Package: elpa-markdown-toc
>> Version: 0.1.5-2
>> Severity: grave
>
>> markdown-toc-generate-toc crashes with:
>>
>> Debugger entered--Lisp error: (wrong-type-argument consp nil)
>
> Thanks for reporting; fix pending!

Oh interesting! Where can I see it? is there a patch?

-- 
Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le
loisir de la faire plus courte.
- Blaise Pascal

Bug#1036359: crashes with (wrong-type-argument consp nil)

[Antoine Beaupré]

On 2023-05-19 15:02:34, David Bremner wrote:
> Hi Antoine;
>
> I agree that markdown file looks innocuous, but do you know if it is
> just this file or any markdown file?

I managed to have it generate a TOC with a simple:

# a

# b

## c

But it also crashed (ultimately) on:

https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-36-gitolite-gitweb-retirement.md

a.

-- 
La perfection est atteinte, non pas lorsqu'il n'y a plus rien à
ajouter, mais lorsqu'il n'y a plus rien à retirer.
- Antoine de Saint-Exupéry

Bug#1033517: yt-dlp: mpv fails to work with yt-dlp, after yt-dlp upgrade (uncoordinated API change?)

[Antoine Beaupré]

On 2023-03-28 00:13:46, Francesco Poli wrote:
> On Mon, 27 Mar 2023 00:03:20 -0400 (EDT) Unit 193 wrote:
[...]
>> And here lies the problem.  Seemingly one of the big fixes in 2023.03.03 
>> is a workaround for the aforementioned throttling, to revert would mean to 
>> make yt-dlp unusably slow.  But to leave it as is, mpv can't directly 
>> utilize yt-dlp with the default quality option.
>> 
>> If we weren't so close to the freeze I'd say the right option would be to 
>> simply patch the yt-dlp hook in mpv and move on, but that's not precisely 
>> an option anymore either.
>
> Why not?
>
> The [freeze policy] states that, even in full freeze, fixes for
> important bugs are appropriate, as long as they can be done via unstable
> (as it is currently the case for mpv).
>
> [freeze policy]: 
>
> I have just filed bug [#1033595], in order to request that the patches
> you cited are applied to mpv.
>
> [#1033595]: 
>
> I hope this can be the way to go.

Considering that a bug was filed against mpv, shouldn't this one be
downgraded? I don't quite see why yt-dlp should be kicked out of
bookworm because mpv didn't catchup...

a.
-- 
Never believe that a few caring people can't change the world. For,
indeed, that's all who ever have.
- Margaret Mead

Bug#987008: grub2: diff for NMU version 2.06-8.1

[Antoine Beaupré]

On 2023-03-07 15:59:40, Steve McIntyre wrote:
> On Tue, Mar 07, 2023 at 10:39:04AM -0500, Antoine Beaupré wrote:
>>On 2023-02-26 19:15:39, anar...@debian.org wrote:
>>> Control: tags 987008 + pending
>>>
>>> Dear maintainer,
>>>
>>> I've prepared an NMU for grub2 (versioned as 2.06-8.1) and
>>> uploaded it to DELAYED/2. Please feel free to tell me if I
>>> should delay it longer.
>>>
>>> Note that the package was uploaded to *experimental*, not unstable, as
>>> an extra precaution. Let me know if you will followup with an unstable
>>> update or I should.
>>
>>Timing out.
>>
>>I have now uploaded this package to unstable, DELAYED/2.
>
> Argh, no. I've taken your changes already, but I'm in the middle of
> some other grub work. Let's not waste time and effort on an NMU going
> through the system, complete with signing etc.

Okay, so I'll cancel the NMU.

Bug#987008: grub2: diff for NMU version 2.06-8.1

[Antoine Beaupré]

On 2023-02-26 19:15:39, anar...@debian.org wrote:
> Control: tags 987008 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for grub2 (versioned as 2.06-8.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Note that the package was uploaded to *experimental*, not unstable, as
> an extra precaution. Let me know if you will followup with an unstable
> update or I should.

Timing out.

I have now uploaded this package to unstable, DELAYED/2.

a.

-- 
The ideal situation occurs when the things that we regard as beautiful
are also regarded by other people as useful.
- Donald Knuth

Bug#987008: please review this grub patch to fix LVM rename support

[Antoine Beaupré]

Hi Peter,

I'm writing to you as the author of this patch in grub:

https://git.savannah.gnu.org/cgit/grub.git/commit/?id=879c4a8342eacc0ba4b9dd11dc69d3ec3dbe73af

We've had a report of a release-critical bug (in CC) against grub in
Debian that claims boot failures after renaming a logical volume:

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

The suggested patch (author in CC) is quite short:

---
Index: grub2-2.02+dfsg1/grub-core/disk/lvm.c
===
--- grub2-2.02+dfsg1.orig/grub-core/disk/lvm.c
+++ grub2-2.02+dfsg1/grub-core/disk/lvm.c
@@ -253,7 +253,7 @@ error_parsing_metadata:

   p = q = (char *)ptr;

-  if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, ))
+  if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), ))
 goto error_parsing_metadata;

   mda_end = (char *)ptr;


I have tried to review the patch but quickly got lost in this long
function, so I'm not sure it's the right fix.

Could you expand on the rationale on why the rlocn->offset is checked
first but mda_size instead of rlocn->size in the second case?

Thank you for any input,

a.


signature.asc
Description: PGP signature

Bug#987008: grub LVM bug #987008: experimental package available, please test

[Antoine Beaupré]

Hi everyone,

I have uploaded a NMU of this package in experimental, with a 2-days
delayed to give the maintainers here time to respond... Considering the
importance of grub, i figured it was safer that way.

A copy of the package is also available here:

https://people.debian.org/~anarcat/debian/sid/

You should be able to get a cryptographically verified binary package using:

dget https://people.debian.org/~anarcat/debian/sid/grub2_2.06-8.1_amd64.changes

I would be grateful if someone could test the resulting package in their
environments and do some smoke tests on the conditions of this bug
report. I haven't had the leisure to reproduce the test harness nor the
bug, so I rely on you to confirm the package actually fixes this
properly.

Once I get confirmation, this can be re-uploaded into unstable directly,
which should fix the bug in bookworm (eventually).

Thank you for your time,

a.

-- 
It is better to sit alone than in company with the bad; and it is better
still to sit with the good than alone. It better to speak to a seeker of
knowledge than to remain silent; but silence is better than idle words.
- Imam Bukhari


signature.asc
Description: PGP signature

Bug#987008: working on this bug

[Antoine Beaupré]

owner 987008 anar...@debian.org
thanks

Hi,

I've ported the submitted patch here into the package and plan to upload
an NMU shortly.

To quote the actual patch file I ended up with:

Description: fix renamed LV detection
  It looks like the detection of the LVM logical volumes fails in
  certain edge conditions. In particular, it was reported that
  renaming an LV will make grub fail to boot from the system as it
  cannot properly detect it anymore.
  .
  I have looked at the code surrounding the patch and cannot claim to
  understand the entire function here, as it is huge and quite
  cryptic. But it seems sane: the `ptr` we're inspecting here starts
  at the `rlocn->offset`, but we were adding `mda_size` to the
  (somewhat) unrelated metadatabuf instead. Now we're marking the
  `mda_end` correctly, based on the rlocn->offsite and ->size.
  .
  I have not tested this myself as the test setup is quite involved,
  but it seems others (e.g. "Hoyer, David" )
  have tested the patch and confirmed it worked.

A.

-- 
Never be deceived that the rich will allow you to vote away their wealth.
- Lucy Parsons

Bug#997179: tty-clock: FTBFS: ttyclock.c:278:73: error: format not a string literal and no format arguments [-Werror=format-security]

[Antoine Beaupré]

tag 997179 +pending
user debian-rele...@lists.debian.org
usertag 997179 + bsp-2023-02-ca-montreal
thanks

I've orphaned this package (#1031941) but I figured I could at least fix
this bug before I go.
-- 
When the power of love overcomes love of power the world will know peace.
- Jimi Hendrix

Bug#1028333: [Pkg-puppet-devel] Bug#1028333: puppetserver: find an upgrade path from puppet-master

[Antoine Beaupré]

On 2023-01-19 11:30:31, Jérôme Charaoui wrote:
> So considering all this I'm currently leaning towards adding a 
> transitional "puppet-master" and/or "puppet-master-passenger" package 
> for the purpose of shipping a NEWS file recommending that users migrate 
> to the puppetserver package manually.

Agreed. We should also probably make an entry in the release
notes. According to the RT, this should be done in a MR here:

https://salsa.debian.org/ddp-team/release-notes/

-- 
Never underestimate the bandwidth of a station wagon full of tapes
hurtling down the highway.
- Andrew S. Tanenbaum, "Computer Networks"

Bug#1027947: merging some bugs into this

[Antoine Beaupré]

reassign 1028689 1028767 1028739 1028689 setuptools-scm
forcemerge 1027947 1028767 1028739 1028689
affects 1028767 sphinxs-autodoc-typehints
affects 1028739 pubpaste
affects 1028689 stressant
thanks

It seems like this bug is affecting a *lot* of packages. Just on my
side, two packages are FTBFS and I suspect more are coming. So I have
merged the few we confirmed (in #debian-python) that are affected by
this directly, but tumbleweed found possibly 36 more FTBFS that are
related:

https://paste.debian.net/1267195/

Appended below in case it gets rotated out. I haven't merged all of
those here just yet as they need to be inspected individually... or not?
Maybe it would suffice to just close them in the upload? Not sure what
the best course of action is here.

I don't have time to handle this right now, but it seems to me an urgent
upload of this package is in order to avoid further damage...

a.

-- 
We reject kings, presidents and voting.
We believe in rough consensus and running code.
- David Clark

udd=> SELECT id, title FROM bugs WHERE title like '%pip%tomli%';

   id|  
title   

   
-+-
 1028675 | defcon: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmpyii6c34w', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028682 | pytest-datadir: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmp5v184i0l', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028685 | python-moreorless: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmpplzevbo5', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028689 | stressant: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmp0mjlxei3', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028692 | python-django-simple-history: FTBFS: 
distutils.errors.DistutilsError: Command '['/usr/bin/python3.10', '-m', 'pip', 
'--disable-pip-version-check', 'wheel', '--no-deps', '-w', '/tmp/tmp5h4kkd45', 
'--quiet', 'tomli>=1.0.0']' returned non-zero exit status 1.
 1028693 | python-httpsig: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmpx89_6m9x', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028700 | gftools: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmpbduohu8m', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028701 | python-pynetbox: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmpgjvv751g', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028702 | python-signedjson: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmpgpptvxh2', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028703 | python-glyphsets: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmplxebepu8', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028706 | wxmplot: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmp6lc3j72o', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028708 | sphinx-autorun: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmp41vr75jq', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028721 | khard: FTBFS: distutils.errors.DistutilsError: Command 
'['/usr/bin/python3.10', '-m', 'pip', '--disable-pip-version-check', 'wheel', 
'--no-deps', '-w', '/tmp/tmpyt_g2chc', '--quiet', 'tomli>=1.0.0']' returned 
non-zero exit status 1.
 1028723 | python-inflect: FTBFS: 

Bug#1026005: cumin FTBFS: Tries to use $HOME

[Antoine Beaupré]

Hi all,

So cumin is failing to build in Debian because it does some nasty things
during build (namely using $HOME, because of that setup.py develop --user).

I have a beginning of a fix for this in the bugfix-1026005 branch on
salsa. The problem now is that it fails on *other* parts of the test
suite, which wasn't failing before. I suspect it might be because the
code layout is different, but I can't figure out how or why...

Riccardo, Moritz, any ideas on how this could be fixed?

Here's the failing build log:

anarcat@angela:cumin$ dpkg-buildpackage 
dpkg-buildpackage: info: source package cumin
dpkg-buildpackage: info: source version 4.1.1-3
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Antoine Beaupré 
dpkg-buildpackage: info: host architecture amd64
 dpkg-source --before-build .
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-import-version-number-from-setuptools_scm.patch
 fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:240: python3.10 setup.py clean 
running clean
removing '/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build' (and 
everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.10' does not exist -- can't clean it
   dh_autoreconf_clean -O--buildsystem=pybuild
   dh_clean -O--buildsystem=pybuild
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: warning: upstream signing key but no upstream tarball signature
dpkg-source: info: building cumin using existing ./cumin_4.1.1.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building cumin in cumin_4.1.1-3.debian.tar.xz
dpkg-source: info: building cumin in cumin_4.1.1-3.dsc
 debian/rules build
dh build --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:240: python3.10 setup.py config 
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:240: /usr/bin/python3 setup.py build 
running build
running build_py
creating /home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin
copying cumin/transport.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin
copying cumin/color.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin
copying cumin/cli.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin
copying cumin/__init__.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin
copying cumin/grammar.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin
copying cumin/query.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin
creating 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/backends
copying cumin/backends/direct.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/backends
copying cumin/backends/openstack.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/backends
copying cumin/backends/puppetdb.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/backends
copying cumin/backends/knownhosts.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/backends
copying cumin/backends/__init__.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/backends
creating 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/transports
copying cumin/transports/clustershell.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/transports
copying cumin/transports/__init__.py -> 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build/cumin/transports
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:240: cd 
/home/anarcat/dist/cumin/.pybuild/cpython3_3.10_cumin/build; python3.10 -m 
pytest /home/anarcat/dist/cumin/cumin/tests/unit
 test 
session starts 

platform linux -- Python 3.10.8, pytest-7.1.2, pluggy-1.0.0+repack
rootdir: /home/anarcat/dist/cumin, configfile: pytest.ini
plugins: arraydiff-0.5.0, betamax-0.8.1, astropy-header-0.2.2, 
remotedata-0.3.3, requests-mock-1.9.3, hypothesis-6.36.0, openfiles-0.5.0, 
mock-3.8.2, astropy-0.10.0, cov-4.0.0, doctestplus-0.12.1, 
filter-subpackage-0.1.1
collected 416 items 


../../../cumin/tests/unit/test_backends.py .
  [  0%

Bug#1010544: victoriametrics: FTBFS on armel

[Antoine Beaupré]

Seems to me we could just kick armel out of the supported architectures
for this package for now... I think we'd need to downgrade the severity
of this bug report, and remove the armel package from testing.

What do people think here?
-- 
Never believe that a few caring people can't change the world. For,
indeed, that's all who ever have.
- Margaret Mead

Bug#1022393: moment-timezone.js: FTBFS: make[1]: *** [debian/rules:12: data/meta/2022c.json] Error 1

[Antoine Beaupré]

On 2022-10-23 15:21:14, Lucas Nussbaum wrote:
>> make[1]: Entering directory '/<>'
>> # Fail the build if the tzdata package does not match TZVER.
>> grep -q '^# version 2022c$' /usr/share/zoneinfo/tzdata.zi
>> make[1]: *** [debian/rules:12: data/meta/2022c.json] Error 1

this looks like a failure due to the tzdata update... it looks like the
fix is just to update to latest upstream:

https://github.com/moment/moment-timezone/releases/tag/0.5.38

a.

-- 
Hard times are coming when we will be wanting the voices of writers
who can see alternatives to how we live now and can see through our
fear-stricken society and its obsessive technologies to other ways of
being, and even imagine some real grounds for hope. We will need
writers who can remember freedom. Poets, visionaries—the realists of a
larger reality. - Ursula Le Guin

Bug#1008263: plans to upload memtest86+ 6 to unstable?

[Antoine Beaupré]

On 2022-10-06 22:11:54, Fabio Fantoni wrote:
> Il 06/10/2022 17:44, Antoine Beaupré ha scritto:
>> Hello Fabio!
>>
>> Below is an excerpt of a discussion that happened in bug #1008263 about
>> removing pcmemtest from Debian, to remove the duplication of work with
>> memtest86+:
>>
>> On 2022-09-09 17:08:34, Felix Zielcke wrote:
>>> I wasn't sure if I should wait until the new memtest86+ gets out of
>>> beta and uploaded to unstable. But yeah, maybe it's better to just file
>>> the RM now
>> I am wondering if you had any plans to upload memtest86+ 6 to unstable
>> already? It looks like it could fix a *lot* of issues that currently
>> affect memtest86, which is basically unusable on modern platforms right
>> now.
>>
>> For example, on my Framework laptop -- which only boots from EFI --
>> memtest86 from testing/unstable just doesn't boot at all. I am just
>> testing the version from experimental and, so far so good, it seems to
>> work fine!
>>
>> Thanks for any update!
>>
> Hi, I was waiting the release of the definitive (stable) version before 
> upload to unstable, unfortunately the release scheduled for a month ago 
> was delayed, however x86fr said there is a last patch missing that he 
> needs to add shortly and then 6.00 will be released

I still think the current beta release is better than what we have in
unstable... But as long as it makes it to bookworm, I'm happy. :)

a.

-- 
Be conservative in what you send and liberal in what you accept.
- John Postel

Bug#1008263: plans to upload memtest86+ 6 to unstable?

[Antoine Beaupré]

Hello Fabio!

Below is an excerpt of a discussion that happened in bug #1008263 about
removing pcmemtest from Debian, to remove the duplication of work with
memtest86+:

On 2022-09-09 17:08:34, Felix Zielcke wrote:
> I wasn't sure if I should wait until the new memtest86+ gets out of
> beta and uploaded to unstable. But yeah, maybe it's better to just file
> the RM now

I am wondering if you had any plans to upload memtest86+ 6 to unstable
already? It looks like it could fix a *lot* of issues that currently
affect memtest86, which is basically unusable on modern platforms right
now.

For example, on my Framework laptop -- which only boots from EFI --
memtest86 from testing/unstable just doesn't boot at all. I am just
testing the version from experimental and, so far so good, it seems to
work fine!

Thanks for any update!

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of speech
because I have nothing to say."
- Edward Snowden

Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Antoine Beaupré]

On 2022-10-03 18:21:46, Michael Prokop wrote:
> AFAICT (thanks to our daily Grml ISO builds) this RC bug caused
> puppet to get removed from Debian/testing, so unless this gets fixed
> we won't have puppet in bookworm? Is anyone taking care of this?

Puppet 5 has been EOL for years. It's a good thing it's gone from
bookworm, and a deliberate act on part of the Puppet package
maintainers.

We've packaged puppet-agent 7 and uploaded to unstable, it should
trickle down in bookworm in a day or two if all goes well.

We're working on packaging puppetserver 7. You can follow that work and
more here:

https://wiki.debian.org/Teams/Puppet/Work

A.

-- 
Imagine a world in which every single person on the planet is given
free access to the sum of all human knowledge.
 - Jimmy Wales, co-founder of Wikipedia

Bug#1017313: postfix: FTBFS: unistd.h:363:13: error: conflicting types for ‘closefrom’; have ‘void(int)’

[Antoine Beaupré]

Control: tags -1 +patch

On 2022-08-14 10:46:11, Lucas Nussbaum wrote:
>> In file included from ./vstream.h:22,
>>  from attr_print0.c:100:
>> /usr/include/unistd.h:363:13: error: conflicting types for ‘closefrom’; have 
>> ‘void(int)’
>>   363 | extern void closefrom (int __lowfd) __THROW;
>>   | ^
>> In file included from attr_print0.c:92:
>> ./sys_defs.h:1512:12: note: previous declaration of ‘closefrom’ with type 
>> ‘int(int)’
>>  1512 | extern int closefrom(int);
>>   |^
>> make: *** [Makefile:212: attr_print64.o] Error 1

Would this patch cut it? Not sure where to forward this upstream
either...

-- 
Prolétaires de tous les pays, qui lave vos chaussettes?
- Audrey Lorde
Description: fix closefrom declaration (Closes: #1017313)
  Some change in libc (or gcc?) broke compilation of Postfix in Debian
  bookworm (coming stable). It's unclear exactly when this definition
  changed, but it's clearly breaking builds in Debian right now.
  .
  Postfix uses this function only once, and discards the return value,
  so it's effectively void anyways.  
Author: Antoine Beaupré 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017313
Forwarded: no
Last-Update: 2022-09-23

--- postfix-3.6.4.orig/src/util/sys_defs.h
+++ postfix-3.6.4/src/util/sys_defs.h
@@ -1509,7 +1509,7 @@ extern int setsid(void);
 #endif
 
 #ifndef HAS_CLOSEFROM
-extern int closefrom(int);
+extern void closefrom(int);
 
 #endif
 

Bug#1008263: pcmemtest is goging to replace memtest86+ upstream

[Antoine Beaupré]

On 2022-03-25 17:12:42, Felix Zielcke wrote:
> I'm not yet sure if I should file a removal bug for pcmemtest.
> But I think I'll just wait and see if that is necessary

I think you should: right now pcmemtest *will* ship with Debian
bookworm, and I don't think that's right if upstream development has
shifted to memtest86+...

Instead of maintaining this package, it seems to me efforts should be
made to bring memtest86+ 6 into bookworm (which it is currently not, it
seems stuck in experimental).

A fair way to keep this package out of bookworm would be to raise the
severity of this bug report to `serious`, which should kick it out of
bookworm in no time.

Then, of course, an RM request would be appropriate as well.

Thanks for maintaining those packages!

A.

-- 
Blind respect for authority is the greatest enemy of truth.
   - Albert Einstein

Bug#1009643: [Pkg-puppet-devel] Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Antoine Beaupré]

Control: reassign -1 src:puppet

On 2022-08-25 14:19:42, Antoine Beaupré wrote:

[...]

> For what it's worth, I have tested lavamind's Puppet 7 package from
> experimental, on bookworm, and it works fine:
>
> https://tracker.debian.org/pkg/puppet-agent
>
> ... I am not sure how to express this in the BTS here, because it's a
> different source package, so I can't mark it as fixed there without
> first marking it as affecting that other package, but it never affected
> it.

The correct way seems to be to move this bug report back to src:puppet
where it belongs, which this message should do.

-- 
A man is none the less a slave because he is allowed to choose a new
master once in a term of years.
 - Lysander Spooner

Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Antoine Beaupré]

On 2022-04-14 10:49:43, Antoine Beaupré wrote:
> On 2022-04-13 17:26:27, Gabriel Filion wrote:
>> Hi there,
>>
>> For what it's worth, upstream puppet does not yet suppport ruby 3.0.
>>
>> see: https://puppet.com/docs/puppet/7/release_notes_puppet.html
>>
>> puppet 7 added support for ruby 2.7 but 2.9 and 3.0 were never there 
>> upstream. I'm guessing they'll bump to 3.x for the puppet 8 cycle only.
>
> That's actually not quite correct: Puppet 7.8 added support for Ruby 3,
> so we should be able to jump there.
>
> It is my hope that we can ship Puppet agent 6 and Puppet server 7 in
> bookworm to fix all of those issues in one fell swoop. See:
>
> https://alioth-lists.debian.net/pipermail/pkg-puppet-devel/2022-April/012681.html
>
> I don't think it's worth fixing the Puppet 5.5 packages to be honest,
> our energy is better spent updating to upstream packages.

For what it's worth, I have tested lavamind's Puppet 7 package from
experimental, on bookworm, and it works fine:

https://tracker.debian.org/pkg/puppet-agent

... I am not sure how to express this in the BTS here, because it's a
different source package, so I can't mark it as fixed there without
first marking it as affecting that other package, but it never affected
it.

Anyways, just to say that this is fixed in experimental. :)

-- 
A developed country is not a place where the poor have cars. It's
where the rich use public transportation.
- Gustavo Petro 

Bug#1013933: Keep xsane out of Debian releases

[Antoine Beaupré]

On 2022-06-27 19:25:13, Jörg Frings-Fürst wrote:
> This is a placeholder RC bug to prevent xsane from entering testing
> and making it to a Debian release. Xsane has not been maintained by
> the Upstream author since 2014. Even the current fork does not show
> much further development.
>
> Because of the bugs in the GUI I don't think the current version
> is suitable for a Debian release.
>
> Should the fork develop positively, I will close this bug.

Good to know, thanks!

Are you aware of an alternative SANE GUI that would be a good
replacement for xsane?

-- 
Brief is this existence, as a fleeting visit in a strange house.
The path to be pursued is poorly lit by a flickering consciousness.
   - Albert Einstein

Bug#1017434: speedtest-cli: error message "Cannot retrieve speedtest configuration"

[Antoine Beaupré]

Control: severity -1 normal

On 2022-08-24 17:15:20, Antoine Beaupré wrote:
> Control: tags -1 +unreproducible
>
> It's funny, I had this exact same problem earlier, and now it's
> gone. Maybe it's a transient issue with speedtest.net itself?

I still can't reproduce this. I can only assume it was a glitch on the
speedtest website, because things are back to normal now.

Maybe the bug here is "there should be better feedback to the user when
the site crashes", but that certainly doesn't warrant the current
severity.

a.

-- 
Dr. King’s major assumption was that if you are nonviolent, if you
suffer, your opponent will see your suffering and will be moved to
change his heart. He only made one fallacious assumption: In order for
nonviolence to work, your opponent must have a conscience. The United
States has none.- Stokely Carmichael

Bug#1017434: speedtest-cli: error message "Cannot retrieve speedtest configuration"

[Antoine Beaupré]

Control: tags -1 +unreproducible

It's funny, I had this exact same problem earlier, and now it's
gone. Maybe it's a transient issue with speedtest.net itself?
-- 
Brief is this existence, as a fleeting visit in a strange house.
The path to be pursued is poorly lit by a flickering consciousness.
   - Albert Einstein

Bug#981009: charybdis abandoned upstream, do not ship in bullseye

[Antoine Beaupré]

On 2022-08-02 13:46:44, Chris Hofstaedtler wrote:
> * Antoine Beaupre :
>> After a somewhat long period of uncertainty, Charybdis has been
>> finally abandoned upstream. The official git repository here:
>> 
>> https://github.com/charybdis-ircd/charybdis
>> 
>> .. is marked as "archived by the owner [and] read-only".
>
> Is it time to file an RM bug, given that its probably going to be
> solanum?

Sure, feel free.

-- 
Be yourself. Everyone else is already taken!
- Oscar Wilde

Bug#1009010: fix remaining bugs

[Antoine Beaupré]

On 2022-06-24 16:53:20, Georges Khaznadar wrote:
> Hello, please find as an attachment a patch to fix #1012190 and #981703
> and close them.

Hi,

thanks for the patches.

I am note sure they work though, see my comments below...

> -- 
> Georges KHAZNADAR et Jocelyne FOURNIER
> 22 rue des mouettes, 59240 Dunkerque France.
> Téléphone +33 (0)3 28 29 17 70
>
> diff --git a/debian/changelog b/debian/changelog
> index f5795bd..2c59b7e 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,18 @@
> +slop (7.6-2.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * added a file d/libslop7.6.shlibs; #closes: #1012190

I don't understand why this is necessary. #1012190 should be closed
automatically when 7.6 migrates to testing, it's already marked as fixed
in unstable, deliberately.

> +  * modified d/control
> ++ now libslop7.6 conflicts with libslop7.5 and replaces it

libslop7.5 doesn't exist as far as I know, why is that necessary?

> ++ added a strict dependency libdevel =>
> +  libslopy7.6(>= ${source:Version}), libslopy7.6(<= ${source:Version}.1~)

shouldn't the shlibs:Depends do the right thing here?

i should also note that the bug to fix here is #1009010 and it's going
to be fixed once 7.6-2 passes NEW (which it entered yesterday).

> +  * applied GSR's patch; closes: #981703

i'd rather have that merged in when upstream does that release, instead
of carrying that local patch...

> +  * modified d/rules to clean out bin/slop

[...]

> diff --git a/debian/rules b/debian/rules
> index bb2a2a9..61fae45 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -20,3 +20,8 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
>  # main packaging script based on dh7 syntax
>  %:
>   dh $@
> +
> +override_dh_auto_clean:
> + dh_auto_clean
> + # remove a binary file not cleaned by the Makefile
> + rm -f bin/slop

could you submit this upstream?

thanks.

-- 
Nothing incites to money-crimes like great poverty or great wealth.
- Mark Twain

Bug#1011545: [Debian Bug Tracking System] Bug#1011545 closed by Debian FTP Masters (reply to Anthony Fok ) (Bug#1011545: fixed in gh 2.4.0+dfsg1-3)

[Antoine Beaupré]

Hum. Now I'm a little confused: why did you do this?

* Add diversion for /usr/bin/gh to allow concurrent install with gitsome
  and remove Conflicts with gitsome. This is inspired by the conflict
  resolution between the moreutils and parallel packages where both
  contain /usr/bin/parallel.  See discussions in #749355.

This seems like it's the opposite of what I was suggesting in the bug
report (#1011545). And you even refer to that bug report in the
changelog:

* Limit "Conflicts: gitsome" to older (<< 0.8.0+ds-7.1) versions.
  Thanks to Antoine Beaupre for the suggestion, and for resolving the
  file conflict with gitsome (#1005858) so amicably! (Closes: #1011545)

What actually happened, from what I can tell, is that you just removed
the Conflicts... I don't think that's the right resolution here: gitsome
has been fixed, in unstable, and gh doesn't need to go around with fancy
diversion stuff, because we're *precisely* not in a situation like
moreutils and parallel...

Could this change be reverted?

-- 
When I came back to the United States, I decided that if you could use
propaganda for war, you could certainly use it for peace. And
"propaganda" got to be a bad word because of the Germans using it, so
what I did was to try and find some other words so we found the words
"public relations".  - Edward Bernays


--- Begin Message ---
This is an automatic notification regarding your Bug report
which was filed against the gh package:

#1011545: please version the Conflicts: with gitsome

It has been closed by Debian FTP Masters  
(reply to Anthony Fok ).

Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Debian FTP Masters 
 (reply to Anthony Fok ) by
replying to this email.


-- 
1011545: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011545
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: gh
Source-Version: 2.4.0+dfsg1-3
Done: Anthony Fok 

We believe that the bug you reported is fixed in the latest version of
gh, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1011...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Anthony Fok  (supplier of updated gh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 31 May 2022 01:58:33 -0600
Source: gh
Architecture: source
Version: 2.4.0+dfsg1-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Go Packaging Team 
Changed-By: Anthony Fok 
Closes: 1008761 1011545
Changes:
 gh (2.4.0+dfsg1-3) unstable; urgency=medium
 .
   * Limit "Conflicts: gitsome" to older (<< 0.8.0+ds-7.1) versions.
 Thanks to Antoine Beaupre for the suggestion, and for resolving the
 file conflict with gitsome (#1005858) so amicably! (Closes: #1011545)
   * Change default editor from nano to /usr/bin/editor as per Debian Policy
 §11.4. Thanks to Jakub Wilk for the bug report. (Closes: #1008761)
   * Rename "Build-Using" field to "Static-Build-Using" in debian/control
   * Add diversion for /usr/bin/gh to allow concurrent install with gitsome
 and remove Conflicts with gitsome. This is inspired by the conflict
 resolution between the moreutils and parallel packages where both
 contain /usr/bin/parallel.  See discussions in #749355.
Checksums-Sha1:
 1092d879dbffd7d271b7fea3191a511b8b721086 3914 gh_2.4.0+dfsg1-3.dsc
 c563c649ee6d53af12f8f0b3aa96ed7ffd38e449 940048 gh_2.4.0+dfsg1-3.debian.tar.xz
 22ce340f153035ba9c31b4caee0303686279d6d2 12875 gh_2.4.0+dfsg1-3_amd64.buildinfo
Checksums-Sha256:
 80c5e5b02c9c08368844d664be37d0efa8dd3042a94aa9fec21245ae8bc7bf19 3914 
gh_2.4.0+dfsg1-3.dsc
 73bc2982038e0591645b097206394ce0c9cf8ec76bea81bac7ecc3f98d3b04d6 940048 
gh_2.4.0+dfsg1-3.debian.tar.xz
 338bbbcbb80aedd05607ae6c2a7c8f5e93bb8d74be6e713b3329d6c71b158725 12875 
gh_2.4.0+dfsg1-3_amd64.buildinfo
Files:
 faf8dbe284cccd7fc02d4c4d749450ef 3914 golang optional gh_2.4.0+dfsg1-3.dsc
 28794e83d36e6b935976254736cdfcbd 940048 golang optional 
gh_2.4.0+dfsg1-3.debian.tar.xz
 7e1b70f938b6d7f4f0fe3ccdc86cb1ae 12875 golang optional 
gh_2.4.0+dfsg1-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQJEBAEBCAAuFiEEFCQhsZrUqVmW+VBy6iUAtBLFms8FAmKWNO4QHGZva2FAZGVi
aWFuLm9yZwAKCRDqJQC0EsWaz/xAD/9RtxjOETIInSGTEbCNDE4U/k/F2y5T11Ki
zUMk0bF6O8zXMwWGsDI8zo35WIMA8O1SHQj2tD/Odr1gDs6CN4YZE7fMCnRBxYWe
HPgkPv+rUIHnsAdvQI1ER+grqb8uytvnd+baBIolr/7z+Br2kKAHFN5Qst7l3Et6

Bug#994855: zfs-dkms: Panic when receiving, fixed upstream

[Antoine Beaupré]

Is there a plan to fix this in bullseye as well?

Bug#929165: How to use rm_conffile to remove files that contain empty " ", comma "," and wildcard "*"?

[Antoine Beaupré]

On 2022-05-16 19:13:45, Andreas Metzler wrote:
> On 2022-05-16 Antoine Beaupré  wrote:
>> Sorry for jumping in, but this bug report has been open for more than
>> three years now, and blocked this package from shipping with
>> bullseye. It's still blocking it from bookworm as well...
>
>> On 2021-03-14 13:53:17, Andreas Metzler wrote:
>> [...]
>>> Hello is using debhelper compat 9 though, it breaks with compat >= 12. 9
>>> does not warn, 10-11 warn without fatal error., 12 and later fail.
>
>>> So you could work around this by avoiding this dh_installdeb
>>> functionality and directly adding dpkg-maintscript-helper
>>> invocations to {post,pre}{inst,rm}.
>
>>> I will submit a bug against debhelper and Cc you.
>
>> Where is that bug report?
>
> Hello Antoine,
>
> https://bugs.debian.org/985212

I guess that bug should marked as a blocker of this one?

Maybe with Debhelper 13 (with the {Space} stuff), we could make a new
patch?

a.

-- 
Do not use your energy to worry.
Use your energy to believe, to create, to learn, to think, and to grow.
- Richard Feynman

Bug#929165: How to use rm_conffile to remove files that contain empty " ", comma "," and wildcard "*"?

[Antoine Beaupré]

Hi everyone!

Sorry for jumping in, but this bug report has been open for more than
three years now, and blocked this package from shipping with
bullseye. It's still blocking it from bookworm as well...

On 2021-03-14 13:53:17, Andreas Metzler wrote:
[...]
> Hello is using debhelper compat 9 though, it breaks with compat >= 12. 9
> does not warn, 10-11 warn without fatal error., 12 and later fail.
>
> So you could work around this by avoiding this dh_installdeb
> functionality and directly adding dpkg-maintscript-helper
> invocations to {post,pre}{inst,rm}.
>
> I will submit a bug against debhelper and Cc you.

Where is that bug report?

Are the tags still valid here? (moreinfo - should there be +patch?)

Thanks!

a.

-- 
The university must paint itself black, mulatto, worker anddd
peasant. If not, people will break down their doors and paint the
university the color they like.
- Ernesto "Che" Guevara

Bug#1009643: Puppet: Fails to work with Ruby 3.0

[Antoine Beaupré]

On 2022-04-13 17:26:27, Gabriel Filion wrote:
> Hi there,
>
> For what it's worth, upstream puppet does not yet suppport ruby 3.0.
>
> see: https://puppet.com/docs/puppet/7/release_notes_puppet.html
>
> puppet 7 added support for ruby 2.7 but 2.9 and 3.0 were never there 
> upstream. I'm guessing they'll bump to 3.x for the puppet 8 cycle only.

That's actually not quite correct: Puppet 7.8 added support for Ruby 3,
so we should be able to jump there.

It is my hope that we can ship Puppet agent 6 and Puppet server 7 in
bookworm to fix all of those issues in one fell swoop. See:

https://alioth-lists.debian.net/pipermail/pkg-puppet-devel/2022-April/012681.html

I don't think it's worth fixing the Puppet 5.5 packages to be honest,
our energy is better spent updating to upstream packages.

-- 
That's the kind of society I want to build. I want a guarantee - with
physics and mathematics, not with laws - that we can give ourselves
real privacy of personal communications.
 - John Gilmore

Bug#1009010: slop: maim: error while loading shared libraries: libslopy.so.7.5: cannot open shared object file: No such file or directory

[Antoine Beaupré]

On 2022-04-05 22:36:30, Axel Beckert wrote:
> Package: slop
> Version: 7.6-1
> Severity: serious
> Control: affects -1 maim
>
> Slop seems to provide a shared library without having a proper SONAME or
> ABI in the package name and bumping the library made at least "maim" to
> fail to work:
>
> maim: error while loading shared libraries: libslopy.so.7.5: cannot open 
> shared object file: No such file or directory
>
> From my point of view, it is an error of slop to provide a shared
> library but not having a proper library package with proper SONAME or
> ABI version in the package name.
>
> In case you disagree, please do not provide a shared library at all and
> do compile this library directly into the binary "slop".

I agree, this is a long-standing bug in the package, and a lintian
warning I have consistently (and incorrectly) ignored.

I would be happy to take whatever fix you think is best for this. The
package is in salsa.debian.org/debian and i'm LowNMU.

I think my main blocker is fixing this is that I am not super familiar
with shared libs packages. It also seems a little silly to have a shared
lib for something that's essentially called by other packages (although
now it seems that maim does use it as a shared lib).

The other problem is introducing a shared lib would make us go through a
round trip in NEW, but hopefully that should be trivial enough to be
fast.

Anyways, thanks for the bug report, and definitely something that needs
fixing. In the meantime I think a binNMU might fix this on maim's side,
right?

a.

-- 
The steel horse fills a gap in modern life, it is an answer not only to
its needs, but also to its aspirations.  It's quite certainly here to
stay.
 - Le Vélocipède Illustré, 1869

Bug#995202: horst: diff for NMU version 5.1-2.1

[Antoine Beaupré]

On 2021-11-28 20:55:34, Adrian Bunk wrote:
> Dear maintainer,
>
> I've prepared an NMU for horst (versioned as 5.1-2.1) and uploaded
> it to DELAYED/14. Please feel free to tell me if I should cancel it.

Feel free to upload it directly, thanks!

-- 
We are discreet sheep; we wait to see how the drove is going, and then go
with the drove.
- Mark Twain

Bug#997003: workaround

[Antoine Beaupré]

Hi,

It seems to me a workaround for this bug is to run the systemd unit of
the PHP-FPM process as `www-data`. This should mitigate the privilege
escalation because the process would escalate from `www-data`
to... well, `www-data`.

Obviously that doesn't work if you have multiple pools running as
different users.

Three files need to be changed for this to take effect:

# cat /etc/systemd/system/php7.3-fpm.service.d/override.conf 
[Service]
# mitigation for possible privilege escalations in php-fpm
# (e.g. CVE-2021-21703): do not run the master as root
User=www-data

# cat /etc/php/7.3/fpm/pool.d/00-rootless-logs.conf 
[global]
; default value from Debian: /var/log/php7.3-fpm.log
error_log = /var/log/php/fpm.log

# cat /etc/logrotate.d/php7.3-fpm 
/var/log/php/fpm.log {
rotate 12
weekly
missingok
notifempty
compress
delaycompress
postrotate
/usr/lib/php/php7.3-fpm-reopenlogs
endscript
}

php-fpm and systemd needs to be reloaded as well:

systemctl daemon-reload
systemctl restart php7.3-fpm

This should also be possible in the `init.d` sysvinit script, I leave
that as an exercise for the reader.

a.

-- 
My passionate sense of social justice and social responsibility has
always contrasted oddly with my pronounced lack of need for direct
contact with other human beings and communities. I am truly a "lone
traveler" and have never belonged to my country, my home, my friends,
or even my immediate family, with my whole heart; in the face of all
these ties, I have never lost a sense of distance and a need for
solitude.
   - Albert Einstein


signature.asc
Description: PGP signature

Bug#995952: undertime: Getting TypeError with any timezone

[Antoine Beaupré]

Control: severity -1 normal

On 2021-10-08 15:24:56, Gabriel Filion wrote:
> Package: undertime
> Version: 2.6.0
> Severity: grave
> Justification: renders package unusable
>
> Hello,
>
> I'm currently getting stack traces consistently when using undertime. No 
> matter
> the timezone that I request, I get a stack trace with a TypeError exception:
>
> $ undertime pt
> Traceback (most recent call last):
>   File "/usr/bin/undertime", line 994, in 
> main(args)
>   File "/usr/bin/undertime", line 733, in main
> timezones += filter(None, [guess_zone(z) for z in args.timezones])
> TypeError: 'NoneType' object is not iterable
>
> $ undertime PST
> WARNING: date provided cannot be parsed: PST
> Traceback (most recent call last):
>   File "/usr/bin/undertime", line 994, in 
> main(args)
>   File "/usr/bin/undertime", line 733, in main
> timezones += filter(None, [guess_zone(z) for z in args.timezones])
> TypeError: 'NoneType' object is not iterable
>
> If I run that last command with pdb,
>
> e.g. python3 -m pdb /usb/bin/undertime PST
>
> and then (r)un the program until the error, I can see that args.timezones is
> set to None:
>
> (Pdb) type(args.timezones)
> 
>
>
> now from there, I tried using "undertime -t PST" and that actually worked. So
> there must be something off with the default value to -t

I should have documented this possibly more clearly in the NEWS.Debian
file, or maybe make a 3.x release, but I changed the semantics of the
commandline arguments quite significantly. The arguments are now a time,
and you need to provide a -t (or add it to your config file) for
undertime to work.

I'll take this bug report as a request to improve the error message
and/or data structure. Really, args.timezones should be an empty list
instead of None here, I think.

A.

-- 
L'homme construit des maisons parce qu'il est vivant, mais il écrit des
livres parce qu'il se sait mortel.
- Daniel Pennac, Comme un roman

Bug#994203: fails to start with silent_jack_error_callback

[Antoine Beaupré]

On 2021-09-13 20:33:03, Sebastian Ramacher wrote:
> Control: reassign -1 jackd2 1.9.17~dfsg-1
> Control: tags -1 moreinfo unreproducible
>
> On 2021-09-13 13:39:43, Antoine Beaupre wrote:
>> Package: jackd
>> Version: 5+nmu1
>> Severity: grave
>
> You got the wrong package. This is the meta package that allows you to
> select between jackd and jackd2
>
>> 
>> I have tried to use jackd in bullseye (because pipewire was giving me
>> problems in ardour) and it seems I can't start it at all:
>> 
>> anarcat@curie:~(main)$ jackd
>> jackd: symbol lookup error: jackd: undefined symbol: 
>> silent_jack_error_callback
>
> This symbol is provided by libjackserver which jackd correctly links and
> depends on (via libjack-jackd2-0). So I suspect that you have some old
> libjackserver in your library search paths that interfers with jackd.
>
> So please provide a verbose error log from ld.so when it tries to
> resolve the symbol.

Interestingly, I cannot reproduce this anymore. It seems this was
specifically related to the SNAFU I ran into while installing pipewire
from bookworm on bullseye.

So I guess this bug can be closed.

a.

-- 
The ultimate test of your knowledge is your capacity to convey it to
another.
- Richard Feynman

Bug#988707: qthid-fcd-controller: triggers lintian autoreject tag 'bogus-mail-host'

[Antoine Beaupré]

On 2021-06-16 15:01:35, Adrian Bunk wrote:
> On Mon, May 24, 2021 at 11:33:50AM -0400, Antoine Beaupré wrote:
>> On 2021-05-18 15:45:52, Andreas Beckmann wrote:
>>...
>> > https://lintian.debian.org/tags/bogus-mail-host
>> >
>> > E Uploaders anar...@koumbit.og
>> 
>> Thanks for catching this. I haven't used that email address in a long
>> time now, and this should definitely be changed, probably to
>> anar...@debian.org.
>
> This email address was never working due to the "og" typo lintian is 
> complaining about.

Right, but i did mean the origin, .org address here. :)

>>...
>> I barely remember uploading it,
>>...
>
> You can't remember something that never happened?  ;-)
> https://tracker.debian.org/pkg/qthid-fcd-controller

Right, i guess i meant i'm not sure why i'm uploader. :)

>> Considering that I'm just the uploader here (?), I'll let the maintainer
>> (in cc) decide.
>
> Just a bystander, but removing you from Uploaders feels like a logical 
> resolution of this bug to me.

Agreed.

-- 
The survival of humans and other species on planet Earth in my view can
only be guaranteed via a timely transition towards a stationary
state, a world economy without growth.
 - Peter Custers

Bug#988707: qthid-fcd-controller: triggers lintian autoreject tag 'bogus-mail-host'

[Antoine Beaupré]

On 2021-05-18 15:45:52, Andreas Beckmann wrote:
> Source: qthid-fcd-controller
> Version: 4.1-5
> Severity: serious
>
> Hi,
>
> src:qthid-fcd-controller triggers the lintian autoreject tag 
> 'bogus-mail-host',
> i.e. if the package would be reuploaded today without changes, it would
> be automatically rejected by ftp-master.
>
> https://lintian.debian.org/tags/bogus-mail-host
>
> E Uploaders anar...@koumbit.og

Thanks for catching this. I haven't used that email address in a long
time now, and this should definitely be changed, probably to
anar...@debian.org.

That said, I'm not sure this package still belongs in Debian at
all... I barely remember uploading it, and I can't quite find the
upstream source anymore. The homepage does still exist, at least, but
points to a different upstream, with different version numbers... and
it's archived too...

Maybe we should just remove this one?

Considering that I'm just the uploader here (?), I'll let the maintainer
(in cc) decide.

a.

-- 
A man is none the less a slave because he is allowed to choose a new
master once in a term of years.
 - Lysander Spooner

Bug#982154: trocla FTBFS: test failure

[Antoine Beaupré]

Control: forward -1 https://github.com/duritong/trocla/issues/63

On 2021-05-04 15:54:02, Antoine Beaupré wrote:
> FWIW, I tried to fix this by updating to latest upstream (0.3.0) and I
> get the exact same test failure in unstable right now.
>
> I contacted upstream about the problem privately.

And now publicly:

https://github.com/duritong/trocla/issues/63

Seems like this is a real upstream compatibility issue with Ruby 2.7.

Upstream recommends skipping the test.

-- 
It will be a great day when our schools get all the money they need
and the air force has to hold a bake sale to buy a bomber.
- Unknown

Bug#982154: trocla FTBFS: test failure

[Antoine Beaupré]

FWIW, I tried to fix this by updating to latest upstream (0.3.0) and I
get the exact same test failure in unstable right now.

I contacted upstream about the problem privately.

A.
-- 
"Faith" means not wanting to know what is true.
 - Friedrich Nietzshe

Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"

[Antoine Beaupré]

Control: severity -1 normal

On 2021-04-28 09:00:46, Lev Lamberov wrote:
> Hi Antoine,
>
> Вт 27 апр 2021 @ 13:53 Antoine Beaupre :
>
>> Package: elpa-esup
>> Version: 0.7.1-3
>> Severity: grave
>> Tags: upstream
>>
>> This package is unusable in Debian 11 bullseye in its current
>> state. In my Emacs 1:27.1+1-3.1 session, i run M-x esup and I get:
>>
>> error in process sentinel: Wrong type argument: (or eieio-object class), 
>> nil, obj
>>
>> *Messages* has this:
>>
>> Loading /usr/share/emacs/site-lisp/elpa/esup-0.7.1/esup-autoloads.el 
>> (source)...done
>> Starting esup...
>> esup process started on port 37851
>> at 1
>> error in process sentinel: slot-value: Wrong type argument: (or eieio-object 
>> class), nil, obj
>> error in process sentinel: Wrong type argument: (or eieio-object class), 
>> nil, obj
>>
>> This is the upstream bug: https://github.com/jschaf/esup/issues/85
>>
>> It looks like it is a packaging issue, since, according to the above
>> bug report, recompiling the .el files fixes the problem (haven't tested).
>
> Thanks for reporting, investigating and forwarding!
>
> Is it a fresh install of elpa-esup?

Yes, installed from the Debian package in Bullseye.

> I have elpa-esup installed for a long time and I cannot reproduce the
> bug on my machine. Running esup starts another GNU Emacs session and
> gives me a proper report on startup like the following excerpt:

Oh interesting! Maybe that's why it works, since the bytecode is older?

> ```
> Total User Startup Time: 0.357sec Total Number of GC Pauses: 3 Total 
> GC Time: 0.065sec
>
> package.elc:16  0.134sec   37%
> (byte-code "\301\302!\210\301\303!\210 [...]
> ```
>
> I wonder how recompiling could fix the problem you face, since
> installing/reinstalling the package or GNU Emacs itself should trigger
> recompilation of it along with all other installed Emacs packages.

Yeah, as I said I haven't tried to recompile myself, that's just what
the upstream bug report says. If anything, maybe it's the opposite and
if *you* recompile you'll trigger the bug? No idea.

[...]

> So, may it be a bug in dh-elpa or GNU Emacs itself?

Maybe! This is way beyond my elisp-fu unfortunately.

One key information I have just discovered is that I can't reproduce
with `emacs -q`. So this is probably an interaction with my .emacs.d
configuration and the package, unfortunately. Downgrading severity.

a.

-- 
While the creative works from the 16th century can still be accessed
and used by others, the data in some software programs from the 1990s
is already inaccessible.
 - Lawrence Lessig

Bug#975227: [PATCH] Replace use of "grep | wc" with grep -c for binary files.

[Antoine Beaupré]

LGTM.

On 2021-04-21 08:20:36, David Bremner wrote:
> The latter actually reports a number of matches on stdout, making the
> tests pass.
> ---
>  tests.d/client-server/02-move-mail | 2 +-
>  tests.d/client-server/03-copy-mail | 2 +-
>  tests.d/client-server/04-replace-header| 2 +-
>  tests.d/client-server/05-replace-header-fail   | 2 +-
>  tests.d/client-server/06-replace-header-already-ok | 2 +-
>  tests.d/client-server/08-copy-mail-already-ok  | 2 +-
>  tests.d/client-server/10-delete-already-done   | 2 +-
>  tests.d/client-server/12-skip-add-already-there| 2 +-
>  tests.d/client-server/14-skip-copy-already-there-copy-only | 2 +-
>  tests.d/client-server/18-copybody  | 2 +-
>  tests.d/client-server/19-copybody-already-ok   | 2 +-
>  tests.d/client-server/22-replace   | 2 +-
>  tests.d/client-server/23-replace-aready-ok | 2 +-
>  tests.d/client-server/34-move-fail2| 2 +-
>  tests.d/client-server/35-delete| 2 +-
>  tests.d/client-server/36-move-fail3| 2 +-
>  16 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/tests.d/client-server/02-move-mail 
> b/tests.d/client-server/02-move-mail
> index e3dbd90..7828b69 100644
> --- a/tests.d/client-server/02-move-mail
> +++ b/tests.d/client-server/02-move-mail
> @@ -9,7 +9,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^MOVE ' log.s2c | wc -l`
> +X=`grep -c '^MOVE ' log.s2c`
>  assert $X 1 "missing MOVE in s2c"
>  
>  X=`grep '^COMMIT$' log.c2s | wc -l`
> diff --git a/tests.d/client-server/03-copy-mail 
> b/tests.d/client-server/03-copy-mail
> index 0037531..ec185a2 100644
> --- a/tests.d/client-server/03-copy-mail
> +++ b/tests.d/client-server/03-copy-mail
> @@ -9,7 +9,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^COPY ' log.s2c | wc -l`
> +X=`grep -c '^COPY ' log.s2c`
>  assert $X 1 "missing COPY in s2c"
>  
>  X=`grep '^GET ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/04-replace-header 
> b/tests.d/client-server/04-replace-header
> index 8af6cbb..1ffcaf1 100644
> --- a/tests.d/client-server/04-replace-header
> +++ b/tests.d/client-server/04-replace-header
> @@ -9,7 +9,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
> +X=`grep -c '^REPLACEHEADER ' log.s2c`
>  assert $X 1 "missing REPLACEHEADER in s2c"
>  
>  X=`grep '^GETHEADER ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/05-replace-header-fail 
> b/tests.d/client-server/05-replace-header-fail
> index 8743c24..9599251 100644
> --- a/tests.d/client-server/05-replace-header-fail
> +++ b/tests.d/client-server/05-replace-header-fail
> @@ -11,7 +11,7 @@ msync 2
>  
>  test_eq target/Mail.old target/Mail 
>  
> -X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
> +X=`grep -c '^REPLACEHEADER ' log.s2c`
>  assert $X 1 "missing REPLACEHEADER in s2c"
>  
>  X=`grep '^GETHEADER ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/06-replace-header-already-ok 
> b/tests.d/client-server/06-replace-header-already-ok
> index 1d29c14..c2c0b2f 100644
> --- a/tests.d/client-server/06-replace-header-already-ok
> +++ b/tests.d/client-server/06-replace-header-already-ok
> @@ -10,7 +10,7 @@ test_eq Mail target/Mail
>  msync 2
>  
>  test_eq Mail target/Mail 
> -X=`grep '^REPLACEHEADER ' log.s2c | wc -l`
> +X=`grep -c '^REPLACEHEADER ' log.s2c`
>  assert $X 1 "missing REPLACEHEADER in s2c"
>  
>  X=`grep '^GETHEADER ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/08-copy-mail-already-ok 
> b/tests.d/client-server/08-copy-mail-already-ok
> index 781a109..0e481e5 100644
> --- a/tests.d/client-server/08-copy-mail-already-ok
> +++ b/tests.d/client-server/08-copy-mail-already-ok
> @@ -10,7 +10,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^COPY ' log.s2c | wc -l`
> +X=`grep -c '^COPY ' log.s2c`
>  assert $X 1 "missing COPY in s2c"
>  
>  X=`grep '^GET ' log.c2s | wc -l`
> diff --git a/tests.d/client-server/10-delete-already-done 
> b/tests.d/client-server/10-delete-already-done
> index 926394d..c15603b 100644
> --- a/tests.d/client-server/10-delete-already-done
> +++ b/tests.d/client-server/10-delete-already-done
> @@ -10,7 +10,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^DELETE ' log.s2c | wc -l`
> +X=`grep -c '^DELETE ' log.s2c`
>  assert $X 1 "missing DELETE in s2c"
>  
>  X=`grep '^COMMIT$' log.c2s | wc -l`
> diff --git a/tests.d/client-server/12-skip-add-already-there 
> b/tests.d/client-server/12-skip-add-already-there
> index 0a53a80..38ed3ff 100644
> --- a/tests.d/client-server/12-skip-add-already-there
> +++ b/tests.d/client-server/12-skip-add-already-there
> @@ -10,7 +10,7 @@ msync 2
>  
>  test_eq Mail target/Mail 
>  
> -X=`grep '^ADD ' log.s2c | wc -l`
> +X=`grep -c '^ADD ' log.s2c`
>  assert $X 1 

Bug#982758: webext-browserpass: Failed to install on upgrade to bullseye

[Antoine Beaupré]

I have had the same, completely crashes the apt run too, neat. :)

dpkg: error processing archive 
/var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb (--unpack):
 unable to open 
'/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/browserp...@maximbaz.com/icon.png.dpkg-new':
 No such file or directory
Reinstalling 
/etc/chromium/native-messaging-hosts/com.dannyvankooten.browserpass.json that 
was moved away
Errors were encountered while processing:
 /var/cache/apt/archives/webext-browserpass_3.7.2-1+b1_amd64.deb

I bumped the severity because it completely fails to upgrade.

Workaround: apt purge webext-browserpass && apt install webext-browserpass

-- 
Twenty years from now you will be more disappointed by the things that
you didn't do than by the ones you did do. So throw off the bowlines.
Sail away from the safe harbor. Catch the trade winds in your sails.
Explore. Dream. Discover.  - Mark Twain

Bug#974616: nomacs: "charset=Ascii" appears before the comment of the image

[Antoine Beaupré]

On 2020-12-14 23:45:06, Vincent Lefevre wrote:
> Control: retitle -1 nomacs uses internal libexiv2 functions to get the user 
> comment
> Control: severity -1 serious
> Control: tags -1 - patch
>
> On 2020-12-12 21:59:38 +0100, Vincent Lefevre wrote:
>> I'm attaching the patch I've written. There was already a function
>> that removes substrings of the form 'charset="ASCII"' case
>> insensitively. So I do the same thing with 'charset=ASCII'
>> (i.e. without the double-quotes) and 'charset=Unicode', which
>> appears when the string has non-ASCII characters.
>> 
>> Note that this function is a hack: it will remove real occurrences
>> of such strings, not just those added by libexiv2. However, there
>> is very little probability that such strings really appear in the
>> comment. And one cannot do much better to fix the issue.
>
> This is just a workaround that seems to work with the current
> libexiv2 version, but according to the upstream libexiv2 maintainer,
> nomacs uses some internal libexiv2 function, which means that an
> update of libexiv2 can break it at any time, potentially introducing
> security issues.
>
> Note that a change of behavior could have already been seen with the
> upgrade of libexiv2-27 to 0.27.3 with the appearance of spurious data
> before the comment.
>
> The correct way to get the comment with the public API is
>
>   std::string comment = Exiv2::CommentValue(value().toString()).comment());
>
> Note: The upstream nomacs version comes with a bundled libexiv2,
> meaning that this may not be an issue to use internal libexiv2
> features. Debian chose to use the shared library, thus it needs
> to replace these internals by calls to the public API.

Is this fixed upstream, in the latest 3.16 release?

I mean I understand that it *still* bundles exiv2 and friends:

https://github.com/nomacs/nomacs/tree/master/3rd-party

... but maybe their usage of the library improved?

There is #974617 for upgrading to 3.16...

a.

-- 
By now the computer has moved out of the den and into the rest of your
life. It will consume all of your spare time, and even your vacation,
if you let it. It will empty your wallet and tie up your thoughts. It
will drive away your family. Your friends will start to think of you
as a bore. And what for?
   - The True Computerist by Tom Pittman

Bug#985737: convertdate: autopkgtest failure

[Antoine Beaupré]

reassign 985737 pymeeus
found 985737 0.3.7-1
fixed 985737 0.4.3+dfsg1-1
thanks

On 2021-03-22 21:29:43, Sebastian Ramacher wrote:
> Source: convertdate
> Version: 2.3.2-1
> Severity: serious
> X-Debbugs-Cc: sramac...@debian.org
>
> The autopkgtests of convertdate fail everywhere:
> | test_jwday (tests.test_utils.TestConvertdate) ... ok
> |
> | ==
> | ERROR: test_equinox_jd (tests.test_persian.testPersian) (y=1000, jd=2086381)
> | --
> | Traceback (most recent call last):
> |   File 
> "/tmp/autopkgtest-lxc.ctbufrn7/downtmp/autopkgtest_tmp/tests/test_persian.py",
>  line 43, in test_equinox_jd
> | self.assertEqual(persian.equinox_jd(gyear), jd)
> |   File "/usr/lib/python3/dist-packages/convertdate/persian.py", line 51, in 
> equinox_jd
> | deltat_jd = mean_jd - Epoch.tt2ut(gyear, 3) / (24 * 60 * 60.)
> |   File "/usr/lib/python3/dist-packages/pymeeus/Epoch.py", line 1403, in 
> tt2ut
> | dt = 1574.2 + u * (
> | UnboundLocalError: local variable 'u' referenced before assignment
>
> See
> https://ci.debian.net/data/autopkgtest/testing/amd64/c/convertdate/11090578/log.gz

Hum. The failure is actually in pymeeus, and, as far as I can tell, the
code in the *unstable* version of pymeeus doesn't have that bug. Here's
`tt2ut` where `dt` is assigned `1574.2 + u`, with context:

elif year >= 500 and year < 1600:
u = (year - 1000) / 100.0
dt = 1574.2 + u * (

So I think this bug is actually fixed already, and CI will pass when
pymeeus migrates.

A.

-- 
Si l'image donne l'illusion de savoir
C'est que l'adage pretend que pour croire,
L'important ne serait que de voir
- Lofofora

Bug#981009: Charybdis abandoned upstream, do not ship in bullseye

[Antoine Beaupré]

On 2021-02-18 02:32:10, Sadie Powell wrote:
> Charybdis' development was terminated due to (among other reasons) threats by 
> a former maintainer. It probably won't be revived.
>
> It's successor is probably Solanum (https://github.com/solanum-ircd/solanum) 
> which is a fork that is led by freenode and OFTC people some of whom were 
> contributors to Charybdis. It might be a good idea to package that instead 
> when it gets a release?

I believe my co-maintainer here is working on this, actually. No WNPP
bug, as far as I know, but as you say, without an upstream release it
might not be worth it just yet.

But yes, it's pretty much the replacement for charybdis, but do note
that it's not a drop-in replacement.

A.

-- 
We will create a civilization of the Mind in Cyberspace. May it be more
humane and fair than the world your governments have made before.
- John Perry Barlow, 1996
A Declaration of Independence of Cyberspace

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

On 2021-01-25 22:20:38, Dr. Tobias Quathamer wrote:
> Am 25.01.21 um 16:35 schrieb Antoine Beaupré:
>> On 2021-01-24 23:53:20, Damon Lynch wrote:
>>> On Sun, Jan 24, 2021 at 8:44 PM Antoine Beaupré  wrote:
>>>
>>>>  Maybe then there is an easy fix to keep RPD in Debian if
>>>> rawkit disappears.
>>>>
>>>>
>>> There is no need for any kind of fix in the code itself. Just remove the
>>> mention of rawkit from the Rapid Photo Downloader Debian package. Rapid
>>> Photo Downloader will run without rawkit, without any changes to its code.
>>> If rawkit is present and working, Rapid Photo Downloader will use it. If
>>> rawkit is either not working or not present, Rapid Photo Downloader won't
>>> use it.
>> 
>> This still requires a fix to the Debian package "code" in that the
>> dependency needs to be changed.
>> 
>> Thanks for the clarification!
>
> Hi Antoine and Damon,
>
> I've just taken the time to update RPD to its latest upstream release.
> Also, the dependency on libraw is now downgraded to a recommendation. I
> think that the Debian package of RPD should now be in a good condition
> for the next stable release.
>
> Thanks to both of you for sorting this out and making me aware of the
> situation!

Good job, Tobias, thanks!

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

On 2021-01-24 23:53:20, Damon Lynch wrote:
> On Sun, Jan 24, 2021 at 8:44 PM Antoine Beaupré  wrote:
>
>>  Maybe then there is an easy fix to keep RPD in Debian if
>> rawkit disappears.
>>
>>
> There is no need for any kind of fix in the code itself. Just remove the
> mention of rawkit from the Rapid Photo Downloader Debian package. Rapid
> Photo Downloader will run without rawkit, without any changes to its code.
> If rawkit is present and working, Rapid Photo Downloader will use it. If
> rawkit is either not working or not present, Rapid Photo Downloader won't
> use it.

This still requires a fix to the Debian package "code" in that the
dependency needs to be changed.

Thanks for the clarification!

a.

-- 
A developed country is not a place where the poor have cars. It's
where the rich use public transportation.
- Gustavo Petro 

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

On 2021-01-24 20:18:27, Damon Lynch wrote:
>> Otherwise I'm afraid we won't be able to ship
>> RPD with Debian starting with bullseye, which would really be a shame...
>
> I am the developer of Rapid Photo Downloader. I am not impressed by this
> suggestion. Rapid Photo Downloader has an optional, soft dependency on
> rawkit. Rapid Photo Downloader will install and run perfectly well without
> rawkit, which has been the case for some years now.
>
> If you have any packaging questions about Rapid Photo Downloader you can
> ask me, instead of
> simply removing the package from Debian. To be as polite as possible, I am
> somewhat taken aback by a suggestion to remove it without any communication
> with me.

I was merely stating the current situation, which is that there is
currently a hard dependency between RPD and rawkit right now, and rawkit
will be removed. This means that RPD, without change, will also be
removed.

I was not suggesting that RPD *must* be removed from Debian. I use it
regularly, and I would hate to see it go...

> FWIW, the latest version of Rapid Photo Downloader  is 0.9.26. The Debian
> package is somewhat out of date these days.

... and in fact, I would love if the package was more up to date to. :)
But this is the hand we're given right now.

I'm glad to hear that the rawkit dependency is not as "hard" as I first
understood it. Maybe then there is an easy fix to keep RPD in Debian if
rawkit disappears.

But I figured I would share my concerns rather than stay silent, because
otherwise this would have all happened automatically and you probably
would have noticed too late.

I'm sorry if it sounded a bit cavalier, I wasn't expecting you to read
this thread directly, and I did suggest the maintainer contact you
directly as well.

I unfortunately do not have time to deal with this problem myself (other
than raising this red flag) so I hope that others will be able to.

A.
-- 
>From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
- Winston Smith, 1984

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

On 2021-01-24 14:59:03, Antoine Beaupré wrote:
> Hi,
>
> It seems like rapid-photo-downloader will not make it into the next
> Debian stable release (bullseye). It depends on "rawkit" (which I happen
> to maintain for some reason), and *that* package fails with newer libraw
> versions:
>
> https://bugs.debian.org/978079
>
> I'm not sure how to fix this, and I don't have the cycles to do so right
> now. But since you're the RPD maintainer, I figured you might have extra
> motivation to fix this... Otherwise I'm afraid we won't be able to ship
> RPD with Debian starting with bullseye, which would really be a shame...
>
> It might be worth bringing this up with upstream as well, if you can
> find the time...

Actually, I just found out that there's an active fork which fixes those
problems, called rawpy:

https://discuss.pixls.us/t/rawkit-unmaintained-path-forward-for-rapid-photo-downloader/14299

There's a patch in Arch to port rawkit to libraw19, but I feel it would
be ill-advised to carry such a hack through a stable Debian release.

So I think the way forward for RPD is to package rawpy, remove rawkit,
and have RPD depend on rawpy. I don't have time to do this work myself
and, since RPD is the only thing that needs rawkit in Debian, I would
suggest you take on the dependency as well.

Unfortunately, this would need to happen in the coming week, otherwise
we'll miss the NEW window before the soft freeze (2021-02-12). Do you
have time to deal with this until then?

Thanks,

a.

-- 
The flesh you so fancifully fry
Is not succulent, tasty or kind
It's death for no reason
And death for no reason is murder
- Morrissey

Bug#978079: heads up: rapid-photo-downloader might not make it to bullseye

[Antoine Beaupré]

Hi,

It seems like rapid-photo-downloader will not make it into the next
Debian stable release (bullseye). It depends on "rawkit" (which I happen
to maintain for some reason), and *that* package fails with newer libraw
versions:

https://bugs.debian.org/978079

I'm not sure how to fix this, and I don't have the cycles to do so right
now. But since you're the RPD maintainer, I figured you might have extra
motivation to fix this... Otherwise I'm afraid we won't be able to ship
RPD with Debian starting with bullseye, which would really be a shame...

It might be worth bringing this up with upstream as well, if you can
find the time...

a.
-- 
Advertisers, not governments, are the primary censors of media content 
in the United States today.
- C. Edwin Baker

Bug#978079: python3-rawkit: Support for libraw20 missing

[Antoine Beaupré]

Control: forward -1 https://github.com/photoshell/rawkit/issues/155
Control: tags -1 +confirmed

On 2020-12-25 16:58:42, Kendy Kutzner wrote:
> sudo aptitude install libraw20 python3-rawkit
> python3
 from rawkit.raw import Raw
 r=Raw(filename='1608680820.cr2')
> [...]
> ImportError: Unsupported Libraw version: 0.20.2.
>
> I'm using bullseye/sid.

Unfortunately, not only does it look like an upstream issue with no fix,
but worse, it seems like upstream is dead. Or at least, the git
repository is "archived":

https://github.com/photoshell/rawkit/

... not sure what to make of this :(

a.

-- 
By now the computer has moved out of the den and into the rest of your
life. It will consume all of your spare time, and even your vacation,
if you let it. It will empty your wallet and tie up your thoughts. It
will drive away your family. Your friends will start to think of you
as a bore. And what for?
   - The True Computerist by Tom Pittman

Bug#954079: magic-wormhole: Fails to send with a type error

[Antoine Beaupré]

reassign 954079 automat
affects 954079 magic-wormhole
forward 954079 https://github.com/glyph/automat/issues/118
thanks

On 2020-03-16 13:49:58, Guillem Jover wrote:
> Package: magic-wormhole
> Version: 0.11.2-1
> Severity: serious
>
> Hi!
>
> This package does not work anymore in unstable. I guess due to the new
> python-3.8 transition? Had to use a buster schroot to be able to send
> some stuff today. :)
>
>   ,---
>   $ wormhole send somedir/
>   Traceback (most recent call last):
> File "/usr/lib/python3/dist-packages/wormhole/cli/cli.py", line 255, in 
> 
>   return react(_dispatch_command, (cfg, lambda: f(cfg)))
> File "/usr/lib/python3/dist-packages/wormhole/cli/cmd_send.py", line 36, 
> in send
>   return Sender(args, reactor).go()
> File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 
> 1613, in unwindGenerator
>   return _cancellableInlineCallbacks(gen)
> File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 
> 1529, in _cancellableInlineCallbacks
>   _inlineCallbacks(None, g, status)
>   ---  ---
> File "/usr/lib/python3/dist-packages/wormhole/cli/cli.py", line 122, in 
> _dispatch_command
>   yield maybeDeferred(command)
> File "/usr/lib/python3/dist-packages/twisted/internet/defer.py", line 
> 1418, in _inlineCallbacks
>   result = g.send(result)
> File "/usr/lib/python3/dist-packages/wormhole/cli/cmd_send.py", line 64, 
> in go
>   w = create(
> File "/usr/lib/python3/dist-packages/wormhole/wormhole.py", line 271, in 
> create
>   b = Boss(w, side, relay_url, appid, wormhole_versions, client_version,
> File "", line 21, in __init__
>   self.__attrs_post_init__()
> File "/usr/lib/python3/dist-packages/wormhole/_boss.py", line 49, in 
> __attrs_post_init__
>   self._build_workers()
> File "/usr/lib/python3/dist-packages/wormhole/_boss.py", line 59, in 
> _build_workers
>   self._RC = RendezvousConnector(self._url, self._appid, self._side,
> File "", 
> line 18, in __init__
>   self.__attrs_post_init__()
> File "/usr/lib/python3/dist-packages/wormhole/_rendezvous.py", line 88, 
> in __attrs_post_init__
>   d = self._connector.whenConnected(failAfterFailures=faf)
> File "/usr/lib/python3/dist-packages/twisted/application/internet.py", 
> line 1121, in whenConnected
>   return self._machine.whenConnected(failAfterFailures)
> File "/usr/lib/python3/dist-packages/automat/_methodical.py", line 126, 
> in __get__
>   def doInput(*args, **kwargs):
> File "/usr/lib/python3/dist-packages/automat/_introspection.py", line 39, 
> in decorator
>   return copyfunction(decorated,
> File "/usr/lib/python3/dist-packages/automat/_introspection.py", line 31, 
> in copyfunction
>   return function(copycode(template.__code__, codechanges), *values)
> File "/usr/lib/python3/dist-packages/automat/_introspection.py", line 19, 
> in copycode
>   return code(*values)
>   builtins.TypeError: an integer is required (got type bytes)
>   ERROR: an integer is required (got type bytes)
>   `---

This is actually a bug in automat, not magic-wormhole, see:

https://github.com/warner/magic-wormhole/issues/377

I've reassigned this bug accordingly. It seems that upgrading the
automat package would fix this.

A.

-- 
La mer, cette grande unificatrice, est l'unique espoir de l'homme.
Aujourd'hui plus que jamais auparavant, ce vieux dicton dit
littéralement ceci: nous sommes tous dans le même bateau.
- Jacques Yves Cousteau - Océanographe

Bug#885282: gameclock: Depends on unmaintained pygtk

[Antoine Beaupré]

On 2020-03-27 22:44:31, Moritz Mühlenhoff wrote:
> On Sat, Jan 06, 2018 at 01:01:28PM -0500, Antoine Beaupré wrote:
>> Control: forwarded -1 https://gitlab.com/anarcat/gameclock/issues/1
>> 
>> Understood.
>
> Hi Antoine,
> let's remove gameclock from the archive for now? When ported it
> can still be reintroduced, but currently it's among the last
> handful of packages blocking the pygtk removal.

Yes, please proceed, thanks.

a.

-- 
For every complex problem, there is an answer that is clear, simple -
and wrong.
- H.L. Mencken

Bug#937066: monkeysign: Python2 removal in sid/bullseye

[Antoine Beaupré]

On 2020-03-20 23:41:59, Moritz Mühlenhoff wrote:
> On Sat, Nov 09, 2019 at 06:11:46PM -0500, Antoine Beaupré wrote:
>> There was a 3 year old "python 3" branch sitting around in the repo that
>> I revived by merging in the latest code.
>> 
>> Tests still fail (the test suite hangs on py2 and fails on py3), but at
>> least there's some work done. A large part of the porting was already
>> done by converting `print` statements to the `logging` library (thanks
>> to simonft).
>> 
>> Help on this front would be greatly appreciated. I was already
>> considering abandoning monkeysign before I realized I had to port it to
>> Python 3, so it is likely this software will simply die if no one steps
>> up to help.
>
> Hi,
> Has there been further development? Otherwise I'd suggest to remove monkeysign
> for now, it's blocking the removal of pygtk (and in turn a few other 
> libraries)
> and it can still be re-introduced by bullseye release if it gets ported.

i'm sorry to say there has been no progress and must now admit this is
the only short term solution.

a.

-- 
It will be a great day when our schools get all the money they need
and the air force has to hold a bake sale to buy a bomber.
- Unknown

Bug#954147: src:dateparser: Requires a package outside of Main

[Antoine Beaupré]

On 2020-03-17 09:14:03, Scott Kitterman wrote:
> Package: src:dateparser
> Version: 0.7.2-1
> Severity: serious
> Justification: Policy 2.2.1
>
> This package uses python pip to download and install packages from outside the
> Debian archive to run autopkgtests.  Main is required to be self-contained,
> including for tests.  See the FTP Master's reject FAQ [1] item Non-Main II.
>
> An excerpt from a recent autpkgtest log is included below to demonstrate the
> issue with this package.

I believe this is only a problem because autopkgtest isn't configured to
install the build-deps of the package, not that it requires packages
outside of main per se.

I would be happy to take a patch or NMU to do this, but i'm a bit busy
to take care of this myself right now.

Bug#936249: bugs-everywhere: Python2 removal in sid/bullseye

[Antoine Beaupré]

On 2019-12-26 02:05:56, maxigas wrote:
> On Wed, Dec 25 2019, Moritz Mühlenhoff wrote:
>
>> On Fri, Aug 30, 2019 at 07:12:24AM +, Matthias Klose wrote:
>>> Package: src:bugs-everywhere
>>> Version: 1.1.1-4
>>> Severity: normal
>>> Tags: sid bullseye
>>> User: debian-pyt...@lists.debian.org
>>> Usertags: py2removal
>>> 
>>> Python2 becomes end-of-live upstream, and Debian aims to remove
>>> Python2 from the distribution, as discussed in
>>> https://lists.debian.org/debian-python/2019/07/msg00080.html
>>
>> bugs-everywhere is dead upstream, the last commits are from 2013.
>>
>> Are you planning to port it to Python 3 yourself? Otherwise I'll
>> request it's removal from the archive.
>
> Hm, i'm sorry but i don't think i will have the time to port it.

Same here, and there are alternatives. Just a quick list covering still
active projects:

https://distix.eu/
https://github.com/MichaelMure/git-bug
https://github.com/neithernut/git-dit
https://sit.fyi/

maybe something for the release notes i guess...

a.
-- 
Information is not knowledge. Knowledge is not wisdom.
Wisdom is not truth. Truth is not beauty.
Beauty is not love. Love is not music.
Music is the best.  - Frank Zappa

Bug#946055: /etc/etckeeper/commit.d/50vcs-commit[22]: ${@#-m}: bad substitution

[Antoine Beaupré]

On 2019-12-18 22:59:54, Thorsten Glaser wrote:
>> I encourage you to engage with joeyh anyways, if you can. ;)
>
> We engaged in real life during our trip to DebConf in Bosnia,
> which was enjoyable (if a lengthy road trip), I can relate ;)
> I just had trouble with the website (it’s not my medium anyway).

They might welcome patches by email...

-- 
Hard times are coming when we will be wanting the voices of writers
who can see alternatives to how we live now and can see through our
fear-stricken society and its obsessive technologies to other ways of
being, and even imagine some real grounds for hope. We will need
writers who can remember freedom. Poets, visionaries—the realists of a
larger reality. - Ursula Le Guin

Bug#946055: /etc/etckeeper/commit.d/50vcs-commit[22]: ${@#-m}: bad substitution

[Antoine Beaupré]

On 2019-12-18 20:42:11, Thorsten Glaser wrote:
>> https://etckeeper.branchable.com/todo/
>
> This seems to be a static page? I don’t find out how to do that.

It's not a static page: there's a field at the top of the page where you
can input a page name and then you get served a login form and so on.

But nevermind that, I filed it:

https://etckeeper.branchable.com/todo/vcs-commit_hook_is_not_POSIX-friendly/

I encourage you to engage with joeyh anyways, if you can. ;)

a.

-- 
Dr. King’s major assumption was that if you are nonviolent, if you
suffer, your opponent will see your suffering and will be moved to
change his heart. He only made one fallacious assumption: In order for
nonviolence to work, your opponent must have a conscience. The United
States has none.- Stokely Carmichael

Bug#946055: /etc/etckeeper/commit.d/50vcs-commit[22]: ${@#-m}: bad substitution

[Antoine Beaupré]

Control: forward -1 
https://etckeeper.branchable.com/todo/vcs-commit_hook_is_not_POSIX-friendly/

On 2019-12-18 20:32:41, Thorsten Glaser wrote:
> On Wed, 18 Dec 2019, Thorsten Glaser wrote:
>
>> The patch fixes the issue by reimplementing the -mmessage feature
>> introduced in 1.18.11 in portable shell *and* fixing issues with
>> messages starting with -n or -c or containing backslashes as well.
>
> I can confirm that a package built with this patch fixes the issue.
>
> The debugging sponsored by ⮡ tarent, see below.
>
> I’ve not been able to figure out how to submit *either* patches
> *or* bugreports upstream. Please do so (DevRef §5.8.3(6)).

Ack. Forwarded.

a.

-- 
The value of a college education is not the learning of many facts but
the training of the mind to think.
   - Albert Einstein

Bug#946055: /etc/etckeeper/commit.d/50vcs-commit[22]: ${@#-m}: bad substitution

[Antoine Beaupré]

On 2019-12-18 20:16:50, Thorsten Glaser wrote:
> Package: etckeeper
> Version: 1.18.12-1
> Followup-For: Bug #946055
>
> Find a patch attached. I intend to NMU if this isn’t fixed RSN.

This package, like all of mine, is LowNMU so upload whenever you feel
ready.

> The patch fixes the issue by reimplementing the -mmessage feature
> introduced in 1.18.11 in portable shell *and* fixing issues with
> messages starting with -n or -c or containing backslashes as well.

Thanks for the patch! I do have a comment though...

> diff -Nru etckeeper-1.18.12/debian/patches/fix-sh-syntax.diff 
> etckeeper-1.18.12/debian/patches/fix-sh-syntax.diff
> --- etckeeper-1.18.12/debian/patches/fix-sh-syntax.diff   1970-01-01 
> 01:00:00.0 +0100
> +++ etckeeper-1.18.12/debian/patches/fix-sh-syntax.diff   2019-12-18 
> 20:11:17.0 +0100
> @@ -0,0 +1,19 @@
> +# DP: fix #946055 by reimplementing in portable shell
> +# DP: also fixes issues with echo -n, -c, and backslashes
> +
> +--- a/commit.d/50vcs-commit
>  b/commit.d/50vcs-commit
> +@@ -12,10 +12,9 @@ if [ -n "$1" ]; then
> + if [ "x$1" = "x--stdin" ]; then
> + cat > "$logfile"
> + else
> +-if [ "x$1" = "x-m" ]; then
> +-shift 1
> +-fi
> +-echo "${@#-m}" > "$logfile"
> ++sed '1s/^-m \{0,1\}//' >"$logfile" <<-EOF
> ++$*
> ++EOF

... isn't there a simpler way than piping this through sed?

does that regex really do the same as ${@#-m}? it seems there's some
whitespace and anchoring stuff going on here that would subtly change
behavior...

I also encourage you to submit your patch upstream in:

https://etckeeper.branchable.com/

specifically here:

https://etckeeper.branchable.com/todo/

Let me know if you want me to carry that for you.

Thanks again!

a.

-- 
If quantum mechanics hasn't profoundly shocked you, you haven't
understood it yet.
   - Niels Bohr

Bug#946484: internetarchive: DistributionNotFound: The 'backports.csv' distribution was not found

[Antoine Beaupré]

On 2019-12-09 22:51:16, Jakub Wilk wrote:
> Package: internetarchive
> Version: 1.8.5-1
> Severity: grave
>
> The ia command doesn't work at all:
>
>$ ia help
>Traceback (most recent call last):
>  File "/usr/bin/ia", line 6, in 
>from pkg_resources import load_entry_point
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3250, in 
>@_call_aside
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3234, in _call_aside
>f(*args, **kwargs)
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 3263, in _initialize_master_working_set
>working_set = WorkingSet._build_master()
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 583, in _build_master
>ws.require(__requires__)
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 900, in require
>needed = self.resolve(parse_requirements(requirements))
>  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 
> 786, in resolve
>raise DistributionNotFound(req, requirers)
>pkg_resources.DistributionNotFound: The 'backports.csv' distribution was 
> not found and is required by internetarchive

This is strange. The requirements seem to be wrong:

'backports.csv < 1.07;python_version<"2.7"',
'backports.csv < 1.07;python_version<"3.4"',
'backports.csv;python_version>="2.7"',
'backports.csv;python_version>="3.4"',

the latter two lines say we need the backport in python 3.4 and above,
which is non-sensical: we *don't* need the backport then...

I'll see what i can do.

a.

-- 
It will be a great day when our schools get all the money they need
and the air force has to hold a bake sale to buy a bomber.
- Unknown

Bug#942901: [Pkg-privacy-maintainers] Bug#942901: torbrowser-launcher: Tor Browser 9.0 shows only black screens due to no write access to /dev/shm/org.mozilla.ipc.*.*

[Antoine Beaupré]

On 2019-10-23 09:41:51, Paul Wise wrote:
> Package: torbrowser-launcher
> Version: 0.3.2-2
> Severity: serious
>
> Tor Browser 9.0 shows only black screens because the default apparmor
> profile does not allow write access to /dev/shm/org.mozilla.ipc.*.*
> like it does for /dev/shm/org.chromium.* and I was able to fix this
> issue by adding this workaround:
>
> ==> /etc/apparmor.d/local/torbrowser.Browser.firefox <==
> owner /{dev,run}/shm/org.mozilla.*.* rw,

I also had to add:

owner @{torbrowser_home_dir}/updater ix,

and restart apparmor:

service apparmor restart

anyone working on uploading a fix for this?
-- 
No animal has more liberty than the cat; but it buries the mess it
makes. The cat is the best anarchist. Until they learn that from the cat
I cannot respect them.
- For whom the bell tolls, Ernest Hemingway

Bug#937066: monkeysign: Python2 removal in sid/bullseye

[Antoine Beaupré]

There was a 3 year old "python 3" branch sitting around in the repo that
I revived by merging in the latest code.

Tests still fail (the test suite hangs on py2 and fails on py3), but at
least there's some work done. A large part of the porting was already
done by converting `print` statements to the `logging` library (thanks
to simonft).

Help on this front would be greatly appreciated. I was already
considering abandoning monkeysign before I realized I had to port it to
Python 3, so it is likely this software will simply die if no one steps
up to help.

A.
-- 
L'ennui avec la grande famille humaine, c'est que tout le monde veut
en être le père.
- Mafalda

Bug#885517: Bug#935335: Depends on removed python-zbar

[Antoine Beaupré]

On 2019-08-21 23:49:06, Andrey Rahmatullin wrote:
> Package: src:monkeysign
> Version: 2.2.4
> Severity: serious
>
> As Python 2 versions of zbar and zbarpygtk were removed, this package should 
> be
> updated to use Python 3 or removed.

Monkeysign will not be ported to zbar or pygtk3. There is already
another alternative (GNOME keysign) which does what monkeyscan does, and
better.

I will probably replace all of monkeyscan's code with this simple shell
command:

zenity --error --text="Monkeyscan has been removed from Monkeysign. Use 
GNOME keysign instead." --width 400

But I will focus on porting to Python 3 first..

a.
-- 
Dr. King’s major assumption was that if you are nonviolent, if you
suffer, your opponent will see your suffering and will be moved to
change his heart. He only made one fallacious assumption: In order for
nonviolence to work, your opponent must have a conscience. The United
States has none.- Stokely Carmichael

Bug#943867: stressant: non-buildd binaries

[Antoine Beaupré]

On 2019-11-09 08:05:32, peter green wrote:
> tags 943867 +patch
> thanks
>
> Since there was no maintainer response to this bug report, I decided to go 
> ahead and prepare a NMU. While testing for said NMU I found that the 
> package's clean target did not clean up properly. So I fixed it.

thanks, feel free to upload sooner.

merged in git.

a.
-- 
La destruction de la société totalitaire marchande n'est pas une affaire
d'opinion. Elle est une nécessité absolue dans un monde que l'on sait
condamné. Puisque le pouvoir est partout, c'est partout et tout le temps
qu'il faut le combattre. - Jean-François Brient, de la servitude moderne

Bug#942114: ganeti-instance-debootstrap: diff for NMU version 0.16-6.1

[Antoine Beaupré]

On 2019-11-02 07:01:43, Mike Gabriel wrote:
> Hi Antoine,
>
> On  Sa 02 Nov 2019 00:10:38 CET, anarcat wrote:
>
>> Control: tags 942114 + pending
>>
>> Dear maintainer,
>>
>> I've prepared an NMU for ganeti-instance-debootstrap (versioned as  
>> 0.16-6.1) and
>> uploaded it to DELAYED/02. Please feel free to tell me if I
>> should delay it longer.
>>
>> Regards.
>
> Would it in fact be an option, to join the Ganeti team and do a team upload?
>
> Otherwise, I'd say the NMU is ok for now, I will update the packaging  
> Git the coming week with that NMU.
>
> Thanks for helping out on Ganeti in Debian!

I'd be happy to join the team as I'll be using Ganeti quite a bit in the
coming months/years/who knows, but I suspect it might already be too
late for a team upload...

a.

-- 
Anarchy is not perfection, it is not the absolute ideal which like the
horizon recedes as fast as we approach it; but it is the way open to
all progress and all improvements for the benefit of everybody.
- Errico Malatesta

Bug#942114: cache fails to store capabilities correctly

[Antoine Beaupré]

On 2019-10-10 11:17:24, Antoine Beaupré wrote:
> Control: tags -1 +patch
>
> Here's a patch to fix this, also available in:
>
> https://salsa.debian.org/ganeti-team/ganeti-instance-debootstrap/merge_requests/1

I'm thinking of doing a NMU of this patch to unstable within the next
month if no one else comments here.

From there, if/when the package trickles down to testing, I'll ask the
release team to get the update down into stable as well.

A.

-- 
La nature n'a créé ni maîtres ni esclaves
Je ne veux ni donner ni recevoir de lois.
- Denis Diderot


signature.asc
Description: PGP signature

Bug#942114: cache fails to store capabilities correctly

[Antoine Beaupré]

Control: tags -1 +patch

Here's a patch to fix this, also available in:

https://salsa.debian.org/ganeti-team/ganeti-instance-debootstrap/merge_requests/1

-- 
You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.
- Theo de Raadt
>From cd34bcc48a2af92f484535b81fba2d46dad1dbb6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Thu, 10 Oct 2019 11:07:51 -0400
Subject: [PATCH] respect Linux capabilities(7) in cache

The default GNU tar configuration does not carry fancy extended
attributes and that is where, among other things, stuff like Linux
capabilities(7) are stored. This is kind of important because that's
how ping(8) works for regular users.

We shove --selinux and --acls in there while we're at it, because why
not. We never know what the future might bring, and it seems
silly *not* to create a complete archive.

Note that --xattrs-include='*' is important because, by default, GNU
tar will not include capabilities /even/ if --xattrs is specified on
the commandline, see this bug report for details:

https://bugzilla.redhat.com/show_bug.cgi?id=771927
---
 create | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/create b/create
index 607bab2..7526e71 100755
--- a/create
+++ b/create
@@ -83,7 +83,7 @@ if [ "$CLEAN_CACHE" -a -d "$CACHE_DIR" ]; then
 fi
 
 if [ -f "$CACHE_FILE" ]; then
-  tar xf "$CACHE_FILE" -C $TMPDIR
+  tar --acls --selinux --xattrs --xattrs-include='*' -x -f "$CACHE_FILE" -C $TMPDIR
 else
   if [ "$PROXY" ]; then
 export http_proxy="$PROXY"
@@ -109,7 +109,7 @@ else
 
   if [ "$GENERATE_CACHE" = "yes" ]; then
 TMP_CACHE=`mktemp "${CACHE_FILE}.XX"`
-tar cf "$TMP_CACHE" -C $TMPDIR .
+tar --acls --selinux --xattrs --xattrs-include='*' -c -f "$TMP_CACHE" -C $TMPDIR .
 mv -f "$TMP_CACHE" "$CACHE_FILE"
   fi
 fi
-- 
2.20.1

Bug#849308: state of wireguard mainline inclusion?

[Antoine Beaupré]

On 2019-09-08 16:28:52, Daniel Kahn Gillmor wrote:
> Version: 0.0.20190905-1
>
> Over in 849...@bugs.debian.org, Daniel Kahn Gillmor wrote:
>> I do plan for putting wireguard into buster-backports, since i expect
>> the upstream inclusion issues to be resolved one way or another by the
>> time of bullseye release.  If anyone wants to help out by adding it to
>> stretch-backports-sloppy, i would welcome that.
>
> Following up on this, and after some discussion with Jason (upstream), i
> think it's time to let wireguard migrate into debian testing.
>
> So i'm closing #849308 with this e-mail, and once wireguard migrates
> into testing, i'll look into putting it into buster-backports.
>
> I welcome anyone who wants to contribute to the debian packaging to
> offer maintenance help too!

Awesome news, thanks everyone!

A.

PS: does that mean anything regarding WG's inclusion into mainline? I
haven't followed LKML recently so I don't know if that closer to
realization... Or is this just a (vague, non-binding) promise that the
protocol won't change as much anymore?

-- 
À force de ne jamais réfléchir, on a un bonheur stupide
- Jean Cocteau

Bug#928990: marked as pending in dmarc-cat

[Antoine Beaupré]

Control: tag -1 pending

Hello,

Bug #928990 in dmarc-cat reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/go-team/packages/dmarc-cat/commit/63003873c96e06c7bcff6e47c083ea393c6c8f54


move test suite to autopkgtest because of network access (Closes: #928990)


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/928990

Bug#928990: dmarc-cat: attempts internet communication during build

[Antoine Beaupré]

Control: tags -1 +confirmed

On 2019-05-14 20:47:26, Gianfranco Costamagna wrote:
> Hello, as said, the package attempts to do internet communication
> during build... this is forbidden by policy.

Agreed.

I don't know how to handle this in the package build... Maybe I should
just disable the test suite?

Is there a knob (like an environment variable) that I can use to disable
the test suite selectively when building under the buildds?

In another package I maintain (monkeysign), I added an environment
variable that disables network tests in debian/rules, but that turns off
all network tests in the debian package build. Is this the same as what
I should do here?

Are autokgtests allowed to do network requests? Maybe I should just move
the test suite there?

Any help would be greatly welcome.

A.

-- 
Qui vit sans folie n'est pas si sage qu'il croit.
- François de La Rochefoucauld

Bug#928509: Firefox insecure because of missing extensions

[Antoine Beaupré]

Control: severity 928509 normal

On 2019-05-06 15:04:09, Karsten wrote:
> Package: firefox-esr
> Version: 60.6.1esr-1~deb8u1
> Justification: user security hole
> Severity: grave
> Tags: security
>
> Hello Debian-Team,
>
> this security bug shall show that Firefox is going to be more and more 
> unusable to be secure in the internet.
>
> Today one of the most vulnerable things has happen, because all the 
> addons/extensions has gone,
> and there is no No-Script and Ublock or other Tracking-Protection any more.
> It is not possible to reinstall them!
>
> There are several articles about this out there like
> * 
> https://www.tenforums.com/browsers-email/131965-firefox-has-deleted-all-extensions-wont-reload-them.html
> * 
> https://discourse.mozilla.org/t/fixed-certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047/12
>
> When there is no fix for the used Firefox-Version, then a new browser 
> solution is needed for Debian.

I am not sure I understand the problem you're trying to outline here.

The package you filed this bug against (Firefox) does not ship with
uMatrix or uBlock or Noscript. It's true that those extensions, when
installed from the Mozilla add-ons site, got disabled due to the bug
described in #928415, but not the actual extensions (including uBlock)
shipped from Debian packages.

I would therefore argue that this effect is not necessarily a security
hole in itself and affects only "third-party" code not shipped in
Debian.

I'm therefore lowering the severity of this bug report, as it actually
keeps the *fixed* version of Firefox from migrating into Buster, making
this problem actually worse than it should be.

I would otherwise be curious to hear more about which problem you
specifically think 60.6.1 (the fixed version) actually still has that
needs to be address and, ideally, how that should be addressed.

Thank you for the bug report!

a.
-- 
La démocratie réelle se définit d'abord et avant tout par la
participation massive des citoyens à la gestion des affaires de la cité.
Elle est directe et participative. Elle trouve son expression la plus
authentique dans l'assemblée populaire et le dialogue permanent sur
l'organisation de la vie en commun.  - De la servitude moderne

Bug#926042: [Pkg-privacy-maintainers] Bug#926042: torbrowser-launcher should not be included in Buster

[Antoine Beaupré]

On 2019-05-03 17:15:59, intrigeri wrote:
> Hi,
>
> (slightly reordering quoted text)
>
> Antoine Beaupre:
>> So what will be the way forward for Debian users in buster?
>
>> TL;DR: TBL in backports or install by hand from TPO, AFAIK.
>
> Agreed.
>
>> What does Tails do with this?
>
> Tails only uses the torbrowser-launcher source package as a way to get
> its AppArmor profiles… that we then patch heavily to make them
> suitable for the weird way we install Tor Browser in Tails images.
>
>> So I see a few long-term solutions to the "how to install TBB in Debian"
>> problem in Buster:
>
>>  1. maintain through backports (seems to have been the option taken for
>> stretch)
>
> That might be viable if the AppArmor profiles are disabled by default.

Why would we disable apparmor profiles?

>>  2. drop TBL and rewrite it as a one-shot installer, like we had for
>> Flash, mstt-corefonts and still have (I suspect?) for other packages
>
> I'm curious: how would that installer differ from TBL in practice?
>
> It seems to me that current TBL is essentially a one-shot installer +
> a .desktop file + some AppArmor profiles.

I think TBL checks for updates at every start. Such a one-shot installer
would deploy TBB and get out of the way after.

>>  4. drop TBL and shipp TBB directly in Debian
>
>> Option 4, therefore, would require more ambitious packaging work. Maybe
>> we could talk with upstream to see if that would be possible? There are
>> Debian packages for Firefox, after all - how hard could it possibly be
>> to do the same for TBB? ;)
>
> This has been discussed numerous times in the past. I don't recall the
> details but what I remember is: it requires lots of hard work.
> Personally, I don't think it's worth the effort. There's a ticket on
> Tor's Trac about it, that might even have the relevant info.

"There's a ticket on Tor's Trac about it" is one of those statements
that sounds like "I have heard there is a green mouse crawling the
sewers of a small town in rural Kazhakstan with the encryption key to
the Russian nuclear arsenal".

In other words, do you have a ticket number because I have, like many
others, lost all hope of finding anything in Trac that I don't already
know where it is. ;)

>> Anyways, I would be glad to hear what the options are here and if this
>> inventory is complete!
>
> Here's one more option:
>
> 5. Ensure Tor Browser can be installed in GNOME Software
>as a Flatpak or Snap
>
>This would cover the initial installation via usual means for
>non-technical users (GNOME Software). It provides sandboxing at
>least as good as AppArmor's, without the UX cost.

That would be something I'd be happy to try, but it doesn't seem that
either is available now:

https://snapcraft.io/search?q=tor
https://flathub.org/apps/search/tor

(Observe, while you're there, how there are three possible "tor"
packages listed there, none of which are tor browser, and it's unclear
which one would be officially anything at all.)

Is there a ticket for "package TBB for flatpak or snap" on Trac as well?
;)

Thanks for your reply!

A.

-- 
I would defend the liberty of consenting adult creationists to practice
whatever intellectual perversions they like in the privacy of their own
homes; but it is also necessary to protect the young and innocent.
- Arthur C. Clarke

Bug#788721: firefox-esr: Some sources are misssing

[Antoine Beaupré]

Hi all,

We had the privilege to hold the Toronto BSP in the Mozilla offices
here, and our host (in CC) was kind enough to take a quick look at this
issue with the Firefox package. He told me to CC him so that he could
look into the issue.

So to summarize for Will: there's a release-critical bug filed against
Firefox in Debian right now, which is fully visible here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no=788721

The problem is that the Firefox source code bundles copies of compiled
of Javascript files that are missing the source version. In Debian
that's considered a copyright issue as compiled Javascript files are
like compiled binaries and not sufficient to work on as source code.

We need to find where that source is, in other words, for those files.

Jonas created a short list of the affected files, below. We'd be really
grateful if you could take a look at this.

Thanks!

A.

-- 
It will be a great day when our schools get all the money they need
and the air force has to hold a bake sale to buy a bomber.
- Unknown

On 2019-04-07 12:01:39, Jonas Smedegaard wrote:
> control: reassign 788721 firefox-esr
> control: retitle 788721 firefox-esr: Some sources are missing
>
> This bug affects firefox-esr in testing:
>
> At least these non-source files are still problematic:
>
> js/src/octane/typescript-input.js
> js/src/octane/box2d.js
> third_party/python/mock-1.0.0/html/_static/underscore.js
> third_party/python/mock-1.0.0/html/_static/jquery.js
> browser/components/translation/cld2/cld-worker.js
> browser/extensions/pocket/content/panels/js/vendor/jquery.tokeninput.min.js
> browser/extensions/pocket/content/panels/js/vendor/jquery-2.1.1.min.js
> layout/mathml/tests/stretchy-and-large-operators.js
>
> Other of the previously reported files may still be relevant as well, 
> and possibly additional files are similarly problematic (indicated by 
> doing a "find -name '*.min.js'" without examining further).
>
>  - Jonas
>
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
>
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private