Bug#1066313: fixed upstream

[Clément Hermann]

Hi,

Le 11/04/2024 à 22:23, micah anderson a écrit :


These issues are fixed upstream in main, but there is not a release.

The fix is in commit 1171bf2fd4e7a0cab02cf5fca59090b65af9cd29.

Clément would you pull that fix into the package to resolve this FTBFS?


Thanks for the heads up!

I'll try to upload a new version this week or early next week. I did 
include the fix, but there are a few lintian/policy issues I'd like to 
fix before an upload.


Cheers,


--
nodens

Bug#1055756: libasound2: some legacy midi apps (e.g. Chromium WebMIDI) are broken by alsa-lib 1.2.10

[Clément Hermann]

Hi,

FYI I created a merge request at 
https://salsa.debian.org/alsa-team/alsa-lib/-/merge_requests/4 to fix 
this one, using upstream patch.


cheers!

--
nodens

Bug#1055756: libasound2: some legacy midi apps (e.g. Chromium WebMIDI) are broken by alsa-lib 1.2.10

[Clément Hermann]

Package: libasound2
Version: 1.2.10-1
Severity: normal
Tags: patch upstream

Dear Alsa team,

alsa-lib 1.2.10 implements UMP support for seq.

Unfortunately, it breaks chromium WebMIDI at least partially.

This is a chromium bug, actually, but since it is a regression, upstream
has implemented a workaround for it:

Upstream Issue: https://github.com/alsa-project/alsa-lib/issues/360
Upstream fix: 
https://github.com/alsa-project/alsa-lib/commit/2fca03e792ef1b740e8a7370fdd360d0b627c84c

I have a fixed version available at
https://salsa.debian.org/nodens/alsa-lib.

(I'd have applied to join the team or proposed a NMU, but I forgot to update
my key in time and can't upload right now).

Cheers,

nodens

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

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

Versions of packages libasound2 depends on:
ii  libasound2-data  1.2.10-1
ii  libc62.37-12

libasound2 recommends no packages.

Versions of packages libasound2 suggests:
ii  libasound2-plugins  1.2.7.1-1+b1

-- no debconf information

Bug#1053869: alsa-ucm-conf: Devices profiles using ucm2/common/pcm/split.conf won't load (undefined var)

[Clément Hermann]

Package: alsa-ucm-conf
Version: 1.2.10-1
Severity: normal
Tags: upstream

Dear Alsa team,

Since 1.2.10, profiles using ucm2/common/pcm/split.conf won't load (at
least on Arturia Minifuse 1 and 2, and Motu M4). As a result, for cards
with more than 2 outputs, the default surround profile is loaded instead.

```
~$ alsaucm listcards
ALSA lib ucm_subs.c:807:(uc_mgr_get_substituted_value) variable 
'${var:__Device}' is not defined in this context!
ALSA lib parser.c:2024:(parse_verb_file) error: 
/USB-Audio/Arturia/Minifuse-12-HiFi.conf failed to parse device
ALSA lib main.c:1554:(snd_use_case_mgr_open) error: failed to import hw:1 use 
case configuration -22
ALSA lib parser.c:2965:(uc_mgr_scan_master_configs) Unable to open '-hw:1': 
Invalid argument
alsaucm: error failed to get card list: Invalid argument
```

