Bug#712953: sysvinit: System Restarts Instead of Powering Off

[Alan Chandler]

On 09/03/2019 2:41 am, Ben Hutchings wrote:

Control: tag -1 moreinfo

On Fri, 21 Jun 2013 09:13:19 +0100 "Alan Chandler" <
a...@chandlerfamily.org.uk> wrote:

Package: sysvinit
Version: 2.88dsf-41
Severity: normal

Dear Maintainer,

When I attempt to power off the machine (either logging out of gnome3, or via 
shutdown now typed in at a terminal)
the system goes through the shutdown sequence (it does seem to pause after 
telling all processes to terminate and
then reports that some processes are still running). It finally reports it is 
about to power off.

But the computer then restarts and reboots.

If I load up Debian Wheezy and shut that down, the computer powers off properly.

Sorry this report took so long to get assigned properly.  Is this still
happening in a current Debian version?

Ben.
  


This was 6 years ago.  I don't have the problem now.

--
Alan Chandler
http://www.chandlerfamily.org.uk

Bug#921607: mupdf shell script [correction]

[Mike]

the patch should be:

 $cmd || true
else
-$cmd "$file" || true
+$cmd "$file" $2
fi

There is a start page param after the file:

usage: /usr/lib/mupdf/mupdf-x11 [options] file.pdf [page]


- the proposed 'exec' leaves a tmp-file in /tmp !

(- I see no reason for the 'true'?)

Bug#924010: wmbiff: Built without TLS support

[Yavor Doganov]

On Fri, Mar 08, 2019 at 07:21:22PM +0100, Andreas Metzler wrote:
> On 2019-03-08 Yavor Doganov  wrote:
> > | checking for gzopen in -lz... no
> > | GNUTLS support requires libz.a and libgdbm.a
> 
> Actually ./configure seems to wrong, GNUTLS suppport does not require
> libz.a and libgdbm.a (anymore).

Thanks; here is a better patch.
>From da55170615c095d2076a839d335f1071ceb8f906 Mon Sep 17 00:00:00 2001
From: Yavor Doganov 
Date: Sat, 9 Mar 2019 08:30:55 +0200
Subject: [PATCH] debian/patches: (gnutls-detection.patch) Detect GNUTLS
 unconditionally.

---
 debian/patches/gnutls-detection.patch | 40 +++
 debian/patches/series |  1 +
 2 files changed, 41 insertions(+)
 create mode 100644 debian/patches/gnutls-detection.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/gnutls-detection.patch b/debian/patches/gnutls-detection.patch
new file mode 100644
index 000..acb58bb
--- /dev/null
+++ b/debian/patches/gnutls-detection.patch
@@ -0,0 +1,40 @@
+Description: Detect GNUTLS unconditionally.
+Author: Yavor Doganov 
+Debian-Bug: https://bugs.debian.org/924010
+Forwarded: no
+Last-Update: 2019-03-09
+---
+
+--- wmbiff.orig/configure.ac
 wmbiff/configure.ac
