Bug#991798: qtcreator: No suitable kits found

2021-08-01 Thread Ross Boylan
Package: qtcreator
Version: 4.14.1-1
Severity: important
Justification: Unable to use package

Dear Maintainer,

   * What led up to the situation?

   Install qtcreator and launch it.
   File | New File or Project
   Application (Qt Quick) | Qt Quick Application - Scroll
   Hit choose
   Enter location. Next.
   Accept defaults until get to Kit Selection
   
   It says "No suitable kits found" and the Next button is greyed out.
   Desktop appears as the only entry in the bottom panel, but it is
   greyed out and hovering over brings up a bubble saying at least one
   required feature is missing. The Qt Version shows as None in that bubble.

   Clicked on the options link (or the manage button for the desktop
   kit) shows Desktop listed under kits and nothing under Qt Versions.
   
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   The following steps were on buster with an earlier version.

   Attempted to set path to Qt.
   
   Checked the internet and installed the qt5-default.  This allowed
 me to select a Qt version.

   I then was able to create the project.  The build failed with a
   message "Unknown Modules in Qt: Quick".  There were lots of other
   error messages too.

   Installed additional qml-modules related to quick.  No change.
   
   reportbug suggested trying a later version before filing the bug,
   so I ran it on bullseye, leading to this report.

   In bullseye, in Kits | Qt Versions attempted to use link with Qt
   using /usr/lib/x86_64-linux-gnu/qt5/bin and several other
   variations; the Link with Qt button never activated.
   
   * What was the outcome of this action?

   Unable to get even a simple project to build.

   * What outcome did you expect instead?

   That I would be able to follow the instructions on Qt's site for
   "build your first Qt project" and they would work.
   
   Failing that, at least some guidance about what was necessary to
   make this thing work on Debian, e.g., a README.Debian file.


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 qtcreator depends on:
ii  clang-11   1:11.0.1-2
ii  libc6  2.31-13
ii  libclang1-11   1:11.0.1-2
ii  libdw1 0.183-1
ii  libelf10.183-1
ii  libgcc-s1  10.2.1-6
ii  libkf5syntaxhighlighting5  5.78.0-2
ii  libqt5concurrent5  5.15.2+dfsg-9
ii  libqt5core5a [qtbase-abi-5-15-2]   5.15.2+dfsg-9
ii  libqt5designer55.15.2-5
ii  libqt5designercomponents5  5.15.2-5
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5help55.15.2-5
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5printsupport55.15.2+dfsg-9
ii  libqt5qml5 [qtdeclarative-abi-5-15-2]  5.15.2+dfsg-6
ii  libqt5quick5   5.15.2+dfsg-6
ii  libqt5quickwidgets55.15.2+dfsg-6
ii  libqt5serialport5  5.15.2-2
ii  libqt5sql5 5.15.2+dfsg-9
ii  libqt5sql5-sqlite  5.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libqt5xml5 5.15.2+dfsg-9
ii  libstdc++6 10.2.1-6
ii  libyaml-cpp0.6 0.6.3-9
ii  libzstd1   1.4.8+dfsg-2.1
ii  qml-module-qtqml-models2   5.15.2+dfsg-6
ii  qml-module-qtquick-controls5.15.2-2
ii  qml-module-qtquick25.15.2+dfsg-6
ii  qtchooser  66-2
ii  qtcreator-data 4.14.1-1

Versions of packages qtcreator recommends:
ii  clang-tidy 1:11.0-51+nmu5
ii  gdb-minimal [gdb]  10.1-1.7
ii  konsole [x-terminal-emulator]  4:20.12.3-1
ii  make   4.3-4.1
ii  qmlscene   5.15.2+dfsg-6
ii  qt5-doc5.15.2-2
ii  qt5-qmltooling-plugins 5.15.2+dfsg-6
ii  qtbase5-dev-tools  5.15.2+dfsg-9
ii  qtcreator-doc  4.14.1-1
ii  qtdeclarative5-dev-tools   5.15.2+dfsg-6
ii  qttools5-dev-tools 5.15.2-5
ii  qttranslations5-l10n   5.15.2-2
ii  qtxmlpatterns5-dev-tools   5.15.2-3
ii  termit [x-terminal-emulator]   3.1-1
ii  xterm [x-terminal-emulator]366-1

Versions of packages qtcreator suggests:
ii  clazy   1.9-3
ii  cmake   

Bug#991797: openssh-client: UserKnownHostsFile default wrong

2021-08-01 Thread Frank-Michael Fischer

Package: openssh-client
Version: 1:8.4p1-5
Severity: important

Dear Maintainer,

The default setting of UserKnownHostsFile has changed in this version to:

~/.ssh/known_hosts.d/%k

But existing former versions have placed it in:

~/.ssh/known_hosts

This renders ssh connections impossible, unless I change it back to the 
former default by adding to ssh_config:


UserKnownHostsFile ~/.ssh/known_hosts ~/.ssh/known_hosts2

Regards,

FMF

-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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

Versions of packages openssh-client depends on:
ii  adduser   3.118
ii  dpkg  1.20.9
ii  libc6 2.31-13
ii  libedit2  3.1-20191231-2+b1
ii  libfido2-1    1.6.0-2
ii  libgssapi-krb5-2  1.18.3-6
ii  libselinux1   3.1-3
ii  libssl1.1 1.1.1k-1
ii  passwd    1:4.8.1-1
ii  zlib1g    1:1.2.11.dfsg-2

Versions of packages openssh-client recommends:
ii  xauth  1:1.1-1

Versions of packages openssh-client suggests:
pn  keychain  
pn  libpam-ssh    
pn  monkeysphere  
pn  ssh-askpass   

