Bug#920775: RFS: python-css-parser/1.0.4-1 [ITP]

[Chris Lamb]

Hi Nicholas,

> No one has responded to this RFS since it was filed 12 Jan.  Would you
> please sponsor and review this NEW package

Sure. python-css-parser_1.0.4-1_amd64.changes uploaded.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#921317: ruby-blade-qunit-adapter: Incomplete debian/copyright?

[Chris Lamb]

Source: ruby-blade-qunit-adapter
Version: 2.0.1-1
Severity: serious
Justication: Policy §12.5
X-Debbugs-CC: Utkarsh Gupta , 
ftpmas...@debian.org

Hi,

I just ACCEPTed ruby-blade-qunit-adapter from NEW but noticed it was 
missing attribution in debian/copyright for at least the qunit.js code
copy.

This is in no way exhaustive so please check over the entire package 
carefully and address these on your next upload.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#921176: redis-server service is failing to start in buster lxc container

[Chris Lamb]

Hi,

> redis-server service is failing to start in buster lxc container

Any update on this? :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#921246: llvm-toolchain-7: FTBFS on kfreebsd-any

[Sylvestre Ledru]

Le 03/02/2019 à 23:55, Svante Signell a écrit :

On Sun, 2019-02-03 at 23:39 +0100, Sylvestre Ledru wrote:

Le 03/02/2019 à 17:21, Sylvestre Ledru a écrit :

Le 03/02/2019 à 15:28, Svante Signell a écrit :

Source: llvm-toolchain-7
Version: 7_7.0.1-4
Severity: important
Tags: ftbfs, patch
User: debian-k...@lists.debian.org
Usertags: kfreebsd

Hello,

Currently llvm-toolchain-7 FTBFS on GNU/kFreeBSD dues to a missing

Looks like it wasn't enough:

https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-7=kfreebsd-amd64=1%3A7.0.1-6=1549244138=0

/usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-kfreebsd-gnu/8/../../../x86_64-kfreebsd-gnu/libc.so when 
searching for -lc
/usr/bin/ld: 
/usr/lib/gcc/x86_64-kfreebsd-gnu/8/../../../x86_64-kfreebsd-gnu/libc.a(cxa_atexit.o):
 relocation R_X86_64_32 against `.bss' can not be used when making a shared 
object; recompile with -fPIC

This might be caused by the stage2 build.
I had similar issues that some flags were not passed from stage1 to stage2
I fixed that
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/blob/7/debian/rules#L355

but this might be a different issue!

Cheers,
S

Bug#921316: python3-sqt: Depends: python3 (< 3.6) but 3.7.2-1 is to be installed

[Adrian Bunk]

Package: python3-sqt
Version: 0.8.0-2
Severity: serious

The following packages have unmet dependencies:
 python3-sqt : Depends: python3 (< 3.6) but 3.7.2-1 is to be installed

Was this binary built in an old/outdated chroot with Python 3.6
as default?

Bug#921293: hwloc: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Il 04/02/19 07:44, Brice Goglin ha scritto:
> Le 04/02/2019 à 07:15, Samuel Thibault a écrit :
>> Control: severity -1 important
>>
>> Hello,
>>
>> Paolo Greppi, le lun. 04 févr. 2019 00:59:40 +0100, a ecrit:
>>> Package: hwloc
>>> Version: 1.11.12-1
>>> Severity: serious
>>>
>>> I tested your package against a draft package for doxygen 1.8.15:
>>> https://bugs.debian.org/919413
>> This is not serious yet, until it actually gets uploaded.
>>
>>> and it FTBFS with this error:
>>> ! LaTeX Error: File `listofitems.sty' not found.
>> Isn't the doxygen-latex package supposed to cope with this kind of
>> dependency, to avoid having to patch over dozens of packages with new
>> upstream release of just doxygen?
> 
> 
> Indeed we don't seem to include any latex sty file explicitly. Doxygen
> is the one generating a latex source that requires listofitems.sty.
> 
> Brice

Yes we patched doxygen.sty:
https://salsa.debian.org/paolog-guest/doxygen/blob/master/debian/patches/longtabu.diff
in a way that works for hundreds of packages except 9.

I lack the latex skills to understand what is going on in your case.

One alternative line of action is waiting for the actual tabu fix.

Paolo

Bug#921188: closed by Ritesh Raj Sarraf (Bug#921188: fixed in bpfcc 0.8.0-2)

[Vincent Bernat]

 ❦  4 février 2019 11:48 +0530, Ritesh Raj Sarraf :

>> The .so should go in the -dev package, while the .so.0 and .so.0.8.0
>> should go to the non -dev package. Currently, the opposite is true.
>
> Hi Vincent,
>
> So many things I must be missing something very obvious. Does this look
> good to you ? If not, can you please submit a patch.

Yes, this looks good! Thanks!
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#909643: closed by Ben Hutchings (Re: doing a dist-upgrade from debian7 to debian8 ended with a non bootable system)

[Ben Hutchings]

On Mon, 2019-02-04 at 10:43 +0900, Stephane Tranchemer wrote:
> Hi,
> You are right Ben, this was the culprit.
> 
> The bottom line is, in a previous version of the debian distribution the
> busybox package was called "busybox-cvs-static".
> 
> But at a time it just gone to "busybox-static", so when doing the normal
> procedure of
> apt-update
> apt-upgrade
> apt-distupgrade
> 
> it is not replaced by the newer version...

Yes, and it obviously should have been.

> Quite a nasty pitfall.
> 
> Thanks for your time.

It appears that busybox-cvs was only uploaded once and only included in
the Debian 3.1 "sarge" release.  It was then obsoleted by newer
versions of busybox, but that didn't build the transitional packages
needed to cause an automatic upgrade.

But I think it is now much to late to do anything about this.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.




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

Bug#921315: samtools: baseline violation on i386

[Adrian Bunk]

Source: samtools
Version: 1.9-2
Severity: serious
Tags: patch

SSE is not part of the i386 baseline, fix:

--- debian/rules.old2019-02-03 20:43:51.747130097 +
+++ debian/rules2019-02-03 20:44:04.383129977 +
@@ -5,7 +5,7 @@
 
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 ifneq (,$(filter $(DEB_HOST_ARCH),i386 kfreebsd-i386 hurd-i386))
-  export DEB_CFLAGS_MAINT_APPEND=-msse -mfpmath=sse
+  export DEB_CFLAGS_MAINT_APPEND=-ffloat-store
 endif
 
 %:

Bug#918498: /usr/share/initramfs-tools/hooks/keymap: Please ship in the kbd or console-setup package

[Josh Triplett]

On Sun, Feb 03, 2019 at 11:48:06PM +0100, Ben Hutchings wrote:
> On Sun, 06 Jan 2019 10:59:47 -0800 Josh Triplett  > wrote:
> > Package: initramfs-tools-core
> > Version: 0.132
> > Severity: normal
> > File: /usr/share/initramfs-tools/hooks/keymap
> > 
> > initramfs-tools ships a hook for setting a keymap, which complains on
> > every run of update-initramfs without kbd or console-setup installed.
> > Please consider moving this hook to kbd or console-setup, so that it
> > doesn't run at all without one of those packages installed.
> 
> This only happens if you set KEYMAP=y in initramfs.conf or you install
> a package that does that.

Yes, I'm aware of that.

> (cryptsetup-initramfs does so, on the
> assumption that you will need to type a passphrase.)

And I have cryptsetup-initramfs installed (and kbd and console-setup
intentionally not installed).

> I don't consider this a bug.

I get a complaint every single time I upgrade packages that cause the
initramfs trigger to run, and every time I regenerate the initramfs
myself. I'd like to stop getting that message.

This hook doesn't make sense to run unless kbd or console-setup is
installed. Rather than having the hook in initramfs-tools and checking
if kbd or console-setup is installed, why not move the hook to one of
those packages (where it can *know* that package is installed)?

cryptsetup-initramfs already Recommends kbd and console-setup. This
error message feels tantamount to emitting a warning on every single apt
upgrade saying "there are recommended packages you don't have
installed".

Bug#905940: convert package to dh-elpa

[Nicholas D Steeves]

Hi Ralf,

On Thu, Jan 24, 2019 at 07:52:18AM +0100, Ralf Treinen wrote:
> Hi Nicholas,
> 
> thanks for working on this package.

You're welcome :-)

> On Tue, Jan 22, 2019 at 03:45:40PM -0700, Nicholas D Steeves wrote:
> 
> > Done.  Here's the MR:
> > 
> >   https://salsa.debian.org/ocaml-team/tuareg-mode/merge_requests/1
> > 
> > Please note that autopkgtests for Tuareg require one of:
> > 
> > 1. ocaml-mode being elpafied too.
> > 2. a manual workaround to pull in ocaml-mode to the autopkgtestbed.
> 
> I will look to your proposed changes soon. Though I do not see
> why you mixed this up with unrelated cosmetic modifications. Renaming
> tuareg-mode, however, is out of question.

I included the whitespace cleanup as a courtesy, and for the sake of
completeness.  Is it unwanted?  Unless I made a mistake somewhere
there should be one operation per commit so it will be easy to drop
any unwanted commits.

As for bin:tuareg-mode vs bin:elpa-tuareg-mode, the former requires
extra work (kind of like a "Provides: virtual-package", but for
Package.el rather than dpkg).  Here is a brief case for
bin:elpa-tuareg

1. Compatibility with GNU ELPA/MELPA/Package.el without extra work. eg:
   https://melpa.org/#/tuareg, and not https://melpa.org/#/tuareg-mode

2. The mode is named "tuareg.el", "tuareg.el" has "(provide 'tuareg)"
   rather than "(provide 'tuareg-mode)".

3. Upstream README.md refers to the software as "Tuareg" rather than
   "tuareg-mode".  I edited the descriptions for consistency with MELPA
   and upstream documentation.

Do you prefer consistency with historical/existing Debian package
names rather than consistency with what Emacs uses for its own
dependency resolution and with MELPA?  That's fine with me, but please
share your rationale.  Also affects bin:ocaml-mode vs bin:elpa-caml

I'd be happy to do a v2 MR asap, after learning what the contentious
issues/commits are. :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#921293: hwloc: FTBFS with upcoming doxygen 1.8.15

[Brice Goglin]

Le 04/02/2019 à 07:15, Samuel Thibault a écrit :
> Control: severity -1 important
>
> Hello,
>
> Paolo Greppi, le lun. 04 févr. 2019 00:59:40 +0100, a ecrit:
>> Package: hwloc
>> Version: 1.11.12-1
>> Severity: serious
>>
>> I tested your package against a draft package for doxygen 1.8.15:
>> https://bugs.debian.org/919413
> This is not serious yet, until it actually gets uploaded.
>
>> and it FTBFS with this error:
>> ! LaTeX Error: File `listofitems.sty' not found.
> Isn't the doxygen-latex package supposed to cope with this kind of
> dependency, to avoid having to patch over dozens of packages with new
> upstream release of just doxygen?


Indeed we don't seem to include any latex sty file explicitly. Doxygen
is the one generating a latex source that requires listofitems.sty.

Brice

Bug#921259: KiCad 5.1 appears to be 6.0 (experimental)

[Geert Stappers]

Control: tag -1  wontfix

On Sun, Feb 03, 2019 at 11:47:56PM +0100, Carsten Schoenert wrote:
>   ...
> The reason behind the current used number '6.0.0' is grounded on the
> original next planed version number for KiCad.
>   ...


Acknowlege. Thanks.

Based upon that information I did tag this bugreport as won't be fixed.


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#919413: Bug#921293: hwloc: FTBFS with upcoming doxygen 1.8.15

[Samuel Thibault]

Control: severity -1 important

Hello,

Paolo Greppi, le lun. 04 févr. 2019 00:59:40 +0100, a ecrit:
> Package: hwloc
> Version: 1.11.12-1
> Severity: serious
> 
> I tested your package against a draft package for doxygen 1.8.15:
> https://bugs.debian.org/919413

This is not serious yet, until it actually gets uploaded.

> and it FTBFS with this error:
> ! LaTeX Error: File `listofitems.sty' not found.

Isn't the doxygen-latex package supposed to cope with this kind of
dependency, to avoid having to patch over dozens of packages with new
upstream release of just doxygen?

Samuel

Bug#921188: closed by Ritesh Raj Sarraf (Bug#921188: fixed in bpfcc 0.8.0-2)

[Ritesh Raj Sarraf]

On Sun, 2019-02-03 at 18:22 +0100, Vincent Bernat wrote:
> The .so should go in the -dev package, while the .so.0 and .so.0.8.0
> should go to the non -dev package. Currently, the opposite is true.

Hi Vincent,

So many things I must be missing something very obvious. Does this look
good to you ? If not, can you please submit a patch.

commit 6bb608054d8f5af4f70d512a63edd1c1ce811dd4 (HEAD -> master)
Author: Ritesh Raj Sarraf 
Date:   Mon Feb 4 11:46:44 2019 +0530

Fix .so and its symlink in their respective pacakges

Thanks: Vincent Bernat

diff --git a/debian/libbpfcc-dev.install b/debian/libbpfcc-dev.install
index 626fd75..529cf38 100644
--- a/debian/libbpfcc-dev.install
+++ b/debian/libbpfcc-dev.install
@@ -1,3 +1,3 @@
 usr/include/bcc/*
-usr/lib/*/libbcc.so.*
 usr/lib/*/pkgconfig/libbcc.pc
+usr/lib/*/libbcc.so
diff --git a/debian/libbpfcc.install b/debian/libbpfcc.install
index 76feb4d..0eac52e 100644
--- a/debian/libbpfcc.install
+++ b/debian/libbpfcc.install
@@ -1 +1 @@
-usr/lib/*/libbcc.so
+usr/lib/*/libbcc.so.*



-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System


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

Bug#919272: Is multiple-layers of alternatives a good thing to users?

[Mo Zhou]

Hi Ian and Thibaut,

Inspired by Thibaut's comment, I worked out a good solution for
the co-installation problem, which only results in a single layer
of alternatives.

Thibaut's proposed layout:
>   Package: libblis2-openmp,  Provides: libblas.so.3, libblis.so.2
>   Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
>   Package: libblis2-serial,  Provides: libblas.so.3, libblis.so.2
>   Package: python3-numpy,Depends: libblas.so.3

My updated version, all variants are co-installable now:

 Package: libblis2-openmp,  Provides: libblas.so.3, libblis.so.2
 Package: libblis2-pthread, Provides: libblas.so.3, libblis.so.2
 Package: libblis2-serial,  Provides: libblas.so.3, libblis.so.2
 Package: libblis2 (meta),
 Package: python3-numpy,Depends: libblas.so.3

The meta package is still necessary because of symbols/shlibdeps.
Different threading variants have the same ABI/API, so the
dependency template is written as

 libblis.so.2 libblis2 #MINVER#

instead of e.g.

 libblis.so.2 libblis2-openmp #MINVER#

On Sun, Feb 03, 2019 at 09:34:08PM +, Ian Jackson wrote:
> In general coinstallability is a good thing.
> ...
> This would mean that the user could choose a different library for
> "programs which wanted BLAS" and "programs which wanted BLIS" but I
> don't think that is a problem ?
> ...
> I agree that multiple layers of alternatives indirection is
> undesirable.  But I think these libraries can be made coinstallable
> without that.

My initial design of package layout is hierarchical. Inspired by
the comments I found the above solution after a rethink. BLIS
packaging has been updated and I'm testing it now.

Thank you for comments.

Bug#921272: texlive-latex-extra: package tabu broken when xcolor is used

[Hilmar Preuße]

forcemerge 920621 921272
stop

On 03.02.19 21:23, Thomas Schiex wrote:

> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
>
>Compiling the LaTeX doxygen-generated documentation for debian package 
> toulbar2 fails. 
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  A minimal latex file does not compile anymore on texlive (did previously)
> 
Already reported, merging. Upstream is working, for workarounds see
upstream bug.

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#921314: devscripts: provide salsa request_access command

[Michael Gilbert]

package: devscripts
severity: wishlist

It would be a nice improvement if the salsa script supported gitlab's
request_access, which allows a user to request membership to a team.

Best wishes,
Mike

Bug#921313: ITP: node-solid-keychain -- keychain for use with Web Cryptography API in Node.js

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-solid-keychain
  Version : 0.1.3
  Upstream Author : Anvil Research, Inc.
