Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Nick Gawronski, le dim. 21 mars 2021 15:36:16 -0500, a ecrit:
> Hi, I am not sure if any desktop login screen is active as no sound is
> played just the boot beep from vmware player.  After the system boots I just
> login using ssh to check if things are running and this is how I found that
> espeakup and pulseaudio are running.

Could you send the output of 

ps axf

?

Samuel

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Nick Gawronski, le dim. 21 mars 2021 15:07:41 -0500, a ecrit:
> pulseaudio is running

Pulseaudio is running? That's odd, I don't see how that could happen. So
you just boot the system, log-in through ssh, and there pulseaudio is
already running without having started anything? (no graphical session
and not even lightdm)

Samuel

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Nick Gawronski, le dim. 21 mars 2021 13:45:37 -0500, a ecrit:
> I tried this with both a debian desktop environment and just the
> standard system utilities with the same result.

So this rules out the orca question indeed. Is pulseaudio running on the
installed system? (Normally that shouldn't be happening with a text-only
environment, but better make sure).

> If I try to run espeak with text when connected over ssh all I get is
> some static sounds for about a second.

What do you mean by "static sounds"? What does it sound like?

> What else can I try to see if the sound is working are samples
> provided to test with?

You could use aplay from alsa-utils on a .wav file.

Samuel

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Hello,

Please keep the bug in Cc, so the maintainers of the correspoding
package get the additional information too.

john doe, le dim. 21 mars 2021 19:38:43 +0100, a ecrit:
> On 3/21/2021 7:02 PM, Samuel Thibault wrote:
> > A user reports that although he has sound during installation (using
> > speech synthesis), there is no sound at reboot into the installed
> > system, although it looks like the audio levels seem correct. Any idea?
> > 
> 
> If Espeakup-ng and Orca are started at the same time, that might be
> where the issue lies...

In that case, either one or the other would be working. Nick reported
that none of them was working.

Samuel

Bug#985666: alsa-utils: no sound after installation

[Samuel Thibault]

Package: alsa-utils
Version: 1.2.4-1

Hello,

A user reports that although he has sound during installation (using
speech synthesis), there is no sound at reboot into the installed
system, although it looks like the audio levels seem correct. Any idea?

Samuel

Nick Gawronski, le mer. 17 mars 2021 19:34:24 -0500, a ecrit:
> # amixer -c 0 scontents
> Simple mixer control 'Master',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Mono:
>   Front Left: Playback 49 [78%] [-21.00dB] [on]
>   Front Right: Playback 49 [78%] [-21.00dB] [on]
> Simple mixer control 'PCM',0
>   Capabilities: pvolume pswitch pswitch-joined
>   Playback channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Mono:
>   Front Left: Playback 23 [37%] [0.00dB] [on]
>   Front Right: Playback 23 [37%] [0.00dB] [on]
> Simple mixer control 'Line',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'CD',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'Mic',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [on]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [on]
> Simple mixer control 'Mic Boost (+20dB)',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [off]
> Simple mixer control 'Video',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'Phone',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'IEC958',0
>   Capabilities: pswitch pswitch-joined
>   Playback channels: Mono
>   Mono: Playback [off]
> Simple mixer control 'Aux',0
>   Capabilities: pvolume pswitch pswitch-joined cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Playback channels: Front Left - Front Right
>   Capture channels: Front Left - Front Right
>   Limits: Playback 0 - 63
>   Front Left: Playback 0 [0%] [-34.50dB] [off] Capture [off]
>   Front Right: Playback 0 [0%] [-34.50dB] [off] Capture [off]
> Simple mixer control 'Capture',0
>   Capabilities: cvolume cswitch cswitch-joined
>   Capture channels: Front Left - Front Right
>   Limits: Capture 0 - 15
>   Front Left: Capture 8 [53%] [12.00dB] [on]
>   Front Right: Capture 8 [53%] [12.00dB] [on]
> Simple mixer control 'Mix',0
>   Capabilities: cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Capture channels: Front Left - Front Right
>   Front Left: Capture [off]
>   Front Right: Capture [off]
> Simple mixer control 'Mix Mono',0
>   Capabilities: cswitch cswitch-exclusive
>   Capture exclusive group: 0
>   Capture channels: Front Left - Front Right
>   Front Left: Capture [off]
>   Front Right: Capture [off]

Bug#985645: hurd: Hurd creates buggy core files or gdb cannot read core files properly

[Samuel Thibault]

Svante Signell, le dim. 21 mars 2021 11:47:14 +0100, a ecrit:
> Example session:
> host ftp.sunet.se
> ftp.sunet.se is an alias for sunet.ftp.acc.umu.se.
> sunet.ftp.acc.umu.se has address 194.71.11.173
> sunet.ftp.acc.umu.se has address 194.71.11.165
> socket.c:3175: REQUIRE(readable || writeable) failed, back trace
> #0 0x1337666 in ??
> #1 0x1337595 in ??
> #2 0x137e3d5 in ??
> #3 0x1372d1c in ??
> #4 0x13e782f in ??

So bind9 itself doesn't find its own symbols.  I'm then not surprised
that gdb can't either. Trying a trivial example:

int main(void) {  *(int*) 0 = 0; }

gives

€ gdb ./test core
[...]
Program terminated with signal SIGSEGV, Segmentation fault.

