Bug#969312: localechooser doesn’t display Occitan and Kabyle languages

[Quentin PAGÈS]

Hello, 


any update for this report? 


Best regards 


Quentin PAGÈS 

Bug#916605: torbrowser-launcher: I can't start torbrowser-launcher

[Aidan Gauland]

Package: torbrowser-launcher
Version: 0.3.2-13~bpo10+1
Followup-For: Bug #916605

Dear Maintainer,

I get similar behaviour even after deleting the following directories:
  ~/.local/share/torbrowser/
  ~/.config/torbrowser/
  ~/.cache/torbrowser/

The launcher opens the download progress modal, then while the same
modal shows "Installing", another modal comes up saying:

"The version of Tor Browser you have installed is earlier than it should
be, which could be a sign of an attack!"

with only an OK button.  When I dismiss that, the "Installing" modal
stays up
indefinitely.  If I dismiss that and rerun torbrowser-launcher, I get
this on
stdout

Tor Browser Launcher
By Micah Lee, licensed under MIT
version 0.3.2
https://github.com/micahflee/torbrowser-launcher
qt5ct: using qt5ct plugin
Your version of Tor Browser is out-of-date. Downloading the newest version.
Downloading
https://aus1.torproject.org/torbrowser/update_3/release/Linux_x86_64-gcc3/x/en-US

and exits immediately.

Regards,
Aidan Gauland



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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates   20200601~deb10u1
ii  gnupg 2.2.12-1+deb10u1
ii  libdbus-glib-1-2  0.110-4
ii  python3   3.7.3-1
ii  python3-gpg   1.12.0-6
ii  python3-pyqt5 5.11.3+dfsg-1+b3
ii  python3-requests  2.21.0-1
ii  python3-socks 1.6.8+dfsg-1

Versions of packages torbrowser-launcher recommends:
ii  tor  0.3.5.10-1

Versions of packages torbrowser-launcher suggests:
ii  apparmor  2.13.2-10

-- Configuration Files:
/etc/apparmor.d/local/torbrowser.Browser.firefox changed:
owner /{dev,run}/shm/org.mozilla.*.* rw,


-- no debconf information

Bug#970753: apertium-ind-zlm: Wrong e-mail address in Maintainer field

[Tino Didriksen]

Upstream packaging fixed this for all Apertium and related packages in May,
and this will come through to Debian this week and weekend when I redo all
Apertium packaging.

https://github.com/apertium/apertium-packaging/commit/11357cf6325363a2b4127b0f5fd1bdaaf3726232

-- Tino Didriksen


On Wed, 23 Sep 2020 at 00:38, Alex Muntada  wrote:

> Package: apertium-ind-zlm
> Version: 0.1.2-2
> Severity: serious
> Usertags: alioth-lists.debian.org
> X-Debbugs-Cc: kar...@debian.org, t...@didriksen.cc
>
> The Maintainer of this package uses the alioth-lists.debian.org
> domain, which does not exist. This breaks policy §3.3[1] that
> requires a working e-mail address. You should be using the
> alioth-lists.debian.net domain instead.
>
> After reporting[2] the issue to debian-science-maintainers list,
> I'm filing this bug as suggested[3] there.
>
> Cheers,
> Alex
>
>   [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
>   [2]
> https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085266.html
>   [3]
> https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085350.html
>
> --
>   ⢀⣴⠾⠻⢶⣦⠀
>   ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
>   ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
>   ⠈⠳⣄
>
>

Bug#968042: upgrading packet python2 from 2.7.17-2 up to 2.7.18-2 asks packets deletion

[Luc Maisonobe]

On Sat, 12 Sep 2020 18:54:57 +0200 Diederik de Haas
 wrote:
> On Fri, 07 Aug 2020 18:11:20 +0300 Vladmimir Stavrinov  
> wrote:
> > Now there are no problems with python2 but dependencies are still broken 
> > for 
> > python itself:
> 
> It's now a month later and this problem still exists (on my Debian Sid 
> system).
> Are the following packages supposed to be deleted from the system?
> python python-minimal libpython-stdlib
> 
> I'd still have the python2 variants of those packages installed btw.

I got a similar problem on Debian testing, but with even more weird
consequences.

I did accept to delete the packages, then the packages installation
failed with an error:

Removing update-manager-core (0.200.5-2.1) ...
  File "/usr/sbin/update-python-modules", line 52
print x
  ^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(x)?
dpkg: error processing package update-manager-core (--remove):
 installed update-manager-core package pre-removal script subprocess
returned error exit status 1
dpkg: too many errors, stopping

I tried to add the missing parentheses to update-python-modules, but
the installation failed at a later stage, with another syntax error.

I guessed it was a python2/python3 difference, indeed
/etc/alternatives/python points to python3, perhaps python2 was
half-removed?

So I ended up changing the link back semi-manually using

update-alternatives --install /usr/bin/python python /usr/bin/python2 20

and then

aptitude install update-manager-core

to finish reconfiguring the half-installed package.

Bug#970664: libvte-2.91-0: Terminal not displaying correctly

[Fabián Inostroza]

Hi,

The issue happens with some themes, normally I use Numix from the
repositories, when using HighContrast or HighContrastInverse the issue
also happens. With adwaita it works fine.

Regards.

El lun., 21 sept. 2020 a las 11:51, Fabián Inostroza
() escribió:
>
> Hi,
>
> When I take a screenshot of the whole screen the background of the
> terminal is transparent, that is, if there is another window behind
> then the content of that window is captured, the text of the terminal
> is kept.
> If I take a screenshot of the terminal window then the background is
> transparent, nothing is shown, except text, the alpha channel is zero.
> In both cases I see some other corrupt content on the screen.
>
> The only warning I get when launching gnome-terminal from xterm is
> $ gnome-terminal -v
> # Warning: DESKTOP_STARTUP_ID not set and no fallback available.
>
> then the program detaches from the console.
>
> No related warnings shown on journal or dmesg.
>
> I'm using GNOME with X11 and intel modesetting driver. I've tried all
> combinations of X11, wayland, intel and modesetting driver with the
> same results. My hardware is a thinkpad x230.
>
> Until now I'm not seeing corruption in other applications, just
> gnome-terminal and the gedit terminal plugin. Other terminal
> applications work fine (I've tried xterm and terminator).
>
> Regards.
>
>
>
> El lun., 21 sept. 2020 a las 5:53, Simon McVittie () 
> escribió:
> >
> > Control: tags -1 + moreinfo
> >
> > On Sun, 20 Sep 2020 at 19:29:19 -0300, Fabian Inostroza wrote:
> > > After an upgrade of libvte gnome-terminal and other software using
> > > the library (gedit terminal plugin) doesn't work.
> > > Where the console should be there is some transparency and a effect
> > > similar to when you record a screen that shows what
> > > the camera sees (feedback).
> >
> > If you take a screenshot (please try both a screenshot of the window and
> > a full-screen screenshot), does the display corruption appear in the
> > screenshot, or does the screenshot show what it *should* have looked
> > like?
> >
> > If you run gnome-terminal or another program using vte from a different
> > terminal such as xterm, are warnings shown?
> >
> > Are any warnings logged in the systemd journal when you run a program
> > that uses vte for the first time in a session?
> >
> > What desktop environment are you using? If it's GNOME, are you in Wayland
> > or Xorg mode?
> >
> > What graphics hardware are you using? If both open-source and proprietary
> > drivers are available, which one are you using? (Some common graphics
> > hardware on PC: Intel integrated graphics with DRI/Mesa open-source
> > drivers, AMD Radeon series with DRI/Mesa open-source drivers, NVIDIA
> > with DRI/Mesa "nouveau" open-source drivers, or NVIDIA with proprietary
> > "nvidia-driver".)
> >
> > Do you see similar graphical corruption anywhere else?
> >
> > gnome-terminal is working fine for me in GNOME 3.36 in a qemu virtual
> > machine with QXL graphics, and in GNOME 3.38 from experimental on real
> > hardware (a Lenovo Thinkpad) with Intel graphics, so I'm not going to
> > be able to debug this unless we can isolate what is happening differently
> > on your system.
> >
> > smcv

Bug#966846: Kernel panic (4.19.0-10): RIP __cgroup_bpf_run_filter_skb

[Michel Le Bihan]

Hello,

I'm a bit late but I also have this issue and it occurs every several
hours on my server. Here is the trace if anybody is still interested: 
https://lebihan.pl/files/trace.txt

When can I expect the new package to be uploaded into stable?

Michel Le Bihan

Bug#970618: RFS: wwl/1.3+db-3 [QA] -- Calculates distance and azimuth between two Maidenhead locators

[Francisco Vilmar Cardoso Ruviaro]

Hi Tobias,

thanks for creating https://salsa.debian.org/debian/wwl,
I pushed it into the repository.

Regards
-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#892058: debian-keyring: please automatically send reminder emails to people whose keys will expire soon

[Vagrant Cascadian]

I too would like to have such a service available, having let my key
expire again recently.

I've sometimes set up a local cron job to nudge me by checking the
installed debian-keyring package, but that package doesn't always get
updated (and I occasionally hear it's been talked of not including a
package at all?). I kind of liked not having to have network access
(other than normal package updating processes).

Maybe I could run a cron job polling keyring.debian.org directly on some
debian infrastructure instead (any suggestions where?)... but if I'm
doing this for myself, others surely could use it too; a shared cron job
that people could call to opt in to might be nice, and then they could
control the email address to send and how often they want the reminders
themselves...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#914813: Configuration for BananaPi M3 in Armbian

[Vagrant Cascadian]

Control: tags 914813 pending

On 2020-09-22, Bernhard wrote:
> Attached, there is the current kernel configuration in Armbian.
> Here, there is RSB configured:
>> CONFIG_MFD_AXP20X=y
>> CONFIG_MFD_AXP20X_I2C=y
>> CONFIG_MFD_AXP20X_RSB=y

CONFIG_MFD_AXP20X_RSB=y is also in noteworthy upstream defconfigs:

arch/arm/configs/multi_v7_defconfig:CONFIG_MFD_AXP20X_RSB=y
arch/arm/configs/sunxi_defconfig:CONFIG_MFD_AXP20X_RSB=y


> Can you please enable RSB in current kernel configuration in sid/experimental?

Pushed to sid, should be in next upload to sid:

  
https://salsa.debian.org/kernel-team/linux/-/commit/3a72e77dde965d9ea38eea6c9b7b502fe2fc9875


> As i wrote in my previous message:
> If you provide me a SD-Card image with enabled RSD in kernel, i can test.

Will try and build a kernel soon for you to test, so you don't have to
wait for an upload.


Thanks for keeping at this issue!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#970717: kubernetes: abuse of "embedded code copies" | hundreds of vendored libraries

[Dmitry Smirnov]

> It's not entirely clear to me if the policy concerns are around
> licensing compliance or simply the volume of vendored dependencies.

The concern is entirely about volume of vendored dependencies.

Most certainly no other package in Debian ever had that many private copies 
of 3rd party libraries.

While some discrepancies in license documentation are likely, they are beyond
the scope of this problem. This is not a bureaucratic concern for license 
coverage but a technical issue regarding how a package is maintained in a 
wrong way, IMHO.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- Friedrich Nietzsche


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

Bug#931301: Tests failing on on file offset change

[Bastian Germann]

The -D_FILE_OFFSET_BITS=64 option makes the tests fail on i686.
Maybe the tests impose wrong assumptions:

FAIL: mtdlib_test
===
   mtd-utils 2.1.2: ./test-suite.log
===

# TOTAL: 2
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  2
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: ubilib_test
=

[==] Running 16 test(s).
[ RUN  ] test_libubi_open
[  ERROR   ] --- 0x3 != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:22: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_libubi_open
[ RUN  ] test_ubi_vol_block_create
[   OK ] test_ubi_vol_block_create
[ RUN  ] test_ubi_vol_block_remove
[   OK ] test_ubi_vol_block_remove
[ RUN  ] test_ubi_update_start
[   OK ] test_ubi_update_start
[ RUN  ] test_ubi_dev_present
[  ERROR   ] --- 0x5 != 0x3
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:92: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_ubi_dev_present
[ RUN  ] test_ubi_rsvol
libubi: error!: cannot open "/foo"
error 2 (No such file or directory)
[  ERROR   ] --- 0x != 0
[   LINE   ] --- tests/unittests/libubi_test.c:121: error: Failure!
[  FAILED  ] test_ubi_rsvol
[ RUN  ] test_ubi_rmvol
[  ERROR   ] --- 0x6 != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:89: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_ubi_rmvol
[ RUN  ] test_ubi_rnvols
[  ERROR   ] --- 0x7 != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:89: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_ubi_rnvols
[ RUN  ] test_ubi_leb_change_start
[  ERROR   ] --- 0x8 != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:89: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_ubi_leb_change_start
[ RUN  ] test_ubi_get_info
[  ERROR   ] --- 0x9 != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:89: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_ubi_get_info
[ RUN  ] test_ubi_mkvol
[  ERROR   ] --- 0xa != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:89: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_ubi_mkvol
[ RUN  ] test_ubi_leb_unmap
[   OK ] test_ubi_leb_unmap
[ RUN  ] test_ubi_is_mapped
[   OK ] test_ubi_is_mapped
[ RUN  ] test_ubi_remove_dev
[  ERROR   ] --- 0xb != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:89: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_ubi_remove_dev
[ RUN  ] test_ubi_attach
[  ERROR   ] --- 0xc != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libubi_test.c:89: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_ubi_attach
[ RUN  ] test_ubi_set_property
[   OK ] test_ubi_set_property
[==] 16 test(s) run.
[  PASSED  ] 6 test(s).
[  FAILED  ] 10 test(s), listed below:
[  FAILED  ] test_libubi_open
[  FAILED  ] test_ubi_dev_present
[  FAILED  ] test_ubi_rsvol
[  FAILED  ] test_ubi_rmvol
[  FAILED  ] test_ubi_rnvols
[  FAILED  ] test_ubi_leb_change_start
[  FAILED  ] test_ubi_get_info
[  FAILED  ] test_ubi_mkvol
[  FAILED  ] test_ubi_remove_dev
[  FAILED  ] test_ubi_attach

 10 FAILED TEST(S)
FAIL ubilib_test (exit status: 10)

FAIL: mtdlib_test
=

[==] Running 17 test(s).
[ RUN  ] test_libmtd_open
[  ERROR   ] --- 0x3 != 0x4
tests/unittests/test_lib.h:37: error: Check of parameter fd, function
__wrap_close failed
tests/unittests/libmtd_test.c:33: note: Expected parameter declared here
[   LINE   ] --- tests/unittests/test_lib.h:37: error: Failure!
[  FAILED  ] test_libmtd_open
[ RUN  ] test_mtd_is_bad
[   OK ] test_mtd_is_bad
[ RUN  ] test_mtd_mark_bad
[   OK ] test_mtd_mark_bad
[ RUN  ] test_mtd_lock
[   OK ] test_mtd_lock
[ RUN  ] test_mtd_unlock
[   OK ] 

Bug#970764: python3-venv: /usr/bin/pyvenv is a dangling symlink, man page, too

[Norbert Preining]

Package: python3-venv
Version: 3.8.2-3
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: norb...@preining.info

Hi

something seems to have gone a bit wrong with the venv packaging, since
both the actual binary pyvenv in /usr/bin, as well as the man page are
both dangling symlinks, rendering the package unusable.

Thanks

Norbert

-- 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.8.10 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-venv depends on:
ii  python33.8.2-3
ii  python3-distutils  3.8.5-1
ii  python3.8-venv 3.8.6~rc1-2

python3-venv recommends no packages.

python3-venv suggests no packages.

-- no debconf information

Bug#970763: wminput immedinately exits with Segmentation Fault on use

[Ryan Armstrong]

Package: wminput
Version: 0.6.91-1+b1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

With the most recent version of wminput, the application fails to start
immediately, raising a Segmentation Fault. This occurrs on both of my
machines that currently track Debian Testing. It does not matter what
command-line arguments are used, even --version causes this behaviour.

I attempted to rebuild the package with debug symbols in order to get a
useful stack trace. While I was able to build and install the package +
dbgsym packages, the backtrace in gdb was not useful. Here it is for
reference anyways:

$ gdb wminput
GNU gdb (Debian 9.2-1) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from wminput...
Reading symbols from
/usr/lib/debug/.build-id/87/07b22dc522a1bffe98fc49614410ec12d85b05.debug...
(gdb) run
Starting program: /usr/bin/wminput 

Program received signal SIGSEGV, Segmentation fault.
0x0001 in ?? ()
(gdb) bt
#0  0x0001 in ?? ()
#1  0x7fffe4b2 in ?? ()
#2  0x in ?? ()

And here is LDD's output:

$ ldd /usr/bin/wminput
linux-vdso.so.1 (0x7ffc5dbc2000)
libcwiid.so.1 => /usr/lib/libcwiid.so.1 (0x7f3439bdb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f3439bd5000)
libbluetooth.so.3 => /usr/lib/x86_64-linux-gnu/libbluetooth.so.3 
(0x7f3439bb)
libpython3.8.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.8.so.1.0 
(0x7f3439667000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f3439645000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f343948)
/lib64/ld-linux-x86-64.so.2 (0x7f3439c4c000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 
(0x7f3439451000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f3439434000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f343942f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f34392eb000)

I'm hoping this should be trivial for anyone else to reproduce. 
If you'd like me to try anything else, please let me know.

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

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

Versions of packages wminput depends on:
ii  libbluetooth3  5.54-1
ii  libc6  2.31-3
ii  libcwiid1  0.6.91-1+b1
ii  libpython3.8   3.8.5-2
ii  python3-cwiid  0.6.91-1+b1

wminput recommends no packages.

wminput suggests no packages.

-- no debconf information

Bug#970750: lintian: cannot run origtar check on package source:nvidia-cuda-toolkit/10.2.89-5

[Felix Lechner]

Hi Andreas,

On Tue, Sep 22, 2020 at 3:00 PM Andreas Beckmann  wrote:
>
> (which is a multi-tarball source):

Thanks for filing this bug. It is a well-known but hopefully
short-lived issue with some packages that combine multiple upstream
source tarballs.

We now unpack the orig sources and do an MD5 based comparison between
the patched and the orig source trees. It re-enables large parts of
the cruft check that had been turned off whenever diffstat output is
not available---which was for any source format above 1.0. Now the
tags run again on 3.0 (quilt) sources, which make up the majority of
the archive.

Upstream tarballs come with various prefixes and internal name
conflicts that are probably responsible here.

Kind regards
Felix Lechner

Bug#970762: virt-manger fails to open vm console/info with: Error launching details: g-io-error-quark: Error opening file /usr/share/misc/pci.ids: No such file or directory

[Daniel Leidert]

Package: pciutils
Version: 1:3.7.0-2
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The recent update-pciutils command seems to remove /usr/share/misc/pci.ids. This
leads to the error described in the subject and also removes a file distributed 
by
the pci.ids Debian package which is a clear policy violation.

Please fix this asap. Also #950812 should be fixed with this upload. Forcing the
link creation solves this issue.

Regards, Daniel


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

Kernel: Linux 5.8.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE
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 pciutils depends on:
ii  libc6 2.31-3
ii  libkmod2  27+20200310-2
ii  libpci3   1:3.7.0-2

pciutils recommends no packages.

Versions of packages pciutils suggests:
ii  bzip2  1.0.8-4
ii  curl   7.72.0-1
ii  wget   1.20.3-1+b3

- -- no debconf information

- -- debsums errors found:
debsums: changed file /usr/sbin/update-pciids (from pciutils package)

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAl9qjZUACgkQS80FZ8KW
0F0g6RAA2hoYUaAhp34nZUDlBfHONgtHTzNt2sbGEfKO2q/CaBIbH6vem0W0osgX
au6dvtR0hGN2vAImC7T7gLb7rqGMHafQxhZMuTA5thsKBW4pm6Tb+IGg0XRU3QFt
4wp4XqAPrnfoFEzMEZIqkAeRVXLtboD7opHBgfbZdaYuuSumZo/P5ftBss9esCpz
JYXbv1dCw7nbaWnOioe93prypyi+coBd0AkP7piJCA9Tl6ybKDxES6UZE+QkdDQ5
0ssVD3HyV5DG80Y/vONQ6t6hSkNYtDTtUhuqUPE+Q+Mvlce43Igogln6Hbu54QaO
f8rYBpzyWfBOuRw6Ol6ODoFTqmmc0i8YUjJ/0jxbRlZGAqfk9SrxMpx18ZzC2uu3
yd2GCtmw/owhIrV4BUTTW06WpE+mwSwzbtDDdfRsH+oRLCk1NGNzmc4F8zTPj33j
akjWysiM8/YClkEP4fo9YNWQxLcFUr3T+6TLWvUG7EqSUQj4R4lKBND8VDTiS7L9
1UJ86SeiujfnAx8+eWM/mDiSynXgFLRoQ9Uv/5tXXieOweTUPxbl+Q9TV7u7m+Ja
VnMAxpHRrDsk3jO1sJlVcvzZ6OPD6LY0K6I7fBFQ8TpioGZxB+Uupws0vXBjtAaz
8KV3m/ZUTaGHlsANriQSmdmeAMTwDgfL2xlOn+0ywXP0fxCE6bA=
=42bX
-END PGP SIGNATURE-

Bug#970761: qosmic FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: qosmic
Version: 1.6.0-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qosmic fails to cross build from source, because the upstream qosmic.pro
file hard codes the build architecture pkg-config. qmake actually
detects the correct pkg-config, but the .pro file fails to use it.
Please consider applying the attached patch to make qosmic cross
buildable.

Helmut
--- qosmic-1.6.0.orig/qosmic.pro
+++ qosmic-1.6.0/qosmic.pro
@@ -37,7 +37,7 @@
 CONFIG += link_pkgconfig
 
 link_pkgconfig {
-	message("Config using pkg-config version "$$system(pkg-config --version))
+	message("Config using pkg-config version "$$system($$PKG_CONFIG --version))
 	PKGCONFIG = flam3 lua5.2
 }
 else {
@@ -77,7 +77,7 @@
 }
 
 link_pkgconfig {
-	! system(pkg-config --atleast-version 3.1.1 flam3) {
+	! system($$PKG_CONFIG --atleast-version 3.1.1 flam3) {
 		error("Qosmic $$VERSION requires at least version 3.1.1 of flam3 to build.")
 	}
 }

Bug#970760: pipewire: PipeWire failing to open devices and loading libspa-alsa

[Paul Menzel]

Package: pipewire
Version: 0.3.12-1
Severity: normal
Forwarded: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/293

Dear Debian folks,


If PipeWire is started first in the user session, it prevents PulseAudio 
from accessing the sound devices causing the sound devices not to found 
and working [1].


As a workaround, remove the package *pipewire*, or disable the user 
service and socket units.



Kind regards,

Paul


[1]: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/293

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 pipewire depends on:
ii  init-system-helpers  1.58
ii  libpipewire-0.3-modules  0.3.12-1
ii  pipewire-bin 0.3.12-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#970759: normaliz: Wrong e-mail address in Maintainer field

[Alex Muntada]

Package: normaliz
Version: 3.8.5+ds-1
Severity: serious
Usertags: alioth-lists.debian.org
X-Debbugs-Cc: calcu...@rezozer.net

The Maintainer of this package uses the alioth-lists.debian.org
domain, which does not exist. This breaks policy §3.3[1] that
requires a working e-mail address. You should be using the
alioth-lists.debian.net domain instead.

After reporting[2] the issue to debian-science-maintainers list,
I'm filing this bug as suggested[3] there.

Cheers,
Alex

  [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
  [2] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085266.html
  [3] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085350.html

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#970758: mpfi: Wrong e-mail address in Maintainer field

[Alex Muntada]

Package: mpfi
Version: 1.5.3+ds-4
Severity: serious
Usertags: alioth-lists.debian.org
X-Debbugs-Cc: calcu...@rezozer.net, lfou...@debian.org

The Maintainer of this package uses the alioth-lists.debian.org
domain, which does not exist. This breaks policy §3.3[1] that
requires a working e-mail address. You should be using the
alioth-lists.debian.net domain instead.

After reporting[2] the issue to debian-science-maintainers list,
I'm filing this bug as suggested[3] there.

Cheers,
Alex

  [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
  [2] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085266.html
  [3] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085350.html

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#970757: gap-scscp: Wrong e-mail address in Maintainer field

[Alex Muntada]

Package: gap-scscp
Version: 2.3.1+ds-1
Severity: serious
Usertags: alioth-lists.debian.org
X-Debbugs-Cc: calcu...@rezozer.net

The Maintainer of this package uses the alioth-lists.debian.org
domain, which does not exist. This breaks policy §3.3[1] that
requires a working e-mail address. You should be using the
alioth-lists.debian.net domain instead.

After reporting[2] the issue to debian-science-maintainers list,
I'm filing this bug as suggested[3] there.

Cheers,
Alex

  [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
  [2] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085266.html
  [3] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085350.html

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#970755: gap-guava: Wrong e-mail address in Maintainer field

[Alex Muntada]

Package: gap-guava
Version: 3.15+ds-2
Severity: serious
Usertags: alioth-lists.debian.org
X-Debbugs-Cc: calcu...@rezozer.net

The Maintainer of this package uses the alioth-lists.debian.org
domain, which does not exist. This breaks policy §3.3[1] that
requires a working e-mail address. You should be using the
alioth-lists.debian.net domain instead.

After reporting[2] the issue to debian-science-maintainers list,
I'm filing this bug as suggested[3] there.

Cheers,
Alex

  [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
  [2] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085266.html
  [3] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085350.html

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#970756: gap-openmath: Wrong e-mail address in Maintainer field

[Alex Muntada]

Package: gap-openmath
Version: 11.5.0+ds-1
Severity: serious
Usertags: alioth-lists.debian.org
X-Debbugs-Cc: calcu...@rezozer.net

The Maintainer of this package uses the alioth-lists.debian.org
domain, which does not exist. This breaks policy §3.3[1] that
requires a working e-mail address. You should be using the
alioth-lists.debian.net domain instead.

After reporting[2] the issue to debian-science-maintainers list,
I'm filing this bug as suggested[3] there.

Cheers,
Alex

  [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
  [2] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085266.html
  [3] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085350.html

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#970754: e-antic: Wrong e-mail address in Maintainer field

[Alex Muntada]

Package: e-antic
Version: 0.1.5+ds-2.1
Severity: serious
Usertags: alioth-lists.debian.org
X-Debbugs-Cc: plugw...@raspbian.org, calcu...@rezozer.net

The Maintainer of this package uses the alioth-lists.debian.org
domain, which does not exist. This breaks policy §3.3[1] that
requires a working e-mail address. You should be using the
alioth-lists.debian.net domain instead.

After reporting[2] the issue to debian-science-maintainers list,
I'm filing this bug as suggested[3] there.

Cheers,
Alex

  [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
  [2] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085266.html
  [3] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085350.html

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#970753: apertium-ind-zlm: Wrong e-mail address in Maintainer field

[Alex Muntada]

Package: apertium-ind-zlm
Version: 0.1.2-2
Severity: serious
Usertags: alioth-lists.debian.org
X-Debbugs-Cc: kar...@debian.org, t...@didriksen.cc

The Maintainer of this package uses the alioth-lists.debian.org
domain, which does not exist. This breaks policy §3.3[1] that
requires a working e-mail address. You should be using the
alioth-lists.debian.net domain instead.

After reporting[2] the issue to debian-science-maintainers list,
I'm filing this bug as suggested[3] there.

Cheers,
Alex

  [1] https://www.debian.org/doc/debian-policy/ch-binary.html#s-maintainer
  [2] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085266.html
  [3] 
https://alioth-lists.debian.net/pipermail/debian-science-maintainers/2020-September/085350.html

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer  log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#970752: Subject: open-vm-tools: ConditionVirtualization=vmware was not met

[sixerjman]

Package: open-vm-tools Version: open-vm-tools service (vmtoolsd) fails to
start Severity: normal Dear Maintainer,

* What led up to the situation? Tried to start vmtoolsd

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

* What was the outcome of this action? Condition not met, start failed

* What outcome did you expect instead? vmtoolsd starts

The following condition caused the failure:

ConditionVirtualization=vmware was not met

After commenting it out vmtoolsd started successfully. For what it's worth,
the same condition fails in VMware vmplayer.

-- System Information: Debian Release: bullseye/sid APT prefers testing APT
policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-1-amd64 (SMP w/2 CPU threads) Kernel taint flags:
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8,
LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8),
LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via
/run/systemd/system) LSM: AppArmor: enabled

Bug#970751: RFS: ticker/1.12 [QA] -- configurable text scroller

[Leandro Cunha]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: ticker
   Version : 1.12
   Upstream Author : Joey Hess 
 * URL : http://kitenet.net/~joey/code/ticker/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/ticker
   Section : utils

It builds those binary packages:

  ticker - configurable text scroller

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/t/ticker/ticker_1.12.dsc

Changes since the last upload:

 ticker (1.12) unstable; urgency=medium
 .
   * QA upload.
   * debian/rules:
 - Avoid running configure during make clean. (Closes: #928196)
   * debian/copyright:
 - Add Upstream-Name and Upstream-Contact.
 - Update link format with HTTPS reported by Lintian.
 - Add myself.
   * debian/control:
 - Debhelper-compat level to 13.
 - Bumped Standards-Version to 4.5.0.
 - Add Vcs-Browser and Vcs-Git in Salsa.
 - Remove build-dep dh-autoreconf reported by Lintian.
   * Fixed spelling error in a manual page reported by Lintian.
   * Rename archives README with .md and GPL for LICENSE.md.
   * debian/tests:
 - Add control file for autopkgtest.
   * Add debian/salsa-ci.yml file.
   * Fix exit non-zero in help command reported by autopkgtest.

Regards,
--
  Leandro Cunha

Bug#970750: lintian: cannot run origtar check on package source:nvidia-cuda-toolkit/10.2.89-5

[Andreas Beckmann]

Package: lintian
Version: 2.95.0
Severity: important

Hi,

current lintian spews a lot of internal errors while checking 
src:nvidia-cuda-toolkit
(which is a multi-tarball source):

$ lintian nvidia-cuda-toolkit_10.2.89-5_amd64.changes
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/tools'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/tools':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/targets'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/targets':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/share'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/share':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/nvvmx'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvvmx':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/nvvm'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvvm':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/nvml'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvml':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/nsightee_plugins'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nsightee_plugins':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/nsight-compute-2019.5.0'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nsight-compute-2019.5.0':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/libnvvp'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/libnvvp':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/libnsight'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/libnsight':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/extras'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/extras':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/doc'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/doc':
 Directory not empty
mv: cannot move 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el/bin'
 to 
'/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/bin':
 Directory not empty
Warning in group nvidia-cuda-toolkit/10.2.89-5: Can't 
rmdir('/tmp/lintian-pool-szq2AoYmsr/nvidia-cuda-toolkit/nvidia-cuda-toolkit_10.2.89-5_source/orig/nvidia-cuda-toolkit-10.2.89.orig-ppc64el'):
 Directory not empty at /usr/share/lintian/bin/../lib/Lintian/Index.pm line 572
 at /usr/share/lintian/bin/../lib/Lintian/Index.pm line 572.

Lintian::Index::drop_basedir_segment(Lintian::Index=HASH(0x557431c0e998)) 
called at /usr/share/lintian/bin/../lib/Lintian/Processable/Orig.pm line 154

Lintian::Processable::Orig::rmdir(Lintian::Processable::Source=HASH(0x557413e86d00))
 called at (eval 71) line 22

Lintian::Processable::Orig::orig(Lintian::Processable::Source=HASH(0x557413e86d00))
 called at /usr/share/lintian/checks/cruft.pm line 610
Lintian::cruft::source(Lintian::cruft=HASH(0x55742bcca6f0)) called at 
/usr/share/lintian/bin/../lib/Lintian/Check.pm line 133
Lintian::Check::run(Lintian::cruft=HASH(0x55742bcca6f0)) called at 

Bug#970749: nautilus-dropbox: New upstream release available

[Raphaël Hertzog]

Package: nautilus-dropbox
Version: 2019.02.14-1
Severity: wishlist

Version 2020.03.04 is available in the upstream git repository:
https://github.com/dropbox/nautilus-dropbox/tags

It would be nice to have this version packaged.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
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 nautilus-dropbox depends on:
ii  gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-5
ii  gir1.2-gtk-3.0   3.24.22-1
ii  libc62.31-3
ii  libglib2.0-0 2.64.4-1
ii  libgtk-3-0   3.24.22-1
ii  libnautilus-extension1a  3.36.3-1
ii  procps   2:3.3.16-5
ii  python3  3.8.2-3
ii  python3-gi   3.36.1-1

Versions of packages nautilus-dropbox recommends:
ii  python3-gpg  1.14.0-1

Versions of packages nautilus-dropbox suggests:
ii  nautilus  3.36.3-1

-- no debconf information

Bug#970748: pulseeffects: Numerous desktop files without a common categories

[Calum McConnell]

Package: pulseeffects
Version: 4.8.0-1
Severity: minor
X-Debbugs-Cc: calumlikesapple...@gmail.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package creates a huge number of .desktop files, but
doesn't put them in a common cateogory.  That means that
it's hard to put them in a GNOME app-folder without manually
naming every one of them.  If you added a Categories: line, that
would not be the case: it would be possible to quickly add
every one into a lsb-plugins folder.  That way, it is easy to
manage the huge number of applications created, while
still letting them be used.

Ideally, the line would contain the basic cateogories.
as well as an X-lsb-plugin line.  That makes it easy
for users to modify GSettings to hide all the entries
into folders.  This could be done with a bash script.

I can write said script if you would like.  
Thanks!
Calum M.

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

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

Versions of packages pulseeffects depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.38.0-1
ii  gir1.2-gst-plugins-bad-1.0   1.18.0-2
ii  gstreamer1.0-adapter-pulseeffects4.8.0-1
ii  gstreamer1.0-plugins-bad 1.18.0-2
ii  gstreamer1.0-plugins-good1.18.0-1
ii  gstreamer1.0-pulseaudio  1.18.0-1
ii  libatkmm-1.6-1v5 2.28.0-2
ii  libboost-filesystem1.71.01.71.0-6+b2
ii  libc62.31-3
ii  libcairomm-1.0-1v5   1.12.2-4
ii  libgcc-s110.2.0-9
ii  libglib2.0-0 2.66.0-2
ii  libglibmm-2.4-1v52.64.2-2
ii  libgstreamer-plugins-base1.0-0   1.18.0-2
ii  libgstreamer1.0-01.18.0-3
ii  libgtk-3-0   3.24.23-1
ii  libgtkmm-3.0-1v5 3.24.2-1
ii  libpangomm-1.4-1v5   2.42.1-1
ii  libpulse013.0-5
ii  libsigc++-2.0-0v52.10.2-1
ii  libsndfile1  1.0.28-8
ii  libstdc++6   10.2.0-9
ii  pulseaudio   13.0-5

Versions of packages pulseeffects recommends:
ii  calf-plugins   0.90.3-1+b1
ii  gstreamer1.0-autogain-pulseeffects 4.8.0-1
ii  gstreamer1.0-convolver-pulseeffects4.8.0-1
ii  gstreamer1.0-crystalizer-pulseeffects  4.8.0-1
ii  liblilv-0-00.24.8~dfsg0-1
ii  lsp-plugins-lv21.1.26-1
ii  rubberband-ladspa  1.9.0-1
ii  zam-plugins3.9~repack3-1+b1

pulseeffects suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEE/vC/PEGxsMPJ5u5w7/Xh1+DNmzIFAl9qPuQdHGNhbHVtbGlr
ZXNhcHBsZXBpZUBnbWFpbC5jb20ACgkQ7/Xh1+DNmzLp5A//SL2GZ50v4BPLmxM+
OltNdbcam51kbgRiVU14P9zOkNww1+m2vnWT8B0NloKnqjXPl0TjUx4qm+miZe6M
BEzu1sy9L6JYewR8nASZpxVSezoOVawtNx8YwJSdAPdXhEoDuJojOrh3tJvW9XBJ
LXencJlZyylg+yGV1faj5NHYQ1/kQhDYXwxg7s+Y0hubRAU/7olfTpITdn3tu2Dr
CgR1CL43B2c/ArXlxwxQ0SL2vuIV7VQrJEhwROM6wpCPCmA9/w6+pTEtyP0pYS0W
xFMfbmkmvIq46cxjTpBjXasTIY6Wh+Ko5i4fnV5Oz4e3WO8YwmfZ4N12MJtlqrTY
wqY7Mif5ijcnopYB+LvgE3+xuEqlFytJGcbxtJmuYpEXuf1nLK6fyZk8+aovTkDI
bQf8uKA0hoarkKXnuHTIar99viSjQDOaqznBjjzwnMtFSV66OfjrjNchZSGpERbT
x5MiHcqaQwZ5gG8FpRBUk6df+n8gZVllMxahvOgNcEEKOryamvdc31L0SGZL1KfK
9lrO0HmmBarqJPe3DNi79qDJ+Du1atYdHZliSz5TUhu0h0UKgk3p/WiykhUbArWL
jOPuotb5aoes/yHH/fynECy3ah73MpwldwoeQkiMPDCbsC0eEeU1MX4sjIdbec0I
2r8RY313J9YmRkCb1uJRbB+uof8=
=Fo9+
-END PGP SIGNATURE-

Bug#959420: O: free42-nologo -- Free42 is a re-implementation of the HP-42S calculator

[Sébastien Villemot]

Hi Stephen

Le mardi 22 septembre 2020 à 23:19 +0200, Stephen Kitt a écrit :
> On Thu, 16 Jul 2020 14:57:13 +0200, Sébastien Villemot 
> wrote:
> > Le jeudi 09 juillet 2020 à 20:07 +0200, Sébastien Villemot a écrit :
> > > On Mon, 29 Jun 2020 22:34:20 +0200 Stephen Kitt 
> > > wrote:  
> > > > 
> > - providing aliases for the manpage so that it works with free42dec as
> > well (and possibly with the free42 generic alternative)
> 
> That’s easily done with alternatives.
> 
> I have another question regarding your packaging: why not use the packaged
> Intel RDFP math library?

At least because the Debian package for the Intel decimal floating-
point library entered the archive on 2020-07-22, so after I had
submitted my code!

Of course we should use the packaged library if possible, and I had
myself though about packaging that library independently. However, I
had given up the idea because Free42 patches the library: see
gtk/intel-lib-linux.patch. I did not really look into this patch to see
how important it is and whether it makes it impossible to use the
pristine library, but I guess this is a significant blocker for the
split in two packages.

I’m going to wait for Christian’s feedback on this issue in particular,
and on my work in general, before moving further. As long as we are in
time for inclusion in bullseye, no rush on my side.

Thanks for your feedback,

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#970747: liblinphone-dev: should depend on liblinphone++10

[Andres Salomon]

Package: liblinphone-dev
Version: 4.4.0-1
Severity: serious

While building linphone-desktop, I hit the following build error:


CMake Error at /usr/share/LinphoneCxx/cmake/LinphoneCxxTargets.cmake:70 
(message):

 The imported target "linphone++" references the file

"/usr/lib/x86_64-linux-gnu/liblinphone++.so.10"

 but this file does not exist.  Possible reasons include:

 * The file was deleted, renamed, or moved to another location.

 * An install or uninstall procedure did not complete successfully.

 * The installation package was faulty and contained

"/usr/share/LinphoneCxx/cmake/LinphoneCxxTargets.cmake"

 but not all the files it references.

Call Stack (most recent call first):
 /usr/share/LinphoneCxx/cmake/LinphoneCxxConfig.cmake:33 (include)
 CMakeLists.txt:165 (find_package)



dilinger@e7470:/home/dev/linphone-desktop-4.2.2$ dpkg -S 
/usr/lib/x86_64-linux-gnu/liblinphone*so

liblinphone-dev: /usr/lib/x86_64-linux-gnu/liblinphone++.so
liblinphone-dev: /usr/lib/x86_64-linux-gnu/liblinphone.so

dilinger@e7470:/home/dev/linphone-desktop-4.2.2$ ls -lh 
/usr/lib/x86_64-linux-gnu/liblinphone*so
lrwxrwxrwx 1 root root 19 Aug 31 19:03 
/usr/lib/x86_64-linux-gnu/liblinphone++.so -> liblinphone++.so.10
lrwxrwxrwx 1 root root 17 Aug 31 19:03 
/usr/lib/x86_64-linux-gnu/liblinphone.so -> liblinphone.so.10


dilinger@e7470:/home/dev/linphone-desktop-4.2.2$ ls -lh 
/usr/lib/x86_64-linux-gnu/liblinphone*so.10
-rw-r--r-- 1 root root 3.6M Aug 31 19:03 
/usr/lib/x86_64-linux-gnu/liblinphone.so.10



As you can see, liblinphone++.so.10 is missing. It seems like
liblinphone-dev should depend on both liblinphone10 AND
liblinphone++10, but right now it only depends on
liblinphone10.

Bug#959420: O: free42-nologo -- Free42 is a re-implementation of the HP-42S calculator

[Stephen Kitt]

Hi Sébastien,

Thanks for your patience!

On Thu, 16 Jul 2020 14:57:13 +0200, Sébastien Villemot 
wrote:
> Le jeudi 09 juillet 2020 à 20:07 +0200, Sébastien Villemot a écrit :
> > On Mon, 29 Jun 2020 22:34:20 +0200 Stephen Kitt 
> > wrote:  
> > > Control: retitle -1 ITA: free42-nologo -- Free42 is a re-implementation
> > > of the HP-42S calculator Control: owner -1 !
> > > 
> > > On Sat, May 02, 2020 at 10:58:56AM +0200, Tobias Frost wrote:  
> > > > The current maintainer of free42-nologo, Christian Stalp <
> > > > ch...@chrishell.de  
> > > > >,  
> > > > is apparently not active anymore.  Therefore, I orphan this package
> > > > now.  
> > > 
> > > I’m working with Christian to get an updated version of the package
> > > ready. I’ll change this to an ITA on my behalf for now, to signal that
> > > I am taking care of the package (whether with Christian, or directly,
> > > or co-maintaining).  
> > 
> > Just to let you know that, if needed, I’m willing to help with the
> > package.  
> 
> I went ahead and I created a repository that contains an almost-ready
> package for 2.5.19, using a standard git-buildpackage workflow. See:
> https://salsa.debian.org/sebastien/free42-nologo
> 
> Please let me know if you accept to have the next upload based on this
> work.

Thanks for preparing this, I’ve asked Christian to take a look.

> - what to put in the Maintainer/Uploaders field. My suggestion is to
> create a team alias on tracker.debian.org that can function as a cheap
> mailing list (of the form team+pkg-fre...@tracker.debian.org, where
> "pkg-free42" can be replaced by whatever we want), and use that address
> in the Maintainer field. Personal adresses would go to the Uploaders
> field.

If Christian agrees, I think that would make sense.

> - where to put the git repository. I suggest the "debian" group on
> salsa.debian.org, or alternatively a dedicated group on salsa

The Debian group would be fine by me.

> Then a few packaging decisions remain to be taken:
> 
> - what to do with the old "menu" entry (and the corresponding generated
> 32x32 pixmap). I suggest to drop it, since it is essentially obsolete.

Yes, if the package ships a desktop file (see below), it shouldn’t ship menu
entries.

> - now that we have two versions of the program (binary vs decimal), I
> think it would make sense to use the alternatives mechanism to provide
> a generic /usr/bin/free42 that will point either to free42dec or
> free42bin (the former being the default, since it is more precise and
> more faithful to the original HP 42S)

Agreed.

> - providing a .desktop file (pointing to the generic free42; or
> alternatively, two desktop files, one for each version)

Agreed (one for each version).

> - providing aliases for the manpage so that it works with free42dec as
> well (and possibly with the free42 generic alternative)

That’s easily done with alternatives.

I have another question regarding your packaging: why not use the packaged
Intel RDFP math library?

Regards,

Stephen


pgpDaBgAKonOM.pgp
Description: OpenPGP digital signature

Bug#967546: udev: missing /dev/stdin etc.

[Michael Biebl]

Ben,

in case you want to follow up on
https://github.com/systemd/systemd/commit/6b2229c6c60d0486f5eb9ed3088f9c780d7c0233#commitcomment-42637841
with arguments I might have missed.

Michael



signature.asc
Description: OpenPGP digital signature

Bug#970742: plasma-workspace: No "Switch-User" with systemd V246

[Achim Schaefer]

Hi,

I just downgraded to systemd 245.7 and the option is back.

regards
On 22.09.20 22:01, Achim Schaefer wrote:

Package: plasma-workspace
Version: 4:5.17.5-4
Severity: important
Tags: upstream

Dear Maintainer,

in archlinux they tested with Version 245 and it works again:
https://bugs.archlinux.org/task/67623

A bug in kde is already open:
https://bugs.kde.org/show_bug.cgi?id=423526

Thanks


--witch USer functionality doe snot work any more with systemd Version 246.
System Information:
Debian Release: bullseye/sid
   APT prefers stable-updates
   APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  drkonqi   5.17.5-2
ii  frameworkintegration  5.70.0-1
ii  gdb   9.2-1
ii  iso-codes 4.5.0-1
ii  kactivitymanagerd 5.17.5-2
ii  kded5 5.70.0-1
ii  kinit 5.70.0-1
ii  kio   5.70.1-1
ii  kpackagetool5 5.70.0-1
ii  kwin-common   4:5.17.5-3
ii  libappstreamqt2   0.12.11-1
ii  libc6 2.31-3
ii  libcolorcorrect5  4:5.17.5-4
ii  libgcc-s1 10.2.0-9
ii  libgps26  3.20-12
ii  libice6   2:1.0.9-2
ii  libkf5activities5 5.70.0-1
ii  libkf5activitiesstats15.70.0-1
ii  libkf5authcore5   5.70.0-1
ii  libkf5baloo5  5.70.0-2
ii  libkf5bookmarks5  5.70.0-1
ii  libkf5calendarevents5 5.70.0-1
ii  libkf5completion5 5.70.0-1
ii  libkf5config-bin  5.70.0-1
ii  libkf5configcore5 5.70.0-1
ii  libkf5configgui5  5.70.0-1
ii  libkf5configwidgets5  5.70.0-2
ii  libkf5coreaddons5 5.70.0-2
ii  libkf5crash5  5.70.0-1
ii  libkf5dbusaddons5 5.70.0-1
ii  libkf5declarative55.70.0-1
ii  libkf5globalaccel-bin 5.70.0-1
ii  libkf5globalaccel55.70.0-1
ii  libkf5guiaddons5  5.70.0-2
ii  libkf5holidays5   1:5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5idletime5   5.70.0-1
ii  libkf5itemmodels5 5.70.0-3
ii  libkf5jobwidgets5 5.70.0-1
ii  libkf5kdelibs4support55.70.0-2
ii  libkf5kiocore55.70.1-1
ii  libkf5kiofilewidgets5 5.70.1-1
ii  libkf5kiogui5 5.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5networkmanagerqt6   5.70.0-1
ii  libkf5newstuff5   5.70.0-1
ii  libkf5notifications5  5.70.0-1
ii  libkf5notifyconfig5   5.70.0-1
ii  libkf5package55.70.0-1
ii  libkf5people5 5.70.0-1
ii  libkf5peoplewidgets5  5.70.0-1
ii  libkf5plasma5 5.70.1-1
ii  libkf5plasmaquick55.70.1-1
ii  libkf5prison5 5.70.0-1
ii  libkf5quickaddons55.70.0-1
ii  libkf5runner5 5.70.0-1
ii  libkf5service-bin 5.70.0-1
ii  libkf5service55.70.0-1
ii  libkf5solid5  5.70.0-1
ii  libkf5texteditor5 5.70.1-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5wallet-bin  5.70.0-1
ii  libkf5wallet5 5.70.0-1
ii  

Bug#970746: lintian: Bogus "W: no-manual-page" reports

[Hilmar Preusse]

Package: lintian
Version: 2.95.0
Severity: normal

Dear Maintainer,

Hopefully this is not an FAQ.

I run lintian for texlive-binaries_2020.20200327.54578-4+b1_amd64.deb.
It reports a few warnings b/c of missing manual pages:

W: no-manual-page usr/bin/pmpost
W: no-manual-page usr/bin/r-mpost
W: no-manual-page usr/bin/r-pmpost
W: no-manual-page usr/bin/r-upmpost 

With that package installed however it is possible to run
"man pmpost". I can only guess why the page is not found: b/c there
is no pmpost.1 file installed anywhere, the man page for pmpost is
included in the man page of mpost:

hille@sid:~ $ apropos pmpost
mpost (1)- MetaPost, a system for creating graphics r-mpost, r-pm...

Regards,
  Hilmar

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

Kernel: Linux 5.8.0-2-686-pae (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_GB.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lintian depends on:
ii  binutils2.35.1-1
ii  bzip2   1.0.8-4
ii  diffstat1.63-1
ii  dpkg1.20.5
ii  dpkg-dev1.20.5
ii  file1:5.38-5
ii  gettext 0.19.8.1-10
ii  gpg 2.2.20-1
ii  intltool-debian 0.35.0+20060710.5
ii  libapt-pkg-perl 0.1.36+b2
ii  libarchive-zip-perl 1.68-1
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b5
ii  libclone-perl   0.45-1
ii  libconfig-tiny-perl 2.24-1
ii  libcpanel-json-xs-perl  4.23-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1
ii  libdevel-size-perl  0.83-1+b1
ii  libdigest-sha-perl  6.02-1+b2
ii  libdpkg-perl1.20.5
ii  libemail-address-xs-perl1.04-1+b2
ii  libfile-basedir-perl0.08-1
ii  libfile-find-rule-perl  0.34-1
ii  libfont-ttf-perl1.06-1
ii  libhtml-html5-entities-perl 0.004-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004002-1
ii  liblist-compare-perl0.55-1
ii  liblist-moreutils-perl  0.416-1+b5
ii  liblist-utilsby-perl0.11-1
ii  libmoo-perl 2.004000-1
ii  libmoox-aliases-perl0.001006-1
ii  libnamespace-clean-perl 0.27-1
ii  libpath-tiny-perl   0.114-1
ii  libperlio-gzip-perl 0.19-1+b6
ii  libproc-processtable-perl   0.59-2
ii  libsereal-decoder-perl  4.018+ds-1
ii  libsereal-encoder-perl  4.018+ds-1
ii  libtext-glob-perl   0.11-1
ii  libtext-levenshteinxs-perl  0.03-4+b7
ii  libtext-markdown-discount-perl  0.12-1
ii  libtext-xslate-perl 3.5.8-1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b2
ii  libtimedate-perl2.3300-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.010006-1
ii  libunicode-utf8-perl0.62-1+b1
ii  liburi-perl 1.76-2
ii  libxml-libxml-perl  2.0134+dfsg-2
ii  libyaml-libyaml-perl0.82+repack-1
ii  lzip1.21-8
ii  lzop1.04-1
ii  man-db  2.9.3-2
ii  patchutils  0.4.2-1
ii  perl [libdigest-sha-perl]   5.30.3-4
ii  t1utils 1.41-4
ii  unzip   6.0-25
ii  xz-utils5.2.4-1+b1

lintian recommends no packages.

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

-- no debconf information

-- 
sigmentation fault


signature.asc
Description: PGP signature

Bug#970745: buster-pu: package pdns_4.1.6-3+deb10u1

[Chris Hofstaedtler]

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

Fixes for low-severity issues CVE-2019-10203 and CVE-2020-17482.
Both using upstream patches for the 4.1 branch.

Maybe it should be pointed out in the stable update notes that
manual action is needed to remedy CVE-2019-10203 for existing
installations using postgres. "Manual schema update required for
PostgreSQL"?

Chris


diff -Nru pdns-4.1.6/debian/changelog pdns-4.1.6/debian/changelog
--- pdns-4.1.6/debian/changelog 2019-06-21 19:07:07.0 +
+++ pdns-4.1.6/debian/changelog 2020-09-22 19:07:45.0 +
@@ -1,3 +1,13 @@
+pdns (4.1.6-3+deb10u1) buster; urgency=medium
+
+  * Apply upstream patches to fix CVE-2019-10203.
+To actually fix this problem in existing installations, the newly
+supplied schema file 4.1.10_to_4.1.11.schema.pgsql.sql has to be
+manually applied to the backing PostgreSQL database. (Closes: #970729)
+  * Apply upstream patches to fix CVE-2020-17482 (Closes: #970737)
+
+ -- Chris Hofstaedtler   Tue, 22 Sep 2020 19:07:45 +
+
 pdns (4.1.6-3) unstable; urgency=medium
 
   * Fix Denial of service via crafted zone records (CVE-2019-10162)
diff -Nru pdns-4.1.6/debian/patches/CVE-2019-10203.patch 
pdns-4.1.6/debian/patches/CVE-2019-10203.patch
--- pdns-4.1.6/debian/patches/CVE-2019-10203.patch  1970-01-01 
00:00:00.0 +
+++ pdns-4.1.6/debian/patches/CVE-2019-10203.patch  2020-09-22 
19:07:45.0 +
@@ -0,0 +1,54 @@
+From 6b48327a0da913d8eeb1c1a4938d3f22d80f9fb3 Mon Sep 17 00:00:00 2001
+From: Peter van Dijk 
+Date: Tue, 30 Jul 2019 15:40:09 +0200
+Subject: [PATCH] adjust gpgsql schema for advisory 2019-06
+
+---
+ modules/gpgsqlbackend/4.1.10_to_4.1.11.schema.pgsql.sql | 1 +
+ modules/gpgsqlbackend/schema.pgsql.sql  | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+ create mode 100644 modules/gpgsqlbackend/4.1.10_to_4.1.11.schema.pgsql.sql
+
+diff --git a/modules/gpgsqlbackend/4.1.10_to_4.1.11.schema.pgsql.sql 
b/modules/gpgsqlbackend/4.1.10_to_4.1.11.schema.pgsql.sql
+new file mode 100644
+index 00..b0c2ee1efa
+--- /dev/null
 b/modules/gpgsqlbackend/4.1.10_to_4.1.11.schema.pgsql.sql
+@@ -0,0 +1 @@
++ALTER TABLE domains ALTER notified_serial TYPE bigint USING CASE WHEN 
notified_serial >= 0 THEN notified_serial::bigint END;
+diff --git a/modules/gpgsqlbackend/schema.pgsql.sql 
b/modules/gpgsqlbackend/schema.pgsql.sql
+index b105d87951..cad35d5f19 100644
+--- a/modules/gpgsqlbackend/schema.pgsql.sql
 b/modules/gpgsqlbackend/schema.pgsql.sql
+@@ -4,7 +4,7 @@ CREATE TABLE domains (
+   masterVARCHAR(128) DEFAULT NULL,
+   last_checkINT DEFAULT NULL,
+   type  VARCHAR(6) NOT NULL,
+-  notified_serial   INT DEFAULT NULL,
++  notified_serial   BIGINT DEFAULT NULL,
+   account   VARCHAR(40) DEFAULT NULL,
+   CONSTRAINT c_lowercase_name CHECK (((name)::TEXT = LOWER((name)::TEXT)))
+ );
+
+
+From 15b1f3607691e6b0443696d6edca40cc3a04bbb0 Mon Sep 17 00:00:00 2001
+From: tcely 
+Date: Sun, 4 Aug 2019 05:12:30 -0400
+Subject: [PATCH] gpgsqlbackend: add missing schema file to Makefile
+
+---
+ modules/gpgsqlbackend/Makefile.am | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/modules/gpgsqlbackend/Makefile.am 
b/modules/gpgsqlbackend/Makefile.am
+index 8a820d516b..9e2f271702 100644
+--- a/modules/gpgsqlbackend/Makefile.am
 b/modules/gpgsqlbackend/Makefile.am
+@@ -12,6 +12,7 @@ dist_doc_DATA = \
+   schema.pgsql.sql \
+   nodnssec-3.x_to_3.4.0_schema.pgsql.sql \
+   dnssec-3.x_to_3.4.0_schema.pgsql.sql \
++  4.1.10_to_4.1.11.schema.pgsql.sql \
+   3.4.0_to_4.1.0_schema.pgsql.sql
+ 
+ libgpgsqlbackend_la_SOURCES = \
diff -Nru pdns-4.1.6/debian/patches/CVE-2020-17482.patch 
pdns-4.1.6/debian/patches/CVE-2020-17482.patch
--- pdns-4.1.6/debian/patches/CVE-2020-17482.patch  1970-01-01 
00:00:00.0 +
+++ pdns-4.1.6/debian/patches/CVE-2020-17482.patch  2020-09-22 
19:07:45.0 +
@@ -0,0 +1,153 @@
+From 3b88cb8c8cdd166b566ef7bd87f47732b2783f6a Mon Sep 17 00:00:00 2001
+From: Remi Gacogne 
+Date: Tue, 11 Aug 2020 11:25:06 +0200
+Subject: [PATCH 1/2] Raise an exception on invalid hex content in unknown
+ records
+
+Otherwise we can end up reading uninitialised memory from the stack,
+possibly leaking information.
+This is only an issue if the content is read from an untrusted source
+and can be passed back to an attacker.
+---
+ pdns/dnsparser.cc  | 24 
+ pdns/test-dnsrecords_cc.cc | 32 
+ 2 files changed, 48 insertions(+), 8 deletions(-)
+
+diff --git a/pdns/dnsparser.cc b/pdns/dnsparser.cc
+index b6108d8c6b..3a4e193f01 100644
+--- a/pdns/dnsparser.cc
 b/pdns/dnsparser.cc
+@@ -40,17 +40,25 @@ class UnknownRecordContent : public DNSRecordContent
+ // parse the input
+ vector parts;
+ stringtok(parts, 

Bug#970744: ben: please provide machine-parseable version of transition status

[Sebastian Ramacher]

Package: ben
Version: 0.9.0
Severity: wishlist

Hi,

thanks for maintaining ben. In additiona to the HTML output, it would be
great to have the same information as machine-parseable file. With such
a file one could feed other tools to further process the info produced
by ben, e.g., to produce a list of binNMUs.

Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (650, 'unstable-debug'), (650, 'unstable'), (601, 'testing'), 
(600, 'experimental-debug'), (600, 'buildd-unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ben depends on:
ii  bzip2   1.0.8-4
ii  curl7.72.0-1
ii  libben-ocaml [libben-ocaml-dvwl1]   0.9.0+b8
ii  libc6   2.31-3
ii  libjs-jquery3.5.1+dfsg-4
ii  libpcre32:8.39-13
ii  libpq5  12.4-1
ii  libtyxml-ocaml [libtyxml-ocaml-vbzd5]   4.4.0-1
ii  ocaml-base-nox [ocaml-base-nox-4.08.1]  4.08.1-10

Versions of packages ben recommends:
ii  dose-distcheck  5.0.1-15+b1

Versions of packages ben suggests:
ii  python3-yaml  5.3.1-2

-- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#970743: lintian: outdated wrong-vcs-location-for-dpmt, wrong-vcs-location-for-papt

[Bastian Germann]

Package: lintian
Version: 2.95.0
Severity: important

The teams DPMT and DPAT are not merged into the Debian Python Team
(DPT). All the git repositories were moved to
https://salsa.debian.org/python-team/packages

The two lintian errors wrong-vcs-location-for-dpmt and
wrong-vcs-location-for-papt should be changed accordingly.

Bug#855541: purple-matrix: Not ready for release yet

[Alex ARNAUD]

On Mon, 20 Feb 2017 00:12:35 +0100 Kurt Roeckx  wrote:
> Package: purple-matrix
> Version: 0.0.0+git20170105-1
> Severity: serious
>
> Hi,
>
> I think this version shouldn't be shipped with the next
> release. Like the description says, it's "somewhat alpha".
>
> It works some times, but then stops working, it crashes,
> and so on.

I've used the package purple-matrix on Debian 10 since at least 6 months 
through Pidgin. It's not a perfect tool, have issues but in my opinion 
it is usable. Sometimes purple-matrix is disconnected or makes Pidgin to 
crash but it's quite rare. It's sufficient to restart Pidgin to make it 
working again.


I have two points why I think we should have it into next stable:

 * This is very difficult for a stable user to use purple-matrix. In my
   case, I have had to rebuilt the package due to dependencies and it's
   clearly something not easy for all.
 * As a visual-impaired person, purple-matrix through Pidgin is the
   most accessible Matrix client I've used.


There are still reasons why we would like to keep it in unstable:

 * There are no commits in 2020
 * The project doesn't publish new release and "just" push commits


In my humble opinion, the drawbacks of keeping it to unstable are more 
important.



@Kurt: I let you decide if you prefer to keep close or not but since the 
creation of this issue in 2017 many commits come to the project.



Thanks in advance.

Bug#970742: plasma-workspace: No "Switch-User" with systemd V246

[Achim Schaefer]

Package: plasma-workspace
Version: 4:5.17.5-4
Severity: important
Tags: upstream

Dear Maintainer,

in archlinux they tested with Version 245 and it works again:
https://bugs.archlinux.org/task/67623

A bug in kde is already open:
https://bugs.kde.org/show_bug.cgi?id=423526

Thanks


--witch USer functionality doe snot work any more with systemd Version 246.
System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages plasma-workspace depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-1
ii  dbus-x11 [dbus-session-bus]   1.12.20-1
ii  drkonqi   5.17.5-2
ii  frameworkintegration  5.70.0-1
ii  gdb   9.2-1
ii  iso-codes 4.5.0-1
ii  kactivitymanagerd 5.17.5-2
ii  kded5 5.70.0-1
ii  kinit 5.70.0-1
ii  kio   5.70.1-1
ii  kpackagetool5 5.70.0-1
ii  kwin-common   4:5.17.5-3
ii  libappstreamqt2   0.12.11-1
ii  libc6 2.31-3
ii  libcolorcorrect5  4:5.17.5-4
ii  libgcc-s1 10.2.0-9
ii  libgps26  3.20-12
ii  libice6   2:1.0.9-2
ii  libkf5activities5 5.70.0-1
ii  libkf5activitiesstats15.70.0-1
ii  libkf5authcore5   5.70.0-1
ii  libkf5baloo5  5.70.0-2
ii  libkf5bookmarks5  5.70.0-1
ii  libkf5calendarevents5 5.70.0-1
ii  libkf5completion5 5.70.0-1
ii  libkf5config-bin  5.70.0-1
ii  libkf5configcore5 5.70.0-1
ii  libkf5configgui5  5.70.0-1
ii  libkf5configwidgets5  5.70.0-2
ii  libkf5coreaddons5 5.70.0-2
ii  libkf5crash5  5.70.0-1
ii  libkf5dbusaddons5 5.70.0-1
ii  libkf5declarative55.70.0-1
ii  libkf5globalaccel-bin 5.70.0-1
ii  libkf5globalaccel55.70.0-1
ii  libkf5guiaddons5  5.70.0-2
ii  libkf5holidays5   1:5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5idletime5   5.70.0-1
ii  libkf5itemmodels5 5.70.0-3
ii  libkf5jobwidgets5 5.70.0-1
ii  libkf5kdelibs4support55.70.0-2
ii  libkf5kiocore55.70.1-1
ii  libkf5kiofilewidgets5 5.70.1-1
ii  libkf5kiogui5 5.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5networkmanagerqt6   5.70.0-1
ii  libkf5newstuff5   5.70.0-1
ii  libkf5notifications5  5.70.0-1
ii  libkf5notifyconfig5   5.70.0-1
ii  libkf5package55.70.0-1
ii  libkf5people5 5.70.0-1
ii  libkf5peoplewidgets5  5.70.0-1
ii  libkf5plasma5 5.70.1-1
ii  libkf5plasmaquick55.70.1-1
ii  libkf5prison5 5.70.0-1
ii  libkf5quickaddons55.70.0-1
ii  libkf5runner5 5.70.0-1
ii  libkf5service-bin 5.70.0-1
ii  libkf5service55.70.0-1
ii  libkf5solid5  5.70.0-1
ii  libkf5texteditor5 5.70.1-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5wallet-bin  5.70.0-1
ii  libkf5wallet5 5.70.0-1
ii  libkf5waylandclient5  4:5.70.0-1
ii  libkf5widgetsaddons5  5.70.0-1
ii  

Bug#964621: fakeroot: statx function not wrapped, causing FTBFS

[jhcha54008]

Le lundi 21 septembre à 23h 11mn 37s (+), Clint Adams a écrit :
> On Mon, Sep 21, 2020 at 12:48:25PM +0200, jhcha54008 wrote:
> > should this bug be merged with #940056 and #968868 ?
> 
> If statx is the only reason for the failures.

Hi,

Oops, you're right : the test 't.xattr' keeps failing but statx
is not the culprit. 
It seems that the output format of getcap has changed (if I 
understand correctly) : the test code expects
 
$tmp/foo = cap_net_raw+ep

but gets instead

$tmp/foo cap_net_raw=ep

However, one may build successfully version 1.24.1-1 if t.xattr is 
corrected and statx is wrapped.
(actually, I tested with dpkg-buildpackage in a sid chroot on 
amd64/stretch and add libfakestatx.so.0.0 from [1] to LD_PRELOAD
in fakeroot)

I hope it will help to find a solution !

Regards,
JH Chatenet

[1] : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940056#10

Bug#970741: rhythmbox build-depends unsatisfiable in testing

[peter green]

Source: rhythmbox
Version: 3.4.4-2
Severity: serious

rhythmbox build-depends on gstreamer1.0-doc which is no longer built by the 
gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely 
gone from testing.

Bug#970740: farstream-0.2 build-depends unsatisfiable in testing

[peter green]

Source: farstream-0.2
Version: 0.2.8-5
Severity: serious

farstream-0.2 build-depends on gstreamer1.0-doc which is no longer built by the 
gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely 
gone from testing.

Bug#967546: udev: missing /dev/stdin etc.

[Michael Biebl]

Hi Ben,

thanks for notifying us.

Am 22.09.20 um 05:40 schrieb Ben Hutchings:
> Control: reopen 967546
> Control: block 970678 with 967546
> 
> This udev change also affected the installer, which has neither systemd
> nor sysvinit; see bug #970678.  It might also affect some other
> initramfs environments (but initramfs-tools itself doesn't use these
> symlinks, and dracut creates them).
> 
> systemd still includes the dev_setup() function which creates these
> symlinks, so I don't see why it can't be called by udevd.

Judging from the upstream commit [1], it's unlikely that I can convince
Lennart to revert this change and I really don't want to carry a
downstream revert patch for all eternity.

The alternative I see is, that we update the places which mount devtmpfs
and extend those to also setup the necessary symlinks as in dev_setup()[2].

For the udev package that would be debian/extra/start-udev
(debian-installer) and debian/udev.init (although I have been informed,
that the sysvinit package already has applied a workaround).

For initramfs-tools, this would be [3].

Are you ok, if we handle it this way?
I can provide a MR for initramfs-tools if wanted.

Regards,
Michael



[1] https://github.com/systemd/systemd/commit/6b2229c6c60d0486
[2]
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/src/shared/dev-setup.c#L18
[3]
https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/init#L37



signature.asc
Description: OpenPGP digital signature

Bug#970739: clutter-gst-3.0 build-depends unsatisfiable in testing

[peter green]

Source: clutter-gst-3.0
Version: 3.0.27-1
Severity: serious

clutter-gst-3.0 build-depends on gstreamer1.0-doc which is no longer built by 
the gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely 
gone from testing.

Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)

[Alec Leamas]

On 22/09/2020 13:52, Tobias Frost wrote:

> Uploading right after this mail with this cosmetic change:
> 
> l-1.2.1_orig/debian/changelog libcxx-serial-1.2.1/debian/changelog
> --- libcxx-serial-1.2.1_orig/debian/changelog 2020-09-22 13:46:47.366672711 
> +0200
> +++ libcxx-serial-1.2.1/debian/changelog  2020-09-22 13:50:03.325964836 
> +0200
> @@ -13,7 +13,6 @@
>* Fix lingering templates in d/watch.
>* New local patches:
>   - Drop v8stdint.h header (above)
> - - Make build verbose.
>* Cherry-picked upstream bugfix patches:
>   - Fix SerialImpl constructor resource leak.
>   - Handle 500kpbs serial ports.
> 
> 
> As always, thanks for your contributions!


And thanks for your thoughtful review, uploading and not least fixing my
last nitpicks!

Cheers!

--alec

Bug#970738: ITP: lucene8 -- Full-text search engine library for Java(TM)

[sudip]

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

* Package name: lucene8
  Version : 8.6.2
  Upstream Author : NA
* URL : https://lucene.apache.org/
* License : Apache-2.0
  Programming Lang: Java
  Description : Full-text search engine library for Java(TM)
Lucene is a full-text search engine for the Java(TM) programming language.
Lucene is not a complete application, but rather a code library and API
that can easily be used to add search capabilities to applications.

I can maintain it under the umbrella of Java team.

--
Regards
Sudip

Bug#970737: CVE-2020-17482

[Chris Hofstaedtler]

Source: pdns
Severity: important
Tags: security
Control: found -1 4.0.3-1
Control: found -1 4.1.6-3
Control: found -1 4.3.0-5

https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2020-05.html
Leaking uninitialised memory through crafted zone records

Bug#970431: wxwidgets3.0: Links in documentation points to build path, not installed path

[Scott Talbert]

On Wed, 16 Sep 2020, Scott Talbert wrote:

   For more information on socket events see href="/build/1st/wxwidgets3.0-3.0.5.1+dfsg/interface/wx/socket.h#wxSocketFlags">wxSocketFlags 
. 


This seems to be a change/regression in doxygen as the wx3.0-doc package 
that's in the archive doesn't have this problem.  Links seem to have switched 
from relative to absolute for some reason.  I'll bisect the issue and report 
upstream.


Fixed upstream: 
https://github.com/doxygen/doxygen/commit/dfc82af001c56254c6fde0affd009f80e19b1548


Thanks,
Scott

Bug#970736: linux-image-4.19.0-10-amd64: crashes once every few days

[Jouni Seppänen]

Package: src:linux
Version: 4.19.132-1
Severity: normal

Dear Maintainer,

I'm running a PCEngines APU3C4 system as a router, with a Huawei 909s-120
LTE module for the upstream connection. It has been crashing once every
few days.  Now I was able to catch the oops message on a separate computer
connected to the serial console.

The crashes may have started after I started using mbim-network
from libmbim-utils 1.18.0-1 to connect the LTE modem. I did this because
ModemManager/NetworkManager was unable to get an IPv6 address. (It turns
out that my ISP is only giving me a /64 subnet which is not supposed to
be broken down into further subnets, so I may well go back to ModemManager
and forgo IPv6.)

I say the crashes "may" have started after that, because they are not
easily reproducible, so the underlying problem might have been there and
I just didn't happen to see crashes before I changed the configuration.
The crash dump does seem to mention cdc_mbim on one of the cores, so
perhaps it is relevant.

[135697.443269] VFS: brelse: Trying to free free buffer
[135697.449620]  __find_get_block+0x265/0x2d0
[135697.449629] BUG: unable to handle kernel NULL pointer dereference at 
000d
[135697.449639] PGD 0 P4D 0 
[135697.453858]  __getblk_gfp+0x24/0x280
[135697.461871] Oops:  [#1] SMP NOPTI
[135697.464603]  ? lock_timer_base+0x67/0x80
[135697.468329] CPU: 0 PID: 527 Comm: rs:main Q:Reg Not tainted 4.19.0-10-amd64 
#1 Debian 4.19.132-1
[135697.472341]  __ext4_get_inode_loc+0xe4/0x3f0 [ext4]
[135697.476242] Hardware name: PC Engines apu3/apu3, BIOS v4.12.0.2 06/28/2020
[135697.485435]  ? ext4_dirty_inode+0x46/0x60 [ext4]
[135697.490343] RIP: 0010:new_sync_write+0x4d/0x160
[135697.497550]  ext4_reserve_inode_write+0x52/0xc0 [ext4]
[135697.502152] Code: 24 60 31 c0 31 c0 48 89 34 24 f6 c5 04 48 89 54 24 08 0f 
95 c0 01 c0 f6 c5 40 0f 85 f8 00 00 00 48 8b 97 f0 00 00 00 48 8b 12  42 0d 
20 0f 85 e4 00 00 00 f6 c5 10 75 18 48 8b 93 f0 00 00 00
[135697.507040]  ext4_mark_inode_dirty+0x51/0x1d0 [ext4]
[135697.512129] RSP: 0018:b7a780ae3e58 EFLAGS: 00010246
[135697.531306]  ? jbd2__journal_start+0xd9/0x1e0 [jbd2]
[135697.536337] RAX: 0002 RBX: 921527ccc600 RCX: 
8401
[135697.541925]  ext4_dirty_inode+0x46/0x60 [ext4]
[135697.546846] RDX:  RSI: 7feef0001580 RDI: 
921527ccc600
[135697.554133]  __mark_inode_dirty+0x1ba/0x380
[135697.558645] RBP: b7a780ae3f08 R08: 0121 R09: 
9215230e4b00
[135697.558656] R10: 0007 R11:  R12: 

[135697.565924]  generic_update_time+0xb6/0xd0
[135697.570204] R13: b7a780ae3f08 R14: 7feef0001580 R15: 

[135697.570215] FS:  7feefbe42700() GS:92152aa0() 
knlGS:
[135697.577465]  file_update_time+0xe1/0x130
[135697.584678] CS:  0010 DS:  ES:  CR0: 80050033
[135697.584686] CR2: 000d CR3: 00012466 CR4: 
000406f0
[135697.588926]  __generic_file_write_iter+0x98/0x1c0
[135697.596163] Call Trace:
[135697.604458]  ext4_file_write_iter+0xc6/0x3b0 [ext4]
[135697.608411]  ? common_file_perm+0x5b/0xf0
[135697.614280]  ? __seccomp_filter+0x44/0x4a0
[135697.621549]  ? security_file_permission+0x2c/0xb0
[135697.626359]  ? __handle_mm_fault+0xa83/0x1270
[135697.628895]  vfs_write+0xa5/0x1a0
[135697.633888]  new_sync_write+0xfb/0x160
[135697.637992]  ksys_write+0x57/0xd0
[135697.642196]  vfs_write+0xa5/0x1a0
[135697.647028]  do_syscall_64+0x53/0x110
[135697.651504]  ksys_write+0x57/0xd0
[135697.654940]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[135697.658806]  do_syscall_64+0x53/0x110
[135697.662234] RIP: 0033:0x7feefcf5b4a7
[135697.665666]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[135697.669461] Code: 44 00 00 41 54 49 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 
e8 fb fc ff ff 4c 89 e2 48 89 ee 89 df 41 89 c0 b8 01 00 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 34 fd ff ff 48
[135697.672879] RIP: 0033:0x7f415bee92c7
[135697.678062] RSP: 002b:7feefbe41840 EFLAGS: 0293 ORIG_RAX: 
0001
[135697.681853] Code: 44 00 00 41 54 55 49 89 d4 53 48 89 f5 89 fb 48 83 ec 10 
e8 5b fd ff ff 4c 89 e2 41 89 c0 48 89 ee 89 df b8 01 00 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 94 fd ff ff 48
[135697.685515] RAX: ffda RBX: 0007 RCX: 
7feefcf5b4a7
[135697.685523] RDX: 0121 RSI: 7feef0001580 RDI: 
0007
[135697.690721] RSP: 002b:7f415842c1d0 EFLAGS: 0293 ORIG_RAX: 
0001
[135697.709655] RBP: 7feef0001580 R08:  R09: 
6e69746974696572
[135697.713324] RAX: ffda RBX: 0005 RCX: 
7f415bee92c7
[135697.720978] R10: 3a6c656e72656b20 R11: 0293 R12: 
0121
[135697.720987] R13: 7feef0001580 R14:  R15: 
5579b67d9690
[135697.739901] RDX: 0053 RSI: 561b4f5be000 RDI: 

Bug#961511: [Pkg-xen-devel] Bug#961511: [PATCH] d/xen-utils-common.xen.init: disable oom killer for xenstored

[Elliott Mitchell]

On Tue, Sep 22, 2020 at 02:39:09PM +0200, Hans van Kranenburg wrote:
> How did you test it and how did you get a working process without the --?

By reading the man page, noticing there was no mention of "--" and then
trying `choom -n +5 sleep 5` and found that worked.  When you sent this
message I checked and GNU `sleep` does have "--version", thus I tried
`choom -n +5 sleep 5 --version` and found *that* failed.

A "--" seemed natural, but documentation omitting crucial details is a
problem.  Never mind.

Nice find, I did at one point have the oom-killer get the wrong process
and saw *problems*.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#970735: mpdecimal FTBFS in bullseye: symbol differences

[Helmut Grohne]

Source: mpdecimal
Version: 2.5.0-4
Severity: serious
Tags: ftbfs patch
User: helm...@debian.org
Usertags: rebootstrap

mpdecimal has a number of symbols whose appearance is quite dependent on
the precise compiler version. These tend to be symbols for inlined
functions and template instantiations. This presently causes FTBFS in
bullseye, e.g.:

https://tests.reproducible-builds.org/debian/rbuild/bullseye/amd64/mpdecimal_2.5.0-4.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bullseye/arm64/mpdecimal_2.5.0-4.rbuild.log.gz
https://tests.reproducible-builds.org/debian/rbuild/bullseye/armhf/mpdecimal_2.5.0-4.rbuild.log.gz

This happens, because the bullseye toolchain was not exactly the same as
the unstable toolchain at the time of the build and the compiler decided
to instantiate symbols differently. Instead of changing symbols back and
forth, I suggest simply marking them as optional.

Beyond this, you can use arch-bits=32 and arch-bits=64 to remove the
need for interpolating the symbol file since that feature is now present
in oldstable.

I'm attaching a patch for the optional stuff for your convenience.

Helmut
diff --minimal -Nru mpdecimal-2.5.0/debian/changelog 
mpdecimal-2.5.0/debian/changelog
--- mpdecimal-2.5.0/debian/changelog2020-08-06 15:33:23.0 +0200
+++ mpdecimal-2.5.0/debian/changelog2020-09-22 19:35:08.0 +0200
@@ -1,3 +1,10 @@
+mpdecimal (2.5.0-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark optional symbols as optional. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 22 Sep 2020 19:35:08 +0200
+
 mpdecimal (2.5.0-4) unstable; urgency=medium
 
   * Update symbols files.
diff --minimal -Nru mpdecimal-2.5.0/debian/libmpdec.symbols.in 
mpdecimal-2.5.0/debian/libmpdec.symbols.in
--- mpdecimal-2.5.0/debian/libmpdec.symbols.in  2020-08-06 15:33:23.0 
+0200
+++ mpdecimal-2.5.0/debian/libmpdec.symbols.in  2020-09-22 19:35:08.0 
+0200
@@ -416,22 +416,22 @@
  _ZN7decimal9UnderflowD2Ev@Base 2.5
  _ZN7decimallsERSoRKNS_7ContextE@Base 2.5
  _ZN7decimallsERSoRKNS_7DecimalE@Base 2.5
- 
(arch=ia64)_ZN9__gnu_cxx12__to_xstringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEET_PFiPT0_mPKS8_PvEmSB_z@Base
 2.5
+ 
(optional=templinst)_ZN9__gnu_cxx12__to_xstringINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcEET_PFiPT0_mPKS8_PvEmSB_z@Base
 2.5
  _ZNK7decimal10ValueError4whatEv@Base 2.5
  _ZNK7decimal11MallocError4whatEv@Base 2.5
  _ZNK7decimal12RuntimeError4whatEv@Base 2.5
  _ZNK7decimal16DecimalException4whatEv@Base 2.5
  _ZNK7decimal7Context4reprB5cxx11Ev@Base 2.5
  _ZNK7decimal7Decimal4reprB5cxx11Eb@Base 2.5
- (arch=!ia64 !ppc64el !kfreebsd-amd64 
!kfreebsd-i386)_ZNK7decimal7Decimal6to_sciB5cxx11Eb@Base 2.5
- 
(arch=ia64)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv@Base
 2.5
- (arch=!armel 
!riscv64)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 2.5
- (arch=!armel 
!riscv64)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 2.5
- (arch=!armel 
!riscv64)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 2.5
- (arch=!armel 
!riscv64)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 2.5
- (arch=!armel 
!riscv64)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 2.5
- 
(arch=ia64)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 2.5
- 
(arch=ia64)_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPcEEvT_S7_St20forward_iterator_tag@Base
 2.5
+ (optional=inline)_ZNK7decimal7Decimal6to_sciB5cxx11Eb@Base 2.5
+ 
(optional=templinst)_ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE10_M_releaseEv@Base
 2.5
+ 
(optional=templinst)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EE10_M_destroyEv@Base
 2.5
+ 
(optional=templinst)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EE10_M_disposeEv@Base
 2.5
+ 
(optional=templinst)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EE14_M_get_deleterERKSt9type_info@Base
 2.5
+ 
(optional=templinst)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EED0Ev@Base
 2.5
+ 
(optional=templinst)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EED1Ev@Base
 2.5
+ 
(optional=templinst)_ZNSt19_Sp_counted_deleterIPKcZN7decimal4util9shared_cpES1_EUlS1_E_SaIvELN9__gnu_cxx12_Lock_policyE2EED2Ev@Base
 2.5
+ 

Bug#970386: dovecot-imapd: assertion failure in message_part_finish when searching large folder

[Noah Meyerhans]

On Mon, Sep 21, 2020 at 03:43:32PM -0700, Noah Meyerhans wrote:
> > Note, I cannot attach these mails to this message, as otherwise the
> > Debian bug system refuses them, since they appear to contain malware,
> > which was probably the spammer's intent. So I uploaded them here:
> > 
> > https://www.andric.com/debian/bug970386-1.eml.xz
> > https://www.andric.com/debian/bug970386-2.eml.xz
> > https://www.andric.com/debian/bug970386-3.eml.xz
> 
> Thanks for these.  I have used them to successfully reproduce a crash
> when performing a server-side search using 1:2.2.27-3+deb9u6

I have also reproduced the crash with the buster version
(1:2.3.4.1-5+deb10u4 from stable-proposed-updates), but I have not been
able to crash with 1:2.3.11.3+dfsg1-2 from sid/bullseye.

noah

Bug#963392: [Help] Re: r-cran-rstanarm: FTBFS: error: (converted from warning) TBB library not found.

[Shayan Doust]

Hello Andreas,

Yes, this does seem like a local issue to r-cran-rcppparallel.

tbb and variants are loaded when r-cran-rcppparallel is imported, as seen in
[hooks.R]. The function of interest is 'tbbLibPath()', which seems to depict tbb
library path.

With some more investigation, you can see this function within [build.R]. You
can see for all supported platforms apart from Windows and Sparc systems, it
seems like it expects the library to be situated under lib/ (due to the first
argument used within system.file()).

I'll try to write a simple patch for this hook file. For a Debian package, this
assumption for library location is plain wrong.

Kind regards,
Shayan Doust


[hooks.R]:
https://github.com/RcppCore/RcppParallel/blob/b216ba27dcbd3c523932bd918b6dd0b1b08d3566/R/hooks.R#L8
[build.R]:
https://github.com/RcppCore/RcppParallel/blob/b216ba27dcbd3c523932bd918b6dd0b1b08d3566/R/build.R#L66

On Tue, 8 Sep 2020 20:32:53 +0200 Andreas Tille  wrote:
> Control: tags -1 help
> 
> Hi,
> 
> any help why TBB is not found?  I think this issue is actually causes by
> r-cran-rcppparallel since the code copy of libtbb was removed there -
> but it seems to not provide the Debian packaged lib properly.
> 
> Kind regards
> 
> Andreas.
> 
> -- 
> http://fam-tille.de
> 
> 


0x6D7D441919D02395.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#970717: kubernetes: abuse of "embedded code copies" | hundreds of vendored libraries

[Janos LENART]

Hi Elana,

Thank you for looking into this.

I've believed the vendor/ directory is thoroughly vetted, and I have also
checked every single directory, sometimes even files. I do not think there
is a DFSG issue here. Dmitry does not agree with the fact that vendor/ is
boundled in the Debian packages. It is not actually against the Debian
Policy either, only his interpretation of it. There was a flamewar on this
on debian-devel. Long story short, Dmitry did not maintain and did not want
to maintain the package, I've adopted it and repackaged it boundling the
vendor/ directory, Dmitry was upset because of the technical disagreement.
Nobody with actual powers had a problem with this. Marking this as a
serious bug is his latest attempt at sabotage.

Granted, the current solution is not ideal.

Janos

On Tue, Sep 22, 2020 at 6:09 PM Elana Hashman  wrote:

> On Tue, Sep 22, 2020 at 08:56:25PM +1000, Dmitry Smirnov wrote:
> >
> > As discussed in debian-devel, Kubernetes package abuses Debian practices
> > and Golang team policies by needlessly vendoring hundreds(!) of
> libraries,
> > most of which are available in Debian.
> >
> > For a complex package like Kubernetes, _some_ strategic vendoring would
> be
> > understandable for practical reasons. But not everything.
> >
> > Maintainer circumvented packaging practices and introduced re-packaged
> > Kubernetes in a state that would have never been accepted by ftp-masters.
> >
> > Please consider removing redundant libraries from "vendor".
> > In the current state, the package is unsuitable for "stable".
>
> It's not entirely clear to me if the policy concerns are around
> licensing compliance or simply the volume of vendored dependencies.
>
>
> Wearing my Kubernetes SIG Chair/upstream hat:
>
> I believe that the license compliance of everything in vendor/ has been
> thoroughly vetted, but that information may not have been adequately
> surfaced for downstream projects to use. In this case, any violations
> are surface-level/paperwork as opposed to fundamental issues with DFSG
> compliance. I've requested that upstream better surfaces this
> information in order to be able to build Kubernetes in a
> policy-compliant way in Debian:
> https://github.com/kubernetes/kubernetes/issues/94976
>
> Thanks,
>
> - e
>


-- 
LÉNÁRT, János

Bug#970734: cdist: new upstream version

[Matthias Stecher]

Package: cdist
Version: 6.0.2-1
Severity: wishlist

Dear Maintainer,

cdist version 6.8.0 is released upstream, while the latest available version is
6.0.2.

I'd like to use new versions of cdist via the debian repositories. If needed, I
can help, too.

Best regards,
Matthias



-- System Information:
Debian Release: bullseye/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_DIE, TAINT_WARN, 
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 cdist depends on:
ii  python3  3.8.2-3

cdist recommends no packages.

Versions of packages cdist suggests:
pn  cdist-doc  

-- no debconf information

Bug#970547: caja: changes file modification time on ssh remote copy

[Francesco Potortì]

Ok, I tried again and discovered this strange behaviour, which is the
reason for my previous confusion:

- copy from local to remote using Caja via ssh:
  file modification time is preserved

- move from local to remote using Caja via ssh:
  file modification time is set to current time

The same happens from remote to local.

When using 'gio copy --preserve' the modification time is not preserved,
in either direction.  The protocols are 'file' and 'sftp'.

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#970703: proxytunnel FTCBFS: forces the build architecture compiler

[Sven Geuer]

Hello Helmut,

I wasn't aware setting CC explicitly would interfere with cross-
building. Thanks for letting me know, it will be fixed shortly.

Sven

Am Dienstag, den 22.09.2020, 06:37 +0200 schrieb Helmut Grohne:
> Source: proxytunnel
> Version: 1.10.20200907-1
> Tags: patch
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> proxytunnel fails to cross build from source, because debian/rules
> forces the build architecture compiler. It even has a comment
> explaining
> that exporting CC makes changing the compiler simple. Unfortunately,
> that choice overrides the default choice of dh_auto_build and makes
> things fail. Please leave CC unset by default and only set it, when
> you
> know it needs being set. I'm attaching a patch that makes proxytunnel
> cross buildable for your convenience.
> 
> Helmut


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

Bug#970717: kubernetes: abuse of "embedded code copies" | hundreds of vendored libraries

[Elana Hashman]

On Tue, Sep 22, 2020 at 08:56:25PM +1000, Dmitry Smirnov wrote:
> 
> As discussed in debian-devel, Kubernetes package abuses Debian practices 
> and Golang team policies by needlessly vendoring hundreds(!) of libraries,
> most of which are available in Debian.
> 
> For a complex package like Kubernetes, _some_ strategic vendoring would be
> understandable for practical reasons. But not everything.
> 
> Maintainer circumvented packaging practices and introduced re-packaged
> Kubernetes in a state that would have never been accepted by ftp-masters.
> 
> Please consider removing redundant libraries from "vendor".
> In the current state, the package is unsuitable for "stable".

It's not entirely clear to me if the policy concerns are around
licensing compliance or simply the volume of vendored dependencies.


Wearing my Kubernetes SIG Chair/upstream hat:

I believe that the license compliance of everything in vendor/ has been
thoroughly vetted, but that information may not have been adequately
surfaced for downstream projects to use. In this case, any violations
are surface-level/paperwork as opposed to fundamental issues with DFSG
compliance. I've requested that upstream better surfaces this
information in order to be able to build Kubernetes in a
policy-compliant way in Debian:
https://github.com/kubernetes/kubernetes/issues/94976

Thanks,

- e


signature.asc
Description: PGP signature

Bug#905456: Please create new list debian-clojure

[Elana Hashman]

On Tue, Sep 22, 2020 at 02:02:40PM +0200, Alexander Wirt wrote:
> 
> ehm, but you asked on the list if subscribers should get subscribed to
> the new list? 

I did upon initial list request but it's been over a year. Would you
like me to ask again? (The list should be CC'd so this is pretty
transparent.)

- e


signature.asc
Description: PGP signature

Bug#970732: btrfsmaintenance: New upstream version available

[Christer Mjellem Strand]

Package: btrfsmaintenance
Version: 0.4.2-1
Severity: wishlist

Dear Maintainer,

Version 0.5 was released on 2020-07-30. Please consider updating this package 
when possible.

Thanks.

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

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

Versions of packages btrfsmaintenance depends on:
ii  btrfs-progs  4.20.1-2
ii  cron 3.0pl1-134+deb10u1
ii  systemd  241-7~deb10u4

btrfsmaintenance recommends no packages.

btrfsmaintenance suggests no packages.

Bug#970731: btrfsmaintenance: Update description: CFQ is no longer Debian's default scheduler

[Christer Mjellem Strand]

Package: btrfsmaintenance
Version: 0.4.2-1
Severity: minor

Dear Maintainer,

The description for this package mentions that "CFQ is Debian's default block 
scheduler."
At least as of buster, I don't believe this is true anymore:

# cat /sys/block/sd*/queue/scheduler
[mq-deadline] none
[mq-deadline] none
[mq-deadline] none
[mq-deadline] none

As such, the description should probably be updated.

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

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

Versions of packages btrfsmaintenance depends on:
ii  btrfs-progs  4.20.1-2
ii  cron 3.0pl1-134+deb10u1
ii  systemd  241-7~deb10u4

btrfsmaintenance recommends no packages.

btrfsmaintenance suggests no packages.

Bug#970726: patch uploaded in deferred/7

[Gianfranco Costamagna]

control: tags -1 patch pending

The following debdiff has been uploaded in deferred/7, feel free to 
reschedule/cancel it

diff -Nru rpi.gpio-0.7.0/debian/changelog rpi.gpio-0.7.0/debian/changelog
--- rpi.gpio-0.7.0/debian/changelog 2020-01-16 17:20:40.0 +0100
+++ rpi.gpio-0.7.0/debian/changelog 2020-09-22 18:16:04.0 +0200
@@ -1,3 +1,13 @@
+rpi.gpio (0.7.0-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Grab workaround from meta-raspberrypi to add fcommon and fix gcc-10 build
+failure (Closes: #970726)
+  * Fix README.txt installation, by fixing typo in debian/rpio.gpio-common.docs
+(Closes: #970728) (patch from Ubuntu Dave Jones )
+
+ -- Gianfranco Costamagna   Tue, 22 Sep 2020 
18:16:04 +0200
+
 rpi.gpio (0.7.0-0.1) unstable; urgency=medium

   * Non-maintainer upload.
diff -Nru rpi.gpio-0.7.0/debian/rpi.gpio-common.docs 
rpi.gpio-0.7.0/debian/rpi.gpio-common.docs
--- rpi.gpio-0.7.0/debian/rpi.gpio-common.docs  1970-01-01 01:00:00.0 
+0100
+++ rpi.gpio-0.7.0/debian/rpi.gpio-common.docs  2020-09-22 18:16:02.0 
+0200
@@ -0,0 +1 @@
+README.txt
diff -Nru rpi.gpio-0.7.0/debian/rpio.gpio-common.docs 
rpi.gpio-0.7.0/debian/rpio.gpio-common.docs
--- rpi.gpio-0.7.0/debian/rpio.gpio-common.docs 2018-06-12 14:22:46.0 
+0200
+++ rpi.gpio-0.7.0/debian/rpio.gpio-common.docs 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-README.txt
diff -Nru rpi.gpio-0.7.0/debian/rules rpi.gpio-0.7.0/debian/rules
--- rpi.gpio-0.7.0/debian/rules 2020-01-16 17:20:40.0 +0100
+++ rpi.gpio-0.7.0/debian/rules 2020-09-22 18:16:02.0 +0200
@@ -7,7 +7,7 @@

 export DEB_BUILD_MAINT_OPTIONS = hardening=+all

-DEB_CFLAGS_MAINT_APPEND += $(shell getconf LFS_CFLAGS)
+DEB_CFLAGS_MAINT_APPEND += $(shell getconf LFS_CFLAGS) -fcommon
 DEB_LDFLAGS_MAINT_APPEND += $(shell getconf LFS_LDFLAGS)
 DEB_LDFLAGS_MAINT_APPEND += -Wl,--as-needed
 export DEB_CFLAGS_MAINT_APPEND DEB_LDFLAGS_MAINT_APPEND


diff -Nru rpi.gpio-0.7.0/debian/changelog rpi.gpio-0.7.0/debian/changelog
--- rpi.gpio-0.7.0/debian/changelog 2020-01-16 17:20:40.0 +0100
+++ rpi.gpio-0.7.0/debian/changelog 2020-09-22 18:16:04.0 +0200
@@ -1,3 +1,13 @@
+rpi.gpio (0.7.0-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Grab workaround from meta-raspberrypi to add fcommon and fix gcc-10 build
+failure (Closes: #970726)
+  * Fix README.txt installation, by fixing typo in debian/rpio.gpio-common.docs
+(Closes: #970728) (patch from Ubuntu Dave Jones )
+
+ -- Gianfranco Costamagna   Tue, 22 Sep 2020 
18:16:04 +0200
+
 rpi.gpio (0.7.0-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rpi.gpio-0.7.0/debian/rpi.gpio-common.docs 
rpi.gpio-0.7.0/debian/rpi.gpio-common.docs
--- rpi.gpio-0.7.0/debian/rpi.gpio-common.docs  1970-01-01 01:00:00.0 
+0100
+++ rpi.gpio-0.7.0/debian/rpi.gpio-common.docs  2020-09-22 18:16:02.0 
+0200
@@ -0,0 +1 @@
+README.txt
diff -Nru rpi.gpio-0.7.0/debian/rpio.gpio-common.docs 
rpi.gpio-0.7.0/debian/rpio.gpio-common.docs
--- rpi.gpio-0.7.0/debian/rpio.gpio-common.docs 2018-06-12 14:22:46.0 
+0200
+++ rpi.gpio-0.7.0/debian/rpio.gpio-common.docs 1970-01-01 01:00:00.0 
+0100
@@ -1 +0,0 @@
-README.txt
diff -Nru rpi.gpio-0.7.0/debian/rules rpi.gpio-0.7.0/debian/rules
--- rpi.gpio-0.7.0/debian/rules 2020-01-16 17:20:40.0 +0100
+++ rpi.gpio-0.7.0/debian/rules 2020-09-22 18:16:02.0 +0200
@@ -7,7 +7,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-DEB_CFLAGS_MAINT_APPEND += $(shell getconf LFS_CFLAGS)
+DEB_CFLAGS_MAINT_APPEND += $(shell getconf LFS_CFLAGS) -fcommon
 DEB_LDFLAGS_MAINT_APPEND += $(shell getconf LFS_LDFLAGS)
 DEB_LDFLAGS_MAINT_APPEND += -Wl,--as-needed
 export DEB_CFLAGS_MAINT_APPEND DEB_LDFLAGS_MAINT_APPEND

Bug#970730: spice-gtk build-depends unsatisfiable in testing

[peter green]

Source: spice-gtk
Version: 0.38-2
Severity: serious

spice-gtk build-depends on gstreamer1.0-doc which is no longer built by the 
gstreamer1.0 source package.
It still seems to be present in unstable as a cruft package, but is completely 
gone from testing.

Bug#970726: rpi.gpio: FTBFS in sid (gcc-10)

[Gianfranco Costamagna]

control: tags -1 patch


This works...

--- rpi.gpio-0.7.0/debian/rules 2020-01-16 17:20:40.0 +0100
+++ rpi.gpio-0.7.0/debian/rules 2020-09-22 18:03:46.0 +0200
@@ -7,7 +7,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
-DEB_CFLAGS_MAINT_APPEND += $(shell getconf LFS_CFLAGS)
+DEB_CFLAGS_MAINT_APPEND += $(shell getconf LFS_CFLAGS) -fcommon
 DEB_LDFLAGS_MAINT_APPEND += $(shell getconf LFS_LDFLAGS)
 DEB_LDFLAGS_MAINT_APPEND += -Wl,--as-needed
 export DEB_CFLAGS_MAINT_APPEND DEB_LDFLAGS_MAINT_APPEND


G.

On Tue, 22 Sep 2020 17:58:36 +0200 Gianfranco Costamagna 
 wrote:
> Source: rpi.gpio
> Version: 0.7.0-0.1
> Severity: serious
> 
> Hello, looks like gcc-10 broke the rpi-gpio build (obviously only on arm*).
> 
> 
> people from meta-raspberrypi workarounded with the fcommon flag...
> # ignore issues with -fno-common from gcc-10 until it's fixed in upstream:
> # https://sourceforge.net/p/raspberry-gpio-python/tickets/187/
> CFLAGS += "-fcommon"
> 
> 
> aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python3.8 -c source/soft_pwm.c -o 
> build/temp.linux-arm64-3.8/source/soft_pwm.o
> aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python3.8 -c source/py_pwm.c -o 
> build/temp.linux-arm64-3.8/source/py_pwm.o
> aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python3.8 -c source/common.c -o 
> build/temp.linux-arm64-3.8/source/common.o
> aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
> -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat 
> -Werror=format-security -g -fwrapv -O2 -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC 
> -I/usr/include/python3.8 -c source/constants.c -o 
> build/temp.linux-arm64-3.8/source/constants.o
> aarch64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
> -Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-Bsymbolic-functions 
> -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -g -O2 
> -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
> build/temp.linux-arm64-3.8/source/py_gpio.o 
> build/temp.linux-arm64-3.8/source/c_gpio.o 
> build/temp.linux-arm64-3.8/source/cpuinfo.o 
> build/temp.linux-arm64-3.8/source/event_gpio.o 
> build/temp.linux-arm64-3.8/source/soft_pwm.o 
> build/temp.linux-arm64-3.8/source/py_pwm.o 
> build/temp.linux-arm64-3.8/source/common.o 
> build/temp.linux-arm64-3.8/source/constants.o -o 
> /<>/.pybuild/cpython3_3.8_rpi.gpio/build/RPi/_GPIO.cpython-38-aarch64-linux-gnu.so
> /usr/bin/ld: 
> build/temp.linux-arm64-3.8/source/soft_pwm.o:./source/soft_pwm.c:28: multiple 
> definition of `threads'; 
> build/temp.linux-arm64-3.8/source/event_gpio.o:./source/event_gpio.c:60: 
> first defined here
> /usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:38: 
> multiple definition of `gpio_direction'; 
> build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:38: first 
> defined here
> /usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/py_pwm.h:23: 
> multiple definition of `PWMType'; 
> build/temp.linux-arm64-3.8/source/py_gpio.o:./source/py_pwm.h:23: first 
> defined here
> /usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:41: 
> multiple definition of `module_setup'; 
> build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:41: first 
> defined here
> /usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:40: 
> multiple definition of `setup_error'; 
> build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:40: first 
> defined here
> /usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:39: 
> multiple definition of `rpiinfo'; 
> build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:39: first 
> defined here
> /usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:37: 
> multiple definition of `pin_to_gpio'; 
> build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:37: first 
> defined here
> /usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:36: 
> 

Bug#970729: CVE-2019-10203

[Chris Hofstaedtler]

Source: pdns
Severity: important
Tags: security
Control: found -1 4.0.3-1
Control: found -1 4.1.6-3
Control: fixed -1 4.2.0-1

https://doc.powerdns.com/authoritative/security-advisories/powerdns-advisory-2019-06.html
Denial of service via crafted zone records when using the gpgsql (PostgreSQL) 
backend

DSA has previously marked this as  (Minor issue)

Bug#970728: rpi.gpio: bad debian/doc file

[Gianfranco Costamagna]

Source: rpi.gpio
Version: 0.7.0-0.1
tags: patch


Hello, please do
mv debian/rpio.gpio-common.docs debian/rpi.gpio-common.docs

otherwise the file is completely useless...

(the patch comes from Ubuntu, Dave Jones )

thanks

G.

Bug#970727: python-magcode-core needs a source-only upload.

[peter green]

Source: python-magcode-core
Version: 1.5.4-2
Severity: serious

The release team have decreed that non-buildd binaries can no longer migrate to 
testing, please make a source-only
upload so your package can migrate.

Bug#970726: rpi.gpio: FTBFS in sid (gcc-10)

[Gianfranco Costamagna]

Source: rpi.gpio
Version: 0.7.0-0.1
Severity: serious

Hello, looks like gcc-10 broke the rpi-gpio build (obviously only on arm*).


people from meta-raspberrypi workarounded with the fcommon flag...
# ignore issues with -fno-common from gcc-10 until it's fixed in upstream:
# https://sourceforge.net/p/raspberry-gpio-python/tickets/187/
CFLAGS += "-fcommon"


aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security 
-g -fwrapv -O2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.8 -c source/soft_pwm.c -o 
build/temp.linux-arm64-3.8/source/soft_pwm.o
aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security 
-g -fwrapv -O2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.8 -c source/py_pwm.c -o 
build/temp.linux-arm64-3.8/source/py_pwm.o
aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security 
-g -fwrapv -O2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.8 -c source/common.c -o 
build/temp.linux-arm64-3.8/source/common.o
aarch64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security 
-g -fwrapv -O2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.8 -c source/constants.c -o 
build/temp.linux-arm64-3.8/source/constants.o
aarch64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions 
-Wl,-Bsymbolic-functions -Wl,-z,relro -g -fwrapv -O2 -Wl,-Bsymbolic-functions 
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 
build/temp.linux-arm64-3.8/source/py_gpio.o 
build/temp.linux-arm64-3.8/source/c_gpio.o 
build/temp.linux-arm64-3.8/source/cpuinfo.o 
build/temp.linux-arm64-3.8/source/event_gpio.o 
build/temp.linux-arm64-3.8/source/soft_pwm.o 
build/temp.linux-arm64-3.8/source/py_pwm.o 
build/temp.linux-arm64-3.8/source/common.o 
build/temp.linux-arm64-3.8/source/constants.o -o 
/<>/.pybuild/cpython3_3.8_rpi.gpio/build/RPi/_GPIO.cpython-38-aarch64-linux-gnu.so
/usr/bin/ld: 
build/temp.linux-arm64-3.8/source/soft_pwm.o:./source/soft_pwm.c:28: multiple 
definition of `threads'; 
build/temp.linux-arm64-3.8/source/event_gpio.o:./source/event_gpio.c:60: first 
defined here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:38: 
multiple definition of `gpio_direction'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:38: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/py_pwm.h:23: 
multiple definition of `PWMType'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/py_pwm.h:23: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:41: 
multiple definition of `module_setup'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:41: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:40: 
multiple definition of `setup_error'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:40: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:39: 
multiple definition of `rpiinfo'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:39: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:37: 
multiple definition of `pin_to_gpio'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:37: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:36: 
multiple definition of `pin_to_gpio_rev3'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:36: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:35: 
multiple definition of `pin_to_gpio_rev2'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:35: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:34: 
multiple definition of `pin_to_gpio_rev1'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:34: first defined 
here
/usr/bin/ld: build/temp.linux-arm64-3.8/source/py_pwm.o:./source/common.h:33: 
multiple definition of `gpio_mode'; 
build/temp.linux-arm64-3.8/source/py_gpio.o:./source/common.h:33: first defined 
here
/usr/bin/ld: 

Bug#970725: cups-client: lpoptions fails to get printer options

[Brian Potkin]

Package: cups-client
Version: 2.3.3-3
Severity: normal




cups-browsed is not running, 'lpstat -l -e' lists ENVY4500 as being on
the network and gives its URI. 'lpoptions -p ENVY4500 -l' (which works
on 2.3.3-2) gives:

 lpoptions: Unable to get PPD file for ENVY4500: The printer or class
does not exist.

'lpoptions -p ENVY4500' does work.

Regards,

Brian.

Bug#970580: licenseutils: Memory access error

[Mattia Rizzolo]

Control: forwarded -1 https://savannah.nongnu.org/bugs/?59157

On Sat, Sep 19, 2020 at 10:24:38AM +0200, Mechtilde Stehmann wrote:
> At the first start I got
> 
> licensing gpl: got unexpected response code 302 from
> www.gnu.org/licenses/gpl.txt
> 
> I also tested more options and get "Memory access error"
> 
> No option gives a result


thank you, forwarded upstream at the above URL.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#961371: [ftpmas...@ftp-master.debian.org: due_2.0.0-1_amd64.changes ACCEPTED into unstable, unstable]

[Alex Doyle]

Hi Geert,
 That's excellent! Thanks so much for your help with this.

I expect it will be a while ( like, months ) until I have a new version
ready to release. From reading the mentor's faq, it looks like I should
contact you?

I'd imagine that from here on out it would be a  lot less work involved to
approve new versions since there is a known good baseline to compare
against.

And thanks again - if we're ever at the same DebConf, I definitely owe you
a beverage of your choice :)
-Alex

On Tue, Sep 22, 2020 at 5:57 AM Geert Stappers  wrote:

> - Forwarded message from Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> -
>
> Date: Tue, 22 Sep 2020 12:00:09 +
> From: Debian FTP Masters 
> To: Alex Doyle , stapp...@debian.org
> Subject: due_2.0.0-1_amd64.changes ACCEPTED into unstable, unstable
>
>
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Sat, 19 Sep 2020 22:39:58 +0200
> Source: due
> Binary: due
> Architecture: source all
> Version: 2.0.0-1
> Distribution: unstable
> Urgency: medium
> Maintainer: Alex Doyle 
> Changed-By: Alex Doyle 
> Description:
>  due- Dedicated User Environment: manage build environments in
> Docker c
> Closes: 931617
> Changes:
>  due (2.0.0-1) unstable; urgency=medium
>  .
>[ Alex Doyle ]
>* Initial upload. Closes: #931617
>  .
>[ Geert Stappers ]
>* Uploader
> Checksums-Sha1:
>  88e1e57205188ce920e74d13a00025ba94aef04a 1852 due_2.0.0-1.dsc
>  b37ff0b79c5e26760c5bc170c70889570e127d14 105376 due_2.0.0.orig.tar.gz
>  2ff9c89b48952cf4dc36b1089d50b48160f3fcc7 2996 due_2.0.0-1.debian.tar.xz
>  fbcab6e758a3c4c3436dc27006cfd7b0d690dcdb 74120 due_2.0.0-1_all.deb
>  739d14896bed173ac0e728f21505bd897bc10ef3 6428 due_2.0.0-1_amd64.buildinfo
> Checksums-Sha256:
>  bc2c85160464733d11ae6701e3a178d7f1a137ab22b9ef0724eba0affc8d7a88 1852
> due_2.0.0-1.dsc
>  5a19ff71aaef037ec4b82bc925387065976e721ec08b488ffd597dfebde97780 105376
> due_2.0.0.orig.tar.gz
>  066fc8861f0ac05b90e01b8bc7f6e239e1c326e9d842852d345f295a8775210a 2996
> due_2.0.0-1.debian.tar.xz
>  619982dccb9589f15de424a557ec75d0fcd56644b6083ae5de8be31695994b4c 74120
> due_2.0.0-1_all.deb
>  9827e5c697f81e2200a7af1ddfc89e3a0bf777c2a21606f7bc7f8acc38858527 6428
> due_2.0.0-1_amd64.buildinfo
> Files:
>  4fb5cff6346482839b5fbc6b4a18dc3b 1852 devel optional due_2.0.0-1.dsc
>  2475a84a68ff837854caa1c607eab862 105376 devel optional
> due_2.0.0.orig.tar.gz
>  4ae14448019b16133ff25009a56d1a61 2996 devel optional
> due_2.0.0-1.debian.tar.xz
>  27b8b03bc1bc88215bf834b268e7b2fd 74120 devel optional due_2.0.0-1_all.deb
>  620d5bea2ced8f41fa3923a594784bf7 6428 devel optional
> due_2.0.0-1_amd64.buildinfo
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAl9mckwACgkQITXRI9jB
> m+xoNQ/9GLNX2pu3ivT6pnraXR0R6LyOdROv2qx0/7q22sYgsI4j3Arj8xtASNSK
> 7pO3HpMOmjdd3hRweO1EWrpQ6T+avqJBxirPSzFez673/P9xvNQRhhh/2ntqFQhu
> lxqom+iK48vyKFbUpE/2l1eoRzSHslTzBJP01IslfUj3zq+4HgXXzDy9Uv89xHL7
> B6L2aTaIFcME/mUayTHV/Sy8LPsaJmyGXNcV70ibXNklLMRww4VDUP1BvLzkGjl9
> Z54e85EzgwQokeQRwceA7hRTYLjZGFSRPH4lFkO81oeetv4TyQbfMRvLNb0UGvUy
> Lka6UvjU1vmjoQB/zCM8xJKDvWjuJofEXDVeJl8H3l7/vNZlq2A27TfkbEy5TrGZ
> Wblf9ga1XjiEokfFMo8jgbSQpaCLOOkof27Ac6FT/7AyviQzU1U+zULlPdtbP3jI
> a9epABkge/fnGRW0wTRklZjl0RyLnv7BWit+S0aRWunWBHueC0uzSRBVf/aUr6iX
> KrSeyotMVl8ZBkimc4Rb7M5Usu/vYXoQxA04CIZ7uPW3pFd1TmTxW6FipcieAn0j
> 31zkM+4KriDPuV4i9DtuZb+ePZ0YRYHPVCxY4ghG2ZaltN7KnRqyTSWBdPIA5YtD
> pVpD77tswBM/97GAoN5nDv3uuW6XYtBBhGv3A2rGQOPwp5XCbbw=
> =t2dI
> -END PGP SIGNATURE-
>
>
> Thank you for your contribution to Debian.
>
> - End forwarded message -
>
> --
> Regards
> Geert Stappers
> --
> Silence is hard to parse
>

Bug#970724: Suggests: check-pgbackrest

[Christoph Berg]

Package: pgbackrest
Version: 2.29-1
Severity: wishlist

Hi,

I recently packaged check_pgbackrest (package: check-pgbackrest) which
is the recommended monitoring plugin for pgbackrest (says Snow-Man).

Please consider adding `Suggests: check-pgbackrest` in the pgbackrest
control file.

Thanks,
Christoph

Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base

[tony mancill]

On Tue, Sep 22, 2020 at 10:07:12AM +0100, Julian Gilbey wrote:
> On Mon, Sep 21, 2020 at 10:49:24PM -0700, tony mancill wrote:
> > [...]
> > 
> > One other thing I wanted to mention is what I'm using for a test case:
> > 
> >   jlink --add-modules java.desktop --output test
> > 
> > This fails, complaining about the hash of java.xml recorded in
> > java.base.  But other invocations of jlink are successful with the
> 
> That is super-weird; this command works fine for me.
> 
> Things to check (again, just trying to think of obvious things that
> I might well do wrong myself ;-): what is the output of
> 
> jlink describe 
> debian/openjdk-11-jdk-headless/usr/lib/jvm/java-14-openjdk-amd64/jmods/java.base.jmod
>  | grep java.xml
> sha256sum 
> debian/openjdk-14-jdk-headless/usr/lib/jvm/java-14-openjdk-amd64/jmods/java.xml.jmod
> 
> (run in the build directory)?  Do these hashes match those in the
> error message that you're seeing with the failing jlink command?

No, the hashes don't match, although FWIW, they are consistent across
builds.  Looking only at java.xml.jmod...


>From the build logs:

Creating java.xml.jmod
Executing: [/bin/rm -f /<>/build/images/jmods/java.xml.jmod 
/<>/build/support/images/jmods/java.xml.jmod]
Executing: [/<>/build/jdk/bin/jmod -J-XX:+UseSerialGC -J-Xms32M 
-J-Xmx512M -J-XX:TieredStopAtLevel=1 create --module-version 14.0.2 
--target-platform 'linux-amd64' --module-path 
/<>/build/images/jmods --class-path 
/<>/build/jdk/modules/java.xml --legal-notices 
"/<>/build/support/modules_legal/common:/<>/src/java.xml/share/legal"
 --exclude '**{_the.*,_*.marker,*.diz,*.debuginfo,*.dSYM/**,*.dSYM}' 
/<>/build/support/images/jmods/java.xml.jmod]
Executing: [strip-nondeterminism 
/<>/build/support/images/jmods/java.xml.jmod && sha256sum 
/<>/build/support/images/jmods/java.xml.jmod && /bin/mv 
/<>/build/support/images/jmods/java.xml.jmod 
/<>/build/images/jmods/java.xml.jmod]
4a15f120c6eedb70aee4bca50f90e62e9f48dd7517eb511087a0c05e26efa039  
/<>/build/support/images/jmods/java.xml.jmod

 
On the filesystem after installing the binary packages:

$ sha256sum /usr/lib/jvm/java-14-openjdk-amd64/jmods/java.xml.jmod
22fa9b1ebb789375c8fb8e1644bc2b49620a63a13682dc4d5a4497d445d9ef89  
/usr/lib/jvm/java-14-openjdk-amd64/jmods/java.xml.jmod

>From the error message:

Error: Hash of java.xml 
(22fa9b1ebb789375c8fb8e1644bc2b49620a63a13682dc4d5a4497d445d9ef89) differs to 
expected hash 
(4a15f120c6eedb70aee4bca50f90e62e9f48dd7517eb511087a0c05e26efa039) recorded in 
java.base


This leads me to question whether strip-nondeterminism is idempotent,
although based on some simple empirical testing, it appears that it is.
In any event, something is happening the jmod later during the build
such that it differs from what was recorded.  I'm still trying to grok
the logic around the "interim" builds of jmods; perhaps that's where the
difference lies.

 
> Which jlink are you using when you run your test command?
> (/usr/bin/jlink is a symlink to /etc/alternatives/jlink - where does
> that point?)

Everything looks sane with my openjdk-14

$ ls -al /usr/bin/jlink  
lrwxrwxrwx 1 root root 23 Jul 16  2018 /usr/bin/jlink -> /etc/alternatives/jlink
$ ls -al /etc/alternatives/jlink
lrwxrwxrwx 1 root root 44 Sep 21 21:21 /etc/alternatives/jlink -> 
/usr/lib/jvm/java-14-openjdk-amd64/bin/jlink


> > patched build.  For example, the following is fine:
> > 
> >   jlink --add-modules java.base --output test
> > 
> > As does java.compiler and 32 others.  So 34 are okay and 38 of them are
> > failing.  The "good" vs. "fail" modules are attached in case it sparks
> > inspiration for someone.  I will take a look at the output of the
> > non-parallelized build in the (GMT-7) morning.
> > 
> > So there are approximately 50/50 odds that your test case is working
> > (hence the confusion), because the strip-determinism patch is only be
> > causing problems for a subset of modules.
> 
> There's nothing obvious to me in this list.  It's just a mystery...
> In my build, the SHA-256 hashes in java.base.jmod exactly match the
> SHA-256 hashes of the jmod files themselves.

Perhaps you'd like to prepare a source package and/or could make your
binaries available so I can try to reproduce with your build.

If this due to my local setup, and given that I was planning on a
delayed NMU anyway, another option would be for you to NMU your working
build (maybe to experimental we want to poke at it more).

> > Thank you for the ideas.  I will keep working on it.
> 
> Could you perhaps make your openjdk-*_*.debian.tar.xz available
> somewhere so that I can try it on my machine, and see if there's a
> difference between machines?  (I can get the .orig.tar.gz from the
> mirrors.)

Sure thing.  My debian.tar.xz and the build log from the .NONPARALLEL:
build, etc. can be found here:
https://people.debian.org/~tmancill/openjdk-14/944738/

FWIW, I ran the same "test all modules" with this most current build and
the same set of 

Bug#970723: libxom-java: missing dependency on jaxen in POM

[Andrius Merkys]

Package: libxom-java
Tags: patch

Hello,

Sources of jaxen were stripped from xom source, using Debian-provided
libjaxen-java instead. However, the dependency on jaxen is not
registered in pom.xml, resulting in failures of reverse dependencies of
libxom-java:

java.lang.NoClassDefFoundError: org/jaxen/NamespaceContext

I propose adding the following to libxom-java's pom.xml:

+
+jaxen
+jaxen
+

This way Maven builds/tests of sources depending on xom will
transitively pull in jaxen.

Andrius

Bug#970721: xom: new releases available

[Andrius Merkys]

Source: xom

Hello,

debian/watch for xom is failing, but the watched site does not seem to
be up-to-date enough. The watched site provides a link to GitHub [1],
which contains many more recent releases. I suggest switching
debian/watch to GitHub site, and package the newest upstream from there.

Andrius

[1] https://github.com/elharo/xom/tags

Bug#970722: linux: Igc driver has /proc/net/dev stats issue

[Hideo Oshima]

Source: linux
Version: 5.8.10-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I use Intel I225-V Ethernet controller with igc driver.
But it has /proc/net/dev stats issue.
For example Receive and Transmit bytes, packetes are all 0.

$cat /proc/net/dev
Inter-|   Receive|  Transmit
 face |bytespackets errs drop fifo frame compressed multicast|bytes
packets errs drop fifo colls carrier compressed
lo:   22642 271000 0  0 022642
271000 0   0  0
enp9s0:   0   00 96480 0  0 00
0000 0   0  0

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

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

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

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

-- 
大島秀夫(Hideo Oshima)
http://hidenosuke.org/

Bug#970711: False positive: globbing-patterns-out-of-order extra/readline/* */CMakeLists.txt

[Felix Lechner]

Hi Otto,

On Tue, Sep 22, 2020 at 2:03 AM Otto Kekäläinen  wrote:
>
> Maybe it cannot parse paths that start with a
> wildcard?

I agree. The issue is the matching behavior of the leading wildcard.

This is probably the same as Bug#970274 but I ultimately decided
against merging them because the ineffective re-ordering attempts you
described. They are probably a consequence, but I am not sure. It
should be examined after the other bug was solved.

Merging the bugs the other way around seemed also like a poor idea,
because Bug#970274 pinpoints the exact reference from the copyright
specification at issue here. The copyright check was rewritten
recently. There is no official parser.

Thanks for helping to make Lintian better for everyone, and sorry
about all the bugs!

Kind regards
Felix Lechner

Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.

[Florian Bruhin]

Hi Dmitry,

On Tue, Sep 22, 2020 at 03:56:15PM +0300, Dmitry Shachnev wrote:
> Hi Florian!
> 
> On Tue, Sep 22, 2020 at 01:48:17PM +0200, Florian Bruhin wrote:
> > reassign -1 libqt5webenginecore5 5.14.2+dfsg1-5
> > thanks
> >
> > Hey,
> >
> > Since you can reproduce this with Falkon, it definitely isn't an issue
> > in qutebrowser. Reassigning this to QtWebEngine. Let's hope it works,
> > I'm not too experienced with using Debian's BTS - whoever is on the
> > receiving end, please let me know if I messed up something :)
> 
> I see you ended up sending a mail to cont...@bugs.debian.org. Another way is
> sending a mail to the bug itself but prefixing the commands with "Control: ".

Ah, thanks! I guess with that, the "-1" would've worked properly as
well. I ended up getting an error and trying again with explicitly
specifying the bug number.

> > Thanks! For reference, here's a demangled version of the relevant stack
> > trace:
> >
> > #0  0x7f6842b6928f 
> > blink::CompositedLayerMapping::ComputeBoundsOfOwningLayer(blink::PaintLayer 
> > const*, blink::IntRect&, blink::IntRect&, blink::PhysicalOffset&, 
> > blink::IntPoint&) (libQt5WebEngineCore.so.5   0x462928f)
> > #1  0x7f6842b74054 
> > blink::CompositedLayerMapping::UpdateGraphicsLayerGeometry(blink::PaintLayer
> >  const*, blink::PaintLayer const*, WTF::Vector > WTF::PartitionAllocator>&, blink::GraphicsLayerUpdater::UpdateContext&) 
> > (libQt5WebEngineCore.so.5   0x4634054)
> > #2  0x7f6842b76561 
> > blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
> > blink::GraphicsLayerUpdater::UpdateType, 
> > blink::GraphicsLayerUpdater::UpdateContext&, 
> > WTF::Vector&) 
> > (libQt5WebEngineCore.so.5   0x4636561)
> > #3  0x7f6842b764ca 
> > blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
> > blink::GraphicsLayerUpdater::UpdateType, 
> > blink::GraphicsLayerUpdater::UpdateContext&, 
> > WTF::Vector&) 
> > (libQt5WebEngineCore.so.5   0x46364ca)
> > #4  0x7f6842b764ca 
> > blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
> > blink::GraphicsLayerUpdater::UpdateType, 
> > blink::GraphicsLayerUpdater::UpdateContext&, 
> > WTF::Vector&) 
> > (libQt5WebEngineCore.so.5   0x46364ca)
> > #5  0x7f6842b764ca 
> > blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
> > blink::GraphicsLayerUpdater::UpdateType, 
> > blink::GraphicsLayerUpdater::UpdateContext&, 
> > WTF::Vector&) 
> > (libQt5WebEngineCore.so.5   0x46364ca)
> > [...]
> >
> > From a quick search in QtWebEngine's and Chromium's bugtracker I
> > couldn't find anything relevant... I also don't remember seeing this
> > stacktrace before.
> 
> I also have no clue about this. Unfortunately we build Qt WebEngine without
> any debugging information so it is impossible to get the line numbers.
> But I see the ComputeBoundsOfOwningLayer method changed between Qt 5.14 and
> 5.15, so let's see if upgrading to Qt 5.15 helps here (I am working on it).

Let me note that QtWebEngine 5.15.1 has another bug causing frequent
renderer process crashes: https://bugreports.qt.io/browse/QTBUG-86752

I'm currently trying to bisect it because it seems to work in the
current 5.15 branch - but I suppose it might be the Chromium update
between 5.15.1 and 5.15(.2) fixing this again.

Thus, I'd recommend either staying with 5.15.0, or using the current
5.15 HEAD (or waiting for 5.15.2).

Florian

-- 
m...@the-compiler.org (Mail/XMPP) | https://www.qutebrowser.org 
   https://bruhin.software/ | https://github.com/sponsors/The-Compiler/
   GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
 I love long mails! | https://email.is-not-s.ms/


signature.asc
Description: PGP signature

Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.

[Dmitry Shachnev]

Hi Florian!

On Tue, Sep 22, 2020 at 01:48:17PM +0200, Florian Bruhin wrote:
> reassign -1 libqt5webenginecore5 5.14.2+dfsg1-5
> thanks
>
> Hey,
>
> Since you can reproduce this with Falkon, it definitely isn't an issue
> in qutebrowser. Reassigning this to QtWebEngine. Let's hope it works,
> I'm not too experienced with using Debian's BTS - whoever is on the
> receiving end, please let me know if I messed up something :)

I see you ended up sending a mail to cont...@bugs.debian.org. Another way is
sending a mail to the bug itself but prefixing the commands with "Control: ".

> Thanks! For reference, here's a demangled version of the relevant stack
> trace:
>
> #0  0x7f6842b6928f 
> blink::CompositedLayerMapping::ComputeBoundsOfOwningLayer(blink::PaintLayer 
> const*, blink::IntRect&, blink::IntRect&, blink::PhysicalOffset&, 
> blink::IntPoint&) (libQt5WebEngineCore.so.5   0x462928f)
> #1  0x7f6842b74054 
> blink::CompositedLayerMapping::UpdateGraphicsLayerGeometry(blink::PaintLayer 
> const*, blink::PaintLayer const*, WTF::Vector WTF::PartitionAllocator>&, blink::GraphicsLayerUpdater::UpdateContext&) 
> (libQt5WebEngineCore.so.5   0x4634054)
> #2  0x7f6842b76561 
> blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
> blink::GraphicsLayerUpdater::UpdateType, 
> blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector 0u, WTF::PartitionAllocator>&) (libQt5WebEngineCore.so.5   0x4636561)
> #3  0x7f6842b764ca 
> blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
> blink::GraphicsLayerUpdater::UpdateType, 
> blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector 0u, WTF::PartitionAllocator>&) (libQt5WebEngineCore.so.5   0x46364ca)
> #4  0x7f6842b764ca 
> blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
> blink::GraphicsLayerUpdater::UpdateType, 
> blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector 0u, WTF::PartitionAllocator>&) (libQt5WebEngineCore.so.5   0x46364ca)
> #5  0x7f6842b764ca 
> blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
> blink::GraphicsLayerUpdater::UpdateType, 
> blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector 0u, WTF::PartitionAllocator>&) (libQt5WebEngineCore.so.5   0x46364ca)
> [...]
>
> From a quick search in QtWebEngine's and Chromium's bugtracker I
> couldn't find anything relevant... I also don't remember seeing this
> stacktrace before.

I also have no clue about this. Unfortunately we build Qt WebEngine without
any debugging information so it is impossible to get the line numbers.
But I see the ComputeBoundsOfOwningLayer method changed between Qt 5.14 and
5.15, so let's see if upgrading to Qt 5.15 helps here (I am working on it).

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#961371: [ftpmas...@ftp-master.debian.org: due_2.0.0-1_amd64.changes ACCEPTED into unstable, unstable]

[Geert Stappers]

- Forwarded message from Debian FTP Masters 
 -

Date: Tue, 22 Sep 2020 12:00:09 +
From: Debian FTP Masters 
To: Alex Doyle , stapp...@debian.org
Subject: due_2.0.0-1_amd64.changes ACCEPTED into unstable, unstable



Accepted:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sat, 19 Sep 2020 22:39:58 +0200
Source: due
Binary: due
Architecture: source all
Version: 2.0.0-1
Distribution: unstable
Urgency: medium
Maintainer: Alex Doyle 
Changed-By: Alex Doyle 
Description:
 due- Dedicated User Environment: manage build environments in Docker c
Closes: 931617
Changes:
 due (2.0.0-1) unstable; urgency=medium
 .
   [ Alex Doyle ]
   * Initial upload. Closes: #931617
 .
   [ Geert Stappers ]
   * Uploader
Checksums-Sha1:
 88e1e57205188ce920e74d13a00025ba94aef04a 1852 due_2.0.0-1.dsc
 b37ff0b79c5e26760c5bc170c70889570e127d14 105376 due_2.0.0.orig.tar.gz
 2ff9c89b48952cf4dc36b1089d50b48160f3fcc7 2996 due_2.0.0-1.debian.tar.xz
 fbcab6e758a3c4c3436dc27006cfd7b0d690dcdb 74120 due_2.0.0-1_all.deb
 739d14896bed173ac0e728f21505bd897bc10ef3 6428 due_2.0.0-1_amd64.buildinfo
Checksums-Sha256:
 bc2c85160464733d11ae6701e3a178d7f1a137ab22b9ef0724eba0affc8d7a88 1852 
due_2.0.0-1.dsc
 5a19ff71aaef037ec4b82bc925387065976e721ec08b488ffd597dfebde97780 105376 
due_2.0.0.orig.tar.gz
 066fc8861f0ac05b90e01b8bc7f6e239e1c326e9d842852d345f295a8775210a 2996 
due_2.0.0-1.debian.tar.xz
 619982dccb9589f15de424a557ec75d0fcd56644b6083ae5de8be31695994b4c 74120 
due_2.0.0-1_all.deb
 9827e5c697f81e2200a7af1ddfc89e3a0bf777c2a21606f7bc7f8acc38858527 6428 
due_2.0.0-1_amd64.buildinfo
Files:
 4fb5cff6346482839b5fbc6b4a18dc3b 1852 devel optional due_2.0.0-1.dsc
 2475a84a68ff837854caa1c607eab862 105376 devel optional due_2.0.0.orig.tar.gz
 4ae14448019b16133ff25009a56d1a61 2996 devel optional due_2.0.0-1.debian.tar.xz
 27b8b03bc1bc88215bf834b268e7b2fd 74120 devel optional due_2.0.0-1_all.deb
 620d5bea2ced8f41fa3923a594784bf7 6428 devel optional 
due_2.0.0-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEin8gjG2ecykWV0FNITXRI9jBm+wFAl9mckwACgkQITXRI9jB
m+xoNQ/9GLNX2pu3ivT6pnraXR0R6LyOdROv2qx0/7q22sYgsI4j3Arj8xtASNSK
7pO3HpMOmjdd3hRweO1EWrpQ6T+avqJBxirPSzFez673/P9xvNQRhhh/2ntqFQhu
lxqom+iK48vyKFbUpE/2l1eoRzSHslTzBJP01IslfUj3zq+4HgXXzDy9Uv89xHL7
B6L2aTaIFcME/mUayTHV/Sy8LPsaJmyGXNcV70ibXNklLMRww4VDUP1BvLzkGjl9
Z54e85EzgwQokeQRwceA7hRTYLjZGFSRPH4lFkO81oeetv4TyQbfMRvLNb0UGvUy
Lka6UvjU1vmjoQB/zCM8xJKDvWjuJofEXDVeJl8H3l7/vNZlq2A27TfkbEy5TrGZ
Wblf9ga1XjiEokfFMo8jgbSQpaCLOOkof27Ac6FT/7AyviQzU1U+zULlPdtbP3jI
a9epABkge/fnGRW0wTRklZjl0RyLnv7BWit+S0aRWunWBHueC0uzSRBVf/aUr6iX
KrSeyotMVl8ZBkimc4Rb7M5Usu/vYXoQxA04CIZ7uPW3pFd1TmTxW6FipcieAn0j
31zkM+4KriDPuV4i9DtuZb+ePZ0YRYHPVCxY4ghG2ZaltN7KnRqyTSWBdPIA5YtD
pVpD77tswBM/97GAoN5nDv3uuW6XYtBBhGv3A2rGQOPwp5XCbbw=
=t2dI
-END PGP SIGNATURE-


Thank you for your contribution to Debian.

- End forwarded message -

-- 
Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#970692: dovecot-core: fts_solr plugin failure

[Raphaël Walther]

On Mon, 21 Sep 2020 10:43:43 -0700, Noah Meyerhans wrote:
> Thanks for this report.  If we're able to provide builds with this patch
> backported, will you be able to validate that the issue is resolved?  If
> so, we should be able to get this fixed in an upcoming buster point
> release.

Yes, this is a bug I can reproduce.

Bug#970678: Forwarding debian-boot posting

[Geert Stappers]

- Partly forwarded message from Bjørn Mork -

Date: Tue, 22 Sep 2020 12:17:38 +0200
From: Bjørn Mork
To: debian-b...@lists.debian.org
Subject: Re: Bug#970678: Network preseeding using http is broken

Ben Hutchings  writes:
>
> It's a udev regression, bug #967546.

Looks like that's deliberate, so probably Not A Bug.  Quoting from
https://github.com/systemd/systemd/commit/6b2229c6c60d0486 :

 "if people want to use udev from other init systems
  they should do this on their own,"

You might want to just fork udev while it still sort of works outside
systemd.


Bjørn

- End partly forwarded message -

I hope this helps both bugreports.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#961511: [Pkg-xen-devel] Bug#961511: [PATCH] d/xen-utils-common.xen.init: disable oom killer for xenstored

[Hans van Kranenburg]

notfixed 961511 xen/4.14.0-1~exp1
thanks

Right... so in the end I made an off-by-one error while rebasing and
totally lost that commit. It's not actually in 4.14.0-1~exp1 now. That's
bad.

On 9/21/20 3:50 AM, Elliott Mitchell wrote:
> This is fun.  Actually isn't too difficult to trigger, simply slowly
> reduce the memory Xen allocates to Dom0 and eventually the oom-killer is
> likely to trigger (having tried to shrink Dom0 as far as possible,
> believe me, I know).  I had been wondering which of the Xen daemons could
> be safely restarted since it is handy to restart daemons instead of whole
> machine for security updates...
> 
> Interestingly running `xenstored --help` mentions:
>   -I, --internal-db   store database in memory, not on disk
> 
> There is a run/xenstored/tdb file so I end up wondering if newer versions
> are in fact storing everything in a file and restarting isn't so bad.

Not by default, and I don't know if it's actually considered best
practice. I could not find any info about this yet. I suspect it's not
recommended.

oxenstored has the following option in /etc/xen/oxenstored.conf:

# Activate filed base backend
persistent = false

When enabling this, the file /run/xenstored/db gets rewritten a lot and
I also see it's out of sync with what's in xenstore-ls after doing some
things. So, it might me inconsistent when the process is oom-killed.

> The patch switches the arguments from:
> --exec "$try_xenstored" -- ...
> to:
> --exec /usr/bin/choom -- -n -1000 "$try_xenstored" -- ...
> 
> I'm pretty sure start-stop-daemon is consuming the "--" and the second
> "--" shouldn't be there.

Well, I tested it and found out that it's needed...

-# start-stop-daemon --start \
   --pidfile "/run/xenstore.pid" \
   --exec /usr/bin/choom -- -n -1000 \
   /usr/lib/xen-4.14/bin/oxenstored --pid-file "/run/xenstore.pid"
/usr/bin/choom: unrecognized option '--pid-file'
Try 'choom --help' for more information.

-# start-stop-daemon --start \
   --pidfile "/run/xenstore.pid" \
   --exec /usr/lib/xen-4.14/bin/oxenstored --test
Would start /usr/lib/xen-4.14/bin/oxenstored .

and with the extra separator:

-# start-stop-daemon --start \
   --pidfile "/run/xenstore.pid" \
   --exec /usr/bin/choom -- -n -1000 \
   /usr/lib/xen-4.14/bin/oxenstored -- --pid-file "/run/xenstore.pid"

-# grep . /proc/$(pidof /usr/lib/xen-4.14/bin/oxenstored)/oom_*
/proc/363043/oom_adj:-17
/proc/363043/oom_score:0
/proc/363043/oom_score_adj:-1000

-# cat /proc/$(pidof /usr/lib/xen-4.14/bin/oxenstored)/cmdline
/usr/lib/xen-4.14/bin/oxenstored--pid-file/run/xenstore.pid

How did you test it and how did you get a working process without the --?

Hans

Bug#946231: Versions, Upstream version versus Debian version

[Jan Luca Naumann]

Dear all,

since one concern pronounced in this bug report was that there is no
automatic migration. Therefore, I developed a helper script to convert
most kinds of pkla files to the JS-based format (see attachment). I
created a merge request in the upstream repo as well if they want to
include the converter as well [1].

Maybe it is now possible to upgrade polkit to a newer version including
the new-style rules?

Best,
Jan

[1] https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/66

On Fri, 6 Dec 2019 00:25:41 + Simon McVittie  wrote:
> On Thu, 05 Dec 2019 at 23:07:00 +0100, Geert Stappers wrote:
> > Upstream is at version 0.116 ( 
> > https://gitlab.freedesktop.org/polkit/polkit/-/tags )
> > Debian version is 0.105-something ( 
> > https://salsa.debian.org/utopia-team/polkit/blob/master/debian/changelog )
> > 
> > Debian changelog talks about changes from upstream version 0.114 and 0.116.
> 
> The latest upstream version is available in experimental.
> 
> The version in unstable is exactly what its version number indicates:
> a very old upstream version, with the majority of the upstream changes
> from later versions backported into it via debian/patches.
> 
> The reason for this is that upstream version
> 0.106 removed the "localauthority" backend (which
> configures polkit via .ini-style files like for example
> /var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.Flatpak.pkla,
> which can be overridden by sysadmin configuration in
> /etc/polkit-1/localauthority or /var/lib/polkit-1/localauthority)
> and replaced it with a new JavaScript-based backend (which
> configures polkit via short JavaScript fragments like for example
> /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules, which can be
> overridden by sysadmin configuration in /etc/polkit-1/rules.d).
> 
> The migration path between the two is not obvious, and some of the Debian
> maintainers of polkit are strongly opposed to it being configured with
> JavaScript files, so at the moment we are stuck with polkit 0.105.
> 
> One day, I want to stop patching changes from 0.11x into 0.105,
> and instead start patching the "localauthority" backend into 0.11x,
> so that we can stick to the upstream version in all respects except
> for the configuration backend. However, all the maintainers of polkit
> (both in Debian and upstream) mostly work on other things, so it's rare
> that someone has enough uninterrupted time to do something like that.
> 
> There has been some upstream unhappiness with the current configuration
> arrangements, mostly because the mozjs library that is used for the
> JavaScript interpreter does not have a stable API; so it is possible that
> a newer upstream version will either change the configuration language
> (again), or change the JavaScript implementation to something more friendly
> (most likely a smaller interpreter like duktape).
> 
> smcv
> 
> 
#!/usr/bin/env python3

from __future__ import annotations

import argparse
import configparser
from dataclasses import dataclass
import enum
import sys
import traceback
from textwrap import dedent, indent
from typing import Dict, List, Optional, Union, cast


def ensure_indent(text: str, numspaces: int = 4) -> str:
return indent(dedent(text), " " * numspaces)


class PolkitConfConverterException(Exception):
def __init__(self, msg: str):
super().__init__()
self.msg = msg


class PolkitIdType(enum.Enum):
USER = enum.auto()
GROUP = enum.auto()
NETGROUP = enum.auto()

@classmethod
def parse_identity_type(cls, input: str) -> PolkitIdType:
result_map = {
"unix-user": cls.USER,
"unix-group": cls.GROUP,
"unix-netgroup": cls.NETGROUP,
}

try:
return result_map[input]
except KeyError as e:
raise PolkitConfConverterException("Unknown polkit identity type") from e


class PolkitResult(enum.Enum):
YES = enum.auto()
NO = enum.auto()
AUTH_SELF = enum.auto()
AUTH_SELF_KEEP = enum.auto()
AUTH_ADMIN = enum.auto()
AUTH_ADMIN_KEEP = enum.auto()

@classmethod
def parse_polkit_result(
cls, polkit_result: Optional[str]
) -> Optional[PolkitResult]:
if polkit_result is None:
return None

result_map = {
"yes": cls.YES,
"no": cls.NO,
"auth_self": cls.AUTH_SELF,
"auth_self_keep": cls.AUTH_SELF_KEEP,
"auth_admin": cls.AUTH_ADMIN,
"auth_admin_keep": cls.AUTH_ADMIN_KEEP,
}

try:
return result_map[polkit_result]
except KeyError as e:
raise PolkitConfConverterException("Unknown polkit result value") from e

@classmethod
def polkit_result_str(cls, element: PolkitResult) -> Optional[str]:
result_map = {
cls.YES: "polkit.Result.YES",
cls.NO: "polkit.Result.NO",
cls.AUTH_SELF: "polkit.Result.AUTH_SELF",
 

Bug#970715: libucx0: Not installable in unstable

[Alastair McKinstry]

Hi Graham

Thanks.

On 22/09/2020 12:20, Graham Inggs wrote:

Hi Alastair

It seems that packages should statically link libbfd and not use the
shared libbfd.

See the package description of binutils-dev [1]:

Package: binutils-dev (2.35.1-1)
GNU binary utilities (BFD development files)

This package includes header files and static libraries necessary to
build programs which use the GNU BFD library, which is part of
binutils. Note that building Debian packages which depend on the
shared libbfd is Not Allowed.

Regards
Graham


[1] https://packages.debian.org/unstable/binutils-dev


--
Alastair McKinstry, email: alast...@sceal.ie, matrix: @alastair:sceal.ie, 
phone: 087-6847928
Green Party Councillor, Galway County Council

Bug#970720: reprepro: Processing of changes file produced with sbuild's --dpkg-file-suffix fails

[root]

Package: reprepro
Version: 5.3.0-1
Severity: normal

When using sbuild with --dpkg-file-suffix=_buildd, the resulting
changes files is named something like:

  hello_2.10-3_amd64_buildd.changes

It contains a reference to a buildinfo file named:

  hello_2.10-3_amd64_buildd.buildinfo

When trying to process this upload, reprepro chokes on this buildinfo
files, presumably because it parses the architecture as "amd64_buildd":

  'hello_2.10-3_amd64_buildd.changes' contains
  'hello_2.10-3_amd64_buildd.buildinfo' not matching an valid
  architecture in any distribution known!

The scenario at play here is producing binary packages from a
source-only upload: since the latter already contains a buildinfo
file, sbuild introduced --dpkg-file-suffix precisely so there wouldn't
be a conflict (see #869184 for more background information).

Cheers,

--
Seb

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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 reprepro depends on:
ii  libarchive13   3.3.3-4+deb10u1
ii  libbz2-1.0 1.0.6-9.1
ii  libc6  2.28-10
ii  libdb5.3   5.3.28+dfsg1-0.5
ii  libgpg-error0  1.35-1
ii  libgpgme11 1.12.0-6
ii  liblzma5   5.2.4-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages reprepro recommends:
ii  apt  1.8.2

Versions of packages reprepro suggests:
ii  gpg-agent [gnupg-agent]  2.2.12-1+deb10u1
ii  inoticoming  0.2.3-2
pn  lzip 
ii  pinentry-curses  1.1.0-2

-- no debconf information

Bug#970678: Address change due to junk email (Was: Network preseeding using http is broken)

[Martin Samuelsson]

Spammers have harvested the email alias used to report this issue, and 
actively abuse it. As a consequence I'm suspending it. I'm subscribed to the 
bug report using another address.


Follow-up sent to the bug will reach me. For instructions on how to email me 
directly, please follow instructions at https://bugs.debian.org/199392#40 or 
find a disposable contact address on my web page.


Sorry about the noise.
--
/Martin

Bug#905456: Please create new list debian-clojure

[Alexander Wirt]

On Sun, Sep 20, 2020 at 02:38:39PM -0700, Elana Hashman wrote:
> On Thu, Sep 10, 2020 at 09:52:40PM +0200, Alexander Wirt wrote:
> > 
> > Sorry for joining late. Could you please upgrade the list of subscribers
> > and provide me with the archive of the old alioth list?
> 
> No problem. I'm attaching another encrypted dump of the subscriber list.
> 
> The archives are publicly available at
> https://alioth-lists.debian.net/pipermail/pkg-clojure-maintainers/
> 
> I'd just be downloading and attaching the gzips from the link above so
> hopefully this is enough... unfortunately as with most public mailing
> lists the archives are full of spam, not sure if there's any easy way to
> clean that.
ehm, but you asked on the list if subscribers should get subscribed to
the new list? 

Alex

Bug#970478: ERROR: Renderer process crashed when using qtwebengine backend.

[Florian Bruhin]

reassign -1 libqt5webenginecore5 5.14.2+dfsg1-5
thanks

Hey,

Since you can reproduce this with Falkon, it definitely isn't an issue
in qutebrowser. Reassigning this to QtWebEngine. Let's hope it works,
I'm not too experienced with using Debian's BTS - whoever is on the
receiving end, please let me know if I messed up something :)

On Mon, Sep 21, 2020 at 05:57:03PM -0300, felipe wrote:
> Attaching 'coredump info temp-basedir with dbgsym.txt'
> and 'coredump info qt-flag single-process with dbgsym'.

Thanks! For reference, here's a demangled version of the relevant stack
trace:

#0  0x7f6842b6928f 
blink::CompositedLayerMapping::ComputeBoundsOfOwningLayer(blink::PaintLayer 
const*, blink::IntRect&, blink::IntRect&, blink::PhysicalOffset&, 
blink::IntPoint&) (libQt5WebEngineCore.so.5   0x462928f)
#1  0x7f6842b74054 
blink::CompositedLayerMapping::UpdateGraphicsLayerGeometry(blink::PaintLayer 
const*, blink::PaintLayer const*, WTF::Vector&, blink::GraphicsLayerUpdater::UpdateContext&) 
(libQt5WebEngineCore.so.5   0x4634054)
#2  0x7f6842b76561 
blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
blink::GraphicsLayerUpdater::UpdateType, 
blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector&) (libQt5WebEngineCore.so.5   0x4636561)
#3  0x7f6842b764ca 
blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
blink::GraphicsLayerUpdater::UpdateType, 
blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector&) (libQt5WebEngineCore.so.5   0x46364ca)
#4  0x7f6842b764ca 
blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
blink::GraphicsLayerUpdater::UpdateType, 
blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector&) (libQt5WebEngineCore.so.5   0x46364ca)
#5  0x7f6842b764ca 
blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
blink::GraphicsLayerUpdater::UpdateType, 
blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector&) (libQt5WebEngineCore.so.5   0x46364ca)
#6  0x7f6842b764ca 
blink::GraphicsLayerUpdater::UpdateRecursive(blink::PaintLayer&, 
blink::GraphicsLayerUpdater::UpdateType, 
blink::GraphicsLayerUpdater::UpdateContext&, WTF::Vector&) (libQt5WebEngineCore.so.5   0x46364ca)
#7  0x7f6842b766bd 
blink::GraphicsLayerUpdater::Update(blink::PaintLayer&, 
WTF::Vector&) 
(libQt5WebEngineCore.so.5   0x46366bd)
#8  0x7f6842b76b3d 
blink::PaintLayerCompositor::UpdateIfNeeded(blink::DocumentLifecycle::LifecycleState,
 blink::CompositingReasonsStats&) (libQt5WebEngineCore.so.5   0x4636b3d)
#9  0x7f6842b780d0 
blink::PaintLayerCompositor::UpdateIfNeededRecursiveInternal(blink::DocumentLifecycle::LifecycleState,
 blink::CompositingReasonsStats&) (libQt5WebEngineCore.so.5   0x46380d0)
#10 0x7f6842b78409 
blink::PaintLayerCompositor::UpdateIfNeededRecursive(blink::DocumentLifecycle::LifecycleState)
 (libQt5WebEngineCore.so.5   0x4638409)
#11 0x7f6842579377 
blink::LocalFrameView::RunCompositingLifecyclePhase(blink::DocumentLifecycle::LifecycleState)
 (libQt5WebEngineCore.so.5   0x4039377)
#12 0x7f68425839d9 
blink::LocalFrameView::UpdateLifecyclePhasesInternal(blink::DocumentLifecycle::LifecycleState).part.0
 (libQt5WebEngineCore.so.5   0x40439d9)
#13 0x7f6842583e14 
blink::LocalFrameView::UpdateLifecyclePhases(blink::DocumentLifecycle::LifecycleState,
 blink::DocumentLifecycle::LifecycleUpdateReason) (libQt5WebEngineCore.so.5   
0x4043e14)
#14 0x7f6842b11564 
blink::PageAnimator::UpdateAllLifecyclePhases(blink::LocalFrame&, 
blink::DocumentLifecycle::LifecycleUpdateReason) (libQt5WebEngineCore.so.5   
0x45d1564)
#15 0x7f68424cf16c 
blink::WebViewImpl::UpdateLifecycle(blink::WebWidget::LifecycleUpdate, 
blink::WebWidget::LifecycleUpdateReason) (libQt5WebEngineCore.so.5   0x3f8f16c)
#16 0x7f684332cafa content::RenderWidget::UpdateVisualState() 
(libQt5WebEngineCore.so.5   0x4decafa)
#17 0x7f68416a92c6 
cc::ProxyMain::BeginMainFrame(std::unique_ptr >) 
(libQt5WebEngineCore.so.5   0x31692c6)
#18 0x7f68416a1633 
base::internal::Invoker >), 
base::WeakPtr, std::unique_ptr > >, void 
()>::RunOnce(base::internal::BindStateBase*) (libQt5WebEngineCore.so.5   
0x3161633)
#19 0x7f6840b043a4 base::TaskAnnotator::RunTask(char const*, 
base::PendingTask*) (libQt5WebEngineCore.so.5   0x25c43a4)
#20 0x7f6840b17337 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoWorkImpl(base::sequence_manager::LazyNow*,
 bool*) (libQt5WebEngineCore.so.5   0x25d7337)
#21 0x7f6840b177b8 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::DoSomeWork()
 (libQt5WebEngineCore.so.5   0x25d77b8)
#22 0x7f6840acdba6 
base::MessagePumpDefault::Run(base::MessagePump::Delegate*) 
(libQt5WebEngineCore.so.5   0x258dba6)
#23 0x7f6840b14cdf 
base::sequence_manager::internal::ThreadControllerWithMessagePumpImpl::Run(bool,
 base::TimeDelta) (libQt5WebEngineCore.so.5   0x25d4cdf)

Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)

[Tobias Frost]

On Tue, Sep 22, 2020 at 12:51:42PM +0200, Alec Leamas wrote:

> > For later (as this requires a trip though NEW), maybe you want to put
> > the doxygen documentation on a arch:all -doc package?
> 
> 
> Hm... I know I actually considered this. On Fedora, the separate -doc
> package is a nobrainer. However, I have understood that on Debian "too"
> small packages are not really welcome.
> 
> Here, the docs are about 450K in 40 files. Is this enough for a package
> to not be too small? What is really "small" in this context?

Yeah, this is not precisly definded. However for ~1/2MB, I would say it is
worth the trouble. As it can become arch:all, the deduplication is siginifanct.
(See below the "PS" as well.)
> 
> > Only minor changes required ;-) Good job!
> 
> 
> hmpf. Missing the NMU wasn't minor, for sure. "depressed"

/me starts wondering who is the pedantic one here…
OK, you wanted it: *beside that* good job!
(:-D)

> 
> Cannot upload to mentors:
> (...)
> 
> And now, what? "confused"

Probably someone has broken mentors…
Put your changes on your repo, I can pull from there. (in this case
there is no new orig.tar.gz, so the dangers of /me uploading something
wrong is limited)

Or send me a patch against the version I've reviewed… (choices, I know)

> 
> And now, what? "confused"

> 
> Many thanks for reviewing!
> 
> Cheers!
> --alec
> 
> 
> PS: As long as it is possible in any way, I'm avoiding the NEW queue.
> Have been waiting there more than a year... DS

I understand your worries… Some remarks for relief your worries:
- NEW is usually fast for existing source packages only adding/dropping
  packages. (yes, NEW-as-in-ITP sometimes (often) takes i$%§$§%$§ long*…)
- we would utilize the strategy to upload this package to experimental,
  where it would wait to clear NEW. This won't affect unstable and you'd
  be able to upload to unstable without the new binary package without
  problems. Once it has cleared NEW you'd (merge and) upload it to
  unstable


(* Debian is all about "When it's ready.", IOW patience required. Yes, its
  sometimes quite challening, but one mostly has to accept it or look
  how to drive things. With FTP/NEW such a strategy would be becoming
  DD, getting even more involved, joining the FTP masters team…)


signature.asc
Description: PGP signature

Bug#970712: RFS: libcxx-serial/1.2.1-2 [RC] -- Cross-platform, Serial Port library written in C++ (runtime)

[Alec Leamas]

Hi again,

On 22/09/2020 12:51, Alec Leamas wrote:

> Cannot upload to mentors:
> 
> $ dput -f mentors ../libcxx-serial_1.2.1-2_source.changes
> Checking signature on .changes
> gpg: ../libcxx-serial_1.2.1-2_source.changes: Valid signature from
> 0A1DA7134E068B4C
> Checking signature on .dsc
> gpg: ../libcxx-serial_1.2.1-2.dsc: Valid signature from 0A1DA7134E068B4C
> Uploading to mentors (via ftp to mentors.debian.net):
>   Uploading libcxx-serial_1.2.1-2.dsc: 553 Could not create file.
> Leaving existing libcxx-serial_1.2.1-2.dsc on the server and continuing


Some kind of transient error. A new upload is available, timestamp on
mentors: 2020-09-22 11:08  (#4)


Cheers!

--alec

Bug#967854: ITA: gimp-plugin-registry -- repository of optional extensions for GIMP

[Ying-Chun Liu (PaulLiu)]

retitle 967854 ITA: gimp-plugin-registry -- repository of optional
extensions for GIMP
owner 967854 !
thanks

Hi Bernd,

I'll take this package because I still use gimp-mask very often.
I'll prepare a new upload to fix the bugs soon.

Yours,
Paul





signature.asc
Description: OpenPGP digital signature

Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: Bug#970651: rollup: Unable to build with current tsc

[Pirate Praveen]

On Tue, Sep 22, 2020 at 13:21, Xavier  wrote:

Looks good to me too. We could perhaps list the "bigger transitions"
(nodejs, babel, bubble, rollup)


Included a link to that page already :)

Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc

[Xavier]

Le 22/09/2020 à 13:10, Jonas Smedegaard a écrit :
> Quoting Pirate Praveen (2020-09-22 13:03:53)
>>
>>
>> On Mon, Sep 21, 2020 at 11:53, Jonas Smedegaard  wrote:
>>> If you simply mean a loose "don't break reverse dependencies!" and 
>>> write some suggestions down on a wiki page, then I fully agree: That 
>>> is common for Debian in general.  What might be notable about 
>>> node.js is the likelyhood of complying with semantic versioning, and 
>>> it might be helpful to emphasize that in this team.
>>
>> I have started a wiki page by copying from ruby teams policy at 
>> https://wiki.debian.org/Javascript/Transitions/Policy
>>
>> Please go through and suggest if we need to change anything.
>>
>>> If you propose a formal screening process, then I am sceptical both 
>>> how to practically enforce that and whether it is the right 
>>> approach.
>>
>> ok, lets start with documenting our expectation and forget this option 
>> for now. If we see a lot of uploads not following the policy, we can 
>> think about this or other options later.
> 
> Current wiki text looks fine to me.
> 
> Thanks for driving this!
> 
>  - Jonas

Looks good to me too. We could perhaps list the "bigger transitions"
(nodejs, babel, bubble, rollup)

Thanks !

Bug#970715: libucx0: Not installable in unstable

[Graham Inggs]

Hi Alastair

It seems that packages should statically link libbfd and not use the
shared libbfd.

See the package description of binutils-dev [1]:

Package: binutils-dev (2.35.1-1)
GNU binary utilities (BFD development files)

This package includes header files and static libraries necessary to
build programs which use the GNU BFD library, which is part of
binutils. Note that building Debian packages which depend on the
shared libbfd is Not Allowed.

Regards
Graham


[1] https://packages.debian.org/unstable/binutils-dev

Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc

[Jonas Smedegaard]

Quoting Pirate Praveen (2020-09-22 13:03:53)
> 
> 
> On Mon, Sep 21, 2020 at 11:53, Jonas Smedegaard  wrote:
> > If you simply mean a loose "don't break reverse dependencies!" and 
> > write some suggestions down on a wiki page, then I fully agree: That 
> > is common for Debian in general.  What might be notable about 
> > node.js is the likelyhood of complying with semantic versioning, and 
> > it might be helpful to emphasize that in this team.
> 
> I have started a wiki page by copying from ruby teams policy at 
> https://wiki.debian.org/Javascript/Transitions/Policy
> 
> Please go through and suggest if we need to change anything.
> 
> > If you propose a formal screening process, then I am sceptical both 
> > how to practically enforce that and whether it is the right 
> > approach.
> 
> ok, lets start with documenting our expectation and forget this option 
> for now. If we see a lot of uploads not following the policy, we can 
> think about this or other options later.

Current wiki text looks fine to me.

Thanks for driving this!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#970719: aide: dependency problem aide

[Hans-J. Ullrich]

Package: aide
Version: 0.16.1-1+b1
Severity: minor

Dear Maintainer,

I am not quite sure, but please take a look:

When I want to install aide, aptitude is telling, that aide-common is 
suggested. But it also ist telling, that aide-common is dependent to aide. 

This is weired. As aptitude is setting aide-common as dependent to aide, it 
should be installed, when aide is installed, but it is NOT. The package 
aide-common has to be manually installed. 

I do not believe, that this is wanted this way, I more believe, you want both 
packages installed, when the package aide is installed.

Please correct me, if I am wrong.

Thanks for looking at this and best regards

Hans


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

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

aide depends on no packages.

Versions of packages aide recommends:
pn  aide-common  

Versions of packages aide suggests:
pn  figlet  

-- no debconf information

Bug#970718: ITP: nbclient -- Client for Jupyter notebooks

[Gordon Ball]

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

* Package name: nbclient
  Version : 0.5.0
  Upstream Author : Jupyter contributors
* URL : https://github.com/jupyter/nbclient
* License : BSD-3-clause
  Programming Lang: Python
  Description : Client for Jupyter notebooks

Library for executing code embedded in Jupyter notebook files. This
functionality was previously included as ExecutePreprocessor in
the nbconvert library.

This is a required dependency to update nbconvert 5 -> 6

It will be maintained under the Debian Python Team.

Bug#970651: [Pkg-javascript-devel] Bug#970651: Bug#970651: rollup: Unable to build with current tsc

[Pirate Praveen]

On Mon, Sep 21, 2020 at 11:53, Jonas Smedegaard  wrote:

Quoting Pirate Praveen (2020-09-21 09:15:46)
If you simply mean a loose "don't break reverse dependencies!" and 
write
some suggestions down on a wiki page, then I fully agree: That is 
common

for Debian in general.  What might be notable about node.js is the
likelyhood of complying with semantic versioning, and it might be
helpful to emphasize that in this team.


I have started a wiki page by copying from ruby teams policy at
https://wiki.debian.org/Javascript/Transitions/Policy

Please go through and suggest if we need to change anything.

If you propose a formal screening process, then I am sceptical both 
how

to practically enforce that and whether it is the right approach.


ok, lets start with documenting our expectation and forget this option 
for now. If we see a lot of uploads not following the policy, we can 
think about this or other options later.