Bug#969291: RFS: sane-backends/1.0.31-1~experimental1 [RC] -- API library for scanners [transitional package]

2020-09-18 Thread Raphael Hertzog
Hi,

On Thu, 10 Sep 2020, Jörg Frings-Fürst wrote:
> > I'd like to see this new upstream release in sid so I'm taking a look
> > but I'm quite surprised by many things. And actually I want this fix
> > in the package too:
> > https://gitlab.com/sane-project/backends/-/merge_requests/502
> 
> I have add this merge request as d/p/0165-respect_local_only_parameter.patch

Thanks. From the comments in that merge request, it seems that
https://gitlab.com/sane-project/backends/-/merge_requests/506 should be
included too to have a complete fix.

And as we said, at this point we should upload this to "unstable" and not
to "experimental".

Can you add the missing change and fix the version and target
distribution? I'm happy to review and upload afterwards. I have not found
anything problematic in a quick look.

BTW, looking at the added patch, it's wrong to write "Forwarded: no" when
you import an upstream patch. The correct value would be "not-needed" but
in fact DEP-14 tells that you don't need the field when you have a "Bug"
header.

https://dep-team.pages.debian.net/deps/dep3/

For the other patches, you have set "Forwared: not needed" when the value
documented in DEP3 is "Forwarded: not-needed".

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



Bug#969291: RFS: sane-backends/1.0.31-1~experimental1 [RC] -- API library for scanners [transitional package]

2020-09-18 Thread Raphael Hertzog
Hi,

On Sat, 05 Sep 2020, Jörg Frings-Fürst wrote:
> > First of all, why is this packaging git repository not hosted on
> > salsa.debian.org? I can create you a repository in the "debian"
> > namespace and grant you commit rights on this repository. It
> > would make it easier for random DD to help you out.
> 
> Why is simply explained. For the packages in the salsa section debian DDs have
> the right to make changes even against the intention of the maintainers and 
> then
> upload them without following the NMU rules. This is not my idea of teamwork.

This is seldom a problem. And you should trust your peers, not fear their
help.

Having it hosted outside of salsa.debian.org creates needless barriers, in
particular when you are not a DD. When I sponsor, I prefer to sponsor out
of salsa so that I can fix the issues that I find and so that I can tag,
etc.

> The change from libsane to libsane1 requires IMHO a transition. Therefore only
> in experimental. 

It no longer requires a transition since we have a transitional package.
That said you should still ask for a binnmu of the reverse dependencies to
get updated dependencies. But they don't have to migrate together with
sane-backends.

> Normally I forward almost all patches. After lintian complained about the
> missing entry forwarded as a warning, I added not-needed for old patches. 
> After
> moving sane to GitLab I don't have direct access to the old bug reports
> anymore. 

I don't understand what you are trying to explain. Surely you can open
merge request against sane-backends if you have something to submit?

> > Looking at your history on this package, have you considered asking
> > for the Debian Maintainer status so that you can upload that package
> > on your own?
> 
> I am missing the second signing of my key by a DD. I live here near the oldest
> city in Germany, but for Debian far away from everything. 

If you have seen the recent messages, you will see that those signatures
are no longer mandatory. If you have worked with a regular sponsor over a
long period of time, then you can likely go through the process easily.

https://lists.debian.org/debian-devel-announce/2020/09/msg0.html

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



Bug#969291: RFS: sane-backends/1.0.31-1~experimental1 [RC] -- API library for scanners [transitional package]

2020-09-04 Thread Raphael Hertzog
Hello,

I'd like to see this new upstream release in sid so I'm taking a look
but I'm quite surprised by many things. And actually I want this fix
in the package too:
https://gitlab.com/sane-project/backends/-/merge_requests/502

First of all, why is this packaging git repository not hosted on
salsa.debian.org? I can create you a repository in the "debian"
namespace and grant you commit rights on this repository. It
would make it easier for random DD to help you out.

Then, why is this in experimental ?

I saw you switched from "libsane" to "libsane1". This was not really
warranted, the lintian warning that you fixed with this rename
was harmless and you should consider the cost to update all the
reverse build dependencies (and there are quite a few). However
now that you have added the transitional package and that you are
already gone through NEW, I guess it's ok to push this to completion.

I saw many numbered patches in debian/patches/ but the number
does not indicate the order in which they are applied. Thus I'd suggest
to drop the numbering entirely. And a few of them are likely
worth forwarding to the upstream developers... I see "Forwarded: not
needed" on patches that should be forwarded IMO.

Looking at your history on this package, have you considered asking
for the Debian Maintainer status so that you can upload that package
on your own?

Cheers,

On Sun, 30 Aug 2020, Jörg Frings-Fürst wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "sane-backends":
> 
>Package name: sane-backends
>Version : 1.0.31-1~experimental1
>Upstream Author : [fill in name and email of upstream]
>URL : http://www.sane-project.org
>License : GPL-3+, GPL-2+ with sane exception, Artistic, GFDL-1.1,
>  GPL-2+, LGPL-2.1+, GPL-2
>Vcs : https://jff.email/cgit/sane-backends.git
>Section : graphics
> 
> It builds those binary packages:
> 
>   libsane - API library for scanners [transitional package]
>   libsane-dev - API development library for scanners [development files]
>   libsane1 - API library for scanners
>   libsane-common - API library for scanners -- documentation and support files
>   sane-utils - API library for scanners -- utilities
> 
> To access further information about this package, please visit the following
> URL:
> 
>   https://mentors.debian.net/package/sane-backends/
> 
> Alternatively, one can download the package with dget using this command:
> 
>  dget -x 
> https://mentors.debian.net/debian/pool/main/s/sane-backends/sane-backends_1.0.31-1~experimental1.dsc
> 
> or from
> 
>  git 
> https://jff.email/cgit/sane-backends.git?h=release%2Fdebian%2F1.0.31-1_experimental1
> 
> Changes since the last upload:
> 
>  sane-backends (1.0.31-1~experimental1) experimental; urgency=medium
>  .
>* New upstream release (Closes: #968949, #962539).
>* Add back libsane transitional package, to ease upgrades (Closes: 
> #962936):
>  - debian/control: Add package libsane as oldlibs.
>Thanks to Gianfranco Costamagna .
>* debian/copyright:
>  - Fix lintian *-globbing-patterns errors.
>  - Refresh to the new upstream release.
>* Convert debian/po/de.po to utf-8.
>* New patches:
>  - debian/patches/0045-disable_lock_test_at_build_time.patch
>  - debian/patches/0050-Use-python3-shebang.patch
>  - debian/patches/0055-Fix_build_error.patch
>* debian/rules:
>  - Use --enable-locking instead --disable-locking.
>* debian/control:
>  - Add libpoppler-glib-dev to Build-Depends.
>  - Add ipp-usb to libsane1 Recommends (Closes: #968953).
>* debian/libsane1.symbols:
>  - Remove 7 not longer available symbols.
>* debian/saned@.service:
>  - Switch Standard[Output|Error] from syslog to append:/var/log/saned.log.
>  - New debian/sane-utils.logrotate to pack and remove old logs.
>* debian/libsane-common.lintian-overrides:
>  - Rename tags.
>* debian/patches/0125-multiarch_dll_search_path.patch:
>  - Add $(prefix)/lib64/sane to lib search path  (Closes: #931297).
>* Fix FTCBFS: (Closes: #948711)
>  - 0060-cross.patch: Make gphoto2 detection use the host architecture
>pkg-config.
>  - Build tools/sane-desc for the build architecture.
>  - Thanks to Helmut Grohne .
>* Remove files no longer needed:
>  - debian/saned.socket
>  - debian/saned@.service
> 
> CU
> Jörg
> 
> - -- 
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
> 
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
> 
> Jörg Frings-Fürst
> D-54470 Lieser
> 
> 
> git:  https://jff.email/cgit/
> 
> Threema:  SYR8SJXB
> Wire: @joergfringsfuerst
> Skype:joergpenguin
> Ring: jff
> 

Bug#969458: perl crash in eval command trying a failing require statement

2020-09-04 Thread Raphael Hertzog
On Thu, 03 Sep 2020, Niko Tyni wrote:
> > The $name tried is "Kali" and we don't ship any Dpkg::Vendor::Kali. The
> > code should fallback to Dpkg::Vendor::Debian and this works a few times
> > but after multiples calls, at some point it no longer works and the
> > require statement in the eval block just never returns, it seems to crash
> > the perl interpreter.
> 
> This looks like a bug in dpkg to me.

Thanks for the analysis. I wasn't aware of this $SIG{__DIE__} feature...
hopefully a fixed dpkg will be released soon.

> I suspect the Perl side is working as designed?

Indeed.

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



Bug#969320: aflplusplus: please make the build reproducible

2020-08-31 Thread Raphael Hertzog
Hi,

On Mon, 31 Aug 2020, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> aflplusplus could not be built reproducibly.

The reprotest CI job fails too and seems to show other issues:
https://salsa.debian.org/pkg-security-team/aflplusplus/-/jobs/964936/raw

I couldn't easily figure out the reason...

> Here is the variation in the manpage
> 
> │ │ │ │ │ -.B afl-clang-fast \- /bin/sh: 1: ./afl-clang-fast: not found
> │ │ │ │ │ +.B afl-clang-fast \- /bin/sh: ./afl-clang-fast: No such file or 
> directory
> 
> This is, I think, because we do not build or keep these variants on
> non-x86 systems, so the call in the Makefile fails with the above
> message. This then varies depending on the user's shell that /bin/sh
> symlinks to (!), rendering the package reproducible.

The issue is actually in llvm_mode/GNUMakefile. One one line we expect the
binary in the current directory but it's actually built in the parent
directory.

> There is also a variation in these manpages based on the build date:
> 
> │ │ │ │ │ -.TH afl-clang-fast 8 2021-10-03 afl++
> │ │ │ │ │ +.TH afl-clang-fast 8 2020-08-31 afl++
> 
> ... but I can't quite see why as you do appear to be using the
> SOURCE_DATE_EPOCH environment variable. It may not matter if we don't
> even ship them, hence why I'm not immediately investigating this
> angle.

It does matter as we ship them on i386/amd64!

The issue is that llvm_mode/GNUMakefile is not using SOURCE_DATE_EPOCH.

Here's the patch I'm adding to git and submitting to upstream:

diff --git a/llvm_mode/GNUmakefile b/llvm_mode/GNUmakefile
index 1a8c9f43..380397f2 100644
--- a/llvm_mode/GNUmakefile
+++ b/llvm_mode/GNUmakefile
@@ -28,6 +28,8 @@ MAN_PATH?= $(PREFIX)/share/man/man8
 
 VERSION = $(shell grep '^$(HASH)define VERSION ' ../config.h | cut -d '"' 
-f2)
 
+BUILD_DATE  ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "+%Y-%m-%d" 
2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "+%Y-%m-%d" 2>/dev/null || 
date -u "+%Y-%m-%d")
+
 ifeq "$(shell uname)" "OpenBSD"
   LLVM_CONFIG ?= $(BIN_PATH)/llvm-config
   HAS_OPT = $(shell test -x $(BIN_PATH)/opt && echo 0 || echo 1)
@@ -440,10 +442,10 @@ install: all
 
 vpath  % ..
 %.8: %
-   @echo .TH $* 8 `date "+%Y-%m-%d"` "afl++" > ../$@
+   @echo .TH $* 8 $(BUILD_DATE) "afl++" > ../$@
@echo .SH NAME >> ../$@
@echo -n ".B $* \- " >> ../$@
-   @./$* -h 2>&1 | head -n 1 | sed -e "s/$$(printf '\e')[^m]*m//g" >> ../$@
+   @../$* -h 2>&1 | head -n 1 | sed -e "s/$$(printf '\e')[^m]*m//g" >> 
../$@
@echo >> ../$@
@echo .SH SYNOPSIS >> ../$@
@../$* -h 2>&1 | head -n 3 | tail -n 1 | sed 's/^\.\///' >> ../$@

Filed here: https://github.com/AFLplusplus/AFLplusplus/pull/535

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



Bug#697781: ITP

2020-08-07 Thread Raphael Hertzog
Control: retitle -1 ITP: hamster-time-tracker -- a GNOME time tracker
Control: owner -1 !

I'm going to reintroduce the hamster time tracker into Debian. I was
using hamster-applet up to today but I just realized that it was dropped
from Debian a long time ago...

I will use https://salsa.debian.org/projecthamster-team/hamster-time-tracker
to maintain the package since Matthijs already created this a while ago.
I'm waiting to have write access but I have the package ready to upload
and I will upload it right away.

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



Bug#967086: Empty pages when authenticated

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

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

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

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

Did you drop you old certificate and restart your browser?

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



Bug#967086: Empty pages when authenticated

2020-08-05 Thread Raphael Hertzog
Hi,

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

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

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

So maybe get a new certificate?

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

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



Bug#964399: Should ganglia be removed?

2020-07-28 Thread Raphael Hertzog
Hi,

On Tue, 07 Jul 2020, Marcos Fouces wrote:
> I also done some work on ganglia-web and ganglia-linux-modules packages
> (also unpublished).
> 
> I believe that it is still a good piece of software that deserve its
> place on Debian so i would like to step up as uploader (co-uploaders
> welcome!) if needed.
> 
> I also would like to maintain it under pkg-security team umbrella.

Why pkg-security? It doesn't seem related to the team's purpose.

I can create you repositories in the "debian" namespace if you want but
I'd rather not add random packages to the pkg-security team...

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



Bug#966368: lintian gets stuck when run by sbuild within rebuildd

2020-07-27 Thread Raphael Hertzog
Hi,

On Mon, 27 Jul 2020, Chris Lamb wrote:
> > In Kali, our build daemons run "rebuildd" with a build script that calls
> > sbuild --run-lintian. Since lintian 2.85 (I believe 2.84.0 is not affected),
> > the build process get stuck at the point when lintian is run. I see two 
> > lintian
> > processes (a parent and its child) and both are stuck in epoll_pwait()
> > according to strace.
> 
> I think this is the same as #966122 and/or #966072.

Looks like the same as #966122 since it seems to break in the same check
(deb-format which is the only place where I expect "ar t" to be called).

I didn't find this one while looking for duplicate... I saw #964770 but it
didn't seem exactly the same issue.

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



Bug#959963: Updating qterminal to version 0.15.0

2020-07-24 Thread Raphael Hertzog
Hi,

is there any chance that one of you can take care of updating qterminal
to the latest upstream version? Version 0.15 is available and it seems
to fix a bunch of issues for many persons. It's our main terminal in Kali
and we would like to see the latest version in Debian.

https://github.com/lxqt/qterminal/releases/download/0.15.0/qterminal-0.15.0.tar.xz

If you don't have the time to handle this, are you OK with a NMU to upload
the new version? Feel free to grant me (temporary if you want) membership
in the lxqt team on salsa if you want me to commit this to the git
repository (I'm user 'hertzog').

I expect the work to be relatively easy given that Ubuntu already did it:
https://launchpad.net/ubuntu/+source/qterminal/0.15.0-0ubuntu1

Thank you in advance!
-- 
Raphaël Hertzog ◈ Offensive Security ◈ Kali Linux Developer



Bug#966022: lintian: False positive on missing-depends-on-sensible-utils with commands like i3-sensible-pager

2020-07-22 Thread Raphael Hertzog
Hello,

I just want to point out that the search for the "sensible-*" commands
might be a bit too broad. It also finds the strings in
/usr/share/lintian/overrides/i3-wm-gaps...

Same issue in i3-wm in Debian:
https://lintian.debian.org/sources/i3-wm/4.17.1-1.html

Cheers,

On Wed, 22 Jul 2020, Raphaël Hertzog wrote:
> In this package https://gitlab.com/kalilinux/packages/i3-gaps we have the
> following lintian errors:
> 
> E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3
> E: i3-gaps-wm: missing-depends-on-sensible-utils usr/bin/i3-sensible-pager
> 
> But they are wrong:
> 
> $ grep -r sensible-pager src/
> src/bindings.c:sasprintf(, "i3-sensible-pager \"%s\"\n", 
> errorfilename);
> src/config_parser.c:sasprintf(, "i3-sensible-pager \"%s\"\n", 
> errorfilename);
> 
> The program is calling i3-sensible-pager (provided in the same package)
> and not "sensible-pager".
> 
> Cheers,
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
> 'oldstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages lintian depends on:
> ii  binutils  2.34.90.20200706-1
> ii  bzip2 1.0.8-3
> ii  diffstat  1.63-1
> ii  dpkg  1.20.5
> ii  dpkg-dev  1.20.5
> ii  file  1:5.38-5
> ii  gettext   0.19.8.1-10
> ii  gpg   2.2.20-1
> ii  intltool-debian   0.35.0+20060710.5
> ii  libapt-pkg-perl   0.1.36+b3
> ii  libarchive-zip-perl   1.68-1
> ii  libcapture-tiny-perl  0.48-1
> ii  libclass-xsaccessor-perl  1.19-3+b5
> ii  libclone-perl 0.45-1
> ii  libconfig-tiny-perl   2.24-1
> ii  libcpanel-json-xs-perl4.19-1
> ii  libdata-validate-domain-perl  0.10-1
> ii  libdevel-size-perl0.83-1+b1
> ii  libdpkg-perl  1.20.5
> ii  libemail-address-xs-perl  1.04-1+b2
> ii  libfile-basedir-perl  0.08-1
> ii  libfile-find-rule-perl0.34-1
> ii  libfont-ttf-perl  1.06-1
> ii  libhtml-parser-perl   3.72-5
> ii  libio-async-loop-epoll-perl   0.21-1
> ii  libio-async-perl  0.77-3
> ii  libjson-maybexs-perl  1.004002-1
> ii  liblist-compare-perl  0.53-1
> ii  liblist-moreutils-perl0.416-1+b5
> ii  liblist-utilsby-perl  0.11-1
> ii  libmoo-perl   2.004000-1
> ii  libmoox-aliases-perl  0.001006-1
> ii  libnamespace-clean-perl   0.27-1
> ii  libpath-tiny-perl 0.114-1
> ii  libsereal-decoder-perl4.014+ds-1
> ii  libsereal-encoder-perl4.014+ds-1
> ii  libtext-levenshteinxs-perl0.03-4+b7
> ii  libtext-xslate-perl   3.5.8-1
> ii  libtime-duration-perl 1.21-1
> ii  libtime-moment-perl   0.44-1+b2
> ii  libtimedate-perl  2.3300-1
> ii  libtry-tiny-perl  0.30-1
> ii  libtype-tiny-perl 1.010002-1
> ii  libunicode-utf8-perl  0.62-1+b1
> ii  liburi-perl   1.76-2
> ii  libxml-libxml-perl2.0134+dfsg-2
> ii  libxml-writer-perl0.625-1
> ii  libyaml-libyaml-perl  0.82+repack-1
> ii  man-db2.9.3-2
> ii  patchutils0.3.4-3
> ii  perl [libdigest-sha-perl] 5.30.3-4
> ii  t1utils   1.41-4
> ii  xz-utils  5.2.4-1+b1
> 
> Versions of packages lintian recommends:
> ii  libperlio-gzip-perl  0.19-1+b6
> 
> Versions of packages lintian suggests:
> pn  binutils-multiarch 
> ii  libtext-template-perl  1.59-1
> 
> -- no debconf information

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



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

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

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

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

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

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

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

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

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


signature.asc
Description: PGP signature


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

2020-06-29 Thread Raphael Hertzog
Hi,

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

or distro-tracker?

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

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

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



Bug#962862: debci: XSS in web interface

2020-06-24 Thread Raphael Hertzog
Hi,

On Mon, 15 Jun 2020, Sebastien Delafond wrote:
> See for instance the following URL:
> 
>   
> https://ci.debian.net/user/debci/jobs?package=abc;>alert(document.domain)

The issue is present in multiple parameters and even in the URL itself:

XSS Param URL: 
https://ci.debian.net/user/debci%3Cvideo%3E%3Csource%20onerror=%22javascript:prompt(9401)%22%3E/jobs

XSS Param package: 
https://ci.debian.net/user/nobody/jobs?arch[]=amd64=bamtools%27%22()%26%25%3Cxx%3E%3CScRiPt%3Ealert(9904)%3C/ScRiPt%3E[]=kali-dev

XSS Param trigger: 
https://ci.debian.net/user/debci/jobs?arch[]=amd64=20[]=kali-dev=1%27%22()%26%25%3Cxxx%3E%3CScRiPt%3Eprompt(9829)%3C/ScRiPt%3E

Is there any chance that you could fix this in the near future?

The issues are not critical but ignoring them doesn't give a good image of
us. (And what if this could be exploited to trigger a test run with
some evil parameters...)

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



Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

2020-06-18 Thread Raphael Hertzog
Hi,

On Thu, 18 Jun 2020, Raphael Hertzog wrote:
> Actually your fix does not work because pkg_resources is not documented in
> setup.py or requirements.txt and thus it will not magically appear in
> ${python3:Depends} just by adding it in Build-Depends.
> 
> I opened https://github.com/SecureAuthCorp/impacket/issues/885 upstream to
> get this fixed but in the meantime we have to hardcode the dependency in
> Depends. I'll do that for now.

Actually, I'm not sure that anything needs to happen at the upstream
level... pkg_resources is part of setuptools, we have packaged it
separately but I believe that there's no way for us to track its usage
based on upstream dependencies so we must always manually add such a
depency (this really smells like a big deficiency in our packaging tools).

Am I correct?

Should upstream list setuptools in their requirements.txt or setup.py
because they use "pkg_resources"?

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



Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

2020-06-18 Thread Raphael Hertzog
On Wed, 17 Jun 2020, Emmanuel Arias wrote:
> I've just pushed to salsa the fix, could anyone review it and sponsor
> it, please?

Actually your fix does not work because pkg_resources is not documented in
setup.py or requirements.txt and thus it will not magically appear in
${python3:Depends} just by adding it in Build-Depends.

I opened https://github.com/SecureAuthCorp/impacket/issues/885 upstream to
get this fixed but in the meantime we have to hardcode the dependency in
Depends. I'll do that for now.

Cheers,
> El mié., 17 de jun. de 2020 a la(s) 19:18, Emmanuel Arias
> (emmanuelaria...@gmail.com) escribió:
> >
> > Hi,
> >
> > I will fix it today
> >
> > Cheers,
> > Arias Emmanuel
> > @eamanu
> > http://eamanu.com
> >
> > El mié., 17 de jun. de 2020 a la(s) 19:18, Scott Kitterman
> > (deb...@kitterman.com) escribió:
> > >
> > > On Wed, 17 Jun 2020 21:12:40 +0200 Paul Gevers  wrote:
> > > > Source: impacket, smbmap
> > > > Control: found -1 impacket/0.9.21-1
> > > > Control: found -1 smbmap/1.8.2-1
> > > > Severity: serious
> > > > Tags: sid bullseye
> > > > X-Debbugs-CC: debian...@lists.debian.org
> > > > User: debian...@lists.debian.org
> > > > Usertags: breaks needs-update
> > > >
> > > > Dear maintainer(s),
> > > >
> > > > With a recent upload of impacket the autopkgtest of smbmap fails in
> > > > testing when that autopkgtest is run with the binary packages of
> > > > impacket from unstable. It passes when run with only packages from
> > > > testing. In tabular form:
> > > >
> > > >passfail
> > > > impacket   from testing0.9.21-1
> > > > smbmap from testing1.8.2-1
> > > > all others from testingfrom testing
> > > >
> > > > I copied some of the output at the bottom of this report. Is the latest
> > > > impacket missing a dependency or is the version function not supported
> > > > anymore?
> > > >
> > > > Currently this regression is blocking the migration of impacket to
> > > > testing [1]. Due to the nature of this issue, I filed this bug report
> > > > against both packages. Can you please investigate the situation and
> > > > reassign the bug to the right package?
> > > >
> > > > More information about this bug and the reason for filing it can be 
> > > > found on
> > > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> > > >
> > > > Paul
> > > >
> > > > [1] https://qa.debian.org/excuses.php?package=impacket
> > > >
> > > > https://ci.debian.net/data/autopkgtest/testing/amd64/s/smbmap/5914948/log.gz
> > > >
> > > > autopkgtest [07:08:34]: test command1: smbmap -h
> > > > autopkgtest [07:08:34]: test command1: [---
> > > > Traceback (most recent call last):
> > > >   File "/usr/bin/smbmap", line 19, in 
> > > > from impacket import version, smbserver
> > > >   File "/usr/lib/python3/dist-packages/impacket/version.py", line 7, in
> > > > 
> > > > import pkg_resources
> > > > ModuleNotFoundError: No module named 'pkg_resources'
> > > > autopkgtest [07:08:35]: test command1: ---]
> > > >
> > > Looks like a missing depends on python3-pkg-resources for impacket since
> > > that's where it's imported.
> > >
> > > Scott K
> 

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



Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

2020-06-18 Thread Raphael Hertzog
Hi,

On Wed, 17 Jun 2020, Emmanuel Arias wrote:
> I've just pushed to salsa the fix, could anyone review it and sponsor
> it, please?

I'll take care of it right now.

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



Bug#962042: smuxi-frontend-gnome: clicking on a link does not open it in the web browser

2020-06-15 Thread Raphael Hertzog
Hi,

On Mon, 15 Jun 2020, Mirco Bauer wrote:
> I can't reproduce this issue on buster with Google Chrome as the default
> browser set in GNOME preferences.

I have firefox as default browser.

> 
> For opening any links Smuxi relies on Mono's
> System.Diagnostics.Process.Start() implementation which then uses
> /usr/bin/xdg-open and (others). From your strace it seems to pick xdg-open
> as it is executable which is expected for GNOME desktop environments.
> 
> Why it throws the exception, is not clear What happens if you run this
> from a terminal:
> /usr/bin/xdg-open '
> https://pbs.twimg.com/media/ESpweBhXgAAefGF?format=jpg=small'
> echo $?

$ LANG=C /usr/bin/xdg-open '
https://pbs.twimg.com/media/ESpweBhXgAAefGF?format=jpg=small'
gio: 
file:///home/rhertzog/freexian/deblts/%0Ahttps:/pbs.twimg.com/media/ESpweBhXgAAefGF%3Fformat=jpg=small:
 Error when getting information for file ?/home/rhertzog/freexian/deblts/
https:/pbs.twimg.com/media/ESpweBhXgAAefGF?format=jpg=small?: No such file 
or directory
$ echo $?
4

I have kept the leading newline character that you have put in the call...
but without the newline character, it works fine.

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



Bug#830572: UNRELEASED entry and new upstream version

2020-06-11 Thread Raphael Hertzog
On Wed, 10 Jun 2020, Guido Günther wrote:
> Happy to apply a patch. I'm using
> 
> ```
> [import-orig]
> # Automatically forward the changelog after importing a new upstream version
> postimport = gbp dch -S -a --debian-branch=$GBP_BRANCH && git commit --amend 
> -C@{0} debian/changelog
> ```
> 
> to basically get this.

Note that "gbp dch -S -a" will not do what I'm asking here. My issue is
when we have a pre-existing UNRELEASED entry for the former upstream
version. That changelog entry is reused by "gbp dch" but the version
number is not changed to match the latest upstream release that was merged
before with gbp import-orig.

More concretely, I have merged upstream release 4.0 but right
now my changelog has this:
cpputest (3.8-8) UNRELEASED; urgency=medium

And after "gbp dch" it still has the same header line when it should have
updated it to 4.0-1 (or 4.0-1~1.gbp with -S).

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



Bug#830572: UNRELEASED entry and new upstream version

2020-06-10 Thread Raphael Hertzog
Hi,

I was about to report that "gbp dch" was not updating the version number
in an UNRELEASED entry even after you have merged a new upstream version.
But I found this (broader) bug report, covering this and more.

It would be really nice to get the changes documented in this bug
report...

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



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

2020-06-02 Thread Raphael Hertzog
Control: forcemerge 884933 -1

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

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

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

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

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



Bug#960926: developers-reference: updating the packages copyright notices

2020-05-18 Thread Raphael Hertzog
Hi,

On Mon, 18 May 2020, Holger Levsen wrote:
> I'd like to update the copyright statements in d/changelog and and
> source/index.rst and bring them in sync as well. Thus I have prepared
> the following diff.
> 
> I'd appreciate a quick review and possible corrections from you!

Fine for me.

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


signature.asc
Description: PGP signature


Bug#960890: python-django: New upstream 3.x release

2020-05-18 Thread Raphael Hertzog
Hi,

On Sun, 17 May 2020, Chris Lamb wrote:
> This is a bug to track the progress of uploading Django 3.x to
> unstable.

Hum, this is a long term goal right? Because the next LTS in 3.x
is 3.2 and upstream has not yet released 3.1 and we will get 3.2
only in 2021 AFAIK.

And IIRC our goal was to have only LTS versions in testing/unstable.

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



Bug#959923: dh-linktree: "replace" fails on files in linked directories

2020-05-18 Thread Raphael Hertzog
Hi,

On Thu, 07 May 2020, Norbert Preining wrote:
> When dh-linktree replace is called with a file in a "directory" which is
> a symlink, dh-linktree dies because dpkg-query fails:
> 
> dpkg-query: no path found matching pattern 
> /usr/share/javascript/jquery/jquery.js
> dh_linktree: error: dpkg --search -- /usr/share/javascript/jquery/jquery.js 
> /usr/share/javascript/underscore/underscore.js subprocess returned exit 
> status 1
> 
> We are supposed to use the /usr/share/javascript/jquery/jquery.js file
> but cannot use it to replace copies.

FWIW I no longer have any package using dh-linktree. I will orphan the package
right away as I don't have any willingness to fix this and other open
bugs.

Cheers,

PS: CCing debhelper maintainers in case this specialized tool is of any
interest to them. And Paul who made some backports upldoad in the past.
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS



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

2020-05-13 Thread Raphael Hertzog
Hi,

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

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

:-)

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



Bug#938438: scap-security-guide: Python2 removal in sid/bullseye

2020-05-11 Thread Raphael Hertzog
Hi,

On Fri, 08 May 2020, Jeremy Bicha wrote:
> Maintainers, please indicate whether you are working on a fix or else
> this package will be removed from Debian Unstable soon. (You can
> always reintroduce the package if you remove the Python2
> dependencies.)

I just looked at the upstream source code and it seems to support Python 3
since quite a while.

https://github.com/ComplianceAsCode/content

Philippe, can you take care to prepare an update and get rid of Python 2?

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



Bug#936206: binplist: Python2 removal in sid/bullseye

2020-05-11 Thread Raphael Hertzog
Hi,

On Fri, 08 May 2020, Moritz Mühlenhoff wrote:
> > Your package either build-depends, depends on Python2, or uses Python2
> > in the autopkg tests.  Please stop using Python2, and fix this issue
> > by one of the following actions.
> 
> https://github.com/google/binplist/issues/6 is without any update since 2016 
> and there
> are no reverse deps, let's remove?

No objection from me.

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



Bug#922075: npm: segfault during extract on i386

2020-04-29 Thread Raphael Hertzog
On Tue, 31 Mar 2020, Christian Walther wrote:
> Any news on this? I am seeing the same crash (same gdb backtrace) with
> the nodejs 10.15.2~dfsg-2 and npm 5.8.0+ds6-4 provided by Debian 10 i386
> (on a virtual machine) while using "npm install" on an internal package.

We also have experienced this segfault in Kali while trying to build a
package on .

I'm wondering why this bug was not forwarded upstream?

I know that linux 32 bit is no longer officially supported by
upstream, but are they rejecting bug reports?

It seems that "unofficial builds" are still made and thus bug
reports and fixes are likely accepted, though not handled with
any priority I guess. That would still give more visibility to this issue.

https://unofficial-builds.nodejs.org/

I'm also wondering why i386 and armel are treated differently, given that
both are unsupported upstream (in Debian, i386 is still built, but armel
is no longer built).

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



Bug#876643: Another case of conflicting binaries allowed in the archive

2020-04-22 Thread Raphael Hertzog
Control: severity -1 important

While syncing my Debian mirror with reprepro in the Kali archive, I
got a failure due to a file conflict:
> File "pool/main/z/zeroc-ice/libzeroc-ice-dev_3.7.3-1_arm64.deb" is already 
> registered with
> different checksums!
> md5 expected: 295b24c0644692f31ec3f4dd2b8d6d7b, got: 
> 11aceacca1ae3b0c6ed6b68d89979e1e
> sha256 expected: 
> 2e6c4316b23ce72a99d3f7e124f064723504421c65f239020e258bd0e403efdc, got:
> 38fa33ab7ff8d1426838156a4451ca1c9f31d8a11405a119c17ddc31b4890eb6
> size expected: 4009552, got: 4009752

It looks like some binaries have been removed as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958274 but they have
been reintroduced shortly afterwards due to a bin-NMU.

dak should really remember the removed files and refuse to reintroduce
them. Or at least only reintroduce exact same files.

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



Bug#819136: Bugs included in #819136 patches

2020-04-11 Thread Raphael Hertzog
Hello,

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

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

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

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

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

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



Bug#956226: linux: dh-thin-pool module missing in md-modules udeb, d-i unable to remove thinly provisioned logical volume

2020-04-08 Thread Raphael Hertzog
Source: linux
Version: 4.19.67-2+deb10u2
Severity: normal
Tags: d-i patch

The dm-thin-pool module is required when you want to run d-i on a machine
which contains thinly provisioned logical volumes. Otherwise d-i is unable
to remove them and you see messages like this from partman-lvm:

> modprobe: FATAL: Module dm-thin-pool not found in directory 
> /lib/modules/4.9.0-9-amd64
[...]
> Can't process LV vg_system/lv_system: thin-pool target support missing from 
> kernel?

Thus I attach a patch to add the missing module in md-modules. I have also
included the dependencies (dm-persistent-data and dm-bio-prison), I'm not
sure if it's required...

Cheers,
 Raphaël.

-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
>From 3b91afe0e9bc9626d81ae6695a7072e4bd792ef3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Wed, 8 Apr 2020 17:51:54 +0200
Subject: [PATCH] udeb: add dm-thin-pool in md-modules udeb

That module is required when you want to run d-i on a machine which
contains thinly provisioned logical volumes. Otherwise d-i is unable
to remove them and you see messages like this from partman-lvm:

modprobe: FATAL: Module dm-thin-pool not found in directory /lib/modules/4.9.0-9-amd64
Can't process LV vg_system/lv_system: thin-pool target support missing from kernel?
---
 debian/installer/modules/md-modules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/installer/modules/md-modules b/debian/installer/modules/md-modules
index d4f710406d46..d2da3b835d4f 100644
--- a/debian/installer/modules/md-modules
+++ b/debian/installer/modules/md-modules
@@ -6,9 +6,12 @@ raid0
 raid1
 raid456
 raid10
+dm-bio-prison
 dm-mirror
+dm-persistent-data
 dm-raid
 dm-snapshot
+dm-thin-pool
 bcache
 
 # RAID-related libraries, also used by btrfs
-- 
2.26.0



Bug#955474: FTBFS: fatal error: stropts.h: No such file or directory

2020-04-01 Thread Raphael Hertzog
Control: retitle 954582 FTBFS: fatal error: stropts.h: No such file or directory
Control: forcemerge 954582 -1

I was mislead by the title of the other RC bug, it looks like both are
reporting the same underlying issue.

The proper solution seems to be to rebuild python 3.8 against glibc 2.30
and I just requested this in #955478.

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



Bug#937521: pyrit: Python2 removal in sid/bullseye

2020-03-30 Thread Raphael Hertzog
Hi,

On Sun, 29 Mar 2020, Sandro Tosi wrote:
> so maybe it's time to drop pyrit and it's only reverse dependency
> wifite?

Ack for pyrit. I requested the removal of the package from unstable.

However, wifite works without pyrit. I uploaded a new version dropping
the build-dependency and the suggests on pyrit.

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



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

2020-03-30 Thread Raphael Hertzog
Hello Tom,

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

I saw them.

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

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

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

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

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


This message was created automatically by mail delivery software.

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

  tom@localhost


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

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


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



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

2020-03-30 Thread Raphael Hertzog
Control: forcemerge 901500 -1

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

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

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

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

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


signature.asc
Description: PGP signature


Bug#922533: Review of proposed move of /var/log/account to /var/account

2020-03-28 Thread Raphael Hertzog
Hi,

On Wed, 18 Mar 2020, Marcos Fouces wrote:
> Any DD available for review and upload this new release.

Uploaded!

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



Bug#944553: midori deletes my files

2020-03-26 Thread Raphael Hertzog
Control: severity -1 important

On Tue, 18 Feb 2020, Sergio Durigan Junior wrote:
> Thanks for the report.
> 
> It's not clear from your description whether tmpa_crtoef.htm is the
> only file that triggers this behaviour, or if this happens with any file
> when you try opening it with Midori.
> 
> I gave it a quick try with a simple file here and could not reproduce
> the issue:

Given this and the lack of upstream answer I'm downgrading this bug to
important because midori has been removed from testing due to this
unreproducible issue!

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


signature.asc
Description: PGP signature


Bug#952733: dnsrecon fails in Google Search enumeration due to incorrect urllib functions being used

2020-03-03 Thread Raphael Hertzog
On Fri, 28 Feb 2020, Jonas Andradas wrote:
> new updates performed along the day fixed the issue... sorry for reporting it
> too soon!

What updates? It seems weird that this issue would fix itself.

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



Bug#939641: dnsrecon: Python2 removal in sid/bullseye

2020-02-26 Thread Raphael Hertzog
Control: forwarded -1 https://github.com/darkoperator/dnsrecon/issues/115

On Tue, 25 Feb 2020, Scott Kitterman wrote:
> There is evidence in the upstream commit history [1] that this will work with 
> either python2 or python3, so I sould appreciate it if you could see if 
> switching to python3 works.  If you need help with the packaging changes for 

A quick test shows that this was not extensively tested with Python 3.

I have fixed a few issues that I saw but I'm still going ahead with the
switch.

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


signature.asc
Description: PGP signature


Bug#946519: iptables fails to update rules from fwbuilder

2020-02-12 Thread Raphael Hertzog
Hello,

On Mon, 20 Jan 2020, Arturo Borrero Gonzalez wrote:
> >After upgrading to buster from strech, the iptables defined in fwbuilder 
> > don't works when changed:
> >  iall I get is a message "iptables: Chain already exists" for each rule and 
> > they don't work.
> > 
> >Moreover as I removed network-manager package my system start withour 
> > rules (maybe with default rules) an this moment the script generated by 
> > fwbuilder runs without warnning and rules are applied. Afterwards, if I 
> > tried to aplly diferent rules, I get the warnning messages and the rules 
> > don't work.
> > 
> >At first my system was running the stable version of iptables, 1.8.2-4, 
> > so I move to the testing version, 1.8.3-2, without changes.
> 
> We would need additional information about what ruleset are you (or fwbuilder)
> trying to load.

The user is likely affected by this fwbuilder bug:
https://github.com/fwbuilder/fwbuilder/issues/88

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



Bug#951120: hydra: Non-free licence exception

2020-02-12 Thread Raphael Hertzog
Control: forwarded -1 https://github.com/vanhauser-thc/thc-hydra/issues/497

On Tue, 11 Feb 2020, Dominik George wrote:
> The licence of hydra states:

Actually the LICENSE file does not contain that sentence. It's only in the
README and it has been added 3 years ago

> The additional exception to the AGPL contradicts the Debian Free Software
> Guidelines.

Indeed.

> I propose moving hydra to non-free.

I'd rather convince upstream to fix this. I opened a ticket here:
https://github.com/vanhauser-thc/thc-hydra/issues/497

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



Bug#947847: please install systemd-sysusers using update-alternatives

2020-01-29 Thread Raphael Hertzog
On Wed, 29 Jan 2020, Thomas Goirand wrote:
> echo 'u radvd - "radvd daemon"' | \
>systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf

Does opensysusers support this use case?

If not, you just provided a good reason why it's not a good idea
to use an alternative for systemd-sysusers.

> My idea is to have a single entry point for programs to call the
> sysusers binary. If we collectively decide that it's going to be called
> /bin/foo, then by all means, let's do that. But I don't think it's
> reasonable to say it's going to be called /bin/systemd-bar, and nobody
> can take over this path. This is the wrong answer to the problem.

I do believe it's not a good idea to reuse a systemd binary name for a
generic API, even if that API is a subset of what's provided by
systemd-sysusers.

> I do agree that the data file is the interface, but can you predict
> *ALL* the cases where /bin/systemd-sysusers is called? As much as I
> understand, it could be called by:
> - something debhelper adds to postinst
> - something the maintainer adds manually to postinst
> - the init system itself

There's no need to predict the future, you must analyze the
current situation and go forward from there. AFAIK, we don't have
anything at the debhelper level yet and we can define that debhelper
will call your new /bin/foo^Wcreate-system-users. As for the
service creating users during boot, you can provide a debconf
question giving the option to the user to install an override
of systemd-sysusers.service which actually calls opensysusers.
The question would not be shown by default and would default
to not override systemd-sysusers. It would also not be shown
if systemd is not used.

> And more disturbingly, it could be called by any program that just wants
> to add a user the same way one would just call useradd or adduser. The
> man page for systemd-sysusers even gives a very clear example:

Given that both programs are doing the same thing based on the same input,
I don't see any problem in that. We have dependencies to ensure that
programs are available.

And when we get to the point where the lack of systemd-sysuvers is a
problem, we can always patch programs to use /bin/create-system-users
instead of systemd-sysusers.

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



Bug#947847: please install systemd-sysusers using update-alternatives

2020-01-29 Thread Raphael Hertzog
On Tue, 28 Jan 2020, Thomas Goirand wrote:
> This is exactly what should be avoided. It's perfectly fine to try to
> use opensysusers with systemd if one wants. In fact, that's exactly the
> best way we could do to be able to test it. Also, dpkg-divert is really
> ugly, and something you use as the last resort, when all other options
> have been exhausted.

It's not that ugly if you consider that you are in an experimental phase
where you want to test opensysusers.

Also you seem to imply that the common interface is the systemd-sysusers
binary. I don't think that this is necessarily the case. The common
interface is the file format. The name of the program creating the users
is not important as long as it's properly hooked in the packaging system
and boot sequence.

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



Bug#939260: Ready for Python 3

2020-01-20 Thread Raphael Hertzog
FTR, upstream just notified me that the latest version available on GitHub
is now ready for Python 3:
https://github.com/websploit/websploit

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



Bug#948257: Bug#948350: depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not open builtin file '[...]/lib/modules/[kernelversion]/modules.builtin.bin'

2020-01-16 Thread Raphael Hertzog
Hello,

On Tue, 07 Jan 2020, Marco d'Itri wrote:
> #948257

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#105, Ben is
wondering whether the fix should not be done in kmod since the ERROR
displayed is due to a Debian-specific patch that you applied
(debian/patches/verbose_missing_bin):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#95

Can you please take position and explain why you think this should be
fixed in initramfs-tools when the message is not even displayed
in upstream's kmod ?

The message also seems to appear during a manual kernel build and install:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948257#110

Given all this, it seems cleaner to drop the patch
debian/patches/verbose_missing_bin that you applied.

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


signature.asc
Description: PGP signature


Bug#936243: brutespray: Python2 removal in sid/bullseye

2020-01-14 Thread Raphael Hertzog
On Fri, 10 Jan 2020, Emmanuel Arias wrote:
> I was working on python2 support remove. I prepare a NMU in two MR:
> https://salsa.debian.org/pkg-security-team/brutespray/merge_requests/1
> https://salsa.debian.org/pkg-security-team/brutespray/merge_requests/2
> 
> Please, consider apply it.

Thanks for this! Though it's not really practical to use merge requests to
apply a new upstream release. Next time, better ask someone in the team
to import the new upstream release so that you can work from there...

The merge request doesn't update the upstream tags, it also creates noises
with the merge commits, and lacks the update to pristine-tar.

I did all this manually this time to compensate and I merged your work.
An upload will follow soon.

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



Bug#842565: buildd.debian.org: XDG_RUNTIME_DIR is set but directory does not seem to exist

2020-01-04 Thread Raphael Hertzog
Control: affects -1 schroot

Hi,

On Sun, 30 Oct 2016, Hilko Bengen wrote:
> it seems that at least on the i386 and amd64 buildds, XDG_RUNTIME_DIR is
> set to a nonexisting directory, /run/user/2952.

I have been bitten by this too and chatted with Aurélien Jarno on
#debian-buildd and it seems that this environment variable is set
by the schroot PAM support due to pam_systemd.

But this happens only when the buildd process is started by cron
(such as on official build daemon) and not when it's started manually
after having switched to the buildd user. That's likely some 
special casing done in pam_systemd.

Aurélien summed up his investigation that way:
19:08  i really think the problem is related to libpam-systemd. When 
the buildd process ends up with loginuid != 2952 (e.g. started by hand), 
XDG_RUNTIME_DIR is not set
19:08  when started by cron, it ends up with loginuid = 2952, and then 
XDG_RUNTIME_DIR is set

And a later test confirmed that removing libpam-systemd removed the
environment variable.

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



Bug#948009: blhc: Don't scan dwz invocations seen with DH_VERBOSE=true

2020-01-04 Thread Raphael Hertzog
Hi,

On Sat, 04 Jan 2020, Simon Ruderich wrote:
> On Fri, Jan 03, 2020 at 10:44:10AM +0100, Raphaël Hertzog wrote:
> > https://salsa.debian.org/pkg-security-team/aflplusplus/-/jobs/481494/raw
> 
> Hello,
> 
> could you please provide me with the full raw (= text-only) build
> log so I can reproduce this?

https://buildd.debian.org/status/fetch.php?pkg=aflplusplus=amd64=2.60c-1=1578051979=1

This newer build log also triggers other legitimate errors but it still
has the invalid catch on the dwz invocation.

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



Bug#934207: [Pkg-javascript-devel] Bug#934207: new upstream (12.8.0)

2019-12-26 Thread Raphael Hertzog
On Thu, 8 Aug 2019 10:08:52 +0200 =?UTF-8?B?SsOpcsOpbXkgTGFs?= 
 wrote:
> Yes, take for granted that if you're thinking about upgrading that package,
> i've already started doing it ;)

Thanks for your work on nodejs!

What are your plans to upload nodejs 12.x to unstable?

Cheers,

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



Bug#939260: websploit: Python2 removal in sid/bullseye

2019-12-26 Thread Raphael Hertzog
On Mon, 16 Dec 2019 14:28:33 +0100 Raphael Hertzog  wrote:
> Great. Looking forward to it. Do you have any idea how much time you need
> to complete this Python 3 port of websploit?

On the 21th, I got a private reply saying that he might need 20 days
to complete the Python 3 port.

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



Bug#947387: [Python-modules-team] Bug#947387: python3-pcapy: missing Breaks+Replaces: python-pcapy

2019-12-26 Thread Raphael Hertzog
On Wed, 25 Dec 2019, Emmanuel Arias wrote:
> Raphaël, please could you review my patch?

Reviewed and uploaded.

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



Bug#945723: Upstream progress on python 3 port

2019-12-26 Thread Raphael Hertzog
Hello,

upstream seems to be close to release a Python 3 version, current
WIP is in https://github.com/epinna/weevely3/tree/Debian-master
according to https://github.com/epinna/weevely3/pull/119#issuecomment-568770367

Sending this mail to reset the auto-rm clock, hoping that Samuel will
upload a fixed version once this is ready at the upstream level.

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



Bug#897137: live-build: man -k and apropos don't work in live system

2019-12-19 Thread Raphael Hertzog
Control: tag -1 - patch

On Sat, 28 Apr 2018, Robert Munyer wrote:
> The cause is the command "rm -rf /var/cache/man/*" in
> "/usr/share/live/build/hooks/normal/0190-remove-temporary-files.hook.chroot".
> 
> You can prevent the problem by doing the following before "lb config":

While this fixes this feature, it bloats the image for a feature that is
seldom used.

I'm not sure that I want to apply your patch.

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



Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running

2019-12-18 Thread Raphael Hertzog
On Wed, 18 Dec 2019, Guillem Jover wrote:
> > We could add hundreds of path-based triggers, one for each binary that we
> > reference in our desktop files but we would likely miss any path
> > change... and it would be a bit tedious to maintain.
> 
> I checked the kali package, and the solutions that came to mind were to
> use path-based triggers either on each executable, or just on the PATH
> directories. The first has the problem that you mention about moving
> directories, but the second does not.
> 
> Then instead of looking up these in the dpkg database you could search
> the PATH for the programs, because that's what the .desktop files depend
> on anyway.

Indeed, thanks for the suggestion!

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



Bug#939260: websploit: Python2 removal in sid/bullseye

2019-12-16 Thread Raphael Hertzog
Hello,

On Tue, 10 Dec 2019, 0X0Ptim0Us wrote:
> Got it, thank you. I will work on it

Great. Looking forward to it. Do you have any idea how much time you need
to complete this Python 3 port of websploit?

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



Bug#946460: tcmu: Fix for 32 bit builds

2019-12-11 Thread Raphael Hertzog
Hi,

On Mon, 09 Dec 2019, James Page wrote:
> In Ubuntu, the attached patch was applied to achieve the following:
> 
>   * Resolve issues with compilation on 32 bit architectures:
> - d/p/32bit-size_t-cast.patch: Ensure same type comparison
>   avoiding compilation error.

Thanks, merged this one.

> - d/p/Disable-Werror.patch: Drop, no longer needed.

But not this one, -Werror is generally not a good idea in the context of
Debian.

I wonder why Ubuntu is interested in a build working cleanly with -Werror.

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



Bug#939260: websploit: Python2 removal in sid/bullseye

2019-11-28 Thread Raphael Hertzog
Control: forwarded -1 https://github.com/websploit/websploit/issues/24

On Mon, 02 Sep 2019, Stefano Rivera wrote:
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

I have forwarded this request to the upstream developer through
the above issue and I'm putting him in copy too because I haven't
seen any recent activity from him, neither on GitHub nor on Sourceforge.

Fardin, do you have plans to update websploit to Python 3?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#895787: Fwd: RFS: pcapy/0.11.3-1 [ITA]

2019-11-26 Thread Raphael Hertzog
Hello,

On Mon, 25 Nov 2019, Emmanuel Arias wrote:
> Yes, I will need sponsorship please :)

I sponsored the upload but the package was not 100% ready so I had to fix
a few things:

- it installed documentation in /usr/share/doc/pcapy/ in addition to
  /usr/share/doc/python3-pcapy/

- there was a lintian warning about syntax errors in copyright file

- I saw upstream tests so I added them as autopkgtest

- the last 3 changelog entries have never been uploaded so I merged the 3
  entries into 0.11.4-1

- you missed "Closes: #xxx" tags for two bugs

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running

2019-11-23 Thread Raphael Hertzog
On Fri, 22 Nov 2019, Guillem Jover wrote:
> That still does not explain why this needs to be done outside the dpkg's
> execution context, though?

I don't know any point in dpkg's execution context where we are sure that
we will not install/remove other packages later on.

> Triggers right now should get batched more aggressively than in the
> past. And I'm not quite sure why they would not be preferable to a
> hook which gets executed unconditionally every time, regardless of
> any package unpacking on the interested paths. This is the kind of
> thing triggers were designed to cover. The current way this is
> deployed seems rather iffy to me TBH.

I'm not opposed to use a trigger based solution but how do you expect it
to work? Watching /usr/share/applications doesn't work as there are
packages that don't provide a .desktop files and where we want to
install our own desktop file when the package gets installed.

And I don't want to have to modify all packages for which we are shipping
a .desktop file to install.

We could add hundreds of path-based triggers, one for each binary that we
reference in our desktop files but we would likely miss any path
change... and it would be a bit tedious to maintain.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#943525: Namespaces for Lintian Tags

2019-11-22 Thread Raphael Hertzog
Hi,

On Wed, 20 Nov 2019, Felix Lechner wrote:
> There are many motivations:

Among those motivations, which one is the one that triggered this process
and which one are there as "additional benefits" that you could identify
to justify the change?

> 1. Shortens tag names.

I don't see that as a benefit, we copy/paste the tags into overrides
or full lines into lintian-info. We rarely need to type them.

> 2. Points to the code that issued the tag.

"grep -r" on the codebase has been working well for me. This mapping
is only really needed when you want to dig into the code anyway.

> 3. Frees up name space (good tags are rare).

Can you show examples of how this would help you concretely?

I have a hard time seeing how difficult it can be to invent
a new name for a new tag.

> 4. Multiple checks can use the same tag in different contexts (i.e. 
> 'spelling').

spelling-error-in-binary
spelling-error-in-description
spelling-error-in-changelog
etc

is perfectly fine.

> 5. Preempts name conflicts in case some check-writing is delegated to
> expert teams.

This is not a real problem, that's the kind of pseudo-benefit that you
try to imagine to justify the change that you want (I have done
that many times ;-)).

> 6. Quicker to split large checks when components reuse tag names.

I don't follow you. For me splitting checks means they get renamed and
thus your tag names are renamed too.

> 7. Brings consistency between Lintian and custom profile users, such
> pkg-perl-tools and pkg-js-tools, who already have private namespaces.

A very minor benefit IMO.


Now can you do the same analysis with the disadvantages?

Since the check is embedded in the tag name:
* It's harder to move a tag from one check to another.
* It's harder to rename a check.

What else can you come up with?

> The change is technically easy. (Lintian even has a way to track
> renamed tags for overrides.) On an optical level, however, the change

I was about to ask for overrides, but this would be a massive usage of
this rename feature and it will confuse many persons. People will start
to use the new name in overrides to avoid this confusion and it won't work
with old lintians (not a big deal but still).

> will affect a lot of people. It could even cause headaches for some
> users, for example in derivatives. We would like to solicit your
> input.

What kind of headaches are you referring to?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



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

2019-11-22 Thread Raphael Hertzog
Hello,

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

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

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

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

Basically, there's no easy fix currently.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#945131: dpkg: implement a way to wait to detect whether dpkg is running

2019-11-20 Thread Raphael Hertzog
Hi,

On Wed, 20 Nov 2019, Guillem Jover wrote:
> > To achieve this in a more elegant way, could you possibly implement some
> > "dpkg --is-running" test ? And/or maybe "dpkg --wait-lock-release" or
> > something similar ?
> 
> I'm not sure I understand why this is not done say via a trigger
> instead? Also why this script cannot just called within the postinst
> w/o putting it on the background?

The package provides many desktop files and the associated icons. The
script scans the list of installed packages and installs/uninstalls the desktop
files corresponding to each package (we have a mapping desktop-file <-->
binary package). The script might use dpkg-divert if the target desktop file
already exists for some reason.

As a long as dpkg is running, we might install/remove packages and it
might affect the set of desktop files to install/remove. Thus doing
it only in the postinst is not a viable option.

Also I just want to perform the operation once, after all package
operations have been completed. But path-based triggers are of no help
as I really have to monitor the installation/removal of many packages.
A named trigger would require changes in the hundreds of packages that
can affect the menu. And the reason of kali-menu is precisely because
we didn't want to have to fork hundreds of packages.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#943953: linux: DKMS module builds are failing on arm64 due to lack of armhf cross-compiler

2019-11-04 Thread Raphael Hertzog
Control: tags -1 - moreinfo

Hi,

On Sat, 02 Nov 2019, Ben Hutchings wrote:
> I already communicated this via IRC, but I thought it should be logged
> in the BTS too: I have a tentative fix for this in <
> https://salsa.debian.org/benh/linux.git> branch bug943953.  I don't
> have an arm64 system to test it on though.

Steev tested it and replied to you on IRC:
03:09  bwh: buxy: tested on two different arm64 machines, seems to be 
working

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


signature.asc
Description: PGP signature


Bug#943709: Pyside2 package dependencies do not reflect Python module dependencies

2019-10-29 Thread Raphael Hertzog
Hi,

On Mon, 28 Oct 2019, Mark Weyer wrote:
> Package: python3-pyside2.qtgui
> Version: 5.11.2-3+rpi1
> Severity: normal
> 
> This bug is reported against an example package but is more general. Thus it
> pertains to more binary packages built from the same source package pyside2

Can you be a bit more explicit?

What sample dependencies are missing? Where do you see what you call "Python
module dependencies"?

Are you just basing this on the analysis of "import" statements or
something else?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#942126: gvfs-fuse: /run/user/ID/gvfs/ empty after upgrade

2019-10-28 Thread Raphael Hertzog
Control: severity -1 serious

Hi,

On Tue, 22 Oct 2019, Cesare Leonardi wrote:
> Ok, I confirm that replacing fuse with fuse3, as reported by Bert, make
> gvfs-fuse works as expected, with /run/user/ID/gvfs/ populated again.
> So please, consider to tighten gvfs-fuse dependencies on fuse3.

I was hit by this issue as well and installing fuse3 resolved the problem.
Given the simple fix and the fact that it's a clear regression I'm bumping
the severity of the bug.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#938797: volatility: Python2 removal in sid/bullseye

2019-10-19 Thread Raphael Hertzog
Control: tag -1 + fixed-upstream

On Fri, 30 Aug 2019, Matthias Klose wrote:
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

There's a volatility 3.0 that works with Python 3:
https://github.com/volatilityfoundation/volatility3

We should package it! Putting in CC the uploaders of volatility.

Cheers,

PS: I filed https://github.com/volatilityfoundation/volatility3/issues/95
requesting a 3.x release because right now they provide volatility3
version 1.0.0 :(
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#927135: src:rekall: Please update to python3 version

2019-10-18 Thread Raphael Hertzog
Hi,

On Fri, 18 Oct 2019, Moritz Mühlenhoff wrote:
> > I started having a look at packaging the new upstream release of
> > rekall, to support python 3 (mostly because rekall is a r-dep of some
> > of the packages i maintain). For now it looks like the most immediate
> > need is to get aff4 ported to python3, as it's a strong dependency of
> > rekall, so i filed #936091
> 
> JFTR, src:pyaff4 is now in the archive.

We prepared the update in git a while ago, I uploaded it to experimental
because I'm not sure that it's really working at this point. I'm not a
rekall user and would like Hilko and/or Sasha to have a look at it.

But I wanted to upload it right now because of the binary-NEW delay that
we will have in any case...

In fact, I'm pretty sure it's broken. I get the same error when I run
debian/tests/linux-image-tests and when I run "rekal --filename
/proc/kcore":

[...]
  File "/usr/lib/python3/dist-packages/rekall/plugins/addrspaces/aff4.py", line 
125, in __init__
os.path.join(cache_dir, "aff4_cache")))
TypeError: Set() missing 1 required positional argument: 'value'

Looks like rekall needs an older version of pyaff4 :-(

https://github.com/google/rekall/issues/493

Since rekall is the only reverse dependency I will likely prepare
a 0.27+really0.26.post6 for python3-pyaff4 unless you feel like patching
the code for this update:
https://github.com/aff4/pyaff4/commit/c72c52ab1faea21ca1afb331d5bdf31270fe3dc2

I don't know if there are others API breaking change in 0.27.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

2019-10-18 Thread Raphael Hertzog
On Thu, 17 Oct 2019, Ximin Luo wrote:
> Who is using reprepro to archive Debian Rust packages? That's the first

Anybody who is mirroring Debian unstable with reprepro right now. I have
no special interest in rust, but I do maintain a debian derivative
that we build with reprepro merging debian testing and our own packages
(and we mirror unstable as well because we cherry-pick fixes from unsatble
from time to time, hence the reason why I discovered this before it has
his testing).

> time I've heard of this. I suspect this is a small number (its popcon
> [1] is less than that of rustc itself), and that they will be perfectly
> happy to upgrade to a fixed version of reprepro.

Such a fixed version will not magically appear and will not be magically
deployed. I have no problem upgrading to a newer reprepro once there's a
fixed version but I do still believe that your use of Provides is abusive
and that you should rethink the approach.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

2019-10-17 Thread Raphael Hertzog
Hello Ximin,

On Thu, 17 Oct 2019, Ximin Luo wrote:
> >> Do you have some concrete suggestions on how to improve the tool to reduce 
> >> this "abuse"?
> > 
> > Yes, I gave you one.
> 
> It doesn't work.

Look, I'm not a cargo/rust expert, I won't design the tool for you but I
implemented dpkg-gensymbols and the symbols support for dpkg-shlibdeps
and I'm pretty confident that such a solution can work for your case too.

We are not adding a provides to libc6 for each symbol that the library is
exporting. And you should not add a provides for each "interface" (or
whatever it's called in rust) that a package is providing.

You should export the list of interfaces in a separate metadata file thas
is not part of the generated "Packages" file and you should have a tool to
generate the binary dependencies pointing back to the correct package that
is exporting the interface.

It might not be as flexible as the current approach as it might require
rebuilds when the package providing the interface changes, but that's
quite usual in Debian.

> > You are being arrogant. Replying in the same tone, I would say that the
> > design of your tool suck.
> 
> That's cool, and it really doesn't persuade me to have any sympathy
> towards your issue. Note that the next time this package is
> automatically regenerated, your "fixes" will be undone.

Note that if you re-introduce the issue I will ask ftpmasters to
remove the package and/or ask the tech-ctte to decide about it.

(I can play that game too... but it's not helping)

You can't just ignore problems when you are breaking the infrastructure of
derivative distributions and users... right now the problem is limited to
unstable and I'm the first to have discovered it but I'm pretty confident
that others will hit it as well.

And as I said, those servers are not running unstable so if you really
want to go down the route of fixing reprepro (while ignoring the fact
that Ansgar, who is a ftpmaster, is asking you to not continue with such a
Provides header), you will have to get fixes pushed to stable...

> Please be a bit more self-critical about your own opinion. Have you
> considered the possibility that it is the reading tool (reprepro in this
> case) that "sucks" and not the writing tool?

Yes, reprepro sucks in some ways. But a design that puts 270K of metadata
in a single Provides line sucks too.

But reprepro is in wide use and your new package is the first one to
trigger the limit. You can't just ignore the reality, you have to cope
with the fact that we have reprepro users and that we can't deploy
a package with 270K-long Provides header currently.

(And IMO we should never allow this but that's another discussion)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#942487: [Pkg-rust-maintainers] Bug#942487: Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

2019-10-17 Thread Raphael Hertzog
On Thu, 17 Oct 2019, Ximin Luo wrote:
> Can you please explain why 256 KB provides field is "abuse"?

Because that's the amount of metadata required for 250 common packages.

> Do you have some concrete suggestions on how to improve the tool to reduce 
> this "abuse"?

Yes, I gave you one.

> BTW, the tool is run not at build time but to generate the source
> package. So it can't use these "foo.cargo" files, because you don't need
> to install all of the dependencies in order to use the tool.

If you run a tool to generate the source package, you can include
whatever call you want during your source package build. i.e. you
control debian/rules too. And you can process the source package
and/or the binary package built to create those meta-information
and also to use the existing meta-information on the system.

> It is 2019. If a tool can't handle 256 KB of data, I'd say the tool is
> at fault and not the 256 KB of data.

You are being arrogant. Replying in the same tone, I would say that the
design of your tool suck.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#942487: [Pkg-rust-maintainers] Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

2019-10-17 Thread Raphael Hertzog
Hi,

On Thu, 17 Oct 2019, Sylvestre Ledru wrote:
> I will see how to add a lintian check to block that from happening again.

FWIW, I already filed #942493 against lintian this morning.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#942487: [Pkg-rust-maintainers] Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

2019-10-17 Thread Raphael Hertzog
On Thu, 17 Oct 2019, Ximin Luo wrote:
> Control: tags -1 + wontfix

This is clearly not acceptable. You can't ignore problems like this one.
I saw you already broke debian-installer once with the former packages
that overflowed the 16K limit of cdebootstrap. Now it's the turn of
reprepro and this one is harder to fix because there are real servers
running stable version of reprepro, etc.

> The tool's algorithm was suggested by the maintainer of dpkg and has his
> blessing. It is partly due to limitations in dpkg, see #901827 for
> details.

The algorithm is one thing... but the design of your tool is another
thing.

dpkg has dpkg-shlibdeps to build dependencies based on exported
information by various package (through
/var/lib/dpkg/info/*.{shlibs,symbols}).

cargo should build the same infrastructure, i.e. have a
/var/lib/dpkg/info/foo.cargo used by dh-cargo to build the correct
dependency.

Don't abuse the "Provides" field when you have such a volume of
interfaces to document.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#942487: rust-web-sys: Provides header is more than 256K long and it breaks reprepro...

2019-10-17 Thread Raphael Hertzog
On Thu, 17 Oct 2019, Raphaël Hertzog wrote:
> For this reason, I'm going to NMU the package and disable/reduce the Provides
> field until you find a reasonable solution.

Uploaded rust-web-sys_0.3.28-1.1_source.changes. It's still 150K but
should make reprepro happy.

I believe it's unreasonable to hardcode so many "interfaces" in the
provides field, in particular when you represent each interface with 4
different versioned variants.

Will all the package really have an auto-generated Depends line listing
all those interfaces ?

FWIW, IRC discussion on #debian-devel concurred that it was really not 
reasonable.

And as a data point:
09:30  Longest Provides currently in unstable/amd64: 277987 
librust-web-sys;  59926 librust-winapi;  7505 oca-addons-account;  3357 
librust-x11+default-dev;  3280 librust-slog+default-dev
09:31  So at least it's only very few packages that have this problem.

But from the top 5, 4 are rust packages. And this one is like 40 times
bigger than the next non-rust package with a big provides line...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#936730: [Python-modules-team] Bug#936730: impacket: Python2 removal in sid/bullseye

2019-10-17 Thread Raphael Hertzog
Hi,

On Wed, 16 Oct 2019, Emmanuel Arias wrote:
> Hello! Raphael
> 
> I've write a comments on mentors. I don't know if you coulld see it

No, I didn't get any mail through mentors. Anyway, reviewed and uploaded.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#942104: release.debian.org: Will fail if "Suite" field is missing

2019-10-10 Thread Raphael Hertzog
Control: tag -1 + patch

On Thu, 10 Oct 2019, Ansgar wrote:
> https://wiki.debian.org/DebianRepository/Format#A.22Release.22_files
> says one of Suite and Codename is required.  Codename itself is not required.

Ok.

> I wouldn't be surprised if many tools just use one and assume it always
> exists and would recommend to always provide both.

Well, that's not really an option for me right now. Because APT will just
complain if you add a "Suite" when it was missing before hand.

In any case, here's a suggested patch (attached).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/
>From 31acf2e02241082e6bce5419cabb42e8ab950775 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Thu, 10 Oct 2019 15:00:00 +0200
Subject: [PATCH] Fall back to codename if Suite is not available

---
 britney2/inputs/suiteloader.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/britney2/inputs/suiteloader.py b/britney2/inputs/suiteloader.py
index 665b66f..ae77785 100644
--- a/britney2/inputs/suiteloader.py
+++ b/britney2/inputs/suiteloader.py
@@ -143,8 +143,8 @@ class DebMirrorLikeSuiteContentLoader(SuiteContentLoader):
 release_file = None
 
 if release_file is not None:
-suite.name = release_file['Suite']
-self.logger.info("Using suite name from Release file: %s", release_file['Suite'])
+suite.name = release_file.get('Suite', release_file['Codename'])
+self.logger.info("Using suite name from Release file: %s", suite.name)
 
 def _check_release_file(self, target_suite, missing_config_msg):
 try:
-- 
2.23.0



Bug#939626: Upstream

2019-10-04 Thread Raphael Hertzog
Control: tag -1 fixed-upstream

On Wed, 11 Sep 2019 14:00:54 +0200 =?utf-8?Q?S=C3=A9bastien?= Delafond 
 wrote:
> Upstream indicates that:
> 
>   We are working actively on that subject. So the next release of
>   centreon-broker won't need qt4 nor qt5. Qt will be completely removed
>   from it. We hope this change to be finish for the next release of
>   Centreon.
> 
> This is targetted for 19.10, to be released in October 2019.

Sending this mail to avoid the testing autoremoval and giving us more
time, basically waiting for the new upstream release.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#936730: [Python-modules-team] Bug#936730: impacket: Python2 removal in sid/bullseye

2019-10-03 Thread Raphael Hertzog
Hello,

On Tue, 01 Oct 2019, Emmanuel Arias wrote:
> I've just push to salsa and mentors
> (https://mentors.debian.net/package/python-ldapdomaindump)
> ldapdomaindump, maybe you can sponsor it :) thanks

I can sponsor it but first I'd like you to make some changes:

1/ fix the Vcs-Git and Vcs-Browser URL to match the correct location
   on salsa.debian.org

2/ point 1 prove that you based your work on the kali package so please
   credit Kali in the changelog and keep the Kali copyright notice for the
   debian/* files in debian/copyright.

3/ please reuse the same .orig.tar.gz (bit for bit!) for Debian as what we
   used in Kali, otherwise Kali will not be able to import the Debian
   package due to different conflicting files with the same name
   (you have to redo "pristine-tar commit " manually with
   the correct file).

$ wget 
http://http.kali.org/pool/main/p/python-ldapdomaindump/python-ldapdomaindump_0.9.1.orig.tar.gz
$ sha1sum python-ldapdomaindump_0.9.1.orig.tar.gz 
7df22d1fb6207e71c93abad6fa5e92179aa8b548  
python-ldapdomaindump_0.9.1.orig.tar.gz

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#875190: [shiboken] Future Qt4 removal from Buster

2019-10-01 Thread Raphael Hertzog
On Tue, 01 Oct 2019, Didier 'OdyX' Raboud wrote:
> > There are no reverse dependencies of src:shiboken in unstable and it has
> > been replaced by src:pyside2, let's remove from the archive?
> 
> As maintainer: agreed!

Can you file the RM request then?

Thank you.
-- 
Raphaël Hertzog ◈ Debian Developer

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


signature.asc
Description: PGP signature


Bug#936730: [Python-modules-team] Bug#936730: impacket: Python2 removal in sid/bullseye

2019-09-30 Thread Raphael Hertzog
Hello,

On Sun, 29 Sep 2019, Emmanuel Arias wrote:
> Thanks for your help and sorry for the my bad things on the package.

No problem.

> I have some question for you: Why impacket was uploaded to NEW?

Because python3-impacket was never in the archive, it's a NEW binary
package (even though the source package is not new).

> If you restored python-impacket the build dependecies was not restored?

I did restore the build dependencies:

Build-Depends: debhelper-compat (= 12),
   python-all,
   dh-python,
   python-setuptools,
[...]

Cheers,

> El dom., 29 de sep. de 2019 a la(s) 10:42, Raphael Hertzog
> (hert...@debian.org) escribió:
> >
> > Hi,
> >
> > On Fri, 27 Sep 2019, Emmanuel Arias wrote:
> > > I've just push to salsa the last changes.
> > > I will need sponsorship to upload it.
> >
> > I took care of it. But I reverted the removal of python-impacket for
> > now, it still has reverse dependencies in Debian (and even more in Kali).
> >
> > I had to cleanup a few things too, there was some upstream doc installed
> > in a wrong directory (/usr/share/doc/impacket). The changelog was
> > mishandled, the UNRELEASED entry for 0.9.19 should have been merged with
> > the 0.9.20.
> >
> > And I had to rename debian/{install,links,examples} to 
> > debian/python3-impacket.*
> > but that's because I restored python-impacket. But in general, I find it
> > better to be explicit about the target package so I tend to avoid the
> > former names.
> >
> > You had already pushed a tag, in general it's best when the uploader
> > pushes the tag so that if he has something to correct, he can do it.
> > Thus I dropped your tag and you will have to drop it on your side if you
> > want to get the correct one.
> >
> > Cheers,
> >
> > > El jue., 26 de sep. de 2019 a la(s) 17:02, Sophie Brun (
> > > sop...@offensive-security.com) escribió:
> > >
> > > > Hi Emmanuel,
> > > >
> > > > ldapdomaindump is not in Debian but I packaged it for Kali last year.
> > > > The repo is here:
> > > > https://gitlab.com/kalilinux/packages/python-ldapdomaindump
> > > > I don't remember if the package is totally compliant with the Debian
> > > > policy but you can reuse it and improve it for Debian.
> > > >
> > > > For impacket: I build the package with the Kali package
> > > > python3-ldapdomaindump: no tests are really run.
> > > > I think we can just override dh_auto_test for the moment.
> > > >
> > > > I push few changes including a patch to avoid the installation of the
> > > > examples/*py as scripts in usr/bin/
> > > > There were not in usr/bin in python-impacket and I think it's better to
> > > > not have all these scripts in /usr/bin (but it's only my personal 
> > > > opinion).
> > > >
> > > > Cheers,
> > > >
> > > > Sophie
> > > >
> > > >
> > > > Le 26/09/2019 à 17:06, Emmanuel Arias a écrit :
> > > > > Hi Sophie, take care that I push some changes to salsa.
> > > > >
> > > > > the test are failing because |ldapdomaindump is not in debian (that is
> > > > correct?) I will package |ldapdomaindump.||
> > > > > ||
> > > > > ||
> > > > > ||So I think that the best solution is patch the tests to skipped it 
> > > > > and
> > > > in  new version (when |ldapdomaindump) is in|||
> > > > > |||debian create a new version|||
> > > > > |||
> > > > > |||
> > > > > |||any suggestion?|||
> > > > > |||
> > > > > |||
> > > > > Cheers,
> > > > > Arias Emmanuel
> > > > > @eamanu
> > > > > http://eamanu.com
> > > > >
> > > > >
> > > > > El jue., 26 de sep. de 2019 a la(s) 11:03, Sophie Brun (
> > > > sop...@offensive-security.com <mailto:sop...@offensive-security.com>)
> > > > escribió:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Le 26/09/2019 à 15:18, Emmanuel Arias a écrit :
> > > > > > I will update the package.
> > > > >
> > > > > I started to update the package (I need it for the reverse depends
> > > > in pkg-security team)
> > > > >
> > > > > Can I push my changes on the git repo or maybe you prefer to 
> > > > > update
> > > > everything yourself?
> > > > >
> > > > > Cheers,
> > > > > Sophie
> > > > >
> > > >
> >
> > --
> > Raphaël Hertzog ◈ Debian Developer
> >
> > Support Debian LTS: https://www.freexian.com/services/debian-lts.html
> > Learn to master Debian: https://debian-handbook.info/get/
> >
> 

-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#936730: [Python-modules-team] Bug#936730: impacket: Python2 removal in sid/bullseye

2019-09-29 Thread Raphael Hertzog
Hi,

On Fri, 27 Sep 2019, Emmanuel Arias wrote:
> I've just push to salsa the last changes.
> I will need sponsorship to upload it.

I took care of it. But I reverted the removal of python-impacket for
now, it still has reverse dependencies in Debian (and even more in Kali).

I had to cleanup a few things too, there was some upstream doc installed
in a wrong directory (/usr/share/doc/impacket). The changelog was
mishandled, the UNRELEASED entry for 0.9.19 should have been merged with
the 0.9.20.

And I had to rename debian/{install,links,examples} to debian/python3-impacket.*
but that's because I restored python-impacket. But in general, I find it
better to be explicit about the target package so I tend to avoid the
former names.

You had already pushed a tag, in general it's best when the uploader
pushes the tag so that if he has something to correct, he can do it.
Thus I dropped your tag and you will have to drop it on your side if you
want to get the correct one.

Cheers,

> El jue., 26 de sep. de 2019 a la(s) 17:02, Sophie Brun (
> sop...@offensive-security.com) escribió:
> 
> > Hi Emmanuel,
> >
> > ldapdomaindump is not in Debian but I packaged it for Kali last year.
> > The repo is here:
> > https://gitlab.com/kalilinux/packages/python-ldapdomaindump
> > I don't remember if the package is totally compliant with the Debian
> > policy but you can reuse it and improve it for Debian.
> >
> > For impacket: I build the package with the Kali package
> > python3-ldapdomaindump: no tests are really run.
> > I think we can just override dh_auto_test for the moment.
> >
> > I push few changes including a patch to avoid the installation of the
> > examples/*py as scripts in usr/bin/
> > There were not in usr/bin in python-impacket and I think it's better to
> > not have all these scripts in /usr/bin (but it's only my personal opinion).
> >
> > Cheers,
> >
> > Sophie
> >
> >
> > Le 26/09/2019 à 17:06, Emmanuel Arias a écrit :
> > > Hi Sophie, take care that I push some changes to salsa.
> > >
> > > the test are failing because |ldapdomaindump is not in debian (that is
> > correct?) I will package |ldapdomaindump.||
> > > ||
> > > ||
> > > ||So I think that the best solution is patch the tests to skipped it and
> > in  new version (when |ldapdomaindump) is in|||
> > > |||debian create a new version|||
> > > |||
> > > |||
> > > |||any suggestion?|||
> > > |||
> > > |||
> > > Cheers,
> > > Arias Emmanuel
> > > @eamanu
> > > http://eamanu.com
> > >
> > >
> > > El jue., 26 de sep. de 2019 a la(s) 11:03, Sophie Brun (
> > sop...@offensive-security.com )
> > escribió:
> > >
> > > Hello,
> > >
> > > Le 26/09/2019 à 15:18, Emmanuel Arias a écrit :
> > > > I will update the package.
> > >
> > > I started to update the package (I need it for the reverse depends
> > in pkg-security team)
> > >
> > > Can I push my changes on the git repo or maybe you prefer to update
> > everything yourself?
> > >
> > > Cheers,
> > > Sophie
> > >
> >

-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#936730: impacket: Python2 removal in sid/bullseye

2019-09-26 Thread Raphael Hertzog
control: forwarded -1 https://github.com/SecureAuthCorp/impacket/issues/663
control: tag -1 + fixed-upstream

Hi,

On Fri, 30 Aug 2019, Matthias Klose wrote:
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html

There's a new upstream release 0.9.20 that now supports Python 3.
We should package it first so that we can then fix reverse depends.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#940699: scapy: Please drop the "Breaks" on python-scapy or restore the python 2 package

2019-09-19 Thread Raphael Hertzog
Hi,

On Thu, 19 Sep 2019, Iain R. Learmonth wrote:
> I've prepared an upload that drops the Breaks: from the package. I am
> not using the Python 2 version of the package, nor do I really want to
> have to test that version. If you wanted to adopt the package,
> especially as it has more rdeps in Kali than Debian, then I think that
> would make sense and you'd be able to bring back the Python 2 package
> yourself, and also better maintain it to support Kali better going
> forward. If you choose to do this, please drop me from Uploaders and
> also feel free to move the package into the security packaging team or
> some other appropriate location.

Ok, I will take over the package in the pkg-security team.

Thanks for your quick feedback!
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#934691: rekall: maintainer address bounces

2019-09-11 Thread Raphael Hertzog
Control: tag -1 + pending

On Tue, 13 Aug 2019, peter green wrote:
> While sending https://lists.debian.org/debian-python/2019/08/msg00072.html I 
> got
> 
>   forensics-de...@lists.alioth.debian.org
> (generated fromrek...@packages.debian.org)
> host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
> SMTP error from remote mail server after RCPT 
> TO::
> 550 Unrouteable address

The maintainer email has been fixed in git a long time ago but no upload
happened so far. I wanted to wait for the python 3 conversion but since
it might take some time still, I'll go ahead with an upload right now
to get this RC bugs out of the picture.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#927135: src:rekall: Please update to python3 version

2019-08-26 Thread Raphael Hertzog
Hi,

On Sun, 25 Aug 2019, Scott Kitterman wrote:
> If you have lost interest in the package, please let me know so I can ask to 
> have it removed.

Don't remove rekall please. There's a new upstream release with Python 3
support. We will get to it eventually.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#935278: postrm does not remove user/group on purge

2019-08-21 Thread Raphael Hertzog
Hello,

On Wed, 21 Aug 2019, INetSim wrote:
> Package: inetsim
> Version: 1.2.7+dfsg.1-1
> Severity: normal
> 
> The postrm script does not remove user/group inetsim on purge.

That's actually a common practice, in particular when the user/group
tends to own data files that might survive the package removal.

You don't want another user/group to take over the left-over data
files generated by inetsim.

I don't know whether inetsim generates any such data files but
in the general case I do not consider this a bug.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#934483: virtualbox-guest-dkms: Doesn't build with latest kernel in unstable 5.2.0-2-686-pae

2019-08-19 Thread Raphael Hertzog
On Sun, 11 Aug 2019, Christian Marillat wrote:
> But bevare fixind the include file path (drm/ttm/ttm_page_alloc.h) doesn't
> work at all the virtualbox doesn't start.

I fixed the path, the build went through. I rebooted my VM and it worked.

What exactly was the failure that you had? Did you have some error message
in the kernel logs?

However on the gdm3 login screen, after I have input my login/password,
the picture stays fixed and I have to resize the window or force a VT
switch to get it working again...

In the kernel log I see this:
> [drm] Error -12 pinnning new fb, out of video mem?

And as you mentionned in your other mail, if I increase the allocated
memory for video to 32 Mb (I had 16), this problem goes away.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#934483: virtualbox-guest-dkms: Doesn't build with latest kernel in unstable 5.2.0-2-686-pae

2019-08-19 Thread Raphael Hertzog
Hi,

On Thu, 15 Aug 2019, Darsey Litzenberger wrote:
> I haven't gotten around to testing, but it looks like maybe all that needs
> to be done is to disable building some of these modules after a certain
> kernel version.

At least I can confirm that if you disable "vboxvideo" from the
dkms configuration (in dkms.conf and Makefile in the
/usr/src/virtualbox-guest-6.0.10/ directory), then the DKMS build
works.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#932506: elastalert: (build-)depends on cruft packages.

2019-08-17 Thread Raphael Hertzog
Control: tag -1 + confirmed upstream fixed-upstream

Hi,

On Sat, 20 Jul 2019, peter green wrote:
> elastalert (build-)depends on the python-croniter binary package which
> is no longer built by the python-croniter binary package.
> 
> If you want to keep your package in Debian you will probablly need to
> migrate to python 3.

There's a new upstream release compatible with Python 3. We will update
the package next week (mainly replying this to reset the timer for the
autoremoval from testing).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



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

2019-07-20 Thread Raphael Hertzog
Hi,

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

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

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

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


signature.asc
Description: PGP signature


Bug#931919: debian-handbook: Debian Handbook for Debian Buster

2019-07-13 Thread Raphael Hertzog
Hello,

On Fri, 12 Jul 2019, tkoeck wrote:
> are there any plans to update the book to Debian Buster? As far as I
> have seen it's just for Debian Jessie.

Yes, we're working on it in the git repository. We don't know yet when we
will be done...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#931361: ettercap: Please update to new version 0.8.3

2019-07-03 Thread Raphael Hertzog
Hi,

On mer., 03 juil. 2019, Sophie Brun wrote:
> I would like to propose you to join the pkg-security-team
> to maintain this package. If you are interested:
> https://wiki.debian.org/Teams/pkg-security

Barak, if you are interested, we can help you to move/setup the packaging
repository and to prepare the update for 0.8.3. Just let us know.

BTW, Gianfranco Costamagna who is among the Uploaders is already part of
the pkg-security team.

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



Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

2019-07-02 Thread Raphael Hertzog
Hi,

sorry for the delay.

On Fri, 28 Jun 2019, Michael Biebl wrote:
> Could you give the packages at
> https://people.debian.org/~biebl/systemd/buster/ a try?

It seems to work for me:

$ sudo sysctl net.ipv6.conf.default.disable_ipv6=1
net.ipv6.conf.default.disable_ipv6 = 1
$ cat /etc/systemd/network/test.netdev 
[NetDev]
Name=test
Kind=dummy
$ cat /etc/systemd/network/test.network 
[Match]
Name=test

[Network]
Address=192.168.5.1/24
Address=abcd:abcd:abcd:abcd::1/64
$ sudo systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; 
vendor preset: enabled)
   Active: inactive (dead)
 Docs: man:systemd-networkd.service(8)
$ sudo systemctl start systemd-networkd
$ sudo systemctl status systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/lib/systemd/system/systemd-networkd.service; disabled; 
vendor preset: enabled)
   Active: active (running) since Tue 2019-07-02 10:45:21 CEST; 1s ago
 Docs: man:systemd-networkd.service(8)
 Main PID: 1235 (systemd-network)
   Status: "Processing requests..."
Tasks: 1 (limit: 4915)
   Memory: 1.8M
   CGroup: /system.slice/systemd-networkd.service
   └─1235 /lib/systemd/systemd-networkd

juil. 02 10:45:21 x260-buxy systemd[1]: Starting Network Service...
juil. 02 10:45:21 x260-buxy systemd-networkd[1235]: test: netdev ready
juil. 02 10:45:21 x260-buxy systemd-networkd[1235]: enp0s31f6: Gained IPv6LL
juil. 02 10:45:21 x260-buxy systemd-networkd[1235]: Enumeration completed
juil. 02 10:45:21 x260-buxy systemd[1]: Started Network Service.
juil. 02 10:45:21 x260-buxy systemd-networkd[1235]: test: Gained carrier
juil. 02 10:45:21 x260-buxy systemd-networkd[1235]: test: An IPv6 address is 
requested, but IPv6 is disabled by sysctl, ignoring.
juil. 02 10:45:21 x260-buxy systemd-networkd[1235]: test: Configured

> The debdiff is larger then I had hoped, so I'm not sure if the SRMs will
> ack this changeset. It's quite well possible that I messed something up
> when doing the backport, so aaving at least a confirmation that it fixes
> the issue at hand would be welcome.

Thank you for this work!

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


signature.asc
Description: PGP signature


Bug#930719: autopkgtest: Hangs with qemu backend when copyup destination failed

2019-06-28 Thread Raphael Hertzog
On Wed, 19 Jun 2019, Raphaël Hertzog wrote:
> In Kali we do have a debci setup at autopkgtest.kali.org, we have
> configured it to use the qemu backend. Unfortunately, after a while
> all our workers were stuck... upon investigation it looks like that
> autopkgtest can get stuck with the qemu backend when the VM image
> is not big enough for the "copyup" operation to complete.

That diagnostic was wrong. The size of the image was not the problem.
In fact the failing "copyup" was copying from the VM back into the host.
We use a "tmpfs" for TMPDIR and /var/lib/debci/tmp so that all autopkgtest
files get copied there (qemu overlay and everything)... but that tmpfs was
badly sized:
# grep debci /etc/fstab 
tmpfs   /srv/debci/tmp  tmpfs   
size=300G,nr_inodes=300k,rw,uid=debci,gid=debci,mode=755 0 0

The 300k inodes was too small, thunderbird alone has 327000 files in its
source package. Thus the copy operation was failing. Still, it would be
nice if autopkgtest could avoid to get stuck in such situations...

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#929469: systemd-networkd: systemd-networkd: fails with "could not set address: Permission denied"

2019-06-27 Thread Raphael Hertzog
Hi,

On Wed, 26 Jun 2019, Michael Biebl wrote:
> I agree. While setting up an IPv6 address and at the same time disabling
> IPv6 on the kernel side could be seen as a misconfiguration, it might
> just as well be plain oversight on the admin's side.
> networkd behaving more sensibly in that case is certainly desirable,
> including logging about this issue (and afaics this is what the upstream
> patch set does via log_info).

Indeed, it prints a nice warning.

> TBH, I'm not even sure if it should be added to NEWS.
> NEWS entries are shown to almost everyone. If we flood users with NEWS
> entries they are not affected by, they will get into a habit of ignoring
> NEWS entries.
> Fwiw, I really struggled whether to add a NEWS entry for the
> video->render group change for exactly this reason.

The net result of this problem is a server that is not reachable after a
reboot so it can certainly be argued that it's worth documenting. It could
be a debconf prompt that happens only when systemd-networkd is active
and when ipv6 is disabled, but TBH the time spent in writing this code
would be just as well spent backporting the upstream fix.

I do believe it's worth a point release fix. Unfortunately, I don't have
any spare cycle to spend on this issue... I invested a lot of time in
debugging it already.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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


signature.asc
Description: PGP signature


Bug#931017: dkms: "install" loads modules immediately, and loads more than the newly installed modules

2019-06-25 Thread Raphael Hertzog
Control: forwarded -1 https://github.com/dell/dkms/issues/85

On Mon, 24 Jun 2019, Raphaël Hertzog wrote:
> The reason is that "dkms install" runs this:
> find /sys/devices -name modalias -print0 | xargs -0 cat | xargs modprobe -a 
> -b -q

This was added in this commit:
https://github.com/dell/dkms/commit/f5bfb12fef1fc06e56355cdba500eaa98d4e6aa8

The rationale given there does not apply at all to Debian where
the modules are built/installed as soon as the DKMS package is installed
and not only on next reboot...

So we can likely just patch this out until upstream provides a way
to disable this code.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#930929: [Pkg-libvirt-maintainers] Bug#930929: marked as done (libvirt: is no longer able to use kvm)

2019-06-23 Thread Raphael Hertzog
Hi,

On Sun, 23 Jun 2019, Guido Günther wrote:
> > But after a reboot with the good systemd, it began again to work... sorry
> > for the noise!
> 
> Thanks for reporting all the details! Should we expect issues with newer
> systemd then or do you deem the problems related to the patches you
> tested?

I don't see any relationship between the patches that I tested and this
issue... but at the same time, I don't see any significant upstream change
either to 50-udev-default.rules so I'm not sure where it came from.

Maybe related to some other changes on how "uaccess" works? Every time I
modified manually /dev/kvm to "chgrp kvm /dev/kvm "and when I restarted
libvirtd, it was back to "root:root" ownership.

FWIW, I was running a git snapshot of June 13th with a patch for
PR12795 that I built on top of the packaging of what's in experimental.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#930929: libvirt: is no longer able to use kvm

2019-06-22 Thread Raphael Hertzog
On Sat, 22 Jun 2019, Raphael Hertzog wrote:
> And despite this I still have the error and yet the libvirt-qemu user
> is part of the kvm group:
> $ id libvirt-qemu
> uid=124(libvirt-qemu) gid=130(kvm) groupes=130(kvm),132(libvirt-qemu)

Still I confirm that the libvirt-qemu user is not able to open /dev/kvm.

$ sudo -u libvirt-qemu qemu-system-x86_64 -enable-kvm -S -no-user-config 
-nodefaults -nographic -machine none,accel=kvm:tcg -qmp 
unix:/tmp/qmp.monitor,server,nowait
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize KVM: Permission denied
qemu-system-x86_64: Back to tcg accelerator
^Cqemu-system-x86_64: terminating on signal 2

Running the same command with my personal user works fine.

Looking with strace in this command run as libvirt-qemu gives this:
openat(AT_FDCWD, "/dev/kvm", O_RDWR|O_CLOEXEC) = -1 EACCES (Permission denied)
fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x8), ...}) = 0
write(2, "Could not access KVM kernel modu"..., 54Could not access KVM kernel 
module: Permission denied
) = 54
write(2, "qemu-system-x86_64: failed to in"..., 64qemu-system-x86_64: failed to 
initialize KVM: Permission denied
) = 64

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#930929: libvirt: is no longer able to use kvm

2019-06-22 Thread Raphael Hertzog
Control: found -1 5.0.0-3
Control: found -1 5.2.0-2

On Sat, 22 Jun 2019, Raphaël Hertzog wrote:
> For a few days/weeks (I'm not sure when it started exactly), I can no
> longer run my VM with virt-manager.

I tried downgrading to the version in testing, but the problem stayed the
same. I also tried with the version 5.2.0-2 in experimental, same result.
(But that was before I realized the problem with my systemd version, see
below)

> When I try to start a VM I see this in the logs of libvirtd:
> libvirtd[12569]: Unable to read from monitor: Connexion ré-initialisée par le 
> correspondant

FWIW, the part of this message in French is "Connection reset by peer".

> $ ls -al /dev/kvm
> crw-rw+ 1 root root 10, 232 juin  22 19:07 /dev/kvm

This was wrong, and it was due to a systemd/udev version that I manually
built out of experimental with upstream patches to test... now I
downgraded to the version in unstable and I have this:

$ ls -al /dev/kvm
crw-rw+ 1 root kvm 10, 232 juin  22 21:14 /dev/kvm

And despite this I still have the error and yet the libvirt-qemu user
is part of the kvm group:

$ id libvirt-qemu
uid=124(libvirt-qemu) gid=130(kvm) groupes=130(kvm),132(libvirt-qemu)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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



Bug#820597: Devuan ... let's remove such reference

2019-06-21 Thread Raphael Hertzog
On Thu, 20 Jun 2019, Jorge wrote:
> I wouldn't add Trisquel, because it's based on Ubuntu. Yes, ultimately, an
> Ubuntu derivative is a Debian derivative, but do we really want to add
> those? PureOS is a FSF-supported Debian derivative, so I plan to add that
> one to fill that free software purist lack.

Ack. Looks like a good plan.

A+
-- 
Raphaël Hertzog ◈ Debian Developer

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



  1   2   3   4   5   6   7   8   9   10   >