Bug#973865: RFS: dhcpdump/1.8-3 [ITA] -- Capture dhcp-packets and show for easier checking and debugging

[Peter Ji]

Hi, Baptiste:


At 2020-12-03 05:43:40, "Baptiste Beauplat"  wrote:
>

>Note: Read through the entire mail, I have a couple of useful links in
>the end.
>[1]: 
>>https://www.debian.org/doc/debian-policy/upgrading-checklist.html#version-4-5-1

>[2]: http://www.mavetju.org/unix/general.php

>[3]: https://www.debian.org/doc/manuals/developers-reference/

>[4]: https://www.debian.org/doc/manuals/maint-guide/

>[5]: https://salsa.debian.org/debian/dhcping

>[6]: https://salsa.debian.org

>[7]: https://salsa.debian.org/salsa-ci-team/pipeline >



Thank you very much for such a careful review. The information you mentioned

 was very helpful to new comer like me. Especially the list in the end.
Thanks!


I tried to repacking dhcpdump as suggested, such as detailed changelog

and modified other  d/* files in the latest upload.
Although it may still have errors, I will continue to work on.

I know Debian's Gitlab But not familiar.  I will try to apply for access when 
necessary.


Regards,
--
  Peter_Ji

Bug#975129: qwt: FTBFS: qwt_painter_command.h:85:22: error: field ‘clipPath’ has incomplete type ‘QPainterPath’

[Gudjon I. Gudjonsson]

Hi

On Sunday, 13 December 2020 18:06:22 CET you wrote:
> Please go ahead, I have been sponsoring QWT and even made the latest
> binNMU, and we can't risk this many packages being removed just now.
> Ping me if you need help!

Sorry, I won't have any time until at least from now. Please go ahead.

Regards
Gudjon

Bug#977126: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0

[Ryutaroh Matsumoto]

Control: retitle -1 linux-image-rpi does not boot by qemu-system-arm -machine 
raspi0 or raspi1ap

Booting a Debian armel kernel by grub-efi-arm:armel seems unnecessary
to everyone (?). So I changed the title.
If linux-image-rpi can boot on qemu-system-arm, then I can modify
autopkgtest-virt-qemu to use linux-image-rpi with no change.
Ryutaroh

Bug#972921: reopening 972921 (Was: shasta: binary-all FTBFS)

[Andreas Tille]

Control: tags -1 moreinfo

Hi Adrian,

On Tue, Dec 08, 2020 at 12:12:31PM +, Debian Bug Tracking System wrote:
> Please contact me if you need assistance.

I think I need assistance.  The Auto-Building page[1] shows green for
all, amd64 and arm64 and

   
https://buildd.debian.org/status/fetch.php?pkg=shasta&arch=all&ver=0.6.0-4&stamp=1607534158&raw=0

looks OK.

So I wonder why that bug was reopened (may be you mistyped the bug number?)

Kind regards

   Andreas.

[1] https://buildd.debian.org/status/package.php?p=shasta

-- 
http://fam-tille.de

Bug#977419: lintian: Use of uninitialized value in string eq at package-relations.pm

[Robert Luberda]

On Mon, 14 Dec 2020 22:10:44 -0800 Felix Lechner
 wrote:
> Hi,
> 
> 
> Alas, I *cannot* reproduce it with either of the two packages. I tried
> both 2.104.0 and our development version (on stable). 

I have the same issue for any of my packages, for example:
Warning in group dwww/1.13.5: Use of uninitialized value in string eq at
/usr/share/lintian/checks/fields/package-relations.pm line 129.

I think it is related to the recent perl upgrade. I use the latest
version of perl which is 5.32.0-6.

>Are you both on
> more cutting-edge releases? Specifically, what is your version of
> liblist-moreutils-perl, please? Thanks!

On my system it is 0.430-1

Regards,
robert

Bug#976570: libstatgen: FTBFS on arm64: E: Build killed with signal TERM after 150 minutes of inactivity

[Dylan Aïssi]

severity 976570 normal
thanks

Hi,

arm64 is not on the architecture list for libstatgen, so I decrease
the severity of the bug.

Best,
Dylan

Bug#977443: RFS: qwinff/0.2.1+git20201215-1 -- GUI for FFmpeg

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: qwinff
   Version : 0.2.1+git20201215-1
   Upstream Author : Timothy Lin 
 * URL : http://qwinff.github.io/
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/multimedia-team/qwinff
   Section : video

It builds those binary packages:

  qwinff - GUI for FFmpeg

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/q/qwinff/qwinff_0.2.1+git20201215-1.dsc

Changes since the last upload:

 qwinff (0.2.1+git20201215-1) unstable; urgency=medium
 .
   * New upstream version.
   * d/upstream/metadata: added.
   * d/control: added Rules-Requires-Root.
   * d/watch: drop template part.
   * d/copyright:
 - update copyright years.
 - added Upstream-Contact.
 - fix file matcher.
   * Bump debhelper version to 13, drop d/compat.
   * Bump standards version to 4.5.1.

Regards,
-- 
  Gürkan Myczko

Bug#977442: RFS: zytrax/0+git20201215-1 -- Easy to use, tracker-inspired music sequencer

[Gürkan Myczko]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: zytrax
   Version : 0+git20201215-1
   Upstream Author : Juan Linietsky
 * URL : https://github.com/reduz/zytrax
 * License : public-domain, MIT+extended, MIT, GPL-2+
 * Vcs : https://salsa.debian.org/multimedia-team/zytrax
   Section : sound

It builds those binary packages:

  zytrax - Easy to use, tracker-inspired music sequencer

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/z/zytrax/zytrax_0+git20201215-1.dsc

Changes since the last upload:

 zytrax (0+git20201215-1) unstable; urgency=medium
 .
   * New upstream version.
   * d/upstream/metadata: added.
   * d/control:
 - added Rules-Requires-Root.
 - added Vcs fields.
   * d/copyright:
 - update copyright years.
 - added Upstream-Contact.
   * d/clean: updated.
   * d/docs: dropped.
   * Bump debhelper version to 13.
   * Bump standards version to 4.5.1.

Regards,
-- 
  Gürkan Myczko

Bug#977441: linux: Pls. consider CONFIG_DRM_V3D

[Ryutaroh Matsumoto]

Source: linux
Version: 5.9.11-1
Severity: wishlist

Dear Maintainer,

>From 5.10, Linux vc4 driver starts supporting Raspberry Pi GPU as
https://www.phoronix.com/scan.php?page=news_item&px=RPi4-Display-Linux-5.10-Coming

>From Ubuntu kernel experience, CONFIG_DRM_V3D seems necessary to
fully use its hardware acceleration, as
https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1850876

Could you consider to enable CONFIG_DRM_V3D for arm64 and possibly
for armhf?

Best regards, Ryutaroh Matsumoto

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

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

Bug#977440: gmusicbrowser: New version not in testing

[asmegir]

Package: gmusicbrowser
Version: 1.1.15~ds0-1
Severity: wishlist

Dear Maintainer,

There is a newly released version of this package - 1.1.16 (released on 
18-11-2020)
 
It seems that stalled development had it removed from testing but it'd be nice
if it could be added again before the coming freeze.

Thanks!
Damon 

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

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

Versions of packages gmusicbrowser depends on:
ii  gir1.2-gstreamer-1.0   1.14.4-1
ii  libglib-object-introspection-perl  0.047-1
ii  libgtk2-perl   2:1.24992-1+b2
ii  libgtk2.0-02.24.32-3
ii  perl   5.28.1-6+deb10u1

Versions of packages gmusicbrowser recommends:
ii  libcairo-perl   1.106-3+b1
ii  libdigest-crc-perl  0.22.2-1+b1
pn  libgtk2-notify-perl 
pn  libgtk2-trayicon-perl   
ii  libhtml-parser-perl 3.72-3+b3
ii  libintl-perl1.26-2
ii  liblocale-gettext-perl  1.07-3+b4
ii  libnet-dbus-perl1.1.0-5+b1
ii  perl [libio-compress-perl]  5.28.1-6+deb10u1

Versions of packages gmusicbrowser suggests:
ii  alsa-utils 1.1.8-2
pn  libgnome2-wnck-perl
pn  libgtk2-appindicator-perl  
pn  libgtk2-mozembed-perl  
pn  mpg321 | flac123 | ogg123  
pn  mplayer | mpv  
ii  vorbis-tools   1.4.0-11

-- no debconf information

Bug#977439: incorrect Jie-alert at 23o'clock, need "big hour" for lunar, lunar to/from solar is diff.

[luckystar]

Package: lunar
Version: 2.2-8
Severity: normal


Hi,
The attachment is a substitute of 22_patch within lunar_2.2-8
for the following bugs:

*** bugs_testing_scripts-with_results.txt
Here is some simple bash-scripts for testing with results:

1. different datetime when query luan to/from solar:
diff <(lunar=./usr/bin/lunar; y=1908; m=2; d=3; i=''; for h in `seq 0 72`; do 
let dd=$d+$[h/24]; h=$[h%24]; $lunar -u -s $i $y $m $dd $h | sed -n '3{N;s/\n/ 
\| /p}'; done) <(lunar=./usr/bin/lunar; y=1908; m=1; d=2; i='-i'; for h in `seq 
0 72`; do let dd=$d+$[h/24]; h=$[h%24]; $lunar -u -s $i $y $m $dd $h | sed -n 
'3{N;s/\n/ \| /p}'; done) 

1c1
< 阳历：　1908年 2月 3日 0时　星期一 | 阴历：　1908年 1月 2日子时　生肖属猴
---
> 阳历：　1908年 2月 2日 0时　星期日 | 阴历：　1908年 1月 2日子时　生肖属猴
24,25c24,25
< 阳历：　1908年 2月 3日23时　星期一 | 阴历：　1908年 1月 3日子时　生肖属猴
< 阳历：　1908年 2月 4日 0时　星期二 | 阴历：　1908年 1月 3日子时　生肖属猴
---
> 阳历：　1908年 2月 3日23时　星期一 | 阴历：　1908年 1月 2日子时　生肖属猴
> 阳历：　1908年 2月 3日 0时　星期一 | 阴历：　1908年 1月 3日子时　生肖属猴
48,49c48,49
< 阳历：　1908年 2月 4日23时　星期二 | 阴历：　1908年 1月 4日子时　生肖属猴
< 阳历：　1908年 2月 5日 0时　星期三 | 阴历：　1908年 1月 4日子时　生肖属猴
---
> 阳历：　1908年 2月 4日23时　星期二 | 阴历：　1908年 1月 3日子时　生肖属猴
> 阳历：　1908年 2月 4日 0时　星期二 | 阴历：　1908年 1月 4日子时　生肖属猴
72,73c72,73
< 阳历：　1908年 2月 5日23时　星期三 | 阴历：　1908年 1月 5日子时　生肖属猴
< 阳历：　1908年 2月 6日 0时　星期四 | 阴历：　1908年 1月 5日子时　生肖属猴
---
> 阳历：　1908年 2月 5日23时　星期三 | 阴历：　1908年 1月 4日子时　生肖属猴
> 阳历：　1908年 2月 5日 0时　星期三 | 阴历：　1908年 1月 5日子时　生肖属猴

2. "jie_alarm" at 0 - 23 o'clock, correct one is at 23 - 22:
 (lunar=./usr/bin/lunar; y=1908; m=2; d=4; i=''; for h in 22 23 24 47; do let 
dd=$d+$[h/24]; h=$[h%24]; $lunar -u -s $i $y $m $dd $h; done) 

Lunar Version 2.2-8 (Debian) (May 16, 2020)

阳历：　1908年 2月 4日22时　星期二
阴历：　1908年 1月 3日亥时　生肖属猴
干支：　戊申年　甲寅月　己丑日　乙亥时　
用四柱神算推算之时辰八字：　丁未年　癸丑月　己丑日　乙亥时　
Lunar Version 2.2-8 (Debian) (May 16, 2020)

阳历：　1908年 2月 4日23时　星期二
阴历：　1908年 1月 4日子时　生肖属猴
干支：　戊申年　甲寅月　庚寅日　丙子时　
用四柱神算推算之时辰八字：　丁未年　癸丑月　庚寅日　丙子时　
Lunar Version 2.2-8 (Debian) (May 16, 2020)

阳历：　1908年 2月 5日 0时　星期三
阴历：　1908年 1月 4日子时　生肖属猴
干支：　戊申年　甲寅月　庚寅日　丙子时　
用四柱神算推算之时辰八字：　戊申年　甲寅月　庚寅日　丙子时　
* 是日为节, 月柱可能要修改
* 年柱亦可能要修改
* 请查有节气时间之万年历
Lunar Version 2.2-8 (Debian) (May 16, 2020)

阳历：　1908年 2月 5日23时　星期三
阴历：　1908年 1月 5日子时　生肖属猴
干支：　戊申年　甲寅月　辛卯日　戊子时　
用四柱神算推算之时辰八字：　戊申年　甲寅月　辛卯日　戊子时　
* 是日为节, 月柱可能要修改
* 年柱亦可能要修改
* 请查有节气时间之万年历

3. for en, lunar using "big hour", e.g: zi3...etc. since "big hour" never 
bigger then 12:

./usr/bin/lunar

Lunar Version 2.2-8 (Debian) (May 16, 2020)

Solar : 2020.12.13.16   Sunday
Lunar : 2020.10.29.16   ShengXiao: Mouse
GanZhi: Geng1-Zi3.Ding1-Hai4.Geng1-Yin2.Jia3-Shen1
(GanZhi Order)  7-1.4-12.7-3.1-9
(JiaZi Cycle)   37.24.27.21

BaZi (8-characters) according to 'Four Column Calculation':
Geng1-Zi3.Wu4-Zi3.Geng1-Yin2.Jia3-Shen1
(GanZhi Order)  7-1.5-1.7-3.1-9
(JiaZi Cycle)   37.25.27.21

4 datetime-go-back testing with results:
4.1 solar to lunar, correct:
 (lunar=./usr/bin/lunar; y=1908; m=2; d=3; i=''; for h in `seq 0 72`; do let 
dd=$d+$[h/24]; h=$[h%24]; $lunar -u -s $i $y $m $dd $h | sed -n '3{N;s/\n/ \| 
/p}'; done)
阳历：　1908年 2月 3日 0时　星期一 | 阴历：　1908年 1月 2日子时　生肖属猴
...
阳历：　1908年 2月 3日22时　星期一 | 阴历：　1908年 1月 2日亥时　生肖属猴
阳历：　1908年 2月 3日23时　星期一 | 阴历：　1908年 1月 3日子时　生肖属猴
阳历：　1908年 2月 4日 0时　星期二 | 阴历：　1908年 1月 3日子时　生肖属猴
阳历：　1908年 2月 4日 1时　星期二 | 阴历：　1908年 1月 3日丑时　生肖属猴
...
阳历：　1908年 2月 4日22时　星期二 | 阴历：　1908年 1月 3日亥时　生肖属猴
阳历：　1908年 2月 4日23时　星期二 | 阴历：　1908年 1月 4日子时　生肖属猴
阳历：　1908年 2月 5日 0时　星期三 | 阴历：　1908年 1月 4日子时　生肖属猴
阳历：　1908年 2月 5日 1时　星期三 | 阴历：　1908年 1月 4日丑时　生肖属猴
.
阳历：　1908年 2月 5日22时　星期三 | 阴历：　1908年 1月 4日亥时　生肖属猴
阳历：　1908年 2月 5日23时　星期三 | 阴历：　1908年 1月 5日子时　生肖属猴
阳历：　1908年 2月 6日 0时　星期四 | 阴历：　1908年 1月 5日子时　生肖属猴

4.2 lunar to solar, incorrect:
 (lunar=./usr/bin/lunar; y=1908; m=2; d=3; i='-i'; for h in `seq 0 72`; do let 
dd=$d+$[h/24]; h=$[h%24]; $lunar -u -s $i $y $m $dd $h | sed -n '3{N;s/\n/ \| 
/p}'; done)

阳历：　1908年 2月 2日 0时　星期日 | 阴历：　1908年 1月 2日子时　生肖属猴
.
阳历：　1908年 2月 3日22时　星期一 | 阴历：　1908年 1月 2日亥时　生肖属猴
阳历：　1908年 2月 3日23时　星期一 | 阴历：　1908年 1月 2日子时　生肖属猴
   ^
  the time | go back here
   V
阳历：　1908年 2月 3日 0时　星期一 | 阴历：　1908年 1月 3日子时　生肖属猴
.
阳历：　1908年 2月 4日23时　星期二 | 阴历：　1908年 1月 3日子时　生肖属猴
   ^
  the time | go back here
   V
阳历：　1908年 2月 4日 0时　星期二 | 阴历：　1908年 1月 4日子时　生肖属猴
.
阳历：　1908年 2月 5日23时　星期三 | 阴历：　1908年 1月 4日子时　生肖属猴
阳历：　1908年 2月 5日 0时　星期三 | 阴历：　1908年 1月 5日子时　生肖属猴


-- System Information:
Debian Release: 6.0.10
  APT prefers squeeze-lts
  APT policy: (500, 'squeeze-lts'), (500, 'oldoldstable-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.32-5-486
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--- old/lunar.c	2020-12-05 11:13:54.901959460 +0800
+++ new/lunar.c	2020-12-05 11:29:05.194918875 +0800
@@ -410,15 +410,23 @@
 offset = Solar2Day(&solar);
 solar.weekday = (offset + Sola

Bug#977438: linux: Pls. consider DRM_VC4_HDMI_CEC

[Ryutaroh Matsumoto]

Source: linux
Version: 5.9.11-1
Severity: wishlist

Dear Maintainer,

Could you consider to enable CONFIG_DRM_VC4_HDMI_CEC
for arm64 and possibly armhf?
It should enable cec-client command in Debian cec-util to
control some CEC-capable devices connected via HDMI.

Best regards, Ryutaroh Matsumoto


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: arm64 (aarch64)

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

Bug#977419: lintian: Use of uninitialized value in string eq at package-relations.pm

[Felix Lechner]

Hi,

On Mon, Dec 14, 2020 at 9:24 PM Louis-Philippe Véronneau
 wrote:
>
> I can reproduce this behavior with supysonic 0.6.2+ds-2:

Alas, I *cannot* reproduce it with either of the two packages. I tried
both 2.104.0 and our development version (on stable). Are you both on
more cutting-edge releases? Specifically, what is your version of
liblist-moreutils-perl, please? Thanks!

Kind regards
Felix Lechner

Bug#860557: gprename ported to GTK3

[Christoph Anton Mitterer]

Hey.

Seems gprename has been ported to GTK3... would be awesome if this
could find it's way back into Debian :-)

https://sourceforge.net/p/gprename/bugs/18/

Cheers,
Chris.

Bug#977412: xastir: reproducible builds: Binaries contain embedded paths from usrmerge systems

[tony mancill]

Hi Vagrant!

On Mon, Dec 14, 2020 at 01:22:33PM -0800, Vagrant Cascadian wrote:
> Source: xastir
> Severity: normal
> Tags: patch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: usrmerge
> X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> 
> Several binaries shipped with xastir include embedded paths to the "sed"
> and "mv" commands:

Thank you for the bug report and the patch!  I have applied it and
uploaded.

I hope all is well - cheers,
tony


signature.asc
Description: PGP signature

Bug#977437: ITP:dde-device-formatter -- Device formatter of DDE

[Tu Qinggang]

Package:wnpp
Severity: wishlist
Owner: Tu Qinggang 
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name    : dde-device-formatter
  Version : 0.0.1.5
  Upstream Author : Deepin Technology Co, Ltd.
* URL : https://github.com/linuxdeepin/dde-device-formatter
  License : GPL-3.0
  Programming Lang: C++
  Description : Device formatter for Deepin Desktop Environment

dde-device-formatter is a simple graphical interface for creating file 
system in a block device.


It is part of Deepin software and DDE (Deepin Desktop Environment).

I intend to maintaining this.

Bug#977419: lintian: Use of uninitialized value in string eq at package-relations.pm

[Louis-Philippe Véronneau]

I can reproduce this behavior with supysonic 0.6.2+ds-2:

Warning in group supysonic/0.6.2+ds-2: Use of uninitialized value in
string eq at /usr/share/lintian/checks/fields/package-relations.pm line 129.
E: supysonic: alternates-not-allowed Recommends
N:
E: alternates-not-allowed
N:
N:   Only the "Depends", "Recommends", "Suggests" and "Pre-Depends" fields
N:   may specify alternate dependencies using the "|" symbol.
N:
N:   Refer to Debian Policy Manual section 7.1 (Syntax of relationship
N:   fields) for details.
N:
N:   Severity: error
N:
N:   Check: fields/package-relations
N:
E: supysonic: alternates-not-allowed Suggests


-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_signature
Description: OpenPGP digital signature

Bug#977339: pandoc: `data-dir` or `XDG_DATA_HOME` don't appear to work for --defaults

[Kapil Paranjape]

Oops! Thanks!

As you pointed out, I misread the manual page.

Once the file was moved to $HOME/.local/share/pandoc/defaults/options.yaml
it was found and it worked!

Marking this bug as done.

Regards,

Kapil.
--

On Mon, 14 Dec 2020 at 22:37, John MacFarlane  wrote:

> The man page says:
>
> > The file will be searched for first in the working directory, and then in
> > the `defaults` subdirectory of the user data directory
>
> It looks as if you've put your options.yaml directly in the user
> data directory rather than in the defaults subdirectory of that
> directory: try `$HOME/.local/share/pandoc/defaults/options.yaml`.
>

Bug#976788: linux-image-5.9.0-4-amd64: nouveau DRM timeout causes machine to freeze

[Uros Knuples]

Package: src:linux
Version: 5.9.11-1
Followup-For: Bug #976788

Hello,

I have the same problem as described the previous reportes.

The lock-up appears when using kwin-x11 display manager with compositing 
enabled. It does not appear on previous kernel versions (<=5.8).

This is the relevant kernel log;

Dec 15 04:17:39 localhost kernel: [3.758379] fb0: switching to nouveaufb 
from VESA VGA
Dec 15 04:17:39 localhost kernel: [4.258725] nouveau :01:00.0: vgaarb: 
deactivate vga console
Dec 15 04:17:39 localhost kernel: [4.258879] nouveau :01:00.0: NVIDIA 
GT216 (0a5a00a2)
Dec 15 04:17:39 localhost kernel: [4.296522] nouveau :01:00.0: bios: 
version 70.16.26.00.05
Dec 15 04:17:39 localhost kernel: [4.296925] nouveau :01:00.0: bios: 
OOB 1 015f1901 015f1901
Dec 15 04:17:39 localhost kernel: [4.318543] nouveau :01:00.0: fb: 1024 
MiB DDR3
Dec 15 04:17:39 localhost kernel: [4.399251] nouveau :01:00.0: DRM: 
VRAM: 1024 MiB
Dec 15 04:17:39 localhost kernel: [4.399255] nouveau :01:00.0: DRM: 
GART: 1048576 MiB
Dec 15 04:17:39 localhost kernel: [4.399261] nouveau :01:00.0: DRM: 
TMDS table version 2.0
Dec 15 04:17:39 localhost kernel: [4.399264] nouveau :01:00.0: DRM: DCB 
version 4.0
Dec 15 04:17:39 localhost kernel: [4.399268] nouveau :01:00.0: DRM: DCB 
outp 00: 01000323 00010034
Dec 15 04:17:39 localhost kernel: [4.399273] nouveau :01:00.0: DRM: DCB 
outp 01: 02014300 
Dec 15 04:17:39 localhost kernel: [4.399276] nouveau :01:00.0: DRM: DCB 
outp 02: 02021362 00020010
Dec 15 04:17:39 localhost kernel: [4.399283] nouveau :01:00.0: DRM: DCB 
conn 00: 0340
Dec 15 04:17:39 localhost kernel: [4.399286] nouveau :01:00.0: DRM: DCB 
conn 01: 1061
Dec 15 04:17:39 localhost kernel: [4.399289] nouveau :01:00.0: DRM: DCB 
conn 02: 0147
Dec 15 04:17:39 localhost kernel: [4.399293] nouveau :01:00.0: DRM: DCB 
conn 03: 00202346
Dec 15 04:17:39 localhost kernel: [4.399296] nouveau :01:00.0: DRM: DCB 
conn 04: 0400
Dec 15 04:17:39 localhost kernel: [4.399299] nouveau :01:00.0: DRM: DCB 
conn 05: 0210
Dec 15 04:17:39 localhost kernel: [4.399302] nouveau :01:00.0: DRM: DCB 
conn 06: 0211
Dec 15 04:17:39 localhost kernel: [4.399305] nouveau :01:00.0: DRM: DCB 
conn 07: 0213
Dec 15 04:17:39 localhost kernel: [4.402944] nouveau :01:00.0: DRM: MM: 
using COPY for buffer copies
Dec 15 04:17:39 localhost kernel: [4.491176] nouveau :01:00.0: DRM: 
allocated 1366x768 fb: 0x7, bo (ptrval)
Dec 15 04:17:39 localhost kernel: [4.491273] fbcon: nouveaudrmfb (fb0) is 
primary device
Dec 15 04:17:39 localhost kernel: [5.828809] nouveau :01:00.0: [drm] 
fb0: nouveaudrmfb frame buffer device
Dec 15 04:17:39 localhost kernel: [5.846907] [drm] Initialized nouveau 
1.3.1 20120801 for :01:00.0 on minor 0
Dec 15 04:18:10 localhost kernel: [   62.947755] nouveau :01:00.0: bios: 
OOB 1 015f1901 015f1901
Dec 15 04:18:10 localhost kernel: [   62.947992] nouveau :01:00.0: bios: 
OOB 1 015f1901 015f1901
Dec 15 04:18:10 localhost kernel: [   62.948398] nouveau :01:00.0: bios: 
OOB 1 015f1901 015f1901
Dec 15 04:30:57 localhost kernel: [  829.485336] nouveau :01:00.0: disp: 
ERROR 5 [INVALID_STATE] 06 [] chid 1 mthd 0080 data 0001
Dec 15 04:30:57 localhost kernel: [  829.485343] nouveau :01:00.0: disp: 
Base 1:
Dec 15 04:30:57 localhost kernel: [  829.485355] nouveau :01:00.0: disp:
0084:   
Dec 15 04:30:57 localhost kernel: [  829.485362] nouveau :01:00.0: disp:
0088:   
Dec 15 04:30:57 localhost kernel: [  829.485369] nouveau :01:00.0: disp:
008c:   
Dec 15 04:30:57 localhost kernel: [  829.485375] nouveau :01:00.0: disp:
0090:   
Dec 15 04:30:57 localhost kernel: [  829.485381] nouveau :01:00.0: disp:
0094:   
Dec 15 04:30:57 localhost kernel: [  829.485388] nouveau :01:00.0: disp:
00a0: 0070 -> 0060
Dec 15 04:30:57 localhost kernel: [  829.485395] nouveau :01:00.0: disp:
00a4: f000  
Dec 15 04:30:57 localhost kernel: [  829.485402] nouveau :01:00.0: disp:
00c0: fb7a  
Dec 15 04:30:57 localhost kernel: [  829.485409] nouveau :01:00.0: disp:
00c4:   
Dec 15 04:30:57 localhost kernel: [  829.485415] nouveau :01:00.0: disp:
00c8:   
Dec 15 04:30:57 localhost kernel: [  829.485422] nouveau :01:00.0: disp:
00cc:   
Dec 15 04:30:57 localhost kernel: [  829.485429] nouveau :01:00.0: disp:
00e0: 4000  
Dec 15 04:30:57 localhost kernel: [  829.485435] nouveau :01:00.0: disp:
00e4:   
Dec 15 04:30:57 localhost kernel: [  829.485442] nouveau :01:00.0: disp:
00e8

Bug#977430: matrix-synapse: please make service file not call python3 directly

[Russell Coker]

Package: matrix-synapse
Version: 1.24.0-1~bpo10+1
Severity: normal

The matrix-synapse.service file calls python3 directly for ExecStartPre and
ExecStart.  That means that when running SE Linux the daemon will get the
same context as all other instances of python3 being run (IE not a special
context for this daemon) and also it means that if the sysadmin wants to
change the start command there is no good way to do it as "systemctl edit"
doesn't allow overriding those 2 lines.

It would give more flexibility for all sysadmins if scripts under /usr/sbin
or /etc/matrix-synapse were used for these as well as making it easier to
run with SE Linux.

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

Kernel: Linux 4.19.0-13-amd64 (SMP w/3 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages matrix-synapse depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  init-system-helpers1.56+nmu1
ii  libjs-jquery   3.3.1~dfsg-3
ii  libpython3-stdlib  3.7.3-1
ii  lsb-base   10.2019051400
ii  perl   5.28.1-6+deb10u1
ii  python33.7.3-1
ii  python3-attr   19.3.0-3~bpo10+1
ii  python3-bcrypt 3.1.6-1
ii  python3-bleach 3.1.2-0+deb10u1
ii  python3-canonicaljson  1.4.0-1~bpo10+1
ii  python3-distutils  3.7.3-1
ii  python3-frozendict 1.2-1
ii  python3-idna   2.6-1
ii  python3-jinja2 2.10-2
ii  python3-jsonschema 2.6.0-4
ii  python3-lxml   4.3.2-1+deb10u1
ii  python3-msgpack0.5.6-1+b1
ii  python3-nacl   1.3.0-2
ii  python3-netaddr0.7.19-1
ii  python3-openssl19.0.0-1
ii  python3-phonenumbers   8.9.10-1
ii  python3-pil5.4.1-2+deb10u2
ii  python3-prometheus-client  0.6.0-1
ii  python3-pyasn1 0.4.2-3
ii  python3-pyasn1-modules 0.2.1-0.2
ii  python3-pymacaroons0.13.0-2
ii  python3-service-identity   18.1.0-5~bpo10+1
ii  python3-signedjson 1.1.0-1~bpo10+1
ii  python3-sortedcontainers   2.0.4-1
ii  python3-systemd234-2+b1
ii  python3-treq   18.6.0-0.1
ii  python3-twisted18.9.0-8~bpo10+1
ii  python3-typing-extensions  3.7.4.1-1~bpo10+1
ii  python3-unpaddedbase64 1.1.0-4
ii  python3-yaml   3.13-2

Versions of packages matrix-synapse recommends:
pn  python3-psycopg2  

Versions of packages matrix-synapse suggests:
pn  python3-txacme  

-- Configuration Files:
/etc/matrix-synapse/homeserver.yaml changed [not included]

-- debconf information excluded

Bug#932088: gdebi doenst ask for a root password. just silently closes

[xiao sheng wen]

Package: gdebi
Version: 0.9.5.7+nmu3
Followup-For: Bug #932088

Dear Maintainer,

I meet the same bug.

I use Buster 10.7, I installed XFCE,MATE,GNOME desktop in my computer.

But this bug only occur in XFCE, MATE and GNOME is no problem.

BTW:
dbus-x11 is already installed in my compurter.

I also strace the pid of gdebi-gtk, the last error lines is following:

mprotect(0x7f6abcb42000, 4096, PROT_READ) = 0
mprotect(0x7f6abc71, 4096, PROT_READ) = 0
mprotect(0x7f6abc6ff000, 32768, PROT_READ) = 0
mprotect(0x7f6abc7b4000, 4096, PROT_READ) = 0
mprotect(0x7f6abc9ce000, 4096, PROT_READ) = 0
mprotect(0x7f6abc9af000, 4096, PROT_READ) = 0
mprotect(0x7f6abcb53000, 4096, PROT_READ) = 0
mprotect(0x55c84fb26000, 4096, PROT_READ) = 0
mprotect(0x7f6abcba2000, 4096, PROT_READ) = 0
munmap(0x7f6abcb57000, 147011)  = 0
set_tid_address(0x7f6abbcfa810) = 25973
set_robust_list(0x7f6abbcfa820, 24) = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7f6abc9896b0, sa_mask=[], 
sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f6abc995730}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7f6abc989740, sa_mask=[], 
sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f6abc995730}, NULL, 
8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, 
rlim_max=RLIM64_INFINITY}) = 0
brk(NULL)   = 0x55c851978000
brk(0x55c851999000) = 0x55c851999000
statfs("/sys/fs/selinux", 0x7ffd9c0c23b0) = -1 ENOENT (No such file or 
directory)
statfs("/selinux", 0x7ffd9c0c23b0)  = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tr"..., 1024) = 377
read(3, "", 1024)   = 0
close(3)= 0
access("/etc/selinux/config", F_OK) = -1 ENOENT (No such file or directory)
futex(0x7f6abcaedf58, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f6abcaedf58, FUTEX_WAKE_PRIVATE, 2147483647) = 0
geteuid()   = 1001
openat(AT_FDCWD, "lib/x86_64-linux-gnu/charset.alias", O_RDONLY) = -1 ENOENT 
(No such file or directory)
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", 
O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=26402, ...}) = 0
mmap(NULL, 26402, PROT_READ, MAP_SHARED, 3, 0) = 0x7f6abcb74000
close(3)= 0
futex(0x7f6abc97ca08, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "pkexec must be setuid root\n", 27) = 27
exit_group(127) = ?
+++ exited with 127 +++

Is this bug possible have relation to the selinux ?

I'd installed the package about selinux:

 dpkg -l|grep selinux
ii  libselinux1:amd642.8-1+b1   
  amd64SELinux runtime shared libraries
ii  libselinux1:i386 2.8-1+b1   
  i386 SELinux runtime shared libraries


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

Kernel: Linux 4.19.0-13-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=UTF-8), 
LANGUAGE=zh_CN:zh (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gdebi depends on:
ii  gdebi-core0.9.5.7+nmu3
ii  gir1.2-gtk-3.03.24.5-1
ii  gir1.2-vte-2.91   0.54.2-2
ii  gnome-icon-theme  3.12.0-3
ii  policykit-1   0.105-25
ii  python3   3.7.3-1
ii  python3-gi3.30.4-1

Versions of packages gdebi recommends:
ii  libgtk2-perl  2:1.24992-1+b2
ii  lintian   2.103.0~bpo10+1
ii  shared-mime-info  1.10-1

gdebi suggests no packages.

-- no debconf information

Bug#977328: false positive when passing variables to functions by address

[Russ Allbery]

Joachim Reichel  writes:
> On 14.12.20 01:23, Russ Allbery wrote:

>> In the second case, something about adding retval to the test messes up
>> its understanding of the data flow.

> Removing retval from the if() condition does not change anything for
> me. Could you double-check?

Ah, it's not the presence in the condition that does it, it's the
assignment of the function return value (?!).  The following produces no
warnings:

int
test_b(void)
{
char **string = NULL;

some_other_call(&string);
if (string && string[0])
return 0;
return -1;
}

but the following does:

int result;

int
test_b(void)
{
char **string = NULL;

result = some_other_call(&string);
if (string && string[0])
return 0;
return -1;
}

% cppcheck --enable=warning,style foo-2.c 
Checking foo-2.c ...
foo-2.c:6:12: warning: Either the condition 'if(string&&string[0])' is 
redundant or there is possible null pointer dereference: string. 
[nullPointerRedundantCheck]
char **string = NULL;
   ^
foo-2.c:9:8: note: Assuming that condition 'if(string&&string[0])' is not 
redundant
if (string && string[0])
   ^
foo-2.c:6:12: note: Null pointer dereference
char **string = NULL;
   ^

>> The third case seems similar to the previous set of bugs, although note
>> that it only happens with assignment.  If that line is instead replaced
>> with something like call_c(foo->flag), there is no error.

> I suppose you meant replacing "blah.flag = foo->flag;" by
> "call_c(foo->flag)"? This does not change anything for me.

Indeed, you're right.  I'm not sure what it was that I was trying that
made me think that.  Here's a more minimal test case:

void
test_c(void)
{
some_type *foo = NULL;

retval = call_a(&foo);
if (retval != 0)
goto done;
call_b(foo->flag);

done:
if (foo != NULL)
free_foo(foo);
}

% cppcheck --enable=warning,style foo-3.c 
Checking foo-3.c ...
foo-3.c:9:12: warning: Either the condition 'foo!=NULL' is redundant or there 
is possible null pointer dereference: foo. [nullPointerRedundantCheck]
call_b(foo->flag);
   ^
foo-3.c:12:13: note: Assuming that condition 'foo!=NULL' is not redundant
if (foo != NULL)
^
foo-3.c:9:12: note: Null pointer dereference
call_b(foo->flag);
   ^

> Is "call_b(&blah);" relevant in this test?

It was there just to prevent an unused variable warning for blah from
cluttering up the output, but the above test works better.

Thank you so much for looking into this and passing along the bug reports!
I love cppcheck and run it on all the C software I release.

-- 
Russ Allbery (r...@debian.org)  

Bug#977436: bowtie2: reproducible builds: Embeds hostname in build

[Vagrant Cascadian]

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

The hostname gets embedded in the debug symbols:

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

  ./usr/lib/debug/.dwz/x86_64-linux-gnu/bowtie2.debug
  509   ··[··2fcb]··BUILD_HOST·"ionos11-amd64"
  557   ··[··3430]··BUILD_HOST·"i-capture-the-hostname"


The attached patch fixes this by passing the HOSTNAME variable in
debian/rules.


Thanks for maintaining bowtie2!


live well,
  vagrant
From 4fc949ff654adb250b5a855ec4c77080f568b443 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Dec 2020 03:42:49 +
Subject: [PATCH 2/2] debian/rules: Pass HOSTNAME variable to dh_auto_build.

The hostname of the build system will get embecded in the binary
otherwise, breaking reproducible builds.
---
 debian/rules | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 464a80c..851f8c0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -24,7 +24,7 @@ export EXTRA_OPTIONS
 	dh $@
 
 override_dh_auto_build:
-	LD_PRELOAD= dh_auto_build -- EXTRA_FLAGS="-std=c++98 $(LDFLAGS)" $(EXTRA_OPTIONS)
+	LD_PRELOAD= dh_auto_build -- EXTRA_FLAGS="-std=c++98 $(LDFLAGS)" $(EXTRA_OPTIONS) HOSTNAME=reproducible-hostname
 
 override_dh_auto_test:
 ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977435: bowtie2: reproducible builds: Embeds timestamp in build

[Vagrant Cascadian]

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

The debugging symbols embed the build time:

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

  ./usr/lib/debug/.dwz/x86_64-linux-gnu/bowtie2.debug 
  501   ··[··2df6]··BUILD_TIME·"Thu·Dec·10·16:47:13·UTC·2020"
  504   ··[··2f02]··BUILD_TIME·"Thu·Jan·13·00:06:51·UTC·2022"

The attached patch fixes this by adjusting the Makefile to have date to
produce a consistent timestamp using SOURCE_DATE_EPOCH.


Thanks for maintaining bowtie2!


live well,
  vagrant
From abf1a60be6d2bf1b2d86cc66a001f1d233e3d2da Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Dec 2020 03:41:17 +
Subject: [PATCH 1/2] debian/patches: Patch Makefile to use SOURCE_DATE_EPOCH.

---
 debian/patches/series  |  1 +
 .../patches/use-source-date-epoch-in-Makefile  | 18 ++
 2 files changed, 19 insertions(+)
 create mode 100644 debian/patches/use-source-date-epoch-in-Makefile

diff --git a/debian/patches/series b/debian/patches/series
index e11a345..d85c587 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@ silence_tbb_deprecation_warning.patch
 simde
 correct_64bit_test
 no_sanity
+use-source-date-epoch-in-Makefile
diff --git a/debian/patches/use-source-date-epoch-in-Makefile b/debian/patches/use-source-date-epoch-in-Makefile
new file mode 100644
index 000..a37f05c
--- /dev/null
+++ b/debian/patches/use-source-date-epoch-in-Makefile
@@ -0,0 +1,18 @@
+From: Vagrant Cascadian 
+Subject: Patch Makefile to set date for BUILD_TIME using SOURCE_DATE_EPOCH.
+
+https://reproducible-builds.org/docs/source-date-epoch/
+
+Index: bowtie2/Makefile
+===
+--- bowtie2.orig/Makefile
 bowtie2/Makefile
+@@ -279,7 +279,7 @@ both-debug: bowtie2-align-s-debug bowtie
+ DEFS := -fno-strict-aliasing \
+   -DBOWTIE2_VERSION="\"`cat BOWTIE2_VERSION`\"" \
+   -DBUILD_HOST="\"$${HOSTNAME:-`hostname`}\"" \
+-  -DBUILD_TIME="\"`date -u`\"" \
++  -DBUILD_TIME="\"`LC_ALL=C date -u -d@$(SOURCE_DATE_EPOCH)`\"" \
+   -DCOMPILER_VERSION="\"`$(CXX) -v 2>&1 | tail -1`\"" \
+   $(FILE_FLAGS) \
+   $(PREF_DEF) \
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977345: libxxhash built without hw-accelerated XXH3, 50% performance loss

[Norbert Preining]

Hi Julian,

thanks for the suggestion, sounds interesting.

On Mon, 14 Dec 2020, Julian Andres Klode wrote:
> > At the bare minimum, on x86, export DIGEST=1 when building and install
> > xxh_x86dispatch.h header. I'd love to see the xxh_x86dispatch.h also

Do you have something like the following in mind?
--- a/debian/libxxhash-dev.install
+++ b/debian/libxxhash-dev.install
@@ -4,3 +4,4 @@ usr/include/xxhash.h
 usr/include/xxh3.h
 usr/lib/*/pkgconfig/libxxhash.pc
 doc/xxhash_spec.md usr/share/doc/libxxhash-dev
