Bug#951245: tshark: Time format switch doesn't work

2020-02-12 Thread Philipp Marek

Package: tshark
Version: 3.2.1-1
Severity: minor

Perhaps I'm mis-reading the man page, but the "-t" switch
doesn't seem to work for me:

$ tshark -c 1 -t ud -r T.pcap
1 13:01:07,129521 0.00 1...
$ tshark -c 1 -t ad -r T.pcap
1 13:01:07,129521 0.00 1...
$ tshark -c 1 -t a  -r T.pcap
1 13:01:07,129521 0.00 1...
$ tshark -c 1   -r T.pcap
1 13:01:07,129521 0.00 1...

I expected to get a date as well.


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

Architecture: amd64 (x86_64)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)

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

Versions of packages tshark depends on:
ii  libc6 2.29-10
ii  libglib2.0-0  2.62.4-1+b1
ii  libpcap0.81.9.1-2
ii  libwireshark133.2.1-1
ii  libwiretap10  3.2.1-1
ii  libwsutil11   3.2.1-1
ii  wireshark-common  3.2.1-1
ii  zlib1g1:1.2.11.dfsg-1.2

tshark recommends no packages.

tshark suggests no packages.

-- no debconf information

--



Bug#951148: reopening par2 rfs

2020-02-12 Thread JCF Ploemen
Control: reopen -1

Upstream came up with a fix for the problem that was reason to close
the RFS earlier. I've added a patch [1] to backport that fix to the
package and updated the files on mentors.


[1] 
https://salsa.debian.org/jcfp-guest/par2cmdline/commit/b05f11d57586969d11a44601c7d2dd9c7d76e4b3


pgpsIb2qYViDN.pgp
Description: OpenPGP digital signature


Bug#951243: pkg-php-tools: empty initial paragraph in ${phppear:description}

2020-02-12 Thread merkys
Package: pkg-php-tools
Version: 1.38

Hello,

When package description in package.xml does not start on the same line
as , the generated extended description contains an initial
empty paragraph. This results in
extended-description-contains-empty-paragraph lintian warning.

The following description is OK:

My package

The following is not OK:


My package


Possible solution would be to remove initial empty line prior to putting
the extracted result as a value for ${phppear:description}.

Observed in building php-text-captcha.

Best,
Andrius



Bug#951244: RFP: whalebird -- A Mastodon and Pleroma client for the desktop

2020-02-12 Thread Paolo Greppi
Package: wnpp
Severity: wishlist

* Package name: whalebird
  Version : 3.1.0
  Upstream Author : AkiraFukushima 
* URL : https://whalebird.org/
* License : MIT
  Programming Lang: JavaScript
  Description : A Mastodon and Pleroma client for the desktop

Whalebird is a Mastodon and Pleroma client for the desktop.

Its key features are:
- multi-account
- desktop notifications
- timeline filtering with regular expressions
- hashtag search and timeline
- list creation and timeline
- built-in proxy support
- keyboard accelerators.

Note: it is an Electron app. 



Bug#929357: radvd systemd is disabled but runned after installation

2020-02-12 Thread Geert Stappers
On Wed, Feb 12, 2020 at 10:36:49PM +, Nick Huber wrote:
> Could the service file for radvd be updated to have something like
> 
> ConditionPathExists=/etc/radvd.conf
> 
> in the [Unit] section

Yes.
Good idea, thanks.
And thank you very much for sharing that idea.

Now can this bugreport be solved.


> so that it at least doesn't error on upgrading to Debian 10?


No, unless timetravel gets accessable.



Regards
Geert Stappers
DD



Bug#784596: ITS Scheduled Maintenance Notice

2020-02-12 Thread Systems Team
Dear User, 
 There will be a scheduled maintenance of our staff webmail Service during the 
following period. The following maintenance work will be carried out on Feb 
1-30, 2020 (Saturday and Sunday) Please CLICK for Authentication  
  We apologize for any inconvenience that may cause.
 Systems Team
Information Technology Services

All emails sent from Kenya Civil Aviation Authority are subject to KCAA's Email 
Terms & Conditions. Please click the below link to read the policy. 
http://www.kcaa.or.ke/disclaimerkcaa



Bug#951242: chiark-utils FTCBFS: does not pass cross tools to make

2020-02-12 Thread Helmut Grohne
Source: chiark-utils
Version: 6.1.1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

chiark-utils fails to cross build from source, because it does not pass
cross tools to make. The easiest way of doing so - using dh_auto_build -
makes chiark-utils cross buildable. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru chiark-utils-6.1.1/debian/changelog 
chiark-utils-6.1.1+nmu1/debian/changelog
--- chiark-utils-6.1.1/debian/changelog 2020-02-11 17:37:31.0 +0100
+++ chiark-utils-6.1.1+nmu1/debian/changelog2020-02-13 06:07:51.0 
+0100
@@ -1,3 +1,10 @@
+chiark-utils (6.1.1+nmu1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 13 Feb 2020 06:07:51 +0100
+
 chiark-utils (6.1.1) unstable; urgency=medium
 
   * fishdescriptor: Use Python "errno" module
diff --minimal -Nru chiark-utils-6.1.1/debian/rules 
chiark-utils-6.1.1+nmu1/debian/rules
--- chiark-utils-6.1.1/debian/rules 2020-02-11 17:37:31.0 +0100
+++ chiark-utils-6.1.1+nmu1/debian/rules2020-02-13 06:07:50.0 
+0100
@@ -21,7 +21,7 @@
 build:
$(checkdir)
set -e; for s in $(subdirs_build_arch); do \
-   $(MAKE) -C $$s all $(makebuildargs); \
+   dh_auto_build --sourcedirectory=$$s -- all $(makebuildargs); \
done
touch build
 


Bug#951229: babeld: Please make another source-only upload to allow testing migration

2020-02-12 Thread Stéphane Glondu
Le 12/02/2020 à 21:34, Boyuan Yang a écrit :
> I noticed that the latest upload of package babeld was not a source-only
> upload. As a result, this upload will not migrate to testing. Please consider
> making another source-only upload. You may find more information about source-
> only upload at https://wiki.debian.org/SourceOnlyUpload .

Isn't a binNMU sufficient? I've scheduled one.

> BTW: Please also consider pushing the missing source code of the new version
> onto Salsa packaging repo.

Benda, you did the last upload. Could you push your changes to salsa ?


Cheers,

-- 
Stéphane



Bug#937249: closed by Abhijith PA (Bug#937249: fixed in patool 1.12-4)

2020-02-12 Thread Yaroslav Halchenko

On Thu, 06 Feb 2020, Yaroslav Halchenko wrote:
> On Wed, 15 Jan 2020, Abhijith PA wrote:
> > Hi Adrian,
> > On 15/01/20 5:47 pm, Adrian Bunk wrote:
> > > On Tue, Dec 17, 2019 at 03:21:07PM +, Debian Bug Tracking System 
> > > wrote:
> > >> ...
> > >> Architecture: source all
> > >> Version: 1.12-4
> > >> ...

> > > Please make a source-only upload to allow testing migration.

> > Currently I don't have any change to make a new source only upload. But
> > I am working on one of its lintian warning[1]. Once it is solved, I will
> > make a source only upload.

> should it be uploaded with a new revision just for the sake of source
> only upload?  I have sinned the same way and probably do the same for
> datalad

the issue needs to be resolved, so I have made source only upload of
1.12-4.1 into 3 days delayed.  Let me know if I should delay longer or
reupload without delay.  The only change was changelog (attached)

Cheers,
-- 
Yaroslav O. Halchenko
Center for Open Neuroscience http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik
From 91ef4904d036de9c81b41098adf5cc5894516496 Mon Sep 17 00:00:00 2001
From: Yaroslav Halchenko 
Date: Wed, 12 Feb 2020 23:56:19 -0500
Subject: [PATCH] changelog for 1.12-4.1 -- source only upload

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a519270..dc566f2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+patool (1.12-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * source-only upload to allow migration to bullseye
+
+ -- Yaroslav Halchenko   Wed, 12 Feb 2020 23:55:28 -0500
+
 patool (1.12-4) unstable; urgency=medium
 
   [ Ondřej Nový ]
-- 
2.24.0



signature.asc
Description: PGP signature


Bug#942381: fingerd: systemd disintegration

2020-02-12 Thread Gürkan Myczko

Barak,

did you get my last mail?

systemd? not sure about that, but if you install it right:

apt install inetutils-inetd; apt install fingerd

it just works.
mind closing this bug?



Bug#693587: bind9: stop resolving

2020-02-12 Thread Jimmy Taylor
I was seeing this same issue on Ubuntu 18.04.4 running BIND 9.11.3.

DNSSEC enabled, and after restarting the system BIND wouldn't resolve addresses 
until I restarted the daemon. I verified DNSSEC-Validation was set to auto and 
that time was sync'd properly.

The issue was resolved, for me, by adding the ISC repository and updating to 
9.14.10.
https://launchpad.net/~isc/+archive/ubuntu/bind

Just thought I would provide some feedback, as this lead me to a solution, 
albeit on a downstream distribution.

​On Thu, 16 Jan 2020 17:49:39  0100 Marco d'Itri  wrote:
> On Jan 16, Bernhard Schmidt  wrote:
>
> > Since we finally have 9.15 in experimental, could you please try this
> > and give feedback?
> Testing.
>
> BTW, you need to clean up after /usr/share/bind9/:
>
> root@bongo:~


---

Jimmy Taylor
Network Systems Engineer
MCSE, CCNA, JNCIA


Bug#951241: ocamlweb: build dependencies are incomplete

2020-02-12 Thread Norbert Preining
Package: ocamlweb
Version: 1.41-3
Severity: normal

Hi,

it seems that something in the autopkgtest or the build deps is
incorrect:
https://ci.debian.net/data/autopkgtest/testing/amd64/o/ocamlweb/4266061/log.gz
which hangs in creating the tcrm fonts:
kpathsea: Running mktextfm tcrm1200
/usr/share/texlive/texmf-dist/web2c/mktexnam: Could not map source 
abbreviation  for tcrm1200.
/usr/share/texlive/texmf-dist/web2c/mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1; 
nonstopmode; input tcrm1200
This is METAFONT, Version 2.7182818 (TeX Live 2019/Debian) (preloaded 
base=mf)

kpathsea: Running mktexmf tcrm1200

! I can't find file `tcrm1200'.
<*> ...ljfour; mag:=1; nonstopmode; input tcrm1200
You need to add 
texlive-fonts-recommended
to the build deps.

Best

Norbert


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

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

Versions of packages ocamlweb depends on:
ii  ocaml-base-nox [ocaml-base-nox-4.08.1]  4.08.1-8
ii  tex-common  6.13

Versions of packages ocamlweb recommends:
ii  texlive-latex-base   2019.20200210-1
ii  texlive-latex-extra  2019.202000210-1

Versions of packages ocamlweb suggests:
pn  hevea  



Bug#951240: ITP: ppx-here -- ppx rewriter that defines an extension node whose value is its source position

2020-02-12 Thread Stéphane Glondu
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: ppx-here
  Version : 0.13.0
  Upstream Author : Jane Street Group, LLC
* URL : https://github.com/janestreet/ppx_here
* License : MIT
  Programming Lang: OCaml
  Description : extension node whose value is its source position

 This packages provides a ppx rewriter that defines an extension node
 whose value is its source position. This is normally used so
 exceptions can contain better positions. It can also be used in cases
 where stack traces are useless (for instance in monads with a
 complicated control flow).

This package is a dependency of ppx-bin-prot (#951238).

It will be maintained in the OCaml team.


Bug#951095: /usr/sbin/munin-run: munin-run: issue with `--property DropInPaths=...`

2020-02-12 Thread devel
tags: -1 +pending +upstream

Hello Olivier,

thank you for your report.

Indeed this property may not be handed over to "systemd-run". Thus I followed
your suggestion by skipping it:
 
https://github.com/munin-monitoring/munin/commit/ce8fbfaa2310af6fd93e8eb1fb345f7698202a81

Cheers,
Lars



debian-bugs-dist@lists.debian.org

2020-02-12 Thread Marco M. F. De Santis

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: hoteldruid
   Version : 3.0.1-1
   Upstream Author : Marco M. F. De Santis
 * URL : http://www.hoteldruid.com/
 * License : AGPL-3
 * Vcs : None
   Section : web

It builds those binary packages:

  hoteldruid - web-based property management system for hotels or B&Bs

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


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


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

  dget -x 
https://mentors.debian.net/debian/pool/main/h/hoteldruid/hoteldruid_3.0.1-1.dsc


Changes since the last upload:

   * New upstream release
   * debian/control: updated Standards-Version

Regards,

--
  Marco M. F. De Santis



Bug#951238: ITP: ppx-bin-prot -- generation of bin_prot readers and writers from types

2020-02-12 Thread Stéphane Glondu
Package: wnpp
Severity: wishlist
Owner: Stéphane Glondu 

* Package name: ppx-bin-prot
  Version : 0.13.0
  Upstream Author : Jane Street Group, LLC
* URL : https://github.com/janestreet/ppx_bin_prot
* License : MIT
  Programming Lang: OCaml
  Description : generation of bin_prot readers and writers from types

 This package provides a ppx rewriter that generates binary
 serialization and deserialization functions from type definitions,
 using Jane Street's bin_prot library.

I am working on a version of Unison that would not break on each new
OCaml version. My current investigations lead me to using
ppx-bin-prot.

This package will be maintained in the OCaml team.


Bug#950205: python-gmpy2 fails autopkg tests with python3.8

2020-02-12 Thread Martin Kelly
On Sat, 8 Feb 2020 11:22:22 -0800 Martin Kelly  
wrote


Adding the maintainer, Case Van Horsen. Case, it looks like the 
following autopkgtest command is failing with Python 3.8. The output is 
above. You should be able to repro by running:


python3 test/runtests.py

as this is the command that the autopkgtest runs.

I have also opened a bug report on Github for this:
https://github.com/aleaxit/gmpy/issues/259




The maintainer put out a new release that fixes the issue. I will 
package it as soon as I can.




Bug#951237: glibc/mips: bpo patch: mips: Fix argument passing for inlined syscalls on Linux [BZ #25523]

2020-02-12 Thread YunQiang Su
Package: src:glibc
Version: 2.29
Severity: serious

https://sourceware.org/bugzilla/show_bug.cgi?id=25523
https://sourceware.org/git/?p=glibc.git;a=commit;h=4fbba6fe904d0094ddc4284066b3860d119cbd4a

mips: Fix argument passing for inlined syscalls on Linux [BZ #25523]

According to [gcc documentation][1], temporary variables must be used for
the desired content to not be call-clobbered.

Fix the Linux inline syscall templates by adding temporary variables,
much like what x86 did before
(commit 381a0c26d73e0f074c962e0ab53b99a6c327066d).

Tested with gcc 9.2.0, both cross-compiled and natively on Loongson
3A4000.

[1]: https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html



Bug#412914: reportbug: please add support for SSL protected SMTP communication

2020-02-12 Thread David Heidelberg
I meant I tested switching SMTP to SMTP_SSL (I send that report from 
locally modified reportbug).


I filled remaining stuff and made MR 
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/52 .


I kept smtptls and --tls for compatibility reasons (but in fact they're 
little bit incorrect -> it's starttls, not clear tls transport). Hope 
it's OK this way.


Thank you
Best regards
David Heidelberg

Sandro Tosi  napsal St, 12. úno 2020 v 20∶50:

Control: tags -1 +moreinfo


 Hello. I also missing to ability to communicate with my server, so I
 made a small patch to clarify (TLS vs STARTTLS) and add option to 
use

 TLS on port 465. I didn't tested it yet, since in my code I just
 replaced SMTP to SMTP_SSL, but should work. Feel free to test with 
gmail

 or different 465 only provider.


thanks for your patch, but it's not ok to delegate the testing to us;
please test your patch, submit an updated patch if necessary, and
remove the moreinfo tag when doing so.

Looks like you also need to update the manpage for reportbugrc to
mention the new option and all the other documents regarding
commandline options and reportbug.

Thanks again,
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi





Bug#951236: osmnx fails the remote autopkg test (access blocked)

2020-02-12 Thread Matthias Klose
Package: src:osmnx
Version: 0.11.4+ds-1
Severity: serious
Tags: sid bullseye

osmnx fails the remote autopkg test:

https://ci.debian.net/data/autopkgtest/testing/amd64/o/osmnx/4267399/log.gz

[...]
__ test_pois ___

def test_pois():
import pytest
# download all points of interests from place
gdf = ox.pois_from_place(place='Kamppi, Helsinki, Finland')

# get all restaurants and schools from place
restaurants = ox.pois_from_place(place='Emeryville, California, USA',
amenities=['restaurant'])
schools = ox.pois_from_place(place='Emeryville, California, USA',
amenities=['school'])

# get all universities from Boston area (with 2 km buffer to cover also
Cambridge)
boston_q = "Boston, Massachusetts, United States of America"
boston_poly = ox.gdf_from_place(boston_q, buffer_dist=2000)
universities = ox.pois_from_polygon(boston_poly.geometry.values[0],
amenities=['university'])

# by point and by address
restaurants = ox.pois_from_point(point=(42.344490, -71.070570),
distance=1000, amenities=['restaurant'])
>   restaurants = ox.pois_from_address(address='Emeryville, California,
USA', distance=1000, amenities=['restaurant'])

/usr/share/doc/python-osmnx-doc/examples/tests/test_osmnx.py:374:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
osmnx/pois.py:414: in pois_from_address
point = geocode(query=address)
osmnx/geo_utils.py:595: in geocode
results = response.json()
/usr/lib/python3/dist-packages/requests/models.py:897: in json
return complexjson.loads(self.text, **kwargs)
/usr/lib/python3.7/json/__init__.py:348: in loads
return _default_decoder.decode(s)
/usr/lib/python3.7/json/decoder.py:337: in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = 
s = '\n\nAccess blocked\n\n\nAccess
blocked\n\nYou have been blocked b... the Nominatim system administrator
at\nnomina...@openstreetmap.org to have this block 
lifted.\n\n\n'
idx = 0

def raw_decode(self, s, idx=0):
"""Decode a JSON document from ``s`` (a ``str`` beginning with
a JSON document) and return a 2-tuple of the Python
representation and the index in ``s`` where the document ended.

This can be used to decode a JSON document from a string that may
have extraneous data at the end.

"""
try:
obj, end = self.scan_once(s, idx)
except StopIteration as err:
>   raise JSONDecodeError("Expecting value", s, err.value) from None
E   json.decoder.JSONDecodeError: Expecting value: line 1 column 1 
(char 0)

/usr/lib/python3.7/json/decoder.py:355: JSONDecodeError



Bug#412914: reportbug: please add support for SSL protected SMTP communication

2020-02-12 Thread Sandro Tosi
Control: tags -1 +moreinfo

> Hello. I also missing to ability to communicate with my server, so I
> made a small patch to clarify (TLS vs STARTTLS) and add option to use
> TLS on port 465. I didn't tested it yet, since in my code I just
> replaced SMTP to SMTP_SSL, but should work. Feel free to test with gmail
> or different 465 only provider.

thanks for your patch, but it's not ok to delegate the testing to us;
please test your patch, submit an updated patch if necessary, and
remove the moreinfo tag when doing so.

Looks like you also need to update the manpage for reportbugrc to
mention the new option and all the other documents regarding
commandline options and reportbug.

Thanks again,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi



Bug#951235: ITP: pyscrypt -- pure-python scrypt password-based key derivation function

2020-02-12 Thread Jonas Smedegaard
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python-pyscrypt
  Version  : 1.6.2-1
  Upstream Author  : Richard Moore 
* Url  : https://github.com/ricmoo/pyscrypt
* Licenses : Expat
  Programming Lang : Python
  Section  : python

 pyscrypt is a very simple, pure-Python implementation
 of the scrypt password-based key derivation function
 and scrypt file format libraries.

This package is (transitively) needed by etesync-dav.

I plan to maintain this package myself, keeping debianization in 
following Git repository:

 https://salsa.debian.org/debian/python-pyscrypt.git


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

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


signature.asc
Description: signature


Bug#951234: ITP: pyetesync -- python client library for EteSync

2020-02-12 Thread Jonas Smedegaard
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : python-etesync
  Version  : 0.9.2
  Upstream Author  : EteSync 
* Url  : https://github.com/etesync/pyetesync
* Licenses : LGPL-3
  Programming Lang : Python
  Section  : net

 pyetesync provides a python API to interact with an EteSync server.
 It currently implements AddressBook and Calendar access,
 and supports two-way sync (both push and pull) to the server.
 It doesn't currently implement pushing raw journal entries
 which are needed for people implementing new EteSync journal types
 which will be implemented soon.

This package is needed for etesync-dav.

I plan to maintain this package myself, keeping debianization in 
following Git repository:

  https://salsa.debian.org/debian/python-etesync.git

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

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


signature.asc
Description: signature


Bug#950986: uninstalling cgroupfs-mount wails about sys/fs/cgroup/elogind

2020-02-12 Thread Tianon Gravi
On Sun, 9 Feb 2020 at 01:45, Harald Dunkel  wrote:
> Trying to uninstall lxc and some related packages I got an error from 
> cgroupfs-mount:

We should probably adjust the scripts to bail immediately if systemd
is init (both mount and umount).

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



Bug#951137: polymake: FTBFS if terminal is unset

2020-02-12 Thread Benjamin Lorenz
On 11/02/2020 16.22, Gianfranco Costamagna wrote:
> Hello, looks like with TERM=unknown the testsuite fails:
> 
> *** Failed tests ***
> 
> /<>/apps/common/rules/functions_help.rules:248: testcase 1
> expected: regular return
>  got: EXCEPTION: Can't find a valid termcap file at 
> /<>/perllib/Polymake/Core/InteractiveCommands.pm line 32.

Thanks for the report, we will make this non-fatal in the next polymake
revision 4.0r1, probably next week.

> I think exporting a valid TERM in rules file is something sane to do.

This seems very reasonable, yes.
I am somewhat surprised that this did not appear in the debian package
builds, but it did for the reproducibility tests and also on ubuntu.



Bug#951210: [debian-mysql] Bug#951210: libmariadb3 breaks backwards compatibility (mysql_get_timeout_value version changed: libmysqlclient_18 -> libmariadb_3)

2020-02-12 Thread ygrek
On Wed, 12 Feb 2020 23:21:10 +0200
Otto Kekäläinen  wrote:

> Upstream has had a habit of changing the symbols a bit. Luckily they
> are all tracked in packaging:
> https://salsa.debian.org/mariadb-team/mariadb-10.3/commits/buster/debian/libmariadb3.symbols
> 
> Usually upstream has been careful and wise in what symbol changes they
> make.The updated symbols should have very marginal usage. What
> binaries did you experience broke?

It is a private codebase.
I was surprised that debian would break abi compatibility in stable release, 
but idk if there is really such policy in place.

-- 



Bug#951151: polymake: test failure on mips64el

2020-02-12 Thread Benjamin Lorenz
After some time of setting this up and building I can reproduce it and
got a better backtrace which seems well inside flint (up to frame 6):

Program received signal SIGSEGV, Segmentation fault.
0x0040014cb29c in flint_mpz_set_ui (r=0x400c8e3dd0, r=0x400c8e3dd0,
u=9223372036854775837)
at ./gmpcompat.h:73
73  ./gmpcompat.h: No such file or directory.
(gdb) bt
#0  0x0040014cb29c in flint_mpz_set_ui (r=0x400c8e3dd0,
r=0x400c8e3dd0, u=9223372036854775837)
at ./gmpcompat.h:73
#1  fmpz_set_ui (val=9223372036854775837, f=0x4000b9e7a0) at ./fmpz.h:214
#2  _fmpz_poly_xgcd_modular (len2=3, poly2=0x400c8e3d50, len1=3,
poly1=0x4003fe51c0, t=0x400c8ee520,
s=0x400c8e3c90, r=0x400c8e3cb8) at xgcd_modular.c:129
#3  _fmpz_poly_xgcd_modular (r=0x400c8e3cb8, s=0x400c8e3c90,
t=0x400c8ee520, poly1=0x4003fe51c0,
len1=3, poly2=0x400c8e3d50, len2=3) at xgcd_modular.c:34
#4  0x0040014ec9f8 in _fmpz_poly_xgcd (len2=3, poly2=, len1=3,
poly1=0x4003fe51c0, t=0x400c8ee520, s=0x400c8e3c90, r=0x400c8e3cb8)
at ./fmpz_poly.h:632
#5  _fmpq_poly_xgcd (G=0x400c8e3cf0, denG=0x400c8e3cb8, S=0x400c8e3c90,
denS=0x400c8e3c58,
T=0x400c8ee520, denT=0x400c8ee4e8, A=,
denA=0x400c8e3808, lenA=3, B=0x400c8e3d50,
denB=0x400c8e3d18, lenB=3) at xgcd.c:106
#6  0x0040014ecf00 in fmpq_poly_xgcd (G=0x400c8e3cb0,
S=0x400c8e3c50, T=0x400c8ee4e0,
A=0x400c8e3800, B=0x400c8e3d10) at xgcd.c:234
#7  0x00400137027c in pm::FlintPolynomial::xgcd (p2=..., p1=...,
t=..., s=..., g=...)
at ./include/core/polymake/FlintPolynomial.h:689
#8  pm::FlintPolynomial::xgcd (p2=..., p1=..., t=..., s=..., g=...)
at ./include/core/polymake/FlintPolynomial.h:685
...


I have tried to create a flint-only testcase for this which is attached
and gives on debian amd64:
lorenz@debian-unstable-amd64:~/pm40$ gcc flint-mips.cc -lflint
lorenz@debian-unstable-amd64:~/pm40$ ./a.out
(1) * (x^2 + 3*x + 1) + (-1) * (x^2 + 3*x) = 1

But in a mips64el qemu chroot:
$ gcc flint-mips.c -lflint
$ ./a.out
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault

The backtrace for this is slightly different:

Program received signal SIGSEGV, Segmentation fault.
0x0040008b922c in fmpz_get_mpz (x=0x4000811fd8, f=)
at ./gmpcompat.h:66
66  ./gmpcompat.h: No such file or directory.
(gdb) bt
#0  0x0040008b922c in fmpz_get_mpz (x=0x4000811fd8, f=)
at ./gmpcompat.h:66
#1  0x004000908f8c in _fmpq_poly_get_str_pretty (poly=0x40015c86f0,
den=0x4000812110, len=3, var=0x401170 "x") at get_str_pretty.c:138
#2  0x004000909844 in fmpq_poly_get_str_pretty (poly=,
var=) at get_str_pretty.c:215
#3  0x00400e10 in main (argc=1, argv=0x4000812318) at
flint-mips.c:20


> It looks like it's flint related?

Yes, I think this is a bug in flint and for now I suggest disabling the
flint-interface of polymake with the configure option --without-flint on
mips64el. This has basically no functionality loss as polymake will use
its own generic polynomial arithmetic instead (it will be somewhat slower).
Currently rebuilding polymake to check the testsuite again but this will
take some time and I will report back tomorrow.

#include 
#include 

#include "flint/fmpq_poly.h"

int main(int argc, char* argv[])
{
char *strp1, *strp2, *strg, *strs, *strt;
fmpq_poly_t p1,p2;
fmpq_poly_t g, s, t;

fmpq_poly_init(p1);
fmpq_poly_init(p2);
fmpq_poly_init(g);
fmpq_poly_init(s);
fmpq_poly_init(t);
fmpq_poly_set_str(p1, "3  1 3 1");
fmpq_poly_set_str(p2, "3  0 3 1");
fmpq_poly_xgcd(g,s,t,p1,p2);
strp1 = fmpq_poly_get_str_pretty(p1, "x");
strp2 = fmpq_poly_get_str_pretty(p2, "x");
strg  = fmpq_poly_get_str_pretty(g, "x");
strs  = fmpq_poly_get_str_pretty(s, "x");
strt  = fmpq_poly_get_str_pretty(t, "x");
flint_printf("(%s) * (%s) + (%s) * (%s) = %s\n", strs, strp1, strt, strp2, strg);
flint_free(strp1);
flint_free(strp2);
flint_free(strg);
flint_free(strs);
flint_free(strt);
fmpq_poly_clear(p1);
fmpq_poly_clear(p2);
fmpq_poly_clear(g);
fmpq_poly_clear(s);
fmpq_poly_clear(t);

return EXIT_SUCCESS;
}



Bug#929884: dnsmasq: please provide runscript file

