date:20210825


On 8/25/2021 4:16 PM, Phillip Susi wrote:

Chuck Zmudzinski  writes:

If it doesn't work, I am also willing to try approach a by patching
the Linux kernel xen-kbdfront driver by removing the for loops that
advertise those 654 keys. I tend to agree with Philip that this is
totally unnecessary, but I suppose I could be wrong about that.
I read the discussion Philip had with the Xen developers and they
seemed to want to keep the Xen keyboard driver as it is.

That was the first thing I tried and the libinput maintainer pointed out
that if you don't advertise the keys, you can't use the keys.  In other
words, somebody presses that key on their keyboard and the domU won't
recognize it.



Well, good news - It looks like Ben's patch works, I just tested it in 
my full

install in a Xen HVM domU and all looks good. I did not see the Coldplug
failure at the beginning of the boot - it is hard to miss in the bright red
letters on the console, and even more convincing is the fact that another
symptom of the bug is gone. This bug manifests itself in udev not being
able to write uevent data to sysfs for the Xen Virtual Keyboard. With
Ben's patch of increasing the UEVENT_BUFFER_SIZE from 2048 to 4096,
udev can write its uevent data to sysfs for the Xen Virtual Keyboard:

With the current 5.10.0-8 kernel:

chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent
chuckz@debian:~$

With the patched kernel with a change to the ABI version from 8 to 8.1:

chuckz@debian:~$ uname -r
5.10.0-8.1-amd64
chuckz@debian:~$ cat /sys/devices/virtual/input/input2/uevent
PRODUCT=1/5853//0
NAME="Xen Virtual Keyboard"
PHYS="xenbus/device/vkbd/0"
PROP=0
EV=3
KEY=7fff  ...
MODALIAS=input:b0001v5853pe-e0,1,k71,72... really long MODALIAS

I expect with that patch the installation media will work
in a Xen HVM domU.

Cheers,

Chuck

Bug#992995: mail-expire: Add support to skip new or unread marked mails

2021-08-25 Thread Salvatore Bonaccorso

Package: mail-expire
Version: 0.9.1
Severity: wishlist
X-Debbugs-Cc: car...@debian.org

Hi

While searching for alternatives in the Debian archive to the now
removed 'archivemail' I wonder the following for mail-expire:

It would be nice if mail-expire could skip mails which are net new or
were marked unread explicitly via an additional flag, which does not
need to be the default.

Regards,
Salvatore

Bug#992994: nmu: kio-gdrive_21.08.0-1

2021-08-25 Thread Norbert Preining

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-Cc: debian-qt-...@lists.debian.org

kio-gdrive depends on libkpimgapicore5-20.08 and other KDE Gears 20.08
libraries. Since 21.08 version of KDE Gears has been uploaded, we need
rebuild of kio-gdrive to make KDE PIM and kio-gdrive co-installable.

nmu kio-gdrive_21.08.0-1 . ANY . unstable . -m "Rebuild for KDE Gears 21.08 
co-installability."

Bug#637094: Bug#637052: python-amara: SAXParseException syntax error when importing

2021-08-25 Thread Tommi Höynälänmaa


On Mon, 8 Aug 2011 15:44:27 +0200 Jakub Wilk  wrote:

...

>
> Also, it'd nice if update-xmlcatalog (or dh_installcatalogs?) could do
> some sanity checks.
>


Should we call xmllint in update-xmlcatalog?

 - Tommi Höynälänmaa




OpenPGP_0xBB861FDE40460F83.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#990246: vlc: reproducible builds: Embeds build username and hostname in binaries

2021-08-25 Thread Vagrant Cascadian

Control: forwarded 990246 https://savannah.gnu.org/support/index.php?110532

On 2021-08-25, Vagrant Cascadian wrote:
> On 2021-08-25, Sebastian Ramacher wrote:
>> On 2021-06-23 13:16:47, Vagrant Cascadian wrote:
>>> The build username and build system hostname are embedded in binaries
>>> shipped in vlc:
>>> 
>>>   
>>> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/vlc.html
...
> Thanks for considering. Perhaps it will be best to take this upstream at
> this point, anyways...

https://savannah.gnu.org/support/index.php?110532

Will see what upstream has to say...

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#988975: bash-completion: Wrong completion after some certain words such as TZ, TERM and LANG

2021-08-25 Thread Gabriel F. T. Gomes

Control: tags -1 + confirmed upstream

The change in behavior is caused by the following upstream commit:

  
https://github.com/scop/bash-completion/commit/d1756f06ef9bffb1b4621c4e63e47e181ddf1086

which got released in upstream version 2.10.

Bug reported submitted upstream as 
https://github.com/scop/bash-completion/issues/590


Cheers,
Gabriel

On Sat, 22 May 2021 17:59:29 +0800
WHR  wrote:

> Package: bash-completion
> Version: 1:2.11-2
> Severity: important
> X-Debbugs-Cc: msl023...@gmail.com
> 
> This version has a bug that didn't exist in previous Debian release (Buster).
> The completion becomes wrong after certain words; for exmaple I want to
> search for word 'TERM' in a file, so I typed (^ indicates cursor position):
> 
> grep -F TERM 
>  ^
> 
> however the completion here doesn't give the expected result, of listing
> files in the working directory, but instead:
> 
> $ grep -F TERM 
> Display all 1750 possibilities? (y or n)
> 9termhp2  screen.linux-m1
> Etermhp236screen.linux-m1b
> Eterm-256color   hp2382a  screen.linux-m2
> Eterm-88colorhp2392   screen.minitel1
> MtxOrb   hp2397a  screen.minitel1-nb
> ...
> 
> It appears that bash wrongly completed this as the TERM environmet variable,
> which is obviously incorrect here.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.147-rivoreo-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> -- no debconf information

Bug#961660: Cause is have() Wrapper Function of Function _have()

2021-08-25 Thread Gabriel F. T. Gomes

Thanks for the update.

I'll close the bug report now. Feel free to reopen it if anything else pops-up.

Bug#992993: libapt-pkg6.0: infinite recursion in pkgDepCache::MarkPackage

2021-08-25 Thread Aaron M. Ucko

Package: libapt-pkg6.0
Version: 2.3.8

As of apt 2.3.8, most uses of libapt-pkg segfault; I can't even use
reportbug to submit this report!  The culprit appears to be infinite
recursion in pkgDepCache::MarkPackage:

  #0  Configuration::FindB (this=0x5556bee0, 
  Name=Name@entry=0x77e29f47 "Debug::pkgAutoRemove", 
  Default=Default@entry=@0x7f7ff3a0: false)
  at ../apt-pkg/contrib/configuration.cc:453
  #1  0x77dc2ff3 in pkgDepCache::MarkPackage (this=0x55636c80, 
  Pkg=..., Ver=..., follow_recommends=@0x7fffdace: true, 
  follow_suggests=@0x7fffdacf: true, reason=0x77e32cfa "Dependency")
  at ../apt-pkg/depcache.cc:2303
  #2  0x77dc3b6a in pkgDepCache::MarkPackage (this=0x55636c80, 
  Pkg=..., Ver=..., follow_recommends=@0x7fffdace: true, 
  follow_suggests=@0x7fffdacf: true, reason=)
  at ../apt-pkg/depcache.cc:2406
  #3  0x77dc3b6a in pkgDepCache::MarkPackage (this=0x55636c80, 
  Pkg=..., Ver=..., follow_recommends=@0x7fffdace: true, 
  follow_suggests=@0x7fffdacf: true, reason=)
  at ../apt-pkg/depcache.cc:2406

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 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:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::LastInstalledKernel "5.10.0-8-amd64";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "0";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";
APT::Update "";
APT::Update::Post-Invoke "";
APT::Update::Post-Invoke:: "touch /var/lib/apt/periodic/update-success-stamp 
2>/dev/null || true";
APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || 
true";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 
0 ; apt-show-versions -i";
APT::Update::Post-Invoke-Success:: "[ ! -f /var/run/dbus/system_bus_socket ] || 
/usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt 
org.debian.apt.CacheChanged || true";
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/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; 
fi";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w 
/var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then 
/usr/lib/cnf-update-db > /dev/null; fi";
APT::Archives "";
APT::Archives::MaxAge "30";
APT::Archives::MinAge "2";
APT::Archives::MaxSize "500";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Architectures:: "x32";
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 "";

Bug#978695: notepadqq: Input windows hangs so input is not possible

2021-08-25 Thread Anthony Fok

Control: severity -1 important
Control: tags -1 moreinfo unreproducible

On Wed, 30 Dec 2020 12:42:15 +0100 Michael Rasmussen  wrote:
> Package: notepadqq
> Version: 2.0.0~beta1-1+b1
> Severity: grave
> Justification: renders package unusable
>
> Dear Maintainer,
>
> When notepadqq is started you expect to see an empty tab
> or tabs with reason files, but neither happens. Try to open a tab
> resolves in a frozen application and if started from command line
> the following is seen:
>
> js: Uncaught ReferenceError: $ is not defined
> js: Uncaught ReferenceError: $ is not defined
> Now close application and this is shown:
> js: Uncaught TypeError: Cannot read property 'isClean' of undefined
>
> From here only way to actually quit the application is ^C

Hi Michael,

Thank you for your bug report.
However, when testing on Debian unstable shortly after the Debian 11
(bullseye) release,
I am unable to reproduce any of the errors that you encountered in
December 2020.

Could you please try again and see if you could still see any of such errors?

Cheers,

Anthony

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel


On 8/24/2021 7:12 PM, Ben Hutchings wrote:


Text-based sysfs attributes are limited to a page, but udev receives
uevents through netlink, not sysfs.

The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).  That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390

But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.  Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
  
  #define UEVENT_HELPER_PATH_LEN		256

  #define UEVENT_NUM_ENVP   64  /* number of env 
pointers */
-#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */
+#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */
  
  #ifdef CONFIG_UEVENT_HELPER

  /* path to the userspace helper executed on an event */
--- END ---

?

Ben.



I tried this patch but the build failed - it ran for over an hour. I am not
sure why as I have not built a Linux kernel in many years. So I will
this:

1) Try to build the unmodified kernel on my system just to be sure I
am building the kernel correctly and that my hardware is OK. Once
I could not build the Linux kernel until I replaced a bad memory
card.

2) If that succeeds, I will try the patch with a bump to the abi version.

From the output of the failed build and what I read in the section on
the Debian kernel ABI name, I think that the system detected an
ABI change and so it failed. The build was checking symbols when
it failed.

This will take a little while because it takes over an hour to build the
kernel on my system.

Chuck

Bug#992992: ITP: python-spinners -- spinners library of terminal for python3

2021-08-25 Thread Nobuhiro Iwamatsu

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: python-spinners
  Version : 0.0~git20200220.a73d561
  Upstream Author : Manraj Singh 
* URL : https://github.com/manrajgrover/py-spinners
* License : Expat
  Programming Lang: Python
  Description : spinners library of terminal for python3

  More than 60 spinners libraries for terminal, this is python port of
  amazing node library cli-spinners 
(https://github.com/sindresorhus/cli-spinners).

Bug#992991: matlab-support: R2021a Could not initialize shared resources for X11GraphicsDevice

2021-08-25 Thread Andrew McGinnis

Package: matlab-support
Version: 0.0.22
Severity: important
X-Debbugs-Cc: andrew@mcginnis.space

Dear Maintainer,

When running MATLAB R2021a on Bullseye, MATLAB appears to not recognize my 
graphics card.  This makes it impossible to plot graphs, unless matlab is run 
with the -softwareopengl option.  I get the following error message in MATLAB 
at startup:

com.jogamp.opengl.GLException: X11GLXDrawableFactory - Could not initialize 
shared resources for X11GraphicsDevice[type .x11, connection :0, unitID 0, 
handle 0x0, owner false, ResourceToolkitLock[obj 0x363a0dad, isOwner false, 
<53ad249f, 55216f24>[count 0, qsz 0, owner ]]]
at 
jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:326)
at jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:297)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NullPointerException
at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:688)
at jogamp.opengl.GLContextImpl.makeCurrent(GLContextImpl.java:580)
at 
jogamp.opengl.x11.glx.X11GLXDrawableFactory$SharedResourceImplementation.createSharedResource(X11GLXDrawableFactory.java:297)
... 2 more

I have managed to get MATLAB to run with hardware graphics acceleration by 
adding:

export MESA_LOADER_DRIVER_OVERRIDE=i965

to my profile.  This is from the following post on the Mathworks Forum:

https://www.mathworks.com/matlabcentral/answers/342906-could-not-initialize-shared-resources-for-x11graphicsdevice#answer_425485

My machine has an Intel graphics card.

Please consider adding support for Intel graphics drivers to this package.

Thank you,

Andrew

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

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

Versions of packages matlab-support depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  sudo   1.9.5p2-3

Versions of packages matlab-support recommends:
ii  libgfortran-10-dev10.2.1-6
ii  libstdc++-10-dev [libstdc++-dev]  10.2.1-6

Versions of packages matlab-support suggests:
pn  lsb-core  

-- debconf information:
* matlab-support/matlab-install-glob: /opt/MATLAB/R2021a
* matlab-support/mexbuild-user: andrew
  matlab-support/title:
* matlab-support/default-version: Matlab R2021a @ /opt/MATLAB/R2021a
* matlab-support/rename-libs: true
  matlab-support/no-matlab-found:

Bug#990053: Same error on Debian 11

2021-08-25 Thread Scorpion2185

I have the same error on Debian 11:
[...]
yowsup-cli v2.0.15
yowsup v2.5.7
[...]
INFO:yowsup.common.http.warequest:b'{"login":"XXX","param":"authkey","reason":"missing_param","status":"fail"}\n'
status: b'fail'
reason: b'missing_param'
param: b'authkey'
login: b'XXX'

Bug#989705: Suspend to RAM hangs computer with nouveau driver and kernel 5.10.0-7-amd64 / 5.12.13 / 5.12.15 / 5.13

2021-08-25 Thread manu

Hi and thanks computer.enthusiastic for your report,

I'm using a NVIDIA Corporation GT216M [GeForce GT 240M] (rev a2) and can
confirm :

- kernel 5.10.0-8 (Debian 11) : FAIL

- kernel 4.19.0-17 (Debian 10 or Debian 11) : OK

Bug#992981: autoconf: AC_CHECK_LIB no longer works with g++

Control: forwarded -1 https://savannah.gnu.org/support/index.php?110532

On 2021-08-26 00:54:02 +0200, Vincent Lefevre wrote:
> Patch attached. I tested it and solves the failure with GNU MPFR.

I've reported the bug upstream and submitted the patch, as the issue
is reproducible from the git repository.

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

Bug#992990: systemd: Does not clean up user session

2021-08-25 Thread Samuel Thibault

Package: systemd
Version: 247.3-6
Severity: normal

Hello,

It seems that the user sessions are not getting cleaned up when it
crashes unexpectedly, and notably the dbus session bus, which can lead
to various oddities. To reproduce:

- logging in from lightdm ($USER is ff)
- the MATE desktop starts
- the attached snapshot shows the dbus-daemon running: not only the ones
  for the ff user, but also for lightdm (!?)
- as root in a mate-terminal, run systemctl restart lightdm
- the MATE session thus gets completely interrupted, lightdm shows up
  again
- logging in again as $USER ff
- the MATE desktop starts
- the attached snapshot shows that it's still the same dbus-daemon
  running: again not only the ones for the ff user, but also for lightdm

These surviging processes are worrying: when a user is not connected,
should there really be such remainings?  I understand that a user may be
running e.g. screen sessions, but more than this?

I could check that systemd 249.3-3 from experimental behaves the same

Samuel

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser3.118
ii  libacl12.2.53-10
ii  libapparmor1   2.13.6-10
ii  libaudit1  1:3.0.5-1
ii  libblkid1  2.36.1-8
ii  libc6  2.31-13
ii  libcap21:2.44-1
ii  libcrypt1  1:4.4.18-4
ii  libcryptsetup122:2.3.5-1
ii  libgcrypt201.8.7-6
ii  libgnutls303.7.1-5
ii  libgpg-error0  1.38-2
ii  libip4tc2  1.8.7-1
ii  libkmod2   28-1
ii  liblz4-1   1.9.3-2
ii  liblzma5   5.2.5-2
ii  libmount1  2.36.1-8
ii  libpam0g   1.4.0-9
ii  libseccomp22.5.1-1
ii  libselinux13.1-3
ii  libsystemd0247.9-1
ii  libzstd1   1.4.8+dfsg-2.1
ii  mount  2.36.1-8
ii  ntp [time-daemon]  1:4.2.8p15+dfsg-1
ii  util-linux 2.36.1-8

Versions of packages systemd recommends:
ii  dbus  1.13.18-1

Versions of packages systemd suggests:
ii  policykit-10.105-31
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.140
ii  libnss-systemd   247.9-1
ii  libpam-systemd   247.9-1
ii  udev 247.9-1

-- Configuration Files:
/etc/systemd/journald.conf changed [not included]
/etc/systemd/logind.conf changed [not included]

-- no debconf information

-- 
Samuel
#include

Bug#992989: avahi-daemon CPU usage increases over time

2021-08-25 Thread Ryan Armstrong

Package: avahi-daemon
Version: 0.8-5
Severity: normal

Dear Maintainer,

After upgrading to Debian Bullseye, I noticed that the Avahi CPU usage on my 
server machine was
quite high (eventually 100% of one core). After resetting Avahi, the CPU usage 
was normal then
eventually increased over time again until it was again rather high. The
increase appears to be (very roughly) 1 or 2% per hour on my rather humble 
Intel(R) Celeron(R) 
CPU 4205U @ 1.80GHz. 

Checking the journal, I only see the following sorts of lines:

Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:30 zeta avahi-daemon[31]: avahi_key_new() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_normalize_name() failed.
Aug 25 16:21:31 zeta avahi-daemon[31]: avahi_key_new() failed.

