Bug#1054514: [PATCH v2 1/1] Revert "drm/qxl: simplify qxl_fence_wait"

[Greg KH]

On Thu, Apr 04, 2024 at 07:14:48PM +0100, Alex Constantino wrote:
> This reverts commit 5a838e5d5825c85556011478abde708251cc0776.
> 
> Changes from commit 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait") would
> result in a '[TTM] Buffer eviction failed' exception whenever it reached a
> timeout.
> Due to a dependency to DMA_FENCE_WARN this also restores some code deleted
> by commit d72277b6c37d ("dma-buf: nuke DMA_FENCE_TRACE macros v2").
> 
> Fixes: 5a838e5d5825 ("drm/qxl: simplify qxl_fence_wait")
> Link: https://lore.kernel.org/regressions/ztgydqrlk6wx_...@eldamar.lan/
> Reported-by: Timo Lindfors 
> Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054514
> Signed-off-by: Alex Constantino 
> ---
>  drivers/gpu/drm/qxl/qxl_release.c | 50 +++
>  include/linux/dma-fence.h |  7 +
>  2 files changed, 52 insertions(+), 5 deletions(-)

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- You have marked a patch with a "Fixes:" tag for a commit that is in an
  older released kernel, yet you do not have a cc: stable line in the
  signed-off-by area at all, which means that the patch will not be
  applied to any older kernel releases.  To properly fix this, please
  follow the documented rules in the
  Documentation/process/stable-kernel-rules.rst file for how to resolve
  this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Greg Kroah-Hartman]

On Tue, Mar 05, 2024 at 07:46:59AM +, Greg Kroah-Hartman wrote:
> On Mon, Mar 04, 2024 at 10:41:50PM +0100, Salvatore Bonaccorso wrote:
> > Hi,
> > 
> > On Mon, Mar 04, 2024 at 01:05:09PM -0700, Jonathan Corbet wrote:
> > > Salvatore Bonaccorso  writes:
> > > 
> > > > Ok. In the sprit of the stable series rules we might try the later and
> > > > if it's not feasible pick the first variant?
> > > 
> > > Well, "the spirit of the stable series" is one of Greg's titles, and he
> > > said either was good...:)
> > 
> > here we go. Please let me know if you need anything changed in the
> > commit message to describe the situation better.
> > 
> > Greg, in the Fixes tag I added the 5.10.y commit as the issue is
> > specific to the 5.10.y series. Is this the correct form to note this?
> 
> Looks good, I'll queue this up after the next round of releases goes
> out, thanks for the patch!

Now finally queued up, sorry for the delay.

greg k-h

Bug#1065520: python3-nitime: package install Waring

[Greg Schmidt]

Package: python3-nitime
Version: 0.10.2-2
Severity: minor
X-Debbugs-Cc: g...@gwschmidt.com

Dear Maintainer,

syntax error found in doc string of 
usr/lib/python3/dist-packages/nitime/algorithms/event_related.py

Preparing to unpack .../8-python3-nitime_0.10.2-2_all.deb ...
Unpacking python3-nitime (0.10.2-2) over (0.10.2-1) ...
Setting up python3-nitime (0.10.2-2) ...
>>> /usr/lib/python3/dist-packages/nitime/algorithms/event_related.py:13: 
>>> SyntaxWarning: invalid escape sequence '\h'



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

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

Versions of packages python3-nitime depends on:
ii  python3 3.11.6-1
ii  python3-matplotlib  3.6.3-1+b2
ii  python3-numpy   1:1.24.2-2
ii  python3-scipy   1.11.4-6

Versions of packages python3-nitime recommends:
ii  python3-networkx  2.8.8-1
ii  python3-nibabel   5.2.1-1

python3-nitime suggests no packages.

-- no debconf information

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Greg Kroah-Hartman]

On Mon, Mar 04, 2024 at 10:41:50PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> On Mon, Mar 04, 2024 at 01:05:09PM -0700, Jonathan Corbet wrote:
> > Salvatore Bonaccorso  writes:
> > 
> > > Ok. In the sprit of the stable series rules we might try the later and
> > > if it's not feasible pick the first variant?
> > 
> > Well, "the spirit of the stable series" is one of Greg's titles, and he
> > said either was good...:)
> 
> here we go. Please let me know if you need anything changed in the
> commit message to describe the situation better.
> 
> Greg, in the Fixes tag I added the 5.10.y commit as the issue is
> specific to the 5.10.y series. Is this the correct form to note this?

Looks good, I'll queue this up after the next round of releases goes
out, thanks for the patch!

greg k-h

Bug#1064035: [regression 5.10.y] linux-doc builds: Global symbol "$args" requires explicit package name (did you forget to declare "my $args"?) at ./scripts/kernel-doc line 1236.

[Greg Kroah-Hartman]

On Fri, Mar 01, 2024 at 01:31:10PM +0100, Salvatore Bonaccorso wrote:
> Hi,
> 
> Ben Hutchings reported in https://bugs.debian.org/1064035 a problem
> with the kernel-doc builds once 3080ea5553cc ("stddef: Introduce
> DECLARE_FLEX_ARRAY() helper") got applied in 5.10.210 (as
> prerequisite of another fix in 5.10.y):
> 
> > The backport of commit 3080ea5553cc "stddef: Introduce
> > DECLARE_FLEX_ARRAY() helper" modified scripts/kernel-doc and
> > introduced a syntax error:
> > 
> > Global symbol "$args" requires explicit package name (did you forget to 
> > declare "my $args"?) at ./scripts/kernel-doc line 1236.
> > Global symbol "$args" requires explicit package name (did you forget to 
> > declare "my $args"?) at ./scripts/kernel-doc line 1236.
> > Execution of ./scripts/kernel-doc aborted due to compilation errors.
> > 
> > This doesn't stop the documentation build process, but causes the
> > documentation that should be extracted by kernel-doc to be missing
> > from linux-doc-5.10.
> > 
> > We should be able to fix this by eithering backport commit
> > e86bdb24375a "scripts: kernel-doc: reduce repeated regex expressions
> > into variables" or replacing /$args/ with /([^,)]+)/.
> > 
> > Ben.
> 
> What would be prefered here from stable maintainers point of view?
> AFAICS e86bdb24375a ("scripts: kernel-doc: reduce repeated regex
> expressions into variables") won't apply cleanly and needs some
> refactoring. The alternative pointed out by Ben would be to replace
> the /$args/ with  /([^,)]+)/.

I'll take a patch that does either, your call :)

thanks,

greg k-h

Bug#1063837: coreutils: shred: documentation bug: 3>- should be 3>&-

[Greg Wooledge]

Package: coreutils
Version: 9.1-1
Severity: minor
Tags: upstream

The info page for shred includes this example code:

 i=$(mktemp)
 exec 3<>"$i"
 rm -- "$i"
 echo "Hello, world" >&3
 shred - >&3
 exec 3>-

The last line is incorrect.  It should be "exec 3>&-" which closes file
descriptor 3.  As written, the example code creates or truncates a
file literally named "-" instead.

This same error appears on
https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.html
(as of today) so I believe it's an upstream bug.

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

Kernel: Linux 6.1.0-18-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.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 coreutils depends on:
ii  libacl1  2.3.1-3
ii  libattr1 1:2.5.1-4
ii  libc62.36-9+deb12u4
ii  libgmp10 2:6.2.1+dfsg1-1.1
ii  libselinux1  3.4-1+b6

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#1061635: bind9: Missing version dependency on libuv1

[Greg Alexander]

Subject: Missing version dependency on libuv1
Package: bind9
X-Debbugs-Cc: d...@galexander.org
Version: 1:9.19.19-1
Severity: normal

I used "apt install" to upgrade bind9:amd64 to version 1:9.19.19-1.
apt failed and then I got this error from everything bind-related, such
as dig in bind9-dnsutils:

   # dig deb.devuan.org @192.168.100.254
   netmgr/netmgr.c:167:isc_netmgr_create(): fatal error: libuv version
   too old: running with libuv 1.40.0 when compiled with libuv 1.46.0
   will lead to libuv failures
   Aborted

I had libuv1:amd64 version 1.40.0-1.  I was eventually able to upgrade
libuv1 to version 1.46.0-3, and that resolved my problems.

I think the correct resolution would be to change the dependency in the
bind9-libs manifest file.  bind9-libs currently depends on:

   Depends: ..., libuv1 (>= 1.38.0), ...

It should probably be changed to

   Depends: ..., libuv1 (>= 1.46.0), ...

Thanks!!!
- Greg


-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux ascii
Release:9
Codename:   n/a
Architecture: x86_64

Kernel: Linux 5.10.104 (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)

Versions of packages bind9-dnsutils depends on:
ii  bind9-host [host]  1:9.19.19-1
ii  bind9-libs 1:9.19.19-1
ii  libc6  2.37-12
ii  libedit2   3.1-20181209-1
ii  libidn2-0  2.0.5-1
ii  libkrb5-3  1.20.1-2
ii  libprotobuf-c1 1.3.1-1+b1

bind9-dnsutils recommends no packages.

bind9-dnsutils suggests no packages.

-- no debconf information
Report will be sent to Debian Bug Tracking System 

Bug#1061478: apt: Internal Error, AutoRemover broke stuff, unmet dependencies: linux-headers-6.6.9-amd64

[greg]

Package: apt
Version: 2.7.10
Severity: normal
X-Debbugs-Cc: gre...@gmx.de

Make update everey day (as sudo):

apt update
apt full-upgrade

mm, seems like the AutoRemover destroyed something which really
shouldn't happen. Please file a bug report against apt.

The following information may help to resolve the situation:

The following packages have unmet dependencies:
 linux-headers-6.6.9-amd64 : Depends: linux-image-6.6.9-amd64 (= 6.6.9-1+b1)
but it is not installable or
  linux-image-6.6.9-amd64-unsigned (=
6.6.9-1+b1) but it is not going to be installed
E: Internal Error, AutoRemover broke stuff


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-.*";
APT::VersionedKernelPackages:: "kfreebsd-.*";
APT::VersionedKernelPackages:: "gnumach-.*";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "tasks";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/swcatalog -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh --source=os > /dev/null || 
true; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::zstd "";
APT::Compressor::zstd::Name "zstd";
APT::Compressor::zstd::Extension ".zst";
APT::Compressor::zstd::Binary "zstd";
APT::Compressor::zstd::Cost "60";
APT::Compressor::zstd::CompressArg "";
APT::Compressor::zstd::CompressArg:: "-19";
APT::Compressor::zstd::UncompressArg "";
APT::Compressor::zstd::UncompressArg:: "-d";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";
APT::Compressor::xz::Cost "200";
APT::Compressor::xz::CompressArg "";
APT::Compressor::xz::CompressArg:: "-6";
APT::Compressor::xz::UncompressArg "";
APT::Compressor::xz::UncompressArg:: "-d";
APT::Compressor::bzip2 "";
APT::Compressor::bzip2::Name "bzip2";
APT::Compressor::bzip2::Extension ".bz2";
APT::Compressor::bzip2::Binary "bzip2";
APT::Compressor::bzip2::Cost "300";
APT::Compressor::bzip2::CompressArg "";
APT::Compressor::bzip2::CompressArg:: "-6";
APT::Compressor::bzip2::UncompressArg "";
APT::Compressor::bzip2::UncompressArg:: "-d";
APT::Compressor::lzma "";
APT::Compressor::lzma::Name "lzma";
APT::Compressor::lzma::Extension ".lzma";
APT::Compressor::lzma::Binary "xz";
APT::Compressor::lzma::Cost "400";
APT::Compressor::lzma::CompressArg "";
APT::Compressor::lzma::CompressArg:: "--format=lzma";
APT::Compressor::lzma::CompressArg:: "-6";
APT::Compressor::lzma::UncompressArg "";
APT::Compressor::lzma::UncompressArg:: "--format=lzma";
APT::Compressor::lzma::UncompressArg:: "-d";
Dir "/";
Dir::State "var/lib/apt";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::extended_states "extended_states";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::netrc "auth.conf";
Dir::Etc::netrcparts "auth.conf.d";
Dir::Etc::parts 

Bug#1055601: darktable: Segfault in first run after system hang

[Greg Schmidt]

Package: darktable
Version: 4.4.2-1+b1
Severity: normal
X-Debbugs-Cc: g...@desk1.attlocal.net

Dear Maintainer,

I was using darktable when my system hung. I had to reboot to recover. After 
the reboot I started darktable and 
it segfaulted. A backtrace was created which implicated dlopen. It was 
attempting to load "libMesaOpenCL.so.1".
A subsequent start of darktable was normal. 

Content of /tmp/darktable_bt_T7K9D2.txt follows:

this is darktable 4.4.2 reporting a segfault:

warning: Currently logging to /tmp/darktable_bt_T7K9D2.txt.  Turn the logging 
off and on to make the new setting effective.
#0  0x7f83a54f11b7 in __GI___wait4 (pid=5442, stat_loc=0x0, options=0, 
usage=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
#1  0x7f83a57a28d0 in  () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#2  0x7f83a545a510 in  () at 
/lib/x86_64-linux-gnu/libc.so.6
#3  0x7f833fd6bd52 in LLVMCreateTargetMachine () at 
/lib/x86_64-linux-gnu/libLLVM-15.so.1
#4  0x7f8351455e0e in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#5  0x7f83514561c5 in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#6  0x7f83513654eb in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#7  0x7f8351365943 in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#8  0x7f8395331720 in amdgpu_winsys_create () at 
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
#9  0x7f8351366616 in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#10 0x7f835123b50a in  () at 
/usr/lib/x86_64-linux-gnu/gallium-pipe/pipe_radeonsi.so
#11 0x7f8351eb4fa8 in  () at /lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#12 0x7f8351ea0bd8 in  () at /lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#13 0x7f8351eafae2 in  () at /lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#14 0x7f8351e737d9 in  () at /lib/x86_64-linux-gnu/libMesaOpenCL.so.1
#15 0x7f83a5dfad2e in call_init (env=0x5568250ba0e0, argv=0x7ffd910bebe8, 
argc=7, l=) at ./elf/dl-init.c:90
#16 call_init (l=, argc=7, argv=0x7ffd910bebe8, 
env=0x5568250ba0e0) at ./elf/dl-init.c:27
#17 0x7f83a5dfae14 in _dl_init (main_map=0x556825573a60, argc=7, 
argv=0x7ffd910bebe8, env=0x5568250ba0e0) at ./elf/dl-init.c:137
#18 0x7f83a5df7516 in __GI__dl_catch_exception 
(exception=exception@entry=0x0, operate=operate@entry=0x7f83a5e01570 
, args=args@entry=0x7ffd910ba280) at ./elf/dl-catch.c:211
#19 0x7f83a5e0150e in dl_open_worker (a=a@entry=0x7ffd910ba420) at 
./elf/dl-open.c:808
#20 0x7f83a5df7489 in __GI__dl_catch_exception 
(exception=exception@entry=0x7ffd910ba400, operate=operate@entry=0x7f83a5e01480 
, args=args@entry=0x7ffd910ba420) at ./elf/dl-catch.c:237
#21 0x7f83a5e018a8 in _dl_open (file=0x556825096160 "libMesaOpenCL.so.1", 
mode=, caller_dlopen=0x7f839c0238bd, nsid=, 
argc=7, argv=0x7ffd910bebe8, env=0x5568250ba0e0) at ./elf/dl-open.c:884
#22 0x7f83a54a26f8 in dlopen_doit (a=a@entry=0x7ffd910ba690) at 
./dlfcn/dlopen.c:56
#23 0x7f83a5df7489 in __GI__dl_catch_exception 
(exception=exception@entry=0x7ffd910ba5f0, operate=0x7f83a54a26a0 
, args=0x7ffd910ba690) at ./elf/dl-catch.c:237
#24 0x7f83a5df75af in _dl_catch_error (objname=0x7ffd910ba648, 
errstring=0x7ffd910ba650, mallocedp=0x7ffd910ba647, operate=, 
args=) at ./elf/dl-catch.c:256
#25 0x7f83a54a21e7 in _dlerror_run (operate=operate@entry=0x7f83a54a26a0 
, args=args@entry=0x7ffd910ba690) at ./dlfcn/dlerror.c:138
#26 0x7f83a54a27a9 in dlopen_implementation (dl_caller=, 
mode=, file=) at ./dlfcn/dlopen.c:71
#27 ___dlopen (file=, mode=) at 
./dlfcn/dlopen.c:81
#28 0x7f839c0238bd in  () at /lib/x86_64-linux-gnu/libOpenCL.so.1
#29 0x7f839c023aa3 in  () at /lib/x86_64-linux-gnu/libOpenCL.so.1
#30 0x7f839c0249e3 in clGetPlatformIDs () at 
/lib/x86_64-linux-gnu/libOpenCL.so.1
#31 0x7f83a578aabb in dt_opencl_init () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#32 0x7f83a56efbf3 in dt_init () at 
/usr/bin/../lib/x86_64-linux-gnu/darktable/libdarktable.so
#33 0x556823a7a08c in  ()
#34 0x7f83a54456ca in __libc_start_call_main 
(main=main@entry=0x556823a7a070, argc=argc@entry=7, 
argv=argv@entry=0x7ffd910bebe8) at ../sysdeps/nptl/libc_start_call_main.h:58
#35 0x7f83a5445785 in __libc_start_main_impl (main=0x556823a7a070, argc=7, 
argv=0x7ffd910bebe8, init=, fini=, 
rtld_fini=, stack_end=0x7ffd910bebd8) at ../csu/libc-start.c:360
#36 0x556823a7a0f1 in  ()

=

  Id   Target Id Frame 
* 1Thread 0x7f839dc860c0 (LWP 5423) "darktable"  0x7f83a54f11b7 in 
__GI___wait4 (pid=5442, stat_loc=0x0, options=0, usage=0x0) at 
../sysdeps/unix/sysv/linux/wait4.c:30
  2Thread 0x7f839d7ff6c0 (LWP 5425) "pool-spawner"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  3Thread 0x7f839cffe6c0 (LWP 5426) "gmain"  0x7f83a5519a1f in 
__GI___poll (fds=0x556825096e50, nfds=1, timeout=-1) at 

Bug#1051523: Doxygen changes breaks krb5 documentation build

[Greg Hudson]

On 9/12/23 03:01, Paolo Greppi wrote:

This may well be a doxygen bug, can anybody tell if there is any pattern?


I believe this is a deliberate behavior change in Doxygen 1.9.7, made to 
address a problem affecting a different doxygen-to-RST converter:


  https://github.com/doxygen/doxygen/pull/9797
  https://github.com/doxygen/doxygen/issues/8790

(doxyrest doesn't appear to be packaged by Debian, or I'd investigate 
whether we could use it instead of the current homegrown bridge.  But 
that would be a longer-term change anyway.)


Although it might be difficult to modify the current scripts to handle 
this change, the deduplication only arises because of @group 
declarations in krb5.hin, which don't have any effect on the generated 
RST files.  I have filed a PR to remove these and the associated @ref 
declarations:


  https://github.com/krb5/krb5/pull/1316

Bug#1036543: [PATCH 5.10 076/529] crypto: ccp: Use the stack for small SEV command buffers

[Greg Kroah-Hartman]

