Bug#916266: gringo FTBFS: symbol differences

[Adrian Bunk]

Source: gringo
Version: 5.3.0-4
Severity: serious
Tags: ftbfs

Some recent change in unstable makes gringo FTBFS:

https://tests.reproducible-builds.org/debian/history/gringo.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gringo.html

...
   dh_makeshlibs
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/gringo/DEBIAN/symbols doesn't match completely 
debian/symbols
--- debian/symbols (gringo_5.3.0-4_amd64)
+++ dpkg-gensymbolsfvdYmA   2018-12-11 15:16:40.497532258 -1200
@@ -123,7 +123,7 @@
  
_ZNSt6vectorISt10unique_ptrIA_cSt14default_deleteIS1_EESaIS4_EE12emplace_backIJPcEEEvDpOT_@Base
 5.3.0
  
(optional=templinst|arch=mips)_ZNSt6vectorISt4pairIPKciESaIS3_EE12emplace_backIJS3_EEEvDpOT_@Base
 1
  
(optional=templinst)_ZNSt6vectorISt4pairIPKciESaIS3_EE17_M_realloc_insertIJS3_EEEvN9__gnu_cxx17__normal_iteratorIPS3_S5_EEDpOT_@Base
 1
- 
(optional=templinst|arch=!x32)_ZNSt6vectorISt4pairIS0_IjjEjESaIS2_EE17_M_realloc_insertIJS1_RjEEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 1
+#MISSING: 5.3.0-4# 
(optional=templinst|arch=!x32)_ZNSt6vectorISt4pairIS0_IjjEjESaIS2_EE17_M_realloc_insertIJS1_RjEEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 1
  (optional=templinst|arch=amd64 arm64 armel armhf hurd-i386 i386 
kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc powerpcspe ppc64 ppc64el 
s390x sh4 
x32)_ZNSt6vectorISt4pairIiiESaIS1_EE17_M_realloc_insertIJRKiS6_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 1
  (optional=templinst|arch=amd64 arm64 armel armhf hurd-i386 i386 
kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc powerpcspe ppc64 ppc64el 
s390x sh4 
x32)_ZNSt6vectorISt4pairIiiESaIS1_EE17_M_realloc_insertIJiiEEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 1
  
(optional=templinst)_ZNSt6vectorISt4pairIijESaIS1_EE12emplace_backIJRS1_EEEvDpOT_@Base
 1
@@ -179,7 +179,7 @@
  (arch=!armel !riscv64)_ZTISt11_Mutex_baseILN9__gnu_cxx12_Lock_policyE2EE@Base 
1
  (arch=armel 
riscv64)_ZTISt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE1EE@Base 1
  (arch=!armel 
!riscv64)_ZTISt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE@Base 1
- _ZTISt19_Sp_make_shared_tag@Base 1
+#MISSING: 5.3.0-4# _ZTISt19_Sp_make_shared_tag@Base 1
  (arch=armel 
riscv64)_ZTISt23_Sp_counted_ptr_inplaceIjSaIjELN9__gnu_cxx12_Lock_policyE1EE@Base
 1
  (arch=!armel 
!riscv64)_ZTISt23_Sp_counted_ptr_inplaceIjSaIjELN9__gnu_cxx12_Lock_policyE2EE@Base
 1
  (arch=armel riscv64)_ZTSN9__gnu_cxx7__mutexE@Base 1
@@ -196,6 +196,7 @@
  
_ZTVNSt6thread11_State_implINS_8_InvokerISt5tupleIJSt10mem_fun1_tIvN5Clasp2mt13ParallelSolveEjEPS6_jEE@Base
 1
  (arch=armel 
riscv64)_ZTVSt23_Sp_counted_ptr_inplaceIjSaIjELN9__gnu_cxx12_Lock_policyE1EE@Base
 1
  (arch=!armel 
!riscv64)_ZTVSt23_Sp_counted_ptr_inplaceIjSaIjELN9__gnu_cxx12_Lock_policyE2EE@Base
 1
+ _ZZNSt19_Sp_make_shared_tag5_S_tiEvE5__tag@Base 5.3.0-4
  clingo_add_string@Base 1
  clingo_assignment_decision@Base 1
  clingo_assignment_decision_level@Base 1
dh_makeshlibs: failing due to earlier errors
make: *** [debian/rules:58: binary] Error 2

Bug#915053: gitlab: Err 500 when go to the project page(any project)

[Dragos Jarca]

Maby is a good idea to add a check task to see if /var/lib/gems is 
incompatible wit gitlab.


Dragos Jarca

On 12.12.2018 13:09, Dragos Jarca wrote:

Ok...after a lot of research of my problem, solved it!

Th problem was /var/lib/gems/2.5.0 that have multiple vesrsions of 
same gem. I renamed this dir and reconfigured gitlab. Now all is ok!


Just wait to next varsion(11.5.3) in experimental. The last version in 
experimental I think is a goog option.


Dragos Jarca

On 09.12.2018 11:36, Dragos Jarca wrote:

Hi

Updated to 11.4.9, but the problem exists.

Seems tat gitlab API not work in all forms described in documentation.

root@omv:/etc/gitlab# curl --header 'PRIVATE-TOKEN: ***' 
https://gitlab.dynamicpuzzle.ro/api/v4/projects/14/repository/files/db%2Fupd%2Esql/raw?ref=master
alter table ws add column if not exists isactive TINYINT not null 
default 0;

alter table ws add column if not exists apikey varchar(128);
root@omv:/etc/gitlab# curl 
https://gitlab.dynamicpuzzle.ro/api/v4/projects/14/repository/files/db%2Fupd%2Esql/raw?ref=master?private_token=***

{"message":"404 Project Not Found"}
root@omv:/etc/gitlab# curl --header '_gitlab_session=*' 
https://gitlab.dynamicpuzzle.ro/api/v4/projects/14/repository/files/db%2Fupd%2Esql/raw?ref=master

{"message":"404 Project Not Found"}

In web interface _gitlab_session is responsable, and seems not no work.
Strange is that:

https://gitlab.dynamicpuzzle.ro/meteo/meteo/blob/master/db/upd.sql
not work and return ERR 500

and

https://gitlab.dynamicpuzzle.ro/api/v4/projects/14/repository/files/db%2Fupd.sql/raw?ref=master 



work and return content of file.

I can work in external git clients, but cannot see thhe project files 
and commits in the web interface.


Dragos Jarca

On 06.12.2018 10:00, Pirate Praveen wrote:

On 12/4/18 10:03 PM, Dragos Jarca wrote:

Yes, tried on different browsers, different os, different browsers on
moile phones, smart tb browser, etc.

I have just uploaded gitlab 11.4.9 to experimental. See if that fixes
the issues.

Bug#916220: saidar: segfault after couple of minutes

[Tim Bishop]

I have been able to replicate this (on Ubuntu 18.04), but only on some
systems. In particular, it didn't fail on a test VM, but did on a larger
server.

This commit appears to resolve the issue in my testing:

https://github.com/i-scream/libstatgrab/commit/84fd8c38ee4feb0117ed22ab56f6b46661411ec6

And I'd recommend this one too:

https://github.com/i-scream/libstatgrab/commit/d4ecd6d440534d0ca14448c602f85fc263f45cb6

See the upstream bug here, which includes for full stack trace with
debugging symbols:

https://github.com/i-scream/libstatgrab/issues/102

Tim.

On Tue, Dec 11, 2018 at 10:54:03PM +0100, Bernhard Übelacker wrote:
> Hello Mindaugas Celiesius,
> I just tried to reproduce the crash.
> Unfortunately it did not crash in my test.
> 
> Therefore I assume the information you provided is not
> sufficient for the Maintainer to correct the program.
> 
> Maybe you could install a core dump collector like systemd-coredump.
> When another crash happens you can enumerate the recorded crashes by:
>   coredumpctl list
> 
> And possibly provide the information given by:
>   coredumpctl gdb
> 
> This output would be even better if saidar-dbgsym from the
> debug symbol repositories described in [1].
> 
> Kind regards,
> Bernhard
> 
> [1] https://wiki.debian.org/HowToGetABacktrace

-- 
Tim Bishop
http://www.bishnet.net/tim/
PGP Key: 0x6C226B37FDF38D55

Bug#916267: libgtk-3-0: Cannot print to IPP printers from the GTK dialog

[Brian Potkin]

Package: libgtk-3-0
Version: 3.24.1-3
Severity: grave
Tags: upstream
Justification: renders IPP printers unusable without other packages (CUPS and 
cups-browsed)



An IPP printer is allocated the destination "print" in the dialog and
is tagged as "Rejecting Jobs". This is irrespective of whether its TXT
record pdl key has application/PDF in it or not. Furthermore, the dialog
seems incapable of displaying more than one entry for IPP printers on
the network.

More detail is in the upstream bug report.

Regards,

Brian.

Bug#916227: dictionaries-common: ispell-find-hunspell-dictionaries fails to find installed dictionaries

[Agustin Martin]

On Wed, Dec 12, 2018 at 11:53:29AM +0100, Sébastien Hinderer wrote:
> Agustin Martin (2018/12/12 11:31 +0100):
> > On Tue, Dec 11, 2018 at 06:07:41PM +0100, Sebastien Hinderer wrote:
> > > Package: dictionaries-common
> > > Version: 1.28.1
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > For some reason ispell-find-hunspell-dictionaries does not find the 
> > > installed hunspell dictionaries, leading ispell-hunspell-dictionary-alist 
> > > to be nil.
> > 
> > Hi,
> > 
> > GNU Emacs uses its own ispell.el and flyspell.el files, not those provided
> > by dictionaries-common, which are only for XEmacs.
> 
> Oh, I wasn't aware of that, sorry.

No problem. dictionaries-common used to ship {ispell,flyspell}.el also for
GNU Emacs, containing the most recent version patched to work with XEmacs
and older Emacs, but that is no longer true because of compatibility issues.

> > ispell.el has recently
> > been patched in Emacs to work around this issue, but since XEmacs does not
> > use hunspell auto-detection I do not think this change is needed in
> > dictionaries-common ispell.el.
> 
> OK so I am using GNU Emacs, not xemacs. IS there a way for me to get the
> correct (patched) version of ispell.el by installing debian packages, or
> do I have to do something different, like installing an upstream version
> of GNU Emacs?

One possibility is to wait for Emacs 26 to be packaged. I think this change
was not pushed to the Emacs25 (master) branch. Installing Emacs from
upstream is an overkill and will become old at some time.

A temporary hack would be to add an entry to your .emacs file, something
like (if none is explicitly set)

;; 
(setq ispell-local-dictionary-alist
  (append ispell-local-dictionary-alist
  '(
("castellano8"
 "[[:alpha:]]"
 "[^[:alpha:]]"
 "[-]" t ("-d" "es_ES") nil utf-8)
)))
;; ---

adapted to your language. Do not forget to remove it once either hunspell or
Emacs are fixed.

Regards,

-- 
Agustin

Bug#916267: libgtk-3-0: Cannot print to IPP printers from the GTK dialog

[Simon McVittie]

Control: severity -1 important

On Wed, 12 Dec 2018 at 11:20:04 +, Brian Potkin wrote:
> Justification: renders IPP printers unusable without other packages (CUPS and 
> cups-browsed)

This sounds like an important bug, but it does not make GTK+ entirely
useless (you can still use graphical applications that don't involve
printing, or print via CUPS), so it isn't grave.

> More detail is in the upstream bug report.

Which upstream bug report?

smcv

Bug#916268: lastpass-cli: missing build dependency on pkg-config

[Adrian Bunk]

Source: lastpass-cli
Version: 1.3.1-5
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/lastpass-cli.html

...
CMake Error at 
/usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.13/Modules/FindPkgConfig.cmake:39 
(find_package_handle_standard_args)
  CMakeLists.txt:8 (find_package)

Bug#916269: RM: gnat-gps [i386 armhf armel mips mipsel kfreebsd-i386 hurd-i386] -- NBS; no longer built on 32bit

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

gnat-gps (18-5) unstable; urgency=medium

  * Disable 32 bits builds, affected by #913371.
The problem was hidden by some 64 bits chroot.

 -- Nicolas Boulenguez   Tue, 11 Dec 2018 14:43:22 +0100

Bug#877633: this bug stop sshd

[Sergey B Kirpichev]

On Wed, 12 Dec 2018 11:13:24 + marc marc  wrote:
> could the priority of the fix be increased accordingly ?

Are you about backporting existing fix to stable?  I'm not sure,
that the problem is too severe.

Bug#916034: sl-modem-dkms: module FTBFS for 4.18.0-3-amd64, 4.9.0-8-amd64

[أحمد المحمودي]

On Sun, Dec 09, 2018 at 03:06:49PM +0100, Andreas Beckmann wrote:
> old_st7554.c:49:10: fatal error: linux/init.h: No such file or directory
> old_st7554.c:48:26: fatal error: linux/module.h: No such file or directory
---end quoted text---

Are you sure that you havethe appropriate linux headers package 
installed ?

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


signature.asc
Description: PGP signature

Bug#916262: staden-io-lib: data/xx#unsorted.sam fails randomly

[Andreas Tille]

On Wed, Dec 12, 2018 at 11:48:30AM +, James Bonfield wrote:
> A simple method is probably the best way to go.

+1

   Andreas.
 

-- 
http://fam-tille.de

Bug#915942: libext2fs2: ships empty directory /usr/share/doc/libext2fs

[Andreas Beckmann]

On 2018-12-12 04:24, Theodore Y. Ts'o wrote:
>> PS: and now I still need to understand why this disappears on some
>> stretch->buster upgrade paths ...
> 
> For stretch these documents were installed in /usr/share/e2fslibs.
> This was a screw up as part of the rename of e2fslibs to libext2fs2.

No problem on your side, but #915943, a package doing roughly
  rmdir `find /usr/share/doc -type d -empty`


Andreas

Bug#916262: staden-io-lib: data/xx#unsorted.sam fails randomly

[James Bonfield]

On Wed, Dec 12, 2018 at 11:56:28AM +0100, Andreas Tille wrote:
> besides the remaining build issues on some architectures there
> is a new bug report about random failures.
> 
> I hope you will have a clue about this.

They all seem to be the same cause, which I haven't investigated yet.
One solution is just to give up with auto-generating data and bundle a
larger corpus of test data.

The problem comes from the auto-generation step producing files of
differing length.  I hard coded the random number generator and also
put the test system into serial mode so it cannot attempt to run
multiple data generation steps in parallel, but it hasn't cured it.

A simple method is probably the best way to go.

James
-- 
James Bonfield (j...@sanger.ac.uk)
The Sanger Institute, Hinxton, Cambs, CB10 1SA


-- 
 The Wellcome Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE. 

Bug#916271: RM: debops/experimental -- ROM; not planned to go to unstable

[Daniel Stender]

Package: ftp.debian.org
Severity: normal

Hi FTP,

please remove Debops [1] from Experimental. There is not going to be an
update, I don't have the time to fix it for unstable (see #889297).

Thanks,
Daniel Stender

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

Bug#915136: More info

[Pirate Praveen]

On 12/11/18 9:51 AM, Pirate Praveen wrote:
>> Maybe we need to report the bug to upstream too? I think, probably the
>> bug
>> are debian-specific but they can give us some new information.
> 
> Yes, I think only upstream can help here.

Try the solution mentioned here,

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=915053#67



signature.asc
Description: OpenPGP digital signature

Bug#916272: cylc: binary-any FTBFS

[Adrian Bunk]

Source: cylc
Version: 7.8.0-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=cylc&suite=sid