warning: Unexpected size of section `.reg2/903' in core file.
#0  main () at test.c:5
5   *(int*) 0 = 0;

So it seems to work at least basically.

Samuel

Bug#985436: libstarpu-dev: broken symlink: /usr/lib/x86_64-linux-gnu/libstarpurm-1.3.so -> libstarpurm-1.3.so.1.0.1

[Samuel Thibault]

Andreas Beckmann, le ven. 19 mars 2021 13:48:25 +0100, a ecrit:
> the same problem exists in src:starpu-contrib.

Ah, right, sure, uploaded.

Samuel

Bug#985475: unblock: starpu/1.3.7+dfsg-3

[Samuel Thibault]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

Please unblock package starpu

[ Reason ]
#985436 reported a broken symlink in libstarpu-dev which is due to a
mere missing dependency.

[ Impact ]
Without it, the user has to install the libstarpurm-1.3-1 binary package
by hand in addition to libstarpu-dev, so as to be able to link with
-lstarpurm

[ Tests ]
Issue detected by piupart, seen as fixed by piuparts.

[ Risks ]
Code is trivial: just an additional dependency that should have been
there from the start.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock starpu/1.3.7+dfsg-3
diff -Nru starpu-1.3.7+dfsg/debian/changelog starpu-1.3.7+dfsg/debian/changelog
--- starpu-1.3.7+dfsg/debian/changelog  2021-01-16 13:37:36.0 +0100
+++ starpu-1.3.7+dfsg/debian/changelog  2021-03-18 22:50:37.0 +0100
@@ -1,3 +1,10 @@
+starpu (1.3.7+dfsg-3) unstable; urgency=medium
+
+  * control: Make libstarpu-dev depend on libstarpurm-1.3-1
+(Closes: Bug#985436).
+
+ -- Samuel Thibault   Thu, 18 Mar 2021 22:50:37 +0100
+
 starpu (1.3.7+dfsg-2) unstable; urgency=medium
 
   * control: Fix libstarpurm providing libstarpu-anyrm.
diff -Nru starpu-1.3.7+dfsg/debian/control starpu-1.3.7+dfsg/debian/control
--- starpu-1.3.7+dfsg/debian/control2020-12-31 14:48:16.0 +0100
+++ starpu-1.3.7+dfsg/debian/control2021-03-18 22:49:38.0 +0100
@@ -30,7 +30,7 @@
 Package: libstarpu-dev
 Section: libdevel
 Architecture: any
-Depends: libstarpu-1.3-5 (= ${binary:Version}) | libstarpu-any-1.3-5, 
libstarpufft-1.3-2 (= ${binary:Version}) | libstarpu-anyfft-1.3-2, 
libstarpumpi-1.3-3 (= ${binary:Version}) | libstarpu-anympi-1.3-3, 
libsocl-1.3-0 (= ${binary:Version}) | libsocl-any-1.3-0, ${misc:Depends}, 
libhwloc-dev, opencl-headers, ocl-icd-opencl-dev
+Depends: libstarpu-1.3-5 (= ${binary:Version}) | libstarpu-any-1.3-5, 
libstarpufft-1.3-2 (= ${binary:Version}) | libstarpu-anyfft-1.3-2, 
libstarpumpi-1.3-3 (= ${binary:Version}) | libstarpu-anympi-1.3-3, 
libsocl-1.3-0 (= ${binary:Version}) | libsocl-any-1.3-0, libstarpurm-1.3-1 (= 
${binary:Version}) | libstarpu-anyrm-1.3-1, ${misc:Depends}, libhwloc-dev, 
opencl-headers, ocl-icd-opencl-dev
 Conflicts: libstarpu-contrib-dev
 Provides: libstarpu-any-dev
 Description: Task scheduler for heterogeneous multicore machines - dev

Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)

[Samuel Thibault]

Hello,

Paul Gevers, le jeu. 18 mars 2021 12:01:33 +0100, a ecrit:
> On 17-03-2021 19:40, Samuel Thibault wrote:
> > Paul Gevers, le mer. 17 mars 2021 19:38:16 +0100, a ecrit:
> >>> "apt upgrade --without-new-pkgs"
> >>
> >> Looking into history, I see we did this because of
> >> https://bugs.debian.org/931637. I guess your suggestion is a better
> >> alternative?
> > 
> > It would probably fill both the objective of upgrading without new
> > packages, and letting users have a progression bar, yes.
> 
> Sanity check, does the attached patch do what you mean?

Yes!

Samuel

Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)

[Samuel Thibault]

Paul Gevers, le mer. 17 mars 2021 19:38:16 +0100, a ecrit:
> > "apt upgrade --without-new-pkgs"
> 
> Looking into history, I see we did this because of
> https://bugs.debian.org/931637. I guess your suggestion is a better
> alternative?

It would probably fill both the objective of upgrading without new
packages, and letting users have a progression bar, yes.

Samuel

Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)

[Samuel Thibault]

Paul Gevers, le mar. 16 mars 2021 22:08:51 +0100, a ecrit:
>  wrote:
> > So we'd rather make release-notes document using apt instead of
> > apt-get? I'm fine with that but we *ALSO* need to make sure that debian
> > developers actually *test* that path, and not the apt-get path.
> 
> Already the buster release notes talk about using apt instead of apt-get

Mmm, actually no, it tells to use "apt-get upgrade"

https://www.debian.org/releases/buster/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade

Possibly this should be turned to 

"apt upgrade --without-new-pkgs"

?

Otherwise people will continue replacing apt-get with apt in "apt-get
upgrade" without knowing that they are really different, and get
upgrading bugs that maintainers that use "apt-get upgrade" (expectedly)
do not get.

> and even has a note about the difference [1]. I'm not aware (but I don't
> follow user facing help channels) that this has lead to problems that
> would have been prevented with sticking to apt-get.

I did see some users getting upgrading issues when running
"apt upgrade", while "apt-get upgrade" first would have solved them.

Samuel

Bug#984881: libnvidia-ml-dev: missing libnvidia-ml.so in library search path?

[Samuel Thibault]

Andreas Beckmann, le dim. 14 mars 2021 06:19:28 +0100, a ecrit:
> On 11/03/2021 16.57, Samuel Thibault wrote:
> > Thanks for the nvidia-alternative upload, but it seems that it then
> > doesn't work for ppc64el, which doesn't have the nvidia-alternative
> > binary package since it doesn't build the nvidia-graphics-drivers source
> > package?
> 
> Now all *-legacy-* and *-tesla-* packages should be updated, too.

Thanks!

Samuel

Bug#985274: unblock: hwloc-contrib/2.4.1+dfsg-2

[Samuel Thibault]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package hwloc-contrib

[ Reason ]
hwloc-contrib currently FTBFS due to #984984 : nvidia-alternative fixed
providing libnvidia-ml.so, and thus hwloc-contrib is now able to build
its nvml plugin but dh_missing complains that it was not configured to.

In the hwloc-contrib/2.4.1+dfsg-2 upload, I re-enabled installing
the nvml plugin, as the attached patch shows.

[ Impact ]
Without the nvml plugin, it is harder for hwloc-based applications to
determine the locality of GPUs in the system, and thus to optimize data
transfers and get efficient execution.

[ Tests ]
I have tested it on a system that has GPUs, the nvml location is
correct.

[ Risks ]
The code change is trivial :)
The consequence for systems without a GPU is just an nvmlInit() call
that will report that there is no nvml device. For systems with a GPU,
the nvml plugin just gets information from libnvidia-ml and stores it
for applications that would want it.

Alternatively, we could mark the nvml plugin as not-installed.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock hwloc-contrib/2.4.1+dfsg-2
diff -Nru hwloc-contrib-2.4.1+dfsg/debian/changelog 
hwloc-contrib-2.4.1+dfsg/debian/changelog
--- hwloc-contrib-2.4.1+dfsg/debian/changelog   2021-02-22 18:21:18.0 
+0100
+++ hwloc-contrib-2.4.1+dfsg/debian/changelog   2021-03-11 16:01:54.0 
+0100
@@ -1,3 +1,10 @@
+hwloc-contrib (2.4.1+dfsg-2) unstable; urgency=medium
+
+  * libhwloc-contrib-plugins.install: Install the nvml plugin again
+(Closes: Bug#984984)
+
+ -- Samuel Thibault   Thu, 11 Mar 2021 16:01:54 +0100
+
 hwloc-contrib (2.4.1+dfsg-1) unstable; urgency=medium
 
   * New upstream bugfix release.
diff -Nru hwloc-contrib-2.4.1+dfsg/debian/libhwloc-contrib-plugins.install 
hwloc-contrib-2.4.1+dfsg/debian/libhwloc-contrib-plugins.install
--- hwloc-contrib-2.4.1+dfsg/debian/libhwloc-contrib-plugins.install
2021-02-22 18:21:18.0 +0100
+++ hwloc-contrib-2.4.1+dfsg/debian/libhwloc-contrib-plugins.install
2021-03-11 16:01:54.0 +0100
@@ -1 +1,2 @@
 usr/lib/*/hwloc/hwloc_cuda.so
+usr/lib/*/hwloc/hwloc_nvml.so

Bug#985204: unblock: pyatspi/2.38.1-1

[Samuel Thibault]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

I have uploaded the upstream bugfix version 2.38.1.

I'm sorry I didn't realize "key package" was spanning quite large, so
that update won't auto-propagate without explicit unblock, I thought
it would auto-propagate so just went on with packaging the new version
rather than just applying the fix (that said the new upstream version
contains only the fix, so it's possibly better to have the new upstream
version, so that users don't erroneously think that Debian doesn't have
the fix).

[ Reason ]
This version fixes (and brings actual code changes only for that):

https://gitlab.gnome.org/GNOME/pyatspi2/-/issues/6
https://gitlab.gnome.org/GNOME/pyatspi2/-/issues/7

[ Impact ]
Without it, blind users using orca can get completely stuck in the
situation mentioned in the bugs:

- Launch cawbird (a twitter client)
- Tab amongst links in the timeline

That alone completely hangs the Orca screen reader, leaving the whole
desktop unusable for the blind user, who basically has not choice but
reboot.

[ Tests ]
pyatspi has a full testsuite showing up as "runtests.sh" in the build
logs.

[ Risks ]
The change is actually trivial.

For reference I have attached the debdiff (called patch-complete),
but most of it is upstream update from autoconf 1.16.2 to 1.16.3. The
attached diff (called patch) is the content of the source after only
the dh_autoreconf step which thus normalizes the autoconf version,
and thus in which the autoconf part only shows the upstream version
number change. In the attached patch-realchange, I stripped the autoconf
upstream version number changes to show the real meat which boils down
to making a while loop never able to be infinite (twice):

@@ -296,7 +296,8 @@
 if acc is None:
 # guard against bad start condition
 return None
-while 1:
+tries = 0
+while tries < 100:
 if acc.parent is None:
 # stop if there is no parent and we haven't returned 
yet
 return None
@@ -306,6 +307,8 @@
 pass
 # move to the parent
 acc = acc.parent
+tries = tries + 1
+return None

 def getPath(acc):
 """

As a technical note: the problem here is with applications which have a
complex structure with parent/child relations that happen in a loop. The
100 limit means it won't support application that have more than 100
widget nesting levels, which I have never seen (usually at most 15-20).

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock pyatspi/2.38.1-1
diff -Nru pyatspi-2.38.0/aclocal.m4 pyatspi-2.38.1/aclocal.m4
--- pyatspi-2.38.0/aclocal.m4   2020-09-12 21:25:54.0 +0200
+++ pyatspi-2.38.1/aclocal.m4   2021-03-13 22:36:26.0 +0100
@@ -1,4 +1,4 @@
-# generated automatically by aclocal 1.16.2 -*- Autoconf -*-
+# generated automatically by aclocal 1.16.3 -*- Autoconf -*-
 
 # Copyright (C) 1996-2020 Free Software Foundation, Inc.
 
@@ -9407,7 +9407,7 @@
 [am__api_version='1.16'
 dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
 dnl require some minimum version.  Point them to the right macro.
-m4_if([$1], [1.16.2], [],
+m4_if([$1], [1.16.3], [],
   [AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
 ])
 
@@ -9423,7 +9423,7 @@
 # Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
 # This function is AC_REQUIREd by AM_INIT_AUTOMAKE.
 AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
-[AM_AUTOMAKE_VERSION([1.16.2])dnl
+[AM_AUTOMAKE_VERSION([1.16.3])dnl
 m4_ifndef([AC_AUTOCONF_VERSION],
   [m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
 _AM_AUTOCONF_VERSION(m4_defn([AC_AUTOCONF_VERSION]))])
@@ -9836,7 +9836,7 @@
 [_AM_SET_OPTIONS([$1])dnl
 dnl Diagnose old-style AC_INIT with new-style AM_AUTOMAKE_INIT.
 m4_if(
-  m4_ifdef([AC_PACKAGE_NAME], [ok]):m4_ifdef([AC_PACKAGE_VERSION], [ok]),
+  m4_ifset([AC_PACKAGE_NAME], [ok]):m4_ifset([AC_PACKAGE_VERSION], [ok]),
   [ok:ok],,
   [m4_fatal([AC_INIT should be called with package and version arguments])])dnl
  AC_SUBST([PACKAGE], ['AC_PACKAGE_TARNAME'])dnl
@@ -10075,12 +10075,7 @@
 [AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
 AC_REQUIRE_AUX_FILE([missing])dnl
 if test x"${MISSING+set}" != xset; then
-  case $am_aux_dir in
-  *\ * | *\*)
-MISSING="\${SHELL} \"$am_aux_dir/missing\"" ;;
-  *)
-MISSING="\${SHELL} $am_aux_dir/missing" ;;
-  esac
+  MISSING="\${SHELL} '$am_aux_dir/missing'"
 fi
 # Use eval to expand $SHELL
 if eval "$MISSING --is-lightweight"; then
@@ -10252,12 +10247,14 @@
 m4_default([$3], [AC_MSG_ERROR([no suitable Python interpreter found])])
   else
 
-  dnl Query Python for its version number.  Getting [:3] seems to be
-  dnl the best 

Bug#985189: ITP: et -- Eternal Terminal (ET) is a remote shell that automatically reconnects without interrupting the session.

[Samuel Thibault]

Hello,

Jason Gauci, le dim. 14 mars 2021 04:38:27 +, a ecrit:
>   Package name: et
> 
> Eternal Terminal (ET) is a remote shell that automatically reconnects without 
> interrupting the session.

It would be useful to add the difference with mosh:

"
While mosh provides the same core functionality as ET, it does not
support native scrolling nor tmux control mode (tmux -CC).
"

Samuel

Bug#985119: debian-installer: shared-mime-info installed for no apparent reason

[Samuel Thibault]

Hello,

Witold Baryluk, le sam. 13 mars 2021 00:36:59 +, a ecrit:
> I just used the daily netinst for testing on arm64 in qemu.

> what dependss on shared-mime-info that it was installed in the first
> place?

On qemu, the hwdetect package installs qemu-guest-agent, which depends
on libglib2.0-0, which recommends shared-mime-info.

> the only reason libicu67 was installed is due to
> shared-mime-info. That grows the default install by about 10%!).

Possibly libglib2.0-0's shared-mime-info could be downgraded to
Suggests, Cc-ing glib2.0 maintainers about it.

Samuel

Bug#984881: libnvidia-ml-dev: missing libnvidia-ml.so in library search path?

[Samuel Thibault]

Hello,

Andreas Beckmann, le mer. 10 mars 2021 10:32:42 +0100, a ecrit:
> I'll think about where best to add this ... driver or cuda toolkit.

Thanks for the nvidia-alternative upload, but it seems that it then
doesn't work for ppc64el, which doesn't have the nvidia-alternative
binary package since it doesn't build the nvidia-graphics-drivers source
package?

Samuel

Bug#984984: hwloc-contrib: FTBFS with latest nvidia-alternative

[Samuel Thibault]

Source: hwloc-contrib
Version: 2.4.1+dfsg-1
Severity: serious
Justification: FTBFS

With the new nvidia-alternative package which fixed shipping
libnvidia-ml.so (see #984881), hwloc-contrib now FTBFS:

   dh_missing -a
dh_missing: warning: usr/lib/x86_64-linux-gnu/hwloc/hwloc_nvml.so exists in 
debian/tmp but is not installed to anywhere

That's because hwloc can now build its nvml plugin. It happens that we'd
want to ship indeed, so I'll propose to use the attached patch.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-proposed-updates-debug'), (500, 'testing-proposed-updates'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.11.0 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/libhwloc-contrib-plugins.install 
b/debian/libhwloc-contrib-plugins.install
index 59555c70..80553c88 100644
--- a/debian/libhwloc-contrib-plugins.install
+++ b/debian/libhwloc-contrib-plugins.install
@@ -1 +1,2 @@
 usr/lib/*/hwloc/hwloc_cuda.so
+usr/lib/*/hwloc/hwloc_nvml.so

Bug#984899: buster-pu: package hwloc-contrib/1.11.12-3+deb10u1

[Samuel Thibault]

Adam D. Barratt, le mer. 10 mars 2021 21:25:27 +, a ecrit:
> On Wed, 2021-03-10 at 01:32 +0100, Samuel Thibault wrote:
> > I have uploaded a proposed 1.11.12-3+deb10u1 version of hwloc-contrib
> > for buster.
> 
> The amd64 package that was uploaded appears to have been built either
> on a system with backports enabled, or outside of a stable chroot -

Ah, yes, that was supposed to be the easy part since on my own machine,
but I must have picked the wrong chroot.

> I've just flagged that upload for rejection on that basis.

Thanks!

I have re-uploaded a fixed version. The .buildinfo files do show
packages coming from buster now.

Samuel

Bug#984899: buster-pu: package hwloc-contrib/1.11.12-3+deb10u1

[Samuel Thibault]

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

Hello,

I have uploaded a proposed 1.11.12-3+deb10u1 version of hwloc-contrib
for buster.

[ Reason ]
PowerPC systems provide much better bandwidth between CPUs and NVIDIA
GPUs thanks to NVLink, they are thus currently very often used for
running NVIDIA GPUs (top500.org has a lot of them for instance). But
hwloc currently does not show NVIDIA GPUs on ppc64el because the
hwloc-contrib package is not getting built there.  This makes it much
harder for applications to determine the locality of GPUs in the system
and thus where to place data etc. to get efficient execution.

This is not a regression over oldstable, which did not have it built on
ppc64el either.

[ Impact ]
If this isn't included, people will have to build hwloc by hand to get
the locality information and thus efficient execution.

[ Tests ]
The hwloc-contrib package has a full testsuite which I could run on a
ppc64el system.

[ Risks ]
There is no risk for the only other arch (amd64), because the change
disables the libcuda1 build-dep only on ppc64el, and it drops libcuda
from the link of a test which is not getting shipped anyway.

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

[ Changes ]
There is no libcuda1 on ppc64el, so this dependency had to be disabled.
This disables one test (cuda), but otherwise the functionalities of the
built package are the same.

The cudart test used to be linked against libcuda, but that was actually
spurious, upstream doesn't link it against libcuda any more since a long
time actually.

With regards,
Samuel
diff -Nru hwloc-contrib-1.11.12/debian/changelog 
hwloc-contrib-1.11.12/debian/changelog
--- hwloc-contrib-1.11.12/debian/changelog  2019-02-09 00:46:55.0 
+0100
+++ hwloc-contrib-1.11.12/debian/changelog  2021-03-10 00:22:29.0 
+0100
@@ -1,3 +1,11 @@
+hwloc-contrib (1.11.12-3+deb10u1) buster; urgency=medium
+
+  * control: Enable build on ppc64el with libcuda1 build-dep disabled.
+  * patches/cuda-ppc64el: Upstream fix for cudart test that does not actually
+need libcuda1.
+
+ -- Samuel Thibault   Wed, 10 Mar 2021 00:22:29 +0100
+
 hwloc-contrib (1.11.12-3) unstable; urgency=medium
 
   * control: Add libcuda1 dependency, not brought by nvidia-cuda-dev any more.
diff -Nru hwloc-contrib-1.11.12/debian/control 
hwloc-contrib-1.11.12/debian/control
--- hwloc-contrib-1.11.12/debian/control2019-02-09 00:46:06.0 
+0100
+++ hwloc-contrib-1.11.12/debian/control2021-03-09 23:55:17.0 
+0100
@@ -3,7 +3,7 @@
 Maintainer: Samuel Thibault 
 Build-Depends: debhelper (>= 9), libltdl-dev,
   valgrind [amd64 arm64 armhf i386 mips mipsel powerpc ppc64el s390x mips64el 
ppc64],
-  libx11-dev, libxext-dev, nvidia-cuda-dev, libcuda1, libxnvctrl-dev,
+  libx11-dev, libxext-dev, nvidia-cuda-dev, libcuda1 [!ppc64el], 
libxnvctrl-dev,
   libpciaccess-dev, pkg-config,
   libibverbs-dev [linux-any],
   ocl-icd-opencl-dev [!hurd-i386] | opencl-dev, opencl-headers,
@@ -18,7 +18,7 @@
 Vcs-Browser: https://github.com/open-mpi/hwloc-debian/tree/contrib
 
 Package: libhwloc-contrib-plugins
-Architecture: amd64
+Architecture: amd64 ppc64el
 Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}, libhwloc5 (>= 
${source:Upstream-Version}~), libhwloc5 (<< ${source:Upstream-Version}A)
 Description: Hierarchical view of the machine - contrib plugins
diff -Nru hwloc-contrib-1.11.12/debian/patches/cuda-ppc64el 
hwloc-contrib-1.11.12/debian/patches/cuda-ppc64el
--- hwloc-contrib-1.11.12/debian/patches/cuda-ppc64el   1970-01-01 
01:00:00.0 +0100
+++ hwloc-contrib-1.11.12/debian/patches/cuda-ppc64el   2021-03-10 
00:21:15.0 +0100
@@ -0,0 +1,21 @@
+commit 542fb5677723e13980056ea5f1023b5120bd2e0d
+Author: Samuel Thibault 
+Date:   Wed Mar 10 00:20:05 2021 +0100
+
+tests/cudart: Do not link against libcuda
+
+ppc64el doesn't have libcuda and the cudart test does not need it anyway.
+
+diff --git a/tests/Makefile.am b/tests/Makefile.am
+index cc9ce5039..5129b8a34 100644
+--- a/tests/Makefile.am
 b/tests/Makefile.am
+@@ -104,7 +104,7 @@ openfabrics_verbs_LDADD = $(LDADD) -libverbs
+ myriexpress_LDADD = $(LDADD) -lmyriexpress
+ opencl_LDADD = $(LDADD) $(HWLOC_OPENCL_LIBS) $(HWLOC_OPENCL_LDFLAGS)
+ cuda_LDADD = $(LDADD) -lcuda
+-cudart_LDADD = $(LDADD) -lcuda -lcudart
++cudart_LDADD = $(LDADD) -lcudart
+ nvml_LDADD = $(LDADD) -lnvidia-ml
+ hwloc_bind_LDADD = $(LDADD)
+ if HWLOC_HAVE_PTHREAD
diff -Nru hwloc-contrib-1.11.12/debian/patches/series 
hwloc-contrib-1.11.12/debian/patches/series
--- hwloc-contrib-1.11.12/debian/patches/series 2019-02-09 00:46:08.0 
+0100
+++ hwloc-contrib-1.11.12/debian/patches/series 2021-03-10 00:02:11.0 
+0100

Bug#984881: libnvidia-ml-dev: missing libnvidia-ml.so in library search path?

[Samuel Thibault]

Package: libnvidia-ml-dev
Version: 11.2.67~11.2.1-2
Severity: important

Hello,

While trying to build a program that uses nvml, I am getting:

$ gcc transfers.c -o transfers -lnvidia-ml
/usr/bin/ld: cannot find -lnvidia-ml
collect2: error: ld returned 1 exit status

indeed libnvidia-ml-dev doesn't provide a libnvidia-ml.so link in
/usr/lib/x86_64-linux-gnu

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libnvidia-ml-dev depends on:
ii  libnvidia-ml1 [libnvidia-ml.so.1]  460.39-1

libnvidia-ml-dev recommends no packages.

libnvidia-ml-dev suggests no packages.

-- no debconf information

-- 
Samuel
il y a 10 catégories de personnes dans le monde : ceux qui comprennent le
binaire, et ceux qui ne le comprennent pas

Bug#984802: [Pkg-fonts-devel] Bug#984802: conflicts: lcdf-typetools

[Samuel Thibault]

Jonas Smedegaard, le lun. 08 mars 2021 17:36:53 +0100, a ecrit:
> Quoting Samuel Thibault (2021-03-08 16:12:37)
> > Gürkan Myczko, le lun. 08 mars 2021 15:44:52 +0100, a ecrit:
> > > Package: otf-trace
> > > Version: 1.12.5+dfsg-7
> > > Severity: serious
> > > Justification: Sounds like a serious violation of ?10.1
> > 
> > Well, yes. The base issue is that OTF stands both for OpenType Font 
> > and Open Trace Format. Thus the marked "Conflicts".
> > 
> > The question is who should "own" the otfinfo command name?
> 
> Do you mean if the package already owning it is ok giving it up?

No, I rather mean that in name spaces it's hard to define a notion of
"owning" a name. The two meanings of "OTF" have sprinkled independently,
one can try to look at history to check "who came first", but that's
rather meaningless.

> > Packages names are not really a concern, I was fine with using 
> > libopen-trace-format-dev along the existing libotf-dev.
> > 
> > But command names are really a concern since that's what 
> > documentations, tutorials, etc. found on internet will say: "run 
> > otfinfo", and making Debian systems deviate from that will confuse 
> > users, be it for one side or the other side.
> > 
> > (and the probability that somebody works both on OpenType Font and 
> > Open Trace Format on the same machine is quite low).
> 
> I thought similarly about a clash between a JavaScript interpreter and a 
> ham routing daemon, but turned out the rules are quite strict: See 
> bug#681360 about node.

And yet it has been so for 9 years without anybody complaining.

Samuel

Bug#984802: conflicts: lcdf-typetools

[Samuel Thibault]

Gürkan Myczko, le lun. 08 mars 2021 15:44:52 +0100, a ecrit:
> Package: otf-trace
> Version: 1.12.5+dfsg-7
> Severity: serious
> Justification: Sounds like a serious violation of ?10.1

Well, yes. The base issue is that OTF stands both for OpenType Font and
Open Trace Format. Thus the marked "Conflicts".

The question is who should "own" the otfinfo command name?

Packages names are not really a concern, I was fine with using
libopen-trace-format-dev along the existing libotf-dev.

But command names are really a concern since that's what documentations,
tutorials, etc. found on internet will say: "run otfinfo", and making
Debian systems deviate from that will confuse users, be it for one side
or the other side.

(and the probability that somebody works both on OpenType Font and Open
Trace Format on the same machine is quite low).

Samuel

Bug#984617: unblock: lowmem/1.49

[Samuel Thibault]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello,

I have uploaded a new version of lowmem, see the attached patch.

[ Reason ]
This updates the memory levels at which the d-i enables low-memory
optimizations.

[ Impact ]
If this isn't getting updated, starting the d-i on an amd64 machine with
an amount of memory between 550MB and 780MB, with default parameters,
will try to install without any low-memory optimization, but that will
fail with OOM errors.

[ Tests ]
I tested the d-i image in each modified case.

[ Risks ]
The code change is trivial: it only changes the numerical level.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock lowmem/1.49

Thanks!
Samuel
diff -Nru lowmem-1.48/debian/changelog lowmem-1.49/debian/changelog
--- lowmem-1.48/debian/changelog2020-12-15 18:15:38.0 +0100
+++ lowmem-1.49/debian/changelog2021-03-03 02:21:13.0 +0100
@@ -1,3 +1,9 @@
+lowmem (1.49) unstable; urgency=medium
+
+  * debian-installer-startup.d/S15lowmem: Update minimum memory sizes.
+
+ -- Samuel Thibault   Wed, 03 Mar 2021 02:21:13 +0100
+
 lowmem (1.48) unstable; urgency=medium
 
   * Team upload
diff -Nru lowmem-1.48/debian-installer-startup.d/S15lowmem 
lowmem-1.49/debian-installer-startup.d/S15lowmem
--- lowmem-1.48/debian-installer-startup.d/S15lowmem2019-06-02 
14:21:18.0 +0200
+++ lowmem-1.49/debian-installer-startup.d/S15lowmem2021-03-03 
02:15:44.0 +0100
@@ -25,9 +25,9 @@
min=39
;;
amd64)
-   level1=483 # MT=494300, qemu: -m 550
-   level2=273 # MT=279260, qemu: -m 300
-   min=145# MT=148188, qemu: -m 170
+   level1=737 # MT=754108, qemu: -m 780
+   level2=424 # MT=433340, qemu: -m 460
+   min=316# MT=322748, qemu: -m 350
;;
arm|armel|armhf)
# Update needed
@@ -42,9 +42,9 @@
min=18
;;
i386)
-   level1=386 # MT=394604, qemu: -m 400
-   level2=237 # MT=242628, qemu: -m 250
-   min=109# MT=110956, qemu: -m 120
+   level1=466 # MT=478056, qemu: -m 485
+   level2=348 # MT=356312, qemu: -m 365
+   min=269# MT=275220, qemu: -m 285
;;
mips)
# Update needed
@@ -89,9 +89,9 @@
min=30# MT=30040, qemu: -m 90
;;
hurd-i386)
-   level1=499 # qemu: -m 500
-   level2=409 # qemu: -m 410
-   min=389# qemu: -m 390
+   level1=600 # MT=614208, qemu: -m 600
+   level2=480 # MT=491328, qemu: -m 480
+   min=475# MT=486208, qemu: -m 475
;;
*)
level1=64
diff -Nru lowmem-1.48/README lowmem-1.49/README
--- lowmem-1.48/README  2019-10-13 20:07:57.0 +0200
+++ lowmem-1.49/README  2021-03-03 02:06:22.0 +0100
@@ -131,13 +131,16 @@
 devices).
 
 In both cases, you need to set min to absolute minimum amount of memory needed
-for an install, booting with lowmem=2, partitioning by hand, etc.
+for an install, booting with lowmem=2, loading only the nic-modules udeb,
+partitioning by hand, etc.
 
 Ideally, constraints should be tested for both netboot and businesscard images
 (businesscard CD will use slightly more memory before partitioning that netinst
 because of mirror selection).
 
-NB: the minimum value should be update in the manual in build/arch-options
+NB: the minimum value should be updated in the manual in build/arch-options
+
+NB: the minimum value should be updated in 
debian-installer/build/boot/x86/f2.txt
 
 NB: the minimum memory required to run the graphical installer must
 also be tested. See rootskel (debian-installer.d/S60frontend).

Bug#983897: installation-reports: Installation in Uyghur hangs

[Samuel Thibault]

Holger Wansing, le ven. 05 mars 2021 00:12:19 +0100, a ecrit:
> Samuel Thibault  wrote (Wed, 3 Mar 2021 00:43:38 
> +0100): 
> > I was trying the debian installer in Uyghur to test lowmem levels, and
> > it seems that it just hangs when asking for user login/password, see the
> > attached screenshot (obtained by just selecting Uyghur then all default
> > answers). Running in Arabic however works fine so it doesn't seem to be
> > a general RtoL-specific issue.
> 
> I found another situation where it hangs for Uyghur:
> if you start an installation on a machine having no network connection,
> it hangs at the point where this dialog should appear:
>   Network configuration method:
>   .
>   From here you can choose to retry DHCP network autoconfiguration
>   (which may succeed if your DHCP server takes a long time to respond)
>   or to configure the network manually. Some DHCP servers require
>   a DHCP hostname to be sent by the client, so you can also choose
>   to retry DHCP network autoconfiguration with a hostname that you
>   provide.
>   .
>   Retry network autoconfiguration
>   Retry network autoconfiguration with a DHCP hostname
>   Configure network manually, ${wifireconf}
>   Do not configure the network at this time
> 
> 
> However, this dialog does not appear, it hangs forever on a blank screen.
> 
> So, it's apparently a more wide-spread issue.

Possibly it's a resurgence of a bug we had noticed with arabic

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

Samuel

Bug#983897: installation-reports: Installation in Uyghur hangs

[Samuel Thibault]

Package: installation-reports
Severity: normal
Tags: d-i i18n

Hello,

I was trying the debian installer in Uyghur to test lowmem levels, and
it seems that it just hangs when asking for user login/password, see the
attached screenshot (obtained by just selecting Uyghur then all default
answers). Running in Arabic however works fine so it doesn't seem to be
a general RtoL-specific issue.

Samuel

Bug#983589: w3m: Cannot verify certificates any more

[Samuel Thibault]

Tatsuya Kinoshita, le sam. 27 févr. 2021 07:36:20 +0900, a ecrit:
> On 2021-02-26 at 21:25 +0100, Samuel Thibault wrote:
> > Since version 0.5.3+git20210102-3 of w3m (downgrading to -2 fixes it),
> > all https website give me
> >
> > unable to get local issuer certificate: accept? (y/n)
> 
> Hmm, could you please tell me your configuration of ssl_ca_path
> and ssl_ca_file in <~/.w3m/config> and ?

I have

ssl_ca_file
ssl_ca_path /etc/ssl/certs, ~/.ssl/certs

Samuel

Bug#983589: w3m: Cannot verify certificates any more

[Samuel Thibault]

Package: w3m
Version: 0.5.3+git20210102-3
Severity: important

Hello,

Since version 0.5.3+git20210102-3 of w3m (downgrading to -2 fixes it),
all https website give me

unable to get local issuer certificate: accept? (y/n)

and choosing y gives

Accept unsecure SSL session: unverified: unable to get local issuer certificate

while choosing n quits.

This makes w3m vulnerable to spoofing. I almost thought about making
this a grave severity, since I believe we definitely don't want to keep
this bug in Bullseye.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages w3m depends on:
ii  libc6  2.31-9
ii  libgc1 1:8.0.4-3
ii  libgpm21.20.7-8
ii  libssl1.1  1.1.1j-1
ii  libtinfo6  6.2+20201114-2
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages w3m recommends:
ii  ca-certificates  20210119

Versions of packages w3m suggests:
pn  cmigemo 
ii  curl7.74.0-1.1
ii  dict1.13.0+dfsg-1
pn  dict-wn 
pn  dictd   
pn  libsixel-bin
ii  man-db  2.9.4-1
ii  mime-support3.66
ii  mpv 0.32.0-2+b1
ii  sensible-utils  0.0.14
pn  w3m-el  
ii  w3m-img 0.5.3+git20210102-2
ii  wget1.21-1+b1
ii  xdg-utils   1.1.3-4
ii  xsel1.2.0+git9bfc13d.20180109-3

-- no debconf information

-- 
Samuel
Actually, typing random strings in the Finder does the equivalent of
filename completion.
(Discussion in comp.os.linux.misc on the intuitiveness of commands: file
completion vs. the Mac Finder.)

Bug#946118: synaptics touchpad does not work in debian installer graphical mode

[Samuel Thibault]

Holger Wansing, le sam. 20 févr. 2021 20:45:59 +0100, a ecrit:
> Samuel Thibault  wrote (Sat, 7 Dec 2019 22:54:09 +0100):
> > Samuel Thibault, le mer. 04 déc. 2019 01:52:36 +0100, a ecrit:
> > > Thinking of it... IIRC the touchpad is not working on my DELL XPS13
> > > laptop in g-i.
> > 
> > Indeed, it doesn't work.
> 
> Now that the graphical installer uses libinput instead of evdev, maybe it's
> worth it to try if it works for you now with latest builds?

It does work for me in the latest builds that use libinput, indeed.

Samuel

Bug#913978: bug 913978: gnome-control-center is not accessible with Orca screenreader

[Samuel Thibault]

Hello,

Paul Gevers, le sam. 06 févr. 2021 10:10:33 +0100, a ecrit:
> On Thu, 16 May 2019 20:15:20 +0200 Paul Gevers  wrote:
> > On Sat, 27 Apr 2019 13:16:05 -0700 Tassia Camoes Araujo
> >  wrote:
> > > From what I could understand, it is unlikely this will be fixed before
> > > Buster release. So how should we proceed about his bug?
> > > Even if a backport can possibly be provided later, would it be possible
> > > to just document the keystrokes "workaround" mentioned by Jeremy Bicha
> > > in the package shipped with Buster?
> > > It might be a big difference for users in need of this accessibility
> > > feature.
> > 
> > Although I rather have the bug fixed (who doesn't) I think documenting
> > is the least that can be done. @a11y team, anybody willing to update the
> > Wiki? I'll make sure the release notes have something.
> 
> One release further. Can somebody, e.g. from the Debian Accessibility
> Team, please at least check if this is still an issue? If not, we can
> close the bug, if so, we can document it *again* [1] as I'm not
> expecting it to get fixed in these last months if it's not fixed already.

I had a look, it looks like it is exactly in the same state as before:
having to press right arrow twice, having to use control-f then esc to
get back to the panel list (not able to select a result element with the
keyboard). So the same text would be needed.

Samuel

Bug#879147: debian-ports and unreleased packages

[Samuel Thibault]

Hello,

For information, I submitted a couple of fixes for the unreleased
distribution in debian-cd, it now behaves fine when setting UNRELEASED=1
in CONF.sh: it includes packages from the unreleased distribution in the
sid distribution of the CD. Also, I switched to using LOCAL=1,
LOCALDEBS and UPDATE_LOCAL=1, which is indeed enough to select any few
packages from unreleased for the bootstrap part.

Samuel

Bug#982917: nvme-cli: Add a nvme-cli-udeb package?

[Samuel Thibault]

Package: nvme-cli
Version: 1.12-5
Severity: normal
Tags: d-i

Hello,

I was reinstalling a laptop after a NVME change, and I realized: what
if the NVME did not have any namespace set up? The installer would then
not recognize the disk. We would need at least the nvme command to be
available on the text console to fix this by hand (Ideally the installer
would even automatically propose to configure an NVME namespace).

Perhaps the addition of nvme-cli-udeb would be possible for bullseye
already? I could verify that the binary of the nvme-cli package does
work already, so it'd be a mere matter of adding the nvme-cli-udeb
package that just ships the /usr/sbin/nvme file.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages nvme-cli depends on:
ii  libc6 2.31-9
ii  libuuid1  2.36.1-6
ii  uuid-runtime  2.36.1-6

nvme-cli recommends no packages.

nvme-cli suggests no packages.

-- no debconf information

Bug#982283: override: bsdmainutils:oldlibs/optional

[Samuel Thibault]

Samuel Thibault, le jeu. 11 févr. 2021 00:56:20 +0100, a ecrit:
> As I mentioned previously in the bug, bsdutils (required) recommends
> bsdextrautils, so for that part things don't change.

Ah, no, the base install doesn't follow recommends, so bsdextrautils  is
not getting installed any more indeed. I have to say I didn't know about
the tools it contains, except hexdump :)

> For calendar and cal/ncal, the question indeed holds. For bsdmainutils
> maintainers: I guess the goal of splitting them out of bsdmainutils was
> precisely to not install them by default?

Bug#982283: override: bsdmainutils:oldlibs/optional

[Samuel Thibault]

Sean Whitton, le mer. 10 févr. 2021 16:44:30 -0700, a ecrit:
> On Thu 11 Feb 2021 at 12:21AM +01, Samuel Thibault wrote:
> > Sean Whitton, le lun. 08 févr. 2021 11:10:43 -0700, a ecrit:
> >> On Mon 08 Feb 2021 at 10:19AM +01, Chris Hofstaedtler wrote:
> >> >
> >> > bsdmainutils has become a transitional package in bullseye. It would be
> >> > great if we don't install it by default - right now its Priority:
> >> > important.
> >>
> >> I'm happy to go right ahead and lower the priority of the package that's
> >> only transitional, as it having a higher priority is not achieving
> >> anything at all.
> >
> > Yes, please.
> 
> Done.

Thanks!

> >> It seems appropriate to start a discussion on -devel about not
> >> installing those various utils by default by not raising the priority of
> >> the package they're not in, however?
> >
> > With the three "not" I didn't understand which way you wanted to mean
> > something.
> 
> Heh, sorry.  It seems appropriate to start a discussion on -devel to see
> if anyone thinks it's a problem for us to stop shipping those various
> utils in the base install, which would be achieved by raising the
> priority of the package which now contains them, in addition to lowering
> the priority of this one.

Ok now I understand, thanks :)

As I mentioned previously in the bug, bsdutils (required) recommends
bsdextrautils, so for that part things don't change.

For calendar and cal/ncal, the question indeed holds. For bsdmainutils
maintainers: I guess the goal of splitting them out of bsdmainutils was
precisely to not install them by default?

Samuel

Bug#982283: override: bsdmainutils:oldlibs/optional

[Samuel Thibault]

Sean Whitton, le lun. 08 févr. 2021 11:10:43 -0700, a ecrit:
> On Mon 08 Feb 2021 at 10:19AM +01, Chris Hofstaedtler wrote:
> > Package: ftp.debian.org
> > Severity: normal
> >
> > Hi,
> >
> > bsdmainutils has become a transitional package in bullseye. It would be
> > great if we don't install it by default - right now its Priority:
> > important.
> 
> I'm happy to go right ahead and lower the priority of the package that's
> only transitional, as it having a higher priority is not achieving
> anything at all.

Yes, please.

> It seems appropriate to start a discussion on -devel about not
> installing those various utils by default by not raising the priority of
> the package they're not in, however?

With the three "not" I didn't understand which way you wanted to mean
something.

Samuel

Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too

[Samuel Thibault]

Stephen Lyons, le mar. 09 févr. 2021 23:52:43 +, a ecrit:
> If I refer you back to:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959221#15 it was the
> Debian Sid DVD image:
> https://cdimage.debian.org/cdimage/ports/latest/hurd-i386/current/debian-sid-hurd-i386-DVD-1.iso
> which report that it is:
> "DVD Binary-1 20200731-17:45".

Ok, sorry for the duplicate question. Could you try a more recent image
such as 

https://people.debian.org/~sthibault/hurd-i386/installer/cdimage/daily/debian-sid-hurd-i386-NETINST-1.iso

?

Samuel

Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too

[Samuel Thibault]

Stephen Lyons, le mar. 09 févr. 2021 23:32:00 +, a ecrit:
> So I have worked around the problem - which seems to be confined to the
> installer and is a nuisance

So you mean that the installed system does not have the keyboard issue?
That is very surprising since that is supposed to be about the same
kernel.  Which ISO image had you used exactly?

Samuel

Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too

[Samuel Thibault]

Stephen Lyons, le mar. 09 févr. 2021 05:12:01 +, a ecrit:
> +A eventually toggles only between screen 1 (installer)

It's not control+A alone, but control+A then space.

> However it seems like pretty much all key strokes seem to be piling up
> somehow in parts of the installation process.

As I answered privately, possibly the BIOS emulates your USB keyboard
into the PC keyboard in a surprising way. Not something that somebody
without the hardware can easily debug, unfortunately.

Samuel

Bug#982273: libbsd0-udeb: depends on libmd0

[Samuel Thibault]

Cyril Brulebois, le lun. 08 févr. 2021 16:16:17 +0100, a ecrit:
> Guillem Jover  (2021-02-08):
> > I've uploaded it now, once it hits NEW I'll poke ftp-masters. The git
> > and source+binary packages at:
> > 
> >   
> >   
> 
> Looks good to me, thanks!
> 
> Checked libmd build plus libbsd rebuilt against it, resulting udebs
> made available in src:debian-installer's build/localudebs, and the
> dependency tree is fine now.

I scheduled the rebuilds on the buildds with versioned dependency.

Samuel

Bug#982273: libbsd0-udeb: depends on libmd0

[Samuel Thibault]

Guillem Jover, le lun. 08 févr. 2021 13:58:56 +0100, a ecrit:
> I'd rather not revert the switch to use libmd,
> but that requires the d-i team to approve (CCed) such package and
> ftp-masters to approve such package. :/

ftp-master will probably be an easy step, you can probably ping them to
get such trivial addition reviewed quickly.

Samuel

Bug#982283: override: bsdmainutils:oldlibs/optional

[Samuel Thibault]

Chris Hofstaedtler, le lun. 08 févr. 2021 10:19:38 +0100, a ecrit:
> bsdmainutils has become a transitional package in bullseye. It would be
> great if we don't install it by default - right now its Priority:
> important.

For information, bsdmainutils' packaging already sets the priority to
oldlibs.

> Changing this will probably make these utilities not available by
> default:
> 
> from package ncal:
>   cal
>   ncal
> 
> from package bsdextrautils:
>   col
>   colcrt
>   colrm
>   column
>   hd
>   hexdump
>   look
>   ul
>   write

bsdextrautils is recommended by bsdutils which has priority required, so
that one will still get installed by default.

Samuel

Bug#982273: libbsd0-udeb: depends on libmd0

[Samuel Thibault]

Control: clone -1 -2
Control: reassign -2 reportbug
Control: retitle -2 gets source package name wrong

Andrei POPESCU, le lun. 08 févr. 2021 09:35:46 +0200, a ecrit:
> Control: reassign -1 src:libbsd 0.11.1-1
> 
> On Lu, 08 feb 21, 02:25:01, Samuel Thibault wrote:
> > Source: libbsd0-udeb
> 
> The BTS interprets this as Package: src:libbsd0-udeb (which doesn't 
> exist).

Uh, reportbug does it completely wrongly indeed:

$ reportbug libbsd0-udeb
[...]

Which of the following packages is the bug in?

1 libbsd-devutility functions from BSD systems - development files

2 libbsd0   Utilitaires issus des systèmes BSD — bibliothèque partagée

3 libbsd0-dbg   utility functions from BSD systems - debugging symbols

4 libbsd0-udeb  Source package

Select one of these packages:


The package naming is completely off here.

Samuel

Bug#982273: libbsd0-udeb: depends on libmd0

[Samuel Thibault]

Source: libbsd0-udeb
Version: 0.11.1-1
Severity: serious
Justification: makes debian-installer FTBFS

Hello,

The "new upstream" upload of libbsd builds a udeb that depends on a
non-udeb:

The following packages have unmet dependencies:
 libbsd0-udeb : Depends: libmd0 (>= 1.0.3) but it is not installable

Please avoid linking against libmd0, or else add a libmd0-udeb package
to libmd.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Samuel
c> ah (on trouve fluide glacial sur le net, ou il faut aller dans le monde reel 
?)
s> dans le monde reel
c> zut

Bug#981440: bsdmainutils: Please make it only suggest calendar

[Samuel Thibault]

Hello,

Any news on this? It would be good to avoid installing cpp by default on
all base Debian systems.

Samuel

Samuel Thibault, le dim. 31 janv. 2021 12:06:35 +0100, a ecrit:
> Package: bsdmainutils
> Version: 12.1.7
> Severity: important
> 
> Hello,
> 
> In 257885db82a3 ("Split calendar into its own package") the calendar
> package was split out from the bsdmainutils package into its own package
> to save some room since the bsdmainutils is priority important, the
> former suggesting the latter. But a898abc6e8e5 ("Make bsdmainutils a
> transitional package.") later turned the suggestion into a dependency,
> so that calender does get installed.
> 
> The problem is that calendar depends on cpp, and thus in the end the
> base install of Debian bullseye installs cpp, which uses 30MB, just for
> a calendar that was supposed not to be installed by default, I don't
> think we want this :)
> 
> Could you make bsdmainutils back to only suggesting calendar, like it
> used to?
> 
> Samuel
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
> (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
> (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
> 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages calendar depends on:
> ii  cpp  4:10.2.1-1
> ii  libbsd0  0.10.0-1
> ii  libc62.31-9
> 
> calendar recommends no packages.
> 
> calendar suggests no packages.
> 
> -- no debconf information

Bug#982126: Re : Disk with 60801 cylinders (seen in Puppy Gparted) is detected as having 16709 in Hurd

[Samuel Thibault]

Control: reassign -1 gnumach

Please use the reportbug command rather than trying to fill the form by
hand, which is always error-prone.

Paul Dufresne, le sam. 06 févr. 2021 12:14:26 -0500, a ecrit:
> I have tried to install July 2020 version of Hurd on a real (Dual Core 3 Ghz)
> computer.
> 
> AHCI was not working (with a message Phy0? from memory).
> So I change in the BIOS, AHCI to IDE.
> Then the 500 GB disk was detected as:
>  hd2: ST500DM002-1BD142, 131071 MB CHS=16709/255/63
>  
>  I booted a Puppy Linux on it, and in Gparted,
>  CHS=60801/255/63

That's because the IDE driver only supports LBA28. The AHCI driver does
support 2TB devices, see 
http://darnassus.sceen.net/~hurd-web/faq/2_gib_partition_limit/
 
Samuel

Bug#959221: [hurd] install UI slow to point of unusable, even text UI for me too

[Samuel Thibault]

Hello,

Stephen Lyons, le sam. 06 févr. 2021 02:30:43 +, a ecrit:
> However, now I have found #959221

I have to admit I had never noticed that bug report, I don't know why.

> I have to say that trying to install
> onto a real machine with this later and different image does not seem
> any better. Some parts of the UI work acceptably fast but others, like
> around disk partitioning are dangerously unresponsive,

That's odd, I had never seen such behavior, be it in virtual environment
or bare metal. Since you mention disk partitioning, I would guess a bad
interaction between the ahci disk driver and the disk device. Nothing I
can work on personally since on my systems I don't have the issue. Are
there timeout logs being printed?

If you got to the second console with ctrl-alt-f2, and run there

ps | grep R

which processus show up?

Samuel

Bug#981442: apparmor: Please do not install by default or depend on python3

[Samuel Thibault]

intrigeri, le ven. 05 févr. 2021 12:25:58 +0100, a ecrit:
> Samuel Thibault (2021-02-05):
> > I'll keep the VMs around, for any further test you'd want?
> 
> No, that's good enough for me. I'll upload ASAP.

Thanks!

Samuel

Bug#981442: apparmor: Please do not install by default or depend on python3

[Samuel Thibault]

Hello,

intrigeri, le ven. 05 févr. 2021 09:06:54 +0100, a ecrit:
> I did the backporting work in a topic branch:
> https://salsa.debian.org/apparmor-team/apparmor/-/tree/debian-bug-981442

Thanks!

>   4. ensure aa-status works (compare with how it works in a regular
>   testing/sid system)

I tried a bit with the base system, got 

apparmor module is loaded.
3 profiles are loaded.
3 profiles are in enforce mode.
   lsb_release
   nvidia_modprobe
   nvidia_modprobe//kmod
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

just like with the python version. I tried to install tcpdump and ntp, then got

apparmor module is loaded.
5 profiles are loaded.
5 profiles are in enforce mode.
   /usr/sbin/ntpd
   lsb_release
   nvidia_modprobe
   nvidia_modprobe//kmod
   tcpdump
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/ntpd (792)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

I'm not sure how I can easily check for the complain case.
(AIUI they'd be supposed to be bugs :) )


I'll keep the VMs around, for any further test you'd want?

Samuel

Bug#981668: gettext: Fix build without the java build-deps

[Samuel Thibault]

Santiago Vila, le mar. 02 févr. 2021 20:08:30 +0100, a ecrit:
> On Tue, Feb 02, 2021 at 07:49:11PM +0100, Samuel Thibault wrote:
> > That being said my patch is not enough to fix #981669, as the !nojava
> > won't automatically be set for the nojava architectures,
> > [!hppa !hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] would additionally be
> > needed, as well as
> > 
> > ifneq (,$(filter $(DEB_HOST_ARCH),hppa hurd-i386 kfreebsd-amd64 
> > kfreebsd-i386))
> 
> I'm confused. Why is this necessary at all?
> 
> I believed the novaja thing was defined externally as a bootstrapping trick.

It is needed for bootstrapping all archs, yes. But it is also needed
for ports which do not have openjdk ported, and build packages normally
without any profile specification. Debhelper etc. thus ignore ,
and thus the list of archs where openjdk was not ported is currently
unfortunately hardcoded in the concerned packages, yes :/

Samuel

Bug#981668: gettext: Fix build without the java build-deps

[Samuel Thibault]

Santiago Vila, le mar. 02 févr. 2021 19:40:14 +0100, a ecrit:
> On Tue, Feb 02, 2021 at 07:32:33PM +0100, Samuel Thibault wrote:
> > gettext uses  qualifiers in debian/control to allow for a
> > non-java build, but debian/rules still inconditionally uses --with
> > maven-repo-helper. The attached patch fixes this.
> 
> Thanks a lot. Is this essentially the same bug as #981669?
> This is the very first time I receive similar bugs with a 2-minute
> difference...

Yeah, that's such a coincidence, the bug numbers are even consecutive!
I noticed the dependency issue earlier this morning, and only took the
time to have some look now.

That being said my patch is not enough to fix #981669, as the !nojava
won't automatically be set for the nojava architectures,
[!hppa !hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] would additionally be
needed, as well as

ifneq (,$(filter $(DEB_HOST_ARCH),hppa hurd-i386 kfreebsd-amd64 kfreebsd-i386))

Samuel

Bug#981668: gettext: Fix build without the java build-deps

[Samuel Thibault]

Package: gettext
Version: 0.21-3
Severity: normal

Hello,

gettext uses  qualifiers in debian/control to allow for a
non-java build, but debian/rules still inconditionally uses --with
maven-repo-helper. The attached patch fixes this.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gettext depends on:
ii  dpkg   1.20.7.1
ii  gettext-base   0.21-3
ii  install-info   6.7.0.dfsg.2-6
ii  libc6  2.31-9
ii  libgomp1   10.2.1-6
ii  libunistring2  0.9.10-4
ii  libxml22.9.10+dfsg-6.3+b1

Versions of packages gettext recommends:
ii  curl  7.74.0-1
ii  lynx  2.9.0dev.6-1
ii  wget  1.21-1+b1

Versions of packages gettext suggests:
ii  autopoint 0.21-3
pn  gettext-doc   
ii  libasprintf-dev   0.21-3
ii  libgettextpo-dev  0.21-3

-- no debconf information

-- 
Samuel
 Créer une hiérarchie supplementaire pour remedier à un problème (?) de
 dispersion est d'une logique digne des Shadocks.
 * BT in: Guide du Cabaliste Usenet - La Cabale vote oui (les Shadocks aussi) *
--- gettext-0.21/debian/rules   2020-12-20 15:00:00.0 +
+++ gettext-0.21-nojava/debian/rules2021-02-02 17:46:20.0 +
@@ -1,7 +1,11 @@
 #!/usr/bin/make -f
 
+ifeq (,$(filter nojava,$(DEB_BUILD_PROFILES)))
+WITH_MAVEN=--with maven-repo-helper
+endif
+
 %:
-   dh $@ --with elpa --with maven-repo-helper
+   dh $@ --with elpa $(WITH_MAVEN)
 
 
 #

Bug#981442: apparmor: Please do not install by default or depend on python3

[Samuel Thibault]

intrigeri, le lun. 01 févr. 2021 09:16:23 +0100, a ecrit:
> I'm asking because AFAICT, the chain of dependencies has not changed
> between Buster and Bullseye:
> 
>  - the Linux kernel images Recommends: apparmor
>  - apparmor depends python3:any

One thing that changed is that mime-support (which python3.9 depends
on) now depends on mailcap, which pulls in perl. That is getting fixed
through #981016, but still better avoid installing the python stack only
for aa-status :)

Samuel

Bug#981016: python3.9: depends on mime-support which is transitional package

[Samuel Thibault]

Hello,

Martin-Éric Racine, le lun. 25 janv. 2021 18:19:56 +0200, a ecrit:
> Package: python3.9
> Version: 3.9.1-3
> Severity: important

As a side note, this is also important because while in buster
mime-support used to only recommend bzip2, file, and xz-utils, among its
replacement

> Depends: mailcap, media-types

mailcap now *depends* on perl, which pulls in 40MB, which is
significantly heavy for small installation sets.

I see that in the git Mathias replaced mime-support with media-types,
thanks!

Samuel

Bug#981442: apparmor: Please do not install by default or depend on python3

[Samuel Thibault]

Hello,

intrigeri, le lun. 01 févr. 2021 09:16:23 +0100, a ecrit:
> Samuel Thibault (2021-01-31):
> > As of Debian bullseye alpha3, apparmor is getting installed by default
> > even in the base system,
> 
> To be clear, in this context "base system" is d-i terminology, right?

Yes. That's when one selects no task, so the absolute minimum that gets
installed.

> > bringing with it python3 and thus 30MB of
> > various stuff that didn't used to get installed in the past, which I do
> > not think we want.
> 
> Could you please confirm whether "in the past" means "in Stretch and
> older" here, or something else?

I'm surprised here. It does seem that Stretch, even as 10.0, does
install apparmor and thus python, indeed. But I check for the install
size before each Debian release, and did not notice that. Perhaps the
apparmor recommendation appeared late in the Stretch process. I'm
not sure whether debian-boot was aware that python ended up getting
installed.

> > or avoid making it hardly depend on python3?
> 
> The only reason why apparmor "Depends: python3" in current testing/sid
> is that /usr/sbin/aa-status is written in Python.
> 
> Upstream commit 8f9046b1b179190d0003ae1beacf460ee93c5090, included in
> upstream 3.0.0 release, and thus in Debian experimental already,
> ported that program to C, which should allow dropping the dependency
> on python3. I did not check how hard it would be to backport
> this commit.

That would be great to backport!

Samuel

Bug#981442: apparmor: Please do not install by default or depend on python3

[Samuel Thibault]

Samuel Thibault, le dim. 31 janv. 2021 13:19:28 +0100, a ecrit:
> Cc-ing the linux package maintainers since that's what recommends
> apparmor, thus pulling the 30MB.

Actually, that not only pulls python3 but also perl, libicu, and in the
end with dependencies, that amounts to 114MB.

Samuel

> Samuel Thibault, le dim. 31 janv. 2021 12:10:43 +0100, a ecrit:
> > Package: apparmor
> > Version: 2.13.6-7
> > Severity: important
> > 
> > Hello,
> > 
> > As of Debian bullseye alpha3, apparmor is getting installed by default
> > even in the base system, bringing with it python3 and thus 30MB of
> > various stuff that didn't used to get installed in the past, which I do
> > not think we want. Could you have a look at not installing apparmor by
> > default, or avoid making it hardly depend on python3?
> > 
> > Samuel
> > 
> > -- System Information:
> > Debian Release: bullseye/sid
> >   APT prefers testing
> >   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> > 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
> > (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
> > (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
> > 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
> > Architecture: amd64 (x86_64)
> > Foreign Architectures: i386
> > 
> > Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
> > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE 
> > not set
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages apparmor depends on:
> > ii  cdebconf [debconf-2.0]  0.256
> > ii  debconf [debconf-2.0]   1.5.74
> > ii  libc6   2.31-9
> > ii  lsb-base11.1.0
> > ii  python3 3.9.1-1
> > 
> > apparmor recommends no packages.
> > 
> > Versions of packages apparmor suggests:
> > pn  apparmor-profiles-extra  
> > pn  apparmor-utils   
> > 
> > -- debconf information excluded

Bug#981442: apparmor: Please do not install by default or depend on python3

[Samuel Thibault]

Hello,

Cc-ing the linux package maintainers since that's what recommends
apparmor, thus pulling the 30MB.

Also Cc-ing d-b for information.

Samuel

Samuel Thibault, le dim. 31 janv. 2021 12:10:43 +0100, a ecrit:
> Package: apparmor
> Version: 2.13.6-7
> Severity: important
> 
> Hello,
> 
> As of Debian bullseye alpha3, apparmor is getting installed by default
> even in the base system, bringing with it python3 and thus 30MB of
> various stuff that didn't used to get installed in the past, which I do
> not think we want. Could you have a look at not installing apparmor by
> default, or avoid making it hardly depend on python3?
> 
> Samuel
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
> 'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), 
> (500, 'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
> (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
> 'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not 
> set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages apparmor depends on:
> ii  cdebconf [debconf-2.0]  0.256
> ii  debconf [debconf-2.0]   1.5.74
> ii  libc6   2.31-9
> ii  lsb-base11.1.0
> ii  python3 3.9.1-1
> 
> apparmor recommends no packages.
> 
> Versions of packages apparmor suggests:
> pn  apparmor-profiles-extra  
> pn  apparmor-utils   
> 
> -- debconf information excluded

Bug#981442: apparmor: Please do not install by default or depend on python3

[Samuel Thibault]

Package: apparmor
Version: 2.13.6-7
Severity: important

Hello,

As of Debian bullseye alpha3, apparmor is getting installed by default
even in the base system, bringing with it python3 and thus 30MB of
various stuff that didn't used to get installed in the past, which I do
not think we want. Could you have a look at not installing apparmor by
default, or avoid making it hardly depend on python3?

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apparmor depends on:
ii  cdebconf [debconf-2.0]  0.256
ii  debconf [debconf-2.0]   1.5.74
ii  libc6   2.31-9
ii  lsb-base11.1.0
ii  python3 3.9.1-1

apparmor recommends no packages.

Versions of packages apparmor suggests:
pn  apparmor-profiles-extra  
pn  apparmor-utils   

-- debconf information excluded

-- 
Samuel
***e trouve un .xls
***e passe un moment à se demander quelle version de xml c'est ça, le .xls
e: donc j'ai fait un file
 -+- #sos - on n'a pas forcément les mêmes références que tout le monde -+-

Bug#981440: bsdmainutils: Please make it only suggest calendar

[Samuel Thibault]

Package: bsdmainutils
Version: 12.1.7
Severity: important

Hello,

In 257885db82a3 ("Split calendar into its own package") the calendar
package was split out from the bsdmainutils package into its own package
to save some room since the bsdmainutils is priority important, the
former suggesting the latter. But a898abc6e8e5 ("Make bsdmainutils a
transitional package.") later turned the suggestion into a dependency,
so that calender does get installed.

The problem is that calendar depends on cpp, and thus in the end the
base install of Debian bullseye installs cpp, which uses 30MB, just for
a calendar that was supposed not to be installed by default, I don't
think we want this :)

Could you make bsdmainutils back to only suggesting calendar, like it
used to?

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages calendar depends on:
ii  cpp  4:10.2.1-1
ii  libbsd0  0.10.0-1
ii  libc62.31-9

calendar recommends no packages.

calendar suggests no packages.

-- no debconf information

-- 
Samuel
 hiri, le cri ici, c des marrants
 j'ai un rep ".uglyhackdirectorywithoutacls" ds mon home
 -+- #ens-mim en stage -+-

Bug#981436: src:slurm-wlm: autopkgtest hickups

[Samuel Thibault]

Package: src:slurm-wlm
Version: 20.02.6-2
Severity: normal

Hello,

It seems like the slurm-wlm package gets some autopkgtest hickups:

https://ci.debian.net/packages/s/slurm-wlm/testing/ppc64el/

shows failures which seem unrelated to package updates, and sometimes
spuriously blocks package migrations (that used to block hwloc, but a
rebuild fixed it).

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#981418: pocketsphinx: drop unused Build-Depends

[Samuel Thibault]

Hello,

Helmut Grohne, le sam. 30 janv. 2021 19:02:18 +0100, a ecrit:
> It turns out that swig-sphinxbase, gstreamer1.0-plugins-base, swig,
> and libjs-jquery are reported as unused.

I guess that was used for the python support, which was moved to another
package.

> Since pocketsphinx is normally reproducible, the artifacts were
> bit-identical.

Yay for reproducibility :D

Applied, thanks!

Samuel

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Brice Goglin, le mer. 27 janv. 2021 00:12:18 +0100, a ecrit:
> libnuma-dev and libibverbs-dev are also only needed for tests (libnuma
> isn't used in the lib itself since 2.0).

I committed for libnuma, thanks!

For libibverbs-dev, it was removed as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950067

Samuel

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Samuel Thibault, le mar. 26 janv. 2021 22:25:16 +0100, a ecrit:
> Helmut Grohne, le mar. 26 janv. 2021 22:14:22 +0100, a ecrit:
> > Maybe w3m can also be moved to b-d-i though?
> 
> Strictly speaking, no, as it is needed to update the README file from
> the doxygen html file, and it is getting installed in binary:any
> packages. But that's relatively pedantic, since the README file itself
> is an a completely easily modifiable form.

I have commented it, so it is documented how to get it generated, in
case anybody really wants to do it :)

Samuel

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Helmut Grohne, le mar. 26 janv. 2021 14:35:08 +0100, a ecrit:
> +Build-Depends: debhelper-compat (= 12), dh-exec, libltdl-dev [!gnu-any-any],

Ah, that triggers lintian's

E: hwloc source: invalid-arch-string-in-source-relation gnu-any-any 
[Build-Depends: libltdl-dev [!gnu-any-any]]

Samuel

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Helmut Grohne, le mar. 26 janv. 2021 22:14:22 +0100, a ecrit:
> Maybe w3m can also be moved to b-d-i though?

Strictly speaking, no, as it is needed to update the README file from
the doxygen html file, and it is getting installed in binary:any
packages. But that's relatively pedantic, since the README file itself
is an a completely easily modifiable form.

Samuel

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Helmut Grohne, le mar. 26 janv. 2021 14:35:08 +0100, a ecrit:
> Finally, the documentation is not rebuilt during package build.

Ah, that is unexpected actually, we do want to rebuild the
documentation. Is that part a problem for loops?

I applied the rest, thanks!

Samuel

Bug#922744: don't compress debug sections by default

[Samuel Thibault]

Sean Whitton wrote:
> we would like to hear from anyone whose workflows are benefitted by
> having compressed debug symbols turned on by default in debhelper.

I have been hit a few times in the past couple of years by having
to remove some -dbgsym packages (essentially the big ones: firefox,
thunderbird, libreoffice, qt, gtk, etc.) to be able to recover room on
my hdd. Only to reinstall them a bit later when I needed them again to
debug something (after pestering a bit when the backtrace showed up
without symbols), only to remove them again later, etc. So yes, if the
dbgsym installed size was 3x larger the concern would have been even
bigger.

Samuel

Bug#979120: qa.debian.org: Salsa CI results oddly up to date?

[Samuel Thibault]

Control: -1 + unreproducible
Control: close -1

Samuel Thibault, le jeu. 07 janv. 2021 20:10:25 +0100, a ecrit:
> Samuel Thibault, le dim. 03 janv. 2021 02:18:56 +0100, a ecrit:
> > The VCS CI tick is super useful, but it seems it's not always correctly up
> > to date. As of now, on line ccsm of
> > 
> > https://qa.debian.org/developer.php?email=sthibault%40debian.org
> > 
> > there is a "failed" word in the VCS column, while 
> > 
> > https://salsa.debian.org/compiz-team/ccsm/-/pipelines
> > 
> > shows that this has been fixed 3 days ago already.
> 
> The ccsm package does not have the "failed" word any more, but the vmg
> package still has it while
> 
> https://salsa.debian.org/a11y-team/vmg/-/pipelines
> 
> is fixed since a week.

I am not getting any spurious failed word any more, apparently.

Samuel

Bug#980125: vtk9: Fix java dep on non-java ports

[Samuel Thibault]

Package: vtk9
Version: 9.0.1+dfsg1-7
Severity: normal
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

It seems I missed one change in the control file for the non-java ports:
libvtk9-dev shouldn't depend on default-jdk on those archs, as the
attached patch fixes.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages vtk9 depends on:
ii  libc6   2.31-9
ii  libgcc-s1   10.2.1-3
ii  libstdc++6  10.2.1-3
ii  libvtk9 9.0.1+dfsg1-5

vtk9 recommends no packages.

Versions of packages vtk9 suggests:
pn  vtk9-doc   
pn  vtk9-examples  

-- 
Samuel
 argh, pi est plus grand que 2. Ca casse tout
 -+- #ens-mim -+-
--- debian/control.original 2021-01-14 21:22:49.379024997 +0100
+++ debian/control  2021-01-14 21:23:22.074973349 +0100
@@ -85,7 +85,7 @@
 Section: libdevel
 Depends: ${misc:Depends},
  ${shlibs:Depends},
- default-jdk,
+ default-jdk [!hppa !hurd-any !kfreebsd-any],
  default-libmysqlclient-dev,
  libavcodec-dev,
  libavformat-dev,

Bug#980031: pyqt5: FTBFS on !linux

[Samuel Thibault]

Source: pyqt5
Version: 5.15.2+dfsg-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

Since qtconnectivity5-dev is linux-only, pyqt5 cannot be built on !linux
ports. The attached patch fixes it.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Samuel
"I don't know why, but first C programs tend to look a lot worse than
first programs in any other language (maybe except for fortran, but then
I suspect all fortran programs look like `firsts')"
(By Olaf Kirch)
--- debian/control.original 2021-01-11 21:30:45.0 +
+++ debian/control  2021-01-13 07:42:50.0 +
@@ -30,7 +30,7 @@
python3-pyqtbuild (>= 1.6),
python3-sipbuild (>= 5.5.0+dfsg-2~),
python3-sipbuild-dbg (>= 5.3),
-   qtconnectivity5-dev,
+   qtconnectivity5-dev [linux-any],
qtdeclarative5-dev (>= 5.9.1),
qtlocation5-dev (>= 5.9.1),
qtmultimedia5-dev (>= 5.9.1),
@@ -538,7 +538,7 @@
  This package contains the extension built for the Python 3 debug interpreter.
 
 Package: python3-pyqt5.qtbluetooth
