Bug#889923: First attempt at packaging go-errors

2018-04-04 Thread Raju Devidas
Reply In between


On 03/27/2018 10:26 PM, Rock Storm wrote:
> Hi,
>
> A long time ago I made a first attempt at packaging go-errors/errors
> [0], as I needed it for packaging the latest version of Arduino.
Nice, I wanted to get along packaging Arduino as well. Or help
maintaining it.
It's a petty that we lag behind maintaining the latest versions of a lot
of important packages like Arduino.
>
>  [0]: https://github.com/rockstorm101/go-errors-errors-debian-pkg
>  
> If you are still interested in packaging it, you might find it useful.
> I just updated the repository with the latest release.
Thanks a lot for the work, I'll refer it.
>
> If you are not interested or you don't mind me taking over the 
> packaging, it seems the attempt to package Arduino is back on track. So 
> we would need this dependency packaged soon.
Don't worry I'll get this done at the earliest. Actually I don't mind
you taking over,
it is just that I was working on it today. I also need this to be
packaged as a dependency for micro-editor.
> Let me know what you think,
>
> Regards,
>

-- 
Raju Devidas
rajudev.gitlab.io
XMPP/Jabber: rajudev(at)disroot.org



Bug#894875: RFS: cavestory-nx/1.0.0-1 [ITP] -- NXEngine is a Cave Story game engine clone

2018-04-04 Thread Carlos Donizete Froes
Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package "cavestory-nx"

 * Package name: cavestory-nx
   Version : 1.0.0-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://github.com/coringao/cavestory-nx
 * License : GPL-3+
   Section : contrib/games

  It builds those binary packages:

 cavestory-nx - NXEngine is a Cave Story game engine clone
 cavestory-nx-data -NXEngine is a Cave Story game engine clone (data files)

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

  https://mentors.debian.net/package/cavestory-nx

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

  dget -x https://mentors.debian.net/debian/pool/contrib/c/cavestory-
nx/cavestory-nx_1.0.0-1.dsc

  More information about Cave Story NX can be obtained from
https://github.com/coringao/cavestory-nx.


  Regards,
   Carlos Donizete Froes [a.k.a coringao]



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

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


Bug#470939: ok

2018-04-04 Thread Eric Barry
-message -
From: Eric Barry 
Date: Thu, Apr 5, 2018 at 5:04 AM
Subject: ok
To:


Bug#894852: Here's a URL to that core dump of qemu's segfault

2018-04-04 Thread Michael Tokarev
05.04.2018 07:55, Kingsley G. Morse Jr. wrote:
> It's at
> 
> http://loaner.com/core_of_qemu_SIGSEGV.1.gz
> 
> You should be able to decompress it with a command
> like:
> 
> $ gunzip kingsleys_stupendous_core_dump.gz

Thank you very much for your attempts.

But I *think* this bug has been already addressed in an upcoming
release of qemu (wich will contain a *ton* of changes all over).

2.11 version in debian is built with SDL2 GUI front-end. This one
turned out to be not mature enough, with numerous bugs starting from
crashes and up to various small nits here and there.  New release will
be compiled with GTK3 GUI, which is much more mature. I already marked
all bugs related to SDL2 GUI as "pending upload", this one will follow.

But there are some issues still. Due to large amount of changes I'd love
to test things as much as possible before uploading, to ensure it doesn't
break anything. And there's really lots of changes. Upstream hasn't
released 2.12 yet, only a few release candidates, and a few issues
still remain there as well. Expecting the new release really soon now.
And finally, qemu package in Debian will contain several new binary
packages, which will have to enter manual NEW queue (each new package
need manual approval from the Debian FTP team), so it might delay
things even more.  Still I'm sure we'll be there very soon :)

Thank you for your understanding!

/mjt



Bug#889033: smartmontools: New version (6.6) is available

