date:20210305

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 7affc9ce4fca374a256f8195eea7800033d20a96 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 6 Mar 2021 03:19:19 +
>Subject: [PATCH] menu.c: Fix errors

  In case constructs:

  Use "break" as the last command in a case.

  Use /* FALLTHROUGH */, not a "goto default;" which does not function.

Signed-off-by: Bjarni Ingi Gislason 
---
 menu.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/menu.c b/menu.c
index 6ddb96f..90462c4 100644
--- a/menu.c
+++ b/menu.c
@@ -1485,10 +1485,8 @@ new_state:
 
case AC_REENTER_GROUP:
menu_return(ME_REENTER_GROUP);
- /* Previous command returns or "goto", but the compiler can't know that,
-so "break" is used to tell that */
-   break; /* avoid a "fallthrough" warning */
}
+   break; /* avoid a warning */
/* XXX: bug? fall */
 
case K_QUIT:
@@ -2412,8 +2410,9 @@ do_auto_read:
firsta = nexta;
goto redraw;
}
-   goto default; /* Uncertain code, avoid a warning */
+   /* FALLTHROUGH */ /* Avoids a warning */
/* XXX: fall? */
+
case MC_NEXTGROUP:
menu_cmd = ME_NEXT;
break;
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984633: additional info

2021-03-05 Thread Mathirajan S. Manoharan

chipset info : 
https://www.realtek.com/en/products/communications-network-ics/item/rtl8188ftv

Some forums (https://forums.linuxmint.com/viewtopic.php?t=295485) report that 
the driver for this device is here (https://github.com/kelebek333/rtl8188fu)

Bug#984633: firmware-realtek: RTL8188FTV realtek chipset does not work

2021-03-05 Thread Mathirajan S. Manoharan

Package: firmware-realtek
Version: 20201218-3
Severity: normal
X-Debbugs-Cc: mathi...@hotmail.com

Dear Maintainer,

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

   * What led up to the situation? i plugged in the usb realtek adapter to my
pc hoping to connect to internet via wifi. But this device is not recognized.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

lsusb -d 0bda:f179 -v  --> shows the following

Bus 001 Device 003: ID 0bda:f179 Realtek Semiconductor Corp. RTL8188FTV
802.11b/g/n 1T1R 2.4G WLAN Adapter
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass0
  bDeviceSubClass 0
  bDeviceProtocol 0
  bMaxPacketSize064
  idVendor   0x0bda Realtek Semiconductor Corp.
  idProduct  0xf179 RTL8188FTV 802.11b/g/n 1T1R 2.4G WLAN Adapter
  bcdDevice0.00
  iManufacturer   1 Realtek
  iProduct2 802.11n
  iSerial 3 002E2D5AF615
  bNumConfigurations  1

How ever "lshw -c network" does not show the wireless interface for this
device.
Device is not recognized. So, it can't be used for wifi connections.

   * What was the outcome of this action? Device not recognized
   * What outcome did you expect instead? Wireless network interface to show up
on my pc and enable me to connect to wifi network.

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


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

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

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

Versions of packages firmware-realtek suggests:
ii  initramfs-tools  0.139

Bug#984472: e2fsprogs: resize2fs on inconsistent filesystem (in a way that e2fsck doesn't detect) completely corrupts MMP data (in a way e2fsck can't recover from)

2021-03-05 Thread Theodore Ts'o

I can't reproduce the problem given your file system image.  Given
your description, this is almost certainly operator error.

> $ e2fsck -f   /dev/zvol/filling/store/nabijaczleweli/e2test
> e2fsck 1.46.2 (28-Feb-2021)
> e2fsck: MMP: e2fsck being run while checking MMP block
> MMP check failed: If you are sure the filesystem is not in use on any node, 
> run:
> 'tune2fs -f -E clear_mmp /dev/zvol/filling/store/nabijaczleweli/e2test'
> MMP_block:
> mmp_magic: 0x4d4d50
> mmp_check_interval: 10
> mmp_sequence: e24d4d50
> mmp_update_date: Wed Mar  3 14:51:38 2021
> mmp_update_time: 1614779498
> mmp_node_name: tarta
> mmp_device_name: /dev/zvol/filling/store/nabijacz

What this message means is that some *other* node was trying to run
fsck on the node at the same time as your e2fsck run.

The key in this message is 

MMP check failed: If you are sure the filesystem is not in use on any node, run:
  

When you then run 

'tune2fs -f -E clear_mmp /dev/zvol/filling/store/nabijaczleweli/e2test'

It forcibly clears the MMP block.  The MMP protects the file system
from simulatenous modification by more than one system.  Given that
you you had this file system on some kind of remote block device
(which presumably is why you were using the multi-mount protection
feature in the first place), forcibly overriding the MMP protection is
a bad thing.  It's the functional equivalent of turning off the gun's
safety, and then aiming the gun at your foot, and pulling the trigger.

> 
> $ tune2fs -f -E clear_mmp /dev/zvol/filling/store/nabijaczleweli/e2test
> tune2fs 1.46.2 (28-Feb-2021)
> 
> $ e2fsck -fy   /dev/zvol/filling/store/nabijaczleweli/e2test
> e2fsck 1.46.2 (28-Feb-2021)
> ext2fs_open2: Superblock checksum does not match superblock
> e2fsck: Superblock invalid, trying backup blocks...
> Superblock has invalid MMP magic.  Fix? yes

The bad checksum and the invalid MMP magic means that some other
system was also modifying the file system while tune2fs was clearing
the MMP block.

If I run the same set of commands in your logs after unpacking your image:

% unzstd rbd13.e2i.qcow2.zst
% e2image -r rbd13.e2i.qcow2 rbd13
% truncate -s 4T rbd13  # This "expands" the file to 4TB

... and then running the same set of commands using "rbd13" instead of
"/dev/zvol/filling/store/...", it works just fine.  But on the local
file, obviously there won't be any other system or node modifying the
file system, and there is no corruption.


I do see some problems in how resize2fs handles MMP devices.  In
particular resize2fs doesn't check the MMP block.  So if there is some
other process messing with the file system, the result can be file
system corruption.  But you really shouldn't have been trying to
resize the file system if someone else is trying to use the file
system.

And even if you do this, if you run "tune2fs -f -E clear_mmp ..." and
something else is using the file system, you're going to be doomed,
anyway.

I suppose we can add some "are you sure?  ARE YOU REALLY SURE?"
question to "tune2fs -f -E clear_mmp", and maybe even force the user
to type the string "I AGREE TO ASSUME RESPONSIBILITY FOR FILE SYSTEM
DESTRUCTION IF OTHER NODES ARE USING, MOUNTING, OR MODIFYING THE FILE
SYSTEM", but at the end of the day, there is only so much we can do
protect against PEBCAK failures

- Ted

Bug#984581: pst-utils: Fails to extract email addresses for emails having ARC headers from PST file

2021-03-05 Thread Paul Wise

Control: tags -1 + moreinfo

On Fri, 2021-03-05 at 23:06 +0530, sai kalyan wrote:

> Version: 0.6.71-0.1

Could you test version 0.6.75-1 from Debian bullseye?

> Tags: patch

Could you attach your patch to the bug report?

> for some mails where the transport headers contain ARC headers

Could you provide some information about what ARC headers are?

> the email addresses are not extracted from the PST and only usernames
> are available in the MIME content of emails that are extracted.

Please supply an example PST file that this problem occurs with.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#984632: menu.c: Add FALLTHROUGH to avoid warnings

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From deff7d2d59ed063e24aea5be2a1ad329dd5a0b45 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 6 Mar 2021 02:24:24 +
>Subject: [PATCH] menu.c: Add FALLTHROUGH to avoid warnings

  In case constructs:

  Add several "/* FALLTHROUGH */ /* to avoid a warning */".

  Add a "return 0;" after a returning function, to avoid a warning.

  Add information to the output of a "sys_error(...)" function.

Signed-off-by: Bjarni Ingi Gislason 
---
 menu.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/menu.c b/menu.c
index b91a974..0dfee2c 100644
--- a/menu.c
+++ b/menu.c
@@ -1295,6 +1295,7 @@ draw_menu:
case 1:
if ((ah->flag & A_ROOT_ART) == 0)
break;
+   /* FALLTHROUGH */ /* to avoid a warning */
/* XXX: bug? Another fall? */
case 2:
menu_length++;
@@ -1484,6 +1485,9 @@ new_state:
 
case AC_REENTER_GROUP:
menu_return(ME_REENTER_GROUP);
+ /* Previous command returns, but the compiler can't know that,
+so "return 0;" is used to tell that */
+   return 0; /* avoid a "fallthrough" warning */
}
/* XXX: bug? fall */
 
@@ -1622,6 +1626,7 @@ new_state:
case 3:
if (ah->attr == 0)
break;
+   /* FALLTHROUGH */ /* to avoid a warning */
/* XXX: check fall */
case 1:
if ((ah->attr & A_SELECT) == 0)
@@ -1860,6 +1865,7 @@ new_state:
goto empty_menu_hack;
}
 
+   /* FALLTHROUGH */ /* avoid a warning */
/* XXX: Fall ? */
case K_OPEN_SUBJECT:
if (numa < 0)
@@ -2251,6 +2257,7 @@ new_state:
case 1:
if ((articles[nexta]->flag & A_ROOT_ART) == 0)
break;
+   /* FALLTHROUGH */ /* to avoid a warning */
/* XXX: fall? */
case 2:
--menu_length;
@@ -2405,6 +2412,7 @@ do_auto_read:
firsta = nexta;
goto redraw;
}
+   goto defaut; /* Uncertain code, avoid a warning */
/* XXX: fall? */
case MC_NEXTGROUP:
menu_cmd = ME_NEXT;
@@ -2419,7 +2427,8 @@ do_auto_read:
break;
 
default:
-   sys_error("show_articles returned improper value");
+   sys_error("File %s, line %d: show_articles returned improper value, 
%d",
+   __FILE__, __LINE__, show_artices());
 }
 
 menu_exit:
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984497: python-cython-blis package

2021-03-05 Thread Paul Wise

On Fri, 2021-03-05 at 16:52 +0100, Andreas Tille wrote:

> Finally the license statement is all about redistribution ... and
> than upstream says:  Do not redistribute. 

They appear to be fine with redistribution, just not with wide
distribution by a popular Linux distribution, which has a stable
release that is guaranteed to get out of date with documentation.

Possibly they could be convinced by having the package only available
in Debian unstable or experimental and guaranteeing to keep it up to
date with the latest available upstream version.

On the other hand they probably also don't want to deal with bug
reports about a build that they did not produce.

Perhaps the right way is for Debian to distribute ExplosionAI software
under different names with all documentation pointing at Debian to
avoid upstream having to deal with bug reports from Debian users.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

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

Bug#984504: pkg-config: "pkg-config --cflags" incorrectly omits -I flags

2021-03-05 Thread Vincent Lefevre

Control: forwarded -1 
https://gitlab.freedesktop.org/pkg-config/pkg-config/-/issues/66

I've reported the bug upstream.

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

Bug#927454: ITP: towncrier -- compiler for project news file

2021-03-05 Thread Sergio Durigan Junior

On Friday, April 19 2019, Ben Finney wrote:

> * Package name: towncrier
>   Version : 19.2.0
>   Upstream Author : Amber Brown  and Contributors
> * URL or Web page : https://pypi.org/project/towncrier/
> * License : Expat
>   Description : compiler for project news file
>   Towncrier is a utility to produce useful, summarised news files for your
>   project. Rather than reading the VCS history as some newer tools do, or 
> having
>   one single file which developers all write to, towncrier reads “news 
> fragments”
>   which contain information *useful to end users*.
>   .
>   towncrier delivers the news which is convenient to those that hear it, 
> not
>   those that write it.
>   .
>   That is, a “news fragment” (a small file containing just enough 
> information to
>   be useful to end users) can be written that summarises what has changed 
> from
>   the “developer log” (which may contain complex information about the 
> original
>   issue, how it was fixed, who authored the fix, and who reviewed the 
> fix). By
>   compiling a collection of these fragments, towncrier can produce a 
> digest of
>   the changes which is valuable to those who may wish to use the software.

Hi Ben,

How are you?

I'm writing to check on the status of the towncrier package.  I noticed
that you have an apparently complete package on
https://salsa.debian.org/bignose/pkg-towncrier, but it hasn't been
uploaded and I can't find why.

I have a friend (who is also my namesake) who is interested in having
towncrier in the archive.  Maybe you can give us/him some pointers on
the current status of the package so that he can help you with it?

Thanks in advance,

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


signature.asc
Description: PGP signature

Bug#984631: more.h: change type "fct_type" to "fct_type_int" in "next_header_field()"

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From ed38d205c62e39306ce24febffc3fdce895405d1 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Sat, 6 Mar 2021 00:45:20 +
>Subject: [PATCH] more.h: change type "fct_type" to "fct_type_int" in
> "next_header_field()"

Signed-off-by: Bjarni Ingi Gislason 
---
 more.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/more.h b/more.h
index 7f987f8..82bce5a 100644
--- a/more.h
+++ b/more.h
@@ -3,7 +3,7 @@
  */
 
 voidscan_header_fields(char *, article_header *);
-int next_header_field(char **, char **, fct_type *);
+int next_header_field(char **, char **, fct_type_int *);
 int more(article_header *, int, int);
 voidrot13_line(register char *);
 
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984630: python3-waitress: leaves alternatives after upgrade: /etc/alternatives/waitress-serve -> /usr/bin/waitress-serve-python3

Package: python3-waitress
Version: 1.4.4-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-removal-and-or-configuration-purging

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

1m8.4s INFO: Warning: Package purging left files on system:
  /etc/alternatives/waitress-serve -> /usr/bin/waitress-serve-python3not 
owned

The preinst script already has the code to clean up the alternative,
but that does not get called because the preint script is never called
with the argument "configure". Please trigger this cleanup in "upgrade"
instead.

cheers,

Andreas


python3-waitress_1.4.4-1.log.gz
Description: application/gzip

Bug#984629: grc added colourify aliases

2021-03-05 Thread Craig Sanders

Package: grc
Version: 1.12-1

The grc package has suddenly added aliases to colourify several commands.
Worse, it creates some truly awful (e.g. white on green) and completely
useless and unreadable colour combinations (e.g. blue on black for several
commands, and black on black for docker container and image IDs).

I don't know exactly what version of the grc package started this (I only
noticed last night after rebooting my machines for a kernel upgrade), but this
should:

1. Be optional/configurable - e.g. with a "GRC_ALIASES=[true | false]" setting
in /etc/default/grc

IMO the default should be 'false' (for the principle of least surprise) but
that doesn't really matter as long as there is a way for the user to choose.

I have grc installed to colourise logs and other output when I want to. I wasn't
expecting to have common commands suddenly have garish and hard-to-read colours.

BTW, depending on order of execution, these aliases may also over-ride aliases
already set by the user/system-admin.


2. Not assume a white terminal background.  Either choose colours that work
on both white and black backgrounds, or have a "light" and a "dark" set of
colours.

A "light" and "dark" set could be implemented by having a /usr/share/grc/light
and /usr/share/grc/dark subdirectories (which should all be conffiles as
noted below).

The /etc/profile.d/grc.sh script could read a setting in /etc/default/grc
(e.g. GRC_ALIASES=[light|dark|none]), and symlink the appropriate colour set
into /usr/share/grc/ - e.g 

if [ -n "$GRC_ALIASES" ] && [ "$GRC_ALIASES" != "none" ] ; then
ln -sf "/usr/share/$GRC_ALIASES"/conf.* /usr/share/grc/
fi

A setting of "none" should delete all symlinks in /usr/share/grc.  e.g.

if [ -z "$GRC_ALIASES" ] || [ "$GRC_ALIASES" = "none" ] ; then
find /usr/share/grc/ -maxdepth 1 -type l -delete
fi


3. List /usr/share/grc/conf.* as conffiles.  None of them are currently
conffiles in the package - this means that any local customisations (like
fixing black on black) will be reset every time grc is upgraded.


craig

PS: I had to undo this on all my systems by running (in every terminal and
tmux window...dozens of shells after rebooting them for a new kernel and
re-starting my usual terminal windows and tmux sessions, so this was very
tedious):

unalias as blkid colourify configure df diff dig docker docker-compose 
docker-machine du env fdisk findmnt free g++ gas gcc getsebool head id ifconfig 
ip iptables journalctl kubectl ld lsblk lsof lspci make mount netstat ping ps 
semanage sockstat ss tail traceroute traceroute6

I also had to edit /etc/profile.d/grc.sh on all machines to prevent it from
happening again:

- if [ "$TERM" != dumb ] && [ -n "$GRC" ]; then
+ if [ 0 -eq 1 ] ; then

Bug#976053: Info received (sysdig-dkms is buildable with the latest upstream sources)

2021-03-05 Thread Dima Kogan

This bug makes sysdig unusable with the kernel in Bullseye. I'm going to
do an NMU this coming weekend if I don't hear from you.

Bug#984628: bsdmainutils: leaves alternatives after upgrade: /usr/bin/from

Package: bsdmainutils
Version: 12.1.7+nmu2
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package left unowned files on
the system after purge, which is a violation of policy 6.8:

https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#details-of-removal-and-or-configuration-purging

The leftover files are actually alternatives that were installed by the
package but have not been properly removed.

Filing this as important as having a piuparts clean archive is a release
goal since lenny.

>From the attached log (scroll to the bottom...):

0m28.1s INFO: Warning: Package purging left files on system:
  /etc/alternatives/from -> /usr/bin/bsd-fromnot owned
  /etc/alternatives/from.1.gz -> /usr/share/man/man1/bsd-from.1.gz   not 
owned
  /etc/calendar/ not owned
  /etc/cron.daily/bsdmainutils.dpkg-remove   not owned
  /usr/bin/from -> /etc/alternatives/fromnot owned
  /usr/share/man/man1/from.1.gz -> /etc/alternatives/from.1.gz   not owned


Since the /usr/bin/bsd-from binary has been dropped in bullseye,
the alternative set up by the package from buster needs to be
cleaned up during postinst configure:

update-alternatives --remove write /usr/bin/bsd-write


cheers,

Andreas


bsdmainutils_12.1.7+nmu2.log.gz
Description: application/gzip

Bug#981686: linux-image-5.10.0-3-amd64: Streaming video over NFSv3 broken since upgrade to 5.10.12

2021-03-05 Thread Geoff

Package: linux-image-5.10.20-xanmod1
Followup-For: Bug #981686
X-Debbugs-Cc: unit...@bigpond.com

NFSv3 issue is fixed upstream in 5.10.15 so this bug can be closed.

Bug#984627: debcargo: should ignore build-dependencies that are marked cfg(target_env = "msvc")

2021-03-05 Thread Daniel Kahn Gillmor

Package: debcargo
Version: 2.4.4-1
Control: affects -1 src:rust-nettle-sys

in Cargo.toml from nettle-sys 2.0.5, we see:

[target."cfg(target_env = \"msvc\")".build-dependencies.vcpkg]
version = "0.2.9"


But debcargo 2.4.4 translates that into actual Build-Depends: and
Depends: fields, despite the target environment not being the MSVC
compiler.  It generates:

-
Source: rust-nettle-sys
Section: rust
Priority: optional
Build-Depends: debhelper (>= 12),
 dh-cargo (>= 24),
 cargo:native ,
 rustc:native ,
 libstd-rust-dev ,
 librust-bindgen-0.55-dev  | librust-bindgen-0.54-dev  | 
librust-bindgen-0.53-dev (>= 0.53.1-~~) ,
 librust-pkg-config-0.3+default-dev ,
 librust-vcpkg-0.2+default-dev (>= 0.2.9-~~) ,
 nettle-dev (>= 3.5.1~~) ,
 llvm
Maintainer: Debian Rust Maintainers 

Uploaders:
 Daniel Kahn Gillmor ,
 kpcyrd 
Standards-Version: 4.5.1
Vcs-Git: https://salsa.debian.org/rust-team/debcargo-conf.git [src/nettle-sys]
Vcs-Browser: 
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/nettle-sys
Rules-Requires-Root: no

Package: librust-nettle-sys-dev
Architecture: any
Multi-Arch: same
Depends:
 ${misc:Depends},
 librust-bindgen-0.55-dev | librust-bindgen-0.54-dev | librust-bindgen-0.53-dev 
(>= 0.53.1-~~),
 librust-pkg-config-0.3+default-dev,
 librust-vcpkg-0.2+default-dev (>= 0.2.9-~~),
 nettle-dev (>= 3.5.1~~)
Provides:

-

So, i'll probably patch this out of the upstream sources for now, but
debcargo should have handled this more cleanly.

   --dkg


signature.asc
Description: PGP signature

Bug#984626: ITP: python-tr -- implementation of the tr algorithm

2021-03-05 Thread Jelmer Vernooij

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

* Package name: python-tr
  Version : 0.1.2
  Upstream Author : Yukino Ikegami
* URL : https://pypi.org/project/python-tr/
* License : MIT
  Programming Lang: Python
  Description : implementation of the tr algorithm

This module is a Python implementation of the tr algorithm.

tr(string1, string2, source, option=’’)

If not given option, then replace all characters in string1 with the character
in the same position in string2.

Bug#983435:

2021-03-05 Thread bugsgrid+deb

Control: retitle -1 upgrade or grub-install breaks system if udev is
not installed

May I ask what I'm supposed to do next?
As any grub packages in usual debian repositories are no longer
working for me, I'm forced to dig up snapshot.debian.org to revert
(yes I forgot to save working .deb locally, stupid was mine).
Well, I don't care any security holes only relevant under SecureBoot,
but I'm not sure if I'm actually supposed to keep hold on grub for
eternity.

Thanks,

Bug#984625: pygments: New 2.8.0 upstream version available

2021-03-05 Thread Kunal Mehta

Package: pygments
Version: 2.7.1+dfsg-1
Severity: wishlist

Dear maintainer,

Pygments has released version 2.8.0: 
https://pygments.org/docs/changelog/#version-2-8-0

It now includes the "dot" language, which had previously been requested by
Wikimedia users: .

0002-add-g-parameter-to-pygmentize-man-page.patch can also be dropped as it has 
been fixed upstream.

I prepared an update to 2.8.0 for Wikimedia on Buster, feel free to use any of 
my packaging work in case it is useful: 
.

Thanks,
-- Kunal

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

Kernel: Linux 5.4.88-1.qubes.x86_64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#984624: regexp.c: cast an int to size_t in a comparison

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 31b27501562ac5c96b62e290afcf2a35679d936d Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Fri, 5 Mar 2021 23:02:04 +
>Subject: [PATCH] regexp.c: cast an int to size_t in a comparison

regexp.c:275:52: warning: comparison of integer expressions of different 
signedness: 'size_t' {aka 'long unsigned int'} and 'int' [-Wsign-compare]
  275 |   if (OP(scan) == EXACTLY && strlen(OPERAND(scan)) >= len) {
  |^~

Signed-off-by: Bjarni Ingi Gislason 
---
 regexp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/regexp.c b/regexp.c
index 0a08534..316743e 100644
--- a/regexp.c
+++ b/regexp.c
@@ -272,7 +272,8 @@ regcomp(char *exp)
longest = NULL;
len = 0;
for (; scan != NULL; scan = regnext(scan))
-   if (OP(scan) == EXACTLY && strlen(OPERAND(scan)) >= len) {
+   if (OP(scan) == EXACTLY && strlen(OPERAND(scan))
+   >= (size_t) len) {
longest = OPERAND(scan);
len = strlen(OPERAND(scan));
}
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#984604: buster-pu: package sabnzbdplus/2.3.6+dfsg-1

2021-03-05 Thread Jeroen Ploemen

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

The sabnzbdplus package in buster is affected by a security issue
(CVE-2020-13124), permitting code execution from the program's web
interface through crafted settings. By default, the web interface is
only accessible from localhost, with no authentication required.

Affected versions are 2.0.0RC1 - 3.0.0Beta3 (inclusive), see the
upstream security advisory [1] for details. The issue has been fixed in
testing and unstable already via a regular upload of a newer upstream
release. For buster, the relevant upstream commits have been
backported, see the attached debdiff.

The security team was contacted but didn't consider this issue severe
enough to warrant a DSA, and suggested going with a regular update
instead [2].


[1] https://github.com/sabnzbd/sabnzbd/security/advisories/GHSA-9x87-96gg-33w2
[2] https://security-tracker.debian.org/tracker/CVE-2020-13124


buster_sabnzbdplus_2.3.6+dfsg-1.debdiff
Description: Binary data


pgpt4qFXtIcFX.pgp
Description: OpenPGP digital signature

Bug#984623: pychess: Fails to switch off sound

2021-03-05 Thread Pelle

Package: pychess
Version: 1.0.0-1.1
Severity: normal

Dear Maintainer,

PyChess keeps playing sound effects, even when "Use sounds in PyChess" is
unchecked. Additionally the "Use sounds in PyChess checkbox is automatically
reenabled every time PyChess is launched. I expect PyChess to not play sounds
when "Use sounds in PyChess" is unchecked, and I expect the setting to persist
after quitting and relaunching PyChess.

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

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

Versions of packages pychess depends on:
ii  gaviotatb0.4-2.1
ii  gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1
ii  gir1.2-glib-2.0  1.66.1-1+b1
ii  gir1.2-gst-plugins-base-1.0  1.18.3-1
ii  gir1.2-gstreamer-1.0 1.18.3-1
ii  gir1.2-gtk-3.0   3.24.24-3
ii  gir1.2-gtksource-3.0 3.24.11-2
ii  gir1.2-pango-1.0 1.46.2-3
ii  gir1.2-rsvg-2.0  2.50.3+dfsg-1
ii  gnome-icon-theme 3.12.0-3
ii  gobject-introspection1.66.1-1+b1
ii  libgaviotatb10.4-2.1
ii  python3  3.9.2-2
ii  python3-cairo1.16.2-4+b2
ii  python3-gi   3.38.0-2
ii  python3-gi-cairo 3.38.0-2
ii  python3-websockets   8.1-1

pychess recommends no packages.

pychess suggests no packages.

Bug#984622: rust-derive-more uninstallable, unmigratable due to missing rust-peg

2021-03-05 Thread Steve Langasek

Source: rust-derive-more
Version: 0.99.5-2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute

The rust-derive-more package has not been migratable to testing for 139 days
because the new version has a dependency on rust-peg which does not exist in
Debian (including in the NEW queue).

$ sudo apt install librust-derive-more+generate-parsing-rs-dev 
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 librust-derive-more+generate-parsing-rs-dev : Depends: 
librust-peg-0.5+default-dev but it is not installable
E: Unable to correct problems, you have held broken packages.
$

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#984621: RM: xmille -- RoQA; superseded by kgames

Package: ftp.debian.org
Severity: normal

kgames Breaks+Replaces+Provides xmille

anbe@coccia:~$ dak rm -Rn xmille
Will remove the following packages from unstable:

xmille | 2.0-13 | source
xmille |  2.0-13+b2 | amd64, arm64, armel, armhf, i386, mips64el, mipsel, 
ppc64el, s390x

Maintainer: Steve M. Robbins 

--- Reason ---

--

Checking reverse dependencies...
No dependency problem found.

Andreas

Bug#984620: fltk1.1: Please add a Wayland driver

2021-03-05 Thread Guillem Jover

Source: fltk1.1
Source-Version: 1.1.10-29
Severity: wishlist
Tags: upstream
Forwarded: https://www.fltk.org/str.php?L3371

Hi!

I've just switched to use Wayland (after several previous attempts),
and I noticed one of the remaining items on my system that require
using the Xwayland compatibility X11 server is this library.

Given that the X.Org server is apparently pretty much dead, that other
distributions are also switching to Wayland and that most mainstream
desktop environments now support this natively. It would be nice to
have fltk support this too.

Filing this to be able to track the progress in Debian, which I expect
will become more visible sooner rather than later. :)

Thanks,
Guillem

Bug#983379: linux uml segfault

2021-03-05 Thread Hajime Tazaki



might be late, but I'll give it a try with your dlopen reproducer.

-- Hajime

On Sat, 06 Mar 2021 05:22:19 +0900,
Johannes Berg wrote:
> 
> On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
> > 
> > objcopy (from binutils) can localize symbols (i.e., objcopy -L
> > sem_init $orig_file $new_file).
> 
> This doesn't seem to be sufficient.
> 
> > It also does renaming symbols.  But
> > not sure this is the ideal solution.
> 
> Even that doesn't seem to actually work/help? I still get libcom_err
> trying to call UML's sem_init, even after doing
>  objcopy --redefine-sym sem_init=uml_sem_init

Bug#984554: libnginx-mod-stream-geoip: ngx_stream_geoip_module.so: undefined symbol: ngx_stream_add_variable

2021-03-05 Thread Felix Lechner

The following thread is more recent and describes the same phenomenon:

https://github.com/oerdnj/deb.sury.org/issues/1437#issuecomment-734722970

Bug#984554: [SOLVED] Bug#984554: libnginx-mod-stream-geoip: ngx_stream_geoip_module.so: undefined symbol: ngx_stream_add_variable

2021-03-05 Thread Felix Lechner

Hi,

After comparing the failing upgrade with other, working installations
of 'nginx-full' and following the precedence rationale here [1], I was
able to resolve the installation impasse by running the following
command in /etc/nginx/modules-enabled:

ln -s /usr/share/nginx/modules-available/mod-stream.conf 50-mod-stream.conf

Hope that helps!

Kind regards
Felix Lechner

[1] http://mailman.nginx.org/pipermail/nginx/2016-July/051323.html

Bug#984619: keymap.c: fix an error the compiler reported

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 5c6df55004338b0468e43688e9503e6acd15d6f6 Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Fri, 5 Mar 2021 21:50:36 +
>Subject: [PATCH] keymap.c: fix an error the compiler reported

keymap.c: In function 'key_name':
keymap.c:833:33: error: 'uint' undeclared (first use in this function); did you 
mean 'int'?
  833 |  snprintf(buf, NBUF, "0x%02x", (uint)c);
  | ^~~~
  | int
keymap.c:833:33: note: each undeclared identifier is reported only once for 
each function it appears in
keymap.c:833:38: error: expected ')' before 'c'
  833 |  snprintf(buf, NBUF, "0x%02x", (uint)c);
  |  ^
  |  )



  Change "uint" to "unsigned int".

Signed-off-by: Bjarni Ingi Gislason 
---
 keymap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/keymap.c b/keymap.c
index fee9bbf..1cb0011 100644
--- a/keymap.c
+++ b/keymap.c
@@ -830,7 +830,7 @@ key_name(key_type c)
goto out;
 }
 if (data_bits < 8 && c >= NORMAL_KEYS) {
-   snprintf(buf, NBUF, "0x%02x", (uint)c);
+   snprintf(buf, NBUF, "0x%02x", (unsigned int) c);
goto out;
 }
 buf[0] = c;
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983917: gnome-weather: Fails to get forecast data

2021-03-05 Thread Andreas Henriksson

Control: reassign -1 libgweather-3-16 3.36.1-1

Thanks for your bug report, more info below.

On Wed, Mar 03, 2021 at 11:58:38AM +0100, Pelle wrote:
> Package: gnome-weather
> Version: 3.36.1-1
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> Gnome Weather fails to get forecast data. After entering a location the app
> shows the message: "Forecast data not available"
[...]

Apparently yr.no has discontinued it's old API and a new one is
available from met.no.

The changes needed are in libgweather and has been done for
libgweather 40.x releases upstream. The changes includes atleast
one API change which possibly makes it not possible to simply update
libgweather.

Here are a bunch of commits to look closer at:
https://gitlab.gnome.org/GNOME/libgweather/-/commit/3f8f622e9a7d532b9041133bfcc42b67f0cdd9da
https://gitlab.gnome.org/GNOME/libgweather/-/commit/c0c39a54b67849efe17367fa9b6f1ca7ad58349b
https://gitlab.gnome.org/GNOME/libgweather/-/commit/44d042336f9439ca3b341b5bcb44c55a3384fa66
https://gitlab.gnome.org/GNOME/libgweather/-/commit/6b3c33980a56f6c8ffa1cb516560c495bec88fc8
https://gitlab.gnome.org/GNOME/libgweather/-/commit/924671fe2022f1d3bd7179a04dfb6c9f0780a77a
https://gitlab.gnome.org/GNOME/libgweather/-/commit/d49f7f90dc8af135260009e313e718704b284257
https://gitlab.gnome.org/GNOME/libgweather/-/commit/827631c054cda713e89a36862a54a4c88632cac3



And finally the API breaking fixup commit in gnome-weather is:
https://gitlab.gnome.org/GNOME/gnome-weather/-/commit/6763f7dc9cb25eac4aa13e94e07ea932a42c8e4d

Regards,
Andreas Henriksson

Bug#964718: ITS: python-invoke

2021-03-05 Thread Antoine Beaupré

On 2021-03-05 08:49:03, Thomas Goirand wrote:
> On 3/5/21 3:26 AM, Antoine Beaupré wrote:
>> On 2020-11-22 12:44:52, Thomas Goirand wrote:
>>> Hi Antoine,
>>>
>>> I'm sorry it took me so long to reply (I'm doing this now as part of a
>>> bug triaging session).
>>>
>>> Please, feel free to take over the maintenance of python-invoke under
>>> the DPMT. The OpenStack team no longer needs that package anyway, and it
>>> may be a bit neglected as you wrote. Please just keep me as uploader.
>> 
>> Hi!
>> 
>> Thanks for your vote of confidence! :)
>> 
>> I started the work here:
>> 
>> https://salsa.debian.org/anarcat/python-invoke
>> 
>> I'm afraid I kind of forgot about this ITS and this is likely to miss
>> the freeze. I've been struggling to add autopkgtest so that it kind of
>> goes under the radar, but alas, some build-deps are missing for that
>> (pytest_relaxed, for one).
>> 
>> Also, if someone in the openstack team has access to both the openstack
>> project and the python team, it might be nice if they could *move* the
>> repository between the two teams, so that we benefit from the nice
>> GitLab redirections.
>
> Done.
>
> However, be aware that the OpenStack team uses a git tag workflow (ie:
> we import the upstream git history) while the Python team uses a
> pristine-tar workflow. So you may as well start from scratch (the
> redirection is there though...).

I'm kind of an heretic in the Python team in that i am in between: i use
import-orig with an upstream source, but not pristine-tar. I did base
myself on your work though.

Thanks for the rename!

-- 
The individual has always had to struggle to keep from being overwhelmed
by the tribe. If you try it, you will be lonely often, and sometimes
frightened. But no price is too high to pay for the privilege of owning
yourself.- Friedrich Nietzsche

Bug#984617: unblock: lowmem/1.49

2021-03-05 Thread Samuel Thibault

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

Hello,

I have uploaded a new version of lowmem, see the attached patch.

[ Reason ]
This updates the memory levels at which the d-i enables low-memory
optimizations.

[ Impact ]
If this isn't getting updated, starting the d-i on an amd64 machine with
an amount of memory between 550MB and 780MB, with default parameters,
will try to install without any low-memory optimization, but that will
fail with OOM errors.

[ Tests ]
I tested the d-i image in each modified case.

[ Risks ]
The code change is trivial: it only changes the numerical level.

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock lowmem/1.49

Thanks!
Samuel
diff -Nru lowmem-1.48/debian/changelog lowmem-1.49/debian/changelog
--- lowmem-1.48/debian/changelog2020-12-15 18:15:38.0 +0100
+++ lowmem-1.49/debian/changelog2021-03-03 02:21:13.0 +0100
@@ -1,3 +1,9 @@
+lowmem (1.49) unstable; urgency=medium
+
+  * debian-installer-startup.d/S15lowmem: Update minimum memory sizes.
+
+ -- Samuel Thibault   Wed, 03 Mar 2021 02:21:13 +0100
+
 lowmem (1.48) unstable; urgency=medium
 
   * Team upload
diff -Nru lowmem-1.48/debian-installer-startup.d/S15lowmem 
lowmem-1.49/debian-installer-startup.d/S15lowmem
--- lowmem-1.48/debian-installer-startup.d/S15lowmem2019-06-02 
14:21:18.0 +0200
+++ lowmem-1.49/debian-installer-startup.d/S15lowmem2021-03-03 
02:15:44.0 +0100
@@ -25,9 +25,9 @@
min=39
;;
amd64)
-   level1=483 # MT=494300, qemu: -m 550
-   level2=273 # MT=279260, qemu: -m 300
-   min=145# MT=148188, qemu: -m 170
+   level1=737 # MT=754108, qemu: -m 780
+   level2=424 # MT=433340, qemu: -m 460
+   min=316# MT=322748, qemu: -m 350
;;
arm|armel|armhf)
# Update needed
@@ -42,9 +42,9 @@
min=18
;;
i386)
-   level1=386 # MT=394604, qemu: -m 400
-   level2=237 # MT=242628, qemu: -m 250
-   min=109# MT=110956, qemu: -m 120
+   level1=466 # MT=478056, qemu: -m 485
+   level2=348 # MT=356312, qemu: -m 365
+   min=269# MT=275220, qemu: -m 285
;;
mips)
# Update needed
@@ -89,9 +89,9 @@
min=30# MT=30040, qemu: -m 90
;;
hurd-i386)
-   level1=499 # qemu: -m 500
-   level2=409 # qemu: -m 410
-   min=389# qemu: -m 390
+   level1=600 # MT=614208, qemu: -m 600
+   level2=480 # MT=491328, qemu: -m 480
+   min=475# MT=486208, qemu: -m 475
;;
*)
level1=64
diff -Nru lowmem-1.48/README lowmem-1.49/README
--- lowmem-1.48/README  2019-10-13 20:07:57.0 +0200
+++ lowmem-1.49/README  2021-03-03 02:06:22.0 +0100
@@ -131,13 +131,16 @@
 devices).
 
 In both cases, you need to set min to absolute minimum amount of memory needed
-for an install, booting with lowmem=2, partitioning by hand, etc.
+for an install, booting with lowmem=2, loading only the nic-modules udeb,
+partitioning by hand, etc.
 
 Ideally, constraints should be tested for both netboot and businesscard images
 (businesscard CD will use slightly more memory before partitioning that netinst
 because of mirror selection).
 
-NB: the minimum value should be update in the manual in build/arch-options
+NB: the minimum value should be updated in the manual in build/arch-options
+
+NB: the minimum value should be updated in 
debian-installer/build/boot/x86/f2.txt
 
 NB: the minimum memory required to run the graphical installer must
 also be tested. See rootskel (debian-installer.d/S60frontend).

Bug#983379: [PATCH] um: mark all kernel symbols as local

2021-03-05 Thread Anton Ivanov


On 05/03/2021 20:43, Johannes Berg wrote:

From: Johannes Berg 

Ritesh reported a bug [1] against UML, noting that it crashed on
startup. The backtrace shows the following (heavily redacted):

(gdb) bt
...
  #26 0x60015b5d in sem_init () at ipc/sem.c:268
  #27 0x7f89906d92f7 in ?? () from /lib/x86_64-linux-gnu/libcom_err.so.2
  #28 0x7f8990ab8fb2 in call_init (...) at dl-init.c:72
...
  #40 0x7f89909bf3a6 in nss_load_library (...) at nsswitch.c:359
...
  #44 0x7f8990895e35 in _nss_compat_getgrnam_r (...) at 
nss_compat/compat-grp.c:486
  #45 0x7f8990968b85 in __getgrnam_r [...]
  #46 0x7f89909d6b77 in grantpt [...]
  #47 0x7f8990a9394e in __GI_openpty [...]
  #48 0x604a1f65 in openpty_cb (...) at arch/um/os-Linux/sigio.c:407
  #49 0x604a58d0 in start_idle_thread (...) at 
arch/um/os-Linux/skas/process.c:598
  #50 0x60004a3d in start_uml () at arch/um/kernel/skas/process.c:45
  #51 0x600047b2 in linux_main (...) at arch/um/kernel/um_arch.c:334
  #52 0x6000574f in main (...) at arch/um/os-Linux/main.c:144

indicating that the UML function openpty_cb() calls openpty(),
which internally calls __getgrnam_r(), which causes the nsswitch
machinery to get started.

This loads, through lots of indirection that I snipped, the
libcom_err.so.2 library, which (in an unknown function, "??")
calls sem_init().

Now, of course it wants to get libpthread's sem_init(), since
it's linked against libpthread. However, the dynamic linker
looks up that symbol against the binary first, and gets the
kernel's sem_init().

Hajime Tazaki noted that "objcopy -L" can localize a symbol,
so the dynamic linker wouldn't do the lookup this way. I tried,
but for some reason that didn't seem to work.

Doing the same thing in the linker script instead does seem to
work, though I cannot entirely explain - it *also* works if I
just add "VERSION { { global: *; }; }" instead, indicating that
something else is happening that I don't really understand. It
may be that explicitly doing that marks them with some kind of
empty version, and that's different from the default.

Explicitly marking them with a version breaks kallsyms, so that
doesn't seem to be possible.

Marking all the symbols as local seems correct, and does seem
to address the issue, so do that. Also do it for static link,
nsswitch libraries could still be loaded there.

[1] https://bugs.debian.org/983379

Reported-by: Ritesh Raj Sarraf 
Signed-off-by: Johannes Berg 
---
  arch/um/kernel/dyn.lds.S | 6 ++
  arch/um/kernel/uml.lds.S | 6 ++
  2 files changed, 12 insertions(+)

diff --git a/arch/um/kernel/dyn.lds.S b/arch/um/kernel/dyn.lds.S
index dacbfabf66d8..2f2a8ce92f1e 100644
--- a/arch/um/kernel/dyn.lds.S
+++ b/arch/um/kernel/dyn.lds.S
@@ -6,6 +6,12 @@ OUTPUT_ARCH(ELF_ARCH)
  ENTRY(_start)
  jiffies = jiffies_64;
  
+VERSION {

+  {
+local: *;
+  };
+}
+
  SECTIONS
  {
PROVIDE (__executable_start = START);
diff --git a/arch/um/kernel/uml.lds.S b/arch/um/kernel/uml.lds.S
index 45d957d7004c..7a8e2b123e29 100644
--- a/arch/um/kernel/uml.lds.S
+++ b/arch/um/kernel/uml.lds.S
@@ -7,6 +7,12 @@ OUTPUT_ARCH(ELF_ARCH)
  ENTRY(_start)
  jiffies = jiffies_64;
  
+VERSION {

+  {
+local: *;
+  };
+}
+
  SECTIONS
  {
/* This must contain the right address - not quite the default ELF one.*/



Acked-By: Anton Ivanov 
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/

Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch

2021-03-05 Thread Utkarsh Gupta

Hi Thorsten

On Sat, Mar 6, 2021 at 2:25 AM Thorsten Glaser  wrote:
> debian/patches/CVE-2021-27135.patch changes button.c line (after
> patching) 3747 to:
>
>line = realloc(line, screen->selection_size);
>
> But “line” is a local variable, the address of the buffer must
> be stored in the one handed out, too, so please change this to:
>
> if ((have * 2) < (size_t) j) {
> Char *next = realloc(line, have + 1);
> if (next) {
> screen->selection_data = line = next;
> screen->selection_size = have + 1;
> }
> }
>
> This also deals properly with realloc failures (since we’re
> shrinking, ignore them and just keep the older, larger area).

Thanks for the very comprehensive bug report and for the patch as well!

> I’ve not looked at jessie-ELTS or buster-security whether they
> are affected as well; sid is clean (and where I got the realloc
> failure check necessity from, although sid’s free()s the buffer
> if realloc fails; this isn’t needed @Tom).

If this seems to be happening in stretch, I assume there's a problem
with jessie-ELTS as well. That said, buster is good because a DSA
wasn't issued and this will be fixed via a point release. I am glad
and surprised that sid is okay and there doesn't seem to be a problem.
Just to cross-check and ensure I get it right (for stretch and
jessie), can you send me the reproducer as well? I'd like to be able
to reproduce this before and after your patch (just to be one the
safer side) and do the same for jessie as well!

Thanks, again, for such a detailed bug report! :D

- u

Bug#984616: nis: prompting due to modified conffiles which were not modified by the user: /etc/default/nis

Package: nis
Version: 4.2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

This was observed during a buster -> bullseye upgrade.

>From the attached log (scroll to the bottom...):

  Setting up nis (4.2) ...
  
  Configuration file '/etc/default/nis'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** nis (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package nis 
(--configure):
   end of file on stdin at conffile prompt
  Processing triggers for libc-bin (2.31-9) ...
  Errors were encountered while processing:
   nis


cheers,

Andreas


nis_4.2.log.gz
Description: application/gzip

Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch

2021-03-05 Thread Thorsten Glaser

Source: xterm
Version: 327-2+deb9u1
Severity: serious
Justification: introduces use-after-realloc

debian/patches/CVE-2021-27135.patch changes button.c line (after
patching) 3747 to:

   line = realloc(line, screen->selection_size);

But “line” is a local variable, the address of the buffer must
be stored in the one handed out, too, so please change this to:

if ((have * 2) < (size_t) j) { 
Char *next = realloc(line, have + 1);
if (next) {
screen->selection_data = line = next;
screen->selection_size = have + 1;
}
}

This also deals properly with realloc failures (since we’re
shrinking, ignore them and just keep the older, larger area).

I’ve not looked at jessie-ELTS or buster-security whether they
are affected as well; sid is clean (and where I got the realloc
failure check necessity from, although sid’s free()s the buffer
if realloc fails; this isn’t needed @Tom).

bye,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh

Bug#984614: snort-common: prompting due to modified conffiles which were not modified by the user: /etc/cron.daily/snort-common

Package: snort-common
Version: 2.9.15.1-4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

This was observed during a buster -> bullseye upgrade.

>From the attached log (scroll to the bottom...):

  Setting up snort-common (2.9.15.1-4) ...
  
  Configuration file '/etc/cron.daily/snort-common'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** snort-common (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
snort-common (--configure):
   end of file on stdin at conffile prompt
  Processing triggers for libc-bin (2.31-9) ...
  Errors were encountered while processing:
   snort-common


cheers,

Andreas


snort-common_2.9.15.1-4.log.gz
Description: application/gzip

Bug#984613: glance-store-common: prompting due to modified conffiles which were not modified by the user: /etc/glance/rootwrap.conf

Package: glance-store-common
Version: 2.3.0-3
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: affects -1 + glance-common

Hi,

during a test with piuparts I noticed your package failed the piuparts
upgrade test because dpkg detected a conffile as being modified and then
prompted the user for an action. As there is no user input, this fails.
But this is not the real problem, the real problem is that this prompt
shows up in the first place, as there was nobody modifying this conffile
at all, the package has just been installed and upgraded...

This is a violation of policy 10.7.3, see
https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
which says "[These scripts handling conffiles] must not ask unnecessary
questions (particularly during upgrades), and must otherwise be good
citizens."

https://wiki.debian.org/DpkgConffileHandling should help with figuring
out how to do this properly.

In https://lists.debian.org/debian-devel/2009/08/msg00675.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

This was observed during a buster -> bullseye upgrade.

>From the attached log (scroll to the bottom...):

  Setting up glance-store-common (2.3.0-3) ...
  
  Configuration file '/etc/glance/rootwrap.conf'
   ==> File on system created by you or by a script.
   ==> File also in package provided by package maintainer.
 What would you like to do about it ?  Your options are:
  Y or I  : install the package maintainer's version
  N or O  : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
   The default action is to keep your current version.
  *** rootwrap.conf (Y/I/N/O/D/Z) [default=N] ? dpkg: error processing package 
glance-store-common (--configure):
   end of file on stdin at conffile prompt


cheers,

Andreas


glance-common_2:21.0.0-1.log.gz
Description: application/gzip

Bug#984612: term.c: Patch "term.c: various changes", remove part of it

Source: nn
Version: 6.7.3-14
Severity: normal
Tags: patch

Dear Maintainer,

>From 8038177822b036a08d98f3415b11887c07de657b Mon Sep 17 00:00:00 2001
>From: Bjarni Ingi Gislason 
>Date: Fri, 5 Mar 2021 18:15:47 +
>Subject: [PATCH]  Patch "term.c: various changes", remove part of it

  term.c:

  Remove 'Add code instead of "cfmakeraw()" depending of the definition
of "__osf__".'

Signed-off-by: Bjarni Ingi Gislason 
---
 term.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/term.c b/term.c
index e15eb66..088c9f5 100644
--- a/term.c
+++ b/term.c
@@ -674,16 +674,6 @@ init_term(int full)
 #ifdef HAVE_TERMIOS_H
 #  ifdef __osf__
 cfmakeraw(_tty);
-#  else /* same as for HAVE_TERMIO_H */
-raw_tty.c_iflag &= ~(BRKINT | INLCR | ICRNL | IGNCR | ISTRIP);
-raw_tty.c_iflag |= IGNBRK | IGNPAR;
-raw_tty.c_oflag &= ~OPOST;
-raw_tty.c_lflag &= ~(ISIG | ICANON | XCASE | ECHO | NOFLSH);
-
-/* read a maximum of 10 characters in one burst; timeout in 1-200 ms */
-raw_tty.c_cc[VMIN] = KEY_BURST;
-raw_tty.c_cc[VTIME] = ((int) (raw_tty.c_cflag & CBAUD) > B1200) ? 1 : 2;
-set_term_speed((unsigned long) (raw_tty.c_cflag & CBAUD));
 #  endif
 
 /* read a maximum of 10 characters in one burst; timeout in 1-200 ms */
-- 
2.30.1



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

Kernel: Linux 5.10.9-1 (SMP w/2 CPU threads)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#983379: [PATCH] um: mark all kernel symbols as local

From: Johannes Berg 

Ritesh reported a bug [1] against UML, noting that it crashed on
startup. The backtrace shows the following (heavily redacted):

(gdb) bt
...
 #26 0x60015b5d in sem_init () at ipc/sem.c:268
 #27 0x7f89906d92f7 in ?? () from /lib/x86_64-linux-gnu/libcom_err.so.2
 #28 0x7f8990ab8fb2 in call_init (...) at dl-init.c:72
...
 #40 0x7f89909bf3a6 in nss_load_library (...) at nsswitch.c:359
...
 #44 0x7f8990895e35 in _nss_compat_getgrnam_r (...) at 
nss_compat/compat-grp.c:486
 #45 0x7f8990968b85 in __getgrnam_r [...]
 #46 0x7f89909d6b77 in grantpt [...]
 #47 0x7f8990a9394e in __GI_openpty [...]
 #48 0x604a1f65 in openpty_cb (...) at arch/um/os-Linux/sigio.c:407
 #49 0x604a58d0 in start_idle_thread (...) at 
arch/um/os-Linux/skas/process.c:598
 #50 0x60004a3d in start_uml () at arch/um/kernel/skas/process.c:45
 #51 0x600047b2 in linux_main (...) at arch/um/kernel/um_arch.c:334
 #52 0x6000574f in main (...) at arch/um/os-Linux/main.c:144

indicating that the UML function openpty_cb() calls openpty(),
which internally calls __getgrnam_r(), which causes the nsswitch
machinery to get started.

This loads, through lots of indirection that I snipped, the
libcom_err.so.2 library, which (in an unknown function, "??")
calls sem_init().

Now, of course it wants to get libpthread's sem_init(), since
it's linked against libpthread. However, the dynamic linker
looks up that symbol against the binary first, and gets the
kernel's sem_init().

Hajime Tazaki noted that "objcopy -L" can localize a symbol,
so the dynamic linker wouldn't do the lookup this way. I tried,
but for some reason that didn't seem to work.

Doing the same thing in the linker script instead does seem to
work, though I cannot entirely explain - it *also* works if I
just add "VERSION { { global: *; }; }" instead, indicating that
something else is happening that I don't really understand. It
may be that explicitly doing that marks them with some kind of
empty version, and that's different from the default.

Explicitly marking them with a version breaks kallsyms, so that
doesn't seem to be possible.

Marking all the symbols as local seems correct, and does seem
to address the issue, so do that. Also do it for static link,
nsswitch libraries could still be loaded there.

[1] https://bugs.debian.org/983379

Reported-by: Ritesh Raj Sarraf 
Signed-off-by: Johannes Berg 
---
 arch/um/kernel/dyn.lds.S | 6 ++
 arch/um/kernel/uml.lds.S | 6 ++
 2 files changed, 12 insertions(+)

diff --git a/arch/um/kernel/dyn.lds.S b/arch/um/kernel/dyn.lds.S
index dacbfabf66d8..2f2a8ce92f1e 100644
--- a/arch/um/kernel/dyn.lds.S
+++ b/arch/um/kernel/dyn.lds.S
@@ -6,6 +6,12 @@ OUTPUT_ARCH(ELF_ARCH)
 ENTRY(_start)
 jiffies = jiffies_64;
 
+VERSION {
+  {
+local: *;
+  };
+}
+
 SECTIONS
 {
   PROVIDE (__executable_start = START);
diff --git a/arch/um/kernel/uml.lds.S b/arch/um/kernel/uml.lds.S
index 45d957d7004c..7a8e2b123e29 100644
--- a/arch/um/kernel/uml.lds.S
+++ b/arch/um/kernel/uml.lds.S
@@ -7,6 +7,12 @@ OUTPUT_ARCH(ELF_ARCH)
 ENTRY(_start)
 jiffies = jiffies_64;
 
+VERSION {
+  {
+local: *;
+  };
+}
+
 SECTIONS
 {
   /* This must contain the right address - not quite the default ELF one.*/
-- 
2.26.2

Bug#984609: openrocket: uninstallable: depends on no longer available openjdk-8-jre

2021-03-05 Thread Bdale Garbee

Andreas Beckmann  writes:

> Package: openrocket
> Version: 15.03.6
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package is no longer
> installable in sid:
>
>   The following packages have unmet dependencies:
>openrocket : Depends: openjdk-8-jre but it is not installable

Known, and the package has already been excluded from testing.

I'm working on re-packaging from upstream unreleased source for
future inclusion in Debian main.  There's really no solution for making
the current jar installer work without pulling the openjdk-8-jre in.
Doing that from oldstable will continue to work for quite a while, so
this installer isn't entirely useless in the interim until I can
complete re-packaging for main.  Will leave the bug open until then.

Bdale

signature.asc
Description: PGP signature

Bug#983334: pipewire-bin: pipewire-media-session is defunct

2021-03-05 Thread Patrice Duroux

Package: pipewire-bin
Followup-For: Bug #983334
Control: fixed -1 0.3.22-2

It's ok now!


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

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

Versions of packages pipewire-bin depends on:
ii  libasound2   1.2.4-1.1
ii  libc62.31-9
ii  libdbus-1-3  1.12.20-2
ii  libncurses6  6.2+20201114-2
ii  libpipewire-0.3-00.3.22-2
ii  libpipewire-0.3-modules  0.3.22-2
ii  libsndfile1  1.0.31-1
ii  libtinfo66.2+20201114-2

pipewire-bin recommends no packages.

pipewire-bin suggests no packages.

Bug#983379: linux uml segfault

On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
> 
> objcopy (from binutils) can localize symbols (i.e., objcopy -L
> sem_init $orig_file $new_file).

This doesn't seem to be sufficient.

> It also does renaming symbols.  But
> not sure this is the ideal solution.

Even that doesn't seem to actually work/help? I still get libcom_err
trying to call UML's sem_init, even after doing
 objcopy --redefine-sym sem_init=uml_sem_init


> How does UML handle symbol conflicts between userspace code and Linux
> kernel (like this case sem_init) ?  AFAIK, libnl has a same symbol as
> Linux kernel (genlmsg_put) and others can possibly do as well.

I think like I said it just doesn't but since you don't have much
userspace code linked with UML it never really mattered?

We only link a 'linux' binary, after all. How does LKL handle this
though? It should be far more affected?


Despite the objcopy *not* fixing it, this does seem to:

diff --git a/arch/um/kernel/dyn.lds.S b/arch/um/kernel/dyn.lds.S
index dacbfabf66d8..2f2a8ce92f1e 100644
--- a/arch/um/kernel/dyn.lds.S
+++ b/arch/um/kernel/dyn.lds.S
@@ -6,6 +6,12 @@ OUTPUT_ARCH(ELF_ARCH)
 ENTRY(_start)
 jiffies = jiffies_64;
 
+VERSION {
+  {
+local: *;
+  };
+}
+
 SECTIONS
 {
   PROVIDE (__executable_start = START);
diff --git a/arch/um/kernel/uml.lds.S b/arch/um/kernel/uml.lds.S
index 45d957d7004c..7a8e2b123e29 100644
--- a/arch/um/kernel/uml.lds.S
+++ b/arch/um/kernel/uml.lds.S
@@ -7,6 +7,12 @@ OUTPUT_ARCH(ELF_ARCH)
 ENTRY(_start)
 jiffies = jiffies_64;
 
+VERSION {
+  {
+local: *;
+  };
+}
+
 SECTIONS
 {
   /* This must contain the right address - not quite the default ELF one.*/

johannes

Bug#984610: dh-exec: unsatisfiable cross Build-Depends

2021-03-05 Thread Helmut Grohne

Source: dh-exec
Version: 0.23.2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

dh-exec cannot be cross built from source, because its Build-Depends are
not satisfiable. There are two dependencies that are at issue in
particular:
 * perl. It is interpreted as a host architecture perl, which happens to
   conflict with the build architecture one from essential. It really
   wants to run perl, so we should annotate it :any.
 * bats. It is used for running tests and can be skipped via .

Please consider applying the attached patch.

Helmut
diff --minimal -Nru dh-exec-0.23.2/debian/changelog 
dh-exec-0.23.3/debian/changelog
--- dh-exec-0.23.2/debian/changelog 2019-05-18 14:44:04.0 +0200
+++ dh-exec-0.23.3/debian/changelog 2021-03-05 16:46:04.0 +0100
@@ -1,3 +1,11 @@
+dh-exec (0.23.3) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate perl dependency :any.
++ Annotate bats dependency .
+
+ -- Helmut Grohne   Fri, 05 Mar 2021 16:46:04 +0100
+
 dh-exec (0.23.2) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru dh-exec-0.23.2/debian/control dh-exec-0.23.3/debian/control
--- dh-exec-0.23.2/debian/control   2019-05-18 14:44:04.0 +0200
+++ dh-exec-0.23.3/debian/control   2021-03-05 16:46:04.0 +0100
@@ -5,9 +5,9 @@
 Build-Depends: debhelper (>= 9.20151004~), dh-autoreconf,
automake (>= 1:1.11),
libpipeline-dev, pkg-config,
-   perl (>= 5.14.2~),
+   perl:any (>= 5.14.2~),
libdpkg-perl (>= 1.17.14~),
-   bats,
+   bats ,
 Rules-Requires-Root: no
 Standards-Version: 3.9.6
 Homepage: https://github.com/algernon/dh-exec

Bug#984611: libserial: further reduce Build-Depends using the nocheck profile

2021-03-05 Thread Helmut Grohne

Source: libserial
Version: 1.0.0-5
Severity: wishlist
Tags: patch

Thank you for applying my previous Build-Depends-reduction patch. I
looked into libserial again and found another reduction (even though it
does not help cross building): If you pass --disable-tests, you can skip
another two dependencies. I'm attaching a patch for your convenience.

For cross building libserial, likely python3-sip has to change $somehow.

Helmut
diff --minimal -Nru libserial-1.0.0/debian/changelog 
libserial-1.0.0/debian/changelog
--- libserial-1.0.0/debian/changelog2021-02-08 21:30:32.0 +0100
+++ libserial-1.0.0/debian/changelog2021-03-05 12:31:27.0 +0100
@@ -1,3 +1,10 @@
+libserial (1.0.0-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Further reduce Build-Depends via  + --disable-tests. (Closes: 
#-1)
+
+ -- Helmut Grohne   Fri, 05 Mar 2021 12:31:27 +0100
+
 libserial (1.0.0-5) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff --minimal -Nru libserial-1.0.0/debian/control 
libserial-1.0.0/debian/control
--- libserial-1.0.0/debian/control  2021-02-08 21:30:00.0 +0100
+++ libserial-1.0.0/debian/control  2021-03-05 12:31:27.0 +0100
@@ -5,8 +5,8 @@
 Maintainer: Gianfranco Costamagna 
 Uploaders: David Morris 
 Build-Depends: debhelper-compat (= 12),
-   libgtest-dev,
-   libboost-test-dev,
+   libgtest-dev ,
+   libboost-test-dev ,
python3-sip-dev,
 Build-Depends-Indep: python3-sphinx,
  python3-sphinx-rtd-theme,
diff --minimal -Nru libserial-1.0.0/debian/rules libserial-1.0.0/debian/rules
--- libserial-1.0.0/debian/rules2020-03-11 10:19:15.0 +0100
+++ libserial-1.0.0/debian/rules2021-03-05 12:31:19.0 +0100
@@ -3,6 +3,9 @@
 %:
dh $@
 
+override_dh_auto_configure:
+   dh_auto_configure -- --$(if $(filter 
nocheck,$(DEB_BUILD_OPTIONS)),dis,en)able-tests
+
 override_dh_auto_clean:
dh_auto_clean
rm -rf debian/doctrees

Bug#983371: linux: backport binfmt_misc: pass binfmt_misc flags to the interpreter

2021-03-05 Thread Salvatore Bonaccorso

Hi,

On Tue, Feb 23, 2021 at 01:55:31PM +0800, YunQiang Su wrote:
> Package: src:linux
> Version: 5.10.13-1
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20210222=2347961b11d4079deace3c81dceed460c08a8fc1
> 
> This patch is for qemu to be aware whether P flag is set.

At this stage of the release it is to late to add features for
bullseye. But I asked upstream if they consider it stable material at
https://lore.kernel.org/stable/yd42sh5n2sjf9...@eldamar.lan/ .

Given the replies from Sasha and Greg, this is so not an option.

But we can close the bug once the next experimental upload includes
the upstream commit.

Regards,
Salvatore

Bug#983379: linux uml segfault



> Ritesh, can you give the following a spin - it renames sem_init as 
> um_sem_init for UML only?

FWIW, this fixes the issue in my reproducer, so should work here too:

diff --git a/ipc/util.h b/ipc/util.h
index 5766c61aed0e..cfed40ba983c 100644
--- a/ipc/util.h
+++ b/ipc/util.h
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#define sem_init uml_sem_init
 
 /*
  * The IPC ID contains 2 separate numbers - index and sequence number.

johannes

Bug#983379: linux uml segfault

On Fri, 2021-03-05 at 19:03 +, Anton Ivanov wrote:
> 
> I thought of that, but surrendered to the "dark side" of the quick and ugly 
> fix.

:)

> We can do that for the ipc/sem.c - it brings in uaccess.h which
> ultimately pulls uaccess from our asm tree. So if we do it there, it
> will end up in sem.c

Well, most easily you could do it in ipc/util.h, where it's declared. Or
any place that is pulled in by it, e.g. even asm/errno.h.

All ugly though.

johannes

Bug#984609: openrocket: uninstallable: depends on no longer available openjdk-8-jre

Package: openrocket
Version: 15.03.6
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is no longer
installable in sid:

  The following packages have unmet dependencies:
   openrocket : Depends: openjdk-8-jre but it is not installable


Cheers,

Andreas

Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()

2021-03-05 Thread Dennis Filder

Control: tag -1 - patch

On Fri, Mar 05, 2021 at 07:17:24PM +0100, Pino Toscano wrote:

> Did you actually check that it fixes the problem for you?

No, I included the patch more as a hint to the nature of the bug, not
as a fix, but I should have stated that more clearly.

Regards,
Dennis.

Bug#983379: linux uml segfault

On Wed, 2021-03-03 at 23:40 +0100, Johannes Berg wrote:

> Now libcom_err.so.2 is trying to call sem_init(), and that gets ... tada
> ... Linux's sem_init() instead of libpthread's.
> 
> And then the crash.

FWIW, I can trivially reproduce this by simply force-loading
libcom_err.so:


diff --git a/arch/um/Makefile b/arch/um/Makefile
index 1cea46ff9bb7..a16b411154fb 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -134,7 +134,7 @@ LINK_WRAPS = -Wl,--wrap,malloc -Wl,--wrap,free 
-Wl,--wrap,calloc
 LD_FLAGS_CMDLINE = $(foreach opt,$(KBUILD_LDFLAGS),-Wl,$(opt))
 
 # Used by link-vmlinux.sh which has special support for um link
-export CFLAGS_vmlinux := $(LINK-y) $(LINK_WRAPS) $(LD_FLAGS_CMDLINE)
+export CFLAGS_vmlinux := $(LINK-y) $(LINK_WRAPS) $(LD_FLAGS_CMDLINE) -ldl
 
 # When cleaning we don't include .config, so we don't include
 # TT or skas makefiles and don't clean skas_ptregs.h.
diff --git a/arch/um/os-Linux/main.c b/arch/um/os-Linux/main.c
index c8a42ecbd7a2..873dc4c40cb7 100644
--- a/arch/um/os-Linux/main.c
+++ b/arch/um/os-Linux/main.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define PGD_BOUND (4 * 1024 * 1024)
 #define STACKSIZE (8 * 1024 * 1024)
@@ -115,6 +116,8 @@ int __init main(int argc, char **argv, char **envp)
 
setsid();
 
+dlopen("/usr/lib64/libcom_err.so.2", RTLD_NOW|RTLD_GLOBAL);
+
new_argv = malloc((argc + 1) * sizeof(char *));
if (new_argv == NULL) {
perror("Mallocing argv");


johannes

Bug#984608: sword-comm-tdavid: Missing source


Package: sword-comm-tdavid
Severity: serious
Control: forwarded https://tracker.crosswire.org/browse/MOD-404

sword-comm-tdavid is missing source. The suggested decompression 
commands in debian/copyright will not give the original source because 
the translation process is lossy.


I suggest to move the package to non-free or to remove it.

Bug#984607: node-unicode-13.0.0: doesn't provide /RGI_Emoji inside /Sequence_Property, may need update

2021-03-05 Thread Sahil Dhiman

Package: node-unicode-13.0.0
Severity: normal
File: node-unicode-13.0.0
X-Debbugs-Cc: sa...@sahilister.in

Dear Maintainer,

I'm presently working on packaging emoji-regex, which uses unicode-13.0.0.
The package makes request for `node-
unicode-13.0.0/Sequence_Property/RGI_Emoji/index.js` (patched), which isn't
found.

As this package is generated from `node-unicode-data`, on local package
generation, `[..]/RGI_Emoji/` directory isn't generated at all. Bootstrapping
it from upstream repo, does provides this directory as well as
`[..]/Emoji_Test/`.

Debian version - 0.8.0
Upstream version - 1.0.4

I request if the package be updated (or `node-unicode-data` be checked for
updates).

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

Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#984606: sword-comm-scofield: Missing source


Package: sword-comm-scofield
Severity: serious
Control: forwarded https://tracker.crosswire.org/browse/MOD-402

sword-comm-scofield is missing source. The suggested decompression 
commands in debian/copyright will not give the original source because 
the translation process is lossy.


I suggest to move the package to non-free or to remove it.

Bug#984526: RFS: sword-text-kjv

The claim about the eBible version supposedly not being in public domain 
was only asserted directed towards the crown copyright. Nobody actually 
came up with a copyright violation claim against eBible.


That said, I imported the engKJV2006eb version with its USFX source.
The sword module is not built from source because Debian is missing 
haiola: #984600. I guess, this is not what a package should look like 
but it is far better than having a non-free upstream in main.

Bug#984593: libmutter-7-0: gnome-shell segfaults because monitor_mode contains null pointer.

2021-03-05 Thread Bernhard Übelacker


Package: libmutter-7-0
Version: 3.38.3-2
Severity: normal
X-Debbugs-Cc: bernha...@mailbox.org

Dear Maintainer,
I tried to replicate #982572, therefore
setup a qemu VM with two qxl devices [1].

This is currently running a kernel 5.2 due to #983934.

Inside I have trouble with mouse input,
therefore activated remote access by keyboard.
(Unfortunately can just access one of the
two screens with this method.)

On that screen I did some resolution changes and
window moves, then gnome-shell crashed.
I have not yet tried to reproduce this or cannot
say if this happens because of this special setup.
Found also no other down- or any upstream bug about this.

It seems that we get in [3] a nullpointer for "monitor_mode",
that gets dereferenced later.

In [2] are the last frames of the backtrace, complete
in attached file.

Kind regards,
Bernhard


[3] 
https://sources.debian.org/src/mutter/3.38.3-3/src/backends/meta-renderer.c/#L228

[2]
(gdb) bt
#0  meta_monitor_mode_foreach_crtc (monitor=monitor@entry=0x55c936bd45a0, 
mode=0x0, func=func@entry=0x7fbadddaf010 , 
user_data=user_data@entry=0x7fff8032e9e0, error=error@entry=0x0) at 
../src/backends/meta-monitor.c:1912
#1  0x7fbadddaefe5 in meta_renderer_real_get_views_for_monitor 
(renderer=, monitor=0x55c936bd45a0) at 
../src/backends/meta-renderer.c:228
#2  0x7fbadde3190f in is_redraw_queued (monitor_src=0x7fbacc039150) at 
../src/backends/meta-screen-cast-monitor-stream-src.c:210
#3  sync_cursor_state (monitor_src=0x7fbacc039150) at 
../src/backends/meta-screen-cast-monitor-stream-src.c:228
#4  0x7fbadeab80a2 in g_closure_invoke (closure=0x55c9376dd460, 
return_value=return_value@entry=0x0, n_param_values=1, 
param_values=param_values@entry=0x7fff8032ebd0, 
invocation_hint=invocation_hint@entry=0x7fff8032eb50) at 
../../../gobject/gclosure.c:810
#5  0x7fbadeaca602 in signal_emit_unlocked_R 
(node=node@entry=0x55c936648d40, detail=detail@entry=0, 
instance=instance@entry=0x7fbac0002280, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7fff8032ebd0) at 
../../../gobject/gsignal.c:3809
#6  0x7fbadead06cf in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7fff8032ed50) at ../../../gobject/gsignal.c:3495
#7  0x7fbadead0c3f in g_signal_emit (instance=, 
signal_id=, detail=) at ../../../gobject/gsignal.c:3551
#8  0x7fbadde4cdba in meta_wayland_pointer_set_focus (pointer=0x55c936be7820, 
surface=) at ../src/wayland/meta-wayland-pointer.c:973
#9  0x7fbadde4d40d in repick_for_event (pointer=0x55c936be7820, 
for_event=) at ../src/wayland/meta-wayland-pointer.c:640
...

[1] -spice port=5930,addr=$LOCALIP,disable-ticketing -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1
 -device 
qxl,id=video1,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1




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

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

Versions of packages libmutter-7-0 depends on:
ii  adwaita-icon-theme 3.38.0-1
ii  gsettings-desktop-schemas  3.38.0-2
ii  libatk1.0-02.36.0-2
ii  libc6  2.31-9
ii  libcairo-gobject2  1.16.0-5
ii  libcairo2  1.16.0-5
ii  libcanberra0   0.30-7
ii  libdrm22.4.104-1
ii  libegl11.3.2-1
ii  libfontconfig1 2.13.1-4.2
ii  libfribidi01.0.8-2
ii  libgbm120.3.4-1
ii  libgdk-pixbuf-2.0-02.42.2+dfsg-1
ii  libgl1 1.3.2-1
ii  libglib2.0-0   2.66.7-1
ii  libgnome-desktop-3-19  3.38.4-1
ii  libgraphene-1.0-0  1.10.4+dfsg1-1
ii  libgtk-3-0 3.24.24-1
ii  libgudev-1.0-0 234-1
ii  libice62:1.0.10-1
ii  libinput10 1.16.4-3
ii  libjson-glib-1.0-0 1.6.2-1
ii  libpango-1.0-0 1.46.2-3
ii  libpangocairo-1.0-01.46.2-3
ii  libpangoft2-1.0-0  1.46.2-3
ii  libpipewire-0.3-0  0.3.19-4
ii  libsm6 2:1.2.3-1
ii  libstartup-notification0   0.12-6+b1
ii  libsystemd0247.3-1
ii  libudev1   247.3-1
ii  libwacom2  1.8-2
ii  libwayland-server0 1.18.0-2~exp1.1
ii  libx11-6   2:1.7.0-2
ii  libx11-xcb12:1.7.0-2
ii  libxau61:1.0.9-1
ii  libxcb-randr0  1.14-3
ii  libxcb-res01.14-3
ii  libxcb11.14-3
ii

Bug#984526: [pkg-crosswire-devel] Bug#984526: sword-text-kjv: Package is non-free

2021-03-05 Thread Fr Cyrille




Le 04/03/2021 à 20:56, Bastian Germann a écrit :

Am 04.03.21 um 20:33 schrieb Teus Benschop:

Here is an article on the copyright issues with regard to the KJV.
https://en.wikipedia.org/wiki/King_James_Version#Copyright_status

It says, among many other things that "The Authorized Version is in the
public domain in most of the world. However, in the United Kingdom, the
right to print, publish and distribute it is a royal prerogative..."

It's a bit messy, it looks. Reading over it, I am not sure that the 
KJV is

free to be distributed in Debian.


This was discussed in #338077 and found to be okay (because it is a 
Commonwealth problem only). This is not the problem here. It is the 
editions by CrossWire that are non-free.


Earlier faults in history are continuing to harass us and limit the 
word of

God somehow.
In the 17th century there was not even the concept of copyright. When 
copyright was invented, the English Crown retrospectively applied that 
concept to the KJV.




___
pkg-crosswire-devel mailing list
pkg-crosswire-de...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-crosswire-devel

Bug#983379: linux uml segfault

2021-03-05 Thread Anton Ivanov





On 05/03/2021 18:32, Johannes Berg wrote:



On 5 March 2021 18:39:42 CET, Anton Ivanov  
wrote:



On 04/03/2021 07:47, Johannes Berg wrote:

On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:


Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we could somehow rename sem_init()? Or maybe

we

can somehow give the kernel binary a lower symbol resolution than

the

libc/libpthread.


objcopy (from binutils) can localize symbols (i.e., objcopy -L
sem_init $orig_file $new_file).  It also does renaming symbols.  But
not sure this is the ideal solution.


Yes, we started thinking about it but it was too late at night when I
replied ...

I think there's basically a way to have an external list of symbols

to

export, for symbol versioning, that we could/should use to basically

not

export any of the kernel symbols out to libs.


How does UML handle symbol conflicts between userspace code and

Linux

kernel (like this case sem_init) ?  AFAIK, libnl has a same symbol

as

Linux kernel (genlmsg_put) and others can possibly do as well.


I fear it doesn't?


Let's assume it does not, and try to fix this by de-conflicting the
symbol.
For the time being, also, let's aim for a Debian specific patch just to
go into their "patches" dir for build so that UML is not dropped out of
the release.

This should make all internal uses of sem_init be um_sem_init in the
actual object files. I will chase the issue of it picking up glibc
memcpy separately.
Upon close inspection it looks like a different issue - it is in the
other direction (picking a dynamic symbol instead of the one from the
tree). I spent all day chasing it today and I cannot reproduce it. At
the same time it was reproducible yesterday without any problems :(



+#ifdef CONFIG_UML
+void __init um_sem_init(void)
+#else
  void __init sem_init(void)
+#endif


Might be easier to just

#define sem_init um_sem_init

in an appropriate header file, perhaps even in arch/um/?


I thought of that, but surrendered to the "dark side" of the quick and ugly fix.

We can do that for the ipc/sem.c - it brings in uaccess.h which ultimately 
pulls uaccess from our asm tree. So if we do it there, it will end up in sem.c

However, that function is also referenced and is invoked out of ipc/util.c 
which does not pull that include.

I am going to dig through the rest of our includes to see if we can find a suitable one 
which will be picked up by both sem.c and util.c. I hope there is a place which we can 
use for a "proper" fix.

By the way, I actually remember seeing a couple of includes like that somewhere 
dealing with other um symbol conflicts, just can't remember where I saw it.




johannes



--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#984605: unblock: debian-edu-config/2.11.51

2021-03-05 Thread Holger Levsen

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
x-debbugs-cc: debian-...@lists.debian.org

Hi,

please unblock package debian-edu-config, the debdiff is small and self 
explaining
and fixes an important bug:

$ debdiff debian-edu-config_2.11.50.dsc debian-edu-config_2.11.51.dsc
diff -Nru debian-edu-config-2.11.50/cf3/cf.dhcpserver 
debian-edu-config-2.11.51/cf3/cf.dhcpserver
--- debian-edu-config-2.11.50/cf3/cf.dhcpserver 2021-01-31 18:38:48.0 
+0100
+++ debian-edu-config-2.11.51/cf3/cf.dhcpserver 2021-03-05 18:52:59.0 
+0100
@@ -32,6 +32,8 @@
 
 "/usr/bin/systemctl enable isc-dhcp-server.service"
   contain => in_shell;
+"/usr/bin/touch /var/lib/dhcp/dhcpd.leases"
+  contain => in_shell;
 "/usr/bin/systemctl restart isc-dhcp-server.service"
   contain => in_shell;
 }
diff -Nru debian-edu-config-2.11.50/debian/changelog 
debian-edu-config-2.11.51/debian/changelog
--- debian-edu-config-2.11.50/debian/changelog  2021-02-16 15:39:04.0 
+0100
+++ debian-edu-config-2.11.51/debian/changelog  2021-03-05 19:58:03.0 
+0100
@@ -1,3 +1,11 @@
+debian-edu-config (2.11.51) unstable; urgency=medium
+
+  [ Wolfgang Schweer ]
+  * cf3/cf.dhcpserver: Make sure the dhcpd.leases file exists. Closes: #984596.
+(Without a leases file, isc-dhcp-server remains in starting stage forever.)
+
+ -- Holger Levsen   Fri, 05 Mar 2021 19:58:03 +0100
+

unblock debian-edu-config/2.11.51

Thanks for all your work on bullseye!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁   holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀ PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C
 ⠈⠳⣄

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes... (Greta Thunberg)


signature.asc
Description: PGP signature

Bug#869534: ITP: ptpython -- Alternative Python Prompt

2021-03-05 Thread Daniel Baumann

Hi Andrej

On 3/5/21 7:19 PM, Andrej Shadura wrote:
> push my work so that you can take bits from it and merge with
> whatever you have:

no problem :)

thanks, and thanks for doing the prompt-toolkit upload, too.

I've now uploaded my ptpython to NEW. jftr there's the diff between the
two packages attached. I'll happily merge the things where it makes
sense in the subsequent upload.

Regards,
Daniel
diff -Naurp /srv/git/daniel/ptpython/debian/changelog debian/changelog
--- /srv/git/daniel/ptpython/debian/changelog	2021-03-01 20:19:30.279540055 +0100
+++ debian/changelog	2021-03-05 19:47:22.796978707 +0100
@@ -1,5 +1,5 @@
-ptpython (3.0.16-1) sid; urgency=medium
+ptpython (3.0.16-1) unstable; urgency=low
 
-  * Initial upload to sid (Closes: #869534).
+  * Initial upload.
 
- -- Daniel Baumann   Fri, 26 Feb 2021 05:10:41 +0100
+ -- Andrej Shadura   Fri, 05 Mar 2021 19:06:27 +0100
diff -Naurp /srv/git/daniel/ptpython/debian/control debian/control
--- /srv/git/daniel/ptpython/debian/control	2021-03-01 20:21:58.603091620 +0100
+++ debian/control	2021-03-05 19:47:22.796978707 +0100
@@ -1,36 +1,40 @@
 Source: ptpython
+Maintainer: Andrej Shadura 
+Uploaders: Debian Python Team 
 Section: python
 Priority: optional
-Maintainer: Daniel Baumann 
 Build-Depends:
  debhelper-compat (= 13),
  dh-python,
- python3,
+ dh-sequence-python3,
+ python3-all,
+ python3-appdirs,
+ python3-setuptools,
+ python3-jedi (>= 0.16.0),
  python3-prompt-toolkit (>= 3.0.16),
  python3-pygments,
- python3-setuptools,
-Rules-Requires-Root: no
 Standards-Version: 4.5.1
 Homepage: https://github.com/prompt-toolkit/ptpython
-Vcs-Browser: https://git.progress-linux.org/users/daniel.baumann/debian/packages/ptpython
-Vcs-Git: https://git.progress-linux.org/users/daniel.baumann/debian/packages/ptpython
+Vcs-Browser: https://salsa.debian.org/python-team/packages/ptpython
+Vcs-Git: https://salsa.debian.org/python-team/packages/ptpython.git
 
-Package: ptpython
-Section: python
+Package: python3-ptpython
 Architecture: all
 Depends:
- python3-prompt-toolkit (>= 3.0.16),
  ${misc:Depends},
  ${python3:Depends},
-Description: Alternative Python Prompt with auto-completion and syntax highlighting
- Ptpython is an advanced Python REPL:
+Description: advanced Python REPL
+ Ptpython is an advanced terminal-based Python REPL.
+ .
+ Features:
+ .
+  * Syntax highlighting.
+  * Multiline editing (the up arrow works)
+  * Autocompletion
+  * Mouse support
+  * Support for color schemes
+  * Support for bracketed paste (disabled by default)
+  * Vi and Emacs key bindings
+  * Support for double-width characters
  .
-   * Syntax highlighting.
-   * Multiline editing (the up arrow works).
-   * Autocompletion.
-   * Mouse support.
-   * Support for color schemes.
-   * Support for bracketed paste.
-   * Both Vi and Emacs key bindings.
-   * Support for double width (Chinese) characters.
-   * ...and many other things.
+ Ptpython is built using prompt_toolkit.
diff -Naurp /srv/git/daniel/ptpython/debian/copyright debian/copyright
--- /srv/git/daniel/ptpython/debian/copyright	2021-03-04 20:25:38.063415553 +0100
+++ debian/copyright	2021-03-05 19:47:22.796978707 +0100
@@ -1,14 +1,12 @@
 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: ptpython
-Upstream-Contact: Jonathan Slenders 
-Source: https://github.com/prompt-toolkit/ptpython/releases
 
 Files: *
-Copyright: 2015-2020 Jonathan Slenders 
+Copyright: 2014—2021, Jonathan Slenders 
 License: BSD-3-clause
 
 Files: debian/*
-Copyright: 2021 Daniel Baumann 
+Copyright: 2021, Andrej Shadura 
 License: BSD-3-clause
 
 License: BSD-3-clause
@@ -22,7 +20,7 @@ License: BSD-3-clause
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
  .
- * Neither the name of the organization nor the names of its
+ * Neither the name of the {organization} nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
  .
diff -Naurp /srv/git/daniel/ptpython/debian/gbp.conf debian/gbp.conf
--- /srv/git/daniel/ptpython/debian/gbp.conf	1970-01-01 01:00:00.0 +0100
+++ debian/gbp.conf	2021-03-05 19:47:22.796978707 +0100
@@ -0,0 +1,3 @@
+[DEFAULT]
+debian-branch = debian/unstable
+upstream-branch = upstream/latest
diff -Naurp /srv/git/daniel/ptpython/debian/rules debian/rules
--- /srv/git/daniel/ptpython/debian/rules	2021-03-01 20:19:30.279540055 +0100
+++ debian/rules	2021-03-05 19:47:22.796978707 +0100
@@ -1,6 +1,5 @@
 #!/usr/bin/make -f
 
 export PYBUILD_NAME=ptpython
-
 %:
-	dh ${@} --buildsystem=pybuild --with python3
+	dh "$@" --buildsystem=pybuild
diff -Naurp /srv/git/daniel/ptpython/debian/upstream/metadata debian/upstream/metadata
--- /srv/git/daniel/ptpython/debian/upstream/metadata	1970-01-01 01:00:00.0 +0100
+++ debian/upstream/metadata	2021-03-05 19:47:22.796978707 +0100
@@ -0,0 +1,5 @@
+---

Bug#984590: Patch update for #984590

2021-03-05 Thread Mike Gabriel


Hi,

the correct fix to scanlogd.init is this:

```
commit b8ce8248b1b54f2f2173ac34d358a944235d6685 (HEAD -> master)
Author: Mike Gabriel 
Date:   Fri Mar 5 15:36:20 2021 +0100

debian/scanlogd.init: RDIR/empty must not be writeable by the  
user that scanlogd runs as. (Closes: #984590).


diff --git a/debian/scanlogd.init b/debian/scanlogd.init
index 1095d97..38c1bdf 100644
--- a/debian/scanlogd.init
+++ b/debian/scanlogd.init
@@ -33,8 +33,9 @@ set -e
 umask 022
 if [ ! -d $RDIR/empty ]; then
 mkdir -p $RDIR/empty
-chown -R scanlogd:nogroup $RDIR
 fi
+chown scanlogd:nogroup $RDIR
+chown root:root $RDIR/empty

 case "$1" in
   start)
```

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



pgpIUJZ4DzJJZ.pgp
Description: Digitale PGP-Signatur

Bug#984591: ITP: nspark -- nspark extracts archives created by SparkFS and ArcFS

2021-03-05 Thread Dave Lambley

Package: wnpp
Severity: wishlist
Owner: Dave Lambley 

* Package name: nspark
  Version : 1ae314734375fe6fd041a94cf4003a674e3adbd0
  Upstream Author : James Woodcock 
* URL : https://github.com/mjwoodcock/nspark
* License : Custom
  Programming Lang: C
  Description : nspark extracts archives created by SparkFS and ArcFS

This is a simple utility which I keep wishing was aleady packaged.  It is used
for extracting archives generated by RISC OS software, which are not supported
by Info-ZIP.  It is mentioned in,

https://wiki.debian.org/PaulWise/InterestingSoftware

The program dates back to 1992.  While there has not been a versioned release
since 1999, it's safe to describe it as "stable".  It continues to be
maintained.

As I am not a Debian Developer, I will need a sponsor.

All the best,
Dave

Bug#984592: musescore-common: fails to remove: rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory

2021-03-05 Thread Thorsten Glaser

Andreas Beckmann dixit:

> Which is another point for *shipping* the directories to let dpkg do the
> refcounting, otherwise the manually created directory gets removed by dpkg
> removing a different package.

Hmh, good point.

> On 05/03/2021 16.17, Thorsten Glaser wrote:
>>> Why don't you ship the three empty directories in the package?
>>
>> lintian considers that an error.
>
> which can be overridden if you intentionally want to ship empty
> directories as in this case

Hmm…

| Tag: package-contains-empty-directory
| Severity: info
| Check: files/empty-directories
| Explanation: This package installs an empty directory. This might be 
intentional
|  but it's normally a mistake. If it is intentional, add a Lintian override.
|  .
|  If a package ships with or installs empty directories, you can remove them
|  in debian/rules by calling:
|  .
|   $ find path/to/base/dir -type d -empty -delete

So overriding this if the empty directory is deliberate is not only
okay but actually considered normal and perhaps even perferrable?

Maybe some wording could be added in lintian, so that’s clearer.
The mere _existence_ of that tag (perhaps also in linda, back then)
scared me away from ever shipping empty directories in Debian…

I’ll reconsider that later, for now I’ve plugged the issue differently.

Thanks,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#984422: xwelltris: ftbfs with GCC-11

2021-03-05 Thread Nilesh Patra

control: tags -1 patch

The  patch fixes this if seems ok, please consider to apply

Nilesh

--- a/src/sdl/sdlwelldrawing.cxx
+++ b/src/sdl/sdlwelldrawing.cxx
@@ -72,7 +72,7 @@
 
 fields[i]=SDL_DisplayFormat(surface);
 SDL_FreeSurface(surface);
-    if(fields[i]>0)
+    if(fields[i]!=0)
     clear_field(i);
 }
 bg_color=colors[BackColor];

Bug#983379: linux uml segfault




On 5 March 2021 18:39:42 CET, Anton Ivanov  
wrote:
>
>
>On 04/03/2021 07:47, Johannes Berg wrote:
>> On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:
>> 
 Now, I don't know how to fix it (short of changing your nsswitch
 configuration) - maybe we could somehow rename sem_init()? Or maybe
>we
 can somehow give the kernel binary a lower symbol resolution than
>the
 libc/libpthread.
>>>
>>> objcopy (from binutils) can localize symbols (i.e., objcopy -L
>>> sem_init $orig_file $new_file).  It also does renaming symbols.  But
>>> not sure this is the ideal solution.
>> 
>> Yes, we started thinking about it but it was too late at night when I
>> replied ...
>> 
>> I think there's basically a way to have an external list of symbols
>to
>> export, for symbol versioning, that we could/should use to basically
>not
>> export any of the kernel symbols out to libs.
>> 
>>> How does UML handle symbol conflicts between userspace code and
>Linux
>>> kernel (like this case sem_init) ?  AFAIK, libnl has a same symbol
>as
>>> Linux kernel (genlmsg_put) and others can possibly do as well.
>> 
>> I fear it doesn't?
>
>Let's assume it does not, and try to fix this by de-conflicting the
>symbol.
>For the time being, also, let's aim for a Debian specific patch just to
>go into their "patches" dir for build so that UML is not dropped out of
>the release.
>
>This should make all internal uses of sem_init be um_sem_init in the
>actual object files. I will chase the issue of it picking up glibc
>memcpy separately.
>Upon close inspection it looks like a different issue - it is in the
>other direction (picking a dynamic symbol instead of the one from the
>tree). I spent all day chasing it today and I cannot reproduce it. At
>the same time it was reproducible yesterday without any problems :(

>+#ifdef CONFIG_UML
>+void __init um_sem_init(void)
>+#else
>  void __init sem_init(void)
>+#endif

Might be easier to just

#define sem_init um_sem_init

in an appropriate header file, perhaps even in arch/um/? 


johannes
-- 
Sent from my phone.

Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()

2021-03-05 Thread Dmitry Shachnev

Control: tags -1 -patch

Hi Pino!

On Fri, Mar 05, 2021 at 07:17:24PM +0100, Pino Toscano wrote:
> Did you actually check that it fixes the problem for you?
> The thing is, in C++ (at least since C++98) the delete operator is
> defined to be a no-op for a null pointer, much like free() in C.
> Hence, constructs like "if (foo) delete foo;" are essentially doing
> null pointer checks twice, and with the same no-op result.
>
> A possible cause of the crash could be that the item being deleted was
> already deleted, and thus there was a stale pointer somewhere. That is
> my own speculation though.
>
> Because of this, I'm inclined to remove the "patch" tag from this bug;
> I'd like to hear from Dmitry what he thinks about it (since he already
> handled this bug).

I agree with you, the patch is probably not going to work.

Unfortunately, I did not have time to investigate this properly yet, but
I answered some upstream's questions and I hope they will fix it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#983994: bloboats: ftbfs with GCC-11

2021-03-05 Thread Nilesh Patra

The following patch seems to fix it. If seems appropriate, please consider 
applying

Thanks,
Nilesh


--- a/src/menu.cpp
+++ b/src/menu.cpp
@@ -1567,7 +1567,7 @@
 // Get resolutions
 vector resolutions;
 SDL_Rect** modes = SDL_ListModes(NULL, 
SDL_FULLSCREEN|SDL_HWSURFACE|SDL_OPENGL);
-    if(modes > 0) {
+    if(modes != 0) {
     Uint32 bpp = SDL_GetVideoInfo()->vfmt->BitsPerPixel;
     for(int i=0; modes[i] && i < 10; ++i) {
         Resolution resolution;

Bug#869534: ITP: ptpython -- Alternative Python Prompt

2021-03-05 Thread Andrej Shadura

Hi Daniel,

On Fri, 26 Feb 2021 08:25:24 +0100 Daniel Baumann
 wrote:
> retitle 869534  ITP: ptpython -- Alternative Python Prompt
> owner 869534 Daniel Baumann 
> thanks

I know this is my fault, but I prepared a package for ptpython not
having checked for an ITP in advance. I later found the ITP but decided
to push my work so that you can take bits from it and merge with
whatever you have:

https://salsa.debian.org/python-team/packages/ptpython

-- 
Cheers,
  Andrej

Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()

2021-03-05 Thread Pino Toscano

Hi Dennis,

In data venerdì 26 febbraio 2021 22:48:43 CET, Dennis Filder ha scritto:
> If you decide to use the attached patch, please put the bugnumber in
> the Bug-Debian: field for me.

The patch you provided is the following:

--- qtdeclarative-opensource-src-5.15.2+dfsg/src/quick/items/qquickitem.cpp 
2021-02-26 18:48:50.407487828 +0100
+++ qtdeclarative-opensource-src-5.15.2+dfsg/src/quick/items/qquickitem.cpp 
2021-02-26 18:48:52.711491373 +0100
@@ -8335,8 +8335,8 @@

 QQuickItemLayer::~QQuickItemLayer()
 {
-delete m_effectSource;
-delete m_effect;
+if (m_effectSource) delete m_effectSource; // FIXME: consider Q_ASSERT() 
here instead
+if (m_effect) delete m_effect; // FIXME: consider Q_ASSERT() here instead
 }

 /*!

Did you actually check that it fixes the problem for you?
The thing is, in C++ (at least since C++98) the delete operator is
defined to be a no-op for a null pointer, much like free() in C.
Hence, constructs like "if (foo) delete foo;" are essentially doing
null pointer checks twice, and with the same no-op result.

A possible cause of the crash could be that the item being deleted was
already deleted, and thus there was a stale pointer somewhere. That is
my own speculation though.

Because of this, I'm inclined to remove the "patch" tag from this bug;
I'd like to hear from Dmitry what he thinks about it (since he already
handled this bug).

-- 
Pino Toscano

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

Bug#981515: kcoreaddons: please replace fam with gamin

2021-03-05 Thread Pino Toscano

In data venerdì 5 marzo 2021 18:16:18 CET, Glenn Strauss ha scritto:
> On Fri, Mar 05, 2021 at 05:12:17PM +0100, Pino Toscano wrote:
> 
> > Personally, I'd argue that switching the FAM implementation across the
> > distribution _is_ a "transition", and as such it ought to have been
> > requested (if not even started) two months ago.
> 
> In July 2020, #966273 was filed: RFA: fam -- File Alteration Monitor
> 
> I posted in October 2020 on that bug where FAM was abandoned.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15
> Debian developers did not suggest "next steps" for over 3 months,
> until the freeze occurred.
> 
> The bug was not touched by a Debian Developer until 31 Jan 2021.

This message was addressed only to bugs, one of them was assigned to
"wnpp" and the other to libgamon0: this means that only the gamin
maintainer (1 specific person, as there is no group maintenance) and
who watches the bugs of wnpp and src:gamin actually read it.

Becuase of this, its audience was limited, and neither the general
list for Debian development (debian-devel) nor the release team
(release-team) were notified/aware of it by default.

I can understand your frustation, but that is not a reason to rush
things just because of this. All the deadline for Debian releases have
been more or less streamlined/standardized for at least the past 2
stable releases already, so every step is well known in advance.
Because of this, for example, we were not able to provide Plasma 5.12
in Bullseye.

> The solution is to remove FAM.

And nobody, really, *nobody* ever said the opposite, so please stop
repeating that it is not wanted.

> Back on topic:
> 
> If you take a moment to look in the kcoreaddons code, you can see that
> kcoreaddons has multiple mechanisms for filesystem notification.
> If FAM interfaces fail for any reason, kcoreaddons switches to an
> alternative mechanism.
>   
> https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.cpp#L1611
> 
> Therefore, your FUD is unsubstantiated.  Changing kcoreaddons to use
> gamin, or to not use FAM or gamin, are both reasonable options.
> As I posted in
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#49
> gamin can be configured to poll NFS locations and so is a reasonable
> substitution for FAM, not limited to inotify() as Sune suggested in
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#39

Sure, I well know that KDirWatch in kcoreaddons builds fine with either
libfam or gamin as "FAM", I remember people doing this many years ago
in other distributions. However, what I said is something completely
different, let me summarize it in short points for easier understanding:
- I am fine switching from libfam to gamin in the future
- I am fine dropping libfam from Debian in the future
- I want first libgamin to stop providing libfam
- switching from libfam from gamin *is* switching FAM implementation,
  and thus which code is used for "FAM", and possibily different bugs;
  hence, this is *too late* to properly test is in Bullseye

There is no FUD in what I said.

> It is true that this relatively safe change is being requested during
> the soft freeze and so should be scrutinized.  However, that does not
> make the requested change any more or less dangerous.  It does mean
> less time to test by people who, in your own words, might not be using
> this feature:
> > and these FAM/gamin bits do not get much of use these days

So if, "less time to test by people who [...] might not be using this
feature", this switch is even more dangerous. Thanks from proving my
point.

> I posit that the code in upstream kcoreaddons is already better tested
> than would be Debian "testing" (existence in tree?) of an additional
> month or two or three of the Debian kcoreaddons package configured to
> use gamin (or to use neither FAM nor gamin).

This "additional month or two or three" we are talking about is called
"Debian freeze". Dependency changes like this are very much *not* the
kind of changes we want to introduce during a freeze.

-- 
Pino Toscano

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

Bug#984603: puppet-master-passenger crashes when ruby-scanf is not installed

2021-03-05 Thread Frederik

Package: puppet-master-passenger
Version: 5.5.22-1
Severity: normal

Dear Maintainer,

I upgraded my system running puppet-master-passenger from Buster to
bullseye. From that moment on, puppet-master-passenger crashed when a
client tries to retriveve its configuration. The follow stacktrace could
be found in the Apache error.log:

App 25308 stderr: [ 2021-03-05 18:58:49.5455 28292/0x56253d9b7cc0(Worker 1) 
utils.rb:87 ]: *** Exception LoadError (cannot load such file -- scanf) 
(process 28292, thread 0x56253d9b7cc0(Worker 1)):
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/rubygems/core_ext/kernel_require.rb:85:in `require'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/functions/scanf.rb:29:in `block in get_binding'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/functions.rb:250:in `class_eval'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/functions.rb:250:in `create_loaded_function'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/functions.rb:191:in `create_function'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/functions/scanf.rb:28:in `get_binding'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/ruby_function_instantiator.rb:22:in
 `eval'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/ruby_function_instantiator.rb:22:in
 `create'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/module_loaders.rb:263:in 
`instantiate'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/module_loaders.rb:237:in `find'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:161:in 
`internal_load'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:42:in `load_typed'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:153:in 
`internal_load'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:42:in `load_typed'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:153:in 
`internal_load'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:42:in `load_typed'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:153:in 
`internal_load'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:42:in `load_typed'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:153:in 
`internal_load'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/base_loader.rb:42:in `load_typed'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/loader/loader.rb:72:in `load'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/runtime3_support.rb:302:in 
`call_function'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:964:in 
`call_function_with_block'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:959:in 
`eval_CallMethodExpression'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/visitor.rb:90:in `visit_this_1'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:81:in 
`evaluate'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:370:in 
`eval_AssignmentExpression'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/visitor.rb:90:in `visit_this_1'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:81:in 
`evaluate'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:660:in `block 
in eval_BlockExpression'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:660:in `each'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:660:in 
`reduce'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:660:in 
`eval_BlockExpression'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/visitor.rb:90:in `visit_this_1'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:81:in 
`evaluate'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:177:in `block 
in evaluate_block_with_bindings'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/parser/scope.rb:983:in `with_guarded_scope'
App 25308 stderr:   from 
/usr/lib/ruby/vendor_ruby/puppet/pops/evaluator/evaluator_impl.rb:173:in 
`evaluate_block_with_bindings'
App 25308 stderr:

Bug#984602: fai-setup: mid-export newlines in /etc/exports

2021-03-05 Thread Matthew Pounsett

Package: fai-server
Version: 5.10
Severity: normal

Dear Maintainer,

I'm a new user of FAI.  I've run a few test setups on VMs and am in the
process of doing the first install on a production server, prepping to build
real installs.

This didn't crop up on single-interface VMs, but in production I've run into a
problem with priming of the /etc/exports file, triggered by the presence of
multiple interface and IP protocols on the server.  At the end of the run of
`fai-setup -v`, the nfs-server fails to load, and it appears the cause is that
it is either failing to strip newlines when it obtains the server IP
addresses, or is erroneously inserting newlines, when it constructs the
exports entries.

For example (indenting added by me, newlines added by fai-setup):

   /srv/fai/config 127.0.0.1/8
   
   
   
   172.16.2.2/30
   
   64.191.0.64/24
   192.168.1.64/24
   192.168.0.64/24
   fe80::fc54:ff:fe78:7dd0/64
   fe80::fc54:ff:fe48:106e/64
   fe80::fc54:ff:fece:417f/64(async,ro,no_subtree_check)

This causes nfs-server.service to fail to start.

Correcting this is an easy problem to solve (remove the newlines) but a newbie
to NFS might take a while to figure that out.


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

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

Versions of packages fai-server depends on:
ii  debootstrap  1.0.114
ii  e2fsprogs1.44.5-1+deb10u3
ii  fai-client   5.10
ii  xz-utils 5.2.4-1

Versions of packages fai-server recommends:
ii  dosfstools4.1-2
ii  isc-dhcp-server   4.4.1-2
ii  libproc-daemon-perl   0.23-1
ii  mtools4.0.23-1
ii  nfs-kernel-server 1:1.3.4-2.5+deb10u1
ii  openbsd-inetd [inet-superserver]  0.20160825-4
ii  openssh-client1:7.9p1-10+deb10u2
ii  openssh-server1:7.9p1-10+deb10u2
ii  tftpd-hpa 5.2+20150808-1+b1

Versions of packages fai-server suggests:
ii  binutils   2.31.1-16
pn  debmirror  
pn  fai-setup-storage  
pn  grub2  
pn  perl-tk
ii  qemu-utils 1:3.1+dfsg-8+deb10u8
ii  reprepro   5.3.0-1
ii  squashfs-tools 1:4.3-12
ii  xorriso1.5.0-1

-- no debconf information

Bug#984595: buster-pu: package samba/2:4.9.5+dfsg-5

2021-03-05 Thread Sebastian Ramacher

On 2021-03-05 16:51:44 +, Vasyl Gello wrote:
> Hi Sebastian!
> 
> > FWIW, the relevant version for buster-backports is ffmpeg
> > 7:4.3.2-0+deb11u1 which does not require libsmbclient-dev. So the bug in
> > samba does not prevent backports of ffmpeg
> 
> Strange, I have noticed that 7:4.3.2-0+deb11u1 sits in debian/bullseye branch 
> of ffmpeg, but not in debian/master.
> What is more strange, 'gbp pull --all' does not populate new branches so 
> there is no way to distinguish from CLI
> if the new Git branch was cut.
> 
> Anyway, I think it is nice to have a fixed samba in buster. Or you are not 
> planning to enable smbclient within ffmpeg
> for bullseye at all?

It's too late to introduce new binary packages in bullseye. The changes
in debian/master are already for bookworm. That's why I have branched of
debian/bullseye before the experimental uploads. smbclient in ffmpeg
won't happen for bullseye.

Cheers

> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#984592: musescore-common: fails to remove: rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory


On 05/03/2021 16.17, Thorsten Glaser wrote:

Why don't you ship the three empty directories in the package?


lintian considers that an error.


which can be overridden if you intentionally want to ship empty 
directories as in this case


On 05/03/2021 17.56, Thorsten Glaser wrote:
> According to 
https://piuparts.debian.org/sid-strict/source/m/musescore2.html

> the musescore-common package succeeds piuparts, too… huh… weird.

triggered by a test of multimedia-musiciantools with 
--install-recommends (in my local piuparts instance) which installs

fluid-soundfont-gm: /usr/share/sounds/sf2/FluidR3_GM.sf2

On 05/03/2021 16.24, Thorsten Glaser wrote:
> Interesting, because this never happened for me, and I cannot
> easily reproduce it either. In a fresh cowbuilder:

try with fluid-soundfont-gm

install fluid-soundfont-gm musescore-common
remove fluid-soundfont-gm
remove musescore-common

Which is another point for *shipping* the directories to let dpkg do the 
refcounting, otherwise the manually created directory gets removed by 
dpkg removing a different package.


Andreas

Bug#984601: inkscape-speleo: Wrong homepage

2021-03-05 Thread Davide Prina


Package: inkscape-speleo
Version: 1.8-4
Severity: normal

I have see that the project homepage do not respond anymore:
http://www.thomas-holder.de/projects/inkscape-speleo/extensions/

I think that the homepage is now:
https://github.com/speleo3/inkscape-speleo

Ciao
Davide

Note: this is a simplified bug report that I use to report homepage 
problems found at https://repology.org/repository/debian_testing/problems

Bug#983379: linux uml segfault

2021-03-05 Thread Anton Ivanov





On 04/03/2021 07:47, Johannes Berg wrote:

On Thu, 2021-03-04 at 14:38 +0900, Hajime Tazaki wrote:


Now, I don't know how to fix it (short of changing your nsswitch
configuration) - maybe we could somehow rename sem_init()? Or maybe we
can somehow give the kernel binary a lower symbol resolution than the
libc/libpthread.


objcopy (from binutils) can localize symbols (i.e., objcopy -L
sem_init $orig_file $new_file).  It also does renaming symbols.  But
not sure this is the ideal solution.


Yes, we started thinking about it but it was too late at night when I
replied ...

I think there's basically a way to have an external list of symbols to
export, for symbol versioning, that we could/should use to basically not
export any of the kernel symbols out to libs.


How does UML handle symbol conflicts between userspace code and Linux
kernel (like this case sem_init) ?  AFAIK, libnl has a same symbol as
Linux kernel (genlmsg_put) and others can possibly do as well.


I fear it doesn't?


Let's assume it does not, and try to fix this by de-conflicting the symbol.
For the time being, also, let's aim for a Debian specific patch just to go into their 
"patches" dir for build so that UML is not dropped out of the release.

This should make all internal uses of sem_init be um_sem_init in the actual 
object files. I will chase the issue of it picking up glibc memcpy separately.
Upon close inspection it looks like a different issue - it is in the other 
direction (picking a dynamic symbol instead of the one from the tree). I spent 
all day chasing it today and I cannot reproduce it. At the same time it was 
reproducible yesterday without any problems :(

Ritesh, can you give the following a spin - it renames sem_init as um_sem_init 
for UML only?

diff --git a/ipc/sem.c b/ipc/sem.c
index f6c30a85dadf..5157796daf54 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -263,7 +263,11 @@ void sem_exit_ns(struct ipc_namespace *ns)
 }
 #endif

+#ifdef CONFIG_UML
+void __init um_sem_init(void)
+#else
 void __init sem_init(void)
+#endif
 {
sem_init_ns(_ipc_ns);
ipc_init_proc_interface("sysvipc/sem",
diff --git a/ipc/util.h b/ipc/util.h
index 5766c61aed0e..b3356efb3c96 100644
--- a/ipc/util.h
+++ b/ipc/util.h
@@ -47,7 +47,12 @@ extern int ipc_min_cycle;
 #define IPCMNI_IDX_MASK((1 << IPCMNI_SHIFT) - 1)
 #endif /* CONFIG_SYSVIPC_SYSCTL */

+#ifdef CONFIG_UML
+void um_sem_init(void);
+#define sem_init() um_sem_init()
+#else
 void sem_init(void);
+#endif
 void msg_init(void);
 void shm_init(void);





johannes




--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#984537: libefl-all-dev should Recommend libeina-bin, libelementary-bin

2021-03-05 Thread Pierre Couderc


On 3/5/21 5:51 PM, Ross Vandegrift wrote:

On Fri, Mar 05, 2021 at 06:49:50AM +0100, Pierre Couderc wrote:

On Thu, Mar 04, 2021 at 10:44:10AM -0800, Ross Vandegrift wrote:

On Thu, Mar 04, 2021 at 06:28:42PM +0100, Pierre Couderc wrote:

But I think there should be some improvement  in libefl-all-dev :
libefl-all-dev is done for efl developers

I need developers tools : at least eina_btlog and elemetary_test at least...

Is it possible ?

Yes, you'll find them in libeina-bin and libelementary-bin.  Probably,
libefl-all-dev should Recommend them.

This would be a nice change for the next release.

Ross

Why not even include them ?

It would be a temporary situation before merged packages come out.
Moving those two binaries is more effort that I'd rather put into the
permanent reorganization.  But adding a Recommends is very simple.

For more on how that might look, see this thread:
https://alioth-lists.debian.net/pipermail/pkg-e-devel/2020-February/003674.html

Ross

Fine !

Bug#981347: [debian-mysql] Bug#981347: mariadb-10.5 FTBFS on kfreebsd

2021-03-05 Thread Glenn Strauss

I believe this bug was addressed in
https://salsa.debian.org/mariadb-team/mariadb-10.5/-/merge_requests/2

Cheers, Glenn

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

2021-03-05 Thread Matthias Klose

yes, the rationale for uncompressed debug sections is that any tool can access
them.  On disk as deb/dbgsym package, there is no big difference in size.  Also
a debuginfod server can be configured to send the debuginfo compressed on the
fly.  The "only" downside is to have the uncomressed debuginfo on the disk when
doing the debugging.

Matthias

Bug#984537: libefl-all-dev should Recommend libeina-bin, libelementary-bin

2021-03-05 Thread Ross Vandegrift

On Fri, Mar 05, 2021 at 06:49:50AM +0100, Pierre Couderc wrote:
> > On Thu, Mar 04, 2021 at 10:44:10AM -0800, Ross Vandegrift wrote:
> > > On Thu, Mar 04, 2021 at 06:28:42PM +0100, Pierre Couderc wrote:
> > > > But I think there should be some improvement  in libefl-all-dev :
> > > > libefl-all-dev is done for efl developers
> > > > 
> > > > I need developers tools : at least eina_btlog and elemetary_test at 
> > > > least...
> > > > 
> > > > Is it possible ?
> > > Yes, you'll find them in libeina-bin and libelementary-bin.  Probably,
> > > libefl-all-dev should Recommend them.
> > This would be a nice change for the next release.
> > 
> > Ross
> 
> Why not even include them ?

It would be a temporary situation before merged packages come out.
Moving those two binaries is more effort that I'd rather put into the
permanent reorganization.  But adding a Recommends is very simple.

For more on how that might look, see this thread:
https://alioth-lists.debian.net/pipermail/pkg-e-devel/2020-February/003674.html

Ross

Bug#981515: kcoreaddons: please replace fam with gamin

2021-03-05 Thread Glenn Strauss

On Fri, Mar 05, 2021 at 05:12:17PM +0100, Pino Toscano wrote:

> Personally, I'd argue that switching the FAM implementation across the
> distribution _is_ a "transition", and as such it ought to have been
> requested (if not even started) two months ago.

In July 2020, #966273 was filed: RFA: fam -- File Alteration Monitor

I posted in October 2020 on that bug where FAM was abandoned.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15
Debian developers did not suggest "next steps" for over 3 months,
until the freeze occurred.

The bug was not touched by a Debian Developer until 31 Jan 2021.

All this reflects poorly on Debian Developers, who we all understand
are volunteers. I am not questioning the skills of Debian Developers.
I am criticizing the execution. The failure to triage bugs in a
timely fashion, the failure to encourage outside contributions, and
the failure to recruit and nurture additional help all reflect poorly
on Debian as a project, as does the 12+ year old bug which is being
deferred, yet again.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=510368
The solution is to remove FAM. It just FUD that is delaying action.
(It is FUD hiding behind policy, since FAM package removal was a
blocking bug for Bullseye.)

Back on topic:

If you take a moment to look in the kcoreaddons code, you can see that
kcoreaddons has multiple mechanisms for filesystem notification.
If FAM interfaces fail for any reason, kcoreaddons switches to an
alternative mechanism.

https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.cpp#L1611

Therefore, your FUD is unsubstantiated. Changing kcoreaddons to use
gamin, or to not use FAM or gamin, are both reasonable options.
As I posted in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#49
gamin can be configured to poll NFS locations and so is a reasonable
substitution for FAM, not limited to inotify() as Sune suggested in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#39

It is true that this relatively safe change is being requested during
the soft freeze and so should be scrutinized. However, that does not
make the requested change any more or less dangerous. It does mean
less time to test by people who, in your own words, might not be using
this feature:
> and these FAM/gamin bits do not get much of use these days

I posit that the code in upstream kcoreaddons is already better tested
than would be Debian "testing" (existence in tree?) of an additional
month or two or three of the Debian kcoreaddons package configured to
use gamin (or to use neither FAM nor gamin).

With that, I've said my piece. I shall not argue further.

Bug#984600: RFP: Haiola Scripture Publishing Software