-Architecture: any
+Architecture: linux-any
 Depends: python3-pyqt5 (= ${binary:Version}),
  ${misc:Depends},
  ${python3:Depends},
@@ -550,7 +550,7 @@
 
 Package: python3-pyqt5.qtbluetooth-dbg
 Section: debug
-Architecture: any
+Architecture: linux-any
 Depends: python3-dbg,
  python3-pyqt5-dbg (= ${binary:Version}),
  python3-pyqt5.qtbluetooth (= ${binary:Version}),
@@ -562,7 +562,7 @@
  This package contains the extension built for the Python 3 debug interpreter.
 
 Package: python3-pyqt5.qtnfc
-Architecture: any
+Architecture: linux-any
 Depends: python3-pyqt5 (= ${binary:Version}),
  ${misc:Depends},
  ${python3:Depends},
@@ -574,7 +574,7 @@
 
 Package: python3-pyqt5.qtnfc-dbg
 Section: debug
-Architecture: any
+Architecture: linux-any
 Depends: python3-dbg,
  python3-pyqt5-dbg (= ${binary:Version}),
  python3-pyqt5.qtnfc (= ${binary:Version}),

Bug#978806: eztrace: ftbfs with autoconf 2.70

[Samuel Thibault]

Control: tags -1 unreproducible moreinfo