...
# shipped separately
find debian/python-cylc -name glyphicons-halflings-regular.ttf -delete
mkdir -p debian/cylc/usr/share/cylc
if test -f debian/python-cylc/usr/lib/python2.7/dist-packages/cylc/job.sh ; 
then \
mv debian/python-cylc/usr/lib/python2.7/dist-packages/cylc/job.sh 
debian/cylc/usr/share/cylc/job.sh ;  \
chmod +x debian/cylc/usr/share/cylc/job.sh ; \
fi
chmod +x debian/cylc/usr/share/bash-completion/completions/cylc-bash-completion
chmod: cannot access 
'debian/cylc/usr/share/bash-completion/completions/cylc-bash-completion': No 
such file or directory
make[1]: *** [debian/rules:41: override_dh_fixperms] Error 1


This can be reproduced with
  dpkg-buildpackage -B

Bug#916270: fortunes-eo: extremely racist fortune present/estas treege racisma fortuno

[tristan alexander mc leay]

Package: fortunes-eo
Version: 20020729b-1
Severity: normal

Dear Maintainer, (English above/Esperanto sekvas)

The fortunes-eo package contains the following fortune:

"Lavu tutan jaron, negro ne blankiĝos"
i.e. "Wash for a whole year, a negro won't become white"

It uses both offensive language (Prevo marks "negro" as evitinda) and offensive
imagery to make its point. It is not appropriate in Debian.

Kara Zorgulo, (English above/Esperanto ĉi tie)

La pakaĵo fortunes-eo enhavas la sekvantan fortunon:

"Lavu tutan jaron, negro ne blankiĝos"

Ĝi uzas kaj malĝentilegan idiomon (Prevo rigardas "negron" kiel evitinda) kaj
malĝentilegan bildecon por fari ĝian celsignifon. Ĝi ne estas taŭga en
Debiano.



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

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

Versions of packages fortunes-eo depends on:
ii  fortune-mod  1:1.99.1-7+b1

fortunes-eo recommends no packages.

fortunes-eo suggests no packages.

-- no debconf information

Bug#916267: libgtk-3-0: Cannot print to IPP printers from the GTK dialog

[Brian Potkin]

On Wed 12 Dec 2018 at 11:28:41 +, Simon McVittie wrote:

> Control: severity -1 important
> 
> On Wed, 12 Dec 2018 at 11:20:04 +, Brian Potkin wrote:
> > Justification: renders IPP printers unusable without other packages (CUPS 
> > and cups-browsed)
> 
> This sounds like an important bug, but it does not make GTK+ entirely
> useless (you can still use graphical applications that don't involve
> printing, or print via CUPS), so it isn't grave.

Fair enough.
 
> > More detail is in the upstream bug report.
> 
> Which upstream bug report?

It's in the record now. I was waiting for a bug number to be allocated.

-- 
Brian.

Bug#909649: gnuplot: out of range data in tikz terminal when scaling y with two decimals

[Agustin Martin]

Control: forward -1 https://sourceforge.net/p/gnuplot/bugs/2084/

On Wed, Sep 26, 2018 at 12:20:16PM +0200, Agustin Martin wrote:
> Yesterday I noticed a strange behavior in the tikz terminal when I use more
> than one non null decimal in y scale as in
> 
>  set term tikz monochrome originreset scale 1.05,0.65
>  set term tikz monochrome originreset scale 1.05,0.61
> 
> This results in y values going crazy and making LateX fail because of data
> out of range; e.g. for 0.61,

Similar problem has been reported upstream for the x size in cm. Problems
seem to have the same origin.

Marking as forwarded.

-- 
Agustin

Bug#916273: RFS: xpad/5.2.0-1 -- sticky note application for X

