Bug#806214: Status of build time test suites of tree-puzzle

[Andreas Tille]

Hi Shayan,

On Thu, Sep 05, 2019 at 01:45:36AM +0100, Shayan Doust wrote:
> Some investigative work. I also compiled a clean copy directly from the
> upstream website to prevent any sort of contamination and to rule out
> possible upstream fault and then a packaging build attempt (debhelper 11).

Thanks a lot for diving into this.
 
> > I have some gut feeling that the test files for comparison do not
> > really fit the proper result.
> 
> This may be the case, but I am having a hard time getting the same
> output as
> https://buildd.debian.org/status/fetch.php?pkg=tree-puzzle=all=5.2-11=1539685923=0
> 
> I have just ran qp-pure-prot.test as an example:
> 
> 113,114c86,87
> < WARNING: Result of chi-square test may not be valid because of
> < small maximum likelihood frequencies and short sequence length!
> ---
> > WARNING: Result of chi-square test may not be valid because of small
> > maximum likelihood frequencies and short sequence length!
> 
> * Diffs like this indicate formatting faults which are easy to rectify,
> or remove as a whole.
> 
> * The first line of the test output file contains TEST-PUZZLE and the
> version number. This version number (5.3.rc16) is not visible in the
> upstream expected output file, so diff will of course display this as a
> delta.
> 
> * There is a higher verbosity of paragraphed description / output in the
> test's newly-generated results file compared to what upstream has. Maybe
> upstream is running an older / more obselete version of the program?
> 
> * From what I can see, the numbers seem to match for the most part, but
> upstream has introduced chi2-value column which is not present in the
> expected results file.
> 
> For instance, running qp-pure-bin.test. Here is a small slice of my output:
> 
> 194c169
> < (bipartition with sequences in input order : number of times seen (and
> ratio))
> ---
> > (bipartition with sequences in input order : number of times seen)
> 196,197c171,172
> <  *..** :  1000 (1.000)
> <  *...* :  1000 (1.000)
> ---
> >  *..**  :  1000
> >  *...*  :  1000
> 201c176
> < (bipartition with sequences in input order : number of times seen (and
> ratio))
> ---
> > (bipartition with sequences in input order : number of times seen)
> 
> Ratios seem to have been added to the test. Scanning through all the
> other test binaries and their outputs, my values seem to match up to
> what is expected regardless of the issues above.
> 
> So next I decided to see when the tests directory was added. This
> happened to be version 5.2. Quickly testing a couple of test binaries,
> they run successfully. It seems like to me that the expected test
> results file introduced in 5.2 were just never updated to 5.3~rc16.

This matches perfectly my suspicion after a way less deep inspection.
Thanks for confirming.

> I am
> not sure why your build log is different in terms of value. Maybe
> upstream modified the current release candidate and version (some do
> this). I will keep this updated with anything else that I spot or comes
> to mind.

Would you mind pinging upstream about this?  I have no idea about their
release schedule.  Version 5.3~rc16 is out for quite some while but may
be its the right moment to approach them.
 
> Kind regards,

Thanks again for your very valuable contribution

 Andreas.
 
> On Mon, 8 Jul 2019 21:26:02 +0200 Andreas Tille  wrote:
> > Hi,
> > 
> > after switching tree-puzzle debhelper level to 9  I was cheating around
> > the build time test suite via
> > 
> > override_dh_auto_test:
> > # unfortunately most tests are failing for the moment
> > # the issue is documented in
> > #   debian/patches/patch_test_results.patch
> > # and needs to be discussed with upstream
> > dh_auto_test || true
> > 
> > The rationale was that just by switching the debhelper level the build
> > time test suite was run at all.  Most probably it was failing all the
> > time before and simply nobody realised this.  To sort this out we need
> > to talk to upstream.  The issue is documented in bug #806214 (bug in
> > CC).
> > 
> > I now bumped the upstream source in Git to the latest upstream release
> > candidate.  Since this had not changed quite some time I assume upstream
> > is not very rapidly pushing a final release.  However, this might be the
> > right point in time to sort things out.
> > 
> > If you check the build log of 5.2-11 at
> > 
> >
> > https://buildd.debian.org/status/fetch.php?pkg=tree-puzzle=all=5.2-11=1539685923=0
> > 
> > you can find
> > 
> > ...
> > dh_auto_test || true
> >  make -j1 check VERBOSE=1
> > make[2]: Entering directory '/<>'
> > Making check in src
> > make[3]: Entering directory '/<>/src'
> > make[3]: Leaving directory '/<>/src'
> > Making check in doc
> > make[3]: Entering directory '/<>/doc'
> > make[4]: Entering directory '/<>/doc'
> > make[4]: Nothing to be done for 'check-am'.
> > make[4]: Leaving directory '/<>/doc'
> > make[3]: Leaving directory '/<>/doc'
> > Making check in data
> > make[3]: 

Bug#939449: ITP: jnati -- Java Native Execution Framework

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist

* Package name    : jnati
  Version : 0.4
  Upstream Author : Sam Adams
* URL : http://jnati.sourceforge.net/
* License : GPL-3
  Programming Lang: Java
  Description : Java Native Execution Framework
 A toolkit for working with native, non-Java, programs and libraries from
 within Java.

This package is a dependency of jni-inchi, required by opsin and cdk.

Remark: This package is to be maintained with Debian Java Maintainers at
   https://salsa.debian.org/java-team/jnati

Bug#931729: apt-mirror: SSUse of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror line 829

[Сергей Фёдоров]

To solve a problem I wrote about earlier,
in the text of the program "apt-mirror 0.5.4-1" commented or added new lines.

I marked my changes with comments:
# *** my comment
# *** my insert

#---
sub need_update
{
my $filename   = shift;
my $size_on_server = shift;

my ( undef, undef, undef, undef, undef, undef, undef, $size ) = 
_stat($filename);

return 1 unless ($size);
return 0 if $size_on_server == $size;

unlink( $filename ) || die("apt-mirror: unlink error:  $! for file: 
$filename");  # *** my insert
return 1;
}

#---
sub process_index
{
 ...
 if ( exists $lines{"Filename:"} )
 {   # Packages index
 $skipclean{ remove_double_slashes( $path . "/" . $lines{"Filename:"} ) 
} = 1;
 print FILES_ALL remove_double_slashes( $path . "/" . 
$lines{"Filename:"} ) . "\n";
 print FILES_MD5 $lines{"MD5sum:"} . "  " . remove_double_slashes( 
$path . "/" . $lines{"Filename:"} ) . "\n" if defined $lines{"MD5sum:"};
 print FILES_SHA1 $lines{"SHA1:"} . "  " . remove_double_slashes( $path 
. "/" . $lines{"Filename:"} ) . "\n" if defined $lines{"SHA1:"};
 print FILES_SHA256 $lines{"SHA256:"} . "  " . remove_double_slashes( 
$path . "/" . $lines{"Filename:"} ) . "\n" if defined $lines{"SHA256:"};
 if ( need_update( $mirror . "/" . $lines{"Filename:"}, $lines{"Size:"} 
) )
 {
 print FILES_NEW remove_double_slashes( $uri . "/" . 
$lines{"Filename:"} ) . "\n";
 add_url_to_download( $uri . "/" . $lines{"Filename:"}, 
$lines{"Size:"} );
 }
 }
 #else  # *** my comment
 elsif ( exists $lines{"Files:"} )  # *** my insert
 {# Sources index
  foreach ( split( /\n/, $lines{"Files:"} ) )
  {
 ...
}
##
## Main download

chdir get_variable("mirror_path") or die("apt-mirror: can't chdir to mirror");

my $need_bytes = 0;
foreach ( values %urls_to_download )
{
$need_bytes += $_;
}
if ($need_bytes > 0) {   # *** my insert

  my $size_output = format_bytes($need_bytes);

  print "$size_output will be downloaded into archive.\n";

  download_urls( "archive", sort keys %urls_to_download );
}   # *** my insert
##

String with "unlink" in "sub need_update" is very important, since "wget" does
not a re-change a package if it is not fully downloaded on previous runs
of "apt-mirror". For example, if in the previous run "apt-mirror" pressed 
"Ctrl+C".

After this change everything works fine and the message:

Processing indexes: [SUse of uninitialized value $lines{"Files:"} in split 
at /usr/bin/apt-mirror line 829,  line 1.
Use of uninitialized value $lines{"Files:"} in split at /usr/bin/apt-mirror 
line 829,  line 2.
P]

no longer appears. And messages for re-download the not completely
downloaded packages also do not occur.

Bug#939448: zope.fixers: Python2 removal in sid/bullseye

[Matthias Klose]

Package: src:zope.fixers
Version: 1.0-1
Severity: normal
Tags: sid bullseye
User: debian-pyt...@lists.debian.org
Usertags: py2removal

Python2 becomes end-of-live upstream, and Debian aims to remove
Python2 from the distribution, as discussed in
https://lists.debian.org/debian-python/2019/07/msg00080.html

Your package either build-depends, depends on Python2, or uses Python2
in the autopkg tests.  Please stop using Python2, and fix this issue
by one of the following actions.

- Convert your Package to Python3. This is the preferred option.  In
  case you are providing a Python module foo, please consider dropping
  the python-foo package, and only build a python3-foo package.  Please
  don't drop Python2 modules, which still have reverse dependencies,
  just document them.

  This is the preferred option.

- If the package is dead upstream, cannot be converted or maintained
  in Debian, it should be removed from the distribution.  If the
  package still has reverse dependencies, raise the severity to
  "serious" and document the reverse dependencies with the BTS affects
  command.  If the package has no reverse dependencies, confirm that
  the package can be removed, reassign this issue to ftp.debian.org,
  make sure that the bug priority is set to normal and retitle the
  issue to "RM: PKG -- removal triggered by the Python2 removal".

- If the package has still many users (popcon >= 300), or is needed to
  build another package which cannot be removed, document that by
  adding the "py2keep" user tag (not replacing the py2remove tag),
  using the debian-pyt...@lists.debian.org user.  Also any
  dependencies on an unversioned python package (python, python-dev)
  must not be used, same with the python shebang.  These have to be
  replaced by python2/python2.7 dependencies and shebang.

  This is the least preferred option.

If the conversion or removal needs action on another package first,
please document the blocking by using the BTS affects command, like

  affects  + src:zope.fixers

If there is no py2removal bug for that reverse-dependency, please file
a bug on this package (similar to this bug report).

If there are questions, please refer to the wiki page for the removal:
https://wiki.debian.org/Python/2Removal, or ask for help on IRC
#debian-python, or the debian-pyt...@lists.debian.org mailing list.

Bug#938988: gcc-defaults: enable mipsel and mips64el cross targets for arm64

[Matthias Klose]

Control: reassign -1 src:gcc-defaults-mipsen

On 30.08.19 21:55, Vagrant Cascadian wrote:

Source: gcc-defaults
Version: 181
Control: block -1 by #938979
Severity: wishlist

Please consider enabling the following targets for arm64:

   gcc-mips64el-linux-gnuabi64
   gcc-mipsel-linux-gnu

This is at least useful for cross-building some arch:all packages on
arm64 (e.g. u-boot-qemu).


won't fix, see
https://lists.debian.org/debian-gcc/2019/09/msg5.html

Bug#939447: nvidia-legacy-check: Supported graphics card (Quadro K1100M) is flagged as unsupported

[Carlo Segre]

Package: nvidia-legacy-check
Version: 430.40-2
Severity: normal

The NVidia Quadro K1100M is supported by the current non-free drivers (my card
is working just fine with the drivers on sid) but is not included in the list
of supported GPS.  This means that when nvidia-legacy-check is installed, the
warning pops up and predicts dire things if I do not switch to the legacy
package which as far as I know does not support this card.

This problem can be corrected by adding the code "10DE0FF6" to the list of
supported ID numbers in the nvidia-legacy-check.preinst file.


-- Package-specific info:
uname -a:
Linux hydride 5.2.0-2-amd64 #1 SMP Debian 5.2.9-2 (2019-08-21) x86_64 GNU/Linux

/proc/version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  430.40  Sun Jul 21 04:53:48 CDT 
2019
GCC version:  gcc version 8.3.0 (Debian 8.3.0-21)

lspci 'display controller [030?]':
00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core 
Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA 
controller])
Subsystem: Lenovo 4th Gen Core Processor Integrated Graphics Controller 
[17aa:221e]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK107GLM [Quadro 
K1100M] [10de:0ff6] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Lenovo GK107GLM [Quadro K1100M] [17aa:221a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia


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

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

Versions of packages nvidia-legacy-check depends on:
ii  debconf [debconf-2.0] 1.5.73
ii  nvidia-installer-cleanup  20151021+9
ii  pciutils  1:3.6.2-2

nvidia-legacy-check recommends no packages.

nvidia-legacy-check suggests no packages.

Versions of packages nvidia-driver-libs:i386 depends on:
ii  libgl1-nvidia-glvnd-glx  430.40-2
ii  nvidia-egl-icd   430.40-2

Versions of packages nvidia-driver-libs:i386 recommends:
pn  libgles-nvidia1
ii  libgles-nvidia2430.40-2
ii  libglx-nvidia0 430.40-2
ii  libopengl0 1.1.0-1+b1
ii  nvidia-vulkan-icd  430.40-2

Versions of packages nvidia-alternative depends on:
ii  dpkg1.19.7
ii  glx-alternative-nvidia  1.0.0

Versions of packages nvidia-kernel-dkms depends on:
ii  dkms   2.7.1-2
ii  nvidia-installer-cleanup   20151021+9
ii  nvidia-kernel-support [nvidia-kernel-support--v1]  430.40-2

Versions of packages nvidia-kernel-dkms recommends:
pn  nvidia-driver | libcuda1  

Versions of packages glx-alternative-nvidia depends on:
ii  dpkg  1.19.7
ii  glx-alternative-mesa  1.0.0
ii  glx-diversions1.0.0
ii  update-glx1.0.0

Versions of packages glx-alternative-nvidia suggests:
pn  nvidia-driver  

Versions of packages xserver-xorg-video-intel depends on:
ii  libc6  2.28-10
ii  libdrm-intel1  2.4.99-1
ii  libdrm22.4.99-1
ii  libpciaccess0  0.14-1
ii  libpixman-1-0  0.36.0-1
ii  libudev1   242-7
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb-dri2-0  1.13.1-2
ii  libxcb-dri3-0  1.13.1-2
ii  libxcb-sync1   1.13.1-2
ii  libxcb-util0   0.3.8-3+b2
ii  libxcb11.13.1-2
ii  libxcursor11:1.2.0-2
ii  libxdamage11:1.1.5-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxinerama1   2:1.1.4-2
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxshmfence1 

Bug#938891: zodb: Python2 removal in sid/bullseye

[Matthias Klose]

reassign 938891 ftp.debian.org
retitle 938891 RM: zodb -- Python2 removal in sid/bullseye
thanks

please remove this package with all it's r-dependencies

Reverse-Depends
===
* pyscrabble-server (for python-zodb)
* python-zope.annotation(for python-zodb)
* python-zope.catalog   (for python-zodb)
* python-zope.container (for python-zodb)
* python-zope.error (for python-zodb)
* python-zope.index (for python-zodb)
* python-zope.intid (for python-zodb)
* python-zope.keyreference  (for python-zodb)
* python-zope.minmax(for python-zodb)
* python-zope.pluggableauth (for python-zodb)
* python-zope.preference(for python-zodb)
* python-zope.principalannotation  (for python-zodb)
* python-zope.securitypolicy(for python-zodb)
* python-zope.session   (for python-zodb)

Bug#935910: apt: Should be less tolerant of dpkg errors when forcing removal

[Guillem Jover]

Control: reassign -1 apt

Hi!

On Wed, 2019-08-28 at 09:30:45 +0100, Mark Hindley wrote:
> On Tue, Aug 27, 2019 at 08:26:30PM +0200, Julian Andres Klode wrote:
> > > I suggest that --abort-after=1 should be apt's default when forcing 
> > > package
> > > removal.

This was a false lead and the wrong conclusion from an initially
correctly diagnosed problem. :) Reducing the abort-after default
would be an incorrect workaround.

> > APT is the wrong place for that. We're trying to move to a future where
> > we only tell dpkg all the actions to do and then run a single dpkg, so
> > adding hacks like that feels counter-intuitive.
> > 
> > If we agree that this is a good thing to do, dpkg should do it.
> 
> OK, then I suppose from dpkg's point of view it should not go on to remove a
> package's dependencies (in this case libsystemd0) if the prerm fails. Or the
> default for --abort-after (currently 50) is wrong; perhaps it should be 1 when
> dpkg is being invoked by APT?

And dpkg does not remove packages when one of its dependencies is
still present and has failed a maintainer script. The problem here is
that apt is telling dpkg to ignore dependencies via --force-depends.

Thanks,
Guillem

Bug#926981: golang-1.12-go: Needs /etc/alternatives/go to be useful

[Tianon Gravi]

On Wed, 4 Sep 2019 at 19:51, Michael Hudson-Doyle
 wrote:
> On Thu, 5 Sep 2019 at 12:39, Nye Liu  wrote:
>> that is ABSOLUTELY one of the roles of update-alternatives, particularly
>> for compiler variants, e.g. gcc, java, etc.
>
>  gcc isn't managed by alternatives though! In general, alternatives are not a 
> great fit for toolchains, because they mess up the ability for version 
> constraints in build-depends to be useful and mean the package versions 
> reported in build logs / .buildinfo files can't be relied on. I'm not going 
> to budge on this one, sorry.
>
> Cheers,
> mwh

See also 
https://alioth-lists.debian.net/pipermail/pkg-golang-devel/Week-of-Mon-20160208/000248.html
for the discussion that led to the removal of the generic alternatives
in the first place.

♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4

Bug#939446: buster-pu: package emacs/1:26.1+1-3.2

[Rob Browning]

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

  emacs (1:26.1+1-3.2+deb10u1) buster; urgency=medium

* Update the EPLA packaging key (previous key expires 2019-09-23) via
  the upstream commit f16785d361097df9fddfcc0b60ae6f0d92e7e911.  Add the
  old and new keyrings to debian/ and debian/source/include-binaries
  since debian/patches/ can't handle git binary diffs.  Thanks to Stefan
  Monnier for reporting the problem and providing the patch.

diff -Nru emacs-26.1+1/debian/.gitignore emacs-26.1+1/debian/.gitignore
--- emacs-26.1+1/debian/.gitignore	2019-02-03 08:42:30.0 -0600
+++ emacs-26.1+1/debian/.gitignore	1969-12-31 18:00:00.0 -0600
@@ -1,72 +0,0 @@
-*~
-.\#*
-/*-stamp
-/build-lucid
-/build-nox
-/build-x
-/emacs
-/emacs.debhelper.log
-/emacs.substvars
-/emacs-gtk
-/emacs-bin-common
-/emacs-bin-common.README.Debian
-/emacs-bin-common.debhelper.log
-/emacs-bin-common.lintian-overrides
-/emacs-bin-common.postinst
-/emacs-bin-common.postrm
-/emacs-bin-common.prerm
-/emacs-bin-common.substvars
-/emacs-common
-/emacs-common.README.Debian
-/emacs-common.debhelper.log
-/emacs-common.docs
-/emacs-common.links
-/emacs-common.lintian-overrides
-/emacs-common.postinst
-/emacs-common.prerm
-/emacs-common.substvars
-/emacs-el
-/emacs-el.debhelper.log
-/emacs-el.prerm
-/emacs-el.substvars
-/emacs-lucid
-/emacs-lucid.README.Debian
-/emacs-lucid.debhelper.log
-/emacs-lucid.desktop
-/emacs-lucid.lintian-overrides
-/emacs-lucid.menu
-/emacs-lucid.postinst
-/emacs-lucid.postinst.debhelper
-/emacs-lucid.postrm.debhelper
-/emacs-lucid.prerm
-/emacs-lucid.substvars
-/emacs-nox
-/emacs-nox.README.Debian
-/emacs-nox.debhelper.log
-/emacs-nox.desktop
-/emacs-nox.links
-/emacs-nox.lintian-overrides
-/emacs-nox.menu
-/emacs-nox.postinst
-/emacs-nox.postinst.debhelper
-/emacs-nox.postrm
-/emacs-nox.postrm.debhelper
-/emacs-nox.prerm
-/emacs-nox.substvars
-/emacs-gtk.README.Debian
-/emacs-gtk.debhelper.log
-/emacs-gtk.desktop
-/emacs-gtk.links
-/emacs-gtk.lintian-overrides
-/emacs-gtk.menu
-/emacs-gtk.postinst
-/emacs-gtk.postinst.debhelper
-/emacs-gtk.postrm
-/emacs-gtk.postrm.debhelper
-/emacs-gtk.prerm
-/emacs-gtk.substvars
-/emacs-common.README.00
-/emacs-common.README.01
-/files
-/tmp-alt-list
-\#*\#
diff -Nru emacs-26.1+1/debian/changelog emacs-26.1+1/debian/changelog
--- emacs-26.1+1/debian/changelog	2019-02-03 08:42:30.0 -0600
+++ emacs-26.1+1/debian/changelog	2019-09-04 21:35:24.0 -0500
@@ -1,3 +1,13 @@
+emacs (1:26.1+1-3.2+deb10u1) buster; urgency=medium
+
+  * Update the EPLA packaging key (previous key expires 2019-09-23) via
+the upstream commit f16785d361097df9fddfcc0b60ae6f0d92e7e911.  Add the
+old and new keyrings to debian/ and debian/source/include-binaries
+since debian/patches/ can't handle git binary diffs.  Thanks to Stefan
+Monnier for reporting the problem and providing the patch.
+
+ -- Rob Browning   Wed, 04 Sep 2019 21:35:24 -0500
+
 emacs (1:26.1+1-3.2) unstable; urgency=medium
 
   * Non-maintainer upload.
Binary files /tmp/SPAXT75_oS/emacs-26.1+1/debian/etc-package-keyring-new.gpg and /tmp/SOba52Hexv/emacs-26.1+1/debian/etc-package-keyring-new.gpg differ
Binary files /tmp/SPAXT75_oS/emacs-26.1+1/debian/etc-package-keyring-old.gpg and /tmp/SOba52Hexv/emacs-26.1+1/debian/etc-package-keyring-old.gpg differ
diff -Nru emacs-26.1+1/debian/rules emacs-26.1+1/debian/rules
--- emacs-26.1+1/debian/rules	2019-02-03 08:42:30.0 -0600
+++ emacs-26.1+1/debian/rules	2019-09-04 21:27:51.0 -0500
@@ -314,7 +314,15 @@
 override_dh_auto_configure:
 
 debian/stamp-configured: $(autogen_build_files)
-# If the deps for this target change, start over
+# If the deps for this target change, start over.
+# When the "new" keyring is obsolete, update
+# debian/source/include-binaries.
+	if test "$$(sha1sum etc/package-keyring.gpg | cut -f 1 -d ' ')" \
+	  != 5eda21f010a2d246359efc6450830ac3d500760e; then \
+	  echo 'Unexpected keyring hash - is it obsolete?'; \
+	  false; \
+	fi
+	cp -a debian/etc-package-keyring-new.gpg etc/package-keyring.gpg
 	rm -rf debian/build-src debian/build-gtk debian/build-lucid debian/build-nox
 	mkdir debian/build-src
 	cp -a $$(ls -A | egrep -v '^(\.git|\.pc|debian)$$') debian/build-src
@@ -559,6 +567,8 @@
 
 override_dh_clean: $(persistent_autogen_files)
 	dh_clean
+	cp -a debian/etc-package-keyring-old.gpg \
+	  etc/package-keyring.gpg
 	rm -rf \
 	  debian/stamp-* \
 	  debian/build-lucid \
diff -Nru emacs-26.1+1/debian/source/include-binaries emacs-26.1+1/debian/source/include-binaries
--- emacs-26.1+1/debian/source/include-binaries	1969-12-31 18:00:00.0 -0600
+++ emacs-26.1+1/debian/source/include-binaries	2019-09-04 21:26:12.0 -0500
@@ -0,0 +1,2 @@
+debian/etc-package-keyring-new.gpg
+debian/etc-package-keyring-old.gpg

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 

Bug#935485: Looking for help with a recently removed package, kcollectd

[Antonio Russo]

>> I've changed the maintainer to be Qt/KDE, and changed my role to uploader
>> (and I've added you there as well, is that appropriate?).
> 
> No please remove myself from uploaders, as I'm only the sponsor. I do not 
> intend at the moment to care about new versions of kcollectd. You care about 
> the package and do the uploads!
> 
> As we will manage this as part of the Qt/KDE team we also use a location that 
> reflects this:
> https://salsa.debian.org/qt-kde-team/extras/kcollectd

I've removed you as an uploader, and updated Vcs-Git and Vcs-Browser in control.

> you should have enough permissions to push to this location. Please update 
> the 
> debian/control according to the new locations.

I am getting

remote: GitLab: You are not allowed to push code to protected branches on this 
project.

while

# ssh g...@salsa.debian.org
Welcome to GitLab, @aerusso-guest!

I've updated aerusso-guest/kcollectd, however (and mentors).


> Are the version 0.10.2-1, 0.10.2-2 and 0.10.2-3 released somewhere (aka 
> Ubuntu 
> or anywhere else)? If not please merge the changelog entries, as it is unusal 
> to keep non released versions in changelog. 
> Normally you keep the last changelog entry open and just add new stuff until 
> we 
> release to Debian/Ubuntu. [1]

I've squashed the changelog entries into 0.10.2-1 as well.

Let me know anything else I should do.

Thanks,
Antonio

Bug#926981: golang-1.12-go: Needs /etc/alternatives/go to be useful

[Michael Hudson-Doyle]

On Thu, 5 Sep 2019 at 12:39, Nye Liu  wrote:

> On 8/29/2019 8:08 AM, Shengjing Zhu wrote:
>
> >> That definitely does not provide update-alternatives functionality.
> >>
> > We don't provide update-alternatives for difference versions. This is
> > not the goal of update-alternatives.
> that is ABSOLUTELY one of the roles of update-alternatives, particularly
> for compiler variants, e.g. gcc, java, etc.
>

 gcc isn't managed by alternatives though! In general, alternatives are not
a great fit for toolchains, because they mess up the ability for version
constraints in build-depends to be useful and mean the package versions
reported in build logs / .buildinfo files can't be relied on. I'm not going
to budge on this one, sorry.

Cheers,
mwh

Bug#939445: libc6: Localized sorting has unexpected change in zh_CN locale

[WHR]

Package: libc6
Version: 2.28-10
Severity: normal
Tags: l10n

Hi, I found the item sorting has surprising change in Debian Buster when using
zh_CN locale; the Chinese characters are now sorted before English letters. I
usually using LANG=zh_CN.UTF-8 to display localized messages in my system;
however this change affected convenience for me of finding items.
The default sorting mode of ls(1) has been affected by this, I don't exactly
known how ls(1) sorting the files, but I guess the source of the issue is from
the GLIBC, because bash(1) is also affected when trying something like
'echo *'.

For example:

root@debian:~/test# export | grep -F -e LANG -e LC_
declare -x LANG="C.UTF-8"
root@debian:~/test# ls -l
total 40
drwxr-xr-x 2 root root 4096 Sep  4 22:24 111
drwxr-xr-x 2 root root 4096 Sep  4 22:24 222
drwxr-xr-x 2 root root 4096 Sep  4 22:24 aaa
drwxr-xr-x 2 root root 4096 Sep  4 22:24 bbb
drwxr-xr-x 2 root root 4096 Sep  4 22:24 ccc
drwxr-xr-x 2 root root 4096 Sep  4 22:24 test
drwxr-xr-x 2 root root 4096 Sep  4 22:24 z.测试
drwxr-xr-x 2 root root 4096 Sep  4 22:24 zzz
drwxr-xr-x 2 root root 4096 Sep  4 22:24 一
drwxr-xr-x 2 root root 4096 Sep  4 22:24 测试
root@debian:~/test# LANG=en_US.UTF-8 ls -l
total 40
drwxr-xr-x 2 root root 4096 Sep  4 22:24 111
drwxr-xr-x 2 root root 4096 Sep  4 22:24 222
drwxr-xr-x 2 root root 4096 Sep  4 22:24 aaa
drwxr-xr-x 2 root root 4096 Sep  4 22:24 bbb
drwxr-xr-x 2 root root 4096 Sep  4 22:24 ccc
drwxr-xr-x 2 root root 4096 Sep  4 22:24 test
drwxr-xr-x 2 root root 4096 Sep  4 22:24 zzz
drwxr-xr-x 2 root root 4096 Sep  4 22:24 z.测试
drwxr-xr-x 2 root root 4096 Sep  4 22:24 一
drwxr-xr-x 2 root root 4096 Sep  4 22:24 测试
root@debian:~/test# LANG=zh_CN.UTF-8 ls -l
总用量 40
drwxr-xr-x 2 root root 4096 9月   4 22:24 111
drwxr-xr-x 2 root root 4096 9月   4 22:24 222
drwxr-xr-x 2 root root 4096 9月   4 22:24 测试
drwxr-xr-x 2 root root 4096 9月   4 22:24 一
drwxr-xr-x 2 root root 4096 9月   4 22:24 aaa
drwxr-xr-x 2 root root 4096 9月   4 22:24 bbb
drwxr-xr-x 2 root root 4096 9月   4 22:24 ccc
drwxr-xr-x 2 root root 4096 9月   4 22:24 test
drwxr-xr-x 2 root root 4096 9月   4 22:24 z.测试
drwxr-xr-x 2 root root 4096 9月   4 22:24 zzz
root@debian:~/test# LANG=zh_TW.UTF-8 ls -l
總計 40
drwxr-xr-x 2 root root 4096  9月  4 22:24 111
drwxr-xr-x 2 root root 4096  9月  4 22:24 222
drwxr-xr-x 2 root root 4096  9月  4 22:24 aaa
drwxr-xr-x 2 root root 4096  9月  4 22:24 bbb
drwxr-xr-x 2 root root 4096  9月  4 22:24 ccc
drwxr-xr-x 2 root root 4096  9月  4 22:24 test
drwxr-xr-x 2 root root 4096  9月  4 22:24 zzz
drwxr-xr-x 2 root root 4096  9月  4 22:24 z.测试
drwxr-xr-x 2 root root 4096  9月  4 22:24 一
drwxr-xr-x 2 root root 4096  9月  4 22:24 测试
root@debian:~/test# bash -c 'echo *'
111 222 aaa bbb ccc test z.测试 zzz 一 测试
root@debian:~/test# LANG=en_US.UTF-8 bash -c 'echo *'
111 222 aaa bbb ccc test zzz z.测试 一 测试
root@debian:~/test# LANG=zh_CN.UTF-8 bash -c 'echo *'
111 222 测试 一 aaa bbb ccc test z.测试 zzz
root@debian:~/test# LANG=zh_TW.UTF-8 bash -c 'echo *'
111 222 aaa bbb ccc test zzz z.测试 一 测试

It seems only zh_CN has this problem, zh_TW was not.
I has tried to workaround this by setting 'LC_*' variables, but none has worked.
I'm really disliked this change, but I still don't want to give up on the zh_CN
locale that provided by C library.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/16 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: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libgcc1  1:8.3.0-6

Versions of packages libc6 recommends:
ii  libidn2-0  2.0.5-1

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.71
pn  glibc-doc  
ii  libc-l10n  2.28-10
ii  locales2.28-10

-- debconf information:
  glibc/kernel-not-supported:
  glibc/restart-failed:
  glibc/restart-services:
  glibc/upgrade: true
  glibc/kernel-too-old:
* libraries/restart-without-asking: true
  glibc/disable-screensaver:

Bug#939444: spf-milter-python: spfmilter cannot access contents of sendmail /etc/mail

[Winston Sorfleet]

Package: spf-milter-python
Version: 0.9-2
Severity: important
Tags: newcomer

Dear Maintainer,

spf-milter-python can be configured to look up /etc/mail/access.db; this
is the default situation.  However, with sendmail, the /etc/mail
contents are group smmsp, e.g.:

-rw--- 1 root  smmsp  8835 Aug  7 10:58 access
-rw-r- 1 smmta smmsp 12288 Aug  7 10:58 access.db

Sendmail logs (for host flamen) are as follows:
Sep  1 00:09:47 flamen spfmilter: /etc/mail/access.db: Cannot open for reading

Therefore the spf-milter-python user should be added to group smmsp in
/etc/group


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

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

Versions of packages spf-milter-python depends on:
ii  adduser3.118
ii  lsb-base   10.2019051400
ii  python 2.7.16-1
ii  python-milter  1.0.3-3
ii  python-spf 2.0.12t-3

spf-milter-python recommends no packages.

Versions of packages spf-milter-python suggests:
ii  sendmail  8.15.2-13

-- no debconf information

Bug#939443: pnopaste: please add the word "server" to the description

[Paul Wise]

Source: pnopaste
Severity: wishlist

I was looking for pastebin server packages and couldn't find any in
Debian. The reason was that none of the ones in Debian include the word
"server" in their description, please add this word to pnopaste's.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#939442: dovecot-core: mail_filter and mail_filter_out broken after upgrade to buster

[Michael Fincham]

Package: dovecot-core
Version: 2.3.4.1-5+deb10u1
Severity: important

Hi Dovecot maintainers,

After upgrading from the latest stretch version of dovecot-core
(2.2.27-3+deb9u5) to buster (2.3.4.1-5+deb10u1) the "mail filter"
interface seems to have broken. This problem is also present in the sid
version (2.3.7.2-1).

Mail filter is used to run the content of messages being stored or
retrieved through an arbitrary process. The interface used for the
external process is described here:
https://wiki.dovecot.org/Plugins/MailFilter

It is expected that the process will be called with the arguments
specific in the configuration then supplied a message body on stdin,
however since upgrading it seems that the arguments are not being
correctly passed, instead being all jammed in to $1 and separated by
tabs, rather than expanded in to argv. Even stranger the first few
lines of the body of the message appear in argv rather than in stdin...

These reproduction steps were carried out on a fresh install of Debian
Buster with the "dovecot-core" package installed initially from stretch
then upgraded to the buster version, however this behaviour has also
been observed on stretch systems after upgrading to buster.

To reproduce, drop this minimalised config in
to /etc/dovecot/conf.d/repro.conf:

# Minimal maildir setup for LDA
first_valid_uid = 0
mail_location = maildir:~/Maildir
userdb {
  driver = static
  args = allow_all_users=yes uid=mail gid=mail home=/tmp/%u
}

# Mail filter configuration
mail_plugins = $mail_plugins mail_filter

plugin {
  mail_filter = mail-filter read %u
  mail_filter_out = mail-filter write %u
}

service mail-filter {
 executable = script /usr/local/bin/mail-filter.sh
 user = dovecot
 unix_listener mail-filter {
   mode = 0666
 }
}

And create the example script in /usr/local/bin/mail-filter.sh with
executable permissions:

#!/bin/bash

echo "arguments were: $@" 1>&2
tempfile=$(mktemp)
cat > "${tempfile}"
cat "${tempfile}"
rm "${tempfile}"

This script simply logs the arguments it recieves, writes stdin to a
file then retrieves it again from the file.

Here's a sample session of me using dovecot-lda to pass a message
through this script, then retrieve it again with doveadm:

root@scratch-b6fd8bdd:~# /usr/lib/dovecot/dovecot-lda -d 
fincham@scratch-b6fd8bdd -f 'Test ' < /root/test.eml 
root@scratch-b6fd8bdd:~# doveadm fetch -u 'fincham@scratch-b6fd8bdd' hdr 
subject Test
hdr:
To: Test 
From: Test 
Subject: This is the test e-mail

root@scratch-b6fd8bdd:~# tail /var/log/syslog | grep mail-filter
Sep  5 00:07:48 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
write fincham@scratch-b6fd8bdd
Sep  5 00:07:50 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
read fincham@scratch-b6fd8bdd

However after upgrading dovecot to the buster version this process no
longer works, and the logged argv of the example script is very strange:

root@scratch-b6fd8bdd:~# apt dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following NEW packages will be installed:
  liblua5.3-0 libsodium23 ssl-cert
The following packages will be upgraded:
  dovecot-core
[...]

root@scratch-b6fd8bdd:~# /usr/lib/dovecot/dovecot-lda -d 
fincham@scratch-b6fd8bdd -f scratch-b6fd8bdd < /root/test.eml 
Aborted
root@scratch-b6fd8bdd:~# doveadm fetch -u 'fincham@scratch-b6fd8bdd' hdr 
subject Test
hdr:
Hello!
doveadm(fincham@scratch-b6fd8bdd): Error: Mailbox INBOX: UID=1: read() failed: 
Cached message size larger than expected (115 > 7, box=INBOX, UID=1) (read 
reason=mail stream)
doveadm(fincham@scratch-b6fd8bdd): Error: Corrupted record in index cache file 
/tmp/fincham@scratch-b6fd8bdd/Maildir/dovecot.index.cache: UID 1: Broken 
physical size in mailbox INBOX: read() failed: Cached message size larger than 
expected (115 > 7, box=INBOX, UID=1)
doveadm(fincham@scratch-b6fd8bdd): Error: read() failed: Cached message size 
larger than expected (115 > 7, box=INBOX, UID=1)
doveadm(fincham@scratch-b6fd8bdd): Error: fetch(hdr) failed for box=INBOX 
uid=1: read() failed: Cached message size larger than expected (115 > 7, 
box=INBOX, UID=1)
root@scratch-b6fd8bdd:~# tail /var/log/syslog | grep mail-filter
Sep  5 00:07:48 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
write fincham@scratch-b6fd8bdd
Sep  5 00:07:50 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
read fincham@scratch-b6fd8bdd
Sep  5 00:12:11 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
write#011fincham@scratch-b6fd8bdd#011 To: Test  From: 
Test  Subject: This is the test e-mail
Sep  5 00:12:14 scratch-b6fd8bdd dovecot: mail-filter: Error: arguments were: 
read#011fincham@scratch-b6fd8bdd#011 To: Test  From: 
Test  Subject: This is the test e-mail

-- Package-specific info:

dovecot configuration
-
# 2.3.4.1 (f79e8e7e4): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.4 ()
# OS: Linux 

Bug#939441: firmware-iwlwifi: Microcode SW error detected / Error sending REPLY_ADD_STA: time out after 2000ms

[Andrew Bettison]

Package: firmware-iwlwifi
Version: 20190717-2
Severity: normal
Tags: upstream

During heavy Wi-Fi use (rsync), every few seconds (see first kern.log
extract):

Microcode SW error detected.  Restarting 0x200.

And once:

Error sending REPLY_ADD_STA: time out after 2000ms.

followed by an event log dump (see second kern.log
extract).  At that point the Wi-Fi froze, and could only
be restored by restarting NetworkManager.



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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.135
Sep  5 08:23:41 sago kernel: [0.00] microcode: microcode updated early 
to revision 0xa0b, date = 2010-09-28
Sep  5 08:23:41 sago kernel: [0.00] Linux version 5.2.0-2-amd64 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-21)) #1 SMP 
Debian 5.2.9-2 (2019-08-21)
Sep  5 08:23:41 sago kernel: [0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 
root=UUID=b5cca383-fde9-4f0b-9735-36077a0c8ede ro quiet
Sep  5 08:23:41 sago kernel: [0.00] x86/fpu: Supporting XSAVE feature 
0x001: 'x87 floating point registers'
Sep  5 08:23:41 sago kernel: [0.00] x86/fpu: Supporting XSAVE feature 
0x002: 'SSE registers'
Sep  5 08:23:41 sago kernel: [0.00] x86/fpu: Enabled xstate features 
0x3, context size is 576 bytes, using 'standard' format.
Sep  5 08:23:41 sago kernel: [0.00] BIOS-provided physical RAM map:
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0x-0x0009b7ff] usable
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0x0009b800-0x0009] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0x0010-0xdf451bff] usable
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xdf451c00-0xdfff] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xf800-0xfbff] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfec0-0xfec0] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfed18000-0xfed1bfff] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfed2-0xfed8] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfeda-0xfeda5fff] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xfee0-0xfee0] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0xffe0-0x] reserved
Sep  5 08:23:41 sago kernel: [0.00] BIOS-e820: [mem 
0x0001-0x00041fff] usable
Sep  5 08:23:41 sago kernel: [0.00] NX (Execute Disable) protection: 
active
Sep  5 08:23:41 sago kernel: [0.00] SMBIOS 2.4 present.
Sep  5 08:23:41 sago kernel: [0.00] DMI: Dell Inc. Precision M6400  
   /076V94, BIOS A09 11/05/2009
Sep  5 08:23:41 sago kernel: [0.00] tsc: Fast TSC calibration failed
Sep  5 08:23:41 sago kernel: [0.00] e820: update [mem 
0x-0x0fff] usable ==> reserved
Sep  5 08:23:41 sago kernel: [0.00] e820: remove [mem 
0x000a-0x000f] usable
Sep  5 08:23:41 sago kernel: [0.00] last_pfn = 0x42 max_arch_pfn = 
0x4
Sep  5 08:23:41 sago kernel: [0.00] MTRR default type: uncachable
Sep  5 08:23:41 sago kernel: [0.00] MTRR fixed ranges enabled:
Sep  5 08:23:41 sago kernel: [0.00]   0-9 write-back
Sep  5 08:23:41 sago kernel: [0.00]   A-B uncachable
Sep  5 08:23:41 sago kernel: [0.00]   C-D7FFF write-protect
Sep  5 08:23:41 sago kernel: [0.00]   D8000-E uncachable
Sep  5 08:23:41 sago kernel: [0.00]   F-F write-protect
Sep  5 08:23:41 sago kernel: [0.00] MTRR variable ranges enabled:
Sep  5 08:23:41 sago kernel: [0.00]   0 base 0 mask 8 
write-back
Sep  5 08:23:41 sago kernel: [0.00]   1 base 0E000 mask FE000 
uncachable
Sep  5 08:23:41 sago kernel: [0.00]   2 disabled
Sep  5 08:23:41 sago kernel: [0.00]   3 disabled
Sep  5 08:23:41 sago kernel: [0.00]   4 disabled
Sep  5 08:23:41 sago kernel: [0.00]   5 disabled
Sep  5 08:23:41 sago kernel: [0.00]   6 disabled
Sep  5 08:23:41 sago kernel: [ 

Bug#939440: apt: Please improve documentation for apt-get/apt-secure regarding repository codename changes

[Christopher David Howie]

Package: apt
Version: 1.8.2
Severity: minor

When running "apt-get update" against a repository with a change in the 
codename, apt-get outputs the following lines:



E: Repository '___' changed its 'Codename' value from '___' to '___'
N: This must be accepted explicitly before updates for this repository can be 
applied. See apt-secure(8) manpage for details
The apt-secure manpage documents the presence of this feature, but does 
not provide any additional information about how to accept the change:



Since version 1.5 the user must therefore explicitly confirm changes
to signal that the user is sufficiently prepared e.g. for the new
major release of the distribution shipped in the repository (as e.g.
indicated by the codename).
This is a bit frustrating to try to unravel, as the only documentation 
referenced in the apt-get output doesn't actually tell you what to do.


I would suggest referring the user to the --allow-releaseinfo-change 
flag in either the apt-get output or the apt-secure manpage.  Without 
some kind of pointer in this direction, presumably the user would have 
to read the apt-get manpage in its entirety to discover that this flag 
exists.


--
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document: 
http://www.chrishowie.com/email-preferences/


PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is 
addressed.  If you have received this message it was obviously addressed 
to you and therefore you can read it.


Additionally, by sending an email to ANY of my addresses or to ANY 
mailing lists to which I am subscribed, whether intentionally or 
accidentally, you are agreeing that I am "the intended recipient," and 
that I may do whatever I wish with the contents of any message received 
from you, unless a pre-existing agreement prohibits me from so doing.


This overrides any disclaimer or statement of confidentiality that may 
be included on your message.

Bug#806214: Status of build time test suites of tree-puzzle

[Shayan Doust]

Hello Andreas,

Some investigative work. I also compiled a clean copy directly from the
upstream website to prevent any sort of contamination and to rule out
possible upstream fault and then a packaging build attempt (debhelper 11).

> I have some gut feeling that the test files for comparison do not
> really fit the proper result.

This may be the case, but I am having a hard time getting the same
output as
https://buildd.debian.org/status/fetch.php?pkg=tree-puzzle=all=5.2-11=1539685923=0

I have just ran qp-pure-prot.test as an example:

113,114c86,87
< WARNING: Result of chi-square test may not be valid because of
< small maximum likelihood frequencies and short sequence length!
---
> WARNING: Result of chi-square test may not be valid because of small
> maximum likelihood frequencies and short sequence length!

* Diffs like this indicate formatting faults which are easy to rectify,
or remove as a whole.

* The first line of the test output file contains TEST-PUZZLE and the
version number. This version number (5.3.rc16) is not visible in the
upstream expected output file, so diff will of course display this as a
delta.

* There is a higher verbosity of paragraphed description / output in the
test's newly-generated results file compared to what upstream has. Maybe
upstream is running an older / more obselete version of the program?

* From what I can see, the numbers seem to match for the most part, but
upstream has introduced chi2-value column which is not present in the
expected results file.

For instance, running qp-pure-bin.test. Here is a small slice of my output:

194c169
< (bipartition with sequences in input order : number of times seen (and
ratio))
---
> (bipartition with sequences in input order : number of times seen)
196,197c171,172
<  *..** :  1000 (1.000)
<  *...* :  1000 (1.000)
---
>  *..**  :  1000
>  *...*  :  1000
201c176
< (bipartition with sequences in input order : number of times seen (and
ratio))
---
> (bipartition with sequences in input order : number of times seen)

Ratios seem to have been added to the test. Scanning through all the
other test binaries and their outputs, my values seem to match up to
what is expected regardless of the issues above.

So next I decided to see when the tests directory was added. This
happened to be version 5.2. Quickly testing a couple of test binaries,
they run successfully. It seems like to me that the expected test
results file introduced in 5.2 were just never updated to 5.3~rc16. I am
not sure why your build log is different in terms of value. Maybe
upstream modified the current release candidate and version (some do
this). I will keep this updated with anything else that I spot or comes
to mind.

Kind regards,
Shayan Doust

On Mon, 8 Jul 2019 21:26:02 +0200 Andreas Tille  wrote:
> Hi,
> 
> after switching tree-puzzle debhelper level to 9  I was cheating around
> the build time test suite via
> 
> override_dh_auto_test:
>   # unfortunately most tests are failing for the moment
>   # the issue is documented in
>   #   debian/patches/patch_test_results.patch
>   # and needs to be discussed with upstream
>   dh_auto_test || true
> 
> The rationale was that just by switching the debhelper level the build
> time test suite was run at all.  Most probably it was failing all the
> time before and simply nobody realised this.  To sort this out we need
> to talk to upstream.  The issue is documented in bug #806214 (bug in
> CC).
> 
> I now bumped the upstream source in Git to the latest upstream release
> candidate.  Since this had not changed quite some time I assume upstream
> is not very rapidly pushing a final release.  However, this might be the
> right point in time to sort things out.
> 
> If you check the build log of 5.2-11 at
> 
>
> https://buildd.debian.org/status/fetch.php?pkg=tree-puzzle=all=5.2-11=1539685923=0
> 
> you can find
> 
> ...
> dh_auto_test || true
>  make -j1 check VERBOSE=1
> make[2]: Entering directory '/<>'
> Making check in src
> make[3]: Entering directory '/<>/src'
> make[3]: Leaving directory '/<>/src'
> Making check in doc
> make[3]: Entering directory '/<>/doc'
> make[4]: Entering directory '/<>/doc'
> make[4]: Nothing to be done for 'check-am'.
> make[4]: Leaving directory '/<>/doc'
> make[3]: Leaving directory '/<>/doc'
> Making check in data
> make[3]: Entering directory '/<>/data'
> make[3]: Nothing to be done for 'check'.
> make[3]: Leaving directory '/<>/data'
> Making check in tests
> make[3]: Entering directory '/<>/tests'
> make  check-TESTS
> make[4]: Entering directory '/<>/tests'
> make[5]: Entering directory '/<>/tests'
> SKIP: build-puzzle
> FAIL: qp-pure-bin.test
> FAIL: qp-pure-nucl.test
> FAIL: qp-tn-nucl.test
> FAIL: qp-hky-clock-nucl.test
> FAIL: qp-hky-rhet-nucl.test
> FAIL: qp-hky-rhet-clock-nucl.test
> FAIL: qp-pure-prot.test
> FAIL: qp-mtrev-prot.test



signature.asc
Description: OpenPGP digital signature

Bug#939357: cryptsetup-run: invoking "sudo cryptdisks_start" with "decrypt_keyctl" in crypttab fails

[Guilhem Moulin]

Control: reassign -1 sudo 1.8.27-1
Control: affects -1 cryptsetup
Control: merge -1 906752

On Thu, 05 Sep 2019 at 02:03:34 +0200, Guilhem Moulin wrote:
> Perhaps keyctl(1) could provide a wrapper using thread-keyring(7) as
> temporary keyring, like the attached PoC.

Of course I forgot the attachment :-P  That said I'm not sure that
using a temporary keyring and changing ownership is the way to go, it
adds complexity and not having a reachable user-keyring(7) might cause
other problems.

I was about to reassign that to sudo but noticed there is already a bug
open: https://bugs.debian.org/906752

-- 
Guilhem.
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[]) {
if (argc != 4)
exit(EXIT_FAILURE);
key_serial_t key = add_key(argv[1], argv[2], argv[3], strlen(argv[3]), KEY_SPEC_THREAD_KEYRING);
if (key == -1)
err(EXIT_FAILURE, "add_key");

if (keyctl_set_timeout(key, 60) == -1)
err(EXIT_FAILURE, "keyctl_set_timeout");
if (keyctl_setperm(key, KEY_POS_ALL|KEY_USR_VIEW|KEY_USR_READ|KEY_USR_WRITE|KEY_USR_SEARCH) == -1)
err(EXIT_FAILURE, "keyctl_setperm");
if (keyctl_link(key, KEY_SPEC_USER_KEYRING))
err(EXIT_FAILURE, "keyctl_link");
keyctl_unlink(key, KEY_SPEC_THREAD_KEYRING);

exit(EXIT_SUCCESS);
}


signature.asc
Description: PGP signature

Bug#926981: golang-1.12-go: Needs /etc/alternatives/go to be useful

[Nye Liu]

On 8/29/2019 8:08 AM, Shengjing Zhu wrote:


That definitely does not provide update-alternatives functionality.


We don't provide update-alternatives for difference versions. This is
not the goal of update-alternatives.
that is ABSOLUTELY one of the roles of update-alternatives, particularly 
for compiler variants, e.g. gcc, java, etc.

Bug#939439: python3-websockify: trying to overwrite '/usr/share/man/man1/websockify.1.gz', which is also in package websockify 0.8.0+dfsg1-14

[Axel Beckert]

Package: python3-websockify,websockify
Version: 0.8.0+dfsg1-14
Severity: serious

Upgrading websockify from 0.8.0+dfsg1-10 to 0.8.0+dfsg1-14 fails for me
as follows when its new dependency python3-websockify is unpacked:

Preparing to unpack .../websockify_0.8.0+dfsg1-14_armhf.deb ...
Unpacking websockify (0.8.0+dfsg1-14) over (0.8.0+dfsg1-10) ...
Selecting previously unselected package python3-websockify.
Preparing to unpack .../python3-websockify_0.8.0+dfsg1-14_armhf.deb ...
Unpacking python3-websockify (0.8.0+dfsg1-14) ...
dpkg: error processing archive 
/var/cache/apt/archives/python3-websockify_0.8.0+dfsg1-14_armhf.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/websockify.1.gz', which is also in 
package websockify 0.8.0+dfsg1-14
Errors were encountered while processing:
 /var/cache/apt/archives/python3-websockify_0.8.0+dfsg1-14_armhf.deb

Seems as if /usr/share/man/man1/websockify.1.gz is installed into two
binary packages from the same source package at the same time.

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'buildd-unstable'), (500, 'testing'), (110, 'experimental'), (1, 
'experimental-debug'), (1, 'buildd-experimental')
Architecture: armhf (armv7l)

Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT)
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)

Bug#939438: RFS: lebiniou/3.31-1 -- displays images that evolve with sound

[Olivier Girondel]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "lebiniou":

 * Package name: lebiniou
   Version : 3.31-1
   Upstream Author : Olivier Girondel 
 * URL : https://biniou.net
 * License : GPL-2+
   Section : graphics

It builds this binary package:

  lebiniou - displays images that evolve with sound

The package appears to be lintian-clean.

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.31-1.dsc

Changes since the last upload:

  * New upstream release 3.31.
  * debian/control: Remove libpnglite-dev.
  * debian/control: Add libmagickwand-dev.

Regards,
  Olivier Girondel

Bug#939357: [pkg-cryptsetup-devel] Bug#939357: cryptsetup-run: invoking "sudo cryptdisks_start" with "decrypt_keyctl" in crypttab fails

[Guilhem Moulin]

Control: retitle -1 `decrypt_keyctl` fails when the user-keyring(7) isn't 
attached to the calling process

Hi Sebastian,

Thanks for the detailed report!  I was able to reproduce this in a fresh
Buster netinstall, taking SSH sessions and sudo(8)'s ‘-i’ flag out of
the picture.  This is what I get right after a reboot:

user@kvm-31992:~$ sudo keyctl show @u
Keyring
  99804791 --alswrv  0 65534  keyring: _uid.0
user@kvm-31992:~$ sudo keyctl show @s
Keyring
1021507217 --alswrv   1000  1000  keyring: _ses
 872133423 ---lswrv   1000 65534   \_ keyring: _uid.1000
user@kvm-31992:~$ sudo keyctl show @us
Keyring
 133933438 --alswrv  0 65534  keyring: _uid_ses.0
  99804791 --alswrv  0 65534   \_ keyring: _uid.0

Keys attached to root's user-keyring(7) can't be read.

user@kvm-31992:~$ sudo keyctl add user "foo" "bar" @u
875128385
user@kvm-31992:~$ sudo keyctl show @us
Keyring
 133933438 --alswrv  0 65534  keyring: _uid_ses.0
  99804791 --alswrv  0 65534   \_ keyring: _uid.0
 875128385 --alswrv  0 0   \_ user: foo
user@kvm-31992:~$ sudo keyctl print 875128385
keyctl_read_alloc: Permission denied

So LUKS2 volumes can't be open using token keyrings:

user@kvm-31992:~$ sudo dd if=/dev/zero of=/tmp/disk.img bs=1M count=64 
status=none
user@kvm-31992:~$ sudo cryptsetup luksFormat -q \
--pbkdf-force-iterations 4 --pbkdf-memory 32 /tmp/disk.img </dev/null
Caching passphrase for foo:  ***
root@kvm-31992:/home/user# exit

I suppose /etc/pam.d/sudo could use pam_keyinit(8) to initialize a new
session instead of doing the above dance.  Anyway cryptsetup calls
request_key("user",,NULL,0) at the moment, so unlocking LUKS2 devices
via keyring tokens will only works in sessions where the user-keyring(7)
is linked to the session-keyring(7).

On Wed, 04 Sep 2019 at 00:18:57 +0200, Sebastian Mohr wrote:
> I don't know whether there are further security implications or
> something like that,

AFAICT blindly using session-keyring(7) as it might open a window during
which any program in the user session is able to read the payload:

user@kvm-31992:~$ sudo keyctl add user "foo" "foo" @s
137160032
user@kvm-31992:~$ keyctl show @s
Keyring
 461059914 --alswrv   1000  1000  keyring: _ses
 641525861 --alswrv   1000 65534   \_ keyring: _uid.1000
 137160032 --alswrv  0 0   \_ user: foo
user@kvm-31992:~$ keyctl print 137160032
foo

(While the key is owned by the privileged user, it's possessed by the
caller.  It might even be possible to poison the session-keyring(7)
by creating %user:foo with non-root ownership.)  I think the best place
to solve that is in /etc/pam.d/sudo itself, but failing that I suppose
it's acceptable to have the payload readable by root (perhaps only as
fallback, when the caller doesn't have enough right on the key it's
adding).

Perhaps keyctl(1) could provide a wrapper using thread-keyring(7) as
temporary keyring, like the attached PoC.  Or we could even rewrite
decrypt_keyctl in C, or merge it with askpass.  In fact one of our goals
for this release cycle is to better integrate crypttab(5) with LUKS2
native keyring support, and that probably goes via adding keyring
support in askpass. 

Cheers,
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#937481: pymol: Python2 removal in sid/bullseye

[Sandro Tosi]

Hey Stuart,
i saw you updated the git repo for pymol a couple of days ago, are you
also planning on uploading it soon? it currently depends on
20-something python2 modules, and it would be extra beneficial if we
can start removing these highly-connected packages soon.

Thanks!

PS: i believe # 910686 could be closed in the same release too

On Fri, 30 Aug 2019 07:34:29 + Matthias Klose  wrote:
> Package: src:pymol
> Version: 2.2.0+dfsg-4
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
>
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
>
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
>
> - Convert your Package to Python3. This is the preferred option.  In
>   case you are providing a Python module foo, please consider dropping
>   the python-foo package, and only build a python3-foo package.  Please
>   don't drop Python2 modules, which still have reverse dependencies,
>   just document them.
>
>   This is the preferred option.
>
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.  If the
>   package still has reverse dependencies, raise the severity to
>   "serious" and document the reverse dependencies with the BTS affects
>   command.  If the package has no reverse dependencies, confirm that
>   the package can be removed, reassign this issue to ftp.debian.org,
>   make sure that the bug priority is set to normal and retitle the
>   issue to "RM: PKG -- removal triggered by the Python2 removal".
>
> - If the package has still many users (popcon >= 300), or is needed to
>   build another package which cannot be removed, document that by
>   adding the "py2keep" user tag (not replacing the py2remove tag),
>   using the debian-pyt...@lists.debian.org user.  Also any
>   dependencies on an unversioned python package (python, python-dev)
>   must not be used, same with the python shebang.  These have to be
>   replaced by python2/python2.7 dependencies and shebang.
>
>   This is the least preferred option.
>
> If the conversion or removal needs action on another package first,
> please document the blocking by using the BTS affects command, like
>
>   affects  + src:pymol
>
> If there is no py2removal bug for that reverse-dependency, please file
> a bug on this package (similar to this bug report).
>
> If there are questions, please refer to the wiki page for the removal:
> https://wiki.debian.org/Python/2Removal, or ask for help on IRC
> #debian-python, or the debian-pyt...@lists.debian.org mailing list.
>
>

Bug#868527: [buildd-tools-devel] Bug#868527: Bug#868527: want sbuild --no-source or something

[Sean Whitton]

Hello,

On Wed 04 Sep 2019 at 08:34AM +02, Johannes Schauer wrote:

> okay now I'm confused. I read [1] and it made me understand that users somehow
> have to remember this horribly complicated sbuild command in certain
> circumstances.
>
> [1] https://lists.debian.org/23912.64795.250863.812...@chiark.greenend.org.uk
>
> I came back to this bug because I find it horrible for users having to 
> remember
> this rune. But now you say that dgit is already taking care of doing the right
> thing?

I'm sorry, I think I confused two dgit+sbuild topics.  Let's continue
the discussion in response to Ian's message.  Thanks again for your
interest.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#894519: xpra 2.4 depends on python-gtkglext1

[Sandro Tosi]

control: severity -1 serious

On Wed, 17 Oct 2018 13:36:07 -0400 Jeremy Bicha  wrote:
> python-gtkglext1 is back in Testing (Buster) now.

if i dont hear back in a week, i'll retitle this bug RM; raising to RC
for now for visibility

Bug#939437: ruby-glib2: missing dependency on ruby-pkg-config >=1.3.5

[Cédric Boutillier]

Package: ruby-glib2
Version: 3.3.7-1
Severity: important

Dear Maintainer,

the glib2 gemspec indicates that it should depend on ruby-pkg-config.
However this package does not appear in the dependency list. gem
dependency check will thus fail for every package depending on
ruby-glib2.

Please add the dependency or remove it from gemspec depending on what is
the best approach.

Best wishes,

Cédric

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

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

Versions of packages ruby-glib2 depends on:
ii  libc6 2.28-10
ii  libglib2.0-0  2.60.6-2
ii  libruby2.52.5.5-4
ii  ruby  1:2.5.1

ruby-glib2 recommends no packages.

ruby-glib2 suggests no packages.

-- no debconf information

Bug#921694: mdk4: FTBFS randomly when built in parallel (undefined reference to `getFrequencyFromChannel')

[Samuel Henrique]

Hello Santiago,

Can you please check whether this problem persists with the latest version
uploaded to unstable?
mdk4 4.1+git20190904-1

It was uploaded a couple of hours ago.

I told upstream to wait for confirmation that this problem is happening
with the current code of mdk4.

Thanks

-- 
Samuel Henrique 

Bug#939435: cgroupfs-mount: mount a name=systemd cgroup hierarchy for lxc

[StalkR]

Package: cgroupfs-mount
Version: 1.4
Severity: normal
Tags: patch

Dear Maintainer,

I run my host without systemd (sysvinit).
I installed lxc. lxc-checkconfig complains about cgroups.
Debian wiki 
(https://wiki.debian.org/LXC#Preparing_host_system_WITHOUT_Systemd_for_running_LXC)
says to install cgroupfs-mount, but lxc-checkconfig still complains:
> Cgroup v1 systemd controller: missing
I created a container (lxc-create -n buster -t debian -- -r buster)
which has systemd by default, and indeed it does not start.

Gentoo wiki (https://wiki.gentoo.org/wiki/LXC#Mounted_cgroup_filesystem)
explains the issue:
> the host needs to have a name=systemd cgroup hierarchy mounted. Doing so
> does not require running systemd on the host:
> root # mkdir -p /sys/fs/cgroup/systemd
> root # mount -t cgroup -o none,name=systemd systemd /sys/fs/cgroup/systemd
I patched /usr/bin/cgroupfs-mount to do this, and it works:
lxc-checkconfig no longer complains, and container starts.

Please consider the attached patch.

Thanks!

-- System Information:
Debian Release: 10
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
--- /usr/bin/cgroupfs-mount 2019-09-04 23:45:04.697211790 +0200
+++ /usr/bin/cgroupfs-mount 2019-09-04 23:44:24.801211790 +0200
@@ -51,4 +51,14 @@
 #  freezer 7   3   1
 #  blkio   8   3   1
 
+# named cgroups
+for sys in systemd; do
+   mkdir -p $sys
+   if ! mountpoint -q $sys; then
+   if ! mount -n -t cgroup -o none,name=$sys cgroup $sys; then
+   rmdir $sys || true
+   fi
+   fi
+done
+
 exit 0

Bug#939436: node-js-beautify: does not start: 'config-chain' not found

[Johannes Deutsch]

Package: node-js-beautify
Version: 1.7.5+repack-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

after installing css-beautify refuses to run with the following error:


internal/modules/cjs/loader.js:670
throw err;
^

Error: Cannot find module 'config-chain'
at Function.Module._resolveFilename (internal/modules/cjs/loader.js:668:15)
at Function.Module._load (internal/modules/cjs/loader.js:591:27)
at Module.require (internal/modules/cjs/loader.js:723:19)
at require (internal/modules/cjs/helpers.js:14:16)
at Object. (/usr/share/nodejs/js-beautify/js/lib/cli.js:40:10)
at Module._compile (internal/modules/cjs/loader.js:816:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:827:10)
at Module.load (internal/modules/cjs/loader.js:685:32)
at Function.Module._load (internal/modules/cjs/loader.js:620:12)
at Module.require (internal/modules/cjs/loader.js:723:19)

However 'config-chain' is also installed on the system.



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

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

Versions of packages node-js-beautify depends on:
ii  node-config-chain  1.1.11-1
ii  node-lru-cache 5.1.1-5
ii  node-mkdirp0.5.1-1
ii  node-nopt  3.0.6-3
ii  node-semver5.7.1-1
ii  node-sigmund   1.0.0-1
ii  nodejs 11.15.0-1nodesource1

Versions of packages node-js-beautify recommends:
ii  jsbeautifier  1.6.4-7

node-js-beautify suggests no packages.

-- no debconf information

Bug#938964: please don't install runit-helper on everyone's system

[Dmitry Bogatov]

[2019-09-01 21:38] Shengjing Zhu 
> On Sun, Sep 1, 2019 at 9:23 PM Dmitry Bogatov  wrote:
> > Just for my curiosity (not going to happen in my watch), would you be
> > happier if `runit-helper` script was part of init-system-helpers (which
> > is essential, anyway).
> I'm not sure why you didn't chose this at first. As it calls itself
> "helper tools for all init systems".

It calls, yeah.

Package: init-system-helpers
Maintainer: Debian systemd Maintainers 

-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#939434: viking: should allow the control of cache expiry time

[Vincent Lefevre]

Package: viking
Version: 1.7-1
Severity: normal

If "Autodownload maps" is enabled, in practice, one also needs to
enable "Autodownload Only Gets Missing Maps" (each time viking is
started, because this is not the default and this option is not
saved). Otherwise moving the map often makes viking hang for a few
seconds: it seems that it tries to re-download parts of the maps,
even if this has already been done several seconds ago, and this
makes viking hardly usable.

The issue with enabling "Autodownload Only Gets Missing Maps" is that
parts of the maps could have been downloaded years ago, so that they
can have become obsolete.

The user should be able to control cache expiry time.

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

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

Versions of packages viking depends on:
ii  gpsbabel 1.6.0+ds-7
ii  libatk1.0-0  2.33.3+really2.32.0-4
ii  libbz2-1.0   1.0.6-9.2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libcurl3-gnutls  7.65.3-1
ii  libexpat12.2.7-1
ii  libfontconfig1   2.13.1-2+b1
ii  libfreetype6 2.9.1-4
ii  libgcc1  1:9.2.1-6
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libgeoclue-2-0   2.5.3-1
ii  libgexiv2-2  0.10.9-1
ii  libglib2.0-0 2.60.6-2
ii  libgps23 3.17-7
ii  libgtk2.0-0  2.24.32-3
ii  libicu63 63.2-2
ii  libmagic11:5.37-5
ii  libmapnik3.0 3.0.22+ds1-1
ii  libnettle6   3.4.1-1+b1
ii  liboauth01.0.3-3
ii  libpango-1.0-0   1.42.4-7
ii  libpangocairo-1.0-0  1.42.4-7
ii  libpangoft2-1.0-01.42.4-7
ii  libsqlite3-0 3.29.0-2
ii  libstdc++6   9.2.1-6
ii  libx11-6 2:1.6.7-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages viking recommends:
ii  expect [expect-dev]  5.45.4-2+b1

Versions of packages viking suggests:
pn  gpsd  

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#939433: RFS: xca/2.1.2-2 -- x509 Certification Authority management tool based on QT

[Thomas Ward]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "xca" as I do not yet have 
'unsponsored' upload privileges for this package even though I am the 
maintainer.


* Package name : xca
Version : 2.1.2-2
Upstream Author : Christian Hohnstaedt 
* URL : https://hohnstaedt.de/xca/
* License : BSD-3-clause
* Vcs : https://salsa.debian.org/debian/xca
Section : x11

It builds those binary packages:

xca - x509 Certification Authority management tool based on QT

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


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

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

dget -x https://mentors.debian.net/debian/pool/main/x/xca/xca_2.1.2-2.dsc

Changes since the last upload:

* d/patches/0002-pkg-config-remove-hardcoding.patch: Remove hard-coded
pkg-config in configure.ac, and replace it with $PKG_CONFIG references
instead.
Thanks to Helmut Grohne for the 1.4.1-1 patch, which is the basis
for this patch.
(Closes: #896891)

Regards,

Thomas

Bug#938352: repo: Python2 removal in sid/bullseye

[Andreas Henriksson]

Control: tags -1 + fixed-upstream

On Fri, Aug 30, 2019 at 07:50:09AM +, Matthias Klose wrote:
> Package: src:repo
[...]
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3.
[...]

It seems there's been recent work on improving python3 support upstream,
including removing the "python3 is experimental" warning.

Upgrading to the latest upstream release (which currently seem to be
v1.13.5.1) looks like a good start to adress this issue. I'm thus
tagging this with fixed-upstream. Please remove if additional upstream
work is actually needed.

Regards,
Andreas Henriksson

Bug#939002: Problem in test suite of sf since upgrade of proj

[Edzer Pebesma]

Thanks for reporting.

I see warnings of this kind:

< Warning message:
< In CPL_crs_from_proj4string(x) :
<   GDAL Message 1: +init=epsg: syntax is deprecated. It might
return a CRS with a non-EPSG compliant axis order.

but not the errors you get with +init=epsg: ; this is with PROJ
6.1.1RC1, and now with PROJ 6.2.0. I have no idea why.


On 9/4/19 3:58 PM, Andreas Tille wrote:
> Control: tags -1 upstream
> Control: forwarded -1 Edzer Pebesma 
> 
> Hi Edzer,
> 
> since the upgrade to proj (6.1.1-1) the autopkgtest for sf fails:
> 
> $ LC_ALL=C.UTF-8 R --no-save < testthat.R 
> 
> R version 3.6.1 (2019-07-05) -- "Action of the Toes"
> Copyright (C) 2019 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
> 
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
> 
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
> 
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
> 
>> library(testthat)
>> suppressPackageStartupMessages(library(sf))
>>
>> test_check("sf")
> proj_create: Error -5: unknown projection id
> proj_create: Error -9: unknown elliptical parameter name
> proj_create: init=epsg:/init=IGNF: syntax not supported in non-PROJ4 
> emulation mode
> proj_create: init=epsg:/init=IGNF: syntax not supported in non-PROJ4 
> emulation mode
> proj_create: init=epsg:/init=IGNF: syntax not supported in non-PROJ4 
> emulation mode
> ── 1. Error: $.crs works (@test_crs.R#49)  
> ─
> missing value where TRUE/FALSE needed
> 1: expect_true(is.numeric(st_crs("+init=epsg:3857 +units=m")$b)) at 
> testthat/test_crs.R:49
> 2: quasi_label(enquo(object), label, arg = "object")
> 3: eval_bare(get_expr(quo), get_env(quo))
> 4: st_crs("+init=epsg:3857 +units=m")
> 5: st_crs.character("+init=epsg:3857 +units=m")
> 6: make_crs(x)
> 
> proj_create: init=epsg:/init=IGNF: syntax not supported in non-PROJ4 
> emulation mode
> ── 2. Error: $.crs works 2 (@test_crs.R#55)  
> ───
> missing value where TRUE/FALSE needed
> 1: expect_true(is.numeric(st_crs("+init=epsg:3857 +units=km")$b)) at 
> testthat/test_crs.R:55
> 2: quasi_label(enquo(object), label, arg = "object")
> 3: eval_bare(get_expr(quo), get_env(quo))
> 4: st_crs("+init=epsg:3857 +units=km")
> 5: st_crs.character("+init=epsg:3857 +units=km")
> 6: make_crs(x)
> 
> Cannot open layer foo
> Reading layer `nospatial' from data source 
> `/usr/lib/R/site-library/sf/gpkg/nospatial.gpkg' using driver `GP
> Reading layer `nospatial' from data source 
> `/usr/lib/R/site-library/sf/gpkg/nospatial.gpkg' using driver `GP
> OGR: Unsupported geometry type
> Reading layer `nc' from data source `/usr/lib/R/site-library/sf/shape/nc.shp' 
> using driver `ESRI Shapefile'
> Simple feature collection with 100 features and 14 fields
> geometry type:  MULTIPOLYGON
> dimension:  XY
> bbox:   xmin: -84.32385 ymin: 33.88199 xmax: -75.45698 ymax: 36.58965
> epsg (SRID):4267
> proj4string:+proj=longlat +datum=NAD27 +no_defs
> driver `foo' not available.
> Dataset /tmp/RtmpTlApgW/file1ffa3ef15a25.gpkg already exists: remove first, 
> use update=TRUE to append,
> delete_layer=TRUE to delete layer, or delete_dsn=TRUE to remove the entire 
> data source before writing.
> Creating layer . failed.
> Failed to create feature 1 in x
> Failed to create feature 1 in x
> Failed to create feature 1 in x
> ══ testthat results  
> ═══
> [ OK: 658 | SKIPPED: 59 | WARNINGS: 6 | FAILED: 2 ]
> 1. Error: $.crs works (@test_crs.R#49) 
> 2. Error: $.crs works 2 (@test_crs.R#55) 
> 
> Error: testthat unit tests failed
> Execution halted
> 
> 
> Could you try to port sf to the recent version of proj?
> 
> Kind regards
> 
>   Andreas.
> 
> 

-- 
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081


pEpkey.asc
Description: application/pgp-keys

Bug#938868: yowsup: Python2 removal in sid/bullseye

[Steve Langasek]

Package: yowsup
Version: 2.5.7-4
Followup-For: Bug #938868
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

python-axolotl has already been removed from the latest upload to Debian, so
this makes yowsup's remaining python2 dependency more problematic.

There are no reverse-dependencies of python-yowsup in the archive, so this
is a straightforward removal.  Please see the attached patch, which has been
uploaded to Ubuntu for this issue.

-- 
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 Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru yowsup-2.5.7/debian/control yowsup-2.5.7/debian/control
--- yowsup-2.5.7/debian/control 2018-10-05 13:52:27.0 -0700
+++ yowsup-2.5.7/debian/control 2019-09-04 13:15:14.0 -0700
@@ -4,11 +4,6 @@
 Maintainer: Josue Ortega 
 Build-Depends: debhelper (>= 11),
dh-python,
-   python-all,
-   python-axolotl (>= 0.1.39),
-   python-dateutil,
-   python-pil,
-   python-setuptools,
python3-all,
python3-axolotl (>= 0.1.39),
python3-dateutil,
@@ -19,42 +14,6 @@
 Vcs-Git: https://salsa.debian.org/debian/yowsup.git
 Vcs-Browser: https://salsa.debian.org/debian/yowsup
 
-Package: python-yowsup
-Architecture: all
-Depends: ${misc:Depends}, ${python:Depends},
- python-yowsup-common (>= 2.5.7-1~)
-Description: library to implement a WhatsApp client
- WhatsApp Messenger is a cross-platform mobile messaging app
- which allows you to exchange messages, via Internet, without
- having to pay for SMS, using a mobile phone.
- .
- In addition to basic messaging, WhatsApp users can create
- groups, send each other unlimited images, video and audio
- media messages.
- .
- Yowsup is a cross platform Python library that enable to do all
- the previous in your own app. Yowsup allows you to login and use
- the WhatsApp service, providing all capabilities of an official
- WhatsApp client, allowing to create a full-fledged custom
- WhatsApp client.
- .
- python-yowsup has these features:
-- Registration.
-- Text send/receive.
-- Encryption of messages.
-- Media send/receive (images, videos, audio, location,
-  contact cards).
-- Groups(create, leave, join, update picture, updating
-  subject).
-- Fetch user profile picture.
-- Fetch user status.
-- Set profile picture.
-- Set group icon.
-- Set status and others.
- .
- The package yowsup-cli is a good example of the python-yowsup
- implementation.
-
 Package: python3-yowsup
 Architecture: all
 Depends: ${misc:Depends}, ${python3:Depends},
@@ -131,7 +90,7 @@
 Section: net
 Architecture: all
 Depends: ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  python3-yowsup,
  python3-libxml2,
  python3-axolotl (>= 0.1.39),
diff -Nru yowsup-2.5.7/debian/python3-yowsup.docs 
yowsup-2.5.7/debian/python3-yowsup.docs
--- yowsup-2.5.7/debian/python3-yowsup.docs 1969-12-31 16:00:00.0 
-0800
+++ yowsup-2.5.7/debian/python3-yowsup.docs 2018-10-05 13:52:27.0 
-0700
@@ -0,0 +1 @@
+README.md
diff -Nru yowsup-2.5.7/debian/python3-yowsup.README.Debian 
yowsup-2.5.7/debian/python3-yowsup.README.Debian
--- yowsup-2.5.7/debian/python3-yowsup.README.Debian1969-12-31 
16:00:00.0 -0800
+++ yowsup-2.5.7/debian/python3-yowsup.README.Debian2018-10-05 
13:52:27.0 -0700
@@ -0,0 +1,9 @@
+python-yowsup for Debian
+
+
+A full and updated python-yowsup library specification/documentation
+is available at:
+
+https://github.com/tgalal/yowsup/wiki
+
+ -- Joao Eriberto Mota Filho   Thu, 30 Apr 2015 17:32:30 
-0300
diff -Nru yowsup-2.5.7/debian/python-yowsup.docs 
yowsup-2.5.7/debian/python-yowsup.docs
--- yowsup-2.5.7/debian/python-yowsup.docs  2018-10-05 13:52:27.0 
-0700
+++ yowsup-2.5.7/debian/python-yowsup.docs  1969-12-31 16:00:00.0 
-0800
@@ -1 +0,0 @@
-README.md
diff -Nru yowsup-2.5.7/debian/python-yowsup.README.Debian 
yowsup-2.5.7/debian/python-yowsup.README.Debian
--- yowsup-2.5.7/debian/python-yowsup.README.Debian 2018-10-05 
13:52:27.0 -0700
+++ yowsup-2.5.7/debian/python-yowsup.README.Debian 1969-12-31 
16:00:00.0 -0800
@@ -1,9 +0,0 @@
-python-yowsup for Debian
-
-
-A full and updated python-yowsup library specification/documentation
-is available at:
-
-https://github.com/tgalal/yowsup/wiki
-
- -- Joao Eriberto Mota Filho   Thu, 30 Apr 2015 17:32:30 
-0300
diff -Nru yowsup-2.5.7/debian/rules yowsup-2.5.7/debian/rules
--- yowsup-2.5.7/debian/rules   2018-10-05 13:52:27.0 -0700
+++ yowsup-2.5.7/debian/rules   2019-09-04 13:15:14.0 -0700
@@ -4,8 +4,7 @@
 

Bug#939048: transition: glibc

[Paul Gevers]

Hi maintainers of sextractor and iraf-fitsutil,

In bug 939048 we are discussing a transition slot for glibc 2.29. As
part of the preparation we are checking autopkgtest results in unstable,
when glibc 2.29 from experimental is installed. This e-mail is a heads
up of failures in your packages. Can you please check that these are
genuine? If so, please either let us know in this bug, or by filing a
bug against your own package that blocks this bug.

On 04-09-2019 22:06, Aurelien Jarno wrote:

[...]

> Thanks for the info.
> 
>> I'll check why there are so many "Test in progress" items. Most of them
>> should be neutral I see.
>  
> Ok. I have checked the one marked as regression, and there are only two
> if them that are real regressions in addition to postgresql-hll:
> - iraf-fitsutil: this is a strange issue, I am able to reproduce it, but
>   I haven't investigated more yet.

Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/i/iraf-fitsutil/2885704/log.gz

> - sextractor: I am able to reproduce the issue, it seems to be related
>   to a math precision change, but I haven't investigated more yet.

Log:
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/sextractor/2841528/log.gz

@aurelien, so, let's have the maintainers on board.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#937125: neard: Python2 removal in sid/bullseye

[Andreas Henriksson]

Control: tags -1 + patch

On Fri, Aug 30, 2019 at 07:28:03AM +, Matthias Klose wrote:
> Package: src:neard
[...]
> Usertags: py2removal
> 
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https://lists.debian.org/debian-python/2019/07/msg00080.html
> 
> Your package either build-depends, depends on Python2, or uses Python2
> in the autopkg tests.  Please stop using Python2, and fix this issue
> by one of the following actions.
> 
> - Convert your Package to Python3. [...]

The src:neard package seems to ship a few test scripts in a private
location in the neard-tools package. It seems like these could simply be
dropped without anyone noticing. Other alternative would ofcourse be to
convert them to python3, but given that upstream has had no activity for
a couple of years I doubt that's going to happen.

I'm attaching a trivial patch that auto-converts the scripts (hoping
that produces a good enough result, and even if it doesn't the files are
installed in a private location and seems completely unused anyway)
during installation and swaps all helpers and packaging meta-data over
to python3.

A debdiff is attached. The result has only been build-tested.
Anyone is welcome to review and upload.

Regards,
Andreas Henriksson
diff -Nru neard-0.16/debian/changelog neard-0.16/debian/changelog
--- neard-0.16/debian/changelog 2017-01-19 03:24:08.0 +0100
+++ neard-0.16/debian/changelog 2019-09-04 22:25:59.0 +0200
@@ -1,3 +1,11 @@
+neard (0.16-0.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Convert neard-tools private test utils to python3 during install and
+switch dependencies to python3 equivalent (Closes: #937125)
+
+ -- Andreas Henriksson   Wed, 04 Sep 2019 22:25:59 +0200
+
 neard (0.16-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru neard-0.16/debian/control neard-0.16/debian/control
--- neard-0.16/debian/control   2017-01-19 03:21:14.0 +0100
+++ neard-0.16/debian/control   2019-09-04 22:25:22.0 +0200
@@ -15,7 +15,7 @@
  libnl-3-dev (>= 3.2),
  libnl-genl-3-dev (>= 3.2),
  pkg-config,
- python,
+ 2to3,
  systemd,
 
 Package: neard
@@ -40,10 +40,10 @@
 Architecture: linux-any
 Depends:
  ${misc:Depends},
- ${python:Depends},
+ ${python3:Depends},
  ${shlibs:Depends},
  neard (= ${binary:Version}),
- python-dbus,
+ python3-dbus,
 Description: neard command-line tools
  This package contains various scripts for testing neard.
 
diff -Nru neard-0.16/debian/neard-tools.install 
neard-0.16/debian/neard-tools.install
--- neard-0.16/debian/neard-tools.install   2013-04-15 16:14:02.0 
+0200
+++ neard-0.16/debian/neard-tools.install   2019-09-04 22:23:36.0 
+0200
@@ -1,2 +1,2 @@
-test/* usr/lib/neard/tools
+usr/lib/neard/tools
 usr/bin/nfctool
diff -Nru neard-0.16/debian/rules neard-0.16/debian/rules
--- neard-0.16/debian/rules 2017-01-16 00:46:38.0 +0100
+++ neard-0.16/debian/rules 2019-09-04 22:25:59.0 +0200
@@ -11,7 +11,7 @@
 
 
 %:
-   dh $@ --with autotools_dev,python2
+   dh $@ --with autotools_dev,python3
 
 override_dh_auto_configure:
./configure $(confflags) \
@@ -27,6 +27,11 @@
# Temporary workaround for broken .pc file, fixed in git master.
sed -i -e 's/@pkglibdir@/$${pkglibdir}/' \
$(CURDIR)/debian/tmp/usr/lib/pkgconfig/neard.pc
+   # Convert private test utilities to python3 during installation
+   2to3 -f all --output-dir=$(CURDIR)/debian/tmp/usr/lib/neard/tools/ -W 
-n test/*
+   # ... also fix up their shebangs
+   sed -ie '1 s,#!.*python.*,#!/usr/bin/python3,' 
$(CURDIR)/debian/tmp/usr/lib/neard/tools/*
 
-override_dh_python2:
-   dh_python2 /usr/lib/neard/tools/
+
+override_dh_python3:
+   dh_python3 /usr/lib/neard/tools/

Bug#939048: transition: glibc

[Aurelien Jarno]

On 2019-09-04 21:08, Paul Gevers wrote:
> Hi Aurelien,
> 
> On 02-09-2019 21:43, Aurelien Jarno wrote:
> 
> [...]
> 
> >>> - nemo: seems to be a bug in udisks2 postinst script
> >>> - pg-repack: debci issue, the regression is caused by libpq5 from
> >>>   experimental, which is wrongly selected instead of the unstable
> >>>   version.
> >>> - repmgr: ditto with libpq-dev.
> 
> [...]
> 
> >>> There are also a few failures that seems to be related to slight change
> >>> of precision of the math functions: pyfai, sextractor.
> >>
> >> So what do you propose with these? Do they need to fix something? E.g.
> >> their autopkgtest? Then we better warn them *now*, i.e. filing bugs.
> > 
> > For those I still only have look the test logs. I still need to debug
> > the issue first and also check if this is a real bug or a false
> > positive.
> 
> pyfai dropped of the list.
> 
> Myon is aware of the postgresql-hll regression:
> https://github.com/citusdata/postgresql-hll/issues/67
>
> We'll remove the package from testing when we start the transition.

Thanks for the info.

> I'll check why there are so many "Test in progress" items. Most of them
> should be neutral I see.
 
Ok. I have checked the one marked as regression, and there are only two
if them that are real regressions in addition to postgresql-hll:
- iraf-fitsutil: this is a strange issue, I am able to reproduce it, but
  I haven't investigated more yet.
- sextractor: I am able to reproduce the issue, it seems to be related
  to a math precision change, but I haven't investigated more yet.

Aurelien

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


signature.asc
Description: PGP signature

Bug#939432: buster-pu: package lucene-solr/3.6.2+dfsg-20

[Markus Koschany]

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

Dear release team,

I would like to update lucene-solr in Buster. It is affected by Debian
bug #933854 and #933857. Stretch is not affected. The solr-jetty
service will not start out of the box until some systemd configuration
by jetty9 is overridden. Please find attached the debdiff.

Regards,

Markus
diff -Nru lucene-solr-3.6.2+dfsg/debian/changelog 
lucene-solr-3.6.2+dfsg/debian/changelog
--- lucene-solr-3.6.2+dfsg/debian/changelog 2019-04-25 16:39:14.0 
+0200
+++ lucene-solr-3.6.2+dfsg/debian/changelog 2019-09-04 22:30:29.0 
+0200
@@ -1,3 +1,14 @@
+lucene-solr (3.6.2+dfsg-20+deb10u1) buster; urgency=medium
+
+  * Team upload.
+  * Disable obsolete call to ContextHandler in solr-jetty9.xml.
+Install solr-permissions.conf into /etc/systemd/system/jetty9.service.d/ 
and
+override read-only permissions of Jetty9 which will allow the service to
+start out-of-the-box again.
+Thanks to Stephan Beirer for the report. (Closes: #933854, #933857)
+
+ -- Markus Koschany   Wed, 04 Sep 2019 22:30:29 +0200
+
 lucene-solr (3.6.2+dfsg-20) unstable; urgency=medium
 
   * Team upload.
diff -Nru lucene-solr-3.6.2+dfsg/debian/solr-jetty.install 
lucene-solr-3.6.2+dfsg/debian/solr-jetty.install
--- lucene-solr-3.6.2+dfsg/debian/solr-jetty.install2019-04-25 
16:39:14.0 +0200
+++ lucene-solr-3.6.2+dfsg/debian/solr-jetty.install2019-09-04 
22:30:29.0 +0200
@@ -1 +1,2 @@
 debian/solr-jetty.xml /etc/solr/
+debian/solr-permissions.conf /etc/systemd/system/jetty9.service.d/
diff -Nru lucene-solr-3.6.2+dfsg/debian/solr-jetty.xml 
lucene-solr-3.6.2+dfsg/debian/solr-jetty.xml
--- lucene-solr-3.6.2+dfsg/debian/solr-jetty.xml2019-04-25 
16:39:14.0 +0200
+++ lucene-solr-3.6.2+dfsg/debian/solr-jetty.xml2019-09-04 
22:30:29.0 +0200
@@ -14,9 +14,11 @@
   
 
   
+  
 

Bug#939408: systemd in buster broken with RootDirectory and User

[Michael Biebl]

Am 04.09.19 um 14:57 schrieb Michael Biebl:
> Am 04.09.19 um 14:09 schrieb Stefan Priebe - Profihost AG:
>> Hello,
>>
>> currently systemd is broken in buster regarding RootDirectory and User.
>>
>> The issue was fixed in systemd 243 and the relevant commits are
>> referenced in the specific bug report:
>> https://github.com/systemd/systemd/issues/12498
> 
> Can you file a bug report please so we can track this properly
> 
>> Any chance to get this fixed soon? This broke a lot of our services from
>> stretch.
> 
> This will have to be fixed via a buster point release. We are too late
> for 10.1, which is just around the corner, so this will have to wait for
> 10.2. I'm not a release manager, so I can't tell you when 10.2 will
> happen, they probably don't know themselves yet.
> But it's typically around 2 months after the last point release.

Stefan, if you could test the preliminary packages for 10.2 from [1]
and report back if those fix your issue, this would be appreciated.

Regards,
Michael

[1] https://people.debian.org/~biebl/systemd/buster/
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#939411: amanda: merged /usr and tar path problem in /etc/amanda-security.conf

[Gene Heskett]

it appears that a similar fix is required for those systems using amgtar 
in place of tar.


The amgtar path must also point to /usr/bin/tar in order for amgtar to 
be able to use /usr/bin/tar with amgtar's list of options.

Bug#934974: More than USB?

[Martin Michlmayr]

It seems more than USB is broken.  This post says that
mmc and TFTP doesn't work either.

https://lists.debian.org/debian-arm/2019/09/msg2.html

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

Bug#792778: nouveau: screen sometimes remains blank after "xset dpms force off"

[Vincent Lefevre]

Control: reopen -1
Control: found -1 5.2.9-2

On 2019-09-01 10:41:15 +0200, Vincent Lefevre wrote:
> On 2015-07-18 14:52:03 +0200, Vincent Lefevre wrote:
> > After I blank the screen of my laptop with "xset dpms force off", it
> > is usually unblanked as expected when I type a key or move the mouse,
> > but not always. When this occurs, the screen is no longer off, in the
> > sense I can see some light on it, but nothing is displayed.
> 
> This is old, and with a few tests on the same machine after using
> again nouveau since last night, I could not reproduce the problem
> with a 5.2.0-2-amd64 kernel. Closing.

I could reproduce it again. Exactly the same issue.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#939419: libparse-pidl-perl: version ordering issue.

[Andrew Bartlett]

On Wed, 2019-09-04 at 19:59 +0100, plugwash wrote:
> Package: libparse-pidl-perl
> Version: 2:4.9.5+dfsg-5+deb10u1+really0.02
> X-debbugs-cc: secur...@debian.org
> 
> It seems that the recent update to samba in buster-security generated a 
> libparse-pidl-perl package with a lower version number than the version 
> already in buster. As far as I can tell this has the following consequences.
> 
> 1. Users will not get the update to this package, (I don't think this is 
> a big problem in this particular case as I don't see anything perl 
> related in the changelog).
> 2. I suspect it will stop the security update getting rolled in to the 
> next point release.
> 3. It may mess up downstream infrastructure (that is how I ran into the 
> issue).
> 
> I see two possible fixes.
> 
> 1. Avoid using version numbers for the samba package that will trigger 
> this issue.
> 2. Change the logic that generates the version numbers for the 
> libparse-pidl-perl package.

3. Drop the package.  It is of very limited interest.  It should have
been dropped once Openchange was removed.  Anybody wishing to build
openchange can just install it from the Samba tarball.

PIDL is maintained for Samba's internal use (where we use it
extensively, and actively modify it for our needs), it really isn't
suitable for external consumption, except by wireshark which has a
modified, vendored copy.

Andrew Bartlett

-- 
Andrew Bartlett   http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT  http://catalyst.net.nz/services/samba

Bug#934974: u-boot: usb start fails on sheevaplug in u-boot 2019.01

[Martin Michlmayr]

* Jan Hahne  [2019-08-17 16:27]:
> But the command "usb start" gave me these errors:
> EHCI timed out on TD - token=0x80008d80
> EHCI timed out on TD - token=0x80008c80
>  ERROR: NOT USB_CONFIG_DESC 8f
> 2 USB Device(s) found
>   scanning usb for storage devices... 0 Storage Device(s) found

You mention USB problems.  We just got a report that said that
MMC and TFTP (network) didn't work either:
https://lists.debian.org/debian-arm/2019/09/msg2.html

Did you try those?  If so, I assume those failed for you as well?

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

Bug#938414: rrdtool python2 removal

[Andreas Henriksson]

Control: tags -1 + pending

Hello,

I quickly looked at this bug report to see if I could help but noticed
it had already been taken care of in:
https://salsa.debian.org/rrdtool-team/rrdtool/commit/43fc6247fb551100c7ac65da3ce09d99d602482d
and
https://salsa.debian.org/rrdtool-team/rrdtool/commit/4203eac1a28f965350527545d0ba5001e6ef98a5
I'm thus tagging this bug report as pending.

I noticed two things you might want to adress though:
- the dh-python build-dependency was removed. This package contains the
  dh_python3 helper which the package still seems to be using, so
  removing this build-dependency was likely a mistake.
- The debian/changelog should be changed from "(See: #938414)" to
  "(Closes: #938414)" so that this bug report gets closed automatically
  when the fixed package is uploaded.

Regards,
Andreas Henriksson

Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade

[Michael Biebl]

Hi Joel

On Tue, 26 Jun 2018 11:54:36 +0100 Joel Cross
 wrote:
> Package: systemd
> Version: 239-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Over the last few days (since my last system upgrade) I am unable to
> successfully hibernate/resume using the `systemctl hibernate` command. This is
> what happens:
> 
> - I run the command
> - The screen blinks a few times and my machine switches off, as expected
> - When I boot my machine back up, it takes me to the login screen, rather than
> restoring my pre-hibernate state.
> 
> In contrast, when I use the command `pm-hibernate` as root, my system is able
> to resume from hibernation as expected.
> 
> Please let me know what further information you need from me (if any) in order
> to be able to correctly diagnose this bug.
> 

This bug should be fixed by
https://github.com/systemd/systemd/commit/2002d8cdaee105a7ab6bc89d480a9ded2198247a
and
https://github.com/systemd/systemd/commit/64602c843beb228be919e5f0639427b60d589ec6

which are part of 243~rc2-1 which is available from experimental.
It would be awesome if you could test this version and confirm that it
fixes your problem.

Using the version from experimental should be fairly safe, but if you
are too concerned about using something from experimental, I can provide
a patch v242 package.


Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#939431: linux-image-5.2.0-2-amd64: failedto reeed

[Christian Petersen]

Package: src:linux
Version: 5.2.9-2
Severity: normal
Tags: upstream

Dear Maintainer,

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

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

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



-- Package-specific info:
** Version:
Linux version 5.2.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-21)) #1 SMP Debian 5.2.9-2 (2019-08-21)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.2.0-2-amd64 
root=UUID=1b98e41e-8276-493e-b9ca-6994e7aa1958 ro noacpi reboot=acpi 
ipv6.disable=1

** Tainted: POE (12289)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

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

** Model information
sys_vendor: Apple Inc.
product_name: Macmini4,1
product_version: 1.0
chassis_vendor: Apple Inc.
chassis_version: Mac-F2208EC8
bios_vendor: Apple Inc.
bios_version: MM41.88Z.0047.B00.1802021546
board_vendor: Apple Inc.
board_name: Mac-F2208EC8
board_version: 

** Loaded modules:
uinput
cpufreq_conservative
cpufreq_powersave
cpufreq_userspace
nls_ascii
nls_cp437
vfat
fat
snd_hda_codec_hdmi
snd_hda_codec_cirrus
snd_hda_codec_generic
ledtrig_audio
snd_hda_intel
snd_hda_codec
snd_hda_core
coretemp
snd_hwdep
kvm_intel
snd_pcm_oss
kvm
snd_mixer_oss
snd_pcm
snd_timer
efi_pstore
snd
irqbypass
sg
applesmc
input_polldev
soundcore
efivars
pcspkr
evdev
pcc_cpufreq
button
acpi_cpufreq
nvidia(POE)
drm
ecryptfs
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
hid_apple
hid_appleir
hid_generic
usbhid
hid
sr_mod
cdrom
sd_mod
ohci_pci
ahci
libahci
libata
ohci_hcd
tg3
ehci_pci
libphy
ehci_hcd
firewire_ohci
scsi_mod
ptp
pps_core
firewire_core
crc_itu_t
usbcore
usb_common
video

** PCI devices:
00:00.0 Host bridge [0600]: NVIDIA Corporation MCP89 HOST Bridge [10de:0d60] 
(rev a1)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 

00:03.3 RAM memory [0500]: NVIDIA Corporation MCP89 Memory Controller 
[10de:0d69] (rev a1)
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

00:04.1 USB controller [0c03]: NVIDIA Corporation MCP89 EHCI USB 2.0 Controller 
[10de:0d9d] (rev a2) (prog-if 20 [EHCI])
Subsystem: NVIDIA Corporation MCP89 EHCI USB 2.0 Controller [10de:cb89]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:06.0 USB controller [0c03]: NVIDIA Corporation MCP89 OHCI USB 1.1 Controller 
[10de:0d9c] (rev a1) (prog-if 10 [OHCI])
Subsystem: NVIDIA Corporation MCP89 OHCI USB 1.1 Controller [10de:cb89]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ohci-pci
Kernel modules: ohci_pci

00:06.1 USB controller [0c03]: NVIDIA Corporation MCP89 EHCI USB 2.0 Controller 
[10de:0d9d] (rev a2) (prog-if 20 [EHCI])
Subsystem: NVIDIA Corporation MCP89 EHCI USB 2.0 Controller [10de:cb89]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:08.0 Audio device [0403]: NVIDIA Corporation MCP89 High Definition Audio 
[10de:0d94] (rev a2)
Subsystem: NVIDIA Corporation MCP89 High Definition Audio [10de:cb89]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:0a.0 SATA controller [0106]: NVIDIA Corporation MCP89 SATA Controller (AHCI 
mode) [10de:0d88] (rev a2) (prog-if 01 [AHCI 1.0])
Subsystem: Apple Inc. MCP89 SATA Controller (AHCI mode) [106b:cb89]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ 

Bug#939363: [Pkg-openssl-devel] Bug#939363: openssl: Older OpenSSL binaries crash on startup, no error messages are shown.

[Sebastian Andrzej Siewior]

On 2019-09-03 21:24:04 [-0400], Dylan H. wrote:
> As title says. Using AppImages with older OpenSSL binaries instantly aborts 
> the
> application and I get no error codes. I have tested this with Ripcord and it
> will not open.

can you give some more details? Like what you have installed and what
have you started. Applications which linked against libssl have symbol
dependecies which means an older version is either linked to another
libssl or should work with the current library.

> Hopefully this will be resolved soon. The developer of this application
> (ripcord) says that the OpenSSL package is broken and incompatible with older
> binaries.

Can you provide a link to that application? I can't find anything
usefull. Saying "broken and incompatible" is not helpfull in oder to
dermine the root cause. There are no problems with the applications in
the devian archive so it must be limited to something "special".

Sebastian

Bug#927147: requestsync: Please port to python3

[Stefano Rivera]

Control: tag 927147 pending

Thanks for the patch. I'm starting a python3 porting branch. And hope to
finish it in a day or two.

https://code.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/+git/ubuntu-dev-tools/+ref/python3

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#939429: RM: tegaki-pygtk -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove tegaki-pygtk. It's dead upstream (last commit from 2014), depends 
on Python 2
and is orphaned since 2016.

Cheers,
Moritz

Bug#939430: RM: tegaki-python -- RoQA; Depends on Python 2, dead upstream

[Moritz Muehlenhoff]

Package: ftp.debian.org
Severity: normal

Please remove tegaki-python. It's dead upstream (last commit from 2014), 
depends on Python 2
and is orphaned since 2016. (Removal bug of tegaki-pygtk needs to be processed 
first).

Cheers,
Moritz

Bug#939428: O: sslh -- Applicative protocol multiplexer

[gui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the sslh package.

The package description is:
 sslh lets one accept HTTPS, SSH, OpenVPN, tinc and XMPP connections on the
 same port. This makes it possible to connect to any of these servers on
 port 443 (e.g. from inside a corporate firewall, which almost never block
 port 443) while still serving HTTPS on that port.
 sslh lets one accept HTTPS, SSH, OpenVPN, tinc and XMPP connections on the
 same port. This makes it possible to connect to any of these servers on
 port 443 (e.g. from inside a corporate firewall, which almost never block
 port 443) while still serving HTTPS on that port.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wEMcPHGd1aUBpcm9x
d2Eub3JnAAoJEJmGUYuaqqClxWQP/imL7Hnz7apHu+axiE6SqWphV8MTJGitlOIL
bArESkkTRU25oeW8zixFR+Au45QuuilxuI5fkKX/7lPC3NAfCDuPMaJi/g0qTBuj
Mh9Z7VJRdE8mh3GxgVFFC1klkvqXQst2xSliQT/bYwDBcenCdUHYJk7ngQ6O37QG
sCEWfM7Ywak0GLiEqkt4Ad/mZUYew2QobyIROqg4q1M5SM9yFOZ5FC6gHB5RmrWb
IBYLdMGh6xTlwUbfr27gZCkNs/qA1iASPhaohXmPnc+qO2lkhh6QSPKnouTQ7NWL
JwfdrIfwy35RWgrizuVx5lrs/m7byYRA1hUoLwKQf5nrx9iBfoqPDH1TDJs4j96Q
NHaEGIKbOyIFnlaqRmB5XcNQj8ALHeJe45snh/RF9cQIg95pBb0kb+pd5TkhV4Az
iDz6sdnb1X86SUPoLwug4o8j67k/q0mpUfCcXDiDslLh680rRXoSb+Gn5QS81+7Z
eSXZ5d3bAKv+zZYNXph9WpCxCw3nnDEgLj8fAxXXxl09ocfpO4siZGS/YnvI8jaR
xgP5bFo3325ishp4z5HvXJ9mcbBLcZ3lMvXWtsfylfGOYlGhXIgpmFFC+FwvIR3i
/BAogxbzSooe72sKEIo/uaHs4YpzTxaj/EQVeXS880+TZu9S3aVmBLAyaFHxG5M8
FjNnBzuk
=VZff
-END PGP SIGNATURE-

Bug#939425: O: memcached -- high-performance memory object caching system

[gui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the memcached package.

The package description is:
 Danga Interactive developed memcached to enhance the speed of LiveJournal.com,
 a site which was already doing 20 million+ dynamic page views per day for 1
 million users with a bunch of webservers and a bunch of database servers.
 memcached dropped the database load to almost nothing, yielding faster page
 load times for users, better resource utilization, and faster access to the
 databases on a memcache miss.
 .
 memcached optimizes specific high-load serving applications that are designed
 to take advantage of its versatile no-locking memory access system. Clients
 are available in several different programming languages, to suit the needs
 of the specific application. Traditionally this has been used in mod_perl
 apps to avoid storing large chunks of data in Apache memory, and to share
 this burden across several machines.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wEEQPHGd1aUBpcm9x
d2Eub3JnAAoJEJmGUYuaqqClWq8P/1IXawKBdizCVjnG84Xqbc3s9Ju1vndaDEyn
oINGyhDIxTe65bH+4cE76krcgn8x5Fmj+8DeQd2y7qfBNSOJlsnPS9PnicDcnazw
bvVBaG09uwYNo3FCj7nWs0Sz5i1/RBhy2ywksVwLzS1cUSXTZX9d7rtO1j+MZFTc
bGBgt1zPeEn5dNgo4HjzLSbLUSB/6yURitxjkloIhL2+jxqm6c881TNjQOdWYhQC
kgmKdNJfhsxoFaq0e8PM1pdiaTozBIFqpiOcyvHhHVqe/BSsVc1r+lYkfcOLlhSf
AiRnvRiOtnxECHB+DYCbJ1HT5SVI+pdcb4Xwn9lYVRmdFB4jkqrfwh2BAkfSqk+P
XIiGH1RxNqS0NcQe13WrjRmkcUSU67N2eqjQF8z7mfQeGV/nBdbQmAUwzXgPAbFs
byZD1hrASkRt64VNL4h+cfvXLFhzVf2l3/2JPuQNxoTNCuH7456fJF81j1Z56QEQ
mkyvSXqr86MsE2/St0zgx9ViLFbpiO/SxWiib/ENW6WUqNs+cMkwgfEJwTO4zmq7
aHMO1zMH/Lmfg3mZhJrouUoEYoQVpsTotYhSAjAQYmNr54cnj/LrRCrDsS/PdApG
2RoA+wNs1sJ5nVLxe/CLjUF23j2XfCu52In/HTKTCnEr7iLYBAREKhIhDPAnwzxv
56uN0O0R
=/4pr
-END PGP SIGNATURE-

Bug#939426: O: qstat -- Command-line tool for querying quake (and other) servers

[gui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the qstat package.

The package description is:
 Qstat provides a simple interface for querying servers for a number
 of games, including but not limited to quake, quakeworld, quake2,
 quake3arena, unreal tournament or half-life.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wEG8PHGd1aUBpcm9x
d2Eub3JnAAoJEJmGUYuaqqCl37kP/0P5l912lNvqjEuQqrBt75G6nzuiAtNZKATN
Ncyu/H/z+AnK/+LRidqy7fYTiX2DkHu4SJgBId+KywpdjTu7bNbDNFLjM4FKQ7kJ
OZpgPnmdfIv/u5+1WvX78Hx2FvRrMGkRiPE5BOfSUVIaqD/NGPw3a2CrCooaTse6
NmgYNdHtz+hWY202yZCU/My5Ns1zzbQIAYoTizqsj1YzUrbrnVK4KwhuhdV9pRE9
mOj6ybpxsnFa9a6SuncH53usg0WvWzXFXeo4GvK1eP/tpfrsXgdz9jNU4zRKNeTd
lfGw7lDwJg4fYHpm82jGA+YHsTvUcC79B9U62XZ0DIIbaKgIbsR+B23CPHg2kEuG
KIuVhPE/DKU0A11VZw9KpIGxgckdAwCHdtN/MecBzdT+DKb0vR1T5Uin/ndDtZoU
+4TS6TxkSHshUMFJKZTqeQ23+3OvYARf5EalM3Aoo2/wb02wpnkbJBz7suspzpuB
3PqIWz6en32bvVfilseWAf7FjUR8TxMfr/J88Q44J9mZoWnVMsn9+gHkTgTclrI3
FJB4Tz/Nq1qRCJb//O7m/4A8OpMbKNPwuwrB/J+NM8ghfDLJEmkpaflm6q8vn0/r
KSxQI8ydX8/7tfwQ+gtQfZfB058ZxQKRZQE2UxBxxTait7f4DJ1VOIujtLi1m04N
6eGv3NAa
=A9O7
-END PGP SIGNATURE-

Bug#939424: O: inspircd -- Modular IRCd written in C++

[gui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the inspircd package.

The package description is:
 InspIRCd is a modular C++ IRC Daemon for several operating systems created
 to provide a stable, modern, lightweight irc server from scratch and provide
 a vast number of features in a modularised form using an advanced module API.
 By keeping the functionality of the main core to a minimum, the server is very
 stable, fast and customizable.
 .
 This package contains the daemon.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wEBYPHGd1aUBpcm9x
d2Eub3JnAAoJEJmGUYuaqqClp0wP/RaxmTPNOiNFsoRTelm0LP+uwjr64S43AM53
OMGmqRYnCgd//OT22bVqJo1ghNKVNu7sDjiSyAtIXvjvevbexzuHAMOUgFamEs03
4faUTqkW3zlh06YqaH8I58kxcfGkg6pOrF0AVt218RGcCt96k1vDKiCBEiqcnlgJ
nEESrOnL9I+rcMtxA6KX9FXj5e5gVDpjKZirMv/TP0d46qR4hLlmxfZ7l/MwsiEz
QjFm50HvEjOVp5j7SvBErtFlyWaNL4FI+FPC4rgN9+8fS3HtVD/eCIMelIS6XBmr
tOvFFWAW6TltoKzJWdeSvjTBZH0gaNpj3SkWdj91ShsXeF/+609yIliQg8EP+1ks
zqy4gq/fMG+pkDju11Wv54A7Q+hmUOHcznhOGEUb9JvgY1N52z5zFLmBCvLdsfzq
P5+WgSiNizH+R/t5JgxDnw1prRjfB3fb4oPM6CZIe2cbPYTCcqtPGcWD/+SDVcUi
Ck0n6nXua/kZnAKVNghXL1zqJZrwKv3pEQK73v30koEMc86CtMMcIfmliNnvAAbR
H0I1lveww8z5p5nJPD0EsK7T5Jl464mONw8MyR0QkQ/FSf7mZKFoeUofgqzxXoCA
SMW/49aBTGeuwr99RA5yUhlI/HiWTOYA6yuCDabPYOesYyT6zLfmPGIKu74751Ux
KNGZ2gC2
=vGIy
-END PGP SIGNATURE-

Bug#939427: O: rsnapshot -- local and remote filesystem snapshot utility

[gui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the rsnapshot package.

The package description is:
 rsnapshot is an rsync-based filesystem snapshot utility. It can take
 incremental backups of local and remote filesystems for any number of
 machines. rsnapshot makes extensive use of hard links, so disk space is
 only used when absolutely necessary.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wEKkPHGd1aUBpcm9x
d2Eub3JnAAoJEJmGUYuaqqCl6FYP/0CfLsmUDBz1VY/DE+YX/zxdUcFyTVl8MKNo
DpYDrZH6zNeC1CZd5m24AOZgR69/1rwTNth66oZihTrvbao6gYB0ZuCItwnI7oZM
qQdT/cNi3qJrIgixo4/hmiOtc3Gk7EpQ419uLpS8sD2QZco1P+UXDnQLoF4LTco4
2DTCigxw9VxN2mWRvhwcOA4JTjaRJofC5d3Luia5GkvaMmK6llHgsAQrMnK8zS8L
iXZ9HL93kFSxd+hDUEvyIWlld/JJHm3P7tmYkkDOFGdJrJH0jIYDVnm1kVIgyTt5
JcCWsMiA9KG0/FeuJcEkpSOnWn8WMe+so6Sdz+yZklywLhaXd+blAYdmdR8q8cEf
NEwFvrBxKTdmMBMSlGkNdG4emeALUcoIbBt8kDBrRSgSh3pWRWshZNdnwFQtczrb
yP2x8GOkG8Ew74R7OFTn4frfoD6WFpg+51sukzAhH5okBbu6m0pVGxEMaR+hWIzU
czQrZpNIfSr1gbB8DxlEOR1+NSEbUA56vYxKN99M0VTzgW/g18hCnL77UsWeMgYy
LXQ2OBo3GjkJ95m4jl9E6Er5Y2CL/QmDNTkaE/750tZO2psBOzkIwVmWFk0bcH+e
T3T/uygsE0BphhUeurTPO6NQWJzmsQqh4uypTRmPKMv6VSAt4jvD7zKxPWYvHmq2
q8ZZjyqU
=5PpI
-END PGP SIGNATURE-

Bug#939423: O: hping3 -- Active Network Smashing Tool

[gui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the hping3 package.

The package description is:
 hping3 is a network tool able to send custom ICMP/UDP/TCP packets and
 to display target replies like ping does with ICMP replies. It handles
 fragmentation and arbitrary packet body and size, and can be used to
 transfer files under supported protocols. Using hping3, you can test
 firewall rules, perform (spoofed) port scanning, test network
 performance using different protocols, do path MTU discovery, perform
 traceroute-like actions under different protocols, fingerprint remote
 operating systems, audit TCP/IP stacks, etc.  hping3 is scriptable
 using the Tcl language.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wD+8PHGd1aUBpcm9x
d2Eub3JnAAoJEJmGUYuaqqClkkwP/i1XQiDS1EnNJj+k2S3zDYnnAmt+hBrlAi4N
FNWg1JxTJElNpBXYQ9Au9pIATgghfNvOm39fe+Iz7cPKS5I5mV1ev92zi9UJVaiP
m+0KVy1SmlJggI5bbbwoRdBi7tu9DWBz0TKeth7djqQZUxdg3h/CesuVG3et7Ffg
PCHEgTSjqPoDdI/vxreYEciKh6mxi/2f1EN5QPSUEB/s4Q7PvoC1KD6wklVDvYAt
FvMdHJl+/MWgQch62/kLsFeUxeUmXcw12D3td5LBZacFKX1fEpuRcxbQXDaCGAbv
gKunWEHFrWW31Br606CiKrf8SYzB17MsqsDXIwBZu2VqdFsuIip+MZJBL4IM3XC0
kAsZDpfHmmT+/2+GSyTWMqEi2QoHR1RRE6Kw77Iyz3n3ch3lEGmIKRKTd9mkduKt
CZaDDN9xvoxqNmwPSFEStQxdZeX1tJnipyo6fNPkzOwrokWtmj2HHNiDEeUT06UW
CpgagxzISXbkB3B7KrQIE9faOtMfbAD48YyGZYgN0usiDt8PLbDGqJMQxcIYyXrW
iIt4OAaMQzoUOcB+KF1/VvVkCr3d7NjeLgOW9sOXtI2KmEUTJ0cygcGFF0/51ujr
QOvZJJPW0VGmA0YB8EPN7f5jvxgLYMwZEpgNt71PePxqSrrMtSnX5kSwx0oU+x4B
nW/jojl7
=rxrA
-END PGP SIGNATURE-

Bug#939422: O: flowscan -- flow-based IP traffic analysis and visualization tool

[gui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the flowscan package.

The package description is:
 FlowScan is a freely-available network traffic analysis and
 visualization tool which uses IP flow data to provide a continuous
 near real-time view of a network's IP traffic.
 .
 FlowScan is a tool to monitor and graph flow information from Cisco
 and Riverstone routers in near real-time. You can also use FlowScan
 with flow information generated by programs like fprobe.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wD7kPHGd1aUBpcm9x
d2Eub3JnAAoJEJmGUYuaqqClqn4P/A0enKEKWOeurDWiXLLRHDvam1kSTAeKnK2a
NPp50BLBEJpI2ntxslC3nOU0xJVLO+3DuHTJZc+kBJxpK33LRDtokGed1cxSDIE1
53D6vxm7cblaKX4o62bM+zjVPhXfwfAD/kt9n7aNyNRNyE4BE3Fzq3sVeb1eLks9
+Qg59IFOsfV88aaizyAadqZZfbRvVOSLy5rheNBmK/ir3r7sA24Wldsd8V/CGKg2
G1e2MsQiWjv8MpC7aNMD82XW6lCSDcvF9kTNLCMKXTwdPHYsMj2OFYjh+jiNbsn1
UxJ3Ix0olrtymb1Sij6RqM8n9kVEOSQNtExfsa2Sbruw2ZaNTKav9AHtOTUY6X6a
D5pqrjkbViB79c3dVzJv4UuK2pIbHZ980CYMSNuOxAuba24LFAaW+XUGi9QpLzE7
nGP87LmaxlXwwSeESuD46ayyKf3OS2BffO5eFXHFSfaRN01FsuNKA6iZe5MG6rsK
Hg5SyD58QdgYuPpgqDxYUAD2itzUQOwL9Pe+ZUKizHQ1HmSsLAije/oyvxhIDaUl
FTKVkcwu4jAzfu1wlU5H9Lz5JAMphLUOUSMkN3K9pSivlsR/z9KoZJvcUUVmy8D0
A8NmAuwB8DrU9BvfLdvsSbfZRpREv9RoIChsKAVXMZnkSQdV7jLbAfHeYwG4M3Ai
WdwgStNO
=e4bu
-END PGP SIGNATURE-

Bug#939421: O: gdisk -- GPT fdisk text-mode partitioning tool

[gui]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I intend to orphan the gdisk package.

The package description is:
 GPT fdisk (aka gdisk) is a text-mode partitioning
 tool that works on Globally Unique Identifier
 (GUID) Partition Table (GPT) disks, rather than
 on the more common (through 2009)
 Master Boot Record (MBR) partition tables.

-BEGIN PGP SIGNATURE-

iQJDBAEBCAAtFiEEiG7UsIsv14Zirt0ImYZRi5qqoKUFAl1wD2sPHGd1aUBpcm9x
d2Eub3JnAAoJEJmGUYuaqqClXFMP/jPrjuqzAv47hV/3rcgbse7xXcvQqV8fcXtW
XyHox/V0IWh3X1YiNrN0e+C5oSKHwzAK4WCkVifmm4srB1SwBf1h177PPnmtm9et
WesDXX07ihr2qQlMRMspopiMt8BnQmdyOvXvfaQig5mInskh7qSwvRnS3sPfXSVM
Jv2OnXUflF0D/y11kRU7ifLoPkYF/BGhGhI78QrwGyta3eVyzvYxnRvvXZI12TsO
IJIoa18sdLBbdl+VuYwM/reN/ovd/cDpYfOVOykv4T+yw4OeBmeh3RSQ5CC0gnoC
B8uc3/qaUyekftIEcsASt3IeZN3z3m/SdTsYZciM/lz6BcwuwLyujRDylLPoD1Td
H7PJu/5m3ceyQZHaIUA4KK8swZRTv2ByJdqvGIiXUwFO0VmbjMUkHxbZoGAyIi0v
MTTZmPjR6815qrmkUvyyuOvaTveFvkg0uSHJRCrzo068rV2AOWdrZKYa9Ng0Fwht
Bu9vU8PqKzz+9HM2krX+U237NFVkrIFFebQYin1xPWPaQ+zGyfBHZj12uatAyIQn
BURLZ23hK6OIk3IV8ZyK/XFps6htIj7MsoN83oPvLlXs+LGweKCm9pL7QOUhZibi
S/SMRkZHedRp8/S0e7+IxpGWbzqBudgeOCgXs4mYhasMeWEKdfCwLRHW6bGS74qR
4NNc1RR9
=wejK
-END PGP SIGNATURE-

Bug#939420: stdx-allocator: FTBFS, test failures.

[Peter Michael Green]

Package: stdx-allocator
Version: 3.0.1-2
Tags: bullseye, sid

stdx-allocator failed to build when binnmu'd for the ldc transition.


dh_auto_test -a
cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test
[0/1] Running all tests.
1/1 stdx-allocator-test FAIL 0.12 s (exit status 1)

Ok:0
Expected Fail: 0
Fail:  1
Unexpected Pass:   0
Skipped:   0
Timeout:   0


The output from the failed tests:

1/1 stdx-allocator-test FAIL 0.12 s (exit status 1)

--- command ---
/<>/obj-x86_64-linux-gnu/stdx-allocator-test
--- stderr ---
core.exception.AssertError@../source/stdx/allocator/gc_allocator.d(161): 
Assertion failure

??:? _d_assert [0x7fd6ea38763c]
gc_allocator.d:161 [0x55b4ecb75f74]
gc_allocator.d:0 [0x55b4ecb75fb5]
??:? int core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*) 
[0x7fd6ea38e13b]
??:? int rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref 
rt.sections_elf_shared.DSO) [0x7fd6ea3bada1]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref 
rt.sections_elf_shared.DSO)) [0x7fd6ea3bc109]
??:? int rt.minfo.moduleinfos_apply(scope int 
delegate(immutable(object.ModuleInfo*))) [0x7fd6ea3bad4b]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) 
[0x7fd6ea3a501e]
??:? runModuleUnitTests [0x7fd6ea38df54]
??:? void rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() [0x7fd6ea3b18ca]
??:? _d_run_main [0x7fd6ea3b1717]
??:? __libc_start_main [0x7fd6ea11e09a]
??:? [0x55b4ecb102b9]
1/22 unittests FAILED
---

Full log written to /<>/obj-x86_64-linux-gnu/meson-logs/testlog.txt

Bug#939048: transition: glibc

[Paul Gevers]

Hi Aurelien,

On 02-09-2019 21:43, Aurelien Jarno wrote:

[...]

>>> - nemo: seems to be a bug in udisks2 postinst script
>>> - pg-repack: debci issue, the regression is caused by libpq5 from
>>>   experimental, which is wrongly selected instead of the unstable
>>>   version.
>>> - repmgr: ditto with libpq-dev.

[...]

>>> There are also a few failures that seems to be related to slight change
>>> of precision of the math functions: pyfai, sextractor.
>>
>> So what do you propose with these? Do they need to fix something? E.g.
>> their autopkgtest? Then we better warn them *now*, i.e. filing bugs.
> 
> For those I still only have look the test logs. I still need to debug
> the issue first and also check if this is a real bug or a false
> positive.

pyfai dropped of the list.

Myon is aware of the postgresql-hll regression:
https://github.com/citusdata/postgresql-hll/issues/67

We'll remove the package from testing when we start the transition.

I'll check why there are so many "Test in progress" items. Most of them
should be neutral I see.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#939419: libparse-pidl-perl: version ordering issue.

[plugwash]

Package: libparse-pidl-perl
Version: 2:4.9.5+dfsg-5+deb10u1+really0.02
X-debbugs-cc: secur...@debian.org

It seems that the recent update to samba in buster-security generated a 
libparse-pidl-perl package with a lower version number than the version 
already in buster. As far as I can tell this has the following consequences.


1. Users will not get the update to this package, (I don't think this is 
a big problem in this particular case as I don't see anything perl 
related in the changelog).
2. I suspect it will stop the security update getting rolled in to the 
next point release.
3. It may mess up downstream infrastructure (that is how I ran into the 
issue).


I see two possible fixes.

1. Avoid using version numbers for the samba package that will trigger 
this issue.
2. Change the logic that generates the version numbers for the 
libparse-pidl-perl package.


I have knocked up some code to implement the second option and I am 
testing it now. If it works out ok i'll post a patch here.

Bug#939415: nmu: cloudcompare_2.10.3-3

[Sebastiaan Couwenberg]

On 9/4/19 8:53 PM, Paul Gevers wrote:
> On 04-09-2019 20:21, Bas Couwenberg wrote:
>> nmu cloudcompare_2.10.3-3 . ANY . unstable . -m "Rebuild with libpdal-dev 
>> 2.0.1"
> 
> Scheduled.

Thanks!

> You'll handle grass and python-pdal yourself?

Yes, both have just been uploaded to unstable as they are also
maintained within the GIS team.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



signature.asc
Description: OpenPGP digital signature

Bug#769607: systemd does not show shutdown or reboot messages with systemd.show_status=true

[Michael Biebl]

On Thu, 27 Nov 2014 14:43:33 -0800 Nikolaus Rath  wrote:
> On Sat, 15 Nov 2014 00:17:59 +0100 Szymon Weihs  wrote:
> > 
> > When I'm doing reboot or shutdown from graphical environment (systemctl
> > reboot/poweroff), my screen turns off immediately so I can't see any 
> > messages
> > provided with option systemd.show_status=true.
> > If I shutdown my computer from console (for example tty1) everything works 
> > as
> > expected - I can see all messages included the last "Reached target 
> > shutdown"
> > and then the screen turns off along with the computer.
> 
> As a workaround, does it help if you add
> 
> ExecStop=/bin/chvt 1
> 
> to the [Service] section of /etc/systemd/system/display-manager.service?
> 

> Hi Nikolaus,
> 
> Your workaround works fine for me, thank you very much :D


Which display manager are you using?
Should we re-assign this bug report accordingly?
With gdm3 this seems to work fine.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#925769: lix: ftbfs with GCC-9

[Andreas Ronnquist]

This one can be closed now, right? See

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931825

(which really looks like the same bug to me - and it has been closed).

best
-- Andreas Rönnquist
gus...@debian.org

Bug#939418: libpfm4 FTCBFS: rebuilds during make install for the wrong architecture

[Helmut Grohne]

Source: libpfm4
Version: 4.10.1+git14-g815ff28-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libpfm4 fails to cross build from source. It actually builds fine for
some architectures. For ppc64el, the archmap entry is missing though.
However during make install it rebuilds from scratch for the build
architecture, because the arch flag is not passed. The attached patch
fixes both and makes libpfm4 cross buildable at least for ppc64el.
Please consider applying the patch.

Helmut
diff --minimal -Nru libpfm4-4.10.1+git14-g815ff28/debian/changelog 
libpfm4-4.10.1+git14-g815ff28/debian/changelog
--- libpfm4-4.10.1+git14-g815ff28/debian/changelog  2019-08-14 
16:04:02.0 +0200
+++ libpfm4-4.10.1+git14-g815ff28/debian/changelog  2019-09-04 
20:36:33.0 +0200
@@ -1,3 +1,12 @@
+libpfm4 (4.10.1+git14-g815ff28-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS for ppc64el: (Closes: #-1)
++ Pass LIBPFM4_ARCH_FLAG to make install to avoid a rebuild.
++ Extecn LIBPFM4_ARCH_ map for ppc64el.
+
+ -- Helmut Grohne   Wed, 04 Sep 2019 20:36:33 +0200
+
 libpfm4 (4.10.1+git14-g815ff28-1) unstable; urgency=medium
 
   * New upstream GIT snapshot.
diff --minimal -Nru libpfm4-4.10.1+git14-g815ff28/debian/rules 
libpfm4-4.10.1+git14-g815ff28/debian/rules
--- libpfm4-4.10.1+git14-g815ff28/debian/rules  2019-08-14 16:04:02.0 
+0200
+++ libpfm4-4.10.1+git14-g815ff28/debian/rules  2019-09-04 20:36:33.0 
+0200
@@ -19,6 +19,7 @@
 LIBPFM4_ARCH_armel  = arm
 LIBPFM4_ARCH_armhf  = arm
 LIBPFM4_ARCH_i386   = i386
+LIBPFM4_ARCH_ppc64el = powerpc
 
 LIBPFM4_ARCH_FLAG   = $(foreach a,$(strip 
$(LIBPFM4_ARCH_$(DEB_HOST_ARCH))),ARCH=$a)
 
@@ -38,7 +39,8 @@
DESTDIR=$(CURDIR)/debian/tmp \
PREFIX=/usr \
LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) \
-   LDCONFIG=true
+   LDCONFIG=true \
+   $(LIBPFM4_ARCH_FLAG)
 
 override_dh_missing:
dh_missing --list-missing

Bug#939389: light-locker: Does not work in buster with xfce4

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: tag -1 unreproducible moreinfo

On Wed, 2019-09-04 at 17:37 +0100, Anton Ivanov wrote:
> No
> 
> These are the XDG environment variables:
> 
> XDG_CONFIG_DIRS=/etc/xdg
> XDG_CURRENT_DESKTOP=XFCE
> XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share
> XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/aivanov
> XDG_MENU_PREFIX=xfce-
> XDG_SEAT=seat0
> XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
> XDG_SESSION_DESKTOP=lightdm-xsession
> XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session14
> XDG_SESSION_TYPE=x11
> XDG_VTNR=7

So there's definitely something fishy, because lightdm should definitely set
XDG_SESSION_ID. Try looking at lightdm logs maybe?
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1wBRcACgkQ3rYcyPpX
RFtcCQgA2LtYtspQrvEDoyvlDTtMeUCs4YhJxwC53WiJcNT7BhXzE2v1Y9tzGWGs
5sDZfQFfKqjgwrL4ofBD/QwGUa5/ZKmPx4IKRDIGiNNNLdmI5tXKYLaWncjOXZc5
5OGHl+wCBt4NP4BpPe0BL1zxME/Oy2KCUO2KnNfPgZ/m5oTJgpmBhYUdGLRqhF0O
EknH73/0+0Umt+Wu9/WxCA3HCxgxla3L/m+lkcXDETGzVjM6fBP945oFynaUnd3E
OQEkpAuCKXHToB1bLyyUK7oaaidaHyOhZ0Drt2QopFcBgXdcbIZclMKmKlJr8/0X
d9Suq/A0ljctx+tz1a2OEn9lBR9biQ==
=+8fp
-END PGP SIGNATURE-

Bug#873615: Fails to detect changes in tarballs that share the same top-level directory

[Carlos Maddela]

On 2/9/19 1:21 am, Axel Beckert wrote:
> 
> So I can't really reproduce this.
> 
> Any idea what I might do different than you? Did you use any
> additional commandline options when you ran into this?

Without the -m option, tardiff only details the changes to the source
tree (i.e. new or removed files and directories), but not changes to
actual source files. So to reproduce the bug in a way that shows it
clearly, you would have to use tarballs that only have changes to source
files and to use the -m option with tardiff. This is what I did:

$ mkdir -p foo-1.0/src
$ echo README > foo-1.0/README
$ echo 1.0 > foo-1.0/VERSION
$ touch foo-1.0/src/main.c
$ tar cvf foo-1.0.tar foo-1.0
foo-1.0/
foo-1.0/README
foo-1.0/VERSION
foo-1.0/src/
foo-1.0/src/main.c
$ cp -a foo-1.0 foo-1.1
$ echo 1.1 > foo-1.1/VERSION
$ tar cvf foo-1.1.tar foo-1.1
foo-1.1/
foo-1.1/README
foo-1.1/VERSION
foo-1.1/src/
foo-1.1/src/main.c
$ tardiff -m foo-1.0.tar foo-1.1.tar
/ VERSION
$ rm *.tar
$ mv foo-1.0 foo
$ tar cvf foo-1.0.tar foo
foo/
foo/README
foo/VERSION
foo/src/
foo/src/main.c
$ rm -rf foo
$ mv foo-1.1 foo
$ tar cvf foo-1.1.tar foo
foo/
foo/README
foo/VERSION
foo/src/
foo/src/main.c
$ tardiff -m foo-1.0.tar foo-1.1.tar
$ exit
exit

In the first case, when the top-level directories are different, it
correctly detects that the VERSION file has changed, whereas when the
top-level directories are the same, it fails to detect the change.
The reason being, the VERSION file from the second tarball will have
clobbered that of the first.

> 
> P.S.: I've hence uploaded a new tardiff package without your patch,
> but once I'm able to reproduce this, I'd include your patch and do
> another upload.

Cheers for that.


Carlos

Bug#939417: lnav FTCBFS: upstream issues

[Helmut Grohne]

Source: lnav
Version: 0.8.5-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lnav fails to cross build from source for multiple reasons. The
immediate failure comes from adding /usr/lib/x86_64-linux-gnu to the
library search path. This is totally wrong and leads gcc to using
incompatible libraries.

The second failure is tring to execute bin2c. It's only used during
building and it is a tool whose behaviour is not dependent on the
architecture it is built on. Thus we should use the build architecture
compiler here. It can be detected using the AX_CC_FOR_BUILD macro from
the autoconf-archive.

Then ptimec fails to run for the same reason as failing to run bin2c.
I'm not sure what ptimec does exactly and whether it can be similarly
compiled using the build architecture compiler. Thus my patch only
solves the former problems. Please consider applying it anyway as a step
towards making lnav cross buildable. Please close this bug when doing
so even though lnav will continue to fail cross building.

Helmut
--- lnav-0.8.5.orig/configure.ac
+++ lnav-0.8.5/configure.ac
@@ -16,20 +16,6 @@
 fi
 done
 
-for defdir in /opt/local /usr/local /usr /; do
-
-if test -d "$defdir/lib64"; then
-LDFLAGS="$LDFLAGS -L$defdir/lib64"
-fi
-if test -d "$defdir/lib"; then
-LDFLAGS="$LDFLAGS -L$defdir/lib"
-fi
-
-if test -d "$defdir/lib/x86_64-linux-gnu"; then
-LDFLAGS="$LDFLAGS -L$defdir/lib/x86_64-linux-gnu"
-fi
-done
-
 dnl abssrcdir is the absolute path to the source base (regardless of where
 dnl you are building it)
 AS_CASE([x$srcdir],
@@ -41,6 +27,7 @@
 AC_SUBST(abssrcdir)
 
 AC_PROG_CXX
+AX_CC_FOR_BUILD
 
 CPPFLAGS="$CPPFLAGS -D_ISOC99_SOURCE -D__STDC_LIMIT_MACROS -D_GNU_SOURCE"
 
--- lnav-0.8.5.orig/src/Makefile.am
+++ lnav-0.8.5/src/Makefile.am
@@ -1,7 +1,7 @@
 
 bin_PROGRAMS = lnav
 
-noinst_PROGRAMS = bin2c ptimec lnav-test
+noinst_PROGRAMS = ptimec lnav-test
 
 noinst_LIBRARIES = libdiag.a
 
@@ -17,26 +17,26 @@
 RE2C_V_ = $(RE2C_V_@AM_DEFAULT_V@)
 RE2C_V_0 = @echo "  RE2C   " $@;
 
-help.c: $(srcdir)/help.txt bin2c
-	$(BIN2C_V)./bin2c -z -c $(srcdir)/help.txt $@
+help.c: $(srcdir)/help.txt bin2c$(EXEEXT_FOR_BUILD)
+	$(BIN2C_V)./bin2c$(EXEEXT_FOR_BUILD) -z -c $(srcdir)/help.txt $@
 
-dump-pid-sh.c: $(srcdir)/dump-pid.sh bin2c
-	$(BIN2C_V)./bin2c -z -c $(srcdir)/dump-pid.sh $@
+dump-pid-sh.c: $(srcdir)/dump-pid.sh bin2c$(EXEEXT_FOR_BUILD)
+	$(BIN2C_V)./bin2c$(EXEEXT_FOR_BUILD) -z -c $(srcdir)/dump-pid.sh $@
 
-default-log-formats-json.c: $(srcdir)/default-log-formats.json bin2c
-	$(BIN2C_V)./bin2c -z -c $(srcdir)/default-log-formats.json $@
+default-log-formats-json.c: $(srcdir)/default-log-formats.json bin2c$(EXEEXT_FOR_BUILD)
+	$(BIN2C_V)./bin2c$(EXEEXT_FOR_BUILD) -z -c $(srcdir)/default-log-formats.json $@
 
-default-config-json.c: $(srcdir)/default-config.json bin2c
-	$(BIN2C_V)./bin2c -z -c $(srcdir)/default-config.json $@
+default-config-json.c: $(srcdir)/default-config.json bin2c$(EXEEXT_FOR_BUILD)
+	$(BIN2C_V)./bin2c$(EXEEXT_FOR_BUILD) -z -c $(srcdir)/default-config.json $@
 
-init-sql.c: bin2c init.sql
-	$(BIN2C_V)./bin2c -z -c $(srcdir)/init.sql $@
+init-sql.c: bin2c$(EXEEXT_FOR_BUILD) init.sql
+	$(BIN2C_V)./bin2c$(EXEEXT_FOR_BUILD) -z -c $(srcdir)/init.sql $@
 
-%.c: $(srcdir)/%.lnav bin2c
-	$(BIN2C_V)./bin2c -z -c $< $@
+%.c: $(srcdir)/%.lnav bin2c$(EXEEXT_FOR_BUILD)
+	$(BIN2C_V)./bin2c$(EXEEXT_FOR_BUILD) -z -c $< $@
 
-%.c: $(srcdir)/%.json bin2c
-	$(BIN2C_V)./bin2c -z -c $< $@
+%.c: $(srcdir)/%.json bin2c$(EXEEXT_FOR_BUILD)
+	$(BIN2C_V)./bin2c$(EXEEXT_FOR_BUILD) -z -c $< $@
 
 TIME_FORMATS = \
 "@%@" \
@@ -401,8 +401,8 @@
 	$(TEXT2C_FILES) \
 	$(LDADD)
 
-bin2c_SOURCES = bin2c.c
-bin2c_LDADD =
+bin2c$(EXEEXT_FOR_BUILD): bin2c.c
+	$(CC_FOR_BUILD) $< -o $@
 
 ptimec_SOURCES = ptimec.cc
 ptimec_LDADD =

Bug#938361: rgain: Python2 removal in sid/bullseye

[Simon McVittie]

On Fri, 30 Aug 2019 at 07:50:19 +, Matthias Klose wrote:
> - If the package is dead upstream

rgain is no longer maintained upstream:
https://bitbucket.org/fk/rgain/issues/26/wanted-new-maintainer

There is a fork at https://github.com/chaudum/rgain that aims to be
python3-compatible; it remains to be seen whether its maintenance will
continue. If it does, I'll switch upstream source to that.

Switching to Python 3 will require a trip through the NEW queue *anyway*,
and the package in unstable is currently identical to the one in buster,
so this package could be removed from unstable until there is a maintained
Python 3 port if necessary. There are no reverse-dependencies.

This package is ostensibly a library, but the main point of it is the
replaygain(1) and collectiongain(1) scripts, which should really be in a
separate binary package to be more discoverable as executables (#780915).

smcv

Bug#939416: lintian: suggest to use libjs-twitter-bootstrap which is only avaialable in unstable

[Carsten Schoenert]

Package: lintian
Version: 2.19.0
Severity: normal

Dear Maintainer,

lintian is suggesting to use the package libjs-twitter-bootstrap in case
it has found bootstrap.js in the source.

Basically a good suggestion but the package libjs-twitter-bootstrap
isn't available in the Buster release and also not within Testing. This
is happen due RC bug report #907724.

Seems the package libjs-bootstrap is a valid successor for this old
suggestion.

[1] https://bugs.debian.org/907724

Regards
Carsten

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

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

Versions of packages lintian depends on:
ii  binutils 2.32.51.20190821-2
ii  bzip21.0.6-9.2
ii  diffstat 1.62-1+b1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.37-5
ii  gettext  0.19.8.1-9
ii  gpg  2.2.17-3
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b1
ii  libarchive-zip-perl  1.64-1
ii  libcapture-tiny-perl 0.48-1
ii  libcgi-pm-perl   4.44-1
ii  libclass-accessor-perl   0.51-1
ii  libclone-perl0.41-1+b1
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.74-1
ii  libipc-run-perl  20180523.0-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b4
ii  libmoo-perl  2.003004-2
ii  libpath-tiny-perl0.108-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3000-2
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.004004-1
ii  liburi-perl  1.76-1
ii  libxml-simple-perl   2.25-1
ii  libyaml-libyaml-perl 0.80+repack-1
ii  man-db   2.8.7-3
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.28.1-6
ii  t1utils  1.41-3
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b5

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libhtml-parser-perl3.72-3+b3
ii  libtext-template-perl  1.55-1

-- no debconf information

Bug#939413: qemu-system: Regression: `-drive file=/dev/fdset/$FD` fails with EPERM

[Guilhem Moulin]

On Wed, 04 Sep 2019 at 19:54:51 +0200, Guilhem Moulin wrote:
>  $ qemu-system-x86_64 -display none \
>  -add-fd "fd=3,set=0" \
>  -drive "file=/dev/fdset/0,format=raw,media=disk" \
>  3<>/tmp/disk.img
>  qemu-system-x86_64: -drive file=/dev/fdset/0,format=raw,media=disk: Could 
> not open '/dev/fdset/0': Permission denied

Unsurprisingly it doesn't work if the file descriptor is read-only

$ qemu-system-x86_64 -display none \
-add-fd "fd=3,set=0" \
-drive "file=/dev/fdset/0,format=raw,media=disk" \
3/tmp/disk.img 4

signature.asc
Description: PGP signature

Bug#939415: nmu: cloudcompare_2.10.3-3

[Bas Couwenberg]

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

Please rebuild cloudcompare with PDAL 2.0.1:

nmu cloudcompare_2.10.3-3 . ANY . unstable . -m "Rebuild with libpdal-dev 2.0.1"

Kind Regards,

Bas

Bug#938642: telepathy-python: Python2 removal in sid/bullseye

[Simon McVittie]

Control: severity -1 serious
Control: affects -1 python-jarabe sugar-browse-activity 
sugar-imageviewer-activity sugar-memorize-activity sugar-pippy-activity 
python-sugar3 tictactoe-ng
Control: block -1 by 938581 938583 938588 938591 938592 938595 938667

On Fri, 30 Aug 2019 at 07:55:23 +, Matthias Klose wrote:
> - If the package is dead upstream, cannot be converted or maintained
>   in Debian, it should be removed from the distribution.

telepathy-python has been dead upstream since 2011[1] (the most recent
release was 2010) and has never supported Python 3. It is currently
still in Debian due to reverse dependencies. I think it should be removed.

[1] https://blogs.gnome.org/danni/2011/11/17/let-us-not-mourn-telepathy-python/

Bug#938836: xapian-bindings: Python2 removal in sid/bullseye

[Olly Betts]

On Wed, Sep 04, 2019 at 11:43:10AM +0200, Matthias Klose wrote:
> > popcon is 15747.
> 
> I think that's too easy.  There is a python3-xapian module which can be used
> by the rdeps.  The py2keep tag isn't meant for "I don't care to investigate"
> issues.

I was merely following the instructions you gave:

| If the package has still many users (popcon >= 300), or is needed to
| build another package which cannot be removed, document that by
| adding the "py2keep" user tag

> So the preference still would be to get the other packages ported or
> removed, if possible.

Sure, happy to drop it once nothing's using it.

Cheers,
Olly

Bug#939414: fp-docs-3.0.4: All fcl docs are missing from binary package

[Peter]

Package: fp-docs-3.0.4
Version: 3.0.4+dfsg-22
Severity: important

Dear Maintainers,

The binary package fp-docs-3.0.4 is missing the entire set of fcl docs.
The problem is well illustrated by the package sizes. Recent versions with 
sizes are ;-

2.6.4  42mB
3.0.0  50mB
3.0.4  13mB


Please also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858797


Regards,
Peter B

Bug#931551: transition: llvm-defaults to 8

[Paul Gevers]

Hi Sylvestre,

On 04-09-2019 19:39, Paul Gevers wrote:
> It's ongoing.

And blocked from migration. Please fix the RC issue *and* upload a
source only package next time.

Paul

Bug#932813: [Workaround] RabbitMQ init scripts are broken

[aab]

Same scenario and same result here.

Looking for a fix, I've found a workaround;
edit /etc/rabbitmq/rabbitmq-env.conf and include this:

NODENAME=rabbit@localhost
NODE_IP_ADDRESS=127.0.0.1
ERL_EPMD_ADDRESS=127.0.0.1

The second option was necessary to install rabbitmq on stretch; in
buster, it seems the third option is needed as epmd only listens on
IPV6. Don't know it the first option is necessary...

-- 

CLAVE PÚBLICA GPG: D48D35DF

Algunos consejos para un uso 
coherente del correo electrónico:

1.- Para proteger la intimidad de tus contactos y evitar el SPAM
(correo no deseado): Borra la dirección del remitente y cualquier otra
dirección que aparezca en el cuerpo del mensaje. Introduce los/las
destinatarias en el apartado CCO (Con Copia Oculta) 2.- Existen otros
programas de mensajería instantánea libres y gratuitos, así que no es
ningún drama que MSN desaparezca o que hagan lo que les dé la gana. 3.-
Nadie regala duros a cuatro pesetas, verdad? Pues por qué se le da
tanto bombo a Sony Ericsson o a quien sea con el rollo de que regalan
ordenadores? A alguien le han dado uno, o cheques de Bill Gates?

CUIDA A TUS CONTACTOS Y DEJA DE HACER PUBLICIDAD A LAS MULTINACIONALES!

¡GRACIAS!


pgpikTAOUPjMh.pgp
Description: Firma digital OpenPGP

Bug#939413: qemu-system: Regression: `-drive file=/dev/fdset/$FD` fails with EPERM

[Guilhem Moulin]

Package: qemu-system-x86
Version: 1:4.1-1
Severity: normal
File: qemu-system

Dear Maintainer,

Using a pre-opened file descriptor to a disk image no longer work as
documented (and as it used to with ≤1:3.1+dfsg-8~deb10u1):

$ touch /tmp/disk.img
$ qemu-system-x86_64 -display none \
-add-fd "fd=3,set=0" \
-drive "file=/dev/fdset/0,format=raw,media=disk" \
3<>/tmp/disk.img
qemu-system-x86_64: -drive file=/dev/fdset/0,format=raw,media=disk: Could 
not open '/dev/fdset/0': Permission denied

Interestingly, for read-only media it does work if the file descriptor
is opened in read-only mode:

$ qemu-system-x86_64 -display none \
-add-fd "fd=3,set=0" \
-drive "file=/dev/fdset/0,format=raw,media=cdrom,readonly" \
3
ii  qemu-system-gui  1:4.1-1
pn  qemu-utils   

Versions of packages qemu-system-x86 suggests:
pn  qemu-block-extra  
pn  samba 
pn  sgabios   
pn  vde2  

-- no debconf information


signature.asc
Description: PGP signature

Bug#939412: please update build-depends to easy backporting

[Daniel Baumann]

Package: firefox
Version 69.0-1
Severity: wishlist

Hi,

thank you for uploading firefox 69.0-1.

The new version requires a few version bumps in build-depends to build
on buster (doing local backports):

  - cbindgen (>= 0.9.0
  - cargo (>= 0.37)
  - rustc (>= 1.35)

It would be nice if you could bump them in one of the next uploads in
order to ease backporting.

Regards,
Daniel

Bug#939395: [Debian-ha-maintainers] Bug#939395: ocfs2-tools - FS can't mount at boot on drbd device

[Valentin Vidić]

On Wed, Sep 04, 2019 at 03:28:51PM +0200, Ervin Hegedüs wrote:
> Status of services after reboot:
> 
> # systemctl status drbd.mount
> ● drbd.mount - /drbd
>Loaded: loaded (/etc/fstab; generated)
>Active: failed (Result: exit-code) since Wed 2019-09-04 15:13:49 CEST; 16s 
> ago
> Where: /drbd
>  What: /dev/drbd0
>  Docs: man:fstab(5)
>man:systemd-fstab-generator(8)
> 
> Sep t 04 15:13:49 t2app1 systemd[1]: Mounting /drbd...
> Sep t 04 15:13:49 t2app1 mount[720]: mount.ocfs2: I/O error on channel while 
> opening device /dev/drbd0
> Sep t 04 15:13:49 t2app1 systemd[1]: drbd.mount: Mount process exited, 
> code=exited, status=1/FAILURE
> Sep t 04 15:13:49 t2app1 systemd[1]: drbd.mount: Failed with result 
> 'exit-code'.
> Sep t 04 15:13:49 t2app1 systemd[1]: Failed to mount /drbd.

You might want to try configuring systemd to start the
services sequentially (Requires+After):

1. drbd.service
2. o2cb.service
3. ocfs2.service or drbd.mount (they both try to mount).

-- 
Valentin

Bug#936229: bootstrap-vz: Python2 removal in sid/bullseye

[plugwash]

severity 936229 serious
thanks

bootstrap-vz depends on the python-fysom binary package which has 
already been dropped by the python-fysom source package.

Bug#931551: transition: llvm-defaults to 8

[Paul Gevers]

Control: tag -1 pending

On 18-08-2019 18:54, Jonathan Wiltshire wrote:
> Control: tag -1 confirmed
> 
> On Sun, Jul 07, 2019 at 04:29:31PM +0200, Sylvestre Ledru wrote:
>> Now that we release buster, I would like to move llvm-defaults to 
>> llvm-toolchain-8.
> 
> Ok, let's go!

It's ongoing.

Paul

Bug#939411: amanda: merged /usr and tar path problem in /etc/amanda-security.conf

[Charles Curley]

Package: amanda-client
Version: 1:3.5.1-2+b2
Severity: normal
File: amanda

Dear Maintainer,

   * What led up to the situation?

 Installing amanda clients on a) Debian 10 (buster) systems
 upgraded from Debian 9 (stretch), and b) installing Debian 10
 fresh.

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

 Installed amanda clients, and ran amcheck as usual as a test.

   * What was the outcome of this action?

 Error messages such as:

 picnc / lev 0  FAILED ["security file '/etc/amanda-security.conf' do not 
allow to run '/usr/bin/tar' as root for 'amgtar:gnutar_path'"]

   * What outcome did you expect instead?

 I expected amcheck to run successfully.

This bug report follows a discussion on the amanda hackers list, starting at 
https://marc.info/?l=amanda-hackers=156742521310310=2

The short of it is that Gene Heskett and I (and likely others) had encountered 
a misconfiguration in /etc/amanda-security.conf where Debian 10 had been 
freshly installed, but not where it had been upgraded from Debian 9. This is 
because a fresh install does a merger of /usr and some of its sub-directories. 
For more information on that, see 
https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#merged-usr

So we recommend shipping /etc/amanda-security.conf with two lines for 
runtar:gnutar_path, as follows:

runtar:gnutar_path=/usr/bin/tar
runtar:gnutar_path=/bin/tar

This appears to cover both installations, and should be fairly harmless.

For the testing I did with various permutations, see 
https://marc.info/?l=amanda-hackers=156754855611097=2

I did not test any of the other possible versions of tar (amgtar:gnutar_path, 
etc.).

Thanks to Nathan Stratton Treadway  for his detective work 
on this.


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

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

Versions of packages amanda-client depends on:
ii  amanda-common   1:3.5.1-2+b2
ii  libc6   2.28-10
ii  libcurl47.64.0-4
ii  libglib2.0-02.58.3-2
ii  libreadline77.0-5
ii  libssl1.1   1.1.1c-1
ii  libxml-simple-perl  2.25-1
ii  perl5.28.1-6

amanda-client recommends no packages.

Versions of packages amanda-client suggests:
pn  dump   
pn  gnuplot
ii  smbclient  2:4.9.5+dfsg-5+deb10u1

-- Configuration Files:
/etc/amanda-security.conf changed [not included]

-- no debconf information

Bug#927414: now shipped in edk2 source

[dann frazier]

fyi, we are now distributing qemu-ovmf-secureboot as a supplementary
orig tarball for edk2 so that we can use it to build secureboot ovmf
images. It is still not provided in a binary package though.

  -dann

Bug#934231: anacron: please provide a runscript for runit

[Lorenzo Puliti]

Package: anacron
Version: 2.3-29
Followup-For: Bug #934231

Hi,
I have updated the patches and the MR:
First patch adds Gtilab CI test and include a test for the runscript

https://salsa.debian.org/Lorenzo.ru.g-guest/anacron/pipelines/69420

The second one, compared to the previuos version, adds the following:
 * bump dh-runit version to 2.8.14 in Build-depends
 * add presubj option for dh-runit
 * slightly reword the echo messages in run and finish files

Thanks,
Lorenzo


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

Kernel: Linux 4.20.3-van (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)

Versions of packages anacron depends on:
ii  debianutils  4.8.6.3
ii  libc62.28-10
ii  lsb-base 11.1.0

Versions of packages anacron recommends:
ii  cron [cron-daemon]  3.0pl1-134

Versions of packages anacron suggests:
ii  postfix [mail-transport-agent]  3.4.5-1+b1
ii  powermgmt-base  1.36
ii  socklog [system-log-daemon] 2.1.0+repack-1

-- no debconf information
>From 7b21cdaa7e71ccb4ebe684a333a090f7e82369a1 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Wed, 4 Sep 2019 18:30:06 +0200
Subject: [PATCH 1/2] Add gitlab CI

---
 debian/.gitlab-ci.yml | 6 ++
 1 file changed, 6 insertions(+)
 create mode 100644 debian/.gitlab-ci.yml

diff --git a/debian/.gitlab-ci.yml b/debian/.gitlab-ci.yml
new file mode 100644
index 000..8ca3a45
--- /dev/null
+++ b/debian/.gitlab-ci.yml
@@ -0,0 +1,6 @@
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
+  - https://salsa.debian.org/kaction/daemons/raw/master/pipeline.yml
+variables:
+  RELEASE: unstable 
-- 
2.23.0

>From 0969d723daa71cd8d2cb26e44edebe27c4306c9f Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Thu, 8 Aug 2019 13:36:43 +0200
Subject: [PATCH 2/2] Add a runscript for runit

Add a runscript for runit; rely on dh-runit for
maintscripts code.
---
 debian/anacron.runit|  1 +
 debian/anacron.runscript/finish | 11 +++
 debian/anacron.runscript/run| 21 +
 debian/control  |  2 ++
 debian/rules|  2 +-
 5 files changed, 36 insertions(+), 1 deletion(-)
 create mode 100644 debian/anacron.runit
 create mode 100644 debian/anacron.runscript/finish
 create mode 100644 debian/anacron.runscript/run

diff --git a/debian/anacron.runit b/debian/anacron.runit
new file mode 100644
index 000..b41198a
--- /dev/null
+++ b/debian/anacron.runit
@@ -0,0 +1 @@
+debian/anacron.runscript logscript,name=anacron,since=2.3-30,presubj
diff --git a/debian/anacron.runscript/finish b/debian/anacron.runscript/finish
new file mode 100644
index 000..45a5ef2
--- /dev/null
+++ b/debian/anacron.runscript/finish
@@ -0,0 +1,11 @@
+#!/bin/sh
+set -e
+
+NAME=Anacron
+
+[ $1 = -1 ] && echo "runsv: ERROR in $NAME: unexpected error or wrong sh 
syntax"
+
+[ $1 = 161 ] && echo "runsv: ERROR $1 in $NAME: disabled by local settings" \
+ && sv d $(dirname $0) && exit 0
+
+echo "runsv: $NAME stopped " 
diff --git a/debian/anacron.runscript/run b/debian/anacron.runscript/run
new file mode 100644
index 000..dcfb16d
--- /dev/null
+++ b/debian/anacron.runscript/run
@@ -0,0 +1,21 @@
+#!/usr/bin/env /lib/runit/invoke-run
+set -e
+
+NAME=Anacron
+
+exec 2>&1
+
+# exit status of on_ac_power:
+# 0= on-ac // 1= on-battery // 255=unknown, likely a desktop witout APM
+if [ x"$ANACRON_RUN_ON_BATTERY_POWER" != x"yes" -a -x /usr/bin/on_ac_power ]; 
then
+/usr/bin/on_ac_power || retval=$? 
+if [ x"$retval" = x1 ]; then
+echo "deferred while on battery power" && exit 161
+fi
+fi
+
+# don't restart anacron when it's done
+sv once anacron
+
+echo "runsv: starting $NAME..."
+exec /usr/sbin/anacron -d $ANACRON_ARGS
diff --git a/debian/control b/debian/control
index 9a38b23..fc5e3ed 100644
--- a/debian/control
+++ b/debian/control
@@ -3,6 +3,7 @@ Section: admin
 Priority: optional
 Build-Depends:
  debhelper-compat (= 12),
+ dh-runit(>=2.8.14),
 Maintainer: Debian QA Group 
 Standards-Version: 4.2.1
 Rules-Requires-Root: no
@@ -12,6 +13,7 @@ Vcs-Browser: https://salsa.debian.org/debian/anacron
 
 Package: anacron
 Architecture: any
+Breaks: ${runit:Breaks}
 Depends:
  debianutils (>= 1.7),
  lsb-base (>= 3.0-10),
diff --git a/debian/rules b/debian/rules
index 93acac4..5b251e6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,7 +20,7 @@ else
 endif
 
 %:
-   dh $@
+   dh $@ --with runit
 
 override_dh_auto_install:
$(MAKE) install PREFIX=debian/anacron 
MANDIR=debian/anacron/usr/share/man
-- 
2.23.0

Bug#939410: ITP: qosmic -- GUI for creating & rendering flam3 images

[Peter]

Package: wnpp
Severity: wishlist
Owner: P Blackman 

* Package name: qosmic
  Version : 1.6.0
  Upstream Author : David Bitseff 
* URL : https://github.com/bitsed/qosmic/releases
* License : GPL-3.0+
  Programming Lang: C++, QT

  Description : GUI for creating & rendering flam3 images
 Graphical interface (QT5) for creating, editing, and rendering
 flam3 IFS fractal flame images. Images can be saved as png files.
 The theory of fractal flames is described here;-
 https://flam3.com/flame_draves.pdf
 https://github.com/bitsed/qosmic/wiki

My initial packaging effort can be found here;-
https://launchpad.net/~ueter/+archive/ubuntu/qosmic/+packages

The description for the flam3 package says;-

"You can create your own flames with the Apophysis interactive designer (for
windows), Qosmic (for Linux), or Oxidizer (for Mac OS X), or Apophysis-J
(cross-platform in Java)."

So it would be good to have an official package for qosmic too.

This package will need a sponsor.

Bug#920978: audacious: It would be great is the qt5 ui from audacios was also put into the deb package

[Mikhail "L117" Nikolenko]

Followup-For: Bug #920978
Package: audacious
Version: 3.10.1-1

Dear Maintainer,

I'm also very interested in Qt5 UI. There's a bug #820472, where someone 
argued that
"GTK player should not depend on Qt stuff". But in fact, audacious is 
*"multifrontend"*

player nowadays, and Qt UI is superior in some aspects. E.g. it has better,
more natural search bar, that filters out entries that do not match, 
leaving only those
that do, making it more keyboard-friendly; It also has window docking 
capabilities, so
I don't have to waste time unminimizing and realigning 
AlbumArt/LyricWiki windows as they
are tied to a player window. Not to say it just looks prettier on 
KDE-based desktops.
So I think a few more qt dependencies is not a big price to make both 
GTK/Qt users happy,
considering persistent storage capacities we have nowadays. And it 
should not require

much effort to enable it, as this was already done in `stretch` release.

Regards, Mikhail.

P.S. I had some issues with `reportbug` so this email is sent via 
thunderbird instead.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages audacious depends on:
ii  audacious-plugins 3.10.1-1
ii  dbus  1.12.16-1
ii  dbus-user-session [default-dbus-session-bus]  1.12.16-1
ii  gtk2-engines-pixbuf   2.24.32-3
ii  libaudcore5   3.10.1-1
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-6
ii  libglib2.0-0  2.58.3-2
ii  libstdc++6    8.3.0-6

Versions of packages audacious recommends:
ii  unzip  6.0-23

audacious suggests no packages.

-- no debconf information

Bug#939409: gunicorn: dropping gunicorn3 package and binary breaks reverse dependencies

[Antonio Terceiro]

Source: gunicorn
Version: 19.9.0-1
Severity: normal
Affects: lava-server
Control: affects -1 + lava-server isso graphite-api pywps

Hi,

Dropping gunicorn3 breaks lava-server without notice. According to
codesearch, at least 3 other packages mention gunicorn3: isso,
graphite-api, pywps.

Maybe dropping the binary package is ok, and gunicorn could provide a
gunicorn3 compat sysmlink? Changing dependencies in Debian is easier
than changing upstream code that is calling gunicorn3. Replaces: should
also help.

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

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


signature.asc
Description: PGP signature

Bug#939407: gtk-3-examples: Paste from closed GTK3 applications is broken under Wayland (clipboard vanishes on exit)

[Conrad J.C. Hughes (for Debian package stuff)]

Package: gtk-3-examples
Version: 3.24.5-1
Severity: normal

Dear Maintainer,

This has been reported upstream, but since no fix has been forthcoming in
*three years*, there's no due date, and the issue "needs design", it would be
interesting to know whether Debian has a workaround: this seems like a major
usability fail.

  https://gitlab.gnome.org/GNOME/gtk/issues/587

If I copy some data from a GTK3 application and then close the app, the
clipboard is cleared.  This is unexpected: usual behaviour is for copied data
to survive application closure.  To reproduce:

- Open gtk3-demo, expand the "Entry" section and double-click on "Entry
Buffer".
- This will open a text field; type in some text and and press control-C to
copy it.
- Select a text field in another window and press control-V: the copied text is
pasted/inserted, as expected.
- Close gtk3-demo.
- Select a text field in another window and press control-V: nothing appears.
The clipboard is empty (or perhaps never existed).

Expected behaviour would be that the second attempt to paste would work exactly
the same as the first.



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

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

Versions of packages gtk-3-examples depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo-gobject21.16.0-4
ii  libcairo21.16.0-4
ii  libepoxy01.5.3-0.1
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  libwayland-client0   1.16.0-1
ii  libwayland-cursor0   1.16.0-1
ii  libwayland-egl1  1.16.0-1
ii  libx11-6 2:1.6.7-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxinerama1 2:1.1.4-2
ii  libxkbcommon00.8.2-1
ii  libxrandr2   2:1.5.1-1

gtk-3-examples recommends no packages.

gtk-3-examples suggests no packages.

-- no debconf information

Bug#939408: systemd in buster broken with RootDirectory and User

[Michael Biebl]

Package: systemd
Version: 241-5
Submitter: s.pri...@profihost.ag
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: buster-backport

Am 04.09.19 um 14:09 schrieb Stefan Priebe - Profihost AG:
> Hello,
> 
> currently systemd is broken in buster regarding RootDirectory and User.
> 
> The issue was fixed in systemd 243 and the relevant commits are
> referenced in the specific bug report:
> https://github.com/systemd/systemd/issues/12498
> 
> Any chance to get this fixed soon? This broke a lot of our services from
> stretch.


Let's turn this into a bug report so it can be tracked properly.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#939389: light-locker: Does not work in buster with xfce4

[Anton Ivanov]

On 04/09/2019 17:18, Yves-Alexis Perez wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2019-09-04 at 12:47 +0100, Anton Ivanov wrote:

I do not.

It is mounted normally and light-locker worked fine before the upgrade
to buster.

In your session, is XDG_SESSION_ID set (and to what)?


No

These are the XDG environment variables:

XDG_CONFIG_DIRS=/etc/xdg
XDG_CURRENT_DESKTOP=XFCE
XDG_DATA_DIRS=/usr/share/xfce4:/usr/local/share/:/usr/share/:/usr/share
XDG_GREETER_DATA_DIR=/var/lib/lightdm/data/aivanov
XDG_MENU_PREFIX=xfce-
XDG_SEAT=seat0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
XDG_SESSION_DESKTOP=lightdm-xsession
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session14
XDG_SESSION_TYPE=x11
XDG_VTNR=7


Could you give us the
debug output?


light-locker --debug

** (light-locker:8185): ERROR **: 17:36:51.025: session_id is not set, 
is /proc mounted with hidepid>0?

Trace/breakpoint trap




Regards,
- -- 
Yves-Alexis

-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1v48IACgkQ3rYcyPpX
RFvXUggA4qG3JbgGWPtSu61824ScLXDk+zuX1xuvS5LSP59xxVMbU1uv7AsC6qt5
X6kZbH4EcFJoIsubf3clGCo6x012x1nQIHgXvfOV7KKuJq0Kf3LTLhdDvjg/El7l
wo8XlPcsl/ULXlWs693VzgcMiCnWYAows1m+4phKEg4eAeagHKTOx5UwttMTmUGi
dSEmTEjY7Jtmn0escL1oN52A0x99y3Unfy+hT6NxMYoF1Xr2OCSlmYTFXkOuyg8w
U4G6onJXV+PN9iR8nOL+QRA75P5ogoooq+XFkPWivmb4b/LqAIFP77nFmxigT7kT
ZoqXejAlWTwK9aQun8oztyYs6mpfDw==
=627D
-END PGP SIGNATURE-



--
Anton R. Ivanov
https://www.kot-begemot.co.uk/

Bug#939406: UNGOOGLED-CHROMIUM EVENT CHROMIUM

[PICCORO McKAY Lenz]

Source: chromium-browser
Severity: important
Tags: patch

I REVISED THE CHROMIUM AND CHROME AND SEEMS DOES NTO RESPECT THE
FREEDOM OF THE USERS IN ANY CHANCE AFTER A REVIEW OVER THE UNGOOGLED
CHROMIUM PROJECT..

https://github.com/ungoogled-software/ungoogled-chromium-debian

As LXDE does in the past and today.. it's better that upstream work
hand to hand with the debian itselft..

that's reduced the problems of updating things.. in chromium that are
a very oftyen updated package...

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

Bug#939405: ITP: waypipe -- Proxy wayland clients over a single socket

[Birger Schacht]

Package: wnpp
Severity: wishlist
Owner: Birger Schacht 

* Package name: waypipe
  Version : 0.6.1
  Upstream Author : Manuel Stoeckl
* URL : https://mstoeckl.com/notes/gsoc/blog.html
* License : MIT
  Programming Lang: C
  Description : Proxy wayland clients over a single socket

waypipe is a proxy for Wayland clients. It forwards Wayland messages
and serializes changes to shared memory buffers over a single socket.
This makes application forwarding similar to ssh -X feasible.
Upstream considers the software to be unstable right now- I will
package waypipe for experimental for now.

Bug#939389: light-locker: Does not work in buster with xfce4

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Wed, 2019-09-04 at 12:47 +0100, Anton Ivanov wrote:
> I do not.
> 
> It is mounted normally and light-locker worked fine before the upgrade 
> to buster.

In your session, is XDG_SESSION_ID set (and to what)? Could you give us the
debug output?

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl1v48IACgkQ3rYcyPpX
RFvXUggA4qG3JbgGWPtSu61824ScLXDk+zuX1xuvS5LSP59xxVMbU1uv7AsC6qt5
X6kZbH4EcFJoIsubf3clGCo6x012x1nQIHgXvfOV7KKuJq0Kf3LTLhdDvjg/El7l
wo8XlPcsl/ULXlWs693VzgcMiCnWYAows1m+4phKEg4eAeagHKTOx5UwttMTmUGi
dSEmTEjY7Jtmn0escL1oN52A0x99y3Unfy+hT6NxMYoF1Xr2OCSlmYTFXkOuyg8w
U4G6onJXV+PN9iR8nOL+QRA75P5ogoooq+XFkPWivmb4b/LqAIFP77nFmxigT7kT
ZoqXejAlWTwK9aQun8oztyYs6mpfDw==
=627D
-END PGP SIGNATURE-

Bug#939404: ldc ftbfs, missing b-d gdmd

[Matthias Klumpp]

Am Mi., 4. Sept. 2019 um 18:05 Uhr schrieb Matthias Klose :
>
> On 04.09.19 18:01, Matthias Klumpp wrote:
> > Am Mi., 4. Sept. 2019 um 18:00 Uhr schrieb Matthias Klose :
> >>
> >> Package: src:ldc
> >> Version: 1:1.17.0-1
> >> Severity: serious
> >> Tags: sid bullseye
> >>
> >> looks like gdmd isn't available, and according to the changelog gdc should 
> >> be
> >> used for the bootstrap?
> >
> > Man you're quick ^^
>
> sorry ;)
>
> > gdmd is currently stuck in NEW, I hope it gets accepted quickly:
> > https://ftp-master.debian.org/new/gdmd_2.068.2%2Bgit190828-1.html
>
> could you provide that package to download for me? like people.debian.org?

I can when I'm home and have my ssh keys, but meanwhile you could just
fetch the package's source from
https://salsa.debian.org/d-team/gdmd and uild it yourself.
The package basically only contains a simple Perl script to translate
`dmd` flags to `gdc` flags (would be nice if upstream project would
speak GDC commands natively, but sadly not all do, and LDC upstream
does want to support being compiled with itself and the original DMD
as well).

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/

Bug#939401: nvidia-driver: Xorg crashing in an endless loop after upgrade to version 430

[Niklas]

The 435 driver seems to work perfectly fine. Thank you very much!