2018-04-04 Thread Christian Franke
For a smartmontools-6.6+ package, please reconsider the decision to 
remove the update-smart-drivedb script (Bug#804299) as it now validates 
the downloaded file.


See https://www.smartmontools.org/ticket/751 for details.

Related: Bug#824795



Bug#894852: Here's a URL to that core dump of qemu's segfault

2018-04-04 Thread Kingsley G. Morse Jr.
It's at

http://loaner.com/core_of_qemu_SIGSEGV.1.gz

You should be able to decompress it with a command
like:

$ gunzip kingsleys_stupendous_core_dump.gz

So,
Kingsley

-- 
Time is the fire in which we all burn.



Bug#894872: astyle: symbols adjustments to support build with -O3

2018-04-04 Thread Steve Langasek
Package: astyle
Followup-For: Bug #894872
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Sorry, looks like I missed one more symbol.  Revised patch attached.
diff -Nru astyle-3.1/debian/libastyle3.symbols 
astyle-3.1/debian/libastyle3.symbols
--- astyle-3.1/debian/libastyle3.symbols2018-03-18 06:07:06.0 
-0700
+++ astyle-3.1/debian/libastyle3.symbols2018-04-04 21:49:56.0 
-0700
@@ -526,12 +526,12 @@
  
(arch=armel)_ZNSt19_Sp_counted_deleterIPN6astyle12ASPeekStreamENSt12__shared_ptrIS1_LN9__gnu_cxx12_Lock_policyE1EE8_DeleterISaIS1_EEES8_LS5_1EED1Ev@Base
 3.0
  
(arch=armel)_ZNSt19_Sp_counted_deleterIPN6astyle12ASPeekStreamENSt12__shared_ptrIS1_LN9__gnu_cxx12_Lock_policyE1EE8_DeleterISaIS1_EEES8_LS5_1EED2Ev@Base
 3.0
  
(optional)_ZNSt6vectorIN6astyle10ASEnhancer15SwitchVariablesESaIS2_EE17_M_realloc_insertIJRS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.0
- 
_ZNSt6vectorIN6astyle9BraceTypeESaIS1_EE17_M_realloc_insertIJRS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 3.1
+ 
(optional)_ZNSt6vectorIN6astyle9BraceTypeESaIS1_EE17_M_realloc_insertIJRS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 3.1
  
_ZNSt6vectorIN6astyle9BraceTypeESaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 3.0
  
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 3.0
  
_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE12emplace_backIJRS7_EEEvDpOT_@Base
 3.0
  
_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base
 0debian2.06
- 
_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE17_M_realloc_insertIJRS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 3.0
+ 
(optional)_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE17_M_realloc_insertIJRS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 3.0
  
(optional)_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 3.0
  
(arch-bits=32)_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE7reserveEj@Base
 3.0
  
(arch-bits=64|optional)_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE7reserveEm@Base
 3.0
@@ -539,17 +539,18 @@
  
(optional)_ZNSt6vectorIPKSt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_ESaISA_EE17_M_realloc_insertIJSA_EEEvN9__gnu_cxx17__normal_iteratorIPSA_SC_EEDpOT_@Base
 3.0
  
(optional)_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE12emplace_backIJRS2_EEEvDpOT_@Base
 3.0
  
(optional)_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE12emplace_backIJS2_EEEvDpOT_@Base
 3.0
- 
_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE17_M_realloc_insertIJRS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.0
- 
_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.1
+ 
(optional)_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE17_M_realloc_insertIJRS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.0
+ 
(optional)_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.1
  
(optional)_ZNSt6vectorIPS_IPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EESaISA_EE12emplace_backIJSA_EEEvDpOT_@Base
 0debian2.06
- 
_ZNSt6vectorIPS_IPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EESaISA_EE17_M_realloc_insertIJSA_EEEvN9__gnu_cxx17__normal_iteratorIPSA_SC_EEDpOT_@Base
 3.0
+ 
(optional)_ZNSt6vectorIPS_IPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EESaISA_EE17_M_realloc_insertIJSA_EEEvN9__gnu_cxx17__normal_iteratorIPSA_SC_EEDpOT_@Base
 3.0
  
(optional)_ZNSt6vectorISt4pairIiiESaIS1_EE17_M_realloc_insertIJRS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 3.0
+ (optional)_ZNSt6vectorISt4pairIiiESaIS1_EE12emplace_backIJRS1_EEEvDpOT_@Base 
3.1
  _ZNSt6vectorISt4pairIiiESaIS1_EEaSERKS3_@Base 0debian2.06
  _ZNSt6vectorIbSaIbEE13_M_insert_auxESt13_Bit_iteratorb@Base 0debian2.06
  _ZNSt6vectorIiSaIiEE12emplace_backIJRiEEEvDpOT_@Base 3.0
  _ZNSt6vectorIiSaIiEE12emplace_backIJiEEEvDpOT_@Base 0debian2.06
- 
_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJRiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 3.1
- 
_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 3.0
+ 
(optional)_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJRiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 3.1
+ 
(optional)_ZNSt6vectorIiSaIiEE17_M_realloc_insertIJiEEEvN9__gnu_cxx17__normal_iteratorIPiS1_EEDpOT_@Base
 3.0
  _ZNSt6vectorIiSaIiEEaSERKS1_@Base 0debian2.06
  

Bug#894873: fontforge: Please remove myself from Uploaders

2018-04-04 Thread Christian Perrier
Package: fontforge
Version: 1:20170731~dfsg-1
Severity: minor

I'm no longer active in font packages maintenance, so I'm in the
process of requesting to be removed from Uploaders in packages where
I'm listed as such.

So, for next uploads, may I suggest that my name is removed from
Uploaders?

Thanks in advance.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fontforge depends on:
ii  fontforge-common  1:20170731~dfsg-1
ii  libc6 2.27-2
ii  libfontforge2 1:20170731~dfsg-1
ii  libgdraw5 1:20170731~dfsg-1
ii  libltdl7  2.4.6-2
ii  libx11-6  2:1.6.4-3

fontforge recommends no packages.

Versions of packages fontforge suggests:
pn  autotrace 
pn  fontforge-doc 
pn  fontforge-extras  
pn  potrace   
pn  python-fontforge  

-- no debconf information



Bug#894872: astyle: symbols adjustments to support build with -O3

2018-04-04 Thread Steve Langasek
Package: astyle
Version: 3.1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

While the 3.1-1 upload includes adjustments to the symbols files
specifically for supporting builds with -O3, version 3.1-1 still fails to
build in Ubuntu on ppc64el where the port is built with -O3 by default.

Please find attached a patch which handles making all the necessary
remaining template symbols 'optional'.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru astyle-3.1/debian/libastyle3.symbols 
astyle-3.1/debian/libastyle3.symbols
--- astyle-3.1/debian/libastyle3.symbols2018-03-18 06:07:06.0 
-0700
+++ astyle-3.1/debian/libastyle3.symbols2018-04-04 21:48:58.0 
-0700
@@ -526,12 +526,12 @@
  
(arch=armel)_ZNSt19_Sp_counted_deleterIPN6astyle12ASPeekStreamENSt12__shared_ptrIS1_LN9__gnu_cxx12_Lock_policyE1EE8_DeleterISaIS1_EEES8_LS5_1EED1Ev@Base
 3.0
  
(arch=armel)_ZNSt19_Sp_counted_deleterIPN6astyle12ASPeekStreamENSt12__shared_ptrIS1_LN9__gnu_cxx12_Lock_policyE1EE8_DeleterISaIS1_EEES8_LS5_1EED2Ev@Base
 3.0
  
(optional)_ZNSt6vectorIN6astyle10ASEnhancer15SwitchVariablesESaIS2_EE17_M_realloc_insertIJRS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.0
- 
_ZNSt6vectorIN6astyle9BraceTypeESaIS1_EE17_M_realloc_insertIJRS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 3.1
+ 
(optional)_ZNSt6vectorIN6astyle9BraceTypeESaIS1_EE17_M_realloc_insertIJRS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 3.1
  
_ZNSt6vectorIN6astyle9BraceTypeESaIS1_EE17_M_realloc_insertIJS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 3.0
  
_ZNSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE17_M_realloc_insertIJRS5_EEEvN9__gnu_cxx17__normal_iteratorIPS5_S7_EEDpOT_@Base
 3.0
  
_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE12emplace_backIJRS7_EEEvDpOT_@Base
 3.0
  
_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE12emplace_backIJS7_EEEvDpOT_@Base
 0debian2.06
- 
_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE17_M_realloc_insertIJRS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 3.0
+ 
(optional)_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE17_M_realloc_insertIJRS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 3.0
  
(optional)_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE17_M_realloc_insertIJS7_EEEvN9__gnu_cxx17__normal_iteratorIPS7_S9_EEDpOT_@Base
 3.0
  
(arch-bits=32)_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE7reserveEj@Base
 3.0
  
(arch-bits=64|optional)_ZNSt6vectorIPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EE7reserveEm@Base
 3.0
@@ -539,17 +539,18 @@
  
(optional)_ZNSt6vectorIPKSt4pairIKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES7_ESaISA_EE17_M_realloc_insertIJSA_EEEvN9__gnu_cxx17__normal_iteratorIPSA_SC_EEDpOT_@Base
 3.0
  
(optional)_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE12emplace_backIJRS2_EEEvDpOT_@Base
 3.0
  
(optional)_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE12emplace_backIJS2_EEEvDpOT_@Base
 3.0
- 
_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE17_M_realloc_insertIJRS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.0
- 
_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.1
+ 
(optional)_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE17_M_realloc_insertIJRS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.0
+ 
(optional)_ZNSt6vectorIPN6astyle12ASBeautifierESaIS2_EE17_M_realloc_insertIJS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT_@Base
 3.1
  
(optional)_ZNSt6vectorIPS_IPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EESaISA_EE12emplace_backIJSA_EEEvDpOT_@Base
 0debian2.06
- 
_ZNSt6vectorIPS_IPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EESaISA_EE17_M_realloc_insertIJSA_EEEvN9__gnu_cxx17__normal_iteratorIPSA_SC_EEDpOT_@Base
 3.0
+ 
(optional)_ZNSt6vectorIPS_IPKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaIS7_EESaISA_EE17_M_realloc_insertIJSA_EEEvN9__gnu_cxx17__normal_iteratorIPSA_SC_EEDpOT_@Base
 3.0
  
(optional)_ZNSt6vectorISt4pairIiiESaIS1_EE17_M_realloc_insertIJRS1_EEEvN9__gnu_cxx17__normal_iteratorIPS1_S3_EEDpOT_@Base
 3.0
+ (optional)_ZNSt6vectorISt4pairIiiESaIS1_EE12emplace_backIJRS1_EEEvDpOT_@Base 
3.1
  _ZNSt6vectorISt4pairIiiESaIS1_EEaSERKS3_@Base 0debian2.06
  _ZNSt6vectorIbSaIbEE13_M_insert_auxESt13_Bit_iteratorb@Base 0debian2.06
  _ZNSt6vectorIiSaIiEE12emplace_backIJRiEEEvDpOT_@Base 3.0
  _ZNSt6vectorIiSaIiEE12emplace_backIJiEEEvDpOT_@Base 

Bug#894870: lintian could ask maintainers to use dh_auto_*

2018-04-04 Thread Helmut Grohne
Package: lintian
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap

Chris asked me to file this vague idea as a bug to keep track of the
discussion. If the discussion winds down, please don't hesitate to close
this as wontfix.

While making packages cross buildable, I noticed another *very* common
fix pattern and I am wondering how to automate it. The pattern is
actually multiple ones:

 * s!\./configure !dh_auto_configure -- !
 * s/cmake /dh_auto_configure -- /
 * s/qmake /dh_auto_configure -- /
 * s/\$(MAKE)/dh_auto_build --/

The reason why this helps is that debhelper has knowledge of cross
compilation in many cases. It passes additional flags for each of these
commands.

Now it's not quite as simple as depicted here. Let me share some
experience and explain corner cases.

 * Some ./configure scripts are very old or not generated by autotools.
   In such cases, dh_auto_configure may be unusable, because it passes
   unrecognized flags.
 * When applying any of these, one must add "debhelper (>= 7)" to
   Build-Depends.
 * When converting ./configure, it is often useful to drop redundant
   flags such as --prefix=/usr --mandir=... --infodir=... and others.
 * Depending on the compat level, dh_auto_configure passes a multiarch
   --libdir which might not work with a package immediately.
 * When doing out-of-tree builds with autotools, one usually uses
   "cd builddir && ../configure ..." and that should be translated to
   --builddirectory. Sometimes though it is "cd src && ./configure ..."
   in which case, it needs to be --sourcedirectory.
 * For cmake, most packages use out of tree builds (with a different
   directory name from debhelper) and thus often requires
   --builddirectory.
 * When substituting $(MAKE), be careful to distinguish dh_auto_build
   and dh_auto_install.
 * Some packages have multiple build systems and need to explicitly
   select one.

You'll find lots of example patches at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=rebootstrap;users=helm...@debian.org
Check only ones with "FTCBFS", "build architecture" is a good title
filter as well.

If we add something like this, I think it cannot be above certainty
possible, because there are so many cases, where this choice has a good
reason. This is certainly not a "copy & paste"-kind of advice, but one
where the packager needs to think about the implications. It's more akin
to "please increase the compatibility level", which can break in
similarly subtle ways.

Additional benefits (or caveats):
 * For some build systems (e.g. cmake) dh_auto_configure automatically
   passes dpkg-buildflags.
 * For the makefile buildsystem, dh_auto_install tries to prevent
   stripping (in higher compat levels) to get useful -dbgsym packages.

In any case, the real lesson learned here is that our tool diversity has
a significant cost. In a sense, a lot of my patches have converted
packages to become more standard debhelper packages. Such uniformity
lets us eliminate whole bug classes with little changes and that's
something I've used a lot as at least Niels knows. I had to replicate a
few of these for cdbs. From this experience, I think that we should more
aggressively try to move away from tool diversity. Other areas (such as
maintainer script removal or R³) also benefit from decreased tool
diversity.

Now it reads more like this mail should have gone to d-devel. Can we
turn this into something useful anyhow?

Helmut



Bug#894871: ctorrent FTCBFS: configures for the build architecture

2018-04-04 Thread Helmut Grohne
Source: ctorrent
Version: 1.3.4.dnh3.3.2-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ctorrent fails to cross build from source, because fails passing the
relevant --host flag to ./configure. The easiest way of doing so is
deferring the task to dh_auto_configure. After doing so, ctorrent cross
builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru ctorrent-1.3.4.dnh3.3.2/debian/changelog 
ctorrent-1.3.4.dnh3.3.2/debian/changelog
--- ctorrent-1.3.4.dnh3.3.2/debian/changelog2016-12-07 22:57:46.0 
+0100
+++ ctorrent-1.3.4.dnh3.3.2/debian/changelog2018-04-05 06:08:50.0 
+0200
@@ -1,3 +1,10 @@
+ctorrent (1.3.4.dnh3.3.2-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 05 Apr 2018 06:08:50 +0200
+
 ctorrent (1.3.4.dnh3.3.2-5) unstable; urgency=low
 
   * Orphaning package. 
diff --minimal -Nru ctorrent-1.3.4.dnh3.3.2/debian/rules 
ctorrent-1.3.4.dnh3.3.2/debian/rules
--- ctorrent-1.3.4.dnh3.3.2/debian/rules2012-04-15 16:40:42.0 
+0200
+++ ctorrent-1.3.4.dnh3.3.2/debian/rules2018-04-05 06:08:45.0 
+0200
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 override_dh_auto_configure:
-   ./configure --prefix=/usr $(shell dpkg-buildflags 
--export=configure) --with-ssl=no
+   dh_auto_configure -- $(shell dpkg-buildflags --export=configure) 
--with-ssl=no
 
 %:
dh $@ 


Bug#894867: gitlab: GitLab Security Release: 10.6.3, 10.5.7, and 10.4.7

2018-04-04 Thread Salvatore Bonaccorso
Source: gitlab
Version: 10.6.2+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
Control: clone -1 -2 -3
Control: retitle -1 gitlab: Confidential issue comments in Slack, Mattermost, 
and webhook integrations
Control: retitle -2 gitlab: Persistent XSS in milestones data-milestone-id
Control: retitle -3 gitlab: Persistent XSS in filename of merge request
Control: found -1 8.13.11+dfsg1-8
Control: found -3 8.13.11+dfsg1-8


Hi

New gitlab release fixing three issues. Will fill three bugs for it
since no CVEs are assigned (yet) to clearly identify the issues
(cloning this bug report to three bugs).

See: 
https://about.gitlab.com/2018/04/04/security-release-gitlab-10-dot-6-dot-3-released/

Regards,
Salvatore



Bug#891216: Requre d-devel consultation for epoch bump

2018-04-04 Thread Sean Whitton
Hello,

On Mon, Feb 26 2018, Mattia Rizzolo wrote:

> This needs to be reworded.  "the +really convention" is probably not
> really policy material (feels more like devref's) and therfore probably
> not mentioned here.

I disagree.  Policy often describes conventions; in particular,
conventions that exist in response to things that are forbidden or
required by Policy.

Moreover, we want someone reading about epochs to be hinted towards the
+really convention, without hoping that they just happen to head over to
devref right after.

> And with this the mention of d-devel happened twice in your patch.

This is Ian responding to the fact that epochs are discussed in two
places.

I would rather fix that in a separate bug.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#891216: Requre d-devel consultation for epoch bump

2018-04-04 Thread Sean Whitton
Hello Ian,

On Fri, Feb 23 2018, Ian Jackson wrote:

> We had another thread on debian-devel recently, in which it once again
> became evident that epochs are misunderstood.  Epoch bumps should be
> rare and there are often better solutions.  I suggest that we should
> ask people to consult debian-devel.

I agree.

> Also we should encourage the +really convention rather than epoch
> bumps.

I agree.

>   + Epochs can help when the upstream version numbering scheme
>   + changes, but they must be used with care.  In Debian, please
>   + consult debian-devel when changing the epoch.

This doesn't use one of the usual Policy terms "must", "should" or
"recommended", yet it's an imperative, so I find it ambiguous whether
this is a requirement of Policy or a suggested best practice.

So I think we should have:

You should not change the epoch for a package before this has been
discussed on the debian-devel mailing list and a consensus about
doing that has been reached.

This is consistent with wording elsewhere in Policy.

I also prefer to drop the "In Debian" because Policy does not usually
qualify Debian-specific practices, and if we are going to start doing
that, we should have a separate discussion and not let it hold up this
bug.

>   ...
>
> Note that the purpose of epochs is
>   - to allow us to leave behind mistakes in version numbering, and
> to cope with situations where the
>   + upstream
> version numbering scheme changes
>   + and to allow us to leave behind serious mistakes
> .
>   +
>   + Epochs should not usually be used when
>   + a package needs to be rolled back (use the +really convention)

I would prefer to see an explanation of the +really convention if you'd
care to write one, but that's informative so can be added later.

>   + or to
> cope with
>   - It is not intended to
> version numbers containing strings of letters which the package
> management system cannot interpret (such as ALPHA or pre-), or with
> silly orderings.
>   +
>   + If you think that increasing the epoch is the right situation,
>   + please consult debian-devel before doing so
>   + (even in experimental).

For consistency, s/please/you should/.

Seconds?

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#894866: python-cmor: Syntax error at upgrade

2018-04-04 Thread Nicolas Patrois
Package: python-cmor
Version: 3.3.2-1
Severity: important

Dear Maintainer,

The upgrade is blocked due to a syntax error in the configuration.
It seems that a Python 3 syntax is used in a Python 2 script:
  File "/usr/lib/python2.7/dist-packages/cmip6_cv/PrePARE/PrePARE.py", line 720
print (str(errmsg), file=sys.stderr)
^
SyntaxError: invalid syntax

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

Kernel: Linux 4.3.0-1-686-pae (SMP w/3 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR:fr:en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-cmor depends on:
ii  libc6 2.27-3
ii  libnetcdf13   1:4.6.1-1
ii  libossp-uuid161.6.2-1.5+b6
ii  libudunits2-0 2.2.26-3
ii  python2.7.14-4
ii  python-numpy [python-numpy-abi9]  1:1.13.3-2

python-cmor recommends no packages.

python-cmor suggests no packages.

-- no debconf information



Bug#894865: ITP: cavestory-nx -- NXEngine is a Cave Story game engine clone

2018-04-04 Thread Carlos Donizete Froes
Package: wnpp
Severity: wishlist
Owner: Carlos Donizete Froes 

* Package name: cavestory-nx
  Version : 1.0.0
  Upstream Author : Carlos Donizete Froes 
* URL : https://github.com/coringao/cavestory-nx
* License : GPL-3+
  Programming Lang: C++
  Description : NXEngine is a Cave Story game engine clone

 A complete clone of the game and rewritten in action/adventure masterpiece
 Cave Story using the NXEngine engine.
 .
 Chances are that the differences of the game are imperceptible or
 too small for most, but worth bearing in mind.
 .
 In this adventure you control a little amnesiac who runs around helping these
 rabbit creatures called Mimigas as he tries to find his way out of
 the giant cave to the floating island that makes up the game setting.



Bug#892147: Please create the Pragha package with complete audio (api) support

2018-04-04 Thread Jürgen Göricke
Hello Gabriel,

> I tested it in my system, which has pulseaudio and this doesn't work 
> either...  

Oh, I'm so surprised! Because the error message suggests otherwise.

> So, I'm guessing that this is not a problem specific to alsa.  

This could be assumed, at least for the time being, if we look at the facts to 
date.

> I don't know how to solve that, yet, but I'll investigate.  

Maybe it makes sense to contact the Pragha project (upstream) directly and 
report the problem there? This might help to find and fix the bug faster and 
provide all distributions with a bugfix release.

> Thanks for the additional information! :)  

You're welcome! We are all interested in solving this problem and to be able to 
offer all community members (almost) error-free software.

> Just to confirm, have you tried to play an audio file (a .ogg file, for 
> instance)?
> Did it work?  (I'm asking to be sure that the problem is only when playing 
> from online radios).

Yes, I tried playing local audio files.
Both ogg and mp3 files can be played without problems!


pgpqGHO9akgxF.pgp
Description: Digitale Signatur von OpenPGP


Bug#894864: ITP: tweeny -- modern C++ tweening library

2018-04-04 Thread Hubert Chathi
Package: wnpp
Owner: Hubert Chathi 
Severity: wishlist

* Package name: tweeny
  Version : 2+git20171120.b94ce07
  Upstream Author : Leonardo G. Lucena de Freitas and Guilherme R. Costa
* URL or Web page : https://github.com/mobius3/tweeny
* License : MIT (expat)
  Description : modern C++ tweening library

Tweeny is an inbetweening library designed for the creation of complex
animations for games and other beautiful interactive software. It
leverages features of modern C++ to empower developers with an intuitive
API for declaring tweenings of any type of value, as long as they
support arithmetic operations.

The goal of Tweeny is to provide means to create fluid interpolations
when animating position, scale, rotation, frames or other values of
screen objects, by setting their values as the tween starting point and
then, after each tween step, plugging back the result.



Bug#894863: RFS: highwayhash/0~20180209-g14dedec-3

2018-04-04 Thread Lumin
Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: highwayhash
   Version : 0~20180209-g14dedec-3
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : science

  It builds those binary packages:

libhighwayhash-dev - Fast strong hash functions:
SipHash/HighwayHash (development)
 libhighwayhash0 - Fast strong hash functions: SipHash/HighwayHash (library)

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/h/highwayhash/highwayhash_0~20180209-g14dedec-3.dsc

  More information about hello can be obtained from https://www.example.com.

http://debomatic-amd64.debian.net/distribution#unstable/highwayhash/0~20180209-g14dedec-3/buildlog

  Changes since the last upload:

highwayhash (0~20180209-g14dedec-3) unstable; urgency=medium

  * Set Ccience team as the maintainer
+ Put myself to Uploaders.
  * Move the packaging repo to salsa science team's namespace
+ Update Vcs-* links in control.
  * Add gcc to autopkgtest depends to fix CI test failure.
  * Collect symbol updates for x32 from buildd.


-- 
Best,



Bug#894862: dh-golang: DH_GOPKG is empty in debian/rules, while documentation states that it's automatically set

2018-04-04 Thread Arnaud Rebillout
Package: dh-golang
Version: 1.34
Severity: normal

Dear Maintainer,

According to `man dh-golang`:

  "DH_GOPKG" (string) contains the Go package name which this Debian
  package is building.

  "DH_GOPKG" is automatically set to the value of the first import path
  of the "XS-Go-Import-Path" "debian/control" field, which can contain
  several comma-separated import paths.

However, I tried to use this variable in the debian/rules file, in
targets such as `override_dh_auto_test` and `override_dh_auto_build`,
and this variable is empty.

I added some debug to dh-golang, and I clearly see the code from
`_set_dh_gopkg` being executed, and the variable is set there. So it
looks like the environment in `debian/rules` is unrelated to the
environment that is set by dh-golang.

If it's expected, then maybe the man page needs a little rewording. If
it's not expected, then it's a bug?

Regards,

  Arnaud

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

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

Versions of packages dh-golang depends on:
ii  debhelper 11.1.5
ii  dpkg  1.19.0.5
ii  libdpkg-perl  1.19.0.5
ii  perl  5.26.1-5

dh-golang recommends no packages.

dh-golang suggests no packages.

-- no debconf information



Bug#894861: openalpr: Segmentation fault reading particular image

2018-04-04 Thread John Scott
Package: openalpr
Version: 2.3.0-1+b4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

When reading a particular image, I've been able to
reproduce a segmentation fault. I had been searching
for images to test OpenALPR with, so I searched for
an image [1] and ran 'alpr maxresdefault.jpg'. Other
images I tested with work fine.

I've included a backtrace I made on Buster.

[1] https://i.ytimg.com/vi/2bhhILfgWQs/maxresdefault.jpg

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

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

Versions of packages openalpr depends on:
ii  libc62.27-3
ii  libgcc1  1:8-20180321-1
ii  liblept5 1.75.3-3
ii  libopenalpr2 2.3.0-1+b4
ii  libopencv-calib3d3.2 3.2.0+dfsg-4+b4
ii  libopencv-contrib3.2 3.2.0+dfsg-4+b4
ii  libopencv-core3.23.2.0+dfsg-4+b4
ii  libopencv-features2d3.2  3.2.0+dfsg-4+b4
ii  libopencv-flann3.2   3.2.0+dfsg-4+b4
ii  libopencv-highgui3.2 3.2.0+dfsg-4+b4
ii  libopencv-imgcodecs3.2   3.2.0+dfsg-4+b4
ii  libopencv-imgproc3.2 3.2.0+dfsg-4+b4
ii  libopencv-ml3.2  3.2.0+dfsg-4+b4
ii  libopencv-objdetect3.2   3.2.0+dfsg-4+b4
ii  libopencv-photo3.2   3.2.0+dfsg-4+b4
ii  libopencv-shape3.2   3.2.0+dfsg-4+b4
ii  libopencv-stitching3.2   3.2.0+dfsg-4+b4
ii  libopencv-superres3.23.2.0+dfsg-4+b4
ii  libopencv-video3.2   3.2.0+dfsg-4+b4
ii  libopencv-videoio3.2 3.2.0+dfsg-4+b4
ii  libopencv-videostab3.2   3.2.0+dfsg-4+b4
ii  libopencv-viz3.2 3.2.0+dfsg-4+b4
ii  libstdc++6   8-20180321-1
ii  libtesseract44.00~git2219-40f43111-1.2

openalpr recommends no packages.

openalpr suggests no packages.

- -- no debconf information

*** /home/john/alpr/bt.txt
#0  0x73820f88 in 
tesseract::LTRResultIterator::WordFontAttributes(bool*, bool*, bool*, bool*, 
bool*, bool*, int*, int*) const (this=this@entry=0x56009e40, 
is_bold=is_bold@entry=0x7fffbfb7, is_italic=is_italic@entry=0x7fffbfb7, 
is_underlined=is_underlined@entry=0x7fffbfb7, 
is_monospace=is_monospace@entry=0x7fffbfb7, 
is_serif=is_serif@entry=0x7fffbfb7, is_smallcaps=0x7fffbfb7, 
pointsize=0x7fffbfbc, font_id=0x7fffbfb8) at ltrresultiterator.cpp:172
#1  0x77b126d3 in alpr::TesseractOcr::recognize_line(int, 
alpr::PipelineData*) (this=0x55f329c0, line_idx=0, 
pipeline_data=0x7fffc640) at ./src/openalpr/ocr/tesseract_ocr.cpp:91
#2  0x77b137e0 in alpr::OCR::performOCR(alpr::PipelineData*) 
(this=this@entry=0x55f329c0, 
pipeline_data=pipeline_data@entry=0x7fffc640) at 
./src/openalpr/ocr/ocr.cpp:48
#3  0x77ae7d43 in alpr::AlprImpl::analyzeSingleCountry(cv::Mat, 
cv::Mat, std::vector >) 
(this=this@entry=0x55d12440, colorImg=..., grayImg=..., 
warpedRegionsOfInterest=std::vector of length 1, capacity 1 = {...}) at 
./src/openalpr/alpr_impl.cpp:316
#4  0x77aea0cd in alpr::AlprImpl::recognizeFullDetails(cv::Mat, 
std::vector >) 
(this=this@entry=0x55d12440, img=..., regionsOfInterest=std::vector of 
length 1, capacity 1 = {...})
at ./src/openalpr/alpr_impl.cpp:143
#5  0x77aeccc5 in alpr::AlprImpl::recognize(cv::Mat, 
std::vector >) 
(this=this@entry=0x55d12440, img=..., regionsOfInterest=std::vector of 
length 1, capacity 1 = {...})
at ./src/openalpr/alpr_impl.cpp:478
#6  0x77aed544 in alpr::AlprImpl::recognize(unsigned char*, int, int, 
int, std::vector) (this=this@entry=0x55d12440, 
pixelData=pixelData@entry=0x7fffbf571020 
"J>\026J>\026J>\026K?\027M>\027M>\027P?\030P?\030Q@\031Q@\031S@\032S@\032VA\033VA\033WB\034UB\034UB\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034TC\034UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035UD\035R@\033R@\033RA\032Q@\031QA\027QA\026QA\026QC\023SE\024RF\020QE\017QF\rPE\vQF\fQG\vSH\nRE\aTE\006TE"...,
 bytesPerPixel=bytesPerPixel@entry=3, imgWidth=, 
imgHeight=, regionsOfInterest=std::vector of length 1, capacity 
1 = {...}) at ./src/openalpr/alpr_impl.cpp:458
#7  0x77ae0d20 in alpr::Alpr::recognize(unsigned char*, int, int, int, 
std::vector) (this=, 
pixelData=0x7fffbf571020 

Bug#894816: [mikutter] mikutter doesn't start with error

2018-04-04 Thread dai
Control: forwarded -1 https://dev.mikutter.hachune.net/issues/1199
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#894828: apt-get -s install lxde-core don't install lxterminal in newly base system ?

2018-04-04 Thread xvapiew asdfoq
Package: apt
Version: 1.6~beta1
Severity: normal
X-Debbugs-CC: aga...@siduction.org

I'm sure all 'x-terminal-emulator' is non-installed due I do this immediately 
after base system installed.
That meaning I use debootstrap+chroot do these things,so I 99% sure no one 
terminal is installed.(except some terminal marked as 'core' ,and so on)



Bug#894816: [mikutter] mikutter doesn't start with error

2018-04-04 Thread dai
Control: reassign -1 ruby-gtk2 3.2.3-1
Control: severity -1 grave
Control: affects -1 mikutter
Control: retitle -1 [ruby-gtk2] mikutter doesn't start with error

confirmed. please use ruby-gtk2 3.2.1-5+b2 (and other dep libs) for now.

On Wed, Apr 04, 2018 at 09:58:34PM +0900, Hideo Oshima wrote:
> mikutter doesn't start.
> 
> Followings are console message.
> 
> $ mikutter 
> Traceback (most recent call last):
>   54: from /usr/share/mikutter/mikutter.rb:42:in `'
>   53: from /usr/share/mikutter/core/miquire.rb:18:in `miquire'
>   52: from /usr/share/mikutter/core/miquire.rb:75:in `miquire'
>   51: from /usr/share/mikutter/core/miquire.rb:75:in `each'
>   50: from /usr/share/mikutter/core/miquire.rb:76:in `block in miquire'
>   49: from /usr/share/mikutter/core/miquire.rb:95:in 
> `file_or_directory_require'
>   48: from /usr/share/mikutter/core/miquire.rb:98:in 
> `miquire_original_require'
>   47: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
> `require'
>   46: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
> `require'
>   45: from /usr/share/mikutter/core/boot/load_plugin.rb:10:in ` (required)>'
>   44: from /usr/share/mikutter/core/miquire_plugin.rb:96:in `load_all'
>   43: from /usr/share/mikutter/core/miquire_plugin.rb:36:in `each_spec'
>   42: from /usr/share/mikutter/core/miquire_plugin.rb:33:in `each'
>   41: from /usr/share/mikutter/core/miquire_plugin.rb:33:in `each'
>   40: from /usr/share/mikutter/core/miquire_plugin.rb:38:in `block in 
> each_spec'
>   39: from /usr/share/mikutter/core/miquire_plugin.rb:98:in `block in 
> load_all'
>   38: from /usr/share/mikutter/core/miquire_plugin.rb:146:in `load'
>   37: from /usr/share/mikutter/core/utils.rb:278:in `atomic'
>   36: from /usr/lib/ruby/2.5.0/monitor.rb:226:in `mon_synchronize'
>   35: from /usr/share/mikutter/core/utils.rb:278:in `block in atomic'
>   34: from /usr/share/mikutter/core/miquire_plugin.rb:147:in `block in 
> load'
>   33: from /usr/share/mikutter/core/miquire_plugin.rb:147:in `each'
>   32: from /usr/share/mikutter/core/miquire_plugin.rb:149:in `block (2 
> levels) in load'
>   31: from /usr/share/mikutter/core/miquire_plugin.rb:146:in `load'
>   30: from /usr/share/mikutter/core/utils.rb:278:in `atomic'
>   29: from /usr/lib/ruby/2.5.0/monitor.rb:226:in `mon_synchronize'
>   28: from /usr/share/mikutter/core/utils.rb:278:in `block in atomic'
>   27: from /usr/share/mikutter/core/miquire_plugin.rb:147:in `block in 
> load'
>   26: from /usr/share/mikutter/core/miquire_plugin.rb:147:in `each'
>   25: from /usr/share/mikutter/core/miquire_plugin.rb:149:in `block (2 
> levels) in load'
>   24: from /usr/share/mikutter/core/miquire_plugin.rb:146:in `load'
>   23: from /usr/share/mikutter/core/utils.rb:278:in `atomic'
>   22: from /usr/lib/ruby/2.5.0/monitor.rb:226:in `mon_synchronize'
>   21: from /usr/share/mikutter/core/utils.rb:278:in `block in atomic'
>   20: from /usr/share/mikutter/core/miquire_plugin.rb:158:in `block in 
> load'
>   19: from /usr/share/mikutter/core/miquire_plugin.rb:158:in `load'
>   18: from /usr/share/mikutter/core/plugin/gtk/gtk.rb:7:in ` (required)>'
>   17: from /usr/share/mikutter/core/miquire.rb:18:in `miquire'
>   16: from /usr/share/mikutter/core/miquire.rb:75:in `miquire'
>   15: from /usr/share/mikutter/core/miquire.rb:75:in `each'
>   14: from /usr/share/mikutter/core/miquire.rb:76:in `block in miquire'
>   13: from /usr/share/mikutter/core/miquire.rb:95:in 
> `file_or_directory_require'
>   12: from /usr/share/mikutter/core/miquire.rb:98:in 
> `miquire_original_require'
>   11: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
> `require'
>   10: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
> `require'
>9: from 
> /usr/share/mikutter/core/mui/cairo_cell_renderer_message.rb:3:in ` (required)>'
>8: from /usr/share/mikutter/core/miquire.rb:18:in `miquire'
>7: from /usr/share/mikutter/core/miquire.rb:75:in `miquire'
>6: from /usr/share/mikutter/core/miquire.rb:75:in `each'
>5: from /usr/share/mikutter/core/miquire.rb:76:in `block in miquire'
>4: from /usr/share/mikutter/core/miquire.rb:95:in 
> `file_or_directory_require'
>3: from /usr/share/mikutter/core/miquire.rb:98:in 
> `miquire_original_require'
>2: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
> `require'
>1: from /usr/lib/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in 
> `require'
> /usr/share/mikutter/core/mui/cairo_miracle_painter.rb:21:in ` (required)>': uninitialized constant Gtk::Object (NameError)
> Did you mean?  Object
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature


Bug#894664: cups: Libreoffice doesn't see my network printer

2018-04-04 Thread Stefan Monnier
> Thank you for thinking to send the log.  There are three devices with IP
> addresses which cannot be found.  Are they all printers?

Only the HP-8100 is a real printer.  The other two are advertised by
some laptop which happened to be connected.

> Does Evince show them all?

Yes.

> Please do
>
>   avahi-browse -art > log
>
> and post log. avahi-browse is in the avahi-utils package.

Here it is (the laptop was absent this time).


Stefan
+  wlan0 IPv6 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
+  wlan0 IPv4 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
+   eth0 IPv6 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
+   eth0 IPv4 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
+  wlan0 IPv6 CUPS @ server Web Site
 local
+  wlan0 IPv4 CUPS @ server Web Site
 local
+   eth0 IPv6 CUPS @ server Web Site
 local
+   eth0 IPv4 CUPS @ server Web Site
 local
+  wlan0 IPv6 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
+  wlan0 IPv4 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
+   eth0 IPv6 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
+   eth0 IPv4 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
+  wlan0 IPv6 HP OfficeJet Pro 8100 @ server_ipps._tcp  
 local
+  wlan0 IPv4 HP OfficeJet Pro 8100 @ server_ipps._tcp  
 local
+   eth0 IPv6 HP OfficeJet Pro 8100 @ server_ipps._tcp  
 local
+   eth0 IPv4 HP OfficeJet Pro 8100 @ server_ipps._tcp  
 local
=  wlan0 IPv6 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [0]
   txt = []
=  wlan0 IPv4 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [0]
   txt = []
=   eth0 IPv6 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [0]
   txt = []
=   eth0 IPv4 HP OfficeJet Pro 8100 @ serverUNIX Printer
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [0]
   txt = []
=  wlan0 IPv6 CUPS @ server Web Site
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [631]
   txt = []
=  wlan0 IPv4 CUPS @ server Web Site
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [631]
   txt = []
=   eth0 IPv6 CUPS @ server Web Site
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [631]
   txt = []
=   eth0 IPv4 CUPS @ server Web Site
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [631]
   txt = []
=  wlan0 IPv6 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [631]
   txt = ["printer-type=0x901E" "printer-state=3" "Duplex=T" "Color=T" 
"TLS=1.2" "UUID=8a590a22-8022-31c0-7155-5d1c1f5bb656" "URF=DM3" 
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
 "product=(HP Officejet Pro 8100 eprinter-n811a)" "priority=0" "note=Salon" 
"adminurl=https://server.local:631/printers/Salon-HP-8100; "ty=HP Officejet Pro 
8100, hpcups 3.16.11" "rp=printers/Salon-HP-8100" "qtotal=1" "txtvers=1"]
=  wlan0 IPv4 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
   hostname = [server.local]
   address = [192.168.1.2]
   port = [631]
   txt = ["printer-type=0x901E" "printer-state=3" "Duplex=T" "Color=T" 
"TLS=1.2" "UUID=8a590a22-8022-31c0-7155-5d1c1f5bb656" "URF=DM3" 
"pdl=application/octet-stream,application/pdf,application/postscript,image/jpeg,image/png,image/pwg-raster,image/urf"
 "product=(HP Officejet Pro 8100 eprinter-n811a)" "priority=0" "note=Salon" 
"adminurl=https://server.local:631/printers/Salon-HP-8100; "ty=HP Officejet Pro 
8100, hpcups 3.16.11" "rp=printers/Salon-HP-8100" "qtotal=1" "txtvers=1"]
=   eth0 IPv6 HP OfficeJet Pro 8100 @ serverInternet Printer
 local
   hostname = [server.local]
   address = [fd84:6537:edcf:0:216:ff:fe03:18c4]
   port = [631]
   txt = ["printer-type=0x901E" "printer-state=3" "Duplex=T" "Color=T" 
"TLS=1.2" "UUID=8a590a22-8022-31c0-7155-5d1c1f5bb656" "URF=DM3" 

Bug#894860: pdftk: New "upstream" (java-only) version available

2018-04-04 Thread Rogério Brito
Package: pdftk
Version: 2.02-4+b2
Severity: wishlist

Hi.

There is a new, java-only version/conversion of pdftk at
https://gitlab.com/marcvinyals/pdftk

This would deal with a lot of problems and FTBFS bugs regarding the removal
of gcj...

Please, package this new version as it would be very hard to live without
pdftk on future versions of Debian.


Thanks,

Rogério.

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

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

Versions of packages pdftk depends on:
ii  libc6   2.27-3
ii  libgcc1 1:8-20180321-1
ii  libgcj176.4.0-12
ii  libstdc++6  8-20180321-1

pdftk recommends no packages.

Versions of packages pdftk suggests:
ii  poppler-utils [xpdf-utils]  0.62.0-2

-- no debconf information

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



Bug#885029: xrdp: thinclient_drives not umounted after session terminated

2018-04-04 Thread Thorsten Glaser
>Dominik George dixit:
>
>>please test whether this is still reprodusible with a recent version
>>from sid.
>
>Yes, it still happens.

I just had it happen again.

d?  ? ?  ?  ?? thinclient_drives/

The session is closing properly, not crashing:

Apr  5 00:45:15 leee xrdp-sesman[16887]: (16887)(-1214032384)[CORE ] window 
manager (pid 16888) did exit, cleaning up session
Apr  5 00:45:16 leee xrdp-sesman[16887]: (16887)(-1214032384)[INFO ] calling 
auth_stop_session and auth_end from pid 16887
Apr  5 00:45:16 leee xrdp-sesman[16887]: pam_unix(xrdp-sesman:session): session 
closed for user tg
Apr  5 00:45:16 leee xrdp-sesman[16887]: (16887)(-1214032384)[DEBUG] 
cleanup_sockets:
Apr  5 00:45:16 leee xrdp-sesman[16887]: (16887)(-1214032384)[DEBUG] 
cleanup_sockets: deleting /var/run/xrdp/sockdir/xrdpapi_10
Apr  5 00:45:17 leee xrdp[16885]: (16885)(-1215062400)[DEBUG] Closed socket 18 
(AF_UNIX)
Apr  5 00:45:17 leee xrdp-sesman[6614]: (6614)(-1214032384)[INFO ] ++ 
terminated session:  username tg, display :10.0, session_pid 16887, ip 
2001:xxx::xxx:xxx::::46547 - socket: 12
Apr  5 00:45:17 leee xrdp[16885]: (16885)(-1215062400)[DEBUG] Closed socket 12 
(AF_INET6 2001:xxx::xxx:::: port 3389)
Apr  5 00:45:18 leee xrdp[16885]: (16885)(-1215062400)[DEBUG] 
xrdp_mm_module_cleanup
Apr  5 00:45:18 leee xrdp[16885]: (16885)(-1215062400)[DEBUG] Closed socket 17 
(AF_UNIX)

Yet, it is still mounted:

xrdp-chansrv on /home/tg/thinclient_drives type fuse.xrdp-chansrv 
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Versions of packages involved:

ii  xorgxrdp   0.9.5-2  i386 Remote Desktop 
Protocol (RDP) modules for X.org
ii  xrdp   0.9.6-1  i386 Remote Desktop 
Protocol (RDP) server
un  xrdp-pulseaudio-instal   (no description 
available)

bye,
//mirabilos
-- 
21:12⎜ sogar bei opensolaris haben die von der community so
ziemlich jeden mist eingebaut │ man sollte unices nich so machen das
desktopuser zuviel intresse kriegen │ das macht die code base kaputt
21:13⎜ linux war früher auch mal besser :D



Bug#459427: changelog vs. NEWS handling

2018-04-04 Thread Sean Whitton
Hello,

On Wed, Apr 04 2018, Adrian Bunk wrote:

> This ensures that policy will always be horribly outdated.

Policy is meant to lag behind practice.  One of the reasons for this is
that it ensures that no-one feels they have to update Policy before
innovating.

The extent to which it lags is a function of how many people are willing
to produce patches to the text of Policy (if you look at our bug lists,
this is the main area in which we are lacking manpower).

>> This is the standard way to make changes to Policy. The alternative is
>> releases of Policy rendering many packages buggy, and that is undesirable.
>>...
>
> A new debhelper compat level making packages buggy according to policy
> is what is desirable?

Yes.  It's okay for packages to break Policy that is thought to be
outdated, when the break that they introduce is an attempt to move
forward.  It's not okay for Policy to change first, except in those
exceptional cases where the only way to make sense of the change is to
change Policy first.

> Let me repeat what I already wrote earlier in this bug:
>
> IMHO the way forward is to find a consensus text for a policy change,
> Cc debian-devel on the proposal, and if no objections are raised release
> a new policy with these changes.

I would like to suggest that you do exactly that, but insert the
debhelper change before your final step of releasing Policy.

> The Policy Editors are a delegation, and the debhelper maintainer is
> just a random person who happens to maintain this specific package.

I don't see how that's relevant.

> Precedent is also that the Policy Editors do use their powers to
> push through even a change that makes thousands of packages buggy
> after an objection has been raised:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431#334

Thank you for bringing up that example.

We would not have made that change had, say, less than 70% of the
archive already been reproducible.  Right now, without an implementation
in debhelper, this change would be making far, far more of the archive
buggy, and it would stay buggy for longer.

Further, we do not have a consensus on this bug in the way that we did
in the case of reproducible builds.

> I begin to wonder whether I should take this personally.

You absolutely should not.  As I said, I'm grateful for your interest in
working on this.  Moreover, I want to see this bug closed as much as you
do.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#892229: wireless-regdb: incompatible with Linux kernel 4.15

2018-04-04 Thread Jape Person
In addition to these findings, has anyone noticed this having an
adverse effect on file transfers? I suspect what I have seen is
due to my particular wireless hardware. (I didn't experiment
with Ethernet connections.)

I used

# sysctl net.ipv4.tcp_congestion_control=cubic

to switch tcp_congestion_control from bbr to cubic. This improve
file transfer speeds between my Debian testing system by roughly
100X on my LAN.

Just posting a note to indicate that -- at least for some people
-- this is a pretty serious bug.

Thanks,
JP



Bug#894338: nvidia-graphics-drivers: CVE-2018-6249, CVE-2018-6253: null pointer dereference and infinite recursion due to malformed shader

2018-04-04 Thread Luca Boccassi
On Wed, 2018-04-04 at 00:25 +0200, Andreas Beckmann wrote:
> On 2018-03-30 16:20, Luca Boccassi wrote:
> > It's due to the updated glx-alternative-foo sets the libGL.so.1
> > symlink
> > to Mesa, even when update-glx --glx nvidia is used:
> > 
> > lrwxrwxrwx 1 root root 48 Mar 30 15:02 /etc/alternatives/glx
> > --libGL.so.1-i386-linux-gnu -> /usr/lib/mesa-diverted/i386-linux-
> > gnu/libGL.so.1
> > lrwxrwxrwx 1 root root 50 Mar 30 15:02 /etc/alternatives/glx
> > --libGL.so.1-x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-
> > linux-gnu/libGL.so.1
> 
> Is this with the libglvnd libgl1 from stretch-backports installed?
> Then
> this is intentional.
> If backports breaks after updating stable, let's fix backports, not
> stable,
> 
> > I guess that was done for glvnd? But this happens with the stretch-
> > backports version too, is that right?
> 
> I'm not sure what the problem is here exactly ...  and how to
> reproduce
> it in a minimal stretch chroot ...
> 
> > Changing those symlinks manually to the nvidia version fixes the
> > problem.
> 
> Pointing to what?

Gah, of course I had libglvnd from bpo. I always, always forget to
remove it when moving back and forth...

Sorry for the noise, works fine after removing those.

Do you need any help with these uploads? Would you like me to create
the tickets for the release team, or do the upload to unstable of 390?

-- 
Kind regards,
Luca Boccassi

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


Bug#894859: Supplement

2018-04-04 Thread Lu Wang
I find ibus-libpinyin also has the bug. The blank is OK, but Shift, Ctrl ... 
shows the same bug. Maybe the bug is belong to ibus. Should I submit a new bug 
report to ibus?



Bug#870645: new relase package when?

2018-04-04 Thread PICCORO McKAY Lenz
what are need for a new package will be uploaded! PLEASE! if coulnd do it,
let others

packages in mentor goes to /dev/null alwaus F*N way


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


Bug#894859: ibus-rime: ibus-rime can not input Chinese after pressing some keys

2018-04-04 Thread Lu Wang
Package: ibus-rime
Version: 1.2-1+b1
Severity: important

Dear Maintainer,

I do not know how the situation happens excepting that I updated my
system with apt last night. Some packages such as ibus-gtk (ibus-gtk3 as well 
?) is
updated. This morning, when I use ibus-rime to compose documents, I find
ibus-rime is totally unusable. I switch to ibus-rime and the first
Chinese character is OK. But if one presses blank, ibus-rime can only
input English Characters. I try ibus-rime in various applications such
as qterminal, LibreOffice and gvim, the same result shows ibus-rime has
a bug. I started gvim in terminal and when I press blank, such a warning shows.

(gvim:2074): IBUS-WARNING **: 07:19:52.457: Process Key Event failed:
GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code18:
The connection is closed.

I also try other keys, such Ctrl, Alt, up, down, left and right, and the
same warning is given.

This bug obvious makes ibus-rime unusable.

By the way, other input methods such as ibus-libpinyin is OK.

Best Regards

Lu Wang


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

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

Versions of packages ibus-rime depends on:
ii  ibus1.5.18-1
ii  libc6   2.27-3
ii  libgdk-pixbuf2.0-0  2.36.11-2
ii  libglib2.0-02.56.0-4
ii  libibus-1.0-5   1.5.18-1
ii  libnotify4  0.7.7-3
ii  librime-data0.35-1
ii  librime11.2.9+dfsg2-1

ibus-rime recommends no packages.

ibus-rime suggests no packages.

-- no debconf information




Bug#873809: Packaging newer upstreams

2018-04-04 Thread PICCORO McKAY Lenz
1.2 bug upstream was resolved and still no package for debian..

https://github.com/Uberi/Minetest-WorldEdit/issues/115

what its need for end the package, i want to backport to wheeze and squeeze
but i dont know what do i care for untill debian defaults this package


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


Bug#894792: man-db: Permission denied running man as root

2018-04-04 Thread Colin Watson
Control: tag -1 fixed-upstream

On Wed, Apr 04, 2018 at 01:22:09PM +0200, Salvo Tomaselli wrote:
> Here it is

Thanks.  I've fixed your bug upstream, for the upcoming man-db 2.8.3:

  
https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=c08cb8aedb7bb647e3f1ac6b9d009c0b174f8ba1

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



Bug#894667: beep bug

2018-04-04 Thread rain1

Hello.

After analysis of the diff it in unclear what exactly the race condition 
bug is and how it would constitute a privileged escalation.


Please could somebody provide an explanation of what the race condition 
is, and how it is a security issue rather than just being a regular bug. 
so we can understand why the patch fixes it.


It seems that open/closing the console_device (set with -e) was done 
repeatedly in the -n case. It's possible that the race in question would 
be triggered if a SIGINT or SIGTERM was sent at the right time (which 
time)? possibly causing a double free. As the beep program just performs 
ioctl or writes a very simple struct to an fd it does not seem there is 
enough attacker control to actually do any sort of code execution with 
beep.


So this may not really be a security issue, just a minor improvement in 
the code. I welcome being corrected though.


(Note: we have looked at the satire website about the bug 
https://holeybeep.ninja and it does not provide any technical details of 
interest)


Cheers!



Bug#894754: vagrant: Invalid gemspec in rbnacl-libsodium stack level too deep

2018-04-04 Thread Nicholas Capo
I'm sorry.
It seems I did have additional gems installed.

After removing all gems, and `ruby*` apt packages (and reinstalling
vagrant), vagrant works again!

When I then did `sudo gem install overcommit` which installed
childprocess-0.9.0 as a dependency, vagrant broke again.

Feel free to close this issue.

Sorry to have bothered you,

Nicholas

P.S. It seems to be an interaction either with having multiple version of
childprocess or maybe just childprocess > 0.5.9.

On Wed, Apr 4, 2018 at 2:23 PM Antonio Terceiro  wrote:

> Control: tag -1 + moreinfo unreproducible
>
> On Tue, Apr 03, 2018 at 04:17:51PM -0500, Nicholas Capo wrote:
> > Package: vagrant
> > Version: 2.0.2+dfsg-3
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > When running any `vagrant` command the following is error appears and the
> > command seems to never complete.
> >
> > ```
> > $ vagrant status
> > Invalid gemspec in
> [/usr/share/rubygems-integration/all/specifications/rbnacl-
> > libsodium.gemspec]: stack level too deep
> > ```
> >
> > At one point I typed Ctrl+C quickly and got this (possibly related) stack
> > trace:
> >
> > ```
> > $ vagrant status
> > Invalid gemspec in
> [/usr/share/rubygems-integration/all/specifications/rbnacl-
> > libsodium.gemspec]: stack level too deep
> > [...]
> > ```
>
> I can't reproduce this on my system, nor in a clean system with only
> vagrant installed.
>
> > I have tried removing `ruby-rbnacl` (which removes `vagrant`) and
> reinstalling,
> > but the issue persists.
> > ```
> > $ sudo apt autoremove --purge ruby-rbnacl
> [...]
> > $ sudo apt install vagrant
> > $ vagrant status
> > Invalid gemspec in
> [/usr/share/rubygems-integration/all/specifications/rbnacl-
> > libsodium.gemspec]: stack level too deep
> > ^C
> > ```
> >
> > I do not beleive I have any gems installed (other than what comes from
> apt),
> > but here is the list just in case:
> >
> > ```
> > sudo gem list
> [...]
> > ```
>
> I need more than that. please share the output of:
>
> find /var/lib/gems
> gem list rbnacl-libsodium
> ruby -e 'gem "rbnacl-libsodium"'
>
> also, do you have vagrant plugins installed from outside of Debian?
>


Bug#867311: Fixed upstream?

2018-04-04 Thread Ben Poliakoff
It appears that this bug has been fixed upstream... is it likely that that
fix will make it to the stretch release? We won't be able to upgrade any of
our end user facing systems to stretch until this is resolved.

Ben


Bug#894766:

2018-04-04 Thread Matti Palmström
> However, why would we make a separate package for a single file which
weights 50 kBytes? Please have a look at the plugins sizes:

Dependencies, qupzilla 2.2.5 works fine without policykit and others but
those seems to be required by libkf5wallet-bin. On my system
libkf5wallet-bin wants to install 40MB of dependencies.

Regard
/M

$ sudo aptitude install -R libkf5wallet-bin
The following NEW packages will be installed:
  libdbusmenu-qt5-2{a} libfam0{a} libkf5archive5{a} libkf5auth-data{a}
libkf5auth5{a}
  libkf5codecs-data{a} libkf5codecs5{a} libkf5config-data{a}
libkf5configcore5{a}
  libkf5configgui5{a} libkf5configwidgets-data{a} libkf5configwidgets5{a}
  libkf5coreaddons-data{a} libkf5coreaddons5{a} libkf5crash5{a}
libkf5dbusaddons-data{a}
  libkf5dbusaddons5{a} libkf5guiaddons5{a} libkf5i18n-data{a}
libkf5i18n5{a}
  libkf5iconthemes-data{a} libkf5iconthemes5{a} libkf5itemviews-data{a}
libkf5itemviews5{a}
  libkf5notifications-data{a} libkf5notifications5{a} libkf5service-bin{a}
  libkf5service-data{a} libkf5service5{a} libkf5wallet-bin
libkf5wallet-data{a}
  libkf5wallet5{a} libkf5widgetsaddons-data{a} libkf5widgetsaddons5{a}
  libkf5windowsystem-data{a} libkf5windowsystem5{a} libkwalletbackend5-5{a}
libpam-systemd{ab}
  libphonon4qt5-4{a} libpolkit-agent-1-0{a} libpolkit-gobject-1-0{a}
libpolkit-qt5-1-1{a}
  libqt5script5{a} phonon4qt5{a} phonon4qt5-backend-vlc{a}
The following packages are RECOMMENDED but will NOT be installed:
  kwayland-integration libkf5config-bin libkf5dbusaddons-bin
libkf5iconthemes-bin qtwayland5
0 packages upgraded, 46 newly installed, 0 to remove and 2 not upgraded.
Need to get 6,413 kB of archives. After unpacking 42.0 MB will be used.


Bug#894857: plasma-discover: Can't use with LXQt (missing dependencies)

2018-04-04 Thread robert
Package: plasma-discover
Version: 5.12.4-1
Severity: important
Tags: upstream

Dear Maintainer,

I want to use plasma-discover with LXQt, but it does not start or does not show
any applications.

So I created this https://bugs.kde.org/show_bug.cgi?id=392737 bug report, and
"Nate Graham" told me that Discover should definitely work with other desktop
environments and I am simply experiencing a Debian packaging issue, and so I
opened this bug report here.

Regards,
Robert



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

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

Versions of packages plasma-discover depends on:
ii  appstream 0.11.8-3
ii  kio   5.44.0-1
ii  libappstreamqt2   0.11.8-3
ii  libc6 2.27-3
ii  libkf5attica5 5.44.0-1
ii  libkf5configcore5 5.44.0-1
ii  libkf5configwidgets5  5.44.0-1
ii  libkf5coreaddons5 5.44.0-1
ii  libkf5crash5  5.44.0-1
ii  libkf5dbusaddons5 5.44.0-1
ii  libkf5declarative55.44.0-1
ii  libkf5i18n5   5.44.0-1
ii  libkf5itemmodels5 5.44.0-1
ii  libkf5kiocore55.44.0-1
ii  libkf5kiowidgets5 5.44.0-1
ii  libkf5newstuffcore5   5.44.0-1
ii  libkf5notifications5  5.44.0-1
ii  libkf5service-bin 5.44.0-1
ii  libkf5service55.44.0-1
ii  libkf5widgetsaddons5  5.44.0-1
ii  libkf5xmlgui5 5.44.0-2
ii  libpackagekitqt5-11.0.1-1
ii  libqt5core5a  5.9.2+dfsg-12
ii  libqt5dbus5   5.9.2+dfsg-12
ii  libqt5gui55.9.2+dfsg-12
ii  libqt5network55.9.2+dfsg-12
ii  libqt5qml55.9.2-3
ii  libqt5quick5  5.9.2-3
ii  libqt5widgets55.9.2+dfsg-12
ii  libqt5xml55.9.2+dfsg-12
ii  libstdc++68-20180321-1
ii  packagekit1.1.9-1
ii  plasma-discover-common5.12.4-1
ii  qml-module-org-kde-kirigami2  5.44.0-2

Versions of packages plasma-discover recommends:
ii  software-properties-kde  0.96.20.2-1

Versions of packages plasma-discover suggests:
pn  plasma-discover-backend-flatpak  

-- no debconf information



Bug#894664: cups: Libreoffice doesn't see my network printer

2018-04-04 Thread Brian Potkin
On Wed 04 Apr 2018 at 17:37:00 -0400, Stefan Monnier wrote:

> > Tentatively, this looks more like a cups-browsed issue.
> >
> > /etc/cups/cups-browsed should have a line "BrowseRemoteProtocols dnssd 
> > cups".
> 
> Yes, I have that.
> 
> > Try uncommenting "LogDir /var/log/cups" and "DebugLogging file" and look
> > at /var/log/cups/cups-browsed_log after restarting cups-browsed. Is the
> > printer in there?
> 
> Yes, I attached the file below.
> I guess the problem is
> 
> Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
> server' of type '_ipps._tcp' in domain 'local' skipped, could not determine 
> IP address.
> 
> but I don't know why.  "host server" on that same machine returns
> "server.lan has address 192.168.1.2".

Thank you for thinking to send the log. There are three devices with IP
addresses which cannot be found. Are they all printers? Does Evince show
them all?

Please do

  avahi-browse -art > log

and post log. avahi-browse is in the avahi-utils package.

Cheers,

Brian.



Bug#894855: bind(): No such file or directory [core/socket.c line 230]

2018-04-04 Thread Purism Sysadmins
Package: mailman3-web
Version: 0+20170523-13~bpo9+1
Severity: important

Dear Maintainer,

When I tried to install mailman3-full I got this:

```
Apr 04 12:36:10 lists systemd[1]: mailman3-web.service: Main process exited, 
code=exited, status=1/FAILURE
Apr 04 12:36:10 lists systemd[1]: Failed to start Mailman3-web uWSGI service.
Apr 04 12:36:10 lists systemd[1]: mailman3-web.service: Unit entered failed 
state.
Apr 04 12:36:10 lists systemd[1]: mailman3-web.service: Failed with result 
'exit-code'.
dpkg: error processing package mailman3-web (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mailman3-full:
 mailman3-full depends on mailman3-web; however:
  Package mailman3-web is not configured yet.

dpkg: error processing package mailman3-full (--configure):
 dependency problems - leaving unconfigured
Processing triggers for libc-bin (2.24-11+deb9u3) ...
Processing triggers for systemd (232-25+deb9u3) ...
Processing triggers for libgdk-pixbuf2.0-0:amd64 (2.36.5-2+deb9u2) ...
Errors were encountered while processing:
 mailman3-web
 mailman3-full
E: Sub-process /usr/bin/dpkg returned an error code (1)
W: Operation was interrupted before it could finish
```

Checking in the logs (/var/log/mailman3/web/mailman-web.log) I got this:

```
*** Starting uWSGI 2.0.14-debian (64bit) on [Wed Apr  4 12:36:10 2018] ***
compiled with version: 6.3.0 20170516 on 17 March 2018 15:41:47
os: Linux-4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)
nodename: announcements
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /
detected binary path: /usr/bin/uwsgi-core
setgid() to 33
setuid() to 33
chdir() to /usr/share/mailman3-web
your processes number limit is 7931
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
bind(): No such file or directory [core/socket.c line 230]
```

My workaround was this:

```
mkdir /run/mailman3/web/
chown www-data:www-data /run/mailman3/web/
```

Regards,

Theodotos Andreou
Purism Sysadmin

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

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

Versions of packages mailman3-web depends on:
ii  dbconfig-sqlite3  2.0.9~bpo9+1
ii  debconf [debconf-2.0] 1.5.61
ii  lsb-base  9.20161125
ii  node-less 1.6.3~dfsg-2
ii  python2.7.13-2
ii  python-django-hyperkitty  1.1.4-4~bpo9+2
ii  python-django-postorius   1.1.2-3~bpo9+2
ii  python-psycopg2   2.6.2-1
ii  python-whoosh 2.7.0-2
ii  ruby-sass 3.4.23-1
ii  ucf   3.0036
ii  uwsgi 2.0.14+20161117-3+deb9u2
ii  uwsgi-plugin-python   2.0.14+20161117-3+deb9u2

Versions of packages mailman3-web recommends:
ii  libapache2-mod-proxy-uwsgi  2.0.14+20161117-3+deb9u2

Versions of packages mailman3-web suggests:
pn  postgresql | default-mysql-server | virtual-mysql-server  

-- debconf information:
  mailman3-web/superuser-password: (password omitted)
  mailman3-web/app-password-confirm: (password omitted)
  mailman3-web/password-confirm: (password omitted)
  mailman3-web/internal/skip-preseed: false
  mailman3-web/purge: false
  mailman3-web/upgrade-error: abort
  mailman3-web/db/dbname: mailman3web.db
  mailman3-web/emailname: localhost.local
  mailman3-web/django-site: lists.example.com
  mailman3-web/install-error: abort
  mailman3-web/superuser-name: admin
  mailman3-web/passwords-do-not-match:
* mailman3-web/database-type: sqlite3
  mailman3-web/superuser-mail: root@localhost
  mailman3-web/dbconfig-remove: true
  mailman3-web/internal/reconfiguring: false
  mailman3-web/configure-webserver: none
  mailman3-web/db/basepath: /var/lib/mailman3/web
* mailman3-web/dbconfig-install: true
  mailman3-web/restart-webserver: true
  mailman3-web/remove-error: abort
  mailman3-web/dbconfig-upgrade: true
  mailman3-web/nginx-choice:
  mailman3-web/missing-db-package-error: abort
  mailman3-web/upgrade-backup: true
  mailman3-web/dbconfig-reinstall: false



Bug#894856: appstream: Incomplete debian/copyright?

2018-04-04 Thread Chris Lamb
Source: appstream
Version: 0.12.0-1
Severity: serious
Justication: Policy 12.5
X-Debbugs-CC: Matthias Klumpp 

Hi,

I just ACCEPTed appstream from NEW but noticed it was missing 
attribution in debian/copyright for at least Jan Grulich, 
Aleix Pol Gonzalez, Lucas Moura, etc.

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


Regards,

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



Bug#894834: lintian: [PATCH] Spelling fixes

2018-04-04 Thread Chris Lamb
tags 894834 + pending
thanks

Thanks! Applied in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=cd31f7cb0954cd64175667e4cfdbecf113d7e5d3


Regards,

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



Bug#894820: lintian: Point testsuite references to salsa.d.o

2018-04-04 Thread Chris Lamb
tags 894820 + pending
thanks

Applied in Git, pending upload. Thanks!

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=7b092a1c931d7c8cbe7859f3ac0a5312850e3ffb


Regards,

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



Bug#894053: zathura: upstream switched to a different issue tracker, please re-forward Debian bug reports

2018-04-04 Thread Francesco Poli
Control: reopen -1


On Sun, 25 Mar 2018 23:40:40 +0200 Francesco Poli wrote:

> However, I cannot find the new locations for the upstream issues
> corresponding to the following Debian bug reports:
> 
> #733949
> #733946
> #733945
> #733944
> 
> Could you please set the new forwarded URLs for the above Debian bug
> reports? 
> 
> Thanks for your helpfulness.

I am reopening the bug report, since the above mentioned reports (along
with other ones) still have the outdated forwarded URLs and I cannot
find the correct upstream issues.

Could you please clarify?
Thanks for your time and patience!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpk762xXx_8a.pgp
Description: PGP signature


Bug#894664: cups: Libreoffice doesn't see my network printer

2018-04-04 Thread Stefan Monnier
> Tentatively, this looks more like a cups-browsed issue.
>
> /etc/cups/cups-browsed should have a line "BrowseRemoteProtocols dnssd cups".

Yes, I have that.

> Try uncommenting "LogDir /var/log/cups" and "DebugLogging file" and look
> at /var/log/cups/cups-browsed_log after restarting cups-browsed. Is the
> printer in there?

Yes, I attached the file below.
I guess the problem is

Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local' skipped, could not determine IP 
address.

but I don't know why.  "host server" on that same machine returns
"server.lan has address 192.168.1.2".


Stefan


Wed Apr  4 17:31:38 2018 cups-browsed: Creating http connection to local CUPS 
daemon: /var/run/cups/cups.sock:631
Wed Apr  4 17:31:38 2018 network interface at 192.168.1.112
Wed Apr  4 17:31:38 2018 network interface at 192.168.1.138
Wed Apr  4 17:31:38 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
IPP-Create-Subscription
Wed Apr  4 17:31:38 2018 cups-browsed [BrowsePoll /var/run/cups/cups.sock:0]: 
subscription ID=1250
Wed Apr  4 17:31:38 2018 cups-browsed (/var/run/cups/cups.sock): cupsGetDests
Wed Apr  4 17:31:38 2018 Could not determine system default printer!
Wed Apr  4 17:31:38 2018 Using signal handler SIGACTION
Wed Apr  4 17:31:38 2018 Avahi server connection got available, setting up 
service browsers.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: CACHE_EXHAUSTED
Wed Apr  4 17:31:38 2018 Avahi Browser: ALL_FOR_NOW
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: NEW: service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'
Wed Apr  4 17:31:38 2018 Avahi Browser: CACHE_EXHAUSTED
Wed Apr  4 17:31:38 2018 Avahi Browser: ALL_FOR_NOW
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipp._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local'.
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' of type '_ipps._tcp' in domain 'local' skipped, could not determine IP 
address.
Wed Apr  4 17:31:38 2018 listening
Wed Apr  4 17:31:38 2018 Avahi Resolver: Service 'HP OfficeJet Pro 8100 @ 
server' 

Bug#894798: RFS: dde-qt-dbus-factory/1.0.1-1~exp1

2018-04-04 Thread Adam Borowski
On Wed, Apr 04, 2018 at 07:10:26PM +0800, Boyuan Yang wrote:
>   I am looking for a sponsor for my package "dde-qt-dbus-factory" into
> experimental.
> 
>  * Package name: dde-qt-dbus-factory
>Version : 1.0.1-1~exp1

>   This upload will initiate a transition for libdframeworkdbus1 ->
> libdframeworkdbus2. All reverse dependencies are inside pkg-deepin
> team thus it will be handled inside the team after we get the
> permission from Release Team later.
> 
>   Changes since the last upload:
> 
> dde-qt-dbus-factory (1.0.1-1~exp1) experimental; urgency=medium

https://ftp-master.debian.org/new/dde-qt-dbus-factory_1.0.1-1~exp1.html

A version by that number already exists in NEW; changed-by: you and signed
with szlin's key, dated 2018-03-18.


喵!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ ... what's the frequency of that 5V DC?
⠈⠳⣄



Bug#894517: rapid-photo-downloader: Thumbnails are no longer created

2018-04-04 Thread Pascal Volk
On 2018-04-01 02:10, Damon Lynch wrote:
> The problem is not in Rapid Photo Downloader. The problem is the
> incompatibility of python3-tornado 5.0 with python3-zmq 16.0.2.
> 
> Tornado 5.0 is very new.
> 

Hi there,

today's update of python3-zmq:amd64 (16.0.2-2+b1 -> 17.0.0-1) has solved
the problem. :-)
Thumbnails are generated again. No more python tracebacks.

I guess this bug report can be closed and marked as solved.


Thanks and Best Regards,
Pascal
-- 
Ubuntu is an ancient African word meaning “I can’t install Debian.”
 -- unknown



signature.asc
Description: OpenPGP digital signature


Bug#892548: dhelp: /usr/sbin/dhelp_parse broken with ruby 2.5

2018-04-04 Thread gregor herrmann
On Wed, 04 Apr 2018 00:48:59 +0300, Коля Гурьев wrote:

> Unfortunately, I can't reproduce this error. However, I've faced the
> other error related to dhelp's cron script. It fails to build a document
> index, and so search doesn't work. But at least the dhelp_parse utility
> can rebuild its documentation directory, and a home page is still
> available. It seems some of the next warnings aren't linked to dhelp.

Indeed, I can confirm that "my" original output is gone, and I now
see what you've copied below.

Cheers,
gregor
 

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


signature.asc
Description: Digital Signature


Bug#894854: ansible: Ansible 2.5.0 fails to gather facts on hosts which don't have dmidecode

2018-04-04 Thread Jeremy Sowden
Package: ansible
Version: 2.5.0+dfsg-1
Severity: important
Tags: patch upstream

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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

Since upgrading Ansible to 2.5.0, it has been failing to gather facts on my
servers which do not have dmidecode installed.  I diffed the 2.4.3 and 2.5.0
versions of ansible/module_utils/facts/virtual/linux.py and found the following
change:

@@ -220,6 +233,17 @@
 virtual_facts['virtualization_role'] = 'guest'
 return virtual_facts

+# In older Linux Kernel versions, /sys filesystem is not available
+# dmidecode is the safest option to parse virtualization related values
+dmi_bin = self.module.get_bin_path('dmidecode')
+(rc, out, err) = self.module.run_command('%s -s system-product-name' % 
dmi_bin)
+if rc == 0:
+# Strip out commented lines (specific dmidecode output)
+vendor_name = ''.join([line.strip() for line in out.splitlines() 
if not line.startswith('#')])
+if vendor_name in ['VMware Virtual Platform', 'VMware7,1']:
+virtual_facts['virtualization_type'] = 'VMware'
+virtual_facts['virtualization_role'] = 'guest'
+

If dmidecode is not installed, dmi_bin is None and the call to
self.module.run_command fails with a fatal error.  Compare this to the running
of dmidecode in ansible/module_utils/facts/hardware/linux.py (ll. 304ff.):

# Fall back to using dmidecode, if available
dmi_bin = self.module.get_bin_path('dmidecode')
DMI_DICT = {
'bios_date': 'bios-release-date',
'bios_version': 'bios-version',
'form_factor': 'chassis-type',
'product_name': 'system-product-name',
'product_serial': 'system-serial-number',
'product_uuid': 'system-uuid',
'product_version': 'system-version',
'system_vendor': 'system-manufacturer'
}
for (k, v) in DMI_DICT.items():
if dmi_bin is not None:
(rc, out, err) = self.module.run_command('%s -s %s' % 
(dmi_bin, v))
if rc == 0:
# Strip out commented lines (specific dmidecode output)
thisvalue = ''.join([line for line in out.splitlines() 
if not line.startswith('#')])
try:
json.dumps(thisvalue)
except UnicodeDecodeError:
thisvalue = "NA"

dmi_facts[k] = thisvalue
else:
dmi_facts[k] = 'NA'
else:
dmi_facts[k] = 'NA'

In this case, the code checks whether dmi_bin is None before attempting to run
it.

I think the new code is also missing a return statement.

I have installed dmidecode on my amd64 hosts, but I have an armel on which
dmidecode is not available.

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

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

Versions of packages ansible depends on:
ii  python2.7.14-4
ii  python-crypto 2.6.1-8
ii  python-cryptography   2.1.4-1
ii  python-httplib2   0.9.2+dfsg-1
ii  python-jinja2 2.10-1
ii  python-netaddr0.7.19-1
ii  python-paramiko   2.4.0-1
ii  python-pkg-resources  39.0.1-1
ii  python-yaml   3.12-1+b1

Versions of packages ansible recommends:
pn  python-jmespath   
pn  python-kerberos   
pn  python-libcloud   
pn  python-selinux
pn  python-winrm  
pn  python-xmltodict  

Versions of packages ansible suggests:
ii  cowsay   3.03+dfsg2-4
pn  sshpass  

-- no debconf information
diff --git a/lib/ansible/module_utils/facts/virtual/linux.py 
b/lib/ansible/module_utils/facts/virtual/linux.py
index a0ad545..7b0b233 100644
--- a/lib/ansible/module_utils/facts/virtual/linux.py
+++ b/lib/ansible/module_utils/facts/virtual/linux.py
@@ -236,13 +236,15 @@ class LinuxVirtual(Virtual):
 # In older Linux Kernel versions, /sys filesystem is not available
 # dmidecode is the safest option to parse virtualization related values
 dmi_bin = self.module.get_bin_path('dmidecode')
-

Bug#892548: dhelp: /usr/sbin/dhelp_parse broken with ruby 2.5

2018-04-04 Thread Коля Гурьев
tags 892548 - unreproducible
reassign 892548 libruby2.5
forcemerge 892099 892548
stop

It appears the bug with very similar issue was fixed in the libruby2.5
package so I merge these bugs. If your error still exists, let us know.



Bug#894853: sopwith: SDL1 version is useless, please use GTK or SDL2

2018-04-04 Thread Adam Borowski
Package: sopwith
Version: 1.8.4-6
Severity: normal

Hi!
Sopwith suffers from SDL1 bugs that make it unplayable on any
monitor-attached machine I currently own:
* destroys xrandr settings (sets all monitors to mirror mode, landscaped, at
  a silly resolution)
* places its display solely on my right _vertical_ monitor, despite that one
  not being set as primary.  It doesn't even use that blasted mirror mode it
  itself forces at exit!
* on my both laptops and phone, sopwith puts its display as a tiny image at
  the center of black screen

SDL1 has been abandoned years ago, and still lives in the world of CRT, when
monitors could be set to an arbitrary resolution, GPUs sucked, and attaching
more than one monitor was a rare case that required non-standard hardware
(two graphics cards, when computers usually had one AGP/whatever slot).

SDL's upstream understandably refuses to fix this, telling people to switch
to SDL2 instead.  This requires some porting, which is more of a task for
upstream rather than you -- but, I see that sopwith has a GTK port; perhaps
that one could work on modern monitors?


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

Kernel: Linux 4.16.0-debug-00034-g57a36aaa2c3f (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sopwith depends on:
ii  libc62.27-3
ii  libsdl1.2debian  1.2.15+dfsg2-0.1

sopwith recommends no packages.

sopwith suggests no packages.

-- no debconf information



Bug#891434: the same on 2 Acer Aspire V13 PC's

2018-04-04 Thread Jean-Marc
On Wed, 07 Mar 2018 11:13:02 -0500 Rann Bar-On  wrote:
> Is this still the case with 2.02+dfsg1-3 or has it been fixed?

Yes, it is.

I experinced the same issue on 2 Acer Aspire V13 PC's.

Updating GRUB to 2.02+dfsg1-2 and to 2.02+dfsg1-3.

Both PC's left unbootable.

Rescued with an install image + re-installing GRUB with the option --removable.

I saved the logs if you are interested.

Regards,

Jean-Marc 


pgpy3OdO2EOsf.pgp
Description: PGP signature


Bug#894462: paraview: edges are blotted [regression]

2018-04-04 Thread Anton Gladky
Hi Francesco,

2018-04-02 17:31 GMT+02:00 Francesco Poli :
...
> I noticed that you removed yourself from the uploader list, but I was
> hoping someone else from the Debian Science Team was going to step in
> soon... Is this not the case?  :-(
...

Well, I hope also.

>> I am not using it any more
>
> Because you no longer have the need to perform data visualizations?
> Or because you now use some other similar package?
> I am not aware of any other comparable package in Debian, but maybe you
> are: that's why I am asking...

Please see here [1].

[1] https://lists.debian.org/debian-science/2017/10/msg00078.html

>> If you really want it to be fixed (as well as export to AVI), feel free
>> to join our team and provide some patches.
>
> This is difficult, I lack the time and I don't know how long will it
> take to get the expertise required to maintain such a package...

Debian Science Team members are usually very helpful if somebody
is trying to solve technical questions.

>> Otherwise paraview is the good
>> candidate to be dropped from the next release.
>
> Assuming this is not an April Fool's Day prank, I am very worried by
> this danger. I really hope this won't happen!

Some packages can live many years without maintainer.
But ParaView is too large and complex to use this opportunity.
If RC-bugs will not be resolved on time - any package is being
removed from the testing, and later - does not go to release.

Best regards

Anton



Bug#894851: ITP: libstatistics-contingency-perl -- module to calculate precision, recall, F1, accuracy, etc.

2018-04-04 Thread Laurent Baillet
Package: wnpp
Severity: wishlist
Owner: Laurent Baillet 

* Package name: libstatistics-contingency-perl
  Version : 0.0.9
  Upstream Author : Ken Williams 
* URL : 
http://search.cpan.org/~kwilliams/Statistics-Contingency-0.09/lib/Statistics/Contingency.pm
* License : GPL-1+ or Artistic
  Programming Lang: Perl
  Description : module to calculate precision, recall, F1, accuracy, etc.

this module permits to calculate statistical measures based on contingency 
tables. they can be used to judge the quality of automatic categorization.

this module is a dependency for perl module AI::Categorizer that I plan to 
package



Bug#894850: cinnamon: Network applet can't activate new networks

2018-04-04 Thread Tollef Fog Heen
Package: cinnamon
Version: 3.6.7-5
Severity: important

When trying to connect to a new wireless network, I'm getting in the jouranl:

JS ERROR: Exception in callback for signal: activate: TypeError: 
NM.Client.Permission is undefined
   
default_to_private_connections@/usr/share/cinnamon/applets/netw...@cinnamon.org/applet.js:77
   
NMDeviceWireless.prototype._createAutomaticConnection@/usr/share/cinnamon/applets/netw...@cinnamon.org/applet.js:1543
   
NMDeviceWireless.prototype._createNetworkItem/<@/usr/share/cinnamon/applets/netw...@cinnamon.org/applet.js:1588
   
_emit@resource:///org/gnome/gjs/modules/signals.js:140
   
PopupBaseMenuItem.prototype.activate@/usr/share/cinnamon/js/ui/popupMenu.js:178
   
PopupBaseMenuItem.prototype._onButtonReleaseEvent@/usr/share/cinnamon/js/ui/popupMenu.js:151

Happy to provide any sort of debugging information.

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

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

Versions of packages cinnamon depends on:
ii  cinnamon-common  3.6.7-5
ii  cinnamon-control-center  3.6.5-1
ii  cinnamon-desktop-data3.6.2-2
ii  cinnamon-screensaver 3.6.1-2
ii  cinnamon-session 3.6.1-1
ii  cinnamon-settings-daemon 3.6.2-1
ii  cjs  3.2.0-3
ii  cups-pk-helper   0.2.6-1+b1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-caribou-1.0   0.4.21-5
ii  gir1.2-clutter-1.0   1.26.2+dfsg-4
ii  gir1.2-cmenu-3.0 3.6.0-1
ii  gir1.2-cogl-1.0  1.22.2-3
ii  gir1.2-cvc-1.0   3.6.2-2
ii  gir1.2-gdkpixbuf-2.0 2.36.11-2
ii  gir1.2-gkbd-3.0  3.26.0-3
ii  gir1.2-glib-2.0  1.56.0-2
ii  gir1.2-gnomedesktop-3.0  3.28.0-1
ii  gir1.2-gtk-3.0   3.22.29-2
ii  gir1.2-gtkclutter-1.01.8.4-3
ii  gir1.2-keybinder-3.0 0.3.2-1
ii  gir1.2-meta-muffin-0.0   3.6.0-1
ii  gir1.2-nm-1.01.10.6-2
ii  gir1.2-nma-1.0   1.8.10-2
ii  gir1.2-notify-0.70.7.7-3
ii  gir1.2-pango-1.0 1.42.0-1
ii  gir1.2-polkit-1.00.105-20
ii  gir1.2-soup-2.4  2.62.0-1
ii  gir1.2-upowerglib-1.00.99.7-2
ii  gir1.2-xapp-1.0  1.0.4-2
ii  gkbd-capplet 3.26.0-3
ii  gnome-backgrounds3.28.0-1
ii  gnome-themes-standard3.22.3-4
ii  gsettings-desktop-schemas3.28.0-1
ii  iso-flags-png-320x2401.0.1-1
ii  libatk-bridge2.0-0   2.26.2-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo21.15.10-1
ii  libcinnamon-menu-3-0 3.6.0-1
ii  libcjs0  3.2.0-3
ii  libclutter-1.0-0 1.26.2+dfsg-4
ii  libcogl-pango20  1.22.2-3
ii  libcogl-path20   1.22.2-3
ii  libcogl201.22.2-3
ii  libcroco30.6.12-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgirepository-1.0-11.56.0-2
ii  libgl1   1.0.0-2
ii  libglib2.0-0 2.56.0-4
ii  libglib2.0-bin   2.56.0-4
ii  libgstreamer1.0-01.14.0-1
ii  libgtk-3-0   3.22.29-2
ii  libmuffin0   3.6.0-1
ii  libpango-1.0-0   1.42.0-1
ii  libpangocairo-1.0-0  1.42.0-1
ii  libstartup-notification0 0.12-5
ii  libx11-6 2:1.6.5-1
ii  

Bug#894849: debian-installer: support dove cubox

2018-04-04 Thread Josua Mayer
Package: debian-installer
Severity: wishlist
Tags: d-i

Dear Maintainer,

Lets figure out how install media can be created that works with the original 
Dove Cubox.
Bug#876773 has added support for this device to flash-kernel;
Bug#876774 is about adding support to linux-image-armmp.

The goal of this bug is generating a debian-installer image for use with block 
storage such as 
sata, usb or microsd that will actually boot by itself.
Ideally with at least some packages for doing an offline installation.

So this is the boot process we are working with:
preinstalled U-boot on SPI Flash looks for boot.scr on usb -> mmc -> sata, 
first in /boot, then /.
This U-Boot is very old and needs u-boot wrapped uImage with appended DTB, and 
uInitrd.

For reference, this is the boot-script in flash-kernel:
https://anonscm.debian.org/git/d-i/flash-kernel.git/commit/?id=7d9106b7a89df0b697d048e03a3f94f167e2e0d0
It is usable for booting d-i as is, however I am a little unsure about the 
substitutions
@@LINUX_KERNEL_CMDLINE_DEFAULTS@@
@@LINUX_KERNEL_CMDLINE@@
@@UBOOT_ENV_EXTRA@@

So we need:
boot.scr
uImage
uInitrd

These can manually be created by issueing
cat vmlinuz dtbs/dove-cubox.dtb > vmlinuz-dtb
mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 -d 
vmlinuz-dtb uImage
mkimage -A arm -O linux -T ramdisk -C none -a 0 -e 0 -d initrd.gz uInitrd

I did manage to build debian-installer from source, using the patched kernel 
package;
and I can say that it boots and has internet access. Installation gets as far 
as searchign for kernel module packages on the Debian servers. However I have 
no idea what is required to load drivers for usb, sdhc and sata from the 
install drive.

Please let me know what can be done to ultimately achieve readily usable 
installer images, say of the next debian release.

Yours sincerely
Josua Mayer

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


-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 4.16.0-rc6-armmp (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)



Bug#894762: cups-daemon: with IdleExitTimeout 60, correctly exits when idle for 60 s, but immediately respawns [regression]

2018-04-04 Thread Francesco Poli
Control: reopen -1


On Wed, 04 Apr 2018 21:06:26 +0200 Didier 'OdyX' Raboud wrote:

> Le mercredi, 4 avril 2018, 12.59:07 h CEST Brian Potkin a écrit :
> > This means cups.service has acquired an extra directive
> > "Restart=always".
> 
> Indeed. That's to make sure CUPS is restarted even when exiting normally 
> (such 
> as configuration changes.

Hello Brian and Didier!
Thanks to both of you for your kind and prompt replies.

> 
> You can configure this by creating a /etc/systemd/system/cups.service with
> [Service]
> Restart=no

Do I understand correctly that /etc/systemd/system/cups.service should
be a (modified) copy of /lib/systemd/system/cups.service ?
Or the two above quoted lines are enough as the content of
/etc/systemd/system/cups.service ?

> 
> As that's an upstream decision, I'm hereby closing this bugreport. Please 
> reopen if you think a Debian-specific patch could make sense.

Well, I am afraid I do not understand this upstream decision.

I mean: what's the point of socket activation, if the daemon is
automatically re-spawned anyway?
A Debian-specific patch could probably make sense, otherwise countless
users who want socket activation will need to create their (modified)
version of cups.service to be placed into /etc/systemd/system/


Moreover, I think that the documentation in README.Debian.gz is no
longer accurate, as it talks about SystemdIdleExit, which is no longer
supported, and, above all, it says nothing about this Restart=no
directive, which is now needed in order to enable socket activation...

I am reopening the bug report, since, at the very least,
copying /usr/share/doc/cups-daemon/examples/cups-socket.localhost.conf
into /etc/systemd/system/cups.socket.d/ is no longer enough to enable
socket activation. Hence the documentation is outdated, as I said.


Looking forward to hearing back from you.
Thanks for your time and patience!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpY5aFEwEUJ2.pgp
Description: PGP signature


Bug#893006: stretch-pu: package boost1.62/1.62.0+dfsg-4+deb9u1

2018-04-04 Thread Philipp Huebner
Hi,

Am 02.04.2018 um 12:57 schrieb Julien Cristau:
> On Thu, Mar 15, 2018 at 14:51:10 +0100, Philipp Huebner wrote:
>> I would like to fix #883987 in boost1.62 for Stretch.
>> The changes are basically the same as what is currently in testing and I got 
>> the
>> maintainer's go-ahead in
>> http://lists.alioth.debian.org/pipermail/pkg-boost-devel/2018-March/004184.html
>>
> What made these partial specializations not be necessary anymore?  That
> seems like critical missing information if we are to make a decision
> here, to know if/what we might be breaking instead.

my guess is that only upstream can really answer that.

My work colleague confirmed that we're basically using the same code as
in the example at the upstream bug tracker and it fails when using gcc-6
on Stretch:
https://svn.boost.org/trac10/ticket/12534


Best wishes,
-- 
 .''`.   Philipp Huebner 
: :'  :  pgp fp: 6719 25C5 B8CD E74A 5225  3DF9 E5CA 8C49 25E4 205F
`. `'`
  `-



signature.asc
Description: OpenPGP digital signature


Bug#888949: libconfig-model-dpkg-perl: recognize X{S,B}-Ruby-Versions field for packages depending on ruby, not only ruby section

2018-04-04 Thread Cédric Boutillier

> How about basing this decision on the Maintainer field ? (which would 
> probably 
> be more reliable than basing the decision on the presence of a dependency)

The XS-Ruby-Version is used (only?) by dh_ruby provided by the gem2deb
package. I think this behaviour would be useful also for packages not
maintained by the Ruby team, and they have a higher probability to not
be in the ruby section. So I think "build-depend on gem2deb" would be
the best criterion.

Now a decision based on the Maintainer field would possibly cover more
than 95% of the cases already, with (almost?) no false positive.

Cheers,

Cédric


signature.asc
Description: PGP signature


Bug#894840: clang: baseline cpu violation on i386

2018-04-04 Thread Sylvestre Ledru
severity 894840 normal
thanks

Hello,

On 04/04/2018 20:36, Andreas Beckmann wrote:
> Package: clang
> Version: baseline cpu violation on i386
> Severity: serious
> 
> Hi,
> 
> all clang versions (at least since wheezy) by default generate code for
> a cpu that is newer than the baseline cpu on i386. On clang-6.0 the
> default is apparently pentium4 which has sse2 (among other features),
> but that is not available on the baseline cpu, which is currently i686.
Sorry about that but this is by design and I am not planning to work on fixing 
that...

As this has been the case for a long time, it shows that it isn't a severe 
issue.

I think we (Debian) should instead have a discussion on having SSE2 as minimal 
req for intel-like cpu.
Other projects like Firefox or Chrome are making that a requirement too.

Cheers,
Sylvestre



Bug#894511: Please emphasize in the documentation a possible race condition in if-*.d hooks with systemd

2018-04-04 Thread Guus Sliepen
On Sat, Mar 31, 2018 at 06:01:18PM +0200, Raphaël Halimi wrote:

> With /etc/init.d/networking script, network interfaces configured with
> class "auto" are raised first, and only when that's done, interfaces
> configured with class "allow-hotplug" are then raised:
> 
> ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
> 
> With systemd, the unit file only calls:
> 
> /sbin/ifup -a --read-environment
> 
> ...letting udev (I guess) take care of the interfaces configured with
> class "allow-hotplug", the major difference being that both steps are
> done concurrently.

Hm, but that is more of a coincidence than by design. Ifupdown still has
a udev rule, regardless of the init system, that will bring up hotplug
interfaces. Also, the /etc/init.d/networking script might call
ifup_hotplug, but this only covers interfaces that are present at boot
time, while future hotplugged interfaces might still result in
concurrent calls to ifup.

> This leads to situation where a given hook in /etc/network/if-*.d can
> end up running multiple times simultaneously.

Indeed. I can see how this is a problem, but I don't think serializing
ifupdown is the right solution.

> The NEWS.Debian file's entry for 0.8 states that:
> 
> "Ifupdown will now be more strict when errors occur, and will also
> properly return a non-zero exit code when (de)configuring an interface
> fails. Please ensure your /etc/network/interfaces is correct and that
> your interfaces can be brought up and down without errors, especially
> during system startup."
> 
> IMHO, this doesn't emphasize enough on the fact that a given hook in
> if-*.d must be able to run several times simultaneously,

Yes, that should indeed be emphasized more. And it should be able to run
simultaneously both for SysV and systemd, although the problem happens
more often with the latter.

> I suppose the aggressive parallelizing done by systemd is expected
> behavior,

Debian's SysV system also runs init scripts in parallel! It's just that
the ordering is different than with systemd. I'm not sure why we still
call ifup_hotplug from the SysV init script as we also have the udev
rule, but it's pure luck that the init script configures the hotplug
interfaces before udev runs (unless udev really behaves differently
under SysV for some reason).

> IMHO, there should be at least some kind of warning documented somewhere

You are right. I'll add a an entry to the manual and to NEWS.Debian, so
there will be a clear warning when people are upgrading ifupdown.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature


Bug#894848: imagemagick: CVE-2018-9133: Excessive iteration in DecodeLabImage and EncodeLabImage

2018-04-04 Thread Salvatore Bonaccorso
Source: imagemagick
Version: 8:6.8.9.9-5
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/1072

Hi,

The following vulnerability was published for imagemagick:

CVE-2018-9133[0]:
| ImageMagick 7.0.7-26 Q16 has excessive iteration in the DecodeLabImage
| and EncodeLabImage functions (coders/tiff.c), which results in a hang
| (tens of minutes) with a tiny PoC file. Remote attackers could leverage
| this vulnerability to cause a denial of service via a crafted tiff
| file.

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-9133
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-9133
[1] https://github.com/ImageMagick/ImageMagick/issues/1072

Regards,
Salvatore



Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

2018-04-04 Thread Axel Beckert
Hi,

Michael Biebl wrote:
> >> As soon as you clean up the stray
> >> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1 and run ldconfig, the
> >> problem should go away?
> > 
> > No, because there's also a symlink to it which (according to the
> > timestamp) seem to have been created by maintainer scripts of this
> > package:
> > 
> > 6080 lrwxrwxrwx 1 root root 23 Apr  4 09:03 
> > /lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.1
> > 
> > Not sure how I should clean up that one. Can I safely delete it, too?
> 
> Running ldconfig should take care of removing the stray symlink.
> It was ldconfig which created the symlink, afaik.

Worked, thanks! (Both, emacs and gio-querymodules, work again.)

Feel free to close the bug report.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#459427: changelog vs. NEWS handling

2018-04-04 Thread Adrian Bunk
On Wed, Apr 04, 2018 at 12:00:29PM -0700, Sean Whitton wrote:
> Hello Adrian,
> 
> Thank you for your continued effort to get this bug resolved.
> 
> On Sat, Mar 10 2018, Adrian Bunk wrote:
> 
> >> Please expand on why you think this is the way we have to proceed.
> >
> > you skipped the part of my email with the explanation:
> >
> >   with such a piecemeal approach
> >   we risk fragmentation based on debhelper compat level used, with every
> >   new compat level installing different files in different locations.
> 
> This is not inevitable.  What I am envisaging is:
> 
> - we hash out our preferred solution either in this bug or in the
>   debhelper bug, with the debhelper maintainer having the final say on
>   what gets implemented
> - debhelper implements all of that solution at exactly one compat level
> - the archive starts to use that compat level
> - Policy is updated.

This ensures that policy will always be horribly outdated.

> This is the standard way to make changes to Policy. The alternative is
> releases of Policy rendering many packages buggy, and that is undesirable.
>...

A new debhelper compat level making packages buggy according to policy
is what is desirable?

> Our delegation gives the Policy Editors editorial authority over the
> contents of the Policy Manual, but by means of the Policy Changes
> Process we delegate that authority back to the body of DDs.
> 
> That means that changes have to establish consensus.  How do we
> establish consensus on an issue like this, just by talking about it
> where everyone has a view?  That's extremely hard.  There's no way to
> bring the discussion to a close, and so the bug is still open after 10
> years.

Let me repeat what I already wrote earlier in this bug:

IMHO the way forward is to find a consensus text for a policy change,
Cc debian-devel on the proposal, and if no objections are raised release 
a new policy with these changes.

> What we can do in this case is shortcircuit that process of establishing
> consensus by means of debhelper.  The debhelper maintainer has authority
> over what debhelper will implement.  So he implements something.  If
> it's basically a sensible convention, almost everyone will start using
> it, even if it is not their number one choice of solution.  But then we
> have enough of a consensus, so it's no longer problematic to change

The Policy Editors are a delegation, and the debhelper maintainer is 
just a random person who happens to maintain this specific package.


Precedent is also that the Policy Editors do use their powers to 
push through even a change that makes thousands of packages buggy 
after an objection has been raised:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844431#334

I begin to wonder whether I should take this personally.

> Sean Whitton

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#894759: ifupdown: networking.service ExecStartPre exits with status=1/FAILURE when it's supposed to do nothing.

2018-04-04 Thread Guus Sliepen
tags 894759 + pending
thanks

On Tue, Apr 03, 2018 at 02:56:59PM -0700, Filipe Brandenburger wrote:

> When networking.service's ExecStartPre is not supposed to do anything
> (for instance, when CONFIGURE_INTERFACES=no is set, or when `ifquery
> --read-environment --list --exclude=lo` returns an empty list, then the
> ExecStartPre will show with a (code=exited, status=1/FAILURE) in the
> `systemctl status networking.service` output.
> 
> That doesn't really cause any failures, but is misleading, since there's
> nothing necessarily wrong with that condition.
> 
> I suggest using an "if" instead of "&&" on that line, so that it still
> exits 0 if there's nothing to do.

Thanks, I applied your patch, it will be part of the next release!

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature


Bug#894847: nasm: CVE-2018-8883

2018-04-04 Thread Salvatore Bonaccorso
Source: nasm
Version: 2.13.02-0.1
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.nasm.us/show_bug.cgi?id=3392447

Hi,

The following vulnerability was published for nasm:

CVE-2018-8883[0]:
| Netwide Assembler (NASM) 2.13.02rc2 has a buffer over-read in the
| parse_line function in asm/parser.c via uncontrolled access to
| nasm_reg_flags.

cut-cut-cut-cut-cut-cut-
nasm -felf64 411618
411618:8: error: label or instruction expected at start of line
411618:16: error: comma, colon, decorator or end of line expected after operand
411618:17: error: label or instruction expected at start of line
411618:20: error: label or instruction expected at start of line
411618:38: error: comma, colon, decorator or end of line expected after operand
411618:40: warning: unterminated string
411618:40: error: label or instruction expected at start of line
411618:43: error: label or instruction expected at start of line
=
==5711==ERROR: AddressSanitizer: global-buffer-overflow on address 
0x55a680396c88 at pc 0x55a680244455 bp 0x7ffd87222c30 sp 0x7ffd87222c28
READ of size 8 at 0x55a680396c88 thread T0
#0 0x55a680244454  (/usr/bin/nasm+0x269454)
#1 0x55a68020bc43  (/usr/bin/nasm+0x230c43)
#2 0x55a680204bbe  (/usr/bin/nasm+0x229bbe)
#3 0x7fb63c410a86 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
#4 0x55a680206a39  (/usr/bin/nasm+0x22ba39)

0x55a680396c88 is located 0 bytes to the right of global variable 
'nasm_reg_flags' defined in 'x86/regflags.c:6:17' (0x55a680396500) of size 1928
SUMMARY: AddressSanitizer: global-buffer-overflow (/usr/bin/nasm+0x269454) 
Shadow bytes around the buggy address:
  0x0ab55006ad40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab55006ad50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab55006ad60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab55006ad70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab55006ad80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ab55006ad90: 00[f9]f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x0ab55006ada0: 00 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9
  0x0ab55006adb0: 03 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9
  0x0ab55006adc0: 00 04 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 00 00
  0x0ab55006add0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0ab55006ade0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==5711==ABORTING
cut-cut-cut-cut-cut-cut-



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-8883
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8883
[1] https://bugzilla.nasm.us/show_bug.cgi?id=3392447

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#889803: NMU for cdio-paranoia

2018-04-04 Thread Bas Zoetekouw
Hi Pavel,

Did you NMU for cd-paranoia ever made it though DELAYED?  I was also
looking for the cd-paranoia binary, but it still doesn't seem to be in
the archive.

Gr,
Bas.



signature.asc
Description: OpenPGP digital signature


Bug#894846: nasm: CVE-2018-8882

2018-04-04 Thread Salvatore Bonaccorso
Source: nasm
Version: 2.13.02-0.1
Severity: important
Tags: security upstream
Forwarded: https://bugzilla.nasm.us/show_bug.cgi?id=3392445

Hi,

The following vulnerability was published for nasm:

CVE-2018-8882[0]:
| Netwide Assembler (NASM) 2.13.02rc2 has a stack-based buffer under-read
| in the function ieee_shr in asm/float.c via a large shift value.

The issue is verifiable with an ASAN build of nasm.

cut-cut-cut-cut-cut-cut-
$ nasm -felf64  411616
411616:16: error: comma, colon, decorator or end of line expected after operand
411616:21: error: parser: instruction expected
411616:30: error: label or instruction expected at start of line
411616:33: error: comma, colon, decorator or end of line expected after operand
411616:34: error: comma, colon, decorator or end of line expected after operand
411616:39: error: comma, colon, decorator or end of line expected after operand
=
==5602==ERROR: AddressSanitizer: stack-buffer-overflow on address 
0x7ffdc0250564 at pc 0x559c536f0418 bp 0x7ffdc0250420 sp 0x7ffdc0250418
READ of size 4 at 0x7ffdc0250564 thread T0
#0 0x559c536f0417  (/usr/bin/nasm+0x330417)
#1 0x559c536f3fbc  (/usr/bin/nasm+0x333fbc)
#2 0x559c53624394  (/usr/bin/nasm+0x264394)
#3 0x559c535f0c43  (/usr/bin/nasm+0x230c43)
#4 0x559c535e9bbe  (/usr/bin/nasm+0x229bbe)
#5 0x7f37551a3a86 in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21a86)
#6 0x559c535eba39  (/usr/bin/nasm+0x22ba39)

Address 0x7ffdc0250564 is located in stack of thread T0 at offset 84 in frame
#0 0x559c536f2ecf  (/usr/bin/nasm+0x332ecf)

  This frame has 2 object(s):
[32, 36) 'exponent'
[96, 120) 'mant' <== Memory access at offset 84 underflows this variable
HINT: this may be a false positive if your program uses some custom stack 
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow (/usr/bin/nasm+0x330417)
Shadow bytes around the buggy address:
  0x100038042050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100038042060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100038042070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100038042080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x100038042090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000380420a0: 00 00 f1 f1 f1 f1 04 f2 f2 f2 f2 f2[f2]f2 00 00
  0x1000380420b0: 00 f2 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000380420c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x1000380420d0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x1000380420e0: 02 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 f2 f2 f2 f2
  0x1000380420f0: f8 f8 f8 f8 f2 f2 f2 f2 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==5602==ABORTING
cut-cut-cut-cut-cut-cut-

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-8882
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8882
[1] https://bugzilla.nasm.us/show_bug.cgi?id=3392445

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore



Bug#894845: nat FTCBFS: uses the build architecture compiler

2018-04-04 Thread Helmut Grohne
Source: nat
Version: 1:1.0-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

nat fails to cross build from source, because it uses the build
architecture compiler. The easiest way of fixing that is letting
dh_auto_build pass cross compilers to make. After doing so, nat cross
builds successfully. Please consider applying the attached patch.

Helmut
diff -u nat-1.0/debian/changelog nat-1.0/debian/changelog
--- nat-1.0/debian/changelog
+++ nat-1.0/debian/changelog
@@ -1,3 +1,12 @@
+nat (1:1.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Defer all stripping to dh_strip.
+
+ -- Helmut Grohne   Wed, 04 Apr 2018 21:40:32 +0200
+
 nat (1:1.0-6) unstable; urgency=medium
 
   * include.h: Apply patch provided by Cyril Roelandt to fix 
diff -u nat-1.0/debian/control nat-1.0/debian/control
--- nat-1.0/debian/control
+++ nat-1.0/debian/control
@@ -2,7 +2,7 @@
 Section: admin
 Priority: extra
 Maintainer: Javier Fernandez-Sanguino Peña 
-Build-Depends: debhelper (>> 3.0.0)
+Build-Depends: debhelper (>= 7)
 Standards-Version: 3.9.6
 Homepage: http://www.tux.org/pub/security/secnet/tools/nat10/
 
diff -u nat-1.0/debian/rules nat-1.0/debian/rules
--- nat-1.0/debian/rules
+++ nat-1.0/debian/rules
@@ -13,9 +13,6 @@
 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
 endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
 
 configure: configure-stamp
 configure-stamp:
@@ -29,7 +26,7 @@
 
 build-stamp: configure-stamp 
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch build-stamp
 
 clean:


Bug#894844: moon-buggy FTCBFS: configures for the build architecture

2018-04-04 Thread Helmut Grohne
Source: moon-buggy
Version: 1:1.0.51-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

moon-buggy fails to cross build from source, because it configures for
the build architecture. The easiest way of fixing this is letting
dh_auto_configure do it as is demonstrated in the attached patch. After
doing so, moon-buggy cross builds successfully. Please consider applying
the patch.

Helmut
diff --minimal -Nru moon-buggy-1.0.51/debian/changelog 
moon-buggy-1.0.51/debian/changelog
--- moon-buggy-1.0.51/debian/changelog  2017-12-30 16:27:58.0 +0100
+++ moon-buggy-1.0.51/debian/changelog  2018-04-04 21:31:11.0 +0200
@@ -1,3 +1,10 @@
+moon-buggy (1:1.0.51-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass --host to ./configure. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 04 Apr 2018 21:31:11 +0200
+
 moon-buggy (1:1.0.51-1) unstable; urgency=medium
 
   * repackage from scratch using an epoch and dh 9
diff --minimal -Nru moon-buggy-1.0.51/debian/rules 
moon-buggy-1.0.51/debian/rules
--- moon-buggy-1.0.51/debian/rules  2017-12-30 15:46:51.0 +0100
+++ moon-buggy-1.0.51/debian/rules  2018-04-04 21:31:05.0 +0200
@@ -14,11 +14,8 @@
dh $@ --with autotools_dev
 
 override_dh_auto_configure:
-   ./configure \
-   --prefix=/usr \
+   dh_auto_configure -- \
--bindir=/usr/games \
-   --mandir=/usr/share/man \
-   --infodir=/usr/share/info \
--sharedstatedir=/var/games \
--with-setgid=games 
 


Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

2018-04-04 Thread Michael Biebl
Am 04.04.2018 um 21:27 schrieb Axel Beckert:

>> As soon as you clean up the stray
>> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1 and run ldconfig, the
>> problem should go away?
> 
> No, because there's also a symlink to it which (according to the
> timestamp) seem to have been created by maintainer scripts of this
> package:
> 
> 6080 lrwxrwxrwx 1 root root 23 Apr  4 09:03 
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.1
> 
> Not sure how I should clean up that one. Can I safely delete it, too?

Running ldconfig should take care of removing the stray symlink.
It was ldconfig which created the symlink, afaik.






signature.asc
Description: OpenPGP digital signature


Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

2018-04-04 Thread Axel Beckert
Hi Michael,

Michael Biebl wrote:
> Do you have an idea, where this file might have come from?

On a first thought: No. The package is no package I installed on
purpose, it came in by dependencies and I surely didn't fiddle around
with its configuration (if it has one).

On a second thought: I know that in the very beginning of that system
(i.e. during 2015) I had issues with the SD card the system runs off
and I at least replaced the SD card once, maybe twice. IIRC the
original SD card went readonly and I dd'ed its contents onto a new one
and ran fsck (offline). While that in theory could cause stray files,
IMHO especially dpkg is rather good in keeping things consistent.

So I slightly doubt that this is the cause for this issue. On the
other hand, it seems the best explanation currently available.

> So it looks like a local misconfiguration which went unnoticed so far as
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.5* took precedence over
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

I have no idea what kind of "configuration" could be involved here.

> I guess there is nothing really the libglib2.0-0 package can do about
> this. Do you agree?

If I'm the only one who happens to have this issue, I'm fine with
closing this as unreproducible.

> As soon as you clean up the stray
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1 and run ldconfig, the
> problem should go away?

No, because there's also a symlink to it which (according to the
timestamp) seem to have been created by maintainer scripts of this
package:

6080 lrwxrwxrwx 1 root root 23 Apr  4 09:03 
/lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.1

Not sure how I should clean up that one. Can I safely delete it, too?

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#894843: gimp: Binary package gimp=2.10.0~RC1-1 depends on gimp-data (>= 2.10.0~RC1), but it's not available.

2018-04-04 Thread Lenard Szolnoki
Package: gimp
Version: 2.8.20-2
Severity: normal

Dear Maintainer,

It seems like the gimp-data package is not built from the 2.10.0~RC1-1
source package, yet it's a dependency of the gimp binary package.

Best Regards
Lénárd Szolnoki

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (600, 'stable'), (400, 
'experimental'), (80, 'unstable'), (70, 'testing'), (60, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gimp depends on:
ii  gimp-data2.8.20-2
ii  libaa1   1.4p5-44+b1
ii  libatk1.0-0  2.28.1-1
ii  libbabl-0.1-00.1.44-1
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-2
ii  libcairo21.15.10-2
ii  libdbus-1-3  1.12.6-2
ii  libdbus-glib-1-2 0.110-2
ii  libexif120.6.21-4
ii  libexpat12.2.5-3
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgegl-0.3-00.3.28-1
ii  libgimp2.0   2.8.20-2
ii  libglib2.0-0 2.56.0-4
ii  libgs9   9.22~dfsg-2
ii  libgtk2.0-0  2.24.32-1
ii  libgudev-1.0-0   232-2
ii  libice6  2:1.0.9-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjson-glib-1.0-0   1.4.2-3
ii  liblcms2-2   2.9-1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libpango-1.0-0   1.40.14-1
ii  libpangocairo-1.0-0  1.40.14-1
ii  libpangoft2-1.0-01.40.14-1
ii  libpng16-16  1.6.34-1
ii  libpoppler-glib8 0.61.1-2
ii  librsvg2-2   2.40.20-2
ii  libsm6   2:1.2.2-1+b3
ii  libtiff5 4.0.9-4
ii  libwmf0.2-7  0.2.8.4-12
ii  libx11-6 2:1.6.5-1
ii  libxcursor1  1:1.1.15-1
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  libxt6   1:1.1.5-1
ii  python   2.7.14-4
ii  python-gtk2  2.24.0-5.1+b1
ii  python2.72.7.14-7
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages gimp recommends:
ii  ghostscript  9.22~dfsg-2

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gvfs-backends 1.36.0-1
ii  libasound21.1.3-5

-- debconf-show failed


Bug#894842: RM: roboptim-core -- RoQA, unmaintained, RC-Buggy

2018-04-04 Thread Tobias Frost
Source: roboptim-core
Severity: serious

Dear Maintainer,

The package is RC-buggy since 2015 and seems to be unmaintained.
The last non-NMU upload was 2014.

Therefore the question whether it should be removed from Debian.
Popcon is almost zero.

If you think the package should remain in Debian, please fix the 
RC bugs and then close this bugs. If not, I will reassign the bug 
to ftp.debian.org in exactly 3 months from now for execution of the 
removal.

Thanks!
--
tobi



Bug#894754: vagrant: Invalid gemspec in rbnacl-libsodium stack level too deep

2018-04-04 Thread Antonio Terceiro
Control: tag -1 + moreinfo unreproducible

On Tue, Apr 03, 2018 at 04:17:51PM -0500, Nicholas Capo wrote:
> Package: vagrant
> Version: 2.0.2+dfsg-3
> Severity: normal
> 
> Dear Maintainer,
> 
> When running any `vagrant` command the following is error appears and the
> command seems to never complete.
> 
> ```
> $ vagrant status
> Invalid gemspec in [/usr/share/rubygems-integration/all/specifications/rbnacl-
> libsodium.gemspec]: stack level too deep
> ```
> 
> At one point I typed Ctrl+C quickly and got this (possibly related) stack
> trace:
> 
> ```
> $ vagrant status
> Invalid gemspec in [/usr/share/rubygems-integration/all/specifications/rbnacl-
> libsodium.gemspec]: stack level too deep
> [...]
> ```

I can't reproduce this on my system, nor in a clean system with only
vagrant installed.

> I have tried removing `ruby-rbnacl` (which removes `vagrant`) and 
> reinstalling,
> but the issue persists.
> ```
> $ sudo apt autoremove --purge ruby-rbnacl
[...]
> $ sudo apt install vagrant
> $ vagrant status
> Invalid gemspec in [/usr/share/rubygems-integration/all/specifications/rbnacl-
> libsodium.gemspec]: stack level too deep
> ^C
> ```
> 
> I do not beleive I have any gems installed (other than what comes from apt),
> but here is the list just in case:
> 
> ```
> sudo gem list
[...]
> ```

I need more than that. please share the output of:

find /var/lib/gems
gem list rbnacl-libsodium
ruby -e 'gem "rbnacl-libsodium"'

also, do you have vagrant plugins installed from outside of Debian?


signature.asc
Description: PGP signature


Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

2018-04-04 Thread Michael Biebl
Am 04.04.2018 um 21:06 schrieb Michael Biebl:
> Am 04.04.2018 um 20:20 schrieb Axel Beckert:
>> Hi,
>>
>> Simon McVittie wrote:
 This looks like there is a libglib-2.0.so.0 in /lib/arm-linux-gnueabihf/ 
 that shouldn't be there, and this takes precedence over the more recent
 one from the Debian package that gets installed to /usr/lib.
>>>
>>> My thoughts exactly. What's that doing there? I would have expected that
>>> removing the old libglib2.0-0 package would delete that.
>>>
>>> Please try:
>>>
>>> ls -il /lib/arm-linux-gnueabihf/libglib-2.0.so*
>>
>> 6080 lrwxrwxrwx 1 root root 23 Apr  4 09:03 
>> /lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.1
>> 1563 -rw-r--r-- 1 root root 814280 Nov 13  2014 
>> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
> 
> Where is this file /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
> coming from?
> Does dpkg list it as owned by any package?

Sorry, somehow completely missed the following paragraph where you
answered that already.

Do you have an idea, where this file might have come from?

So it looks like a local misconfiguration which went unnoticed so far as
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.5* took precedence over
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

I guess there is nothing really the libglib2.0-0 package can do about
this. Do you agree?
As soon as you clean up the stray
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1 and run ldconfig, the
problem should go away?



signature.asc
Description: OpenPGP digital signature


Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

2018-04-04 Thread Axel Beckert
Hi,

Michael Biebl wrote:
> >> ls -il /lib/arm-linux-gnueabihf/libglib-2.0.so*
> > 
> > 6080 lrwxrwxrwx 1 root root 23 Apr  4 09:03 
> > /lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.1
> > 1563 -rw-r--r-- 1 root root 814280 Nov 13  2014 
> > /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
> 
> Where is this file /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
> coming from?

I don't know.

> Does dpkg list it as owned by any package?

Please read my previous mail a few lines further than you cited it.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#882213: gvfs-fuse: MTP device still visible after disconnecting

2018-04-04 Thread Jérémy Viès
The fixes for gnome-3-22 has also been posted on gnome git repository.
Can you backport the fix to gvfs 1.30, used by gnome 3.22 that are on
stretch ?

https://github.com/GNOME/gvfs/commits/gnome-3-22

Thx a lot,
Jérémy

On Tue, 3 Apr 2018 12:03:36 +0100 Simon McVittie  wrote:
> Version: 1.35.90-1
>
> On Mon, 20 Nov 2017 at 11:20:10 +0100, Michal M. wrote:
> >  - Unmount your device, disconnect USB cable. Device is removed, but
item is
> > still visible in "Devices" section. It's dead item, not possible to
remove it
> > or mount/unmount
>
> This is believed to have been fixed in gvfs 1.35 (see #882353, #883425).
>
> smcv
>
>


Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

2018-04-04 Thread Michael Biebl
Am 04.04.2018 um 20:20 schrieb Axel Beckert:
> Hi,
> 
> Simon McVittie wrote:
>>> This looks like there is a libglib-2.0.so.0 in /lib/arm-linux-gnueabihf/ 
>>> that shouldn't be there, and this takes precedence over the more recent
>>> one from the Debian package that gets installed to /usr/lib.
>>
>> My thoughts exactly. What's that doing there? I would have expected that
>> removing the old libglib2.0-0 package would delete that.
>>
>> Please try:
>>
>> ls -il /lib/arm-linux-gnueabihf/libglib-2.0.so*
> 
> 6080 lrwxrwxrwx 1 root root 23 Apr  4 09:03 
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.1
> 1563 -rw-r--r-- 1 root root 814280 Nov 13  2014 
> /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

Where is this file /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
coming from?
Does dpkg list it as owned by any package?



signature.asc
Description: OpenPGP digital signature


Bug#459427: changelog vs. NEWS handling

2018-04-04 Thread Sean Whitton
Hello Adrian,

Thank you for your continued effort to get this bug resolved.

On Sat, Mar 10 2018, Adrian Bunk wrote:

>> Please expand on why you think this is the way we have to proceed.
>
> you skipped the part of my email with the explanation:
>
>   with such a piecemeal approach
>   we risk fragmentation based on debhelper compat level used, with every
>   new compat level installing different files in different locations.

This is not inevitable.  What I am envisaging is:

- we hash out our preferred solution either in this bug or in the
  debhelper bug, with the debhelper maintainer having the final say on
  what gets implemented
- debhelper implements all of that solution at exactly one compat level
- the archive starts to use that compat level
- Policy is updated.

This is the standard way to make changes to Policy.  The alternative is
releases of Policy rendering many packages buggy, and that is undesirable.

I don't think you've explained why you think that can't happen for this
bug too.  You're right to note the piecemeal compat level risk, but now
that we're aware of that risk, it seems straightforward to mitigate.
We just avoid implementing anything in debhelper until we can implement
it all in debhelper.

> Your point of view sounds to me like
>   In 15 years policy will be changed to document whatever the
>   debhelper maintainer decides to implement in dh compat 12.
>
> To me this doesn't make sense.
>
> This bug is now over 10 years old, and at some point someone has to
> decide which files should be installed and where.
>
> The obvious way forward would be to try to find a consensus here,
> and then ask on debian-devel whether there are any objections.
>
> If anything ends up being controverial and a decision is required, our
> constitution already makes it clear who is responsible for the decision
> (and this is not the debhelper maintainer).

Our delegation gives the Policy Editors editorial authority over the
contents of the Policy Manual, but by means of the Policy Changes
Process we delegate that authority back to the body of DDs.

That means that changes have to establish consensus.  How do we
establish consensus on an issue like this, just by talking about it
where everyone has a view?  That's extremely hard.  There's no way to
bring the discussion to a close, and so the bug is still open after 10
years.

What we can do in this case is shortcircuit that process of establishing
consensus by means of debhelper.  The debhelper maintainer has authority
over what debhelper will implement.  So he implements something.  If
it's basically a sensible convention, almost everyone will start using
it, even if it is not their number one choice of solution.  But then we
have enough of a consensus, so it's no longer problematic to change
Policy.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#894841: pg-repack: fix failing dep8 tests with postgresql 10.3

2018-04-04 Thread Nishanth Aravamudan
Package: pg-repack
Version: 1.4.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to fix DEP8 regressions with
Postgresql 10.3.


  * debian/patches/always_qualify_relation_names.patch: Always qualify
relation names.  Thanks to Masahiko Sawada .


Thanks for considering the patch.

*** /tmp/tmpB3TGJW/pg-repack_1.4.2-1ubuntu1.debdiff
diff -Nru pg-repack-1.4.2/debian/patches/always_qualify_relation_names.patch 
pg-repack-1.4.2/debian/patches/always_qualify_relation_names.patch
--- pg-repack-1.4.2/debian/patches/always_qualify_relation_names.patch  
1969-12-31 16:00:00.0 -0800
+++ pg-repack-1.4.2/debian/patches/always_qualify_relation_names.patch  
2018-04-04 10:22:56.0 -0700
@@ -0,0 +1,2905 @@
+Description: Always qualify relation names
+ Due to change at PostgreSQL 10.3, 9.6.8, 9.5.12, 9.4.17 and 9.3.22,
+ relation names passed by PostgreSQL function such as
+ pg_get_indexdef_string() are schema-qualified, which could be cause
+ of a parse error.
+Author: Masahiko Sawada 
+Origin: upstream, https://github.com/reorg/pg_repack/pull/172
+Bug: https://github.com/reorg/pg_repack/issues/169
+Bug: https://github.com/reorg/pg_repack/issues/174
+Forwarded: not-needed
+Last-Update: 2018-04-04
+
+--- a/lib/pg_repack.sql.in
 b/lib/pg_repack.sql.in
+@@ -16,6 +16,30 @@
+ $$SELECT 'pg_repack REPACK_VERSION'::text$$
+ LANGUAGE SQL IMMUTABLE STRICT;
+ 
++CREATE FUNCTION repack.pg_version(version_str text DEFAULT NULL) RETURNS 
integer
++AS $$
++-- Return the server version number in a format similar to PG_VERSION_NUM.
++-- Call with no argument for the server version, pass an argument for 
testing
++select (case
++when array_length(tokens, 1) = 2 then
++to_char(tokens[1], 'FM00') ||
++'00' || to_char(tokens[2], 'FM00')
++when array_length(tokens, 1) = 3 then
++to_char(tokens[1], 'FM00') ||
++to_char(tokens[2], 'FM00') ||
++to_char(tokens[3], 'FM00')
++else
++-- This will raise an error which we can read
++'unexpected version string: ' || coalesce($1, version())
++end)::int
++from (
++select string_to_array(substring(
++split_part(coalesce($1, version()), ' ', 2)
++from '\d+\.\d+(?:\.\d+)?'), '.')::int[]
++) as x (tokens);
++$$
++LANGUAGE SQL IMMUTABLE;
++
+ CREATE AGGREGATE repack.array_accum (
+ sfunc = array_append,
+ basetype = anyelement,
+--- a/lib/repack.c
 b/lib/repack.c
+@@ -354,11 +354,30 @@
+   Oid nsp = get_rel_namespace(relid);
+   char   *nspname;
+ 
++  /*
++   * Relation names given by PostgreSQL core are always
++   * qualified since some minor releases. Note that this change
++   * doesn't introduce to PostgreSQL 9.2 and 9.1 releases.
++   */
++#if ((PG_VERSION_NUM >= 10 && PG_VERSION_NUM < 13) || \
++   (PG_VERSION_NUM >= 90600 && PG_VERSION_NUM < 90608) || \
++   (PG_VERSION_NUM >= 90500 && PG_VERSION_NUM < 90512) || \
++   (PG_VERSION_NUM >= 90400 && PG_VERSION_NUM < 90417) || \
++   (PG_VERSION_NUM >= 90300 && PG_VERSION_NUM < 90322) || \
++   (PG_VERSION_NUM >= 90200 && PG_VERSION_NUM < 90300) || \
++   (PG_VERSION_NUM >= 90100 && PG_VERSION_NUM < 90200))
+   /* Qualify the name if not visible in search path */
+   if (RelationIsVisible(relid))
+   nspname = NULL;
+   else
+   nspname = get_namespace_name(nsp);
++#else
++  /* Qualify the name */
++  if (OidIsValid(nsp))
++  nspname = get_namespace_name(nsp);
++  else
++  nspname = NULL;
++#endif
+ 
+   return quote_qualified_identifier(nspname, get_rel_name(relid));
+ }
+--- a/regress/expected/repack.out
 b/regress/expected/repack.out
+@@ -1,14 +1,19 @@
+ -- Test output file identifier.
+-SELECT CASE
+-  WHEN split_part(version(), ' ', 2) ~ '^(10)'
+-  THEN 'repack_2.out'
+-  WHEN split_part(version(), ' ', 2) ~ '^(9\.6|9\.5)'
+-  THEN 'repack.out'
+-  WHEN split_part(version(), ' ', 2) ~ '^(9\.4|9\.3|9\.2|9\.1)'
+-  THEN 'repack_1.out'
+-  ELSE version()
+-END AS testfile;
+-  testfile  
++select filename from (values
++( 90100,  90300, 'repack_1.out'),
++( 90300,  90322, 'repack_6.out'),
++( 90322,  90400, 'repack_5.out'),
++( 90400,  90417, 'repack_1.out'),
++( 90417,  90500, 'repack_5.out'),
++( 90500,  90512, 'repack.out'),
++( 90512,  90600, 'repack_4.out'),
++( 90600,  90608, 'repack.out'),
++( 90608, 10, 'repack_4.out'),
++(10, 13, 'repack_2.out'),
++(13, 11, 'repack_3.out')
++) as x (min, max, filename)
++where min <= repack.pg_version() and repack.pg_version() < max;
++  filename  
+ 
+  repack.out
+ (1 

Bug#894549: debhelper: dh_usrlocal may remove a direct subdirectory of /usr/local

2018-04-04 Thread Niels Thykier
On Wed, 04 Apr 2018 18:29:00 + Niels Thykier  wrote:
> On Mon, 2 Apr 2018 16:53:52 +0200 Nicolas Boulenguez
>  wrote:
> > Package: debhelper
> > Followup-For: Bug #894549
> > 
> > Hello.
> > 
> > This new diff should fix the same issues in dh_usrlocal.
> > The result is more readable in my opinion, hopefully preventing
> > similar errors in the future.
> > 
> > It should also be a bit more efficient: instead of sorting two huge
> > lists of paths all starting with "/usr/share/", it sorts once simple
> > names in each directory.
> > 
> > When a normal file is encountered, it displays an error instead of a
> > warning. This does not change much, as rmdir would fail with a less
> > explicit message when attempting to remove the containing directory.
> 
> Hi Nicolas,
> 
> Thanks for your finding and the patch.
> 
> While we are at the subject of making it more readable, perhaps I could
> ask you convert dh_usrlocal to use the "hashref" based autoscript?  That
> should avoid the need for the "\\\"-mess we currently have.
> 
> Also, many thanks for the other bugs you have filed recently.  I am very
> grateful that you have included patches in them. :)
> 
> Thanks,
> ~Niels
> 
> 

Just double checked this one:  I think there is a bug in your proposed
patch.  The "justdirs" is supposed to be in "opposite" order of "dirs"
("justdirs" are in "removal order" while "dirs" are in "creation order")
but as far as I can see that ordering is not preserved in the patch.

I think dh_usrlocal might be ready for some test cases to avoid future
breakage.  If you want to have a look at that, it would be appreciated
as well - otherwise, I will probably look at it when I review your
updated patch.

Thanks,
~Niels



Bug#894807: qtbase-opensource-src: Consider recommending qt5ct perhaps in widgets or gui

2018-04-04 Thread Dmitry Shachnev
Hi Lisandro and Maximiliano!

On Wed, Apr 04, 2018 at 09:03:34AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> [08:50:25]  lisandro, mitya57: yet again about PLATFORMTHEMES,
> currently nothing depends on qt5-gtk-platformtheme qt5-style-plugins nor
> qt5ct, I don't know what qt5 uses when QT_PLATFORMTHEME is not being set,
> but it seems reasonable that at least that package gets installed when
> installing a qt app.
> [08:51:22]  let me see if I understand that
> [08:52:02]  when there is no QT_PLATFORMTHEME set then qt shows a
> default theme, which I *think* it's the windows' one
> [08:52:52]  if the user wants a different theme then she must
> install a new theme or qt5ct in order to easily change the ones shipped by
> qt
> [08:53:52]  we could recommend qt5ct with libqt5widgets5 I guess
> [08:55:40]  That would be fine by me, and qt5ct sets QT_PLATFORMTHEME
> in the session if installed. (that would also avoid desktop environments to
> have to set QT_PLATFORMTHEME)
> [08:56:52]  so far it sets it everywhere except Plasma
> [08:56:58]  At least on the cinnamon side of things we are setting
> QT_PLATFORMTHEME=gtk2 as it was the only sensible plaformtheme for stretch,
> but that's no longer true.
>
> It could be recommends or suggests, thoughts welcomed!

I must admit that qt5ct has significantly improved since the times I last
looked at it. In particular, it now can handle global menus and D-Bus tray
icons.

However there is still one major problem with it: it does not support native
GTK+ 3 dialogs. Test case: run Qt Designer under GNOME with qt5ct and without
it. If you click Open button, the native GTK+ dialog will be used only when
qt5ct is not used. This is a significant regression for users of GNOME, Xfce,
Cinnamon, etc (compared to normal Qt setup).

Given this issue, and the fact that it is difficult for an average user to
disable qt5ct, I think we should not recommend it in Qt. Suggests is fine
though.

As Maximiliano mentioned some other things in his IRC message, I will reply
to them too:

> currently nothing depends on qt5-gtk-platformtheme qt5-style-plugins

libqt5gui5 currently recommends qt5-gtk-platformtheme. We cannot depend on
it because we do not want to depend on GTK+.

qt5-style-plugins is a collection of obsolete styles that are no longer
maintained or supported by The Qt Company. It can be sometimes safe to use,
but we do not want to suggest using it.

> At least on the cinnamon side of things we are setting QT_PLATFORMTHEME=gtk2

There is no sense in doing that (and this is the wrong variable name anyway).
Qt automatically enables GTK+ integration support when it is run on Cinnamon
or on other GTK+ based desktop:

https://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/themes/genericunix/qgenericunixthemes.cpp#n863

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#881431: proposed wording

2018-04-04 Thread Sean Whitton
Hello,

Thank you for the feedback, Simon.

I tried to incorporate what you said while avoiding talking about the
namespace pairs, for the sake of readability.  Further, I shortened
"upstream version without the epoch" to "upstream version" because the
epoch is a Debian thing.

Seeking seconds:

> §3.2.2 Uniqueness of version numbers
>
> The part of the version number after the epoch must not be reused for
> a version of the package with different contents once the package has
> been accepted into the archive, even if the version of the package
> previously using that part of the version number is no longer present
> in any archive suites.
>
> This uniqueness requirement applies to the version numbers of source
> packages and of binary packages, even if the source package producing
> a given binary package changes.  Thus the version numbers which a
> binary package must not reuse includes the version numbers of any
> versions of the binary package ever accepted into the archive, under
> any source package.
>
> Additionally, for non-native packages, the upstream version must not
> be reused for different upstream source code, so that for each source
> package name and upstream version number there exists exactly one
> original source archive contents [reference to defintiion of that].
>
> The reason for these restrictions is as follows.  Epochs are not
> included in the names of the files that compose source packages, or in
> the filenames of binary packages, so reusing a version number, even if
> the epoch differs, results in identically named files with different
> contents.  This can cause various problems.
>
> If you find yourself wanting to reuse the part of a version number
> after the epoch, you can just increment the Debian revision, which
> doesn't need to start at 1 or be consecutive.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#894764: Please prompt for password on import of encrypted file

2018-04-04 Thread martin f krafft
also sprach Jeff  [2018-04-05 04:05 +1200]:
> Do you know of a command-line tool with which I can build a PDF with a
> password, or at least add a password to an existing PDF?

pdftk can do that:

  pdftk input.pdf output output.pdf encrypt_128bit user_pw s3cr3t

Cheers!

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
"this week dragged past me so slowly;
 the days fell on their knees..."
  -- david bowie


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)


Bug#890355: man: nroff: Bad system call

2018-04-04 Thread Thorsten Glaser
Hi Colin,

>tglase@tglase:~ $ man ls
>man: nroff: Bad system call
> Manual page ls(1) line ?/? (END) (press h for help or q to quit)

any progress on this? Can I disable the seccomp stuff locally,
using a configuration file or something? It’s kinda annoying
after a while, on my $dayjob desktop which uses x32.


Also, this might be related: I see this at the tail of a failed
buildd log, for sh4, on a buildd which uses qemu:

   dh_installman -a -O--buildsystem=cmake
man: ../../../src/man.c:2334: display: Assertion `man_file' failed.
qemu: uncaught target signal 6 (Aborted) - core dumped
dh_installman: man -l --recode UTF-8 
./debian/musescore/usr/share/man/man1/mscore.1.gz > 
debian/musescore/usr/share/man/man1/mscore.1.gz.dh-new died with signal 6
dh_installman: Aborting due to earlier error
make: *** [debian/rules:10: binary-arch] Error 2

Perhaps seccomp is confusing qemu here, too?

Thanks in advance,
//mirabilos
-- 
 you introduced a merge commit│ % g rebase -i HEAD^^
 sorry, no idea and rebasing just fscked │ Segmentation
 should have cloned into a clean repo  │  fault (core dumped)
 if I rebase that now, it's really ugh │ wuahh



Bug#894840: clang: baseline cpu violation on i386

2018-04-04 Thread Andreas Beckmann
Package: clang
Version: baseline cpu violation on i386
Severity: serious

Hi,

all clang versions (at least since wheezy) by default generate code for
a cpu that is newer than the baseline cpu on i386. On clang-6.0 the
default is apparently pentium4 which has sse2 (among other features),
but that is not available on the baseline cpu, which is currently i686.

>From clang on wheezy/i386 (but the result is equivalent on newer releases
and also on amd64 with -m32) - clang generates sse code for some floating
point arithmetic, while gcc generates x87 code:

$ echo 'double fma(double a, double b, double c) { return a * b + c; }' | clang 
-O2 -S -xc - -o-
.file   "-"
.text
.globl  fma
.align  16, 0x90
.type   fma,@function
fma:# @fma
# BB#0: 
subl$12, %esp
movsd   16(%esp), %xmm0
mulsd   24(%esp), %xmm0
addsd   32(%esp), %xmm0
movsd   %xmm0, (%esp)
fldl(%esp)
addl$12, %esp
ret
.Ltmp0: 
.size   fma, .Ltmp0-fma


.section".note.GNU-stack","",@progbits

$ echo 'double fma(double a, double b, double c) { return a * b + c; }' | gcc 
-O2 -S -xc - -o-
.file   ""
.text
.p2align 4,,15
.globl  fma
.type   fma, @function
fma:
.LFB0:  
.cfi_startproc
fldl12(%esp)
fmull   4(%esp)
faddl   20(%esp)
ret
.cfi_endproc
.LFE0:  
.size   fma, .-fma
.ident  "GCC: (Debian 4.7.2-5) 4.7.2"
.section.note.GNU-stack,"",@progbits


Andreas



Bug#894549: debhelper: dh_usrlocal may remove a direct subdirectory of /usr/local

2018-04-04 Thread Niels Thykier
On Mon, 2 Apr 2018 16:53:52 +0200 Nicolas Boulenguez
 wrote:
> Package: debhelper
> Followup-For: Bug #894549
> 
> Hello.
> 
> This new diff should fix the same issues in dh_usrlocal.
> The result is more readable in my opinion, hopefully preventing
> similar errors in the future.
> 
> It should also be a bit more efficient: instead of sorting two huge
> lists of paths all starting with "/usr/share/", it sorts once simple
> names in each directory.
> 
> When a normal file is encountered, it displays an error instead of a
> warning. This does not change much, as rmdir would fail with a less
> explicit message when attempting to remove the containing directory.

Hi Nicolas,

Thanks for your finding and the patch.

While we are at the subject of making it more readable, perhaps I could
ask you convert dh_usrlocal to use the "hashref" based autoscript?  That
should avoid the need for the "\\\"-mess we currently have.

Also, many thanks for the other bugs you have filed recently.  I am very
grateful that you have included patches in them. :)

Thanks,
~Niels



Bug#886394: java.lang.ClassNotFoundException: javafx.scene.layout.HBox

2018-04-04 Thread Norbert
Package: pdfsam
Version: 3.3.5-1
Followup-For: Bug #886394

Hello,

I can confirm the bug report, the package is still unusable.

I have tested upgrading these libraries to unstable/sid, but the problem still 
persists:
ii  libopenjfx-java8u151-b12-1
ii  libopenjfx-jni 8u151-b12-1
ii  openjfx8u151-b12-1



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

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

Versions of packages pdfsam depends on:
ii  default-jre [java8-runtime]2:1.9-62
ii  libatinject-jsr330-api-java1.0+ds1-5
ii  libbcmail-java 1.59-1
ii  libbcprov-java 1.59-1
ii  libcommons-io-java 2.6-2
ii  libcommons-lang3-java  3.5-1
ii  libfontawesomefx-java  8.9-1
ii  libgettext-commons-java0.9.6-6
ii  libhibernate-validator-java4.3.3-4
ii  libjackson2-jr-java2.9.4-1
ii  liblogback-java1:1.2.3-2
ii  libsambox-java 1.1.19-1
ii  libsejda-eventstudio-java  1.0.6-1
ii  libsejda-injector-java 1.0.2-1
ii  libsejda-java  3.2.38-1
ii  libslf4j-java  1.7.25-3
ii  openjdk-8-jre [java8-runtime]  8u162-b12-1
ii  openjdk-9-jre [java8-runtime]  9.0.4+12-3
ii  openjfx8u141-b14-3

pdfsam recommends no packages.

pdfsam suggests no packages.

-- no debconf information



Bug#894763: libglib2.0-0: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

2018-04-04 Thread Axel Beckert
Hi,

Simon McVittie wrote:
> > This looks like there is a libglib-2.0.so.0 in /lib/arm-linux-gnueabihf/ 
> > that shouldn't be there, and this takes precedence over the more recent
> > one from the Debian package that gets installed to /usr/lib.
> 
> My thoughts exactly. What's that doing there? I would have expected that
> removing the old libglib2.0-0 package would delete that.
> 
> Please try:
> 
> ls -il /lib/arm-linux-gnueabihf/libglib-2.0.so*

6080 lrwxrwxrwx 1 root root 23 Apr  4 09:03 
/lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.4200.1
1563 -rw-r--r-- 1 root root 814280 Nov 13  2014 
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

So while the symlink is rather new (corresponds to the time when I
upgraded the package again to answer your questions, i.e. it seems the
package upgrade time), the libglib-2.0.so.0.4200.1 is rather old on
the other hand. And dpkg doesn't seem to know that file:

$ dpkg -S /lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1
dpkg-query: no path found matching pattern 
/lib/arm-linux-gnueabihf/libglib-2.0.so.0.4200.1

> ls -il /usr/lib/arm-linux-gnueabihf/libglib-2.0.so*

16493 lrwxrwxrwx 1 root root 23 Apr  1 17:59 
/usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0 -> libglib-2.0.so.0.5600.0
 6859 -rw-r--r-- 1 root root 837824 Apr  1 17:59 
/usr/lib/arm-linux-gnueabihf/libglib-2.0.so.0.5600.0

> Since you were seeing these symbol lookup errors while packages are
> being configured,

JFTR: Not only then, also after the apt or aptitude run is finished,
i.e. I still see this:

$ emacs
emacs: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy

> * assorted other packages are configured
>   - in your situation, we fail here and never get further

No. libglib2.0-0 never failed to upgrade or downgrade (in the past few
days). Just some elpa-* packages and it weren't enough to abort the
whole run.

Additionally, I was able to upgrade them successfully after
downgrading libglib2.0-0. Now they are upgraded and I've upgraded
libglib2.0-0 again (without any issues _during_ the upgrade as no
other affected packages were upgraded in the same run) and now Emacs
crashes again as before:

$ emacs
emacs: symbol lookup error: /usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: 
undefined symbol: g_date_copy

As does gio-querymodules:

$ LD_BIND_NOW=1 /usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules
/usr/lib/arm-linux-gnueabihf/glib-2.0/gio-querymodules: symbol lookup error: 
/usr/lib/arm-linux-gnueabihf/libgobject-2.0.so.0: undefined symbol: g_date_copy

> GLib maintainers following testing/unstable wouldn't have seen this
> failure mode, because we would be very likely to be upgrading from a
> version that is recent enough that it already has all the same symbols as
> the one in /lib; but it would be a problem for stretch -> buster upgrades.

JFTR: This is a Debian Sid installation which is usually dist-upgraded
at least every few days since early 2015 or so, i.e. not recently
upgraded from Stretch. There was "stretch" instead of "testing" in the
sources.list until recently, though. Noticed it when I wanted to
downgrade libglib2.0-0 to the version from testing. But fixing this
didn't make any difference as it didn't cause any previously
impossible upgrades or so to show up. And sid was always present in
the sources.list.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#894839: RFS: arptables/0.0.4-1 [ITA]

2018-04-04 Thread Alberto Molina Coballes
Package: sponsorship-requests
Severity: normal

Dear mentors,

I'm adopting arptables and integrating it into the pkg-netfilter
packaging team [0], Arturo Borrero González  
(pkg-netfilter member) intends to sponsor it, but this is my 
first package uploaded to mentors so any comment will be 
appreciated.

* Package name: arptables
  Version : 0.0.4-1
  Upstream Author : Alberto Molina Coballes 
* URL : http://www.netfilter.org
* License : GPL-2
  Section : net

It builds those binary packages:

   arptables  - ARP table administration

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

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

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

 dget -x 
https://mentors.debian.net/debian/pool/main/a/arptables/arptables_0.0.4-1.dsc

Changes since the last upload:

  [ Alberto Molina Coballes ]
  * [9e86b20] New upstream version 0.0.4

  [ Arturo Borrero Gonzalez ]
  * [8d554a1] d/patches: replace 01_Makefile.diff with 
0001-debian-defaults.patch
  * [5f8d185] d/patches: drop 02_manpage.diff
  * [3b3324a] d/patches: drop 03_type.diff
  * [b2d0146] d/patches: drop 04_arptables-save.diff

  [ Alberto Molina Coballes ]
  * [bbe8faf] Modifying debian/copyright according to DEP-5
  * [fec4507] Updating debian/compat to 11
  * [88f65fd] Updating maintainers and adding uploaders (Closes: #891758)
  * [1a66102] Adding VCS-* headers
  * [e87d9dd] Updating Homepage header
  * [84776dc] Updating to debhelper 11
  * [b210e11] Updating Standards-Version to 4.1.3
  * [d8b2837] d/patches: refresh 0001_debian-defaults.patch
  * [6623413] d/watch: updating upstream url

Regards,

Alberto Molina Coballes

[0] https://wiki.debian.org/Teams/pkg-netfilter


Bug#894838: libroboptim-core-dev: Please change dependency from liblog4cxx10-dev to liblog4cxx-dev,

2018-04-04 Thread Tobias Frost
Package: libroboptim-core-dev
Version: 2.0-7.1
Severity: serious

Dear Maintainer,

As I plan to remove the transitional packages from log4cxx, please replace
the dependency to the new packages without the so-name embedded.

As robotim-core is anyway RC-buggy and not in testing, this bug will not delay
the upload of log4cxx, hence the bug is severity serious.

--
tobi

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

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

Versions of packages libroboptim-core-dev depends on:
pn  libboost-all-dev   
pn  libeigen3-dev  
pn  liblog4cxx10-dev   
ii  libltdl-dev2.4.6-2
pn  libroboptim-core2  
ii  pkg-config 0.29-4+b1

libroboptim-core-dev recommends no packages.

Versions of packages libroboptim-core-dev suggests:
pn  libroboptim-core-doc  



Bug#894837: plotdrop FTCBFS: uses build architecture build tools

2018-04-04 Thread Helmut Grohne
Source: plotdrop
Version: 0.5.4-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

plotdrop fails to cross build from source, because its Makefile hard
codes build architecture build tools. It uses bare pkg-config, which is
the build architecture one. dh_auto_build passes a cross $(PKG_CONFIG)
and all the Makefile has to do is pick it up. Furthermore, it uses the
-s option for the install command, which strips using the build
architecture strip. Besides breaking cross compilation, it also breaks
-dbgsym packages, so it is best left to dh_strip. Please consider
applying the attached patch.

Helmut
Index: plotdrop-0.5.4/Makefile
===
--- plotdrop-0.5.4.orig/Makefile
+++ plotdrop-0.5.4/Makefile
@@ -9,9 +9,10 @@
 OBJECTS=main.o gnuplot.o droplist.o
 
 LDFLAGS = 
-LIBS = `pkg-config --libs gtk+-2.0 gio-2.0 glib-2.0 libglade-2.0`
+PKG_CONFIG ?= pkg-config
+LIBS = `$(PKG_CONFIG) --libs gtk+-2.0 gio-2.0 glib-2.0 libglade-2.0`
 CFLAGS = -g -Wall -pedantic -std=c99
-LCFLAGS = `pkg-config --cflags gtk+-2.0 gio-2.0 glib-2.0 libglade-2.0` -DDATADIR="\"$(DATADIR)\"" -DVERSION="\"$(VERSION)\""
+LCFLAGS = `$(PKG_CONFIG) --cflags gtk+-2.0 gio-2.0 glib-2.0 libglade-2.0` -DDATADIR="\"$(DATADIR)\"" -DVERSION="\"$(VERSION)\""
 
 all: $(TARGET)
 
@@ -26,7 +27,7 @@
 
 install: all
 	install -d $(DESTDIR)$(BINDIR) $(DESTDIR)$(DATADIR)
-	install -s $(TARGET) $(DESTDIR)$(BINDIR)
+	install $(TARGET) $(DESTDIR)$(BINDIR)
 	install -m 0644 droplist.glade $(DESTDIR)$(DATADIR)
 	install -d $(DESTDIR)$(PREFIX)/share/applications
 	install -m 0644 plotdrop.desktop $(DESTDIR)$(PREFIX)/share/applications


Bug#720177: `git debrebase` UI

2018-04-04 Thread Sean Whitton
Hello,

Just re-reading our older discussions about the UI, now that I
understand git-debrebase a lot better.

On Sat, Sep 02 2017, Sean Whitton wrote:

> I think that my concerns about failing to leverage user's existing
> understanding of git-rebase(1) can be answered by doing the following:
>
>   - state that git-debrebase(1) is ONLY: a wrapper around git-rebase(1)
> that magically knows the base
>   - have ALL arguments to git-debrebase(1) get passed straight to
> git-rebase(1), i.e., no subsubcommands
>   - move the other functionality (`git debrebase push`, new upstream
> version command) to other subcommands of `git`, e.g. `git
> debpush`, `git debnewupstream` etc.
>
> The point of this is to make it much easier to get a grip on exactly
> what `git debrebase` does.  That is a foundational piece of
> understanding of the workflows surrouding these tools.
>
> It might seem inelegant to have multiple subcommands (especially `git
> debpush` which sounds almost like `dgit push`) but I think that it's a
> price worth paying.  There's also a mnemonic at work: "ah, `git
> debrebase` is a wrapper around `git rebase`, and `git debpush` is a
> wrapper around `git push`".

I think there's still something to this argument against git-debrebase
having subcommands, but it's probably mitigated by the current content
of dgit-maint-debrebase(7).

If we find that users really struggle with grokking the workflow, we
might reconsider splitting out subcommands in the future, after talking
to them and trying to determine whether my hunch in the quoted message
is right.

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#894774: meson fails it's autopkg tests on i386

2018-04-04 Thread Jussi Pakkanen
On Wed, Apr 4, 2018 at 10:25 AM, Matthias Klose  wrote:

> meson fails it's autopkg tests on i386.  simd is not in the base architecture 
> of
> the i386 target, so you probably should skip that test.

There are two things to note here:

1) the test is written so that it compiles all the things that the
compiler supports but then, at runtime, checks what the current
processor supports and runs that. If the current processor does not
have any SIMD support then it falls back to plain C code. The test
should run on every platform and CPU regardless of whether they have
SIMD or not.

2) as part of Meson's release gating, I run the full package build and
tests for Debian using a sid i386 pbuilder (under VMware currently).
The tests have passed on my machine. It does work as expected, at
least under some circumstances.

The question here is why is it failing in Ubuntu. This requires
debugging on the machine in question, roughly:

- install Meson
- cd into meson source root
- meson test\ cases/common/155\ simd builddir
- ninja -C builddir test

And then catting the log file that the test suite runner prints.
(which IIRC we should print in cases of error but for some reason
don't in this case)

You can also try running the test binary directly to see what it does,
it's in builddir/simdtest.



Bug#894836: blktrace FTCBFS: uses the build architecture compiler

2018-04-04 Thread Helmut Grohne
Source: blktrace
Version: 1.1.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

blktrace fails to cross build from source, because it uses the build
architecture compiler. The simplest way to fix this is using
dh_auto_build. After doing so, blktrace cross builds successfully. The
attached patch also fixes a build/host confusion. Please consider
applying it.

Helmut
diff --minimal -Nru blktrace-1.1.0/debian/changelog 
blktrace-1.1.0/debian/changelog
--- blktrace-1.1.0/debian/changelog 2015-05-17 14:35:07.0 +0200
+++ blktrace-1.1.0/debian/changelog 2018-04-04 19:51:58.0 +0200
@@ -1,3 +1,12 @@
+blktrace (1.1.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ Fix build/host confusion.
+
+ -- Helmut Grohne   Wed, 04 Apr 2018 19:51:58 +0200
+
 blktrace (1.1.0-2) unstable; urgency=low
 
   * Upload to unstable.
diff --minimal -Nru blktrace-1.1.0/debian/rules blktrace-1.1.0/debian/rules
--- blktrace-1.1.0/debian/rules 2015-03-25 08:18:15.0 +0100
+++ blktrace-1.1.0/debian/rules 2018-04-04 19:51:56.0 +0200
@@ -2,7 +2,7 @@
 
 #export DH_VERBOSE=1
 
-#DEB_BUILD_ARCH_OS   ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS  )
+include /usr/share/dpkg/architecture.mk
 
 CFLAGS += -Wall -Wextra -Wno-shadow -g
 
@@ -16,7 +16,7 @@
dh $@
 
 override_dh_auto_build:
-ifeq ($(DEB_BUILD_ARCH_OS),linux)
+ifeq ($(DEB_HOST_ARCH_OS),linux)
# Building for a Linux-type OS, everything's fine
#
# variables are:
@@ -26,13 +26,13 @@
 else

## Oops, it seems you are trying to build blkutils
-   ## for a non-Linux OS `$(DEB_BUILD_ARCH_OS)'.
+   ## for a non-Linux OS `$(DEB_HOST_ARCH_OS)'.
## This is not supported.
## Please file a bug if you think this is wrong.

false
 endif
-   $(MAKE) CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)" all docs
+   dh_auto_build -- CFLAGS="$(CPPFLAGS) $(CFLAGS) $(LDFLAGS)" all docs
 
 override_dh_auto_install:
$(MAKE) install \


Bug#877040: [Pkg-mozext-maintainers] Bug#877040: New upstream version, including transition to webext

2018-04-04 Thread Sean Whitton
Hello,

On Wed, Apr 04 2018, Michael Meskes wrote:

> As a first step I would love to see us migrate to salsa. The current git
> structure is different from what I usually use, so I have to dig into that.

README.source has some details but please feel free to ask me any
questions, since I came up with that structure (a long time ago..).

-- 
Sean Whitton


signature.asc
Description: PGP signature


Bug#894510: debhelper: Because it is listing tmpfiles in systemd's only, conf overriding is not working

2018-04-04 Thread Niels Thykier
Hi,

@Michael/@Felipe: Could you have a look at this bug ?

On Sat, 31 Mar 2018 08:58:21 -0700 Seyeong Kim
 wrote:
> Package: debhelper
> Version: 9.20160115ubuntu3
> Severity: normal
> Tags: d-i
> 
> In autoscripts/postinst-init-tmpfiles, There is TMPFILE containing conf in 
> systemd pkg only.
> Then if there is 00rsyslog.conf from rsyslog pkg. and installing or upgrading 
> systemd
> 
> /var/log's permission is 755(which is default) not 775(which is in 
> 00rsyslog.conf)
> overriding doesn't work when upgrading.
> 
> Please refer to below LP
> ubuntu lp bug : https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1748147
> 
> removing TMPFILE from autoscripts/postinst-init-tmpfiles solves this issue.
> e.g. change like below
> systemd-tmpfiles --create #TMPFILES# >/dev/null || true
> to
> systemd-tmpfiles --create >/dev/null || true
> 
> and removing related code from dh_installinit maybe needed
> e.g. below kind of part
> if (compat(10) && !$dh{NOSCRIPTS}) {
> # Include postinst-init-tmpfiles if the package ships any 
> files
> # in /usr/lib/tmpfiles.d or /etc/tmpfiles.d
> my @tmpfiles;
> find({
> wanted => sub {
> my $name = $File::Find::name;
> return unless -f $name;
> $name =~ s/^\Q$tmp\E//g;
> if ($name =~ m,^/usr/lib/tmpfiles\.d/, ||
> $name =~ m,^/etc/tmpfiles\.d/,) {
> push @tmpfiles, $name;
> }
> },
> no_chdir => 1,
> }, $tmp);
> if (@tmpfiles > 0) {
> autoscript($package,"postinst", 
> "postinst-init-tmpfiles",
> "s,#TMPFILES#," . join(" ", sort 
> @tmpfiles).",g");
> }
> }
> 
> Is there any reason that TMPFILE list is there? 
> 
> [...]

Thanks,
~Niels



  1   2   3   >