Which was around the time I turned on another machine on my network.
However, the timing was not aligned with when Avahi CPU usage increased.
There is a possibility it is aligned with when I turn on my printer, but
I will need to investigate that further. I did not see anything else in
the log of note.

In the meantime, is there any means for me to gather additional
information to help diagnose this problem?

Thanks,
Ryan

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

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

Versions of packages avahi-daemon depends on:
ii  adduser  3.118
ii  bind9-host [host]1:9.16.15-1
ii  dbus 1.12.20-2
ii  init-system-helpers  1.60
ii  libavahi-common3 0.8-5
ii  libavahi-core7   0.8-5
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libdaemon0   0.14-7.1
ii  libdbus-1-3  1.12.20-2
ii  libexpat12.2.10-2
ii  lsb-base 11.1.0

Versions of packages avahi-daemon recommends:
ii  libnss-mdns  0.14.1-2

Versions of packages avahi-daemon suggests:
pn  avahi-autoipd  

-- no debconf information

Bug#992972: unbound: Enable DNS-over-HTTPS (DoH)

2021-08-25 Thread John Shaft

Package: unbound
Version: 1.13.1-1
Severity: wishlist

Dear Maintainer,

Unbound 1.12.0 added support for DoH.

To enable it, Unbound has to be compiled with the parameter --with-libnghttp2 
(see https://github.com/NLnetLabs/unbound/pull/255) - thus making this lib a 
requirement

DoH being a proposed Internet standard, its lack is problematic

Regards,


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 11 (bullseye)
Release:11
Codename:   bullseye
Architecture: armv7l

Kernel: Linux 5.10.52-v7l+ (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unbound depends on:
ii  adduser 3.118
ii  dns-root-data   2021011101
ii  libc6   2.31-13+rpi1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libprotobuf-c1  1.3.3-1+b2
ii  libpython3.93.9.2-1+rpi1
ii  libssl1.1   1.1.1k-1
ii  libsystemd0 247.3-6+rpi1
ii  lsb-base11.1.0+rpi1
ii  openssl 1.1.1k-1
ii  unbound-anchor  1.13.1-1

unbound recommends no packages.

Versions of packages unbound suggests:
pn  apparmor  

-- no debconf information

Bug#992988: linux: please enable CONFIG_FSL_MC_UAPI_SUPPORT on arm64

2021-08-25 Thread russm

Source: linux
Severity: normal
X-Debbugs-Cc: russm-debian-b...@slofith.org

Dear Maintainer,

Please enable CONFIG_FSL_MC_UAPI_SUPPORT=y alongside CONFIG_FSL_MC_BUS=y
on arm64 to allow userspace management of DPAA2 networking objects.

Thanks


-- System Information:
Debian Release: 11.0
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (1, 'experimental')
Architecture: arm64 (aarch64)

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

Bug#992987: RFP: pooler -- Optimise DNA sequencing primer-set combinations

2021-08-25 Thread Silas S . Brown

Package: wnpp
Severity: wishlist

Would the Debian Med team be interested in Primer Pooler
for Debian's Next Generation Sequencing section?

Primer Pooler has been used and cited in cancer research,
plant science and climatology, and I am also aware of its
use at a national food standards agency and other places.

It should be an easy package to maintain, being a single
C binary and man page, and it's quite stable now (the last
few updates were changing the wording of some messages in
response to occasional user misunderstandings).  I could
probably maintain it myself if I had a little help with
the initial stage of making it Debian-compliant.  (I am
the upstream developer.)

License is Apache 2, and there is a FreeBSD package, see
https://cgit.freebsd.org/ports/tree/biology/pooler/

Upstream is http://ssb22.user.srcf.net/pooler/
or in Git: https://github.com/ssb22/PrimerPooler

Thanks.

Silas

Bug#991134: firefox: random connection failures

On 2021-07-15 12:56:24 +0200, Vincent Lefevre wrote:
> This has just happened when doing "Back": the HTML page
> https://www.vinc17.net/ was displayed, but without the CSS, which
> should have been in the cache (as being loaded a few minutes earlier).
> After doing a reload, I got a connection error (still immediate).
> A second reload worked.

This has occurred many times with pages under https://www.vinc17.net/
but also with a page under https://lists.gnu.org/ (which I had visited
2-3 minutes earlier). This issue might occur only for pages that are
already in the cache.

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

Bug#992986: nextcloud-desktop: vfs plugins outside library lookup path

2021-08-25 Thread Christian Tramnitz

Package: nextcloud-desktop
Version: 3.3.1-2
Severity: normal
X-Debbugs-Cc: christian+deb...@tramnitz.com

Dear Maintainer,


   * upgrading to 3.3.1 causes vfs issues
   * upgrading an existing installation with vfs support (experimental feature)
   * nextcloud-desktop does not start anymore with error message:
 [ critical plugins ]:  Could not load plugin: not existant or bad 
metadata "nextcloudsync_vfs_suffix"
 [ fatal default ]: Could not load plugin
   * plugins loaded from /usr/lib/x86_64-linux-gnu/nextcloudsync_vfs_*
   * an invocation of nextcloud-desktop with strace reveals that the 
/usr/lib/x86_64-linux-gnu directory is not checked for plugins



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

Kernel: Linux 5.10.47-1.fc32.qubes.x86_64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_DE.UTF-8), LANGUAGE=de_DE.UTF-8
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.31-13
ii  libcloudproviders0 0.3.0-3
ii  libgcc-s1  10.2.1-6
ii  libglib2.0-0   2.66.8-1
ii  libnextcloudsync0  3.3.1-2
ii  libqt5core5a   5.15.2+dfsg-9
ii  libqt5dbus55.15.2+dfsg-9
ii  libqt5gui5 5.15.2+dfsg-9
ii  libqt5keychain10.10.0-1
ii  libqt5network5 5.15.2+dfsg-9
ii  libqt5qml5 5.15.2+dfsg-6
ii  libqt5quick5   5.15.2+dfsg-6
ii  libqt5quickcontrols2-5 5.15.2+dfsg-2
ii  libqt5sql5-sqlite  5.15.2+dfsg-9
ii  libqt5svg5 5.15.2-3
ii  libqt5webenginecore5   5.15.2+dfsg-3
ii  libqt5webenginewidgets55.15.2+dfsg-3
ii  libqt5widgets5 5.15.2+dfsg-9
ii  libstdc++6 10.2.1-6
ii  nextcloud-desktop-common   3.3.1-2
ii  nextcloud-desktop-l10n 3.3.1-2
ii  qml-module-qtgraphicaleffects  5.15.2-2
ii  qml-module-qtqml-models2   5.15.2+dfsg-6
ii  qml-module-qtquick-controls2   5.15.2+dfsg-2
ii  qml-module-qtquick-layouts 5.15.2+dfsg-6
ii  qml-module-qtquick-window2 5.15.2+dfsg-6
ii  qml-module-qtquick25.15.2+dfsg-6

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  3.3.1-2

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#992981: autoconf: AC_CHECK_LIB no longer works with g++

Control: tags -1 patch

On 2021-08-26 00:09:07 +0200, Vincent Lefevre wrote:
> On 2021-08-25 23:56:45 +0200, Vincent Lefevre wrote:
> > I've found the cause. With Autoconf 2.69, there was
> > 
> > #ifdef __cplusplus
> > extern "C"
> > #endif
> > 
> > at the beginning of the test program generated by Autoconf.
> > This is no longer the case with Autoconf 2.71. A manual test
> > confirms that these 3 lines make the difference.
> 
> It seems that upstream commit 326c9a547423d25c621bc5c0ef76edbf6eda8c92
> is the cause. I'm going to test with the 3 lines re-added and provide
> a patch if this works.

Patch attached. I tested it and solves the failure with GNU MPFR.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Description: Fix generation of C code for C++ compilers.
 AC_CHECK_LIB fails with a C++ compiler (e.g., g++) because
   #ifdef __cplusplus
   extern "C"
   #endif
 is missing in the generated C code. There 3 lines were removed
 in commit 326c9a547423d25c621bc5c0ef76edbf6eda8c92 on 2020-10-09
 with the comment "(AC_LANG_CALL(C)): Remove #ifdef __cplusplus,
 this macro is no longer used to generate C++ code." but this is
 actually C code compiled with a C++ compiler, not C++ code.
Author: Vincent Lefevre 
Bug-Debian: https://bugs.debian.org/992981
Last-Update: 2021-08-25

Index: b/lib/autoconf/c.m4
===
--- a/lib/autoconf/c.m4
+++ b/lib/autoconf/c.m4
@@ -127,6 +127,9 @@ m4_if([$2], [main], ,
 [/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply.  */
+#ifdef __cplusplus
+extern "C"
+#endif
 char $2 ();])], [return $2 ();])])

Bug#754809: Debian bug-tracking system still generating bouncing emails that violate DMARC

2021-08-25 Thread Sébastien Noel


Same observation here:
DMARC aggregate reports notifies me that emails sends to the BTS
are not delivered to the final recipient.

I should not be surprised anymore if bugreports are left un-answered,
maintainers are simply not getting notification...

Since the last comment of this bug, 4 months have passed and no 
reaction.

I suspect that nobody recieved the last email, and my guts tell me
that i'm writing to /dev/null rigth now :(

Without a working BTS, i'm wondering :
Is the project still interested by users' feedback ?

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel


On 8/25/2021 12:45 PM, Chuck Zmudzinski wrote:

On 8/24/2021 7:12 PM, Ben Hutchings wrote:

On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote:

Ben Hutchings  writes:


I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
ï¿½ï¿½ï¿½ doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
ï¿½ï¿½ï¿½ values.

It's not clear to me whether the Xen driver is advertising 
correctly or

not.ï¿½ If it is, thenï¿½the solution should be b, but that may be too
disruptive a change to the kernel.ï¿½ So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
ï¿½ï¿½ï¿½ capabilities part of the modalias.

The problem with a) is that the Xen keyboard is not a physical keyboard
and so it has no way of knowing what keys it actually has.ï¿½ It is a 
fake

input device designed to pass through whatever input the Xen hypervisor
sends down.ï¿½ As such, any key could come in.ï¿½ If it doesn't advertise
that it has all of these keys, then they would not be accepted by
libinput when the hypervisor sends them down.

Right, that's what I feared.

xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC,
KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654
keys and 2362 bytes in the modalias.


This seems to be the heart of the problem: libinput was designed
assuming that all keyboards can and must report what keys are actually
present, and then libinput tries to cram that information into the
modalias rather than some other sysfs attribute as it should ( or 
not at
all... I still don't see how this information is actually supposed 
to be

useful to userspace ).

I think modaliases aren't intended to be interpreted by user-space,
other than processing wildcards when matching to modules.

For input devices, the same information is available through other
variables in the uevent, in a more compact form.ï¿½ The information *is*
useful for user-space; e.g. in initramfs-tools we recognise keyboard
devices and add their drivers to the initramfs but ignore other input
devices.


As for b), the problem isn't with the modalias attribute itself, but
when the kernel tries to copy it into the environment block for the 
udev
callout.ï¿½ The environment block is only a single page, and so 
limited to

4 KB.ï¿½ And that's for everything else that goes into the environment,
not just the modalias.

Text-based sysfs attributes are limited to a page, but udev receives
uevents through netlink, not sysfs.

The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).ï¿½ That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390 



But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.ï¿½ Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
ï¿½ ï¿½ #define UEVENT_HELPER_PATH_LENï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 256
ï¿½ #define UEVENT_NUM_ENVPï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 64ï¿½ï¿½ï¿½ /* 
number of env pointers */
-#define UEVENT_BUFFER_SIZEï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 2048ï¿½ï¿½ï¿½ /* buffer for the 
variables */
+#define UEVENT_BUFFER_SIZEï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ 4096ï¿½ï¿½ï¿½ /* buffer for the 
variables */

ï¿½ ï¿½ #ifdef CONFIG_UEVENT_HELPER
ï¿½ /* path to the userspace helper executed on an event */
--- END ---

?

Ben.




I will try it in my bullseye Xen HVM DomU.

I am not sure how to rebuild the installation media with a patched
systemd, but I can patch my installed Xen HVM DomU system
with a patched systemd with the increased buffer size and see if the
Coldplug failure early in the boot process goes away. If so, then it
is likely this patch to systemd would also fix the installation media.

If it doesn't work, I am also willing to try approach a by patching
the Linux kernel xen-kbdfront driver by removing the for loops that
advertise those 654 keys. I tend to agree with Philip that this is
totally unnecessary, but I suppose I could be wrong about that.
I read the discussion Philip had with the Xen developers and they
seemed to want to keep the Xen keyboard driver as it is.

Chuck


The build failed with an error. I used the test-patches script to start 
the build:


chuckz@debian:~/linuxdata/sources-bullseye/kernel/linux-5.10.46$ bash 
debian/bin/test-patches ../patch


with Ben's patch to UEVENT_BUFFER_SIZE in ../patch.

The build was running for over an hour and then failed with the last few 
lines on

the console as:

RT_SYMBOL
zl10039_attachï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ module: 
drivers/media/dvb-frontends/zl10039,

Bug#992854: digikam: symbol lookup error: undefined symbol: FT_Palette_Select

2021-08-25 Thread Steven Robbins

On Tuesday, August 24, 2021 4:32:33 A.M. CDT Alain Bertrand wrote:
>

> Launching digikam

> digikam: symbol lookup error:
> /lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5: undefined symbol: 
> FT_Palette_Select and digikam exits

I have not encountered this myself.  

A quick google suggested possibly an issue with freetype library -- see 
https://bbs.archlinux.org/viewtopic.php?id=259420

What is output of ldd /usr/bin/digikam |grep -i freetype ?
What freetype package/version is installed?

Best,
-Steve

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

Bug#992984: /usr/lib/byobu/disk_io: fails to show correct statistics

2021-08-25 Thread Rob Leslie

Package: byobu
Version: 5.133-1
Severity: normal
File: /usr/lib/byobu/disk_io
Tags: patch

Dear Maintainer,

Since upgrading to bullseye, the disk_io status notification fails to show
instantaneous statistics, and shows instead a persistent cumulative total of
all I/O.

The problem is due to the interaction between lines 65 and 75:

65> [ -r "$cache" ] && read x1 < "$cache" || x1=0

75> printf "%s" "$x2" > "$cache"

Because the $cache file is written without a terminating newline, the read
builtin returns failure, causing the || operator to execute x1=0.

According to sh(1):
> The read builtin will indicate success unless
>   EOF is encountered on input, in which case failure is returned.

A further problem is that when the I/O rate is below the $DISK_IO_THRESHOLD,
the previous statistics remain visible and are not cleared from the status
line.

The attached patch corrects these problems.


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

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

Versions of packages byobu depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  gawk   1:5.1.0-1
ii  gettext-base   0.21-4
ii  iproute2   5.10.0-4
ii  python33.9.2-3
ii  python3-newt   0.52.21-4+b3
ii  tmux   3.1c-1

Versions of packages byobu recommends:
ii  less551-2
pn  pastebinit  
pn  run-one 
ii  sensible-utils  0.0.14

Versions of packages byobu suggests:
pn  apport  
pn  ccze
ii  gnupg   2.2.27-2
ii  lsb-release 11.1.0
ii  po-debconf  1.0.21+nmu1
pn  screen  
pn  speedometer 
pn  ttf-ubuntu-font-family  
pn  update-notifier-common  
ii  vim 2:8.2.2434-3
pn  wireless-tools  
ii  xterm   366-1

-- debconf information excluded
--- /usr/lib/byobu/disk_io  2020-02-17 06:11:50.0 -0800
+++ .byobu/bin/disk_io  2021-08-25 14:24:57.322324975 -0700
@@ -72,11 +72,12 @@
symbol="$ICON_WR"
[ -n "$a7" ] && x2="$a7" || x2=0
fi
-   printf "%s" "$x2" > "$cache"
+   printf "%s\n" "$x2" > "$cache"
rate=$((($x2 - $x1) / ($t2 - $t1) * 512 / 1024))
if [ $rate -lt $DISK_IO_THRESHOLD ]; then
# Below threshold, don't print
-   continue
+   #continue
+   rate=""
elif [ "$rate" -lt 0 ]; then
rate=0
elif [ "$rate" -gt 1048576 ]; then

Bug#992985: unifont: Drop transitional dummy package ttf-unifont

Source: unifont
Version: 1:13.0.06-1
Severity: normal
X-Debbugs-CC: henr...@debian.org

Hi,

I believe the transitional dummy package ttf-unifont provided by src:unifont
can be removed with next package upload. I just worked on a bunch of reverse
dependencies to make sure that no package in Debian Sid currently depends on
ttf-unifont. Since ttf-unifont is already a transitional dummy package in
Debian 11, we may remove it in the Debian 12 release cycle.

Thanks,
Boyuan Yang


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

Bug#625295: Wrong Time-stamp

2021-08-25 Thread Jeremy Sowden

In your example, you are using TCP time-stamps:

  https://datatracker.ietf.org/doc/html/rfc7323#section-3

which are not the same as IP time-stamps:

  https://datatracker.ietf.org/doc/html/rfc781

Instead of:

  sudo hping3 --fast -c 3 -n -S -p 80 --tcp-timestamp $host

try:

  ping -T tsonly $host

J.


signature.asc
Description: PGP signature

Bug#992983: Yaegi build fails on 32bits arches

2021-08-25 Thread Alois Micard

Source: golang-github-traefik-yaegi
Version: 0.9.21-5
Severity: important
Tags: ftbfs
X-Debbugs-Cc: creekor...@debian.org

Yaegi build is failing for the following arches:

### armel

See: 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-traefik-yaegi=armel=0.9.21-5=1629926346=0