Matthias Klose, le jeu. 31 déc. 2020 14:27:20 +, a ecrit:
> The package fails to build in a test rebuild on at least amd64 with
> autoconf 2.70, but succeeds to build with autoconf 2.69.

> The full build log can be found at:
> http://qa-logs.debian.net/2020/09/26.ac270/eztrace_1.1-8-6_unstable_ac270.log

Matthias Klose, le ven. 08 janv. 2021 13:58:56 +0100, a ecrit:
> Control: reassign -1 eztrace
> 
> > My understanding is that the problem comes from autoconf.
> 
> and that's the reason that you reassign to a third package? Not amused.

I meant that some autoconf test apparently triggered an issue with gcc:

> /usr/include/c++/10/cstdlib:151:11: error: 'malloc' has not been declared in 
> '::'
>   151 |   using ::malloc;
>   |   ^~

But as François found:

> The conftest.cpp file generated by autoconf contains
> 
>  #define malloc rpl_malloc
> 
> which may mess with stdlib.h.

It's the "'malloc' has not been declared in '::'" message that looks
odd, if it was telling rpl_malloc, I would have understood that the
concern is not in gcc. Now,

> Simplifying the conftest.cpp to this shows the problem:
> // conftest.cpp
> #define malloc rpl_malloc
> #include 