* URL : https://github.com/solid/keychain
* License : Expat
  Programming Lang: JavaScript
  Description : keychain for use with Web Cryptography API in Node.js

 This package provides KeyChain
 for use with Web Cryptography API in Node.js.
 .
 The Web Cryptography API
 is the World Wide Web Consortium’s (W3C) recommendation
 for a low-level interface
 that would increase the security of web applications
 by allowing them to perform cryptographic functions
 without having to access raw keying material.
 .
 Node.js is an event-based server-side JavaScript engine.

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxX0xsACgkQLHwxRsGg
ASF1cw/7BcHR6OkJb4WJu/dITbUZWfDknk9Ce/oYyz9tzn1Rcge04dIWZOwgNbNb
WFbThA62eNvLmzUsS17F6rs1I90K3hI1jaQ3oU6jyfKSqTFkWSSrJQiy0aFr/4x9
5Puxf4gFsc+3aQMTJDZ7xxJ91lRrscW5SotukKsrq/k2oJHjvTileolwZh8AoorB
NA0b4WgPUmDMGvjdbltJDLoSdYKWULXZbGSdFkQI1bmwzRqmwCZ5jUzIMN0VbJ6o
DYUWdtxPPiyHNrHh27OjCTjMOxItXsKYjFPT5DDr6cEpYuNLjVPuXYGWYdIUqImV
1H7rb7u7eGVVpRj8GAEx0PbyPtOzVN12/0jIovrBA8L5rc4IbZCNzHKka0Ub+bjs
Aft3WBZ+cbtNk3b0sddb/+T9VBP/9HxX0VjSvQqOWI8icf8wJX76dq/9tRodeFql
/EkY1AHX/SHAEF6tDqbohXWokp99liKAp+XHG8ZtfS0xx/LZFUPzyrbBbW/pGtZ8
60hoLi+JK/uNnjMVgG7HYG/5paYoje1R0Nl0x4bSkTH/V2+SJShYctx7hY/PyWp2
pTdv5hdXkmO2DEzuyyadmka9ei6HFU1Jqm9XzDA4pvV8h7Az0MCQx+6fElktVyZb
KLZjjaTk1C7SxWP8dGRaCQYjcfV+GDWosd+5++Up+JQ4GRKXJ3Y=
=veDw
-END PGP SIGNATURE-

Bug#921256: RM: apriltag [arm64 armel armhf mips64el mipsel] -- RoQA; gcc hits 150 minute buildd timeout

[Dima Kogan]

Dima Kogan  writes:

> Otherwise, I can look at patching the sources to obviate the need to
> compile their giant "source" files. That'd probably be a good thing to
> do anyway. This is the preferred solution, right?

Actually, this was straightforward, and I'm about to push a fixed
package. Thanks.

Bug#921312: libsaxonhe-java: description says XSLT 3.0 is unsupported but upstream websites disagree

[Paul Wise]

Package: libsaxonhe-java
Version: 9.9.0.2+dfsg-1
Severity: important

The description says XSLT 3.0 is unsupported but the upstream websites
say it is supported. The upstream websites and feature matrix makes it
clear that only basic support is available, but it is supported.

$ apt-cache show libsaxonhe-java | grep -B2 3.0
 at the basic level of conformance defined by W3C. Not included in
 the Home Edition are: schema processing and schema aware XSLT and XQuery;
 support for the 3.0 versions of the specifications; numerous Saxon extensions;

$ w3m -dump http://saxon.sourceforge.net/ | grep -A3 Saxon-HE.*home
  • Saxon-HE (home edition) is an open source product available under the
Mozilla Public License version 2.0. It provides implementations of XSLT
(3.0), XQuery (3.1), and XPath (2.0 and 3.1) at the basic level of
conformance defined by W3C. It is available for Java and .NET.

$ w3m -dump https://www.saxonica.com/html/products/products.html | grep -C1 
Saxon-HE.*3.0
 Home Edition: open-source entry-level product (available from
Saxon-HE SourceForge and Maven). Provides implementations of XSLT 3.0, XQuery
 3.1, and XPath 3.1 at the basic level of conformance defined by W3C.

https://www.saxonica.com/html/products/feature-matrix-9-9.html

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages libsaxonhe-java depends on:
ii  libdom4j-java2.1.1-2
ii  libicu4j-java62.1-1
ii  libintellij-annotations-java 16.0.3-1
ii  libjdom1-java1.1.3-2
ii  libxml-commons-resolver1.1-java  1.2-9
ii  libxom-java  1.2.10-1

libsaxonhe-java recommends no packages.

libsaxonhe-java suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#921311: ITP: canboat -- NMEA 2000 (and 0183) toolkit for marine data networks

[Philip J Freeman]

Package: wnpp
Severity: wishlist
Owner: Philip J Freeman 

* Package name: canboat
  Version : 1.2.1
  Upstream Author : Kees Verruijt 
* URL : https://github.com/canboat/canboat
* License : GPL
  Programming Lang: C, Perl, PHP
  Description : NMEA 2000 (and 0183) toolkit for marine data networks

CANboat provides NMEA 2000 (n2k) and NMEA 0183 utilities for interfacing with
marine onboard data networks. An NMEA 2000 PGN decoder can read and decode N2K
messages. You can also generate and publish n2k messages and send them to the
network. USB devices, like the Actisense NGT-1 NMEA2000 PC Interface, or CAN
devices can be used to interface withthe network.
Another utility can read NMEA 0183 data and send it to stdout. You can tee data
to TCP sockets to send data to 3rd party data brokers.

I use this sotware on my boat on an ongoing basis and would like to package it
for my distro. I'm working on some other Sailing/boating related debian
packages as well.

I am not a DD, so I will need a sponsor.

Bug#921310: dnsmasq "segment fault" bug when total conf files size is too large

[Zac Morris]

Package: dnsmasq
Status: install ok installed
Priority: optional
Section: net
Installed-Size: 71
Maintainer: Simon Kelley 
Architecture: all
Version: 2.76-5+deb9u2
Depends: netbase, dnsmasq-base (>= 2.76-5+deb9u2), init-system-helpers (>=
1.18~)
Suggests: resolvconf
Conflicts: resolvconf (<< 1.15)
Conffiles:
 /etc/init.d/dnsmasq 619ec632736050c3f49e43ecf218efce
 /etc/default/dnsmasq 8528b9b07acf4cbac231eb21dd3d262c
 /etc/dnsmasq.conf bc949f5cad485a88b585271b933f0c05

When I add conf files from: https://energized.pro/#packs
Any of the files greater than Basic (13MB), cause dnsmasq to crash with a
segmentation fault 0 fault 4.

I do not use resolvconf nor systemd.

This is running on a PC with 16GB of RAM, and a 4 core i3 Intel processor,
not just a small consumer wifi router/ARM box.

My lan.conf file:
  1 listen-address=192.168.1.1,127.0.0.1
  2 cache-size=1000
  3 no-negcache
  4 conf-file=/usr/share/dnsmasq-base/trust-anchors.conf
  5 dnssec
  6 dnssec-check-unsigned
  7
  8 #domain-needed
  9 bogus-priv
 10 no-resolv
 11 no-poll
 12 server=/lan.zacwolf.com/192.168.1.1
 13 server=8.8.8.8
 14 server=8.8.4.4
 15 #server=209.18.47.61
 16 #server=209.18.47.62
 17 strict-order
 18 local=/lan.zacwolf.com/
 19 interface=br0
 20 expand-hosts
 21 domain=lan.zacwolf.com
 22 dhcp-range=192.168.1.100,192.168.1.249,72h
 23 addn-hosts=/etc/dnsmasq_static_hosts.conf
24-50 assign reserved IPs to MACs
 51 #===START TFTP Options
 52 enable-tftp
 53 dhcp-range=tftp,192.168.1.250,192.168.1.253
 54 tftp-root=/var/tftp
 55 tftp-no-fail
 56 #tftp-secure
 57 #tftp-no-blocksize
 58 #===END TFTP OPTIONS
 59 dhcp-option=option6:information-refresh-time,6h
 60 dhcp-option=19,0# option ip-forwarding off
 61 dhcp-option=42,216.239.35.0 # Google NTP server
 62 dhcp-option=44,192.168.1.1  # set netbios-over-TCP/IP nameserver(s)
aka WINS server(s)
 63 dhcp-option=45,192.168.1.1  # netbios datagram distribution server
 64 dhcp-option=46,8# netbios node type
 65
 66 dhcp-authoritative
 67 #dhcp-script=/bin/echo
 68
 69 #Redirect trackers to local webserver
 70 conf-file=/etc/dnsmasq.d/blocks.conf

If the blocks.conf goes over the 13MB Basic file from Energized Pro, I get
the segment fault error.

THANKS!

Bug#921309: ITP: node-trust-json-document -- JSON Document manipulation library

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-trust-json-document
  Version : 0.1.4
  Upstream Author : Anvil Research, Inc.
* URL : https://github.com/anvilresearch/json-document
* License : Expat
  Programming Lang: JavaScript
  Description : JSON Document manipulation library

 Model and manipulate data with ES6 classes,
 JSON Schema initialization and validation,
 JSON Patch, JSON Pointer, and JSON Mappings.
 .
  * works in Node.js and the browser
  * compiled schema initialization and validation methods
  * high-level JSONDocument class for ease of use
  * zero production dependencies
  * compatible with webpack

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxXxhYACgkQLHwxRsGg
ASEvWg//ejSHHzLLRZM+/nExUfc6r6TUcF3VzjzT/oj+eZdDV9fyxt86uYKthMgn
oy1ltDw1N6rCoB6yBPLAmjoUm/CiNix4UZNH0zFcO9xC4k6q3I5sU7XrQvJPTQg1
P0tlKHfIX6wKvefAp17hwD31u3VKVD/5paAWFhj98ux5AZkj1pG/4W7vkj6hwcfM
4/ibnul3RAUJgXzCk6GfsP/7QoXCKwuI+rKghwkQMxHJ0zfX2yHE2w5nnTufhFw9
WABK88HyEPIb6pd9gt4pe+WweCD4Mds1R0o3WJDeMOzdL8iaYAzuQaWk18/ie1Gp
y1gB48R+ngw7JK8BrMGzZlAPll0ii0U9t2Er1TfbtS8dxLng026puMo9rzeKZ91H
xIA4tIEq1ZXimgVSNCh1F+ASMMRAk9yEnu/JQn/tXGCaauCfAF2VToKqjFr1Ds2k
CybRx7pKOAs9EF07Z0abV9gzbUwPVQ2a2Oo2RZrhTMtS57G7bxG357DO4CROZusu
Al9de0RWImqd/9iu7ULx4YmrM7GRIg5b6DGtcyRPQ2bpyLK042Qybg9J6cTsgC0g
hKvCxUwodUl5vIKFI2ni1JZtsRciv1F9I41HxxHLWmY2kxuhIuV/wHbTZ2lmQ2KE
u3Zj/CERlR8jYl4j6C6USreEPXWcZkf7DyRR17Q7t+xKqJXc3IE=
=auEa
-END PGP SIGNATURE-

Bug#921308: firmware-realtek: at start up get the messege firmware: failed to load rtl_bt/rtl8821a_config.bin

[Carlos Calcaneo Roldan]

Package: firmware-realtek
Version: 20190114-1
Severity: normal

Dear Maintainer,

I have a new install of debian with all firmware in place.
Installed on a lenovo 320-15abr

No sure what more info to put. Sorry!

Noticed the error and that that file is not in the list of files included in
firmware-realtek.

Not sure what more I can do.




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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 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)
LSM: AppArmor: enabled

firmware-realtek depends on no packages.

firmware-realtek recommends no packages.

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

-- no debconf information

Bug#920648: ntopng: missing libssl-dev dependency

[Ludovico Cavedon]

Thank you for your help!

Ludovico

On Sun, Feb 3, 2019 at 7:24 PM peter green  wrote:

> I have uploaded a NMU fixing this bug, a debdiff is attatched. Per the NMU
> guidelines since this RC bug is 7 days old with no maintainer response I
> have uploaded the NMU without delay.
>
>

Bug#921307: ITP: node-trust-jwa -- JSON Web Algorithm

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-trust-jwa
  Version : 0.4.6
  Upstream Author : MIT Connection Science
* URL : https://github.com/anvilresearch/jwa
* License : Expat
  Programming Lang: JavaScript
  Description : JSON Web Algorithm

 The JOSE suite of specifications standardizes various mechanisms
 required for integrity protection and encryption
 of data structured and serialized as JSON.

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxXtUYACgkQLHwxRsGg
ASEFPRAAqPFkgzjHHv/GgPkmivzxyH+OU43IFBdrwMIeACtU/zQC2T4N2O3YMJD4
OwKwqslBQ/IixOkV05mhQ6B+ko9u5cK28v38BDaduFX8Y1JMJGTX4LjXckIbXkMG
FepbuOkN56ToqHHli/TfsittOI7SF+XwczXMAufSSiccvsTPH2ttPf2/zAJ98MSZ
xF2yWlw4Hhx6v/z6JWr3m7wna58Aiha55jGF3VsoHfO9oZ7OovqMcb5XUDxy0rtC
RNhSm2qf0V6mBp644SbA1qtIUNi3+QCFER0JREqd4rSc8fPPdr8VQ10eiMUzGLNN
AwYfEpjD1n+GFEBZO6m5LV+BLJcfzRbXqokq1MLmULAoUWJpm9Jjf69wmwnDH6Z2
LCR1sBFpLx2iJX1ihrKei4V0QxfSWlXZBcWmAuM1FVeJ9CEfXTvsa+cX5Xrk+n6l
mnylw+rRXFY8NmJq4/esR8MXZbh9K3uur3jGHgCDjR4ou140F4m9pqU9gW12sWOc
bOh3p1HdYM4C+aWADXOiW6ByOYRLltnNjTcaP6ANGzIZemSYAzhdZzg6vGd0KUYl
p8sgZHJjLNfR5VJ+NQ6TyjBELTmljR2DXa3HrKpCz/ASVqgBlrPpraTh/lr+XIyJ
lmRbUX3Bty6Q3uJhsZQNQBZJ8vttK6BXg1xrdkpL76NNfn79SEM=
=RP7a
-END PGP SIGNATURE-

Bug#918385: The name org.freedesktop.Notifications was not provided by any .service files

[積丹尼 Dan Jacobson]

> "MG" == Michael Gilbert  writes:

MG> The notification-daemon package itself does not provide a systemd
MG> service file.  I'm not sure how notifications are intended to work in
MG> gnome since I don't use it, but it seems like either the service file
MG> or a dependency may be missing.

MG> Other providers of notification-daemon like dunst, xfce4-notifyd, and
MG> many others do include a notifications service file.   You could
MG> choose one of those instead.

All I know is I use
$ pstree
systemd-+-acpid
|-agetty
|-at-spi-bus-laun-+-dbus-daemon
| `-3*[{at-spi-bus-laun}]
|-at-spi2-registr---2*[{at-spi2-registr}]
|-atd

|-chromium-+-chrome-sandbox---chromium---chromium-+-2*[chromium---11*[{chromium}]]
|  |  
|-2*[chromium---9*[{chromium}]]
|  |  
|-2*[chromium---12*[{chromium}]]
|  |  
`-2*[chromium---10*[{chromium}]]
|  |-chromium---6*[{chromium}]
|  `-28*[{chromium}]
|-cron
|-2*[dbus-daemon]
|-dbus-launch
|-dconf-service---2*[{dconf-service}]
|-emacs-+-aspell
|   `-3*[{emacs}]
|-exim4
|-gnome-keyring-d---3*[{gnome-keyring-d}]
|-gvfsd---2*[{gvfsd}]
|-ibus-daemon-+-ibus-dconf---3*[{ibus-dconf}]
| |-ibus-engine-che---5*[{ibus-engine-che}]
| |-ibus-engine-sim---2*[{ibus-engine-sim}]
| |-ibus-extension4*[{ibus-extension-}]
| |-ibus-ui-gtk3---4*[{ibus-ui-gtk3}]
| `-2*[{ibus-daemon}]
|-ibus-portal---2*[{ibus-portal}]
|-ibus-x11---3*[{ibus-x11}]
|-nodm-+-Xorg---3*[{Xorg}]
|  `-nodm---bash-+-icewm-session-+-icewm
||   `-icewmbg
|`-ssh-agent
|-rsyslogd---3*[{rsyslogd}]
|-systemd---(sd-pam)
|-systemd-journal
|-systemd-logind
|-systemd-resolve
|-systemd-timesyn---{systemd-timesyn}
|-systemd-udevd
|-udisksd---4*[{udisksd}]
|-xfstt
|-xterm---bash---pstree

Bug#920648: ntopng: missing libssl-dev dependency

[peter green]

I have uploaded a NMU fixing this bug, a debdiff is attatched. Per the NMU 
guidelines since this RC bug is 7 days old with no maintainer response I have 
uploaded the NMU without delay.

diff -Nru ntopng-3.8+dfsg1/debian/changelog ntopng-3.8+dfsg1/debian/changelog
--- ntopng-3.8+dfsg1/debian/changelog   2019-01-26 08:36:22.0 +
+++ ntopng-3.8+dfsg1/debian/changelog   2019-02-04 01:10:39.0 +
@@ -1,3 +1,10 @@
+ntopng (3.8+dfsg1-2.1) unstable; urgency=high
+
+  * Non-maintainer upload.
+  * Add build-depends on libssl-dev (Closes: 920648)
+
+ -- Peter Michael Green   Mon, 04 Feb 2019 01:10:39 +
+
 ntopng (3.8+dfsg1-2) unstable; urgency=medium
 
   * Fix missing space in postinst migration script (Closes: #920281).
diff -Nru ntopng-3.8+dfsg1/debian/control ntopng-3.8+dfsg1/debian/control
--- ntopng-3.8+dfsg1/debian/control 2019-01-22 01:55:35.0 +
+++ ntopng-3.8+dfsg1/debian/control 2019-02-04 01:10:39.0 +
@@ -27,6 +27,7 @@
python3-breathe,
python3-sphinx,
python3-sphinx-rtd-theme,
+   libssl-dev,
 Standards-Version: 4.3.0
 Homepage: http://www.ntop.org/products/ntop/
 Vcs-Git: https://salsa.debian.org/debian/ntopng.git

Bug#921244: comp/send: strange error and undocumented behaviour when using Bcc-header

[Alexander Zangerl]

retitle 921244 broken bcc handling with transport sendmail/pipe
thanks

On Sun, 03 Feb 2019 14:13:24 +, Harald Geyer writes:
>I get the following error:
>| What now? send
>| sendmail: No recipients specified although -t option used
>| exit 1

could you please provide (possibly sanitised) copies
of your ~/.mh_profile and /etc/nmh/mts.conf?

>Both recipients get messages with different Message-Ids, but the
>content seems to be exactly the same.
...
>I believe this is in conflict
>with the man page of send(1), which states that Bcc-recipients will
>receive a message with a clear indication in the body, warning them
>not to disclose their status as recipients by replying.

i don't see any indication in the send manpage that supports your reasoning.
but looking closely at the FAQ, the post manpage and the actual
code i do see that nmh tries to reformat bcc's under some/many/most
circumstances (and offers a weird nonstandard dcc header to create the
'normal'/classic behaviour of identical copies).

i can confirm that nmh 1.7 has buggy bcc handling, at least
when sendmail/pipe is used as transport:
using a shim program instead of actual sendmail/postfix/whatever i could see
that the sequence of comp-whatnow-post creates TWO messages to transmit,

* one that contains the original body, complete with to: and bcc:,
ie. leaving sendmail/postfix/whatever to handle that bcc:,
which causes normal mail transfer agents to produce the
'normal'/classic bcc: behaviour,
* and one that has the warning-encrusted body but no to: at all and only a blank
bcc: header. that one is clearly untransmittable, which is what causes
  the error message you saw.

i'll get in touch with upstream and have a deeper look at the problem myself
as well.

you might try switching to 'smtp' or 'sendmail/smtp' in /etc/nmh/mts.conf
as a potential workaround until that bug is sorted; note that
according to the mts.conf manpage dcc: is NOT supported if 'sendmail/pipe'
is the transport.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin


signature.asc
Description: Digital Signature

Bug#919072: schleuder: FTBFS in both buster and sid

[Georg Faerber]

Control: reopen -1
Control: found -1 3.3.0-7

Hi,

I've just uploaded 3.3.0-7, which, three times in a row, built fine on
my local machine prior to the upload.

On 19-01-12 13:26:16, Santiago Vila wrote:
> Failures:
> 
>   1) user sends a plain text message from thunderbird being signed-inline
>  Failure/Error: expect(error).to be_empty
>expected `"Error: A serious, unhandleable error happened. Please 
> contact the administrators of this system or service and provide them with 
> the following information:\n\ninvalid byte sequence in US-ASCII\n".empty?` to 
> return true, got false
>  # ./spec/schleuder/integration/send_plain_spec.rb:18:in `block (3 
> levels) in '
>  # ./spec/spec_helper.rb:47:in `block (3 levels) in '
>  # ./spec/spec_helper.rb:46:in `block (2 levels) in '
>
> [...]

However, it seems, this error still happens (sometimes?) [1].

In any case: two done, one more to go.. :)

Cheers,
Georg


[1] https://salsa.debian.org/ruby-team/schleuder/pipelines/35065


signature.asc
Description: Digital signature

Bug#921306: dgit.1: Use a single-font-style macro for a single argument

[Bjarni Ingi Gislason]

Package: dgit
Version: 8.3
Severity: minor
Tags: patch

Dear Maintainer,

>From b706387a72d95ae30652901f126f92be90699b28 Mon Sep 17 00:00:00 2001
>Date: Mon, 4 Feb 2019 02:30:04 +

  Use a single-font-style macro (".B", ".I") for a single argument.

  Remove unneeded quotation marks (").

  The output from "nroff" and "groff" is unchanged with this patch.

  [ There are still some typographical mistakes left. ]

Signed-off-by: Bjarni Ingi Gislason 
---
 dgit.1 | 64 +-
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/dgit.1 b/dgit.1
index 6f89574..f0d2a8f 100644
--- a/dgit.1
+++ b/dgit.1
@@ -462,12 +462,12 @@ Prints version information and exits.
 Tries to fetch a copy of the source code for the dgit-repos-server,
 as actually being used on the dgit git server, as a git tree.
 .TP
-.BI "dgit print-dgit-repos-server-source-url"
+.B dgit print-dgit-repos-server-source-url
 Prints the url used by dgit clone-dgit-repos-server.
 This is hopefully suitable for use as a git remote url.
 It may not be useable in a browser.
 .TP
-.BI "dgit print-dpkg-source-ignores"
+.B dgit print-dpkg-source-ignores
 Prints the -i and -I arguments which must be passed to dpkg-souce
 to cause it to exclude exactly the .git directory
 and nothing else.
@@ -515,7 +515,7 @@ distro's
 config setting (see CONFIGURATION, below), or failing that, the
 uploader trailer line in debian/changelog.
 .TP
-.BR --no-sign
+.B --no-sign
 does not sign tags or uploads (meaningful only with push).
 .TP
 .TP
@@ -527,7 +527,7 @@ Valid with dgit fetch and dgit pull, only.
 .TP
 .BR --clean=git " | " -wg
 Use
-.BR "git clean -xdf"
+.B git clean -xdf
 to clean the working tree,
 rather than running the package's rules clean target.
 
@@ -548,7 +548,7 @@ See --clean=git[-ff],always, below.
 .TP
 .BR --clean=git-ff " | " -wgf
 Use
-.BR "git clean -xdff"
+.B git clean -xdff
 to clean the working tree.
 Like
 git clean -xdf
@@ -566,7 +566,7 @@ Avoids running rules clean,
 and can avoid needing the build-dependencies.
 
 With
-.BR ,ignores
+.B ,ignores
 or
 .BR -wci ,
 untracked files covered by .gitignore are tolerated,
@@ -599,7 +599,7 @@ or
 .BR -wdd ,
 the build-dependencies are not checked
 (due to passing
-.BR -d
+.B -d
 to dpkg-buildpackage),
 which violates policy, but may work in practice.
 
@@ -635,7 +635,7 @@ refuse to push.  It may (for Debian, will) be unable to 
access the git
 history for any packages which have been newly pushed and have not yet
 been published.
 .TP
-.BR --include-dirty
+.B --include-dirty
 Do not complain if the working tree does not match your git HEAD,
 and when building,
 include the changes from your working tree.
@@ -643,7 +643,7 @@ This can be useful with build, if you plan to commit later. 
 (dgit
 push will still ensure that the .dsc you upload and the git tree
 you push are identical, so this option won't make broken pushes.)
 .TP
-.BR --ignore-dirty
+.B --ignore-dirty
 Deprecated alias for --include-dirty.
 .TP
 .BR --overwrite [=\fIprevious-version\fR]
@@ -685,7 +685,7 @@ changes, even with
 unless someone committed to git a finalised changelog
 entry, and then made later changes to that version.)
 If
-.IR previous-version
+.I previous-version
 is specified, it ought to be the version currently in the archive.
 
 dgit push --overwrite
@@ -717,7 +717,7 @@ someone should make a suitable dgit push
 to update the contents of dgit-repos
 to a version without the controversial changes.
 .TP
-.BR --no-chase-dsc-distro
+.B --no-chase-dsc-distro
 Tells dgit not to look online
 for additional git repositories
 containing information about a particular .dsc being imported.
@@ -780,7 +780,7 @@ The meanings of
 .IR something s
 understood in the context of Debian are discussed below:
 .TP
-.BR --deliberately-not-fast-forward
+.B --deliberately-not-fast-forward
 Declare that you are deliberately rewinding history.  When pushing to
 Debian, use this when you are making a renewed upload of an entirely
 new source package whose previous version was not accepted for release
@@ -797,7 +797,7 @@ and
 should be needed;
 --overwrite is usually better.
 .TP
-.BR --deliberately-include-questionable-history
+.B --deliberately-include-questionable-history
 Declare that you are deliberately including, in the git history of
 your current push, history which contains a previously-submitted
 version of this package which was not approved (or has not yet been
@@ -806,12 +806,12 @@ option after verifying that: none of the 
rejected-from-NEW (or
 never-accepted) versions in the git history of your current push, were
 rejected by ftpmaster for copyright or redistributability reasons.
 .TP
-.BR --deliberately-fresh-repo
+.B --deliberately-fresh-repo
 Declare that you are deliberately rewinding history and want to
 throw away the existing repo.  Not relevant when pushing to Debian,
 as the Debian server will do this automatically when necessary.
 .TP
-.BR --quilt=linear
+.B 

Bug#918569: Could not find 'activerecord' (~> 4.2) - did find: [activerecord-5.2.0]

[Georg Faerber]

Hi Pirate,

On 19-01-07 19:13:39, Pirate Praveen wrote:
> Currently rails 5.2 is in unstable and schleuder autopkgtest is
> failing (it is causing a delay in rails 5 migration to buster). Please
> fix it so we can get rails 5 into buster.

I'm back from traveling, and just uploaded 3.3.0-7 containing a fix.
Sorry that this took so long.. :(

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#921305: zfs-dkms: fails to upgrade from stretch

[Andreas Beckmann]

Package: zfs-dkms
Version: 0.7.12-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stretch'.
It installed fine in 'stretch', then the upgrade to 'buster' fails.

The problem is the order chosen by apt to process the packages.

* the new spl-dkms gets configured and builds modules for the stretch kernel
* the new zfs-dkms gets unpacked
* the buster kernel headers get unpacked
* the new zfs-dkms gets configured and attempts to build a module for the
  buster kernel
* this fails due to a missing spl-dkms build for the buster kernel
* the buster kernel headers get configured

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

[...]
 Setting up spl-dkms (0.7.12-1) ...
  Loading new spl-0.7.12 DKMS files...
  It is likely that 4.13.2 belongs to a chroot's host
  Building for 4.9.0-8-amd64
  Building initial module for 4.9.0-8-amd64
  Done.
[...]
  DKMS: install completed.
[...]
  Preparing to unpack .../zfs-dkms_0.7.12-2_all.deb ...
  
   Uninstall Beginning 
  Module:  zfs
  Version: 0.6.5.9
  Kernel:  4.9.0-8-amd64 (x86_64)
  -
  
  Status: Before uninstall, this module version was ACTIVE on this kernel.
[...]
  DKMS: uninstall completed.
  
  --
  Deleting module version: 0.6.5.9
  completely from the DKMS tree.
  --
  Done.
  Unpacking zfs-dkms (0.7.12-2) over (0.6.5.9-5) ...
[...]
  Selecting previously unselected package linux-compiler-gcc-8-x86.
  Preparing to unpack .../4-linux-compiler-gcc-8-x86_4.19.12-1_amd64.deb ...
  Unpacking linux-compiler-gcc-8-x86 (4.19.12-1) ...
  Selecting previously unselected package linux-headers-4.19.0-1-common.
  Preparing to unpack .../5-linux-headers-4.19.0-1-common_4.19.12-1_all.deb ...
  Unpacking linux-headers-4.19.0-1-common (4.19.12-1) ...
  Selecting previously unselected package linux-kbuild-4.19.
  Preparing to unpack .../6-linux-kbuild-4.19_4.19.12-1_amd64.deb ...
  Unpacking linux-kbuild-4.19 (4.19.12-1) ...
  Selecting previously unselected package linux-headers-4.19.0-1-amd64.
  Preparing to unpack .../7-linux-headers-4.19.0-1-amd64_4.19.12-1_amd64.deb ...
  Unpacking linux-headers-4.19.0-1-amd64 (4.19.12-1) ...
  Preparing to unpack .../8-linux-headers-amd64_4.19+101_amd64.deb ...
  Unpacking linux-headers-amd64 (4.19+101) over (4.9+80+deb9u6) ...
[...]
  Setting up linux-headers-4.19.0-1-common (4.19.12-1) ...
  Setting up libcomerr2:amd64 (1.44.5-1) ...
  Setting up zfs-dkms (0.7.12-2) ...
  Loading new zfs-0.7.12 DKMS files...
  It is likely that 4.13.2 belongs to a chroot's host
  Building for 4.19.0-1-amd64 and 4.9.0-8-amd64
  Building initial module for 4.19.0-1-amd64
  configure: error: 
*** Please make sure the kmod spl devel  package for your
*** distribution is installed then try again.  If that fails you
*** can specify the location of the spl objects with the
*** '--with-spl-obj=PATH' option.  Failed to find spl_config.h in
*** any of the following:
/usr/src/spl-0.7.12/4.19.0-1-amd64
/usr/src/spl-0.7.12
  Error! Bad return status for module build on kernel: 4.19.0-1-amd64 (x86_64)
  Consult /var/lib/dkms/zfs/0.7.12/build/make.log for more information.
  dpkg: error processing package zfs-dkms (--configure):
   installed zfs-dkms package post-installation script subprocess returned 
error exit status 10
[...]
  Setting up linux-headers-4.19.0-1-amd64 (4.19.12-1) ...
[...]


cheers,

Andreas


zfs-dkms_0.7.12-2.log.gz
Description: application/gzip

Bug#894294: Comment in the source of unmkinitramfs is ambiguous

[Ben Hutchings]

On Wed, 28 Mar 2018 21:18:54 +0900 Osamu Aoki  wrote:
> Source: initramfs-tools
> Version: 0.130
> Severity: wishlist
> 
> The line 56-59 of unmkinitramfs goes:
> 
>  # There may be a prepended uncompressed archive.  cpio
>  # won't tell us the true size of this so we have to
>  # parse the headers and padding ourselves.  This is
>  # very roughly based on linux/lib/earlycpio.c
> 
> The claim "cpio won't tell us the true size of this ..." doesn't have
> any explicit reference to substantiate its claim while my uneducated
> simple use of cpio telling me the true file size without the tailing
> garbage ;-)
>
> For example:
> 
> $ cpio -i -t /dev/null
> 48 blocks
> 
> So the uncompressed cpio file size is 512*48 BYTES.  With some simple
> experimentation with cpio, I realize cpio always create file size in
> multiple of 512 bytes and it treat 512 bytes as a block.  I can extract
> tailing basic initrd image file as subinitrd.img with:
> 
> $ dd if=/initrd.img of=subinitrd.img bs=512 skip=48
> 
> At least on my recent Debian system, this subinitrd.img is a nicely
> extracted gzipped cpio archive.
[...]

This code started life in bug #717805 and you can see there that
various people found different behaviour.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.



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

Bug#921287: ITP: battery -- cross-platform, normalized battery information library

[Antoine Beaupré]

On 2019-02-04 00:24:40, Henrique de Moraes Holschuh wrote:
> On Sun, 03 Feb 2019, Antoine Beaupré wrote:
>> Package: wnpp
>> Severity: wishlist
>> Owner: Antoine Beaupré 
>> 
>> * Package name: battery
>
> Please don't sit on a generic name.  Can it be named something else?
> golang-battery?  battery-info-go?

You're right, I renamed the ITP. that's a false flag because of the way
dh-make-golang behaves when it finds something that it think should end
up in /usr/bin...

a.

-- 
Conformity-the natural instinct to passively yield to that vague something
recognized as authority.
- Mark Twain

Bug#911425: fixed in libvma 8.8.1-1

[Paul Wise]

Control: reopen -1

On Mon, 2019-02-04 at 02:10 +, Tzafrir Cohen wrote:

>  libvma (8.8.1-1) unstable; urgency=medium
>  .
>* Initial release. (Closes: #911425)

You have closed the wrong bug report.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#921304: ITP: node-solid-oidc-op -- OpenID Connect Provider for Node.js

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-solid-oidc-op
  Version : 0.4.2
  Upstream Author : Anvil Research, Inc. 
* URL : https://github.com/solid/oidc-op
* License : Expat
  Programming Lang: JavaScript
  Description : OpenID Connect Provider for Node.js

 This library aims to implement
 a full-featured OpenID Connect Provider for Node.js.
 It is not intended to be used directly by most developers,
 but rather via a complete self-contained server
 such as Anvil Connect.
 Some applications require an embedded identity provider,
 such as entertainment or IoT appliances.
 This package can be used directly in these cases.
 .
 The module should make available an OIDCProvider class
 which can be instantiated multiple times
 to support multitenancy use cases.
 It should also have a method
 that provides a mountable router or app
 for widely used frameworks like Express.
 .
 Node.js is an event-based server-side JavaScript engine.

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxXpKYACgkQLHwxRsGg
ASHPFhAAnQRUad0wtKEQJGKbbkRd/kvjR0mGlbf77L3cW5MZol6rV8oD31BG9YMR
iaR14YxqMpL++iMUU999kAiQ541tachEaODFH/EX6DYHcR88OEkK539QHcmD4CWx
H+xMKklgAPyIadxHq3ZT09pjMcubawy2sfVBNQchBM8CNz9fN/UvsVcY165K2cLj
Boy69jBf+ujfmnu9wZO7go2dO1dkH5mBkK0iokfjriciIiJZZorWPWMJ+ZImv616
qkF5xDkkbgz3+nkIpfhluLI6o8sglgx0WCv9fFEKD26PGGKp1STXUfhkqxqJ2oHZ
qVaIcR9Vygt7B9Zi2a2CnRqphJ64F9nxNtwUAkqzkZRXkNPMxi8xeAuhOPwPty+v
61FyQu6z2w1WT919P23y3dIkzOgznYPZv8819cPZ4IsyW7JKQEpjpEAjM8ixvNVM
6XWc3SJNcOiyRuTUN2+KIEcbWg1uKioUYjtRvs0l3Xs2ieegZHmd5tVyZYxU3463
RRUKBVG6wOKyiuZqltAdh6usGTQNe/K86gjXjk1O/Zv4fkPxT33tw1HWR+a0FpDA
hS0oqzBTo0iN8N0i6rM2+M0wNbT4yLyTIYtX3RnicthKfbTBvG3V1TP1LsHum294
5NAvp5NUyXEWygQ0A0OMtJxeGHdElw1Yc2p17zlRw1AH2BupBj8=
=dNAJ
-END PGP SIGNATURE-

Bug#877391: Please add apparmor profile

[Michael Gilbert]

control: tag -1 moreinfo, help

On Sat, Nov 11, 2017 at 4:05 PM Michael Gilbert wrote:
> I also noticed that a similar file is already in apparmor-profiles.
> Is that not sufficient?

It looks like apparmor will no longer provide a chromium profile with
buster.  I'm not planning to look into this myself, but I would accept
a well tested patch.

Best wishes,
Mike

Bug#921287: ITP: battery -- cross-platform, normalized battery information library

[Henrique de Moraes Holschuh]

On Sun, 03 Feb 2019, Antoine Beaupré wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Antoine Beaupré 
> 
> * Package name: battery

Please don't sit on a generic name.  Can it be named something else?
golang-battery?  battery-info-go?

-- 
  Henrique Holschuh

Bug#918385: The name org.freedesktop.Notifications was not provided by any .service files

[Michael Gilbert]

control: reassign -1 src:notification-daemon

On Sat, Jan 5, 2019 at 12:42 PM Dan Jacobson wrote:
> ERROR:object_proxy.cc(621)] Failed to call method: 
> org.freedesktop.Notifications.GetCapabilities: object_path= 
> /org/freedesktop/Notifications: org.freedesktop.DBus.Error.ServiceUnknown: 
> The name org.freedesktop.Notifications was not provided by any .service files
>
> Installing the Suggested notification-daemon does not fix it.

The notification-daemon package itself does not provide a systemd
service file.  I'm not sure how notifications are intended to work in
gnome since I don't use it, but it seems like either the service file
or a dependency may be missing.

Other providers of notification-daemon like dunst, xfce4-notifyd, and
many others do include a notifications service file.   You could
choose one of those instead.

Best wishes,
Mike

Bug#909643: closed by Ben Hutchings (Re: doing a dist-upgrade from debian7 to debian8 ended with a non bootable system)

[Stephane Tranchemer]

Hi,
You are right Ben, this was the culprit.

The bottom line is, in a previous version of the debian distribution the
busybox package was called "busybox-cvs-static".

But at a time it just gone to "busybox-static", so when doing the normal
procedure of
apt-update
apt-upgrade
apt-distupgrade

it is not replaced by the newer version...

Quite a nasty pitfall.

Thanks for your time.


> The screenshot shows:
>
> "busybox 20040623-1"
>
> You have an ancient version of busybox installed and you must upgrade
> it.
>
> Ben.
>
> --
> Ben Hutchings
> Horngren's Observation:
>   Among economists, the real world is often a special case.
>
>
>

Bug#921303: ITP: node-trust-webcrypto -- WebCrypto API for Node.js

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-trust-webcrypto
  Version : 0.9.2
  Upstream Author : 2016, Anvil Research, Inc.
* URL : https://github.com/anvilresearch/webcrypto
* License : Expat
  Programming Lang: JavaScript
  Description : WebCrypto API for Node.js

 W3C's Web Cryptography API,
 which defines a standard interface
 for performing cryptographic operations in JavaScript,
 such as key generation, hashing, signing, and encryption.
 This package implements the API for Node.js,
 in order to support universal crypto-dependent code
 required by protocols such as JOSE and OpenID Connect.
 .
 JOSE is a framework intended to provide a method
 to securely transfer claims (such as authorization information)
 between parties, e.g. in systems involving OAuth 2.0.
 .
 Connect (OIDC) is an authentication layer on top of OAuth 2.0,
 an authorization framework.
 .
 Node.js is an event-based server-side JavaScript engine.

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxXmE4ACgkQLHwxRsGg
ASFN3BAAkfY9hD+JORYMQ/rUUhdSKz+Ob6D1GOWnLoVnLoNIYKM29qR0AvoRhg2d
y53+ZDj7z0/UUpfJSbq0E/JeuLqhWxoDnntauODFvkz3p/9pxSPvcTZAOHXunNUR
6pS/1bebOuPfu2WkcIra58+larBaReuMqyo9Xn3kA6VWN4dErsXWCEKB8i9XeIKc
gjbm0lfxnVbS+m7mWDmna0Nzb/yHSNPeVZsslQu/5jLYgvt4s/LOLVO6rA1+glJ2
i1Atp2NWUqSlBzEtCbLUzCTJ6UhhUc6XC/29Bmkqqm/uhFrP/DZgNFHCFE5JwiCF
0lkPJ5dp2bX0NCSaFmyAaQa6MQprAC9wiwjreAaXwKCpS16ECGyCt1avZcf3nIsu
N9Nkzx4KDu/e00TlYxbWCREQZJnrsFhUB/zISLTA10FHDdXbIg43P985Z4/PYDsI
IXythE6cSnIvaLD+7ykBVFdRyET15z9c5M69W2sba7GC7D+FhxaZDtEY/Od4KdzG
wjMV6Z9cgcXaCdEB4t1cgm3lBwFtlUNW6oB9XmQ8+vAYPdOb8W6ZivzFQerwmWRX
hzTNW4T02oExAMBYidnhqF5M4z4+4ayQ2ss7/sDRlnjRs1FhaVJgg+2rkYiyyTdq
fOJtPKi8Ynr94ci3gbHST1WaabVVcavBUyiebqzqozLW1Izorr8=
=McjZ
-END PGP SIGNATURE-

Bug#914036: config-package-dev: scripts directly access internal dpkg database

[Geoffrey Thomas]

On Sun, 18 Nov 2018, Guillem Jover wrote:


Source: config-package-dev
Source-Version: 5.5
Severity: important
User: debian-d...@lists.debian.org
Usertags: dpkg-db-access-blocker

Hi!

This package contain scripts that directly access the dpkg internal
database [S], instead of using the correct public interface
«dpkg --verify» (note that it currently does not return an error exit
code when it finds modified files, that will be fixed in 1.19.3, but
you can always just check the output).

 [S] check-files.mk, dh_configpackage


Both check-files.mk and dh_configpackage use dpkg-query --control-path 
$package md5sums, and only fall back to /var/lib/dpkg/info when that 
option doesn't exit. Is that enough?


(I can drop the fallback if you'd like - we wanted to support backports to 
LTSes but that code was written in 2011 so any current supported release 
certainly has --control-path. Relatedly, we could probably switch to 
--control-show at this point too if you'd like, but see also 
https://bugs.debian.org/735021 .)


I suppose we could use dpkg --verify, which would in theory simplify 
the code because (if I'm testing it right) it handles conffiles and 
non-conffiles just the same, and so we don't need a special case for 
dpkg-query -W'${Conffiles}'. But there are two downsides to it:


- It's less efficient, since it verifies all files in the package instead 
of just the one we want to check.


- As far as I can tell, it doesn't distinguish "This file has not been 
modified" from "I have no md5sums for this file". It's very rare to see a 
package with a missing or incomplete md5sums control file these days, but 
we do handle that case currently (we print an error if it's incomplete, 
and a warning if the package has no md5sums at all) and I'd like to keep 
handling it.


Do you think you can extend the --verify interface to support querying an 
individual file by name, and print an error if the file could not be 
verified?


If you can do a dpkg --verify-file (where dpkg figures out the package 
name, and prints an error if the file is unknown or the owning package 
doesn't provide md5sums) then I can skip most of the complexity in what 
I'm doing and just call that in newer versions of dpkg. :) I could also 
use a dpkg --verify "$package" --verify-file "$file", or something.


--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.com

Bug#921181: pescetti: recommends unavailable package dds

[Gabriele Stilli]

Il 04/02/19 01:12, Thorsten Alteholz ha scritto:

> according to the tracker [1] the package is still available in 
> version 2.9.0-6. Why do you think it is gone?

The binary package "dds", on which pescetti depends, has gone since
version 2.9.0-1; the source package "dds" only features libdds{0,-dev}.

Regards,
Gabriele

Bug#919475: xterm: No resize larger than display size?

[Thomas Dickey]

On Thu, Jan 17, 2019 at 02:56:20PM +0100, Jan-Benedict Glaw wrote:
> On Wed, 2019-01-16 20:58:16 -0500, Thomas Dickey  wrote:
> > On Wed, Jan 16, 2019 at 01:10:24PM +0100, Jan-Benedict Glaw wrote:
> > > Package: xterm
> > > Version: 342-1
> […]
> > > I was used to resize the uxterm window quite larger than the actual
> > > root window size (and move the window to see parts of it), which may
> > > be useful for stuff presenting quite long lines. This used to work at
> > > least in version 327-2, and didn't work in 338-1 nor current 342-1.
> > > 
> > >   Bisecting it down, it seems this bug was introduced with the import
> > > of 334. Though I didn't find an obvious entry in XTerm's changelog.
> > 
> > How did you move it?  Perhaps related to this, from #336:
> > 
> > revise omitTranslation resource, e.g., splitting “default” into several
> > more useful categories
> 
> I'm a WindowMaker user, so my move and resize works like this:

thanks - I can reproduce the problem.  It was introduced by this item in #334:

fix repainting, e.g., on resize, when double-buffering is used with Xft
(patch by Daniel Colascione).

That change eliminated a check for zIconBeep before handling struct-notify.

There were other things changed, whose relevance to double-buffering is more
apparent.  Perhaps just ifdef'ing the check (so it's unavailable if double-
buffering isn't configured) will be enough.  Since it's an experimental
feature, it's not part of the Debian package.

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


signature.asc
Description: Digital signature

Bug#921205: socket bind() to port 25 for address (any IPv6) failed: Address already in use: daemon abandoned

[積丹尼 Dan Jacobson]

severity 921205 important
thanks

The user is getting daily warning emails, thus important.

Here we observe the deamon being started, but no evidence of it ever
being stopped.

1. Please ensure the deamon being stopped is also logged! Thank you.

Anyway, every day I poweroff, so it is indeed stopped, but never logged.

Anyway, you can see the week when the problem started... in the middle of
January.

The problem surely simply is: you didn't check if the deamon really got
stopped when doing the prerm scripts, I bet!

No, there is nothing else certainly trying to get port 25 during
upgrades. Else it would have tried at boot.

# zgrep daemon *
mainlog:2019-02-04 08:45:57 exim 4.92-RC5 daemon started: pid=911, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.1:2019-02-03 16:08:55 exim 4.92-RC4 daemon started: pid=850, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.1:2019-02-03 16:58:04 socket bind() to port 25 for address (any IPv6) 
failed: Address already in use: daemon abandoned
mainlog.2.gz:2019-01-31 06:19:56 exim 4.92-RC4 daemon started: pid=916, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.3.gz:2019-01-30 06:44:45 exim 4.92-RC4 daemon started: pid=907, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.4.gz:2019-01-29 06:30:45 exim 4.92-RC4 daemon started: pid=919, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.4.gz:2019-01-29 21:11:45 exim 4.92-RC4 daemon started: pid=868, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.5.gz:2019-01-28 08:26:03 exim 4.92-RC4 daemon started: pid=858, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.5.gz:2019-01-28 09:27:08 socket bind() to port 25 for address (any 
IPv6) failed: Address already in use: daemon abandoned
mainlog.5.gz:2019-01-28 19:46:25 exim 4.92-RC4 daemon started: pid=880, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.6.gz:2019-01-27 22:30:06 exim 4.92-RC4 daemon started: pid=895, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.7.gz:2019-01-17 06:40:15 exim 4.92-RC4 daemon started: pid=903, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.8.gz:2019-01-16 08:27:59 exim 4.92-RC4 daemon started: pid=941, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.8.gz:2019-01-16 18:41:14 exim 4.92-RC4 daemon started: pid=913, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
mainlog.9.gz:2019-01-15 19:18:06 exim 4.92-RC4 daemon started: pid=944, -q30m, 
listening for SMTP on port 25 (IPv6 and IPv4)
paniclog:2019-02-03 16:58:04 socket bind() to port 25 for address (any IPv6) 
failed: Address already in use: daemon abandoned
# ls -og
total 56
-rw-r- 1  748 02-04 08:57 mainlog
-rw-r- 1 7779 02-03 23:38 mainlog.1
-rw-r- 1  384 01-11 00:09 mainlog.10.gz
-rw-r- 1  826 02-03 16:08 mainlog.2.gz
-rw-r- 1 1290 01-30 13:44 mainlog.3.gz
-rw-r- 1 1028 01-29 23:41 mainlog.4.gz
-rw-r- 1 1024 01-28 23:46 mainlog.5.gz
-rw-r- 1  406 01-28 00:00 mainlog.6.gz
-rw-r- 1  915 01-17 12:40 mainlog.7.gz
-rw-r- 1 1893 01-16 23:41 mainlog.8.gz
-rw-r- 1  750 01-15 23:48 mainlog.9.gz
-rw-r- 1  117 02-03 16:58 paniclog
-rw-r- 10 2017-03-23  rejectlog
-rw-r- 1  131 2017-03-22  rejectlog.1

Bug#919135: ERROR:context_group.cc(381)] ContextResult::kFatalFailure: too few texture image units supported (0, should be 8).

[Michael Gilbert]

control: severity -1 minor
control: forwarded -1 http://crbug.com/822418

On Sat, Jan 12, 2019 at 7:57 PM Dan Jacobson wrote:
> [5799:5799:0113/084128.701923:ERROR:context_group.cc(381)] 
> ContextResult::kFatalFailure: too few texture image units supported (0, 
> should be 8).
[...]
> Doesn't happen with a fresh profile though.

kFatalFailure means that there chromium at one point was able to
communicate with your GPU, but then lost it.  You may have a setting
in your profile that is causing this, or maybe too many tabs open.  It
could be many things, could you try to identify specifically what
causes it?

Best wishes,
Mike

Bug#921302: ITP: silver-platter -- automatic merge proposal creator

[Jelmer Vernooij]

Package: wnpp
Severity: wishlist
Owner: Jelmer Vernooij 

* Package name: silver-platter
  Version : 0.1
  Upstream Author : Jelmer Vernooij 
* URL : https://jelmer.uk/code/silver-platter
* License : GPL
  Programming Lang: Python
  Description : automatic merge proposal creator

Silver-Platter makes it possible to contribute automatable changes to source
code in a version control system, either by directly pushing changes or
creating merge proposals.

Bug#921181: pescetti: recommends unavailable package dds

[Thorsten Alteholz]

Hi Gabriele,

On Sat, 2 Feb 2019, Gabriele Stilli wrote:

pescetti recommends dds which isn't available anymore, at least in
buster and sid.


according to the tracker [1] the package is still available in version 
2.9.0-6. Why do you think it is gone?


Best regards
 Thorsten

[1] https://tracker.debian.org/pkg/dds

Bug#917740: not about CHANGES

[Yaroslav Halchenko]

tags 917740 +unreproducible +moreinfo
severity 917740 normal
thanks

Rebuilt package in current sid pbuilder env - no failing test.  So my
fear is that the issue is somehow specific to that environment where it
failed or something has changed since then.   Lowering severity.  I will
upload fresh upstream shortly - so we will see if reproduces then

On Sun, 03 Feb 2019, Yaroslav Halchenko wrote:

> CHANGES error is benign , will clarify upstream 
> https://github.com/nipy/nipype/issues/2873

> the actual issue is

> > raise TypeError("expected str, bytes or os.PathLike object, 
> > "
> > >   "not " + path_type.__name__)
> > E   TypeError: expected str, bytes or os.PathLike object, not 
> > unicode

> or in full:

> > === FAILURES 
> > ===
> > _ test_split_and_merge 
> > _

> > tmpdir = local('/tmp/pytest-of-user42/pytest-0/test_split_and_merge0')

> > def test_split_and_merge(tmpdir):
> > import numpy as np
> > import nibabel as nb
> > import os.path as op
> > import os

> > from nipype.algorithms.misc import split_rois, merge_rois

> > in_mask = example_data('tpms_msk.nii.gz')
> > dwfile = tmpdir.join('dwi.nii.gz').strpath
> > mskdata = nb.load(in_mask, mmap=NUMPY_MMAP).get_data()
> > aff = nb.load(in_mask, mmap=NUMPY_MMAP).affine

> > dwshape = (mskdata.shape[0], mskdata.shape[1], mskdata.shape[2], 6)
> > dwdata = np.random.normal(size=dwshape)
> > tmpdir.chdir()
> > nb.Nifti1Image(dwdata.astype(np.float32), aff, 
> > None).to_filename(dwfile)

> > >   resdw, resmsk, resid = split_rois(dwfile, in_mask, roishape=(20, 
> > > 20, 2))

> > /<>/nipype/algorithms/tests/test_splitmerge.py:26: 
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _ 
> > /<>/nipype/algorithms/misc.py:1318: in split_rois
> > np.savez(iname, (nzels[0][first:last], ))
> > /usr/lib/python2.7/dist-packages/numpy/lib/npyio.py:619: in savez
> > _savez(file, args, kwds, False)
> > /usr/lib/python2.7/dist-packages/numpy/lib/npyio.py:700: in _savez
> > file = os_fspath(file)
> > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> > _ _ 

> > path = 
> > '/tmp/pytest-of-user42/pytest-0/test_split_and_merge0/roi00_idx'

> > def os_fspath(path):
> > """Return the path representation of a path-like object.
> > If str or bytes is passed in, it is returned unchanged. Otherwise 
> > the
> > os.PathLike interface is used to get the path representation. If the
> > path representation is not str or bytes, TypeError is raised. If the
> > provided path is not str, bytes, or os.PathLike, TypeError is 
> > raised.
> > """
> > if isinstance(path, (str, bytes)):
> > return path

> > # Work from the object's type to match method resolution of other 
> > magic
> > # methods.
> > path_type = type(path)
> > try:
> > path_repr = path_type.__fspath__(path)
> > except AttributeError:
> > if hasattr(path_type, '__fspath__'):
> > raise
> > elif PurePath is not None and issubclass(path_type, PurePath):
> > return _PurePath__fspath__(path)
> > else:
> > raise TypeError("expected str, bytes or os.PathLike object, 
> > "
> > >   "not " + path_type.__name__)
> > E   TypeError: expected str, bytes or os.PathLike object, not 
> > unicode

> > /usr/lib/python2.7/dist-packages/numpy/compat/py3k.py:237: TypeError
-- 
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

Bug#919413: here are the 9 bugs I created

[Paolo Greppi]

BTW, I retried uhd and actually it does not fail.

So I created 9 new bugs:
hwloc: https://bugs.debian.org/921293
fltk1.3: https://bugs.debian.org/921294
wcslib: https://bugs.debian.org/921295
ccfits: https://bugs.debian.org/921296
qevercloud: https://bugs.debian.org/921297
libstxxl: https://bugs.debian.org/921298
caffe: https://bugs.debian.org/921299
frobby: https://bugs.debian.org/921300
starpu: https://bugs.debian.org/921301

Paolo

Bug#921301: starpu: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: starpu
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
mv: cannot stat 'latex/refman.pdf': No such file or directory

Paolo

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

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

Bug#920775: RFS: python-css-parser/1.0.4-1 [ITP]

[Nicholas D Steeves]

Hi Chris,

No one has responded to this RFS since it was filed 12 Jan.  Would you
please sponsor and review this NEW package if late 2018 firmware
support for various ebook readers is important for Buster?  It is a
required dep for updating Calibre.  Links follow below:

On Mon, Jan 28, 2019 at 06:24:42PM -0700, Nicholas D Steeves wrote:
>
> To access further information about this package, please visit the following 
> URL:
> 
>   https://mentors.debian.net/package/python-css-parser
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/p/python-css-parser/python-css-parser_1.0.4-1.dsc
> 
> Alternatively, clone this repository:
> 
>   git clone https://salsa.debian.org/python-team/modules/python-css-parser.git
> 
> 
> Thank you,
> Nicholas


signature.asc
Description: PGP signature

Bug#920775: RFS: python-css-parser/1.0.4-1 [ITP]

[Nicholas D Steeves]

On Mon, Jan 28, 2019 at 06:24:42PM -0700, Nicholas D Steeves wrote:
> Package: sponsorship-requests
> Severity: normal
> Justification: new required dep for Calibre
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "python-css-parser".  It
> will be maintained on the Debian Python Modules Team.  I hope that it
> can clear NEW before 12 Feb, because the Christmas Kobo firmware
> update requires a newer Calibre, and a newer Calibre requires
> python-css-parser.
> 
> Package name: python-css-parser
> Version : 1.0.4-1
> Upstream Author : Kovid Goyal (maintainer of fork), Christof Hoeke (orig)
> URL : https://github.com/ebook-utils/css-parser
> License : LGPL-3.0 and Apache 2.0
> Section : python

Correction:  I'm not sure why I wrote LGPL-3.0 and Apache 2.0 under
License...it appears I was confused when filing this RFS, because the
debian/copyright file was correct.  The License field for this bug
should read as follows:

License: as a whole, LGPL-3+, but the package contains
 LGPL 2.1+, LGPL-3+ dual-licensed CC-BY-3.0,
 and GPL-3+

I've updated the copyright file with comments explaining how LGPL-3+
was established--namely upstream website.  I did not note that summing
LGPL-2.1+ Files: * with LGPL-3+ src/css_parser/encutils/* results in
LGPL-3+ as a project license.


Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#917740: not about CHANGES

[Yaroslav Halchenko]

CHANGES error is benign , will clarify upstream 
https://github.com/nipy/nipype/issues/2873

the actual issue is

> raise TypeError("expected str, bytes or os.PathLike object, "
> >   "not " + path_type.__name__)
> E   TypeError: expected str, bytes or os.PathLike object, not 
> unicode

or in full:

> === FAILURES 
> ===
> _ test_split_and_merge 
> _
> 
> tmpdir = local('/tmp/pytest-of-user42/pytest-0/test_split_and_merge0')
> 
> def test_split_and_merge(tmpdir):
> import numpy as np
> import nibabel as nb
> import os.path as op
> import os
> 
> from nipype.algorithms.misc import split_rois, merge_rois
> 
> in_mask = example_data('tpms_msk.nii.gz')
> dwfile = tmpdir.join('dwi.nii.gz').strpath
> mskdata = nb.load(in_mask, mmap=NUMPY_MMAP).get_data()
> aff = nb.load(in_mask, mmap=NUMPY_MMAP).affine
> 
> dwshape = (mskdata.shape[0], mskdata.shape[1], mskdata.shape[2], 6)
> dwdata = np.random.normal(size=dwshape)
> tmpdir.chdir()
> nb.Nifti1Image(dwdata.astype(np.float32), aff, 
> None).to_filename(dwfile)
> 
> >   resdw, resmsk, resid = split_rois(dwfile, in_mask, roishape=(20, 20, 
> > 2))
> 
> /<>/nipype/algorithms/tests/test_splitmerge.py:26: 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> /<>/nipype/algorithms/misc.py:1318: in split_rois
> np.savez(iname, (nzels[0][first:last], ))
> /usr/lib/python2.7/dist-packages/numpy/lib/npyio.py:619: in savez
> _savez(file, args, kwds, False)
> /usr/lib/python2.7/dist-packages/numpy/lib/npyio.py:700: in _savez
> file = os_fspath(file)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> _ 
> 
> path = 
> '/tmp/pytest-of-user42/pytest-0/test_split_and_merge0/roi00_idx'
> 
> def os_fspath(path):
> """Return the path representation of a path-like object.
> If str or bytes is passed in, it is returned unchanged. Otherwise the
> os.PathLike interface is used to get the path representation. If the
> path representation is not str or bytes, TypeError is raised. If the
> provided path is not str, bytes, or os.PathLike, TypeError is raised.
> """
> if isinstance(path, (str, bytes)):
> return path
> 
> # Work from the object's type to match method resolution of other 
> magic
> # methods.
> path_type = type(path)
> try:
> path_repr = path_type.__fspath__(path)
> except AttributeError:
> if hasattr(path_type, '__fspath__'):
> raise
> elif PurePath is not None and issubclass(path_type, PurePath):
> return _PurePath__fspath__(path)
> else:
> raise TypeError("expected str, bytes or os.PathLike object, "
> >   "not " + path_type.__name__)
> E   TypeError: expected str, bytes or os.PathLike object, not 
> unicode
> 
> /usr/lib/python2.7/dist-packages/numpy/compat/py3k.py:237: TypeError


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

Bug#921300: frobby: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Package: frobby
Version: 0.9.0-5
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo

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

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

Versions of packages frobby depends on:
ii  libc6  2.28-5
ii  libgcc11:8.2.0-16
ii  libgmp10   2:6.1.2+dfsg-4
ii  libgmpxx4ldbl  2:6.1.2+dfsg-4
ii  libstdc++6 8.2.0-16

frobby recommends no packages.

frobby suggests no packages.

-- no debconf information

Bug#921299: caffe: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: caffe
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo

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

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

Bug#921298: libstxxl: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: libstxxl
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo


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

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

Bug#921297: qevercloud: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: qevercloud
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo

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

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

Bug#919413: ready for unstable

[Paolo Greppi]

I ran ratt, 31 of 729 packages genuinely FTBFS due to doxygen 1.8.15.
More details here:
https://salsa.debian.org/paolog-guest/doxygen/wikis/ratt-job-for-doxygen-1.8.15

All these failures are related to an issue with texlive-base 2018.20190126-1:
https://bugs.debian.org/920621
and ultimately due to the latex tabu extension:
https://github.com/tabu-fixed/tabu/issues/1
https://github.com/doxygen/doxygen/issues/6769

With the help of Hilmar Preuße I patched doxygen so that is builds, and
(almost always) generates tex files that are parseable by pdflatex from
texlive-base 2018.20190126-1.
This at the cost of producing ugly-looking PDFs, while we wait for a
properly fixed tabu.

With those fixes 20 of the failing packages above build fine.
toulbar2 now FTBFS due to new latex even without new doxygen.
We are left with 10 (in order of decreasing popcon):
hwloc   13658   
fltk1.3 12796   
uhd 1119
wcslib  577 
ccfits  526 
qevercloud  285 
libstxxl229 
caffe   171 
frobby  126 
starpu  11  

I will now file bugs with these 10 packages so that the maintainers are aware
of the issue.

The latest version of the package, ready for the upload to unstable, is here:
https://salsa.debian.org/paolog-guest/doxygen

Paolo

Bug#921296: ccfits: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: ccfits
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
make[2]: *** [Makefile:8: refman.pdf] Error 1

Paolo

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

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

Bug#921294: fltk1.3: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: fltk1.3
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
cp: cannot stat 'latex/refman.pdf': No such file or directory

Paolo

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

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

Bug#921195: mcabber: does not connect to Jabber via IPv6 (fails Etch release goal)

[Thorsten Glaser]

Andreas Metzler dixit:

>commu.teckids.org offers TLS 1.3, so I a suspect the TLS code is not up
>to date for TLS 1.3.

No, I can normally connect. mcabber is my primary client because it
works inside GNU screen. It just didn’t work at FOSDEM in the IPv6-only
network there (the FOSDEM-legacy had IPv4, but I didn’t test it, ssh to
another Debian sid box with v4+v6 was quicker).

bye,
//m.

Bug#921295: wcslib: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Source: wcslib
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found. popcon = 569

Paolo

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

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

Bug#921293: hwloc: FTBFS with upcoming doxygen 1.8.15

[Paolo Greppi]

Package: hwloc
Version: 1.11.12-1
Severity: serious

Dear Maintainer,

I tested your package against a draft package for doxygen 1.8.15:
https://bugs.debian.org/919413

and it FTBFS with this error:
! LaTeX Error: File `listofitems.sty' not found.

Paolo

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

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

Versions of packages hwloc depends on:
ii  libc6  2.28-5
ii  libcairo2  1.16.0-2
ii  libhwloc5  1.11.12-1
ii  libice62:1.0.9-2
ii  libsm6 2:1.2.2-1+b3
ii  libtinfo6  6.1+20181013-1
ii  libx11-6   2:1.6.7-1

hwloc recommends no packages.

hwloc suggests no packages.

-- no debconf information

Bug#921292: ITP: node-node-rsa -- RSA library for Node.js

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-node-rsa
  Version : 1.0.3
  Upstream Author : rzcoder 
* URL : https://github.com/rzcoder/node-rsa
* License : Expat
  Programming Lang: JavaScript
  Description : RSA library for Node.js

 This package provides an RSA library implementation in Node.js
 based on JSBN .
 .
 Node.js is an event-based server-side JavaScript engine.

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxXfoQACgkQLHwxRsGg
ASH7dw/9FfRjiwnc6FRGr/N4gahG3HV9SiBtFyVKR4j/ZUT+QXoO2xDCr2vztcFZ
Ls+2Zdtqb+294H2dc/IXN3+KmkscVPW4tg0Qp2/wMiE5WCUPk/Pvnyw15E11v01E
tJc/THlosnhqg5cPP8J4/ruLWqvPGggD5Tld1nR4XBlBWA18gCO3AQ6MurMS2tWl
UoyK6pSIy8FQQEMP0FUOl2TV9G1skVsmN4v2Qt5U4IAI04tpnTv4KABPMz/I0aCS
6wRSgyejiaG5ql6zJ928okOHWvp2X95TZq/al6gTuo6ci1RGlu6BpnvRmuRmTx8u
PeEkplRO2SueVFpyYS0vPnfLOah+OZVS/GbS41awxrVhg0uMe1ILkROcEwMdg1Iz
j08uR48RRL1DNhtQ3tAfD7MGV3S2p/v30y5p51pxCr7jNFZR75LgyUR3FECbQbPl
bfMC+4DBxjmfJU9LvwhamLtHybsZ8ULt6Kaqchl0Z7/ppFYXzmIxryCTnEbZA81h
1g+k0UOiV1qoCV4DkemB8hFNe23hRJxZRWBy05Psuj7tAuFmEH5ePxfJLHRG/J2K
WPkpsflOeoh2i4xH/3MH9S5MAQxTbnk5psu7vOgfkfT0vNLCru6nd/8rvs8tCb+I
11lZURPOUgZAD+1PLWerPFNaI0ECQ65ogRPx/m1109V5TO3iJmw=
=opVI
-END PGP SIGNATURE-

Bug#921291: openhft-chronicle-bytes: FTBFS on i386

[Andreas Beckmann]

Package: openhft-chronicle-bytes
Version: 1.16.25-1
Severity: serious
Justification: fails to build from source

Hi,

openhft-chronicle-bytes FTBFS in a i386 pbuilder chroot, while it builds
successfully in an amd64 pbuilder chroot.


Andreas


openhft-chronicle-bytes_1.16.25-1.log.gz
Description: application/gzip

Bug#909643: marked as done (installation-reports: doing a dist-upgrade from debian7 to debian8 ended with a non bootable system)

[ccmcphe]

UnsubscribeSent from my Samsung Galaxy smartphone.
 Original message From: Debian Bug Tracking System 
 Date: 2/3/19  4:15 PM  (GMT-05:00) To: Ben Hutchings 
 Subject: Bug#909643: marked as done 
(installation-reports: doing a dist-upgrade from debian7 to debian8 ended with 
a non bootable system) Your message dated Sun, 03 Feb 2019 22:10:14 +0100with 
message-id and 
subject line Re: doing a dist-upgrade from debian7 to debian8 ended with a non 
bootable systemhas caused the Debian Bug report #909643,regarding 
installation-reports: doing a dist-upgrade from debian7 to debian8 ended with a 
non bootable systemto be marked as done.This means that you claim that the 
problem has been dealt with.If this is not the case it is now your 
responsibility to reopen theBug report if necessary, and/or fix the problem 
forthwith.(NB: If you are a system administrator and have no idea what 
thismessage is talking about, this may indicate a serious mail 
systemmisconfiguration somewhere. Please contact 
owner@bugs.debian.orgimmediately.)-- 909643: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909643Debian Bug Tracking 
SystemContact ow...@bugs.debian.org with problems

Bug#920386: build_user configuration crashes with "uninitialized value $chroot_arch in scalar chomp"

[Johannes Schauer]

Control: reassign -1 schroot

On Thu, 24 Jan 2019 23:30:40 + James Clarke  wrote:
> On Thu, Jan 24, 2019 at 06:06:30PM -0500, Antoine Beaupre wrote:
> > Package: sbuild
> > Version: 0.78.0-2
> > Severity: normal
> >
> > I'm trying to setup sbuild so it builds under a different user by
> > default. The sbuild.conf(5) manpage says:
> >
> >BUILD_USER
> >   STRING type.  Username used for running dpkg-buildpackage. By 
> > default the
> >   user  running sbuild is used within the chroot as well but 
> > that might al‐
> >   low a process from within the chroot to break out of the  
> > chroot  by  at‐
> >   taching to a process running outside the chroot with eg. gdb 
> > and then be‐
> >   coming root inside the chroot through schroot and thus be 
> > able  to  leave
> >   the chroot.
> >
> >   build_user = ...;
> >
> > I'm assuming the example code there is a typo and should be really:
> >
> > $build_user = 'sbuild';
> >
> > ... so I add the above to my `.sbuildrc`. Then I try a build and it
> > fails early in the process:
> >
> > E: read_command failed to execute dpkg
> > Use of uninitialized value $chroot_arch in scalar chomp at 
> > /usr/share/perl5/Sbui
> > ld/Build.pm line 3024.
> >
> > The "sbuild" user exists in the chroot:
> >
> > $ schroot -c unstable-amd64-sbuild --directory / id sbuild
> > uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)
> >
> > I have tried to look at the line pointed at by the error message:
> >
> > chomp(my $chroot_arch = $self->get('Session')->read_command(
> > { COMMAND => ['dpkg', '--print-architecture'],
> >   USER => $self->get_conf('BUILD_USER'),
> >   PRIORITY => 0,
> >   DIR => '/' }));
> >
> > .. but to figure out what the problem is, you need to dig into
> > `read_command`, which is quite a rabbit hole. It calls
> > Chroot::read_command which calls pipe_command, which calls
> > pipe_command_internal, which calls exec_command, and *then* we hit the
> > schroot specific code with get_command_internal, and *finally*
> > _get_exec_argv, which shows the user is passed to the `schroot -u`
> > argument.
> >
> > When trying to reproduce the problem outside of sbuild, I therefore
> > do:
> >
> > $ schroot -c unstable-amd64-sbuild --directory / -u sbuild id
> > [schroot] password for sbuild:
> >
> > I think that's where the problem lies: stdin is probably closed which
> > makes the command fail. Even if it would be open, the process would
> > just hang asking for a password, which doesn't exist (set to '*' in
> > /etc/shadow).
> >
> > If I run schroot as root, that works however:
> >
> > $ sudo schroot -c unstable-amd64-sbuild --directory / -u sbuild id
> > uid=129(sbuild) gid=138(sbuild) groups=138(sbuild)
> >
> > For what that's worth, the caller is in the `sbuild` group:
> >
> > $ grep sbuild /etc/group
> > sbuild:x:138:anarcat
> >
> > The schroot has that configuration:
> >
> > [unstable-amd64-sbuild]
> > description=Debian unstable/amd64 autobuilder
> > groups=root,sbuild
> > root-groups=root,sbuild
> > profile=sbuild
> > type=directory
> > directory=/home/chroot/unstable-amd64-sbuild
> > union-type=overlay
> >
> > So in *theory* it should allow users in the sbuild group to run
> > commands without entering a password.
> >
> > Am I missing something?
> 
> Here's the discussion Antoine and I had on IRC about this:
> 
> [22:39:57]   has anyone ever made $build_user work in sbuild? here 
> it crashes with Use of uninitialized value $chroot_arch in scalar chomp at 
> /usr/share/perl5/Sbuild/Build.pm line 3024.
> [22:53:04]anarcat: sounds like your chroot doesn't have that user?
> [22:53:37]sorry, *host*
> [22:53:43]the user gets passed as schroot -u
> [22:54:01]that or a perms issue
> [22:54:27]or use pbuilder :P
> [23:05:04]   i'll file a bug :p
> [23:05:13]   jrtc27: sudo schroot -u sbuild works
> [23:05:19]   but not as a regular user
> [23:18:30]sure
> [23:18:44]but you're not running sbuild under sudo
> [23:19:25]so schroot is also run as you
> [23:20:30]$build_user follows the rules of schroot -u argument, 
> which is documented in its manpage under AUTHENTICATION
> [23:21:32]   ...
> [23:21:38]   so i need to enter the password of the sbuild user?
> [23:22:05]   this makes no sense to me - i can run schroot as root, 
> but not as the sbuild user??
> [23:22:31]agreed that it doesn't make much sense if you're in 
> root-users/groups
> [23:23:08]   there's also the problem that it doesn't "immediately 
> fail with permission denied", it crashes with some unrelated, random message
> [23:23:35]   anyways, enough for today, thanks for the feedback!
> [23:23:43]well, yeah, the error running the command should be 
> propagated up rather than the caller choking due to not getting output
> [23:23:56]   bug is #920386
> [23:24:02]so I guess two 

Bug#921290: gnunet-gtk: FTBFS with gnutls 3.6: 'GNUTLS_CRT_RAW' undeclared

[Andreas Beckmann]

Source: gnunet-gtk
Version: 0.11.0~pre66-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

gnunet-gtk/experimental recently started to FTBFS, this is probably
related to the upload of gnutls28 3.6.x to unstable. The previous
successful experimental builds happened with gnutls 3.5.19.

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -I../../ -I../../src/include 
-Wdate-time -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/gtk-3.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/inclu
de/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 
-I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/libdrm 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/includ
e/pango-1.0 -I/usr/include/fribidi -I/usr/include/atk-1.0 -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/
include/blkid -I/usr/include/uuid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread -I/usr/include/gtk-3.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1
.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 
-I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/libdrm 
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1
.0 -I/usr/include/fribidi -I/usr/include/atk-1.0 -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/b
lkid -I/usr/include/uuid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -pthread 
-I/usr/include/libgladeui-2.0 -I/usr/include/gtk-3.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include 
-I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo 
-I/usr/include/libdrm -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -
I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libm
ount -I/usr/include/blkid -I/usr/include/uuid -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libxml2 
-fno-strict-aliasing -Wall -g -O2 "-fdebug-prefix-map=/build/gnunet-gtk-0.1
1.0~pre66=." -fstack-protector-strong -Wformat -Werror=format-security -pthread 
-I/usr/include/gtk-3.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/d
bus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0 
-I/usr/include/cairo -I/usr/include/libdrm -I/usr/include/pango-1.0 
-I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/fribidi -I/usr
/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid -I/usr/
include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -c 
plugin_gtk_namestore_box.c  -fPIC -DPIC -o 
.libs/libgnunet_plugin_gtk_namestore_box_la-plugin_gtk_namestore_box.o
In file included from plugin_gtk_namestore_box.c:62:
plugin_gtk_namestore_tlsa.c: In function 'import_address_cb':
plugin_gtk_namestore_tlsa.c:964:10: error: 'GNUTLS_CRT_RAW' undeclared (first 
use in this function); did you mean 'GNUTLS_CRT_MAX'?
 case GNUTLS_CRT_RAW:
  ^~
  GNUTLS_CRT_MAX
plugin_gtk_namestore_tlsa.c:964:10: note: each undeclared identifier is 
reported only once for each function it appears in
plugin_gtk_namestore_tlsa.c:950:5: warning: enumeration value 
'GNUTLS_CRT_RAWPK' not handled in switch [-Wswitch]
 switch (type)
 ^~
plugin_gtk_namestore_tlsa.c:950:5: warning: enumeration value 'GNUTLS_CRT_MAX' 
not handled in switch [-Wswitch]
make[5]: *** [Makefile:1148: 
libgnunet_plugin_gtk_namestore_box_la-plugin_gtk_namestore_box.lo] Error 1


Cheers,

Andreas


gnunet-gtk_0.11.0~pre66-1.log.gz
Description: application/gzip

Bug#921246: llvm-toolchain-7: FTBFS on kfreebsd-any

[Svante Signell]

On Sun, 2019-02-03 at 23:39 +0100, Sylvestre Ledru wrote:
> Le 03/02/2019 à 17:21, Sylvestre Ledru a écrit :
> > Le 03/02/2019 à 15:28, Svante Signell a écrit :
> > > Source: llvm-toolchain-7
> > > Version: 7_7.0.1-4
> > > Severity: important
> > > Tags: ftbfs, patch
> > > User: debian-k...@lists.debian.org
> > > Usertags: kfreebsd
> > > 
> > > Hello,
> > > 
> > > Currently llvm-toolchain-7 FTBFS on GNU/kFreeBSD dues to a missing 
> > > port to that
> > > architecture. Attached are 14 patches...
> > > clang_lib_Basic_Targets.diff
> > > CMakeLists.txt.diff
> > > compiler-rt_lib.diff
> > > include_llvm_ADT_Triple.h.diff
> > > kfreebsd-libcxx-threads-detection.diff
> > > kfreebsd-openmp.diff
> > > kfreebsd-threads-build.diff
> > > kfreebsd-triple-clang.diff
> > > kfreebsd-triple.diff
> > > lib_Support.diff
> > > lib_Target_X86.diff
> > > lldb_source_Host_freebsd_Host.cpp.diff
> > > lldb_source_Plugins_Process_FreeBSD.diff
> > > tools_llvm-shlib_CMakeLists.txt.diff
> > > 
> > > Additionally, the install file for liblldb-7 needs a separate file: 
> > > liblldb-
> > > 7.install.kfreebsd. Adding [!kfreebsd-any] to the last row of 
> > > liblldb-7.install
> > > (or liblldb-X.Y.install.in) did not work.
> > > 
> > > I will submit these patches to upstream too, in due time.
> > 
> > Wahou, impressive!
> > 
> > Don't hesitate to submit a MR next time!
> > 
> > S
> > 
> I tried to build it on amd64 but it fails with
> 
> /build/llvm-toolchain-7-7.0.1/projects/compiler-
> rt/lib/fuzzer/FuzzerUtilPosix.cpp:122:28: 
> error:
>use of undeclared identifier 'LIBFUZZER_KFREEBSD'
>LIBFUZZER_OPENBSD || LIBFUZZER_KFREEBSD) {
> 
> 
> Index: llvm-toolchain-7-7.0.1/compiler-rt/lib/fuzzer/FuzzerDefs.h
> ===
> --- llvm-toolchain-7-7.0.1.orig/compiler-rt/lib/fuzzer/FuzzerDefs.h
> +++ llvm-toolchain-7-7.0.1/compiler-rt/lib/fuzzer/FuzzerDefs.h
> @@ -28,6 +28,7 @@
>   #define LIBFUZZER_LINUX 1
>   #define LIBFUZZER_NETBSD 0
>   #define LIBFUZZER_FREEBSD 0
> +#define LIBFUZZER_KFREEBSD 0
>   #define LIBFUZZER_OPENBSD 0
>   #define LIBFUZZER_WINDOWS 0
>   #elif __APPLE__
> 
> 
> It fixed it (and it has to be replicated for the other archs)

Sorry, I was a little sloppy defining LIBFUZZER_KFREEBSD. Do you want an updated
patch?

Bug#921282: sbuild: emits many messages “Alias ‘[...]’ already associated with ‘[...]’ chroot”

[Ben Finney]

Control: retitle -1 schroot: emits many messages “Alias ‘[...]’ already 
associated with ‘[...]’ chroot”
Control: found -1 schroot/1.6.10-6+b1

On 03-Feb-2019, Johannes Schauer wrote:
> it seems that this message comes from schroot and not sbuild. Thus,
> reassigning.

Thanks. I am also altering the metadata for the version of ‘schroot’
installed.

-- 
 \“Humanity has advanced, when it has advanced, not because it |
  `\ has been sober, responsible, and cautious, but because it has |
_o__)been playful, rebellious, and immature.” —Tom Robbins |
Ben Finney 

Bug#921287: Acknowledgement (ITP: battery -- cross-platform, normalized battery information library)

[Antoine Beaupré]

Control: retitle 921287 golang-github-distatus-battery-dev

Bug#921259: KiCad 5.1 appears to be 6.0 (experimental)

[Carsten Schoenert]

Hello Gert,

Am 03.02.19 um 23:19 schrieb Geert Stappers:
> On Sun, Feb 03, 2019 at 07:39:20PM +0100, Nick Østergaard wrote:
>> This is not wrong, this is as expected.
> 
> Please elaborate

this version number (6.0.0-rc1) is currently hard coded within the CMake
 files of kicad.

> $ grep 6.0.0-rc1 CMakeModules/*
> CMakeModules/KiCadVersion.cmake:set( KICAD_VERSION "6.0.0-rc1-unknown" )

I'm currently to lazy to do any kind of patching this as this would
resulting in differing the showed version number in Debian from all
other packaging systems for KiCad.

The reason behind the current used number '6.0.0' is grounded on the
original next planed version number for KiCad. Unfortunately version
5.0.x has some significant issues regarding the changes happen to
wxWidgets not only in Debian. So the KiCad project decided to do a
version 5.1.x for fixing these issues and adding GTK+3 support to KiCad
especially in/for Linux.

This version string is no real problem, I guess Debian is now also hit
by the newer GLM version which seems not be usable for the current HEAD
in 5.1.

-- 
Regards
Carsten Schoenert

Bug#921276: status update

[Antoine Beaupré]

Control: block 921276 by 921286 921285 921287 921288

The above estimate is incorrect: docopt is already packaged, for
example.

I've filed more ITPs for the other (currently) known build-deps, but
that might grow a little more. I didn't notice an RFP for termui
(#890567) so we have a duplicate there (#921286).

I also filed a bunch of bugs upstream so they issue proper releases.

A.
-- 
We are discreet sheep; we wait to see how the drove is going, and then go
with the drove.
- Mark Twain

Bug#919619: network-manager: should support iwd as wpasupplicant alternative

[Jonas Smedegaard]

Quoting Andreas Henriksson (2019-02-03 23:12:37)
> Control: severity -1 wishlist

Please reconsider the severity, because...

> On Thu, Jan 17, 2019 at 10:09:21PM +0100, Jonas Smedegaard wrote:
> > network-manager is compiled with support for iwd,
> > but the package declares an absolute dependency on wpasupplicant.

Above is the issue reported: I.e. the _possibility_ for using iwd as 
alternative.


> Please note that from a "debian stable perspective" iwd should still 
> be considered "tech preview".

Yes.  Understood.

But similar to our various X11 login managers not _depending_ on stable 
window managers but at most _recommending those, I beg for same here.

> Having said all that, iwd should probably work well for most users.
> (But at the same time I'd also recommend keeping wpasupplicant
> installed for those cases where you do run into a situation where
> you can't connect using iwd and has no other connectivity options
> available.)

It seems you - literally - agree that we should _recommend_ 
wpasupplicant.  That is what this bug is about: Currently 
network-manager _depends_ on wpasupplicant which is wrong: In some 
exotic situations it makes sense to not install wpasupplicant, and 
network-manager _works_ without wpasupplicant, just less ideal.


> > Please add iwd as alternative to wpasupplicant.
> 
> In support of this statement, I'd like to think of potential drawbacks 
> and try to argue why they aren't problematic.

In retrsospect I regret having mentioned above in this same bugreport.

Because I agree that _encouraging_ the use of iwd is of severity 
wishlist and unsuitable for Buster.

Please disregard, for the purpose of judging severity of this bugreport 
at least.


 - Jonas

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

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


signature.asc
Description: signature

Bug#921289: caja-dropbox: Please remove the older Drombox instances

[Jean-Philippe MENGUAL]

Package: caja-dropbox
Version: 1.20.0-4
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I have noted an anormal increasing of my root filesystem, in particular between 
sleep and resume.

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

I updated caja-dropbox  via apt dist-upgrade.
The /var/lib/dropbox was enormous. I onwered why.

   * What was the outcome of this action?

ls /var/lib/drombox -a showed all the Drombox versions installed since .30 to 
.65. dropboxd runs the latest one. VERSION rfrs to the
latest.

Result: the partition has more than 600MB useless due to older releases of 
installations of Dropbox.


   * What outcome did you expect instead?

With only the latest release, you have 600%B more. I could undertand we keep 
release-1 (minus 1), but not all the releases. All the more as
to remove the older releases of the Drombox instance, I need to rm the hidden 
folders manually. Altrnatively, could not the dropboxd
script provide a command to clean the .dropbox-dist directory?

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

Regard


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

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

Versions of packages caja-dropbox depends on:
ii  dbus-x11 1.12.12-1
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-5
ii  libcairo-gobject21.16.0-2
ii  libcairo21.16.0-2
ii  libcaja-extension1   1.20.3-1+b1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.2-4
ii  libgtk-3-0   3.24.4-1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  policykit-1  0.105-25
ii  procps   2:3.3.15-2
ii  python   2.7.15-4
ii  python-gpg   1.12.0-6
ii  python-gtk2  2.24.0-5.1+b1

caja-dropbox recommends no packages.

Versions of packages caja-dropbox suggests:
ii  caja  1.20.3-1+b1

-- no debconf information

Bug#921287: ITP: battery -- cross-platform, normalized battery information library

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: battery
  Version : 0.0~git20170521.916919e-1
  Upstream Author : 
* URL : https://github.com/distatus/battery
* License : Expat?
  Programming Lang: Go
  Description : cross-platform, normalized battery information library

 Gives access to a system independent, typed battery state, capacity,
 charge and voltage values recalculated as necessary to be returned in mW,
 mWh or V units.

-- 

gotop dependency. asked for releases in 

https://github.com/distatus/battery/issues/9


signature.asc
Description: PGP signature

Bug#921246: llvm-toolchain-7: FTBFS on kfreebsd-any

[Sylvestre Ledru]

Le 03/02/2019 à 17:21, Sylvestre Ledru a écrit :


Le 03/02/2019 à 15:28, Svante Signell a écrit :

Source: llvm-toolchain-7
Version: 7_7.0.1-4
Severity: important
Tags: ftbfs, patch
User: debian-k...@lists.debian.org
Usertags: kfreebsd

Hello,

Currently llvm-toolchain-7 FTBFS on GNU/kFreeBSD dues to a missing 
port to that

architecture. Attached are 14 patches...
clang_lib_Basic_Targets.diff
CMakeLists.txt.diff
compiler-rt_lib.diff
include_llvm_ADT_Triple.h.diff
kfreebsd-libcxx-threads-detection.diff
kfreebsd-openmp.diff
kfreebsd-threads-build.diff
kfreebsd-triple-clang.diff
kfreebsd-triple.diff
lib_Support.diff
lib_Target_X86.diff
lldb_source_Host_freebsd_Host.cpp.diff
lldb_source_Plugins_Process_FreeBSD.diff
tools_llvm-shlib_CMakeLists.txt.diff

Additionally, the install file for liblldb-7 needs a separate file: 
liblldb-
7.install.kfreebsd. Adding [!kfreebsd-any] to the last row of 
liblldb-7.install

(or liblldb-X.Y.install.in) did not work.

I will submit these patches to upstream too, in due time.


Wahou, impressive!

Don't hesitate to submit a MR next time!

S


I tried to build it on amd64 but it fails with

/build/llvm-toolchain-7-7.0.1/projects/compiler-rt/lib/fuzzer/FuzzerUtilPosix.cpp:122:28: 
error:

  use of undeclared identifier 'LIBFUZZER_KFREEBSD'
  LIBFUZZER_OPENBSD || LIBFUZZER_KFREEBSD) {


Index: llvm-toolchain-7-7.0.1/compiler-rt/lib/fuzzer/FuzzerDefs.h
===
--- llvm-toolchain-7-7.0.1.orig/compiler-rt/lib/fuzzer/FuzzerDefs.h
+++ llvm-toolchain-7-7.0.1/compiler-rt/lib/fuzzer/FuzzerDefs.h
@@ -28,6 +28,7 @@
 #define LIBFUZZER_LINUX 1
 #define LIBFUZZER_NETBSD 0
 #define LIBFUZZER_FREEBSD 0
+#define LIBFUZZER_KFREEBSD 0
 #define LIBFUZZER_OPENBSD 0
 #define LIBFUZZER_WINDOWS 0
 #elif __APPLE__


It fixed it (and it has to be replicated for the other archs)

Cheers,
S

Bug#921288: ITP: golang-github-protonmail-go-appdir -- Minimalistic Go package to get application directories such as config and cache

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-protonmail-go-appdir
  Version : 0.0~git20190108.8d7e66f-1
  Upstream Author : 
* URL : https://github.com/ProtonMail/go-appdir
* License : MIT/Expat?
  Programming Lang: Go
  Description : Minimalistic Go package to get application directories such 
as config and cache

 Minimalistic Go package to get application directories such as config
 and cache.

gotop dependency. asked for releases in 

https://github.com/ProtonMail/go-appdir/issues/3


signature.asc
Description: PGP signature

Bug#921282: sbuild: emits many messages “Alias ‘[...]’ already associated with ‘[...]’ chroot”

[Johannes Schauer]

Control: reassign -1 schroot

Hi,

Quoting Ben Finney (2019-02-03 22:51:27)
> Package: sbuild
> Version: 0.78.0-2
> Severity: normal
> 
> When using a chroot created for SBuild, the SBuild commands (‘sbuild’,
> ‘sbuild-update’, ‘sbuild-shell’, etc.) emit a stream of repeated
> messages about alias associations.
> 
> These messages are interspersed in with other SBuild output and the
> output from the commands it runs. This makes the output unusably
> crowded with warning messages.
> 
> =
> $ sudo sbuild-shell unstable
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
> ‘unknown’ chroot
> W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already 
> associated with ‘unknown’ chroot
> W: line 9 

Bug#921286: ITP: termui -- Golang terminal dashboard

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: termui
  Version : 2.3.0-1
  Upstream Author : Zack Guo
* URL : https://github.com/gizak/termui
* License : MIT/Expat?
  Programming Lang: Go
  Description : Golang terminal dashboard

 termui is a cross-platform and fully-customizable terminal dashboard
 and widget library built on top of termbox-go. It is inspired by
 blessed-contrib and tui-rs and written purely in Go.

 Features
 
  * Built in widget implementations for common use cases
  * Utilities to create custom widgets
  * A grid layout for relative widget positioning
  * Mouse support
  * Event handling for keyboard, mouse and resizing events
  * Colors and styling
 
--

Dependency for gotop.


signature.asc
Description: PGP signature

Bug#921285: ITP: golang-github-cjbassi-drawille-go -- Pixel graphics in terminal with unicode braille characters (golang)

[Antoine Beaupré]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupré 

* Package name: golang-github-cjbassi-drawille-go
  Version : 0.0~git20190126.27dc511-1
  Upstream Author : Caleb Bassi
* URL : https://github.com/cjbassi/drawille-go
* License : MIT/Expat?
  Programming Lang: Go
  Description : Pixel graphics in terminal with unicode braille characters 
(golang)

 A drawille implementation in Go with a more permissive license.

-- 

Dependency for gotop (#921276)

Asked for tagged releases in https://github.com/cjbassi/drawille-go/issues/1


signature.asc
Description: PGP signature

Bug#921259: KiCad 5.1 appears to be 6.0 (experimental)

[Geert Stappers]

On Sun, Feb 03, 2019 at 07:39:20PM +0100, Nick Østergaard wrote:
> This is not wrong, this is as expected.

Please elaborate

Bug#921150: also accept me in the go team WAS: ITP

[Geert Stappers]

On Sat, Feb 02, 2019 at 10:32:31AM +, Rock Storm wrote:
 [ ...
   ITP golang-github-arduino-go-paths-helper
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921150
 ... ]
> The package 'arduino-builder' [1] has been split into several smaller
> Go libraries like this one (at least two more to come). Even
> though 'arduino-builder' is maintained by the electronics team, I
> believe this libraries should be maintained by the Go team.
> 
> If you agree, then let this mail serve also as a formal request for the
> Go team to accept this package, and also to accept me in the team.
> 
> @Geert, I'm CCing you so you are aware of this matter and in case
> you want to argue against.

Yes, got it.

Yes, https://github.com/arduino/go-paths-helper  is in go-lang.

Yes, packaging it like other go packages and together with the go team
is wise.


To prevent that the ITP + new team member message will be seen
as another ITP, did I change the Subject: header.



Groeten
Geert Stappers
DD


P.S.
I'm not subscribed to debian-go@l.d.o
I'm subscribed to this bugreport

[1]: https://salsa.debian.org/electronics-team/arduino/arduino-builder
-- 
Leven en laten leven


signature.asc
Description: PGP signature

Bug#900761: please separate passwd manipulation from the library package, together with expect et al

[Josip Rodin]

On Sat, Feb 02, 2019 at 09:39:25PM +0100, Markus Wanner wrote:
> I fear that's not possible, as it would mean splitting the library
> itself.  Please speak up if you have ideas or wishes on what the
> packaging could do to improve your use case.  Otherwise, I'll close this
> issue.

If it's an upstream issue that can't be fixed with packaging, then
tag it upstream and forward it, as the fine manual teaches you to.

(I'm not sure why people are so anxious to close bug reports these days...)

-- 
 2. That which causes joy or happiness.

Bug#921284: build-using should only include copylefted files

[Antoine Beaupre]

Package: dh-golang
Version: 1.39
Severity: serious

My first submissions for the dmarc-cat package (#920385) were refused
by the FTP masters because the built-using field did not respect §7.8
of the Debian policy. Extract from #debian-ftp:

16:55:59  Built-Using is only meant to be used when the result is 
GPL/MPL/similar and you've statically linked (/bundled) another source package
16:56:33  okay, so to comply with licensing issues?
16:56:47  it also seems useful to track rdeps for golang as well, no?
16:57:03  no, built-using is _not_ for tracking dependencies
16:57:10  it is for license compliance
16:57:26  and bsd licensed software does not require that

So in the case of dmarc-cat, dependencides like
golang-github-stretchr-testify-dev should actually not be listed in
the Built-Using field.

dh-cargo solves this by manually inspecting the copyright files in the
dependencies:

https://sources.debian.org/src/dh-cargo/17/dh-cargo-built-using/

Some similar solution should be implemented in dh-golang.

In the meantime, a workaround is to inspect the automatically
generated Built-Using line and hardcode a proper version after a
manual copyright audit. In the case of dmarc-cat, that inspection seem
to indicate no Built-Using line should be included whatsoever, as all
dependencies are BSD/MIT/Expat/Apache which doesn't require including
source...


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

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

Versions of packages dh-golang depends on:
ii  debhelper 12
ii  dpkg  1.19.2
ii  libdpkg-perl  1.19.2
ii  perl  5.28.1-3

dh-golang recommends no packages.

dh-golang suggests no packages.

-- debconf-show failed

Bug#919619: network-manager: should support iwd as wpasupplicant alternative

[Andreas Henriksson]

Control: severity -1 wishlist

Hi,

I think this severity is better as wishlist until iwd 1.0 is released
with further details below.

On Thu, Jan 17, 2019 at 10:09:21PM +0100, Jonas Smedegaard wrote:
> Package: network-manager
> Version: 1.14.4-4
> Severity: important
[...]
> network-manager is compiled with support for iwd,
> but the package declares an absolute dependency on wpasupplicant.

Please note that from a "debian stable perspective" iwd should still be
considered "tech preview". There are no promises about any kind of
interface stability until version 1.0 is released (notably the dbus IPC
interface which NM uses). See also #911057 related to (the lack of)
interface stability promises.

There are also a number of features still missing in both iwd and the
iwd-plugin of NM before the iwd code-path can compete with and be a full
(production-ready) replacement for wpasupplicant.
- iwd is still working on implementing support for "complex" wifi setups
  (and I don't have access to any such networks for testing and
  evaluation).
- network-manager is still missing support for things like connecting to
  hidden SSIDs while using iwd.

Having said all that, iwd should probably work well for most users.
(But at the same time I'd also recommend keeping wpasupplicant
installed for those cases where you do run into a situation where
you can't connect using iwd and has no other connectivity options
available.)

> 
> Please add iwd as alternative to wpasupplicant.

In support of this statement, I'd like to think of potential drawbacks
and try to argue why they aren't problematic.

If the dependency was described as 'wpasupplicant | iwd' the only
problematic situation I would forsee would be when someone first
installed iwd, then later installed NM (and assumed it would drag in the
default dependency).

Given the total number of users of iwd are currently "almost
non-existant" (compared to NM userbase) the cases where the above
problem will happen is also thus non-existant.
(current numbers according to popcon: 34 installed, 24 vote. See:
https://qa.debian.org/popcon.php?package=iwd )

My conclusion is thus that the dependency could likely safely be
described as 'wpasupplicant | iwd' to cater for the very small minority
(subset) of iwd users who wishes to not have wpasupplicant installed
(and prepare for a future where iwd >= 1.0 and NM iwd-plugin is also in
better shape).

> Also, please consider relaxing to only recommend this combo,
> as network-manager is certainly usable without those available, only
> (as described when seemingly this was tightened in 0.6.0-1)
> "necessary for all encrypted connections."

>From my own experience I can tell that there aren't enough volunteers
taking on the support burden of downgrading things which could
theoretically be recommends instead of depends for very popular and
widely used software like NM. There are just too many people still
disabling recommends without knowing what they're getting themselves
into and then complaining "it's broken".

The minority of people who really can't spare the storage space to have
wpasupplicant installed while unused (and want to avoid maintaning their
own fork of the package) will find the solution here:
https://packages.debian.org/unstable/equivs

Even if we assume counting the people who want neither would double the
number of people who would rather just have iwd, this graph should make
it pretty clear why "a minor inconvenience for NM users" far outweighs
"a major inconvenience for iwd/none users":
https://qa.debian.org/popcon-graph.php?packages=iwd%2Cnetwork-manager_vote=on_legend=on_ticks=on_date=_date=_date=_fmt=%25Y-%25m=1
Even if only 1% (which I'm pretty sure is way to low) of users are in
the 'install without recommends and complain'-camp, that's still alot
more users than iwd*2.

Regards,
Andreas Henriksson

Bug#917524: initramfs-tools: Upgrade from initramfs-tools package fails

[Ben Hutchings]

Control: tag -1 moreinfo

On Sat, 29 Dec 2018 03:33:54 +0100 =?UTF-8?B?SsO8cmdlbiBHw7ZyaWNrZQ==?= 
 wrote:
> Hello Ben,
> 
> I already installed udev 240-2, but the bug in the initramfs-tools package 
> still exists.
> This is not surprising, because udev was installed a few days ago without any 
> errors.
> Only by installing the package "initramfs-tools" (version: 0.132: all) the 
> installation error occurred.
> 
> Can you please check again where exactly the error is?
> Thanks a lot!
[...]

Please check again with udev 240-4 as the bug I am thinking of was only
partly fixed in 240-2.

Ben.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.




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

Bug#921283: ITP: node-trust-keyto -- utility for translating cryptographic keys between representations

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-trust-keyto
  Version : 0.3.4
  Upstream Author : Greg Linklater 
* URL : https://eternaldeiwos.github.io/keyto
* License : Expat
  Programming Lang: JavaScript
  Description : utility for translating cryptographic keys between 
representations

 This Node.js library implements routines
 to translate between multiple cryptographic key representations.
 .
 RSA
  * PKCS1
  * PKCS8
  * JWK
 .
 ECDSA - secp256k1 (Blockchain Curve)
  * PKCS1 (Private Only)
  * PKCS8
  * JWK
  * BLK (Private Key Hex String)
 .
 ECDSA - secp256r1 (P-256)
  * PKCS1 (Private Only)
  * PKCS8
  * JWK
 .
 ECDSA - secp384r1 (P-384)
  * PKCS1 (Private Only)
  * PKCS8
  * JWK
 .
 ECDSA - secp521r1 (P-521)
  * PKCS1 (Private Only)
  * PKCS8
  * JWK
 .
 Node.js is an event-based server-side JavaScript engine.

This package will be maintained in the JavaScript team.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxXY8oACgkQLHwxRsGg
ASEcJA//ZjpswpGnT5ppi3m9FdB6+CMO3P23rmk9fB7ecQ+GLoB1lbss6FY1lFHx
czgmbzc1igPt/ZoeLk/vvpAjY/qQdOzsgQZfX1GTvl6GkPNYBQnXemXhsQnursDO
I1ROmDlgCSRogITvY/ZTY+kcxLQG+wK6SvKOs2IZKqXykGzVTLgmUG+g8aCY716o
f5eoVFVS6KkyIMwIJ5xJ33y+ib+k5ILXqW9zrDNXXhFUWlkETtkgRq6QePBn/TNR
kvJp5m8e0mY9nKdW4bW+4VdeTvXqeJ8qr2t0xdJNGA54HIvcNCNGsXg7WZGo71Ee
cZ8lnCPpZ5EfVbfUHvGUvaY8MMiAptBBiU3Lc8Si0r/keAJQKvgrqHWxO/tTIX69
Wmw0zaxLTAy1FgfkkZVqP/ROdIwYtiJc+epXjVo8S0cXB5jUR8Jg2/wQMU/meCMk
HTzag3D3lKkLKkQ8VQJ03df87cTUSt8Ky/O53xb91x55DfKDO2idd9FZye1loFtD
MyQrQ1iESxSzNeeNjBKrIPvff7HfGb13QATpo6X6xAAJTOdrnWrLvPXQx8VTBsIu
b3zRbBeCaK4iEe18fbuhLWZ8dlLph2QG7xvfhLc1qhv/yK94jN722dnFYA7BK7WG
Z33RzGxTuXS7I2Gs4XbpOnT+hBm0qrO+FzOoih3r6TNRGpGt/Sw=
=5oAR
-END PGP SIGNATURE-

Bug#921282: sbuild: emits many messages “Alias ‘[...]’ already associated with ‘[...]’ chroot”

[Ben Finney]

Package: sbuild
Version: 0.78.0-2
Severity: normal

When using a chroot created for SBuild, the SBuild commands (‘sbuild’,
‘sbuild-update’, ‘sbuild-shell’, etc.) emit a stream of repeated
messages about alias associations.

These messages are interspersed in with other SBuild output and the
output from the commands it runs. This makes the output unusably
crowded with warning messages.

=
$ sudo sbuild-shell unstable
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 
‘unknown’ chroot
I: /bin/sh
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘UNRELEASED’ already associated 
with ‘unknown’ chroot
W: line 9 [stretch-amd64-sbuild] aliases: Alias ‘sid’ already associated with 

Bug#921265: [Debian-ha-maintainers] Bug#921265: corosync breaks corosync-qdevice autopkgtest: Could not initialize corosync configuration API error CS_ERR_LIBRARY

[Valentin Vidic]

On Sun, Feb 03, 2019 at 08:53:03PM +0100, Paul Gevers wrote:
> Currently this regression is blocking the migration of corosync 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? If needed, please change the
> bug's severity.

Thanks, we also noticed this problem yesterday.  For now I will
update the test in the corosync-qdevice package.

-- 
Valentin

Bug#921281: stretch-pu: package arc/5.21q-4+deb9u1

[Salvatore Bonaccorso]

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

Hi

arc/5.21q-6 adressed in unstable an older directory traversal issue,
#774527 (CVE-2015-9275). Although the issue is marked as ignored in
the security-tracker, given the same base version I decided to prepare
as well a 5.21q-4+deb9u1 for stretch.

Attached is the debdiff with the same three patches addes as for
5.21q-6 (yes there is typo in the patch name, but I just used the very
same as for the unstable upload).

Regards,
Salvatore
diff -Nru arc-5.21q/debian/changelog arc-5.21q/debian/changelog
--- arc-5.21q/debian/changelog  2015-09-02 16:44:25.0 +0200
+++ arc-5.21q/debian/changelog  2019-02-03 22:39:01.0 +0100
@@ -1,3 +1,13 @@
+arc (5.21q-4+deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix version 1 arc header reading
+  * Fix arcdie crash when called with more then 1 variable argument
+  * Fix directory traversal bugs (CVE-2015-9275)
+Thanks to Hans de Goede  (Closes: #774527)
+
+ -- Salvatore Bonaccorso   Sun, 03 Feb 2019 22:39:01 +0100
+
 arc (5.21q-4) unstable; urgency=medium
 
   * New maintainer. Thanks to Klaus Reimer for your work over this package.
diff -Nru arc-5.21q/debian/patches/arc-5.21p-directory-traversel.patch 
arc-5.21q/debian/patches/arc-5.21p-directory-traversel.patch
--- arc-5.21q/debian/patches/arc-5.21p-directory-traversel.patch
1970-01-01 01:00:00.0 +0100
+++ arc-5.21q/debian/patches/arc-5.21p-directory-traversel.patch
2019-02-03 22:39:01.0 +0100
@@ -0,0 +1,21 @@
+Fix directory traversal bugs
+
+arc archives do not contain directory hierarchies, only filenames, so refuse
+to operate on archives which have the directory-seperator inside filenames.
+
+BugLink: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774527
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1179143
+Signed-off-by: Hans de Goede 
+diff -up arc-5.21p/arcio.c~ arc-5.21p/arcio.c
+--- arc-5.21p/arcio.c~ 2015-01-16 13:04:16.0 +0100
 arc-5.21p/arcio.c  2015-01-16 15:45:31.389010626 +0100
+@@ -109,6 +109,9 @@ readhdr(hdr, f)/* read a header from
+ #if   _MTS
+   (void) atoe(hdr->name, strlen(hdr->name));
+ #endif
++  if (strchr(hdr->name, CUTOFF) != NULL)
++  arcdie("%s contains illegal filename %s", arcname, hdr->name);
++
+   for (i = 0, hdr->size=0; i<4; hdr->size<<=8, hdr->size += dummy[16-i], 
i++);
+   hdr->date = (short) ((dummy[18] << 8) + dummy[17]);
+   hdr->time = (short) ((dummy[20] << 8) + dummy[19]);
diff -Nru arc-5.21q/debian/patches/arc-5.21p-fix-arcdie.patch 
arc-5.21q/debian/patches/arc-5.21p-fix-arcdie.patch
--- arc-5.21q/debian/patches/arc-5.21p-fix-arcdie.patch 1970-01-01 
01:00:00.0 +0100
+++ arc-5.21q/debian/patches/arc-5.21p-fix-arcdie.patch 2019-02-03 
22:39:01.0 +0100
@@ -0,0 +1,34 @@
+Fix arcdie crash when called with more then 1 variable argument
+
+Add proper vararg handling to fix crash on 64 bit machines when arcdie gets
+called with more then 1 variable argument.
+
+Signed-off-by: Hans de Goede 
+diff -up arc-5.21p/arcmisc.c~ arc-5.21p/arcmisc.c
+--- arc-5.21p/arcmisc.c~   2010-08-07 15:06:42.0 +0200
 arc-5.21p/arcmisc.c2015-01-16 16:10:29.322603290 +0100
+@@ -4,6 +4,7 @@
+  */
+ 
+ #include 
++#include 
+ #include 
+ #include "arc.h"
+ 
+@@ -223,11 +224,13 @@ upper(string)
+ }
+ /* VARARGS1 */
+ VOID
+-arcdie(s, arg1, arg2, arg3)
+-  char   *s;
++arcdie(const char *s, ...)
+ {
++  va_list args;
+   fprintf(stderr, "ARC: ");
+-  fprintf(stderr, s, arg1, arg2, arg3);
++  va_start(args, s);
++  vfprintf(stderr, s, args);
++  va_end(args);
+   fprintf(stderr, "\n");
+ #if   UNIX
+   perror("UNIX");
diff -Nru arc-5.21q/debian/patches/arc-5.21p-hdrv1-read-fix.patch 
arc-5.21q/debian/patches/arc-5.21p-hdrv1-read-fix.patch
--- arc-5.21q/debian/patches/arc-5.21p-hdrv1-read-fix.patch 1970-01-01 
01:00:00.0 +0100
+++ arc-5.21q/debian/patches/arc-5.21p-hdrv1-read-fix.patch 2019-02-03 
22:39:01.0 +0100
@@ -0,0 +1,70 @@
+Fix version 1 arc header reading
+
+The code for v1 hdr reading was reading the packed header directly into an
+unpacked struct.
+
+Use the same read to dummy array, then manual unpack to header struct as
+used for v2 headers for v1 headers too.
+
+Signed-off-by: Hans de Goede 
+diff -ur arc-5.21p/arcio.c arc-5.21p.new/arcio.c
+--- arc-5.21p/arcio.c  2010-08-07 15:06:42.0 +0200
 arc-5.21p.new/arcio.c  2015-01-16 12:59:43.203289118 +0100
+@@ -37,6 +37,7 @@
+ #endif
+   charname[FNLEN];/* filename buffer */
+   int try = 0;/* retry counter */
++  int hdrlen;
+   static int  first = 1;  /* true only on first read */
+ 
+   if (!f) /* if archive didn't open */
+@@ -92,23 +93,19 @@
+   printf("I think you need 

Bug#921226: RFS: austin/0.6.1~beta-1 [ITP]

[Adam Borowski]

On Sun, Feb 03, 2019 at 11:43:43AM +, Gabriele wrote:
> * Package name: austin
>   Version : 0.6.1~beta-1

>   dget -x 
> https://mentors.debian.net/debian/pool/main/a/austin/austin_0.6.1~beta-1.dsc

> austin (0.6.1~beta-1) unstable; urgency=medium
> 
>   * Initial release (Closes: #918518)

Hi!
First, could you please upload your GPG public key to a keyserver (most will
then distribute it further)?  That's not strictly needed, but will allow
verifying that subsequent uploads come from the same person.

The command to do so is:
gpg --send-keys 28685C7301633F89212E14876036934E1BA07EFA
(not sure if there's a need to name a keyserver explicitly)


The package requires some tool named "snapcraft" to even repack the source;
I see no program by that name anywhere in Debian.

It also doesn't declare any build-dependencies beyond debhelper; I haven't
looked any further but it's pretty clear it'll need something pythonesque.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

Bug#921280: systemd-cgtop no longer shows memory usage

[Anthony DeRobertis]

Package: systemd
Version: 240-5
Severity: normal
File: /usr/bin/systemd-cgtop

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

systemd-cgtop now displays '-' for all memory usage columns. Not sure
exactly when it stopped working, I had it running in a terminal for a
long time (so it was an old version). When I finally restarted it, it no
longer worked. Even after rebooting the machine, it continues to not
work.

Control Group Tasks 
  %CPU   Memory  Input/s Output/s
/   781 
  11.6---
/init.scope   1 
 ----
/system.slice   238 
   1.2---
/system.slice/acpid.service   1 
   0.0---
/system.slice/apache-htcacheclean.service 1 
   0.0---
/system.slice/apache2.service11 
   0.0---
/system.slice/atd.service 1 
 ----
⋮

Memory accounting information shows fine in `systemctl status`, though:

$ systemctl status atd.service
● atd.service - Deferred execution scheduler
   Loaded: loaded (/lib/systemd/system/atd.service; enabled; vendor preset: enab
   Active: active (running) since Sun 2019-02-03 16:27:07 EST; 13min ago
 Docs: man:atd(8)
  Process: 1503 ExecStartPre=/usr/bin/find /var/spool/cron/atjobs -type f -name 
 Main PID: 1565 (atd)
Tasks: 1 (limit: 4915)
   Memory: 1.3M
  CPU: 4ms
   CGroup: /system.slice/atd.service
   └─1565 /usr/sbin/atd -f

Feb 03 16:27:06 Watt systemd[1]: Starting Deferred execution scheduler...
Feb 03 16:27:07 Watt systemd[1]: Started Deferred execution scheduler.

I'm booting with systemd.unified_cgroup_hierarchy=1 if it matters.


- -- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.52-3+b1
ii  libapparmor1 2.13.2-7
ii  libaudit11:2.8.4-2
ii  libblkid12.33.1-0.1
ii  libc62.28-5
ii  libcap2  1:2.25-1.2
ii  libcryptsetup12  2:2.0.6-1
ii  libgcrypt20  1.8.4-4
ii  libgnutls30  3.6.6-2
ii  libgpg-error01.33-3
ii  libidn11 1.33-2.2
ii  libip4tc01.8.2-3
ii  libkmod2 25-2
ii  liblz4-1 1.8.3-1
ii  liblzma5 5.2.2-1.3
ii  libmount12.33.1-0.1
ii  libpam0g 1.1.8-4
ii  libseccomp2  2.3.3-3
ii  libselinux1  2.8-1+b1
ii  libsystemd0  240-5
ii  mount2.33.1-0.1
ii  util-linux   2.33.1-0.1

Versions of packages systemd recommends:
ii  dbus1.12.12-1
ii  libpam-systemd  240-5

Versions of packages systemd suggests:
ii  policykit-10.105-25
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.132
ii  udev 240-5

- -- Configuration Files:
/etc/systemd/system.conf changed:
[Manager]
DefaultCPUAccounting=yes
DefaultMemoryAccounting=yes


- -- no debconf information

-BEGIN PGP SIGNATURE-

iHMEARECADMWIQTlAc7j4DAtSNRJJ0z7P4jCVepZ/gUCXFdgiBUcYW50aG9ueUBk
ZXJvYmVydC5uZXQACgkQ+z+IwlXqWf50PQCdEhQOhXiA7v/qi/IRdbVnovWzrMMA
n0zKtwj5lJ8BazDXSybxJw2JAX7/
=Cs2T
-END PGP SIGNATURE-

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Felipe Sateler]

Control: forwarded -1 https://github.com/systemd/systemd/issues/11645

I have forwarded the bug upstream, and proposed two solutions. If upstream
likes one, we can apply that in the debian package.

Saludos

Bug#919272: Is multiple-layers of alternatives a good thing to users?

[Ian Jackson]

Mo Zhou writes ("Is multiple-layers of alternatives a good thing to users?"):
> A user suggested[1] that the 6 variants[2] of BLIS should be
> co-installable. However, making them co-installable would result in
> multiple layers of alternatives in the update-alternatives system and
> will possibly confuse users, as discussed in [3]. I wrote this mail
> in case anyone has a better solution so we will have a chance to fix[1].
> 
> Tacking the three 32-bit variants as examples, we will have the
> following alternative chain if the 3 variants were made co-installable:
> 
>   Package: libblis2-openmp,  Provides: libblis.so.2
>   Package: libblis2-pthread, Provides: libblis.so.2
>   Package: libblis2-serial,  Provides: libblis.so.2
>   Package: libblis2 (meta),  Provides: libblas.so.3,  Depends: libblis.so.2,
>   Package: python3-numpy,Depends: libblas.so.3
> 
>   numpy asks for libblas.so.3
> -> libblas.so.3 is an alternative pointing to libblis2
> -> libblis.so.2 is an alternative pointing to any one of the three 
> variants

In general coinstallability is a good thing.

I don't understand why the multiple levels of alternatives are
inevitable.  Why could each of the variants not provide both an
alternative option for libblas.so.3, and separately one for
libblis.so.3 ?

This would mean that the user could choose a different library for
"programs which wanted BLAS" and "programs which wanted BLIS" but I
don't think that is a problem ?

(Getting there from here is left as an exercise to the reader...)

> Such layout not only makes the packaging more difficult to maintain, but
> also makes it harder for the user to understand what BLAS backend is
> actually invoked.

I agree that multiple layers of alternatives indirection is
undesirable.  But I think these libraries can be made coinstallable
without that.

HTH.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#904030: Additional symptoms

[Étienne Mollier]

Good Day,

I landed here since this very issue, observed elsewhere,
triggered a discussion on debian-user-french.  Here are a few
symptoms observed while doing a few experiments:

- The problem appeared on Xfce desktop with clipit starting up
  automatically at session launch.  It did also appear when
  starting a dwm desktop and launching :

$ clipit

- When the problem appears, another symptom is the disappearance
  of the text selection highlighting after a few tenth of
  seconds.  While the text is highlighted, the paste /can/
  occur.  This has been observed on xfce4-terminal and mousepad,
  but not stterm (un)interestingly.

- The problem does /not/ appear when clipit is run in daemon
  mode, where it only keeps CLIPBOARD and PRIMARY safe, e.g.:

$ clipit -d

  and the program works as expected, e.g. copy buffers are
  maintained, even though the initial X client holding the
  selection has been closed.

- Not sure if that is interesting, but the "File" menu of Thunar
  is flickering at the same rate as the clipboard selection is
  cleared.  This flicker does not appear when clipit is not
  running in faulty mode.  I haven't observed this on any other
  program yet.

- I haven't been able to reproduce the problem on my main Debian
  Sid system.  Furthermore, upgrading clipit using Sid packages
  to the Buster machine didn't fix the problem.

- The problem appeared even without any window manager running.

- If I purge gvfs related packages from the system, no changes.

The configuration was Debian Buster, built using the Alpha 5
Debian installer on a virtual machine.  The host was the main
Debian Sid machine.

Not sure if this is very helpful, but let's hope some bit will
be informative.

Kind Regards,
-- 
Étienne Mollier 

Bug#921278: bibtex2html: Lacks several math-related translations

[James Van Zandt]

Package: bibtex2html
Version: 1.99-2.1
Severity: wishlist
Tags: patch

Dear Maintainer,


I maintain several large bibtex files, including one devoted to
numerical analysis papers, with abstracts that use a lot of math
notation.  I have collected some of the required translations
into a latex macro file that I can load with the -m switch.
However, it would be more convenient to have those translations
built into bibtex2html tool.

I'm proposing four kinds of additions:

 - bibtex2html already had a translation for \log.  I've added
   translations for all 32 of the math functions on p. 162 of the
   TeXbook.

 - I added single-character translations for \lbrace, \rbrace,
   and \over.

 - There were already translations for \sum, \int, and \prod that
   used HTML entities.  I've added translations using
   Unicode.  (Note that there were already translations for "--"
   and "---" to both HTML entities and Unicode, presumably for
   situations where one was acceptable but the other was not, so
   I'm following the same convention.)

 - I added both Unicode and HTML translations for \ell, \ll,
   \gg,\langle, and \rangle.

I'm attaching a patch to make those additions for Debian.  It
would be even better to get them accepted upstream.

 - Jim Van Zandt


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (700, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages bibtex2html depends on:
ii  ocaml-base-nox [ocaml-base-nox-4.05.0]  4.05.0-11
ii  perl5.28.1-3
ii  texlive-base2018.20190131-1

bibtex2html recommends no packages.

Versions of packages bibtex2html suggests:
pn  hlins  


more-translations
Description: Binary data