```
--- FAIL: TestInterpConsistencyBuild/build0.go (1.04s)
--- FAIL: TestInterpConsistencyBuild/const13.go (0.64s)
--- FAIL: TestInterpConsistencyBuild/unsafe4.go (1.27s)
--- FAIL: TestEvalShift/#01 (0.00s)
--- FAIL: TestFile/build0.go (0.01s)
--- FAIL: TestFile/const13.go (0.00s)
--- FAIL: TestFile/const20.go (0.00s)
--- FAIL: TestFile/unsafe3.go (0.03s)
--- FAIL: TestFile/unsafe4.go (0.02s)
--- FAIL: TestFile/unsafe5.go (0.00s)
```

### armhf

See: 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-traefik-yaegi=armel=0.9.21-5=1629926346=0

```
--- FAIL: TestInterpConsistencyBuild/build0.go (1.04s)
--- FAIL: TestInterpConsistencyBuild/const13.go (0.64s)
--- FAIL: TestInterpConsistencyBuild/unsafe4.go (1.27s)
--- FAIL: TestEvalShift/#01 (0.00s)
--- FAIL: TestFile/build0.go (0.01s)
--- FAIL: TestFile/const13.go (0.00s)
--- FAIL: TestFile/const20.go (0.00s)
--- FAIL: TestFile/unsafe3.go (0.03s)
--- FAIL: TestFile/unsafe4.go (0.02s)
--- FAIL: TestFile/unsafe5.go (0.00s)
```

### i386

See: 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-traefik-yaegi=i386=0.9.21-5=1629925198=0

```
runtime: marked free object in span 0xe72c7b10, elemsize=48 freeindex=1 (bad 
use of unsafe.Pointer? try -d=checkptr)
0xa9f4000 alloc marked  
0xa9f4030 free  marked   zombie
0a9f4030:         
0a9f4040:         
0a9f4050:         
[...]
fatal error: found pointer to free object

runtime stack:
runtime.throw(0x892a60d, 0x1c)
```

### s390x

See: 
https://buildd.debian.org/status/fetch.php?pkg=golang-github-traefik-yaegi=s390x=0.9.21-5=1629924866=0

```
--- FAIL: TestFile/unsafe3.go (0.00s)
```

Looks like the Yaegi build is failing on 32bits arches. I've opened this issue 
to further investigate and submit a PR if it applies.
Cheers,


-- 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/2 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#992981: autoconf: AC_CHECK_LIB no longer works with g++

Control: tags -1 upstream

On 2021-08-25 23:56:45 +0200, Vincent Lefevre wrote:
> I've found the cause. With Autoconf 2.69, there was
> 
> #ifdef __cplusplus
> extern "C"
> #endif
> 
> at the beginning of the test program generated by Autoconf.
> This is no longer the case with Autoconf 2.71. A manual test
> confirms that these 3 lines make the difference.

It seems that upstream commit 326c9a547423d25c621bc5c0ef76edbf6eda8c92
is the cause. I'm going to test with the 3 lines re-added and provide
a patch if this works.

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

Bug#992981: autoconf: AC_CHECK_LIB no longer works with g++

On 2021-08-25 23:41:34 +0200, Vincent Lefevre wrote:
> When I want to build MPFR with g++, I get:
> 
> checking for __gmpz_init in -lgmp... no
> configure: error: libgmp not found or uses a different ABI (including static 
> vs shared).
> 
> due to
> 
> dnl Check if we can link with GMP
> AC_CHECK_LIB(gmp, __gmpz_init, [LIBS="-lgmp $LIBS"],
>  [AC_MSG_ERROR([libgmp not found or uses a different ABI (including static vs 
> shared).
> Please read the INSTALL file -- see "In case of problem".])])
> 
> in the configure.ac file.

Note: the error is

  undefined reference to `__gmpz_init()'

I've found the cause. With Autoconf 2.69, there was

#ifdef __cplusplus
extern "C"
#endif

at the beginning of the test program generated by Autoconf.
This is no longer the case with Autoconf 2.71. A manual test
confirms that these 3 lines make the difference.

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

Bug#992974: exim4-config: permit to include local file in acl_check_mail

2021-08-25 Thread Noury

Le 2021-08-25 22:00, Marc Haber a écrit :
> On Wed, Aug 25, 2021 at 09:23:47PM +0200, Noury wrote:
> > Can you please add the following lines in 
> > /etc/exim4/conf.d/acl/30_exim4-config_check_mail
> > 
> >   .ifdef CHECK_MAIL_LOCAL_ACL_FILE
> >   .include CHECK_MAIL_LOCAL_ACL_FILE
> >   .endif
> > 
> > This can be necessary, even if documentation says it's not.
> 
> The ACL in /etc/exim4/conf.d/acl/30_exim4-config_check_mail is a
> one command "ACCEPT" acl that can easily be overridden by setting a
> completly own ACL by setting MAIN_ACL_CHECK_MAIL.
> 
> Greetings
> Marc
> 
> -- 
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
> 

Hello Marc,

I didn't know MAIN_ACL_CHECK_MAIL.
I've just tried it and it works fine.
Thanks a lot!
"bug" can be closed.

Bug#992982: mate-themes: firefox icon not following themes

2021-08-25 Thread Samuel Thibault

Package: mate-themes
Version: 3.22.21-1
Severity: normal
Tags: a11y

Hello,

A user who uses the inverted high contrast theme reported that in
the application menu, the firefox icon is not getting its inverted
high contrast variant. Apparently, this is because we are using
firefox-esr.desktop, which references the firefox-esr icon, and
mate-themes only provides a firefox icon. I guess the firefox.png icons
could be duplicated into firefox-esr.png icons? Possibly even in
upstream?

Samuel

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

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

Versions of packages mate-themes depends on:
ii  gtk2-engines  1:2.20.2-5
ii  gtk2-engines-murrine  0.98.2-3+b1
ii  gtk2-engines-pixbuf   2.24.33-2
ii  librsvg2-common   2.50.3+dfsg-1
ii  mate-icon-theme   1.24.0-1

mate-themes recommends no packages.

mate-themes suggests no packages.

-- no debconf information

Bug#992967: ITP: erlang-poolboy -- Erlang worker pool factory

2021-08-25 Thread James Valleroy

Package: wnpp
Severity: wishlist
Owner: James Valleroy 
X-Debbugs-Cc: debian-de...@lists.debian.org, jvalle...@mailbox.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: erlang-poolboy
  Version : 1.5.2
  Upstream Author : Devin Torres 
* URL : https://github.com/devinus/poolboy
* License : Unlicense or ISC
  Programming Lang: Erlang
  Description : Erlang worker pool factory

A lightweight, generic pooling library for Erlang with a focus on
simplicity, performance, and rock-solid disaster recovery.

This is a dependency of pleroma (#895050). It will be maintained in
the Erlang team.

-BEGIN PGP SIGNATURE-

iQJKBAEBCgA0FiEEfWrbdQ+RCFWJSEvmd8DHXntlCAgFAmEmgIEWHGp2YWxsZXJv
eUBtYWlsYm94Lm9yZwAKCRB3wMdee2UICAHND/9D1dMaRJR2CfQaOpGDs/5YkJc4
0gOCRNlRBazA9qQaZmV8XZ1WeF8xcQInTEYJgCRq4sy1+h5rKmZxXlbN+W92KF3H
5EAqhlGb1OiF1R7G8khU6hxlMs0vzhYsk7ZXI+l8KUzuyGhlgYGKUoPA+ww6dEum
Mh+8emz5ShLGzAz9sxseKYlLtGLp1wSjf84ZoaxqfJo8dia/6skrz3mIDi63/M6C
W3tOABB9Hm4QzHWdr3bELNq2HBDuYwVGoQPUWRlcC2nXLjWXm4+MKMJljkNdfBgV
YHyyYauLsAWHrpFi0+33mIN6YFCavEWY/Dikh0dpntv4cPCjtcBg7hdxa3MXBFLg
AsA7wmS7q+UGrMjG3roBsDd1PueGbd+IDEPPEZLZztq/bXn0VbIPw4LIltLE0vYo
1tNw1MC4a8VAsZ/TqbKTTsEBH6BuRIb+8Amq3Xxu0i7xOzSK36aUlKIl3WMHevul
iU+Yw0Mnebffcke+KeFvkgwW48x0/n4ZNNb/Dwe21f/IPFFWXHfnFnj+RZ4xSt+e
eQo5HCZNNJgnfuIWvkCqI1lAQE8esnfQ/KQ8B8BAw3IMWbsdUvpj8bNqksbAJNUC
5qxQMu6EptLvMsKjA4R4oQszTQV92wXaUefKiMpvuQTw4VdT3PqbZF7h3Vph/wK6
l/WmQCXytrTbC+iasg==
=iEOn
-END PGP SIGNATURE-

Bug#992981: autoconf: AC_CHECK_LIB no longer works with g++

Package: autoconf
Version: 2.71-2
Severity: important

When I want to build MPFR with g++, I get:

checking for __gmpz_init in -lgmp... no
configure: error: libgmp not found or uses a different ABI (including static vs 
shared).

due to

dnl Check if we can link with GMP
AC_CHECK_LIB(gmp, __gmpz_init, [LIBS="-lgmp $LIBS"],
 [AC_MSG_ERROR([libgmp not found or uses a different ABI (including static vs 
shared).
Please read the INSTALL file -- see "In case of problem".])])

in the configure.ac file.

This is a regression: this error disappears if I downgrade to
autoconf 2.69-14.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages autoconf depends on:
ii  debianutils  5.4-3
ii  m4   1.4.18-5
ii  perl 5.32.1-5

Versions of packages autoconf recommends:
ii  automake [automaken]  1:1.16.4-1

Versions of packages autoconf suggests:
ii  autoconf-archive  20190106-2.1+local1
ii  autoconf-doc  2.71-2
ii  gettext   0.21-4
ii  gnu-standards 2010.03.11-1.1
ii  libtool   2.4.6-15+local1

-- no debconf information

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

Bug#992924: freefem++: autopkgtest failure on arm64/ppc64el

2021-08-25 Thread François Mazen

Hello Adrian,

thanks for making the failures visible with this bug. 

I'm waiting for my access to porter boxes [1] in order to debug and fix
the issue(s).

In the meantime, do not hesitate to provide patch or any kind of help.

Best Regards,
François

[1]: https://nm.debian.org/process/920/approval/

Bug#893745: PR on salsa.debian.org

2021-08-25 Thread Mattias Ellert

Control: tags 893745 + patch

https://salsa.debian.org/python-team/packages/python-cffi/-/merge_requests/2

Mattias



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

Bug#992979: sagemath: Blank black page for 3D plots using three.js viewer

2021-08-25 Thread Tobias Hansen

Hi,

yes, this is probably because sagemath 9.2 uses threejs 117 while in Debian we 
are using / trying to use the Debian package three.js which is at version 111. 
Replacing js stuff with Debian packages is always fiddly...

Best,
Tobias

On 8/25/21 9:56 PM, Balbir Thomas wrote:
> Package: sagemath
> Version: 9.2-2
> Severity: normal
>
> Dear Maintainer,
>
> Creating any 3D graphics using the default three.js viewer
> opens a blank black page in the web browser. The same plot
> with an argument "viewer=tachyon" or "viewer=jmol" results
> in a correct plot.
>
> It was suggested in IRC that this may be a wayland issue
> but I did check I am not running wayland using
>
> loginctl show-session $XDG_SESSION_ID -p Type
>
> and this shows the session type is tty. I am using the FVWM
> desktop.
>
> -- System Information:
> Debian Release: 11.0
>   APT prefers stable-security
>   APT policy: (500, 'stable-security'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.10.0-8-amd64 (SMP w/6 CPU threads)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_GB:en
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages sagemath depends on:
> ii  curl  7.74.0-1.3+b1
> ii  cysignals-tools   1.10.2+ds-6
> ii  cython3   0.29.21-3+b1
> ii  ecl   20.4.24+ds-2
> ii  eclib-tools   20190909-3+b1
> ii  fflas-ffpack  2.4.3-2
> ii  flintqs   1:1.0-3+b1
> ii  gap-atlasrep  2.1.0-3
> ii  gap-dev   4.11.0-4
> ii  gap-online-help   4.11.0-4
> ii  gap-primgrp   3.4.0-1
> ii  gap-smallgrp  1.4.1-2
> ii  gap-table-of-marks1.2.9-1
> ii  gap-transgrp  2.0.6-2
> ii  gfan  0.6.2-4
> ii  glpk-utils5.0-1
> ii  gmp-ecm   7.0.4+ds-5
> ii  ipython3  7.20.0-1
> ii  iso-codes 4.6.0-1
> ii  jmol  
> 14.6.4+2016.11.05+dfsg1-4
> ii  lcalc 1.23+dfsg-11+b1
> ii  less  551-2
> ii  libatlas3-base [libblas.so.3] 3.10.3-10
> ii  libblas3 [libblas.so.3]   3.9.0-3
> ii  libbraiding0  1.0-1+b1
> ii  libbrial-groebner31.2.10-1+b1
> ii  libbrial3 1.2.10-1+b1
> ii  libc6 2.31-13
> ii  libcdd-tools  094l-2
> ii  libcliquer1   1.21-2
> ii  libec520190909-3+b1
> ii  libecm1   7.0.4+ds-5
> ii  libflint-2.6.32.6.3-3
> ii  libflint-arb2 1:2.19.0-1
> ii  libgap7   4.11.0-4
> ii  libgcc-s1 10.2.1-6
> ii  libgd32.3.0-2
> ii  libgiac0  1.6.0.41+dfsg1-1
> ii  libgivaro94.1.1-2
> ii  libglpk40 5.0-1
> ii  libgmp10  2:6.2.1+dfsg-1
> ii  libgmpxx4ldbl 2:6.2.1+dfsg-1
> ii  libgomp1  10.2.1-6
> ii  libgsl25  2.6+dfsg-2
> ii  libhomfly01.02r6-1
> ii  libiml0   1.0.4-1+b2
> ii  libjs-mathjax 2.7.9+dfsg-1
> ii  libjs-three   111+dfsg1-2
> ii  liblfunction0 1.23+dfsg-11+b1
> ii  liblrcalc11.2-2+b1
> ii  libm4ri-0.0.20200125  20200125-1+b1
> ii  libm4rie-0.0.20200125 20200125-1+b2
> ii  libmpc3   1.2.0-1
> ii  libmpfi0  1.5.3+ds-5
> ii  libmpfr6  4.1.0-3
> ii  libntl43

Bug#992980: gnome-shell complains if using lightdm

2021-08-25 Thread GT

Package: gnome-shell
Version: 3.38.4-1
Severity: normal

Dear Maintainer

   * What led up to the situation?
open a gnome session using lightdm
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
a notification is displayed at every session opening saying i am not using gdm
   * What outcome did you expect instead?
not to be enoying by notification.For sure i don't use gdm, i choose lighdm

Here the log messages
```
août 25 16:14:14 debian gnome-shell[5341]: GNOME Shell started at Wed Aug 25
2021 16:14:11 GMT+0200 (CEST)
août 25 16:14:14 debian gnome-shell[5341]: JS ERROR: TypeError:
file.touch_async is not a function
_handleLockScreenWarning@resource:///org/gnome/shell/ui/main.js:327:29
_initializeUI/<@resource:///org/gnome/shell/ui/main.js:300:13
_startupAnimationComplete@resource:///org/gnome/shell/ui/layout.js:733:14
_startupAnimation@resource:///org/gnome/shell/ui/layout.js:688:18
_prepareStartupAnimation@resource:///org/gnome/shell/ui/layout.js:683:14
_loadBackground/signalId
ii  chrome-gnome-shell10.1-5
ii  gdm3  3.38.2.1-1
ii  gkbd-capplet  3.26.1-1+b1
ii  gnome-control-center  1:3.38.4-1
ii  gnome-menus   3.36.0-1
ii  gnome-user-docs   40.4-1
pn  ibus  
ii  iio-sensor-proxy  3.0-2
pn  switcheroo-control
ii  unzip 6.0-26

Versions of packages gnome-shell suggests:
ii  gir1.2-telepathyglib-0.12   0.24.1-3
ii  gir1.2-telepathylogger-0.2  0.8.2-4

Versions of packages gnome-session depends on:
ii  gnome-session-bin  3.38.0-4
ii  gnome-session-common   3.38.0-4
ii  gnome-settings-daemon  3.38.2-1

Versions of packages gnome-session suggests:
ii  desktop-base   11.0.3
ii  gnome-keyring  3.36.0-1

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  3.38.2-1
ii  gsettings-desktop-schemas 3.38.0-2
ii  libasound21.2.5.1-1
ii  libc6 2.31-13
ii  libcairo2 1.16.0-5
ii  libcanberra-gtk3-00.30-7+b1
ii  libcanberra0  0.30-7+b1
ii  libcolord21.4.5-3
ii  libcups2  2.3.3op2-3+deb11u1
ii  libfontconfig12.13.1-4.2
ii  libgcr-base-3-1   3.38.1-2
ii  libgdk-pixbuf-2.0-0   2.42.6+dfsg-2
ii  libgeoclue-2-02.5.7-3
ii  libgeocode-glib0  3.26.2-2
ii  libglib2.0-0  2.68.4-1
ii  libgnome-desktop-3-19 3.38.5-3
ii  libgtk-3-03.24.30-1
ii  libgudev-1.0-0234-1
ii  libgweather-3-16  3.36.1-3
ii  liblcms2-22.12~rc1-2
ii  libmm-glib0   1.14.12-0.2
ii  libnm01.30.6-1
ii  libnotify40.7.9-3
ii  libnspr4  2:4.32-1
ii  libnss3   2:3.68-1
ii  libpam-systemd [logind]   247.9-1
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libpolkit-gobject-1-0 0.105-31
ii  libpulse-mainloop-glib0   14.2-2
ii  libpulse0 14.2-2
ii  libupower-glib3   0.99.11-2
ii  libwacom2 1.8-2
ii  libwayland-client01.19.0-2
ii  libx11-6  2:1.7.2-1
ii  libxext6  2:1.3.3-1.1
ii  libxi62:1.7.10-1

