Bug#961696: mccs FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: mccs
Version: 1:1.1-8
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mccs fails to cross build from source, because the upstream makefile
uses a non-standard compiler variable that debhelper doesn't know how to
substitute. The CCC variable in mccs is not just used for the compiler,
but also includes flags. It defaults to using g++. Please consider using
CXX there such that the standard variable can be used to replace the
compiler without discarding flags. Doing so makes mccs cross buildable.
Please consider applying the attached patch.

Helmut
--- mccs-1.1.orig/make.local
+++ mccs-1.1/make.local
@@ -108,6 +108,6 @@
 INC=-I$(OBJDIR) -I$(SRCDIR) -I$(SRCLIB)
 #CCCOPT=-g -Wall
 CCCOPT=-Wall -O6
-CCC=g++ $(CCCOPT) $(LDFLAGS)
+CCC=$(CXX) $(CCCOPT) $(LDFLAGS)
 
 

Bug#961695: minissdpd: could start before miniupnpd

[Ryutaroh Matsumoto]

Package: minissdpd
Version: 1.5.20190210-1+b1
Severity: minor
Tags: patch

Dear Maintainer,

apt-cache show minissdpd says

 Just make sure that MiniSSDPd is started before
 any other UPnP program on the computer.

But systemctl list-dependencies --before minissdpd does not include
miniupnpd. I suggest the following content to the systemd service file:

[Unit]
Before=miniupnpd.service

Best regards, Ryutaroh Matsumoto

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja_JP.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 minissdpd depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  init-system-helpers1.57
ii  libc6  2.30-8
ii  libnfnetlink0  1.0.1-3+b1
ii  lsb-base   11.1.0

minissdpd recommends no packages.

minissdpd suggests no packages.

-- debconf information:
* minissdpd/listen: 192.168.1.2
* minissdpd/ip6: false
  minissdpd/why_I_am_here:
* minissdpd/start_daemon: true

Bug#961694: libnitrokey: Merge request in Salsa for Librem Key patches to libnitrokey

[Jeremiah C. Foster]

Source: libnitrokey
Version: 3.5.*
Severity: normal
Tags: upstream

Dear Maintainer,

I've provided a merge request of some changes made to libnitrokey's
source code from upstream. While the patches have not yet been applied
to the upstream source code, we've found the changes suitable for
PureOS, a Debian derivative. Hopefully you'll find the cherry-picked
patch suitable.

https://salsa.debian.org/kitterman/libnitrokey/-/merge_requests/3

Many thanks for all your work.

Regards,

Jeremiah

-- System Information:
Distributor ID: PureOS
Description:PureOS
Release:10.0
Codename:   byzantium
Architecture: x86_64

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

Bug#961693: ITP: r-cran-gmp -- Multiple Precision Arithmetic

[Rodrigo Carvalho]

Package: wnpp
Severity: wishlist
Owner: Rodrigo Carvalho 

* Package name: r-cran-gmp
  Version : 0.5-14
  Upstream Author : Antoine Lucas, Immanuel Scholz, Rainer Boehme,
Sylvain Jasson, Martin Maechler
* URL : https://cran.r-project.org/package=gmp
* License : GPL-2 | GPL-3
  Programming Lang: R and C++
  Description : Multiple Precision Arithmetic

Multiple Precision Arithmetic (big integers and rationals,
 prime number tests, matrix computation), "arithmetic without limitations"
 using the C library GMP (GNU Multiple Precision Arithmetic).

It will be maintained by R Packages Team

Bug#933071: RFS: ibus-keymagic/1.4-1~exp1 [ITP] -- keymagic engine for IBus

[Ko Ko Ye`]

Dear mentors,

I am looking for a sponsor for my package "ibus-keymagic"

 * Package name: ibus-keymagic
   Version : 1.4-1~exp1
   Upstream Author : kokoye2007 
 * URL : https://keymagic.net
 * License : GPL-2.0+
 * Vcs : https://salsa.debian.orgr/kokoye2007-guest/ibus-keymagic
   Section : utils

It builds those binary packages:

  ibus-keymagic - keymagic engine for IBus
  ibus-keymagic-ayar-phonetic - ibus keymagic ayar-phonetic;
  ibus-keymagic-beolssalba - ibus keymagic beolssalba;
  ibus-keymagic-cessalba - ibus keymagic cessalba;
  ibus-keymagic-ddeolssalba - ibus keymagic ddeolssalba;
  ibus-keymagic-gugeolssalba - ibus keymagic gugeolssalba;
  ibus-keymagic-khmer-nida - ibus keymagic khmer-nida;
  ibus-keymagic-loringian-miu - ibus keymagic loringian-miu;
  ibus-keymagic-malayalam-inscript - ibus keymagic malayalam-inscript;
  ibus-keymagic-malayalam-mozhi - ibus keymagic malayalam-mozhi;
  ibus-keymagic-meolssalba - ibus keymagic meolssalba;
  ibus-keymagic-mon-anonta - ibus keymagic mon-anonta;
  ibus-keymagic-monbur - ibus keymagic monbur;
  ibus-keymagic-mon - ibus keymagic mon;
  ibus-keymagic-myanmar3 - ibus keymagic Myanmar3;
  ibus-keymagic-myanmar3x - ibus keymagic Myanmar3x;
  ibus-keymagic-myansan - ibus keymagic myansan;
  ibus-keymagic-mywin - ibus keymagic mywin;
  ibus-keymagic-ou-khamti - ibus keymagic ou-khamti;
  ibus-keymagic-ou-mon - ibus keymagic ou-mon;
  ibus-keymagic-ou-myanmar - ibus keymagic ou-Myanmar;
  ibus-keymagic-ou-palaung - ibus keymagic ou-palaung;
  ibus-keymagic-ou-pao - ibus keymagic ou-pao;
  ibus-keymagic-ou-shan - ibus keymagic ou-shan;
  ibus-keymagic-ou-taile - ibus keymagic ou-taile;
  ibus-keymagic-ou-taitham - ibus keymagic ou-taitham;
  ibus-keymagic-panglongshan - ibus keymagic panglongshan;
  ibus-keymagic-paoh - ibus keymagic paoh;
  ibus-keymagic-parabaik - ibus keymagic parabaik;
  ibus-keymagic-sunssalba - ibus keymagic sunssalba;
  ibus-keymagic-unimon - ibus keymagic unimon;
  ibus-keymagic-yunghkio - ibus keymagic yunghkio;
  ibus-keymagic-zawgyi - ibus keymagic zawgyi;
  ibus-keymagic-zawgyinonsmart - ibus keymagic zawgyinonsmart;
  ibus-keymagic-zawgyitai - ibus keymagic zawgyitai;
  ibus-keymagic-zawgyiunicode - ibus keymagic zawgyiunicode;
  ibus-keymagic-zgunicode - ibus keymagic zgunicode;
  ibus-keymagic-pyidaungsu - ibus keymagic pyidaungsu;

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

  https://mentors.debian.net/package/ibus-keymagic

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

  dget -x 
https://mentors.debian.net/debian/pool/main/i/ibus-keymagic/ibus-keymagic_1.4-1~exp1.dsc

Changes since the last upload:

   * fix gpg key and uscan watch file.
   * lintian check is clean.
   * Closes: #933071.

Regards,

--
  kokoye2007

-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#933071: update

[Ko Ko Ye`]

we change

debhelper-compact 13
repo github to salsa
debian/rules for bullseye  rules
update metadata


who can test and sponsor for me.

https://mentors.debian.net/package/ibus-keymagic

https://mentors.debian.net/debian/pool/main/i/ibus-keymagic/ibus-keymagic_1.4-1~exp1.dsc
-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#961692: Fonts are outdated

[Yoon Khe]

Source: fonts-cns11643
Severity: normal

The packages fonts-cns11643-kai; fonts-cns11643-sung; and 
fonts-cns11643-pixmaps were last updated in October 2018. New versions of these 
fonts have been released since, most recently in May 2020 
(https://data.gov.tw/dataset/5961).

Bug#961635: uploaded package

[Roland Plüss]

Uploaded the package to mentors as requested:

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

-- 
Mit freundlichen Grüssen
Plüss Roland

Game Development and Game Engine Technologies https://dragondreams.ch



signature.asc
Description: OpenPGP digital signature

Bug#903827: probably not fixed Re: Bug#903827

[Rebecca N. Palmer]

Control: reassign -1 src:llvm-toolchain-10
Control: reopen -1

Probably still exists, though pocl no longer appears affected:

$ strings /usr/lib/x86_64-linux-gnu/libMesaOpenCL.so.1 | grep "/clang/"
/usr/lib/llvm-10/lib/clang/10.0.0/include
$ strings /usr/lib/x86_64-linux-gnu/libpocl.so.2.5.0 | grep "/clang/"
/usr/lib/llvm-9/include/clang/Frontend/CompilerInstance.h
$ clang --print-resource-dir
/usr/lib/llvm-9/lib/clang/9.0.1
$ clang-10 --print-resource-dir
/usr/lib/llvm-10/lib/clang/10.0.0

Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel

[YunQiang Su]

Adrian Bunk  于2020年5月21日周四 下午3:40写道：
>
> On Thu, May 21, 2020 at 06:41:34AM +0800, YunQiang Su wrote:
> > Adrian Bunk  于2020年5月21日周四 上午4:44写道：
> > >
> > > On Tue, May 19, 2020 at 11:43:30AM +0800, Shengjing Zhu wrote:
> > > >
> > > > FTR, after giving back golang-1.14 mipsel several times, it's finally
> > > > built, by a longson builder.
> > > > So I guess it only occurs on octeon. Since the porterbox eller is also
> > > > octeon, it also can't build any go program.
> > >
> > > On eller golang-1.14 fails to build both in sid and buster chroots.
> > >
> > > golang-1.11 also fails to build in a buster chroot with floating point
> > > test errors.
> > >
> > > golang-1.14 gets unbroken by GOMIPS=softfloat.
> > >
> > > The only kernel configuration change on eller in the buster point
> > > release is CONFIG_MIPS_O32_FP64_SUPPORT=y, everything observed would
> > > make sense if the problem is that golang-1.11 and golang-1.14 are
> > > not compatible with CONFIG_MIPS_O32_FP64_SUPPORT.
> >
> > It is just support O32_FP64. I don't expect it will have any effect.
> > Since currently, the toolchain/libraries are all FPXX.
>
> Only the gcc/binutils toolchain/libraries or also the Go toolchain?

you are right. the current golang still output FP32 object...
So, we think that it is buggy.

Since Loongson CPU has some strange behaviour, it even can work...
Let's try to patch golang to support FPXX or FP64.

https://github.com/golang/go/issues/39289

>
> Go has its own compiler.
> Go has its own linker.
>
> You do not need binutils installed for building Go programs.
>
> cu
> Adrian

Bug#961691: linux-image-5.6.0-1-amd64: System hangs all the time

[Igor Liferenko]

Package: src:linux
Version: 5.6.7-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since upgrade of 2020-05-18 system started to hang all the time without any 
reason,
forcing me to reboot computer each time loosing my work.

-- Package-specific info:
** Version:
Linux version 5.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 
(Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.6.0-1-amd64 
root=UUID=284f2b06-aeb5-4d51-bffe-ddb426f4c63f ro

** Not tainted

** Kernel log:
[   10.387864] systemd[1]: Mounted Huge Pages File System.
[   10.390388] systemd[1]: Mounted POSIX Message Queue File System.
[   10.394777] systemd[1]: Mounted Kernel Debug File System.
[   10.399670] systemd[1]: Mounted Kernel Trace File System.
[   10.404568] systemd[1]: Finished Create list of static device nodes for the 
current kernel.
[   10.427001] RPC: Registered named UNIX socket transport module.
[   10.429045] RPC: Registered udp transport module.
[   10.431114] RPC: Registered tcp transport module.
[   10.433100] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   10.437145] systemd[1]: Mounted RPC Pipe File System.
[   10.440980] systemd[1]: Starting pNFS block layout mapping daemon...
[   10.487925] systemd[1]: Finished Load Kernel Modules.
[   10.490130] systemd[1]: Condition check resulted in FUSE Control File System 
being skipped.
[   10.490243] systemd[1]: Condition check resulted in Kernel Configuration 
File System being skipped.
[   10.493417] systemd[1]: Starting Apply Kernel Variables...
[   10.516173] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro
[   10.522665] systemd[1]: Finished Remount Root and Kernel File Systems.
[   10.525011] systemd[1]: Started pNFS block layout mapping daemon.
[   10.646829] systemd[1]: Condition check resulted in Rebuild Hardware 
Database being skipped.
[   10.648586] systemd[1]: Condition check resulted in Platform Persistent 
Storage Archival being skipped.
[   10.651696] systemd[1]: Starting Load/Save Random Seed...
[   10.655199] systemd[1]: Starting Create System Users...
[   10.779957] systemd[1]: Finished udev Coldplug all Devices.
[   10.816807] systemd[1]: Starting Helper to synchronize boot up for 
ifupdown...
[   10.828057] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[   10.831924] systemd[1]: Mounted NFSD configuration filesystem.
[   10.860106] systemd[1]: Finished Apply Kernel Variables.
[   10.930500] systemd[1]: Finished Load/Save Random Seed.
[   11.041107] systemd[1]: Finished Set the console keyboard layout.
[   11.050969] systemd[1]: Finished Create System Users.
[   11.056564] systemd[1]: Starting Create Static Device Nodes in /dev...
[   11.090135] systemd[1]: Started Journal Service.
[   11.119693] systemd-journald[258]: Received client request to flush runtime 
journal.
[   11.379257] systemd-journald[258]: File 
/var/log/journal/a7cfea2033ec4c4182a6354cbc46c69c/system.journal corrupted or 
uncleanly shut down, renaming and replacing.
[   13.136231] parport_pc 00:03: reported by Plug and Play ACPI
[   13.137946] parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
[   13.377785] sd 1:0:0:0: Attached scsi generic sg0 type 0
[   13.516053] ppdev: user-space parallel port driver
[   13.556030] iTCO_vendor_support: vendor-support=0
[   13.645501] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[   13.647259] iTCO_wdt: Found a ICH10 TCO device (Version=2, TCOBASE=0x0860)
[   13.649190] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[   14.563063] intel_powerclamp: No package C-state available
[   14.605586] intel_powerclamp: No package C-state available
[   14.641855] intel_powerclamp: No package C-state available
[   14.680160] intel_powerclamp: No package C-state available
[   15.115708] snd_hda_codec_via hdaudioC0D0: autoconfig for VT1708S: 
line_outs=4 (0x1c/0x19/0x22/0x23/0x0) type:line
[   15.117461] snd_hda_codec_via hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   15.119133] snd_hda_codec_via hdaudioC0D0:hp_outs=1 
(0x1d/0x0/0x0/0x0/0x0)
[   15.120838] snd_hda_codec_via hdaudioC0D0:mono: mono_out=0x0
[   15.122623] snd_hda_codec_via hdaudioC0D0:dig-out=0x20/0x0
[   15.124284] snd_hda_codec_via hdaudioC0D0:inputs:
[   15.125939] snd_hda_codec_via hdaudioC0D0:  Rear Mic=0x1a
[   15.127550] snd_hda_codec_via hdaudioC0D0:  Front Mic=0x1e
[   15.129180] snd_hda_codec_via hdaudioC0D0:  Line=0x1b
[   15.130763] snd_hda_codec_via hdaudioC0D0:  CD=0x1f
[   15.132384] Adding 2539516k swap on /dev/sda2.  Priority:-2 extents:1 
across:2539516k FS
[   15.148279] input: HDA Intel Rear Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input8
[   15.150830] input: HDA Intel Front Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input9
[   15.153555] input: HDA Intel Line as 
/devices/pci:00/:00:1b.0/sound/card0/input10
[   15.156024] input: HDA Intel Line Out Front as 

Bug#961690: [PATCH] Use mktemp(1) instead of tempfile(1) in lessfile

