Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

[Paul Gevers]

Hi Mike,

On 21-08-2021 23:23, Mike Hommey wrote:
>> Interesting. We heavily use lxc on ci.d.n (all tests run in one) and we
>> haven't experienced this. I'm wondering what the specifics of you
>> system(s) is that trigger the issue. Do you have ideas?
> 
> I actually don't. I have some containers that trigger it, and some that
> don't. I wasn't able to figure out why.

That doesn't make an awful good release-notes report. Have you filed the
bug somewhere (e.g. against the lxc package). I think that's probably
the better course of action than to try to figure it out with the
release notes editors.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992654: glibc breaks ruby-rugged autopkgtest: RemoteNetworkTest#test_remote_check_connection_push_credentials

[Paul Gevers]

Control: reassign -1 ruby-rugged 1.1.0+ds-4
Control: retitle -1 ruby-rugged autopkgtest regressed in Augustus 2021
Control: tag -1 - unreproducible

On 22-08-2021 00:32, Aurelien Jarno wrote:
>> With a recent upload of glibc the autopkgtest of ruby-rugged fails in
>> testing when that autopkgtest is run with the binary packages of glibc
>> from unstable. It passes when run with only packages from testing. In
>> tabular form:
>>
>>passfail
>> glibc  from testing2.31-16
>> ruby-ruggedfrom testing1.1.0+ds-4
>> versioned deps [0] from testingfrom unstable
>> all others from testingfrom testing
> 
> Unfortunately I have not been able to reproduce this behaviour.
> 
> In my testing, the autopktest failure happens already happen in pure
> testing (i.e. glibc 2.31-13), and it also appears with testing + glibc
> 2.31-16. I therefore don't believe glibc has anything to do with this
> failure.

The migration-reference/0 result on arm64 agrees with you, hence
reassigning to ruby-rugged alone.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#965169: #965169 ITA: jigl

[Joost van Baal-Ilić]

retitle 965169 ITA: jigl -- Generates a static html photo gallery from one or 
more directories of images
owner 965169 joos...@debian.org
thanks

I intend to adopt jigl.  I use it myself, and plan to keep on using it.  I
created a git repo @ g...@salsa.debian.org:debian/jigl.git , plan to start
filling it with some old .dsc's and work on a new upload from there.

Bye,

Joost

Bug#992664: ITP: ruby-parser -- Ruby parser written in pure Ruby

[Pirate Praveen]

On 22/08/21 5:04 am, Hideki Yamane wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Hideki Yamane 
> X-Debbugs-Cc: debian-de...@lists.debian.org, 
> pkg-ruby-extras-maintain...@lists.alioth.debian.org
> 
> * Package name: ruby-parser
>   Version : 3.0.2.0
> * URL : https://github.com/whitequark/parser
> * License : MIT
>   Programming Lang: Ruby
>   Description : Ruby parser written in pure Ruby
> 
>  Parser is a production-ready Ruby parser written in pure Ruby. It recognizes
>  as much or more code than Ripper, Melbourne, JRubyParser or ruby_parser, and
>  is vastly more convenient to use.
> 

This is already available as ruby-whitequark-parser (named to avoid
conflict with ruby-ruby-parser). Since ruby-parser is now
ruby-ruby-parser may be we can rename this package to ruby-parser or add
Provides: ruby-parser

https://tracker.debian.org/pkg/ruby-whitequark-parser



signature.asc
Description: OpenPGP digital signature

Bug#992152: thank you for fixing this

[Martin-Éric Racine]

Hey Michael,

Thank you for fixing this.

I don't suppose that this dependency fix could be pushed over to
Bullseye as well?

It just feels silly that exfatprogs and in-kernel exFAT support is
already in Stable, but udisks2 pulls in the FUSE-based implementation
instead.

Cheers!
Martin-Éric

Bug#992670: ibus: drop ibus-gtk and im-config to Suggests

[Martin-Éric Racine]

Package: ibus
Version: 1.5.24-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please drop the Recommends on ibus-gtk and im-config to Suggests. The GTK 
plug-in pulls in GTK2, which is deprecated, while im-config is superfluous on a 
system that uses ibus.

- -- Package-specific info:
ibus is /usr/bin/ibus
ibus-setup is /usr/bin/ibus-setup
im-config -l =>  ibus xim
im-config -m => 'xim' 'missing' 'ibus' '' 'ibus'

XMODIFIERS=
GTK_IM_MODULE=
QT_IM_MODULE=
WAYLAND_DISPLAY=
XDG_CURRENT_DESKTOP=
XDG_MENU_PREFIX=
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=
XDG_SESSION_CLASS=user
XDG_SESSION_DESKTOP=
XDG_SESSION_ID=1
XDG_SESSION_TYPE=tty

== ls -l /usr/lib/ibus/ibus-* /usr/libexec/ibus-* ==
/bin/ls: cannot access '/usr/lib/ibus/ibus-*': No such file or directory
- -rwxr-xr-x 1 root root  17948 Mar  2 22:47 /usr/libexec/ibus-dconf
- -rwxr-xr-x 1 root root  13852 Mar  2 22:47 /usr/libexec/ibus-engine-simple
- -rwxr-xr-x 1 root root 185884 Mar  2 22:47 /usr/libexec/ibus-extension-gtk3
- -rwxr-xr-x 1 root root  13852 Mar  2 22:47 /usr/libexec/ibus-memconf
- -rwxr-xr-x 1 root root  91676 Mar  2 22:47 /usr/libexec/ibus-portal
- -rwxr-xr-x 1 root root 128548 Mar  2 22:47 /usr/libexec/ibus-ui-emojier
- -rwxr-xr-x 1 root root 366132 Mar  2 22:47 /usr/libexec/ibus-ui-gtk3
- -rwxr-xr-x 1 root root 108140 Mar  2 22:47 /usr/libexec/ibus-x11

== dpkg-query -l 'ibus*' ==
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---
ii  ibus  1.5.24-1 i386 Intelligent Input Bus - core
un  ibus-anthy  (no description available)
un  ibus-array  (no description available)
un  ibus-clutter(no description available)
ii  ibus-data 1.5.24-1 all  Intelligent Input Bus - data 
files
un  ibus-doc(no description available)
un  ibus-el (no description available)
un  ibus-googlepinyin   (no description available)
un  ibus-gtk(no description available)
ii  ibus-gtk3:i3861.5.24-1 i386 Intelligent Input Bus - GTK3 
support
un  ibus-pinyin (no description available)

=== gsettings ===
org.freedesktop.ibus.general enable-by-default false
org.freedesktop.ibus.general xkb-latin-layouts ['ara', 'bg', 'cz', 'dev', 'gr', 
'gur', 'in', 'jp(kana)', 'mal', 'mkd', 'ru', 'ua']
org.freedesktop.ibus.general use-xmodmap true
org.freedesktop.ibus.general preload-engines @as []
org.freedesktop.ibus.general dconf-preserve-name-prefixes 
['/desktop/ibus/engine/pinyin', '/desktop/ibus/engine/bopomofo', 
'/desktop/ibus/engine/hangul']
org.freedesktop.ibus.general use-global-engine true
org.freedesktop.ibus.general engines-order @as []
org.freedesktop.ibus.general embed-preedit-text true
org.freedesktop.ibus.general switcher-delay-time 400
org.freedesktop.ibus.general use-system-keyboard-layout false
org.freedesktop.ibus.general version ''
org.freedesktop.ibus.general.hotkey previous-engine @as []
org.freedesktop.ibus.general.hotkey enable-unconditional @as []
org.freedesktop.ibus.general.hotkey disable-unconditional @as []
org.freedesktop.ibus.general.hotkey next-engine ['Alt+Shift_L']
org.freedesktop.ibus.general.hotkey trigger ['Control+space', 
'Zenkaku_Hankaku', 'Alt+Kanji', 'Alt+grave', 'Hangul', 'Alt+Release+Alt_R']
org.freedesktop.ibus.general.hotkey next-engine-in-menu ['Alt+Shift_L']
org.freedesktop.ibus.general.hotkey prev-engine @as []
org.freedesktop.ibus.general.hotkey triggers ['space']
org.freedesktop.ibus.panel show 0
org.freedesktop.ibus.panel show-im-name false
org.freedesktop.ibus.panel y -1
org.freedesktop.ibus.panel use-glyph-from-engine-lang true
org.freedesktop.ibus.panel show-icon-on-systray true
org.freedesktop.ibus.panel auto-hide-timeout 1
org.freedesktop.ibus.panel lookup-table-orientation 1
org.freedesktop.ibus.panel custom-font 'Sans 10'
org.freedesktop.ibus.panel xkb-icon-rgba '#415099'
org.freedesktop.ibus.panel use-custom-font false
org.freedesktop.ibus.panel property-icon-delay-time 500
org.freedesktop.ibus.panel follow-input-cursor-when-always-shown false
org.freedesktop.ibus.panel x -1
org.freedesktop.ibus.panel.emoji has-partial-match false
org.freedesktop.ibus.panel.emoji favorite-annotations @as []
org.freedesktop.ibus.panel.emoji load-unicode-at-startup false
org.freedesktop.ibus.panel.emoji partial-match-length 3
org.freedesktop.ibus.panel.emoji favorites @as []
org.freedesktop.ibus.panel.emoji hotkey ['e']
org.freedesktop.ibus.panel.emoji lang 'en'
org.freedesktop.ibus.panel.emoji font 'Monospace 16'
org.freedesktop.ibus.panel.emoji load-emoji-at-startup true
org.freedesktop.ibus.panel.emoji unicode-hotkey ['u']
org.freedes

Bug#987787: libdebuginfod-common: wrong permissions on /etc/profile.d/debuginfod.{c,}sh (and odd content)

[Paul Wise]

On Mon, 16 Aug 2021 17:13:50 +0200 наб wrote:

> Here's a debdiff, which:
>   1. installs the conffiles 644
>   2. simplifies on/off toggling
>   3. => doesn't pollute the environment with an empty DEBUGINFOD_URLS
>  when off
>   4. fixes debuginfod.csh on the csh from current sid
>  (it failed with invalid variable name on that line
> if DEBUGINFOD_URLS was already set)
>   5. fixes /bin/bash shebangs(?!) in post{inst,rm}

I think this approach is pretty convoluted, personally I would just
make the files in /etc either not exist when disabled, or symlinks into
/usr/share when enabled.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#975023: vmdb2: qemu-debootstrap after virtual-filesystems fails,Re: vmdb2: qemu-debootstrap after virtual-filesystems fails

[Ryutaroh Matsumoto]

Hi, Diederik

I redid vmdb run and again got errors as attached.
qemu-user-static are from bullseye and sid.
Both trial failed.

Best regards, Ryutaroh

From: Diederik de Haas 
Subject: Re: vmdb2: qemu-debootstrap after virtual-filesystems fails,Re: vmdb2: 
qemu-debootstrap after virtual-filesystems fails
Date: Thu, 19 Aug 2021 15:58:26 +0200,Thu, 19 Aug 2021 15:58:26 +0200

> Hi Ryutaroh Matsumoto,
> 
> On 18 Nov 2020 12:57:40 +0900 Ryutaroh Matsumoto 
>  
> wrote:
>> Package: vmdb2
>> Version: 0.19-1
>> ...
>> ii  qemu-utils  1:5.1+dfsg-4+b1
> 
> Can you check whether this issue is still reproducible with version 0.22-1?
> What qemu version are you using?
> 
> If it's 5.1, I'd like to see whether the problem still occurs with qemu 6.x, 
> which has now been uploaded to unstable.
> I'm wondering whether https://bugs.debian.org/988174 and this bug may have a 
> similar or even the same cause.
> 
> Cheers,
>   Diederik


test.log.xz
Description: Binary data


test6.log.xz
Description: Binary data

Bug#992669: python3.9-dev: python3.9-config --cflags includes -specs=/usr/share/dpkg/no-pie-compile.specs

[Mark Watts]

Package: python3.9-dev
Version: 3.9.2-1
Severity: normal
X-Debbugs-Cc: watts.mark2...@gmail.com

Dear Maintainer,

I'm using the python3.9-config --cflags to provide flags for building a
program that embeds python. I'm doing this in a Docker container with
the essential parts described by the Dockerfile excerpt below. I would
expect that any files referenced in the CFLAGS would be installed along
with python3.9-config. Instead, I have to install another package to get
this file or do a sed on cflags to remove the -specs argument.

Dockerfile:
```
FROM debian:11

ENV PYTHON_VERSION 3.9
# pkg-config is needed because, somehow, the CFLAGS in the python config script
# adds a flag that depends on a file from a package pkg-config depends on...
RUN apt-get update && \
apt-get install -y "^python${PYTHON_VERSION}-dev$" 

RUN python${PYTHON_VERSION}-config --cflags | grep -qF 
/usr/share/dpkg/no-pie-compile.specs 
RUN test -f /usr/share/dpkg/no-pie-compile.specs
```


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

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

Versions of packages python3.9-dev depends on:
ii  libexpat1-dev 2.2.10-2
ii  libpython3.9  3.9.2-1
ii  libpython3.9-dev  3.9.2-1
ii  python3.9 3.9.2-1
ii  zlib1g-dev1:1.2.11.dfsg-2

Versions of packages python3.9-dev recommends:
ii  libc6-dev [libc-dev]  2.31-16

python3.9-dev suggests no packages.

-- no debconf information

Bug#992668: ricochet-im: does not start

[The Hermit]

Package: ricochet-im
Version: 1.1.4-3+b4
Severity: normal
X-Debbugs-Cc: her...@outofoptions.com

Dear Maintainer,
Updated to Bullseye.
hermit@~:ricochet 
/usr/include/c++/9/bits/move.h:194:7: runtime error: load of value 279, which 
is not a valid value for type 'Type'


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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages ricochet-im depends on:
ii  libc62.31-13
ii  libgcc-s110.2.1-6
ii  libprotobuf233.12.4-1
ii  libqt5core5a 5.15.2+dfsg-9
ii  libqt5gui5   5.15.2+dfsg-9
ii  libqt5network5   5.15.2+dfsg-9
ii  libqt5qml5   5.15.2+dfsg-6
ii  libqt5quick5 5.15.2+dfsg-6
ii  libqt5widgets5   5.15.2+dfsg-9
ii  libssl1.11.1.1k-1
ii  libstdc++6   10.2.1-6
ii  libubsan110.2.1-6
ii  qml-module-qtmultimedia  5.15.2-3
ii  qml-module-qtquick-controls  5.15.2-2
ii  qml-module-qtquick-dialogs   5.15.2-2
ii  tor  0.4.5.9-1

ricochet-im recommends no packages.

ricochet-im suggests no packages.

-- no debconf information

Bug#992258: www.debian.org: packages.debian.org still has stable=buster and doesn't know about bullseye-security

[Daniel Lewart]

Uwe,

> looking at:
> https://packages.debian.org/search?keywords=thunderbird&searchon=names&suite=stable§ion=all
> this lists the thunderbird packages from buster, while bullseye is the
> current stable release.
> Probably related to that packages.d.o doesn't know about
> bullseye-security and bullseye-backports.

Rhonda D'Vine submitted a Merge Request for this on Aug 16:
https://salsa.debian.org/webmaster-team/packages/-/merge_requests/21

I don't know what is taking so long for it to be merged.

Daniel Lewart
Urbana, Illinois

Bug#983982: bazel-bootstrap: ftbfs with GCC-11

[Gunnar Hjalmarsson]

Control: tag -1 patch

Attached please find a relevant patch which we applied in Ubuntu. It 
contains two cherry picked commits from upstream.


However, while that patch allows bazel-bootstrap to build with gcc-11, 
autopkgtest still triggers similar errors. So there seems to be more 
into it.


--
Gunnar Hjalmarsson
Description: Include  to fix FTBFS with gcc-11
Origin:
 https://github.com/bazelbuild/bazel/commit/8cc0e261
 https://github.com/bazelbuild/bazel/commit/9761509f
Bug: https://github.com/bazelbuild/bazel/issues/12702

From: cushon 
Date: Tue, 15 Dec 2020 23:18:55 -0800
Subject: [PATCH] Include 
---
 third_party/ijar/zlib_client.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/third_party/ijar/zlib_client.h b/third_party/ijar/zlib_client.h
index ed6616362fcc..c4b051e0100c 100644
--- a/third_party/ijar/zlib_client.h
+++ b/third_party/ijar/zlib_client.h
@@ -16,6 +16,7 @@
 #define THIRD_PARTY_IJAR_ZLIB_CLIENT_H_
 
 #include 
+#include 
 
 #include "third_party/ijar/common.h"
 

From: David Ostrovsky 
Date: Wed, 16 Jun 2021 07:55:57 -0700
Subject: [PATCH] Fix building on gcc 11
---
 third_party/ijar/mapped_file_unix.cc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/third_party/ijar/mapped_file_unix.cc b/third_party/ijar/mapped_file_unix.cc
index 6e3a90871844..65179e3290ec 100644
--- a/third_party/ijar/mapped_file_unix.cc
+++ b/third_party/ijar/mapped_file_unix.cc
@@ -15,10 +15,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
+#include 
 
 #include 
+#include 
 
 #include "third_party/ijar/mapped_file.h"
 

Bug#992470: RFS: yuma123/2.12-1 -- NETCONF/YANG server/client development toolchain

[Adam Borowski]

On Thu, Aug 19, 2021 at 03:29:57AM +0200, Vladimir Vassilev wrote:
>  * Package name: yuma123
>Version : 2.12-1

>  yuma123 (2.12-1) unstable; urgency=medium
>  .
>* New upstream release.
>* Bump Standards version to 4.5.1
>* Updated homepage. Closes: #929522
>* Added "Multi-Arch: same" to -dev and module packages
   