Versions of packages gnome-settings-daemon recommends:
ii  iio-sensor-proxy   3.0-2
ii  pulseaudio 14.2-2
ii  x11-xserver-utils  7.7+8

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

Versions of packages libgjs0g depends on:
ii  libc6  2.31-13
ii  libcairo-gobject2  1.16.0-5
ii  libcairo2  1.16.0-5
ii  libffi73.3-6
ii  libgcc-s1  10.2.1-6
ii  libgirepository-1.0-1  1.68.0-2
ii  libglib2.0-0   2.68.4-1
ii  libmozjs-78-0  78.4.0-2
ii  libreadline8   8.1-2
ii  libstdc++6 10.2.1-6
ii  libx11-6   2:1.7.2-1

Versions of packages gnome-shell is related to:
ii  libegl-mesa0 [libegl-vendor]  20.3.5-1
ii  libgl1-mesa-dri   20.3.5-1
ii  libglx-mesa0 [libglx-vendor]  20.3.5-1

Bug#992979: sagemath: Blank black page for 3D plots using three.js viewer

2021-08-25 Thread Balbir Thomas

Package: sagemath
Version: 9.2-2
Severity: normal

Dear Maintainer,

Creating any 3D graphics using the default three.js viewer
opens a blank black page in the web browser. The same plot
with an argument "viewer=tachyon" or "viewer=jmol" results
in a correct plot.

It was suggested in IRC that this may be a wayland issue
but I did check I am not running wayland using

loginctl show-session $XDG_SESSION_ID -p Type

and this shows the session type is tty. I am using the FVWM
desktop.

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

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

Versions of packages sagemath depends on:
ii  curl  7.74.0-1.3+b1
ii  cysignals-tools   1.10.2+ds-6
ii  cython3   0.29.21-3+b1
ii  ecl   20.4.24+ds-2
ii  eclib-tools   20190909-3+b1
ii  fflas-ffpack  2.4.3-2
ii  flintqs   1:1.0-3+b1
ii  gap-atlasrep  2.1.0-3
ii  gap-dev   4.11.0-4
ii  gap-online-help   4.11.0-4
ii  gap-primgrp   3.4.0-1
ii  gap-smallgrp  1.4.1-2
ii  gap-table-of-marks1.2.9-1
ii  gap-transgrp  2.0.6-2
ii  gfan  0.6.2-4
ii  glpk-utils5.0-1
ii  gmp-ecm   7.0.4+ds-5
ii  ipython3  7.20.0-1
ii  iso-codes 4.6.0-1
ii  jmol  14.6.4+2016.11.05+dfsg1-4
ii  lcalc 1.23+dfsg-11+b1
ii  less  551-2
ii  libatlas3-base [libblas.so.3] 3.10.3-10
ii  libblas3 [libblas.so.3]   3.9.0-3
ii  libbraiding0  1.0-1+b1
ii  libbrial-groebner31.2.10-1+b1
ii  libbrial3 1.2.10-1+b1
ii  libc6 2.31-13
ii  libcdd-tools  094l-2
ii  libcliquer1   1.21-2
ii  libec520190909-3+b1
ii  libecm1   7.0.4+ds-5
ii  libflint-2.6.32.6.3-3
ii  libflint-arb2 1:2.19.0-1
ii  libgap7   4.11.0-4
ii  libgcc-s1 10.2.1-6
ii  libgd32.3.0-2
ii  libgiac0  1.6.0.41+dfsg1-1
ii  libgivaro94.1.1-2
ii  libglpk40 5.0-1
ii  libgmp10  2:6.2.1+dfsg-1
ii  libgmpxx4ldbl 2:6.2.1+dfsg-1
ii  libgomp1  10.2.1-6
ii  libgsl25  2.6+dfsg-2
ii  libhomfly01.02r6-1
ii  libiml0   1.0.4-1+b2
ii  libjs-mathjax 2.7.9+dfsg-1
ii  libjs-three   111+dfsg1-2
ii  liblfunction0 1.23+dfsg-11+b1
ii  liblrcalc11.2-2+b1
ii  libm4ri-0.0.20200125  20200125-1+b1
ii  libm4rie-0.0.20200125 20200125-1+b2
ii  libmpc3   1.2.0-1
ii  libmpfi0  1.5.3+ds-5
ii  libmpfr6  4.1.0-3
ii  libntl43  11.4.3-1+b1
ii  libopenblas0  0.3.13+ds-3
ii  libopenblas0-pthread [libblas.so.3]   0.3.13+ds-3
ii  libpari-gmp-tls7  2.13.1-1
ii  libplanarity0 3.0.1.0-1
ii  libpynac18py3 0.7.27-1
ii  libratpoints-2.1.31:2.1.3-1+b2
ii  libreadline8  8.1-1

Bug#992978: buster-pu: package mbrola/3.3+dfsg-4+deb11u1

2021-08-25 Thread Samuel Thibault

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

[ Reason ]
As of version 3.3, mbrola does not properly detect the end of file of
its input, and thus remains stuck when e.g. the espeakup daemon is
terminating and wants to cleanly terminate its mbrola child process.

This is a regression compared to buster, in which the relevant code was
quite different.

[ Impact ]
Restarting the espeakup screen reader daemon (e.g. at the very least on
upgrading from bullseye to bookworm) remains stuck, until systemd loses
patience (which takes a minute or so). In the meanwhile the computer is
speechless, thus unusable for the blind user.

[ Tests ]
This was tested manually in unstable.

[ Risks ]
The code is very simple.

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

[ Changes ]
The do/while loop that keeps reading input data now breaks also when
feof(input) returns true.
diff -Nru mbrola-3.3+dfsg/debian/changelog mbrola-3.3+dfsg/debian/changelog
--- mbrola-3.3+dfsg/debian/changelog2021-01-01 17:16:15.0 +0100
+++ mbrola-3.3+dfsg/debian/changelog2021-08-25 22:20:51.0 +0200
@@ -1,3 +1,9 @@
+mbrola (3.3+dfsg-4+deb11u1) bullseye; urgency=medium
+
+  * patches/EOF: Fix detecting end of file.
+
+ -- Samuel Thibault   Wed, 25 Aug 2021 22:20:51 +0200
+
 mbrola (3.3+dfsg-4) unstable; urgency=medium
 
   * patches/flags: Fix passing hardening flags.
diff -Nru mbrola-3.3+dfsg/debian/patches/EOF mbrola-3.3+dfsg/debian/patches/EOF
--- mbrola-3.3+dfsg/debian/patches/EOF  1970-01-01 01:00:00.0 +0100
+++ mbrola-3.3+dfsg/debian/patches/EOF  2021-08-25 22:20:34.0 +0200
@@ -0,0 +1,24 @@
+https://github.com/numediart/MBROLA/pull/35
+
+commit 151763240cb170943e8cc050df8a1ae6347cb7bf
+Author: Samuel Thibault 
+Date:   Fri Aug 20 00:43:29 2021 +0200
+
+Fix detecting EOF
+
+fgets returns NULL on EOF as well, so we need to call feof to properly
+detect EOF.
+
+diff --git a/Parser/input_file.c b/Parser/input_file.c
+index eea2da2..ac3454d 100644
+--- a/Parser/input_file.c
 b/Parser/input_file.c
+@@ -38,7 +38,7 @@ static long readline_InputFile(Input* in, char *line, int 
size)
+ 
+   do
+   ret = fgets(line, size, (FILE*)in->self);
+-  while (ret == NULL && errno == EINTR);
++  while (ret == NULL && !feof((FILE*)in->self) && errno == EINTR);
+ 
+   return ret != NULL;
+ }
diff -Nru mbrola-3.3+dfsg/debian/patches/series 
mbrola-3.3+dfsg/debian/patches/series
--- mbrola-3.3+dfsg/debian/patches/series   2020-12-30 17:53:50.0 
+0100
+++ mbrola-3.3+dfsg/debian/patches/series   2021-08-25 22:20:34.0 
+0200
@@ -1,2 +1,3 @@
 intr
 flags
+EOF

Bug#992572:

2021-08-25 Thread Nicholas Brown

Severity: Important

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel


On 8/24/2021 7:12 PM, Ben Hutchings wrote:

On Tue, Aug 24, 2021 at 03:27:19PM -0400, Phillip Susi wrote:

Ben Hutchings  writes:


I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
values.

It's not clear to me whether the Xen driver is advertising correctly or
not.  If it is, thenï¿½the solution should be b, but that may be too
disruptive a change to the kernel.  So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
capabilities part of the modalias.

The problem with a) is that the Xen keyboard is not a physical keyboard
and so it has no way of knowing what keys it actually has.  It is a fake
input device designed to pass through whatever input the Xen hypervisor
sends down.  As such, any key could come in.  If it doesn't advertise
that it has all of these keys, then they would not be accepted by
libinput when the hypervisor sends them down.

Right, that's what I feared.

xen-kbdfront is setting the bits for keys in the ranges [KEY_ESC,
KEY_UNKNOWN) and [KEY_OK, KEY_MAX), which I think works out to 654
keys and 2362 bytes in the modalias.


This seems to be the heart of the problem: libinput was designed
assuming that all keyboards can and must report what keys are actually
present, and then libinput tries to cram that information into the
modalias rather than some other sysfs attribute as it should ( or not at
all... I still don't see how this information is actually supposed to be
useful to userspace ).

I think modaliases aren't intended to be interpreted by user-space,
other than processing wildcards when matching to modules.

For input devices, the same information is available through other
variables in the uevent, in a more compact form.  The information *is*
useful for user-space; e.g. in initramfs-tools we recognise keyboard
devices and add their drivers to the initramfs but ignore other input
devices.


As for b), the problem isn't with the modalias attribute itself, but
when the kernel tries to copy it into the environment block for the udev
callout.  The environment block is only a single page, and so limited to
4 KB.  And that's for everything else that goes into the environment,
not just the modalias.

Text-based sysfs attributes are limited to a page, but udev receives
uevents through netlink, not sysfs.

The current limit on the environment of a uevent appears to be 2 KB
(UEVENT_BUFFER_SIZE defined in ).  That seems like it
*might* be easier to change, so long as user-space doesn't have a
similar limit.

I looked into systemd/udev, and it seems to use an 8 KB buffer for
receiving uevents:

https://sources.debian.org/src/systemd/247.9-1/src/libsystemd/sd-device/device-monitor.c/?hl=390#L390

But as a first step I think increasing the kernel buffer size to 4 KB
would be enough.  Perhaps someone could test whether this patch to the
domU kernel makes udev happier:

--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -30,7 +30,7 @@
  
  #define UEVENT_HELPER_PATH_LEN		256

  #define UEVENT_NUM_ENVP   64  /* number of env 
pointers */
-#define UEVENT_BUFFER_SIZE 2048/* buffer for the variables */
+#define UEVENT_BUFFER_SIZE 4096/* buffer for the variables */
  
  #ifdef CONFIG_UEVENT_HELPER

  /* path to the userspace helper executed on an event */
--- END ---

?

Ben.




I will try it in my bullseye Xen HVM DomU.

I am not sure how to rebuild the installation media with a patched
systemd, but I can patch my installed Xen HVM DomU system
with a patched systemd with the increased buffer size and see if the
Coldplug failure early in the boot process goes away. If so, then it
is likely this patch to systemd would also fix the installation media.

If it doesn't work, I am also willing to try approach a by patching
the Linux kernel xen-kbdfront driver by removing the for loops that
advertise those 654 keys. I tend to agree with Philip that this is
totally unnecessary, but I suppose I could be wrong about that.
I read the discussion Philip had with the Xen developers and they
seemed to want to keep the Xen keyboard driver as it is.

Chuck

Bug#992421: dnslookup_relay_to_domains probably needs ignore_target_hosts

2021-08-25 Thread Marc Haber

On Tue, Aug 24, 2021 at 07:47:46PM +0200, Andreas Metzler wrote:
> According to chapter 3, »8. Recognizing the local host« exim uses the
> local_interfaces setting (unless it is 0.0.0.0 or ::0) to recognize the
> local host. - Are you setting it?

No, MAIN_LOCAL_INTERFACES isn't set.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#992977: spdlog: Failed upstream test set_level_to_string_view

Source: spdlog
Severity: important
Version: 1:1.8.5+ds-1
Forwarded: https://github.com/gabime/spdlog/issues/1896

Dear Debian spdlog maintainer,

Current spdlog/1.8.5 in Debian has a failed test, according to autopkgtest.

This issue is known to upstream and is not fixed yet:
https://github.com/gabime/spdlog/issues/1896 .

The fix for now could be disabling this specific test for now, such as
disabling the test case of set_level_to_string_view. Spdlog also released
multiple new versions of spdlog recently; we need to check whether new
versions in future would fix this bug as well.

Thanks,
Boyuan Yang


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

Bug#992056: PID integer overflow fix

2021-08-25 Thread Victor Timofei


I made a patch that fixes this issue.

You can check it out on https://github.com/angeloc/htpdate/pull/8

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Phillip Susi

Chuck Zmudzinski  writes:
> If it doesn't work, I am also willing to try approach a by patching
> the Linux kernel xen-kbdfront driver by removing the for loops that
> advertise those 654 keys. I tend to agree with Philip that this is
> totally unnecessary, but I suppose I could be wrong about that.
> I read the discussion Philip had with the Xen developers and they
> seemed to want to keep the Xen keyboard driver as it is.

That was the first thing I tried and the libinput maintainer pointed out
that if you don't advertise the keys, you can't use the keys.  In other
words, somebody presses that key on their keyboard and the domU won't
recognize it.

Bug#992976: uscan: mode=git refs/heads/ instruction scans for tags instead, and fails

2021-08-25 Thread Romain Porte

Package: devscripts
Version: 2.21.3
Severity: important
X-Debbugs-Cc: deb...@microjoe.org

Dear Maintainer,

While trying to use uscan to scan for upstream commits on a specific
branch instead of the default on, I tried to use refs/heads/ as
explained in the uscan man page.

Here is the content of the d/watch file I am using:

version=4
opts="mode=git, gitmode=full, pgpmode=none, pretty=8.994+git%cd.%h, repack, 
compression=xz" \
https://bitbucket.org/jpcgt/flatcam.git \
refs/heads/Beta

However when running uscan, the invocation fails with the following
message:

uscan info: uscan (version 2.21.3) See uscan(1) for help
uscan info: Scan watch files in .
uscan info: Check debian/watch and debian/changelog in .
uscan info: package="flatcam" version="8.994+ds-1" (as seen in 
debian/changelog)
uscan info: package="flatcam" version="8.994+ds" (no epoch/revision)
uscan info: ./debian/changelog sets package="flatcam" version="8.994+ds"
uscan info: Process watch file at: debian/watch
package = flatcam
version = 8.994+ds
pkg_dir = .
uscan info: opts: mode=git, gitmode=full, pgpmode=none, 
pretty=8.994+git%cd.%h, repack, compression=xz
uscan info: line: https://bitbucket.org/jpcgt/flatcam.git refs/heads/Beta
uscan info: Parsing mode=git
uscan info: Parsing  gitmode=full
uscan info: Parsing  pgpmode=none
uscan info: Parsing  pretty=8.994+git%cd.%h
uscan info: Parsing  repack
uscan info: Parsing  compression=xz
uscan info: line: https://bitbucket.org/jpcgt/flatcam.git refs/heads/Beta
uscan warn: Tag pattern missing version delimiters () in debian/watch, 
skipping:
  https://bitbucket.org/jpcgt/flatcam.git refs/heads/Beta
uscan info: Scan finished