That rpl_malloc is due to this:

configure:14650: checking for GNU libc compatible malloc
configure:14682: g++ -o conftest -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now conftest.cpp -liberty -lz -lpthread 
-lm -ldl  >&5
conftest.cpp: In function 'int main()':
conftest.cpp:43:18: error: invalid conversion from 'void*' to 'char*' 
[-fpermissive]
   43 | char *p = malloc (0);
  |   ~~~^~~
  |  |
  |  void*

but... where is this code actually coming from?? I tried to install
autoconf/experimental, the eztrace package built fine... and indeed that
version of autoconf has:

./autoconf/autoconf.m4f: [[void *p = malloc (0);

not char *. Was the rebuild really made with autoconf 2.70-1?
(FTR, autoconf 2.69 generates return ! malloc (0); instead)

Samuel

Bug#978098: webkit2gtk: Re-enable build for hurd-i386?

[Samuel Thibault]

Alberto Garcia, le ven. 08 janv. 2021 17:54:25 +0100, a ecrit:
> realpath(3) says that passing NULL to that function is
> implementation-defined in POSIX.1-2001, and only properly specified in
> POSIX.1-2008, so I would expect that you need to check for a different
> version.

Mmm, indeed.

“
Issue 7

This function is updated for passing a null pointer to realpath() for the 
resolved_name argument.
”

that's posix2008 only then.

so even if the interpretation


> Either way, is there any modern system that does not implement
> POSIX.1-2008?

That can be an argument indeed! Some people may not buy it, but less and
less so :)

> I also saw that Samuel already sent the changes to computeRAMSize()
> upstream, and that earlier someone added support for FreeBSD, so maybe
> we can enable replace 'linux-any hurd-any' by simply 'any'.

Possibly indeed.

Samuel

Bug#979120: qa.debian.org: Salsa CI results oddly up to date?

[Samuel Thibault]

Hello,

Samuel Thibault, le dim. 03 janv. 2021 02:18:56 +0100, a ecrit:
> The VCS CI tick is super useful, but it seems it's not always correctly up
> to date. As of now, on line ccsm of
> 
> https://qa.debian.org/developer.php?email=sthibault%40debian.org
> 
> there is a "failed" word in the VCS column, while 
> 
> https://salsa.debian.org/compiz-team/ccsm/-/pipelines
> 
> shows that this has been fixed 3 days ago already.

The ccsm package does not have the "failed" word any more, but the vmg
package still has it while

https://salsa.debian.org/a11y-team/vmg/-/pipelines

is fixed since a week.

Samuel

Bug#967123: debian-installer: Unversioned Python removal in sid/bullseye

[Samuel Thibault]

Cyril Brulebois, le mar. 05 janv. 2021 20:28:52 +0100, a ecrit:
> Matthias Klose  (2020-08-04):
> > Your package either build-depends, depends on one of those packages.
> 
> I couldn't find any hit on “python” (that would be relevant) in current
> git, current version, or the version you filed this bug report against.

I guess the report was based on e.g.

https://buildd.debian.org/status/fetch.php?pkg=debian-installer=amd64=20200314=1584184547=0

which shows python getting installed for the build.


But

https://buildd.debian.org/status/fetch.php?pkg=debian-installer=amd64=20201202=1606924683=0

doesn't show it, so I guess it was a transitive dep that got fixed.

Samuel

Bug#979160: glibc FTBFS on kfreebsd-*: Uses configure option --enable-add-ons=fbtl

[Samuel Thibault]

Hello,

Mattias Ellert, le dim. 03 janv. 2021 18:19:37 +0100, a ecrit:
>   --enable-add-ons=libidn,"fbtl " \
> 
> However, the configure script does not have an --enable-add-ons option,
> so this is ignored. (Option is not listed by ./configure --help, nor
> found by grepping for it.)

FI, in NEWS:

* The add-ons mechanism for building additional packages at the same time as
  glibc has been removed.  The --enable-add-ons configure option is now
  ignored.

So fbtl needs to be included in Makefiles etc. just like htl is for
instance.

Samuel

Bug#919561: Please display Debian CI status for contrib/non-free packages on DDPO

[Samuel Thibault]

Hello,

M. Zhou, le jeu. 17 janv. 2019 08:28:24 +, a ecrit:
> For example, ci.d.o keeps running autopkgtest for zfs-linux and
> intel-mkl on Debian testing, but the result is not displayed on my DDPO
> page[1].
> 
> https://ci.debian.net/packages/z/zfs-linux/testing/amd64/
> https://ci.debian.net/packages/i/intel-mkl/testing/amd64/
> 
> [1] https://qa.debian.org/developer.php?login=lumin

This seems to have been fixed?

Samuel

Bug#979120: qa.debian.org: Salsa CI results oddly up to date?

[Samuel Thibault]

Package: qa.debian.org
Severity: normal

Hello,

The VCS CI tick is super useful, but it seems it's not always correctly up
to date. As of now, on line ccsm of

https://qa.debian.org/developer.php?email=sthibault%40debian.org

there is a "failed" word in the VCS column, while 

https://salsa.debian.org/compiz-team/ccsm/-/pipelines

shows that this has been fixed 3 days ago already.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Samuel
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)."
(By Matt Welsh)

Bug#653916: cmake doesn't read $CPPFLAGS, ignores some hardening flags

[Samuel Thibault]

Modestas Vainius, le lun. 27 févr. 2012 00:54:52 +0200, a ecrit:
> The plan how to solve this problem properly on the cmake side has been 
> outlined in the upstream bug report [1]. The rest [2] will have to be done by 
> package maintainers / dh / cdbs.
> 
> [1] http://www.cmake.org/Bug/view.php?id=12928#c28716
> [2] -DCMAKE_POLICY_DEFAULT_CMP=NEW

FTR, we are missing CPPFLAGS in the "c++ -dM -E" commands:

https://salsa.debian.org/debian/vite/-/jobs/1298406

353:CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c 
/usr/share/cmake-3.18/Modules/CMakeCXXCompilerABI.cpp -DMT_PARSING 
-DQT_CHARTS_LIB -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB 
-DQT_SVG_LIB -DQT_UITOOLS_LIB -DQT_WIDGETS_LIB -DQT_XML_LIB 
-I/usr/include/open-trace-format 
-I/builds/debian/vite/debian/output/source_dir/obj-x86_64-linux-gnu/src/common 
-I/builds/debian/vite/debian/output/source_dir/obj-x86_64-linux-gnu/src 
-I/builds/debian/vite/debian/output/source_dir/src 
-I/builds/debian/vite/debian/output/source_dir/externals/qtcolorpicker/src 
-I/usr/include/x86_64-linux-gnu/qt5 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++ 
-I/usr/include/x86_64-linux-gnu/qt5/QtXml 
-I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL 
-I/usr/include/x86_64-linux-gnu/qt5/QtUiTools 
-I/usr/include/x86_64-linux-gnu/qt5/QtCharts 
-I/usr/include/x86_64-linux-gnu/qt5/QtSvg -I/usr/include/c++/10 
-I/usr/include/x86_64-linux-gnu/c++/10 -I/usr/include/c++/10/backward 
-I/usr/lib/gcc/x86_64-linux-gnu/10/include -I/usr/local/include 
-I/usr/include/x86_64-linux-gnu -I/usr/include