-- Configuration Files:
/etc/ssh/ssh_config changed:
Include /etc/ssh/ssh_config.d/*.conf
Host *
UserKnownHostsFile ~/.ssh/known_hosts ~/.ssh/known_hosts2
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes


-- no debconf information



Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

2021-08-01 Thread Franklin Yu
Hi Tim,

About your original request: I don’t think “/etc/zsh/zprofile.d” is going to
help. There is some distinction between x-profile and x-rc: profile are supposed
to be read only for the login shell, once (in every session). We put environment
variable there, for all the child processes to inherit. In contrast, x-rc files
should be read for all interactive invocation of shells; if I’m in an
interactive Zsh session, and I type “zsh”, this child shell reads the zshrc
again.

Whether we want to modify the path in zprofile or zshrc, depends on where you
want the change to take place. Generally I would update $PATH in
“/etc/profile.d/”, so that GUI applications like IDEs can find them (think of
PyCharm finding your Python); however, from your description, the users of your
package seem to expect the CLI tools to only be available in their interactive
shells (like Bash and Zsh). If that’s the case, then I think what you want is
actually “/etc/zsh/zshrc.d”. For example, I’m using GNOME Shell, and my terminal
emulators might are not creating “login shells” (because the actual login shell
is GNOME Shell in this case), so these Zsh sessions don’t read my “~/.zprofile”
at all.

Regards,
Franklin

Bug#989147: glibc: CVE-2021-33574: mq_notify does not handle separately allocated thread attributes

2021-08-01 Thread Liming Liu
Hi,
Anybody knows when will this be patched in buster (glibc 2.28)?

Thanks,
Liming

On Wed, 26 May 2021 21:57:12 +0200 Salvatore Bonaccorso 
mailto:car...@debian.org>> wrote:
> Source: glibc
> Version: 2.31-12
> Severity: important
> Tags: security upstream
> Forwarded: https://sourceware.org/bugzilla/show_bug.cgi?id=27896
> X-Debbugs-Cc: car...@debian.org, Debian Security 
> Team mailto:t...@security.debian.org>>
>
> Hi,
>
> The following vulnerability was published for glibc, basically purely
> to track the upstream issue and fix once coming downstream.
>
> CVE-2021-33574[0]:
> | The mq_notify function in the GNU C Library (aka glibc) through 2.33
> | has a use-after-free. It may use the notification thread attributes
> | object (passed through its struct sigevent parameter) after it has
> | been freed by the caller, leading to a denial of service (application
> | crash) or possibly unspecified other impact.
>
>
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2021-33574
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33574
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=27896
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore
>
>



Bug#991796: packagesearch: excessive line separation in package list

2021-08-01 Thread Ross Boylan
Package: packagesearch
Version: 2.7.11+b2
Severity: minor

Dear Maintainer,

The baseline separation between rows in the package list for
packagesearch in bullseye seems excessive.  Although I've tagged this
as minor, it affects the usability of the tool because it reduces the
number of packages visible in a single pane.

The baseline separation is greater than that between lines in the
description, which are shown on the right of the screen capture
attached.  The separation also seems greater than in buster.

bullseye and buster are both running under KDE; the bullseye machine
is virtual (KVM + virt-manager using the graphics virt-manager
provides).

I looked for settings that could control the separation, but found
none.

Thanks.
Ross

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/3 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 packagesearch depends on:
ii  apt   2.2.4
ii  apt-xapian-index  0.52
ii  debtags   2.1.5
ii  libapt-pkg6.0 2.2.4
ii  libc6 2.31-13
ii  libept1.6.0   1.2.1
ii  libgcc-s1 10.2.1-6
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5network55.15.2+dfsg-9
ii  libqt5widgets55.15.2+dfsg-9
ii  libqt5xml55.15.2+dfsg-9
ii  libstdc++610.2.1-6
ii  libxapian30   1.4.18-3
ii  xterm 366-1

Versions of packages packagesearch recommends:
ii  apt-file   3.2.2
ii  deborphan  1.7.33

packagesearch suggests no packages.

-- no debconf information


Bug#991795: gtk3-nocsd affecting Firefox right-clicking on links

2021-08-01 Thread Jay Mottern

Package: gtk3-nocsd
Version: 3-1
Severity: important

Dear Maintainer,

Steps to reproduce in Debian Bullseye with Xfce 4.16 and gtk3-nocsd:
Install Firefox 90.0.2
Open any web page
Right-click on a link
Expected behavior: a context menu with choices such as open link in new tab,
open link in new window, bookmark link location, etc.
Actual behavior: the link is automatically opened in a new browser window.

Steps to correct the issue:
apt purge gtk3-nocsd
Reboot
Firefox's right-click on links behavior is as expected.


-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not
set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gtk3-nocsd depends on:
ii libgtk3-nocsd0 3-1+b1

gtk3-nocsd recommends no packages.

gtk3-nocsd suggests no packages.



Bug#991788: xfce4-settings: black screen after suspend when laptop lid is closed and re-opened

2021-08-01 Thread truetechie
Package: xfce4-settings
Version: 4.16.0-1
Severity: critical

On Debian and, by extension, Ubuntu, when suspending a laptop via closing the 
lid on XFCE, the screen stays black after resuming from suspend. The only way 
to "fix" the system is to blindly type "xrandr --auto" into a terminal or 
switch to a TTY and restart X.

This issue can be easily fixed by disabling Upower support when the package is 
compiled. However, despite being set as default in 4.16, Debian seems to have 
it re-enabled. Removing "--enable-upower-glib" from the configure flags in the 
package instantly solves this issue.


Bug#991794: duperemove FTCBFS: uses the build architecture pkg-config

2021-08-01 Thread Helmut Grohne
Source: duperemove
Version: 0.11.2-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

duperemove fails to cross build from source, because the upstream
Makefile hard codes the build architecture pkg-config and thus fails
finding required libraries. Please consider applying the attached patch
to make it substitutable.

Helmut
--- duperemove-0.11.2.orig/Makefile
+++ duperemove-0.11.2/Makefile
@@ -2,6 +2,7 @@ VER=0.11.2
 RELEASE=v$(VER)
 
 CC ?= gcc
+PKG_CONFIG ?= pkg-config
 CFLAGS ?= -Wall -ggdb
 
 MANPAGES=duperemove.8 btrfs-extent-same.8 hashstats.8 show-shared-extents.8
@@ -41,10 +42,10 @@ csum_test_obj = $(hash_obj) util.o csum.
 install_progs = duperemove hashstats btrfs-extent-same show-shared-extents
 progs = $(install_progs) csum-test
 
-glib_CFLAGS=$(shell pkg-config --cflags glib-2.0)
-glib_LIBS=$(shell pkg-config --libs glib-2.0)
-sqlite_CFLAGS=$(shell pkg-config --cflags sqlite3)
-sqlite_LIBS=$(shell pkg-config --libs sqlite3)
+glib_CFLAGS=$(shell $(PKG_CONFIG) --cflags glib-2.0)
+glib_LIBS=$(shell $(PKG_CONFIG) --libs glib-2.0)
+sqlite_CFLAGS=$(shell $(PKG_CONFIG) --cflags sqlite3)
+sqlite_LIBS=$(shell $(PKG_CONFIG) --libs sqlite3)
 
 ifdef DEBUG
 	DEBUG_FLAGS = -ggdb3 -fsanitize=address -fno-omit-frame-pointer	-O0 \


Bug#991793: gnucobol4 FTCBFS: abuses AC_CHECK_FILE

2021-08-01 Thread Helmut Grohne
Source: gnucobol4
Version: 4.0~early~20200606-5
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

gnucobol4 fails to cross build from source, because it uses
AC_CHECK_FILE to test for file existence inside the source tree while
that macro is meant to test files on the host machine. Doing so makes
./configure fail in the absence of unreasonable cache variables. Please
consider applying the attached patch to fix that. The patch does not
make gnucobol4 cross buildable, because it also uses help2man.
Generation of manual pages using help2man is a difficult topic for cross
compilation with no obviously best solution. Therefore, this bug is only
about the AC_CHECK_FILE part.

Helmut
--- gnucobol4-4.0~early~20200606.orig/configure.ac
+++ gnucobol4-4.0~early~20200606/configure.ac
@@ -590,7 +590,7 @@
 	AC_MSG_NOTICE([Checks for local cJSON ...])
 	curr_libs="$LIBS"; curr_cppflags="$CPPFLAGS"
 	with_cjson_local=no
-	AC_CHECK_FILE([./libcob/cJSON.c],
+	AS_IF([test -e ./libcob/cJSON.c],
 	  [AC_MSG_CHECKING([if linking of ./libcob/cJSON.c works])
 	   CPPFLAGS="$curr_cppflags -I./libcob"
 	   AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include "cJSON.c"]],
@@ -601,7 +601,7 @@
 	   )]
 	)
 	if test "$with_cjson_local" = "no"; then
-	  AC_CHECK_FILE([$srcdir/libcob/cJSON.c],
+	  AS_IF([test -e "$srcdir/libcob/cJSON.c"],
 	[AC_MSG_CHECKING([if linking of $srcdir/libcob/cJSON.c works])
 	 CPPFLAGS="$curr_cppflags -I$srcdir/libcob"
 	 AC_LINK_IFELSE([AC_LANG_PROGRAM([[#include "cJSON.c"]],


Bug#991792: mirror submission for mirrors.nju.edu.cn

2021-08-01 Thread Yao Ge
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirrors.nju.edu.cn
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Yao Ge 
Country: CN China
Location: Nanjing
Sponsor: eScience Center, Nanjing University https://sci.nju.edu.cn




Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirrors.nju.edu.cn/debian/project/trace/mirrors.nju.edu.cn



Bug#991791: RFS: pynauty

2021-08-01 Thread Torrance, Douglas

I've recently packaged pynauty [1], which provides a Python interface to nauty
[2] for computing automorphism groups of graphs.

I'm a DM, but this package would be NEW, so I need a sponsor.  Would anyone be
willing to review?
https://salsa.debian.org/python-team/packages/pynauty

Thanks!
Doug

[1] https://github.com/pdobsan/pynauty
[2] https://pallini.di.uniroma1.it/


signature.asc
Description: PGP signature


Bug#960231: kubernetes: provision of 'kubeadm' command-line utility

2021-08-01 Thread James Addison
I had a feeling there was a good reason for this :)

Thank you!

On Sun, Aug 1, 2021, 22:04 Janos LENART  wrote:

> Hi,
>
> Absolutely. However, there are missing pieces for the puzzle (cni). This
> is in the pipeline.
>
> Janos
>
> On Sat, 31 Jul 2021, 19:36 James Addison,  wrote:
>
>> Hello - adding a small reminder/bump on this bug; it would be useful
>> to have the kubeadm command available as a package alongside the other
>> Kubernetes tools and binaries.  If there's an alternative plan for how
>> to provide that, please let me know - or I can refresh the patch soon.
>>
>> Thanks,
>> James
>>
>


Bug#991715: screen: zombie child

2021-08-01 Thread Vincent Lefevre
On 2021-08-02 02:45:58 +0200, Axel Beckert wrote:
> So I will start experimenting with the patches suggested by upstream
> in the upstream bug report again.

Also try the volatile as I suggested (and see if this leads to a
change of the generated code). Otherwise, the code seems correct;
well, unless I've missed something, at least it shouldn't leave
zombies (except if wait4 fails, but I wonder how this could occur).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#991791: ITP: pynauty -- isomorphism testing and automorphisms of graphs

2021-08-01 Thread Doug Torrance
Package: wnpp
Severity: wishlist
Owner: Doug Torrance 
X-Debbugs-Cc: debian-de...@lists.debian.org, dtorra...@piedmont.edu

* Package name: pynauty
  Version : 1.0.2
  Upstream Author : Peter Dobsan 
* URL : https://github.com/pdobsan/pynauty
* License : GPL
  Programming Lang: Python
  Description : isomorphism testing and automorphisms of graphs

Pynauty can be used to compare graphs for isomorphism and to
determine their automorphism group in a Python programming
environment. Pynauty is a Python/C extension module using library
components from the Nauty package by Brendan McKay.

I intend to maintain this package under the umbrella of the Debian
Python Team.



Bug#991790: bash: /etc/inputrc is not being loaded on ssh root sessions, home and end buttons won't work unles you run "bind -f /etc/inputrc", ~/.inputrc works

2021-08-01 Thread z3t4m4n
Package: bash
Version: 5.1-2+b2
Severity: minor
X-Debbugs-Cc: z3t4...@gmail.com

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   After upgrading to bullseye, ssh as root and found that home/end
   buttons do not work
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   edited ~/.inputrc to make them work as temporal solution
   * What was the outcome of this action?
   It solved the issue with home/end
   * What outcome did you expect instead?
   That home/end buttos worked as intende on root ssh sessions

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.11.22-3-pve (SMP w/1 CPU thread)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages bash depends on:
ii  base-files   11.1
ii  debianutils  4.11.2
ii  libc62.31-13
ii  libtinfo66.2+20201114-2

Versions of packages bash recommends:
ii  bash-completion  1:2.11-2

Versions of packages bash suggests:
pn  bash-doc  

-- no debconf information



Bug#991715: screen: zombie child

2021-08-01 Thread Axel Beckert
Control: forwarded -1 
https://savannah.gnu.org/bugs/?func=detailitem_id=25089

Hi Vincent,

Vincent Lefevre wrote:
> On 2021-08-01 22:46:57 +0200, Axel Beckert wrote:
> > I've seen this zsh zombies at least Buster, too. See
> > http://savannah.gnu.org/bugs/?func=detailitem_id=25089
> > 
> > Could your issue be related or even identical to the one above in the
> > upstream bug tracker? (I currently assume so, hence the "confirmed"
> > tag.)
> 
> There aren't many details, but this seems to be the same bug:

Thanks for confirming my gut feeling.

> > Unfortunately so far I wasn't able to reproduce this on demand.
> 
> Currently I can reproduce the bug all the time on this VM

Thanks for the detail that this also happens on a VM.

> when starting new screen sessions. Note: I haven't rebooted the VM
> yet (in case this is related to some kernel status).

Indeed, I just did one try with the .screenrc I built for testing this
bug (which more or less opens around 90 zsh screen windows. About 20
to 30 or so became zombies until I closed the last one.


> > And for some reason, so far this issue — if seen at all — has mostly
> > been seen when Screen runs on virtual machines. The reason for this is
> > though unclear, at least to me.
> 
> I would say that this could have an influence on the behavior in the
> case of a race condition.
[...]
> I'm wondering whether the issue is due to what happens with the clone.
> I suspect that there is a wait4 that catches this clone, but not the
> terminated shell process, hence the corresponding zombie.

Thanks for your analysis. One more analysis pointing towards a race
condition and/or a logical error

> > Vincent Lefevre wrote:
> > > It seems more or less reproducbile:
> > 
> > That would be good news!
[…]
> > Would you mind providing that .screenrc-mutt?
> 
> This doens't matter: the problem is reproducible with a normal
> "screen", even if I remove the .screenrc file.
> 
> > And now easy or how long does it take until zombies appear?
> 
> I don't understand what you mean:

Typo: s/now/how/

> as soon as I quit a shell running from a screen window, I get a
> zombie (same PID).

Yep, already got that from the remainder of this reply of yours.

But nevertheless it made me trying this again and indeed, I was
immediately able to reproduce it (already rebooted into 4.19.194-3).
So something indeed seems to have worsened the situation.

So I will start experimenting with the patches suggested by upstream
in the upstream bug report again.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#991715: screen: zombie child

2021-08-01 Thread Vincent Lefevre
Control: tags -1 - moreinfo

Hi Axel,

On 2021-08-01 22:46:57 +0200, Axel Beckert wrote:
> I've seen this zsh zombies at least Buster, too. See
> http://savannah.gnu.org/bugs/?func=detailitem_id=25089
> 
> Could your issue be related or even identical to the one above in the
> upstream bug tracker? (I currently assume so, hence the "confirmed"
> tag.)

There aren't many details, but this seems to be the same bug:

"Maybe also worth to note is that these zombies process are not just
there for a few minutes and then get cleaned up. Most of them (but not
all) stay for at least days, if not until I exit the screen session."

which is more or less what I observe (I confirm the "Most of them (but
not all)").

> Unfortunately so far I wasn't able to reproduce this on demand.

Currently I can reproduce the bug all the time on this VM when
starting new screen sessions. Note: I haven't rebooted the VM yet
(in case this is related to some kernel status).

> And for some reason, so far this issue — if seen at all — has mostly
> been seen when Screen runs on virtual machines. The reason for this is
> though unclear, at least to me.

I would say that this could have an influence on the behavior in the
case of a race condition.

Comment #12 says: "The reason for this is that in the C language only
some very narrow set of library functions can be invoked from the
signal handler"

However, the signal handler in screen.c is named SigChld and does

static sigret_t SigChld SIGDEFARG
{
  debug("SigChld()\n");
  GotSigChld = 1;
  SIGRETURN;
}

which is OK (the function named SigChldHandler is actually the
callback function, not the signal handler), possibly except the
"debug" (but I don't think it does anything without debugging).

Note that GotSigChld is declared as

static int GotSigChld;

which is incorrect, AFAIK. It must be declared as volatile.
Without that, there is a risk that the loop

  while (GotSigChld) {
GotSigChld = 0;
DoWait();
#ifdef SYSVSIGS
signal(SIGCHLD, SigChld);
#endif
  }

be transformed into an "if" (itself transformed into a true condition,
due to the context, but this second transformation doesn't matter).

Now, if I understand correctly, the loop would matter only if two
SIGCHLD are received in a short time, which probably doesn't occur
in my case. Well... actually it does. See below.

I've tried to see what happens with "strace -p PID" on the SCREEN
process, but that's rather useless: While I don't use strace, I get
zombies, but as soon as I use strace and quit the shell with Ctrl-D,
all the zombies disappear. This could confirm that the cause is a
race condition, as strace slows things down.

In case this is useful, here's the strace output with 5 zombies, then
strace -p PID, then quit the shell in the current screen window, then
interrupted strace:

select(1024, [3 4 5 6], [], NULL, {tv_sec=58, tv_usec=982211}) = 1 (in [3], 
left {tv_sec=47, tv_usec=980823})
read(3, "\4", 4096) = 1
gettimeofday({tv_sec=1627860672, tv_usec=147052}, NULL) = 0
select(1024, [3 4 5 6], [6], NULL, {tv_sec=47, tv_usec=952948}) = 1 (out [6], 
left {tv_sec=47, tv_usec=952939})
write(6, "\4", 1)   = 1
gettimeofday({tv_sec=1627860672, tv_usec=163469}, NULL) = 0
select(1024, [3 4 5 6], [], NULL, {tv_sec=47, tv_usec=936531}) = 1 (in [6], 
left {tv_sec=47, tv_usec=936522})
read(6, "\0\33[?2004l\r\r\n", 4096) = 12
gettimeofday({tv_sec=1627860672, tv_usec=174073}, NULL) = 0
select(1024, [3 4 5 6], [3], NULL, {tv_sec=47, tv_usec=925927}) = 1 (out [3], 
left {tv_sec=47, tv_usec=925919})
write(3, "\r\n", 2) = 2
gettimeofday({tv_sec=1627860672, tv_usec=184401}, NULL) = 0
select(1024, [3 4 5 6], [], NULL, {tv_sec=47, tv_usec=915599}) = 1 (in [6], 
left {tv_sec=47, tv_usec=740073})
read(6, "\0\33[96mzlogout r139201\33(B\33[m\r\n", 4096) = 29
gettimeofday({tv_sec=1627860672, tv_usec=373145}, NULL) = 0
select(1024, [3 4 5 6], [3], NULL, {tv_sec=47, tv_usec=726855}) = 1 (out [3], 
left {tv_sec=47, tv_usec=726846})
write(3, "\33[27m\33[36m\33[49m\33[96mzlogout r139"..., 42) = 42
gettimeofday({tv_sec=1627860672, tv_usec=385146}, NULL) = 0
select(1024, [3 4 5 6], [], NULL, {tv_sec=47, tv_usec=714854}) = 1 (in [6], 
left {tv_sec=47, tv_usec=704494})
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=25280, si_uid=1000, 
si_status=0, si_utime=12, si_stime=7} ---
rt_sigreturn({mask=[]}) = 1
read(6, 0x7fff26608bc0, 4096)   = -1 EIO (Input/output error)
wait4(25280, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WSTOPPED, NULL) = 
25280
ioctl(3, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B38400 opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B38400 opost -isig -icanon -echo ...}) = 0
gettimeofday({tv_sec=1627860672, tv_usec=423366}, NULL) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2971, ...}) = 0
gettimeofday({tv_sec=1627860672, tv_usec=430229}, NULL) = 0

Bug#991789: gnome: Suspend activates in multi-seat environment when only one seat is active

2021-08-01 Thread Joshua Brickel
Package: gnome
Version: 1:3.38+3
Severity: important
X-Debbugs-Cc: joshua.bric...@gmail.com

I have a two seat multi-seat setup.  When one seat is active and the other
is not (under GDM control), then after about twenty minutes the computer
goes into suspend mode, even in the middle of typing a sentence on the
active seat.

The system was not doing this till a software update came through about a
week ago.  Hence why I think this is a gnome issue, and probably a GDM
issue.

Note this happens even though on the active seat I set the under
settings->Power->Automatic
Suspend to OFF.




-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/48 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 gnome depends on:
ii  avahi-daemon 0.8-5
ii  cheese   3.38.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  desktop-base 11.0.3
ii  evolution3.38.3-1
ii  evolution-plugins3.38.3-1
ii  file-roller  3.38.1-1
ii  gedit-plugins3.38.1-1
ii  gnome-calendar   3.38.2-1
ii  gnome-clocks 3.38.0-1
ii  gnome-color-manager  3.36.0-1
ii  gnome-core   1:3.38+3
ii  gnome-documents  3.34.0-2
ii  gnome-getting-started-docs   3.38.0-1
ii  gnome-maps   3.38.2-1
ii  gnome-music  3.36.7-1
ii  gnome-screenshot 3.38.0-1
ii  gnome-sound-recorder 3.38.1-1
ii  gnome-todo   3.28.1-6
ii  gnome-tweaks 3.34.0-4
ii  gnome-weather3.36.1-1
ii  gstreamer1.0-libav   1.18.4-3
ii  gstreamer1.0-plugins-ugly1.18.4-2
ii  libgsf-bin   1.14.47-1
ii  libproxy1-plugin-networkmanager  0.4.17-1
ii  libreoffice-calc 1:7.0.4-4
ii  libreoffice-gnome1:7.0.4-4
ii  libreoffice-impress  1:7.0.4-4
ii  libreoffice-writer   1:7.0.4-4
ii  network-manager-gnome1.20.0-3
ii  orca 3.38.2-1
ii  rhythmbox3.4.4-4
ii  rhythmbox-plugin-cdrecorder  3.4.4-4
ii  rhythmbox-plugins3.4.4-4
ii  rygel-playbin0.40.0-1
ii  rygel-tracker0.40.0-1
ii  seahorse 3.38.0.1-2
ii  shotwell 0.30.11-1
ii  simple-scan  3.38.1-1
ii  totem-plugins3.38.0-2
ii  xdg-user-dirs-gtk0.10-3

Versions of packages gnome recommends:
ii  gnome-games 1:3.38+3
ii  gnome-remote-desktop0.1.9-5
ii  nautilus-extension-brasero  3.12.2-6
ii  transmission-gtk3.00-1

Versions of packages gnome suggests:
pn  alacarte 
pn  empathy  
pn  firefox-esr-l10n-all | firefox-l10n-all  
pn  goobox | sound-juicer
pn  polari   
ii  vinagre  3.22.0-8.1
pn  webext-ublock-origin 

Versions of packages gnome-core depends on:
ii  adwaita-icon-theme3.38.0-1
ii  at-spi2-core  2.38.0-4
ii  baobab3.38.0-1
ii  caribou   0.4.21-7.1
ii  dconf-cli 0.38.0-2
ii  dconf-gsettings-backend   0.38.0-2
ii  eog   3.38.2-1
ii  evince3.38.2-1
ii  evolution-data-server 3.38.3-1
ii  firefox-esr   78.12.0esr-1
ii  fonts-cantarell   0.111-3
ii  gdm3  3.38.2.1-1
ii  gedit 3.38.1-1
ii  gkbd-capplet  3.26.1-1
ii  glib-networking   2.66.0-2
ii  gnome-backgrounds 3.38.0-1
ii  gnome-bluetooth   3.34.3-2
ii  gnome-calculator  3.38.2-1
ii  gnome-characters  3.34.0-1
ii  gnome-contacts3.38.1-1+b1
ii  gnome-control-center  1:3.38.4-1
ii  gnome-disk-utility3.38.2-1
ii  gnome-font-viewer 3.34.0-2+b1
ii  gnome-keyring 3.36.0-1
ii  gnome-logs3.36.0-2
ii  gnome-menus   3.36.0-1
ii  gnome-online-accounts 3.38.0-3
ii  gnome-online-miners   3.34.0-2
ii  gnome-session 3.38.0-4
ii  gnome-settings-daemon 3.38.2-1
ii  gnome-shell   3.38.4-1
ii  gnome-shell-extensions3.38.2-1
ii  gnome-software3.38.1-1
ii  gnome-sushi   

Bug#776663: zsh-common: Wish for /etc/zsh/zprofile.d or equivalent

2021-08-01 Thread Franklin Yu
Hello Frank,

> With respect to shells, I usually find that applications, that need to
> inject code into a user's shell to be by and large mis-designed.
>
> Something that *might* make sense is to source stuff from /etc/profile
> and “/etc/profile.d/” in POSIX-mode. See ¹, a mail about that from 2011.
> Nobody cared enough to reply; which I guess that tells you something
> about the urgency of the situation. ;-)
>
> [1]: 
> http://lists.alioth.debian.org/pipermail/pkg-zsh-devel/2011-October/000248.html

I’d like to vote for exactly that; sourcing “/etc/profile” in POSIX-mode seems
very valid. This file currently seems POSIX without Bashism, and I propose to
keep it POSIX.

> But like the mails says, even if we did that, it's hard to decide what
> because it's not used for portable purposes alone. The bash completion
> thing is sourced from there, which other POSIX shells will have a major
> problem with.

I’m not familiar with other shells, but I don’t think Zsh in POSIX mode provides
the “$BASH” variable, so the Bash guard in “/etc/profile” should prevent it from
breaking Zsh.

Regards,
Franklin

Bug#889072:

2021-08-01 Thread Dhdh Durh
Bb


Bug#886927: ITP: tlog -- Terminal I/O recording and playback package.

2021-08-01 Thread Justin St. Marie
Hi Markus,

Have you gained any traction packaging tlog?  This package would be very
helpful to me.

Best,
Justin


Bug#991787: unblock: ucspi-unix/1.0-2

2021-08-01 Thread Peter Pentchev
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: r...@debian.org

This is a pre-approval request before I upload ucspi-unix to
unstable to fix a FTBFS on architectures where dietlibc is
not built; see #991774.

[ Reason ]
See #991774 for more details: the way ucspi-unix runs the upstream build
twice is not fully conditional on the presence of the dietlibc build
helpers.

[ Impact ]
The ucspi-unix package is not built at all on architectures that
dietlibc does not support, thus Debian users are currently missing
the ucspi-unix functionality for these architectures.

[ Tests ]
None; it does not currently build at all.

[ Risks ]
Leaf package, not widely used. The risk that exposing Debian users to
the functionality of ucspi-unix would do them harm is, IMHO, negligible.

[ 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

[ Other info ]
I based my fix on Dmitry Bogatov's already existing Salsa repository for
ucspi-unix. There was already a Salsa-specific commit there that is not
directly related to this bugfix, but does not affect the package at all.
Still, if you'd prefer me to prepare a new, bullseye-specific branch
that will only include this fix and not the Salsa CI definition, let me
know.

unblock ucspi-unix/1.0-2
diff -Nru ucspi-unix-1.0/debian/changelog ucspi-unix-1.0/debian/changelog
--- ucspi-unix-1.0/debian/changelog 2018-11-28 06:26:16.0 +0200
+++ ucspi-unix-1.0/debian/changelog 2021-08-02 01:36:27.0 +0300
@@ -1,3 +1,14 @@
+ucspi-unix (1.0-2) unstable; urgency=medium
+
+  [ Dmitry Bogatov ]
+  * Add a Gitlab CI config file.
+
+  [ Peter Pentchev ]
+  * New maintainer. Closes: #983804
+  * Only run the dietlibc build if possible. Closes: #991774
+
+ -- Peter Pentchev   Mon, 02 Aug 2021 01:36:27 +0300
+
 ucspi-unix (1.0-1) unstable; urgency=medium
 
   * New maintainer (Closes: #907084)
diff -Nru ucspi-unix-1.0/debian/control ucspi-unix-1.0/debian/control
--- ucspi-unix-1.0/debian/control   2018-11-28 06:26:16.0 +0200
+++ ucspi-unix-1.0/debian/control   2021-08-02 00:59:30.0 +0300
@@ -1,7 +1,7 @@
 Source: ucspi-unix
 Section: net
 Priority: optional
-Maintainer: Dmitry Bogatov 
+Maintainer: Peter Pentchev 
 Build-Depends:
  debhelper-compat (= 11),
  dh-buildinfo (>= 0.11+nmu1),
diff -Nru ucspi-unix-1.0/debian/.gitlab-ci.yml 
ucspi-unix-1.0/debian/.gitlab-ci.yml
--- ucspi-unix-1.0/debian/.gitlab-ci.yml1970-01-01 02:00:00.0 
+0200
+++ ucspi-unix-1.0/debian/.gitlab-ci.yml2021-08-02 00:57:09.0 
+0300
@@ -0,0 +1,5 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+variables:
+  RELEASE: experimental
diff -Nru ucspi-unix-1.0/debian/rules ucspi-unix-1.0/debian/rules
--- ucspi-unix-1.0/debian/rules 2018-11-28 06:26:16.0 +0200
+++ ucspi-unix-1.0/debian/rules 2021-08-02 00:59:38.0 +0300
@@ -41,7 +41,9 @@
echo 'diet gcc $(LDFLAGS)' > diet/conf-ld
 
 override_dh_auto_build:
+ifeq (${HAVE_DIETLIBC},yes)
$(MAKE) -C diet
+endif
$(MAKE) -C glibc
 
 override_dh_auto_install:


signature.asc
Description: PGP signature


Bug#991774: ucspi-unix FTBFS on architectures without dietlibc

2021-08-01 Thread Peter Pentchev
control: owner -1 !
control: tag -1 + confirmed patch pending

On Sun, Aug 01, 2021 at 05:47:49PM +0300, Adrian Bunk wrote:
> Source: ucspi-unix
> Version: 1.0-1
> Severity: important
> Tags: ftbfs
> 
> https://buildd.debian.org/status/package.php?p=ucspi-unix=sid
> 
> ...
> chmod 755 compile
> ./compile unixclient.c
> ./compile: 4: exec: diet: not found
> make[2]: *** [Makefile:74: unixclient.o] Error 127
> 
> 
> This should either be fixed properly, or the build dependency
> on dietlibc-dev should become unconditional to avoid expected
> build failures.

Thanks for the report and for all your work on Debian. I think I have a
fix for this problem - see the attached patch, a.k.a.:

  
https://salsa.debian.org/debian/ucspi-unix/-/commit/6b39b6e8e4bbccecb140d5bd1519a1c57110a141

I will contact the release team to ask for a pre-approval, just in case
they decide that this is worth doing during the freeze.

Thanks again, and keep up the great work!

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@debian.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
commit 6b39b6e8e4bbccecb140d5bd1519a1c57110a141
Author: Peter Pentchev 
Date:   Mon Aug 2 00:51:53 2021 +0300

Only run the dietlibc build if possible.

Closes: #991774
Reported by: Adrian Bunk 

diff --git a/debian/rules b/debian/rules
index 013eb22..747e13b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -41,7 +41,9 @@ override_dh_auto_configure:
echo 'diet gcc $(LDFLAGS)' > diet/conf-ld
 
 override_dh_auto_build:
+ifeq (${HAVE_DIETLIBC},yes)
$(MAKE) -C diet
+endif
$(MAKE) -C glibc
 
 override_dh_auto_install:


signature.asc
Description: PGP signature


Bug#991779: ITP: ruby-semantic-range -- node-semver rewritten in Ruby

2021-08-01 Thread Sruthi Chandran
Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: ruby-semantic-range
  Version : 3.0.0
  Upstream Author : 2016 Andrew Nesbitt
* URL : https://libraries.io/github/librariesio/semantic_range
* License : Expat
  Description : This gem is node-semver rewritten in Ruby for
comparison and inclusion of  semantic versions and ranges



Bug#991786: ITP: python-billard -- fork of the Python 2.7 multiprocessing package

2021-08-01 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: python-billard -- fork of the Python 2.7 multiprocessing package
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-billard
  Version : 3.6.4.0
  Upstream Author : , R Oudkerk and Contributors
* URL : https://github.com/celery/billiard
* License : License: 
  Programming Lang: Python
  Description : fork of the Python 2.7 multiprocessing package
 The multiprocessing package billard is a renamed and updated version
 of R Oudkerk's pyprocessing package. This standalone variant draws its
 fixes/improvements from python-trunk and provides additional bug fixes
 and improvements.
 .
 Also, it is a fork of the multiprocessing backport package by Christian
 Heims.  It includes the no-execv patch contributed by R. Oudkerk.
 And the Pool improvements previously located in Celery.  Billiard is used
 in and is a dependency for Celery and is maintained by the Celery team.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/python-team/packages/python-billard



Bug#960231: kubernetes: provision of 'kubeadm' command-line utility

2021-08-01 Thread Janos LENART
Hi,

Absolutely. However, there are missing pieces for the puzzle (cni). This is
in the pipeline.

Janos

On Sat, 31 Jul 2021, 19:36 James Addison,  wrote:

> Hello - adding a small reminder/bump on this bug; it would be useful
> to have the kubeadm command available as a package alongside the other
> Kubernetes tools and binaries.  If there's an alternative plan for how
> to provide that, please let me know - or I can refresh the patch soon.
>
> Thanks,
> James
>


Bug#991715: screen: zombie child

2021-08-01 Thread Axel Beckert
Control: tag -1 + confirmed moreinfo

Hi Vincent,

thanks for the bug report.

Vincent Lefevre wrote:
> I had a screen window with a shell (zsh) and quit the shell. The
> window was closed as expected, but after 20 minutes, there is still
> a zombie child:

I've seen this zsh zombies at least Buster, too. See
http://savannah.gnu.org/bugs/?func=detailitem_id=25089

Could your issue be related or even identical to the one above in the
upstream bug tracker? (I currently assume so, hence the "confirmed"
tag.)

Unfortunately so far I wasn't able to reproduce this on demand.

And for some reason, so far this issue — if seen at all — has mostly
been seen when Screen runs on virtual machines. The reason for this is
though unclear, at least to me.

And so it is also with my case: The only host, where I run into this
issue over and over again (but always never immediately after starting
Screen or trying to reproduce it) was on a virtual machine running on
a VMware ESX server.

There are also a few proposed patches, but some got revoked again due
to other issues. Unfortunately one of these revoked patches worked for
my casae quite well. Haven't tried the most recent patch yet, though.

I can dig up details if you wantto try that patch.

Vincent Lefevre wrote:
> It seems more or less reproducbile:

That would be good news!

> 21983  SCREEN -c d_joooj/home/vinc17/.screenrc-mutt -T screen-256color-bce-s 
> -dR

Would you mind providing that .screenrc-mutt? And now easy or how long
does it take until zombies appear? (Feel free to remove the "moreinfo"
tag when replying to these questions.)

> But it may happen that zombies disappear.

That's what I noticed, too, but it can take days, maybe weeks.

Vincent Lefevre wrote:
> As I don't remember having such an issue in the past, a possible cause
> might have been one of the following recent upgrades:
> 
> krb5 1.17-3+deb10u1 → 1.17-3+deb10u2
> linux-signed-amd64 4.19.194-2 → 4.19.194-3
> systemd 241-7~deb10u7 → 241-7~deb10u8

If it's the same issue as #25089 in the upstream bug tracker, it's
rather old and shows up seldomly, but for years already. I though can
imagine that some of the updates caused it to happen more often. Then
again, I didn't notice it so far. And I do monitor most of my boxes
for zombie processes.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#985775: [Pkg-rust-maintainers] Bug#985775: git-absorb: Git does not recognize absorb as a git command

2021-08-01 Thread Tomas Janousek

Hi,

On Wed, Mar 24, 2021 at 02:51:20AM +, peter green wrote:

Git changed the gitexecdir directory. Said change is currently blocked from
migrating to testing by bug 985416 which was cloned from bug 985351, ongoing
discussion of the issue seems to be in bug 985351.

Given where we are in the release process, that there still seems to be ongoing
discussion on the git side as to how best to deal with this issue and that this
doesn't currently affect bullseye, I think we should probably wait for a direct
request from the git maintainers before changing anything on the git-absorb 
side.


I'll just note that the current state in Debian testing is that "git 
absorb" works but git's bash completion doesn't suggest absorb. It does 
suggest every git-something in $PATH, but stuff in /usr/lib/git-core 
seems to be handled specially (see for example 
https://github.com/git/git/commit/6532f3740b1c228c0a2a03a4126f4f7e4f2d73e7: 
apparently the commands in git-core are categorized and one can 
configure which categories of commands should be autocompleted).


I believe this is another argument for installing git-absorb into 
/usr/bin.


--
Tomáš "liskin" ("Pivník") Janoušek, https://work.lisk.in/


Bug#138691: zsh: completion for man should find filenames as well as man pages

2021-08-01 Thread Vincent Lefevre
As this very old bug is still open...

On 2002-03-18 11:45:08 -0500, Matt Zimmerman wrote:
> On Mon, Mar 18, 2002 at 11:06:15AM -0500, Clint Adams wrote:
> 
> > > When the -l option is given, man will open and display a man page
> > > specified as a pathname (and not search manpath).  At least with
> > > Debian's man, this also works if -l is not specified, though manpath is
> > > searched first.
> > 
> > This doesn't work for me with man-db 2.3.20-15.  What am I doing wrong?
> 
> The fallback only seems to work if there is a '/' character in the argument:
> 
> poseidon:[~] ls man.1
> man.1
> poseidon:[~] man man.1
> No manual entry for man.1
> zsh: exit 16man man.1
> poseidon:[~] man -l man.1
> Reformatting man.1, please wait...
> poseidon:[~] man ./man.1
> Reformatting man.1, please wait...
> poseidon:[~] 

With zsh 5.8-6+b2 on my machine, completion works as expected if there
is a "/" character:

zira:~> man ./ma[Tab]

gives

zira:~> man ./man.1

Completion also works with -l, but also proposes files that are not
man pages. I don't know whether such a difference is expected.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)



Bug#991784: kuvert FTCBFS: builds for the build architecture

2021-08-01 Thread Alexander Zangerl
On Sun, 01 Aug 2021 20:30:37 +0200, Helmut Grohne writes:
>kuvert fails to cross build from source, because it does not pass cross
>tools to make. The easiest way of doing so - using dh_auto_build - makes
>kuvert cross buildable. Please consider applying the attached patch.

thanks for the note, i'll take care of this within a day or two.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"One World, One Web, One Program" - Microsoft Promotional Ad
"Ein Volk, Ein Reich, Ein Führer" - Adolf Hitler


signature.asc
Description: Digital Signature


Bug#987441: s390x installation bugs

2021-08-01 Thread Valentin Vidic
On Sun, Aug 01, 2021 at 05:10:07PM +0200, Cyril Brulebois wrote:
> Valentin Vidic  (2021-08-01):
> > No problem, I was not able to reproduce this reliably or get a core
> > dump for this crash. It could just be an emulation problem with qemu
> > or some timing issue for the first installer step. If there is no
> > update on this problem I think we can even close it for now.
> 
> Speaking of the first step, did anyone mention #987368 before, now fixed
> in udpkg?

Thanks, that does sound similar to what I was getting there. I will try
to see if it still happens with the latest installer. And since it
crashes on start I had no way to access the logs or dmesg of the
machine. Perhaps there is some installer option to help debug this kind
of thing?

-- 
Valentin



Bug#991738: unblock: gdcm/3.0.8-2 (pre-approval)

2021-08-01 Thread Étienne Mollier
Control: tags -1 - moreinfo

Hi Graham,

Graham Inggs, on 2021-08-01:
> Please go ahead and upload to unstable, then remove the moreinfo tag
> once it has built.

gdcm has built against all release architectures [1].  The only
missing build is against the experimental hurd-i386.

[1]: https://buildd.debian.org/status/package.php?p=gdcm

Thank you for the green light!

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/2, please excuse my verbosity.


signature.asc
Description: PGP signature


Bug#991712: Submitted a but on the kernel's bugzilla

2021-08-01 Thread Julien Wajsberg
Hey,

I filed https://bugzilla.kernel.org/show_bug.cgi?id=213939 on the kernel's
bugzilla about this.

Cheers,
-- 
Julien


Bug#901332: d-i: Offer to shut down / power off instead of reboot at the end

2021-08-01 Thread Thorsten Glaser
Hi Phil,

>BTW one can preseed this behaviour with 'debian-installer/exit/halt' or
>'debian-installer/exit/poweroff' as mentioned here:
>
>  https://www.debian.org/releases/stable/amd64/apbs04.en.html#preseed-finish

oh, good to know.

>which means that you could specify such a setting on the kernel command
>line when starting debian-installer to get the behaviour you want.

I’m not versed in preseeding… so that means I have to write
debian-installer/exit/poweroff=true to the kernel commandline?

Wow, quite a handful to type (but on the plus side, it can be
added to netboot menus right now, no further change needed, so
it solves half the problem ☺).

Thanks,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)



Bug#991785: Debdiff (Was: Bug#991785: Acknowledgement (unblock: debian-science/1.14.2))

2021-08-01 Thread Andreas Tille
Sorry, I forgot to attach the debdiff that was promised...


-- 
http://fam-tille.de
diff -Nru debian-science-1.14.1/debian/changelog debian-science-1.14.2/debian/changelog
--- debian-science-1.14.1/debian/changelog	2021-03-09 06:29:09.0 +0100
+++ debian-science-1.14.2/debian/changelog	2021-05-10 15:27:28.0 +0200
@@ -1,3 +1,23 @@
+debian-science (1.14.2) unstable; urgency=medium
+
+  * Re-render metapackages according the package pool in bullseye
+
+  * start of automatic changelog entry * 
+  
+  * Changes in metapackage dependencies
+   -science-dataacquisition-dev
+added:
+  Recommends:  libopenrefine-vicino-java, libopenrefine-arithcode-java
+   -science-simulations
+added:
+  Recommends:  pysph-viewer
+   -science-workflow
+added:
+  Recommends:  python3-nipype, python3-wdlparse
+  Suggests:  cwlformat
+
+ -- Andreas Tille   Mon, 10 May 2021 15:27:28 +0200
+
 debian-science (1.14.1) unstable; urgency=medium
 
   * Source-only upload
diff -Nru debian-science-1.14.1/debian/control debian-science-1.14.2/debian/control
--- debian-science-1.14.1/debian/control	2021-03-09 06:29:09.0 +0100
+++ debian-science-1.14.2/debian/control	2021-05-10 15:27:28.0 +0200
@@ -230,7 +230,8 @@
 tandem-mass,
 v-sim,
 xbs,
-xdrawchem
+xdrawchem,
+xmakemol-gl | xmakemol
 Suggests: bkchem,
   fdmnes,
   gcu-plugin,
@@ -246,8 +247,7 @@
   python-pymzml-doc,
   python3-periodictable,
   tinker,
-  viewmol,
-  xmakemol-gl | xmakemol
+  viewmol
 Description: Debian Science Chemistry packages
  This metapackage will install Debian Science packages related to
  Chemistry.  You might also be interested in the field::chemistry
@@ -317,12 +317,14 @@
 python3-aws-xray-sdk,
 python3-csvkit,
 python3-guidata,
-python3-intake,
 python3-pygetdata,
 python3-pymeasure,
 python3-segyio,
 python3-xrayutilities
 Suggests: libnarval1-dev,
+  libopenrefine-arithcode-java,
+  libopenrefine-vicino-java,
+  python3-intake,
   r-cran-mi,
   r-cran-ncdf4
 Description: Debian Science data acquisition development packages
@@ -351,6 +353,10 @@
  science-config (= ${source:Version}),
  science-tasks (= ${source:Version})
 Recommends: environment-modules,
+gridengine-client,
+gridengine-exec,
+gridengine-master,
+gridengine-qmon,
 ipython3,
 mpich,
 openmpi-bin,
@@ -358,10 +364,6 @@
 Suggests: coop-computing-tools,
   dmtcp,
   globus-core,
-  gridengine-client,
-  gridengine-exec,
-  gridengine-master,
-  gridengine-qmon,
   hpcc,
   htcondor,
   mpich2python,
@@ -1811,7 +1813,6 @@
 libccp4-dev,
 libcexceptions-dev,
 libclipper-dev,
-libcod-precision-perl,
 libetsf-io-dev,
 libetsf-io-doc,
 libfftw3-dev,
@@ -1843,6 +1844,7 @@
   gsl-doc-pdf,
   gsl-ref-html | gsl-ref-psdoc,
   libcblas-dev,
+  libcod-precision-perl,
   libfeel++-dev,
   libfftw3-doc,
   libpspio-dev,
@@ -1964,7 +1966,6 @@
 coinor-symphony,
 esys-particle,
 gnudatalanguage,
-iep,
 ipython3,
 julia,
 lammps,
@@ -2017,6 +2018,7 @@
   freemat,
   geneva,
   hpcc,
+  iep,
   libarrayfire-unified-dev,
   libcblas-dev,
   libclblas-dev,
@@ -2749,6 +2751,8 @@
 gearman,
 gearman-tools,
 make,
+python3-nipype,
+python3-wdlparse,
 snakemake,
 toil
 Suggests: cwlformat,
diff -Nru debian-science-1.14.1/dependency_data/debian-science_1.14.1.json debian-science-1.14.2/dependency_data/debian-science_1.14.1.json
--- debian-science-1.14.1/dependency_data/debian-science_1.14.1.json	1970-01-01 01:00:00.0 +0100
+++ debian-science-1.14.2/dependency_data/debian-science_1.14.1.json	2021-05-10 15:27:28.0 +0200
@@ -0,0 +1 @@
+{"neuroscience-datasets": {"depends": [], "suggests": [], "recommends": ["mni-icbm152-nlin-2009", "mni-colin27-nifti", "haxby2001-faceobject", "fsl-harvard-oxford-atlases", "fsl-juelich-histological-atlas", "fsl-jhu-dti-whitematter-atlas", "fsl-mni-structural-atlas", "fsl-talairach-daemon-atlas", "fsl-oxford-thalamic-connectivity-atlas", "fsl-bangor-cerebellar-atlas", "mclaren-rhesus-macaque-atlas", "sri24-atlas"], "ignore": [], "avoid": []}, "distributedcomputing": {"depends": [], "suggests": ["hpcc", "coop-computing-tools", "python3-mpi4py", "psom", "octave-mpi"], "recommends": ["ipython3", "nordugrid-arc-nox", 

Bug#991785: unblock: debian-science/1.14.2

2021-08-01 Thread Andreas Tille
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: Nilesh Patra , Ole Streicher 
, Debian Science Team 


Please unblock package debian-science

[ Reason ]
Blends metapackages need to be refreshed at end of freeze to
reflect the status of the package pool after removal of RC
buggy packages.  That's why the debian-science metapackages
need to be refreshed.

[ Impact ]
Some removed packages would be recommended in science
metapackages.

[ Tests ]
There are not tests for those metapackages.

[ Risks ]
I do not see any risks that could occure by the package
upgrade.

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [ ] I reviewed all changes and I approve them
  I did NOT reviewed the changes actually since I
  trust the Blends framework to do a proper job
  upgrading the packages.
  [x] attach debdiff against the package in testing

[ Other info ]
Usually the Blends update is done in the last days of
every freeze period.  The package 1.14.2 is a bit older
now - it seems I forgot to file an unblock request (or
my submission failed for whatever reason.)

unblock debian-science/1.14.2



Bug#991784: kuvert FTCBFS: builds for the build architecture

2021-08-01 Thread Helmut Grohne
Source: kuvert
Version: 2.2.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kuvert fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
kuvert cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru kuvert-2.2.2/debian/changelog 
kuvert-2.2.2+nmu1/debian/changelog
--- kuvert-2.2.2/debian/changelog   2017-10-28 03:39:51.0 +0200
+++ kuvert-2.2.2+nmu1/debian/changelog  2021-08-01 20:26:02.0 +0200
@@ -1,3 +1,10 @@
+kuvert (2.2.2+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 01 Aug 2021 20:26:02 +0200
+
 kuvert (2.2.2) unstable; urgency=medium
 
   * kill/reload code now runs earlier, which makes
diff --minimal -Nru kuvert-2.2.2/debian/rules kuvert-2.2.2+nmu1/debian/rules
--- kuvert-2.2.2/debian/rules   2017-10-28 03:38:02.0 +0200
+++ kuvert-2.2.2+nmu1/debian/rules  2021-08-01 20:25:57.0 +0200
@@ -18,9 +18,7 @@
 
 build-stamp:
dh_testdir
-
-   $(MAKE)
-
+   dh_auto_build
touch build-stamp
 
 clean:


Bug#991783: utalk FTCBFS: strips with the build architecture strip

2021-08-01 Thread Helmut Grohne
Source: utalk
Version: 1.0.2-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

utalk fails to cross build from source, because it strips with the build
architecture strip during make install. Beyond breaking cross
compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as
generation of -dbgsym packages. The best solution is to defer all
stripping to dh_strip and not strip at an earlier time. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru utalk-1.0.2/debian/changelog utalk-1.0.2/debian/changelog
--- utalk-1.0.2/debian/changelog2021-05-14 15:49:22.0 +0200
+++ utalk-1.0.2/debian/changelog2021-08-01 20:32:18.0 +0200
@@ -1,3 +1,10 @@
+utalk (1.0.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Do not strip during make install. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 01 Aug 2021 20:32:18 +0200
+
 utalk (1.0.2-1) unstable; urgency=low
 
   * New upstream release (closes: #980251)
diff --minimal -Nru utalk-1.0.2/debian/patches/nostrip.patch 
utalk-1.0.2/debian/patches/nostrip.patch
--- utalk-1.0.2/debian/patches/nostrip.patch1970-01-01 01:00:00.0 
+0100
+++ utalk-1.0.2/debian/patches/nostrip.patch2021-08-01 20:31:38.0 
+0200
@@ -0,0 +1,20 @@
+--- utalk-1.0.2.orig/Makefile
 utalk-1.0.2/Makefile
+@@ -47,6 +47,8 @@
+ 
+ ROFF = nroff
+ 
++STRIP ?= strip
++
+ all:  utalk
+ 
+ utalk.cat:utalk.1
+@@ -59,7 +61,7 @@
+   $(CC) $(LDFLAGS) -o stest stest.o $(LIBS) $(EXTRALIBS)
+ 
+ install:  utalk utalk.1
+-  strip utalk
++  $(STRIP) utalk
+   mkdir -p $(BINDIR)
+   mkdir -p $(MANDIR)
+   mkdir -p $(MANDIR)/man1
diff --minimal -Nru utalk-1.0.2/debian/patches/series 
utalk-1.0.2/debian/patches/series
--- utalk-1.0.2/debian/patches/series   2021-05-14 15:49:22.0 +0200
+++ utalk-1.0.2/debian/patches/series   2021-08-01 20:31:14.0 +0200
@@ -1 +1,2 @@
 fix-utalk-makefile.patch
+nostrip.patch
diff --minimal -Nru utalk-1.0.2/debian/rules utalk-1.0.2/debian/rules
--- utalk-1.0.2/debian/rules2021-05-14 15:49:22.0 +0200
+++ utalk-1.0.2/debian/rules2021-08-01 20:32:14.0 +0200
@@ -20,7 +20,7 @@
 
 
 override_dh_auto_install:
-   dh_auto_install -- prefix=/usr
+   dh_auto_install -- prefix=/usr STRIP=true
 
 %:
dh $@


Bug#991782: aribas FTCBFS: multiple reasons

2021-08-01 Thread Helmut Grohne
Source: aribas
Version: 1.64-6
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

aribas fails to cross build from source for three distinct reasons.

1. debian/rules intends to build differently when building for i386, but
   what it actually does is conditionalizing what it builds on. Please
   refer to man dpkg-architecture for a definition of "build" and
   "host."

2. debian/rules forces the build architecture compiler. The simplest fix
   is letting dpkg's buildtools.mk initiatlize CC.

3. debian/patches/casting_pointers (unintentionally?!) reverts
   debian/patches/no_strip. As such stripping is performed with the
   build architecture strip. Doing so also happens to break
   DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym packages.

Please consider applying the attached patch to fix all of the above.

Helmut
diff --minimal -Nru aribas-1.64/debian/changelog aribas-1.64/debian/changelog
--- aribas-1.64/debian/changelog2016-12-09 19:06:43.0 +0100
+++ aribas-1.64/debian/changelog2021-08-01 20:47:12.0 +0200
@@ -1,3 +1,13 @@
+aribas (1.64-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Fix build vs. host confusion in debian/rules.
++ Let dpkg's buildtools.mk supply a compiler.
++ Stop reverting d/patches/no_strip in d/patches/casting_pointers.
+
+ -- Helmut Grohne   Sun, 01 Aug 2021 20:47:12 +0200
+
 aribas (1.64-6) unstable; urgency=low
 
   * Installed emacsen-startup, as proposed by Kevin Ryde (thanks!)
diff --minimal -Nru aribas-1.64/debian/patches/casting_pointers 
aribas-1.64/debian/patches/casting_pointers
--- aribas-1.64/debian/patches/casting_pointers 2016-12-09 19:06:43.0 
+0100
+++ aribas-1.64/debian/patches/casting_pointers 2021-08-01 20:47:12.0 
+0200
@@ -549,15 +549,6 @@
  # This is the size of the ARIBAS heap in Megabytes
  # The value should not exceed one half of the RAM of your machine
  # If MEMFLAG is not defined, MEM=2 will be used by default
-@@ -48,7 +48,7 @@
- 
- $(PROGRAM): $(OBJECTS) $(ASSOBJECTS)
-   $(CC) -o $(PROGRAM) $(LFLAGS) $(OBJECTS) $(ASSOBJECTS)
--
-+  strip $(PROGRAM)
- clean:
-   \rm *.o
- 
 Index: aribas-1.64/src/LINUX/README
 ===
 --- aribas-1.64.orig/src/LINUX/README  2010-02-10 21:17:30.0 +0100
@@ -650,15 +641,6 @@
  # MEM may be set to any integer value from 1 to 32.
  # This is the size of the ARIBAS heap in Megabytes
  # The value should not exceed one half of the RAM of your machine
-@@ -44,7 +44,7 @@
- 
- $(PROGRAM): $(OBJECTS)
-   $(CC) -o $(PROGRAM) $(OBJECTS)
--
-+  strip $(PROGRAM)
- clean:
-   \rm *.o
- 
 Index: aribas-1.64/src/print.c
 ===
 --- aribas-1.64.orig/src/print.c   2010-02-10 21:17:11.0 +0100
diff --minimal -Nru aribas-1.64/debian/rules aribas-1.64/debian/rules
--- aribas-1.64/debian/rules2016-12-09 19:06:43.0 +0100
+++ aribas-1.64/debian/rules2021-08-01 20:47:10.0 +0200
@@ -1,10 +1,12 @@
 #!/usr/bin/make -f
 
+-include /usr/share/dpkg/buildtools.mk
+
 %:
dh $@
 
 override_dh_auto_build:
-   if [ "$(DEB_BUILD_ARCH)" = "i386" ];\
+   if [ "$(DEB_HOST_ARCH)" = "i386" ];\
then \
cp src/LINUX/arito386.S src;\
MAKEFILE=LINUX/Makefile.linux;\
@@ -16,7 +18,7 @@
EXTRAFLAGS="-DUNiX -DPROTO";\
fi;\
cd src && make -f $$MAKEFILE\
-   CC=gcc\
+   CC=$(CC)\
CFLAGS="$(OPTFLAGS) $$EXTRAFLAGS"\
ASSOBJECTS="$$ASSOBJECTS"
 


Bug#991614: apache-directory-server: CVE-2021-33900

2021-08-01 Thread Salvatore Bonaccorso
Hi Markus,

On Sun, Aug 01, 2021 at 05:53:55PM +0200, Salvatore Bonaccorso wrote:
> Hi Markus,
> 
> On Sun, Aug 01, 2021 at 05:28:23PM +0200, Markus Koschany wrote:
> > On Wed, 28 Jul 2021 17:44:49 +0200 Salvatore Bonaccorso 
> > wrote:
> >  
> > > Hi,
> > > 
> > > The following vulnerability was published for apache-directory-server.
> > > 
> > > CVE-2021-33900[0]:
> > 
> > 
> > Hi Salvatore,
> > 
> > are you sure CVE-2021-33900 corresponds to apache-directory-server as well? 
> > To
> > me it seems the vulnerability is in apache-directory-studio which is a
> > different Apache project
> > 
> > https://github.com/apache/directory-studio/
> > 
> > We haven't packaged that yet.
> 
> I will have a look again (hopefully today) and come back to you again.
> Maybe this was a mistake, so I will recheck.

So aboslutely correct. The issue is in Apache Directory Studio. It
went from a error in tracking initially in 7adc1d9f0406
("CVE-2021-33900/apacheds") in the security-tracker repo, to fixing
the source package name in cff955e4f7e3 ("CVE-2021-33900: Track source
package name apache-directory-server") but without noticing the wrong
source package affected.

So, right, and closing this issue (and corrected along the
security-tracker tracking of CVE-2021-33900).

Regards,
Salvatore



Bug#901332: d-i: Offer to shut down / power off instead of reboot at the end

2021-08-01 Thread Philip Hands
Thorsten Glaser  writes:

> Package: debian-installer
> Followup-For: Bug #901332
> X-Debbugs-Cc: t...@mirbsd.de
>
> Did anything ever come from this, now that we’re nearing a release?

BTW one can preseed this behaviour with 'debian-installer/exit/halt' or
'debian-installer/exit/poweroff' as mentioned here:

  https://www.debian.org/releases/stable/amd64/apbs04.en.html#preseed-finish

which means that you could specify such a setting on the kernel command
line when starting debian-installer to get the behaviour you want.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature


Bug#991780: mc: still depends on transitional package mime-support

2021-08-01 Thread Thomas Uhle

Package: mc
Version: 3:4.8.26-1.1
Severity: normal

Dear maintainers,

mc internally uses run-mailcap which used to be in mime-support but has 
been moved to package mailcap (new in bullseye). Package mime-support has 
become a transitional package. Could you please update dependencies by 
replacing mime-support with mailcap?


Thank you in advance!

Thomas Uhle



-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mc depends on:
ii  libc6 2.31-13
ii  libext2fs21.46.2-2
ii  libglib2.0-0  2.66.8-1
ii  libgpm2   1.20.7-8
ii  libslang2 2.3.2-5
ii  libssh2-1 1.9.0-2
ii  mc-data   3:4.8.26-1.1

Versions of packages mc recommends:
ii  mime-support3.66
ii  perl5.32.1-4
ii  sensible-utils  0.0.14
ii  unzip   6.0-26

Versions of packages mc suggests:
pn  arj  
ii  bzip21.0.8-4
pn  catdvi | texlive-binaries
pn  dbview   
pn  djvulibre-bin
ii  epub-utils   0.2.2-4+b4
ii  evince [pdf-viewer]  3.38.2-1
ii  file 1:5.39-3
pn  genisoimage  
pn  gv   
ii  imagemagick-7 [imagemagick]  8:7.1.0.4-dmo1
pn  libaspell-dev
pn  odt2txt  
ii  poppler-utils20.09.0-3.1
pn  python-boto  
ii  python-is-python2 [python]   2.7.18-9
ii  python-tz2020.4-1
pn  unar 
ii  w3m  0.5.3+git20210102-6
pn  wimtools 
ii  zip  3.0-12



Bug#991555: unblock: wpewebkit/2.32.3-1

2021-08-01 Thread Paul Gevers
Control: tags -1 moreinfo

Hi Alberto,

On 27-07-2021 15:57, Alberto Garcia wrote:
> Please unblock package wpewebkit

wpewebkit is blocked behind wpebackend-fdo which was NACK'ed already due
to build system changes. Can the upload be done in such a way that that
dependency doesn't show up? Can wpebackend-fdo be reverted to unblock
wpewebkit?

Having said all this, the window to resolve this is closing. Less than
one week.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#991687: Update xfce4-sensors-plugin to v1.4.1

2021-08-01 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, 2021-07-30 at 12:00 +0200, Peter Weilbacher wrote:
> According to 
> https://gitlab.xfce.org/panel-plugins/xfce4-sensors-plugin/-/blob/master/NEWS
>  
> new versions (v1.4 and now v1.4.1) of the sensors plugin have been 
> released upstream. These are supposed to fix many longstanding bugs, 
> including some reported against the Debian version (e.g. #851407, 
> #989933, and possibly #871717).

Hi Peter, thanks for the notification. We'll try to update it in sid but it
won't be part of Bullseye.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAmEG1bMACgkQ3rYcyPpX
RFswswf/fCFf2121WNKlybTvXpArILvUU2/ZsVTl7oJqNMNsDS7tn9tNwMuHt1YD
kD25gJD9M1j5cTVwUU7gXOJhzbzQHAKHAK4PIiiE9GB2ETD0PXdHB1LsBqS2JNDN
XdV0stEa30/mm98yzi2gWc7L0HZ6B2o1PhTPdOn8t3jQWfQ+UDW+C/SvkEZ4lSiJ
dVDyyvdIBQer2z9cXK9F5vTuXmLp5i9GAkY6pbjKZ3LEkv3ugFbbo36kJCh0dyJk
epikSPxVHqffmS8gL2qvLNV+Qdr2AsFuDQRMIiEekpxpoU3F6qhLmUc6IEaarq6s
xm+/Q8sH9GOl2j8T9ClPL+JipCKvkA==
=TOo2
-END PGP SIGNATURE-



Bug#991778: dlint: Dlint fails to find version number of dig

2021-08-01 Thread Patrik Schindler
Package: dlint
Version: 1.4.0-8
Severity: grave
Tags: patch
Justification: renders package unusable

On my Debian Buster system, dig fails to work with

;; This program requires DiG version 2.1 or newer, which I cannot find.

Checking on this, I saw that the "ver" call in line 109 doesn't output a
version number anymore. So I changed that to dig -v.

Next, sed was unable to extract a meaningful version number from what dig -v
provided, so I changed the sed statement in the same line accordingly.

The following replacement for line 109 works for me.

ver=`dig -v 2>&1 | grep DiG | head -1 | sed -e 's/^DiG \([0-9.]\+\).*$/\1/'`

My changes might introduce non-backwards compatible changes, though.

-- System Information:
Debian Release: 10.10
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-17-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages dlint depends on:
ii  dnsutils  1:9.11.5.P4+dfsg-5.1+deb10u5
ii  perl  5.28.1-6+deb10u1

dlint recommends no packages.

dlint suggests no packages.

-- no debconf information



Bug#976553: mojoshader: FTBFS: segfaults

2021-08-01 Thread Aditya

On Mon, 1 Mar 2021 19:39:38 +0200 Adrian Bunk  wrote:
> Control: tags -1 patch
>
> >...
> > > make[3]: Entering directory '/<>/obj-aarch64-linux-gnu'
> > > [ 9%] Generating ../mojoshader_parser_hlsl.h
> > > ./lemon -q -T/<>/misc/lempar.c 
/<>/mojoshader_parser_hlsl.lemon

> > > Segmentation fault
> > > make[3]: *** [CMakeFiles/mojoshader.dir/build.make:86: 
../mojoshader_parser_hlsl.h] Error 139

> >...
>
> The attached patch fixes the segfault on architectures where char is
> unsigned.
>
> cu
> Adrian

Was finally able to build mojoshader on arm64 using this patch. Thanks 
Adrain!


Kind regards,
Aditya



Bug#991614: apache-directory-server: CVE-2021-33900

2021-08-01 Thread Salvatore Bonaccorso
Hi Markus,

On Sun, Aug 01, 2021 at 05:28:23PM +0200, Markus Koschany wrote:
> On Wed, 28 Jul 2021 17:44:49 +0200 Salvatore Bonaccorso 
> wrote:
>  
> > Hi,
> > 
> > The following vulnerability was published for apache-directory-server.
> > 
> > CVE-2021-33900[0]:
> 
> 
> Hi Salvatore,
> 
> are you sure CVE-2021-33900 corresponds to apache-directory-server as well? To
> me it seems the vulnerability is in apache-directory-studio which is a
> different Apache project
> 
> https://github.com/apache/directory-studio/
> 
> We haven't packaged that yet.

I will have a look again (hopefully today) and come back to you again.
Maybe this was a mistake, so I will recheck.

Salvatore



Bug#991777: solaar: depends on udev file 42-logitech-unify-permissions.rules that is yet 60-solaar.rules

2021-08-01 Thread Thomas Uhle

Package: solaar
Version: 1.0.4+dfsg-1
Severity: normal

Dear maintainer,

after upgrading from buster to bullseye I have the following error message 
in $HOME/.xsession-errors everytime when Solaar starts:


Solaar depends on a udev file that is not present
For more information see the Solaar installation directions
at https://pwr-solaar.github.io/Solaar/installation


Having a look at the code, it is quite obvious that Solaar requests a udev 
rules file with the name "42-logitech-unify-permissions.rules", but for 
some reason this file has been named "60-solaar.rules" in Debian. So there 
are two possible solutions:

(a) Rename 60-solaar.rules to 42-logitech-unify-permissions.rules to be in
line with upstream.
(b) If it cannot be position 42 but has to stay at position 60 for some
reason whatsoever, then you need to adapt line 141 in
/usr/share/solaar/lib/solaar/gtk.py from

udev_file = '42-logitech-unify-permissions.rules'

to

udev_file = '60-solaar.rules'


Moreover, 60-solaar.rules is missing the following lines compared to 
upstream's 42-logitech-unify-permissions.rules at least:


--- /lib/udev/rules.d/60-solaar.rules   2020-10-22 16:02:24 +0200
+++ /home/thomas/solaar/rules.d/42-logitech-unify-permissions.rules 
2020-03-30 16:56:11 +0200
@@ -20,6 +48,9 @@

 LABEL="solaar_apply"

+# don't apply to the paired peripherals, just the receivers
+DRIVERS=="logitech-djdevice|logitech-hidpp-device", GOTO="solaar_end"
+
 # Allow any seated user to access the receiver.
 # uaccess: modern ACL-enabled udev
 # udev-acl: for Ubuntu 12.10 and older


It really would be great if you could fix this for the version in bullseye 
given that there are already several bug reports on Github and Launchpad 
with respect to systems running Solaar on Ubuntu 20.04 LTS and I would 
expect that there will be new reports once bullseye is released.


Best regards,

Thomas Uhle



-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-8-arm64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages solaar depends on:
ii  adduser  3.118
ii  debconf [debconf-2.0]1.5.77
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-2
ii  gir1.2-gtk-3.0   3.24.24-4
ii  gir1.2-notify-0.70.7.9-3
ii  passwd   1:4.8.1-1
ii  python3  3.9.2-3
ii  python3-gi   3.38.0-2
ii  python3-pyudev   0.22.0-2
ii  udev 247.3-6

Versions of packages solaar recommends:
ii  python3-dbus  1.2.16-5
ii  upower0.99.11-2

solaar suggests no packages.



Bug#991776: virt-viewer: Cannot connect to display with IPv6 literal as host

2021-08-01 Thread Kevin Otte
Package: virt-viewer
Version: 7.0-2
Severity: important

Dear Maintainer,

When attempting to connect to a remote display, and socat is present on the
remote system, I am unable to connect:

-
kjotte@mystic:~$ virt-viewer -vv -c qemu+ssh://agamemnon.home.nivex.net/system 
icarus
Opening connection to libvirt with URI 
qemu+ssh://agamemnon.home.nivex.net/system
Guest icarus is running, determining display
Guest icarus has a spice display
Opening indirect TCP connection to display at ::1:5901
Setting up SSH tunnel via agamemnon.home.nivex.net
2021/08/01 11:22:00 socat[54337] E TCP: wrong number of parameters (4 instead 
of 2)

(virt-viewer:159986): GSpice-WARNING **: 11:22:00.585: incomplete link header 
(0/16)
-

This is likely because the IPv6 literal "::1" is being passed directly to socat
without being wrapped in brackets (eg: [::1]).

The problem does not occur if socat is not present on the remote system as it
falls back to netcat.


-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 virt-viewer depends on:
ii  libatk1.0-0 2.36.0-2
ii  libc6   2.31-13
ii  libcairo-gobject2   1.16.0-5
ii  libcairo2   1.16.0-5
ii  libgdk-pixbuf2.0-0  2.40.2-2
ii  libglib2.0-02.66.8-1
ii  libgovirt2  0.3.7-2
ii  libgtk-3-0  3.24.24-4
ii  libgtk-vnc-2.0-01.0.0-1
ii  libgvnc-1.0-0   1.0.0-1
ii  libpango-1.0-0  1.46.2-3
ii  libpangocairo-1.0-0 1.46.2-3
ii  librest-0.7-0   0.8.1-1.1
ii  libsoup2.4-12.72.0-2
ii  libspice-client-glib-2.0-8  0.39-1
ii  libspice-client-gtk-3.0-5   0.39-1
ii  libvirt-glib-1.0-0  3.0.0-1
ii  libvirt07.0.0-3
ii  libxml2 2.9.10+dfsg-6.7

virt-viewer recommends no packages.

Versions of packages virt-viewer suggests:
ii  netcat-openbsd [netcat]  1.217-3
ii  netcat-traditional [netcat]  1.10-46

-- no debconf information



Bug#991614: apache-directory-server: CVE-2021-33900

2021-08-01 Thread Markus Koschany
On Wed, 28 Jul 2021 17:44:49 +0200 Salvatore Bonaccorso 
wrote:
 
> Hi,
> 
> The following vulnerability was published for apache-directory-server.
> 
> CVE-2021-33900[0]:


Hi Salvatore,

are you sure CVE-2021-33900 corresponds to apache-directory-server as well? To
me it seems the vulnerability is in apache-directory-studio which is a
different Apache project

https://github.com/apache/directory-studio/

We haven't packaged that yet.

Cheers,

Markus


signature.asc
Description: This is a digitally signed message part


Bug#987441: s390x installation bugs

2021-08-01 Thread Cyril Brulebois
Valentin Vidic  (2021-08-01):
> No problem, I was not able to reproduce this reliably or get a core
> dump for this crash. It could just be an emulation problem with qemu
> or some timing issue for the first installer step. If there is no
> update on this problem I think we can even close it for now.

Speaking of the first step, did anyone mention #987368 before, now fixed
in udpkg?

(The BTS seems to be sad right now, and I'd like to avoid diving into
bug mail.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature


Bug#991765: unblock: magnus/1:1.0.3-3

2021-08-01 Thread Mike Gabriel
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package magnus

[ Reason ]
Andreas Beckmann discovered that a package "magnus" has been in Debian
squeeze already with a higher version number.

The package in squeeze was another piece of software and had a higher
version.

So, the situation is a little awkward, but the agreement was: use epoch
"1:" for this magnus package (magnifier glass for MATE desktop).

[ Impact ]
Possible conflict with old versions of the magnus package in squeeze.

[ Tests ]
None.

[ Risks ]
None, except from people possibly having an old magnus package.

[ 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

[ Other info ]
Unfortunately, I uploaded way too many changes as 1:1.0.3-2 and reverted
most of them in 1:1.0.3-3. This lets debian/changelog appear a little bit
bloated.

unblock magnus/1:1.0.3-3
diff -Nru magnus-1.0.3/debian/changelog magnus-1.0.3/debian/changelog
--- magnus-1.0.3/debian/changelog   2019-09-28 00:30:02.0 +0200
+++ magnus-1.0.3/debian/changelog   2021-07-30 20:21:26.0 +0200
@@ -1,3 +1,40 @@
+magnus (1:1.0.3-3) unstable; urgency=medium
+
+  * Revert the unintended changes listed below. There were not meant to
+end up in the Debian bullseye version of this package.
+
+  * debian/control:
++ revert: Bump DH compat level to version 13.
++ revert: Bump Standards-Version: to 4.5.0. No changes needed.
++ revert: Add Rules-Requires-Root: field and set it to no.
+  * debian/upstream/metadata:
++ revert: Append .git suffix to URLs in Repository: field.
++ revert: Drop obsolete fields Contact: and Name:.
+
+ -- Mike Gabriel   Fri, 30 Jul 2021 20:21:26 +0200
+
+magnus (1:1.0.3-2) unstable; urgency=medium
+
+  * debian/changelog:
++ Introduce epoch 1 in package version. Debian previously (until Debian 6)
+  had another piece of software called 'magnus' with a higher version
+  number. (Closes: #991624).
+  * debian/copyright:
++ Update copyright attributions.
+
+  * The following changelog entries have been added here post-upload and were
+not intended to end up in this version.
+
+  * debian/control:
++ Bump DH compat level to version 13.
++ Bump Standards-Version: to 4.5.0. No changes needed.
++ Add Rules-Requires-Root: field and set it to no.
+  * debian/upstream/metadata:
++ Append .git suffix to URLs in Repository: field.
++ Drop obsolete fields Contact: and Name:.
+
+ -- Mike Gabriel   Fri, 30 Jul 2021 12:14:37 +0200
+
 magnus (1.0.3-1) unstable; urgency=medium
 
   [ Martin Wimpress ]
diff -Nru magnus-1.0.3/debian/copyright magnus-1.0.3/debian/copyright
--- magnus-1.0.3/debian/copyright   2019-06-06 16:35:20.0 +0200
+++ magnus-1.0.3/debian/copyright   2021-07-30 12:16:02.0 +0200
@@ -6,7 +6,9 @@
 data/screenshot.png
 
 Files: .gitignore
+   .github/FUNDING.yml
.travis.yml
+   snap/snapcraft.yaml
magnus
README.md
 Copyright: 2019, Stuart Langridge 


Bug#991774: ucspi-unix FTBFS on architectures without dietlibc

2021-08-01 Thread Adrian Bunk
Source: ucspi-unix
Version: 1.0-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=ucspi-unix=sid

...
chmod 755 compile
./compile unixclient.c
./compile: 4: exec: diet: not found
make[2]: *** [Makefile:74: unixclient.o] Error 127


This should either be fixed properly, or the build dependency
on dietlibc-dev should become unconditional to avoid expected
build failures.



Bug#991775: ITP: graphene -- GraphQL Framework for Python

2021-08-01 Thread Carsten Schoenert
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: graphene
  Version : 2.1.9
  Upstream Author : Syrus Akbary 
* URL : https://github.com/graphql-python/graphene
* License : MIT
  Programming Lang: Python
  Description : GraphQL Framework for Python

 Graphene is a Python library for building GraphQL schemas/types fast and
 easily.
 .
  * Easy to use: Graphene helps you use GraphQL in Python without effort.
  * Relay: Graphene has builtin support for Relay.
  * Data agnostic: Graphene supports any kind of data source: SQL (Django,
SQLAlchemy), NoSQL, custom Python objects, etc. Upstream believes
that by providing a complete API you could plug Graphene anywhere
your data lives and make your data available through GraphQL.

This package is an direct dependency for the next major version of
NetBox (will be version 3) which I consider to package.

The package will get maintained within the Debian Python Team.



Bug#991773: libvirt-daemon-driver-lxc: container reboot done from inside or outside container shuts container down

2021-08-01 Thread Alexis Huxley
Package: libvirt-daemon-driver-lxc
Version: 7.0.0-3
Severity: normal

Dear Maintainer,

A Debian 11 RC2 container running on a Debian 11 RC2 hosts responds
to the reboot command by shutting down services and then powering
off, *not* by rebooting, which is what I would expect.

This applies regardless of whether I:

* run 'reboot' inside the container
* run 'virsh reboot' on the host
* run 'kill -SIGINT 1' inside the container

This is consistently reproducible.

Here's output from trying it with 'virsh reboot', as it's the
most copy-and-paste-able:

pestaroli# export LIBVIRT_DEFAULT_URI=lxc:///
pestaroli# virsh list --all
 Id   Name  State
--
 -mafalde   shut off

pestaroli# virsh start mafalde
Domain 'mafalde' started

pestaroli# virsh list --all
 Id   Name  State
-
 467946   mafalde   running

pestaroli# virsh reboot mafalde
Domain 'mafalde' is being rebooted

pestaroli# virsh list --all
 Id   Name  State
--
 -mafalde   shut off   <-- should be 'running'!

pestaroli# 

I am submitting this bug report against the libvirt-daemon-driver-lxc
package because /usr/lib/libvirt/libvirt_lxc is the parent of the
container's init process:

root  468678  0.0  0.4 355008 17096 ?Sl   15:26   0:00 
/usr/lib/libvirt/libvirt_lxc --name mafalde --console 30 --security=apparmor 
--handshake 34 --veth vnet77
10468681  0.7  0.2  99948 10008 ?Ss   15:26   0:00  \_ 
/sbin/init
10468713  0.3  0.3  31932 13016 ?Ss   15:26   0:00  
\_ /lib/systemd/systemd-journald
100105468770  0.1  0.1   7952  4332 ?Ss   15:26   0:00  
\_ /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile 
--systemd-activation --syslog-only

but it might well be that the bug is in another package (I think
you are more qualified to judge that than I am), so please reassign
if you think appropriate.  In case it is relevant, here are the
lxc/libvirt/systemd packages installed on the host:

pestaroli# dpkg -l | egrep '(lxc|libvirt|systemd)'
ii  liblxc1:amd641:4.0.6-2  
amd64Linux Containers userspace tools (library)
ii  libnss-systemd:amd64 247.3-6
amd64nss module providing dynamic user and group name resolution
ii  libpam-systemd:amd64 247.3-6
amd64system and service manager - PAM module
ii  libsystemd0:amd64247.3-6
amd64systemd utility library
ii  libvirt-clients  7.0.0-3
amd64Programs for the libvirt library
ii  libvirt-daemon   7.0.0-3
amd64Virtualization daemon
ii  libvirt-daemon-config-network7.0.0-3
all  Libvirt daemon configuration files (default network)
ii  libvirt-daemon-config-nwfilter   7.0.0-3
all  Libvirt daemon configuration files (default network filters)
ii  libvirt-daemon-driver-lxc7.0.0-3
amd64Virtualization daemon LXC connection driver
ii  libvirt-daemon-driver-qemu   7.0.0-3
amd64Virtualization daemon QEMU connection driver
ii  libvirt-daemon-system7.0.0-3
amd64Libvirt daemon configuration files
ii  libvirt-daemon-system-systemd7.0.0-3
all  Libvirt daemon configuration files (systemd)
ii  libvirt0:amd64   7.0.0-3
amd64library for interfacing with different virtualization systems
ii  lxc  1:4.0.6-2  
amd64Linux Containers userspace tools
ii  lxc-templates3.0.4-5
amd64Linux Containers userspace tools (templates)
ii  lxcfs4.0.7-1
amd64FUSE based filesystem for LXC
ii  systemd  247.3-6
amd64system and service manager
ii  systemd-container247.3-6
amd64systemd container/nspawn tools
ii  systemd-sysv 247.3-6
amd64system and service manager - SysV links
pestaroli# 

and here is the container's XML:

pestaroli# virsh dumpxml 

Bug#991703: unblock: openjdk-11/11.0.12+7-2

2021-08-01 Thread Paul Gevers
Hi,

On 01-08-2021 16:02, Emmanuel Bourg wrote:
> I've just uploaded openjdk-11-jre-dcevm/11.0.12+7-1 which fixes the issue.
> 
> Should I file an unblock request?

Yes, please. Please elaborate on the items I asked last time a bit too,
like how the source is literately the same (and if not, how not). Just
for the avoidance of doubt.

Paul



OpenPGP_signature
Description: OpenPGP digital signature


Bug#947688: systemd-networkd: Python socket.getfqdn() not working properly when resolv.conf lacks "domain" key

2021-08-01 Thread Michael Biebl

Control: forwarded -1 https://github.com/systemd/systemd/issues/20358

Am 01.08.21 um 11:13 schrieb Dirk Heinrichs:

Sorry for the delay, I always forgot to do it. It's finally there now:
https://github.com/systemd/systemd/issues/20358


Thanks, marking it accordingly.




OpenPGP_signature
Description: OpenPGP digital signature


Bug#991772: kexec-tools: [INTL:nl] Dutch translation of debconf messages

2021-08-01 Thread Frans Spiesschaert
 
 
Package: kexec-tools 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of kexec-tools debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip


Bug#991703: unblock: openjdk-11/11.0.12+7-2

2021-08-01 Thread Emmanuel Bourg

Hi Paul,

Le 2021-07-30 15:29, Paul Gevers a écrit :


Matthias is asking for an unblock of openjdk-11, but it breaks
openjdk-11-jre-dcevm. Are you in the position to fix this soon?


I've just uploaded openjdk-11-jre-dcevm/11.0.12+7-1 which fixes the 
issue.


Should I file an unblock request?

Emmanuel Bourg



Bug#991771: debian-installer: firmware support: review/update “6.4.1. Preparing a medium” procedure

2021-08-01 Thread Cyril Brulebois
Package: debian-installer
Severity: normal
X-Debbugs-Cc: debian...@lists.debian.org

A lot of work has happened in the firmware support department for
Bullseye, as documented in #989863. In passing, Steve mentioned the
“download archives of firmware packages” use case that we document in
6.4.1:
  https://www.debian.org/releases/bullseye/amd64/ch06s04.en

The code changes implemented to widen firmware detection rely on
supplemental information extracted from DEP-11 metadata, and ship
alongside the included firmware packages, on the debian-cd side,
only when building (unofficial) firmware-enabled images.

To make sure we wouldn't disrupt anything on (official) main-only
images, we shipped those `*.patterns` files in a `dep11` subdir of
the `firmware` directory (again, only for firmware-enabled images).

If we want to make it possible for people to complete their main-only
installation image with files they would download separately, we would
need those files to be shipped somewhere on the installation image,
and/or to update those instructions. This would likely require code
changes in any cases, since hw-detect prompts for extra storage devices
from check-missing-firmware (in case firmware files were spotted as
missing in dmesg), while the extra looking at `.patterns` files was
implemented in the post-base-installer 50install-firmware hook.

This didn't seem to be very high priority, and I didn't make it a
blocker for 11.0; we can brainstorm what use cases we want to support
and how, implement changes in D-I Bookworm Alpha releases, and maybe
cherry-pick results in 11.n.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


Bug#991770: umatrix: new upstream release (1.4.4) fixes security issue

2021-08-01 Thread Paul Wise
Source: umatrix
Version: 1.4.0+dfsg-1
Severity: wishlist
Tags: security

There is a new upstream release 1.4.4 that fixes a security issue:

https://github.com/gorhill/uMatrix/releases
https://github.com/vtriolet/writings/blob/main/posts/2021/ublock_origin_and_umatrix_denial_of_service.adoc

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part


Bug#991769: ITP: python-ml-collections -- collections designed for ML usecases

2021-08-01 Thread Steffen Moeller
Package: wnpp
Severity: wishlist

Subject: ITP: python-ml-collections -- collections designed for ML usecases
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: python-ml-collections
  Version : 0.1.0
  Upstream Author : xx-20yy ML Collections Authors 
* URL : https://github.com/google/ml_collections
* License : Apache-2.0
  Programming Lang: Python
  Description : collections designed for ML usecases
 The package provices two classes called ConfigDict and FrozenConfigDict that
 are "dict-like" data structures with dot access to nested elements. Together,
 they are supposed to be used as a main way of expressing configurations of
 experiments and models.
 .
 Features:
  * Dot-based access to fields.
  * Locking mechanism to prevent spelling mistakes.
  * Lazy computation.
  * FrozenConfigDict() class which is immutable and hashable.
  * Type safety.
  * "Did you mean" functionality.
  * Human readable printing (with valid references and cycles), using valid 
YAML format.
  * Fields can be passed as keyword arguments using the ** operator.
 .
 There are two exceptions to the strong type-safety of the ConfigDict. int
 values can be passed in to fields of type float. In such a case, the
 value is type-converted to a float before being stored. Similarly,
 all string types (including Unicode strings) can be stored in fields
 of type str or unicode.

Remark: This package is maintained by Debian Python Team at
   https://salsa.debian.org/python-team/packages/python-ml-collections



Bug#991768: wireguard-dkms: wireguard-dmks autoinstall fails, not matching BUILD_EXCLUSIVE directive in Bullesye

2021-08-01 Thread Sem
Package: wireguard-dkms
Version: 1.0.20210219-1
Severity: important
Tags: upstream




-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages wireguard-dkms depends on:
ii  dkms  2.8.4-3
ii  perl  5.32.1-4

Versions of packages wireguard-dkms recommends:
ii  wireguard1.0.20210223-1
ii  wireguard-tools  1.0.20210223-1

wireguard-dkms suggests no packages.

-- no debconf information

When regulary updating the system via apt/apt-get on Bullseye wireguard will 
fail to build when the linux-image package is updated with the following error:

Setting up linux-headers-5.10.0-8-amd64 (5.10.46-3) ...
/etc/kernel/header_postinst.d/dkms:
dkms: running auto installation service for kernel 5.10.0-8-amd64:Error!  The 
/var/lib/dkms/wireguard/1.0.20210219/5.10.0-8-amd64/x86_64/dkms.conf for module 
wireguard includes a BUILD_EXCLUSIVE directive which
does not match this kernel/arch.  This indicates that it should not be built.



Bug#860027: ITP: elpa-page-break-lines -- Emacs mode to display ugly ^L page breaks as tidy horizontal lines

2021-08-01 Thread Nicholas D Steeves
Hello Martin!

Martin  writes:

> On 2021-08-01 03:37, Nicholas D Steeves wrote:
>> This src:package naming is not compliant with our team policy.  See:
>>
>>   https://wiki.debian.org/Teams/DebianEmacsenTeam
>>
>> I just made a minor addition "I.e. Do not add an 'elpa-' prefix to the
>> source package name." in case it wasn't previously clear.
>
> Oh, I see. I probably did this wrong for more than one package :-(
> I'll keep it in mind for the future, thanks for the hint!

You're welcome!  If the packages are still in NEW then it's not too late
to fix :-)  Also, I don't know if ftpmasters are now aware of our
team policy (and if they reject based on it), so it may be worthwhile to
contact them soon.

Cheers!
Nicholas


signature.asc
Description: PGP signature


Bug#958402: sudo: A password is required for /usr/bin/uptime

2021-08-01 Thread Marc Haber
On Mon, Feb 22, 2021 at 04:33:26PM +0100, Marc Haber wrote:
> You could try disabling this on .conkyrc to find out whether this might
> still be causing the issue?
> 
> This doesn't look like a sudo issue at all.

Unfortunately, the bug reporter did not reply. I intend to close this
issue by the end of August 2021 if no reply is added until then or the
issue is observed by other people.

Greetings
Marc



Bug#869135: Please don't adopt giza for libpgplot-perl

2021-08-01 Thread Ole Streicher

Hi Karl,

On 01.08.21 10:14, Karl Glazebrook wrote:

There does not seem to have been any further reply on this thread?


Yea, and the bug was then archived a while ago. For the discussion, I 
unarchived it and forwarded your last mail.



Gregor says 'In Debian all tests [0] pass’

However, if you drill down in to the logs you can see they are not being 
run correctly


The best would be to open a new Debian bug for libpgplot-perl with these 
findings. I would guess a bug there.


The original Caltech pgplot is old software but works fine and is 
required by a lot of astronomy software. Seems to me we can have a 
debian package for it, and for giza-pgplot seperately? I note all the 
advantages of giza, and it can be the default.


Would it make sense to create a debian package called 
‘libpgplot-classic’ or something for ‘contrib'?


I would guess that this is not that simple, as it would require a fork 
of the package. The problem is that pgplot is a static library (and the 
package itself is a one-in-all). Therefore, it would be needed as a buld 
time dependency, which would make the source package "contrib".


Another way would be to modernize the original pgplot package, with a 
shared lib and then let the user decide which one to link at run time. 
But this requires a significant effort, and the pgplot package itself 
seems quite unmaintained in Debian.


Cheers

Ole



Bug#869135: Please don't adopt giza for libpgplot-perl

2021-08-01 Thread Karl Glazebrook
Hi all,

There does not seem to have been any further reply on this thread?

Gregor says 'In Debian all tests [0] pass’

However, if you drill down in to the logs you can see they are not being run 
correctly

Sample below (e.g. 
https://buildd.debian.org/status/fetch.php?pkg=libpgplot-perl=ia64=1%3A2.24-1%2Bb2=1604918369=0
 )

The original Caltech pgplot is old software but works fine and is required by a 
lot of astronomy software. Seems to me we can have a debian package for it, and 
for giza-pgplot seperately? I note all the advantages of giza, and it can be 
the default.

Would it make sense to create a debian package called ‘libpgplot-classic’ or 
something for ‘contrib'?


Karl




== Running test8.p ==


Testing scalars in array routines...

PGPLOT module version 2.24

PGPLOT giza-1.1.0 library

%giza - ERROR - giza_newpage_prompt: Failed to read character from stdin
== Running test9.p ==


Testing PGPLOT 5.0 colour image routines...

PGPLOT module version 2.24

PGPLOT giza-1.1.0 library

32768 bytes read
16384 element image stored
Plotting...
%giza - ERROR - giza_newpage_prompt: Failed to read character from stdin
== Running test10.p ==


Testing multiple ways of passing things...

PGPLOT module version 2.24

PGPLOT giza-1.1.0 library

Plotting...
--
Points: scalars passed one by one
Image: packed char string
--
Points: 1D array passed by glob
Image: 1D array passed by glob
--
Points: 1D array passed by reference
Image: 1D array passed by reference
--
Line: 1D cross-section of 2D array
Image: 2D array passed by reference
--
%giza - ERROR - giza_newpage_prompt: Failed to read character from stdin
== Running test11.p ==


Testing Object-Oriented stuff...

PGPLOT module version 2.24

PGPLOT giza-1.1.0 library


Testing Square Objects...
Square plot method...
Square expand and rotate methods...
Inheriting Square methods in Triangles...
Fun isn't it?
%giza - ERROR - giza_newpage_prompt: Failed to read character from stdin








On Fri, 27 Jul 2018 00:28:48 +0200 gregor herrmann 
mailto:gre...@debian.org>> wrote:
> On Fri, 27 Jul 2018 08:17:18 +1000, Karl Glazebrook wrote:
>
> > For example the perl/PGPLOT module (which I own on CPAN) comes with
> > a suite of test 12 scripts. When I tested them against giza, only 4
> > of the most basic ones passed!!
>
> Just to add a data point: In Debian all tests [0] pass:
> https://buildd.debian.org/status/package.php?p=libpgplot-perl
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpgplot-perl.html
> https://ci.debian.net/packages/libp/libpgplot-perl/
>
> [0] with one tiny patch to test12.p:
> https://salsa.debian.org/perl-team/modules/packages/libpgplot-perl/blob/master/debian/patches/test-pgplot5-version.patch
>
> Maybe the giza source is Debian has another version or carries
> patches, compared to the version you tried?
>
>
> Cheers,
> gregor
>
> --
>  .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
>  : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
>  `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
>`-   NP: Pogues: If I Should Fall From The Grac


Bug#991738: unblock: gdcm/3.0.8-2 (pre-approval)

2021-08-01 Thread Graham Inggs
Control: tags -1 + confirmed moreinfo

Hi Étienne

Please go ahead and upload to unstable, then remove the moreinfo tag
once it has built.

Regards
Graham



Bug#991749: unblock: ruby-maven-libs/3.3.9+ds-2

2021-08-01 Thread Graham Inggs
Control: tags -1 + moreinfo

Hi Praveen

On Sat, 31 Jul 2021 at 21:21,  wrote:
> +  * Bump debhelper from old 10 to 12.

Please revert this change.  See 'Target fixes' section of the freeze policy [1].

Regards
Graham


[1] https://release.debian.org/bullseye/freeze_policy.html#full



Bug#990383: nuspell: Small bugs in debian/control

2021-08-01 Thread Thorsten Alteholz

Hi Dimitrij,

thanks a log for your bug report.

According to [1] the term "spell checker" does not seem to be that wrong ...

Anyway, I updated the dependencies and due to the current freeze of 
Debian, I uploaded the new version to experimental.


  Thorsten


[1] https://en.wikipedia.org/wiki/Spell_checker



Bug#991767: samba: Attempt to change password over IPv6 using kpasswd fails on AD DC server

2021-08-01 Thread Lorenz Schori
Package: samba
Version: 2:4.13.5+dfsg-2
Severity: normal

Dear Maintainer,

After upstream commit 43c808f2ff907497dfff0988ff90a48fdcfc16ef any
attempt to change a password over IPv6 fails on the server side. Samba
generates the following log entries (on the domain controller):

Starting GENSEC mechanism krb5
Failed to start GENSEC server mech krb5: NT_STATUS_INTERNAL_ERROR

On the client side the request to change the password results in the
following message after a delay of a couple of seconds:

kpasswd: Cannot contact any KDC for requested realm changing
password

Upstream commit 43c808f2ff907497dfff0988ff90a48fdcfc16ef changed calls
to tsocket_address_bsd_sockaddr() in gensec_krb5.c such that IPv6
addresses will be rejected.

Affected are all upstream releases from branches 4.14 and 4.13. Older
branches / releases are not affected.

On the distro side, this bug affects soon to be released Debian
Bullseye, it does neither affect current stable Debian Buster nor Ubuntu
Focal (LTS).

Upstream bug (fixed in upstream release 4.13.10):
https://bugzilla.samba.org/show_bug.cgi?id=14750

-- Package-specific info:
* /etc/samba/smb.conf present, but not attached
* /var/lib/samba/dhcp.conf not present

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

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

Versions of packages samba depends on:
ii  adduser  3.118
ii  dpkg 1.20.9
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13
ii  libgnutls30  3.7.1-5
ii  libldb2  2:2.2.0-3.1
ii  libpam-modules   1.4.0-9
ii  libpam-runtime   1.4.0-9
ii  libpopt0 1.18-2
ii  libpython3.9 3.9.2-1
ii  libtalloc2   2.3.1-2+b1
ii  libtasn1-6   4.16.0-2
ii  libtdb1  1.4.3-1+b1
ii  libtevent0   0.10.2-1
ii  libwbclient0 2:4.13.5+dfsg-2
ii  lsb-base 11.1.0
ii  procps   2:3.3.17-5
ii  python3  3.9.2-3
ii  python3-dnspython2.0.0-1
ii  python3-samba2:4.13.5+dfsg-2
ii  samba-common 2:4.13.5+dfsg-2
ii  samba-common-bin 2:4.13.5+dfsg-2
ii  samba-libs   2:4.13.5+dfsg-2
ii  tdb-tools1.4.3-1+b1

Versions of packages samba recommends:
ii  attr1:2.4.48-6
ii  logrotate   3.18.0-2
ii  python3-markdown3.3.4-1
ii  samba-dsdb-modules  2:4.13.5+dfsg-2
ii  samba-vfs-modules   2:4.13.5+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
pn  ctdb   
ii  ldb-tools  2:2.2.0-3.1
pn  ntp | chrony   
pn  smbldap-tools  
pn  ufw
pn  winbind

-- no debconf information



Bug#991636: unblock: projectm/3.1.7-1.1 (pre-approval)

2021-08-01 Thread Graham Inggs
Control: tags -1 + confirmed moreinfo

Hi Andreas

On Thu, 29 Jul 2021 at 14:33, Andreas Beckmann  wrote:
> The fix is not yet uploaded, I intend to 2-day NMU it.

Please go ahead and upload to unstable, then remove the moreinfo tag
once it has built.

Regards
Graham



Bug#860027: ITP: elpa-page-break-lines -- Emacs mode to display ugly ^L page breaks as tidy horizontal lines

2021-08-01 Thread Martin


On 2021-08-01 03:37, Nicholas D Steeves wrote:
> This src:package naming is not compliant with our team policy.  See:
>
>   https://wiki.debian.org/Teams/DebianEmacsenTeam
>
> I just made a minor addition "I.e. Do not add an 'elpa-' prefix to the
> source package name." in case it wasn't previously clear.

Oh, I see. I probably did this wrong for more than one package :-(
I'll keep it in mind for the future, thanks for the hint!



Bug#991766: ITP: golang-github-rancher-go-rancher-metadata -- Go Bindings for Rancher-metadata service

2021-08-01 Thread Alois Micard
Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-rancher-go-rancher-metadata
  Version : 0.0~git20200311.7f4c936-1
  Upstream Author : Rancher
* URL : https://github.com/rancher/go-rancher-metadata
* License : Apache-2.0
  Programming Lang: Go
  Description : Go Bindings for Rancher-metadata service

This package is needed for Traefik.
Cheers,



Bug#960305: matrix-synapse: No instructions on setting up TLS

2021-08-01 Thread Nicolas George
Mikko Rasa (12020-05-11):
> Debian's homeserver configuration contains a https listener with certificate
> files stored under /etc/matrix-synapse.  However these files are not supplied
> nor generated by the package and there's no instructions on how to generate
> them.  Due to this the server won't start and it's not immediately obvious
> what should be done to correct the situation.

Hi. I am running in the same problem, and gave up considering this
project "not mature enough".

I have a tidbit of information to add:

The systemd service configuration says:

ExecStartPre=/usr/bin/python3 -m synapse.app.homeserver 
--config-path=/etc/matrix-synapse/homeserver.yaml 
--config-path=/etc/matrix-synapse/conf.d/ --generate-keys

The "--generate-keys" exists in the source code Python files.

Yet if I run this command explicitly, it does nothing at all, and strace
shows it does nothing about the keys.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature


Bug#991642: kicad does not start several modules like eescheme

2021-08-01 Thread Carsten Schoenert
Hello Hans,

again, *PLEASE* use Reply All! The BTS isn't getting this information if
you just simply reply to the emails.

Am 01.08.21 um 12:40 schrieb Hans:
> Hi again,
> 
> I tried also the packages from unstable (version 5.99), but got the same 
> issue.

unstable doesn't provide 5.99 based versions, instead unstable is
holding that latest stable release 5.1.10.
Due an mistake on my side they seems to be 5.99, but the packages in
unstable are 5.1.10. Note the "really" suffix in the package full name.

5.99.0+really5.1.10+dfsg1-1

> Below I attached a screenshot of kicad, and you can see, that the first 4 
> icons are not active. Same, when you click on "Werkzeuge".
> 
> Hope this helps.

Unfortunately not really, at least on my side I can't assume anything
useful to solve this problem.

But it looks to me if the KiCad isn't recognizing the full feature set
of the graphic card and disables these options.

-- 
Regards
Carsten



Bug#981933: Reopen Bug#981933, fixed in experimental

2021-08-01 Thread Rafael Laboissière

Control: found -1 2.3.1+dfsg-8

I am hereby noting the version 2.3.1+dfsg-8 of octave-ltfat (currently 
in testing and unstable) as affected by Bug#981933.


Rafael Laboissière



Bug#991764: Debian 11 successfully installed at Asus ZenBook UX501

2021-08-01 Thread Bernhard
Package: installation-reports

Boot method: Network
Image version: Current Debian 11 Testing (RC3?)
Date: 2021-08-01

Machine: Asus Zenbook Pro UX501J
Processor: Intel(R) Core(TM) i7-4720HQ CPU @ 2.60GHz
Memory: 16GB
Partitions:

> DateisystemTyp  1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
> udev   devtmpfs   8119788   0   81197880% /dev
> tmpfs  tmpfs  16278361208   16266281% /run
> /dev/sdb2  ext4 120983240 8394836 1063965848% /
> tmpfs  tmpfs  8139180   28916   81102641% /dev/shm
> tmpfs  tmpfs 5120   4  51161% /run/lock
> /dev/sdb1  vfat523244 1485230961% /boot/efi
> tmpfs  tmpfs  1627836  52   16277841% /run/user/1000

Output of lspci -knn:

> 00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor DRAM Controller [8086:0c04] (rev 06)
>   Subsystem: ASUSTeK Computer Inc. Xeon E3-1200 v3/4th Gen Core Processor 
> DRAM Controller [1043:18dd]
>   Kernel modules: ie31200_edac
> 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor PCI Express x16 Controller [8086:0c01] (rev 06)
>   Kernel driver in use: pcieport
> 00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
> Processor Integrated Graphics Controller [8086:0416] (rev 06)
>   Subsystem: ASUSTeK Computer Inc. 4th Gen Core Processor Integrated 
> Graphics Controller [1043:18dd]
>   Kernel driver in use: i915
>   Kernel modules: i915
> 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen Core 
> Processor HD Audio Controller [8086:0c0c] (rev 06)
>   Subsystem: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD 
> Audio Controller [8086:2010]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB xHCI [8086:8c31] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB xHCI [1043:18dd]
>   Kernel driver in use: xhci_hcd
>   Kernel modules: xhci_pci
> 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 
> Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> MEI Controller [1043:18dd]
>   Kernel driver in use: mei_me
>   Kernel modules: mei_me
> 00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB EHCI #2 [8086:8c2d] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB EHCI [1043:18dd]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset 
> High Definition Audio Controller [8086:8c20] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset High 
> Definition Audio Controller [1043:18dd]
>   Kernel driver in use: snd_hda_intel
>   Kernel modules: snd_hda_intel
> 00:1c.0 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #1 [8086:8c10] (rev d5)
>   Kernel driver in use: pcieport
> 00:1c.2 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #3 [8086:8c14] (rev d5)
>   Kernel driver in use: pcieport
> 00:1c.3 PCI bridge [0604]: Intel Corporation 8 Series/C220 Series Chipset 
> Family PCI Express Root Port #4 [8086:8c16] (rev d5)
>   Kernel driver in use: pcieport
> 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset 
> Family USB EHCI #1 [8086:8c26] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> USB EHCI [1043:18dd]
>   Kernel driver in use: ehci-pci
>   Kernel modules: ehci_pci
> 00:1f.0 ISA bridge [0601]: Intel Corporation HM87 Express LPC Controller 
> [8086:8c4b] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. HM87 Express LPC Controller [1043:18dd]
>   Kernel driver in use: lpc_ich
>   Kernel modules: lpc_ich
> 00:1f.2 SATA controller [0106]: Intel Corporation 8 Series/C220 Series 
> Chipset Family 6-port SATA Controller 1 [AHCI mode] [8086:8c03] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> 6-port SATA Controller 1 [AHCI mode] [1043:18dd]
>   Kernel driver in use: ahci
>   Kernel modules: ahci
> 00:1f.3 SMBus [0c05]: Intel Corporation 8 Series/C220 Series Chipset Family 
> SMBus Controller [8086:8c22] (rev 05)
>   Subsystem: ASUSTeK Computer Inc. 8 Series/C220 Series Chipset Family 
> SMBus Controller [1043:18dd]
>   Kernel driver in use: i801_smbus
>   Kernel modules: i2c_i801
> 01:00.0 3D controller [0302]: NVIDIA Corporation GM107M [GeForce GTX 960M] 
> [10de:139b] (rev a2)
>   Subsystem: ASUSTeK Computer Inc. GM107M [GeForce GTX 

Bug#991763: ITP: golang-github-unrolled-secure -- HTTP middleware for Go that facilitates some quick security wins.

2021-08-01 Thread Alois Micard
Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-unrolled-secure
  Version : 1.0.9-1
  Upstream Author : Cory Jacobsen
* URL : https://github.com/unrolled/secure
* License : Expat
  Programming Lang: Go
  Description : HTTP middleware for Go that facilitates some quick security 
wins.

This package is needed for Traefik.
Cheers,



Bug#991762: /usr/bin/firefox: Firefox volume is reset each time it calls pulseaudio

2021-08-01 Thread Emmanuel Revah
Package: firefox-esr
Version: 78.12.0esr-1
Severity: normal
File: /usr/bin/firefox

Dear Maintainer,

   * What led up to the situation?

While playing a video I turned the volume down (in pulseaudio). Once the video 
ended, I pressed "replay" which led to the volume being reset to the original 
level.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

I removed the package `pulseaudio-equalizer`, in case, which didn't seem to 
change anything. Same for `pavucontrol` (while writing this report) which has 
no effect.

I heard about this bug from Firefox, it seems to still be open and a known 
issue.
https://bugzilla.mozilla.org/show_bug.cgi?id=1422637



-- Package-specific info:

-- Extensions information
Name: Amazon.co.uk
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Default theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled

Name: Dictionnaire français dictionary
Location: 
${PROFILE_EXTENSIONS}/fr-dicolle...@dictionaries.addons.mozilla.org.xpi
Status: enabled

Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: eBay
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Firefox Color
Location: ${PROFILE_EXTENSIONS}/firefoxco...@mozilla.com.xpi
Status: user-disabled

Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

Name: Grammalecte [fr]
Location: ${PROFILE_EXTENSIONS}/french...@grammalecte.net.xpi
Status: enabled

Name: KeePassXC-Browser
Location: ${PROFILE_EXTENSIONS}/keepassxc-brow...@keepassxc.org.xpi
Status: user-disabled

Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled

Name: Tails Verification
Location: ${PROFILE_EXTENSIONS}/{4121db26-aeba-4014-b6fe-1db322d7c585}.xpi
Status: user-disabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: uMatrix
Location: ${PROFILE_EXTENSIONS}/umat...@raymondhill.net.xpi
Status: enabled

Name: Web Compat
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled

Name: WebCompat Reporter
Location: 
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled

Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled

-- Plugins information

-- Addons package information
ii  firefox-esr78.12.0esr-1 amd64Mozilla Firefox web browser - 
Extended Support Release (ESR)

-- System Information:
Debian Release: 11.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages firefox-esr depends on:
ii  debianutils  4.11.2
ii  fontconfig   2.13.1-4.2
ii  libatk1.0-0  2.36.0-2
ii  libc62.31-13
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbus-1-3  1.12.20-2
ii  libdbus-glib-1-2 0.110-6
ii  libevent-2.1-7   2.1.12-stable-1
ii  libffi7  3.3-6
ii  libfontconfig1   2.13.1-4.2
ii  libfreetype6 2.10.4+dfsg-1
ii  libgcc-s110.2.1-6
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.8-1
ii  libgtk-3-0   3.24.24-4
ii  libnspr4 2:4.29-1
ii  libnss3  2:3.61-1
ii  libpango-1.0-0   1.46.2-3
ii  libstdc++6   10.2.1-6
ii  libvpx6  1.9.0-1
ii  libx11-6 2:1.7.1-1
ii  libx11-xcb1  2:1.7.1-1
ii  libxcb-shm0  1.14-3
ii  libxcb1  1.14-3
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.5-2
ii  libxext6 2:1.3.3-1.1
ii  libxfixes3   1:5.0.3-2
ii  libxrender1  1:0.9.10-1
ii  procps   

Bug#991761: ITP: swc -- A super-fast typescript / javascript compiler written in rust

2021-08-01 Thread Jérémy Lal
Package: wnpp
Severity: wishlist
Owner: Jérémy Lal 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-javascript-de...@alioth-lists.debian.net

* Package name: swc
  Version : 1.2.70
  Upstream Author : kdy1 
* URL : https://swc.rs/
* License : Apache-2.0 or Expat
  Programming Lang: Rust, Nodejs
  Description : A super-fast typescript / javascript compiler written in 
rust

swc is a typescript / javascript transpiler.
It consumes javascript or typescript file written in one version
of these languages and emits javascript code which can be executed
on javascript engines that are not yet supporting latest features.
.
It is an order a magnitude faster than similar projects written in
javascript.
.
It also provides spack, a full featured javascript modules bundler
that can do tree shaking among other things.

swc is a game changer for javascript development / deployment.
It can transpile, bundle, minify a large project in second(s).
It is now quite mature and usable.


Bug#991760: ITP: golang-github-unrolled-render -- Go package for easily rendering JSON, XML, binary data, and HTML templates responses.

2021-08-01 Thread Alois Micard
Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-unrolled-render
  Version : 1.4.0-1
  Upstream Author : Cory Jacobsen
* URL : https://github.com/unrolled/render
* License : Expat
  Programming Lang: Go
  Description : Go package for easily rendering JSON, XML, binary data, and 
HTML templates responses.

This package is needed for Traefik.
Cheers,



Bug#989289: pmix: diff for NMU version 4.0.0-4.1

2021-08-01 Thread Sebastian Ramacher
Dear maintainer,

I've prepared an NMU for pmix (versioned as 4.0.0-4.1). The diff
is attached to this message.

Cheers
-- 
Sebastian Ramacher
diff -Nru pmix-4.0.0/debian/changelog pmix-4.0.0/debian/changelog
--- pmix-4.0.0/debian/changelog	2021-01-20 18:30:05.0 +0100
+++ pmix-4.0.0/debian/changelog	2021-08-01 11:20:07.0 +0200
@@ -1,3 +1,13 @@
+pmix (4.0.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  [ Nobuhiro Iwamatsu ]
+  * Add libevent-dev, libhwloc-dev and zlib1g-dev to libpmix-dev's Depends
+(Closes: #989289)
+
+ -- Sebastian Ramacher   Sun, 01 Aug 2021 11:20:07 +0200
+
 pmix (4.0.0-4) unstable; urgency=medium
 
   * Add Breaks: libopenmpi3 (<< 4.1.0-3) to libpmix2 to get necessary
diff -Nru pmix-4.0.0/debian/control pmix-4.0.0/debian/control
--- pmix-4.0.0/debian/control	2021-01-20 18:30:05.0 +0100
+++ pmix-4.0.0/debian/control	2021-08-01 11:19:00.0 +0200
@@ -26,7 +26,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: ${shlibs:Depends}, ${misc:Depends}, libpmix2 (= ${binary:Version}),
+Depends: ${shlibs:Depends}, ${misc:Depends}, libpmix2 (= ${binary:Version}), libevent-dev, libhwloc-dev, zlib1g-dev
 Description: Development files for the PMI Exascale library  
  This is the OpenMPI implementation of the Process Management Interface (PMI)
  Exascale API. PMIx aims to retain transparent compatibility with the existing


signature.asc
Description: PGP signature


Bug#947688: systemd-networkd: Python socket.getfqdn() not working properly when resolv.conf lacks "domain" key

2021-08-01 Thread Dirk Heinrichs
Michael Biebl:

> On Wed, 25 Nov 2020 03:27:20 +0100 Michael Biebl 
> wrote:
>> If it's still reproducible, can you raise this upstream please at
>> https://github.com/systemd/systemd/issues 
> Any updates here?

Sorry for the delay, I always forgot to do it. It's finally there now:
https://github.com/systemd/systemd/issues/20358

Bye...

    Dirk

-- 
Dirk Heinrichs 
Matrix-Adresse: @heini:chat.altum.de
GPG Public Key: 80F1540E03A3968F3D79C382853C32C427B48049
Privacy Handbuch: https://www.privacy-handbuch.de




OpenPGP_signature
Description: OpenPGP digital signature


Bug#991759: lxc fails to start a container with xfs root after host is booted

2021-08-01 Thread Markus Iehoven
Package: lxc
Version: 1:4.0.6-2
Severity: important

Debian GNU/Linux 11 (bullseye) 5.10.0-8-amd64 #1 SMP Debian 5.10.46-3

I have a lxc container with root on a LVM volume formated to XFS. The
container can not be started after host is rebooted. look like XFS
module is not loaded at this time. modprobe xfs fixes the problem. But
I thinks that it should be done automatically

~# lxc-start -n mongo -F

lxc-start: mongo: storage/storage_utils.c: mount_unknown_fs: 298
Failed to determine FSType for "/dev/fast/mongo"
lxc-start: mongo: conf.c: lxc_mount_rootfs: 1257 Failed to mount
rootfs "/dev/fast/mongo" onto "/usr/lib/x86_64-linux-gnu/lxc/rootfs"
with options "(null)"
lxc-start: mongo: conf.c: lxc_setup_rootfs_prepare_root: 3142 Failed
to setup rootfs for
lxc-start: mongo: conf.c: lxc_setup: 3278 Failed to setup rootfs
  lxc-start: mongo: start.c: do_start: 1218 Failed to setup container "mongo"
  lxc-start: mongo: sync.c: __sync_wait: 36 An error occurred in
another process (expected sequence number 5)
  lxc-start: mongo: start.c: __lxc_start: 1999 Failed to spawn container "mongo"
lxc-start: mongo: tools/lxc_start.c: main: 308 The container failed to start
lxc-start: mongo: tools/lxc_start.c: main: 313 Additional information
can be obtained by setting the --logfile and --logpriority options

it works:
~# modprobe xfs && lxc-start -n mongo



Bug#991758: openresolv: please update to 3.8.1 to fix "Too few arguments" error

2021-08-01 Thread Dimitri Papadopoulos
Package: openresolv
Version: 3.8.0-1
Severity: important


The resolvconf script calls "/bin/systemctl --quiet is-active" without
the required argument, which fails with "Too few arguments"  error messages.

Stable Debian versions currently ship with openresolv 3.8.0. This issue
has been fixed by upstream commit 4c54816, included in version 3.8.1:
https://roy.marples.name/git/openresolv/commit/4c54816

See for example:
https://gitlab.com/openconnect/vpnc-scripts/-/issues/24
https://gitlab.com/openconnect/openconnect/-/issues/273
https://github.com/adrienverge/openfortivpn/issues/870

Best Regards,
Dimitri



Bug#991119: postsrsd security update

2021-08-01 Thread Salvatore Bonaccorso
Control: tags -1 - moreinfo

Hi Oxan,

On Thu, Jul 29, 2021 at 10:29:15PM +0200, Oxan van Leeuwen wrote:
> Hi,
> 
> On 14-07-2021 22:05, Oxan van Leeuwen wrote:
> > Hi Tomasz,
> > 
> > Another (low-severity) security update for postsrsd is required (see
> > #994039).
> > 
> > For bullseye, I've prepared a package in the master branch on Salsa. Can
> > you upload that to unstable? Given the imminent freeze I've filed an
> > unblock request (#991119).
> 
> Do you by any chance happen to have time to upload this shortly? The window
> to get the update into bullseye is closing.
> 
> Thanks!

Not sure if Tomasz is available, and given the window for aksing
unblock requests is closing very quickly I uploaded your change.

Regards,
Salvatore



Bug#991757: ITP: golang-github-traefik-yaegi -- Yaegi is Another Elegant Go Interpreter

2021-08-01 Thread Alois Micard
Package: wnpp
Severity: wishlist
Owner: Aloïs Micard 

* Package name: golang-github-traefik-yaegi
  Version : 0.9.21-1
  Upstream Author : Traefik Labs
* URL : https://github.com/traefik/yaegi
* License : Apache-2.0
  Programming Lang: Go
  Description : Yaegi is Another Elegant Go Interpreter

Yaegi is a dependency of Traefik.
Cheers,