Issue is known upstream
(https://github.com/alsa-project/alsa-ucm-conf/issues/346) and fixed by 
https://github.com/alsa-project/alsa-ucm-conf/commit/b68aa52acdd2763fedad5eec0f435fbf43e5ccc6

Applying the change directly in
`/usr/share/alsa/ucm2/common/pcm/split.conf` fixes the issue (hence the
local modification reported by reportbug). I guess the next release of
alsa-ucm-conf will include it, but in the meantime, I suggest applying
it as a patch in Debian.

I can provide a MR on salsa if it helps.

Cheers,

nodens

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

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

Versions of packages alsa-ucm-conf depends on:
ii  libasound2  1.2.10-1

alsa-ucm-conf recommends no packages.

alsa-ucm-conf suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/alsa/ucm2/common/pcm/split.conf (from 
alsa-ucm-conf package)

Bug#1017619: nautilus-wipe: Fails to build with nautilus 43

[Clément Hermann]

Hi,

FYI, Upstream has started work on that  in a branch 
https://git.tuxfamily.org/wipetools/nautiluswipe.git/log/?h=nautilus-extension-4-wip.


There are "alpha release" but I'm not sure this will be ready for 
bookworm. I can try to update it in experimental, though.


Cheers,

--
nodens

Bug#1029048: torsocks: Consider update Debian Package with latest upstream commits on master branch

[Clément Hermann]

Package: torsocks
Version: 2.3.0-3
Severity: wishlist

Hi,

upstream has some interesting commits in the Master branch (but no
release).

Notably, it seems now to handle syscall passthrough instead of dropping
them with a warning. We might want that in Bookworm (but this need to
happen soon).

https://gitweb.torproject.org/torsocks.git/commit/?id=67cee6c7976b4e103e6f9c3a70e767ffe54368e0

Thanks Unit193 for pointing that out!

Cheers,

--
nodens

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

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

Versions of packages torsocks depends on:
ii  libc6  2.36-7

Versions of packages torsocks recommends:
ii  tor  0.4.7.12-1

torsocks suggests no packages.

-- no debconf information

Bug#1016881: Please update chrome-gnome-shell to version 42

[Clément Hermann]

Hi,

Le 24/11/2022 à 07:44, Andres Salomon a écrit :
On Sat, 24 Sep 2022 12:39:08 +0200 =?utf-8?q?Cl=C3=A9ment_Hermann?= 
 wrote:

 > Package: chrome-gnome-shell
 > Version: 10.1-5
 > Followup-For: Bug #1016881
 >
 > Hi,
 >
 > Not sure it's actually a bug on chrome-gnome-shell, since what we need
 > is a new package that will replace this one for gnome >=42.

chrome-gnome-shell should probably turn into an empty package that 
depends on gnome-browser-extension (once it's uploaded). It would be 
good to get this done before bookworm freezes.


Agreed.


 >
 > The bug here is it should depends on gnome-shell <42.0, I guess.
 >
 > RFP for gnome-browser-extension: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020616

 >

I guess if no one else does it, I'll do it?



I'm willing to help, but I'm afraid I won't find enough time to do it 
before the freeze since I'm a bit swamped at the moment and have no 
experience packaging anything using meson…



Cheers

--
nodens

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Hi

Le 25/10/2022 à 13:53, Clément Hermann a écrit :

Hi Moritz,

Le 25/10/2022 à 11:15, Moritz Muehlenhoff a écrit :

Given that the primary use case for onionshare will be tails, my 
suggestion would be that CVE-2022-21689
and CVE-2022-21690 get backported fixes for the next Bullseye point 
release (which Tails will sync up

to). What do you think?


There are some users of onionshare beside in Tails, but that sounds 
like a viable plan.


FYI, backported fixes have been uploaded and should be included in next 
point release (#1023981)


Cheers,

--
nodens

Bug#1023981: bullseye-pu: package onionshare/2.2-3+deb11u1

[Clément Hermann]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu


[ Reason ]
Following discussion with Security Team about vulnerabilities in
onionshare (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014966 ), I prepared a
patched version which backport upstream fixes for CVE-2022-21689 and 
CVE-2022-21690.

Moritz proposed we just use point release for those instead of uploading
 to bullseye-security, hence this request. The issues aren't that
 critical and we are lagging already, so it can wait a few weeks more.

[ Impact ]

If the request isn't approved, I guess I'll ask Security Team to make it
a security upload.

[ Tests ]
I modified the tests in the code, and I did test the modified
functionnality manually with a bullseye virtual machine.

[ Risks ]
Modifications are quite simple. The last relevant CVE referenced in the
bug above would mean a lot more work, and more risks (backporting a lot
of code, or actually upgrade stable to 2.5, which would imply upgrading
python-stem as well). Since it is considered an edge case, it's been
decided it would be ignored in bullseye (I intend to provide a backport
later for user who would be at risk otherwise).

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
   * Change debian-branch to debian/bullseye in d/gbp.conf (ignored for
 dch)
   * Backport upstream fix for CVE-2022-21690 by forcing PlainText in
 QLabel
   * Backport upstream fix for CVE-2022-21689 by using µsec in filenames
 when receiving files
diff -Nru onionshare-2.2/debian/changelog onionshare-2.2/debian/changelog
--- onionshare-2.2/debian/changelog 2021-01-11 12:12:11.0 +0100
+++ onionshare-2.2/debian/changelog 2022-11-12 17:23:52.0 +0100
@@ -1,3 +1,10 @@
+onionshare (2.2-3+deb11u1) bullseye; urgency=medium
+
+  * Backport upstream fix for CVE-2022-21690
+  * Backport upstream fix for CVE-2022-21689
+
+ -- Clément Hermann   Sat, 12 Nov 2022 17:23:52 +0100
+
 onionshare (2.2-3) unstable; urgency=medium
 
   [ Ulrike Uhlig ]
diff -Nru onionshare-2.2/debian/gbp.conf onionshare-2.2/debian/gbp.conf
--- onionshare-2.2/debian/gbp.conf  2020-08-29 19:03:20.0 +0200
+++ onionshare-2.2/debian/gbp.conf  2022-11-12 17:23:52.0 +0100
@@ -1,4 +1,4 @@
 [DEFAULT]
 pristine-tar = True
-debian-branch = debian/sid
+debian-branch = debian/bullseye
 upstream-branch = master
diff -Nru onionshare-2.2/debian/patches/CVE-2022-21689-fix.diff 
onionshare-2.2/debian/patches/CVE-2022-21689-fix.diff
--- onionshare-2.2/debian/patches/CVE-2022-21689-fix.diff   1970-01-01 
01:00:00.0 +0100
+++ onionshare-2.2/debian/patches/CVE-2022-21689-fix.diff   2022-11-12 
17:23:52.0 +0100
@@ -0,0 +1,54 @@
+Description: Fix for CVE-2022-21689
+ Adapted from upstream 
https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377
+
+use microseconds for timestamps in filename
+
+Origin: backport, 
https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377
+Bug-GitHub: 
https://github.com/onionshare/onionshare/security/advisories/GHSA-jh82-c5jw-pxpc
+Last-Update: 2022-11-12
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/onionshare/web/receive_mode.py
 b/onionshare/web/receive_mode.py
+@@ -294,7 +294,7 @@
+ # Figure out what files should be saved
+ now = datetime.now()
+ date_dir = now.strftime("%Y-%m-%d")
+-time_dir = now.strftime("%H.%M.%S")
++time_dir = now.strftime("%H.%M.%S.%f")
+ self.receive_mode_dir = os.path.join(
+ self.web.common.settings.get("data_dir"), date_dir, time_dir
+ )
+--- a/tests/GuiReceiveTest.py
 b/tests/GuiReceiveTest.py
+@@ -1,3 +1,4 @@
++import glob
+ import os
+ import requests
+ from datetime import datetime, timedelta
+@@ -50,17 +51,17 @@
+ now = datetime.now()
+ for i in range(10):
+ date_dir = now.strftime("%Y-%m-%d")
+-if identical_files_at_once:
+-time_dir = now.strftime("%H.%M.%S-1")
+-else:
+-time_dir = now.strftime("%H.%M.%S")
++time_dir = now.strftime("%H.%M.%S")
+ receive_mode_dir = os.path.join(
+ self.gui.common.settings.get("data_dir"), date_dir, time_dir
+ )
+-expected_filename = os.path.join(receive_mode_dir, 
expected_basename)
+-if os.path.exists(expected_filename):
+-exists = True
+-break
++# The directories have microseconds in the name, so we need
++# to use globbing against d

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Hi Moritz,

Le 25/10/2022 à 11:15, Moritz Muehlenhoff a écrit :

Hi Clément,


Sadly, upstream rectified and confirms it affects 2.2 [0], and has been
tested and reproduced on Bullseye. We do need to fix it. Upstream has a few
suggestions, but I guess our choices are either uploading 2.5 to stable, if
that's possible. python-stem at least will need to be updated as well, from
1.8.0 to 1.8.1 which luckily is bugfix only.

With the upstream confirmation about affected states I had a look at the 
remaining
issues affecting Bullseye:


Thanks!


CVE-2022-21694 
(https://github.com/onionshare/onionshare/security/advisories/GHSA-h29c-wcm8-883h)
is not a vulnerability by itself, it's a lack of a feature at most. We can 
ignore it for
Bullseye.


Agreed, that's my reasoning too.


CVE-2022-21688 
(https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v)
is just a stop gap, the actual issue is in QT and I'll reach out to upstream 
for more information
when this was fixed in QT so that it can be backported to Bullseye's QT 
packages.

Agreed. The fix for CVE-2022-21690 will provide a workaround as well.


This leaves:
https://security-tracker.debian.org/tracker/CVE-2022-21690
https://security-tracker.debian.org/tracker/CVE-2022-21689
https://security-tracker.debian.org/tracker/CVE-2021-41868

I think it's fair to ignore CVE-2021-41868 for Bullseye, it sounds like an edge 
case
and invasive to fix.
I'm not sure how much of an edge case it is. But I agree it's fair. We 
could provide a backport for users needing secure authentication, so 
they could use onion v3 auth for this usage (I didn't check yet how easy 
a backport would be, but I expect it'd be simple except maybe for the 
poetry build system part).




This leaves CVE-2022-21690 and CVE-2022-21689 which have isolated patches which 
could be backported?


Yes.


Given that the primary use case for onionshare will be tails, my suggestion 
would be that CVE-2022-21689
and CVE-2022-21690 get backported fixes for the next Bullseye point release 
(which Tails will sync up
to). What do you think?


There are some users of onionshare beside in Tails, but that sounds like 
a viable plan.


Cheers,

--
nodens

Bug#1021732: [Pkg-privacy-maintainers] Bug#1021732: libimage-exiftool-perl breaks mat2 autopkgtest: 'ColorProfiles' not found in ...

[Clément Hermann]

Hi Georg,

Le 14/10/2022 à 11:12, Georg Faerber a écrit :

Control: forwarded -1 https://0xacab.org/jvoisin/mat2/-/issues/178
Control: tags -1 + fixed-upstream upstream

Hi Paul,

On 22-10-13 19:52:35, Paul Gevers wrote:

With a recent upload of libimage-exiftool-perl the autopkgtest of mat2
fails in testing when that autopkgtest is run with the binary packages
of libimage-exiftool-perl from unstable.

Thanks for your report.



Do you mind if I cherry-pick the upstream fix and upload today ?
This is blocking the perl 5.36 transition.

Thanks!

--
nodens

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Le 24/10/2022 à 20:41, Clément Hermann a écrit :


- CVE-2022-21694 <https://github.com/advisories/GHSA-h29c-wcm8-883h> 
affects Bullseye, but that might be an acceptable risk ? The issue is 
that CSP can only be turned on or off, not configured to allow js etc, 
so it is only useful for static websites. I believe that's the most 
common usage of a website with onionshare, and it's arguably a missing 
feature more than a vulnerability /per se/.


- CVE-2022-21689 <https://github.com/advisories/GHSA-jh82-c5jw-pxpc> 
fix should be easy to backport, at a glance: 
https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377


- CVE-2021-41868 <https://github.com/advisories/GHSA-7g47-xxff-9p85> 
doesn't affect 2.2 I think, it must have been a mistake from mig5. I 
just asked for confirmation. I do hope so since it's a bad one.


Sadly, upstream rectified and confirms it affects 2.2 [0], and has been 
tested and reproduced on Bullseye. We do need to fix it. Upstream has a 
few suggestions, but I guess our choices are either uploading 2.5 to 
stable, if that's possible. python-stem at least will need to be updated 
as well, from 1.8.0 to 1.8.1 which luckily is bugfix only.


- CVE-2022-21690 <https://github.com/advisories/GHSA-ch22-x2v3-v6vq> 
seems like a one-line patch: 
https://github.com/onionshare/onionshare/commit/8f1e7ac224e54f57e43321bba2c2f9fdb5143bb0


- CVE-2022-21688 <https://github.com/advisories/GHSA-x7wr-283h-5h2v> 
seems like it should be worked around with the CVE-2022-21690 
<https://github.com/advisories/GHSA-ch22-x2v3-v6vq> fix (OTF-001)?


I'd welcome input on those.

Of course if we choose to update onionshare to 2.5 in stable, we fix 
those as well.


[0] 
https://github.com/onionshare/onionshare/issues/1633#issuecomment-1289735350


Cheers,

--
nodens

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Le 24/10/2022 à 18:26, Clément Hermann a écrit :

Hi,

Le 23/10/2022 à 18:27, Clément Hermann a écrit :

Hi,

Le 22/10/2022 à 15:01, Salvatore Bonaccorso a écrit :

To be on safe side, explicitly confirming by upstream would be great.


Agreed. And asked upstream: 
https://github.com/onionshare/onionshare/issues/1633.


Upstream replied quickly (yay!) and confirms the known issues are 
fixed in 2.5.


Also, the detail of the vulnerable/patched versions has been updated. 
Quoting from the upstream issue:


Only affected >= 2.3 - < 2.5: CVE-2021-41867 
<https://github.com/advisories/GHSA-6rvj-pw9w-jcvc>, CVE-2022-21691 
<https://github.com/advisories/GHSA-w9m4-7w72-r766>, CVE-2022-21695 
<https://github.com/advisories/GHSA-99p8-9p2c-49j4>, CVE-2022-21696 
<https://github.com/advisories/GHSA-68vr-8f46-vc9f>
Only affected >= 2.2 - < 2.5: CVE-2022-21694 
<https://github.com/advisories/GHSA-h29c-wcm8-883h>
Only affected >=2.0 - < 2.5: CVE-2022-21689 
<https://github.com/advisories/GHSA-jh82-c5jw-pxpc>
Only affected >=2.0 - < 2.4: CVE-2021-41868 
<https://github.com/advisories/GHSA-7g47-xxff-9p85> (Receive mode 
bug, fixed by changing the authentication from HTTP auth to using 
Client Auth in Tor itself)
All versions < 2.5: CVE-2022-21690 
<https://github.com/advisories/GHSA-ch22-x2v3-v6vq>, and possibly 
depending on the Qt version, CVE-2022-21688 
<https://github.com/advisories/GHSA-x7wr-283h-5h2v>


GHSA-jgm9-xpfj-4fq6 
<https://github.com/onionshare/onionshare/security/advisories/GHSA-jgm9-xpfj-4fq6> 
is a complicated one, as a fix 
<https://github.com/onionshare/onionshare/pull/1474> we reduced the 
scope of access for Flatpak but you could argue that on 'native' 
Debian the whole file system, or at least the parts accessible to the 
user running OnionShare, is available not even in read-only mode. I'm 
not sure there's really a 'fix' for the deb package.


The advisories on 
https://github.com/onionshare/onionshare/security/advisories have been 
updated to reflect this.


I did more homework.

So, to summarize:
- CVE-2021-41867 <https://github.com/advisories/GHSA-6rvj-pw9w-jcvc>, 
CVE-2022-21691 <https://github.com/advisories/GHSA-w9m4-7w72-r766>, 
CVE-2022-21695 <https://github.com/advisories/GHSA-99p8-9p2c-49j4>, 
CVE-2022-21696 <https://github.com/advisories/GHSA-68vr-8f46-vc9f> 
aren't affecting Debian (stable has 2.2, unstable has 2.5). Which is 
good because the


- CVE-2022-21694 <https://github.com/advisories/GHSA-h29c-wcm8-883h> 
affects Bullseye, but that might be an acceptable risk ? The issue is 
that CSP can only be turned on or off, not configured to allow js etc, 
so it is only useful for static websites. I believe that's the most 
common usage of a website with onionshare, and it's arguably a missing 
feature more than a vulnerability /per se/.


- CVE-2022-21689 <https://github.com/advisories/GHSA-jh82-c5jw-pxpc> fix 
should be easy to backport, at a glance: 
https://github.com/onionshare/onionshare/commit/096178a9e6133fd6ca9d95a00a67bba75ccab377


- CVE-2021-41868 <https://github.com/advisories/GHSA-7g47-xxff-9p85> 
doesn't affect 2.2 I think, it must have been a mistake from mig5. I 
just asked for confirmation. I do hope so since it's a bad one.


- CVE-2022-21690 <https://github.com/advisories/GHSA-ch22-x2v3-v6vq> 
seems like a one-line patch: 
https://github.com/onionshare/onionshare/commit/8f1e7ac224e54f57e43321bba2c2f9fdb5143bb0


- CVE-2022-21688 <https://github.com/advisories/GHSA-x7wr-283h-5h2v> 
seems like it should be worked around with the CVE-2022-21690 
<https://github.com/advisories/GHSA-ch22-x2v3-v6vq> fix (OTF-001)?


I'd welcome input on those.

Cheers,

--
nodens

Bug#1022725: onionshare: Please provide Apparmor profiles (GHSA-jgm9-xpfj-4fq6)

[Clément Hermann]

Package: onionshare
Version: 2.5-2
Severity: wishlist

Quoting 
https://github.com/onionshare/onionshare/security/advisories/GHSA-jgm9-xpfj-4fq6

> Between September 26, 2021 and October 8, 2021, Radically Open
> Security conducted a penetration test of OnionShare 2.4, funded by the
> Open Technology Fund's Red Team lab. This is an issue from that
> penetration test.


> Vulnerability ID: OTF-013
> Vulnerability type: Improper Hardening
> Threat level: Low

> Description:
>
> The filesystem restriction could be hardened and should only allow for
> pre-defined subfolders.

Upstream uses Flatpak to mitigate this, which of course makes little
sense on Debian.

However, we could provide something similar using Apparmor.

Cheers,

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

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

Versions of packages onionshare depends on:
ii  onionshare-cli 2.5-2
ii  python33.10.6-1
ii  python3-pyside2.qtcore 5.15.2-2.3+b2
ii  python3-pyside2.qtwidgets  5.15.2-2.3+b2
ii  python3-qrcode 7.3.1-1

onionshare recommends no packages.

onionshare suggests no packages.

-- no debconf information

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Hi,

Le 23/10/2022 à 18:27, Clément Hermann a écrit :

Hi,

Le 22/10/2022 à 15:01, Salvatore Bonaccorso a écrit :


Thanks for the quick reply! (much appreciated). I think it would be
good to get a confirmation from upstream and if possible to have
those advisories updates. E.g.
https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v 


while mentioning "affected versions < 2.4" the patched version remains
"none". this might be that the < 2.4 just reflects the point in time
when the advisory was filled. OTOH you have arguments with the v2.5
release information that they might all be fixed.

To be on safe side, explicitly confirming by upstream would be great.


Agreed. And asked upstream: 
https://github.com/onionshare/onionshare/issues/1633.


Upstream replied quickly (yay!) and confirms the known issues are fixed 
in 2.5.


Also, the detail of the vulnerable/patched versions has been updated. 
Quoting from the upstream issue:


Only affected >= 2.3 - < 2.5: CVE-2021-41867 
<https://github.com/advisories/GHSA-6rvj-pw9w-jcvc>, CVE-2022-21691 
<https://github.com/advisories/GHSA-w9m4-7w72-r766>, CVE-2022-21695 
<https://github.com/advisories/GHSA-99p8-9p2c-49j4>, CVE-2022-21696 
<https://github.com/advisories/GHSA-68vr-8f46-vc9f>
Only affected >= 2.2 - < 2.5: CVE-2022-21694 
<https://github.com/advisories/GHSA-h29c-wcm8-883h>
Only affected >=2.0 - < 2.5: CVE-2022-21689 
<https://github.com/advisories/GHSA-jh82-c5jw-pxpc>
Only affected >=2.0 - < 2.4: CVE-2021-41868 
<https://github.com/advisories/GHSA-7g47-xxff-9p85> (Receive mode bug, 
fixed by changing the authentication from HTTP auth to using Client 
Auth in Tor itself)
All versions < 2.5: CVE-2022-21690 
<https://github.com/advisories/GHSA-ch22-x2v3-v6vq>, and possibly 
depending on the Qt version, CVE-2022-21688 
<https://github.com/advisories/GHSA-x7wr-283h-5h2v>


GHSA-jgm9-xpfj-4fq6 
<https://github.com/onionshare/onionshare/security/advisories/GHSA-jgm9-xpfj-4fq6> 
is a complicated one, as a fix 
<https://github.com/onionshare/onionshare/pull/1474> we reduced the 
scope of access for Flatpak but you could argue that on 'native' 
Debian the whole file system, or at least the parts accessible to the 
user running OnionShare, is available not even in read-only mode. I'm 
not sure there's really a 'fix' for the deb package.


The advisories on 
https://github.com/onionshare/onionshare/security/advisories have been 
updated to reflect this.


--
nodens

Bug#915869: onionshare sometimes get backtrace on shutdown

[Clément Hermann]

Hi,

have you seen the same issue with recent (2.x) versions?

(asking because I never had the issue, and I'm tempted to close this as 
fixed in current testing version at least).



Cheers,

--
nodens

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Hi,

Le 22/10/2022 à 15:01, Salvatore Bonaccorso a écrit :


Thanks for the quick reply! (much appreciated). I think it would be
good to get a confirmation from upstream and if possible to have
those advisories updates. E.g.
https://github.com/onionshare/onionshare/security/advisories/GHSA-x7wr-283h-5h2v
while mentioning "affected versions < 2.4" the patched version remains
"none". this might be that the < 2.4 just reflects the point in time
when the advisory was filled. OTOH you have arguments with the v2.5
release information that they might all be fixed.

To be on safe side, explicitly confirming by upstream would be great.


Agreed. And asked upstream: 
https://github.com/onionshare/onionshare/issues/1633.


Cheers,

--
nodens

Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

[Clément Hermann]

Hi,

Le 22/10/2022 à 15:59, Vincent Lefevre a écrit :

Hi,

On 2022-10-22 14:31:24 +0200, Clément Hermann wrote:

I could reproduce your issue if I enable check_sigs option in CPAN
(which is _not_ the default).


OK, I forgot about that (though I think that it should be the default
for security reasons, and IIRC, this was recommended for this reason
in some other thread).


I do think it's a good idea to enable it.


Thing is, it's not a bug, really. Or not quite. It's a result of the
correction of a bug in CPAN < 2.29 who would succeed silently if there is no
signature/no way to check the key.

You can find some context in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and
http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html


I didn't know that. In particular, I had not got any announce,
probably because it is still not fixed in Debian/stable. And
AFAIK, http is also still used by default in Debian/stable, so
that this makes the security even worse.


http or not won't change much, since CPAN uses a mirror network 
(arguably with only "safe" mirrors now). Checking the signature of the 
hashes is the right way to make sure a downloaded module is really the 
one a developer makes available.



I do agree that it's bad UX that CPAN isn't more helpful when the key isn't
available, e.g. asking for it or suggesting a way to get it, but the fact
that it fails if the key isn't available while the Checksums are signed is
the right behavior, and your workaround (getting the key) is the right
solution.

CPAN doesn't have a way to centralize key themself, and probably shouldn't,
either. Not sure how such error can be avoided completely (the Debian method
of having a preconfigured keyring won't do for CPAN IMO), but it should at
least suggest a solution.


I agree. There should be at least sufficient documentation when the
error occurs. If Debian could automatically provide the key and use
it, this would be better, IMHO: less work for the user, and this
would ensure (if correctly done) that the key is correct and still
valid.


Thing is, Debian cannot anticipate what modules you want to install via 
CPAN (so outside of Debian), so which developer keys to get, and also 
cannot install keys from all CPAN contributors in the user keyring…


A way to fix this would be to make the message in CPAN more helpful and 
propose to get the key from a known source (e.g. keyserver), but I think 
that really ought to be done upstream.


Note that in my current installation, a more helpful message is 
displayed at the end (possibly because I installed 
libmodule-signature-perl):


```
Module::Signature verification returned value 0E0

The manual says for this case: Cannot verify the
OpenPGP signature, maybe due to the lack of a network connection to
the key server, or if neither gnupg nor Crypt::OpenPGP exists on the
system. You probably want to analyse the situation and if you cannot
fix it you will have to decide whether you want to stop this session
or you want to turn off signature verification. The latter would be
done with the command 'o conf init check_sigs'
```

I'm guessing the key would be donwloaded with Crypt::OpenPGP installed 
(unfortunately not in Debian yet), but I didn't test.


Please report if you test with Crypt::OpenPGP installed via CPAN: if 
that makes the behaviour better UX-wise, we should package it (there are 
a few deps but I don't see any issue at a glance).


Cheers,


--
nodens

Bug#1014966: onionshare: CVE-2021-41867 CVE-2021-41868 CVE-2022-21688 CVE-2022-21689 CVE-2022-21690 CVE-2022-21691 CVE-2022-21692 CVE-2022-21693 CVE-2022-21694 CVE-2022-21695 CVE-2022-21696

[Clément Hermann]

Hi Salvatore,

Le 22/10/2022 à 13:49, Salvatore Bonaccorso a écrit :



For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-41867
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41867
[1] https://security-tracker.debian.org/tracker/CVE-2021-41868
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41868
[2] https://security-tracker.debian.org/tracker/CVE-2022-21688
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21688
[3] https://security-tracker.debian.org/tracker/CVE-2022-21689
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21689
[4] https://security-tracker.debian.org/tracker/CVE-2022-21690
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21690
[5] https://security-tracker.debian.org/tracker/CVE-2022-21691
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21691
[6] https://security-tracker.debian.org/tracker/CVE-2022-21692
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21692
[7] https://security-tracker.debian.org/tracker/CVE-2022-21693
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21693
[8] https://security-tracker.debian.org/tracker/CVE-2022-21694
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21694
[9] https://security-tracker.debian.org/tracker/CVE-2022-21695
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21695
[10] https://security-tracker.debian.org/tracker/CVE-2022-21696
 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-21696

 From the reported list CVE-2021-41867 and CVE-2021-41868 were
addressed in 2.4 upstream. But the other seem yet unfixed in 2.5, even
though likely as well those who contain "has been patched in 2.5". I
have not found any indication that this there is really the case.

Any more insights OTOH from you on those?
According to onionshare 2.5 release notes [1], and to the 
vulnerabilities list on the github project [2], I'd say they were fixed.
All vulnerabilities are marked as affecting <2.4 since 2.5 release, and 
for instance for the username impersonation, it's been specified in the 
release notes that the security have been tightened on this front.


That said, I didn't check the code for every vuln individually, and I 
definitely could ask upstream for clarification/confirmation if you 
think it's necessary.




[1] https://github.com/onionshare/onionshare/releases/tag/v2.5
[2] https://github.com/onionshare/onionshare/security/advisories

Cheers,

--
nodens

Bug#1022200: CPAN should be more helpful on missing key when check_sigs is enabled (Was: Re: cpan: cannot check signatures)

[Clément Hermann]

Hi!

Thanks for your report.

I could reproduce your issue if I enable check_sigs option in CPAN 
(which is _not_ the default).


Thing is, it's not a bug, really. Or not quite. It's a result of the 
correction of a bug in CPAN < 2.29 who would succeed silently if there 
is no signature/no way to check the key.


You can find some context in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015985 and
http://blogs.perl.org/users/neilb/2021/11/addressing-cpan-vulnerabilities-related-to-checksums.html

I do agree that it's bad UX that CPAN isn't more helpful when the key 
isn't available, e.g. asking for it or suggesting a way to get it, but 
the fact that it fails if the key isn't available while the Checksums 
are signed is the right behavior, and your workaround (getting the key) 
is the right solution.


CPAN doesn't have a way to centralize key themself, and probably 
shouldn't, either. Not sure how such error can be avoided completely 
(the Debian method of having a preconfigured keyring won't do for CPAN 
IMO), but it should at least suggest a solution.


So setting the severity back to normal, but still leaving the bug open, 
since it's confusing for the user, and it could be done better (upstream).


Cheers,

--
nodens

Bug#1022203: openpgp-applet: since upstream move from Alioth to Salsa, uscan fails

[Clément Hermann]

Source: openpgp-applet
Version: 1.1-3
Severity: normal

Hi,

Since some time, the debian/watch for opengpgp-applet can't get
signatures.
The signatures are in the /upload/ subdirectory, which is unpredicatable:

Looking at 
https://salsa.debian.org/openpgp-applet-team/openpgp-applet/-/archive/OpenPGP_Applet-1.1/openpgp-applet-OpenPGP_Applet-1.1.tar.gz,
 we can get the download link for tarballs, but to get the signature for this 
file, one has to follow the link to the release desc:
https://salsa.debian.org/openpgp-applet-team/openpgp-applet/-/tags/OpenPGP_Applet-1.1

in which the signature can be downloaded: 
https://salsa.debian.org/openpgp-applet-team/openpgp-applet/uploads/77ee3004f99643f3a2275317354bf950/OpenPGP_Applet-1.1.tar.gz.asc

This is fine for humans who will figure it out, but bad for automation.

Maybe there is a way to parse a specific page with the version name with
uscan? Didn't find an obvious way, but would welcome pointers.

Cheers

-- 
nodens

Bug#1021901: ardour: Ardour 7.0.0 out :)

[Clément Hermann]

Package: ardour
Version: 1:6.9.0+ds0-2+b1
Severity: wishlist

Dear Maintainer,

In case you didn't notice yet, Ardour 7.0.0 has been released on October
15th. Since I wanted to give it a go, I thought I'd try to upgrade to
the last upstream release.

So I created a MR on salsa for you to review:

https://salsa.debian.org/multimedia-team/ardour/-/merge_requests/4

It's still in Draft since there are a few things to fix still (check
TODO section in changelog). I intend to fix them before removing the
Draft tag.

Of course, feel free to beat me to it, add commits before merging, remove the 
draft tag and just merge and work from there; or cherry-pick what you want…

I tried my best to stay consistent with the previous work / team rules,
but I'm new to these packages, so I might have missed stuff.

HTH,

-- 
nodens


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

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

Versions of packages ardour depends on:
ii  ardour-data   1:6.9.0+ds0-2
ii  ardour-lv2-plugins1:6.9.0+ds0-2+b1
ii  libarchive13  3.6.0-1
ii  libasound21.2.7.2-1
ii  libatkmm-1.6-1v5  2.28.3-1
ii  libaubio5 0.4.9-4.2+b1
ii  libc6 2.35-2
ii  libcairo2 1.16.0-6
ii  libcairomm-1.0-1v51.14.4-1
ii  libcurl3-gnutls   7.85.0-1
ii  libcwiid1 0.6.91-4
ii  libdbus-1-3   1.14.2-1
ii  libfftw3-single3  3.3.8-2
ii  libfluidsynth32.3.0-1
ii  libfontconfig12.13.1-4.5
ii  libgcc-s1 12.2.0-5
ii  libgdk-pixbuf-2.0-0   2.42.9+dfsg-1
ii  libglib2.0-0  2.74.0-2
ii  libglibmm-2.4-1v5 2.66.5-1
ii  libgtk2.0-0   2.24.33-2
ii  libgtkmm-2.4-1v5  1:2.24.5-4+b1
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-1
ii  liblilv-0-0   0.24.14-1
ii  liblo70.31-1
ii  liblrdf0  0.6.1-2
ii  libltc11  1.3.1-1
ii  libpango-1.0-01.50.10+ds-1
ii  libpangocairo-1.0-0   1.50.10+ds-1
ii  libpangoft2-1.0-0 1.50.10+ds-1
ii  libpangomm-1.4-1v52.46.3-1
ii  libpulse0 16.1+dfsg1-2
ii  libqm-dsp01.7.1-5
ii  libreadline8  8.2-1
ii  librubberband23.0.0+dfsg0-1+b1
ii  libsamplerate00.2.2-2
ii  libsigc++-2.0-0v5 2.10.8-1
ii  libsndfile1   1.1.0-2
ii  libstdc++612.2.0-5
ii  libsuil-0-0   0.10.18-1
ii  libtag1v5 1.12-1+b1
ii  libusb-1.0-0  2:1.0.26-1
ii  libvamp-hostsdk3v52.10.0-1
ii  libvamp-sdk2v52.10.0-1
ii  libwebsockets17   4.1.6-3
ii  libx11-6  2:1.8.1-2
ii  libxml2   2.9.14+dfsg-1+b1

Versions of packages ardour recommends:
ii  ardour-video-timeline  1:6.9.0+ds0-2

ardour suggests no packages.

-- no debconf information

Bug#1016881: Please update chrome-gnome-shell to version 42

[Clément Hermann]

Package: chrome-gnome-shell
Version: 10.1-5
Followup-For: Bug #1016881

Hi,

Not sure it's actually a bug on chrome-gnome-shell, since what we need
is a new package that will replace this one for gnome >=42.

The bug here is it should depends on gnome-shell <42.0, I guess.

RFP for gnome-browser-extension: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1020616

Cheers,


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

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

Versions of packages chrome-gnome-shell depends on:
ii  gnome-shell   42.4-2
ii  python3   3.10.6-1
ii  python3-gi3.42.2-2
ii  python3-requests  2.27.1+dfsg-1

chrome-gnome-shell recommends no packages.

Versions of packages chrome-gnome-shell suggests:
ii  chromium  105.0.5195.125-1
ii  firefox   104.0.2-1

-- no debconf information

-- 
nodens

Bug#1020616: RFP: gnome-browser-connector -- GNOME Shell extensions integration for web browsers

[Clément Hermann]

Package: wnpp
Severity: wishlist

* Package name: gnome-browser-connector
  Version : 42.1
  Upstream Author : Yuri Konotopov 
* URL : 
https://wiki.gnome.org/Projects/GnomeShellIntegrationForChrome
* License : GPLv3
  Programming Lang: Python
  Description : GNOME Shell extensions integration for web browsers

 Provides integration with GNOME Shell extensions repository (v8 API) for
 Chromium (and derivatives) and Firefox
 .
 This package provides the connector that talks with the browser
 extension, supporting v8 API version and replacing the former
 chrome-gnome-shell connector

Bug#1019888: pipewire 0.3.57-1: no/crackling sound if pavucontrol is open, 0.3.56-1 is fine

[Clément Hermann]

Package: pipewire
Version: 0.3.57-1

Tags: fixed-upstream

Dear pipewire maintainers,

I'm a happy user of pipewire since a few month, however since the
upgrade to 0.3.57, no node can output sound if pavucontrol is open.

When pavucontrol is open, pipewire log show the following error message

(3-4/second):
```
spa.alsa: hw:sofhdadsp: snd_pcm_avail after recover: Broken pipe
```

Starting pavucontrol after the node starts playing works a little
better: there is sound, but it's choppy.

Closing pavucontrol makes the sound working again.
Downgrading pipewire to the 0.3.56-1 version fixes it as well.

I believe this is an upstream regression: 
https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2671 (fixed in 
0.3.58 it seems, but I didn't test it).


Disclaimer: I have a fairly fine-tuned configuration for low audio
latency, for pro audio apps (recording, routing, etc). It might make
things worse in this case. So while I considered tagging this `Important`
I refrained from doing so, I might be in a corner case.

The Gnome sound parameter menu works fine (but you can't enable/disable
device profiles with it, hence my usage of pavucontrol even when I'm not
using recording apps).

Please, can we get 0.3.58 sooner rather than later?

I see there are a lot of changes in the work, and I understand you want 
to get them right,
as well as discuss them maybe, especially with the conversation going on 
currently about pipewire.


That said, can I suggest decorellate system changes and upgrading to 
latest upstream release first so this is fixed?


Thanks :)


PS: if anyone reading this needs to downgrade on **sid**, the easy way is

- adding the right snapshot in apt list from snapshots.d.o:
https://snapshot.debian.org/archive/debian/20220720T032429Z/
contrib non-free`

- and downgrade like this:

`export pwver=0.3.56-1; apt install 
{pipewire{,-alsa,-bin,-jack,-pulse},libspa-0.2-{modules,bluetooth,jack},libpipewire-0.3{-0,-modules},gstreamer1.0-pipewire}=$pwver`


do *not* do this on testing, at least not blindly, you'd need to get the 
right snapshot first ;)



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

Kernel: Linux 5.18.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
not set

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pipewire depends on:
ii init-system-helpers 1.64
ii libpipewire-0.3-modules 0.3.57-1
ii pipewire-bin 0.3.57-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

--
nodens

Bug#1018428: onionshare: build-depends on python3-nose or uses it for autopkgtest

[Clément Hermann]

Hi,

Le 28/08/2022 à 20:42, Dmitry Shachnev a écrit :

Source: onionshare
Version: 2.2-3
User: python-modules-t...@lists.alioth.debian.org
Usertags: nose-rm

Dear Maintainer,

Your package still uses nose [1], which is an obsolete testing framework for
Python, dead and unmaintained since 2015 [2][3].

If you received this bug report, it means that your package either has a
build-dependency on python3-nose or uses that package in debian/tests/control.
If that is not the case, please reply and CC me explicitly.



thanks for the report!

The dependency is actually leftover cruft, the tests use pytest now, but 
the build-dep wasn't removed.


It should be fixed in the next upload (which won't come immediately 
because new upstream release has lots of changes, work in progress).


Cheers,

--
nodens

Bug#472477: #472477 ssh-add -D does not remove SSH key from gnome-keyring-daemon memory (workaround)

[Clément Hermann]

Hi,

So, my workaround for this annoying issue was to use gpg-agent instead. 
As a nice side effect, you can then use a gpg key to authenticate.


The tricky part for me was to make sure gnome woudn't try to set 
SSH_AUTH_SOCK to gnome keyring anyway.


In case others want to go this route, here is what I've done:

- make sure your gpg-agent can handle ssh agent role by including 
`enable-ssh-support` in ~/.gnupg/gpg-agent.conf
(you can also set ttls there while you're at it if you want, e,g, 
`default-cache-ttl-ssh 1200`, `max_cache_ttl-ssh 7200`)


- disable ssh component of gnome-keyring in systemd user units:

```
systemctl --user mask gcr-ssh-agent.socket --now
systemctl --user mask gcr-ssh-agent.service --now
```

- disable ssh component of gnome-keyring also in XDG autostart by adding 
the Hidden property:

```
cp /etc/xdg/autostart/gnome-keyring-ssh.desktop ~/.config/autostart/
echo "Hidden=true" >> ~/.config/autostart/gnome-keyring-ssh.desktop
```

Then restart the session.

Be aware that when you use ssh-add for the first time when having the 
gpg-agent socket in SSH_AUTH_SOCK, you'll be first prompted by ssh-add, 
then by gpg-agent. Set a passphrase in gpg-agent when prompted, 
otherwise it will be stored in clear in your private keys. Usual 
gpg-agent stuff applies, it will lock whenever you lock the session, you 
get a timeout, etc.


Cheers,

--
nodens

Bug#990189: alsa-ucm-conf: New upstream version 1.2.7.1

[Clément Hermann]

Package: alsa-ucm-conf
Version: 1.2.6.3-1
Followup-For: Bug #990189

Dear Maintainer,

upstream is now at 1.2.7.1, and there are many interesting changes for
multichannel cards.

Thanks!

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

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

Versions of packages alsa-ucm-conf depends on:
ii  libasound2  1.2.6.2-0.1

alsa-ucm-conf recommends no packages.

alsa-ucm-conf suggests no packages.

-- no debconf information

Bug#1013750: alsa-lib: new upstream release 1.2.7.1

[Clément Hermann]

Source: alsa-lib
Version: 1.2.4-1.1
Severity: wishlist

Dear Maintainer,

the 1.2.7.1 upstream release is available.

It's especially interesting to me because of changes in the UCM
interface that allows to handle multichannel interfaces better (macros
for making splitting/joining channels easier in UCM, e.g for pro-audio
interfaces, and the new configs upstream need 1.2.7 alsa-lib).

(I'll file a separate bug for the same request on alsa-ucm-conf).

Thanks!

nodens

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

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

Bug#981817: [Pkg-privacy-maintainers] Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

[Clément Hermann]

On 10/02/2021 00:18, Jonathan Marquardt wrote:
> On Fri, Feb 05, 2021 at 12:08:49PM +0100, Clément Hermann wrote:

>> in a clean Buster virtual machine, I tried to pip3 install psutil then
>> install onioncircuits, and I didn't get this error (though I didn't try
>> with a graphical environment running). There must be something else
>> going on in your environment, maybe check the permissions on /usr/local
>> and below, or try to go the virtualenv route, or if you can, install the
>> python modules you need using Debian Packages (psutil has a recent
>> version available through buster-backports for instance).
>
> I played around a bit and found the following things:
>
> Clean install with Debian 10 with Gnome: onioncircuits works.
>
> After I run "pip3 install psutil" as root: onioncircuits doesn't work.
>
> After I run "pip3 uninstall psutil" as root: It works again.
>
> However I found out that it always works (on all of my systems) if I
launch
> onionciruits with the command:
>
> $ python3 /usr/bin/onionciruit
>
> I have no idea why.

"type python3" might tell you if you are maybe using an alternate
python3 interpreter located in /usr/local when doing that. The shebang
in onioncircuits explicitely uses /usr/bin/python3 which might be
different that the one that is first in PATH.

I would recommend making sure any other, non-system python3 is
self-enclosed (maybe in /opt) if needed. python-virtualenv might be a
solution you want to have a look at: system python used for packages,
and separated, local python for local code.

I'm going to close this bug, since it's not an issue on the package.

Thanks for the additional info, even if it's not a bug in the package
this might be useful to other!

Cheers,

-- 
nodens

Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

[Clément Hermann]

On 04/02/2021 13:04, Jonathan Marquardt wrote:
> On Thu, Feb 04, 2021 at 12:23:17PM +0100, Clément Hermann wrote:
>> The error message reference stuff in /usr/local: this leads me to think
>> some python libs where locally installed without using the package
>> system. Can you check that please ? And maybe test in a vm for instance
>> to check in a clean environment ?
> 
> I checked and you're right. This doesn't happen in a clean environment. I 
> figured out what causes the issue. I have psutil installed using pip (pip3 
> install psutil).
> 
> Is there a way to fix this? What even causes this? I need psutil to be 
> installed for some other python programs.

I'm not sure in this particular case, the permission error suggests
there is something on your setup that prevents the user running
onioncircuits to access this file.

Usually when one mixes distribution packages and pip, one would use
virtualenv or something similar to ensure what is run via pip modules is
self-contained.

The thing is, I'm not sure why this error is on this module
specifically, or that the module is pstutil is significant or it could
be anyone.

in a clean Buster virtual machine, I tried to pip3 install psutil then
install onioncircuits, and I didn't get this error (though I didn't try
with a graphical environment running). There must be something else
going on in your environment, maybe check the permissions on /usr/local
and below, or try to go the virtualenv route, or if you can, install the
python modules you need using Debian Packages (psutil has a recent
version available through buster-backports for instance).

Cheers,

-- 
nodens

Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

[Clément Hermann]

Control: severity -1 normal
Control: tags -1 +moreinfo

Hi,

Thanks for reporting a bug in onioncircuit Debian package!


On 04/02/2021 10:39, Jonathan Marquardt wrote:
> Package: onioncircuits
> Version: 0.5-4
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> I have multiple systems running the Debian Tor package with an open control 
> port. I always used this in combination with onioncircuits without any 
> problems until I upgraded to Debian Buster. Since the upgrade (or even fresh 
> installation of Buster) I'm unable to start onioncircuits:
> 
> 
> 
> $ onioncircuits
> Traceback (most recent call last):
>   File "/usr/bin/onioncircuits", line 25, in 
> import pycountry
>   File "/usr/lib/python3/dist-packages/pycountry/__init__.py", line 9, in 
> 
> from pkg_resources import resource_filename
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3191, 
> in 
> @_call_aside
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3175, 
> in _call_aside
> f(*args, **kwargs)
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 3204, 
> in _initialize_master_working_set
> working_set = WorkingSet._build_master()
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 574, 
> in _build_master
> ws = cls()
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 567, 
> in __init__
> self.add_entry(entry)
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 623, 
> in add_entry
> for dist in find_distributions(entry, True):
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2033, 
> in find_on_path
> for dist in factory(fullpath):
>   File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2095, 
> in distributions_from_metadata
> if len(os.listdir(path)) == 0:
> PermissionError: [Errno 13] Permission denied: 
> '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'
> 
> 
> 
> This even happens as root.
> 
> Is this a known issue?

I don't think so. I can't reproduce this issue either on a system that
already had onioncircuits installed or a newly installed system, so I'm
lowering the severity.

The error message reference stuff in /usr/local: this leads me to think
some python libs where locally installed without using the package
system. Can you check that please ? And maybe test in a vm for instance
to check in a clean environment ?


Cheers,

-- 
nodens

Bug#768073: [pkg-lxc-devel] Bug#768073: ITP: lxd - The Linux Container Daemon

[Clément Hermann]

Hi,

On 08/01/2021 05:07, peylight wrote:
> Hi Dear Debian Developers,
> Can you check the 331th message of LXD packaging please:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768073#311
> 

Thanks for your interest in LXD packaging - and sorry for the late reply.

The issue with said package is that it doesn't follow Debian packaging
guidelines. We can't vendor all the deps like it's done here. Some
vendoring might be OK in very specific cases, but here we have to take
the long road.

The progress on packaging LXD deps is tracked in gobby.debian.org at
Teams/Go/lxd-deps-packaging.

An http export is here:
https://gobby.debian.org/export/Teams/Go/lxd-dep-packaging.

As you can see, there are still a lors of dependancies. I doubt we'll be
able to make this enter Debian before the soft freeze, but if enough
people want to help, that might still be possible.

Intested parties, please don't hesitate to just tag some entries in the
Gobby doc or ping me on IRC (nodens) to tell me what you're working on.

Cheers,

-- 
nodens

Bug#976579: libgsecuredelete: FTBFS in debian (patch)`

[Clément Hermann]

Hi,

libgsecuredelete currently fails to build in Debian: see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976579.

This is due to some automake strangeness: generated valac command line
seems wrong, according to Rico Tzschichholz, aka ricotz, upstream Vala
contributor.

The attached patch (courtesy of ricotz) allows to build properly. I also
managed to successfully build and use nautilus-wipe with the resulting lib.

Also, the vapi path follows vala recommendation and is put in
/usr/share/vala/vapi.

It was also suggested the *_vala.stamp file should be deleted before
build to ensure the code is properly generated. I implemented this in
the debian package (to be uploaded soon).

Please, consider including this patch.

Cheers,

-- 
Clément Hermann (nodens)
(with my Tails contributor and Debian Privacy Packaging Team member hats
both on)
Description: Fix valac call generation in gsecuredelete/Makefile.am
 Should avoid "already contains a definition for" errors by using vala properly
Author: Rico Tzschichholz 
Forwarded: yes
Last-Update: 2021-01-11
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
diff --git a/gsecuredelete/Makefile.am b/gsecuredelete/Makefile.am
index c5c62e3..b7dcc18 100644
--- a/gsecuredelete/Makefile.am
+++ b/gsecuredelete/Makefile.am
@@ -26,15 +26,16 @@ libgsecuredelete_la_SOURCES = gsd-async-operation.vala \
   gsd-swap-operation.vala \
   gsd-utils.vala \
   gsd-zeroable-operation.vala
-libgsecuredelete_la_include_HEADERS = gsecuredelete.h \
-  gsecuredelete.vapi
+libgsecuredelete_la_include_HEADERS = gsecuredelete.h
+
+vapidir = $(datadir)/vala/vapi
+dist_vapi_DATA = gsecuredelete.vapi
 
 test_VALAFLAGS = $(AM_VALAFLAGS) --vapidir=. --pkg=gsecuredelete
 test_SOURCES = main.vala
 test_LDADD = libgsecuredelete.la
 
 gsecuredelete.vapi: libgsecuredelete_la_vala.stamp
-test_vala.stamp: gsecuredelete.vapi
 
 $(libgsecuredelete_la_SOURCES:.vala=.c): gsd-config.h

Bug#971299: [Pkg-privacy-maintainers] Bug#971299: onionshare: Switch to python3-pycryptodome

[Clément Hermann]

Hi,

On 10/01/2021 23:46, Sebastian Ramacher wrote:
> On 2020-10-05 15:18:46 +0200, Clément Hermann wrote:
>>
>> Hi,
>>
>> Control: block 971299 with 886291
>> thanks
>>
>> On 28/09/2020 23:29, Sebastian Ramacher wrote:
>>> Source: onionshare
>>> Version: 2.2-2
>>> Severity: important
>>> Tags: sid bullseye
>>> Usertags: pycrypto
>>>
>>> Dear maintainer,
>>>
>>> onionshare currently Build-Depends or Depends on python3-crypto from
>>> PyCrypto. This project is no longer maintained and PyCryptodome
>>> (https://www.pycryptodome.org/en/latest/) provides a drop in
>>> replacement. Please switch to python3-pycryptodome. I'd like to
>>> remove python-crypto before the release of bullseye.
>>
>>
>> As far as I understand it, pycryptodome *can* be a drop-in replacement
>> usually, but not currently in Debian since it doesn't install in Crypto
>> but Cryptodomex namespace (#886291).
>>
>> Are there any plan to change it when python3-crypto is removed or before ?
>>
>> Of course, we can patch onionshare to import cryptodomex, but that patch
>> would be debian-only then… Upstream already expect pycryptodome as
>> Crypto module.
> 
> Sorry for the delay. I don't have any plans other than removing
> python3-crypto. CCing the pycryptodome maintainer for more input.

Thanks. Meanwhile, Ulrike added a patch to import cryptodome explicitly,
and I just uploaded the version with it. It's a short-term fix IMO,
until #886291 is clarified, but at least it removes the dep to pycrypto.

Cheers,

-- 
nodens

Bug#978411: src:golang-gopkg-lxc-go-lxc.v2: fails to migrate to testing for too long: maintainer built arch:all binary

[Clément Hermann]

Hi Paul,

On 27/12/2020 07:12, Paul Gevers wrote:
> Source: golang-gopkg-lxc-go-lxc.v2
> Version: 0.0+git20190625.f4822c6-1
> Severity: serious
> Control: close -1 0.0+git20201012.d1943fb-1
> Tags: sid bullseye pending
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> As recently announced [1], the Release Team now considers packages that
> are out-of-sync between testing and unstable for more than 60 days as
> having a Release Critical bug in testing. Your package
> src:golang-gopkg-lxc-go-lxc.v2 in its current version in unstable has
> been trying to migrate for 62 days [2]. Hence, I am filing this bug.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and bullseye, so
> it doesn't affect (old-)stable.
> 
> Your package is only blocked because the arch:all binary package(s)
> aren't built on a buildd. Unfortunately the Debian infrastructure
> doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will
> shortly do a no-changes source-only upload to DELAYED/15, closing this
> bug. Please let me know if I should delay or cancel that upload.


Thanks!

I'll make an upload later today with some small fixes, so you can cancel it.

Cheers,

-- 
nodens

Bug#768073: ITP: lxd - The Linux Container Daemon

[Clément Hermann]

Hi,

On 27/09/2020 20:23, Kurt Kremitzki wrote:
> Hello,
> 
> With the release of LXD 4.6 [1], it should now be a lot easier for it to be 
> brought to Debian:
> 
> "Dqlite changes
> 
> Shortly after LXD 4.5 was released, a major change was made to upstream 
> dqlite.
> 
> Rather than relying on our fork of sqlite3 which was adding some hooks used 
> to 
> intercept filesystem writes and replicating to other nodes, we are now using 
> a 
> different approach to get VFS access from a standard sqlite3.
> 
> While invisible to users, this should help packagers a fair bit by removing 
> two custom dependencies of LXD, that custom sqlite3 and libco.
> 
> LXD with dqlite can now use any standard sqlite3 of version 3.25 or higher."
> 
> [1] https://discuss.linuxcontainers.org/t/lxd-4-6-has-been-released/8981

That was indeed on the radar after discussions with upstream at FOSDEM
and we were in the loop. Thanks for keeping the subscribers of this bug
informed! (and sorry I didn't do it myself).

And now, dqlite is actually in Debian:
https://tracker.debian.org/pkg/dqlite (thanks Laszlo!).

I'm happy to say I can now resume working on LXD deps and lxd itself.

We might have a chance to see LXD in the next release after all! \o/

Cheers,


-- 
nodens

Bug#971299: onionshare: Switch to python3-pycryptodome

[Clément Hermann]

Hi,

Control: block 971299 with 886291
thanks

On 28/09/2020 23:29, Sebastian Ramacher wrote:
> Source: onionshare
> Version: 2.2-2
> Severity: important
> Tags: sid bullseye
> Usertags: pycrypto
> 
> Dear maintainer,
> 
> onionshare currently Build-Depends or Depends on python3-crypto from
> PyCrypto. This project is no longer maintained and PyCryptodome
> (https://www.pycryptodome.org/en/latest/) provides a drop in
> replacement. Please switch to python3-pycryptodome. I'd like to
> remove python-crypto before the release of bullseye.


As far as I understand it, pycryptodome *can* be a drop-in replacement
usually, but not currently in Debian since it doesn't install in Crypto
but Cryptodomex namespace (#886291).

Are there any plan to change it when python3-crypto is removed or before ?

Of course, we can patch onionshare to import cryptodomex, but that patch
would be debian-only then… Upstream already expect pycryptodome as
Crypto module.

Take care,

-- 
nodens

Bug#905068: ITP: libdqlite - High-availability SQLite with Raft consensus (Was: Re: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications)

[Clément Hermann]

retitle -1 ITP: libdqlite - High-availability SQLite with Raft consensus
thanks


On Tue, 31 Jul 2018 11:24:36 +0800 (CST) "Clement Hermann"  
wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Clement Hermann 
> 
> * Package name: golang-github-canonicalltd-dqlite
>   Version : 0.0~git20180507.e5bc052-1
>   Upstream Author : Canonical Ltd
> * URL : https://github.com/CanonicalLtd/dqlite
> * License : Apache-2.0
>   Programming Lang: Go
>   Description : Distributed SQLite for Go applications
> 
>  dqlite can be used to replicate a SQLite database across a cluster,
>  using the Raft algorithm.
>  - No external processes needed: dqlite is just a Go library, you link
>it to your application exactly like you would with SQLite.
>  - Full support for transactions
>  - No need for statements to be deterministic (e.g. you can use time())
> 
> This is a dependency of LXD 3 (ITP: #768973) and will be maintained under the
> Go team umbrella.

New description

* Package name: libdqlite
   Version : 1.4.0
   Upstream Author : Canonical Ltd
 * URL : https://github.com/CanonicalLtd/dqlite
 * License : LGPLv3 with linking exception
   Programming Lang: C
   Description : High-availability SQLite with Raft consensus
 

 dqlite is a C library that implements an embeddable and replicated SQL 
database 
 engine with high-availability and automatic failover.

 "dqlite" stands for "distributed SQLite", meaning that dqlite extends SQLite 
with 
 a network protocol that can connect together various instances of your 
application
 and have them act as a highly-available cluster, with no dependency on 
external databases.
 
 Design higlights:
 - Asynchronous single-threaded implementation using libuv as event loop.
 - Custom wire protocol optimized for SQLite primitives and data types.
 - Data replication based on the Raft algorithm and its efficient C-raft 
implementation.

Bug#951546: timewarrior: Bash completion doesn't work for timew

[Clément Hermann]

Package: timewarrior
Version: 1.2.0-1
Severity: normal
Tags: patch

Hi,

bash completion doesn't work, because the completion script is installed
in /usr/share/bash-completion/ instead of
/usr/share/bash-completion/completions/.

It would probably be better to use dh_bash-completion.

Please find a patch attached :)

(note that it will trigger a lintian warning, I'm disscussing this in
https://salsa.debian.org/lintian/lintian/merge_requests/292).

Cheers,

nodens

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages timewarrior depends on:
ii  libc62.29-10
ii  libgcc-s1 [libgcc1]  10-20200211-1
ii  libgcc1  1:10-20200211-1
ii  libstdc++6   10-20200211-1

Versions of packages timewarrior recommends:
ii  taskwarrior  2.5.1+dfsg-8

Versions of packages timewarrior suggests:
ii  python  2.7.17-2

-- no debconf information
>From 3a78ef9487e71705e4641789a9d04a90e28a1711 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Hermann?= 
Date: Fri, 14 Feb 2020 17:24:27 +0100
Subject: [PATCH] Fix bash-completion installation path

- removes dh-auto-install override
- adds --with-bash-completion to dh call
--adds d/timewarrior.bash-completion control file
- adds bash-completion to build-depends
---
 debian/control | 2 +-
 debian/rules   | 7 +--
 debian/timewarrior.bash-completion | 1 +
 3 files changed, 3 insertions(+), 7 deletions(-)
 create mode 100644 debian/timewarrior.bash-completion

diff --git a/debian/control b/debian/control
index 5984306..f30e6ba 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: utils
 Priority: optional
 Maintainer: Debian Tasktools Packaging Team 
 Uploaders: Gordon Ball 
-Build-Depends: debhelper-compat (= 12), cmake, git, python
+Build-Depends: debhelper-compat (= 12), cmake, git, python, bash-completion
 Standards-Version: 4.4.1
 Homepage: https://timewarrior.net/
 Vcs-Browser: https://salsa.debian.org/tasktools-team/timew
diff --git a/debian/rules b/debian/rules
index 02f9548..611059d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,17 +6,12 @@ TAG_VERSION := $(shell echo $(DEB_VERSION_UPSTREAM) | tr '~' 
'.' | sed -e 's/+[d
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
-   dh $@
+   dh $@ --with bash-completion
 
 override_dh_auto_configure:
find . -type f -exec sed -i '1s|^#!/usr/bin/env 
python|#!/usr/bin/python|' {} \;
dh_auto_configure
 
-override_dh_auto_install:
-   dh_auto_install
-   mkdir -p debian/timewarrior/usr/share/bash-completion
-   cp completion/timew-completion.bash 
debian/timewarrior/usr/share/bash-completion/timew
-
 override_dh_installchangelogs:
dh_installchangelogs -k ChangeLog
 
diff --git a/debian/timewarrior.bash-completion 
b/debian/timewarrior.bash-completion
new file mode 100644
index 000..5f2d031
--- /dev/null
+++ b/debian/timewarrior.bash-completion
@@ -0,0 +1 @@
+completion/timew-completion.bash timew
-- 
2.25.0

Bug#951484: bash-completion: please provide dh-sequence-bash-completion virtual package

[Clément Hermann]

Package: bash-completion
Version: 1:2.10-1
Severity: wishlist

Hi,

bash-completion dh sequence addon could benefit from providing the
virtual package dh-sequence-bash-completion.

It would allow to just add dh-sequence-bash-completion to the
build-depends of a package instead of adding bash-completion as a
build-dep and --with-bash-completion to dh call in d/rules.

Cheers,

nodens

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#951214: flatpak: text display issue in file dialogs when using "Roboto" font

[Clément Hermann]

Package: flatpak
Version: 1.6.1-1
Severity: normal

Hi,

I use Roboto Regular font for most of my interface (gnome).

When opening a file dialog in flatpak apps, All text in the dialog
appear as squares. It works if I switch to Cantarell Regular (or, apparently, 
RobotoRegular Regular).

Steps to reproduce:

- Install Roboto fonts - (fonts-roboto-unhinted and fonts-roboto-hinted,
in my case).
- use gnome-tweaks to change interface text font to Roboto
  Regular
- open gedit has a flatpak (org.gnome.gedit)
- try to open a file

While leaving the file dialog open, one can change font to cantarell or
robotoregular (any variant), and it works fine.

It might be a bug in the Roboto package.

Cheers,

nodens

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages flatpak depends on:
ii  adduser3.118
ii  bubblewrap 0.4.0-1
ii  libappstream-glib8 0.7.16-1
ii  libarchive13   3.4.0-1+b1
ii  libc6  2.29-10
ii  libdconf1  0.34.0-2
ii  libfuse2   2.9.9-2
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-2
ii  libglib2.0-0   2.62.4-2
ii  libgpgme11 1.13.1-6
ii  libjson-glib-1.0-0 1.4.4-2
ii  libostree-1-1  2019.6-1
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libseccomp22.4.2-2
ii  libsoup2.4-1   2.68.2-1
ii  libsystemd0244.2-1
ii  libxau61:1.0.8-1+b2
ii  libxml22.9.4+dfsg1-8
ii  xdg-dbus-proxy 0.1.2-1

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.24-1
ii  gtk-update-icon-cache3.24.13-1
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   244.2-1
ii  p11-kit  0.23.20-1
ii  policykit-1  0.105-26
ii  shared-mime-info 1.10-1
ii  xdg-desktop-portal   1.6.0-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.6.0-1

Versions of packages flatpak suggests:
ii  avahi-daemon  0.7-5

-- no debconf information

Bug#949575: RFP: bandwhich -- Terminal bandwidth utilization tool

[Clément Hermann]

Package: wnpp
Severity: wishlist

* Package name: bandwhich
  Version : 0.10.0
  Upstream Author : Aram Drevekenin 
* URL : https://github.com/imsnif/bandwhich
* License : MIT
  Programming Lang: Rust
  Description : Terminal bandwidth utilization tool

Bandwhich is a CLI utility for displaying current network utilization by
process, connection and remote IP/hostname, written in Rust.
.
It works by sniffing a given network interface and records IP packet
size, cross referencing it with the /proc filesystem (or lsof). It is
responsive to the terminal window size, displaying less info if there is
no room for it. It will also attempt to resolve ips to their host name
in the background using reverse DNS on a best effort basis.

Dear Rust team,

Please consider adding this to the rust packages library in Debian :)

Cheers,

nodens

Bug#948318: openssh-server: Unable to restart sshd restart after upgrade to version 8.1p1-2

[Clément Hermann]

On Sat, 18 Jan 2020 23:55:10 +0100 Marco d'Itri  wrote:
> On Jan 07, Guillaume Brocker  wrote:
> 
> > janv. 06 11:10:46 sigismund sshd[27148]: /usr/sbin/sshd: 
> > /lib/i386-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required 
> > by /usr/sbin/sshd)
> Does purging libxcrypt1 make it work?
> 
> If you can confirm this then I will make the next libcrypt1 conflict 
> with it. I did not expect for libxcrypt1 to be still around since it was 
> not shipped in buster and nobody really ever used it.

I have the same issue. The symbol is in the file provided by libcrypt1, 
however, it is in /usr/lib.

what I have in /lib is:

```
ls -l /lib/x86_64-linux-gnu/libcrypt.so.1
lrwxrwxrwx 1 root root 16 déc.  27 20:31 /lib/x86_64-linux-gnu/libcrypt.so.1 -> 
libcrypt-2.25.so
ls -l /lib/x86_64-linux-gnu/libcrypt-2.25.so 
-rw-r--r-- 1 root root 39272 déc.   2  2017 libcrypt-2.25.so

```

The version (2.25) looks like it's a leftover from an older libc6 package ? no 
package provides libcrypt-2.25.so as a file. libcrypt has been disabled in 
libc6 2.29-4. 
It looks like a leftover or something. Removing the file and running ldconfig 
fixes the issue for me (but now I wonder if I have other leftover files like 
this…).

Anyway, I think the bug, if it's not a local problem, isn't in openssh-server, 
but more in libc6, and an old version...

Cheers,

-- 
nodens

Bug#948335: New upstream

[Clément Hermann]

Hi,

Le January 7, 2020 1:03:14 PM UTC, Bastian Germann  a écrit 
:
>Package: golang-bindata
>Version: 3.0.7+git20151023.72.a0ff256-3
>Severity: normal
>
>The jteeuwen/go-bindata repository is not maintained anymore, according
>to its README.md.


Thanks for reporting this !

>Please switch to https://github.com/go-bindata/go-bindata

According to https://github.com/jteeuwen/discussions/issues/2, it's unclear if 
that's actually the "new upstream", or even maintained (there are also merges 
after this discussion). 

So while it's clear the upstream should be changed, the question is which 
upstream ?

Cheers

-- 
nodens

Bug#935364: debhelper: dh_clean doesn't print info about files listed in debian/clean being removed, even with DH_VERBOSE

[Clément Hermann]

On 01/09/2019 08:57, Niels Thykier wrote:
> Control: tags -1 moreinfo unreproducible
> 
> On Thu, 22 Aug 2019 00:10:08 +0200 =?utf-8?q?Cl=C3=A9ment_Hermann?=
>  wrote:
>> Package: debhelper
>> Version: 12.5.3
>> Severity: normal
>>
>> Hi,
>>
>> while working on a package, I had trouble finding out why some file were
>> disapearing without any reason and no entry in build log, despite using
>> DH_VERBOSE.
>>
>> Looking at the code, it's because
>> glob_expand_error_handler_silently_ignores is used, I guess to avoid
>> warning about not being able to remove non-existing files.
>>

> 
> 
> Hi,
> 
> I cannot reproduce the issue from the description.  When I run dh_clean
> with verbose it lists files/directories being removed.
> 
> """
>> dh_clean -v foo
>> rm -f debian/debhelper-build-stamp
>> rm -rf debian/.debhelper/
>> rm -f -- debian/debhelper.substvars debian/dh-systemd.substvars foo 
>> debian/files
>> ^^^
>> rm -fr -- debian/debhelper/ debian/tmp/ debian/dh-systemd/
>> [...]
> """
> 
> (see ^^^ line)
> 
> Can you provide a concrete example where it does not work?


Hi,

Apparently I missed the file when looking at my buildd logs. I tried to
reproduce the issue, and it's actually here, just lost in the middle of
the "rm" line. I probably was so confused about this file disappearing I
wasn't able to "grep" properly (or even to set DH_VERBOSE env var) ;)

Sorry for the noise.


Cheers,

nodens

Bug#935364: debhelper: dh_clean doesn't print info about files listed in debian/clean being removed, even with DH_VERBOSE

[Clément Hermann]

Package: debhelper
Version: 12.5.3
Severity: normal

Hi,

while working on a package, I had trouble finding out why some file were
disapearing without any reason and no entry in build log, despite using
DH_VERBOSE.

Looking at the code, it's because
glob_expand_error_handler_silently_ignores is used, I guess to avoid
warning about not being able to remove non-existing files.

It would be nice if dh_clean would print something about files being
removed, at least when DH_VERBOSE=1. IMO, warnings about
non-existing files are OK if DH_VERBOSE is used.

What do you think? I didn't really look at a possible patch yet, I
wanted to discuss it first.

Cheers,

-- 
nodens

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.5.0-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.13-1
ii  file 1:5.37-5
ii  libdpkg-perl 1.19.7
ii  man-db   2.8.6.1-1
ii  perl 5.28.1-6
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201901

-- no debconf information

Bug#842921: RFP: libextutils-hascompiler-perl -- check for the presence of a compiler

[Clément Hermann]

Hi,

closing this, since it was packaged after all (#932485). Sorry, while
packaging it I failed to check if there was already an RFP.

Cheers,

nodens.

Bug#932409: libconfig-model-dpkg-perl: When the installed debian-policy is older than the hardcoded one, the error message is unhelpful

[Clément Hermann]

On 21/07/2019 13:56, Dominique Dumont wrote:
> On Thu, 18 Jul 2019 18:45:26 -0300 =?utf-8?q?Cl=C3=A9ment_Hermann?= 
>  wrote:
>> while it is true that there is an issue on my system (I should have made
>> sure the latest policy version was installed), the message is quite
>> bizarre and unhelpful ;)
>>
>> Idealy, we whould check if the installed version is older than the
>> hardcoded version and warn the user about the outdated local version and
>> not ask him to check for "upgrades" in policy ;)
> 
> Fair enough.
> 
> Next version will show this kind of message in a similar situation:
> 
> Warning in 'control source Standards-Version': Current standards version 
> '1000.1.1' is newer than lintian version (4.4.0). Please check your system
> 
> Is this fine with you ?

That's perfectly fine with me, thanks for taking care of this! :)

Cheers,

-- 
nodens

Bug#932495: ITP: libextutils-makemaker-dist-zilla-develop-perl -- Perl module creating bare-bones Makefile.PL files for use with dzil

[Clément Hermann]

Package: wnpp
Owner: Clément Hermann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libextutils-makemaker-dist-zilla-develop-perl
  Version : 0.03
  Upstream Author : Jesse Luehrs 
* URL :
https://metacpan.org/release/ExtUtils-MakeMaker-Dist-Zilla-Develop
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module creating bare-bones Makefile.PL files
for use with dzil

Dist::Zilla makes developing modules much easier by generating all kinds of
boilerplate files, saving authors from having to write them by hand, but in
some cases this can make developing more inconvenient. The most prominent
example of this is with Makefile.PL files - although the majority of
distributions can be hacked on just by editing the files in a source control
checkout and using prove for testing, for some this isn't sufficient. In
particular, distributions which use an auto-generated test suite and
distributions which use XS both need special handling at build time before
they will function, and with Dist::Zilla, this means running dzil build and
rebuilding after every change. This is tedious!

ExtUtils::MakeMaker::Dist::Zilla::Develop provides an alternative. Create a
minimal Makefile.PL in source control which handles just enough
functionality
for basic development (it can be as minimal as just what is in the
/SYNOPSIS,
but can also contain commands to generate your test suite, for example), and
tell Dist::Zilla to replace it with a real Makefile.PL when you're actually
ready to build a real distribution. To do this, make sure you're still using
the MakeMaker|Dist::Zilla::Plugin::MakeMaker plugin, either directly or
through a pluginbundle like @Basic|Dist::Zilla::PluginBundle::Basic, and add
the exclude_filename = Makefile.PL option to your dist.ini where you use
[GatherDir].

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#932494: ITP: libextutils-hascompiler-perl -- Perl Module checking the presence of a compiler

[Clément Hermann]

Package: wnpp
Owner: Clément Hermann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libextutils-hascompiler-perl
  Version : 0.021
  Upstream Author : Leon Timmermans 
* URL : https://metacpan.org/release/ExtUtils-HasCompiler
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl Module checking the presence of a compiler

ExtUtils::HasCompiler tries to check if the current system is capable of
compiling, linking and loading an XS module.

This module is mainly packaged to avoid patching the build system of
modules using it at build time.

Notice: this is an early release, interface stability isn't guaranteed yet.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#932485: ITP: libextutils-hascompiler-perl -- Perl Module checking the presence of a compiler

[Clément Hermann]

Package: wnpp
Owner: Clément Hermann 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libextutils-hascompiler-perl
  Version : 0.021
  Upstream Author : Leon Timmermans 
* URL : https://metacpan.org/release/ExtUtils-HasCompiler
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl Module checking the presence of a compiler

ExtUtils::HasCompiler tries to check if the current system is capable of
compiling, linking and loading an XS module.

This module is mainly packaged to avoid patching the build system of
modules using it at build time.

Notice: this is an early release, interface stability isn't guaranteed yet.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Bug#932409: libconfig-model-dpkg-perl: When the installed debian-policy is older than the hardcoded one, the error message is unhelpful

[Clément Hermann]

Package: libconfig-model-dpkg-perl
Version: 2.122
Severity: normal

While running dh-make-perl (0.106, not uploaded yet) for a new package,
with an out-of-date policy installed (4.3.0 instead of 4.4.0), I got the
following error:

```
Warning in 'source Standards-Version': Current standards version is '4.3.0'. 
Please read https://www.debian.org/doc/debian-policy/upgrading-checklist.html 
for the changes that may be needed on your package to upgrade it from standard 
version '4.4.0' to '4.3.0'.

Offending value: '4.4.0'
```

while it is true that there is an issue on my system (I should have made
sure the latest policy version was installed), the message is quite
bizarre and unhelpful ;)

Idealy, we whould check if the installed version is older than the
hardcoded version and warn the user about the outdated local version and
not ask him to check for "upgrades" in policy ;)

Cheers,

-- 
nodens

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libconfig-model-dpkg-perl depends on:
ii  libapt-pkg-perl0.1.36+b1
ii  libarray-intspan-perl  2.003-1
ii  libconfig-model-backend-yaml-perl  2.133-2
ii  libconfig-model-perl   2.133-1
ii  libexporter-lite-perl  0.08-1
ii  liblog-log4perl-perl   1.49-1
pn  libmodule-corelist-perl
ii  libmouse-perl  2.5.6-1+b1
ii  libparse-recdescent-perl   1.967015+dfsg-2
ii  libsoftware-licensemoreutils-perl  1.004-1
ii  libtext-autoformat-perl1.74-2
ii  libtext-levenshtein-damerau-perl   0.41-1
ii  liburi-perl1.76-1
ii  libwww-perl6.36-2
ii  libyaml-perl   1.27-1
ii  licensecheck   3.0.31-3
ii  lintian2.15.0
ii  perl   5.28.1-6

Versions of packages libconfig-model-dpkg-perl recommends:
ii  libconfig-model-tkui-perl  1.369-2

libconfig-model-dpkg-perl suggests no packages.

-- no debconf information

Bug#768073: ITP: lxd -- The Linux Container Daemon

[Clément Hermann]

Hi,

First, sorry for the late reply. A mail filter caught this message
before I had the chance to read it.

On 14/12/2018 12:15, Harald Dunkel wrote:
> Hi folks,
> 
> how good are chances to get LXD into Buster?

As much as it pains me to say so, not very good at the moment, with the
soft freeze coming up in February.

The biggest issue is, starting with lxd3, Canonical decided to implement
replication in sqlite, which is fine, but since they needed it soon and
know that it would take a while for inclusion, they rely on a patched
version of sqlite.

It doesn't affect Ubuntu since Ubuntu is actually using Snap now to
distribute even the packaged version of LXD, and there having a patched
version is fine, since it's only in the snap context. However, we can't
patch sqlite this way in Debian.

you can check the ITP on golang-github-canonicalltd-dqlite [1] for more
info on this discussion. Sadly it's stalled currently (and the bandwidth
I can use to work on this packaging is quite low at the moment).


[1] - https://bugs.debian.org/905068

Cheers,

-- 
nodens

Bug#916202: golang-github-miekg-mmark: upstream project moved - very old release in the archive

[Clément Hermann]

Source: golang-github-miekg-mmark
Severity: normal

Hi,

it was reported on the #debian-golang channel that this package's
upstream has moved.
Indeed, the README.md on https://github.com/miekg/mmark warns:
> !THIS REPOSITORY IS DEPRECATED!
>
> A new version of mmark can be found at
> https://github.com/mmarkdown/mmark. Its new main site is
> https://mmark.nl.

I guess we need a new source package golang-github-mmarkdown-mmark,
producing binaries replacing/conflicting/providing the ones from
golang-github-miekg-mmark

Cheers,

nodens
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#915123: goaccess: New upstream release 1.3 available

[Clément Hermann]

Package: goaccess
Version: 1:1.2-4
Severity: wishlist
Tags: patch

Hi,

There is a new upstreame release of goaccess (1.3).
Since I wanted to test it, I made an updated package myself.

Please check https://salsa.debian.org/debian/goaccess/merge_requests/1
on salsa, review, merge, and upload if it's OK :)

Cheers,

nodens

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages goaccess depends on:
ii  libbz2-1.01.0.6-9
ii  libc6 2.28-1
ii  libgeoip1 1.6.12-1
ii  libncurses6   6.1+20181013-1
ii  libtinfo6 6.1+20181013-1
ii  libtokyocabinet9  1.4.48-12
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages goaccess recommends:
ii  geoip-database20181108-1
ii  geoip-database-extra  20181108-1

goaccess suggests no packages.

-- no debconf information

Bug#905065: ITP: golang-github-canonicalltd-raft-membership -- Extension of the Hashicorp raft package to easily join and leave a cluster

[Clément Hermann]

Hi!

On 26/10/2018 15:41, Pierre-Elliott Bécue wrote:
> Le mardi 31 juillet 2018 à 11:24:36+0800, Clement Hermann a écrit :
>> Package: wnpp
>> Severity: wishlist
>> Owner: Clement Hermann 
>>
>> * Package name: golang-github-canonicalltd-raft-membership
>>   Version : 0.0~git20180413.3846634-1
>>   Upstream Author : Canonical Ltd
>> * URL : https://github.com/CanonicalLtd/raft-membership
>> * License : Apache-2.0
>>   Programming Lang: Go
>>   Description : Extension of the Hashicorp raft package to easily join 
>> and leave a cluster
>>
>>  github-canonicalltd-raft-membership provides the raftmembership package, 
>> which contains an
>>  extension of the raft Go package (https://github.com/hashicorp/raft) from
>>  Hashicorp to easily make a node join or leave a cluster.
>>
>> This is a dependency of LXD 3 (ITP: #768973) and will be maintained under the
>> Go team umbrella.
> 
> Hi,
> 
> raft-test being in Debian[1], and the salsa repository for raft-membership
> looking close to ready[2], do you require anything else to upload this
> package?Hi !
> 

I did open this ITP, however Shengjing Zhu was working on it during
DebCamp. IIRC it only needs a sponsor at this point. Please, feel free
to take over, review and upload ! :)

Cheers,

-- 
nodens

Bug#904261: [pkg-go] Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

On 9/14/18 3:11 PM, Martín Ferrari wrote:
> On 12/09/18 15:59, Martín Ferrari wrote:
> 
>>> I'm not sure it warrants an upload right away, but it would be nice to
>>> have it before debhelper is updated.
>>>
>>> Could anyone sponsor that ?
>>
>> I would be happy to, but I have not been following dh-golang devel much
>> to decide if we sHould upload now.. Any other opinion?
> 
> I have just uploaded it.
> 
> 

Thanks !

-- 
nodens

Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications

[Clément Hermann]

Hey,

thanks for the quick response!

On 9/14/18 2:24 PM, Free Ekanayaka wrote:
> Hey there,
> 
> I do have the intention to submit the patches upstream, but since 1) the
> work is not fully complete 2) SQLite authors are *extremely*
> conservative when it comes to contributions, that won't happen any time
> soon.

Totally understand.

> Is there anything that prevents you from going with second option? You
> can grab:
> 
> https://github.com/CanonicalLtd/sqlite/releases/tag/version-3.24.0%2Breplication3
> 
> and package it as a new sqlite-replication library. It's fairly safe to
> have it Conflict and Replace the regular sqlite package, since the
> patches onlly add things, they don't modify behavior or change APIs.

That's good to know (the "add only")!

>From the top of my mind, it should be possible, but I need to recheck
the policy, see how other forks do it, and ask the current maintainer of
sqlite3 how they feel about it. Especially as I'm not so familiar with
shared library packaging ^^

I guess normally, it would involve providing a virtual package and
changing the original sqlite3 to do the same. At least that's how it's
done for Mysql/mariadb for instance, but here there is no server binary
in sqlite3, so the situation is a bit different.

If the implementation used a different name, that would allow to have
both installed. Of course, That involves patching the go bindings as
well, and it would have to change again once the patches to sqlite3 are
accepted upstream. If it can indeed take a long time, maybe it's worth it ?


Cheers,

-- 

nodens

Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications

[Clément Hermann]

Hi!


On Tue, 31 Jul 2018 14:00:12 -0400 =?UTF-8?Q?St=C3=A9phane_Graber?=
 wrote:

> On Tue, Jul 31, 2018 at 10:10 AM Free Ekanayaka  wrote:
> >
> > Hey,
> >
> > I would think that Stéphane will want to backport these changes to the
> > 3.0.x series, as they improve performance considereably. It wouldn't be
> > a big change for the LXD code itself, since this is mostly "backend"
> > code.
>
> Yes, we will be backporting the switch to the new dqlite
> implementation in the 3.0.x branch, should be in 3.0.2.
>


And I see it's indeed the case. Thanks!


Now the only issue in Debian context is that dqlite depends on a patched
sqlite3...


It there any plan to upstream those patches ? Or at least treating that
as a proper fork, with a different name ? The former would be better. of
course, but the later could at least make sure we can package it
separately (with conflicts/provides dance)... And the later is a way to
wait until patches are approved upstream.


As I see LXD packaging in Ubuntu is now replaced by snaps [1], I guess
it's not really necessary for Canonical, but that would really help the
packaging effort in Debian and other distros.


[1] https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1788040

Cheers,


-- 

nodens

Bug#908656: debhelper: Please include note about third-party tool dh-golang changes in the compatibility notes

[Clément Hermann]

On 9/12/18 6:38 PM, Niels Thykier wrote:
> Clément Hermann:
>>
>> On 12/09/2018 11:13, Clément Hermann wrote:
>>> Package: debhelper
>>> Version: 11.3.5
>>> Severity: wishlist
>>> Tags: patch
>>>
>>> Hi,
>>>
>>> as discussed in #904261, we'd like to have an item in the
>>> compatibility notes about a non-backward compatible change in dh-golang.
>>>
>>> A merge request will be done on salsa with a proposed text as soon as I have
>>> a bug number. I'll include the link in a follow-up e-mail.
>>
>> Actually, I forgot that I'm not a DD and I can't push anything in the
>> repo... I created a branch on a fork in my personal namespace on salsa:
>>
>> https://salsa.debian.org/nodens-guest/debhelper/tree/document_dh_golang_changes_compat12
>>
>>
>> Cheers,
>>
> 
> Hi,
> 
> Could you please open a MR request for this in salsa? :)
> 

Oh, yes. I wasn't sure how to do that from another project but RTFM'ing
a bit showed me how :)

