Bug#1003372: ITP: oci-python-sdk -- Oracle Cloud Infrastructure Python SDK

[Paul Wise]

Control: outlook -1 blocked by 
https://github.com/oracle/oci-python-sdk/issues/444

Packaging oci-python-sdk is currently blocked by the extensive
vendoring/forking of Python libraries that upstream does.
Details are available in the bug I have filed upstream.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#1010416: ITP: python-ansible-compat -- Ansible compatibility goodies

[Josenilson Ferreira da Silva]

Package: wnpp
Severity: wishlist
Owner: Josenilson Ferreira da Silva 
X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com

* Package name: python-ansible-compat
  Version : 2.0.2
  Upstream Author : Sorin Sbarnea 
* URL : https://github.com/ansible/ansible-compat
* License : MIT
  Programming Lang: Python
  Description : Ansible compatibility goodies
  Python package contains functions that facilitate working
  with various versions of Ansible 2.9 and newer.

Bug#1010407: chromium: does not support older CPUs that lack SSE3 instructions

[Andres Salomon]

Okay, the next release will include the explicit check for SSE3:

https://salsa.debian.org/chromium-team/chromium/-/commit/836b9da55c776a27d884d0405f385dcb7ef6f12e

This is replacing the old check for SSE2.

Bug#1010415: www.debian.org: please slightly clarify description of 'grave' bug severity

[Andres Salomon]

Package: www.debian.org

Severity: wishlist


On https://www.debian.org/Bugs/Developer, the description for the 
severity level of grave reads, "makes the package in question unusable 
or mostly so, or causes data loss, or introduces a security hole 
allowing access to the accounts of users who use the package."


I believe that this confuses our users (and sometimes developers), who 
read that and think to themselves, "well this makes the package unusable 
FOR ME, therefore the severity must be grave." It's clear from the 
description of 'important' ("a bug which has a major effect on the 
usability of a package, without rendering it completely unusable to 
everyone") that the intention is for grave to apply to issues that make 
the package unusable FOR MOST USERS. I'm filing this bug because I keep 
seeing bugs filed as grave that make this mistake.


Therefore, I suggest modifying the language of the grave severity level 
description to read (with the new text between asterisks), "makes the 
package in question unusable *by most users*, or causes data loss, or 
introduces a security hole allowing access to the accounts of users who 
use the package.", with "or mostly so" being removed.



Reportbug's description for grave is "makes the package in question 
unusable by most or all users, or causes data loss, or introduces a 
security hole allowing access to the accounts of users who use the 
package."  Modifying the website language as I suggested would make it 
closer match the reportbug language.

Bug#1010369: RediSearch Upstream Needs Swapped out from version 1 to version 2

[Chris Lamb]

Hi,

> I see, that's too bad... is it easy to specify what the Redis Ltd would 
> need to change to make their license compatible?

Yes, but that's not quite the issue. They are already aware of the
situation and (to reduce a very long and complex discussion into a
single sentence) the license incompatibility is essentially deliberate
and not an accidental oversight.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1010414: libcec: reproducible builds: Embeds kernel version in libcec.so.*

[Vagrant Cascadian]

Source: libcec
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: kernel
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The running kernel of the build machine is embedded in libcec.so.*:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bookworm/amd64/diffoscope-results/libcec.html

  ./usr/lib/x86_64-linux-gnu/libcec.so.6.0.2

  
compiled·on·Linux-5.16.0-0.bpo.4-amd64·...·,·features:·P8_USB,·DRM,·P8_detect,·randr,·Exynos,·Linux,·AOCEC
vs.
  
compiled·on·Linux-5.10.0-13-amd64·...·,·features:·P8_USB,·DRM,·P8_detect,·randr,·Exynos,·Linux,·AOCEC


The attached patch updates the existing reproducible builds patch to use
CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM (which includes the running
kernel version).

With this patch applied, libcec should build reproducibly on
tests.reproducible-builds.org when it migrates to bookworm/testing!


To get it building reproducibly in unstable and experimental where
differing build paths are tested, it also needs to apply one of the
standard fixes mentioned here:

  
https://tests.reproducible-builds.org/debian/issues/cmake_rpath_contains_build_path_issue.html


I intend to fix both issues shortly.


Thanks for maintaining libcec!


live well,
  vagrant
From 9f3a10d425e92281399a669effdb76e24d02b6ae Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sat, 30 Apr 2022 23:55:26 +
Subject: [PATCH 2/2] debian/patches: Update reproducible build patch to use
 Use CMAKE_SYSTEM_NAME instead of CMAKE_SYSTEM.

CMAKE_SYSTEM contains the running kernel version, which is likely to
be different between two builds.

https://tests.reproducible-builds.org/debian/issues/unstable/captures_kernel_version_via_CMAKE_SYSTEM_issue.html
---
 debian/patches/03_reproducible_build.patch | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/patches/03_reproducible_build.patch b/debian/patches/03_reproducible_build.patch
index 8d995bb..3611c36 100644
--- a/debian/patches/03_reproducible_build.patch
+++ b/debian/patches/03_reproducible_build.patch
@@ -1,6 +1,7 @@
 Description: Remove non-determinism from build process
  .
 Author: Balint Reczey 
+Updated: Vagrant Cascadian 
 Forwarded: not-needed
 --- a/src/libcec/CMakeLists.txt
 +++ b/src/libcec/CMakeLists.txt
@@ -9,7 +10,7 @@ Forwarded: not-needed
  
  # platform and device specific
 -include(cmake/SetBuildInfo.cmake)
-+set(LIB_INFO "compiled on ${CMAKE_SYSTEM} ... ")
++set(LIB_INFO "compiled on ${CMAKE_SYSTEM_NAME} ... ")
  include(cmake/CheckPlatformSupport.cmake)
  
  ## create project groups
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#1010381: commons-daemon: FTBFS on riscv64: error: Unsupported CPU architecture "riscv64"

[tony mancill]

On Sun, May 01, 2022 at 12:59:27AM +0800, Bo YU wrote:
> On Sun, May 1, 2022 at 12:44 AM tony mancill  wrote:
> 
> > On Sun, May 01, 2022 at 12:39:02AM +0800, Bo YU wrote:
> > > > Thank you for the bug report and the patch.  I will perform an upload
> > of
> > > > this package soon.
> > > >
> > > > Thank you.
> > > I will try to send the patch for upstream also ;)
> >
> > Thank you!  Note that the Debian package is quite a bit behind upstream,
> > so I wonder whether the patch is even necessary against upstream version
> > 1.3.0.  (I have not checked yet.)
> >
> If i am not wrong:
> https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=blob_plain;f=src/native/unix/support/apsupport.m4;hb=HEAD
> 
> It seems that commons-daemon
> 
> upstream
> did not support riscv64.
> 
> Hmm, another story, in pabs review, deleting the architecture detection
> altogether is a better option from debian-riscv IRC channel talking about
> it.
> if so, this will push upstream to change a lot first i think. And i am not
> family with  the build system, maybe the java lang build does not
> detect on which arch buildng?

The Debian commons-daemon source package generates (2) binary packages:

Package: libcommons-daemon-java
Architecture: all

Package: jsvc
Architecture: any

So the jsvc package is architecture-specific.

I will start with applying your patch against the current source version
in Debian and then look at the upgrade.

Regards,
tony



signature.asc
Description: PGP signature

Bug#1010413: mocha: ftbfs with nodejs 16: workerpool needs to be updated

[Jérémy Lal]

Package: mocha
Version: 9.2.2+ds1+~cs28.3.8-1
Severity: important

Hi,
node-crc ftbfs with nodejs 16 because mocha's parallel mode does:
workerpool fails with:

TypeError: The "options" argument must be of type object. Received an instance 
of Array
at ChildProcess.target.send (node:internal/child_process:733:7)
at Array.forEach ()
at dispatchQueuedRequests 
(/usr/share/nodejs/workerpool/src/WorkerHandler.js:262:21)
at ChildProcess. 
(/usr/share/nodejs/workerpool/src/WorkerHandler.js:221:7)

After standard uscan update (that I pushed on salsa, please tell me if I can 
upload it),
and a patch to work around webpack < 5, node-crc builds fine with both nodejs 
14 and 16.

Jérémy



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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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)
LSM: AppArmor: enabled

Versions of packages mocha depends on:
ii  node-ansi-colors  4.1.1-3
ii  node-browser-stdout   1.3.1-6
ii  node-camelcase6.3.0-1
ii  node-chalk5.0.0-5
ii  node-chokidar 3.5.3-1
ii  node-ci-info [node-is-unicode-supported]  3.3.0+~cs4.2.0-1
ii  node-debug4.3.4+~cs4.1.7-1
ii  node-decamelize   4.0.0-1
ii  node-diff 5.0.0~dfsg+~5.0.1-3
ii  node-escape-string-regexp 4.0.0-2
ii  node-find-up  6.3.0-7
ii  node-glob 7.2.1+~cs7.6.15-2
ii  node-growl1.10.5-4
ii  node-he   1.2.0-3
ii  node-is-plain-obj 3.0.0-2
ii  node-js-yaml  4.1.0+dfsg+~4.0.5-6
ii  node-minimatch5.0.0+~3.0.5-2
ii  node-ms   2.1.3+~cs0.7.31-2
ii  node-postcss [node-nanoid]8.4.8+~cs7.3.21-2
ii  node-serialize-javascript 6.0.0-1
ii  node-strip-json-comments  4.0.0-4
ii  node-supports-color   8.1.1+~8.1.1-1
ii  node-which2.0.2+~cs1.3.2-2
ii  node-wide-align   1.1.3-4
ii  node-yargs16.2.0+~16.0.4-2
ii  node-yargs-parser 21.0.1+~21.0.0-1
ii  nodejs16.13.2+really14.19.1~dfsg-6+b1

mocha recommends no packages.

Versions of packages mocha suggests:
ii  chai  4.3.6~ds1+~cs9.7.12-3

-- no debconf information

Bug#1010407: chromium: Chromium immediately crashes on Illegal instruction on Buster i386

[Andres Salomon]

Severity: normal

Control: retitle 1010407 chromium: does not support older CPUs without 
SSE3 instructions


Tags: wontfix


Thanks for the report! It looks like chromium officially dropped older 
CPU support:


https://www.tomshardware.com/news/chrome-stops-working-on-old-processors

There's not much I can do about that unfortunately, and I wouldn't 
recommend using older versions of chromium due to security bugs. I 
suggest firefox?


I will add a test to the chromium script to refuse to run without sse3, 
though.



On 4/30/22 16:11, Gordon N. Squash wrote:

Package: chromium
Version: 90.0.4430.212-1~deb10u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I am using Debian Buster i386 on an Intel Pentium 4-based machine manufactured
in mid-2003.  The CPU is a Pentium 4 (Northwood) family 15, model 2, stepping
7.  It supports SSE and SSE2 but not SSE3, SSSE3, AVX, x86-64, or any other
jazz that many Web browsers tend to need these days.  Nevertheless, I know
that Debian versions of browsers tend to be compiled for much lower-specced
machines than even this one, and I've used slightly older versions of Chromium
(~ 85) here before, so I figured it'd work as usual.

I installed the latest version of Chromium for Buster (I intend to upgrade to
Bullseye soon).  I have used Chromium on this version of Debian and this
hardware before, specifically some versions between 80 and 85.  However, I
purged Chromium after using it the last time and also made a point of deleting
my Chromium profile in my home directory.  Therefore, I am quite confident
that my installation is not the cause of the problem here.

Immediately after installing chromium and chromium-sandbox, I ran Chromium
from a terminal window on my desktop environment (MATE).  The CPU usage spiked
for a few seconds, then fell down to zero again.  Chromium never displayed a
window at all; it crashed, and printed this in the terminal:

Received signal Illegal instruction

I ran Chromium with the --debug option, and when Chromium crashed again, I
used the gdb 'disassemble' command to see what the failing instruction was:

# Env:
# LD_LIBRARY_PATH=
#
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options 
--enable-gpu-rasterization --no-default-browser-check --disable-pings 
--media-router=0 --enable-remote-extensions --load-extension=
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.8dFo68
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
[etc]
Reading symbols from /usr/lib/chromium/chromium...(no debugging symbols 
found)...done.
(gdb) run
Starting program: /usr/lib/chromium/chromium 
--show-component-extension-options --enable-gpu-rasterization 
--no-default-browser-check --disable-pings --media-router=0 
--enable-remote-extensions --load-extension= --single-process
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xaf569b40 (LWP 2977)]
[Detaching after fork from child process 2978]
[Detaching after fork from child process 2979]
[New Thread 0xaebffb40 (LWP 2985)]
[New Thread 0xad673b40 (LWP 2986)]
[New Thread 0xace72b40 (LWP 2987)]
[New Thread 0xac671b40 (LWP 2988)]
[New Thread 0xabe70b40 (LWP 2989)]
[New Thread 0xab66fb40 (LWP 2990)]

Thread 6 "ThreadPoolForeg" received signal SIGILL, Illegal instruction.

[Switching to Thread 0xac671b40 (LWP 2988)]
0x05656790 in ?? ()
(gdb) disassemble 0x05656790,+16
Dump of assembler code from 0x5656790 to 0x56567a0:
=> 0x05656790:   fisttpll (%esp)
   0x05656793:  mov(%esp),%ecx
   0x05656796:  mov0x4(%esp),%edx
   0x0565679a:  mov%edx,0x4(%eax)
   0x0565679d:  mov%ecx,(%eax)
   0x0565679f:  jmp0x56567ba
End of assembler dump.
(gdb)