+@@ -58,11 +58,7 @@
+ AC_CHECK_LIB(resolv, herror)
+ 
+ dnl Pre-gnutls.
+-gnutls="ok"
+ gcrypt="ok"
+-AC_CHECK_LIB(z, gzopen, [], [gnutls="nope"]) dnl GNUTLS seems to need libz; fail here if it's missing.
+-dnl perhaps not required anymore:
+-dnl AC_CHECK_LIB(gdbm, dbminit, [], [gnutls="nope"]) dnl GNUTLS seems to need libgdbm; fail here if it's missing.
+ 
+ dnl Parameter is minimum version
+ dnl TODO: fix so that GCRYPT is tested only if GNUTLS fails; the dependence
+@@ -76,17 +72,13 @@
+ 
+ 
+ GNUTLS_MAN_STATUS="This copy of WMBiff was not compiled with GNUTLS."
+-if test "$gnutls" = "ok"; then
+- PKG_CHECK_MODULES([LIBGNUTLS], [gnutls > 2.2.0], [LIBS="$LIBS $LIBGNUTLS_LIBS"
++PKG_CHECK_MODULES([LIBGNUTLS], [gnutls > 2.2.0], [LIBS="$LIBS $LIBGNUTLS_LIBS"
+   CFLAGS="$CFLAGS $LIBGNUTLS_CFLAGS"
+  CPPFLAGS="$CPPFLAGS $LIBGNUTLS_CFLAGS"
+  GNUTLS_COMMON_O="gnutls-common.o"
+  GNUTLS_MAN_STATUS="This copy of WMBiff was compiled with GNUTLS."
+  AC_CHECK_HEADERS(gnutls/gnutls.h) ],
+  [ echo GNUTLS can be found at ftp://gnutls.hellug.gr/pub/gnutls ])
+-else
+- AC_MSG_RESULT(GNUTLS support requires libz.a and libgdbm.a, so will be disabled)
+-fi
+ 
+ GCRYPT_MAN_STATUS="This copy of WMBiff was not compiled with gcrypt."
+ if test "$gcrypt" = "ok"; then
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..99fe75a
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+gnutls-detection.patch
-- 
2.20.1

Bug#824729: task-bulgarian-desktop: please recommend hunspell-bg as (preferred?) alternative to myspell-bg

[Holger Wansing]

Control: tags -1 + pending


Jonas Smedegaard  wrote:
> task-bulgarian-desktop recommends myspell-bg but not hunspell-bg.
> 
> Please recommend hunspell-bg as alternative to myspell-bg.
> 
> As I understand it, hunspell has features not in myspell (e.g. related
> to combining words which is very common in danish).  If there are no
> particular reason to favor myspell-bg (e.g. bigger wordlist) then
> hunspell-bg should probably be listed first.

I have committed this.

myspell-bg is just a transitional package to hunspell-bg these days, anyway.



Tagging this bug as pending

Thanks
Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#885178: closed by Georges Khaznadar (this bug is closed in revision 1.3-1)

[Graham Inggs]

Hi Jonas

On Fri, 11 Jan 2019 at 23:48, Jonas Smedegaard  wrote:
> python-sympy 1.3-1 still depend on ipython, where this bugreport states
> that it should instead declare that it enhances ipython.

Are you able to provide a patch?

I will do a team upload and file an unblock request if Georges is unavailable.

Regards
Graham

Bug#923975: task files should not recommend removed packages

[Holger Wansing]

Control: tags -1 + pending

Wolfgang Schweer  wrote:
> 
> while working at Debian Edu installation media I noticed that various
> tasks are recommending packages that are not (or no longer) available:
> 
> task-catalan-desktop:myspell-ca (see also: #910615)
> task-chinese-s:  fortune-zh
> task-finnish-desktop:xul-ext-mozvoikko
> task-french: doc-linux-fr-text, doc-debian-fr
> task-greek-desktop:  fonts-mgopen (see also: #823150)
> task-gujarati-kde-desktop:   kde-l10n-gu
> task-hungarian-desktop:  libreoffice-thesausus-hu
> task-italian-desktop:myspell-it
> task-kannada-kde-desktop:kde-l10n-kn
> task-kurdish-desktop:libreoffice-l10n-ku, myspell-ku
> task-lithuanian-desktop: myspell-lt
> task-macedonian-kde-desktop: kde-l10n-mk
> task-malayalam-kde-desktop:  kde-l10n-ml
> task-polish: doc-linux-pl, doc-linux-pl-html
> task-sinhala-kde-desktop:kde-l10n-si
> task-slovenian-desktop:  myspell-sl
> task-spanish:doc-debian-es
> task-thai-desktop:   myspell-th
> task-thai-kde-desktop:   kde-l10n-th
> task-ukrainian:  doc-debian-uk
> task-vietnamese-kde-desktop: kde-l10n-vi
> 
> Also, while at it: some inconsistency?
> 
> --- a/debian-tasks.desc   2019-03-07 19:20:48.179994586 +0100
> +++ b/debian-tasks.desc   2019-03-07 19:28:48.227824535 +0100
> @@ -1278,7 +1278,7 @@
>  Enhances: kde-desktop, ukrainian-desktop
>  Section: l10n
>  
> -Task: sinhala-desktop
> +Task: uyghur-desktop
>  Key: 
>task-uyghur-desktop
>  Enhances: desktop

All fixed in git.
Thanks Wolfgang

Tagging this bug as pending


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#924068: unblock: hydroffice.bag/0.2.15-2

[Andreas Tille]

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

Please unblock package hydroffice.bag


diff -Nru hydroffice.bag-0.2.15/debian/changelog 
hydroffice.bag-0.2.15/debian/changelog
--- hydroffice.bag-0.2.15/debian/changelog  2016-09-09 10:17:11.0 
+0200
+++ hydroffice.bag-0.2.15/debian/changelog  2019-03-09 06:59:59.0 
+0100
@@ -1,3 +1,12 @@
+hydroffice.bag (0.2.15-2) unstable; urgency=medium
+
+  * Team upload.
+  * Replace sphinx.ext.pngmath by sphinx.ext.imgmath
+Closes: #922390
+  * Point Vcs-fields to Salsa
+
+ -- Andreas Tille   Sat, 09 Mar 2019 06:59:59 +0100
+
 hydroffice.bag (0.2.15-1) unstable; urgency=low
 
   * Initial release. (Closes: #823233)
diff -Nru hydroffice.bag-0.2.15/debian/control 
hydroffice.bag-0.2.15/debian/control
--- hydroffice.bag-0.2.15/debian/control2016-09-09 10:17:11.0 
+0200
+++ hydroffice.bag-0.2.15/debian/control2019-03-09 06:59:59.0 
+0100
@@ -20,8 +20,8 @@
python3-setuptools,
python3-wheel
 Standards-Version: 3.9.8
-Vcs-Browser: 
https://anonscm.debian.org/cgit/debian-science/packages/hydroffice.bag.git
-Vcs-Git: 
https://anonscm.debian.org/git/debian-science/packages/hydroffice.bag.git
+Vcs-Browser: https://salsa.debian.org/science-team/hydroffice.bag
+Vcs-Git: https://salsa.debian.org/science-team/hydroffice.bag.git
 Homepage: http://www.hydroffice.org/
 X-Python-Version: >= 2.7
 X-Python3-Version: >= 3.4
diff -Nru hydroffice.bag-0.2.15/debian/patches/series 
hydroffice.bag-0.2.15/debian/patches/series
--- hydroffice.bag-0.2.15/debian/patches/series 2016-09-09 10:17:11.0 
+0200
+++ hydroffice.bag-0.2.15/debian/patches/series 2019-03-09 06:59:59.0 
+0100
@@ -1 +1,2 @@
+sphinx.ext.pngmath.patch
 Use-local-copy-of-project-logo.patch
diff -Nru hydroffice.bag-0.2.15/debian/patches/sphinx.ext.pngmath.patch 
hydroffice.bag-0.2.15/debian/patches/sphinx.ext.pngmath.patch
--- hydroffice.bag-0.2.15/debian/patches/sphinx.ext.pngmath.patch   
1970-01-01 01:00:00.0 +0100
+++ hydroffice.bag-0.2.15/debian/patches/sphinx.ext.pngmath.patch   
2019-03-09 06:59:59.0 +0100
@@ -0,0 +1,16 @@
+Description: Replace sphinx.ext.pngmath by sphinx.ext.imgmath to build with 
sphinx 1.8
+Bug-Debian: https://bugs.debian.org/922390
+Author: Andreas Tille 
+Last-Update: Fri, 08 Mar 2019 18:38:02 +0100
+
+--- a/docs/conf.py
 b/docs/conf.py
+@@ -21,7 +21,7 @@ sys.path.insert(0, os.path.join(this, os
+ extensions = [
+ 'sphinx.ext.autodoc',
+ 'sphinx.ext.coverage',
+-'sphinx.ext.pngmath',
++'sphinx.ext.imgmath',
+ 'sphinx.ext.viewcode',
+ 'sphinx.ext.coverage',
+ 'sphinx.ext.intersphinx',


unblock hydroffice.bag/0.2.15-2

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

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

Bug#499796: initscripts: rootfs over nfs hangs at reboot

[Pierre Ynard]

tags 696910 patch
retitle 499796 initscripts: reboot called with -i hangs on iSCSI root
severity 499796 normal
merge 499796 696910
thanks

> My opinion is that /etc/init.d/reboot should honor NETDOWN, and source
> it from /etc/default/halt. And then NETDOWN should be documented in
> /etc/default/halt, as requested in #703844.

Actually, #696910 suggests that NETDOWN could also be disabled if iSCSI
is detected.

-- 
Pierre Ynard

Bug#921738: Not in the README?

[Jason Lingohr]

Thanks for the instructions on how to get this to work, but why is this 
not in the README?!?

Bug#914771: Re: Bug#914771: bundler: cannot load such file -- bundler-1.16.1/exe/bundle

[Antonio Terceiro]

On Sat, Mar 09, 2019 at 01:43:30AM +0100, Daniel Leidert wrote:
> Am Freitag, den 08.03.2019, 16:23 -0300 schrieb Antonio Terceiro:
> > On Fri, Mar 08, 2019 at 07:10:55PM +0100, Daniel Leidert wrote:
> > > Can we maybe change Gem.bin_path to fall back to /usr/bin or even
> > > $path?
> > 
> > Not at this point in the release cycle.
> 
> That's a suboptimal situation. It seems, there are more reports about
> this issue, like https://bugs.debian.org/710814.

It is suboptimal. Anyway, I will give it another shot. I think I found
the problem.

> However: If I apply your suggested fix (hardcode '/usr/bin/bundle') to
> jekyll, the result is:
> 
> > jekyll new --force test
> > Running bundle install in /tmp/test... 
> > 
> > 
> > Your user account isn't allowed to install to the system RubyGems.
> >   You can cancel this installation and run:
> > 
> >   bundle install --path vendor/bundle
> > 
> >   to install the gems into ./vendor/bundle/, or you can enter your password
> >   and install the bundled gems to RubyGems using sudo.
> > 
> >   Password: 
> > 
> 
> So jekyll would need another fix to not try to install into the systems
> gems location but fall back to './vendor/bundle' too. IMHO jekyll is
> currently broken with ruby-bundler.

This would happen anyway, because jekyll is calling out to bundler to
install stuff. This needs to be fixed in jekyll. rails also tries to
install stuff with bundler when creating a new app, and that's patched
out in Debian, i.e. a call to `bundle` is replaced by a call to `bundle
--local`, which will only *check* if everything in the Gemfile is
installed (and this should work if all of the packages taht rails
Recommends: were installed), but won't try to install anything.


signature.asc
Description: PGP signature

Bug#431966: network-manager shuts down before CIFS is unmounted

[Pierre Ynard]

retitle 431966 network-manager shuts down before CIFS is unmounted
severity 477498 normal
merge 431966 477498 516733 481252 552104
reassign 431966 network-manager
thanks

After reading all these bug reports, I believe that the problem is most
likely tied to network-manager, whose init script is called before
/etc/init.d/umountfs.sh during the shutdown / reboot sequence. CIFS
network filesystems only need network access still available to be
properly unmounted by umountfs.sh; but since network-manager already cut
the network off, failures, timeouts and errors ensue.

Can any reporter comment on whether they still experience the issue?

Dear NM maintainers, could you please look at this and tell us if you
think this issue still persists today? And help us figure out how
dependencies or sendsigs exception should be adjusted to resolve this?

Thanks,

-- 
Pierre Ynard

Bug#712953: sysvinit: System Restarts Instead of Powering Off

[Ben Hutchings]

Control: tag -1 moreinfo

On Fri, 21 Jun 2013 09:13:19 +0100 "Alan Chandler" <
a...@chandlerfamily.org.uk> wrote:
> Package: sysvinit
> Version: 2.88dsf-41
> Severity: normal
> 
> Dear Maintainer,
> 
> When I attempt to power off the machine (either logging out of gnome3, or via 
> shutdown now typed in at a terminal)
> the system goes through the shutdown sequence (it does seem to pause after 
> telling all processes to terminate and
> then reports that some processes are still running). It finally reports it is 
> about to power off.
> 
> But the computer then restarts and reboots.
> 
> If I load up Debian Wheezy and shut that down, the computer powers off 
> properly.

Sorry this report took so long to get assigned properly.  Is this still
happening in a current Debian version?

Ben.
 
-- 
Ben Hutchings
Knowledge is power.  France is bacon.




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

Bug#924067: ITP: ruby-jekyll-avatar -- Jekyll plugin for rendering GitHub avatars

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-jekyll-avatar
  Version : 0.6.0
  Upstream Author : Ben Balter
* URL : https://github.com/benbalter/jekyll-avatar
* License : MIT
  Programming Lang: Ruby
  Description : Jekyll plugin for rendering GitHub avatars

Jekyll Avatar makes it easy to add GitHub avatars to a Jekyll site by
specifying a username. If performance is a concern, Jekyll Avatar is deeply
integrated with the GitHub avatar API, ensuring avatars are cached and load
in parallel. It even automatically upgrades users to Retina images, when

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAlyDI5oACgkQS80FZ8KW
0F0RcxAAw8Mfn7YiLKOapFAHCIJVYBQgzZapNQA1CtKHFHTVLe4a5KKfFpKd8oA5
UXYLudbezsUPMdi/hmFyAgXFjlOKps0fRtgXM38zQJW36tx7F5dSVw8SsPSxyznE
Bt6umKhJp349LZEyMxzmEY+Qu6akZJUeQzSdpnecSEQq+kw9zc8HJXEPj5SCd4HZ
+PLoobPDpulnpNoF2oVNuwmGHZhADAGxZlxuqeMd8pzC1oFXwWyl3FtqpE1a97PC
NtdESffiimJG8s/D5hUI0vEsN4weCjOFJ/SlNNqaY2Tp0hO9/4+Ti+fJgz7Xf0PY
EhtomHdDIBa78N9j3d/Mej59bE96qQwdWn7Inn3tGYoHnjgd6UPlBfUuk3hbCefh
TDf+bYKS4B8n9VQAEcvILWAcgCwm/9u0kz4HFkmt9jQLbIVtSrnlllgg4VGrYqIc
hlxuvAimZfeVKArW254ct1shqFz36KjMDjL1yjlfFpiLUxlJVKjrS8PDBCy7KF5g
E4hIJjKoX+T+Del7lAJ+sRkT0fVDIe8QZc/oXYl6PVz5xXUKcm62WUrri2VVc4q5
jp698f353RUpc7zpieWF/f3m88GRXePKocIfxUJjE7lObkLEZt33GSfWAoHoVMYh
/FQ0/bR2JIoHTHa7rFhhYFgqiy6YDixHoJE88pXZTd91NOZPaBA=
=GHKC
-END PGP SIGNATURE-

Bug#924066: calibre: new calibre 3.40.1

[Jonatan Nyberg]

package: calibre
severity: normal

Dear Maintainer,

Please consider to upgrade to the current upstream version of calibre
(3.40.1).

Kind regards,
Jonatan

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

1) I found some code that when commented solves the problem for me.

These are:

https://salsa.debian.org/live-team/live-build/blob/f242323fa246840ba9581586ad78a8301629d84c/scripts/build/binary_grub-efi#L181-188

or

if you prefer a "fixing" commit:
https://github.com/rescatux/live-build/commit/7a17008337b31ab968224b70dbdbde39c6d5a108
.

These lines are:


if [ -r
${_CHROOT_DIR}/usr/lib/grub/\$platform-signed/gcd\$efi_name.efi.signed -a \
-r 
${_CHROOT_DIR}/usr/lib/shim/shim\$efi_name.efi.signed -a \
"${LB_UEFI_SECURE_BOOT}" != "disable" ]; then
cp
${_CHROOT_DIR}/usr/lib/grub/\$platform-signed/gcd\$efi_name.efi.signed \
${_CHROOT_DIR}/grub-efi-temp/EFI/boot/grub\$efi_name.efi
cp ${_CHROOT_DIR}/usr/lib/shim/shim\$efi_name.efi.signed \
${_CHROOT_DIR}/grub-efi-temp/EFI/boot/boot\$efi_name.efi
fi


2) So let's add more information about this issue:

Build logs shows that Secure Boot is enabled.
And that it's true because I find the .signed files in the live-build's
chroot for my build.

That would explain why that code gets triggered.

This laptop has both UEFI and BIOS/CSM boot modes.
I make sure to boot with UEFI.
I guess this laptop works with x64 and not ia32. I can try to boot an
ia32-UEFI-only version of Super Grub2 Disk if you want to.

This laptop does NOT have any UEFI Secure Boot enabled in its UEFI firmware.


3) I expect the live-build generated image to be able to fallback to a
working grub menu even if Secure Boot is not enabled here.

Anyways I don't think the problem is not related to UEFI firmware not
supporting Secure Boot but to something else related on how those signed
images try to find their own config (grub cfgs) files on a given path.

4) A deeper look tells me that the non-SB efi images are built before at:

https://salsa.debian.org/live-team/live-build/blob/f242323fa246840ba9581586ad78a8301629d84c/scripts/build/binary_grub-efi#L159-162

So let's focus on:
"\${LIVE_BUILD_PATH}/efi-image" "${_CHROOT_DIR}/\$outdir" "\$platform"
"\$efi_name" "\$netboot_prefix"

This is using efi-image which I stole back in the day from
src:live-installer .

https://salsa.debian.org/live-team/live-build/blob/f242323fa246840ba9581586ad78a8301629d84c/scripts/build/efi-image


Can anyone more experienced than me take a look at the 'signed packages'
'source package' and check how the EFI are actually built?

I guess they use a different script than efi-image or an update one that
changes some paths.



As always, any feedback is welcome.

adrian15

El 08/03/19 a las 23:21, adrian15 escribió:
> Package: live-build
> Version: 1:20180224
> Severity: important
> 
> Current live-build head ( f242323fa246840ba9581586ad78a8301629d84c We
> should add buster for release ) brings on my HP250 G6 2SX60EA laptop
> UEFI boot an:
> 
> grub>
> output.
> 
> My specific build is done in a Buster chroot and the target distro is
> Buster i386 with 686 and amd64 kernels.
> 
> I also happen to use this commit:
> https://github.com/rescatux/live-build/commit/6217dea5bc84212098d0efee18953151b41b3497
> so that amd64 kernel works for i386. I don't think you need this commit
> to be able to reproduce my problem (if you had an HP250 G6 2SX60EA or
> equivalent).
> 
> 
> I have done a manual bisect and it seems the problem comes from:
> 035518ff69a97fa5d3fa432e13c9593a9f459a4e UEFI: add support for Secure
> Boot on amd64 and arm64.
> 
> I'll try to tinker a bit reverting the commit that breaks things for me
> and applying it part by part. Anyways any feedback that can speed up my
> testing is welcomed.
> 
> Thank you very much!
> 
> adrian15
> 
> 
> Here there is the bisect just in case you need me to test more commits:
> 
> ( grub> ) f242323fa246840ba9581586ad78a8301629d84c We should add buster
> for release
> ( N/A ) 2fa258cca25d834f7896b7adc64892dc583010bf use deb.debian.org as
> default
> ( N/A ) 069d0d7b5a67f71b60cdaea01e498bb2559cc3c7 Update changelog for
> 1:20180925 release
> ( N/A ) cc1341ab4ad2302c46469c15039fac948cdec094 lintian: override error
> on dependency on e2fsprogs
> ( N/A ) 66839c4346c63e8c48d7eba6b3d1ca99f1dd691f Bump Standards-Version
> to 4.2.1.
> ( N/A ) b2a760de575c1439e996cb895deb575c611ddf15 Add
> Rules-Requires-Root: no.
> ( N/A ) 4db6471248223ffec7ea1a028b929cd819abd490 Build-Depend on
> debhelper >= 10~ to facilitate backports.
> ( N/A ) f108fdfa71c9d66a5ef9dfe7f1f48c170c7f228e UEFI: remove the
> EFI/debian/grub.cfg, not necessary anymore
> ( grub> ) c22f1f5b71745922ae28df0ebf4b7d1a49d89f55 Use
> gcd{x64.aa64}.efi.signed for amd64/arm64 arch.
> ( grub> ) 8403487d4e3bda65cdd2ea6081399f7977325adb copy keys to
> /etc/apt/trusted.gpg.d with appropriate extension for them to not be
> ignored.
> (  ) 52908422880f8d5cfa18c577d4138d5449af37f6 Handle includes.chroot
> files installed over symlinked directories
> (  ) 332c170c3b8dc2449b348191562c784db68ed331 Update changelog fo

Bug#908199: Not an issue in "aptitude".

[Gong S.]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

It turns out that the problem is that in kernel 4.19-trunk the console 
rendering is broken.
Updating to kernel 4.20 fixes the problem.
Please close this.
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsBcBAEBCAAGBQJcgxfZAAoJENi1YDlFXXQfHIQIAKZ0vZaktX00PXOZwvbZ
vzrlxgJDjvORhAjaRGZO5HW2Q0D6NrgEAYRWeqEFvRN6we41XBe6m09TOp7m
wcQ/r6Ea4tRbCNe4JCCdrYjwovbwg+XExvyB+7rPcVk4uDF3L5nDynOzab48
LOdkuuc7jitIsbWU4fI9sxUTB+bL2C8FnbCNNABwn120kWMCCpzSczn/RHIa
tvp3hvMckDTh+dZWF1+fUiPuwgccjTIrUr+dE8wURdd7S1+iMt7vYY/6Wt3q
4ulKkXYfxA8JzbesQFSzLxcxDjuIKeDuwQ6byR+HpLQd+oHPH0WYZlVkql8W
fW7fyJ/jzfqOmcdrdGGpiiw=
=B2+B
-END PGP SIGNATURE-



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


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

Bug#908894: [Debian lazygit] Go-team lazygit repo conflict issue

[Jongmin Kim]

Dear Dawid Dziula,

Hi there!

I figured out that you created Salsa repository named 'lazygit'.

I think you have an intent for packaging the lazygit. I have ITP for
this package[1], and already worked some, so I'm contacting you.

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

In fact, I have already done the lazygit packaging some month ago.
I pushed all of my work to [2] (with updated to latest: 0.7.2), checkout
please.

[2] https://salsa.debian.org/jmkim-guest/lazygit

The work includes:
  - Unvendor some dependencies which already in Debian.
  - Fix the hardening warnings by Lintian.
  - Fix for building reproducible.

If you not yet packaged all yet, could you let me upload my works? I'll
upload my work into the team's repository, and then we can do co-work.

Until now, I've been doing the job for packaging the vendored dependencies
in lazygit. As lazygit contains a lot of dependencies in its 'vendor'
directory, and Debian does not allow the embedded code copies[3], I'm
currently packaging the dependencies for split out from 'vendor'. At
present, around 48 packages are remaining[4].

[3] https://wiki.debian.org/EmbeddedCodeCopies
[4] 
https://salsa.debian.org/jmkim-guest/lazygit/blob/debian/sid/debian/copyright

Thank you!


-- 
Jongmin Kim

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


signature.asc
Description: PGP signature

Bug#924065: ITP: ruby-jekyll-redirect-from -- Jekyll plugin to give posts and pages multiple URLs

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-jekyll-redirect-from
  Version : 0.14.0
  Upstream Author : Parker Moore
* URL : https://github.com/jekyll/jekyll-redirect-from
* License : MIT
  Programming Lang: Ruby
  Description : Jekyll plugin to give posts and pages multiple URLs

When importing posts and pages, it's annoying and impractical to create new
pages in the proper subdirectories so they redirect to the new post URL.
Instead of dealing with maintaining those pages for redirection,
jekyll-redirect-from handles it them.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAlyDEfwACgkQS80FZ8KW
0F0evg//bQbo0cJap6yJG1G/Uodxl2z6oG26bL6CiONKW2BTJhUWjuRS6R4YoyXS
HyenW5CNDBoOzXTaWztiXfVeJqGp3sB4z14VyMjPTg4LWqDMirW31lkzzySTA0KA
VFKExZDxOORW89fgaq5rIBkvJ301PUW13venAGd+M+TB56G/Fta2vcIsfBHt8f5r
0Ewc9Lm5juD0w1eUbMLOWj1XKCHXClAMrGikegV26THBedR7/hVMM0XJ2jfUgXeu
Vwzc8DcAnOaiv4X5MJXDpSWVHJsgFa117CcU+M6mpBIIEDcIhw/1BnGQpdbEbsS0
QyW3zasEP4unM79hMxPCBzGyso5Sk93mOR3anvGfKkHuSvgNlYYwxKEbY7Vvnmu/
mOZjUWY+F5RL+9ZI5dUzqv96jUzv9X+yUAKsps2x83p7KRX0YW2xEhq67NOgrMwO
N2DKxJQruI5Y8sQWOpVVcCIttXUfSkvMW1Rm3+QRqRpiahZGC+vLlnO8V+VVPOt2
hk9ikY80cR2XVKGYJ4iRnuevpnXv/b7tSSoOG9wutzFqSr8qiW+Lg1fGZwJBuHv2
EG0F3NJqPYe38PcnUC/6gbzLQmbQsOAQRMvePQwFwwLeYwuzNN9zO0wW+3IWs3Xr
GkIqIUw4VihPnfmqYWnLvdeMsXmMjHbIrfMCAU1o4ej8P/WeFu0=
=3cVn
-END PGP SIGNATURE-

Bug#924064: ITP: ruby-jekyll-data -- read and add data files within Jekyll theme-gems to site hash

[Daniel Leidert]

Package: wnpp
Severity: wishlist
Owner: Daniel Leidert 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ruby-jekyll-data
  Version : 1.0.0
  Upstream Author : Ashwin Maroli
* URL : https://github.com/ashmaroli/jekyll-data
* License : MIT
  Programming Lang: Ruby
  Description : read and add data files within Jekyll theme-gems to site 
hash

Introducing a plugin that reads data files within jekyll theme-gems and adds
the resulting hash to the site's internal data hash. If a _config.yml is
present at the root of the theme-gem, it will be evaluated and the extracted
hash data will be incorporated into the site's existing config hash.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEvu1N7VVEpMA+KD3HS80FZ8KW0F0FAlyDEVEACgkQS80FZ8KW
0F2U1xAArx2EDemqcpCP1yExMuJEpE7WkEDZgAVO+I7G7Woe4vBD0lXebYKlDw4u
Ek8u/ID0k4f6X94t8GaqT7wdh8B6S4hLvH9oUXMaW20xG13DCS/BF3J1HnLB5JW2
AccnLYAg6sLisHLNsz4QgTJ2EZxQUL9qtToUj/L1trTRP4S3OUz6K/hGSKWaAqQ7
Tbm39rFug9IiLwm2TxOjI1/HlyFQ/dJI4JcZEvwHZE+5vQYQTbIlt0Qvb3g2atsv
LJqdZxamvPOmlRrlZAfMfVGaUC0wAyrDKpHh75Ru99XiW98kR6zbbsInvQjJvU0d
GfZLgLLPRdA5e/VFQSevl8QlDitx+6s1Tjt+yFFqbnCc14mCSjBsGXE7iXhXz35b
XyBmrWdEAJmB+FH8QmDEj+dCHfwynfwtjkhjwcUQOoxKyLfK8MPufZEBbIJuOPj/
MvKhZ16za9uwKoDZSVTlzGij3GWRjezWbc1KYLl5Q3AeqIP2Ne9bIkTrRGHGdnaV
4E75CNaborRjLQIS9876JUoAeEDagzFieX3TIfR/mP7PbHkX49ewsDaIcz/ZeY+u
idKs04gp+LIriClpqMrC8V7x2u+TrOSSwhFK0ZYDyuE0Q992dwF2/PrWUNvFZEN1
5VKs7cMV9GwrTrdiK856tNX3a4GQ3Xm6IhBAVa6M1UpZ3ulQHNE=
=rxNV
-END PGP SIGNATURE-

Bug#624125: sysv-rc: CONCURENCY=makefile causes bluetooth rfcomm setup to fail SOMETIMES

[Pierre Ynard]

retitle 624125 asynchronous events cause bluetooth rfcomm setup to fail 
SOMETIMES
reassign 624125 bluez
thanks

I think responsibility should lie best with the bluetooth package to
ensure proper dependencies and pre-requisites and that the asynchronous
events it relies on are handled properly. Either way I don't see that
sysvinit or any of its init scripts has any real influence in this.
Reassigning so bluetooth maintainers get a chance to look at this.

Dear maintainers, could you take a look at this report of this error:

> Can't open RFCOMM control socket: Address family not supported by
> protocol

Thanks,

-- 
Pierre Ynard

Bug#914771: Re: Bug#914771: bundler: cannot load such file -- bundler-1.16.1/exe/bundle

[Daniel Leidert]

Am Freitag, den 08.03.2019, 16:23 -0300 schrieb Antonio Terceiro:
> On Fri, Mar 08, 2019 at 07:10:55PM +0100, Daniel Leidert wrote:
> > Can we maybe change Gem.bin_path to fall back to /usr/bin or even
> > $path?
> 
> Not at this point in the release cycle.

That's a suboptimal situation. It seems, there are more reports about
this issue, like https://bugs.debian.org/710814.

However: If I apply your suggested fix (hardcode '/usr/bin/bundle') to
jekyll, the result is:

> jekyll new --force test
> Running bundle install in /tmp/test... 
> 
> 
> Your user account isn't allowed to install to the system RubyGems.
>   You can cancel this installation and run:
> 
>   bundle install --path vendor/bundle
> 
>   to install the gems into ./vendor/bundle/, or you can enter your password
>   and install the bundled gems to RubyGems using sudo.
> 
>   Password: 
> 

So jekyll would need another fix to not try to install into the systems
gems location but fall back to './vendor/bundle' too. IMHO jekyll is
currently broken with ruby-bundler.

Regards, Daniel


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

Bug#908216: btrfs blocked for more than 120 seconds

[Nicholas D Steeves]

On Wed, Mar 06, 2019 at 07:55:45AM -0600, Russell Mosemann wrote:
>The four most problematic servers were hanging nearly every day. They each
>have a dedicated hard drive and are running 4.19.0-0.bpo.2-amd64. I
>installed btrfs-progs 4.20.1 on each and recreated the file system on the
>hard drive. There have been no issues since then, but it is too early to
>tell. There are hardly any references or files on the drives. It might
>take up to a month to know if there is an issue.
> 

Thanks for reformatting with newer -progs; this eliminates the most
difficult/impossible to reproduce factor.  Which of the five rounds of
tests from
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908216#202 have you
started with?

It should be possible to accelerate triggering the bug by using the
network to send additional VM images from each server to the test
subject once a day.  eg: if four servers send VM images to a fifth
server then ideally (optimistically!) the bug would be triggered 80%
faster, and if everything is still all clear after a month then you'd
have at least 220 reflinked historical backups and five sparse copies
of large VM images.

Thank you for your work on making this bug reproducible.  This not
only accelerates its resolution (reproducible case in core
functionality needs to be forwarded upstream), but also provides
valuable data to inform our wiki's upcoming btrfs on buster
(linux-4.19) recommendations.

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#924063: sway: Configure x-terminal-emulator as $term or add urxvt (and suckless-tools) to recommends and fix keyboard layout.

[Javier Barroso]

Package: sway
Version: 1.0~rc3-1
Severity: wishlist

Dear Maintainer,

Thank you for your Debian work

If you have not installed urxvt and/or suckless-tools (for dmenu) you will
not be
able to launch any app from sway with default config (at least for my
knowledge)

So I'm proposing to add suckless-tools to recommended packages, and
changing in the default config urxvt to x-terminal-emulator (or adding
urxvt to the recommended list)

Maybe worth of mention on a (new) README.Debian (or similar) that if you
want to have
a different layout keyboard than the default (english), you need to add
XKB_DEFAULT_LAYOUT to the languaje preferred, at my case:

$ cat /etc/environment.d/99sway.conf
XKB_DEFAULT_LAYOUT=es

Not sure how awesome (or others wm) solve this problem. Maybe the
correct solution is another.

Regards
PD: Sorry for mention 3 mini bugs only on one bug report, i hope it is
not problem


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

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

Versions of packages sway depends on:
ii  libc62.28-8
ii  libcairo21.16.0-3
ii  libevdev21.6.0+dfsg-1
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libglib2.0-0 2.58.3-1
ii  libinput10   1.12.6-1
ii  libjson-c4   0.13.1+dfsg-2
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpcre3 2:8.39-11
ii  libpixman-1-00.36.0-1
ii  libsystemd0  241-1
ii  libwayland-client0   1.16.0-1
ii  libwayland-cursor0   1.16.0-1
ii  libwayland-server0   1.16.0-1
ii  libwlroots0  0.3-1
ii  libxcb1  1.13.1-2
ii  libxkbcommon00.8.2-1

Versions of packages sway recommends:
ii  sway-backgrounds  1.0~rc3-1

Versions of packages sway suggests:
pn  swayidle  
pn  swaylock  

-- Configuration Files:
/etc/sway/config changed [not included]

-- no debconf information

Bug#924061: ceph-osd: ceph-volume@.service missing

[Bernd Zeimetz]

Package: ceph-osd
Version: 12.2.11+dfsg1-2
Severity: grave

Hi,

unfortunately the ceph-volume@.service systemd template is missing,
which basically breaks the activation of OSDs.

Sounds like
http://tracker.ceph.com/issues/21011

As this basically breaks the usage of bluestore volumes, I think grave
is the appropriate severity, especially as - looking at the ceph bug
tracker - this might have been working before.

Thanks for fixing,

Bernd


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

( I CC Luca Bocassi which commited the bug that makes showing grub> on
HP 250 G6 2SX60EA instead of the grub menu. )

I forgot to mention about the grub environment in both cases. So that it
can help, maybe to understand, why it's failing.

1) grub environment on failing build

I suspect I get in a blink of an eye the message:
/boot not found
but I'm not 100% sure.

As I said I'm getting a grub> prompt.
Which has some variables defines, among these variables there are these
ones:

cmdpath=(hd0,msdos2)/EFI/BOOT # USB
prefix=(hd1,msdos2)/boot/grub # Laptop internal hard disk
root=hd1,msdos2 # Laptop internal hard disk

How do I manage to show the menu manually?

set root=hd0,msdos2
chainloader (hd0,msdos2)/efi/boot/grubx64.efi
boot

2) grub environment on grub showing menu at boot
This is Debian Live testing amd64 gnome nonfree
and I know it's not live-build based but lwr based.

Anyways I put the variables here:

cmdpath=(hd0,msdos2)/EFI/BOOT # USB
prefix=(hd0)/boot/grub # USB
root=hd0 # USB

3) grub environment on grub showing menu at boot
This is on ac3ed23638cbc4b10059f9678283d08b4a082136 commit (UEFI: add
minimal grub.cfg to fat32 partition)


cmdpath=(hd0,msdos2)/EFI/BOOT # This might be an additional EFI
partition because it only has 'efi' and 'boot' directories.
prefix=(hd0)/boot/grub # USB ( boot/ , efi/, efi.img, isolinux/, live/ y
md5sum.txt )
root=hd0 # USB ( boot/ , efi/, efi.img, isolinux/, live/ y md5sum.txt )


adrian15

El 08/03/19 a las 23:21, adrian15 escribió:
> Package: live-build
> Version: 1:20180224
> Severity: important
> 
> Current live-build head ( f242323fa246840ba9581586ad78a8301629d84c We
> should add buster for release ) brings on my HP250 G6 2SX60EA laptop
> UEFI boot an:
> 
> grub>
> output.
> 
> My specific build is done in a Buster chroot and the target distro is
> Buster i386 with 686 and amd64 kernels.
> 
> I also happen to use this commit:
> https://github.com/rescatux/live-build/commit/6217dea5bc84212098d0efee18953151b41b3497
> so that amd64 kernel works for i386. I don't think you need this commit
> to be able to reproduce my problem (if you had an HP250 G6 2SX60EA or
> equivalent).
> 
> 
> I have done a manual bisect and it seems the problem comes from:
> 035518ff69a97fa5d3fa432e13c9593a9f459a4e UEFI: add support for Secure
> Boot on amd64 and arm64.
> 
> I'll try to tinker a bit reverting the commit that breaks things for me
> and applying it part by part. Anyways any feedback that can speed up my
> testing is welcomed.
> 
> Thank you very much!
> 
> adrian15
> 
> 
> Here there is the bisect just in case you need me to test more commits:
> 
> ( grub> ) f242323fa246840ba9581586ad78a8301629d84c We should add buster
> for release
> ( N/A ) 2fa258cca25d834f7896b7adc64892dc583010bf use deb.debian.org as
> default
> ( N/A ) 069d0d7b5a67f71b60cdaea01e498bb2559cc3c7 Update changelog for
> 1:20180925 release
> ( N/A ) cc1341ab4ad2302c46469c15039fac948cdec094 lintian: override error
> on dependency on e2fsprogs
> ( N/A ) 66839c4346c63e8c48d7eba6b3d1ca99f1dd691f Bump Standards-Version
> to 4.2.1.
> ( N/A ) b2a760de575c1439e996cb895deb575c611ddf15 Add
> Rules-Requires-Root: no.
> ( N/A ) 4db6471248223ffec7ea1a028b929cd819abd490 Build-Depend on
> debhelper >= 10~ to facilitate backports.
> ( N/A ) f108fdfa71c9d66a5ef9dfe7f1f48c170c7f228e UEFI: remove the
> EFI/debian/grub.cfg, not necessary anymore
> ( grub> ) c22f1f5b71745922ae28df0ebf4b7d1a49d89f55 Use
> gcd{x64.aa64}.efi.signed for amd64/arm64 arch.
> ( grub> ) 8403487d4e3bda65cdd2ea6081399f7977325adb copy keys to
> /etc/apt/trusted.gpg.d with appropriate extension for them to not be
> ignored.
> (  ) 52908422880f8d5cfa18c577d4138d5449af37f6 Handle includes.chroot
> files installed over symlinked directories
> (  ) 332c170c3b8dc2449b348191562c784db68ed331 Update changelog for
> 1:20180618 release
> (  ) be7bc0a9ffcc0b59ae66a63a863fb586d7ac1fca Bump Standards-Version to
> 4.1.4, no changes.
> ( Skipped ) 316b1281581b188e3353fe59bb40bcb81cbd953f UEFI: parse vendor
> from Grub package metadata
> (  ) e5492b1c702858eb26e2b93c65810773ad0bfa85 Avoid apt-key add and just
> drop the key in /etc/apt/trusted.gpg.d
> (  ) 186765e3fd905a2ecd08cd22dd9afdcc581b1d0a lb clean: remove ONIE image
> (  ) b3ec8d59787a2c59c5cc68f9fd60ff004049d828 Update changelog for
> 1:20180411 release
> (  ) b062ede56c5aef3b1909efbf87f71d6617bc1936 Fix debian/NEWS date to
> match an actual release
> (  ) 277f0cec71b8a9a1b109225a69551ef5c7ba05e2 Reconfigure bootstrapped
> packages after preseeding.
> (  ) da0119396559308b29c78a7cc983013cf07797f0 Don't recommend gzip, it's
> essential
> (  ) 08dd0b90dbe87411fb0657c940926c85730ac3e7 Print an error and exit if
> a host package (dependency) is missing.
> (  ) 050e637b2ceaa1f6735fd9f84b0f7f4676637a79 ONIE: do not use package
> cache, only runs on host
> (  ) a0335ac4a42a1b784b054459b2377a0935720d23 ONIE: add Recommends for
> programs needed by binary_onie
> (  ) e47652d8412d2ccb2d32c370096580b7019f7655 ONIE: missing 

Bug#823150: Please remove the Recommends on fonts-mgopen

[Holger Wansing]

Control: tags -1 + pending

Faidon Liambotis  wrote:
> Package: task-greek-desktop
> Version: 3.34
> Severity: normal
> 
> Hi,
> 
> It's been a long time since MgOpen was the only reasonable font with
> Greek glyphs; a standard Debian desktop should support Greek just fine
> these days and MgOpen is actually in such a poor state that it's even
> counterproductive to install it by default (the lack of the Euro
> currency glyph is an example of that).
> 
> As such, I've requested from the ftp-masters its removal from the
> archive. You can see the full rationale over at #819026.

Just committed.
Tagging this bug as pending.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#910615: task-catalan-desktop: Please recommend hunspell-ca instead of dropped transitional package myspell-ca

[Holger Wansing]

Control: tags -1 + pending

Agustin Martin  wrote:
> Package: task-catalan-desktop
> Version: 3.46
> Severity: normal
> 
> Dear Maintainer,
> 
> myspell-ca transitional package is being dropped. Please change Recommends
> to hunspell-ca.

Just committed.
Tagging this bug as pending.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#924060: systemd: Memory leak introduced with CVE-2018-16864 fix

[Will Roberts]

Package: systemd
Version: 215-17+deb8u10
Severity: important
Tags: patch

Dear Maintainer,

The fix for CVE-2018-16864 contains a memory leak that was fixed for
newer distributions of Debian, but not old-stable. I believe this commit 
contains
the changes that need to be applied:

https://salsa.debian.org/systemd-team/systemd/commit/d9c31850e7bfbb537c7fdc81ad9a9fc96a1fd33e

Thanks,
Will

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u10
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2+deb8u5
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1+deb8u2+b1
ii  libselinux1 2.3-2
ii  libsystemd0 215-17+deb8u10
ii  mount   2.25.2-6
ii  sysv-rc 2.88dsf-59
ii  udev215-17+deb8u10
ii  util-linux  2.25.2-6

Versions of packages systemd recommends:
ii  dbus1.8.22-0+deb8u1
ii  libpam-systemd  215-17+deb8u10

Versions of packages systemd suggests:
pn  systemd-ui  

-- no debconf information

Bug#924037: Please add anacron back to task-desktop and task-laptop

[Holger Wansing]

Control: tags -1 + pending


Cyril Brulebois  wrote:
> Hi Holger,
> 
> Holger Wansing  (2019-03-08):
> > Since this is just a revert of a recent change, this can be considered
> > causing no harm.
> > 
> > Any objections?
> > kibi?
> 
> Sure, a revert looks good indeed; thanks!

Just committed.
Tagging this bug as pending



Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#780641: startpar hang on reboot

[Pierre Ynard]

unarchive 682654
forcemerge 682654 780641
reassign 682654 startpar
retitle 682654 startpar hang with upstart
fixed 682654 0.61~beta-1
thanks

Everything points to an issue with upstart support in startpar. upstart
was removed from the Debian archive, and support was dropped in startpar
0.61~beta-1, so I'm closing this.

Thanks,

-- 
Pierre Ynard

Bug#923958: [Pkg-ayatana-devel] Bug#923958: libmessaging-menu-dev: wrong filenames in pkg-config file

[Mike Gabriel]

Hi Luca,

On  Do 07 Mär 2019 17:24:28 CET, Luca Boccassi wrote:


Package: libmessaging-menu-dev
Version: 0.6.0-2
Severity: important

Dear Maintainer,

The pkg-config file shipped by libmessaging-menu-dev adds a non-
existing directory to the include path via cflags and a non-existing
linking flag:

$ pkg-config --cflags messaging-menu
-pthread -I/usr/include/ayatana-messaging-menu -I/usr/include/gio-unix-
2.0 -I/usr/include/libmount -I/usr/include/blkid -I/usr/include/uuid
-I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
$ pkg-config --libs messaging-menu
-layatana-messaging-menu -lgio-2.0 -lgobject-2.0 -lglib-2.0

$ dpkg -L libmessaging-menu-dev | grep include
/usr/include
/usr/include/messaging-menu
/usr/include/messaging-menu/messaging-menu-app.h
/usr/include/messaging-menu/messaging-menu-message.h
/usr/include/messaging-menu/messaging-menu.h

$ dpkg -L libmessaging-menu-dev | grep so
/usr/lib/x86_64-linux-gnu/libmessaging-menu.so

/usr/include/ayatana-messaging-menu does not exist, the actual
directory is /usr/include/messaging-menu. libayatana-messaging-menu.so
does not exist, the actual library is libmessaging-menu.so.

This makes pkg-config unusable as the real include directory and
linker flags are missing.


I am also receiving some patches on the upstream side of the project  
at the moment.


Do you think, you can file a pull request against the upstream Git repo [1]?

Or send a patch to this bug tracker instead, if you don't want to use Github?

Thanks,
Mike

[1] https://github.com/AyatanaIndicators/ayatana-indicator-messages/
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

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



pgpa4kn3AnPFF.pgp
Description: Digitale PGP-Signatur

Bug#923899: RFP: elpa-puppet-mode -- syntax highlighting for puppet manifests in emacs

[Nicholas D Steeves]

On Thu, Mar 07, 2019 at 09:55:05AM -0500, Antoine Beaupré wrote:
> 
> I've opened another one to ask upstream to make a new release:
> 
> https://github.com/voxpupuli/puppet-mode/issues/117
>

Thank you Antoine :-)

> ... in the meantime, I think we shouldn't package 0.3 directly. It's
> really old (5 years!) and there's been good stuff packaged since.
> 
> So I would recommend packaging a snapshot instead, something like
> "0.3+git7dee1b5" for example. It's not ideal because git revisions don't
> increment, but hopefully the above issue will be fixed and that would be
> just a temporary hack.
> 
> Alternatively, I could just upload 0.3 as is, but I would honestly not
> use it myself since I want the latest features and bugfixes. This would
> defeat the purpose of the package in first place... ;)
>