The scan fails because *tag pattern* is not found. But I am not looking
for tags but for the last commit of a branch (refs/heads/*).

Quoting the man page:

If matching-pattern is set to refs/heads/branch, uscan
downloads source from the named branch of the git repository.

Expected behavior would be uscan to download the latest commit of the
branch, without any pattern required to be matched.

Thanks.

-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.20.9
ii  fakeroot  1.25.3-1.1
ii  file  1:5.39-3
ii  gnupg 2.2.27-2
ii  gnupg22.2.27-2
ii  gpgv  2.2.27-2
ii  libc6 2.31-13
ii  libfile-dirlist-perl  0.05-2
ii  libfile-homedir-perl  1.006-1
ii  libfile-touch-perl0.11-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20200505.0-1
ii  libmoo-perl   2.004004-1
ii  libwww-perl   6.52-1
ii  patchutils0.4.2-1
ii  perl  5.32.1-4+deb11u1
ii  python3   3.9.2-3
ii  sensible-utils0.0.14
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 2.2.4
ii  curl7.74.0-1.3+b1
ii  dctrl-tools 2.24-3+b1
ii  debian-keyring  2021.07.26
ii  dput-ng [dput]  1.33
ii  equivs  2.3.1
ii  libdistro-info-perl 1.0
ii  libdpkg-perl1.20.9
ii  libencode-locale-perl   1.05-1.1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.26-1
ii  liblist-compare-perl0.55-1
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 5.08-1
ii  licensecheck3.1.1-2
ii  lintian 2.104.0
ii  man-db  2.9.4-2
ii  patch   2.7.6-7
ii  pristine-tar1.49
ii  python3-apt 2.2.1
ii  python3-debian  0.1.39
ii  python3-magic   2:0.4.20-3
ii  python3-requests2.25.1+dfsg-2
ii  python3-unidiff 0.5.5-2
ii  python3-xdg 0.27-2
ii  strace  5.10-1
ii  unzip   6.0-26
ii  wget1.21-1+b1
ii  xz-utils5.2.5-2

Versions of packages devscripts suggests:
pn  adequate  
ii  at3.1.23-1.1
ii  autopkgtest   5.16
pn  bls-standalone

Bug#992786: passenger uses many vendored libraries

2021-08-25 Thread Adrian Bunk

On Mon, Aug 23, 2021 at 08:18:42AM -0400, Michael Lazin wrote:
> I am new to this list and would like to get involved, but I am a relative
> beginner in programming.   I understand from looking at this CVE that it is
> triggered by a particular type of API call, which is probably unlikely in
> the wild, unless prior recon has been done and there is already a threat
> actor inside.  The threat is less than six.  I work in security and I have
> seen many environments where threats this low are not patched.
>...

Debian has already issued a security advisory for this specific 
vulnerabily for the libuv1 package (and sent to the wrong list):
https://www.debian.org/security/2021/dsa-4936

My bug report was about passenger having copies of libraries that might
also be vulnerable to CVEs like for example this one.

> If I would
> have time and would want to volunteer help, can someone instruct me how to
> get started?  Thank you in advance. I apologize if I am making noise on the
> list, I just signed up.  I thought QA would be an easy way to get started
> in the Debian community.  Thanks.

That's appreciated.

General information:
https://www.debian.org/intro/help

The debian-mentors mailing list would be a good starting point for 
helping other contributors with problems packaging and maintaining 
software in Debian.

> Michael Lazin
>...

cu
Adrian

Bug#992949: tmix FTCBFS: AC_RUN_IFELSE

2021-08-25 Thread Romain Francoise

Hi,

Thanks for the report. Can you submit the patch upstream through the
GitHub issue tracker? It'll be more efficient than having to push a
patch on your behalf.

Bug#992974: exim4-config: permit to include local file in acl_check_mail

2021-08-25 Thread Marc Haber

On Wed, Aug 25, 2021 at 09:23:47PM +0200, Noury wrote:
> Can you please add the following lines in 
> /etc/exim4/conf.d/acl/30_exim4-config_check_mail
> 
>   .ifdef CHECK_MAIL_LOCAL_ACL_FILE
>   .include CHECK_MAIL_LOCAL_ACL_FILE
>   .endif
> 
> This can be necessary, even if documentation says it's not.

The ACL in /etc/exim4/conf.d/acl/30_exim4-config_check_mail is a
one command "ACCEPT" acl that can easily be overridden by setting a
completly own ACL by setting MAIN_ACL_CHECK_MAIL.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#992947: due wrongly recommends qemu package

2021-08-25 Thread Alexander Doyle

Hi Michael,
 That makes sense. I'm working on a few updates to DUE anyway and will roll a 
fix in with them to reduce churn.

The intent of recommending QEMU (as one would expect) was to allow containers 
built from different architectures to run locally, so it's probably 
qemu-user-static since that has to be embedded in the resulting Docker image.  
I'll do some testing to see if this configuration has any dependencies on a 
qemu-user installation in the host environment.

Thanks!
Alex

From: Michael Tokarev 
Sent: Wednesday, August 25, 2021 5:28 AM
To: Debian Bug Tracking System 
Subject: Bug#992947: due wrongly recommends qemu package

External email: Use caution opening links or attachments


Package: due
Version: 2.3.0-2
Severity: important
X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org

The "due" package has "qemu" in its Recommends section.
This is completely wrong, especially since there's another
 Recommends for qemu-user-static right next to qemu.

In the long past, when qemu first appeared in Debian,
there was just one binary package, named qemu, which
contained everything. Later on, it has been split at
least to full system emulation package (qemu-system)
and to user-level emulation package (qemu-user and
qemu-user-static), with "qemu" becoming a metapackage
and depending on everything.

But later on it has become clear that installing whole
qemu is useless. So "qemu" package become a dummy empty
package with nothing in it and no dependencies.

Many bugs has been filed against numerous packages which
listed "qemu" in various dependencies, and most of them
has been fixed by now.

But it seems some new packages emerged which again list
qemu as one of dependencies.

Please remove it from Recommends.  And while doing this,
please actually think about what you want to recommend.

If you want some user emulation, there are 2 packages -
qemu-user and qemu-user-static, both providing the same
set of binaries but the latter is compiled statically
so it is easier to run things within a foreign chroot.

Setting severity to be "important" since a) the thing is
clearly wrong and b) I really want to remove qemu binary
package from the archive for a long time already and this
Recommends doesn't let me do that.

Thanks!

Bug#992975: Acknowledgement (Does not work on bullseye)

2021-08-25 Thread Enrico Zini

Severity: normal

Hello,

update/correction: the plugin still works with the usual
vim-addon-manager


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini

Bug#914128: perl: usrmerge issues

2021-08-25 Thread Niko Tyni

On Tue, Aug 24, 2021 at 09:55:38PM +0300, Niko Tyni wrote:
> On Thu, Jul 15, 2021 at 04:36:10PM -0700, Vagrant Cascadian wrote:

> > Attached patch also fixes these issues, by adjusting libpth and libspath
> > in debian/config.over ... it feels a little hackish ... but ...
> 
> Yeah. The "pristine" probed values of libpth and libspath on a
> non-usrmerged system look messy enough (/lib/../lib and the like) that
> it might be more robust to just override them to some cleaner hardcoded
> values rather than have more logic that tries to imitate the mess on
> usrmerged systems. But I'll see how that works out.

For the record, I came up with a cleaner fix (calling realpath with
--no-symlinks in libpth.U). It's specific to 5.34 which has changes
in that unit, so I expect I won't be fixing this in the 5.32 series.

Will upload the 5.34 fixes to experimental this weekend or so.

Thanks again,
-- 
Niko

Bug#992975: Does not work on bullseye

2021-08-25 Thread Enrico Zini

Package: vim-syntastic
Version: 3.10.0-2
Severity: serious

Hello,

the upgrade instructions for bullseye say:

  * Before upgrading, run "vam remove " for any addon in this package
that has been installed with "vam install ".  Adjust the command
as necessary for system-wide installed addon.
  * After upgrading, add "packadd! " to your vimrc for any addon that
you want to use.  The addon name can be found in the package description
or the list of directories under /usr/share/vim-scripts.

However, when I add `packadd! syntastic` in .vimrc, I get this error:

   E919: Directory not found in 'packpath': "pack/*/opt/syntastic"

Using packadd! on, say, nerd-commenter (distributed by vim-scripts)
works fine. It looks like vim-syntastic missed the update that
vim-scripts had.

/usr/share/doc/vim-syntastic/README.Debian doesn't mention anything
relevant (and there's a typo where it says "pathogen" instead of
"syntastic").

Unfortunately I don't know anything about vim plugin packaging and I
can't be much of use, besides reporting the issue :(


Enrico


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

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

Versions of packages vim-syntastic depends on:
ii  vim2:8.2.2434-3
ii  vim-addon-manager  0.5.10

vim-syntastic recommends no packages.

Versions of packages vim-syntastic suggests:
pn  checkstyle   
pn  chktex   
pn  closure-linter   
ii  cppcheck 2.3-1
pn  foodcritic   
pn  hlint
pn  lacheck  
pn  libperl-critic-perl  
ii  libxml2-utils2.9.10+dfsg-6.7
pn  pep8 
pn  puppet-lint  
pn  pyflakes 
ii  pylint   2.7.2-3
pn  python-flake8
pn  shellcheck   
pn  sparse   
pn  splint   
ii  tidy 2:5.6.0-11

-- no debconf information

Bug#992974: exim4-config: permit to include local file in acl_check_mail

2021-08-25 Thread Noury

Package: exim4-config
Version: 4.94.2-7
Severity: normal
Tags: patch

Can you please add the following lines in 
/etc/exim4/conf.d/acl/30_exim4-config_check_mail

  .ifdef CHECK_MAIL_LOCAL_ACL_FILE
  .include CHECK_MAIL_LOCAL_ACL_FILE
  .endif

This can be necessary, even if documentation says it's not.


-- Package-specific info:
Exim version 4.94.2 #2 built 22-Aug-2021 16:16:25
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event I18N OCSP 
PIPE_CONNECT PRDR PROXY SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to replace
# the DEBCONFsomethingDEBCONF strings in the configuration template files.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='internet'
dc_other_hostnames='colibri.dagami.org : colibri : dagami.org : dagami.tk : 
sncli.cf'
dc_local_interfaces=''
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
# liste des adresses pour lesquelles on accepte d'envoyer les mails sans 
login/password (adresses fiables) Attention, ne pas mettre 192.168.0.x (réseau 
local freebox), on peut venir avec
# 82.124.98.221 = fibre orange
#dc_relay_nets='127.0.0.1;::1;[2a01:cb00:e2:1c00::]/56;172.245.226.185/32;23.95.164.22/32;[::1];90.91.177.143/32;86.242.104.180/32;'
dc_relay_nets='2a01::cb00::e2::1c00/56 : 172.245.226.185/32 : 
23.95.164.22/32 : 90.91.177.143/32 : 86.242.104.180/32'
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='dovecot_vmail'
mailname:colibri.dagami.org
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on
# port 25 only. To listen on more ports, it is recommended to use
# -oX 25:587:10025 -oP /var/run/exim4/exim.pid
SMTPLISTENEROPTIONS=''

-- 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/3 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.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 exim4-config depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.77

Versions of packages exim4-config recommends:
ii  ca-certificates  20210119

exim4-config suggests no packages.

-- Configuration Files:
/etc/exim4/conf.d/acl/30_exim4-config_check_mail changed [not included]
/etc/exim4/exim4.conf.template changed [not included] -> but using split mode
/etc/exim4/passwd.client [Errno 13] Permission non accordée: 
'/etc/exim4/passwd.client'

-- debconf information excluded

Bug#949020: linux-image-5.6.0-2-amd64: Lenovo poweroff/suspend failure

2021-08-25 Thread Faustin Lammler

Hi!

I have the exact same problem on a fresh Debian 11 installation and a
T460s laptop.

Changing TPM from 2.0 to 1.2 in the BIOS resolves the poweroff and the
suspend issue.

Also FYI (not sure if that helps), as I did not found 949020 earlier, I
have used the following workaround on Buster + 5.10 bpo kernel
(hibernating just after booting to then be able to suspend until next
reboot):
| echo reboot >/sys/power/disk
| echo disk >/sys/power/state

As far as I can remember, I did not had the poweroff problem on Buster,
just suspend.

-- 
Faustin


signature.asc
Description: PGP signature

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

On 8/25/2021 10:54 AM, Ben Hutchings wrote:

On Tue, 2021-08-24 at 15:19 -0400, Chuck Zmudzinski wrote:

On 8/24/2021 1:12 PM, Ben Hutchings wrote:

[...]

I think a proper fix would be one of:

a. If the Xen virtual keyboard driver is advertising capabilities it
doesn't have, stop it doing that.
b. Change the implementation of modalias attributes to allow longer
values.

It's not clear to me whether the Xen driver is advertising correctly or
not. If it is, then the solution should be b, but that may be too
disruptive a change to the kernel. So a reasonable workaround might
be:

c. Change the input subsystem to limit the length of the
capabilities part of the modalias.

Ben.

So workaround c would not involve disruptions to the kernel or
systemd? Workaround c seems too disruptive for stable to me,
but maybe could go into unstable and eventually into testing.

I don't think it would be very disruptive. It might require a kernel
ABI bump, but we do those regularly during a stable release. And this
bug is severe enough that I think a fix would be suitable for Debian
stable.

A problem with the approach of fixing this bug in the Xen
keyboard driver is that the fix must be implemented in the underlying
Dom0 system, which could be almost anything - another Linux distro
or Debian stable or oldstable. Any fix upstream would probably get into
a bullseye Dom0, but not oldstable Dom0, but perhaps it could be
provided as a backport for anyone who is still on oldstable for their
Xen Dom0.

[...]

I agree that we need to fix this for domU independently of any protocol
change to allow discovery of which keys the underlying input device
has. So we can't solve this with approach a.

Ben.

Actually, now I think my comments about approach a are wrong. I was thinking
the Linux kernel was reading the modalias of the Xen Virtual Keyboard from
through some interface provided by xen - the hypervisor or libxl or some
such component running in Dom0. After further investigation, now I think the
modalias of the Xen Virtual Keyboard is coming from here:

https://github.com/torvalds/linux/blob/6e764bcd1cf72a2846c0e53d3975a09b242c04c9/drivers/input/misc/xen-kbdfront.c#L257

This is the xen-kbdfront.c driver, which is part of the Linux kernel.

At line 257 of that driver, we have:

for (i = KEY_ESC; i < KEY_UNKNOWN; i++)
__set_bit(i, kbd->keybit);
for (i = KEY_OK; i < KEY_MAX; i++)
__set_bit(i, kbd->keybit);

This is advertising too many keys, making the modalias absurdly large.
The Xen virtual keyboard driver in the Linux kernel has been doing
this at least since 2011 when to Xen virtual keyboard driver was
moved to its current location in the Linux kernel source tree.

So this can probably be fixed in the Linux kernel without any patches
to the Xen hypervisor or libxl running in Dom0. Probably just
removing those two for loops would fix it.

Chuck

Bug#990868: lenovo T460 Shutdown Problem

2021-08-25 Thread Faustin Lammler

Hi Bjørn!

Bjørn Mork ,
25/08/2021 – 20:12:09 (+0200):

> This sounds like https://bugs.debian.org/949020
Yes, exactly! I remember searching a lot when it happened to me last
year, but not sufficiently apparently...

> Short version: Disable TPM 2.0 (select 1.2) i BIOS, or disable IOMMU by
> booting with intel_iommu=off on the command line.

Switching to TPM 1.2 works perfectly, I did not tried the
intel_iommu=off workaround so far...

Thanks again!

-- 
Faustin


signature.asc
Description: PGP signature

Bug#992973: plib: CVE-2021-38714

2021-08-25 Thread Salvatore Bonaccorso

Source: plib
Version: 1.8.5-8
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://sourceforge.net/p/plib/bugs/55/
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for plib.

CVE-2021-38714[0]:
| In Plib through 1.85, there is an integer overflow vulnerability that
| could result in arbitrary code execution. The vulnerability is found
| in ssgLoadTGA() function in src/ssg/ssgLoadTGA.cxx file.

The severity of the this bug is set op purpose higher as it is
probably warranted. There is the following reason for that: plib is
orphaned in Debian for a while, it is obsoleted and unmaintained
upstream as well. Ideally it get's removed from Debian from the next
release, but thee would be some revers dependencies issues to be
solved, making it imposssible for now to remove the package:

| Checking reverse dependencies...
| # Broken Depends:
| crrcsim: crrcsim [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x]
| flightgear: flightgear
| openuniverse: openuniverse
| stormbaancoureur: stormbaancoureur
| torcs: torcs
| 
| # Broken Build-Depends:
| crrcsim: libplib-dev
| flightgear: libplib-dev
| torcs: libplib-dev
| 
| Dependency problem found.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-38714
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-38714
[1] https://sourceforge.net/p/plib/bugs/55/

Regards,
Salvatore

Bug#968078: gcompris-qt: no images displayed without libqt5svg5

2021-08-25 Thread Julien Palard

I reproduced it a few weeks ago on mobian bullseye (which uses Debian
repositories directly) and gcompris-qt 1.0.1:

- https://invent.kde.org/education/gcompris/-/issues/35
- https://gitlab.com/mobian1/issues/-/issues/348#note_653778823

--
[Julien Palard](https://mdk.fr)

Bug#992971: grilo: CVE-2021-39365

2021-08-25 Thread Salvatore Bonaccorso

Source: grilo
Version: 0.3.13-1
Severity: important
Tags: security upstream
Forwarded: https://gitlab.gnome.org/GNOME/grilo/-/issues/146
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 0.3.7-1

Hi,

The following vulnerability was published for grilo.

CVE-2021-39365[0]:
| In GNOME grilo though 0.3.13, grl-net-wc.c does not enable TLS
| certificate verification on the SoupSessionAsync objects it creates,
| leaving users vulnerable to network MITM attacks. NOTE: this is
| similar to CVE-2016-20011.


If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2021-39365
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-39365
[1] https://gitlab.gnome.org/GNOME/grilo/-/issues/146

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#976235: enlightenment: e switches off screen|monitor

2021-08-25 Thread Ross Vandegrift

Hi enno,

On Tue, Aug 24, 2021 at 11:02:24PM +0200, enno wrote:
> NEW: If I do nothing, screen stays black for quite precisely 30 seconds, no 
> matter if on VT7 or VT1-6, then screen comes back.  If in TTY1-6 it stays, if 
> in VT7 as soon as I press a key or click a mouse it turns black again.  But 
> then sometimes also VT1-6 turn black again, apparently without my influence.
> 
> And in .xsession-errors--where I redirect console output, there's:

Sorry, I still don't think I have any idea what's going on.  You're best
off contacting upstream at enlightenment-us...@lists.sf.net or #e on
libera.chat.

Ross

Bug#992877: RFS: alberta/3.0.3-1 -- adaptive finite element library (library)

2021-08-25 Thread Adam Borowski

On Tue, Aug 24, 2021 at 07:08:32PM +0200, Adam Borowski wrote:
> On Tue, Aug 24, 2021 at 04:49:07PM +0200, Lisa Julia Nebel wrote:
> > alberta (3.0.3-1) experimental; urgency=medium

> I'm afraid it fails to build with the toolchain in experimental, failing
> with:
> checking for rpc/types.h... no
> configure: error: Sorry, rpc/types.h is needed.
> 
> This is pretty puzzling as that header comes from libc6-dev, which suggests
> something is terribad with the build system.

Actually, glibc has dropped ancient rpc -- and in anticipation of upgrade to
glibc 32 or 34, there's been an upload of 31 to experimental and now
unstable that drops this header.


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

Bug#992956: bullseye-pu: package modsecurity-crs/3.3.0-1

2021-08-25 Thread Alberto Gonzalez Iniesta

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

Hi, (again, see #992863)

This [1] security bug was found in modsecurity-crs.
As stated in #992863 by the security team, a DSA won't be issued
(security team on Cc:) so I'm targeting bullseye proposed updates
instead.

Here's the debdiff. Hope it's all OK.

I'll wait for your instructions before uploading.

Cheers,

Alberto


[1] https://coreruleset.org/20210630/cve-2021-35368-crs-request-body-bypass/
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992000
-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55
diff -Nru modsecurity-crs-3.3.0/debian/changelog 
modsecurity-crs-3.3.0/debian/changelog
--- modsecurity-crs-3.3.0/debian/changelog  2020-08-16 20:24:09.0 
+0200
+++ modsecurity-crs-3.3.0/debian/changelog  2021-08-24 17:40:57.0 
+0200
@@ -1,3 +1,10 @@
+modsecurity-crs (3.3.0-1+deb11u1) bullseye; urgency=medium
+
+  * Add upstream patch to fix request body bypass
+CVE-2021-35368 (Closes: #992000)
+
+ -- Alberto Gonzalez Iniesta   Tue, 24 Aug 2021 17:40:57 
+0200
+
 modsecurity-crs (3.3.0-1) unstable; urgency=medium
 
   * New upstream version 3.3.0
diff -Nru modsecurity-crs-3.3.0/debian/patches/CVE-2021-35368.patch 
modsecurity-crs-3.3.0/debian/patches/CVE-2021-35368.patch
--- modsecurity-crs-3.3.0/debian/patches/CVE-2021-35368.patch   1970-01-01 
01:00:00.0 +0100
+++ modsecurity-crs-3.3.0/debian/patches/CVE-2021-35368.patch   2021-08-24 
17:40:57.0 +0200
@@ -0,0 +1,136 @@
+From b05cd8569862ee9599edd153a09cbbca2c74600a Mon Sep 17 00:00:00 2001
+From: Walter Hop 
+Date: Wed, 30 Jun 2021 12:37:56 +0200
+Subject: [PATCH] Fix CVE-2021-35368 WAF bypass using pathinfo (Christian 
Folini)
+
+---
+diff --git a/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf 
b/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
+index f29ab3e1..2e5ce88f 100644
+--- a/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
 b/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
+@@ -64,6 +64,15 @@
+ 
+ SecRule :crs_exclusions_drupal|TX:crs_exclusions_drupal "@eq 0" \
+ "id:9001000,\
++phase:1,\
++pass,\
++t:none,\
++nolog,\
++ver:'OWASP_CRS/3.3.0',\
++skipAfter:END-DRUPAL-RULE-EXCLUSIONS"
++
++SecRule :crs_exclusions_drupal|TX:crs_exclusions_drupal "@eq 0" \
++"id:9001001,\
+ phase:2,\
+ pass,\
+ t:none,\
+@@ -267,55 +276,60 @@ SecRule REQUEST_FILENAME "@endsWith 
/admin/config/content/formats/manage/full_ht
+ #
+ # Extensive checks make sure these uploads are really legitimate.
+ #
+-SecRule REQUEST_METHOD "@streq POST" \
+-"id:9001180,\
+-phase:1,\
+-pass,\
+-t:none,\
+-nolog,\
+-noauditlog,\
+-ver:'OWASP_CRS/3.3.0',\
+-chain"
+-SecRule REQUEST_FILENAME "@rx /admin/content/assets/add/[a-z]+$" \
+-"chain"
+-SecRule REQUEST_COOKIES:/S?SESS[a-f0-9]+/ "@rx ^[a-zA-Z0-9_-]+" \
+-"ctl:requestBodyAccess=Off"
+-
+-SecRule REQUEST_METHOD "@streq POST" \
+-"id:9001182,\
+-phase:1,\
+-pass,\
+-t:none,\
+-nolog,\
+-noauditlog,\
+-ver:'OWASP_CRS/3.3.0',\
+-chain"
+-SecRule REQUEST_FILENAME "@rx /admin/content/assets/manage/[0-9]+$" \
+-"chain"
+-SecRule ARGS:destination "@streq admin/content/assets" \
+-"chain"
+-SecRule REQUEST_HEADERS:Content-Length "@gt 31486341" \
+-"chain"
+-SecRule REQUEST_COOKIES:/S?SESS[a-f0-9]+/ "@rx 
^[a-zA-Z0-9_-]+" \
+-"ctl:requestBodyAccess=Off"
+-
+-SecRule REQUEST_METHOD "@streq POST" \
+-"id:9001184,\
+-phase:1,\
+-pass,\
+-t:none,\
+-nolog,\
+-noauditlog,\
+-ver:'OWASP_CRS/3.3.0',\
+-chain"
+-SecRule REQUEST_FILENAME "@rx 
/file/ajax/field_asset_[a-z0-9_]+/[ua]nd/0/form-[a-z0-9A-Z_-]+$" \
+-"chain"
+-SecRule REQUEST_HEADERS:Content-Length "@gt 31486341" \
+-"chain"
+-SecRule REQUEST_HEADERS:Content-Type "@rx 
^(?i)multipart/form-data" \
+-"chain"
+-SecRule REQUEST_COOKIES:/S?SESS[a-f0-9]+/ "@rx 
^[a-zA-Z0-9_-]+" \
+-"ctl:requestBodyAccess=Off"
++# Rule 9001180 was commented out in 2021 in order to fight CVE-2021-35368.
++#
++#SecRule REQUEST_METHOD "@streq POST" \
++#"id:9001180,\
++#phase:1,\
++#pass,\ +#t:none,\
++#nolog,\
++#noauditlog,\
++#ver:'OWASP_CRS/3.3.0',\
++#chain"
++#SecRule REQUEST_FILENAME "@rx /admin/content/assets/add/[a-z]+$" \
++#"chain"
++#SecRule REQUEST_COOKIES:/S?SESS[a-f0-9]+/ "@rx ^[a-zA-Z0-9_-]+" \
++#"ctl:requestBodyAccess=Off"
++
++# Rule 9001182 was commented out in 2021 in order to fight

Bug#959155: shotwell: please provide a version of shotwell without webkit

2021-08-25 Thread Jörg Frings-Fürst

Hello,


Am Donnerstag, dem 30.04.2020 um 00:04 -0300 schrieb Rogério Brito:
> Package: shotwell
> Version: 0.30.8-1
> Severity: wishlist
> 
> Hi.
> 
> It would be great to have a leaner version of shotwell without webkit
> (and,
> more generally, without the "social" features of sharing photos on
> "social
> websites").
> 

this is an idea for further development. I ask you to discuss this
directly with the developer. 

Just open a new issue on [1].


[1] 
https://gitlab.gnome.org/GNOME/shotwell/-/issues/new?issue%5Bmilestone_id%5D=

> 
> Thanks in advance,
> 
> Rogério Brito.
> [...]

CU
Jörg

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

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

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


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

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


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



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

Bug#969773: timeshift: runs deprecated gvfs-trash utility

Control: reopen -1
Control: found -1 20.03+ds-2
Control: fixed -1 20.11.1-1
Control: fixed -1 20.11.1-1~bpo10+1
Control: close -1

Hi,

在 2021-08-25星期三的 19:28 +0100，Simon McVittie写道：
> On Wed, 25 Aug 2021 at 18:06:03 +, Debian Bug Tracking System forwarded:
> > This bug is fixed since timeshift/20.03+ds-3.
> 
> That version doesn't seem to have ever been in Debian. If it's fixed in
> 20.11.1-1, please close it as fixed in 20.11.1-1.
> 
>     smcv

Thanks for the info. I checked the packaging history and it's indeed the case.
Now adjusting the version string accordingly.

Thanks,
Boyuan Yang


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

Bug#969773: timeshift: runs deprecated gvfs-trash utility

2021-08-25 Thread Simon McVittie

On Wed, 25 Aug 2021 at 18:06:03 +, Debian Bug Tracking System forwarded:
> This bug is fixed since timeshift/20.03+ds-3.

That version doesn't seem to have ever been in Debian. If it's fixed in
20.11.1-1, please close it as fixed in 20.11.1-1.

smcv

Bug#992970: transition: wbxml2

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-scie...@lists.debian.org ti...@debian.org
Forwarded: https://release.debian.org/transitions/html/auto-wbxml2.html

Dear Release Team,

I am looking into starting the transition as shown on
https://release.debian.org/transitions/html/auto-wbxml2.html . The transition
is caused by upstream's SONAME bump in the new release.

For package wbxml2, the only reverse dependency is virtuoso-opensource. I have
tested that the build for virtuoso-opensource is ok with wbxml2 from
experimental.

Example Ben file (the one currently from auto-wbxml2 should be enough):

title = "wbxml2";
is_affected = .depends ~ "libwbxml2-0" | .depends ~ "libwbxml2-1";
is_good = .depends ~ "libwbxml2-1";
is_bad = .depends ~ "libwbxml2-0";


Thanks,
Boyuan Yang


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

Bug#990868: lenovo T460 Shutdown Problem

2021-08-25 Thread Bjørn Mork

Faustin Lammler  writes:

> Hi!
> I seem to have the same problem on my T460s and it is impossible to
> suspend the laptop (lid close or systemctl suspend).
>
> As far as I can remember, the problem appeared with kernel 5 branch (bpo
> on buster).
>
> At that time I did not wanted to open a bug report because I was not
> sure of my installation (dist-upgrade from buster, plus lots of bpo
> kernel installation and test) and I had found a workaround for the
> suspend problem, using those commands after reboot:
> | echo reboot >/sys/power/disk
> | echo disk >/sys/power/state
>
> Now I have a clean Debian 11 installation and both suspend and poweroff
> does not work anymore.

This sounds like https://bugs.debian.org/949020

Short version: Disable TPM 2.0 (select 1.2) i BIOS, or disable IOMMU by
booting with intel_iommu=off on the command line.


Bjørn

Bug#992969: fix_ldscript doesn't fix the path to the ld-linux.so file

2021-08-25 Thread Matthias Klose

Package: dpkg-cross
Version: 2.6.18+nmu1
Severity: important

seen when trying to convert every non-default 32bit multilib libc-dev-* package.

$ cat /usr/powerpc64-linux-gnu/lib32/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-powerpc)
GROUP ( /usr/powerpc64-linux-gnu/lib32/libc.so.6
/usr/powerpc64-linux-gnu/lib32/libc_nonshared.a  AS_NEEDED (
/usr/powerpc64-linux-gnu/lib/ld.so.1 ) )


$ cat /usr/x86_64-linux-gnux32/lib32/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /usr/x86_64-linux-gnux32/lib32/libc.so.6
/usr/x86_64-linux-gnux32/lib32/libc_nonshared.a  AS_NEEDED (
/usr/x86_64-linux-gnux32/lib/ld-linux.so.2 ) )


while the paths to the shared and static libc libs is correctly converted, the
path to the ld-linux.so.2 points to the default (64bit) ld-linux.so.

working around this in the cross-toolchain-base packages.

Bug#992966: simple-cdd: fails to validate Release file with a good signature and a signature that can't be checked

2021-08-25 Thread Raphael Hertzog

Control: severity -1 important

Bumping the severity on suggestion of #debian-release.

On Wed, 25 Aug 2021, Raphaël Hertzog wrote:
> Right now if you try to use simple-cdd on a stretch or buster system (to
> build stretch/buster images), you get failures like this one:

I was a bit to quick in my assertion. The problem is limited to stretch
because buster's debian-archive-keyring has been updated a while ago (but
my buster chroot was not up-to-date):
https://tracker.debian.org/news/1236764/accepted-debian-archive-keyring-20191deb10u1-source-all-into-proposed-updates-stable-new-proposed-updates/

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com

Bug#992921: timeshift: util-linux 2.37.2-1 breaks timeshift

Control: severity -1 grave
Control: tags -1 +bookworm +sid

On Wed, 25 Aug 2021 08:36:27 +0200 martijn markies
 wrote:
> Package: timeshift
> Version: 20.11.1-1
> Severity: important
> X-Debbugs-Cc: rubenswa...@protonmail.com
> 
> Dear Maintainer,
> 
> Using the patch from kdmurthy in this thread
https://github.com/teejee2008/timeshift/issues/753 fixed the problem for me.
> 
> *** Reporter, please consider answering these questions, where appropriate
***
> 
>    * What led up to the situation?
>    * What exactly did you do (or not do) that was effective (or
>  ineffective)?
>    * What was the outcome of this action?
>    * What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: 11.0
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'oldstable-updates'), (500,
'unstable'), (500, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> Versions of packages timeshift depends on:
> ii  libc6    2.31-13
> ii  libcairo2    1.16.0-5
> ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
> ii  libgee-0.8-2 0.20.4-1
> ii  libglib2.0-0 2.68.4-1
> ii  libgtk-3-0   3.24.30-1
> ii  libjson-glib-1.0-0   1.6.2-1
> ii  libvte-2.91-0    0.62.3-1
> ii  psmisc   23.4-2
> ii  rsync    3.2.3-4
> 
> timeshift recommends no packages.
> 
> timeshift suggests no packages.
> 
> -- no debconf information
> 
> 



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

Bug#992925: pavucontrol: Please bump libpulse-dev build-dependency to >= 15

2021-08-25 Thread Tomas Janousek


Hi,

On Wed, Aug 25, 2021 at 09:39:42AM +0200, Laurent Bigonville wrote:

Could you please bump libpulse-dev build-dependency to >= 15 so we are
sure that pa_context_send_message_to_object() exists on all
architectures?

pa_context_send_message_to_object() is needed at build time to enable
the new configuration widget to switch the codec used by bluetooth
headsets (I was actually waiting for this feature)


Just wanted to clarify a bit: the most common architecture—amd64—is 
affected too. pavucontrol 5.0-1 lacks the codec switching and profile 
locking features here.


Fortunately pulseaudio 15 is now in unstable, so the dep bump should be 
all right.


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

Bug#992968: xarchiver FTBFS: configure: error: cannot find required auxiliary files: compile

2021-08-25 Thread Helmut Grohne

Source: xarchiver
Version: 1:0.5.4.17-2
Severity: serious
Tags: ftbfs

xarchiver fails to build from source in unstable, because configure
misses a compile file. The build ends with:

| dh_auto_configure -- --libexecdir=/usr/lib
|   ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --libexecdir=/usr/lib
| configure: error: cannot find required auxiliary files: compile
|   tail -v -n \+0 config.log
| ==> config.log <==
| ...
| configure: exit 1
| dh_auto_configure: error: ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-option-checking --disable-silent-rules 
--libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run 
--disable-maintainer-mode --disable-dependency-tracking --libexecdir=/usr/lib 
returned exit code 1
| make[1]: *** [debian/rules:9: override_dh_auto_configure] Error 25
| make[1]: Leaving directory '/build/1st/xarchiver-0.5.4.17'
| make: *** [debian/rules:5: build] Error 2
| dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2

Also reproduced by reproducible builds:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/xarchiver_0.5.4.17-2.rbuild.log.gz

Helmut

Bug#992966: simple-cdd: fails to validate Release file with a good signature and a signature that can't be checked

2021-08-25 Thread Raphaël Hertzog

Package: simple-cdd
Version: 0.6.8
Severity: normal
X-Debbugs-Cc: raph...@freexian.com

Right now if you try to use simple-cdd on a stretch or buster system (to
build stretch/buster images), you get failures like this one:

> 2021-08-24 10:45:08 ERROR verify gpg signature exited with code 2
> 2021-08-24 10:45:08 ERROR Last 3 lines of standard error:
> 2021-08-24 10:45:08 ERROR verify gpg signature: gpg: Signature made Tue 24 
> Aug 2021 09:21:34 AM CDT
> 2021-08-24 10:45:08 ERROR verify gpg signature: gpg:using RSA 
> key A7236886F3CCCAAD148A27F80E98404D386FA1D9
> 2021-08-24 10:45:08 ERROR verify gpg signature: gpg: Can't check signature: 
> No public key
> 2021-08-24 10:45:08 ERROR Signature verification failed on ['gpg', '--batch', 
> '--no-default-keyring', '--keyring', 
> '/usr/share/keyrings/debian-archive-keyring.gpg', '--keyring', 
> '/srv/install/simple-cdd/.gnupg/pubring.gpg', '--verify', 
> '/srv/install/simple-cdd/tmp/mirror/extrafiles']
> FAILURE:  build-simple-cdd failed, exiting

The problem is that the Release file (and the extrafiles) of stretch and
buster is signed by 4 keys, including the recently added keys for
bullseye. But /usr/share/keyrings/debian-archive-keyring.gpg in
stretch/buster does not (yet) contain the new key and simple-cdd uses `gpg
--verify` which fails with error code 2 as soon as a single signature
can't be verified.

But simple-cdd should fail only if none of the signatures can't be
verified or if some signature fails to verify while the key is present
(a bit like APT does it...). But the absence of a key should not result in
a failure provided that the other signatures are working.

Elements of proof:

$ wget http://debian.backend.mirrors.debian.org/debian/dists/stretch/Release
$ wget http://debian.backend.mirrors.debian.org/debian/dists/stretch/Release.gpg
$ LANG=C gpg --keyring 
/srv/chroots/buster-amd64/usr/share/keyrings/debian-archive-keyring.gpg 
--verify Release.gpg Release
gpg: Signature made Sat Aug 14 09:43:24 2021 CEST
gpg:using RSA key 16E90B3FDF65EDE3AA7F323C04EE7237B7D453EC
gpg: Good signature from "Debian Archive Automatic Signing Key (9/stretch) 
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: E1CF 20DD FFE4 B89E 8026  58F1 E0B1 1894 F66A EC98
 Subkey fingerprint: 16E9 0B3F DF65 EDE3 AA7F  323C 04EE 7237 B7D4 53EC
gpg: Signature made Sat Aug 14 09:43:25 2021 CEST
gpg:using RSA key 0146DC6D4A0B2914BDED34DB648ACFD622F3D138
gpg: Good signature from "Debian Archive Automatic Signing Key (10/buster) 
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 80D1 5823 B7FD 1561 F9F7  BCDD DC30 D7C2 3CBB ABEE
 Subkey fingerprint: 0146 DC6D 4A0B 2914 BDED  34DB 648A CFD6 22F3 D138
gpg: Signature made Sat Aug 14 10:46:19 2021 CEST
gpg:using RSA key A7236886F3CCCAAD148A27F80E98404D386FA1D9
gpg: Can't check signature: No public key
gpg: Signature made Sat Aug 14 10:26:43 2021 CEST
gpg:using RSA key 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500
gpg:issuer "debian-rele...@lists.debian.org"
gpg: Good signature from "Debian Stable Release Key (9/stretch) 
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the owner.
Primary key fingerprint: 067E 3C45 6BAE 240A CEE8  8F6F EF0F 382A 1A7B 6500
$ echo $?
2
$ LANG=C gpg --keyring 
/srv/chroots/buster-amd64/usr/share/keyrings/debian-archive-keyring.gpg 
--with-subkey-fingerprints --list-keys A7236886F3CCCAAD148A27F80E98404D386FA1D9
gpg: error reading key: No public key
$ LANG=C gpg --keyring /usr/share/keyrings/debian-archive-keyring.gpg 
--with-subkey-fingerprints --list-keys A7236886F3CCCAAD148A27F80E98404D386FA1D9
pub   rsa4096 2021-01-17 [SC] [expires: 2029-01-15]
  1F89983E0081FDE018F3CC9673A4F27B8DD47936
uid   [ unknown] Debian Archive Automatic Signing Key (11/bullseye) 

sub   rsa4096 2021-01-17 [S] [expires: 2029-01-15]
  A7236886F3CCCAAD148A27F80E98404D386FA1D9



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

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

Versions of packages simple-cdd depends on:
ii  dctrl-tools 2.24-3+b1
ii  debian-cd   3.1.35
ii  lsb-release 11.1.0
ii  python3 3.9.2-3
ii  python3-simple-cdd  0.6.8
ii  reprepro

Bug#992965: ITP: gn -- meta-build system that generates build files for Ninja

X-Debbugs-Cc: debian-de...@lists.debian.org chrom...@packages.debian.org

在 2021-08-25星期三的 19:12 +0200，Romain Porte写道：
> Package: wnpp
> Severity: wishlist
> Owner: Romain Porte 
> X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org, Debian
> Chromium Team 
> 
> * Package name    : gn
>   Version : 0+git20210811
>   Upstream Author : Google
> * URL : https://gn.googlesource.com/gn/
> * License : BSD-3-Clause
>   Programming Lang: Python
>   Description : meta-build system that generates build files for Ninja
> 
> This package is introduced as a dependency for some Google software
> related to Chromium. It can also replace the `gn` copy currently
> embedded in the Chromium source package.
> 
> I intent to publish this package under the umbrella of the Debian
> Chromium team.

https://tracker.debian.org/pkg/generate-ninja

Thanks,
Boyuan Yang


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

Bug#992965: ITP: gn -- meta-build system that generates build files for Ninja

2021-08-25 Thread Romain Porte

Package: wnpp
Severity: wishlist
Owner: Romain Porte 
X-Debbugs-Cc: debian-de...@lists.debian.org, deb...@microjoe.org, Debian 
Chromium Team 

* Package name: gn
  Version : 0+git20210811
  Upstream Author : Google
* URL : https://gn.googlesource.com/gn/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : meta-build system that generates build files for Ninja

This package is introduced as a dependency for some Google software
related to Chromium. It can also replace the `gn` copy currently
embedded in the Chromium source package.

I intent to publish this package under the umbrella of the Debian
Chromium team.

Bug#990246: vlc: reproducible builds: Embeds build username and hostname in binaries

2021-08-25 Thread Vagrant Cascadian

On 2021-08-25, Sebastian Ramacher wrote:
> On 2021-06-23 13:16:47, Vagrant Cascadian wrote:
>> The build username and build system hostname are embedded in binaries
>> shipped in vlc:
>> 
>>   
>> https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/amd64/diffoscope-results/vlc.html
>> 
>>   ./usr/lib/x86_64-linux-gnu/libvlccore.so.9.0.0 
>> 
>>   pbuilder1
>>   vs.
>>   pbuilder2
>> 
>>   ionos11-amd64
>>   vs.
>>   i-capture-the-hostname
>> 
>> The attached patch fixes this by setting VLC_COMPILE_BY and
>> VLC_COMPILE_HOST to empty values in configure.ac.
>
> NACK. This information is part of the logs that are usually requested
> from users by upstream. We want to have this information included in the
> log so that upstream can easily identify where the logs are coming from
> and what they are using. And for that purpose, a self-built deb or one
> from a downstream distribution is different from the Debian one.

The username and hostname of the build seems a rather imprecise way to
find out information about the origin of the build...

In the context of Debian, a given package+version has specific build
logs associated with it findable at https://buildd.debian.org/PACKAGE

I would expect downstream projects to have something similar
(e.g. ubuntu).

Obviously that wouldn't help for a self-built deb, but I would think the
person who built the deb would already have that information (and
ideally share that information with upstream)...

Thanks for considering. Perhaps it will be best to take this upstream at
this point, anyways...


live well,
  vagrant


>> This patch does not address all reproducibility issues in vlc
>> (e.g. build paths), though applying it reduces the diff for the
>> remaining issues.
>> 
>> 
>> Thanks for maintaining vlc!
>> 
>> 
>> live well,
>>   vagrant
>
>> From 01e2dcc51b31f1a06bcd07faa0ae3fbd0ddbe9c6 Mon Sep 17 00:00:00 2001
>> From: Vagrant Cascadian 
>> Date: Wed, 23 Jun 2021 19:33:47 +
>> Subject: [PATCH 1/3] Disable embedding the build hostname and username in the
>>  binaries.
>> 
>> https://tests.reproducible-builds.org/debian/issues/user_hostname_manually_added_requiring_further_investigation_issue.html
>> ---
>>  configure.ac | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/configure.ac b/configure.ac
>> index 7db5256a8..5d6324cf9 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -4324,8 +4324,8 @@ AC_SUBST(VERSION_MINOR)
>>  AC_SUBST(VERSION_REVISION)
>>  AC_SUBST(VERSION_EXTRA)
>>  AC_SUBST(COPYRIGHT_YEARS)
>> -AC_DEFINE_UNQUOTED(VLC_COMPILE_BY, "`whoami|sed -e 's/\\\/\\\/g'`", 
>> [user who ran configure])
>> -AC_DEFINE_UNQUOTED(VLC_COMPILE_HOST, "`hostname -f 2>/dev/null || 
>> hostname`", [host which ran configure])
>> +AC_DEFINE_UNQUOTED(VLC_COMPILE_BY, "", [user who ran configure])
>> +AC_DEFINE_UNQUOTED(VLC_COMPILE_HOST, "", [host which ran configure])
>>  AC_DEFINE_UNQUOTED(VLC_COMPILER, "`$CC -v 2>&1 | tail -n 1 | sed -e 's/ 
>> *$//'`", [compiler])
>>  dnl
>>  dnl  Handle substvars that use $(top_srcdir)
>> -- 
>> 2.32.0


signature.asc
Description: PGP signature

Bug#992800: [Pkg-puppet-devel] Bug#992800: puppet agent breaks after upgrade to bullseye on arm architecture

2021-08-25 Thread Thomas Goirand

On 8/24/21 8:39 AM, stoeni wrote:
> Am 24.08.2021 um 00:34 schrieb Thomas Goirand:
>> On 8/23/21 5:40 PM, stoeni wrote:
>>> Package: puppet
>>> Version: 5.5.22-2
>>> Severity: normal
>>> X-Debbugs-Cc: none
>>>
>>> After upgrading some Raspberry Pi (Zero, Model3/4) from buster to
>>> bullseye, the puppet client no longer works on this architecture.
>>>
>>> Steps to reproduce this error:
>>>
>>> - install rasbian buster on a Raspberry Pi
>>> - upgrade to bullseye
>>> - run e.g. "puppet agent"
>>>
>>> running puppet without arguments works:
>>>
>>> --<8--
>>> root@moon:~# puppet
>>> See 'puppet help' for help on available puppet subcommands
>>> -->8--
>>>
>>> running puppet with arguments aborts:
>>>
>>> --<8--
>>> root@moon:~# puppet help
>>> Aborted
>>> -->8--
>>>
>>> puppet 5.5.10 runs well on buster with amd64 or arm architecture, 5.5.22
>>> runs on bullseye and amd64, not on arm.
>>>
>>> as there are no log entries or any usable output how can i help to track
>>> this thing down? maybe its ruby related?
>>>
>>> would some strace output help?
>>
>> Hi,
>>
>> Are you *SURE* that the problem is the arch, and not the (very small)
>> amount of RAM you get on such a small device?
>>
>> I do remember running puppet agent on 512 MB device, and it was eating a
>> lot of RAM already. This was 5 years ago... I wouldn't be surprised if
>> newer ruby and newer puppet agent used more memory...
>>
>> Maybe you could try adding a lot of SWAP, just to try? (not saying that
>> a device swapping a lot is usable, but I just want to know if that would
>> work...)
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
> 
> Hi Thomas,
> 
> 8G of RAM (without swap) on a Pi4 should be sufficient ;-)

It should does. Thanks for the details. I thought it was one of these
512MB RAM Pi...

> 5.5.10 runs well, but slow on the Pi zeros (512MB).
> 
> OOM should be logged via kernel/dmesg? But there is nothing logged

Ok, I don't know then.

Thomas Goirand

Bug#992734: scripts/add-key: mktemp

2021-08-25 Thread Gunnar Wolf

tags 992734 + pending
thanks

Thank you very much for the patch, Clint!

I have added it to our working tree. Next time we upload a package,
the changelog will take care of closing this bug.

Bug#983357: Bug#988776: Bug#983357: Netinst crashes xen domU when loading kernel

2021-08-25 Thread Ben Hutchings

On Wed, 2021-08-25 at 12:45 -0400, Chuck Zmudzinski wrote:
[...]
> 
> I will try it in my bullseye Xen HVM DomU.
> 
> I am not sure how to rebuild the installation media with a patched
> systemd, but I can patch my installed Xen HVM DomU system
> with a patched systemd with the increased buffer size and see if the
> Coldplug failure early in the boot process goes away. If so, then it
> is likely this patch to systemd would also fix the installation media.
[...]

Sorry for not being clear - this is a patch for the kernel. 
Instructions for rebuilding the kernel package are at
.

I agree that you should check whether this fixes the coldplug error
before we try rebuilding the installer.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

Bug#990659: qemu-system-misc: qemu-riscv64-static sometimes crashes while running gcc in chroot

2021-08-25 Thread Rich

Hi Michael,
First, my apologies, I hadn't noticed you were one of the maintainers
of the package when I wrote my response, so it was written thinking I
was talking to someone uninvolved in the process who had offered
suggestions while stating a lack of familiarity with the problem
domain, not someone who every well-informed person in the discussion
would know was quite familiar with qemu a priori, and is just stating
they have no experience in this one area. (I have no particular
insight into why I reached this conclusion, but somehow I did.)

I very much appreciate that you've done everything you can reasonably
do at the moment to provide a reasonably recent and patched set of
software - I know the freeze meant that 6.0 couldn't turn up in
unstable, much less bullseye, which in turn means that
buster-backports wasn't going to see anything, and buster is, as you
say, obviously a complete nonstarter.

I'm no stranger to building and running my own packages, so that's not
really the issue, it just seems unfortunate to keep shipping a program
that has a nontrivial chance of crashing and burning every time it's
run, and there being no real potential for that changing. (Of course,
you might not know that's the case until well after it's in stable, at
which point it's not getting dropped short of earth-shattering
catastrophe...) I'm not claiming to have a good idea for how to
resolve or even mitigate this, other than perhaps a breakdown
somewhere easily discoverable of "we expect these tools to work
reliably, these few usually work for most people, and these forsaken
ones may torch the crops and salt the earth while laughing". (A
warning on first run of any of the more exciting options in
qemu-user-static or if any of qemu-system-* fit the bill would
probably be troublesome, at least in the common former case of being
used to run non-native binaries...)

I had not asked upstream for help because they pretty clearly state
[1] that they don't provide support for older or distro-provided
versions, and as I mentioned before, when I tried building 6.0 against
buster, it blew up spectacularly. (Of course, with bullseye out and
6.1 sitting happily in unstable, this becomes much more
accessible...once I take the plunge on my main systems, at least. And
it seems moot anyway, because I've been hanging out in their IRC
channel, and nobody seems to be getting turned away for running older
or distro versions, just gently suggested that it might be resolved
already.)

Thank you again for your work, and I'm sorry that I came across as an
ungrateful entitled person.

- Rich

[1] - https://www.qemu.org/support/

On Wed, Aug 25, 2021 at 10:46 AM Michael Tokarev  wrote:
>
> 04.07.2021 15:02, Rich wrote:
> > When I tried building qemu 6.0 or git on buster, as I recall it
> > errored out on dependencies not available in sufficiently new
> > incarnations, even in backports.
> >
> > If the answer to "this is quite buggy" is "just run a version not even
> > in unstable yet", that's...quite unfortunate.
> >
> > If you're just saying this because it's qemu upstream's opinion, well,
> > I knew that. :)
>
> Hi Rich!
>
> I'm sorry to disappoint you, but this was all I was able to offer.
> It is not "qemu upstream's opinion", it is my opinion, - it fells
> like riscv64 in 3.1 was quite buggy and there's nothing I can do
> about it, - I definitely wont backport changes from 6.0 to buster's
> 3.1 version.
>
> Usually qemu builds quite well on current distributions, including
> debian buster. I backported 5.2 version (from bullseye) for buster
> together with 2 or 3 new dependencies which were not in buster.
>
> I can not, at the time, provide a more recent version of qemu
> (6.0) even for unstable since - at the time - debian was frozen
> before bullseye release. However, I did provide 6.0 version
> in experimental - this is the only way I know to actually
> provide a new upstream version for debian during freeze.
> Ofcourse I can't provide backport of 6.0 for buster since it
> wasn't in bullsyeye or instable.
>
> So your disapproval of my answer stays solely with you - I did
> everything I was able to do. And I definitely suggested you the
> only realistic - to my opinion - way to go forward - which is to
> try either latest stable version or even the current development
> version. Because this is the only way to ensure if the bug you're
> seeing is already fixed.
>
> Meanwhile, 6.1 has been released (yesterday) and it is already
> available on debian unstable today.
>
> /mjt