I circumvented the issue by passing
-DCMAKE_CXX_COMPILER_ARG1="$(CPPFLAGS)" to cmake

Samuel

Bug#950793: blhc: Reports missing -D_FORTIFY_SOURCE=2 for libtool linking

[Samuel Thibault]

Hello,

Thomas Stewart, le jeu. 06 févr. 2020 15:21:16 +, a ecrit:
> CPPFLAGS missing (-D_FORTIFY_SOURCE=2): libtool: link: (cd .libs && gcc -g 
> -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall -c -fno-builtin "w1retapS.c")

"me too" with the speech-dispatcher package.

https://salsa.debian.org/tts-team/speech-dispatcher/-/jobs/1295146

CPPFLAGS missing (-D_FORTIFY_SOURCE=2): libtool: link: (cd .libs && gcc -g -O2 
-fdebug-prefix-map=/builds/tts-team/speech-dispatcher/debian/output/source_dir=.
 -fstack-protector-strong -Wformat -Werror=format-security -c -fno-builtin 
"sd_dummyS.c")

> However looking at the build log snippet[0] the full command is actually
> a call to libtool in link mode. This libtool invocation generates a new
> S.c file to generate dlsyms information. Looking at the internals of a
> generated libtool[1], it's basing the gcc args on LTCFLAGS.
> 
> When libtool is generated it bases its LTCFLAGS from CFLAGS[2]. Looking
> at the dpkg-buildflags hardening the -D_FORTIFY_SOURCE=2 flag is for
> CPPFLAGS rather than CFLAGS[3].

In the debian packaging we don't really have control over the LTCFLAGS
definition, so we can't really fix it there. We'd thus need either blhc
to ignore these libtool-related builds, or libtool to be patched to
include CPPFLAGS in LTCFLAGS.

Samuel

Bug#978659: vtk9: FTBFS on hurd-i386 and non-java ports

[Samuel Thibault]

Package: vtk9
Version: 9.0.1+dfsg1-5
Severity: important
Tags: patch

Hello,

Just like for vtk7, vtk9 needs fixes on hurd-i386 (for applism), and on
non-java ports, please see the attached patches.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages vtk9 depends on:
ii  libc6   2.31-6
ii  libgcc-s1   11-20201216-2
ii  libstdc++6  11-20201216-2
pn  libvtk9 

vtk9 recommends no packages.

Versions of packages vtk9 suggests:
pn  vtk9-doc   
pn  vtk9-examples  

-- 
Samuel
 bouhouhouh, b il m'a abandonné. Tout ca parce que je regardais plus mon 
emacs que lui !
 s/lui/ses messages irc/
 -+- #ens-mim esseulé -+-
https://gitlab.kitware.com/diatomic/diy/-/merge_requests/59

>From bb0d55c8ae34a43354b1002262dad722c410d8cb Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Sat, 13 Jun 2020 13:59:31 +0200
Subject: [PATCH] Fix build on mach-based OS which are not OS X

---
 include/diy/time.hpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/time.hpp 
b/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/time.hpp
index 692cf36..671e69d 100644
--- a/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/time.hpp
+++ b/ThirdParty/diy2/vtkdiy2/include/vtkdiy2/time.hpp
@@ -3,11 +3,11 @@
 
 #ifndef _WIN32
 #include 
-#ifdef __MACH__
+#if defined(__MACH__) && defined(__APPLE__)
 #include 
 #include 
-#endif // __MACH__
+#endif // __MACH__ && __APPLE__
 #endif // ifndef _WIN32
 
 namespace diy
 {
@@ -16,7 +16,7 @@ typedef unsigned long   time_type;
 
 inline time_type get_time()
 {
-#ifdef __MACH__ // OS X does not have clock_gettime, use clock_get_time
+#if defined(__MACH__) && defined(__APPLE__) // OS X does not have 
clock_gettime, use clock_get_time
 clock_serv_t cclock;
 mach_timespec_t ts;
 host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, );
-- 
GitLab

--- debian/control.original 2020-12-29 14:14:29.0 +
+++ debian/control  2020-12-29 14:15:29.0 +
@@ -8,7 +8,7 @@
 Build-Depends: chrpath,
cmake (>= 3.2.0),
debhelper-compat (= 13),
-   default-jdk,
+   default-jdk [!hppa !hurd-any !kfreebsd-any],
default-libmysqlclient-dev,
dh-python,
doxygen-latex,
@@ -115,7 +115,7 @@
  libtiff-dev,
  libutfcpp-dev,
  libvtk9 (= ${binary:Version}),
- libvtk9-java (= ${binary:Version}),
+ libvtk9-java (= ${binary:Version}) [!hppa !hurd-any !kfreebsd-any],
  libx11-dev,
  libxft-dev,
  libxml2-dev,
@@ -161,7 +161,7 @@
  that use VTK.
 
 Package: libvtk9-java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha 
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
 Section: java
 Depends: ${java:Depends},
  ${misc:Depends},
--- debian/rules.original   2020-12-29 14:15:37.0 +
+++ debian/rules2020-12-29 14:18:12.0 +
@@ -3,7 +3,11 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 
+nojava_archs=hppa hurd-i386 kfreebsd-i386 kfreebsd-amd64
+ifneq ($(DEB_BUILD_ARCH),$(filter $(DEB_BUILD_ARCH), $(nojava_archs)))
 export JAVA_HOME=/usr/lib/jvm/default-java
+extra_flags += -DVTK_WRAP_JAVA=ON
+endif
 
 ifneq (,$(filter $(DEB_HOST_ARCH), armel m68k mips mipsel powerpc sh4))
   export DEB_CXXFLAGS_MAINT_APPEND += -Wl,--no-as-needed -latomic 
-Wl,--as-needed
@@ -52,7 +56,6 @@
-DVTK_MODULE_USE_EXTERNAL_VTK_zlib:BOOL=ON \
-DVTK_PYTHON_VERSION:STRING=3 \
-DVTK_USE_TK=ON \
-   -DVTK_WRAP_JAVA=ON \
-DVTK_WRAP_PYTHON=ON \
 -DCMAKE_BUILD_TYPE=RelWithDebInfo
 
@@ -70,8 +73,10 @@
 
 override_dh_auto_install:
dh_auto_install -X.pyc -X.pyo
+ifneq ($(JAVA_HOME),)
# Correct headers for paraview
mv $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/java/vtk.jar 
$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/java/vtk9.jar
+endif
sed -i -e "s/FATAL_ERROR/STATUS/g" 
$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/vtk-9.0/VTK-targets.cmake
 
 override_dh_install:

Bug#978611: fenrir: New version available

[Samuel Thibault]

Control: clone -1 -2
Control: reassign -2 python-daemonize
Control: retitle -2 Please package version >= 2.5.0
Control: block -1 by -2

Davide Prina, le mar. 29 déc. 2020 09:51:51 +0100, a ecrit:
> Here: https://github.com/chrys87/fenrir
> there is a new version 1.9.6

Yes, I had already worked on this, but it requires python3-daemonize
>= 2.5.0 which is not packaged yet.

Samuel

Bug#978098: webkit2gtk: Re-enable build for hurd-i386?

[Samuel Thibault]

Hello,

Laurent Bigonville, le ven. 25 déc. 2020 23:15:54 +0100, a ecrit:
> Shouldn't the patch be applied in "official" package as well (and maybe
> upstream)?

Debian maintainers usually prefer to see patches applied upstream before
adding them to their packaging. They are already submitted upstream, see
URLs in the patch file. Some of them are already applied, others need
some rework, help welcome!

And they usually rather see a complete working set before changing debian/

Samuel

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

Santiago Vila, le dim. 27 déc. 2020 00:59:23 +0100, a ecrit:
> On Sun, Dec 27, 2020 at 12:29:01AM +0100, Samuel Thibault wrote:
> > Lucas Nussbaum, le sam. 26 déc. 2020 22:52:15 +0100, a ecrit:
> > > > INTLTOOL_EXTRACT="/usr/bin/intltool-extract" 
> > > > XGETTEXT="/usr/bin/xgettext" srcdir=. /usr/bin/intltool-update 
> > > > --gettext-package dasher --pot
> > > > xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && 
> > > > UNICODE_VALUE (c) < 0x11' failed.
> > > > ERROR: xgettext failed to generate PO template file. Please consult
> > > >error message above if there is any.
> > 
> > And this is due to this part of dasher:
> > 
> >   EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
> >WideStringToUtf8(L"\xABCDFF", -1).c_str());
> > 
> > which is precisely *expected* to be an invalid code-point... Since this
> > string is not marked as to be translated, xgettext shouldn't error out
> > about it?
> 
> I don't know.
> 
> It must be noted that I uploaded gettext 0.21 for unstable recently
> and it propagated to testing today. Apparently the new gettext is more
> nitpicky than the old one.
> 
> My feeling is that somehow you are calling xgettext "implicitly", i.e.
> without being really aware that you are in fact calling xgettext.

Well, it does seem that upstream's intent really is to call xgettext
over the source code, to extract translatable strings.

> If required I can ask gettext upstream about this, but we would need a
> minimal test case and a little bit more of investigation on our side.

€ cat test.c

#include 

void f(const wchar_t *str) { }

void g(void) {
f(L"\xABCDFF");
}


€ xgettext test.c
xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && 
UNICODE_VALUE (c) < 0x11' failed.

Samuel

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

Hello gettext maintainers,

Lucas Nussbaum, le sam. 26 déc. 2020 22:52:15 +0100, a ecrit:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > INTLTOOL_EXTRACT="/usr/bin/intltool-extract" XGETTEXT="/usr/bin/xgettext" 
> > srcdir=. /usr/bin/intltool-update --gettext-package dasher --pot
> > xgettext: x-c.c:1666: phase5_get: Assertion `UNICODE_VALUE (c) >= 0 && 
> > UNICODE_VALUE (c) < 0x11' failed.
> > ERROR: xgettext failed to generate PO template file. Please consult
> >error message above if there is any.

And this is due to this part of dasher:

  EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
   WideStringToUtf8(L"\xABCDFF", -1).c_str());

which is precisely *expected* to be an invalid code-point... Since this
string is not marked as to be translated, xgettext shouldn't error out
about it?

Samuel

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

Samuel Thibault, le dim. 27 déc. 2020 00:13:55 +0100, a ecrit:
> FTR, the file that poses problem is Testing/gtest/test/gtest_unittest.cc
> This is not something that contains anything to be translated, we'd need
> some option to just ignore Testing/ entirely.

More precisely, it is line 

  EXPECT_STREQ("(Invalid Unicode 0xABCDFF)",
   WideStringToUtf8(L"\xABCDFF", -1).c_str());

which is *expected* to be an invalid code-point...

Samuel

Bug#978315: dasher: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2

[Samuel Thibault]

FTR, the file that poses problem is Testing/gtest/test/gtest_unittest.cc
This is not something that contains anything to be translated, we'd need
some option to just ignore Testing/ entirely.

Samuel

Bug#978164: kguiaddons: FTBFS on non-linux

[Samuel Thibault]

Pino Toscano, le sam. 26 déc. 2020 22:04:14 +0100, a ecrit:
> Yes, I know. I already fixed it few days ago:
> https://salsa.debian.org/qt-kde-team/kde/kguiaddons/-/commit/1130cd0d8f0c95c9536a74034826fbb0ed5f0d8c

Cool, thanks!

Samuel

Bug#978164: kguiaddons: FTBFS on non-linux

[Samuel Thibault]

Source: kguiaddons
Version: 5.77.0-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

kguiaddons currently doesn't build on non-Linux, where Wayland is not
available. The attached patch fixes this.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

-- 
Samuel
 KK1 a 1 conseil de comment s'attaquer a du code java ou ya plus de 50 
classes ? par kel bout ?
 le troisième
 -+- #ens-mim en stage -+-
--- debian/control.original 2020-12-26 20:33:59.0 +
+++ debian/control  2020-12-26 20:34:21.0 +
@@ -10,9 +10,9 @@
extra-cmake-modules (>= 5.77.0~),
graphviz,
libqt5sql5-sqlite:native,
-   libqt5waylandclient5-dev (>= 5.13.0~),
+   libqt5waylandclient5-dev (>= 5.13.0~) [linux-any],
libqt5x11extras5-dev (>= 5.13.0~),
-   libwayland-dev (>= 1.9~),
+   libwayland-dev (>= 1.9~) [linux-any],
libx11-dev,
libxcb1-dev,
pkg-config,
@@ -21,7 +21,7 @@
qtbase5-private-dev,
qttools5-dev,
qttools5-dev-tools (>= 5.4),
-   qtwayland5-dev-tools (>= 5.13.0~),
+   qtwayland5-dev-tools (>= 5.13.0~) [linux-any],
 Standards-Version: 4.5.1
 Homepage: https://invent.kde.org/frameworks/kguiaddons
 Vcs-Browser: https://salsa.debian.org/qt-kde-team/kde/kguiaddons
--- debian/rules.original   2020-12-26 20:42:47.0 +
+++ debian/rules2020-12-26 20:43:55.0 +
@@ -2,11 +2,15 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+ifneq ($(DEB_BUILD_ARCH_OS),linux)
+WAYLAND=-DWITH_WAYLAND=OFF
+endif
+
 %:
dh $@ --with kf5,pkgkde_symbolshelper --buildsystem kf5 --without 
build_stamp
 
 override_dh_auto_configure:
-   dh_auto_configure -- -DBUILD_QCH=ON -DBUILD_TESTING=OFF
+   dh_auto_configure -- -DBUILD_QCH=ON -DBUILD_TESTING=OFF $(WAYLAND)
 
 override_dh_auto_test:
# Disable auto tests at build time
--- debian/libkf5guiaddons5.symbols.original2020-12-26 20:49:28.0 
+
+++ debian/libkf5guiaddons5.symbols 2020-12-26 20:49:33.0 +
@@ -184,5 +184,5 @@
  _ZTV19KeySequenceRecorder@Base 5.77.0
  _ZTV24KModifierKeyInfoProvider@Base 5.61.0
  _ZTV30KLocalImageCacheImplementation@Base 4.96.0
- zwp_keyboard_shortcuts_inhibit_manager_v1_interface@Base 5.77.0
- zwp_keyboard_shortcuts_inhibitor_v1_interface@Base 5.77.0
+ (arch=linux-any)zwp_keyboard_shortcuts_inhibit_manager_v1_interface@Base 
5.77.0
+ (arch=linux-any)zwp_keyboard_shortcuts_inhibitor_v1_interface@Base 5.77.0

Bug#977469: matplotlib: Please make package bootstrappable

[Samuel Thibault]

John Paul Adrian Glaubitz, le jeu. 17 déc. 2020 23:47:42 +0100, a ecrit:
> You just solved that mystery for me. I was already starting to question
> my sanity when the --profile switch didn't work as expected :-).

It was driving me crazy in the past couple hours as well, I was
questioning the support in sbuild, in pbuilder, and at the point of
trying mk-build-deps with the nodoc profile instead of the stage1
profile, I at last noticed that the  were working but not the
  :)

Samuel

Bug#977469: matplotlib: Please make package bootstrappable

[Samuel Thibault]

Hello,

While at it:

   python3-sphinx-gallery (>= 0.7.0)  ,

I believe you meant

   python3-sphinx-gallery (>= 0.7.0) ,

So that the python3-sphinx-gallery dep is disable when using the stage1
profile alone or when using the nodoc profile alone. Currently one has
to using both the stage1 and the nodoc profiles to break the

python3-matplotlib -> python3-sphinx-gallery -> python3-matplotlib

loop.

Samuel

Bug#976247: speech-dispatcher: conffiles not removed: /etc/speech-dispatcher/modules/ kali.conf ibmtts.conf baratinoo.conf

[Samuel Thibault]

Hello,

Guillem Jover, le lun. 14 déc. 2020 01:51:58 +0100, a ecrit:
> and then conditionally run rm_conffile in speech-dispatcher
> iff speech-dispatcher-kali is not present?

Right, that seems to be doing the job.

Thanks!
Samuel

Bug#977466: rootskel: bterm cannot start when requesting graphical console and serial console at the same time

[Samuel Thibault]

Re,

Alper Nebi Yasak, le mar. 15 déc. 2020 23:42:16 +0300, a ecrit:
> I've tested with this and the patch for rootskel, and in the text-based
> installer on the framebuffer the black boxes are replaced with actual
> characters (arm64 QEMU, with console=ttyAMA0 console=tty0).
> 
> Can you apply that and do a release for rootskel if that's fine?
> (also see: a small fix for the changelog [1])

I applied it, thanks!

Samuel

Bug#977466: rootskel: bterm cannot start when requesting graphical console and serial console at the same time

[Samuel Thibault]

Wang Shanker, le mer. 16 déc. 2020 01:05:58 +0800, a ecrit:
> I carried out a simple test by limiting memory of my qemu machine
> and appending `lowmem=2` to the kernel command line. I can confirm
> that btrem and its font file get deleted.

Ok, good!

Thanks for testing, I have uploaded the fix to lowmem.

Samuel

Bug#977466: rootskel: bterm cannot start when requesting graphical console and serial console at the same time

[Samuel Thibault]

Hello,

Wang Shanker, le mer. 16 déc. 2020 00:53:27 +0800, a ecrit:
> Then I believe the following patch will remove unnecessary files when the
> memory is not enough.

Thanks!

But "believe" is not enough, we need someone to actually test it :)

Samuel

Bug#977477: release-notes: Update apt upgrade guidance (Was: Re: Bug#977477: apt: Adding progression indication to apt-get output)

[Samuel Thibault]

Julian Andres Klode, le mar. 15 déc. 2020 16:15:23 +0100, a ecrit:
> > The problem is that these are not equivalent: apt upgrade will attempt
> > to install additional packages required by newer versions of existing
> > packages. That can lead to conflicts/breaks with other existing
> > packages, and thus get into all the complexity that using apt-get
> > upgrade first avoids.
> 
> You mean that using apt upgrade upgrades more packages already, and
> hence dist-upgrade has less conflicts?

No, I mean that apt upgrade will encounter more conflicts by trying to
install newer packages, which may break/conflict other old packages.

> :D You can argue that in circles, you don't know which is going to be
> better.

Whatever is "best" or "worse", what we want is that what users actually
use is what is documented and *tested*. If we fail that we'll continue
seeing users getting trapped into conflicts etc.

> Of course people are free to apt upgrade --without-new-pkgs. The
> optimal way to upgrade likely is
> 
> apt upgrade --without-new-pkgs
> apt upgrade
> apt full-upgrade
> 
> which is equivalent to
> 
> apt-get upgrade
> apt-get upgrade --with-new-pkgs
> apt-get dist-upgrade

Will the second step nicely behave in the case of a new package that
conflicts/breaks with an old already-installed package?

> > The problem is then that actual users end up in *other* situations than
> > what would typically be tested according to the release notes.
> 
> People should test apt for interactive systems, and apt-get for
> non-interactive systems, as always.

I believe few developpers know this, and have their hands used to
apt-get, not apt. As shown by the release notes which document using
apt-get, not apt.

> Enabling progress for apt-get - the legacy scripting frontend -
> is a no-go. As is removing it from apt - the interactive user's
> frontend.

So we'd rather make release-notes document using apt instead of
apt-get? I'm fine with that but we *ALSO* need to make sure that debian
developers actually *test* that path, and not the apt-get path.

Samuel

Bug#977466: rootskel: bterm cannot start when requesting graphical console and serial console at the same time

[Samuel Thibault]

Wang Shanker, le mar. 15 déc. 2020 22:59:52 +0800, a ecrit:
> Thanks for your response. In `S15lowmem`, I can see the limit for the
> memory is around tens or hundreds of megabytes. The font file, however,
> is only around 200K. I doubt the necessity of removing it. 

200K+200K+200K+... in various packages, ends up getting a few
megabytes. So yes, it does make a difference in the end.

> Just to confirm, if the font must be deleted, shall we add the rm into
> https://salsa.debian.org/installer-team/lowmem/-/blob/master/lowmem_debconf ?

Yes (it seems I pointed you at the installed path instead of the source,
indeed :) )

Samuel

Bug#977477: apt: Adding progression indication to apt-get output

[Samuel Thibault]

I forgot to mention: yes, the addition of number in the package name
provides some indication, but that is too small for people to notice or
find it usable.

Samuel

Bug#977477: apt: Adding progression indication to apt-get output

[Samuel Thibault]

Package: apt
Version: 2.1.12
Severity: normal

Hello,

The release notes tell people that they should basically use

apt-get upgrade
apt-get dist-upgrade

But people tend to rather use

apt upgrade
apt dist-upgrade

I guess essentially because apt provides progression indication.

The problem is that these are not equivalent: apt upgrade will attempt
to install additional packages required by newer versions of existing
packages. That can lead to conflicts/breaks with other existing
packages, and thus get into all the complexity that using apt-get
upgrade first avoids.

The problem is then that actual users end up in *other* situations than
what would typically be tested according to the release notes.

We can try to insist on making people use apt-get upgrade instead of apt
upgrade, but I believe that can only work if apt-get provides at least
*some* progress indication, especially for distribution upgrades, whose
duration are quite unknown before doing them.

Alternatively, we could fix apt into behaving really like apt-get, to
avoid that discrepancy between what debian developers actually test and
what users actually use.

Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apt depends on:
ii  adduser 3.118
ii  debian-archive-keyring  2019.1
ii  gpgv2.2.20-1
ii  gpgv1   1.4.23-1+b1
ii  libapt-pkg6.0   2.1.12
ii  libc6   2.31-5
ii  libgcc-s1   10.2.1-1
ii  libgnutls30 3.6.15-4
ii  libseccomp2 2.5.0-3+b1
ii  libstdc++6  10.2.1-1
ii  libsystemd0 247.1-3

Versions of packages apt recommends:
ii  ca-certificates  20200601

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.13-2+b1
ii  dpkg-dev1.20.5
ii  gnupg   2.2.20-1
ii  gnupg1  1.4.23-1+b1
ii  gnupg2  2.2.20-1
ii  powermgmt-base  1.36
ii  synaptic0.90.2

-- no debconf information

Bug#977466: rootskel: bterm cannot start when requesting graphical console and serial console at the same time

[Samuel Thibault]

Wang Shanker, le mar. 15 déc. 2020 20:17:50 +0800, a ecrit:
> The cause of the probem is in the `S70menu` script, where the font file
> get deleted when bterm is not used.

Ok but this is done on purpose for the lowmem case. We probably need to
put that rm back into the lowmem package then, I guess it would be in
./debian/lowmemcheck/bin/lowmem_debconf along disabling the framebuffer.

Samuel

Bug#977009: vtk7: FTBFS on hurd-i386 due to Applism

[Samuel Thibault]

Package: vtk7
Version: 7.1.1+dfsg2-4
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

Could you apply the attached upstream patch from

https://gitlab.kitware.com/diatomic/diy/-/commit/bb0d55c8ae34a43354b1002262dad722c410d8cb.patch

to fix the build on hurd-i386?

Thanks,
Samuel

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages vtk7 depends on:
ii  libc62.31-5
ii  libgcc-s1 [libgcc1]  10.2.0-19
ii  libstdc++6   10.2.0-19
ii  libtcl8.68.6.10+dfsg-1
ii  libtk8.6 8.6.10-1
pn  libvtk7.1
pn  libvtk7.1p   

vtk7 recommends no packages.

Versions of packages vtk7 suggests:
pn  vtk7-doc   
pn  vtk7-examples  

-- 
Samuel
 le y est un animal discret se logeant facilement dans un terminal
*** c has changed the topic on channel #ens-mim to ne pas jeter de cacahuetes 
aux ys, svp
 -+- #ens-mim - n'oubliez pas le guide -+-
>From bb0d55c8ae34a43354b1002262dad722c410d8cb Mon Sep 17 00:00:00 2001
From: Samuel Thibault 
Date: Sat, 13 Jun 2020 13:59:31 +0200
Subject: [PATCH] Fix build on mach-based OS which are not OS X

---
 include/diy/time.hpp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ThirdParty/diy2/vtkdiy2/include/vtkdiy/time.hpp 
b/ThirdParty/diy2/vtkdiy2/include/vtkdiy/time.hpp
index 692cf36..671e69d 100644
--- a/ThirdParty/diy2/vtkdiy2/include/vtkdiy/time.hpp
+++ b/ThirdParty/diy2/vtkdiy2/include/vtkdiy/time.hpp
@@ -3,10 +3,10 @@
 
 #include 
 
-#ifdef __MACH__
+#if defined(__MACH__) && defined(__APPLE__)
 #include 
 #include 
-#endif
+#endif
 
 namespace diy
 {
@@ -16,7 +16,7 @@ typedef unsigned long   time_type;
 
 inline time_type get_time()
 {
-#ifdef __MACH__ // OS X does not have clock_gettime, use clock_get_time
+#if defined(__MACH__) && defined(__APPLE__) // OS X does not have 
clock_gettime, use clock_get_time
 clock_serv_t cclock;
 mach_timespec_t ts;
 host_get_clock_service(mach_host_self(), CALENDAR_CLOCK, );
-- 
GitLab

Bug#976247: speech-dispatcher: conffiles not removed: /etc/speech-dispatcher/modules/ kali.conf ibmtts.conf baratinoo.conf

[Samuel Thibault]

Hello debian-dpkg,

I moved a configuration file kali.conf from the speech-dispatcher
package to the speech-dispatcher-kali package (as well as others, but
let's keep that example only).

The thing is: speech-dispatcher does not depend on
speech-dispatcher-kali (and cannot: the former is in main, the latter is
in contrib). It means that we either have

- a system with speech-dispatcher only, we want kali.conf to go away.

- a system with speech-dispatcher and speech-dispatcher-kali, we want to
  keep kali.conf and reassign it to speech-dispatcher-kali.

Using mv_conffile only in speech-dispatcher-kali does not remove
kali.conf in the first case. Using mv_conffile only in speech-dispatcher
leaves kali.conf.dpkg-new. Using rm_conffile in speech-dispatcher and
mv_conffile in speech-dispatcher-kali breaks: 

Removing obsolete conffile /etc/speech-dispatcher/modules/kali.conf ...
[...]
Preserving user changes to /etc/speech-dispatcher/modules/kali.conf (renamed 
from /etc/speech-dispatcher/modules/kali.conf)...
mv: cannot stat '/etc/speech-dispatcher/modules/kali.conf': No such file or 
directory

Do you have any other idea?

Samuel