[JCF Ploemen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for "xpad":

  Package name: xpad
  Version : 5.2.0-1
  Upstream Author : Arthur Borsboom
  URL : https://launchpad.net/xpad
  License : GPL-3+
  Section : x11

It builds a single binary package:
  xpad - sticky note application for X

Mentors URL:
  https://mentors.debian.net/package/xpad

Download with dget:
  dget -x https://mentors.debian.net/debian/pool/main/x/xpad/xpad_5.2.0-1.dsc


Changes since last upload:
  * New upstream release.
  * Watch: re-add upstream signing key A6F2322B to the collection.
  * Rules: remove override of dh_autoreconf, missing makefile is back.
  * d/clean: remove, no longer needed.


Regards.


pgpxoJlDIDhtu.pgp
Description: OpenPGP digital signature

Bug#916274: "apt install mypackage" should register mypackage as explicitly installed

[Harald Dunkel]

Package: apt
Version: 1.4.8

I ran "apt install symlinks" on Stretch, even though it was
already installed due to a package dependency. When this package
dependency changed (the referring package was removed),
symlinks was removed automagically. :-(

This is not as expected. "apt install mypackage" should mark
mypackage as explicitly installed, even if the package is
already in.


Regards
Harri

Bug#915094: Additional information.

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

>Is this true even if you reboot?
The problem does not happen at boot. It happens randomly after you have 4-5 
days of uptime, especially with long, CPU-heavy processes already running (like 
ZPAQ compression).
I still do not know the exact cause, but it happens only with new processes, as 
soon as it starts. Existing processes are not affected.
>What if you force an fsck check on the file system?
I have not tested it, but I do not want to take the risk of checking a running 
system.
I reformatted the FS without that feature, and it does not seem to happen after 
a week. Maybe the problem is within the EXTFS driver?
--
"And in the naked light, I saw ten thousand people, maybe m\
ore. People talking without speaking, people hearing withou\
t listening. People writing songs that voices never shared,\
no one dared disturb the sound of silence."
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAQBQJcEQIWCRDYtWA5RV10HwAAR3sH/1qqatN9KerwnfLm82zr
mcZJdDdInoFoyPcUIE7uFiInmT6e5k+nVo5pxVY9+2FamLFpVE3MoChUon0z
JHywMUeC8rvmZMnHq1JH0Z9RSdRvv430w/OdcqDBa71Bm4XQMn3eVMQcTLCo
1m8E8PvO++4ZB1YC1h0FzCnp92qeLoG1nUu1CYf7Gcdx1rDeOVytnpcJV9tO
hkN7Stlf9QMxjthql/fkRTe34D0VO4kiE6yMQJzW7RLiwfa0siM13yTEk+OS
vQsl2UXj8Q80a/MrAlk/uV9mCWEShufwZyk78tY98t+PMwiow8MXTPdbEWE5
Xso0RgTFTUyzB4d2BoawKgY=
=EGHR
-END PGP SIGNATURE-



publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc
Description: application/pgp-keys


publickey - pthfdr@protonmail.ch - 0xAB77ABA4.asc.sig
Description: PGP signature

Bug#916034: sl-modem-dkms: module FTBFS for 4.18.0-3-amd64, 4.9.0-8-amd64

[Andreas Beckmann]

On 2018-12-12 12:46, أحمد المحمودي wrote:
> On Sun, Dec 09, 2018 at 03:06:49PM +0100, Andreas Beckmann wrote:
>> old_st7554.c:49:10: fatal error: linux/init.h: No such file or directory
>> old_st7554.c:48:26: fatal error: linux/module.h: No such file or directory
> ---end quoted text---
> 
> Are you sure that you havethe appropriate linux headers package 
> installed ?

linux-headers-4.18.0-3-amd64 is installed, but maybe it has changed its
layout?

There is
/usr/src/linux-headers-4.18.0-3-amd64/include/generated/uapi/linux/version.h

You you get the compile flags from Kbuild, or do you reinvent them on
your own?


Andreas

Bug#916274: "apt install mypackage" should register mypackage as explicitly installed

[Julian Andres Klode]

On Wed, Dec 12, 2018 at 01:47:52PM +0100, Harald Dunkel wrote:
> Package: apt
> Version: 1.4.8
> 
> I ran "apt install symlinks" on Stretch, even though it was
> already installed due to a package dependency. When this package
> dependency changed (the referring package was removed),
> symlinks was removed automagically. :-(
> 
> This is not as expected. "apt install mypackage" should mark
> mypackage as explicitly installed, even if the package is
> already in.

That's what it already does; unless it is an upgrade, then it
does not change the state (or, it only changes the autostate if there
is no other state change it can do).

FWIW, I disagree with this completely. install should not ever
change the auto flag of already installed packages just because
I mentioned them, I always end up marking half my system (well, ok,
more like 10%) manually installed by accident because I have to specify
additional packages to hint in an install request.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

Bug#916275: crm114 FTCBFS: builds for the wrong architecture

[Helmut Grohne]

Source: crm114
Version: 20100106-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

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

Helmut
diff --minimal -Nru crm114-20100106/debian/changelog 
crm114-20100106/debian/changelog
--- crm114-20100106/debian/changelog2018-07-11 15:07:19.0 +0200
+++ crm114-20100106/debian/changelog2018-12-12 14:13:20.0 +0100
@@ -1,3 +1,10 @@
+crm114 (20100106-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 12 Dec 2018 14:13:20 +0100
+
 crm114 (20100106-8) unstable; urgency=medium
 
   * Standards 4.1.5 (no real change).
diff --minimal -Nru crm114-20100106/debian/rules crm114-20100106/debian/rules
--- crm114-20100106/debian/rules2016-01-19 20:17:54.0 +0100
+++ crm114-20100106/debian/rules2018-12-12 14:13:19.0 +0100
@@ -14,17 +14,13 @@
 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
 endif
-ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
-NUMJOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
-MAKEFLAGS += -j$(NUMJOBS)
-endif
 
 build: build-arch build-indep
 build-arch: build-stamp
 build-indep: build-stamp
 build-stamp:
dh_testdir
-   $(MAKE) $(MAKEFLAGS) CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
+   dh_auto_build --parallel -- CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)"
touch build-stamp
 
 clean: 

Bug#761817: Fwd: Fwd: [info] Upcoming Debian repository signing key expiration

[Wilfried Goesgens]

Hi Christop,
Thanks for giving us a heads up regarding the key life time.
I've read through:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761817

(which is probably related to this mail?)
and have some remarks:

 - V8 does not provide a stable API across versions, so you need 
exactly the version that we use (or that release series).
 - we apply some patches to V8, mostly build system related, however 
some of them patch away some "Resources empty? Geronimo" code which 
is not nice to have in a database - that will auto-terminate without any 
feedback then.
 - Rocksdb - same here. While we send patches of our changes upstream, 
they may only become available in later versions which may not be api 
compatible - so if I strongly sugest to use the version shipped with 
arangodb.
 - Boost - you most probably need the version we use, it should be ok 
to use a system provided version
 - snappy - whatever is newer probably is better. needs to work with 
rocksdb.
 - s2 (not yet in your list) - probably needs to be exactly the shipped 
version with ArangoDB 3.4

 - curl - you can probably use newer versions.
 - velocypack - our binary json representation 
https://github.com/arangodb/velocypack/ - to be honest we didn't yet 
work with tags here so you could identify whats released with which 
arangodb - we need to fix this.

 - fuerte - our binary transport c++ library - issues see velocypack.
 - iresearch - needs to be a matching version, however upstream is also 
maintained by us.
 - ICU - we use the one bundled with V8 - don't know whether there is a 
good way to include a system one


Up to arangodb we used cpack to generate debian packages, accompanying 
scripts can be found in Installation/debian; This is probably why you 
don't find a debian/ directory.
With ArangoDB 3.4 we migrated to statically linked binaries with libmusl 
- compile once, bundle into tar/rpm/deb; The currently used debian 
scripts can be found here: 
https://github.com/arangodb/oskar/tree/master/debian/3.4


Since we need to be able to ship bugfix versions, we do this with the 
third version digit incrementing. So Arangodb 3.3.20 can be treated as a 
bugfix version of 3.3.19.


The current arangodb cmake build is intended to bundle and bring all 
required 3rd party libraries, I don't know how well it can be configured 
to prefer system installed ones.


If you have more questions regarding compiling arangodb don't hesitate 
to ping me via slack or github issues.


Cheers,
Willi

ps: there are only rspec / ruby tests remaining which probably shouldn't 
be represented in the final package, the ruby tag of the initial wnpp 
can probably be removed.



-- Forwarded message -
From: *Christoph Biedl* >

Date: Mi., 12. Dez. 2018 um 01:11 Uhr
Subject: [info] Upcoming Debian repository signing key expiration
To: Frank Celler mailto:i...@arangodb.com>>


Hello,

thanks for providing arangodb packages for Debian, and especially for
providing a GPG signature for these. However, there is a problem coming:
The key as provided at

https://download.arangodb.com/arangodb34/DEBIAN/Release.key

has an expiration date less than six months into the future:

| $ gpg --list-key EA93F5E56E751E9B
+ pub   rsa4096 2015-06-02 [SC] [expires: 2019-06-01]
|       CD8CB0F1E0AD5B52E93F41E7EA93F5E56E751E9B
| uid           [ unknown] Frank Celler (ArangoDB Debian Repository) 
mailto:i...@arangodb.com>>

+ sub   rsa4096 2015-06-02 [E] [expires: 2019-06-01]

From my experience, deploying a new signing key is a lengthy process,
so I'm asking you to start it as soon as possible. Unfortunatley, the
risk users out there will not install it in time is already quite high.

Regards,

    Christoph

Bug#916052: [b...@debian.org] Bug#916052: alsa-oss FTBFS with glibc 2.28

[Elimar Riesebieter]

Control: forwarded -1 alsa-de...@alsa-project.org


Hi,

could you please investigate? It seems as alsa-oss doesn't built
with glibc 2.28.

Thanks in advance
Elimar
-- 
  Learned men are the cisterns of knowledge,
  not the fountainheads ;-)
--- Begin Message ---
Source: alsa-oss
Version: 1.1.6-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/alsa-oss.html

...
In file included from alsa-oss.c:736:
stdioemu.c:40:10: fatal error: libio.h: No such file or directory
 #include 
  ^
compilation terminated.
make[2]: *** [Makefile:517: alsa-oss.lo] Error 1

--- End Message ---

Bug#916276: glibc: Please add prelimenary patch to fix regression on qemu-user

[John Paul Adrian Glaubitz]

Source: glibc
Version: 2.28-2
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: m68k

Hi!

In 298d0e3129c0b5137f4989275b13fe30d0733c4d ("Consolidate Linux getdents{64}
implementation"), upstream made changes to the getdents{64} implementation
which breaks glibc on qemu-user.

The result of that is that applications like dash behave erratically, such that
for example pattern expansion no longer works. This means that "*" is not 
expanded
to filenames:

$ ls -l old/
total 148
-rw-r--r-- 1 glaubitz fbedv 16188 Jun 21  2003 chardraw.c
-rw-r--r-- 1 glaubitz fbedv  7922 Jun 21  2003 fillpoly.c
-rw-r--r-- 1 glaubitz fbedv   948 Jun 21  2003 readme
-rw-r--r-- 1 glaubitz fbedv 31860 Jun 21  2003 to_atari.c
-rw-r--r-- 1 glaubitz fbedv 13093 Jun 21  2003 to_eps.c
-rw-r--r-- 1 glaubitz fbedv  6631 Jun 21  2003 to_mf.c
-rw-r--r-- 1 glaubitz fbedv  3261 Jun 21  2003 to_pbm.c
-rw-r--r-- 1 glaubitz fbedv 12854 Jun 21  2003 to_pcx.c
-rw-r--r-- 1 glaubitz fbedv 10657 Jun 21  2003 to_pdf.c
-rw-r--r-- 1 glaubitz fbedv  6697 Jun 21  2003 to_pm.c
-rw-r--r-- 1 glaubitz fbedv  9463 Jun 21  2003 to_x11a.c
-rw-r--r-- 1 glaubitz fbedv 10405 Jun 21  2003 to_x11.c
$ ls -l old/*
/bin/ls: cannot access 'old/*': No such file or directory
$

dash is just one example. Other affected applications are cmake or qmake.
The attached prelimenary patch by James Clarke fixes the problem for me.

Thanks,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=23960

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
Description: Fix regression of glibc 2.28 on qemu-user
 The new getdents{64} implementation in glibc 2.28 breaks
 qemu-user making certain applications like dash fail to
 work properly.
 .
Author: James Clarke 
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23960
Last-Update: 2018-12-11

Index: glibc-2.28/sysdeps/unix/sysv/linux/alpha/getdents.c
===
--- glibc-2.28.orig/sysdeps/unix/sysv/linux/alpha/getdents.c
+++ glibc-2.28/sysdeps/unix/sysv/linux/alpha/getdents.c
@@ -1,11 +1,13 @@
 /* Although Alpha defines _DIRENT_MATCHES_DIRENT64, 'struct dirent' and
'struct dirent64' have slight different internal layout with d_ino
being a __ino_t on non-LFS version with an extra __pad field which should
-   be zeroed.  */
+   be zero.  */
 
 #include 
 #undef _DIRENT_MATCHES_DIRENT64
 #define _DIRENT_MATCHES_DIRENT64 0
-#define DIRENT_SET_DP_INO(dp, value) \
-  do { (dp)->d_ino = (value); (dp)->__pad = 0; } while (0)
+#define DIRENT_CHECK_DP_INO_SIZE(kdp, dp) \
+  (sizeof ((kdp)->d_ino) == sizeof ((dp)->d_ino) + sizeof ((dp)->__pad))
+#define DIRENT_CHECK_DP_INO(dp) \
+  (dp)->__pad == 0
 #include 
Index: glibc-2.28/sysdeps/unix/sysv/linux/getdents.c
===
--- glibc-2.28.orig/sysdeps/unix/sysv/linux/getdents.c
+++ glibc-2.28/sysdeps/unix/sysv/linux/getdents.c
@@ -24,92 +24,85 @@
 # include 
 # include 
 
-# ifndef DIRENT_SET_DP_INO
-#  define DIRENT_SET_DP_INO(dp, value) (dp)->d_ino = (value)
+/* For Linux we need a special version of this file since the
+   definition of `struct dirent' is not the same for the kernel and
+   the libc; the kernel places d_type after the variable-length d_name,
+   but we place it at a fixed offset just before d_name.  */
+
+struct kernel_dirent
+  {
+__syscall_ulong_t d_ino;
+__syscall_ulong_t d_off;
+unsigned short d_reclen;
+char d_name[256];
+  };
+
+# ifndef DIRENT_CHECK_DP_INO_SIZE
+#  define DIRENT_CHECK_DP_INO_SIZE(kdp, dp) \
+(sizeof ((kdp)->d_ino) == sizeof ((dp)->d_ino))
 # endif
 
-/* Pack the dirent64 struct down into 32-bit offset/inode fields, and
-   ensure that no overflow occurs.  */
 ssize_t
 __getdents (int fd, char *buf, size_t nbytes)
 {
-  union
-  {
-/* For !_DIRENT_MATCHES_DIRENT64 kernel 'linux_dirent64' has the same
-   layout of 'struct dirent64'.  */
-struct dirent64 k;
-struct dirent u;
-char b[1];
-  } *kbuf = (void *) buf, *outp, *inp;
-  size_t kbytes = nbytes;
-  off64_t last_offset = -1;
   ssize_t retval;
+# ifdef DIRENT_CHECK_DP_INO
+  off64_t last_offset = -1;
+# endif
 
-# define size_diff (offsetof (struct dirent64, d_name) \
-   - offsetof (struct dirent, d_name))
-  char kbuftmp[sizeof (struct dirent) + size_diff];
-  if (nbytes <= sizeof (struct dirent))
-kbuf = (void*) kbuftmp;
-
-  retval = INLINE_SYSCALL_CALL (getdents64, fd, kbuf, kbytes);
-  if (retval == -1)
-return -1;
-
-  /* These two pointers might alias the same memory buffer.
- Standard C requires that we always use the same type for them,
- so we must use the union type.  */
-  inp = kbuf;
-  outp = (void *) buf;
-
-  while (&inp->b < &kbuf->b + retval)
+  /* The d_ino and d_off fields in kernel_dirent and dirent

Bug#916260: gparted mounts partition without protection

[Phillip Susi]

On 12/12/2018 3:50 AM, Marc Lehmann wrote:
> Package: gparted
> Version: 0.25.0-1+b1
> Severity: normal
> 
> Dear Maintainer,
> 
> for some operations, gparted mounts partitions under /tmp/gparted-XX 
> without any protection
> against access. This makes these partitions potentially accessible to other 
> users on the system while
> the operation runs.
> 
>* What led up to the situation?
> 
> Resizing a btrfs partition.
> 
>* What was the outcome of this action?
> 
> While resizing, the partion was mounted under /tmp/gparted-BSeLY6,
> accessible to all users, potentially allowing other users to read or write
> the data:

I'm not sure this can be considered a bug.  There are several ways the
user could have the filesystem mounted in a non temporary manner and if
the permissions of the filesystem allow them access, then they can
access it.





signature.asc
Description: OpenPGP digital signature

Bug#874727: New version of coin3

[Leopold Palomo-Avellaneda]

Hi,

see:

https://lists.debian.org/debian-science/2018/12/msg00028.html

Cheers,

Leopold


-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?



signature.asc
Description: OpenPGP digital signature

Bug#912711: Bug#912656: ITS: python-fs

[Jeremy Bicha]

Control: tags -1 +pending
Control: block 915656 by 912711

I have uploaded both python-fs and python-backports.os to the NEW queue for you.

Thanks,
Jeremy Bicha

Bug#916277: alot: please package new upstream release 0.8

[Jonas Smedegaard]

Package: alot
Version: 0.7-2
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

alot 0.8 is out, with exciting changes - esp. notmuch named queries.

Please package it.

...or tell me if ok that I add myself as co-maintainer and do it. :-)

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwRFcIACgkQLHwxRsGg
ASHJ6hAAn6qQpqPkP0MwLaa0VzxtkLTJ83ijlgZATsyv1tObp0hJUX0cbMwK4/GO
/c9LxPuueIoF/mtFGd9xmPqFfro67I0K1adlXzg1XqeLH0QgNavV63Othkg+ZeEl
YqtHdl0JXzNe+uMiw/YsvUwze6O9R5i/JTZ6rHVax73lfDRigxW1Kaq6iOYl6Kfy
KCQV/rmgVDuuKxGa4/b/TNjyKCy4I1S+DwBpVrxmWAz8+4c9am4Rp8cX+LI52iRZ
7IIX5+HTuPK+0BNzteHoTSOh8vct4TISnkCYy1Cb56WpKqUtmH3MhBKohMQ3g0KF
Xz0Xo+7eNjujBJwGjggBdcZlHAG21WBosufYJyQqG6DXflfNxmxSj0KoxTsZMeZh
jONgVSXjT8jCKATfZFexcpzQaQtl0+wfHt7ulrRJQD2WrIWUjNE2NLvxr2Ripokk
eU3TvqnlMFaNtSSuXFKrwcvKRruEEF6qT3QTSa/8mStSBqbYSHnVqNrFQOIVfLAu
3DgJosbPsmguhBd+4Ydu7TByRSRQvglwh95Pxhl9FdMv2erD//H7tWPALjh+imTh
vdrB0xg8364l+5rIXkp3cSesGw86vjnISvN9tFoz4YBQwhrySUOsnwNXQGqLzwpN
MhsSFuf9AHrzv96CMtPtlZ6mP7XtdpUSJlJpq45QUz2yoGY5FEg=
=Jp8q
-END PGP SIGNATURE-

Bug#916274: "apt install mypackage" should register mypackage as explicitly installed

[Harald Dunkel]

Hi Julian,

On 12/12/18 1:56 PM, Julian Andres Klode wrote:


That's what it already does; unless it is an upgrade, then it
does not change the state (or, it only changes the autostate if there
is no other state change it can do).



Confirmed. I saw this too late.

Nevertheless, aptitude removed the symlinks package. Are there 2
flags in the database indicating whether a package was installed
automatically or explicitly?

Do you think this report should be reassigned to aptitude?


FWIW, I disagree with this completely. install should not ever
change the auto flag of already installed packages just because
I mentioned them, I always end up marking half my system (well, ok,
more like 10%) manually installed by accident because I have to specify
additional packages to hint in an install request.



My suggestion here would be to make this configurable.


Regards
Harri

Bug#916278: qemu: CVE-2018-19665

[Salvatore Bonaccorso]

Source: qemu
Version: 1:3.1+dfsg-1
Severity: important
Tags: security upstream
Forwarded: https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03570.html

Hi,

The following vulnerability was published for qemu.

CVE-2018-19665[0]:
| The Bluetooth subsystem in QEMU mishandles negative values for length
| variables, leading to memory corruption.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-19665
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-19665
[1] https://lists.gnu.org/archive/html/qemu-devel/2018-11/msg03570.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#909497: CUDA 10 available now

[Graham Inggs]

On 2018/12/11 21:51, Andreas Beckmann wrote:

Which packages
* can be binNMUed (manually by me or another DD, not by the release team)
* need sourceful uploads
* should get sourceful uploads to change ... and ...
?


eztrace-contrib, hwloc-contrib and starpu-contrib all built with no 
changes required, so I guess can be binNMU'd.


pycuda built with the patch from #914804 (already in git)

caffe-contrib and lua-torch-cutorch failed to build, but I think for 
reasons unrelated to the CUDA transition.



I think there is not much point opening a transition bug since this will
be completely at our hands ...


Agreed.

Bug#916195: changed sources in salsa

[Carlos Pascual]

On Wednesday, December 12, 2018 10:23:31 AM CET PICCA Frederic-Emmanuel wrote:
> Hello,
> 
> since Debian wants to remove python-qt4 for buster, maybe it would be nice
> to remove this from the dependecies ?
> 
> Do not hesitate to commit this change if this is ok for you.
> 
> Fred

I am fine with removing it, but just let me point that if it does not cause 
harm to leave it there, it may facilitate the creation of backports to 
stretch.

So let me know what you prefer.

Carlos

-- 
++
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpasc...@cells.es
 Phone: +34 93 592 4428
++

Bug#914951: 4.19.5 fails to boot as Xen dom0

[Hans van Kranenburg]

On 11/30/18 10:46 PM, Hans van Kranenburg wrote:
> On 11/29/18 2:38 AM, Hans van Kranenburg wrote:
>> On 11/29/18 1:20 AM, Hans van Kranenburg wrote:
>>> Package: src:linux
>>> Version: 4.19.5-1~exp1
>>> Severity: normal
>>>
>>> Hi,
>>>
>>> Latest 4.19 upload fails to boot as Xen dom0.
>>
>> Copy at
>> https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03313.html
>>
>> [...]
> 
> A fix has been written and tested:
> 
> https://lists.xenproject.org/archives/html/xen-devel/2018-11/msg03570.html
> 
> I tested it on top of 4.19.5-1~exp1.
> 
> I expect the first of those two patches (the actual fix) to show up in a
> later 4.19.

Since next upload seems to be targeted at unstable, we should have this
fix already:

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

Hans

Bug#916195: changed sources in salsa

[PICCA Frederic-Emmanuel]

Hello Carlos,

> I am fine with removing it, but just let me point that if it does not cause
> harm to leave it there, it may facilitate the creation of backports to
> stretch.

I think that it needs to be removed for Buster.
I understand for the backports.

do you know if a release is expected before the Debian freeze ?


Fred

Bug#909802: poppler: CVE-2018-16646 denial-of-service via crafted file

[Mike Gabriel]

Hi Moritz,

On  Mi 12 Dez 2018 11:46:32 CET, Moritz Mühlenhoff wrote:


On Thu, Nov 08, 2018 at 10:51:37AM +, Mike Gabriel wrote:

Hi Moritz,

On  Di 06 Nov 2018 17:14:35 CET, Moritz Mühlenhoff wrote:

> On Fri, Sep 28, 2018 at 08:32:25PM +0200, Markus Koschany wrote:
> > Package: poppler
> > X-Debbugs-CC: t...@security.debian.org
> > Severity: important
> > Tags: security
> >
> > Hi,
> >
> > The following vulnerability was published for poppler.
> >
> > CVE-2018-16646[0]:
> > | In Poppler 0.68.0, the Parser::getObj() function in Parser.cc  
may cause

> > | infinite recursion via a crafted file. A remote attacker can leverage
> > | this for a DoS attack.
>
> For jessie the wrong patches got applied. They are based on MR 67, which
> didn't get merged in favour of the patch from MR 91.
>
> On a more general notice: This bug has virtually no security impact, it's
> hard too see why this change was made for an LTS release to begin with,
> but at least wait until it's applied/fixed in unstable before backporting.

Not security, but functionality.


Of which there have been hundreds of other since the version in jessie
was released, anyway let's not digress, the point of my followup is
to notify you of regression in the security fix for CVE-2018-16646. I've
just added links to the relevant upstream commits to the security tracker.
These seem also needed in jessie.

Cheers,
Moritz


Thanks for letting me know. Regresion fix upload to jessie is on its way...

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

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



pgpBH9BQHq8BY.pgp
Description: Digitale PGP-Signatur

Bug#916280: typedload: build dependency on mypy is too strict

[Adrian Bunk]

Source: typedload
Version: 1.10-2
Severity: serious

Build-Depends: ..., mypy (= 0.641-1)

If there is some tight interdependency between typedload and mypy,
then this should be expressed properly with a set of >= and <=
dependencies.

In any case a build dependency on the exact Debian revision
of another package seems far too strict.

Bug#916279: qemu-system-common: Overwrite /usr/share/doc-base/qemu-system-doc without declaring replacement

[Boyuan Yang]

Package: qemu-system-common
Version: 1:3.1+dfsg-1
Severity: serious

(Sorry for non-English text, but the output should be self-explainable).

/usr/share/doc-base/qemu-system-doc was previously provided by
qemu-system-data 1:2.12+dfsg-3 but now it is provided by qemu-system-common.

准备解压 .../15-qemu-system-common_1%3a3.1+dfsg-1_amd64.deb  ...
正在解压 qemu-system-common (1:3.1+dfsg-1) 并覆盖 (1:2.12+dfsg-3+b1) ...
dpkg: 处理归档 
/tmp/apt-dpkg-install-FyVVBs/15-qemu-system-common_1%3a3.1+dfsg-1_amd64.deb
(--unpack)时出错：
 正试图覆盖 /usr/share/doc-base/qemu-system-doc，它同时被包含于软件包 qemu-system-data
1:2.12+dfsg-3
dpkg-deb: 错误: 粘贴 子进程被信号(断开的管道) 终止了
在处理时有错误发生：
 /tmp/apt-dpkg-install-FyVVBs/15-qemu-system-common_1%3a3.1+dfsg-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

--
Thanks,
Boyuan Yang

Bug#916281: RM: lua-torch-cutorch -- ROM; deprecated upstream; NBS; NPOASR;

[Mo Zhou]

Package: ftp.debian.org
Severity: normal

rm src:lua-torch-cutorch

It's deprecated by upstream, and has already been replaced by newer
alternatives. Since I'm not going to maintain it anymore and I don't
expect anyone to take it over, I'm requesting a removal.

Bug#914316: Fixed in gcc-8 8.2.0-10

[Andreas Boll]

On Sun, Nov 25, 2018 at 1:29 AM Michael Biebl  wrote:
>
> On Sat, 24 Nov 2018 09:33:11 +0100 Sven Joachim  wrote:
> > Source: gcc-8
> > Version: 8.2.0-10
> >
> > The miscompilation of mesa has been fixed in the latest gcc-8 upload,
> > please see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859 for
> > details.
>
> I recompiled mesa with 8.2.0-10 and I can confirm the fix.
>
> Andreas, thank you for the quick mesa update! Feel free to drop my
> workaround again in one of your next uploads.

Thanks Michael, we have removed your workaround in mesa 18.3.0~rc4-1.

Andreas

Bug#916282: m_inmail: $INMAIL_DB is ignored

[Jan-Benedict Glaw]

Package: lbdb
Version: 0.47

Hi!

While `lbdb-fetchaddr' will honor the "-f" switch to write addresses
to a non-default database, it seems that the m_inmail plugin actually
does not have a way to use a different database.

  While documentation (in `man lbdbq') states that $INMAIL_DB would be
honored, it actually isn't.  It would however be nice to really supply
the database name through the _environment_ to allow querying
different sources without modifying the ~/.lbdb/lbdbrc config file.

Thanks a lot,
  Jan-Benedict
-- 


signature.asc
Description: PGP signature

Bug#909497: CUDA 10 available now

[Mo Zhou]

lua-torch-cutorch is deprecated by upstream and orphaned by me:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916281

caffe-contrib FTBFS because libopencv-dev cannot be installed,
  libopencv-dev cannot be installed because there is a temporary FTBFS
  against hdf5 where libvtk6-dev is uninstallable.

I'm not going deeper along the dep tree.

On Wed, Dec 12, 2018 at 04:48:53PM +0200, Graham Inggs wrote:
> On 2018/12/11 21:51, Andreas Beckmann wrote:
> > Which packages
> > * can be binNMUed (manually by me or another DD, not by the release team)
> > * need sourceful uploads
> > * should get sourceful uploads to change ... and ...
> > ?
> 
> eztrace-contrib, hwloc-contrib and starpu-contrib all built with no changes
> required, so I guess can be binNMU'd.
> 
> pycuda built with the patch from #914804 (already in git)
> 
> caffe-contrib and lua-torch-cutorch failed to build, but I think for reasons
> unrelated to the CUDA transition.
> 
> > I think there is not much point opening a transition bug since this will
> > be completely at our hands ...
> 
> Agreed.

Bug#914034: not deadlocking totally though

[Cyrille Bollu]

Hi,

It's not completly hung; It's just that it takes 3 minutes to timeout:

root@vm-cyrille-debian:~# date;perl -MLWP::UserAgent -e
'LWP::UserAgent->new->post("https://facebook.com";, { data => "foo" }) or
die';date
Wed Dec 12 09:28:37 UTC 2018
Wed Dec 12 09:31:42 UTC 2018

Bug#916195: changed sources in salsa

[Carlos Pascual]

On Wednesday, December 12, 2018 2:59:53 PM CET PICCA Frederic-Emmanuel wrote:
> Hello Carlos,
> 
> > I am fine with removing it, but just let me point that if it does not
> > cause
> > harm to leave it there, it may facilitate the creation of backports to
> > stretch.
> 
> I think that it needs to be removed for Buster.

Fine. I'll remove it.

> I understand for the backports.
> 
> do you know if a release is expected before the Debian freeze ?

I have no idea, but I don't expect it.


> 
> 
> Fred


-- 
++
 Carlos Pascual Izarra
 Scientific Software Coordinator
 Computing Division
 ALBA Synchrotron  [http://www.albasynchrotron.es]
 Carrer de la Llum 2-26
 E-08290 Cerdanyola del Valles (Barcelona), Spain
 E-mail: cpasc...@cells.es
 Phone: +34 93 592 4428
++

Bug#797781: [buildd-tools-devel] Bug#797781: diffoscope does not seem to work with schroot]

[Aurelien Jarno]

On 2018-12-12 10:06, Helmut Grohne wrote:
> Hi Aurelien,
> 
> On Sun, Sep 06, 2015 at 07:28:40PM +0200, Aurelien Jarno wrote:
> > The buildd flavour of the configuration mount a tmpfs in /dev/shm. AFAIK
> > this is not done for the default flavour as too options are possible
> > there:
> > - Bind mount like above. This means sharing the shm directory with the
> >   outside world. This might have some security implications, and
> >   unwanted consequences.
> > - Empty tmpfs like for buildds. This means the processes do not have
> >   accesses to shared memory from processes outside of the chroot.
> > 
> > Depending on how the user want to use schroot, one or the other
> > configuration should be used. I don't know how we should choose the
> > default one.
> 
> Essentially, we have three options (for the default and desktop
> profiles) now:
> 
> (A) Status quo: Don't mount /dev/shm.
> (B) Bind mount /dev/shm.
> (C) Mount a tmpfs on /dev/shm.
> 
> As you point out, each of (B) and (C) breaks some people's workflows
> (either isolation or stuff doesn't work).
> 
> Either (B) or (C) fixes what many users (e.g. diffoscope, ghc, my own
> itch, ...) want. (C) doesn't regress on isolation compared to (A).
> Therefore I argue that (C) is strictly "better" than (A), but (B) isn't.

(C) might give users the possibility to trigger an OOM and DoS system.
/dev/shm is writable by any user. If users have no limit on the number
of chroots they can run, they might be able to fill the whole memory
(RAM + swap), leading to an OOM, potentially killing essential services
as the memory from a tmpfs can't be killed. This does not happen on a
normal system, as the default size of a tmpfs is half of the size of the
RAM.

So I am not sure that (C) is "strictly better".

Aurelien

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

Bug#916283: No "Varying the domain and host names"

[Joachim Breitner]

Package: reprotest
Version: 0.7.8
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

the manpage says

> see "Varying the domain and host names" for details.

but I see no such section anywhere.

Cheers,
Joachim

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

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

Versions of packages reprotest depends on:
ii  apt-utils  1.8.0~alpha2
ii  diffoscope 107
ii  libdpkg-perl   1.19.2
ii  procps 2:3.3.15-2
ii  python33.7.1-2
ii  python3-debian 0.1.33
ii  python3-distro 1.3.0-1
ii  python3-pkg-resources  40.6.2-1
ii  python3-rstr   2.2.6-1

Versions of packages reprotest recommends:
ii  diffoscope   107
ii  disorderfs   0.5.5-1
ii  faketime 0.9.7-3
ii  locales-all  2.28-2
ii  sudo 1.8.26-2

Versions of packages reprotest suggests:
ii  autodep8 0.15
ii  qemu-system  1:2.12+dfsg-3+b1
ii  qemu-utils   1:2.12+dfsg-3+b1
ii  schroot  1.6.10-6+b1

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHEEARECADEWIQQxTjstYFpus1p9gRn2KOuTR0MgbAUCXBEmoBMcbm9tZWF0YUBk
ZWJpYW4ub3JnAAoJEPYo65NHQyBszlcAn1vr9aXhFgelEAPz/Sxx+FFBUgQ+AKCG
K8gHl/dzp+YNplHSbR/98JjtdQ==
=77Ar
-END PGP SIGNATURE-

Bug#915136: Solution not applicable

[Er_Maqui]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,

Thanks for the response. Unfortunately, my /var/lib/gems/2.5.0 is empty.

kanade:/var/lib/gems# ls 2.5.0/ -la
total 8
drwxr-xr-x 2 root root 4096 Mar  4  2018 .
drwxr-xr-x 3 root root 4096 Dec 12 16:02 ..

(I didn't have another folder on /var/lib/gems too).

If there's any other place where I can check please tell me.


Doing a dpkg-reconfigure gitlab, I have these debug:

kanade:/var/lib/gems# dpkg-reconfigure gitlab
Creating runtime directories for gitlab...
Updating file permissions...
Configuring hostname and email...
Configuring nginx with HTTPS...
Configuring gitlab with HTTPS...
Updating gitlab_url in gitlab-shell configuration...
Configuring letsencrypt...
Let's encrypt certificate already present.
Registering /usr/lib/tmpfiles.d/gitlab.conf via ucf
/etc/systemd/system/gitlab-mailroom.service.d/override.conf already exist
/etc/systemd/system/gitlab-unicorn.service.d/override.conf already exist
/etc/systemd/system/gitlab-sidekiq.service.d/override.conf already exist
/etc/systemd/system/gitlab-workhorse.service.d/override.conf already exist
Registering /etc/gitlab-shell/config.yml via ucf
Registering /etc/gitlab/gitlab.yml via ucf
Registering /etc/gitlab/gitlab-debian.conf via ucf
Reloading nginx configuration...
dbconfig-common: writing config to /etc/dbconfig-common/gitlab.conf
dbconfig-common: flushing administrative password
NOTICE:  extension "pg_trgm" already exists, skipping
CREATE EXTENSION
Verifying we have all required libraries...
Resolving dependencies.
Bundle complete! 172 Gemfile dependencies, 316 gems now installed.
Gems in the groups development and test were not installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Running final rake tasks and tweaks...
gitlab_production database is not empty, skipping gitlab setup
Installing node modules...
npm WARN saveError ENOENT: no such file or directory, open
'/home/gitlab/yarn/package.json'
npm WARN enoent ENOENT: no such file or directory, open
'/home/gitlab/yarn/package.json'
npm WARN yarn No description
npm WARN yarn No repository field.
npm WARN yarn No README data
npm WARN yarn No license field.

+ yarn@1.12.3
updated 1 package in 1.811s

yarn install v1.12.3
[1/4] Resolving packages...
[2/4] Fetching packages...
info fsevents@1.2.4: The platform "linux" is incompatible with this module.
info "fsevents@1.2.4" is an optional dependency and failed compatibility
check. Excluding it from installation.
[3/4] Linking dependencies...
[4/4] Building fresh packages...
$ node ./scripts/frontend/postinstall.js
success Dependency postinstall check passed.
Done in 10.37s.
Precompiling locales...

All files created, make sure they are being added to your assets.
If they are not, you can add them with this line (configurable):

//= require_tree ./locale
//= require gettext/all

Precompiling assets...
Webpacking...
Hash: 30cea2a0e07bbb61dcaa
Version: webpack 4.19.1
Time: 46916ms
Built at: 12/12/2018 4:19:15 PM

Running rake checks...
Check if Gitlab is configured correctly...


Maybe I should try to uninstall gitlab and reinstall it?


https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEYf0F71OtDykDsKZdCU2zE9sy6H8FAlwRK7IACgkQCU2zE9sy
6H8XjA//Uy7DcuwNsrHeJOiS/kOxinzu+20/bx78aiBSNiR9ETsJ8n8SEsl6wJM7
YVM4gfChistQSA/P6Wo7+ivhS2erhBnrIpKnJZ/wAwQ0x9qF6aaYYpnRQ0xJRD9+
Pmm0IAdEoXUEXizb4Aw5iX7Ef/jeE4JgkzUwp7+c+OBFZUn3Kf5US2L0JjtijI02
eQqqGqX11hcR++HbElz4NQGiYdPYCU1o9VzmiDkMVlKMD/lE+0hlADWUzDR4gYa9
4jJcc8LoUoWdWJl024iqJCsJFFuWrNdcnWH8Z9d93E5ko8fLGyw9W9WlFX8kcI9s
ZbP5/gHcRugW8AmmCfgI1OyBh/AR3cYXM/nJdH+7ObH1+of+bwXyM1AUDfSYrgQx
tFkj+z6evopRBM9jRGPj3kmM96gGelXv9t94q6RzG+LvRpK/WtQ7RKKQShRMDoxW
RoMuBKIb8TXh/8XCqw1KhfxbNvYFWoZVf5l5Dnsq/Fqq1pvu7eEA+3TYDRQBZ+HH
MvIM/IiYtNaJ220KTsO6cfQ/GA2xuKvp/sjkXTjhFxw3mBI/BXfrHmcu06twVcHP
rg7IjIkhnewrnizoyI+6XaczqhAOP1ijPUz0vxvTBpWAAhpbKJf8z8+39dG/WLZa
btX9ppmo0kiohFlNDu/3YX9+u3Diur9ogv10NLOu2FKh9mzLB9Y=
=GdDI
-END PGP SIGNATURE-

Bug#915859: [Pkg-privacy-maintainers] Bug#915859: uses a fixed filename in /tmp

[Ulrike Uhlig]

Hi!

Salvatore Bonaccorso:

> So it will additionally allow potentially denial of service on
> multi-user systems. 
> 
> Not sure if the grave severity is warranted, though, will leave this
> discussion to you both :)

Ack, grave sounds a bit grave.

> For tracking the issue, I have requested a CVE from MITRE, which got
> assigned CVE-2018-19960.

Thank you.

I've asked upstream to fix it yesterday, and they did. So I'll upload a
newer version of onionshare a bit later this week (probably not today
though).

Cheers!
u.

Bug#915136: Solution not applicable

[Pirate Praveen]

On 12/12/18 9:09 PM, David López Zajara (Er_Maqui) wrote:
> Maybe I should try to uninstall gitlab and reinstall it?
I think you can try that.

Try to take the database to a different machine and do a clean install.

One possibility is any files left over in /etc/gitlab which were
subsequently removed from gitlab. Try comparing the files in gitlab
package source repo's config directory and your /etc/gitlab.



signature.asc
Description: OpenPGP digital signature

Bug#797781: [buildd-tools-devel] Bug#797781: diffoscope does not seem to work with schroot]

[Roger Leigh]

On 12/12/2018 15:25, Aurelien Jarno wrote:

On 2018-12-12 10:06, Helmut Grohne wrote:

Hi Aurelien,

On Sun, Sep 06, 2015 at 07:28:40PM +0200, Aurelien Jarno wrote:

The buildd flavour of the configuration mount a tmpfs in /dev/shm. AFAIK
this is not done for the default flavour as too options are possible
there:
- Bind mount like above. This means sharing the shm directory with the
   outside world. This might have some security implications, and
   unwanted consequences.
- Empty tmpfs like for buildds. This means the processes do not have
   accesses to shared memory from processes outside of the chroot.

Depending on how the user want to use schroot, one or the other
configuration should be used. I don't know how we should choose the
default one.


Essentially, we have three options (for the default and desktop
profiles) now:

(A) Status quo: Don't mount /dev/shm.
(B) Bind mount /dev/shm.
(C) Mount a tmpfs on /dev/shm.

As you point out, each of (B) and (C) breaks some people's workflows
(either isolation or stuff doesn't work).

Either (B) or (C) fixes what many users (e.g. diffoscope, ghc, my own
itch, ...) want. (C) doesn't regress on isolation compared to (A).
Therefore I argue that (C) is strictly "better" than (A), but (B) isn't.


(C) might give users the possibility to trigger an OOM and DoS system.
/dev/shm is writable by any user. If users have no limit on the number
of chroots they can run, they might be able to fill the whole memory
(RAM + swap), leading to an OOM, potentially killing essential services
as the memory from a tmpfs can't be killed. This does not happen on a
normal system, as the default size of a tmpfs is half of the size of the
RAM.

So I am not sure that (C) is "strictly better".


It should perhaps be combined with some sensible default size 
limitations like we used to provide in (IIRC) /etc/default/tmpfs.


For the (B) case, do we have any defined use case for sharing shm 
between host and chroot?  It's useless for anonymous (unlinked) 
mappings, because they won't be propagated.  So the only use case is 
named mappings.  If we don't have any concrete use case for that, I'd be 
tempted to drop this possibility entirely.


For (A) if you don't mount /dev/shm, is there still some risk due to 
using the underlying devtmpfs mount and causing problems, including 
security problems, as a result?  You might still get shared data between 
host and chroots stored there, which might have security and privacy 
implications?  And you could affect the /dev mountpoint if using all the 
space prevents device node or other file creation under /dev on the host?


I think (C) is vastly preferable from the security point of view. 
However, it does as you point out, have problems if you overcommit 
resources across multiple chroots.


One possible mitigation would be to not mount a tmpfs at all.  There is 
no technical requirement that /dev/shm be a tmpfs.  It could be backed 
by disk, e.g. creating and bind mounting chroot/shm to chroot/dev/shm 
would make it use the same disc backing as the chroot itself.  Or create 
a session-specific private dir under [/var]/tmp and bind mount that (it 
will avoid serialising and storing session state for source chroots). 
There will of course be a potential performance cost in using a real 
disc, but it takes all of the resource exhaustion and privacy questions 
completely out of the picture.



Regards,
Roger

Bug#916220: saidar: segfault after couple of minutes

[Mindaugas Celiesius]

Hello. Thanks for the explanation. So, a very strange situation arose. This 
program (sayar) has started to function normally. What have I done today? I 
installed systemd-coredump and gdb in hopes of getting more information for 
you. In addition, I used a window manager -herbstluftwm. I uninstalled it and 
compiled from source another windows manager-dwm. So, I did a test in this 
window manager using the terminal st and urxvt. Surprisingly, after five hours 
of use, this program start functioning normally. I will still use it for 
several days and if problems arise, I'll let you know. If there is a 
possibility, I would ask you do not close this bug report.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄ A master species delegates.

Bug#916280: typedload: build dependency on mypy is too strict

[Salvo Tomaselli]

You are right that it's not ideal.

However it is because every single new version of mypy changes
something, so they fix a false positive and fail because I had a "#
type: ignore" tag or they introduce some new false positive.

So in practice it never happens that the build works when changing
mypy version, since it runs tests during the build.
Il giorno mer 12 dic 2018 alle ore 16:06 Adrian Bunk 
ha scritto:
>
> Source: typedload
> Version: 1.10-2
> Severity: serious
>
> Build-Depends: ..., mypy (= 0.641-1)
>
> If there is some tight interdependency between typedload and mypy,
> then this should be expressed properly with a set of >= and <=
> dependencies.
>
> In any case a build dependency on the exact Debian revision
> of another package seems far too strict.



-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

http://ltworf.github.io/ltworf/

Bug#916280: typedload: build dependency on mypy is too strict

[Adrian Bunk]

On Wed, Dec 12, 2018 at 05:12:02PM +0100, Salvo Tomaselli wrote:
> You are right that it's not ideal.
> 
> However it is because every single new version of mypy changes
> something, so they fix a false positive and fail because I had a "#
> type: ignore" tag or they introduce some new false positive.

At least the Debian revision part looks clearly wrong.

Something like
  Build-Depends: ..., mypy (>= 0.641), mypy (<< 0.641.1)
should in any case be sufficient.

> So in practice it never happens that the build works when changing
> mypy version, since it runs tests during the build.
> Il giorno mer 12 dic 2018 alle ore 16:06 Adrian Bunk 
> ha scritto:
> >
> > Source: typedload
> > Version: 1.10-2
> > Severity: serious
> >
> > Build-Depends: ..., mypy (= 0.641-1)
> >
> > If there is some tight interdependency between typedload and mypy,
> > then this should be expressed properly with a set of >= and <=
> > dependencies.
> >
> > In any case a build dependency on the exact Debian revision
> > of another package seems far too strict.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#916284: mrtrix3 seems to be amd64-only

[Adrian Bunk]

Source: mrtrix3
Version: 3.0~rc3+git86-g4b523b413-1
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=mrtrix3&suite=sid

After looking at the build failures non-SSE seems to be unsupported,
and the Architecture: should be changed accordingly.

Bug#912087: openssh-server: Slow startup after the upgrade to 7.9p1

[Uwe Kleine-König]

On Sun, Oct 28, 2018 at 11:41:14AM +0100, Bernhard Übelacker wrote:
> Dear Maintainer,
> just some more information, because I think I see this
> difference in my qemu buster amd64 VM too.
> 
> Before I could ssh into that machine just after some seconds.
> 
> Now it takes some time until that line "random: crng init done"
> appears in dmesg.
> With logging in in the qemu window this line appears just after a
> few seconds, when just trying via ssh it takes much longer.

I have a NAS running Debian[1] and there I only get the "crng init done"
message after more than 15 minutes (even though there is network activity and I
debugged the failure via rs232):

root@machine:~# dmesg | tail
[   22.579884] audit: type=1400 audit(1529665920.708:3): 
apparmor="STATUS" operation="profile_load" profile="unconfined" 
name="man_filter" pid=299 comm="apparmor_parser"
[   22.627877] audit: type=1400 audit(1529665920.708:4): 
apparmor="STATUS" operation="profile_load" profile="unconfined" 
name="man_groff" pid=299 comm="apparmor_parser"
[   22.711102] 8021q: 802.1Q VLAN Support v1.8
[   22.840150] mvneta d0074000.ethernet eth1: PHY 
[d0072004.mdio-mii:01] driver [Marvell 88E1318S]
[   22.856020] mvneta d0074000.ethernet eth1: configuring for 
phy/rgmii-id link mode
[   22.872501] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[   26.020202] mvneta d0074000.ethernet eth1: Link is Up - 1Gbps/Full - 
flow control rx/tx
[   26.027639] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 1057.771583] random: crng init done
[ 1057.774739] random: 7 urandom warning(s) missed due to ratelimiting

I'm not aware the machine has a random number generator, so the solutions
presented here up to now don't help me.

I think the idea to mention this in the release notes for buster is a
good one (unless a solution is found until then of course).

Best regards
Uwe

[1] this i an armv7/mvebu machine with a Armada 370 CPU


signature.asc
Description: PGP signature

Bug#909497: CUDA 10 available now

[Graham Inggs]

On 2018/12/12 17:21, Mo Zhou wrote:

caffe-contrib FTBFS because libopencv-dev cannot be installed,
   libopencv-dev cannot be installed because there is a temporary FTBFS
   against hdf5 where libvtk6-dev is uninstallable.

I'm not going deeper along the dep tree.


I should have mentioned my previous test builds were done in Ubuntu 
disco-proposed (roughly equivalent to unstable) where the hdf5 
transition has just started.


I've just tested building caffe-contrib locally in Ubuntu disco (roughly 
equivalent to testing) and it builds fine with no changes required.

Bug#916285: RFS: extsmail/2.2-1 -- enables the robust sending of e-mail to external commands

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: extsmail
   Version : 2.2-1
   Upstream Author : Laurence Tratt 
 * URL : https://tratt.net/laurie/src/extsmail/
 * License : BSD/MIT
   Section : mail

  It builds this binary package:

extsmail   - enables the robust sending of e-mail to external commands

  The package appears to be lintian-clean

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/e/extsmail/extsmail_2.2-1.dsc

  Changes since the last upload:

  * New upstream release 2.2. (Closes: #748739)
  * debian/compat: Upgrade to 11.
  * debian/control: Priority: optional.
  * debian/control: Vcs-Browser: https://github.com/ltratt/extsmail.
  * debian/control: Vcs-Git: https://github.com/ltratt/extsmail.git.
  * debian/control: Build-Depends: Remove dh-autoreconf.
  * debian/control: Build-Depends: Update debhelper (>= 11).
  * debian/control: Update Homepage.
  * debian/control: Standards-Version: 4.2.1.
  * debian/copyright: Update copyright years.
  * debian/copyright: Update Source URL.
  * debian/copyright: Use secure copyright format URI.
  * debian/rules: Remove --with autoreconf.
  * debian/tests/control: Added.
  * debian/watch: version=4.
  * debian/watch: Use secure URI.

  Regards,

--
Olivier

Bug#916226: diffoscope pytest warnings

[Chris Lamb]

tags 916226 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/reproducible-builds/diffoscope/commit/a4c38a60fe505de772f0d9ced5cca1ca5df540ba

  tests/comparators/test_icc.py | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


Regards,

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

Bug#873081: (no subject)

[Daniel Hornung]

FWIW, I was just bitten by this bug on Kubuntu: https://bugs.launchpad.net/
ubuntu/+source/akonadi/+bug/1808186

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

Bug#914034: bug in Net::SSLeay?

[cyrille]

Hello,

I've investigated a little bit this problem, and I wonder if this could 
be caused by a bug in Net::SSLeay 1.85 which seems to be resolved in 
version 1.86_06 (not yet released on CPAN) via 
https://github.com/radiator-software/p5-net-ssleay/pull/56/commits/f67e75f2b50fa72da9a5111abc13b2bd06d33650.


For the record, here's a debugging session of the 
"LWP::UserAgent->new->post("https://facebook.com";, { data => "foo" }) or 
die" command:


root@vm-cyrille-debian:~# perl -d -MLWP::UserAgent -e 
'LWP::UserAgent->new->post("https://facebook.com";, { data => "foo" }) or 
die'


Loading DB routines from perl5db.pl version 1.53
Editor support available.

Enter h or 'h h' for help, or 'man perldebug' for more help.

main::(-e:1):	LWP::UserAgent->new->post("https://facebook.com";, { data 
=> "foo" }) or die

  DB<1> s
LWP::UserAgent::new(/usr/share/perl5/LWP/UserAgent.pm:23):
23:	Carp::croak("Options to LWP::UserAgent should be key/value 
pairs, not hash reference")

24: if ref($_[1]) eq 'HASH';
  DB<1> c 206
LWP::UserAgent::CODE(0x55d48645fdf0)(/usr/share/perl5/LWP/UserAgent.pm:206):
206:	$response = $protocol->request($request, $proxy, 
$arg, $size, $self->{timeout}) || die "No response returned by 
$protocol";

  DB<2> s
LWP::Protocol::http::request(/usr/share/perl5/LWP/Protocol/http.pm:127):
127:my($self, $request, $proxy, $arg, $size, $timeout) = @_;
  DB<2> c 377
LWP::Protocol::http::request(/usr/share/perl5/LWP/Protocol/http.pm:377):
377:my $n = $socket->sysread($buf, 1024, length($buf));
  DB<3> s
IO::Socket::SSL::sysread(/usr/share/perl5/IO/Socket/SSL.pm:1150):
1150:   my $self = shift;
  DB<3> c 1109
IO::Socket::SSL::_generic_read(/usr/share/perl5/IO/Socket/SSL.pm:1109):
1109:   $SSL_ERROR = $! = undef;
  DB<4> v
1106:   my $ssl =  ${*$self}{_SSL_object} || return;
1107:   my $buffer=\$_[2];
1108
1109==>  $SSL_ERROR = $! = undef;
1110:   my ($data,$rwerr) = $read_func->($ssl, $length);
:   while ( ! defined($data)) {
1112:		if ( my $err = $self->_skip_rw_error( $ssl, defined($rwerr) ? 
$rwerr:-1 )) {

1113:   if ($err == $Net_SSLeay_ERROR_SYSCALL) {
1114# OpenSSL 1.1.0c+ : EOF can now result in SSL_read 
returning -1
1115:   if (not $!) {
  DB<4> n
IO::Socket::SSL::_generic_read(/usr/share/perl5/IO/Socket/SSL.pm:1110):
1110:   my ($data,$rwerr) = $read_func->($ssl, $length);
  DB<4> s


This is where the code "hangs", and $read_func is actually 
Net::SSLeay::read


Br,

Cyrille

Bug#915956: nmu: anbox_0.0~git20181014-1

[Emilio Pozuelo Monfort]

On 08/12/2018 15:39, Shengjing Zhu wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: binnmu
> 
> nmu anbox_0.0~git20181014-1 . amd64 arm64 armhf . unstable . -m "Rebuild 
> against lxc3. (Closes: #915821)"
> 

Why is this needed? Your package anbox depends on lxc and liblxc1 so no binNMU
should be necessary. If anbox is unusable, there may be something else that is
wrong.

Cheers,
Emilio

Bug#915956: nmu: anbox_0.0~git20181014-1

[Shengjing Zhu]

On Thu, Dec 13, 2018 at 1:00 AM Emilio Pozuelo Monfort  wrote:
>
> On 08/12/2018 15:39, Shengjing Zhu wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: binnmu
> >
> > nmu anbox_0.0~git20181014-1 . amd64 arm64 armhf . unstable . -m "Rebuild 
> > against lxc3. (Closes: #915821)"
> >
>
> Why is this needed? Your package anbox depends on lxc and liblxc1 so no binNMU
> should be necessary. If anbox is unusable, there may be something else that is
> wrong.

Launching a lxc container needs a configuration file, and the
configuration key is different for lxc2 and lxc3.
I think such breakage is not covered by liblxc so version.

Anbox upstream determines the lxc version at build time, to choose
what configure key to use.

https://github.com/anbox/anbox/blob/73b8b63/src/anbox/container/lxc_container.cpp#L50


--
Shengjing Zhu

Bug#915956: nmu: anbox_0.0~git20181014-1

[Emilio Pozuelo Monfort]

On 12/12/2018 18:08, Shengjing Zhu wrote:
> On Thu, Dec 13, 2018 at 1:00 AM Emilio Pozuelo Monfort  
> wrote:
>>
>> On 08/12/2018 15:39, Shengjing Zhu wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: binnmu
>>>
>>> nmu anbox_0.0~git20181014-1 . amd64 arm64 armhf . unstable . -m "Rebuild 
>>> against lxc3. (Closes: #915821)"
>>>
>>
>> Why is this needed? Your package anbox depends on lxc and liblxc1 so no 
>> binNMU
>> should be necessary. If anbox is unusable, there may be something else that 
>> is
>> wrong.
> 
> Launching a lxc container needs a configuration file, and the
> configuration key is different for lxc2 and lxc3.
> I think such breakage is not covered by liblxc so version.
> 
> Anbox upstream determines the lxc version at build time, to choose
> what configure key to use.
> 
> https://github.com/anbox/anbox/blob/73b8b63/src/anbox/container/lxc_container.cpp#L50

Sounds like something that should be done at runtime.

For now, a rebuild would fix users that have newer lxc, but it would be possible
to have the old one with a rebuilt anbox if you don't force a minimum version.
Thus you should probably do a maintainer upload bumping the build and runtime
dep to ensure you get the newer configuration.

Emilio

Bug#916286: traverso: baseline violation on i386

[Adrian Bunk]

Source: traverso
Version: 0.49.4-2
Severity: serious

SSE is not part of the i386 baseline.

Even worse is that when built on binet -m3dnow is passed on gcc,
this is not supported by any modern CPU.

Bug#916212: elogind: when upgrading /run/elogind.pid believed even if actual process had died

[Mark Hindley]

On Wed, Dec 12, 2018 at 12:54:42AM +1030, Arthur Marsh wrote:
> Package: elogind
> Version: 239.3-1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
> aptitude upgrade:
> 
> [UPGRADE] elogind:amd64 239.1+20181115-1 -> 239.3-1
> [UPGRADE] libelogind0:amd64 239.1+20181115-1 -> 239.3-1
> [UPGRADE] libpam-elogind:amd64 239.1+20181115-1 -> 239.3-1
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> When attempting to restart the new version of elogind, there would
> be an error message based on the existence of the /run/elogind.pid file,
> even when the process did not exist. I had to manually remove
> /run/elogind.pid to be able to start the new elogind

Arthur. Could you try this patch and verify it fixes this issue for you?

Thanks

Mark

--- a/src/login/elogind.c
+++ b/src/login/elogind.c
@@ -179,8 +179,8 @@
 get_process_comm(pid, &comm);
 if (NULL == startswith(strna(comm), 
program_invocation_short_name))
 goto we_are_alone;
+return pid;
 }
-return pid;
 
 we_are_alone:
 

Bug#916222: libopenmpt0: crashes with SIGSEGV when using OpenCV from Java [PATCH]

[Jakub Vaněk]

Hi all,

I have prepared a patch for the Debian source package itself:
https://github.com/ev3dev/libopenmpt/commit/3dc5d930bfa6d1876fdf86336870184ee41dbe66.patch

Cheers,

Jakub Vanek

Bug#916288: kea-dhcp4-server: Segfault after running for several minutes

[Anton Avramov]

Package: kea-dhcp4-server
Version: 1.1.0-1
Severity: important

Dear Maintainer,

I'm trying kea with mariadb as a backend. Relevant package installed from
mariadb website (libmariadbclient18=10.2.19+maria~stretch). I have 
inserted several host reservations. Initially the server gives

out leases but in some point (I suspect on renew) it crashes.
Here is a debug trace of what I've collected:
--
[New Thread 0x7fffef838700 (LWP 25166)]


Thread 1 "kea-dhcp4" received signal SIGSEGV, Segmentation fault.
0x747f525c in mysql_stmt_bind_result () from 
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18

(gdb) (gdb) bt
#0 0x747f525c in mysql_stmt_bind_result () from 
/usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
#1 0x77a9ed19 in ?? () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#2 0x77a9f540 in ?? () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#3 0x77aa0551 in isc::dhcp::MySqlHostDataSource::get4(unsigned 
int const&, isc::dhcp::Host::IdentifierType const&, unsigned char 
const*, unsigned long) const ()

from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#4 0x77a5acba in isc::dhcp::HostMgr::get4(unsigned int const&, 
isc::dhcp::Host::IdentifierType const&, unsigned char const*, unsigned 
long) const ()

from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#5 0x779eeb8c in boost::shared_ptr 
boost::_mfi::cmf4, 
isc::dhcp::HostMgr, unsigned int const&, isc::dhcp::Host::IdentifierType 
const&, unsigned char const*, unsigned long>::callconst, unsigned int const, isc::dhcp::Host::IdentifierType const, 
unsigned char const*, unsigned long>(isc::dhcp::HostMgr* const&, void 
const*, unsigned int const&, isc::dhcp::Host::IdentifierType const&, 
unsigned char const*&, unsigned long&) const () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#6 0x779ed9b1 in boost::shared_ptr 
boost::_mfi::cmf4, 
isc::dhcp::HostMgr, unsigned int const&, isc::dhcp::Host::IdentifierType 
const&, unsigned char const*, unsigned 
long>::operator()(isc::dhcp::HostMgr* const&, 
unsigned int const&, isc::dhcp::Host::IdentifierType const&, unsigned 
char const*, unsigned long) const () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#7 0x779ec881 in boost::shared_ptr 
boost::_bi::list5, boost::arg<1>, 
boost::arg<2>, boost::arg<3>, boost::arg<4> 
>::operator(), 
boost::_mfi::cmf4, 
isc::dhcp::HostMgr, unsigned int const&, isc::dhcp::Host::IdentifierType 
const&, unsigned char const*, unsigned long>, 
boost::_bi::rrlist4const&, unsigned char const*, unsigned long> 
>(boost::_bi::type >, 
boost::_mfi::cmf4, 
isc::dhcp::HostMgr, unsigned int const&, isc::dhcp::Host::IdentifierType 
const&, unsigned char const*, unsigned long>&, 
boost::_bi::rrlist4const&, unsigned char const*, unsigned long>&, long) () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#8 0x779eadbe in boost::shared_ptr 
boost::_bi::bind_t, 
boost::_mfi::cmf4, 
isc::dhcp::HostMgr, unsigned int const&, isc::dhcp::Host::IdentifierType 
const&, unsigned char const*, unsigned long>, 
boost::_bi::list5, boost::arg<1>, 
boost::arg<2>, boost::arg<3>, boost::arg<4> > >::operator()const&, isc::dhcp::Host::IdentifierType const&, unsigned char const*, 
unsigned long>(unsigned int const&, isc::dhcp::Host::IdentifierType 
const&, unsigned char const*&&, unsigned long&&) () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#9 0x779e83e8 in 
boost::detail::function::function_obj_invoker4const>, boost::_mfi::cmf4, 
isc::dhcp::HostMgr, unsigned int const&, isc::dhcp::Host::IdentifierType 
const&, unsigned char const*, unsigned long>, 
boost::_bi::list5, boost::arg<1>, 
boost::arg<2>, boost::arg<3>, boost::arg<4> > >, 
boost::shared_ptr, unsigned int const&, 
isc::dhcp::Host::IdentifierType const&, unsigned char const*, unsigned 
long>::invoke(boost::detail::function::function_buffer&, unsigned int 
const&, isc::dhcp::Host::IdentifierType const&, unsigned char const*, 
unsigned long) () from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#10 0x779e0a28 in 
boost::function4, unsigned int 
const&, isc::dhcp::Host::IdentifierType const&, unsigned char const*, 
unsigned long>::operator()(unsigned int const&, 
isc::dhcp::Host::IdentifierType const&, unsigned char const*, unsigned 
long) const () from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#11 0x779de266 in void 
isc::dhcp::AllocEngine::findReservationInternal(isc::dhcp::AllocEngine::ClientContext4&, 
boost::function (unsigned int 
const&, isc::dhcp::Host::IdentifierType const&, unsigned char const*, 
unsigned long)> const&) () from 
/usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#12 0x779d2ef2 in 
isc::dhcp::AllocEngine::findReservation(isc::dhcp::AllocEngine::ClientContext4&) 
() from /usr/lib/x86_64-linux-gnu/libkea-dhcpsrv.so.6
#13 0x555d6c6c in isc::dhcp::Dhcpv4Exchange::Dhcpv4Exchange 
(this=0x7fffdc90, alloc_engine=..., query=..., subnet=...) at 
../../../../src/bin/dhcp4/dhcp4_sr

Bug#916287: po2oo unusable

[Mechtilde Stehmann]

Package: translate-toolkit
Version: 2.3.1-2
Severity: grave

I try to convert *.po files from Pootle to *.sdf files

It fails with error message:

Traceback (most recent call last):
  File "/usr/bin/po2oo", line 11, in 
load_entry_point('translate-toolkit==2.3.1', 'console_scripts',
'po2oo')()
  File "/usr/lib/python3/dist-packages/translate/convert/po2oo.py", line
264, in main
parser.run(argv)
  File "/usr/lib/python3/dist-packages/translate/convert/convert.py",
line 181, in run
self.recursiveprocess(options)
  File "/usr/lib/python3/dist-packages/translate/convert/convert.py",
line 422, in recursiveprocess
self.templatearchive = self.openarchive(options.template, 'template')
  File "/usr/lib/python3/dist-packages/translate/convert/convert.py",
line 312, in openarchive
return archiveclass(archivefilename, **archiveoptions)
  File "/usr/lib/python3/dist-packages/translate/storage/oo.py", line
360, in __init__
self.createsubfileindex()
  File "/usr/lib/python3/dist-packages/translate/storage/oo.py", line
366, in createsubfileindex
subfile = self.getsubfilename(line)
  File "/usr/lib/python3/dist-packages/translate/storage/oo.py", line
375, in getsubfilename
raise ValueError("invalid tab-delimited line: %r" % line)
ValueError: invalid tab-delimited line: '#\n'


This still worked at 2018-12-07 in Testing


I use daily updated testing system

I will try to downgrade to version 2.3.1-1 now

Kind regards


-- 
Mechtilde Stehmann
## Debian Developer
## Loook, tbsync, libreoffice-canzeley-client
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#916289: liblilv-0-0: Plugins in /usr/local/lib/lv2 are not scanned

[Julien ROGER]

Package: liblilv-0-0
Version: 0.24.2~dfsg0-2
Severity: normal

Dear Maintainer,

LV2 plugins installed in /usr/local/lib/lv2 path are not visible in LV2 hosts.

lv2ls command doesn't show them either.

The problem comes from the "--default-lv2-path" option passed to the configure
script (debian/rules commit 53a743c6).
The specified path is "/usr/local/lv2" instead of "/usr/local/lib/lv2".

Julien





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

Kernel: Linux 4.19.7 (SMP w/6 CPU cores; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages liblilv-0-0 depends on:
ii  libc6  2.28-2
ii  libserd-0-00.28.0~dfsg0-1
ii  libsord-0-00.16.0~dfsg0-1+b1
ii  libsratom-0-0  0.6.0~dfsg0-1

liblilv-0-0 recommends no packages.

liblilv-0-0 suggests no packages.

-- debconf-show failed

Bug#916290: compiz-dev: move .pc files to a multiarch location

[Helmut Grohne]

Package: compiz-dev
Version: 2:0.8.14-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:libcompizconfig

libcompizconfig fails to cross build from source, because it fails to
find compiz.pc. During cross compilation, pkg-config does not search
/usr/lib/pkgconfig. The attached patch moves those files to the
multiarch location. Please consider applying it.

Helmut
diff --minimal -Nru compiz-0.8.14/debian/changelog 
compiz-0.8.14/debian/changelog
--- compiz-0.8.14/debian/changelog  2018-11-15 17:15:59.0 +0100
+++ compiz-0.8.14/debian/changelog  2018-12-12 17:00:20.0 +0100
@@ -1,3 +1,10 @@
+compiz (2:0.8.14-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move compiz-dev's .pc files to a multiarch location. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 12 Dec 2018 17:00:20 +0100
+
 compiz (2:0.8.14-3) unstable; urgency=medium
 
   * control: Fix indep-only build.
diff --minimal -Nru compiz-0.8.14/debian/rules compiz-0.8.14/debian/rules
--- compiz-0.8.14/debian/rules  2018-11-15 17:14:12.0 +0100
+++ compiz-0.8.14/debian/rules  2018-12-12 17:00:18.0 +0100
@@ -1,6 +1,8 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
 
+include /usr/share/dpkg/architecture.mk
+
 CORE_ABIVERSION := $(shell sed -rn 
's/^\#define[[:space:]]+CORE_ABIVERSION[[:space:]]+//p' include/compiz-core.h )
 
 LDFLAGS += -Wl,--as-needed
@@ -30,6 +32,8 @@
-type f -name '*.la' -exec rm -f {} ';'
 
dh_install --fail-missing
+   mkdir debian/compiz-dev/usr/lib/$(DEB_HOST_MULTIARCH)
+   mv debian/compiz-dev/usr/lib/pkgconfig 
debian/compiz-dev/usr/lib/$(DEB_HOST_MULTIARCH)/pkgconfig
 
 # matecompat plugin and xml file are seperately installed
 # into the -mate package respectively

Bug#916291: soapsnp: missing build dependency on zlib1g-dev

[Adrian Bunk]

Source: soapsnp
Version: 1.03-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/soapsnp.html

...
g++ -g -O2 -ffile-prefix-map=/build/1st/soapsnp-1.03=. -fstack-protector-strong 
-Wformat -Werror=format-security -g -O2 
-ffile-prefix-map=/build/1st/soapsnp-1.03=. -fstack-protector-strong -Wformat 
-Werror=format-security -fomit-frame-pointer -O3 -ffast-math -funroll-loops 
call_genotype.o chromosome.o matrix.o normal_dis.o prior.o rank_sum.o main.o -o 
soapsnp -lz -Wl,-z,relro -Wl,-z,now
/usr/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
make[1]: *** [makefile:14: soapsnp] Error 1

Bug#916292: pyfai FTBFS on i386: test failures

[Adrian Bunk]

Source: pyfai
Version: 0.16.0+dfsg1-2
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pyfai&arch=i386&ver=0.16.0%2Bdfsg1-2&stamp=1540775253&raw=0

...
==
FAIL: test_dot16 (pyFAI.test.test_openCL.TestKahan)
--
Traceback (most recent call last):
  File 
"/<>/pyfai-0.16.0+dfsg1/.pybuild/cpython2_2.7_pyfai/build/pyFAI/test/test_openCL.py",
 line 456, in test_dot16
self.assertEqual(ref64, res)
AssertionError: 1431655765.0 != 1431655808.0

Stderr:
WARNING:silx.opencl.common:Last chance to get an OpenCL device ... probably not 
the one requested

==
FAIL: test_kahan (pyFAI.test.test_openCL.TestKahan)
--
Traceback (most recent call last):
  File 
"/<>/pyfai-0.16.0+dfsg1/.pybuild/cpython2_2.7_pyfai/build/pyFAI/test/test_openCL.py",
 line 375, in test_kahan
self.assertEqual(ref64, res)
AssertionError: 67108863.0 != 67108864.0

Stderr:
WARNING:silx.opencl.common:Last chance to get an OpenCL device ... probably not 
the one requested

==
...
Ran 255 tests in 112.925s

FAILED (failures=2, skipped=70)
E: pybuild pybuild:338: test: plugin custom failed with: exit code=1: 
PYTHONPATH=/<>/pyfai-0.16.0+dfsg1/.pybuild/cpython2_2.7_pyfai/build 
http_proxy='127.0.0.1:9' PYFAI_TESTIMAGES=testimages 
PYFAI_DATA=/<>/pyfai-0.16.0+dfsg1 xvfb-run -a --server-args="-screen 
0 1024x768x24" python2.7 ./run_tests.py --low-mem --installed
dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
make[1]: *** [debian/rules:28: override_dh_auto_test] Error 25

Bug#916293: pyqwt3d FTBFS on !amd64

[Adrian Bunk]

Source: pyqwt3d
Version: 0.1.8-2
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=pyqwt3d

...
g++ -c -g -O2 -fdebug-prefix-map=/build/sip4-4tZIxD/sip4-4.19.13+dfsg=. 
-fstack-protector-strong -Wformat -Werror=format-security  -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -Wall -W -DNDEBUG -DGL2PS_HAVE_ZLIB -DHAS_NUMPY -I. 
-I/usr/include/qwtplot3d -I/usr/include/python3.7m 
-I/usr/lib/python3/dist-packages/numpy/core/include 
-I/usr/include/x86_64-linux-gnu/qt5/Qt 
-I/usr/include/x86_64-linux-gnu/qt5/QtCore 
-I/usr/include/x86_64-linux-gnu/qt5/QtGui 
-I/usr/include/x86_64-linux-gnu/qt5/QtWidgets 
-I/usr/include/x86_64-linux-gnu/qt5/QtOpenGL 
-I/usr/include/x86_64-linux-gnu/qt5/ -I/usr/X11R6/include -o sip_Qwt3Dcmodule.o 
sip_Qwt3Dcmodule.cpp
In file included from sip_Qwt3Dcmodule.cpp:7:
sipAPI_Qwt3D.h:12:10: fatal error: QMetaType: No such file or directory
 #include 
  ^~~
compilation terminated.
make[2]: *** [Makefile:17: sip_Qwt3Dcmodule.o] Error 1


The root cause is:
configure/configure-qt5.py:qt_inc_dir="/usr/include/x86_64-linux-gnu/qt5/"

Bug#916220: saidar: segfault after couple of minutes

[Mindaugas Celiesius]

Package: saidar
Version: 0.91-1+b1
Followup-For: Bug #916220

Dear Maintainer,

Again, crash ocurs. Here output of coredumpctl list
TIMEPID   UID   GID SIG COREFILE EXE
Wed 2018-12-12 20:26:56 EET   14429  1000  1000  11 present  /usr/bin/saidar

coredumpctl gdb shows:
PID: 14429 (saidar)
   UID: 1000 (mindaugas)
   GID: 1000 (mindaugas)
Signal: 11 (SEGV)
 Timestamp: Wed 2018-12-12 20:26:55 EET (19min ago)
  Command Line: saidar -c
Executable: /usr/bin/saidar
 Control Group: /user.slice/user-1000.slice/session-1.scope
  Unit: session-1.scope
 Slice: user-1000.slice
   Session: 1
 Owner UID: 1000 (mindaugas)
   Boot ID: f141696875e44f708fd1bcf7d92a6784
Machine ID: 51df46d040b44213a0c2cac3db8b9dd3
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.saidar.1000.f141696875e44f708fd1bcf7d92a6784.14429.1544639215.lz4
   Message: Process 14429 (saidar) of user 1000 dumped core.

Stack trace of thread 14429:
#0  0x7f81aa19653e __strcmp_sse2_unaligned (libc.so.6)
#1  0x7f81aae1fc49 sg_vector_compute_diff 
(libstatgrab.so.10)


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

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

Versions of packages saidar depends on:
ii  libc6  2.24-11+deb9u3
ii  libncurses56.0+20161126-1+deb9u2
ii  libstatgrab10  0.91-1+b1
ii  libtinfo5  6.0+20161126-1+deb9u2

saidar recommends no packages.

saidar suggests no packages.

-- no debconf information

Bug#906016: transition: gjs built with mozjs60

[Simon McVittie]

On Sat, 03 Nov 2018 at 20:47:38 +, Simon McVittie wrote:
> On Wed, 10 Oct 2018 at 20:10:52 +0200, Emilio Pozuelo Monfort wrote:
> > Please go ahead.
> 
> I have uploaded the new gjs, and Jeremy uploaded the matching polari
> version.

gjs has been waiting to migrate for a while, with no warnings in the
excuses document. According to the britney log, it seems to be because
migrating it will make parts of the GNOME stack uninstallable on s390x
(which we already knew was going to happen), including the desktop task:

Trying easy from autohinter: gjs/1.54.3-1 gnome-shell/3.30.2-1 
polari/3.30.2-1
start: 25+0: a-1:i-21:a-0:a-0:a-0:m-1:m-0:m-1:p-0:s-1
orig: 25+0: a-1:i-21:a-0:a-0:a-0:m-1:m-0:m-1:p-0:s-1
easy: 32+0: a-1:i-21:a-0:a-0:a-0:m-1:m-0:m-1:p-0:s-8
* s390x: gdm3, gnome, gnome-characters, gnome-core, gnome-documents, 
gnome-maps, task-pkgs-are-installable-faux
FAILED

Is there something that the release team can do to force this through
(perhaps task-gnome-desktop or task package installability can be marked
as unimportant for s390x?), or are tasksel changes needed, or what?

Thanks,
smcv

Bug#916287: po2oo unusable

[Mechtilde Stehmann]

Control: severity -1 normal


the error message doesn't tell where the problem is.

After downgrading it doesn't work too. So I test it with a new template.

Then it works.

-- 
Mechtilde Stehmann

## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F



signature.asc
Description: OpenPGP digital signature

Bug#881015: Info received (Bug#881015: Info received (Bug#881015: Massive memory leak in ksmserver))

[Julien Aubin]

On Thu, 23 Nov 2017 07:19:23 +0100 Julien Aubin  wrote:
> Another precision is that I start most of these games in windowed mode.
>
> 2017-11-23 7:09 GMT+01:00 Debian Bug Tracking System 
> :
>
> > Thank you for the additional information you have supplied regarding
> > this Bug report.
> >
> > This is an automatically generated reply to let you know your message
> > has been received.
> >
> > Your message is being forwarded to the package maintainers and other
> > interested parties for their attention; they will reply in due course.
> >
> > Your message has been sent to the package maintainer(s):
> >  Debian/Kubuntu Qt/KDE Maintainers 
> >
> > If you wish to submit further information on this problem, please
> > send it to 881...@bugs.debian.org.
> >
> > Please do not send mail to ow...@bugs.debian.org unless you wish
> > to report a problem with the Bug-tracking system.
> >
> > --
> > 881015: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881015
> > Debian Bug Tracking System
> > Contact ow...@bugs.debian.org with problems
> >

Hi,

Looks like an upstream fix has been done for this issue, see
https://bugs.kde.org/show_bug.cgi?id=373274

Could you please backport the fix as it is VERY annoying ?

Thanks,

Bug#916294: statx and statx_timestamp need to be skipped

[Maximiliano Curia]

Package: abi-compliance-checker
Version: 2.3-0.2
Severity: important
Tags: patch

Hi,

with the new glibc version upload sys/stat.h includes bits/statx.h, which in 
turn add two structs (statx and statx_timestamp) which need to be added to the 
C_Structure (TUDump.pm) to avoid a compilation error.


Thanks for maintaining acc in Debian.

Happy hacking,

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

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

Versions of packages abi-compliance-checker depends on:
ii  build-essential  12.5
ii  perl 5.26.2-7+b1

Versions of packages abi-compliance-checker recommends:
ii  exuberant-ctags [ctags]  1:5.9~svn20110310-12

Versions of packages abi-compliance-checker suggests:
pn  doc-base  
pn  icheck

-- no debconf information

--
"La duración de un minuto depende de que lado del baño estés."
-- Ley de la Relatividad (Burke)
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#914887: re: tt-rss: Permission denied error when creating a database user in postgresql

[Paul Gevers]

Hi Sunil,

On Tue, 11 Dec 2018 14:41:29 -0800 Sunil Mohan Adapa 
wrote:
> The problem with configuring tt-rss with postgresql turns out to be in
> dbconfig-common due to usage of su. Similar bugs were fixed in
> quassel-core[1] and monkeysphere[2] packages.

Thanks for the investigation.

> Further, su(1) recommends using
> runuser when used by privileged users.

One learns new things every day.

> Attached patch uses runuser in the pgsql methods instead of su.

Did you run the tests that are part of dbconfig-common with your patch
applied? I am running it now and there seems to be at least one test
case failing.

test_dbc_psql_db_installed_real
case 1: pgsqld in path
case 2: pgsqld not in path
ASSERT:pgsqld should not have been found

I need to check myself what this means.

> The
> shell is not required anymore. However, due to the way single quoted
> strings are passed around in variables such as 'extra', more changes
> would be required. The shell is kept to make the patch minimally impacting.

Thanks for that.

> As the bug impacts all FreedomBox machines trying to install tt-rss,
> please consider making a release with the fix as soon as you can.

If we get a working patch, I'll upload the fix quickly.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#914887: re: tt-rss: Permission denied error when creating a database user in postgresql

[Sunil Mohan Adapa]

On 12/12/18 11:27 am, Paul Gevers wrote:
[...]
>> Attached patch uses runuser in the pgsql methods instead of su.
> 
> Did you run the tests that are part of dbconfig-common with your patch
> applied? I am running it now and there seems to be at least one test
> case failing.
> 
> test_dbc_psql_db_installed_real
> case 1: pgsqld in path
> case 2: pgsqld not in path
> ASSERT:pgsqld should not have been found
> 
> I need to check myself what this means.

I have not run the tests. My apologies. Investigating now.

Thanks,

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#914887: re: tt-rss: Permission denied error when creating a database user in postgresql

[Paul Gevers]

Hmm,

On 12-12-2018 20:31, Sunil Mohan Adapa wrote:
> On 12/12/18 11:27 am, Paul Gevers wrote:
> [...]
>>> Attached patch uses runuser in the pgsql methods instead of su.
>>
>> Did you run the tests that are part of dbconfig-common with your patch
>> applied? I am running it now and there seems to be at least one test
>> case failing.
>>
>> test_dbc_psql_db_installed_real
>> case 1: pgsqld in path
>> case 2: pgsqld not in path
>> ASSERT:pgsqld should not have been found
>>
>> I need to check myself what this means.
> 
> I have not run the tests. My apologies. Investigating now.

Seems I am running them incorrectly. Let me first confirm.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#916021: lintian: Please check for references to build directory

[Dmitry Bogatov]

[2018-12-11 08:26] Chris Lamb 
> [...]
> However, we could trust the "Build-Path" field in a .buildinfo if it
> exists? Would that work for you? I assume yours contains:
>
>   Build-Path: /home/iu/devel/salsa/ucscpi-tcp"?
>
> (You may need to pass --buildinfo-option=--always-include-path to
> dpkg-buildpackage.)

Sounds reasonable. I like it.

Bug#877633: this bug stop sshd

[Jocelyn Jaubert]

Hi,

On Wed, 12 Dec 2018 14:55:55 +0300 Sergey B Kirpichev
 wrote:
> On Wed, 12 Dec 2018 11:13:24 + marc marc  
> wrote:
> > could the priority of the fix be increased accordingly ?
> 
> Are you about backporting existing fix to stable?  I'm not sure,
> that the problem is too severe.

I've seen this issue with Marc, and I find this behaviour dangerous.

We lost access to a debian stretch machine after sshd was killed by
installing monit and openssh checker, like we did on previous debian
version.

Now we know how to solve it, we can put a workaround in the script
installing monit, but other unaware people might hit the same issue.


Thanks,
Jocelyn

Bug#916295: bcron: missing init.d scripts

[Dmitry Bogatov]

Package: bcron
Version: 0.11-2
Severity: wishlist

Dear Maintainer,

please provide /etc/init.d scripts, so bcron could be run with sysvinit.
Here is current content of bin:bcron

$ dpkg -L bcron
/.
/etc
/etc/sv
/usr
/usr/bin
/usr/bin/bcrontab
/usr/sbin
/usr/sbin/bcron-exec
/usr/sbin/bcron-sched
/usr/sbin/bcron-spool
/usr/sbin/bcron-start
/usr/sbin/bcron-update
/usr/share
/usr/share/doc
/usr/share/doc/bcron
/usr/share/doc/bcron/bcron.html
/usr/share/doc/bcron/buildinfo_amd64.gz
/usr/share/doc/bcron/changelog.Debian.gz
/usr/share/doc/bcron/changelog.gz
/usr/share/doc/bcron/copyright
/usr/share/doc-base
/usr/share/doc-base/bcron
/usr/share/info
/usr/share/info/bcron.info.gz
/usr/share/man
/usr/share/man/man1
/usr/share/man/man1/bcrontab.1.gz
/usr/share/man/man8
/usr/share/man/man8/bcron-exec.8.gz
/usr/share/man/man8/bcron-sched.8.gz
/usr/share/man/man8/bcron-spool.8.gz
/usr/share/man/man8/bcron-start.8.gz
/usr/share/man/man8/bcron-update.8.gz

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages bcron depends on:
ii  libbg2  2.04+dfsg-2
ii  libc6   2.28-2
ii  runit   2.1.2-20
ii  runit-helper2.8.1
ii  sysuser-helper  1.3.3

Versions of packages bcron recommends:
ii  bcron-run 0.11-2
ii  msmtp-mta [mail-transport-agent]  1.6.7-1
ii  ucspi-unix1.0-1

bcron suggests no packages.

-- no debconf information


pgp0nZhQoi6WC.pgp
Description: PGP signature

Bug#916230: Svlogd: log files named as `timestamp.u' even if there is no processor in place

[Dmitry Bogatov]

control: tags -1 confirmed

[2018-12-11 18:51] Lorenzo Puliti 
> Package: runit
> Version: 2.1.2-19
> Severity: normal
> 
> Hi Dmitry,
> 
> I have several log directories with more than 10 log files.
> This is true when there are no config files and also when there is
> a config file that sets `num' to 10.
> The patch for #878476 (Fix spin lock on systems with poor clock) excluded
> `.u' files from being deleted, and this fix highlighted that svlogd is
> naming some or all log files as `timestamp.u' instead of `timestamp.s'.
> I have no `processor' in place so this looks wrong to me.
> Also, with a mix of `.t' and `.u' log files the number of old log
> files is no longed guaranteed to be equal to `num'.

True. According to manpage, .u files should not appear if there is no
preprocessor specified.

I managed to reproduce bug. Seems that .u file appears when svlogd is
restarted and there is some .s files, but not always. I plan to debug
it this weekend.

Thank you for report. If you have some ideas, how to reproduce bug
more reliable, it would be great!

Bug#916095: lintian: False positive: license-problem-gfdl-invariants

[Dmitry Bogatov]

[2018-12-11 18:37] Chris Lamb 
> Hi Dmitry,
>  
> > > > any later version published by the Free Software Foundation; 
> > > > with no
> > > > Invariant Sections, no Front-Cover and Back-Cover texts.  [..]
> > > 
> > > … is that it is missing an explicit reference to having "no bad
> > > sections". See #698667 for some of the background?
> > 
> > I am fine with override, but long description asked to report a bug in
> > case of false-positive.
> 
> As I understand it, I don't believe this is a false-positive as it is
> missing "no bad sections".

What is "bad sections"?  In General Resolution [^1], they are not
mentioned.

[^1] www.debian.org/vote/2006/vote_0001

Bug#908760: xdg-utils: xdg-open doesn't work in LXDE on URLs

[Teemu Ikonen]

This bug is fixed in this upstream commit:
https://cgit.freedesktop.org/xdg/xdg-utils/commit/scripts?id=31525d3855f876ddf2e29091b2e8d376f923e09e

Bug#916296: apt-cacher-ng: distkill.pl script referred in documentation is not included

[Nemo Inis]

Package: apt-cacher-ng
Version: 3.2-1
Severity: normal

Dear Maintainer,

Sections 7.2 and 8.2 refer to a distkill.pl script which allows hand-pruning
unneeded distribution releases from the archive.
That script is not included in the current version of apt-cacher-ng.



-- Package-specific info:

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

Kernel: Linux 4.17.0-3-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, 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 apt-cacher-ng depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.69
ii  dpkg   1.19.2
ii  libbz2-1.0 1.0.6-9
ii  libc6  2.27-8
ii  libgcc11:8.2.0-9
ii  liblzma5   5.2.2-1.3
ii  libssl1.1  1.1.1a-1
ii  libstdc++6 8.2.0-9
ii  libsystemd0239-13
ii  libwrap0   7.6.q-27
ii  lsb-base   10.2018112800
ii  zlib1g 1:1.2.11.dfsg-1

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
pn  avahi-daemon  
pn  doc-base  
ii  libfuse2  2.9.8-2

-- Configuration Files:
/etc/apt-cacher-ng/acng.conf changed [not included]
/etc/apt-cacher-ng/security.conf [Errno 13] Permission denied: 
'/etc/apt-cacher-ng/security.conf'

-- debconf information excluded

Bug#916297: reportbug: crash after using "Display modified configuration files"

[Nemo Inis]

Package: reportbug
Version: 7.5.1
Severity: important

Dear Maintainer,

When reporting a bug, reportbug sometimes issues a warning that "The following
configuration files have been modified:" (for the package being reported
against).
It then gives the option to Send the modified files, or "Display modified
configuration files (exit with "q")"

Clicking that button displays the pertinent configuration files OK, but after
pressing q to exit back to the bug, reportbug dies with:

TypeError: on_child_exited() takes 2 positional arguments but 3 were given




-- Package-specific info:
** Environment settings:
EDITOR="vi"
PAGER="less -iXE"
INTERFACE="gtk2"

** /home/jpd/.reportbugrc:
reportbug_version "6.2.1"
mode novice
ui gtk2
realname "Nemo Inis"
email "nemoi...@hotmail.com"
no-cc
header "X-Debbugs-CC: nemoi...@hotmail.com"
smtphost smtp.telus.net

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

Kernel: Linux 4.17.0-3-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, 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 reportbug depends on:
ii  apt1.8.0~alpha2
ii  python33.6.7-1
ii  python3-reportbug  7.5.1
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
pn  dlocate
pn  emacs24-bin-common | emacs25-bin-common
ii  exim4  4.91-8
ii  exim4-daemon-light [mail-transport-agent]  4.91-8+b1
ii  file   1:5.34-2
ii  gnupg  2.2.11-1
pn  python3-urwid  
pn  reportbug-gtk  
ii  xdg-utils  1.1.3-1

Versions of packages python3-reportbug depends on:
ii  apt1.8.0~alpha2
ii  file   1:5.34-2
ii  python33.6.7-1
ii  python3-apt1.7.0
ii  python3-debian 0.1.33
ii  python3-debianbts  2.7.2
ii  python3-requests   2.20.0-2

python3-reportbug suggests no packages.

-- no debconf information

Bug#877633: this bug stop sshd

[Sergey B Kirpichev]

On Wed, Dec 12, 2018 at 08:38:51PM +0100, Jocelyn Jaubert wrote:
> We lost access to a debian stretch machine after sshd was killed by
> installing monit and openssh checker, like we did on previous debian
> version.

1) All configuration snippets povided - are disabled per default.
2) You should carefully read configuration file before turn it on.

Given this, I'm not sure that stable release managers accept a fix.

> Now we know how to solve it, we can put a workaround in the script
> installing monit, but other unaware people might hit the same issue.

But I'll try to provide a fix for stable release, asap.

Bug#916297: reportbug: crash after using "Display modified configuration files"

[Sandro Tosi]

> When reporting a bug, reportbug sometimes issues a warning that "The following
> configuration files have been modified:" (for the package being reported
> against).
> It then gives the option to Send the modified files, or "Display modified
> configuration files (exit with "q")"
>
> Clicking that button displays the pertinent configuration files OK, but after
> pressing q to exit back to the bug, reportbug dies with:
>
> TypeError: on_child_exited() takes 2 positional arguments but 3 were given

please report the unaltered. complete reportbug traceback.

Does it happen for a specific package only or for multiple ones? in
any case, report the exact package this is happening on

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#916298: steam: should depend on steam-devices

[Simon McVittie]

Package: steam
Version: 1.0.0.56-1
Severity: normal
Tags: patch

The Steam client relies on the udev rules in the steam-devices package
to provide access to USB and Bluetooth gamepads, controllers and VR
devices, and to give it the ability to emulate input devices via uinput
when remapping gamepad inputs to control keyboard- and mouse-based
games. The udev rules were originally just for the Steam Controller,
but increasingly many features of the client need input device remapping.

Steam developers at Valve consider it to be a bug that the Debian/Ubuntu
steam package can be installed without also installing the udev rules in
the steam-devices package: I'm told it's generating a noticeable support
burden for them.

Please upgrade the Suggests to a hard dependency, or at least a
Recommends.

Thanks,
smcv
>From 1a62267ce7dfe3344ce9220ef2892db24c2a8e8d Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 13 Nov 2018 14:58:27 +
Subject: [PATCH 6/7] steam-devices: Mark as Multi-Arch: foreign

Otherwise, this package can't satisfy the steam package's dependency
when installed with `dpkg -i` on an amd64 system (at which time it is
assumed to belong to the host architecture), as opposed to when it
is found in the Packages file for an i386 apt repository.

Signed-off-by: Simon McVittie 
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index e8d4c65..42aa32b 100644
--- a/debian/control
+++ b/debian/control
@@ -51,6 +51,7 @@ Description: Valve's Steam digital software delivery system
 
 Package: steam-devices
 Architecture: all
+Multi-Arch: foreign
 Depends:
  ${misc:Depends},
 Recommends:
-- 
2.20.0

>From b68d802c8cac4feea6f4d79f879e30fb87091dc3 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 13 Nov 2018 12:21:24 +
Subject: [PATCH 2/7] Upgrade steam-devices to a hard dependency

Valve developers have requested that the Debian/Ubuntu steam package
should always pull in steam-devices. Increasingly many features of the
Steam client require the ability to emulate input devices (for the
Steam Controller, in-home streaming or VR), and not installing
steam-devices automatically has become a significant upstream support
burden.

Signed-off-by: Simon McVittie 
---
 debian/control | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 420e230..f1c44a4 100644
--- a/debian/control
+++ b/debian/control
@@ -20,6 +20,7 @@ Pre-Depends:
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
+ steam-devices,
  xz-utils,
  libudev1,
  libxinerama1,
@@ -34,8 +35,6 @@ Recommends:
  fonts-liberation,
  nvidia-driver-libs-i386,
  xterm | x-terminal-emulator,
-Suggests:
- steam-devices,
 Description: Valve's Steam digital software delivery system
  Steam (http://www.steampowered.com) is a software content delivery system
  developed by Valve software (http://www.valvesoftware.com).  There is
-- 
2.20.0

Bug#916299: postgresql-11: starts with error after upgrade from stretch to buster

[Andreas Beckmann]

Package: postgresql-11
Version: 11.1-1
Severity: important
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

  Setting up postgresql-11 (11.1-1+b2) ...
  Creating new PostgreSQL cluster 11/main ...
  /usr/lib/postgresql/11/bin/initdb -D /var/lib/postgresql/11/main --auth-local 
peer --auth-host md5
  The files belonging to this database system will be owned by user "postgres".
  This user must also own the server process.
  
  The database cluster will be initialized with locale "C.UTF-8".
  The default database encoding has accordingly been set to "UTF8".
  The default text search configuration will be set to "english".
  
  Data page checksums are disabled.
  
  fixing permissions on existing directory /var/lib/postgresql/11/main ... ok
  creating subdirectories ... ok
  selecting default max_connections ... 100
  selecting default shared_buffers ... 128MB
  selecting dynamic shared memory implementation ... posix
  creating configuration files ... ok
  running bootstrap script ... ok
  performing post-bootstrap initialization ... ok
  syncing data to disk ... ok
  
  Success. You can now start the database server using:
  
  /usr/lib/postgresql/11/bin/pg_ctl -D /var/lib/postgresql/11/main -l 
logfile start
  
  Ver Cluster Port Status OwnerData directory  Log file
  [ESC][31m11  main5432 down   postgres /var/lib/postgresql/11/main 
/var/log/postgresql/postgresql-11-main.log[ESC][0m
  update-alternatives: using /usr/share/postgresql/11/man/man1/postmaster.1.gz 
to provide /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) in auto mode
  invoke-rc.d: could not determine current runlevel
  Starting PostgreSQL 11 database server: mainThe PostgreSQL server failed to 
start. Please check the log output: 2018-12-12 17:39:34.198 UTC [17806] LOG: 
listening on IPv6 address "::1", port 5432 2018-12-12 17:39:34.198 UTC [17806] 
LOG: listening on IPv4 address "127.0.0.1", port 5432 2018-12-12 17:39:34.198 
UTC [17806] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 
2018-12-12 17:39:34.204 UTC [17833] LOG: database system was shut down at 
2018-12-12 17:39:33 UTC 2018-12-12 17:39:34.207 UTC [17806] LOG: database 
system is ready to accept connections 2018-12-12 17:39:34.792 UTC [19057] 
[unknown]@[unknown] LOG: incomplete startup packet ... failed!
   failed!
  invoke-rc.d: initscript postgresql, action "start" failed.
  dpkg: error processing package postgresql-11 (--configure):
   subprocess installed post-installation script returned error exit status 1


To summarize what the piuparts test does (should do) for postgresql:

- start with a minimal stretch chroot, allow starting the postgresql service
- install postgresql
- switch apt sources to buster
- install postgresql/buster
*** it failed here to start the -11 server ***
therefore the following actions were not performed
- perform the pg_upgradecluster dance
- perform the --dist-upgrade

The intention of upgrading postgresql early is to ensure the service is running 
throughout the dist-upgrade for the tested packages to be able to perform
their database upgrades.
Packages that only recommend the postgresql package (because they could also 
work with a remote database server) get postgresql installed into the chroot
by piuparts before the actual test starts. During dist-upgrade there is no
dependency ensuring that postgresql is running  while the upgraded database
using package gets configured, so upgrading postgresql first avoids any downtime
during the dist-upgrade.

This scheme has been working quite well for some time already, but we are always
open for improvements.


If I enter the chroot directly after the failure, I find the following state:

# invoke-rc.d postgresql status
invoke-rc.d: could not determine current runlevel
9.6/main (port 5432): online
11/main (port 5433): online

# invoke-rc.d postgresql stop
invoke-rc.d: could not determine current runlevel
[ ok ] Stopping PostgreSQL 11 database server: main.
[ ok ] Stopping PostgreSQL 9.6 database server: main.

# invoke-rc.d postgresql start
invoke-rc.d: could not determine current runlevel
[] Starting PostgreSQL 11 database server: main[] The PostgreSQL server 
failed to start. Please check the log output: 2018-12-12 20:08:03.529 UTC [892] 
LOG: listening on IPv6 address "::1", port 5433 2018-12-12 20:08:03.529 UTC 
[892] LOG: listening on IPv4 address "127.0.0.1", port 5433 2018-12-12 
20:08:03.529 UTC [892] LOG: listening on Unix socket 
"/var/run/postgresql/.s.PGSQL.5433" 2018-12-12 20:08:03.544 UTC [898] LOG: 
database system was shut down at 2018-12-12 20:07:51 UTC 2018-12-12 
20:08:03.548 UTC [892] LOG: database system is ready to accept connections 
2018-12-12 20:08:04.126 UTC [986] [unknown]@[unknown] LOG:[FAILmplete startup 
pac

Bug#916300: steam: intended d/copyright change (https URL) not reflected in d/copyright.in

[Simon McVittie]

Package: steam
Version: 1.0.0.56-1
Severity: minor
Tags: patch

The copyright file in the steam package is meant to contain a https URL,
but if it is regenerated from d/copyright.in this change is lost.

smcv
>From 8b444a94a1bd2df003728d80a700a3084b87224e Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Fri, 23 Nov 2018 19:11:20 +
Subject: [PATCH 1/7] d/copyright.in: Really refer to the https form of
 copyright-format

d/copyright is generated from d/copyright.in and license files.

Signed-off-by: Simon McVittie 
---
 debian/copyright.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/copyright.in b/debian/copyright.in
index a74dd98..0bbbda2 100644
--- a/debian/copyright.in
+++ b/debian/copyright.in
@@ -1,5 +1,5 @@
 Format: Mostly copyright-format 1.0
-#   http://www.debian.org/doc/packaging-manuals/copyright-format/1.0
+#   https://www.debian.org/doc/packaging-manuals/copyright-format/1.0
 #   This file does not entirely adhere to copyright-format 1.0 since
 #   that would require reformating the steam license agreement (adding
 #   spaces, dots, and word-wrapping), and  modifications to the license
-- 
2.20.0

Bug#905734: found #905734 hplip/3.17.10

[Didier 'OdyX' Raboud]

Dear Paul,

Le vendredi, 7 décembre 2018, 16.15:01 h CET Paul Elliott a écrit :
> I just downloaded it. It won't build under stretch. All the builds shown in
> the logs are under sid or experimental.

It does under stretch-backports (aka stretch + backports)

https://buildd.debian.org/status/package.php?p=hplip&suite=stretch-backports

To build, it needs debhelper and dh-autoreconf from backports indeed.

> Correct me if I am wrong, but if you build under sid, it won't run under
> stretch, because the libraries linked against won't be the same.

Exactly. Different release suites produce differently linked software.

> I don't think it will help stretch users.

Stretch users don't get updated software, ONLY security fixes.

Stretch users who enabled backports can get an hplip that was built against 
stretch libraries that can be installed on stretch hosts.

You seem to want a source hplip from unstable that builds without 
modifications in stable. That's not something I'm interested in providing and 
a very unusual requirement for Debian packages.

You also seem to want binary hplip packages that, when built in unstable, can 
be installed on stretch hosts. That neither is something I'm interested in 
providing, _also_ an unusual requirement, and that cannot be easily 
guaranteed.

Finally, this bug was about "Unable to backport package hplip on stretch".  It 
is not a requirement for unstable packages to build without changes on stable.  
So I made minimal changes (thanks to inputs from this bug) to be able to build 
hplip in stretch-backports, AND I uploaded this modified package to the 
stretch-backports suite.  It is now accessible in the Debian-standard way to 
get backported packages on stable.  There's nothing more I can (or will) do.

EOD for me.

Cheers,
OdyX

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

Bug#916301: steam: cannot be built with debuild -ai386 on an amd64 system

[Simon McVittie]

Package: steam
Version: 1.0.0.56-1
Severity: minor
Tags: patch

If you have an amd64 system (as I would expect essentially all Steam
users do), the Debian steam package can't be built with debuild -ai386
due to two minor issues:

* the Build-Depends on python3 wants a host-architecture (i386) version
  of python3, but should use python3:any to accept a build-architecture
  (amd64) version, since we are not compiling Python extensions

* d/rules mixes up DEB_BUILD_ARCH with DEB_HOST_ARCH

Patch attached.

smcv
>From 8218cb0a0f83a280605307c4216d48ebc1be88a0 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 13 Nov 2018 14:49:21 +
Subject: [PATCH 5/7] Allow cross-compilation for i386 on a non-i386 build
 machine

Signed-off-by: Simon McVittie 
---
 debian/control | 2 +-
 debian/rules   | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index f1c44a4..e8d4c65 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Debian Games Team 
 Uploaders: Michael Gilbert 
 Build-Depends:
  debhelper (>= 11),
- python3,
+ python3:any,
  libx11-6,
 XS-Autobuild: yes
 Standards-Version: 4.2.1
diff --git a/debian/rules b/debian/rules
index 643516d..f7124aa 100755
--- a/debian/rules
+++ b/debian/rules
@@ -8,8 +8,8 @@ orig=../steam_$(uversion).orig.tar.xz
 dest=../steam-$(uversion).orig
 
 build-arch:
-ifneq ($(DEB_BUILD_ARCH), i386)
-	@echo "error: $(DEB_BUILD_ARCH) is not a supported architecture"
+ifneq ($(DEB_HOST_ARCH), i386)
+	@echo "error: $(DEB_HOST_ARCH) is not a supported architecture"
 	@exit 1
 endif
 
-- 
2.20.0

Bug#889885: patch

[dann frazier]

tags 889885 + patch
kthxbye

Here's a patch that does as described in Message #10. Note that ovmf
is left as a Suggests for Ubuntu because the MIR is still in review.

--- qemu-3.1+dfsg.orig/debian/control-in2018-12-02 09:10:27.0 
-0700
+++ qemu-3.1+dfsg/debian/control-in 2018-12-12 13:22:29.647040076 -0700
@@ -241,9 +241,9 @@
 Recommends: qemu-system-gui (= ${binary:Version}), qemu-utils,
 # aarch64 arm uses bootroms
  ipxe-qemu (>= 1.0.0+git-2013.c3d1e78-1~),
-:debian: qemu-efi
+:debian: qemu-efi-aarch64, qemu-efi-arm
 Suggests: samba, vde2, qemu-block-extra (= ${binary:Version}),
-:ubuntu: qemu-efi
+:ubuntu: qemu-efi-aarch64, qemu-efi-arm
 Provides: ${sysprovides:arm}
 Description: QEMU full system emulation binaries (arm)
  QEMU is a fast processor emulator: currently the package supports
@@ -337,9 +337,11 @@
 Depends: ${shlibs:Depends}, ${misc:Depends}, qemu-system-common (>> 1:2.12~), 
qemu-system-data (>> ${source:Version}~),
  seabios (>= 1.10.2-1~), ipxe-qemu (>= 1.0.0+git-2013.c3d1e78-1~)
 Recommends: qemu-system-gui (= ${binary:Version}), qemu-utils,
+:debian: ovmf
 :ubuntu: cpu-checker
 Suggests: samba, vde2, qemu-block-extra (= ${binary:Version}),
- sgabios, ovmf
+ sgabios
+:ubuntu: ovmf
 Provides: ${sysprovides:x86}
 Description: QEMU full system emulation binaries (x86)
  QEMU is a fast processor emulator: currently the package supports