Bug#1031810: mirror listing update for debian.mirror.net.in

[Mirror Admin Debian]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: debian.mirror.net.in
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Mirror Admin Debian 
Country: IN India
Location: Mumbai
Sponsor: Digital Dreams Consulting Pvt Ltd https://www.ddcpl.com




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

Bug#1031770: kontact: cannot show existing messages and will not retrieve new ones

[Rai]

Hi all,

The same thing here:
I updated my debian 10 here on Tuesday and restarting the system Wednesday 
morning kmail and calendar get broken with the mentioned mysql error. Even 
deletion of ./local/share/akonadi and others does not help.

I think the mariadb stuff is the culprit one.

Here is the relevant part of dpkg.log:

2023-02-21 07:30:26 startup archives unpack
2023-02-21 07:30:26 upgrade isc-dhcp-client:amd64 4.4.1-2+deb10u2 
4.4.1-2+deb10u3
2023-02-21 07:30:26 status half-configured isc-dhcp-client:amd64 4.4.1-2+deb10u2
2023-02-21 07:30:26 status unpacked isc-dhcp-client:amd64 4.4.1-2+deb10u2
2023-02-21 07:30:26 status half-installed isc-dhcp-client:amd64 4.4.1-2+deb10u2
2023-02-21 07:30:26 status triggers-pending man-db:amd64 2.8.5-2
2023-02-21 07:30:26 status unpacked isc-dhcp-client:amd64 4.4.1-2+deb10u3
2023-02-21 07:30:26 upgrade isc-dhcp-common:amd64 4.4.1-2+deb10u2 
4.4.1-2+deb10u3
2023-02-21 07:30:26 status half-configured isc-dhcp-common:amd64 4.4.1-2+deb10u2
2023-02-21 07:30:26 status unpacked isc-dhcp-common:amd64 4.4.1-2+deb10u2
2023-02-21 07:30:26 status half-installed isc-dhcp-common:amd64 4.4.1-2+deb10u2
2023-02-21 07:30:26 status unpacked isc-dhcp-common:amd64 4.4.1-2+deb10u3
2023-02-21 07:30:26 upgrade libssl1.1:amd64 1.1.1n-0+deb10u3 1.1.1n-0+deb10u4
2023-02-21 07:30:26 status triggers-pending libc-bin:amd64 2.28-10+deb10u2
2023-02-21 07:30:26 status half-configured libssl1.1:amd64 1.1.1n-0+deb10u3
2023-02-21 07:30:26 status unpacked libssl1.1:amd64 1.1.1n-0+deb10u3
2023-02-21 07:30:26 status half-installed libssl1.1:amd64 1.1.1n-0+deb10u3
2023-02-21 07:30:26 status unpacked libssl1.1:amd64 1.1.1n-0+deb10u4
2023-02-21 07:30:26 upgrade mariadb-common:all 1:10.3.36-0+deb10u2 
1:10.3.38-0+deb10u1
2023-02-21 07:30:26 status half-configured mariadb-common:all 
1:10.3.36-0+deb10u2
2023-02-21 07:30:26 status unpacked mariadb-common:all 1:10.3.36-0+deb10u2
2023-02-21 07:30:26 status half-installed mariadb-common:all 1:10.3.36-0+deb10u2
2023-02-21 07:30:26 status unpacked mariadb-common:all 1:10.3.38-0+deb10u1
2023-02-21 07:30:26 upgrade libmariadb3:amd64 1:10.3.36-0+deb10u2 
1:10.3.38-0+deb10u1
2023-02-21 07:30:26 status half-configured libmariadb3:amd64 1:10.3.36-0+deb10u2
2023-02-21 07:30:26 status unpacked libmariadb3:amd64 1:10.3.36-0+deb10u2
2023-02-21 07:30:26 status half-installed libmariadb3:amd64 1:10.3.36-0+deb10u2
2023-02-21 07:30:26 status unpacked libmariadb3:amd64 1:10.3.38-0+deb10u1
2023-02-21 07:30:26 upgrade libnss3:amd64 2:3.42.1-1+deb10u5 2:3.42.1-1+deb10u6
2023-02-21 07:30:26 status half-configured libnss3:amd64 2:3.42.1-1+deb10u5
2023-02-21 07:30:26 status unpacked libnss3:amd64 2:3.42.1-1+deb10u5
2023-02-21 07:30:26 status half-installed libnss3:amd64 2:3.42.1-1+deb10u5
2023-02-21 07:30:26 status unpacked libnss3:amd64 2:3.42.1-1+deb10u6
2023-02-21 07:30:26 upgrade mariadb-client-core-10.3:amd64 1:10.3.36-0+deb10u2 
1:10.3.38-0+deb10u1
2023-02-21 07:30:26 status half-configured mariadb-client-core-10.3:amd64 
1:10.3.36-0+deb10u2
2023-02-21 07:30:26 status unpacked mariadb-client-core-10.3:amd64 
1:10.3.36-0+deb10u2
2023-02-21 07:30:26 status half-installed mariadb-client-core-10.3:amd64 
1:10.3.36-0+deb10u2
2023-02-21 07:30:27 status unpacked mariadb-client-core-10.3:amd64 
1:10.3.38-0+deb10u1
2023-02-21 07:30:27 upgrade mariadb-server-core-10.3:amd64 1:10.3.36-0+deb10u2 
1:10.3.38-0+deb10u1
2023-02-21 07:30:27 status half-configured mariadb-server-core-10.3:amd64 
1:10.3.36-0+deb10u2
2023-02-21 07:30:27 status unpacked mariadb-server-core-10.3:amd64 
1:10.3.36-0+deb10u2
2023-02-21 07:30:27 status half-installed mariadb-server-core-10.3:amd64 
1:10.3.36-0+deb10u2
2023-02-21 07:30:27 status unpacked mariadb-server-core-10.3:amd64 
1:10.3.38-0+deb10u1
2023-02-21 07:30:27 upgrade openssl:amd64 1.1.1n-0+deb10u3 1.1.1n-0+deb10u4
2023-02-21 07:30:27 status half-configured openssl:amd64 1.1.1n-0+deb10u3
2023-02-21 07:30:27 status unpacked openssl:amd64 1.1.1n-0+deb10u3
2023-02-21 07:30:27 status half-installed openssl:amd64 1.1.1n-0+deb10u3
2023-02-21 07:30:27 status unpacked openssl:amd64 1.1.1n-0+deb10u4
2023-02-21 07:30:27 startup packages configure
2023-02-21 07:30:27 configure libssl1.1:amd64 1.1.1n-0+deb10u4 
2023-02-21 07:30:27 status unpacked libssl1.1:amd64 1.1.1n-0+deb10u4
2023-02-21 07:30:27 status half-configured libssl1.1:amd64 1.1.1n-0+deb10u4
2023-02-21 07:30:28 status installed libssl1.1:amd64 1.1.1n-0+deb10u4
2023-02-21 07:30:28 configure isc-dhcp-client:amd64 4.4.1-2+deb10u3 
2023-02-21 07:30:28 status unpacked isc-dhcp-client:amd64 4.4.1-2+deb10u3
2023-02-21 07:30:28 status half-configured isc-dhcp-client:amd64 4.4.1-2+deb10u3
2023-02-21 07:30:28 status installed isc-dhcp-client:amd64 4.4.1-2+deb10u3
2023-02-21 07:30:28 configure libnss3:amd64 2:3.42.1-1+deb10u6 
2023-02-21 07:30:28 status unpacked libnss3:amd64 2:3.42.1-1+deb10u6
2023-02-21 07:30:28 status half-configured libnss3:amd64 2:3.42.1-1+deb10u6
2023-02-21 07:30:28 status installed 

Bug#1031799: cmake-data: cmake does not search multiarch paths for HIP

[Cordell Bloor]

There is a related issue once finding hip-lang-config.cmake is handled. The
next problem is this:

    CMake Error at 
/usr/share/cmake-3.25/Modules/CMakeFindDependencyMacro.cmake:47 
(find_package):
  By not providing "Findamd_comgr.cmake" in CMAKE_MODULE_PATH this 
project

  has asked CMake to find a package configuration file provided by
  "amd_comgr", but CMake did not find one.

  Could not find a package configuration file provided by 
"amd_comgr" with

  any of the following names:

    amd_comgrConfig.cmake
    amd_comgr-config.cmake

  Add the installation prefix of "amd_comgr" to CMAKE_PREFIX_PATH 
or set

  "amd_comgr_DIR" to a directory containing one of the above files.  If
  "amd_comgr" provides a separate development package or SDK, be 
sure it has

  been installed.
    Call Stack (most recent call first):
/usr/lib/x86_64-linux-gnu/cmake/hip-lang/hip-lang-config.cmake:98 
(find_dependency)
  /usr/share/cmake-3.25/Modules/CMakeHIPInformation.cmake:146 
(find_package)
/root/build/CMakeFiles/CMakeScratch/TryCompile-9ltYBc/CMakeLists.txt:2 
(project)



    CMake Error at 
/usr/share/cmake-3.25/Modules/CMakeDetermineCompilerABI.cmake:57 
(try_compile):

  Failed to configure test project build system.
    Call Stack (most recent call first):
  /usr/share/cmake-3.25/Modules/CMakeTestHIPCompiler.cmake:29 
(CMAKE_DETERMINE_COMPILER_ABI)

  CMakeLists.txt:6 (enable_language)


    -- Configuring incomplete, errors occurred!

I haven't pinned down the exact cause, but I think this is because
project(example LANGUAGE HIP) will call hip-lang-config.cmake before
CMAKE_HIP_LIBRARY_ARCHITECTURE is detected and therefore
/usr/lib/x86_64-linux-gnu/amd_comgr is not in the search path. It only 
checks

/usr/lib/amd_comgr. You can workaround the issue by passing the architecture
explicitly or by adding /usr/lib/x86_64-linux-gnu/amd_comgr to your PATH.

It's not immediately clear to me whether this aspect of the failure 
should be

considered a HIP bug or a CMake bug. I'm tempted to ask for some advice from
upstream.

Bug#1031809: Bump webp-pixbuf-loader version to 0.1.2 as it contains important bugfixes

[Nikolay Kyx]

Package: webp-pixbuf-loader
Version: 0.0.5-5
Severity: serious

Steps to reproduce:
1. Install gpicview.
2. Skip through webp images (cycling between 2 is sufficient) and
monitor its RAM consumption.
3. Consider updating to latest tag
https://github.com/aruiz/webp-pixbuf-loader/releases

Bug#1031808: clang-15: clang does not search debian paths for rocm

[Cordell Bloor]

Package: clang-15
Version: 1:15.0.7-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

Clang does not search the system paths when looking for the ROCm
components that it requires for building HIP langauge code. Consider the
following sample program:

main.hip:

#include 
#include 
#include 

#define CHECK_HIP(expr) do {  \
  hipError_t result = (expr); \
  if (result != hipSuccess) { \
fprintf(stderr, "%s:%d: %s (%d)\n",   \
  __FILE__, __LINE__, \
  hipGetErrorString(result), result); \
exit(EXIT_FAILURE);   \
  }   \
} while(0)

__global__ void sq_arr(float *arr, int n) {
  int tid = blockDim.x*blockIdx.x + threadIdx.x;
  if (tid < n) {
arr[tid] = arr[tid] * arr[tid];
  }
}

int main() {
  enum { N = 5 };
  float hArr[N] = { 1, 2, 3, 4, 5 };
  float *dArr;
  CHECK_HIP(hipMalloc(, sizeof(float) * N));
  CHECK_HIP(hipMemcpy(dArr, hArr, sizeof(float) * N, 
hipMemcpyHostToDevice));
  sq_arr<<>>(dArr, N);
  CHECK_HIP(hipMemcpy(hArr, dArr, sizeof(float) * N, 
hipMemcpyDeviceToHost));
  for (int i = 0; i < N; ++i) {
printf("%f\n", hArr[i]);
  }
  CHECK_HIP(hipFree(dArr));
  return 0;
}

It should be possible to build this sample program using the commands:

apt install hipcc
clang++-15 -x hip -lamdhip64 main.hip

At present, however, that will result in the following error messages:

clang: error: cannot find ROCm device library; provide its path via 
'--rocm-path' or '--rocm-device-lib-path', or pass '-nogpulib' to build without 
ROCm device library
clang: error: cannot find HIP runtime; provide its path via '--rocm-path', 
or pass '-nogpuinc' to build without HIP runtime
clang: error: cannot find HIP runtime; provide its path via '--rocm-path', 
or pass '-nogpuinc' to build without HIP runtime

The errors can be resolved with a few additional flags:

  clang++-15 -x hip --rocm-path=/usr \
--rocm-device-lib-path=/usr/lib/x86_64-linux-gnu/amdgcn/bitcode \
--hip-version=5.2.21153 \
-lamdhip64 main.hip

However, this should not be necessary. The first step should be to
backport the upstream HIP detection for Debian and Fedora [1]. That will
solve 2/3rds of this problem by eliminating the need to pass --rocm-path
and --hip-version. 

It's less clear what should be done about the ROCm Device Lib path. The
upstream LLVM project searches for the ROCm device libs at
/usr/lib/llvm-15/lib/clang/15.0.7/lib/amdgcn/bitcode [2], which seems
like the ideal place to put them. However, placing the device libs in a
path that contains the LLVM version number would require a lot of
coordination between packages.

My understanding is that the bitcode files are LLVM IR and newer
versions of LLVM can use bitcode files that were compiled with older
versions of LLVM [3], so it should be fine to leave the bitcode files in
an unversioned path like /usr/lib/$(DEB_HOST_MULTIARCH)/amdgcn/bitcode
and still not have to worry about what happens when LLVM is updated.

After considering these trade-offs, my conclusion is that
/usr/lib/$(DEB_HOST_MULTIARCH)/amdgcn/bitcode should be added to the
search paths for the ROCm device libs.

Sincerely,
Cory Bloor

[1]: 
https://github.com/llvm/llvm-project/commit/082593ff7aff68060bd66dccfa43493d07d9c255
[2]: 
https://github.com/llvm/llvm-project/blob/419948fe6708021524f86e15d755719d634ab8d2/clang/lib/Driver/ToolChains/AMDGPU.cpp#L416
[3]: https://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages clang-15 depends on:
ii  binutils2.40-2
ii  libc6   2.36-8
ii  libc6-dev   2.36-8
ii  libclang-common-15-dev  1:15.0.7-1
ii  libclang-cpp15  1:15.0.7-1
ii  libclang1-151:15.0.7-1
ii  libgcc-12-dev   12.2.0-14
ii  libgcc-s1   12.2.0-14
ii  libllvm15   1:15.0.7-1
ii  libobjc-12-dev  12.2.0-14
ii  libstdc++-12-dev12.2.0-14
ii  libstdc++6  12.2.0-14
ii  llvm-15-linker-tools1:15.0.7-1

Versions of packages clang-15 recommends:
ii  llvm-15-dev  1:15.0.7-1
ii  python3  3.11.2-1

Versions of packages clang-15 suggests:
pn  clang-15-doc  
pn  wasi-libc 

-- no debconf information

Bug#1019841: Works fine with the patch

[Michael Fritscher]

Good day,

amule works just fine with the patch. Tested: Connecting to the
networks, searching, downloading and uploading. So it seems to be good
to apply the patch and let it through the machinery :-)

It seems that we missed the soft freeze. But is there any chance to get
an exception to get it back to testing? I mean, this is a "leaf" package
(nothing should depend on it or use it), so there should be no risk, and
this way, users who upgrade to bookworm are not left with unmaintained
versions of some libraries on which amule depends on, which is a
security problem.
Or can we use the -backports way, which used by phpmyadmin some releases
ago iirc?

Hint: If you like to test it yourself, you can search for debian or
ubuntu (which has more sources anyhow). Then you'll find e.g. some iso
files from e.g. Debian 10 or Ubuntu 22.04. The program does not up- or
download any data you don't request. You probably need a current
server.met, which can you find on the internet (I hesitate to link at it
directly here, but I can if you prefer this way)

Best regards,
Michael

Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Dima Kogan (2023-02-23 00:45:37)
> This should work, but it doesn't. I used sysdig to confirm that
> something is indeed looking in $PWD/keys/ and something is indeed
> calling read() on the relevant key. I have also confirmed that if I copy
> my keys to /etc/apt/trusted.gpg.d/ then it does work properly. But I
> don't want to do that. Ideally I'd like mmdebstrap to grab all the keys
> in $PWD/keys and add them to /etc/apt/trusted.gpg.d/ in the chroot, but
> NOT on the host machine. Any clear way to do that? Any debugging tricks
> I'm missing?

there unfortunately exists no way to ask apt for more information about why
"apt-get update" fails. So lets try to figure out whether this is an apt
problem or an mmdebstrap problem. At the end of the mmdebstrap man page you
find a small shell script:

mkdir -p "$2/etc/apt" "$2/var/cache" "$2/var/lib"
cat << END > "$2/apt.conf"
Apt::Architecture "$(dpkg --print-architecture)";
Apt::Architectures "$(dpkg --print-architecture)";
Dir "$(cd "$2" && pwd)";
Dir::Etc::Trusted "$(eval "$(apt-config shell v Dir::Etc::Trusted/f)"; 
printf "$v")";
Dir::Etc::TrustedParts "$(eval "$(apt-config shell v 
Dir::Etc::TrustedParts/d)"; printf "$v")";
END
echo "deb http://deb.debian.org/debian/ $1 main" > "$2/etc/apt/sources.list"
APT_CONFIG="$2/apt.conf" apt-get update
APT_CONFIG="$2/apt.conf" apt-get --yes --download-only install '?essential'
for f in "$2"/var/cache/apt/archives/*.deb; do dpkg-deb --extract "$f" 
"$2"; done
chroot "$2" sh -c "dpkg --install --force-depends 
/var/cache/apt/archives/*.deb"

This script sets up a chroot in the same way as mmdebstrap does. But now you
can directly change some values like Dir::Etc::TrustedParts which you can now
explicitly set to your keyring directory. If you do that (and also put your
mirror into the sources.list), what happens?

Thanks!

cheers, josch

Bug#1031807: ITP: java-opensaml -- Shibboleth Project's OpenSAML java libraries

[Joseph Nahmias]

Package: wnpp
Severity: wishlist
Owner: Joseph Nahmias 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-j...@lists.debian.org, 
debian-security-to...@lists.debian.org, j...@nahmias.net, d...@shibboleth.net
Control: block 1031769 by -1

* Package name: java-opensaml
  Version : 4.3.0
  Upstream Author : Shibboleth 
* URL : https://shibboleth.atlassian.net/wiki/spaces/OS30/overview
* License : Apache 2
  Programming Lang: Java
  Description : Shibboleth Project's OpenSAML java libraries

 OpenSAML is a set of open source C++ & Java libraries used in support
 of the Shibboleth Project's implementation of the Security Assertion
 Markup Language (SAML).

 OpenSAML 4, the current Java library version, is based on Java 11, and
 supports SAML 1.0, 1.1, and 2.0. Additionally, various development groups
 have found the framework created to support OpenSAML useful for their own
 work and the Java codebase includes some code supporting WS-Addressing,
 WS-Security, WS-Trust and XACML.

 The OpenSAML libraries do not provide a complete SAML identity or service
 provider. If you are looking for such software you should check out the
 Shibboleth project instead. Also, these libraries will not teach you any
 of the specifications listed above. The libraries are meant solely to
 support individuals who have taken the time to read and understand the
 specifications and are not in general a good solution for those looking
 for a quick way to implement SAML.

Bug#1031806: installation-reports: Installation completed successfully but no user /home folder or Documents, Pictures etc

[Jason]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: mtx_li...@hotmail.com

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
https://gemmei.ftp.acc.umu.se/cdimage/bookworm_di_alpha2/amd64/iso-cd/debian-bookworm-DI-alpha2-amd64-netinst.iso
Date: 

Machine: Dell Inspiron 3670
Partitions: 


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

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

Comments/Problems:




Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230217"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 6.1.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.8-1 
(2023-01-29) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core 
Processor Host Bridge/DRAM Registers [8086:3ec2] (rev 07)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core 
Processor PCIe Controller (x16) [8086:1901] (rev 07)
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 Display controller [0380]: Intel Corporation CoffeeLake-S 
GT2 [UHD Graphics 630] [8086:3e92]
lspci -knn: DeviceName: Onboard - Video
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 
v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model 
[8086:1911]
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation 
Cannon Lake PCH Thermal Controller [8086:a379] (rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH 
USB 3.1 xHCI Host Controller [8086:a36d] (rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared 
SRAM [8086:a36f] (rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Cannon 
Lake PCH HECI Controller [8086:a360] (rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake PCH 
SATA AHCI Controller [8086:a352] (rev 10)
lspci -knn: DeviceName: Onboard - SATA
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1b.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #21 [8086:a32c] (rev f0)
lspci -knn: DeviceName: Intel HD Audio
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #5 [8086:a33c] (rev f0)
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.7 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #8 [8086:a33f] (rev f0)
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:a308] 
(rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS 
[8086:a348] (rev 10)
lspci -knn: DeviceName: Onboard - Sound
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn:  

Bug#1029731: libglapi-mesa: Apps fail with 'DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory' after upgrade from 22.3.2-1 to 22.3.3-1

[Stuart Young]

Hi All,

Just a note that it looks like this patch got picked up in the 22.3.6
release that just went out.


On Thu, 23 Feb 2023 at 06:03, Diederik de Haas 
wrote:

> Control: tag -1 upstream fixed-upstream patch
>
> On Tue, 31 Jan 2023 01:19:54 +0300 Andrey Skvortsov
>  wrote:
> > Here is link to created upstream issue.
> > https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198
>
> In https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21330 this
> issue
> got fixed upstream and I've attached the patch/diff to this message.
>
> When adding it to debian/patches and adding it to debian/patches/series
> and
> running `debian/rules patch`, it applies cleanly (which is not the case
> for
> all of them):
>
> ```
> me@laptop:~/dev/debian/salsa/xorg-team/lib/mesa$ debian/rules patch
> dh patch --with quilt \
> --builddirectory=build/ \
> --buildsystem=meson
>dh_quilt_patch -O--builddirectory=build/ -O--buildsystem=meson
> Applying patch 07_gallium-fix-build-failure-on-powerpcspe.diff
> patching file src/gallium/include/pipe/p_config.h
>
> Applying patch path_max.diff
> patching file src/util/tests/cache_test.cpp
> Hunk #1 succeeded at 82 (offset 1 line).
> patching file src/util/tests/process_test.c
> patching file src/gallium/auxiliary/pipe-loader/pipe_loader.c
> Hunk #1 succeeded at 42 (offset -1 lines).
>
> Applying patch src_glx_dri_common.h.diff
> patching file src/glx/dri_common.h
> Hunk #1 succeeded at 57 (offset 2 lines).
>
> Applying patch bug102973-lima.diff
> patching file src/gallium/drivers/lima/lima_resource.c
>
> Now at patch bug102973-lima.diff
> ```
>
> HTH



-- 
Stuart Young (aka Cefiar)

Bug#1031805: fonts-ibm-plex: debian package does not seem to include japanese or korean fonts

[Edgar Yllescas]

Package: fonts-ibm-plex
Version: 6.1.1-1
Severity: normal
Tags: l10n

First thanks for packaging this font pack, as indicated on the title the debian
package does not seem provide the japanese or korean fonts from the upstream
package, altho not a deal breaker i do feel this impacts the usability for
those who want to use japanese or korean glyphs in text with the ibm plex font,
is this decision in lieu of waiting for the chinese fonts to have unified CJK
font files or is there another reason for this specific decision?

anyway best regards in any case.



-- System Information:
Debian Release: bookworm/sid
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-5-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

-- no debconf information

Bug#1031744: httpdirfs: usage of ubsan might introduce vulnerabilities

[Fufu Fang]

Hi Adrian,
I have pushed a commit to Github which removes the usage of UBSAN. I am
happy to go with this method. 

Do let me know if you prefer ASAN to be added alongside UBSAN, rather
than simply removing UBSAN.
Best wishes,
Fufu

Bug#1031744: httpdirfs: usage of ubsan might introduce vulnerabilities

[Fufu Fang]

Hi Adrian,
I am the author of httpdirfs. Do you reckon I should just remove ubsan,
or should I add asan into the Makefile? I reckon I should just remove
ubsan.
Best wishes,
Fufu
 
On Tue, 2023-02-21 at 21:41 +0200, Adrian Bunk wrote:
> Package: httpdirfs
> Version: 1.2.4-1
> Severity: serious
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Package: httpdirfs
> Version: 1.2.4-2
> Depends: ..., libubsan1 (>= 8), ...
> 
> 
> This is a bad idea not only due to slower execution,
> but might even introduce vulnerabilities:
> https://www.openwall.com/lists/oss-security/2016/02/17/9
> 
> While there are safe usages of ubsan, httpdirfs being the
> only package in the archive that uses ubsan but not asan
> is something that sounds wrong and underreviewed.
> 

Bug#1031160: reason for removal of zeroc-ice on armhf and arm64.

[Chris Knadle]

Greetings.

I'd like to know the status of mumble-server on armhf and arm64 and whether it 
can be restored for those architectures, because mumble server is commonly run 
on that hardware and is one one of the base expected programs for the FreedomBox 
project which has a number of hardware targets for armhf and arm64.


   https://freedombox.org/

If there's a way I can help let me know, and please keep me in the loop if 
feasible.

Thanks
   -- Chris

--
Chris Knadle
chris.kna...@coredump.us
(maintainer of mumble in Debian)

Adrian Bunk:

On Tue, Feb 14, 2023 at 11:56:40AM +, Peter Green wrote:

I recently became aware that mumble's build-dependencies were no longer
satisfiable on armhf due to a missing zeroc-ice. I looked at the build
logs for zeroc-ice and all were green. So I looked at the removal log
and found the following.


[Date: Sun, 12 Feb 2023 17:56:51 -] [ftpmaster: Scott Kitterman]
Removed the following packages from unstable:

libzeroc-ice-dev |  3.7.8-2.1 | arm64, armhf
libzeroc-ice3.7 |  3.7.8-2.1 | arm64, armhf
libzeroc-icestorm3.7 |  3.7.8-2.1 | arm64, armhf
mumble-server |1.3.4-4 | arm64, armhf
php-zeroc-ice |  3.7.8-2.1 | arm64, armhf
python3-zeroc-ice |  3.7.8-2.1 | arm64, armhf
zeroc-glacier2 |  3.7.8-2.1 | arm64, armhf
zeroc-ice-compilers |  3.7.8-2.1 | arm64, armhf
zeroc-ice-utils |  3.7.8-2.1 | arm64, armhf
zeroc-icebox |  3.7.8-2.1 | arm64, armhf
zeroc-icebridge |  3.7.8-2.1 | arm64, armhf
zeroc-icegrid |  3.7.8-2.1 | arm64, armhf
zeroc-icepatch2 |  3.7.8-2.1 | arm64, armhf
Closed bugs: 1031160

--- Reason ---
RoQA; openjfx no longer builds on arm64 and armhf, build-depends not available


This strikes me as strange in a couple of ways.

1. The only relationships of zeroc-ice to openjfx are in build-depends-indep
and in the binary dependencies of an arch all package. Afaict it is 
perfectly
normal for build-depends-indep and the binary dependencies of arch all
packages to only be satisfiable on a subset of the architectures where
2. Only one of the two binaries from the mumble source package was removed.

Was this removal just a mistake? or was there a reason behind it that I am not
seeing?


As requestor of #1031160 I would say this was a mistake,
perhaps due to

https://tracker.debian.org/pkg/openjfx
Issues preventing migration:
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
beast2-mcmc/2.7.3+dfsg-1/arm64 uninstallable
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
josm/0.0.svn18646+dfsg-1/arm64 uninstallable
∙ ∙ removing openjfx/11.0.11+0-1.1/arm64 from testing makes 
pdfsam/4.3.4-1/arm64 uninstallable

This will require a hint from the release team I have not yet requested,
since installability of binary-all packages is tested on amd64 and arm64
but there is no requirement that a binary-all package is installable on
arm64 and several are not.[1]

cu
Adrian

[1] https://release.debian.org/britney/testing_uninst.txt

Bug#1031804: nvtop: Crashes on multi-gpu system

[Jesse Rhodes]

Package: nvtop
Version: 3.0.1-1
Severity: important
X-Debbugs-Cc: je...@sney.ca

Dear Maintainer, 

This system has an integrated AMD GPU (Ryzen 7 7700X/"Raphael") and a discrete 
nVidia GPU (Geforce GTX 1660 Super), configured for PRIME offloading, with the 
proprietary nvidia driver, and monitors connected to the integrated.

I tried to run nvtop to verify that the Geforce was being used for a jitsi 
video conference, and it immediately crashed with the following output: 

nvtop: ./src/extract_gpuinfo_amdgpu.c:946: parse_drm_fdinfo_amd: Assertion 
`!cache_entry_check && "We should not be processing a client id twice per 
update"' failed.
Aborted (core dumped)

I also got a backtrace (attached). 

The message "processing a client id twice" indicates maybe it's not expecting 
to see statistics from two separate video devices? Though the man page at least 
implies it should support that. 

Including the PRIME environment variables '__NV_PRIME_RENDER_OFFLOAD=1 
__GLX_VENDOR_LIBRARY_NAME=nvidia' when running nvtop makes no difference.

This is not an Optimus laptop but rather a desktop that I'm using the same way. 
I would be interested to know if actual Optimus devices have the same issue, 
and if not, what the difference is. 

Please let me know if you need any more information, and thanks for your work! 

sney 

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.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 nvtop depends on:
ii  libc6 2.36-8
ii  libncursesw6  6.4-2
ii  libsystemd0   252.5-2
ii  libtinfo6 6.4-2

nvtop recommends no packages.

nvtop suggests no packages.

-- no debconf information
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[?1049h(B[?7h[?1h=[?25lnvtop: 
./src/extract_gpuinfo_amdgpu.c:946: parse_drm_fdinfo_amd: Assertion 
`!cache_entry_check && "We should not be processing a client id twice per 
update"' failed.

Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=, signo=signo@entry=6, 
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44  ./nptl/pthread_kill.c: No such file or directory.
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x77c2ed2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x77bdfef2 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x77bca472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x77bca395 in __assert_fail_base (fmt=0x77d3ea70 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x5556d180 "!cache_entry_check 
&& \"We should not be processing a client id twice per update\"", 
file=0x5556d138 "./src/extract_gpuinfo_amdgpu.c", line=946, 
function=) at ./assert/assert.c:92
#5  0x77bd8df2 in __GI___assert_fail 
(assertion=assertion@entry=0x5556d180 "!cache_entry_check && \"We should 
not be processing a client id twice per update\"", 
file=file@entry=0x5556d138 "./src/extract_gpuinfo_amdgpu.c", 
line=line@entry=946, function=function@entry=0x5556d410 
<__PRETTY_FUNCTION__.2> "parse_drm_fdinfo_amd") at ./assert/assert.c:101
#6  0x55567bce in parse_drm_fdinfo_amd (info=0x5558a2a0, 
fdinfo_file=0x5558ceb0, process_info=0x7fffd960) at 
./src/extract_gpuinfo_amdgpu.c:946
#7  0x5556456b in processinfo_sweep_fdinfos () at 
./src/extract_processinfo_fdinfo.c:178
#8  0x5556301e in gpuinfo_refresh_processes 
(devices=devices@entry=0x7fffdbb0) at ./src/extract_gpuinfo.c:247
#9  0x8fba in main (argc=, argv=) at 
./src/nvtop.c:265
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
tid = 
ret = 0
pd = 
old_mask = {__val = {93824992365256}}
ret = 
#1  0x77c2ed2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
No locals.
#2  0x77bdfef2 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
ret = 
#3  0x77bca472 in __GI_abort () at ./stdlib/abort.c:79
save_stage = 1
act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, 
sa_mask = {__val = {946, 93824993866816, 7, 140737351478368, 93824993866992, 
55834574848, 0, 140737488345000, 6025323250437744384, 5, 18446744073709551344, 
13, 93824992334136, 

Bug#1030882: RFS: dbus-c++/0.9.0-11 [QA] -- C++ API for D-Bus

[Thomas Uhle]

On Wed, 15 Feb 2023, Bastian Germann wrote:


On Wed, 8 Feb 2023 18:58:49 +0100 Thomas Uhle 
 wrote:
>  + Put libdbus-c++-ecore-1.so.* and libdbus-c++-glib-1.so.* in their own
>binary packages libdbus-c++-ecore-1-0 and libdbus-c++-glib-1-0 resp.
>to avoid pulling in e.g. Ecore libraries (and their dependencies) on
>systems where these libraries are not needed. (Closes: 1018772)

It is too late for bookworm. So please target experimental with the new binary 
packages.
If you want the other changes to get into bookworm, you should separate them 
into their own unstable revision.


I have reverted this change.


> Should I already change "UNRELEASED" into "unstable" in debian/changelog or 
> shall I leave this as it is?


Yes, please target unstable.


Done.

I have also updated the packaging copyright and added the missing 
Upstream-Contact to debian/copyright, bumped the watch file version 
to 4, and added debian/upstream/metadata.


All commits can be reviewed and pulled from

  https://salsa.debian.org/uhle/dbus-cplusplus .

These are the changes since last version:

  dbus-c++ (0.9.0-11) unstable; urgency=medium

* QA upload.
* Add 09_fix_build_order_and_linking.patch to change the order in which the
  libraries are built and to fix the underlinking issue. (Closes: #889114)
* Add 10_prevent_deadlock_on_timeout_expiration.patch to prevent a possible
  deadlock. (Closes: #956114)
* Add 11_fix_MessageIter__copy_data.patch to fix copying nested types in
  dicts and structs. (LP: #1098723)
* Add 12_autoconf_update.patch to avoid hard-to-read deprecation warnings
  that clutter the build logs.
* Update 01_host_name_max.patch because stdio.h is needed by perror().
* debian/control:
  + Add libdbus-1-dev to libdbus-c++-dev's dependencies. (Closes: #1018771)
  + Fix spelling and capitalization of the package descriptions.
  + Update Homepage to use https URL.
  + Mark libdbus-c++-bin as Multi-Arch: allowed. It fixes a regression since
version 0.9.0-9.
  + Add Rules-Requires-Root: no.
  + Bump Standards-Version to 4.6.2, no changes needed.
* debian/copyright:
  + Add Upstream-Contact, information copied from configure.ac.
  + Update packaging copyright according to debian/changelog and
debian/patches.
* debian/watch: Use uscan version 4.
* Add debian/upstream/metadata.

Best regards,

Thomas Uhle

Bug#1006529:

[Daniel Black]

2023-02-01  0:35:16 0 [Warning] mariadbd: Couldn't allocate 8388608
bytes (Large/HugeTLB memory page size 2097152); errno 22; continuing

I believe it is a kernel bug.

MariaDB is reading the page size from /sys/kernel/mm/hugepages.

  mapflag= MAP_PRIVATE | OS_MAP_ANON;
  mapflag|= my_bit_log2_size_t(large_page_size) << MAP_HUGE_SHIFT;

  ptr= mmap(NULL, aligned_size, PROT_READ | PROT_WRITE, mapflag, -1, 0);

aligned_size is a memory size that is an increment of the page size.

Per the mmap(2) man page, a ENOMEM, if memory cannot be allocated.

EINVAL (22) is totally unexpected. From man page, the only condition
satisfiable under the above conditions is length is too large (8M?
seems unlikely), or not aligned on the page boundary.

Given the page boundary was obtained from the /sys/kernel/mm/hugepages
I'm out of explanations. Can you validate that the pages sizes on the
directories in /sys/kernel/mm/hugepages are true to the architecture
specification.

I looked at kernel at mm/mmap.c and also can't see which path is
returning EINVAL

Bug#998105: chainer is still not supported (requires a cfg file as work-around)

[BiT dev]

On Tue, 21 Feb 2023 20:40:21 +0100 Sven Geuer  wrote:

> I still need to pin python3-keyring to use
> keyring.backends.SecretService.

What do you mean with "pin"? Installing an old version of python3-keyring 
(without the chainer) by pinning the ("old") DEB package (version)?

> Unfortunately BiT version 1.3.3 still fails with a version of python3-
> keyring offering keyring.backends.chainer.
> [...]

TLDR:
-

"chainer" is new and a "meta keyring" that decides internally which actually 
installed
keyring will be used using some heuristics.

"chainer" is not supported by BiT since the heuristics may choose another 
keyring in the future for any reason
and the wrong keyring is used then (which does not contain the stored 
credentials for BiT).

To solve (work around) this problem add a keyring config file to specify 
("pin") which keyring you want
to use instead of chainer, see these instructions here:

https://github.com/bit-team/backintime#non-working-password-safe-and-bit-forgets-passwords-keyring-backend-issues

-> Just use your prefered keyring in the config file:

default-keyring=keyring.backends.SecretService.Keyring



In full length:
---

To really use a a keyring two things must be installed:

1. A supported keyring software (debian package)
2. A python library that has a "driver" to enable the keyring of 1. for python

The BiT logs show that "secret service" is installed (satisfies above number 
1.):

>DEBUG: [common/tools.py:862 keyringSupported] Available keyring backends:
...
>DEBUG: [common/tools.py:865 keyringSupported] 
> keyring.backends.SecretService.Keyring (priority: 5)

The BiT logs also show that above number 2. is satisfied
("python3-secretstorage" is installed together with "python3-keyring" AFAIR 
since it has a "depends" relationship):

>DEBUG: [common/tools.py:899 keyringSupported] Available supported backends:
>  [,  'keyring.backends.kwallet.DBusKeyring'>]

Since newer "python3-keyring" versions use "chainer" by default now (which is 
not supported by BiT) no keyring is available in BiT:

> DEBUG: [common/tools.py:905 keyringSupported] No appropriate keyring found. 
> 'keyring.backends.chainer' can't be used with BackInTime



Outlook:
--

I think I should add a link to above "known issues" section to the debug output.

How the chainer issue could be fixed is described quite well in this feature 
request (add a GUI to select the keyring):

https://github.com/bit-team/backintime/issues/1330

Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

[Ian Jackson]

Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying 
--quilt=single"):
> I'm reluctant to introduce something else like this when we already have
> the git-debpush tags thing.  Hmm -- is there some reason why dgit
> couldn't put information in those tags in the same way?

Well, I'm a bit confused right now, but: I think a potential problem
is that if the branch format is converted without making a tag, things
can go wrong.  I'm not sure precisely how we avoided this with
git-debpush; part of the answer might be that git-debpush always works
in split brain mode.

> Right, but the pile of Emacs addons I maintain using dgit-maint-merge(7)
> will never hit any of those behaviours.  So it's a high cost to impose
> on someone in a position such as mine.

Hmmm.  I am very reluctant to recommend a practice which will induce
other tools to corrupt data.  Note that the corruption might be
experienced by downstreams (ie, people outside Debian) who are trying
to use dgit to manipulate packages from Debian.

Whereas inventing a dropping in debian/source/ seems straightforward
and precisely correct.  It's a description of the maintenance/update
practice that generated the tree you're working with, and (by
implication) how updates to it should be made.

Is there anything stopping us inventing an "unofficial"
debian/source/options entry ?
... tested it ...
It causes these messages:
dpkg-source: info: using options from dgit/debian/source/options: --wombat
dpkg-source: warning: --wombat is not a valid option for 
Dpkg::Source::Package::V1
which is probably too annoying.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#729402: 68 instead of 132: oneko man page misleading for modern DE

[Marcel Partap]

Hi,
was digging a bit into this because we've put oneka as a rare easter egg event into our distro ( 
c.f. https://github.com/fsfw-dresden/usb-live-linux/tree/main/features/config_desktop_cats ) and 
the cursor was not restored properly. Turns out the 132 in cursor 132 (aka 
"top_left_arrow") suggested by the oneko man page to be the default root cursor is not 
what works on modern DEs. There, we want 68 ("left_ptr") .. as in the xsetroot command 
Charles has given 9 years ago.

See https://tronche.com/gui/x/xlib/appendix/b/ for a complete visual list of X 
cursors...

The two attached patches should help, one documents the number 68 to be a more 
adequate choice for modern DEs, the other expands on Ricardo's 2013 patch and 
makes oneko restore left_ptr (68) by default.

Best Regards
Marcel--- oneko.man.orig	2023-02-21 15:51:16.0 +0100
+++ oneko.man	2023-02-21 18:39:13.419114942 +0100
@@ -93,7 +93,8 @@
 .TP
 .BI \-cursor " cursornumber"
 Specify a cursos number to set when quitting. For example, 132 is the
-default root cursor.
+default root cursor, while 68 (left_ptr) should be more fit for modern
+desktop environments.
 .SS Resources
 Application name is "neko"(or "tora") and class name is "Oneko".
 .TP
--- oneko.c.orig	2023-02-21 15:51:16.0 +0100
+++ oneko.c	2023-02-23 00:47:15.096002556 +0100
@@ -10,7 +10,7 @@
 #include "patchlevel.h"
 
 #include 
-int restoredCursor = 0; 
+int restoredCursor = DEFAULT_CURSOR; 
 
 /*
  *	グローバル変数
--- oneko.h.orig	2023-02-21 15:51:16.0 +0100
+++ oneko.h	2023-02-23 01:00:52.602587346 +0100
@@ -60,6 +60,8 @@
 #define	DEFAULT_FOREGROUND	"black"		/* フォアグラウンドカラー */
 #define	DEFAULT_BACKGROUND	"white"		/* バックグラウンドカラー */
 
+#define	DEFAULT_CURSOR		68		/* left_ptr */
+
 /*
  *	猫の状態定数
  */

Bug#1031586: deap: FTBFS in testing: AttributeError: module 'numpy' has no attribute 'bool'

[Andrey Rakhmatullin]

Control: tags -1 + upstream

This doesn't seem to be fixed or even reported upstream yet.
https://numpy.org/devdocs/release/1.20.0-notes.html#using-the-aliases-of-builtin-types-like-np-int-is-deprecated
needs to be followed to fix this.

Bug#1031803: in `request': undefined method `escape' for URI:Module (NoMethodError)

[Yaroslav Halchenko]

Package: ghi
Version: 1.2.0-1.1
Severity: normal

I just installed it since just now discovered, and at the first invocation got
a crash, so not sure how usable it is:

❯ ghi list
zsh: correct 'ghi' to 'gih' [nyae]? n
# NeurodataWithoutBorders/nwb-schema open issues
/usr/lib/ruby/vendor_ruby/ghi/client.rb:100:in `request': undefined 
method `escape' for URI:Module (NoMethodError)

  path = URI.escape path