On Fri, May 26, 2023 at 05:36:02PM +0200, Ben Hutchings wrote:
> On Wed, 2023-05-17 at 16:06 +0200, Greg Kroah-Hartman wrote:
> > On Wed, May 17, 2023 at 04:02:35PM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, May 17, 2023 at 02:56:21PM +0200, Ben Hutchings wrote:
> > > > On Fri, 2023-03-10 at 14:33 +0100, Greg Kroah-Hartman wrote:
> > > > > From: Sean Christopherson 
> > > > > 
> > > > > [ Upstream commit e4a9af799e5539b0feb99571f0aaed5a3c81dc5a ]
> > > > > 
> > > > > For commands with small input/output buffers, use the local stack to
> > > > > "allocate" the structures used to communicate with the PSP.   Now that
> > > > > __sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
> > > > > reason to avoid using the stack, e.g. CONFIG_VMAP_STACK=y will just 
> > > > > work.
> > > > [...]
> > > > 
> > > > Julien Cristau reported a regression in ccp - the
> > > > WARN_ON_ONCE(!virt_addr_valid(data)) is now being triggered.  I believe
> > > > this was introduced by the above commit, which depends on:
> > > > 
> > > > commit 8347b99473a313be6549a5b940bc3c56a71be81c
> > > > Author: Sean Christopherson 
> > > > Date:   Tue Apr 6 15:49:48 2021 -0700
> > > >  
> > > > crypto: ccp: Play nice with vmalloc'd memory for SEV command structs
> > > > 
> > > > Ben.
> > > > 
> > > 
> > > Thanks for letting me know, now queued up.
> > 
> > Nope, now dropped, it breaks the build :(
> 
> I've now looked further and found that we need both:
> 
> d5760dee127b crypto: ccp: Reject SEV commands with mismatching command buffer
> 8347b99473a3 crypto: ccp: Play nice with vmalloc'd memory for SEV command 
> structs
> 
> (Not yet tested; I'll ask Julien if he can do that.)

Looks sane to me, both now queued up, thanks.

greg k-h

Bug#1037004: msmtp-mta doesn't respect DEBIAN_FRONTEND=noninteractive

[Greg]

Package: msmtp-mta
Version: 1.8.6-1
Severity: important

Dear Maintainer,

Regarding your commit here: 
https://salsa.debian.org/kolter/msmtp/-/commit/7633ea472e24bf3be003396a2e4567d101f8cf53

This has added a TUI when installing the `msmtp-mta` package that appears even 
on non-interactive terminals. This is making it very difficult for us to 
upgrade our Gitlab install which has this command in a Dockerfile:

RUN DEBIAN_FRONTEND=noninteractive apt-get -y update && \
  apt-get install -yq --no-install-recommends msmtp-mta s-nail htop dialog less 
paxctl sudo

The command is executed by `docker-compose build --pull`

However the TUI shows up and there’s no way to dismiss it without aborting the 
install. Pressing enter/space etc does not work, it only types keys over the 
TUI.

Any help with this is greatly appreciated!

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(100, 'focal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.6-200.fc37.x86_64 (SMP w/2 CPU cores; PREEMPT)
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: sysvinit (via /sbin/init)

Versions of packages msmtp-mta depends on:
ii  init-system-helpers  1.57
ii  libc62.31-0ubuntu9.9
ii  msmtp1.8.6-1

msmtp-mta recommends no packages.

msmtp-mta suggests no packages.

-- no debconf information

Bug#1032815: FIXED (Configuration error)

[Greg Deitrick]

The file /etc/network/interfaces contained a block that defined a network
connection for the wifi adapter.  Eliminating that block and rebooting
restored the desired behavior.

Bug#1032815: network-manager: nmcli finds no wifi APs while wifi network connected and working

[Greg Deitrick]

Package: network-manager
Version: 1.42.4-1
Severity: important
X-Debbugs-Cc: greg.deitr...@gmail.com

Dear Maintainer,

1. Gnome / Settings / Wi-Fi reports "No Wi-Fi Adapter Found"
2. The command, ' nmcli device wifi list ' reports no available wifi APs
Consequently, wifi connections cannot be managed by Gnome nor by nmcli

However, at the same time:
1.  Wifi network connection is working.
2.  There is no wired ethernet port on this computer.
3.  The command "ping www.google.com" indicates successful transmission.
4.  A second computer in the same location reports 4 active wifi networks with 
signal strengths from 59 to 100.
 
This occurred immediately after a fresh install of 
debian-bookworm-DI-alpha2-amd64-netinst.iso onto a Framework Laptop 12th gen.  
The wifi network connection was configured during this install and used during 
the install.  Only the base system was installed initially.  After the first 
boot apt-get update/upgrade was performed and the system was rebooted.  Then 
tasksel was used to install a desktop environment and gnome.

Prior to this install, this computer was running Ubuntu 22.04 for over 4 
months.  During this time Gnome managed the wifi network connection as expected.
The problem persisted after upgrading network-manager from the version in 
bookworm to the version in unstable.

Some possibly helpful output:

$ nmcli device wifi list
IN-USE  BSSID  SSID  MODE  CHAN  RATE  SIGNAL  BARS  SECURITY 

$ nmcli device show
GENERAL.DEVICE: lo
GENERAL.TYPE:   loopback
GENERAL.HWADDR: 00:00:00:00:00:00
GENERAL.MTU:65536
GENERAL.STATE:  100 (connected (externally))
GENERAL.CONNECTION: lo
GENERAL.CON-PATH:   
/org/freedesktop/NetworkManager/ActiveConnection/1
IP4.ADDRESS[1]: 127.0.0.1/8
IP4.GATEWAY:--
IP6.ADDRESS[1]: ::1/128
IP6.GATEWAY:--
IP6.ROUTE[1]:   dst = ::1/128, nh = ::, mt = 256

GENERAL.DEVICE: wlp166s0
GENERAL.TYPE:   wifi
GENERAL.HWADDR: 8C:F8:C5:EE:01:C9
GENERAL.MTU:1500
GENERAL.STATE:  10 (unmanaged)
GENERAL.CONNECTION: --
GENERAL.CON-PATH:   --
IP4.ADDRESS[1]: 192.168.1.36/24
IP4.GATEWAY:192.168.1.1
IP4.ROUTE[1]:   dst = 192.168.1.0/24, nh = 0.0.0.0, mt 
= 0
IP4.ROUTE[2]:   dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 0
IP4.ROUTE[3]:   dst = 169.254.0.0/16, nh = 0.0.0.0, mt 
= 1000
IP6.ADDRESS[1]: fe80::8ef8:c5ff:feee:1c9/64
IP6.GATEWAY:--
IP6.ROUTE[1]:   dst = fe80::/64, nh = ::, mt = 256

$ lshw -C network
  *-network 
   description: Wireless interface
   product: Wi-Fi 6 AX210/AX211/AX411 160MHz
   vendor: Intel Corporation
   physical id: 0
   bus info: pci@:a6:00.0
   logical name: wlp166s0
   version: 1a
   serial: 8c:f8:c5:ee:01:c9
   width: 64 bits
   clock: 33MHz
   capabilities: pm msi pciexpress msix bus_master cap_list ethernet 
physical wireless
   configuration: broadcast=yes driver=iwlwifi driverversion=6.1.0-5-amd64 
firmware=72.daa05125.0 ty-a0-gf-a0-72.uc ip=192.168.1.36 latency=0 link=yes 
multicast=yes wireless=IEEE 802.11
   resources: irq:16 memory:7a20-7a203fff

$ lsmod | grep iwl
iwlmvm385024  0
mac80211 1175552  1 iwlmvm
iwlwifi   360448  1 iwlmvm
cfg80211 1134592  3 iwlmvm,iwlwifi,mac80211
rfkill 36864  9 iwlmvm,bluetooth,cfg80211

$ sudo dmesg | grep iwl
[4.558340] iwlwifi :a6:00.0: enabling device ( -> 0002)
[4.570738] iwlwifi :a6:00.0: firmware: direct-loading firmware 
iwlwifi-ty-a0-gf-a0-72.ucode
[4.570752] iwlwifi :a6:00.0: api flags index 2 larger than supported by 
driver
[4.570767] iwlwifi :a6:00.0: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.36
[4.571101] iwlwifi :a6:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[4.571153] iwlwifi :a6:00.0: firmware: failed to load 
iwl-debug-yoyo.bin (-2)
[4.571168] iwlwifi :a6:00.0: loaded firmware version 72.daa05125.0 
ty-a0-gf-a0-72.ucode op_mode iwlmvm
[4.689001] iwlwifi :a6:00.0: Detected Intel(R) Wi-Fi 6 AX210 160MHz, 
REV=0x420
[4.865896] iwlwifi :a6:00.0: firmware: direct-loading firmware 
iwlwifi-ty-a0-gf-a0.pnvm
[4.865972] iwlwifi :a6:00.0: loaded PNVM version 64acdc51
[4.884369] iwlwifi :a6:00.0: Detected RF GF, rfid=0x10d000
[4.961304] iwlwifi :a6:00.0: base HW address: 8c:f8:c5:ee:01:c9
[4.995420] 

Bug#993612: [PATCH 5.10 104/139] of/address: Return an error when no valid dma-ranges are found

[Greg Kroah-Hartman]

From: Mark Brown 

commit f6933c01e42d2fc83b9133ed755609e4aac6eadd upstream.

Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.

This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.

Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown 
Cc: Luca Di Stefano 
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
Link: 
https://lore.kernel.org/r/20230126-synquacer-boot-v2-1-cb80fd23c...@kernel.org
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/of/address.c |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -990,8 +990,19 @@ int of_dma_get_range(struct device_node
}
 
of_dma_range_parser_init(, node);
-   for_each_of_range(, )
+   for_each_of_range(, ) {
+   if (range.cpu_addr == OF_BAD_ADDR) {
+   pr_err("translation of DMA address(%llx) to CPU address 
failed node(%pOF)\n",
+  range.bus_addr, node);
+   continue;
+   }
num_ranges++;
+   }
+
+   if (!num_ranges) {
+   ret = -EINVAL;
+   goto out;
+   }
 
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
@@ -1000,18 +1011,16 @@ int of_dma_get_range(struct device_node
}
 
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
 */
*map = r;
of_dma_range_parser_init(, node);
for_each_of_range(, ) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
 range.bus_addr, range.cpu_addr, range.size);
-   if (range.cpu_addr == OF_BAD_ADDR) {
-   pr_err("translation of DMA address(%llx) to CPU address 
failed node(%pOF)\n",
-  range.bus_addr, node);
+   if (range.cpu_addr == OF_BAD_ADDR)
continue;
-   }
r->cpu_start = range.cpu_addr;
r->dma_start = range.bus_addr;
r->size = range.size;

Bug#993612: [PATCH 5.15 13/67] of/address: Return an error when no valid dma-ranges are found

[Greg Kroah-Hartman]

From: Mark Brown 

commit f6933c01e42d2fc83b9133ed755609e4aac6eadd upstream.

Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.

This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.

Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown 
Cc: Luca Di Stefano 
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
Link: 
https://lore.kernel.org/r/20230126-synquacer-boot-v2-1-cb80fd23c...@kernel.org
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/of/address.c |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -963,8 +963,19 @@ int of_dma_get_range(struct device_node
}
 
of_dma_range_parser_init(, node);
-   for_each_of_range(, )
+   for_each_of_range(, ) {
+   if (range.cpu_addr == OF_BAD_ADDR) {
+   pr_err("translation of DMA address(%llx) to CPU address 
failed node(%pOF)\n",
+  range.bus_addr, node);
+   continue;
+   }
num_ranges++;
+   }
+
+   if (!num_ranges) {
+   ret = -EINVAL;
+   goto out;
+   }
 
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
@@ -973,18 +984,16 @@ int of_dma_get_range(struct device_node
}
 
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
 */
*map = r;
of_dma_range_parser_init(, node);
for_each_of_range(, ) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
 range.bus_addr, range.cpu_addr, range.size);
-   if (range.cpu_addr == OF_BAD_ADDR) {
-   pr_err("translation of DMA address(%llx) to CPU address 
failed node(%pOF)\n",
-  range.bus_addr, node);
+   if (range.cpu_addr == OF_BAD_ADDR)
continue;
-   }
r->cpu_start = range.cpu_addr;
r->dma_start = range.bus_addr;
r->size = range.size;

Bug#993612: [PATCH 6.1 013/114] of/address: Return an error when no valid dma-ranges are found

[Greg Kroah-Hartman]

From: Mark Brown 

commit f6933c01e42d2fc83b9133ed755609e4aac6eadd upstream.

Commit 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
converted the parsing of dma-range properties to use code shared with the
PCI range parser. The intent was to introduce no functional changes however
in the case where we fail to translate the first resource instead of
returning -EINVAL the new code we return 0. Restore the previous behaviour
by returning an error if we find no valid ranges, the original code only
handled the first range but subsequently support for parsing all supplied
ranges was added.

This avoids confusing code using the parsed ranges which doesn't expect to
successfully parse ranges but have only a list terminator returned, this
fixes breakage with so far as I can tell all DMA for on SoC devices on the
Socionext Synquacer platform which has a firmware supplied DT. A bisect
identified the original conversion as triggering the issues there.

Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range")
Signed-off-by: Mark Brown 
Cc: Luca Di Stefano 
Cc: 993...@bugs.debian.org
Cc: sta...@kernel.org
Link: 
https://lore.kernel.org/r/20230126-synquacer-boot-v2-1-cb80fd23c...@kernel.org
Signed-off-by: Rob Herring 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/of/address.c |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -965,8 +965,19 @@ int of_dma_get_range(struct device_node
}
 
of_dma_range_parser_init(, node);
-   for_each_of_range(, )
+   for_each_of_range(, ) {
+   if (range.cpu_addr == OF_BAD_ADDR) {
+   pr_err("translation of DMA address(%llx) to CPU address 
failed node(%pOF)\n",
+  range.bus_addr, node);
+   continue;
+   }
num_ranges++;
+   }
+
+   if (!num_ranges) {
+   ret = -EINVAL;
+   goto out;
+   }
 
r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
if (!r) {
@@ -975,18 +986,16 @@ int of_dma_get_range(struct device_node
}
 
/*
-* Record all info in the generic DMA ranges array for struct device.
+* Record all info in the generic DMA ranges array for struct device,
+* returning an error if we don't find any parsable ranges.
 */
*map = r;
of_dma_range_parser_init(, node);
for_each_of_range(, ) {
pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
 range.bus_addr, range.cpu_addr, range.size);
-   if (range.cpu_addr == OF_BAD_ADDR) {
-   pr_err("translation of DMA address(%llx) to CPU address 
failed node(%pOF)\n",
-  range.bus_addr, node);
+   if (range.cpu_addr == OF_BAD_ADDR)
continue;
-   }
r->cpu_start = range.cpu_addr;
r->dma_start = range.bus_addr;
r->size = range.size;

Bug#1029267: Solved

[Greg Dev]

Caused by installation failure, not a bug.

Bug#1021054: nextcloud-desktop: Depends on: qtbase-abi-5-15-4 but is not installable

[greg]

Package: nextcloud-desktop
Version: 3.6.0-2
Severity: normal
X-Debbugs-Cc: gre...@gmx.de

Dear Maintainer,

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

   * What led up to the situation?
Use of nextcloud with debian sid
   * 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: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
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 nextcloud-desktop depends on:
ii  libc6  2.35-1
ii  libcloudproviders0 0.3.1-2
ii  libgcc-s1  12.2.0-3
ii  libglib2.0-0   2.74.0-2
pn  libnextcloudsync0  
ii  libqt5core5a   5.15.6+dfsg-2
ii  libqt5dbus55.15.6+dfsg-2
ii  libqt5gui5 5.15.6+dfsg-2
pn  libqt5keychain1
ii  libqt5network5 5.15.6+dfsg-2
ii  libqt5qml5 5.15.6+dfsg-2
ii  libqt5quick5   5.15.6+dfsg-2
pn  libqt5quickcontrols2-5 
pn  libqt5sql5-sqlite  
ii  libqt5svg5 5.15.6-2
pn  libqt5webenginecore5   
pn  libqt5webenginewidgets5
ii  libqt5widgets5 5.15.6+dfsg-2
ii  libstdc++6 12.2.0-3
pn  nextcloud-desktop-common   
pn  nextcloud-desktop-l10n 
pn  qml-module-qt-labs-platform
pn  qml-module-qtgraphicaleffects  
pn  qml-module-qtqml-models2   
pn  qml-module-qtquick-controls2   
pn  qml-module-qtquick-dialogs 
pn  qml-module-qtquick-layouts 
pn  qml-module-qtquick-window2 
pn  qml-module-qtquick2

Versions of packages nextcloud-desktop recommends:
pn  nextcloud-desktop-doc  

nextcloud-desktop suggests no packages.

Bug#1004904: gitlab-runner: Installer overwrites the systemd service definition.

[Greg Harvey]

Package: gitlab-runner
Version: 14.7.0
Severity: important

Dear Maintainer,

When upgrading the gitlab-runner package with `apt-get dist-upgrade` the 
package installer overwrites this file:

  /etc/systemd/system/gitlab-runner.service

Any upgrade of gitlab-runner via this package results in the service definition 
being obliterated, thus the ExecStart line for the service being reset to 
defaults.

Consequently any custom parameters the user may have set, such as system user 
or working directory, get lost and gitlab-runner is not functional until the 
user manually restores their previous settings and reloads systemctl.

I would expeect the installer to *not* overwrite this file during an upgrade, 
because it has very likely been altered by the user to carry custom settings 
for the daemon.

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

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

Bug#886617: Please package version 2.1

[Greg McFarlane]

Hi Daniel,

As the original maintainer of Pmw (over 20 years ago!) I would be very
happy if you updated Pmw to version 2.1.

Regards,

Greg (old email: gr...@iname.com)

On Mon, Jan 10, 2022 at 4:09 AM Daniel Leidert  wrote:

> unblock 886617 by 936212
> block  936212 by 886617
> block 1003405 by 886617
> retitle 886617 python-pmw: Please package version 2.1 and include Python 3
> support
> thanks
>
> Hi,
>
> there is finally a bkchem version ported to python 3 and it has already
> been
> packaged. However, it requires the update pf pmw to version 2.1
> (https://pypi.org/project/Pmw-py3/).
>
> This would close a lot of open bug reports, and maybe even allow the final
> removal of python2.
>
> Should we prepare an NMU?
>
> Regards, Daniel
> --
> Regards,
> Daniel Leidert  | https://www.wgdd.de/
> GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
> GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78
>
> https://www.fiverr.com/dleidert
> https://www.patreon.com/join/dleidert
>

Bug#994095: ITS: python-pmw

[Greg McFarlane]

Hi Moritz and Boyuan,

Thanks for getting in touch.

The latest release of Pmw is here:

  https://sourceforge.net/projects/pmw/

I am no longer actively maintaining Pmw, although in December 2020 I did
merge a number of changes (mainly for Python 3) into the latest release.

I would be very grateful if you could do all you can to move the latest Pmw
release into Debian.

There is a copyright file here: /Pmw/Pmw_2_1/doc/copyright.html

Do you need any more for the copyright?

Note that my normal email has changed from gr...@iname.com to
veganasg...@gmail.com.

Thanks for your help.

Veganly,

Greg McFarlane


On Thu, Nov 11, 2021 at 9:15 AM Boyuan Yang  wrote:

> Hi,
>
> 在 2021-11-10星期三的 22:43 +0100，Moritz Mühlenhoff写道：
> > Am Sat, Sep 11, 2021 at 01:04:16PM -0400 schrieb Boyuan Yang:
> > > Source: python-pmw
> > > Version:  1.3.2-6
> > > Severity: important
> > > X-Debbugs-CC: se...@debian.org
> > >
> > > Dear package python-pmw maintainer in Debian,
> > >
> > > After looking into the package you maintain (python-pmw,
> > > https://tracker.debian.org/pkg/python-pmw), I found that this package
> > > received no maintainer updates in the past 10 years and was not in good
> > > shape. As a result, I am filing an ITS (Intent to Salvage) request
> > > against your package according to section 5.12 in Debian's Developers'
> > > Reference [1].
> > >
> > > My current plan is to package the latest upstream release (2.1),
> > > clean up packaging and orphan this package to allow possible external
> > > contribution.
> > >
> > > Please let me know whether you are still willing to maintain this
> > > package. According to the criteria listed at [2], I will upload a Non-
> > > maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
> > > (Oct 02, 2021) to continue with the package salvaging. If you find it
> > > necessary to pause the ITS process, please let me know immediately by
> > > replying this bug report.
> >
> > What's the status? Given the package hasn't seen a maintainer upload
> > for over a decade it seems safe to proceed :-)
> >
> > You don't need to care about the current reverse dep when dropping
> > support for Python 2; bkchem is already uninstallable due to missing
> > python-pil.
>
> See https://salsa.debian.org/python-team/packages/python-pmw ; a previous
> upload was rejected by FTP Masters due to incomplete copyright. More work
> is
> needed, and any help would be great.
>
> Thanks,
> Boyuan Yang
>
>

Bug#994596: tcllib: no calendar module available

[greg]

Package: tcllib
Version: 1.20+dfsg-1
Severity: normal
X-Debbugs-Cc: gre...@gmx.de

Dear Maintainer,

*** 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: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
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 tcllib depends on:
ii  iproute2  5.14.0-1
ii  tcl   8.6.11+1

tcllib recommends no packages.

Versions of packages tcllib suggests:
ii  tcllib-critcl  1.20+dfsg-1

Bug#994095: ITS: python-pmw

[Greg McFarlane]

Hi Boyuan,

Thanks for contacting me about Pmw. The latest version of Pmw (2.1) is here:

  https://sourceforge.net/projects/pmw/

This contains a few fixes people have emailed me over the last few years. I
can no longer maintain this software, so please do what you can to keep Pmw
in Debian.

Thanks for your help,

Greg

On Sun, Sep 12, 2021 at 3:06 AM Boyuan Yang  wrote:

> Source: python-pmw
> Version:  1.3.2-6
> Severity: important
> X-Debbugs-CC: se...@debian.org
>
> Dear package python-pmw maintainer in Debian,
>
> After looking into the package you maintain (python-pmw,
> https://tracker.debian.org/pkg/python-pmw), I found that this package
> received no maintainer updates in the past 10 years and was not in good
> shape. As a result, I am filing an ITS (Intent to Salvage) request
> against your package according to section 5.12 in Debian's Developers'
> Reference [1].
>
> My current plan is to package the latest upstream release (2.1),
> clean up packaging and orphan this package to allow possible external
> contribution.
>
> Please let me know whether you are still willing to maintain this
> package. According to the criteria listed at [2], I will upload a Non-
> maintainer Upload (NMU) of this package onto DELAYED/7 after 21 days
> (Oct 02, 2021) to continue with the package salvaging. If you find it
> necessary to pause the ITS process, please let me know immediately by
> replying this bug report.
>
>
> [1]
>
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
> [2] https://wiki.debian.org/PackageSalvaging
>
> --
> Best Regards,
> Boyuan Yang
>

Bug#355442: mawk: missing Posix ERE curly braces

[Greg Wooledge]

The version of mawk shipped with bullseye still has this bug (or what
upstream calls a known limitation).

I've also verified that the bug occurs with upstream mawk, version
1.3.4-20200120, both with and without the --without-builtin-regex
compile time option.

unicorn:~/tmp/mawk-1.3.4-20200120$ ./configure --without-builtin-regex
[ output omitted ]
unicorn:~/tmp/mawk-1.3.4-20200120$ make
[ output omitted ]
unicorn:~/tmp/mawk-1.3.4-20200120$ echo 99 | ./mawk '/^9{1}/'
unicorn:~/tmp/mawk-1.3.4-20200120$ 

(Output should have been 99.)

Since it's failing even with --without-builtin-regex I figure this might
be something upstream should hear about, so I'm Cc-ing Mr. Dickey.

Bug#991853: archive.debian.org: Invalid SSL/TLS certificate, https fails

[Greg Wooledge]

Package: www.debian.org
Severity: normal

Apologies if this is the wrong pseudo-package; I couldn't find one
for archive.debian.org specifically.

Attempts to download a package from the archive.debian.org site using
https with command line tools fail.  These examples are performed on a
bullseye host:


$ wget 
https://archive.debian.org/debian/pool/main/a/apt/apt-transport-https_0.9.7.9+deb7u7_amd64.deb
--2021-08-03 08:26:17--  
https://archive.debian.org/debian/pool/main/a/apt/apt-transport-https_0.9.7.9+deb7u7_amd64.deb
Resolving archive.debian.org (archive.debian.org)... 217.196.149.234, 
193.62.202.28, 130.89.148.13, ...
Connecting to archive.debian.org (archive.debian.org)|217.196.149.234|:443... 
connected.
ERROR: The certificate of ‘archive.debian.org’ is not trusted.
ERROR: The certificate of ‘archive.debian.org’ doesn't have a known issuer.
The certificate's owner does not match hostname ‘archive.debian.org’

$ curl 
https://archive.debian.org/debian/pool/main/a/apt/apt-transport-https_0.9.7.9+deb7u7_amd64.deb
 > apt-transport-https_0.9.7.9+deb7u7_amd64.deb
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
curl: (60) SSL certificate problem: self signed certificate in certificate chain
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.


If I go to https://archive.debian.org/debian/pool/main/a/apt/ in
Google Chrome, I'm prompted with the standard warning about an
invalid certificate; if I choose to go forward despite that, I get:


Not Found
The requested URL was not found on this server.

Apache Server at archive.debian.org Port 443


Finally, I will note that it would be most helpful if the archive.debian.org
site can be accessed directly by older systems using the apt-transport-https
package.  If this is impossible due to security concerns, then downloading
the packages by hand on a newer system, and then moving them over to the
older systems, would still be better than the current situation, which is
that the packages are completely inaccessible in environments where plain
http is blocked.

Bug#991578: [Aptitude-devel] Bug#991578: aptitude: document state indicator letters more clearly

[Greg Wooledge]

On Wed, Jul 28, 2021 at 10:06:45AM +0200, Axel Beckert wrote:
> From my mind there are also some more possible states, which seem not
> to be documented in the manual at all on a first glance. IIRC these
> are:
> 
> H or h = on hold
> U or u = unpacked, but not configured, e.g. if the configure step in
>  the previous run failed.
> B  = broken (dependencies are not fullfilled)
> F  = forbidden version

For whatever reason, the aptitude developers did not include all of
the state letters in the man page.  They only included the "most
common" ones, even though the example right above that section includes
a letter that isn't in their list ("h").

This patch only moves things around within the man page.  I didn't add
any additional content, because I was going for a minimalist change.

A larger set of state letters is documented at
 (more
specifically, )
which I *think* is what the man page is referring to when it talks about an
"aptitude reference manual" or "reference guide".

I don't know whether that's a complete set either.

The developers chose to keep that information out of the man page,
and I didn't want to step on any toes, so I kept it out of my patch
as well.  If the developers would like the full set of state letters to
be documented in the man page, I would definitely welcome that.

Bug#991578: aptitude: document state indicator letters more clearly

[Greg Wooledge]

Package: aptitude
Version: 0.8.13-3
Severity: wishlist
Tags: patch

This patch improves the documentation of the state indicator letters, used
in the output of the "search" and "why" actions.

-- Package-specific info:
Terminal: rxvt-unicode-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 10.2.1 20210110
Compiled against:
  apt version 6.0.0
  NCurses version 6.2
  libsigc++ version: 2.10.4
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.2.20201114
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7fff06399000)
libapt-pkg.so.6.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7fa53929c000)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7fa539261000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7fa539232000)
libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7fa539229000)
libcwidget.so.4 => /usr/lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7fa539123000)
libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fa538fe)
libboost_iostreams.so.1.74.0 => 
/usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.74.0 (0x7fa538fc5000)
libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 
(0x7fa538da3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7fa538d81000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fa538bb4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa538a7)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fa538a56000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa53888f000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 
(0x7fa538875000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fa538858000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7fa538845000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fa53881d000)
liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 
(0x7fa5387fa000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 
(0x7fa53871d000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 
(0x7fa5386f5000)
libsystemd.so.0 => /usr/lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7fa53864)
libgcrypt.so.20 => /usr/lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7fa53852)
libxxhash.so.0 => /usr/lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7fa538507000)
/lib64/ld-linux-x86-64.so.2 (0x7fa5398c1000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fa538501000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fa5384f4000)
libuuid.so.1 => /usr/lib/x86_64-linux-gnu/libuuid.so.1 
(0x7fa5384eb000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7fa5384c5000)

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

Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 aptitude depends on:
ii  aptitude-common   0.8.13-3
ii  libapt-pkg6.0 2.2.4
ii  libboost-iostreams1.74.0  1.74.0-9
ii  libc6 2.31-13
ii  libcwidget4   0.5.18-5
ii  libgcc-s1 10.2.1-6
ii  libncursesw6  6.2+20201114-2
ii  libsigc++-2.0-0v5 2.10.4-2
ii  libsqlite3-0  3.34.1-3
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  libxapian30   1.4.18-3