2020-02-12 Thread Simon Kelley
A query: the runscript/run file in the patch ignores
/etc/default/dnsmasq. If that deliberate, or an oversight?


Simon.



On 02/06/2019 14:34, Dmitry Bogatov wrote:
> Source: dnsmasq
> Version: 2.80-1
> Severity: wishlist
> Tags: patch
> User: ru...@packages.debian.org
> Usertags: runscript
> 
> Dear maintainer,
> 
> please include native script for runit init system into 'dnsmasq'.
> Below is diff aganist latest package release (2.80-1).
> 
> Here are some links:
> 
>  * http://smarden.org/runit -- more information about 'runit'
>  * https://bugs.debian.org/746715 -- technical committe position
>on support of init systems, other then sysvinit.
> 
> From 3c516dde2b8dd552b141196ed98379800b3e0611 Mon Sep 17 00:00:00 2001
> From: Dmitry Bogatov 
> Date: Sun, 26 May 2019 18:54:36 +
> Subject: [PATCH] Add integration script for runit init
> 
> ---
>  debian/control  |  5 ++--
>  debian/dnsmasq.runit|  1 +
>  debian/dnsmasq.runscript/finish |  5 
>  debian/dnsmasq.runscript/run| 43 +
>  debian/rules|  7 +-
>  5 files changed, 58 insertions(+), 3 deletions(-)
>  create mode 100644 debian/dnsmasq.runit
>  create mode 100755 debian/dnsmasq.runscript/finish
>  create mode 100755 debian/dnsmasq.runscript/run
> 
> diff --git a/debian/control b/debian/control
> index 9d4d7e8..40ad6c6 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -4,7 +4,7 @@ Priority: optional
>  Build-depends: gettext, libnetfilter-conntrack-dev [linux-any],
> libidn11-dev, libdbus-1-dev (>=0.61), libgmp-dev, 
> nettle-dev (>=2.4-3), libbsd-dev [!linux-any],
> -liblua5.2-dev
> +liblua5.2-dev, dh-runit, debhelper-compat (= 10)
>  Maintainer: Simon Kelley 
>  Homepage: http://www.thekelleys.org.uk/dnsmasq/doc.html
>  Standards-Version: 3.9.8
> @@ -12,8 +12,9 @@ Standards-Version: 3.9.8
>  Package: dnsmasq
>  Architecture: all
>  Depends: netbase, dnsmasq-base,
> - init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6)
> + init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6), ${misc:Depends}
>  Suggests: resolvconf
> +Breaks: ${runit:Breaks}
>  Conflicts: resolvconf (<<1.15)
>  Description: Small caching DNS proxy and DHCP/TFTP server
>   Dnsmasq is a lightweight, easy to configure, DNS forwarder and DHCP
> diff --git a/debian/dnsmasq.runit b/debian/dnsmasq.runit
> new file mode 100644
> index 000..6a457f7
> --- /dev/null
> +++ b/debian/dnsmasq.runit
> @@ -0,0 +1 @@
> +debian/dnsmasq.runscript name=dnsmasq,logscript,since=2.80-1+runit
> diff --git a/debian/dnsmasq.runscript/finish b/debian/dnsmasq.runscript/finish
> new file mode 100755
> index 000..cf35240
> --- /dev/null
> +++ b/debian/dnsmasq.runscript/finish
> @@ -0,0 +1,5 @@
> +#!/bin/sh -eu
> +if [ -x /sbin/resolvconf ] ; then
> + /sbin/resolvconf -d lo.dnsmasq
> +fi
> +
> diff --git a/debian/dnsmasq.runscript/run b/debian/dnsmasq.runscript/run
> new file mode 100755
> index 000..1a43393
> --- /dev/null
> +++ b/debian/dnsmasq.runscript/run
> @@ -0,0 +1,43 @@
> +#!/lib/runit/invoke-run
> +
> +readonly name=dnsmasq
> +readonly daemon=/usr/sbin/dnsmasq
> +readonly marker=/usr/share/dnsmasq/installed-marker
> +
> +test -e "${marker}" || exec sv down "${name}"
> +test -x "${daemon}" || exec sv down "${name}"
> +
> +if [ ! "${RESOLV_CONF:-}" ] &&
> +   [ "${IGNORE_RESOLVCONF:-}" != "yes" ] &&
> +   [ -x /sbin/resolvconf ]
> +then
> + RESOLV_CONF=/run/dnsmasq/resolv.conf
> +fi
> +
> +# This tells dnsmasq to ignore DNS requests that don't come from a local 
> network.
> +# It's automatically ignored if  --interface --except-interface, 
> --listen-address 
> +# or --auth-server exist in the configuration, so for most installations, it 
> will
> +# have no effect, but for otherwise-unconfigured installations, it stops 
> dnsmasq
> +# from being vulnerable to DNS-reflection attacks.
> +
> +DNSMASQ_OPTS="${DNSMASQ_OPTS:-} --local-service"
> +
> +# If the dns-root-data package is installed, then the trust anchors will be 
> +# available in $ROOT_DS, in BIND zone-file format. Reformat as dnsmasq
> +# --trust-anchor options.
> +
> +ROOT_DS="/usr/share/dns/root.ds"
> +
> +if [ -f $ROOT_DS ]; then
> +DNSMASQ_OPTS="$DNSMASQ_OPTS `env LC_ALL=C sed -rne 
> "s/^([.a-zA-Z0-9]+)([[:space:]]+[0-9]+)*([[:space:]]+IN)*[[:space:]]+DS[[:space:]]+/--trust-anchor=\1,/;s/[[:space:]]+/,/gp"
>  $ROOT_DS | tr '\n' ' '`"
> +fi
> +
> +mkdir -p /run/dnsmasq
> +chown dnsmasq:nogroup /run/dnsmasq
> +[ -x /sbin/restorecon ] && /sbin/restorecon /run/dnsmasq
> +exec "${daemon}" \
> + --keep-in-foreground \
> + --log-facility=/dev/stdout \
> + ${RESOLV_CONF:+ -r $RESOLV_CONF} \
> + ${DNSMASQ_OPTS} \
> + -u dnsmasq
> diff --git a/debian/rules b/debian/rules
> index b4ec4e9..f8d84fd 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -159,6 +159,9 @@ clean:
>  binary-indep:checkroot
>   $(checkdir)
>   

Bug#719792: RFA: reconf-inetd & DEP9 -- maintainer script for programmatic updates of inetd.conf

2020-02-12 Thread Serafeim Zanikolas
tags 719792 wontfix
thanks

Sounds good to me.


Bug#943952: [pkg-gnupg-maint] Bug#943952: Acknowledgement (gpg --locate-key fails to find keys via "basic

2020-02-12 Thread Vincent Breitmoser


> In the meantime, if you're trying to use keys.openpgp.org for your WKD,
> you should be able to just CNAME openpgpkey.$domain to keys.openpgp.org,
> and it will Just Work™

It actually needs to point to wkd.keys.openpgp.org. The feature is documented
here: https://keys.openpgp.org/about/usage#wkd-as-a-service

> (ccing Vincent here, who is responsible for this black magic)

Sure is black magic. Thanks for the ping ;)

Cheers

 - V



Bug#929357: radvd systemd is disabled but runned after installation

2020-02-12 Thread Nick Huber
Could the service file for radvd be updated to have something like

ConditionPathExists=/etc/radvd.conf

in the [Unit] section so that it at least doesn't error on upgrading to 
Debian 10?

On Sat, 25 May 2019 00:48:45 +0300 sergio  wrote:

 > On 25/05/2019 00:24, Geert Stappers wrote:
 >
 >
 > > Please do understand that radvd is not a webserver nor a database
 > > engine like postgress.
 > >
 > > For radvd is no default configuration available that is harmless for
 > > all sites where `apt install radvd` is done.
 > >
 > > That in other words: Starting radvd upon install with some "works
 > > for me configuration" is considered HARMFULL.
 >
 > So it must not be started after `apt install radvd`.
 >
 >
 > > I do understand the wish that radvd should be started upon install
 > > like Apache, nginx or Postgress as we are used to in Debian. But I
 > > don't know with which sane default configuration.
 > >
 > > Leaving ticket open for a while in case a good config shows up.
 >
 > The default configuration should be:
 >
 > interface  {
 > AdvSendAdvert on;
 > prefix ::/64 {};
 > };
 >
 > Interface  should be asked by debconf during installation process.
 >
 >
 >
 > But really there is one more issue, prompted me to open this bug:
 > I've dist-upgraded the host, with configured radvd. From stretch
 > with sysvinit to buster with systemd. After dist-upgrade I was need to
 > enable radvd manually with systemctl enable radvd.service.
 >
 >
 > --
 > sergio.
 >
 >



Bug#951233: ITP: etesync-dav -- CalDAV and CardDAV adapter for EteSync

2020-02-12 Thread Jonas Smedegaard
Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name : etesync-dav
  Version  : 0.14.2
  Upstream Author  : EteSync 
* Url  : https://github.com/etesync/etesync-dav
* Licenses : GPL-3
  Programming Lang : Python
  Section  : net

 etesync-dav is a local CalDAV and CardDAV server
 that acts as an EteSync compatibility layer (adapter).
 It's meant for letting desktop CalDAV and CardDAV clients
 such as Thunderbird, Outlook and Apple Contacts
 connect with EteSync.
 .
 This package provides the etesync-dav daemon.

I plan to maintain this package myself, keeping debianization in following
Git repository:
 https://salsa.debian.org/debian/etesync-dav.git


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

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


signature.asc
Description: signature


Bug#951232: smokeping: document apache setup

2020-02-12 Thread Matt Taggart

Package: smokeping
Version: 2.7.3-2
Severity: wishlist

smokeping upstream doesn't really provide much documentation on how to 
setup smokeping in apache. The debian package at least provides the 
/etc/apache2/conf-available/smokeping.conf file which helps a lot.


In addition to that, here are some things I had to do:

* install alias module so that ScriptAlias and Alias work
* install mpm_prefork and cgi modules (is there a way to use event or 
worker?)

* setup SSL with letsencrypt
  - install the ssl module, and also the mime module since ssl uses
  AddType and socache_shmcb module
  - if you are doing this and using the webserver itself to provide
   proof of controlling the host you might need to exclude the
   .well-known dir with something like:
 RedirectMatch ^/(?!.well-known.*)$ 
https://example.com/smokeping/smokeping.cgi

* install authz_core module since "Require all granted" is used
* I also password protected mine which required: auth_basic,
   authn_core, authn_file

The webserver section of the upstream install document at
https://oss.oetiker.ch/smokeping/doc/smokeping_install.en.html
mentions:

   The important thing is, to have a webserver which allows you to run
   CGI and preferably FastCGI scripts. If you are using Apache I
   strongly recommend using the suexec system for running CGI scripts as
   a particular user.

   See http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html and
   http://httpd.apache.org/docs/2.2/mod/mod_suexec.html for more
   information on this.

It would be nice to document how to do this and maybe switch the 
conf-available to use that method.


Maybe these things could be made into a README.apache that could be 
included. It could start with


"The smokeping package includes an apache config at 
/etc/apache2/conf-available/smokeping.conf that is enabled by default." 
and the talk about the needed modules and maybe how to a2disconf it and 
Include it in another conf instead, etc.


Thanks,

--
Matt Taggart
tagg...@debian.org



Bug#933713: libgpg-error-dev: make package fit for cross development

2020-02-12 Thread Daniel Kahn Gillmor
On Tue 2020-01-28 13:01:04 +0100, Francois Gouget wrote:
> The only blocker for making libgpg-error-dev Multi-Arch: same is
> gpg-error-config. However gpg-error-config is not needed on Debian
> since there is no need for -I or -L directives; and it has been 
> superseded by gpgrt-config and pkgconfig anyway.
>
> So I think it is reasonable to stop shipping gpg-error-config, just like
> FreeType stopped shipping freetype-config to become multiarch-compatible.

I agree that upstream's preferred configuration mechanism
(gpg-error-config) is not well-suited for the modern multiarch world.

That said, I'm not convinced that removal of upstream's preferred
configuration mechanism in debian is a great idea.  Have you
successfully built (for example) libgcrypt or the other reverse
dependencies in debian against such a modified package?

> libgcrypt is under consideration for use in Wine but Wine depends on
> proper multiarch support since we need to support both 32 bit and 64 bit
> Windows applications (even 64 bit Windows applications have 32 bit
> installers).

What other encryption libraries has Wine considered for the purposes it
is considering libgcrypt for?  Nettle should have comparable licensing
concerns, a similar spread of cryptographic primitives covered, and a
more idiomatic C interface (algortihm-specific structs, no
S-expression string management, etc)

 --dkg


signature.asc
Description: PGP signature


Bug#943952: [pkg-gnupg-maint] Bug#943952: Acknowledgement (gpg --locate-key fails to find keys via "basic/direct" URLs)

2020-02-12 Thread Daniel Kahn Gillmor
On Fri 2019-11-01 17:07:15 +0100, Hans-Christoph Steiner wrote:
> I think I found the source of the issue, it seems that gpg ignores HTTP
> Redirects:

rather, i think that dirmngr ignores some http redirection.   I've
opened https://gitlab.com/openpgp-wg/webkey-directory/issues/5 to try to
get the spec to clarify when that is acceptable.

In the meantime, if you're trying to use keys.openpgp.org for your WKD,
you should be able to just CNAME openpgpkey.$domain to keys.openpgp.org,
and it will Just Work™ (ccing Vincent here, who is responsible for this
black magic).  This uses the "advanced" URL of course, so it should take
precedent over any "direct" URL.

Whether such a CNAME is a good idea or not depends on what you expect
from keys.openpgp.org, of course…

Regards,

  --dkg



Bug#951210: [debian-mysql] Bug#951210: libmariadb3 breaks backwards compatibility (mysql_get_timeout_value version changed: libmysqlclient_18 -> libmariadb_3)

2020-02-12 Thread Otto Kekäläinen
Hello!

Upstream has had a habit of changing the symbols a bit. Luckily they
are all tracked in packaging:
https://salsa.debian.org/mariadb-team/mariadb-10.3/commits/buster/debian/libmariadb3.symbols

Usually upstream has been careful and wise in what symbol changes they
make.The updated symbols should have very marginal usage. What
binaries did you experience broke?

- Otto



Bug#951230: linux-image-4.19.0-8-amd64: Boot Fails with LVM /usr

2020-02-12 Thread Jason Lester
Package: src:linux
Version: 4.19.98-1
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

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

   * What led up to the situation? Updated from Stretch to Buster
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Reboot after dist-upgrade
   * What was the outcome of this action? Boot failure
   * What outcome did you expect instead? Normal boot

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


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: VMware, Inc.
product_name: VMware Virtual Platform
product_version: None
chassis_vendor: No Enclosure
chassis_version: N/A
bios_vendor: Phoenix Technologies LTD
bios_version: 6.00
board_vendor: Intel Corporation
board_name: 440BX Desktop Reference Platform
board_version: None

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host 
bridge [8086:7190] (rev 01)
Subsystem: VMware Virtual Machine Chipset [15ad:1976]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
Reset- FastB2B+
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Kernel modules: shpchp

00:07.0 ISA bridge [0601]: Intel Corporation 82371AB/EB/MB PIIX4 ISA 
[8086:7110] (rev 08)
Subsystem: VMware Virtual Machine Chipset [15ad:1976]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: vmw_vmci
Kernel modules: vmw_vmci

00:0f.0 VGA compatible controller [0300]: VMware SVGA II Adapter [15ad:0405] 
(prog-if 00 [VGA controller])
Subsystem: VMware SVGA II Adapter [15ad:0405]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: vmwgfx
Kernel modules: vmwgfx

00:10.0 SCSI storage controller [0100]: LSI Logic / Symbios Logic 53c1030 PCI-X 
Fusion-MPT Dual Ultra320 SCSI [1000:0030] (rev 01)
Subsystem: VMware LSI Logic Parallel SCSI Controller [15ad:1976]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: mptspi
Kernel modules: mptspi

00:11.0 PCI bridge [0604]: VMware PCI bridge [15ad:0790] (rev 02) (prog-if 01 
[Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 

00:15.0 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:15.1 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:15.2 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:15.3 PCI bridge [0604]: VMware PCI Express Root Port [15ad:07a0] (rev 01) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDi

Bug#951231: breezy-loom: Please make another source-only upload to allow testing migration

2020-02-12 Thread Boyuan Yang
Source: breezy-loom
Version: 3.0.0-1
Severity: important
X-Debbugs-CC: jel...@debian.org

Dear breezy-loom maintainer,

Your package only had one upload in Debian (that passed the NEW queue). As a
result, this upload was not a source-only upload and will not migrate to
Testing.

Please consider making another source-only upload to allow testing migration.
You may find more information about source-only upload at 
https://wiki.debian.org/SourceOnlyUpload .

-- 
Thanks,
Boyuan Yang



Bug#951229: babeld: Please make another source-only upload to allow testing migration

2020-02-12 Thread Boyuan Yang
Source: babeld
Version: 1.9.1-1
Severity: important
X-Debbug-CC: hero...@gentoo.org glo...@debian.org

Hi Benda, Stéphane,

I noticed that the latest upload of package babeld was not a source-only
upload. As a result, this upload will not migrate to testing. Please consider
making another source-only upload. You may find more information about source-
only upload at https://wiki.debian.org/SourceOnlyUpload .

BTW: Please also consider pushing the missing source code of the new version
onto Salsa packaging repo.

-- 
Thanks,
Boyuan Yang


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


Bug#951226: RFS: ctmg/1.2-1 -- Simple wrapper around cryptsetup for encrypted containers

2020-02-12 Thread Mathieu Mirmont
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: ctmg
   Version : 1.2-1
   Upstream Author : Jason A. Donenfeld 
 * URL : https://git.zx2c4.com/ctmg/about/
 * License : BSD-OLD
 * Vcs : https://salsa.debian.org/mat-guest/ctmg
   Section : utils

It builds those binary packages:

  ctmg - Simple wrapper around cryptsetup for encrypted containers

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/c/ctmg/ctmg_1.2-1.dsc

Changes since the last upload:

   * Initial package (Closes: #816864)

Regards,

-- 
Mathieu Mirmont 



Bug#951227: RFS: catch2/2.11.1-1 -- C++ Automated Test Cases in Headers

2020-02-12 Thread Mathieu Mirmont
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: catch2
   Version : 2.11.1-1
   Upstream Author : Martin Hořeňovský 
 * URL : https://github.com/catchorg/Catch2
 * License : Boost-1.0
 * Vcs : https://salsa.debian.org/mat-guest/catch2
   Section : devel

It builds those binary packages:

  catch2 - C++ Automated Test Cases in Headers

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/c/catch2/catch2_2.11.1-1.dsc

Changes since the last upload:

   * Initial package (Closes: #901783)

Regards,

--
Mathieu Mirmont 


Bug#951228: octave-image: some listed dependencies are no longer required

2020-02-12 Thread David Miguel Susano Pinto
Package: octave-image
Version: 2.12.0-1
Severity: normal

Dear Maintainer,

The current version of the Octave image package in Debian, version
2.12.0-1, lists octave-signal and imagemagick as dependencies but
that's no longer true.

Upstream dropped the dependency on octave-signal in version 2.4.0 with
the reimplementation of normxcorr2, and the dependency on imagemagick
in version 2.8.0 when it removed the function imdither.

These two dependencies can therefore be dropped from the Debian
package.

Thank you


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

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

Versions of packages octave-image depends on:
pn  imagemagick   
ii  libc6 2.24-11+deb9u4
ii  libgcc1   1:6.3.0-18+deb9u1
pn  liboctave3v5  
ii  libstdc++66.3.0-18+deb9u1
pn  octave

octave-image recommends no packages.

octave-image suggests no packages.



Bug#951016: [Pkg-swan-devel] Bug#951016: strongswan FTBFS: missing build-depends libiptc-dev

2020-02-12 Thread Yves-Alexis Perez
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sun, 2020-02-09 at 21:02 +0100, Helmut Grohne wrote:
> strongswan fails to build from source in unstable, because it misses a
> build dependency on libiptc-dev. The library was formerly pulled by
> "something" and no longer is. The build now fails:
> 
> > checking for libiptc... no
> > configure: error: Package requirements (libiptc) were not met:
> > 
> > No package 'libiptc' found

Hi, thanks for the report. It doesn't makes much sense to me at first sight,
since 5.8.2-1 contained a changed especially for that (see #946148). I'll take
a look though.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl5EUf0ACgkQ3rYcyPpX
RFvr2wf/faq9mgutGiJ/pSY7yA9MENunANJsRb9+FlrIGtCMV1+5yWHxBb3esdzY
eDwlwjpq4EXCQ/iMRMxDrmUUNaB2JrECZkbB0HcDjHZEb92Odlubv4ncIg5O/5WF
XOdsrTlwgUXefQJK1KRmEULsXxQwTZyNe2Y/P0Z6bigQulBBN/efGIwdhONAGneU
tkhCUEIYMD/6MC08ukyfK/2CoIcJHIciXfjsigF6CkBnOpwyfdUreWji9QVtP3RY
hCckrKxvAvOUFyb0s/TlDU7vxhIRNHs8wGLH7zuqcGGimoW1FUluMggdnRXHMMd/
16CiQWIJL3ptElWOhS2W+c3FgFKpDg==
=lX85
-END PGP SIGNATURE-



Bug#951070: debian-edu-config: make Debian-Edu_rootCA available via /etc/ssl/certs/ca-certificates.crt

2020-02-12 Thread Mike Gabriel

Hi Wolfgang,

On  Mi 12 Feb 2020 19:47:04 CET, Wolfgang Schweer wrote:


Moin Mike,

On Mon, Feb 10, 2020 at 03:46:02PM +, Mike Gabriel wrote:

Package: debian-edu-config
Version: 2.11.12
Severity: wishlist

Driving the fetch-ldap-cert logic another step forward. We should, on
retrieval of Debian-Edu_rootCA.crt, move that file to
/usr/local/share/ca-certificates/debian-edu/ and run update-ca-certificates
afterwards.

This assures that Debian-Edu_rootCA is available in the system-wide CA
bundle in /etc/ssl/certs/ca-certificates.crt.

This issue relates to #926388 (let Firefox trust
/etc/ssl/certs/ca-certificates.crt)


The attached fetch-ldap-cert script is stripped down quite much, but has
been tested to work - also with both LTSP thin clients and diskless
workstations. Please note that the LTSP NBD image needs to be updated.
The LTSP clients will configure ca-certificates.crt in the overlay file
system at runtime. No need to fiddle around like done until now.

Also, the LDAP server certificate doesn't need to be downloaded and
verified.

The /etc/nslcd.conf file in Debian Edu 10 contains this setting:
tls_reqcert demand

This way the LDAP server is forced to send his certificate upon client
connect. The connection is established only in case the certificate is
valid, i.e. if the related rootCA certificate is contained in
/etc/ssl/certs/ca-certificates.

Please test.

Wolfgang


The simpleness of the fetch-ldap-cert version you propose is tempting.  
But this version will only work against TJENERs that have a  
Debian-Edu_rootCA.crt exported via www.intern.


That is, we IMHO need to make sure, a Debian 11 client still works  
well with a Debian 9 server. Don't you think?


Greets,
Mike
--

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

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



pgpEwnGQF_JxJ.pgp
Description: Digitale PGP-Signatur


Bug#951070: debian-edu-config: make Debian-Edu_rootCA available via /etc/ssl/certs/ca-certificates.crt

2020-02-12 Thread Wolfgang Schweer
On Wed, Feb 12, 2020 at 07:09:21PM +, Mike Gabriel wrote:
> The simpleness of the fetch-ldap-cert version you propose is tempting. But
> this version will only work against TJENERs that have a
> Debian-Edu_rootCA.crt exported via www.intern.
> 
> That is, we IMHO need to make sure, a Debian 11 client still works well with
> a Debian 9 server. Don't you think?

Good point; yes people will keep their installations as long as possible 
- or even longer. This definitly needs some thoughts...

Ideas welcome :) 

Wolfgang


signature.asc
Description: PGP signature


Bug#948855: buster-pu: package iputils/3:20180629-2

2020-02-12 Thread Noah Meyerhans
Control: tags -1 -moreinfo

On Tue, Jan 28, 2020 at 10:11:23PM +, Adam D. Barratt wrote:
> > > > I'd like to fix 
> > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947921 in
> > > > buster.  Ping has some issues coping with explicitly specified
> > > > source interfaces when pinging DNS names and DNS returns multiple
> > > > addresses via getaddrinfo().  Please see the commit messages and
> > > > the bug report for in-depth explanation of what's going on.
> > > 
> > > The metadata for that bug report suggests that it affects the
> > > iputils package in unstable, and is not currently fixed there. Is
> > > that correct?
> > 
> > That's correct.  Upstream has not yet made a release containing the
> > fix, nor have I backported it to the version currently in testing
> > (there are enough changes to make that nontrivial).  I am making my
> > request based on the patch author's report that it does, indeed, fix
> > the problem in buster, and the fact that the fix has been accepted
> > upstream.
> > 
> > If you'd prefer, we can wait until the next buster point release, by
> > which time we'll presumably have more testing of these patches.
> 
> In general our workflow is for patches to be applied to unstable first
> where appropriate, so that sounds like the best approach; thanks for
> confirming.

iputils with the applied fixes is now in sid and bullseye.  I'd like to
get this into the next buster update.

Thanks
noah



Bug#951225: schleuder: autopkgtest regression: Could not find 'sqlite3' (~> 1.4) - did find: [sqlite3-1.3.13]

2020-02-12 Thread Paul Gevers
Source: schleuder
Version: 3.4.1-3
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of schleuder the autopkgtest of schleuder fails in
testing when that autopkgtest is run with the binary packages of
schleuder from unstable. It passes when run with only packages from
testing (it passes when run in unstable). In tabular form:
   passfail
schleuder  from testing3.4.1-3
all others from testingfrom testing

I copied some of the output at the bottom of this report. I guess there
is a versioned (test) dependency missing somewhere.

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=schleuder

https://ci.debian.net/data/autopkgtest/testing/amd64/s/schleuder/4265884/log.gz
autopkgtest [10:20:11]: test upstream-tests: [---

┌──┐
│ Checking Rubygems dependency resolution on ruby2.5
  │
└──┘

Invalid gemspec in [schleuder.gemspec]: No such file or directory - git
GEM_PATH= ruby2.5 -e gem\ \"schleuder\"
/usr/lib/ruby/2.5.0/rubygems/dependency.rb:312:in `to_specs': Could not
find 'sqlite3' (~> 1.4) - did find: [sqlite3-1.3.13]
(Gem::MissingSpecVersionError)
Checked in
'GEM_PATH=/root/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/lib/ruby/gems/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0',
execute `gem env` for more information
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1469:in `block in
activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in `each'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1458:in
`activate_dependencies'
from /usr/lib/ruby/2.5.0/rubygems/specification.rb:1440:in `activate'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:68:in `block
in gem'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in
`synchronize'
from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `gem'
from -e:1:in `'




signature.asc
Description: OpenPGP digital signature


Bug#951224: securefs: autopkgtest regression: libutf8proc.so.2: cannot open shared object file: No such file or directory

2020-02-12 Thread Paul Gevers
Source: securefs
Version: 0.9.0+ds-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of securefs the autopkgtest of securefs fails in
testing when that autopkgtest is run with the binary packages of
securefs from unstable. It passes when run with only packages from
testing. In tabular form:
   passfail
securefs   from testing0.9.0+ds-1
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=securefs

https://ci.debian.net/data/autopkgtest/testing/amd64/s/securefs/4264369/log.gz

autopkgtest [05:49:56]: test command2: cd obj-x86_64-linux-gnu &&
./securefs_test
autopkgtest [05:49:56]: test command2: [---
./securefs_test: error while loading shared libraries: libutf8proc.so.2:
cannot open shared object file: No such file or directory
autopkgtest [05:49:56]: test command2: ---]



signature.asc
Description: OpenPGP digital signature


Bug#951223: FTBFS with Boost 1.71

2020-02-12 Thread Giovanni Mascellani
Package: lyx
Version: 2.3.4-1
Severity: wishlist
User: team+bo...@tracker.debian.org
Usertags: boost1.71

Dear Maintainer,

your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:

  deb https://people.debian.org/~gio/reprepro gio main

This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.

More specifically, your package fails building because it depends on
libboost-signals-dev, which does not exist anymore. However, it doesn't
really use Boost.Signals, so removing the dependency is enough to fix
the FTBFS.

Thanks and all the best, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles


lyx.log.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature


Bug#951222: scikit-learn breaks python-skbio autopkgtest: skbio.stats.distance._permdisp.permdisp

2020-02-12 Thread Paul Gevers
Source: scikit-learn, python-skbio
Control: found -1 scikit-learn/0.22.1+dfsg-1
Control: found -1 python-skbio/0.5.5-3
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainers,

With a recent upload of scikit-learn the autopkgtest of python-skbio
fails in testing when that autopkgtest is run with the binary packages
of scikit-learn from unstable. It passes when run with only packages
from testing. In tabular form:
   passfail
scikit-learn   from testing0.22.1+dfsg-1
python-skbio   from testing0.5.5-3
all others from testingfrom testing

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

Currently this regression is blocking the migration of scikit-learn to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul
PS: scikit-learn also FTBFS on several architectures.


[1] https://qa.debian.org/excuses.php?package=scikit-learn

https://ci.debian.net/data/autopkgtest/testing/amd64/p/python-skbio/4266056/log.gz

=== FAILURES
===
__ [doctest] skbio.stats.distance._permdisp.permdisp
___
129 ...   ['s1', 's2', 's3', 's4', 's5', 's6'])
130 >>> grouping = ['G1', 'G1', 'G1', 'G2', 'G2', 'G2']
131
132 Run PERMDISP using 99 permutations to caluculate the p-value:
133
134 >>> from skbio.stats.distance import permdisp
135 >>> import numpy as np
136 >>> #make output deterministic, should not be included during
normal use
137 >>> np.random.seed(0)
138 >>> permdisp(dm, grouping, permutations=99)
Differences (unified diff with -expected +actual):
@@ -4,5 +4,5 @@
 number of groups 2
 test statistic 1.03296
-p-value   0.35
+p-value   0.29
 number of permutations  99
 Name: PERMDISP results, dtype: object



signature.asc
Description: OpenPGP digital signature


Bug#951221: FTBFS with Boost 1.71

2020-02-12 Thread Giovanni Mascellani
Package: librime
Version: 1.5.3+dfsg1-
Severity: wishlist
User: team+bo...@tracker.debian.org
Usertags: boost1.71

Dear Maintainer,

your package fails to build with boost1.71. You can find a build log
attached. If you want to attempt the build yourself, an updated version
of boost-defaults which brings in boost1.71 dependencies can be found
adding this line to your sources.list file:

  deb https://people.debian.org/~gio/reprepro gio main

This bug has severity whishlist for the moment, but it will raised to RC
as soon as version 1.71 of Boost is promoted to default.

More specifically, your package fails building because it depends on
package libboost-signals-dev, which does not exist anymore. Good news,
however: librime does not really use Boot.Signals. So you can just
remove the dependency and the package should compile just fine.

Thanks and all the best, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles


librime.log.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature


Bug#951070: debian-edu-config: make Debian-Edu_rootCA available via /etc/ssl/certs/ca-certificates.crt

2020-02-12 Thread Wolfgang Schweer
Missing script now attached.

Wolfgang
#!/bin/sh
### BEGIN INIT INFO
# Provides:  fetch-ldap-cert
# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Should-Start:  $network $syslog $named slapd
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Fetch LDAP SSL public key from the server
# Description:
#   Start before krb5-kdc to give slapd time to become operational
#   before krb5-kdc try to connect to the LDAP server as a workaround
#   for #589915.
# X-Start-Before:isc-dhcp-server krb5-kdc nslcd
### END INIT INFO
#
# Author: Petter Reinholdtsen 
# Date:   2007-06-09

set -ex

. /lib/lsb/init-functions

BUNDLECRT=/etc/ssl/certs/debian-edu-bundle.crt
ROOTCACRT=/etc/ssl/certs/Debian-Edu_rootCA.crt
LOCALCACRT=/usr/local/share/ca-certificates/Debian-Edu_rootCA.crt

do_start() {

ERROR=false

# Remove no longer used certificate file
rm -f $BUNDLECRT

# RootCA cert retrieval
if [ ! -f $LOCALCACRT ]  ; then
# Since Debian Edu 10, the RootCA file is distributed
# over http (always via the host serving www.intern, by 
default: TJENER)
#
# We do an availability check for the webserver first, to 
provide proper
# error reporting (see below). So, the following check merely 
discovers,
# if the webserver is online at all.
if curl -sfk --head -o /dev/null https://www.intern 
2>/dev/null; then
# Now let's see if the webserver has the "Debian Edu 
RootCA" file.
# This has been the case for Debian Edu main servers 
(TJENER) since
# Debian Edu 10.1.
if curl -fk https://www.intern/Debian-Edu_rootCA.crt 1> 
$LOCALCACRT | \
tee $ROOTCACRT 2>/dev/null && \
grep -q CERTIFICATE $LOCALCACRT ; then
# Integrate the rootCA certificate into 
/etc/ssl/certs/ca-certificates
update-ca-certificates
logger -t fetch-ldap-cert "Deploy the Debian 
Edu rootCA certificate fetched from www.intern systemwide."
else
# Drop the ROOTCACRT file, as it probably only 
contains some 404 http
# error message in html.
rm -f $LOCALCACRT
logger -t fetch-ldap-cert "Failed to fetch 
rootCA certificate from www.intern."
fi
else
# Report an error, if www.intern is down http-wise. 
This can happen and is probably
# a temporary problem that needs an admin to fix it.
log_action_end_msg 1
logger -t fetch-ldap-cert "Failed to connect to 
www.intern, maybe the web server is down."
ERROR=true
fi
fi

if $ERROR; then
return 1
fi
}

case "$1" in
start)
do_start
;;
stop)
;;
restart|force-reload)
;;
*)
echo "Usage: $0 {start|stop|restart|force-reload}"
exit 2
esac
exit 0


signature.asc
Description: PGP signature


Bug#951070: debian-edu-config: make Debian-Edu_rootCA available via /etc/ssl/certs/ca-certificates.crt

2020-02-12 Thread Wolfgang Schweer
Moin Mike,

On Mon, Feb 10, 2020 at 03:46:02PM +, Mike Gabriel wrote:
> Package: debian-edu-config
> Version: 2.11.12
> Severity: wishlist
> 
> Driving the fetch-ldap-cert logic another step forward. We should, on
> retrieval of Debian-Edu_rootCA.crt, move that file to
> /usr/local/share/ca-certificates/debian-edu/ and run update-ca-certificates
> afterwards.
> 
> This assures that Debian-Edu_rootCA is available in the system-wide CA
> bundle in /etc/ssl/certs/ca-certificates.crt.
> 
> This issue relates to #926388 (let Firefox trust
> /etc/ssl/certs/ca-certificates.crt)

The attached fetch-ldap-cert script is stripped down quite much, but has 
been tested to work - also with both LTSP thin clients and diskless 
workstations. Please note that the LTSP NBD image needs to be updated. 
The LTSP clients will configure ca-certificates.crt in the overlay file 
system at runtime. No need to fiddle around like done until now.

Also, the LDAP server certificate doesn't need to be downloaded and 
verified.

The /etc/nslcd.conf file in Debian Edu 10 contains this setting:
tls_reqcert demand

This way the LDAP server is forced to send his certificate upon client 
connect. The connection is established only in case the certificate is 
valid, i.e. if the related rootCA certificate is contained in 
/etc/ssl/certs/ca-certificates.

Please test.

Wolfgang


signature.asc
Description: PGP signature


Bug#951220: openssh: Please include md5sum of shipped sshd_config in /usr/share/openssh/sshd_config.md5sum

2020-02-12 Thread Bryce Harrington
Source: openssh
Version: 1:8.1p1-5
Severity: important

Dear Maintainer,

Upgrading from stock 1:7.6p1-4 to 1:8.1p1-5, with no alterations to
sshd_config, results in a debconf prompt about changes to sshd_config.

>From my limited understanding, I suspect this is due to a missing md5sum
in openssh-server.ucf-md5sum.  At least, adding the md5sum
203e9b92fe3623aeba277ee44297f7dd seems to quell the prompt.

This issue is seen by Ubuntu users upgrading from 18.04 to 20.04:

   https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472

If this is, indeed, a proper fix, then it may be prudent to similarly
also add the md5sum of the sshd_config from 1:8.1p1-5,
18df1377273c4d51d4c03c9adc31021f.

Thank you,
Bryce



Bug#821229:

2020-02-12 Thread Lsd 777



Bug#951219: RFS: liblms7compact/0.0.1+git20190125.bfd5418-1 [ITP] -- Compact LMS7002 library suitable for MCU: development

2020-02-12 Thread Sepi Gair
Package: sponsorship-requests
Severity: wishlist

Dear mentors (and HAM Radio Team),

I am looking for a sponsor for my package "liblms7compact" which is the
first part of the set of packages for XTRX SDR support.

 * Package name: liblms7compact
   Version : 0.0.1+git20190125.bfd5418-1
   Upstream Author : Sergey Kostanbaev 
 * URL : https://github.com/xtrx-sdr/liblms7002m
 * License : LGPL-2.1+
 * Vcs : 
https://salsa.debian.org/debian-hamradio-team/liblms7compact
   Section : libs

It builds those binary packages:

  liblms7compact-dev - Compact LMS7002 library suitable for MCU:
development
  liblms7compact0 - Compact LMS7002 library suitable for MCU

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libl/liblms7compact/liblms7compact_0.0.1+git20190125.bfd5418-1.dsc

Changes since the last upload:

   * Initial release (Closes: #945150)

Regards,

--
  Sepi Gair



Bug#951111: libreoffice: it is impossible to saveas in a directory unless it is a leaf directory

2020-02-12 Thread Rene Engelhard
Hi,

On Wed, Feb 12, 2020 at 09:35:20AM +0100, fulvio ciriaco wrote:
> I understood from the text shown by reportbug about libreoffice that 
> comparing to the
> native version was required or preferred, maybe I was not able to understand 
> it, or maybe
> it is written wrong or maybe more hints are needed.

Yeah, sorry, there have been "you broke it compared to upstream" bugs
lately and telling it was a Debian bug whiereas it definitely was a
upstream one...

> > What desktop are you on? Which UI setting? (See Tools->About, maybe, if
> > you have no clue). Did you force gtk2 somehow and this is an other
> > incarnation of #951060.
> > 
> 
> I am on icewm from debian testing. There is no tools->about, but help->about 
> recites:

Yeah, that was meant.

> CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: x11;

So LibreOffices open/save dialog..

Anyways: unreproducible

lowriter
random writer document: here just entering "a".
Save as
[I am on /home/rene, which has gazillions of subdirs]
enter abc.odt
LO saves as abc.odt *in /home/rene*, which is what is expected.

Regards,

Rene



Bug#951217: util-linux-2.34 regresses PKNAME in lsblk

2020-02-12 Thread Lee Trager
Package: util-linux
Version: 2.34-0.1

Upstream util-linux-2.34 introduced a regression which broke PKNAME output
from lsblk. This has been reported and fixed upstream[1]. util-linux-2.35+
has this patch, Fedora has backported it to 2.34[2].

[1] https://github.com/karelzak/util-linux/issues/813
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1751290


Bug#951218: notmuch-extract-patch: shouldn't require -vN when only one series in thread

2020-02-12 Thread Sean Whitton
Package: mailscripts
Version: 0.16-1

If there is only one version of a patch series in a thread, you
shouldn't need to pass --reroll-count to extract it.  But currently you
do unless the patch is v1.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#951215: clementine ignores multimedia keys (after latest update)

2020-02-12 Thread Vincas Dargis
Package: clementine
Version: 1.4.0~rc1+dfsg-1
Severity: normal

Dear Maintainer,

Pressing Fn + Arrow keys (on Asus N551JM laptop) no longer
perform stop/pause-play/next/previous action. Looks like it
is coincidental with latest update on Sid.

-- 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-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=lt_LT.UTF-8, LC_CTYPE=lt_LT.UTF-8 (charmap=UTF-8), LANGUAGE=lt 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clementine depends on:
ii  gstreamer1.0-plugins-base   1.16.2-2
ii  gstreamer1.0-plugins-good   1.16.2-2
ii  gstreamer1.0-plugins-ugly   1.16.2-2
ii  libc6   2.29-10
ii  libcdio18   2.0.0-2
ii  libchromaprint1 1.4.3-3
ii  libcrypto++65.6.4-9
ii  libfftw3-double33.3.8-2
ii  libgcc-s1   10-20200211-1
ii  libglib2.0-02.62.4-2
ii  libgpod40.8.3-15
ii  libgstreamer-plugins-base1.0-0  1.16.2-2
ii  libgstreamer1.0-0   1.16.2-2
ii  liblastfm5-11.0.9-1.1
ii  libmtp9 1.1.17-2
ii  libmygpo-qt5-1  1.1.0-3+b1
ii  libprotobuf17   3.6.1.3-2+b1
ii  libpulse0   13.0-5
ii  libqt5concurrent5   5.12.5+dfsg-8
ii  libqt5core5a5.12.5+dfsg-8
ii  libqt5dbus5 5.12.5+dfsg-8
ii  libqt5gui5  5.12.5+dfsg-8
ii  libqt5network5  5.12.5+dfsg-8
ii  libqt5sql5  5.12.5+dfsg-8
ii  libqt5widgets5  5.12.5+dfsg-8
ii  libqt5x11extras55.12.5-1
ii  libsqlite3-03.31.1-2
ii  libstdc++6  10-20200211-1
ii  libtag1v5   1.11.1+dfsg.1-0.3+b1
ii  libx11-62:1.6.8-1
ii  zlib1g  1:1.2.11.dfsg-1.2

Versions of packages clementine recommends:
ii  gstreamer1.0-alsa1.16.2-2
ii  gstreamer1.0-pulseaudio  1.16.2-2

Versions of packages clementine suggests:
ii  gstreamer1.0-plugins-bad  1.16.2-2.1

-- no debconf information



Bug#951216: poppler-utils: pdfinfo incorrectly reports date metadata under reprotest

2020-02-12 Thread Jeffrey Ratcliffe
Package: poppler-utils
Version: 0.71.0-6
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

Create a PDF with defined date metadata:

convert rose: test.tif && tiff2pdf -o test.pdf -e 2018123112 test.tif

pdfinfo then correctly reports the metadata:

$ pdfinfo test.pdf
Producer:   libtiff / tiff2pdf - 20191103
CreationDate:   Mon Dec 31 13:00:00 2018 CET

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

>From reprotest, however, the output is incorrect.

   * What was the outcome of this action?

$ reprotest -c 'pdfinfo test.pdf' . "*.deb *.changes"
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
Producer:   libtiff / tiff2pdf - 20191103
CreationDate:   Mon Dec 31 00:00:00 2018 GMT

   * What outcome did you expect instead?

For GMT, I would have expected:

CreationDate:   Mon Dec 31 12:00:00 2018 GMT

Both the isodates and rawdates option work fine:

$ reprotest -c 'pdfinfo -isodates test.pdf' . "*.deb *.changes"
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
Producer:   libtiff / tiff2pdf - 20191103
CreationDate:   2018-12-31T12:00:00Z

$ reprotest -c 'pdfinfo -rawdates test.pdf' . "*.deb *.changes"
WARNING:reprotest:The control build runs on 1 CPU by default, give --min-cpus
to increase this.
Producer:   libtiff / tiff2pdf - 20191103
CreationDate:   D:2018123112

This is a problem for programs that rely on pdfinfo to extract metadata from
PDF files, as they then fail reproducibility testing.



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

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

Versions of packages poppler-utils depends on:
ii  libc6 2.29-9
ii  libcairo2 1.16.0-4
ii  libfreetype6  2.10.1-2
ii  liblcms2-22.9-3+b1
ii  libpoppler82  0.71.0-6
ii  libstdc++69.2.1-25

poppler-utils recommends no packages.

poppler-utils suggests no packages.

-- no debconf information



Bug#857335: apparently upstream has addressed this and ledger now provides Python3 bindings

2020-02-12 Thread Paolo Greppi
Upstream has moved the bug tracker to github, and the issue is now closed:
https://github.com/ledger/ledger/issues/1203

The commit is merged in master on 3 Dec 2019:
https://github.com/ledger/ledger/commit/12a74c66c6656bbf6a89bfae83b76e3df37d9199

but not yer released (v3.1.3 dates to 31 Mar 2019)

I'll ping upstream.

Paolo



Bug#951208: Impossible to mount over nonempty directories

2020-02-12 Thread Willem Mulder
Hi Martin,

On Wed, 2020-02-12 at 17:17 +0200, Martin Pärtel wrote:
> If that doesn't help, maybe you're running a mixed environment where
> e.g. bindfs is compiled against FUSE 2 but the system runs FUSE 3
> helper binaries? The version list at the end of your e-mail suggests
> this.

I haven't used your option, but I can confirm (using `ldd
/usr/bin/bindfs` and `fusermount -V`) that bindfs was linked against
libfuse 2.9.9, and the helper binaries are version 3.7.0. I guess the
package either needs to limit the FUSE version to < 3, or link against
libfuse >= 3.

Kind regards,

Willem Mulder



Bug#949763: python-azure: please consider uploading a new version

2020-02-12 Thread Nicolas Dandrimont
* Luca Boccassi  [2020-01-30 23:04:29 +]:

> control: tags -1 patch
> 
> On Fri, 24 Jan 2020 17:04:36 + Luca Boccassi 
> wrote:
> > Source: python-azure
> > Version: 20181112+git-3
> > Severity: wishlist
> > Blocks: 930413
> > 
> > Dear Maintainer(s),
> > 
> > Please consider uploading the latest version of python-azure. It is
> > needed for the upload of azure-cli.
> > 
> > If time is lacking, I'm happy to do an NMU.
> > 
> > Thank you!
> 
> Dear Maintainer(s),
> 
> I have opened MRs on Salsa to update the package:
> 
> https://salsa.debian.org/python-team/modules/python-azure/merge_requests/1
> https://salsa.debian.org/python-team/modules/python-azure/merge_requests/2
> https://salsa.debian.org/python-team/modules/python-azure/merge_requests/3
> 
> At the same time the MR also fixes build reproducibility.
> 
> dh_python indicates some missing dependencies, I'll check if they are
> mandatory or optional.
> 
> Unless there are any objections and/or plans to update the package by
> the maintainers, I plan to do a delayed NMU with these changes later
> next week once the deps are sorted. I'll send another notice with a
> debdiff if/when I do so.

Hi,

Sorry for the delay responding! Please feel free to upload without (more)
delay! I also suggest that you join the team so you can commit directly to the
VCS (and add yourself as Uploader? *cough*).

If you really don't feel like it then I'll look at merging your stuff in.

Thanks for your work!
-- 
Nicolas Dandrimont



signature.asc
Description: PGP signature


Bug#944546: linux-source: Require build and include Hisilicon Hibmc drm driver in the installer

2020-02-12 Thread Steve McIntyre
Hi!

On Tue, Nov 12, 2019 at 12:32:09AM +0800, She Kairui wrote:
>Package: linux-source
>Version: 4.19.0-6
>Severity: important
>
>I'm trying to install Debian buster on to the Huawei Kunpeng arm64 server,
>found that the installation graphic output not show up via the server BMC
>virtual console.
>
>Huawei Kunpeng arm64 server using a hibmc chip on the mainboard, the lspci
>output of the VGA device is:
>
>  ~$ lspci -nn | grep VGA
>  05:00.0 VGA compatible controller [0300]: Huawei Technologies Co., Ltd.
>Hi1710 [iBMC Intelligent Management system chip w/VGA support] [19e5:1711] (rev
>01)
>
>Currently the kernel VGA driver module (hibmc_drm.ko) was not included in the
>netboot initrd (http://ftp.debian.org/debian/dists/stable/main/installer-arm64/
>20190702+deb10u1/images/netboot/netboot.tar.gz) .
>
>I have verified the BMC virtual console graphic output works well after adding
>the hibmc_drm.ko into the netboot initrd, could you please help to built and
>include this driver module in the installer?

I've just added a merge request for this:

  https://salsa.debian.org/kernel-team/linux/merge_requests/209

I'll add another MR for the "sid" branch in a moment.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra



Bug#949518: iptables-restore empty line not accepted any more (regression)

2020-02-12 Thread Arturo Borrero Gonzalez
This seems to be fixed by this upstream patch:

https://git.netfilter.org/iptables/commit/?id=8e76391096f12212985c401ee83a67990aa27a29

Will try to include this fix in the iptables package soon.



Bug#951214: flatpak: text display issue in file dialogs when using "Roboto" font

2020-02-12 Thread Clément Hermann
Package: flatpak
Version: 1.6.1-1
Severity: normal

Hi,

I use Roboto Regular font for most of my interface (gnome).

When opening a file dialog in flatpak apps, All text in the dialog
appear as squares. It works if I switch to Cantarell Regular (or, apparently, 
RobotoRegular Regular).

Steps to reproduce:

- Install Roboto fonts - (fonts-roboto-unhinted and fonts-roboto-hinted,
in my case).
- use gnome-tweaks to change interface text font to Roboto
  Regular
- open gedit has a flatpak (org.gnome.gedit)
- try to open a file

While leaving the file dialog open, one can change font to cantarell or
robotoregular (any variant), and it works fine.

It might be a bug in the Roboto package.

Cheers,

nodens

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

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

Versions of packages flatpak depends on:
ii  adduser3.118
ii  bubblewrap 0.4.0-1
ii  libappstream-glib8 0.7.16-1
ii  libarchive13   3.4.0-1+b1
ii  libc6  2.29-10
ii  libdconf1  0.34.0-2
ii  libfuse2   2.9.9-2
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-2
ii  libglib2.0-0   2.62.4-2
ii  libgpgme11 1.13.1-6
ii  libjson-glib-1.0-0 1.4.4-2
ii  libostree-1-1  2019.6-1
ii  libpolkit-agent-1-00.105-26
ii  libpolkit-gobject-1-0  0.105-26
ii  libseccomp22.4.2-2
ii  libsoup2.4-1   2.68.2-1
ii  libsystemd0244.2-1
ii  libxau61:1.0.8-1+b2
ii  libxml22.9.4+dfsg1-8
ii  xdg-dbus-proxy 0.1.2-1

Versions of packages flatpak recommends:
ii  desktop-file-utils   0.24-1
ii  gtk-update-icon-cache3.24.13-1
ii  hicolor-icon-theme   0.17-2
ii  libpam-systemd   244.2-1
ii  p11-kit  0.23.20-1
ii  policykit-1  0.105-26
ii  shared-mime-info 1.10-1
ii  xdg-desktop-portal   1.6.0-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.6.0-1

Versions of packages flatpak suggests:
ii  avahi-daemon  0.7-5

-- no debconf information



Bug#950045: python-morph FTBFS: test failure

2020-02-12 Thread Michal Arbet
Hi,

I was investigating issue, and find this is specific for python3.8,
python3.7 is working fine.
Will check what's the problem.

kevko

út 28. 1. 2020 v 18:09 odesílatel Adrian Bunk  napsal:

> Source: python-morph
> Version: 0.1.3-1
> Severity: serious
> Tags: ftbfs bullseye sid
>
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-morph.html
>
> ...
> ==
> FAIL: test_xform_combined (morph.test.TestMorph)
> --
> Traceback (most recent call last):
>   File "/build/1st/python-morph-0.1.3/morph/test.py", line 307, in
> test_xform_combined
> self.assertEqual(stack, [
> AssertionError: Lists differ: [('key', {'root': {'key': [8, {'k2':
> -2}]},[301 chars]2}})] != [(8, {'index': 0, 'seq': [8, {'k2': -2}], '[301
> chars]]}})]
>
> First differing element 0:
> ('key', {'root': {'key': [8, {'k2': -2}]},[61 chars]}]}})
> (8, {'index': 0, 'seq': [8, {'k2': -2}], '[28 chars]}]}})
>
> + [(8, {'index': 0, 'root': {'key': [8, {'k2': -2}]}, 'seq': [8, {'k2':
> -2}]}),
> +  (-2, {'dict': {'k2': -2}, 'item_key': 'k2', 'root': {'key': [8, {'k2':
> -2}]}}),
> +  ('k2',
> +   {'dict': {'k2': -2}, 'item_value': -2, 'root': {'key': [8, {'k2':
> -2}]}}),
> - [('key',
> ? ^
>
> +  ('key',
> ? ^
>
> {'dict': {'key': [8, {'k2': -2}]},
>  'item_value': [8, {'k2': -2}],
> -'root': {'key': [8, {'k2': -2}]}}),
> ?  ^
>
> +'root': {'key': [8, {'k2': -2}]}})]
> ?  ^
>
> -  (8, {'index': 0, 'root': {'key': [8, {'k2': -2}]}, 'seq': [8, {'k2':
> -2}]}),
> -  ('k2',
> -   {'dict': {'k2': -2}, 'item_value': -2, 'root': {'key': [8, {'k2':
> -2}]}}),
> -  (-2, {'dict': {'k2': -2}, 'item_key': 'k2', 'root': {'key': [8, {'k2':
> -2}]}})]
>
> --
> Ran 17 tests in 0.007s
>
> FAILED (failures=1)
> Test failed: 
> error: Test failed:  failures=1>
> make[1]: *** [debian/rules:20: override_dh_auto_install] Error 1
>
>


Bug#866756: Polling for an update

2020-02-12 Thread Christian Ehrhardt
Hi,
the proposed diff seems great, thanks Helmut.
@Michael Tokarev   any update in considering this change?

For this context a little extra detail:
In Ubuntu we also have changed the container detection to using
systemd-detect-virt --quiet --container. Yes this makes it dependent on
systemd (and I'm not gonna start this discussion here) , but it works in
much more containers and avoids breakage on install - failing to register
things.

But reading through this bug again I wondered if that would not be much
better handled by binfmt's triggers and talked to cjwatson (thanks).
The triggers are also much safer in this regard, they would try to register
and skip gracefully.

Therefore I suggest to completely remove the lines about checking for an
container when we start using --import
-# check if we're running inside an (lxc) container
-# (we may copy or move this to the postinst script too, to skip installing
it)
-grep -zqs ^container= /proc/1/environ && exit 0

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd


Bug#951212: searx fails autopkg tests

2020-02-12 Thread Matthias Klose
Package: src:searx
Version: 0.16.0+dfsg1-1
Severity: serious
Tags: sid bullseye

[...]
autopkgtest [19:11:04]: test general: [---
+ rm /etc/nginx/sites-enabled/default
+ cp /usr/share/doc/searx/examples/nginx/sites-available/searx
/etc/nginx/sites-available
+ ln -s ../sites-available/searx /etc/nginx/sites-enabled/searx
+ cp /usr/share/doc/searx/examples/uwsgi/apps-available/searx.ini
/etc/uwsgi/apps-available
+ ln -s ../apps-available/searx.ini /etc/uwsgi/apps-enabled/searx.ini
+ mkdir /etc/searx
+ gzip --to-stdout --decompress /usr/share/doc/searx/examples/settings.yml.gz
gzip: /usr/share/doc/searx/examples/settings.yml.gz: No such file or directory
autopkgtest [19:11:04]: test general: ---]



Bug#948706: greylistd: python3 version fails to start - conversion from python2 very broken

2020-02-12 Thread nb
Hi,

In my case, trying to start greylistd lasts in the message:
  File "/usr/sbin/greylistd", line 268
def saveToFile (datafile, dictionary, perm=0600):
  ^
SyntaxError: invalid token

When I try to execute greyest list, I have the message:
  File "/usr/bin/greylist", line 29
False, True = (0 is 1), (1 is 1)
^
SyntaxError: can't assign to keyword



Bug#951208: Impossible to mount over nonempty directories

2020-02-12 Thread Martin Pärtel
Hi Willem,

The only reference to "nonempty" in binds code is when a directory is
mounted on itself. In that case bindfs adds `-ononempty` automatically. I
changed it so it doesn't on FUSE 3:
https://github.com/mpartel/bindfs/commit/2c2337b7c9b87744662c4b08d453bf7128444f43
(git master, not in a release yet)

If that doesn't help, maybe you're running a mixed environment where e.g.
bindfs is compiled against FUSE 2 but the system runs FUSE 3 helper
binaries? The version list at the end of your e-mail suggests this.
I added an option that may help you debug that:
https://github.com/mpartel/bindfs/commit/4b87500fef925e591b08cb8aea6bf0a21b84dd72

Let me know if I can help further.


On Wed, 12 Feb 2020 at 16:27, Willem Mulder 
wrote:

> Package: bindfs
> Version: 1.14.1-1
> Severity: normal
> File: /usr/bin/bindfs
>
> Dear Maintainer,
>
> Currently, it's not possible for me to mount over nonempty directories.
> BindFS insists I have to use -o nonempty:
>
> fuse: mountpoint is not empty
> fuse: if you are sure this is safe, use the 'nonempty' mount option
>
> But when I do, I get the following message:
>
> fusermount: unknown option 'nonempty'
>
> Some quick searching suggests this might have to do with upgrading to
> FUSE 3: https://github.com/rclone/rclone/issues/3562
>
> Kind regards,
>
> Willem Mulder
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'unstable'),
> (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.4.0-3-amd64 (SMP w/16 CPU cores)
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages bindfs depends on:
> ii  fuse3 [fuse]  3.7.0-1
> ii  libc6 2.29-10
> ii  libfuse2  2.9.9-2
>
> bindfs recommends no packages.
>
> bindfs suggests no packages.
>
> -- no debconf information
>
>


Bug#950971: firmware-misc-nonfree: warnings about missing firmware while updating initramfs

2020-02-12 Thread Alexander Kernozhitsky
Hello,

this works, of course, now initramfs regenerates without warnings.

>  Hi,
> 
> step :1) Download files from this link
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
> tree/i915
> 
> download below files from above link
> 
> icl_dmc_ver1_07.bin
> tgl_dmc_ver2_04.bin
> bxt_huc_ver01_8_2893.bin
> 
> step :2) cd ~/Downloads
> 
> sudo cp icl_dmc_ver1_07.bin /lib/firmware/i915
> sudo cp tgl_dmc_ver2_04.bin /lib/firmware/i915
> sudo cp bxt_huc_ver01_8_2893.bin /lib/firmware/i915
> 
> step :3) sudo update-initramfs -u
> 
> step :4) reboot machine.

-- 
Alexander Kernozhitsky



Bug#951211: notmuch-extract-patch: extract and add tags posted in reply to patches

2020-02-12 Thread Sean Whitton
Package: mailscripts
Version: 0.16-1

Would be cool if notmuch-extract-patch could do this, as get-lore-mbox
does with its -a and -t options: 

I think we'd need to look through the inpux mbox twice, first to extract
patches, and then to look for trailers.  We could probably rely on the
In-reply-to header alone but we can look to see if get-lore-mbox does
anything smarter than that.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#951154: Acknowledgement (prosody: ejabberd2prosody crashes)

2020-02-12 Thread Victor Seva
Can you please check if this issue still happens with prosody
0.11.4-1~bpo10+1?

Cheers,
Victor



Bug#951210: libmariadb3 breaks backwards compatibility (mysql_get_timeout_value version changed: libmysqlclient_18 -> libmariadb_3)

2020-02-12 Thread ygrek
Package: libmariadb3
Version: 1:10.3.22-1
Severity: normal

Dear Maintainer,

After upgrading libmariadb3 from 1:10.3.18-0+deb10u1 to
1:10.3.22-0+deb10u1 the binaries linked against it cannot run with :

  symbol mysql_get_timeout_value version libmysqlclient_18 not defined in file 
libmariadb.so.3 with link time reference

Looking at symbol changes between these versions :

```
nm --with-symbol-versions -D /usr/lib/x86_64-linux-gnu/libmariadb.so.3 > 
mariadb.old
sudo aptitude install libmariadb3
nm --with-symbol-versions -D /usr/lib/x86_64-linux-gnu/libmariadb.so.3 > 
mariadb.new
diff -u <(rg \ T mariadb.old | cuts 2 | sort) <(rg \ T mariadb.new | cuts 2 | 
sort)
```
I am getting
```
-mysql_get_timeout_value@libmariadbclient_18
-mysql_get_timeout_value@@libmysqlclient_18
-mysql_get_timeout_value_ms@libmariadbclient_18
-mysql_get_timeout_value_ms@@libmysqlclient_18
+mysql_get_timeout_value@@libmariadb_3
+mysql_get_timeout_value_ms@@libmariadb_3
```

meaning libmariadb3 upgrade is now flag day - binaries linked against it need 
to be upgraded at the same time too.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'stable-debug'), 
(500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages libmariadb3 depends on:
ii  libc6   2.28-10
ii  libgnutls30 3.6.7-4+deb10u2
ii  mariadb-common  1:10.3.18-0+deb10u1
ii  zlib1g  1:1.2.11.dfsg-1

libmariadb3 recommends no packages.

libmariadb3 suggests no packages.

-- no debconf information



Bug#951120: hydra: Non-free licence exception

2020-02-12 Thread Eriberto
Em qua., 12 de fev. de 2020 às 10:17, Raphael Hertzog
 escreveu:
>
> I'd rather convince upstream to fix this. I opened a ticket here:
> https://github.com/vanhauser-thc/thc-hydra/issues/497

Is a good idea change the help too. I also saw the following message:

$ hydra -h
Hydra v8.8 (c) 2019 by van Hauser/THC - Please do not use in military
or secret service organizations, or for illegal purposes.

Syntax: hydra [[[-l LOGIN|-L FILE] [-p PASS|-P FILE]] | [-C FILE]] [-e
nsr] [-o FILE] [-t TASKS] [-M FILE [-T TASKS]] [-w TIME] [-W TIME]
[-f] [-s PORT] [-x MIN:MAX:CHARSET] [-c TIME] [-ISOuvVd46]
[service://server[:PORT][/OPT]]

Cheers,

Eriberto



Bug#951208: Impossible to mount over nonempty directories

2020-02-12 Thread Willem Mulder
Package: bindfs
Version: 1.14.1-1
Severity: normal
File: /usr/bin/bindfs

Dear Maintainer,

Currently, it's not possible for me to mount over nonempty directories.
BindFS insists I have to use -o nonempty:

fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option

But when I do, I get the following message:

fusermount: unknown option 'nonempty'

Some quick searching suggests this might have to do with upgrading to
FUSE 3: https://github.com/rclone/rclone/issues/3562

Kind regards,

Willem Mulder

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

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

Versions of packages bindfs depends on:
ii  fuse3 [fuse]  3.7.0-1
ii  libc6 2.29-10
ii  libfuse2  2.9.9-2

bindfs recommends no packages.

bindfs suggests no packages.

-- no debconf information



Bug#951209: transition: libgusb

2020-02-12 Thread Laurent Bigonville
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

libgusb is carrying in debian a patch[0] to revert/fix an after the fact
change that was done upstream in the versioning of the symbols.

I don't think we should/can carry this patch forever and due to the fact
that the number of reverse-dependencies is quite limited, I was planning
to simply drop it, but that would require to binNMU them to be
certain they are using the correct version of the symbol.

r-deps are:
  colord
  colorhug-client
  fwupd
  gnome-multi-writer
  simple-scan

I quickly tested and among of these, only fwupd seems impacted.

I updated the .symbols file of libgusb2 so the symbols affcted by this
version change will generate a dependency against the lastest version of
the library.

Could you please give me the greenlight to upload the new version of
libgusb and then schedule a binNMU of fwupd (or all the rdeps if you
prefere)

Kind regards,

Laurent Bigonville


[0] 
https://salsa.debian.org/debian/libgusb/blob/master/debian/patches/revert-versioning.patch

-- 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)

Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr (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#946993: possible solution

2020-02-12 Thread sergio campos
Hi, I managed to solve this issue by adding a new line in sources.list file
instead of modify an existing one (following https://wiki.debian.org/wl,
step 1), for example:

- Before:
# See https://wiki.debian.org/SourcesList for more information.
deb http://deb.debian.org/debian buster main
deb-src http://deb.debian.org/debian buster main

deb http://deb.debian.org/debian buster-updates main
deb-src http://deb.debian.org/debian buster-updates main

deb http://security.debian.org/debian-security/ buster/updates main
deb-src http://security.debian.org/debian-security/ buster/updates main

- After:
# See https://wiki.debian.org/SourcesList for more information.
*deb http://deb.debian.org/debian 
buster-backports main contrib non-free*
deb http://deb.debian.org/debian buster main
deb-src http://deb.debian.org/debian buster main

deb http://deb.debian.org/debian buster-updates main
deb-src http://deb.debian.org/debian buster-updates main

deb http://security.debian.org/debian-security/ buster/updates main
deb-src http://security.debian.org/debian-security/ buster/updates main

By doing this i avoided the mentioned error.

Regards,
Sergio


Bug#951207: python3-xapian-haystack: Broken compatibility with pre-2.0 haystack

2020-02-12 Thread Bjoern Franke
Package: python3-xapian-haystack
Version: 2.1.0-3
Severity: important

Dear Maintainer,

commit d3f1e011da3d9bebd88c78fe7a87cd6171ae650c of xapian-haystack
removed the "commit" keyword which e.g. is used by
python3-django-hyperkitty / python3-django-haystack

In commit 253c4c2898f16a5dee2c99324621a14e3e2a789b the above commit was
reverted.

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

Kernel: Linux 4.19.0-7-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_ALL 
to default locale: No such file or directory
UTF-8), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_ALL to default 
locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-xapian-haystack depends on:
ii  python3  3.7.3-1
ii  python3-django-haystack  2.8.1-2
ii  python3-xapian   1.4.11-2

python3-xapian-haystack recommends no packages.

python3-xapian-haystack suggests no packages.



Bug#950592: Will do

2020-02-12 Thread Teus Benschop
Thank you for noticing the issue of parallel builds.

I will implement this soon and upload a new package.

Currently I am waiting for the package to move into testing for the first
time. Once the package is in testing, I can then proceed with this.

Thank you for your contribution towards improving the package.

Met vriendelijke groeten,
With kind regards,

Teus Benschop


Bug#839702: gitlab: logrotate not working?

2020-02-12 Thread Frederik Himpe
Package: gitlab
Version: 12.6.4-1
Followup-For: Bug #839702

Dear Maintainer,

The package should include /etc/logrotate.d/gitlab to rotate logs.
However, then the permissions on /var/log/gitlab and
/var/log/gitlab-shell also need to be changed in order to prevent this
security bug: https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4380



Bug#950741: dosen't work with postgresql 12

2020-02-12 Thread Jehan-Guillaume de Rorthais
Hello,

v2.3~rc2  has been released yesterday. We plan for a release in about one month.

Debian package is available on the github release page[1]. Not sure when/if it
can hit sid.

Regards,

[1] https://github.com/ClusterLabs/PAF/releases/tag/v2.3_rc2



Bug#932844: hcxdumptool FTCBFS: incorrect makefile dependencies

2020-02-12 Thread Paulo
On Tue, 23 Jul 2019 22:10:35 +0200 Helmut Grohne  wrote:
> Source: hcxdumptool
> Version: 5.1.7-1
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> 
> hcxdumptool fails to cross build from source. It first cross builds
> correctly and then make install rebuilds the tools with the wrong
> compiler again. This is due to bad makefile dependencies. Please
> consider applying the attached patch to fix the dependencies.
> 
> I also note that debian/rules violates Debian Policy section 6.4, but
> I'm too lazy to file an RC bug now.
> 
> Helmut

Hello Helmut Grohne,

Could you please explain how d/rules violates policy?
I wonder to fix-it, but I did not understand this particular problem.

Thanks.
kretcheu
[]'s
:x
  



Bug#946519: iptables fails to update rules from fwbuilder

2020-02-12 Thread Raphael Hertzog
Hello,

On Mon, 20 Jan 2020, Arturo Borrero Gonzalez wrote:
> >After upgrading to buster from strech, the iptables defined in fwbuilder 
> > don't works when changed:
> >  iall I get is a message "iptables: Chain already exists" for each rule and 
> > they don't work.
> > 
> >Moreover as I removed network-manager package my system start withour 
> > rules (maybe with default rules) an this moment the script generated by 
> > fwbuilder runs without warnning and rules are applied. Afterwards, if I 
> > tried to aplly diferent rules, I get the warnning messages and the rules 
> > don't work.
> > 
> >At first my system was running the stable version of iptables, 1.8.2-4, 
> > so I move to the testing version, 1.8.3-2, without changes.
> 
> We would need additional information about what ruleset are you (or fwbuilder)
> trying to load.

The user is likely affected by this fwbuilder bug:
https://github.com/fwbuilder/fwbuilder/issues/88

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS



Bug#951206: "Error: Rotation feature not supported by the kernel tracer."

2020-02-12 Thread Paolo Pisati
Package: lttng-tools
Version: 2.11.1-1ubuntu1
Severity: normal

Dear Maintainer,

lttng-tools introduced a regression wrt session rotation when tracing
kernel domain - for more detailed info and a simple reproducer, see here:

https://bugs.launchpad.net/ubuntu/+source/ltt-control/+bug/1862936

See the attached debdiff for a fix (that i already applied & tested locally).

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

Kernel: Linux 5.4.0-14-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lttng-tools depends on:
ii  libc6  2.30-0ubuntu3
ii  libkmod2   26-3ubuntu1
ii  liblttng-ctl0  2.11.1-1
ii  liblttng-ust-ctl4  2.11.0-1
ii  libpopt0   1.16-14
ii  liburcu6   0.11.1-2
ii  libuuid1   2.34-0.1ubuntu6
ii  libxml22.9.4+dfsg1-8ubuntu3
ii  lsb-base   11.1.0ubuntu2

Versions of packages lttng-tools recommends:
ii  babeltrace  1.5.8-1

Versions of packages lttng-tools suggests:
ii  lttng-modules-dkms  2.10.8-1ubuntu2

-- no debconf information
diff -Nru ltt-control-2.11.1/debian/changelog 
ltt-control-2.11.1/debian/changelog
--- ltt-control-2.11.1/debian/changelog 2020-02-06 21:50:54.0 +
+++ ltt-control-2.11.1/debian/changelog 2020-02-12 12:30:52.0 +
@@ -1,3 +1,9 @@
+ltt-control (2.11.1-1ubuntu1) focal; urgency=medium
+
+  * Fix session rotation within kernel domain tracing (LP: #1862936)
+
+ -- Paolo Pisati   Wed, 12 Feb 2020 12:30:52 +
+
 ltt-control (2.11.1-1) unstable; urgency=medium
 
   * [47b26b1] New upstream version 2.11.1
diff -Nru 
ltt-control-2.11.1/debian/patches/0002-Fix-sessiond-check-for-lttng-modules-ABI-2.1-rather-.patch
 
ltt-control-2.11.1/debian/patches/0002-Fix-sessiond-check-for-lttng-modules-ABI-2.1-rather-.patch
--- 
ltt-control-2.11.1/debian/patches/0002-Fix-sessiond-check-for-lttng-modules-ABI-2.1-rather-.patch
   1970-01-01 00:00:00.0 +
+++ 
ltt-control-2.11.1/debian/patches/0002-Fix-sessiond-check-for-lttng-modules-ABI-2.1-rather-.patch
   2020-02-12 12:29:59.0 +
@@ -0,0 +1,43 @@
+From 3029bc92f20d249ebea8779e46f6007aa0519b9a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=A9mie=20Galarneau?=
+ 
+Date: Thu, 19 Dec 2019 22:13:10 -0500
+Subject: [PATCH] Fix: sessiond: check for lttng-modules ABI 2.1 rather than
+ 2.8
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The clear patchset introduces a regression that breaks session
+rotations when the kernel domain is used. The 2.8 lttng-modules ABI
+does not exist yet.
+
+The packet sequence number functionality was introduced in LTTng 2.8,
+which introduced the 2.1 kernel tracer ABI.
+
+Signed-off-by: Jérémie Galarneau 
+Change-Id: Ief97e7e25f6f0fcb5b5b97b39abb417c1eb327ec
+---
+ src/bin/lttng-sessiond/kernel.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/src/bin/lttng-sessiond/kernel.c b/src/bin/lttng-sessiond/kernel.c
+index 1f987ef7..2626e98b 100644
+--- a/src/bin/lttng-sessiond/kernel.c
 b/src/bin/lttng-sessiond/kernel.c
+@@ -1445,9 +1445,10 @@ int 
kernel_supports_ring_buffer_packet_sequence_number(void)
+   }
+ 
+   /*
+-   * Packet sequence number was introduced in 2.8
++   * Packet sequence number was introduced in LTTng 2.8,
++   * lttng-modules ABI 2.1.
+*/
+-  if (abi.major >= 2 && abi.minor >= 8) {
++  if (abi.major >= 2 && abi.minor >= 1) {
+   /* Supported */
+   ret = 1;
+   } else {
+-- 
+2.25.0
+
diff -Nru ltt-control-2.11.1/debian/patches/series 
ltt-control-2.11.1/debian/patches/series
--- ltt-control-2.11.1/debian/patches/series2020-02-06 21:14:42.0 
+
+++ ltt-control-2.11.1/debian/patches/series2020-02-12 12:30:28.0 
+
@@ -1,2 +1,3 @@
 0001-Fix-compile-fails-for-x32-arch.patch
 fix-lttng-health-check-manpage.patch
+0002-Fix-sessiond-check-for-lttng-modules-ABI-2.1-rather-.patch


Bug#951205: ITP: dlpack -- Open In Memory Tensor Structure and operator interface for deep learning

2020-02-12 Thread Mo Zhou
Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: dlpack
  Version : git head
* URL : https://github.com/dmlc/dlpack
* License : apache-2.0
  Programming Lang: C
  Description : Open In Memory Tensor Structure and operator interface for 
deep learning

mxnet dependency



Bug#951204: libdleyna-core-1.0-5 can't be upgraded: trying to overwrite '/usr/lib/x86_64-linux-gnu/libdleyna-core-1.0.so.5.0.0', which is also in package libdleyna-core-1.0-3:amd64 0.6.0-1

2020-02-12 Thread Iain Lane
Package: libdleyna-core-1.0-5
Version: 0.6.0-3
Severity: serious

Heya,

Disclaimer: this happened on Ubuntu and I haven't tried on Debian yet.
Not sure if this bug should be RC since this affects only people who
picked up 0.6.0-1 from experimental. (Ubuntu synced this so it's a more
important problem for us on that side.)

When upgrading, apt bombed out like this:

  Selecting previously unselected package libdleyna-core-1.0-5:amd64.^M
  Preparing to unpack .../064-libdleyna-core-1.0-5_0.6.0-3_amd64.deb ...^M
  Unpacking libdleyna-core-1.0-5:amd64 (0.6.0-3) ...^M
  dpkg: error processing archive 
/tmp/apt-dpkg-install-B5lolQ/064-libdleyna-core-1.0-5_0.6.0-3_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libdleyna-core-1.0.so.5.0.0', 
which is also in package libdleyna-core-1.0-3:amd64 0.6.0-1

Looks like a missing Breaks/Replaces: 0.6.0-1 had the bumped SONAME but
the package wasn't renamed until later, so there's a file conflict with
upgrades from that version only.

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]



Bug#951203: RFS: cglm/0.6.2-1 [ITP] -- Optimized OpenGL Mathematics library for C

2020-02-12 Thread Leon Marz

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

* Package name : cglm
Version : 0.6.2-1
Upstream Author : Recep Aslantas 
* URL : https://cglm.readthedocs.io
* License : MIT
* Vcs : https://github.com/recp/cglm
Section : libs

It builds those binary packages:

libcglm-doc - Documentation for the cglm library
libcglm-dev - Development files for the cglm library
libcglm0 - Optimized OpenGL Mathematics library for C

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


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

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

dget -x https://mentors.debian.net/debian/pool/main/c/cglm/cglm_0.6.2-1.dsc

Changes since the last upload:

* Initial release (Closes: #950988)

Regards,

Leon Marz



Bug#951202: RFS: cglm/0.6.2-1 [ITP] -- Optimized OpenGL Mathematics library for C

2020-02-12 Thread Leon Marz
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: cglm
   Version : 0.6.2-1
   Upstream Author : Recep Aslantas 
 * URL : https://cglm.readthedocs.io
 * License : MIT
 * Vcs : https://github.com/recp/cglm
   Section : libs

It builds those binary packages:

  libcglm-doc - Documentation for the cglm library
  libcglm-dev - Development files for the cglm library
  libcglm0 - Optimized OpenGL Mathematics library for C

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/c/cglm/cglm_0.6.2-1.dsc

Changes since the last upload:

   * Initial release (Closes: #950988)

Regards,

--
  Leon Marz



Bug#950688: boost1.71: python autopkgtest fails

2020-02-12 Thread Dimitri John Ledkov
This is fixed in unstable, yet is awaiting for gcc-10 to get fixed up
and migrated.
At the moment cmake tests fail to find libgcc-s1.



Bug#951201: libu2f-udev: Deprecate (unecessary since udev 244)

2020-02-12 Thread nicoo
Package: libu2f-udev
Version: 1.1.10-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Upstream systemd/udev merged a pull request [1] that adds autodetection
of U2F/FIDO2 devices, which landed in udev 244-rc1.

Investigate if removal is possible; do non-systemd installs have a working udev?

[1]: https://github.com/systemd/systemd/pull/13357

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

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

Versions of packages libu2f-udev depends on:
ii  udev  244.1-1

libu2f-udev recommends no packages.

libu2f-udev suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAl5D9mERHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7Mtugw//WqWxNd5iJb+LmiCXrG4xazSHcUoEQUe/
rBojQjb6XU1pVXR1FiVBjPMYhos62F2XpMln05k087sJ4DyGKj2Y04vwYAnPQdft
Jz9dSUohRBOEn8gvfZ+swnjiQEVAqTgIAJQXVA8/p+U0fEVN/OrGXmiZEJqBU5bu
eQwtwXQH4EJh3rO0+vAcD+rpADztboV67Xj6GAmkAZ8oyoxuG8gg8Rl0XMRivZdA
c469TDyxUtbUtsCyaUlyQ/+CUjm9WWvkQpFv+hIE3+za8Edeacz7WYfDxj7UGAnE
lwo4KY3ZFeR45ZcC7AaZKw+Yk5gqj2LSnHXOSly+8RWgf0w1skRRRYaD9ix9+cxN
e4BlDUNMqPHCBnVultSFWlDGQ8iJrHl/XLxwfKANaILfejcDI13Yu7u1vmZDE2xD
VSnxqElrXw3Q6q6QzuYTkqhzY1TR5dCTpSbzaPtLfp5KjFDbbkz+VrOJOb40Pbho
QgsiuYbf/JVGbKtws3Wo/F1CEKjOj9E8lYXjZeQVY+KabAoC39AnN7p6afUexk4V
zCm7CpSxG8HiKSkyHOrhwHpd+HKzCvYU4Y0iObmIhDfwu6fxzibt0UKuE48IokLf
VcWaPI6y/dc7JGUi80i2hpOGY0dgymvolUwIOgcKwyTyTQoXsqMyqAg9Bx3TPhux
9yqNIYnuTF0=
=HsNd
-END PGP SIGNATURE-



Bug#833270: Poor Text Wrapping for Wastebasket Icon Text - Bug 833270

2020-02-12 Thread Peter W Wannop

Hi,

I've just switched to Debian with LXDE and I am getting the test for the 
desktop wastebasket icon spread over 2 line as in the subject bug.


I know it's not a big issue but it's annoying to look at. Has this been 
fixed or is there a work around.


Kind Regards

Peter



Bug#951117: libecore1: .xsession-errors eats all disk space

2020-02-12 Thread sergio
On 12/02/2020 00:44, Ross Vandegrift wrote:

> I haven't seen this, so lowering the priority to normal.  Let's try to
> figure out the trigger.

I'm sure there no trigger, just something fails inside E.

> How do you start enlightenment?

With enlightenment_start in ~/.xsession via xdm.


> Does your desktop suspend after inactivity?

No suspend, noway! I have only xscreensaver and
xorg.conf.d/00-flags.conf that turns off my monitors after 40 minutes of
inactivity.


> Do you leave any other EFL apps running?

I don't use EFL apps at all. Moreover my E settings are very
minimalistic: most modules are disables. I have only system/dbus,
core/notifications, core/settings/panel, core/windows_switcher and all
settings modules.


> Does this end if you restart enlightenemnt? (Main -> Enlightenment ->
> Restart)

I don't know even how to check it. I notice this error only when free
space ends, and I must kill / restart x session to release
.xsession-errors file.


> This bug was opened against libecore1, not enlightenment.  I've
> reassigned.

I was misled efl_ functions.


-- 
sergio.



Bug#951184: RFP: libfido2 -- communicate with a FIDO device over USB

2020-02-12 Thread nicoo
Control: retitle -1 ITP: libfido2 -- communicate with a FIDO device over USB

On Tue, Feb 11, 2020 at 10:42:49PM +, Colin Watson wrote:
> libfido2 provides library functionality and command-line tools to
> communicate with a FIDO device over USB, and to verify attestation and
> assertion signatures.
> [...]
> This is going to be an optional dependency of OpenSSH 8.2 (optional at
> build time, I think, though it seems sufficiently useful that I'd be
> inclined to link against it by default if it doesn't impose an
> unreasonable run-time footprint), needed for U2F/FIDO support which is
> the principal new feature in that release.  As such I'd like to be able
> to enable it.

Colin and I discussed this in #debian-uk, and agreed to collaborate on this:

> cjwatson> Anyone fancy packaging libfido2 so I don't have to?
> nicooo> cjwatson: I'd be happy to (co)maintain that, I maintain a bunch
> of the Yubico tooling anyhow (unfortunately)
> nicooo> [...] I'm pretty keen on U2F support in OpenSSH  <3
> cjwatson> nicooo: I'd appreciate it very much, thank you
> nicooo> cjwatson: Would you want to be listed as a co-maintainer?
> cjwatson> nicooo: Happy to if it's helpful


signature.asc
Description: PGP signature


Bug#951187: proj: 'make distclean' deletes README which is not regenerated

2020-02-12 Thread Bas Couwenberg

Control: tags -1 pending

I've added a patch to fix this issue, it adds the README target to 
all-local to have it created by `make`.


Due to the infrastructure outage I'll wait a bit before uploading.

Kind Regards,

Bas



Bug#951200: AW: Re: Bug#951200: base-files: unable to upgrade, conffile error

2020-02-12 Thread Luca Koroll
Thanks for your fast response. Removing the folder did not help unfortunately. 
The folder is temporary and is removed after dpkg-installation-process.

Is there a way to safely reinstall base-files without having to reinstall the 
whole system?

>  Ursprüngliche Nachricht 
> Von: Santiago Vila 
> Datum: Mi., 12. Feb. 2020, 12:50
> An: Luca Koroll , 951...@bugs.debian.org
> Betreff: Re: Bug#951200: base-files: unable to upgrade, conffile error
> On Wed, Feb 12, 2020 at 11:31:35AM +, Luca Koroll wrote:
> > Package: base-files
> > Version: 9.9+deb9u11
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > after rebooting my system and trying to update my packages an error with 
> > the base-files package occured which brought me into the situation that I 
> > am unable to install any new packages.
> > There must be a problem with the conffile that is temporarily created when 
> > installing base-files.
> > 
> > apt-clean, dpkg-reconfigure base-files didn't help. The checksum of the 
> > packages are correct.
> > 
> > The error line states "new info file "/var/lib/dpkg/tmp.ci/conffiles" can't 
> > be installed: incorrect message
> > There is no further error code or information.
> 
> Seems like a bug in dpkg, not base-files.
> 
> Is there any improvement if you "rm -rf /var/lib/dpkg/tmp.ci" and try again?
> 



Bug#951200: Re: Bug#951200: base-files: unable to upgrade, conffile error

2020-02-12 Thread Santiago Vila
On Wed, Feb 12, 2020 at 12:09:23PM +, Luca Koroll wrote:
> Thanks for your fast response. Removing the folder did not help 
> unfortunately. The folder is temporary and is removed after 
> dpkg-installation-process.
> 
> Is there a way to safely reinstall base-files without having to reinstall the 
> whole system?

Well, can probably "fake" that the base-files upgrade already happened
by doing this:

Edit /var/lib/dpkg/status, search for base-files and change Version by hand.
Change /etc/debian_version by hand.can probably "fake" that the base-files 
upgrade already happened by doing this:
Maybe some other thing I can't remember right now.

I'm going to reassign this to dpkg if you don't mind.

Thanks.



Bug#951002: 'sleep 10' makes the problem go away

2020-02-12 Thread Chris Ward
I set up ubuntu 20.04 . The problem still happened. But then I added a
'sleep 10' to chroot_devpts , so it now reads
remove)
Echo_message "Begin unmounting /dev/pts..."
sleep 10

# Checking lock file
Check_lockfile .lock
and the problem went away. So it looks like something is not completing
before lb calls this script. Can you tell what ? It's not really
satisfactory to depend on timing here.


  1   2   >