^^^
from /usr/lib/ruby/vendor_ruby/ghi/client.rb:76:in `get'
from /usr/lib/ruby/vendor_ruby/ghi/commands/list.rb:148:in 
`block in execute'
from /usr/lib/ruby/vendor_ruby/ghi/formatting.rb:509:in `throb'
from /usr/lib/ruby/vendor_ruby/ghi/commands/list.rb:146:in 
`execute'
from /usr/lib/ruby/vendor_ruby/ghi/commands/command.rb:17:in 
`execute'
from /usr/lib/ruby/vendor_ruby/ghi.rb:80:in `execute'
from /usr/bin/ghi:4:in `'



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

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

Versions of packages ghi depends on:
ii  git   1:2.39.1-0.1
ii  ruby  1:3.1
ii  ruby-pygments.rb  2.3.0+ds-2.2

Versions of packages ghi recommends:
ii  less  590-1.1

ghi suggests no packages.

-- debconf-show failed

Bug#1027439: elementpath breaks python-xmlschema autopkgtest: 'XMLSchemaContext' object has no attribute 'iter'

[Andrey Rakhmatullin]

On Sat, Dec 31, 2022 at 03:34:33PM +0100, Paul Gevers wrote:
>   File 
> "/tmp/autopkgtest-lxc.0cuhskff/downtmp/build.pHW/src/xmlschema/testing/_builders.py",
> line 128, in check_xsd_file
> xpath_context_elements = [x for x in context.iter() if isinstance(x,
> XsdValidator)]
>  
> AttributeError: 'XMLSchemaContext' object has no attribute 'iter'
I think this is fixed in
https://github.com/sissaschool/xmlschema/commit/52c31478dc2dcd0e2fdbaaa45d17de7913d36906
(included in xmlschema 2.0.0).

Bug#1031450: gearmand: FTBFS: ld: /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so: undefined reference to `memcached_server_minor_version'

[Andrey Rakhmatullin]

Control: reassign -1 libmemcachedutil2 1.1.3-2
Control: affects -1 src:gearmand

> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_server_minor_version'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_server_instance_by_position'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_behavior_set'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_set_sasl_auth_data'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_free'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_flush'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_clone'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_server_major_version'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_version'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_behavior_get'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_server_micro_version'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_server_cursor'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_server_error_return'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_stat_free'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_server_error'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_create'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_stat'
> > /usr/bin/ld: 
> > /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
> >  undefined reference to `memcached_server_add'

It's indeed underlinked. I assume it needs to be linked with
libmemcached.so.11.

Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

[Sean Whitton]

Hello,

On Wed 22 Feb 2023 at 09:45PM GMT, Ian Jackson wrote:

> Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as 
> implying --quilt=single"):
>> How about having single-debian-patch imply --quilt=single in the absence
>> of any other setting or command line argument for the quilt mode?
>> Then in the docs we would say that it is a good idea to use only the git
>> configuration value, but that this is another option if you prefer it.
>>
>> This is still better than the previous situation because dgit will undo
>> some problems created by single-debian-patch (right?).
>
> The usual reason for eschewing in-tree directions about quilt format
> is that the tree can't (mustn't) tell you if it's patches-applied or
> not.  I think it would be OK for the tree to influence *how* patches
> are made (ie, choose between --quilt=linear, --quilt=single, etc.)

Yes, this is a good distinction.

> There is also the fact that it would have an effect on dgit's
> behaviour for an NMUer, but I think that's OK for this.
>
> So your idea has merit.
>
> However, do we want to have people put single-debian-patch in the
> source tree ?  That has such weird dpkg-source behaviours.

Right, but the pile of Emacs addons I maintain using dgit-maint-merge(7)
will never hit any of those behaviours.  So it's a high cost to impose
on someone in a position such as mine.

> Ideally we would do something that would influence dgit, but not
> dpkg-source.  So maybe we could put some *other* dropping in the
> source tree?

I'm reluctant to introduce something else like this when we already have
the git-debpush tags thing.  Hmm -- is there some reason why dgit
couldn't put information in those tags in the same way?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031802: libvirt-daemon-driver-lxc: Incorrect dependencies

[Vincent Danjean]

Package: libvirt-daemon-driver-lxc
Version: 9.0.0-1
Severity: important

After doing a partial upgrade of my system (i.e. only libvirt-daemon
with its required dependencies), libvirtd refused to start.
In systemd journal, I can see:

févr. 23 00:53:32 eyak libvirtd[3010536]: internal error: Failed to load module 
'/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_lxc.so': 
/usr/lib/x86_64-linux-gnu/libvirt/connection-driver/libvirt_driver_lxc.so: 
undefined symbol: fuse_new_31, version FUSE_3.1

Upgrading libfuse3-3 from 3.12.0-1 to 3.14.0-2 fixed the problem.
libvirt-daemon-driver-lxc should bump its dependency on libfuse3-3.
For now, there is:
Depends: [...] libfuse3-3 (>= 3.2.3) [...]

If this dependency is automaticcaly generated, then it probably
means there is a bug in the libfuse3-3 package (its shlibs file)

  Regards
Vincent


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

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

Versions of packages libvirt-daemon-driver-lxc depends on:
ii  libblkid1   2.38.1-4
ii  libc6   2.36-6
ii  libcap-ng0  0.8.3-1+b2
ii  libfuse3-3  3.14.0-2
ii  libgcc-s1   12.2.0-10
ii  libglib2.0-02.74.2-1
ii  libtirpc3   1.3.3+ds-1
ii  libvirt-daemon  9.0.0-1
ii  libvirt09.0.0-1

libvirt-daemon-driver-lxc recommends no packages.

libvirt-daemon-driver-lxc suggests no packages.

-- no debconf information

Bug#1031786: logcheck: Filtering not working with entries from journald

[Mathias Gibbens]

Control: severity -1 normal

  You can disable the checking of the systemd journal:

> $ sudo cat /etc/logcheck/logcheck.logfiles.d/journal.logfiles
> ## The word 'journal' tells logcheck to check log entries in the
> ## systemd journal
> 
> # (This is enabled by default, but if you do not want to check entries
> # in the journal you can comment out the next line)
> journal

  I did have to update some of my local rules to account for the format
of the journal entries, but it wasn't too hard. From your example,
something like this should work for both:

> meinfjell courierd(\[[[:digit:]]+\])?: Installing uucp

Mathias


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

Bug#1028543: lutris: Application not shown in GNOME's application launcher without /usr/games in $PATH.

[Jaycee Santos]

Package: lutris
Version: 0.5.12-1
Followup-For: Bug #1028543
X-Debbugs-Cc: jlsan...@protonmail.com

I also ran into this problem recently (being unable to start lutris).
This gitlab issue seems somewhat relevant[1]. I think the actual bug is caused
by gdm3.

After finding your bug report, I was able to find out that /usr/games was also
missing from my $PATH under certain circumstances. The circumstances were
running a wayland kde plasma session that was launched through GDM on a Debian
system where games are in /usr/games. I was also unable to start five-or-more
or gnome-chess, as those are also located in /usr/games.

However, I am able to start lutris under GNOME through GDM; my PATH appears to 
be
set properly: `/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games`.

Whereas SDDM handles the PATH environment variable properly, something about
specifically launching the plasma wayland session (or sway) through GDM leads
to PATH being set to:
`/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin`.

The issue persists on a fresh install of Debian 12 bookworm.

I still do not know why this happens, but I assume it is related to GDM's 
handling
of wayland sessions. 

Jaycee

1: https://gitlab.gnome.org/GNOME/gdm/-/issues/692

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

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
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 lutris depends on:
ii  cabextract1.9-3
ii  curl  7.88.1-1
ii  fluid-soundfont-gs3.1-5.3
ii  gir1.2-gtk-3.03.24.36-4
ii  gir1.2-webkit2-4.12.38.5-1
ii  mesa-utils8.5.0-1
ii  p7zip 16.02+dfsg-8
ii  psmisc23.6-1
ii  python3   3.11.2-1
ii  python3-dbus  1.3.2-4+b1
ii  python3-distro1.8.0-1
ii  python3-gi3.42.2-3+b1
ii  python3-lxml  4.9.2-1+b1
ii  python3-magic 2:0.4.26-3
ii  python3-pil   9.4.0-1.1+b1
ii  python3-requests  2.28.1+dfsg-1
ii  python3-setproctitle  1.3.1-1+b2
ii  python3-yaml  6.0-3+b2
ii  unzip 6.0-28
ii  x11-xserver-utils 7.7+9+b1

Versions of packages lutris recommends:
ii  gvfs-backends1.50.3-1
ii  libwine-development  7.22~repack-2
ii  python3-evdev1.6.1+dfsg-1+b1
ii  winetricks   20220411-1

Versions of packages lutris suggests:
pn  gamemode   
ii  gamescope  3.11.49-1

-- no debconf information

Bug#1031786: logcheck: Filtering not working with entries from journald

[Richard Lewis]

On Wed, 22 Feb 2023, 17:51 Helge Kreutzmann,  wrote:

> Package: logcheck
> Version: 1.4.1
> Severity: grave
> Justification: renders package unusable
>
> The change for #1025719 broke logcheck massively.
>
> I've extensivly tuned logcheck files which nicely filter out lots of
> messages (see statistics at the end).
>
> Now I see them all again (only those comming from the journal).
>
> I don't see any information what I should do for migration.
>

sorry about that.

i agree there is a bug in the documentation - we should add a NEWS.Debian
entry - my fault i simply forgot. But this is hardly a grave bug.


 It is trivial to disable checking of the journal. just edit

/etc/logcheck/logcheck.logfiles.d/journal.logfiles

and add a # before the word  "journal".

this will take effect on the next run of logcheck. This is also documented
in that file --- as a heavy logcheck user i would recommend reading new
config files when installing a new version. (We dont plan more changes for
bookworm but in the longer-term there could be some changes to make
logcheck more efficient)

HOWEVER,  you might want to consider adjusting to this in the long-term -
if your log messages are different in the journal and syslog then not
checking the journal means you are by definition not being informed of
things. That would rather seem to defeat the point of monitoring the log
messges. But it is of course up to you.


But given debian has demoted syslog logcheck does need to "move with the
times" and support systemd by default - we will not force anyone to adapt,
but we cant predict what settings work for you.


Let's use a trivial example. The following harmless message is emitted
> by courier to the journal:
> Feb 22 16:37:40 meinfjell courierd[401638]: Installing uucp
>
> In syslog this is:
> syslog:2023-02-22T14:37:40.491690+00:00 meinfjell courierd: Installing uucp
>
> I have the following in
> /etc/logcheck/ignore.d.server:
> meinfjell courierd: Initializing uucp


Is this a typo?

this rule is not going to filter that message regardless of whether it is
in the journal or syslog. one says initiailizing one says installing
(Maybe courier changed its logging? )

I also note you have the "new" timestamp format for syslog- that's an
rsyslog change and nothing to do with logcheck. I believe you can revert
that change quite easily as well.


As you can see, the message from the journal is slightly different
> than from syslog, breaking tons of rules.
>


that sounds like a bug in courier. As above you can choose to only check
one source of messages. Most programs put the same messages in both in my
experience.


> For statistics:
> On my local system, I have 11396 lines of rules, on my server system
> currently 2721 (I'm in the processing of setting this up, so this will
> grow).
>

wow! but yes, logcheck-databse does need a lot of manual tuning to be
useful. (I am surprised it copes with thay many lines tbh!)

sorry again for the inconvenience.

Bug#1031450: gearmand: FTBFS: ld: /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so: undefined reference to `memcached_server_minor_version'

[Sergio Durigan Junior]

Control: tags -1 + patch

On Friday, February 17 2023, Lucas Nussbaum wrote:

> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
>
> Relevant part (hopefully):
>> /bin/bash ./libtool --tag=CXX --mode=link c++ -g -O2
>> -ffile-prefix-map=/<>=. -fstack-protector-strong
>> -Wformat -Werror=format-security -Wno-unknown-pragmas -Wno-pragmas
>> -Wall -Wextra -Wno-attributes -Wvarargs -Waddress -Warray-bounds
>> -Wchar-subscripts -Wcomment -Wctor-dtor-privacy -Wfloat-equal
>> -Wformat=2 -Wformat-y2k -Wmaybe-uninitialized
>> -Wmissing-field-initializers -Wlogical-op -Wnon-virtual-dtor
>> -Wnormalized=id -Woverloaded-virtual -Wpointer-arith
>> -Wredundant-decls -Wshadow -Wsign-compare -Wstrict-overflow=1
>> -Wswitch-enum -Wtrampolines -Wundef -funsafe-loop-optimizations
>> -Wc++11-compat -Wclobbered -Wunused -Wunused-result
>> -Wunused-variable -Wunused-parameter -Wunused-local-typedefs
>> -Wwrite-strings -Wformat-security -fwrapv -pipe -fPIE -pie
>> -Wsizeof-pointer-memaccess -Wpacked -std=c++0x -Wl,-z,relro
>> -Wl,-z,now -Wl,--as-needed -o t/httpd tests/httpd_test.o
>> libgearman/libgearman.la libtest/libtest.la tests/libstartworker.la
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_server_minor_version'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_server_instance_by_position'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_behavior_set'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_set_sasl_auth_data'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_free'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_flush'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_clone'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_server_major_version'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_version'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_behavior_get'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_server_micro_version'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_server_cursor'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_server_error_return'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_stat_free'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_server_error'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_create'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_stat'
>> /usr/bin/ld: 
>> /usr/lib/gcc/x86_64-linux-gnu/12/../../../x86_64-linux-gnu/libmemcachedutil.so:
>>  undefined reference to `memcached_server_add'
>> collect2: error: ld returned 1 exit status

The problem happens because of the order of the "-l" parameters during
link-time.  libmemcachedutil depends on libmemcached, and as such should
be specified first in the command line.

I filed https://github.com/gearman/gearmand/pull/365 upstream and I'm
inlining a patch that fixes the problem for me.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff --git a/debian/changelog b/debian/changelog
index c274aba..4065db1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+gearmand (1.1.19.1+ds-3) UNRELEASED; urgency=medium
+
+  [ Jenkins ]
+  * Apply multi-arch hints. + libgearman-doc: Add Multi-Arch: foreign.
+Changes-By: apply-multiarch-hints
+
+  [ Sergio Durigan Junior ]
+  * d/p/0006-Fix-order-of-linking.patch:
+Adjust linking order for 

Bug#1031801: libduktape.so.207: undefined symbol: log2

[Daniel Albers]

Package: libduktape207
Version: 2.7.0-1+b1
Severity: critical
Justification: breaks unrelated software

Dear Maintainer,

with this package version installed starting e.g. polkitd fails with:

/usr/lib/polkit-1/polkitd: symbol lookup error:
  /usr/lib/x86_64-linux-gnu/libduktape.so.207: undefined symbol: log2

It appears that libduktape.so.207 is missing a link against libm:

$ ldd /usr/lib/x86_64-linux-gnu/libduktape.so.207
linux-vdso.so.1 (0x7ffda6777000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb0fce14000)
/lib64/ld-linux-x86-64.so.2 (0x7fb0fd04c000)

Recompiling and linking with -lm fixes the issue.

Cheers
Daniel


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable-security'), (700, 
'stable'), (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages libduktape207 depends on:
ii  libc6  2.36-8

libduktape207 recommends no packages.

libduktape207 suggests no packages.

-- no debconf information

Bug#1031800: mmdebstrap: --keyring doesn't work properly

[Dima Kogan]

Package: mmdebstrap
Version: 1.3.1-2
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 


Hi. I'm using mmdebstrap to bootstrap an install that uses the normal
Debian repos AND my own repo. My repo is signed with a key that lives in
$PWD/keys/something.gpg. I pass --keyring=$PWD/keys as suggested in the
docs, but this doesn't work for some mysterious reason. No clear
diagnostics are avaible, with --verbose saying nothing extra. This is
what I see:

  $ sudo mmdebstrap\
--architectures=arm64  \
--keyring=$PWD/keys\
--aptopt 'Acquire::https::MY_REPO_DOMAIN::Verify-Peer "false"' \
bookworm   \
bookworm-tst   \
http://deb.debian.org/debian   \
http://MY_REPO_DOMAIN/public/debian/bookworm

  I: automatically chosen mode: root
  I: arm64 cannot be executed natively, but transparently using qemu-user 
binfmt emulation
  I: finding correct signed-by value...
  I: automatically chosen format: directory
  I: running apt-get update...
  Get:1 https://MY_REPO_DOMAIN/public/debian/bookworm bookworm InRelease [5136 
B]
  Get:2 http://deb.debian.org/debian bookworm InRelease [177 kB]
  Err:1 https://MY_REPO_DOMAIN/public/debian/bookworm bookworm InRelease
The following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 221CA67104340B68
  Get:3 http://deb.debian.org/debian bookworm/main arm64 Packages [8909 kB]
  Reading package lists...
  W: GPG error: https://MY_REPO_DOMAIN/public/debian/bookworm bookworm 
InRelease: The following signatures couldn't be verified because the public key 
is not available: NO_PUBKEY 221CA67104340B68
  E: The repository 'http://MY_REPO_DOMAIN/public/debian/bookworm bookworm 
InRelease' is not signed.
  E: apt-get update --error-on=any -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false 
failed
  I: main() received signal PIPE: waiting for setup...
  E: mmdebstrap failed to run

This should work, but it doesn't. I used sysdig to confirm that
something is indeed looking in $PWD/keys/ and something is indeed
calling read() on the relevant key. I have also confirmed that if I copy
my keys to /etc/apt/trusted.gpg.d/ then it does work properly. But I
don't want to do that. Ideally I'd like mmdebstrap to grab all the keys
in $PWD/keys and add them to /etc/apt/trusted.gpg.d/ in the chroot, but
NOT on the host machine. Any clear way to do that? Any debugging tricks
I'm missing?

Thanks!

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), 
(500, 'stable')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: armhf, armel

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

Versions of packages mmdebstrap depends on:
ii  apt  2.5.2
ii  perl 5.36.0-4
ii  python3  3.10.6-1

Versions of packages mmdebstrap recommends:
pn  arch-test
pn  fakechroot   
ii  fakeroot 1.29-1
ii  gpg  2.2.35-3
ii  libdistro-info-perl  1.1
ii  libdpkg-perl 1.21.19
ii  mount2.38.1-1
pn  uidmap   

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.5.2
ii  binfmt-support 2.2.2-1
ii  ca-certificates20211016
ii  debootstrap1.0.127
ii  distro-info-data   0.54
ii  dpkg-dev   1.21.19
pn  genext2fs  
ii  perl-doc   5.36.0-4
pn  qemu-user  
ii  qemu-user-static   1:7.0+dfsg-7+b1
pn  squashfs-tools-ng  

-- no debconf information

Bug#1023926: Missing dependeny on libavahi-client-dev

[Thorsten Alteholz]

Hi Jakob,

On Wed, 22 Feb 2023, Jakob Haufe wrote:

Yes, but this doesn't work for me. See attached log.


from the changelog of pkgconf:
 pkgconf (1.8.1-1) unstable; urgency=high

  * Apply an upstream patch to validate the dependency graph when --exists
is specified (Closes: #1026781).

and I was still using version 1.8.0-12 without that validation.
So, problem solved, next step fixing bug ...

  Thorsten

Bug#1030453: devpi-common: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.11 returned exit code 13

[Andrey Rakhmatullin]

Control: tags -1 + upstream

https://github.com/devpi/devpi/issues/939
https://github.com/devpi/devpi/issues/948

"The latest packaging breaks devpi and until the next major version one
has to use a version <22. See #939

I have a fix ready for latest packaging, but that might change behaviour
with sorting, which is why I hold it back for the next major release."

As far as I can see the fix is not even in the main branch yet (at least
the one that was proposed in
https://github.com/devpi/devpi/issues/939#issuecomment-1347924626 ).

Bug#1030495: navarp: FTBFS: AttributeError: module 'numpy' has no attribute 'complex'

[Andrey Rakhmatullin]

Control: reassign -1 python3-igor 0.3-4
Control: tags -1 + upstream

On Sat, Feb 04, 2023 at 08:56:51AM +0100, Lucas Nussbaum wrote:
> >   File "/usr/lib/python3/dist-packages/igor/binarywave.py", line 110, in 
> > 
> > 1:_numpy.complex, # NT_CMPLX, makes number complex.
> >   ^^
> >   File "/usr/lib/python3/dist-packages/numpy/__init__.py", line 284, in 
> > __getattr__
> > raise AttributeError("module {!r} has no attribute "
> > AttributeError: module 'numpy' has no attribute 'complex'
Reassigning.
The upstream repo links needs to be updated to
http://git.tremily.us/?p=igor.git but the project is dead since 2016
anyway.
The fix needs to follow 
https://numpy.org/devdocs/release/1.20.0-notes.html#using-the-aliases-of-builtin-types-like-np-int-is-deprecated

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[FC Stegerman]

* Sam Hartman  [2023-02-22 23:33]:
[...]
> >> A tool for glamorous shell scripts. Leverage the power of
> >> Bubbles (https://github.com/charmbracelet/bubbles) and Lip
> >> Gloss (https://github.com/charmbracelet/lipgloss) in your
> >> scripts and aliases without writing any Go code!
[...]
> >> Gum provides highly configurable, ready-to-use utilities to
> >> help you write  useful shell scripts and dotfiles aliases
> >> with just a few lines of code.
> 
> Antonio> This last paragraph above looks like a good enough package
> Antonio> description.  Save everything else for an upstream README
> Antonio> installed on /usr/share/doc/gum/, or some other type of
> Antonio> documentation.
> 
> I disagree.

With what?  Antonio said "last paragraph".  The links to Bubbles and
Lip Gloss are not in the last paragraph.  The last paragraph does look
alright to me, if a bit vague on what kind of utilities, so a brief
description of Bubbles and Lip Gloss does seem useful to add.

> I should not have to chase down links to  websites to understand a
> description

No disagreement there.

> Please include a phrase or two describing each of bubbles and gloss.

No disagreement there -- if they are mentioned in the description.

- FC

Bug#1019841: Please scratch the last message

[Michael Fritscher]

Sorry for the noise :-( Please scratch the last message - somehow the
diff got lost. I'rebuilding now.

Bug#1022073: pam-u2f: new upstream release 1.2.1 available

[Enrique Garcia]

Package: libpam-u2f
Version: 1.1.0-1.1+b1
Followup-For: Bug #1022073
X-Debbugs-Cc: cqu...@arcor.de

The following blog from yubico, who are the developers of libpam-u2f recommends
using at least version 1.1.1 since there is a risk of local PIN bypass:

https://support.yubico.com/hc/en-us/articles/360016649099-Ubuntu-Linux-Login-
Guide-U2F

The issue is in libpam-u2f 1.1.0, which is exactly the version shipped right
now with Debian (bullseye, bookworm, sid)


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

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

Versions of packages libpam-u2f depends on:
ii  libc6   2.36-8
ii  libfido2-1  1.12.0-2
ii  libpam0g1.5.2-6
ii  libssl3 3.0.8-1

Versions of packages libpam-u2f recommends:
ii  pamu2fcfg  1.1.0-1.1+b1

libpam-u2f suggests no packages.

-- no debconf information

Bug#1029439: feynmf: FTBFS in bookworm (I can't open file `fmfsamp4')

[Hilmar Preuße]

On 2/21/23 22:00, James Addison wrote:

Hi all,


I'm adding the 'help' tag to this bug, and am cc'ing the debian-tex-maint list,
because it feels like extra brainpower could aid in figuring this one out more
quickly.

A brief recap of this bug so far, for folks reading the list:

   * the feynmf Debian package is failing to build in testing (bookworm)
   * the bug may somehow be related to the mflogo TeX package
   * successful build logs are available on buildd.debian.org for comparison


Sorry, I'm not of any help here. At the first glance we look at a syntax
error in the feynmf.dtx file however I'm wondering why this did not pop
within the last > 25 years. As feynmf upstream seems to be dead I
suggest to contact the people from https://tex.stackexchange.com/ . I
already had a short look, but I could not find a posting describing this
issue.

Therefore I suggest to ask there; they should be able at least to
clarify if the issue is located in the LaTeX3 code or in feynmf.

Sorry,
  Hilmar
--
Testmail

Bug#1031799: cmake-data: cmake does not search multiarch paths for HIP

[Cordell Bloor]

Package: cmake-data
Version: 3.25.1-1
Severity: normal
X-Debbugs-Cc: c...@slerp.xyz, debian...@lists.debian.org

Dear Maintainer,

It is not possible to use CMake's HIP language support together with
the Debian package for HIP. Consider this sample project:

CMakeLists.txt:

cmake_minimum_required(VERSION 3.22)
project(example LANGUAGES HIP)
add_executable(ex main.hip)

main.hip:

#include 
#include 
#include 

#define CHECK_HIP(expr) do {  \
  hipError_t result = (expr); \
  if (result != hipSuccess) { \
fprintf(stderr, "%s:%d: %s (%d)\n",   \
  __FILE__, __LINE__, \
  hipGetErrorString(result), result); \
exit(EXIT_FAILURE);   \
  }   \
} while(0)

__global__ void sq_arr(float *arr, int n) {
  int tid = blockDim.x*blockIdx.x + threadIdx.x;
  if (tid < n) {
arr[tid] = arr[tid] * arr[tid];
  }
}

int main() {
  enum { N = 5 };
  float hArr[N] = { 1, 2, 3, 4, 5 };
  float *dArr;
  CHECK_HIP(hipMalloc(, sizeof(float) * N));
  CHECK_HIP(hipMemcpy(dArr, hArr, sizeof(float) * N, 
hipMemcpyHostToDevice));
  sq_arr<<>>(dArr, N);
  CHECK_HIP(hipMemcpy(hArr, dArr, sizeof(float) * N, 
hipMemcpyDeviceToHost));
  for (int i = 0; i < N; ++i) {
printf("%f\n", hArr[i]);
  }
  CHECK_HIP(hipFree(dArr));
  return 0;
}

Build log:

# apt install hipcc cmake
# HIPFLAGS="--rocm-path=/usr 
--rocm-device-lib-path=/usr/lib/x86_64-linux-gnu/amdgcn/bitcode" \
HIPCXX=clang++-15 cmake -S. -Bbuild --debug-output \
-DCMAKE_LIBRARY_ARCHITECTURE=x86_64-linux-gnu
Running with debug output on.
-- The HIP compiler identification is Clang 15.0.7
   Called from: [3] 
/usr/share/cmake-3.25/Modules/CMakeDetermineCompilerId.cmake
[2] 
/usr/share/cmake-3.25/Modules/CMakeDetermineHIPCompiler.cmake
[1] /root/CMakeLists.txt
CMake Error at 
/usr/share/cmake-3.25/Modules/CMakeDetermineHIPCompiler.cmake:106 (message):
  The ROCm root directory:

   /usr

  does not contain the HIP runtime CMake package, expected at:

   /usr/lib/cmake/hip-lang/hip-lang-config.cmake

Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


   Called from: [2] 
/usr/share/cmake-3.25/Modules/CMakeDetermineHIPCompiler.cmake
[1] /root/CMakeLists.txt
-- Configuring incomplete, errors occurred!

This error is because when provided as part of the libamdhip64-dev
package, the HIP runtime CMake package is installed to
/usr/lib/$(DEB_HOST_MULTIARCH)/cmake/hip-lang/hip-lang-config.cmake
CMake should probably check both locations to ensure compatibility with
the layout of both the upstream ROCm project and the Debian HIP package.

In total, this path appears in three places:

/usr/share/cmake-3.25/Modules/CMakeDetermineHIPCompiler.cmake:105
/usr/share/cmake-3.25/Modules/CMakeDetermineHIPCompiler.cmake:110
/usr/share/cmake-3.25/Modules/CMakeHIPInformation.cmake:145

Sincerely,
Cory Bloor

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/32 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

-- no debconf information

Bug#1031798: libsepol: Inaccurate copyright file

[Bastian Germann]

Source: libsepol
Version: 3.4-2
Severity: serious
Control: tags -1 patch

The d/copyright file points to a 404 URL as source. The Zlib license is missing.
Also, it does not present all copyright information that is contained in the 
source.
I have a fix for these Policy violations attached in the machine-readable 
format.Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Comment:
 This is the Debian package for libsepol.
 .
 This package was debianized by Russell Coker  on
 Fri, 20 Aug 2004 17:26:18 +1000.
Source: https://github.com/SELinuxProject/selinux/wiki/Releases

Files: *
Copyright: libsepol is
 Copyright (C) 2003, 2004 Stephen Smalley 
 Copyright (C) 2003-2007  Red Hat, Inc.
 Copyright (C) 2004, 2005 Trusted Computer Solutions, Inc.
 Copyright (C) 2003-2008, 2011 Tresys Technology, LLC
 Copyright (C) 2017 Mellanox Techonolgies Inc.
 Copyright (c) 2008 NEC Corporation
License: LGPL-2.1+
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
 .
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Lesser General Public License for more details.
 .
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
Comment:
 On Debian GNU/Linux systems, the complete text of the Lesser GNU General
 Public License version 2.1 can be found in 
`/usr/share/common-licenses/LGPL-2.1'.

Files: cil/test/unit/CuTest.*
Copyright: (c) 2003 Asim Jalis
License: Zlib
 This software is provided 'as-is', without any express or implied
 warranty. In no event will the authors be held liable for any damages
 arising from the use of this software.
 .
 Permission is granted to anyone to use this software for any purpose,
 including commercial applications, and to alter it and redistribute it
 freely, subject to the following restrictions:
 .
 1. The origin of this software must not be misrepresented; you must not
 claim that you wrote the original software. If you use this software in
 a product, an acknowledgment in the product documentation would be
 appreciated but is not required.
 .
 2. Altered source versions must be plainly marked as such, and must not
 be misrepresented as being the original software.
 .
 3. This notice may not be removed or altered from any source
 distribution.

Files: debian/*
Copyright: © 2005-2008, Manoj Srivastava 
License: GPL-2
The Debian specific changes are distributed under the terms of the
GNU General Public License, version 2.
 .
A copy of the GNU General Public License is also available at
http://www.gnu.org/copyleft/gpl.html>.  You may also obtain
it by writing to the Free Software Foundation, Inc., 51 Franklin
St, Fifth Floor, Boston, MA 02110-1301 USA
Comment:
 On Debian GNU/Linux systems, the complete text of the GNU General
 Public License version 2 can be found in `/usr/share/common-licenses/GPL-2'.

Files: man/*man8/chkcon.8
   man/man8/genpolusers.8
Copyright: (c) 1997 Manoj Srivastava 
License: GPL-2+
This is free documentation; you can redistribute it and/or
modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2 of
the License, or (at your option) any later version.
Comment:
 On Debian GNU/Linux systems, the complete text of the GNU General
 Public License version 2 can be found in `/usr/share/common-licenses/GPL-2'.

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Sam Hartman]

> "Antonio" == Antonio Terceiro  writes:

Antonio> On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote:
>> 
>> On 2/21/23 15:03, Ryan Kavanagh wrote:
>> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
>> > > Description : A tool for glamourous shell scripts
>> > > 
>> > > A tool for glamorous shell scripts. Leverage the power of
>> Bubbles and > > Lip Gloss in your scripts and aliases without
>> writing any Go code!  > This long description does not provide
>> users with enough information to > understand what the package
>> does. What are "Bubbles" and "Lip Gloss" in > a shell script?
>> What is a "glamourous shell script"?
>> > 
>> > It would be helpful if the package's long description satisfied
>> §3.4.2 > of the Debian Policy Manual [0]:
>> > 
>> > The description field needs to make sense to anyone, even
>> people who > have no idea about any of the things the package
>> deals with. [3]
>> > 
>> > [...]
>> > 
>> > [3] The blurb that comes with a program in its announcements
>> and/or > README files is rarely suitable for use in a
>> description. It is > usually aimed at people who are already in
>> the community where the > package is used.
>> > 
>> > Best wishes, > Ryan
>> > 
>> > [0]
>> 
https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description
>> > 
>> 
>> The package description will be this or close to it:

Antonio> That is just too long, please don't.

>>  A tool for glamorous shell scripts. Leverage the power of
>> Bubbles  (https://github.com/charmbracelet/bubbles) and Lip Gloss
>>  (https://github.com/charmbracelet/lipgloss) in your scripts and
>> aliases  without writing any Go code!   .   Tutorial  .   Gum
>> provides highly configurable, ready-to-use utilities to help you
>> write  useful shell scripts and dotfiles aliases with just a few
>> lines of code.

Antonio> This last paragraph above looks like a good enough package
Antonio> description.  Save everything else for an upstream README
Antonio> installed on /usr/share/doc/gum/, or some other type of
Antonio> documentation.

I disagree.
I should not have to chase down links to  websites to understand a
description
Please include a phrase or two describing each of bubbles and gloss.

Bug#852226: dgit: Want `dgit setup-maint-merge`

[Sean Whitton]

Hello,

On Sun 22 Jan 2017 at 09:28AM -07, Sean Whitton wrote:

> Package: dgit
> Version: 3.6
> Severity: wishlist
>
> A simple helper which would
>
> * do nothing (except maybe print a warning) if source format 1.0
> * otherwise,
>   - ensure relevant options present in d/source/options
>   - update d/source/patch-header to match latest version in the manpage
>   - nuke any existing d/patches so that the next dgit quilt-fixup will
> normalise d/patches (this might be unnecessary: perhaps
> single-debian-patch will already ensure normalisation)
>
> I think this should be a dgit subcommand because the -maint-merge
> workflow shouldn't be used without dgit (since there should be a
> canonical, non-rewinding git history that is updated with every upload).

This has been almost entirely obsoleted by recent releases.

I wonder, though: could --quilt=single automatically add auto-commit ?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1023632: Please package latest upstream version 4.0.0

[Jeremy Bícha]

On Tue, Nov 8, 2022 at 4:15 AM Simon McVittie  wrote:
> On Mon, 07 Nov 2022 at 23:41:16 +0100, Michael Biebl wrote:
> > The latest upstream version appears to be 4.0.0, so it would be nice to
> > have this version in unstable / bookworm.
>
> This is a parallel-installable API and ABI break which requires app
> porting, so it should probably be packaged as a new src:gcr4 instead of
> as a continuation of src:gcr.

Do either of you want to review my gcr4 packaging?

https://salsa.debian.org/gnome-team/gcr4

Sorry, this was on my todo list but obviously not high enough. I was
annoyed that we will need to keep two versions of gcr in Debian for a
while. Some apps will probably need to code copy (like
evolution-data-server) did to stop using the old gcr. There was some
discussion on https://gitlab.gnome.org/GNOME/gcr/-/issues/100

I'm going to try to get upstream to review
https://gitlab.gnome.org/GNOME/gcr/-/merge_requests/127 this week
since it affects the binary package names we will use.

Thank you,
Jeremy Bícha

Bug#1031275: [PATCH v3 1/6] man2/: use IEC or ISO multiples to clarify long numeric digit strings

[Rob Landley]

On 2/21/23 19:34, Alex Colomar wrote:
> Hi Rob,
> 
> On 2/21/23 18:00, Rob Landley wrote:
>> If you're going to tell people to learn something new: 1<<10 is a kilobyte,
>> 1<<20 is a megabyte, 1<<30 is a gigabyte, and so on. I've sometimes used
>> 16*(1<<30) for clarity.
> 
> That's nice, and for code it might be a good idea (although you have to 
> be careful, since those are all ints, and 16*(1<<30) is going to 
> overflow, so you'll need 16L).  For documentation, I don't think I like 
> it that much.

16LL on 32 bit systems, but from an "explain what the number is" perspective it
neatly avoids needing to specify a base or units. :)

 Also, for the record, I had no idea what KiB / MiB means and how it's
 different from KB/MB until this discussion.
>> 
>> Very few people do. Some people have been trying to make "fetch" happen for 
>> many
>> years, but it didn't.
> 
> What's "fetch"?

A pop culture reference: https://www.youtube.com/watch?v=Pubd-spHN-0

>> (Part of the reason is kibybyte/mebibyte/gibibyte are
>> minor tongue twisters, they're physically harder to say, so nobody does.)
> 
> I rarely talk about this stuff; more often, I write about it.  When I 
> write, the shorthand MiB is nice (I never write mebibyte).

I always read that TLA as "Men in Black", but I know what you mean.

> For talking, 
> I say "megs" (or rather the Spanish equivalent "megas"), so being 
> colloquial I can't be blamed, since I didn't really say megabytes.  If I 
> say the technical term, which is rare, I try to be precise, and say 
> mebibytes instead of megabytes.

I say "binary megabytes" the same way I say "degrees celsius".

 I googled it before
 writing this reply, and found this among the first hits:
 https://ux.stackexchange.com/a/13850.
>>>
>>> That answer was written more than a decade ago.  These days, binary
>>> prefixes are more common.  In fact, I'd say most GNU/Linux commands
>> 
>> "First off, I'd suggest printing out a copy of the GNU coding standards,
>> and NOT read it.  Burn them, it's a great symbolic gesture." - Linus Torvalds
> 
> The GNU coding standards for writing C programs are horrible.  But they 
> have very nice things in their standards.  Their standardization of 
> Makefile targets and variables is quite nice, and I try to follow it 
> closely.

Hence cmake and ninja and so on.

>> (Still there in Documentation/process/coding-style.rst.)
>> 
>> GNU has nothing to do with Linux, and never did. Stallman has a history of
>> taking credit for other people's work:
> 
> I never said so. GNU is a set of userspace programs, Linux is a kernel, 
> and GNU/Linux is the entire OS (or more precisely a relatively important 
> part of it).

A busybox system isn't gnu, which means alpine linux isn't. Android using toybox
with a "no GPL in userspace policy" and built with llvm to avoid even the FSF's
compiler isn't gnu. So Linux on phones, and one of the standard docker distros,
actively _avoid_ using gnu. (These days, "systemd/linux" is probably at least as
accurate as "gnu/linux". I type that from devuan...)

> Most Linux distros are GNU/Linux distros, since user space 
> is mostly GNU.

Not really, no. Stallman constantly takes credit for other people's work (ala
the James Gosling interview video from last time). Here's the glibc maintainer
accusing stallman of a "hostile takeover of glibc development" 20 years ago:

https://sourceware.org/legacy-ml/libc-announce/2001/msg0.html#:~:text=And%20now

There were similar political shenanigans to bring EGCS back under FSF control
back in the day (resulting in bad blood at the time), which is why projects like
LLVM carefully avoid having any FSF contamination in them.

When I was researching for a computer history book back in 2001 (ala
https://landley.net/history/mirror) I drove to Boston and interviewed Stallman
at MIT. He claimed credit for BSD having defended itself from AT's lawsuits,
which is not something anybody who was actually involved wrote in any of their
histories:

  https://www.oreilly.com/library/view/open-sources/1565925823/ch04.html

Free software was the NORM before 1983. 1970s computer magazines had BASIC
source code listings in the back, the CP/M users group northwest started its
public domain library in 1981 (ala
https://landley.net/history/mirror/cpm/cpmug.html), I learned C to participate
in the WWIV modding community (we didn't even have "patch", we had english
descriptions of what to do (really! https://landley.net/history/wwiv/ ). Project
Gutenberg was founded in 1971. The Hercules emultor runs that last public domain
release of OS/360 ala http://www.hercules-390.eu/hercfaq.html#2.02

In reality, copyright was extended to cover source code by the Berne convention
in 1976... which meant people published MORE source because binaries weren't
copyrightable and source had at least a little traction. Copyright was extended
to cover binaries by the 1983 Apple vs Franklin lawsuit, before which there WAS
no non-free 

Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

[Ian Jackson]

Sean Whitton writes ("Bug#1031793: dgit: Treat single-debian-patch as implying 
--quilt=single"):
> How about having single-debian-patch imply --quilt=single in the absence
> of any other setting or command line argument for the quilt mode?
> Then in the docs we would say that it is a good idea to use only the git
> configuration value, but that this is another option if you prefer it.
> 
> This is still better than the previous situation because dgit will undo
> some problems created by single-debian-patch (right?).

The usual reason for eschewing in-tree directions about quilt format
is that the tree can't (mustn't) tell you if it's patches-applied or
not.  I think it would be OK for the tree to influence *how* patches
are made (ie, choose between --quilt=linear, --quilt=single, etc.)

There is also the fact that it would have an effect on dgit's
behaviour for an NMUer, but I think that's OK for this.

So your idea has merit.

However, do we want to have people put single-debian-patch in the
source tree ?  That has such weird dpkg-source behaviours.

Ideally we would do something that would influence dgit, but not
dpkg-source.  So maybe we could put some *other* dropping in the
source tree?

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Bug#1031797: libsemanage: Inaccurate copyright file

[Bastian Germann]

Source: libsemanage
Version: 3.4-1
Severity: serious
Control: tags -1 patch

The d/copyright file points to a 404 URL as source.
Also, it does not present all copyright information that is contained in the 
source.
I have a fix for these Policy violations attached in the machine-readable 
format.Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Comment: This is the Debian package for libsemanage.
Source: https://github.com/SELinuxProject/selinux/wiki/Releases

Files: *
Copyright: (C) 2004-2007, 2009 Tresys Technology, LLC
   (C) 2005 Red Hat, Inc.
   (C) 2005-2021 Red Hat, Inc.
   (C) 2017 Mellanox Technologies Inc.
License: LGPL-2.1+
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
 .
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
Lesser General Public License for more details.
 .
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, write to the Free Software
Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1
Comment:
 On Debian GNU/Linux systems, the complete text of the Lesser GNU General
 Public License version 2.1 can be found in 
`/usr/share/common-licenses/LGPL-2.1'.

Files: debian/*
Copyright: © 2005-2009, Manoj Srivastava 
License: GPL-2
The Debian specific changes are distributed under the terms of the
GNU General Public License, version 2.
 .
A copy of the GNU General Public License is also available at
http://www.gnu.org/copyleft/gpl.html>.  You may also obtain
it by writing to the Free Software Foundation, Inc., 51 Franklin
St, Fifth Floor, Boston, MA 02110-1301, USA.
Comment:
 On Debian GNU/Linux systems, the complete text of the GNU General
 Public License version 2 can be found in `/usr/share/common-licenses/GPL-2'.

Bug#1030857: transmission: New 4.0 version is available

[Leo Antunes]

Hi,

Just FYI: I have done some work in the salsa repo[0], but there are still a few 
kinks to iron out before we can ship it. It builds, but my debhelper-foo is a 
bit rusty :)

If anyone wants to jump in and finish it up, I wouldn't complain!

Cheers
Leo

[0] https://salsa.debian.org/debian/transmission

Bug#1019267: Missing dependeny on libavahi-client-dev

[Jakob Haufe]

I guess this was meant for #1023926? Will reply there.

Cheers, sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgpwLbAgeON_3.pgp
Description: OpenPGP digital signature

Bug#1031794: socklog: fails to extract source package: dpkg-source: error: pathname 'socklog-2.1.0+repack/debian/service/socklog-unix/log/supervise' points outside source root (to '/run/runit/supervis

[Sven Joachim]

On 2023-02-22 21:45 +0100, Lucas Nussbaum wrote:

> Source: socklog
> Version: 2.1.0+repack-4
> Severity: serious
>
> dpkg-source: info: extracting socklog in socklog-2.1.0+repack
> dpkg-source: info: unpacking socklog_2.1.0+repack.orig.tar.gz
> dpkg-source: info: unpacking socklog_2.1.0+repack-4.debian.tar.xz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying 0001-socklog-conf-update-service.patch
> dpkg-source: info: applying 0002-tryto-c.patch
> dpkg-source: info: applying 0003-patches-fix-build-warnings.patch
> dpkg-source: error: pathname 
> 'socklog-2.1.0+repack/debian/service/socklog-unix/log/supervise' points 
> outside source root (to '/run/runit/supervise/socklog-unix.log')
>
> That's on a system with a mix of testing and unstable. I'm not sure of
> which package introduced that additional check. Let me know if you
> cannot reproduce.

I can reproduce this, but only if the target directory
(/run/runit/supervise) actually exists.  Otherwise dpkg-source does not
complain.

Lintian reports the absolute symlink as a warning, but maybe turning it
into an error would be more appropriate.

Cheers,
   Sven

Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

[Sean Whitton]

Hello,

On Wed 22 Feb 2023 at 01:28PM -07, Sean Whitton wrote:

> This is still better than the previous situation because dgit will undo
> some problems created by single-debian-patch (right?).

Re-reading #1018984, I see that this is not right.

I still think we should have s-d-p imply --quilt=single, and present
both options in the documentation.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1030658: More info needed on the RC bug you opened

[Damyan Ivanov]

-=| Martin Quinson, 22.02.2023 08:58:42 +0100 |=-
> tag 1030658 +moreinfo
> thanks
> 
> Hello Damyan,
> 
> sorry for not noticing this bug before, I thought I was subscribed to the
> package.

No problem.

Today, however, everything works again. I tried on two systems 
tracking sid, including the one I used to report the issue. Strange.

> It looks like a missing dependency to me. Could you please give me 
> the output
> of `ldd /usr/bin/zeal` ?

linux-vdso.so.1 (0x7fff9f3be000)
libQt5Widgets.so.5 => /lib/x86_64-linux-gnu/libQt5Widgets.so.5 
(0x7fa243c0)
libQt5Core.so.5 => /lib/x86_64-linux-gnu/libQt5Core.so.5 
(0x7fa24360)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7fa2434a1000)
libQt5Concurrent.so.5 => /lib/x86_64-linux-gnu/libQt5Concurrent.so.5 
(0x7fa2443a)
libQt5Gui.so.5 => /lib/x86_64-linux-gnu/libQt5Gui.so.5 
(0x7fa242c0)
libQt5Network.so.5 => /lib/x86_64-linux-gnu/libQt5Network.so.5 
(0x7fa2432f7000)
libQt5WebEngineWidgets.so.5 => 
/lib/x86_64-linux-gnu/libQt5WebEngineWidgets.so.5 (0x7fa244352000)
libQt5WebEngineCore.so.5 => 
/lib/x86_64-linux-gnu/libQt5WebEngineCore.so.5 (0x7fa23aa0)
libQt5WebChannel.so.5 => /lib/x86_64-linux-gnu/libQt5WebChannel.so.5 
(0x7fa24432c000)
libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x7fa242abe000)
libQt5X11Extras.so.5 => /lib/x86_64-linux-gnu/libQt5X11Extras.so.5 
(0x7fa244325000)
libxcb-keysyms.so.1 => /lib/x86_64-linux-gnu/libxcb-keysyms.so.1 
(0x7fa23a60)
libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x7fa2442f9000)
libarchive.so.13 => /lib/x86_64-linux-gnu/libarchive.so.13 
(0x7fa23a938000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7fa23a20)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fa2442d9000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fa23a41f000)
/lib64/ld-linux-x86-64.so.2 (0x7fa24451f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fa23a859000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fa2442b8000)
libdouble-conversion.so.3 => 
/lib/x86_64-linux-gnu/libdouble-conversion.so.3 (0x7fa243beb000)
libicui18n.so.72 => /lib/x86_64-linux-gnu/libicui18n.so.72 
(0x7fa239e0)
libicuuc.so.72 => /lib/x86_64-linux-gnu/libicuuc.so.72 
(0x7fa239c02000)
libpcre2-16.so.0 => /lib/x86_64-linux-gnu/libpcre2-16.so.0 
(0x7fa243b5d000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7fa23a144000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 
(0x7fa239aca000)
libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x7fa239a43000)
libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 
(0x7fa242a88000)
libharfbuzz.so.0 => /lib/x86_64-linux-gnu/libharfbuzz.so.0 
(0x7fa23993f000)
libmd4c.so.0 => /lib/x86_64-linux-gnu/libmd4c.so.0 (0x7fa2432e5000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 
(0x7fa23a807000)
libQt5Quick.so.5 => /lib/x86_64-linux-gnu/libQt5Quick.so.5 
(0x7fa23920)
libQt5PrintSupport.so.5 => 
/lib/x86_64-linux-gnu/libQt5PrintSupport.so.5 (0x7fa2398cb000)
libQt5QuickWidgets.so.5 => 
/lib/x86_64-linux-gnu/libQt5QuickWidgets.so.5 (0x7fa2432d)
libQt5Qml.so.5 => /lib/x86_64-linux-gnu/libQt5Qml.so.5 
(0x7fa238c0)
libQt5Positioning.so.5 => /lib/x86_64-linux-gnu/libQt5Positioning.so.5 
(0x7fa23983d000)
libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x7fa2390a7000)
libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so 
(0x7fa23980b000)
libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x7fa2397c9000)
libevent-2.1.so.7 => /lib/x86_64-linux-gnu/libevent-2.1.so.7 
(0x7fa239772000)
libjpeg.so.62 => /lib/x86_64-linux-gnu/libjpeg.so.62 
(0x7fa238b6d000)
libopus.so.0 => /lib/x86_64-linux-gnu/libopus.so.0 (0x7fa238b0f000)
libvpx.so.7 => /lib/x86_64-linux-gnu/libvpx.so.7 (0x7fa23880)
libXcomposite.so.1 => /lib/x86_64-linux-gnu/libXcomposite.so.1 
(0x7fa2442ab000)
libXdamage.so.1 => /lib/x86_64-linux-gnu/libXdamage.so.1 
(0x7fa243b58000)
libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x7fa242a73000)
libXfixes.so.3 => /lib/x86_64-linux-gnu/libXfixes.so.3 
(0x7fa242a6b000)
libXrandr.so.2 => /lib/x86_64-linux-gnu/libXrandr.so.2 
(0x7fa23a137000)
libXtst.so.6 => /lib/x86_64-linux-gnu/libXtst.so.6 (0x7fa242a63000)
libwebpmux.so.3 => /lib/x86_64-linux-gnu/libwebpmux.so.3 
(0x7fa23a12b000)
libwebpdemux.so.2 => /lib/x86_64-linux-gnu/libwebpdemux.so.2 
(0x7fa23976c000)
libwebp.so.7 => 

Bug#1031754: ncmpc-lyrics: missing dependencies on python3-bs4 and python3-requests

[Diederik de Haas]

On Wednesday, 22 February 2023 21:39:18 CET kal...@debian.org wrote:
> 22/02/2023 13:38, Diederik wrote:
> > MR of that patch:
> > https://salsa.debian.org/mpd-team/ncmpc/-/merge_requests/1
> Thanks very much for your MR Diederik :)

Thanks for merging (so quick!) and maintaining the package :-)

> FYI: Regarding the cross building issue, there is an report against
> sphinx package https://bugs.debian.org/961206

Oh, that's good to know; I wasn't aware of that.
Referencing that bug in the comment of salsa-ci.yml would be better then my 
comment. If it is possible, it should be enabled imo.
I chose to disable it as I find a Ci which is expected to fail (or in this case 
'passed' with an exclamation mark) quickly loses it value.

Cheers,
  Diederik

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

Bug#1031790: libraw: CVE-2021-32142

[David Bremner]

Salvatore Bonaccorso  writes:

> Source: libraw
> Version: 0.20.2-2
> Severity: important
> Tags: security upstream
> Forwarded: https://github.com/LibRaw/LibRaw/issues/400
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> Control: fixed -1 0.21.1-1
>
> Hi,
>
> The following vulnerability was published for libraw. The wording for
> the CVE description from the feed is disputable, believe this should
> be at most DoS.

For (naughty) packages that embed libraw, is this worth
1) Trying to squeeze in a minor version update
2) waiting for stable update?
3) not worrying about for bookworm?

I know the answer is probably "it depends", just looking for feedback
and-or what other maintainers are planning on doing.

d

Bug#1031796: glusterfs: CVE-2022-48340

[Salvatore Bonaccorso]

Source: glusterfs
Version: 10.3-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/gluster/glusterfs/issues/3732
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for glusterfs.

CVE-2022-48340[0]:
| In Gluster GlusterFS 11.0, there is an xlators/cluster/dht/src/dht-
| common.c dht_setxattr_mds_cbk use-after-free.


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-2022-48340
https://www.cve.org/CVERecord?id=CVE-2022-48340
[1] https://github.com/gluster/glusterfs/issues/3732

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1031771: linphone-desktop: Update check recommends AppImage

[Dennis Filder]

Control: reassign -1 linphone 5.1.65-3
X-Debbugs-CC: Bastian Germann 

On Wed, Feb 22, 2023 at 02:15:09PM +0100, Bastian Germann wrote:
> The update check in the "burger menu" should be disabled because it
> downloads the AppImage version of linphone-desktop.

Patching an envvar-overridable early return and warning message into
linphone/coreapi/update_check.c:linphone_core_check_for_update() seems
to me like the easiest way to address this.  It would also function as
a stop-gap for any new mechanisms that try to trigger an update check.

I'll try to have a branch prepared in salsa by Sunday.

Regards.

Bug#1031795: directvnc: Homepage 404s

[Bastian Germann]

Source: directvnc
Version: 0.7.8-1
Severity: minor

The new homepage URL is https://drinkmilk.github.io/directvnc/

Bug#1031794: socklog: fails to extract source package: dpkg-source: error: pathname 'socklog-2.1.0+repack/debian/service/socklog-unix/log/supervise' points outside source root (to '/run/runit/supervis

[Lucas Nussbaum]

Source: socklog
Version: 2.1.0+repack-4
Severity: serious

Hi,

# dget 
https://deb.debian.org/debian/pool/main/s/socklog/socklog_2.1.0+repack-4.dsc
dget: retrieving 
https://deb.debian.org/debian/pool/main/s/socklog/socklog_2.1.0+repack-4.dsc
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100  1980  100  19800 0   8615  0 --:--:-- --:--:-- --:--:--  8646
dget: retrieving 
https://deb.debian.org/debian/pool/main/s/socklog/socklog_2.1.0+repack.orig.tar.gz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 59796  100 597960 0   162k  0 --:--:-- --:--:-- --:--:--  163k
dget: retrieving 
https://deb.debian.org/debian/pool/main/s/socklog/socklog_2.1.0+repack-4.debian.tar.xz
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
100 11080  100 110800 0  46909  0 --:--:-- --:--:-- --:--:-- 46751
socklog_2.1.0+repack-4.dsc:
  Good signature found
   validating socklog_2.1.0+repack.orig.tar.gz
   validating socklog_2.1.0+repack-4.debian.tar.xz
All files validated successfully.
dpkg-source: info: extracting socklog in socklog-2.1.0+repack
dpkg-source: info: unpacking socklog_2.1.0+repack.orig.tar.gz
dpkg-source: info: unpacking socklog_2.1.0+repack-4.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-socklog-conf-update-service.patch
dpkg-source: info: applying 0002-tryto-c.patch
dpkg-source: info: applying 0003-patches-fix-build-warnings.patch
dpkg-source: error: pathname 
'socklog-2.1.0+repack/debian/service/socklog-unix/log/supervise' points outside 
source root (to '/run/runit/supervise/socklog-unix.log')

That's on a system with a mix of testing and unstable. I'm not sure of
which package introduced that additional check. Let me know if you
cannot reproduce.

Lucas

Bug#837091: firefox-esr: EME DRM extention present and enabled

[Sebastian Ramacher]

Control: severity -1 normal

On 2017-05-27 13:47:45 +0100, Simon McVittie wrote:
> On Thu, 08 Sep 2016 at 20:14:28 +0200, Tjeerd Pinkert wrote:
> > after reading up a bit (late(ly)) on the W3C EME proposed standard for
> > embedding of DRM managed content in web pages, I decided to have a
> > look if it is present in the firefox browser
> [...]
> > I think the presence of code that requires closed source components to
> > function, might violate the DFSG for the main section? On the other
> > hand, no package relation is available in the non-free section as far
> > as I see that is actively depended on. If a decision has been taken on
> > this already, then please close.
> 
> I don't see a freeness problem here.
> 
> Firefox with the EME API enabled at compile time, but no CDM (DRM
> implementation) installed, is presumably no less functional than Firefox
> with the EME API disabled at compile time - so the CDM is not a
> dependency, because Firefox without a CDM is a perfectly acceptable web
> browser (just missing an optional feature). If we shipped CDMs in
> non-free, I don't think Firefox would have a stronger relationship to
> them than Suggests (or more likely, the CDMs would declare an Enhances
> relationship on Firefox, which means the same thing). Packages in main
> are allowed to have Suggests on non-free or even not-in-Debian packages,
> just not (Pre-)Depends or Recommends.
> 
> Free CDMs do seem to exist -
> https://github.com/fraunhoferfokus/open-content-decryption-module is one
> example. It is fairly likely that content publishers will not actually
> *use* those CDMs, but that's between you and the content providers whose
> products you choose to buy. So from a freeness point of view, this
> doesn't seem any worse than any other plugin interface that can accept
> both Free and non-Free plugins - for example glibc NSS, PAM, GStreamer,
> Firefox NPAPI, kernel modules, and OpenGL/EGL/Vulkan drivers.
> 
> I understand your desire to avoid DRM, but I don't think opening
> release-critical bugs requesting that features are removed from our
> builds of Firefox is an appropriate way to go about it.

ACK, so let's downgrade the severity.

Cheers

> > P.S. yes I know, having flash installed as a plugin is as bad as
> > having EME enabled...
> 
> In particular, I believe having the Flash NPAPI plugin installed means
> your copy of Firefox already loads a DRM implementation, because there's
> one in Flash. You might as well use one that is better-sandboxed, which
> is the purpose of EME.
> 
> S

-- 
Sebastian Ramacher

Bug#1031754: ncmpc-lyrics: missing dependencies on python3-bs4 and python3-requests

[kaliko]

22/02/2023 13:38, Diederik wrote:

MR of that patch: https://salsa.debian.org/mpd-team/ncmpc/-/merge_requests/1


Thanks very much for your MR Diederik :)

FYI: Regarding the cross building issue, there is an report against 
sphinx package https://bugs.debian.org/961206
I stumbled upon the issue trying to build MPD for amrhf (raspbian) and 
arm64 Debian...


Cheers
k

Bug#1031325: e2fsprogs 1.47.0 introduces a breaking change into Bookworm, breaking grub and making installations of Ubuntu and Debian releases via debootstrap impossible

[Paul Gevers]

Dear Ted,

On 16-02-2023 23:24, Theodore Ts'o wrote:

But, if the Debian Release team would like to override my position, my
suggestion would be to just change the default for /etc/mke2fs.conf
for *everyone* running Debian bookworm, and with the understanding
that this will be reverted in Debian testing after the next stable
release, and that moving forward, we make it the image building tools
problem if they want to support this highly dubious practice of using
Debian N+X's mkfs to build images for Debian N.


The Release Team discussed this topic in their IRC meeting of this 
evening. I would like to affirm your position as a maintainer of 
e2fsprogs to make this kind of changes in your package and that's up to 
image builders to cope with that. However, because of the *timing* of 
the change we ask you to revert the change of the default settings for 
bookworm and please enable them once trixie opens.


For future default changes, consider planning them before the transition 
freeze.


Thanks

Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031793: dgit: Treat single-debian-patch as implying --quilt=single

[Sean Whitton]

Package: dgit
Version: 10.6

Hello,

I think that it's very unfortunate that one of our flagship workflows,
dgit-maint-merge(7), now requires local git configuration, in the form
of 'git config --local dgit.default.quilt-mode single'.
Git configuration is a pain to automate.

I understand the issues with single-debian-patch, but most packages will
never run into issues, and in any case there's no doubt it's a bug in
dpkg, which can be fixed.

How about having single-debian-patch imply --quilt=single in the absence
of any other setting or command line argument for the quilt mode?
Then in the docs we would say that it is a good idea to use only the git
configuration value, but that this is another option if you prefer it.

This is still better than the previous situation because dgit will undo
some problems created by single-debian-patch (right?).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1031792: sofia-sip: CVE-2022-47516

[Salvatore Bonaccorso]

Source: sofia-sip
Version: 1.12.11+20110422.1+1e14eea~dfsg-4
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for sofia-sip.

CVE-2022-47516[0]:
| An issue was discovered in the libsofia-sip fork in drachtio-server
| before 0.8.20. It allows remote attackers to cause a denial of service
| (daemon crash) via a crafted UDP message that leads to a failure of
| the libsofia-sip-ua/tport/tport.c self assertion.

This was orriginally reported at [1] in the sofia-sip fork as used in
drachtio-server, but was fixed as well in sofia-sip itself at [2].

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-2022-47516
https://www.cve.org/CVERecord?id=CVE-2022-47516
[1] https://github.com/drachtio/drachtio-server/issues/244
[2] 
https://github.com/freeswitch/sofia-sip/commit/cadf505d88e2971d24b6a4379ddbb1398d8ec443

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#854472: libreswan FTBFS on mips and mipsel: error: "_ABI64" is not defined [-Werror=undef]

[Daniel Kahn Gillmor]

I've now uploaded the patch below to debian's DELAYED/15 queue as nspr 4.35-1.1.

On Fri 2023-02-10 16:06:33 -0500, Daniel Kahn Gillmor wrote:
> Control: tags 854472 + patch
>
> On Thu 2017-02-02 12:02:59 +, Radovan Birdic wrote:
>>> In file included from /usr/include/nspr/prtypes.h:26:0,
>>>  from /usr/include/nspr/plarena.h:15,
>>>  from /usr/include/nss/cert.h:13,
>>>  from /«PKGBUILDDIR»/lib/libswan/nss_copies.c:6:
>>> /usr/include/nspr/prcpucfg.h:511:18: error: "_ABI64" is not defined 
>>> [-Werror=undef]
>>>  #if _MIPS_SIM == _ABI64
>>>   ^~
>>> cc1: all warnings being treated as errors
>>> ../../../mk/depend.mk:28: recipe for target 'nss_copies.o' failed
>>> make[5]: *** [nss_copies.o] Error 1
>
> This failure has started happening again on 32-bit mipsel since nspr
> 4.35.
>
> I tracked it down to a libmusl-related fix upstream, as reported here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1815947
>
> The attached patch was suggested by Giulio Benetti
> , cc'ed here.
>
> I've also made it as a merge request on salsa:
>
> https://salsa.debian.org/mozilla-team/nspr/-/merge_requests/3
>
> Please consider applying this so that libreswan can build on mipsel!
>
>  --dkg
>
> From 4b5482f4e8ceb621367a49f7c937b32f9d1132a7 Mon Sep 17 00:00:00 2001
> From: Daniel Kahn Gillmor 
> Date: Fri, 10 Feb 2023 15:57:30 -0500
> Subject: [PATCH] Avoid libreswan build failures on mipsel (Closes: #854472)
>
> ---
>  ...build-failures-on-mipsel-Closes-8544.patch | 30 +++
>  debian/patches/series |  1 +
>  2 files changed, 31 insertions(+)
>  create mode 100644 
> debian/patches/0001-Avoid-libreswan-build-failures-on-mipsel-Closes-8544.patch
>  create mode 100644 debian/patches/series
>
> diff --git 
> a/debian/patches/0001-Avoid-libreswan-build-failures-on-mipsel-Closes-8544.patch
>  
> b/debian/patches/0001-Avoid-libreswan-build-failures-on-mipsel-Closes-8544.patch
> new file mode 100644
> index 000..fcf3e11
> --- /dev/null
> +++ 
> b/debian/patches/0001-Avoid-libreswan-build-failures-on-mipsel-Closes-8544.patch
> @@ -0,0 +1,30 @@
> +From: Daniel Kahn Gillmor 
> +Date: Fri, 10 Feb 2023 15:55:36 -0500
> +Subject: Avoid libreswan build failures on mipsel (Closes: #854472)
> +
> +Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1815947
> +
> +Bug 1815947 - Fix build failure with glibc and uclibc while including 
> sgidefs.h
> +
> +Let's include glibc and uclibc  while with musl let's include 
> Linux
> +.
> +---
> + nspr/pr/include/md/_linux.cfg | 4 
> + 1 file changed, 4 insertions(+)
> +
> +diff --git a/nspr/pr/include/md/_linux.cfg b/nspr/pr/include/md/_linux.cfg
> +index 2232820..009d5e5 100644
> +--- a/nspr/pr/include/md/_linux.cfg
>  b/nspr/pr/include/md/_linux.cfg
> +@@ -499,7 +499,11 @@
> + #elif defined(__mips__)
> + 
> + /* For _ABI64 */
> ++#if defined(__GLIBC__) || defined(__UCLIBC__)
> ++#include 
> ++#else
> + #include 
> ++#endif
> + 
> + #ifdef __MIPSEB__
> + #define IS_BIG_ENDIAN 1
> diff --git a/debian/patches/series b/debian/patches/series
> new file mode 100644
> index 000..6529bf9
> --- /dev/null
> +++ b/debian/patches/series
> @@ -0,0 +1 @@
> +0001-Avoid-libreswan-build-failures-on-mipsel-Closes-8544.patch
> -- 
> 2.39.1