'fisttp' is an SSE3 instruction; my CPU does not support SSE3.  I would have
expected that Chromium would work on my old CPU since Firefox is specially
compiled (on Debian) to not use SSE3, and in fact if I'm not mistaken, Firefox
is compiled not to even need SSE2.  (Maybe it does now, I don't know.)  I
must use Chromium since some Web sites I visit (ironically, or maybe
appropriately, including intel.com) do not work correctly on Firefox or even
Webkit-based browsers like Midori; sadly I can't upgrade this old workhorse
right now.

Is there something I can do to get Chromium working?  Thanks in advance.

-- System Information:
Debian Release: 10.5
   APT prefers oldstable
   APT policy: (500, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages chromium depends on:
ii  

Bug#440253: Please package inform 7

[Diane Trout]

> Inform 7 is released piecemeal http://inform7.com/sources/>,
with
> many necessary components not yet released in source form at all.
> People hoping to see this in Debian will, it seems, need to be
patient
> with the upstream developers.
> 
> > Since Inform 7 seems to be an important development, it would be
> > nice to have it in Debian.
> 
> I agree. It will need to be a distinct package, though, as the
> ‘inform’ package is soon to be renamed ‘inform6’ to reflect its focus
> only on the Inform 6 system.


As an update it appears that Inform7 was fully open sourced under the
artistic public license with redistribution of derived works permission
included.

>From https://github.com/ganelson/inform
"As from the first date of this repository becoming public, 28 April
2022, the Package is placed under the Artistic License 2.0."

Bug#1010411: gucharmap: displaying characters white on white

[Simon McVittie]

Control: retitle -1 gucharmap: displaying characters white on white
Control: tags -1 + moreinfo unreproducible

On Sat, 30 Apr 2022 at 21:33:40 +, Ray Dillinger wrote:
> Gucharmap wants libc6 version 2.4, but
> installed without complaint even though I have libc6 version 2.33.

That's not an error: 4 is less than 33. Version numbers are tuples
compared component-by-component, not decimal, so 2.4 < 2.33 < 2.100 (and
2.4 is not the same as 2.40 or 2.4). glibc 2.4 is a version from
about 15 years ago.

In packages that have more than two components in their version numbers,
like GTK 3.24.33, it's more obvious that it can't be a decimal number,
but the correct version-comparison for libc6 works the same as it does
for GTK.

The maintainers of gucharmap are likely to need more information to
work out why it is drawing in white-on-white for you; it's working fine
for me (black symbols on a white background). The output of

reportbug --template gucharmap

would be a good start.

smcv

Bug#1003450: qemu-system: dns resolution does not work within the guest if the host have only nameserver in /etc/resolv.conf

[Michael Tokarev]

Version: 4.7.0-1

On Mon, 10 Jan 2022 12:40:59 +0100 mc36  wrote:

Package: qemu-system
Version: 1:6.2+dfsg-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
i recently moved to an ipv6-only network for testing purposes...

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
i ceased ipv4 completely from my desktop for a while...

   * What was the outcome of this action?
for example "qemu-system-x86_64 -enable-kvm -cdrom
debian-11.2.0-amd64-netinst.iso" cannot complete mirror selection because dns
resolution does not work within the guest when resolt.conf have only ipv6
entries...


It looks like this problem has been fixed in upstream version 4.7.0
(which I just uploaded but forgot to add the Closes: thisbug).

Thanks,

/mjt

Bug#1010410: node-tape: Cannot esm-import package 'tape'

[Jérémy Lal]

Package: node-tape
Version: 5.5.3+~cs8.20.16-1
Severity: important

tape's package.json probably needs some fix:

cat tmp.mjs 
import * as tape from 'tape'

node tmp.mjs

internal/process/esm_loader.js:74
internalBinding('errors').triggerUncaughtException(
  ^

Error [ERR_MODULE_NOT_FOUND]: Cannot find package 'tape' imported from 
/home/dev/tmp.mjs
Did you mean to import tape/index.js?



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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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)
LSM: AppArmor: enabled

Versions of packages node-tape depends on:
ii  node-debbundle-es-to-primitive   1.2.1+~cs9.7.25-2
ii  node-deep-equal  2.0.5+~cs32.11.68-3
ii  node-define-properties   1.1.3-3
ii  node-defined 1.0.0-3
ii  node-es-abstract 1.19.2+~cs16.20.24-1
ii  node-function-bind   1.1.1+repacked+~1.0.3-2
ii  node-glob7.2.1+~cs7.6.15-2
ii  node-inherits2.0.4-6
ii  node-istanbul0.4.5+repack10+~cs97.25.57-3
ii  node-minimatch   5.0.0+~3.0.5-2
ii  node-minimist1.2.6+~cs5.3.2-1
ii  node-object-inspect  1.11.0+~cs1.8.1-3
ii  node-resolve [node-object-keys]  1.22.0+~cs5.29.10-2
ii  node-resumer 0.0.0-5
ii  node-through 2.3.8+~cs0.0.30-1
ii  nodejs   16.13.2+really14.19.1~dfsg-6+b1

node-tape recommends no packages.

node-tape suggests no packages.

-- no debconf information

Bug#1010411: gucharmap installing without required version of libc6 (was: gucharmap displaying characters white on white)

[Ray Dillinger]

package: gucharmap
version:1:14.0.3

While preparing this bug report for the white-on-white characters, I
checked the versions of everything gucharmap depends on and I think I
found a packaging error.  Gucharmap wants libc6 version 2.4, but
installed without complaint even though I have libc6 version 2.33.

Packages gucharmap depends on:
libgucharmap  (I have 2.90-7)
dconf-settings-backend  |  gsettings-backend
   (I have dconf-gsettings-backend 0.40.0-3)
libatk1.0-0 (I have 1.0-0)
  >   libc6  2.4 (!!!  I have 2.33-7 !!! ) <=
libcairo2 (I have 1.16.0-5 )
libglib2.0-0 (I have 2.72.1-1 )
libgtk-3.0 (I have 3.24.33-1 )
libpango-1.1-0 (I have 1.50.6+ds-2 )
libpangocairo-1.0.0 (I have 1.50.6+ds-2 )

When I open gucharmap on my desktop machine, all characters are
displayed as empty white boxes.

If I select a character, the white background darkens and the white
character is visible.

When I use a different font, the white characters displayed in their
white boxes are rendered in the new font. 

I searched a lot of resources and read a lot of documentation and tried
a lot of things without success, but if this is actually just a
packaging bug that's all irrelevant.

I did a complete uninstall, then reinstalled, and I still have libc6
2.33, and gucharmap still lists libc6 2.4 as a requirement, and apt-get
and dpkg did not even question it.

And of course I still have gucharmap displaying all characters white on
white.  For now I'm blaming the packaging error, in sincere hopes that
fixing the packaging error fixes it.

Bear

Bug#1010393: installation-reports: No swap partition which disables hibernate

[Pascal-liste]

Le 30/04/2022 à 14:41, Andreas Tille wrote:


Partitions:
$ sudo df -Tl


"df" shows mounted filesystems, not partitions. And it does not need 
root privileges, so sudo is superfluous. If you want to show partitions 
and other block devices, use "lsblk" instead.



Filesystem  Type  1K-blocks   Used Available Use% Mounted on
udevdevtmpfs   32785108  0  32785108   0% /dev
tmpfs   tmpfs   6564204   1936   6562268   1% /run
/dev/mapper/Debian-root ext4 1919713600 1339815668 482308072  74% /
tmpfs   tmpfs  32821012  43540  32777472   1% /dev/shm
tmpfs   tmpfs  5120  4  5116   1% /run/lock
/dev/nvme0n1p2  ext2 481642 173328283329  38% /boot
/dev/nvme0n1p1  vfat 523248   3484519764   1% /boot/efi
tmpfs   tmpfs   6564200 72   6564128   1% 
/run/user/1454



The actual problem I'd like to report is that no swap partition was
created


There are mentions of a swap logical volume in partman's log.
Swap area not being a filesystem, df does not show it.

Bug#1010409: transition: openimageio

[Matteo F. Vescovi]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi Release Team!

I'm filing this transition bug report to track down the transition of
openimageio library.

Following the auto-openimageio checklist[1], here is the list of source
packages reverse-depending on openimageio and the results of the builds:

* blender_3.1.2+dfsg-1 => OK
* embree_3.13.3+dfsg-1 => OK
* olive-editor_20200620-2 => FTBFS (oiio-related)
* opencolorio_1.1.1~dfsg0-7.1 => FTBFS (oiio-related)

Both FTBFS seem to be caused by some changes in openimageio 2.3.x
compared to older 2.2.x version. In the specific case of opencolorio,
this is an old version that should be updated very soon, hopefully.

I'll file bug reports for those FTBFS and track any progress in added
support.

Thanks for your time and patience.


[1] https://release.debian.org/transitions/html/auto-openimageio.html


Ben file:

title = "openimageio";
is_affected = .depends ~ "libopenimageio2.2" | .depends ~ "libopenimageio2.3";
is_good = .depends ~ "libopenimageio2.3";
is_bad = .depends ~ "libopenimageio2.2";

-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#1010393: installation-reports: No swap partition which disables hibernate

[Andreas Tille]

Hi Steve,

Am Sat, Apr 30, 2022 at 09:17:18PM +0100 schrieb Steve McIntyre:
> >The actual problem I'd like to report is that no swap partition was
> >created which is probably fine if the box is featuring 64GB.  However,
> >this prevents from using hibernation feature which I'm missing now and
> >thus I probably need to re-install.  (/var/log/installer/partman.gz is
> >attached.)
> 
> Are you sure about this? When we built and tested the 11.2 release
> images, I'm fairly certain that partman will complain and ask you to
> double-check if you didn't make a swap partition...

I usually choose the default when doing the installation and I'm pretty
sure that there was no such question asked since I would have become
suspicious about a missing swap partition. 

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#1009791: mutt: change-folder no longer selects next folder with new mail

[Kevin J. McCarthy]

On Thu, Apr 28, 2022 at 01:36:10PM -0700, Kevin J. McCarthy wrote:
I don't know if you've compiled Mutt from git before, but if you are 
able and willing to try, I would appreciate hearing it that helped 
with your problem.


I've just released version 2.2.4 with a fix that I believe will also
address your issue.

When you have a chance to test against 2.2.4, would you mind updating this
ticket to confirm/deny that is the case?

Thank you,

-Kevin

Bug#1010408: ftbfs: Error: Failed to find "global.fs = fs;" in Go JS shim code

[Jérémy Lal]

Source: golang-github-evanw-esbuild
Version: 0.14.25-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

your package FTBFS, however a trivial upstream update fixes it (took me a 
minute to rebuild it).

Jérémy.


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

Kernel: Linux 5.17.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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)
LSM: AppArmor: enabled

Bug#1010256: Package

[Geert Stappers]

This ITP is severing it's purpose:
  Telling that is there an intent to package.


The packaging and upload can be done.  Yes, that is our common goal.


Future will tell which conflicts we have to resolve.
But we gonna cross that bridge when we are at the brigde.



Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#986130: ,fetchmailconf: No update/upgrade possible due to error

[Matthias Andree]

Does this warrant "grave"?

This looks like trying to configure fetchmailconf before fetchmail is
configured, and before fetchmail saw configuration. However why is
fetchmail being "restart"ed? It could not have been running before...

Bug#1010393: installation-reports: No swap partition which disables hibernate

[Steve McIntyre]

Hi Andreas

On Sat, Apr 30, 2022 at 02:41:33PM +0200, Andreas Tille wrote:
>Package: installation-reports
>Severity: important
>
>(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://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.2.0+nonfree/amd64/iso-dvd/firmware-11.2.0-amd64-DVD-1.iso
>Date: 
>
>Machine: frame.work
>Partitions: 
>$ sudo df -Tl
>Filesystem  Type  1K-blocks   Used Available Use% Mounted 
>on
>udevdevtmpfs   32785108  0  32785108   0% /dev
>tmpfs   tmpfs   6564204   1936   6562268   1% /run
>/dev/mapper/Debian-root ext4 1919713600 1339815668 482308072  74% /
>tmpfs   tmpfs  32821012  43540  32777472   1% /dev/shm
>tmpfs   tmpfs  5120  4  5116   1% /run/lock
>/dev/nvme0n1p2  ext2 481642 173328283329  38% /boot
>/dev/nvme0n1p1  vfat 523248   3484519764   1% /boot/efi
>tmpfs   tmpfs   6564200 72   6564128   1% 
>/run/user/1454

...

>The actual problem I'd like to report is that no swap partition was
>created which is probably fine if the box is featuring 64GB.  However,
>this prevents from using hibernation feature which I'm missing now and
>thus I probably need to re-install.  (/var/log/installer/partman.gz is
>attached.)

Are you sure about this? When we built and tested the 11.2 release
images, I'm fairly certain that partman will complain and ask you to
double-check if you didn't make a swap partition...

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
 Privacy is an inherent human right, and a requirement for maintaining
 the human condition with dignity and respect."
  -- Bruce Schneier

Bug#1010406: Acknowledgement (wrong init script, dpkg -i defaultly does init.d restart action, but packages init script has 'exit 3' on restart action, so dpkg -i fails)

[alex ratchev]

i have forgotten, to add, i use sysvinit

thank you..

On Sat, Apr 30, 2022, 22:12 Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1010406:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010406.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Khalid Aziz 
>
> If you wish to submit further information on this problem, please
> send it to 1010...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1010406: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010406
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1010405: debian-history: typo "Several [...] server"

[Jakub Wilk]

Package: debian-history
Version: 2.26
Severity: minor
Tags: patch

--
Jakub Wilk
From d3c50db43d19168719874a02866e97781a0f97fa Mon Sep 17 00:00:00 2001
From: Jakub Wilk 
Date: Sat, 30 Apr 2022 22:07:10 +0200
Subject: [PATCH] Fix typo

---
 project-history.en.dbk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/project-history.en.dbk b/project-history.en.dbk
index ebba701..c6145da 100644
--- a/project-history.en.dbk
+++ b/project-history.en.dbk
@@ -1821,7 +1821,7 @@ recently moved from the U.S.A.  to the Netherlands.
 
 
 
-November 2003: Several Debian server hacked
+November 2003: Several Debian servers hacked
 
 Starting 17:00 UTC on November 19th, 2003, four of the project's main
 Web servers for bug tracking, mailing lists, security and Web searches
-- 
2.36.0

Bug#1010406: wrong init script, dpkg -i defaultly does init.d restart action, but packages init script has 'exit 3' on restart action, so dpkg -i fails

[alex ratchev]

Package: kexec-tools
Version: unstable

.. in dpkg --configure step by apt-get install fails on restart.action ( of
the init script ) cause 'the package maintainers wrote officially the
script doesnt need it so the maintainer done all rigjt , .. =p'

fix.. i couldnt get around removing set -e or changing the exit 3 line to
exit 0

greets

Bug#1010404: wrong init scripts, dokg -i issues restart but cause not running exit

[alex ratchev]

Package: docker.io, prometheus-node-exporter

Version: unstable


i install sometimes those for a mate, and to say it happens in 65% of the
cases ( is bugged )

then dpkg -i by apt issues straight init restart ( invoke-rc.d restart )
but as its a new fresh install it doesnt run and restart stop start fails
with wrong exit code

fix, after apt failed run /etc/init.d/ start
and run apt-get -f install

to mention about my minimal debian setup, its either upgraded from whatever
old or new debootstrap'ed
to -> unstable ( i use all 5 trees in sources.list tho ( since 2002 plz
dont bugg me ) )
also, i ditch systemd* ( excepts udevd ), in favor of old simple sysvinit

once the error disappeared when i --pruge'd n libnss-systemd and i thought
that was a fix but on further boxen this didnt help
also, the error ( i think to 75% 'imho' ) doesnt appear when plain
installed via debootstrap and the earlier only sysvinit the lesser the bug
chance

Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

[Cyril Brulebois]

Control: tag -1 upstream
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=215925

Hi Bjørn,

Bjørn Mork  (2022-04-30):
> But that's a merge commit. Not likely the real cuplrit, unless there's
> a merge bug.
> 
> I looked briefly at what was merged there, and I believe this commit
> stands out as suspicious:
> 
> bjorn@miraculix:/usr/local/src/git/linux$ git show f59f6aaead97
> commit f59f6aaead975f0ec4d8ff2d59c4ffb8cf0127b2
> Author: Arnd Bergmann 
> Date:   Mon Nov 22 23:21:56 2021 +0100
> 
> mmc: bcm2835: stop setting chan_config->slave_id

Yeah, I skipped a bunch of details in my last mail since I've tried
various things (including reverting that one I spotted, plus the few
commits around it since it was part of removing that field altogether)
but didn't get any consistent results.

My methodology was probably fragile since I worked incrementally, and I
suppose I got some wires crossed at some point. Sorry for the confusion.


I've redone this entirely, and here are better (and reproducible, this
time) findings:

 - 830aa6f29f07a4e2f1a947dfa72b3ccddb46dd21 breaks the boot, leading to
   a kernel panic very early in the boot process; I'm seeing the trace
   on the screen, not on the serial console. It involves the modified
   brcm_pcie_driver_init() function, so that's quite consistent.

 - 87c71931633bd15e9cfd51d4a4d9cd685e8cdb55 is the last commit
   exhibiting the kernel panic (further in that branch, before it gets
   merged into mainline).

 - 88db8458086b1dcf20b56682504bdb34d2bca0e2 is the last commit that lets
   the CM4 boots properly.

 - d0a231f01e5b25bacd23e6edc7c979a18a517b2b, which is the merge of the
   last two aforementioned commits, is the first one that results in
   a completely black screen (no kernel panic displayed), and still
   nothing on the serial console. It seems to me that the kernel panic
   escalates into a more serious issue after this merge. I note there
   are conflict resolutions about drivers/pci/controller/pcie-brcmstb.c
   in that commit.


No luck with latest master. I've filed this upstream (see link above).


Cheers,
-- 
Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/


signature.asc
Description: PGP signature

Bug#1010148: openmsx: patch for ftbfs on riscv64

[Dr. Bas Wijnen]

Thanks for the patch. I'm on vacation at the moment. I'll upload it after next
week, unless the new release is out sooner, in which case I'll upload that
which apparently also fixes this problem.

On Mon, Apr 25, 2022 at 07:07:02PM +0800, Bo YU wrote:
> Package: openmsx
> Version: 17.0-2
> Followup-For: Bug #1010148
> Control: tags -1 patch
> 
> Dear Maintainer,
> 
> sorry, I don't know why can attach patch if `repotbug --mutt`?
> send patch again.

> Last-Update: 2022-04-25
> 
> --- openmsx-17.0.orig/build/detectsys.py
> +++ openmsx-17.0/build/detectsys.py
> @@ -53,6 +53,8 @@ def detectCPU():
>   return 'sheb' if cpu.endswith('eb') else 'sh'
>   elif cpu == 'avr32':
>   return 'avr32'
> + elif cpu == 'riscv64':
> + return 'riscv64'
>   elif cpu == '':
>   # Python couldn't figure it out.
>   os = system().lower()



signature.asc
Description: PGP signature

Bug#1010403: locales: The locale for Switzerland in english is missing (en_CH)

[Lorenzo]

Package: locales
Version: 2.31-13+deb11u3
Severity: normal
X-Debbugs-Cc: flyer1...@gmail.com

Dear Maintainer,

It's common in Switzerland to use debian in english, but maintaining the metric 
system unit, currency and the european way of writing the date.
In the attachement file there is a possible locale template to include in the 
official package.

*** Desktop/en_CH
comment_char %
escape_char /

% This file is part of the GNU C Library and contains locale data.
% The Free Software Foundation does not claim any copyright interest
% in the locale data contained in this file.  The foregoing does not
% affect the license of the GNU C Library as a whole.  It does not
% exempt you from the conditions of the license if your use would
% otherwise be governed by that license.

% English language locale for Switzerland
% Source: RAP
% Address: Sankt Jo//rgens Alle 8
%DK-1615 Ko//benhavn V, Danmark
% Contact: Keld Simonsen
% Email: keld.simon...@dkuug.dk
% Tel: +45 - 31226543
% Fax: +45 - 33256543
% Language: en
% Territory: CH
% Revision: 4.3
% Date: 1996-10-15
% Users: general

LC_IDENTIFICATION
title  "English locale for Switzerland"
source "RAP"
address""
contact""
email  "bug-glibc-loca...@gnu.org"
tel""
fax""
language   "Swiss English"
territory  "Switzerland"
revision   "1.0"
date   "2022-04-30"

category "i18n:2012";LC_IDENTIFICATION
category "i18n:2012";LC_CTYPE
category "i18n:2012";LC_COLLATE
category "i18n:2012";LC_TIME
category "i18n:2012";LC_NUMERIC
category "i18n:2012";LC_MONETARY
category "i18n:2012";LC_MESSAGES
category "i18n:2012";LC_PAPER
category "i18n:2012";LC_NAME
category "i18n:2012";LC_ADDRESS
category "i18n:2012";LC_TELEPHONE
category "i18n:2012";LC_MEASUREMENT
END LC_IDENTIFICATION

LC_CTYPE
copy "i18n"

translit_start
include "translit_combining";""
translit_end
END LC_CTYPE

LC_COLLATE
% Copy the template from ISO/IEC 14651
copy "iso14651_t1"
END LC_COLLATE

LC_MONETARY
copy  "de_CH"
END LC_MONETARY

LC_NUMERIC
copy "de_CH"
END LC_NUMERIC

LC_TIME
abday   "Sun";"Mon";"Tue";"Wed";"Thu";"Fri";"Sat"
day "Sunday";/
"Monday";/
"Tuesday";/
"Wednesday";/
"Thursday";/
"Friday";/
"Saturday"
abmon   "Jan";"Feb";/
"Mar";"Apr";/
"May";"Jun";/
"Jul";"Aug";/
"Sep";"Oct";/
"Nov";"Dec"
mon "January";/
"February";/
"March";/
"April";/
"May";/
"June";/
"July";/
"August";/
"September";/
"October";/
"November";/
"December"
d_t_fmt "%a %d %b %Y %T"
date_fmt"%a %d %b %Y %T %Z"
d_fmt   "%d. %m. %y"
t_fmt   "%T"
am_pm   "";""
t_fmt_ampm  ""
week7;19971130;4
first_weekday 2
END LC_TIME

LC_MESSAGES
copy "en_US"
END LC_MESSAGES

LC_PAPER
copy "i18n"
END LC_PAPER

LC_TELEPHONE
tel_int_fmt"+%c %a %l"
int_select "00"
int_prefix "41"
END LC_TELEPHONE

LC_MEASUREMENT
copy "i18n"
END LC_MEASUREMENT

LC_NAME
copy "en_US"
END LC_NAME

LC_ADDRESS
postal_fmt"%f%N%a%N%d%N%b%N%s %h %e %r%N%z %T%N%c%N"
country_name "Switzerland"
country_ab2   "CH"
country_ab3   "CHE"
country_num   756
country_car"CH"
country_post "CH"
country_isbn "979-10"
lang_name "English"
lang_ab  "en"
lang_term"eng"
lang_lib"eng"
END LC_ADDRESS


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

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

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.77
ii  libc-bin   2.31-13+deb11u3
ii  libc-l10n  2.31-13+deb11u3

locales recommends no packages.

locales suggests no packages.

-- debconf information:
* locales/locales_to_be_generated: en_US.UTF-8 UTF-8
* locales/default_environment_locale: en_US.UTF-8

Bug#1010112: virtualbox: 6.1.34-dfsg-2 broken, guest VM display window stays black with blinking cursor

[nbi]

False alarm. The answer is given here: 
https://forums.virtualbox.org/viewtopic.php?f=7=105468


In my case after exiting QEMU-KVM virt-manager the qemu-system-x86 and 
kvm-nx-lpage-re processes remain live. Since only one hypervisor is 
active at a time the fix is to simply kill these processes when QEMU-KVM 
is not in use - and the VirtualBox VMs start just fine. Hope this helps 
someone else who might get tripped up by this.



On Fri, 29 Apr 2022 11:57:02 -0700 nbi  wrote:
> You upgraded to 6.1.34-dfsg-2 from what? 6.1.32 or an earlier version?
> How did you upgrade? dpkg, apt, or Synaptic?
>
> On Tue, 26 Apr 2022 03:24:46 +0300 Alexander Kernozhitsky
>  wrote:
> > Hello,
> >
> > I just upgraded to 6.1.34-dfsg-2, and for me everything worked fine,
> guest
> > systems start normally.
> >
> > Did you try to downgrade the package and ensure that the bug is done
> after
> > downgrade?
> >
> > --
> > Alexander Kernozhitsky
> >
> >
> >
> >
>
>
>

Bug#1010402: debmake-doc: Quilt configuration leads to shell error

[Philippe SWARTVAGHER]

Package: debmake-doc
Version: 1.17-4
Severity: normal
Tags: upstream patch

Dear Maintainer,

I followed the instructions provided in this doc to setup (d)quilt,
especially the content of the ~/.quiltrc-dpkg file. But when I used
dquilt, the following error appeared:

% dquilt new fix-meson-build.patch
/home/philippe/.quiltrc-dpkg: ligne 10: + : commande introuvable
Le patch fix-meson-build.patch est maintenant au sommet

Indeed the + sign in the value of the QUILT_COLORS env var is understood
by shells (at least Bash and ZSH) as an external (unknown) command.

I provide a patch where the QUILT_COLORS value is not split accross two
lines (as it is done in
https://www.debian.org/doc/manuals/maint-guide/modify.fr.html#quiltrc).

Philippe.
From 7d7a0f386f0efa3d18512d15ddd6aa6d71a81ef8 Mon Sep 17 00:00:00 2001
From: Philippe SWARTVAGHER 
Date: Sat, 30 Apr 2022 19:16:00 +0200
Subject: [PATCH] Fix quilt configuration

The + sign splitting the QUILT_COLORS string is interpreted by shells
(at least Bash and ZSH) like a (unknown) command.
---
 asciidoc/12-setups.txt | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/asciidoc/12-setups.txt b/asciidoc/12-setups.txt
index 0bf5160..2a390ab 100644
--- a/asciidoc/12-setups.txt
+++ b/asciidoc/12-setups.txt
@@ -88,8 +88,7 @@ if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then
 QUILT_PATCH_OPTS="--reject-format=unified"
 QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
 QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
-QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:" + \
-"diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33"
+QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33"
 if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi
 fi
 

base-commit: 7cf5b2587bf79036de5c56543df76b5de0965f18
-- 
2.36.0

Bug#1007884: bullseye-pu: package glewlwyd/2.5.2-2+deb11u2

[Nicolas Mora]

Hello,

Is it possible to review the patch, so the package in bullseye can be in 
p-u?


Thanks!

Bug#1010381: commons-daemon: FTBFS on riscv64: error: Unsupported CPU architecture "riscv64"

[Bo YU]

On Sun, May 1, 2022 at 12:44 AM tony mancill  wrote:

> On Sun, May 01, 2022 at 12:39:02AM +0800, Bo YU wrote:
> > > Thank you for the bug report and the patch.  I will perform an upload
> of
> > > this package soon.
> > >
> > > Thank you.
> > I will try to send the patch for upstream also ;)
>
> Thank you!  Note that the Debian package is quite a bit behind upstream,
> so I wonder whether the patch is even necessary against upstream version
> 1.3.0.  (I have not checked yet.)
>
If i am not wrong:
https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=blob_plain;f=src/native/unix/support/apsupport.m4;hb=HEAD

It seems that commons-daemon

upstream
did not support riscv64.

Hmm, another story, in pabs review, deleting the architecture detection
altogether is a better option from debian-riscv IRC channel talking about
it.
if so, this will push upstream to change a lot first i think. And i am not
family with  the build system, maybe the java lang build does not
detect on which arch buildng?

Bug#743228: ifupdown: IPv6 Address doesn't get configured at/after boot

[Kitamare - Helpdesk]

Can you give me some what to do to not get the link local addresses only.


Could you please give us the output of `ifup eth0.2 -v`?



Sure, but as in the ticket it just does not work at boot time. When I bring the
interface manually down and then up again it works as supposed. Should I try to
switch to ifupdown2?

» ifup eth0.2 -v
ifup: reading directory /etc/network/interfaces.d
ifup: interface eth0.2 already configured


» ifdown eth0.2 -v && ifup eth0.2 -v
ifdown: reading directory /etc/network/interfaces.d
ifdown: configuring interface eth0.2=eth0.2 (inet)
/bin/run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/resolvconf
run-parts: executing /etc/network/if-down.d/wpasupplicant
 /sbin/ip route del default via 192.xxx.xxx.xxx  dev eth0.2 2>&1 1>/dev/null || 
true
/sbin/ip addr del 192.xxx.xxx.xxx/255.255.255.0 broadcast 192.xxx.xxx.255   
 eth0.2 label eth0.2
/bin/run-parts --verbose /etc/network/if-post-down.d
run-parts: executing /etc/network/if-post-down.d/vlan
run-parts: executing /etc/network/if-post-down.d/wireless-tools
run-parts: executing /etc/network/if-post-down.d/wpasupplicant
ifdown: configuring interface eth0.2=eth0.2 (inet6)
/bin/run-parts --verbose /etc/network/if-down.d
run-parts: executing /etc/network/if-down.d/resolvconf
run-parts: executing /etc/network/if-down.d/wpasupplicant
/sbin/ip -6 addr flush dev eth0.2 scope global
/bin/run-parts --verbose /etc/network/if-post-down.d
run-parts: executing /etc/network/if-post-down.d/vlan
run-parts: executing /etc/network/if-post-down.d/wireless-tools
run-parts: executing /etc/network/if-post-down.d/wpasupplicant
if test `cat /sys/class/net/eth0/type` -eq 32; then echo 0x2 > 
/sys/class/net/eth0/delete_child; else /sbin/ip link del eth0.2; fi

ifup: reading directory /etc/network/interfaces.d
if test -d /sys/class/net/eth0 && ! ip link show eth0.2 >/dev/null 2>&1;   
  then if test `cat /sys/class/net/eth0/type` -eq 32; then echo 0x2 > 
/sys/class/net/eth0/create_child; else /sbin/ip link set up dev eth0;
 /sbin/ip link add link eth0 name eth0.2 type vlan id 2;   fi; fi

ifup: configuring interface eth0.2=eth0.2 (inet)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/vlan
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
/sbin/ip addr add 192.xxx.xxx.xxx/255.255.255.0 broadcast 192.xxx.xxx.255   
 eth0.2 label eth0.2
 /sbin/ip route add default via 192.xxx.xxx.xxx  dev eth0.2 onlink
/bin/run-parts --exit-on-error --verbose /etc/network/if-up.d
run-parts: executing /etc/network/if-up.d/000resolvconf
run-parts: executing /etc/network/if-up.d/ethtool
run-parts: executing /etc/network/if-up.d/ip
run-parts: executing /etc/network/if-up.d/wpasupplicant
ifup: configuring interface eth0.2=eth0.2 (inet6)
/bin/run-parts --exit-on-error --verbose /etc/network/if-pre-up.d
run-parts: executing /etc/network/if-pre-up.d/ethtool
run-parts: executing /etc/network/if-pre-up.d/vlan
run-parts: executing /etc/network/if-pre-up.d/wireless-tools
run-parts: executing /etc/network/if-pre-up.d/wpasupplicant
/sbin/modprobe -q net-pf-10 > /dev/null 2>&1 || true # ignore failure.

/sbin/sysctl -q -e -w net.ipv6.conf.eth0/2.accept_ra=2
/sbin/sysctl -q -e -w net.ipv6.conf.eth0/2.autoconf=1
/sbin/ip link set dev eth0.2 up
/lib/ifupdown/wait-for-ll6.sh
/sbin/dhclient -6 -v -P -pf /run/dhclient6.eth0.2.pid -lf 
/var/lib/dhcp/dhclient6.eth0.2.leases -I -df 
/var/lib/dhcp/dhclient.eth0.2.leases eth0.2
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/


###
IPV6 prefix delegation script in
/etc/dhcp/dhclient-exit-hooks.d/prefix_delegation
reason 'PREINIT6'
nothing to do
###

Listening on Socket/eth0.2
Sending on   Socket/eth0.2
PRC: Confirming active lease (INIT-REBOOT).
XMT: Forming Rebind, 0 ms elapsed.
XMT:  X-- IA_PD 32:b2:18:78
XMT:  | X-- Requested renew  +3600
XMT:  | X-- Requested rebind +5400
XMT:  | | X-- IAPREFIX dead:beef:3630:fc::/62
XMT:  | | | X-- Preferred lifetime +7200
XMT:  | | | X-- Max lifetime +7500
XMT:  V IA_PD appended.
XMT: Rebind on eth0.2, interval 940ms.
RCV: Reply message on eth0.2 from fe80:::70ff::fef.
RCV:  X-- Preference 0.
RCV:  X-- IA_PD 32:b2:18:78
RCV:  | X-- starts 1651311586
RCV:  | X-- t1 - renew  +1800
RCV:  | X-- t2 - rebind +2880
RCV:  | X-- [Options]
RCV:  | | X-- IAPREFIX 2a0a:a547:3630:fc::/62
RCV:  | | | X-- Preferred lifetime 3600.
RCV:  | | | X-- Max lifetime 7200.
RCV:  X-- Server ID: 00:03:00:01:xx:xx:70:xx:0f:xx
PRC: Bound 

Bug#1010381: commons-daemon: FTBFS on riscv64: error: Unsupported CPU architecture "riscv64"

[tony mancill]

On Sun, May 01, 2022 at 12:39:02AM +0800, Bo YU wrote:
> > Thank you for the bug report and the patch.  I will perform an upload of
> > this package soon.
> >
> > Thank you.
> I will try to send the patch for upstream also ;)