It's at https://salsa.debian.org/debian/debhelper/merge_requests/10 in
cas you missed the notification.

Thanks !

-- 
nodens

Bug#904261: [pkg-go] Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

On 10/09/2018 12:47, Clément Hermann wrote:
> The change is implemented (see [1]), and Niels is OK to add something to
> the compatibility notes of debhelper, as long as we provide the text and
> open a bug.

This is #908656.

> So, if no one objects, I'll merge the branch, add the relevant changelog
> entries and upload^Wask for someone to upload. ;)
> 
> (and I'll take care of the bug creation on debhelper meanwhile).

And it has been merged.

I'm not sure it warrants an upload right away, but it would be nice to
have it before debhelper is updated.

Could anyone sponsor that ?

Cheers,

-- 
nodens

Bug#908656: debhelper: Please include note about third-party tool dh-golang changes in the compatibility notes

[Clément Hermann]

On 12/09/2018 11:13, Clément Hermann wrote:
> Package: debhelper
> Version: 11.3.5
> Severity: wishlist
> Tags: patch
> 
> Hi,
> 
> as discussed in #904261, we'd like to have an item in the
> compatibility notes about a non-backward compatible change in dh-golang.
> 
> A merge request will be done on salsa with a proposed text as soon as I have
> a bug number. I'll include the link in a follow-up e-mail.

Actually, I forgot that I'm not a DD and I can't push anything in the
repo... I created a branch on a fork in my personal namespace on salsa:

https://salsa.debian.org/nodens-guest/debhelper/tree/document_dh_golang_changes_compat12


Cheers,

-- 
nodens

Bug#908656: debhelper: Please include note about third-party tool dh-golang changes in the compatibility notes

[Clément Hermann]

Package: debhelper
Version: 11.3.5
Severity: wishlist
Tags: patch

Hi,

as discussed in #904261, we'd like to have an item in the
compatibility notes about a non-backward compatible change in dh-golang.

A merge request will be done on salsa with a proposed text as soon as I have
a bug number. I'll include the link in a follow-up e-mail.

Cheers,

nodens

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  0.042-1
ii  dpkg 1.19.0.5+b1
ii  dpkg-dev 1.19.0.5
ii  dwz  0.12-2
ii  file 1:5.33-3
ii  libdpkg-perl 1.19.0.5
ii  man-db   2.8.4-2
ii  perl 5.26.2-6
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201801

-- no debconf information

Bug#904261: [pkg-go] Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

On 16/08/2018 17:37, Clément Hermann wrote:
> On 16/08/2018 17:13, Clément Hermann wrote:
>> On 16/08/2018 16:26, Martín Ferrari wrote:
> 
>>> We could also change the default in the next debhelper compat mode;
>>> dunno how this is normally handled, but it would be good to coordinate
>>> so this change is documented.. In that case it might be even be sensible
>>> to add the switch in the code now.
>> That's a great idea. It looks easy enough to add the switch in the code,
>> but I couldn't find how those things are usually handled for modules
>> outside debhelper itself. I'll ask the perl team, apparently that's
>> something they did in the past.
> 
> It's actually a bad example, as it's part of debhelper and not an
> external module.
> 
> I'll send an email to the debhelper team and ask directly (CC-ing this BR).
> 
> Cheers,
> 

The change is implemented (see [1]), and Niels is OK to add something to
the compatibility notes of debhelper, as long as we provide the text and
open a bug.

So, if no one objects, I'll merge the branch, add the relevant changelog
entries and upload^Wask for someone to upload. ;)