I don't see this change...
>* Added 0005-Workaround-library-not-linked-against-libc.patch


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables
⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice.
⠈⠳⣄

Bug#992666: /usr/bin/cut: -n ignored => mangles output

[наб]

Package: coreutils
Version: 8.32-4
Severity: normal
File: /usr/bin/cut

Dear Maintainer,

POSIX.1-2008 says:
-- >8 --
-n
Do not split characters. When specified with the -b option,
each element in list of the form low-high
(-separated numbers) shall be modified as follows:

*   If the byte selected by low is not the first byte
of a character, low shall be decremented to select
the first byte of the character originally selected by low.
If the byte selected by high is not the last byte of a 
character,
high shall be decremented to select the last byte of the 
character
prior to the character originally selected by high,
or zero if there is no prior character.
If the resulting range element has high equal to zero
or low greater than high, the list element shall be
dropped from list for that input line without causing an error.

Each element in list of the form low- shall be treated as above
with high set to the number of bytes in the current line,
not including the terminating .
Each element in list of the form -high shall be treated as above
with low set to 1.
Each element in list of the form num (a single number)
shall be treated as above with low set to num and high set to num.
-- >8 --


With a more succinct exemplary text driving the point home:
-- >8 --
Earlier versions of the cut utility worked in an environment
where bytes and characters were considered equivalent
(modulo  and  processing in some implementations).
In the extended world of multi-byte characters,
the new -b option has been added.
The -n option (used with -b) allows it to be used to act on bytes
rounded to character boundaries.
The algorithm specified for -n guarantees that:
cut -b 1-500 -n file > file1
cut -b 501- -n file > file2
ends up with all the characters in file appearing exactly once
in file1 or file2. (There is, however, a  in both
file1 and file2 for each  in file.)
-- >8 --


So, compare a conforming implementation:
-- >8 --
$ printf 'яйцо\nЯЙЦО' | ./out/cmd/cut -nb 1-5
яй
ЯЙ
$ printf 'яйцо\nЯЙЦО' | ./out/cmd/cut -nb 6-
цо
ЦО
$ printf 'яйцо\nЯЙЦО' | ./out/cmd/cut -nb 1-4
яй
ЯЙ
$ printf 'яйцо\nЯЙЦО' | ./out/cmd/cut -nb 5-
цо
ЦО
$ printf 'яйцо\nЯЙЦО' | ./out/cmd/cut -nb 1-3
я
Я
$ printf 'яйцо\nЯЙЦО' | ./out/cmd/cut -nb 4-
йцо
ЙЦО
-- >8 --

With the garbage that GNU cut spews:
-- >8 --
$ printf 'яйцо\nЯЙЦО' | cut -nb 1-5
яй�
ЯЙ�
$ printf 'яйцо\nЯЙЦО' | cut -nb 6-
�о
�О
$ printf 'яйцо\nЯЙЦО' | cut -nb 1-4
яй
ЯЙ
$ printf 'яйцо\nЯЙЦО' | cut -nb 5-
цо
ЦО
$ printf 'яйцо\nЯЙЦО' | cut -nb 1-3
я�
Я�
$ printf 'яйцо\nЯЙЦО' | cut -nb 4-
�цо
�ЦО
-- >8 --

Or, without the luxury of REPLACEMENT CHARACTER:
-- >8 --
$ printf 'яйцо\nЯЙЦО' | cut -nb 1-5 | hexdump -C
  d1 8f d0 b9 d1 0a d0 af  d0 99 d0 0a  ||
000c
$ printf 'яйцо\nЯЙЦО' | cut -nb 6-  | hexdump -C
  86 d0 be 0a a6 d0 9e 0a   ||
0008
$ printf 'яйцо\nЯЙЦО' | cut -nb 1-4 | hexdump -C
  d1 8f d0 b9 0a d0 af d0  99 0a|..|
000a
$ printf 'яйцо\nЯЙЦО' | cut -nb 5-  | hexdump -C
  d1 86 d0 be 0a d0 a6 d0  9e 0a|..|
000a
$ printf 'яйцо\nЯЙЦО' | cut -nb 1-3 | hexdump -C
  d1 8f d0 0a d0 af d0 0a   ||
0008
$ printf 'яйцо\nЯЙЦО' | cut -nb 4-  | hexdump -C
  b9 d1 86 d0 be 0a 99 d0  a6 d0 9e 0a  ||
000c
-- >8 --


If we consult the manual, we can see:
-- >8 --
$ man cut | grep -C3 -- -n
  select  only  these fields;  also print any line that contains no 
delimiter character, unless the -s op‐
  tion is specified

   -n (ignored)

   --complement
  complement the set of selected bytes, characters or fields
-- >8 --

If I hadn't seen the dog-water I was given I would've assumed this
a joke; a bad one. But I have, and I don't think I can classify this
as anything but "actively malicious".

Either don't recognise -n at all or implement it.
Don't destroy the input while actively flaunting defying the standard.

наб

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 coreutils depends on:
ii  libacl1  2.2.53-10
ii  libattr1 1:2.4.48-6
ii  libc62.31-16
ii  libgmp10 2:6.2.1+dfsg-1
ii  libselinux1  3.1-3

coreutil

Bug#992606: dgit-maint-* should use 'dgit push-source' as the primary example

[Sean Whitton]

Hello,

On Sat 21 Aug 2021 at 01:45AM GMT, Osamu Aoki wrote:

> I was tired and followed dgit-maint-native without much thought.
>
>% dgit -wgf sbuild -A -c sid
>% dgit -wgf --overwrite push
>
> Then of course upload was rejected (source-only upload required).
>
>
> It looks like this is general problem for all dgit-maint-*.
>
> Considering the current Debian situation, the primary example should use
> 'push-source' instead of 'push'.  Maybe, in the following paragraph, you
> mention to use 'push' if you are in a special condition which requires
> to make the binary package upload.

Definitely.  Patches welcome.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#965823: socket: Removal of obsolete debhelper compat 5 and 6 in bookworm

[lorenzo]

On Mon, 20 Jul 2020 19:35:35 + Niels Thykier
 wrote:
> Source: socket
> Version: 1.1-10
> Severity: normal
> Usertags: compat-5-6-removal
> 
> Hi,
> 
> The package socket uses debhelper with a compat level of 5 or 6,
> which is deprecated and scheduled for removal[1].
> 
> Please bump the debhelper compat at your earliest convenience
> /outside the freeze/!
> 
>   * Compat 13 is recommended (supported in stable-backports)
> 
>   * Compat 7 is the bare minimum

> 
> At the time of filing this bug, compat 5 and 6 are expected to be
> removed "some time during the development cycle of bookworm".
> 


Hi,

is help needed/appreciated with updating this package?

Cheers,
Lorenzo

Bug#992665: json-glib: Update to 1.6.4

[Jeremy Bicha]

Source: json-glib
Version: 1.6.2-1
Severity: wishlist
Control: block -1 by 987000

GNOME has released json-glib 1.6.4 but the documentation has been
switched to gi-docgen. So we should wait for gi-docgen to be available
in Debian before packaging the update.

Thanks,
Jeremy Bicha

Bug#972999: avoid "which"

[Vincent Lefevre]

Control: severity -1 important
Control: found -1 0.0.14
Control: retitle -1 sensible-utils: replace "which" by "command -v" in 
sensible-browser, sensible-editor and sensible-pager

On 2020-10-27 05:30:46 +0100, Harald Dunkel wrote:
> To avoid problems with user-supplied "which" or bad $PATH variables
> sensible-editor should use built-ins (e.g. "type") or absolute path names.

Now "which" is deprecated and a distracting warning is displayed.
This is even more annoying as one doesn't always know where it
comes from. For instance, I get

/usr/bin/which: this version of 'which' is deprecated and should not be used.
/usr/bin/which: this version of 'which' is deprecated and should not be used.

when installing Debian packages, and I had to use strace to find out
that these warnings came from sensible-pager (via apt-listchanges).

So, raising to important.

As /usr/share/doc/debianutils/NEWS.Debian.gz says:

  * The 'which' utility will be removed in the future.  Shell scripts
often use it to check whether a command is available.  A more
standard way to do this is with 'command -v'; for example:
  if command -v update-icon-caches >/dev/null; then
update-icon-caches /usr/share/icons/...
  fi
'2>/dev/null' is unnecessary when using 'command': POSIX says "no
output shall be written" if the command isn't found.  It's also
unnecessary for the debianutils version of 'which', and hides the
deprecation warning.

So, this is easy to fix.

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

Bug#962728: F3D

[François Mazen]

Hello Sylwester,

Thanks for your interest in F3D, I'm working on the packaging of this
software [1].

The package is already on mentors [2], so let's hope that it will bring
some DD's attention! [3]

Best,
François

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985993
[2]: https://mentors.debian.net/package/f3d/
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986108




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

Bug#992523: cpio breaks perl autopkgtest on armhf and i386: realloc(): invalid next size

[Diederik de Haas]

On Thu, 19 Aug 2021 20:40:19 +0200 Paul Gevers  wrote:
> With a recent upload of cpio the autopkgtest of perl fails in testing
> when that autopkgtest is run with the binary packages of cpio from
> unstable. It passes when run with only packages from testing.

Maybe it's the same bug as https://bugs.debian.org/992192 ?
(potential) patch: https://bugs.debian.org/992192#17


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

Bug#992664: ITP: ruby-parser -- Ruby parser written in pure Ruby

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 
X-Debbugs-Cc: debian-de...@lists.debian.org, 
pkg-ruby-extras-maintain...@lists.alioth.debian.org

* Package name: ruby-parser
  Version : 3.0.2.0
* URL : https://github.com/whitequark/parser
* License : MIT
  Programming Lang: Ruby
  Description : Ruby parser written in pure Ruby

 Parser is a production-ready Ruby parser written in pure Ruby. It recognizes
 as much or more code than Ripper, Melbourne, JRubyParser or ruby_parser, and
 is vastly more convenient to use.

Bug#922550: ifupdown: network hangs for 5 minutes at startup / Failed to start Wait for network to be configured by ifupdown

[Vincent Lefevre]

I don't know whether this still occurs as I now use NetworkManager
(ifupdown 0.8.36+nmu1 is installed, and I don't see any problem,
but it is no longer used to bring up the network...).

Feel free to close the bug, assuming no-one else has the same issue
with the latest version.

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

Bug#992653: glibc breaks openconnect autopkgtest: FAIL: auth-nonascii

[Aurelien Jarno]

control: tag -1 patch

Hi,

On 2021-08-21 21:52, Paul Gevers wrote:
> Source: glibc, openconnect
> Control: found -1 glibc/2.31-16
> Control: found -1 openconnect/8.10-2
> Severity: serious
> Tags: sid bookworm
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of glibc the autopkgtest of openconnect fails in
> testing when that autopkgtest is run with the binary packages of glibc
> from unstable. It passes when run with only packages from testing. In
> tabular form:
> 
>passfail
> glibc  from testing2.31-16
> openconnectfrom testing8.10-2
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. Unfortunately,
> the log is rather brief.
> 
> Currently this regression is blocking the migration of glibc to testing
> [1]. Due to the nature of this issue, I filed this bug report against
> both packages. Can you please investigate the situation and reassign the
> bug to the right package?

The openconnect auth-nonascii test uses two locales for its tests:
cs_CZ.UTF-8 and cs_CZ.ISO8859-2. It get those locales from the
locales-all package. Starting with glibc 2.31-14, non-UTF-8 locales are
deprecated and not provided anymore by locales-all. Therefore the test
fails as the cs_CZ.ISO8859-2 is not available anymore.

One option would simply be to disable the test with the cs_CZ.ISO8859-2
locale as done in the attached patch. If non-UTF-8 locales are not
supported anymore, I don't think we need to test them.

Also please note that while this new glibc broke the openconnect
testsuite, it didn't break openconnect itself which is still functional
from the user point of view. In that regard there is no need to declare
a Breaks: openconnect on the glibc side.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net
--- openconnect-8.10.orig/tests/auth-nonascii
+++ openconnect-8.10/tests/auth-nonascii
@@ -31,7 +31,7 @@ wait_server $PID
 
 KEY=${srcdir}/certs/user-key-nonascii-password.p12
 set -x
-for CHARSET in UTF-8 ISO8859-2; do
+for CHARSET in UTF-8; do
 echo -n "Connecting to obtain cookie (with password charset ${CHARSET})... "
 CERTARGS="-c ${KEY} --key-password $(cat ${srcdir}/pass-${CHARSET})"
 ( echo "test" | LC_ALL=cs_CZ.${CHARSET} LD_PRELOAD=libsocket_wrapper.so $OPENCONNECT -q $ADDRESS:443 -u test $CERTARGS --servercert=d66b507ae074d03b02eafca40d35f87dd81049d3 --cookieonly --passwd-on-stdin ) ||


signature.asc
Description: PGP signature

Bug#852674: cfengine3: should depend on exact version of libpromises3

[Simon McVittie]

Control: severity -1 serious
Justification: Policy §3.5, §8.6.2

I happened to notice this in cfengine3's bugs list while checking
whether #992662 had already been reported.

On Thu, 26 Jan 2017 at 11:07:39 +0100, Christoph Martin wrote:
> cfengine3 depends on libpromises3 without version information.
> It should depend on the exact version which also cfengine3 has.

This is a Policy violation and can break partial upgrades, so I'm marking
it as release-critical.

> Please use
> 
> libpromises3 (= ${binary:Version})
> 
> in the control file

If libpromises3 continues to be shipped in its own binary package,
then this is an appropriate (and simple) solution. For completeness,
debian/rules should probably also pass an appropriate -V option such as
-VUpstream-Version to dh_makeshlibs.

Since libpromises3 appears to be a private library and no development
files are provided to allow other packages to link to it, another option
would be to install libpromises.so.3 into a private library directory
(perhaps by configuring with --libdir=/usr/lib/cfengine3), link
cfengine3 with an appropriate RUNPATH to be able to find it (libtool
should usually do this automatically), and ship it as part of the cfengine3
binary package instead of a separate binary package.

smcv

Bug#992663: ifupdown: spurious warning "/etc/network/interfaces does not exist"

[Vincent Lefevre]

Package: ifupdown
Version: 0.8.36+nmu1
Severity: minor

When upgrading:

Setting up ifupdown (0.8.36+nmu1) ...
Installing new version of config file /etc/init.d/networking ...
ifupdown.postinst: Warning: /etc/network/interfaces does not exist

I now use NetworkManager by default, so that /etc/network/interfaces
is not necessary. And AFAIK, the network can also be managed by
systemd.

(I'm not sure whether ifupdown is still useful, but I think that the
ifup and ifdown commands may become necessary in case of issue with
NetworkManager.)

-- Package-specific info:
--- /etc/network/interfaces:
MISSING


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

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

Versions of packages ifupdown depends on:
ii  adduser   3.118
ii  iproute2  5.13.0-2
ii  libc6 2.31-16
ii  lsb-base  11.1.0

Versions of packages ifupdown recommends:
ii  isc-dhcp-client [dhcp-client]  4.4.1-2.3

Versions of packages ifupdown suggests:
ii  ppp 2.4.9-1+1
pn  rdnssd  

-- Configuration Files:
/etc/default/networking changed:
VERBOSE=yes


-- no debconf information

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

Bug#992662: cfengine3: stores wrong path to chpasswd, etc. if built on merged-/usr system

[Simon McVittie]

Source: cfengine3
Version: 3.15.2-3
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org, Fabio Tranchitella 