+xxh_x86dispatch.h /usr/include
diff --git a/debian/rules b/debian/rules
index 2053a97..b6159cd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,7 +2,12 @@

 #export DH_VERBOSE=1

-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
+
+ifeq ($(DEB_HOST_ARCH),$(filter $(DEB_HOST_ARCH),i386 amd64))
+   export DISPATCH=1
+endif
+
 %:
dh $@

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#595090: 如何快速精准找到CEO buyer等决策人邮箱？

[amenablambk89zxxsm]

我已邀请您填写以下表单：
如何快速精准找到CEO buyer等决策人邮箱？

要填写此表单，请访问：
https://docs.google.com/forms/d/e/1FAIpQLScb50_OYXqtjQQau2sNdRBeTi1dLBrLuoM9lb2tZ66f0KQ_Eg/viewform?vc=0&c=0&w=1&flr=0&usp=mail_form_link

我已邀请您填写表单：

Google表单：创建调查问卷并分析调查结果。

Bug#975580: packagekit: segfault at 8 ip 000055afca94a631 sp 00007fff94cece20 error 4 in packagekitd[55afca948000+24000]

[Bernhard Übelacker]

Control: forcemerge 974826 975580


Dear Maintainer,
I just noticed this issue on some devices here too,
and found it leads to the same upstream as #974826 does.
So I hope it is ok to merge them.