signature.asc
Description: PGP signature

Bug#1031791: jquery-minicolors: CVE-2021-32850

[Salvatore Bonaccorso]

Source: jquery-minicolors
Version: 2.3.5+dfsg-3
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for jquery-minicolors.

CVE-2021-32850[0]:
| jQuery MiniColors is a color picker built on jQuery. Prior to version
| 2.3.6, jQuery MiniColors is prone to cross-site scripting when
| handling untrusted color names. This issue is patched in version
| 2.3.6.


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-32850
https://www.cve.org/CVERecord?id=CVE-2021-32850
[1] 
https://securitylab.github.com/advisories/GHSL-2021-1045_jQuery_MiniColors_Plugin/
[2] 
https://github.com/claviska/jquery-minicolors/commit/ef134824a7f4110ada53ea6c173111a4fa2f48f3
 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#991408: netbeans: please remove this package

[Leandro Cunha]

Hi Adam,

This bug can remain archive, there is no need to unarchive and the maintainer
himself has the choice to keep or not a package that is his. And it seems to me
that he chose to keep it even though he has 1 package out of testing and
present in unstable used as build-dep outdated since 2008.
I chose insert -ignore exactly because this bug does not affect stretch.
But I didn't know that it can only be used by the release team (something
not mentioned in the documentation I've read about debbugs [1]).

[1] https://www.debian.org/Bugs/server-control

-- 
Cheers,
Leandro Cunha

Bug#1031790: libraw: CVE-2021-32142

[Salvatore Bonaccorso]

Source: libraw
Version: 0.20.2-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/LibRaw/LibRaw/issues/400
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: fixed -1 0.21.1-1

Hi,

The following vulnerability was published for libraw. The wording for
the CVE description from the feed is disputable, believe this should
be at most DoS.

CVE-2021-32142[0]:
| Buffer Overflow vulnerability in LibRaw linux/unix v0.20.0 allows
| attacker to escalate privileges via the
| LibRaw_buffer_datastream::gets(char*, int) in
| /src/libraw/src/libraw_datastream.cpp.

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-32142
https://www.cve.org/CVERecord?id=CVE-2021-32142
[1] https://github.com/LibRaw/LibRaw/issues/400
[2] 
https://github.com/LibRaw/LibRaw/commit/bc3aaf4223fdb70d52d470dae65c5a7923ea2a49
 

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1031789: RFP: thunar-plugins -- easy Python plugins for Thunar

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org

* Package name: thunar-plugins
  Version : 1.4.0
  Upstream Contact: Yann Büchau
* URL : https://pypi.org/project/thunar-plugins/
* License : GPLv3
  Programming Lang: Python
  Description : easy Python plugins for Thunar

This Python package extends the Thunar file manager and provides a way for 
other Python packages to do the same without worrying about Thunar finding them.

Features Added to Thunar

  * a settings menu to en-/disable plugins added by this or other Python 
packages
  * creating links to a file or folder
  * Calculating various checksums of files
  * Git Annex support:
* git annex sync|add|get|drop|lock|unlock
* branch switching
* metadata-driven views
* editing metadata in the file properties dialog



This plugin seems amazing. It's the best git-annex integration I've
seen in a file manager so far.

It has an unfortunate name though, as it does way more as being
"plugins", it actually ships a bunch of plugins itself...

Bug#986357: Please improve package description

[Daniel Kahn Gillmor]

Hi Enrico--

On Sun 2021-04-04 10:02:27 +0200, Enrico Zini wrote:
> The package contains a user-facing tool, and the package description
> contains mostly redundant technical details about how the package is
> generated.
>
> Could you please update the description so that it explains what the sq
> command is supposed to do, so that one could use the description to see
> if it's a package that might do some of what they need?

Sorry for the long delay in getting back to you.

At the time you wrote this, i think the sq package description was
pretty similar to what it is today:


Description: OpenPGP command-line tool from Sequoia
 sq is a command-line interface for OpenPGP, structured using
 subcommands and implemented in Rust.
 .
 Subcommands include: help, decrypt, encrypt, sign, verify, armor,
 dearmor, autocrypt, inspect, key, keyring, certify, packet.
 .
 It offers modern cryptographic algorithms by default, like Ed25519 and
 Curve25519.
 .
 The tool offers both message handling (encryption, decryption,
 signing, and verification), and key and certificate management (key
 generation, certificate maintenance, and certification), and is
 interoperable with other major OpenPGP implementations like GnuPG
 (gpg).
 .
 WARNING: sq does not have a stable CLI interface yet.  Use with
 caution in scripts.
 This package contains the following binaries built from the Rust crate
 "sequoia-sq":
  - sq


This contains the fact that it's a command-line OpenPGP tool, describes
the various things it can do, and references some comparable
implementations (so people can find it if they search for GnuPG or gpg)

Can you say a little bit more about what you would prefer it to say
instead?

--dkg


signature.asc
Description: PGP signature

Bug#981301: elvish: please document where you want tab completion directives installed

[Daniel Kahn Gillmor]

On Fri 2021-01-29 12:47:53 +0800, Shengjing Zhu wrote:
> On Thu, Jan 28, 2021 at 05:35:20PM -0500, Daniel Kahn Gillmor wrote:
>> Package: src:elvish
>> Version: 0.15.0~rc3-1
>> Control: affects -1 src:rust-sequoia-sq src:rust-sequoia-sqv
>> 
>> I'm packaging a few rust binaries built using the "clap" crate, which
>> auto-generates completion files for bash, fish, zsh, elvish, and
>> powershell.
>> 
>> I know how to ship the bash, fish, and zsh tab completion directives.
>> But i don't know how to ship the elvish tab completion directives, or
>> how to test that they work as expected.  i'm including an example sq.elv
>> that is produced by the rust-sequoia-sq package when it's built, for
>> reference.
>
> It doesn't support global completion files yet. Author just says he will
> consider this after 0.15.

Hi there!  elvish is now several versions past 0.15.  any ideas where to
put tab completion files so that elvish can pick them up automatically?

--dkg


signature.asc
Description: PGP signature

Bug#1029731: libglapi-mesa: Apps fail with 'DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory' after upgrade from 22.3.2-1 to 22.3.3-1

[Diederik de Haas]

Control: tag -1 upstream fixed-upstream patch

On Tue, 31 Jan 2023 01:19:54 +0300 Andrey Skvortsov 
 wrote:
> Here is link to created upstream issue.
> https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198

In https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21330 this issue 
got fixed upstream and I've attached the patch/diff to this message.

When adding it to debian/patches and adding it to debian/patches/series and 
running `debian/rules patch`, it applies cleanly (which is not the case for 
all of them):

```
me@laptop:~/dev/debian/salsa/xorg-team/lib/mesa$ debian/rules patch
dh patch --with quilt \
--builddirectory=build/ \
--buildsystem=meson
   dh_quilt_patch -O--builddirectory=build/ -O--buildsystem=meson
Applying patch 07_gallium-fix-build-failure-on-powerpcspe.diff
patching file src/gallium/include/pipe/p_config.h

Applying patch path_max.diff
patching file src/util/tests/cache_test.cpp
Hunk #1 succeeded at 82 (offset 1 line).
patching file src/util/tests/process_test.c
patching file src/gallium/auxiliary/pipe-loader/pipe_loader.c
Hunk #1 succeeded at 42 (offset -1 lines).

Applying patch src_glx_dri_common.h.diff
patching file src/glx/dri_common.h
Hunk #1 succeeded at 57 (offset 2 lines).

Applying patch bug102973-lima.diff
patching file src/gallium/drivers/lima/lima_resource.c

Now at patch bug102973-lima.diff
```

HTH>From c426e5677f36c3b0b8e8ea199ed4f2c7fad06d47 Mon Sep 17 00:00:00 2001
From: Erico Nunes 
Date: Sun, 12 Feb 2023 22:33:30 +0100
Subject: [PATCH] lima: don't use resource_from_handle while creating scanout

resource_from_handle implementations create an additional reference to
the scanout resource, which caused lima to leak those resources after
commit ad4d7ca8332488be8a75aff001f00306a9f6402e.

Do as the other drivers do and import the bo directly while creating
the scanount resource.

Cc: 22.3 mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198
Signed-off-by: Erico Nunes 
Reviewed-by: Vasily Khoruzhick 
Part-of: 
---
 src/gallium/drivers/lima/lima_resource.c | 26 ++--
 1 file changed, 20 insertions(+), 6 deletions(-)