If cfengine3 is built on a merged-/usr system (as created by new
installations of Debian >= 10, debootstrap --merged-usr, or installing
the usrmerge package into an existing installation), the paths to
chpasswd, useradd etc. are recorded in the binary as /sbin/chpasswd,
/sbin/useradd, etc.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/cfengine3.html
(search for "/sbin/chpasswd" to see the differences I'm concerned about).

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends-arch=usrmerge and once without.

The problematic situation is if the package is *built* on a merged-/usr
system, but *used* on a non-merged-/usr system. In this situation,
/sbin/chpasswd etc. exist on the build system but not on the system
where cfengine3 will be used, resulting in the features that use these
executables not being available.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends-arch=usrmerge.

A side benefit of fixing this is that this change seems likely to be
sufficient to make the package reproducible (as recommended by Policy
§4.15).

smcv
>From 9e28323e714949a960c88c56b99aab5d6b90f91a Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 Aug 2021 23:13:30 +0100
Subject: [PATCH] Specify canonical paths to chpasswd, etc.

If cfengine3 is built on a merged-/usr system where both /usr/bin/chpasswd
and /sbin/chpasswd exist, it will hard-code the latter into binaries,
resulting in a package that will not work correctly when used on
non-merged-/usr systems. Forcing the canonical path will make it work
on any combination of merged-/usr and non-merged-/usr build and runtime
systems, as well as improving reproducibility.

Signed-off-by: Simon McVittie 
---
 ...4-Make-it-possible-to-override-paths.patch | 46 +++
 debian/patches/series |  1 +
 debian/rules  |  4 ++
 3 files changed, 51 insertions(+)
 create mode 100644 debian/patches/cf3_path_root_prog.m4-Make-it-possible-to-override-paths.patch

diff --git a/debian/patches/cf3_path_root_prog.m4-Make-it-possible-to-override-paths.patch b/debian/patches/cf3_path_root_prog.m4-Make-it-possible-to-override-paths.patch
new file mode 100644
index ..a0eb3398
--- /dev/null
+++ b/debian/patches/cf3_path_root_prog.m4-Make-it-possible-to-override-paths.patch
@@ -0,0 +1,46 @@
+From: Simon McVittie 
+Date: Sat, 21 Aug 2021 23:13:08 +0100
+Subject: cf3_path_root_prog.m4: Make it possible to override paths
+
+CF3_PATH_ROOT_PROG is documented to have almost the same semantics as
+AC_PATH_PROG, but AC_PATH_PROG has the key feature that if the variable
+given as its first argument is set to a value, that value is used as-is.
+Give CF3_PATH_ROOT_PROG that feature too, so that we can force the paths
+for various programs to take their canonical values.
+
+Signed-off-by: Simon McVittie 
+---
+ libntech/m4/cf3_path_root_prog.m4 | 4 
+ m4/cf3_path_root_prog.m4  | 4 
+ 2 files changed, 8 insertions(+)
+
+diff --git a/libntech/m4/cf3_path_root_prog.m4 b/libntech/m4/cf3_path_root_prog.m4
+index c7fe4f9..00ed909 100644
+--- a/libntech/m4/cf3_path_root_prog.m4
 b/libntech/m4/cf3_path_root_prog.m4
+@@ -40,6 +40,10 @@ AC_DEFUN([CF3_PATH_ROOT_PROG],
+   ])
+   AS_ECHO_N(["checking for $2... "])
+   for i in $(echo $path | sed -e 's/:/ /g'); do
++AS_IF([test -n "$][$1"], [
++  found=1
++  break
++])
+ AS_IF([test -e $i/$2 && ls -ld $i/$2 | grep ['^[^ ][^ ][^ ][xs][^ ][^ ][^ ][^ ][^ ][^ ]'] > /dev/null], [
+   $1=$i/$2
+   found=1
+diff --git a/m4/cf3_path_root_prog.m4 b/m4/cf3_path_root_prog.m4
+index 8d5613f..1743acd 100644
+--- a/m4/cf3_path_root_prog.m4
 b/m4/cf3_path_root_prog.m4
+@@ -40,6 +40,10 @@ AC_DEFUN([CF3_PATH_ROOT_PROG],
+   ])
+   AS_ECHO_N(["checking for $2... "])
+   for i in $(echo $path | sed -e 's/:/ /g'); do
++AS_IF([test -n "$][$1"], [
++  found=1
++  break
++])
+ AS_IF([test -e $i/$2 && ls -ld $i/$2 | grep ['^[^ ][^ ][^ ][xs][^ ][^ ][^ ][^ ][^ ][^ ]'] > /dev/null], [
+   $1=$i/$2
+   found=1
diff --git a/debian/patches/series b/debian/patches/series
index 7ed7

Bug#992661: nfs-utils: nfs-kernel-server shouldn't be restarted on update

[Vincent Vanlaer]

Package: nfs-utils
Version: 1:1.3.4-6
Severity: normal

Dear Maintainer,

Currently, the postinst script for nfs-kernel-server restarts
nfs-kernel-server on update.  This is completely stops the NFS server,
killing all connections, as explained in rpc.nfsd(8). While clients will
reconnect, this seems to be an unnecessary interuption. Moreover, should
for some reason the NFS server fail te start, then the consequences are
more severe.

Therefore, I suggest that nfs-kernel-server/nfs-server should not but
restarted on package updates. In which way this is accomplished isn't
entirely clear to me as other services restart with nfs-server, and it
may be advised to restart those on upgrade.

Thoughts?


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

Kernel: Linux 5.13.12-arch1-1 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#992654: glibc breaks ruby-rugged autopkgtest: RemoteNetworkTest#test_remote_check_connection_push_credentials

[Aurelien Jarno]

tag: control -1 + unreproducible

On 2021-08-21 22:00, Paul Gevers wrote:
> Source: glibc, ruby-rugged
> Control: found -1 glibc/2.31-16
> Control: found -1 ruby-rugged/1.1.0+ds-4
> Severity: serious
> Tags: sid bookworm
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of glibc the autopkgtest of ruby-rugged fails in
> testing when that autopkgtest is run with the binary packages of glibc
> from unstable. It passes when run with only packages from testing. In
> tabular form:
> 
>passfail
> glibc  from testing2.31-16
> ruby-ruggedfrom testing1.1.0+ds-4
> versioned deps [0] from testingfrom unstable
> all others from testingfrom testing

Unfortunately I have not been able to reproduce this behaviour.

In my testing, the autopktest failure happens already happen in pure
testing (i.e. glibc 2.31-13), and it also appears with testing + glibc
2.31-16. I therefore don't believe glibc has anything to do with this
failure.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#992660: debian-reference-common: should not recommend debian-reference

[Vincent Lefevre]

Package: debian-reference-common
Version: 2.80
Severity: important

debian-reference-common should not recommend debian-reference, which
is a "metapackage to install (all) translations of Debian Reference".

With the current situation, if the user wants to install
debian-reference-fr, he will get debian-reference-common too
due to the Depends, then debian-reference and all the translations
due to the Recommends. In general, the user will want just one or
two language versions, not all of them! If he wants all of them,
then he should install debian-reference directly.

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

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

Versions of packages debian-reference-common depends on:
ii  sensible-utils  0.0.14

Versions of packages debian-reference-common recommends:
ii  debian-reference  2.80

Versions of packages debian-reference-common suggests:
pn  calibre 
ii  firefox [www-browser]   88.0.1-1
hi  firefox-esr [www-browser]   52.9.0esr-1~deb9u1
ii  lynx [www-browser]  2.9.0dev.9-2
pn  mc  
ii  opera-stable [www-browser]  78.0.4093.147
pn  vim 
ii  w3m [www-browser]   0.5.3+git20210102-6

-- no debconf information

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

Bug#349461: xtightvncviewer seems to ignore $HOSTALIASES as required by gethostbyname(7)

[Sven Geuer]

Control: tags -1 = unreproducible,moreinfo

On Mon, 23 Jan 2006 18:19:48 +1100 Tim Connors
 wrote:
> Package: xtightvncviewer
> Version: 1.2.9-8
> Severity: normal
> 
> I have a file $HOME/.hostaliases, with contents
> ...
> bohr vpn252-75.cc.swin.edu.au
> ...
> and have set $HOSTALIASES to $HOME/.hostaliases (see gethostbyname(7)
> for description -- it's meant to be a glibc thing)
> 
> All programs I have come across to date obey this file, except of
> course setuid progs.  xtightvncviewer is not setuid, but still seems
> to ignore me setting a display of bohr:0:
> 
> > xtightvncviewer -encodings tight -geometry 1280x1024+0+0 -passwd
/home/ssi/tconnors/.vnc/passwd  bohr:0
> ...
> Couldn't convert 'bohr' to host address
>[...]

I cannot reproduce this bug. At least with version 1:1.3.10-3
xtightvncviewer considers $HOSTALIASES and the referenced file.

Is it still an issue for? Do you have instructions for me how to
reproduce it?

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#992659: RFS: xsd/4.0.0-9 -- XML Data Binding for C++

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xsd":

   Package name: xsd
   Version : 4.0.0-9
   Upstream Author : xsd-user Maillist 
   URL : http://codesynthesis.com
   License : GPL-2+ and FLOSS, public-domain, GFDL-1.2
   Vcs : https://jff.email/cgit/xsd.git/
   Section : devel

It builds those binary packages:

  xsdcxx - XML Data Binding for C++

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/xsd/

Alternatively, one can download the package with dget using this
command:

  dget -x
https://mentors.debian.net/debian/pool/main/x/xsd/xsd_4.0.0-9.dsc

or from 

 git https://jff.email/cgit/xsd.git/?h=release/debian/4.0.0-9

Changes since the last upload:

 xsd (4.0.0-9) unstable; urgency=medium
 .
   * Migrate to debhelper 13:
 - Bump minimum debhelper-compat version in debian/control to = 13.
   * Fix FTCBFS: Use dpkg's buildtools.mk to export tools for make
 install. (Closes: #955728). Thanks to Helmut Grohne .
   * Declare compliance with Debian Policy 4.6.0.0 (No changes needed).
   * Use jdupes to change duplicate files into symlinks:
 - debian/rules: Add override_dh_link.
 - debian/control: Add Build-Depend jdupes.
 - debian/xsdcxx.lintian-overrides: Remove duplicate-files.
   * Switch to debhelper-compat:
 - debian/control: Replace debhelper with debhelper-compat.
 - Remove debian/compat.
   * debian/control:
 - Switch Vcs-* to new location.
 - Add Rules-Requires-Root: no.
   * debian/copyright:
 - Add year 2020 to debian/*.
 - Use secure URI.
 - Change Source to directory listing.
 - Add paragraph for FLOSS.
 - Fix lintian *-globbing-patterns errors.
   * debian/changelog:
 - Remove EOL before EOF.
   * Add -std=gnu++11 to CXXFLAGS to fix FTBFS with GCC-11 (Closes: #984405).


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#992648: runit: write wtmp entry at boot and shutdown

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-41
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Other inits write a wtmp entry during boot and also when shutdown or reboot
actions are requested.
Runit currently has no such feature.

Void Linux has code in its halt implementation that can write a wtmp entry
see
https://github.com/void-linux/void-runit/commit/8045334f08798ea91e25875539efb3b430ed3e99

maybe Void code can be imported in our shutdown implementation with minimal 
effort.
Another option would be to use some variation of the Void code to extend
the runit's utmpset utility.
I prefer the latter but it requires more work on my side plus in the long term
I'll have to carry on another quilt patch likely forever.. 


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.31-13
ii  sysuser-helper  1.3.5.1

Versions of packages runit recommends:
ii  runit-init  2.1.2-41

Versions of packages runit suggests:
ii  socklog  2.1.0+repack-4+b1

-- no debconf information

Bug#992658: RFS: simutrans/122.0-1 [Team] -- transportation simulator

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "simutrans":

 * Package name: simutrans
   Version : 122.0-1
   Upstream Author : [fill in name and email of upstream]
 * URL : http://www.simutrans.com/
 * License : Artistic-1.0, other, Expat, sha1-license
 * Vcs : https://salsa.debian.org/games-team/simutrans
   Section : games

It builds those binary packages:

  simutrans-makeobj - data file compiler for Simutrans
  simutrans-data - transportation simulator (base data)
  simutrans - transportation simulator

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/simutrans/

Alternatively, one can download the package with dget using this
command:

  dget -x 
https://mentors.debian.net/debian/pool/main/s/simutrans/simutrans_122.0-1.dsc

or from salsa

https://salsa.debian.org/games-team/simutrans
 

Changes since the last upload:

 simutrans (122.0-1) unstable; urgency=medium
 .
   * Team upload.
 .
   [ Jörg Frings-Fürst ]
   * New upstream release.
   * debian/simutrans-data.install:
 - Fix missing script directory (Closes: #992160).
   * debian/copyright:
 - Fix duplicate globbing patterns.
 - Add year 2021 to myself.
   * debian/simutrans-data.lintian-overrides:
 - Add override for package-contains-documentation-outside-usr-share-doc.
 - Refresh to new upstream release.
   * debian/rules:
 - Add iconv to convert txt into utf-8.
   * debian/control:
 - Change to debhelper-compat (=13).
   * Update debian/translations and convert into utf-8.
   * Declare compliance with Debian Policy 4.5.1 (No changes needed).
 .
   [ Debian Janitor ]
   * Set upstream metadata fields: Archive, Repository.


CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema: SYR8SJXB
Wire: @joergfringsfuerst
Skype: joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#919058: its-tools: crashes

[Osamu Aoki]

Control: affects 919058 - src:debmake-doc

Since debmake-doc has stopped using its-tools from 1.16-1 this is no longer 
issue.
po4a is used to handle xml.

Osamu

Bug#992657: kio: Invalid escape sequence in /usr/share/kservices5/searchproviders/rae.desktop

[Francois Marier]

Package: kio
Version: 5.83.0-2
Severity: normal

I saw the following message in my logs after starting kmymoney:

Aug 21 14:00:14 hostname /usr/libexec/gdm-x-session[1872937]: kf.config.core: 
"KConfigIni: In file /usr/share/kservices5/searchproviders/rae.desktop, line 
94: " "Invalid escape sequence
\"\\{\"."

Francois

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (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 kio depends on:
ii  kded5 5.83.0-2
ii  libacl1   2.2.53-10
ii  libc6 2.31-16
ii  libgcc-s1 11.2.0-2
ii  libgssapi-krb5-2  1.18.3-6
ii  libkf5archive55.83.0-2
ii  libkf5authcore5   5.83.0-2
ii  libkf5codecs5 5.83.0-2
ii  libkf5configcore5 5.83.0-2
ii  libkf5configwidgets5  5.83.0-3
ii  libkf5coreaddons5 5.83.0-2
ii  libkf5dbusaddons5 5.83.0-2
ii  libkf5doctools5   5.83.0-2
ii  libkf5i18n5   5.83.0-3
ii  libkf5itemviews5  5.83.0-2
ii  libkf5kiocore55.83.0-2
ii  libkf5kiogui5 5.83.0-2
ii  libkf5kiontlm55.83.0-2
ii  libkf5kiowidgets5 5.83.0-2
ii  libkf5notifications5  5.83.0-3
ii  libkf5service-bin 5.83.0-2
ii  libkf5service55.83.0-2
ii  libkf5solid5  5.83.0-2
ii  libkf5textwidgets55.83.0-2
ii  libkf5wallet-bin  5.83.0-2
ii  libkf5wallet5 5.83.0-2
ii  libkf5widgetsaddons5  5.83.0-2
ii  libkf5windowsystem5   5.83.0-2
ii  libqt5core5a  5.15.2+dfsg-10
ii  libqt5dbus5   5.15.2+dfsg-10
ii  libqt5gui55.15.2+dfsg-10
ii  libqt5network55.15.2+dfsg-10
ii  libqt5qml55.15.2+dfsg-8
ii  libqt5widgets55.15.2+dfsg-10
ii  libqt5x11extras5  5.15.2-2
ii  libqt5xml55.15.2+dfsg-10
ii  libstdc++611.2.0-2
ii  libxml2   2.9.10+dfsg-6.7
ii  libxslt1.11.1.34-4

kio recommends no packages.

kio suggests no packages.

-- no debconf information

-- 
https://fmarier.org/

Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

[Mike Hommey]

On Sat, Aug 21, 2021 at 11:19:52PM +0200, Paul Gevers wrote:
> Hi Mike,
> 
> On 21-08-2021 23:11, Mike Hommey wrote:
> > On Sat, Aug 21, 2021 at 10:50:13PM +0200, Paul Gevers wrote:
> >> Hi Mike,
> >>
> >> On 16-08-2021 22:29, Paul Gevers wrote:
> >>> Hi Mike,
> >>>
> >>> Sorry for brevity, I'm in a hurry.
> >>>
> >>> On 15-08-2021 23:08, Mike Hommey wrote:
>  The release notes has a section about the issues with openstack, but
>  there are also problems with lxc. I'm not sure what the proper
>  workaround is, but setting `lxc.mount.auto = cgroup:mixed:force` fixed
>  it for me.
> >>>
> >>> Can you elaborate what the issues are you experience with LXC?
> >>
> >> ping.
> > 
> > Sorry, I somehow missed your email.
> > 
> > Containers would just not start, with messages like:
> >   Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
> >   [!!] Failed to mount API filesystems.
> >   Exiting PID 1...
> 
> Interesting. We heavily use lxc on ci.d.n (all tests run in one) and we
> haven't experienced this. I'm wondering what the specifics of you
> system(s) is that trigger the issue. Do you have ideas?

I actually don't. I have some containers that trigger it, and some that
don't. I wasn't able to figure out why.

Mike

Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

[Paul Gevers]

Hi Mike,

On 21-08-2021 23:11, Mike Hommey wrote:
> On Sat, Aug 21, 2021 at 10:50:13PM +0200, Paul Gevers wrote:
>> Hi Mike,
>>
>> On 16-08-2021 22:29, Paul Gevers wrote:
>>> Hi Mike,
>>>
>>> Sorry for brevity, I'm in a hurry.
>>>
>>> On 15-08-2021 23:08, Mike Hommey wrote:
 The release notes has a section about the issues with openstack, but
 there are also problems with lxc. I'm not sure what the proper
 workaround is, but setting `lxc.mount.auto = cgroup:mixed:force` fixed
 it for me.
>>>
>>> Can you elaborate what the issues are you experience with LXC?
>>
>> ping.
> 
> Sorry, I somehow missed your email.
> 
> Containers would just not start, with messages like:
>   Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
>   [!!] Failed to mount API filesystems.
>   Exiting PID 1...

Interesting. We heavily use lxc on ci.d.n (all tests run in one) and we
haven't experienced this. I'm wondering what the specifics of you
system(s) is that trigger the issue. Do you have ideas?

I'm wondering if it's not related to the discussion we had in bug
985617: linux-user-namespaces. See
https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#linux-user-namespaces

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#450583: xtightvncviewer: scrollbars take realestate, but geometry can't be resized to compensate for lost realestate

[Sven Geuer]

Control: tags -1 = wontfix

On Thu, 08 Nov 2007 22:13:36 +1100 Tim Connors
 wrote:
> Package: xtightvncviewer
> Version: 1.2.9-21
> Severity: normal
> 
> I am trying to view a very wide screen on a machine with a taller but
> less wide screen.  Naturally, this causes xtightvncviewer to display
> scroll bars.  Alas, by adding a horizontal scrollbar, this takes 15 or
> so pixels from the vertical size, so it needs to add a vertical
> scrollbar as well.  If I try to get the window manager to increase the
> vertical size of the vncviewer window, vncviewer refuses to increase
> its height.  It will happily allow a decrease in height, so it appears
> to have encoded the maximum window size to the size of the framebuffer
> being displayed, without adding the necessary number of pixels that
> are taken up by a scrollbar if displayed.
> 
> [...]

On Mon, 12 Nov 2007 20:29:51 +0100 Ola Lundqvist 
wrote:
> Hi
> 
> Thanks for the report. I'll see what I can do about this. I hope
> upstream have fixed in the version that I'll update to later.
> [...]

Even with xtightvncversion 1.3.10 resizing the window does not handle
scrollbars correctly. As upstream does not maintain Tightvnc for Linux
any more, do not expect this bug being fixed some day.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

[Mike Hommey]

On Sat, Aug 21, 2021 at 10:50:13PM +0200, Paul Gevers wrote:
> Hi Mike,
> 
> On 16-08-2021 22:29, Paul Gevers wrote:
> > Hi Mike,
> > 
> > Sorry for brevity, I'm in a hurry.
> > 
> > On 15-08-2021 23:08, Mike Hommey wrote:
> >> The release notes has a section about the issues with openstack, but
> >> there are also problems with lxc. I'm not sure what the proper
> >> workaround is, but setting `lxc.mount.auto = cgroup:mixed:force` fixed
> >> it for me.
> > 
> > Can you elaborate what the issues are you experience with LXC?
> 
> ping.

Sorry, I somehow missed your email.

Containers would just not start, with messages like:
  Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted
  [!!] Failed to mount API filesystems.
  Exiting PID 1...

Mike

Bug#992192: cpio: diff for NMU version 2.13+dfsg-6.1

[Salvatore Bonaccorso]

Control: tags 992192 + patch
Control: tags 992192 + pending

Hi Anibal,

I've prepared an NMU for cpio (versioned as 2.13+dfsg-6.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Actually if you do a maintainer upload and even before that would be
welcome.

Regards,
Salvatore
diff -Nru cpio-2.13+dfsg/debian/changelog cpio-2.13+dfsg/debian/changelog
--- cpio-2.13+dfsg/debian/changelog	2021-08-13 05:06:27.0 +0200
+++ cpio-2.13+dfsg/debian/changelog	2021-08-21 22:58:50.0 +0200
@@ -1,3 +1,10 @@
+cpio (2.13+dfsg-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix dynamic string reallocations (Closes: #992192)
+
+ -- Salvatore Bonaccorso   Sat, 21 Aug 2021 22:58:50 +0200
+
 cpio (2.13+dfsg-6) unstable; urgency=high
 
   * Fix regression of original fix for CVE-2021-38185
diff -Nru cpio-2.13+dfsg/debian/patches/992192-Fix-dynamic-string-reallocations.patch cpio-2.13+dfsg/debian/patches/992192-Fix-dynamic-string-reallocations.patch
--- cpio-2.13+dfsg/debian/patches/992192-Fix-dynamic-string-reallocations.patch	1970-01-01 01:00:00.0 +0100
+++ cpio-2.13+dfsg/debian/patches/992192-Fix-dynamic-string-reallocations.patch	2021-08-21 22:58:50.0 +0200
@@ -0,0 +1,80 @@
+From: Sergey Poznyakoff 
+Date: Wed, 18 Aug 2021 09:41:39 +0300
+Subject: Fix dynamic string reallocations
+Origin: https://git.savannah.gnu.org/cgit/cpio.git/commit/?id=236684f6deb3178043fe72a8e2faca538fa2aae1
+Bug: https://lists.gnu.org/archive/html/bug-cpio/2021-08/msg5.html
+Bug-Debian: https://bugs.debian.org/992192
+
+* src/dstring.c (ds_resize): Take additional argument: number of
+bytes to leave available after ds_idx.  All uses changed.
+---
+ src/dstring.c | 18 --
+ 1 file changed, 8 insertions(+), 10 deletions(-)
+
+diff --git a/src/dstring.c b/src/dstring.c
+index b7e0bb5b5ec1..fd4e03067c25 100644
+--- a/src/dstring.c
 b/src/dstring.c
+@@ -49,9 +49,9 @@ ds_free (dynamic_string *string)
+ /* Expand dynamic string STRING, if necessary.  */
+ 
+ void
+-ds_resize (dynamic_string *string)
++ds_resize (dynamic_string *string, size_t len)
+ {
+-  if (string->ds_idx == string->ds_size)
++  while (len + string->ds_idx >= string->ds_size)
+ {
+   string->ds_string = x2nrealloc (string->ds_string, &string->ds_size,
+   1);
+@@ -63,8 +63,7 @@ ds_resize (dynamic_string *string)
+ void
+ ds_reset (dynamic_string *s, size_t len)
+ {
+-  while (len > s->ds_size)
+-s->ds_string = x2nrealloc (s->ds_string, &s->ds_size, 1);
++  ds_resize (s, len);
+   s->ds_idx = len;
+ }
+ 
+@@ -86,10 +85,10 @@ ds_fgetstr (FILE *f, dynamic_string *s, char eos)
+   /* Read the input string.  */
+   while ((next_ch = getc (f)) != eos && next_ch != EOF)
+ {
+-  ds_resize (s);
++  ds_resize (s, 0);
+   s->ds_string[s->ds_idx++] = next_ch;
+ }
+-  ds_resize (s);
++  ds_resize (s, 0);
+   s->ds_string[s->ds_idx] = '\0';
+ 
+   if (s->ds_idx == 0 && next_ch == EOF)
+@@ -101,12 +100,12 @@ ds_fgetstr (FILE *f, dynamic_string *s, char eos)
+ void
+ ds_append (dynamic_string *s, int c)
+ {
+-  ds_resize (s);
++  ds_resize (s, 0);
+   s->ds_string[s->ds_idx] = c;
+   if (c)
+ {
+   s->ds_idx++;
+-  ds_resize (s);
++  ds_resize (s, 0);
+   s->ds_string[s->ds_idx] = 0;
+ }  
+ }
+@@ -115,8 +114,7 @@ void
+ ds_concat (dynamic_string *s, char const *str)
+ {
+   size_t len = strlen (str);
+-  while (len + 1 > s->ds_size)
+-s->ds_string = x2nrealloc (s->ds_string, &s->ds_size, 1);
++  ds_resize (s, len);
+   memcpy (s->ds_string + s->ds_idx, str, len);
+   s->ds_idx += len;
+   s->ds_string[s->ds_idx] = 0;
+-- 
+2.33.0
+
diff -Nru cpio-2.13+dfsg/debian/patches/series cpio-2.13+dfsg/debian/patches/series
--- cpio-2.13+dfsg/debian/patches/series	2021-08-13 04:58:34.0 +0200
+++ cpio-2.13+dfsg/debian/patches/series	2021-08-21 22:58:50.0 +0200
@@ -14,3 +14,4 @@
 963304-remove-superfluous-declaration-of-program_name
 992045-CVE-2021-38185-rewrite-dynamic-string-support
 992098-regression-of-orig-fix-for-CVE-2021-38185
+992192-Fix-dynamic-string-reallocations.patch

Bug#992656: python3-pyx: incorrect vertical alignment of text output when using the LatexEngine

[Andre Wobst]

Package: python3-pyx
Version: 0.15-3+b3
Severity: important
Tags: upstream patch

The following example shows the alignment issue:

from pyx import *
text.set(engine=text.LatexEngine)
c = canvas.canvas()
c.text(0, 0, "Hello, world!")
c.stroke(path.line(0, 0, 2, 0))
c.writePDFfile()

This issue is caused by a change in texlive.

As upstream authors we recommand fixing this issue in Debian stable by applying
the patch in commit
https://github.com/pyx-project/pyx/commit/8d561b02e55008e4ad50ea7bdd247a1c9a58b2ee
since otherwise text output is broken for all LaTeX users. We recieved several
corresponding bug reports already.

Thanks and best regards,

Andre Wobst and Joerg Lehmann

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 python3-pyx depends on:
ii  libc6 2.31-13
ii  libkpathsea6  2020.20200327.54578-7
ii  python3   3.9.2-3

Versions of packages python3-pyx recommends:
ii  texlive-latex-base  2020.20210202-3

Versions of packages python3-pyx suggests:
ii  python3-pil8.1.2+dfsg-0.3
pn  python3-pyx-doc
ii  texlive-fonts-recommended  2020.20210202-3

-- no debconf information

Bug#347393: tightvncserver: vncserver script ignores config parameter for passwd file

[Sven Geuer]

Control: tags -1 = wontfix

On Tue, 10 Jan 2006 15:03:00 +0100 "Peter Troeger"
 wrote:
> Package: tightvncserver
> Version: 1.2.9-6
> Severity: normal
> 
> A change of the parameter "$vncPasswdFile" in /etc/vnc.conf is not
> considered by the vncserver script. Instead, it always looks for a
> password file in the user's home directory.
> 
> [...]

At least for tightvncserver 1.2.9 and higher $vncPasswdFile has never
been a variable known to the package. Not sure why you expect it.

Since tightvncserver 1.3.10 there is a system wide configuration file
/etc/tightvncserver.conf pertaining to the package. /etc/vnc.conf still
seems to be evalutated to pull in configurations of a predecessor of
tightvncserver.

Sven  

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#992655: /bin/which: this version of 'which' is deprecated and should not be used.

[Francois Marier]

Package: tiger
Version: 1:3.2.4~rc1-3
Severity: important
Tags: patch

Every time the cronjob runs, I get emails containing this:

  /bin/which: this version of 'which' is deprecated and should not be used.

This is due to a recent change in debianutils:

  * The 'which' utility will be removed in the future.  Shell scripts
often use it to check whether a command is available.  A more
standard way to do this is with 'command -v'; for example:
  if command -v update-icon-caches >/dev/null; then
update-icon-caches /usr/share/icons/...
  fi
'2>/dev/null' is unnecessary when using 'command': POSIX says "no
output shall be written" if the command isn't found.  It's also
unnecessary for the debianutils version of 'which', and hides the
deprecation warning.

https://salsa.debian.org/debian/debianutils/-/blob/5aeca1e3b14c08b5ab92995e91efcc2b3806a639/debian/NEWS#L7-16

Attached is a patch which replaces the `which` command with `command -v`.

Francois

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (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 tiger depends on:
ii  binutils   2.37-4
ii  bsdutils   1:2.37.2-1
ii  debconf [debconf-2.0]  1.5.77
ii  debianutils5.3-1
ii  libc6  2.31-16
ii  lsb-release11.1.0
ii  net-tools  1.60+git20181103.0eebece-1
ii  ucf3.0043

Versions of packages tiger recommends:
ii  chkrootkit  0.54-1+b2
pn  john
ii  postfix [mail-transport-agent]  3.5.6-1+b1
pn  tripwire | aide 

Versions of packages tiger suggests:
ii  lsof   4.93.2+dfsg-1.1
pn  lynis  

-- debconf information:
* tiger/policy_adapt:
* tiger/mail_rcpt: root
diff --git a/systems/Linux/2/gen_bootparam_sets b/systems/Linux/2/gen_bootparam_sets
index bd91690..c8c1b95 100755
--- a/systems/Linux/2/gen_bootparam_sets
+++ b/systems/Linux/2/gen_bootparam_sets
@@ -25,10 +25,10 @@
 #
 
 # If run directly do this, just in case:
-[ -z "$AWK" ] && AWK=`which awk`
-[ -z "$SED" ] && AWK=`which sed`
-[ -z "$RM" ] && RM=`which rm`
-[ -z "$YPCAT" ] && YPCAT=`which ypcat 2>/dev/null`
+[ -z "$AWK" ] && AWK=`command -v awk`
+[ -z "$SED" ] && AWK=`command -v sed`
+[ -z "$RM" ] && RM=`command -v rm`
+[ -z "$YPCAT" ] && YPCAT=`command -v ypcat`
 [ -z "$WORKDIR" ] && WORKDIR=/tmp
 
 [ -r /etc/bootparams ] && {
diff --git a/systems/Linux/2/gen_cron b/systems/Linux/2/gen_cron
index caaf498..2cc361c 100755
--- a/systems/Linux/2/gen_cron
+++ b/systems/Linux/2/gen_cron
@@ -35,9 +35,9 @@
 #-
 #
 # Defin commands we need, just in case
-[ -z "$FIND" ] && FIND=`which find` 
-[ -z "$LS" ] && LS=`which ls` 
-[ -z "$SED" ] && SED=`which sed` 
+[ -z "$FIND" ] && FIND=`command -v find` 
+[ -z "$LS" ] && LS=`command -v ls` 
+[ -z "$SED" ] && SED=`command -v sed` 
 [ -z "$CRONSPOOL" ] && CRONSPOOL="/var/spool/cron/crontabs"
 
 [ ! -n "$GETUSERHOME" ] && GETUSERHOME=echo
diff --git a/systems/Linux/2/gen_export_sets b/systems/Linux/2/gen_export_sets
index 23838f9..76b7ba3 100755
--- a/systems/Linux/2/gen_export_sets
+++ b/systems/Linux/2/gen_export_sets
@@ -23,9 +23,9 @@
 #-
 #
 # For debugging purposes
-[ -z "$GREP" ] && GREP=`which grep`
-[ -z "$SED" ] && SED=`which sed`
-[ -z "$AWK" ] && AWK=`which awk`
+[ -z "$GREP" ] && GREP=`command -v grep`
+[ -z "$SED" ] && SED=`command -v sed`
+[ -z "$AWK" ] && AWK=`command -v awk`
 [ -z "$WORKDIR" ] && WORKDIR=/tmp
 
 EXPFILE=/etc/exports
diff --git a/systems/Linux/2/gen_group_sets b/systems/Linux/2/gen_group_sets
index 93ef408..9e4cbbb 100755
--- a/systems/Linux/2/gen_group_sets
+++ b/systems/Linux/2/gen_group_sets
@@ -24,13 +24,13 @@
 #
 
 # If run directly do this, just in case:
-[ -z "$GREP" ] && GREP=`which grep`
-[ -z "$AWK" ] && AWK=`which awk`
-[ -z "$SED" ] && SED=`which sed`
-[ -z "$SORT" ] && SORT=`which sort`
-[ -z "$COMM" ] && COMM=`which comm`
-[ -z "$RM" ] && RM=`which rm`
-[ -z "$YPCAT" ] && YPCAT=`which ypcat 2>/dev/null`
+[ -z "$GREP" ] && GREP=`command -v grep`
+[ -z "$AWK" ] && AWK=`command -v awk`
+[ -z "$SED" ] && SED=`command -v sed`
+[ -z "$SORT" ] && SORT=`command -v sort`
+[ -z "$COMM" ] && COMM=`command -v comm`
+[ -z "$RM" ] && RM=`command -v rm`
+[ -z "$YPCAT" ] && YPCAT=`command -v ypcat`
 [ -z "$WORKDIR" ] && WORKDIR=/tmp
 
 
diff --git a/systems/Linux/2/gen_mounts b/systems/Linux/2/gen_mounts
index 0f3fb67..5bc3477 100755
--- a/systems/Linux/2/gen_mounts
+++ b/s

Bug#992213: release-notes: Release notes should mention lxc issues with cgroups change

[Paul Gevers]

Hi Mike,

On 16-08-2021 22:29, Paul Gevers wrote:
> Hi Mike,
> 
> Sorry for brevity, I'm in a hurry.
> 
> On 15-08-2021 23:08, Mike Hommey wrote:
>> The release notes has a section about the issues with openstack, but
>> there are also problems with lxc. I'm not sure what the proper
>> workaround is, but setting `lxc.mount.auto = cgroup:mixed:force` fixed
>> it for me.
> 
> Can you elaborate what the issues are you experience with LXC?

ping.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#983930: kmc: ftbfs with -march=x86-64-v2

[Étienne Mollier]

Control: tag -1 confirmed

Good day,

having a closer look at kmc, there is simde set up, and it looks
like enabling -march=x86-64-v2 leads through a buggy build path.
Some parts of the source code are designed to build against some
specific combinations of machine specific flags.  In the present
case, if I inject -march=x86-64-v2, and some diagnostic output,
then a mismatch appears between code targetting the specific cpu
capability sse2, caused by availability of sse4.1 in build
options:
  
In file included from kmer_counter/raduls_sse2.cpp:12:
kmer_counter/raduls_impl.h:734:2: warning: #warning 
"RADULS_RADIX_SORT_FUNNAME=RadixSortMSD_SSE41" [-Wcpp]

^
thus, explaining the error reported by Matthias:
> ./kmer_counter/kmc.h:1132: undefined reference to `void 
> RadulsSort::RadixSortMSD_SSE2 >(CKmer<2u>*, CKmer<2u>*, unsigned 
> long long, unsigned int, unsigned int, CMemoryPool*)'
> collect2: error: ld returned 1 exit status

To a larger extent, this is bound to fail with additional
symptoms when using machine types x86-64-v3, as it appends
various avx support, without mentionning various combinations
thrown by -march=native.  I see two options to mitigate this:
 1. either disable build of raduls_sse2.cpp, which is unneeded
in x86-64-v2 context, since it is overred by the sse4.1
implementation raduls_sse41.cpp any ways;
 2. or cheat with the C preprocessor macro definitions, to get
back the missing function in its sse2 only context.

Point 1 looks cleaner to me, but I only have been able to
implement point 2 successfully so far, without causing baseline
violations in normal builds, nor beating the purpose of
optimisations, and with support for further flags combinations
than just the baseline or -march=x86-64-v2.  Will push changes
on Salsa this evening, most likely.

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


signature.asc
Description: PGP signature

Bug#602934: tightvncserver: Xtightvnc creates a broken socket under /tmp/.X11-unix/

[Sven Geuer]

Control: tags -1 = unreproducible,moreinfo

Hi Lars,

On Tue, 09 Nov 2010 17:24:20 +0100 Lars  wrote:
> Package: tightvncserver
> Version: 1.3.9-6.1+b1
> Severity: normal
> 
> 
> Xtightvnc/tightvncserver creates a broken socket under /tmp/.X11-
unix/
> 
> It should create /tmp/.X11-unix/X
> 
> Example
> 
> vncserver :10
> 
> Should create /tmp/.X11-unix/X10
> 
> However it creates /tmp/.X11-unix/X1
> 
> vncserver  :19 creates X1
> vncserver  :99 creates X9
> vncserver :100 creates X10
> 
> And so on.
> 
> Thet socket /tmp/.X11-unix/X is also never removed.
> 
>[...]

I cannot reproduce this issue with tighghvncserver 1:1.3.10-3.

Do you still see it? If yes, please provide more details about your
enviroment.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#846383: grub2: add TPM support

[Vincent Bernat]

fixed 846383 2.04-18
thanks

 ❦ 21 August 2021 20:42 +02, Vincent Bernat:

>> grub2 (2.04-18) unstable; urgency=medium
>>
>>   [ Steve McIntyre ]
>>   * Enable the shim_lock and tpm modules for i386-efi too. Ensure that
>> tpm is included in our EFI images.
>>   [...]
>>
>>  -- Colin Watson   Sun, 25 Apr 2021 16:20:17 +0100
>>
>> Do we think that's enough to close this bug?
>
> Does this mean it's inside "core.efi"? I think this is not the case:
> there is a "tpm.mod" file and "strings core.efi | grep tpm" does not
> return any result. But maybe it's easy for a user to build a core.efi
> with the module added? Some users may like core.efi to be signed, but
> that's not my case.

OK, that's not the file which is used to boot with EFI. This is
/usr/lib/grub/x86_64-efi/monolithic/grubx64.efi which contains the TPM
module. So, yes, this can be closed.

-- 
Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"

Bug#598328: tightvncserver: New display number every time

[Sven Geuer]

Control: tags -1 = unreproducible,moreinfo
Hi David,

On Tue, 28 Sep 2010 11:44:51 +0200 David Moerike
 wrote:
> [...]
> 
> On AMD64, when killing the process with 
> tightvncserver -kill :n 
> or with killall Xtightvnc and again executing
> xtightvncserver 
> the display number is increased every time by one.
> 
> Problem does not occur on i386.
> 
> David Moerike

I cannot reproduce this issue with tighghvncserver 1:1.3-10-3.

Do you still see it? If yes, please provide more details about your
enviroment.

Sven

-- 
GPG Fingerprint
3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585


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

Bug#962322: python3-cherrypy3: application config loading from file fails

[Kevin Otte]

This just bit me on an upgrade from buster to bullseye 
(python3-cherrypy3 8.9.1-8):


kjotte@vesta:~/sixspot$ ./sixspot.py
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cherrypy/lib/reprconf.py", line 
213, in as_dict

value = unrepr(value)
  File "/usr/lib/python3/dist-packages/cherrypy/lib/reprconf.py", line 
518, in unrepr

return b.build(obj)
  File "/usr/lib/python3/dist-packages/cherrypy/lib/reprconf.py", line 
359, in build

raise TypeError('unrepr does not recognize %s' %
TypeError: unrepr does not recognize 'Constant'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/kjotte/svn/sixspot/trunk/./sixspot.py", line 402, in 
cherrypy.quickstart(SixSpot(),config=config_file)
  File "/usr/lib/python3/dist-packages/cherrypy/__init__.py", line 180, 
in quickstart

_global_conf_alias.update(config)
  File "/usr/lib/python3/dist-packages/cherrypy/_cpconfig.py", line 
158, in update

reprconf.Config.update(self, config)
  File "/usr/lib/python3/dist-packages/cherrypy/lib/reprconf.py", line 
155, in update

config = Parser().dict_from_file(config)
  File "/usr/lib/python3/dist-packages/cherrypy/lib/reprconf.py", line 
228, in dict_from_file

return self.as_dict()
  File "/usr/lib/python3/dist-packages/cherrypy/lib/reprconf.py", line 
219, in as_dict

raise ValueError(msg, x.__class__.__name__, x.args)
ValueError: ('Config error in section: \'global\', option: 
\'server.socket_host\', value: \'"::"\'. Config values must be valid 
Python.', 'TypeError', ("unrepr does not recognize 'Constant'",))



Any chance we can get a fix in before I upgrade my production box?

Bug#992654: glibc breaks ruby-rugged autopkgtest: RemoteNetworkTest#test_remote_check_connection_push_credentials

[Paul Gevers]

Source: glibc, ruby-rugged
Control: found -1 glibc/2.31-16
Control: found -1 ruby-rugged/1.1.0+ds-4
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of glibc the autopkgtest of ruby-rugged fails in
testing when that autopkgtest is run with the binary packages of glibc
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
glibc  from testing2.31-16
ruby-ruggedfrom testing1.1.0+ds-4
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of glibc to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
glibc/2.31-16. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=glibc

https://ci.debian.net/data/autopkgtest/testing/amd64/r/ruby-rugged/14750518/log.gz
autopkgtest [11:15:38]: test gem2deb-test-runner: [---

┌──┐
│ Checking Rubygems dependency resolution on ruby2.7
   │
└──┘

GEM_PATH= ruby2.7 -e gem\ \"rugged\"

┌──┐
│ Run tests for ruby2.7 from debian/ruby-tests.rb
   │
└──┘

mv lib .gem2deb.lib
mv ext .gem2deb.ext
RUBYLIB=. GEM_PATH= ruby2.7 debian/ruby-tests.rb
Run options: --seed 56390

# Running:

S....F...

Finished in 16.209826s, 33.8683 runs/s, 144.0484 assertions/s.

  1) Failure:
RemoteNetworkTest#test_remote_check_connection_push_credentials
[/tmp/autopkgtest-lxc.3h184rhw/downtmp/build.1At/src/test/remote_test.rb:40]:
Expected false to be truthy.

549 runs, 2335 assertions, 1 failures, 0 errors, 5 skips

You have skipped tests. Run with --verbose for details.
mv .gem2deb.lib lib
mv .gem2deb.ext ext
autopkgtest [11:15:55]: test gem2deb-test-runner: ---]




OpenPGP_signature
Description: OpenPGP digital signature

Bug#992653: glibc breaks openconnect autopkgtest: FAIL: auth-nonascii

[Paul Gevers]

Source: glibc, openconnect
Control: found -1 glibc/2.31-16
Control: found -1 openconnect/8.10-2
Severity: serious
Tags: sid bookworm
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of glibc the autopkgtest of openconnect fails in
testing when that autopkgtest is run with the binary packages of glibc
from unstable. It passes when run with only packages from testing. In
tabular form:

   passfail
glibc  from testing2.31-16
openconnectfrom testing8.10-2
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report. Unfortunately,
the log is rather brief.

Currently this regression is blocking the migration of glibc to testing
[1]. Due to the nature of this issue, I filed this bug report against
both packages. Can you please investigate the situation and reassign the
bug to the right package?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
glibc/2.31-16. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=glibc

https://ci.debian.net/data/autopkgtest/testing/amd64/o/openconnect/14748886/log.gz

autopkgtest [07:17:01]: test upstream-test-suite: [---
PASS: auth-certificate
FAIL: auth-nonascii
PASS: auth-pkcs11
PASS: auth-username-pass
PASS: id-test
autopkgtest [07:17:36]: test upstream-test-suite: ---]



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992641: shutdown.c: does not check for /run/runit.nosync

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-41
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

When called as reboot/halt/poweroff -f shutdown code does a sync(),
regardless of existence of /run/runit.nosync, then poweroff/reboot
the system without contacting the init.
However according to runit(8) 
'If  /run/runit.nosync  exists, runit doesn't invoke sync().'


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.31-13
ii  sysuser-helper  1.3.5.1

Versions of packages runit recommends:
ii  runit-init  2.1.2-41

Versions of packages runit suggests:
ii  socklog  2.1.0+repack-4+b1

-- no debconf information

Bug#991463: new upstream (5.3.2) with nsec3 (potential DoS) fixes

[Daniel Baumann]

Hi,

in the meanwhile, there's 5.4.1 out. do you need help getting the
package updated or uploaded?

Regards,
Daniel

Bug#992651: sharutils: stores wrong path to bash if built on merged-/usr system

[Simon McVittie]

Source: sharutils
Version: 1:4.15.2-5
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

If sharutils is built on a merged-/usr system (as created by new
installations of Debian >= 10, debootstrap --merged-usr, or installing
the usrmerge package into an existing installation), the path to bash
is recorded in the binary as /usr/bin/bash.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/sharutils.html
(search for "/usr/bin/bash" to see the difference I'm concerned about).

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends-arch=usrmerge and once without.

The problematic situation is if the package is *built* on a merged-/usr
system, but *used* on a non-merged-/usr system. In this situation,
/usr/bin/bash exists on the build system but not on the system where
sharutils will be used, resulting in the feature that uses bash not being
available.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

Some Debian developers advocate that instead of merged-/usr, we should
use a different strategy where /bin becomes a "symlink farm" with
individual symlinks such as /bin/bash -> /usr/bin/bash. If that route is
taken instead of merged-/usr, then resolving bugs like this one will be
equally important as part of that transition, because it shares the
property that both /bin/bash and /usr/bin/bash exist after the transition,
but only /bin/bash exists on untransitioned systems.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends-arch=usrmerge.

A side benefit of fixing this is that this change seems likely to be
sufficient to make the package reproducible (as recommended by Policy
§4.15).

smcv
>From ba667fd7e76dde2d70729a7458ffdb2d15cdf1d3 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 Aug 2021 18:49:16 +0100
Subject: [PATCH] d/rules: Specify canonical path to bash

If sharutils is built on a merged-/usr system where both /usr/bin/bash
and /bin/bash exist, it will hard-code the former into its executable,
resulting in an binary package that will not work correctly when used on
non-merged-/usr systems. Forcing the canonical path will make it work
on any combination of merged-/usr and non-merged-/usr build and runtime
systems.

Run autoreconf so that the modified m4 files are picked up.

Signed-off-by: Simon McVittie 
---
 debian/control|  2 +-
 ...t-POSIX_SHELL-from-the-environment-d.patch | 44 +++
 debian/patches/series |  1 +
 debian/rules  |  5 ++-
 4 files changed, 50 insertions(+), 2 deletions(-)
 create mode 100644 debian/patches/libopts.m4-accept-POSIX_SHELL-from-the-environment-d.patch

diff --git a/debian/control b/debian/control
index ec86070..d69acfd 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: utils
 Priority: optional
 Maintainer: Santiago Vila 
 Standards-Version: 3.9.8
-Build-Depends: debhelper (>= 9.20120311), texinfo
+Build-Depends: debhelper (>= 9.20120311), dh-autoreconf, texinfo
 Homepage: https://www.gnu.org/software/sharutils/
 Rules-Requires-Root: no
 
diff --git a/debian/patches/libopts.m4-accept-POSIX_SHELL-from-the-environment-d.patch b/debian/patches/libopts.m4-accept-POSIX_SHELL-from-the-environment-d.patch
new file mode 100644
index 000..5682187
--- /dev/null
+++ b/debian/patches/libopts.m4-accept-POSIX_SHELL-from-the-environment-d.patch
@@ -0,0 +1,44 @@
+From: Simon McVittie 
+Date: Sat, 21 Aug 2021 19:19:03 +0100
+Subject: libopts.m4: accept POSIX_SHELL from the environment during
+ the configure step
+
+This lets us set it to the canonical path /bin/bash, even on systems
+where both /bin/bash and /usr/bin/bash are available, and therefore
+which(1) might return /usr/bin/bash (depending on PATH order).
+
+Both copies of libopts.m4 are marked as generated files, but the files
+from which they were generated do not seem to be present in the sharutils
+package. This change is equivalent to part of a 2016 autogen commit
+.
+
+Origin: https://git.savannah.gnu.org/cgit/autogen.git/commit/?id=db064b9a
+---
+ libopts/m4/libopts.m4 | 1 +
+ m4/libopts.m4 | 1 +
+ 2 files changed, 2 insertions(+)
+
+diff --git a/libopts/m4/libopts.m4 b/libopts/m4/libopts.m4
+index 1a896d9..3b88

Bug#846383: grub2: add TPM support

[Vincent Bernat]

 ❦ 21 August 2021 17:45 +01, Colin Watson:

>> > We think that TPM support is a good addition to Debian because it can 
>> > increase
>> > its adoption in environments where a more secure approach to the booting is
>> > needed, by being able to securely measure if any component has been
>> > tampered.
>> 
>> It seems that Grub in Debian has now TPM support as there is a tpm.mod
>> shipped with Grub. Manual here:
>> https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html
>> 
>> The documentation suggests the module should be builtin. If not, it is a
>> bit unknown what can happen. Maybe the tpm.mod itself can be tampered?
>> 
>> Would it be possible to have the module builtin for GRUB UEFI (where
>> the size does not matter)?
>
> It already is, in bullseye:
>
> grub2 (2.04-18) unstable; urgency=medium
>
>   [ Steve McIntyre ]
>   * Enable the shim_lock and tpm modules for i386-efi too. Ensure that
> tpm is included in our EFI images.
>   [...]
>
>  -- Colin Watson   Sun, 25 Apr 2021 16:20:17 +0100
>
> Do we think that's enough to close this bug?

Does this mean it's inside "core.efi"? I think this is not the case:
there is a "tpm.mod" file and "strings core.efi | grep tpm" does not
return any result. But maybe it's easy for a user to build a core.efi
with the module added? Some users may like core.efi to be signed, but
that's not my case.
-- 
Consider well the proportions of things.  It is better to be a young June-bug
than an old bird of paradise.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Bug#992649: run-parts in /usr/bin breaks systemd-cron

[Clint Adams]

On Sat, Aug 21, 2021 at 02:12:14PM -0400, Robert Edmonds wrote:
> Hi,
> 
> systemd-cron's cron targets fail without being able to invoke
> /bin/run-parts, e.g.:
> 
> ● cron-daily.service - systemd-cron daily script service
>  Loaded: loaded (/lib/systemd/system/cron-daily.service; static)
>  Active: failed (Result: exit-code) since Sat 2021-08-21 06:25:03 
> EDT; 41ms ago
>Docs: man:systemd.cron(7)
> Process: 833540 ExecStartPre=/lib/systemd-cron/boot_delay 5 
> (code=exited, status=0/SUCCESS)
> Process: 833541 ExecStart=/bin/run-parts --report /etc/cron.daily 
> (code=exited, status=203/EXEC)
>Main PID: 833541 (code=exited, status=203/EXEC)
> CPU: 27ms
> 
> Aug 21 06:25:03 chase systemd[1]: Starting systemd-cron daily script 
> service...
> Aug 21 06:25:03 chase systemd[833541]: cron-daily.service: Failed to 
> locate executable /bin/run-parts: No such file or directory
> Aug 21 06:25:03 chase systemd[833541]: cron-daily.service: Failed at step 
> EXEC spawning /bin/run-parts: No such file or directory
> Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Main process 
> exited, code=exited, status=203/EXEC
> Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Failed with result 
> 'exit-code'.
> Aug 21 06:25:03 chase systemd[1]: Failed to start systemd-cron daily 
> script service.
> Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Triggering 
> OnFailure= dependencies.

It looks like systemd-cron is hard-coding the path to run-parts in two places:

 * cron-boot.service
 * cron-schedule.service

If this gets fixed, debianutils can add a Breaks for the appropriate
version of systemd-cron.

Bug#992650: mocha: and node-ci-info provides is-unicode-supported

[Pirate Praveen]

Package: mocha,node-ci-info
severity: important

Package node-is-unicode-supported is a virtual package provided by:
 node-ci-info 3.2.0+~cs4.2.0-1
 mocha 9.0.3+ds1+~cs30.4.31-2
You should explicitly select one to install.

I propose we drop it from mocha as it is heavier dependency. I added 
is-unicode-supported in node-ci-info as a dependency of node-tsdx which 
is still in progress. Though we will need to upload node-ci-info to 
unstable first.

Bug#992649: run-parts in /usr/bin breaks systemd-cron

[Robert Edmonds]

Package: debianutils
Version: 5.3-1
Severity: important

Hi,

systemd-cron's cron targets fail without being able to invoke
/bin/run-parts, e.g.:

● cron-daily.service - systemd-cron daily script service
 Loaded: loaded (/lib/systemd/system/cron-daily.service; static)
 Active: failed (Result: exit-code) since Sat 2021-08-21 06:25:03 EDT; 
41ms ago
   Docs: man:systemd.cron(7)
Process: 833540 ExecStartPre=/lib/systemd-cron/boot_delay 5 
(code=exited, status=0/SUCCESS)
Process: 833541 ExecStart=/bin/run-parts --report /etc/cron.daily 
(code=exited, status=203/EXEC)
   Main PID: 833541 (code=exited, status=203/EXEC)
CPU: 27ms

Aug 21 06:25:03 chase systemd[1]: Starting systemd-cron daily script 
service...
Aug 21 06:25:03 chase systemd[833541]: cron-daily.service: Failed to locate 
executable /bin/run-parts: No such file or directory
Aug 21 06:25:03 chase systemd[833541]: cron-daily.service: Failed at step 
EXEC spawning /bin/run-parts: No such file or directory
Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Main process exited, 
code=exited, status=203/EXEC
Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Failed with result 
'exit-code'.
Aug 21 06:25:03 chase systemd[1]: Failed to start systemd-cron daily script 
service.
Aug 21 06:25:03 chase systemd[1]: cron-daily.service: Triggering OnFailure= 
dependencies.

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

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

Versions of packages debianutils depends on:
ii  libc6  2.31-16

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

-- 
Robert Edmonds
edmo...@debian.org

Bug#992637: Too aggressive energy savings on kernel 5.10 cause some USB devices to malfunction

[Diederik de Haas]

Control: retitle -1 Too aggressive energy savings on kernel 5.10 cause some USB 
devices to malfunction



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

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

[Diederik de Haas]

Control: retitle -1 Too aggressive energy savings on kernel 5.10 cause some 
devices to malfunction

On zaterdag 21 augustus 2021 18:48:31 CEST Kobus van Schoor wrote:
> Thanks Diederik, that did the trick!
> After setting "Runtime PM for PCI Device Intel Corporation Sunrise
> Point-LP CSME HECI #1" to "Bad" the issue went away :)

Great! Now you've narrowed down the issue and have a workaround.

> I can just set it to "Bad", but it was running fine on "Good" on the
> previous kernels, so I guess there is still some regression here

Agreed, this is (or seems like) a regression.

> (and I don't know what this effect will now have on battery life). 

"Bad" should consume a bit more energy, but you can still keep most on "Good",
so you should still have improved battery life.

> How should I proceed, as the bug's nature has now changed?

I don't know that, hopefully more knowledgeable people will chime in.
I have retitled this bug so it better reflects the problem.
AFAICT, it's still a kernel issue. If not, someone else will probably reassign.

Cheers,
  Diederik

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

Bug#972435: amanda: Please add support for TI RPC implementation

[Aurelien Jarno]

control: tag -1 + ftbfs
control: severity -1 serious

On 2020-10-18 15:19, Aurelien Jarno wrote:
> Source: amanda
> Version: 1:3.5.1-5
> Severity: normal
> Tags: patch upstream
> 
> Dear maintainer,
> 
> The glibc SunRPC implementation has been marked obsolete for some time.
> It will get removed from glibc in version 2.32 that has been released a
> few weeks ago.  The TI RPC implementation should be used instead, which
> also brings new features (IPv6, Kerberos support, ...).
> 
> You will find attached a patch taken from Fedora to add support for the
> TI RPC implementation in case the SunRPC implementation is not
> available. Would it be possible to apply it to the Debian package so
> that amanda continues to build when the glibc SunRPC gets removed.

Now that rpc support has been removed from glibc 2.31-14, amanda fails
to build from source and needs the patch attached to this bug report to
build. I am therefore increasing the severity.

Regards,
Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#992631: runit: shutdown.c does not handle shutdown/halt overlapped flags

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-41
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Shutdown that comes with runit can be called both as 'shutdown'
or 'halt/reboot/poweroff'. Following the SysVinit implementation,
-h, -n, -f are overlapped and have a different effect with halt or
shutdown.
Runit's shutdown.c does not support -n nor -h and -f forces a reboot/poweroff
even if called with shutdown.
Also is possible to reboot the system with a combo like 'poweroff -r'
All this should be fixed.


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages runit depends on:
ii  libc6   2.31-13
ii  sysuser-helper  1.3.5.1

Versions of packages runit recommends:
ii  runit-init  2.1.2-41

Versions of packages runit suggests:
ii  socklog  2.1.0+repack-4+b1

-- no debconf information

Bug#992647: backuppc: stores wrong path to ping6 if built on merged-/usr system

[Simon McVittie]

Source: backuppc
Version: 4.4.0-4
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

If backuppc is built on a merged-/usr system (as created by new installations
of Debian >= 10, debootstrap --merged-usr, or installing the usrmerge
package into an existing installation), the path to ping6 is recorded in the
binary as /usr/bin/ping6.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/backuppc.html
(search for "ping6" to see the difference I'm concerned about).

If you have sbuild available, an easy way to reproduce this is to build
twice, once with --add-depends-arch=usrmerge and once without.

The problematic situation is if the package is *built* on a merged-/usr
system, but *used* on a non-merged-/usr system. In this situation,
/usr/bin/ping6 exists on the build system but not on the system where
backuppc will be used, resulting in the feature that uses ping6 not being
available.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

Some Debian developers advocate that instead of merged-/usr, we should
use a different strategy where /bin becomes a "symlink farm" with
individual symlinks such as /bin/ping6 -> /usr/bin/ping6. If that route is
taken instead of merged-/usr, then resolving bugs like this one will be
equally important as part of that transition, because it shares the
property that both /bin/ping6 and /usr/bin/ping6 exist after the transition,
but only /bin/ping6 exists on untransitioned systems.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends-arch=usrmerge.

A side benefit of fixing this is that this change seems to be sufficient
to make the package reproducible (as recommended by Policy §4.15).

smcv
>From 7a89355ff53e827de8f3a5b91f7ebb79d47ad1c6 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 Aug 2021 18:26:59 +0100
Subject: [PATCH] d/rules: Specify canonical path to ping6

If backuppc is built on a merged-/usr system where both /usr/bin/ping6
and /bin/ping6 exist, it will hard-code the former into configuration,
resulting in configuration that will not work correctly when used on
non-merged-/usr systems. Forcing the canonical path will make it work
on any combination of merged-/usr and non-merged-/usr build and runtime
systems.

Signed-off-by: Simon McVittie 
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index eabbf04..8b66440 100755
--- a/debian/rules
+++ b/debian/rules
@@ -34,7 +34,8 @@ override_dh_install:
 	--bin-path sendmail=/usr/sbin/sendmail \
 	--bin-path hostname=/bin/hostname --bin-path split=/usr/bin/split \
 	--bin-path par2=/usr/bin/par2 --bin-path cat=/bin/cat \
-	--bin-path gzip=/bin/gzip --bin-path bzip2=/bin/bzip2
+	--bin-path gzip=/bin/gzip --bin-path bzip2=/bin/bzip2 \
+	--bin-path ping6=/bin/ping6
 	mv -f debian/backuppc/usr/share/backuppc/cgi-bin/* debian/backuppc/usr/share/backuppc/lib/realindex.cgi
 	install --mode=755 index.cgi debian/backuppc/usr/lib/backuppc/cgi-bin
 	install --mode=755 debian/BackupPC_deleteFile debian/backuppc/usr/share/backuppc/bin
-- 
2.33.0

Bug#992612: linux-image-5.10.0-8-amd64: Macbook3,1 fails to boot without nomodeset with nouveau

[Rich]

https://forums.developer.nvidia.com/t/error-loading-nvidia-kernel-module-with-macbookpro3-1/39313

I found other threads, but apparently this is just a thing people have
found happens with nouveau or nvidia.ko if you're booting in EFI mode?

That user said they booted in BIOS emu and smuggled their vBIOS out that
way, I'll see what I can do...


On Sat, Aug 21, 2021, 6:00 AM Rich  wrote:

> Okay, so, I did just reboot and verify this...
>
> * kernel command line "... ro quiet":
> displays a blinking cursor in the top-left for a couple seconds and
> then abruptly cuts to full black, no response to VT switching or any
> other keyboard input, waited 5 minutes to see if this ever changed
>
> * kernel command line "...ro"
> displays normal output up to the aforementioned EFI VGA lines, then
> just...stops ever updating again, waited for 5m on this one too, also
> doesn't respond to VT switching or anything else
>
> https://i.imgur.com/jmcHHhm.jpg is a photo
>
> * kernel command line "...quiet nomodeset"
> We get all the way to X and are cooking
>
> As far as it's concerned, it keeps going normally after it stops
> outputting, and isn't sure why I hard power cycled it.
>
> Here's the first lines after that divergence on the "...ro" case:
>
> Aug 21 04:57:09 struth kernel: checking generic (c003 71) vs
> hw (c000 1000)
> Aug 21 04:57:09 struth kernel: fb0: switching to nouveaufb from EFI VGA
> Aug 21 04:57:09 struth kernel: hub 6-0:1.0: 2 ports detected
> Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: UHCI Host Controller
> Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: new USB bus
> registered, assigned bus number 7
> Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: detected 2 ports
> Aug 21 04:57:09 struth kernel: uhci_hcd :00:1d.2: irq 21, io base
> 0x6040
> Aug 21 04:57:09 struth kernel: Console: switching to colour dummy device
> 80x25
> Aug 21 04:57:09 struth kernel: nouveau :01:00.0: vgaarb:
> deactivate vga console
> Aug 21 04:57:09 struth kernel: usb usb7: New USB device found,
> idVendor=1d6b, idProduct=0001, bcdDevice= 5.10
> Aug 21 04:57:09 struth kernel: usb usb7: New USB device strings:
> Mfr=3, Product=2, SerialNumber=1
> Aug 21 04:57:09 struth kernel: usb usb7: Product: UHCI Host Controller
> Aug 21 04:57:09 struth kernel: usb usb7: Manufacturer: Linux
> 5.10.0-8-amd64 uhci_hcd
> Aug 21 04:57:09 struth kernel: usb usb7: SerialNumber: :00:1d.2
> Aug 21 04:57:09 struth kernel: nouveau :01:00.0: NVIDIA G84 (084700a2)
> Aug 21 04:57:09 struth kernel: hub 7-0:1.0: USB hub found
> Aug 21 04:57:09 struth kernel: hub 7-0:1.0: 2 ports detected
> Aug 21 04:57:09 struth kernel: ata4.00: ATAPI: HL-DT-ST DVDRW
> GSA-S10N, AP09, max UDMA/33
> Aug 21 04:57:09 struth kernel: nouveau :01:00.0: Invalid PCI ROM
> header signature: expecting 0xaa55, got 0x
> Aug 21 04:57:09 struth kernel: nouveau :01:00.0: bios: unable to
> locate usable image
> Aug 21 04:57:09 struth kernel: nouveau :01:00.0: bios ctor failed, -22
> Aug 21 04:57:09 struth kernel: nouveau: probe of :01:00.0 failed
> with error -22
> Aug 21 04:57:09 struth kernel: scsi 1:0:0:0: CD-ROM
> HL-DT-ST DVDRW  GSA-S10N  AP09 PQ: 0 ANSI: 5
> Aug 21 04:57:09 struth kernel: random: fast init done
> Aug 21 04:57:09 struth kernel: ata1: SATA link up 1.5 Gbps (SStatus
> 113 SControl 300)
> Aug 21 04:57:09 struth kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0
> (SET FEATURES) filtered out
> Aug 21 04:57:09 struth kernel: ata1.00: ATA-8: WDC WD2500LPVT-00G33T0,
> 01.01A01, max UDMA/133
> Aug 21 04:57:09 struth kernel: ata1.00: 488397168 sectors, multi 0:
> LBA48 NCQ (depth 32), AA
> Aug 21 04:57:09 struth kernel: ata1.00: ACPI cmd ef/10:03:00:00:00:a0
> (SET FEATURES) filtered out
> Aug 21 04:57:09 struth kernel: ata1.00: configured for UDMA/133
> Aug 21 04:57:09 struth kernel: scsi 0:0:0:0: Direct-Access ATA
>  WDC WD2500LPVT-0 1A01 PQ: 0 ANSI: 5
> Aug 21 04:57:09 struth kernel: sr 1:0:0:0: [sr0] scsi3-mmc drive:
> 24x/24x writer cd/rw xa/form2 cdda caddy
> Aug 21 04:57:09 struth kernel: cdrom: Uniform CD-ROM driver Revision: 3.20
> Aug 21 04:57:09 struth kernel: clocksource: tsc: mask:
> 0x max_cycles: 0x1fa284fbd4e, max_idle_ns:
> 440795223138 ns
> Aug 21 04:57:09 struth kernel: clocksource: Switched to clocksource tsc
> Aug 21 04:57:09 struth kernel: sr 1:0:0:0: Attached scsi CD-ROM sr0
> Aug 21 04:57:09 struth kernel: sd 0:0:0:0: [sda] 488397168 512-byte
> logical blocks: (250 GB/233 GiB)
>
>
> When we check out why Xorg doesn't ever spawn if the system keeps
> running when this happens, the Xorg.0.log diff says...
> (EE) open /dev/fb0: No such file or directory
> vesa: Refusing to run on UEFI
> (EE) Screen 0 deleted because of no matching config section.
> (II) UnloadModule: "modesetting"
> (EE) Screen 0 deleted because of no matching config section.
> (II) UnloadModule: "fbdev"
> (II) UnloadSubModule: "fbdevhw"
> (EE) Device(s) detected, but none match those in the c

Bug#992646: transition: ace

[Sudip Mukherjee]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: sudipm.mukher...@gmail.com

Hi,

Small transition with only two affected packages: diagnostics, ivtools,
Both of them builds fine with ace 7.0.3+dfsg-1 version in experimental.

The autogenerated ben tracker looks good. Please consider 'ace' for
transition.
Thanks in advance.


--
Regards
Sudip

Bug#992629: shutdown.c: FTBFS on Hurd

[Lorenzo Puliti]

Source: runit
Version: 2.1.2-41exp
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: plore...@disroot.org

According to buildd logs, the shutdown.c source fails to build
on Hurd

> debian/contrib/shutdown.c:108:10: error: ‘RB_POWER_OFF’ undeclared (first use 
> in this function)

this goes on since the shutdown.c source was introduced in runit (2.1.2-10).
Note that the build un Hurd was failing even before that because of sv test 
failure,
see
https://buildd.debian.org/status/fetch.php?pkg=runit&arch=hurd-i386&ver=2.1.2-9&stamp=1476227134&raw=0

the sv test failure can be dealt with after this one is fixed.


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

Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

-- no debconf information

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

[Kobus van Schoor]

Thanks Diederik, that did the trick! After setting "Runtime PM for PCI
Device Intel Corporation Sunrise Point-LP CSME HECI #1" to "Bad" the
issue went away :) I can just set it to "Bad", but it was running fine
on "Good" on the previous kernels, so I guess there is still some
regression here (and I don't know what this effect will now have on
battery life). How should I proceed, as the bug's nature has now
changed?

On Sat, 2021-08-21 at 18:08 +0200, Diederik de Haas wrote:
> On zaterdag 21 augustus 2021 17:38:51 CEST Kobus van Schoor wrote:
> > Enabling/disabling it however has no effect
> 
> It was worth a shot ;-)
> 
> > (it was set to "Bad" anyway).
> 
> I don't expect much from it, but you could set them all to "Bad". If
> that 
> still doesn't make a difference, then you can fully rule out energy
> savings.
> With 'lsusb -t' you can see that a/your device has a parent and it
> may be that 
> power savings on a/the parent has an effect.
> I don't expect it to make a difference, but otoh it's easy to try
> out.

Bug#846383: grub2: add TPM support

[Colin Watson]

On Sat, Aug 21, 2021 at 04:05:11PM +0200, Vincent Bernat wrote:
>  ❦ 30 November 2016 20:11 GMT, Urquiza, Fabio:
> > We think that TPM support is a good addition to Debian because it can 
> > increase
> > its adoption in environments where a more secure approach to the booting is
> > needed, by being able to securely measure if any component has been
> > tampered.
> 
> It seems that Grub in Debian has now TPM support as there is a tpm.mod
> shipped with Grub. Manual here:
> https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html
> 
> The documentation suggests the module should be builtin. If not, it is a
> bit unknown what can happen. Maybe the tpm.mod itself can be tampered?
> 
> Would it be possible to have the module builtin for GRUB UEFI (where
> the size does not matter)?

It already is, in bullseye:

grub2 (2.04-18) unstable; urgency=medium

  [ Steve McIntyre ]
  * Enable the shim_lock and tpm modules for i386-efi too. Ensure that
tpm is included in our EFI images.
  [...]

 -- Colin Watson   Sun, 25 Apr 2021 16:20:17 +0100

Do we think that's enough to close this bug?

-- 
Colin Watson (he/him)  [cjwat...@debian.org]

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Clint Adams]

On Sat, Aug 21, 2021 at 06:30:21PM +0200, Eric Valette wrote:
> And for the sake of completeness, I already did merge. Just no remembered
> it! So even for merged / and /usr system there is a bug unless usrmerge is
> installed.

I'm confused.  You installed usrmerge but then deleted the /sbin symlink?

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Eric Valette]

I do not mind deciding everything should be in /usr but as pointed out 
there are other project that should adapt.


And for the sake of completeness, I already did merge. Just no 
remembered it! So even for merged / and /usr system there is a bug 
unless usrmerge is installed.


-- eric

Bug#992645: ncftp: stores wrong path to tar if built on merged-/usr system

[Simon McVittie]

Source: ncftp
Version: 2:3.2.5-2.2
Severity: important
Tags: patch bookworm sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: usrmerge
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

If ncftp is built on a merged-/usr system (as created by new installations
of Debian >= 10, debootstrap --merged-usr, or installing the usrmerge
package into an existing installation), the path to tar is recorded in the
binary as /usr/bin/tar.

This can be seen on the reproducible-builds.org infra:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/ncftp.html
(search for "/bin/tar" to see the difference I'm concerned about).

If you have sbuild available, an easy way to reproduce this is to build
ncftp twice, once with --add-depends-arch=usrmerge and once without.

The problematic situation is if pkgconf is *built* on a merged-/usr
system, but *used* on a non-merged-/usr system. In this situation,
/usr/bin/tar exists on the build system but not on the system where
ncftp will be used, resulting in the feature that uses tar not being
available.

Technical Committee resolution #978636 mandates heading towards a
transition to merged-/usr, and this will become a non-issue at the end of
that transition; but variation between merged-/usr and non-merged-/usr
builds is a problem while that transition is taking place, because it
can lead to partial upgrades behaving incorrectly. It is likely that
this class of bugs will become release-critical later in the bookworm
development cycle.

Some Debian developers advocate that instead of merged-/usr, we should
use a different strategy where /bin becomes a "symlink farm" with
individual symlinks such as /bin/tar -> /usr/bin/tar. If that route is
taken instead of merged-/usr, then resolving bugs like this one will be
equally important as part of that transition, because it shares the
property that both /bin/tar and /usr/bin/tar exist after the transition,
but only /bin/tar exists on untransitioned systems.

The attached patch resolves this: with it applied, the package builds
identically with and without --add-depends-arch=usrmerge.

A side benefit of fixing this is that this change might be sufficient
to make the package reproducible (as recommended by Policy §4.15).

smcv
>From 252c7fdcee3fa2548bc8246849aa3dc280169992 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 Aug 2021 16:50:49 +0100
Subject: [PATCH] d/rules: Specify canonical path to tar

If ncftp is built on a merged-/usr system, then tar is available at
both /usr/bin/tar and /bin/tar, but if it is subsequently used on a
non-merged-/usr system, only /bin/tar will work. Force the canonical
path /bin/tar so that the layout of the build system does not matter.

Signed-off-by: Simon McVittie 
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index 5b12238..a0410b4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -21,6 +21,7 @@ config.status:
 	dh_testdir
 	cp /usr/share/misc/config.guess /usr/share/misc/config.sub .
 	# Add here commands to configure the package.
+	TAR=/bin/tar \
 	CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)" ./configure \
 		--prefix=/usr \
 		--mandir=\$${prefix}/share/man \
-- 
2.33.0

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Eric Valette]

On 21/08/2021 18:09, Clint Adams wrote:

On Sat, Aug 21, 2021 at 06:04:33PM +0200, Eric Valette wrote:

if you expect to have unconditionally it make a depends and people with not
enough place to merge / and /usr will explain you maybe not politely you
broke their system...


That would make it impossible to purge usrmerge after install, which would
be unfortunate.


For my personnal case, On a NAS with only remote access, repartioning on the
fly is a bit tricky and that has been live for about 8 years...


What is your plan?  Keep running sid on your NAS until 2 years from now and
then never upgrade again when unmerged /usr is completely unsupported in the
stable release?



Avoid to make the merge as long as possible until everyting is fixed 
everywhere. Recent changes did broke various things if I look at 
critical bug. It also broke at least my laptop with no way to enter X11 
(and here / and /usr are already merged).


The location is incorrect anyway unless upstream kernel explicitly makes 
a change.


I do not mind deciding everything should be in /usr but as pointed out 
there are other project that should adapt.


-- eric

Bug#992644: RM: tokyotyrant -- RoQA; Orphaned; Useless; Upstream Vanished

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: z...@debian.org car...@debian.org

Dear FTP Masters,

As discussed in https://bugs.debian.org/980331 , package tokyotryant in Sid is
not useful anymore. Now that all its reverse dependencies and reverse build-
dependencies have disappeared, we may consider removing this package from
Debian Unstable.

Its popcon value is still pretty high (1807) mainly because collectd
previously depends on it. Recent collectd package in Debian 11 and later has
removed such dependency.

Thanks,
Boyuan Yang


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

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

[Diederik de Haas]

On zaterdag 21 augustus 2021 17:38:51 CEST Kobus van Schoor wrote:
> Enabling/disabling it however has no effect

It was worth a shot ;-)

> (it was set to "Bad" anyway).

I don't expect much from it, but you could set them all to "Bad". If that 
still doesn't make a difference, then you can fully rule out energy savings.
With 'lsusb -t' you can see that a/your device has a parent and it may be that 
power savings on a/the parent has an effect.
I don't expect it to make a difference, but otoh it's easy to try out.

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

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Clint Adams]

On Sat, Aug 21, 2021 at 06:04:33PM +0200, Eric Valette wrote:
> if you expect to have unconditionally it make a depends and people with not
> enough place to merge / and /usr will explain you maybe not politely you
> broke their system...

That would make it impossible to purge usrmerge after install, which would
be unfortunate.

> For my personnal case, On a NAS with only remote access, repartioning on the
> fly is a bit tricky and that has been live for about 8 years...

What is your plan?  Keep running sid on your NAS until 2 years from now and
then never upgrade again when unmerged /usr is completely unsupported in the
stable release?

Bug#992643: RM: ircp-tray -- RoQA; No longer supported by kernel; Unmaintained

[Boyuan Yang]

Package: ftp.debian.org
X-Debbugs-Cc: by...@debian.org d.fil...@ubuntu.com
Severity: normal

Dear Debian FTP Masters,

As discussed in https://bugs.debian.org/906474 , linux kernel after Buster no
longer support IrDA. This makes ircp-tray package no longer useful and would
FTBFS due to missing header.

The upstream developer suggested in https://bugs.debian.org/906474 to remove
this package from archive. Besides, the current maintainer of package ircp-
tray (in cc list) did not maintain this package in the past 10 years. As a
result, I believe it is reasonable to request removal of package ircp-tray
from unstable now.

-- 
Regards,
Boyuan Yang


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

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Eric Valette]

On 21/08/2021 17:56, Clint Adams wrote:

On Sat, Aug 21, 2021 at 05:51:06PM +0200, Eric Valette wrote:

But as nobody makes the link, there is a problem by default.


https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#178

As soon as you install the usrmerge package you should be fine.



if you expect to have unconditionally it make a depends and people with 
not enough place to merge / and /usr will explain you maybe not politely 
you broke their system...


For my personnal case, On a NAS with only remote access, repartioning on 
the fly is a bit tricky and that has been live for about 8 years...


-- eric

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Clint Adams]

On Sat, Aug 21, 2021 at 05:51:06PM +0200, Eric Valette wrote:
> But as nobody makes the link, there is a problem by default.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#178

As soon as you install the usrmerge package you should be fine.

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Eric Valette]

On 21/08/2021 17:48, Clint Adams wrote:

On Sat, Aug 21, 2021 at 05:45:48PM +0200, Eric Valette wrote:

But upstream kernel look explicitely in /sbin so there will be a problem...

/usr/src/linux-zotac-h67itx# sh -x
/usr/src/linux-5.10.7/arch/x86/boot/install.sh 5.10.60 arch/x86/boot/bzImage
System.map "/boot"
+ verify arch/x86/boot/bzImage
+ '[' '!' -f arch/x86/boot/bzImage ']'
+ verify System.map
+ '[' '!' -f System.map ']'
+ '[' -x /root/bin/installkernel ']'
+ '[' -x /sbin/installkernel ']'
+ exec /sbin/installkernel 5.10.60 arch/x86/boot/bzImage System.map /boot


Once your /sbin is a symlink to usr/sbin, that problem will go away.



But as nobody makes the link, there is a problem by default.


-- eric

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Eric Valette]

On 21/08/2021 17:45, Eric Valette wrote:

On 21/08/2021 17:43, Clint Adams wrote:

On Sat, Aug 21, 2021 at 05:34:58PM +0200, Eric Valette wrote:

root@nas2:/usr/src/linux# ls -l /sbin/installkernel <== manually copied
-rwxr-xr-x 1 root root 2659 21 août  17:24 /sbin/installkernel
root@nas2:/usr/src/linux# ls -l /usr/sbin/installkernel
-rwxr-xr-x 1 root root 2659 20 août  13:31 /usr/sbin/installkernel

I suspect  the link is a hard link that does not work on different 
filesystem use -s


No, there is no link; unmerged /usr won't be supported for bookworm.




But upstream kernel look explicitely in /sbin so there will be a problem...

/usr/src/linux-zotac-h67itx# sh -x 
/usr/src/linux-5.10.7/arch/x86/boot/install.sh 5.10.60 
arch/x86/boot/bzImage System.map "/boot"

+ verify arch/x86/boot/bzImage
+ '[' '!' -f arch/x86/boot/bzImage ']'
+ verify System.map
+ '[' '!' -f System.map ']'
+ '[' -x /root/bin/installkernel ']'
+ '[' -x /sbin/installkernel ']'
+ exec /sbin/installkernel 5.10.60 arch/x86/boot/bzImage System.map /boot


removing the link in /sbin gives:

sh -x /usr/src/linux-5.10.7/arch/x86/boot/install.sh 5.10.60 
arch/x86/boot/bzImage System.map "/boot"

+ verify arch/x86/boot/bzImage
+ '[' '!' -f arch/x86/boot/bzImage ']'
+ verify System.map
+ '[' '!' -f System.map ']'
+ '[' -x /root/bin/ ']'
+ '[' -x /sbin/ ']'
+ '[' -f /boot/vmlinuz ']'
+ mv /boot/vmlinuz /boot/vmlinuz.old
+ '[' -f /boot/System.map ']'
+ mv /boot/System.map /boot/System.old
+ cat arch/x86/boot/bzImage
+ cp System.map /boot/System.map
+ '[' -x /sbin/lilo ']'
+ '[' -x /etc/lilo/install ']'
+ sync
+ echo 'Cannot find LILO.'
Cannot find LILO.

-- eric

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Clint Adams]

On Sat, Aug 21, 2021 at 05:34:58PM +0200, Eric Valette wrote:
> root@nas2:/usr/src/linux# ls -l /sbin/installkernel <== manually copied
> -rwxr-xr-x 1 root root 2659 21 août  17:24 /sbin/installkernel
> root@nas2:/usr/src/linux# ls -l /usr/sbin/installkernel 
> -rwxr-xr-x 1 root root 2659 20 août  13:31 /usr/sbin/installkernel
> 
> I suspect  the link is a hard link that does not work on different filesystem 
> use -s

No, there is no link; unmerged /usr won't be supported for bookworm.

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Clint Adams]

On Sat, Aug 21, 2021 at 05:45:48PM +0200, Eric Valette wrote:
> But upstream kernel look explicitely in /sbin so there will be a problem...
> 
> /usr/src/linux-zotac-h67itx# sh -x
> /usr/src/linux-5.10.7/arch/x86/boot/install.sh 5.10.60 arch/x86/boot/bzImage
> System.map "/boot"
> + verify arch/x86/boot/bzImage
> + '[' '!' -f arch/x86/boot/bzImage ']'
> + verify System.map
> + '[' '!' -f System.map ']'
> + '[' -x /root/bin/installkernel ']'
> + '[' -x /sbin/installkernel ']'
> + exec /sbin/installkernel 5.10.60 arch/x86/boot/bzImage System.map /boot

Once your /sbin is a symlink to usr/sbin, that problem will go away.

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Eric Valette]

On 21/08/2021 17:43, Clint Adams wrote:

On Sat, Aug 21, 2021 at 05:34:58PM +0200, Eric Valette wrote:

root@nas2:/usr/src/linux# ls -l /sbin/installkernel <== manually copied
-rwxr-xr-x 1 root root 2659 21 août  17:24 /sbin/installkernel
root@nas2:/usr/src/linux# ls -l /usr/sbin/installkernel
-rwxr-xr-x 1 root root 2659 20 août  13:31 /usr/sbin/installkernel

I suspect  the link is a hard link that does not work on different filesystem 
use -s


No, there is no link; unmerged /usr won't be supported for bookworm.




But upstream kernel look explicitely in /sbin so there will be a problem...

/usr/src/linux-zotac-h67itx# sh -x 
/usr/src/linux-5.10.7/arch/x86/boot/install.sh 5.10.60 
arch/x86/boot/bzImage System.map "/boot"

+ verify arch/x86/boot/bzImage
+ '[' '!' -f arch/x86/boot/bzImage ']'
+ verify System.map
+ '[' '!' -f System.map ']'
+ '[' -x /root/bin/installkernel ']'
+ '[' -x /sbin/installkernel ']'
+ exec /sbin/installkernel 5.10.60 arch/x86/boot/bzImage System.map /boot


-- eric

Bug#992642: rust-grep-matcher: binary uploads from buildds rejected

[Adrian Bunk]

Source: rust-grep-matcher
Version: 0.1.5-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=rust-grep-matcher&suite=sid

bunk@coccia:~$ cat 
/srv/ftp-master.debian.org/queue/reject/rust-grep-matcher_0.1.5-1_amd64-buildd.changes.reason

librust-grep-matcher-dev_0.1.5-1_amd64.deb: has 8 file(s) with a timestamp too 
far in the past:
  usr/share/cargo/registry/grep-matcher-0.1.5/LICENSE-MIT (Thu Nov 29 21:33:09 
1973)  usr/share/cargo/registry/grep-matcher-0.1.5/README.md (Thu Nov 29 
21:33:09 1973)  usr/share/cargo/registry/grep-matcher-0.1.5/UNLICENSE (Thu Nov 
29 21:33:09 1973)  
usr/share/cargo/registry/grep-matcher-0.1.5/src/interpolate.rs (Thu Nov 29 
21:33:09 1973)  usr/share/cargo/registry/grep-matcher-0.1.5/src/lib.rs (Thu Nov 
29 21:33:09 1973)  
usr/share/cargo/registry/grep-matcher-0.1.5/tests/test_matcher.rs (Thu Nov 29 
21:33:09 1973)  usr/share/cargo/registry/grep-matcher-0.1.5/tests/tests.rs (Thu 
Nov 29 21:33:09 1973)  
usr/share/cargo/registry/grep-matcher-0.1.5/tests/util.rs (Thu Nov 29 21:33:09 
1973)
bunk@coccia:~$

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

[Kobus van Schoor]

Thank you for the suggestion, I booted the old kernel and the new
kernel and compared their tuneables screen to check for differences -
on the new kernel there is a setting "Autosuspend for USB device DSO-
6022BE [OpenHantek]" (which is the device in question) which wasn't
present on the old kernel. Enabling/disabling it however has no effect
(it was set to "Bad" anyway). The only other difference between the
kernels is the runtime pm for my audio controller (which also didn't
make a difference).

On Sat, 2021-08-21 at 16:57 +0200, Diederik de Haas wrote:
> On zaterdag 21 augustus 2021 16:42:21 CEST Kobus van Schoor wrote:
> > - My battery lasts significantly longer after upgrading to bullseye
> > (around 2 hours extra I would guess). I'm not sure if there is now
> > extra power saving features present in the kernel which might be
> > interfering with my USB bus.
> 
> With 'powertop' there's a screen named 'Tunables' and there you can
> enable or 
> disable various power related settings.
> Where there previously was a whole list of settings I had to manually
> enable, 
> since recently they're all enabled by default. In my case I disable a
> setting 
> wrt my mouse otherwise it responds poorly.
> 
> With 'lsusb [-t]' you should be able to detect where your device is
> connected 
> to and find a matching tunable in powertop and see whether that
> helps.

Bug#992639: debianutils: move of installkernel to /usr/sbin/installkernel breaks kernel build on system with separate / and /usr

[Eric Valette]

Package: debianutils
Version: 5.3-1
Severity: normal

root@nas2:/usr/src/linux# ls -l /sbin/installkernel <== manually copied
-rwxr-xr-x 1 root root 2659 21 août  17:24 /sbin/installkernel
root@nas2:/usr/src/linux# ls -l /usr/sbin/installkernel 
-rwxr-xr-x 1 root root 2659 20 août  13:31 /usr/sbin/installkernel

I suspect  the link is a hard link that does not work on different filesystem 
use -s


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

Kernel: Linux 5.10.60 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages debianutils depends on:
ii  libc6  2.31-16

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

Bug#992617: xserver-xorg-video-radeon: Screen rotate doesn't work

[Kari Pahula]

On Sat, Aug 21, 2021 at 12:17:02PM +0200, Michel Dänzer wrote:
> > DRM Information from dmesg:
> > ---
> > 
> > 
> 
> Since there are no DRM driver related messages in dmesg, looks like
> something is preventing the radeon kernel driver from loading at
> all. If you're passing nomodeset on the kernel command line, remove
> that. Otherwise, full dmesg output would be needed to diagnose.

I'm not using nomodeset.  I've attached a dump from dmesg after a
reboot.  That "ring 0 stalled" message doesn't look promising at all.

Actually, when I first tried running startx it just stopped after
showing the initial log messages to tty, while occasionally blinking
my screens black.  I did a kill -9 on the Xorg process and then startx
worked when I tried it again, but I guess it gave up on any
acceleration at that point.

I tried booting the last kernel I had (linux-image-5.10.0-4) and the
one from Buster but those didn't solve anything.
[0.00] Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) 
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 
2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03)
[0.00] Command line: BOOT_IMAGE=/vmlinuz-5.10.0-8-amd64 
root=/dev/mapper/corsair-root ro quiet
[0.00] random: get_random_u32 called from bsp_init_amd+0x284/0x2c0 with 
crng_init=0
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xba6e9fff] usable
[0.00] BIOS-e820: [mem 0xba6ea000-0xba719fff] reserved
[0.00] BIOS-e820: [mem 0xba71a000-0xba729fff] ACPI data
[0.00] BIOS-e820: [mem 0xba72a000-0xbb531fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbb532000-0xbca33fff] reserved
[0.00] BIOS-e820: [mem 0xbca34000-0xbca34fff] usable
[0.00] BIOS-e820: [mem 0xbca35000-0xbcc3afff] ACPI NVS
[0.00] BIOS-e820: [mem 0xbcc3b000-0xbd082fff] usable
[0.00] BIOS-e820: [mem 0xbd083000-0xbd7f3fff] reserved
[0.00] BIOS-e820: [mem 0xbd7f4000-0xbd7f] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfec2-0xfec20fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed61000-0xfed70fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfef0-0x] reserved
[0.00] BIOS-e820: [mem 0x00011000-0x00083eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: To be filled by O.E.M. To be filled by O.E.M./SABERTOOTH 
990FX R2.0, BIOS 2901 05/04/2016
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 4013.328 MHz processor
[0.001431] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.001433] e820: remove [mem 0x000a-0x000f] usable
[0.009268] AGP: No AGP bridge found
[0.009338] last_pfn = 0x83f000 max_arch_pfn = 0x4
[0.009342] MTRR default type: uncachable
[0.009342] MTRR fixed ranges enabled:
[0.009344]   0-9 write-back
[0.009345]   A-B write-through
[0.009345]   C-C write-protect
[0.009346]   D-EAFFF uncachable
[0.009347]   EB000-F write-protect
[0.009348] MTRR variable ranges enabled:
[0.009349]   0 base  mask 8000 write-back
[0.009350]   1 base 8000 mask C000 write-back
[0.009351]   2 base BD80 mask FF80 uncachable
[0.009352]   3 base BE00 mask FE00 uncachable
[0.009353]   4 disabled
[0.009354]   5 disabled
[0.009354]   6 disabled
[0.009355]   7 disabled
[0.009356] TOM2: 00083f00 aka 33776M
[0.010192] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.010307] e820: update [mem 0xbd80-0x] usable ==> 

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

[Diederik de Haas]

On zaterdag 21 augustus 2021 16:42:21 CEST Kobus van Schoor wrote:
> - My battery lasts significantly longer after upgrading to bullseye
> (around 2 hours extra I would guess). I'm not sure if there is now
> extra power saving features present in the kernel which might be
> interfering with my USB bus.

With 'powertop' there's a screen named 'Tunables' and there you can enable or 
disable various power related settings.
Where there previously was a whole list of settings I had to manually enable, 
since recently they're all enabled by default. In my case I disable a setting 
wrt my mouse otherwise it responds poorly.

With 'lsusb [-t]' you should be able to detect where your device is connected 
to and find a matching tunable in powertop and see whether that helps.


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

Bug#992638: rust-sized-chunks REJECT: has 26 file(s) with a timestamp too far in the past

[Adrian Bunk]

Source: rust-sized-chunks
Version: 0.6.5-1
Severity: serious
Tags: ftbfs

bunk@coccia:~$ cat 
/srv/ftp-master.debian.org/queue/reject/rust-sized-chunks_0.6.5-1_amd64-buildd.changes.reason

librust-sized-chunks-dev_0.6.5-1_amd64.deb: has 26 file(s) with a timestamp too 
far in the past:
  usr/share/cargo/registry/sized-chunks-0.6.5/.github/workflows/ci.yml (Thu Jan 
 1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/.github/workflows/fuzz.yml (Thu Jan 
 1 00:00:00 1970)  usr/share/cargo/registry/sized-chunks-0.6.5/.gitignore (Thu 
Jan  1 00:00:00 1970)  usr/share/cargo/registry/sized-chunks-0.6.5/.travis.yml 
(Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/CHANGELOG.md (Thu Jan  1 00:00:00 
1970)  usr/share/cargo/registry/sized-chunks-0.6.5/CODE_OF_CONDUCT.md (Thu Jan  
1 00:00:00 1970)  usr/share/cargo/registry/sized-chunks-0.6.5/LICENCE.md (Thu 
Jan  1 00:00:00 1970)  usr/share/cargo/registry/sized-chunks-0.6.5/README.md 
(Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/arbitrary.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/inline_array/iter.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/inline_array/mod.rs (Thu Jan  1 
00:00:00 1970)  usr/share/cargo/registry/sized-chunks-0.6.5/src/lib.rs (Thu Jan 
 1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/ring_buffer/index.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/ring_buffer/iter.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/ring_buffer/mod.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/ring_buffer/refpool.rs (Thu Jan 
 1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/ring_buffer/slice.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/sized_chunk/iter.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/sized_chunk/mod.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/sized_chunk/refpool.rs (Thu Jan 
 1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/sparse_chunk/iter.rs (Thu Jan  
1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/sparse_chunk/mod.rs (Thu Jan  1 
00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/sparse_chunk/refpool.rs (Thu 
Jan  1 00:00:00 1970)  usr/share/cargo/registry/sized-chunks-0.6.5/src/tests.rs 
(Thu Jan  1 00:00:00 1970)  
usr/share/cargo/registry/sized-chunks-0.6.5/src/types.rs (Thu Jan  1 00:00:00 
1970)  usr/share/doc/librust-sized-chunks-dev/changelog.gz (Thu Jan  1 00:00:00 
1970)
bunk@coccia:~$

Bug#992637: Dropped packets/high latency on USB bus when using USB oscilloscope in bullseye

[Kobus van Schoor]

Package: linux-image-amd64
Version: 5.10.46-4
Severity: important
X-Debbugs-Cc: v.schoor.ko...@gmail.com

Dear Maintainer,

   * What led up to the situation?

After installing bullseye, a specialized piece of hardware that I use
(Hantek 6022BE oscilloscope) has stopped transmitting packets reliably
over USB. This tool is used to read voltages from electronic circuits
in realtime - if there is significant latency or some packets are
dropped the signal becomes distorted and unusable. However, after
working with the maintainer of the software that I use to interact with
the scope (OpenHantek, see GitHub issue
here: https://github.com/OpenHantek/OpenHantek6022/issues/207) it seems
that the issue is specific to my laptop/USB bus. The maintainer
confirmed that if there was significant latency, or if packets were
dropped, the issue would present itself like I'm seeing it. 

The same issue is present on Fedora Workstation 34 on my laptop.

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

I've tried various things that didn't help:

- I tried someone else's exact same scope, the same issue occurred (so
the issue is on my laptop)
- I tried the realtime version of the kernel
- I tried all the ports on my laptop, which included USB 2 and 3 ports

Some things that I've noticed:

- My battery lasts significantly longer after upgrading to bullseye
(around 2 hours extra I would guess). I'm not sure if there is now
extra power saving features present in the kernel which might be
interfering with my USB bus. The issue is present both when connected
to AC or when running on battery
- The issue doesn't immediately occur. The device works ok for around
10 seconds before the signal becomes corrupted
- All my other USB devices still seem to work fine (mouse, external
HDD)

Installing buster's latest kernel on bullseye (I added the buster repos
and pinned it, and installed linux-image-4.19.0-17-amd64 from the
oldstable repos) resolves the problem, so it has something to do with
the kernel. Other people have reported that they are not experiencing
the issue on their side, even with the new kernel (however they have
different hardware than me).

I am not seeing any error messages in dmesg, so I presume the kernel is
not aware of the issue.

The oscilloscope’s USB controller is a Cypress CY7C68013A-100AXC (as I
understand it, a EX USB FX2 chip).

My laptop is an HP Probook 450 G5. lspci gives the following output:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core
Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620
(rev 07)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200
v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 08)
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI
Controller (rev 21)
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-
LP Thermal subsystem (rev 21)
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-
LP Serial IO I2C Controller #0 (rev 21)
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-
LP Serial IO I2C Controller #1 (rev 21)
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP
CSME HECI #1 (rev 21)
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA
Controller [AHCI mode] (rev 21)
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
Port #5 (rev f1)
00:1c.5 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root
Port #6 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Device 9d1b (rev f1)
00:1f.0 ISA bridge: Intel Corporation Sunrise Point LPC Controller/eSPI
Controller (rev 21)
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev
21)
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev
21)
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)
01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev
78)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd.
RTS522A PCI Express Card Reader (rev 01)


Please let me know if I can give any more information.

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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-5.10.0-8-amd64  5.10.46-4

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#992636: dput-ng: dput/dcut often fails with 'cannot read from timed out object'

[Sylvestre Ledru]

Package: dput-ng
Version: 1.33
Severity: important

Dear Maintainer,

Lately, dcut and dput have been failing more than before.

example:
$ dcut rm -f llvm-toolchain-13_13.0.0~+rc1-2_source.changes
Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
Expanding package list for removals to: 
llvm-toolchain-13_13.0.0~+rc1-2_source.changes, 
llvm-toolchain-13_13.0.0~+rc1-2_source.buildinfo, 
llvm-toolchain-13_13.0.0~+rc1-2.debian.tar.xz, 
llvm-toolchain-13_13.0.0~+rc1-2.dsc
Uploading sylvestre-1629556197.commands to ftp-master
cannot read from timed out object

Or
$ dput rust-datetime_0.5.2-1_source.changes
Uploading rust-datetime using ftp to ftp-master (host: ftp.upload.debian.org; 
directory: /pub/UploadQueue/)
running allowed-distribution: check whether a local profile permits uploads to 
the target distribution
running protected-distribution: warn before uploading to distributions where a 
special policy applies
running checksum: verify checksums before uploading
running suite-mismatch: check the target distribution for common errors
running gpg: check GnuPG signatures before the upload
Uploading rust-datetime_0.5.2-1.dsc
cannot read from timed out object

Not sure what is causing this but the error message could be improved :)

Cheers,
Sylvestre




-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (600, 'unstable'), (500, 'oldstable-updates'), (500, 
'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages dput-ng depends on:
ii  python3   3.9.2-3
ii  python3-dput  1.33

dput-ng recommends no packages.

Versions of packages dput-ng suggests:
pn  dput-ng-doc  
pn  python3-twitter  

-- no debconf information

Bug#992634: [Pkg-rust-maintainers] Bug#992634: rust-globset REJECT: has 9 file(s) with a timestamp too far in the past

[Sylvestre Ledru]

Le 21/08/2021 à 16:05, Adrian Bunk a écrit :
> Source: rust-globset
> Version: 0.4.8-1
> Severity: serious
> Tags: ftbfs
>
> bunk@coccia:~$ cat 
> /srv/ftp-master.debian.org/queue/reject/rust-globset_0.4.8-1_amd64-buildd.changes.reason
>
> librust-globset-dev_0.4.8-1_amd64.deb: has 9 file(s) with a timestamp too far 
> in the past:
>   usr/share/cargo/registry/globset-0.4.8/COPYING (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/globset-0.4.8/LICENSE-MIT (Thu Nov 29 21:33:09 1973) 
>  usr/share/cargo/registry/globset-0.4.8/README.md (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/globset-0.4.8/UNLICENSE (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/globset-0.4.8/benches/bench.rs (Thu Nov 29 21:33:09 
> 1973)  usr/share/cargo/registry/globset-0.4.8/src/glob.rs (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/globset-0.4.8/src/lib.rs (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/globset-0.4.8/src/pathutil.rs (Thu 
> Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/globset-0.4.8/src/serde_impl.rs (Thu Nov 29 21:33:09 
> 1973)bunk@coccia:~$

I am not sure why this warning deserves a reject but I will have a look...

Sylvestre

Bug#992635: RFP: janet -- A functional and imperative programming language and bytecode interpreter.

[mooff]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: mooff@awful.cooking

* Package name: janet
  Version : 1.16.1
  Upstream Author : Calvin Rose 
* URL : https://janet-lang.org/
* License : MIT
  Programming Lang: C, Janet, Lisp
  Description : Janet is a functional and imperative programming language 
and bytecode interpreter.

Janet is a functional and imperative programming language and bytecode
interpreter. It is a lisp-like language, but lists are replaced by other
data structures (arrays, tables (hash table), struct (immutable hash
table), tuples). The language also supports bridging to native code
written in C, meta-programming with macros, and bytecode assembly.

It has a small, quality, bubbling ecosystem which would be
supported by Janet's inclusion in Debian.

See also:
https://joyframework.com/
https://github.com/janet-lang/jpm

Bug#846383: grub2: add TPM support

[Vincent Bernat]

 ❦ 30 November 2016 20:11 GMT, Urquiza, Fabio:

> We think that TPM support is a good addition to Debian because it can increase
> its adoption in environments where a more secure approach to the booting is
> needed, by being able to securely measure if any component has been
> tampered.

It seems that Grub in Debian has now TPM support as there is a tpm.mod
shipped with Grub. Manual here:
https://www.gnu.org/software/grub/manual/grub/html_node/Measured-Boot.html

The documentation suggests the module should be builtin. If not, it is a
bit unknown what can happen. Maybe the tpm.mod itself can be tampered?

Would it be possible to have the module builtin for GRUB UEFI (where
the size does not matter)?
-- 
The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
-- Mark Twain

Bug#992619: mirror submission for tw1.mirror.blendbyte.net

[Blendbyte Inc.]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: tw1.mirror.blendbyte.net
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/
Maintainer: Blendbyte Inc. 
Country: TW Taiwan
Location: Taipei
Sponsor: Blendbyte Inc. https://blendbyte.com




Trace Url: http://tw1.mirror.blendbyte.net/debian/project/trace/
Trace Url: 
http://tw1.mirror.blendbyte.net/debian/project/trace/ftp-master.debian.org
Trace Url: 
http://tw1.mirror.blendbyte.net/debian/project/trace/tw1.mirror.blendbyte.net

Bug#992634: rust-globset REJECT: has 9 file(s) with a timestamp too far in the past

[Adrian Bunk]

Source: rust-globset
Version: 0.4.8-1
Severity: serious
Tags: ftbfs

bunk@coccia:~$ cat 
/srv/ftp-master.debian.org/queue/reject/rust-globset_0.4.8-1_amd64-buildd.changes.reason

librust-globset-dev_0.4.8-1_amd64.deb: has 9 file(s) with a timestamp too far 
in the past:
  usr/share/cargo/registry/globset-0.4.8/COPYING (Thu Nov 29 21:33:09 1973)  
usr/share/cargo/registry/globset-0.4.8/LICENSE-MIT (Thu Nov 29 21:33:09 1973)  
usr/share/cargo/registry/globset-0.4.8/README.md (Thu Nov 29 21:33:09 1973)  
usr/share/cargo/registry/globset-0.4.8/UNLICENSE (Thu Nov 29 21:33:09 1973)  
usr/share/cargo/registry/globset-0.4.8/benches/bench.rs (Thu Nov 29 21:33:09 
1973)  usr/share/cargo/registry/globset-0.4.8/src/glob.rs (Thu Nov 29 21:33:09 
1973)  usr/share/cargo/registry/globset-0.4.8/src/lib.rs (Thu Nov 29 21:33:09 
1973)  usr/share/cargo/registry/globset-0.4.8/src/pathutil.rs (Thu Nov 29 
21:33:09 1973)  usr/share/cargo/registry/globset-0.4.8/src/serde_impl.rs (Thu 
Nov 29 21:33:09 1973)bunk@coccia:~$

Bug#992633: rust-globset_0.4.8-1_i386-buildd.changes REJECTED

[Aurelien Jarno]

Source: rust-globset
Version: 0.4.8-1
Severity: serious

On 2021-08-21 13:50, Debian FTP Masters wrote:
> 
> 
> librust-globset-dev_0.4.8-1_i386.deb: has 9 file(s) with a timestamp too far 
> in the past:
>   usr/share/cargo/registry/globset-0.4.8/COPYING (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/globset-0.4.8/LICENSE-MIT (Thu Nov 29 21:33:09 1973) 
>  usr/share/cargo/registry/globset-0.4.8/README.md (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/globset-0.4.8/UNLICENSE (Thu Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/globset-0.4.8/benches/bench.rs (Thu Nov 29 21:33:09 
> 1973)  usr/share/cargo/registry/globset-0.4.8/src/glob.rs (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/globset-0.4.8/src/lib.rs (Thu Nov 29 
> 21:33:09 1973)  usr/share/cargo/registry/globset-0.4.8/src/pathutil.rs (Thu 
> Nov 29 21:33:09 1973)  
> usr/share/cargo/registry/globset-0.4.8/src/serde_impl.rs (Thu Nov 29 21:33:09 
> 1973)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#992632: ITP: r-bioc-degnorm -- DegNorm: degradation normalization for RNA-seq data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-degnorm -- DegNorm: degradation normalization for RNA-seq 
data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-degnorm
  Version : 1.2.0+ds
  Upstream Author : Bin Xiong and Ji-Ping Wang
* URL : https://bioconductor.org/packages/DegNorm/
* License : LGPL-3.0+
  Programming Lang: GNU R
  Description : DegNorm: degradation normalization for RNA-seq data
 This package performs degradation normalization in bulk RNA-seq data to
 improve differential expression analysis accuracy.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-degnorm

Bug#992630: ITP: r-bioc-degnorm -- DegNorm: degradation normalization for RNA-seq data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: r-bioc-degnorm -- DegNorm: degradation normalization for RNA-seq 
data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: r-bioc-degnorm
  Version : 1.2.0+ds
  Upstream Author : Bin Xiong and Ji-Ping Wang
* URL : https://bioconductor.org/packages/DegNorm/
* License : LGPL-3.0+
  Programming Lang: GNU R
  Description : DegNorm: degradation normalization for RNA-seq data
 This package performs degradation normalization in bulk RNA-seq data to
 improve differential expression analysis accuracy.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-bioc-degnorm

Bug#992618: hdparm: /lib/udev/hdparm does not set APM options anymore when resuming from suspend

[g1]

Package: hdparm
Version: 9.60+ds-1

/lib/udev/rules.d/85-hdparm.rules invokes /lib/udev/hdparm when
block devices matching /dev/sdX or /dev/hdX are added.

/lib/udev/hdparm is supposed to extract options relevant to
$DEVNAME and battery-vs-ac status from /etc/hdparm.conf and apply
them using /sbin/hdparm.  According to the changelog, since version
9.58+ds-2 the script singles out APM options and delegates them to
/usr/lib/pm-utils/sleep.d/95hdparm-apm.

However, /usr/lib/pm-utils/sleep.d/95hdparm-apm includes the following fragment:

# Do nothing when called via /etc/init.d/acpi-support; udev rules take care
# of setting the initial hdparm policy for us.
if ([ "$previous" ] && [ "$runlevel" ]) || [ "$runlevel" = S ]; then
exit 0
fi

When the condition is met (e.g. acpid handling resume-from-suspend),
APM options are not restored according to /etc/hdparm.conf.  Since udev
rules rely on /lib/udev/hdparm, the comment doesn't apply.

Please revert /lib/udev/hdparm to the previous version, so that it again
does just one thing: apply to device X all options configured for X
in /etc/hdparm.conf.

By the way, every now and then the hdparm package changes in surprising
ways: perhaps including a NEWS.Debian.gz could help.

Best regards,
g.



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

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

Versions of packages hdparm depends on:
ii  libc6 2.31-13
ii  lsb-base  11.1.0

Versions of packages hdparm recommends:
pn  powermgmt-base  

hdparm suggests no packages.

-- Configuration Files:
/etc/hdparm.conf changed:
quiet
/dev/sda {
apm = 254
apm_battery = 254
spindown_time = 250
write_cache = off
}


-- no debconf information