Bug#875827: wx-config does not work when --host is passed

[Olly Betts]

Control: reassign -1 libwxgtk3.0-gtk3-dev/3.0.4+dfsg-1

Reassigning - the GTK2 flavour packages are gone from testing and only
present in unstable due to a handful of untransitioned rdeps.

On Thu, Sep 14, 2017 at 11:03:08PM +0200, Helmut Grohne wrote:
> Package: libwxgtk3.0-dev
> Version: 3.0.3.1+dfsg-1
> Tags: upstream
> Forwarded: https://trac.wxwidgets.org/ticket/12698
> User: helm...@debian.org
> Usertags: rebootstrap
> Control: affects -1 + src:mediainfo
> 
> I figured that mediainfo fails to cross build from source, because it
> does not find wxWidgets. It invokes wx-config as:
> 
> wx-config --host=$DEB_HOST_GNU_TYPE --unicode=yes --static=no base 
> --version
> 
> That fails whereas it works after dropping --host:
> 
> | $ WXDEBUG=1 wx-config --host=powerpc64le-linux-gnu --unicode=yes 
> --static=no base --version
> | 
> |   input parameters  = base
> |   libs parameters   = 
> |   optional-libs parameters  = 
> |   input options = host
> | host = powerpc64le-linux-gnu
> |   yes/no options= unicode static
> | unicode = yes
> | static = no
> |   flag options  = 
> |   output options= version
> | version = yes
> |   query options = 
> | 
> |   prefix   = '/usr'
> |   exec_prefix  = '/usr'
> |   wxconfdir= '/usr/lib/powerpc64le-linux-gnu/wx/config'
> |   m_host   = 'powerpc64le-linux-gnu-?'
> |   m_toolkit= '[^-]+'
> |   m_widgetset  = '(univ)?'
> |   m_chartype   = 'unicode'
> |   m_debugtype  = '(debug|release)'
> |   m_flavour= '(-[^-]+)?'
> |   m_version= '[0-9]+\.[0-9]+'
> |   m_linkage= ''
> |   configmask   = 
> '^powerpc64le-linux-gnu-?-[^-]+(univ)?-unicode-[0-9]+\.[0-9]+(-[^-]+)?$'
> |   this config  = 'gtk2-unicode-3.0'
> | 
> |   must delegate to an alternate config
> |   potential delegates (0):
> | 
> |   Warning: No config found to match: 
> ^powerpc64le-linux-gnu-?-[^-]+(univ)?-unicode-[0-9]+\.[0-9]+(-[^-]+)?$
> |in /usr/lib/powerpc64le-linux-gnu/wx/config
> |   If you require this configuration, please install the desired
> |   library build.  If this is part of an automated configuration
> |   test and no other errors occur, you may safely ignore it.
> |   You may use wx-config --list to see all configs available in
> |   the default prefix.
> | 
> | $ WXDEBUG=1 wx-config  --unicode=yes --static=no base --version
> | 
> |   input parameters  = base
> |   libs parameters   = 
> |   optional-libs parameters  = 
> |   input options = 
> |   yes/no options= unicode static
> | unicode = yes
> | static = no
> |   flag options  = 
> |   output options= version
> | version = yes
> |   query options = 
> | 
> |   prefix   = '/usr'
> |   exec_prefix  = '/usr'
> |   wxconfdir= '/usr/lib/powerpc64le-linux-gnu/wx/config'
> |   m_host   = ''
> |   m_toolkit= '[^-]+'
> |   m_widgetset  = '(univ)?'
> |   m_chartype   = 'unicode'
> |   m_debugtype  = '(debug|release)'
> |   m_flavour= '(-[^-]+)?'
> |   m_version= '[0-9]+\.[0-9]+'
> |   m_linkage= ''
> |   configmask   = '^[^-]+(univ)?-unicode-[0-9]+\.[0-9]+(-[^-]+)?$'
> |   this config  = 'gtk2-unicode-3.0'
> | 
> |   using this config
> | 3.0.3
> |   user supplied libs: ''
> |   fetching lib flags for: ''
> |   retrieved: ldflags = 
> |  wxlibs  = 
> |  alllibs = 
> | 
> |   using libs: ' '
> |   using_gui = yes
> | 
> | $
> 
> I believe that mediainfo's use of --host is reasonable and wx-config
> should handle the native --host just fine.

I noticed the upstream bug this is forwarded too was closed as invalid
way back in 2011.  It seems unlikely upstream will fix this without
prodding, so we probably should reopen the upstream bug and provide
an explanation for why this should work.

But reviewing your report I'm confused.  Is this really a cross-build or
not?

You say "native --host", which seems to imply it's not really a
cross-build but a native build with --host=`./config.guess` or
something similar, and that is indeed what the upstream bug report
this bug is forwarded to is complaining doesn't work.

But looking at mediainfo's ./Project/GNU/GUI/wxwin.m4 it seems we must
be triggering this conditional appending:

  if test "$cross_compiling" = "yes"; then
 wx_config_args="$wx_config_args --host=$host_alias"
  fi

So it seems that mediainfo's configure script thinks we are
cross-compiling.

I checked the crossqa logs for mediainfo, but they show a failure due
to libzen, not wx:

configure: error: libzen configuration is not found

http://crossqa.debian.net/build/mediainfo_18.12-2.1_ppc64el_20191016050307.log

Cheers,
Olly

Bug#943583: sysv-rc: information from the Policy Manual for README.runlevels

[Dmitry Bogatov]

[2019-10-28 21:51] Sean Whitton 
> >> but I'm not sure this text has actually ever been updated since Ian
> >> Jackson wrote it the mid-nineties.
> >
> > It seems it is still correct. I double-checked last part, about
> > runlevels 0/6, reading source of /etc/init.d/rc -- it is still accurate.
>
> What I meant here was that it might be that only Ian holds copyright on
> the text, not the other copyright holders listed for the Policy Manual
> in general.

Then it means that I did not update d/copyright in src:sysvinit, and it
was right thing to do. Or am I missing any other consequence?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#943395: runit: Minor fixes to invoke-run

[Dmitry Bogatov]

control: tags -1 +pending

[2019-10-30 19:45] Lorenzo Puliti 
> Package: runit
> Version: 2.1.2-35
> Followup-For: Bug #943395
>
> patch refreshed

Thank you. Applied in git.

Do you want me to upload #943395 and #942320 right now, or wait for
dh-runit and git-daemon?
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Ahmed El-Mahmoudy]

On Sat, Nov 02, 2019 at 05:27:35AM -0400, Jeremy Bicha wrote:
> Yes, I will sponsor this for you.
Thanks.

> In this case, I see the new tag has already been pushed so I wouldn't
> worry about it here.

Since you didn't upload yet, I made a couple of changes and pushed a
new tag.

-- 
‎أحمد المحمودي (Ahmed El-Mahmoudy)
 Digital design engineer
GPG KeyIDs: 4096R/A7EF5671 2048R/EDDDA1B7
GPG Fingerprints:
 6E2E E4BB 72E2 F417 D066  6ABF 7B30 B496 A7EF 5761
 8206 A196 2084 7E6D 0DF8  B176 BC19 6A94 EDDD A1B7


signature.asc
Description: PGP signature

Bug#944033: /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron: mail from weekly cronjob

[gregor herrmann]

Package: e2fsprogs
Version: 1.45.4-1
Severity: minor
File: /usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Cron sends me the following mail once per week:

#v+
From: Cron Daemon 
To: root@$fqdn
Subject: Cron  test -e /run/systemd/system || SERVICE_MODE=1 
/usr/lib/x86_64-linux-gnu/e2fsprogs/e2scrub_all_cron
Date: Sun, 03 Nov 2019 03:30:03 +0100

/sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or 
directory
/sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or 
directory
/sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or 
directory
/sbin/e2scrub_all: line 173: /proc/8234/fd/pipe:[90083173]: No such file or 
directory
#v-

I totally can leave with a useless mail per week, it's just that I
don't understand it and it might indicate that something is not going
as planned …

/proc/8234/ didn't exist anymore when I saw the mail and tried to
investigate.


Cheers,
gregor


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

Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages e2fsprogs depends on:
ii  libblkid12.34-0.1
ii  libc62.29-3
ii  libcom-err2  1.45.4-1
ii  libext2fs2   1.45.4-1
ii  libss2   1.45.4-1
ii  libuuid1 2.34-0.1
ii  logsave  1.45.4-1

Versions of packages e2fsprogs recommends:
pn  e2fsprogs-l10n  

Versions of packages e2fsprogs suggests:
pn  e2fsck-static  
pn  fuse2fs
ii  gpart  1:0.3-6
ii  parted 3.3-1

- -- Configuration Files:
/etc/e2scrub.conf changed:
periodic_e2scrub=1


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl2+UnpfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgay/g/+LJRkOK5Y0m0E8cQanWUDga15JKJjkxxwRDM+BgtFRjgUdvvgrkS6zK7E
wEKUzkBEe91lo6SWtKiQP8EG+PMP0P+jCcudC6TPTM29eG4e3x8lIHB17Hcn1DoV
OcqPVMnKXkiF/qKyrF8BPQYucFdRpf+irFVI41vohdgAUuWElXIhE/3IckUmHoRT
L2m01FxdDDX/RHowg+kTdg177FFp8JUx0Rtu7oexo+d9Rud/itcjWqNucrnHOn5W
b0Rhu2VvQIZK8MLIa8CRfflR95HaLJdQreqCwFT0yCmRunirNa+52QYTTTLbXKG/
7yp2XUlSKvWlFGO/C7DNh19sSfxrZNV8rrjGoK/RHKakNDMqj/+TXn7B1phv8uLi
B0bz2LzJqP5M6ahlQ/HPnSTd6Xl+gq7wrwiqix11AnLEZKrdtxOkUxZ+uRcwzcHM
X37N8BWC/fyV2OcVFzfoz7M/KO+y4o+/kH3gPNBIpQmQ1XL/scFyZcBuR1tZlU1m
jA6lJd/l9EUHclRp8zempolTFUmH+4WiOCII3ukcwS2PMUQfQ4qQA8dL2BXOg0oo
f6VjG9YRA8w8nVhNg5LO8X95MnIjekmD66BFk2uPwvTNihh+SOeh1AigQaOs8+Is
AisLJFDSe0uW9AWQoncdopKebRvpUZrKSE6kiVko5xSZPaIea18=
=1ZRS
-END PGP SIGNATURE-

Bug#935044: debsums: extend localepurge support

[gregor herrmann]

Control: tag -1 + patch

On Sun, 18 Aug 2019 15:58:17 +0200, gregor herrmann wrote:

> Package: debsums
> Version: 2.2.3
> Severity: normal
> 
> debsums knows about a couple of locations where localepurge removes
> files from and doesn't report those files as missing. Recently
> localepurge has started to remove more localization files, and so the
> weekly debsums cronjob mails is very long by now.

I've created a patch in the 935044-localepurge branch and a merge request:
https://salsa.debian.org/perl-team/modules/packages/debsums/merge_requests/2


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#943967: /usr/share/vim/vim81/debian.vim: runtimepath overriden in debian.vim without /etc/vim path

[James McCoy]

On Fri, Nov 01, 2019 at 10:25:49PM +0100, Václav Ovsík wrote:
> A directory /etc/vim is missing from the VIM runtimepath and so my
> syntax file at /etc/vim/syntax/dhcpd.vim is not loaded after upgrade
> to the Debian Buster release.
> 
> You mentioned addition of /etc/vim into the default 'runtimepath' in
> changelog for version 2:8.1.0693-2. That is true, but this default
> runtimepath is overriden in the debian.vim file.

Thanks for the report.  Good catch!  I can fix that using the same
mechanism that's adding /etc/vim to 'runtimepath', which will allow
removing the setting of 'runtimepath' from debian.vim.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#883241: chrony: daemon doesn't automatically start

[Andres Salomon]

Sorry, I stopped using chrony some time ago and the laptop that was 
generating this bug was murdered by a cup of tea.



On Sat, Oct 5, 2019 at 02:43, Michael Biebl  wrote:

Seems like Conflicts= do not work reliably to ensure the
systemd-timesyncd.service is not started during boot.

See also the upstream bug report


We've re-added the Conditions to systemd-timesyncd.service.
#
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService


This should ensure systemd-timesyncd.service is not started if chrony 
is

installed.

Andres, can you still reproduce the problem?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git

[Mo Zhou]

Hi Nicolas,

FYI, there was once a heated discussion on highlighting diffs generated
by git: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925288
(was: ITP: diff-so-fancy) That ITP eventually turned into a
packaging request for the "diff-highlight" executable already shipped
in src:git .

That said, the new rust tool seems to have enough new features that
the others do not have.

On Sun, Nov 03, 2019 at 01:47:37AM +0100, Nicolas Braud-Santoni wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Nicolas Braud-Santoni 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> * Package name: git-delta
>   Version : 0.0.10
>   Upstream Author : Dan Davison 
> * URL : https://github.com/dandavison/delta
> * License : ISC
>   Programming Lang: Rust
>   Description : A syntax-highlighting pager for git
> 
> Delta brings language syntax highlighting, within-line insertion/deletion
> detection, and restructured diff output to git on the command line.
> 
> Features include:
> - - language-aware syntax highlighting;
> - - detecting and hilighting insertions & deletions within a single line.
> 
> -BEGIN PGP SIGNATURE-
> 
> iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl2+I6YRHG5pY29vQGRl
> Ymlhbi5vcmcACgkQ5vmO4pLV7MtXkxAAimwMV+oSf88JqflVUrwKnGrF3C4UIq2l
> 9qKU/ObCf85Nn+t410pAzy9KdqDasEJCSyszWAyEwzljy/M83PJSS+A9juMPcJj0
> pc1WJFdv69OLgLlbky2w0fXBfXuS1KSSd8HljNfj0TU2gtlC5uBCtQevmNkxKrSG
> ckhBwIqHahh3cOcZFJlvp+jfjPQ/pemuYDWmKVnsTiHJIgfxxku8me73K3jmlKTq
> oLEEtjipeyw+6ziAfqAOhWZNObg7Kt5/lTiY+senM767vOGj7SC04Oxfo4sojxrl
> QPVSNJ83fOcUY9WQt8TOeN76LeC81/i0U9mLe6quuNK5wcdS0O4jOHFDoYmd+FI/
> 1Rl5/cmmwFfyI4c+iCsHU+5cP+SYYBAz/RUcWPBAqbK3sDMAucvSCJR70Mej8x7p
> f0KEP+yp4Tzp9MUkeWZSsHLsNUDgZWGpQqXW92cpYNJFw3VLR1kVT2aNhHc54fNn
> rFcr9K/hxJVYtHF6z+H7cS89pzqPSrl7hz/+5l8ZCNdcIYHGJm7pA+O2238Ur7Et
> 93Xn5SDLvhS6nX2I9XbC8zOSeLBgFED5fzQWe/IMdLDyTKEEnuI/FvKYzebnc8jx
> yPDzlCnAbhe1yaFG50SR3T4/SvZb7IsM4yHpclK+qZ1kLorl1o6jHukDgGr2zZT6
> 0rolB+uH3vQ=
> =Q9lL
> -END PGP SIGNATURE-
> 

Bug#944031: qtsensors-opensource-src: FTBFS on !linux

[Samuel Thibault]

Source: qtsensors-opensource-src
Version: 5.12.5-2
Severity: important
Tags: patch

Hello,

qtsensors-opensource-src currently FTBFS on !linux archs, because the
libqt5sensors5 package doesn't even contain the libQt5Sensors.so.5
library.

Indeed, even if the source package contains libqt5sensors5.install, that
file gets dropped during the build, because debian/clean contains its
name. Could you apply the attached patch to fix this?

Thanks,
Samuel

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

Kernel: Linux 5.3.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
 what the fuck is wtf
--- debian/clean.original   2019-11-03 01:07:55.0 +
+++ debian/clean2019-11-03 01:07:56.0 +
@@ -1,4 +1,3 @@
-debian/libqt5sensors5.install
 doc/qtsensors.qch
 doc/qtsensors/
 examples/sensors/grue/detect_grue

Bug#944032: RM: python-backports.csv -- ROM; Python 2-only package, no longer needed

[Stuart Prescott]

Package: ftp.debian.org
Severity: normal

Dear FTP team,

python-backports.csv was only introduced to bring Python 3 features to
Python 2 modules. Its final user, python-translate has now been dropped from
src:translate-toolkit and so python-backports.csv has no further use in the
archive.

thanks
Stuart

Bug#944025: wiki.debian.org: Instructions for TP-Link TL WN821N Guide do not function as predicted

[Paul Wise]

Control: close -1

On Sun, Nov 3, 2019 at 7:57 AM Greg Pfister wrote:

> built kernel module following guide on page "https://wiki.debian,org/wifi; - 
> No
> Errors on build nor installation of module - on 4.19.0-5-amd64 however recived
> the following error in system log: x86/modules: Skipping invalid relocation
> target, existing value is nonzero for type 1, loc da5661c0, val
> c0f35572"

This sounds like a bug in the WiFi driver you are compiling, not a bug
in the wiki page. Please report the issue to the driver developer
instead.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#944029: ITP: megahit -- ultra-fast and memory-efficient meta-genome assembler

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: megahit -- ultra-fast and memory-efficient meta-genome assembler
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: megahit
  Version : 1.2.9
  Upstream Author : The University of Hong Kong & L3 Bioinformatics Limited
* URL : https://github.com/voutcn/megahit
* License : GPL-3
  Programming Lang: C
  Description : ultra-fast and memory-efficient meta-genome assembler
 Megahit is an ultra-fast and memory-efficient NGS assembler. It is
 optimized for metagenomes, but also works well on generic single genome
 assembly (small or mammalian size) and single-cell assembly.

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

Bug#944030: jinja2-time: FTBFS in unstable

[Steve Langasek]

Source: jinja2-time
Version: 0.2.0-2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal

Hi Vincent,

The jinja2-time source package currently fails to build from source in
unstable:

[...]
tests/test_now.py ..FFF  [100%]

=== FAILURES ===
 test_add_time _

environment = 

def test_add_time(environment):
environment.datetime_format = '%a, %d %b %Y %H:%M:%S'

template = environment.from_string(
"{% now 'utc' + 'hours=2,seconds=30' %}"
)

>   assert template.render() == "Thu, 10 Dec 2015 01:33:31"

tests/test_now.py:61: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/jinja2/asyncsupport.py:76: in render
return original_render(self, *args, **kwargs)
/usr/lib/python3/dist-packages/jinja2/environment.py:1008: in render
return self.environment.handle_exception(exc_info, True)
/usr/lib/python3/dist-packages/jinja2/environment.py:780: in handle_exception
reraise(exc_type, exc_value, tb)
/usr/lib/python3/dist-packages/jinja2/_compat.py:37: in reraise
raise value.with_traceback(tb)
:1: in top-level template code
???
jinja2_time/jinja2_time.py:26: in _datetime
d = d.replace(**replace_params)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = 
kwargs = {'hours': 2.0, 'seconds': 30.0}, absolute_kwargs = {}, key = 'hours'
value = 2.0

def replace(self, **kwargs):
""" Returns a new :class:`Arrow ` object with 
attributes updated
according to inputs.

Use property names to set their value absolutely::

>>> import arrow
>>> arw = arrow.utcnow()
>>> arw

>>> arw.replace(year=2014, month=6)


You can also replace the timezone without conversion, using a
:ref:`timezone expression `::

>>> arw.replace(tzinfo=tz.tzlocal())


"""

absolute_kwargs = {}

for key, value in kwargs.items():

if key in self._ATTRS:
absolute_kwargs[key] = value
elif key in ["week", "quarter"]:
raise AttributeError("setting absolute {} is not 
supported".format(key))
elif key != "tzinfo":
>   raise AttributeError('unknown attribute: "{}"'.format(key))
E   AttributeError: unknown attribute: "hours"

/usr/lib/python3/dist-packages/arrow/arrow.py:603: AttributeError
[...]

This failure was reproduced in Ubuntu focal, and you can find a full build
log at
.

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


signature.asc
Description: PGP signature

Bug#944028: ITP: git-delta -- A syntax-highlighting pager for git

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: git-delta
  Version : 0.0.10
  Upstream Author : Dan Davison 
* URL : https://github.com/dandavison/delta
* License : ISC
  Programming Lang: Rust
  Description : A syntax-highlighting pager for git

Delta brings language syntax highlighting, within-line insertion/deletion
detection, and restructured diff output to git on the command line.

Features include:
- - language-aware syntax highlighting;
- - detecting and hilighting insertions & deletions within a single line.

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl2+I6YRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MtXkxAAimwMV+oSf88JqflVUrwKnGrF3C4UIq2l
9qKU/ObCf85Nn+t410pAzy9KdqDasEJCSyszWAyEwzljy/M83PJSS+A9juMPcJj0
pc1WJFdv69OLgLlbky2w0fXBfXuS1KSSd8HljNfj0TU2gtlC5uBCtQevmNkxKrSG
ckhBwIqHahh3cOcZFJlvp+jfjPQ/pemuYDWmKVnsTiHJIgfxxku8me73K3jmlKTq
oLEEtjipeyw+6ziAfqAOhWZNObg7Kt5/lTiY+senM767vOGj7SC04Oxfo4sojxrl
QPVSNJ83fOcUY9WQt8TOeN76LeC81/i0U9mLe6quuNK5wcdS0O4jOHFDoYmd+FI/
1Rl5/cmmwFfyI4c+iCsHU+5cP+SYYBAz/RUcWPBAqbK3sDMAucvSCJR70Mej8x7p
f0KEP+yp4Tzp9MUkeWZSsHLsNUDgZWGpQqXW92cpYNJFw3VLR1kVT2aNhHc54fNn
rFcr9K/hxJVYtHF6z+H7cS89pzqPSrl7hz/+5l8ZCNdcIYHGJm7pA+O2238Ur7Et
93Xn5SDLvhS6nX2I9XbC8zOSeLBgFED5fzQWe/IMdLDyTKEEnuI/FvKYzebnc8jx
yPDzlCnAbhe1yaFG50SR3T4/SvZb7IsM4yHpclK+qZ1kLorl1o6jHukDgGr2zZT6
0rolB+uH3vQ=
=Q9lL
-END PGP SIGNATURE-

Bug#944027: softflowd 0.9.9-5 bad date

[Eric]

Package: softflowd
Version: 0.9.9-5

Log messages exported in v9 have a date near 1970. Rolling back to 0.9.9-3 
fixed this.

Using Debian 10.1 buster, works when installing 0.9.9-3 from stretch

Bug#863355: O: citeproc-py -- Citation Style Processor (CSL) for Python

[Emmanuel Arias]

Hi,

I am interest to adopt it

Thanks

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

Bug#944026: jinja2-time: failing tests with python3.8

[Steve Langasek]

Package: python3-freezegun
Version: 0.3.11-0.1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

Hi Federico,

The jinja2-time package fails to build from source in Ubuntu focal, because
Ubuntu has begun the transition to python3.8 and freezegun is not
source-compatible with python3.8:

[...]
 ERRORS 
__ ERROR collecting .pybuild/cpython3_3.8_jinja2-time/build/tests/test_now.py __
tests/test_now.py:5: in 
from freezegun import freeze_time
/usr/lib/python3/dist-packages/freezegun/__init__.py:9: in 
from .api import freeze_time
/usr/lib/python3/dist-packages/freezegun/api.py:28: in 
real_clock = time.clock
E   AttributeError: module 'time' has no attribute 'clock'
!!! Interrupted: 1 errors during collection 
[...]

  (https://launchpad.net/ubuntu/+source/jinja2-time/0.2.0-2/+build/17967649)

Debian has not yet started the transition to python3.8 - the version of
python3-defaults that adds python3.8 as supported is currently in
experimental - but this will eventually become a serious bug in Debian as
well once that transition begins.

For the moment I have worked around the failure in Ubuntu by changing the
packaging to test only against the current version of python3 and not
against all supported versions, but this is a very short-term fix given that
python3.8 will become the default in the next 6 months.

Thanks,
-- 
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 jinja2-time-0.2.0/debian/control jinja2-time-0.2.0/debian/control
--- jinja2-time-0.2.0/debian/control2019-09-02 05:46:08.0 -0700
+++ jinja2-time-0.2.0/debian/control2019-11-02 17:16:55.0 -0700
@@ -4,7 +4,7 @@
 Maintainer: Vincent Bernat 
 Uploaders: Debian Python Modules Team 

 Build-Depends: debhelper-compat (= 9), dh-python,
-   python3-all,
+   python3,
python3-arrow,
python3-jinja2,
python3-setuptools,

Bug#944003: [pkg-apparmor] Bug#944003: apparmor: Fails to build for python 3.8

[Christian Boltz]

Hello,

Am Samstag, 2. November 2019, 16:20:10 CET schrieb intrig...@debian.org:
> As discovered on #942663, src:apparmor fails to build for python 3.8.
...
>  - upstream Git: libraries/libapparmor/m4/ac_python_devel.m4
> 
>  - upstream tarball: libraries/libapparmor/configure

This is part of the libapparmor bindings which are generated with swig, 
which I'm not really familiar with. However, there's an interesting 
detail on http://www.swig.org/Release/RELEASENOTES for swig 4.0.1 (which 
is the latest release):
- Add Python 3.8 support.

Which swig version gets used in the failing builds?
If it's older than 4.0.1, then updating swig is probably the first thing 
to do/test ;-)

Note that this is just a wild guess ;-)


Regards,

Christian Boltz
-- 
seccheck runs here on a host that contains 3 daily backups of 10+ SAP
hosts, and the "Local Monthly Security" Mail size is 562 MB. This mail
size causes an unfriednly, suspicious grin on the face of my mail
admin... [Werner Flamme in opensuse-security]


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

Bug#944025: wiki.debian.org: Instructions for TP-Link TL WN821N Guide do not function as predicted

[Greg Pfister]

Package: wiki.debian.org
Severity: important
Tags: a11y

Dear Maintainer,

   * What led up to the situation?

Installation of recommended USB WIFI device TP-Link TL WN821N which is listed
on WIKI as "confirmed to work"


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

built kernel module following guide on page "https://wiki.debian,org/wifi; - No
Errors on build nor installation of module - on 4.19.0-5-amd64 however recived
the following error in system log: x86/modules: Skipping invalid relocation
target, existing value is nonzero for type 1, loc da5661c0, val
c0f35572"

Removed module, rebooted, ran "make clean", "make", "make install".  Same
resultes.

Please note that under 5.3.0-1-amd64 will NOT make (after a make clean) due to
multiple errors.

   * What was the outcome of this action?
x86/modules: Skipping invalid relocation target, existing value is nonzero for
type 1, loc da5661c0, val c0f35572

   * What outcome did you expect instead?

Expected module to execute and device function properly as listed in Guide.



*  Current Module List

Module  Size  Used by
8814au   1351680  0
fuse  122880  1
cfg80211  761856  1 8814au
rfkill 28672  4 cfg80211
joydev 24576  0
pktcdvd45056  2
intel_rapl 24576  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
snd_hda_codec_conexant24576  1
snd_hda_codec_generic86016  1 snd_hda_codec_conexant
snd_hda_codec_hdmi 57344  1
snd_hda_intel  45056  6
coretemp   16384  0
snd_hda_codec 151552  4
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
snd_hda_core   94208  5
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
snd_hwdep  16384  1 snd_hda_codec
kvm_intel 245760  0
snd_pcm   114688  4
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
sg 36864  0
snd_timer  36864  1 snd_pcm
mei_me 45056  0
kvm   724992  1 kvm_intel
snd94208  20
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm
mei   118784  1 mei_me
soundcore  16384  1 snd
ie31200_edac   16384  0
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
irqbypass  16384  1 kvm
crct10dif_pclmul   16384  0
crc32_pclmul   16384  0
ghash_clmulni_intel16384  0
pcc_cpufreq16384  0
serio_raw  16384  0
evdev  28672  9
intel_cstate   16384  0
intel_uncore  135168  0
intel_rapl_perf16384  0
pcspkr 16384  0
dcdbas 16384  0
parport_pc 32768  0
ppdev  20480  0
lp 20480  0
parport57344  3 parport_pc,lp,ppdev
ip_tables  28672  0
x_tables   45056  1 ip_tables
autofs449152  2
ses20480  0
enclosure  16384  1 ses
scsi_transport_sas 45056  1 ses
ext4  733184  1
crc16  16384  1 ext4
mbcache16384  1 ext4
jbd2  122880  1 ext4
crc32c_generic 16384  0
fscrypto   32768  1 ext4
ecb16384  0
hid_microsoft  16384  0
hid_logitech_hidpp 36864  0
hid_logitech_dj24576  0
hid_generic16384  0
usbhid 57344  0
hid   135168  5
usbhid,hid_microsoft,hid_generic,hid_logitech_dj,hid_logitech_hidpp
uas28672  0
usb_storage73728  2 uas
sr_mod 28672  2
cdrom  65536  2 pktcdvd,sr_mod
sd_mod 61440  3
crc32c_intel   24576  2
radeon   1626112  13
aesni_intel   200704  1
aes_x86_64 20480  1 aesni_intel
i2c_algo_bit   16384  1 radeon
crypto_simd16384  1 aesni_intel
ahci   40960  3
cryptd 28672  3 crypto_simd,ghash_clmulni_intel,aesni_intel
ttm   126976  1 radeon
libahci40960  1 ahci
glue_helper16384  1 aesni_intel
libata270336  2 libahci,ahci
drm_kms_helper200704  1 radeon
ehci_pci   16384  0
r8169  86016  0
ehci_hcd   94208  1 ehci_pci
psmouse   172032  0
i2c_i801   28672  0
realtek20480  1
drm   483328  8 drm_kms_helper,radeon,ttm
libphy 77824  2 r8169,realtek
usbcore   290816  6 8814au,ehci_pci,usbhid,usb_storage,ehci_hcd,uas
scsi_mod  245760  8
ses,scsi_transport_sas,sd_mod,usb_storage,uas,libata,sg,sr_mod

Bug#873651: O: flask-openid -- OpenID support for Flask applications

[Emmanuel Arias]

Hi!

I am interest to adopt it  :-)



Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

Bug#944024: cronie: ships /usr/sbin/anacron

[Andreas Beckmann]

Package: cronie
Version: 1.5.5-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation (if that is what you want).

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

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

  Preparing to unpack .../cronie_1.5.5-1_amd64.deb ...
  Unpacking cronie (1.5.5-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/cronie_1.5.5-1_amd64.deb (--unpack):
   trying to overwrite '/usr/sbin/anacron', which is also in package anacron 
2.3-29
  Errors were encountered while processing:
   /var/cache/apt/archives/cronie_1.5.5-1_amd64.deb


cheers,

Andreas


anacron=2.3-29_cronie=1.5.5-1.log.gz
Description: application/gzip

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

Hi,

If I am not mistaken, Ubuntu version used on Mozilla's build server 
farms uses rather very old version of sqlite3.


  

[task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
[task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
[task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu



Maybe I should downgrade to this and then upgrade a bit until local test breaks.

From: https://launchpad.net/ubuntu/xenial/+source/sqlite3

Updates

   Package versions including new features after the distribution
   release has been made. Updates are usually turned on by default
   after a fresh install.

 * sqlite3 3.11.0-1ubuntu1.2
   
   (main)

Bug#944023: sogo: cronjob produces output and exits with error after package removal

[Andreas Beckmann]

Package: sogo
Version: 4.1.0-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your packages cronjob produces
output after the package has been removed.

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

0m31.8s INFO: Package sogo contains cron file: /etc/cron.daily/sogo
0m31.8s DEBUG: Starting command: ['chroot', '/srv/piuparts/tmp/tmphFOFTC', 
'/etc/cron.daily/sogo']
0m31.8s DUMP: 
  find: '/var/spool/sogo': No such file or directory
  find: '/var/spool/sogo': No such file or directory
0m31.8s ERROR: Command failed (status=1): ['chroot', 
'/srv/piuparts/tmp/tmphFOFTC', '/etc/cron.daily/sogo']


cheers,

Andreas


sogo_4.1.0-1.log.gz
Description: application/gzip

Bug#943732: pandas: test fails/crashes on mipsel

[Rebecca N. Palmer]

Control: retitle -1 pandas: test fails/crashes on mipsel

arm* = new tests hitting the already-known issue #877754
(which I don't like having open with no user-level warning, but blocking 
the transition over it doesn't actually help)

s390x/ppc64 = bug in the tests, not the library
riscv64 = looks NaN-handling-related, possibly in numpy (their 
TestBoolCmp.test_float fails as well, but doesn't fail the build due to 
#943369), not a release arch


This leaves mipsel as the only RC issue: ~100 failures (many, but not 
all, xz compression related), an intermittent crash, and no detailed 
output because of a MemoryError while trying to print it(!).

Bug#877754: NaN -> datetime = 0 (not NaT) on arm*

[Rebecca N. Palmer]

Control: retitle -1 NaN -> datetime = 0 (not NaT) on arm*
Control: tag -1 - fixed-upstream
Control: reassign -1 python3-numpy
Control: affects -1 python3-pandas
Control: forwarded -1 https://github.com/numpy/numpy/issues/8325

The underlying issue is that datetime/timedelta are internally ints, and 
use the C float -> int conversion.  This is undefined when the input is 
NaN, so is allowed to be whatever is most efficient on that hardware: 
typically -2**63 (NaT) on x86 but 0 (1970-01-01) on arm*.

Bug#944022: firehol: default config is unusable for a server

[Toni Mueller]

Package: firehol
Version: 3.1.6+ds-8
Severity: important

Dear Maintainer,

as-is, the firehol package installs a set of filters that will disable
access to the server. This would not be a problem if the package would
not also immediately start firehol, ie, implement this configuration. I
found that it shouldn't be started, but it definitely is, despite
/etc/defaults/firehol saying "START_FIREHOL=NO".

The effect is that if you install this package on a server, you're
immediately losing contact and have no remedy to fix that.

Suggested fix: Do not enable this service during installation, at least
not on a server, or install a default policy like this:

interface any world
policy accept


Cheers,
Toni


-- System Information:
Debian Release: 10.1
  APT prefers stable
  APT policy: (550, 'stable'), (500, 'stable-updates'), (500, 'unstable'), 
(500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 firehol depends on:
ii  firehol-common  3.1.6+ds-8
ii  lsb-base10.2019051400

Versions of packages firehol recommends:
ii  fireqos  3.1.6+ds-8

Versions of packages firehol suggests:
pn  firehol-doc
pn  firehol-tools  
pn  ulogd2 

-- Configuration Files:
/etc/firehol/firehol.conf changed [not included]

-- no debconf information

Bug#937895: Debdiff to fix these bugs

[Thomas Goirand]

Hi,

Please find attached the debdiff to fix these bugs. Please upload the
fix, or allow me to NMU it. :)

Please note that both bugs are now of severity serious, as:
1/ livereload is a leaf package that is blocking other bugs
2/ the autopkgtest are using django Py2, which is removed from Sid.

Cheers,

Thomas Goirand (zigo)
diff -Nru python-livereload-2.6.1/debian/changelog 
python-livereload-2.6.1/debian/changelog
--- python-livereload-2.6.1/debian/changelog2019-07-20 20:36:14.0 
+0200
+++ python-livereload-2.6.1/debian/changelog2019-11-02 22:29:38.0 
+0100
@@ -1,3 +1,10 @@
+python-livereload (2.6.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Removed Python 2 support (Closes: #937895, 943960)
+
+ -- Thomas Goirand   Sat, 02 Nov 2019 22:29:38 +0100
+
 python-livereload (2.6.1-2) unstable; urgency=medium
 
   * d/p/0002: Sorry attempt to fix a failing test. See the patch notes to get
diff -Nru python-livereload-2.6.1/debian/control 
python-livereload-2.6.1/debian/control
--- python-livereload-2.6.1/debian/control  2019-07-16 22:42:32.0 
+0200
+++ python-livereload-2.6.1/debian/control  2019-11-02 22:27:41.0 
+0100
@@ -7,37 +7,15 @@
  debhelper (>= 11),
  dh-python,
  help2man,
- python-all,
- python-setuptools,
- python-tornado,
  python3-all,
  python3-setuptools,
  python3-sphinx,
+ python3-tornado,
 Standards-Version: 4.4.0
 Homepage: https://github.com/lepture/python-livereload
 Vcs-Git: https://salsa.debian.org/debian/python-livereload.git
 Vcs-Browser: https://salsa.debian.org/debian/python-livereload
 
-Package: python-livereload
-Architecture: all
-Depends: python-pkg-resources, ${misc:Depends}, ${python:Depends}
-Recommends: node-less, python-pyinotify
-Suggests:
- coffeescript,
- node-uglify,
- python-django,
- python-flask,
- python-livereload-doc,
- python-slimmer,
-Description: automatic browser refresher
- It is really boring for Web developers to need to refresh their browser
- every time they save a (CSS, JavaScript, or HTML) file. LiveReload will
- take care of that for you, so that when you save a file, your browser
- will refresh itself - and what's more, it can perform tasks such as
- compiling LESS to CSS before the browser reload.
- .
- This package contains the Python 2 version of livereload.
-
 Package: python3-livereload
 Architecture: all
 Depends: python3-pkg-resources, ${misc:Depends}, ${python3:Depends}
diff -Nru python-livereload-2.6.1/debian/livereload 
python-livereload-2.6.1/debian/livereload
--- python-livereload-2.6.1/debian/livereload   2019-07-16 22:42:32.0 
+0200
+++ python-livereload-2.6.1/debian/livereload   2019-11-02 22:29:38.0 
+0100
@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/python3
 import sys
 import os
 sys.path.insert(0, os.environ['PWD'])
diff -Nru python-livereload-2.6.1/debian/rules 
python-livereload-2.6.1/debian/rules
--- python-livereload-2.6.1/debian/rules2019-07-16 22:42:32.0 
+0200
+++ python-livereload-2.6.1/debian/rules2019-11-02 22:29:38.0 
+0100
@@ -11,7 +11,7 @@
 
 
 %:
-   dh $@ --with python2,python3,sphinxdoc --buildsystem=pybuild
+   dh $@ --with python3,sphinxdoc --buildsystem=pybuild
 
 override_dh_auto_clean:
dh_auto_clean --all
@@ -24,7 +24,6 @@
cd docs; \
python3 -m sphinx -C -b html -Dmaster_doc=index . _build/html; \
cd -;
-   rm -r debian/python-livereload/usr/bin
 
 override_dh_auto_test:
 
diff -Nru python-livereload-2.6.1/debian/tests/control 
python-livereload-2.6.1/debian/tests/control
--- python-livereload-2.6.1/debian/tests/control2019-07-20 
20:31:27.0 +0200
+++ python-livereload-2.6.1/debian/tests/control2019-11-02 
22:28:39.0 +0100
@@ -3,9 +3,3 @@
  python3-setuptools,
  python3-django,
 Restrictions: allow-stderr
-
-Test-Command: python2 setup.py test
-Depends: @,
- python-setuptools,
- python-django,
-Restrictions: allow-stderr

Bug#944021: xul-ext-compactheader: not compatible with thunderbird 68

[Sven Joachim]

Package: xul-ext-compactheader
Version: 2.1.6-1
Severity: serious

This package is not compatible with thunderbird 68 which has just appeared
in unstable:

,
| $ LANG=C aptitude -s install thunderbird thunderbird-l10n-de
| The following packages will be upgraded:
|   thunderbird{b} thunderbird-l10n-de
| The following packages are RECOMMENDED but will NOT be installed:
|   lightning
| 2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
| Need to get 35.3 MB of archives. After unpacking 2812 kB will be used.
| The following packages have unmet dependencies:
|  thunderbird : Breaks: xul-ext-compactheader (< 3.0.0) but 2.1.6-1 is 
installed
`

On the thunderbird side of things, shouldn't the Breaks be adjusted to
(<< 3.0.0~), since 3.0.0.~beta3 is the latest version on
https://github.com/jmozmoz/compactheader/releases ?


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

Kernel: Linux 5.3.8-nouveau (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages xul-ext-compactheader depends on:
ii  thunderbird  1:60.9.0-1

xul-ext-compactheader recommends no packages.

xul-ext-compactheader suggests no packages.

-- no debconf information

Bug#941016: ITP: gnome-firmware-updater -- GTK tool to upgrade, downgrade, and reinstall firmware on devices supported by fwupd

[mike . gabriel]

Hi Jesper,

Am Samstag, 2. November 2019 schrieb Jesper Mejervik Derander:
> 
> Hi Mike,
> 
> Thank you for a detailed review! 
> 
> > Hi Jesper,
> > (Cc:ing Martin Wimpress from Ubuntu MATE)
> > 
> > 
> > > I'm ok with that. Thank you for taking your time, I will do my best to
> > > help. I've applied some upstream patches that fix
> > > the manpage issue and i've also taken care of the lintian issues.
> > > looking forward to hearing your review comments soon!
> > 
> > Here comes the review:
> > 
> > 1.
> > src:pkg name: upstream names it gnome-firmware-updater, so why do you  
> > name it gnome-firmware
> > 
> > 2.
> > bin:pkg name: same as with src:pkg name
> > 
> > 3.
> > debian/control:
> > 
> >- SYNOPSIS: gtk front end for fwupd -> GTK
> >- LONG_DESCRIPTION: indent the itemizations by two characters
> >- LONG_DESCRIPTION: why don't you use the wording from
> >  upstream's README.md file? Please do.
> >  
> > https://gitlab.gnome.org/hughsie/gnome-firmware-updater/blob/master/README.md
> >- Build-Depends: please add a comma after the last pkg name, it  
> > makes diffs look nicer
> >  one the line below Build-Depends gets changed (e.g. with another pkg 
> > name)
> >- Vcs-*: fields are missing, we should put the pkg on salsa under  
> > the debian/ folder
> >- Depends: field, I recommend having one package per row.
> >- Please use appropriate upper case and lower case letters
> > 
> > debian/copyright:
> >
> >- personally, I don't like the "Files: *" debian/copyright style,  
> > but ftpmaster
> >  wave it through, so...
> >- Source: field: no URL with a release number here, I'd put the  
> > releases/ folder
> >  here as URL or even better, the GitLab repo.
> > 
> >A general thing: you did good, but for other packages you might  
> > maintain... I normally
> >use all licenses appearing in the upstream code for debian/.
> > 
> > 
> > debian/changelog:
> >
> >- my spelling: "Initial release to Debian. (Closes: #941016)."
> > -> thus, using full-stops
> >
> > 4.
> > The pristine-tar branch is not on salsa, I cannot build without that  
> > branch using gbp-buildpackage.
> >
> > There are three options now:
> >
> >(a) you work on those bits and pieces and I take a second look
> >(b) you are ok with me adding some commits
> >(c) a mixture of (a) and (b)
> >
> > We should created an empty Git repo (gnome-firmware-updater) under  
> > salsa.debian.org/debian (I can do that, if you agree) and push a clone  
> > of your Git repo there. Please let me know if you are ok with  
> > continueing using that repository as the official packaging VCS  
> > location.
> > 
> > Another option would be placing the packaging Git repo onto the Debian  
> > GNOME team's namespace on GitLab, but gnome-firmware-updater has  
> > "gnome" in its name, but as I learned from upstream, it is a suitable  
> > add-on tool for all GTK-based desktop environments, so a "neutral"  
> > spot like the /debian team folder salsa is probably the better way to  
> > go.
> >
> > Also, Martin Wimpress from Ubuntu MATE and I would like to add  
> > ourselves as uploaders. Furthermore, I recommend adding the Debian  
> > GNOME team and the Debian+Ubuntu MATE team as uploaders, too. In old  
> > times, most Debian packages had been 1-person-maintained, which turned  
> > out to be a bad concept in case devs went missing in action (MIA).  
> > Allowing team uploads to packages makes Debian a much more flexible  
> > place to be at. Please let me know, if you are ok with this, too.
> >
> > Thanks for your work!
> > Mike
> 
> Regarding the naming of the package, I've based it on the Fedora/openSUSE 
> package and this upstream commit: 
> https://gitlab.gnome.org/hughsie/gnome-firmware-updater/commit/55705a55e930e4ecb14fc5ae122bbbad9042f03b

Ah, ok. Your package name makes more sense, then.

> It seems like this is the current and future package name so I suggest 
> keeping it.

Yes.
 
> If you're okay with it, I'd be happy to take the time and fix these issues 
> myself, that way I can learn how to do these
> things properly (so, option a). I'll try to do it as soon as possible.

Ok, please do, then. Thanks!
 
> I'm okay with moving the repo under /debian/gnome-firmware but perhaps I 
> could tidy up a bit first. I plan to use the 
> dep14 structure like they do with the gnome-shell package. Perhaps we can 
> move it after the initial packaging is complete?

Yes. Ok.
 
> Are you okay with having a second look once I have a new revision ready?

 Yes, ping for the next review iteration. Thanks.

> I'll let you know when it's done. I'll make sure
> to add you and Martin as uploaders by then.

Great!
 
> Best regards,
> Jesper Derander
>

light+love
Mike

-- 
Gesendet von meinem Fairphone2 (powered by Sailfish OS).

Bug#944020: python3-libusb1: should be named python3-usb1, since it installs a `usb1` top-level module

[Sandro Tosi]

Package: python3-libusb1
Severity: serious

Hello,
as per python policy, the binary name should be python3-.

Since the top level module here is `usb1`, the binary package name should then
be `python3-usb1`.

Please rename it, handling the transition from the binary package name.

Since it's a violation of the policy, severity is set to serious.

Regards,
Sandro

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

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

Versions of packages python3-libusb1 depends on:
ii  libusb-1.0-0  2:1.0.22-2
ii  python3   3.7.3-1

python3-libusb1 recommends no packages.

python3-libusb1 suggests no packages.

Bug#944019: nmu: netsniff-ng_0.6.6-1

[Andreas Beckmann]

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

nmu netsniff-ng_0.6.6-1 . ANY . experimental . -m "Rebuild against libcli1.10."

Rebuild for the ongoing libcli transition.


Andreas

Bug#944018: ocsinventory-reports: depends on no longer available libjs-select2.js

[Andreas Beckmann]

Package: ocsinventory-reports
Version: 2.6~RC+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

The following packages have unmet dependencies:
 ocsinventory-reports : Depends: libjs-select2.js but it is not installable


Cheers,

Andreas

Bug#944017: libsoxr: autopkgtest regression: segmentation fault

[Paul Gevers]

Source: libsoxr
Version: 0.1.3-2
Severity: serious
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of libsoxr the autopkgtest of libsoxr fails in
testing when that autopkgtest is run with the binary packages of libsoxr
from unstable. It passes when run with only packages from testing. In
tabular form:
   passfail
libsoxrfrom testing0.1.3-2
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libsoxr

https://ci.debian.net/data/autopkgtest/testing/amd64/libs/libsoxr/3316475/log.gz

autopkgtest [06:56:28]: test inst-check: [---
Examples in /usr/share/doc/libsoxr-dev/examples; using pkg-config:
cc -o /tmp/tmp.8rTY2fUTZY/1-single-block 1-single-block.c -lsoxr -lm
c++ -o /tmp/tmp.8rTY2fUTZY/2-stream 2-stream.C -lsoxr -lm
cc -o /tmp/tmp.8rTY2fUTZY/3-options-input-fn 3-options-input-fn.c -lsoxr -lm
cc -o /tmp/tmp.8rTY2fUTZY/4-split-channels 4-split-channels.c -lsoxr -lm
cc -o /tmp/tmp.8rTY2fUTZY/5-variable-rate 5-variable-rate.c -lsoxr -lm
 0.09  0.56  0.92  0.76  0.07 -0.71 -1.05 -0.72
 0.03  0.73  0.99  0.69 -0.00 -0.69 -0.99 -0.72
-0.01  0.71  1.01  0.71 -0.00 -0.71 -1.00 -0.70
 0.00  0.71  1.00  0.71  0.00 -0.71 -1.00 -0.71
 0.00  0.71  1.00  0.71 -0.00 -0.71 -1.00 -0.71
-0.00  0.71  1.00  0.71  0.00 -0.71 -1.00 -0.71
-0.00  0.71  1.00  0.71  0.00 -0.71 -1.00 -0.71
 0.00  0.71  1.00  0.71  0.00 -0.71 -1.00 -0.71
-0.00  0.71  1.00  0.71 -0.00 -0.71 -1.00 -0.71
-0.00  0.70  1.00  0.71  0.00 -0.71 -1.01 -0.71
 0.01  0.72  0.99  0.69  0.00 -0.69 -0.99 -0.73
-0.03  0.72  1.05  0.71 -0.07 -0.76 -0.92 -0.56
/tmp/tmp.8rTY2fUTZY/1-single-block no error
runtime=libsoxr-0.1.3 API=0.1.3
/tmp/tmp.8rTY2fUTZY/2-stream no error; I/O: no error
/tmp/tmp.8rTY2fUTZY/3-options-input-fn no error; 0 clips; I/O: no error
(cr32s)
Segmentation fault
autopkgtest [06:56:29]: test inst-check: ---]



signature.asc
Description: OpenPGP digital signature

Bug#944016: orangeassassin: depends on no longer available python3-raven

[Andreas Beckmann]

Package: orangeassassin
Version: 1.0b-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

The following packages have unmet dependencies:
 orangeassassin : Depends: python3-raven but it is not installable


Cheers,

Andreas

Bug#944015: RM: openambit/experimental -- RoQA; dead upstream, depends on qjson/qt4

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

openambit is already gone from sid (#935610):

On Sat, 24 Aug 2019 15:41:29 +0200 Moritz Muehlenhoff 
wrote:
> Please remove openambit, it's orphaned and depends on qjson, which
> gets removed alongside with qt4.

Andreas

Bug#936237: breezy: Python2 removal in sid/bullseye

[Andreas Beckmann]

Followup-For: Bug #936237
Control: severity -1 serious

The python-breezy package in experimental is no longer installable
since some of its python2 dependencies are already gone.

Andreas

Bug#944014: nmu: bind_1:9.13.3-1

[Andreas Beckmann]

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

nmu bind_1:9.13.3-1 . ANY . experimental . -m "Rebuild against libjson-c4."

Let's finish the libjson-c transition in experimental, too.


Andreas

Bug#944013: debian-edu-config: adjusted ini files needed to match changed behaviour of firefox-esr 68.2.0esr

[Wolfgang Schweer]

Package: debian-edu-config
Version: 2.10.65+deb10u1
Severity: important

For a centralized management of Firefox-ESR 68.2.x user profiles, the 
related profiles.ini file needs to be adjusted and a new file 
installs.ini needs to be shipped. Otherwise new users would miss PKI 
setup, facing a bad experience with insecure connections inside the 
internal network.

These changes would solve the problem for Debian Edu installations; 
tested for both Buster and Bullseye:

profiles.ini:

[Profile0]
Name=debian-edu
IsRelative=1
Path=debian-edu.default

[General]
StartWithLastProfile=1
Version=2

[Install3B6073811A6ABF12]
Default=debian-edu.default
Locked=1

---

installs.ini:
[3B6073811A6ABF12]
Default=debian-edu.default
Locked=1

---

Also, the related tool 'gosa-create' to activate these changes for new 
user accounts needs to be adjusted.

Wolfgang


signature.asc
Description: PGP signature

Bug#943998: O_TMPFILE not available on macOS

[Clint Adams]

> FTBFS on macOS systems, because of undefined O_TMPFILE,
> which was introduced in 4.9 release.
> 
> Attempt to build was made here: 
> https://github.com/Homebrew/homebrew-core/pull/46107

Dmitry, any thoughts?  Maybe disabling --stdin on systems without O_TMPFILE?

Bug#944009: buster-pu: package ncurses/6.1+20181013-2+deb10u2

[Thomas Dickey]

On Sat, Nov 02, 2019 at 08:10:39PM +0100, Sven Joachim wrote:
> Package: release.debian.org
> Severity: normal
> Tags: buster d-i
> User: release.debian@packages.debian.org
> Usertags: pu
> 
> I would like to upload ncurses 6.1+20181013-2+deb10u2 to buster, fixing
> several bugs in tic's parser which have been reported last month.  Two
> of them are heap buffer overflows that have been assigned CVE numbers

hmm - "overflow" is the wrong term, afaik
(all of the ones that I verified were out-of-bound-reads).

> and a Debian bug[1], two others are out-of-bound-reads and one an
> infinite loop.
> 
> I have verified that the reported crashes and the infinite loop which I
> could reproduce in ncurses 6.1+20181013-2+deb10u1 appear to be fixed, at
> least with the submitted corrupt input files.  Also, the compiled
> terminfo files in ncurses-base and ncurses-term are identical to the
> ones currently in buster.
> 
> This upload touches the tinfo library which is used in the installer,
> however to the best of my knowledge the changed functions are only used
> by tic and not by any other packages.

that's accurate - comp*.c are just tic.

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: PGP signature

Bug#944012: freetds: CVE-2019-13508: Heap overflow in FreeTDS if UDT type is used with protocol 5.0

[Salvatore Bonaccorso]

Source: freetds
Version: 1.1.6-1
Severity: important
Tags: security upstream fixed-upstream
Control: found -1 1.00.104-1

Hi,

The following vulnerability was published for freetds.

CVE-2019-13508[0]:
| FreeTDS through 1.1.11 has a Buffer Overflow.


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-2019-13508
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-13508
[1] 
https://github.com/FreeTDS/freetds/commit/0df4eb82a0e3ff844e373d7c9f9c6c813925e2ac
[2] https://bugs.launchpad.net/bugs/1835896
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1736255
[4] https://bugzilla.novell.com/show_bug.cgi?id=1141132

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#944011: locales: Other Scandinavian languages should not be fallback language for Norwegian

[Samuel Thibault]

Reassign: localechooser

Hello,

Andreas Noteng, le sam. 02 nov. 2019 20:46:12 +0100, a ecrit:
> Package: locales
> 
> If installing Debian choosing Norwegian Bokmål as your system language
> the other Scandinavian langiages are defined as fallback languages if
> translations are missing:
> LANGUAGE="nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en"

This is not configured by the locales package, but by the localechooser
package, thus reassigning.

> Allthough very similar the other scandinavian languages are not suited
> as fallbacks for technical texts. I usually have to prepend LANG=C to
> whichever command I am running in these cases in order to understand the
> exact details of the messages. I suggest removing "da" and "sv" from the
> above string. If the same is the case for Norwegian Nynorsk, Swedish and
> Danish I'd suggest doing the same for those languages as well.

Samuel

Bug#857115: dconf update does not change defaults

[Changwoo Ryu]

Control: tags -1 confirmed
Control: forwarded -1 https://github.com/ibus/ibus/issues/2150
Control: severity -1 minor
Control: retitle -1 ibus: ibus-setup doesn't use the installed dconf profile

The original title was confusing. "dconf update" updates the system
dconf db file which is not necessarily the default. The problem is on
ibus-setup reading the settings. See the forwarded upstream issue.

Bug#944011: locales: Other Scandinavian languages should not be fallback language for Norwegian

[Andreas Noteng]

Package: locales
Version: 2.28-10
Severity: minor
Tags: l10n

If installing Debian choosing Norwegian Bokmål as your system language
the other Scandinavian langiages are defined as fallback languages if
translations are missing:
LANGUAGE="nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en"

Allthough very similar the other scandinavian languages are not suited
as fallbacks for technical texts. I usually have to prepend LANG=C to
whichever command I am running in these cases in order to understand the
exact details of the messages. I suggest removing "da" and "sv" from the
above string. If the same is the case for Norwegian Nynorsk, Swedish and
Danish I'd suggest doing the same for those languages as well.

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

Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:da:sv:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages locales depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc-bin   2.28-10
ii  libc-l10n  2.28-10

locales recommends no packages.

locales suggests no packages.

-- debconf information:
  locales/default_environment_locale: None
  locales/locales_to_be_generated:

Bug#944010: RM: freefem3d -- ROM; RC-bugs, no interest in the science team, dead upstream

[Anton Gladky]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On behalf of Debian Science Team I request to remove freemat package.

The package has RC-Bugs #897752 (FTBFS) and #921459 (dead upstream) and
has no an active uploader in the team. After the call [1] no interest was
identified in the team.

[1] https://lists.debian.org/debian-science/2019/09/msg00018.html

Regards,

Anton

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl291wsRHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wbpvw//TkHh6PEFmm8poj7TDyvTShY9b2MOy0PU
+5f4P77PUrCRek1zRrD7IaMZNu1+Mw0Xh4F5fkRHiUg+2VBR0IbFksJWoILn4v+H
k/YAh/IhiqaNtrpQ0f/xnwHAn3CP77KTO60yLH2BRhpzxRy1B5RD79eOzeJGo6FC
4t2YIvNGpcLthXmbqpHCNsfc32q4R0ICLkDi5d9jqTLhAxOnNwnK2GN0FS0lGYSK
ZXfgqHnR8OunrGwVVOzIBXo1zIrudmHGP474UmTf0A+JazDtfliy36UADPITkKvx
bt1zNdbviwzS+EalnKt8lFnEF/d/GV7Mn5ABp3STVIa8sKQXE4fvGLSZEfIBAyq1
T2XwMDurrBiejRX5KmzX6nLj0bxjkCLcwtcZzTeA1qgF4peHvv9hC2EFX1648hFd
edijYIvRs5jH2TymQBKvLNW0s7MWNtbqZLPU4aOprwkDTuucvmsEbKAN7++uhjzh
Gwu7eF0Zl/EfQfr5TCkChy5Sj4ow+tfAwDvGeIKazVF5n0DtWGuudnZ/K3/DDOuV
P0/UzbuSOZC75Ym1DWnVoXgk1PAwH/woRgzrgWwWZV8ZGrZxLn4Vj9GLKYkAODQP
2tiPCBjppdKFESYCqZRcjc8zpcIc53XO4rUMs4eJmYsSMsI+P2EqGeTv5Lph6e6X
WTTawMsQskY=
=OVPb
-END PGP SIGNATURE-

Bug#944009: buster-pu: package ncurses/6.1+20181013-2+deb10u2

[Sven Joachim]

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

I would like to upload ncurses 6.1+20181013-2+deb10u2 to buster, fixing
several bugs in tic's parser which have been reported last month.  Two
of them are heap buffer overflows that have been assigned CVE numbers
and a Debian bug[1], two others are out-of-bound-reads and one an
infinite loop.

I have verified that the reported crashes and the infinite loop which I
could reproduce in ncurses 6.1+20181013-2+deb10u1 appear to be fixed, at
least with the submitted corrupt input files.  Also, the compiled
terminfo files in ncurses-base and ncurses-term are identical to the
ones currently in buster.

This upload touches the tinfo library which is used in the installer,
however to the best of my knowledge the changed functions are only used
by tic and not by any other packages.

Thanks for your consideration.


1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942401

diff -Nru ncurses-6.1+20181013/debian/changelog ncurses-6.1+20181013/debian/changelog
--- ncurses-6.1+20181013/debian/changelog	2019-08-05 20:03:21.0 +0200
+++ ncurses-6.1+20181013/debian/changelog	2019-11-02 19:16:19.0 +0100
@@ -1,3 +1,20 @@
+ncurses (6.1+20181013-2+deb10u2) buster; urgency=medium
+
+  * Cherry-pick tic fixes from upstream patchlevels 20191012,
+20191015 and 20191019 (Closes: #942401).
+- Check for invalid hashcode in _nc_find_type_entry and
+  nc_find_entry (CVE-2019-17594).
+- Check for missing character after backslash in fmt_entry
+ (CVE-2019-17595).
+- Check for acsc with odd length in dump_entry in check for
+  one-one mapping.
+- Check for missing character after backslash in write_it.
+- Modify tic to exit if it cannot remove a conflicting name, because
+  treating that as a partial success can cause an infinite loop in
+  use-resolution.
+
+ -- Sven Joachim   Sat, 02 Nov 2019 19:16:19 +0100
+
 ncurses (6.1+20181013-2+deb10u1) buster; urgency=medium
 
   * Drop "rep" from xterm-new and derived terminfo descriptions
diff -Nru ncurses-6.1+20181013/debian/patches/CVE-2019-17594.diff ncurses-6.1+20181013/debian/patches/CVE-2019-17594.diff
--- ncurses-6.1+20181013/debian/patches/CVE-2019-17594.diff	1970-01-01 01:00:00.0 +0100
+++ ncurses-6.1+20181013/debian/patches/CVE-2019-17594.diff	2019-11-02 17:21:09.0 +0100
@@ -0,0 +1,37 @@
+Author: Sven Joachim 
+Description: Fix for CVE-2019-17594
+ Check for invalid hashcode in _nc_find_type_entry and nc_find_entry,
+ fix cherry-picked from upstream patchlevel 20191012.
+Bug-Debian: https://bugs.debian.org/942401
+Bug: https://lists.gnu.org/archive/html/bug-ncurses/2019-10/msg00017.html
+Forwarded: not-needed
+Last-Update: 2019-11-02
+
+---
+ ncurses/tinfo/comp_hash.c |8 ++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/ncurses/tinfo/comp_hash.c
 b/ncurses/tinfo/comp_hash.c
+@@ -63,7 +63,9 @@ _nc_find_entry(const char *string,
+ 
+ hashvalue = data->hash_of(string);
+ 
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++	&& (unsigned) hashvalue < data->table_size
++	&& data->table_data[hashvalue] >= 0) {
+ 
+ 	real_table = _nc_get_table(termcap);
+ 	ptr = real_table + data->table_data[hashvalue];
+@@ -96,7 +98,9 @@ _nc_find_type_entry(const char *string,
+ const HashData *data = _nc_get_hash_info(termcap);
+ int hashvalue = data->hash_of(string);
+ 
+-if (data->table_data[hashvalue] >= 0) {
++if (hashvalue >= 0
++	&& (unsigned) hashvalue < data->table_size
++	&& data->table_data[hashvalue] >= 0) {
+ 	const struct name_table_entry *const table = _nc_get_table(termcap);
+ 
+ 	ptr = table + data->table_data[hashvalue];
diff -Nru ncurses-6.1+20181013/debian/patches/CVE-2019-17595.diff ncurses-6.1+20181013/debian/patches/CVE-2019-17595.diff
--- ncurses-6.1+20181013/debian/patches/CVE-2019-17595.diff	1970-01-01 01:00:00.0 +0100
+++ ncurses-6.1+20181013/debian/patches/CVE-2019-17595.diff	2019-11-02 17:22:34.0 +0100
@@ -0,0 +1,36 @@
+Author: Sven Joachim 
+Description: Fix for CVE-2019-17595
+ Fix for CVE-2019-17595 cherry-picked from upstream patchlevel
+ 20191012.  Additionally to the CVE fix, this contains a check for
+ acsc with odd length in dump_entry in check for one-one mapping.
+Bug-Debian: https://bugs.debian.org/942401
+Bug: https://lists.gnu.org/archive/html/bug-ncurses/2019-10/msg00013.html
+Bug: https://lists.gnu.org/archive/html/bug-ncurses/2019-10/msg00018.html
+Forwarded: not-needed
+Last-Update: 2019-11-02
+
+---
+ progs/dump_entry.c |5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/progs/dump_entry.c
 b/progs/dump_entry.c
+@@ -1110,7 +1110,8 @@ fmt_entry(TERMTYPE2 *tterm,
+ *d++ = '\\';
+ *d = ':';
+ 			} else if (*d == '\\') {
+-*++d = *s++;
++if ((*++d = *s++) == '\0')
++break;
+ 			}
+ 			d++;
+ 			*d = '\0';
+@@ -1370,7 +1371,7 

Bug#908862: Building in reproducible build

[Thomas Goirand]

On 11/2/19 6:54 PM, Santiago Vila wrote:
> retitle 908862 neutron: FTBFS randomly (failing tests)
> thanks
> 
> Dear Thomas: Please don't put my name in the bug title like you did.
> That's a gross mischaracterization of what's really happening.

I initially wrote "Santiago Vila + reproducible build" though it got cut
at the plus ... :/ Sorry for this.

> I believe this is a race condition of some sort. You can probably
> reproduce the failure in your laptop by doing this:
> 
> taskset -c 0 dpkg-buildpackage -uc -us -A
> 
> I hope this should finally make moreinfo and unreproducible not to
> apply anymore.

I need to repair openvswitch first, as since it's missing, neutron
build-dep can't be installed (I managed to break it, somehow...).

> Disabling the tests in debian/rules if a single CPU is detected would
> probably help, but, as I've shown, the problem is not limited to
> single-CPU systems. I would bet that this also fails in your system
> if you try enough times, but we might better stop here and let upstream
> do their job at finding a proper fix.
> 
> For the Debian package, I would just disable the failing tests, as
> they do not seem to be trusted.

Disabling tests is really not what I want to do. These tests are
catching real world issues, and I do need to detect the problems.

Thomas Goirand (zigo)

Bug#936399: diodon: Python2 removal in sid/bullseye

[Oliver Sauder]

Just an update on the current progress of this issue.

Updating of waf seems to be more complicated and breaks the current build.

Instead of trying to fix those errors an upstream PR is work in progress 
to move to meson build system as many GNOME projects do as well.


See https://github.com/diodon-dev/diodon/pull/12

It is not quite finished yet and any help would be appreciated 
especially on changing the debian files to use meson instead of waf.


Oliver

Bug#943970: debmirror: Debmirror fails to verify valid, signed InRelease files

[Colin Watson]

Control: clone -1 -2
Control: reassign -2 apt
Control: retitle -2 apt: SplitClearSignedFile mishandles lines with trailing 
whitespace

On Fri, Nov 01, 2019 at 05:58:06PM -0400, John Bazik wrote:
> When debmirror splits InRelease files using split_clearsigned_file, it
> can produce text and signature files that gpgv reports as having a
> "BAD signature."  Yet gpgv reports "Good signature" for the original
> InRelease file, by itself.  What I found is that most files work but
> some do not.  Attached is a standalone split command, using the code
> from debmirror.  This is what I see when I test the debian-archive
> wheezy-backports InRelease file:

Very interesting.  It's due to the "Version: " line, with a trailing
space, in the InRelease file for wheezy-backports.

RFC 4880 section 7.1 says:

   Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
   the end of any line is removed when the cleartext signature is
   generated.

Remarkable; but we have to cope with it.  Apparently the clearsigning
process is not intended to be reversible.

As the comment notes, I translated the split_clearsigned_file function
from similar code in APT, and as far as I can see by code inspection it
has the same bug.  APT maintainers: I think you need to remove any
trailing space or tab characters from buf before writing it to
ContentFile.  There should be a message posted to #943970 shortly with a
link to my fix in debmirror.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#908862: Building in reproducible build

[Santiago Vila]

retitle 908862 neutron: FTBFS randomly (failing tests)
thanks

Dear Thomas: Please don't put my name in the bug title like you did.
That's a gross mischaracterization of what's really happening.
I'm recovering the original title, but adding the word "randomly",
meaning that it fails in some systems and it works in some others.

I believe this is a race condition of some sort. You can probably
reproduce the failure in your laptop by doing this:

taskset -c 0 dpkg-buildpackage -uc -us -A

I hope this should finally make moreinfo and unreproducible not to
apply anymore.

Disabling the tests in debian/rules if a single CPU is detected would
probably help, but, as I've shown, the problem is not limited to
single-CPU systems. I would bet that this also fails in your system
if you try enough times, but we might better stop here and let upstream
do their job at finding a proper fix.

For the Debian package, I would just disable the failing tests, as
they do not seem to be trusted.

Thanks.

Bug#927027: dcfldd: split=1000 fails on i386, armhf

[Eriberto]

Hi again Steve and Berhard,

dcfldd v1.5 was released today[1].

[1] 
https://github.com/resurrecting-open-source-projects/dcfldd/releases/tag/v1.5

I confirm that the new version is working fine now on amd64, i386 and
armhf (I did some tests over these architectures) with split=1000 in
command line. However, I got segmentation fault when running it with
autopkgtest in armhf (amd64 and i386 are ok).

I will remove the split option and close this bug (via upload).
Tomorrow, I will make tests in several architectures and file a bug
against autopkgtest package.

Thank you very much for you contribution.

Cheers,

Eriberto

Bug#944006: nginx-extras missing TLS1.3

[Florent CARRÉ]

Package: nginx-extras
Version: 1.14.2-2+deb10u1

When I modify to have exclusively TLS1.2 and TLS1.3, just TLS1.2 is available.

Steps to reproduce :
- switch to ssl_protocols TLSv1.2 TLSv1.3
- restart nginx
- curl -v --tlsv1.3 mydomain.com

I obtain :
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, protocol version (582):
* error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version
* Closing connection 0
curl: (35) error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert
protocol version

And it's available in openssl : openssl ciphers -v | grep " TLSv1\.3 "
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any  Au=any
Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any  Au=any  Enc=AESGCM(128) Mac=AEAD

Regards

Bug#944007: libobject-remote-perl: test failure with Moo 2.003006

[gregor herrmann]

Source: libobject-remote-perl
Version: 0.004000-1
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As first seen on ci.debian.net, libobject-remote-perl's test fail:

https://ci.debian.net/packages/libo/libobject-remote-perl/unstable/amd64/
https://ci.debian.net/data/autopkgtest/unstable/amd64/libo/libobject-remote-perl/3296702/log.gz

Test Summary Report
- ---
t/await.t   (Wstat: 65280 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/basic.t   (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/basic_data.t  (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/bridged.t (Wstat: 256 Tests: 1 Failed: 1)
  Failed test:  1
  Non-zero exit status: 1
t/chained.t (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/fatnode.t (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: Bad plan.  You planned 1 tests but ran 0.
t/not_found.t   (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/objects.t (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/sender.t  (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/tied.t(Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/timeout.t (Wstat: 256 Tests: 2 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
t/transfer.t(Wstat: 1536 Tests: 6 Failed: 6)
  Failed tests:  1-6
  Non-zero exit status: 6
t/watchdog.t(Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
t/watchdog_fatnode.t (Wstat: 65280 Tests: 0 Failed: 0)
  Non-zero exit status: 255
  Parse errors: No plan found in TAP output
Files=19, Tests=76,  9 wallclock secs ( 0.06 usr  0.02 sys +  4.98 cusr  0.55 
csys =  5.61 CPU)
Result: FAIL


The same happens during a local build.

The same can be seen on cpantesters (for perl 5.13.6):
http://matrix.cpantesters.org/?dist=Object-Remote%200.004000;os=linux;perl=5.31.6;reports=1


Looking at the logs both from ci.debian.net and cpantesters.org
indicates that to upgrade of Moo / libmoo-perl from 2.003004 to 2.003006
caused the breakage; so this may well be a bug in Moo.


Cheers,
gregor

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAl29uslfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgZNMg/9EWK1vlkVZBEIKFfi8G9l5iN6NBMY4mD7ZYpQgKqccUPrcRXAfA5KzvjB
fWZhTENm2c9xr0CC3cy3Q2AP8/CalZxwIDQzDHouSkozZF/3DwmynDhRRMyhCyXm
VAiaASEyByOWTLMvDhAGVqlt3SWYjUpaESWkPfGA0DjTno3Pg9M3C0YnTjL7VNr0
N5yj/TA01/noPraO23VY1KUrSQf7YvNcDkwr8NmnYw3ZJWLXIonKlaYS4m8l0X12
JTDVWCwDp5+qx6E/FhGxZGhweI4rgUQkZwXmxGKJ2AXwbnylpfQkK0gqHDQtwrf6
x4TJk+v434CboWjhGWXFr24z2YbIC0xV3PgPlJgEZC4Mi8keROHOLMLeh8Zf8W/K
NAJS5f3OJLw3BDg216VXWpUBiSrrb9V3lzLSAzCsSRVd6H0hwMxQheLJzNpKU2Pm
cErphYd6knyU4XhB+wPjsmabYtwYgsYwbfSmt5i8DnoIvTExdl8dzRIh5l+DW760
AoCnfSgGFAmjiEQqUNFoZc4iNruieQuc9jYXcbZtkRQreB/Cm6paehjrJ7IaA+VR
Trkiq2/uRdq/nRqX2M47fI4BgGihjiGX5V0k/PHF/X3smCxQPD4pnF4JyTiFxwLv
6jyklkw9DKds0E09xBs5sKPqY6iNnMoTNkUuyrYa5XYLRWAgbgY=
=TrL4
-END PGP SIGNATURE-

Bug#943974: [debian-mysql] Bug#943974: mariadb-server-10.3: as "service mysql stop" fails, system refuse to shut down

[Patrice Duroux]

On Sat, 2 Nov 2019 13:11:27 +0100 Eric Valette  wrote:
> On 02/11/2019 13:03, Otto Kekäläinen wrote:
> > Control: tags-1 moreinfo
> > 
> > Hello!
> > 
> > Thanks for reporting! Unfortunately you report does not include
> > anything useful for debugging. Please provide some log output from
> > system and mariadb logs, what files you have, maybe something how your
> > system is customized etc. The default MariaDB install does not hang
> > out-of-the-box, there is something special going on this particular
> > system.
> > 
> 
> I cannot keep a system that does not properly shutdown so I removed it. 
> The only dependency I had on it is experimental
> akonadi-backend-mysql. I do not use database on this system and
> mysql was pulled due to broken dependency on akonadi-backend-sqlite
> 
> Before that I removed everyting with a purge and reinstalled. No change. 
> You have another report that says mariadb does crash and becomes 
> irresponsive and that there is no dbg files.
> 
> Removing it is not even possible simply I had to hack prerm file to not 
> do the stop...
> 
> --eric
> 

Hi,

Do not hesitate to read my post @debian-user here:
https://lists.debian.org/debian-user/2019/10/msg01181.html

there are some clues about this I think.

Regards,
Patrice

Bug#944005: ffmpeg: please provide a version of ffmpeg with opencl support

[Rogério Brito]

Package: ffmpeg
Version: 7:4.2.1-1
Severity: wishlist

It seems that ffmpeg has supported opencl for filters for quite some time
now and it would really rock if such support were compiled into Debian's
build.

If not desired in the regular package, perhaps such support could be added
to one of the -extra packages?


Thanks for all the work with ffmpeg,

Rogério Brito.


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

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

Versions of packages ffmpeg depends on:
ii  libavcodec587:4.2.1-1
ii  libavdevice58   7:4.2.1-1
ii  libavfilter77:4.2.1-1
ii  libavformat58   7:4.2.1-1
ii  libavresample4  7:4.2.1-1
ii  libavutil56 7:4.2.1-1
ii  libc6   2.29-2
ii  libpostproc55   7:4.2.1-1
ii  libsdl2-2.0-0   2.0.10+dfsg1-1
ii  libswresample3  7:4.2.1-1
ii  libswscale5 7:4.2.1-1

ffmpeg recommends no packages.

Versions of packages ffmpeg suggests:
pn  ffmpeg-doc  

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#924705: Please enable PKCS8_PRIVATE_KEY_PARSER

[Andreas Henriksson]

Control: forcemerge 924705 941098
Control: block 941651 by 924705
Control: affects 924705 iwd

Hi,

This issue was discussed today on #debian-kernel and there was a request
to add more information about its usage. Quoting what Lev has already
written in plain text below (as his html mail is not displayed very
well by the bug tracking software).

On Fri, Nov 01, 2019 at 02:32:52PM +0300, Lev Abashkin wrote:
> This feature is used by iwd for enterprise network connections.
> I had to recompile kernel to be able to use iwd in my scenario.
> Ubuntu kernel has already turned it on.

The iwd (replacement/competitor to wpa_supplicant) relies on
lots of in-kernel functionality, instead of duplicating it in
userspace. That includes the kernel crypto.

The pkcs8 parser is needed for wpa2 enterprise network connections
and without it you simply can't connect to those kind of networks.
(Connecting to wpa2 personal still works however.)

If you need more detailed information on exactly how this works I'd
recommend you talk directly to iwd upstream. They can be reached
via irc in #iwd on FreeNode, mailinglist iwd at lists.01.org (moderated
for non-subscribers), etc.

I'm merging a duplicate with similar message. Also there's apparently
no auto-module-loading for this and no nice way to handle failures, so
iwd upstream decided to cope with this by always shipping a snippet
that tries to load the pkcs8 private key parser module in case it's
built as a module. That means currently users of iwd gets a warning
about failure to load the module on the default debian kernel (which I
think is reasonable to give them a hint that something is actually not
fully set up for all kind of wifi functionality on their system). This
bug was set as a blocker for the reported problem in iwd, although I
don't really see anything to do on the iwd side.

Regards,
Andreas Henriksson

Bug#943959: mailscripts: add decryption capability for email-print-mime-structure

[Sean Whitton]

Hello,

On Sat 02 Nov 2019 at 01:34AM -04, Daniel Kahn Gillmor wrote:

> OK, done with a series of 8 patches.  (plus one trailing 9th patch that
> updates the manpage).
>
> you can also find them in my salsa repo where you might expect them.
>
> Thanks for considering them!

Thanks for the contribution!

I used `M-x notmuch-extract-thread-patches` from mailscripts to apply
them :D

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#943962: [debian-mysql] Bug#943962: mariadb-server-10.3: mysqld crashes and hangs, no longer processing requests

[Richard van den Berg]

I had looked at https://wiki.debian.org/HowToGetABacktrace but I might
be missing something obvious.

https://packages.debian.org/search?keywords=mariadb-server-core-10.3
shows mariadb-server-core-10.3-dbgsym to be only available for sid, but
I am on buster.

# apt update
Hit:4 http://deb.debian.org/debian-debug buster-debug InRelease
Get:9 http://deb.debian.org/debian-debug buster-proposed-updates-debug
InRelease [40.2 kB]
Get:12 http://deb.debian.org/debian-debug
buster-proposed-updates-debug/main amd64 Packages [59.9 kB]

# apt install mariadb-server-core-10.3-dbgsym
Reading package lists... Done
Building dependency tree  
Reading state information... Done
Package mariadb-server-core-10.3-dbgsym is not available, but is
referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

E: Package 'mariadb-server-core-10.3-dbgsym' has no installation candidate

# apt-cache search mariadb-server-core dbg

# find-dbgsym-packages /usr/sbin/mysqld
W: No dbg package for source 'libgpg-error'
W: Cannot find debug package for /lib/x86_64-linux-gnu/libgpg-error.so.0
(0b8984cf2f0dd4f4901e9100cdb9410d7ebe7930)
W: No dbg package for source 'systemd'
W: Cannot find debug package for /lib/x86_64-linux-gnu/libsystemd.so.0
(6793bb7adf4f0ec3b4e32e8fa455f8f404670c9a)
W: No dbg package for source 'libgcrypt20'
W: Cannot find debug package for /lib/x86_64-linux-gnu/libgcrypt.so.20
(c698702313bfded270bf0c7c106b38c66aa46982)
W: No dbg package for source 'snappy'
W: Cannot find debug package for
/usr/lib/x86_64-linux-gnu/libsnappy.so.1
(5cace6e4a1b7e4056635f7c863aca22a16c8269e)
W: No dbg package for source 'mariadb-10.3'
W: Cannot find debug package for /usr/sbin/mysqld
(9236e06e9ef547c2834e1485de16215016ee3a78)
W: No dbg package for source 'libaio'
W: Cannot find debug package for /usr/lib/x86_64-linux-gnu/libaio.so.1
(9a169b1c42a22a3575cdda12b7bed7d99e72221c)
W: No dbg package for source 'xz-utils'
W: Cannot find debug package for /lib/x86_64-linux-gnu/liblzma.so.5
(a465b446328312ea341abff3436660ef4103479a)
libgcc1-dbg liblz4-1-dbg libpcre3-dbg libstdc++6-8-dbg zlib1g-dbg

Bug#944004: talloc: Please reenable python3-talloc on hurd-i386

[Samuel Thibault]

Source: talloc
Version: 2.3.0-2
Severity: important
Tags: patch

Hello,

The python3-talloc package build is currently disabled on hurd-i386, I
don't really see why? It just builds fine. Could you re-enable it as the
attached patch does?

Thanks,
Samuel

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

Kernel: Linux 5.3.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- 
Samuel
 PS> Salut ! J'ai un sujet de philo à vous soumettre : "Suffit-il
 PS> d'observer pour connaître" Idées + plan Merçi
 Oui, ya qu'a t'observer pour connaître le fait que tu es une feignasse.
 -+- FF in: Guide du Neuneu d'Usenet - Neuneu fait de la philo -+-
--- debian/control.original 2019-11-02 16:55:05.574565810 +0100
+++ debian/control  2019-11-02 16:55:08.864566219 +0100
@@ -43,7 +43,7 @@
 Package: python3-talloc
 Multi-Arch: same
 Section: python
-Architecture: linux-any kfreebsd-any
+Architecture: any
 Depends: libtalloc2 (= ${binary:Version}),
  ${misc:Depends},
  ${python3:Depends},

Bug#937552: pysvn: Python2 removal in sid/bullseye

[Peter Green]

Severity 937552 serious
Thanks

pysvn build-depends on the python-cxx-dev binary package, which is no longer 
built by the the python-cxx-dev source package.

Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream

[intrigeri]

Hi,

Guillem Jover:
> On Sat, 2019-07-27 at 12:20:00 -0300, intrigeri wrote:
>> gregor herrmann:
>> > In dpt-new-upstream we're using Dpkg::Changelog::Debian from
>> > libdpkg-perl, which might help here as well.

>> Oh, this is very interesting, thanks! I had taken a look at that
>> module, but from the documentation I understood it only gives us "the
>> number of changelog entries that have been parsed with success", so
>> I had discarded this option.

> If the documantion was not clear, I'd be happy to try to improve it so
> that other people do not get this impression too. Could you cover a bit
> what lead you to that conclusion?

Back then I had read only `perldoc Dpkg::Changelog::Debian`, which
documents one method:

$c->parse($fh, $description)
Read the filehandle and parse a Debian changelog in it. The data in
the object is reset before parsing new data.

Returns the number of changelog entries that have been parsed with
success.

I understood only later that "See also: Dpkg::Changelog" was not
optional :)

Cheers,
-- 
intrigeri

Bug#944003: apparmor: Fails to build for python 3.8

[intrigeri]

Source: apparmor
Version: 2.13.3-6
Severity: important
Tags: sid bullseye
X-Debbugs-Cc: Matthias Klose 

As discovered on #942663, src:apparmor fails to build for python 3.8.

Example failure log¹:

  configure:4690: gcc -o conftest -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -I/usr/include/python3.8 -I/usr/include/python3.8 
-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now conftest.c  
-L/usr/lib/python3.8/config-3.8-x86_64-linux-gnu -L/usr/lib  -lcrypt -lpthread 
-ldl  -lutil -lm -lm  >&5
  /usr/bin/ld: /tmp/cc08CYZS.o: in function `main':
  ./libraries/libapparmor.python3.8/conftest.c:18: undefined reference to 
`Py_Initialize'
collect2: error: ld returned 1 exit status

Those Py_Initialize() calls can be found there:

 - upstream Git: libraries/libapparmor/m4/ac_python_devel.m4

 - upstream tarball: libraries/libapparmor/configure

Dear upstream & Ubuntu folks, I probably won't be able to investigate
this further in the next weeks, so help would be warmly welcome.

[1] 
https://launchpadlibrarian.net/447332483/buildlog_ubuntu-focal-amd64.apparmor_2.13.3-5ubuntu2_BUILDING.txt.gz

Cheers,
-- 
intrigeri

Bug#942663: [pkg-apparmor] Bug#942663: apparmor b-d's on python3-all-dev, but only builds for the default version

[intrigeri]

Hi Matthias,

Matthias Klose:
> apparmor b-d's on python3-all-dev, but only builds for the default version. 
> This 
> makes it harder to prepare python transitions. Please build for all supported 
> python versions.

> Example build log at
> https://launchpad.net/ubuntu/+source/apparmor/2.13.3-5ubuntu2/+build/17926986

My understanding of this build log is that:

 - src:apparmor's debian/rules does try to build for all
   supported python3's

 - The build for python 3.8 fails with:
   ./libraries/libapparmor.python3.8/conftest.c:18: undefined reference to 
`Py_Initialize'
   As you noted in another bug report, this should fail the build
   (set -e) but does not. I've applied your patch in sid so I hope
   it's now fixed, as in: this specific failure should now make the
   package FTBFS, which is more correct feedback.

 - The build for python 3.7 succeeds.

So, it seems to me that:

 - "only builds for the default version" is incorrect, this bug
   report is therefore invalid, and should be closed.

 - src:apparmor fails to build for python 3.8, which is itself
   a bug. I'll report it right away so it's tracked.
   FTR, the call to Py_Initialize seems to come from
   libraries/libapparmor/m4/ac_python_devel.m4 in upstream Git;
   it can also be found in libraries/libapparmor/configure
   in the upstream tarball (bold guess: the former is used to
   generate the later at upstream release time).

Did I misunderstand something?

Cheers,
-- 
intrigeri

Bug#943979: postgresql-12-pg-checksums: Shouldn't it upgrade to this version when upgrading to postgresql.*-12?

[Christoph Berg]

Re: Diederik de Haas 2019-11-01 
<157264840605.3603.15284332434643955256.report...@bagend.home.cknow.org>
> I just upgraded my postgresql packages from version 11 to 12, but this
> package wasn't upgraded with it, I had to manually install it.
> Not a problem in itself, but it makes sense to me if it was upgraded
> alongside the other postgresql packages.

Hi,

the problem here is that this isn't a upgrade in the strict sense -
the package name changes, and it makes sense to allow both packages to
be installed in parallel. Apt doesn't know that installing
postgresql-12 next to postgresql-11 should imply installing all
postgresql-12-* packages that were installed in the postgresql-11-*
variant.

The "proper" fix here would be to create meta packages for all
PostgreSQL extensions, but having even more tiny (or empty) packages
wouldn't be very pretty.

See also #703850.

Christoph

Bug#943509: libsqlite3 (Re: Bug#943509: python-django: FTBFS due to failed tests: failures=7, skipped=891, expected failures=4)

[ISHIKAWA,chiaki]

Dear Laszló,

Thank you for your e-mail.

(Sorry my local system does not seem to have the correct font for the 
character in your name, and so I am not sure if I am writing the name 
correctly.

I hope it will show correctly on your end.)

My comments inline:

On 2019/11/01 23:44, László Böszörményi (GCS) wrote:

Hi Chiaki,

On Thu, Oct 31, 2019 at 9:09 PM ISHIKAWA,chiaki  wrote:

I vouch that there seems to be a serious issue in libsqlite3 3.30.1-1.

  It's not that fatal like it may seem so.

I wish that is  the case.

I came here because it seems that I have an issue with sqlite3 on my
linux installation.
The problem manifested as database operation failures during thunderbird
mail client regression testing (called mach xcpshell-tests|)

  Is there a documented way to get and run it locally?


There is a series of documents.
However, it is such a long winding path, it may take a few days to set 
up and  run correctly.

I can't really suggest that you take the steps outlined below casually.

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Simple_Thunderbird_build

My summary is as follows.

First you have to download the source for C-C (comm-central) AND M-C 
(mozilla-central.)

M-C should be installed somewhere with mozilla directory name.
C-C needs to be installed as comm immediately below mozilla directory.

Then you have to configure the development environment.
Setting environment variables and configuration file and set an 
environment variable, MOZCONFIG,

that points to the config file.
You have to specify the MOZ_OBJDIR that stores the generated binary: 
this object directory MUST be

outside the source tree.

Before building,
you have to download a series of debian package header files and 
libraries (i.e., development library packages) that are used by

the thunderbird build process.
There are a lot actually under Debian that we need to install on top of 
regular installation.


*THEN*
We run the compilation process using so-called |../mach build| command 
in the C-C topmost directory (comm) immediately below M-C (mozill)a 
directory.


This command will likely suggest that we need to install clang c++ 
compiler and rust compiler with many packages.

It prints out the commands how to perform these actions. So I follow it.

Once the compilation is successful, we can finally run
xpcshell test by

cd $MOZOBJ || exit 1

...    mozilla/mach --log-no-times xpcshell-test

where mach command is in the mozilla source directory (M-C).

Build takes about 1 hour on my Ryzen1700 with 16GB memory.
(Actually, Debian GNU/Linux amd64 image that runs inside VirtualBox that 
runs on top Windows10 Pro 64 bit)


If you really are interested, I can help.

There are all sorts of minor issues that pop up from time to time when 
we use open source tools and libraries.
Usually error messages are clear, but sometimes python and other script 
language errors pop up and they are difficult to analyze.




I looks someone on Ubuntu did not see it this month and mozilla's
compilation and testing farm machines do not seem to see it. They run
CentOs if I am not mistaken.

  Which version of CentOS? Its latest release, versioned 8 has SQLite3
3.26.0 if I'm not mistaken.


Oh, I was wrong. The compilation/test farm machines have transitioned to 
Ubuntu sometime before.
I did not know that. Maybe we can know what sqlite3 version is working 
there.

I see the following version info of OS. It seems a very old OS package.

[task 2019-10-31T22:44:44.290Z] ++ NAME=Ubuntu
[task 2019-10-31T22:44:44.290Z] ++ VERSION='16.04.5 LTS (Xenial Xerus)'
[task 2019-10-31T22:44:44.290Z] ++ ID=ubuntu
[task 2019-10-31T22:44:44.290Z] ++ ID_LIKE=debian
[task 2019-10-31T22:44:44.290Z] ++ PRETTY_NAME='Ubuntu 16.04.5 LTS'
[task 2019-10-31T22:44:44.291Z] ++ VERSION_ID=16.04

from 
https://taskcluster-artifacts.net/OtJtVGBiQkax0LeOVJAcbw/0/public/logs/live_backing.log

This is from a build/test job submission result:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central=e1c9f00a40034361a9a3b6c4abdf0807e22c5d7e

Mozilla has a rather nice build/test farm setup.




https://bugzilla.mozilla.org/show_bug.cgi?id=1589779

So I thought maybe the current installation of libsqlite3 on my linux PC
was to blame.

  Might be, but SQLite3 3.30.1 should be safe.

I am still trying to find out what changed between latest August and 
beginning of October.


It can be

- my PC environment changes (including package updates), or
- even testing environment change (but unlikely).

Since someone under Ubuntu told me the test works there without an 
issue, I think

local package version issue is more like it.


Well, it looks that is the case if I read the exchanges here correctly.
My libsqlite3 seems to be affected: the version is 3.30.1-1
(The problem was not observed in August. I am not sure if the upgrade of
libsqlite3 happened during then and now.)

What do people suggest that best course of action under the circumstances?

Bug#944002: buster-pu: package libreoffice/1:6.1.5-3+deb10u5

[Rene Engelhard]

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

Hi,

I think we should fix #943873 in stable since even though stable has
PostgreSQL 11 people might use it against some other server having
12...

Debdiff attached. (Patch from 1:6.3.3-2 cherry-picked.)

Regards,

Rene
diff --git a/changelog b/changelog
index d5983949..a78024d8 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,11 @@
+libreoffice (1:6.1.5-3+deb10u5) buster; urgency=medium
+
+  * debian/patches/Postgresql-12-no-adsrc.diff: add from
+libreoffice-6-3 branch; fix the postgresql driver with
+PostgreSQL 12 (closes: #943873)
+
+ -- Rene Engelhard   Thu, 31 Oct 2019 18:26:41 +0100
+
 libreoffice (1:6.1.5-3+deb10u4) buster-security; urgency=medium
 
   * debian/patches/expand-pyuno-path-separators.diff.
diff --git a/patches/Postgresql-12-no-adsrc.diff 
b/patches/Postgresql-12-no-adsrc.diff
new file mode 100644
index ..76275ade
--- /dev/null
+++ b/patches/Postgresql-12-no-adsrc.diff
@@ -0,0 +1,128 @@
+From 0872f7dc87445f81afd56b5a096d026df75d3a05 Mon Sep 17 00:00:00 2001
+From: Julien Nabet 
+Date: Sun, 13 Oct 2019 00:26:10 +0200
+Subject: tdf#128111: "adsrc" doesn't exist from Postgresql 12
+
+Before Postgresql 8.0, there was only "adsrc"
+then it's been deprecated
+"The adsrc field is historical, and is best not used, because it does not 
track outside changes
+ that might affect the representation of the default value.
+ Reverse-compiling the adbin field (with pg_get_expr for example) is a better 
way to display the default value
+"
+and finally it's been removed with version 12
+
+See evolution with:
+- https://www.postgresql.org/docs/8/catalog-pg-attrdef.html
+- https://www.postgresql.org/docs/11/catalog-pg-attrdef.html
+- https://www.postgresql.org/docs/12/catalog-pg-attrdef.html
+
+Merge with 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=1ec93ef100bb5f6ccef91f12e28ed09feb3eb38b
+
+Change-Id: I57e9da423a23b5a96bbb64b0e026b160e9643ab9
+Reviewed-on: https://gerrit.libreoffice.org/80722
+(cherry picked from commit 0c46c81e04530e8f6ce4f34195d8f0443ed8bfc3)
+Reviewed-on: https://gerrit.libreoffice.org/80736
+Tested-by: Jenkins
+Reviewed-by: Julien Nabet 
+---
+ connectivity/source/drivers/postgresql/pq_databasemetadata.cxx |  6 +++---
+ connectivity/source/drivers/postgresql/pq_statement.cxx| 10 ++
+ connectivity/source/drivers/postgresql/pq_tools.cxx|  7 +++
+ connectivity/source/drivers/postgresql/pq_tools.hxx|  2 ++
+ 4 files changed, 18 insertions(+), 7 deletions(-)
+
+diff --git a/connectivity/source/drivers/postgresql/pq_databasemetadata.cxx 
b/connectivity/source/drivers/postgresql/pq_databasemetadata.cxx
+index 10c8546..8af02f9 100644
+--- a/connectivity/source/drivers/postgresql/pq_databasemetadata.cxx
 b/connectivity/source/drivers/postgresql/pq_databasemetadata.cxx
+@@ -1514,7 +1514,7 @@ css::uno::Reference< XResultSet > 
DatabaseMetaData::getColumns(
+ //allow NULL values. An empty string means
+ //nobody knows.
+ //   => pg_attribute.attnotnull
+-
++OUString strDefaultValue = getColExprForDefaultSettingVal(m_pSettings);
+ Reference< XPreparedStatement > statement = m_origin->prepareStatement(
+ "SELECT pg_namespace.nspname, "  // 1
+ "pg_class.relname, " // 2
+@@ -1524,8 +1524,8 @@ css::uno::Reference< XResultSet > 
DatabaseMetaData::getColumns(
+ "pg_attribute.attnotnull, "  // 6
+ "pg_type.typdefault, "   // 7
+ "pg_type.typtype, "  // 8
+-"pg_attrdef.adsrc, " // 9
+-"pg_description.description, "   // 10
+++ strDefaultValue +  // 9
++",pg_description.description, "   // 10
+ "pg_type.typbasetype, "  // 11
+ "pg_attribute.attnum "   // 12
+ "FROM pg_class, "
+diff --git a/connectivity/source/drivers/postgresql/pq_statement.cxx 
b/connectivity/source/drivers/postgresql/pq_statement.cxx
+index 7796cac..79930e2 100644
+--- a/connectivity/source/drivers/postgresql/pq_statement.cxx
 b/connectivity/source/drivers/postgresql/pq_statement.cxx
+@@ -631,10 +631,12 @@ static void getAutoValues(
+ String2StringMap & result,
+ const Reference< XConnection > & connection,
+ const OUString ,
+-const OUString & tableName )
++const OUString & tableName,
++ConnectionSettings *pConnectionSettings )
+ {
++OUString strDefaultValue = 
getColExprForDefaultSettingVal(pConnectionSettings);
+ Reference< XPreparedStatement > stmt = connection->prepareStatement(
+-  "SELECT   pg_attribute.attname, pg_attrdef.adsrc "
++  "SELECT   pg_attribute.attname, " + strDefaultValue +
+   "FROM pg_class, pg_namespace, pg_attribute "
+   

Bug#941093: ping!

[Norbert Preining]

On Sat, 02 Nov 2019, Mattia Rizzolo wrote:
> I filed the RM myself, I x-debbugs-cc'ed calibre@.

Thanks!

Norbert

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

Bug#944001: RM: calibre [armel, mips64el, ppc64el, s390x] -- RM: ANAIS; new build dependency not available in these architectures

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-Cc: cali...@packages.debian.org

Dear ftp-team

please drop calibre (and calibre-bin) from these architectures, since
it's not buildable anymore.  It requires qtwebengine which is not being
ported.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#941093: ping!

[Mattia Rizzolo]

On Sat, Nov 02, 2019 at 11:18:16PM +0900, Norbert Preining wrote:
> I am fine with both, but I feel like RM is necessary, since without
> qtwebengine reading ebooks does not work.
> 
> Any suggestions of what I should do?

I filed the RM myself, I x-debbugs-cc'ed calibre@.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#941093: ping!

[Norbert Preining]

Hi

On Sat, 02 Nov 2019, Dmitry Shachnev wrote:
> - calibre has missing build on armel, mips64el, ppc64el and s390x because
>   Qt WebEngine is not available there. I am CCing the calibre maintainers.
>   Either that build-dependency should be limited to the architectures where
>   Qt WebEngine is available, or an RM bug for calibre on the other
>   architectures should be filed.

I am fine with both, but I feel like RM is necessary, since without
qtwebengine reading ebooks does not work.

Any suggestions of what I should do?

Best

Norbert

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

Bug#941093: ping!

[Dmitry Shachnev]

Hi all,

On Fri, Oct 25, 2019 at 05:31:41PM +0300, Dmitry Shachnev wrote:
> s390x will be removed in #943467, and mips64el will be (hopefully) fixed
> in https://salsa.debian.org/debian/telegram-desktop/merge_requests/16
> (thanks Nicholas!).

I looked at update_output.txt and it looks like there are two issues
preventing Qt from migration:

- qgis is too young, only 2 of 5 days old;

- calibre has missing build on armel, mips64el, ppc64el and s390x because
  Qt WebEngine is not available there. I am CCing the calibre maintainers.
  Either that build-dependency should be limited to the architectures where
  Qt WebEngine is available, or an RM bug for calibre on the other
  architectures should be filed.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#936992: Upstream here: Please close this bug

[Sam Trenholme]

Upstream here: Please close this bug.

One can close this bug by removing the Python2 dependency.

MaraDNS does not use any Python, neither Python2, nor Python3, to build the
code.

MaraDNS does not use any Python to install the code.

MaraDNS does not use any Python to run the authoritative daemon, nor the
recursive daemon, nor the DNS-over-TCP daemon, nor the tool for making
recursive DNS queries.

Python is *only* used for the bind2csv2.py tool which converts Bind zone
files in to MaraDNS zone files. One can safely remove this tool without
affecting MaraDNS’s functionality.

Thank you.

Bug#942633: gitlab: Experimental gitlab requires gitshell 9.3.0 but only 9.1.0 is packaged

[Romain Bignon]

Hello,

The problem is still here, and is so not related to compatibility between
versions of gitlab/gitlab-shell/gitality…

Is there anything I can do to find the origin of this issue?

Romain

Bug#943999: Drop /usr/lib/systemd/user/sockets.target.wants/pulseaudio.socket symlink

[Laurent Bigonville]

On Sat, 02 Nov 2019 14:38:32 +0100 Laurent Bigonville  
wrote:

[...]
>
> That means that the static
> /usr/lib/systemd/user/sockets.target.wants/pulseaudio.socket symlink is
> not useless (and actually harmful as it will prevent the user to
> completely disable the socket if they want)
>

[...]

are *now* useless I meant...

Bug#944000: Please drop symlinks from /usr/lib/systemd/user/sockets.target.wants/

[Laurent Bigonville]

Source: gnupg2
Version: 2.2.14-1
Severity: normal

Hello,

With debhelper 12, dh_installsystemduser is called during the build of
the package, that means that the .service and .socket files are enabled
by default (in /etc/systemd/user)

That also means that the static /usr/lib/systemd/user/sockets.target.wants/
symlinks are now useless (and actually harmful as it will prevent the
user from completely disable the sockets if they want)

Please stop creating these symlinks

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.3.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Bug#943999: Drop /usr/lib/systemd/user/sockets.target.wants/pulseaudio.socket symlink

[Laurent Bigonville]

Source: pulseaudio
Version: 12.99.2-1
Severity: normal

Hello,

With debhelper 12, dh_installsystemduser is called during the build of
the package, that means that the .service and .socket files are enabled
by default (in /etc/systemd/user)

That means that the static
/usr/lib/systemd/user/sockets.target.wants/pulseaudio.socket symlink is
not useless (and actually harmful as it will prevent the user to
completely disable the socket if they want)

Please stop creating that symlink

Kind regards,

Laurent Bigonville

-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.3.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; enable-memfd = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architecture)

; load-default-script-file = yes
; default-script-file = /etc/pulse/default.pa

; log-target = auto
; log-level = notice
; log-meta = no
; log-time = no
; log-backtrace = 0

; resample-method = speex-float-1
; avoid-resampling = false
; enable-remixing = yes
; remixing-use-all-sink-channels = yes
; enable-lfe-remixing = no
; lfe-crossover-freq = 0

; flat-volumes = no

; rlimit-fsize = -1
; rlimit-data = -1
; rlimit-stack = -1
; rlimit-core = -1
; rlimit-as = -1
; rlimit-rss = -1
; rlimit-nproc = -1
; rlimit-nofile = 256
; rlimit-memlock = -1
; rlimit-locks = -1
; rlimit-sigpending = -1
; rlimit-msgqueue = -1
; rlimit-nice = 31
; rlimit-rtprio = 9
; rlimit-rttime = 20

; default-sample-format = s16le
; default-sample-rate = 44100
; alternate-sample-rate = 48000
; default-sample-channels = 2
; default-channel-map = front-left,front-right

; default-fragments = 4
; default-fragment-size-msec = 25

; enable-deferred-volume = yes
; deferred-volume-safety-margin-usec = 8000
; deferred-volume-extra-delay-usec = 0
#!/usr/bin/pulseaudio -nF
#
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software 

Bug#943998: O_TMPFILE not available on macOS

[dawidd0811]

Package: debianutils
Version: 4.9

FTBFS on macOS systems, because of undefined O_TMPFILE,
which was introduced in 4.9 release.

Attempt to build was made here: 
https://github.com/Homebrew/homebrew-core/pull/46107

Bug#943981: Proposal: Switch to cgroupv2 by default

[Michael Biebl]

Hi Noah

Am 02.11.19 um 00:05 schrieb Noah Meyerhans:
> I'd like to propose that we switch to cgroupv2 as the default
> configuration for the bullseye release.  This has the potential to
> impact quite a few packages (notably, it breaks Docker today), so I

Afaics, lxc is also affected, which is quite an issue, given that our CI
is based on LXC (on stable though, so this would only affect bullseye if
we decided to stick with v2).

> don't think it can be done without engaging with a broader subsection of
> the developer community, but this seems like a reasonable place to
> start.  By making this transition soon, I expect that we can iron out
> the issues well in advance of the bullseye release.
> 
> Detailed documentation of cgroupv2 can be found at
> https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html, with
> rationales and comparison against v1 documented under the "Issues with
> v1 and Rationales for v2" heading.
> 
>>From systemd's perspective, the switch may be as simple as adding
> "-Ddefault-hierarchy=unified" to the configuration options in
> debian/rules.  A minimal patch to implement this change is attached.


Fwiw, systemd in experimental already defaults to cgroupv2 (it's the
default since v243), which is why I haven't uploaded it to unstable yet.

We'll have to work out a plan how to best proceed here.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#943953: linux: DKMS module builds are failing on arm64 due to lack of armhf cross-compiler

[Ben Hutchings]

Control: tag -1 moreinfo patch

I already communicated this via IRC, but I thought it should be logged
in the BTS too: I have a tentative fix for this in <
https://salsa.debian.org/benh/linux.git> branch bug943953.  I don't
have an arm64 system to test it on though.

Ben.

-- 
Ben Hutchings
Humans are not rational beings; they are rationalising beings.



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

Bug#943974: [debian-mysql] Bug#943974: mariadb-server-10.3: as "service mysql stop" fails, system refuse to shut down

[Eric Valette]

On 02/11/2019 13:03, Otto Kekäläinen wrote:

Control: tags-1 moreinfo

Hello!

Thanks for reporting! Unfortunately you report does not include
anything useful for debugging. Please provide some log output from
system and mariadb logs, what files you have, maybe something how your
system is customized etc. The default MariaDB install does not hang
out-of-the-box, there is something special going on this particular
system.



I cannot keep a system that does not properly shutdown so I removed it. 
The only dependency I had on it is experimental

akonadi-backend-mysql. I do not use database on this system and
mysql was pulled due to broken dependency on akonadi-backend-sqlite

Before that I removed everyting with a purge and reinstalled. No change. 
You have another report that says mariadb does crash and becomes 
irresponsive and that there is no dbg files.


Removing it is not even possible simply I had to hack prerm file to not 
do the stop...


--eric

Bug#943974: [debian-mysql] Bug#943974: mariadb-server-10.3: as "service mysql stop" fails, system refuse to shut down

[Otto Kekäläinen]

Control: tags-1 moreinfo

Hello!

Thanks for reporting! Unfortunately you report does not include
anything useful for debugging. Please provide some log output from
system and mariadb logs, what files you have, maybe something how your
system is customized etc. The default MariaDB install does not hang
out-of-the-box, there is something special going on this particular
system.

Bug#934599: Quote needed

[Jerry Wilson]

  Good day,
  
  Can you please provide me with quote for the below.
 7 HP 651A Magenta Original LaserJet Toner Cartridge, CE343A Original
Microsoft Surface Book 2 MFR #: HN6-1 x 9
 Thank you
 Jerry Wilson
Director of Purchasing
Contemporary Plan
2741 W 21st St,
Erie, PA 16506
814 208 9313
www.contemporaryplan.com 

Bug#943962: [debian-mysql] Bug#943962: mariadb-server-10.3: mysqld crashes and hangs, no longer processing requests

[Otto Kekäläinen]

Hello!

Yes, upstream developers will value a good trace.

Debian ships debug symbols for all packages by default. You just need
to install them from the debug repository. Maybe this helps
https://wiki.debian.org/HowToGetABacktrace ?

Bug#940575: RFS: fortran-language-server/1.10.2-1 [ITP] -- Fortran Language Server for the Language Server Protocol

[Hugo Lefeuvre]

Hi Denis,

I did a few minor changes and uploaded.

Upstream published 1.10.3 recently, you might want to package it.
No need to open RFSs in the future, just send me an e-mail.

Please, don't forget to update upstream and pristine-tar branches/to push
them. :)

I will close this bug once ftpmasters have accepted the package.

cheers,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C


signature.asc
Description: PGP signature

Bug#885302: gtklick: Depends on unmaintained pygtk

[Moritz Mühlenhoff]

On Fri, Dec 29, 2017 at 12:23:22PM +0100, Jaromír Mikeš wrote:
> >
> > pygtk is unmaintained upstream. It has not had a release since GNOME 3
> > was released in 2011.
> >
> > The way forward is to port your app to use GObject Introspection
> > bindings.
> 
> ​Hi Dominic,
> 
> there is a serious issue with gtklick in debian.
> Is there any chance get this fixed and avoid pygtk dependency?

Was there any followup, should gtklick be removed?

Cheers,
Moritz

Bug#943996: llvm-9 now depends on libz3-4

[Sylvestre Ledru]

Le 02/11/2019 à 12:09, Paolo Greppi a écrit :

Hi Sylvestre and many thanks for the prompt response, see below.

On 02/11/19 11:59, Sylvestre Ledru wrote:

Hello,


Le 02/11/2019 à 11:52, Paolo Greppi a écrit :

Package: llvm-9
Version: 1:9.0.0-3
Severity: normal

[...]

This does not seem right.

Why? z3 is a solver used to improve the static analysis results.

I enabled it in 9-3

Cheers,
Sylvestre

Ah OK !

Then one of llvm-9-dev, libclang-9-dev or clang-9 musg depend on libz3-dev 
because my build does not find /usr/lib/x86_64-linux-gnu/libz3.so:


Right! Thanks

I just pushed a fix in the vcs

Sylvestre

Bug#943997: d-shlibs: Please support libpython3-dev

[Hideki Yamane]

Package: d-shlibs
Severity: important
Tags: patch

Dear Maintainer,

 During python3 transition for fontforge, I've found d-shlibs doesn't
 support it.

>d-shlibmove --commit \
>--devunversioned \
>--exclude-la \
>--extralib debian/tmp/x/usr/lib/libgunicode.so \
>--extralib debian/tmp/x/usr/lib/libgutils.so \
>--movedev "debian/tmp/x/usr/include/*" usr/include/ \
>--movedev "debian/tmp/x/usr/lib/pkgconfig/*.pc" 
> usr/lib/x86_64-linux-gnu/pkgconfig \
>--override s/libfontforge3-dev/libfontforge-dev/ \
>debian/tmp/x/usr/lib/libfontforge.so
>Library package automatic movement utility
> --> libfontforge-dev package from same source package.
(snip)
> --> libpng-dev package exists.
>devlibs error: There is no package matching [libpython3.7m1.0-dev] and noone 
>provides it, please report bug to d-shlibs maintainer
(snip)
> --> zlib1g-dev package exists.
>make: *** [debian/rules:64: debian/stamp-local-shlibs-libfontforge] Error 1

 It provides the value as libpython3.7m1.0-dev, not libpython3-dev, so
 I've tried to made a patch for it. Could you review it, please?
>From 381d711c89e0670510b119890eb55093c8e6c62d Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Sat, 2 Nov 2019 17:34:05 +0900
Subject: [PATCH 1/2] add libpython3.[0-9]*-dev for list

---
 d-devlibdeps | 1 +
 1 file changed, 1 insertion(+)

diff --git a/d-devlibdeps b/d-devlibdeps
index af7373d..d4debd4 100755
--- a/d-devlibdeps
+++ b/d-devlibdeps
@@ -160,6 +160,7 @@ overridedevlibdeps() {
-e 's/libpthread-stubs0-dev//' \
-e 's/libpvm3-3-dev/pvm-dev/' \
-e 's/libpython2.7-1\.0-dev/libpython-dev/' \
+   -e 's/libpython3\.[0-9].*-dev/libpython3-dev/' \
-e 's/libQtCore4-dev/libqt4-dev/' \
-e 's/libQtGui4-dev/libqt4-dev/' \
-e 's/libQt5\(\|Core\|Gui\|Widgets\)5-dev/qtdeclarative5-dev/' \
-- 
2.24.0.rc2

Bug#943996: llvm-9 now depends on libz3-4

[Paolo Greppi]

Hi Sylvestre and many thanks for the prompt response, see below.

On 02/11/19 11:59, Sylvestre Ledru wrote:
> Hello,
> 
> 
> Le 02/11/2019 à 11:52, Paolo Greppi a écrit :
>> Package: llvm-9
>> Version: 1:9.0.0-3
>> Severity: normal
> [...]
>> This does not seem right.
> 
> Why? z3 is a solver used to improve the static analysis results.
> 
> I enabled it in 9-3
> 
> Cheers,
> Sylvestre

Ah OK !

Then one of llvm-9-dev, libclang-9-dev or clang-9 musg depend on libz3-dev 
because my build does not find /usr/lib/x86_64-linux-gnu/libz3.so:

https://salsa.debian.org/debian/doxygen/-/jobs/395949

P.

Bug#943996: llvm-9 now depends on libz3-4

[Sylvestre Ledru]

Hello,


Le 02/11/2019 à 11:52, Paolo Greppi a écrit :

Package: llvm-9
Version: 1:9.0.0-3
Severity: normal

[...]

This does not seem right.


Why? z3 is a solver used to improve the static analysis results.

I enabled it in 9-3

Cheers,
Sylvestre

Bug#943996: llvm-9 now depends on libz3-4

[Paolo Greppi]

Package: llvm-9
Version: 1:9.0.0-3
Severity: normal

Dear Maintainer,

when I tried upgrading to llvm-9 to build doxygen, it started to complain of 
missing /usr/lib/x86_64-linux-gnu/libz3.so
This is surprising because we never needed this:
https://packages.debian.org/sid/libz3-4

Now apt-cache rdepends libz3-4 returns:

libz3-4
Reverse Depends:
  libz3-dev
  llvm-10-tools
  llvm-10-runtime
  llvm-10
  libllvm10
  libclang1-10
  libclang-common-10-dev
  llvm-9-tools
  llvm-9-runtime
  llvm-9
  libllvm9
  libclang-common-9-dev
  libz3-jni
  libclang-common-9-dev
  llvm-9-tools
  llvm-9-runtime
  llvm-9
  libllvm9

This does not seem right.

P.S. the popcon graph for z3 is funny
https://qa.debian.org/popcon.php?package=z3

Paolo

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

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

Versions of packages llvm-9 depends on:
ii  libc6   2.29-3
ii  libgcc1 1:9.2.1-16
ii  libllvm91:9.0.0-3
ii  libpfm4 4.10.1+git14-g815ff28-1
ii  libstdc++6  9.2.1-16
ii  libtinfo6   6.1+20191019-1
ii  libz3-4 4.8.6-2
ii  llvm-9-runtime  1:9.0.0-3
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages llvm-9 recommends:
ii  llvm-9-dev  1:9.0.0-3

Versions of packages llvm-9 suggests:
pn  llvm-9-doc  

-- no debconf information

Bug#943905: gnutls28 FTCBFS during guile bindings

[Andreas Metzler]

On 2019-11-01 Andreas Metzler  wrote:
[...]
> As a hotfix I plan to upload with noguile profile support [...] after
> -3 has migrated to testing.
[...]

Done yesterday.

Bug#941060: Debian Chromium VERY out-of-date

[PeeBee]

Debian's version of Chromium is getting very out of date and insecure as 
a result


Latest version (2-nov-2019) is now: 78.0.3904.87

but Debian is only providing: 76.0.3809.100

Updates used to be provided regularly - why have they stopped?

Other distros (e.g. Arch Linux & Slackware) are able to provide current 
up-to-date versions

Bug#943994: python3-zeitgeist not compatible with python3

[Laurent Bigonville]

On Sat, 02 Nov 2019 10:31:36 +0100 Laurent Bigonville  
wrote:

[...]
>
> Looks like it's not compatible with python3.
>

Looking at the debian changelog, I personally removed that package back 
in March 2018 because it was not compatible, not sure why it was 
reintroduced:


zeitgeist (1.0.1-0.2) unstable; urgency=medium

  * Non-maintainer upload.
  * Drop python3-zeitgeist package as the binding is not compatible with
python3, for python3, GIR binding should be used instead. Reintroduce the
python2 binding for now as we still have one rdependency (Closes: #891615)
  * Avoid installing files in /usr/lib/zeitgeist/zeitgeist/, move them one
level up to /usr/lib/zeitgeist/ instead
  * Do not make the metapackge pull python-zeitgeist, this is not needed for
normal operations

 -- Laurent Bigonville   Sun, 11 Mar 2018 19:54:01 +0100

An idea?

Bug#936214: bleachbit: Python2 removal in sid/bullseye

[Matthias Klose]

On 02.11.19 09:05, Hugo Lefeuvre wrote:

Hi Matthias,

I see that you just raised the severity of this bug to serious, and
Bleachbit is now to be removed on 16.11.

I don't think this is the way to go. Upstream is actively working on this.
We have recently managed the GTK3 migration, meaning that Py3 is now top
priority.  Loosing Bleachbit would be a significant source of annoyance for
many Debian users (popcon 2754 at the moment).

May I add the py2keep flag, until the Bleachbit Py3 migration completes?


Hi,

thanks for reaching out to debian-python.  Unfortunately the pygtk py2removal 
bug (#937452) didn't see much attention, and I didn't raise the severity of this 
issue myself, just for the r-deps affecting the Python2 removal.  Pygtk will 
never be ported to Python3, so action is needed for every rdep.


You won't loose Bleachbit just because it's removed from testing for a few 
weeks/months, and I don't see any rdeps for the package itself.  Using the 
py2keep tag for packages which have a transition plan in place for bullseye 
seems to be odd, and distracts the view for packages which we apparently need to 
keep.


Lowering the severity for the bleachbit issue might be a work around, but then 
unexpected pygtk removal may bite you again.


Matthias

Bug#943995: cu2qu: missing python3-all-dev dependency (patch)

[Gianfranco Costamagna]

Source: cu2qu
Version: 1.6.6-4
Severity: serious
Justification: breaks on Python upgrade when more python3 versions are available
tags: patch

[snip]
copying Lib/cu2qu/cu2qu.c -> /<>/.pybuild/cpython3_3.8/build/cu2qu
running build_ext
building 'cu2qu.cu2qu' extension
creating build
creating build/temp.linux-amd64-3.8
creating build/temp.linux-amd64-3.8/Lib
creating build/temp.linux-amd64-3.8/Lib/cu2qu
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g 
-fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security 
-g -fwrapv -O2 -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -DCYTHON_TRACE_NOGIL=1 -I/usr/include/python3.8 -c 
Lib/cu2qu/cu2qu.c -o build/temp.linux-amd64-3.8/Lib/cu2qu/cu2qu.o
Lib/cu2qu/cu2qu.c:22:10: fatal error: Python.h: No such file or directory
   22 | #include "Python.h"
  |  ^~
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
E: pybuild pybuild:341: build: plugin distutils failed with: exit code=1: 
/usr/bin/python3.8 setup.py build "--with-cython"
dh_auto_build: pybuild --build --test-pytest -i python{version} -p "3.8 3.7" 
returned exit code 13
make: *** [debian/rules:6: build] Error 255
dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2



patch:
--- cu2qu-1.6.6/debian/control  2019-11-01 15:18:25.0 +
+++ cu2qu-1.6.6/debian/control  2019-11-02 09:30:09.0 +
@@ -8,7 +8,7 @@
 Build-Depends: debhelper-compat (= 12),
dh-python,
python3-all,
-   python3-dev,
+   python3-all-dev,
cython3 (>= 0.28.5),
python3-defcon (>= 0.6.0),
python3-fonttools (>= 3.32.0),

Bug#943994: python3-zeitgeist not compatible with python3

[Laurent Bigonville]

Package: python3-zeitgeist
Version: 1.0.2-2
Severity: serious

Hi,

When installing python3-zeitgeist, the bytecompilation fails with the
following error:


Paramétrage de python3-zeitgeist (1.0.2-2) ...
  File "/usr/lib/python3/dist-packages/zeitgeist/client.py", line 121
except dbus.exceptions.DBusException, e:
^
SyntaxError: invalid syntax

  File "/usr/lib/python3/dist-packages/zeitgeist/datamodel.py", line 144
except KeyError, e:
   ^
SyntaxError: invalid syntax

dpkg: erreur de traitement du paquet python3-zeitgeist (--configure) :
 installed python3-zeitgeist package post-installation script subprocess 
returned error exit status 1

Looks like it's not compatible with python3.

Kind regards,

Laurent Bigonville

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

Kernel: Linux 5.3.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy

Versions of packages python3-zeitgeist depends on:
ii  python3   3.7.5-1
ii  python3-dbus  1.2.12-1
ii  python3-gi3.34.0-1
ii  python3-xdg   0.25-5

python3-zeitgeist recommends no packages.

python3-zeitgeist suggests no packages.

-- no debconf information

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Jeremy Bicha]

‪On Sat, Nov 2, 2019 at 3:40 AM ‫أحمد المحمودي (Ahmed El-Mahmoudy)‬‎
 wrote:‬
> On Tue, Oct 29, 2019 at 06:24:23AM -0400, Jeremy Bicha wrote:
> > 2. Do a binary upload of the package.
>
> Can't do binary upload since it adds a new package, and I am not a DD

Yes, I will sponsor this for you.

> > 3. Ask for auto-builds to be enabled
> > 4. After all that is done, the next upload can be source-only.
> >
> > If that sounds good with you, could you make the change and then bump
> > the Debian version number? (There is no need to try to re-use the
> > tagged version number; there are lots of higher version numbers we can
> > use!).
> ---end quoted text---
>
> I didn't bump the debian version number. Why should I do so ?

If you pushed a git release tag, it is better to just bump the
version. git does not allow updating tags easily for anyone who has
already pulled the old tag. Since there are so many available version
numbers, I highly recommend just using a higher version number when a
git tag has been pushed.

In this case, I see the new tag has already been pushed so I wouldn't
worry about it here.

Thanks,
Jeremy Bicha

Bug#942085: RFS: hijra/0.4.1-2 [RC] -- Hijri Islamic Calendar converting functions for Python

[Jeremy Bicha]

‪On Sat, Nov 2, 2019 at 4:58 AM ‫أحمد المحمودي (Ahmed El-Mahmoudy)‬‎
 wrote:‬
> "1. Check wehther it is legally allowed and technically possible to
> auto-build the package"
>
> How do I check that it is legally allowed to build the non-free package ?

Some stuff in non-free have restrictive licenses that wouldn't allow
for automatic building. If you think that might be the case with
hijra, we should not enable auto building.

Thanks,
Jeremy Bicha

Bug#943993: smplayer doesn't manage time properly

[Guy Durrieu]

Package: smplayer
Version: 18.10.0~ds0-1
Severity: important

Dear Maintainer,

Due, I suppose, to a recent update, smplayer doesn't manage time 
properly anymore:


- current time and total duration are displayed as 00:00:00.
- when restarting, a video correctly restarts from a previously stored 
time (when smplayer worked normally).
- but if the video is paused, it will not restart at all; as a matter of 
fact, the displayed button from the beginning is always |>, not ||...
- when restarting again, the video always restarts from the same time 
(the laast stop time is not stored).


I tried to reset the smplayer directory (within .config) without any 
effect (except all videos restart from 00:00:00).


Thanks in advance for your help !

Regards.

-- Guy Durrieu.

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

Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
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_FR.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages smplayer depends on:
ii  libc6   2.29-2
ii  libgcc1 1:9.2.1-8
ii  libqt5core5a    5.11.3+dfsg1-4
ii  libqt5dbus5 5.11.3+dfsg1-4
ii  libqt5gui5  5.11.3+dfsg1-4
ii  libqt5network5  5.11.3+dfsg1-4
ii  libqt5script5   5.11.3+dfsg-3
ii  libqt5widgets5  5.11.3+dfsg1-4
ii  libqt5xml5  5.11.3+dfsg1-4
ii  libstdc++6  9.2.1-8
ii  libx11-6    2:1.6.8-1
ii  mplayer 4:1.4-dmo5
ii  mpv 1:0.30.0-dmo1
ii  zlib1g  1:1.2.11.dfsg-1+b1

Versions of packages smplayer recommends:
ii  smplayer-l10n    18.10.0~ds0-1
ii  smplayer-themes  1:18.6.0-1

smplayer suggests no packages.

-- no debconf information