[Aaron Schrab]

tags 961690 patch
thanks

--- 8< --

From: Aaron Schrab 
Date: Wed, 27 May 2020 19:30:14 -0400
Subject: [PATCH] Use mktemp(1) instead of tempfile(1) in lessfile

As of version 4.10 of the debianutils package, tempfile(1) issues a
run-time deprecation warning. Switch to mktemp(1) to avoid this.
---
 debian/lesspipe | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/lesspipe b/debian/lesspipe
index a74459f..f36ee3b 100644
--- a/debian/lesspipe
+++ b/debian/lesspipe
@@ -48,7 +48,7 @@ if [ $# -eq 1 ] ; then
# generate filename for possible use by lesspipe
umask 077
if [ $BASENAME = $LESSFILE ]; then
-   TMPFILE=`tempfile -d $TMPDIR -p lessf`
+   TMPFILE=$(mktemp "${TMPDIR}/lessfXX")
if [ -z "$TMPFILE" ]; then
echo >&2 "Could not find essential program 'tempfile'. 
Exiting"
   exit 1
--
2.27.0.rc2

Bug#961689: orville-write: please remove alternatives usage for write(1)

[Chris Hofstaedtler]

Package: orville-write
Version: 2.55-3
Severity: important

orville-write uses alternatives to ship a variant of write(1). For
similar reasons, it also diverts mesg(1).

write(1) will move from src:bsdmainutils to src:util-linux, and
orville-write is the only other package supplying a write
implementation, with a different feature set, and unclear compatibility.

Please stop using alternatives, and also implement diverting write,
like its done already for mesg. The new binary package in src:util-linux
will probably get a Breaks/Conflicts: relationship to orville-write (<<
2.55-4~) in the hope that this will be fixed.

Thanks,
Chris

Bug#961690: less: Using lessfile and latest debianutils results in a deprecation warning

[Aaron Schrab]

Package: less
Version: 551-1
Severity: normal

Dear Maintainer,

After updating my system today I started seeing the following warning 
when running `less` with LESSOPEN="/usr/bin/lessfile %s":

WARNING: tempfile is deprecated; consider using mktemp instead.

It looks like this is due to a change in debianutils 4.10:

debianutils (4.10) unstable; urgency=medium

  * installkernel: stay in /sbin. closes: #961476.
  * tempfile: add run-time deprecation warning.

 -- Clint Adams   Sun, 24 May 2020 19:40:59 -0400


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

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

Versions of packages less depends on:
ii  libc6  2.30-8
ii  libtinfo6  6.2-1

less recommends no packages.

less suggests no packages.

-- no debconf information

Bug#961688: RM: orville-write -- RoQA; not useful anymore

[Chris Hofstaedtler]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

#917571 removed xtell (RoM), stating that instant messaging is done
differently today. I agree, and the same is true for orville-write.

Also, orville-write appears to FTBFS with gcc-10 (#957648), and also
diverts mesg(1), and relies on alternatives for write(1). xtell used
this alternatives system too, and obviously bsdmainutils ships the
default implementation. Now, write(1) wants to move to src:util-linux,
and if I don't have to keep the alternatives stuff alive for this, I'd
be a lot happier.

Thanks,
an obviously biased Chris

Bug#960390: x86_64: No serial port output

[Punit Agrawal]

On Tue, 26 May 2020 12:20:04 +0100 Steve McIntyre  wrote:
> On Sat, May 23, 2020 at 10:34:36AM +0900, Punit Agrawal wrote:
> >On Sat, May 23, 2020 at 1:54 AM Steve McIntyre  wrote:
> >>
> >> On Sat, May 23, 2020 at 01:15:37AM +0900, Punit Agrawal wrote:
> >
> >[...]
> >
> >> >To avoid needing any workarounds such as those discussed in earlier
> >> >replies, I looked at enabling the installer images to output on the
> >> >serial console by default. The attached simple change to the grub
> >> >configuration gives output on serial as well as connected monitor.
> >> >
> >> >The next issue that needs fixing is to update the kernel command line
> >> >to launch the installer on the serial console.
> >>
> >> I think few people have been bothered by this in the past - all the
> >> server machines I've used for years have had options for redirecting a
> >> VGA console to the serial port. Do you have one that doesn't?
> >
> >Actually, I was installing in "-nographic" VM rather than a server.
> >There are workarounds that allow me to continue earlier in the thread
> >(See #67, #68) but I was hoping to improve things so that it just
> >works.
> >
> >I was just surprised that it isn't possible to use the installer
> >without a VGA monitor (or a redirect on hardware that supports it) -
> >especially coming from arm64. There are a few other use cases that
> >will benefit from the serial support as well.
> >
> >Considering that it looks to be a configuration issue - do you think
> >it's worth enabling? Are there any downsides that I am missing?
>
> Possibly? I spent half an hour looking at things last week, but I
> don't have the time to look at this properly for a while myself. Other
> priorities...

Thanks for taking a look. Appreciate your comments.
>From looking at your feedback below, it seems (as of now) the issue
regarding enabling serial output in d-i grub is -

1. Feasibility (and the required changes)
2. While, not degrading behaviour for existing users

I completely agree and have tried to figure out 1. without regressing
existing other use cases.

> >From your patch, I'm not sure:
>
>  a) you're unconditionally replacing colour choices

This is needed to enable text based grub menu on the serial console.
The display still shows the fancy image based splash / graphical
looking menu from before.

>  b) you're setting up terminal_output only, what about terminal_input?
> (as mentioned in the info pages)
>  c) do you need to have a "serial" command to enable serial ports
> (again, from the info page)?

I had both "serial --unit=0" and "terminal_input console gfxterm" in
an earlier local version of the patch (following the documentation).
But they got dropped in a bid to minimise the changes that add the
missing feature. I am not entirely sure why things work without both
of these to be honest.

But thinking back, it's best to stick to documented use to future
proof against grub updates. I will update the patch adding these back.

>  d) is there any downside on machines without serial?

I did not notice any downsides to the normal (display connected) use
case in my testing.
I tested the following combination of display and serial using Qemu

i. Display only (no serial option passed to Qemu)
ii. Display and Serial connected ("-serial mon:stdio")
iii. Serial only ("-nographic -serial mon:stdio")

I'll post an updated patch (likely later today), adding the left out
configuration ("serial" and "terminal_input").
If it passes initial testing, we should consider merging into nightly
builds to get wider feedback and be quick to revert in case of
regression.

Bug#951565: freerdp2-x11: does not work at all, immediately exits, against xrdp server (rdesktop works)

[Mike Gabriel]

Control: close -1

Hi,

On  Fr 21 Feb 2020 20:47:57 CET, Mike Gabriel wrote:


Hi Thorsten, hi Bernhard,

On  Fr 21 Feb 2020 12:01:14 CET, Bernhard Miklautz wrote:


Hi Thorsten,

On Tue, Feb 18, 2020 at 07:18:23AM +0100, Thorsten Glaser wrote:

tglase@tglase-nb:~ $ xfreerdp /v:tglase-edge
..
[07:15:08:628] [29233:29234] [INFO][com.winpr.clipboard] -  
initialized POSIX local file subsystem
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.update] -  
[0x03] Cache Glyph - SERVER BUG: The support for this feature was  
not announced! Use /relax-order-checks to ignore
[07:15:08:745] [29233:29234] [INFO][com.freerdp.client.common] -  
Network disconnect!
[07:15:08:745] [29233:29234] [ERROR][com.freerdp.client.x11] -  
Failed to check FreeRDP file descriptor

..

I also tried xfreerdp /size:1000x768 /v:tglase-edge but that
does not change anything.

FreeRDP does strict protocol level checks per default since a while.
xrdp does use the glyph cache without announcing/negotiating it - this
causes xfreerdp to close the connection.

Give the options /relax-order-checks (as the error above
indicates) and +glyph-cache a try.

As reference also See:

https://github.com/neutrinolabs/xrdp/issues/1229 and
https://github.com/neutrinolabs/xrdp/issues/1266

Best regards,
Bernhard


Bernhard, thanks for your answer on this.

Thorsten, shall we close or reassign to xRDP?

:-P

Mike


Closing this manually. No feedback from bug submitter. Not a bug in freerdp2.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpE4q7LTR7UJ.pgp
Description: Digitale PGP-Signatur

Bug#961683: dgit-maint-debrebase(7): Drop bad advice about upstream/ tag case

[Ian Jackson]