Versions of packages aptitude recommends:
ii  libdpkg-perl1.20.9
ii  sensible-utils  0.0.14

Versions of packages aptitude suggests:
pn  apt-xapian-index
pn  aptitude-doc-en | aptitude-doc  
pn  debtags 
ii  tasksel 3.68

-- no debconf information
--- aptitude-0.8.13/doc/en/manpage.xml  2020-05-20 23:32:38.0 -0400
+++ aptitude-0.8.13-edited/doc/en/manpage.xml   2021-07-27 15:21:10.599153571 
-0400
@@ -696,32 +696,12 @@
 ihA raptor-utils- Raptor RDF Parser utilities
 
   
-   Each search result is listed on a separate line.  The
-   first character of each line indicates the current state
-   of the package: the most common states are
-   p, meaning that no trace of the package
-   exists on the system, c, meaning that
-   the package was deleted but its configuration files remain
-   on the system, i, 

Bug#892105: Cherry-pick "i40e: Be much more verbose about what we can and cannot offload"

[Greg KH]

On Tue, Jun 29, 2021 at 06:20:30PM +, Fujinaka, Todd wrote:
> I think I accidentally deleted the forward from the intel-wired-lan spam 
> filter. Re-forwarding and adding Alex's gmail address.
> 
> Also, 
> 
> Todd Fujinaka
> Software Application Engineer
> Data Center Group
> Intel Corporation
> todd.fujin...@intel.com
> 
> -Original Message-
> From: Philipp Hahn  
> Sent: Tuesday, June 22, 2021 11:19 AM
> To: sta...@vger.kernel.org; 892...@bugs.debian.org; Ben Hutchings 
> 
> Cc: Alexander Duyck ; Andrew Bowers 
> ; Bonaccorso, Salvatore 
> Subject: Cherry-pick "i40e: Be much more verbose about what we can and cannot 
> offload"
> 
> Hello,
> 
> I request the following patch from v4.10-rc1 to get cherry-picked into
> "stable/linux-4.9.y":
> 
> > commit f114dca2533ca770aebebffb5ed56e5e7d1fb3fb

Please provide a working backport, that you have tested works properly,
as it does not apply cleanly.

thanks,

greg k-h

Bug#892105: Cherry-pick "i40e: Be much more verbose about what we can and cannot offload"

[Greg KH]

On Tue, Jun 22, 2021 at 08:18:53PM +0200, Philipp Hahn wrote:
> Hello,
> 
> I request the following patch from v4.10-rc1 to get cherry-picked into
> "stable/linux-4.9.y":
> 
> > commit f114dca2533ca770aebebffb5ed56e5e7d1fb3fb
> > Author: Alexander Duyck 
> > Date:   Tue Oct 25 16:08:46 2016 -0700
> > 
> > i40e: Be much more verbose about what we can and cannot offload
> > This change makes it so that we are much more robust about defining 
> > what we
> > can and cannot offload.  Previously we were just checking for the L4 
> > tunnel
> > header length, however there are other fields we should be verifying as
> > there are multiple scenarios in which we cannot perform hardware 
> > offloads.
> > In addition the device only supports GSO as long as the MSS is 64 or
> > greater.  We were not checking this so an MSS less than that was 
> > resulting
> > in Tx hangs.
> > Change-ID: I5e2fd5f3075c73601b4b36327b771c64fcb6c31b
> > Signed-off-by: Alexander Duyck 
> > Tested-by: Andrew Bowers 
> 
> Debian had this old Bug
> <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892105> reported against
> 4.9.82, which still exists in Debians old-stable 9 "Stretch" current kernel
> 4.9.258, but also with latest stable 4.9.273.

Now queued up, thanks.

greg k-h

Bug#988676: pinfo: tag table corrupt after repeating total-search

[Greg Wooledge]

Package: pinfo
Version: 0.6.13-1.1
Severity: normal

I get the message "Tag table is corrupt, trying to fix..." when repeating
a total-search after starting pinfo on a sub-node inside a larger page tree.

Steps to reproduce:

pinfo date
s
%F
f
f

This assumes Debian's default configuration with KEY_TOTALSEARCH_1 = 's'
and KEY_SEARCH_AGAIN_1='f'.

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

Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 pinfo depends on:
ii  install-info  6.7.0.dfsg.2-6
ii  libc6 2.31-11
ii  libncursesw6  6.2+20201114-2
ii  libreadline8  8.1-1
ii  libtinfo6 6.2+20201114-2

pinfo recommends no packages.

pinfo suggests no packages.

-- no debconf information

Bug#926501: xpdf: continuousView memory leak

[Greg Alexander]

I updated to 3.04+git20210103-2 amd64, and it's usable again!  I am still
using continuousView.  Memory usage remained below 150MB even after
extensively navigating a large PDF.

Thank you!  This is a big improvement in usability for me.

- Greg

On Thu, Mar 04, 2021 at 07:05:55AM +0100, Florian Schlichting wrote:
> can you please test this issue with xpdf 3.04+git20210103-1 or newer and
> confirm that your memory problem has indeed been solved?

Bug#982998: chkrootkit chkproc uses incorrect value for max_pid

[Greg Schmidt]

Package: chkrootkit
Version: 0.54-1
Severity: normal
X-Debbugs-Cc: g_w_schm...@sbcglobal.net

Dear Maintainer,
   * What led up to the situation?

Executed chkrotkit and had a error in the report

`Checking `bindshell'...not infected
 Checking `lkm'...  OooPS, not expected 3778733 value
 chkproc: Warning: Possible LKM Trojan installed
 chkdirs: nothing detected

Hmm, what does that mean?

grabbed the source and see that while reading thru the output from a 'ps maux'
the pid field is checked against MAX_PROCESSES

ret = atol(p);
if ( ret < 0 || ret > MAX_PROCESSES )
{
fprintf (stderr, " OooPS, not expected %ld value\n", ret);
exit (2);
}

and 
#define MAX_PROCESSES 9

BUT on my system the value of pid_max is much higher 
root@desk1:~# cat /proc/sys/kernel/pid_max
4194304

Maybe the tool could use the /proc value rather than
a compiled in value. 

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

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

Versions of packages chkrootkit depends on:
ii  binutils   2.35.1-7
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.31-9
ii  net-tools  1.60+git20181103.0eebece-1
ii  openssh-client 1:8.4p1-3
ii  procps 2:3.3.16-5

chkrootkit recommends no packages.

chkrootkit suggests no packages.

-- debconf information:
  chkrootkit/diff_mode: false
  chkrootkit/run_daily_opts: -q
  chkrootkit/run_daily: false

Bug#980978: update xkb-data to match upstream

[Greg Meyer]

Package: xkb-data
Version: 2.29-2

xkeyboard-config has since released both 2.30 and 2.31, it would be greatly
appreciated if the Debian package could be updated to include the changes.

Bug#972539: isc-dhcp-client: fails to set valid_lft if IP exists, then IP expires early

[Greg Alexander]

Package: isc-dhcp-client
Version: 4.4.1-2.1+b2
Severity: normal

Dear Maintainer,

I believe I have found the exact bug anticipated by Sven Ulland in his
fix for #834532.  Here is a quote from his report:

> A problem remains: If dhclient is terminated and started again, it starts with
> reason=REBOOT and attempts to do a 'ip -4 addr add ...'. Since the address is
> still configured on the interface, this results in 'RTNETLINK answers: File
> exists', and the lifetimes are not reset. If the lifetimes expire before the
> DHCP renew hits, the address(es) are removed from the interface. This should
> probably be fixed in a separate issue.

Just to expand on Sven's description with my actual symptoms...  I have a
script which can restart dhclient rather abruptly (killall -9 dhclient;
dhclient wlan0).  Sometimes the IP address remains on the interface, and
then after dhclient restarts the valid_lft is not reset.  Then the kernel
kills the IP address after the lifetime runs out, but dhclient isn't
ready to renew the interface yet.  The connection is then dead until
dhclient renews on its own schedule (or it is manually restarted).

To work around it on my system, I simply found the two commands that set
valid_lft and replaced "ip -4 addr add" with "ip -4 addr replace".

I think this fix should be generally applicable.  Here's the trivial
patch:

http://galexander.org/x/0001-replace-IPv4-lifetime-instead-of-add-in-case-it-alre.patch

Hope this helps!  Thanks!

- Greg


-- System Information:
Distributor ID: Debian
Description:Devuan GNU/Linux 3 (beowulf)
Release:3
Codename:   beowulf
Architecture: x86_64

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

Versions of packages isc-dhcp-client depends on:
ii  debianutils4.8.6.1
ii  iproute2   4.20.0-2
ii  libc6  2.31-4
ii  libdns-export1110  1:9.11.19+dfsg-1
ii  libisc-export1105  1:9.11.19+dfsg-1

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.4.1-2

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
ii  resolvconf1.84

-- Configuration Files:
/etc/dhcp/dhclient.conf changed [not included]

-- no debconf information

Bug#905564: /etc/default/su

[Greg Wooledge]

There is no /etc/default/su file by default, but if you create one and
put

ALWAYS_SET_PATH yes

in it, then su *does* change the PATH variable, and this avoids the warning
message from login.

ii  util-linux 2.33.1-0.1   amd64miscellaneous system utilities

unicorn:~$ cat /etc/default/su
ALWAYS_SET_PATH yes
unicorn:~$ echo "$PATH"
/home/greg/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
unicorn:~$ su
Password:
root@unicorn:/home/greg# echo "$PATH"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root@unicorn:/home/greg#

Bug#965074: Patches to make multicast proccesing on CDC NCM drivers

[Greg KH]

On Wed, Sep 02, 2020 at 03:27:28PM +0200, Santiago Ruano Rincón wrote:
> El 02/09/20 a las 14:05, Greg KH escribió:
> > On Wed, Sep 02, 2020 at 01:47:18PM +0200, Santiago Ruano Rincón wrote:
> > > El 30/07/20 a las 16:07, Oliver Neukum escribió:
> > > > Am Donnerstag, den 30.07.2020, 15:53 +0200 schrieb Santiago Ruano
> > > > Rincón:
> > > > > Hi,
> > > > > 
> > > > > Miguel Rodríguez sent this set of patches two years ago to fix the 
> > > > > lack
> > > > > of multicast processing on CDC NCM driver:
> > > > > 
> > > > > https://www.spinics.net/lists/linux-usb/msg170611.html
> > > > > https://www.spinics.net/lists/linux-usb/msg170603.html
> > > > > https://www.spinics.net/lists/linux-usb/msg170567.html
> > > > > https://www.spinics.net/lists/linux-usb/msg170568.html
> > > > > 
> > > > > I've using a DKMS version of them, available in
> > > > > https://github.com/stbuehler/fixed-cdc-ether-ncm/tree/wip/patches
> > > > > since more than a year ago, and they are working fine with my Dell 
> > > > > D6000
> > > > > docking station. IPv6 connectivity is broken without them.
> > > > > 
> > > > > Is there any chance to consider those patches (or what would be needed
> > > > > to make it happen)?
> > > > > It would be great to have them upstream!
> > > > 
> > > > Hi,
> > > > 
> > > > they have been merged on Wednesday.
> > > …
> > > 
> > > Great, thanks!
> > > 
> > > It would be possible to apply/backport Miguel's patches (along with
> > > 5fd99b5d9950d6300467ded18ff4e44af0b4ae55) to stable versions please?
> > 
> > I don't see that git commit id in Linus's tree, are you sure it is
> > correct?
> 
> I should had mention it is found in linux-next, sorry. Please see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969365#10

Ah, nothing I can do with patches that are not yet in Linus's tree.

> > > FWIW, in the context of Debian, I'm personally interested in 4.19.y.
> > 
> > What specific list of commits are you wanting to see backported?
> 
> This:
> 
> 37a2ebdd9e597ae1a0270ac747883ea8f6f767b6
> e10dcb1b6ba714243ad5a35a11b91cc14103a9a9
> e506addeff844237d60545ef4f6141de21471caf
> 0226009ce0f6089f9b31211f7a2703cf9a327a01

These do not look like bugfixes, but a new feature being added for this
driver.  So why not just use a newer kernel version for this feature?

thanks,

greg k-h

Bug#965074: Patches to make multicast proccesing on CDC NCM drivers

[Greg KH]

On Wed, Sep 02, 2020 at 01:47:18PM +0200, Santiago Ruano Rincón wrote:
> El 30/07/20 a las 16:07, Oliver Neukum escribió:
> > Am Donnerstag, den 30.07.2020, 15:53 +0200 schrieb Santiago Ruano
> > Rincón:
> > > Hi,
> > > 
> > > Miguel Rodríguez sent this set of patches two years ago to fix the lack
> > > of multicast processing on CDC NCM driver:
> > > 
> > > https://www.spinics.net/lists/linux-usb/msg170611.html
> > > https://www.spinics.net/lists/linux-usb/msg170603.html
> > > https://www.spinics.net/lists/linux-usb/msg170567.html
> > > https://www.spinics.net/lists/linux-usb/msg170568.html
> > > 
> > > I've using a DKMS version of them, available in
> > > https://github.com/stbuehler/fixed-cdc-ether-ncm/tree/wip/patches
> > > since more than a year ago, and they are working fine with my Dell D6000
> > > docking station. IPv6 connectivity is broken without them.
> > > 
> > > Is there any chance to consider those patches (or what would be needed
> > > to make it happen)?
> > > It would be great to have them upstream!
> > 
> > Hi,
> > 
> > they have been merged on Wednesday.
> …
> 
> Great, thanks!
> 
> It would be possible to apply/backport Miguel's patches (along with
> 5fd99b5d9950d6300467ded18ff4e44af0b4ae55) to stable versions please?

I don't see that git commit id in Linus's tree, are you sure it is
correct?

> FWIW, in the context of Debian, I'm personally interested in 4.19.y.

What specific list of commits are you wanting to see backported?

thanks,

greg k-h

Bug#966649: Unfortunately there are several Uploads missing (Was: upload_history is back)

[greg]

I'd like to unsubscribe
Thank you

On Wed, Aug 26, 2020 at 3:15 PM Eriberto Mota  wrote:

> Em qua., 26 de ago. de 2020 às 06:45, Andreas Tille 
> escreveu:
> >
> > Control: reopen -1
> >
> > Hi Asheesh,
> >
> > On Tue, Aug 25, 2020 at 10:52:56PM -0700, Asheesh Laroia wrote:
> > > Test yourself with e.g. this command (which queries the public UDD
> mirror,
> > > but you can use the real UDD if you can connect to ullmann.debian.org
> )!
> >
> > So the bad news is that there is something wrong with the importer.
>
> Please, check my UDD[1] that lists all sources in Debian Sid (see the
> 'Upload Sid' column).
>
> [1] https://people.debian.org/~eriberto/udd/help_a_package.html
>
> Currently there are 31.371 sources in Sid and 19.353 has no upload date.
>
> Thanks a lot for your efforts.
>
> Regards,
>
> Eriberto
>
>

Bug#969013: kdump-tools: obsolete syslog+console used in unit file

[Greg Schmidt]

Package: kdump-tools
Version: 1:1.6.7-4
Severity: minor

Dear Maintainer,
Following error seen in journalctl output:

Aug 25 23:26:01 desk1 systemd[1]: /lib/systemd/system/kdump-tools.service:6: 
Standard output type syslog+console is obsolete, automatically updating to 
journal+console. Please update your unit file, and consider removing the 
setting altogether.

and systemctl status shows

root@desk1:~# systemctl status kdump-tools
● kdump-tools.service - Kernel crash dump capture service
 Loaded: loaded (/lib/systemd/system/kdump-tools.service; enabled; vendor 
preset: enabled)
 Active: active (exited) since Sat 2020-08-22 18:58:14 EDT; 3 days ago
   Main PID: 1196 (code=exited, status=0/SUCCESS)
  Tasks: 0 (limit: 18902)
 Memory: 0B
 CGroup: /system.slice/kdump-tools.service

Aug 24 06:42:21 desk1 systemd[1]: /lib/systemd/system/kdump-tools.service:6: 
Standard output type syslog+console is obsolete, automatically updating to 
journal+console. Please update your unit file, and consider removing the 
setting altogether.
Aug 24 06:42:25 desk1 systemd[1]: /lib/systemd/system/kdump-tools.service:6: 
Standard output type syslog+console is obsolete, automatically updating to 
journal+console. Please update your unit file, and consider removing the 
setting altogether.
Aug 25 23:25:32 desk1 systemd[1]: /lib/systemd/system/kdump-tools.service:6: 
Standard output type syslog+console is obsolete, automatically updating to 
journal+console. Please update your unit file, and consider removing the 
setting altogether.


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

Kernel: Linux 5.7.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=C.UTF-8, 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 kdump-tools depends on:
ii  bsdmainutils   12.1.7
ii  debconf [debconf-2.0]  1.5.74
ii  file   1:5.38-5
ii  init-system-helpers1.58
ii  kexec-tools1:2.0.20-2.1
ii  linux-base 4.6
ii  lsb-base   11.1.0
ii  makedumpfile   1:1.6.7-4
ii  ucf3.0043

Versions of packages kdump-tools recommends:
ii  initramfs-tools-core  0.137

kdump-tools suggests no packages.

-- debconf information:
* kdump-tools/use_kdump: true

Bug#963493: Repeatable hard lockup running strace testsuite on 4.19.98+ onwards

[Greg KH]

On Fri, Jun 26, 2020 at 12:35:58PM +0100, Steve McIntyre wrote:
> Hi folks,
> 
> I'm the maintainer in Debian for strace. Trying to reproduce
> https://bugs.debian.org/963462 on my machine (Thinkpad T470), I've
> found a repeatable hard lockup running the strace testsuite. Each time
> it seems to have failed in a slightly different place in the testsuite
> (suggesting it's not one particular syscall test that's triggering the
> failure). I initially found this using Debian's current Buster kernel
> (4.19.118+2+deb10u1), then backtracking I found that 4.19.98+1+deb10u1
> worked fine.
> 
> I've bisected to find the failure point along the linux-4.19.y stable
> branch and what I've got to is the following commit:
> 
> e58f543fc7c0926f31a49619c1a3648e49e8d233 is the first bad commit
> commit e58f543fc7c0926f31a49619c1a3648e49e8d233
> Author: Jann Horn 
> Date:   Thu Sep 13 18:12:09 2018 +0200
> 
> apparmor: don't try to replace stale label in ptrace access check
> 
> [ Upstream commit 1f8266ff58840d698a1e96d2274189de1bdf7969 ]
> 
> As a comment above begin_current_label_crit_section() explains,
> begin_current_label_crit_section() must run in sleepable context because
> when label_is_stale() is true, aa_replace_current_label() runs, which uses
> prepare_creds(), which can sleep.
> Until now, the ptrace access check (which runs with a task lock held)
> violated this rule.
> 
> Also add a might_sleep() assertion to begin_current_label_crit_section(),
> because asserts are less likely to be ignored than comments.
> 
> Fixes: b2d09ae449ced ("apparmor: move ptrace checks to using labels")
> Signed-off-by: Jann Horn 
> Signed-off-by: John Johansen 
> Signed-off-by: Sasha Levin 
> 
> :04 04 ca92f885a38c1747b812116f19de6967084a647e 
> 865a227665e460e159502f21e8a16e6fa590bf50 M security
> 
> Considering I'm running strace build tests to provoke this bug,
> finding the failure in a commit talking about ptrace changes does look
> very suspicious...!
> 
> Annoyingly, I can't reproduce this on my disparate other machines
> here, suggesting it's maybe(?) timing related.
> 
> Hope this helps - happy to give more information, test things, etc.

So if you just revert this one patch, all works well?

I've added the authors of the patch to the cc: list...

Also, does this problem happen on Linus's tree?

thanks,

greg k-h

Bug#757402: [PATCH] tests: skip small-stack tests on hppa architecture

[Greg Price]

On hppa these tests crash because the allocated stack space is too
small, even after it was doubled in b9a190789 (and the data size
doubled to match) to make it work on powerpc.  For this arch just
skip these tests, which is enough to make the whole suite pass.

Fixes: https://bugs.debian.org/757402
Based-on-patch-by: John David Anglin 
Signed-off-by: Greg Price 
---
 t/test-lib.sh | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0ea1e5a05..c62961a3e 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -1467,6 +1467,14 @@ FreeBSD)
;;
 esac
 
+# Detect arches where a few things don't work
+uname_m=$(uname -m)
+case $uname_m in
+parisc* | hppa*)
+   test_set_prereq HPPA
+   ;;
+esac
+
 ( COLUMNS=1 && test $COLUMNS = 1 ) && test_set_prereq COLUMNS_CAN_BE_1
 test -z "$NO_PERL" && test_set_prereq PERL
 test -z "$NO_PTHREADS" && test_set_prereq PTHREADS
@@ -1606,16 +1614,16 @@ run_with_limited_cmdline () {
 }
 
 test_lazy_prereq CMDLINE_LIMIT '
-   test_have_prereq !MINGW,!CYGWIN &&
+   test_have_prereq !HPPA,!MINGW,!CYGWIN &&
run_with_limited_cmdline true
 '
 
 run_with_limited_stack () {
(ulimit -s 128 && "$@")
 }
 
 test_lazy_prereq ULIMIT_STACK_SIZE '
-   test_have_prereq !MINGW,!CYGWIN &&
+   test_have_prereq !HPPA,!MINGW,!CYGWIN &&
run_with_limited_stack true
 '
 
-- 
2.26.2

Bug#757402: git: test suite fails on hppa, in run_with_limited_stack

[Greg Price]

On Wed, May 13, 2020 at 4:53 AM John David Anglin  wrote:
> On 2020-05-13 1:44 a.m., Greg Price wrote:
> > Probably cleanest to put this outside the `case $uname_s`.
> I put it where I did because the result of uname -m is somewhat OS dependent.
>
> The config.guess script attempts to guess a canonical system name for a 
> target.  It has all the gory
> details on the interpretation of uname -m.

I just took a look through that. Wow, I see what you mean!

case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
# ...
9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:*)
echo hppa1.1-hp-bsd
exit ;;

And there are lots more like that one, and others with complex internal logic.

Still I'm not sure that that situation is helped by putting the `uname
-m` inside this case. This is the catchall `*)` case after looking
only for MINGW, CYGWIN, and FreeBSD, and those all appear to have
pretty sane `uname -m` behavior. (On FreeBSD, `uname -p` gets a bit
more specific but `uname -m` is already sane; I found the report here:
  https://github.com/mesonbuild/meson/issues/5766
informative.) If any of the OSes where config.guess has to do more
work were to get this far in building and testing Git, they'd end up
running any code we stick at this spot anyway. So I think it still
makes more sense to put the new `case` next to the existing one.

One other thought I have from that config.guess example, though --
there are some cases there like this:

parisc64:Linux:*:* | hppa64:Linux:*:*)
echo hppa64-unknown-linux-"$LIBC"
exit ;;

That suggests to me that the condition should perhaps look for "hppa", too, like

parisc* | hppa*)
test_set_prereq HPPA
;;

What do you think?

Cheers,
Greg

Bug#757402: git: test suite fails on hppa, in run_with_limited_stack

[Greg Price]

Great! WFM on amd64, too.

>  *)
> + uname_m=$(uname -m)
> + case $uname_m in
> + parisc*)
> + test_set_prereq HPPA
> + ;;
> + esac

Probably cleanest to put this outside the `case $uname_s`.

Would you mind if I send a version of this patch to the upstream
mailing list? I think that's the best route for it to go through.

Or you're of course welcome to do so (and please cc this bug); if you
haven't submitted patches to Git before, you'll want to read the
instructions here:
https://git.github.io/htmldocs/SubmittingPatches.html#send-patches

Cheers,
Greg

Bug#757402: git: test suite fails on hppa, in run_with_limited_stack

[Greg Price]

Control: retitle -1 git: test suite fails on hppa, in run_with_limited_stack
Control: found -1 1:2.26.1-1

On Thu, 7 Aug 2014 16:10:20 -0400 John David Anglin
 wrote:
> run_with_limited_stack git tag --contains HEAD >actual &&
> [...]
> Killed
> not ok 136 - --contains works in a deep repo

Thanks for the report.


On Fri, 05 Sep 2014 23:12:26 +0200 Helge Deller  wrote:
> git fails to build on hppa arch, because the stack is set to 64kb
> in the run_with_limited_stack() function for this test.
> I assume 64kb stack size is far too small for hppa?
> Even /bin/ls won't work with a 128kb stack - so I'm not sure if
> this testcase should just be disabled for hppa (it's disabled on
> Windows because Windows does not support setting ulimits).

A few weeks after these reports, the stack size for these tests was
bumped to 128k upstream:
  https://git.kernel.org/pub/scm/git/git.git/commit/?id=b9a190789
apparently in order to make it work on the m68k arch. (Commit message
copied below.)

But that wasn't enough on hppa, and the test suite is still failing
there with essentially the same issue. It appears now slightly
earlier, in another test 6120.70 (from t/t6120-describe.sh) which has
adopted the same technique. Here's the failure in the most recent
buildd log in unstable, on Git v2.26.1:

"""
expecting success of 6120.70 'describe works in a deep repo':
git tag -f far-far-away HEAD~7999 &&
echo "far-far-away" >expect &&
git describe --tags --abbrev=0 HEAD~4000 >actual &&
test_cmp expect actual &&
run_with_limited_stack git describe --tags --abbrev=0
HEAD~4000 >actual &&
test_cmp expect actual

Updated tag 'far-far-away' (was cb6ab2c)
Segmentation fault
not ok 70 - describe works in a deep rep
"""
https://buildd.debian.org/status/fetch.php?pkg=git=hppa=1%3A2.26.1-1=1586894380=0

I think it would indeed be sensible to simply disable these test cases
on hppa. Here's how the prereq for them is defined:
"""
test_lazy_prereq ULIMIT_STACK_SIZE '
test_have_prereq !MINGW,!CYGWIN &&
run_with_limited_stack true
'
"""

So perhaps that `!MINGW,!CYGWIN` bit can be straightforwardly extended
to skip these tests on hppa too. If somebody would like to find the
right incantation to put there for hppa, and test that it works, then
I think that may be enough to get the Git test suite passing again on
hppa.

Cheers,
Greg



commit b9a1907899a2a00e94092207bb5de4d864408806
Author: Junio C Hamano 
Date:   Tue Sep 23 15:41:38 2014 -0700

t7004: give the test a bit more stack space

It was reported that the allocated stack space was too small for
some archs openSUSE buildfarm runs the tests on.  Double it while
also doubling the amount of data to be handled.

Reported-by: Andreas Schwab 
Suggested-by: Jeff King 
Tested-by: Andreas Schwab 
Signed-off-by: Junio C Hamano 

Bug#933100: hg-git: autopkgtest needs update for new version of git

[Greg Price]

Control: affects -1 - src:git

On Fri, 26 Jul 2019 20:07:31 +0200 Paul Gevers  wrote:
> With a recent upload of git the autopkgtest of hg-git fails in testing
> when that autopkgtest is run with the binary packages of git from
> unstable. It passes when run with only packages from testing. In tabular
> form:
>passfail
> gitfrom testing1:2.22.0-1
> hg-git from testing0.8.12-1.1
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report. It seems your
> test is picky about capitalization of output generated by a binary (git)
> provided by the git package. Please fix your test.

I'm not quite sure whether this test in hg-git was ever fixed, but in
any case I believe it no longer affects git: the delay eventually
expired and a new git version migrated. (As have several more new
versions since then.)

Cheers,
Greg

Bug#959770: python3.8 for buster-backports

[Greg Price]

Package: src:python3.8
Severity: wishlist

Hello,

Do you think you might be able to provide a backport of python3.8 in
buster-backports? I'm sure I'm not the only user of buster who would
greatly appreciate having Python 3.8 packaged for it.

Thanks, kind regards,
Greg

Bug#750687: fixed as of buster (Re: "git status" becomes fork-bomb if a submodule's .git directory is not accessible)

[Greg Price]

Control: fixed -1 1:2.20.1-2+deb10u1
Control: fixed -1 1:2.26.2-1~bpo10+1

I tried reproducing this on the Git 2.20 in buster (with the
reproduction recipe from message #14), and it seems it
has been fixed! Same with the Git 2.26 backported from bullseye.

Instead of a fork bomb, there's an error message:

nobody@678fb692c9b5:/tmp/bar$ git status
fatal: 'foo/.git' not recognized as a git repository

which seems pretty OK.

Cheers,
Greg

Bug#958718: lightdm: tight loop trying to start greeter about 85 hours after starting lightdm

[Greg Klanderman]

Package: lightdm
Version: 1.26.0-7
Severity: important

Dear Maintainer,

Around 85 hours after restarting the lightdm service, it goes into a very tight
loop creating greeter sessions which fail immediately.  It is attempting to
start a greeter session 30-50 times per second, filling up
/var/log/lightdm/lightdm.log with Gb of log lines and using significant CPU.

Bugs 895983 and 910050 seem related but not exactly the same.

I have 2 seats configured.

Here is a log excerpt of the first time this happened after the most recent
restart; this sequence then repeats 30-50 times per second:

[+308685.52s] DEBUG: Seat seat-1: Creating greeter session
[+308685.56s] DEBUG: Seat seat-1: Creating display server of type x
[+308685.58s] DEBUG: Seat seat-1: Starting local X display
[+308685.58s] DEBUG: XServer 3: Logging to /var/log/lightdm/x-3.log
[+308685.58s] DEBUG: XServer 3: Writing X server authority to 
/var/run/lightdm/root/:3
[+308685.58s] DEBUG: XServer 3: Launching X Server
[+308685.59s] DEBUG: Launching process 1548921: /usr/bin/X :3 -seat seat-1 
-auth /var/run/lightdm/root/:3 -nolisten tcp
[+308685.59s] DEBUG: XServer 3: Waiting for ready signal from X server :3
[+308685.73s] DEBUG: Seat seat-1: Switching to existing greeter
[+308685.73s] DEBUG: Locking login1 session 2548
[+308685.96s] DEBUG: Process 1548921 exited with return value 1
[+308685.96s] DEBUG: XServer 3: X server stopped
[+308685.96s] DEBUG: XServer 3: Removing X server authority 
/var/run/lightdm/root/:3
[+308685.96s] DEBUG: Seat seat-1: Display server stopped
[+308685.96s] DEBUG: Seat seat-1: Stopping session
[+308685.96s] DEBUG: Seat seat-1: Session stopped
[+308685.96s] DEBUG: Seat seat-1: Stopping display server, no sessions require 
it
[+308685.98s] DEBUG: Seat seat-1: Active display server stopped, starting 
greeter

Errors shown in /var/log/Xorg.3.log:

[111628.803] (EE) systemd-logind: failed to get session: PID 2119345 does not 
belong to any known session
[111628.808] (II) xfree86: Adding drm device (/dev/dri/card0)
[111628.809] (EE) /dev/dri/card0: failed to set DRM interface version 1.4: 
Permission denied
...
[111628.818] (EE) AMDGPU(0): [drm] failed to set drm interface version.
...
[111628.818] (EE) Screen 0 deleted because of no matching config section.
[111628.818] (II) UnloadModule: "amdgpu"
[111628.818] (EE) Screen 0 deleted because of no matching config section.
[111628.818] (II) UnloadModule: "modesetting"
[111628.818] (EE) Fatal server error:
[111628.818] (EE) Cannot run in framebuffer mode. Please specify busIDs
for all framebuffer devices
[111628.818] (EE)
[111628.818] (EE)
Please consult the The X.Org Foundation support
 at http://wiki.x.org
 for help.
[111628.818] (EE) Please also check the log file at "/var/log/Xorg.3.log" for 
additional information.
[111628.818] (EE)
[111628.819] (EE) Server terminated with error (1). Closing log file.


I have attached a longer sample of /var/log/lightdm/lightdm.log, starting from
lightdm being restarted through the beginning of the tight loop trying to start
greeter sessions.  I have also attached a complete /var/log/Xorg.3.log.

I am having to restart lightdm every few days to keep this under control: it is
creating Gb of log, and using a lot of CPU so I have rated severity important.

thank you,
Greg




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

Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lightdm depends on:
ii  adduser3.118
ii  dbus   1.12.16-2
ii  debconf [debconf-2.0]  1.5.74
ii  libaudit1  1:2.8.5-3+b1
ii  libc6  2.30-4
ii  libgcrypt201.8.5-5
ii  libglib2.0-0   2.64.2-1
ii  libpam-systemd [logind]245.4-3
ii  libpam0g   1.3.1-5
ii  libxcb11.14-2
ii  libxdmcp6  1:1.1.2-3
ii  lightdm-gtk-greeter [lightdm-greeter]  2.0.7-1
ii  lsb-base   11.1.0

Versions of packages lightdm recommends:
ii  xserver-xorg  1:7.7+20

Versions of packages lightdm suggests:
ii  accountsservice  0.6.55-1
ii  upower   0.99.11-1
ii  xserver-xephyr   2:1.20.8-2

-- debconf information:
* shared/default-x-display-manager: lightdm
  lightdm/daemon_name: /usr/sbin/lightdm
[+0.48s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.48s] DEBUG: Starting Light Display Man

Bug#930532: xymon: imaps reports "unexpected service response"

[Greg Arnold]

I have a host that is consistently failing the imaps test - with debug
on, I get "tcp_got_expected: No data in banner"

If I run "sudo -u xymon /usr/lib/xymon/server/bin/xymonnet" from the
command line,it seems to always pass the test.

Bug#944025: wiki.debian.org: Instructions for TP-Link TL WN821N Guide do not function as predicted

[Greg Pfister]

Package: wiki.debian.org
Severity: important
Tags: a11y

Dear Maintainer,

   * What led up to the situation?

Installation of recommended USB WIFI device TP-Link TL WN821N which is listed
on WIKI as "confirmed to work"


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

built kernel module following guide on page "https://wiki.debian,org/wifi; - No
Errors on build nor installation of module - on 4.19.0-5-amd64 however recived
the following error in system log: x86/modules: Skipping invalid relocation
target, existing value is nonzero for type 1, loc da5661c0, val
c0f35572"

Removed module, rebooted, ran "make clean", "make", "make install".  Same
resultes.

Please note that under 5.3.0-1-amd64 will NOT make (after a make clean) due to
multiple errors.

   * What was the outcome of this action?
x86/modules: Skipping invalid relocation target, existing value is nonzero for
type 1, loc da5661c0, val c0f35572

   * What outcome did you expect instead?

Expected module to execute and device function properly as listed in Guide.



*  Current Module List

Module  Size  Used by
8814au   1351680  0
fuse  122880  1
cfg80211  761856  1 8814au
rfkill 28672  4 cfg80211
joydev 24576  0
pktcdvd45056  2
intel_rapl 24576  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
snd_hda_codec_conexant24576  1
snd_hda_codec_generic86016  1 snd_hda_codec_conexant
snd_hda_codec_hdmi 57344  1
snd_hda_intel  45056  6
coretemp   16384  0
snd_hda_codec 151552  4
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
snd_hda_core   94208  5
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_hwdep  16384  1 snd_hda_codec
kvm_intel 245760  0
snd_pcm   114688  4
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
sg 36864  0
snd_timer  36864  1 snd_pcm
mei_me 45056  0
kvm   724992  1 kvm_intel
snd94208  20
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm
mei   118784  1 mei_me
soundcore  16384  1 snd
ie31200_edac   16384  0
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
irqbypass  16384  1 kvm
crct10dif_pclmul   16384  0
crc32_pclmul   16384  0
ghash_clmulni_intel16384  0
pcc_cpufreq16384  0
serio_raw  16384  0
evdev  28672  9
intel_cstate   16384  0
intel_uncore  135168  0
intel_rapl_perf16384  0
pcspkr 16384  0
dcdbas 16384  0
parport_pc 32768  0
ppdev  20480  0
lp 20480  0
parport57344  3 parport_pc,lp,ppdev
ip_tables  28672  0
x_tables   45056  1 ip_tables
autofs449152  2
ses20480  0
enclosure  16384  1 ses
scsi_transport_sas 45056  1 ses
ext4  733184  1
crc16  16384  1 ext4
mbcache16384  1 ext4
jbd2  122880  1 ext4
crc32c_generic 16384  0
fscrypto   32768  1 ext4
ecb16384  0
hid_microsoft  16384  0
hid_logitech_hidpp 36864  0
hid_logitech_dj24576  0
hid_generic16384  0
usbhid 57344  0
hid   135168  5
usbhid,hid_microsoft,hid_generic,hid_logitech_dj,hid_logitech_hidpp
uas28672  0
usb_storage73728  2 uas
sr_mod 28672  2
cdrom  65536  2 pktcdvd,sr_mod
sd_mod 61440  3
crc32c_intel   24576  2
radeon   1626112  13
aesni_intel   200704  1
aes_x86_64 20480  1 aesni_intel
i2c_algo_bit   16384  1 radeon
crypto_simd16384  1 aesni_intel
ahci   40960  3
cryptd 28672  3 crypto_simd,ghash_clmulni_intel,aesni_intel
ttm   126976  1 radeon
libahci40960  1 ahci
glue_helper16384  1 aesni_intel
libata270336  2 libahci,ahci
drm_kms_helper200704  1 radeon
ehci_pci   16384  0
r8169  86016  0
ehci_hcd   94208  1 ehci_pci
psmouse   172032  0
i2c_i801   28672  0
realtek20480  1
drm   483328  8 drm_kms_helper,radeon,ttm
libphy 77824  2 r8169,realtek
usbcore   290816  6 8814au,ehci_pci,usbhid,usb_storage,ehci_hcd,uas
scsi_mod  245760  8
ses,scsi_transport_sas,sd_mod,usb_storage,uas,libata,sg,sr_mod

Bug#941987: [Pkg-openssl-devel] Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Greg]

Le 10/10/2019 à 22:38, Kurt Roeckx a écrit :

On Wed, Oct 09, 2019 at 09:22:25AM +0200, Greg wrote:

Confirmed that fixes this issue, thanks !

Is this important enough you want this fixed in stable soon?





Yes. Thanks !


Greg

Signature email

Bug#916670: cryptsetup doesn't work in buster

[Greg Stark]

I have the same problem (though note that the configure script does in
fact exit without an error despite printing the error to the console.
I have to use dpkg-reconfigure to reproduce the error. I assume my
system isn't bootable but I'm not eager to test this):

root@tweedle:~# dpkg-reconfigure initramfs-tools
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.133+deb10u1) ...
update-initramfs: Generating /boot/initrd.img-3.16.0-6-amd64
cryptsetup: ERROR: Couldn't resolve device rootfs

My /etc/mtab is indeed a symlink to /proc/self/mounts

root@tweedle:~# ls -l /etc/mtab
lrwxrwxrwx 1 root root 19 Aug 24  2017 /etc/mtab -> ../proc/self/mounts

root@tweedle:/home/stark# cat /proc/self/mounts
rootfs / rootfs rw 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
udev /dev devtmpfs
rw,nosuid,relatime,size=1984220k,nr_inodes=496055,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=399172k,mode=755 0 0
/dev/mapper/tweedle--vg-root / ext4
rw,relatime,discard,errors=remount-ro,data=ordered 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup
rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd
0 0
pstore /sys/fs/pstore pstore rw,nosuid,nodev,noexec,relatime 0 0
cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0
cgroup /sys/fs/cgroup/net_cls,net_prio cgroup
rw,nosuid,nodev,noexec,relatime,net_cls,net_prio 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup
rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/perf_event cgroup
rw,nosuid,nodev,noexec,relatime,perf_event 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs
rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
hugetlbfs /dev/hugepages hugetlbfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
sunrpc /run/rpc_pipefs rpc_pipefs rw,relatime 0 0
/dev/sda1 /boot ext2 rw,relatime 0 0
tmpfs /run/user/122 tmpfs
rw,nosuid,nodev,relatime,size=399168k,mode=700,uid=122,gid=126 0 0
gvfsd-fuse /run/user/122/gvfs fuse.gvfsd-fuse
rw,nosuid,nodev,relatime,user_id=122,group_id=126 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
tmpfs /run/user/1000 tmpfs
rw,nosuid,nodev,relatime,size=399168k,mode=700,uid=1000,gid=1000 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse
rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0


-- 
greg

Bug#941987: [Pkg-openssl-devel] Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Greg]

Confirmed that fixes this issue, thanks !

Greg


Le 08/10/2019 à 23:44, Ondřej Surý a écrit :

Yes, I can confirm it fixes the PHP case:

# php -r 'var_dump(openssl_get_cipher_methods());' | grep 'aes-.*-hmac'
   string(21) "aes-128-cbc-hmac-sha1"
   string(23) "aes-128-cbc-hmac-sha256"
   string(21) "aes-256-cbc-hmac-sha1"
   string(23) "aes-256-cbc-hmac-sha256”

Ondrej
--
Ondřej Surý
ond...@sury.org



Signature email

Bug#941987: libssl1.1: Ciphers AES-*-CBC-HMAC-* are missing in libssl 1.1.1d, but available in 1.1.1c

[Greg]

Package: libssl1.1
Version: 1.1.1c-1+0~20190710.13+debian10~1.gbp359e02
Severity: normal

Dear Maintainer,

   * What led up to the situation?
   Upgraded package libssl1.1 from 1.1.1c to 1.1.1d

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Downgraded to 1.1.1c

   * What was the outcome of this action?
   4 more ciphers were back



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

Kernel: Linux 4.19.0-6-amd64 (SMP w/16 CPU cores)
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=en_US:en (charmap=UTF-8)

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

Versions of packages libssl1.1 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10

libssl1.1 recommends no packages.

libssl1.1 suggests no packages.

-- debconf information excluded


Signature email

Bug#934717: closed by Sven Joachim (Bug#934717: fixed in xterm 348-2)

[Greg Klanderman]

Thank you Thomas and Sven!

Greg

Bug#934717: xterm: fullscreen:never resource causes "xterm: Unrecognized keyword: never" warning

[Greg Klanderman]

Package: xterm
Version: 348-1
Severity: normal

Dear Maintainer,

I notice that in xterm 348 (vs 337), I am seeing the following warning when
starting xterm from a shell:

| xterm: Unrecognized keyword: never

This is being caused by the following resource setting:

XTerm*fullscreen: never

and additionally, the resource is not having any effect (fullscreen is not being
inhibited).

I looked briefly at the v348 source and it seemed that "never" is still intended
as a supported value.

thank you,
Greg


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C), LANGUAGE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xterm depends on:
ii  libc6   2.28-10
ii  libfontconfig1  2.13.1-2
ii  libfreetype62.9.1-4
ii  libice6 2:1.0.9-2
ii  libtinfo6   6.1+20190713-2
ii  libutempter01.1.6-3+b1
ii  libx11-62:1.6.7-1
ii  libxaw7 2:1.0.13-1+b2
ii  libxext62:1.3.3-1+b2
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.1.5-1+b3
ii  xbitmaps1.1.1-2

Versions of packages xterm recommends:
ii  x11-utils  7.7+4

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information

Bug#932926: [klibc-utils] fstype: ext4 detection broken with compressed modules

[Greg Edwards]

Package: klibc-utils
Version: 2.0.6-1
Severity: normal

Dear Maintainer,

The check_for_modules() function in the fstype utility does not correctly match
compressed kernel modules, which can result in a failure to mount an ext4 root
file system from the initramfs.

Booting a debian 10 ext4 root with a vanilla 4.19.60 kernel built with
CONFIG_MODULE_COMPRESS=y, CONFIG_MODULE_COMPRESS_XZ=y, and CONFIG_EXT4_FS=m,
the initramfs will fail to mount the ext4 root file system:


Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Will now check root file system ... fsck from util-linux 2.33.1
[/sbin/fsck.ext4 (1) -- /dev/vda1] fsck.ext4 -a -C0 /dev/vda1
/dev/vda1: clean, 112319/524288 files, 736358/2096640 blocks
done.
mount: mounting /dev/vda1 on /root failed: No such device
Failed to mount /dev/vda1 as root file system.


This is due to the klibc's fstype utility failing to match the compressed ext4
module:


(initramfs) /usr/bin/fstype /dev/vda1
FSTYPE=ext4dev <-- here (should be 'ext4')
FSSIZE=8587837440


This results in the ext4 module not being loaded, and the mount failure.  You
can manually load the driver, mount the file system, and continue the boot.


(initramfs) modinfo ext4
filename:   /lib/modules/4.19.60/kernel/fs/ext4/ext4.ko.xz
author: Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, 
Theodore Ts'o and others
description:Fourth Extended Filesystem
license:GPL
alias:  fs-ext4
alias:  ext3
alias:  fs-ext3
alias:  ext2
alias:  fs-ext2
depends:mbcache,jbd2
intree: Y
vermagic:   4.19.60 SMP mod_unload
(initramfs) lsmod | grep ext4
(initramfs) modprobe ext4
(initramfs) lsmod | grep ext4
ext4  634880  0
mbcache16384  1 ext4
jbd2  102400  1 ext4
(initramfs) mount /dev/vda1 /root
[  115.810557] EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: 
(null)
(initramfs) exit


Attached patch resolves it for me.


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

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

Versions of packages klibc-utils depends on:
ii  libklibc  2.0.6-1

klibc-utils recommends no packages.

klibc-utils suggests no packages.

-- no debconf information
From 3512325b51eccef3a16a4a610b3bc825ef5c77c3 Mon Sep 17 00:00:00 2001
From: Greg Edwards 
Date: Tue, 23 Jul 2019 13:57:56 -0600
Subject: [PATCH] [klibc] fstype: match compressed kernel modules

check_for_modules() does not correctly match compressed modules, e.g.
ext4.ko.xz.  Instead of comparing the end of the string to ".ko", search
for the ".ko" substring, and truncate it there if we find a match.

Signed-off-by: Greg Edwards 
---
 usr/kinit/fstype/fstype.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/usr/kinit/fstype/fstype.c b/usr/kinit/fstype/fstype.c
index c5a143286919..885b44fc2f9f 100644
--- a/usr/kinit/fstype/fstype.c
+++ b/usr/kinit/fstype/fstype.c
@@ -160,7 +160,6 @@ static int check_for_modules(const char *fs_name)
 	struct utsname	uts;
 	FILE		*f;
 	char		buf[1024], *cp, *t;
-	int		i;
 
 	if (uname())
 		return 0;
@@ -178,12 +177,9 @@ static int check_for_modules(const char *fs_name)
 		if (cp == NULL)
 			continue;
 		cp++;
-		i = strlen(cp);
-		if (i > 3) {
-			t = cp + i - 3;
-			if (!strcmp(t, ".ko"))
-*t = 0;
-		}
+		t = strstr(cp, ".ko");
+		if (t)
+			*t = 0;
 		if (!strcmp(cp, fs_name)) {
 			fclose(f);
 			return 1;
-- 
2.21.0

Bug#932000: In testing

[Greg Hudson]

Candidate patch here:

https://github.com/krb5/krb5/pull/954

Bug#932000: libgssapi-krb5-2: gss_krb5int_set_allowable_enctypes breaks NFSv4 after removal of deprecated DES enctypes in 1.17-4

[Greg Hudson]

I think gss_krb5int_set_allowable_enctypes() should filter out invalid
enctypes, and only fail if no enctypes remain after filtering.  The
current logic would also fail if the kernel supported an enctype which
libkrb5 did not (e.g. if the kernel gained support for the aes-sha2
enctypes, and someone upgraded to a new kernel on a system with
krb5-1.14 or previous).

Bug#926501: xpdf: continuous memory leak

[Greg Alexander]

I experience this same problem.  When browsing around the end of an 800
page PDF, xpdf will consume 250MB/sec!  Also, it is very slow.  I have
manually downgraded xpdf from 3.04-13 several times on different
computers because of this bug.  Is xpdf abandoned?  I understand if it's
difficult to update to 4.0x but xpdf has been essentially unusable since
January.

If I go through the trouble of generating the one-line patch that will
fix this bug, is there anyone out there that might apply it and issue
3.04-14?

- Greg

Bug#930693: ksh: previous versions have the info

[Greg Wooledge]

Having ksh removed from buster is definitely not my preferred outcome.
Getting one line added to the copyright file would be ideal, but if
that's not allowed, then I can live with "fixed after buster".

Bug#930693: ksh: no Source field in copyright file

[Greg Wooledge]

Package: ksh
Version: 93u+20120801-3.4
Severity: serious
Justification: Policy 12.5

There is no Source field, nor any other information saying where the
upstream sources were obtained, in the copyright file.

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

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

Versions of packages ksh depends on:
ii  binfmt-support  2.2.0-2
ii  libc6   2.28-10

ksh recommends no packages.

ksh suggests no packages.

-- debconf-show failed

Bug#929984: lspci: please make -nn the default

[Greg Wooledge]

Package: pciutils
Version: 1:3.5.2-1
Severity: wishlist

Very frequently, people ask for help with their devices (video, network,
etc.) and someone asks them to show the output of lspci.  Which they
eventually do.  But it would be *so* much more helpful if they would
show the output of "lspci -nn" instead.  Unfortunately, educating the
entire helper community to ask for lspci -nn instead of plain lspci is
an extremely slow process.

It would be great if -nn were the default.  People requesting help could
get that help much more quickly and with less wasted effort, if we didn't
have to go through an extra round of asking for information.

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

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

Versions of packages pciutils depends on:
ii  libc6 2.28-10
ii  libkmod2  26-1
ii  libpci3   1:3.5.2-1

pciutils recommends no packages.

Versions of packages pciutils suggests:
ii  bzip2  1.0.6-9
ii  curl   7.64.0-3
ii  wget   1.20.1-1.1

-- debconf-show failed

Bug#929677: su: man page: runuser(8) vs. runuser(1)

[Greg Wooledge]

Package: util-linux
Version: 2.33.1-0.1
Severity: minor

The su(1) man page mentions runuser(1) (which is correct) in the DESCRIPTION
section, but runuser(8) (which does not exist) in the SEE ALSO section.

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

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

Versions of packages util-linux depends on:
ii  fdisk  2.33.1-0.1
ii  libaudit1  1:2.8.4-3
ii  libblkid1  2.33.1-0.1
ii  libc6  2.28-10
ii  libcap-ng0 0.7.9-2
ii  libmount1  2.33.1-0.1
ii  libpam0g   1.3.1-5
ii  libselinux12.8-1+b1
ii  libsmartcols1  2.33.1-0.1
ii  libsystemd0241-3
ii  libtinfo6  6.1+20181013-2
ii  libudev1   241-3
ii  libuuid1   2.33.1-0.1
ii  login  1:4.5-1.1
ii  zlib1g 1:1.2.11.dfsg-1

util-linux recommends no packages.

Versions of packages util-linux suggests:
pn  dosfstools  
ii  kbd 2.0.4-4
ii  util-linux-locales  2.33.1-0.1

-- debconf-show failed

Bug#878625:

[Greg Wooledge]

I just discovered today that this bug is related to (and is perhaps the
fundamental cause of) other issues I've been seeing.

Specifically, systemd-logind not being able to recognize my NIS user
account resulted in my not being able to start X (via startx) without
hacking the Xwrapper.config to revert to running X as root.  This was
reported under Debian Bug#833182 because at the time, one of my symptoms
(the "drmSetMaster(): Permission denied" error) matched the subject of
that bug, and I am also on Intel graphics.  So, it seemed like the same
bug.

The other symptoms, which I only noticed more recently, were the complete
lack of all XDG_* environment variables and the lack of a /run/user/MYUID
directory, all of which were supposed to be present in my login sessions.

After installing nscd and rebooting (it didn't work until reboot), all
of these symptoms have been cleared up.  I was able to remove the
needs_root_rights=yes line in the /etc/X11/Xwrapper.config file and
start X without root again.

I don't know if there's a less drastic measure than rebooting that can
make nscd "kick in".

Bug#833182: drmSetMaster failed: Permission denied

[Greg Wooledge]

Actually, won't need a new bug: it's already filed.  Bug#878625.

Bug#833182: drmSetMaster failed: Permission denied

[Greg Wooledge]

Yesterday I noticed another issue and wondered if it might be related
to this one.  Turns out: yes, it is.

The issue as I observed it was the complete lack of all XDG_* environment
variables when I logged in.  Didn't matter whether it was console or ssh.
(There was also no /run/user/MYUID directory created for me.)

After some digging, I found that there is a known issue in recent
systemd: 

Long story short, any user defined by a network service like NIS will not
work in systemd because systemd-logind runs (by default config) in a
no-networking-allowed sandbox.  And my user account is defined in NIS.

There are multiple possible workarounds.  The one I tried first was
installing the nscd package.  That didn't fix it immediately, but it
*did* fix it after rebooting.  So, I never moved on to other potential
solutions such as defining a drop-in override for systemd-logind to turn
off the IPAddressDeny=any feature.  That may be better or worse; I can't
say.

My problem may be different from others in this thread, despite the
same symptomatic error message in the X log.  I'm going to open a
separate bug against the nis package just in case; if it turns out that
I'm wrong, then the bug can be marked as a duplicate.

Bug#928125: Revert commit 310ca162d77

[Greg KH]

On Mon, Apr 29, 2019 at 02:05:42PM +0200, Salvatore Bonaccorso wrote:
> Hi Jan, hi Greg,
> 
> On Wed, Mar 20, 2019 at 01:58:06PM +0100, Jan Kara wrote:
> > Hello,
> > 
> > commit 310ca162d77 "block/loop: Use global lock for ioctl() operation." has
> > been pushed to multiple stable trees. This patch is a part of larger series
> > that overhauls the locking inside loopback device upstream and for 4.4,
> > 4.9, and 4.14 stable trees only this patch from the series is applied. Our
> > testing now has shown [1] that the patch alone makes present deadlocks
> > inside loopback driver more likely (the openqa test in our infrastructure
> > didn't hit the deadlock before whereas with the new kernel it hits it
> > reliably every time). So I would suggest we revert 310ca162d77 from 4.4,
> > 4.9, and 4.14 kernels.
> 
> A user in Debian reported [1], providing the following testcase which showed 
> up
> after the recent update to 4.9.168-1 in Debian stretch (based on upstream
> v4.9.168) as follows:
> 
>   dd if=/dev/zero of=/tmp/ff1.raw bs=1G seek=8 count=0
>   sync
>   sleep 1
>   parted /tmp/ff1.raw mklabel msdos
>   parted -s /tmp/ff1.raw mkpart primary linux-swap 1 100
>   parted -s -- /tmp/ff1.raw mkpart primary ext2 101 -1
>   parted -s -- /tmp/ff1.raw set 2 boot on
>   sleep 5
>   losetup -Pf /tmp/ff1.raw --show
> 
> I have verified that the same happens with v4.9.171 where the mentioned commit
> was not reverted, and bisecting of the testcase showed it was introduced with
> 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 (v4.9.152~9) (which is the backport 
> of
> 310ca162d77 for 4.9).
> 
> Reverting 3ae3d167f5ec2c7bb5fcd12b7772cfadc93b2305 on top of v4.9.171 worked
> and fixed the respective issue.
> 
> Can this commit in meanwhile be reverted or is there further ongoing work in
> integrating the followup fixes as mentioned in
> https://lore.kernel.org/stable/20190321104110.gf29...@quack2.suse.cz/ .

Sorry for the delay here.  No, I didn't find any time for the followup
stuff here, and Jan is right, this should just be dropped.

I've now reverted it from 3.18.y, 4.4.y, 4.9.y, and 4.14.y.

thanks,

greg k-h

Bug#881771: Unclear which interface name will be used

[Greg Wooledge]

In the release notes, there's a udevadm command which is supposed to
tell us what the new interface name will be, but I had some trouble
interpreting the output.

wooledg:~$ udevadm test-builtin net_id /sys/class/net/eno1 2>/dev/null
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxa08cfdc389e0
ID_OUI_FROM_DATABASE=Hewlett Packard
ID_NET_NAME_ONBOARD=eno1
ID_NET_LABEL_ONBOARD=enOnboard Lan
ID_NET_NAME_PATH=enp0s31f6

That's after the upgrade to buster; I did not save the results from
before the upgrade, but basically it would have been the same command
with /sys/class/net/eth0 as the final argument, with the same output.

I thought the new interface name would be enp0s31f6 but it turned out
to be eno1 instead.

tl;dr: there's nothing "predicatable" about these names.

Bug#833182: drmSetMaster failed: Permission denied

[Greg Wooledge]

On Tue, Apr 02, 2019 at 12:10:59AM +0200, Thanatermesis wrote:
> If you installed systemd, maybe you need to install libpam-systemd too to
> solve this issue

It's installed.  I showed it specifically because it was mentioned in
this bug.

> El lun., 1 abr. 2019 a las 17:18, Greg Wooledge ()
> escribió:
> 
> > Various packages that are installed:
> >
> > wooledg:~$ dpkg -l linux-image\* libpam-systemd xserver-xorg-\* | grep
> > '^.i'
> > ii  libpam-systemd:amd64241-1amd64
> > system and service manager - PAM module

Bug#833182: drmSetMaster failed: Permission denied

[Greg Wooledge]

I ran into this bug upon upgrading from stretch to buster today.

This system is an HP EliteDesk desktop PC with:

00:00.0 Host bridge [0600]: Intel Corporation Skylake Host Bridge/DRAM 
Registers [8086:191f] (rev 07)
00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 
[8086:1912] (rev 06)


I have the relevant non-free firmware installed.

wooledg:~$ sudo dmesg | grep -i firmware
[sudo] password for wooledg: 
[0.194776] Spectre V2 : Enabling Restricted Speculation for firmware calls
[0.231494] ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored
[3.892737] i915 :00:02.0: firmware: direct-loading firmware 
i915/skl_dmc_ver1_27.bin
[3.893012] [drm] Finished loading DMC firmware i915/skl_dmc_ver1_27.bin 
(v1.27)


Under stretch, I was able to run 'startx' from tty1 as my non-root user
account, without needs_root_rights=yes in Xwrapper.config.  X ran as me,
using the modeset driver, and logged in ~/.local/share/xorg/.

After the upgrade, running startx gave me these errors:

wooledg:~$ grep EE .local/share/xorg/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1140.120] (EE) systemd-logind: failed to get session: PID 1762 does not 
belong to any known session
[  1140.193] (EE) modeset(0): drmSetMaster failed: Permission denied
[  1140.193] (EE)
[  1140.193] (EE) AddScreen/ScreenInit failed for driver 0
[  1140.193] (EE)
[  1140.193] (EE)
[  1140.193] (EE) Please also check the log file at 
"/home/wooledg/.local/share/xorg/Xorg.0.log" for additional information.
[  1140.193] (EE)
[  1140.205] (EE) Server terminated with error (1). Closing log file.


I used lynx from the console to search for a workaround.  I tried purging
the xserver-xorg-legacy package, without success.  I tried reinstalling
it, without success.

I ended up putting needs_root_rights=yes in /etc/X11/Xwrapper.config.
Now, it runs as root, and logs in /var/log/, but at least it's working.

wooledg:~$ grep EE /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1178.050] (EE) systemd-logind: failed to get session: PID 1812 does not 
belong to any known session
[  1178.270] (II) Initializing extension MIT-SCREEN-SAVER


I can't tell whether the systemd-logind error is relevant or not.

Various packages that are installed:

wooledg:~$ dpkg -l linux-image\* libpam-systemd xserver-xorg-\* | grep '^.i'
ii  libpam-systemd:amd64241-1amd64
system and service manager - PAM module
ii  linux-image-4.19.0-4-amd64  4.19.28-2amd64
Linux 4.19 for 64-bit PCs (signed)
ii  linux-image-4.9.0-7-amd64   4.9.110-3+deb9u2 amd64
Linux 4.9 for 64-bit PCs
ii  linux-image-4.9.0-8-amd64   4.9.144-3.1  amd64
Linux 4.9 for 64-bit PCs
ii  linux-image-amd64   4.19+104 amd64
Linux for 64-bit PCs (meta-package)
ii  xserver-xorg-core   2:1.20.3-1   amd64
Xorg X server - core server
ii  xserver-xorg-input-all  1:7.7+19 amd64
X.Org X server -- input driver metapackage
ii  xserver-xorg-input-libinput 0.28.2-1 amd64
X.Org X server -- libinput input driver
ii  xserver-xorg-input-wacom0.34.99.1-1  amd64
X.Org X server -- Wacom input driver
ii  xserver-xorg-legacy 2:1.20.3-1   amd64
setuid root Xorg server wrapper
ii  xserver-xorg-video-all  1:7.7+19 amd64
X.Org X server -- output driver metapackage
ii  xserver-xorg-video-amdgpu   18.1.99+git20190207-1amd64
X.Org X server -- AMDGPU display driver
ii  xserver-xorg-video-ati  1:18.1.99+git20190207-1  amd64
X.Org X server -- AMD/ATI display driver wrapper
ii  xserver-xorg-video-fbdev1:0.5.0-1amd64
X.Org X server -- fbdev display driver
ii  xserver-xorg-video-intel2:2.99.917+git20180925-2 amd64
X.Org X server -- Intel i8xx, i9xx display driver
ii  xserver-xorg-video-nouveau  1:1.0.16-1   amd64
X.Org X server -- Nouveau display driver
ii  xserver-xorg-video-qxl  0.1.5-2+b1   amd64
X.Org X server -- QXL display driver
ii  xserver-xorg-video-radeon   1:18.1.99+git20190207-1  amd64
X.Org X server -- AMD/ATI Radeon display driver
ii  xserver-xorg-video-vesa 1:2.4.0-1amd64
X.Org X server -- VESA display driver
ii  xserver-xorg-video-vmware   1:13.3.0-2   amd64
X.Org X server -- VMware display driver

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Greg Hudson]

On Fri, 4 Jan 2019 19:24:52 -0500 Greg Hudson  wrote:
> krb5_mcc_start_seq_get() is in the traceback, so the memory cache change
> is a clear candidate for the bug.  I can't find anything wrong with the
> code, though.  From the stack trace, there appears to be a memory ccache
> on the list with an invalid mutex, but I don't see any way of getting
> into that state.

I found the bug.  krb5_mcc_ptcursor_next() is not increasing the
refcount on the caches it yields.  The per-type cursor is also subject
to badness if what would have been the next cache is destroyed before it
is yielded, either by a separate thread or by a single thread doing
cache destroy operations in the midst of the iteration.

My plan is to backport commit 49bb627fed70c5258c151c5135ac3d95ed1ee55d
from the master branch and issue new 1.15.x and 1.16.x releases.
Apologies for the release branch regression; in hindsight I should have
decided that commit 146dadec8fe7ccc4149eb2e3f577cc320aee6efb was too big
to backport.

Bug#918088: Acknowledgement (autofs-ldap: automount dies with SIGABRT after libkrb5-3 upgrade - "(k5_mutex_lock: Assertion `r == 0' failed.)")

[Greg Hudson]

On Fri, 04 Jan 2019 15:54:01 -0500 Sam Hartman  wrote:
> There are no thread support changes between 1.16.1 and 1.16.2.
> There is one ccache related change which I'll include below related to
> memory ccaches.
> Do you know what type of credential cache  is being used here?

krb5_mcc_start_seq_get() is in the traceback, so the memory cache change
is a clear candidate for the bug.  I can't find anything wrong with the
code, though.  From the stack trace, there appears to be a memory ccache
on the list with an invalid mutex, but I don't see any way of getting
into that state.

Bug#917141: isc-dhcp-client: error in syslog: nslcd: request denied by validnames option

[greg]

Package: isc-dhcp-client
Version: 4.3.5-3+deb9u1
Severity: minor

dhclient seems to request a username from nslcd with a wildcard "*".
This is denied by nslcd.

Every time dhclient is runs, the following is in syslog:

Dec 23 07:48:50 dhclient[1183]: DHCPREQUEST of 81.16.33.27 on eth0 to 
81.16.33.2 port 67
Dec 23 07:48:50 dhclient[1183]: DHCPACK of 81.16.33.27 from 81.16.33.2
Dec 23 07:48:50 nslcd[21573]: [885e1b] DEBUG: connection from pid=504 uid=0 
gid=0
Dec 23 07:48:50 nslcd[21573]: [885e1b]  request denied by 
validnames option
Dec 23 07:48:50 dhclient[1183]: bound to 81.16.33.27 -- renewal in 1234 seconds.


-- System Information:
Debian Release: 9.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.9.0-8-armmp-lpae (SMP w/1 CPU core)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages isc-dhcp-client depends on:
ii  debianutils   4.8.1.1
ii  iproute2  4.9.0-1+deb9u1
ii  libc6 2.24-11+deb9u3
ii  libdns-export162  1:9.10.3.dfsg.P4-12.3+deb9u4
ii  libisc-export160  1:9.10.3.dfsg.P4-12.3+deb9u4

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.3.5-3+deb9u1

Versions of packages isc-dhcp-client suggests:
pn  avahi-autoipd 
pn  isc-dhcp-client-ddns  
ii  resolvconf1.79

-- no debconf information

Bug#912550: logcheck-database: courier-imaps add (-ssl)?

[Greg]

Package: logcheck-database
Severity: wishlist

Dear Maintainer,

please consider changing the beginning of the regexs of the file courier-imap 
from:

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ imapd:

to

^\w{3} [ :0-9]{11} [._[:alnum:]-]+ imapd(-ssl)?:

because with ssl enabled the same messages seems to appear.


Thank you

-- System Information:
Debian Release: 9.5
  APT prefers stable
  APT policy: (500, 'stable')

Bug#785237: Ubuntu 14.04 issues as well

[Greg Trounson]

I am seeing this behaviour in a suite of lab computers.  Students hit
the space bar to either power up the computer or bring the monitor out
of sleep.  In the latter case that keypress propagates to the username
field in lightdm-gtk-greeter, so an invalid username is processed when
they try to login.

Stripping whitespace in the username field, or otherwise checking for
IEEE 1003.1-2001 compliance would fix this.

Bug#896911: e1000e msix interrupts broken in linux 4.15

[Greg Kroah-Hartman]

On Tue, Sep 18, 2018 at 01:37:34PM +0100, Ben Hutchings wrote:
> Greg,
> 
> On Tue, 2018-09-18 at 13:29 +0100, Ben Hutchings wrote:
> > On Tue, 2018-09-18 at 09:12 +, Yanhui He wrote:
> > > Hi David,
> > > 
> > > Would you please help us push this fix in the new Debian release?
> > > 
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896911
> > 
> > David Miller doesn't send updates for 4.9 any more.
> > 
> > Based on your list of commit subjects, I found:
> > 
> > 745d0bd3af99 e1000e: Remove Other from EIAC
> > 1f0ea19722ef Partial revert "e1000e: Avoid receiver overrun interrupt 
> > bursts"
> > 361a954e6a72 e1000e: Fix queue interrupt re-raising in Other interrupt
> > 116f4a640b31 e1000e: Avoid missed interrupts following ICR read
> > 4e7dc08e57c9 e1000e: Fix check_for_link return value with autoneg off
> > 3016e0a0c912 Revert "e1000e: Separate signaling for link check/link up"
> > e2710dbf0dc1 e1000e: Fix link check race condition
> > 
> > "e1000e: Fix check_for_link return value with autoneg off" was already
> > appplied to 4.9-stable but the others have not been.
> 
> Please queue up the above commits for 4.14 (they apply cleanly).
> 
> Please queue up the patches from the attached mailbox file for 4.9.
> 
> Your other stable branches should be unaffected.

Thanks for these, all now queued up.

greg k-h

Bug#909142: Addition to bug, its not first highlighted wireless net, its any net which was configured with passphrase

[Greg Masters]

Hello, I forgot to say thank you.  Your fast response was unexpected!

To add: ipv6 is disabled (sysctl)
and network-manager is disabled as a service (systemd) and is not running

If that makes any difference

On 9/18/18, Axel Beckert  wrote:
> Control: tag -1 - moreinfo
>
> Hi Greg,
>
> Greg Masters wrote:
>> I have to revise this a little. It appears my report about the bug in
>> relation to the first wireless net was wrong.  It happens when
>> right-arrow any net **with** a changed config, like the addition of a
>> wpa passphrase. In my last post the net with the changed config file
>> contained the passphrase.  BTW i deleted all configs (*.conf) in
>> /etc/wicd and started over, with no change.
>>
>> The (P) prefs option to always show wirred nets is in unselected.
>>
>> Here is the trace as requested:
>
> Thanks for the additional details!
>
>   Regards, Axel
> --
>  ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
> : :' :  |  Debian Developer, ftp.ch.debian.org Admin
> `. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
>   `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
>