As far as I see this error message path triggers the segfault
because "error" is a null pointer.
The upstream links are already in #974826.

Kind regards,
Bernhard


(gdb) bt
#0  0x55f543929631 in pk_dbus_get_uid (dbus=0x55f54473c520, 
sender=sender@entry=0x7f16d4007030 ":1.42") at ../src/pk-dbus.c:81
#1  0x55f543942d5d in pk_engine_is_proxy_unchanged (pac=0x55f544738990 "", no_proxy=0x55f5447959a0 "", 
proxy_socks=0x55f5447912f0 "", proxy_ftp=0x0, proxy_https=0x55f544795820 "", proxy_http=0x0, 
sender=0x7f16d4007030 ":1.42", engine=0x55f5447121a0) at ../src/pk-engine.c:598
#2  pk_engine_set_proxy (context=0x55f54473a330, pac=, no_proxy=, proxy_socks=, proxy_ftp=0x0, proxy_https=, 
proxy_http=0x0, engine=0x55f5447121a0) at ../src/pk-engine.c:686
#3  pk_engine_daemon_method_call (connection_=, sender=sender@entry=0x7f16d4007030 ":1.42", 
object_path=object_path@entry=0x7f16d400af60 "/org/freedesktop/PackageKit", 
interface_name=interface_name@entry=0x7f16d400b780 "org.freedesktop.PackageKit", 
method_name=method_name@entry=0x7f16d4009490 "SetProxy", parameters=parameters@entry=0x7f16d4009760, 
invocation=0x55f54473a330, user_data=0x55f5447121a0) at ../src/pk-engine.c:1438
#4  0x7f16e2acef1e in call_in_idle_cb (user_data=) at 
../../../gio/gdbusconnection.c:4890
#5  0x7f16e2c4dadf in g_main_dispatch (context=0x55f54470fd30) at 
../../../glib/gmain.c:3325
#6  g_main_context_dispatch (context=0x55f54470fd30) at 
../../../glib/gmain.c:4043
#7  0x7f16e2c4de88 in g_main_context_iterate (context=0x55f54470fd30, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4119
#8  0x7f16e2c4e17b in g_main_loop_run (loop=loop@entry=0x55f54470fe20) at 
../../../glib/gmain.c:4317
#9  0x55f543928d21 in main (argc=, argv=) at 
../src/pk-main.c:242
(gdb)

(gdb) display/i $pc
1: x/i $pc
=> 0x55f543929631 :mov0x8(%rax),%r8

(gdb) print/x $rax
$1 = 0x0

(gdb) print error
$2 = (GError_autoptr) 0x0

Bug#977417: release-notes: mention the Calamares installer (live-system installer) ?

[Holger Wansing]

Package: release-notes 
X-Debbugs-CC: highvolt...@debian.org 

Hi,

I just now (!) realized, that Buster introduced the Calamares installer
on its live images. Since this was not mentioned in Buster's release-notes,
I wonder if many users are also not aware of this?

Maybe we should add something to Bullseye's release-notes then? 


Or is the Calamares installer still considered as alpha or experimentell
or similar? Adding Jonathan in CC as calamares package  maintainer
for his advise on this.

Regards
Holger 


-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#943981: Proposal: Switch to cgroupv2 by default

[Ryutaroh Matsumoto]

Hi Arnaud,

> Hi! Docker 20.10 is now in unstable.

Thank you very much for your work!!! Ryutaroh

Bug#976102: a2ps 32-bit segfaults on startup

[Bernhard Übelacker]

Hello Mack Stanley,
I am not involved in packaging a2ps, but I guess there are some more
information needed to even start investigating.

I tried several files in a VM to send to a2ps and I could
not observe a crash.

Therefore could you supply to this bug which command line is used
to trigger the crash?

If possible a link to or if small enough attaching the input you
give to a2ps?

A crash should at least have a trace in dmesg output,
could you add this?

And possibly you could install the package "systemd-cordump".
That way some more information should be written
to the journal - e.g. visible in 'journalctl -e'.

Kind regards,
Bernhard

Bug#977434: RFS: e2tools/0.1.0-1 -- utilities for manipulating files in an ext2/ext3 filesystem

[肖盛文]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : e2tools
Version : 0.1.0-1
Upstream Author : Hans Ulrich Niedermann 
* URL : https://e2tools.github.io
* License : GPL-2+
* Vcs : https://salsa.debian.org/debian/e2tools
Section : misc

It builds those binary packages:

e2tools - utilities for manipulating files in an ext2/ext3 filesystem

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

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

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

dget -x
https://mentors.debian.net/debian/pool/main/e/e2tools/e2tools_0.1.0-1.dsc

Changes since the last upload:

e2tools (0.1.0-1) unstable; urgency=medium
.
* change Vcs-Git to https://salsa.debian.org/debian/e2tools.git
* d/control:
- Bump Standards-Version: 4.5.1
- use debhelper-compat (= 13)
- new upstream Homepage: https://e2tools.github.io
- Build-Depends: + pkgconf
* New upstream, new version 0.1.0 (Closes: #977288 , Closes: #932181)
* delete old patches, new version don't use
* d/docs: add the new version doc *.md
* d/copyright:
- debian/* add email atzli...@sina.com
- update Upstream-Contact, Upstream-Source, etc.
- add email and date info from AUTHORS, NEWS.md, e2tool-e2ls.c, etc.
* d/rules: delete "export CC"
* d/watch: update to version 4,update the new upstream URL
* add upstream/metadata
* d/manpages: upstream had included the debian's man

Regards,

-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat)：atzlinux
《铜豌豆 Linux》 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB




OpenPGP_signature
Description: OpenPGP digital signature

Bug#977433: kyua: reproducible builds: Embeds path to umount in binaries

[Vagrant Cascadian]

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

The path to "umount" may vary as either /bin/umount or /usr/bin/umount
if the system is configured as a usrmerge system:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/diffoscope-results/kyua.html

  ./usr/bin/kyua
  1424  Failed·to·exec·/bin/umount
  1424  Failed·to·exec·/usr/bin/umount

The attached patch fixes this by passing UMOUNT to configure.

Thanks for maintaining kyua!

live well,
  vagrant
From 2cd5c6462c06c2fb6db0bd1424ec72b5e57e05d8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Dec 2020 01:28:55 +
Subject: [PATCH 2/2] debian/rules: Pass UMOUNT to configure.

The path to "umount" may vary as either /bin/umount or /usr/bin/umount
if the system is configured as a usrmerge system. Use /bin/umount for
the most compatible location.

https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/rules b/debian/rules
index df806c9..16cc7bc 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,6 +8,7 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 override_dh_auto_configure:
 	dh_auto_configure -- --disable-developer \
 		KYUA_PLATFORM=$(DEB_HOST_GNU_CPU) \
+		UMOUNT=/bin/umount \
 
 override_dh_auto_install:
 	dh_auto_install --destdir=debian/tmp
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#977432: kyua: reproducible builds: Embeds architecture of running kernel

[Vagrant Cascadian]

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

When building for armhf and running an arm64 kernel, the configure
script uses "uname -m" to determine the architecture for KYUA_PLATFORM,
but this introduces variations depending on the kernel used to perform
the build:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/diffoscope-results/kyua.html

  632 ··0x000837d0·61726d76·376c·556e7375·70706f72·armv7l..Unsuppor
  632 ··0x000837d0·61617263·68363400·556e7375·70706f72·aarch64.Unsuppo


While this is often worked around in chroots by running with a "linux32"
personality, using the running kernel is not the correct way to
determine the architecture.

The attached patch fixes this by passing KYUA_PLATFORM to configure from
debian/rules.


An alternate fix might be to determine the architecture from the
compiler or other userspace utility that is independent from the kernel,
which might be more appropriate to submit upstream.


Thanks for maintaining kyua!


live well,
  vagrant
From 7550204861005095126dd68b2c727702abced3a8 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Dec 2020 01:23:52 +
Subject: [PATCH 1/2] debian/rules: Pass KYUA_PLATFORM to configure.

Ensure that the architecture being built for is the userspace
architecture and not the kernel architecture.

https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index d89b793..df806c9 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,7 +6,8 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 	dh $@
 
 override_dh_auto_configure:
-	dh_auto_configure -- --disable-developer
+	dh_auto_configure -- --disable-developer \
+		KYUA_PLATFORM=$(DEB_HOST_GNU_CPU) \
 
 override_dh_auto_install:
 	dh_auto_install --destdir=debian/tmp
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#977413: kio: Python, Ruby, etc. scripts are not opened in Dolphin 20.12.0

[Alexander Kernozhitsky]

Package: kio
Version: 5.74.0-2
Severity: normal
Tags: patch
X-Debbugs-Cc: sh200...@mail.ru

After upgrading to Dolphin 20.12.0, I encountered the same bug as described in
https://bugs.kde.org/show_bug.cgi?id=425177. If I'm trying to open a Python
script in Dolphin, nothing happens.

The bug is fixed in Frameworks 5.75. The relevant commit is
https://invent.kde.org/frameworks/kio/-/commit/fdd7c47c85d5d6dbf21e05e7a0d6afcf383f1d24.
If the patch from this commit is applied, the bug doesn't reproduce.



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

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

Versions of packages kio depends on:
ii  kded5 5.74.0-2
ii  libacl1   2.2.53-8
ii  libc6 2.31-5
ii  libgcc-s1 10.2.0-19
ii  libgssapi-krb5-2  1.18.3-4
ii  libkf5archive55.74.0-2
ii  libkf5authcore5   5.74.0-2
ii  libkf5codecs5 5.74.0-2
ii  libkf5completion5 5.74.0-2
ii  libkf5configcore5 5.74.0-2
ii  libkf5configwidgets5  5.74.0-2
ii  libkf5coreaddons5 5.74.0-2
ii  libkf5dbusaddons5 5.74.0-2
ii  libkf5doctools5   5.74.0-2
ii  libkf5i18n5   5.74.0-3
ii  libkf5itemviews5  5.74.0-2
ii  libkf5kiocore55.74.0-2.0.1
ii  libkf5kiontlm55.74.0-2.0.1
ii  libkf5kiowidgets5 5.74.0-2.0.1
ii  libkf5notifications5  5.74.0-2
ii  libkf5service-bin 5.74.0-2
ii  libkf5service55.74.0-2
ii  libkf5solid5  5.74.0-2
ii  libkf5textwidgets55.74.0-2
ii  libkf5wallet-bin  5.74.0-2
ii  libkf5wallet5 5.74.0-2
ii  libkf5widgetsaddons5  5.74.0-3
ii  libkf5windowsystem5   5.74.0-2
ii  libqt5core5a  5.15.1+dfsg-4
ii  libqt5dbus5   5.15.1+dfsg-4
ii  libqt5gui55.15.1+dfsg-4
ii  libqt5network55.15.1+dfsg-4
ii  libqt5qml55.15.1+dfsg-3
ii  libqt5widgets55.15.1+dfsg-4
ii  libqt5x11extras5  5.15.1-2
ii  libqt5xml55.15.1+dfsg-4
ii  libstdc++610.2.0-19
ii  libxml2   2.9.10+dfsg-6.3+b1
ii  libxslt1.11.1.34-4

kio recommends no packages.

kio suggests no packages.

-- no debconf information

Bug#943981: Proposal: Switch to cgroupv2 by default

[El boulangero]

Hi! Docker 20.10 is now in unstable.

Best,

  Arnaud

On Sat, Dec 12, 2020 at 4:18 AM Michael Biebl  wrote:

> On Fri, 27 Nov 2020 15:50:03 +0700 El boulangero 
> wrote:
> > Hello all, here comes news from the docker package.
>
> Awesome news.
> I see you have uploaded docker  20.10.0+dfsg1-1 to experimental.
>
> Once systemd 247.1-4 has migrated to testing (i.e. in a couple of
> days), I intend to flip the switch to cgroupv2
> It would probably be good, if this was accompanied with a corresponding
> upload of docker.io 20.x to unstable.
>
> Regards,
> Michael
>

Bug#977431: tortoize: reproducible builds: Embeds timestamp in build

[Vagrant Cascadian]

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

/usr/bin/tortoize includes the build date:

   
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/armhf/diffoscope-results/tortoize.html

   709  Date:·2020-12-13709 Date:·2020-12-14

The attached patch fixes this by passing arguments to the date command
to use SOURCE_DATE_EPOCH instead of the current time.

  https://reproducible-builds.org/docs/source-date-epoch/


Thanks for maintaining tortoize!


live well,
  vagrant
From b3ffb62c6a56947733402f9c3e66af04ce748a42 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Dec 2020 01:25:59 +
Subject: [PATCH] revision.hpp: Use SOURCE_DATE_EPOCH for date string.

Also ensure locale and timezone are consistent.

https://reproducible-builds.org/docs/source-date-epoch/

This patch depends on features of GNU date and will need adjustment to
make more portable.
---
 GNUmakefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/GNUmakefile.in b/GNUmakefile.in
index 56b64c8..030541e 100644
--- a/GNUmakefile.in
+++ b/GNUmakefile.in
@@ -128,7 +128,7 @@ else
 src/revision.hpp:
 	@ echo 'const char kRevision[] = R"(' > $@
 	@ echo tortoize-version: $(VERSION) >> $@
-	@ echo Date:   $$(date --iso-8601) >> $@
+	@ echo Date:   $$(LC_ALL=C date --utc --date=@$(SOURCE_DATE_EPOCH) --iso-8601) >> $@
 	@ echo ')";' >> $@
 
 endif
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977397: uim-el: missing *-uim in input-method-alist on Emacs 27

[dai]

Control: tag -1 patch fixed-upstream

On Tue, Dec 15, 2020 at 02:31:46AM +0900, Nobuhiro Ban wrote:
> I used the japanese-anthy-utf8-uim input-method on my Debian Emacs 26 env.
> But after upgrading Emacs 27,
> I cannot set input-method to japanese-anthy-utf8-uim.
> 
> (Same cause as #977257)
> 
> There is a problem at initializing uim-el.
> So none of the input methods *-uim are prepared on startup.
> 
> From *Message* buffer:
> >Error while loading 50uim-el: Symbol’s function definition is void: 
> >process-kill-without-query
> 
> 
> How to fix:
> 
> Replace process-kill-without-query with set-process-query-on-exit-flag
> in /usr/share/emacs/site-lisp/uim-el/*.el .

Reproduced.  This is already fixed in upstream, so I will backport it:

https://github.com/uim/uim/commit/164e2eb050b5fec25033124834cf49ea1a7d8cbb
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#977257: uim-el: "Active processes exist" prompt upon exiting emacs

[dai]

Control: tags -1 confirmed
Control: block -1 by 977397

On Sun, Dec 13, 2020 at 06:12:47PM +0900, Nobuhiro Ban wrote:
> How to reproduce:
>  1. Run "emacs -q" .
>  2. Hit C-x C-c
>  3. Then, you show the confirmation message like:
> >Process [v] PID Status  BufferTTY  
> >Thread  $
> >uim-el-helpe... 100414  run  *uim-helper* /dev/pts/5   Main  
> >  $
> >
> >-UUU:%%--F1  *Process List*   All L1 (Process Menu) 
> >
> >Active processes exist; kill them and exit anyway? (yes or no)

Reproduced.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#976738: libintl.jar is not installed in /usr/share/maven-repo

[Louis-Philippe Véronneau]

tag -1 patch
block 976751 by -1
block 830904 by 976751
thanks

Dear maintainer,

Since this bug is keeping me from fixing puppetlabs-i18n-clojure (which
in turns, keeps me from packaging puppetserver in Debian), I've prepared
a patch to fix it.

I've successfully built the package with it and I believe it would be
trivial to apply it and should not have any negative effect. I've also
made sure the patch does indeed fix this bug.

I had originally linked the additional jars via gettext-base.links, but
that introduced a version in that file that you would've had to update
for each new upstream version.

Instead, I resorted to copying libintl.jar twice; as it's a very small
file (4KB), I don't think this will be a significant burden.

It shouldn't be necessary, but since the freeze is very close, if you
don't have time to deal with this, I'd also be happy to make an NMU.

Thanks for maintaining gettext in Debian!

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄
diff --git a/debian/gettext-base.install b/debian/gettext-base.install
deleted file mode 100644
index e69de29..000
diff --git a/debian/libintl-0.19.8.1.pom b/debian/libintl-0.19.8.1.pom
deleted file mode 100644
index e69de29..000
diff --git a/debian/libintl-debian.pom b/debian/libintl-debian.pom
new file mode 100644
index 000..6e60bdd
--- /dev/null
+++ b/debian/libintl-debian.pom
@@ -0,0 +1,14 @@
+
+http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4_0_0.xsd";>
+
+  4.0.0
+  org.gnu.gettext
+  libintl
+  debian
+  jar
+  
+
+0.19.8.1
+gettext-base
+  
+
diff --git a/debian/libintl.pom b/debian/libintl.pom
new file mode 100644
index 000..df5a516
--- /dev/null
+++ b/debian/libintl.pom
@@ -0,0 +1,14 @@
+
+http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4_0_0.xsd";>
+
+  4.0.0
+  org.gnu.gettext
+  libintl
+  0.19.8.1
+  jar
+  
+
+0.19.8.1
+gettext-base
+  
+
diff --git a/debian/rules b/debian/rules
index e322583..e9c12e3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,6 +9,7 @@ DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
 DEB_HOST_MULTIARCH := $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+DEB_UPSTREAM_VERSION = $(shell dpkg-parsechangelog | sed -ne 's/^Version: \(.*\)-.*/\1/p')
 
 CC = $(DEB_HOST_GNU_TYPE)-gcc
 CFLAGS := `dpkg-buildflags --get CFLAGS` -Wall
@@ -122,6 +123,17 @@ ifeq ($(filter nojava,$(DEB_BUILD_PROFILES)),)
 	install -d debian/$@/usr/share/java
 	cp -p debian/tmp/usr/share/gettext/libintl.jar \
 		debian/$@/usr/share/java
+	install -d debian/$@/usr/share/maven-repo/org/gnu/gettext/libintl/$(DEB_UPSTREAM_VERSION)
+	cp -p debian/tmp/usr/share/gettext/libintl.jar \
+		debian/$@/usr/share/maven-repo/org/gnu/gettext/libintl/$(DEB_UPSTREAM_VERSION)/libintl-$(DEB_UPSTREAM_VERSION).jar
+	cp -p debian/libintl.pom \
+		debian/$@/usr/share/maven-repo/org/gnu/gettext/libintl/$(DEB_UPSTREAM_VERSION)
+	install -d debian/$@/usr/share/maven-repo/org/gnu/gettext/libintl/debian
+	cp -p debian/tmp/usr/share/gettext/libintl.jar \
+		debian/$@/usr/share/maven-repo/org/gnu/gettext/libintl/debian/libintl-debian.jar
+	cp -p debian/libintl-debian.pom \
+		debian/$@/usr/share/maven-repo/org/gnu/gettext/libintl/debian
+
 endif
 endif
 


OpenPGP_signature
Description: OpenPGP digital signature

Bug#976548: This package only builds Arch:all binary packages

[Markus Koschany]

Control: severity -1 normal

The package is arch:all and builds fine on amd64 but FTBFS on other supported
architectures. Apparently one or two arch-dependent tests fail which is the
root cause of this failure. I'm downgrading the severity to normal as discussed
on the debian-java list. This is still a bug which should be fixed but it is
not release critical.

Markus


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

Bug#977429: vim-runtime: vim:spec.vim occurs Error let keyword is missing...

[YABUKI Yukiharu]

Package: vim-runtime
Version: 2:8.2.1913-1
Severity: normal

Dear Maintainer,

I ran accross a bug when I use spec.vim.

I set g:spec_chglog_format in ~/.vimrc and
```
au BufNewFile,BufRead *.changelog setf spec
```

Then push '\c', spec.vim gives me Error. I investigate this.
I found let keyword is missing. And I checked upstream repository.
Upstream's spec.vim seemed to me that this issue has already fixed.

I am confusing that vim-runtime is not follow upstream (I checked
vim/vim.git in github)


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

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

vim-runtime depends on no packages.

Versions of packages vim-runtime recommends:
ii  vim 2:8.2.1913-1+b2
ii  vim-gtk3 [vim]  2:8.2.1913-1+b2
ii  vim-nox [vim]   2:8.2.1913-1+b2

vim-runtime suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/vim/vim82/ftplugin/spec.vim (from vim-runtime 
package)

Bug#977428: lprng: reproducible builds: Binaries contain embedded paths from usrmerge systems

[Vagrant Cascadian]

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

Several binaries shipped with lprng include embedded paths to the "chown"
and "chgrp" commands:

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

  427   /bin/chown
  427   /usr/bin/chown


The attached patch fixes this by passing the CHOWN and CHGRP variables
to configure.


Thanks for maintaining lprng!


live well,
  vagrant
From 53f042a2da5cb8a554255e0171f3f39598dbf423 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 15 Dec 2020 00:29:41 +
Subject: [PATCH] debian/rules: Pass CHOWN and CHGRP to configure.

The path to "chown" and "chgrp" may vary as either /bin/CMD or
/usr/bin/CMD if the system is configured as a usrmerge system. Use
/bin/CMD for the most compatible location.

https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index 4470ae1..4af91b3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,7 +22,9 @@ override_dh_auto_configure:
 		--enable-kerberos_checks --enable-kerberos \
 		--with-groupid=lp \
 		--disable-remote \
-		--enable-lpd.conf.local
+		--enable-lpd.conf.local \
+		CHOWN=/bin/chown \
+		CHGRP=/bin/chgrp \
 
 override_dh_auto_install: $(autogen-files)
 	# Add here commands to install the package into debian/lprng.
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#968484: wireshark hard-wired to libsystemd0?

[Vincent Lefevre]

On 2020-12-14 23:33:19 +0100, Thorsten Glaser wrote:
> On Mon, 14 Dec 2020, Cristian Ionescu-Idbohrn wrote:
> 
> > > It doesn't depend on the init, but it links against the library to
> > > parse the journal files,
> >
> > I have no journal files on my system (yet).  So, that dependency is
> > total nonsense to me.
> 
> Not on your system but in the packet stream it analyses.
> AIUI when capturing data traffic, wireshark can inspect
> the traffic if it is structured data, and for this it
> needs interpreters for the various formats, and I think
> it just reuses the libsystemd0 one for network logging.

Not arbitrary network logging, though, but for systemd journals sent
across the network. This apparently comes from the following file in
the wireshark source

  epan/dissectors/packet-systemd-journal.c

which says

 * Dissector for systemd's mostly-text-based Journal Export Format described
 * at https://www.freedesktop.org/wiki/Software/systemd/export/.

And at this URL: "Note that this document describes the binary
serialization format of journals only, as used for transfer
across the network."

This is probably useless for data transferred with the local
non-systemd machine, but I suppose that this may be useful
even on such a machine if packets between other machines on
the local network can be captured (though this usage is not
intended by the systemd developers, otherwise there would be
a separate library for this purpose).

So, if I understand correctly, this support should be optional,
but not necessarily completely useless on non-systemd machines.

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

Bug#977423: maintainer address bounces

[Ansgar]

Hi,

On Tue, 15 Dec 2020 00:36:23 +0100 Michael Biebl wrote:
> I just tried to file a bug report against apt-listchanges and got this
> reply
> 
> Reporting-MTA: dns;VI1EUR04HT091.mail.protection.outlook.com
> Received-From-MTA: dns;DBAPR01MB7126.eurprd01.prod.exchangelabs.com
> Arrival-Date: Mon, 14 Dec 2020 23:33:24 +
> 
> Final-Recipient: rfc822;amdln...@googlemail.com
> Action: failed
> Status: 5.1.1
> Diagnostic-Code: smtp;550-5.1.1 The email account that you tried to reach 
> does not exist. Please try

I don't think this is the maintainer address, but someone being
subscribed to mailing lists and Microsoft's electronic telefax[1]
solution sending error messages to the address given in the "From"
header instead of the envelope address (which should be the mailing
list software).

ftpmaster got several bounces as well for mails sent to debian-devel-
changes@.

The error message from the telefax service should contain the original
message headers which should help finding out which Outlook address
produces the problem (e.g. X-MS-Exchange-Inbox-Rules-Loop and others)
and where they are subscribed (e.g. the mailing list in the "List-Id"
field or similar).

If the error messages are related to list mail, you should probably
contact listmaster@l.d.o; I've done so for the bounces I saw.

Ansgar

  [1]: It certainly doesn't seem to be normal email in many ways ;-)

Bug#973848: chromium: Unsupported version, many security bugs unfixed

[Michel Le Bihan]

Hello,

> I suspect that debian's libvpx might need to be build with
experimental features enabled (similar to a previous bug report), in
order to include the absent header files.

This will build the lib, but the header isn't correctly exported. They
don't export the header file for that and the internal header used by
Chromium requires many other internal headers.

> Are you sure that fixes/sequence-point.patch is necessary? I don't
recall getting any warnings related to this when compiling.

I don't know. I don't see the warning mentioned in the commit without
that patch, but I also don't see the commit in Chromium that could
change that.

> Looking at the last couple of commits for the file affected by the
ozone problem [1], it appears to be already fixed upstream.

Great! That will make one less patch to update on next release!

I'm still missing 4 patches:
buster/icu63: Without that one it might be difficult to get the update
in Buster
system/vpx: It's better to use system libs it it isn't too difficult.
There is one commit in Chromium introducing the usage of that
experimental feature. Maybe the patch could revert it?
system/harfbuzz: I didn't investigate what's wrong with it. Just used
in tree version.
A patch for proprietary codecs + system ffmpeg.

Maybe more will be needed for Lintian warnings and errors.

Does anybody have any of the mentioned patches updated/written? It
would avoid duplicate work. I know those are the most difficult patches
to update.

Michel Le Bihan

Bug#977427: mariadb-10.5: bullseye: /updates -> -security

[Paul Wise]

Source: mariadb-10.5
Version: 1:10.5.8-3
Severity: minor
File: storage/mroonga/packages/apt/build-deb.sh
User: debian-de...@lists.debian.org
Usertags: bullseye-security

With the release of Debian bullseye and later, security updates are
provided in the bullseye-security suite instead of bullseye/updates.

In the mariadb source package there appears to be a script that
generates a Debian chroot/container for building packages and that
script relies on appears to write an apt sources.list that will
not provide security updates for packages installed in the
chroot/container. I suggest that this script check the version of the
Debian release in question using distro-info and then if the release is
11 or higher, then use $release-security otherwise use $release/updates
as before. It is much better to use distro-info than to hard-code the
release version numbers. It might even be a good idea to include the
security suite information in distro-info itself and look it up there.

I filed this bug at severity minor since the script in question doesn't
appear to be used for any part of the Debian packages nor for building
the Debian packages, but only for some upstream packages.

   mariadb-10.5-10.5.8 $ grep -A6 -B10 /updates  
storage/mroonga/packages/apt/build-deb.sh
   distribution=$(lsb_release --id --short | tr 'A-Z' 'a-z')
   case "${distribution}" in
 debian)
   component=main
   run cat < /etc/apt/sources.list.d/groonga.list
   deb http://packages.groonga.org/debian/ ${code_name} main
   deb-src http://packages.groonga.org/debian/ ${code_name} main
   EOF
   if ! grep --quiet security /etc/apt/sources.list; then
 run cat < /etc/apt/sources.list.d/security.list
   deb http://security.debian.org/ ${code_name}/updates main
   deb-src http://security.debian.org/ ${code_name}/updates main
   EOF
   fi
   run apt-get update
   run apt-get install -y --allow-unauthenticated groonga-keyring
   run apt-get update
   ;;

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#971713: sysstat: init or systemd file has overlapping runlevels

[Robert Luberda]

Trek pisze:

Hi,

> 
> so the fix would be like the one attached to this mail

I've tried this update-rc.d -f sysstat command manually, and then I run
'apt install --reinstall sysstat', and as the result the warning about
default stop level is fixed, but the original warning about overlapping
run-levels is not.


>> insserv: Script ssh has overlapping Default-Start and Default-Stop
>> runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.

What is surprising the ssh warning is shown even if I run insserv from
the command line without giving any other arguments:

robert@vox:/tmp$ sudo insserv
insserv: Script ssh has overlapping Default-Start and Default-Stop
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.
insserv: FATAL: service mountkernfs has to exist for service udev
insserv: FATAL: service mountdevsubfs has to exist for service hwclock
insserv: FATAL: service urandom has to exist for service networking
insserv: exiting now!

While the sysstat warning is shown only on upgrades.

Anyway I've just checked what the ssh links are:

robert@vox:/tmp$ sudo ls -la /etc/rc*.d/*ssh*
lrwxrwxrwx 1 root root 13 2017-03-27  /etc/rc2.d/K01ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 13 2017-03-27  /etc/rc3.d/K01ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 13 2017-03-27  /etc/rc4.d/K01ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 13 2017-03-27  /etc/rc5.d/K01ssh -> ../init.d/ssh

Removing the links removes the warning as well:

robert@vox:/tmp$ sudo update-rc.d -f ssh remove
insserv: Script ssh has overlapping Default-Start and Default-Stop
runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.

robert@vox:/tmp$ sudo insserv
insserv: FATAL: service mountkernfs has to exist for service udev
insserv: FATAL: service mountdevsubfs has to exist for service hwclock
insserv: FATAL: service urandom has to exist for service networking
insserv: exiting now!

Even apt install --reinstall sysstat does not display any warning.

But when I re-add the K01ssh links, 'apt install --reinstall sysstat'
warns about ssh, and no longer about sysstat service...

Oh, wait, I've just read my email from Sunday, and it looks like the
warning on my system was always about ssh:
>> insserv: warning: current stop runlevel(s) (empty) of script
>>`sysstat' overrides LSB defaults (0 1 6).
>> insserv: Script ssh has overlapping Default-Start and Default-Stop
   ^^^
>> runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.

Sorry about not noticing it before, I must have been too strongly
suggested by the Julian's original bug report :(

So it looks like the warning says that run-level links were customized
by a user. IMHO it would be nice if the warning message stated this
simple fact in a more explicit way.

> 
> this instead comes from ssh, that have an empty Default-Stop too
> 
> @Robert Luberda: I ran out of ideas, your script was correct with an
> empty Default-Stop field, like the ssh one!

I looked into insserv(8) man page before changing the script, and was
under impression that Default-Start and Default-Stop must contain at
least one run level, as the example given at the top of the man page says:

# Default-Start: run_level_1 [ run_level_2 ...]
# Default-Stop:  run_level_1 [ run_level_2 ...]


But if you're sure they can be empty, I will revert the change in
sysstat's init.d script.

Regards,
robert

Bug#971713: sysstat: init or systemd file has overlapping runlevels

[Trek]

On Mon, 14 Dec 2020 03:54:28 +0100
Lorenzo  wrote:

> if you are searching in the source under /debian directory, the code
> that you are looking for will be written by dh-installinit in place of
> the #DEBHEPLER# placeholder, during the build of the package.

@Lorenzo oh yeah, many thanks :)

so the fix would be like the one attached to this mail

but reading the init.d script I see that it does not stop anything, so
an empty Default-Stop should be correct

what I really don't understand now it's from where those messages come
from:

> insserv: Script sysstat has overlapping Default-Start and
> Default-Stop runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.

running insserv on a script with an empty Default-Stop field does not
print this message, at least with buster and sid versions

reading the source, it could set an empty Default-Stop to the value of
Default-Start, but only when compiled with the -DSUSE flag enabled:

  https://sources.debian.org/src/insserv/1.21.0-1/insserv.c/#L3727

and this flag is not enabled on debian builds


> insserv: Script ssh has overlapping Default-Start and Default-Stop
> runlevels (2 3 4 5) and (2 3 4 5). This should be fixed.

this instead comes from ssh, that have an empty Default-Stop too

@Robert Luberda: I ran out of ideas, your script was correct with an
empty Default-Stop field, like the ssh one!

Actually I'm running a buster installation, but using the sid insserv
binary it does not show this issue, so I can't debug further for now

ciao!
diff --git a/debian/sysstat.postinst b/debian/sysstat.postinst
index f4730d0..3ea1596 100644
--- a/debian/sysstat.postinst
+++ b/debian/sysstat.postinst
@@ -114,6 +114,11 @@ if [ "$1" = "configure" ] ; then
 --slave /usr/share/man/man1/sar.1.gz sar.1.gz \
 /usr/share/man/man1/sar.sysstat.1.gz
 fi
+
+# new Default-Stop (see #971713)
+if dpkg --compare-versions "$2" le '12.4.1-2'; then
+update-rc.d -f sysstat remove
+fi
 fi
 
 #DEBHELPER#

Bug#977426: git-debrebase: complains about undocumented snag: -fanchor-treated

[Wookey]

Package: git-debrebase
Version: 9.12
Severity: normal


The issue is that when I try to update tyo a new release I get this complaint:
$ git debrebase new-upstream 20.05
git-debrebase: snag detected (-fanchor-treated): old anchor is recognised due 
to --anchor, cannot check upstream

I don't understand what it is complaining about and whilst -fanchor is
described in man 1 git-debrebase -fanchor-treated is not. So
documenting this would be good. If you explain it to me I could try
and document it myself and supply a patch.


The situation is this:

I prepared a package (armnn 19.11) using dgit and the dgit-maint-debrebase 
process.  
https://browse.dgit.debian.org/armnn.git/log/ a while ago.

I copied it to salsa, where my collaborator Francis added some more
patches to both upstream and debian/ dir (He also did a load of
psuedomerging which I _think_ included operations not permitted in a

git debrebasing repo - it was certainly messy).
https://salsa.debian.org/deeplearning-team/armnn

The task is now to update to 20.05 release (from 
https://github.com/ARM-software/armnn) 

If I just "dgit clone armnn", make sure it knows about upstream and
"git debrebase new-upstream 20.08" I get the above issue.  I also get
the same complaint if I take my existing repo, cherry-pick the good
patches out of the above salsa mess, and then try to git debrebase
new-upstream 20.08

git-debrebase thinks the anchor is the initial "Add debian dir with
initial packaging" which seems correct.

Adding -fanchor-treated makes the rebase proceed as expected, but I'd
like to understand why that is needed rather than blindly adding it.

Bug#977425: gnuradio: FTBFS: dh_missing: usr/libexec/gnuradio/grc_setup_freedesktop

[Vagrant Cascadian]

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

I was unable to build gnuradio; it would fail with dh_missing finding an
uninstalled usr/libexec/gnuradio/grc_setup_freedesktop.

The attached patch fixes this by installing the file in the gnuradio
package, if that seems like an appropriate place for it.


That said, I'm not entirely sure what triggers the issue; the buildds
seem to build gnuradio fine and it also seems to build fine on the
reproducible builds infrastructure. Maybe it is a very recent change in
one of the build dependencies? I've rescheduled a build on
tests.reproducible-builds.org to see if it triggers the issue.


live well,
  vagrant
From 8149639e81578582e7e408eb490c1b1aae00f837 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 14 Dec 2020 21:52:42 +
Subject: [PATCH 2/2] gnuradio: install
 usr/libexec/gnuradio/grc_setup_freedesktop

---
 debian/gnuradio.install | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/gnuradio.install b/debian/gnuradio.install
index 38d5b74..5244434 100644
--- a/debian/gnuradio.install
+++ b/debian/gnuradio.install
@@ -6,3 +6,4 @@ usr/share/gnuradio
 usr/share/icons
 usr/share/metainfo
 usr/share/mime
+usr/libexec/gnuradio/grc_setup_freedesktop
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977420: qpdfview has circular Depends on qpdfview-pdf-mupdf-plugin|qpdfview-pdf-poppler-plugin

[Norbert Preining]

Hi Bill,

thanks for the report, good catch. Will be fixed in -4 (to be uploaded
soon).

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#977424: gnuradio: reproducible builds: files contain build timestamp dependent on timezone

[Vagrant Cascadian]

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

Several files shipped with gnuradio include the build time:

  ./usr/lib/aarch64-linux-gnu/libgnuradio-runtime.so.3.8.2.0

  2061  Mon,·07·Dec·2020·14:42:43
  2061  Tue,·08·Dec·2020·16:42:43


While gnuradio includes a patch to respect SOURCE_DATE_EPOCH, it does
not handle the timezone variation. The attached patch to the patch
updates it to use the UTC timezone.

This patch does not resolve all reproducibility issues (e.g. build
paths), but should make gnuradio reproducible when it lands in bullseye
(where build paths are not tested).


Thanks for maintaining gnuradio!


live well,
  vagrant
From 93250947630cb7c26882805d1287e44c5a414e4d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 14 Dec 2020 21:24:50 +
Subject: [PATCH 1/2] debian/patches: Update cmake timestamp patch to use UTC
 timezone.

Without this, the timestamp may vary based on the timezone of the
build system.
---
 .../patches/cmake-use-TIMESTAMP-function-to-generate-build_date | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/patches/cmake-use-TIMESTAMP-function-to-generate-build_date b/debian/patches/cmake-use-TIMESTAMP-function-to-generate-build_date
index d196d26..aa06074 100644
--- a/debian/patches/cmake-use-TIMESTAMP-function-to-generate-build_date
+++ b/debian/patches/cmake-use-TIMESTAMP-function-to-generate-build_date
@@ -30,7 +30,7 @@ Thanks to Sebastian Kosloswki for pointing out the right way in CMake
 +
 +# Use TIMESTAMP to be compatible with reproducible builds
 +# and put in in the cache so configure_file sees it
-+string(TIMESTAMP BUILD_DATE "%a, %d %b %Y %H:%M:%S")
++string(TIMESTAMP BUILD_DATE "%a, %d %b %Y %H:%M:%S" UTC)
 +set(BUILD_DATE ${BUILD_DATE} CACHE INTERNAL "Build date")
 +message(STATUS "Loading build date ${BUILD_DATE} into constants...")
 +message(STATUS "Loading version ${VERSION} into constants...")
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977423: maintainer address bounces

[Michael Biebl]

Source: apt-listchanges
Severity: serious

I just tried to file a bug report against apt-listchanges and got this
reply

Reporting-MTA: dns;VI1EUR04HT091.mail.protection.outlook.com
Received-From-MTA: dns;DBAPR01MB7126.eurprd01.prod.exchangelabs.com
Arrival-Date: Mon, 14 Dec 2020 23:33:24 +

Final-Recipient: rfc822;amdln...@googlemail.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp;550-5.1.1 The email account that you tried to reach does 
not exist. Please try
 550-5.1.1 double-checking the recipient's email address for typos or
 550-5.1.1 unnecessary spaces. Learn more at
 550 5.1.1  https://support.google.com/mail/?p=NoSuchUser w1si79431edl.297 - 
gsmtp
Remote-MTA: dns;mx.google.com



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

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

-- debconf information excluded

Bug#977422: News entry is not shown on upgrades

[Michael Biebl]

Package: apt-listchanges
Version: 3.22+nmu2
Severity: important

Hi,

sometimes, apt-listchanges doesn't show NEWS entries when it is supposed
to show them.
I suspect this happens, when a src package builds multiple binary
packages and the NEWS entry is not from the "main" binary package.

A specific case is src:systemd which builds the udev package
See 
https://salsa.debian.org/systemd-team/systemd/-/merge_requests/113#note_207684
which illustrates the problem.

If I upgrade udev alone, the NEWS entry for udev is shown.
If I upgrade all binary packages from src:systemd, the NEWS entry is not
shown.

The test VM is still available, so if you want me to run further
diagnostics, please let me know.

Regards,
Michael



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

Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.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 apt-listchanges depends on:
ii  apt2.1.13
ii  debconf [debconf-2.0]  1.5.74
ii  python33.9.0-4
ii  python3-apt2.1.7
ii  python3-debconf1.5.74
ii  sensible-utils 0.0.12+nmu1
ii  ucf3.0043

apt-listchanges recommends no packages.

Versions of packages apt-listchanges suggests:
ii  epiphany-browser [www-browser]3.38.1-2
ii  firefox [www-browser] 83.0-1
ii  gnome-terminal [x-terminal-emulator]  3.38.1-2
ii  google-chrome-stable [www-browser]87.0.4280.88-1
ii  konsole [x-terminal-emulator] 4:20.12.0-1
ii  lynx [www-browser]2.9.0dev.6-1
ii  postfix [mail-transport-agent]3.5.6-1
ii  python3-gi3.38.0-1+b2
ii  sakura [x-terminal-emulator]  3.7.1-2
ii  tilix [x-terminal-emulator]   1.9.3-4+b3
ii  w3m [www-browser] 0.5.3-38+b1
ii  xterm [x-terminal-emulator]   362-1

-- debconf information excluded

Bug#921436: No longer suffering it

[Jaime Crespo]

I changed monitors and I no longer suffer from this issue, or can
provide feedback about it. It can be closed/resolved.

-- 
Jaime Crespo

Bug#924652: Cannot reproduce it anymore

[Jaime Crespo]

After changing the graphic card and upgrading the graphic driver, I no
longer have this issue with window scaling. Gwenview and other kde
programs render images correctly. Not sure if the issue was the card
or the driver, or any other kde update, but I no longer have this
issue.

-- 
Jaime Crespo

Bug#977421: rust-sha1collisiondetection: FTBFS on architectures with unsigned char

[Daniel Kahn Gillmor]

Package: rust-sha1collisiondetection
Version: 0.2.2-1
Severity: critical
Control: forwarded -1 
https://gitlab.com/sequoia-pgp/sha1collisiondetection/-/issues/1

Looks like rust-sha1collisiondetection code isn't as portable as
upstream expected it to be.  It is failing on platforms with an unsigned
char, with errors like:

~~~
error[E0308]: mismatched types
   --> lib/lib.rs:252:31
|
252 | ...   input.as_ptr() as *const i8,
|   ^^^ expected `u8`, found 
`i8`
|
= note: expected raw pointer `*const u8`
   found raw pointer `*const i8`
~~~

This means that the package fails to build from source on arm, powerpc,
riscv, and s390 architectures.

This is reported to upstream at
https://gitlab.com/sequoia-pgp/sha1collisiondetection/-/issues/1 so
hopefully they'll sort it out shortly.

 --dkg


signature.asc
Description: PGP signature

Bug#977420: qpdfview has circular Depends on qpdfview-pdf-mupdf-plugin|qpdfview-pdf-poppler-plugin

[Bill Allombert]

Package: qpdfview
Version: 0.4.18-3
Severity: important

Hello Norbert,

There is a circular dependency between qpdfview and 
qpdfview-pdf-mupdf-plugin|qpdfview-pdf-poppler-plugin:

qpdfview:Depends: qpdfview-pdf-poppler-plugin | 
qpdfview-pdf-mupdf-plugin
qpdfview-pdf-mupdf-plugin   :Depends: qpdfview (= 0.4.18-3)
qpdfview-pdf-poppler-plugin :Depends: qpdfview (= 0.4.18-3)

Circular dependencies are known to cause problems during upgrade between
stable releases, so we should strive to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#977419: lintian: Use of uninitialized value in string eq at package-relations.pm

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.104.0
Severity: important

Hello!

While checking the apt-listbugs package (which I maintain), I experienced
an awkward lintian behavior:

  $ lintian -viF apt-listbugs_0.1.35~rc3_amd64.changes
  N: Using profile debian/ftp-master-auto-reject.
  N: Starting on group apt-listbugs/0.1.35~rc3
  Warning in group apt-listbugs/0.1.35~rc3: Use of uninitialized value in 
string eq at /usr/share/lintian/checks/fields/package-relations.pm line 129.
  Warning in group apt-listbugs/0.1.35~rc3: Use of uninitialized value in 
string eq at /usr/share/lintian/checks/fields/package-relations.pm line 129.
  [...]
  N: Finished processing group apt-listbugs/0.1.35~rc3

with the warning repeated 188 times.

If I enable more checks with:

  $ lintian -EviIL +pedantic apt-listbugs_0.1.35~rc3_amd64.changes

I get the same 188 warnings and two false positives:

  E: apt-listbugs: alternates-not-allowed Depends
  N:
  E: alternates-not-allowed
  N:
  N:   Only the "Depends", "Recommends", "Suggests" and "Pre-Depends" fields
  N:   may specify alternate dependencies using the "|" symbol.
  N:
  N:   Refer to Debian Policy Manual section 7.1 (Syntax of relationship
  N:   fields) for details.
  N:
  N:   Severity: error
  N:
  N:   Check: fields/package-relations
  N:
  E: apt-listbugs: alternates-not-allowed Suggests

I _think_ that these two complaints are false positives, since the
[debian/control] file has not changed since version 0.1.34 and
the same file has been previously (on December the 5th, 2020)
checked by the same version 2.104.0 of lintian, without any
complaint.
And I cannot understand what's wrong with the debian/control file.
But of course, I may be wrong: if this is the case, then please
help me understand...

[debian/control]: 


Is this new awkward behavior of lintian caused by some recent Perl
package upgrade in sid?
Among the lintian dependencies, I see the following changed versions:

  libicu67:amd64 (67.1-4)  ->  (67.1-5)
  libxml2:amd64 (2.9.10+dfsg-6.3)  ->  (2.9.10+dfsg-6.3+b1)
  liblist-moreutils-perl (0.416-1+b6)  ->  (0.430-1)

and nothing else, it seems.

Please investigate and fix this issue.
Thanks for your time!

Bye.



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

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

Versions of packages lintian depends on:
ii  binutils2.35.1-4
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.39-3
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b4
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b6
ii  libclone-perl   0.45-1+b1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.25-1+b1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b3
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.430-1
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004004-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b7
ii  libproc-processtable-perl   0.59-2+b1
ii  libsereal-decoder-perl  4.018+ds-1+b1
ii  libsereal-encoder-perl  4.018+ds-1+b1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b8
ii  libtext-markdown-discount-perl  0.12-1+b1
ii  libtext-xslate-perl 3.5.8-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b3
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.012000-1
ii  libunicode-utf8-perl0.62-1+b2
ii  liburi-perl 5.05-1
ii  libxml-libxml-perl  2.0134+dfsg-2+b1
ii  libyaml-libyaml-perl0.82+repac

Bug#977355: UserWarning: cannot parse package relationship "i", returning it raw

[Stuart Prescott]

On Monday, 14 December 2020 21:42:08 AEDT Raphaël Hertzog wrote:
> This is due to a buggy package containing a dependency on "i" (it's
> libmagics++-dev, bug filed already) but I don't see any reason for deb822
> to fail on this dependency. It's a very short package name that we should
> likely not allow in Debian but I don't a reason to not be able to parse
> it (in particular when nothing else in the build machinery choked on that
> dependency, starting with dpkg-gencontrol).
> 
> Please update the __dep_RE regex to accept single-character dependencies:
> 
>1421 __dep_RE = re.compile(
>1422 r'^\s*(?P[a-zA-Z0-9.+\-]{2,})'

Policy demands that package names be at least two characters long which is 
where this requirement originally came from. On the other hand, policy also 
demands that the package name start with [a-z0-9] and be all lower case and 
this regex doesn't enforce either of those requirements.

https://www.debian.org/doc/debian-policy/ch-controlfields.html#source

This is the classic "should we validate the input?" problem that python-debian 
always struggles with. In other places, we've made the strictness of 
validation optional, but that doesn't look to be feasible here.

I guess it's reasonable to simply allow a single character to start, as in:

(?P[a-zA-Z0-9][a-zA-Z0-9.+\-]*)

(that still disallows packages to start with . + -)

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#976653: dfwinreg FTBFS: missing: pycreg

[Sergio Durigan Junior]

Control: tags -1 + patch
On Sunday, December 06 2020, Adrian Bunk wrote:

> https://buildd.debian.org/status/fetch.php?pkg=dfwinreg&arch=all&ver=20201006-1&stamp=1607180871&raw=0
>
> ...
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> python3 run_tests.py
> Using Python version 3.9.1rc1 (default, Nov 27 2020, 19:38:39) 
> [GCC 10.2.0]
> Checking availability and versions of dependencies.
> [OK]  dfdatetime version: 20200824
> [OK]  dtfabric version: 20200621
> [FAILURE] missing: pycreg
> [OK]  pyregf version: 20201007
> [OK]  yaml version: 5.3.1
>
> make[1]: *** [debian/rules:20: override_dh_auto_test] Error 1

I tried opening an MR against the package, but the git repository is not
up-to-date.  I am therefore proposing the following debdiff here.  I've
uploaded it to DELAYED/5, just in case this bug doesn't get the
necessary attention.

Hilko or anyone from pkg-security, feel free to remove my upload and
prepare on yourselves, if you want :-).

Thanks,

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

diff -Nru dfwinreg-20201006/debian/changelog dfwinreg-20201006/debian/changelog
--- dfwinreg-20201006/debian/changelog  2020-12-05 08:36:37.0 -0500
+++ dfwinreg-20201006/debian/changelog  2020-12-14 17:14:54.0 -0500
@@ -1,3 +1,11 @@
+dfwinreg (20201006-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * B-D on python3-libcreg, which solves a FTBFS during testing.
+  (Closes: #976653)
+
+ -- Sergio Durigan Junior   Mon, 14 Dec 2020 17:14:54 
-0500
+
 dfwinreg (20201006-1) unstable; urgency=medium
 
   [ Samuel Henrique ]
diff -Nru dfwinreg-20201006/debian/control dfwinreg-20201006/debian/control
--- dfwinreg-20201006/debian/control2020-12-05 08:36:37.0 -0500
+++ dfwinreg-20201006/debian/control2020-12-14 17:14:08.0 -0500
@@ -12,6 +12,7 @@
  python3-mock,
  python3-six (>= 1.1.0),
  python3-yaml (>= 3.10),
+ python3-libcreg ,
 Standards-Version: 4.3.0
 Homepage: https://github.com/log2timeline/dfwinreg
 Vcs-Git: https://salsa.debian.org/pkg-security-team/dfwinreg.git


signature.asc
Description: PGP signature

Bug#977418: pki-base-java circular dependency with pki-tools

[Bill Allombert]

Package: pki-base-java
Version: 10.10.1-1
Severity: important

Hello Debian FreeIPA Team,

There is a circular dependency between pki-base-java and pki-tools:

pki-base-java   :Depends: pki-tools
pki-tools   :Depends: pki-base-java (= 10.10.1-1)

Complex circular dependencies are known to cause problems during upgrade, so we
should strive to avoid them.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#974616: nomacs: "charset=Ascii" appears before the comment of the image

[Vincent Lefevre]

Control: retitle -1 nomacs uses internal libexiv2 functions to get the user 
comment
Control: severity -1 serious
Control: tags -1 - patch

On 2020-12-12 21:59:38 +0100, Vincent Lefevre wrote:
> I'm attaching the patch I've written. There was already a function
> that removes substrings of the form 'charset="ASCII"' case
> insensitively. So I do the same thing with 'charset=ASCII'
> (i.e. without the double-quotes) and 'charset=Unicode', which
> appears when the string has non-ASCII characters.
> 
> Note that this function is a hack: it will remove real occurrences
> of such strings, not just those added by libexiv2. However, there
> is very little probability that such strings really appear in the
> comment. And one cannot do much better to fix the issue.

This is just a workaround that seems to work with the current
libexiv2 version, but according to the upstream libexiv2 maintainer,
nomacs uses some internal libexiv2 function, which means that an
update of libexiv2 can break it at any time, potentially introducing
security issues.

Note that a change of behavior could have already been seen with the
upgrade of libexiv2-27 to 0.27.3 with the appearance of spurious data
before the comment.

The correct way to get the comment with the public API is

  std::string comment = Exiv2::CommentValue(value().toString()).comment());

Note: The upstream nomacs version comes with a bundled libexiv2,
meaning that this may not be an issue to use internal libexiv2
features. Debian chose to use the shared library, thus it needs
to replace these internals by calls to the public API.

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

Bug#974608: gthumb uses internal libexiv2 functions

[Vincent Lefevre]

Control: retitle -1 gthumb uses internal libexiv2 functions to get the user 
comment

The bug should be retitled accordingly.

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

Bug#977177: Mistakes were made ... klayout: reproducible builds: Binaries contain build timestamps

[Vagrant Cascadian]

user reproducible-bui...@lists.alioth.debian.org
usertags 977412 - timestamps
thanks

Oops, meant for the klayout patch to go to a new bug report, sorry for
the noise!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#974608: gthumb uses internal libexiv2 functions

[Vincent Lefevre]

Control: severity -1 serious

According to the upstream libexiv2 maintainer, gthumb uses some
internal libexiv2 function, which means that an update of libexiv2
can break it at any time, potentially introducing security issues.

Note that a change of behavior could have already been seen with
the upgrade of libexiv2-27 to 0.27.3 with the appearance of spurious
data before the comment.

The correct way to get the comment is

  std::string comment = Exiv2::CommentValue(value().toString()).comment());

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

Bug#968484: wireshark hard-wired to libsystemd0?

[Thorsten Glaser]

On Mon, 14 Dec 2020, Cristian Ionescu-Idbohrn wrote:

> > It doesn't depend on the init, but it links against the library to
> > parse the journal files,
>
> I have no journal files on my system (yet).  So, that dependency is
> total nonsense to me.

Not on your system but in the packet stream it analyses.
AIUI when capturing data traffic, wireshark can inspect
the traffic if it is structured data, and for this it
needs interpreters for the various formats, and I think
it just reuses the libsystemd0 one for network logging.

> are more intelligent ways to handle that.  After all, wireshark is a
> network traffic sniffer, AFAICT, and should _not_ impose journal file
> parsing on its users.

See above.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

control: tag -1 + patch



On Mon, Dec 14, 2020 at 3:42 PM Sean Whitton 
wrote:

>
> Could you provide an actual patch against policy.git, please, for
> seconding?  See README.md in policy.git for more info.
>
> --
> Sean Whitton
>


https://salsa.debian.org/steele/policy/-/tree/bug976402-steele

diff --git a/virtual-package-names-list.yaml
b/virtual-package-names-list.yaml
index 2a9857a..11afe1e 100644
--- a/virtual-package-names-list.yaml
+++ b/virtual-package-names-list.yaml
@@ -65,6 +65,9 @@ virtualPackages:
 - name: tclsh
   description: a /usr/bin/tclsh
   alternatives: [/usr/bin/tclsh]
 {+- name: todo.txt+}
{+   description: a command-line task management utility compatible with
todo.txt CLI (http://todotxt.org)+}
{+   alternatives: [/usr/bin/todo.txt]+}
 - name: wish
   description: a /usr/bin/wish
   alternatives: [/usr/bin/wish]

Bug#968484: wireshark hard-wired to libsystemd0?

[Cristian Ionescu-Idbohrn]

On Wed, 11 Nov 2020, Thorsten Glaser wrote:
> On Wed, 11 Nov 2020, Juliusz Chroboczek wrote:
> 
> > Why on earth would a network traffic analyzer depend on system init?
> 
> Please read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968379#10
> in which all questions regarding this were satisfyingly answered.

Not from my POV.

> It doesn't depend on the init, but it links against the library to 
> parse the journal files,

I have no journal files on my system (yet).  So, that dependency is 
total nonsense to me.

> and the versioned dependency is autogenerated because it uses a 
> symbol that changed in the later version.

Got that.

Still, loading that library should be optional, anyway.  If the 
required version does not exist and/or no journal files exist, the 
code should ignore parsing journal files instead of forcing me to 
install either libraries and breaking my OS.

> An upgrade of elogind is being worked on, but apparently 
> systemd developers make that difficult by restructuring the 
> codebase.

That's a too friendly way to put it, IMO.

> Balint, would it be possible to build wireshark against the elogind 
> libraries to avoid the versioned dependency?

Well, I'd very much like to skip that dependency too, as long as there 
are more intelligent ways to handle that.  After all, wireshark is a 
network traffic sniffer, AFAICT, and should _not_ impose journal file 
parsing on its users.


Cheers,

-- 
Cristian

Bug#976402: Proposed official virtual packages - todo and todo.txt

[David Steele]

On Mon, Dec 14, 2020 at 3:48 PM Sean Whitton 
wrote:

>
>
> Putting aside the use of the alternatives system, why is a virtual
> package wanted?  When would it be useful to be able to declare a
> dependency and have it satisfied by one of these implementations?
>
>
As an example, a future rev of an integrated todo.txt-gtd[1] would depend
on that virtual package.

[1]:  https://github.com/davesteele/todo.txt-gtd

Bug#977416: klayout: reproducible builds: /usr/bin/klayout broken when /bin/sh points to bash

[Vagrant Cascadian]

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

When /bin/sh points to bash, the generated /usr/bin/klayout contains the
'\n' character intended instead of the intended newline.

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

  ./usr/bin/klayout
  1 #!/bin/sh
  2 LD_LIBRARY_PATH=/usr/lib/klayout·exec·/usr/lib/klayout/klayout·"$@"  1 
#!/bin/sh\nLD_LIBRARY_PATH=/usr/lib/klayout·exec·/usr/lib/klayout/klayout·"$@"


The attached patch fixes this by making two calls to echo when
generating /usr/bin/klayout.


This patch alone does not resolve all reproducibility issues (e.g. build
paths), but when combined with the timestamp patch just submitted,
should result in a reproducible build when it lands in bullseye, where
build paths are not varied.


Thanks for maintaining klayout!


live well,
  vagrant
From cbf4cbff1b977a0f0e34c4054ed558fe98f8273b Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 14 Dec 2020 20:22:43 +
Subject: [PATCH 2/2] debian/rules: Generate klayout script consistently
 regardless of shell.

The behavior of 'echo "\n"' is different when /bin/sh points to bash
vs. dash, resulting in a broken /usr/bin/klayout script.

Call echo twice instead to ensure reproducibility regardless of which
shell is used.
---
 debian/rules | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/rules b/debian/rules
index dc35ce0..8353543 100755
--- a/debian/rules
+++ b/debian/rules
@@ -32,7 +32,8 @@ override_dh_auto_install:
 	mkdir -p debian/klayout/usr/lib/klayout
 	CC=$(CC) CXX=$(CXX) OBJCOPY=objcopy AR=$(AR) CXXFLAGS="$(CXXFLAGS)" CFLAGS="$(CFLAGS)" ./build.sh -qt5 -option $(EXTRA_MAKE_OPTIONS) -expert -qmake /usr/lib/$(MULTIARCH)/qt5/bin/qmake -bin $(CURDIR)/debian/klayout/usr/lib/klayout
 	mkdir -p debian/klayout/usr/bin
-	echo "#!/bin/sh\nLD_LIBRARY_PATH=/usr/lib/klayout exec /usr/lib/klayout/klayout \"\$$@\"" > debian/klayout/usr/bin/klayout
+	echo '#!/bin/sh' > debian/klayout/usr/bin/klayout
+	echo "LD_LIBRARY_PATH=/usr/lib/klayout exec /usr/lib/klayout/klayout \"\$$@\"" >> debian/klayout/usr/bin/klayout
 	chmod +x debian/klayout/usr/bin/klayout
 	chmod -x debian/klayout/usr/lib/klayout/pymod/klayout/db/__init__.py
 	chmod -x debian/klayout/usr/lib/klayout/pymod/klayout/db/pcell_declaration_helper.py
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#962203: NMU

[Calum McConnell]

I have prepared an NMU for this package.  It is currently at
https://mentors.debian.net/package/debdelta/ .  While I need a sponsor to
get it into Debian, I am now reaching out to ment...@lists.debian.org to
see if I can expedite the process.


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

Bug#977415: klayout: reproducible builds: Binaries contain build timestamps

[Vagrant Cascadian]

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

Several binaries shipped with klayout include the build time:

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

  ./usr/lib/klayout/klayout
  124   2021-12-18
  124   2020-11-16


The attached patch fixes this by adjusting the call to date in
version.sh to use the SOURCE_DATE_EPOCH environment variable.

This patch does not resolve all reproducibility issues (e.g. build
paths), but combined with a patch soon to follow, should make klayout
reproducible when it lands in bullseye (where build paths are not
tested).


Thanks for maintaining klayout!


live well,
  vagrant
From 7bf8f643614cf1398e7ef7108d3ba47200d8300d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 14 Dec 2020 19:56:24 +
Subject: [PATCH 1/2] Set KLAYOUT_VERSION_DATE in version.sh using value from
 SOURCE_DATE_EPOCH.

  https://reproducible-builds.org/docs/source-date-epoch/

This patch requires GNU date extensions, and may require adjustments
for portability with other date implementations.
---
 version.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/version.sh b/version.sh
index 7065aa1..03192ba 100644
--- a/version.sh
+++ b/version.sh
@@ -8,7 +8,7 @@ KLAYOUT_VERSION="0.26.2"
 KLAYOUT_PYPI_VERSION="0.26.2"
 
 # The build date
-KLAYOUT_VERSION_DATE=$(date "+%Y-%m-%d")
+KLAYOUT_VERSION_DATE=$(LC_ALL=C date --utc --date=@${SOURCE_DATE_EPOCH} "+%Y-%m-%d")
 
 # The short SHA hash of the commit
 KLAYOUT_VERSION_REV=$(git rev-parse --short HEAD 2>/dev/null)
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#977414: boost1.74: FTBFS on hurd-i386

[Pino Toscano]

Source: boost1.74
Version: 1.74.0-4
Severity: important
Tags: patch upstream fixed-upstream
X-Debbugs-Cc: gl...@debian.org
Control: forwarded -1 https://github.com/boostorg/build/pull/676

Hi,

boost 1.71 currently fails to build on Hurd [1].

The issue is that boost build ("b2") now tries to get its path (i.e.
the full path of the running executable), and the function for this
is not implemented on Hurd; the effect is that launching b2 with a
relative path, like ./b2 as done at different times during the build,
fails.

I recently sent upstream few small improvements for Hurd [2], including
the fix for the aforementioned issue. The series was recently merged
upstream for the future 1.76.0, so I'm attaching here only the part
of it needed to make b2 run properly (the rest is improvements that can
definitely wait for newer boost versions).

[1] 
https://buildd.debian.org/status/fetch.php?pkg=boost1.74&arch=hurd-i386&ver=1.74.0-4&stamp=1607921711&raw=0
[2] https://github.com/boostorg/build/pull/676

Thanks,
-- 
Pino
Author: Pino Toscano 
Description: Use /proc/self/exe for executable_path on Hurd
 .
 Use the Linux compatibility procfs translator to get the full path of
 the current executable.
Origin: 
https://github.com/boostorg/build/commit/25879fc24d96c89e817e7950ec92d6e2cb41e1b3
Applied-Upstream: 1.76.0

--- a/tools/build/src/engine/jam.cpp
+++ b/tools/build/src/engine/jam.cpp
@@ -747,7 +747,7 @@ char * executable_path( char const * arg
 sysctl( mib, 4, buf, &size, NULL, 0 );
 return ( !size || size == sizeof( buf ) ) ? NULL : strndup( buf, size );
 }
-#elif defined(__linux__)
+#elif defined(__linux__) || defined(__GNU__)
 # include 
 char * executable_path( char const * argv0 )
 {

Bug#977412: klayout: reproducible builds: Binaries contain build timestamps

[Vagrant Cascadian]

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

Several binaries shipped with klayout include the build time:

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

  ./usr/lib/klayout/klayout
  124   2021-12-18
  124   2020-11-16


The attached patch fixes this by adjusting the call to date in
version.sh to use the SOURCE_DATE_EPOCH environment variable.

This patch does not resolve all reproducibility issues (e.g. build
paths), but combined with a patch soon to follow, should make klayout
reproducible when it lands in bullseye (where build paths are not
tested).


Thanks for maintaining klayout!


live well,
  vagrant
From 7bf8f643614cf1398e7ef7108d3ba47200d8300d Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 14 Dec 2020 19:56:24 +
Subject: [PATCH 1/2] Set KLAYOUT_VERSION_DATE in version.sh using value from
 SOURCE_DATE_EPOCH.

  https://reproducible-builds.org/docs/source-date-epoch/

This patch requires GNU date extensions, and may require adjustments
for portability with other date implementations.
---
 version.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/version.sh b/version.sh
index 7065aa1..03192ba 100644
--- a/version.sh
+++ b/version.sh
@@ -8,7 +8,7 @@ KLAYOUT_VERSION="0.26.2"
 KLAYOUT_PYPI_VERSION="0.26.2"
 
 # The build date
-KLAYOUT_VERSION_DATE=$(date "+%Y-%m-%d")
+KLAYOUT_VERSION_DATE=$(LC_ALL=C date --utc --date=@${SOURCE_DATE_EPOCH} "+%Y-%m-%d")
 
 # The short SHA hash of the commit
 KLAYOUT_VERSION_REV=$(git rev-parse --short HEAD 2>/dev/null)
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#975242: segfault on all architectures if recompiled as of today

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look and could reproduce the crash.

As far as I see a virtual method is called through a shared library
boundary and somehow returns with a wrong value in the $sp register.
Therefore an instruction in memory without executable mapping is
tried to be executed, which results in this "segfault at ... error 15".

In the same area I found following warning, which I assume is
responsible for this stackpointer error:

ProcessingMode.cxx: In member function ‘virtual int 
OpenJade_DSSSL::ProcessingMode::RootRule::compareSpecificity(const 
OpenJade_DSSSL::ProcessingMode::Rule&) const’:
ProcessingMode.cxx:332:1: warning: no return statement in function 
returning non-void [-Wreturn-type]
  332 | }
  | ^

Attached patch attempts to fill in return statements to silence these
type of warnings, but they have to be double checked. With
these patch applied the example openjade call went through without crash.

Kind regards,
Bernhard


(gdb) bt
#0  0x55b539708b08 in ?? ()
#1  0x7ff0311eaf84 in OpenJade_DSSSL::ProcessingMode::addRootRule 
(this=0x55b539708b08, expr=..., 
ruleType=OpenJade_DSSSL::ProcessingMode::constructionRule, loc=..., interp=...) 
at ProcessingMode.cxx:376
#2  0x7ff0311f25a7 in OpenJade_DSSSL::SchemeParser::doRoot 
(this=0x7ffe734576c0) at SchemeParser.cxx:484
#3  0x7ff0311f9b91 in OpenJade_DSSSL::SchemeParser::parse 
(this=this@entry=0x7ffe734576c0) at SchemeParser.cxx:190
#4  0x7ff0311ff573 in OpenJade_DSSSL::StyleEngine::parseSpec 
(this=this@entry=0x55b5395edc30, specParser=..., charset=..., id=..., mgr=..., 
defVars=...) at StyleEngine.cxx:166
#5  0x7ff03117f61a in OpenJade_DSSSL::DssslApp::processSysid 
(this=0x7ffe73457970, sysid=...) at DssslApp.cxx:138
#6  0x7ff030c5bc7f in OpenSP::EntityApp::processArguments(int, char**) () 
from /lib/libosp.so.5
#7  0x7ff030c4b39b in OpenSP::CmdLineApp::run(int, char**) () from 
/lib/libosp.so.5
#8  0x55b538874a3b in main (argc=15, argv=0x7ffe73458088) at jade.cxx:206
From 1dbae3ee5a83418d9d590895ad73b76f900d9ab0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Mon, 14 Dec 2020 18:01:01 +0100
Subject: Fix some warnings.

warning: control reaches end of non-void function [-Wreturn-type]
warning: no return statement in function returning non-void [-Wreturn-type]

Debian-Bug: https://bugs.debian.org/975242
---
 style/FlowObj.cxx| 1 +
 style/Interpreter.cxx| 9 +
 style/ProcessingMode.cxx | 2 +-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/style/FlowObj.cxx b/style/FlowObj.cxx
index 49b09e9..2894e00 100644
--- a/style/FlowObj.cxx
+++ b/style/FlowObj.cxx
@@ -2958,6 +2958,7 @@ private:
   AcceptFlags af(fo.acceptFlags(context));
   if (af & afTableCell)
 	return true;
+  return false;
 }
 bool charsValid(size_t, const Location &loc, ProcessContext &context) {
   Interpreter &interp = *context.vm().interp;
diff --git a/style/Interpreter.cxx b/style/Interpreter.cxx
index 63b3022..8c8af4e 100644
--- a/style/Interpreter.cxx
+++ b/style/Interpreter.cxx
@@ -2572,6 +2572,7 @@ bool MaybeIntegerCharPropValues::setDefault(const StringC &name,
   interp.message(InterpreterMessages::charPropertyNotIntegerOrFalse,
 		 StringMessageArg(name),
 		 ELObjMessageArg(obj, interp));
+  return true;
 }
 
 bool MaybeIntegerCharPropValues::setValue(const StringC &name,
@@ -2692,28 +2693,34 @@ bool PublicIdCharPropValues::setValue(const StringC &name,
 
 ELObj *PublicIdCharPropValues::value(Char, Interpreter &) const
 {
+  return NULL;
 }
 
 ELObj *PublicIdCharPropValues::defaultValue(Interpreter &) const
 {
+  return NULL;
 }
 
 bool SymbolCharPropValues::setDefault(const StringC &, const Location &,
 		  ELObj *, Interpreter &)
 {
+  return true;
 }
 
 bool SymbolCharPropValues::setValue(const StringC &, const StringC &, const Location &,
 		ELObj *,Interpreter &)
 {
+  return true;
 }
 
 ELObj *SymbolCharPropValues::value(Char, Interpreter &) const
 {
+  return NULL;
 }
 
 ELObj *SymbolCharPropValues::defaultValue(Interpreter &) const
 {
+  return NULL;
 }
 
 bool ELObjCharPropValues::setDefault(const StringC &, const Location &,
@@ -2722,6 +2729,7 @@ bool ELObjCharPropValues::setDefault(const StringC &, const Location &,
   ASSERT(obj);
   interp.makePermanent (obj);
   def_ = obj;
+  return true;
 }
 
 bool ELObjCharPropValues::setValue(const StringC &, const StringC &chars,
@@ -2732,6 +2740,7 @@ bool ELObjCharPropValues::setValue(const StringC &, const StringC &chars,
   interp.makePermanent (obj);
   for(size_t i = 0; i < chars.size(); ++i)
 map_.setChar(chars[i], obj);
+  return true;
 }
 
 ELObj *ELObjCharPropValues::value(Char ch, Interpreter &) const
diff --git a/style/ProcessingMode.cxx b/style/ProcessingMode.cxx
index 1a36996..dc25761 100644
--- a/style/ProcessingMode.cxx
+++ b/style/ProcessingMode.cxx
@@ -328,7 +328,7 @@ ProcessingMode::RootRule::RootRule(const Ptr &action)
 
 int ProcessingMod

Bug#975075: tech-ctte: Should maintainers be able to block init compatibility changes?

[Philip Hands]

Sean Whitton  writes:

> It is difficult to think further about this without input from the
> maintainer as to how much this was a part of his motivation, and what
> experiences he has had led him to think in that way.

Hi All,

Could I just check if there's a point of common acceptability which both
sides of this discussion could live with?

Please don't assume that I'm offering this as a preferred outcome. I
would hope that we can come up with something better than this, but I
think that agreeing that this is an acceptable and achievable baseline
would provide a foundation on which to build something better.

My suggestion for a mutually bearable solution would be that the
network-manager package could have its dependency on libpam-systemd
changed to instead be something like:

  libpam-systemd | network-manager-nonsystemd

and that the init diversity folks could then take responsibility for
satisfying that optional dependency as they see fit in order to keep
network-manager available on non-systemd systems, which should insulate
the network-manager maintainer from almost all of the effort involved.

I say 'almost all' because I would imagine that non-systemd-related bugs
might be reported against network-manager occasionally, and need to be
reassigned, and one could also imagine that upstream might change things
in a way that was clearly going to break things on non-systemd systems,
in which case it would be polite if the network-manager maintainer would
open a bug mentioning that change against the network-manager-nonsystemd
package, etc.

If you think this approach is impractical for some reason, please say
so, because what I have in mind as a better option does rather rely on
this being available as a plausible fall-back position.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian

[Sean Whitton]

Hello Ansgar,

On Tue 24 Nov 2020 at 01:37PM +01, Ansgar wrote:

> Package: debian-policy
> Version: 4.5.1.0
> Severity: normal
>
> After a discussion in #-devel today I reviewed packages using other
> choices of "Rules-Requires-Root" than "no" and "binary-targets".  The
> query [1] found two uses:
>
> - wfrench 1.2.6-1.  This could just use "no"; a bug was filed[2].
>
> - libcap2 1:2.44-1.  Uses it for running tests as root, but doesn't support
>   fakeroot anyway.  Rules-Requires-Root can't however communicate this so
>   additional knowledge is needed.
>
> The complexity to support arbitrary additional keywords as choices of
> R³ seems overkill given there is just one real user (libcap2) and the
> current R³ specification doesn't handle that usecase fully either.
>
> Therefore I suggest to deprecate using R³ values other than "no" and
> "binary-targets" within Debian.
>
> (Unrelated: R³: no should probably be recommended.)

We would definitely need input from the designers of the R³ system
before removing anything (to my knowledge, the design was led by Niels
and Guillem).  They were designing for the very long term, so I don't
think we can safely infer much from the present contents of the archive.

I'm also not really convinced by your arguments that having these other
possible values adds much of a burden.  This is not about code which has
to be updated, just text.  We do not expect newcomers to imbibe
everything in Policy.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#957378: isoqlog: diff for NMU version 2.2.1-9.1

[Sudip Mukherjee]

Control: tags 957378 + patch
Control: tags 957378 + pending
--

Dear maintainer,

I've prepared an NMU for isoqlog (versioned as 2.2.1-9.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru isoqlog-2.2.1/debian/changelog isoqlog-2.2.1/debian/changelog
--- isoqlog-2.2.1/debian/changelog  2013-12-30 07:10:08.0 +
+++ isoqlog-2.2.1/debian/changelog  2020-12-14 21:55:29.0 +
@@ -1,3 +1,11 @@
+isoqlog (2.2.1-9.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix ftbfs with GCC-10. (Closes: #957378)
+- Add -fcommon to CFLAGS.
+
+ -- Sudip Mukherjee   Mon, 14 Dec 2020 21:55:29 
+
+
 isoqlog (2.2.1-9) unstable; urgency=low
 
   * Fixes wrong langfile after non-interactive install (Closes: #670225)
diff -Nru isoqlog-2.2.1/debian/rules isoqlog-2.2.1/debian/rules
--- isoqlog-2.2.1/debian/rules  2012-04-24 00:45:27.0 +0100
+++ isoqlog-2.2.1/debian/rules  2020-12-14 21:53:44.0 +
@@ -20,6 +20,8 @@
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
 endif
+CFLAGS += -fcommon
+
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
 endif

Bug#975250: clarify gathering together of copyright information

[Sean Whitton]

Hello Sam,

On Tue 01 Dec 2020 at 08:07AM -05, Sam Hartman wrote:

> * Sean would prefer that you not be able to collapse years.  He hasn't
>   said whether his objection is strong enough to try and block
>   consensus.

My initial comments were motivated by the very same concerns as Russ:

On Sat 21 Nov 2020 at 12:30PM -08, Russ Allbery wrote:

> In reality, this only matters because we have licenses that say it
> matters.  For example, the BSD license saying:
>
> 1. Redistributions of source code must retain the above copyright
>notice, this list of conditions and the following disclaimer.
>
> We're already arguably not *quite* following that rule by allowing
> coalescing of notices.  I think that's fine because (at least in US law)
> the copyright notice is soemthing with a legal definition and the
> coalesced form is legally equivalent, so we're preserving the notice in
> the way that matters.  But in order to rely on that argument, it feels
> like we should keep the notice legally equivalent, which would mean not
> adding years.

If there is a consensus within the FTP Team that collapsing years does
not violate this sort of condition in the text of licenses, then (qua
Policy Editor) I would be happy to permit collapsing years.  I have made
some enquiries to try to determine whether the FTP Team has a consensus
view on this.

If the FTP Team is not really sure whether this sort of thing is okay,
we could permit collapsing years just when the license does not have a
copyright notice reproduction requirement (see the changes in #955005
for another example of making Policy copyright notice requirements
conditional on particular licenses).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#976149: debian-policy: [9.3.2] drop requirement to not fail if /etc/default file is deleted

[Sean Whitton]

Hello,

On Mon 30 Nov 2020 at 07:49PM +01, Bill Allombert wrote:

> On Mon, Nov 30, 2020 at 02:37:08PM +0100, Oxan van Leeuwen wrote:
>> Source: debian-policy
>> Version: 4.5.1.0
>> Severity: normal
>>
>> Currently Policy requires that init.d scripts, and only init.d scripts, don't
>> fail if the corresponding /etc/default is removed (section 9.3.2, 
>> second-to-last
>> paragraph).
>>
>> Personally I interpret "not fail" as "succeed to function", i.e. it has to
>> actually start the daemon. I don't think that's a particularly sensible
>> requirement.
>
> 'not fail' here means that the script terminates with return code 0.

This is how I would read it too.  Would a patch to add "(i.e. exit with
return code 0)" resolve the original submitter's concerns?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#977185: nheko: switch to Boost 1.74

[Hubert Chathi]

On Sat, 12 Dec 2020 09:42:27 +0100, Sebastian Ramacher  
said:

> nheko currently hardcodes its boost build dependencies with an
> explicit version. Since the default boost version is now 1.74 and we
> are trying to remove boost 1.71 before the release of bullseye, please
> switch to 1.74 or to the unversioned boost packages.

Thanks.  The hard-coding was done when the default boost in sid was too
old for nheko.  I'll switch to the unversioned boost packages.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#977126: panic log attached Re: linux-image-rpi does not boot by qemu-system-arm -machine raspi0

[Ryutaroh Matsumoto]

Hi Ben, I figured out how to collect the kernel panic logs and they are 
attached.
I tried both "-machine raspi0,firmware=/usr/lib/u-boot/rpi_0_w/u-boot.bin" and
"-machine raspi1ap,firmware=/usr/lib/u-boot/rpi/u-boot.bin".
Both failed in the same way as attached.

If you think this symptom deserves a seperate bug report against
qemu-system-arm or linux-image-api, please tell me to do so.
I will file it.

An updated image (just "earlyprintk console=ttyAMA0" are added) is placed at
http://153.240.174.134:64193/disk-image-console-ttyAMA0-earlyprintk.qcow2

Best regards, Ryutaroh
Script started on 2020-12-15 06:00:47+09:00 [TERM="xterm-256color" 
TTY="/dev/pts/0" COLUMNS="80" LINES="24"]
$ qemu-system-arm -display gtk -machine 
raspi1ap,firmware=$HOME/uboot-rpi-armel/usr/lib/u-boot/rpi/u-boot.bin -sd 
autopkgtest-sid-armel.img  -serial stdio
WARNING: Image format was not specified for 'autopkgtest-sid-armel.img' and 
probing guessed raw.
 Automatically detecting the format is dangerous for raw images, write 
operations on block 0 will be restricted.
 Specify the 'raw' format explicitly to remove the restrictions.


U-Boot 2020.10+dfsg-1+b1 (Nov 19 2020 - 03:55:49 +)

DRAM:  448 MiB
RPI Model A+ (0x900021)
MMC:   mmc@7e202000: 0
Loading Environment from FAT... Unable to use mmc 0:1... In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
Bus usb@7e98: USB DWC2
scanning bus usb@7e98 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  2  1  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
767 bytes read in 15 ms (49.8 KiB/s)
U-Boot menu
1:  Debian GNU/Linux bullseye/sid 5.9.0-4-rpi
2:  Debian GNU/Linux bullseye/sid 5.9.0-4-rpi (rescue target)
Enter choice: 1:Debian GNU/Linux bullseye/sid 5.9.0-4-rpi
Retrieving file: /boot/initrd.img-5.9.0-4-rpi
11263318 bytes read in 4651 ms (2.3 MiB/s)
Retrieving file: /boot/vmlinuz-5.9.0-4-rpi
3536544 bytes read in 1579 ms (2.1 MiB/s)
append: LABEL=ROOT net.ifnames=0 consoleblank=0 rw console=ttyAMA0 console=tty1 
console=ttyUSB0 earlyprintk
Retrieving file: /usr/lib/linux-image-5.9.0-4-rpi/bcm2835-rpi-a-plus.dtb
12717 bytes read in 93 ms (132.8 KiB/s)
Kernel image @ 0x08 [ 0x00 - 0x35f6a0 ]
## Flattened Device Tree blob at 0260
   Booting using the fdt blob at 0x260
   Using Device Tree in place at 0260, end 026061ac

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 5.9.0-4-rpi (debian-ker...@lists.debian.org) 
(gcc-10 (Debian 10.2.0-18) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35.1) #1 
Debian 5.9.11-1 (2020-11-27)
[0.00] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), 
cr=00c5387d
[0.00] CPU: VIPT aliasing data cache, unknown instruction cache
[0.00] OF: fdt: Machine model: Raspberry Pi Model A+
[0.00] printk: bootconsole [earlycon0] enabled
[0.00] Memory policy: Data cache writeback
[0.00] Reserved memory: created CMA memory pool at 0x1800, size 64 
MiB
[0.00] OF: reserved mem: initialized node linux,cma, compatible id 
shared-dma-pool
[0.00] Zone ranges:
[0.00]   Normal   [mem 0x-0x1bff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x-0x1bff]
[0.00] Initmem setup node 0 [mem 0x-0x1bff]
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 113680
[0.00] Kernel command line: LABEL=ROOT net.ifnames=0 consoleblank=0 rw 
console=ttyAMA0 console=tty1 console=ttyUSB0 earlyprintk
[0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes, 
linear)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes, 
linear)
[0.00] mem auto-init: stack:off, heap alloc:on, heap free:off
[0.00] Memory: 365436K/458752K available (8192K kernel code, 582K 
rwdata, 1988K rodata, 1024K init, 253K bss, 27780K reserved, 65536K 
cma-reserved)
[0.00] random: get_random_u32 called from 
__kmem_cache_create+0x34/0x388 with crng_init=0
[0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] ftrace: allocating 25918 entries in 51 pages
[0.00] ftrace: allocated 51 pages with 4 groups
[0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[0.000890] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 
2147483647500ns
[0.002814] clocksource: timer: mask: 0x max_cycles: 0x, 
max_idle_ns: 1911260446275 ns
[0.011899] bcm2835: system timer (irq = 27)
[0.032085] Console: colour dummy device 80x30
[0.037519] printk: console [tty1] enabled

Bug#977412: xastir: reproducible builds: Binaries contain embedded paths from usrmerge systems

[Vagrant Cascadian]

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

Several binaries shipped with xastir include embedded paths to the "sed"
and "mv" commands:

  
https://tests.reproducible-builds.org/debian/rb-pkg/bullseye/i386/diffoscope-results/xastir.html

  4074  /bin/sed
  4074  /usr/bin/sed

The attached patches fix this by adding support for the SED_PATH and
MV_PATH variables to configure.ac, and passing those variables to
configure in debian/rules.


Thanks for maintaining xastir!


live well,
  vagrant
From aefe065298f0c141a1d8fa672173c6ff168c1c38 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 14 Dec 2020 21:03:31 +
Subject: [PATCH 1/2] debian/patches: Support passing SED_PATH And MV_PATH in
 configure.ac.

It is needed to be able to pass these variables to configure in order
for builds to be reproducible when package is built on a usrmerge
system vs. a non-usrmerge system.

https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 ...-SED_PATH-and-MV_PATH-to-be-able-to-.patch | 35 +++
 debian/patches/series |  1 +
 2 files changed, 36 insertions(+)
 create mode 100644 debian/patches/0001-configure.ac-Use-SED_PATH-and-MV_PATH-to-be-able-to-.patch

diff --git a/debian/patches/0001-configure.ac-Use-SED_PATH-and-MV_PATH-to-be-able-to-.patch b/debian/patches/0001-configure.ac-Use-SED_PATH-and-MV_PATH-to-be-able-to-.patch
new file mode 100644
index 000..519e5f9
--- /dev/null
+++ b/debian/patches/0001-configure.ac-Use-SED_PATH-and-MV_PATH-to-be-able-to-.patch
@@ -0,0 +1,35 @@
+From d1fac87519eb9b97fa503d0a3ac98a7662400d72 Mon Sep 17 00:00:00 2001
+From: Vagrant Cascadian 
+Date: Mon, 14 Dec 2020 03:20:51 +
+Subject: [PATCH] configure.ac: Use SED_PATH and MV_PATH to be able to specify
+ path to sed and mv.
+
+---
+ configure.ac | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/configure.ac b/configure.ac
+index d0e33fd..52e5226 100644
+--- a/configure.ac
 b/configure.ac
+@@ -159,7 +159,7 @@ AC_CHECK_LIB([Xm], [XmTextFindString])
+ 
+ 
+ use_sed=no
+-AC_PATH_PROG(sed, [sed --version], no, $BINPATH)
++AC_PATH_PROG(SED_PATH, [sed --version], no, $BINPATH)
+ if test "$sed" != "no"; then
+   AC_DEFINE_UNQUOTED(HAVE_SED, 1, [Define if you have sed]) 
+   AC_DEFINE_UNQUOTED(SED_PATH, "${sed}", [Path to sed]) 
+@@ -169,7 +169,7 @@ fi
+ 
+ 
+ use_mv=no
+-AC_PATH_PROG(mv, [mv --version], no, $BINPATH)
++AC_PATH_PROG(MV_PATH, [mv --version], no, $BINPATH)
+ if test "$mv" != "no"; then
+   AC_DEFINE_UNQUOTED(HAVE_MV, 1, [Define if you have mv]) 
+   AC_DEFINE_UNQUOTED(MV_PATH, "${mv}", [Path to mv]) 
+-- 
+2.20.1
+
diff --git a/debian/patches/series b/debian/patches/series
index 037ff16..bfe2657 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ geotiff_directory.patch
 link.patch
 OSM_config.patch
 simple_db.patch
+0001-configure.ac-Use-SED_PATH-and-MV_PATH-to-be-able-to-.patch
-- 
2.20.1

From cdc4738e3378848128ea112334e97025daa6bc10 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 14 Dec 2020 02:29:26 +
Subject: [PATCH 2/2] debian/rules: Add dh_auto_configure override to pass
 SED_PATH and MV_PATH.

The path to "sed" and "mv" may vary as either /bin/CMD or /usr/bin/CMD
if the system is configured as a usrmerge system. Use /bin/CMD for the
most compatible location.

https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 8ad983b..7d0a07b 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,3 +7,6 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 
 override_dh_auto_installchangelogs:
 	dh_installchangelogs ChangeLog
+
+override_dh_auto_configure:
+	dh_auto_configure -- SED_PATH=/bin/sed MV_PATH=/bin/mv
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#976788: even more info

[proctor]

i have done a bit more testing. here are some additional notes:

i have found a reliable way to trigger the issue. i am using firefox-esr.
to cause the x-freeze issue, i can play a youtube video. and as it is
playing, i repeatedly move the mouse over the video, and then off of it.
this causes the "play controls" at the bottom of the youtube video to
appear and disappear repeatedly. eventually this triggers the problem. the
mouse pointer gets sluggish, the video starts to stutter and eventually
stops updating all together. the mouse gets very sluggish and after a while
will not move at all. sometimes takes several minutes of moving the mouse
to move 1cm on the screen -- that sort of thing.

during this time the keyboard seems to remain responsive: i can ctrl+alt+f2
into a terminal, and although i cannot see the terminal because the x
screen is frozen still, i can log in as a user, run commands that seem to
execute immediately, and if i hold the backspace key i get repeated rapid
beeps from the computer. this suggests to me that the keyboard and the rest
of the system remains responsive, and only x is hung/frozen.

since i am now able to trigger this issue at will, i have tested several
times where i log in to terminal, run a command, and then reboot with
ctrl+alt+del. i have done this several times now and not triggered the
"unable to log in after screen freeze" issue, so that part of it remains
intermittent -- i am USUALLY able to log in after the x-freeze without
interventions. twice now however i have been unable to until i modified
permissions (ownership) on files in my home directory, as described
previously in this bug report.

-- 
.this message has been rot26 encrypted for security reasons.
gpg 0x385E2954CE572CADE8C091C09479B105A6770473

Bug#975673: fbxkb: diff for NMU version 0.6-2.1

[Sudip Mukherjee]

Control: tags 975673 + patch
Control: tags 975673 + pending
Control: tags 975771 + patch
Control: tags 975771 + pending
--

Dear maintainer,

I've prepared an NMU for fbxkb (versioned as 0.6-2.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should cancel it.

--
Regards
Sudip

diff -Nru fbxkb-0.6/debian/changelog fbxkb-0.6/debian/changelog
--- fbxkb-0.6/debian/changelog  2014-11-05 15:38:59.0 +
+++ fbxkb-0.6/debian/changelog  2020-12-14 20:31:49.0 +
@@ -1,3 +1,11 @@
+fbxkb (0.6-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add dependency on libgdk-pixbuf-xlib-2.0-dev. (Closes: #975673)
+- The dependency also fixes FTBFS with gtk/gtk.h. (Closes: #975771)
+
+ -- Sudip Mukherjee   Mon, 14 Dec 2020 20:31:49 
+
+
 fbxkb (0.6-2) unstable; urgency=low
 
   * New maintainer (Closes: #767970)
diff -Nru fbxkb-0.6/debian/control fbxkb-0.6/debian/control
--- fbxkb-0.6/debian/control2014-11-04 23:53:40.0 +
+++ fbxkb-0.6/debian/control2020-12-14 20:00:07.0 +
@@ -2,7 +2,7 @@
 Section: x11
 Priority: optional
 Maintainer: Dmitry Borisyuk 
-Build-Depends: debhelper (>= 9), libgtk2.0-dev, libxmu-dev
+Build-Depends: debhelper (>= 9), libgtk2.0-dev, libxmu-dev, 
libgdk-pixbuf-xlib-2.0-dev
 Standards-Version: 3.9.6
 Homepage: http://fbxkb.sourceforge.net
 

Bug#975591: insserv/update-rc.d coordination missing

[Thorsten Glaser]

On Mon, 14 Dec 2020, Bob Proulx wrote:

> Some time ago someone made an argument similar to this for conffiles.
> That if a conffile were removed that it was an intentional change.
> Even if accidental.  And then things were changed so that if a
> conffile is removed then that is now considered a local change.  And

That is correct so.

> > Disabling an init script is *not* the same as leaving a K link...
> > because a K link will attempt to stop the service if manually started.
> > This MUST NOT happen.
> 
> Runlevel 6 is the reboot level and all init scripts there are K links.

I did not say 6, but even for 6 there may very well be users of
some dæmon that shall not be terminated by the init script shipped
with that dæmon.

Because initscripts tend to use start-stop-daemon, matching by
invocation path and, i not root, username, this will catch too much.

> Before introducing extraordinary breakage I think it should require
> extraordinary proof for saying why leaving a K link in runlevel 6 is

I did not say 6. It’s there for *all* runlevels. You yourself
showed that.

> > Considering raising severity on this as disabling with update-rc.d remove
> > does not work and disabling with update-rc.d disable wrongly leaves any K

Still considering this.

> The reverse is also true.  The opposite behavior of not installing
> symlinks if there is no configuration will absolutely break my use of

OK, so let’s add a new option for that. I don’t have a problem with
that; I wrote already that either disable gets fixed or a new correctly
working option gets added.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*

Bug#977408: libstdc++-11-doc: missing Conflicts: libstdc++-10-doc

[Andreas Beckmann]

Followup-For: Bug #977408

Add libgccjit-11-doc which misses a Conflicts: libgccjit-10-doc to the list.

There are file conflicts on .png files with very generic names:

usr/share/info/factorial.png
usr/share/info/factorial1.png
usr/share/info/libgccjit.info.gz
usr/share/info/sum-of-squares.png
usr/share/info/sum-of-squares1.png

which could easily lead to clashes with other packages in the future.


Andreas

Bug#975591: insserv/update-rc.d coordination missing (was Re: Canonical method to locally disable an init script?)

[Bob Proulx]

Thorsten Glaser wrote:
> Bob Proulx wrote:
> > root@angst:/etc# find /etc/rc?.d -name '*bind9' -delete
> > root@angst:/etc# find /etc/rc?.d -name '*bind9'
> > 
> > All removed.  The re-install will reset the links to the defaults.
> > 
> > root@angst:/etc# apt-get install --reinstall bind9
> [...]
> > root@angst:/etc# find /etc/rc?.d -name '*bind9'
> > /etc/rc0.d/K04bind9
> > /etc/rc1.d/K04bind9
> > /etc/rc2.d/S03bind9
> > /etc/rc3.d/S03bind9
> > /etc/rc4.d/S03bind9
> > /etc/rc5.d/S03bind9
> > /etc/rc6.d/K04bind9
> 
> Yes, and that MUST NOT happen.

I disagree.  I believe this must happen.  Other possibilities are worse.

> > Removing the S* links instead of disabling them with a K* link.  But
> > leaving the K* links so it is an installed configuration.  Then
> 
> If the local administrator actively disables an init script, e.g. by
> update-rc.d remove, it MUST NOT be re-added later. (This MIGHT require
> insserv and update-rc.d to coordinate on "manually removed" state, but
> this state MUST NOT be the presence of ANY symlinks for that script.)

Some time ago someone made an argument similar to this for conffiles.
That if a conffile were removed that it was an intentional change.
Even if accidental.  And then things were changed so that if a
conffile is removed then that is now considered a local change.  And
that broke a lot of things!  And then DPkg::Options::=--force-confmiss
was needed to fix the introduced breakage.  Required because the
alternative of purging a package and installing fresh to get back a
conffile that had been accidentally deleted was problematic for many
reasons.  And now EVERY TIME I upgrade I MUST ADD --force-confmiss TO
THE COMMAND or it is possible I will not get a correct installation.
And this is a change that hurts the less informed the most.

Whatever results from this discussion please let's not make the cure
worse than the problem!  At a technical level having no configuration
looks identical to not (yet) having installed anything.  Therefore it
makes the most sense that if there is no configuration that when a
package is installed or upgraded that one should be installed and
configured.  That's the principle of least surprise.  Anything else
would require that notice be placed on display in the bottom of a
locked filing cabinet stuck in a disused lavatory with a sign saying
"Beware of the Leopard." and would be a worse problem for the typical
use case.

> Disabling an init script is *not* the same as leaving a K link...
> because a K link will attempt to stop the service if manually started.
> This MUST NOT happen.

Runlevel 6 is the reboot level and all init scripts there are K links.
Before introducing extraordinary breakage I think it should require
extraordinary proof for saying why leaving a K link in runlevel 6 is
so very bad that it is a MUST NOT happen?  Why?  Because I am unable
to think of any case when having a single K link in runlevel 6 is
incompatible with a desire for the init system to get out of the way
of local changes.

> Considering raising severity on this as disabling with update-rc.d remove
> does not work and disabling with update-rc.d disable wrongly leaves any K
> links around which causes unrelated software, that is, a manually started
> service, to be broken, that is, stopped.
> 
> I just had this happen, so it isn't an academic mind exercise.

The reverse is also true.  The opposite behavior of not installing
symlinks if there is no configuration will absolutely break my use of
it, and many others.  And it will change behavior that has been in
place for many years.  And in similarity to your claim I will mirror
it myself and say that it also must not happen.

Cheers! :-)
Bob

Bug#977411: gdm3: gdm does not recognize keyboard input

[Phillip Susi]

Package: gdm3
Version: 3.38.2-1
Severity: important
X-Debbugs-Cc: ph...@thesusis.net

Dear Maintainer,

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

   * What led up to the situation?

After not using it for some time, I fired up my testing VM ( in a Xen DomU )
and ran a dist-upgrade.  Since then ( last week ), I can't log into the gui
because it does not recognize any keyboard input.  libinput-debug from the
xen console recognizes the input, but not gdm3.

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

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


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

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

Versions of packages gdm3 depends on:
ii  accountsservice   0.6.55-3
ii  adduser   3.118
ii  dbus  1.12.20-1
ii  dconf-cli 0.38.0-1
ii  dconf-gsettings-backend   0.38.0-1
ii  debconf [debconf-2.0] 1.5.74
ii  gir1.2-gdm-1.03.38.2-1
ii  gnome-session [x-session-manager] 3.38.0-3
ii  gnome-session-bin 3.38.0-3
ii  gnome-session-common  3.38.0-3
ii  gnome-settings-daemon 3.38.1-2
ii  gnome-shell   3.38.2-1
ii  gnome-terminal [x-terminal-emulator]  3.38.1-2
ii  gsettings-desktop-schemas 3.38.0-2
ii  konsole [x-terminal-emulator] 4:20.08.3-1
ii  kwin-x11 [x-window-manager]   4:5.19.5-3
ii  libaccountsservice0   0.6.55-3
ii  libaudit1 1:2.8.5-3.1+b1
ii  libc6 2.31-5
ii  libcanberra-gtk3-00.30-7
ii  libcanberra0  0.30-7
ii  libgdk-pixbuf2.0-02.40.2-2
ii  libgdm1   3.38.2-1
ii  libglib2.0-0  2.66.3-2
ii  libglib2.0-bin2.66.3-2
ii  libgtk-3-03.24.24-1
ii  libkeyutils1  1.6.1-2
ii  libpam-modules1.3.1-5
ii  libpam-runtime1.3.1-5
ii  libpam-systemd247.1-3
ii  libpam0g  1.3.1-5
ii  librsvg2-common   2.50.2+dfsg-1
ii  libselinux1   3.1-2+b2
ii  libsystemd0   247.1-3
ii  libx11-6  2:1.6.12-1
ii  libxau6   1:1.0.8-1+b2
ii  libxcb1   1.14-2
ii  libxdmcp6 1:1.1.2-3
ii  lsb-base  11.1.0
ii  mutter [x-window-manager] 3.38.2-1
ii  plasma-workspace [x-session-manager]  4:5.19.5-5+b1
ii  policykit-1   0.105-29
ii  procps2:3.3.16-5
ii  ucf   3.0043
ii  x11-common1:7.7+21
ii  x11-xserver-utils 7.7+8
ii  xterm [x-terminal-emulator]   362-1

Versions of packages gdm3 recommends:
ii  at-spi2-core2.38.0-2
ii  desktop-base10.0.3
ii  x11-xkb-utils   7.7+5
ii  xserver-xephyr  2:1.20.10-1
ii  xserver-xorg1:7.7+21
ii  zenity  3.32.0-6

Versions of packages gdm3 suggests:
pn  gnome-orca
pn  libpam-fprintd
ii  libpam-gnome-keyring  3.36.0-1

-- debconf information:
* shared/default-x-display-manager: gdm3
  gdm3/daemon_name: /usr/sbin/gdm3

Bug#977410: rmlint: shell script ignores recheck (-p) result

[Benjamin Kästner]

Package: rmlint
Version: 2.8.0-3
Severity: normal
Tags: patch

Dear Maintainer,

rmlint's shell script template lib/formats/sh.sh contains `original_check', a 
function that checks whether the original has changed when option "-p" is used.

However, the result of the check is discarded, as `original_check's last if 
clause is missing a `return ERR_VAL'. This has been fixed upstream in version 
2.10.1 by b9d328be2041e42813119d060c86893853b8e250.

Here's a simple test scenario:

$ mkdir test && cd test
$ echo hi > hello
$ cp hello world# files are the same
$ rmlint .  # rmlint finds duplicate
$ echo world > world
$ diff hello world
1c1
< hi
---
> world
$ ./rmlint.sh -d -p
$ ls
hello rmlint.json

According to the shell script's documentation and output, -p should keep both 
"hello" and "world". However, after the steps above, "world" is gone. While the 
script's output says its "cancelling", the files are gone for 
good.

Given that this might lead to data loss, I'm not sure whether "normal" is the 
correct severity, but this is my first bug report on Debian. The attached patch 
is the second half of upstream's b9d328be2041e42813119d060c86893853b8e250.

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

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

Versions of packages rmlint depends on:
ii  libblkid1   2.33.1-0.1
ii  libc6   2.28-10
ii  libelf1 0.176-1.1
ii  libglib2.0-02.58.3-2+deb10u2
ii  libjson-glib-1.0-0  1.4.4-2

Versions of packages rmlint recommends:
pn  rmlint-gui  

Versions of packages rmlint suggests:
pn  rmlint-doc  

-- no debconf information
--- a/lib/formats/sh.sh
+++ b/lib/formats/sh.sh
@@ -160,6 +160,7 @@
 else
 if [ "$(check_for_equality "$1" "$2")" -ne "0" ]; then
 echo "${COL_RED}^^ Error: files no longer identical - 
cancelling.${COL_RESET}"
+return 1
 fi
 fi
 }

Bug#977409: libgm2-17: contains only libraries with SOVERSION 15

[Andreas Beckmann]

Package: libgm2-17
Version: 11-20201208-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships 

-rw-r--r-- root/root 31064 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2cor.so.15.0.0
-rw-r--r-- root/root189592 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2iso.so.15.0.0
-rw-r--r-- root/root 56168 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2log.so.15.0.0
-rw-r--r-- root/root 13968 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2min.so.15.0.0
-rw-r--r-- root/root172720 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2pim.so.15.0.0
lrwxrwxrwx root/root 0 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2cor.so.15 -> libm2cor.so.15.0.0
lrwxrwxrwx root/root 0 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2iso.so.15 -> libm2iso.so.15.0.0
lrwxrwxrwx root/root 0 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2log.so.15 -> libm2log.so.15.0.0
lrwxrwxrwx root/root 0 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2min.so.15 -> libm2min.so.15.0.0
lrwxrwxrwx root/root 0 2020-12-08 14:08 
./usr/lib/x86_64-linux-gnu/libm2pim.so.15 -> libm2pim.so.15.0.0

which is inconsistent with being renamed to libgm2-17.
It also causes file conflicts with libgm2-15 in sid.


Andreas

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Sean Whitton]

Hello,

On Mon 14 Dec 2020 at 09:35AM -05, Dave Steele wrote:

> Update. No todo, and suggest the following for todo.txt text:
>
> command-line task management utility compatible with todo.txt CLI (
> http://todotxt.org)

Could you provide an actual patch against policy.git, please, for
seconding?  See README.md in policy.git for more info.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#922744: don't compress debug sections by default

[Sean Whitton]

Hello Matthias,

On Wed 20 Feb 2019 at 09:34AM +01, Matthias Klose wrote:

> Package: debhelper
> Version: 12.1
> Severity: important
> Tags: sid buster
>
> afaics this change was made in
>
> debhelper (9.20150811) unstable; urgency=medium
>
>   * dh_strip: Always compress debug sections of debug symbols
> in ddebs.
>
> What was the reason for enabling this?  The only savings I can see is some
> on-disk space savings when doing the debugging.  The packages itself are
> compressed anyway.  Otoh there are still tools outside which cannot handle
> compressed debug sections, and Debian seems to be the only distro turning on
> these compressions by default.  Just stumbled about that when looking at a
> binutils issue which fixes the alignment for compressed debug sections (PR
> binutils/23919.

Could you substantiate the concern about tooling issues, please?

On the other side of this dispute, in #631985, there is a concrete
example of how someone's life is made easier by having the compression
turned on, but on the other side things are less substantiated.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#976402: Proposed official virtual packages - todo and todo.txt

[Sean Whitton]

control: tag -1 + moreinfo

Hello David,

On Fri 04 Dec 2020 at 12:15PM -05, David Steele wrote:

> I'd like to propose adding the virtual packages "todo" and "todo.txt" to
> the authoritative list of virtual package names. I'm submitting this per
> Policy section 3.6 and the preamble to the [authoritative list].
>
> [Todo.txt] describes an ecosystem of task management tools that revolve
> around a standard for a freeform-text tasking file.
>
> The reference cli has been packaged for some time, as "todotxt-cli". It
> provides the executable "todo-txt".
>
> An alternative cli provider, "topydo", has been recently added, adding
> an executable by the same name.
>
> I propose uniting this packages using the name "todo" - the common name
> for the utility. Since not all todo list packages that may want to share
> that name conform to the todo.txt standards, I also propose "todo.txt",
> a strict subset of "todo", for packages which conform.

Putting aside the use of the alternatives system, why is a virtual
package wanted?  When would it be useful to be able to declare a
dependency and have it satisfied by one of these implementations?

So far this does not seem anything like, e.g., wanting to declare a
dependency on having the ability to programmatically send e-mail.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#977350: certbot: Version in Debian Stable gets certificates by R3 issuer which might fail to validate

[Brad Warren]

Hi,

Upstream Certbot maintainer here.

It looks like these logs have been modified, removing things like the server 
responses which would have included things like certificate chain obtained from 
Let’s Encrypt or the reason Certbot “exited abnormally”. I doubt the latter is 
related to this problem and is instead related to the renewal failure for your 
other certificate, but you never know. Can you verify that the remainder of the 
log file is about the certificate for dida.ibsquare.be?

Also, can you provide the output of the following command (or these 4 files 
directly)?

sudo tail -n +1 /etc/letsencrypt/archive/nrgcoin.org/{fullchain,chain}{5,6}.pem

Thanks,
Brad Warren

Bug#976462: tech-ctte: Should dbgsym files be compressed via objcopy --compress-debug-section or not?

[Sean Whitton]

Hello Niels,

On Sat 05 Dec 2020 at 01:12PM +01, Niels Thykier wrote:

> The underlying arguments for and against --compress-debug-section appear
>  to be "download size" vs. "installed disk usage" vs. "Tooling support".
>  Though I ask you to please read the bugs #631985 and #922744 for the
> details of the arguments by both proponents.

Just had a look a these, thank you.

ISTM that the arguments in favour of compressing are more concrete right
now: in #631985 there is the example of debugging KDE requiring more
than 10G of disc space.  (Nine years later perhaps it is more.)  On the
other hand, in #922744, there is only an unsubstantiated reference to
tooling support.

I'm going to write to the submitter of #922744 asking for more info.

> Why punt it to you?
> ===
>
> [...]

I think the reasons you give are all reasonable.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#977219: diff NMU for anytun_0.3.7-1.3

[Anton Gladky]

tags 977219 +pending +patch
user team+bo...@tracker.debian.org
usertag 977219 +boost174
thanks

Dear maintainer,

I have prepared an NMU (versioned as 0.3.7-1.3) and
uploaded to DELAYED/5.

Please feel free to tell me if I should delay it longer, cancel
or reschedule.

Diff is attached.

Best regards

Anton


nmu.debdiff
Description: Binary data

Bug#900821: workaround confirmed

[Florian Kain]

Hi all,

we were experiencing this bug in a debian 10.4 docker container (FROM 
php:apache)
it only happens with plain http not with https.

I can confirm that workaround from  Stefan Fritsch  by 
turning EnableMMAP off is working for us!

Cheers,
Florian

Bug#975381: Subject: libinih: drop Debian's custom vendorisation

[Sean Whitton]

control: tag -1 + moreinfo

Dear Stephan,

On Sat 21 Nov 2020 at 12:20PM GMT, Stephan Lachnit wrote:

> Currently the package libinih uses some heavy patches, which aren't upstream
> and aren't used by any other distro. I'm in favor of dropping this, but the
> current maintainer disagrees and we weren't able to make any progess in the
> discussion, so I want to put this here. Parts of the discussion can be found 
> on
> this MR: https://salsa.debian.org/yangfl-guest/inih/-/merge_requests/2
>
> To understand this, one has to look a bit at the history behind inih. Upstream
> was designed as a static library for embedded devices, and therefore has a lot
> of compile time options. At this point, the current maintainer created a patch
> to make all compile time option available on runtime.
>
> When gamemode started using inih, I wanted to get rid of shipped inih code and
> upstreamed a build system to inih for a shared library, that any distro can
> use. This was done in version 48. Due to the popularity of gamemode, inih is
> now found in most major distros (all without Debian's patches):
> https://repology.org/project/inih/versions
>
> There is a notable "exception": inih is not in Ubuntu's main repository. This
> is a bit weird because gamemode is in main, but with the shipped inih source
> which got dropped from 1.6, meaning gamemode is stuck on 1.5.1 on Ubuntu. I'm
> not sure why, but I suspect the heavy patches make it harder to be included in
> main.
>
> Because the library was designed for embedded use cases where every little bit
> of performance matters, the runtime patch was refused upstream. Dropping the
> runtime patch from Debian actually isn't problem, no reverse dependency of
> libinih uses compile time options anyway. However, due to the history of inih
> in Debian is has the soversion 1, while upstream is soversion 0.
>
> I want to drop the vendorisation of Debian and start a transition to soversion
> 0 (which is also a reason I contact the Technical Committee, as it's not clear
> how this would be done). A transition is needed anyway since dropping the 
> patch
> is a breaking change anyway. If the Technical Committee agrees to this, I 
> would
> also gladly help to maintain this package since it is 2 version behind 
> upstream
> since almost half a year and I maintain gamemode, which is directly affected 
> by
> this.

Your message it not clear enough for TC members not familiar with the
packages in question to understand what the dispute is.  We cannot wade
through discussions on salsa -- we need a summary.

Please make another attempt at summarising the dispute.  Please also
indicate which of the TC's powers (as granted by the constitution) you
are asking us to make use of.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature