Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

[殷啟聰 | Kai-Chung Yan]

I removed the javadoc package now and it builds find in Sid. Shall I upload it 
right now?

(I still need the upload permission)



signature.asc
Description: OpenPGP digital signature

Bug#893547: ant: please do not emit --ignore-source-errors on Java 9

[tony mancill]

On Tue, Mar 20, 2018 at 08:51:32AM +0100, Ole Streicher wrote:

Hello Ole,

> On 20.03.2018 05:20, tony mancill wrote:
> > I'm in the midst of preparing an update for ant.  Is there any context
> > in which we want to add "--ignore-source-errors" to the ant javadoc
> > task, or should this patch [1] be removed entirely?
> >
> 
> I am not familar with ant, so I can't recommend here. The failure seems
> to not generally appear, but only on specific targets.
> 
> This is the snippet that produces the error:
> 
>       docletpathref="classpath"
>  failonerror="true"
>  public="true"
>  additionalparam="-headings"
>  destdir="${build.javadocs}"
>  sourcepath="${java.dir}"
>  packagenames="uk.ac.starlink.ttools.func"
>  classpathref="classpath"
>  encoding="cp1252"/>
> 
> while this one (from another package, starjava-pal) works fine:
> 
>       destdir="${dist.javadocs}"
>  author="true"
>  version="true"
>  locale="en"
>  windowtitle="${Name} API"
>  doctitle="${Name}"
>  defaultexcludes="yes"
>  source="${source.version}"
>  classpathref="classpath">
> 
> So, it may have something to do with the doclet.

You're definitely onto something here - thank you for the research.  I
enabled debug logging for maven and built checkstyle to get the full
invocation of javadoc command that fails, and it also uses doclet.

If I run those same command arguments sans the options related to doclet
(-doclet, -docletpath, and -destfile), but still including
--ignore-source-errors, and the javadoc invocation is successful.

So, the bug seems to belong to the JDK and not to ant, very possibly in
here [1].  I haven't tracked it down entirely yet, but I can reproduce
the same behavior with --dump-on-error, which is another "HIDDEN"
option.  I think ToolOption.get() [2] probably returns null (because the
option is hidden) and so we end up here [3], passing false for
isToolOption to handleDocletOptions() when we need for it to be true.
Perhaps the developer who added --ignore-source-errors and
--dump-on-error didn't realize that the parser can't handle hidden
options that don't start with '-XD'?

In any event, that's all based on static analysis of the code.  It'll
take me a bit of time to verify and come up with a patch for the JDK.

In the meantime, I don't know how many FTBFS problems it might cause if
we reverted the --ignore-source-errors patch from ant, so I'm not sure
whether we should change the current behavior or not.

Cheers,
tony

[1] 
https://github.com/dmlloyd/openjdk/blob/zlib-bytebuffer-v9/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java#L795-L820

[2] 
https://github.com/dmlloyd/openjdk/blob/zlib-bytebuffer-v9/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java#L795-L796

[3] 
https://github.com/dmlloyd/openjdk/blob/zlib-bytebuffer-v9/src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/Start.java#L819-L820


signature.asc
Description: PGP signature

Bug#893680: gitaly: arch-dep-package-has-big-usr-share

[Dmitry Smirnov]

Package: gitaly
Version: 0.91.0+debian-1
Severity: important

"gitaly" is not a -dev package therefore it should not install
"usr/share/gocode" folder with all its sources and vendored deps.

All the best,
 Dmitry Smirnov.

---

If liberty means anything at all, it means the right to tell people what
they do not want to hear.
-- George Orwell


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

Bug#893679: searx: incorrect Homepage, should be https://asciimoo.github.io/searx/

[Paul Wise]

Source: searx
Version: 0.14.0+dfsg1-2
Severity: minor

The Homepage is the git repository, it should be this instead:

https://asciimoo.github.io/searx/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#893510: cinnamon: applications are gone from menu

[Norbert Preining]

retitle 893510 menu breaks when a desktop file has encoding problems
thanks

> at least I don't have *any* entry anymore in the start menu, see
> attached screenshot.

The reason was a desktop file that had the *filename* encoding messed
up. Removing or renaming the file to proper encoding fixed the issue.

cinnamon-menu should not die on a wrongly encoded filename, but skip it.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#893678: gesftpserver: drop unused Build-Depends: python-paramiko

[Helmut Grohne]

Source: gesftpserver
Version: 0.2.2-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gesftpserver Build-Depends on python-paramiko, but does not actually use
it. Its source (including test suite) does not reference it.
Furthermore, one can validate with reproducible builds that the only
difference is the buildinfo file created by dh-buildinfo. I suggest that
you drop dh-buildinfo as the .buildinfo files created by dpkg serve the
same purpose. The python-paramiko dependency happens to be problematic
for cross building.

Helmut
diff --minimal -Nru gesftpserver-0.2.2/debian/changelog 
gesftpserver-0.2.2/debian/changelog
--- gesftpserver-0.2.2/debian/changelog 2017-01-24 16:05:34.0 +0100
+++ gesftpserver-0.2.2/debian/changelog 2018-03-21 05:50:49.0 +0100
@@ -1,3 +1,10 @@
+gesftpserver (0.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused python-paramiko dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 21 Mar 2018 05:50:49 +0100
+
 gesftpserver (0.2.2-1) unstable; urgency=medium
 
   [ upstream ]
diff --minimal -Nru gesftpserver-0.2.2/debian/control 
gesftpserver-0.2.2/debian/control
--- gesftpserver-0.2.2/debian/control   2017-01-24 15:58:12.0 +0100
+++ gesftpserver-0.2.2/debian/control   2018-03-21 05:50:49.0 +0100
@@ -9,7 +9,6 @@
  dh-buildinfo,
  libreadline-dev,
  python,
- python-paramiko,
  dh-autoreconf
 Standards-Version: 3.9.8
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/gesftpserver.git
diff --minimal -Nru gesftpserver-0.2.2/debian/rules 
gesftpserver-0.2.2/debian/rules
--- gesftpserver-0.2.2/debian/rules 2017-01-24 16:05:34.0 +0100
+++ gesftpserver-0.2.2/debian/rules 2018-03-21 05:50:49.0 +0100
@@ -24,7 +24,7 @@
 CDBS_BUILD_DEPENDS += , libreadline-dev
 
 # Needed by upstream regresssion testing
-CDBS_BUILD_DEPENDS += , python, python-paramiko
+CDBS_BUILD_DEPENDS += , python
 
 # Preserve upstream shipped cruft
 DEB_CLEAN_EXCLUDE = tests/truncate6~

Bug#893677: nomacs uses the wrong config folder

[robert]

Package: nomacs
Version: 3.8.0+dfsg-4
Severity: normal
Tags: upstream

Dear Maintainer,

I think until LXQt 0.12.0 nomacs has used "~/.config/nomacs/Image Lounge.conf"
for it's config, and I was able to set a system wide config under
"/etc/xdg/nomacs/Image Lounge.conf", and this is how I understand that it
should be.

Now nomacs uses "~/.local/share/nomacs/settings.ini" for it's config and I am
not sure about the system wide config.

Even if the name of the config file has changed from "Image Lounge.conf" to
"settings.ini", I think the correct location for the config should be
"$XDG_CONFIG_HOME/nomacs" for the user config and "/etc/xdg/nomacs" for the
system wide config?

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-1-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 nomacs depends on:
ii  libc6  2.27-2
ii  libexiv2-140.25-3.1
ii  libgcc11:8-20180312-2
ii  libopencv-core3.2  3.2.0+dfsg-4+b4
ii  libopencv-imgproc3.2   3.2.0+dfsg-4+b4
ii  libqt5concurrent5  5.9.2+dfsg-12
ii  libqt5core5a   5.9.2+dfsg-12
ii  libqt5gui5 5.9.2+dfsg-12
ii  libqt5network5 5.9.2+dfsg-12
ii  libqt5printsupport55.9.2+dfsg-12
ii  libqt5svg5 5.9.2-3
ii  libqt5widgets5 5.9.2+dfsg-12
ii  libquazip5-1   0.7.3-5
ii  libraw16   0.18.8-2
ii  libstdc++6 8-20180312-2
ii  libtiff5   4.0.9-4
ii  qt5-image-formats-plugins  5.9.2-2

Versions of packages nomacs recommends:
ii  nomacs-l10n  3.8.0+dfsg-4

nomacs suggests no packages.

-- no debconf information

Bug#893676: hurd: internal compiler error building petsc

[Drew Parsons]

Package: gcc-7
Version: 7.3.0-12
Severity: normal
Tags: upstream

The build of PETSc 3.8 triggers an internal compiler error on hurd:

CC i386-gnu-complex/obj/src/vec/vec/interface/vector.o
  ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <= 
((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
  /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c: In function 
'VecSetInf':
  /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c:1860:1: 
internal compiler error: Aborted
   }

see https://buildd.debian.org/status/logs.php?pkg=petsc=hurd-i386
or
https://buildd.debian.org/status/fetch.php?pkg=petsc=hurd-i386=3.8.3%2Bdfsg1-7=1521574559=0



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

Bug#893675: mark python-isodate Multi-Arch: foreign

[Helmut Grohne]

Package: python-isodate
Version: 0.6.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:ardour

ardour cannot be cross built from source, because its build dependency
on python-isodate is unsatisfiable. In general, Architecture: all
packages can never satisfy cross Build-Depends unless marked Multi-Arch:
foreign. In this case, all dependencies are either annotated :any or
marked Multi-Arch: foreign themselves. The maintainer scripts create
architecture-dependent (.pyc) files, but for most parts that can be
considered a detail as their architecture will match the python
interpreter package. Just for foreign embedded python interpreters their
architecture may be wrong and even then, python-isodate will continue to
work albeit with slower startup. I think that's a reasonable trade-off
and thus ask for marking the package.

Helmut
diff --minimal -Nru isodate-0.6.0/debian/changelog 
isodate-0.6.0/debian/changelog
--- isodate-0.6.0/debian/changelog  2018-01-04 21:21:23.0 +0100
+++ isodate-0.6.0/debian/changelog  2018-03-21 05:40:32.0 +0100
@@ -1,3 +1,10 @@
+isodate (0.6.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark all packages Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 21 Mar 2018 05:40:32 +0100
+
 isodate (0.6.0-1) sid; urgency=medium
 
   * Bump Standards-Version to 4.1.3.
diff --minimal -Nru isodate-0.6.0/debian/control isodate-0.6.0/debian/control
--- isodate-0.6.0/debian/control2018-01-04 21:21:23.0 +0100
+++ isodate-0.6.0/debian/control2018-03-21 05:40:13.0 +0100
@@ -16,12 +16,14 @@
 
 Package: python-isodate
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, ${python:Depends}
 Description: ISO 8601 date/time/duration parser and formatter (Python module)
  This Python module implements ISO 8601 date, time and duration parsing.
 
 Package: python3-isodate
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}, ${python3:Depends}
 Description: ISO 8601 date/time/duration parser and formatter (Python 3 module)
  This Python 3 module implements ISO 8601 date, time and duration parsing.

Bug#893674: eris: further symbol adjustments for gcc7+ppc64el+-O3

[Steve Langasek]

Package: eris
Version: 1.3.23-6
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear maintainers,

The latest version of eris fails to build on ppc64el in Ubuntu, because
Ubuntu builds with -O3 by default on ppc64el, resulting in some symbols file
mismatches.

All of the added/removed symbols look safe to mark as optional, so I've
applied the attached patch in Ubuntu.  Please consider including it in
Debian as well.

-- 
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 eris-1.3.23/debian/liberis-1.3-21.symbols 
eris-1.3.23/debian/liberis-1.3-21.symbols
--- eris-1.3.23/debian/liberis-1.3-21.symbols   2017-12-31 17:59:13.0 
-0800
+++ eris-1.3.23/debian/liberis-1.3-21.symbols   2018-03-20 21:35:26.0 
-0700
@@ -44,7 +44,9 @@
  _ZN4Eris10ServerInfoD1Ev@Base 1.3.19
  _ZN4Eris10ServerInfoD2Ev@Base 1.3.19
  
_ZN4Eris10SpawnPointC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorINS_13CharacterTypeESaISA_EES8_@Base
 1.3.23
+ (optional)_ZN4Eris10SpawnPointC1ERKS0_@Base 1.3.19
  
_ZN4Eris10SpawnPointC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt6vectorINS_13CharacterTypeESaISA_EES8_@Base
 1.3.23
+ (optional)_ZN4Eris10SpawnPointC2ERKS0_@Base 1.3.19
  _ZN4Eris10SpawnPointD1Ev@Base 1.3.19
  _ZN4Eris10SpawnPointD2Ev@Base 1.3.19
  _ZN4Eris10ViewEntity11onTaskAddedEPNS_4TaskE@Base 1.3.19
@@ -776,7 +778,7 @@
  
(optional=GCC7_removed)_ZNSt6vectorIdSaIdEE19_M_emplace_back_auxIJdEEEvDpOT_@Base
 1.3.23
  
(optional=GCC7_added)_ZNSt6vectorIdSaIdEE17_M_realloc_insertIJdEEEvN9__gnu_cxx17__normal_iteratorIPdS1_EEDpOT_@Base
 1.3.23-6~
  _ZNSt6vectorIdSaIdEEaSERKS1_@Base 1.3.19
- _ZNSt7__cxx1110_List_baseIN4sigc9slot_baseESaIS2_EE8_M_clearEv@Base 1.3.23
+ (optional)_ZNSt7__cxx1110_List_baseIN4sigc9slot_baseESaIS2_EE8_M_clearEv@Base 
1.3.23
  
_ZNSt7__cxx1110_List_baseINS_12basic_stringIcSt11char_traitsIcESaIcEEESaIS5_EE8_M_clearEv@Base
 1.3.23
  _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED0Ev@Base 1.3.23
  _ZNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEED1Ev@Base 1.3.23
@@ -861,7 +863,7 @@
  
(optional=certain_64b_arches)_ZNSt8_Rb_treeIPN4Eris8TypeInfoES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS2_ERKS2_@Base
 1.3.21
  
_ZNSt8_Rb_treeIPN4Eris8TypeInfoES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE7_M_copyINS8_11_Alloc_nodeEEEPSt13_Rb_tree_nodeIS2_EPKSC_PSt18_Rb_tree_node_baseRT_@Base
 1.3.23
  
_ZNSt8_Rb_treeIPN4Eris8TypeInfoES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E@Base
 1.3.19
- 
_ZNSt8_Rb_treeIPN4Eris9MetaQueryES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE16_M_insert_uniqueIRKS2_EESt4pairISt17_Rb_tree_iteratorIS2_EbEOT_@Base
 1.3.23
+ 
(optional)_ZNSt8_Rb_treeIPN4Eris9MetaQueryES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE16_M_insert_uniqueIRKS2_EESt4pairISt17_Rb_tree_iteratorIS2_EbEOT_@Base
 1.3.23
  
_ZNSt8_Rb_treeIPN4Eris9MetaQueryES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E@Base
 1.3.19
  
(optional=inline)_ZNSt8_Rb_treeIiSt4pairIKiPN4Eris12ResponseBaseEESt10_Select1stIS5_ESt4lessIiESaIS5_EE24_M_get_insert_unique_posERS1_@Base
 1.3.21
  
(optional=certain_64b_arches)_ZNSt8_Rb_treeIiSt4pairIKiPN4Eris12ResponseBaseEESt10_Select1stIS5_ESt4lessIiESaIS5_EE29_M_get_insert_hint_unique_posESt23_Rb_tree_const_iteratorIS5_ERS1_@Base
 1.3.21

Bug#892664: dpkg: Please add support for zstd (Zstandard) compressed packages

[Guillem Jover]

On Sun, 2018-03-18 at 04:38:15 +0100, Guillem Jover wrote:
> Thanks. I started implementing this several weeks ago after having
> discussed it with Julian Andres Klode on IRC, but stopped after seeing
> the implementation getting messy given the current code structure.

> In any case, as I mentioned on IRC to Andres, this is something I
> pondered about already in 2016, when Paul Wise blogged about it, and
> which I also told Andres about at the time when he was adding lz4
> support to apt. :) But parked it for later as there were several
> apparent problems with it at the time.

Err, obviously s/Andres/Julian/.

Sorry,
Guillem

Bug#893673: clirr: missing binary wrapper

[nkiesel]

Package: clirr
Version: 0.6-6
Severity: grave
Justification: renders package unusable

Dear Maintainer,

the actual binary (or shell script wrapper) for running `clirr` is missing from
the package, and a naive `java -jar /usr/share/java/clirr.jar` does not work
either.



-- 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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clirr depends on:
ii  default-jre [java7-runtime]2:1.8-59
ii  java-wrappers  0.2
ii  libbcel-java   6.2-1
ii  libcommons-cli-java1.4-1
ii  libcommons-lang-java   2.6-7
ii  openjdk-8-jre [java7-runtime]  8u162-b12-1
ii  openjdk-9-jre [java7-runtime]  9.0.4+12-2

clirr recommends no packages.

clirr suggests no packages.

-- no debconf information

Bug#893671: RFP: pubs -- command line bibliography management tool

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: pubs
  Version : 0.7.0
  Upstream Author : Fabien Benureau, Olivier Mangin
* URL : https://github.com/pubs/pubs
* License : LGPL-3.0
  Programming Lang: Python
  Description : command line bibliography management tool

Pubs organizes your bibliographic documents together with the
bibliographic data associated to them and provides command line access
to basic and advanced manipulation of your library.

Pubs is built with the following principles in mind:

 * all papers are referenced using unique citation keys,
 
 * bibliographic data (i.e. pure bibtex information) is kept separated
   from metadata (including links to pdf or tags),
   
 * everything is stored in plain text so it can be manually edited or
   version controlled.

Pubs can also import/export to/from bibtex and supports fetching
metdata from ISBN or DOI numbers.

--

I tested this from pip and it looks really nice. Might be a viable
alternative to the problems with packaging Zotero, although it is much
less intuitive for non-commandline users...

Its requirements:

 * beautifulsoup4
 * bibtexparser
 * configobj
 * date-utils
 * pyyaml
 * requests
 * future
 * pyparsing
 * six
 * urllib3
 * idna
 * chardet
 * certifi

All of those seem available in Debian with reasonable versions, so no
extra work required there.

I do not plan on maintaining this just yet, just a heads up that this
package exists and might be interesting to fellow
journalists/academics. I'd be happy to help with sponsorship and this
might better live in the python apps team.

Bug#893397: adapt the cron scripts to use http:// instead of ftp://

[Paul Wise]

On Tue, Mar 20, 2018 at 10:55 PM, Osamu Aoki wrote:

> apt-get has -C option to use non-standard /etc/apt/sources.list
> listing unstable distribution:

This is the wrong way to completely override the system apt
configuration. The right way is to set the APT_CONFIG environment
variable. See the apt.conf(5) manual page, APT_CONFIG is the first
method that apt uses to find the config file and the -C command-line
option is the very last one so it cannot prevent loading all the
system config. The chdist tool (from devscripts), the apt-venv package
and the derivatives census code get this correct.

I definitely agree that apt-get could be used to download packages
from repositories, especially since it will verify hashes and
signatures.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#893670: autoremovals: version info is no longer displayed

[Paul Wise]

Package: tracker.debian.org
Severity: normal

In the autoremovals detail for josm I see this message:

  Version of openjfx is marked for autoremoval from testing...

The template includes a version number but the text above does not:

  $ grep 'Version.*of' 
distro_tracker/vendor/debian/templates/debian/autoremoval-action-item.html
  Version {{ item.extra_data.version }} of {{ item.package.name }} is 
marked for autoremoval from testing on {{ item.extra_data.removal_date }}. 


The autoremovals information does include the version number:

  $ curl -s https://udd.debian.org/cgi-bin/autoremovals.yaml.cgi | grep -A1 
'source: josm'
source: josm
version: 0.0.svn13500+dfsg-1

I'm guessing that the code importing this isn't working correctly.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#893669: autoremovals: display the package that is triggering the removal

[Paul Wise]

Package: tracker.debian.org
Severity: wishlist
Tags: newcomer

Currently on the josm page it says:

 Marked for autoremoval on 19 April: 850921

If another package is triggering the removal it would be nice to
indicate which packages are causing the removal. This information is
already present in the details but needs adding to the summary. When
the package itself is causing the autoremoval, the message should stay
the same. I suggest this wording for the additional information:

 Marked for autoremoval on 19 April due to openjfx: #850921

https://tracker.debian.org/pkg/josm

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#893668: adminer: CVE-2018-7667

[Chris Lamb]

Package: adminer
Version: 4.2.5-3
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

the following vulnerability was published for adminer.

CVE-2018-7667[0]:
| Adminer through 4.3.1 has SSRF via the server parameter.

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


Regards,

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

Bug#893052: RFS: btrfsmaintenance/0.4.1-1 [I maintain the package]

[Nicholas D Steeves]

Hi Sven,

On Sat, Mar 17, 2018 at 08:06:13PM +0100, Sven Hoexter wrote:
> Hi,
> uploaded the package. I've to make up my mind about the kind of linux specific
> arch all packaging stuff.
> 
> Sven

Thank you for sponsoring this upload :-)

Should I leave filing a wishlist bug against dpkg-dev, for the
creation of an arch: linux-all to you, or go ahead and do it myself?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#893667: DDPO: Debian Maintainer [DM] indicators: add to title who allowed the DM to upload the package

[Paul Wise]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org
Usertags: ddpo

It would be nice to add the name of the person allowed the DM to upload
the package in the title attribute of the [DM] indicators on DDPO.

The indicators currently look like this in the DDPO HTML:

[DM]

The indicator could be changed to this:

[DM]

or possibly this so that the info source is obvious: 

[https://ftp-master.debian.org/dm.txt;>DM]

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#893572: tracker.debian.org: Debian Maintainer display: [dm] links empty, should be uppercase and use parentheses

[Paul Wise]

On Tue, 20 Mar 2018 07:25:35 +0800 Paul Wise wrote:

> I think these changes are needed:

It would also be nice to have info on who approved the package.

> Here is how these changes should look in the HTML:

Updated version:


(https://ftp-master.debian.org/dm.txt;>DM)


-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#878910: [patch] change suggests btrfs-tools to btrfs-progs

[Nicholas D Steeves]

Hi Axel,

On Wed, Mar 21, 2018 at 02:40:04AM +0100, Axel Beckert wrote:
> Hi Nicholas,
> 
> Nicholas D Steeves wrote:
> > [...], I noticed this bug was still open.  Has
> > 
> > - btrfs-tools
> > + btrfs-progs | btrfs-tools
> > 
> > been fixed in git yet?
> 
> It's fixed in git, yes:
> https://github.com/xen-tools/xen-tools/commit/6485f686b76b4b840db5ab7c0312e7d2dbec4c38
> 
> I just haven't come around doing a new release.

Thank you for the update :-)  No rush for a new release!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#878910: [patch] change suggests btrfs-tools to btrfs-progs

[Axel Beckert]

Hi Nicholas,

Nicholas D Steeves wrote:
> [...], I noticed this bug was still open.  Has
> 
> - btrfs-tools
> + btrfs-progs | btrfs-tools
> 
> been fixed in git yet?

It's fixed in git, yes:
https://github.com/xen-tools/xen-tools/commit/6485f686b76b4b840db5ab7c0312e7d2dbec4c38

I just haven't come around doing a new release.

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#893598: yasnippet-snippets: Error while updating

[Nicholas D Steeves]

Control: severity -1 serious

Marking serious to prevent migration to testing.

Good news Harald and Axel!

0~git20150512-1 to 0~git20161123-1 or any newer version require a
bunch of symlink_to_dir entries in a maintscript.  Fixed in git
@commit:66ae69a ; however, I will not upload immediately, because
yasnippet-snippets might also need to register with package.el (ELPA),
because Elpy (not yet uploaded) is in the process of upstreaming their
snippets...after I hear back from the pkg-emacsen team I'll upload without 
delay.

Thank you again for reporting this bug and for your help tracking down
what was triggering it :-)

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#893666: bind9-host: invalid results for -t ANY/NS

[John Runyon]

Package: bind9-host
Version: 1:9.11.2.P1-1
Severity: normal

host is giving invalid results for some queries, for example the below. It is 
likely worth noting that I do have a searchdomain configured, though I also 
included the "null label" in these examples, so it shouldn't be interpreting 
searchdomains anyway.
Running without directly specifying the nameserver to query ("host -t NS com.") 
DOES work.


$ host -t NS com. a.root-servers.net
Using domain server:
Name: a.root-servers.net
Address: 2001:503:ba3e::2:30#53
Aliases:

com has no NS record



$ host -t NS -v com. a.root-servers.net
Trying "com"
Using domain server:
Name: a.root-servers.net
Address: 2001:503:ba3e::2:30#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41664
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 12

;; QUESTION SECTION:
;com.   IN  NS

;; AUTHORITY SECTION:
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.

;; ADDITIONAL SECTION:
e.gtld-servers.net. 172800  IN  A   192.12.94.30
e.gtld-servers.net. 172800  IN  2001:502:1ca1::30
b.gtld-servers.net. 172800  IN  A   192.33.14.30
b.gtld-servers.net. 172800  IN  2001:503:231d::2:30
j.gtld-servers.net. 172800  IN  A   192.48.79.30
j.gtld-servers.net. 172800  IN  2001:502:7094::30
m.gtld-servers.net. 172800  IN  A   192.55.83.30
m.gtld-servers.net. 172800  IN  2001:501:b1f9::30
i.gtld-servers.net. 172800  IN  A   192.43.172.30
i.gtld-servers.net. 172800  IN  2001:503:39c1::30
f.gtld-servers.net. 172800  IN  A   192.35.51.30
f.gtld-servers.net. 172800  IN  2001:503:d414::30

Received 509 bytes from 2001:503:ba3e::2:30#53 in 6 ms


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

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
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: sysvinit (via /sbin/init)

Versions of packages bind9-host depends on:
ii  libbind9-160  1:9.11.2.P1-1
ii  libc6 2.27-2
ii  libcap2   1:2.25-1.2
ii  libcomerr21.44.0-1
ii  libdns169 1:9.11.2.P1-1
ii  libgeoip1 1.6.12-1
ii  libgssapi-krb5-2  1.16-2
ii  libisc166 1:9.11.2.P1-1
ii  libisccfg160  1:9.11.2.P1-1
ii  libjson-c30.12.1-1.3
ii  libk5crypto3  1.16-2
ii  libkrb5-3 1.16-2
ii  liblmdb0  0.9.21-1
ii  liblwres160   1:9.11.2.P1-1
ii  libssl1.1 1.1.0g-2
ii  libxml2   2.9.4+dfsg1-6.1

bind9-host recommends no packages.

bind9-host suggests no packages.

-- no debconf information

Bug#878910: [patch] change suggests btrfs-tools to btrfs-progs

[Nicholas D Steeves]

Hi Axel,

On Tue, Oct 17, 2017 at 08:23:21PM +0200, Axel Beckert wrote:
> Control: tag -1 + confirmed
> 
> Hi Nicholas,
> 
> Nicholas D Steeves wrote:
> > Trivial fix for renamed package.
> 
> Thanks for the bug report and patch!
> 
> > It sounds like btrfs-tools (transitional dummy package) will be
> > present in buster, so this can be put off until buster+1.
> 
> Putting off until buster+1 doesn't make sense, even if the
> transitional package might be present.
> 
> But since I prefer to keep xen-tools installable on older releases,
> too, I'll probably use "btrfs-progs | btrfs-tools".

While searching old bugs for a symlink-to-folder patch I submitted for
another package that will be useful in fixing the yasnippet-snippet
upgrade error, I noticed this bug was still open.  Has

- btrfs-tools
+ btrfs-progs | btrfs-tools

been fixed in git yet?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#893665: smartmontools: smartd doesn't notify newly added devices afters start

[Christoph Anton Mitterer]

And a further problem:

Once smartd monitors a removable device... it spits out errors (that it
cannot open it) just because the device was removed.

This would also be solved by some proper add/remove handling of
removable devices.

Cheers,
Chris.

Bug#893511: gnome-core: "Slow keys" a11y shortcut being spuriously triggered

[George Bateman]

The bug you reference seems to refer only to keyboard issues. While
that may be part of the problem, it's also concerning that the
accessibility shortcuts' "Enable by keyboard" option is broken;
presumably that's unrelated to
https://gitlab.gnome.org/GNOME/mutter/issues/74?

Many thanks,
George.

Bug#893665: smartmontools: smartd doesn't notify newly added devices afters start

[Christoph Anton Mitterer]

Package: smartmontools
Version: 6.5+svn4324-1
Severity: important


Hi.

It seems that smartd, even with a configuration like:
DEVICESCAN -d auto -d removable  …
(i.e. similar or equal to the default config in Debian), doesn't
detect devices which are added after (i.e. removable
devices) the daemon was started.

Example:
1) Start smartd (respectively it runs from system boot)
   It "sees" my internal SSD.
2) I add an external HDD via USB-SATA-bridge.
   The USB-SATA-bridge I'm using requires no special smartmontools
   config, i.e. smartctl --all /dev/sdX works out of the box.

Now even if I wait for the default of 1800s (after which it would
"check" again) it doesn't *not* take note of the new device and
add it to the monitored ones.

Only if I SIGHUP the daemon, it will actually see and add it.


So the first problem here is that smartd never seems to scan
for new devices on it's own.

Even if it would, that would IMO not really solve the problem, as
a maximum of 30 min (assuming the default interval) is probably too
long to take note of SMART issues.
Mostly because it can easily happen that an external device isn't
even connected for so long (e.g. I just connect it to get some data
on it and then I remove it again).


I also think, that sending SIGHUP automatically (e.g. via some cron job
or systemd timer) is not really the best solution, as it would also cause
the config to be read in again (which may be just edited).


The best thing would probably be if udev or systemd could somehow
magically inform smartd when a new device is added (ideally without
the later reading in the configs again).
Then, smartd could immediately make a first check, thus the device would
get checked even if it was removed again before the 30 mins.


One word of caution though:
IMO it would be bad, if any cron/systemd/udev solution would actually
start smartd.
If one does e.g. digital forensics and intentionally stops smartd.serice
in order to prevent any SMART commands being run on devices... it shouldn't
come back by itself ;-)


Thanks,
Chris.

Bug#893397: adapt the cron scripts to use http:// instead of ftp://

[Osamu Aoki]

Hi,

On Tue, Mar 20, 2018 at 11:55:01PM +0900, Osamu Aoki wrote:
> What you did is one way ;-)
> 
> On Mon, Mar 19, 2018 at 03:27:25PM +0100, Laura Arjona Reina wrote:
...
> > pattern specified with -A. Maybe there is a more efficient way to do this?
> 
> Most wgetfiles are downloading the latest unstable binary packages.
> Why re-invent the binary package downloader when we have "apt-get"?
> 
> apt-get has -C option to use non-standard /etc/apt/sources.list
> listing unstable distribution:
> 
> deb http://deb.debian.org/debian/ sid main contrib non-free
> 
> We need to use non-standard directories and not to contaminate the
> system ones:
>   /var/cache/apt/archives/
>   /var/lib/apt/lists/
> 
> This can be done by setting through
>   Item: Dir::Cache::Archives
>   Item: Dir::State::Lists
> specified via -o option.
> 
> By setting all these and few more options as needed, we should be
> able to download the latest binary package from the archive using the
> proven tool.

Just to be clear, I was thinking to do the following to get the latest
binary package in the previous post:

 apt-get update
 apt-get -d install $PACKAGENAME

Then go to redirected /var/cache/apt/archives/ location to pick up the
latest package.

This is just an outline.  There may needs to do few more chores to get
this working.

> Of course, obsolete dpkg-doc from snapshot should use original wgetfiles
> 
> Installation guide: I need to check how it should be handled.
> 
> What do you think?
> 
> Regards,
> 
> Osamu
> 

Bug#883410: linux-image-4.14.0-1-amd64: Enable zstd support for SquashFS in 4.14

[Norbert Lange]

I second this wish,

and would further ask to enable CONFIG_SQUASHFS_FILE_DIRECT, as this
will improve performance.
The "downside" would be that with a bottleneck removed, more IO can
then mean more CPU Resources are used by the kernel (though I don't
see that a downside, just means some threads using IO are finished
earlier, performance still is up). see
https://lkml.org/lkml/2017/9/22/814

Bug#893664: sambamba: Fails to build on i386

[Jeremy Bicha]

Source: sambamba
Version: 0.6.7-1
Severity: serious

sambamba fails to build from source on i386:

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

Thanks,
Jeremy Bicha

Bug#893598: [Pkg-emacsen-addons] Bug#893598: Bug#893598: yasnippet-snippets: Error while updating

[Nicholas D Steeves]

On Tue, Mar 20, 2018 at 06:53:15PM -0400, Nicholas D Steeves wrote:
> Control: tags -1 confirmed
> 
> Hi Axel,
> 
> Thank you for confirming this bug!
> 
> On Tue, Mar 20, 2018 at 10:44:34PM +0100, Axel Beckert wrote:
> > Hi Nicholas,
> > 
> > I just experienced the (probably) same issue:
> > 
> > Preparing to unpack 
> > .../87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb ...
> > Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-1) over 
> > (0~git20161123-1) ...
> > dpkg: error processing archive 
> > /tmp/apt-dpkg-install-lJHmtd/87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb
> >  (--unpack):
> >  unable to open 
> > '/usr/share/yasnippet-snippets/clojure-mode/.yas-parents.dpkg-new': No such 
> > file or directory
> > Errors were encountered while processing:
> >  
> > /tmp/apt-dpkg-install-lJHmtd/87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb
> > 
> > Nicholas D Steeves wrote:
> > > Is /usr or /usr/share a symlink or bind mount to somewhere else, or
> > > are either of them mounted via NFS?
> > 
> > Not in my case:
> > 
> > → mount | fgrep usr
> > → ls -ldF /usr /usr/share
> > drwxr-xr-x  12 root root  4096 Feb 28 05:29 /usr/
> > drwxr-xr-x 990 root root 32768 Mar 20 22:01 /usr/share/
> > 
> > > Also, will the following
> > > commands reproduce "unable to open
> > > '/usr/share/yasnippet-snippets/clojure-mode/.yas-parents.dpkg-new': No
> > > such file or directory"?
> > [...]
> > > curl -O 
> > > https://debian.org/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20161123-1_all.deb
> > 
> > JFTR: This is no valid Debian mirror URL.
> 
> Oh my, sorry about that!  I guess this one will have to do:
> 
> http://ftp.debian.org/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20161123-1_all.deb
> 
> > Anyway, I first purged yasnippet-snippets (0~git20161123-1 was still
> > installed due to the failed upgrade), then I installed
> > yasnippet-snippets 0~git20161123-1 from Debian Testing again. Then I
> > tried to upgrade yasnippet-snippets to 0~git20180307.2b4c4d7e-1 from
> > Debian Unstable again:
> > 
> > [...]
> > Removing yasnippet-snippets (0~git20161123-1) ...
> > [...]
> > Selecting previously unselected package yasnippet-snippets.
> > (Reading database ... 1040898 files and directories currently installed.)
> > Preparing to unpack .../yasnippet-snippets_0~git20161123-1_all.deb ...
> > Unpacking yasnippet-snippets (0~git20161123-1) ...
> > Setting up yasnippet-snippets (0~git20161123-1) ...
> > [...]
> > Preparing to unpack .../yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb 
> > ...
> > Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-1) over 
> > (0~git20161123-1) ...
> > Setting up yasnippet-snippets (0~git20180307.2b4c4d7e-1) ...
> > [...]
> > 
> > So, no, if the initially installed yasnippet-snippets version is
> > 0~git20161123-1, the issue doesn't seem to happen.
> > 
> > Which leaves the question: Upgrading from which version does exhibit
> > that behaviour?
> > 
> > In my case it was an Debian Unstable which has been upgraded
> > regularily since its installation on 2014-04-08. yasnippet-snippets
> > has been first installed in version 0~git20150512-1 on Thu May 28
> > 19:16:25 2015 +0200.
> 
> Thank you very much for this information!  Luckily the only three
> versions are: 0~git20150512-1, 0~git20161123-1, and
> 0~git20180307.2b4c4d7e-1.
> 
> Because http://archive.debian.net is not available I'll try building
> these three versions, purging my current 0~git20180307.2b4c4d7e-1, and
> then sequentially installing/upgrading.  My hypothesis is now that
> this bug is cause by an artifact introduced by upgrading from the 2015
> to 2016 version.
> 
> 
> Time to test!
> Nicholas



> ___
> Pkg-emacsen-addons mailing list
> pkg-emacsen-add...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-emacsen-addons

There, I was finally able to reproduce with:

sudo apt purge yasnippet-snippets
wget
http://archive.ubuntu.com/ubuntu/pool/universe/y/yasnippet-snippets/yasnippet-snippets_0~git20150512-1_all.deb
wget 
http://ftp.debian.org/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20161123-1_all.deb

sudo dpkg -i yasnippet-snippets_0~git20150512-1_all.deb
sudo dpkg -i yasnippet-snippets_0~git20161123-1_all.deb
sudo apt upgrade # or sudo dpkg -i 
yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb

So affected users are those who track Debian sid (and who installed
the 2015 version), plus Ubuntu users who installed xenial (16.04LTS)

Well, that's all the time I have for today!
Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#893663: freeplane: CVE-2018-1000069 XXE vulnerability

[Markus Koschany]

Package: freeplane
X-Debbugs-CC: t...@security.debian.org
X-Debbugs-CC: fnat...@gmx.net
Severity: important
Tags: security

Hi,

the following vulnerability was published for freeplane. Apparently only
stretch/jessie/wheezy might be affected.

@Felix
Can you tell us more about this vulnerability? There only seems to be a
reference in freeplane's wiki.

https://www.freeplane.org/wiki/index.php/XML_External_Entity_vulnerability_in_map_parser

CVE-2018-169[0]:
| FreePlane version 1.5.9 and earlier contains a XML External Entity
| (XXE) vulnerability in XML Parser in mindmap loader that can result in
| stealing data from victim's machine. This attack appears to require
| the vicim to open a specially crafted mind map file. This
| vulnerability appears to have been fixed in 1.6+.

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-169
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-169

Please adjust the affected versions in the BTS as needed.



signature.asc
Description: OpenPGP digital signature

Bug#893057: python3-notmuch: random aborts on exit

[Brian May]

On 2018-03-16 11:28, David Bremner wrote:

> I suspect it has to do with changes in memory management in python3.
> 
> You hide the problem by adding
> 
> del(db)
> 
> at the end of your script.

Unfortunately, I still seem to be getting this abort error, although not
as often. 

Curiously, changes to tags don't seem to be preserved after the program
exits. This may or may not be related.

Bug#893661: gthumb: Memory leakage

[Patrick]

Package: gthumb
Version: 3:3.4.4.1-5
Severity: important

Dear Maintainer,

I'm using gthumb 3.4.4.1 which is the version available in the current Debian
Stable repositories. It seems to have a big memory leak: From the moment I open
the program, every picture I watch seems to stay loaded in the RAM until it's
full and then, the whole system becomes extremely slow.

The only way I found to avoid this is to keep an eye on the system monitor and
close gthumb once in a while before the RAM usage reaches 100%. It seems like
there's been issues like that in the past:

https://mail.gnome.org/archives/gthumb-list/2017-April/msg0.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810054

Thanks!



-- 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/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gthumb depends on:
ii  gsettings-desktop-schemas   3.22.0-1
ii  gthumb-data 3:3.4.4.1-5
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-11+deb9u3
ii  libcairo-gobject2   1.14.8-1
ii  libcairo2   1.14.8-1
ii  libclutter-1.0-01.26.0+dfsg-3
ii  libclutter-gtk-1.0-01.8.2-2
ii  libcogl-pango20 1.22.2-2
ii  libcogl-path20  1.22.2-2
ii  libcogl20   1.22.2-2
ii  libdrm2 2.4.74-1
ii  libegl1-mesa [libegl1-x11]  13.0.6-1+b2
ii  libexiv2-14 0.25-3.1
ii  libgbm1 13.0.6-1+b2
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
ii  libgstreamer-plugins-base1.0-0  1.10.4-1
ii  libgstreamer1.0-0   1.10.4-1
ii  libgtk-3-0  3.22.11-1
ii  libjavascriptcoregtk-4.0-18 2.18.6-1~deb9u1
ii  libjpeg62-turbo 1:1.5.1-2
ii  libjson-glib-1.0-0  1.2.6-1
ii  liblcms2-2  2.8-4
ii  libpango-1.0-0  1.40.5-1
ii  libpangocairo-1.0-0 1.40.5-1
ii  libpng16-16 1.6.28-1
ii  libraw150.17.2-6+deb9u1
ii  librsvg2-2  2.40.16-1+b1
ii  libsecret-1-0   0.18.5-3.1
ii  libsoup2.4-12.56.0-2+deb9u1
ii  libstdc++6  6.3.0-18+deb9u1
ii  libtiff54.0.8-2+deb9u2
ii  libwayland-client0  1.12.0-1
ii  libwayland-cursor0  1.12.0-1
ii  libwayland-egl1-mesa [libwayland-egl1]  13.0.6-1+b2
ii  libwayland-server0  1.12.0-1
ii  libwebkit2gtk-4.0-372.18.6-1~deb9u1
ii  libwebp60.5.2-1
ii  libx11-62:1.6.4-3
ii  libxcomposite1  1:0.4.4-2
ii  libxdamage1 1:1.1.4-2+b3
ii  libxext62:1.3.3-1+b2
ii  libxfixes3  1:5.0.3-1
ii  libxi6  2:1.7.9-1
ii  libxkbcommon0   0.7.1-2~deb9u1
ii  libxrandr2  2:1.5.1-1
ii  zlib1g  1:1.2.8.dfsg-5

Versions of packages gthumb recommends:
ii  bison  2:3.0.4.dfsg-1+b1
ii  flex   2.6.1-1.3
ii  gvfs-bin   1.30.4-1
ii  libgphoto2-6   2.5.12-1
ii  libgphoto2-port12  2.5.12-1

gthumb suggests no packages.

-- no debconf information

Bug#893254: parole: resolved directories incorrectly in playlist (.m3u) files

[Yves-Alexis Perez]

On Tue, 2018-03-20 at 23:10 +, js jb wrote:
> That is correct: I have only /usr1, /usr2, /usr3 directories on my system and 
> the mp3 files are in subdirectories of:
>  /usr3/ME/mp3/...
> 
> The playlists are all in /usr3/ME/mp3/xmms and reference the mp3 files as:
> ..//xyz.mp3
> 
> This  setup worked fine in older versions of parole as well as with other 
> music players (vlc, amarok).
> 
> I can't see where the /usr5 comes from as there is no directory (or file) 
> with this name:
> => locate usr5
> ME@hostname:~ =>

I've tried to generate a playlist with relative filenames, and it seems to
work just fine here. Could you maybe try to run parole through strace and see
the file accesses?

Regards,
-- 
Yves-Alexis

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

Bug#893598: yasnippet-snippets: Error while updating

[Nicholas D Steeves]

On Tue, Mar 20, 2018 at 06:53:15PM -0400, Nicholas D Steeves wrote:
> On Tue, Mar 20, 2018 at 10:44:34PM +0100, Axel Beckert wrote:
>
> > In my case it was an Debian Unstable which has been upgraded
> > regularily since its installation on 2014-04-08. yasnippet-snippets
> > has been first installed in version 0~git20150512-1 on Thu May 28
> > 19:16:25 2015 +0200.
> 
> Thank you very much for this information!  Luckily the only three
> versions are: 0~git20150512-1, 0~git20161123-1, and
> 0~git20180307.2b4c4d7e-1.
> 
> Because http://archive.debian.net is not available I'll try building
> these three versions, purging my current 0~git20180307.2b4c4d7e-1, and
> then sequentially installing/upgrading.  My hypothesis is now that
> this bug is cause by an artifact introduced by upgrading from the 2015
> to 2016 version.

Well that's strange...  No errors...  I also tried installing each
version on top of the last in a clean sid chroot.  Maybe the bug is
only triggered when 0~git20150512-1 was built using particular (old)
versions of debhelper and/or when the upgrade to 0~git20161123-1 was
performed using particular versions of dpkg?

If anyone can provide a copy of (or link to) the old
yasnippet-snippets_0~git20150512-1_all.deb I would be very
appreciative!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#893662: rhythmbox: doesn't find any metadata

[Christoph Anton Mitterer]

Package: rhythmbox
Version: 3.4.2-3
Severity: important


Hi.

The following happens even after deleting all rhythmbox
in .cache, .local/share and so on.

I scan my music (tens of thousands of files) and except for
very few of them it isn't able to find any metadata.

Other tag editors, ffprobe, etc. all display the metadata
just fine.

Attached are --debug logs.


Any ideas?

Thanks,
Chris.

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

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

Versions of packages rhythmbox depends on:
ii  dbus1.12.6-2
ii  gstreamer1.0-plugins-base   1.12.4-1
ii  gstreamer1.0-plugins-good   1.12.4-1+b1
ii  gstreamer1.0-x  1.12.4-1
ii  libc6   2.27-2
ii  libglib2.0-02.56.0-2
ii  libgstreamer-plugins-base1.0-0  1.12.4-1
ii  libgstreamer1.0-0   1.12.4-1
ii  libgtk-3-0  3.22.29-1
ii  libpeas-1.0-0   1.22.0-2
ii  librhythmbox-core10 3.4.2-3
ii  libx11-62:1.6.5-1
ii  media-player-info   23-1
ii  rhythmbox-data  3.4.2-3

Versions of packages rhythmbox recommends:
pn  avahi-daemon
ii  cinnamon [notification-daemon]  3.4.6-1
ii  gstreamer1.0-plugins-ugly   1.12.4-1+b1
ii  gstreamer1.0-pulseaudio 1.12.4-1+b1
ii  gvfs-backends   1.36.0-1
ii  notification-daemon 3.20.0-3
pn  rhythmbox-plugins   
ii  yelp3.26.0-2

Versions of packages rhythmbox suggests:
pn  gnome-codec-install  
pn  gnome-control-center 
ii  gstreamer1.0-plugins-bad 1.12.4-2+b2
pn  rhythmbox-plugin-cdrecorder  

-- no debconf information


log.xz
Description: application/xz

Bug#893660: python-rgain: clutters up with temp files

[Christoph Anton Mitterer]

Package: python-rgain
Version: 1.3.4-2
Severity: normal


Hi.

collectiongain seems to clutter up ~/.cache with temp files:
collectiongain-cache.a93ca9bffa744d36fd46f86b2f8ac14a
collectiongain-cache.a445566b3975f8f60081c410a6069147
collectiongain-cache.abd3f7855590fabe5697767dbee54f58
collectiongain-cache.ae523f68a79b4626ff08a82d3ceefb2a
collectiongain-cache.b107b1edf03f8d3d80e30fa1aa2e1679
collectiongain-cache.c198cd73189da8e03003ba5c4d378862

AFAIU ~/.cache is not really intended for such kind of
temp files which are likely never to be used again.

And even if these would be reused, they should perhaps
go into some subdir :-)

Thanks,
Chris.

Bug#893659: Please add Python 3 support

[Thomas Goirand]

Package: python-ethtool
Severity: important
Tags: patch

Hi,

Please add support for Python 3 in this package. I have attached a patch to do
exactly that. If you don't have time, please allow me to NMU.

Note that the patch was made against the Git in Alioth, though it doesn't take
into account the NMU version currently in Sid. So it would have to be fixed
for that.

Last, this is important for me, because I've switched all of OpenStack to
Python 3, and this is on my way to finish the work (and this would fix the
RC bug: #892882).

Cheers,

Thomas Goirand (zigo)
From e5a221f6a0be7b6d12f1809cd8d84e25f440745a Mon Sep 17 00:00:00 2001
From: Thomas Goirand 
Date: Tue, 20 Mar 2018 22:40:03 +
Subject: [PATCH]   * ran wrap-and-sort -bast.   * Add Python 3 support.   *
 Standards-Version is now 4.1.3.

---
 debian/changelog |  9 +
 debian/control   | 42 +-
 debian/copyright |  4 +---
 debian/rules | 15 +--
 4 files changed, 60 insertions(+), 10 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 26c0b76..be8bc43 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+python-ethtool (0.12-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * ran wrap-and-sort -bast.
+  * Add Python 3 support.
+  * Standards-Version is now 4.1.3.
+
+ -- Thomas Goirand   Tue, 20 Mar 2018 22:35:22 +
+
 python-ethtool (0.12-1) unstable; urgency=medium
 
   * [ea5192b] Fix some other gcc5 warnings.
diff --git a/debian/control b/debian/control
index c346c13..5201912 100644
--- a/debian/control
+++ b/debian/control
@@ -1,17 +1,49 @@
 Source: python-ethtool
 Section: python
 Priority: extra
-Uploaders: Miroslav Suchý 
+Uploaders:
+ Miroslav Suchý ,
 Maintainer: Bernd Zeimetz 
-Build-Depends: debhelper (>= 7.0.50~), python-all-dev (>= 2.6.6-3~), 
libnl-route-3-dev, asciidoc, pkg-config, libxml2-utils, docbook-xml, xsltproc, 
sgml-data, libxml2, docbook-xsl, docbook-xml
-Standards-Version: 3.9.3
+Build-Depends:
+ asciidoc,
+ debhelper,
+ docbook-xml,
+ docbook-xsl,
+ libnl-route-3-dev,
+ libxml2,
+ libxml2-utils,
+ pkg-config,
+ python-all-dev,
+ python-setuptools,
+ python3-all-dev,
+ python3-setuptools,
+ sgml-data,
+ xsltproc,
+Standards-Version: 4.1.3
 Homepage: https://fedorapeople.org/cgit/dsommers/public_git/python-ethtool.git/
 Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=collab-maint/spacewalk/python-ethtool.git
 Vcs-Git: git://anonscm.debian.org/collab-maint/spacewalk/python-ethtool.git
 
 Package: python-ethtool
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}
-Description: Python bindings for the ethtool kernel interface
+Depends:
+ ${misc:Depends},
+ ${python:Depends},
+ ${shlibs:Depends},
+Description: Python bindings for the ethtool kernel interface - Python 2.7
  Allows querying and changing of ethernet card settings, such as speed,
  port, autonegotiation, and PCI locations.
+ .
+ This package provides the Python 2.7 module.
+
+Package: python3-ethtool
+Architecture: any
+Depends:
+ ${misc:Depends},
+ ${python3:Depends},
+ ${shlibs:Depends},
+Description: Python bindings for the ethtool kernel interface - Python 3.x
+ Allows querying and changing of ethernet card settings, such as speed,
+ port, autonegotiation, and PCI locations.
+ .
+ This package provides the Python 3.x module.
diff --git a/debian/copyright b/debian/copyright
index 421fd55..dd6b229 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -33,7 +33,7 @@ On Debian systems, the complete text of the GNU General
 Public License version 2 can be found in `/usr/share/common-licenses/GPL-2'.
 
 The Debian packaging is
-Copyright 2009, Lukáš Ďurfina  
+Copyright 2009, Lukáš Ďurfina 
 Copyright 2012 Miroslav Suchý 
 Copyright 2012 Bernd Zeimetz 
 and is licensed under the GPL 2, see above.
@@ -47,5 +47,3 @@ and is licenced under GPLv2.
  * Portions Copyright 2002 Intel (eli.kuperm...@intel.com,
  *christopher.le...@intel.com,
  *scott.feld...@intel.com)
-
-
diff --git a/debian/rules b/debian/rules
index 6e52b60..4e2bb16 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,19 +2,30 @@
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
+PYTHONS:=$(shell pyversions -vr)
+PYTHON3S:=$(shell py3versions -vr)
 
 override_dh_auto_build:
+   set -e ; set -x ; for i in $(PYTHONs) $(PYTHON3S) ; do \
+   PYTHON=python$$i python$$i setup.py build --force ; \
+   done
dh_auto_build --buildsystem python_distutils
cp -p pethtool.py pethtool
cp -p pifconfig.py pifconfig
a2x -d manpage -f manpage man/pethtool.8.asciidoc
a2x -d manpage -f manpage man/pifconfig.8.asciidoc
 
+override_dh_auto_install:
+   

Bug#893598: [Pkg-emacsen-addons] Bug#893598: yasnippet-snippets: Error while updating

[Nicholas D Steeves]

Control: tags -1 confirmed

Hi Axel,

Thank you for confirming this bug!

On Tue, Mar 20, 2018 at 10:44:34PM +0100, Axel Beckert wrote:
> Hi Nicholas,
> 
> I just experienced the (probably) same issue:
> 
> Preparing to unpack 
> .../87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb ...
> Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-1) over 
> (0~git20161123-1) ...
> dpkg: error processing archive 
> /tmp/apt-dpkg-install-lJHmtd/87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb
>  (--unpack):
>  unable to open 
> '/usr/share/yasnippet-snippets/clojure-mode/.yas-parents.dpkg-new': No such 
> file or directory
> Errors were encountered while processing:
>  
> /tmp/apt-dpkg-install-lJHmtd/87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb
> 
> Nicholas D Steeves wrote:
> > Is /usr or /usr/share a symlink or bind mount to somewhere else, or
> > are either of them mounted via NFS?
> 
> Not in my case:
> 
> → mount | fgrep usr
> → ls -ldF /usr /usr/share
> drwxr-xr-x  12 root root  4096 Feb 28 05:29 /usr/
> drwxr-xr-x 990 root root 32768 Mar 20 22:01 /usr/share/
> 
> > Also, will the following
> > commands reproduce "unable to open
> > '/usr/share/yasnippet-snippets/clojure-mode/.yas-parents.dpkg-new': No
> > such file or directory"?
> [...]
> > curl -O 
> > https://debian.org/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20161123-1_all.deb
> 
> JFTR: This is no valid Debian mirror URL.

Oh my, sorry about that!  I guess this one will have to do:

http://ftp.debian.org/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20161123-1_all.deb

> Anyway, I first purged yasnippet-snippets (0~git20161123-1 was still
> installed due to the failed upgrade), then I installed
> yasnippet-snippets 0~git20161123-1 from Debian Testing again. Then I
> tried to upgrade yasnippet-snippets to 0~git20180307.2b4c4d7e-1 from
> Debian Unstable again:
> 
> [...]
> Removing yasnippet-snippets (0~git20161123-1) ...
> [...]
> Selecting previously unselected package yasnippet-snippets.
> (Reading database ... 1040898 files and directories currently installed.)
> Preparing to unpack .../yasnippet-snippets_0~git20161123-1_all.deb ...
> Unpacking yasnippet-snippets (0~git20161123-1) ...
> Setting up yasnippet-snippets (0~git20161123-1) ...
> [...]
> Preparing to unpack .../yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb 
> ...
> Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-1) over 
> (0~git20161123-1) ...
> Setting up yasnippet-snippets (0~git20180307.2b4c4d7e-1) ...
> [...]
> 
> So, no, if the initially installed yasnippet-snippets version is
> 0~git20161123-1, the issue doesn't seem to happen.
> 
> Which leaves the question: Upgrading from which version does exhibit
> that behaviour?
> 
> In my case it was an Debian Unstable which has been upgraded
> regularily since its installation on 2014-04-08. yasnippet-snippets
> has been first installed in version 0~git20150512-1 on Thu May 28
> 19:16:25 2015 +0200.

Thank you very much for this information!  Luckily the only three
versions are: 0~git20150512-1, 0~git20161123-1, and
0~git20180307.2b4c4d7e-1.

Because http://archive.debian.net is not available I'll try building
these three versions, purging my current 0~git20180307.2b4c4d7e-1, and
then sequentially installing/upgrading.  My hypothesis is now that
this bug is cause by an artifact introduced by upgrading from the 2015
to 2016 version.


Time to test!
Nicholas


signature.asc
Description: PGP signature

Bug#893251: jabref 3.8 is started with OpenJDK 9 instead of 8

[gregor herrmann]

On Mon, 19 Mar 2018 22:40:47 -0700, tony mancill wrote:

> > Maybe that's caused by the recent update of liblog4j2-java 2.8.2-2 -> 
> > 2.10.0-1
> > Indeed, downgrading liblog4j2-java to 2.8.2-2 helps.
> > Not sure if this is a jabref problem or a liblog4j2-java issue; let's
> > hope the java experts can shed some light on this bug.
> Ouch indeed!  I'm pretty certain that this is an issue with how
> liblog4j2-java is being built for Debian.  There is some discussion of
> the issue here [1].  Basically, we need to take precautions when
> building libraries with JDK 9 that are expected to run with JDK 8
> runtimes.

Thanks for looking into this issue and for digging up this reference.
 
> That said, so far I'm not able to build a liblog4j2-java from the
> 2.10.0-1 source package that will play nicely with jabref, but I'll keep
> looking at that and other options (aside from suggesting that we start
> recommending a stretch chroot for jabref...)

Thanks. And I'm optimistic that you'll succeed in the end :)

Should we reassign this bug to liblog4j2-java (+ affects jabref)? I
suppose the problem doesn't exclusively hit jabref?
 
> [1] https://github.com/plasma-umass/doppio/issues/497


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: Rebekka Bakken & Wolfgang Muthspiel: Nowhere


signature.asc
Description: Digital Signature

Bug#893254: parole: resolved directories incorrectly in playlist (.m3u) files

[Yves-Alexis Perez]

On Sat, 2018-03-17 at 10:59 -0400, jack wrote:
> In a playlist as below, located in directory /usr3/ME/mp3/xmms, with mp3
> files located in /usr3/ME/mp3//*.mp3, parole incorrectly resolves
> ../electric_light_orchestra  = /usr5/ME/mp3/electric_light_orchestra
> (instead of /usr3), so no mp3 files are found and parole becomes
> unusable.

Hi,

just to confirm: you don't have any /usr5 repository on your system, do you?

Regards,
-- 
Yves-Alexis

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

Bug#893658: cinnamon: recommend smart-notifier

[Christoph Anton Mitterer]

Package: cinnamon
Version: 3.4.6-1
Severity: wishlist


Hi.

I couldn't find information on whether cinnamon itself queries
smartd (if installed) and displays warnings about SMART errors
in the GUI (where users will likely see them, unlike as in the
syslog).

In case cinnmon itself doesn't do that (which I guess is the
case), could you please recommend the smart-notifier package?
Not sure in which cinnamon meta package, cinnamon, cinnamon-core
cinnamon-desktop-enviroment... but likely one of the more
low-level ones :)

Thanks,
Chris

Bug#893098: axis FTBFS with openjdk-9

[Markus Koschany]

Am 20.03.2018 um 23:13 schrieb Emmanuel Bourg:
> I got a quick look, the source encoding is easily fixed and the
> org.apache.axis.enum was long deprecated and can be removed. But there
> is more than that. Axis implements interfaces from javax.xml.soap that
> were upgraded in Java 9, so Axis now fails to build due to missing
> method implementations. I wonder if it's really worth upgrading Axis, or
> if we should try to remove it.

I've pushed some changes a few minutes ago. If my IDE was working with
OpenJDK 9 it would be relatively painless to generate the missing
methods but it doesn't yet. There are quite a few reverse-dependencies
though.



signature.asc
Description: OpenPGP digital signature

Bug#893657: smartmontools: mail not set to multiple users / -M exec overrides -M

[Christoph Anton Mitterer]

Package: smartmontools
Version: 6.5+svn4324-1
Severity: important


Hi.

I've stumbled over the following issues in smartd:

At first I had bascally the following smartd.conf:
DEVICESCAN -d auto -d removable -n standby,4 -a -m 
root,mylocaluser,m...@email.com -M exec /usr/share/smartmontools/smartd-runner

In order to test it, I've added -M test.


Now on restart, only root got mail, and the postfix logs didn't even show any 
tries for mylocaluser and m...@email.com.

I've added -M once, as I assumed the support for comma-separated multiple 
addresses as explained
in the smartd.conf manpage for -m, may just not work with -M-exec-invoked 
/etc/smartmontools/run.d/10mail
but only with -M once, -M daily or -M diminishing (and that this might be some 
other mail sender than
/etc/smartmontools/run.d/10mail - which it actually seems to be).

Interestingly, it still didn't work.
Only if I removed -M exec... I got mail sent to all three recipients.



So I think there are two issues here:
1) /etc/smartmontools/run.d/10mail, which seems to be used per default
   by debian (as there is no -M once or so)
   should support multiple addresses in -m.
   It's likely not obvious to the user that there are two methods of sending 
warning mails, and
   it should just work as one would naively assume by reading the documentation 
of -m.

2) In contrast to what the manpage claims, it seems that if -M exec is in 
place, -M once/etc. are not
   executed as well.



IMO both are severity=important, as they may prevent information about failing 
drives being passed on.


Cheers,
Chris.

Bug#893556: libusb-0.1-4 has priority important

[Aurelien Jarno]

On 2018-03-19 22:09, Christian Göttsche wrote:
> Package: libusb-0.1-4
> Version: 2:0.1.12-31
> Severity: Important

Can you please tell me what is the important issue caused by this wrong
priority?

> Are there any reasons why this library has a priority of important?

The main reason is that this package hasn't been uploaded since the
relatively recent change of the policy. Some package with priority
important depends on libusb-0.1-4, so the old policy required that
libusb-0.1-4 to have at least priority optional.

> If not, please lower to optional.

I'll do that in the next upload.

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

Bug#893460: mbuffer: make autopkgtests pass on all archs

[Peter Pentchev]

On Tue, Mar 20, 2018 at 02:05:28PM -0700, Steve Langasek wrote:
> On Tue, Mar 20, 2018 at 11:59:28AM +0200, Peter Pentchev wrote:
> > Unfortunately, this patch is not moving in the right direction.  These
> > tests preload a library that is built as part of the mbuffer build that
> > intercepts open() and write() calls (among others) and simulates
> > changing tape devices; basically it splits the mbuffer output into
> > several files.  This is the reason why on amd64 there are many
> > output-test4.* and output-test5.* files - there should not be a single
> > output-test4 file, there should be output-test4.01 and so on files.
> > So the test failure means that the tapetest.so object is not being
> > preloaded correctly or that it fails to intercept the necessary libc
> > calls.
> 
> > Sounds like I'll need to spin up a couple of VMs and see what's what.
> 
> > Thanks again for your work on this and Debian and Ubuntu in general!
> 
> Ah, ok.  Now that I understand the purpose, I can see why it's broken:
> 
> $ objdump -T /usr/lib/arm-linux-gnueabihf/mbuffer/tapetest.so |grep open
> 0780 gDF .text  00e4  Baseopen
> 0001100c gDO .bss   0004  Baseopencount
> $ objdump -T /usr/bin/mbuffer |grep open
>   DF *UND*    GLIBC_2.4   open64
>   DF *UND*    GLIBC_2.7   __open64_2
> $
> 
> mbuffer is quite reasonably built with LFS support on all archs, which means
> that, on 32-bit architectures in particular, the shim for open() does not
> match the actual function called by mbuffer.

Yep, this was my first suspicion; thanks for confirming it!  I'll try to
come up with a fix soon.

> So the tapetest shim is broken on these architectures.  My patch is
> definitely the wrong way to fix this, but if 'tapetest' is indeed simply a
> test library, I don't think I have broken the mbuffer package in Ubuntu by
> (effectively) skipping this test.

Right, sorry that I forgot to mention this.  Yes, if mbuffer passes
the other tests, it is highly unlikely that it's broken.

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13


signature.asc
Description: PGP signature

Bug#893561: libtablelayout-java: license does not seem to meet the DFSG

[Francesco Poli]

On Tue, 20 Mar 2018 00:41:04 +0200 Adrian Bunk wrote:

[...]
> In https://lists.debian.org/debian-legal/2005/01/msg00142.html you 
> agreed entirely that it is OK when software is made DFSG-free through
> renaming to avoid trademark violations.
> 
> What difference would it make whether our users are forbidden to change
> the namespace back to "info.clearthought" due to
> 1. trademark
> 2. licence
> 3. both

Hello Adrian,
thanks for your prompt followup!

I see an important difference between the case at hand and the Mozilla
case.

One thing is the requirement to change the *name* for the work: this is
just how the work presents itself to the user, not something that
really affects functionality/interoperability/interfaces/...
Even if the name of the executable file of a program is changed, there
are many ways to easily let the user invoke it by another name
(symlinks, wrapper scripts, aliases, and so forth...).

I think the requirement to change *namespace* for library classes
is different: it affects the possibility to create modified drop-in
replacements for the library, without having to adapt all the
programs or other libraries that use the original library.
The namespace looks like a functional aspect.

I think it's not by chance that DFSG#4 accepts the requirements to
change the *name* or the *version number*, but not the requirements
to change other, more functional, labels in a package...


I hope this clarifies.


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


pgpGYEY7rAgr4.pgp
Description: PGP signature

Bug#893656: transition: theano 0.9 -> 1.0

[Rebecca N. Palmer]

Source: theano
Severity: wishlist

(Posting here rather than on debian-release as the formal transition 
process is rarely used, and its tools mostly useless, for non-compiled 
cases.)


Theano 1.0 (currently in Salsa) contains some API-breaking changes:
http://www.deeplearning.net/software/theano/NEWS.html

The packages in main that import theano are:

brian - not tested, FTBFS for unrelated reasons (#876920), not in testing
deepnano - not tested but looks already broken, not in testing
keras - build and debci tests pass; upstream say it shouldn't be a 
problem https://github.com/keras-team/keras/issues/5209
lasagne - 3 test failures; fixed upstream by 
https://github.com/Lasagne/Lasagne/pull/836
pyopencl - FTBFS for unrelated reasons (#893050); the theano-using code 
appears to be build/test scripts (pyopencl/compyte/gen*, test*) we never 
actually run
sympy - build hangs at mkdir -p _build/logo (with mkdir using a full CPU 
core?!), probably unrelated as it also happens without *-theano installed


As one of the changes is removal of theano.sandbox.cuda (replaced by 
theano.gpuarray, with a different API) and my hardware doesn't support 
CUDA, I am unable to test this fully and testing by others would be 
welcome.  Be aware that if python(3)-nose is installed (it wasn't for 
these tests), attempting to import theano.sandbox.cuda raises SkipTest 
(?!), not ImportError: 
https://salsa.debian.org/science-team/theano/raw/master/theano/sandbox/cuda/__init__.py

Bug#783627: [network-manager-gnome] NM-applet crashes on autoconnect to mobile broadband

[Iiro Laiho]

On Thu, 29 Oct 2015 11:41:50 +0100 Morten Shearman Kirkegaard 
 wrote:

> This bug appears to be a duplicate of bug #777387.
>
>

No, it does not look anything like this, that one is related to suspends.

This problem seems to still plague Debian Stretch. Is Gnome's 
network-manager ppp connection functionality still being actively 
maintained? I gues ppp is becoming more or less niche functionality.


--
Iiro Laiho

Bug#893181: Pending fixes for bugs in the jasmin-sable package

[pkg-java-maintainers]

tag 893181 + pending
thanks

Some bugs in the jasmin-sable package are closed in revision
fa9a5c75ee33a4ff8380cda039a42636e236ca5b in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/jasmin-sable.git/commit/?id=fa9a5c7

Commit message:

Fixed the build failure with Java 9 (Closes: #893181)

Bug#893098: axis FTBFS with openjdk-9

[Emmanuel Bourg]

I got a quick look, the source encoding is easily fixed and the
org.apache.axis.enum was long deprecated and can be removed. But there
is more than that. Axis implements interfaces from javax.xml.soap that
were upgraded in Java 9, so Axis now fails to build due to missing
method implementations. I wonder if it's really worth upgrading Axis, or
if we should try to remove it.

Emmanuel Bourg

Bug#893655: libwoodstox-java FTBFS with openjdk-9

[Adrian Bunk]

Source: libwoodstox-java
Version: 1:4.1.3-1
Severity: serious
Tags: buster sid
Control: fixed -1 1:5.0.3-2
Control: close -1

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

...

compile.woodstox:
[javac] Using javac -source 1.4 is no longer supported, switching to 1.6
[javac] Using javac -target 1.4 is no longer supported, switching to 1.6
[javac] Compiling 176 source files to 
/build/1st/libwoodstox-java-4.1.3/build/classes/woodstox
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] warning: [options] source value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] target value 1.6 is obsolete and will be removed 
in a future release
[javac] warning: [options] To suppress warnings about obsolete options, use 
-Xlint:-options.
[javac] 
/build/1st/libwoodstox-java-4.1.3/src/java/com/ctc/wstx/osgi/WstxBundleActivator.java:29:
 error: no suitable method found for 
registerService(String,InputFactoryProviderImpl,Properties)
[javac] 
ctxt.registerService(Stax2InputFactoryProvider.class.getName(), inputP, 
inputP.getProperties());
[javac] ^
[javac] method 
BundleContext.registerService(String[],Object,Dictionary) is not 
applicable
[javac]   (argument mismatch; String cannot be converted to String[])
[javac] method 
BundleContext.registerService(String,Object,Dictionary) is not 
applicable
[javac]   (argument mismatch; Properties cannot be converted to 
Dictionary)
[javac] method 
BundleContext.registerService(Class,S#1,Dictionary) is not 
applicable
[javac]   (cannot infer type-variable(s) S#1
[javac] (argument mismatch; String cannot be converted to 
Class))
[javac] method 
BundleContext.registerService(Class,ServiceFactory,Dictionary)
 is not applicable
[javac]   (cannot infer type-variable(s) S#2
[javac] (argument mismatch; String cannot be converted to 
Class))
[javac]   where S#1,S#2 are type-variables:
[javac] S#1 extends Object declared in method 
registerService(Class,S#1,Dictionary)
[javac] S#2 extends Object declared in method 
registerService(Class,ServiceFactory,Dictionary)
[javac] 
/build/1st/libwoodstox-java-4.1.3/src/java/com/ctc/wstx/osgi/WstxBundleActivator.java:31:
 error: no suitable method found for 
registerService(String,OutputFactoryProviderImpl,Properties)
[javac] 
ctxt.registerService(Stax2OutputFactoryProvider.class.getName(), outputP, 
outputP.getProperties());
[javac] ^
[javac] method 
BundleContext.registerService(String[],Object,Dictionary) is not 
applicable
[javac]   (argument mismatch; String cannot be converted to String[])
[javac] method 
BundleContext.registerService(String,Object,Dictionary) is not 
applicable
[javac]   (argument mismatch; Properties cannot be converted to 
Dictionary)
[javac] method 
BundleContext.registerService(Class,S#1,Dictionary) is not 
applicable
[javac]   (cannot infer type-variable(s) S#1
[javac] (argument mismatch; String cannot be converted to 
Class))
[javac] method 
BundleContext.registerService(Class,ServiceFactory,Dictionary)
 is not applicable
[javac]   (cannot infer type-variable(s) S#2
[javac] (argument mismatch; String cannot be converted to 
Class))
[javac]   where S#1,S#2 are type-variables:
[javac] S#1 extends Object declared in method 
registerService(Class,S#1,Dictionary)
[javac] S#2 extends Object declared in method 
registerService(Class,ServiceFactory,Dictionary)
[javac] 
/build/1st/libwoodstox-java-4.1.3/src/java/com/ctc/wstx/osgi/WstxBundleActivator.java:35:
 error: no suitable method found for 
registerService(String,ValidationSchemaFactoryProviderImpl,Properties)
[javac] 
ctxt.registerService(Stax2ValidationSchemaFactoryProvider.class.getName(), 
impl, impl.getProperties());
[javac] ^
[javac] method 
BundleContext.registerService(String[],Object,Dictionary) is not 
applicable
[javac]   (argument mismatch; String cannot be converted to String[])
[javac] method 
BundleContext.registerService(String,Object,Dictionary) is not 
applicable
[javac]   (argument mismatch; Properties cannot be converted to 
Dictionary)
[javac] method 
BundleContext.registerService(Class,S#1,Dictionary) is not 
applicable
[javac]   (cannot infer type-variable(s) S#1
[javac] (argument mismatch; String cannot be converted to 

Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Luca Boccassi]

Control: severity -1 wishlist

On Tue, 2018-03-20 at 21:22 +0100, Philipp Kern wrote:
> Hi,
> 
> On 2/5/18 4:26 PM, Philipp Kern wrote:
> > Since forever users of NVIDIA on Debian accepted that package
> > upgrades
> > break newly spawned binaries because the interface between the
> > client
> > library and the kernel driver is strictly versioned. The kernel
> > module
> > will emit an API mismatch error into the kernel log and GLX
> > requests
> > will fail. A reboot is required to remediate this situation.
> > 
> > I would propose the following model:
> > 
> > * All binary packages that require strict versioning with NVRM are
> > shipped in versioned packages. This means that the library package
> > names
> > reflect both major and minor version (= the version on which the
> > driver
> > checks) of the driver. The resulting packages should be co-
> > installable
> > with each other.
> > * An script modifies the symlink for the currently active libraries
> > to
> > point to the version of the currently loaded nvidia module (as
> > fetched
> > from sysfs's /sys/module/nvidia/version). This script is called on
> > installation but more crucially on every boot. This will tie the
> > libraries to the module loaded at boot-up.
> > * The kernel module itself does not have to be versioned. The
> > kernel
> > module can be upgraded and it will end up in the initrd
> > automatically.
> > 
> > Assuming that we have a metapackage that pulls in the most recent
> > driver
> > (like linux-image does), this model would allow to upgrade the
> > driver at
> > any point in time and only make it live with the next reboot. This
> > allows applications to continue to function.
> > 
> > This approach has the drawback that every update from NVIDIA needs
> > to go
> > through NEW. However I think this is just a theoretical
> > disadvantage at
> > this point as NEW latency for ABI version changes has decreased a
> > lot.
> > 
> > The thing I'm not sure about is how this proposal interacts with
> > the
> > legacy modules. I suppose they can all use the same mechanism but
> > the
> > script would need to be aware what library stack needs to be
> > chosen. The
> > NVIDIA kernel shim already checks using rm_is_supported_device if
> > the
> > currently installed device is supported. That together with
> > modalias
> > should supposedly already load the correct module and then the
> > script
> > could just check which of the modules (if legacy or the normal one)
> > is
> > loaded and act accordingly.
> > 
> > Do you think this would be workable? The NVIDIA packaging is quite
> > a
> > beast to handle, I know (and I'm very grateful for your work!). So
> > we
> > should have some consensus if this is something you'd be interested
> > in. :)
> 
> is there something I could help with to get to a consensus here?
> Anything? :)
> 
> (After just having had this again that I needed to reboot when all I
> wanted was getting the i386 driver.)
> 
> Kind regards and thanks
> Philipp Kern

Hi,

Thanks for your proposal, I understand the need to reboot is an
annoyance.

The problems I see are that it would make an already quite complex
packaging system, over which we have very little control (most of it
it's binary blobs) even more complicated. We already have 2 layers of
update-alternatives (mesa vs nvidia and then current vs legacy).

It would also mean we have to start maintaining multiple versions at
the same time - again being all binary blobs, which will multiply the
source of problems. Basically, it would mean that instead of having
current vs legacy340xx (up until a few months ago also legacy304xx),
every single driver update would have to be maintained separately.

In the end the problem is an annoyance but not a deal breaker - updates
can be scheduled and delayed (unlike some other OSes...), and on top of
that, version bumps are not that common - at most once a month, and
only for those running unstable or testing - in stable we just ship LTS
versions.

Sorry, my personal opinion is that I'm just not sure it would be really
worth the additional time and hassle :-/

-- 
Kind regards,
Luca Boccassi

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

Bug#893654: RFP: node-array-includes -- Array.prototype.includes shim/polyfill/replacement

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-array-includes
  Version : 3.0.3
  Upstream Author : Jordan Harband
* URL : https://github.com/ljharb/array-includes
* License : MIT
  Programming Lang: Javascript
  Description : Array.prototype.includes shim/polyfill/replacement

This package implements the es-shim API interface. It works in an ES3-supported
environment and complies with the proposed spec.  Because
Array.prototype.includes depends on a receiver (the this value), the main export
takes the array to operate on as the first argument.

This package is depended upon by at minimum mastodon ( See #859741 ), but
this website[1] claims that some 33 projects depend on it, and boasts
7M/month downloads[2]

[1] https://www.versioneye.com/nodejs/array-includes/3.0.3
[2] https://github.com/ljharb/array-includes

Bug#893652: strophejs FTBFS with node-almond 0.3.3+dfsg-1

[Adrian Bunk]

Source: strophejs
Version: 1.2.14+dfsg-2
Severity: serious

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

...
   debian/rules override_dh_auto_build
make[1]: Entering directory '/build/1st/strophejs-1.2.14+dfsg'
node /usr/lib/nodejs/requirejs/r.js -o build.js name=/usr/lib/nodejs/almond.js 
insertRequire=strophe-polyfill include=strophe-polyfill out=strophe.min.js
Error: Error: ERROR: module path does not exist: /usr/lib/nodejs/almond.js for 
module named: /usr/lib/nodejs/almond.js. Path is relative to: 
/build/1st/strophejs-1.2.14+dfsg
at /usr/lib/nodejs/requirejs/r.js:25979:35

make[1]: *** [debian/rules:17: override_dh_auto_build] Error 1

Bug#893653: petsc4py FTBFS

[Adrian Bunk]

Source: petsc4py
Version: 3.8.1-2
Severity: serious

Some recent change in unstable makes petsc4py FTBFS:

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

...
# petsc4py embeds the deep PETSC_DIR path as RPATH in its library.
# Swap it out for a standard path, or else dh_shlibdeps gets confused
chrpath -d .pybuild/pythonX.Y_*/build/petsc4py/lib/PETSc*.so
open: No such file or directory
elf_open: Invalid argument
make[1]: *** [debian/rules:39: override_dh_auto_build] Error 1

Bug#893651: isso FTBFS with node-almond 0.3.3+dfsg-1

[Adrian Bunk]

Source: isso
Version: 0.10.6+git20170928+dfsg-1
Severity: serious

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

...
mkdir -p man/man1/ man/man5
mv man/isso.1 man/man1/isso.1
mv man/isso.conf.5 man/man5/isso.conf.5
node /usr/lib/nodejs/requirejs/r.js -o isso/js/build.embed.js 
out=isso/js/embed.min.js
Error: Error: ERROR: module path does not exist: /usr/lib/nodejs/almond.js for 
module named: /usr/lib/nodejs/almond.js. Path is relative to: 
/build/1st/isso-0.10.6+git20170928+dfsg
at /usr/lib/nodejs/requirejs/r.js:25979:35

make[2]: *** [Makefile:42: isso/js/embed.min.js] Error 1

Bug#893598: yasnippet-snippets: Error while updating

[Axel Beckert]

Hi Nicholas,

I just experienced the (probably) same issue:

Preparing to unpack .../87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb 
...
Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-1) over (0~git20161123-1) 
...
dpkg: error processing archive 
/tmp/apt-dpkg-install-lJHmtd/87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb
 (--unpack):
 unable to open 
'/usr/share/yasnippet-snippets/clojure-mode/.yas-parents.dpkg-new': No such 
file or directory
Errors were encountered while processing:
 
/tmp/apt-dpkg-install-lJHmtd/87-yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb

Nicholas D Steeves wrote:
> Is /usr or /usr/share a symlink or bind mount to somewhere else, or
> are either of them mounted via NFS?

Not in my case:

→ mount | fgrep usr
→ ls -ldF /usr /usr/share
drwxr-xr-x  12 root root  4096 Feb 28 05:29 /usr/
drwxr-xr-x 990 root root 32768 Mar 20 22:01 /usr/share/

> Also, will the following
> commands reproduce "unable to open
> '/usr/share/yasnippet-snippets/clojure-mode/.yas-parents.dpkg-new': No
> such file or directory"?
[...]
> curl -O 
> https://debian.org/debian/pool/main/y/yasnippet-snippets/yasnippet-snippets_0~git20161123-1_all.deb

JFTR: This is no valid Debian mirror URL.

Anyway, I first purged yasnippet-snippets (0~git20161123-1 was still
installed due to the failed upgrade), then I installed
yasnippet-snippets 0~git20161123-1 from Debian Testing again. Then I
tried to upgrade yasnippet-snippets to 0~git20180307.2b4c4d7e-1 from
Debian Unstable again:

[...]
Removing yasnippet-snippets (0~git20161123-1) ...
[...]
Selecting previously unselected package yasnippet-snippets.
(Reading database ... 1040898 files and directories currently installed.)
Preparing to unpack .../yasnippet-snippets_0~git20161123-1_all.deb ...
Unpacking yasnippet-snippets (0~git20161123-1) ...
Setting up yasnippet-snippets (0~git20161123-1) ...
[...]
Preparing to unpack .../yasnippet-snippets_0~git20180307.2b4c4d7e-1_all.deb ...
Unpacking yasnippet-snippets (0~git20180307.2b4c4d7e-1) over (0~git20161123-1) 
...
Setting up yasnippet-snippets (0~git20180307.2b4c4d7e-1) ...
[...]

So, no, if the initially installed yasnippet-snippets version is
0~git20161123-1, the issue doesn't seem to happen.

Which leaves the question: Upgrading from which version does exhibit
that behaviour?

In my case it was an Debian Unstable which has been upgraded
regularily since its installation on 2014-04-08. yasnippet-snippets
has been first installed in version 0~git20150512-1 on Thu May 28
19:16:25 2015 +0200.

HTH.

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#877457: stretch update for trafficserver

[Adrian Bunk]

On Fri, Mar 16, 2018 at 02:47:42PM +0100, Jean Baptiste Favre wrote:
> Hello Adrian,

Hello Jean,

> I'd love to fix  it for Stretch.

thanks!

> But, I'm only a Debian Maintainer and I'm not sure I've upload rights.

Your upload rights also work for uploads to (old)stable
(and this is nothing that would go through NEW).

> Besides, I don't know the exact procedure I'll have to follow to
> propagate such fixes to stable (but I'm eager to learn it :) )

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

> Cheers,
> Jean Baptiste

cu
Adrian

> On 14/03/2018 18:58, Adrian Bunk wrote:
> > On Wed, Jan 17, 2018 at 09:42:09AM +, Debian Bug Tracking System wrote:
> >> ...
> >>  trafficserver (7.1.1-1) unstable; urgency=medium
> >>  .
> >>* Fix trafficserver-dev dependencies. (Closes: #877457)
> >> ...
> > 
> > Thanks a lot for fixing this bug for unstable.
> > 
> > It is still present in stretch, could you also fix it there?
> > Alternatively, I can fix it for stretch if you don't object.
> > 
> > Thanks
> > Adrian
> > 

Bug#875914: autopkgtest: support Conflicts: in debian/tests/control

[Paul Gevers]

Control: tags -1 moreinfo

Hi Daniel,

On Fri, 15 Sep 2017 17:16:15 -0400 Daniel Kahn Gillmor
 wrote:
> It would be nice if we could have Conflicts: in any stanza in
> debian/tests/control, to indicate that if a given package is installed,
> this test should not be considered a candidate to run.

If I am correct, most backends already start from a minimal environment
by default and only add the required packages. What use case do you have
in mind where autopkgtest give you the wrong set?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#893650: gem FTCBFS: fails finding Pd

[Helmut Grohne]

Source: gem
Version: 1:0.93.3-13
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gem fails to cross build from source. I figured some aspects and present
them here, but ultimately what I figured doesn't make gem cross build.
Please close this bug anyway after fixing the bits reported here.

The first thing to notice is that gem configures for the build
architecture since it does not pass --host to ./configure. The easiest
way to fix that is using dh_auto_configure. configure.patch demonstrates
how to do that.

While doing so, I noticed that debian/rules confuses "build" and "host".
These terms are explained in man dpkg-architecture. build_host.patch
fixes that up as well.

Then it is still missing Pd, but this time because it cannot determine
the version from running a compiled binary. That's not surprising as we
cannot expect to run compiled stuff during cross compilation.
Fortunately, what needs to be computed is just two integers and that can
be done with AC_COMPUTE_INT even during cross compilation. Doing so
actually simplifis the code as can be seen in cross.patch.

And that's about the bits that I managed to fix. It somehow fails some
ImageMagick stuff then, but couldn't figure that part out yet. Let's not
be concerned about that here and fix the other things first.

Can you take these patches?

Helmut
--- gem-0.93.3/debian/rules	2018-02-01 22:58:19.0 +0100
+++ gem-0.93.3/debian/rules	2018-03-20 20:28:36.0 +0100
@@ -20,7 +20,6 @@
 
 
 archconfflags := \
-	--prefix=/usr \
 	--with-pd=/usr/include/pd \
 	--with-extension=pd_linux \
 	--enable-mmx \
@@ -55,9 +54,9 @@
 
 override_dh_auto_configure:
 ifeq ($(BUILD_ARCH_CPU), ppc64el)
-	CXXFLAGS="$(CXXFLAGS) -m64 -mcpu=powerpc" CFLAGS="$(CFLAGS) -m64 -mcpu=powerpc" ./configure $(archconfflags)
+	CXXFLAGS="$(CXXFLAGS) -m64 -mcpu=powerpc" CFLAGS="$(CFLAGS) -m64 -mcpu=powerpc" dh_auto_configure -- $(archconfflags)
 else
-	CXXFLAGS="$(CXXFLAGS)" CFLAGS="$(CFLAGS)" ./configure $(archconfflags)
+	CXXFLAGS="$(CXXFLAGS)" CFLAGS="$(CFLAGS)" dh_auto_configure -- $(archconfflags)
 endif
 
 override_dh_auto_test:
--- gem-0.93.3/debian/rules	2018-02-01 22:58:19.0 +0100
+++ gem-0.93.3/debian/rules	2018-03-20 20:28:36.0 +0100
@@ -10,7 +10,7 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/buildflags.mk
 
-BUILD_ARCH_CPU := $(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU)
+include /usr/share/dpkg/architecture.mk
 DATE_FMT = %Y/%m/%d at %H:%M:%S UTC
 ifdef SOURCE_DATE_EPOCH
 BUILD_DATE ?= $(shell date -u -d "@$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || date -u -r "$(SOURCE_DATE_EPOCH)" "+$(DATE_FMT)" 2>/dev/null || date -u "+$(DATE_FMT)")
@@ -54,7 +53,7 @@
 	dh $@
 
 override_dh_auto_configure:
-ifeq ($(BUILD_ARCH_CPU), ppc64el)
+ifeq ($(DEB_HOST_ARCH_CPU), ppc64el)
 	CXXFLAGS="$(CXXFLAGS) -m64 -mcpu=powerpc" CFLAGS="$(CFLAGS) -m64 -mcpu=powerpc" ./configure $(archconfflags)
 else
 	CXXFLAGS="$(CXXFLAGS)" CFLAGS="$(CFLAGS)" ./configure $(archconfflags)
Index: gem-0.93.3/m4/gem.m4
===
--- gem-0.93.3.orig/m4/gem.m4
+++ gem-0.93.3/m4/gem.m4
@@ -424,26 +424,14 @@
 
 if test "x$with_pdversion" != "x"; then
   PD_VERSION="$with_pdversion"
+  PD_MAJORVERSION=$(( $(echo $PD_VERSION | cut -d"." -f1) ))
+  PD_MINORVERSION=$(( $(echo $PD_VERSION | cut -d"." -f2) ))
 else
 AC_MSG_CHECKING([for Pd-version])
-cat > conftest.c << EOF
-#include 
-#include "m_pd.h"
-int main(){
-  printf("%d.%d\n", PD_MAJOR_VERSION, PD_MINOR_VERSION);
-  return 0;
-}
-EOF
- if $CXX $CFLAGS -o conftest.o conftest.c > /dev/null 2>&1; then
-  PD_VERSION=`./conftest.o`
- else
-  PD_VERSION=""
- fi
+  AC_COMPUTE_INT([PD_MAJORVERSION],[PD_MAJOR_VERSION],[#include "m_pd.h"])
+  AC_COMPUTE_INT([PD_MINORVERSION],[PD_MINOR_VERSION],[#include "m_pd.h"])
+  PD_VERSION="$PD_MAJORVERSION.$PD_MINORVERSION"
 fi
-
-PD_MAJORVERSION=$(( $(echo $PD_VERSION | cut -d"." -f1) ))
-PD_MINORVERSION=$(( $(echo $PD_VERSION | cut -d"." -f2) ))
-
 if test "$PD_MAJORVERSION" -gt 0 -o "$PD_MINORVERSION" -ge 37; then
   GEM_RTE_REFERENCEPATH=extra/Gem
 else

Bug#893649: xvt: should this package be removed?

[Adam Borowski]

Package: xvt
Version: 2.1-20.3
Severity: serious
Justification: QA query

Hi!
I believe that xvt is no longer suitable for inclusion in Debian, and thus
propose its removal.  Not only has it been dead upstream since times
immemorial but also it lacks features so basic it's mind-boggling.

For example, I believed that Windows 3.11's TELNET.EXE was the last terminal
in existence that lacked color support.  Turns out, here we ship xvt, in
2018.  Or, no UTF-8 support is probably worth a RC bug on its own.

More than two decades ago, xvt was superseded by its fork rxvt, which in
turn spawned a multitude of forks on its own.  I for one remember using a
bunch of them on IRIX, when the world was still young...  Those forks have
then died out around the beginning of this millenium, of them only
rxvt-unicode is still struggling along.

As this package is still nominally maintained (well, your last upload was in
2006...), I can't file a RoQA immediately.  Thus, please tell me whether it
should be removed.  If not, please close this bug, otherwise I'll ask for
removal before Buster freeze.


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-rc6-debug-00033-g80c3264499c7 (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 xvt depends on:
ii  libc6 2.27-2
ii  libx11-6  2:1.6.5-1

xvt recommends no packages.

Versions of packages xvt suggests:
pn  menu  

-- no debconf information

Bug#893644: stretch-pu: package leap-archive-keyring/2016.03.08

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Tue, 2018-03-20 at 16:32 -0400, micah wrote:
> The leap-archive-keyring is a simple archive keyring package that
> contains the
> signing key for trusting the archive of the LEAP encryption access
> project. Unfortunately, the expiration date chosen for the key that
> is included
> in the package in Stretch was too low, and it has expired.
> 
> The newer package that is available in testing, unstable, and
> backports provides
> a key with a sufficient length to cover the stable release cycle.
> 
> I would like to propose that this package be included in the next
> stable release point update.

We'd need to see a debdiff of the proposed upload, built on and tested
against stretch, please.

Regards,

Adam

Bug#881358: breaks compatibility with libva1

[Jamon Terrell]

You're right, I'm mistaken.  I suppose that was manually installed during
my troubleshooting as well. Sorry about that.

That aside, though--while it was a manual install, libva1 does work
side-by-side with libva2, but vdpau-va-driver does not.

It would be incredibly nice if one could run both side-by-side without
hacking their way outside of the debian package management world.  Is this
something that any thought has been given to?  I guess snap/flatpak/etc is
the "future" debian solution to this problem, though?  Do you have other
suggestions for better ways of supporting users who would like to be able
to run apps that haven't spent the time necessary to chase the latest
breaking changes in each new release?

On Tue, Mar 20, 2018 at 3:30 PM Sebastian Ramacher 
wrote:

> On 2018-03-20 19:46:14, Jamon Terrell wrote:
> > Not all applications have been updated to work with libva2, and debian
> > unstable does allow installation of libva1 and libva2 concurrently, but
> > this doesn't work for vdpau because vdpau-va-driver 0.7.4-6 only works
> with
> > libva1 and vdpau-va-driver 0.7.4-7 only works with libva2.  This forces
> > users who want libva1 support to manually install the older version of
> > vdpau-va-driver, and doesn't allow concurrent use of both.
>
> I'm not sure how you come to the conclusion that one is still able to
> install
> libva1 in unstable. It was removed long time ago. Also, all users of libva
> in
> Debian have migrated to libva2.
>
> Cheers
> --
> Sebastian Ramacher
>

Bug#893648: ITP: wallabako -- wallabag commandline client

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 

* Package name: wallabako
  Version : 1.2.0+git20180320.1.5c15e02-1
  Upstream Author : Antoine Beaupre
* URL : https://gitlab.com/anarcat/wallabako
* License : AGPLv3
  Programming Lang: Go
  Description : wallabag commandline client

Wallabako is a Wallabag (read-it later service) client for Kobo
readers. It downloads unread articles as individual EPUB files.

Features:

 * fast: downloads only files that have changed, in parallel
 * unattended: runs in the background, when the wifi is turned on,
   only requires you to tap the fake USB connection screen for the
   Kobo to rescan its database
 * status synchronization: read books are marked as read in the
   Wallabag instance

--

This can serve as a backup/synchronization tool for your Wallabag
instance, although it is currently restricted only to ePUB versions.

Bug#893647: kterm: should this package be removed?

[Adam Borowski]

Package: kterm
Version: 6.2.0-46.2
Severity: serious
Justification: QA query


Hi!
I believe that kterm is no longer suitable for inclusion in Debian, and thus
propose its removal.  It lacks features considered basic for a terminal
emulator, such as UTF-8 support; its compatibility with terminal abilities
taken for granted these days is poor, and it has been dead upstream since
times immemorial (predating the first Debian version in 1996).

As the package is at least nominally maintained (well, no maintainer upload
since 2006...), I'm not supposed to RoQA it immediately.  Thus, please tell
me whether it should be removed.  If not, please close this bug, otherwise
I'll ask for removal before Buster freeze.


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-rc6-debug-00033-g80c3264499c7 (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 kterm depends on:
ii  libc6 2.27-2
ii  libtinfo5 6.1-1
ii  libx11-6  2:1.6.5-1
ii  libxaw7   2:1.0.13-1+b2
ii  libxmu6   2:1.1.2-2
ii  libxt61:1.1.5-1
ii  ncurses-term  6.1-1

Versions of packages kterm recommends:
ii  locales  2.27-2

Versions of packages kterm suggests:
pn  xfonts-shinonome | xfonts-a12k12  

-- no debconf information

Bug#893646: smartmontools: any reason for installing /etc/smartmontools/run.d/10powersave-notify

[Christoph Anton Mitterer]

Package: smartmontools
Version: 6.5+svn4324-1
Severity: normal

Hi.

Any reason for installing:
/etc/smartmontools/run.d/10powersave-notify
?

It's already an example script in /u/s/d/smartmontools/ and the script
invoked in it (/usr/lib/powersave/powersave-notify) seems to exist in
no Debian package.


Cheers,
Chris.


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

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

Versions of packages smartmontools depends on:
ii  debianutils  4.8.4
ii  init-system-helpers  1.51
ii  libc62.27-2
ii  libcap-ng0   0.7.7-3.1+b1
ii  libgcc1  1:8-20180320-1
ii  libselinux1  2.7-2+b1
ii  libstdc++6   8-20180320-1
ii  lsb-base 9.20170808

Versions of packages smartmontools recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20160123cvs-4

Versions of packages smartmontools suggests:
pn  gsmartcontrol   
pn  smart-notifier  

-- no debconf information

Bug#893557: thin-provisioning-tools: FTBFS with glibc 2.17

[Steve Langasek]

On Tue, Mar 20, 2018 at 08:47:41AM +0100, Bastian Blank wrote:
> Hi Steve

> On Mon, Mar 19, 2018 at 03:37:17PM -0700, Steve Langasek wrote:
> > Ok, after some trial and error, I've determined that the reason my earlier
> > test succeeded was because I had built the test preload.so without the
> > benefit of dpkg-buildflags, which means -O3, which is used by default for
> > ppc64el on Ubuntu, was missing from the commandline.

> It is a bug in the compiler if it fails to compile a valid program with
> -O3.  So I don't see what this would fix.

Considering debian/rules also hardcodes -O2 for the package itself, it
doesn't seem inappropriate to also build the test shim with the same
options?

Yes, this is working around a toolchain issue.  Feel free to reassign this
bug to the toolchain, if you prefer.

FWIW I was able to identify a symbol reference that drops out of the .so
when built with -O3 but is present when built with -O2; this may be the
cause of the crash:

-  DF *UND*   GLIBC_2.17  0x60 
__stack_chk_fail

And perhaps that points to an explanation of the toolchain bug.

It's annoyingly difficult to debug this crash, as gdb doesn't appear to let
me DTRT with 'set env LD_PRELOAD' and instead manages to crash itself before
handing control over to the process under test.

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


signature.asc
Description: PGP signature

Bug#851232: debci: does not understand space-separated tests

[Paul Gevers]

Hi Simon,

On 20-03-18 21:41, Simon McVittie wrote:
> ci.debian.net can't currently run these tests anyway (they're marked as
> needing isolation-machine) so they'd be skipped regardless. Perhaps this
> is just misleading output, using after-resolve as shorthand for
> "after-resolve and everything with the same dependencies"?

I bet this is it, but I'll check

> https://autopkgtest.ubuntu.com/packages/nss-mdns/bionic/amd64 (which I
> think is also debci)

I believe Ubuntu uses it's own framework, but with a similar UI.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#893460: mbuffer: make autopkgtests pass on all archs

[Steve Langasek]

On Tue, Mar 20, 2018 at 11:59:28AM +0200, Peter Pentchev wrote:
> Unfortunately, this patch is not moving in the right direction.  These
> tests preload a library that is built as part of the mbuffer build that
> intercepts open() and write() calls (among others) and simulates
> changing tape devices; basically it splits the mbuffer output into
> several files.  This is the reason why on amd64 there are many
> output-test4.* and output-test5.* files - there should not be a single
> output-test4 file, there should be output-test4.01 and so on files.
> So the test failure means that the tapetest.so object is not being
> preloaded correctly or that it fails to intercept the necessary libc
> calls.

> Sounds like I'll need to spin up a couple of VMs and see what's what.

> Thanks again for your work on this and Debian and Ubuntu in general!

Ah, ok.  Now that I understand the purpose, I can see why it's broken:

$ objdump -T /usr/lib/arm-linux-gnueabihf/mbuffer/tapetest.so |grep open
0780 gDF .text  00e4  Baseopen
0001100c gDO .bss   0004  Baseopencount
$ objdump -T /usr/bin/mbuffer |grep open
  DF *UND*    GLIBC_2.4   open64
  DF *UND*    GLIBC_2.7   __open64_2
$

mbuffer is quite reasonably built with LFS support on all archs, which means
that, on 32-bit architectures in particular, the shim for open() does not
match the actual function called by mbuffer.

So the tapetest shim is broken on these architectures.  My patch is
definitely the wrong way to fix this, but if 'tapetest' is indeed simply a
test library, I don't think I have broken the mbuffer package in Ubuntu by
(effectively) skipping this test.

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


signature.asc
Description: PGP signature

Bug#832751: autopkgtest: aborts the entire test run when one test has unsatisfiable dependencies

[Paul Gevers]

Control: tags -1 patch

On Thu, 28 Jul 2016 11:05:24 -0300 Antonio Terceiro
 wrote:
> The third test block failed during the dependency installation phase, and then
> the entire test run was aborted. I would that specific test to be marked as
> failed, or whatever, and that the remaining tests would still run, and I would
> have the PASS/FAIL summary at the end.

Potential solution in MR/1:
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/1

Paul



signature.asc
Description: OpenPGP digital signature

Bug#893645: os-autoinst: FTBFS: FAIL: 02-test_ocr.t

[Steve Langasek]

Source: os-autoinst
Version: 4.4.1508936943.39adc5eb-2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic

In addition to bug #880791, os-autoinst now fails to build with a second
test failure:

[...]
FAIL: 02-test_ocr.t
===

Use of uninitialized value in index at ../needle.pm line 44.
Use of uninitialized value $bmwqemu::vars{"PRJDIR"} in addition (+) at 
../needle.pm line 45.
20:27:15.8564 433 MATCH(bootmenu-ocr.ref:1.00)
Tesseract Open Source OCR Engine v4.00.00alpha with Leptonica
Warning. Invalid resolution 0 dpi. Using 70 instead.
Estimating resolution as 132
Tesseract Open Source OCR Engine v4.00.00alpha with Leptonica
Warning. Invalid resolution 0 dpi. Using 70 instead.
Estimating resolution as 138
ok 1 - ocr match 1
Tesseract Open Source OCR Engine v4.00.00alpha with Leptonica
Warning. Invalid resolution 0 dpi. Using 70 instead.
Estimating resolution as 132
Tesseract Open Source OCR Engine v4.00.00alpha with Leptonica
Warning. Invalid resolution 0 dpi. Using 70 instead.
Estimating resolution as 138
not ok 2 - multiple OCR regions
#   Failed test 'multiple OCR regions'
#   at ./02-test_ocr.t line 42.
1..2
# Looks like you failed 1 test of 2.
FAIL 02-test_ocr.t (exit status: 1)
[...]

First seen in Ubuntu at
,
this failure is also reproducible in unstable.

Perhaps this is a regression in, or incompatibility with, tesseract-ocr
4.00.  (The last successful builds of os-autoinst in Debian used
tesseract-ocr 3.04.01-6.)

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


signature.asc
Description: PGP signature

Bug#892760: Pending fixes for bugs in the antlr3 package

[pkg-java-maintainers]

tag 892760 + pending
thanks

Some bugs in the antlr3 package are closed in revision
1db6ad90371aab09110b44ce94b6c2ad3b3043f8 in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/antlr3.git/commit/?id=1db6ad9

Commit message:

Fix FTBFS with Java 9.

Thanks: Tiago Stürmer Daitx for the patch.
Closes: #892760

Bug#880886: maven-bundle-plugin FTBFS with libmaven-dependency-tree-java

[Emmanuel Bourg]

On 20/03/2018 16:29, 殷啟聰 | Kai-Chung Yan wrote:
> I adopted the patch from Fedora and it looks good. The package builds fine 
> now and 154 of its reverse-build-dependencies built successfully. 27 failed:

Great!


> They either failed in compilation due to Java 9 or failed in tests. But I 
> would say the result is confident enough to prove that the patch works.

I agree. An error in this plugin would have broken the build before the
test phase.


> However this package fails to build in Sid currently because of Java 9. I 
> attached the log. The Maven Javadoc Plugin failed to honor the compile 
> classpath.

The javadoc is useless for Maven plugins anyway, nobody codes against
their API. I suggest removing it.

Emmanuel Bourg

Bug#887082: confirming that issue is still out there and biting really strong

[Simon McVittie]

On Tue, 20 Mar 2018 at 09:10:30 -0400, Yaroslav Halchenko wrote:
> 
> On Tue, 20 Mar 2018, Yaroslav Halchenko wrote:
> > https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/4
> 
> Unfortunately that patch isn't directly applicable any longer

Sorry, if I knew how to rebase it for 3.27/3.28, I would have already
done so, but I don't know enough Javascript to be at all confident that
I'd get it right.

If someone else who is suffering from this knows more Javascript than
I do, now would be a great time to contribute upstream.

smcv

Bug#851232: debci: does not understand space-separated tests

[Simon McVittie]

On Tue, 20 Mar 2018 at 16:22:15 +0100, Paul Gevers wrote:
> On Fri, 13 Jan 2017 07:12:36 + Simon McVittie  wrote:
> > The autopkgtest spec[1] says "Test names are separated by comma and/or
> > whitespace" (which I admit is weird, but it's what it says) and the
> > reference implementation implements that:
> > 
> > 
> > debian/tests/control in nss-mdns 0.10-8 has space-separated Tests (because
> > I misremembered what is allowed) and it looks as though ci.debian.net
> > responds to this by only running the first test per stanza:
> > https://ci.debian.net/data/packages/unstable/amd64/n/nss-mdns/20170113_063407.autopkgtest.log.gz
> > 
> > There is no practical impact right now for this particular package,
> > because I don't think nss-mdns' tests can be relied on to work in a
> > container anyway, so they're all skipped.
> 
> Do you believe the issue is still present? It seems you removed the test
> from nss-mdns and when I test this (albeit within the autopkgtest test
> suite) it seems currently to work as expected.

https://ci.debian.net/data/autopkgtest/unstable/amd64/n/nss-mdns/91/log.gz says:

autopkgtest [01:40:14]: testing package nss-mdns version 0.10-8
autopkgtest [01:40:14]: build not needed
after-resolveSKIP Test requires machine-level isolation but testbed 
does not provide that
nss-behaviourSKIP Test requires machine-level isolation but testbed 
does not provide that
autopkgtest [01:40:14]:  summary
after-resolveSKIP Test requires machine-level isolation but testbed 
does not provide that
nss-behaviourSKIP Test requires machine-level isolation but testbed 
does not provide that

but there are more tests than just those two:

Tests: after-resolve before-resolve jessie-after-resolve jessie-before-resolve 
multiarch-purge multiarch-remove remove-reinstall
Depends: avahi-daemon, avahi-utils, dbus
Restrictions: allow-stderr, breaks-testbed, isolation-machine, needs-root

Tests: nss-behaviour
Depends: dbus
Restrictions: allow-stderr, breaks-testbed, isolation-machine, needs-root

ci.debian.net can't currently run these tests anyway (they're marked as
needing isolation-machine) so they'd be skipped regardless. Perhaps this
is just misleading output, using after-resolve as shorthand for
"after-resolve and everything with the same dependencies"?

https://autopkgtest.ubuntu.com/packages/nss-mdns/bionic/amd64 (which I
think is also debci) supports isolation-machine, and that does run all
the tests, except for multiarch-* which are patched out (they don't
work on Ubuntu's infrastructure).

smcv

Bug#893644: stretch-pu: package leap-archive-keyring/2016.03.08

[micah]

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

Hello,

The leap-archive-keyring is a simple archive keyring package that contains the
signing key for trusting the archive of the LEAP encryption access
project. Unfortunately, the expiration date chosen for the key that is included
in the package in Stretch was too low, and it has expired.

The newer package that is available in testing, unstable, and backports provides
a key with a sufficient length to cover the stable release cycle.

I would like to propose that this package be included in the next stable release
point update.

Thank you!
micah

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

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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#881358: breaks compatibility with libva1

[Sebastian Ramacher]

On 2018-03-20 19:46:14, Jamon Terrell wrote:
> Not all applications have been updated to work with libva2, and debian
> unstable does allow installation of libva1 and libva2 concurrently, but
> this doesn't work for vdpau because vdpau-va-driver 0.7.4-6 only works with
> libva1 and vdpau-va-driver 0.7.4-7 only works with libva2.  This forces
> users who want libva1 support to manually install the older version of
> vdpau-va-driver, and doesn't allow concurrent use of both.

I'm not sure how you come to the conclusion that one is still able to install
libva1 in unstable. It was removed long time ago. Also, all users of libva in
Debian have migrated to libva2.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#889669: nvidia-graphics-drivers: solve the upgrade problem

[Philipp Kern]

Hi,

On 2/5/18 4:26 PM, Philipp Kern wrote:
> Since forever users of NVIDIA on Debian accepted that package upgrades
> break newly spawned binaries because the interface between the client
> library and the kernel driver is strictly versioned. The kernel module
> will emit an API mismatch error into the kernel log and GLX requests
> will fail. A reboot is required to remediate this situation.
> 
> I would propose the following model:
> 
> * All binary packages that require strict versioning with NVRM are
> shipped in versioned packages. This means that the library package names
> reflect both major and minor version (= the version on which the driver
> checks) of the driver. The resulting packages should be co-installable
> with each other.
> * An script modifies the symlink for the currently active libraries to
> point to the version of the currently loaded nvidia module (as fetched
> from sysfs's /sys/module/nvidia/version). This script is called on
> installation but more crucially on every boot. This will tie the
> libraries to the module loaded at boot-up.
> * The kernel module itself does not have to be versioned. The kernel
> module can be upgraded and it will end up in the initrd automatically.
> 
> Assuming that we have a metapackage that pulls in the most recent driver
> (like linux-image does), this model would allow to upgrade the driver at
> any point in time and only make it live with the next reboot. This
> allows applications to continue to function.
> 
> This approach has the drawback that every update from NVIDIA needs to go
> through NEW. However I think this is just a theoretical disadvantage at
> this point as NEW latency for ABI version changes has decreased a lot.
> 
> The thing I'm not sure about is how this proposal interacts with the
> legacy modules. I suppose they can all use the same mechanism but the
> script would need to be aware what library stack needs to be chosen. The
> NVIDIA kernel shim already checks using rm_is_supported_device if the
> currently installed device is supported. That together with modalias
> should supposedly already load the correct module and then the script
> could just check which of the modules (if legacy or the normal one) is
> loaded and act accordingly.
> 
> Do you think this would be workable? The NVIDIA packaging is quite a
> beast to handle, I know (and I'm very grateful for your work!). So we
> should have some consensus if this is something you'd be interested in. :)

is there something I could help with to get to a consensus here?
Anything? :)

(After just having had this again that I needed to reboot when all I
wanted was getting the i386 driver.)

Kind regards and thanks
Philipp Kern

Bug#893218: Pending fixes for bugs in the jackson-datatype-joda package

[pkg-java-maintainers]

tag 893218 + pending
thanks

Some bugs in the jackson-datatype-joda package are closed in revision
66e01c619a2cbed627ad19368ba982d1f10ad5ac in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/jackson-datatype-joda.git/commit/?id=66e01c6

Commit message:

Fix FTBFS with Java9

Closes: #893218

Bug#893640: nmu: webkit2gtk_2.18.6-1

[Jeremy Bicha]

Um, second try:


nmu webkit2gtk_2.18.6-1 . ANY . unstable . -m "Rebuild against
gst-plugins-bad1.0 1.14.0-1"
dw webkit2gtk_2.18.6-1 . ANY . -m
'gstreamer1.0-plugins-bad (>= 1.14.0)'


Thanks,
Jeremy Bicha

Bug#893642: nmu: webkit2gtk_2.20.0-1

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-CC: sl...@debian.org

webkit2gtk is uninstallable in experimental because it needs to be
rebuilt against the new gstreamer release. (gstreamer set its
dependency relationships very tightly).

Here's a guess at the wanna-build syntax:

nmu webkit2gtk_2.20.0-1 . ANY . unstable . -m "Rebuild against
gst-plugins-bad1.0 1.14.0-1"
dw webkit2gtk_2.20.0-1 . ANY . -m 'gstreamer1.0-plugins-bad (>= 1.14.0)'


Thanks,
Jeremy Bicha

Bug#893643: nmu: gnome-dvb-daemon_1:0.2.91~git20170110-3

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-CC: sl...@debian.org

gnome-dvb-daemon is uninstallable in unstable because it needs to be
rebuilt against the new gstreamer release. (gstreamer set its
dependency relationships very tightly.)

Here's a guess at the wanna-build syntax:

nmu gnome-dvb-daemon_1:0.2.91~git20170110-3 . ANY . unstable . -m
"Rebuild against gst-plugins-bad1.0 1.14.0-1"
dw gnome-dvb-daemon_1:0.2.91~git20170110-3 . ANY . -m
'gstreamer1.0-plugins-bad (>= 1.14.0)'


Thanks,
Jeremy Bicha

Bug#893641: nmu: webkit2gtk_2.18.6-1

[Michael Biebl]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

libgstreamer-plugins-bad1.0-0 has an unstable ABI, so ships a shlibs
file which contains e.g.
libgstadaptivedemux-1.0 0 libgstreamer-plugins-bad1.0-0 (>= 1.12.4), 
libgstreamer-plugins-bad1.0-0 (<< 1.13)

This means, on new major upstream relases, rdeps need to be rebuilt.
gstreamer 1.14.0 uploaded, so webkit2gtk and gnome-dvb-daemon need to be
rebuilt.



nmu webkit2gtk_2.18.6-1 . ANY . unstable . -m "Rebuild against 
libgstreamer-plugins-bad1.0-0 1.14.0"
nmu gnome-dvb-daemon_1:0.2.91~git20170110-3 . ANY . unstable . -m "Rebuild 
against libgstreamer-plugins-bad1.0-0 1.14.0"

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

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

Bug#893640: nmu: webkit2gtk_2.18.6-1

[Jeremy Bicha]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
X-Debbugs-CC: sl...@debian.org

webkit2gtk is uninstallable in unstable because it needs to be rebuilt
against the new gstreamer release. (gstreamer set its dependency
relationships very tightly).

Here's a guess at the wanna-build syntax:

nmu webkit2gtk_2.18.6-1 . ANY . unstable . -m "Rebuild against
gst-plugins-bad1.0 1.14.0-1"
dw gstreamer1.0-plugins-bad_1.14.0-1 . ANY . -m
'gstreamer1.0-plugins-bad (>= 1.14.0)'


Thanks,
Jeremy Bicha

Bug#893639: Please update debian/patches/01_ayatana.patch to fully support NG Indicators

[Mike Gabriel]

Package: xfce4-indicator-plugin
Severity: important
Version: 2.3.3-1

Dear maintainers,

please find attached a .debdiff that makes the full scope of Ayatana  
Indicators support work in XFCE4 on Debian.


The changes are all in debian/patches/01_ayatana.patch, details see  
the debian/changelog in the .debdiff (which I quote here for courtesy):


```
xfce4-indicator-plugin (2.3.3-1.1) UNRELEASED; urgency=medium

  * Non-maintainer upload.
  * debian/patches: Fix 01_ayatana.patch:
+ Adapt INDICATOR_SERVICE_DIR to /usr/share/ayatana/indicators.
+ Adapt indicator service and .so names in indicator-dialog.c
+ Use macro HAVE_LIBAYATANA_INDICATOR_INDICATOR_NG_H instead of
  HAVE_LIBINDICATOR_INDICATOR_NG_H to check that NG indicators are
  supported.

 -- Mike Gabriel   Tue, 20 Mar 2018  
20:12:50 +0100

```

Please update the currently broken / half-functional plugin version in  
Debian unstable.


Thanks!
Mike
--

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

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

diff -Nru xfce4-indicator-plugin-2.3.3/debian/changelog 
xfce4-indicator-plugin-2.3.3/debian/changelog
--- xfce4-indicator-plugin-2.3.3/debian/changelog   2018-03-20 
19:12:50.0 +
+++ xfce4-indicator-plugin-2.3.3/debian/changelog   2017-10-15 
14:32:43.0 +
@@ -1,15 +1,3 @@
-xfce4-indicator-plugin (2.3.3-1.1) UNRELEASED; urgency=medium
-
-  * Non-maintainer upload.
-  * debian/patches: Fix 01_ayatana.patch:
-+ Adapt INDICATOR_SERVICE_DIR to /usr/share/ayatana/indicators.
-+ Adapt indicator service and .so names in indicator-dialog.c
-+ Use macro HAVE_LIBAYATANA_INDICATOR_INDICATOR_NG_H instead of
-  HAVE_LIBINDICATOR_INDICATOR_NG_H to check that NG indicators are
-  supported.
-
- -- Mike Gabriel   Tue, 20 Mar 2018 20:12:50 
+0100
-
 xfce4-indicator-plugin (2.3.3-1) unstable; urgency=medium
 
   [ Evgeni Golov ]
diff -Nru xfce4-indicator-plugin-2.3.3/debian/patches/01_ayatana.patch 
xfce4-indicator-plugin-2.3.3/debian/patches/01_ayatana.patch
--- xfce4-indicator-plugin-2.3.3/debian/patches/01_ayatana.patch
2018-03-20 19:12:50.0 +
+++ xfce4-indicator-plugin-2.3.3/debian/patches/01_ayatana.patch
2017-10-15 14:32:43.0 +
@@ -1,9 +1,11 @@
 Description: Debian doesn't have newer indicators, use the ayatana fork 
instead.
 Author: Unit 193 
 
+diff --git a/configure.ac b/configure.ac
+index 588a388..10944da 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -88,8 +88,8 @@
+@@ -88,8 +88,8 @@ XDT_CHECK_PACKAGE([LIBXFCE4UTIL], [libxfce4util-1.0], 
[4.9.0])
  XDT_CHECK_PACKAGE([LIBXFCE4UI], [libxfce4ui-2], [4.11.0])
  XDT_CHECK_PACKAGE([LIBXFCE4PANEL], 
[libxfce4panel-${LIBXFCE4PANEL_VERSION_API}], [4.11.0])
  XDT_CHECK_PACKAGE([XFCONF], [libxfconf-0], [4.6.0])
@@ -14,7 +16,7 @@
  
  dnl 
  dnl *** Check if libindicator has indicator-ng.h headery ***
-@@ -97,13 +97,13 @@
+@@ -97,13 +97,13 @@ dnl *** At the moment this cannot be derived from the 
version number ***
  dnl 
  AC_LANG_PUSH([C])
  CPPFLAGS=`$PKG_CONFIG --cflags ${INDICATOR_PKGNAME}`
@@ -30,6 +32,8 @@
  
  dnl ***
  dnl *** Check for debugging support ***
+diff --git a/panel-plugin/indicator-box.c b/panel-plugin/indicator-box.c
+index 66523d6..98d8549 100644
 --- a/panel-plugin/indicator-box.c
 +++ b/panel-plugin/indicator-box.c
 @@ -28,7 +28,7 @@
@@ -41,6 +45,8 @@
  
  #include "indicator-box.h"
  #include "indicator-button.h"
+diff --git a/panel-plugin/indicator-box.h b/panel-plugin/indicator-box.h
+index 8647e04..b5ca139 100644
 --- a/panel-plugin/indicator-box.h
 +++ b/panel-plugin/indicator-box.h
 @@ -20,7 +20,7 @@
@@ -52,6 +58,8 @@
  #include 
  #include "indicator-config.h"
  
+diff --git a/panel-plugin/indicator-button.c b/panel-plugin/indicator-button.c
+index aa89c41..4c26a1a 100644
 --- a/panel-plugin/indicator-button.c
 +++ b/panel-plugin/indicator-button.c
 @@ -28,13 +28,13 @@
@@ -70,6 +78,8 @@
  
  #define ICON_SIZE 22
  #define SPACING 2
+diff --git a/panel-plugin/indicator-button.h b/panel-plugin/indicator-button.h
+index f0f1610..aa2c808 100644
 --- a/panel-plugin/indicator-button.h
 +++ b/panel-plugin/indicator-button.h
 @@ -20,7 +20,7 @@
@@ -81,26 +91,18 @@
  
  #include "indicator-config.h"
  #include "indicator-box.h"
+diff --git a/panel-plugin/indicator.c b/panel-plugin/indicator.c
+index 475e230..4b25c4d 100644
 --- a/panel-plugin/indicator.c
 +++ b/panel-plugin/indicator.c
-@@ -24,7 +24,7 @@
-  */
- 
- 
--#define INDICATOR_SERVICE_DIR "/usr/share/unity/indicators"
-+#define INDICATOR_SERVICE_DIR 

Bug#893472: libfurl-perl: broken on s390x?

[Niko Tyni]

On Tue, Mar 20, 2018 at 10:02:34AM +0100, Jonas Smedegaard wrote:

> I believe circular build-dependencies for testsuite needs can - and 
> should be addressed by marking such build-dependencies appropriately, 
> rather than skipping them - for exactly situations like this.

Sure.
 
> Question then what the appropriate way to express cycle-breaking 
> hints... :-)

I believe the way to express this is to annotate the build dependency
with . (Though build cycles are probably not much of a deal
with arch:all packages in the first place.)
-- 
Niko

Bug#893472: libfurl-perl: broken on s390x?

[Niko Tyni]

Control: retitle -1 libplack-middleware-deflater-perl: broken on big endian 
hosts
Control: reassign -1 libplack-middleware-deflater-perl 0.12-1
Control: tag -1 patch
Control: affects -1 libfurl-perl

On Mon, Mar 19, 2018 at 09:35:03PM +0200, Niko Tyni wrote:

> I got as far as seeing that removing line 144 in Deflater.pm
> 
>  
> https://sources.debian.org/src/libplack-middleware-deflater-perl/0.12-1/lib/Plack/Middleware/Deflater.pm/#L144
> 
> -   $buf .= pack("LL", $self->{crc},$self->{length}) if $self->{encoding} 
> eq 'gzip';
> 
> makes both test suites pass, but that doesn't seem like a fully
> satisfactory patch. (And no, s/LL/NN/ doesn't fix it.)

Hum, this is somewhat embarrassing. s/LL/VV/ does seem to fix it, which
makes sense as L and N are equivalent on big-endian while L and V are
equivalent on little-endian. I blame lack of sleep.

Also, RFC 1952 says

  All multi-byte numbers in the format described here are stored
  with the least-significant byte first (at the lower memory address).

so little endian seems to be correct.

Lightly tested patch attached; reassigning.
-- 
Niko
>From 480e68c781ddad1e5a19446c13134c8fde2a34e8 Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Tue, 20 Mar 2018 21:51:49 +0200
Subject: [PATCH] Fix gzip trailer on big endian hosts

These values need to be stored as little endian regardless
of the host endianness.

Bug-Debian: https://bugs.debian.org/893472
---
 lib/Plack/Middleware/Deflater.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Plack/Middleware/Deflater.pm b/lib/Plack/Middleware/Deflater.pm
index 4cb0b03..c823c38 100644
--- a/lib/Plack/Middleware/Deflater.pm
+++ b/lib/Plack/Middleware/Deflater.pm
@@ -141,7 +141,7 @@ sub print : method {
 if ( !$self->{header} && $self->{encoding} eq 'gzip' ) {
 $buf = pack("nccVcc",GZIP_MAGIC,Z_DEFLATED,0,time(),0,$Compress::Raw::Zlib::gzip_os_code) . $buf
 }
-$buf .= pack("LL", $self->{crc},$self->{length}) if $self->{encoding} eq 'gzip';
+$buf .= pack("VV", $self->{crc},$self->{length}) if $self->{encoding} eq 'gzip';
 $self->{closed} = 1;
 return $buf;
 }
-- 
2.16.2

Bug#893606: ntpsec: Please build with --enable-leap-smear

[Richard Laager]

On 03/20/2018 06:31 AM, Paride Legovini wrote:
> Please build NTPsec with --enable-leap-smear, which allows compatibility
> with the Google NTP servers [1]

I'm asking upstream for confirmation that this is compatible:
https://lists.ntpsec.org/pipermail/devel/2018-March/006074.html

I'm concerned that NTPsec's behavior might be to smear over the interval
_before_ the leap second, as opposed to _centered on_ the leap second
(which is what Google does).

If you're just consuming time from Google's servers, you don't need leap
smearing in your client ntpd. You just point it at smeared servers (and
only smeared servers) and disable the leap file. Are you intending on
running your own servers and then have clients sync from a mix of you
and Google? Or are you intending on running your own servers and having
clients sync from you only, but you want time consistent with Google and
similar?

-- 
Richard

Bug#893638: libwebkit2gtk-4.0-37: dependency issue with libgstreamer-plugins-bad1.0-0 (1.14.0-1) from unstable

[Gabriel Cavallo]

Package: libwebkit2gtk-4.0-37
Version: 2.18.6-1
X-Debbugs-CC: sl...@debian.org

Howdy maintainers,

On debian unstable/sid amd64, libgstreamer-plugins-bad1.0-0 has been updated to 
(1.14.0-1)
yet libwebkit2gtk-4.0-37 (2.18.6-1) still depends on versions < 1.13.
This broke my entire gnome dependency chain.

The following packages have unmet dependencies:
 gnome : Depends: gnome-core (= 1:3.22+9) but it is not going to be installed   
 
 Depends: cheese (>= 3.22) but it is not going to be installed  
  
 Depends: evolution (>= 3.22) but it is not going to be installed  
 Depends: evolution-plugins (>= 3.22) but it is not going to be 
installed  
 Depends: gnome-calendar (>= 3.22) but it is not going to be installed  
  
 Depends: gnome-documents (>= 3.22) but it is not going to be installed 

 Depends: gnome-getting-started-docs (>= 3.22) but it is not going to 
be installed
 Depends: gnome-maps (>= 3.22) but it is not going to be installed  
 
 Depends: gnome-todo (>= 3.22) but it is not going to be installed
 Depends: rhythmbox-plugins but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

The following packages have unmet dependencies:
 libwebkit2gtk-4.0-37 : Depends: libgstreamer-plugins-bad1.0-0 (< 1.13) but 
1.14.0-1 is to be installed
E: Unable to correct problems, you have held broken packages.

I don't know much about apt pinning but I was able to install everything with:

Package: gstreamer1.0-* libgstreamer* gir1.2-gst-plugins-base-1.0 
gir1.2-clutter-gst-3.0 gir1.2-gstreamer-1.0
Pin: version 1.12*
Pin-Priority: 1001

Is there a better way to get testing packages if there's a conflict in unstable?

I apologize if this is a normal thing but I wanted to report it just in case...

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

Bug#893637: pyraf FTBFS with dh-python 3.20180313

[Adrian Bunk]

Source: pyraf
Version: 2.1.14+dfsg
Severity: serious

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

...
   debian/rules override_dh_auto_test
make[1]: Entering directory '/build/1st/pyraf-2.1.14+dfsg'
HOME=/tmp/ PYTHONPATH=/build/1st/pyraf-2.1.14+dfsg/.pybuild/pythonX.Y_2.7/build 
python2.7 debian/tests/pyraf-test.py
Traceback (most recent call last):
  File "debian/tests/pyraf-test.py", line 18, in 
from pyraf import iraf
ImportError: No module named pyraf
make[1]: *** [debian/rules:12: test-python2.7] Error 1


See #893242 for background.

Bug#893634: hexchat-plugins: Please split into separate packages

[Jeremy Bicha]

On Tue, Mar 20, 2018 at 3:49 PM, Mattia Rizzolo  wrote:
> Anyway, would it be fine for you if I split those plugins in 3 binary
> packages, and make hexchat-plugins depend on all of them?
> And if so, I'd use names like 'hexchat-plugin-sysinfo', etc?

Yes, please. :)

Thanks,
Jeremy Bicha

Bug#893242: python-pygit2 FTBFS with dh-python 3.20180313

[Adrian Bunk]

Control: reassign -1 python-pygit2 0.26.2-2
Control: severity -1 serious
Control: tags -1 - wontfix

On Sun, Mar 18, 2018 at 05:11:09PM +0100, Piotr Ożarowski wrote:
> Control: severity 893242 normal
> Control: tags 893242 + wontfix
> 
> >   File "/usr/lib/python3.6/unittest/loader.py", line 451, in _find_test_path
> > msg % (mod_name, module_dir, expected_dir))
> > ImportError: 'test_archive' module incorrectly imported from 
> > '/build/1st/python-pygit2-0.26.3/.pybuild/cpython3_3.6_pygit2/build/test'. 
> > Expected '/build/1st/python-pygit2-0.26.3/test'. Is this module globally 
> > installed?
> 
> I change the current directory to the build directory on purpose. I want
> to test files that will be installed in the package, not the source
> files and that's what happens if you start tests from source dir (due to
> Python's "." in sys.path).
> 
> I'm amazed that even stdlib enforces such insane setting...
> 
> PS note that previous version of dh-python/pybuild also used build dir
> as current directory

Then tese are RC bugs in the reverse build dependencies that now FTBFS,
reassigning.

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#893634: hexchat-plugins: Please split into separate packages

[Mattia Rizzolo]

On Tue, Mar 20, 2018 at 03:40:28PM -0400, Jeremy Bicha wrote:
> Unless those plugins actually depend on each other (and aren't just
> packaged that way), it doesn't make sense. (And the UI is really bad.
> Just try it in a few hours. You may need to make sure the background
> gnome-software service is killed first so that the latest metadata is
> used.)

I don't have appstream installed, nor I plan on installing it.  Like I
don't have gnome-software installed either…

> It is ok for the hexchat package to also contains plugins with their
> AppStream metadata (but there won't be checkboxes for any of those
> plugins so I don't recommend this here).

Oh, I see.
I understood that, but I did the leap from "main packages contains
plugins and the appstream files can be there" to the separate plugins
packages on my own reckoning it would have been fine.

> It is not ok for a separate hexchat-plugins package to include
> multiple plugins because it won't work properly in GNOME Software.

JFTR, I dislike such plain approach "the tooling is suboptimal, so the
world needs to adapt to such suboptimal tooling", and (even worse!)
"the tooling is suboptimal, so the specification needs to adapt to it"
which is the worst that could happen in any engineering situation.


Anyway, would it be fine for you if I split those plugins in 3 binary
packages, and make hexchat-plugins depend on all of them?
And if so, I'd use names like 'hexchat-plugin-sysinfo', etc?

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#881358: breaks compatibility with libva1

[Jamon Terrell]

Not all applications have been updated to work with libva2, and debian
unstable does allow installation of libva1 and libva2 concurrently, but
this doesn't work for vdpau because vdpau-va-driver 0.7.4-6 only works with
libva1 and vdpau-va-driver 0.7.4-7 only works with libva2.  This forces
users who want libva1 support to manually install the older version of
vdpau-va-driver, and doesn't allow concurrent use of both.

Bug#893634: hexchat-plugins: Please split into separate packages

[Jeremy Bicha]

On Tue, Mar 20, 2018 at 3:20 PM, Mattia Rizzolo  wrote:
> On Tue, Mar 20, 2018 at 02:14:57PM -0400, Jeremy Bicha wrote:
>> There is a problem though. If a user unchecks the box for say,
>> Checksum, then Fishlim and Sysinfo will be uninstalled also. (And last
>> I checked, GNOME Software does not have good UI to show this.)
>
> Which kinda makese sense IMHO.

Unless those plugins actually depend on each other (and aren't just
packaged that way), it doesn't make sense. (And the UI is really bad.
Just try it in a few hours. You may need to make sure the background
gnome-software service is killed first so that the latest metadata is
used.)

> So it seems like the specification explicitly allows for extension
> packages like hexchat-plugins to carry more than one metainfo file in
> it.

I was the one that wrote that part of the specification so I apologize
if I was unclear.

It is ok for the hexchat package to also contains plugins with their
AppStream metadata (but there won't be checkboxes for any of those
plugins so I don't recommend this here).
It is not ok for a separate hexchat-plugins package to include
multiple plugins because it won't work properly in GNOME Software.

Thanks,
Jeremy Bicha

Bug#893634: hexchat-plugins: Please split into separate packages

[Mattia Rizzolo]

Control: severity -1 wishlist

On Tue, Mar 20, 2018 at 02:14:57PM -0400, Jeremy Bicha wrote:
> There is a problem though. If a user unchecks the box for say,
> Checksum, then Fishlim and Sysinfo will be uninstalled also. (And last
> I checked, GNOME Software does not have good UI to show this.)

Which kinda makese sense IMHO.

> To allow those checkboxes to work as expected, please split the
> hexchat-plugins into 3 separate binary packages. This is similar to
> what I had to do for evolution, gedit-plugins, eog-plugins, etc.
> 
> References
> --
> https://www.freedesktop.org/software/appstream/docs/sect-Quickstart-Distros.html

Which also says:
| A binary package must not contain more than one AppStream metadata
| file. The one exception is that it is permissable for a binary package
| that is extended by addons to include those addons (Section 2.6,
| “Addons”) and their AppStream metadata files. Note that users will
| be unable to remove those addons separately.
| Except for the extended package, no other package may contain more
| than one Appstream addon metadata file.

So it seems like the specification explicitly allows for extension
packages like hexchat-plugins to carry more than one metainfo file in
it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#890672: x42-plugins: diff for NMU version 20170428-1.1

[Adrian Bunk]

Control: tags 890672 + pending

Dear maintainer,

I've prepared an NMU for x42-plugins (versioned as 20170428-1.1) and 
uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

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

diff -Nru x42-plugins-20170428/debian/changelog x42-plugins-20170428/debian/changelog
--- x42-plugins-20170428/debian/changelog	2017-06-26 00:32:24.0 +0300
+++ x42-plugins-20170428/debian/changelog	2018-03-20 20:30:37.0 +0200
@@ -1,3 +1,11 @@
+x42-plugins (20170428-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Aurelien Jarno to fix FTBFS with glibc 2.27.
+(Closes: #890672)
+
+ -- Adrian Bunk   Tue, 20 Mar 2018 20:30:37 +0200
+
 x42-plugins (20170428-1) unstable; urgency=medium
 
   * New upstream version 20170428
diff -Nru x42-plugins-20170428/debian/patches/pow10f.patch x42-plugins-20170428/debian/patches/pow10f.patch
--- x42-plugins-20170428/debian/patches/pow10f.patch	1970-01-01 02:00:00.0 +0200
+++ x42-plugins-20170428/debian/patches/pow10f.patch	2018-03-20 20:30:34.0 +0200
@@ -0,0 +1,15 @@
+Description: Replace deprecated pow10f by exp10f.
+Author: Aurelien Jarno 
+Forwarded: no
+
+--- x42-plugins-20170428.orig/meters.lv2/gui/phasewheel.c
 x42-plugins-20170428/meters.lv2/gui/phasewheel.c
+@@ -812,7 +812,7 @@ static bool cb_set_gain (RobWidget* hand
+ 		queue_draw(ui->m2);
+ 	}
+ #ifdef __USE_GNU
+-	const float thresh = pow10f(.05 * (MIN_CUTOFF - val));
++	const float thresh = exp10f(.05 * (MIN_CUTOFF - val));
+ #else
+ 	const float thresh = powf(10, .05 * (MIN_CUTOFF - val));
+ #endif
diff -Nru x42-plugins-20170428/debian/patches/series x42-plugins-20170428/debian/patches/series
--- x42-plugins-20170428/debian/patches/series	1970-01-01 02:00:00.0 +0200
+++ x42-plugins-20170428/debian/patches/series	2018-03-20 20:30:34.0 +0200
@@ -0,0 +1 @@
+pow10f.patch