Thank you!  Note that the Debian package is quite a bit behind upstream,
so I wonder whether the patch is even necessary against upstream version
1.3.0.  (I have not checked yet.)

Bug#1010381: commons-daemon: FTBFS on riscv64: error: Unsupported CPU architecture "riscv64"

[Bo YU]

HI,

On Sun, May 1, 2022 at 12:32 AM tony mancill  wrote:

> On Sat, Apr 30, 2022 at 11:11:02AM +0800, Bo YU wrote:
> > Source: commons-daemon
> > Version: 1.0.15-8
> > Severity: normal
> > Tags: ftbfs patch
> > User: debian-ri...@lists.debian.org
> > Usertags: riscv64
> > X-Debbugs-Cc: debian-ri...@lists.debian.org
> >
> > configure:3126: checking C flags dependant on host system type
> > configure:3294: result: failed
> > configure:3296: error: Unsupported CPU architecture "riscv64"
> > ...
> > ```
> > The full buildd log is:
> >
> https://buildd.debian.org/status/fetch.php?pkg=commons-daemon=riscv64=1.0.15-8=1558276470=0
> >
> > The attach patch is for supporting build on riscv64. And I have tested
> it locally
> > that is ok. If you need me to do some extra tests please tell me.
> >
> > BR,
> > Bo
>
> Hello Bo,
>
> Thank you for the bug report and the patch.  I will perform an upload of
> this package soon.
>
> Thank you.
I will try to send the patch for upstream also ;)

BR,
Bo

> Cheers,
> tony
>

Bug#1010104: cqrlog: missing AppStream metadata

[tony mancill]

On Fri, Apr 29, 2022 at 01:52:42PM +0200, asciiw...@seznam.cz wrote:
> On Tue, 26 Apr 2022 20:44:10 -0700 tony mancill  wrote:
> > On Sun, Apr 24, 2022 at 03:58:48PM +0200, asciiw...@seznam.cz wrote:
> > > Package: cqrlog
> > > Version: 2.5.2-1
> > >
> > > The cqrlog package has no AppStream metadata file although this file is 
> > > already present in upstream[1]. Please, consider adding this file.
> > >
> > > [1] https://github.com/ok2cqr/cqrlog/blob/master/tools/cqrlog.appdata.xml
> >
> > Hi,
> >
> > I see the file in the current Debian package:
> >
> > $ debc cqrlog_2.5.2-1_amd64.changes | grep appdata.xml
> > -rw-r--r-- root/root  1266 2022-01-11 08:26 
> > ./usr/share/metainfo/cqrlog.appdata.xml
> >
> > And I also see the metadata registered for bookworm (Debian testing):
> >
> > https://appstream.debian.org/bookworm/main/metainfo/cqrlog.html
> >
> > Is there some other place where it should be included?
> >
> > Cheers,
> > tony
> 
> Hi,
> 
> ah, the AppData file seems to be in the cqrlog-data package (along with 
> desktop icon files), not the main cqrlog one. I am however not sure whether 
> this is supported by GNOME Software / KDE Discover and the Debian/Ubuntu 
> AppStream generator itself[1]. GNOME Software on Ubuntu 22.04 (which uses 
> cqrlog 2.5.2-1 package synced from Debian) does not seem to display valid 
> metadata for the cqrlog package - it uses autogenerated metadata from its 
> desktop file (and no icon) instead.

Hi Daniel,

:facepalm:  I didn't look closely enough.  Thank you for pointing this
out.  Since cqrlog depends on cqrlog-data with the same source version,
I think this should be fairly simple to move into cqrlog.

I will have a go at it later this weekend.

Cheers,
tony
> 
> Daniel
> 
> [1] https://appstream.debian.org/bookworm/main/issues/cqrlog.html
> 

Bug#1010381: commons-daemon: FTBFS on riscv64: error: Unsupported CPU architecture "riscv64"

[tony mancill]

On Sat, Apr 30, 2022 at 11:11:02AM +0800, Bo YU wrote:
> Source: commons-daemon
> Version: 1.0.15-8
> Severity: normal
> Tags: ftbfs patch
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
> X-Debbugs-Cc: debian-ri...@lists.debian.org
> 
> configure:3126: checking C flags dependant on host system type
> configure:3294: result: failed
> configure:3296: error: Unsupported CPU architecture "riscv64"
> ...
> ```
> The full buildd log is:
> https://buildd.debian.org/status/fetch.php?pkg=commons-daemon=riscv64=1.0.15-8=1558276470=0
> 
> The attach patch is for supporting build on riscv64. And I have tested it 
> locally
> that is ok. If you need me to do some extra tests please tell me.
> 
> BR,
> Bo