Sean Whitton writes ("Bug#961683: dgit-maint-debrebase(7): Drop bad advice 
about upstream/ tag case"):
> Package: dgit
> Version: 9.10
> Tags: patch

Acked-by: Ian Jackson 

Bug#961682: Dgit::upstream_commitish_search(): should fail if more than one tag found

[Ian Jackson]

Sean Whitton writes ("Bug#961682: Dgit::upstream_commitish_search(): should 
fail if more than one tag found"):
> Package: dgit
> Version: 9.10
> Severity: important
> X-debbugs-cc: brem...@debian.org

> Attached is a minimal fix.

Reviewed-by: Ian Jackson 

Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

[Dirk Eddelbuettel]

Paul,

Shall I close this one 'by hand'?  Or will it get closed by migrating
quantlib-swig?  I just close the other one (#956830) that was at the start of
this by hand.

Best,  Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#948087: future of aufs in Debian.

[Tianon Gravi]

On Wed, 27 May 2020 at 14:33, Noah Meyerhans  wrote:
> Docker no longer users aufs by default, though, having switched to
> overlayfs some time ago.  I'm sure we could get them to drop the
> Recommends if we're considering getting rid of it.

This is something I'd been considering for quite a while now and
hadn't gotten around to, so thanks for the push!  I've filed [1] now.
:)

[1]: https://github.com/docker/docker-ce-packaging/pull/472

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#961687: adwaita-icon-theme: speaker icon to increase and decrease volume does not work correctly sometimes

[igormuzetti]

Package: adwaita-icon-theme
Version: 3.30.1-1
Severity: normal
Tags: a11y

Dear Maintainer,

   * What led up to the situation?
Increase and decrease volume using the mouse.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Sometimes when I click on the speaker and try to slide  the sound or microphone
slider, the slider does not follow the mouse and the action is compromised
   * What was the outcome of this action?
I can't change the volume and the slider bridge doesn't move.
   * What outcome did you expect instead?
That the volume of the sound was changed and that the pointer of the slider
followed the movement of the mouse.



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

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

Versions of packages adwaita-icon-theme depends on:
ii  gtk-update-icon-cache  3.24.5-1
ii  hicolor-icon-theme 0.17-2
ii  librsvg2-common2.44.10-2.1

adwaita-icon-theme recommends no packages.

adwaita-icon-theme suggests no packages.

-- no debconf information

Bug#959768: [PATCH] initramfs-tools/hook-functions: Fix libgcc_s.so.1 dependency

[Helge Deller]

Due to Debian bug #950254 the hook-functions copies libgcc_s.so.1 into
the initramfs image. But this breaks architectures which ship other
versions of libgcc_s, e.g. hppa (libgcc_s.so.4) or m68k (libgcc_s.so.2).

Fix it by searching the relevant libgcc_so files.
The fix is modelled after the btrfs hook functions in
/usr/share/initramfs-tools/hooks/btrfs.

Tested on hppa.

Signed-off-by: Helge Deller 
Noticed-by: John Paul Adrian Glaubitz 
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959768
Fixes: f2ac13e8881f ("hook-functions: copy_exec: Copy libgcc_s.so.0 along with 
libpthread.so")


diff -up ./hook-functions.org ./hook-functions
--- ./hook-functions.org2020-05-27 21:57:26.994595173 +
+++ ./hook-functions2020-05-27 21:57:30.182574623 +
@@ -182,7 +182,7 @@ copy_file() {
 # Location of the image dir is assumed to be $DESTDIR
 # We never overwrite the target if it exists.
 copy_exec() {
-   local src target x nonoptlib ret
+   local src target x nonoptlib ret libgcc

src="${1}"
target="${2:-$1}"
@@ -209,7 +209,10 @@ copy_exec() {
# Handle common dlopen() dependency (Debian bug #950254)
case "${x}" in
*/libpthread.so.*)
-   copy_exec "${x%/*}/libgcc_s.so.1" || return
+   LIBC_DIR=$(dirname "${x}")
+   find -L "$LIBC_DIR" -maxdepth 1 -name 'libgcc_s.*' 
-type f | while read -r libgcc; do
+   copy_exec "${libgcc}" || return
+   done
;;
esac

Bug#940965: apt: Fails to find a solution for libgtk-3-0 and sysvinit-core

[Sean Whitton]

Hello,

On Sun 22 Sep 2019 at 08:04PM +02, Simon Richter wrote:

> apt's resolver does not find a working solution for installing both
> libgtk-3-0 and sysvinit-core, or for installing libgtk-3-0 when
> systemd-sysv has a negative score in preferences. Aptitude resolves both of
> these by favouring dbus-x11 over dbus-user-session.
>
> When presented manually with this solution, apt accepts it as valid.

The problematic dependency chain is this:

libgtk-3-0 -> libgtk-3-common -> dconf-gsettings-backend -> dconf-service ->
  default-dbus-session-bus | dbus-session-bus

dbus-x11 Provides: dbus-session-bus, but apt prefers to replace
sysvinit-core with systemd rather than just install dbus-x11.

One way to reproduce this problem, in buster or sid:
1) clean chroot
2) apt-get install sysvinit-core
3) apt-get install emacs

If you install dbus-x11 right before attempting to install Emacs, apt
will not attempt the init system replacement.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#961686: lintian: false positive: runtime-test-file-uses-supported-python-versions-without-python-all-build-depends

[Scott Kitterman]

Package: lintian
Severity: normal

>From lintian.debian.org, so I don't know the lintian version:

https://lintian.debian.org/sources/dkimpy/1.0.4-1.html

among other things it says:

 W 
runtime-test-file-uses-supported-python-versions-without-python-all-build-depends
 debian/tests/py3 py3versions -sv (line 5)

There is py3versions -sv is debian/tests/py3, so that part of the check
is correct, but the build-depends detection is not.  Here's
debian/tests/control for dkimpy 1.0.4-1:

Tests: py3
Depends: python3-all,
 python3-authres,
 python3-dnspython,
 python3-nacl,
 python3-pkg-resources,
 @
Restrictions: allow-stderr

So the check is wrong.

Scott K

Bug#961685: ITP: python-aiohttp-proxy -- full-featured proxy connector for aiohttp

[Martin]

Package: wnpp
Severity: wishlist
Owner: Martin 

* Package name: python-aiohttp-proxy
  Version : 0.1.1
  Upstream Author : Skactor 
* URL : https://github.com/Skactor/aiohttp-proxy
* License : Apache-2.0
  Programming Lang: Python
  Description : full-featured proxy connector for aiohttp
 
This library provides a SOCKS proxy connector for aiohttp.
HTTP, HTTPS, SOCKS4(a) and SOCKS5(h) proxies are supported.

Bug#958539: libtruth-java: Please update libtruth-java

[Olek Wojnar]

Update: I have up through version 0.44 building correctly. 0.45 requires
some extra dependencies so I'm going to package those first.

Bug#961684: lintian: exits with error: Can't use an undefined value as a HASH reference

[Francesco Poli (wintermute)]

Package: lintian
Version: 2.77.0
Severity: grave
Justification: renders package unusable

Hello,
while attempting to check a just built package within my sid
pbuilder-managed chroot enviroment, I see that lintian is no
longer working.
Please note that lintian/2.76.0 was working fine in the same
environment.

Attempting to check the package with the following command:

  # su -p pbuser -c "lintian -viF $PACKAGE.changes"
  Can't use an undefined value as a HASH reference at 
/usr/share/lintian/commands/lintian.pm line 831.

exits immediately with the above shown error message.
Same exact misbehavior with:

  # su -p pbuser -c "lintian -EviIL +pedantic $PACKAGE.changes"

I would say that this renders lintian unusable, hence the
'grave' severity of the bug report.

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


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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=en_US:en (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages lintian depends on:
ii  binutils 2.34-8
ii  bzip21.0.8-3
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-5
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+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b4
ii  libclone-perl0.45-1
ii  libconfig-tiny-perl  2.24-1
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libjson-maybexs-perl 1.004002-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.004000-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.112-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3300-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.82+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.2-1
ii  t1utils  1.41-4
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
pn  libperlio-gzip-perl  

Versions of packages lintian suggests:
pn  binutils-multiarch 
pn  libtext-template-perl  

-- no debconf information

Bug#961637: bambam should not apply Caps-Lock or Num-Lock conditions upon exit.

[Marcin Owsiany]

retitle 961637 restore Caps-Lock or Num-Lock conditions upon exit
tag 961637 + upstream help newcomer
thanks

I don't think CTRL+S/scroll lock apply to bambam as such, because it's not
a terminal application.
However I agree it would be nice to restore prior condition on exit.

Bug#948087: future of aufs in Debian.

[Noah Meyerhans]

On Tue, May 26, 2020 at 05:10:10PM +0300, Adrian Bunk wrote:
> > Adrian filed a rc bug in November 2019 which received no maintainer 
> > response, however the package was not autoremoved from testing due to aufs 
> > and aufs-tools being considered a "key packages" due to high popcon. This 
> > popcon actually seems to be growing in both absolute and percentage terms. 
> > I presume the high popcon is due to some deriviative (hence 
> > debian-derivatives and debian-live in cc) using aufs in their live image 
> > builds (as far as I can tell debian's own live images seem to use overlayfs 
> > instead nowadays).
> >...
> 
> It doesn't have to be a derivative, one webhoster who installs popcon by 
> default is enough.

It's very possible that it is the upstream Docker packaging that
accounts for the upward trend.  The docker.io packages in the Debian
archive list aufs-tools as "Suggests", so they won't be pulled in by
default, but the upstream docker-ce packages distributed directly by
Docker still have them at Recommends.

Docker no longer users aufs by default, though, having switched to
overlayfs some time ago.  I'm sure we could get them to drop the
Recommends if we're considering getting rid of it.

noah

Bug#961441: buster-pu: package libclamunrar/0.102.3-0+deb10u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Sun, 2020-05-24 at 17:47 +0200, Sebastian Andrzej Siewior wrote:
> As part of clamav's new 0.102.3 they also updated their unrar code to
> version 5.9.2, the previous version was based on 5.6.5. I can't tell
> based on the diff if it contains any code fixes or improved support
> of the rar archive. rarlabs / upstream does not provide a revision
> history (or it does and I I did not find it).
> 
> As part of this update I also introduce the `libclamunrar' package
> which only purpose is to depend on libclamunrar9. On the last soname
> bump not everyone noticed that the soname of libclamunrar changed and
> ended up with no unrar support. Due to its non-free nature we can't
> depend on it so it has been suggested to use this package which will
> remain on the next soname bump and pull-in the new libclamunrarX
> library.

Does anything pull the metapackage in on user systems, or is the
assumption that they will read the changelog and install it?

> This version of libclamunrar was in unstable 20th. I didn't backport
> the packaging related changes while preparing this version (I did
> include the update of the copyright file).

There seem to be a few, e.g. the removal of the dh_auto_install
override, the dropping of "--disable-clamav --without-pcre" from the
configure invocation, and most of the Build-Depends being removed.

Regards,

Adam

Bug#961440: stretch-pu: package clamav/0.102.3+dfsg-0~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-05-24 at 17:47 +0200, Sebastian Andrzej Siewior wrote:
> ClamAV upstream released 0.102.3 fixing two CVEs. From their news:
> 
> > ClamAV 0.102.3 is a bug patch release to address the following
> > issues.
> > 
> > - [CVE-2020-3327](
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3327):
> >  Fix a vulnerability in the ARJ archive parsing module in ClamAV
> > 0.102.2 that could cause a Denial-of-Service (DoS) condition.
> > Improper bounds checking of an unsigned variable results in an out-
> > of-bounds read which causes a crash.
[...]
> > - [CVE-2020-3341](
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3341):
> >  Fix a vulnerability in the PDF parsing module in ClamAV 0.101 -
> > 0.102.2 that could cause a Denial-of-Service (DoS) condition.
> > Improper size checking of a buffer used to initialize AES
> > decryption routines results in an out-of-bounds read which may
> > cause a crash. Bug found by OSS-Fuzz.
> > 
> > - Fix "Attempt to allocate 0 bytes" error when parsing some PDF
> > documents.
> > 
> > - Fix a couple of minor memory leaks.
> 

Please go ahead.

Regards,

Adam

Bug#961439: buster-pu: package clamav/0.102.3+dfsg-0+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-05-24 at 17:47 +0200, Sebastian Andrzej Siewior wrote:
> ClamAV upstream released 0.102.3 fixing two CVEs. From their news:
> 
> > ClamAV 0.102.3 is a bug patch release to address the following
> > issues.
> > 
> > - [CVE-2020-3327](
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3327):
> >  Fix a vulnerability in the ARJ archive parsing module in ClamAV
> > 0.102.2 that could cause a Denial-of-Service (DoS) condition.
> > Improper bounds checking of an unsigned variable results in an out-
> > of-bounds read which causes a crash.
[...]
> > - [CVE-2020-3341](
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-3341):
> >  Fix a vulnerability in the PDF parsing module in ClamAV 0.101 -
> > 0.102.2 that could cause a Denial-of-Service (DoS) condition.
> > Improper size checking of a buffer used to initialize AES
> > decryption routines results in an out-of-bounds read which may
> > cause a crash. Bug found by OSS-Fuzz.
> > 
> > - Fix "Attempt to allocate 0 bytes" error when parsing some PDF
> > documents.
> > 
> > - Fix a couple of minor memory leaks.

Please go ahead.

Was the intent that the updates be pushed via -updates?

Regards,

Adam

Bug#961579: stretch-pu: package erlang/1:19.2.1+dfsg-2+deb9u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Tue, 2020-05-26 at 12:33 +0300, Sergei Golovan wrote:
> Recently, a weak ciphers vulnerability was discovered in the Yaws web
> server, and reported as CVE-2020-12872 (see [1] and [2]).
> It turnes out that Yaws uses the default ciphers provided by Erlang,
> so I think it's better to fix this bug there. If we consider only
> Erlang packages in stretch, buster, bullseye/sid then only the
> version in stretch is vulnerable, so I'd like to propose an update
> for it.

Please go ahead.

Regards,

Adam

Bug#961682: Dgit::upstream_commitish_search(): should fail if more than one tag found

[Sean Whitton]

control: tag -1 + patch

Hello,

On Wed 27 May 2020 at 01:55PM -07, Sean Whitton wrote:

> From 0b881dddb050a7f0833bc37842082934492d23c6 Mon Sep 17 00:00:00 2001
> From: Sean Whitton 
> Date: Wed, 27 May 2020 13:49:07 -0700
> Subject: [PATCH] Dgit::upstream_commitish_search: fail if more than one tag
>  exists
>
> We should not assume we know which the user wants to merge, as
> git-deborig does not.
>
> Signed-off-by: Sean Whitton 

Reported-by: David Bremner 

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#961683: dgit-maint-debrebase(7): Drop bad advice about upstream/ tag case

[Sean Whitton]

Package: dgit
Version: 9.10
Tags: patch
X-debbugs-cc: brem...@debian.org

   Importing the release
   % git debrebase new-upstream 1.2.3

   replacing 1.2.3 with upstream/1.2.3 if you imported a tarball.

The first argument to the new-upstream subcommand is a version number,
not a tag name, so this instruction could never have been correct.

-- 
Sean Whitton
From 2527cd10d43a8eb0319584601a1e24f447ffe221 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Wed, 27 May 2020 13:57:47 -0700
Subject: [PATCH] dgit-maint-debrebase(7): Drop bad advice about upstream/ tag
 case

The first argument to the new-upstream subcommand is a version number,
not a tag name, so this instruction could never have been correct.

The user should not need usually to pass both the upstream version
number and the upstream/ tag name, either, because git-debrebase
should find it for them.

Reported-by: David Bremner 
Signed-off-by: Sean Whitton 
---
 dgit-maint-debrebase.7.pod | 2 --
 1 file changed, 2 deletions(-)

diff --git a/dgit-maint-debrebase.7.pod b/dgit-maint-debrebase.7.pod
index 373fb2f7..fdbf2e8d 100644
--- a/dgit-maint-debrebase.7.pod
+++ b/dgit-maint-debrebase.7.pod
@@ -394,8 +394,6 @@ or if you have a working watch file
 
 =back
 
-replacing I<1.2.3> with I if you imported a tarball.
-
 This invocation of git-debrebase(1) involves a git rebase.  You may
 need to resolve conflicts if the Debian delta queue does not apply
 cleanly to the new upstream source.
-- 
2.26.2



signature.asc
Description: PGP signature

Bug#961680: please provide a collection3 package

[Bernd Zeimetz]

Hi,

> The collectd-core package includes the collection3 viewer for the collectd
> statistics that are gathered in the RRDs in the examples subdir. It would
> be great if the Debian packaging built this as a separately installable
> package so that it updates along with collectd.

hmm, I'd assume that you have the collectd-core package on your
webserver - so why no run collection3 from the examples directory? I
don't think that adding a package for a tool that is - imho - pretty
much deprecated these days is not worth the work and disk space.


Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#961682: Dgit::upstream_commitish_search(): should fail if more than one tag found

[Sean Whitton]

Package: dgit
Version: 9.10
Severity: important
X-debbugs-cc: brem...@debian.org

Hello,

Dgit::upstream_commitish_search() should fail, as git-deborig does, if
there is more than one of the three kinds of tags is looks for with the
same upstream version number.

How this can cause trouble:

% git clone https://salsa.debian.org/debian/ledger.git
% cd ledger
% git remote add github https://github.com/ledger/ledger
% git fetch --tags github
% git checkout 722a502e82b95cc928468142895101af91e45e0b
% git debrebase new-upstream 3.2.1

Actual result: debrebase merges the v3.2.1 tag.

Expected result: complain that both v3.2.1 and upstream/3.2.1 tags
exist, and ask user to supply more arguments to new-upstream
subcommand to indicate which they want to use.

Attached is a minimal fix.

-- 
Sean Whitton
From 0b881dddb050a7f0833bc37842082934492d23c6 Mon Sep 17 00:00:00 2001
From: Sean Whitton 
Date: Wed, 27 May 2020 13:49:07 -0700
Subject: [PATCH] Dgit::upstream_commitish_search: fail if more than one tag
 exists

We should not assume we know which the user wants to merge, as
git-deborig does not.

Signed-off-by: Sean Whitton 
---
 Debian/Dgit.pm | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Debian/Dgit.pm b/Debian/Dgit.pm
index 5d898ae5..4e196570 100644
--- a/Debian/Dgit.pm
+++ b/Debian/Dgit.pm
@@ -634,12 +634,14 @@ sub git_check_unmodified () {
 sub upstream_commitish_search ($$) {
 my ($upstream_version, $tried) = @_;
 # todo: at some point maybe use git-deborig to do this
+my @found;
 foreach my $tagpfx ('', 'v', 'upstream/') {
 	my $tag = $tagpfx.(dep14_version_mangle $upstream_version);
 	my $new_upstream = git_get_ref "refs/tags/$tag";
 	push @$tried, $tag;
-	return $new_upstream if length $new_upstream;
+	push @found, $tag if $new_upstream;
 }
+return $found[0] if @found == 1;
 }
 
 sub resolve_upstream_version ($$) {
-- 
2.26.2



signature.asc
Description: PGP signature

Bug#961681: octave: StackOverflowError in Java process reaper

[Benjamin Moody]

Package: octave
Version: 4.4.1-5
Severity: normal

Dear Maintainer,

I don't know whether this is a bug in Octave or a bug in OpenJDK (or
both), but if an Octave program loads a Java library that creates a
subprocess, it results in an unhandled StackOverflowError, and trying
to get the exit status of the subprocess causes the entire program to
hang.

On Debian stretch (octave 4.0.3-3, openjdk-8-jre 8u252-b09-1~deb9u1):

$ octave -W -q -f
octave:1> b = javaObject('java.lang.ProcessBuilder', {'/bin/true'});
octave:2> p = b.start();
octave:3> p.waitFor()
ans = 0

On Debian buster (octave 4.4.1-5, openjdk-11-jre 11.0.7+10-3~deb10u1):

$ octave -W -q -f
octave:1> b = javaObject('java.lang.ProcessBuilder', {'/bin/true'});
OpenJDK 64-Bit Server VM warning: Archived non-system classes are disabled 
because the java.system.class.loader property is specified (value = 
"org.octave.OctClassLoader"). To use archived non-system classes, this property 
must be not be set
octave:2> p = b.start();

Exception: java.lang.StackOverflowError thrown from the 
UncaughtExceptionHandler in thread "process reaper"
octave:3> p.waitFor()

causes octave to hang.

(I have no idea what the "Archived non-system classes are disabled"
thing means, but it appears unrelated.)

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

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

Versions of packages octave depends on:
ii  libamd21:5.4.0+dfsg-1
ii  libarpack2 3.7.0-2
ii  libasound2 1.1.8-1
ii  libatlas3-base [liblapack.so.3]3.10.3-8
ii  libblas3 [libblas.so.3]3.8.0-2
ii  libbz2-1.0 1.0.6-9.2~deb10u1
ii  libc6  2.28-10
ii  libcamd2   1:5.4.0+dfsg-1
ii  libccolamd21:5.4.0+dfsg-1
ii  libcholmod31:5.4.0+dfsg-1
ii  libcolamd2 1:5.4.0+dfsg-1
ii  libcxsparse3   1:5.4.0+dfsg-1
ii  libfftw3-double3   3.3.8-2
ii  libfftw3-single3   3.3.8-2
ii  libfltk-gl1.3  1.3.4-9
ii  libfltk1.3 1.3.4-9
ii  libfreetype6   2.9.1-3+deb10u1
ii  libgcc11:8.3.0-6
ii  libgl1 1.1.0-1
ii  libglpk40  4.65-2
ii  libglu1-mesa [libglu1] 9.0.0-2.1+b3
ii  libgomp1   8.3.0-6
ii  libklu11:5.4.0+dfsg-1
ii  liblapack3 [liblapack.so.3]3.8.0-2
ii  liboctave6 4.4.1-5
ii  libopenblas-base [liblapack.so.3]  0.3.5+ds-3
ii  libportaudio2  19.6.0-1
ii  libqhull7  2015.2-4
ii  libqrupdate1   1.1.2-3
ii  libqscintilla2-qt5-13  2.10.4+dfsg-2.1
ii  libqt5core5a   5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5 5.11.3+dfsg1-1+deb10u3
ii  libqt5help55.11.3-4
ii  libqt5network5 5.11.3+dfsg1-1+deb10u3
ii  libqt5opengl5  5.11.3+dfsg1-1+deb10u3
ii  libqt5printsupport55.11.3+dfsg1-1+deb10u3
ii  libqt5sql5 5.11.3+dfsg1-1+deb10u3
ii  libqt5widgets5 5.11.3+dfsg1-1+deb10u3
ii  libsndfile11.0.28-6
ii  libstdc++6 8.3.0-6
ii  libsuitesparseconfig5  1:5.4.0+dfsg-1
ii  libumfpack51:5.4.0+dfsg-1
ii  libx11-6   2:1.6.7-1
ii  octave-common  4.4.1-5
ii  texinfo6.5.0.dfsg.1-4+b1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages octave recommends:
ii  default-jre-headless  2:1.11-71
ii  epstool   3.09-1
ii  gnuplot-qt [gnuplot-x11]  5.2.6+dfsg1-1+deb10u1
ii  libatlas3-base3.10.3-8
ii  libopenblas-base  0.3.5+ds-3
ii  octave-doc4.4.1-5
ii  pstoedit  3.73-1+b1

Versions of packages octave suggests:
ii  liboctave-dev  4.4.1-5

-- debconf-show failed

Bug#961680: please provide a collection3 package

[Joseph Nahmias]

Package: collectd-core
Version: 5.8.1-1.3
Severity: wishlist
File: /usr/share/doc/collectd-core/examples/collection3

Hello,

The collectd-core package includes the collection3 viewer for the collectd
statistics that are gathered in the RRDs in the examples subdir. It would
be great if the Debian packaging built this as a separately installable
package so that it updates along with collectd.

Thanks,
--Joe


-- System Information:
Debian Release: 10.4
  APT prefers stable-debug
  APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: i386 (i686)

Bug#961679: base-files: please include window title in /etc/issue

[Adam Borowski]

Package: base-files
Version: 11
Severity: wishlist
Tags: patch

Hi!
It would be good if /etc/issue set the window title appropriately.

While it might sound wrong (as /etc/issue is used only for local terminals),
serial consoles do count as local.  Thus, the output may hit either a real
console which since Linux 3.16 ignores these sequences, or a terminal
emulator.

I thus propose to set default /etc/issue to:
\e]0;⭍\n\e\\Debian GNU/Linux \n \l

Explanation:
'\e' means ESC (0x1b).
'\e]0; foo bar baz \e\\' means "set window title to ' foo bar baz '.
'⭍' is my marker that the console is serial rather than ssh; you
may or may not want to keep this bit.
'\n' is counterintuitively machine name rather than 0x0a.
'Debian GNU/Linux \n \l' is the old /etc/issue -- kept unchanged.


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

Kernel: Linux 5.6.4-00079-g239f7f3e0278 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages base-files depends on:
ii  mawk [awk]  1.3.4.20200120-2

base-files recommends no packages.

base-files suggests no packages.

-- Configuration Files:
/etc/issue changed:
\e]0;⭍\n\e\\Debian GNU/Linux \n \l


-- no debconf information

Bug#961676: 5.6 kernel crashes host when using VFIO on KVM guests

[Simon John]

On Wed, 27 May 2020 21:31:46 +0200 Salvatore Bonaccorso 
 wrote:

Source: linux
Version: 5.6.7-1
Control: submitter -1 deb...@the-jedi.co.uk

Forwarding this report as bug in the BTS.

On Mon, May 25, 2020 at 09:03:43PM +0100, Simon John wrote:
> Sorry to email directly but I've tried reportbug but it doesn't seem to work
> with the kernel packages.

What exactly did not work?


I tried to report a bug in 5.5 kernel regarding HDMI audio not working 
after a while until you kill pulseaudio but reportbug did not create a 
valid report i guess as it never got created - i tried using the email 
template too.


same problem when trying to report this bug.

Anyway, at least this bug has been created now, hopefully will get 
looked into.



> The 5.6.0-1 kernel in Sid when used in conjunction with VFIO (PCI
> passthrough) guests in Qemu-KVM causes KVM to crash with no useful logs -
> the guest partially starts. Eventually the host slows down and needs to be
> powered off. Doesn't affect non-VFIO guests using spice/headless, only when
> passing through a PCIe graphics card or USB keyboard/mouse.
> 
> 5.6.0-2 that just landed makes this infinitely worse - as soon as you start

> a VFIO guest the host hard crashes.
> 
> 5.3/5.4/5.5 kernels do not have this problem with the same version of Qemu

> and reverting from qemu 5.0 to 4.2 doesn't help, so it must be the 5.6
> kernel causing the issue.
> 
> Not sure what logs or any useful information I can supply you, there's some

> interesting comments on this reddit thread suggesting a couple of bugs that
> have fixes upstream:
> 
> https://www.reddit.com/r/VFIO/comments/glfgqs/qemu_5_vfio_no_longer_works_on_debian/
> 
> I'm using macos catalina and win10 guests to reproduce the issue, and using

> Intel not AMD chips.
> 
> Cheers.
> 
> -- 
> Simon John


Regards,
Salvatore




Best regards.

--
Simon John

Bug#961678: RFS: xtrkcad/1:5.1.2a-1 -- CAD program for designing model railroad layouts

[Jörg Frings-Fürst]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xtrkcad"

   Package name: xtrkcad
   Version : 1:5.1.2a-1
   Upstream Author : XTrkCAD Developers 

   URL : http://xtrkcad.org/
   License : GPL-2+
   Vcs : https://jff.email/cgit/xtrkcad.git/
   Section : editors

It builds those binary packages:

  xtrkcad - CAD program for designing model railroad layouts
  xtrkcad-common - CAD program for designing model railroad layouts (common
files)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xtrkcad/xtrkcad_5.1.2a-1.dsc

or from git:

  
https://jff.email/cgit/xtrkcad.git/?h=release%2Fdebian%2F1_5.1.2a-1

Changes since the last upload:

   * New upstream release.
 - Remove upstream applied debian/patches/0100-messages_h.patch.
 - Refresh debian/patches/0900-spelling-errors.patch.
   * Rename NEWS.Debian to NEWS.
   * Declare compliance with Debian Policy 4.5.0 (No changes needed).
   * Switch to debhelper-compat:
 - debian/control: change to debhelper-compat (=13).
 - remove debian/compat.
   * debian/copyright:
 - Remove File-Excluded.
 - Add year 2020 to myself.
   * debian/watch:
 - Fix syntax.


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

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

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


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

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


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



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

Bug#961591: [RFS] r-bioc-graph

[Nilesh Patra]

On Thu, 28 May 2020, 01:43 Dylan Aïssi,  wrote:

> Hi,
>
> Le mer. 27 mai 2020 à 20:04, Nilesh Patra  a écrit :
> >
> > The second test (needing the library) failed on gitlab-ci, w/o adding
> r-cran-xml and r-cran-runit, possible because this doesn't pick up depends
> from test-depends.
> > This passed on my local machine though. Since I wanted to be sure, I
> moved this there.
>
> There is probably a bug on the salsa-ci side, because both tests
> passed on my computer. Let's skip salsa-ci for now.
>

Ahh, alrighty.


> I have moved back these dependencies to test-deps and I have updated
> your patch (str_replace_all --> gsub) to not add a new dependency.
>

That's good, and makes sense. I didn't know about this, possibly because I
don't speak R :P


> You probably already noticed, the debian/test/control files for R
> packages require a lot of manual work to keep the list of test-deps
> up-to-date. Because I don't want to do this manually, I moved the code
> to tests these packages into pkg-r-autopkgtest. The list of test-deps
> is automatically generated at run time from the DESCRIPTION file
>

That's nice!

Currently, it is enabled only for bioconductor packages, if there is
> no big bug with this transition, we will be able to remove the
> debian/test/control files and to enable this for other R packages.
>

Got it, thanks for the explanation.


> Thanks again for #961591.
>

:)
And thanks a lot for letting me have this upload (i.e. my name on d/ch for
this upload)

Kind regards,
Nilesh

>

Bug#928813: libapache2-mod-jk: Jk can not find any configured worker

[Markus Koschany]

Am 27.05.20 um 21:54 schrieb Thorsten Glaser:
[...]
> Thank you. Please also take care of buster.

I will take care of Buster eventually.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#961653: libguestfs: FTBFS with Erlang 23

[Hilko Bengen]

* Sergei Golovan:

> I'd like to upload Erlang 23 for the bullseye release, but it makes
> libguestfs fail to build from source, because it uses liberl_interface
> which has been removed from the Erlang distribution.

After briefly chatting with Richard, I have decided to disable building
the Erlang binding, as it has been done for Fedora.

Cheers,
-Hilko

Bug#961677: ITP: libstatistics-pca-perl -- perl module for principal component analysis (PCA)

[Étienne Mollier]

Package: wnpp
Owner: Etienne Mollier 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org, 
debian-...@lists.debian.org

* Package name: libstatistics-pca-perl
  Version : 0.0.1
  Upstream Author : Daniel S. T. Hughes 
* URL : https://metacpan.org/release/Statistics-PCA
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : perl module for principal component analysis (PCA)

Statistics::PCA provides functions for principal component analysis (PCA).
PCA transforms higher-dimensional data consisting of a number of possibly
correlated variables into a smaller number of uncorrelated variables termed
principal components (PCs). The higher the ranking of the PCs the greater the
amount of variability that the PC accounts for.

This PCA procedure involves the calculation of the eigenvalue decomposition
from a data covariance matrix after mean centering the data.

See https://en.wikipedia.org/wiki/Principal_component_analysis

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

Statistics::PCA will allow the command prinseq-graphs, from the
package prinseq-lite, to draw PCA graphs, in addition to the
variety of diagrams already available.  It will thus become a
dependency of prinseq-lite.

The source code of of the package is available on Salsa:


https://salsa.debian.org/perl-team/modules/packages/libstatistics-pca-perl

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/

Bug#961591: [RFS] r-bioc-graph

[Dylan Aïssi]

Hi,

Le mer. 27 mai 2020 à 20:04, Nilesh Patra  a écrit :
>
> The second test (needing the library) failed on gitlab-ci, w/o adding 
> r-cran-xml and r-cran-runit, possible because this doesn't pick up depends 
> from test-depends.
> This passed on my local machine though. Since I wanted to be sure, I moved 
> this there.

There is probably a bug on the salsa-ci side, because both tests
passed on my computer. Let's skip salsa-ci for now.

I have moved back these dependencies to test-deps and I have updated
your patch (str_replace_all --> gsub) to not add a new dependency.

You probably already noticed, the debian/test/control files for R
packages require a lot of manual work to keep the list of test-deps
up-to-date. Because I don't want to do this manually, I moved the code
to tests these packages into pkg-r-autopkgtest. The list of test-deps
is automatically generated at run time from the DESCRIPTION file.
Currently, it is enabled only for bioconductor packages, if there is
no big bug with this transition, we will be able to remove the
debian/test/control files and to enable this for other R packages.

Thanks again for #961591.

Best,
Dylan

Bug#960806: buster-pu: package policyd-rate-limit/1.0.0-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2020-05-18 at 19:20 +0200, Pierre-Elliott Bécue wrote:
> Le lundi 18 mai 2020 à 14:32:24+0100, Adam D. Barratt a écrit :
> > On Mon, 2020-05-18 at 14:13 +0100, Adam D. Barratt wrote:
> > > That appears to have dropped a number of entries from the
> > > changelog
> > > for the unstable upload it's based on, which is a little
> > > confusing to
> > > say the least.
> > > 
> > > If you're dropping changes for the backport, then the unstable
> > > changelog stanza should be exactly as it was for the upload to
> > > unstable, and any changes that weren't included should be
> > > itemised in
> > > the changelog for the stable upload, if they're sufficiently
> > > relevant.
> > 
> > As an alternative suggestion, rather than trying to backport the
> > upload
> > to unstable and reverting a bunch of the changes in the process, it
> > might be easier to start from the current stable package and simply
> > apply the changes required to resolve:
> > 
> > +- Fixes issues in accounting due to socket reuse (Closes:
> > #960792)
> > +- Fixes undeclared variable issue
> > 
> > assuming those are as simple and isolated as I suspect from looking
> > through the diff.
> 
> Would the attached diff be fine?

Yes, that looks OK, thanks.

Regards,

Adam

Bug#928813: libapache2-mod-jk: Jk can not find any configured worker

[Thorsten Glaser]

Markus Koschany dixit:

>The mods-available directory is correct. Both conf and load file have to
>be installed into it but the file naming is wrong. httpd-jk.conf should
>be jk.conf.

OK, so the way it is in stretch is correct.

>Just renaming the file should be sufficient.

That plus renaming and retargetting the symlink.

Given that stretch has the same upstream version, just with a
different Debian revision, I think it makes sense to diff these
two and make the one in sid equivalent to the one in stretch
modulo changelog entries, and then upload that to buster as well.

>I will upload a new revision.

Thank you. Please also take care of buster.

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

Bug#897275: closed by Debian FTP Masters (Bug#916837: Removed package(s) from unstable)

[Helmut Grohne]

Control: reopen -1
Control: reassign -1 llvm-11

The issue affects all llvm versions.

Helmut

Bug#958479: qmake passes unsupported -isystem to gcc

[Helmut Grohne]

Hi Dmitry,

On Wed, May 27, 2020 at 06:17:56PM +0300, Dmitry Shachnev wrote:
> Can I ask you to forward it to upstream Gerrit [1] (see [2] for the
> instruction)? Unfortunately, upstream requires the patch author to sign a
> CLA so I cannot easily forward it under my account. Alternatively, you may
> publicly state that you license your patch under a permissive license
> (e.g. BSD), which should also work (but upstream does not like this much).

I looked and the process is waaay to beyond what I can do. I'm not up to
consenting to a 10-page TOS for a 5-line patch. Sorry.

The 5-page CLA doesn't make this any better. Not a friendly project to
contribute to.

Your suggestion to explicitly license it under BSD seems much more
reasonable to me. Let's do that. However, given that I find you much
more trustworthy than QT upstream, I think that there is an even simpler
option: Please treat the patch I sent to this bug as yours. You may
claim authorship. I think legally that means I transfer whatever
copyright I may have on this particular patch to you after licensing it
under BSD.

Helmut

Bug#961676: 5.6 kernel crashes host when using VFIO on KVM guests

[Salvatore Bonaccorso]

Source: linux
Version: 5.6.7-1
Control: submitter -1 deb...@the-jedi.co.uk

Forwarding this report as bug in the BTS.

On Mon, May 25, 2020 at 09:03:43PM +0100, Simon John wrote:
> Sorry to email directly but I've tried reportbug but it doesn't seem to work
> with the kernel packages.

What exactly did not work?

> The 5.6.0-1 kernel in Sid when used in conjunction with VFIO (PCI
> passthrough) guests in Qemu-KVM causes KVM to crash with no useful logs -
> the guest partially starts. Eventually the host slows down and needs to be
> powered off. Doesn't affect non-VFIO guests using spice/headless, only when
> passing through a PCIe graphics card or USB keyboard/mouse.
> 
> 5.6.0-2 that just landed makes this infinitely worse - as soon as you start
> a VFIO guest the host hard crashes.
> 
> 5.3/5.4/5.5 kernels do not have this problem with the same version of Qemu
> and reverting from qemu 5.0 to 4.2 doesn't help, so it must be the 5.6
> kernel causing the issue.
> 
> Not sure what logs or any useful information I can supply you, there's some
> interesting comments on this reddit thread suggesting a couple of bugs that
> have fixes upstream:
> 
> https://www.reddit.com/r/VFIO/comments/glfgqs/qemu_5_vfio_no_longer_works_on_debian/
> 
> I'm using macos catalina and win10 guests to reproduce the issue, and using
> Intel not AMD chips.
> 
> Cheers.
> 
> -- 
> Simon John

Regards,
Salvatore

Bug#961481: ceph: Protocol incompatibility between armhf and amd64

[Bernd Zeimetz]

Hi,

sorry for not replying inline, but I thought I'd just share my general
opinion on this.

The biggest issue in maintaining ceph is to make it build on 32 bit
architectures. This seems not to be supported at all by upstream anymore.

Between 14.2.7 and 14.2.9 I had a longer look into the issue and started
to fix some issues, for example the parsing of config options does
pretty broken things if the default for the option does not fit into a
32bit integer. Fixing this properly brought me to various other places
where size_t is being used in the code, but actually an (at least)
uint64_t is being required.

Fedora already removed ceph for all 32bit architectures with a "not
supported by upstream anymore", but I was not able to find an official
statement from ceph upstream.

Also unfortunately I did not yet find the time to collect my findings
and send them to the ceph devel mailinglist, but I'd assume that they
just don't want to support 32bit anymore, otherwise they'd test it properly.

As the work to fix this is properly seems to be a rather long task, I
definitely won't do this. But I also don't want to upload maybe-working
binaries to Debian anymore. So unless somebody fixes and tests ceph for
32bit (or does this for Debian, also fine for me - running the
regression test suite is possible with enough resources and some
hardware), I will remove all 32bit architectures with the next upload.


I guess those are not the news you wanted to hear, but so fard thats the
situation.


Bernd


On 5/27/20 10:54 AM, Ard van Breemen wrote:
> Hi,
> 
> On Tue, May 26, 2020 at 06:35:20PM +0200, Val Lorentz wrote:
>> Thanks for the tip.
>>
>> I just tried downgrading an OSD (armhf) and a monitor (amd64) to
>> 14.2.7-1~bpo10+1 using http://snapshot.debian.org/ ; but they are still
>> unable to communicate ("failed decoding of frame header:
>> buffer::bad_alloc").
>>
>> So this might be a different issue, although related.
> 
> Well, 14.2.7-~bpo something did work on my armhf osd cluster,
> with 2 mons running on armhf, and one on proxmox pve 6 running
> ceph 14.2.8 .
> What Already did not work was OSD's on AMD64 working together
> with a 2xarmhf and 1xamd64 mon setup.
> I had a lot of problems getting it to work at all, but I thought
> it was just my lack of knowledge at that time. 99% of the
> problems is with setting up the correct secrets, or in other
> words, the handling of the "keyrings". Even between amd64 and
> amd64 this has been buggy if I look at the release notes.
> Specifically 14.2.6 to 14.2.7 I think.
> I assume bugs are in authentication, because as long as I did not
> reboot the amd64 it works.
> The daemons authenticate using the secrets, and the secret gives
> an authentication ticket.
> 
> Anyway: the most simple test is to install a system, rsync
> /etc/ceph and type in ceph status. It either works (on 32 bits,
> fix the timeout in the python script, because if you don't it
> won't work at all) or it doesn't return at all.
> 
> I will test if it's also the case with armhf ceph cli client to a
> amd64 cluster. I only have one working amd64 cluster though, and
> it has 2 fake OSD's, because amd64 clusters are too expensive to
> experiment with.
> I have to do some networking hacks though to connect the systems.
> 
> Anyway: the kernel has no problem talking to either OSD types, so
> the kernel's protocol handling is implemented correctly, and
> cephx works between an rbd amd64 or armhf kernel client and armhf
> userspace.
> The rbd amd64 userspace utility however does not work at all. As
> far as I can see it can't get past authentication, but without
> any logs I am a bit riddled.
> 
> By the way: the mgr dashboard modules is about 99% correct. The
> disk space is obviously calculated incorrectly.
> 
> Regards,
> Ard
> 

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#961675: reportbug: Cannot report bug due to char encoding problem

[Marc-Jano Knopp]

Package: reportbug
Version: 7.6.0
Severity: normal

Dear Maintainer,

today I tried provide extra information for an existing bug report,
which failed:


$ reportbug -N 590876
Warning: untranslated token "envelopefrom"
*** Welcome to reportbug.  Use ? for help at prompts. ***
Note: bug reports are publicly archived (including the email address of the 
submitter).
Detected character set: ISO-8859-15
Please change your locale if this is incorrect.

Using 'Marc-Jano Knopp ' as your from address.
Retrieving report #590876 from Debian bug tracking system...

{ Here, I get a "less" prompt reading "byte 0/0 (END)", which I quit by
  pressing 'q'. }

Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2284, in 
main()
  File "/usr/bin/reportbug", line 1115, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1391, in user_interface
exinfo = ui.show_report(report, 'debian', self.options.mirrors,
  File "/usr/lib/python3/dist-packages/reportbug/ui/text_ui.py", line 456, in 
show_report
fd.write(text)
  File "/usr/lib/python3.8/encodings/iso8859_15.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_table)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u0148' in position 
369: character maps to 
$ echo $?
1
$

Observations:

- The error does not occur with an UTF-8 uxrvt.
- The error does not occur on e.g. bug #177000.
- It seems it chokes on the name of the "Upstream Author" in #590876.
- It may be that bug #814454 is related to this bug.


-- Package-specific info:
** Environment settings:
EDITOR="jed"
DEBEMAIL="pub_br_debian@marc-jano.de"
DEBFULLNAME="Marc-Jano Knopp"
INTERFACE="text"

** /home/mjk/.reportbugrc:
reportbug_version "3.8"
mode standard
ui text
realname "Marc-Jano Knopp"
email "pub_br_debian@marc-jano.de"
envelopefrom "pub_br_debian@marc-jano.de"

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'stable'), (50, 'unstable'), (25, 
'oldstable'), (10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=UTF-8) 
(ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US.ISO-8859-15 
(charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt2.1.4
ii  python33.8.2-3
ii  python3-reportbug  7.6.0
ii  sensible-utils 0.0.12+nmu1

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
pn  debsums   
pn  dlocate   
ii  emacs-bin-common  1:26.3+1-2
ii  file  1:5.38-5
ii  gnupg 2.2.20-1
pn  python3-urwid 
pn  reportbug-gtk 
ii  ssmtp [mail-transport-agent]  2.64-9
ii  xdg-utils 1.1.3-2

Versions of packages python3-reportbug depends on:
ii  apt2.1.4
ii  file   1:5.38-5
ii  python33.8.2-3
ii  python3-apt2.1.3
ii  python3-debian 0.1.37
ii  python3-debianbts  3.0.2
ii  python3-requests   2.23.0+dfsg-2
ii  sensible-utils 0.0.12+nmu1

python3-reportbug suggests no packages.

-- no debconf information

Bug#961591: [RFS] r-bioc-graph

[Nilesh Patra]

On Wed, 27 May 2020, 23:28 Dylan Aïssi,  wrote:

> Hi Nilesh,
>
> Le mer. 27 mai 2020 à 19:36, Nilesh Patra  a écrit :
> >
> > Hi,
> > Currently r-bioc-graph has failing tests, and has RC bug - #961591 filed
> against this.
> > I have fixed this and pushed my changes to the team repo here[1].
> > Need review and sponsorship.
> >
>
> Thanks for #961591 !!!
>
> I don't understand why you moved some test-deps to deps ?


The second test (needing the library) failed on gitlab-ci, w/o adding
r-cran-xml and r-cran-runit, possible because this doesn't pick up depends
from test-depends.
This passed on my local machine though. Since I wanted to be sure, I moved
this there.

Was this incorrect to do?
Please do let me know.

Regards,
Nilesh

Bug#961591: [RFS] r-bioc-graph

[Dylan Aïssi]

Hi Nilesh,

Le mer. 27 mai 2020 à 19:36, Nilesh Patra  a écrit :
>
> Hi,
> Currently r-bioc-graph has failing tests, and has RC bug - #961591 filed 
> against this.
> I have fixed this and pushed my changes to the team repo here[1].
> Need review and sponsorship.
>

Thanks for #961591 !!!

I don't understand why you moved some test-deps to deps ?

Best,
Dylan

Bug#961206: improve sphinx usage for cross building

[Helmut Grohne]

Hi Dmitry,

On Wed, May 27, 2020 at 05:56:09PM +0300, Dmitry Shachnev wrote:
> If we can fix cross building in DPMT in an automated way, then why not do it?
> Of course it is not the first priority, we can do it after fixing all other
> packages.

I did mean to say that but got it wrong.

> But the actual split is the last step (4th in your message). So at the first
> step I just add Provides and don't split anything. Right?

Yes, thank you for reminding me of what I wrote. I'm working on too many
packages in parallel.

Can we also document somewhere what dependency one should use? I'm not
sure where one would do that though. Possibly a README? Sometimes this
is done in the package description.

How feasible would it be to ask lintian devs for help? Can we detect
uses of sphinx-build in a reasonable manner to flag missing
dependencies?

> Can you please quickly look at this commit and say if it makes sense to you?
> 
> https://salsa.debian.org/python-team/modules/sphinx/-/commit/c51e0ad4908bb7d6

I do not see and issues in that commit. I'd throw it at piuparts before
daring to upload it though. piuparts should be able to catch the worst
issues.

Helmut

Bug#442627: adduser: Please, consider 0750 as default permission to user's directories

[Dario Susman]

Package: adduser
Version: 3.118
Followup-For: Bug #442627

Dear Maintainer,

Unless I'm wrong, I expected the home directories to be set to mode 0700. 
Instead, they are still set to 0755 because /etc/adduser.conf still has:

# If DIR_MODE is set, directories will be created with the specified
# mode. Otherwise the default mode 0755 will be used.
DIR_MODE=0755

Can this be set by default? From the security point of view alone it should be 
the route to go.
When the package is updated it should ask the user if this wants to be set, say 
if the file was modified recently.

Thanks!

Cheers,

Dario Susman


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

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

Versions of packages adduser depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  passwd 1:4.8.1-1

adduser recommends no packages.

Versions of packages adduser suggests:
ii  liblocale-gettext-perl  1.07-4
ii  perl5.30.2-1

-- debconf information:
  adduser/homedir-permission: true
  adduser/title:

Bug#954765: git: git pull downloads all objects again

[Sven Joachim]

Control: forwarded -1 
https://public-inbox.org/git/20200422084254.GA27502@furthur.local/

On 2020-03-23 18:57 +0100, Sven Joachim wrote:

> On 2020-03-23 07:10 +0100, Sven Joachim wrote:
>
>> Package: git
>> Version: 1:2.26.0~rc2-1
>> Severity: important
>>
>> I have a git repository for the Linux kernel where I track both Linus'
>> and the stable repository.
>>
>> ,
>> | $ git remote --verbose show
>> | origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
>> (fetch)
>> | origin  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
>> (push)
>> | stable  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 
>> (fetch)
>> | stable  https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git 
>> (push)
>> `
>>
>> A few days ago, after the update to 2.26.0-rc2, I fetched from the
>> stable tree.  This triggered a run of "git gc --auto" in the background
>> as there were more than 6700 loose objects.
>>
>> This morning I pulled from Linus' tree, and it downloaded _a lot_ of
>> objects.  Both that and resolving deltas took quite some time, as one
>> might imagine.
>>
>> ,
>> | $ git pull
>> | remote: Enumerating objects: 7226920, done.
>> | remote: Counting objects: 100% (7226920/7226920), done.
>> | remote: Compressing objects: 100% (1098637/1098637), done.
>> | remote: Total 7226920 (delta 6082531), reused 7224317 (delta 6080838)
>> | Receiving objects: 100% (7226920/7226920), 1.18 GiB | 3.95 MiB/s, done.
>> | Resolving deltas: 100% (6082531/6082531), done.
>> `
>
> Additionally, the size of the .git directory ballooned to ~3.5 GiB after
> that.  Running "git gc" manually reduced it to ~2 GiB which I think is
> normal.

It seems this has been reported upstream in the meantime, and the fix
(or workaround) was to disable protocol version 2 by default in git
2.27.

Meanwhile, after seeing the problem again I had switched to https for
Linus' repository which also helped.

I think the bug should be either closed or the severity downgraded, but
I leave the decision to the package maintainer who also participated in
the upstream discussion. :-)

Cheers,
   Sven

Bug#932759: marked as done (After upgrade from stretch to buster, removal of obsolete xen 4.8 packages seems to trigger shutdown of xenconsoled)

[Hans van Kranenburg]

Hi,

On 5/27/20 7:39 PM, Debian Bug Tracking System wrote:
> Your message dated Wed, 27 May 2020 17:36:26 +
> with message-id 
> and subject line Bug#932759: fixed in xen 4.11.4-1
> has caused the Debian Bug report #932759,
> regarding After upgrade from stretch to buster, removal of obsolete xen 4.8 
> packages seems to trigger shutdown of xenconsoled
> to be marked as done.
> 
> This means that you claim that the problem has been dealt with.

To avoid confusion, yes, this one closes with the upload of 4.11.4 to
unstable which has the fix.

However, it's still present in 4.11.3+24-g14b62ab3e5-1~deb10u1 in
buster. So, the same fix will also go into buster later, to in the end
help users upgrade from buster to bullseye.

Hans

Bug#959838: Can you help? (ITP: opencensus-java -- Stats collection and distributed tracing framework)

[Felix Natter]

Andreas Tille  writes:

> Hi Felix,

hello Andreas,

> since you recently provided some help with another Java package: This
> one is a predependency for bazel which would be really great to have
> torch (the machine learning framework) which in turn is needed by lots
> of COVID-19 relevant packages.  So if you have a clue how to build this
> it would be another interesting step forward.
>
> Kind regards
>
>  Andreas.
>
> PS: Feel free to answer on list
>
>   https://lists.debian.org/debian-java/2020/05/msg00019.html
>
>
> I've started packaging in
>
>https://salsa.debian.org/java-team/opencensus-java
>
> to support bazel packaging.  Unfortunately I have no idea how to fix all
> the (Build-)Depends of the gradle build.  I was following a hint given
> on debian-java list to find out some dependency relations via
>
>gradle build --info

Wow, what a huge project (and, as usual in Java, with a huge number of
dependencies)...

There are toplevel dependencies (/build.gradle), which are "only" gradle
plugins, so IMHO some of these are candidates for patching out:

classpath 'ru.vyarus:gradle-animalsniffer-plugin:1.4.6'

classpath("org.springframework.boot:spring-boot-gradle-plugin:2.0.5.RELEASE")
classpath 'net.ltgt.gradle:gradle-errorprone-plugin:0.0.16'
classpath "net.ltgt.gradle:gradle-apt-plugin:0.18"
classpath 'com.github.ben-manes:gradle-versions-plugin:0.20.0'
classpath 
"gradle.plugin.com.github.sherter.google-java-format:google-java-format-gradle-plugin:0.8"
classpath "me.champeau.gradle:jmh-gradle-plugin:0.4.8"
classpath "gradle.plugin.io.morethan.jmhreport:gradle-jmh-report:0.9.0"

Then there are ~50 dependencies in the 'libraries' map (most probably
all referenced in subdirectory build.gradle's, like "compile
libraries.grpc_context" in /api/build.gradle):

 libraries = [
appengine_api: 
"com.google.appengine:appengine-api-1.0-sdk:${appengineVersion}",
aspectj: "org.aspectj:aspectjrt:${aspectjVersion}",
auto_value: 
"com.google.auto.value:auto-value:${autoValueVersion}",
auto_service: 'com.google.auto.service:auto-service:1.0-rc3',
byte_buddy: 'net.bytebuddy:byte-buddy:1.8.22',
config: 'com.typesafe:config:1.2.1',
disruptor: 'com.lmax:disruptor:3.4.2',
errorprone: 
"com.google.errorprone:error_prone_annotations:${errorProneVersion}",
findbugs_annotations: 
"com.google.code.findbugs:annotations:${findBugsAnnotationsVersion}",
google_auth: 
"com.google.auth:google-auth-library-credentials:${googleAuthVersion}",
google_cloud_logging: 
"com.google.cloud:google-cloud-logging:${googleCloudGaVersion}",
google_cloud_trace: 
"com.google.cloud:google-cloud-trace:${googleCloudBetaVersion}",
log4j2: "org.apache.logging.log4j:log4j-core:${log4j2Version}",
zipkin_reporter: 
"io.zipkin.reporter2:zipkin-reporter:${zipkinReporterVersion}",
zipkin_urlconnection: 
"io.zipkin.reporter2:zipkin-sender-urlconnection:${zipkinReporterVersion}",
jaeger_reporter: 
"io.jaegertracing:jaeger-client:${jaegerReporterVersion}",
google_cloud_monitoring: 
"com.google.cloud:google-cloud-monitoring:${googleCloudGaVersion}",
grpc_auth: "io.grpc:grpc-auth:${grpcVersion}",
grpc_context: "io.grpc:grpc-context:${grpcVersion}",
grpc_core: "io.grpc:grpc-core:${grpcVersion}",
grpc_netty: "io.grpc:grpc-netty:${grpcVersion}",
grpc_netty_shaded: "io.grpc:grpc-netty-shaded:${grpcVersion}",
grpc_stub: "io.grpc:grpc-stub:${grpcVersion}",
guava: "com.google.guava:guava:${guavaVersion}",
jsr305: 
"com.google.code.findbugs:jsr305:${findBugsJsr305Version}",
signalfx_java: 
"com.signalfx.public:signalfx-java:${signalfxVersion}",
spring_aspects: 
"org.springframework:spring-aspects:${springVersion}",
spring_boot_starter_web: 
"org.springframework.boot:spring-boot-starter-web:${springBootVersion}",
spring_boot_starter_web2: 
"org.springframework.boot:spring-boot-starter-web:${springBoot2Version}",
spring_cloud_build: 
"org.springframework.cloud:spring-cloud-build:${springCloudVersion}",
spring_cloud_starter_sleuth: 
"org.springframework.cloud:spring-cloud-starter-sleuth:${springCloudVersion}",
spring_context: 
"org.springframework:spring-context:${springVersion}",
spring_context_support: 
"org.springframework:spring-context-support:${springVersion}",
prometheus_simpleclient: 
"io.prometheus:simpleclient:${prometheusVersion}",
protobuf: 
"com.google.protobuf:protobuf-java:${protobufVersion}",
opencensus_proto: 

Bug#961591: [RFS] r-bioc-graph

[Nilesh Patra]

Hi,
Currently r-bioc-graph has failing tests, and has RC bug - #961591 filed
against this.
I have fixed this and pushed my changes to the team repo here[1].
Need review and sponsorship.

[1]: https://salsa.debian.org/r-pkg-team/r-bioc-graph


Thanks and regards
Nilesh

Bug#928813: libapache2-mod-jk: Jk can not find any configured worker

[Markus Koschany]

Am 27.05.20 um 17:28 schrieb Thorsten Glaser:
[...]
> In stretch, an “a2enmod jk” will enable mods-available/jk.conf
> and make things work.
> 
> From reading the changelog, you wanted to “Install new httpd-jk.conf
> file which follows Apache 2.4 syntax”, but the directory is wrong;
> these files belong into conf-available, not mods-available.
> That being said, that would require both “a2enmod jk” *and*
> “a2enconf httpd-jk”, which is a UI regression against earlier,
> so I’d prefer for the file to be renamed back to what it was
> in stretch over moving it to another directory.
> 
> 
> ⚠ I intend to team-upload the fix if not done within the week. ⚠
> 

The mods-available directory is correct. Both conf and load file have to
be installed into it but the file naming is wrong. httpd-jk.conf should
be jk.conf. Just renaming the file should be sufficient. I will upload a
new revision.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#961642: Patch

[Francois Marier]

I've applied the attached patch locally and it has silenced the warning.

The first patch hunk (config) is the necessary one, but I've taken the
liberty to remove all other uses of the "tempfile" command.

Francois

-- 
https://fmarier.org/
--- /home/francois/config	2020-05-26 19:17:16.192981188 -0700
+++ config	2020-05-26 19:17:33.213426984 -0700
@@ -415,7 +415,7 @@
   #
 
   [ -n "$RCFILE" -a -r $RCFILE ] && {
-tempfile=`tempfile -d $WORKDIR` || tempfile=$WORKDIR/rcfile.$$
+tempfile=`mktemp -p $WORKDIR` || tempfile=$WORKDIR/rcfile.$$
 $GREP -v '^#' $RCFILE |
 $SED -e 's/^\(.*\)=/export \1; \1=/' > $tempfile
 . $tempfile
--- /home/francois/list_fs_linux.sh	2020-05-26 19:19:14.888087494 -0700
+++ systems/Linux/2/list_fs_linux.sh	2020-05-26 19:19:03.251783213 -0700
@@ -7,7 +7,7 @@
 # /proc/filesystems
 # /lib/modules/{kernel_name}/kernel/fs
 
-tempfile=`tempfile`
+tempfile=`mktemp`
  cat /proc/filesystems | while read type fs; do
 [ -z "$fs" ] && type=$fs
 echo $fs >>$tempfile
--- /home/francois/genmsgidx	2020-05-26 19:20:49.986572502 -0700
+++ util/genmsgidx	2020-05-26 19:20:32.802123675 -0700
@@ -79,8 +79,8 @@
 # Setup a tempfile
 [ -n "$TMPDIR" ] && TMPDIR=/tmp/
 tempfile=""
-if [ -n "`which tempfile`" ] ; then
-tempfile=`tempfile`
+if [ -n "`which mktemp`" ] ; then
+tempfile=`mktemp`
 fi
 [ -z "$tempfile" ] && tempfile=$TMPDIR/te.$$
 [ ! -e $tempfile ] && >$tempfile

Bug#767465: hello

[Gabriel Bertrand]

-- 
Bonjour

J'espère que vous allez bien. je m'appelle Gabriel. Nous pouvons être amis
J'ai des informations importantes que je voudrais partager avec vous

Passez une bonne journée

Cordialement,
Gabriel

Bug#961673: [PATCH] Do not load XSM policy in non XSM boot options

[Ian Jackson]

Package: grub2
Version: 2.04-7
Tags: patch

Hi.  Please find a followup patch to my recently-incorporated MR
  https://salsa.debian.org/grub-team/grub/-/merge_requests/18
Sorry about this.  I have only just discovered this wrinkle.

For a fuller explanation of this slightly suboptimal situation, see
this posting of mine to the xen-devel list and various Xen folks:
  https://lists.xenproject.org/archives/html/xen-devel/2020-05/msg01710.html

Thanks,
Ian.

>From 143c0b32f7db83ca63bb80b9bd9486dd62dffc71 Mon Sep 17 00:00:00 2001
From: Ian Jackson 
Date: Wed, 27 May 2020 17:00:45 +0100
Subject: [PATCH] 20_linux_xen: Do not load XSM policy in non-XSM options

For complicated reasons, even if you have XSM/FLASK disabled (as is
the default) the Xen build system still builds a policy file and puts
it in /boot.

Even so, we shouldn't be loading this in the usual non-"XSM enabled"
entries.  It doesn't do any particular harm but it is quite confusing.

Signed-off-by: Ian Jackson 
---
 util/grub.d/20_linux_xen.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index 7a092b898..cbad5f95a 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -173,7 +173,7 @@ EOF
${module_loader}--nounzip   $(echo $initrd_path)
 EOF
   fi
-  if test -n "${xenpolicy}" ; then
+  if ${xsm} && test -n "${xenpolicy}" ; then
 message="$(gettext_printf "Loading XSM policy ...")"
 sed "s/^/$submenu_indentation/" << EOF
echo'$(echo "$message" | grub_quote)'
-- 
2.20.1


-- 
Ian JacksonThese opinions are my own.  

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

Bug#961672: charset files not installed in a mysql-safe location

[Paride Legovini]

Package: mariadb-server-core-10.3
Version: 1:10.3.22-1

mariadb-server-core-10.3 installs the mariadb charset files in
/usr/share/mysql:

$ dpkg -L mariadb-server-core-10.3 | grep charset
/usr/share/mysql/charsets
/usr/share/mysql/charsets/Index.xml
/usr/share/mysql/charsets/README
/usr/share/mysql/charsets/armscii8.xml
/usr/share/mysql/charsets/ascii.xml
[...]
/usr/share/mysql/charsets/swe7.xml

The location of these files causes the libmysqlclient20 client library
to consider them charset files from mysql, and it tries to use them.

I think this behavior is wrong, as the charset files do not belong to
mysql, however it is not immediately causing user-visible issues.

Things are worse with mysql-8.0, not yet in Debian but packaged in
Ubuntu. In mysql-8.0 the charset file format is not compatible with the
older versions, and this causes the client library to segfault when
trying to use the charset files from mariadb.

Relevant Ubuntu bug:

https://bugs.launchpad.net/ubuntu/+source/mysql-8.0/+bug/1877504

I'm not sure of the best way to fix this, maybe mariadb needs to use the
/usr/share/mariadb namespace for its resources.

Paride

Bug#961671: Renaming crypttab mapping

[Ed Schaller]

Package: cryptsetup-initramfs

Every time I see bug #671037 referenced in the docs (README.initramfs.gz)
or do a rename I feel bad. When I first encountered this long before the
bug was submitted I found a easier/safer way. Sorry for not responding till
now.

if you have

old_name   /dev/... none luks

and you want new_name instead, modify your crypttab

new_name /dev/... none luks

rename the mapping

dmsetup rename old_name new_name

update the initramfs

update-initramfs -uk all

done.

As far as the currently booted system goes, it already sees the new names,
so a reboot is actually optional. I would recommend a reboot though as
you'd likely rather find out now that you have a problem than the next time
the power goes out.

Sorry I didn't send this nearly a decade sooner. Thanks for the fantastic
initram(rd/fs) support provided in Debian.

>>>-->

Bug#584776: fig2ps: errors due to strange characters with --forcespecial option

[Luis Paulo Linares]

Several tests were performed and no errors were found.

Feel free to reopen this bug.

Best,
Luis Paulo

Bug#961669: ITP: gftl-shared -- Common gFTL containers for Fortran intrinsic types

[Alastair McKinstry]

Hi Ole

Definitely willing to help.

Best regards

Alastair

On 27/05/2020 16:45, Ole Streicher wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ole Streicher 
> X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
> Control: block 961667 by -1
> Control: block 961668 by -1
>
> * Package name: gftl-shared
>   Version : 0.9.5
>   Upstream Author : Tom Clune
> * URL : https://github.com/Goddard-Fortran-Ecosystem/
> * License : Apache
>   Language: Fortran 90
>   Description : Common gFTL containers for Fortran intrinsic types
>
> This is a dependency of pfunit. The package will be maintained in
> the DebianScience Team, the repository is
>
> https://salsa.debian.org/science-team/gftl-shared
>
> This is Fortran 90, where I am quite unexperienced. I'd appreciate if
> someone could have a look on how to organize the package structure
> (modules? libs?) and give me hints.
>
> Best regards
>
> Ole
>
-- 
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered. 

Bug#961670: ITP: gftl -- Containers and iterators for Fortran

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
Control: block 961667 by -1
Control: block 961668 by -1
Control: block 961669 by -1

* Package name: gftl
  Version : 1.2.5
  Upstream Author : Tom Clune
* URL : https://github.com/Goddard-Fortran-Ecosystem/gFTL
* License : Apache
  Language: Fortran 90
  Description : Containers and iterators for Fortran

gFTL provides a mechanism to easily create robust containers and
associated iterators which can be used within Fortran applications.
The primary methods are intended to be as close to their C++ STL
analogs as possible. These containers are a powerful productivity
multiplier for certain types of software development.

This is a dependency of pfunit. The package will be maintained in
the DebianScience Team, the repository is

https://salsa.debian.org/science-team/gftl

This is Fortran 90, where I am quite unexperienced. I'd appreciate if
someone could have a look on how to organize the package structure
(modules? libs?) and give me hints.

Best regards

Ole

Bug#961669: ITP: gftl-shared -- Common gFTL containers for Fortran intrinsic types

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
Control: block 961667 by -1
Control: block 961668 by -1

* Package name: gftl-shared
  Version : 0.9.5
  Upstream Author : Tom Clune
* URL : https://github.com/Goddard-Fortran-Ecosystem/
* License : Apache
  Language: Fortran 90
  Description : Common gFTL containers for Fortran intrinsic types

This is a dependency of pfunit. The package will be maintained in
the DebianScience Team, the repository is

https://salsa.debian.org/science-team/gftl-shared

This is Fortran 90, where I am quite unexperienced. I'd appreciate if
someone could have a look on how to organize the package structure
(modules? libs?) and give me hints.

Best regards

Ole

Bug#960571: rst2pdf: Bad dependency on "fontconfing"

[Daniel Serpell]

Package: rst2pdf
Version: 0.97-1
Followup-For: Bug #960571

The last upload clearly was not tested, as it now depends on the
misspelled package "fontconfing".

New package is uninstallable.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rst2pdf depends on:
ii  python33.8.2-3
ii  python3-docutils   0.16+dfsg-2
ii  python3-jinja2 2.11.1-1
ii  python3-pdfrw  0.4-2.1
ii  python3-pkg-resources  46.1.3-1
ii  python3-pygments   2.3.1+dfsg-3
ii  python3-reportlab  3.5.34-1
ii  python3-setuptools 46.1.3-1
ii  python3-simplejson 3.17.0-1
ii  python3-six1.15.0-1
ii  python3-smartypants2.0.0-2

rst2pdf recommends no packages.

Versions of packages rst2pdf suggests:
pn  python3-aafigure  
ii  python3-matplotlib3.2.1-1+b1
ii  python3-pil   7.0.0-4+b1
pn  python3-sphinx
pn  python3-uniconvertor  

-- no debconf information

Bug#436466: dash: Please optimise single command given to -c to exec it

[Jonathan Nieder]

Herbert Xu wrote:
>> Tim Connors wrote:

>>> Because of bug #642922 (archived, but has some interesting discussion),
>>> this patch for this bug ended up being backed out.
[...]
> I gather that the ocamlbuild bug has been fixed so can this be
> reinstated please?

Curious: the ocamlbuild bug appears to still be open upstream
, but
https://github.com/ocaml/ocamlbuild/commit/00e05f686e15b07ac4268fcd10cf3738a5c28467
was applied with the proposed fix in ocamlbuild 0.9.0.

I suspect this means that the ocamlbuild bug was indeed fixed, and
that we should be able to reinstate the patch.

Except...  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642835;msg=55
says the bug is present in ocamlbuild 0.10.1.  Ximin, do you remember
where that version number came from?  Is it possible that the bug is
*not* present in that version?

Thanks,
Jonathan

Bug#961668: ITP: fargparse -- Command line argument parsing for Fortran

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
Control: block 961667 by -1

* Package name: fargparse
  Version : 0.9.5
  Upstream Author : Tom Clune
* URL : https://github.com/Goddard-Fortran-Ecosystem/fArgParse
* License : NASA
  Language: Fortran 90
  Description : Command line argument parsing for Fortran

This is a dependency of pfunit. The package will be maintained in
the DebianScience Team, the repository is

https://salsa.debian.org/science-team/pfunit

This is Fortran 90, where I am quite unexperienced. I'd appreciate if
someone could have a look on how to organize the package structure
(modules? libs?) and give me hints.

Best regards

Ole

Bug#961667: ITP: pfunit -- Parallel Fortran Unit Testing Framework

[Ole Streicher]

Package: wnpp
Severity: wishlist
Owner: Ole Streicher 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org

* Package name: pfunit
  Version : 4.1.8
  Upstream Author : Tom Clune
* URL : https://github.com/Goddard-Fortran-Ecosystem/pFUnit
* License : NASA
  Language: Fortran 90
  Description : Parallel Fortran Unit Testing Framework

pFUnit is a unit testing framework enabling JUnit-like testing of
serial and MPI-parallel software written in Fortran. Limited suport
for OpenMP is also provided in the form of managing exceptions in a
thread-safe manner.

The package will be maintained in the Debian Science Team, the repository is

https://salsa.debian.org/science-team/pfunit

This is Fortran 90, where I am quite unexperienced. I'd appreciate if
someone could have a look on how to organize the package structure
(modules? libs?) and give me hints.

Best regards

Ole

Bug#928813: libapache2-mod-jk: Jk can not find any configured worker

[Thorsten Glaser]

Package: libapache2-mod-jk
Version: 1:1.2.46-1
Followup-For: Bug #928813
Control: severity -1 serious
Control: notfound -1 1:1.2.46-0+deb9u1
Control: found -1 1:1.2.46-1

Indeed, this prevents libapache2-mod-jk from working at all in buster.

Comparing (“dpkg -L libapache2-mod-jk | sort | less”) betweeen stretch
(1:1.2.46-0+deb9u1) and buster (1:1.2.46-1) shows:

(stretch) (buster)
/./.
/etc  /etc
/etc/apache2  /etc/apache2
/etc/apache2/mods-available   
/etc/apache2/mods-available
/etc/apache2/mods-available/jk.conf   
/etc/apache2/mods-available/httpd-jk.conf
/etc/apache2/mods-available/jk.load   
/etc/apache2/mods-available/jk.load
/etc/libapache2-mod-jk/etc/libapache2-mod-jk
/etc/libapache2-mod-jk/httpd-jk.conf  
/etc/libapache2-mod-jk/httpd-jk.conf
/etc/libapache2-mod-jk/workers.properties 
/etc/libapache2-mod-jk/workers.properties
/usr  /usr
/usr/lib  /usr/lib
/usr/lib/apache2  /usr/lib/apache2
/usr/lib/apache2/modules  /usr/lib/apache2/modules
/usr/lib/apache2/modules/mod_jk.so
/usr/lib/apache2/modules/mod_jk.so
/usr/share/usr/share
/usr/share/doc/usr/share/doc
/usr/share/doc/libapache2-mod-jk  
/usr/share/doc/libapache2-mod-jk
/usr/share/doc/libapache2-mod-jk/NEWS.Debian.gz
/usr/share/doc/libapache2-mod-jk/README.Debian
/usr/share/doc/libapache2-mod-jk/README.Debian
/usr/share/doc/libapache2-mod-jk/changelog.Debian.gz  
/usr/share/doc/libapache2-mod-jk/changelog.Debian.gz
/usr/share/doc/libapache2-mod-jk/copyright
/usr/share/doc/libapache2-mod-jk/copyright


Note this difference:
/etc/apache2/mods-available/jk.conf (stretch) vs.
/etc/apache2/mods-available/httpd-jk.conf

In stretch, an “a2enmod jk” will enable mods-available/jk.conf
and make things work.

From reading the changelog, you wanted to “Install new httpd-jk.conf
file which follows Apache 2.4 syntax”, but the directory is wrong;
these files belong into conf-available, not mods-available.

That being said, that would require both “a2enmod jk” *and*
“a2enconf httpd-jk”, which is a UI regression against earlier,
so I’d prefer for the file to be renamed back to what it was
in stretch over moving it to another directory.


⚠ I intend to team-upload the fix if not done within the week. ⚠


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

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

Versions of packages libapache2-mod-jk depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.38-3+deb10u3
ii  libc6   2.28-10

libapache2-mod-jk recommends no packages.

Versions of packages libapache2-mod-jk suggests:
pn  libapache-mod-jk-doc  
ii  tomcat8   8.5.54-0+deb9u1

-- no debconf information

Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Matthew Fernandez]

> On May 27, 2020, at 08:15, Vasyl Gello  wrote:
> 
> Hi Matthew!
> 
> Thanks for the continued review! You read my mind now?)
> 
> >
> >Now that I read the remainder of the main source file, I spotted a 
> >completely separate issue, src/cryptopass.c:375-384 [1]:
> >
> > /* Clean up everything */
> >
> > for (counter = 0; counter < 10; counter++) {
> > memset(derivedpassword, 0, PASSWORD_BUFFER_SIZE);
> > memset(domain, 0, MAX_INPUT_SIZE);
> > memset(masterpassword, 0, MAX_INPUT_SIZE);
> > memset(passlenbuf, 0, PASSWORD_LENGTH_BUFFER_SIZE);
> > memset(salt, 0, SALT_BUFFER_SIZE);
> > memset(username, 0, MAX_INPUT_SIZE);
> > }
> >
> >This does not do what you think it does. Either these duplicated memsets are 
> >redundant or the compiler will optimize them all away observing the targets 
> >are unused after this. The way to erase something in a way the compiler 
> >cannot elide is a single memset_s(). However, the program is about to exit 
> >and be torn down by the operating system, so even this would be redundant.
> >
> >Your intent (I am guessing) is to prevent an attacker reading these values 
> >out of program memory. However, an attacker with this ability can simply 
> >ptrace cryptopass or attach to it with a debugger. I think some thought 
> >should be put into the threat model for this program and it should probably 
> >have a more thorough security review before it is packaged.
> 
> The threat model is obviously not against an attacker with live root or 
> hypervisor access. Rather not to leave unwanted things for possible cold-boot 
> attacks.

The capabilities of a post-reboot userspace attacker are not affected by these 
measures.

> Thanks for mentioning memset_s. I see it is C11-specific so if I target older 
> standard on source level, I will have to do cleanup manually.
> -- 
> Vasyl Gello

Bug#958479: qmake passes unsupported -isystem to gcc

[Dmitry Shachnev]

Hi Helmut!

On Wed, Apr 22, 2020 at 08:39:16PM +0200, Helmut Grohne wrote:
> The context of this bug is #798955 aka moving glibc headers from
> /usr/include to /usr/include/. When doing this, some packages
> FTBFS with the symptom that  or  fail to find
> #include_next  or #include_next  respectively. The
> cause is passing -isystem /usr/include/ to the compiler. I
> asked libstdc++ upstream to fix this, but the reply was that passing
> this flag is unsupported (see bug log of #798955). The takeaway is:
> Pass -isystem /usr/include or -isystem /usr/include/ is broken.
>
> Unfortunately, qmake does exactly that.
> [...]
>
> I can also propose a solution. When constructing INCPATH, any directory
> that directly is a compiler search directory (not a subdirectory
> thereof), the directory should be skipped. Doing so ensures that the
> order of compiler search directories is not changed. The possible harm
> seems quite limited given that the compiler will already search these
> directories (just in the correct order).
>
> What do you think?

I think your patch makes sense.

Can I ask you to forward it to upstream Gerrit [1] (see [2] for the
instruction)? Unfortunately, upstream requires the patch author to sign a
CLA so I cannot easily forward it under my account. Alternatively, you may
publicly state that you license your patch under a permissive license
(e.g. BSD), which should also work (but upstream does not like this much).

In case you agree to forward it, please also fix the indentation, it should
not contain tabs.

[1]: https://codereview.qt-project.org/
[2]: https://wiki.qt.io/Gerrit_Introduction

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Vasyl Gello]

Hi Matthew!

Thanks for the continued review! You read my mind now?)

>
>Now that I read the remainder of the main source file, I spotted a completely 
>separate issue, src/cryptopass.c:375-384 [1]:
>
>/* Clean up everything */
>
>for (counter = 0; counter < 10; counter++) {
>  memset(derivedpassword, 0, PASSWORD_BUFFER_SIZE);
>  memset(domain, 0, MAX_INPUT_SIZE);
>  memset(masterpassword, 0, MAX_INPUT_SIZE);
>  memset(passlenbuf, 0, PASSWORD_LENGTH_BUFFER_SIZE);
>  memset(salt, 0, SALT_BUFFER_SIZE);
>  memset(username, 0, MAX_INPUT_SIZE);
>}
>
>This does not do what you think it does. Either these duplicated memsets are 
>redundant or the compiler will optimize them all away observing the targets 
>are unused after this. The way to erase something in a way the compiler cannot 
>elide is a single memset_s(). However, the program is about to exit and be 
>torn down by the operating system, so even this would be redundant.
>
>Your intent (I am guessing) is to prevent an attacker reading these values out 
>of program memory. However, an attacker with this ability can simply ptrace 
>cryptopass or attach to it with a debugger. I think some thought should be put 
>into the threat model for this program and it should probably have a more 
>thorough security review before it is packaged.

The threat model is obviously not against an attacker with live root or 
hypervisor access. Rather not to leave unwanted things for possible cold-boot 
attacks.

Thanks for mentioning memset_s. I see it is C11-specific so if I target older 
standard on source level, I will have to do cleanup manually.
-- 
Vasyl Gello

Bug#959675: libgrpc++1: endless looping with default settings

[GCS]

Control: tags -1 +pending

On Wed, May 27, 2020 at 4:42 PM Thomas Goirand  wrote:
> Any progress on this? I've been watching this bug activity, and
> nothing's happening. I'm worried for my packages removal in Bullseye
> (ie: most of OpenStack...).
Quoting the package tracker: "grpc is marked for autoremoval from
testing on 2020-06-23" which is almost a month away.
Then Benjamin uploaded Abseil and it's in NEW [1] and I've updated
gRPC and it's also in NEW [2] waiting for Abseil at first. Hope FTP
Masters will clear both packages soon to the archives.
In short, don't worry for the time being.

Regards,
Laszlo/GCS
[1] https://ftp-master.debian.org/new/abseil_0~20200225.2-1.html
[2] https://ftp-master.debian.org/new/grpc_1.29.1-1.html

Bug#961639: util-linux: FTBFS with uname26 error on glibc >= 2.30

[Helge Deller]

On 27.05.20 01:45, Chris Hofstaedtler wrote:
> Please resubmit the patch with upstreams requirements...

Clean-up patch is attached.

Thanks!
Helge
[PATCH] Fix uname26 testcases for glibc >= 2.30

On architectures which already run glibc >= 2.30 the uname26 testcases fail.

The tests/ts/misc/setarch testcase is wrong:
$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> $TS_ERRLOG

Errors are written to $TS_ERRLOG, while OK'ed output is written to $TS_OUTPUT.
With glibc >= 2.30 you get "FATAL: kernel too old", older glibc report "2.6 worked".

But a few lines later in the script we have:
  sed -i "$ s/$expected/2.6 works or kernel too old/" $TS_OUTPUT
which only replaces the text in $TS_OUTPUT (and ignores $TS_ERRLOG).

Changing
$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> $TS_ERRLOG
to
$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> $TS_OUTPUT
fixes the uname26 tests.

Signed-off-by: Helge Deller 
Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961639

diff -up ./tests/ts/misc/setarch.org ./tests/ts/misc/setarch
--- ./tests/ts/misc/setarch.org	2020-05-26 22:27:49.173547933 +
+++ ./tests/ts/misc/setarch	2020-05-26 22:25:49.230293192 +
@@ -45,7 +45,7 @@ ts_init_subtest uname26
 finmsg="" # for debugging 2.6 issues

 echo "## --uname-2.6 echo" >>$TS_OUTPUT
-$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> $TS_ERRLOG
+$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> $TS_OUTPUT
 if [ $? -eq 0 ]; then
 	expected='^2.6 worked$'
 else
@@ -56,7 +56,7 @@ fi
 sed -i "$ s/$expected/2.6 works or kernel too old/" $TS_OUTPUT

 echo "## --uname-2.6 true, non-verbose" >>$TS_OUTPUT
-$TS_CMD_SETARCH $ARCH --uname-2.6 true >> $TS_OUTPUT 2>> $TS_ERRLOG
+$TS_CMD_SETARCH $ARCH --uname-2.6 true >> $TS_OUTPUT 2>> $TS_OUTPUT
 if [ $? -eq 0 ]; then
 	echo "2.6 works or kernel too old" >> $TS_OUTPUT
 else

Bug#922877: boolector: new upstream version (3.1.0) (now MIT licensed)

[Kurt Roeckx]

On Thu, Feb 21, 2019 at 05:33:25PM +0100, Celelibi wrote:
> Package: boolector
> Version: 1.5.118.6b56be4.121013-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> Could you please consider upgrading the packaged version of boolector?
> I guess it was frozen to version 1.5.118 because of the license change.
> But the version 3.0 is now under the MIT license, which is
> Debian-compatible AFAIK.

Any update on this? The latest version is 3.2.1 in the mean time,
while we're stuck on a version from 2012.


Kurt

Bug#961206: improve sphinx usage for cross building

[Dmitry Shachnev]

On Tue, May 26, 2020 at 07:42:30PM +0200, Helmut Grohne wrote:
> > It would be nice to have a better estimate of how many packages can be
> > fixed in an automated way in DPMT [1], how many packages cannot be fixed
> > at all (e.g. because they use sphinx from Python interface) and how many
> > packages are remaining.
>
> Given that many packages use python3 -m sphinx now, the breakage would
> be quite small actually. Using python3 -m sphinx would continue to just
> work after the split (though it would still break cross building). So I
> guess, we can simply remove DPMT from the calculation.

If we can fix cross building in DPMT in an automated way, then why not do it?
Of course it is not the first priority, we can do it after fixing all other
packages.

> > The first step (making python3-sphinx provide sphinx) is zero cost, so
> > I can do it quite soon.
>
> Doing so enables depending on sphinx, but python3-sphinx and sphinx
> actually need to be distinct packages, because sphinx should become
> Multi-Arch: foreign while python3-sphinx should not. You cannot express
> that using Provides.

But the actual split is the last step (4th in your message). So at the first
step I just add Provides and don't split anything. Right?

> > Do you know what is the process of switching from update-alternatives
> > to directly shipping the symlink? Can I just drop the postinst/postrm
> > scripts and add that symlink, or I need to somehow unregister the
> > alternative when the package is upgraded?
>
> I think you need to actually declare Conflicts (not just Breaks and
> Replaces) on any alternative (i.e. python-sphinx). Then, you'd remove
> the alternative in preinst (like you do in prerm already) and unpacking
> the symlinks should work.

Can you please quickly look at this commit and say if it makes sense to you?

https://salsa.debian.org/python-team/modules/sphinx/-/commit/c51e0ad4908bb7d6

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#961666: gnucobol: Please make another source-only upload to allow testing migration

[Boyuan Yang]

Source: gnucobol
Severity: important
Version: 3.0~rc1-1
X-Debbugs-CC: a...@debian.org


Dear Debian gnucobol maintainer,

Your latest upload gnucobol/3.0~rc1-1 was not a source-
only upload; as a result, this package will not migrate to Testing.
Since July 2019, only source-only uploads are allowed to migrate to
Testing in Debian.

According to 
https://lists.debian.org/debian-devel-announce/2020/02/msg5.html ,
if such condition lasts for more than 60 days, this bug will be
considered as release-critical. Your package has been unable to migrate
for 29 days now.

Please rebuild your package and make another source-only upload. You
may find more information about source-only upload at 
https://wiki.debian.org/SourceOnlyUpload .


-- 
Regards,
Boyuan Yang


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

Bug#961665: ITP: lighter -- fast and memory-efficient sequencing error corrector

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: lighter -- fast and memory-efficient sequencing error corrector
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: lighter
  Version : 1.1.2
  Upstream Author : Li Song, Liliana Florea and Ben Langmead
* URL : https://github.com/mourisl/Lighter
* License : GPL-3
  Programming Lang: C
  Description : fast and memory-efficient sequencing error corrector
 Lighter is a fast, memory-efficient tool for correcting sequencing
 errors. Lighter avoids counting k-mers. Instead, it uses a pair of Bloom
 filters, one holding a sample of the input k-mers and the other holding
 k-mers likely to be correct. As long as the sampling fraction is
 adjusted in inverse proportion to the depth of sequencing, Bloom filter
 size can be held constant while maintaining near-constant accuracy.
 Lighter is parallelized, uses no secondary storage, and is both faster
 and more memory-efficient than competing approaches while achieving
 comparable accuracy.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/lighter

Bug#959675: libgrpc++1: endless looping with default settings

[Thomas Goirand]

Hi Benjamin,

Any progress on this? I've been watching this bug activity, and
nothing's happening. I'm worried for my packages removal in Bullseye
(ie: most of OpenStack...).

Cheers,

Thomas Goirand (zigo)

Bug#961664: mailscripts: add a Homepage: field that points to https://git.spwhitton.name/mailscripts

[Daniel Kahn Gillmor]

Package: mailscripts
Version: 0.20-1
Severity: wishlist
Tags: patch

Please add a Homepage: field for mailscripts!

--dkg

From b03bae0bdae8f1f669270a056b7823b5e59998bb Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Wed, 27 May 2020 10:32:39 -0400
Subject: [PATCH] d/control: add Homepage field

If mailscripts ever grows a proper webpage that's not just a Vcs, we
can change the Homepage: field to point to it at that time.  In the
meantime, point to the most visible web resource available to the
project.

It's redundant with the Vcs-Browser: field, but this is still useful
for anyone who is searching just the Homepage: fields for information
about the projects in debian.

Signed-off-by: Daniel Kahn Gillmor 
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index 739d073..3a549a3 100644
--- a/debian/control
+++ b/debian/control
@@ -19,6 +19,7 @@ Build-Depends:
  python3-pgpy ,
 Vcs-Git: https://git.spwhitton.name/mailscripts
 Vcs-Browser: https://git.spwhitton.name/mailscripts
+Homepage: https://git.spwhitton.name/mailscripts
 
 Package: elpa-mailscripts
 Architecture: all
-- 
2.26.2



signature.asc
Description: PGP signature

Bug#961661: How to deal with lintian warning "incorrect-path-for-interpreter" properly (Was: Bug#961661: ITP: samclip -- filter SAM file for soft and hard clipped alignments)

[gregor herrmann]

On Wed, 27 May 2020 13:50:17 +0200, Andreas Tille wrote:

> I'm freqently stumbling upon things like
> 
>   W: samclip: incorrect-path-for-interpreter usr/bin/samclip (#!/usr/bin/env 
> perl != /usr/bin/perl)
> 
> and my usual way to deal with this was firing up sed in d/rules.  However,
> I can not imagine that you have a more clever way how to deal with this.
> Any hint how I can do this more elegantly?

We're also using sed, typically:

% cat libtext-simpletable-perl/debian/rules
#!/usr/bin/make -f

PACKAGE = $(shell dh_listpackages)
TMP = $(CURDIR)/debian/$(PACKAGE)

%:
dh $@

override_dh_installexamples:
dh_installexamples
sed -i '1s|^#!/usr/bin/env perl|#!/usr/bin/perl|' 
$(TMP)/usr/share/doc/$(PACKAGE)/examples/*


or

% cat zonemaster-cli/debian/rules
#!/usr/bin/make -f

PACKAGE = $(shell dh_listpackages)
TMP = $(CURDIR)/debian/$(PACKAGE)

%:
dh $@

override_dh_install:
dh_install
sed -i '1s|^#!/usr/bin/env perl|#!/usr/bin/perl|' 
$(TMP)/usr/bin/$(PACKAGE)


> Moreover some kind review of this pure Perl package would be nice.

(Not from me today.)
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Rolling Stones: Sympathy for the Devil


signature.asc
Description: Digital Signature

Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

[Junchao Zhang]

On Wed, May 27, 2020 at 12:09 AM Drew Parsons  wrote:

> On 2020-05-24 10:01, Drew Parsons wrote:
> > On 2020-05-23 23:45, Satish Balay wrote:
> >>
> >> One more issue: Most externalpackages don't support 64bit-indices.
> ...
> >> We haven't tried using MUMPS in this mode with PETSc
> >
> > This will be the interesting test. I'll start with the 64-bit build of
> > MUMPS and see how tests hold up.
>
>
> The PETSc mumps tests seem to be robust with respect to 64 bit.
> (64 bit MUMPS in the form of -DPORD_INTSIZE64, not all-integer
> -DINTSIZE64)
>
> That is, 32 bit PETSc passes its tests with 64 bit (PORD) MUMPS
> and 64 bit PETSc passes its tests with 32 bit MUMPS.
>
> The test in question that's passing is src/snes/tutorials/ex19, run with
> 'make runex19_fieldsplit_mumps'
> Perhaps it's not stress-testing 64 bit conditions.
>
Could you provide more details, e.g., the error stack trace?


>
> Drew
>

Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

[Matthew Fernandez]

> On May 26, 2020, at 23:46, Vasyl Gello  wrote:
> 
> Hi Matthew!
> 
>> I would suggest adding one as well as fuzzing this code before exposing the 
>> downstream public to it.
> 
> Will fix the issues and add testsuite && fuzzcorp ASAP.
> 
> BTW I fixed all the stuff GCC 8.3.0 reported me with FORTIFY_SOURCE=2 before 
> pushing code to GitHub.
> Did you use GCC 10?

I just used manual inspection to identify this.

Now that I read the remainder of the main source file, I spotted a completely 
separate issue, src/cryptopass.c:375-384 [1]:

/* Clean up everything */

for (counter = 0; counter < 10; counter++) {
  memset(derivedpassword, 0, PASSWORD_BUFFER_SIZE);
  memset(domain, 0, MAX_INPUT_SIZE);
  memset(masterpassword, 0, MAX_INPUT_SIZE);
  memset(passlenbuf, 0, PASSWORD_LENGTH_BUFFER_SIZE);
  memset(salt, 0, SALT_BUFFER_SIZE);
  memset(username, 0, MAX_INPUT_SIZE);
}

This does not do what you think it does. Either these duplicated memsets are 
redundant or the compiler will optimize them all away observing the targets are 
unused after this. The way to erase something in a way the compiler cannot 
elide is a single memset_s(). However, the program is about to exit and be torn 
down by the operating system, so even this would be redundant.

Your intent (I am guessing) is to prevent an attacker reading these values out 
of program memory. However, an attacker with this ability can simply ptrace 
cryptopass or attach to it with a debugger. I think some thought should be put 
into the threat model for this program and it should probably have a more 
thorough security review before it is packaged.

  [1]: 
https://github.com/basilgello/cryptopass/blob/master/src/cryptopass.c#L375-L384 

Bug#932081: sogo/sope: Unable to connect to a remote IMAP server

[Bastian Germann]

I created a merge request from Nicolas's patch which
applies cleanly to sope's current sid and buster versions:
https://salsa.debian.org/debian/sope/-/merge_requests/1

Bug#801858: GLUI

[Miriam Ruiz]

I have prepared some GLUI packages, initially for my own usage, but if
there might be interest in them, they are available at
http://miriamruiz.es/debian/glui/

Greetings,
Miry

Bug#961663: Firefox ESR crashes on pre-SSE2 CPUs

[Frank]

Package: firefox-esr
Version: 68.8.0esr-1~deb10u1
Severity: important

Firefox ESR (i386) crashes on pre-SSE2 CPUs when visiting certain 
websites such as xfce-look.org.
As far as I understand Debian stretch/buster firefox-esr package should 
support processors without SSE2.
Older versions of the firefox-esr package had similar issues and were 
(apparently) fixed.


If this issue/bug is unfixable (I hope not!) package should depend on 
package sse2-support (i386 only).
Upstream doesn't support pre-SSE2 processors anymore, some parts of the 
source code assume SSE2 unconditionally.


Versions tested:
- 68.8.0esr-1~deb10u1 (buster): crashes: SIGSEGV due to SSE2 instruction 
MOVQ
- 68.8.0esr-1~deb9u1 (stretch): crashes: SIGSEGV due to SSE instruction 
LDMXCSR (weird, SSE is supported by CPU)
- 60.9.0esr-1~deb9u1 (stretch): crashes: SIGILL (Illegal instruction) 
due to SSE2 instruction MOVQ
- 60.6.3esr-1~deb9u1 (stretch): crashes: SIGILL (Illegal instruction) 
due to SSE2 instruction MOVQ
- 60.2.0esr-1~deb9u2.2 (stretch, from #908449): SIGILL (Illegal 
instruction) due to SSE2 instruction MOVQ


References:
- #908449 (no subject): 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908449
- #877445 Certain sites crash Firefox on pre-SSE2 CPUs: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877445
- #908396 firefox-esr: stopped working after upgrade from 59 to 60: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908396


Info:
$ firefox -v
Mozilla Firefox 68.8.0esr
$ firefox
[Parent 4798, Gecko_IOThread] WARNING: pipe error (84): Connection reset 
by peer: file 
/build/firefox-esr-lGgo0c/firefox-esr-68.8.0esr/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, 
line 358
[Parent 4798, Gecko_IOThread] WARNING: pipe error (82): Connection reset 
by peer: file 
/build/firefox-esr-lGgo0c/firefox-esr-68.8.0esr/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, 
line 358


###!!! [Parent][MessageChannel] Error: 
(msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot 
send/recv
###!!! [Parent][MessageChannel] Error: 
(msgtype=0x1E0074,name=PBrowser::Msg_StopIMEStateManagement) Channel 
error: cannot send/recv
###!!! [Parent][MessageChannel] Error: 
(msgtype=0x1E008F,name=PBrowser::Msg_Destroy) Channel error: cannot 
send/recv


$ dmesg | tail -n2
[  361.271646] Web Content[4868]: segfault at b5aae898 ip b0666938 sp 
bfc45dec error 7 in libxul.so[aebb4000+439f000]
[  361.271669] Code: 10 89 74 24 14 83 c3 18 89 5c 24 10 5b 5e 5f e9 0e 
3c 02 00 66 90 66 90 66 90 66 90 66 90 66 90 66 90 8b 44 24 04 8b 54 24 
0c  0f 7e 02 66 0f d6 00 8b 54 24 08 8b 12 89 50 08 c7 40 0c 00 00



$ export MOZ_FORCE_DISABLE_E10S=1
$ gdb /usr/lib/firefox-esr/firefox-esr
GNU gdb (Debian 8.2.1-2+b3) 8.2.1

(gdb) run
Starting program: /usr/lib/firefox-esr/firefox-esr
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".

[Thread 0x9cf6ab40 (LWP 7037) exited]

Thread 1 "firefox-esr" received signal SIGSEGV, Segmentation fault.
0xb072d938 in ?? () from /usr/lib/firefox-esr/libxul.so
(gdb) bt full

(gdb) x/i $eip
=> 0xb072d938:   movq   (%edx),%xmm0
(gdb) set disassembly-flavor intel
(gdb) x/i 0xb072d938
=> 0xb072d938:   movq   xmm0,QWORD PTR [edx]

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 6
model   : 10
model name  : AMD Athlon(tm) XP 2400+
stepping: 0
cpu MHz : 2067.256
cache size  : 256 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fdiv_bug: no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow cpuid 3dnowprefetch 
vmmcall
bugs		: fxsave_leak sysret_ss_attrs spectre_v1 spectre_v2 
spec_store_bypass

bogomips: 4134.51
clflush size: 32
cache_alignment : 32
address sizes   : 34 bits physical, 32 bits virtual
power management: ts

Bug#961584: lxc-stop fails with exit code 1

[Inaki Malerba]

El 26/5/20 a las 23:35, Antonio Terceiro escribió:
> is there an easy/documented way of reproducing the salsa ci environment
> (i.e. lxc working under docker) locally? 

Attached is a Dockerfile. It should be sufficient to reproduce the problem.

Changing the FROM statement from debian:unstable to debian:testing is
enough to make it work. It needs to be run as privileged.

$ docker build -t autopkgtest - < Dockerfile
$ docker run --rm --privileged autopkgtest

-- 
- ina
FROM debian:unstable

ENV SALSA_CI_AUTOPKGTEST_LXC 
https://salsa.debian.org/salsa-ci-team/autopkgtest-lxc
ENV LXC_PATH /lxc

# Download and configure container.
RUN apt-get update && apt-get install -y wget
RUN wget --progress=dot:giga 
${SALSA_CI_AUTOPKGTEST_LXC}/-/jobs/artifacts/master/raw/artifacts/lxc.tar?job=stable
 -O lxc.tar
RUN mkdir ${LXC_PATH} && tar xf lxc.tar -C ${LXC_PATH}
RUN sed -i "/lxc.rootfs.path/ s@dir:.*/lxc/@dir:${LXC_PATH}/@" 
${LXC_PATH}/autopkgtest-stable-amd64/config

# Install lxc.
RUN apt-get update && apt-get install -y eatmydata
RUN eatmydata apt-get install -y lxc iptables

RUN echo "lxc.lxcpath=${LXC_PATH}" | tee -a /etc/lxc/lxc.conf
RUN echo 'USE_LXC_BRIDGE="true"' | tee /etc/default/lxc-net

RUN echo 'tmpfs /sys/fs/cgroup tmpfs rw,relatime,seclabel' | tee /etc/fstab
RUN echo 'cgroup /sys/fs/cgroup/cpuset cgroup rw,relatime,cpuset,x-mount.mkdir' 
| tee -a /etc/fstab
RUN echo 'cgroup /sys/fs/cgroup/devices cgroup 
rw,relatime,devices,x-mount.mkdir' | tee -a /etc/fstab

# This steps need to be run as privileged.
CMD umount -R /sys/fs/cgroup && mount -a && \
/etc/init.d/lxc-net start && \
/etc/init.d/lxc start && \
lxc-start autopkgtest-stable-amd64 && \
lxc-stop autopkgtest-stable-amd64 && \
echo "ok"


signature.asc
Description: OpenPGP digital signature

Bug#961377: raspi3-firmware: recent stable update causes non-booting systems

[Thorsten Glaser]

Hi Gunnar,

>VERY GOOD CATCH! Thanks a lot for this. I'm pushing it to Git right

you’re welcome.

>
> https://salsa.debian.org/debian/raspi-firmware/-/commit/2bf38f62de0514c2759f2c33d147c935e4d044bf

Note this caused unbootable RPi 3B+ systems, so it was actually a
severe regression wrt. the previous upload, not just the 0/2 ones.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#961029: Request for new mailing list: debian-ai

[Mattia Rizzolo]

On Wed, May 27, 2020 at 07:58:37PM +0900, Norbert Preining wrote:
> let me support this request.

I likewise want to support this request.

> Hitherto there is no dedicated ML for AI/ML, one of the most active
> areas. In Debian we should strive for better support of AI/ML tools!

I have several acquaintances studying or working on ML/AI stuff, and I'm
always flustered that nothing of what they need is already in Debian (or
if it is it's in a way that's useless to them).  I totally support any
kind of movement towards improving this area!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#949512: Bug#948793: NMU for xmlcopyeditor 1.2.1.3-4.1

[Miriam Ruiz]

Go ahead. Thanks for taking care of it.

Greetings,
Miry

El mié., 27 may. 2020 a las 14:21, Hugh McMaster
() escribió:
>
> Dear maintainer,
>
> I have prepared an NMU for xmlcopyeditor, fixing two bugs.
>
> I intend to upload the NMU to unstable in the next few days. Please
> let me know if you would like to fix these bugs yourself.
>
> Thank you,
>
> Hugh

Bug#961594: Connection failed [IP: 151.101.112.204 80]

[Julien Cristau]

On Tue, May 26, 2020 at 02:55:19PM +0200, Christoph Berg wrote:
> Package: mirrors,apt
> Severity: normal
> 
> On the apt.postgresql.org buildds, I've repeatedly seen failures when
> retrieving files from security.debian.org. It started a few weeks ago,
> and stopped when I reported the problem on #debian-mirrors on the 20th
> when jcristau modified some SRV records for the originating network.
> (The problem was seen from a Hetzner host in 78.46.0.0/15 aka
> HETZNER-RZ-NBG-BLK5).
> 
> Now the problem is back, this time from Hetzner 144.76.0.0/16
> HETZNER-RZ-BLK-ERX1.
> 
> 26 11:58  11:53:34 Err http://security.debian.org/debian-security 
> stretch/updates/main
> amd64 libldap-common all 2.4.44+dfsg-5+deb9u4
> 26 11:58  11:53:34   Connection failed [IP: 151.101.112.204 80]
> 26 11:58  jcristau: it happened again
> 26 11:59  this time from 144.76.0.0/16 HETZNER-RZ-BLK-ERX1
> 26 12:18  hmm there's 2 places apt seems to say "Connection 
> failed", one is closed
> connection while getting headers, i can't quite figure 
> out the other one
> 26 12:19  Myon: can you file a bug against mirrors,apt so we can 
> get input from the
> apt folks?  i'm not sure i can usefully escalate to 
> fastly just yet
> 26 14:46  if a bug with these two lines is enough, sure
> 26 14:46  curious why it's always that .deb, bad cache?
> 26 14:47  or maybe one bad backend?
> 26 14:49  yeah i don't know :/
> 
I wonder if turning on apt's Debug::Acquire::http would give more of a
clue on where things go wrong?  OTOH given this is highly intermittent
it'd be quite noisy...  Christoph, would you be able to give that a try?

Cheers,
Julien