Bug#909142: Addition to bug, its not first highlighted wireless net, its any net which was configured with passphrase

[Greg Masters]

I have to revise this a little. It appears my report about the bug in
relation to the first wireless net was wrong.  It happens when
right-arrow any net **with** a changed config, like the addition of a
wpa passphrase. In my last post the net with the changed config file
contained the passphrase.  BTW i deleted all configs (*.conf) in
/etc/wicd and started over, with no change.

The (P) prefs option to always show wirred nets is in unselected.

Here is the trace as requested:

Traceback (most recent call last):
  File "/usr/share/wicd/curses/wicd-curses.py", line 1149, in call_update_ui
self.update_ui(True)
  File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper
return func(*args, **kargs)
  File "/usr/share/wicd/curses/wicd-curses.py", line 1162, in update_ui
self.handle_keys(input_data)
  File "/usr/share/wicd/curses/wicd-curses.py", line 1040, in handle_keys
self.diag = WirelessSettingsDialog(pos, self.frame)
  File "/usr/share/wicd/curses/netentry_curses.py", line 503, in __init__
self.set_values()
  File "/usr/share/wicd/curses/netentry_curses.py", line 544, in set_values
wireless.GetWirelessProperty(networkID, 'bitrate')
ValueError: dbus.Boolean(True) is not in list
root@orangepizeroplus:~#

Bug#909142: wicd-curses: Right-arrow on first wlan errors wicd-curses.py

[Greg Masters]

Package: wicd-curses
Version: 1.7.4+tb2-6
Severity: important

Dear Maintainer,

I am working with the newest version of wicd-curses installed from .deb 
manually using dpkg.  I installed wicd_1.7.4+tb2-6all.deb, and wicd-curses, 
python-wicd, wicd-daemon all of the same version number.  The latest are
not in the repos.  They supposedly fixed similar errors as in debian 
bug 816597. This errors flag lines 97, 1149, 1162, 1040 in 
/usr/share/wicd/wicd-curses-py.
And file /usr/share/wicd/curses/netentry_curses.py, line 503 and 544.

Last line after crash is ValueError: dbus.Boolean(True) is not in list

On invoking wicd-curses, any attempt to right-arrow on the FIRST
LISTED wireless net will crash.  If the highlight bar is moved (down
arrow) to the second or third wireless net, then right-arrow brings
up the config screen as expected.  

Request: Fix the right-arrow behavior to be consisitent.

Thank you

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

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

Versions of packages wicd-curses depends on:
ii  python2.7.13-2
ii  python-urwid  1.3.1-2+b1
ii  wicd-daemon   1.7.4+tb2-6

Versions of packages wicd-curses recommends:
ii  sudo  1.8.19p1-2.1

wicd-curses suggests no packages.

Versions of packages wicd depends on:
ii  wicd-daemon  1.7.4+tb2-6

Versions of packages wicd-cli depends on:
ii  python   2.7.13-2
ii  wicd-daemon  1.7.4+tb2-6

Versions of packages wicd-cli recommends:
ii  sudo  1.8.19p1-2.1

Versions of packages wicd-gtk depends on:
ii  python 2.7.13-2
pn  python-glade2  
pn  python-gtk2
ii  wicd-daemon1.7.4+tb2-6

Versions of packages wicd-gtk recommends:
ii  policykit-10.105-18
pn  python-notify  

Versions of packages wicd-daemon depends on:
ii  adduser   3.115
ii  dbus  1.10.26-0+deb9u1
ii  debconf   1.5.61
ii  iputils-ping  3:20161105-1
ii  isc-dhcp-client   4.3.5-3+deb9u1
ii  lsb-base  9.20161125
ii  psmisc22.21-2.1+b2
ii  python2.7.13-2
ii  python-dbus   1.2.4-1+b1
ii  python-gobject-2  2.28.6-13
ii  python-wicd   1.7.4+tb2-6
ii  wireless-tools30~pre9-12+b1
ii  wpasupplicant 2:2.4-1+deb9u1

Versions of packages wicd-daemon recommends:
ii  rfkill  0.5-1+b1

Versions of packages wicd-daemon suggests:
pn  pm-utils  

Versions of packages python-wicd depends on:
ii  net-tools  1.60+git20161116.90da8a0-1
ii  python 2.7.13-2

Versions of packages python-wicd suggests:
ii  ethtool   1:4.8-1+b1
ii  iproute2  4.9.0-1+deb9u1

-- debconf information:
* wicd/users:

Bug#905918:

[Greg Wright]

I'm experiencing this on Buster

Running from terminal as suggested by launchpad thread yields this output
(I forgot about it and left it for a few hours so it loops)

✘ ~ ≻≻≻  caffeine
INFO:root:caffeine is inhibiting desktop idleness
org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.SessionManager was not provided by any .service files
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness
INFO:root:caffeine is inhibiting desktop idleness
Protocol error: bad 3 (Window); Sequence Number 11
 Opcode (20, 0) = GetProperty
 Bad resource 0 (0x0)
 at -e line 15.
INFO:root:caffeine is no longer inhibiting desktop idleness

Bug#896904: Upstream version 2.0.3 fixes issue

[Greg Price]

Several reports on the web say that this issue is fixed by installing
Vagrant 2.0.3, from upstream's own .deb package:
  https://github.com/dotless-de/vagrant-vbguest/issues/292
  https://github.com/devopsgroup-io/vagrant-hostmanager/issues/256

And indeed that worked for me just now on buster, after I'd gotten this
issue on vagrant 2.0.2+dfsg-3 .

I don't see anything in upstream's changelog for 2.0.3 that looks like a
fix:

https://github.com/hashicorp/vagrant/blob/master/CHANGELOG.md#203-march-15-2018
but *shrug*; empirically the fix is there.

(Upstream seems to make a release every month or so, so that's no longer
the latest; they're up to 2.1.2.)

Cheers,
Greg

Bug#901279: duplicate of bug #250626

[Greg Alexander]

Hi again - Sorry I had a problem and didn't check if this bug is already
listed.  It may be the same as bug #250626.  I'm not clear on how to
merge it so I'll leave that for someone else if it's appropriate.

However, this bug should not be given severity of "wishlist", it occurred
on a normal "apt-get update" package upgrade, and information was lost
for no reason.  I suppose the idea is that now we should treat grub.cfg
as output and instead put our configuration in /etc/grub.d.  But the fact
that we have not done this yet is no reason to delete our old
configuration!

For god's sake, simply make update-grub script "mv grub.cfg grub.cfg~"
before it overwrites it!  Arguing why it was appropriate to delete user
information is crap.

Thanks,
- Greg

Bug#792394: vtund sends UDP socket number over the network in host order

[Greg Alexander]

severity 792394 important
tags 792394 patch ipv6

Hi!  I ran into this same problem.  The patch
07-dual-family-transport.patch changed it to use host order instead of
network order when sending the UDP port number to the remote host.

Background: When a vtun client connects, it first connects on a TCP port
and gets configuration.  If that configuration tells it to connect on a
UDP port, then there is a bidirectional exchange of UDP port numbers over
the TCP port just before closing the TCP socket.  This exchange is
supposed to happen in network byte order, but an oversight in the patch
caused it to happen in host byte order instead.

Discussion: This is a sticky problem because if you fix it, some small
number of users who had successfully upgraded both endpoints of a tunnel
to the same wrong version will experience difficulty.  The exposure is
somewhat limited by the fact that many users probably do not use UDP.
Also in our favor is that vtund is largely used for historical
compatibility (new Debian<=>Debian tunnels would probably use OpenVPN?)
by users who probably do not upgrade any more often than I do...

At any rate, the current situation is wrong.  Even modern Debian hosts
with different byte orders will be unable to talk to eachother.

Here's my patch, which is relative to the tree after an
"apt-get source vtun".  I'm confident in it (I'm using it right now), but
I'm sorry I don't really know anything about debian packaging so I just
hope this is useful for you guys..

Thanks! - Greg

diff -ur vtun-3.0.3.orig/netlib.c vtun-3.0.3/netlib.c
--- vtun-3.0.3.orig/netlib.c2018-06-13 20:11:33.0 -0400
+++ vtun-3.0.3/netlib.c 2018-06-13 20:30:01.0 -0400
@@ -224,18 +224,19 @@
  }
 
  /* Write port of the new UDP socket */
- port = get_port();
+ host->sopt.lport = get_port();
+ port = htons(host->sopt.lport);
  if( write_n(host->rmt_fd,(char *),sizeof(short)) < 0 ){
 vtun_syslog(LOG_ERR,"Can't write port number");
 return -1;
  }
- host->sopt.lport = htons(port);
 
  /* Read port of the other's end UDP socket */
  if( readn_t(host->rmt_fd,,sizeof(short),host->timeout) < 0 ){
 vtun_syslog(LOG_ERR,"Can't read port number %s", strerror(errno));
 return -1;
  }
+ port = ntohs(port);
 
  opt = sizeof(saddr);
  if( getpeername(host->rmt_fd,(struct sockaddr *),) ){
@@ -260,7 +261,7 @@
  is_rmt_fd_connected=1;
}
  
- host->sopt.rport = htons(port);
+ host->sopt.rport = port;
 
  /* Close TCP socket and replace with UDP socket */
  close(host->rmt_fd); 

Bug#901279: grub-common: update-grub overwrites /boot/grub/grub.cfg

[Greg Alexander]

Package: grub-common
Version: 2.02+dfsg1-4
Severity: important

Dear Maintainer,

I upgraded from an old version of grub using Debian's
"apt-get install grub-pc", and it overwrote my /boot/grub/grub.cfg
without prompting me, and without making a backup copy.  My old grub.cfg
was hand-crafted, simple, concise.  The new one is not. I don't know if I
would be better off with the older grub.cfg, but I do know I would like
to have it for reference!

Inspecting after the fact, I believe the specific steps were:
grub-pc.postinst script ran update-grub, which then ran grub-mkconfig -o
/boot/grub/grub.cfg.

At a minimum, update-grub must make a backup copy of the original
grub.cfg.

Thanks!

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/root / ext3 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
/dev/md0 /big ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
/dev/sda4 /scratch ext3 rw,relatime,errors=continue,barrier=1,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-WDC_WD30EZRZ-00WN9B0_WD-WCC4E6DCS427
(hd1)   /dev/disk/by-id/ata-ST2000DL004_HD204UI_S2H7J9GC303676
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_msdos
insmod part_gpt
insmod diskfilter
insmod mdraid1x
insmod ext2
set root='mduuid/8ecd869162cee1e9f73c365688306c0e'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='mduuid/8ecd869162cee1e9f73c365688306c0e'  
7a3cb040-495b-4c5e-896d-f59fba6a3243
else
  search --no-floppy --fs-uuid --set=root 7a3cb040-495b-4c5e-896d-f59fba6a3243
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
fi
terminal_output gfxterm
if [ "${recordfail}" = 1 ] ; then
  set timeout=30
else
  if [ x$feature_timeout_style = xy ] ; then
set timeout_style=menu
set timeout=5
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
set timeout=5
  fi
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###

### BEGIN /etc/grub.d/10_linux ###
function gfxmode {
set gfxpayload="${1}"
}
set linux_gfx_mode=
export linux_gfx_mode
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-8013aa3b-fcf2-46b1-ac0c-ecf2be63d5a3' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 
--hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 --hint='hd0,gpt2'  
8013aa3b-fcf2-46b1-ac0c-ecf2be63d5a3
else
  search --no-floppy --fs-uuid --set=root 
8013aa3b-fcf2-46b1-ac0c-ecf2be63d5a3
fi
echo'Loading Linux 4.1.46-20171117 ...'
linux   /boot/vmlinuz-4.1.46-20171117 root=/dev/sda2 ro  
}
submenu 'Advanced options for Debian GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-8013aa3b-fcf2-46b1-ac0c-ecf2be63d5a3' {
menuentry 'Debian GNU/Linux, with Linux 4.1.46-20171117' --class debian 
--class gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-4.1.46-20171117-advanced-8013aa3b-fcf2-46b1-ac0c-ecf2be63d5a3' {
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; 
fi
insmod part_gpt
insmod ext2
set root='hd0,gpt2'

Bug#898073: Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Greg Hudson]

On Mon, 7 May 2018 18:28:01 -0500 Benjamin Kaduk  wrote:
> At high risk of opening up the RNG debate that I did not want to
> revisit, the current stance of upstream krb5 seems to fall into what
> I'll call the "Schneier worldview", that a fully-seeded
> well-designed CSPRNG can produce arbitrary amounts of random output
> with no need to track "entropy depletion" or similar (emphasis on
> fully-seeded).

This is a good summary of my position (speaking as the current best
representative of "upstream krb5").  In particular, prior to
getrandom(), I had been frustrated with these Linux /dev/[u]random
properties:

1. /dev/random's concept of "strong" entropy attempts to mitigate
against a preimage attack against SHA-1, and therefore depletes the
estimate of strong randomness available as random data is read.  If you
aren't trying to mitigate against an attack on the CSPRNG, you don't
need any concept of "running out of" randomness, only a one-time switch
from "not ready" to "ready".  (You might try to further reduce the risk
of predictability after you've switched to "ready" state, of course.
Schneier's Fortuna algorithm does this, under the assumption that
entropy estimates will always be fallible.)

2. Reading from /dev/urandom can fully deplete the strong random
estimate; no portion of the estimated incoming hardware entropy is
reserved for /dev/random.  Most running systems read from /dev/urandom
often enough that the randomness estimate constantly returns to zero, so
reading from /dev/random almost always blocks for a noticeable period.

I had always viewed the "strong" parameter to krb5_c_os_random_entropy()
as a workaround for these kernel properties (and perhaps similar
properties on other kernels, although I'm not aware of any specific
examples).  We always want "strong" randomness.  Running a KDC and
issuing tickets with predictable session keys is terrible, even if it is
less terrible than generating long-term keys predictable to an attacker.
 But reading from /dev/random with any frequency is too painful, and
reading from /dev/urandom almost always yields unpredictable output.

For those reasons I was happy to accept a change to use getrandom() with
no flags on Linux, ignoring the "strong" parameter any bypassing the
userspace Fortuna code.  I can see that this change creates new KDC
availability issues on VMs, but I don't see that as a krb5-specific issue.

Bug#893996: Typo in /etc/init.d/mini-httpd causes start/stop/etc issues

[Greg Kennedy]

Package: mini-httpd
Version: 1.23-1.2

I am having issues with 'service mini-httpd stop'. The sysv-style
script in /etc/init.d loses track of the httpd pidfile, and so fails
to stop a running process. This also prevents 'service mini-httpd
restart' from working.

I have looked over the file /etc/init.d/mini-httpd and found that the
error seems to be several mismatches between spelling of "mini-httpd"
and "mini_httpd". For example, PIDFILE is specified as

PIDFILE=/var/run/mini_httpd.pid

or

NAME=mini_httpd
...
if [ -e /var/run/$NAME.pid ]

But, /etc/mini-httpd.conf has:

# Which pidfile to use?
pidfile=/var/run/mini-httpd.pid

I can correct this issue by fixing /etc/mini-httpd.conf to create
pidfile with an underscore - but the deeper problem is simply
inconsistency throughout the package as to what to name the file /
program / service / etc. This needs to be standardized everywhere.

Other info follows.

Linux raspberrypi 4.9.80+ #1098 Fri Mar 9 18:51:28 GMT 2018 armv6l GNU/Linux
libc6 Version 2.24-11+deb9u3

Bug#889831: USB rndis_host - slow download transfers, RX errors

[Greg KH]

On Thu, Feb 08, 2018 at 10:53:20AM -0500, Tomasz Janowski wrote:
> On Thursday, February 8, 2018 3:43:05 PM EST Greg KH wrote:
> > On Thu, Feb 08, 2018 at 02:16:08PM +, Tomasz Janowski, Ph.D. wrote:
> > > Dear USB developers,
> > > 
> > > Based on my google research, the problem I experience seems to happen
> > > with some newer smartphones. My test case is Samsung Galaxy S8 (SM-950U1).
> > > I am trying to use USB tethering and everything seems to work as expected
> > > (modules are loaded, Ethernet devices are up and running, dhcp works
> > > fine). I can connect to the external world using both LTE or wireless
> > > network on the phone.
> > > 
> > > Now, the problem is that the download speeds are terrible, around 64 KB/s,
> > > while uploads are fast, the order of 15 MB/s. These speeds do not depend
> > > on the wireless service provider: the results are similar when I tether
> > > wi-fi. The USB Ethernet interface on the Linux host reports a lot of
> > > receive errors (attached: device_state.txt), while kernel reports bad
> > > rndis messages (attached: kernel.log.txt).
> > > 
> > > Windows 10 works great with the same hardware (same PC and same phone),
> > > with uploads and downloads in the order of 150 Mbit/s, which is probably
> > > as fast as my wireless network can do. But some people reported issues
> > > with older Windows drivers too. Is possible that some newer version of
> > > RNDIS protocol is around and Linux hasn't updated its RNDIS module yet?
> > 
> > Hey, I was _just_ talking to someone at Google about this same issue
> > yesterday, you beat him sending this same type of report to the mailing
> > list, nice job :)
> > 
> > Yes, this is not good, and we should work to resolve this, but first,
> > what kernel version are you using?  I think some fixes for the rndis
> > driver went in recently to 4.15, but it would be good to verify that
> > this isn't already resolved.
> 
> The error messages which I have attached were produced by a precompiled 
> Debian 
> kernel: "Linux version 4.14.0-0.bpo.3-amd64 (debian-ker...@lists.debian.org) 
> (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP Debian 4.14.13-1~bpo9+1 
> (2018-01-14)".
> 
> But I have downloaded the most recent version of the kernel from the official 
> git repository (last commit: Jan 31, 2018) and it had exactly the same 
> problem. Unless a patch was submitted within the last week, the issue is 
> still 
> there.
> 
> Should I get the version as of today and test it again?

If you find a 4.15 tree, that would be great to test, but odds are, the
issues are still there.

I'll try to carve out some time to look at this tomorrow, as I have a
bunch of Android devices to test with, and there's no good reason why
Windows should be slower than Linux for stuff like this.  We should be
able to go as fast as the device lets us.  Most likely we are doing
something "stupid" in the rndis driver somewhere :)

thanks,

greg k-h

Bug#889831: USB rndis_host - slow download transfers, RX errors

[Greg KH]

On Thu, Feb 08, 2018 at 02:16:08PM +, Tomasz Janowski, Ph.D. wrote:
> Dear USB developers,
> 
> Based on my google research, the problem I experience seems to happen
> with some newer smartphones. My test case is Samsung Galaxy S8 (SM-950U1). I 
> am
> trying to use USB tethering and everything seems to work as expected (modules
> are loaded, Ethernet devices are up and running, dhcp works fine). I can 
> connect to
> the external world using both LTE or wireless network on the phone.
> 
> Now, the problem is that the download speeds are terrible, around 64 KB/s,
> while uploads are fast, the order of 15 MB/s. These speeds do not depend
> on the wireless service provider: the results are similar when I tether wi-fi.
> The USB Ethernet interface on the Linux host reports a lot of receive errors 
> (attached:
> device_state.txt), while kernel reports bad rndis messages (attached: 
> kernel.log.txt).
> 
> Windows 10 works great with the same hardware (same PC and same phone), with
> uploads and downloads in the order of 150 Mbit/s, which is probably as fast 
> as my
> wireless network can do. But some people reported issues with older Windows 
> drivers too.
> Is possible that some newer version of RNDIS protocol is around and Linux 
> hasn't updated
> its RNDIS module yet?

