Bug#933246: virtualbox FTBFS: missing Build-Depends: libgsoap-dev

[Helmut Grohne]

Source: virtualbox
Version: 6.0.10-dfsg-1
Severity: serious
Tags: patch ftbfs

We recently noticed that gsoap should not depend on libgsoap-dev
(#930961). For this reason gsoap dropped the dependency any any
downstream needs to explicitly depend on libgsoap-dev. virtualbox is
such a downstream and ftbfs as a consequence of this change. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru virtualbox-6.0.10-dfsg/debian/changelog 
virtualbox-6.0.10-dfsg/debian/changelog
--- virtualbox-6.0.10-dfsg/debian/changelog 2019-07-17 12:10:52.0 
+0200
+++ virtualbox-6.0.10-dfsg/debian/changelog 2019-07-27 21:45:37.0 
+0200
@@ -1,3 +1,10 @@
+virtualbox (6.0.10-dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Build-Depends libgsoap-dev as gsoap no longer depends on it. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Jul 2019 21:45:37 +0200
+
 virtualbox (6.0.10-dfsg-1) unstable; urgency=medium
 
   * New upstream release (Closes: #929074)
diff --minimal -Nru virtualbox-6.0.10-dfsg/debian/control 
virtualbox-6.0.10-dfsg/debian/control
--- virtualbox-6.0.10-dfsg/debian/control   2019-07-17 12:10:12.0 
+0200
+++ virtualbox-6.0.10-dfsg/debian/control   2019-07-27 21:45:37.0 
+0200
@@ -27,6 +27,7 @@
libegl1-mesa-dev,
libgl1-mesa-dev,
libglu1-mesa-dev,
+   libgsoap-dev,
libidl-dev,
libopus-dev,
libpam0g-dev,

Bug#933245: Missing dependency on node-normalize-path

[Pirate Praveen]

Package: node-anymatch
Version: 3.0.3+~2.0.7-1
Severity: serious
Justification: makes package unusable

Found this while building node-watchpack 1.6

Error: Cannot find module 'normalize-path'  Require stack:  
- /usr/share/nodejs/anymatch/index.js   - 
/usr/lib/nodejs/chokidar/index.js - 
/<>/test/Assumption.js   - 
/usr/lib/nodejs/mocha/lib/mocha.js- /usr/lib/nodejs/mocha/index.js  
  - /usr/lib/nodejs/mocha/bin/_mocha  at 
Function.Module._resolveFilename (internal/modules/cjs/loader.js:610:15)
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#930030: several errors on vim startup

[Ross Boylan]

Package: vim-vimoutliner
Version: 0.3.4+pristine-9.3
Followup-For: Bug #930030

Same problem here, also while opening an existing .otl file:
Error detected while processing /var/lib/vim/addons/ftplugin/vo_base.vim:
line  668:
E121: Undefined variable: g:vo_modules_load
line  669:
E121: Undefined variable: s:tmp
E116: Invalid arguments for function stridx(s:tmp, ':')
line  671:
E121: Undefined variable: s:idx
Press ENTER or type command to continue

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

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

Versions of packages vim-vimoutliner depends on:
ii  libpalm-perl1:1.400-1
ii  libxml-writer-perl  0.625-1
ii  perl5.28.1-6
ii  python  2.7.16-1
ii  vim 2:8.1.0875-5

Versions of packages vim-vimoutliner recommends:
ii  vim-addon-manager  0.5.10

vim-vimoutliner suggests no packages.

-- no debconf information

Bug#933244: ITP: r-cran-multidimbio -- GNU R multivariate analysis and visualization for biological data

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-multidimbio -- GNU R multivariate analysis and 
visualization for biological data
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-multidimbio
  Version : 1.1.1
  Upstream Author : Copyright: (FIXME: year)-2016 Samuel V. Scarpino
* URL : https://cran.r-project.org/package=multiDimBio
* License : MIT
  Programming Lang: GNU R
  Description : GNU R multivariate analysis and visualization for 
biological data
 Code to support a systems biology research program from inception
 through publication. The methods focus on dimension reduction approaches
 to detect patterns in complex, multivariate experimental data and places
 an emphasis on informative visualizations. The goal for this project is
 to create a package that will evolve over time, thereby remaining
 relevant and reflective of current methods and techniques.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-multidimbio

Bug#933243: ITP: r-cran-pdftools -- GNU R text extraction, rendering and converting of PDF documents

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-pdftools -- GNU R text extraction, rendering and 
converting of PDF documents
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-pdftools
  Version : 2.2
  Upstream Author : Jeroen Ooms
* URL : https://cran.r-project.org/package=pdftools
* License : MIT
  Programming Lang: GNU R
  Description : GNU R text extraction, rendering and converting of PDF 
documents
 Utilities based on 'libpoppler' for extracting text, fonts, attachments
 and metadata from a PDF file. Also supports high quality rendering of
 PDF documents into PNG, JPEG, TIFF format, or into raw bitmap vectors
 for further processing in R.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-pdftools

Bug#931965: New Debian package squashfs-tools-ng_0.4.2

[Phillip Lougher]

Debian distro

I notice you have produced a new package squashfs-tools-ng_0.4.2.

I have not been able to find any download of that package available.

Can you confirm that this package does not repeat the libel contained
in the upstream package?

Additionally this page

https://ftp-master.debian.org/new/squashfs-tools-ng_0.4.2-1.html

In the "Description" contains two paragraphs lifted from my
Squashfs-tools repository without attribution which I consider a
copyright violation.

"Squashfs is a highly compressed read-only filesystem for Linux. It uses zlib
 compression to compress both files, inodes and directories. Inodes in the
 system are very small and all blocks are packed to minimise data overhead.
 Block sizes greater than 4K are supported up to a maximum of 64K.
 .
 Squashfs is intended for general read-only filesystem use, for archival use
 (i.e. in cases where a .tar.gz file may be used), and in constrained block
 device/memory systems (e.g. embedded systems) where low overhead is needed."

Dr Phillip Lougher
Squashfs author and maintainer

Bug#933242: python-slugify: text-unicode still required dependency

[Hugo Lefeuvre]

Source: python-slugify
Version: 3.0.2-2
Severity: grave

Hi,

3.0.2-2 fixed the missing unidecode binary dependency. However
text-unidecode is still registered as a required dependency. This breaks
reverse dependencies if text-unidecode is not installed on the system.

I'm working on it.

regards,
Hugo

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


signature.asc
Description: PGP signature

Bug#928971: ITS: libgit2

[Tobias Frost]

On Wed, Jul 24, 2019 at 09:16:32PM -0300, Jongmin Kim wrote:
> Hi tobi,
> 
> On Tue, Jul 23, 2019 at 12:31:35AM -0300, Tobias Frost wrote:
> > Hi Jongming Kim,
> > 
> > In preparation for my talk (ITS -- one year later) I came across this
> > bug and as the 21 day delay has been reached I'm wondering if your are
> > still intending to salvage the package or if this bug somehow slipped
> > through some gaps and/or should be closed?
> 
> I'm going to upgrade this package to 0.28.1, and sent some transition
> pings to reverse dependencies maintainers two weeks ago. Some of them
> were closed, but most of them still need actions (patch them myself?).

I see, thanks for working on it. This sounds like you are doing a library
transistion… (as I did not find a bug against the release.debian-org pseudo
package; please read https://wiki.debian.org/Teams/ReleaseTeam/Transitions
how to coordinate library transistions with the release team.
If you did so already, appologizes).
And yes, eventually you might find yourself patching the those breaking r-deps…

> I'm still intending to salvage this package, but didn't get time because
> of DebConf. I'll come back on next week, and going to start upgrade
> transition for this package.

Cool ;-) Thanks for salvaging!

-- 
tobi


> Thanks!
> 
> -- 
> Jongmin Kim
> 
> OpenPGP key located at https://jongmin.dev/pgp
> OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8

Bug#933241: ITP: caml-mode -- emacs mode for editing OCaml programs

[Ralf Treinen]

Package: wnpp
Severity: wishlist
Owner: Ralf Treinen 

* Package name: caml-mode
  Version : recent (*)
  Upstream Author : Damien Doligez, Jacques Garrigue, Xavier Leroy, Didier
Remy, Ian T Zimmerman
* URL : https://github.com/ocaml/caml-mode
* License : GPL2+
  Programming Lang: elisp
  Description : emacs mode for editing OCaml programs

 Objective Caml (OCaml) is an implementation of the ML language, based on
 the Caml Light dialect extended with a complete class-based object system
 and a powerful module system in the style of Standard ML.
 .
 This package provides support for editing both Objective Caml and
 Caml Light programs with Emacs and XEmacs.
 .
 Caml-mode supports:
  - indentation
  - compilation and error retrieving
  - interaction with the toplevel
  - font-lock
  - imenu

This emacs-mode used to be distributed as part of the ocaml distribution
but was recently factored out by upstream into a separate git repository.
This will become relevant for debian starting from ocaml 4.08 on (which
is currently in experimental).

This package will be maintained by the ocaml-team.

(*) Concerning the version: since the creation of the separate git repo,
upstream has not issued release tags. I have asked upstream to tag the
commits they consider a release.

Bug#933240: lintian: add a pedantic tag when Rules-Requires-Root is missing

[Paul Wise]

Package: lintian
Severity: wishlist

I would like lintian to remind me when the new Rules-Requires-Root
field is missing from the source stanza in the debian/control file.

In the documentation for this tag, please mention that packagers should
verify using diffoscope that the binaries built when the R³ field is
set to no are identical to the ones produced when it is yes or absent.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#739228: retitle to O: simulavr -- Atmel AVR simulator

[Joaquin de Andres]

Control: retitle 739228 ITA: simulavr -- Atmel AVR simulator
Control: owner 739228 m...@xcancerberox.com.ar

I would like to mantain this package. I have already upload to
salsa.debian.org and added salsa CI pipeline [1].


[1] https://salsa.debian.org/xcancerberox-guest/simulavr/

Bug#933209: mark openscad-mcad Multi-Arch: foreign

[Kristian Nielsen]

On Sat, 27 Jul 2019 17:06:50 +0200 Helmut Grohne  wrote:

> openscad fails to cross build from source, because its build dependency
> on openscad-mcad is unsatisfiable. In general, Architecture: all

> files (textual). Please mark it Multi-Arch: foreign.

Thanks, Helmut, sounds good. I will prepare a new upload of openscad-mcad
shortly and include this fix (unless you want to NMU it before that).

(Just for reference, the reason for openscad's build-dependency on
openscad-mcad is because it is used in the test suite, which is run as part
of the build. However I assume (?) that a cross build will not run the test
suite and so the build-dependency is actually redundant in this case.
However using Multi-Arch: foreign as suggested seems to be a good solution.)

 - Kristian.

Bug#933110: pkg-components: No upstream maintainer ⇒ unsuitable for Bullseye

[gregor herrmann]

On Fri, 26 Jul 2019 16:42:03 -0300, intrigeri wrote:

> > I'll file bugs against all reverse-dependencies to alert their
> > maintainer about this situation.
> 
> Done. All such bug reports are usertagged "pkg-components-removal" so
> they'll appear there shortly:
> 
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=pkg-components-removal=debian-perl%40lists.debian.org

For the affected reverse-dependencies:
The javascript team has nice instructions for using "components" with
uscan and gbp at
https://wiki.debian.org/Javascript/GroupSourcesTutorial
and I just "ported" libhtml-template-pluggable-perl:
https://salsa.debian.org/perl-team/modules/packages/libhtml-template-pluggable-perl


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#932915: RFS: qcoan/2.0-6

[Adam Borowski]

On Sat, Jul 27, 2019 at 10:00:45AM +0200, Elmar Stellnberger wrote:
> This is a strange error. I have tested the package locally on Debian 10 as
> well as on Debian 8 and Debian 9 via the OpenSuSE build service.

Well, "Debian 9" is oldstable, while all new packages must go to unstable
(and at most get backported later).  That's a difference of two major
releases (ok, maybe 1.2 releases as to-be-Bullseye is very young, although
it did already see the flurry of post-Buster upload).  No wonder the package
fails to build.

> For the obs it tests building the package in a previously empty chroot and
> installs only the packages given via the build dependencies.  Consequently
> I can exclude that there is some missing dependency.

Also, I see that that OpenSuSE build service uses some hacked up homebrewed
dependency resolution -- it likely has a different behaviour than native
Debian tools, which also may be the culprit.

> I´m afraid you will have to research what causes that error message on your
> computer.

The official archive requires all packages to be buildable on unstable using
sbuild; pbuilder may also work -- it has different defaults (notably,
doesn't strip alternative build-dependencies) but those don't apply to your
package.

I haven't started the real review yet -- just tried if it builds -- but I
already see that the -dbg package is obsolete; these are built automatically
since quite a while ago.

> > On Wed, Jul 24, 2019 at 07:02:13PM +0200, Elmar Stellnberger wrote:
> > >   * Package name: qcoan
> > > Version : 2.0-6


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄

Bug#933151: mariadb-10.3: FTBFS on riscv64

[Hector Oron]

Hello,

Missatge de Otto Kekäläinen  del dia ds., 27 de jul.
2019 a les 3:21:
>
> Package: mariadb-10.3
> X-Debbugs-CC: debian-ri...@lists.debian.org
> User: debian-ri...@lists.debian.org
> Usertags: riscv64
>
> The version of the package currently FTBFS on the riscv64 port.
>
> >From 
> >https://buildd.debian.org/status/fetch.php?pkg=mariadb-10.3=riscv64=1%3A10.3.16-1=1561225015=0
>
>
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:177:
> undefined reference to `__atomic_fetch_or_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.LVL1731':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/util/dynamic_bloom.h:179:
> undefined reference to `__atomic_fetch_or_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `SaveValue':
> ./builddir/storage/rocksdb/./storage/rocksdb/rocksdb/db/memtable.cc:596:
> undefined reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: librocksdblib.a(memtable.cc.o): in function `.L0 ':
> /usr/include/c++/8/bits/atomic_base.h:434: undefined reference to
> `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: /usr/include/c++/8/bits/atomic_base.h:434: undefined
> reference to `__atomic_compare_exchange_1'
> /usr/bin/ld: 
> librocksdblib.a(memtable.cc.o):/usr/include/c++/8/bits/atomic_base.h:434:
> more undefined references to `__atomic_compare_exchange_1' follow
> collect2: error: ld returned 1 exit status
>
> If you are an RISC expert, feel free to fork
> https://salsa.debian.org/mariadb-team/mariadb-10.3, play around, and
> make a merge request.

According to:
https://github.com/riscv/riscv-gnu-toolchain/issues/183#issuecomment-253721765

The code including atomic must link using `-latomic`, that is
apparently GCC bug, which it is not often seen in other architectures.
I have been unable to test the assumption.

Regards
-- 
 Héctor Orón  -.. . -... .. .- -.   -.. . ...- . .-.. --- .--. . .-.

Bug#931651: false positive: Match data clobbered by buffer modification hooks

[David Bremner]

David Bremner  writes:

> Nicholas D Steeves  writes:
>
>> Package: emacs-nox
>> Version: 1:26.1+1-3.2
>> Severity: normal
>> Tags: upstream
>> Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35557
>
> This bug is not docker specific, it seems.  I saw this bug today on
> zelenka, s390x porterbox. To duplicate
>
> 0) copy the notmuch-0.29.1-2 dsc to zelenka
> 1) set up a schroot session
> 2) dd-schroot-command -c  apt-get build-dep notmuch
> 3) schoot -c 
> 4) depkg-buildpackage -us -us -b

the above reproducer sequence can be simplified to

0) set up a sid chroot on zelenka
1) install emacs-nox in that chroot
2) run the sample elisp code per the first message in the bug.

d

Bug#931651: false positive: Match data clobbered by buffer modification hooks

[David Bremner]

Nicholas D Steeves  writes:

> Package: emacs-nox
> Version: 1:26.1+1-3.2
> Severity: normal
> Tags: upstream
> Forwarded: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35557

This bug is not docker specific, it seems.  I saw this bug today on
zelenka, s390x porterbox. To duplicate

0) copy the notmuch-0.29.1-2 dsc to zelenka
1) set up a schroot session
2) dd-schroot-command -c  apt-get build-dep notmuch
3) schoot -c 
4) depkg-buildpackage -us -us -b

Bug#931386: stretch-pu: package fribidi/0.19.7-1.1

[Jonathan Wiltshire]

On Wed, Jul 03, 2019 at 07:36:55PM +0200, Samuel Thibault wrote:
> As reported on #917909, the text-based debian installer support for
> right-to-left languages is completely broken, only due to a path
> mismatch. This was fixed in Buster in January with the attached change,
> which I have uploaded to stretch as 0.19.7-1.1, could you accept it?

That's an unusual version; did you mean to +deb9u1 it instead?

-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#931386: stretch-pu: package fribidi/0.19.7-1.1

[Jonathan Wiltshire]

On Mon, Jul 22, 2019 at 05:19:56AM +0200, Cyril Brulebois wrote:
> Jonathan Wiltshire  (2019-07-21):
> > On Wed, Jul 03, 2019 at 07:36:55PM +0200, Samuel Thibault wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > Tags: stretch
> > > User: release.debian@packages.debian.org
> > > Usertags: pu
> > > 
> > > Hello,
> > > 
> > > As reported on #917909, the text-based debian installer support for
> > > right-to-left languages is completely broken, only due to a path
> > > mismatch. This was fixed in Buster in January with the attached change,
> > > which I have uploaded to stretch as 0.19.7-1.1, could you accept it?
> > 
> > Looks OK to me, d-i ack needed.
> 
> No objections to the actual diff (as received following your upload), as
> opposed to the attached diff (which is a src:xorg-server patch by the
> looks of it). ;p
> 
> Attaching the actual diff for further reference.

Well this is deeply embarassing; I don't know what diff I reviewed but it
wasn't that one... Anyway, I will take a look in a moment.


-- 
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#933229: [Pkg-javascript-devel] Bug#933229: yarnpkg: Cannot find module 'babel-runtime/helper/asyncToGenerator'

[Pirate Praveen]

Control: severity -1 wishlist

On 2019, ജൂലൈ 28 1:48:56 AM IST, Christoph Schulz 
 wrote:
>Package: yarnpkg
>Version: 1.13.0-1
>Severity: grave
>Justification: renders package unusable
>
>
>Dear Maintainer,
>
>it seems like the yarnpkg executable is broken somehow.
>
>Please see below for the full error. I will resort to the installation
>method
>from the yarn site for now. [1]
>
>I have installed nodejs from nodesource[2], that could be related to
>the issue.
>

This is indeed the issue. Try with 
export NODE_PATH=/usr/lib/nodejs:/usr/share/nodejs

If this works, please close the bug.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#933239: sagan: fails to start: Cannot open rule file /etc/sagan-rules/windows-security.rules

[Jonas Smedegaard]

Package: sagan
Version: 1.2.0-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Included conffile have sagan attempt to load 
/etc/sagan-rules/windows-security.rules which is not provided by required 
version of sagan-rules, causing sagan to fail to start.

A dirty workaround is to run "touch /etc/sagan-rules/windows-security.rules".


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl082NIACgkQLHwxRsGg
ASGysBAArtS+Yme3xMwoWE66iqhN1Yew2/+n6ttucBUiKhWv37Yx2n377tOtM35o
Jq7nf9EbkMZM07xraCZKZ0kstjSLGvtzXP4iwHzuRFq//k7fKzk+FIs5/4tZMyc1
O5Wg9Y8yomfUV1QrFZA02+2CMyUp3WtOXkE8mpQYCYMGkHWLkaISQ8VyFmM4Xi8s
DASOEKT7+Fvigc+88l7vJYKkVihFBZ24URYmCmA7m9yFyI/ezFQTWXh/mAPUldXg
liSiL75pZp5NydTy0qGldvMbEu9VQDrqTezh9nj6fmTnPuHUUawU+rUyLhRzRzx6
xEsUYNKtFatyIZjVhnL7NODo3maQx+GJyPOb1Men/B/S6DHxlaDmndNiFqY3xvSJ
T3JSTrheqzD/GcGUyH9bObZ0tP7xDBxhzoz2/51phEz2zBvjeGlm1KCeu8dNUSE0
t/erwDUNony6OUWQKW0fHY44MVb24rh1+EQXXcShVCK85GwgTBa8PXHcKkzl9QEL
5ib1KC7TlK17DsPj5X4w4uI+ual4taa4qcIObQqeZC+YVZQ6TCR+AKrA9BWspwEw
JJfe2HRA503R7h2qZbZPwExojCif9bU0qCFU5DEHYaApVCTdhGEn1aUHYrLgiTHL
YXdeGHq/FXHxSQCTPJlUo6xYPa3zzJ8OseDNuIgdIpDgds1ga/g=
=aciS
-END PGP SIGNATURE-

Bug#933238: ITP: r-cran-qpdf -- GNU R split, combine and compress PDF files

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-qpdf -- GNU R split, combine and compress PDF files
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-qpdf
  Version : 1.1
  Upstream Author : Jeroen Ooms,
* URL : https://cran.r-project.org/package=qpdf
* License : MIT
  Programming Lang: GNU R
  Description : GNU R split, combine and compress PDF files
 Content-preserving transformations transformations of PDF files such
 as split, combine, and compress. This package interfaces directly to the 'qpdf'
 C++ API and does not require any command line utilities. Note that 'qpdf' does
 not read actual content from PDF files: to extract text and data you need the
 'pdftools' package.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-qpdf

Bug#933237: ITP: r-cran-gridgraphics -- GNU R redraw base graphics using 'grid' graphics

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-gridgraphics -- GNU R redraw base graphics using 'grid' 
graphics
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-gridgraphics
  Version : 0.4
  Upstream Author : Paul Murrell,
* URL : https://cran.r-project.org/package=gridGraphics
* License : MIT
  Programming Lang: GNU R
  Description : GNU R redraw base graphics using 'grid' graphics
 Functions to convert a page of plots drawn with the
 'graphics' package into identical output drawn with the 'grid' package.
 The result looks like the original 'graphics'-based plot, but consists
 of 'grid' grobs and viewports that can then be manipulated with
 'grid' functions (e.g., edit grobs and revisit viewports).

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-gridgraphics

Bug#931965: squashfs-tools-ng falsehoods and dafamation of myself the Squashfs maintainer

[Phillip Lougher]

Debiian distro

I object to the following claims made by squashfs-tools-ng and I consider it
libellous.


>
>Dear Maintainer,
>
>
>The package squashfs-tools has not been developed and
>maintained by its upstream for more than 5 years.

This is untrue and a slander

I already asked squashfs-tools-ng to remove their libel from their package:

https://github.com/AgentD/squashfs-tools-ng/issues/10

I am posting here to clarify the issue and prevent this falsehood from
spreading.

Dr Phillip Lougher
Squashfs Author and Mainatainer

>However, a newer package "squashfs-tools-ng" is available:
>https://sourceforge.net/p/squashfs/mailman/message/36709721/
>This squashfs-like package is required for Debian live and its derivatives.
>It would be great if squashfs-tools-ng can be available in the Debian

Bug#927731: epiphany-browser/i386: private libdazzle not loaded

[積丹尼 Dan Jacobson]

Why don't you guys use a different name for your special load.

I don't think there is any other example on Debian where this kind of
thing you are doing has been used.

And has been used successfully.

Just don't use the same name...

go into the sources, change whatever your using's name. Call it a
different name... problem solved.

$ epiphany $@
Error loading module 
'/usr/lib/x86_64-linux-gnu/epiphany-browser/web-extensions/libephywebextension.so':
 libdazzle-1.0.so.0: cannot open shared object file: No such file or directory

Bug#933236: ssmtp stopped working after upgrade from stretch to buster

[Mariusz Bialonczyk]

Package: ssmtp
Version: 2.64-8+b2
Severity: important

Dear Maintainer,
SSMTP stopped working (configured for gmail) after upgrade from stretch to 
buster
I can see the following differences in the /var/log/mail.info:

A working mail (before upgrade):
Jul 23 17:12:03 my_host sSMTP[14443]: Creating SSL connection to host
Jul 23 17:12:03 my_host sSMTP[14443]: SSL connection using RSA_AES_128_CBC_SHA1
Jul 23 17:12:06 my_host sSMTP[14443]: Sent mail for xx...@gmail.com (221 2.0.0 
closing connection b27sm8069499ljb.11 - gsmtp) uid=0 username=root outbytes=469

and after upgrade:
Jul 23 19:37:07 my_host sSMTP[27845]: Creating SSL connection to host
Jul 23 19:37:07 my_host sSMTP[27845]: SSL connection using 
ECDHE_RSA_AES_256_GCM_SHA384
Jul 23 19:37:07 my_host sSMTP[27845]:  ()

seding from commandline:
/etc/ssmtp/ echo -n 'Subject: test\n\nTesting ssmtp' | sendmail -v 
x...@gmail.com
[<-] 220 smtp.gmail.com ESMTP w1sm12952635ljm.81 - gsmtp
[->] EHLO XX
[<-] 250 SMTPUTF8
[->] STARTTLS
[<-] 220 2.0.0 Ready to start TLS
[->] EHLO X
[<-] 
sendmail:  ()

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

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

Versions of packages ssmtp depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libgnutls-openssl273.6.7-4

ssmtp recommends no packages.

ssmtp suggests no packages.

-- Configuration Files:
/etc/ssmtp/ssmtp.conf:
root=x...@gmail.com
mailhub=smtp.gmail.com:587
rewriteDomain=gmail.com
hostname=X
FromLineOverride=NO
AuthUser=x...@gmail.com
AuthPass=X
UseTLS=YES
UseSTARTTLS=YES

/etc/ssmtp/revaliases:
root:...@gmail.com:smtp.gmail.com:587

-- debconf information excluded

regards,
-- 
Mariusz Białończyk | xmpp/e-mail: ma...@skyboo.net
http://manio.skyboo.net | https://github.com/manio

Bug#926401: initramfs-tools: update-initramfs -k all -c does not create initrd images anymore

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 04 Apr 2019 15:05:57 +0200 Marc Lehmann  
wrote:
> Package: initramfs-tools
> Version: 0.130
> Severity: normal
> 
> Dear Maintainer,
> 
> between versions 0.130 and 0.133 the behaviour of update-initramfs -k all
> -c changes considerably. In 0.130, this command would generate initrd
> images for all kernels, in 0.133, it is a nop.

Not quite.  In older versions, "-k all" would apply to every initramfs
image that initramfs-tools remembered generating (as recorded in
/var/lib/initramfs-tools).

> The reason is that get_sorted_versions now only lists kernels with
> existing initrd images, which makes the -c option somewhat useless.

Yes, though I can't see how the previous behaviour was useful either. 
Do you delete existing initramfs images, using something other than
"update-initramfs -d", before you run "update-initramfs -k all -c"?

> At least in our case this created unbootable systems after an upgrade to
> buster.

Ben.
 
-- 
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.



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

Bug#933235: ITP: fast -- framework for Heterogeneous Medical Image Computing

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: fast -- framework for Heterogeneous Medical Image Computing
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: fast
  Version : 3.0.0
  Upstream Author : Norwegian University of Science and Technology
* URL : https://github.com/smistad/FAST
* License : BSD-2-Clause
  Programming Lang: C
  Description : framework for Heterogeneous Medical Image Computing
 An open-source cross-platform framework with the main goal of making it
 easier to do processing and visualization of medical images on
 heterogeneous systems (CPU+GPU). Has data streaming, deep learning, high-
 level data management, high-performance algorithms, interoperability
 with Insight Toolkit & integration with existing VTK / Qt applications
 as well as a fast concurrent visualization.

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

Bug#932678: glib2.0: tests timeout on i386 and mips

[Aurelien Jarno]

On 2019-07-26 23:39, Simon McVittie wrote:
> > On mips, the gvariant test timed out.
> 
> This is failing a fuzz-test that randomly modifies binary data and
> tries to parse it. I thought it might be reaching some pathological
> case where the parser breaks, but no - it looks like the actual problem
> is that g_random_double_range() is really slow on at least some mips
> hardware (repeatedly calling g_random_double_range() in a loop is 100
> times as fast on my laptop as on the porterbox minkus, which according
> to db.debian.org is the same EdgeRouter Pro hardware as mips-aql-01,
> the buildd where this test timed out).
> 
> mips porters: Is this something that is expected to be so slow? The
> same test took 60 seconds (so at least 6 times as fast) on mips-sil-01,
> which is apparently a Rhino Labs UTM8 with a somewhat newer CPU.
> For comparison, it took 8 seconds on the i386 buildd.

The UTM8 based buildds like mips-sil-01 are much faster than the
mips-aql-0{1,2,4,5} buildds, and also have an FPU, although I am not
sure it plays a role here.

After giving back this package, it built successfully on mips-manda-01.
I have therefore blacklisted glib2.0 from the slowest buildds.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#711984:

[José Carlos Cabau]

$500,000 has been donated to you by frank and laura rivera. Email: 
frankandlaurariv...@yandex.com for more details

Bug#933221: openarena: suggestion to make openarena -players-mature optional

[Tom Goulet]

On Sat, Jul 27, 2019 at 07:42:52PM +0100, Simon McVittie wrote:
> On Sat, 27 Jul 2019 at 13:01:48 -0400, Tom Goulet wrote:
> > I was hoping to get openarena installed, but without the -mature package.
> This was possible in OpenArena 0.8.1, but it can't actually work since
> 0.8.5 because of the way the 0.8.5 and 0.8.8 patches were structured.

> I've tried to explain this in the package description without making it
> too long:
> 
> In OpenArena 0.8.1 these player models were optional, but the
> structure of the 0.8.5 patch means they cannot be removed from 0.8.5
> or later versions.
> 
> If you have suggestions for better wording I'd be happy to consider them.

I read that, but I guess I didn't take it in.  I think I possibly didn't realise
that the sentence applies to the current version.  It says 081 in the package
name, so I assumed I was using that version.  Possibly you could say, "The
structure of OpenArena has changed this version, and the openarena package
cannot be installed without this package.  This applies to the current version,
which is 0.8.5, even though it says openarena-081- in the package names."
 
> With or without these "mature"[1] player models, OpenArena is rather violent
> (it's a Free Software clone of Quake III Arena), so I wouldn't recommend
> it for children in any case.

Yeah, that's a whole separate debate, but I'm satisfied with your answer.

I was hoping that the wishlist bug report would have some worth in the BTS
anyway, if only for a discussion like this.

Thanks for your competent and helpful reply.

Tom

Bug#933234: python3-memory-profiler: recommend python3-matplotlib for python3-mprof plot

[Jochen Sprickerhof]

Package: python3-memory-profiler
Version: 0.52-1
Severity: normal

On a system without python3-matplotlib I get:

# python3-mprof plot
matplotlib is needed for plotting.
No module named 'pylab'

I would propose to add python3-matplotlib to the Recommends section as
other subcommands of python3-mprof do work.

(I guess this should be the same for python-memory-profiler, but Python
2 is EOL..)

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

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

Versions of packages python3-memory-profiler depends on:
ii  python3 3.7.3-1
ii  python3-psutil  5.5.1-1

python3-memory-profiler recommends no packages.

python3-memory-profiler suggests no packages.

-- no debconf information

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Jonathan McDowell]

On Sat, Jul 27, 2019 at 10:40:00PM +0100, Ian Jackson wrote:
> Jonathan McDowell writes ("Bug#932753: tag2upload should record git tag 
> signer info in .dsc [and 1 more messages]"):
> > My understanding is this was true in the days of v3 keys/fingerprints
> > but is not the case for v4. If we get to the point we find a collision
> > then that's a SHA1 issue that's going to cause bigger issues.
> 
> It would be good to prepare for changing the fingerprint hash
> function.  Would including these parameters do that ?  I think it
> would, provided that "hash-algo" is in fact the algorithm used for the
> fingerprint hash.
> 
> An alternative, perhaps, is to leave this out now, and intend to
> introduce a `fingnerprintv5' value later.

A v5 fingerprint is SHA256 based and 32 bytes (64 ASCII characters)
long.

J.

-- 
Beware of programmers carrying screwdrivers.
This .sig brought to you by the letter X and the number 23
Product of the Republic of HuggieTag

Bug#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Ian Jackson]

Jonathan McDowell writes ("Bug#932753: tag2upload should record git tag signer 
info in .dsc [and 1 more messages]"):
> My understanding is this was true in the days of v3 keys/fingerprints
> but is not the case for v4. If we get to the point we find a collision
> then that's a SHA1 issue that's going to cause bigger issues.

It would be good to prepare for changing the fingerprint hash
function.  Would including these parameters do that ?  I think it
would, provided that "hash-algo" is in fact the algorithm used for the
fingerprint hash.

An alternative, perhaps, is to leave this out now, and intend to
introduce a `fingnerprintv5' value later.

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#932753: tag2upload should record git tag signer info in .dsc [and 1 more messages]

[Jonathan McDowell]

On Fri, Jul 26, 2019 at 09:18:29PM +0100, Sean Whitton wrote:
> For the purposes of tag2upload work, would you mind confirming this:
> 
> On Tue 23 Jul 2019 at 06:38AM +01, Sean Whitton wrote:
> 
> > AIUI a fingerprint fails to uniquely identify a PGP key unless you also
> > include the cryptographic algorithm that was used and the key size.  So
> > for example, my current key is uniquely identified by writing both 4096R
> > and 8DC2487E51ABDD90B5C4753F0F56D0553B6D411B.
> >
> > Even though it's unlikely we'll get a clash of fingerprints within the
> > Debian keyring, it seems the algorithm and keysize ought to be included
> > alongside the fingerprint, if the above is right.

My understanding is this was true in the days of v3 keys/fingerprints
but is not the case for v4. If we get to the point we find a collision
then that's a SHA1 issue that's going to cause bigger issues.

J.

-- 
] https://www.earth.li/~noodles/ []  I'm absolutely  [
]  PGP/GPG Key @ the.earth.li[]  convinced one day soon I'm going  [
] via keyserver, web or email.   [] to get "masturbation" and  [
] RSA: 4096/0x94FA372B2DA8B985   []   "meditation" mixed up.   [

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

[intrigeri]

Hi again,

intrigeri:
> I'm very glad I was mislead. It looks like Dpkg::Changelog{,::*} are
> sufficient for many, if not most, use cases of Parse::DebianChangelog :)

Hoping it will help other affected folks go through this transition,
here are MRs that give examples about how some code can be ported to
Dpkg::Changelog:

  
https://salsa.debian.org/perl-team/modules/packages/dh-make-perl/merge_requests/1
  
https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/merge_requests/4

Cheers,
-- 
intrigeri

Bug#933233: aewm FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: aewm
Version: 1.3.12-5
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

aewm fails to cross build from source, because the upstream Makefile
hard codes the build architecture pkg-config. The attached patch makes
pkg-config substitutable. Please consider applying it.

Helmut
--- aewm-1.3.12.orig/Makefile
+++ aewm-1.3.12/Makefile
@@ -1,6 +1,8 @@
 # aewm - Copyright 1998-2007 Decklin Foster .
 # This program is free software; see LICENSE for details.
 
+PKG_CONFIG ?= pkg-config
+
 # Set this to the location where you want to install
 DESTDIR =
 XROOT = /usr
@@ -10,8 +12,8 @@
 OPT_WMLIB += -lXext
 
 # Uncomment to add Xft support
-OPT_WMFLAGS += -DXFT `pkg-config --cflags xft`
-OPT_WMLIB += `pkg-config --libs xft` -lXext
+OPT_WMFLAGS += -DXFT `$(PKG_CONFIG) --cflags xft`
+OPT_WMLIB += `$(PKG_CONFIG) --libs xft` -lXext
 
 # Uncomment for debugging (abandon all hope, ye who enter here)
 #OPT_WMFLAGS += -DDEBUG
@@ -46,7 +48,7 @@
 
 X11FLAGS = -I$(XROOT)/include
 WMFLAGS = $(X11FLAGS) $(OPT_WMFLAGS)
-GTKFLAGS = `pkg-config --cflags gtk+-2.0`
+GTKFLAGS = `$(PKG_CONFIG) --cflags gtk+-2.0`
 
 $(PLAINOBJ): %.o: %.c
 	$(CC) $(CPPFLAGS) $(CFLAGS) -c $< -o $@
@@ -62,7 +64,7 @@
 
 X11LIB = -L$(XROOT)/lib -lX11
 WMLIB = $(X11LIB) $(OPT_WMLIB)
-GTKLIB = `pkg-config --libs gtk+-2.0` -lX11
+GTKLIB = `$(PKG_CONFIG) --libs gtk+-2.0` -lX11
 
 $(PLAINBIN): %: %.o
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $^ -o $@

Bug#933232: upx-ucl: CVE-2019-14295 CVE-2019-14296

[Salvatore Bonaccorso]

Source: upx-ucl
Version: 3.95-1
Severity: normal
Tags: security upstream

Hi,

The following vulnerabilities were published for upx-ucl.

CVE-2019-14295[0]:
| An Integer overflow in the getElfSections function in p_vmlinx.cpp in
| UPX 3.95 allows remote attackers to cause a denial of service (crash)
| via a skewed offset larger than the size of the PE section in a UPX
| packed executable, which triggers an allocation of excessive memory.


CVE-2019-14296[1]:
| canUnpack in p_vmlinx.cpp in UPX 3.95 allows remote attackers to cause
| a denial of service (SEGV or buffer overflow, and application crash)
| or possibly have unspecified other impact via a crafted UPX packed
| file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-14295
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14295
https://github.com/upx/upx/issues/286
[1] https://security-tracker.debian.org/tracker/CVE-2019-14296
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14296
https://github.com/upx/upx/issues/287

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#933132: dh-make-perl: depends on libparse-debianchangelog-perl that has no upstream maintainer

[intrigeri]

Control: tag -1 + patch

https://salsa.debian.org/perl-team/modules/packages/dh-make-perl/merge_requests/1

Bug#933231: exim4-base: /etc/cron.daily/exim4-base can't detect hostname via hostname --fqdn

[Christian Garbs]

Package: exim4-base
Version: 4.92-8+deb10u1
Severity: normal
Tags: ipv6

After the update from Stretch to Buster, on one of my systems
/etc/cron.daily/exim4-base failed on every run with just

hostname: Name or service not known

as an error message.

I could trace this to the usage of "hostname --fqdn" in the script.
On this (and so far only on this) system this call simply fails:

$ hostname --fqdn
hostname: Name or service not known

The manpage of hostname(1) warns about the --fqdn option:

| If a machine has multiple network interfaces/addresses or
| is used in a mobile environment, then it may either have
| multiple FQDNs/domain names or none at  all.  Therefore
| avoid using hostname --fqdn, hostname --domain and dnsdomainname.
| hostname --ip-address is subject to the same limitations
| so it should be avoided as well.

I don't yet know why, but I indeed have two hostnames:

$ hostname --all-fqdns
het.cgarbs.de het.cgarbs.de 

I guess one is for the IPv4 connection and the other for IPv6.


Because in my case both entries are the same and the cron.daily
script only needs one, I created a shell function that returns
only the first hostname and added it to the top of the cron.daily
script (see attached changed config file below):

# fix multiple hostnames, see warning about THE FQDN in hostname(1)
hostname()
{
/bin/hostname --all-fqdns | tr " " "\n" | grep -F . | sort | uniq | head -n 
1
}


The shell function takes precedence over /bin/hostname and everything
works as expected.

Unfortunately, the hostname(1) manpage says "Do not make any assumptions
about the order of the output." regarding the --all-fqdns option.



So while using the shell function might be a partial fix, it is not a
very good one.

Is there another way to get a proper hostname, perhaps from Exim
or the Exim configuration, that can be used in /etc/cron.daily/exim4-base
instead of calling "hostname --fqdn"?


Regards
Christian

-- Package-specific info:
Exim version 4.92 #3 built 20-Jul-2019 11:35:58
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DANE DKIM DNSSEC Event OCSP PRDR PROXY 
SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa tls
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb fsecure sophie clamd avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is 
/etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='internet'
dc_other_hostnames='cgarbs.de'
dc_local_interfaces='0.0.0.0.25 ; ::0.25'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='true'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

mailname:cgarbs.de
# /etc/default/exim4
EX4DEF_VERSION=''

# 'combined' -   one daemon running queue and listening on SMTP port
# 'no'   -   no daemon running the queue
# 'separate' -   two separate daemons
# 'ppp'  -   only run queue with /etc/ppp/ip-up.d/exim4.
# 'nodaemon' - no daemon is started at all.
# 'queueonly' - only a queue running daemon is started, no SMTP listener.
# setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4
QUEUERUNNER='combined'
# how often should we run the queue
QUEUEINTERVAL='30m'
# options common to quez-runner and listening daemon
COMMONOPTIONS=''
# more options for the daemon/process running the queue (applies to the one
# started in /etc/ppp/ip-up.d/exim4, too.
QUEUERUNNEROPTIONS=''
# special flags given to exim directly after the -q. See exim(8)
QFLAGS=''
# Options for the SMTP listener daemon. By default, it is listening on
# port 25 only. To listen on more ports, it is 

Bug#933230: acpid: Race during startup can result in event devices not being opened

[anomie]

Package: acpid
Version: 1:2.0.31-2

When using netlink and the input layer, acpid opens the existing devices
in /dev/input/event* first and only after sets an inotify to be told
about newly created devices. If an event device is created between the
time acpid reads the directory and the time it sets the inotify, it
won't open that device and events provided by that device will be lost.

On my system, this race happens frequently for /dev/input/event8 "Video
Bus" during boot, preventing acpid from handling my system's brightness
keys.

The attached patch changes the ordering, setting the inotify before
opening the existing devices. It also adds a check to prevent
double-opening of a device if it is created between the inotify and the
reading of the directory.
diff -urN acpid-2.0.31-old/acpid.c acpid-2.0.31/acpid.c
--- acpid-2.0.31-old/acpid.c	2018-03-29 11:05:57.252312727 -0400
+++ acpid-2.0.31/acpid.c	2019-07-27 15:48:34.468992622 -0400
@@ -99,12 +99,12 @@
 	}
 
 	if (netlink) {
-		/* open the input layer */
-		open_input();
-
 		/* watch for new input layer devices */
 		open_inotify();
 
+		/* open the input layer */
+		open_input();
+
 		/* open netlink */
 		open_netlink();
 	}
diff -urN acpid-2.0.31-old/input_layer.c acpid-2.0.31/input_layer.c
--- acpid-2.0.31-old/input_layer.c	2018-08-01 10:11:59.934141098 -0400
+++ acpid-2.0.31/input_layer.c	2019-07-27 15:50:55.725832853 -0400
@@ -490,6 +490,12 @@
 	for (i = 0; i < globbuf.gl_pathc; ++i) {
 		filename = globbuf.gl_pathv[i];
 
+		/* skip if already opened */
+		if (find_connection_name(filename) != NULL) {
+			success = 1;
+			continue;
+		}
+
 		/* open this input layer device file */
 		if (open_inputfile(filename) == 0)
 			success = 1;

Bug#933229: yarnpkg: Cannot find module 'babel-runtime/helper/asyncToGenerator'

[Christoph Schulz]

Package: yarnpkg
Version: 1.13.0-1
Severity: grave
Justification: renders package unusable


Dear Maintainer,

it seems like the yarnpkg executable is broken somehow.

Please see below for the full error. I will resort to the installation method
from the yarn site for now. [1]

I have installed nodejs from nodesource[2], that could be related to the issue.

Kind Regards,
Christoph

[1] https://yarnpkg.com/en/docs/install/#debian-stable
[2] https://github.com/nodesource/distributions/blob/master/README.md#debmanual

$ yarnpkg
internal/modules/cjs/loader.js:628
throw err;
^

Error: Cannot find module 'babel-runtime/helpers/asyncToGenerator'
Require stack:
- /usr/lib/nodejs/yarn/lib/cli/index.js
- /usr/lib/nodejs/yarn/bin/yarn.js
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:625:15)
at Function.Module._load (internal/modules/cjs/loader.js:527:27)
at Module.require (internal/modules/cjs/loader.js:683:19)
at require (internal/modules/cjs/helpers.js:16:16)
at _load_asyncToGenerator (/usr/lib/nodejs/yarn/lib/cli/index.js:11:54)
at /usr/lib/nodejs/yarn/lib/cli/index.js:15:41
at Object. (/usr/lib/nodejs/yarn/lib/cli/index.js:574:3)
at Module._compile (internal/modules/cjs/loader.js:777:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:788:10)
at Module.load (internal/modules/cjs/loader.js:643:32) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/usr/lib/nodejs/yarn/lib/cli/index.js',
'/usr/lib/nodejs/yarn/bin/yarn.js'
  ]
}


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

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

Versions of packages yarnpkg depends on:
ii  node-asap  2.0.6-1
ii  node-babel-runtime 6.26.0+dfsg-3
ii  node-bytes 3.0.0-1
ii  node-camelcase 5.0.0-1
ii  node-chalk 2.3.0-2
ii  node-chownr1.1.1-1
ii  node-ci-info   1.1.2-1
ii  node-cli-table 0.3.1-1
ii  node-commander 2.12.2-3
ii  node-death 1.0.0-1
ii  node-debug 3.1.0-2
ii  node-deep-equal1.0.1-1
ii  node-detect-indent 5.0.0-1
ii  node-duplexify 3.6.1-1
ii  node-emoji 1.8.1-1
ii  node-fast-levenshtein  2.0.5-1
ii  node-glob  7.1.3-2
ii  node-imports-loader0.7.1-1
ii  node-ini   1.3.5-1
ii  node-inquirer  3.3.0-2
ii  node-invariant 2.2.2-1
ii  node-is-builtin-module 2.0.0-1
ii  node-loud-rejection1.6.0-1
ii  node-micromatch2.3.11-1
ii  node-minimatch 3.0.4-3
ii  node-mkdirp0.5.1-1
ii  node-node-uuid 3.3.2-2
ii  node-object-path   0.11.4-2
ii  node-proper-lockfile   2.0.1-1
ii  node-puka  1.0.0+dfsg-1
ii  node-pump  3.0.0-1
ii  node-pumpify   1.5.1-1
ii  node-read  1.0.7-1
ii  node-request   2.88.1-2
ii  node-request-capture-har   1.2.2-1
ii  node-resolve   1.5.0-1
ii  node-rimraf2.6.2-1
ii  node-semver5.5.1-1
ii  node-ssri  5.2.4-2
ii  node-strip-ansi4.0.0-1
ii  node-strip-bom 3.0.0-1
ii  node-tar-stream1.5.2-1
ii  node-validate-npm-package-license  3.0.1-1
ii  node-yn3.0.0-1
ii  nodejs 12.7.0-1nodesource1

yarnpkg recommends no packages.

yarnpkg suggests no packages.

-- no debconf information

Bug#933228: linux-image-4.19.0-5-arm64: Please enable CONFIG_VIDEO_BCM2835=m

[Reco]

Package: src:linux
Version: 4.19.37-5
Severity: wishlist

Dear Maintainer,

Raspberry Pi3, from which I write this bugreport, is a popular SoC that finally 
got a proper support by Debian project.
It would be nice to have a kernel module for the camera host interface, which 
is included into Debian's kernel source tree, but is currently disabled.
Tainted status of the current kernel comes from self-built bcm2835_v4l2.

Sincerely yours, Reco


-- Package-specific info:
** Version:
Linux version 4.19.0-5-arm64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-5 (2019-06-19)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-arm64 root=/dev/mapper/pi2-root ro quiet

** Tainted: COE (13312)
 * Module from drivers/staging has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
Device Tree model: Raspberry Pi 3 Model B Plus Rev 1.3

** Loaded modules:
dm_snapshot
dm_bufio
cbc
cts
rpcsec_gss_krb5
nfsv4
dns_resolver
nfs
lockd
grace
fscache
nls_ascii
nls_cp437
vfat
fat
8021q
garp
mrp
stp
llc
ip6_tables
ip6t_REJECT
nf_reject_ipv6
xt_mac
nft_counter
ipt_REJECT
nf_reject_ipv4
xt_hashlimit
xt_tcpudp
xt_conntrack
nf_conntrack
nf_defrag_ipv6
nf_defrag_ipv4
libcrc32c
xt_comment
nft_compat
nf_tables
nfnetlink
btsdio
bluetooth
drbg
ansi_cprng
microchip
ecdh_generic
brcmfmac
lan78xx
brcmutil
of_mdio
cfg80211
fixed_phy
libphy
rfkill
bcm2835_thermal
bcm2835_rng
rng_core
efi_pstore
bcm2835_wdt
leds_gpio
efivars
bcm2835_v4l2(OE)
vchiq(C)
v4l2_common
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
auth_rpcgss
videodev
sunrpc
media
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
aes_arm64
dm_mod
dwc2
udc_core
usbcore
sdhci_iproc
sdhci_pltfm
sdhci
usb_common
bcm2835
phy_generic
fixed

** PCI devices:
not available

** USB devices:
Bus 001 Device 004: ID 0424:7800 Standard Microsystems Corp. 
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: 10.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages linux-image-4.19.0-5-arm64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.133
ii  kmod26-1
ii  linux-base  4.6

Versions of packages linux-image-4.19.0-5-arm64 recommends:
ii  apparmor 2.13.2-10
ii  firmware-linux-free  3.4

Versions of packages linux-image-4.19.0-5-arm64 suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.19  

Versions of packages linux-image-4.19.0-5-arm64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#874025: Bug#881034: Galera-3 default configuration; nodes beyond primary will not connect

[Otto Kekäläinen]

Control: close -1

There was no further input from reporter, thus closing issue.

Bug#932755: sdl-image1.2: multiple security issues

[Felix Geyer]

Hi Hugo,

On 27.07.19 19:39, Hugo Lefeuvre wrote:

Dear SDL packages maintainers,

I have uploaded the jessie LTS update.

I will coordinate with the security team for stretch and buster fixes via
point release.

Concerning testing: can I upload the NMU?


Sure, please go ahead!

Cheers,
Felix

Bug#933227: dh-make-perl: t/dists.t fails if $NO_NETWORK is not set

[intrigeri]

Package: dh-make-perl
Version: 0.106
Severity: normal

Hi,

since commits 52758d4 and 8f31263, depending on whether we allow the
dh-make-perl test suite to use the network or not (which is determined
by $NO_NETWORK), when run by t/dists.t, it will either reformat
debian/* with cme or not, and then the resulting files differ.

The expected output of the test suite is what we get under
NO_NETWORK=1 and there the tests pass. But when $NO_NETWORK is not
set, the output differs and some tests fail.

Is there a smarter way to fix that, than duplicating each
t/dists/Strange-*/wanted-debian* that differs depending on
$NO_NETWORK?

Cheers,
-- 
intrigeri

Bug#933226: notion: homepage moved to https://notionwm.net/

[Patrice Duroux]

Source: notion
Severity: minor

Dear Maintainer,

and the upstream VCS is there:
https://github.com/raboof/notion

Thanks,
Patrice



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 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

Bug#923914: Is the font package used in debian installer?

[Samuel Thibault]

Tarun Kumar, le dim. 28 juil. 2019 00:26:03 +0530, a ecrit:
> The package is used in debian installer or not?

Yes, but apparently it takes it from the bf-utf package, not from the
unifont package.

Samuel

Bug#933225: Request for a debian-latinoamerica mailing list

[Santiago R.R.]

Package: lists.debian.org
Severity: wishlist

I am filing this bug on behalf of the people that participated in the
Debian Latin America y Caribe Meeting during DC19 [0,1].

[0] https://debconf19.debconf.org/talks/162-latin-america-y-caribe-meeting/
[1] https://pad.riseup.net/p/dc19latin-keep

Name: debian-latinoamerica

Rationale

The Debian communities in the different Latin American countries
have their own mailing list/communication media. We think that a
common and multilingual mailing list would be very useful to
coordinate activities and strenght links among the different
countries.

Short Description: Debian in Latin America

Long description

Multi-lingual mailing list to discuss different topics relating
to Debian the Latin America countries.

Category: users

Subscription Policy: open

Post Policy: open

Web Archive: yes

Please, create a mailing list for the Latin American Debian community.

Cheers,

 -- Santiago


signature.asc
Description: PGP signature

Bug#805108: freedombox-setup: [PATCH] Enable zram

[James Valleroy]

retitle 805108 freedombox: integrate zram-tools
thanks

The zram swap service is now packaged as zram-tools.



signature.asc
Description: OpenPGP digital signature

Bug#923914: Is the font package used in debian installer?

[Tarun Kumar]

The package is used in debian installer or not?


signature.asc
Description: PGP signature

Bug#933221: openarena: suggestion to make openarena -players-mature optional

[Simon McVittie]

Control: tags -1 + upstream wontfix

On Sat, 27 Jul 2019 at 13:01:48 -0400, Tom Goulet wrote:
> I was hoping to get openarena installed, but without the -mature package.

This was possible in OpenArena 0.8.1, but it can't actually work since
0.8.5 because of the way the 0.8.5 and 0.8.8 patches were structured. The
patches contain updates to some of the player models found in the -mature
package, which mean the directory containing those models exists, which is
how the game engine decides which player models should be made available
- but because some of them rely on files from the -mature package, the
player model will be invisible (!) which needless to say makes the game
rather unfair.

It isn't straightforward to fix this as a Debian-specific patch either,
because that would make Debian clients incompatible with upstream
servers (the Quake III Arena engine checks for matching data files during
connection to a server), which is undesirable for a multiplayer-focused
game. So I'm afraid this probably has to be "won't fix".

Even in 0.8.1, removing the -mature package never worked very well,
because in practice multiplayer servers have it, so connecting from
a client that doesn't have it will trigger the check for mismatched
data files and cause connection to fail.

I've tried to explain this in the package description without making it
too long:

In OpenArena 0.8.1 these player models were optional, but the
structure of the 0.8.5 patch means they cannot be removed from 0.8.5
or later versions.

If you have suggestions for better wording I'd be happy to consider them.

> Myself, and some people with whom I'd like to share Linux, have reasons to not
> allow nudity, partial or not, for personal or religious reasons.  Also there
> are children that use Debian and descended distributions, and I'd like them to
> use free software, too.

With or without these "mature"[1] player models, OpenArena is rather violent
(it's a Free Software clone of Quake III Arena), so I wouldn't recommend
it for children in any case.

smcv

[1] or immature, depending on your point of view - the package name
reflects upstream's naming for pak2-players-mature.pk3 rather than
being a value-judgement by its Debian maintainers

Bug#933135: pkg-perl-tools: depends on libparse-debianchangelog-perl that has no upstream maintainer

[intrigeri]

Control: tag -1 + patch

https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/merge_requests/4
removes the only dependency.

Bug#917292: ffmpeg: linking with libcrystalhd3 seem of no use at all

[Jonas Smedegaard]

Quoting James Cowgill (2019-07-27 12:48:23)
> Hi,
> 
> On 27/07/2019 15:52, Jonas Smedegaard wrote:
> > Quoting James Cowgill (2019-07-27 11:12:00)
> >> Hi,
> >>
> >>> ffmpeg currently links with libcrystalhd3.
> >>>
> >>> It seems, however, that libcrystalhd3 is only really useful 
> >>> together with firmware-crystalhd, which was never really usable in 
> >>> Debian, leading to that package being dropped: 
> >>> https://bugs.debian.org/865978
> >>>
> >>> If someone wants to revive CrystalHD in Debian, it seems a good 
> >>> place to start is 
> >>> https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update
> >>>
> >>> I suggest to simply stop link with libcrystalhd3 until 
> >>> firmware-crystalhd reappear in Debian.
> >>
> >> I've disables crystalhd.
[...]
> Should we completely remove libcrystalhd3 from the archive as well in 
> that case (given what you wrote above)?

Yes, unless anyone steps up and points outan actual working use-case of 
the library, we should (have all its reverse dependencies stop link 
against it and) remove it from Debian altogether.


 - 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#933224: dh_installchangelogs manpage does not describe which files are considered as upstream changelog

[Laurent Bigonville]

Package: debhelper
Version: 12.2.3
Severity: normal

Hi,

dh_installchangelogs manpage does not describe which files are
considered as upstream changelog.

Looking at the code, it seems that it looks for files named changelog,
changes and history with different extensions (.txt .md .rst).

Kind regards,

Laurent Bigonville

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf19
ii  dh-strip-nondeterminism  1.3.0-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  dwz  0.12.20190723-1
ii  file 1:5.37-5
ii  libdpkg-perl 1.19.7
ii  man-db   2.8.5-2
ii  perl 5.28.1-6
ii  po-debconf   1.0.21

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201802

-- no debconf information

Bug#932307: multipath-tools does not update wwids file

[Taulelle Lois]

On 2019-07-25 17:01, Ritesh Raj Sarraf wrote:

On Thu, 2019-07-25 at 16:24 +0200, Taulelle Lois wrote:

> A lot has changed lately in how multipath-tools works and you may
> have
> to fiddle around with settings.

Any doc pointer? From Buster manpages, my configuration and my usage
are
correct. Have I missed a new option?


Have you tried the '-W' option ?


Yep. did nothing.

See strace attached. file /etc/multipath.conf seem to be read, but 
ignored, and /etc/multipath/wwids is still empty (except for the default 
header)


execve("/usr/sbin/multipath", ["multipath", "-W"], 0x7fff17faf158 /* 20 vars 
*/) = 0
brk(NULL)   = 0x560f9d54b000
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (Aucun fichier ou dossier 
de ce type)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=25552, ...}) = 0
mmap(NULL, 25552, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fe2cfbb5000
close(3)= 0
openat(AT_FDCWD, "/lib/libmultipath.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320#\1\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=386512, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7fe2cfbb3000
mmap(NULL, 392096, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2cfb53000
mmap(0x7fe2cfb63000, 212992, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0x7fe2cfb63000
mmap(0x7fe2cfb97000, 77824, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x44000) = 0x7fe2cfb97000
mmap(0x7fe2cfbaa000, 32768, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x56000) = 0x7fe2cfbaa000
mmap(0x7fe2cfbb2000, 2976, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe2cfbb2000
close(3)= 0
openat(AT_FDCWD, "/lib/libmpathcmd.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\\21\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14176, ...}) = 0
mmap(NULL, 16400, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2cfb4e000
mmap(0x7fe2cfb4f000, 4096, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fe2cfb4f000
mmap(0x7fe2cfb5, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x2000) = 0x7fe2cfb5
mmap(0x7fe2cfb51000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fe2cfb51000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 
3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@l\0\0\0\0\0\0"..., 832) 
= 832
fstat(3, {st_mode=S_IFREG|0755, st_size=146968, ...}) = 0
mmap(NULL, 132288, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2cfb2d000
mmap(0x7fe2cfb33000, 61440, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7fe2cfb33000
mmap(0x7fe2cfb42000, 24576, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x15000) = 0x7fe2cfb42000
mmap(0x7fe2cfb48000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0x7fe2cfb48000
mmap(0x7fe2cfb4a000, 13504, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe2cfb4a000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdevmapper.so.1.02.1", 
O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\301\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=432664, ...}) = 0
mmap(NULL, 438992, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2cfac1000
mmap(0x7fe2cfacc000, 290816, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xb000) = 0x7fe2cfacc000
mmap(0x7fe2cfb13000, 81920, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x52000) = 0x7fe2cfb13000
mmap(0x7fe2cfb27000, 20480, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x65000) = 0x7fe2cfb27000
mmap(0x7fe2cfb2c000, 720, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fe2cfb2c000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\\21\0\0\0\0\0\0"..., 
832) = 832
fstat(3, {st_mode=S_IFREG|0644, st_size=14592, ...}) = 0
mmap(NULL, 16656, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fe2cfabc000
mmap(0x7fe2cfabd000, 4096, PROT_READ|PROT_EXEC, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7fe2cfabd000
mmap(0x7fe2cfabe000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 
0x2000) = 0x7fe2cfabe000
mmap(0x7fe2cfabf000, 8192, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7fe2cfabf000
close(3)= 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libudev.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20G\0\0\0\0\0\0"..., 

Bug#924622: [pkg-apparmor] Bug#924622: Can the disabling of AppArmor upon removal of its userland tools be made simpler and more complete?

[intrigeri]

Control: retitle -1 Make it easier to fully disable AppArmor

Hi Nathan,

first, thanks for caring :)

Nathan Howard:
> Removal of AppArmor from the userland leaves a moreso unexpected kernel
> side completely enabled and functioning.  So, upon AppArmor's package
> removal is it possible to either:

> (1) Automate some of the following from
> https://wiki.debian.org/AppArmor/HowToUse#Disable_AppArmor

Indeed, it could be nice to ship a script that automates these steps,
at least for GRUB.

> (2) Simply display a splash screen with the remaining steps needed should
> the user want to complete the removal themselves.

I'm not sure this is worth asking the question interactively but at
the very least, we could display a message that would:

 - Explain the user that if they want to fully disable AppArmor, they
   need to take extra steps

 - Point them to the doc where these extra steps are documented.

I would happily review merge requests for any of these :)

Cheers,
-- 
intrigeri

Bug#933223: ITP: libnbd -- Network Block Device client library

[Hilko Bengen]

Package: wnpp
Owner: Hilko Bengen 
Severity: wishlist

* Package name: libnbd
  Version : 0.1.9
  Upstream Author : Eric Blake, Richard W.M. Jones
* URL or Web page : https://github.com/libguestfs/libnbd
* License : LGPL2+
  Description : Network Block Device client library

Bug#932755: sdl-image1.2: multiple security issues

[Hugo Lefeuvre]

Dear SDL packages maintainers,

I have uploaded the jessie LTS update.

I will coordinate with the security team for stretch and buster fixes via
point release.

Concerning testing: can I upload the NMU?

cheers,
Hugo

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


signature.asc
Description: PGP signature

Bug#933222: update for tmux 2.9

[Sebastian Ramacher]

Package: tmux-themepack-jimeh
Version: 0+git20180910-126150d-1
Severity: normal

Please update to at least 1b1b8098419daacb92ca401ad6ee0ca6894a40ca which
fixes compatibility with tmux 2.9.

See https://github.com/jimeh/tmux-themepack/issues/24

Cheers

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

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

Versions of packages tmux-themepack-jimeh depends on:
ii  tmux  2.9a-2

tmux-themepack-jimeh recommends no packages.

Versions of packages tmux-themepack-jimeh suggests:
ii  fonts-powerline  2.7-2

-- no debconf information

-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#933221: openarena: suggestion to make openarena -players-mature optional

[Tom Goulet]

Source: openarena
Severity: wishlist

Dear Maintainer,

I wanted to install Openarena packages, but with no nudity.

I went to install openarena with apt-get, but I specified
openarena-081-players-mature-, with the minus sign to disable installation of
the -mature package.

APT refused to install the package, because openarena-08-players-mature is a
hard dependency for openarena.

I was hoping to get openarena installed, but without the -mature package.

Is it possible to split off the mature package, rather like how xscreensaver
-bsod an -webcollage are split off?  I think it might be okay if it was an
explicit install.

Myself, and some people with whom I'd like to share Linux, have reasons to not
allow nudity, partial or not, for personal or religious reasons.  Also there
are children that use Debian and descended distributions, and I'd like them to
use free software, too.



-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial-backports'), (500, 'xenial')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-55-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: upstart (via init_is_upstart())

Bug#782636: Welcome to fubar!

[fubar Accounts]

Thank you for signing up for fubar. You have chosen wisely.

As you know (or you're about to find out), fubar has some of the coolest, 
kindest, smartest, weirdest, funniest, most attractive, and over-all best 
community members on the entire Internet.
And now, you're a big part of that.

Come hang out on fubar and play free: 
https://fubar.com/alt.php?n=home=15642460864

Username: 782...@bugs.debian.org
fubar ID: 15394034

Thanks again for joining fubar. We've been looking for people like you.

Cheers,
The fubar family


Download the fubar mobile app

Available at the App Store: 
https://itunes.apple.com/app/apple-store/id455311703?pt=395928=email

Get it on Google Play: 
https://play.google.com/store/apps/details?id=com.fubar.mobile=utm_source%3Demail%26utm_medium%3Demail%26utm_campaign%3Demail

--

Unsubscribe or change your email settings here: 
https://fubar.com/email_settings.php?s=ojUjOdEYPVDpA58C6hE6t%2F63YL%2F4KCbsRwyj%2FVHvOsaA8AhdSKx7ng%3D%3D
fubar - 50 Woodside Plaza #433 - Redwood City, CA 94061

Bug#933220: siridb-server: missing source for Release/makefile

[Helmut Grohne]

Source: siridb-server
Version: 2.0.34-1
Severity: serious
Justification: missing source

The Release/makefile starts with:


# Automatically-generated file. Do not edit!


However, I was unable to find the source for the generator. This is a
DFSG#2 violation.

Helmut

Bug#933218: stretch-pu: package libsdl2-image/2.0.1+dfsg-2+deb9u2

[Adam D. Barratt]

Control: tags -1 + confirmed

On 2019-07-27 13:32, Hugo Lefeuvre wrote:

libsdl2-image is currently affected by the following security issues in
stretch:

* CVE-2018-3977: Heap buffer overflow.

* CVE-2019-5052: integer overflow and subsequent buffer overflow in
  IMG_pcx.c.

* CVE-2019-5051: heap-based buffer overflow in IMG_pcx.c.

* CVE-2019-7635: heap buffer overflow in Blit1to4 (IMG_bmp.c).

* CVE-2019-12216, CVE-2019-12217,
  CVE-2019-12218, CVE-2019-12219,
  CVE-2019-12220, CVE-2019-12221,
  CVE-2019-1: OOB R/W in IMG_LoadPCX_RW (IMG_pcx.c).

(for more information, see #932754)


Please go ahead; thanks.

Regards,

Adam

Bug#933219: Updating the ruby-rspec-puppet Uploaders list

[Tobias Frost]

Source: ruby-rspec-puppet
Version: 2.6.1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Thomas Bechtold  has retired, so can't work on
the ruby-rspec-puppet package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

Bug#932318: buster-pu: package unzip/6.0-23+deb10u1

[Adam D. Barratt]

On 2019-07-27 13:18, Santiago Vila wrote:

tags 932318 - moreinfo
thanks

Hello.

The problem with Firefox should now be fixed, and it was unzip's fault.

If possible, I'd like this upload I did 6.0-23+deb10u1 to be rejected 
so that

I can reuse the +deb10u1 version with all the fixes included.


Done, pending dak actually processing the request.

Regards,

Adam

Bug#932935: (No Subject)

[Joshua W. Lawson]

How does one fix the error if they do not have an older kernel and are stuck 
with only BusyBox?

Bug#928160: [pkg-apparmor] Bug#928160:

[intrigeri]

Control: reopen -1
Control: retitle -1 aa-genprof fails when apparmor-profiles is installed
Control: severity -1 important

Hi,

miteigi:
> I'd like to mention that hoxp18 (and I) encountered the bug not when 
> activating
> these extra profiles, but when we used aa-genprof on completely unrelated
> programs. In other words, it (probably) affects anyone who uses aa-genprof and
> has the apparmor-profiles package installed, not only users of these profiles.

Oh right, sorry I missed that part! Reopening accordingly. I'll upload
a fix shortly.

Cheers,
-- 
intrigeri

Bug#933218: stretch-pu: package libsdl2-image/2.0.1+dfsg-2+deb9u2

[Hugo Lefeuvre]

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

Hi,

libsdl2-image is currently affected by the following security issues in
stretch:

* CVE-2018-3977: Heap buffer overflow.

* CVE-2019-5052: integer overflow and subsequent buffer overflow in
  IMG_pcx.c.

* CVE-2019-5051: heap-based buffer overflow in IMG_pcx.c.

* CVE-2019-7635: heap buffer overflow in Blit1to4 (IMG_bmp.c).

* CVE-2019-12216, CVE-2019-12217,
  CVE-2019-12218, CVE-2019-12219,
  CVE-2019-12220, CVE-2019-12221,
  CVE-2019-1: OOB R/W in IMG_LoadPCX_RW (IMG_pcx.c).

(for more information, see #932754)

Attached is a debdiff addressing all of them for stretch.

All of these patches are from upstream, I have removed whitespace changes
and non security related refactoring.

This is the same patch as #933147.

thanks!

cheers,
Hugo

-- 
Hugo Lefeuvre (hle)|www.owl.eu.com
RSA4096_ 360B 03B3 BF27 4F4D 7A3F D5E8 14AA 1EB8 A247 3DFD
ed25519_ 37B2 6D38 0B25 B8A2 6B9F 3A65 A36F 5357 5F2D DC4C
diff -Nru libsdl2-image-2.0.1+dfsg/debian/changelog libsdl2-image-2.0.1+dfsg/debian/changelog
--- libsdl2-image-2.0.1+dfsg/debian/changelog	2018-04-15 12:26:34.0 -0300
+++ libsdl2-image-2.0.1+dfsg/debian/changelog	2019-07-27 13:19:47.0 -0300
@@ -1,3 +1,18 @@
+libsdl2-image (2.0.1+dfsg-2+deb9u2) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Multiple security issues (Closes: #932754):
+- CVE-2018-3977: buffer overflow in do_layer_surface (IMG_xcf.c).
+- CVE-2019-5052: integer overflow and subsequent buffer overflow in
+  IMG_pcx.c.
+- CVE-2019-7635: heap buffer overflow in Blit1to4 (IMG_bmp.c).
+- CVE-2019-12216, CVE-2019-12217,
+  CVE-2019-12218, CVE-2019-12219,
+  CVE-2019-12220, CVE-2019-12221,
+  CVE-2019-1, CVE-2019-5051: OOB R/W in IMG_LoadPCX_RW (IMG_pcx.c).
+
+ -- Hugo Lefeuvre   Sat, 27 Jul 2019 13:19:47 -0300
+
 libsdl2-image (2.0.1+dfsg-2+deb9u1) stretch-security; urgency=high
 
   * Backport various security fixes:
diff -Nru libsdl2-image-2.0.1+dfsg/debian/patches/CVE-2018-3977.patch libsdl2-image-2.0.1+dfsg/debian/patches/CVE-2018-3977.patch
--- libsdl2-image-2.0.1+dfsg/debian/patches/CVE-2018-3977.patch	1969-12-31 21:00:00.0 -0300
+++ libsdl2-image-2.0.1+dfsg/debian/patches/CVE-2018-3977.patch	2019-07-27 13:19:47.0 -0300
@@ -0,0 +1,19 @@
+Description: Fix potential buffer overflow on corrupt or maliciously-crafted XCF file.
+ This patch bundles two fixes, the original one for CVE-2018-3977
+ (TALOS-2018-0645) which is actually broken, and the followup patch
+ (TALOS-2019-0842).
+Author: Ryan C. Gordon 
+Origin: upstream, https://hg.libsdl.org/SDL_image/rev/170d7d32e4a8
+  https://hg.libsdl.org/SDL_image/rev/b1a80aec2b10
+--- a/IMG_xcf.c	2019-07-27 13:21:45.402211011 -0300
 b/IMG_xcf.c	2019-07-27 13:21:45.398211049 -0300
+@@ -637,6 +637,9 @@
+   p16 = (Uint16 *) p8;
+   p   = (Uint32 *) p8;
+   for (y=ty; y < ty+oy; y++) {
++if ((y >= surface->h) || ((tx+ox) > surface->w)) {
++break;
++}
+ row = (Uint32 *)((Uint8 *)surface->pixels + y*surface->pitch + tx*4);
+ switch (hierarchy->bpp) {
+ case 4:
diff -Nru libsdl2-image-2.0.1+dfsg/debian/patches/CVE-2019-12218.patch libsdl2-image-2.0.1+dfsg/debian/patches/CVE-2019-12218.patch
--- libsdl2-image-2.0.1+dfsg/debian/patches/CVE-2019-12218.patch	1969-12-31 21:00:00.0 -0300
+++ libsdl2-image-2.0.1+dfsg/debian/patches/CVE-2019-12218.patch	2019-07-27 13:19:47.0 -0300
@@ -0,0 +1,84 @@
+Description: fix heap buffer overflow issue in IMG_pcx.c
+ Issue known as TALOS-2019-0841, CVE-2019-12218.
+Author: Sam Lantinga 
+Origin: upstream, https://hg.libsdl.org/SDL_image/rev/7453e79c8cdb
+--- a/IMG_pcx.c	2019-07-27 13:21:30.158367768 -0300
 b/IMG_pcx.c	2019-07-27 13:21:30.154367811 -0300
+@@ -100,6 +100,8 @@
+ Uint8 *row, *buf = NULL;
+ char *error = NULL;
+ int bits, src_bits;
++int count = 0;
++Uint8 ch;
+ 
+ if ( !src ) {
+ /* The error message has been set in SDL_RWFromFile */
+@@ -148,14 +150,14 @@
+ bpl = pcxh.NPlanes * pcxh.BytesPerLine;
+ if (bpl > surface->pitch) {
+ error = "bytes per line is too large (corrupt?)";
++goto done;
+ }
+-buf = (Uint8 *)SDL_calloc(SDL_max(bpl, surface->pitch), 1);
++buf = (Uint8 *)SDL_calloc(surface->pitch, 1);
+ row = (Uint8 *)surface->pixels;
+ for ( y=0; yh; ++y ) {
+ /* decode a scan line to a temporary buffer first */
+-int i, count = 0;
+-Uint8 ch;
+-Uint8 *dst = (src_bits == 8) ? row : buf;
++int i;
++Uint8 *dst = buf;
+ if ( pcxh.Encoding == 0 ) {
+ if(!SDL_RWread(src, dst, bpl, 1)) {
+ error = "file truncated";
+@@ -168,14 +170,15 @@
+ error = "file truncated";
+ goto done;
+ }
+- 

Bug#928706: Debian Stretch cannot be installed on QNAP TS-121 (Kirkwood Marvell 6282 CPU w/ 1GB RAM)

[Martin Michlmayr]

* Luca Pasquini  [2019-05-09 12:31]:
> May  9 00:00:50 kernel: [   12.152446] BUG: Bad rss-counter state
> mm:c08593c0 idx:1 val:1
> 
> The unique known workaround is to lower the RAM from 1G to 768M (link:
> https://blog.spblinux.de/2018/09/debian-with-btrfs-on-qnap-11x-21x-kirkwood/).
> I'm wondering if it's planned a fix, because it would be great to use
> the whole memory.

Unfortunately there's no planned fix yet.  Upstream kernel folks
suggested something but that leads to other problems.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#932318: buster-pu: package unzip/6.0-23+deb10u1

[Santiago Vila]

tags 932318 - moreinfo
thanks

Hello.

The problem with Firefox should now be fixed, and it was unzip's fault.

If possible, I'd like this upload I did 6.0-23+deb10u1 to be rejected so that
I can reuse the +deb10u1 version with all the fixes included.

Thanks.

Bug#933217: RM: check-mk -- RoQA, RC-Buggy, unmaintained, no reverse dependency

[Tobias Frost]

Source: check-mk
Severity: serious
Justification: QA/MIA-Team

Dear maintainers of check-mk,

check-mk is currently RC-Buggy with 2 RC bugs:

#876686 [S|  |  ] [check-mk-config-icinga] check-mk-config-icinga: file 
conflict with check-mk-common: /usr/share/check_mk/cmk/paths.py
#924727 [S|  |  ] [src:check-mk] check-mk: build-depends on no longer 
available g++-6

as well as plenty of many other bugs. It missed Buster and the last upload was
two years ago, so this package seems to be unmaintained.

"dak rm -Rn check-mk" tells that there are no reverse dependencies, so I think
it would be sane to just let the package go.

If there is no answer to this bug within 3 months, I will reassign this bug to
ftp.debian.org for the actual removal.

If you disagree, just close the bug, but it would be great if the package could
be fixed into back into an releasble state.

-- 
tobi 


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

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

Bug#932404: firefox-esr, FTBFS "possible zip bomb".

[Santiago Vila]

On Fri, Jul 26, 2019 at 04:01:15AM +, Adler, Mark wrote:
> All,
> 
> Thank you Santiago for the report and David for the diagnosis. Though this is 
> not a valid zip file, there are in fact no overlapping structures and so 
> there should not be a bomb alert.
> 
> I have added a commit that initializes the cover with the actual spans of the 
> central directory, the Zip64 end of central directory record if present, and 
> the end of central directory record (the latter of which may include the 
> Zip64 end of central directory locator). unzip then processes the funky 
> omni.ja file without a bomb alert.
> 
> See:
> 
> 
> https://github.com/madler/unzip/commit/6d351831be705cc26d897db44f878a978f4138fc

I've just uploaded the fix for Debian unstable.

Thanks a lot!

Bug#933216: network-manager: system refuse to work with Intel i210 interface, only work with i217-V. can only use 1 eth conn.

[Mélanie Legault]

Package: network-manager
Version: 1.14.6-2
Severity: important



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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-3
ii  libbluetooth3  5.50-1
ii  libc6  2.28-10
ii  libcurl3-gnutls7.64.0-4
ii  libglib2.0-0   2.58.3-2
ii  libgnutls303.6.7-4
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.6-2
ii  libpam-systemd 241-5
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0241-5
ii  libteamdctl0   1.28-1
ii  libudev1   241-5
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2019051400
ii  policykit-10.105-25
ii  udev   241-5
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-6

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-4
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.10.0-1
ii  ppp  2.4.7-2+4.1

Versions of packages network-manager suggests:
pn  libteam-utils  

- i210 interface do not show up in network-manager gui
- trying to configure by hand with networking associate i210 config with
  i217-V physical port

lshw -class network
  *-network DISABLED
   description: Ethernet interface
   product: Ethernet Connection I217-V
   vendor: Intel Corporation
   physical id: 19
   bus info: pci@:00:19.0
   logical name: eno1
   version: 04
   serial: 94:de:80:6e:ce:05
   capacity: 1Gbit/s
   width: 32 bits
   clock: 33MHz
   capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 
10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
   configuration: autonegotiation=on broadcast=yes driver=e1000e 
driverversion=3.2.6-k firmware=0.13-4 latency=0 link=no multicast=yes 
port=twisted pair
   resources: irq:29 memory:f090-f091 memory:f093d000-f093dfff 
ioport:f080(size=32)
  *-network
   description: Ethernet interface
   product: I210 Gigabit Network Connection
   vendor: Intel Corporation
   physical id: 0
   bus info: pci@:02:00.0
   logical name: enp2s0
   version: 03
   serial: 94:de:80:6e:ce:15
   size: 1Gbit/s
   capacity: 1Gbit/s
   width: 32 bits
   clock: 33MHz
   capabilities: pm msi msix pciexpress bus_master cap_list rom ethernet 
physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
   configuration: autonegotiation=on broadcast=yes driver=igb 
driverversion=5.4.0-k duplex=full firmware=3.11, 0x8469 ip=192.168.6.141 
latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
   resources: irq:19 memory:f050-f05f ioport:e000(size=32) 
memory:f060-f0603fff memory:f040-f04f

-after restarting networking:
eno1: flags=4098  mtu 1500
ether 94:de:80:6e:ce:05  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device interrupt 20  memory 0xf090-f092  

enp2s0: flags=4163  mtu 1500
inet 192.168.6.141  netmask 255.255.255.0  broadcast 192.168.6.255
inet6 fe80::96de:80ff:fe6e:ce15  prefixlen 64  scopeid 0x20
inet6 fd36:af4:e180:0:96de:80ff:fe6e:ce15  prefixlen 64  scopeid 
0x0
ether 94:de:80:6e:ce:15  txqueuelen 1000  (Ethernet)
RX packets 3212  bytes 2575581 (2.4 MiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2675  bytes 331996 (324.2 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
device memory 0xf050-f05f  

lo: flags=73  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10
loop  txqueuelen 1000  (Local Loopback)
RX packets 311  bytes 28247 (27.5 KiB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 311  bytes 28247 (27.5 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

- but traffic is not going on enp2s0 physical interface but eno1 physical 

Bug#933215: Please remove Python 2 use in this package

[Thomas Goirand]

Package: heudiconv
Severity: important

Hi,

Please get rid of all Python 2 in this package, as we're removing it from
Sid. Once done, we can get rid of Py2 support in python-datalad and then,
in python-httpretty.

I'd appreciate a ping when this is done.

Cheers,

Thomas Goirand (zigo)

Bug#928160:

[miteigi]

Greetings,

I'd like to mention that hoxp18 (and I) encountered the bug not when activating
these extra profiles, but when we used aa-genprof on completely unrelated
programs. In other words, it (probably) affects anyone who uses aa-genprof and
has the apparmor-profiles package installed, not only users of these profiles.

I suggest putting an extra '#' before the line responsible for inclusion of
the local profile, making that line a comment — same to the approach in
/usr/share/apparmor/extra-profiles/usr.lib.firefox.firefox .


A little more conjecture (could be wrong): I guess the whole thing
is that aa-autodep (and aa-genprof) scans all the profiles under
/usr/share/apparmor/extra-profiles , which is the "inactive_profiledir" defined
in /etc/apparmor/logprof.conf , and exits with error when it encounters a
line that includes a non-existent .


Kind regards,

miteigi

Bug#933214: fdisk: program loops with "Do you really want to quit?"

[Yangfl]

Package: fdisk
Version: 2.33.1-0.1
Severity: minor

Dear Maintainer,

The program can be tricked inot a situation where

  Do you really want to quit?
  Command (m for help):

is printed over and over by issuing the following command sequence:

  g
  n
  
  
  

Bug#917292: ffmpeg: linking with libcrystalhd3 seem of no use at all

[James Cowgill]

Hi,

On 27/07/2019 15:52, Jonas Smedegaard wrote:
> Quoting James Cowgill (2019-07-27 11:12:00)
>> Hi,
>>
>>> ffmpeg currently links with libcrystalhd3.
>>>
>>> It seems, however, that libcrystalhd3 is only really useful together 
>>> with firmware-crystalhd, which was never really usable in Debian, 
>>> leading to that package being dropped: 
>>> https://bugs.debian.org/865978
>>>
>>> If someone wants to revive CrystalHD in Debian, it seems a good 
>>> place to start is 
>>> https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update
>>>
>>> I suggest to simply stop link with libcrystalhd3 until 
>>> firmware-crystalhd reappear in Debian.
>>
>> I've disables crystalhd.
>>
>> Should we completely from libcrystalhd3 as well in that case?
> 
> Sorry, I fail to parse your last sentence above...

No idea what happened there. What I meant to say:

Should we completely remove libcrystalhd3 from the archive as well in
that case (given what you wrote above)?

James



signature.asc
Description: OpenPGP digital signature

Bug#933213: upgrades causes problems due newer openssl 102 vs 1.1.1

[PICCORO McKAY Lenz]

Package: courier-mta-ssl
Version: 0.73.1-1.6


i upgrade from jessie to buster.. when pass to strech got a problem..
i must manually downgrade the openssl to jessie version before upgrade
both openssl and courier,
minimal version posible 1.0.2 before use the 1.1.1 or more up!

Setting up courier-mta-ssl (0.73.1-1.6) ...
Can't load /usr/lib/courier/esmtpd.rand into RNG
139827721225984:error:2406F079:random number
generator:RAND_load_file:Cannot open
file:../crypto/rand/randfile.c:98:Filename=/usr/lib/courier/esmtpd.rand
Generating a RSA private key


writing new private key to '/tmp/tmp.ABP95tkPaE/esmtpd.pem'
-
Invalid command 'gendh'; type "help" for a list.
dpkg: error processing package courier-mta-ssl (--configure):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for systemd (215-17+deb8u13) ...
Errors were encountered while processing:
 courier-mta-ssl
E: Sub-process /usr/bin/dpkg returned an error code (1)
Failed to perform requested operation on package.  Trying to recover:
Setting up courier-mta-ssl (0.73.1-1.6) ...
Generating a RSA private key
..
..
writing new private key to '/tmp/tmp.jGwSHG2y5y/esmtpd.pem'
-
Invalid command 'gendh'; type "help" for a list.
dpkg: error processing package courier-mta-ssl (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 courier-mta-ssl



-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

Bug#933055: aptitude: Unable to satisfy the build-depends: Build-Depends: debhelper-compat (= 12)

[Sven Joachim]

Control: merge 509100 -1

On 2019-07-26 08:43 +0200, Jochen Sprickerhof wrote:

> Package: aptitude
> Version: 0.8.11-7
> Severity: normal
>
> Hi,
>
> debhelper 12 supports debhelper-compat as a Build-Depends in
> debian/control, instead of a debian/compat. Can you add support for this
> in aptitude build-dep?

Somebody™ needs to write code for that, it has been requested for over
ten years…

Cheers,
   Sven

Bug#933212: dh_dwz: probably shouldn't extract multifiles for udebs

[Simon McVittie]

Package: debhelper
Version: 12.2.3
Severity: normal

I recently converted src:glib2.0 to compat level 12. glib2.0 is unusual
in a couple of ways:

- multiple shared libraries lib{glib,gobject,gio,...}-2.0.so.0 are bundled
  into a single binary package libglib2.0-0
- it has a corresponding udeb, libglib2.0-udeb, with the same libraries

This seems to result in the following sequence of events (disregarding
non-shared-library packages and irrelevant steps):

- dh_install copies shared libraries into libglib2.0-0 and libglib2.0-udeb
- dh_dwz acts on libglib2.0-0 and libglib2.0-udeb
  - creates a multifile in debian/libglib2.0-0/usr/lib/debug/.dwz
  - creates a multifile in debian/libglib2.0-udeb/usr/lib/debug/.dwz
  - compresses all other debug symbols embedded in the shared libraries
- dh_strip acts on libglib2.0-0
  - moves debian/libglib2.0-0/usr/lib/debug/.dwz to debian/libglib2.0-0-dbgsym
  - detaches debug symbols from libglib2.0-0 shared libraries
- dh_strip doesn't delete usr/lib/debug/.dwz from debian/libglib2.0-udeb
  because that's part of a code path that isn't used for udebs
- libglib2.0-udeb ends up containing /usr/lib/debug/.dwz
- the udeb is larger than it ought to be and triggers Lintian warnings

Either dh_dwz shouldn't act on udebs (because it's a waste of time because
dh_strip will discard the debugging symbols anyway), or dh_strip should
delete the multifiles from udebs even though it isn't going to generate
a -dbgsym package (or dh_strip should generate -dbgsym packages for udebs,
but #797391 says that's problematic).

Thanks,
smcv

Bug#933211: libosinfo-bin: Debian Buster does not appear in the OS database

[Steven Monai]

Package: libosinfo-bin
Version: 1.4.0-1
Severity: normal

Dear Maintainer,

When I run the following on the command line:

osinfo-query os | grep -i buster | sed 's/  */ /g'

there is no output.


I would expect to see a line that is analagous to the output
obtained for every previous Debian stable release, specifically:

 debian10 | Debian Buster | 10 | http://debian.org/debian/10


For example, the following command:

osinfo-query os | grep -i stretch | sed 's/  */ /g'

generates this output, as expected:

 debian9 | Debian Stretch | 9 | http://debian.org/debian/9


Thanks,
/-S.M.

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

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

Versions of packages libosinfo-bin depends on:
ii  libc62.28-10
ii  libglib2.0-0 2.60.5-1
ii  libosinfo-1.0-0  1.4.0-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxslt1.1   1.1.32-2

libosinfo-bin recommends no packages.

libosinfo-bin suggests no packages.

-- no debconf information

Bug#932989: gcc-avr: Package version severely outdated compared to main gcc-toolchain

[nightwalker-87]

Hi Hakan,

pointing to this issue in a developer discussion and also this link 
(https://savannah.nongnu.org/forum/forum.php?forum_id=8460 
) led to the 
maintainer Jörg Wunsch.
It looks like as if he could be one of the key persons to address regarding 
this issue, as the key-package avr-libc has a dependency on gcc-avr which 
determines device compatibility.
The obviously current state of device support for avr-libc 2.0.0 as part of the 
latest AVR-toolchain 3.6.1 by Microchip can be found here: 
https://www.microchip.com/webdoc/AVRLibcReferenceManual/index_1supp_devices.html
 
.
Would that mean that a new version of avr-libc with full compatibility to gcc 
8.3 (for example) could ease portability of the complete toolchain, while 
preserving device support at the same time?

Another info I came across is that the distribution Arch Linux maintains a very 
recent version of the toolchain 
(https://archlinux.pkgs.org/rolling/archlinux-community-x86_64/avr-gcc-9.1.0-1-x86_64.pkg.tar.xz.html
 
).
Would it be possible to port these sources to the Debian? How did the 
maintainers at Arch manage to achieve compatibility with the latest 
gcc-mainline? According to the package content this is even based on avr-libc 
2.0.0.
Do they have limitations regarding device support?

Nightwalker-87


> Am 25.07.2019 um 18:41 schrieb nightwalker...@t-online.de:
> 
> Dear Hakan,
> 
> Thank You very much for your quick reply.
> 
> Unfortunately I don’t know too much about the development history of this 
> package @Debian and the related decisions.
> It would be helpful though to have other developers and maintainers to have 
> their say on this to help find a common solution.
> At first one should find out if support for newer devices would suffer from 
> such an approach. I have not come across that topic yet...
> 
> Best regards
> Nightwalker-87
> 
>> Am 25.07.2019 um 18:17 schrieb Hakan Ardo > >:
>> 
>> Hi, 
>> gcc-avr was originally built from the mainline gcc, but was later split out 
>> by to build depend on gcc-source as it was not wanted in the mainstream gcc 
>> package. Has that situation changed? 
>> 
>> It was then decided to base the package on the Atmel distribution instead of 
>> the upstream source as that gave support for newer devices faster. 
>> 
>> Now, as far as I can tell, Atmel have dropped their source distribution and 
>> only provided binaries. So something have to be done indeed. 
>> 
>> Switching back to use upstream source would be one option. But will that 
>> mean we'll have to dropp support for newer devices? 
>> 
>> Den tors 25 juli 2019 17:27nightwalker-87 > > skrev:
>> Package: gcc-avr
>> Version: 1:5.4.0+Atmel3.6.1-2
>> Severity: normal
>> Tags: newcomer
>> 
>> Dear Maintainer,
>> 
>> It appears that the gcc-avr toolchain in the debian repository is severely
>> outdated compared to the current level of version support for the main gcc
>> toolchain. This leaves avr-developers wishing to use newer C language 
>> features
>> behind and makes it necessary to use external toolchains (source based or 
>> pre-
>> compiled). Pointing to this in the debian-devel IRC-Channel, lead to the
>> following idea: "if it was in mainline, the gcc-avr package could be dropped 
>> in
>> favour of a package built from the mainline version of gcc." as well as "an
>> example of such a source package is gcc-arm-none-eabi, the equivalent for avr
>> could be added by someone interested, then gcc-avr could be removed." (user:
>> pabs) From my point of view this could be a promising approach to resume
>> development on this topic. I would appreciate, if debian developers could 
>> take
>> action on this topic to resolve this long lasting backlog and make 
>> contribution
>> to make debian even more attractive for development. As it stands the avr-8
>> architecture will remain for many years to come in some parts even with new
>> applications.
>> 
>> 
>> 
>> -- System Information:
>> Debian Release: bullseye/sid
>>   APT prefers testing
>>   APT policy: (500, 'testing'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> 
>> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
>> Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
>> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> LSM: AppArmor: enabled
>> 
>> Versions of packages gcc-avr depends on:
>> ii  binutils-avr  2.26.20160125+Atmel3.6.1-4
>> ii  libc6 2.28-10
>> ii  libgcc1   1:8.3.0-7
>> ii  libgmp10  2:6.1.2+dfsg-4
>> ii  libmpc3   1.1.0-1
>> ii  libmpfr6  4.0.2-1
>> ii  

Bug#920373: default soundfonts

[Thorsten Glaser]

Fabian Greffrath dixit:

>cleared out: Do you suggest for SF2 soundfonts to also provide the sf3-
>soundfont-gmvirtual package? I mean, technically they should be
>compatible, but this would mean we create a symlink with a different
>file extension. Do we want this?

Yes, of course we do want this!

SF3 readers can also use SF2, they basically uncompress SF3 to SF2
first anyway, and the file extension does not matter really, it’s
not MS-DOS here.

We have that already in MuseScore, which eats
/usr/share/sounds/sf3/MuseScore_General.sf3 which I’m pointing to
/usr/share/sounds/sf2/MuseScore_General_Full.sf2 via alternatives
if the highest-quality soundfont is in use.

I expect that, should ever this fail in some synthesiser,
we fix the synthesiser to work with it instead.

Sorry I only just saw your previous mail in the thread,
my INBOX was a bit unmanageable due to certain threads
from a certain other mailing list for a bit until I
decided to delete them unread…

>Could you please leave a note on -devel that we are going to introduce
>two more virtual packages?

Meh I might be able to post that but I don’t read -devel due
to traffic either except sometimes via the web archives so
feel free to do that yourself ☻

bye,
//mirabilos, currently melting
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

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

[intrigeri]

gregor herrmann:
> In dpt-new-upstream we're using Dpkg::Changelog::Debian from
> libdpkg-perl, which might help here as well.

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

I'm very glad I was mislead. It looks like Dpkg::Changelog{,::*} are
sufficient for many, if not most, use cases of Parse::DebianChangelog :)
We might have to check what API is public and supported, and improve
the documentation accordingly: for example, the "load" method that
our new-upstream script uses does not seem to be documented anywhere.

Cheers,
-- 
intrigeri

Bug#889283: Not found - version 1.35 has left NEW

[Neil Williams]

Version: 1.35+dfsg-1

These three bugs appear fixed in unstable.

 geany-plugin-spellcheck 1.35+dfsg-1
 geany-plugins  1.35+dfsg-1
 geany  1.35-1 

All are now installable in unstable.

Closing the two geany-plugin bugs (as the version string is different
for geany, just following up to 889283).

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp8ovH16NIGl.pgp
Description: OpenPGP digital signature

Bug#933210: rdkit: BD on texlive-generic-extra which isn't build anymore and isn't in bullseye

[Paul Gevers]

Source: rdkit
Version: 201809.1+dfsg-7
Severity: serious
Tags: ftbfs sid bullseye

Since version 2019.20190311-1 the texlive-base package doesn't build
texlive-generic-extra anymore. This is an issue for your package as it
build-depends on it. Please update the building of your package to not
need that (cruft) package anymore.

Unfortunately the migration software doesn't detected this kind of
situation yet, so your package also FTBFS in bullseye since 2019-07-16.

This is currently also blocking migration of rdkit to testing.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#926042: [Pkg-privacy-maintainers] Bug#926042: torbrowser-launcher should not be included in Buster

[intrigeri]

Roger Shimizu:
> Buster is released, so I guess it's okay to reduce the severity to let
> it migrate to testing again.

Thanks a lot for caring about torbrowser-launcher!

FTR, I'm not enthusiastic at the idea of seeing it in testing and
backports (I suspect the reasons why torbrowser-launcher was not
suitable for Buster will still apply for Bullseye) but I can live with
it and I don't care enough about this topic to argue further.

Anyhow, maybe we can simply close this bug then? What's the value in
keeping it open at normal severity?

Cheers!
-- 
intrigeri

Bug#933208: qevercloud FTCBFS: missing Build-Depends: qtbase5-dev:native

[Helmut Grohne]

Source: qevercloud
Version: 3.0.3+ds-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

qevercloud fails to cross build from source, because it fails finding a
native qmake. qevercloud first tries to perform a native build of a
generator and then a cross build of the actual application. The native
pass fails, because it requires a native qmake but no appropriate
build-dependency is present. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru qevercloud-3.0.3+ds/debian/changelog 
qevercloud-3.0.3+ds/debian/changelog
--- qevercloud-3.0.3+ds/debian/changelog2018-05-06 03:10:24.0 
+0200
+++ qevercloud-3.0.3+ds/debian/changelog2019-02-14 11:10:02.0 
+0100
@@ -1,3 +1,10 @@
+qevercloud (3.0.3+ds-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: qtbase5-dev:native. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 14 Feb 2019 11:10:02 +0100
+
 qevercloud (3.0.3+ds-4) unstable; urgency=medium
 
   * Expected to be the last release of qevercloud 3.x.
diff --minimal -Nru qevercloud-3.0.3+ds/debian/control 
qevercloud-3.0.3+ds/debian/control
--- qevercloud-3.0.3+ds/debian/control  2018-05-06 03:10:24.0 +0200
+++ qevercloud-3.0.3+ds/debian/control  2019-02-14 11:09:58.0 +0100
@@ -8,6 +8,7 @@
  ghostscript,
  lemon,
  libqt5webkit5-dev,
+ qtbase5-dev:native,
  qttools5-dev (>= 5.2.1),
  qttools5-dev-tools (>= 5.2.1),
  texlive-binaries,

Bug#933207: firmware-misc-nonfree: Please include DVBSky S960/S860 / Montage Technology M88DS3103 firmware

[Florian Lohoff]

Package: firmware-misc-nonfree
Version: 20190114-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,
would you mind including the firmware for this device:

[   15.093992] usb 1-2: new high-speed USB device number 4 using xhci_hcd
[   15.242748] usb 1-2: New USB device found, idVendor=0572, idProduct=6831, 
bcdDevice= 0.00
[   15.242764] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   15.242773] usb 1-2: Product: S960
[   15.242781] usb 1-2: Manufacturer: Bestunar
[   15.242789] usb 1-2: SerialNumber: 20120511
[   15.525991] usb 1-2: dvb_usb_v2: found a 'DVBSky S960/S860' in warm state
[   15.526612] usb 1-2: dvb_usb_v2: will pass the complete MPEG2 transport 
stream to the software demuxer
[   15.52] dvbdev: DVB: registering new adapter (DVBSky S960/S860)
[   15.527921] usb 1-2: dvb_usb_v2: MAC address: 00:17:42:54:96:0c
[   15.548129] i2c i2c-10: Added multiplexed i2c bus 11
[   15.617279] ts2020 11-0060: Montage Technology TS2022 successfully identified
[   15.617358] usb 1-2: DVB: registering adapter 0 frontend 0 (Montage 
Technology M88DS3103)...
[   15.657955] Registered IR keymap rc-dvbsky
[   15.658119] rc rc0: DVBSky S960/S860 as 
/devices/pci:00/:00:14.0/usb1/1-2/rc/rc0
[   15.658314] input: DVBSky S960/S860 as 
/devices/pci:00/:00:14.0/usb1/1-2/rc/rc0/input12
[   15.659565] rc rc0: lirc_dev: driver dvb_usb_dvbsky registered at minor = 0, 
scancode receiver, no transmitter
[   15.659578] usb 1-2: dvb_usb_v2: schedule remote query interval to 300 msecs
[   15.659588] usb 1-2: dvb_usb_v2: 'DVBSky S960/S860' successfully initialized 
and connected
[   15.659695] usbcore: registered new interface driver dvb_usb_dvbsky

Trying to use the device requests these files:

[  269.506258] m88ds3103 10-0068: found a 'Montage Technology M88DS3103' in 
cold state
[  269.506317] m88ds3103 10-0068: firmware: failed to load 
dvb-demod-m88ds3103.fw (-2)
[  269.506330] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware
[  269.506340] m88ds3103 10-0068: Direct firmware load for 
dvb-demod-m88ds3103.fw failed with error -2
[  269.506346] m88ds3103 10-0068: firmware file 'dvb-demod-m88ds3103.fw' not 
found
[  401.740293] m88ds3103 10-0068: found a 'Montage Technology M88DS3103' in 
cold state
[  401.740333] m88ds3103 10-0068: firmware: failed to load 
dvb-demod-m88ds3103.fw (-2)
[  401.740348] m88ds3103 10-0068: Direct firmware load for 
dvb-demod-m88ds3103.fw failed with error -2
[  401.740353] m88ds3103 10-0068: firmware file 'dvb-demod-m88ds3103.fw' not 
found

I downloaded the firmware files from the Vendors website:

http://www.dvbsky.net/Support_linux.html
http://www.dvbsky.net/download/linux/firmware.zip

[  531.408407] m88ds3103 10-0068: found a 'Montage Technology M88DS3103' in 
cold state
[  531.408546] m88ds3103 10-0068: firmware: direct-loading firmware 
dvb-demod-m88ds3103.fw
[  531.408802] m88ds3103 10-0068: downloading firmware from file 
'dvb-demod-m88ds3103.fw'
[  532.396040] m88ds3103 10-0068: found a 'Montage Technology M88DS3103' in 
warm state
[  532.396054] m88ds3103 10-0068: firmware version: 3.B

USB DVB-S2 Card works without a problem with that firmware.

Flo



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

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

firmware-misc-nonfree depends on no packages.

firmware-misc-nonfree recommends no packages.

Versions of packages firmware-misc-nonfree suggests:
ii  initramfs-tools  0.133

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEdb9o7oebX2papQ/KkN1BIMsJ8i8FAl08aQoACgkQkN1BIMsJ
8i8iIA//V2SKtbBZh8HnKlO0wCT9RY/FHN9fHSomZqEcNWTQVwjetEDWuD+iZYYy
aVqmg/WGzHWSvfogmgufrON0nJjHyvtrZYZkrxqyBU0wPaHf9RGV015ZH7YgZ7Lc
X0r0D+CMFR84zWSuU5cwvv6w66xrvW7xTSbgopSsXpowOdK/8QniJStw4tj340Qv
0B1p4myjub3f6Yo0m8uoi4x4uI5RPz4yzO6eksWyETkddlIXghsuQAVXiAJ1QVI7
l1t9xIXq+kLwp5YbGGKDQC7M9UET3cpZiDDC/EbPliqzJpw0RC33VQt0ILB0sK8f
6xuzOr1OzPtJqGrBqaNbz6FuYeFl+YBYykG/6ZhQUh7Ivtj3hnLXgqHRIMSrwhOa
fYIgMi5feGue/YZatRM7oMBwd86rhPnaPjEPzfD6zlAdQxRCP/Q8QSm/BJ2vmbnw
uTYFOCm4Jap8jNIE1fTxInj7iQ2zUhoLeCb40ojy6nE633tHe6bFoXDzKOXOyljt
I7jE1TBNoMY90EMUMjRcm0k7jaqk2nCwgzKVPUib0yglTtzxekuCBXcN1+zkWe5c
tTGvWgjGc3kfapk5dgFCGx1q3dMaUxyNfUpuRAxXudGK7lL5Ok3fhmJ0+ZbE7TAy
TA81FaL10B/apT33Isz/gmAVCEx8xr0bIZkQRqiu1md99YnnV9M=
=VfCp
-END PGP SIGNATURE-

Bug#799090: Still present in buster version (3.30.1.1-1)

[Jörg Frings-Fürst]

tags 799090 - upstream
thanks


Hello,

in my mail from 14-07-2019 I asked to open a new bug report if the bug
still exists.

Background is

 * the report was created in 2015 on a now totally outdated system.
 * This means that current data, which is important for IMHO to re
   forward to the upstream author, is not available. 

CU
Jörg


-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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

Bug#933209: mark openscad-mcad Multi-Arch: foreign

[Helmut Grohne]

Package: openscad-mcad
Version: 2019.02-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 + src:openscad

openscad fails to cross build from source, because its build dependency
on openscad-mcad is unsatisfiable. In general, Architecture: all
packages can never satisfy cross Build-Depends unless marked Multi-Arch:
foreign or annotated :native. In the case of openscad-mcad, Multi-Arch:
foreign makes sense, because it is a pure data package. It does not have
any dependencies nor maintainer scripts and ships only .scad source
files (textual). Please mark it Multi-Arch: foreign.

Helmut
diff --minimal -Nru openscad-mcad-2019.02/debian/changelog 
openscad-mcad-2019.02/debian/changelog
--- openscad-mcad-2019.02/debian/changelog  2019-02-20 08:16:03.0 
+0100
+++ openscad-mcad-2019.02/debian/changelog  2019-07-27 17:04:07.0 
+0200
@@ -1,3 +1,10 @@
+openscad-mcad (2019.02-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark openscad-mcad Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 27 Jul 2019 17:04:07 +0200
+
 openscad-mcad (2019.02-1) unstable; urgency=medium
 
   * New upstream version
diff --minimal -Nru openscad-mcad-2019.02/debian/control 
openscad-mcad-2019.02/debian/control
--- openscad-mcad-2019.02/debian/control2019-02-20 08:16:03.0 
+0100
+++ openscad-mcad-2019.02/debian/control2019-07-27 17:02:47.0 
+0200
@@ -11,6 +11,7 @@
 
 Package: openscad-mcad
 Architecture: all
+Multi-Arch: foreign
 Depends:
  ${misc:Depends}
 Recommends:

Bug#933206: RM: spl-linux -- ROM; replaced by zfs-linux

[Mo Zhou]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: a...@debian.org

the source code of spl has been merged
into src:zfs-linux as of 0.8.0~* version.

Bug#933205: haskell-patience_0.2.1.1-1_all.changes REJECTED

[Aurelien Jarno]

Source: haskell-patience
Version: 0.2.1.1-1
Severity: serious

On 2019-07-27 14:42, Debian FTP Masters wrote:
> libghc-patience-doc_0.2.1.1-1_all.deb: has 1 file(s) with a timestamp too far 
> in the past:
>   usr/share/doc/libghc-patience-doc/changelog.gz (Thu Jan  1 00:00:00 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#933204: haskell-cgi_3001.3.0.3-1_s390x.changes REJECTED

[Aurelien Jarno]

Source: haskell-cgi
Version: 3001.3.0.3-1
Severity: serious

On 2019-07-27 14:40, Debian FTP Masters wrote:
> 
> 
> libghc-cgi-dev_3001.3.0.3-1_s390x.deb: has 1 file(s) with a timestamp too far 
> in the past:
>   usr/share/doc/libghc-cgi-dev/changelog.gz (Thu Jan  1 00:00:00 1970)
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#917292: ffmpeg: linking with libcrystalhd3 seem of no use at all

[Jonas Smedegaard]

Quoting James Cowgill (2019-07-27 11:12:00)
> Hi,
> 
> > ffmpeg currently links with libcrystalhd3.
> > 
> > It seems, however, that libcrystalhd3 is only really useful together 
> > with firmware-crystalhd, which was never really usable in Debian, 
> > leading to that package being dropped: 
> > https://bugs.debian.org/865978
> > 
> > If someone wants to revive CrystalHD in Debian, it seems a good 
> > place to start is 
> > https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update
> > 
> > I suggest to simply stop link with libcrystalhd3 until 
> > firmware-crystalhd reappear in Debian.
> 
> I've disables crystalhd.
> 
> Should we completely from libcrystalhd3 as well in that case?

Sorry, I fail to parse your last sentence above...


 - 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#933069: marked as done (libglib-perl: autopkgtest regression with GLib 2.60.x: GKeyFile comments no longer contain trailing newline)

[intrigeri]

Control: reopen -1

autopkgtests still fail on testing with 1.329-3. I've dived deeper
into the problem and found the root cause: the (patched) t/g.t adjusts
its expectations depending on what version of GLib we were compiled
against (in this case: sid's 2.60.5), while it should depend on what
version of GLib we're using at runtime. I'm preparing a fix that I'll
submit upstream.

Cheers,
-- 
intrigeri

Bug#933203: Phpmyadmin

[x9nico_YT]

Package: phpmyadmin

Hi, can you update the package to latest version please ? :)

Amically.

Bug#917292: ffmpeg: linking with libcrystalhd3 seem of no use at all

[James Cowgill]

Hi,

> ffmpeg currently links with libcrystalhd3.
> 
> It seems, however, that libcrystalhd3 is only really useful together
> with firmware-crystalhd, which was never really usable in Debian,
> leading to that package being dropped: https://bugs.debian.org/865978
> 
> If someone wants to revive CrystalHD in Debian, it seems a good place to
> start is https://www.mythtv.org/wiki/Broadcom_Crystal_HD#Feb._2014_Update
> 
> I suggest to simply stop link with libcrystalhd3 until firmware-crystalhd
> reappear in Debian.

I've disables crystalhd.

Should we completely from libcrystalhd3 as well in that case?

James



signature.asc
Description: OpenPGP digital signature

Bug#933202: Additional information

[sixerjman]

kernel: [155898.814801] xfdesktop[7896]: segfault at 10 ip b7052d52 sp
bfb1a070 error 4 in
+libglib-2.0.so.0.5800.3[b700+82000]