Okie doke, that's justification enough for me.  I've uploaded
0.3+132.g7dee1b5-1 to mentors.  I use
$tag+$additional_commits_count.g$hash because it's based on git
describe output, I believe it sorts numerically using the
$additional_commits second field, and I think it would be confusing to
use the "-" separator here (instead of ".").  Arguably a colon makes
more sense than a period, but I'm already using periods in my
packages...I guess I could change this for bullseye if the difference
is significant enough.  eg:

  Such and such tag, plus however many commits is this: g$hash
/\ colon used similarly to natural language
  vs
  using ".", which feels like a substitute for "@".
tag+commits@g$hash
I'm not sure that this is as evident, but I read about how other
people prefer the "." separator in various -devel threads.
Meh, enough delimiter philosophy!

This upstream snapshot uses an odd 'puppet-mode-0.4snapshot' as the
internal version for package.el dependency resolution...IIRC
0.4snapshot+foo-1 will sort after 0.4-1, so we can't use that.  And
MELPA unstable uses self-generated "Version: 20180813.1947".  Maybe
0.4snapshot~132.g7dee1b5-1 or 0.4snapshot~132:g7dee1b5-1?  That would
fulfill Debian sort and the elpa version will be less bogus, but I've
never used it before, and it doesn't solve the compatibility with
MELPA unstable problem...I'm definitely not interested in maintaining
a patch that harmonises with MELPA unstable's declared version.

  
https://mentors.debian.net/debian/pool/main/p/puppet-mode/puppet-mode_0.3+132.g7dee1b5-1.dsc

> 
> Thanks for the extremely quick response and packaging anyways, you're
> doing an awesome job. :)

Thank you :-)

Nicholas


signature.asc
Description: PGP signature

Bug#923486: CVE-2019-6111 not fixed, file transfer of unwanted files by malicious SSH server still possible

[Mike Gabriel]

Hi Colin, hi Debian LTS team,

On  Fr 01 Mär 2019 13:24:30 CET, Colin Watson wrote:


And yes, it looks OK - I'll upload it to unstable shortly.


I have prepared a backport of this newly added patch [1] (see #923486  
for details) to openssh in Debian jessie LTS, but with that patch  
backported to openssh in Debian jessie, I get a segmentation fault  
whenever I copy something using the scp cmdline tool (I have of course  
backported all other patches regarding CVE-2019-6109 and CVE-2019-6111).


I have attached the complete .debdiff between openssh 1:6.7p1-5+deb8u7  
(in jessie-security) and my (not-yet-)proposal for 1:6.7p1-5+deb8u8.


The critical patch is CVE-2019-6111-2.patch. With that patch added I  
get segfaults with scp. Without that patch scp works, but is  
susceptible to the earlier mentioned exploit for CVE-2019-6111.


I am a bit lost here and would appreciate some ideas about what is  
going wrong here.


I will only be able to continue on this on Monday, but maybe someone  
else can offer some genuine input over the weekend. Will be much  
appreciated.


Thanks+Greets,
Mike

[1]  
https://anongit.mindrot.org/openssh.git/commit/?id=3d896c157c722bc47adca51a58dca859225b5874

--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net

diff -Nru openssh-6.7p1/debian/changelog openssh-6.7p1/debian/changelog
--- openssh-6.7p1/debian/changelog  2018-09-12 13:23:59.0 +0200
+++ openssh-6.7p1/debian/changelog  2019-02-01 00:45:09.0 +0100
@@ -1,3 +1,16 @@
+openssh (1:6.7p1-5+deb8u8) jessie-security; urgency=medium
+
+  * Non-maintainer upload by the LTS Team.
+  * CVE-2018-20685: Disallow empty incoming filename or ones that refer
+to the current directory; based on report/patch from Harry Sintonen.
+  * CVE-2019-6109: Sanitize scp filenames via snmprintf. To do this we move
+the progressmeter formatting outside of signal handler context and have the
+atomicio callback called for EINTR, too.
+  * CVE-2019-6111: Check in scp client that filenames sent during remote->local
+directory copies satisfy the wildcard specified by the user.
+
+ -- Mike Gabriel   Fri, 01 Feb 2019 00:45:09 +0100
+
 openssh (1:6.7p1-5+deb8u7) jessie-security; urgency=medium
 
   * Add debian/patches/CVE-2016-1908-3.patch: client_x11_get_proto: check if
diff -Nru openssh-6.7p1/debian/patches/CVE-2018-20685.patch 
openssh-6.7p1/debian/patches/CVE-2018-20685.patch
--- openssh-6.7p1/debian/patches/CVE-2018-20685.patch   1970-01-01 
01:00:00.0 +0100
+++ openssh-6.7p1/debian/patches/CVE-2018-20685.patch   2019-02-01 
00:35:55.0 +0100
@@ -0,0 +1,27 @@
+From 6010c0303a422a9c5fa8860c061bf7105eb7f8b2 Mon Sep 17 00:00:00 2001
+From: "d...@openbsd.org" 
+Date: Fri, 16 Nov 2018 03:03:10 +
+Subject: [PATCH] upstream: disallow empty incoming filename or ones that refer
+ to the
+
+current directory; based on report/patch from Harry Sintonen
+
+OpenBSD-Commit-ID: f27651b30eaee2df49540ab68d030865c04f6de9
+
+[sunweaver] - Ported to OpenSSH 1:6.0p1 as found in Debian wheezy (ELTS)
+---
+ scp.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/scp.c
 b/scp.c
+@@ -1039,7 +1039,8 @@
+   size = size * 10 + (*cp++ - '0');
+   if (*cp++ != ' ')
+   SCREWUP("size not delimited");
+-  if ((strchr(cp, '/') != NULL) || (strcmp(cp, "..") == 0)) {
++  if (*cp == '\0' || strchr(cp, '/') != NULL ||
++  strcmp(cp, ".") == 0 || strcmp(cp, "..") == 0) {
+   run_err("error: unexpected filename: %s", cp);
+   exit(1);
+   }
diff -Nru openssh-6.7p1/debian/patches/CVE-2019-6109-1.patch 
openssh-6.7p1/debian/patches/CVE-2019-6109-1.patch
--- openssh-6.7p1/debian/patches/CVE-2019-6109-1.patch  1970-01-01 
01:00:00.0 +0100
+++ openssh-6.7p1/debian/patches/CVE-2019-6109-1.patch  2019-01-31 
17:17:12.0 +0100
@@ -0,0 +1,253 @@
+Backport of:
+
+From 8976f1c4b2721c26e878151f52bdf346dfe2d54c Mon Sep 17 00:00:00 2001
+From: "dtuc...@openbsd.org" 
+Date: Wed, 23 Jan 2019 08:01:46 +
+Subject: [PATCH] upstream: Sanitize scp filenames via snmprintf. To do this we
+ move
+
+the progressmeter formatting outside of signal handler context and have the
+atomicio callback called for EINTR too.  bz#2434 with contributions from djm
+and jjelen at redhat.com, ok djm@
+
+OpenBSD-Commit-ID: 1af61c1f70e4f3bd8ab140b9f1fa699481db57d8
+---
+ atomicio.c  | 20 ++-
+ progressmeter.c | 53 ++---
+ progressmeter.h |  3 ++-
+ scp.c   |  3 ++-
+ sftp-client.c   | 18 +
+ 5 files changed, 53 insertions(+), 44 deletions(-)
+
+Index: openssh-6.6p1/atomicio.c
+

Bug#924055: opendnssec: [INTL:fr] French debconf templates translation

[Jean-Pierre Giraud]

Package: opendnssec
Severity: wishlist
Tags: patch l10n

Hi!

Please find attached the french translation, proofread
by the debian-l10n-french mailing list contributors.

This file should be put as debian/po/fr.po in your package build tree.

Kind Regards

jipege


fr.po.gz
Description: application/gzip

Bug#922004: transition: clamav

[Sebastian Andrzej Siewior]

On 2019-02-27 20:56:00 [+], Niels Thykier wrote:
> Please go ahead. :)

The transition looks complete.

> Thanks,
> ~Niels

Sebastian

Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15]

Package: live-build
Version: 1:20180224
Severity: important

Current live-build head ( f242323fa246840ba9581586ad78a8301629d84c We
should add buster for release ) brings on my HP250 G6 2SX60EA laptop
UEFI boot an:

grub>
output.

My specific build is done in a Buster chroot and the target distro is
Buster i386 with 686 and amd64 kernels.

I also happen to use this commit:
https://github.com/rescatux/live-build/commit/6217dea5bc84212098d0efee18953151b41b3497
so that amd64 kernel works for i386. I don't think you need this commit
to be able to reproduce my problem (if you had an HP250 G6 2SX60EA or
equivalent).


I have done a manual bisect and it seems the problem comes from:
035518ff69a97fa5d3fa432e13c9593a9f459a4e UEFI: add support for Secure
Boot on amd64 and arm64.

I'll try to tinker a bit reverting the commit that breaks things for me
and applying it part by part. Anyways any feedback that can speed up my
testing is welcomed.

Thank you very much!

adrian15


Here there is the bisect just in case you need me to test more commits:

( grub> ) f242323fa246840ba9581586ad78a8301629d84c We should add buster
for release
( N/A ) 2fa258cca25d834f7896b7adc64892dc583010bf use deb.debian.org as
default
( N/A ) 069d0d7b5a67f71b60cdaea01e498bb2559cc3c7 Update changelog for
1:20180925 release
( N/A ) cc1341ab4ad2302c46469c15039fac948cdec094 lintian: override error
on dependency on e2fsprogs
( N/A ) 66839c4346c63e8c48d7eba6b3d1ca99f1dd691f Bump Standards-Version
to 4.2.1.
( N/A ) b2a760de575c1439e996cb895deb575c611ddf15 Add
Rules-Requires-Root: no.
( N/A ) 4db6471248223ffec7ea1a028b929cd819abd490 Build-Depend on
debhelper >= 10~ to facilitate backports.
( N/A ) f108fdfa71c9d66a5ef9dfe7f1f48c170c7f228e UEFI: remove the
EFI/debian/grub.cfg, not necessary anymore
( grub> ) c22f1f5b71745922ae28df0ebf4b7d1a49d89f55 Use
gcd{x64.aa64}.efi.signed for amd64/arm64 arch.
( grub> ) 8403487d4e3bda65cdd2ea6081399f7977325adb copy keys to
/etc/apt/trusted.gpg.d with appropriate extension for them to not be
ignored.
(  ) 52908422880f8d5cfa18c577d4138d5449af37f6 Handle includes.chroot
files installed over symlinked directories
(  ) 332c170c3b8dc2449b348191562c784db68ed331 Update changelog for
1:20180618 release
(  ) be7bc0a9ffcc0b59ae66a63a863fb586d7ac1fca Bump Standards-Version to
4.1.4, no changes.
( Skipped ) 316b1281581b188e3353fe59bb40bcb81cbd953f UEFI: parse vendor
from Grub package metadata
(  ) e5492b1c702858eb26e2b93c65810773ad0bfa85 Avoid apt-key add and just
drop the key in /etc/apt/trusted.gpg.d
(  ) 186765e3fd905a2ecd08cd22dd9afdcc581b1d0a lb clean: remove ONIE image
(  ) b3ec8d59787a2c59c5cc68f9fd60ff004049d828 Update changelog for
1:20180411 release
(  ) b062ede56c5aef3b1909efbf87f71d6617bc1936 Fix debian/NEWS date to
match an actual release
(  ) 277f0cec71b8a9a1b109225a69551ef5c7ba05e2 Reconfigure bootstrapped
packages after preseeding.
(  ) da0119396559308b29c78a7cc983013cf07797f0 Don't recommend gzip, it's
essential
(  ) 08dd0b90dbe87411fb0657c940926c85730ac3e7 Print an error and exit if
a host package (dependency) is missing.
(  ) 050e637b2ceaa1f6735fd9f84b0f7f4676637a79 ONIE: do not use package
cache, only runs on host
(  ) a0335ac4a42a1b784b054459b2377a0935720d23 ONIE: add Recommends for
programs needed by binary_onie
(  ) e47652d8412d2ccb2d32c370096580b7019f7655 ONIE: missing dependency
on file
(  ) 2aff516e1f9713e1c7407f163bc0abc998951bca ONIE: Check_package in the
host, not the chroot
(  ) 44e0d3520e9440cab692c86536083b3ce19510a2 Update changelog for
1:20180328 release
(  ) 919604643bb66a2e2c4ea1cf6a630a6a6e24fbfa Add myself to Uploaders.
(  ) 76a90f31b5e84aa630982e1c09df82b0baff1ebe Bump Standards-Version to
4.1.3.
(  ) 7f5d8ef9e9704efd962fc8950e7991ca66070fdc Use HTTPS in
debian/copyright (policy 4.0.0).
(  ) c1948b4183099b37dbc4ebf6b5e16cb6fe885cef ONIE: detect initrd
compression instead of hard-coding
(  ) 0e91aeea428577b71fa0e2dd21d5cf664a0ebbe9 Add
Acquire::AllowInsecureRepositories to fix apt-secure in sid
(  ) 46c95969265fff53173a06419db46133c12f42ae Add options to build ONIE
images
(  ) 8047c2425ac8ca8c89586b76dcce4a4fbe66f303 Add NEWS file to warn
users about change of live-boot mount paths
( ) aa1ae83854d5e85901ab56ad291f9e938a0582db UEFI: use uppercase EFI
directory name for Tianocore
( CULPRIT grub>  ) 035518ff69a97fa5d3fa432e13c9593a9f459a4e UEFI: add
support for Secure Boot on amd64 and arm64
( OK ) ac3ed23638cbc4b10059f9678283d08b4a082136 UEFI: add minimal
grub.cfg to fat32 partition

( OK ) 0effdbd8ef12d0f668afee9505d1f50659f892ef Add grub-based UEFI boot
support for ARM64
( N/A ) 06d81b6710373f15faa1324f1f691483fafde8d1 Update changelog
( N/A ) 952ac834e4bf63bccfc84715d6e69bd3fd9b3ff0 Simplify bootstrapping
of foreign architectures with qemu-debootstrap
( N/A ) 842e971a65edf049a33dbba738d30c8c7edb85bc Run mksquashfs with
nice -n 19 to not overload the system
( N/A ) ee8d06c46cfa30fb0c7d43fde5d4f8dfef3967c4 Merge branch
'fix_offline_repo' into 'master'
( N/A ) 9a0c6102fdff56da0871bfb1a63cc0349d

Bug#923889: google-compute-image-packages - DoS via serial console write

[Ross Vandegrift]

On Fri, Mar 08, 2019 at 10:59:33AM +0100, Bastian Blank wrote:
> In normal operation, the rate limit of journald might make sure it does
> not come to really blocking.

Ahh, that would do it, thanks.

> What happens for use cases where you need to disable this rate limit?
> Mail servers which Postfix, which exclusively uses syslog that is
> redirected to the journal, need this, or they will loose logs.
> 
> On Azure we tried the same for a short time period.  It got quiet messy
> and also triggered bugs in the platform.

For sure - I wasn't defending the change, just surprised when I couldn't
reproduce the problem.

> I assume the initial goal was to get the log output of the provisioning
> daemons on the serial console.  This goal was also mentioned in the
> formerly shipped rsyslog config snippet.
>
> Forwarding all log traffic there completely destroys that ability, as it
> will be drowned by irrelevant log traffic.  Also the log buffer is
> limited in size.

Yep, agreed.

Ross

Bug#608862: network-manager: automounted nfs volumes no longer mount when connecting with wireless

[Pierre Ynard]

tags 608862 -moreinfo
merge 608862 602212
severity 608862 minor
retitle 608862 asynchronous mountnfs fails on stray lock
thanks

> I looked into this issue a bit more, and it looks like all I needed
> to do is remove the /var/run/network/mountnfs lock directory to get
> it working again. Either there was a bad version sometime that didn't
> clean it up or something crashed or killed it before it could remove
> the directory, but it seems to work fine now.

Interesting choice to lock using mkdir, considering that a stray
/var/run/network/mountnfs lock would never get removed by bootclean.sh
because it's a directory. I'm going to assume that's what happened then.

Nowadays /run is a tmpfs so that issue is mostly moot.

I suppose we could still improve that locking or make sure stray locks
are properly removed before mountnfs operations are started.

-- 
Pierre Ynard

Bug#924052: debhelper: dh_auto_test should prefer 'make check' over 'make test'

[Benjamin Moody]

Package: debhelper
Version: 10.2.5
Severity: wishlist

Dear Maintainer,

If a package is built using make, dh_auto_test should prefer to run
'make check' (which is the GNU standard [1]) rather than 'make test'.

This is doubly true for packages that use automake [2], but I think it
would make sense for all packages using makefiles.

The reason I see for preferring 'make check' is that it's common to
have a test program named 'test.c', 'test.sh', etc., and thus 'make
test' is an instruction to compile the test program rather than to run
it.  I suspect that this (combined with the fact that old versions of
make didn't support the notion of phony targets) is the reason for
GNU's choice of 'make check'.

That is to say, I suspect 'check' was chosen deliberately because it
was (and is) a less common term, and thus less ambiguous.

Note, I'm not proposing that dh_auto_test should ignore the 'test'
target; rather, in cases where *both* 'test' and 'check' are defined
(possibly by implicit rules), 'check' is the one that should be used
by default.

A third possibility would be to run 'make test check', on the
assumption that it's unlikely to be harmful to run both targets.
('make test check' would be better than 'make test && make check',
since the makefile might define the two as aliases of each other.)

There is of course no way to have a single rule that works for every
package.  However, my suspicion is:

- Packages for which 'make check' runs the test suite, and 'make test'
  incidentally does something different, are more common than packages
  for which 'make test' runs the test suite, and 'make check'
  incidentally does something different.

- The least surprising behavior would be to follow the behavior of
  automake and the GNU standards.

The second point is a matter of opinion, but the first is in principle
a testable hypothesis...


[1] GNU Coding Standards: Standard Targets for Users
https://www.gnu.org/prep/standards/html_node/Standard-Targets.html

[2] Automake manual: Support for test suites
https://www.gnu.org/software/automake/manual/html_node/Tests.html


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

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

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.28-5
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg 1.18.25
ii  dpkg-dev 1.18.25
ii  file 1:5.30-1+deb9u2
ii  libdpkg-perl 1.18.25
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-3+deb9u5
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
pn  dh-make  

-- no debconf information

Bug#924051: nfs-common: Krb5 NFSv4 Realmd AD nfsidmap files owned by nobody group 4294967294

[Michael Barkdoll]

Package: nfs-common
Version: 1:1.3.4-2.1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Debian box joined to AD with Realmd.  Mounted nfsv4 with kerberos auth.  
UID/GID match on client and server.  File permissions honored by displayed 
incorrected.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The following was observed in /var/log/syslog on the client:
nss_getpwnam: name 'us...@xx.xx.edu@XX.XX.EDU' domain 'XX.XX.EDU': resulting 
localname '(null)' 

uid and gid appear to not map properly from nfsidmap in a nfsv4 with sec=krb5. 
UID and GID are mapping properly on CentOS server and CentOS client. Ubuntu nfs 
client file permissions are honored, but display in `ls -lan` command are 
incorrect.

---
$ cat /var/log/syslog |grep nfsidmap
Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: key: 0x24a1c64d type: uid value: 
us...@xx.xx.edu@XX.XX.EDU timeout 600
Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: calling 
nsswitch->name_to_uid
Mar 8 16:38:34 client nfsidmap[24736]: nss_getpwnam: name 
'us...@xx.xx.edu@XX.XX.EDU' domain 'XX.XX.EDU': resulting localname '(null)'
Mar 8 16:38:34 client nfsidmap[24736]: nss_getpwnam: name 
'us...@xx.xx.edu@XX.XX.EDU' does not map into domain 'XX.XX.EDU'
Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: nsswitch->name_to_uid 
returned -22
Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: final return value is 
-22
Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: calling 
nsswitch->name_to_uid

$
$ mount -v -t nfs4 -o sec=krb5 SP19SRV.XX.XX.EDU:/export /mnt
$ su userX
$ ls -la /mnt
total 4
drwxr-xr-x 5 nobody 4294967294 50 Feb 28 18:04 .
drwxr-xr-x 24 root root 4096 Mar 7 22:34 ..
drwxr-xr-x 2 nobody 4294967294 125 Mar 8 16:27 userX
$



Problem:
nfsmapid isn't showing proper file permissions on the ubuntu nfsv4 client with 
sec=krb



Client:
---
mount -v -t nfs4 -o sec=krb5 SP19SRV.XX.XX.EDU:/export /mnt
---
$ ls -la
total 4
drwxr-xr-x 5 nobody 4294967294 50 Feb 28 18:04 .
drwxr-xr-x 24 root root 4096 Mar 7 20:58 ..
drwxr-xr-x 2 nobody 4294967294 112 Mar 7 14:30 username
usern...@xx.xx.edu@ubuntuclient:/mnt

---
$ cat /etc/idmapd.conf

[General]

Verbosity = 9
Pipefs-Directory = /run/rpc_pipefs
# set your own domain here, if it differs from FQDN minus hostname
Domain = XX.XXX.EDU

[Mapping]

Nobody-User = nobody
Nobody-Group = nogroup

---
$ cat /etc/default/nfs-common
STATDOPTS=
NEED_GSSD="yes"
NEED_IDMAPD="yes"
# I've tried commenting out NEED_IDMAPD as well.
# I manually created the following file with ktutil to just have nfs lines.
RPCGSSDARGS="-k /etc/nfs.keytab"
# I've tried with and without the above line (this was shown from redhat 
documentaiton)
---

My nfs server is a Centos 7.

Both machines were joined to active directory with sssd. NFSv4 with krb 
security works on my centos server and client. The nfs server mount works on 
the ubuntu client and file permissions are honored. But, the ls -la command is 
showing the incorrect file permissions.



uid and gid's appear to be in sync from sssd. Note in /etc/sssd/sssd.conf 
ldap_id_mapping = False though I don't think that should matter since ids are 
the same on both client and server from the ldap attributes in AD.



Centos 7 servers /var/log/messages with idmapd.conf verbosity:

Mar 8 16:38:32 sp19srv rpc.idmapd[1224]: Server : (group) id "65534" -> name 
"nfsnob...@xx.xx.edu"
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=user
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: calling 
nsswitch->uid_to_name
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: 
nsswitch->uid_to_name returned 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: final return value 
is 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (user) id "3872" -> name 
"us...@xx.xx.edu@XX.XX.EDU"
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=group
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: calling 
nsswitch->gid_to_name
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: 
nsswitch->gid_to_name returned 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: final return value 
is 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (group) id "110" -> name 
"some group g...@xx.xx.edu@XX.XX.EDU"
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=user
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: calling 
nsswitch->uid_to_name
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: 
nsswitch->uid_to_name returned 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: final return value 
is 0
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (user) id "0" -> name 
"r...@xx.xx.edu"
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=group
Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: calling 

Bug#924050: poppler-utils: pdfsig segfaults on signed PDF

[Wesley Schwengle]

Package: poppler-utils
Version: 0.71.0-3
Severity: important

Dear Maintainer,

$ /usr/bin/pdfsig ~/Downloads/bar.pdf
Digital Signature Info of: /home/wesleys/Downloads/bar.pdf
Internal Error (0): Input couldn't be parsed as a CMS signature
zsh: segmentation fault  /usr/bin/pdfsig ~/Downloads/bar.pdf

Mar  8 22:28:30 neptune kernel: [ 8383.032122] pdfsig[13393]: segfault
at 0 ip 7fb1e04c96a1 sp 7fffe6c20b48 error 4 in
libc-2.28.so[7fb1e038f000+148000]

I was hoping to see more information about bar.pdf

I installed poppler from the git repo and then you get this:

$ pdfsig ~/Downloads/bar.pdf
Digital Signature Info of: /home/wesleys/Downloads/bar.pdf
Internal Error (0): Input couldn't be parsed as a CMS signature
Signature #1:
- Signer Certificate Common Name: (null)
- Signer full Distinguished Name: (null)
- Signing Time: Mar 08 2019 11:10:19
- Signing Hash Algorithm: unknown
- Signature Type: adbe.pkcs7.detached
- Signed Ranges: [0 - 12877], [40303 - 123158]
- Total document signed
- Signature Validation: Unknown Validation Failure.

$ pdfsig -v
pdfsig version 0.74.0
Copyright 2005-2019 The Poppler Developers - http://poppler.freedesktop.org
Copyright 1996-2011 Glyph & Cog, LLC

Could you upgrade to the latest version? Many thanks.

* ldd from Debian package
$ ldd /usr/bin/pdfsig
linux-vdso.so.1 (0x7ffd131f7000)
libpoppler.so.82 => /usr/lib/x86_64-linux-gnu/libpoppler.so.82 
(0x7fee16c4c000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fee16ac8000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fee16907000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 
(0x7fee1684b000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 
(0x7fee16805000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x7fee1659c000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fee1637c000)
libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x7fee1622e000)
libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so (0x7fee161ff000)
libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x7fee161be000)
libopenjp2.so.7 => /usr/lib/x86_64-linux-gnu/libopenjp2.so.7 
(0x7fee16167000)
liblcms2.so.2 => /usr/lib/x86_64-linux-gnu/liblcms2.so.2 (0x7fee1610a000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x7fee160cf000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x7fee1605)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fee1602f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fee15eac000)
/lib64/ld-linux-x86-64.so.2 (0x7fee16f65000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fee15e92000)
libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7fee15e53000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fee15e4a000)
libnssutil3.so => /usr/lib/x86_64-linux-gnu/libnssutil3.so (0x7fee15e18000)
libplc4.so => /usr/lib/x86_64-linux-gnu/libplc4.so (0x7fee15e11000)
libplds4.so => /usr/lib/x86_64-linux-gnu/libplds4.so (0x7fee15e0c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fee15e07000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fee15dfb000)
libwebp.so.6 => /usr/lib/x86_64-linux-gnu/libwebp.so.6 (0x7fee15b92000)
libzstd.so.1 => /usr/lib/x86_64-linux-gnu/libzstd.so.1 (0x7fee15af2000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fee15aca000)
libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x7fee158bc000)

* ldd from source
$ ldd $HOME/.local/bin/pdfsig
linux-vdso.so.1 (0x7ffcc1be8000)
libpoppler.so.85 => /home/wesleys/.local/lib/libpoppler.so.85 
(0x7f4091501000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f4091356000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f4091195000)
libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 
(0x7f40910d9000)
libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 
(0x7f4091093000)
libjpeg.so.62 => /usr/lib/x86_64-linux-gnu/libjpeg.so.62 (0x7f4090e2a000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f4090c0a000)
libcurl-gnutls.so.4 => /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 
(0x7f4090b7c000)
libopenjp2.so.7 => /usr/lib/x86_64-linux-gnu/libopenjp2.so.7 
(0x7f4090b25000)
liblcms2.so.2 => /usr/lib/x86_64-linux-gnu/liblcms2.so.2 (0x7f4090ac8000)
libpng16.so.16 => /usr/lib/x86_64-linux-gnu/libpng16.so.16 (0x7f4090a8f000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x7f4090a1)
libnss3.so => /usr/lib/x86_64-linux-gnu/libnss3.so (0x7f40908c)
libsmime3.so => /usr/lib/x86_64-linux-gnu/libsmime3.so (0x7f4090891000)
libnspr4.so => /usr/lib/x86_64-linux-gnu/libnspr4.so (0x7f409085)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f409082f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f40906ac000)
/lib64/ld-linux-x86-64.so.2 (0x7f40917f5000)
libgcc_s.so.1 => /lib/x86_64-li

Bug#924049: gnome-calendar: Cannot set gnome-calendar as default application in gnome-control-center

[Andrew Hayzen]

Package: gnome-calendar
Version: 3.30.1-2

On an install of Debian Buster when I open gnome-control-center I am
unable to set gnome-calendar as a the default calendar even though it
is installed. (I can however set Evolution or Thunderbird as the
default).

Bug#924048: ITP: shockolate -- System Shock game engine

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: shockolate
  Version : 0.7.5
  Upstream Author : Chad Cuddigan 
* URL : https://github.com/Interrupt/systemshock
* License : GPL-3+
  Programming Lang: C, C++
  Description : System Shock game engine

Shockolate is a source port of System Shock, based on the game engine
released by Night Dive Studios. It aims to preserve the original
gaming experience with a few improvements, such as an OpenGL renderer
and support for mods.
.
Shockolate requires the original game assets from the CD-ROM or
Enhanced Edition releases of System Shock. game-data-packager 64 and
greater can package the required files.


This will be packaged within the games team.

Bug#888572: git-buildpackage: creating xz tarballs should be done multi-threaded

[Carsten Schoenert]

Hello Guido,

On Tue, Jan 30, 2018 at 07:19:48AM +0100, Carsten Schoenert wrote:
> > We should not do more options. Multi threaded should be on when:
> > 
> >   - not using pristine-tar
> >   - iff pristine-tar can handle it
> > 
> > The first one is simple but what about the second?

the mentioned issue #888572 was closed some time ago so pristine-tar
shouldn't be a problem here anymore.

I will try to tweak gbp locally now again while working on a new version
of kicad-packages3d which will be about 5GB now to archive. ;)

Regards
Carsten

Bug#923609: proposed solution

[Niko Tyni]

On Fri, Mar 08, 2019 at 02:39:53PM +, Dmitry Bogatov wrote:
 
> I believe this patch would somewhat solve issue. Dear submitter, can you
> please apply this patch, build package and check, that `gdbm_load-nolfs'
> binary from created bin:gdbmtool does sensible thing?

Thanks. It doesn't quite work as-is, because 'future=+all' in
DEB_BUILD_MAINT_OPTIONS still pulls the LFS flags in the build. But if
I take that away, it works at least for my trivial databases (both GDBM
and NDBM). I'll try to test a bit more later.

It would make sense to limit this to 32-bit architectures as I believe the
64-bit architectures always have LFS support no matter the build flags.

Shipping these -nolfs binaries and including instructions for upgrading
databases in the Buster release notes would be an acceptable fix for
this issue IMO.

> By the way, can I somehow help to make autopkgtests on !amd64 happen?

I don't know; the debian-ci@ldo list is probably the best contact for that.

Thanks again,
-- 
Niko

Bug#923665: libmariadbclient-dev-compat: mysql_config

[Otto Kekäläinen]

Maybe there is something to improve in the documentation, Debian.README or
package descriptions in the control file?

I would be happy to get documentation merge requests on Salsa if you have
an idea what needs improvement.

Bug#924046: unblock: libvigraimpex/1.10.0+git20160211.167be93+dfsg1-2

[Andreas Tille]

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

Please unblock package libvigraimpex


diff -Nru libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/changelog 
libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/changelog
--- libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/changelog 
2018-12-27 22:30:27.0 +0100
+++ libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/changelog 
2019-03-08 18:40:38.0 +0100
@@ -1,3 +1,11 @@
+libvigraimpex (1.10.0+git20160211.167be93+dfsg1-2) unstable; urgency=medium
+
+  * Team upload.
+  * Replace sphinx.ext.pngmath by sphinx.ext.imgmath
+Closes: #923467
+
+ -- Andreas Tille   Fri, 08 Mar 2019 18:40:38 +0100
+
 libvigraimpex (1.10.0+git20160211.167be93+dfsg1-1) unstable; urgency=medium
 
   * Repackaged upstream tarball.
diff -Nru libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/patches/series 
libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/patches/series
--- libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/patches/series
2018-12-26 18:03:58.0 +0100
+++ libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/patches/series
2019-03-08 18:36:50.0 +0100
@@ -8,3 +8,4 @@
 const-swap.patch
 multi_convolution_fix_incomplete_template_paramater.patch
 link-with-pthread.patch
+sphinx.ext.pngmath.patch
diff -Nru 
libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/patches/sphinx.ext.pngmath.patch
 
libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/patches/sphinx.ext.pngmath.patch
--- 
libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/patches/sphinx.ext.pngmath.patch
  1970-01-01 01:00:00.0 +0100
+++ 
libvigraimpex-1.10.0+git20160211.167be93+dfsg1/debian/patches/sphinx.ext.pngmath.patch
  2019-03-08 18:40:04.0 +0100
@@ -0,0 +1,27 @@
+Description: Replace sphinx.ext.pngmath by sphinx.ext.imgmath to build with 
sphinx 1.8
+Bug-Debian: https://bugs.debian.org/923467
+Author: Andreas Tille 
+Last-Update: Fri, 08 Mar 2019 18:38:02 +0100
+
+--- a/vigranumpy/docsrc/conf.py.cmake2.in
 b/vigranumpy/docsrc/conf.py.cmake2.in
+@@ -59,7 +59,7 @@ os.environ['PATH'] = os.pathsep.join([vi
+ 
+ # Add any Sphinx extension module names here, as strings. They can be 
extensions
+ # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+-extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo', 'sphinx.ext.coverage', 
'sphinx.ext.pngmath']
++extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo', 'sphinx.ext.coverage', 
'sphinx.ext.imgmath']
+ 
+ # Add any paths that contain templates here, relative to this directory.
+ templates_path = ['_templates']
+--- a/vigranumpy/docsrc/conf.py.in
 b/vigranumpy/docsrc/conf.py.in
+@@ -58,7 +58,7 @@ os.environ['PATH'] = os.pathsep.join([vi
+ 
+ # Add any Sphinx extension module names here, as strings. They can be 
extensions
+ # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+-extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo', 'sphinx.ext.coverage', 
'sphinx.ext.pngmath']
++extensions = ['sphinx.ext.autodoc', 'sphinx.ext.todo', 'sphinx.ext.coverage', 
'sphinx.ext.imgmath']
+ 
+ # Add any paths that contain templates here, relative to this directory.
+ templates_path = ['_templates']


unblock libvigraimpex/1.10.0+git20160211.167be93+dfsg1-2

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

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

Bug#924047: FTBFS: package don't build successful after new GCC version

[Carsten Schoenert]

Package: src:systemc
Version: 2.3.3-1
Severity: grave

Hello Ahmed,

the systemc package is currently failing to build from source basically
related due a newer GCC version and changed symbols introduced by the
newer GCC.

I've fixed the reason of the FTBFS by modifying and adopting the
symbols file so the package is building again on all RC platforms. I've
pushed the adopted symbols file to Salsa after I've tested the builds.

If you can also have a look on a update of Standards-Version to 4.3.0 and
prepare a new changelog entry I can offer a sponsored upload.

I see no problem with a later unblock request so the updated package can
go into the Buster release.

Regards
Carsten

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/6 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#857228: Wayland vs X Windows

[Thomas L]

Hi!

Just to inform you that this bug is still present when installing Buster (with 
Gnome and Guake) from the Debian Buster DI alpha 5 DVD set.

Regards

Bug#924045: unblock: smcroute/2.4.2-4

[Micha Lenk]

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

We are not in full freeze yet, but according to the announced schedule, it
looks like 2.4.2-4 won't make it into buster even if uploaded yesterday. So,

please unblock package smcroute, because
* it fixes Debian bug #924044, broken init script not working for 'stop'
  command, which is a regression compared to the version in Debian stretch.
* it fixes Debian bug #921577, autopkgtests fail consistently, and some related
  issues with the autopkgtests (referenced as unit tests in the
  debian/changelog).

The proposed upload also contains rather cosmetic changes, i.e.
* Bumping the Debian policy version. This is hopefully acceptable because no
  source changes were needed.
* Removing all explicit maintainer scripts in favour of managing the snippets
  for moving the configuration file via debhelper. I personally checked that
  the resulting binary packages' maintainer scripts are bitwise identical after
  this change. So, hopefully this is acceptable too.

Because of the included cosmetic changes, the package isn't uploadede to
unstable yet. It is currently only available on mentors.d.n as
https://mentors.debian.net/debian/pool/main/s/smcroute/smcroute_2.4.2-4.dsc

unblock smcroute/2.4.2-4

Thank you for considering,
Micha
diff -Nru smcroute-2.4.2/debian/changelog smcroute-2.4.2/debian/changelog
--- smcroute-2.4.2/debian/changelog 2018-09-23 20:40:04.0 +
+++ smcroute-2.4.2/debian/changelog 2019-03-07 05:40:19.0 +
@@ -1,3 +1,16 @@
+smcroute (2.4.2-4) unstable; urgency=medium
+
+  * Import upstream fix for malfunctioning 'stop' command to init script
+  * Import upstream fix to allow same outbound interface as inbound when
+routing.  This is slightly hairy, but previous releases of SMCRoute
+supported this and the unit tests rely on this to work
+  * Fix unit tests, with upstream and test setup fixes, closes: #921577
+  * Bump Standards-Version to 4.3.0, no changes needed
+  * Use debhelper maintscript to relocate old /etc/startup.sh script
+to /etc/smcroute.  Fixes an outstanding lintian warning
+
+ -- Joachim Nilsson   Thu, 07 Mar 2019 06:40:19 +0100
+
 smcroute (2.4.2-3) unstable; urgency=medium
 
   * Add missing Build-Depends for systemd, needed for unit file path
diff -Nru smcroute-2.4.2/debian/control smcroute-2.4.2/debian/control
--- smcroute-2.4.2/debian/control   2018-09-21 19:54:23.0 +
+++ smcroute-2.4.2/debian/control   2019-03-07 05:40:19.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Joachim Nilsson 
 Build-Depends: debhelper (>= 10), libcap-dev, systemd, pkg-config
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Homepage: http://troglobit.com/smcroute.html
 Vcs-Browser: https://salsa.debian.org/debian/smcroute
 Vcs-Git: https://salsa.debian.org/debian/smcroute.git
diff -Nru smcroute-2.4.2/debian/gitlab-ci.yml 
smcroute-2.4.2/debian/gitlab-ci.yml
--- smcroute-2.4.2/debian/gitlab-ci.yml 1970-01-01 00:00:00.0 +
+++ smcroute-2.4.2/debian/gitlab-ci.yml 2019-03-07 05:40:19.0 +
@@ -0,0 +1,9 @@
+image: registry.salsa.debian.org/salsa-ci-team/ci-image-git-buildpackage:latest
+
+build:
+  artifacts:
+paths:
+- "*.deb"
+expire_in: 1 day
+  script:
+- gitlab-ci-git-buildpackage-all
diff -Nru 
smcroute-2.4.2/debian/patches/0004-Allow-same-outbound-interface-as-inbound.patch
 
smcroute-2.4.2/debian/patches/0004-Allow-same-outbound-interface-as-inbound.patch
--- 
smcroute-2.4.2/debian/patches/0004-Allow-same-outbound-interface-as-inbound.patch
   1970-01-01 00:00:00.0 +
+++ 
smcroute-2.4.2/debian/patches/0004-Allow-same-outbound-interface-as-inbound.patch
   2019-03-07 05:40:19.0 +
@@ -0,0 +1,96 @@
+commit 802d82eb5c571afe2a294fd302745bf37cc13a1d
+Author: Joachim Nilsson 
+Date:   Sun Feb 10 13:56:17 2019 +0100
+
+Allow same outbound interface as inbound, only warn user
+
+Routing back multicast to the same interface it ingressed on is
+quite a bit dangerous, but there may be use-cases where this is
+a requirement so we should not artificially limit the user.
+
+Also, allowing this means enabling unit testing on systems with
+only one interface.
+
+Signed-off-by: Joachim Nilsson 
+
+diff --git a/src/conf.c b/src/conf.c
+index 974871a..d1fbeed 100644
+--- a/src/conf.c
 b/src/conf.c
+@@ -31,6 +31,8 @@
+ #define MAX_LINE_LEN 512
+ #define DEBUG(fmt, args...)   \
+   smclog(LOG_DEBUG, "%s:%02d: " fmt, conf, lineno, ##args)
++#define INFO(fmt, args...)\
++  smclog(LOG_INFO, "%s:%02d: " fmt, conf, lineno, ##args)
+ #define WARN(fmt, args...)\
+   smclog(LOG_WARNING, "%s:%02d: " fmt, conf, lineno, ##args)
+ 
+@@ -166,13 +168,9 @@ static int add_mroute(int lineno, char *ifname, char 
*group, char *source, char
+   iface_match

Bug#921577: smcroute autopkgtests fail consistently

[Micha Lenk]

Control: severity -1 serious

Raising severity on behalf of the maintainer of smcroute, who prepared a 
fix and intends to fix this issue for Debian buster.


Regards,
Micha

Bug#921641: salsa: Please make hook event list configurable

[Xavier]

Le 08/03/2019 à 20:49, Xavier a écrit :
> Le 07/02/2019 à 16:18, Christoph Berg a écrit :
>> Package: devscripts
>> Version: 2.19.2
>> Severity: wishlist
>>
>> Hi,
>>
>> I would like to have "Job events" disabled in my KGB hooks. These
>> contain mostly the same information as "Pipeline events", but are much
>> more verbose.
>>
>> Christoph
> 
> You can find the diff here:
> https://salsa.debian.org/debian/devscripts/merge_requests/115/diffs
> 
> Thanks for reporting this!
> 
> Cheers,
> Xavier

Note also that "Job events" is disabled by default now.

Bug#924012: starpu build-depends on GCC 7

[Samuel Thibault]

Hello,

Matthias Klose, le ven. 08 mars 2019 11:32:36 +0100, a ecrit:
> starpu build-depends on GCC 7. Please switch to GCC 8, so that buster
> doesn't need to ship with GCC 7.

Matthias Klose, le ven. 08 mars 2019 11:27:29 +0100, a ecrit:
> starpu-contrib build-depends on GCC 7. Please switch to GCC 8, so that buster
> doesn't need to ship with GCC 7.

Well, it's a bit late in the release process... It happens that cuda
needs gcc 7 anyway.

Samuel

Bug#924044: init script does not stop the daemon

[Micha Lenk]

Package: smcroute
Version: 2.4.2-3
Severity: serious
Tags: patch upstream
Control: forwarded -1 https://github.com/troglobit/smcroute/pull/108

I am filing this bug on behalf of the current maintainer and upstream author of
smcroute, Joachim Nilsson, to create the necessary visibility for an issue
considered worth to be fixed for the Debian buster release. It was initially
filed by Hajo Noerenberg on upstream's Github repository as pull request 108.

> I'm using SMCRoute v2.4.2 (debian testing).
>
> The init script does not stop the daemon, an error is reported instead:
>
> # /etc/init.d/smcroute stop
> Stopping static multicast router daemon: smcrouted /usr/sbin/smcrouted: 
> invalid option -- 'k'
>
> I think one should use smcroutectl to stop the daemon.

The pull request is merged already, so the change is already part of the
upstream release 2.4.4.

Micha
commit 6f4e2c1ce8e0f6821e5254000ed43a4fd7744782
Author: hn 
Date:   Mon Jan 28 09:56:33 2019 +0100

fix init script 'stop' command

diff --git a/smcroute.init b/smcroute.init
old mode 100644
new mode 100755
index 00411b8..d0c7752
--- a/smcroute.init
+++ b/smcroute.init
@@ -18,6 +18,7 @@
 
 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
 DAEMON=/usr/sbin/smcrouted
+DAEMONCTL=/usr/sbin/smcroutectl
 DAEMON_OPTS=
 NAME=smcrouted
 DESC="static multicast router daemon"
@@ -50,7 +51,7 @@ stop() {
local error
local result
log_begin_msg "Stopping $DESC: $NAME"
-   error=$($DAEMON -k 2>&1)
+   error=$($DAEMONCTL kill 2>&1)
result=$?
log_progress_msg ${error#ERRO: }
log_end_msg $result

Bug#921641: salsa: Please make hook event list configurable

[Xavier]

Le 07/02/2019 à 16:18, Christoph Berg a écrit :
> Package: devscripts
> Version: 2.19.2
> Severity: wishlist
> 
> Hi,
> 
> I would like to have "Job events" disabled in my KGB hooks. These
> contain mostly the same information as "Pipeline events", but are much
> more verbose.
> 
> Christoph

You can find the diff here:
https://salsa.debian.org/debian/devscripts/merge_requests/115/diffs

Thanks for reporting this!

Cheers,
Xavier

Bug#499796: initscripts: rootfs over nfs hangs at reboot

[Pierre Ynard]

> On other hand, introducing REBOOT_OPTS in /etc/default/reboot is easy.
> Do we want it? Or we want to introduce more restricted version, NETDOWN,
> like in /etc/default/halt. Or maybe we want to reuse /etc/default/halt
> for `reboot' script?

My opinion is that /etc/init.d/reboot should honor NETDOWN, and source
it from /etc/default/halt. And then NETDOWN should be documented in
/etc/default/halt, as requested in #703844.

-- 
Pierre Ynard

Bug#924037: Please add anacron back to task-desktop and task-laptop

[Cyril Brulebois]

Hi Holger,

Holger Wansing  (2019-03-08):
> Since this is just a revert of a recent change, this can be considered
> causing no harm.
> 
> Any objections?
> kibi?

Sure, a revert looks good indeed; thanks!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#921607: mupdf shell script

[Mike]

the patch should be:

if [ "$file" = "" ]; then
-$cmd || true
+exec $cmd
else
-$cmd "$file" || true
+exec $cmd "$file" $2
fi

There is a start page param after the file:

usage: /usr/lib/mupdf/mupdf-x11 [options] file.pdf [page]

Bug#924043: tomb: tomb-kdb-pbkdf2 program not included

[Axel Beckert]

Package: tomb
Version: 2.5+dfsg1-2

The tomb(1) man page tells me the following:

For additional protection against dictionary attacks on keys, the
--kdf option can be used when forging a key, making sure that the
tomb-kdb-pbkdf2 binaries in extras/kdf were compiled and installed
on the system.

So far there seems no Debian package containing the command
tomb-kdb-pbkdf2, not even tomb.

And there is no "extra/kdf" in the source package of tomb, just
"extras/kdf-keys". But the Makefile in there clearly shows that it will
compile a bunch of "tomb-kdb-something" including "tomb-kdb-pbkdf2".

So please include at least those binaries from extras/kdf-keys so that
"tomb forge --kdf" can be used.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages tomb depends on:
ii  cryptsetup-bin  2:2.1.0-2
ii  e2fsprogs   1.44.6-1
ii  gnupg   2.2.13-1
ii  pinentry-curses [pinentry]  1.1.0-1+b1
ii  pinentry-fltk [pinentry]1.1.0-1+b1
ii  pinentry-gnome3 [pinentry]  1.1.0-1+b1
ii  pinentry-gtk2 [pinentry]1.1.0-1+b1
ii  pinentry-qt [pinentry]  1.1.0-1+b1
ii  pinentry-tty [pinentry] 1.1.0-1+b1
ii  sudo1.8.27-1
ii  zsh 5.7.1-1

tomb recommends no packages.

tomb suggests no packages.

-- no debconf information

Bug#924042: tomb: Multiple package relations for optionally used tools are missing (steghide, dcfldd, gettext-base, qrencode, unoconv, lsof, swish-e)

[Axel Beckert]

Package: tomb
Version: 2.5+dfsg1-2
Severity: serious

tomb's exhume subcommand calls steghide:

~ → tomb exhume /tmp/example.jpg
tomb [E] Steghide not installed: cannot exhume keys from images.
~ → dgrep steghide tomb
/usr/bin/tomb:  _deps=(gettext dcfldd shred steghide)
/usr/bin/tomb:  # Check for steghide
/usr/bin/tomb:  command -v steghide 1>/dev/null 2>/dev/null || STEGHIDE=0
/usr/bin/tomb:# Requires steghide(1) to be installed
/usr/bin/tomb:  | steghide embed --embedfile - --coverfile ${imagefile} 
\
/usr/bin/tomb:  _warning "Encoding error: steghide reports problems."
/usr/bin/tomb:  TOMBKEY=$(steghide extract -sf $imagefile -p $tombpass 
-xf -)
/usr/bin/tomb:  steghide extract -sf $imagefile -p ${tombpass} -xf $destkey

But steghide is neither in a Recommends or Suggests header.

And when looking at that grep output above, it becomes clear that there
are even more optional dependencies missing. Citing from tomb's source
code:

_list_optional_tools() {
typeset -a _deps
_deps=(gettext dcfldd shred steghide)
_deps+=(resize2fs tomb-kdb-pbkdf2 qrencode swish-e unoconv lsof)
for d in $_deps; do
_print "`which $d`"
done
return 0
}

So the following packages are missing in tomb's package relations. I
leave the package maintainers to decide, which of them go into Suggests
and which into Recommends:

* gettext-base: /usr/bin/gettext
* dcfldd: /usr/bin/dcfldd
* steghide: /usr/bin/steghide
* qrencode: /usr/bin/qrencode
* unoconv: /usr/bin/unoconv
* lsof: /usr/bin/lsof
* swish-e: /usr/bin/swish-e

Will file a separate bug report for the missing tomb-kdb-pbkdf2 binary.

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages tomb depends on:
ii  cryptsetup-bin  2:2.1.0-2
ii  e2fsprogs   1.44.6-1
ii  gnupg   2.2.13-1
ii  pinentry-curses [pinentry]  1.1.0-1+b1
ii  pinentry-fltk [pinentry]1.1.0-1+b1
ii  pinentry-gnome3 [pinentry]  1.1.0-1+b1
ii  pinentry-gtk2 [pinentry]1.1.0-1+b1
ii  pinentry-qt [pinentry]  1.1.0-1+b1
ii  pinentry-tty [pinentry] 1.1.0-1+b1
ii  sudo1.8.27-1
ii  zsh 5.7.1-1

tomb recommends no packages.

tomb suggests no packages.

-- no debconf information

Bug#914771: Re: Bug#914771: bundler: cannot load such file -- bundler-1.16.1/exe/bundle

[Antonio Terceiro]

On Fri, Mar 08, 2019 at 07:10:55PM +0100, Daniel Leidert wrote:
> Can we maybe change Gem.bin_path to fall back to /usr/bin or even $path?

Not at this point in the release cycle.


signature.asc
Description: PGP signature

Bug#923213: squid: Please disable the "Test apparmor" autopkgtest

[Paul Gevers]

Hi,

On 08-03-2019 09:38, Amos Jeffries wrote:
> On 8/03/19 6:58 am, Paul Gevers wrote:
>> On 07-03-2019 17:51, Luigi Gangitano wrote:
>>> 4.6-2 has just been uploaded with a fix for 923213. I really appreciate
>>> the opportunity to let it in Buster.
>>
>> Please file an unblock bug. I have one question about the proposed
>> solution: you preinst doesn't honor local changes if the package is
>> uninstalled (but not purged) and installed again AFAICT.
> 
> How so? the preinst script only installs the disable symlink and skips
> doing so if there is any existing profile. Everything else is done by
> the debhelper script.

Because it does $(ln -sf) during install, even if the admin removed that
link manually. If the package wasn't purged, the package must honor
those changes by the admin in /etc/.

> This particular chunk of the change is taken verbatim from what Ubuntu
> have been using for years without an issue coming up.

That may be true, it doesn't mean it is policy correct.

On top of that, the autopkgtest fails, so you didn't fix it correctly.

I suggest to revert the changes in the latest upload, disable the
failing test, and I'll unblock the package (so the only delta with
testing should be the disabled test).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#924037: Please add anacron back to task-desktop and task-laptop

[john doe]

On 3/8/2019 7:17 PM, Holger Wansing wrote:
> Hi,
>
> Ian Jackson  wrote:
>> Package: task-desktop
>> Version: 3.49
>>
>> The rationale for this change is IMO not correct.
>>
>> Michael Biebl  wrote:
>> | all important cron jobs have a corresponding .timer unit
>>
>> This is not a sufficient condition.  Firstly, it is necessary for all
>> cron jobs, not just ones considered `important', to have a
>> corresponding timer unit, for this change to be correct.
>>
>> Secondly, this change simply breaks systems without systemd.  If
>> (which I deny) it is a good idea to change this for systemd systems,
>> measures should be taken to arrange that non-systemd systems still get
>> anacron.  For example, a dependency on   systemd-sysv | anacron
>>
>> (Thirdly, and tangentially, for reasons explored further in the
>> debian-devel thread, systemd timer units are not a suitable
>> replacement for many applications.)
>>
>> Also I think that when changes are being made which might break
>> non-systemd systems, the Debian Ecosystem Init Diversity team
>>  debian-init-divers...@chiark.greenend.org.uk
>> should be consulted so that the appropriate fixes can be developed.
>
> I tend to follow this proposal (also looking at the corresponding
> discussion on d-devel).
>
>> Finally, this change is rather late wrt the freeze.
>
> Since this is just a revert of a recent change, this can be considered
> causing no harm.
>
>
> Any objections?
> kibi?
>

I'm probably missing something here, this change have never had the
green light to go ahead in the first place.

--
John Doe

Bug#924041: tvtime(1) man page: bad path in FILES

[Jakub Wilk]

Package: tvtime
Version: 1.0.11-4

The first item in the FILES section of the tvtime(1) manual page is:

  /tvtime/tvtime.xml

This file doesn't exist of course. I think it should be:

  /etc/tvtime/tvtime.xml

--
Jakub Wilk

Bug#659937: initscripts: Wheezy on Dual boot configuration shows wrong time Date: Wed, 15 Feb 2012 08:21:34 +0100

[Pierre Ynard]

tags 659937 moreinfo
thanks

The UTC variable is not in use anymore - /etc/adjtime is used now. I'm
pretty sure this issue is not within the scope of initscripts.

What do the commands `hwclock --show` and `date -R` return? What do the
files /etc/adjtime and /etc/timezone contain?

> Installation has not been through new installation but through
> dist-upgrade from squeeze to wheezy.

Did the problem appear only after the migration, was the time fine
before? Does the problem still persist in any way now, or is it solved?
If so, there's not much we can do now about an old migration problem.

-- 
Pierre Ynard

Bug#924040: ITP: archivebox -- open source self-hosted web archive

[Antoine Beaupre]

Package: wnpp
Severity: wishlist
Owner: Antoine Beaupre 

* Package name: archivebox
  Version : 0.2.4
  Upstream Author : Nick Sweeting
* URL : https://archivebox.io/
* License : MIT/Expat?
  Programming Lang: Python
  Description : open source self-hosted web archive

ArchiveBox takes a list of website URLs you want to archive, and
creates a local, static, browsable HTML clone of the content from
those websites (it saves HTML, JS, media files, PDFs, images and
more).

You can use it to preserve access to websites you care about by
storing them locally offline. ArchiveBox works by rendering the pages
in a headless browser, then saving all the requests and fully loaded
pages in multiple redundant common formats (HTML, PDF, PNG, WARC) that
will last long after the original content dissapears off the
internet. It also automatically extracts assets like git repositories,
audio, video, subtitles, images, and PDFs into separate files using
youtube-dl, pywb, and wget.

ArchiveBox doesn’t require a constantly running server or backend,
instead you just run the ./archive command each time you want to
import new links and update the static output. It can import and
export JSON (among other formats), so it’s easy to script or hook up
to other APIs. If you run it on a schedule and import from browser
history or bookmarks regularly, you can sleep soundly knowing that the
slice of the internet you care about will be automatically preserved
in multiple, durable long-term formats that will be accessible for
decades (or longer).



I'm not using this just yet because the upstream packaging is somewhat
weird right now.

https://github.com/pirate/ArchiveBox/issues/120#issuecomment-471027516

It's eventually going to end up on pypi, at which point i'll look at
packaging this myself.

There are, as far as I know, no similar tool in Debian right
now. There are web crawlers and grabbers, but nothing as comprehensive
as this.

I'd be happy to co-maintain this or delegate to whoever is interested.

Bug#923665: libmariadbclient-dev-compat: mysql_config

[Marc Lehmann]

On Sun, Mar 03, 2019 at 03:48:06PM +0200, Otto Kekäläinen  
wrote:
> The script mariadb_config is in package libmariadb-dev and mysql_config in
> libmariadb-dev-compat.
> 
> https://packages.debian.org/search?mode=path&suite=sid§ion=all&arch=hurd-i386&searchon=contents&keywords=mysql_config

Hm... indeed, sorry for thinking this was missing and wasting
your time then - I guess I was confused by the multitude of
lib{mariadb|mysql][client]* packages then, and this can be closed.

-- 
The choice of a   Deliantra, the free code+content MORPG
  -==- _GNU_  http://www.deliantra.net
  ==-- _   generation
  ---==---(_)__  __   __  Marc Lehmann
  --==---/ / _ \/ // /\ \/ /  schm...@schmorp.de
  -=/_/_//_/\_,_/ /_/\_\

Bug#914771: AW: Re: Bug#914771: bundler: cannot load such file -- bundler-1.16.1/exe/bundle

[Daniel Leidert]

Can we maybe change Gem.bin_path to fall back to /usr/bin or even $path?

Regards, Daniel 

Bug#924010: wmbiff: Built without TLS support

[Andreas Metzler]

On 2019-03-08 Yavor Doganov  wrote:
> Package: wmbiff
> Version: 0.4.33-1
> Severity: serious
> Tags: patch

> IMHO any sane mail checker should support TLS:

> $ wmbiff
> This copy of wmbiff was not compiled with gnutls;
> imaps is unavailable.  Exiting to protect your
> passwords and privacy.

> Looking at the build log:

> | checking for gzopen in -lz... no
> | GNUTLS support requires libz.a and libgdbm.a

> The attached trivial patch fixes it.
[...]

Actually ./configure seems to wrong, GNUTLS suppport does not require
libz.a and libgdbm.a (anymore).

cu Andreas

Bug#924037: Please add anacron back to task-desktop and task-laptop

[Holger Wansing]

Hi,

Ian Jackson  wrote:
> Package: task-desktop
> Version: 3.49
> 
> The rationale for this change is IMO not correct.
> 
> Michael Biebl  wrote:
> | all important cron jobs have a corresponding .timer unit
> 
> This is not a sufficient condition.  Firstly, it is necessary for all
> cron jobs, not just ones considered `important', to have a
> corresponding timer unit, for this change to be correct.
> 
> Secondly, this change simply breaks systems without systemd.  If
> (which I deny) it is a good idea to change this for systemd systems,
> measures should be taken to arrange that non-systemd systems still get
> anacron.  For example, a dependency on   systemd-sysv | anacron
> 
> (Thirdly, and tangentially, for reasons explored further in the
> debian-devel thread, systemd timer units are not a suitable
> replacement for many applications.)
> 
> Also I think that when changes are being made which might break
> non-systemd systems, the Debian Ecosystem Init Diversity team
>  debian-init-divers...@chiark.greenend.org.uk
> should be consulted so that the appropriate fixes can be developed.

I tend to follow this proposal (also looking at the corresponding
discussion on d-devel).

> Finally, this change is rather late wrt the freeze.

Since this is just a revert of a recent change, this can be considered
causing no harm.


Any objections?
kibi?


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#470956: initscripts: checkroot.sh shouldn't fsck twice with /forcefsck

[Adrian Bunk]

Control: tags -1 -moreinfo

On Fri, Mar 08, 2019 at 04:53:41PM +, Pierre Ynard wrote:
> severity 470956 minor
> tags 470956 moreinfo
> thanks
> 
> > I am aware that fsck of ext2 isn't fast, but that's not a reason for
> > doing it needlessly *twice* when the first fsck gave an error <= 3.
> >
> > What happened was:
> > $ shutdown -F -r now
> > # computer reboots
> > # fsck of root fs
> < # fsck.ext2 returned error 3 (most likely since it optimized directories)
> > # computer automatically reboots  (everything works as expected until now)
> > # fsck of root fs  *grrr*
> 
> I don't see how the system itself could guarantee between the two boots
> that the filesystem is still clean the second time. Another OS could
> have been booted instead, used the filesystem and left it dirty. The
> device could have been swapped in and out of the machine, and mounted by
> another system, etc...
> 
> Even we wanted initscripts to set up some flag for the next reboot,
> that's not really possible because the filesystem is still read-only
> at this point, and really shouldn't be touched anymore until after the
> reboot.
> 
> I suppose that if anything could be done about this, it would be by fsck
> utilities in the filesystem internal attributes. But I don't know which
> filesystem types would be concerned by this issue and if they would
> allow to address it. Ted, what do you think about this?

The logical fix would be to mark the filesystem as clean since all
errors have been corrected.

If anything, the kernel should not mark it clean again if it gets 
mounted rw and then unmounted again before a reboot.

> Pierre Ynard

cu
Adrian

-- 

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

Bug#923270: bluetooth: When connect audio slave on system , try to guess

[Corcodel Marian]

Package: bluez
Version: 5.43-2+deb9u1
Followup-For: Bug #923270

I send 2 patches first try to fix ambigous compatation and second patches fix
incorrect senders on my case from 4 senders remain 3 on dbus



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

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

Versions of packages bluez depends on:
ii  dbus 1.10.26-0+deb9u1
ii  init-system-helpers  1.48
ii  kmod 23-2
ii  libc62.24-11+deb9u4
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libreadline7 7.0-3
ii  libudev1 232-25+deb9u8
ii  lsb-base 9.20161125
ii  udev 232-25+deb9u8

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  10.0-1+deb9u1

-- no debconf information
Author: Corcodel Marian 

Last-Update: 2019-03-05

--- bluez-5.43.orig/src/device.c
+++ bluez-5.43/src/device.c
@@ -1749,10 +1749,7 @@ static uint8_t select_conn_bearer(struct
time_t bredr_last = NVAL_TIME, le_last = NVAL_TIME;
time_t current = time(NULL);
 
-   /* Prefer bonded bearer in case only one is bonded */
-   if (dev->bredr_state.bonded && !dev->le_state.bonded )
-   return BDADDR_BREDR;
-   else if (!dev->bredr_state.bonded && dev->le_state.bonded)
+   if (dev->le_state.bonded)
return dev->bdaddr_type;
 
/* If the address is random it can only be connected over LE */
@@ -2393,10 +2390,8 @@ static DBusMessage *pair_device(DBusConn
return btd_error_in_progress(msg);
 
if (device->bredr_state.bonded)
-   bdaddr_type = device->bdaddr_type;
-   else if (device->le_state.bonded)
bdaddr_type = BDADDR_BREDR;
-   else
+   else if (device->le_state.bonded)
bdaddr_type = select_conn_bearer(device);
 
state = get_state(device, bdaddr_type);
Author: Corcodel Marian
Last-Update: 2019-03-08

--- bluez-5.43.orig/src/device.c
+++ bluez-5.43/src/device.c
@@ -2371,8 +2371,8 @@ static void bonding_request_free(struct
 static DBusMessage *pair_device(DBusConnection *conn, DBusMessage *msg,
void *data)
 {
-   struct btd_device *device = data;
-   struct btd_adapter *adapter = device->adapter;
+   struct btd_device *device;
+   struct btd_adapter *adapter;
struct bearer_state *state;
uint8_t bdaddr_type;
const char *sender;
@@ -2381,10 +2381,11 @@ static DBusMessage *pair_device(DBusConn
uint8_t io_cap;
int err;
 
-   btd_device_set_temporary(device, false);
-
if (!dbus_message_get_args(msg, NULL, DBUS_TYPE_INVALID))
return btd_error_invalid_args(msg);
+   device = data;
+   adapter = device->adapter;
+   btd_device_set_temporary(device, false);
 
if (device->bonding)
return btd_error_in_progress(msg);

Bug#470956: initscripts: checkroot.sh shouldn't fsck twice with /forcefsck

[Pierre Ynard]

Oh sorry, I hadn't fully realized that as indicated by the title, this
was with /forcefsck set. In that case, as I said, since the filesystem
is still read-only, the /forcefsck flag can't be cleared - nor should
it be cleared at this point, because it covers all mounts and not just
root.

So an alternative interface to creating a /forcefsck file would have to
be used, one that doesn't reside on the filesystem itself and can be set
and cleared for individual filesystems separately - for example, the
filesystem internal data.

-- 
Pierre Ynard

Bug#924039: RFS: fonts-myanmar/0.1-1 [ITP, NMU]

[Ko Ko Ye`]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,
I am looking for a sponsor for my package "fonts-myanmar"

 * Package name: fonts-myanmar
   Version : 0.1-1
   Upstream Author : kokoye2007 
 * URL : https://salsa.debian.org/kokoye2007-guest/fonts-myanmar/
 * License : GPL3
   Section : fonts

  It builds those binary packages:

fonts-myanmar - Myanmar fonts collection
fonts-myanmar-zawgyi - Myanmar font Zawgyi One v2008;
fonts-myanmar-myanmar3 - Myanmar fonts Myanmar3
fonts-myanmar-myanmarcensus - Myanmar fonts Myanmar Census
fonts-myanmar-pyidaungsu - fonts Pyidaungsu
fonts-myanmar-unicode - Myanmar Unicode fonts
fonts-myanmar-ayar - Myanmar fonts ayar
fonts-myanmar-angoun - Myanmar fonts angoun
fonts-myanmar-chatulight - Myanmar fonts chatulight
fonts-myanmar-chatu - Myanmar fonts chatu
fonts-myanmar-gantgaw - Myanmar fonts gantgaw
fonts-myanmar-khyay - Myanmar fonts khyay
fonts-myanmar-kuttar - Myanmar fonts kuttar
fonts-myanmar-nayone - Myanmar fonts nayone
fonts-myanmar-njaun - Myanmar fonts njaun
fonts-myanmar-pauklay - Myanmar fonts pauklay
fonts-myanmar-phetsot - Myanmar fonts phetsot
fonts-myanmar-phikselsmooth - Myanmar fonts phikselsmooth
fonts-myanmar-phiksel - Myanmar fonts phiksel
fonts-myanmar-ponenyet - Myanmar fonts ponenyet
fonts-myanmar-sabae - Myanmar fonts sabae
fonts-myanmar-sagar - Myanmar fonts sagar
fonts-myanmar-sanpya - Myanmar fonts sanpya
fonts-myanmar-squarelight - Myanmar fonts squarelight
fonts-myanmar-tagu - Myanmar fonts tagu
fonts-myanmar-thuriya - Myanmar fonts thuriya
fonts-myanmar-waso - Myanmar fonts waso
fonts-myanmar-yinmar - Myanmar fonts yinmar
fonts-myanmar-myanmarsanspro - Myanmar fonts Myanmar Sans Pro
fonts-myanmar-namkhone - Myanmar shan fonts Namkhone
fonts-myanmar-mon - Myanmar mon fonts MON3 Anonta 1

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

  https://mentors.debian.net/package/fonts-myanmar


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fonts-myanmar/fonts-myanmar_0.1-1.dsc

More information about fonts-myanmar can be obtained from

https://code.launchpad.net/~kokoye2007/ttf-burmese-fonts/ttf-burmese-fonts

https://salsa.debian.org/kokoye2007-guest/fonts-myanmar/

  Changes since the last upload:
* Follow DFSG and Social Contract
* Package is lintian clean
* Package is not native
* upstream version
* working watch / uscan
* working at Ubuntu PPA
* working debian installer / build deb

  Regards,
   kokoye2007

-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#923976: [Pkg-puppet-devel] Bug#923976: Bug#923976: puppet: Reports submitte

[Kienan Stewart]

Hi,

I have made a patch which seems to resolve the issue. I'm not at all confident
it's in the right place. The patch applies to the PuppetDB source which is used
to make the puppet-terminus-puppetdb package.

diff --git a/puppet/lib/puppet/reports/puppetdb.rb 
b/puppet/lib/puppet/reports/puppetdb.rb
index d3f0c07..b78f02c 100644
--- a/puppet/lib/puppet/reports/puppetdb.rb
+++ b/puppet/lib/puppet/reports/puppetdb.rb
@@ -129,7 +129,7 @@ Puppet::Reports.register_report(:puppetdb) do
 [:puppetdb, :metrics_list, :build]) do
   metrics_list = []
   metrics.each do |name, data|
-metric_hashes = data.values.map {|x| {"category" => data.name, "name" 
=> x.first, "value" => x.last}}
+metric_hashes = data.values.map {|x| {"category" => data.name, "name" 
=> x.first, "value" => x.last.to_f}}
 metrics_list.concat(metric_hashes)
   end
   metrics_list

I'm not aware if there will be consequences to forcing all the metrics values to
floats.

Thanks,
Kienan


signature.asc
Description: PGP signature

Bug#924038: runit: Can't start emergency shell in recovery mode

[Lorenzo Puliti]

Package: runit
Version: 2.1.2-23
Severity: normal
Tags: patch



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
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 runit depends on:
ii  libc6   2.28-8
ii  runit-helper2.8.7
ii  sysuser-helper  1.3.3

Versions of packages runit recommends:
ii  runit-init  2.1.2-23

runit suggests no packages.

-- Configuration Files:
/etc/runit/2 changed [not included]
/etc/runit/3 changed [not included]

-- no debconf information

Hi Dmitry,

When I select 'recovery mode' from the grub menu the emergency shell
doesn't start with the following error 

chpst: fatal: unable to run: sulogin: file does not exist

then the boot continues and all services are started.
It looks like chpst doesn't care about PATH variable and it need a 'env'
command or the full path of the sulogin shell.
The attached patch exec sulogin shell with full path in stage 2.

Thanks,
Lorenzo
>From 47aec318eed051da62ed80f6dac5ede87962acb2 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti 
Date: Fri, 8 Mar 2019 16:48:44 +0100
Subject: [PATCH] Stage 2: use full path for sulogin

Use full path when executing emergency shell in stage 2
---
 debian/contrib/2 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/contrib/2 b/debian/contrib/2
index 8569963..31da5e9 100755
--- a/debian/contrib/2
+++ b/debian/contrib/2
@@ -9,7 +9,7 @@ SVDIR=/etc/service
 if [ -f /run/runit.stopit ] ; then
# single mode
if grep -q -w -i 'single' /proc/cmdline ; then
-   chpst -P sulogin -p /dev/tty1
+   chpst -P /sbin/sulogin -p /dev/tty1
fi
 
 
-- 
2.20.1

Bug#743555: initscripts: command "halt" unintended changed behaviour

[Jesse Smith]

On 3/8/19 12:46 PM, Pierre Ynard wrote:
>> 2. The user runs /sbin/halt without the "-p" flag. This runs
>> /sbin/shutdown -h. INIT_HALT is not set. The /etc/init.d/halt script
>> checks /etc/defaults/halt to see whether it should poweroff or simply
>> stop.
> Yes, but Steve says that /sbin/halt without the "-p" flag should
> definitely call /sbin/shutdown -h -H and always halt without poweroff
> regardless of /etc/default/halt, which is in contradiction with what the
> new version does as you just explained.
>

When /sbin/halt is called without the -p flag, it should call
/sbin/shutdown -h. It should not (and does not) call /sbin/shutdown -h
-H. This is described in the halt(8) manual page. It should _not_ halt
the system regardless of the what is in /etc/defaults/halt.

- Jesse

Bug#923273: [pkg-apparmor] Bug#923273: apparmor: nvidia_modprobe named profile is shipped in complain mode

[Vincas Dargis]

On Fri, 08 Mar 2019 09:13:55 +0100 intrigeri  wrote:

What's the actual impact of this bug? Any user-visible problem?
Makes other profiles useless under their threat model?


nvidia_modprobed is used by LibreOffice profile - it includes `opencl-nvidia` for OpenCL features in 
LibreOffice Calc, and in the end, the `nvidia-modprobe` executable is allowed.


Since LibreOffice is in complain mode by default, so I doubt this issue reduces security for default 
Debian installation, only for users that enforces LibreOffice profile have reduced confinement 
expectations.


No user-visible problems is seen.

nvidia-modprobe is setuid application, and having `nvidia_modrpobe` in enforced mode by default 
would reduce attack vectors against LibreOffice, but again, only for users that enforces LO profile.

Bug#924037: Please add anacron back to task-desktop and task-laptop

[Ian Jackson]

Package: task-desktop
Version: 3.49

The rationale for this change is IMO not correct.

Michael Biebl  wrote:
| all important cron jobs have a corresponding .timer unit

This is not a sufficient condition.  Firstly, it is necessary for all
cron jobs, not just ones considered `important', to have a
corresponding timer unit, for this change to be correct.

Secondly, this change simply breaks systems without systemd.  If
(which I deny) it is a good idea to change this for systemd systems,
measures should be taken to arrange that non-systemd systems still get
anacron.  For example, a dependency on   systemd-sysv | anacron

(Thirdly, and tangentially, for reasons explored further in the
debian-devel thread, systemd timer units are not a suitable
replacement for many applications.)

Also I think that when changes are being made which might break
non-systemd systems, the Debian Ecosystem Init Diversity team
 debian-init-divers...@chiark.greenend.org.uk
should be consulted so that the appropriate fixes can be developed.

Finally, this change is rather late wrt the freeze.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#470956: initscripts: checkroot.sh shouldn't fsck twice with /forcefsck

[Pierre Ynard]

severity 470956 minor
tags 470956 moreinfo
thanks

> I am aware that fsck of ext2 isn't fast, but that's not a reason for
> doing it needlessly *twice* when the first fsck gave an error <= 3.
>
> What happened was:
> $ shutdown -F -r now
> # computer reboots
> # fsck of root fs
< # fsck.ext2 returned error 3 (most likely since it optimized directories)
> # computer automatically reboots  (everything works as expected until now)
> # fsck of root fs  *grrr*

I don't see how the system itself could guarantee between the two boots
that the filesystem is still clean the second time. Another OS could
have been booted instead, used the filesystem and left it dirty. The
device could have been swapped in and out of the machine, and mounted by
another system, etc...

Even we wanted initscripts to set up some flag for the next reboot,
that's not really possible because the filesystem is still read-only
at this point, and really shouldn't be touched anymore until after the
reboot.

I suppose that if anything could be done about this, it would be by fsck
utilities in the filesystem internal attributes. But I don't know which
filesystem types would be concerned by this issue and if they would
allow to address it. Ted, what do you think about this?

-- 
Pierre Ynard

Bug#924036: statsmodels: autopkgtest regression on armhf

[Graham Inggs]

Source: statsmodels
Version: 0.8.0-8
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Hi Maintainer

Since the changes in 0.8.0-8, statsmodels fails its autopkgtests on
armhf, as can be seen in Ubuntu [1].

The tests that are skipped during the build [2], should be skipped
during autopkgtests as well.

Regards
Graham


[1] http://autopkgtest.ubuntu.com/packages/s/statsmodels/disco/armhf
[2] 
https://salsa.debian.org/science-team/statsmodels/commit/282b71a50e6968da44a46e41bb68870817670d70

Bug#923976: [Pkg-puppet-devel] Bug#923976: Bug#923976: puppet: Reports submitte

[Kienan Stewart]

Hi,

I've been digging around a bit more and I think I have an idea to help narrow
the conditions in which I'm seeing this error.

I re-configured a test box to output the report to disk and to PuppetDB so I
was able to compare the data sent.

I see a correlation between time metrics stored a Ruby.BigNumber and all the
failed metrics when trying store the report in PuppetDB. Since the metrics
values with differ from run to run, it could be possible to have runs which
are able to be stored without this specific error.

A summary comparison table is available in the attachment 
reports-errors-summary.tsv.

To produce this I took the error line from the PuppetDB log 
(report-puppetdb_error.log)
where traceback lists details of "value does not match schema"

:cause "Value does not match schema: {:metrics [nil nil nil nil nil nil nil 
nil nil nil nil nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil nil nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil nil nil nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil nil nil nil {:value (not (instance? java.lang.Number 
a-java.lang.String))} nil nil nil nil nil]}"


Each nil value I assumed to be not an error. I lined these values up in 
appearance
order with the metrics data from the same log. (I won't paste the entire line 
here
since it's quite long).

I then got the corresponding value from the report stored on disk (attached
as report-stored.yaml).

Note: for these reports I was using our puppetmaster manifest, so there are more
resource metrics than on an example with an empty manifest.

Thanks,
Kienan

resourceschanged1nil
resourcescorrective_change1nil 
resourcesfailed0nil 
resourcesfailed_to_restart0nil 
resourcesout_of_sync1nil 
resourcesrestarted0nil 
resourcesscheduled0nil 
resourcesskipped0nil 
resourcestotal715nil 
timealternatives0.023357004nil 
timeanchor8.95E-04nil 
timeaugeas0.089786623nil 
timecatalog_application4.96E+00{:value (not (instance? java.lang.Number a-java.lang.String))}ruby/object:BigDecimal27:0.49594088389994795e1
timeconcat_file0.001357939nil 
timeconcat_fragment5.54E-03{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal36:0.553882705e2
timeconfig_retrieval7.15E+00{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal27:0.7151159435435e1
timeconvert_catalog0.544536797000546nil 
timecron0.014934991nil 
timeexec0.020149716nil 
timefact_generation2.20E+00{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal27:0.21955279620005967e1
timefile1.173581222nil 
timefile_line2.55E-02{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal36:0.255076198e1
timefilebucket1.11E-04nil 
timegroup7.41E-04nil 
timeini_setting1.27E-02{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal36:0.126739428e1
timemailalias5.89E-04nil 
timenode_retrieval6.56E+00{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal27:0.6560879654185e1
timepackage0.009044969nil 
timeplugin_sync1.49E+00{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal27:0.1485196431767e1
timepostgresql_conf3.16E-04{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal36:0.315886003e3
timepostgresql_conn_validator0.054996048nil 
timepostgresql_psql1.220987548nil 
timepuppetdb_conn_validator0.033792702nil 
timeresources6.83E-05nil 
timeservice2.94E-01{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal27:0.2937224029997e0
timessh_authorized_key0.0013181nil 
timesshkey8.07E-04nil 
timetotal22.909333186nil 
timetransaction_evaluation4.70985980499972nil 
timeuser3.47E-02{:value (not (instance? java.lang.Number a-java.lang.String))} ruby/object:BigDecimal36:0.346835945e1
timevcsrepo0.055521215nil 
changestotal1nil 
eventsfailure0nil 
eventssuccess1nil 
eventstotal1nil

2019-03-08T11:03:59.479-05:00 INFO  [p.p.command] [16-1552061039324] [86 ms] 
'replace facts' command processed for pm-buster.test
2019-03-08T11:04:05.158-05:00 INFO  [p.p.command] [17-1552061044601] [178 ms] 
'replace catalog' command processed for pm-buster.test
2019-03-08T11:04:12.519-05:00 ERROR [p.p.command] [18] [store report] Fatal 
error on attempt 0 for pm-buster.test
clojure.lang.ExceptionInfo: throw+: {:fatal true, :cause #error {
 :cause "Value does not match

Bug#743555: initscripts: command "halt" unintended changed behaviour

[Pierre Ynard]

> 2. The user runs /sbin/halt without the "-p" flag. This runs
> /sbin/shutdown -h. INIT_HALT is not set. The /etc/init.d/halt script
> checks /etc/defaults/halt to see whether it should poweroff or simply
> stop.

Yes, but Steve says that /sbin/halt without the "-p" flag should
definitely call /sbin/shutdown -h -H and always halt without poweroff
regardless of /etc/default/halt, which is in contradiction with what the
new version does as you just explained.

-- 
Pierre Ynard

Bug#924035: libvirt-daemon: Unable to complete lxc guest shutdown: Failed to delete veth device

[Matthew Gabeler-Lee]

Package: libvirt-daemon
Version: 5.0.0-1
Severity: normal

Dear Maintainer,

Since a recent upgrade (I _think_ this showed up when libvirt 5.0 migrated
to buster, but I'm not entirely sure of that.  It could also be related to
the 4.20 kernel, which is the minimum version needed to support the onboard
graphics in my coffee lake system), I can no longer fully shut down lxc
guests.  I can't trigger a guest shutdown externally, but that is not the
bug I'm reporting here.  If I trigger the guest shutdown from within the
guest, the guests shuts down, and the parent libvirt_lxc process exits, but
the libvirt daemon then hits an error, which is logged thus:

2019-03-08 16:14:00.548+: 17612: error : virNetDevVethDelete:210 : internal 
error: Failed to delete veth device vnet3

(the vnet device number of course changes over time / guest)

At this point I can neither force shut down the guest, nor can I restart it. 
My ownly recourse is to restart the libvirt daemon (reload is insufficient). 
A restart _does_ work, but it disconnects all clients, and I've had bad
experiences in the past with such actions putting libvirt / guests into a
bad state, e.g.  having two copies of every lxc guest running, one of which
has become completely dissociated from the libvirt daemon, with chaotic and
deleterious effect.

Note: this does _not_ affect qemu guests.

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

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

Versions of packages libvirt-daemon depends on:
ii  libacl1 2.2.52-5
ii  libapparmor12.13.2-7
ii  libaudit1   1:2.8.4-2
ii  libavahi-client30.7-4+b1
ii  libavahi-common30.7-4+b1
ii  libblkid1   2.33.1-0.1
ii  libc6   2.28-7
ii  libcap-ng0  0.7.9-2
ii  libcurl3-gnutls 7.64.0-1
ii  libdbus-1-3 1.12.12-1
ii  libdevmapper1.02.1  2:1.02.155-2
ii  libfuse22.9.9-1
ii  libgcc1 1:8.2.0-21
ii  libgnutls30 3.6.6-2
ii  libnetcf1   1:0.2.8-1+b2
ii  libnl-3-200 3.4.0-1
ii  libnl-route-3-200   3.4.0-1
ii  libnuma12.0.12-1
ii  libparted2  3.2-24
ii  libpcap0.8  1.8.1-6
ii  libpciaccess0   0.14-1
ii  libsasl2-2  2.1.27+dfsg-1
ii  libselinux1 2.8-1+b1
ii  libssh2-1   1.8.0-2
ii  libudev1240-6
ii  libvirt05.0.0-1
ii  libxenmisc4.11  4.11.1-1
ii  libxenstore3.0  4.11.1-1
ii  libxentoollog1  4.11.1-1
ii  libxml2 2.9.4+dfsg1-7+b3
ii  libyajl22.1.0-3

Versions of packages libvirt-daemon recommends:
ii  libxml2-utils   2.9.4+dfsg1-7+b3
ii  netcat-openbsd  1.195-2
ii  qemu1:3.1+dfsg-4
ii  qemu-kvm1:3.1+dfsg-4

Versions of packages libvirt-daemon suggests:
pn  libvirt-daemon-driver-storage-gluster  
pn  libvirt-daemon-driver-storage-rbd  
pn  libvirt-daemon-driver-storage-zfs  
ii  libvirt-daemon-system  5.0.0-1
pn  numad  

-- no debconf information

Bug#743555: initscripts: command "halt" unintended changed behaviour

[Jesse Smith]

This topic always gets confusing because so many different components
have the same name (halt). And how they behave will vary slightly,
depending on which version you use.

In the past, if you called /sbin/halt (with or without the -p flag), it
would call /sbin/shutdown -h. The INIT_HALT variable would not be set.
This would cause the /etc/init.d/halt script to check /etc/defaults/halt
to see if the computer should be powered off or not. Basically, whether
the computer was simply stopped or powered off depended on the contents
of /etc/defaults/halt.

With the current version of SysV init (2.94) the /sbin/halt command
works a little differently. One of two things happens:

1. The user runs /sbin/halt -p, this causes /sbin/shutdown -h -P to be
called. That in turns sets the INIT_HALT variable. Then, when
/etc/init.d/halt checks the value of INIT_HALT, it sees it needs to
power off the computer. The computer should turn off.

2. The user runs /sbin/halt without the "-p" flag. This runs
/sbin/shutdown -h. INIT_HALT is not set. The /etc/init.d/halt script
checks /etc/defaults/halt to see whether it should poweroff or simply stop.


In short, I think the original bug report was probably correct. The
/sbin/shutdown command was being called as "shutdown -h" when it should
have been called as "shutdown -h -P" in order versions of this package.
However, 2.94 and newer use the better behaviour (calling shutdown -h
-P) which means this bug report can be marked as "fixed upstream".

- Jesse

Bug#849308: state of wireguard mainline inclusion?

[Daniel Kahn Gillmor]

Hi Mika--

On Thu 2019-03-07 16:16:40 +0100, Michael Prokop wrote:
> So sadly wireguard didn't make it into buster. :(

yep, frustrating.  but that was by design -- it isn't clear to me that
the ecosystem will be happy with having a wide distribution of an
outdated (2019) version running in 2021 :/, depending on what happens
with the upstream inclusion work (which i can't currently predict).

> Are there any plans for providing backports for stretch and/or buster?

I do plan for putting wireguard into buster-backports, since i expect
the upstream inclusion issues to be resolved one way or another by the
time of bullseye release.  If anyone wants to help out by adding it to
stretch-backports-sloppy, i would welcome that.

  --dkg


signature.asc
Description: PGP signature

Bug#743555: [Pkg-sysvinit-devel] Bug#743555: initscripts: command "halt" unintended changed behaviour

[Pierre Ynard]

> I wondered, why the behaviour of the command halt might have changed.

> Does this maybe be related to the change from sysinit to systemd?

I surmise that yes, and that systemd - and upstart - use a different
default behavior than sysvinit.

> I don't know why you are seeing a behavior change here in Debian, but
> this is a FAQ in Ubuntu. You are right that for a very long time,
> the behavior of 'halt' in sysvinit, as influenced by the contents of
> /etc/default/halt, was to 'poweroff'. However, a careful reading of
> the documentation shows that this was actually a *bug*; the 'halt'
> command, without arguments, should always have been configured to
> do a non-poweroff halt, and /etc/default/halt should only ever have
> affected the behavior of 'shutdown -h'.
>
> The standard behaviors should always have been:
>
>   shutdown -P == halt -p == poweroff: halt the system and power down
>   shutdown -H == halt: halt the system, do not power down
> shutdown -h: halt or power off, depending on /etc/default/halt

Steve, which documentation exactly do you base this on and how
authoritative is it supposed to be?

Jesse, what do you think of this? There seems to be a conflict of
opinion here.

-- 
Pierre Ynard

Bug#914771: bundler: cannot load such file -- bundler-1.16.1/exe/bundle

[Antonio Terceiro]

Hello,

On Thu, Nov 29, 2018 at 02:06:29AM +0800, Andrew Lee wrote:
> ┌──┐
> │ Run tests for ruby2.5 from debian/ruby-tests.rake   
>  │
> └──┘
> 
> RUBYLIB=/home/alee/sources/rubygems/ruby-team/ruby-appraisal/debian/ruby-appraisal/usr/lib/ruby/vendor_ruby:.
>  
> GEM_PATH=debian/ruby-appraisal/usr/share/rubygems-integration/all:/home/alee/.gem/ruby/2.5.0:/var/lib/gems/2.5.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.5.0:/usr/share/rubygems-integration/2.5.0:/usr/share/rubygems-integration/all
>  ruby2.5 -S rake -f debian/ruby-tests.rake
> /usr/bin/ruby2.5 /usr/bin/rspec --pattern ./spec/\*\*/\*_spec.rb
> bin/bundle:104:in `load': cannot load such file -- 
> /usr/share/rubygems-integration/all/gems/bundler-1.17.1/exe/bundle (LoadError)
>   from bin/bundle:104:in `'
[...]

On Mon, Jan 21, 2019 at 01:48:53PM -0500, arpin.h...@gmail.com wrote:
[...]
> # This will fail: No such file or directory -- /usr/lib/ruby/exe/bundle
> (LoadError)
> bundle exec rails new . <<< "y"
> 
> I'm on buster, since the new release is coming soon, I think this is a
> good time to update bundler.
[...]

On Thu, Mar 07, 2019 at 04:22:15PM +0100, Daniel Leidert wrote:
> Package: ruby-bundler
> Version: 1.17.3-2
> Followup-For: Bug #914771
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> If ruby-bundler is installed, `jekyll new` fails with this error:
> 
> jekyll new . --force
> Running bundle install in /tmp/test... 
>   Bundler: ruby: No such file or directory -- 
> /usr/share/rubygems-integration/all/gems/bundler-1.17.3/exe/bundle (LoadError)
> 
> If ruby-bundler is removed. Everything works fine. This seems odd
> and might be related o the issue discussed here. IMHO this is an
> important issue and should be fixed before the next stable relase.
[...]

I did some testing and this is caused by bundle not being installed
using the Rubygems layout. That is assumed by a few other packages,
which causes this problems.

However, switching the installation layout at this point in time is too
risky as the fallout could be large (I tried locally and even bundler
itself would need more work). So it won't be possible to fix this before
buster is released.

If you need to workaround this issue for the time being, look for places
where your packages call something like `Gem.bin_path("bundler",
"bundle")` and replace that with a hardcoded "/usr/bin/bundle".


signature.asc
Description: PGP signature

Bug#923173: Fwd: Bug#923173: Acknowledgement (linux-image-4.9.0-8-amd64: Kernel Panic, HALT when detach-ing bcache)

[Henrie Cuijpers]

I tested this for a few older kernels:

linux-image-4.9.0-8-amd64: kernel panic
linux-image-4.9.0-7-amd64: kernel panic
linux-image-4.9.0-6-amd64: works fine
linux-image-4.9.0-5-amd64: not tested
linux-image-4.9.0-4-amd64: works fine

Bug#923976: [Pkg-puppet-devel] Bug#923976: Bug#923976: puppet: Reports submitte

[Kienan Stewart]

On Fri, Mar 08, 2019 at 04:34:39PM +0200, Apollon Oikonomopoulos wrote:
> Control: tags -1 unreproducible moreinfo
> 
> 
> Turns out this is already enabled and running in our tests without 
> issues. I'm unable to trivially reproduce this, which makes me wonder if 
> it's a matter of the terminus version. Which version of the 
> puppet-terminus-puppetdb package are you using on the master?

puppet-terminus-puppetdb is currently 6.2.0-3

> 
> Regards,
> Apollon


signature.asc
Description: PGP signature

Bug#923827: python-zake: FTBFS randomly (failing tests)

[Santiago Vila]

On Fri, Mar 08, 2019 at 03:42:28PM +0100, Thomas Goirand wrote:

> Does the issue always appears in the same test?

Actually two of them:

cat * | grep ^FAIL: | sort
FAIL: zake.tests.test_client.TestMultiClient.test_clients_triggered
FAIL: zake.tests.test_client.TestMultiClient.test_clients_triggered
FAIL: zake.tests.test_client.TestMultiClient.test_clients_triggered
FAIL: zake.tests.test_client.TestMultiClient.test_purge_clients_triggered
FAIL: zake.tests.test_client.TestMultiClient.test_purge_clients_triggered
FAIL: zake.tests.test_client.TestMultiClient.test_purge_clients_triggered
FAIL: zake.tests.test_client.TestMultiClient.test_purge_clients_triggered

> If so, then probably
> just blacklist this unit test would do?

Yes, that's what I would do.

Additionally, you might want to forward it upstream, but that's really
up to you. I'm only trying to make sure the packages build without
failure (including random failures).

Thanks.

Bug#924033: unblock: papi/5.7.0-1

[Andreas Beckmann]

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

Please unblock package papi

This will update papi from a git snapshot to the latest release,
bringing these changes:
* fix arm64 support for Linux 3.19+ (probably RC)
* many memory leaks fixed
* lots of minor bugfixes.
There are also changes to components that are not built by the Debian
package and therefore are not relevant for us.

The package has been built on all (supported) release architectures.
The four rdepends either fail for unrelated reasons or build
successfully with the new papi version (build-tested on amd64).

The attached debdiff has been pruned with 
  filterdiff -p1 -x 'ChangeLogP570.txt' -x 'doc/*' -x 'man/*' -x 
'src/components/cuda/*' -x 'src/components/nvml/*' -x '*.txt' -x '*.html' -x 
gitlog2changelog.py
to exclude documentation changes and changes to the the CUDA related components.
Switching from a git snapshot to a release tarball also "drops"
several config files and scripts that are used by upstream to perform
a release.


Full diffstat before pruning:

 .gitattributes |9 
 ChangeLogP570.txt  | 1012 +
 PAPI_FAQ.html  |  362 --
 RELEASENOTES.txt   |   66 +
 bitbucket-pipelines.yml|   20 
 debian/changelog   |8 
 debian/gbp.conf|2 
 debian/patches/for-debian-fix-hyphenation.patch|4 
 debian/rules   |2 
 debian/upstream/metadata   |2 
 delete_before_release.sh   |   18 
 doc/DataRange.html |  330 -
 doc/Doxyfile-common|2 
 doc/PAPI-C.html|  249 
 doc/README |   17 
 gitlog2changelog.py|  125 --
 man/man1/PAPI_derived_event_files.1|2 
 man/man1/papi_avail.1  |2 
 man/man1/papi_clockres.1   |2 
 man/man1/papi_command_line.1   |2 
 man/man1/papi_component_avail.1|4 
 man/man1/papi_cost.1   |8 
 man/man1/papi_decode.1 |2 
 man/man1/papi_error_codes.1|2 
 man/man1/papi_event_chooser.1  |2 
 man/man1/papi_hybrid_native_avail.1|2 
 man/man1/papi_mem_info.1   |2 
 man/man1/papi_multiplex_cost.1 |2 
 man/man1/papi_native_avail.1   |2 
 man/man1/papi_version.1|2 
 man/man1/papi_xml_event_info.1 |2 
 man/man3/PAPIF_accum.3 |2 
 man/man3/PAPIF_accum_counters.3|2 
 man/man3/PAPIF_add_event.3 |2 
 man/man3/PAPIF_add_events.3|2 
 man/man3/PAPIF_add_named_event.3   |2 
 man/man3/PAPIF_assign_eventset_component.3 |2 
 man/man3/PAPIF_cleanup_eventset.3  |2 
 man/man3/PAPIF_create_eventset.3   |2 
 man/man3/PAPIF_destroy_eventset.3  |2 
 man/man3/PAPIF_enum_event.3|2 
 man/man3/PAPIF_epc.3   |2 
 man/man3/PAPIF_event_code_to_name.3|2 
 man/man3/PAPIF_event_name_to_code.3|2 
 man/man3/PAPIF_flips.3 |2 
 man/man3/PAPIF_flops.3 |2 
 man/man3/PAPIF_get_clockrate.3 |2 
 man/man3/PAPIF_get_dmem_info.3 |2 
 man/man3/PAPIF_get_domain.3|2 
 man/man3/PAPIF_get_event_info.3|2 
 man/man3/PAPIF_get_exe_info.3  |2 
 man/man3/PAPIF_get_granularity.3   |2 
 man/man3/PAPIF_get_hardware_info.3 |2 
 man/man3/PAPIF_get_multiplex.3 |2 
 man/man3/PAPIF_get_preload.3   |2 
 man/man3/PAPIF_get_real_cyc.3  |2 
 man/man3/PAPIF_get_real_nsec.3 |2 
 man/man3/PAPIF_get_real_usec.3 |2 
 man/man3/PAPIF_get_virt_cyc.3  |2 
 man/man3/PAPIF_get_virt_usec.3 |2 
 man/man3/PAPIF_

Bug#923444: bacula: autopkgtest regressed in buster

[Carsten Leonhardt]

Hi all,

Paul Gevers  writes:

>> Or are we trying to fix a problem at the whole wrong level?
>
> I am not sure about the answer. If anybody has the time and energy,
> maybe they can check with the dpkg maintainers if they are aware of the
> situation and if that is intentional. Maybe they consider this issue
> something they can (and should) fix.

I encountered a solution to a problem that might be similar.

While installing an apache module, I got the message:

"Package apache2 is not configured yet. Will defer actions by package xyz."

It's source is:

https://salsa.debian.org/apache-team/apache2/blob/master/debian/debhelper/apache2-maintscript-helper#L80

Maybe there's something to be learned from there?

(I don't have time to have a closer look in the next days, so putting it
into the bug report to not have it forgotten.)

Regards,

Carsten

Bug#924032: mpqc3: FTBFS: Could NOT find MPI

[Andreas Beckmann]

Source: mpqc3
Version: 0.0~git20170114-4.1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

mpqc3 FTBFS in sid and buster with

[...]
-- Detecting Fortran/C Interface
-- Detecting Fortran/C Interface - Found GLOBAL and MODULE mangling
-- Verifying Fortran/CXX Compiler Compatibility
-- Verifying Fortran/CXX Compiler Compatibility - Success
-- Found PAPI: /usr/lib/x86_64-linux-gnu/libpapi.a  
-- Found MPI_C: /usr/lib/x86_64-linux-gnu/libmpich.so (found version "3.1") 
-- Could NOT find MPI_CXX (missing: MPI_CXX_WORKS) 
-- Found MPI_Fortran: /usr/lib/x86_64-linux-gnu/libmpichfort.so (found version 
"3.1") 
-- Could NOT find MPI (missing: MPI_CXX_FOUND) (found version "3.1")
CMake Error at external/MPI:36 (message):
  MPI not found
Call Stack (most recent call first):
  external/External:8 (include)
  CMakeLists.txt:330 (include)


-- Configuring incomplete, errors occurred!


Andreas

BTW, why does it link statically against papi?


mpqc3.buster.build.gz
Description: application/gzip

Bug#923827: python-zake: FTBFS randomly (failing tests)

[Thomas Goirand]

On 3/5/19 8:09 PM, Santiago Vila wrote:
> Package: src:python-zake
> Version: 0.2.2-2
> Severity: important
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> pyversions: missing X(S)-Python-Version in control file, fall back to 
> debian/pyversions
> pyversions: missing debian/pyversions file, fall back to supported versions
> py3versions: no X-Python3-Version in control file, using supported versions
> dh build-indep --buildsystem=python_distutils --with python2,python3
>dh_update_autotools_config -i -O--buildsystem=python_distutils
>dh_auto_configure -i -O--buildsystem=python_distutils
> dh_auto_configure: Please use the third-party "pybuild" build system instead 
> of python-distutils
> dh_auto_configure: This feature will be removed in compat 12.
>dh_auto_build -i -O--buildsystem=python_distutils
> dh_auto_build: Please use the third-party "pybuild" build system instead of 
> python-distutils
> dh_auto_build: This feature will be removed in compat 12.
> pyversions: missing X(S)-Python-Version in control file, fall back to 
> debian/pyversions
> pyversions: missing debian/pyversions file, fall back to supported versions
>   python setup.py build --force
>debian/rules override_dh_auto_test
> make[1]: Entering directory '/<>'
> pyversions: missing X(S)-Python-Version in control file, fall back to 
> debian/pyversions
> pyversions: missing debian/pyversions file, fall back to supported versions
> py3versions: no X-Python3-Version in control file, using supported versions
> set -ex && for i in 2.7 3.7 ; do \
>   PYTHON=python$i python$i -m nose -v 
> --exclude-test=zake.tests.test_client.TestClient.test_child_watch_no_create ; 
> \
> done
> + PYTHON=python2.7 python2.7 -m nose -v 
> --exclude-test=zake.tests.test_client.TestClient.test_child_watch_no_create
> zake.tests.test_client.TestClient.test_child_child_watch ... ok
> zake.tests.test_client.TestClient.test_child_left_delete ... ok
> zake.tests.test_client.TestClient.test_child_watch ... ok
> zake.tests.test_client.TestClient.test_command ... ok
> zake.tests.test_client.TestClient.test_command_custom_version ... ok
> zake.tests.test_client.TestClient.test_command_empty_version ... ok
> zake.tests.test_client.TestClient.test_command_envi ... ok
> zake.tests.test_client.TestClient.test_command_no_connect ... ok
> zake.tests.test_client.TestClient.test_command_version ... ok
> zake.tests.test_client.TestClient.test_concurrent_restart ... ok
> zake.tests.test_client.TestClient.test_concurrent_transaction_aborts ... ok
> zake.tests.test_client.TestClient.test_concurrent_transaction_half_work ... ok
> zake.tests.test_client.TestClient.test_connected ... ok
> zake.tests.test_client.TestClient.test_create ... ok
> zake.tests.test_client.TestClient.test_create_async ... ok
> zake.tests.test_client.TestClient.test_create_async_exception ... ok
> zake.tests.test_client.TestClient.test_create_async_linked ... ok
> zake.tests.test_client.TestClient.test_create_sequence ... ok
> zake.tests.test_client.TestClient.test_create_slashed ... ok
> zake.tests.test_client.TestClient.test_data_watch ... ok
> zake.tests.test_client.TestClient.test_data_watch_not_triggered ... ok
> zake.tests.test_client.TestClient.test_delete ... ok
> zake.tests.test_client.TestClient.test_ephemeral_no_children ... ok
> zake.tests.test_client.TestClient.test_ephemeral_raises ... ok
> zake.tests.test_client.TestClient.test_exists ... ok
> zake.tests.test_client.TestClient.test_get_children ... ok
> zake.tests.test_client.TestClient.test_make_path ... ok
> zake.tests.test_client.TestClient.test_missing_leading_slash ... ok
> zake.tests.test_client.TestClient.test_no_make_path ... ok
> zake.tests.test_client.TestClient.test_path_normalization ... ok
> zake.tests.test_client.TestClient.test_recursive_delete ... ok
> zake.tests.test_client.TestClient.test_root ... ok
> zake.tests.test_client.TestClient.test_root_delete ... ok
> zake.tests.test_client.TestClient.test_sequence ... ok
> zake.tests.test_client.TestClient.test_session_id ... ok
> zake.tests.test_client.TestClient.test_sync ... ok
> zake.tests.test_client.TestClient.test_transaction ... ok
> zake.tests.test_client.TestClient.test_transaction_abort ... ok
> zake.tests.test_client.TestClient.test_transaction_check ... ok
> zake.tests.test_client.TestClient.test_version ... ok
> zake.tests.test_client.TestMultiClient.test_clients_attached ... ok
> zake.tests.test_client.TestMultiClient.test_clients_counter ... ok
> zake.tests.test_client.TestMultiClient.test_clients_triggered ... ok
> zake.tests.test_client.TestMultiClient.test_purge_clients_triggered ... FAIL
> 
> ==
> FAIL: zake.tests.test_client.TestMultiClient.test_purge_clients_triggered
> ---

Bug#923609: proposed solution

[Dmitry Bogatov]

I believe this patch would somewhat solve issue. Dear submitter, can you
please apply this patch, build package and check, that `gdbm_load-nolfs'
binary from created bin:gdbmtool does sensible thing?

By the way, can I somehow help to make autopkgtests on !amd64 happen?

From dbbe906795dd977ed16cccaa7b0385ce8654c8a5 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 7 Mar 2019 20:19:11 +
Subject: [PATCH] Provide version with LFS support disabled

---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index fce1572..03b6242 100755
--- a/debian/rules
+++ b/debian/rules
@@ -39,17 +39,21 @@ ifeq ($(HAVE_DIETLIBC),yes)
CC='diet gcc' CPPFLAGS='-UHAVE_MMAP'
 endif
dh_auto_configure -B glibc-build -- --enable-libgdbm-compat
+   dh_auto_configure -B glibc-nolfs-build -- \
+   CFLAGS='-static' --program-suffix=-nolfs --disable-largefile
 
 override_dh_auto_build:
 ifeq ($(HAVE_DIETLIBC),yes)
dh_auto_build -B diet-build
 endif
dh_auto_build -B glibc-build
+   dh_auto_build -B glibc-nolfs-build
 
 override_dh_auto_install:
 ifeq ($(HAVE_DIETLIBC),yes)
dh_auto_install -B diet-build
 endif
+   dh_auto_install -B glibc-nolfs-build
dh_auto_install -B glibc-build
 
 ifeq ($(HAVE_DIETLIBC),yes)
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgpmOxYXdMFMr.pgp
Description: PGP signature

Bug#923924: Please review and apply attached patch to support shutdown on SIGPWR

[Dmitry Bogatov]

[2019-03-07 12:57] Andras Korn 
> part 1 text/plain 218
> Sorry, I sent an earlier version of the patch by mistake.
>
> I'm attaching the correct one, which I tested and which works for me.
> [...]
> -  if (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & S_IXUSR)) {
> +  if ((sigp) || (sigc && (stat(STOPIT, &s) != -1) && (s.st_mode & 
> S_IXUSR))) {

As far as I can tell by glance on patch, you want SIGPWR trigger reboot.
If so, why don't you create REBOOT file in, say, /etc/rc.local and make
lxc controller to send SIGCONT?

Or am I missing something, and your patch gives more flexibility?

By the way, SIGPWR is not in POSIX, according to signal(7).
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923976: [Pkg-puppet-devel] Bug#923976: Bug#923976: puppet: Reports submitte

[Apollon Oikonomopoulos]

Control: tags -1 unreproducible moreinfo

On 15:47 Fri 08 Mar , Apollon Oikonomopoulos wrote:
> On 14:54 Thu 07 Mar , Kienan wrote:
> > When running puppet 5.x with reports enabled and sent to PuppetDB 6.x,
> > PuppetDB fails to store the report with the following error:
> > 
> > 2019-03-01T17:06:01.396-05:00 ERROR [p.p.command] [100] [store report] 
> > Fatal error on attempt 0 for pm-buster.test
> > clojure.lang.ExceptionInfo: throw+: {:fatal true, :cause #error {
> >  :cause "Value does not match schema: {:metrics [nil nil nil nil nil nil
> >  nil nil nil nil nil nil {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} nil nil {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} nil {:value (not (instance? java.lang.Number
> >  a-java.lang.String))} nil nil nil nil nil nil nil nil nil {:value (not
> >  (instance? java.lang.Number a-java.lang.String))} nil nil nil nil nil
> >  nil]}"
> >  
> > A copy of the Puppet DB log file is attached with the complete
> > backtrace.
> > 
> > I'm filing this bug against the puppet package for the following reasons
> > 
> > * hosts running puppet 4.x (stretch) are able to submit reports to same
> > version of Puppet DB.
> 
> So, this sounds like a regression. I would not be surprised if Puppet 4 
> nodes failed to work with PuppetDB 6, but this is clearly a bug.
> 
> > * I am able to "solve" the problem by modifying a number of places in
> > the puppet agent files where report information is returned and calling
> > "to_i" or "to_f" to force casting into a numeric value instead of a
> > string.
> > 
> > The metrics keys affected include: convert_catalog and
> > transaction_evaluation. The keys affected may change depending on the
> > manifest used for the node.
> > 
> > This being said, it may be appropriate to move this bug to the PuppetDB
> > package. I haven't been able to find any upstream bugs regarding this
> > behaviour.
> > 
> > To reproduce:
> > 
> > 1. Install puppet, puppet-master-passenger, and puppetdb on the same
> > host.
> > 2. Configure the puppet master to storeconfigs with the PuppetDB and the
> > agent to submit reports:
> > 
> > (snippet from /etc/puppet.conf)
> > 
> >   [main]
> > reports = puppetdb
> 
> Note to self: let's add report storage to the puppet/puppetdb 
> autopkgtests.

Turns out this is already enabled and running in our tests without 
issues. I'm unable to trivially reproduce this, which makes me wonder if 
it's a matter of the terminus version. Which version of the 
puppet-terminus-puppetdb package are you using on the master?

Regards,
Apollon

Bug#923905: libdbd-pg-perl: FTBFS (failing tests)

[gregor herrmann]

On Fri, 08 Mar 2019 15:27:25 +0100, Christoph Berg wrote:

> Re: gregor herrmann 2019-03-08 <20190308142308.gu...@jadzia.comodo.priv.at>
> > I'm happy to upload, just wanted to wait in case you're working on
> > the package as well and/or want to take a look.
> Please go ahead, I was just lurking on #postgresql-lounge where the
> issue was discussed as well.

Thanks; uploaded.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#923905: libdbd-pg-perl: FTBFS (failing tests)

[Christoph Berg]

Re: gregor herrmann 2019-03-08 <20190308142308.gu...@jadzia.comodo.priv.at>
> Control: tag -1 + fixed-upstream patch pending
> 
> On Fri, 08 Mar 2019 15:10:48 +0100, Christoph Berg wrote:
> 
> > Upstream fix: 
> > https://github.com/bucardo/dbdpg/commit/2b60151aea6f03ac7e846aae0d21e7f335cad99c
> 
> Ha, I just found the same commit and I've added it as a patch to the
> git repo of our package.
> 
> I'm happy to upload, just wanted to wait in case you're working on
> the package as well and/or want to take a look.

Please go ahead, I was just lurking on #postgresql-lounge where the
issue was discussed as well.

Thanks,
Christoph