Bug#979312: Re: Bug#979312: vokoscreen-ng: Segmentation fault when screenAdded

[handsome_feng]

reassign 979312 deepin-qt5dxcb-plugin 5.0.17-1
thanksSorry, wrong package name.

Bug#979312: Re: Bug#979312: vokoscreen-ng: Segmentation fault when screenAdded

[handsome_feng]

reassign 979312 qt5dxcb-plugin 5.0.17-1
thanks


Hi, I found it works fine after removing the qt5dxcb-plugin, so I reassign this 
to it.
and the bt also shows it caused by deepin_platform_plugin:
(gdb) bt
#0  0x76e604e0 in QGuiApplication::screenAdded(QScreen*) () at 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#1  0x76e4646c in 
QWindowSystemInterface::handleScreenAdded(QPlatformScreen*, bool) ()
at /lib/x86_64-linux-gnu/libQt5Gui.so.5
#2  0x71ee2e00 in QXcbConnection::initializeScreens() () at 
/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#3  0x71ebe390 in QXcbConnection::QXcbConnection(QXcbNativeInterface*, 
bool, unsigned int, char const*) ()
at /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x71ec1113 in QXcbIntegration::QXcbIntegration(QStringList const&, 
int&, char**) ()
at /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#5  0x7201eaf0 in 
deepin_platform_plugin::DPlatformIntegration::DPlatformIntegration(QStringList 
const&, int&, char**) () at 
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libdxcb.so
#6  0x7201e24c in DPlatformIntegrationPlugin::create(QString const&, 
QStringList const&, int&, char**) ()
at /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libdxcb.so
#7  0x76e648cc in QGuiApplicationPrivate::createPlatformIntegration() ()
at /lib/x86_64-linux-gnu/libQt5Gui.so.5
#8  0x76e65d20 in QGuiApplicationPrivate::createEventDispatcher() () at 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#9  0x769149b6 in QCoreApplicationPrivate::init() () at 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x76e68c6f in QGuiApplicationPrivate::init() () at 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#11 0x77669ef9 in QApplicationPrivate::init() () at 
/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#12 0x55577b84 in main(int, char**) (argc=, 
argv=) at main.cpp:36


regards,
handsome_feng

Bug#970736: Patch available

[Jouni K Seppänen]

Control: tag -1 + patch

Patch at https://lore.kernel.org/linux-usb/20210105045249.5590-1-...@iki.fi/

Bug#979397: transition: ntfs-3g

[GCS]

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

Hi RMs,

Only three packages are affected: partclone, testdisk and wimlib. Test
rebuilds are fine on amd64 but as freeze is around the corner I can
test it on more architectures if needed.
The main note that it has an udeb so probably KiBi also would like to
ACK / NACK this transition.

Regards,
Laszlo/GCS

Bug#979312: vokoscreen-ng: Segmentation fault when screenAdded

[Thiago Andrade]

Hi handsome_feng,

I did some tests on vokoscreen-ng and on a clean installation of debian 
sid the package worked perfectly.

When did you specifically observe this segmantation fault?
Could you give some more details so that I can reproduce the error?

Regards

===
$ vokoscreenNG
[vokoscreenNG] Version: 3.0.7
[vokoscreenNG] Locale: pt_BR
[vokoscreenNG] Log from: 2021-01-06 03:00:48
[vokoscreenNG] Country: Brazil
[vokoscreenNG] Qt: 5.15.2
[vokoscreenNG] GStreamer 1.18.2
[vokoscreenNG] Operating system: Debian GNU/Linux bullseye/sid
[vokoscreenNG] CPU Architecture: x86_64
[vokoscreenNG] vokoscreenNG running as: xcb client
[vokoscreenNG] vokoscreenNG running on: x11
[vokoscreenNG] Desktop: MATE
[vokoscreenNG] Icon-Theme: menta
[vokoscreenNG] Styles: (Windows, Fusion)
[vokoscreenNG] Qt-PluginsPath: /usr/lib/x86_64-linux-gnu/qt5/plugins
[vokoscreenNG] Qt-TranslationsPath: /usr/share/qt5/translations
[vokoscreenNG] Qt-LibraryPath:  /usr/lib/x86_64-linux-gnu
[vokoscreenNG] Settings: /home/usuario/.config/vokoscreenNG/vokoscreenNG.ini
[vokoscreenNG] Log: 
/home/usuario/.config/vokoscreenNG/log/2021_01_06_03_00_48.log

[vokoscreenNG] Default Videopath: /home/usuario/Vídeos
[vokoscreenNG] User Videopath: /home/usuario/Vídeos
[vokoscreenNG] CompositingManager running: true

[vokoscreenNG] [Audio] Found: Monitor of Áudio interno Estéreo analógico 
Device: alsa_output.pci-_00_1b.0.analog-stereo.monitor
[vokoscreenNG] [Audio] Found: Áudio interno Estéreo analógico Device: 
alsa_input.pci-_00_1b.0.analog-stereo


[vokoscreenNG] Symbols: + available, - not available
[vokoscreenNG] + matroskamux
[vokoscreenNG] + webmmux
[vokoscreenNG] + avimux
[vokoscreenNG] + mp4mux
[vokoscreenNG] + qtmux
[vokoscreenNG] + x264enc
[vokoscreenNG] - openh264enc
[vokoscreenNG] - vaapih264enc
[vokoscreenNG] - vaapimpeg2enc
[vokoscreenNG] + vp8enc
[vokoscreenNG] + vorbisenc
[vokoscreenNG] + flacenc
[vokoscreenNG] + opusenc
[vokoscreenNG] + lamemp3enc
[vokoscreenNG] + voaacenc

[vokoscreenNG] + ximagesrc
[vokoscreenNG] + pulsesrc
[vokoscreenNG] - pipewiresrc
[vokoscreenNG] + queue
[vokoscreenNG] + capsfilter
[vokoscreenNG] + videoconvert
[vokoscreenNG] + videorate
[vokoscreenNG] + audioconvert
[vokoscreenNG] + audiorate
[vokoscreenNG] + filesink
[vokoscreenNG] + videoscale
[vokoscreenNG] + h264parse
[vokoscreenNG] + audiomixer
[vokoscreenNG] + adder

[vokoscreenNG] Name from screen:  Virtual-1
[vokoscreenNG] Screen available desktop width : 1024
[vokoscreenNG] Screen available desktop height: 768
[vokoscreenNG] DevicePixelRatio: 1  (Normal displays is 1, Retina 
display is 2)

[vokoscreenNG] Vertical refresh rate of the screen in Hz: 60.0038
[vokoscreenNG] Screen orientation Qt::LandscapeOrientation
[vokoscreenNG] Color depth of the screen:  24
[vokoscreenNG] Model from screen:
[vokoscreenNG] Manufactur from screen:
[vokoscreenNG] SerialNumber from screen:
[vokoscreenNG] ItemText in Combobox: Virtual-1 :  1024 x 768
[vokoscreenNG] ItemData in Combobox: x=0 y=0 with=1024 height=768

[vokoscreenNG] Desktop session is a X11 session


On 05/01/2021 05:22, handsome_feng wrote:

Package: vokoscreen-ng
Version: 3.0.7-1
Severity: grave
Justification: renders package unusable
X-Debbugs-Cc: jianfen...@ubuntukylin.com

Dear Maintainer,

When I run vocoscreenNG in debian sid, I got a segmentation fault:

$ vokoscreenNG
[vokoscreenNG] Version: 3.0.7
[vokoscreenNG] Locale: en_US
[vokoscreenNG] Log from: 2021-01-05 08:13:52
[vokoscreenNG] Country: United States
[vokoscreenNG] Qt: 5.15.2
[vokoscreenNG] GStreamer 1.18.2
[vokoscreenNG] Operating system: Debian GNU/Linux bullseye/sid
[vokoscreenNG] CPU Architecture: x86_64
[vokoscreenNG] vokoscreenNG running as: xcb client
[vokoscreenNG] vokoscreenNG running on: x11
[vokoscreenNG] Desktop: UKUI
[vokoscreenNG] Icon-Theme: ukui-icon-theme-default
[vokoscreenNG] Styles: (Breeze, chameleon, ukui-dark, ukui-light, ukui-default,
ukui, Oxygen, Windows, Fusion)
[vokoscreenNG] Qt-PluginsPath:  /usr/lib/x86_64-linux-gnu/qt5/plugins
[vokoscreenNG] Qt-TranslationsPath: /usr/share/qt5/translations
[vokoscreenNG] Qt-LibraryPath:  /usr/lib/x86_64-linux-gnu
[vokoscreenNG] Settings: /home/feng/.config/vokoscreenNG/vokoscreenNG.ini
[vokoscreenNG] Log: /home/feng/.config/vokoscreenNG/log/2021_01_05_08_13_52.log
[vokoscreenNG] Default Videopath: /home/feng/Videos
[vokoscreenNG] User Videopath:
[vokoscreenNG] CompositingManager running: true

[vokoscreenNG] [Audio] Found: Monitor of Built-in Audio Analog Stereo Device:
alsa_output.pci-_00_1b.0.analog-stereo.monitor
[vokoscreenNG] [Audio] Found: Built-in Audio Analog Stereo Device:
alsa_input.pci-_00_1b.0.analog-stereo

[vokoscreenNG] Symbols: + available, - not available
[vokoscreenNG] + matroskamux
[vokoscreenNG] + webmmux
[vokoscreenNG] + avimux
[vokoscreenNG] + mp4mux
[vokoscreenNG] + qtmux
[vokoscreenNG] - x264enc
[vokoscreenNG] - openh264enc
[vokoscreenNG] - vaapih26

Bug#979396: mypaint: #954142 again?

[YABUKI Yukiharu]

Package: mypaint
Version: 2.0.1-2
Severity: important

Dear Maintainer,

We upgraded python 3.9.1. This bug seems to me that #954142 back again.

mypaint shows me:

```
$ mypaint
INFO: mypaint: Installation layout: conventional POSIX-like structure with 
prefix '/usr'
Traceback (most recent call last):
  File "/usr/bin/mypaint", line 293, in 
= get_paths()
  File "/usr/bin/mypaint", line 241, in get_paths
from lib import fileutils
  File "/usr/lib/mypaint/lib/fileutils.py", line 25, in 
import lib.helpers
  File "/usr/lib/mypaint/lib/helpers.py", line 25, in 
from . import mypaintlib
  File "/usr/lib/mypaint/lib/mypaintlib.py", line 13, in 
from . import _mypaintlib
ImportError: /usr/lib/mypaint/lib/_mypaintlib.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: mypaint_brush_stroke_to_2_linearsRGB
```

And does not work.

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

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

Versions of packages mypaint depends on:
ii  gir1.2-gtk-3.0   3.24.24-1
ii  libc62.31-7
ii  libgcc-s110.2.1-3
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgomp1 10.2.1-3
ii  liblcms2-2   2.9-4+b1
ii  libmypaint-1.5-1 1:1.5.1-dmo2
ii  libpng16-16  1.6.37-3
ii  librsvg2-bin 2.50.2+dfsg-1
ii  libstdc++6   10.2.1-3
ii  mypaint-brushes  2.0.2+ds1-1
ii  mypaint-data 2.0.1-2
ii  python3  3.9.1-1
ii  python3-distutils3.9.1-2
ii  python3-gi   3.38.0-1+b2
ii  python3-gi-cairo 3.38.0-1+b2
ii  python3-numpy1:1.19.4-1+b1

Versions of packages mypaint recommends:
ii  mypaint-data-extras  2.0.1-2
ii  shared-mime-info 2.0-1

mypaint suggests no packages.

-- no debconf information

Bug#979386: debian-installer: Install Annoyance

[David]

On Wed, 6 Jan 2021 at 11:42, Mike McCulley  wrote:

> Debian installer displays messages about the necessity of having GRUB
> installed, which implies it's possible to not install GRUB, but that option is
> not available. After installing Debian it's necessary to boot the primary OS
> and reinstall the custom GRUB. Life would be better if there was an option to
> skip the 'install GRUB' step.

> Debian installer formats swap, which changes the UUID, and not formatting is
> not an option. After installing Debian it's necessary to edit any other fstabs
> and update the swap UUIDs. Life would be better if there was an option to not
> format swap.

Hi Mike, I am not the maintainer but have a couple of suggestions from the side
lines which your message does not indicate that you are aware of.

I wonder if you have tried either 'priority=medium' or 'priority=low'
as mentioned
on this page:
https://www.debian.org/releases/buster/amd64/ch06s01.en.html

and with more info here:
https://www.debian.org/releases/buster/amd64/ch05s03.en.html#installer-args

Using that provides more control over the installation process. If I
recall correctly the
installer menu allows to skip any major step, including installing a bootloader.

Regarding the swap annoyance, an easier workaround might be to install
without swap
and later use the 'mkswap' command (or edit /etc/fstab) after you boot into the
new system to specify the same swap area that is already used by other systems.

Bug#979395: vim-scripts: README.Debian still recommends nonfunctional vim-addon-manager

[Christoph Anton Mitterer]

Package: vim-scripts
Version: 20201113
Severity: normal



Hi.

README.Debian still recommends to use vim-addon-manager which seems to be
no longer supported by vim-scripts as noted in the NEWS.Debian.


Cheers,
Chris.

Bug#977652: Fix in golang-goprotobuf 1.3.4

[El boulangero]

> if I just disable code regeneration, the diff with 1.3.4-2 is really
minor.

Answering to myself, so I looked at that again, and the diff is not that
small. It's true that the only file impacted is plugin.pb.go (which is the
file that needs a fix), but the diff is not exactly minor.

Main differences:

-const _ = proto.ProtoPackageIsVersion3
+const _ = proto.ProtoPackageIsVersion2

-func (m *CodeGeneratorResponse_File) XXX_Unmarshal(b []byte) error {
+func (m *CodeGeneratorResponse_File) Unmarshal(b []byte) error {

-func (m *CodeGeneratorResponse_File) XXX_Marshal(b []byte, deterministic
bool) ([]byte, error) {
+func (m *CodeGeneratorResponse_File) Marshal(b []byte, deterministic bool)
([]byte, error) {

I really have no idea if these changes are significant.

On Wed, Jan 6, 2021 at 11:45 AM El boulangero 
wrote:

> It can be fixed with regeneration, in an ugly way. I patch the generated
> file after it's been generated, I didn't find a better solution... It could
> be a bug upstream. However upstream did a major code refactoring to go to
> version 1.4, so there's no fix that can be cherry-picked from their git
> history.
>
> But that's not the point. My concern is that if I rebuild the package with
> code regeneration, the diff with the current package "golang-goprotobuf-dev
> 1.3.4-2" is much bigger, and I'm afraid that it breaks things. On the other
> hand, if I just disable code regeneration, the diff with 1.3.4-2 is really
> minor.
>
> So I thought that, given the timeline, it was better to make as little
> change as possible to this package.
>
> On Wed, Jan 6, 2021 at 11:32 AM Shengjing Zhu  wrote:
>
>> On Wed, Jan 06, 2021 at 10:16:16AM +0700, El boulangero wrote:
>> > Hello Go Team,
>> >
>> > in order to solve #977652, I would need to modify & rebuild the package
>> > golang-goprotobuf.
>> >
>> > The issue is that this package has many reverse build deps, as you might
>> > know already:
>> >
>> > $ build-rdeps golang-goprotobuf-dev
>> > ...
>> > Found a total of 218 reverse build-depend(s) for
>> golang-goprotobuf-dev.
>> >
>> > I did some work already, and it seems that the least invasive way to fix
>> > #977652 is simply to disable code regeneration and rebuild
>> > golang-goprotobuf. The diff in the binary package golang-goprotobuf-dev
>> > will then be very minor. I can post a diff if anyone is interested.
>> >
>> > My question is: is it OK to update this package now, or is it too risky,
>> > and should I wait for after the freeze then?
>>
>> I think minor fix is ok. But OTOH I think we want to keep regenerating
>> files.
>> Can it be fixed with regeneration?
>>
>>

Bug#979394: RFS: dhcpcd-ui/0.7.5-1 [QA] -- Common files for dhcpcd frontends

[Leandro Cunha]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "dhcpcd-ui":

 * Package name: dhcpcd-ui
   Version : 0.7.5-1
   Upstream Author : Roy Marples 
 * URL : https://roy.marples.name/projects/dhcpcd-ui
 * License : BSD-2
 * Vcs : [fill in URL of packaging vcs]
   Section : net

It builds those binary packages:

  dhcpcd-common - Common files for dhcpcd frontends
  dhcpcd-gtk - GTK+ frontend for dhcpcd and wpa_supplicant

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

  https://mentors.debian.net/package/dhcpcd-ui/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dhcpcd-ui/dhcpcd-ui_0.7.5-1.dsc

Changes since the last upload:

 dhcpcd-ui (0.7.5-1) unstable; urgency=medium
 .
   * QA upload.
   * New upstream release.
   * Added debian/gbp.conf.
   * Deleted debian/compat.
   * Added debian/upstream/metadata.
   * Added d/dhpcd-common.install and d/dhcpcd-gtk.install to split each binary
 into its own package.
   * Fixes mostly unusable as some icons are missing. (Closes: #952394)
   * debian/control:
 - Set Debian QA Group as maintainer. (See #770081)
 - Bumped Standards-Version to 4.5.1.
 - Updated debhelper to debhelper-compat to version 13.
 - Updated homepage field.
 - Added 'Rules-Requires-Root: no' to source stanza.
 - Added dhcpcd-common binary for commons files between gtk.
   * debian/watch:
 - Bumped version of 3 to 4.
 - Updated URL to a secure link, reported by Lintian.
   * debian/copyright:
 - Updated year upstream author.
 - Updated source field.
 - Updated file following DEP-5.
 - Added files debian/* and people involved with year of contribution.
 - Added myself.
   * debian/rules:
 - Use debhelper's dpkg-buildflags support to picking up hardening flags.

Regards,
-- 
Leandro Cunha

Bug#978107: [Pkg-xmpp-devel] Bug#978107: Bug#978107: gajim: Crashes when video preview is turned off in settings dialog window

[Bruno Kleinert]

Am Dienstag, dem 05.01.2021 um 23:47 +0300 schrieb Boris Pek:
> Hi,
> 
> > > Too bad. Still no problem for me.
> 
> I cannot reproduce this problem in my system in KDE and Fluxbox too.
> 
> But I have much more packages installed into the system than basic system +
> gajim* packages + recommendations. And unfortunately I do not have enough free
> space for one more guest environment in VirtualBox for tests...
> 
> Martin, could you try to reproduce this bug in a clean environment?
> 
> > I can reproduce in a virtual machine without any camera running sid also on
> > amd64. I used GNOME Boxes with QEMU on KVM, emulating a QXL video card.
> 
> Do you use GNOME Shell launched above Wayland or X11 in your main system?
> 
> If you use Wayland than could you test the X11 session please? It should not
> take too much time...
> 
> Best wishes,
> Boris
> 

Hi Boris,

I used the same virtual machine, i.e., GNOME Boxes on QEMU/KVM with QXL
video emulation, etc., to log into a GNOME 3 session on X11. Indeed,
there it doesn't crash.

Cheers,
Bruno


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

Bug#977652: Fix in golang-goprotobuf 1.3.4

[El boulangero]

It can be fixed with regeneration, in an ugly way. I patch the generated
file after it's been generated, I didn't find a better solution... It could
be a bug upstream. However upstream did a major code refactoring to go to
version 1.4, so there's no fix that can be cherry-picked from their git
history.

But that's not the point. My concern is that if I rebuild the package with
code regeneration, the diff with the current package "golang-goprotobuf-dev
1.3.4-2" is much bigger, and I'm afraid that it breaks things. On the other
hand, if I just disable code regeneration, the diff with 1.3.4-2 is really
minor.

So I thought that, given the timeline, it was better to make as little
change as possible to this package.

On Wed, Jan 6, 2021 at 11:32 AM Shengjing Zhu  wrote:

> On Wed, Jan 06, 2021 at 10:16:16AM +0700, El boulangero wrote:
> > Hello Go Team,
> >
> > in order to solve #977652, I would need to modify & rebuild the package
> > golang-goprotobuf.
> >
> > The issue is that this package has many reverse build deps, as you might
> > know already:
> >
> > $ build-rdeps golang-goprotobuf-dev
> > ...
> > Found a total of 218 reverse build-depend(s) for
> golang-goprotobuf-dev.
> >
> > I did some work already, and it seems that the least invasive way to fix
> > #977652 is simply to disable code regeneration and rebuild
> > golang-goprotobuf. The diff in the binary package golang-goprotobuf-dev
> > will then be very minor. I can post a diff if anyone is interested.
> >
> > My question is: is it OK to update this package now, or is it too risky,
> > and should I wait for after the freeze then?
>
> I think minor fix is ok. But OTOH I think we want to keep regenerating
> files.
> Can it be fixed with regeneration?
>
>

Bug#977652: Fix in golang-goprotobuf 1.3.4

[Shengjing Zhu]

On Wed, Jan 06, 2021 at 10:16:16AM +0700, El boulangero wrote:
> Hello Go Team,
> 
> in order to solve #977652, I would need to modify & rebuild the package
> golang-goprotobuf.
> 
> The issue is that this package has many reverse build deps, as you might
> know already:
> 
> $ build-rdeps golang-goprotobuf-dev
> ...
> Found a total of 218 reverse build-depend(s) for golang-goprotobuf-dev.
> 
> I did some work already, and it seems that the least invasive way to fix
> #977652 is simply to disable code regeneration and rebuild
> golang-goprotobuf. The diff in the binary package golang-goprotobuf-dev
> will then be very minor. I can post a diff if anyone is interested.
> 
> My question is: is it OK to update this package now, or is it too risky,
> and should I wait for after the freeze then?

I think minor fix is ok. But OTOH I think we want to keep regenerating files.
Can it be fixed with regeneration?

Bug#979393: RFS: filezilla/3.52.0.1-1 [Team] -- Full-featured graphical FTP/FTPS/SFTP client

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: filezilla
   Version : 3.52.0.1-1
   Upstream Author : Tim Kosse 
 * URL : https://filezilla-project.org/
 * License : MIT, BSD-like, permissive, GPL-2+, CC0-1.0
 * Vcs : https://salsa.debian.org/debian/filezilla
   Section : net

It builds those binary packages:

  filezilla-common - Architecture independent files for filezilla
  filezilla - Full-featured graphical FTP/FTPS/SFTP client

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/filezilla/filezilla_3.52.0.1-1.dsc

Changes since the last upload:

 filezilla (3.52.0.1-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 3.52.0.1
   * Updated libfilezilla-dev versioned build-dep to 0.26.0
   * Update 'Standards-Version' to 4.5.1 - No changes required.

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#979392: RFS: libfilezilla/0.26.0-1 [Team] -- build high-performing platform-independent programs (runtime lib)

[Philip Wyett]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libfilezilla
   Version : 0.26.0-1
   Upstream Author : Tim Kosse 
 * URL : https://lib.filezilla-project.org/
 * License : GPL-2+
 * Vcs : https://salsa.debian.org/debian/libfilezilla
   Section : libs

It builds those binary packages:

  libfilezilla0 - build high-performing platform-independent programs
(runtime lib)
  libfilezilla-dev - build high-performing platform-independent
programs (development)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libf/libfilezilla/libfilezilla_0.26.0-1.dsc

Changes since the last upload:

 libfilezilla (0.26.0-1) unstable; urgency=medium
 .
   * Team upload
   * New upstream version 0.26.0

Regards

Phil

-- 
*** Playing the game for the games own sake. ***

WWW: https://kathenas.org

Twitter: @kathenasorg

IRC: kathenas

GPG: 724AA9B52F024C8B


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

Bug#979191: Missing dependency for nautilus-nextcloud

[tankboy]

Hi hefee,

I found my mistake. The nextcloud desktop client was not running the
fist time I tried the extension. So I probably started it to check the
connection with the server, then I closed the window and didn't noticed
that the process was still running in background (there's no more
systray in gnome-shell).

Sorry about that.

Cheers

> Control: tags -1 +moreinfo
> 
> Hey,
> 
> > I feel like the package 'nautilus-nextcloud' should have a
> > dependency
> > on 'nextcloud-desktop-cmd'.
> > 
> > If I install only the package 'nautilus-nextcloud' it also install
> > 'nextcloud-desktop' as a dependency, so I can setup an account an
> > sync
> > files but I have none of the features that it should bring to
> > nautilus
> > event though the extension seems to be loaded without errors:
> > 
> > $ nautilus
> > Initializing Nextcloud-client-nautilus extension
> > ...
> > 
> > If I manually install 'nextcloud-desktop-cmd' then everything seems
> > to
> > work as expected.
> 
> This is interessting and strange.  'nextcloud-desktop-cmd' only
> install usr/
> bin/nextcloudcmd and that is not used by the nautilus extension. The
> extension 
> is using a socket to reach Nextcloud get the status:
> $XDG_RUNTIME_DIR/Nextcloud/socket
> and this socket is provided by nextcloud-desktop:
> lsof | grep  $XDG_RUNTIME_DIR/Nextcloud/socket
> 
> That's why expect that 'nextcloud-desktop-cmd' depends on something,
> that is 
> missing is your case. Please try to remove nextcloud-desktop-cmd than
> the 
> extension should still working and apt should list some packages,
> that are not 
> needed anymore, those are the candidates of the missing dependency.
> Can you 
> give me the list of those packages?
> 
> hefee

Bug#979391: ITP: golang-github-facebook-ent -- entity framework for Go

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-facebook-ent
  Version : 0.5.3-1
  Upstream Author : Facebook
* URL : https://github.com/facebook/ent
* License : Apache-2.0
  Programming Lang: Go
  Description : entity framework for Go

 The ent package is a simple, yet powerful entity framework for Go,
 that makes it easy to build and maintain applications with large
 data-models.
 .
 Highlights include:
  - Schema As Code - model any database schema as Go objects.
  - Easily Traverse Any Graph - run queries, aggregations and traverse
any graph structure easily.
  - Statically Typed And Explicit API - 100% statically typed and
explicit API using code generation.
  - Multi Storage Driver - supports MySQL, PostgreSQL, SQLite and
Gremlin.
  - Extendable - simple to extend and customize using Go templates.


The initial packaging will provide only the library, stripping various
components like command-line tools, examples, and internal components.
If any of those might be useful to others, feel free to request
another binary (and please detail which tools it should contain).


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


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


signature.asc
Description: PGP signature

Bug#979390: RM: golang-gosqlite-dev -- RoQA; Unmaintained; Upstream Dead; Blocking sqlite2 removal

[Boyuan Yang]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-CC: jonathan.d...@gmail.com

Dear FTP Masters,

As discussed in https://bugs.debian.org/978077 and
https://bugs.debian.org/607969 , package golang-gosqlite-dev (
https://tracker.debian.org/pkg/golang-gosqlite-dev ) was not maintained
since 2013 and is now blocking the long overdue removal of src:sqlite
(the old sqlite 2.x). The package maintainer also did not respond to
the package removal request. As a result, please remove this package
from Debian Sid.

Thanks,
Boyuan Yang


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

Bug#979389: ITP: golang-github-go-openapi-inflect -- golang library providing functions applying grammar rules to English words

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-go-openapi-inflect
  Version : 0.19.0-1
  Upstream Author : OpenAPI Initiative golang toolkit
* URL : https://github.com/go-openapi/inflect
* License : Expat
  Programming Lang: Go
  Description : golang library providing functions applying grammar rules 
to English words

 This golang library provides a basic set of functions applying
 grammar rules to inflect English words, and to modify case style
 (Capitalize, camelCase, snake_case, etc.). Acronyms are properly
 managed. A common use case is word pluralization.


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


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


signature.asc
Description: PGP signature

Bug#895903: [torsocks] AAAA replies from Tor not handled

[Łukasz Stelmach]

On Tue, 17 Apr 2018 13:55:43 +0100 Kevin Steen  wrote:
>
> Tor now returns IPv6 addresses when hostnames are resolved, but
> torsocks cannot handle this case.
>
> To reproduce:
>  torsocks -d nc ipv6.test-ipv6.com 80
>

Without torsocks nc(1) can't perform this request too.

$ nc ipv6.test-ipv6.com 80
ipv6.test-ipv6.com: forward host lookup failed: Unknown host
$ host ipv6.test-ipv6.com
ipv6.test-ipv6.com has IPv6 address 2001:470:1:18::115

This is because nc appears to be using gethostbyname()

1609896026 DEBUG torsocks[27929]: [gethostbyname] Requesting ipv6.test-ipv6.com 
hostname (in tsocks_gethostbyname() at gethostbyname.c:68)

which can't handle  records.

There is getaddrinfo(3) which is implemented in torsocks. Unfortunately
AF_INET6 appears not to be supported yet. If you look at
tsocks_tor_resolve() in src/lib/torsocks.c, you will find a stub [1].

[1] 
https://github.com/dgoulet/torsocks/blob/d4b0a84bdf2a1895c8ec3091dc2767fd9f8c2d66/src/lib/torsocks.c#L527
-- 
Kind regards,
Łukasz Stelmach


signature.asc
Description: PGP signature

Bug#979386: debian-installer: Install Annoyance

[Mike McCulley]

Package: debian-installer
Version: buster
Severity: normal

Dear Maintainer,

I have a triple-boot setup so GRUB and swap both exist, and that creates the
annoyance.

Debian installer displays messages about the necessity of having GRUB
installed, which implies it's possible to not install GRUB, but that option is
not available. After installing Debian it's necessary to boot the primary OS
and reinstall the custom GRUB. Life would be better if there was an option to
skip the 'install GRUB' step.

Debian installer formats swap, which changes the UUID, and not formatting is
not an option. After installing Debian it's necessary to edit any other fstabs
and update the swap UUIDs. Life would be better if there was an option to not
format swap.



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

Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores)
Locale: LANG=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

Bug#979341: transition: gpsd

[Sebastian Ramacher]

Control: forwarded -1 https://release.debian.org/transitions/html/auto-gpsd.html
Control: tags -1 + confirmed

On 2021-01-05 16:15:57 +0100, Bernd Zeimetz wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hi release team,
> 
> 
> just in time gpsd upstream pushed the first release candidate of 3.22,
> which is due to be released within the next few days.
> 
> As usual its comes with a soname bump and a small api change, so I've
> uploaded -rc1 to experimental, ready to upload to unstable.
> 
> Only one build-rdep fails to build against it (foxtrotgps, fix in
> progress, #979252), as you can see here.
> 
> https://salsa.debian.org/debian-gps-team/pkg-gpsd/-/pipelines/215214
> 
> Please ack the start of the transition.

Please go ahead.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#979320: transition: xmltooling

[Sebastian Ramacher]

Control: tags -1 + confirmed

On 2021-01-05 10:47:56 +0100, Ferenc Wágner wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear Release Team,
> 
> The recent 3.2 release of the Shibboleth SP is a minor release, but due
> to the internal structure of the stack it entails the usual three
> transitions for xmltooling, opensaml and shibboleth-sp.  I'd like to do
> successive sourceful uploads for these (the updated packages are already
> in experimental).  The two other impacted packages build fine without any
> change: shibboleth-resolver and moonshot-gss-eap.  The auto-{xmltooling,
> opensaml,shibboleth-sp} trackers are good.  I'm ready to upload to
> unstable on your word.

Please go ahead
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#906918: fixed upstream

[McIntyre, Vincent (CASS, Marsfield)]

I think these issues should be fixed by upstream now

https://github.com/karelzak/util-linux/commit/4b447adf50c61125c57922cc01ec3e6792cc48af#diff-ebbebd514b5c6a5308506642a9de143627256373989a032476e00fb44ec2a27a

-- 

Bug#979385: adduser: Incorrect documentation about default for usergroups/setgid_home

[Andreas Henriksson]

Package: adduser
Version: 3.118
Severity: normal

Dear Maintainer,

The adduser(8) manual page says this:

The home directory's set-group-ID bit is set if USERGROUPS is
yes so that any files created in the user's home directory
will have the correct group.

This is not true (any more)!

Possibly useful info is found in the comments of SETGID_HOME in
/etc/adduser.conf :

# If SETGID_HOME is "yes" home directories for users with their own
# group the setgid bit will be set. This was the default for
# versions << 3.13 of adduser. Because it has some bad side effects we
# no longer do this per default. If you want it nevertheless you can
# still set it here.
SETGID_HOME=no

Please drop the outdated documentation about setgid home directories
from the manual page.

Regards,
Andreas Henriksson

Bug#968518: clevis: "clevis decrypt" does not work in initrd

[Christoph Biedl]

Marek Rusinowski wrote...

> The upstream.work-around-missing-dev-fd-links.patch doesn't
> work for the tpm2 pin yet.
(...)

In case you haven't noticed yet, that was fixed in clevis 15-3 a few
days ago. There's alreaddy 15-4 which should reach testing in two days.

Christoph


signature.asc
Description: PGP signature

Bug#979384: torsocks: accept() and listen() don't work for AF_INET6 even on localhost

[Łukasz Stelmach]

Package: torsocks
Version: 2.3.0-2
Severity: normal
Control: forwarded -1 https://github.com/dgoulet/torsocks/pull/38
Control: tags -1 + patch

Dear Maintainer,

I was trying to forward a local TCP to a remote machine over a torified
ssh connection but I received the following messages

listen: Operation not permitted
listen [::1]:6331: Operation not permitted

There is a problem in the libtorsocks implementation of listen(),
accept() and accept4() functions. They use struct sockaddr to store
results of getsockname(2), but the structure is too small for IPv6
addresses and utils_sockaddr_is_localhost() is never true for AF_INET6
sockets.

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

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

Versions of packages torsocks depends on:
ii  libc6  2.28-10

Versions of packages torsocks recommends:
ii  tor  0.3.5.12-1

torsocks suggests no packages.

-- no debconf information

-- 
Miłego dnia,
Łukasz Stelmach


signature.asc
Description: PGP signature

Bug#979369: libsdl2 FTBFS with DEB_BUILD_OPTIONS=nocheck

[Simon McVittie]

Control: tags -1 + pending

On Tue, 05 Jan 2021 at 19:23:11 +0100, Helmut Grohne wrote:
> Please consider applying the attached patch.

Thanks, pushed to the experimental branch. I'm preparing a new upstream
release there, but the commits can easily be cherry-picked for unstable
if the new upstream release turns out not to be usable yet.

smcv

Bug#979367: kodi: segfault when shutting down

[Vasyl Gello]

Control: forwarded -1 https://github.com/xbmc/xbmc/issues/19027

Hi Sebastian!

I could not reproduce the crash on my Debian bullseye VM.
However I upstreamed the bug because,I think there might be null checks missing 
in place (see upstream report).

Another thing that bothers me is that you mix dmo and official Debian 
repository.

Can you please backup your Kodi profile and reinstall Kodi with only 
dependencies from official Debian archive?
This incompatibility might be or not be our root cause but it's still worth 
checking.

If you need packages not yet in Debian archive for tests, please let me know so 
I build the required packages against testing/amd64
and push them to a temporary Github repo.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#979281: pulseaudio should reduce unnecessary Build-Depends

[Felipe Sateler]

Control: tags -1 pending

On Mon, Jan 4, 2021 at 7:12 PM Helmut Grohne  wrote:

> Source: pulseaudio
> Version: 13.0-5
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> pulseaudio is involved in a number of dependency cycles relevant to
> architecture bootstrapping. Those are hard to solve, but without looking
> into detail, a number of dependencies can be easily dropped:
>
>  * check is only used for unittests. Therefore it can be skipped with
>the  build profile.
>  * libsamplerate0-dev is deprecated in pulseaudio and only enabled when
>explicitly passing --enable-libsamplerate. The package hasn't done
>this and therefore libsamplerate is unused.
>  * libjson-c-dev is unused since version 10.0 where pulseaudio adopted
>its own json parsing library. See NEWS.
>
> This seems all quite straight forward, no? Please apply the attached
> patch
>

Thanks! Applied.

I suspect this won't help you very much in the bootstrap process. I figure
what is needed is a build profile that builds only libpulse{0,-dev}. Happy
to take patches for it.


-- 

Saludos,
Felipe Sateler

Bug#979084: transition: hamlib

[Christoph Berg]

Re: To 979...@bugs.debian.org
> I'll upload the two rdeps needing source changes and then provide a
> list for binnmus for the rest.

Here we go:

cubicsdr
direwolf
fldigi
freedv
klog
qsstv
soapyaudio
soundmodem
tucnak
xlog

Plus for the limesuite transition:

gr-limesdr
osmo-trx

Thanks,
Christoph

Bug#979306: QVTKOpenGLWidget.h: No such file or directory

[Drew Parsons]

Hi Anton, I've pushed avogadrolibs to salsa master,
https://salsa.debian.org/debichem-team/avogadrolibs

On 2021-01-06 07:00, Anton Gladky wrote:

Hi Drew,

could you please push the version of avogadrolibs which your working on
into the git? So I could probably test it against newer vtk9. Thanks.

Regards

Anton

Am Di., 5. Jan. 2021 um 05:09 Uhr schrieb Drew Parsons 
:


Package: libvtk9-qt-dev
Version: 9.0.1+dfsg1-6
Severity: normal

This is another report from trying to build avogadrolibs against VTK9
(Build-Depends: libvtk9-qt-dev), following on from Bug#979073
(thanks for configuring RenderingContextOpenGL2).

Bug#979383: npm update -g error: no such file or directory, scandir '/usr/local/lib/node_modules'

[Bart]

Package: npm
Version: 7.3.0+ds-2
Severity: normal
X-Debbugs-Cc: bart...@gmail.com

Dear Maintainer,

I am unable to run `npm update -g` on a newly built container based on
debian:testing.

Instead, I get the following error:

```
 > [4/4] RUN npm update -g:
#7 0.804 npm ERR! code ENOENT
#7 0.804 npm ERR! syscall scandir
#7 0.804 npm ERR! path /usr/local/lib/node_modules
#7 0.804 npm ERR! errno -2
#7 0.805 npm ERR! enoent ENOENT: no such file or directory, scandir 
'/usr/local/lib/node_modules'
#7 0.805 npm ERR! enoent This is related to npm not being able to find a file.
#7 0.805 npm ERR! enoent
#7 0.817
#7 0.817 npm ERR! A complete log of this run can be found in:
#7 0.817 npm ERR! /root/.npm/_logs/2021-01-05T22_38_24_940Z-debug.log
```

Steps to reproduce:

Create the following Dockerfile:
```
FROM 
debian:testing@sha256:8169043352db303b39fd9b6daa39ad3d5ea994c94bb9c0cdf56d97144858434c
RUN apt-get update
RUN apt-get install -y npm
RUN npm update -g
```

Then run `docker build .`

Note that I have not attempted to reproduce the problem on a full VM
install, and presume that the same bug would be present.

Expected output:

```
 > npm update -g

up to date, audited 1 package in 377ms

found 0 vulnerabilities
```

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages npm depends on:
ii  ca-certificates 20200601
ii  node-abbrev 1.1.1-2
ii  node-agent-base 6.0.2-1
ii  node-ajv6.12.6-2
ii  node-ansi   0.3.1-1
ii  node-ansi-regex 5.0.0-1
ii  node-ansi-styles4.2.1-1
ii  node-ansistyles 0.1.3-2
ii  node-aproba 2.0.0-1
ii  node-archy  1.0.0-3
ii  node-are-we-there-yet   1.1.5-1
ii  node-asap   2.0.6-2
ii  node-asn1   0.2.3-2
ii  node-assert-plus1.0.0-2
ii  node-asynckit   0.4.0-3
ii  node-aws-sign2  0.7.1-2
ii  node-aws4   1.11.0-1
ii  node-balanced-match 1.0.0-1
ii  node-bcrypt-pbkdf   1.0.2-1
ii  node-brace-expansion2.0.0-1
ii  node-builtins   1.0.3-2
ii  node-cacache15.0.5+~cs13.9.21-1
ii  node-caseless   0.12.1-1
ii  node-chalk  4.1.0-1
ii  node-chownr 1.1.3-5
ii  node-clone  2.1.2-2
ii  node-color-convert  1.9.3-1
ii  node-color-name 1.1.4+~1.1.1-1
ii  node-colors 1.4.0-1
ii  node-columnify  1.5.4-3
ii  node-combined-stream1.0.8-1
ii  node-concat-map 0.0.1-2
ii  node-console-control-strings1.1.0-2
ii  node-core-util-is   1.0.2-2
ii  node-dashdash   2.0.0-1
ii  node-debug  4.3.1+~cs4.1.5-1
ii  node-defaults   1.0.3-2
ii  node-delayed-stream 1.0.0-4
ii  node-delegates  1.0.0-2
ii  node-depd   2.0.0-1
ii  node-ecc-jsbn   0.2.0-2
ii  node-encoding   0.1.13-1
ii  node-err-code   2.0.3+dfsg-1
ii  node-extend 3.0.2-1
ii  node-extsprintf 1.4.0-1
ii  node-fast-deep-equal3.1.3-1
ii  node-forever-agent  0.6.1-2
ii  node-form-data  3.0.0-2
ii  node-fs.realpath1.0.0-1.1
ii  node-function-bind  1.1.1+repack-1
ii  node-gauge  2.7.4-1.1
ii  node-getpass0.1.7-1.1
ii  node-glob   7.1.6+~7.1.3-1
ii  node-graceful-fs4.2.4+repack-1
ii  node-gyp7.1.2-2
ii  node-har-schema 2.0.0-4
ii  node-har-validator  5.1.5-1
ii  node-has-flag   4.0.0-1
ii  node-http-signature 1.3.5-1
ii  node-https-proxy-agent  5.0.0-2
ii  node-iconv-lite 0.5.1-3
ii  node-imurmurhash0.1.4-1.1
ii  node-indent-string  4.0.0-1
ii  node-inflight   1.0.6-1.1
ii  node-inherits   2.0.4-1
ii  node-ini2.0.0-1
ii  node-ip 1.1.5-5
ii  node-ip-regex   4.1.0-2
ii  node-is-typedarray  1.0.0-3
ii  node-isarray2.0.5-1
ii  node-isexe  2.0.0-4
ii  node-isstream   0.1.2+dfsg-1.1
ii  node-jsbn   1.1.0-1.1
ii  node-json-parse-better-errors   1.

Bug#979382: sbuild-createchroot: E: failed running setup script: cannot open /etc/passwd

[Jochen Sprickerhof]

Package: sbuild
Version: 0.80.1
Severity: normal

Hi,

on a freshly installed Debian unstable:

$ sudo apt install sbuild mmdebstrap
$ sbuild-createchroot --debootstrap=mmdebstrap \
--make-sbuild-tarball ~/.cache/sbuild/unstable-amd64.tar.gz \
unstable $(mktemp -d)  # according to man mmdebstrap
I: SUITE: unstable
I: TARGET: /tmp/tmp.eLWAANve3b
I: MIRROR: http://deb.debian.org/debian
I: Running mmdebstrap --arch=amd64 --variant=buildd --verbose 
--include=fakeroot,build-essential --components=main --resolve-deps 
--no-merged-usr unstable /tmp/tmp.eLWAANve3b http://deb.debian.org/debian
I: the option --resolve-deps is a no-op. It only exists for compatibility with 
some debootstrap wrappers.
I: the option --no-merged-usr is a no-op. It only exists for compatibility with 
some debootstrap wrappers.
I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: automatically chosen format: directory
I: running apt-get update...
[...]
I: cleaning package lists and apt cache...
Reading package lists...
I: success in 38.6073 seconds
E: failed running setup script: cannot open /etc/passwd at (eval 20) line 1, 
 line 1.

I guess this is due to the unshare mode, whereas sbuild-createchroot
tries to modify /etc/passwd as the normal user:

$ ll /tmp/tmp.eLWAANve3b/etc/passwd
-rw-r--r-- 1 10 10 922  5. Jan 23:40 /tmp/tmp.eLWAANve3b/etc/passwd

Cheers Jochen

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

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

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.80.1
ii  perl5.32.0-6

Versions of packages sbuild recommends:
ii  autopkgtest  5.15
ii  debootstrap  1.0.123
ii  schroot  1.6.10-11+b1

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.45.6-1
ii  kmod   27+20200310-2
ii  wget   1.21-1

-- no debconf information

Bug#979381: Useless in Debian

[David Prévot]

Package: php-db-dataobject
Severity: serious
X-Debbugs-Cc: Sunil Mohan Adapa , Rajasekhar Ponakala 
, Bhuvan Krishna Devabhaktuni 

Hi Sunil and other uploaders,

As per #979156, I believe php-db-dataobject was introduced in Debian as
part of the gnusocial packaging effort, but Sunil already pointed that
“There is currently no active interest in packaging gnusocial” No
packages currently depend on it, so I don’t believe it’s useful to keep
it around.

Unless someone disagree with the above, I intend to ask for removal of
this package soon (so if you read this message years from now, no need
to ask for permission to act on what I’ve failed to…) and welcome anyone
taking care of the removal request before me.

Thank you Holger for triggering a closer look at this package!

Regards

David


signature.asc
Description: PGP signature

Bug#777291: gpm should provides systemd services

[Axel Beckert]

Control: tag -1 + pending

Hi Moritz,

Moritz Mühlenhoff wrote:
> Attached is a patch against current sid which adds a systemd unit
> for gpm. I've been using it for a few days on my system without
> any issues.

Thanks! Committed to git and pushed.

Will probably do an upload tomorrow. To tired now and still some other
things to fix.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#979380: problem installing for lighttpd when fastcgi-php-fpm is already enabled

[James Dietrich]

Package: phpmyadmin
Version: 4:4.9.7+dfsg1-1
Severity: normal

I am running Debian testing.

I installed lighttpd and, among other things, enabled the fastcgi-php-fpm 
module. At this point lighttpd was functioning properly as expected.

Then I installed phpmyadmin and asked it to configure automatically for 
lighttpd. This caused lighttpd to be unable to start. I determined that this 
was due to the fact that the postinst script in the phpmyadmin package enables 
the lighttpd fastcgi-php module:
lighty-enable-mod phpmyadmin auth fastcgi fastcgi-php

My solution was to manually disable the fastcgi-php module, which allowed 
lighttpd to start again.

But I don't think that the phpmyadmin postinst should enable fastcgi-php when 
the fastcgi-php-fpm module is already enabled.

Let me know if I can provide any further information.

Thank you,
James Dietrich

Bug#979379: ITS: src:gnupg2

[Christoph Biedl]

Package: src:gnupg2
Version: 2.2.20-1
Severity: important
X-Debbugs-Cc: Debian GnuPG Maintainers 
, Daniel Kahn Gillmor 
, Eric Dorland  

Greetings,

as described in the developers' reference, I hereby declare my intention
to salvage the gnugp2 package, with the primary goal of having a recent
upstream version in the upcoming release; and long-term to assert it
will be kept in shape, by (without a particular preference) joining the
team or or taking over maintainership.

According to the "(conservative) criteria" list found in the Debian
wiki:

| A package is eligible for salvaging if it is in clear need of some
| love and care, i.e. there are open bugs,

Lots.

| missing upstream releases,

Several. Debian has 2.20, uploaded in March. Upstream is at 2.26.

There was a "new upstream version availabe" bug report in December 2020:
. This also lists features that are
interesting to have.

| or there is work needed from a quality-assurance perspective;

Possibly yes.

| AND there is the need to upload the package to deal with these issues;

Yes.

| AND at least one of these criteria applies:

|   There is no visible activity regarding the package for six months, OR

Yes: Last upload, also commit to salsa was in March 2020:
https://salsa.debian.org/debian/gnupg2/-/commits/debian/master

|   A previous NMU was not acknowledged, and a bug justifying another
|   NMU is pending for one month 1, OR

No

|   The last upload was an NMU and there was no maintainer upload
|   within one year, OR

No

|Bugs exist for more than one major missing upstream version2 and
|the first bug is older than one year, OR

No

|   The package blocks a sourceful transition for six months after a
|   transition bug was filed against the package in question.

No


Regards,

Christoph


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

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

Versions of packages gnupg depends on:
ii  dirmngr 2.2.20-1
ii  gnupg-l10n  2.2.20-1
ii  gnupg-utils 2.2.20-1
ii  gpg 2.2.20-1
ii  gpg-agent   2.2.20-1
ii  gpg-wks-client  2.2.20-1
ii  gpg-wks-server  2.2.20-1
ii  gpgsm   2.2.20-1
ii  gpgv2.2.20-1

gnupg recommends no packages.

Versions of packages gnupg suggests:
pn  parcimonie  
pn  xloadimage  

-- no debconf information



signature.asc
Description: PGP signature

Bug#979191: Missing dependency for nautilus-nextcloud

[Sandro Knauß]

Control: tags -1 +moreinfo

Hey,

> I feel like the package 'nautilus-nextcloud' should have a dependency
> on 'nextcloud-desktop-cmd'.
> 
> If I install only the package 'nautilus-nextcloud' it also install
> 'nextcloud-desktop' as a dependency, so I can setup an account an sync
> files but I have none of the features that it should bring to nautilus
> event though the extension seems to be loaded without errors:
> 
> $ nautilus
> Initializing Nextcloud-client-nautilus extension
> ...
> 
> If I manually install 'nextcloud-desktop-cmd' then everything seems to
> work as expected.

This is interessting and strange.  'nextcloud-desktop-cmd' only install usr/
bin/nextcloudcmd and that is not used by the nautilus extension. The extension 
is using a socket to reach Nextcloud get the status:
$XDG_RUNTIME_DIR/Nextcloud/socket
and this socket is provided by nextcloud-desktop:
lsof | grep  $XDG_RUNTIME_DIR/Nextcloud/socket

That's why expect that 'nextcloud-desktop-cmd' depends on something, that is 
missing is your case. Please try to remove nextcloud-desktop-cmd than the 
extension should still working and apt should list some packages, that are not 
needed anymore, those are the candidates of the missing dependency. Can you 
give me the list of those packages?

hefee

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

Bug#979354: Acknowledgement (ucf: ucfr aborting when upgrading with diverted config (dpkg-divert))

[Oliver O.]

Attached the patch as a file.
*** usr/bin/ucf~	2020-06-16 07:37:53.0 +0200
--- usr/bin/ucf	2021-01-05 16:36:12.097133824 +0100
***
*** 439,454 
  fi
  
  # Follow dpkg-divert as though we are installed as part of $opt_package
! divert_line=$(dpkg-divert --list "$dest_file")
  if [ -n "$divert_line" ]; then
!if [ echo "$divert_line" | grep "^local" ]; then
!# local diversion; pick something not in the package namespace
!divert_package="LOCAL"
!else
!# extract the name of the diverted package.
!# The fact that this requires output parsing is bug #485012
!divert_package=$(dpkg-divert --listpackage "$dest_file")
!fi
  
 if [ "$divert_package" != "$opt_package" ]; then
 dest_file=$(dpkg-divert --truename "$dest_file")
--- 439,448 
  fi
  
  # Follow dpkg-divert as though we are installed as part of $opt_package
! divert_line=$(dpkg-divert --listpackage "$dest_file")
  if [ -n "$divert_line" ]; then
!# name of the package or 'LOCAL' for a local diversion
!divert_package="$divert_line"
  
 if [ "$divert_package" != "$opt_package" ]; then
 dest_file=$(dpkg-divert --truename "$dest_file")
*** usr/bin/ucfr~	2020-06-16 07:37:53.0 +0200
--- usr/bin/ucfr	2021-01-05 16:39:06.592853096 +0100
***
*** 112,121 
  awk '{print $1;}' );
  
  if [ "$pkg" != "$old_pkg" ]; then
! if [ "X$FORCE" = "X" ]; then
! echo >&2 "$progname: Attempt from package $pkg  to take ${real_conf_file} away from package $old_pkg";
! echo >&2 "ucfr: Aborting.";
! exit 4;
  fi
  else
  if [ "X$VERBOSE" != "X" ]; then
--- 112,129 
  awk '{print $1;}' );
  
  if [ "$pkg" != "$old_pkg" ]; then
! divert_package=$(dpkg-divert --listpackage "$conf_file")
! if [ -n "$divert_package" ]; then
! if [ "X$VERBOSE" != "X" ]; then
! echo >&2 "$progname: Package $pkg will not take away diverted ${conf_file} from package $divert_package";
! fi
! exit 0;
! else
! if [ "X$FORCE" = "X" ]; then
! echo >&2 "$progname: Attempt from package $pkg  to take ${real_conf_file} away from package $old_pkg";
! echo >&2 "ucfr: Aborting.";
! exit 4;
! fi
  fi
  else
  if [ "X$VERBOSE" != "X" ]; then

Bug#979378: network-manager should drop unused Build-Depends

[Helmut Grohne]

Source: network-manager
Version: 1.28.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

network-manager has a number of Build-Depends and is involved in
dependency cycles relevant to architecture bootstrap. Instead of looking
into such cycles, a simpler measure is looking into entirely unused
Build-Depends. As it happens, network-manager has those.

According to debian/changelog, libyaml-perl was added to build the
documentation. At this point nothing in the source mentions it in any
way. I think it can be safely dropped.

The NEWS file kindly explains that since version 1.24,
libpolkit-agent-1-dev and libpolkit-gobject-1-dev are no longer needed.
While meson.build and configure.ac still check for polkit-agent, they're
completely unused otherwise and network-manager now interacts with
polkit via dbus and its own abstraction only.

Please consider applying the attached patch to drop these dependencies.

Helmut
diff --minimal -Nru network-manager-1.28.0/debian/changelog 
network-manager-1.28.0/debian/changelog
--- network-manager-1.28.0/debian/changelog 2020-12-31 21:38:43.0 
+0100
+++ network-manager-1.28.0/debian/changelog 2021-01-05 22:51:29.0 
+0100
@@ -1,3 +1,10 @@
+network-manager (1.28.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 05 Jan 2021 22:51:29 +0100
+
 network-manager (1.28.0-2) unstable; urgency=medium
 
   * Demote libpam-systemd to Recommends.
diff --minimal -Nru network-manager-1.28.0/debian/control 
network-manager-1.28.0/debian/control
--- network-manager-1.28.0/debian/control   2020-12-31 21:38:43.0 
+0100
+++ network-manager-1.28.0/debian/control   2021-01-05 22:51:23.0 
+0100
@@ -11,8 +11,6 @@
intltool,
libglib2.0-dev (>= 2.32),
ppp-dev (>= 2.4.7-1+1),
-   libpolkit-gobject-1-dev,
-   libpolkit-agent-1-dev (>= 0.97),
libselinux1-dev,
libaudit-dev,
libgnutls28-dev (>= 2.12),
@@ -27,7 +25,6 @@
libcurl4-gnutls-dev (>= 7.24.0),
gtk-doc-tools,
perl,
-   libyaml-perl,
libglib2.0-doc,
libmm-glib-dev (>=  0.7.991),
libndp-dev,

Bug#979377: tlf: FTBFS on mips*: test failures

[Sebastian Ramacher]

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

tlf fails to build on mips*:
| 
|Tlf 1.4.1: test/test-suite.log
| 
|
| # TOTAL: 21
| # PASS:  20
| # SKIP:  0
| # XFAIL: 0
| # FAIL:  1
| # XPASS: 0
| # ERROR: 0
|
| .. contents:: :depth: 2
|
| FAIL: run_cabrillo
| ==
|
| [==] Running 12 test(s).
| [ RUN  ] test_starts_with_succeed
| [   OK ] test_starts_with_succeed
| [ RUN  ] test_starts_with_fails
| [   OK ] test_starts_with_fails
| [ RUN  ] test_translateItem
| [   OK ] test_translateItem
| [ RUN  ] test_freeCabfmt
| [   OK ] test_freeCabfmt
| [ RUN  ] test_parseLine
| [   OK ] test_parseLine
| [ RUN  ] test_readCabrilloFormatUniversal
| [   OK ] test_readCabrilloFormatUniversal
| [ RUN  ] test_readCabrilloFormatWAE
| [   OK ] test_readCabrilloFormatWAE
| [ RUN  ] test_readCabrilloFileNotFound
| [   OK ] test_readCabrilloFileNotFound
| [ RUN  ] test_readCabrilloFormatNotFound
| [   OK ] test_readCabrilloFormatNotFound
| [ RUN  ] test_cabToTlf_ParseQSO
| [  ERROR   ] --- 0 != 0x3
| [   LINE   ] --- test_cabrillo.c:159: error: Failure!
| [  FAILED  ] test_cabToTlf_ParseQSO
| [ RUN  ] test_cabToTlf_ParseXQSO
| [  ERROR   ] --- 0 != 0x3
| [   LINE   ] --- test_cabrillo.c:179: error: Failure!
| [  FAILED  ] test_cabToTlf_ParseXQSO
| [ RUN  ] test_cabToTlf_ParseQTC
| [   OK ] test_cabToTlf_ParseQTC
| [==] 12 test(s) run.
| [  PASSED  ] 10 test(s).
| [  FAILED  ] 2 test(s), listed below:
| [  FAILED  ] test_cabToTlf_ParseQSO
| [  FAILED  ] test_cabToTlf_ParseXQSO
|
|  2 FAILED TEST(S)
| FAIL run_cabrillo (exit status: 2)

See
https://buildd.debian.org/status/fetch.php?pkg=tlf&arch=mips64el&ver=1.4.1-2&stamp=1609846479&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#979376: CVE-2020-35681: potential leakage of session identifiers using legacy AsgiHandler

[Salvatore Bonaccorso]

Source: python-django-channels
Version: 3.0.2-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for python-django-channels.

CVE-2020-35681[0]:
| Potential leakage of session identifiers using legacy AsgiHandler

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-35681
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35681
[1] https://channels.readthedocs.io/en/latest/releases/3.0.3.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#979367: kodi: segfault when shutting down

[Sebastian Bachmann]

Hi!

sure, I just started kodi and pressed shutdown.
Should be the most minimal version possible.

Sebastian


On Tue, Jan 05, 2021 at 09:02:30PM +, Vasyl Gello wrote:
> Hi Sebastian!
> 
> Can you also attach kodi.log describing the crashed instance? Please check 
> for user name / IP address / URLs to avoid leaking sensitive info and attach 
> it to the reply.
> 
> Thanks!
> -- 
> Vasyl Gello
> ==
> Certified SolidWorks Expert
> 
> Mob.:+380 (98) 465 66 77
> 
> E-Mail: vasek.ge...@gmail.com
> 
> Skype: vasek.gello
> ==
> 호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다
## Kodi CRASH LOG ###

 SYSTEM INFO 
 Date: Di 05 Jän 2021 22:17:22 CET
 Kodi Options: 
 Arch: x86_64
 Kernel: Linux 5.9.0-5-amd64 #1 SMP Debian 5.9.15-1 (2020-12-17)
 Release: Debian GNU/Linux
## END SYSTEM INFO ##

### STACK TRACE #
=>  Core file: /home/kodi/core (2021-01-05 22:17:22.738685160 +0100)
=
[New LWP 714]
[New LWP 687]
[New LWP 686]
[New LWP 684]
[New LWP 688]
[New LWP 693]
[New LWP 694]
[New LWP 702]
[New LWP 696]
[New LWP 695]
[New LWP 703]
[New LWP 704]
[New LWP 705]
[New LWP 678]
[New LWP 685]
[New LWP 706]
[New LWP 716]
[New LWP 707]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/x86_64-linux-gnu/kodi/kodi.bin --standalone'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fea22e62f6b in PyModule_GetDict () from 
/lib/x86_64-linux-gnu/libpython3.9.so.1.0
[Current thread is 1 (Thread 0x7fe9ae7fc700 (LWP 714))]

Thread 18 (Thread 0x7fe9ce7fc700 (LWP 707)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7fe9ce7fae30, 
clockid=-830493312, expected=0, futex_word=0x556688e94a80) at 
../sysdeps/nptl/futex-internal.h:323
#1  __pthread_cond_wait_common (abstime=0x7fe9ce7fae30, clockid=-830493312, 
mutex=0x556688e95eb0, cond=0x556688e94a58) at pthread_cond_wait.c:520
#2  __pthread_cond_clockwait (abstime=0x7fe9ce7fae30, clockid=-830493312, 
mutex=0x556688e95eb0, cond=0x556688e94a58) at pthread_cond_wait.c:677
#3  __pthread_cond_clockwait (cond=0x556688e94a58, mutex=0x556688e95eb0, 
clockid=-830493312, abstime=0x7fe9ce7fae30) at pthread_cond_wait.c:665
#4  0x556685eb07d2 in ?? ()
#5  0x556685eb0a74 in CTimer::Process() ()
#6  0x556685eacbc5 in CThread::Action() ()
#7  0x556685eae79e in ?? ()
#8  0x556685eaec29 in ?? ()
#9  0x7fea1f622ed0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x7fea236f7ea7 in start_thread (arg=) at 
pthread_create.c:477
#11 0x7fea1f820d8f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 17 (Thread 0x7fe9ad7fa700 (LWP 716)):
#0  0x7fea1f81639f in __GI___poll (fds=0x7fe994000b60, nfds=2, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7fea235d807a in ?? () from /lib/x86_64-linux-gnu/libavahi-common.so.3
#2  0x7fea235d7c01 in avahi_simple_poll_run () from 
/lib/x86_64-linux-gnu/libavahi-common.so.3
#3  0x7fea235d7dd8 in avahi_simple_poll_iterate () from 
/lib/x86_64-linux-gnu/libavahi-common.so.3
#4  0x7fea235d800d in avahi_simple_poll_loop () from 
/lib/x86_64-linux-gnu/libavahi-common.so.3
#5  0x7fea235d80d7 in ?? () from /lib/x86_64-linux-gnu/libavahi-common.so.3
#6  0x7fea236f7ea7 in start_thread (arg=) at 
pthread_create.c:477
#7  0x7fea1f820d8f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 16 (Thread 0x7fe9ceffd700 (LWP 706)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7fe9ceffbeb0, 
clockid=-822100560, expected=0, futex_word=0x556688f0dc30) at 
../sysdeps/nptl/futex-internal.h:323
#1  __pthread_cond_wait_common (abstime=0x7fe9ceffbeb0, clockid=-822100560, 
mutex=0x556688ee1d70, cond=0x556688f0dc08) at pthread_cond_wait.c:520
#2  __pthread_cond_clockwait (abstime=0x7fe9ceffbeb0, clockid=-822100560, 
mutex=0x556688ee1d70, cond=0x556688f0dc08) at pthread_cond_wait.c:677
#3  __pthread_cond_clockwait (cond=0x556688f0dc08, mutex=0x556688ee1d70, 
clockid=-822100560, abstime=0x7fe9ceffbeb0) at pthread_cond_wait.c:665
#4  0x5566864adfb8 in PERIPHERALS::CEventScanner::Process() ()
#5  0x556685eacbc5 in CThread::Action() ()
#6  0x556685eae79e in ?? ()
#7  0x556685eaec29 in ?? ()
#8  0x7fea1f622ed0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#9  0x7fea236f7ea7 in start_thread (arg=) at 
pthread_create.c:477
#10 0x7fea1f820d8f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 15 (Thread 0x7fea1299d700 (LWP 685)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7fea1299bde0, 
clockid=312065280, expected=0, futex_word=0x556688e8c128) at 
../sysdeps/nptl/futex-internal.h:323
#1  __pthread_cond_wait_common (abstime=0x7fea1299bde0, clockid=31206528

Bug#979375: backuppc: Version 4 doesn't manage accents correctly.

[Ghent]

Package: backuppc
Version: 4.4.0-2
Severity: important
Tags: upstream

Dear Maintainer,

The web interface doesn't correctly manage accents in BackupFilesOnly or 
BackupFilesExclude.
If I put the word "Vidéos", it saves "Vid\x{e9}os" in the config file and 
doesn't detect the folder during backup.
If I write "Vidéos" directly in the config file, the web interface displays 
"Vidéos" but it detects correctly the folder during backup.

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable-updates
  APT policy: (950, 'stable-updates'), (950, 'testing'), (950, 'stable'), (180, 
'unstable'), (60, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages backuppc depends on:
ii  adduser3.118
ii  apache2 [httpd]2.4.46-2
ii  apache2-utils  2.4.46-2
ii  backuppc-rsync 3.1.3.0-1
ii  bzip2  1.0.8-4
ii  debconf [debconf-2.0]  1.5.74
ii  exim4  4.94-9
ii  exim4-daemon-light [mail-transport-agent]  4.94-9+b1
ii  init-system-helpers1.60
ii  iputils-ping   3:20200821-2
ii  libarchive-zip-perl1.68-1
ii  libbackuppc-xs-perl0.62-1+b1
ii  libc6  2.31-6
ii  libcgi-pm-perl 4.51-1
pn  libdigest-md5-perl 
ii  libfile-listing-perl   6.14-1
ii  libtime-parsedate-perl 2015.103-3
ii  lsb-base   11.1.0
ii  perl [libio-compress-perl] 5.32.0-6
ii  ucf3.0043

Versions of packages backuppc recommends:
ii  libio-dirent-perl0.05-1+b9
ii  openssh-client [ssh-client]  1:8.4p1-3
ii  rrdtool  1.7.2-3+b7
ii  samba-common-bin 2:4.13.2+dfsg-3
ii  smbclient2:4.13.2+dfsg-3

Versions of packages backuppc suggests:
pn  certbot | acme-tiny | acmetool | dehydrated | lacme | lecm |   
ii  elinks [www-browser]   0.13.2-1+b1
ii  epiphany-browser [www-browser] 3.38.2-1
ii  firefox [www-browser]  84.0-3
pn  libscgi-perl   
ii  links [www-browser]2.21-1
ii  links2 [www-browser]   2.21-1
ii  lynx [www-browser] 2.9.0dev.6-1
ii  midori [www-browser]   7.0-2.1
ii  par2   0.8.1-1
ii  rsync  3.2.3-3
ii  w3m [www-browser]  0.5.3-38+b1

-- Configuration Files:
/etc/backuppc/apache.conf changed [not included]
/etc/backuppc/config.pl [Errno 13] Permission non accordée: 
'/etc/backuppc/config.pl'
/etc/backuppc/hosts [Errno 13] Permission non accordée: '/etc/backuppc/hosts'
/etc/default/backuppc changed [not included]

-- debconf information excluded

Bug#977411: gdm does not recognize keyboard input

[Phillip Susi]

I disabled wayland in /etc/gdm3/daemon.conf and and keyboard input works
fine in X11.

Bug#876966: marked as pending in ben

[Mehdi Dogguy]

On 2021-01-05 22:07, Christoph Berg wrote:

Re: Mehdi Dogguy

Bug #876966 in ben reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit


I pulled scripts.js manually and change works nicely. Thanks!



Thanks a lot for checking, Christoph!

Happy new year,

--
Mehdi

Bug#979374: libdata-csv-clojure: jars are not installed in maven-repo

[Louis-Philippe Véronneau]

Package: libdata-csv-clojure
Version: 0.1.3-1
Severity: important
Owner: po...@debian.org

It seems this package does not install anything in /usr/share/maven-repo.

This means we can't currently use this package as a dependency when
building with leiningen.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979373: libdata-json-clojure: jars are not installed in maven-repo

[Louis-Philippe Véronneau]

Package: libdata-json-clojure
Version: 0.2.6-1
Severity: important
Owner: po...@debian.org

It seems this package does not install anything in /usr/share/maven-repo.

This means we can't currently use this package as a dependency when
building with leiningen.

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979372: asterisk: CVE-2020-35652

[Salvatore Bonaccorso]

Source: asterisk
Version: 1:16.15.0~dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:16.2.1~dfsg-1+deb10u2

Hi,

The following vulnerability was published for asterisk.

Rationale: Choosed RC severity orthogonally to a potential no-dsa
decision, but ideally it get fixed in time for the bullseye release.

CVE-2020-35652[0]:
| remote crash in res_pjsip_diversion

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-35652
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-35652
[1] https://issues.asterisk.org/jira/browse/ASTERISK-29191
[2] https://issues.asterisk.org/jira/browse/ASTERISK-29219
[3] https://downloads.asterisk.org/pub/security/AST-2020-003.html
[4] https://downloads.asterisk.org/pub/security/AST-2020-004.html

Regards,
Salvatore

Bug#979327: xalan: FTBFS on i386: architecture confusion

[Bill Blough]

I had already pushed the initial fix by the time I received this, so I've
reopened the bug.  I'll address it later this evening.

Bug#876966: marked as pending in ben

[Christoph Berg]

Re: Mehdi Dogguy
> Bug #876966 in ben reported by you has been fixed in the
> Git repository and is awaiting an upload. You can see the commit

I pulled scripts.js manually and change works nicely. Thanks!

Christoph

Bug#950761: RFS: ipmitool/1.8.18-11 [RC] -- utility for IPMI control with kernel driver or LAN interface (daemon)

[Salvatore Bonaccorso]

Hi Jörg,

Thanks a lot for your work on this package!

On Sun, Jan 03, 2021 at 05:21:42PM +0100, Jörg Frings-Fürst wrote:
> tags 950761 - pending
> thanks
> 
> Hello Salvatore,
> hello @All,
> 
> 
> following a tip from Salvatore, I have added the missing commits.
> Although these can be incorporated manually, they are not reliably
> functional in at least two places due to the different code base.
> 
> I think the best thing will be to wait for the next upstream release.
> 
> I am therefore withdrawing the RFS bug again.

Would it be feasible (at this stage before the freeze for bullseye) to
just rebase to the 1.8.19 release? Or are you aiming at properly
rebase those patchset to 1.8.18?

Regards,
Salvatore

Bug#979371: nis should depend on libnss-nis

[Thomas Lange]

Package: nis
Version: 3.17.1-9+b1

In bullseye the nis function of libc was moved to a new package, called
libnss-nis. I think the nis package should depend or recommend libnss-nis.
-- 
regards Thomas

Bug#979367: kodi: segfault when shutting down

[Vasyl Gello]

Hi Sebastian!

Can you also attach kodi.log describing the crashed instance? Please check for 
user name / IP address / URLs to avoid leaking sensitive info and attach it to 
the reply.

Thanks!
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

Bug#975372: minidlna: "rm: cannot remove '/var/log/minidlna': Is a directory" on purge

[Salvatore Bonaccorso]

Hi Adam, hi Alexander,

On Fri, Jan 01, 2021 at 06:20:32PM +, Adam D. Barratt wrote:
> Hi,
> 
> On Fri, 2021-01-01 at 14:21 +0100, Salvatore Bonaccorso wrote:
> > Uplaoding 1.2.1+dfsg-1 + CVE fix cannot work. We have already
> > released 1.2.1+dfsg-2+deb10u1 in the security archives, so any
> > version we pick to fix issues need to be highter, no matter if we do
> > several rollbacks or only the #975372 fix.
> > 
> > So we need in any case 1.2.1+dfsg-2+deb10u2 (no matter if "complete"
> > rollback, or just the bugfix).
> > 
> > Given the move of the logdir and systemd unit has now been done with
> > the DSA, I think my preference would be to only just address the
> > "fallout" from the logdir move and so adress #975372.
> > 
> > Adam D. Barratt is Cc'ed in this message, who is a stable release
> > managers in case he would like to indicate a preference.
> > 
> > Adam would that be fine with you with your SRM hat on, to let all the
> > -2 changes pass to stable (agreeing that that would usually not be
> > stable material under normal cicumstances) and so just address the
> > introduced #975372?
> 
> As you say, such changes would not normally be considered as part of a
> stable update. However, given that they've already been published via
> the security archive and as such been on user systems for a month or so
> by this stage, I think attempting to walk back the additional changes
> now is likely to cause us more pain than just going with them, and
> hoping that #975372 is the only issue caused as a result.

Thanks and thanks Alexander for the upload.

Regression update has just been sent out.

Regards,
Salvatore

Bug#971216: doxygen build error

[Helmut Grohne]

On Sat, Dec 19, 2020 at 11:29:36PM +0100, Sven Mueller wrote:
> Could you imagine (no pun intended) to include the change in the
> imagemagick version of the dh_doxygen script into the version in the
> doxygen package, possibly behind an option? It replaces known (currently
> only jquery) .js files by a symlink to the relevant known location of the
> (here:) jquery file and creates a substvar with the required
> dependency/dependencies.

Nack. Please read /usr/share/doc/doxygen/README.jquery and do away with
the symlink. It is broken.

> This would eventually eliminate the need to keep a script in the
> imagemagick sources in sync with the doxygen package.

There is no need in the first place. /usr/bin/dh_doxygen can be used as
is.

> The replacement is desirable from a security standpoint, as it reduces the
> places that need patching if another jquery vulnerability surfaces.

It is not. While jquery does have security updates from time to time, it
seems very unlikely that any of them could be exploited while browsing
documentation. The way Doxygen uses jquery is what lowers the risk.

Replacing jquery.js (which is not jquery despite being thus named) is of
course more secure quite like pulling the plug on your computer is more
secure. It should be noted however that doing so also reduces the
usefulness.

Helmut

Bug#893633: closed by Debian FTP Masters (reply to Markus Koschany ) (Bug#893633: fixed in tuxpuck 0.8.2-10)

[Helmut Grohne]

Control: reopen -1
Control: found -1 tuxpuck/0.8.2-10

On Tue, Jan 05, 2021 at 01:09:05PM +, Debian Bug Tracking System wrote:
>* Fix FTCBFS:
>- Build the utils folder with the build architecture compiler.
>- Remove dependency on sdl from utils/*.c.

Thank you for applying my patch. Unfortunately, it seems you're missing
one essential piece (while still mentioning it in the changelog):

>- Switch the freetype dependency to the build architecture.

Accordingly, it fails finding freetype now.

Can you add the missing :native annotation in your next upload?

Helmut

Bug#979370: dovecot FTCBFS: more AC_RUN_IFELSE

[Helmut Grohne]

Source: dovecot
Version: 1:2.3.11.3+dfsg1-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

Hi,

thank you for removing AC_RUN_IFELSE from configure.ac. Unfortunately,
they're not gone. Just moved to m4/*.m4. As such they still affect cross
building. That being said, dovecot (unlike many other users of
AC_RUN_IFELSE) uses AC_CACHE_CHECK, which enables seeding results. The
check for the signedness of size_t really doesn't have to be run as that
is a compile time property. I'm attaching a patch that reworks it
towards using AC_COMPUTE_INT.

Beyond that, dovecot uses mysql_config. I've looked into that and
mysql_config is unfixably broken during cross builds. It will not be
fixed. Instead, please use pkg-config. My patch implements that with a
fallback to mysql_config to avoid breaking other users.

Last but not least, src/lib-lua/Makefile.am adds $(LUA_LIBS) to
libdovecot_lua_la_DEPENDENCIES. As it happens, LUA_LIBS contains a -L
flag and when that flag shows up in a dependency, make gives up. I have
no clue why one would add LUA_LIBS to DEPENDENCIES as it already is
being correctly added to LIBADD. My patch suggests to quite simply drop
that.

Can you apply this patch as well?

Helmut
--- dovecot-2.3.11.3+dfsg1.orig/m4/size_t_signed.m4
+++ dovecot-2.3.11.3+dfsg1/m4/size_t_signed.m4
@@ -3,14 +3,11 @@
 dnl * that it's unsigned and only some old systems define it as signed.
 AC_DEFUN([DOVECOT_SIZE_T_SIGNED], [
   AC_CACHE_CHECK([whether size_t is signed],i_cv_signed_size_t,[
-AC_RUN_IFELSE([AC_LANG_SOURCE([[
+AC_COMPUTE_INT([i_cv_signed_size_t_num],[[(size_t)(int)-1 <= 0 ? 0 : 1]],[[
   #include 
   #include 
-  int main() {
-/* return 0 if we're signed */
-exit((size_t)(int)-1 <= 0 ? 0 : 1);
-  }
-]])],[
+]])
+AS_IF([test "$i_cv_signed_size_t_num" = 0],[
   i_cv_signed_size_t=yes
   
   echo
@@ -25,7 +22,7 @@
   echo "..ignoring as requested.."
 ],[
   i_cv_signed_size_t=no
-],[])
+])
   ])
   dnl Note: we check size_t rather than ssize_t here, because on OSX 10.2
   dnl ssize_t = int and size_t = unsigned long. We're mostly concerned about
--- dovecot-2.3.11.3+dfsg1.orig/m4/want_mysql.m4
+++ dovecot-2.3.11.3+dfsg1/m4/want_mysql.m4
@@ -1,26 +1,28 @@
 AC_DEFUN([DOVECOT_WANT_MYSQL], [
   have_mysql=no
-  if test $want_mysql != no; then
-AC_CHECK_PROG(MYSQL_CONFIG, mysql_config, mysql_config, NO)
-if test $MYSQL_CONFIG = NO; then
-  	# based on code from PHP
-  	MYSQL_LIBS="-lmysqlclient -lz -lm"
-  	for i in /usr /usr/local /usr/local/mysql; do
-  		for j in include include/mysql ""; do
-  			if test -r "$i/$j/mysql.h"; then
-  MYSQL_INCLUDE="-I$i/$j"
-  			fi
-  		done
-  		for j in lib lib/mysql lib64 lib64/mysql ""; do
-  			if test -f "$i/$j/libmysqlclient.so" || test -f "$i/$j/libmysqlclient.a"; then
-  MYSQL_LIBS="-L$i/$j -lmysqlclient -lz -lm"
-  			fi
-  		done
-  	done
-else
-  MYSQL_INCLUDE="`$MYSQL_CONFIG --include`"
-  MYSQL_LIBS="`$MYSQL_CONFIG --libs`"
-fi
+  AS_IF([test $want_mysql != no],[
+PKG_CHECK_MODULES([MYSQL],[mysqlclient],,[
+  AC_CHECK_PROG(MYSQL_CONFIG, mysql_config, mysql_config, NO)
+  if test $MYSQL_CONFIG = NO; then
+	# based on code from PHP
+	MYSQL_LIBS="-lmysqlclient -lz -lm"
+	for i in /usr /usr/local /usr/local/mysql; do
+		for j in include include/mysql ""; do
+			if test -r "$i/$j/mysql.h"; then
+MYSQL_CFLAGS="-I$i/$j"
+			fi
+		done
+		for j in lib lib/mysql lib64 lib64/mysql ""; do
+			if test -f "$i/$j/libmysqlclient.so" || test -f "$i/$j/libmysqlclient.a"; then
+MYSQL_LIBS="-L$i/$j -lmysqlclient -lz -lm"
+			fi
+		done
+	done
+  else
+MYSQL_CFLAGS="`$MYSQL_CONFIG --include`"
+MYSQL_LIBS="`$MYSQL_CONFIG --libs`"
+  fi
+])
   
 old_LIBS=$LIBS
 if test "$MYSQL_LIBS" != ""; then
@@ -31,14 +33,10 @@
 LIBS="$LIBS -lz -lm"
 AC_CHECK_LIB(mysqlclient, mysql_init, [
   		old_CPPFLAGS=$CPPFLAGS
-  		if test "$MYSQL_INCLUDE" != ""; then
-  			CPPFLAGS="$CPPFLAGS $MYSQL_INCLUDE"
+  		if test "$MYSQL_CFLAGS" != ""; then
+  			CPPFLAGS="$CPPFLAGS $MYSQL_CFLAGS"
   		fi
   		AC_CHECK_HEADER(mysql.h, [
-  			if test "$MYSQL_INCLUDE" != ""; then
-  MYSQL_CFLAGS="$MYSQL_CFLAGS $MYSQL_INCLUDE"
-  			fi
-  
   			AC_CHECK_LIB(mysqlclient, mysql_ssl_set, [
   AC_DEFINE(HAVE_MYSQL_SSL,, [Define if your MySQL library has SSL functions])
   if test "x$have_openssl" = "yes"; then
@@ -85,5 +83,5 @@
   MYSQL_CFLAGS=
 fi
 LIBS=$old_LIBS
-  fi
+  ])
 ])
--- dovecot-2.3.11.3+dfsg1.orig/src/lib-lua/Makefile.am
+++ dovecot-2.3.11.3+dfsg1/src/lib-lua/Makefile.am
@@ -9,7 +9,7 @@
 	dlua-script.c \
 	dlua-dovecot.c \
 	dlua-compat.c
-libdovecot_lua_la_DEPENDENCIES = ../lib-dovecot/libdovecot.la $(LUA_LIBS)
+libdovecot_lua_la_DEPENDENCIES = ../lib-dovecot/libdovecot.la
 libdovecot_lua_la_LIBADD = ../lib-dovecot/libdovecot.la $(LUA

Bug#979369: libsdl2 FTBFS with DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: libsdl2
Version: 2.0.12+dfsg1-4
Severity: important
Tags: ftbfs patch

libsdl2 fails to build from source when built with
DEB_BUILD_OPTIONS=nocheck. debian/rules conditionalizes doxygen with
this option (which doesn't make much sense). In the end, dh_install
fails to find the files that doxygen should have generated. I'm
attaching a patch that simply removes the conditional.

While at it, I also noticed that doxygen's jquery.js is replaced with
libjs-jquery's. Unfortunately, what is named jquery.js is not jquery.js.
It's an amalgamation of multiple javascript libraries that happened to
start out as jquery but now include more. As such replacing it breaks
doxygen's javascript code. I'm quite simply dropping the replacement as
well.

Please consider applying the attached patch.

Helmut
--- libsdl2-2.0.12+dfsg1/debian/changelog
+++ libsdl2-2.0.12+dfsg1/debian/changelog
@@ -1,3 +1,11 @@
+libsdl2 (2.0.12+dfsg1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove wrong check of nocheck profile. (Closes: #-1)
+  * Don't replace jquery.js: What is named jquery, is not jquery.
+
+ -- Helmut Grohne   Tue, 05 Jan 2021 17:21:43 +0100
+
 libsdl2 (2.0.12+dfsg1-4) unstable; urgency=medium
 
   * Team upload
--- libsdl2-2.0.12+dfsg1/debian/control
+++ libsdl2-2.0.12+dfsg1/debian/control
@@ -116,7 +116,6 @@
 Build-Profiles: 
 Depends:
  ${misc:Depends},
- libjs-jquery
 Breaks:
  libsdl2-dev (<< 2.0.4+dfsg-1)
 Replaces:
--- libsdl2-2.0.12+dfsg1/debian/rules
+++ libsdl2-2.0.12+dfsg1/debian/rules
@@ -48,8 +48,6 @@
 override_dh_auto_configure:
dh_auto_configure -- $(confflags)
 
-ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
-
 override_dh_auto_build-indep:
GZIP="-9n" tar czf debian/examples.tar.gz test --owner=0 --group=0 
--mode=go=rX,u+rw,a-s --clamp-mtime --mtime="@$(SOURCE_DATE_EPOCH)" --sort=name
doxygen docs/doxyfile
@@ -57,17 +55,12 @@
find output -name "*.md5" -delete
find output -type d -empty -delete
 
-   find output -name "jquery.js" -delete
-   dh_link -plibsdl2-doc usr/share/javascript/jquery/jquery.js 
usr/share/doc/libsdl2-doc/html/jquery.js
-
 # Force examples to be installed in libsdl2-doc, it does not happen with compat
 # level v11 despite having the file debian/libsdl2-doc.examples (it gets
 # installed as part of libsdl2-dev instead)
 override_dh_installexamples-indep:
dh_installexamples -i --doc-main-package=libsdl2-doc
 
-endif # !nocheck
-
 override_dh_auto_build-arch:
dh_auto_build -- V=1
 

Bug#979368: pacemaker should drop unused Build-Depends

[Helmut Grohne]

Source: pacemaker
Version: 2.0.5-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

pacemaker has a lot of build dependencies and is involved in a number of
dependency cycles relevant to architecture bootstrap. Before looking
into the actual cycles, an easy measure is dropping those that are not
used in any way. Here we go:

 * dctrl-tools is documented (thanks) as being used for
   debian/check_header_deps. That file does not exist.
 * libesmtp-dev seems entirely unused. I looked for #includes or
   something that would link it to no avail.
 * libsnmp-dev also seems unused. I couldn't find and use of it.
 * libsensors-dev is documented as used by net-snmp-config --agent-libs,
   which we just dropped.

The nice thing is that pacemaker builds reproducibly. I attempted a
build with all of these dependencies turned into Build-Conflicts and
doing so results in bit-identical artifacts. It seems like a relatively
safe bet that we can just drop them. Please consider applying my patch.

Helmut
diff --minimal -Nru pacemaker-2.0.5/debian/changelog 
pacemaker-2.0.5/debian/changelog
--- pacemaker-2.0.5/debian/changelog2020-12-26 18:25:28.0 +0100
+++ pacemaker-2.0.5/debian/changelog2021-01-05 20:54:59.0 +0100
@@ -1,3 +1,10 @@
+pacemaker (2.0.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 05 Jan 2021 20:54:59 +0100
+
 pacemaker (2.0.5-1) unstable; urgency=medium
 
   * [b0f97de] New upstream release (2.0.5)
diff --minimal -Nru pacemaker-2.0.5/debian/control 
pacemaker-2.0.5/debian/control
--- pacemaker-2.0.5/debian/control  2020-11-18 19:02:38.0 +0100
+++ pacemaker-2.0.5/debian/control  2021-01-05 20:54:37.0 +0100
@@ -7,8 +7,6 @@
  Adrian Vondendriesch ,
 Build-Depends:
  cluster-glue-dev,
-# debian/check_header_deps needs:
- dctrl-tools,
  debhelper-compat (= 12),
  dh-exec,
  dh-python,
@@ -20,7 +18,6 @@
  libcmap-dev (>= 1.99),
  libcpg-dev (>= 1.99),
  libdbus-1-dev,
- libesmtp-dev,
  libglib2.0-dev,
  libgnutls28-dev,
  libltdl-dev,
@@ -28,9 +25,6 @@
  libpam0g-dev,
  libqb-dev (>= 0.17.1),
  libquorum-dev (>= 1.99),
-# net-snmp-config --agent-libs contains -lsensors in sid on 2015-09-15
- libsensors-dev,
- libsnmp-dev,
  libxml2-dev,
  libxml2-utils,
  libxslt1-dev,

Bug#979367: kodi: segfault when shutting down

[Sebastian Bachmann]

Package: kodi-bin
Version: 2:19.0~beta2+dfsg1-2
Severity: important

Dear Maintainers,

I have configured kodi in standalone mode using lightdm autologin
feature and the kodi.desktop xsession.
When I shutdown the PC using the kodi menu, kodi segfaults and thus
lightdm restarts the session.

I get the following kodi crashlog:

## Kodi CRASH LOG ###

 SYSTEM INFO 
 Date: Di 05 Jän 2021 17:12:26 CET
 Kodi Options: 
 Arch: x86_64
 Kernel: Linux 5.9.0-5-amd64 #1 SMP Debian 5.9.15-1 (2020-12-17)
 Release: Debian GNU/Linux
## END SYSTEM INFO ##

### STACK TRACE #
=>  Core file: /home/kodi/core (2021-01-05 17:12:26.002469806 +0100)
=
[New LWP 752]
[New LWP 723]
[New LWP 722]
[New LWP 721]
[New LWP 740]
[New LWP 1199]
[New LWP 731]
[New LWP 743]
[New LWP 725]
[New LWP 733]
[New LWP 744]
[New LWP 715]
[New LWP 730]
[New LWP 754]
[New LWP 1172]
[New LWP 732]
[New LWP 742]
[New LWP 1171]
[New LWP 741]
[New LWP 724]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/x86_64-linux-gnu/kodi/kodi.bin --standalone'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f4199894f6b in PyModule_GetDict () from 
/lib/x86_64-linux-gnu/libpython3.9.so.1.0
[Current thread is 1 (Thread 0x7f4134ff9700 (LWP 752))]

Thread 20 (Thread 0x7f417bfff700 (LWP 724)):
#0  0x7f4196249c67 in ioctl () at ../sysdeps/unix/syscall-template.S:120
#1  0x7f419a0887e2 in ?? () from /lib/x86_64-linux-gnu/libasound.so.2
#2  0x55a2655e81e9 in CAESinkALSA::AddPackets(unsigned char**, unsigned 
int, unsigned int) ()
#3  0x55a2655d105a in 
ActiveAE::CActiveAESink::OutputSamples(ActiveAE::CSampleBuffer*) ()
#4  0x55a2655d22a3 in ActiveAE::CActiveAESink::StateMachine(int, 
Actor::Protocol*, Actor::Message*) ()
#5  0x55a2655d2d54 in ActiveAE::CActiveAESink::Process() ()
#6  0x55a264cc2bc5 in CThread::Action() ()
#7  0x55a264cc479e in ?? ()
#8  0x55a264cc4c29 in ?? ()
#9  0x7f4196054ed0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x7f419a129ea7 in start_thread (arg=) at 
pthread_create.c:477
#11 0x7f4196252d8f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 19 (Thread 0x7f414effd700 (LWP 741)):
#0  0x7f419624839f in __GI___poll (fds=0x7f414effbeb0, nfds=1, timeout=100) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x55a264943cc2 in PERIPHERALS::CPeripheralBusUSB::WaitForUpdate() ()
#2  0x55a264943e70 in PERIPHERALS::CPeripheralBusUSB::Process() ()
#3  0x55a264cc2bc5 in CThread::Action() ()
#4  0x55a264cc479e in ?? ()
#5  0x55a264cc4c29 in ?? ()
#6  0x7f4196054ed0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x7f419a129ea7 in start_thread (arg=) at 
pthread_create.c:477
#8  0x7f4196252d8f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 18 (Thread 0x7f414cff9700 (LWP 1171)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7f414cff7e30, 
clockid=1291812224, expected=0, futex_word=0x55a267625484) at 
../sysdeps/nptl/futex-internal.h:323
#1  __pthread_cond_wait_common (abstime=0x7f414cff7e30, clockid=1291812224, 
mutex=0x55a26761ac90, cond=0x55a267625458) at pthread_cond_wait.c:520
#2  __pthread_cond_clockwait (abstime=0x7f414cff7e30, clockid=1291812224, 
mutex=0x55a26761ac90, cond=0x55a267625458) at pthread_cond_wait.c:677
#3  __pthread_cond_clockwait (cond=0x55a267625458, mutex=0x55a26761ac90, 
clockid=1291812224, abstime=0x7f414cff7e30) at pthread_cond_wait.c:665
#4  0x55a264cc67d2 in ?? ()
#5  0x55a264cc6a74 in CTimer::Process() ()
#6  0x55a264cc2bc5 in CThread::Action() ()
#7  0x55a264cc479e in ?? ()
#8  0x55a264cc4c29 in ?? ()
#9  0x7f4196054ed0 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6
#10 0x7f419a129ea7 in start_thread (arg=) at 
pthread_create.c:477
#11 0x7f4196252d8f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 17 (Thread 0x7f414e7fc700 (LWP 742)):
#0  futex_abstimed_wait_cancelable (private=0, abstime=0x7f414e7faeb0, 
clockid=1316990384, expected=0, futex_word=0x55a2689cfc98) at 
../sysdeps/nptl/futex-internal.h:323
#1  __pthread_cond_wait_common (abstime=0x7f414e7faeb0, clockid=1316990384, 
mutex=0x55a2689cefb0, cond=0x55a2689cfc70) at pthread_cond_wait.c:520
#2  __pthread_cond_clockwait (abstime=0x7f414e7faeb0, clockid=1316990384, 
mutex=0x55a2689cefb0, cond=0x55a2689cfc70) at pthread_cond_wait.c:677
#3  __pthread_cond_clockwait (cond=0x55a2689cfc70, mutex=0x55a2689cefb0, 
clockid=1316990384, abstime=0x7f414e7faeb0) at pthread_cond_wait.c:665
#4  0x55a2652aee4d in PERIPHERALS::CPeripheralBus::Process() ()
#5  0x55a264cc2bc5 in CThread::Action() ()
#6  0x55a264cc479e in ?? ()
#7  0x55a264cc4c29 in ?? ()
#8  0x7f4196054ed0 in ?? () from /lib/x86_

Bug#978107: [Pkg-xmpp-devel] Bug#978107: Bug#978107: gajim: Crashes when video preview is turned off in settings dialog window

[Boris Pek]

Hi,

>> Too bad. Still no problem for me.

I cannot reproduce this problem in my system in KDE and Fluxbox too.

But I have much more packages installed into the system than basic system +
gajim* packages + recommendations. And unfortunately I do not have enough free
space for one more guest environment in VirtualBox for tests...

Martin, could you try to reproduce this bug in a clean environment?

> I can reproduce in a virtual machine without any camera running sid also on
> amd64. I used GNOME Boxes with QEMU on KVM, emulating a QXL video card.

Do you use GNOME Shell launched above Wayland or X11 in your main system?

If you use Wayland than could you test the X11 session please? It should not
take too much time...

Best wishes,
Boris

Bug#979108: memtool: 64 bit memory reads may be split on 32 bit systems

[Uwe Kleine-König]

Hello Gergely,

On 1/2/21 8:34 PM, Gergely Peli wrote:

Package: memtool
Severity: normal
Tags: upstream patch

Hello,

I tried memtool on a 32 bit ARM system, and the supposedly 64 bit reads
with the "-q" option are done by 2 separate 32 bit "ldr" instructions.
Adding a volatile qualifier to the pointers accessing the memory could
convince gcc to generate a single "ldrd" instruction instead, which uses
a 64 bit memory transfer. See below a proposed patch. Adding volatile to all
4 cases may be an overkill, but can't hurt. Cheers,

Gergely Peli



--- memtool-2016.10.0.orig/memtool.c
+++ memtool-2016.10.0/memtool.c
@@ -152,24 +152,24 @@ static int memory_display(const void *ad
 for (i = 0; i < linebytes; i += width) {
 if (width == 8) {
 uint64_t res;
-   res = (*uqp++ = *((uint64_t *)addr));
+   res = (*uqp++ = *((volatile uint64_t *)addr));


In this code location it doesn't matter if two ldrs instead of a single 
ldrd is used. This is only the code printing the data from the buffer 
that holds the read data. If memtools behaves wrong the problem is 
likely in mmap_read.


This makes me wonder how you found the bug and how you tested that your 
patch indeed fixes it.


Best regards
Uwe



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979366: openvswitch-common: openswitch-common uninstallable on non-amd64

[Andrej Shadura]

Package: openvswitch-common
Version: 2.13.0+dfsg1-13
Severity: grave

Dear Maintainer,

openswitch-common hardcodes x86_64-linux-gnu in its postinst, making it
uninstallable on non-amd64:

Setting up openvswitch-common (2.13.0+dfsg1-14) ...
update-alternatives: using /usr/lib/openvswitch-common/ovs-vswitchd to provide 
/usr/sbin/ovs-vswitchd (ovs-vswitchd) in auto mode
update-alternatives: error: error creating symbolic link 
'/usr/lib/x86_64-linux-gnu/libopenvswitch-2.13.so.0.0.0.dpkg-tmp': No such file 
or directory
dpkg: error processing package openvswitch-common (--configure):
 installed openvswitch-common package post-installation script subprocess 
returned error exit status 2

-- 
Cheers,
  Andrej

Bug#978556: intermediate status report

[Geert Stappers]

The recieving end said

Source-only uploads to NEW are not allowed



My next attempt will be thursday (evening (CET))

Bug#977411: gdm does not recognize keyboard input

[Phillip Susi]

I just made a clean install in a new vm from 10.7 netinst, then did a
dist-upgrade, and once again, keyboard input is not being recognized.

This may be a release-critical issue?

My host system is Ubuntu 18.04 running Xen 4.9.2, and I'm using vnc to
access the virtual console.

Bug#979365: ITP: sass-stylesheets-sass-extras -- useful utilities for working with Sass

[Jonas Smedegaard]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: sass-stylesheets-sass-extras
  Version : 1.0.0
  Upstream Author : Sindre Sorhus 
* URL : https://sindresorhus.com/sass-extras/
* License : Expat
  Programming Lang: Sass
  Description : useful utilities for working with Sass

 sass-extras is a collection of Sass functions
 for using SVG inline, generating random colors,
 system font stack, PRNG, and more...
 .
 Sass makes CSS fun again.
 Sass is an extension of CSS3,
 adding nested rules, variables, mixins, selector inheritance, and more.
 .
 Sass can be encoded in either of two formats - SASS and SCSS.
 These mixins are provided in SCSS format.

This package will be maintained in the Sass team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl/0zNsACgkQLHwxRsGg
ASES5w/9GJy3bx4plJ0b9UiqgX1fPUFPiAbg34P9a1kBtWk2myoaIcxkgIpf38xN
zsEbh9QgS0tV6uDwPmJdNcli2VRtGF88n+XknizP/mn+/nBt4HQq5m3iV5P1HHzE
7JRdy8IT9W23aZTaRUlj1Ccso8DSLWM8wcnH5Cq+WkxeMXZ3dry89uqwuFzZpIB+
y6wLQ0+2v3vnLdUfYXthsXdafZlLHgQxWRl1TYsuoPXxrcO5Boj5agZLbQ8STZWc
gz/oWNTflo21/AApFm+7oalQuG3Rebr6OdGVk6vk02pphNBWs8YHeStLUXLbhXTv
H5RD/am998FnnlwxYl1kNhudgWUk/XO2XxuginnWBByp7Ocd0RpNVxEwsbPIe/0a
tNJhMQOVxaPK1nqA6QXp9jLt09OmfVYwqwlZBmnwCDd+4HTlOVCGS5USjQyM03Q5
U+ys/HEeW7nY6fHCuYpOtsmL3Xgw/tBalHDRqOuIHUxyIX/tYaTi7TyygBs0kJWV
hQZIg0kqfZ62uJG/+Yog7nOsRcS/zMDntIdg+ivCEfx9wUoj3hRrZW7+qKBOyfgj
pAr3kQxtr1RkIQE6n+iZBQPApeegxiyk+1EUUV6TPGeVOoqxpk1GYq6OmCwFPojH
nGeKkPO5yOCX6rfxYxNY3so7tRnyni9rYdp+9BHcc9OEH4pj3lg=
=dhwy
-END PGP SIGNATURE-

Bug#979193: Bullseye Alpha 3 cannot configure HTTP mirror with preseed

[jhcha54008]

X-Debbugs-CC: Samuel Thibault 

Hi,

This looks like bug #879151 in apt-setup - or rather like 
a regression caused by a leftover of a previous attempt
to solve it.

Would the patch of [1] be of any help - if some support of 
debian-ports architectures in apt-setup is still wanted ? 

I hope it will help !

Regards,
JH Chatenet

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

Bug#979364: nodejs: CVE-2020-8265 CVE-2020-8287

[Salvatore Bonaccorso]

Source: nodejs
Version: 12.19.0~dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 10.21.0~dfsg-1~deb10u1
Control: found -1 14.13.0~dfsg-1

Hi,

The following vulnerabilities were published for nodejs.

CVE-2020-8265[0]:
| nodejs: use-after-free in TLSWrap

CVE-2020-8287[1]:
| nodejs: HTTP Request Smuggling

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8265
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8265
[1] https://security-tracker.debian.org/tracker/CVE-2020-8287
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8287

Regards,
Salvatore

Bug#979306: QVTKOpenGLWidget.h: No such file or directory

[Anton Gladky]

Hi Drew,

could you please push the version of avogadrolibs which your working on
into the git? So I could probably test it against newer vtk9. Thanks.

Regards

Anton

Am Di., 5. Jan. 2021 um 05:09 Uhr schrieb Drew Parsons :
>
> Package: libvtk9-qt-dev
> Version: 9.0.1+dfsg1-6
> Severity: normal
>
> This is another report from trying to build avogadrolibs against VTK9
> (Build-Depends: libvtk9-qt-dev), following on from Bug#979073
> (thanks for configuring RenderingContextOpenGL2).

Bug#979355: src:sphinx-rtd-theme: embeds several Sass libraries that should be packaged separately

[Jonas Smedegaard]

Quoting Dmitry Shachnev (2021-01-05 20:12:29)
> On Tue, Jan 05, 2021 at 07:37:06PM +0100, Jonas Smedegaard wrote:
> > > For Neat, sphinx-rtd-theme currently uses an ancient version, 
> > > 1.9.1 (released in 2018) while the latest upstream is 4.0.0.
> >
> > Assuming you are pointing this out because your package cannot 
> > possibly use the newer release, then effectively we are talking 
> > about a fork of Neat.
> 
> Yes, it cannot use the newer release because Wyrm is incompatible with 
> it:
> 
> https://github.com/snide/wyrm/issues/12

That one concretely seems easy fixable - but that's easy to say, I know
:-)


> > Who is caring for bugs in that fork - you? Upstream of 
> > sphinx-rtd-theme?
> 
> According to this comment, upstream of sphinx-rtd-theme are going to 
> work-around bugs in their code:
> 
> https://github.com/readthedocs/sphinx_rtd_theme/issues/544#issuecomment-409521422
> 
> > Are you certain noone else may need this old fork as well, since you 
> > chose to embed it instead of packaging it as a proper package in 
> > Debian?
> 
> I don’t see any reason for other packages to use this old stuff 
> instead of something modern and supported.
> 
> The Wyrm website mentions two users of that library: sphinx-rtd-theme 
> and https://github.com/webhook/webhook, which is also a dead project 
> and not packaged in Debian (Debian’s webhook package is a different 
> thing).

Thanks for those details.  Quite helpful to aid in curating which 
libraries to include with Debian.


> > > I don’t think it makes sense to package old versions of software 
> > > if they will be used only by sphinx-rtd-theme. And with new 
> > > versions it just won’t build.
> >
> > Please file an RFP for wyrm cc the Sass team, and mention the need 
> > for older Sass code.  Might make sense to either look into either 
> > patching sphinx-rtd-theme to work with newer Sass code or if 
> > unfeasable then ship both newest and some older snapshot in a 
> > sass-stylesheets.wyrm package.
> 
> RFP filed: https://bugs.debian.org/979358.

Thanks!


> I don’t think there is need for a separate RFP for neat, because if 
> someone looks at packaging wyrm, they will have to take care of neat 
> too and figure out the exact version to use.

Neat is developed by same authors as Bourbon (if I recall correctly), 
and has use cases also independently of wyrm.


> > Nice - that is helpful to mention in an RFP, as an entry into assessing
> > feasability of changing sphinx-rtd-theme to work with newer Sass code.
> 
> This is definitely something that should be done by upstream, not by us in
> Debian. (Upstream does not even always accept pull requests, e.g. #432 does
> not have any reply for a long time.)

No, not definitely (only possibly): Even if upstream don't care, Debian 
package carrying a patch might be beneficial compared to maintaining old 
Sass code (and certainly better than _embedding_ old Sass code).


> Anyway, I left a reference to our discussion here in my RFP.

Thanks.  For the RFP, for the details shared here, and for maintaining 
sphinx_rtd_theme - I use that package myself, via mkdocs.


 - 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#979363: dovecot: CVE-2020-24386 CVE-2020-25275

[Salvatore Bonaccorso]

Source: dovecot
Version: 1:2.3.11.3+dfsg1-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 1:2.3.4.1-5+deb10u4
Control: fixed -1 1:2.3.4.1-5+deb10u5
Control: found -1 1:2.2.27-3+deb9u6
Control: fixed -1 1:2.2.27-3+deb9u7

Hi,

The following vulnerabilities were published for dovecot.

CVE-2020-24386[0]:
| An issue was discovered in Dovecot before 2.3.13. By using IMAP IDLE,
| an authenticated attacker can trigger unhibernation via attacker-
| controlled parameters, leading to access to other users' email
| messages (and path disclosure).


CVE-2020-25275[1]:
| Dovecot before 2.3.13 has Improper Input Validation in lda, lmtp, and
| imap, leading to an application crash via a crafted email message with
| certain choices for ten thousand MIME parts.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-24386
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24386
[1] https://security-tracker.debian.org/tracker/CVE-2020-25275
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-25275

Regards,
Salvatore

Bug#979362: keepass2: desktop manager freezes when double click by url field

[Aleksandr]

Package: keepass2
Version: 2.41+dfsg-1
Severity: important

Dear Maintainer,

when you do double click by url filed in keepass and it's not url for example
ip address - you take error window and desktop manager freezes.

you can back to the work by pressing alt+f4.

In my vision it shoudn't be so.



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

Kernel: Linux 4.19.0-12-amd64 (SMP w/2 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.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 keepass2 depends on:
ii  libgcrypt20  1.8.4-5
ii  libmono-corlib4.5-cil5.18.0.240+dfsg-3
ii  libmono-system-drawing4.0-cil5.18.0.240+dfsg-3
ii  libmono-system-security4.0-cil   5.18.0.240+dfsg-3
ii  libmono-system-windows-forms4.0-cil  5.18.0.240+dfsg-3
ii  libmono-system-xml4.0-cil5.18.0.240+dfsg-3
ii  libmono-system4.0-cil5.18.0.240+dfsg-3
ii  libx11-6 2:1.6.7-1+deb10u1
ii  mono-runtime 5.18.0.240+dfsg-3

Versions of packages keepass2 recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-1

Versions of packages keepass2 suggests:
pn  keepass2-doc  
pn  mono-dmcs 
pn  xdotool   

-- no debconf information

Bug#977450: RM: radare2-cutter -- ROM; Removal of critical dependency (radare2)

[Sebastian Reichel]

Hi,

> As radare2 has been discontinued in Debian due to packaging
> problems radare2-cutter should also be removed from Debian.

I think you misunderstood something (or maybe it is me :)).

It is true, that radare2 has been removed from Debian stable. It has
not been removed from Debian, though. In fact I uploaded version
5.0 to unstable yesterday and it got accepted by an FTP master today.
But I do plan to keep #950372 open, so that r2 will not transition to
testing/stable anymore.

Thanks,

-- Sebastian


signature.asc
Description: PGP signature

Bug#979348: kalarm: Kalarm requires pulseaudio - no direct ALSA support

[ael]

Package: kalarm
Version: 4:20.08.3-1
Severity: wishlist

I could not get kalarm to play audio with pulse audio absent.
Even with apulse, it did not work, except, perhaps on one occasion
which I have not been able to reproduce.

It needs proper ALSA support.


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

Kernel: Linux 5.9.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kalarm depends on:
ii  akonadi-server4:20.08.3-1
ii  kdepim-runtime4:20.08.3-1
ii  kio   5.77.0-3
ii  libc6 2.31-6
ii  libgcc-s1 10.2.1-3
ii  libkf5akonadicontact5 [libkf5akonadicontact5-20.08]   4:20.08.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-20.08] 4:20.08.3-1
ii  libkf5akonadimime5 [libkf5akonadimime5-20.08] 4:20.08.3-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08]   4:20.08.3-1
ii  libkf5alarmcalendar5abi1 [libkf5alarmcalendar5-20.08] 4:20.08.3-1
ii  libkf5authcore5   5.77.0-3
ii  libkf5calendarcore5abi2   5:5.77.0-2
ii  libkf5calendarutils5 [libkf5calendarutils5-20.08] 4:20.08.3-1
ii  libkf5codecs5 5.77.0-2
ii  libkf5completion5 5.77.0-4
ii  libkf5configcore5 5.77.0-2
ii  libkf5configgui5  5.77.0-2
ii  libkf5configwidgets5  5.77.0-2
ii  libkf5contacts5   5:5.77.0-2
ii  libkf5coreaddons5 5.77.0-2
ii  libkf5crash5  5.77.0-2
ii  libkf5dbusaddons5 5.77.0-2
ii  libkf5globalaccel-bin 5.77.0-3
ii  libkf5globalaccel55.77.0-3
ii  libkf5guiaddons5  5.77.0-4
ii  libkf5holidays5   1:5.77.0-2
ii  libkf5i18n5   5.77.0-2
ii  libkf5identitymanagement5 [libkf5identitymanagement5-20.08]   20.08.3-1
ii  libkf5itemmodels5 5.77.0-2
ii  libkf5jobwidgets5 5.77.0-2
ii  libkf5kiocore55.77.0-3
ii  libkf5kiofilewidgets5 5.77.0-3
ii  libkf5kiowidgets5 5.77.0-3
ii  libkf5mailtransport5 [libkf5mailtransport5-20.08] 20.08.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-20.  20.08.3-1
ii  libkf5mime5abi1 [libkf5mime5-20.08]   20.08.3-1
ii  libkf5notifications5  5.77.0-2
ii  libkf5pimcommon5abi2 [libkf5pimcommon5-20.08] 4:20.08.3-1
ii  libkf5pimtextedit5abi2 [libkf5pimtextedit5-20.08] 20.08.3-1
ii  libkf5textwidgets55.77.0-2
ii  libkf5widgetsaddons5  5.77.0-4
ii  libkf5windowsystem5   5.77.0-2
ii  libkf5xmlgui5 5.77.0-2
ii  libphonon4qt5-4   4:4.11.1-3
ii  libqt5core5a  5.15.2+dfsg-2
ii  libqt5dbus5   5.15.2+dfsg-2
ii  libqt5gui55.15.2+dfsg-2
ii  libqt5network55.15.2+dfsg-2
ii  libqt5widgets55.15.2+dfsg-2
ii  libqt5x11extras5  5.15.2-2
ii  libstdc++610.2.1-3
ii  perl  5.32.0-6
ii  phonon4qt54:4.11.1-3

kalarm recommends no packages.

kalarm suggests no packages.

-- no debconf information

Bug#967123: debian-installer: Unversioned Python removal in sid/bullseye

[Samuel Thibault]

Cyril Brulebois, le mar. 05 janv. 2021 20:28:52 +0100, a ecrit:
> Matthias Klose  (2020-08-04):
> > Your package either build-depends, depends on one of those packages.
> 
> I couldn't find any hit on “python” (that would be relevant) in current
> git, current version, or the version you filed this bug report against.

I guess the report was based on e.g.

https://buildd.debian.org/status/fetch.php?pkg=debian-installer&arch=amd64&ver=20200314&stamp=1584184547&raw=0

which shows python getting installed for the build.


But

https://buildd.debian.org/status/fetch.php?pkg=debian-installer&arch=amd64&ver=20201202&stamp=1606924683&raw=0

doesn't show it, so I guess it was a transitive dep that got fixed.

Samuel

Bug#979322: libcacard: missing runtime glib2.0 dependency?

[Michael Tokarev]

05.01.2021 13:44, Gianfranco Costamagna wrote:
...

after installing it looks still missing
Package 'libpcsclite', required by 'libcacard', not found


Oh. I missed this one. Will do another upload.

/mjt

Bug#777291: gpm should provides systemd services

[Moritz Mühlenhoff]

tags 777291 patch
thx

Attached is a patch against current sid which adds a systemd unit
for gpm. I've been using it for a few days on my system without
any issues.

Cheers,
Moritz

diff -Naur gpm-1.20.7.orig/debian/gpm.service gpm-1.20.7/debian/gpm.service
--- gpm-1.20.7.orig/debian/gpm.service	1970-01-01 01:00:00.0 +0100
+++ gpm-1.20.7/debian/gpm.service	2021-01-01 20:11:49.684963093 +0100
@@ -0,0 +1,11 @@
+[Unit]
+Description=Console Mouse manager
+ConditionPathExists=/dev/input/mice
+
+[Service]
+ExecStart=/usr/sbin/gpm -m /dev/input/mice -t exps2
+Type=forking
+PIDFile=/run/gpm.pid
+
+[Install]
+WantedBy=multi-user.target

Bug#890472: ITP: shaderc -- A collection of tools, libraries and tests for shader compilation

[Witold Baryluk]

Hi,

is there some progress on this? I think libshaderc (and glslc)
would be nice to use in mpv, as well for general Vulkan
developement.

Sebastian Dröge mentioned that shaderc is required for Gtk4,
but I don't think this is true. I checked the Gtk4 sources,
and it uses Vulkan, but doesn't use shaderc. In fact Gtk4
is already in experimental with Vulkan support enabled.
No shaderc required.

Still, it would be really useful to have shaderc in Debian,
for other things.

Regards,
Witold

Bug#979361: tpm2-tss: FTBFS: missing BD on dh-pyhon

[Sebastian Ramacher]

Source: tpm2-pkcs11
Version: 1.5.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org

tpm2-pkcs11 fails to build:
|  debian/rules clean
| dh clean --exclude=.la --exclude=.pc --with python3
| dh: error: unable to load addon python3: Can't locate 
Debian/Debhelper/Sequence/python3.pm in @INC (you may need to install the 
Debian::Debhelper::Sequence::python3 module) (@INC contains: /etc/perl 
/usr/local/lib/i386-linux-gnu/perl/5.32.0 /usr/local/share/perl/5.32.0 
/usr/lib/i386-linux-gnu/perl5/5.32 /usr/share/perl5 
/usr/lib/i386-linux-gnu/perl-base /usr/lib/i386-linux-gnu/perl/5.32 
/usr/share/perl/5.32 /usr/local/lib/site_perl) at (eval 12) line 1.
| BEGIN failed--compilation aborted at (eval 12) line 1.

See
https://buildd.debian.org/status/fetch.php?pkg=tpm2-pkcs11&arch=i386&ver=1.5.0-1&stamp=1609856984&raw=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#979355: src:sphinx-rtd-theme: embeds several Sass libraries that should be packaged separately

[Dmitry Shachnev]

On Tue, Jan 05, 2021 at 07:37:06PM +0100, Jonas Smedegaard wrote:
> > For Neat, sphinx-rtd-theme currently uses an ancient version, 1.9.1
> > (released in 2018) while the latest upstream is 4.0.0.
>
> Assuming you are pointing this out because your package cannot possibly
> use the newer release, then effectively we are talking about a fork of
> Neat.

Yes, it cannot use the newer release because Wyrm is incompatible with it:

https://github.com/snide/wyrm/issues/12

> Who is caring for bugs in that fork - you? Upstream of sphinx-rtd-theme?

According to this comment, upstream of sphinx-rtd-theme are going to
work-around bugs in their code:

https://github.com/readthedocs/sphinx_rtd_theme/issues/544#issuecomment-409521422

> Are you certain noone else may need this old fork as well, since you chose
> to embed it instead of packaging it as a proper package in Debian?

I don’t see any reason for other packages to use this old stuff instead of
something modern and supported.

The Wyrm website mentions two users of that library: sphinx-rtd-theme
and https://github.com/webhook/webhook, which is also a dead project and
not packaged in Debian (Debian’s webhook package is a different thing).

> > I don’t think it makes sense to package old versions of software if
> > they will be used only by sphinx-rtd-theme. And with new versions it
> > just won’t build.
>
> Please file an RFP for wyrm cc the Sass team, and mention the need for
> older Sass code.  Might make sense to either look into either patching
> sphinx-rtd-theme to work with newer Sass code or if unfeasable then ship
> both newest and some older snapshot in a sass-stylesheets.wyrm package.

RFP filed: https://bugs.debian.org/979358.

I don’t think there is need for a separate RFP for neat, because if someone
looks at packaging wyrm, they will have to take care of neat too and figure
out the exact version to use.

> Nice - that is helpful to mention in an RFP, as an entry into assessing
> feasability of changing sphinx-rtd-theme to work with newer Sass code.

This is definitely something that should be done by upstream, not by us in
Debian. (Upstream does not even always accept pull requests, e.g. #432 does
not have any reply for a long time.)

Anyway, I left a reference to our discussion here in my RFP.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#979279: sdlgfx: Please mark -doc package Multi-Arch: foreign

[Steve Langasek]

Package: sdlgfx
Version: 2.0.25-11.1
Followup-For: Bug #979279
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu hirsute ubuntu-patch

Apologies, it seems an additional change is needed in order to make sdlgfx
successfully pass its tests in a cross environment.  Please see attached.

This may want adjusting to work in environments where $DEB_* variables have
not been set, but with this change the sdlgfx tests did pass on all
architectures in Ubuntu.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru sdlgfx-2.0.25/debian/tests/compile-libsdl-gfx-test0 
sdlgfx-2.0.25/debian/tests/compile-libsdl-gfx-test0
--- sdlgfx-2.0.25/debian/tests/compile-libsdl-gfx-test0 2017-10-28 
13:51:09.0 -0700
+++ sdlgfx-2.0.25/debian/tests/compile-libsdl-gfx-test0 2021-01-04 
17:20:06.0 -0800
@@ -18,7 +18,8 @@
 tar xvf $EXAMPLES -C .
 cd examples
 ./autogen.sh
-./configure
+./configure --host=$DEB_HOST_GNU_TYPE
+
 make
 echo "build: OK"
 

Bug#979360: GUI: "Help > User manual" gives "Can't access file: /usr/share/recoll/doc/usermanual.html"

[xiscu]

Package: recoll
Version: 1.27.12-1
Severity: normal

Dear Maintainer,
the user manuall is not directly reacheable ober the Qt-GUI "Help > User 
manual" menue.
A search with find returns "/usr/share/doc/recoll/usermanual.html" for the 
documentation.

Please consider adjusting the path on the GUI.

Thanks in advance,
xiscu

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

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

Versions of packages recoll depends on:
ii  recollcmd  1.27.12-1
ii  recollgui  1.27.12-1

recoll recommends no packages.

recoll suggests no packages.

-- no debconf information

Bug#946451: spyder: work on new upstream release

[Julian Gilbey]

On Tue, Jan 05, 2021 at 09:47:51AM +, Jitse Niesen wrote:
> On 04/01/2021 22:10, Julian Gilbey wrote:
> >
> > Then there are only 6 other failures; again, I haven't investigated
> > further.  I don't know what "xfailures" are.
> 
> This stands for expected failures; they are tests that fail on our upstream
> testing system due to a bug that we know about but have not yet fixed. So
> there is no need for you to worry about them.
> 
> As you must have realized, the automatic tests are not very robust. Our
> experience is that they do occasionally fail due to reasons that we can't
> figure out. So you're probably right not investigating further.
> 
> Good work!
> Jitse

Thanks Jitse!

   Julian

Bug#979359: ITP: golang-github-prometheus-prom2json -- tool to scrape a Prometheus client and dump the result as JSON

[Cyril Brulebois]

Package: wnpp
Severity: wishlist
Owner: Cyril Brulebois 

* Package name: golang-github-prometheus-prom2json
  Version : 1.3.0-1
  Upstream Author : Prometheus
* URL : https://github.com/prometheus/prom2json
* License : Apache-2.0
  Programming Lang: Go
  Description : tool to scrape a Prometheus client and dump the result as 
JSON (library)

 Since the deprecation of the JSON exposition format, looking into
 metrics exposed by Prometheus can be a challenge, as one would
 usually need to interact with the Prometheus server and its protocol
 buffer format. Since JSON is a wildly-supported format, prom2json was
 designed to scrape a Prometheus client in protocol buffer or text
 format, in order to make the results available in JSON format.


Part of the crowdsec packaging effort:
  https://lists.debian.org/debian-go/2020/12/msg00019.html


This package comes with a prom2json command (skipped for now) that looks
like it could be useful on its own, but I don't know the Prometheus
ecosystem well enough to judge its usefulness. If anyone would like
another binary package to be added, shipping this command, this can
definitely be considered.


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


signature.asc
Description: PGP signature

Bug#979353: rmatrix: Please package 1.3-2 to file errors

[Dirk Eddelbuettel]

On 6 January 2021 at 05:33, Peter Hickey wrote:
| Thanks. I've been camping since Christmas without laptop/reception but I'll
| be back next week and deal with these issues

Ah the 'seasonal' advantages of being down under!  Lovely.  Take your time;
we have to wait on Martin Maechler and CRAN to come to terms with a new
Matrix release first.

Dirk

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

Bug#979358: RFP: wyrm -- Handy starter SASS for bourbon / neat projects

[Dmitry Shachnev]

Package: wnpp
Severity: wishlist
Control: block 979355 by -1

* Package name: wyrm
  Version : 1.0.9
  Upstream Author : Dave Snider 
* URL : https://github.com/snide/wyrm
* License : MIT
  Programming Lang: SASS
  Description : Handy starter SASS for bourbon / neat projects

Please see the discussion in bug #979355 for the background of why I am
requesting this.

Wyrm is a small library of Bourbon powered SASS files meant for use in
minimalistic Document and Form heavy sites. It was primarily built for Webhook
but can also be found in use on Read the Docs sphinx theme among other places. 

Wyrm is not maintained upstream anymore, but the Read the Docs theme is still
using it.

Wyrm used to have a website, but currently it is available only via the
Internet Archive:

https://web.archive.org/web/20181226045936/http://wyrmsass.org/

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#977604: smarty3: broken internal parsetree code

[James Dietrich]

After encountering this problem today, what worked for me was to download 
v3.1.36 from GitHub and use that directly, instead of using the Debian package.

So, I wonder, is the problem in the Debian packaging somehow?

Bug#979353: rmatrix: Please package 1.3-2 to file errors

[Dirk Eddelbuettel]

On 5 January 2021 at 19:20, Michael R. Crusoe wrote:
| On Tue, 5 Jan 2021 at 19:12, Dirk Eddelbuettel  wrote:
| 
| > On 5 January 2021 at 18:41, Michael R. Crusoe wrote:
| >
| 
| 
| > | r-cran-matrix 1.3-0-1 causes a bug that is evidently fixed in version
| > | 1.3-2
| > |
| > 
https://github.com/PeteHaitch/DelayedMatrixStats/issues/70#issuecomment-753416812
| > |
| > | Could you consider updating the package to this newer version?
| >
| > Yes. I myself as upstream author of RcppArmadillo am affected by a change
| > in
| > Matrix 1.3-0, and have contacted its author / been contacted back.
| >
| > When I last checked this morning, Matrix 1.3-0 was still under review at
| > CRAN's incoming directory (a little like our NEW queue, and you can look at
| > it).  So whoever told you 1.3-2 was out (Hi, Pete!) was a little
| > overeager. AFAIK it is not yet on CRAN but shown as 'Archived' meaning CRAN
| > maintainers took a dimmer view of it than its authors.
| >
| 
| Ah, I saw 1.3-2 over at https://r-forge.r-project.org/R/?group_id=61 :-)

Yes, good point. We generally have Github (as well as the older R-Forge). In
case of a dire need I could make a pre-CRAN release but experience taught us
it is better to stick with CRAN.
 
| > I generally debianize CRAN packages the day of their CRAN inclusion and
| > run a
| > cron'ed mirror of CRAN updates (google 'eddelbuettel cranberriesfeed' or
| > look
| > at Twitter handle @CRANberriesFeed).
| >
| 
| Great! Looking forward to this getting fixed.
| 
| Thanks for your maintenance of this package.

My pleasure!

Dirk

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

Bug#978931: gssproxy: CVE-2020-12658

[Robbie Harwood (frozencemetery)]

Package: gssproxy
Followup-For: Bug #978931
X-Debbugs-Cc: rharw...@club.cc.cmu.edu
Control: severity -1 minor
Control: close -1

Hi,

I (upstream and downstream maintainer) do not believe this is CVE-worthy and
have filed dispute claim with Mitre.

The code change in question only happens in a shutdown path.  So even a DoS
here makes no sense as a concept - gssproxy is shutting down already.

If we receive more information that updates that understanding, I'm happy to
adjust accordingly, but upstream was not contacted or involved in any way in
this.

Thanks,
--Robbie

Bug#978931: gssproxy: CVE-2020-12658

[rharwood]

Package: gssproxy
Followup-For: Bug #978931
Control: tags -1 - security

Bug#979355: src:sphinx-rtd-theme: embeds several Sass libraries that should be packaged separately

[Jonas Smedegaard]

Hi Dmitry,

Quoting Dmitry Shachnev (2021-01-05 19:02:39)
> On Tue, Jan 05, 2021 at 06:42:45PM +0100, Jonas Smedegaard wrote:
> > Source package sphinx-rtd-theme embeds Sass libraries Bourbon, Neat, 
> > and wyrm.
> >
> > Debian Policy §4.13 says:
> >
> > > Some software packages include in their distribution convenience 
> > > copies of code from other software packages, generally so that 
> > > users compiling from source don’t have to download multiple 
> > > packages. Debian packages should not make use of these convenience 
> > > copies unless the included package is explicitly intended to be 
> > > used in this way. If the included code is already in the Debian 
> > > archive in the form of a library, the Debian packaging should 
> > > ensure that binary packages reference the libraries already in 
> > > Debian and the convenience copy is not used. If the included code 
> > > is not already in Debian, it should be packaged separately as a 
> > > prerequisite if possible.
> >
> > Let me repeat the suggestion at https://bugs.debian.org/865306#30 
> > from 3½ years ago here:
> >
> > File RFPs and cc the SASS team: 
> > pkg-sass-de...@lists.alioth.debian.org
> 
> For Bourbon, there is already an RFP: https://bugs.debian.org/892811.

Yes.  W. Martin Borgert seems to care about having that Sass library 
properly packaged as system-shared library, reusable across packages, 
available for users as well, and properly maintained independenty on 
converse.js that he is/was packaging.  I.e. about Policy compliance.

What I suggest to do in cases where a bugreport is filed already: Post 
to the bugreport so that it is known that more users are in need of that 
RFPed package.  Most elegant is to "block" like W. Martin Borgert did, 
but a plain human email is helpful too.  You did that now: Thanks!


> For Neat, sphinx-rtd-theme currently uses an ancient version, 1.9.1 
> (released in 2018) while the latest upstream is 4.0.0.

Assuming you are pointing this out because your package cannot possibly 
use the newer release, then effectively we are talking about a fork of 
Neat.  Who is caring for bugs in that fork - you? Upstream of 
sphinx-rtd-theme?  Are you certain noone else may need this old fork as 
well, since you chose to embed it instead of packaging it as a proper 
package in Debian?


> For wyrm, it uses the latest version but wyrm itself is dead and 
> unmaintained for 6 years (since January 2015).

Although dead it is evidently still usable and should therefore be 
packaged as a system-shared library for all the reasons described above.


> I don’t think it makes sense to package old versions of software if 
> they will be used only by sphinx-rtd-theme. And with new versions it 
> just won’t build.

Please file an RFP for wyrm cc the Sass team, and mention the need for 
older Sass code.  Might make sense to either look into either patching 
sphinx-rtd-theme to work with newer Sass code or if unfeasable then ship 
both newest and some older snapshot in a sass-stylesheets.wyrm package.


> There is an upstream bug report requesting to move from wyrm to 
> something else: 
> https://github.com/readthedocs/sphinx_rtd_theme/issues/544.

Nice - that is helpful to mention in an RFP, as an entry into assessing 
feasability of changing sphinx-rtd-theme to work with newer Sass code.


> Please also note that I am trying to do my best rebuilding all CSS 
> files from SASS source,

Great!


> so this package meets DFSG and Policy “must” criteria, it just fails 
> to meet the “should, if possible” criterion.

Yes, I am aware - hence the severity of this bugreport.


 - 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#979353: rmatrix: Please package 1.3-2 to file errors

[Peter Hickey]

Thanks. I've been camping since Christmas without laptop/reception but I'll
be back next week and deal with these issues

On Wed, 6 Jan 2021, 5:20 am Michael R. Crusoe,  wrote:

>
>
> On Tue, 5 Jan 2021 at 19:12, Dirk Eddelbuettel  wrote:
>
>> On 5 January 2021 at 18:41, Michael R. Crusoe wrote:
>>
>
>
>> | r-cran-matrix 1.3-0-1 causes a bug that is evidently fixed in version
>> | 1.3-2
>> |
>> https://github.com/PeteHaitch/DelayedMatrixStats/issues/70#issuecomment-753416812
>> |
>> | Could you consider updating the package to this newer version?
>>
>> Yes. I myself as upstream author of RcppArmadillo am affected by a change
>> in
>> Matrix 1.3-0, and have contacted its author / been contacted back.
>>
>> When I last checked this morning, Matrix 1.3-0 was still under review at
>> CRAN's incoming directory (a little like our NEW queue, and you can look
>> at
>> it).  So whoever told you 1.3-2 was out (Hi, Pete!) was a little
>> overeager. AFAIK it is not yet on CRAN but shown as 'Archived' meaning
>> CRAN
>> maintainers took a dimmer view of it than its authors.
>>
>
> Ah, I saw 1.3-2 over at https://r-forge.r-project.org/R/?group_id=61 :-)
>
>
>> I generally debianize CRAN packages the day of their CRAN inclusion and
>> run a
>> cron'ed mirror of CRAN updates (google 'eddelbuettel cranberriesfeed' or
>> look
>> at Twitter handle @CRANberriesFeed).
>>
>
> Great! Looking forward to this getting fixed.
>
> Thanks for your maintenance of this package.
>

Bug#979353: rmatrix: Please package 1.3-2 to file errors

[Michael R. Crusoe]

On Tue, 5 Jan 2021 at 19:12, Dirk Eddelbuettel  wrote:

> On 5 January 2021 at 18:41, Michael R. Crusoe wrote:
>


> | r-cran-matrix 1.3-0-1 causes a bug that is evidently fixed in version
> | 1.3-2
> |
> https://github.com/PeteHaitch/DelayedMatrixStats/issues/70#issuecomment-753416812
> |
> | Could you consider updating the package to this newer version?
>
> Yes. I myself as upstream author of RcppArmadillo am affected by a change
> in
> Matrix 1.3-0, and have contacted its author / been contacted back.
>
> When I last checked this morning, Matrix 1.3-0 was still under review at
> CRAN's incoming directory (a little like our NEW queue, and you can look at
> it).  So whoever told you 1.3-2 was out (Hi, Pete!) was a little
> overeager. AFAIK it is not yet on CRAN but shown as 'Archived' meaning CRAN
> maintainers took a dimmer view of it than its authors.
>

Ah, I saw 1.3-2 over at https://r-forge.r-project.org/R/?group_id=61 :-)


> I generally debianize CRAN packages the day of their CRAN inclusion and
> run a
> cron'ed mirror of CRAN updates (google 'eddelbuettel cranberriesfeed' or
> look
> at Twitter handle @CRANberriesFeed).
>

Great! Looking forward to this getting fixed.

Thanks for your maintenance of this package.

Bug#979357: src:libloki: invalid maintainer address

[Ansgar]

Source: libloki
Version: 0.1.7-3
Severity: serious
Tags: bullseye sid
X-Debbugs-Cc: Holger Levsen 

The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Tue, 05 Jan 2021 17:50:43 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  p...@baranov.fi
Unrouteable address
Reporting-MTA: dns; mailly.debian.org

Action: failed
Final-Recipient: rfc822;petr@baranov.fi
Status: 5.0.0

Bug#979353: rmatrix: Please package 1.3-2 to file errors

[Dirk Eddelbuettel]

On 5 January 2021 at 18:41, Michael R. Crusoe wrote:
| Source: rmatrix
| Version: 1.3-0-1
| Severity: important
| 
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA512
| 
| Hello,
| 
| r-cran-matrix 1.3-0-1 causes a bug that is evidently fixed in version
| 1.3-2
| 
https://github.com/PeteHaitch/DelayedMatrixStats/issues/70#issuecomment-753416812
| 
| Could you consider updating the package to this newer version?

Yes. I myself as upstream author of RcppArmadillo am affected by a change in
Matrix 1.3-0, and have contacted its author / been contacted back.

When I last checked this morning, Matrix 1.3-0 was still under review at
CRAN's incoming directory (a little like our NEW queue, and you can look at
it).  So whoever told you 1.3-2 was out (Hi, Pete!) was a little
overeager. AFAIK it is not yet on CRAN but shown as 'Archived' meaning CRAN
maintainers took a dimmer view of it than its authors.

I generally debianize CRAN packages the day of their CRAN inclusion and run a
cron'ed mirror of CRAN updates (google 'eddelbuettel cranberriesfeed' or look
at Twitter handle @CRANberriesFeed).

Dirk
 
| Thanks,
| 
| -BEGIN PGP SIGNATURE-
| 
| iQJGBAEBCgAwFiEEck1gkzcRPHEFUNdHPCZ2P2xn5uIFAl/0pLMSHGNydXNvZUBk
| ZWJpYW4ub3JnAAoJEDwmdj9sZ+biTbAQAKH9c9eei5brx910zPBL2NMuHWU6vULY
| TfxSOF+4nF6LJV5itgej1gMPe1GmsO181fvC8kyo01hrYZS42o7NEBs05KsBsprx
| 3gHph5L3+L76SSfkJutJRcVo1UZigX22qASRzybg7b7jB496bNvSA9WWGnaZ644u
| OJsQ+5Q3zrEhZ0wJ6XW5Lq95mIfZCAAvV4UrKgVCvWVcJOIVrqkvdFuFDH4pWn4a
| SGq7WJbs9n9YrRIeyUpN1CkpPRws/+XDuFYGZgbN895IVs8ExCRaiMI1ae35Dx+8
| 5aFH8g4JIIK+fY4A5la+3TD5ueJHY8Lw/DxcWmE9SQLC+Oa/Fq8YOYNwRP/TzLxf
| A8Q1pWGtqC30tEO+cRiskBbaTUcJKR5cWvKAcL8TWz/yIgNjgVhrnLIpPu+EIAdL
| RG9Y9XPwQJFYcUx92o4p6Issp6+8FZ+T3BRniQ4BgAdZ8GqzmqzcArj518c8ttmh
| GEDNrG8ImNai/b/BaazbNzw8r6awjIcHs5PdQfCgEzurvIM3RHIR/Re/zF6loJRN
| oXD66fZtKEn0zXtF6nZekiMHnkTcyzjoq2q2bIdVawCJIYVr97Pw9Zcr5ItZaKod
| X2LfN/J2qnoQV0w4qQ8Koj2IoYbiWjscCc/ZhD759JXuEJ/znHOUrKK1rbE4WzXi
| oUEj+HXDRKu0
| =LjTy
| -END PGP SIGNATURE-

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

Bug#978564: src:gst-plugins-bad1.0: fails to migrate to testing for too long: dependency is not migrating

[Paul Gevers]

Hi Sebastian,

On 05-01-2021 10:46, Sebastian Dröge wrote:
> On Mon, 28 Dec 2020 18:40:38 +0100 Paul Gevers  wrote:
>>
>> If you believe your package is unable to migrate to testing due to
>> issues beyond your control, don't hesitate to contact the Release Team.
>> In this case, I think it may be wise to upload to
>> testing-proposed-updates and ask for an unblock. Otherwise your two bug
>> fix releases may not make it to bullseye.
> 
> 
> Hi Paul,
> 
> This is solely blocked on srt currently, and the maintainer will have
> to figure out a solution there for the ABI breakage.

Ack. Although, you *could* help them find a solution. RC bugs in key
packages are a shared responsibility in my opinion.

> I could upload a version of gst-plugins-bad1.0 without the SRT plugin
> for the time being so it can migrate in the meantime.

I suggested to upload the current version to tpu. I'll unblock it if no
further changes to what is currently in unstable and if it happens
within a week or two.

> If I do that and srt gets fixed before the bullseye release, will I be
> able to upload a new gst-plugins-bad1.0 version that re-enables the SRT
> plugin and have it migrated?

It depends [1]:
1. if it entails a dropped/re-added binary, it needs to happen before
the Soft Freeze (12-02-2021)
2. if it doesn't involve that, it needs to happen before the Hard Freeze
(12-03-2021).

Paul
[1] https://release.debian.org/bullseye/freeze_policy.html



OpenPGP_signature
Description: OpenPGP digital signature

Bug#979355: src:sphinx-rtd-theme: embeds several Sass libraries that should be packaged separately

[Dmitry Shachnev]

Control: block -1 by 892811

Hi Jonas!

On Tue, Jan 05, 2021 at 06:42:45PM +0100, Jonas Smedegaard wrote:
> Source package sphinx-rtd-theme embeds Sass libraries Bourbon, Neat, and
> wyrm.
>
> Debian Policy §4.13 says:
>
> > Some software packages include in their distribution convenience
> > copies of code from other software packages, generally so that users
> > compiling from source don’t have to download multiple packages. Debian
> > packages should not make use of these convenience copies unless the
> > included package is explicitly intended to be used in this way. If the
> > included code is already in the Debian archive in the form of a
> > library, the Debian packaging should ensure that binary packages
> > reference the libraries already in Debian and the convenience copy is
> > not used. If the included code is not already in Debian, it should be
> > packaged separately as a prerequisite if possible.
>
> Let me repeat the suggestion at https://bugs.debian.org/865306#30 from
> 3½ years ago here:
>
> File RFPs and cc the SASS team: pkg-sass-de...@lists.alioth.debian.org

For Bourbon, there is already an RFP: https://bugs.debian.org/892811.

For Neat, sphinx-rtd-theme currently uses an ancient version, 1.9.1 (released
in 2018) while the latest upstream is 4.0.0.

For wyrm, it uses the latest version but wyrm itself is dead and unmaintained
for 6 years (since January 2015).

I don’t think it makes sense to package old versions of software if they will
be used only by sphinx-rtd-theme. And with new versions it just won’t build.

There is an upstream bug report requesting to move from wyrm to something
else: https://github.com/readthedocs/sphinx_rtd_theme/issues/544.

Please also note that I am trying to do my best rebuilding all CSS files from
SASS source, so this package meets DFSG and Policy “must” criteria, it just
fails to meet the “should, if possible” criterion.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#979327: xalan: FTBFS on i386: architecture confusion

[Sven Mueller]

No worries. Thanks for the quick response.

Am Di., 5. Jan. 2021 um 18:05 Uhr schrieb Bill Blough :

> I had already pushed the initial fix by the time I received this, so I've
> reopened the bug.  I'll address it later this evening.
>