Bug#992964: gadap: FTBFS due to RPC removal from glibc

Source: gadap
Version: 2.0-12
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead.

For this reason gadap now fails to build from source. You will find
attached a patch to switch to the TI RPC implementation, fixing the
FTBFS.

Regards,
Aurelien
--- gadap-2.0/debian/control
+++ gadap-2.0/debian/control
@@ -4,7 +4,8 @@
 Maintainer: Alastair McKinstry 
 Build-Depends: debhelper-compat (= 13), 
   libdap-dev (>= 3.14.0-4),
-  libcurl4-gnutls-dev | libcurl-dev, libxml2-dev
+  libcurl4-gnutls-dev | libcurl-dev, libxml2-dev,
+  pkg-config, libtirpc-dev
 Standards-Version: 4.5.1
 Homepage: http://cola.gmu.edu/grads/grads.php
 Vcs-Browser: https://salsa.debian.org:/science-team/gadap.git
--- gadap-2.0/debian/patches/libtirpc.patch
+++ gadap-2.0/debian/patches/libtirpc.patch
@@ -0,0 +1,29 @@
+Description: Switch to the TI RPC implementation
+Author: Aurelien Jarno 
+Last-Updated: 2021-08-25
+Forwarded: no
+
+--- gadap-2.0.orig/configure.ac
 gadap-2.0/configure.ac