Hey, I was _just_ talking to someone at Google about this same issue
yesterday, you beat him sending this same type of report to the mailing
list, nice job :)

Yes, this is not good, and we should work to resolve this, but first,
what kernel version are you using?  I think some fixes for the rndis
driver went in recently to 4.15, but it would be good to verify that
this isn't already resolved.

thanks,

greg k-h

Bug#889673: Successfull: Jessie on Olimex A20-Olinuxino Micro Rev. J

[greg]

Package: installation-reports
Severity: normal



-- Package-specific info:

Boot method: USB Stick
Image version: 
http://ftp.debian.org/debian/dists/stable/main/installer-armhf/current/images/hd-media/hd-media.tar.gz
 
https://cdimage.debian.org/debian-cd/current/armhf/iso-cd/debian-9.3.0-armhf-xfce-CD-1.iso
Date: 2018-01-20

Machine: Olimex A20-Olinuxino Micro Rev. J
Partitions: 2018-01-24

$ df -Tl
Dateisystem   Typ  1K-Blöcke Benutzt Verfügbar Verw% 
Eingehängt auf
udev  devtmpfs492424  492424 0  100% /dev
tmpfs tmpfs   102156   10516 91640   11% /run
/dev/mapper/schubert--vg-root ext4 170783032 3001084 1590369882% /
tmpfs tmpfs   510768   05107680% 
/dev/shm
tmpfs tmpfs 5120   0  51200% 
/run/lock
tmpfs tmpfs   510768   05107680% 
/sys/fs/cgroup
/dev/sda1 ext2240972  147771 80760   65% /boot
tmpfs tmpfs   102152   01021520% 
/run/user/1000


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [E]
Detect CD:  [ ]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[O]

Comments/Problems:

Network did not work because of a kernel issue with hardware Revision J.
see https://www.olimex.com/forum/index.php?topic=5839.msg24167#msg24167


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="9 (stretch) - installer build 20170615+deb9u2+b1"
X_INSTALLATION_MEDIUM=hd-media

==
Installer hardware-summary:
==
uname -a: Linux schubert 4.9.0-4-armmp #1 SMP Debian 4.9.65-3 (2017-12-03) 
armv7l GNU/Linux
usb-list: 
usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.9.0-4-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 02 Device 01: MUSB HDRC host driver [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 01
usb-list:Manufacturer: Linux 4.9.0-4-armmp musb-hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.9.0-4-armmp ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 03 Device 02: USB Receiver [046d:c512]
usb-list:Level 01 Parent 01 Port 00  Class 00(>ifc ) Subclass 00 Protocol 00
usb-list:Manufacturer: Logitech
usb-list:Interface 00: Class 03(HID  ) Subclass 01 Protocol 01 Driver usbhid
usb-list:Interface 01: Class 03(HID  ) Subclass 01 Protocol 02 Driver usbhid
usb-list: 
usb-list: Bus 04 Device 01: EHCI Host Controller [1d6b:0002]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.9.0-4-armmp ehci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
usb-list: 
usb-list: Bus 05 Device 01: Generic Platform OHCI controller [1d6b:0001]
usb-list:Level 00 Parent 00 Port 00  Class 09(hub  ) Subclass 00 Protocol 00
usb-list:Manufacturer: Linux 4.9.0-4-armmp ohci_hcd
usb-list:Interface 00: Class 09(hub  ) Subclass 00 Protocol 00 Driver hub
lsmod: Module  Size  Used by
lsmod: xts 3443  2
lsmod: gf128mul8527  1 xts
lsmod: dm_crypt   18980  1
lsmod: dm_mod103409  9 dm_crypt
lsmod: md_mod121064  0
lsmod: jfs   174500  0
lsmod: btrfs1146390  0
lsmod: xor 4718  1 btrfs
lsmod: zlib_deflate   20290  1 btrfs
lsmod: raid6_pq   87373  1 btrfs
lsmod: fuse   89119  0
lsmod: smsc3309  1
lsmod: dwmac_sunxi 2431  0
lsmod: stmmac_platform 5044  1 dwmac_sunxi
lsmod: 

Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

[Greg Wooledge]

On Sun, Jan 14, 2018 at 01:35:30AM +0100, Santiago Vila wrote:
> On Tue, 26 Dec 2017, Greg Wooledge wrote:
> 
> > -if [ -r $i ]; then
> > -  . $i
> > +if [ -r "$i" ]; then
> > +  . "$i"
> 
> Thanks for the report.
> 
> Before I just apply the patch: Is there a standard somewhere
> specifying what kind of filenames are allowed in /etc/profile.d?

Not that I'm aware of.  The glob pattern in /etc/profile appears
to be the only restriction.

Bug#885414: base-files: lack of quoting in shell variable expansions in /etc/profile

[Greg Wooledge]

Package: base-files
Version: 9.9+deb9u3
Severity: normal
Tags: patch

--- /usr/share/base-files/profile   2016-03-04 06:00:00.0 -0500
+++ /tmp/profile2017-12-26 15:49:08.839804524 -0500
@@ -26,8 +26,8 @@
 
 if [ -d /etc/profile.d ]; then
   for i in /etc/profile.d/*.sh; do
-if [ -r $i ]; then
-  . $i
+if [ -r "$i" ]; then
+  . "$i"
 fi
   done
   unset i


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

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

Versions of packages base-files depends on:
ii  gawk [awk]  1:4.1.4+dfsg-1
ii  mawk [awk]  1.3.3-17+b3

base-files recommends no packages.

base-files suggests no packages.

-- debconf-show failed

Bug#881830: linux: cherry-pick "security/keys: add CONFIG_KEYS_COMPAT to Kconfig" to stretch kernel

[Greg Kroah-Hartman]

On Thu, Nov 16, 2017 at 08:28:28PM +, James Cowgill wrote:
> Hi,
> 
> On 16/11/17 19:04, Ben Hutchings wrote:
> > On Wed, 2017-11-15 at 16:50 +, James Cowgill wrote:
> >> Since I was a little puzzled as to why keyutils built previously on
> >> mips, I found this commit to 4.8 which caused the need for KEYS_COMPAT:
> >>
> >> commit 20f06ed9f61a185c6dabd662c310bed6189470df
> >> Author: David Howells <dhowe...@redhat.com>
> >> Date:   Wed Jul 27 11:43:37 2016 +0100
> >>
> >> KEYS: 64-bit MIPS needs to use compat_sys_keyctl for 32-bit userspace
> >> 
> >> MIPS64 needs to use compat_sys_keyctl for 32-bit userspace rather than
> >> calling sys_keyctl.  The latter will work in a lot of cases, thereby 
> >> hiding
> >>     the issue.
> >>
> >> Now I'm thinking maybe this can be argued as a bugfix for the above
> >> commit and put in upstream 4.9?
> > 
> > Greg, please queue up these two for 4.9:
> > 
> > 5c2a625937ba arm64: support keyctl() system call in 32-bit mode
> > 47b2c3fff493 security/keys: add CONFIG_KEYS_COMPAT to Kconfig
> 
> Sorry, I asked for this in two places. I think it's already queued up
> for 4.9 now.

Well, close, but not quite.  The second patch there reverts the first
patch, and adds the "generic" work.  As I already handled that in the
merge of the second patch, the first one is not needed, and the end
result should be the same.

So all is good.  Or at least I think so, someone verifying I got this
all right would be appreciated :)

thanks,

greg k-h

Bug#881562: [Debichem-devel] Bug#881562: rdkit: Please migrate away from Epydoc if possible

[Greg Landrum]

[hopefully I got the "reply to" right here]

Thanks for the pointer to a possible alternative to epydoc. Making this
change is likely a non-trivial amount of work, but we'll have to do
something anyway before we deprecate Python2 support in the RDKit.

I've created an issue in the RDKit tracker. No promises on when it'll get
done though.
https://github.com/rdkit/rdkit/issues/1656


-greg


On Mon, Nov 13, 2017 at 1:31 AM, Kenneth Pronovici <prono...@debian.org>
wrote:

> Source: rdkit
> Severity: wishlist
>
> Hi,
>
> If possible, please consider moving away from the use of Epydoc in your
> package.  Epydoc is basically unmaintained upstream.  Also, it is only
> supported for Python 2, so it will reach its end of life along with
> Python 2 sometime in 2020.
>
> I will continue to maintain the Epydoc packages in Debian as long as I
> can, acting as de facto upstream.  However, once Python 2 is unsupported
> in Debian, I'm not sure that we'll have too many options to keep it
> alive.  Migrating it to Python 3 is a fairly large job that I don't
> have the time or the expertise to take on right now.
>
> For my own Python code, I have recently converted to Sphinx using the
> Napolean plugin.  At [1], I can offer you (or your upstream) a hack-ish
> script to convert common Epydoc markup to Google-style docstrings. It's
> not perfect, but it would get you much of the way toward working code.
>
> Thanks,
>
> Ken (maintainer for python-epydoc)
>
> [1] https://bitbucket.org/cedarsolutions/cedar-backup3/
> src/73037a2/util/sphinx-convert
>
> ___
> Debichem-devel mailing list
> debichem-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel
>

Bug#864718: fsdev emulation security_model=none not handling mode 000

[Greg Kurz]

On Tue, 8 Aug 2017 10:58:29 +0300 Michael Tokarev  wrote:
> I'm forwarding this upstream.
> It looks like the same issue is present in 2.10-tobe.
> 

Now fixed upstream. Will be in 2.10.

https://git.qemu.org/http://git.qemu.org/qemu.git/?p=qemu.git;h=4751fd5328dfcd4fe2f9055728a72a0e3ae56512


pgpJ_FvEZUZVD.pgp
Description: OpenPGP digital signature

Bug#870488: libc6-dev: sched_setattr missing from sched.h and linux/sched.h

[Greg Rogers]

Package: libc6-dev
Version: 2.24-11+deb9u1
Severity: important

Dear Maintainer,

Please update sched.h and linux/sched.h to provide access to
sched_setattr, sched_getattr and SCHED_DEADLINE which have been part of
the kernel since 3.14.

Have installed the RT PREEMPT kernel and the headers are still missing
the definitions.

The man pages have been updated with these functions and defines but not
the headers.


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

Kernel: Linux 4.9.0-3-rt-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6-dev depends on:
ii  libc-dev-bin2.24-11+deb9u1
ii  libc6   2.24-11+deb9u1
ii  linux-libc-dev  4.9.30-2+deb9u2

libc6-dev recommends no packages.

Versions of packages libc6-dev suggests:
pn  glibc-doc 
ii  manpages-dev  4.10-2

-- no debconf information

Bug#839155: Patch for #839155

[Greg Dahlman]

Hi, I think this is a regression from 4.3.

Unfortunately pip uses ~/.local/bin for `pip install --user` calls and when 
this is missing people tend to use sudo for packages for all users.

While the previous change unconditionally added the path I did follow the new 
4.4 behavior and tested for the directory before pre-pending the directory to 
the path.

Thanks,

Gregdiff -Nru bash-4.4/debian/changelog bash-4.4/debian/changelog
--- bash-4.4/debian/changelog	2017-05-15 12:45:32.0 -0700
+++ bash-4.4/debian/changelog	2017-07-26 18:02:45.0 -0700
@@ -1,3 +1,11 @@
+bash (4.4-6) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload
+  * Add $HOME/.local/bin to skel.profile
+- Closes: #839155, LP: #1705571
+
+ -- gdahlman   Wed, 26 Jul 2017 18:02:45 -0700
+
 bash (4.4-5) unstable; urgency=medium
 
   * Apply upstream patch 012.
diff -Nru bash-4.4/debian/skel.profile bash-4.4/debian/skel.profile
--- bash-4.4/debian/skel.profile	2013-10-23 05:41:22.0 -0700
+++ bash-4.4/debian/skel.profile	2017-07-26 18:02:45.0 -0700
@@ -20,3 +20,8 @@
 if [ -d "$HOME/bin" ] ; then
 PATH="$HOME/bin:$PATH"
 fi
+
+# set PATH so it includes user's pip private bin if it exists
+if [ -d "$HOME/.local/bin" ] ; then
+PATH="$HOME/.local/bin:$PATH"
+fi

Bug#868892: tasksel: Unexpected mass package removal with no way to cancel

[Greg Wooledge]

On Wed, Jul 19, 2017 at 01:45:42PM -0300, Henrique de Moraes Holschuh wrote:
> But with the patch, at least there is now an "exit" button when it is
> run in standalone mode...

Yes, that appears to work for me in standalone mode.  I'm not in a
good position to test it within d-i.

Bug#868892: tasksel: Unexpected mass package removal with no way to cancel

[Greg Wooledge]

Package: tasksel
Version: 3.39
Severity: normal

I was trying to help someone in #debian who wanted to install the
Standard set of packages after his netinst had failed to do so due to
a lack of network connection at the time.  I thought that perhaps he
could use tasksel to achieve this, so I tried it on my own computer
first.

I ran "sudo tasksel", and was given the dialog, without any "Standard"
task to choose.  So be it.  I reported that to the user.

But then there was no obvious way for me to escape from tasksel.  There
is no Cancel button -- just an OK button.  Ctrl-C did not work.

So I did what seemed obvious at the time -- I unselected all the tasks
(only one had been selected; I think it was ssh server), and then
selected OK.

Instead of just letting me out, it started deleting packages.  It happened
extremely quickly (on this computer), with no prompt, no warning of
any kind.  Ctrl-C still did not work.  When tasksel finally exited on
its own, there was a long string of ^C^C^C^C^C^C^C... on the terminal.

The only way to figure out what happened, then, is to check the logs.

$ grep remove /var/log/dpkg.log
2017-07-07 11:52:38 startup packages remove
2017-07-07 11:52:48 startup packages remove
2017-07-07 11:52:48 remove exim4:all 4.89-2+deb9u1 
2017-07-19 10:05:49 startup packages remove
2017-07-19 10:05:50 remove python-docutils:all 0.13.1+dfsg-2 
2017-07-19 10:05:50 remove docutils-common:all 0.13.1+dfsg-2 
2017-07-19 10:05:50 remove docutils-doc:all 0.13.1+dfsg-2 
2017-07-19 10:05:50 remove libsoftware-license-perl:all 0.103012-1 
2017-07-19 10:05:50 remove libdata-section-perl:all 0.26-1 
2017-07-19 10:05:50 remove libmro-compat-perl:all 0.12-1 
2017-07-19 10:05:50 remove libclass-c3-perl:all 0.32-1 
2017-07-19 10:05:50 remove libalgorithm-c3-perl:all 0.10-1 
2017-07-19 10:05:50 remove libarchive-extract-perl:all 0.80-1 
2017-07-19 10:05:50 remove libasprintf0c2:amd64 0.19.3-2 
2017-07-19 10:05:50 remove libpod-readme-perl:all 1.1.2-1 
2017-07-19 10:05:50 remove libnamespace-autoclean-perl:all 0.28-1 
2017-07-19 10:05:51 remove libnamespace-clean-perl:all 0.27-1 
2017-07-19 10:05:51 remove libb-hooks-endofscope-perl:all 0.21-1 
2017-07-19 10:05:51 remove libclass-c3-xs-perl:amd64 0.14-1+b1 
2017-07-19 10:05:51 remove libmoox-handlesvia-perl:all 0.001008-2 
2017-07-19 10:05:51 remove libmoo-perl:all 2.002005-1 
2017-07-19 10:05:51 remove libdata-perl-perl:all 0.002009-1 
2017-07-19 10:05:51 remove librole-tiny-perl:all 2.05-1 
2017-07-19 10:05:51 remove libclass-method-modifiers-perl:all 2.12-1 
2017-07-19 10:05:51 remove libclass-xsaccessor-perl:amd64 1.19-2+b7 
2017-07-19 10:05:51 remove libcpan-changes-perl:all 0.42-1 
2017-07-19 10:05:51 remove libmodule-build-perl:all 0.422000-1 
2017-07-19 10:05:51 remove libcpan-meta-perl:all 2.150010-1 
2017-07-19 10:05:51 remove libgetopt-long-descriptive-perl:all 0.100-1 
2017-07-19 10:05:51 remove libsub-exporter-perl:all 0.986-1 
2017-07-19 10:05:51 remove libdata-optlist-perl:all 0.110-1 
2017-07-19 10:05:51 remove libdevel-lexalias-perl:amd64 0.05-1+b4 
2017-07-19 10:05:52 remove libdevel-caller-perl:amd64 2.06-1+b4 
2017-07-19 10:05:52 remove libdevel-globaldestruction-perl:all 0.14-1 
2017-07-19 10:05:52 remove libtype-tiny-perl:all 1.05-1 
2017-07-19 10:05:52 remove liblist-moreutils-perl:amd64 0.416-1+b1 
2017-07-19 10:05:52 remove libexporter-tiny-perl:all 0.042-1 
2017-07-19 10:05:52 remove libfile-slurp-perl:all .19-6 
2017-07-19 10:05:52 remove libimport-into-perl:all 1.002005-1 
2017-07-19 10:05:52 remove libintl-xs-perl:amd64 1.26-2+b1 
2017-07-19 10:05:52 remove libintl-perl:all 1.26-2 
2017-07-19 10:05:52 remove libio-stringy-perl:all 2.111-2 
2017-07-19 10:05:52 remove libisccc90:amd64 1:9.9.5.dfsg-9+deb8u10 
2017-07-19 10:05:52 remove libisc95:amd64 1:9.9.5.dfsg-9+deb8u10 
2017-07-19 10:05:52 remove libjasper1:amd64 1.900.1-debian1-2.4+deb8u3 
2017-07-19 10:05:52 remove libterm-ui-perl:all 0.46-1 
2017-07-19 10:05:52 remove liblog-message-simple-perl:all 0.10-2 
2017-07-19 10:05:52 remove liblog-message-perl:all 0.8-1 
2017-07-19 10:05:53 remove liblwres90:amd64 1:9.9.5.dfsg-9+deb8u10 
2017-07-19 10:05:53 remove libparams-validate-perl:amd64 1.26-1 
2017-07-19 10:05:53 remove libpackage-stash-perl:all 0.37-1 
2017-07-19 10:05:53 remove libmodule-implementation-perl:all 0.09-1 
2017-07-19 10:05:53 remove libmodule-load-conditional-perl:all 0.68-1 
2017-07-19 10:05:53 remove libmodule-pluggable-perl:all 5.2-1 
2017-07-19 10:05:53 remove libmodule-runtime-perl:all 0.014-2 
2017-07-19 10:05:53 remove libmodule-signature-perl:all 0.81-1 
2017-07-19 10:05:53 remove libpackage-constants-perl:all 0.06-1 
2017-07-19 10:05:53 remove libpackage-stash-xs-perl:amd64 0.28-3+b1 
2017-07-19 10:05:53 remove libpadwalker-perl:amd64 2.2-2+b1 
2017-07-19 10:05:53 remove libpango1.0-0:amd64 1.40.5-1 
2017-07-19 10:05:53 remove libpangox-1.0-0:amd64 0.0.2-5+b2 
2017-07-19 10:05:53 remove libpangoxft-1.0-0:amd64 1.40.5-1 
2017-07-19