(and I'll take care of the bug creation on debhelper meanwhile).

Cheers,

[1] https://salsa.debian.org/go-team/packages/dh-golang/merge_requests/3

-- 
nodens

Bug#904261: changing a default behaviour in dh-golang for next compat level

[Clément Hermann]

On 18/08/2018 11:03, Niels Thykier wrote:
> Clément Hermann:
>> How are we supposed to do this properly ? Not checking the compat level
>> and behaving accordingly, this is documented, but the communication
>> part: should we file a bug against debhelper too ?
>>
>> Or should we just add the switch in the code and document it in
>> dh-golang, without coordinating with debhelper itself ?
>>
>> Thanks for any insights!
>>
>> Cheers,
>>
> 
> This is a very good question.  I think you should definitely document it
> in dh-golang itself (its manpage, etc.) regardless of whether it is
> documented in debhelper.

Of course. The change is documented in dh-golang itself. Or rather it
will be, because using debhelper compat level to decide what is the
default behaviour is an afterthought.
> Having thought about, I think I am open to having an item or two for
> third-party debhelper tooling in the compatibility notes.  I may have to
> revise that if I start getting a lot of third-party notes but I am not
> getting a lot of them.
> 
> Could you please file a bug or merge request on salsa against debhelper
> with the proposed text?

I will, as soon as it is fully implemented and has been tested a bit
more: it might need a few weeks before I have time to finalize this.

Thanks,

-- 
nodens

Bug#904261: changing a default behaviour in dh-golang for next compat level

[Clément Hermann]

Hi,

We (go team) are considering changing a default behaviour of dh-golang
in the next compat level (see #904261 for the specifics details). That
would be compat level 12, if I'm not mistaken.

How are we supposed to do this properly ? Not checking the compat level
and behaving accordingly, this is documented, but the communication
part: should we file a bug against debhelper too ?

Or should we just add the switch in the code and document it in
dh-golang, without coordinating with debhelper itself ?

Thanks for any insights!

Cheers,

-- 
nodens

Bug#904261: [pkg-go] Bug#904261: Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

On 16/08/2018 17:13, Clément Hermann wrote:
> On 16/08/2018 16:26, Martín Ferrari wrote:

>> We could also change the default in the next debhelper compat mode;
>> dunno how this is normally handled, but it would be good to coordinate
>> so this change is documented.. In that case it might be even be sensible
>> to add the switch in the code now.
> That's a great idea. It looks easy enough to add the switch in the code,
> but I couldn't find how those things are usually handled for modules
> outside debhelper itself. I'll ask the perl team, apparently that's
> something they did in the past.

It's actually a bad example, as it's part of debhelper and not an
external module.

I'll send an email to the debhelper team and ask directly (CC-ing this BR).

Cheers,

-- 
nodens

Bug#904261: [pkg-go] Bug#904261: Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

On 16/08/2018 16:26, Martín Ferrari wrote:
> Hi Clément,
> 
> On 13/08/18 11:01, Clément Hermann wrote:
> 
>> It happened after Debcamp, but here is the MR:
>> https://salsa.debian.org/go-team/packages/dh-golang/merge_requests/3
> 
> I just took a look. I left a small comment, but otherwise looks like a
> good solution, and I'd merge it.


Thanks! I have my doubts as well regarding the verbosity. My approach
while testing this was that I rather wanted to much information that not
enough.

That said, the original command didn't print anything for file
installation. It's probably only relevant to debug dh-golang itself, so
I'd be okay with removing that.

> We could also change the default in the next debhelper compat mode;
> dunno how this is normally handled, but it would be good to coordinate
> so this change is documented.. In that case it might be even be sensible
> to add the switch in the code now.
That's a great idea. It looks easy enough to add the switch in the code,
but I couldn't find how those things are usually handled for modules
outside debhelper itself. I'll ask the perl team, apparently that's
something they did in the past.

Cheers,


nodens

Bug#768073: [pkg-lxc-devel] Bug#768073: LXD packaging (and lxc-go plus a little bit of salsa)

[Clément Hermann]

On Tue, 10 Jul 2018 13:51:35 +0200 =?UTF-8?Q?Cl=c3=a9ment_Hermann?=
 wrote:
> On 10/07/2018 12:40, Jonathan Dowland wrote:
> > Hey folks,
>
> > I was pleased to see the last LXD dependency that we were tracking has
> > finally made it into Debian, so the path is likely clear for LXD itself
> > now (unless we need to catch up on some newer dependencies since the
> > analysis was done: https://wiki.debian.org/LXD)
>
>
> Actually, yes, it's a bit outdated. I'm currently working on the
> dependancies needed for 3.0.1, see this edited output of dh-make-golang
> estimate (some entries were false positive, due to different import path
> that'll need to be patched, or an apparently useless for in the case of
> go4):

People interested, please check the up-to-date list in the Gobby doc at
gobby.debian.org/Teams/Go/lxd-dep-packaging
(or the export at
https://gobby.debian.org/export/Teams/Go/lxd-dep-packaging). It contains
comments, #ITPs, etc.

To avoid packaging useless deps, we'll probably wait until 3.0.2 for a
proper LXD package (see comments in #905068).

Thanks to people already helping, with packaging or sponsoring!

Cheers,

--
nodens

Bug#904261: [pkg-go] Bug#904261: Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

On 22/07/2018 23:12, Clément Hermann wrote:
> Hi !
> 
> On 22/07/2018 16:49, Shengjing Zhu wrote:
>> On Sun, Jul 22, 2018 at 10:34 PM Michael Stapelberg
>>  wrote:
>>>
>>> There was a discussion on the pkg-go mailing list titled “honoring 
>>> DH_GOLANG_EXCLUDES for sources” a while ago, started by Clément (cc'ed).
>>>
>>
>> Ah, right, I thought I've read this before, but forget where.
>>
> 
> Yes, and life happened meanwhile, but it's still on my radar, and I
> definitely intend to have a proper look at it a submit a MR during
> DebCamp :)
> 

It happened after Debcamp, but here is the MR:
https://salsa.debian.org/go-team/packages/dh-golang/merge_requests/3

Cheers,

-- 
nodens

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Clément Hermann]

Hello,

On 03/08/2018 04:23, Sean Whitton wrote:
> Hello,
> 
> On Thu 02 Aug 2018 at 12:16PM +0800, Clément Hermann wrote:
> 
>> "as verbose as reasonably possible" seems incompatible with "maximally 
>> verbose
>> output", at least in some cases (golang packages come to mind).
>>
>> Would it be possible to clarify this ?
> 
> Yes.  Let's improve this.
> 
> Would s/maximally// be sufficient?  Or s/maximally/more/ ?
> 

IMO, s/maximally// would definitely fix the most pressing matter here,
that is, the fact that we have incompatible statements. I would
definitely be able to declare the go packages I maintain compliant, for
instance.

However, regarding the rest of the discussion on this bug, I agree more
guidance to the maintainer as to what is expected would be nice. But
that is a separate issue, I think.

How about resolving this one with this simple fix and opening a new one
to discuss making this paragraph better ?

Cheers,

nodens

Bug#905251: debian-policy: 4.9 paragraph is unclear (incompatibles statements)

[Clément Hermann]

Package: debian-policy
Version: 4.2.0.0
Severity: normal

Hi,

4.9 states:
The package build should be as verbose as reasonably possible.
This means that ``debian/rules`` should pass to the commands it
invokes options that cause them to produce maximally verbose
output.

"as verbose as reasonably possible" seems incompatible with "maximally verbose
output", at least in some cases (golang packages come to mind).

Would it be possible to clarify this ?

Cheers,

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debian-policy depends on:
ii  libjs-sphinxdoc  1.7.6-1

debian-policy recommends no packages.

Versions of packages debian-policy suggests:
ii  doc-base  0.10.8

-- no debconf information

Bug#905068: ITP: golang-github-canonicalltd-dqlite -- Distributed SQLite for Go applications

[Clément Hermann]

Hi,

On 31/07/2018 17:28, Free Ekanayaka wrote:
> Hello Clement,
> 
> dqlite upstream and LXD team member here.
> 
> Please note that dqlite is going through a bit of change, which I
> started to merge yesterday. So a few of the ITPs you have filed will no
> longer make sense.

Thanks a lot for the heads up!

> In a nutshell:
> 
> 1) https://github.com/CanonicalLtd/dqlite is now a C project
> 2) https://github.com/CanonicalLtd/go-dqlite has Go bindings
> 3) golang-github-canonicalltd-go-sqlite3 won't be necessary anymore
> 4) golang-github-canonicalltd-go-grpc-sql won't be necessary anymore
> 
> This will all be effective starting with LXD 3.4, to be released in 3
> weeks.
> 
> In LXD master, this will be effective once we land:
> 
> https://github.com/lxc/lxd/pull/4854
> 
> which should happen today or tomorrow at latest.