diff --git a/src/gallium/drivers/lima/lima_resource.c b/src/gallium/drivers/lima/lima_resource.c
index 54869ec03d24..0b7691f2b46f 100644
--- a/src/gallium/drivers/lima/lima_resource.c
+++ b/src/gallium/drivers/lima/lima_resource.c
@@ -59,7 +59,10 @@ lima_resource_create_scanout(struct pipe_screen *pscreen,
struct lima_screen *screen = lima_screen(pscreen);
struct renderonly_scanout *scanout;
struct winsys_handle handle;
-   struct pipe_resource *pres;
+
+   struct lima_resource *res = CALLOC_STRUCT(lima_resource);
+   if (!res)
+  return NULL;
 
struct pipe_resource scanout_templat = *templat;
scanout_templat.width0 = width;
@@ -71,20 +74,31 @@ lima_resource_create_scanout(struct pipe_screen *pscreen,
if (!scanout)
   return NULL;
 
+   res->base = *templat;
+   res->base.screen = pscreen;
+   pipe_reference_init(>base.reference, 1);
+   res->levels[0].offset = handle.offset;
+   res->levels[0].stride = handle.stride;
+
assert(handle.type == WINSYS_HANDLE_TYPE_FD);
-   pres = pscreen->resource_from_handle(pscreen, templat, ,
-PIPE_HANDLE_USAGE_FRAMEBUFFER_WRITE);
+   res->bo = lima_bo_import(screen, );
+   if (!res->bo) {
+  FREE(res);
+  return NULL;
+   }
+
+   res->modifier_constant = true;
 
close(handle.handle);
-   if (!pres) {
+   if (!res->bo) {
   renderonly_scanout_destroy(scanout, screen->ro);
+  FREE(res);
   return NULL;
}
 
-   struct lima_resource *res = lima_resource(pres);
res->scanout = scanout;
 
-   return pres;
+   return >base;
 }
 
 static uint32_t
-- 
GitLab



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

Bug#1028472: bullseye-pu: package publicsuffix/20221208.1942-0+deb11u1

[Daniel Kahn Gillmor]

On Sun 2023-02-19 19:45:58 +, Adam D. Barratt wrote:
> On Wed, 2023-01-11 at 11:07 -0500, Daniel Kahn Gillmor wrote:
>> Please consider an update to publicsuffix in debian bullseye.
>> 
>> This package reflects the state of the network, and keeping it
>> current
>> is useful for all the packages that depend on it.
>> 
>> The debdiff from the previous version in bullseye is attached.
>> 
>> This proposed release is also available at the
>> "publicsuffix_debian/20221208.1942-0+deb11u1" tag on the
>
> It looks like there was a 20230209 update in the meantime - is it worth
> rebasing this update on that?

Yes, that's probably a good idea.  i've opened
https://bugs.debian.org/1031788 instead with the updated publicsuffix
data.

--dkg


signature.asc
Description: PGP signature

Bug#1031788: bullseye-pu: package publicsuffix/20230209.2326-0+deb11u1

[Daniel Kahn Gillmor]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: d...@fifthhorseman.net
Control: affects -1 src:publicsuffix

Please consider an update to publicsuffix in debian bullseye.

This package reflects the state of the network, and keeping it current
is useful for all the packages that depend on it.

The debdiff from the previous version in bullseye is attached.

This proposed release is also available at the
"publicsuffix_debian/20230209.2326-0+deb11u1" tag on the "debian/bullseye" 
branch at
the git repo for publicsuffix packaging:

https://salsa.debian.org/debian/publicsuffix

Please followup on this ticket to confirm whether I should upload this
revision to bullseye.


publicsuffix_20220811.1734-0+deb11u1_20230209.2326-0+deb11u1.debdiff.gz
Description: application/gzip

Bug#1019267: Missing dependeny on libavahi-client-dev

[Thorsten Alteholz]

Hi Jakob,

I am not sure that I understand the problem:
Starting with a fresh system:

 root@sid:~# LANG=C dpkg -l "*pappl*"|grep pappl
 dpkg-query: no packages found matching *pappl*
 root@sid:~# LANG=C dpkg -l "*avahi*"|grep avahi
 un  avahi-autoipd(no description available)
 un  avahi-daemon (no description available)

results in:

 root@sid:~# pkg-config --exists pappl; echo $?
 1

Ok, now installing libpappl-dev

 root@sid:~# LANG=C apt-get install libpappl-dev
 Reading package lists... Done
 Building dependency tree... Done
 Reading state information... Done
 The following additional packages will be installed:
   libavahi-client3 libavahi-common-data libavahi-common3 libcups2 libcups2-dev 
libcupsfilters-dev libcupsfilters1 libcupsimage2
   (...)

you can see all needed avahi packages will be installed and afterwards:

 root@sid:~# pkg-config --exists pappl; echo $?
 0

Isn't this the result you wanted?

  Thorsten

Bug#1031785: Additional information

[Levente]

A simple test case to reproduce the bug:

lev@jive:~$ python3
Python 3.11.2 (main, Feb 12 2023, 00:48:52) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
>>> wx.version()
'4.2.0 gtk3 (phoenix) wxWidgets 3.2.1'
>>>


This should be 3.2.2

Bug#1031787: mitmproxy: crashes on startup after upgrade

[Piotr Sulecki]

Package: mitmproxy
Version: 8.1.1-1
Severity: important

Dear Maintainer,

after today's update to Sid, mitmproxy crashes on startup:

$ mitmproxy
Traceback (most recent call last):
  File "/usr/bin/mitmproxy", line 33, in 
sys.exit(load_entry_point('mitmproxy==8.1.1', 'console_scripts', 
'mitmproxy')())
 
^^
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/main.py", line 118, in 
mitmproxy
from mitmproxy.tools import console
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/console/__init__.py", 
line 1, in 
from mitmproxy.tools.console import master
  File "/usr/lib/python3/dist-packages/mitmproxy/tools/console/master.py", line 
26, in 
from mitmproxy.tools.console import consoleaddons
  File 
"/usr/lib/python3/dist-packages/mitmproxy/tools/console/consoleaddons.py", line 
6, in 
from mitmproxy import contentviews
  File "/usr/lib/python3/dist-packages/mitmproxy/contentviews/__init__.py", 
line 23, in 
from . import (
  File "/usr/lib/python3/dist-packages/mitmproxy/contentviews/grpc.py", line 
952, in 
@dataclass
 ^
  File "/usr/lib/python3.11/dataclasses.py", line 1220, in dataclass
return wrap(cls)
   ^
  File "/usr/lib/python3.11/dataclasses.py", line 1210, in wrap
return _process_class(cls, init, repr, eq, order, unsafe_hash,
   ^^^
  File "/usr/lib/python3.11/dataclasses.py", line 958, in _process_class
cls_fields.append(_get_field(cls, name, type, kw_only))
  
  File "/usr/lib/python3.11/dataclasses.py", line 815, in _get_field
raise ValueError(f'mutable default {type(f.default)} for field '
ValueError: mutable default  for field 
parser_options is not allowed: use default_factory
$

This happens regardless of any commandline options passed to the program.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

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

Versions of packages mitmproxy depends on:
ii  dpkg  1.21.20
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-4.1
ii  python3   3.11.2-1
ii  python3-asgiref   3.6.0-1
ii  python3-blinker   1.5-1
ii  python3-brotli1.0.9-2+b6
ii  python3-certifi   2022.9.24-1
ii  python3-cryptography  38.0.4-2
ii  python3-flask 2.2.2-2
ii  python3-h11   0.14.0-1
ii  python3-h24.1.0-4
ii  python3-hyperframe6.0.0-1
ii  python3-kaitaistruct  0.10-1
ii  python3-ldap3 2.9.1-2
ii  python3-msgpack   1.0.3-2+b1
ii  python3-openssl   23.0.0-1
ii  python3-passlib   1.7.4-3
ii  python3-pkg-resources 66.1.1-1
ii  python3-protobuf  3.21.12-1+b2
ii  python3-publicsuffix2 2.20191221-3
ii  python3-pyparsing 3.0.9-1
ii  python3-pyperclip 1.8.2-2
ii  python3-ruamel.yaml   0.17.21-1
ii  python3-sortedcontainers  2.4.0-2
ii  python3-tornado   6.2.0-3
ii  python3-urwid 2.1.2-4+b1
ii  python3-wsproto   1.2.0-1
ii  python3-zstandard 0.20.0-2

mitmproxy recommends no packages.

mitmproxy suggests no packages.

-- no debconf information

Bug#1031745: gdb: breaks rustc gdb debuginfo tests

[Fabian Grünbichler]

Hi!

I extracted one of the failing tests and the corresponding gdb commands
so that you can more easily (and quicker) reproduce the issue:

https://salsa.debian.org/fg/rustc-gdb-1031745

instructions are contained within as well. changing the triggering
function (multiple_arguments) to either just have the tuple as argument,
or making the signature

 fn multiple_arguments((oo, pp): (isize, isize), (qq, rr): (isize, isize)) { 

(and adapting the call accordingly) makes the problem go away.

just having multiple_arguments with the call as standalone test case
also doesn't trigger the issue.

Bug#1031690: Regression in wayland mixed DPI setups

[Didier 'OdyX' Raboud]

Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=465733
Control: tags -1 +fixed-upstream

It looks like this was fixed in https://bugs.kde.org/show_bug.cgi?id=465733, 
in the 5.27.1 Plasma release.

TIA, best,

OdyX

Le lundi, 20 février 2023 18.10:58 h CET, vous avez écrit :
> Package: plasma-workspace-wayland
> Version: 4:5.27.0-1
> Severity: important
> Tags: upstream
> 
> Hello there,
> 
> it looks like there's a regression in mixed DPI setups (one hiDPI screen
> at "150%", a lower-DPI screen at "100%"), on Wayland, for some non-KDE
> applications. In my case, flatpak firefox has too small tabs depending
> on which screen it initially got launched.
> 
> This was working much better pre-5.27.

-- 
OdyX

Bug#1030043: hplip-gui: traceback when launching hp-toolbox

[JHM-O]

> On Tue, 7 Feb 2023 21:52:11 -0600 Ryan Thoryk 
> wrote:
> > Changing line 119 in /usr/share/hplip/base/password.py
> > from:
> > get_distro_std_name(os_name)
> > to:
> > get_distro_name()
> > 
> > appears to fix the issue.
> 
> With this change I see a different error when running hp-check:
> 
> -Traceback (most recent call last):
>   File "/usr/bin/hp-check", line 861, in 
> dep.core.init()
>   File "/usr/share/hplip/installer/core_install.py", line 523, in
> init
> self.get_distro()
>   File "/usr/share/hplip/installer/core_install.py", line 661, in 
> get_distro
> if 'MX' in distro_release_name:
>^^^
> NameError: name 'distro_release_name' is not defined
> 
> Looking at the code, distro_release_name really just is not present
> in 
> that file anywhere that I can see.
> 
> 
> 
> 
> > 
> > -- 
> > Ryan Thoryk
> > r...@thoryk.com
> > r...@tliquest.net
> > 
> > 
> 
Dear Ryan

Comment out line 661-663 in file "core_install.py" and your problem is
solved

Greetings 
Jan Outhuis

Bug#1031786: logcheck: Filtering not working with entries from journald

[Helge Kreutzmann]

Package: logcheck
Version: 1.4.1
Severity: grave
Justification: renders package unusable

The change for #1025719 broke logcheck massively.

I've extensivly tuned logcheck files which nicely filter out lots of
messages (see statistics at the end).

Now I see them all again (only those comming from the journal). 

I don't see any information what I should do for migration.

Let's use a trivial example. The following harmless message is emitted
by courier to the journal:
Feb 22 16:37:40 meinfjell courierd[401638]: Installing uucp

In syslog this is:
syslog:2023-02-22T14:37:40.491690+00:00 meinfjell courierd: Installing uucp

I have the following in 
/etc/logcheck/ignore.d.server:
meinfjell courierd: Initializing uucp


As you can see, the message from the journal is slightly different
than from syslog, breaking tons of rules.

If such a feature is introduced, it should definitely have a switch so
that admins can decide when to change (requires adapting many rules).
Filtering both looks very impractical.

For statistics:
On my local system, I have 11396 lines of rules, on my server system
currently 2721 (I'm in the processing of setting this up, so this will
grow).


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

Kernel: Linux 6.1.9 (SMP w/12 CPU threads; PREEMPT)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages logcheck depends on:
ii  adduser3.131
ii  cron [cron-daemon] 3.0pl1-156
ii  exim4-daemon-light [mail-transport-agent]  4.96-14
ii  lockfile-progs 0.1.19
ii  logtail1.4.1
ii  mime-construct 1.12+really1.11-1

Versions of packages logcheck recommends:
ii  logcheck-database  1.4.1

Versions of packages logcheck suggests:
ii  rsyslog [system-log-daemon]  8.2212.0-1

-- Configuration Files:
/etc/logcheck/header.txt [Errno 13] Keine Berechtigung: 
'/etc/logcheck/header.txt'
/etc/logcheck/logcheck.conf [Errno 13] Keine Berechtigung: 
'/etc/logcheck/logcheck.conf'
/etc/logcheck/logcheck.logfiles [Errno 13] Keine Berechtigung: 
'/etc/logcheck/logcheck.logfiles'
/etc/logcheck/logcheck.logfiles.d/journal.logfiles [Errno 13] Keine 
Berechtigung: '/etc/logcheck/logcheck.logfiles.d/journal.logfiles'
/etc/logcheck/logcheck.logfiles.d/syslog.logfiles [Errno 13] Keine 
Berechtigung: '/etc/logcheck/logcheck.logfiles.d/syslog.logfiles'

-- no debconf information

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: PGP signature

Bug#1031785: python3-wxgtk4.0: Package uses to old version of wx libraries

[Levente]

Package: python3-wxgtk4.0
Version: 4.2.0+dfsg-1+b4
Severity: normal
X-Debbugs-Cc: none


Dear Maintainer,


When I compile a program (KiCad) that uses wxPython, it says this at 
runtime:


The wxPython library was compiled against wxWidgets 3.2.1 but KiCad is 
using 3.2.2.  Python plugins will not be available.


I presume that python3-wxgtk4.0 is linked to wxWidgets 3.2.1 but 
wxWidgets 3.2.2 is deployed as a library, and KiCad links to the newer.


I suggest to recompile the wxPython package.


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

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en

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

Versions of packages python3-wxgtk4.0 depends on:
ii  libc6 2.36-8
ii  libgcc-s1 12.2.0-14
ii  libstdc++612.2.0-14
ii  libwxbase3.2-13.2.2+dfsg-1
ii  libwxgtk-gl3.2-1  3.2.2+dfsg-1
ii  libwxgtk3.2-1 3.2.2+dfsg-1
ii  python3   3.11.1-3
ii  python3-numpy 1:1.24.2-1
ii  python3-pil   9.4.0-1.1+b1
ii  python3-six   1.16.0-4

python3-wxgtk4.0 recommends no packages.

Versions of packages python3-wxgtk4.0 suggests:
pn  wx3.0-doc  

-- no debconf information
Thank you for using reportbug

Bug#1019841: Testing the patch

[Michael Fritscher]

Good day,

I would like to test it in "full connectivity" mode more than happily.

Could you provide a binary package with this patch included? Else I will
try to build it myself - but no guarantee that I will succeed^^

Best regards
Michael

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Antonio Terceiro]

On Wed, Feb 22, 2023 at 09:24:29AM -0700, Scarlett Moore wrote:
> 
> On 2/21/23 15:03, Ryan Kavanagh wrote:
> > On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:
> > >Description : A tool for glamourous shell scripts
> > > 
> > > A tool for glamorous shell scripts. Leverage the power of Bubbles and
> > > Lip Gloss in your scripts and aliases without writing any Go code!
> > This long description does not provide users with enough information to
> > understand what the package does. What are "Bubbles" and "Lip Gloss" in
> > a shell script? What is a "glamourous shell script"?
> > 
> > It would be helpful if the package's long description satisfied §3.4.2
> > of the Debian Policy Manual [0]:
> > 
> >  The description field needs to make sense to anyone, even people who
> >  have no idea about any of the things the package deals with. [3]
> > 
> >  [...]
> > 
> >  [3] The blurb that comes with a program in its announcements and/or
> >  README files is rarely suitable for use in a description. It is
> >  usually aimed at people who are already in the community where the
> >  package is used.
> > 
> > Best wishes,
> > Ryan
> > 
> > [0] 
> > https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description
> > 
> 
> The package description will be this or close to it:

That is just too long, please don't.

>  A tool for glamorous shell scripts. Leverage the power of Bubbles
>  (https://github.com/charmbracelet/bubbles) and Lip Gloss
>  (https://github.com/charmbracelet/lipgloss) in your scripts and aliases
>  without writing any Go code!
>  .
>  Tutorial
>  .
>  Gum provides highly configurable, ready-to-use utilities to help you write
>  useful shell scripts and dotfiles aliases with just a few lines of code.

This last paragraph above looks like a good enough package description.
Save everything else for an upstream README installed on
/usr/share/doc/gum/, or some other type of documentation.

https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions


signature.asc
Description: PGP signature

Bug#1031700:

[dev . lkq1u]

https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2616 
the issue, looks like this description

https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6207 
https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2616

Bug#1031753: linux-image-5.10.0-21-s390x: user space process hangs on s390 kernel 5.10.162-1

[Salvatore Bonaccorso]

On Wed, Feb 22, 2023 at 05:19:47AM +0530, Dipak Zope wrote:
> Package: src:linux
> Version: 5.10.162-1
> Severity: normal
> X-Debbugs-Cc: pk...@debian.org, elb...@debian.org, dipak.zo...@ibm.com
> 
> Dear Maintainer,
> 
> What led up to the situation?
> * Processes does not proceed further, when there is a pending 
> TIF_NOTIFY_SIGNAL signal.
>   The problem is further described in the cover letter:
>   https://lists.debian.org/debian-s390/2023/02/msg00019.html
>   There are other relevant debian bugs #1030545, #1030510, which seems likely 
> because of this issue.
> What exactly did you do (or not do) that was effective (or ineffective) ?
> * kernel upgrade  to 5.10.0.21-s390x
> * commit 788d0824269b ("io_uring: import 5.15-stable io_uring")
> * commit 75309018a24d ("s390: add support for TIF_NOTIFY_SIGNAL")
> what was the outcome of this action?
> * Debian build machines started reporting test failures for multiple 
> packages/ The processes
>   would wait forever in do_signal.
> The following patch fixes this issue:
> https://lists.debian.org/debian-s390/2023/02/msg00019.html
> The patch fixes the problem introduced in commit 75309018a24d ("s390: add 
> support for TIF_NOTIFY_SIGNAL")
> Would request to apply this to the bullseye kernel stable release.

Thanks, change is included in 5.10.169 and pending for the next
bullseye upload.

Regards,
Salvatore

Bug#1031623: Memory leak on bullseye-backports kernel

[Salvatore Bonaccorso]

Control: reassign -1 src:linux 6.0.12-1
Control: tags -1 + moreinfo

Hi,

On Sun, Feb 19, 2023 at 09:14:10PM +0800, bgme wrote:
> Package: linux-image-amd64
> Version: 6.0.12-1~bpo11+1
> 
> Dear Maintainer,
> 
> The bullseye-backports kernel seems to have memory leaks.
> 
> ![Memory Basic 
> 1](https://img.bgme.bid/media_attachments/files/109/765/807/240/058/094/original/4797799a06a1f6a0.png)
> ![Memory Detai 
> 1](https://img.bgme.bid/media_attachments/files/109/765/733/452/620/356/original/ac80f53c417e8987.png)
> ![Memory Slab 
> 1](https://img.bgme.bid/media_attachments/files/109/765/600/897/375/029/original/fc19cd690d31b7c3.png)
> 
> 
> The memory usage graph during the worst memory leak.  But unfortunately, it
> was restarted directly at that time, and no log was kept.
> 
> ![Memory Basic 
> 2](https://img.bgme.bid/media_attachments/files/109/891/489/647/006/108/original/56e5e856c9ce8105.png)
> ![Memory Detail 
> 2](https://img.bgme.bid/media_attachments/files/109/891/492/977/702/947/original/d8916e5ae7ae2347.png)
> ![Memory Slab 
> 2](https://img.bgme.bid/media_attachments/files/109/891/494/523/668/852/original/ca1f479a7c4e4483.png)
> 
> The memory usage graph recently.
> 
> -
> 
> Some informations:
> 
> # lsb_release -a
> Distributor ID: Debian
> Description:    Debian GNU/Linux 11 (bullseye)
> Release:    11
> Codename:   bullseye
> 
> # uname -a
> Linux git 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
> 6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux
> 
> # free -h
>totalusedfree  shared  buff/cache   
> available
> Mem:15Gi   6.6Gi   567Mi   1.0Gi   8.1Gi   
> 7.3Gi
> Swap:  8.0Gi   3.7Gi   4.3Gi
> 
> # smem -tw
> Area   Used  Cache   Noncache
> firmware/hardware 0  0  0
> kernel image  0  0  0
> kernel dynamic memory  1104746474994163548048
> userspace memory465713613719723285164
> free memory  298680 298680  0
> --
>1600328091700686833212
> 
> # cat /proc/meminfo
> MemTotal:   16003280 kB
> MemFree:  292884 kB
> MemAvailable:7623832 kB
> Buffers:  20 kB
> Cached:  8357004 kB
> SwapCached:  1219960 kB
> Active:  6195512 kB
> Inactive:5855924 kB
> Active(anon):2455580 kB
> Inactive(anon):  2337516 kB
> Active(file):3739932 kB
> Inactive(file):  3518408 kB
> Unevictable:   0 kB
> Mlocked:   0 kB
> SwapTotal:   8387580 kB
> SwapFree:4534508 kB
> Zswap:   1665924 kB
> Zswapped:3608680 kB
> Dirty:  6028 kB
> Writeback:76 kB
> AnonPages:   3414016 kB
> Mapped:  1386444 kB
> Shmem:   1098512 kB
> KReclaimable: 408784 kB
> Slab:1475632 kB
> SReclaimable: 408784 kB
> SUnreclaim:  1066848 kB
> KernelStack:   20368 kB
> PageTables:   385704 kB
> NFS_Unstable:  0 kB
> Bounce:0 kB
> WritebackTmp:  0 kB
> CommitLimit:16389220 kB
> Committed_AS:   14574028 kB
> VmallocTotal:   34359738367 kB
> VmallocUsed:   62348 kB
> VmallocChunk:  0 kB
> Percpu: 5824 kB
> HardwareCorrupted: 0 kB
> AnonHugePages:208896 kB
> ShmemHugePages:0 kB
> ShmemPmdMapped:0 kB
> FileHugePages: 0 kB
> FilePmdMapped: 0 kB
> HugePages_Total:   0
> HugePages_Free:0
> HugePages_Rsvd:0
> HugePages_Surp:0
> Hugepagesize:   2048 kB
> Hugetlb:   0 kB
> DirectMap4k:  182128 kB
> DirectMap2M: 5715968 kB
> DirectMap1G:10485760 kB
> 
> # slabtop -o
>  Active / Total Objects (% used): 13245486 / 13988330 (94.7%)
>  Active / Total Slabs (% used)  : 271375 / 271375 (100.0%)
>  Active / Total Caches (% used) : 121 / 158 (76.6%)
>  Active / Total Size (% used)   : 1274666.34K / 1441579.73K (88.4%)
>  Minimum / Average / Maximum Object : 0.01K / 0.10K / 8.00K
> 
>   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> 10730176 10696353  99%0.06K 167659   64670636K vmap_area
> 1151584 907533  78%0.14K  41128   28164512K btrfs_extent_map
> 452312 344597  76%0.57K  16154   28258464K radix_tree_node
> 261504  87883  33%0.03K   2043  128  8172K lsm_inode_cache
> 214500 210884  98%0.20K  10725   20 42900K vm_area_struct
> 158559 152049  95%0.08K   3109   51 12436K Acpi-State
> 145984 144333  98%0.06K   2281   64  9124K anon_vma_chain
> 134736  90425  67%0.19K   6416   21 25664K dentry
>  82104  53847  65%1.17K   3280   27104960K btrfs_inode
>  75348  68093  90%0.19K   3588   21 14352K kmalloc-192
>  56901  

Bug#1031770: kontact: cannot show existing messages and will not retrieve new ones

[Paul Boddie]

On 2023-02-22 17:03, Otto Kekäläinen wrote:

Seems Akonadi tried to execute

"INSERT INTO PimItemTable (rev, remoteId, remoteRevision, gid,
collectionId, mimeTypeId, datetime, atime, dirty, size) VALUES (:0,
:1, :2, :3, :4, :5, :6, :7, :8, :9)"

and gets error

"Incorrect datetime value: '2023-02-22T12:00:36Z' for column
`akonadi`.`pimitemtable`.`datetime` at row 1"

Can you check what the schema for that table is? How does the current
data look like?


So, akonadiconsole produces a graphical representation of the schema, so 
I had to use the command line client as follows:


mysql -S /tmp/akonadi-paulb.c9oVw2/mysql.socket

The socket file can be discovered by doing "ps -ef | grep mysql" and 
reading the --socket option of the mysqld process command line.


After doing "use akonadi", I performed the following:

MariaDB [akonadi]> desc PimItemTable;
+++--+-+-++
| Field  | Type   | Null | Key | Default | 
Extra  |

+++--+-+-++
| id | bigint(20) | NO   | PRI | NULL| 
auto_increment |
| rev| int(11)| NO   | | 0   |   
 |
| remoteId   | varbinary(255) | YES  | MUL | NULL|   
 |
| remoteRevision | varbinary(255) | YES  | | NULL|   
 |
| gid| varbinary(255) | YES  | MUL | NULL|   
 |
| collectionId   | bigint(20) | YES  | MUL | NULL|   
 |
| mimeTypeId | bigint(20) | YES  | MUL | NULL|   
 |
| datetime   | timestamp  | NO   | | current_timestamp() |   
 |
| atime  | timestamp  | NO   | | current_timestamp() |   
 |
| dirty  | tinyint(1) | YES  | | NULL|   
 |
| size   | bigint(20) | NO   | | 0   |   
 |

+++--+-+-++
11 rows in set (0.001 sec)


(Unless you are sure the root cause is
https://bugreports.qt.io/browse/QTBUG-95071)


This was the closest thing I could find.


Or could this be a variant of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993219 ?


I don't think so. People have experienced configuration issues with 
MySQL in the past, on one occasion involving a change in the default 
behaviour of MySQL itself, but the library upgrade seems more likely to 
have caused a problem than anything else.



Very weird that Akonadi would stop working on an upgrade of
1:10.3.38-0+deb10u1. Does it start working if you downgrade back to
1:10.3.37-0+deb10u1?


Yes, I wouldn't expect the issue described in the upstream bug tracker 
to occur at this point, but I don't know what goes into the Debian 
patching of this library, either.


Using "apt-cache showpkg libmariadb3", I found that the following 
version was available via apt:


1:10.3.34-0+deb10u1

However, in my /var/cache/apt/archive collection, I have this later 
version:


1:10.3.36-0+deb10u2

Trying to use dpkg to install this later version seems to make Akonadi 
non-functional, as does any attempt to use apt to install the earlier 
version, these being the respective commands:


dpkg -i 
/var/cache/apt/archives/libmariadb3_1%3a10.3.36-0+deb10u2_amd64.deb

apt-get install libmariadb3=1:10.3.34-0+deb10u1

Both attempts yield errors like this in the Akonadi server log:

Tokenizer Warning: trailing garbage after angle-addr in Return-Path!

Maybe I am just failing to downgrade the library properly, and perhaps I 
would also need to ensure that the MySQL server is also downgraded.


Paul

Bug#998037: gargoyle-free: Mention config file path in man

[Alexandre Detiste]

Control:  tags -1 +pending

Hi,

In the next upload the Debian manpage will be discarded and replaced
by upstream's.

I guess it's what you need ?

Greetings


-

https://github.com/garglk/garglk/blob/master/gargoyle.6

.Pa $HOME/.config/garglk.ini
.Pc
is parsed, with all of its provided options replacing whatever was specified in
the global configuration file.
Finally, if there is a directory-specific and/or game-specific configuration
file, their options will replace any existing options.
Configuration files need not provide all options.
This allows, for example, a game to select only the colors to be used, while
respecing all of the user's other choices.

Bug#1031784: hplip: hp-plugin : lacks dependency impossible to install plugin : scanning is not possible

[Erwan David]

Package: hplip
Version: 3.22.10+dfsg0-1
Severity: important


The error is the same for hp-check : due to the lack of get_distro_std_name
hp-plugin does not work thus impossible to install the plugin and thus
impossible to scan

-- Package-specific info:
Saving output in log file: /home/edavid/hp-check.log

HP Linux Imaging and Printing System (ver. 3.22.10)
Dependency/Version Check Utility ver. 15.1

Copyright (c) 2001-18 HP Development Company, LP
This software comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to distribute it
under certain conditions. See COPYING file for more details.

Note: hp-check can be run in three modes:
1. Compile-time check mode (-c or --compile): Use this mode before compiling 
the HPLIP supplied tarball (.tar.gz
or .run) to determine if the proper dependencies are installed to successfully 
compile HPLIP.   
2. Run-time check mode (-r or --run): Use this mode to determine if a distro 
supplied package (.deb, .rpm, etc) 
or an already built HPLIP supplied tarball has the proper dependencies 
installed to successfully run.   
3. Both compile- and run-time check mode (-b or --both) (Default): This mode 
will check both of the above cases 
(both compile- and run-time dependencies).  


Check types:

a. EXTERNALDEP - External Dependencies  

b. GENERALDEP - General Dependencies (required both at compile and run time)

c. COMPILEDEP - Compile time Dependencies   

d. [All are run-time checks]

PYEXT SCANCONF QUEUES PERMISSION


Status Types:
OK
MISSING   - Missing Dependency or Permission or Plug-in
INCOMPAT  - Incompatible dependency-version or Plugin-version

Traceback (most recent call last):
  File "/usr/bin/hp-check", line 860, in 
dep =  DependenciesCheck(MODE_CHECK,INTERACTIVE_MODE,ui_toolkit)
   ^
  File "/usr/bin/hp-check", line 175, in __init__
self.core = CoreInstall(mode, ui_mode, ui_toolkit)
^^
  File "/usr/share/hplip/installer/core_install.py", line 240, in __init__
self.passwordObj = password.Password(ui_mode)
   ^^
  File "/usr/share/hplip/base/password.py", line 94, in __init__
self.__readAuthType()  # self.__authType
^
  File "/usr/share/hplip/base/password.py", line 119, in __readAuthType
distro_name = get_distro_std_name(os_name)
  ^^^
NameError: name 'get_distro_std_name' is not defined. Did you mean: 
'get_distro_name'?

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'stable-security'), (600, 'unstable'), 
(500, 'stable-updates')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, 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

Versions of packages hplip depends on:
ii  adduser3.131
ii  cups   2.4.2-1+b2
ii  hplip-data 3.22.10+dfsg0-1
ii  libc6  2.36-8
ii  libcups2   2.4.2-1+b2
ii  libdbus-1-31.14.6-1
ii  libhpmud0  3.22.10+dfsg0-1
ii  libpython3.11  3.11.2-4
ii  libsane-hpaio  3.22.10+dfsg0-1
ii  libsane1   1.1.1-6+b2
ii  lsb-base   11.6
ii  printer-driver-hpcups  3.22.10+dfsg0-1
ii  python33.11.1-3
ii  python3-dbus   1.3.2-4+b1
ii  python3-gi 3.42.2-3+b1
ii  python3-pexpect4.8.0-4
ii  python3-pil9.4.0-1.1+b1
ii  python3-reportlab  3.6.12-1
ii  sysvinit-utils [lsb-base]  3.06-2
ii  wget   1.21.3-1+b2
ii  xz-utils   5.4.1-0.1

Versions of packages hplip recommends:
ii  avahi-daemon  0.8-8
ii  policykit-1   122-3
ii  printer-driver-postscript-hp  3.22.10+dfsg0-1
ii  sane-utils1.1.1-6+b2

Versions of packages hplip suggests:
pn  hplip-doc  
ii  hplip-gui  3.22.10+dfsg0-1
ii  python3-notify20.3-5
ii  system-config-printer  1.5.18-1

-- no debconf information

Bug#1017302: Thank you for contacting us.

[Apple Support]

Thank you for contacting us.
 

We’ve received your support request and will get back to you in one to two 
business days. Your case number is 3001605065.

For additional information on development-related topics, visit:
https://developer.apple.com/support/

Best regards, 

Apple Developer Program Support


Copyright (c) 2023 Apple Inc. All rights reserved.

Contact Us
https://developer.apple.com/contact/

Developer
https://developer.apple.com/

My Apple ID
https://appleid.apple.com

Privacy Policy
https://www.apple.com/privacy/

Bug#1022126: merge this change to stable 5.10 kernel

[Salvatore Bonaccorso]

Hi,

On Mon, Feb 20, 2023 at 10:59:50AM +0200, Taavi Ansper wrote:
> Hi
> 
> Kernel 6.2 is released now with the fix as I understand.
> 
> Could this now be merged to 5.10?
> 
> Have been waiting for this for 4.5 months now.

See the reply from https://bugs.debian.org/1022126#102 (i.e. someone
needs to ask stable maintainers upstream to backport the change as
well to the relevant stable series). Notabene, the patch cannot be
cleanly cherry-picked.

Regards,
Salvatore

Bug#1031634: ITP: gum -- A tool for glamourous shell scripts

[Scarlett Moore]

On 2/21/23 15:03, Ryan Kavanagh wrote:

On Sun, Feb 19, 2023 at 09:01:56AM -0700, Scarlett Moore wrote:

   Description : A tool for glamourous shell scripts

A tool for glamorous shell scripts. Leverage the power of Bubbles and
Lip Gloss in your scripts and aliases without writing any Go code!

This long description does not provide users with enough information to
understand what the package does. What are "Bubbles" and "Lip Gloss" in
a shell script? What is a "glamourous shell script"?

It would be helpful if the package's long description satisfied §3.4.2
of the Debian Policy Manual [0]:

 The description field needs to make sense to anyone, even people who
 have no idea about any of the things the package deals with. [3]

 [...]

 [3] The blurb that comes with a program in its announcements and/or
 README files is rarely suitable for use in a description. It is
 usually aimed at people who are already in the community where the
 package is used.

Best wishes,
Ryan

[0] 
https://www.debian.org/doc/debian-policy/ch-binary.html#the-extended-description



The package description will be this or close to it:


 A tool for glamorous shell scripts. Leverage the power of Bubbles
 (https://github.com/charmbracelet/bubbles) and Lip Gloss
 (https://github.com/charmbracelet/lipgloss) in your scripts and aliases
 without writing any Go code!
 .
 Tutorial
 .
 Gum provides highly configurable, ready-to-use utilities to help you write
 useful shell scripts and dotfiles aliases with just a few lines of code.
 .
 Let's build a simple script to help you write Conventional Commits
 (https://www.conventionalcommits.org/en/v1.0.0/#summary) for your
 dotfiles.
 .
 Start with a #!/bin/sh.
 .
   #!/bin/sh
 .
 Ask for the commit type with gum choose:
 .
   gum choose "fix" "feat" "docs" "style" "refactor" "test" "chore"
 "revert"
 .
  | Tip: this command itself will print to stdout which is not all that
  | useful.
  | To make use of the command later on you can save the stdout to a
  | $VARIABLE or
  | file.txt.
 .
 Prompt for an (optional) scope for the commit:
 .
   gum input --placeholder "scope"
 .
 Prompt for a commit message:
 .
   gum input --placeholder "Summary of this change"
 .
 Prompt for a detailed (multi-line) explanation of the changes:
 .
   gum write --placeholder "Details of this change (CTRL+D to finish)"
 .
 Prompt for a confirmation before committing:
 .
  | gum confirm exits with status 0 if confirmed and status 1 if
 cancelled.
 .
   gum confirm "Commit changes?" && git commit -m "$SUMMARY" -m
 "$DESCRIPTION"
 .
 Putting it all together...
 .
   #!/bin/sh
   TYPE=$(gum choose "fix" "feat" "docs" "style" "refactor" "test"
 "chore" "revert")
   SCOPE=$(gum input --placeholder "scope")
 .
   # Since the scope is optional, wrap it in parentheses if it has a
 value.
   test -n "$SCOPE" && SCOPE="($SCOPE)"
 .
   # Pre-populate the input with the type(scope): so that the user may
 change it
   SUMMARY=$(gum input --value "$TYPE$SCOPE: " --placeholder "Summary 
of this

 change")
   DESCRIPTION=$(gum write --placeholder "Details of this change (CTRL+D to
 finish)")
 .
   # Commit these changes
   gum confirm "Commit changes?" && git commit -m "$SUMMARY" -m
 "$DESCRIPTION"
 .
 Customization
 .
 gum is designed to be embedded in scripts and supports all sorts of use
 cases. Components are configurable and customizable to fit your theme
 and use case.
 .
 You can customize with --flags. See gum  --help for a full 
view of

 each command's customization and configuration options.
 .
 For example, let's use an input and change the cursor color, prompt
 color, prompt indicator, placeholder text, width, and pre-populate the
 value:
 .
   gum input --cursor.foreground "#FF0" --prompt.foreground "#0FF" 
--prompt "*

 " \
   --placeholder "What's up?" --width 80 --value "Not much, hby?"
 .
 You can also use ENVIRONMENT_VARIABLES to customize gum by default, this
 is useful to keep a consistent theme for all your gum commands.
 .
   export GUM_INPUT_CURSOR_FOREGROUND="#FF0"
   export GUM_INPUT_PROMPT_FOREGROUND="#0FF"
   export GUM_INPUT_PLACEHOLDER="What's up?"
   export GUM_INPUT_PROMPT="* "
   export GUM_INPUT_WIDTH=80
 .
   # Uses values configured through environment variables above but can
 still be
   # overridden with flags.
   gum input
 .
 Input
 .
 Prompt for input with a simple command.
 .
   gum input > answer.txt
 .
 Prompt for sensitive input with the --password flag.
 .
   gum input --password > password.txt
 .
 Write
 .
 Prompt for some multi-line text.
 .
 Note: CTRL+D and esc are used to complete text entry. CTRL+C will
 cancel.
 .
   gum write > story.txt
 .
 Filter
 .
 Use fuzzy matching to filter a list of values:
 .
   echo Strawberry >> flavors.txt
   echo Banana >> flavors.txt
   echo Cherry >> flavors.txt
   cat flavors.txt | gum filter > selection.txt
 .
 .
 You can also select multiple items with the --limit flag, which determines
 the maximum number of 

Bug#1029261: Thank you for contacting us.

[Apple Support]

Thank you for contacting us.
 

We’ve received your support request and will get back to you in one to two 
business days. Your case number is 3001596588.

For additional information on development-related topics, visit:
https://developer.apple.com/support/

Best regards, 

Apple Developer Program Support


Copyright (c) 2023 Apple Inc. All rights reserved.

Contact Us
https://developer.apple.com/contact/

Developer
https://developer.apple.com/

My Apple ID
https://appleid.apple.com

Privacy Policy
https://www.apple.com/privacy/

Bug#1027870: Thank you for contacting us.

[Apple Support]

Thank you for contacting us.
 

We’ve received your support request and will get back to you in one to two 
business days. Your case number is 3001595937.

For additional information on development-related topics, visit:
https://developer.apple.com/support/

Best regards, 

Apple Developer Program Support


Copyright (c) 2023 Apple Inc. All rights reserved.

Contact Us
https://developer.apple.com/contact/

Developer
https://developer.apple.com/

My Apple ID
https://appleid.apple.com

Privacy Policy
https://www.apple.com/privacy/

Bug#1031770: kontact: cannot show existing messages and will not retrieve new ones

[Otto Kekäläinen]

Seems Akonadi tried to execute

"INSERT INTO PimItemTable (rev, remoteId, remoteRevision, gid,
collectionId, mimeTypeId, datetime, atime, dirty, size) VALUES (:0,
:1, :2, :3, :4, :5, :6, :7, :8, :9)"

and gets error

"Incorrect datetime value: '2023-02-22T12:00:36Z' for column
`akonadi`.`pimitemtable`.`datetime` at row 1"

Can you check what the schema for that table is? How does the current
data look like?
(Unless you are sure the root cause is
https://bugreports.qt.io/browse/QTBUG-95071)

Or could this be a variant of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993219 ?

Very weird that Akonadi would stop working on an upgrade of
1:10.3.38-0+deb10u1. Does it start working if you downgrade back to
1:10.3.37-0+deb10u1?

Bug#1028728: Thank you for contacting us.

[Apple Support]

Thank you for contacting us.
 

We’ve received your support request and will get back to you in one to two 
business days. Your case number is 3001567911.

For additional information on development-related topics, visit:
https://developer.apple.com/support/

Best regards, 

Apple Developer Program Support


Copyright (c) 2023 Apple Inc. All rights reserved.

Contact Us
https://developer.apple.com/contact/

Developer
https://developer.apple.com/

My Apple ID
https://appleid.apple.com

Privacy Policy
https://www.apple.com/privacy/

Bug#1029803: command-not-found breaks dist-upgrade bullseye → bookworm

[Paul Gevers]

Control: tags -1 pending

On 20-02-2023 16:20, Paul Gevers wrote:
I have the attached debdiff ready to handle with the stable release 
managers.


I have uploaded the attached debdiff, I took the liberty to also fix the 
autopkgtest (cherry-pick from unstable).


Paul
diff --git a/debian/changelog b/debian/changelog
index da6aa89..15f7177 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+command-not-found (20.10.1-1+deb11u1) bullseye; urgency=medium
+
+  * creator.py: add new non-free-firmware component (Closes: #1029803)
+  * debian/tests: Add adduser dependency, fix test to not assume vim-tiny
+matches for vim. (from bookworm branch)
+
+ -- Paul Gevers   Wed, 22 Feb 2023 16:09:19 +0100
+
 command-not-found (20.10.1-1) unstable; urgency=medium
 
   * Trim trailing whitespace.
diff --git 
a/debian/patches/0001-creator.py-add-new-non-free-firmware-component.patch 
b/debian/patches/0001-creator.py-add-new-non-free-firmware-component.patch
new file mode 100644
index 000..ad4b3d8
--- /dev/null
+++ b/debian/patches/0001-creator.py-add-new-non-free-firmware-component.patch
@@ -0,0 +1,25 @@
+From 95e94853f4abff33f576e58ebeab795f6cb1a62e Mon Sep 17 00:00:00 2001
+From: Paul Gevers 
+Date: Sun, 19 Feb 2023 21:45:07 +0100
+Subject: [PATCH] creator.py: add new non-free-firmware component
+
+Closes: #1029803
+---
+ CommandNotFound/db/creator.py | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/CommandNotFound/db/creator.py b/CommandNotFound/db/creator.py
+index 75d01f1..8f6ef70 100755
+--- a/CommandNotFound/db/creator.py
 b/CommandNotFound/db/creator.py
+@@ -20,6 +20,7 @@ component_priorities = {
+ 'universe': 100,
+ 'contrib': 80,
+ 'restricted': 60,
++'non-free-firmware': 50,
+ 'non-free': 40,
+ 'multiverse': 20,
+ }
+-- 
+2.39.1
+
diff --git a/debian/patches/series b/debian/patches/series
index 28cdfac..a459c03 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 bts.diff
 0003-cnf-update-db-Add-support-for-Contents-files.patch
+0001-creator.py-add-new-non-free-firmware-component.patch
diff --git a/debian/tests/control b/debian/tests/control
index 4062764..956933f 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,4 +1,4 @@
 Tests: smoke
 Restrictions: needs-root
-Depends: command-not-found
+Depends: command-not-found, adduser
 
diff --git a/debian/tests/smoke b/debian/tests/smoke
index 4f0e5ae..7236ab2 100755
--- a/debian/tests/smoke
+++ b/debian/tests/smoke
@@ -10,7 +10,7 @@ apt-get update
 
 echo "Ensure we have results from c-n-f"
 /usr/lib/command-not-found --ignore-installed vim 2>&1 | grep vim
-/usr/lib/command-not-found --ignore-installed vim 2>&1 | grep vim-tiny
+/usr/lib/command-not-found --ignore-installed vim 2>&1 | grep "command '.*' 
from deb "
 
 
 echo "Add testuser"


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1031783: bullseye-pu: package command-not-found/20.10.1-1+deb11u1

[Paul Gevers]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: command-not-fo...@packages.debian.org
Control: affects -1 + src:command-not-found

[ Reason ]

Bug #1029803: command-not-found in bullseye doesn't know the
non-free-firmware component and will fail during the $(apt update) run
after changing the APT sources lists.

[ Impact ]

Without the fix users have to figure out how to unstuck apt, probably
by uninstalling command-not-found.

[ Tests ]

I have manually upgraded several clean VM's while confirming the
problem and confirming the solution.

The autopkgtest of command-not-found is broken in bullseye, I have
cherry-picked the fix from the unstable branch.

[ Risks ]

The fix is trivial, I consider the risk low.

[ 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 ]

I added non-free-firmware to the list of known components. I
cherry-picked the fix for the autopkgtest.

I don't expect the fix to be controversial and have uploaded it to
bullseye.

[ Other ]

The maintainer approved the fix.

Paul
diff --git a/debian/changelog b/debian/changelog
index da6aa89..15f7177 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+command-not-found (20.10.1-1+deb11u1) bullseye; urgency=medium
+
+  * creator.py: add new non-free-firmware component (Closes: #1029803)
+  * debian/tests: Add adduser dependency, fix test to not assume vim-tiny
+matches for vim. (from bookworm branch)
+
+ -- Paul Gevers   Wed, 22 Feb 2023 16:09:19 +0100
+
 command-not-found (20.10.1-1) unstable; urgency=medium
 
   * Trim trailing whitespace.
diff --git 
a/debian/patches/0001-creator.py-add-new-non-free-firmware-component.patch 
b/debian/patches/0001-creator.py-add-new-non-free-firmware-component.patch
new file mode 100644
index 000..ad4b3d8
--- /dev/null
+++ b/debian/patches/0001-creator.py-add-new-non-free-firmware-component.patch
@@ -0,0 +1,25 @@
+From 95e94853f4abff33f576e58ebeab795f6cb1a62e Mon Sep 17 00:00:00 2001
+From: Paul Gevers 
+Date: Sun, 19 Feb 2023 21:45:07 +0100
+Subject: [PATCH] creator.py: add new non-free-firmware component
+
+Closes: #1029803
+---
+ CommandNotFound/db/creator.py | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/CommandNotFound/db/creator.py b/CommandNotFound/db/creator.py
+index 75d01f1..8f6ef70 100755
+--- a/CommandNotFound/db/creator.py
 b/CommandNotFound/db/creator.py
+@@ -20,6 +20,7 @@ component_priorities = {
+ 'universe': 100,
+ 'contrib': 80,
+ 'restricted': 60,
++'non-free-firmware': 50,
+ 'non-free': 40,
+ 'multiverse': 20,
+ }
+-- 
+2.39.1
+
diff --git a/debian/patches/series b/debian/patches/series
index 28cdfac..a459c03 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 bts.diff
 0003-cnf-update-db-Add-support-for-Contents-files.patch
+0001-creator.py-add-new-non-free-firmware-component.patch
diff --git a/debian/tests/control b/debian/tests/control
index 4062764..956933f 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,4 +1,4 @@
 Tests: smoke
 Restrictions: needs-root
-Depends: command-not-found
+Depends: command-not-found, adduser
 
diff --git a/debian/tests/smoke b/debian/tests/smoke
index 4f0e5ae..7236ab2 100755
--- a/debian/tests/smoke
+++ b/debian/tests/smoke
@@ -10,7 +10,7 @@ apt-get update
 
 echo "Ensure we have results from c-n-f"
 /usr/lib/command-not-found --ignore-installed vim 2>&1 | grep vim
-/usr/lib/command-not-found --ignore-installed vim 2>&1 | grep vim-tiny
+/usr/lib/command-not-found --ignore-installed vim 2>&1 | grep "command '.*' 
from deb "
 
 
 echo "Add testuser"

Bug#1031782: Please don’t enforce --allow-dist-rename

[David Prévot]

Package: debmirror
Version: 1:2.35+deb11u1
Severity: normal
X-Debbugs-Cc: dpre...@evolix.fr

Hi,

Trying to mirror several suites from extended-lts currently fails with
the following output.

> The directory for a dist should be its codename, not a suite.
> Use --allow-dist-rename to have debmirror do the conversion automatically.

Using --omit-suite-symlinks unfortunately does not allow to bypass the
rename_distdir() call, so I had to comment those checks in order to
mirror extended-lts containing directory $suite and $suite-lts (e.g.,
stretch and stretch-lts) both set with “Suite: $suite” (e.g., Suite:
stretch).

Regards

David


signature.asc
Description: PGP signature

Bug#1028713: Comment

[Andreas Tille]

Hi,

I've put the test suite line below (and others) into some autopkgtest
and for the moment forced the build time test to pass[1] to get some
package to test.  I've built this and installed salmon as well as
salmon-dbgsym and was running the same test as Dominik via:

cp -a /usr/share/doc/salmon/examples/* .
gdb --args salmon index -t transcripts.fasta -i sample_salmon_quasi_index
(gdb) run
Starting program: /usr/bin/salmon index -t transcripts.fasta -i 
sample_salmon_quasi_index
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
index ["sample_salmon_quasi_index"] did not previously exist  . . . creating it
[2023-02-22 15:10:42.244] [jLog] [warning] The salmon index is being built 
without any decoy sequences.  It is recommended that decoy sequence (either 
computed auxiliary decoy sequence oor the genome of the organism) be provided 
during indexing. Further details can be found at 
https://salmon.readthedocs.io/en/latest/salmon.html#preparing-transcriptome-indices-mapping-bsased-mode.
[2023-02-22 15:10:42.244] [jLog] [info] building index
out : sample_salmon_quasi_index
[2023-02-22 15:10:42.244] [puff::index::jointLog] [info] Running fixFasta
[New Thread 0x757ff6c0 (LWP 2115402)]

[Step 1 of 4] : counting k-mers
[Thread 0x757ff6c0 (LWP 2115402) exited]

[2023-02-22 15:10:42.248] [puff::index::jointLog] [info] Replaced 0 non-ATCG 
nucleotides
[2023-02-22 15:10:42.248] [puff::index::jointLog] [info] Clipped poly-A tails 
from 0 transcripts
wrote 15 cleaned references

Thread 1 "salmon" received signal SIGSEGV, Segmentation fault.
rapidjson::PrettyWriter, 
rapidjson::UTF8, rapidjson::UTF8, rapidjson::CrtAllocator, 
2u>::StartObject (this=0x7fff8168) at 
/usr/include/rapidjson/prettywriter.h:113
113 new (Base::level_stack_.template Push()) 
typename Base::Level(false);
(gdb) bt 20
#0  rapidjson::PrettyWriter, 
rapidjson::UTF8, rapidjson::UTF8, rapidjson::CrtAllocator, 
2u>::StartObject (this=0x7fff8168)
at /usr/include/rapidjson/prettywriter.h:113
#1  cereal::JSONOutputArchive::writeName (this=0x7fff8030) at 
/usr/include/cereal/archives/json.hpp:347
#2  0x55b04428 in cereal::prologue (ar=...) at 
./external/pufferfish/include/cereal/archives/json.hpp:891
#3  cereal::OutputArchive::process 
(head=@0x7fff7d55: false, this=0x7fff8030) at 
./external/pufferfish/include/cereal/cereal.hpp:416
#4  cereal::OutputArchive::operator() 
(this=) at ./external/pufferfish/include/cereal/cereal.hpp:311
#5  cereal::save (t=..., ar=...) at 
./external/pufferfish/include/cereal/archives/json.hpp:944
#6  cereal::OutputArchive::processImpl, 
(cereal::traits::detail::sfinae)0> (t=..., this=)
at ./external/pufferfish/include/cereal/cereal.hpp:505
#7  cereal::OutputArchive::process > (head=..., this=) at 
./external/pufferfish/include/cereal/cereal.hpp:417
#8  cereal::OutputArchive::operator() > (this=0x7fff8030) at 
./external/pufferfish/include/cereal/cereal.hpp:311
#9  fixFasta (parser=0x76076800, decoyNames=..., keepDuplicates=false, 
k=31, sepStr=" \t", expect_transcriptome=true, noclip_polya=false, iomutex=..., 
log=std::shared_ptr (use count 4, weak count 0) = {...}, 
outFile="sample_salmon_quasi_index/ref_k31_fixed.fa", 
refIdExtensions=std::vector of length 15, capacity 15 = {...}, 
shortRefs=std::vector of length 0, capacity 0) at 
./external/pufferfish/src/FixFasta.cpp:456  o
#10 0x55b08195 in fixFastaMain (args=std::vector of length 7, capacity 
8 = {...}, refIdExtension=std::vector of length 15, capacity 15 = {...},
  s
shortRefs=std::vector of length 0, capacity 0, 
log=std::shared_ptr (use count 4, weak count 0) = {...}, 
hasFeatures=hasFeatures@entry=false)
at ./external/pufferfish/src/FixFasta.cpp:686
#11 0x55a8a510 in pufferfishIndex (indexOpts=...) at 
./external/pufferfish/src/PufferfishIndexer.cpp:432
#12 0x5566399e in SalmonIndex::buildPuffIndex_ (idxOpt=..., 
indexDir=..., this=0x7603e280) at ./include/SalmonIndex.hpp:111
#13 SalmonIndex::build (idxOpt=..., indexDir=..., this=0x7603e280) at 
./include/SalmonIndex.hpp:76
#14 salmonIndex (argc=, argv=) at 
./src/BuildSalmonIndex.cpp:247
#15 0x555fe9a0 in std::function 
>&)>::operator()(int, char const**, std::unique_ptr >&) const 
(__args#2=std::unique_ptr = {...}, __args#1=, 
__args#0=, this=0x7604e1a8)
at /usr/include/c++/12/bits/std_function.h:591
#16 main (argc=, argv=0x7fffde98) at ./src/Salmon.cpp:267


The traceback with the latest Pufferfish is different before

   ./include/SalmonIndex.hpp:111

Interestingly the old pufferfish (used by Dominik) triggers failures in
spdlog while the updated pufferfish above triggers the problem in
rapidjson.


I now tried to check the original upstream tarball, have built it via

> cmake -DCONDA_BUILD=1 -DFETCHED_RAPMAP=1 -DBZIP2_LIBRARIES=-lbz2 
>