Hello Bo,

Thank you for the bug report and the patch.  I will perform an upload of
this package soon.

Cheers,
tony

Bug#994976: xtermcontrol: please make the build reproducible

[Chris Lamb]

Hi Vagrant,

>> +PACKAGE_YEAR = $(shell date --utc --date=@$(SOURCE_DATE_EPOCH) '+%Y')
>> +PACKAGE_DATE = $(shell date --utc --date=@$(SOURCE_DATE_EPOCH) +'%B %d, %Y')
>
> I think this should use %Y-%m-%d instead, as %B is a locale-dependent
> month name.

I was likely copying the existing output — more likely that the patch
would be applied! But you are absolutely right: this needs something
like LC_ALL=C or something.

> This package appears to be part of the QA team, so could be uploaded by
> anyone... I'd consider uploading the fix, unless you'd like to do the
> honors?

I'll get onto it. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#1010400: printrun: Pronterface crashes under python 3.10

[Renzo Davoli]

Package: printrun
Version: 2.0.0~rc8-1
Severity: important
Tags: upstream
X-Debbugs-Cc: re...@cs.unibo.it

Dear Maintainer,

The bug should have been fixed in upstream git:
https://github.com/kliment/Printrun/issues/1225

$ pronterface 
WARNING:root:Could not setup DBus for sleep inhibition: 
org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ScreenSaver 
was not provided by any .service files
Traceback (most recent call last):
  File "/usr/bin/pronterface", line 62, in 
app = PronterApp(False)
  File "/usr/lib/python3/dist-packages/printrun/pronterface.py", line 2455, in 
__init__
self.mainwindow = PronterWindow(self)
  File "/usr/lib/python3/dist-packages/printrun/pronterface.py", line 219, in 
__init__
self.reload_ui()
  File "/usr/lib/python3/dist-packages/printrun/pronterface.py", line 293, in 
reload_ui
self.createGui(self.settings.uimode == _("Compact"),
  File "/usr/lib/python3/dist-packages/printrun/gui/__init__.py", line 259, in 
createGui
viz_pane = VizPane(self, vizpanel)
  File "/usr/lib/python3/dist-packages/printrun/gui/viz.py", line 115, in 
__init__
root.gwindow = gviz.GvizWindow(build_dimensions = 
root.build_dimensions_list,
  File "/usr/lib/python3/dist-packages/printrun/gviz.py", line 77, in __init__
self.p = Gviz(panel, size = size, build_dimensions = build_dimensions, grid 
= grid, extrusion_width = extrusion_width, bgcolor = bgcolor, realparent = self)
  File "/usr/lib/python3/dist-packages/printrun/gviz.py", line 197, in __init__
self.mainpen = wx.Pen(wx.Colour(0, 0, 0), penwidth)
TypeError: Pen(): arguments did not match any overloaded call:
  overload 1: too many arguments
  overload 2: argument 2 has unexpected type 'float'
  overload 3: argument 1 has unexpected type 'Colour'


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

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

Versions of packages printrun depends on:
ii  plater   2.0.0~rc8-1
ii  printcore2.0.0~rc8-1+b1
ii  pronsole 2.0.0~rc8-1
ii  pronterface  2.0.0~rc8-1

printrun recommends no packages.

printrun suggests no packages.

-- no debconf information

Bug#1003168: qemu-user-static: fails to run lyx user directory configuation

[Michael Tokarev]

Control: tag -1 + moreinfo

On Thu, 13 Jan 2022 16:00:26 +0100 Andreas Beckmann  wrote:

On 11/01/2022 08.25, Michael Tokarev wrote:
> 1. try qemu 6.2 (qemu-user-static is self-contained, more or less, so
>     it can be installed on earlier debian releases too)

same behavior :-(

> 2. try to figure out what exactly is failing in there:
> 
>> support/Systemcall.cpp (276): Systemcall: 'python3 -tt 
>> "/usr/share/lyx/configure.py" --binary-dir="/usr/bin/"' finished with 
>> exit code -1


# t=$(mktemp -d) && cd $t && python3 -tt "/usr/share/lyx/configure.py" 
--binary-dir="/usr/bin/" ; cd -

Succeeds :-(

But if that command gets executed from lyx, we are in the realm of Qt::Process.
Perhaps if I find time, I can try to extract a minimized example only doing 
that call...


Hi Andreas!

Do you know if this issue still present with qemu 7.0?

Thanks,

/mjt

Bug#679211: cntlm does not properly handle non-HTTP/1.1 keep-alive

[Gianfranco Costamagna]

control: tags -1 pending

Uploaded
On Thu, 02 Aug 2012 14:47:31 +0200 Graham Inggs  wrote:

tags 679211 patch
thanks

Attached is a cherry-pick of changes in upstream revision 306 excluding 
those relating to more detailed debug logging and compiler warnings.
diff -u cntlm-0.92.3/debian/changelog cntlm-0.92.3/debian/changelog
--- cntlm-0.92.3/debian/changelog
+++ cntlm-0.92.3/debian/changelog
@@ -1,3 +1,14 @@
+cntlm (0.92.3-1.2) unstable; urgency=medium
+
+  [ Gianfranco Costamagna ]
+  * Non-maintainer upload
+
+  [ Graham Inggs ]
+  * Cherry-pick r306 from 0.93 to properly handle non-HTTP/1.1 keep-alive
+(LP: #1009436 Closes: #679211)
+
+ -- Gianfranco Costamagna   Sat, 30 Apr 2022 
15:19:17 +0200
+
 cntlm (0.92.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- cntlm-0.92.3.orig/direct.c
+++ cntlm-0.92.3/direct.c
@@ -282,8 +282,19 @@
data[0]->url = strdup(data[0]->rel_url);
}
 
-   data[0]->headers = hlist_mod(data[0]->headers, 
"Connection", "keep-alive", 1);
-   data[0]->headers = hlist_del(data[0]->headers, 
"Proxy-Authorization");
+   /*
+* Force proxy keep-alive if the client can 
handle it (HTTP >= 1.1)
+*/
+   if (data[0]->http_version >= 11)
+   data[0]->headers = 
hlist_mod(data[0]->headers, "Connection", "keep-alive", 1);
+
+   /*
+* Also remove runaway P-A from the client 
(e.g. Basic from N-t-B), which might 
+* cause some ISAs to deny us, even if the 
connection is already auth'd.
+*/
+   while (hlist_get(data[loop]->headers, 
"Proxy-Authorization")) {
+   data[loop]->headers = 
hlist_del(data[loop]->headers, "Proxy-Authorization");
+   }
 
/*
 * Try to get auth from client if present
@@ -373,18 +384,25 @@
 */
if (loop == 1) {
conn_alive = !hlist_subcmp(data[1]->headers, 
"Connection", "close")
-   && http_has_body(data[0], data[1]) != 
-1;
+   && http_has_body(data[0], data[1]) != -1
+   && data[0]->http_version >= 11;
if (conn_alive) {
data[1]->headers = 
hlist_mod(data[1]->headers, "Proxy-Connection", "keep-alive", 1);
data[1]->headers = 
hlist_mod(data[1]->headers, "Connection", "keep-alive", 1);
} else {
data[1]->headers = 
hlist_mod(data[1]->headers, "Proxy-Connection", "close", 1);
+   data[1]->headers = 
hlist_mod(data[1]->headers, "Connection", "close", 1);
rc = (void *)-1;
}
}
 
-   if (debug)
+   if (debug) {
printf("Sending headers (%d)...\n", 
*wsocket[loop]);
+   if (loop == 0) {
+   printf("HEAD: %s %s %s\n", 
data[loop]->method, data[loop]->url, data[loop]->http);
+   hlist_dump(data[loop]->headers);
+   }
+   }
 
/*
 * Send headers
only in patch2:
unchanged:
--- cntlm-0.92.3.orig/forward.c
+++ cntlm-0.92.3/forward.c
@@ -446,7 +446,9 @@
&& strcasecmp(hostname, 
data[0]->hostname)) {
if (debug)
printf("\n*** F RETURN: %s 
***\n", data[0]->url);
-   if (authok)
+   if (authok && data[0]->http_version >= 11
+   && 
(hlist_subcmp(data[0]->headers, "Proxy-Connection", "keep-alive")
+   || 
hlist_subcmp(data[0]->headers, "Connection", "keep-alive")))
proxy_alive = 1;
 
rc = dup_rr_data(data[0]);
@@ -465,7 +467,7 @@
/*
 * Modify request headers.
 *
-* Try to request keep-alive for every connection. We 
keep them in a pool
+* Try to request keep-alive for every client 

Bug#1010396: ITP: tsn-scripts -- Tool set for Time Sensitive Networking testing

[Vladimir Oltean]

Package: wnpp
Severity: wishlist
Owner: Vladimir Oltean 

* Package name: tsn-scripts
  Version : 0.8
  Upstream Author : Vladimir Oltean 
* URL : https://github.com/vladimiroltean/tsn-scripts
* License : GPL
  Programming Lang: C
  Description : Tool set for Time Sensitive Networking testing

The tsn-scripts project contains the isochron program, a real-time
application for testing Time Sensitive Networking equipment. It works by
monitoring the network synchronization status and sending time-triggered
Ethernet packets. It has a server-client architecture and it measures
network latency by taking multiple timestamps (some hardware, some
software) along the path of the packets. It has been tested by me on
x86_64, armv7 and armv8 systems, but care has been taken for format
interoperability with big endian systems such as PowerPC.

The isochron program is mainly used in system testing, and there is a
desire to integrate it in the kselftest framework of the Linux kernel,
where it will constitute the basis for future TSN selftests of equipment
from various vendors.
There is no existing program known to me that serves this role.
During review of the kernel selftests it was pointed out that for users
it may be desirable for isochron to be distributed by Debian:
https://patchwork.kernel.org/project/netdevbpf/patch/20220428204839.1720129-1-vladimir.olt...@nxp.com/#24838122

This is my first Intent To Package. I am the upstream maintainer of the
project, would like to be the maintainer of the Debian package as well,
and would need a sponsor and mentor to help with review and walk me
through the packaging process. I am flexible in making changes to the
upstream project if this makes Debian packaging easier. In fact, in
expectation of changes to come, I've marked "v0.8" as the version of the
software to package, as opposed to the currently latest "v0.7".

Bug#1010394: RFS: analog/2:6.0.17-1 [QA] -- web server log analyzer

[Lourisvaldo Figueredo Junior]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: analog
   Version : 2:6.0.17-1
   Upstream Author : [fill in name and email of upstream]
 * URL : https://www.c-amie.co.uk/software/analog
 * License : public-domain, GD, libpng, GPL-2+, zlib, BSD-4-clause, 
PCRE
 * Vcs : https://salsa.debian.org/debian/analog
   Section : web

The source builds the following binary packages:

  analog - web server log analyzer

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/analog/
analog_6.0.17-1.dsc

Changes since the last upload:

 analog (2:6.0.17-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream release. (Closes: #698359) (LP: #905313) Consequently:
   - debian/analog.cfg: created.
   - debian/control: updated Homepage field. (Closes: #974671)
   - debian/install: modified to install debian/analog.cfg.
   - debian/patches:
   ~ 00_misc_fixes.diff renamed to 01_misc_fixes.patch and updated.
   ~ 01_bzip_reading.diff renamed to 02_bzip_reading.patch and updated.
   ~ 02_fix_realpath_calls.diff renamed to 03_fix_realpath_calls.patch
 and updated.
   ~ 02_windows_vista_7.patch removed. No longer needed.
   ~ 04_reproducible.patch updated.
   - debian/upstream/metadata: created.
   - debian/watch: updated.
   * debian/rules: using SOURCE_DATE_EPOCH variable, instead of parsing
 the output of dpkg-parsechangelog.

Regards,
-- 
  Lourisvaldo Figueredo Junior

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

Bug#1010395: ITP: neom -- desktop IM client for the Matrix protocol

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org, Matrix Packaging Team 


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: neom
  Version : 0.0~git20220427
  Upstream Author : Antti Keränen 
* URL : https://git.sr.ht/~detegr/neom
* License : BSD-3-clause
  Programming Lang: Rust
  Description : desktop IM client for the Matrix protocol

 Neom is A Matrix client
 that tries to be light but feature complete.
 .
 Matrix is an open, federated communications protocol.

The project is in arly development still.  It is only vaguely usable,
and until it matures it will be used to test packaging of Rust crates
also needed by Fractal (when that project uses stable crate releases).

This project will be maintained in the Matrix team, here:
https://salsa.debian.org/matrix-team/neom


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmJtLswACgkQLHwxRsGg
ASF+0A/9EqWo+qLftjIwtnwV4j2qBi/8k3b/0vww87S48V8kUy+v3FjT/VEQjCGv
O34O6g5yJgz8/vQWPwU6EOOJEZ/C90FPA8fKlxitrJsVqQcWVQDwGFEdBeMzP48D
2wiNKA/hs9juRB4HeN1xVeqcsTZzUsLRaMqm1oXrydgN2/dxnc0c+uxcwQ/+Xw+5
cRLHYfnVMx6wZZBBNQQekFe2IXeN07T9s9FG3a6DWZjviBHAv+1tRyQ2IEsH4x5I
KDVUao3pB/v1yBeXjVuKtSQDmsU8+TV/uONPQt9IedHg4/roqZT/CPtVRWfFf1Av
E7QYQecN52YYSNuSmg48xi+9J2zbKyS3XHGF/W5FNG32ojffE3bcLu2KQkyDTaPJ
4L00jyLcGPAQjpBZmw/r4RIr3y+vMVAZRWmQqolJyDSf9v7xcN6LK+UC9XvmEEgO
8onKgzX/Vn5rufw4hODzUuaIK+YC9pHTZ5GUD8VfOpIsOe/4j/EF2n/mxsJCgXlk
6msnSI5yem/AGbKuRtCYjBW7uPFtkD2k5C5pkXBEs3f7RRI3U40PRY4wu8y8nEVz
0SL7v0dzAAMLXtgypjBtFbWfoT5tcjiHe9PAD6AOhCrV8b3OcnF26EicXXFTdvpV
arnzEssOqSx9gZMshpZsOZRHFk2r3F+cU6sn8nY9JqObWm2jPdQ=
=mcqw
-END PGP SIGNATURE-

Bug#1010393: installation-reports: No swap partition which disables hibernate

[Andreas Tille]

Package: installation-reports
Severity: important

(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://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.2.0+nonfree/amd64/iso-dvd/firmware-11.2.0-amd64-DVD-1.iso
Date: 

Machine: frame.work
Partitions: 
$ sudo df -Tl
Filesystem  Type  1K-blocks   Used Available Use% Mounted on
udevdevtmpfs   32785108  0  32785108   0% /dev
tmpfs   tmpfs   6564204   1936   6562268   1% /run
/dev/mapper/Debian-root ext4 1919713600 1339815668 482308072  74% /
tmpfs   tmpfs  32821012  43540  32777472   1% /dev/shm
tmpfs   tmpfs  5120  4  5116   1% /run/lock
/dev/nvme0n1p2  ext2 481642 173328283329  38% /boot
/dev/nvme0n1p1  vfat 523248   3484519764   1% /boot/efi
tmpfs   tmpfs   6564200 72   6564128   1% 
/run/user/1454



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

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

Comments/Problems:

Detection of Wifi is known to fail since a later kernel than the one on
the installer is needed for this hardware.

The actual problem I'd like to report is that no swap partition was
created which is probably fine if the box is featuring 64GB.  However,
this prevents from using hibernation feature which I'm missing now and
thus I probably need to re-install.  (/var/log/installer/partman.gz is
attached.)

Kind regards
Andreas.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u2"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux (none) 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) 
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 11th Gen Core 
Processor Host Bridge/DRAM Registers [8086:9a14] (rev 01)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation UHD 
Graphics [8086:9a49] (rev 01)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: 00:04.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:9a03] (rev 01)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: 00:06.0 PCI bridge [0604]: Intel Corporation 11th Gen Core 
Processor PCIe Controller [8086:9a09] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP 
Thunderbolt PCI Express Root Port #0 [8086:9a23] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.1 PCI bridge [0604]: Intel Corporation Tiger Lake-LP 
Thunderbolt PCI Express Root Port #1 [8086:9a25] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.2 PCI bridge [0604]: Intel Corporation Tiger Lake-LP 
Thunderbolt PCI Express Root Port #2 [8086:9a27] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:07.3 PCI bridge [0604]: Intel Corporation Tiger Lake-LP 
Thunderbolt PCI Express Root Port #3 [8086:9a29] (rev 01)
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Device 
[8086:9a11] (rev 01)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: 00:0a.0 Signal processing controller [1180]: Intel Corporation 
Device [8086:9a0d] (rev 01)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: 00:0d.0 USB controller [0c03]: Intel Corporation Tiger Lake-LP 
Thunderbolt USB Controller [8086:9a13] (rev 01)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:0d.2 USB controller [0c03]: Intel Corporation Tiger Lake-LP 
Thunderbolt NHI #0 [8086:9a1b] (rev 01)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: 00:0d.3 USB controller [0c03]: Intel Corporation Tiger Lake-LP 
Thunderbolt NHI #1 [8086:9a1d] (rev 01)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: 00:12.0 Serial controller [0700]: Intel Corporation Tiger Lake-LP 
Integrated Sensor Hub [8086:a0fc] (rev 20)
lspci -knn: Subsystem: Device [f111:0001]
lspci -knn: Kernel driver 

Bug#1010355: Fwd: Bug#1010355: CVE-2022-0530: null pointer dereference on invalid UTF-8 input

[Santiago Vila]

Hello Stephen.

Can you take a look at this? The Debian version of procmail in unstable 
has a patch for this which I took from git, and I was planning to just 
apply it to bullseye and buster, but apparently it's not enough to fix 
the issue.


Thanks.

 Mensaje reenviado 
Asunto: Bug#1010355: CVE-2022-0530: null pointer dereference on invalid 
UTF-8 input

Resent-Date: Fri, 29 Apr 2022 11:39:02 +
Resent-From: Enrico Zini 
Resent-To: debian-bugs-dist@lists.debian.org
Resent-CC: t...@security.debian.org, Santiago Vila 
Fecha: Fri, 29 Apr 2022 13:27:33 +0200
De: Enrico Zini 
Responder a: Enrico Zini , 1010...@bugs.debian.org
Para: Debian Bug Tracking System 

Package: unzip
Version: 6.0-21+deb9u2
Severity: serious
Tags: security upstream patch
X-Debbugs-Cc: Debian Security Team 

Fixed: 6.0-26

Hello,

details are at https://security-tracker.debian.org/tracker/CVE-2022-0530

stretch and buster segfault:

  $ unzip testcase-0530   Archive:  testcase-0530
  warning [testcase-0530]:  16 extra bytes at beginning or within zipfile
(attempting to process anyway)
  error [testcase-0530]:  reported length of central directory is
-16 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
zipfile?).  Compensating...
  error:  zipfile probably corrupt (segmentation violation)

bullseye errors out without valgrind issues reported:

  $ unzip testcase-0530
  Archive:  testcase-0530
  warning [testcase-0530]:  16 extra bytes at beginning or within zipfile
(attempting to process anyway)
  error [testcase-0530]:  reported length of central directory is
-16 bytes too long (Atari STZip zipfile?  J.H.Holm ZIPSPLIT 1.1
zipfile?).  Compensating...
  mp/zip-unzip-0/7/source/workdir 
/��6a9f01ad36a4ac3b68815bf6f83b3ff_inpu㉴�瑥:  mismatching 
"local" filename 
(mp/zip-unzip-0/7/source/workdir/��6a9f01ad36a4ac3b6881PK^G^HQ�V�^Q),

   continuing with "central" filename version
 skipping: mp/zip-unzip-0/7/source/workdir 
/��6a9f01ad36a4ac3b68815bf6f83b3ff_inpu㉴�瑥  unable to get password


The main issue here seems to be at utf8_to_local_string, defined in
process.c:2606, which doesn't check the result of utf8_to_wide_string
for a NULL value.

I'm attaching a proposed patch that adds the missing error handling.


Enrico


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

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

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

Versions of packages unzip depends on:
ii  libbz2-1.0  1.0.8-4
ii  libc6   2.31-13+deb11u3

unzip recommends no packages.

Versions of packages unzip suggests:
ii  zip  3.0-12

-- no debconf informationdiff --git a/fileio.c b/fileio.c
index 6290824..77e4b5f 100644
--- a/fileio.c
+++ b/fileio.c
@@ -2361,6 +2361,9 @@ int do_string(__G__ length, option)   /* return PK-type 
error code */
   /* convert UTF-8 to local character set */
   fn = utf8_to_local_string(G.unipath_filename,
 G.unicode_escape_all);
+  if (fn == NULL)
+return PK_ERR;
+
   /* make sure filename is short enough */
   if (strlen(fn) >= FILNAMSIZ) {
 fn[FILNAMSIZ - 1] = '\0';
diff --git a/process.c b/process.c
index d2a846e..715bc0f 100644
--- a/process.c
+++ b/process.c
@@ -2605,6 +2605,8 @@ char *utf8_to_local_string(utf8_string, escape_all)
   int escape_all;
 {
   zwchar *wide = utf8_to_wide_string(utf8_string);
+  if (wide == NULL)
+return NULL;
   char *loc = wide_to_local_string(wide, escape_all);
   free(wide);
   return loc;

Bug#1010392: golang-github-smallstep-certificates: FTBFS on arm64

[Sebastian Ramacher]

Source: golang-github-smallstep-certificates
Version: 0.15.15-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

golang-github-smallstep-certificates FTBFS on arm64:

okgithub.com/smallstep/certificates/templates 0.064s
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 4 
github.com/smallstep/certificates/acme 
github.com/smallstep/certificates/acme/api 
github.com/smallstep/certificates/acme/db/nosql 
github.com/smallstep/certificates/api 
github.com/smallstep/certificates/authority 
github.com/smallstep/certificates/authority/provisioner 
github.com/smallstep/certificates/ca 
github.com/smallstep/certificates/ca/identity 
github.com/smallstep/certificates/cas 
github.com/smallstep/certificates/cas/apiv1 
github.com/smallstep/certificates/cas/softcas 
github.com/smallstep/certificates/cas/stepcas 
github.com/smallstep/certificates/cmd/step-awskms-init 
github.com/smallstep/certificates/cmd/step-ca 
github.com/smallstep/certificates/cmd/step-pkcs11-init 
github.com/smallstep/certificates/cmd/step-yubikey-init 
github.com/smallstep/certificates/commands github.com/smallstep/certificates/db 
github.com/smallstep/certificates/errs github.com/smallstep/certificates/kms 
github.com/smallstep/certificates/kms/apiv1 
github.com/smallstep/certificates/kms/awskms 
github.com/smallstep/certificates/kms/pkcs11 
github.com/smallstep/certificates/kms/softkms 
github.com/smallstep/certificates/kms/sshagentkms 
github.com/smallstep/certificates/kms/uri 
github.com/smallstep/certificates/kms/yubikey 
github.com/smallstep/certificates/logging 
github.com/smallstep/certificates/monitoring 
github.com/smallstep/certificates/pki github.com/smallstep/certificates/server 
github.com/smallstep/certificates/templates returned exit code 1
make: *** [debian/rules:12: binary-arch] Error 25

See
https://buildd.debian.org/status/fetch.php?pkg=golang-github-smallstep-certificates=arm64=0.15.15-2%2Bb1=1651186137=0

Cheers
-- 
Sebastian Ramacher

Bug#1010391: afew: missing dependency on python3-dnspython

[Sascha Silbe]

Package: afew
Version: 3.0.1-1
Severity: normal
X-Debbugs-Cc: sascha-debian-bugs-afew-2022-04...@silbe.org

Dear Maintainer,

after a fresh installation afew fails to start because it cannot find
the "dns" module:

=== Begin ===
Traceback (most recent call last):
  File "/usr/bin/afew", line 33, in 
sys.exit(load_entry_point('afew==3.0.1', 'console_scripts', 'afew')())
  File "/usr/lib/python3/dist-packages/afew/commands.py", line 136, in main
__import__(file_name[:-3], level=0)
  File "/home/sascha/.config/afew/HeaderFilter.py", line 19, in 
class HeaderFilter(Filter):
  File "/usr/lib/python3/dist-packages/afew/FilterRegistry.py", line 60, in 
register_filter
all_filters[klass.__name__] = klass
  File "/usr/lib/python3/dist-packages/afew/FilterRegistry.py", line 39, in 
__setitem__
self.filter[key] = value
  File "/usr/lib/python3/dist-packages/afew/FilterRegistry.py", line 26, in 
filter
self._filter[f.name] = f.load()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2450, 
in load
return self.resolve()
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 2456, 
in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/afew/filters/DKIMValidityFilter.py", 
line 13, in 
import dns.exception
ModuleNotFoundError: No module named 'dns'
=== End ===

The "dns" Python module is shipped by python3-dnspython. Please add a
dependency on it.

NB: my configuration does not make use of DKIMValidityFilter so it's a
hard dependency.

Sascha

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (500, 'stable-debug'), (100, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages afew depends on:
ii  python3  3.9.2-3
ii  python3-chardet  4.0.0-1
ii  python3-dkim 1.0.5-1
ii  python3-notmuch  0.31.4-2

afew recommends no packages.

afew suggests no packages.

-- no debconf information

Bug#1009191: cctbx: please re-enable building on riscv64

[Neil Williams]

On Sat, 30 Apr 2022 10:18:35 +0300
Andrius Merkys  wrote:

> Hello,
> 
> On 2022-04-08 17:57, Graham Inggs wrote:
> > Building on riscv64 was silently disabled in 2021.12+ds1-3.
> > 2021.12+ds1-2 built successfully in the past [1], and 2021.12+ds1-4
> > continues to build in Ubuntu.
> > 
> > Please re-enable building on riscv64 as we would like to promote
> > riscv64 to a release architecture.  
> 
> Neil, is there a particular reason riscv64 support was disabled in
> 2021.12+ds1-3? 

I didn't see it as particularly likely that any real-world usage of
cctbx was manageable on any current RISCV64 hardware. 

> cctbx seems to build fine on riscv64 now. Can it be
> re-enabled?

Probably, yes. I won't have time to do an upload soon though. 

If someone else has time to do it as a team upload, go ahead. 

-- 
Neil Williams
li...@codehelp.co.uk
https://linux.codehelp.co.uk


pgpIzzuE3hnVQ.pgp
Description: OpenPGP digital signature

Bug#1010357: extra info

[Gert van de Kraats]

No problem if I use:
LIBGL_ALWAYS_SOFTWARE=1  MESA_DEBUG=1 gnome-control-center

gnome-control-center also works if I use:
MESA_GLES_VERSION_OVERRIDE=1.0 MESA_DEBUG=1 gnome-control-center

(gnome-control-center:5552): GLib-WARNING **: 10:59:38.934: GError set 
over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL 
before it's set.

The overwriting error message was: Unable to create a GL context
Gsk-Message: 10:59:38.934: Failed to realize renderer of type 
'GskGLRenderer' for surface 'GdkWaylandToplevel': No EGL configuration 
available


gnome-control-center  works without error if I use:
GSK_RENDERER=cairo MESA_DEBUG=1 gnome-control-center

The program seems to work without problems, but I sometimes get errors:

(gnome-control-center:6102): GLib-GObject-CRITICAL **: 11:43:46.650: 
g_object_unref: assertion 'G_IS_OBJECT (object)' failed


(gnome-control-center:6102): GLib-GObject-CRITICAL **: 11:43:46.651: 
g_object_unref: assertion 'G_IS_OBJECT (object)' failed



Maybe you could reproduce the problem at a more powerful graphics card by:
MESA_GLES_VERSION_OVERRIDE=2.0 MESA_DEBUG=1 gnome-control-center

Bug#1010390: RFS: libonig/6.9.8-1 -- regular expressions library

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

   Package name: libonig
   Version : 6.9.8-1
   Upstream Author : [fill in name and email of upstream]
   URL : https://github.com/kkos/oniguruma
   License : BSD-2-clause
   Vcs : https://jff.email/cgit/libonig.git
   Section : libs

The source builds the following binary packages:

  libonig5 - regular expressions library
  libonig-dev - regular expressions library — development files

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/libo/libonig/libonig_6.9.8-1.dsc
or from

git https://jff.email/cgit/libonig.git/?h=release%2Fdebian%2F6.9.8-1



Changes since the last upload:

 libonig (6.9.8-1) unstable; urgency=medium
 .
   * New Upstream release.
 - Remove upstream applied patches:
   + 0100-source_typos.patch
   * debian/copyright:
 - Add year 2022 to myself.


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

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

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


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

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


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



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

Bug#1010389: src:ccache: fails to migrate to testing for too long: FTBFS on s390x and autopkgtest regression

[Paul Gevers]

Source: ccache
Version: 4.5.1-1
Severity: serious
Control: close -1 4.6-1
Tags: sid bookworm ftbfs
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1007732

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:ccache has been trying to migrate for 61 
days [2]. Hence, I am filing this bug. Your package fails to build from 
source on s390x while it built successfully there before. Also, your 
autopkgtest regressed, bug #1007732.


If a package is out of sync between unstable and testing for a longer 
period, this usually means that bugs in the package in testing cannot be 
fixed via unstable. Additionally, blocked packages can have impact on 
other packages, which makes preparing for the release more difficult. 
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that 
hamper the migration of their package in a timely manner.


This bug will trigger auto-removal when appropriate. As with all new 
bugs, there will be at least 30 days before the package is auto-removed.


I have immediately closed this bug with the version in unstable, so if 
that version or a later version migrates, this bug will no longer affect 
testing. I have also tagged this bug to only affect sid and bookworm, so 
it doesn't affect (old-)stable.


If you believe your package is unable to migrate to testing due to 
issues beyond your control, don't hesitate to contact the Release Team.


Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=ccache



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010365: linux: failure to boot on Raspberry Pi Compute Module 4 (black screen)

[Bjørn Mork]

Cyril Brulebois  writes:

> Cyril Brulebois  (2022-04-29):
>> > I'll try and pinpoint when it broke using the various intermediary
>> > versions:
>> > 
>> >  - 5.17~rc3-1~exp1
>> 
>> The first attempt was sufficient: it breaks as early as that version.
>
> Using the same base image as before, and only updating the kernel: I've
> tested upstream builds, starting from the .config found in the Debian
> 5.16.18-1 package, using oldconfig and accepting everything by default:
>
>  - v5.16 is confirmed a first good;
>  - v5.17-rc1 is confirmed a first bad;
>  - the culprit seems to be 3ceff4ea07410763d5d4cccd60349bf7691e7e61

But that's a merge commit. Not likely the real cuplrit, unless there's a
merge bug.

I looked briefly at what was merged there, and I believe this commit
stands out as suspicious:

bjorn@miraculix:/usr/local/src/git/linux$ git show f59f6aaead97
commit f59f6aaead975f0ec4d8ff2d59c4ffb8cf0127b2
Author: Arnd Bergmann 
Date:   Mon Nov 22 23:21:56 2021 +0100

mmc: bcm2835: stop setting chan_config->slave_id

The field is not interpreted by the DMA engine driver, as all the data
is passed from devicetree instead. Remove the assignment so the field
can eventually be deleted.

Reviewed-by: Nicolas Saenz Julienne 
Signed-off-by: Arnd Bergmann 
Acked-by: Ulf Hansson 
Acked-by: Mark Brown 
Link: https://lore.kernel.org/r/2021112203.4103644-5-a...@kernel.org
Signed-off-by: Vinod Koul 

diff --git a/drivers/mmc/host/bcm2835.c b/drivers/mmc/host/bcm2835.c
index 8c2361e66277..463b707d9e99 100644
--- a/drivers/mmc/host/bcm2835.c
+++ b/drivers/mmc/host/bcm2835.c
@@ -1293,14 +1293,12 @@ static int bcm2835_add_host(struct bcm2835_host *host)
 
host->dma_cfg_tx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
host->dma_cfg_tx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   host->dma_cfg_tx.slave_id = 13; /* DREQ channel */
host->dma_cfg_tx.direction = DMA_MEM_TO_DEV;
host->dma_cfg_tx.src_addr = 0;
host->dma_cfg_tx.dst_addr = host->phys_addr + SDDATA;
 
host->dma_cfg_rx.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
host->dma_cfg_rx.dst_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
-   host->dma_cfg_rx.slave_id = 13; /* DREQ channel */
host->dma_cfg_rx.direction = DMA_DEV_TO_MEM;
host->dma_cfg_rx.src_addr = host->phys_addr + SDDATA;
host->dma_cfg_rx.dst_addr = 0;


But I'm basing that only on it being related to the bcm28/27xx SoCs and
a bit unexpected in the sound merge...  I cannot explain why this mmc
host driver change should affect your display.  Could be completely
wrong.  But migt be worth testing?



Bjørn

Bug#1008112: fixed in golang-mvdan-sh 3.4.3+ds2-1

[Nilesh Patra]

On 30 April 2022 2:08:09 pm IST, Shengjing Zhu  wrote:
>On Sat, Apr 30, 2022 at 10:35 AM Nilesh Patra  wrote:
>>
>> Hi Shengjing,
>>
>> > * Team upload
>> > * Merge shfmt package (Closes: #1008112, #1008186, #1008463)
>>
>> Since you added shfmt binary package to golang-mvdan-sh, now both src: 
>> golang-mvdan-sh and src:shfmt are proving a shfmt binary, shouldn't 
>> src:shfmt be removed then?
>>
>It will be removed automatically. See "obsolete source packages" on
>https://wiki.debian.org/ftpmaster_Removals

I see; didn't know about this before. Thanks Shengjing!

>> Also, as you added a new binary package, shouldn't this have made it to new 
>> instead? I'm a bit confused admittedly.
>>
>
>No, it's not a "new" binary package.

Righto.

Thanks for explaining,
Nilesh

Bug#1010344: FTBFS: some test fails with "An export name cannot include a lone surrogate"

[Yadd]

Hi,

could you take a look at this issue ? It seems related to node-eslint-* 
updates.


Cheers,
Yadd

Bug#1008112: fixed in golang-mvdan-sh 3.4.3+ds2-1

[Shengjing Zhu]

On Sat, Apr 30, 2022 at 10:35 AM Nilesh Patra  wrote:
>
> Hi Shengjing,
>
> > * Team upload
> > * Merge shfmt package (Closes: #1008112, #1008186, #1008463)
>
> Since you added shfmt binary package to golang-mvdan-sh, now both src: 
> golang-mvdan-sh and src:shfmt are proving a shfmt binary, shouldn't src:shfmt 
> be removed then?
>

It will be removed automatically. See "obsolete source packages" on
https://wiki.debian.org/ftpmaster_Removals

> Also, as you added a new binary package, shouldn't this have made it to new 
> instead? I'm a bit confused admittedly.
>

No, it's not a "new" binary package.

-- 
Shengjing Zhu

Bug#1010388: buster-pu: package node-ejs/2.5.7-1+deb10u1

[Yadd]

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

[ Reason ]
node-ejs is vulnerable to server-side template injection
(CVE-2022-29078, #1010359) and probably to prototype pollution.

[ Impact ]
Medium security issue

[ Tests ]
New test added, confirms that issue is fixed (sadly locally only,
test isn't launched in buster).

Patch is the same than for Bullseye (except test) and test passed in it.

[ Risks ]
Low risk, code is trivial

[ 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 ]
 * Replace {} by `new Object`
 * check localsName value

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index 3a9ce9c..68d1536 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-ejs (2.5.7-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Sanitize options and new objects (Closes: #1010359, CVE-2022-29078)
+
+ -- Yadd   Sat, 30 Apr 2022 10:18:39 +0200
+
 node-ejs (2.5.7-1) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2022-29078.patch 
b/debian/patches/CVE-2022-29078.patch
new file mode 100644
index 000..ec85061
--- /dev/null
+++ b/debian/patches/CVE-2022-29078.patch
@@ -0,0 +1,174 @@
+Description: sanitize localsName option and fix prototype pollution
+ This patch fixes CVE-2022-29078 but I also apply prototype pollution fixes,
+ even if there are no CVE associated with it
+Author: Nicolas Dumazet 
+Origin: upstream, https://github.com/mde/ejs/commit/15ee6985
+Bug: https://eslam.io/posts/ejs-server-side-template-injection-rce/
+Bug-Debian: https://bugs.debian.org/1010359
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-04-30
+
+--- a/lib/ejs.js
 b/lib/ejs.js
+@@ -61,6 +61,7 @@
+ // so we make an exception for `renderFile`
+ var _OPTS_EXPRESS = _OPTS.concat('cache');
+ var _BOM = /^\uFEFF/;
++var _JS_IDENTIFIER = /^[a-zA-Z_$][0-9a-zA-Z_$]*$/;
+ 
+ /**
+  * EJS template function cache. This can be a LRU object from lru-cache NPM
+@@ -254,7 +255,7 @@
+  */
+ 
+ function includeFile(path, options) {
+-  var opts = utils.shallowCopy({}, options);
++  var opts = utils.shallowCopy(utils.createNullProtoObjWherePossible(), 
options);
+   opts.filename = getIncludePath(path, opts);
+   return handleCache(opts);
+ }
+@@ -270,7 +271,7 @@
+  */
+ 
+ function includeSource(path, options) {
+-  var opts = utils.shallowCopy({}, options);
++  var opts = utils.shallowCopy(utils.createNullProtoObjWherePossible(), 
options);
+   var includePath;
+   var template;
+   includePath = getIncludePath(path, opts);
+@@ -372,8 +373,8 @@
+  */
+ 
+ exports.render = function (template, d, o) {
+-  var data = d || {};
+-  var opts = o || {};
++  var data = d || utils.createNullProtoObjWherePossible();
++  var opts = o || utils.createNullProtoObjWherePossible();
+ 
+   // No options object -- if there are optiony names
+   // in the data, copy them to options
+@@ -431,7 +432,7 @@
+ opts.filename = filename;
+   }
+   else {
+-data = {};
++data = utils.createNullProtoObjWherePossible();
+   }
+ 
+   return tryHandleCache(opts, data, cb);
+@@ -447,8 +448,8 @@
+ };
+ 
+ function Template(text, opts) {
+-  opts = opts || {};
+-  var options = {};
++  opts = opts || utils.createNullProtoObjWherePossible();
++  var options = utils.createNullProtoObjWherePossible();
+   this.templateText = text;
+   this.mode = null;
+   this.truncate = false;
+@@ -466,6 +467,9 @@
+   options.cache = opts.cache || false;
+   options.rmWhitespace = opts.rmWhitespace;
+   options.root = opts.root;
++  if (opts.localsName && !_JS_IDENTIFIER.test(opts.localsName)) {
++throw new Error('localsName is not a valid JS identifier.');
++  }
+   options.localsName = opts.localsName || exports.localsName || 
_DEFAULT_LOCALS_NAME;
+   options.views = opts.views;
+ 
+@@ -571,13 +575,13 @@
+ // Adds a local `include` function which allows full recursive include
+ var returnedFn = function (data) {
+   var include = function (path, includeData) {
+-var d = utils.shallowCopy({}, data);
++var d = utils.shallowCopy(utils.createNullProtoObjWherePossible(), 
data);
+ if (includeData) {
+   d = utils.shallowCopy(d, includeData);
+ }
+ return includeFile(path, opts)(d);
+   };
+-  return fn.apply(opts.context, [data || {}, escapeFn, include, rethrow]);
++  return fn.apply(opts.context, [data || 
utils.createNullProtoObjWherePossible(), escapeFn, include, rethrow]);
+ };
+ returnedFn.dependencies = this.dependencies;
+ return returnedFn;
+--- a/lib/utils.js
 b/lib/utils.js
+@@ -114,8 +114,10 @@
+  */
+ exports.shallowCopy = function (to, from) {
+   from = from || {};
+-  for (var p in from) {
+-to[p] = from[p];
++  if ((to !== null) && (to !== undefined)) {

Bug#1010387: golang-github-google-wire: FTBFS on armhf

[Sebastian Ramacher]

Source: golang-github-google-wire
Version: 0.5.0-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

golang-github-google-wire FTBFS on armhf:

=== CONT  TestWire/FieldsOfStructDoNotProvidePtrToField
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory
runtime: out of memory: cannot allocate 4194304-byte block (2853175296 in use)
fatal error: out of memory

...

FAILgithub.com/google/wire/internal/wire40.790s
FAIL
dh_auto_test: error: cd _build && go test -vet=off -v -p 4 
github.com/google/wire github.com/google/wire/cmd/wire 
github.com/google/wire/internal/wire returned exit code 1
make[1]: *** [debian/rules:10: override_dh_auto_test] Error 25


See
https://buildd.debian.org/status/fetch.php?pkg=golang-github-google-wire=armhf=0.5.0-2=1649772401=0

Cheers
-- 
Sebastian Ramacher

Bug#1010386: golang-v2ray-core: FTBFS on armel and armhf

[Sebastian Ramacher]

Source: golang-v2ray-core
Version: 4.34.0-5
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

golang-v2ray-core FTBFS on armel and armhf:

ok  v2ray.com/core/transport/internet/websocket 5.116s
=== RUN   TestPipeReadWrite
--- PASS: TestPipeReadWrite (0.00s)
=== RUN   TestPipeInterrupt
--- PASS: TestPipeInterrupt (0.00s)
=== RUN   TestPipeClose
--- PASS: TestPipeClose (0.00s)
=== RUN   TestPipeLimitZero
--- PASS: TestPipeLimitZero (2.00s)
=== RUN   TestPipeWriteMultiThread
--- PASS: TestPipeWriteMultiThread (0.10s)
=== RUN   TestInterfaces
--- PASS: TestInterfaces (0.00s)
PASS
ok  v2ray.com/core/transport/pipe   2.130s
FAIL
dh_auto_test: error: cd obj-arm-linux-gnueabi && go test -vet=off -v -p 4 
-timeout 30m v2ray.com/core v2ray.com/core/app v2ray.com/core/app/commander 
v2ray.com/core/app/dispatcher v2ray.com/core/app/dns v2ray.com/core/app/log 
v2ray.com/core/app/log/command v2ray.com/core/app/policy 
v2ray.com/core/app/proxyman v2ray.com/core/app/proxyman/command 
v2ray.com/core/app/proxyman/inbound v2ray.com/core/app/proxyman/outbound 
v2ray.com/core/app/reverse v2ray.com/core/app/router 
v2ray.com/core/app/router/command v2ray.com/core/app/stats 
v2ray.com/core/app/stats/command v2ray.com/core/common 
v2ray.com/core/common/antireplay v2ray.com/core/common/bitmask 
v2ray.com/core/common/buf v2ray.com/core/common/bytespool 
v2ray.com/core/common/cmdarg v2ray.com/core/common/crypto 
v2ray.com/core/common/crypto/internal v2ray.com/core/common/dice 
v2ray.com/core/common/errors v2ray.com/core/common/errors/errorgen 
v2ray.com/core/common/log v2ray.com/core/common/mux v2ray.com/core/common/net 
v2ray.com/core/common/peer v2ray.com/core/common/platform 
v2ray.com/core/common/platform/ctlcmd v2ray.com/core/common/platform/filesystem 
v2ray.com/core/common/protocol v2ray.com/core/common/protocol/bittorrent 
v2ray.com/core/common/protocol/dns v2ray.com/core/common/protocol/http 
v2ray.com/core/common/protocol/tls v2ray.com/core/common/protocol/tls/cert 
v2ray.com/core/common/protocol/udp v2ray.com/core/common/retry 
v2ray.com/core/common/serial v2ray.com/core/common/session 
v2ray.com/core/common/signal v2ray.com/core/common/signal/done 
v2ray.com/core/common/signal/pubsub v2ray.com/core/common/signal/semaphore 
v2ray.com/core/common/strmatcher v2ray.com/core/common/task 
v2ray.com/core/common/uuid v2ray.com/core/features v2ray.com/core/features/dns 
v2ray.com/core/features/dns/localdns v2ray.com/core/features/inbound 
v2ray.com/core/features/outbound v2ray.com/core/features/policy 
v2ray.com/core/features/routing v2ray.com/core/features/routing/dns 
v2ray.com/core/features/routing/session v2ray.com/core/features/stats 
v2ray.com/core/infra/conf v2ray.com/core/infra/conf/command 
v2ray.com/core/infra/conf/json v2ray.com/core/infra/conf/serial 
v2ray.com/core/infra/control v2ray.com/core/infra/control/main 
v2ray.com/core/infra/vprotogen v2ray.com/core/main 
v2ray.com/core/main/confloader v2ray.com/core/main/confloader/external 
v2ray.com/core/main/distro/all v2ray.com/core/main/distro/debug 
v2ray.com/core/main/json v2ray.com/core/main/jsonem v2ray.com/core/proxy 
v2ray.com/core/proxy/blackhole v2ray.com/core/proxy/dns 
v2ray.com/core/proxy/dokodemo v2ray.com/core/proxy/freedom 
v2ray.com/core/proxy/http v2ray.com/core/proxy/mtproto 
v2ray.com/core/proxy/shadowsocks v2ray.com/core/proxy/socks 
v2ray.com/core/proxy/trojan v2ray.com/core/proxy/vless 
v2ray.com/core/proxy/vless/encoding v2ray.com/core/proxy/vless/inbound 
v2ray.com/core/proxy/vless/outbound v2ray.com/core/proxy/vmess 
v2ray.com/core/proxy/vmess/aead v2ray.com/core/proxy/vmess/encoding 
v2ray.com/core/proxy/vmess/inbound v2ray.com/core/proxy/vmess/outbound 
v2ray.com/core/testing/mocks v2ray.com/core/testing/scenarios 
v2ray.com/core/testing/servers/http v2ray.com/core/testing/servers/tcp 
v2ray.com/core/testing/servers/udp v2ray.com/core/transport 
v2ray.com/core/transport/internet 
v2ray.com/core/transport/internet/domainsocket 
v2ray.com/core/transport/internet/headers/http 
v2ray.com/core/transport/internet/headers/noop 
v2ray.com/core/transport/internet/headers/srtp 
v2ray.com/core/transport/internet/headers/tls 
v2ray.com/core/transport/internet/headers/utp 
v2ray.com/core/transport/internet/headers/wechat 
v2ray.com/core/transport/internet/headers/wireguard 
v2ray.com/core/transport/internet/http v2ray.com/core/transport/internet/kcp 
v2ray.com/core/transport/internet/quic v2ray.com/core/transport/internet/tcp 
v2ray.com/core/transport/internet/tls v2ray.com/core/transport/internet/udp 
v2ray.com/core/transport/internet/websocket v2ray.com/core/transport/pipe 
returned exit code 1
make[1]: *** [debian/rules:45: override_dh_auto_test] Error 25

See
https://buildd.debian.org/status/fetch.php?pkg=golang-v2ray-core=armel=4.34.0-5%2Bb1=1651192936=0

Cheers
-- 
Sebastian Ramacher

Bug#1010385: task-spooler: Please update to newer upstream

[John Goerzen]

Package: task-spooler
Version: 1.0.1+dfsg1-1
Severity: wishlist

https://github.com/justanhduc/task-spooler seems to be the new home, and it up 
to 1.3.x.

Thanks!


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

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

Versions of packages task-spooler depends on:
ii  libc6  2.31-13+deb11u3

task-spooler recommends no packages.

task-spooler suggests no packages.

-- no debconf information

Bug#1010384: RFS: dmagnetic/0.34-1 -- Interpreter to play textadventures from Magnetic Scrolls in glorious ANSI Art

[Thomas Dettbarn]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : dmagnetic
Version : 0.34-1
Upstream Author : Thomas Dettbarn 
* URL : https://www.dettus.net/dMagnetic/
* License : BSD-2-Clause
* Vcs : [fill in URL of packaging vcs]
Section : games

The source builds the following binary packages:

dmagnetic - Interpreter to play textadventures from Magnetic Scrolls in 
glorious ANSI Art


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.34-1.dsc


Changes since the last upload:

dmagnetic (0.34-1) unstable; urgency=medium
.
* Minor bugfixes
* Slightly updated documentation
* Popular feature "-nodoc" had an issue with saved games.

Regards,

Thomas

Bug#1010110: ncbi-blast+: terminate called after throwing an instance of 'ncbi::CIO_Exception'

[patrice . duroux]

That would be very nice!
Thanks,
Patrice

Bug#1009191: cctbx: please re-enable building on riscv64

[Andrius Merkys]

Hello,

On 2022-04-08 17:57, Graham Inggs wrote:
> Building on riscv64 was silently disabled in 2021.12+ds1-3.
> 2021.12+ds1-2 built successfully in the past [1], and 2021.12+ds1-4
> continues to build in Ubuntu.
> 
> Please re-enable building on riscv64 as we would like to promote
> riscv64 to a release architecture.

Neil, is there a particular reason riscv64 support was disabled in
2021.12+ds1-3? cctbx seems to build fine on riscv64 now. Can it be
re-enabled?

> [1] https://buildd.debian.org/status/logs.php?pkg=cctbx=riscv64

Best,
Andrius

Bug#1006149: linux-image-5.16.0-1-686: Fails to boot on T41 Thinkpads

[Petra R.-P.]

Am Sa.,  9. Apr. 2022, um 08:20 +0200 schrieb Petra R.-P. 
:
> Am Sa., 26. Mär. 2022, um 17:19 +0100 schrieb Petra Rübe-Pugliese 
> :
> > On Sat 12 Mar 2022 at 21:31:38 +0100  Petra R.-P.  
> > wrote:
> > > On Sat 05 Mar 2022 at 17:59:51 +0100  Petra R.-P. 
> > >  wrote:
> > > [...]
> > > 
> > > The error persists also in linux-image-5.16.0-4-686 (5.16.12-1) .
> > 
> >  ... and in linux-image-5.16.0-5-686 (5.16.14-1) ...
> 
>  ... and in linux-image-5.16.0-6-686 (5.16.18-1) ...

   ... and in linux-image-5.17.0-1-686 (5.17.3-1) ...

although the last messages visible on screen are now different;
in fact the last one is:
 clocksource: Switched to clocksource acpi_pm

   Petra

Bug#1010383: bullseye-pu: package node-ejs/2.5.7-3+deb11u1

[Yadd]

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

[ Reason ]
node-ejs is vulnerable to server-side template injection
(CVE-2022-29078, #1010359) and probably to prototype pollution.

[ Impact ]
Medium security issue

[ Tests ]
New test added, confirms that issue is fixed

[ Risks ]
Low risk, code is trivial

[ 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 ]
 * Replace {} by `new Object`
 * check localsName value

Cheers,
Yadd
diff --git a/debian/changelog b/debian/changelog
index a40e2ed..1409436 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+node-ejs (2.5.7-3+deb11u1) bullseye; urgency=medium
+
+  * Team upload
+  * Sanitize options and new objects (Closes: #1010359, CVE-2022-29078)
+
+ -- Yadd   Sat, 30 Apr 2022 06:59:25 +0200
+
 node-ejs (2.5.7-3) unstable; urgency=medium
 
   * Team upload
diff --git a/debian/patches/CVE-2022-29078.patch 
b/debian/patches/CVE-2022-29078.patch
new file mode 100644
index 000..cd413ae
--- /dev/null
+++ b/debian/patches/CVE-2022-29078.patch
@@ -0,0 +1,174 @@
+Description: sanitize localsName option and fix prototype pollution
+ This patch fixes CVE-2022-29078 but I also apply prototype pollution fixes,
+ even if there are no CVE associated with it
+Author: Nicolas Dumazet 
+Origin: upstream, https://github.com/mde/ejs/commit/15ee6985
+Bug: https://eslam.io/posts/ejs-server-side-template-injection-rce/
+Bug-Debian: https://bugs.debian.org/1010359
+Forwarded: not-needed
+Reviewed-By: Yadd 
+Last-Update: 2022-04-30
+
+--- a/lib/ejs.js
 b/lib/ejs.js
+@@ -61,6 +61,7 @@
+ // so we make an exception for `renderFile`
+ var _OPTS_EXPRESS = _OPTS.concat('cache');
+ var _BOM = /^\uFEFF/;
++var _JS_IDENTIFIER = /^[a-zA-Z_$][0-9a-zA-Z_$]*$/;
+ 
+ /**
+  * EJS template function cache. This can be a LRU object from lru-cache NPM
+@@ -254,7 +255,7 @@
+  */
+ 
+ function includeFile(path, options) {
+-  var opts = utils.shallowCopy({}, options);
++  var opts = utils.shallowCopy(utils.createNullProtoObjWherePossible(), 
options);
+   opts.filename = getIncludePath(path, opts);
+   return handleCache(opts);
+ }
+@@ -270,7 +271,7 @@
+  */
+ 
+ function includeSource(path, options) {
+-  var opts = utils.shallowCopy({}, options);
++  var opts = utils.shallowCopy(utils.createNullProtoObjWherePossible(), 
options);
+   var includePath;
+   var template;
+   includePath = getIncludePath(path, opts);
+@@ -372,8 +373,8 @@
+  */
+ 
+ exports.render = function (template, d, o) {
+-  var data = d || {};
+-  var opts = o || {};
++  var data = d || utils.createNullProtoObjWherePossible();
++  var opts = o || utils.createNullProtoObjWherePossible();
+ 
+   // No options object -- if there are optiony names
+   // in the data, copy them to options
+@@ -431,7 +432,7 @@
+ opts.filename = filename;
+   }
+   else {
+-data = {};
++data = utils.createNullProtoObjWherePossible();
+   }
+ 
+   return tryHandleCache(opts, data, cb);
+@@ -447,8 +448,8 @@
+ };
+ 
+ function Template(text, opts) {
+-  opts = opts || {};
+-  var options = {};
++  opts = opts || utils.createNullProtoObjWherePossible();
++  var options = utils.createNullProtoObjWherePossible();
+   this.templateText = text;
+   this.mode = null;
+   this.truncate = false;
+@@ -466,6 +467,9 @@
+   options.cache = opts.cache || false;
+   options.rmWhitespace = opts.rmWhitespace;
+   options.root = opts.root;
++  if (opts.localsName && !_JS_IDENTIFIER.test(opts.localsName)) {
++throw new Error('localsName is not a valid JS identifier.');
++  }
+   options.localsName = opts.localsName || exports.localsName || 
_DEFAULT_LOCALS_NAME;
+   options.views = opts.views;
+ 
+@@ -571,13 +575,13 @@
+ // Adds a local `include` function which allows full recursive include
+ var returnedFn = function (data) {
+   var include = function (path, includeData) {
+-var d = utils.shallowCopy({}, data);
++var d = utils.shallowCopy(utils.createNullProtoObjWherePossible(), 
data);
+ if (includeData) {
+   d = utils.shallowCopy(d, includeData);
+ }
+ return includeFile(path, opts)(d);
+   };
+-  return fn.apply(opts.context, [data || {}, escapeFn, include, rethrow]);
++  return fn.apply(opts.context, [data || 
utils.createNullProtoObjWherePossible(), escapeFn, include, rethrow]);
+ };
+ returnedFn.dependencies = this.dependencies;
+ return returnedFn;
+--- a/lib/utils.js
 b/lib/utils.js
+@@ -114,8 +114,10 @@
+  */
+ exports.shallowCopy = function (to, from) {
+   from = from || {};
+-  for (var p in from) {
+-to[p] = from[p];
++  if ((to !== null) && (to !== undefined)) {
++for (var p in from) {
++  to[p] = from[p];
++}
+   }
+   return to;
+ };
+@@ -133,12 +135,16 @@
+  * 

Bug#994976: xtermcontrol: please make the build reproducible

[Vagrant Cascadian]

On 2021-09-24, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0] we noticed that
> xtermcontrol could not be built reproducibly.
...
> --- a/debian/rules2021-09-24 09:20:53.800313098 +0100
> --- b/debian/rules2021-09-24 09:35:32.356026521 +0100
> @@ -5,9 +5,15 @@
>  
>  export DEB_BUILD_MAINT_OPTIONS=hardening=+all
>  
> +PACKAGE_YEAR = $(shell date --utc --date=@$(SOURCE_DATE_EPOCH) '+%Y')
> +PACKAGE_DATE = $(shell date --utc --date=@$(SOURCE_DATE_EPOCH) +'%B %d, %Y')

I think this should use %Y-%m-%d instead, as %B is a locale-dependent
month name.

> +
>  %:
>   dh $@
>  
> +override_dh_auto_build:
> + dh_auto_build -- PACKAGE_YEAR="$(PACKAGE_YEAR)" 
> PACKAGE_DATE="$(PACKAGE_DATE)"
> +
>  override_dh_auto_test:
>  ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
>   xvfb-run xterm -e '( dh_auto_test ; echo $$? ) | tee 
> debian/xterm_dh_auto_test.log'

This package appears to be part of the QA team, so could be uploaded by
anyone... I'd consider uploading the fix, unless you'd like to do the
honors?


live well,
  vagrant


signature.asc
Description: PGP signature