+@@ -27,6 +27,13 @@ AC_FUNC_STRTOD
+ AC_CHECK_FUNCS([memset])
+ 
+ dnl Checks for specific libraries
++PKG_CHECK_MODULES([TIRPC], [libtirpc],
++ [
++  LIBS="$LIBS $TIRPC_LIBS"
++  CPPFLAGS="$CPPFLAGS $TIRPC_CFLAGS"
++ ],
++ [ AC_MSG_ERROR([Cannot find libtirpc])
++])
+ AC_CHECK_LIBDAP([3.7.3],
+  [
+   LIBS="$LIBS $DAP_LIBS $DAP_LIBS"
+--- gadap-2.0.orig/gadap.pc.in
 gadap-2.0/gadap.pc.in
+@@ -10,4 +10,4 @@ Description:
+ Version: @PACKAGE_VERSION@
+ Libs: -L${libdir} -lgadap
+ Libs.private:   -lpthread
+-Requires: libdapclient libdapserver
++Requires: libdapclient libdapserver libtirpc
--- gadap-2.0/debian/patches/series
+++ gadap-2.0/debian/patches/series
@@ -2,3 +2,4 @@
 libdap-namespace.patch
 test-errors.patch
 pkg-config.patch
+libtirpc.patch

Bug#992963: netkit-rwall: FTBFS due to RPC removal from glibc

Source: netkit-rwall
Version: 0.17-8
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead.

For this reason netkit-rwall now fails to build from source. You will
find attached a patch to switch to the TI RPC implementation, fixing the
FTBFS.

Regards,
Aurelien 
--- netkit-rwall-0.17/debian/control
+++ netkit-rwall-0.17/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Alberto Gonzalez Iniesta 
 Standards-Version: 4.2.1
-Build-Depends: debhelper (>= 10~), cmake
+Build-Depends: debhelper (>= 10~), cmake, pkg-config, libtirpc-dev
 
 Package: rwalld
 Architecture: any
--- netkit-rwall-0.17/debian/patches/series
+++ netkit-rwall-0.17/debian/patches/series
@@ -1,3 +1,4 @@
 define-salen.patch
 fix-typo.patch
 use-cmake-as-buildsystem.patch
+use-cmake-as-buildsystem-tirpc.patch
--- netkit-rwall-0.17/debian/patches/use-cmake-as-buildsystem-tirpc.patch
+++ netkit-rwall-0.17/debian/patches/use-cmake-as-buildsystem-tirpc.patch
@@ -0,0 +1,38 @@
+Description: Use TI RPC instead of GNU libc RPC 
+Author: Aurelien Jarno 
+Forwarded: no
+Last-Update: 2021-08-25
+
+--- netkit-rwall-0.17.orig/CMakeLists.txt
 netkit-rwall-0.17/CMakeLists.txt
+@@ -5,5 +5,8 @@ set(BIN_DIR "${CMAKE_INSTALL_PREFIX}/bin
+ set(SBIN_DIR "${CMAKE_INSTALL_PREFIX}/sbin")
+ set(MAN_DIR "${CMAKE_INSTALL_PREFIX}/share/man")
+ 
++find_package(PkgConfig REQUIRED)
++pkg_check_modules(TIRPC REQUIRED libtirpc)
++
+ add_subdirectory(rpc.rwalld)
+ add_subdirectory(rwall)
+--- netkit-rwall-0.17.orig/rpc.rwalld/CMakeLists.txt
 netkit-rwall-0.17/rpc.rwalld/CMakeLists.txt
+@@ -15,6 +15,8 @@ add_executable(
+ rwalld.c
+ rwall.h
+ )
++target_include_directories(rpc.rwalld PUBLIC ${TIRPC_INCLUDE_DIRS})
++target_link_libraries(rpc.rwalld ${TIRPC_LIBRARIES})
+ install(
+ TARGETS rpc.rwalld
+ DESTINATION ${SBIN_DIR}
+--- netkit-rwall-0.17.orig/rwall/CMakeLists.txt
 netkit-rwall-0.17/rwall/CMakeLists.txt
+@@ -14,6 +14,8 @@ add_executable(
+ rwall.c
+ rwall.h
+ )
++target_include_directories(rwall PUBLIC ${TIRPC_INCLUDE_DIRS})
++target_link_libraries(rwall ${TIRPC_LIBRARIES})
+ install(
+ TARGETS rwall
+ DESTINATION ${BIN_DIR}

Bug#992961: netkit-bootparamd: FTBFS due to RPC removal from glibc

Source: netkit-bootparamd
Version: 0.17-10
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead.

For this reason netkit-bootparamd now fails to build from source. You
will find attached a patch to switch to the TI RPC implementation,
fixing the FTBFS.

Regards,
Aurelien 
--- netkit-bootparamd-0.17/debian/control
+++ netkit-bootparamd-0.17/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Alberto Gonzalez Iniesta 
 Standards-Version: 4.3.0
-Build-Depends: debhelper (>= 10~), cmake
+Build-Depends: debhelper (>= 10~), cmake, pkg-config, libtirpc-dev
 
 Package: bootparamd
 Architecture: any
--- netkit-bootparamd-0.17/debian/patches/series
+++ netkit-bootparamd-0.17/debian/patches/series
@@ -1,3 +1,5 @@
 fix-getopt-return-type.patch
 use-cmake-as-buildsystem.patch
 use-cmake-as-buildsystem-debian-extras.patch
+use-cmake-as-buildsystem-tirpc.patch
+tirpc-drop-glibc-fix.patch
--- netkit-bootparamd-0.17/debian/patches/tirpc-drop-glibc-fix.patch
+++ netkit-bootparamd-0.17/debian/patches/tirpc-drop-glibc-fix.patch
@@ -0,0 +1,19 @@
+Description: Drop a GNU libc fix now that TI RPC is used instead
+Author: Aurelien Jarno 
+Forwarded: no
+Last-Update: 2021-08-25
+
+--- netkit-bootparamd-0.17.orig/rpc.bootparamd/main.c
 netkit-bootparamd-0.17/rpc.bootparamd/main.c
+@@ -16,11 +16,6 @@
+ #include "bootparam_prot.h"
+ 
+ 
+-#ifdef __GLIBC__
+-  /* quick fix */
+-  void get_myaddress(struct sockaddr_in *);
+-#endif
+-
+ int debug = 0;
+ int dolog = 0;
+ struct in_addr route_addr;
--- netkit-bootparamd-0.17/debian/patches/use-cmake-as-buildsystem-tirpc.patch
+++ netkit-bootparamd-0.17/debian/patches/use-cmake-as-buildsystem-tirpc.patch
@@ -0,0 +1,35 @@
+Description: Use TI RPC instead of GNU libc RPC 
+Author: Aurelien Jarno 
+Forwarded: no
+Last-Update: 2021-08-25
+
+--- netkit-bootparamd-0.17.orig/CMakeLists.txt
 netkit-bootparamd-0.17/CMakeLists.txt
+@@ -5,4 +5,7 @@ set(BIN_DIR "${CMAKE_INSTALL_PREFIX}/bin
+ set(SBIN_DIR "${CMAKE_INSTALL_PREFIX}/sbin")
+ set(MAN_DIR "${CMAKE_INSTALL_PREFIX}/share/man")
+ 
++find_package(PkgConfig REQUIRED)
++pkg_check_modules(TIRPC REQUIRED libtirpc)
++
+ add_subdirectory(rpc.bootparamd)
+--- netkit-bootparamd-0.17.orig/rpc.bootparamd/CMakeLists.txt
 netkit-bootparamd-0.17/rpc.bootparamd/CMakeLists.txt
+@@ -13,6 +13,8 @@ add_executable(
+ 
+ bootparam_prot.h
+ )
++target_include_directories(rpc.bootparamd PUBLIC ${TIRPC_INCLUDE_DIRS})
++target_link_libraries(rpc.bootparamd ${TIRPC_LIBRARIES})
+ add_executable(
+ callbootd
+ 
+@@ -22,6 +24,8 @@ add_executable(
+ 
+ bootparam_prot.h
+ )
++target_include_directories(callbootd PUBLIC ${TIRPC_INCLUDE_DIRS})
++target_link_libraries(callbootd ${TIRPC_LIBRARIES})
+ 
+ install(
+ TARGETS rpc.bootparamd
--- netkit-bootparamd-0.17/debian/control
+++ netkit-bootparamd-0.17/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Alberto Gonzalez Iniesta 
 Standards-Version: 4.3.0
-Build-Depends: debhelper (>= 10~), cmake
+Build-Depends: debhelper (>= 10~), cmake, pkg-config, libtirpc-dev
 
 Package: bootparamd
 Architecture: any
--- netkit-bootparamd-0.17/debian/patches/series
+++ netkit-bootparamd-0.17/debian/patches/series
@@ -1,3 +1,5 @@
 fix-getopt-return-type.patch
 use-cmake-as-buildsystem.patch
 use-cmake-as-buildsystem-debian-extras.patch
+use-cmake-as-buildsystem-tirpc.patch
+tirpc-drop-glibc-fix.patch
--- netkit-bootparamd-0.17/debian/patches/tirpc-drop-glibc-fix.patch
+++ netkit-bootparamd-0.17/debian/patches/tirpc-drop-glibc-fix.patch
@@ -0,0 +1,19 @@
+Description: Drop a GNU libc fix now that TI RPC is used instead
+Author: Aurelien Jarno 
+Forwarded: no
+Last-Update: 2021-08-25
+
+--- netkit-bootparamd-0.17.orig/rpc.bootparamd/main.c
 netkit-bootparamd-0.17/rpc.bootparamd/main.c
+@@ -16,11 +16,6 @@
+ #include "bootparam_prot.h"
+ 
+ 
+-#ifdef __GLIBC__
+-  /* quick fix */
+-  void get_myaddress(struct sockaddr_in *);
+-#endif
+-
+ int debug = 0;
+ int dolog = 0;
+ struct in_addr route_addr;
--- netkit-bootparamd-0.17/debian/patches/use-cmake-as-buildsystem-tirpc.patch
+++ netkit-bootparamd-0.17/debian/patches/use-cmake-as-buildsystem-tirpc.patch
@@ -0,0 +1,35 @@
+Description: Use TI RPC instead of GNU libc RPC 
+Author: Aurelien Jarno 
+Forwarded: no
+Last-Update: 2021-08-25
+
+--- netkit-bootparamd-0.17.orig/CMakeLists.txt
 netkit-bootparamd-0.17/CMakeLists.txt
+@@ -5,4 +5,7 @@ set(BIN_DIR "${CMAKE_INSTALL_PREFIX}/bin
+ set(SBIN_DIR "${CMAKE_INSTALL_PREFIX}/sbin")
+ set(MAN_DIR "${CMAKE_INSTALL_PREFIX}/share/man")
+ 
++find_package(PkgConfig REQUIRED)
++pkg_check_modules(TIRPC REQUIRED libtirpc)
++
+ add_subdirectory(rpc.bootparamd)
+---

Bug#992962: netkit-rusers: FTBFS due to RPC removal from glibc

Source: netkit-rusers
Version: 0.17-10
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead.

For this reason netkit-rusers now fails to build from source. You will
find attached a patch to switch to the TI RPC implementation, fixing the
FTBFS.

Regards,
Aurelien 
--- netkit-rusers-0.17/debian/control
+++ netkit-rusers-0.17/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Alberto Gonzalez Iniesta 
 Standards-Version: 4.2.1
-Build-Depends: debhelper (>= 11), cmake
+Build-Depends: debhelper (>= 11), cmake, pkg-config, libtirpc-dev
 
 Package: rusersd
 Architecture: any
--- netkit-rusers-0.17/debian/patches/series
+++ netkit-rusers-0.17/debian/patches/series
@@ -2,3 +2,4 @@
 system-headers-location.patch
 use-cmake-as-buildsystem.patch
 use-cmake-as-buildsystem-debian-extras.patch
+use-cmake-as-buildsystem-tirpc.patch
--- netkit-rusers-0.17/debian/patches/use-cmake-as-buildsystem-tirpc.patch
+++ netkit-rusers-0.17/debian/patches/use-cmake-as-buildsystem-tirpc.patch
@@ -0,0 +1,50 @@
+Description: Use TI RPC instead of GNU libc RPC 
+Author: Aurelien Jarno 
+Forwarded: no
+Last-Update: 2021-08-25
+
+--- netkit-rusers-0.17.orig/CMakeLists.txt
 netkit-rusers-0.17/CMakeLists.txt
+@@ -7,6 +7,9 @@ set(MAN_DIR "${CMAKE_INSTALL_PREFIX}/sha
+ 
+ set(USE_GLIBC 1)
+ 
++find_package(PkgConfig REQUIRED)
++pkg_check_modules(TIRPC REQUIRED libtirpc)
++
+ add_subdirectory(rpc.rusersd)
+ add_subdirectory(rup)
+ add_subdirectory(rusers)
+--- netkit-rusers-0.17.orig/rpc.rusersd/CMakeLists.txt
 netkit-rusers-0.17/rpc.rusersd/CMakeLists.txt
+@@ -21,6 +21,8 @@ add_executable(
+ daemon.c
+ rusers.h
+ )
++target_include_directories(rpc.rusersd PUBLIC ${TIRPC_INCLUDE_DIRS})
++target_link_libraries(rpc.rusersd ${TIRPC_LIBRARIES})
+ install(
+ TARGETS rpc.rusersd
+ DESTINATION ${SBIN_DIR}
+--- netkit-rusers-0.17.orig/rup/CMakeLists.txt
 netkit-rusers-0.17/rup/CMakeLists.txt
+@@ -16,6 +16,8 @@ add_executable(
+ rstat_xdr.c
+ rstat.h
+ )
++target_include_directories(rup PUBLIC ${TIRPC_INCLUDE_DIRS})
++target_link_libraries(rup ${TIRPC_LIBRARIES})
+ install(
+ TARGETS rup
+ DESTINATION ${BIN_DIR}
+--- netkit-rusers-0.17.orig/rusers/CMakeLists.txt
 netkit-rusers-0.17/rusers/CMakeLists.txt
+@@ -23,6 +23,8 @@ add_executable(
+ rusers_xdr.c
+ rusers.h
+ )
++target_include_directories(rusers PUBLIC ${TIRPC_INCLUDE_DIRS})
++target_link_libraries(rusers ${TIRPC_LIBRARIES})
+ install(
+ TARGETS rusers
+ DESTINATION ${BIN_DIR}

Bug#992069: marked as done (libvkd3d-doc is not installable besides libvkd3d-dev)

2021-08-25 Thread Antoine Le Gonidec


Le 25/08/2021 à 14:21, Antoine Le Gonidec a écrit :

Le 23/08/2021 à 22:44, Sveinar Søpler a écrit :

Can anyone CONFIRM that libvkd3d-dev and libvkd3d-doc (1.2-6) is installable at 
the same time without a conflict?


I wanted to give it a try, but the dependencies of experimental version of 
libvkd3d1 prevent its installation on a current Debian Sid/Bookworm:
(…)
See the "Depends: mesa-vulkan-drivers (<< 21)" from libvkd3d1 1.2-6 
dependencies, it clashes with the version of mesa-vulkan-drivers provided in both unstable and 
experimental.


I gave it a new try after a downgrade to the testing version of 
mesa-vulkan-drivers (20.3.5-1), and I end up with a file conflict error between 
libvkd3d-doc and libvkd3d-dev (both in version 1.2-6):

Unpacking libvkd3d-doc (1.2-6) ...
dpkg: error processing archive 
/tmp/apt-dpkg-install-o7eou1/7-libvkd3d-doc_1.2-6_all.deb (--unpack):
 trying to overwrite '/usr/share/doc/libvkd3d-dev/ANNOUNCE.gz', which is also 
in package libvkd3d-dev:amd64 1.2-6



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992069: marked as done (libvkd3d-doc is not installable besides libvkd3d-dev)

2021-08-25 Thread Antoine Le Gonidec


Le 23/08/2021 à 22:44, Sveinar Søpler a écrit :

Can anyone CONFIRM that libvkd3d-dev and libvkd3d-doc (1.2-6) is installable at 
the same time without a conflict?


I wanted to give it a try, but the dependencies of experimental version of 
libvkd3d1 prevent its installation on a current Debian Sid/Bookworm:

root@hal9000:~# apt depends libvkd3d-dev/experimental
libvkd3d-dev
  Depends: libvkd3d1 (= 1.2-6)
  Depends: libvkd3d-utils1 (= 1.2-6)
  Depends: libvkd3d-shader1 (= 1.2-6)
  Depends: libvkd3d-headers (= 1.2-6)
  Suggests: libvkd3d-doc (= 1.2-6)

root@hal9000:~# apt depends libvkd3d1=1.2-6
libvkd3d1
  Depends: libvulkan1 (>= 1.1.70)
  Depends: libc6 (>= 2.14)
  Depends: libvkd3d-shader1 (>= 1.2)
  Depends: mesa-vulkan-drivers (<< 21)

root@hal9000:~# apt policy mesa-vulkan-drivers
mesa-vulkan-drivers:
  Installed: 21.2.1-1
  Candidate: 21.2.1-1
  Version table:
 *** 21.2.1-1 500
500 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
 21.2.0-1 1
  1 http://deb.debian.org/debian experimental/main amd64 Packages
 20.3.5-1 500
500 http://deb.debian.org/debian stable/main amd64 Packages
500 http://deb.debian.org/debian testing/main amd64 Packages
 18.3.6-2+deb10u1 500
500 http://deb.debian.org/debian oldstable/main amd64 Packages

See the "Depends: mesa-vulkan-drivers (<< 21)" from libvkd3d1 1.2-6 
dependencies, it clashes with the version of mesa-vulkan-drivers provided in both unstable and 
experimental.

This is most probably related to the 1.2-5 → 1.2-6 vkd3d update, see this line 
from the changelog:
« Require mesa-vulkan-drivers before version 21 (causes test failures). »



OpenPGP_signature
Description: OpenPGP digital signature

Bug#992959: nx-libs: FTBFS due to RPC removal from glibc

Source: nx-libs
Version: 2:3.5.99.26-2
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)

Dear maintainer,

The glibc SunRPC implementation has been marked obsolete for some time.
It has been removed upstream from glibc 2.32, and it got disabled in the
recent glibc uploads. The TI RPC implementation should be used instead.

Fortunately nx-libs already supports building libtirpc using the
-DUseTIRPC=1 option, so the fix is really simple. Please find attached a
patch fixing the FTBFS.

Regards,
Aurelien
--- nx-libs-3.5.99.26/debian/control
+++ nx-libs-3.5.99.26/debian/control
@@ -15,6 +15,7 @@
  libjpeg-dev,
  libpixman-1-dev (>= 0.13.2),
  libpng-dev,
+ libtirpc-dev,
  libtool,
  libxcomposite-dev,
  libxdamage-dev,
--- nx-libs-3.5.99.26/debian/rules
+++ nx-libs-3.5.99.26/debian/rules
@@ -58,7 +58,7 @@
 
 override_dh_auto_build:
 
-   PREFIX='/usr' dh_auto_build --no-parallel -- CDEBUGFLAGS="$(CPPFLAGS) 
$(CFLAGS)" LOCAL_LDFLAGS="$(LDFLAGS)" SHLIBGLOBALSFLAGS='$(filter-out 
-pie,$(LDFLAGS))'
+   PREFIX='/usr' dh_auto_build --no-parallel -- CDEBUGFLAGS="$(CPPFLAGS) 
$(CFLAGS)" LOCAL_LDFLAGS="$(LDFLAGS)" SHLIBGLOBALSFLAGS='$(filter-out 
-pie,$(LDFLAGS))' IMAKE_DEFINES="-DUseTIRPC=1"
 
 override_dh_makeshlibs:
dh_makeshlibs -n

Bug#992960: nfstrace: FTBFS due to RPC removal from glibc