Good to know! I guess this won't change anything for 3.0.x series ?
That's what we're aiming for, since we want to package the LTS version:
the users needing cutting-edge version should use the snap IMO.

Cheers,

Bug#904722: sbuild-createchroot fails on btrfs subvolume with "directory non empty"

[Clément Hermann]

Package: sbuild
Version: 0.77.0-3
Severity: normal

Hi,

while following https://www.eyrie.org/~eagle/notes/debian/sbuild.html to
create a sbuild setup using btrfs, the sbuild creation on a btrfs
subvolume fails:

sbuild-createchroot --arch=amd64 --include=debhelper,eatmydata \
--components=main,contrib,non-free sid \
/var/lib/schroot.sbuild/sid-amd64-sbuild \
http://localhost:3142/debian
/var/lib/schroot.sbuild/sid-amd64-sbuild is not empty at 
/usr/bin/sbuild-createchroot line 278.

Of course, the subvolume was just created, and it is empty. However, you
can't rmdir the directory of a btrfs subvolume, so the check fails for
the wrong reason.

I believe this is due to the fix of #888710.

Maybe checking if this is a mountpoint / btrfs subvolume first ?

Cheers,

nodens
-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sbuild depends on:
ii  adduser 3.117
ii  libsbuild-perl  0.77.0-3
ii  perl5.26.2-6

Versions of packages sbuild recommends:
ii  autopkgtest  5.4.1
ii  debootstrap  1.0.106
ii  schroot  1.6.10-5

Versions of packages sbuild suggests:
pn  deborphan  
ii  kmod   25-1
ii  wget   1.19.5-1

-- no debconf information

Bug#904436: apparmor-notify: aa-notify is referring to wiki.ubuntu.com by default

[Clément Hermann]

Package: apparmor-notify
Version: 2.12-5
Severity: normal

aa-notify refers to wiki.ubuntu.com in the notifications.
We should make sure it's using a debian page instead - this is actually
configurable via message_footer in latest upstream version (used to be
hardcoded).

Cheers,


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages apparmor-notify depends on:
ii  libapparmor-perl  2.12-5
ii  libnotify-bin 0.7.7-3
ii  perl  5.26.2-6

apparmor-notify recommends no packages.

apparmor-notify suggests no packages.

-- no debconf information

Bug#904261: [pkg-go] Bug#904261: dh-golang: Don't install files listed in DH_GOLANG_EXCLUDES to dev pacakge

[Clément Hermann]

Hi !

On 22/07/2018 16:49, Shengjing Zhu wrote:
> On Sun, Jul 22, 2018 at 10:34 PM Michael Stapelberg
>  wrote:
>>
>> There was a discussion on the pkg-go mailing list titled “honoring 
>> DH_GOLANG_EXCLUDES for sources” a while ago, started by Clément (cc'ed).
>>
> 
> Ah, right, I thought I've read this before, but forget where.
> 

Yes, and life happened meanwhile, but it's still on my radar, and I
definitely intend to have a proper look at it a submit a MR during
DebCamp :)

-- 
nodens

Bug#768073: [pkg-lxc-devel] Bug#768073: LXD packaging (and lxc-go plus a little bit of salsa)

[Clément Hermann]

Hi !

On 10/07/2018 12:40, Jonathan Dowland wrote:
> Hey folks,

> I was pleased to see the last LXD dependency that we were tracking has
> finally made it into Debian, so the path is likely clear for LXD itself
> now (unless we need to catch up on some newer dependencies since the
> analysis was done: https://wiki.debian.org/LXD)


Actually, yes, it's a bit outdated. I'm currently working on the
dependancies needed for 3.0.1, see this edited output of dh-make-golang
estimate (some entries were false positive, due to different import path
that'll need to be patched, or an apparently useless for in the case of
go4):

github.com/lxc/lxd
github.com/juju/persistent-cookiejar
  github.com/frankban/quicktest
  github.com/CanonicalLtd/go-sqlite3
  github.com/mpvl/subtest
github.com/CanonicalLtd/go-grpc-sql
github.com/CanonicalLtd/raft-http
  github.com/CanonicalLtd/raft-test
  github.com/CanonicalLtd/raft-membership
github.com/CanonicalLtd/dqlite
  github.com/ryanfaerman/fsm
github.com/nbio/st
github.com/juju/gomaasapi
  github.com/juju/collections
  github.com/flosch/pongo2
  gopkg.in/CanonicalLtd/candidclient.v1
gopkg.in/juju/names.v2


The original plan was to start with lxd 2.0, but upstream is slow to
release a new 2.0 version, apparently they're too busy on 3.x and it's a
bit in the backlog. Since there were some merge mistakes in the past
that trigger new deps which are only fixed as patches in the Ubuntu
package, it means quite a lot of hunting work.

Also I injured both my hands meanwhile, which mean I couldn't spend much
time on it... But that's better now ! So I started working on 3.0 deps -
just yesterday, actually. I plan to work on this more during Debcamp,
hopefully I'll find time to at least fill all the ITP until then and
start working on some.

Help welcome, of course, I plan to put all those under the Go-team
umbrella. Feel free to fill ITPs and start working on any of them, just
make sure you're following the Go team new workflow for consistency with
other LXD deps [1].

> What's the status of the LXD package itself? 

Barely started. I have started to sort out build/test/runtime deps and
the like - it's not possible to simply get the ones from Ubuntu package
which work differently (bundling everything in a single source,
vendoring go-lxc, etc, which is not acceptable in Debian). Of course it
still makes sense to reproduce some stuff from the Ubuntu packaging, but
it's not a straightforward "port".

 > In the middle of this whole
> process Alioth went away and was replaced by Salsa. I found the
> following Salsa project but no packaging sources:
> 
>    https://salsa.debian.org/lxc-team/lxd

This project has been created empty during the migration.

Putting lxc-team in CC, as I can't initialize this repo myself (I only
have "developper" access, and I'd need to be master or owner.

Antonio, you're owner, could you please give the lxc-team group master
access ?


Cheers,


[1] https://go-team.pages.debian.net/workflow-changes.html

-- 
nodens

Bug#900769: pkg-perl-tools: dpt should warn about ~/.config/dpt.conf having priority over ~/.dpt.conf

[Clément Hermann]

Package: pkg-perl-tools
Version: 0.45
Severity: wishlist

Hi,

when trying to modify DPT_PACKAGES for some hacking on our meta.git, it
took me a while to figure out I had both ~/.dpt.conf and
~/.config/dpt.conf.

It's a trap! The vars in .config/dpt.conf have precedance over the ones
in ~/.dpt.conf.

It would be nice to have a warning about it when both exists, or at
least to mention that in the documentation.

Cheers,

nodens

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pkg-perl-tools depends on:
ii  curl   7.60.0-2
ii  debhelper  11.3.2
ii  devscripts 2.18.3
ii  dh-make-perl   0.100
ii  dpkg-dev   1.19.0.5
ii  git1:2.17.1-1
ii  git-buildpackage   0.9.9
ii  libdatetime-perl   2:1.49-1
ii  libdpkg-perl   1.19.0.5
ii  libgit-repository-perl 1.321-2
ii  libgitlab-api-v4-perl  0.08-1
ii  libipc-run-perl20180523.0-1
ii  libjson-xs-perl3.040-1
ii  libparse-debianchangelog-perl  1.2.0-12
ii  libproc-invokeeditor-perl  1.13-1
ii  librt-client-rest-perl 1:0.52-1
ii  libutf8-all-perl   0.024-1
ii  lintian2.5.88
ii  openssh-client [ssh-client]1:7.7p1-2
ii  perl   5.26.2-5
ii  pristine-tar   1.44
ii  quilt  0.65-1

Versions of packages pkg-perl-tools recommends:
ii  autodep8  0.12
ii  autopkgtest   5.3.1
ii  libconfig-model-dpkg-perl 2.111
ii  libconfig-model-perl  2.123-1
ii  libdebian-copyright-perl  0.2-4
ii  libfile-slurp-perl.19-6
ii  libmime-lite-perl 3.030-2
ii  libmodule-inspector-perl  1.05-2
ii  libnet-github-perl0.95-1
ii  libparallel-forkmanager-perl  1.19-1
ii  libsoap-lite-perl 1.27-1
ii  libterm-readline-gnu-perl 1.35-4
ii  libwww-mechanize-perl 1.88-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  lintian   2.5.88
ii  myrepos [mr]  1.20160123

Versions of packages pkg-perl-tools suggests:
ii  bc1.07.1-2+b1
ii  cdbs  0.4.156
pn  duck  
pn  moreutils 
pn  parallel  
pn  perl-depends  
ii  python3   3.6.5-3
pn  python3-launchpadlib  

-- no debconf information

Bug#871835: Call for help: review patches for debootstrap

[Clément Hermann]

Hi,

On 06/04/2018 04:01, Hideki Yamane wrote:
> Hi Perl people,
> 
>  Could you help us to check patches for embedded Perl code in debootstrap?
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871835
> 
>  It would improve to make debootstrap faster a lot, but we also afraid to
>  break something.
> 

Disclaimer:
- I'm a perl team member, but not a DD (nor a DM).
- I'm definitely not the best perl expert available in the team, but
hopefully other members can have a quick look too.
- I use debootstrap a lot, but it's the first time I actually looks at
its code and I might miss some stuff regarding that.

So, now that it's out of the way...

I had a look today. It looks good to me, at first glance I had concerns
(like using hash keys in boolean context without the exists function),
but everytime I checked further, it looked fine in context. That for the
perl part.

Other than that, if I may give my opinion, the commit messages make the
patches pretty self explanatory, and the portability concerns are
adressed (you still need grep -E but busybox can provide it, if your
grep doesn't implement it). The changes make perfect sense and the
performance boost is impresssive.

Barring any concern from someone more knowledgeable, I would definitely
apply this :)


Cheers,

-- 
nodens

Bug#890720: Request for new debian-switzerland list

[Clément Hermann]

Le February 17, 2018 10:48:38 PM UTC, Didier 'OdyX' Raboud  a 
écrit :
>Package: lists.debian.org
>Severity: wishlist
>
>The debian.ch association (recognized TO) uses the
>'commun...@lists.debian.ch'
>list since, on privately-owned infrastructure. It's General Assembly
>has
>concluded that a hosting of this low-traffic list would be much better
>on
>Debian.org infrastructure, hence this request
>
>Name: debian-switzerl...@lists.debian.org
>Rationale: debian.ch association & Swiss events' coordination traffic;
>should
> really be on Debian infrastructure if possible
>Short Description: Discussion list for Debian community in Switzerland
>Long Description: Discussion list for the Debian community - debian.ch
>Category: Other
>Subscription Policy: open
>Post Policy: open
>Web Archive: yes; please import the current commun...@lists.debian.ch
>list archive
>
>I hereby invite commun...@lists.debian.ch subscribers to voice their
>interest/support on the Debian bug for the creation of that list.
>
>OdyX, with hir debian.ch President hat
>___
>community mailing list
>commun...@lists.debian.ch
>https://lists.debian.ch/mailman/listinfo/community

Hi,

So, voicing interest and support !

(Sorry about top reply, hard to quote properly on a phone)

Cheers,

nodens
-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#888985: [pkg-go] RFS: irtt/0.9-1 [ITP] (#888985)

[Clément Hermann]

On 07/02/2018 11:39, Pete Heist wrote:
> 
> Ah, ok. IRTT has an API, but it's not published yet. I think a
> binary-only package may be better at this point, and a separate source
> package later when that’s ready? If you agree, could you suggest a
> simple, current binary package hosted on github as a good example?

You can have a single upstream package and produce 2 binary packages -
it's a bit more complicated though. Hence the example of Debian Code Search.


> Debian Code Search? Though its compat version is 8. I just liked how the
> debian directory is hosted right in the github repo, which brings me to
> another question...
> 
> Is it possible to maintain everything on github, or does it need to be
> on alioth, and if so, what is a good workflow for when I want to pull in
> changes from upstream for a new release?

Usually you would host the packaging on Alioth (soon salsa.debian.org),
and leave the upstream on github. Debian Code Search is a bit different
since it's specific to Debian. That doesn't change the usefulness of the
example for binary/api separation though.

Regarding the workflow, the easiest is to tag your releases on github
(you probably already do it anyway) and merge the upstream remote in the
upstream branch on alioth/salsa every time you want to release (the tag
isn't mandatory, it's just easier, and allows for a debian/watch file).

[snip]

> 
> Hrm, any idea why I'm seeing large differences in lintian output? I
> didn’t see any warnings before I posted, but I do see new ones after the
> .lintianrc changes, just they look completely different...
> 
> $ cat /etc/debian_version 
> 9.3
> $ lintian --version
> Lintian v2.5.50.4
> $ cat .lintianrc 
> display-info = yes
> display-experimental = yes
> pedantic = yes
> show-overrides = no
> color = auto
> $ lintian ~/src/github.com/peteheist/irtt/dpkg/irtt_0.9-1_amd64.changes
> 
> P: irtt source: debian-watch-may-check-gpg-signature
> I: irtt: hardening-no-fortify-functions usr/bin/irtt
> I: irtt: spelling-error-in-binary usr/bin/irtt writeN written
> I: irtt: spelling-error-in-binary usr/bin/irtt ot to
> I: irtt: hardening-no-bindnow usr/bin/irtt
> I: irtt: hardening-no-pie usr/bin/irtt
> P: irtt: no-upstream-changelog
> 
> Also, some of the warnings (like compat-version) just come from output
> from dh-make-golang, which I just installed with ‘apt-get install
> dh-make-golang’. Do I need a newer version?

You're expected to run unstable (Sid) for packaging work. At least in a
virtual machine.

By the way, it's also a good practice to actually build the package in a
chroot (using git-buildpackage pbuilder options for instance), to avoid
build-depends issues.


Cheers,

-- 
nodens

Bug#768073: [pkg-lxc-devel] Bug#768073: LXD packaging (and lxc-go plus a little bit of salsa)

[Clément Hermann]

On 03/02/2018 16:52, Clément Hermann wrote:
> Hi,
> Is there anything regarding lxc-team packaging style/workflow I should
> be aware of? From what I saw, the workflow seems to be using gbp with
> pristine star branch, UNRELEASED target distribution until the package
> is ready to upload, so very similar to what I'm used to in pkg-perl.
> Please correct me if I'm wrong! :)

Except pristine star-> pristine-tar, obviously, I had a brain
autocorrect bug. ;)


Cheers,

-- 
nodens

Bug#768073: [pkg-lxc-devel] Bug#768073: LXD packaging (and lxc-go plus a little bit of salsa)

[Clément Hermann]

Hi,


I've resumed active work on LXD, the last dependency
(golang-gopkg-lxc-go-lxc.v2 - #883488) is almost done (pending review
and upload).

Regarding lxc-go, I suggest we archive the previous attemps, since it
will live in pkg-go repository (using gitlab Archive feature on Salsa).
Same for the lxd ubuntu package that has been imported: I think it will
be much easier to create a new package from scratch using
dh-make-golang. Of course, I intent to cherry-pick bits of Ubuntu
packaging where it makes sense.

Speaking of Salsa, can someone grant me access to lxc-team ?

on LXD packaging per se, the only difference with other go packages will
probably be that pkg-go team switched to a workflow without pristine-tar
(see https://pkg-go.alioth.debian.org/workflow-changes.html if you're
interested). And, of course, that the repo is in lxc-team namespace.


Is there anything regarding lxc-team packaging style/workflow I should
be aware of? From what I saw, the workflow seems to be using gbp with
pristine star branch, UNRELEASED target distribution until the package
is ready to upload, so very similar to what I'm used to in pkg-perl.
Please correct me if I'm wrong! :)


Cheers.

-- 
nodens

Bug#883488: RFS: golang-gopkg-lxc-go-lxc.v2

[Clément Hermann]

Hi!


The last missing dependency for LXD should be ready to upload,
hopefully. If a DD could have a look at it and upload it that would be
awesome.

Martín, maybe preferably you since you already had a first look at it ?

Cheers!

-- 
nodens

Bug#837500: fixed in golang-gopkg-flosch-pongo2.v3 3.0-1

[Clément Hermann]

Control: close 839748

On 28/12/2017 17:13, gregor herrmann wrote:
> On Thu, 28 Dec 2017 16:00:17 +0000, Clément Hermann wrote:
> 
>> Format: 1.8
>> Date: Mon, 18 Dec 2017 19:33:18 +0100
>> Source: golang-gopkg-flosch-pongo2.v3
>> Binary: golang-gopkg-flosch-pongo2.v3-dev
>> Architecture: source all
>> Version: 3.0-1
>> Distribution: unstable
>> Urgency: medium
>> Maintainer: Debian Go Packaging Team 
>> <pkg-go-maintain...@lists.alioth.debian.org>
>> Changed-By: Clément Hermann <nod...@nodens.org>
>> Description:
>>  golang-gopkg-flosch-pongo2.v3-dev - Django-syntax like template-engine for 
>> Go
>> Closes: 837500
>> Changes:
>>  golang-gopkg-flosch-pongo2.v3 (3.0-1) unstable; urgency=medium
>>  .
>>[ Jonathan Carter ]
>>* Initial upload to Debian (Closes: #837500)
> 
> Looks like this upload closed the wrong bug, 837500 instead of
> 839748.
Ooops... Sorry about that. I should have checked the changelog more
thoroughtly.

> 837500 can be closed as well, so the only "harm" currently is that 839748
> is still open.

Not anymore ;)

Thanks for noticing!


Cheers,


nodens

Bug#768073: [pkg-lxc-devel] Bug#768073: Bug#768073: LXD packaging

[Clément Hermann]

On 21/12/2017 10:31, Evgeni Golov wrote:
 I also started working on golang-gopkg-lxc-go-lxc.v2-dev (ITP: #883488).

 That's the last dependancy for LXD.

>>>
>>> And it's waiting for review and upload as well, in the pkg-go repository.
>>>
>>
>> I'm almost done, hopefully will have something ready for review this
>> weekend :)
> 
> Awesome! I tried doing this in [1], but the test suite didn't like me :(

yes, it's basically impossible to run the tests in the build system: the
unprivileged ones need a working LXC setup with cgroups (I actually have
trouble with them with my user out of a chroot), and the privileged one
aren't skipped because fakeroot...

I discussed this a bit on #pkg-go and I decided to loose the tests for
the initial packaging, and plan to setup the tests in autopkgtest instead.

There is still some work to be done, I hope I'll find time to finish
this weekend.

 So I started looking packaging LXD stable-2.0 as well, and asked to join
 the pkg-lxc team (pending approval).
>>>
>>> Unfortunately I had no response so far... Ping ? My Alioth username is
>>> nodens-guest.
>>>
>>
>> (Friendly) ping ?
> 
> Sorry, busy with life atm, but now Alioth just said "Member Added
> Successfully" :))
> 
> Welcome!

Thanks :)


-- 
nodens

Bug#768073: [pkg-lxc-devel] LXD packaging

[Clément Hermann]

On 17/12/2017 21:39, Clément Hermann wrote:

> On 04/12/2017 21:40, Clément Hermann wrote:
>> So, I did some work on golang-gopkg-flosch-pongo2
>> <https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-flosch-pongo2.git/>
>> (#839748), since I had no answer.
>> It should be fit for release but I would need someone (from the pkg-go
>> team) to review and upload.
>>
> 
> It's been completely reworked, hopefully it can be reviewed and uploaded
> soon.

It's in NEW right now.

>> I also started working on golang-gopkg-lxc-go-lxc.v2-dev (ITP: #883488).
>>
>> That's the last dependancy for LXD.
>>
> 
> And it's waiting for review and upload as well, in the pkg-go repository.
> 

I'm almost done, hopefully will have something ready for review this
weekend :)


>> So I started looking packaging LXD stable-2.0 as well, and asked to join
>> the pkg-lxc team (pending approval).
> 
> Unfortunately I had no response so far... Ping ? My Alioth username is
> nodens-guest.
> 

(Friendly) ping ?


Cheers,

\

Bug#768073: [pkg-lxc-devel] Bug#768073: LXC team take over ITP?

[Clément Hermann]

Hi,

Time for a new status update, I guess.


On 04/12/2017 21:40, Clément Hermann wrote:
> So, I did some work on golang-gopkg-flosch-pongo2
> <https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-flosch-pongo2.git/>
> (#839748), since I had no answer.
> It should be fit for release but I would need someone (from the pkg-go
> team) to review and upload.
> 

It's been completely reworked, hopefully it can be reviewed and uploaded
soon.

> I also started working on golang-gopkg-lxc-go-lxc.v2-dev (ITP: #883488).
> 
> That's the last dependancy for LXD.
> 

And it's waiting for review and upload as well, in the pkg-go repository.

> So I started looking packaging LXD stable-2.0 as well, and asked to join
> the pkg-lxc team (pending approval).

Unfortunately I had no response so far... Ping ? My Alioth username is
nodens-guest.

> I think the best approach would be to not start from the ubuntu package,
> but instead, start from scratch, with dh-make-golang, so that we have
> proper initial packaging, and then integrate ubuntu work where needed.

That's what I started doing (only locally for now, since I'm not in the
team).

I decided to follow the new pkg-go workflow, for consistency with other
Go packages:

https://pkg-go.alioth.debian.org/workflow-changes.html

Of course, if people in the LXC team disagree, we can use a different one.


Cheers,

-- 
nodens

Bug#839748: [pkg-go] Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Clément Hermann]

On 17/12/2017 16:40, Clément Hermann wrote:
> Hi !
> 
> On 03/12/2017 23:39, Clément Hermann wrote:
> 
>> I just uploaded my fixes and pushed the missing branches/tags.
>>
>> All it needs now is rewiewing, signed tag and upload, hopefully.
>>
> 
> I first did that, but discussion with Tincho and Jonathan on IRC made me
> reset the repo completely in a new repo:
> 
>  
> git+ssh://git.debian.org/git/pkg-go/packages/golang-gopkg-flosch-pongo2.v3.git
> 
> I created it with the setup-repository script on Alioth, hopefully I
> didn't mess up anything.


Note: I left /git/pkg-go/packages/golang-gopkg-flosch-pongo2.git in
place for now but I intend to delete it once the new package has been
reviewed. If someone thinks it's worth keeping, I suggest creating an
"attic" or "archive" directory. IIRC Tincho was against keeping it.

Cheers,

-- 
nodens

Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Clément Hermann]

Hi !

On 03/12/2017 23:39, Clément Hermann wrote:

> I just uploaded my fixes and pushed the missing branches/tags.
> 
> All it needs now is rewiewing, signed tag and upload, hopefully.
> 

I first did that, but discussion with Tincho and Jonathan on IRC made me
reset the repo completely in a new repo:

 git+ssh://git.debian.org/git/pkg-go/packages/golang-gopkg-flosch-pongo2.v3.git

I created it with the setup-repository script on Alioth, hopefully I
didn't mess up anything.

The reasoning behind the reset is that:
- starting from the Ubuntu package made it harder (more work) to follow
the pkg-go rules, especially the new workflow [1]
- some work from the orginal packaging didn't make sense since this
package is solely meant as a build-dep for lxd (so far), so no need to
take a snapshot for instance: LXD is happy with the v3 release
- It was better to start from scratch with dh-make-golang and get bits
from the original packaging work, in the end.

So now, it's ready. If someone could review and upload it, that would be
great :)

[1] https://pkg-go.alioth.debian.org/workflow-changes.html

Cheers,

-- 
nodens

Bug#768073: LXC team take over ITP?

[Clément Hermann]

Hi !

Time for a status update on this one, hopefully !

On Fri, 13 Oct 2017 13:36:47 +0200 Clément Hermann
<clement.herm...@virtua.ch> wrote:

>
> I see there are only a couple dependancies left on the wiki page. Do you
> need help ?
> I'm not a Go expert, but I would really like to see LXD in Debian.
> (also, not a DM/DD - Yet! )
>
> I started looking at golang-gopkg-inconshreveable-log15.v2, the
> packaging should be straightforward enough apparently. I'm willing to do
> it if it helps.

This last one is not needed anymore.

So, I did some work on golang-gopkg-flosch-pongo2
<https://anonscm.debian.org/cgit/pkg-go/packages/golang-gopkg-flosch-pongo2.git/>
(#839748), since I had no answer.
It should be fit for release but I would need someone (from the pkg-go
team) to review and upload.

I also started working on golang-gopkg-lxc-go-lxc.v2-dev (ITP: #883488).

That's the last dependancy for LXD.

So I started looking packaging LXD stable-2.0 as well, and asked to join
the pkg-lxc team (pending approval).

I think the best approach would be to not start from the ubuntu package,
but instead, start from scratch, with dh-make-golang, so that we have
proper initial packaging, and then integrate ubuntu work where needed.


Cheers,

-- 
nodens

Bug#883488: ITP: golang-gopkg-lxc-go-lxc.v2 -- Go bindings for liblxc

[Clément Hermann]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Cl=C3=A9ment_Hermann?= 


* Package name: golang-gopkg-lxc-go-lxc.v2
  Version : 0.0~git20171109.99ba61b-1
  Upstream Author : LXC - Linux Containers
* URL : https://github.com/lxc/go-lxc
* License : LGPL-2.1 with redistribution exception
  Programming Lang: Go
  Description : Go bindings for liblxc

 go-lxc implements Go bindings for the LXC C API (liblxc).


This package is a dependancy for LXD. It will be maintained under
pkg-go team umbrella.

Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Clément Hermann]

On 03/12/2017 17:37, Clément Hermann wrote:
> On 21/11/2017 12:48, Clément Hermann wrote:
>> When I wanted to build the package, I realized it's not using
>> git-buildpackage, as the other Go packages do.
>>
>> Is it intentional, or do you plan to use graft or something like that to
>> rewrite history and have the proper branches ? I had a look at it, and
>> I'm not really comfortable enough with git
>> to do it without messing things up, so I wonder what the options are.
> 
> So, looking at it more closely, I found out that the initial commit is
> actually the upstream source, which means we can just branch from it for
> the upstream branch.
> 
> While waiting for the workflow changes following DebConf17 BoF [0], I
> guess the best is to be as standard as possible, even if it's a bit
> painful in this case, since uscan doesn't allow arbitrary snapshots yet
> [1] and upstream stopped doing releases ages ago. So I guess manual
> snapshot and pristine-tar is the way to go.
> 
> Of course if you have upstream and pristine-tar branch locally it would
> be great to push them ;)
> 
> 
> I asked to join the pkg-go project on alioth, because I have a couple
> commits ready locally for trivial nitpick, but I guess this package is
> not far from upload, and I'm preparing an ITP for
> golang-gopkg-lxc-go-lxc.v2-dev.
> 
> Would anyone mind rewieving / uploading ? Jonathan, are you still
> working on this, or should I take over the ITP ?
> 

I just uploaded my fixes and pushed the missing branches/tags.

All it needs now is rewiewing, signed tag and upload, hopefully.


Cheers,

-- 
nodens

Bug#880701: lintian: Please update the Debian archive sections

[Clément Hermann]

Control: reopen -1

Control: block -1 847520

reopening since it's not fixed after all ;)

(just noticed this because I was bit by the "resolution")

Cheers,

-- 
nodens

Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Clément Hermann]

On 21/11/2017 12:48, Clément Hermann wrote:

> On Sun, 19 Nov 2017 18:45:21 +0100 <clement.herm...@virtua.ch> wrote:
>> Hi !
>>
>> On Tue, 4 Oct 2016 15:30:00 +0100 Jonathan Dowland <j...@debian.org>
> wrote:
> 
>>> This is a dependency for LXD and is being packaged via the pkg-go team.
>>
>> It's actually the last one beside golang-gopkg-lxc-go-lxc.v2-dev.
>>
>> Any ETA ? I saw the repository under pkg-go, is there any way I can help ?
> 
> When I wanted to build the package, I realized it's not using
> git-buildpackage, as the other Go packages do.
> 
> Is it intentional, or do you plan to use graft or something like that to
> rewrite history and have the proper branches ? I had a look at it, and
> I'm not really comfortable enough with git
> to do it without messing things up, so I wonder what the options are.

So, looking at it more closely, I found out that the initial commit is
actually the upstream source, which means we can just branch from it for
the upstream branch.

While waiting for the workflow changes following DebConf17 BoF [0], I
guess the best is to be as standard as possible, even if it's a bit
painful in this case, since uscan doesn't allow arbitrary snapshots yet
[1] and upstream stopped doing releases ages ago. So I guess manual
snapshot and pristine-tar is the way to go.

Of course if you have upstream and pristine-tar branch locally it would
be great to push them ;)


I asked to join the pkg-go project on alioth, because I have a couple
commits ready locally for trivial nitpick, but I guess this package is
not far from upload, and I'm preparing an ITP for
golang-gopkg-lxc-go-lxc.v2-dev.

Would anyone mind rewieving / uploading ? Jonathan, are you still
working on this, or should I take over the ITP ?


Cheers,

nodens


[0] https://pkg-go.alioth.debian.org/workflow-changes.html
[1] https://bugs.debian.org/811565

Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Clément Hermann]

Hi,

just realized I sent this using my work address. Here is the correct one
(but I'm subscribed to the bug anyway).


On Sun, 19 Nov 2017 18:45:21 +0100  wrote:
> Hi !
>
> On Tue, 4 Oct 2016 15:30:00 +0100 Jonathan Dowland 
wrote:

> > This is a dependency for LXD and is being packaged via the pkg-go team.
>
> It's actually the last one beside golang-gopkg-lxc-go-lxc.v2-dev.
>
> Any ETA ? I saw the repository under pkg-go, is there any way I can help ?

When I wanted to build the package, I realized it's not using
git-buildpackage, as the other Go packages do.

Is it intentional, or do you plan to use graft or something like that to
rewrite history and have the proper branches ? I had a look at it, and
I'm not really comfortable enough with git
to do it without messing things up, so I wonder what the options are.


Cheers,

-- 
nodens

Bug#839748: ITP: golang-gopkg-flosch-pongo2.v3 -- Django-syntax like template-engine for Go

[Clément Hermann]

Hi !

On Tue, 4 Oct 2016 15:30:00 +0100 Jonathan Dowland <j...@debian.org> wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Jonathan Dowland <j...@debian.org>
>
> * Package name : golang-gopkg-flosch-pongo2.v3
> Version : 3.0
> Upstream Author : Florian Schlachter
> * URL : https://github.com/flosch/pongo2
> * License : Expat
> Programming Lang: Go
> Description : Django-syntax like template-engine for Go
>
> This offers a template renderer compatible with the Django syntax but
> for the Go language.
> .
> pongo2 is the successor of pongo.
>
> This is a dependency for LXD and is being packaged via the pkg-go team.

It's actually the last one beside golang-gopkg-lxc-go-lxc.v2-dev.

Any ETA ? I saw the repository under pkg-go, is there any way I can help ?

Cheers,

-- 
Clément Hermann
Senior Network System Engineer

VIRTUA.CH
T +41 21 544 28 00

FACEBOOK // http://l.virtua.ch/facebook
TWITTER  // http://l.virtua.ch/twitter
LINKEDIN // http://l.virtua.ch/linkedin

Bug#759604: auditd: Please make auditd log readable by the adm group

[Clément Hermann]

On 06/11/2017 12:41, Laurent Bigonville wrote:

> The proper way to monitor the audit log would be to use audispd and
> create a daemon responding to the events (this is what setroubleshoot is
> doing).
> 
> Parsing the logs manually is meh (especially if you take into account
> that the kernel is not using the proper audit event id)

While I agree it's the Right Thing To Do, right now aa-notify just
parses the log and it works OK. It just needs the proper permissions on
the log to do that without being root.

Can't we implement the permission solution as a first step ? Even if
it's not a perfect solution, it just works, and I don't see any harmful
side-effect - that's what the adm group is for, IMO. Of course, please
correct me if I'm wrong !


Cheers,

-- 
nodens

Bug#849727: [Pkg-privacy-maintainers] Bug#849727: Adopting seahorse-nautilus?

[Clément Hermann]

Control: retitle -1 ITA: seahorse-nautilus -- Nautilus extension for Seahorse 
integration

Fixing title. Thunderbird wrapped it.


Cheers,

-- 
nodens