Bug#917072: mmm-mode: fails to byte-compile with emacs-26

[David Bremner]

Source: mmm-mode
Version: 0.5.7-2
Severity: serious
Justification: fails to install

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


I'm not quite sure whether this is a bug in emacs 26 or in mmm-mode,
but in any case it seems the file mmm-sample.el doesn't really need to
be byte compiled.

Attached is an nmudiff that I plan to upload to DELAYED/5

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

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

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEE3VS2dnyDRXKVCQCp8gKXHaSnniwFAlwd6OIACgkQ8gKXHaSn
niyJmQv/fnUdj6larMpf7Af/5qVgwAeZyOzIdlDoSbjZ9NA6n99LYagXPUKAPyUD
ohbKFueDSU5OwAeLN6h07F47vKBcDe7sVfTOX0ntEPY8Eh5u5EXsRuEpBKnBqhwg
NAgwlwKHpVUdzpT8XUKcZEhEeisyqbP3ZdtYNvrgz2DoLFBLcJdgCJcVopl1/CJD
PTFOEdW5JaATGcPeoSf8Hdzj74SK3NiFPoaeryNkV4SRvCyNqRMPJDD8/tmZTE26
8f7YbWMVcmciZnjwx2HRsYxIjpL5nczkTtDM9bYucq+zCah/k5cx760fGw0XdAtf
caDlGrDmJbyIxqtrff90tU0KnmKNUI39/WzmtqDrWCjxKYF0bA78AlZCDgT3ITpf
j0iXs02ESIq4YPB9v3dfY0oTuJdEUD0laubeY9wNMgHiB42PZzpNi/K0I0nIhe7A
X02Bk9vFqb61d1HqQcJLQZe+xiHPvi0lNd35rRWueWqKrRFDBt9eIslvFeI5nrsF
oD7IQw8C
=kLlK
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index f44b0bb..76a7b5d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+mmm-mode (0.5.7-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable byte compilation of mmm-sample.el as this hangs with emacs-26
+
+ -- David Bremner   Sat, 22 Dec 2018 16:27:49 +0900
+
 mmm-mode (0.5.7-2) unstable; urgency=high
 
   * fix function and file conflicts between emacs and xemacs
diff --git a/mmm-sample.el b/mmm-sample.el
index 5ee4419..58cebd4 100644
--- a/mmm-sample.el
+++ b/mmm-sample.el
@@ -1,4 +1,4 @@
-;;; mmm-sample.el --- Sample MMM submode classes
+;;; mmm-sample.el --- Sample MMM submode classes -*- no-byte-compile: t; -*-
 
 ;; Copyright (C) 2000-2004, 2012-2015, 2018  Free Software Foundation, Inc.
 

Bug#913864: kicad: Backtraces on opening cvpcb

[Julien Goodwin]

On 15/12/18 5:34 pm, Carsten Schoenert wrote:
> I tried to reproduce this issue on several machines in preparation for
> 5.0.2. But I'm unable to get catched by your reported issue on any of my
> machines. Even if I forced the install the packages python-wxgtk3.0 and
> libwxgtk3.0-gtk3-0v5!

For me forcing python-wxgtk3.0_3.0.2.0+dfsg-4 is the way I make things work.

...
> No other user seems to be affected by the root of this report until now.
> I've not seen something similar in the KiCad user forum too. Also the
> backtrace shows to me that somehow functions called that should have
> been disabled (CMake option KICAD_SCRIPTING_WXPYTHON=OFF) for all
> versions since 5.0.0-1.

> Are you really sure you are using a binary from the Debian archive? Can
Yes.

I just upgraded to 5.0.2+dfsg1-1 last night, and before that played around.

Having a python plugin (in .kicad/scripting/plugins, and specifically
InteractiveHtmlBom[1]) seems to be what triggers this.

So if python is intended to be disabled it's clearly not.

1: https://github.com/openscopeproject/InteractiveHtmlBom

Bug#917050: [Pkg-emacsen-addons] Bug#917050: Hangs infinitely when compiling for emacs 1:26.1+1-2

[David Bremner]

Axel Beckert  writes:

>
> mmm-mode is btw. a third case which showed up. This one showed up on
> both machines. The order of compiling the modules looks a little bit
> random, so it seems to depend a lot on which affected module is
> compiled first...

That one I can replicate (or a related problem). In a clean sid chroot:

1) install emacs-gtk (1:26.1+1-2)
2) install mmm-mode

For me that reliably hangs during byte compilation.

Bug#917071: elpa-persp-projectile: byte compilation fails: make-variable-frame-local

[David Bremner]

Package: elpa-persp-projectile
Version: 1:0.2.0-2
Severity: serious
Justification: fails to install

install/persp-projectile-0.2.0: Handling install of emacsen flavor emacs
install/persp-projectile-0.2.0: byte-compiling for emacs

In toplevel form:
persp-projectile.el:47:1:Error: Symbol’s function definition is void: 
make-variable-frame-local
ERROR: install script from elpa-persp-projectile package failed
dpkg: error processing package elpa-persp-projectile (--configure):
 installed elpa-persp-projectile package post-installation script subprocess 
returned error exit status 1
Errors were encountered while processing:
 elpa-persp-projectile


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

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

Versions of packages elpa-persp-projectile depends on:
ii  elpa-perspective   1.12+git20160216.add7942-2
ii  elpa-projectile1.0.0-1
ii  emacs  1:26.1+1-2
ii  emacs-gtk [emacs]  1:26.1+1-2
ii  emacsen-common 3.0.4

Versions of packages elpa-persp-projectile recommends:
ii  emacs  1:26.1+1-2
ii  emacs-gtk [emacs]  1:26.1+1-2

elpa-persp-projectile suggests no packages.

-- no debconf information

Bug#917070: elpa-smex: byte-compilation fails

[David Bremner]

Package: elpa-smex
Version: 3.0-2
Severity: serious
Justification: fails to install


  install/smex-3.0: byte-compiling for emacs

In smex-already-running:
smex.el:91:11:Warning: defsubst ‘smex-already-running’ was used before it was
defined

In smex-update-and-rerun:
smex.el:94:11:Warning: defsubst ‘smex-update-and-rerun’ was used before it was
defined

In smex-read-and-run:
smex.el:107:10:Warning: ‘execute-extended-command’ is for interactive use
only; use ‘command-execute’ instead.

In smex-initialize-ido:
smex.el:228:4:Warning: ‘ido-init-completion-maps’ is an obsolete function (as
of 25.1); it does nothing.

In smex-load-save-file:
smex.el:245:13:Error: missing value for ‘smex-history’ at end of setq
smex.el:245:30:Error: missing value for ‘smex-data’ at end of setq

In smex-save-file-not-empty-p:
smex.el:247:11:Warning: defsubst ‘smex-save-file-not-empty-p’ was used before
it was defined
ERROR: install script from elpa-smex package failed
dpkg: error processing package elpa-smex (--configure):
 installed elpa-smex package post-installation script subprocess returned error 
exit status 1
Errors were encountered while processing:
 elpa-smex



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

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

Versions of packages elpa-smex depends on:
ii  emacs  1:26.1+1-2
ii  emacs-gtk [emacs]  1:26.1+1-2
ii  emacsen-common 3.0.4

Versions of packages elpa-smex recommends:
ii  emacs  1:26.1+1-2
ii  emacs-gtk [emacs]  1:26.1+1-2

elpa-smex suggests no packages.

-- no debconf information

Bug#917069: RM: guile-gnome-platform [armel] -- ROM; guile-2.2 is not available on armel

[Scott Kitterman]

On Saturday, December 22, 2018 07:18:50 AM Tommi Höynälänmaa wrote:
> Package: ftp.debian.org
> X-Debbugs-Cc: guile-gnome-platf...@packages.debian.org
> X-Debbugs-Cc: guile-ca...@packages.debian.org
> X-Debbugs-Cc: g-w...@packages.debian.org
> X-Debbugs-Cc: tommi.hoynalan...@iki.fi
> X-Debbugs-Cc: jbi...@debian.org
> X-Debbugs-Cc: deb...@alteholz.de
> Affects: src:guile-gnome-platform, src:guile-cairo, src:g-wrap
> 
> guile-2.2 doesn't build on armel currently. Therefore, please remove
> guile-gnome-platform, guile-cairo, and g-wrap from armel.
> 
> Packages guile-gnome-platform, guile-cairo, and g-wrap have reverse
> dependency gwave in Debian.
> 
> Seehttps://bugs.debian.org/883778  for more details about the guile armel
> issue.

Please also submit a bug asking for gwave removal on armel.  It will have to 
go first.

Scott K

Bug#916968: w3mman support for section number during keyword search

[Tatsuya Kinoshita]

Control: tags -1 + pending

On December 20, 2018 at 1:21PM -0800, nemoinis (at hotmail.com) wrote:
> Here's a little patch that does that. It is now possible to type:
> w3mman 1 -k text

Merged and updated, thanks for your contribution.

  - https://salsa.debian.org/debian/w3m/commits/master

Will be fixed in the next upload.

Thanks,
--
Tatsuya Kinoshita


pgpycc6IfJvP4.pgp
Description: PGP signature

Bug#917069: RM: guile-gnome-platform [armel] -- ROM; guile-2.2 is not available on armel

[Tommi Höynälänmaa]

Package: ftp.debian.org
X-Debbugs-Cc: guile-gnome-platf...@packages.debian.org
X-Debbugs-Cc: guile-ca...@packages.debian.org
X-Debbugs-Cc: g-w...@packages.debian.org
X-Debbugs-Cc: tommi.hoynalan...@iki.fi
X-Debbugs-Cc: jbi...@debian.org
X-Debbugs-Cc: deb...@alteholz.de
Affects: src:guile-gnome-platform, src:guile-cairo, src:g-wrap

guile-2.2 doesn't build on armel currently. Therefore, please remove
guile-gnome-platform, guile-cairo, and g-wrap from armel.

Packages guile-gnome-platform, guile-cairo, and g-wrap have reverse dependency 
gwave in Debian.

Seehttps://bugs.debian.org/883778  for more details about the guile armel issue.

Thanks,

 Tommi Höynälänmaa

Bug#917050: [Pkg-emacsen-addons] Bug#917050: Hangs infinitely when compiling for emacs 1:26.1+1-2

[Axel Beckert]

Hi David,

David Bremner wrote:
> I can't duplicate this problem here (in a buster system).

Hrm, shouldn't make too much relevant difference to my sid here.

> Can you tell
> us anything more about the configuration where you see it?

Nothing special IMHO. Lots of elpa-packages installed, so chances are
high that only a combination triggers this.

Oh, and I ran into it on two different systems -- all on which I
dist-upgraded Sid today. Both are amd64.

David Bremner wrote:
> > P.S.: This looks very similar to https://bugs.debian.org/917050
> > against elpa-markdown-mode.
> 
> Yup, I also can't replicate this one.

mmm-mode is btw. a third case which showed up. This one showed up on
both machines. The order of compiling the modules looks a little bit
random, so it seems to depend a lot on which affected module is
compiled first...

> For now I'm lowering the severity to help triage the emacs26 related
> bugs.

*sigh* Not appropriate for these bugs IMHO, but understandable until
it's figured out which conditions need to be met.

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

Bug#917068: timbl (build-)depends on cruft packages.

[peter green]

package: timbl
version: 6.4.8-1
severity: serious

timbl and libtimbl4 depend on libticcutils2v5 and the timbl source package 
depends on libtimbl4-dev. These packages are no longer build by the ticcutils 
source package.

I notice there is a new version in new that looks like it probablly fixes this, 
but that looks strange too, the changelog claims it makes a soname bumb from 
3->4 but the soname in sid appears to already be 4.

Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Mikhail Morfikov]

Package: cryptsetup-bin
Version: 2:2.0.6-1
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I have several LUKS containers, and all of them use the same password. Some of
the containers are regular disk partitions, but I also have some file images.
An example file image is stored under /home/me/luks/some.img . Here's the
/etc/crypttab file:

- ---
#
sda2_crypt  UUID=some-uuid-1c1
luks,header=/boot/headers/sda2,keyscript=decrypt_keyctl,initramfs
sdb1_crypt  UUID=some-uuid-2c1
luks,header=/boot/headers/sdb1,keyscript=decrypt_keyctl,initramfs
some_img/home/me/luks/some.img  c1 luks,keyscript=decrypt_keyctl
- ---

All of the containers should be opened at boot time, but only the first two
are.

When I add "initramfs" to the third container, I get the following error:

- ---
cryptsetup: ERROR: Couldn't resolve device /home/me/luks/some.img
- ---

And if that message is ignored, system is unable to boot because it waits for
the "device", but since the "device" is inside of the /home/ partition, and the
/home/ partition is inside of an encrypted LVM setup, it can't be read. So I
can't
use "initramfs" in the case of the LUKS file images, but without it, I can't
open the file image along with the rest of the drives at boot time.

For now, I use a systemd service which uses cryptdisks_start and
cryptdisks_stop scripts. In this way the file image can be opened using the
same
password in the kernel keyring, but is there a way to make it work using only
the /etc/crypttab file?



- -- Package-specific info:

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

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

Versions of packages cryptsetup-bin depends on:
ii  libblkid12.33-0.2
ii  libc62.28-3
ii  libcryptsetup12  2:2.0.6-1
ii  libpopt0 1.16-11
ii  libuuid1 2.33-0.2




-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE5JPPWm5C7TFDUMqpzQRoEHcbZSAFAlwdqsQACgkQzQRoEHcb
ZSBKMg/+PTFKL0K8Fi+rm+5pUAAX4qOUExjiaj75NQu1hfP8fxoZf+g3PaMBX7kl
9byFi/eQQ/kAHP2NfukyOqrpwc6nZt/Gv90ozxNDaZ/THTby6er8g7fDPaM09u28
aZJJM0jC2OoBejilOWrkoQxEPeWwk6+OC5hL3p41RjBNNdgCqyym6NgmDO0ZhjRs
0lqHnXJKWsdkKAHc4ETf/rRIpjvY5KrB5ybpFDXsQgmY284Es7J1TPfdkZ5Ev4Sf
ouGI+C+8Lx3lNAqXD6t1a2UNVqggHHwFs9rZqM+OQkTJPtykGq3Nylh2tbKflKH4
lUfKmdKFDgMidy/LyD6QZJRLD7cqv7HOAyDX5JOKYXDVj8rzU2kYHsfBmno/fyUY
ipnlZiG1oLY1gX3fAekbnnI2YPOH1tMqKxLTsQDgNCfSMReQUj3dZC+18Hb9/Opq
GG0TuvZbj7c+S3pJLrtfoXY+0a9kXkirYsVX7Riiefva6uM4P5KW04jLEs2f4N8P
2sc+pBC4/+PhhiUPhVNuHEQBzSfz/jpnIcTkf2Twy22/cu+Y+Yheqhd+9V5B9rQQ
2fxD5fJRX/RHCDuYho/MX3AhRAZrIYvbXT8kpkecpHvyxhdJZepsLqeOyjWdD+gB
f1PWWTNu1t43dH8omwz/tlpD9az6SPsDr5L29SRk2J7dgAtpr+k=
=4RGF
-END PGP SIGNATURE-

Bug#917066: libqbscore1.12: log-level debug causes segfault

[Wookey]

Package: libqbscore1.12
Version: 1.12.1
Severity: normal
Tags: patch upstream


Enabling --log-level debug (or using --more-verbose) (in the build of
dewalls) causes the build to fail with a segfault.

This has been discussed upstream and a fix for the null pointer
dereference produced. Please apply the attached patch to the package until the 
next
release when you should be able to drop this patch. 

Details are in this thread:
https://lists.qt-project.org/pipermail/qbs/2018-December/002290.html
(some of it was not copied to the list)

You can reproduce/test it as follows: 

Install the debug version of libqbscore1.12. Get the dewalls package,
unpack it, cd into it and run dpkg-buildpackage so the 'deb' profile is set up.
then run
qbs build --settings-dir /tmp --log-level debug  --command-echo-mode 
command-line --no-install   
profile:deb 
modules.qbs.installRoot:/home/wookey/packages/cavewhere/dewalls/debian/dewalls-1.0.0/debian/tmp
project.libDir:lib/x86_64-linux-gnu config:qbs-build

You'll need to adjust the installRoot path.
 
it fails with:
qbs.moduleloader:
Resolving Probe at "/usr/share/qbs/modules/bundle/BundleModule.qbs:46:5"
qbs.moduleloader: Probe disabled; skipping
qbs.moduleloader: reset instance scope of module "Qt.core" in property 
"cxxFlags" of module ("cpp")
   
Thread 3 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff72e89700 (LWP 16286)]
0x778ca457 in QStringRef::toString() const () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
Description: Fix for segfault with --log-level debug
 A segfault can occur when the debug logging level is enabled if the 
'sourceCode' value is null.

Origin: upstream 
https://lists.qt-project.org/pipermail/qbs/2018-December/002292.html
Bug-Debian: https://bugs.debian.org/
Reviewed-By: woo...@debian.org
Last-Update: 2018-12-21

--- qbs-1.12.2+dfsg.orig/src/lib/corelib/language/moduleloader.cpp
+++ qbs-1.12.2+dfsg/src/lib/corelib/language/moduleloader.cpp
@@ -2341,9 +2341,11 @@ void ModuleLoader::adjustDefiningItemsIn
 << ", old defining item was " << v->definingItem()
 << " with scope" << v->definingItem()->scope()
 << ", new defining item is" << replacement
-<< " with scope" << replacement->scope()
-<< ", value source code is "
+<< " with scope" << replacement->scope();
+if (v->type() == Value::JSSourceValueType) {
+qCDebug(lcModuleLoader) << "value source code is"
 << 
std::static_pointer_cast(v)->sourceCode().toString();
+}
 replacement->setPropertyDeclaration(propName, decl);
 replacement->setProperty(propName, v);
 } else {

Bug#917031: nmh: co-installability with mmh

[Alexander Zangerl]

On Fri, 21 Dec 2018 18:54:41 +, Dmitry Bogatov writes:
>please make `nmh' co-installable with `mmh'.

upon reviewing of mmh's documentation and stated goals i don't think
this will work. i think that mmh has to conflict with nmh.

it's not compatible with nmh (except in terms of mail storage on disk),
and this breaks exmh and mh-e (which depend on nmh and its behaviour).

the readme states:
"...rather mmh breaks compatibility to nmh in order to modernize and
simplify it."

"...my experimental version more and more feels like being a fork."

for example, schnalke's thesis shows that he's removed pretty essential tools
like post and reinstated spost, which nmh has deprecated completely in favour
of only post.

to switch some nmh/mmh tools over to the other flavour via
alternatives is doomed to fail in my opinion, because it'll cause any of the
remaining *mh tools to operate on the wrong defaults/preferences. this will
cause nothing but confusion and frustration for users.

to always switch all tools over, well, that's achieved in a better fashion
by just having one of the two packages on a box.

unless you can provide me with a compelling resonining and case for
why this mixing of incompatible and overlapping code should be beneficial
i'll close this as wontfix and make nmh explicitely conflict with mmh.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
A successful sysadmin must accept no limits on his laziness.
 -- Peter da Silva


signature.asc
Description: Digital Signature

Bug#917065: sed: new upstream version brings debug option, speed improvements to --in-place

[Paul Wise]

Package: sed
Version: 4.5-2
Severity: wishlist

sed 4.6 brings two interesting changes (and some bug fixes):

  sed now uses fully-buffered output (instead of line-buffered) when
  writing to files. This should noticeably improve performance of "sed -i"
  and other write commands.

  New option, --debug: print the input sed script in canonical form
  and annotate program execution.

https://savannah.gnu.org/forum/forum.php?forum_id=9331

PS: please note that 4.6 introduced a regression, fixed in 4.7:

https://savannah.gnu.org/forum/forum.php?forum_id=9335

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#917031: nmh: co-installability with mmh

[Alexander Zangerl]

On Fri, 21 Dec 2018 18:54:41 +, Dmitry Bogatov writes:
>please make `nmh' co-installable with `mmh'. I, as maintainer of `mmh',
>took first step and made `mmh' alternative of /usr/bin/mh/mh and bunch
>of slave links.

sure, i'll have a look at making those changes in the next few days.

regards
az


-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
I just went visual on this goofy looking Finn riding on a gnu, wielding 
one pissed off penguin... gah -- Bob The Sane


signature.asc
Description: Digital Signature

Bug#902204: monit: spurious "monit alert -- Link up eth0" messages

[Vincent Lefevre]

On 2018-12-21 17:32:30 +0300, Sergey B Kirpichev wrote:
> Does it send you alert if you
> remove "if changed link capacity then alert" line too, correct?

Yes, I still get the same messages.

> If so, I suspect that the currect monit's behaviour is correct and I suggest
> you just adding "if failed link then unmonitor"-like line.

No, unmonitoring the service is not OK, since I still want alerts
when the Ethernet cable is plugged back in.

In any case, this cannot be correct since while the Ethernet cable
is *not* plugged, I get messages with:


Subject: monit alert --  Link up eth0

Link up Service eth0

Date:Sat, 22 Dec 2018 02:40:38
Action:  alert
Host:zira
Description: link data collection succeeded


The "Link up eth0" cannot be correct since the cable is not plugged.
And just after that (at the same second), monit sends a


Subject: monit alert --  Link down eth0

Link down Service eth0

Date:Sat, 22 Dec 2018 02:40:38
Action:  alert
Host:zira
Description: link down


(I suppose that this is a consequence of the "Link up eth0", which
yields a loop).

So, it seems to be a bug in the monit code that makes it think that
the link is up while it is not.

In validate.c, I see:

[...]
for (LinkStatus_T link = s->linkstatuslist; link; link = link->next) {
Event_post(s, Event_Link, State_Succeeded, link->action, "link 
data collection succeeded");
}
// State
if (! Link_getState(s->inf.net->stats)) {
for (LinkStatus_T link = s->linkstatuslist; link; link = 
link->next)
Event_post(s, Event_Link, State_Failed, link->action, 
"link down");
return State_Failed; // Terminate test if the link is down
} else {
for (LinkStatus_T link = s->linkstatuslist; link; link = 
link->next)
Event_post(s, Event_Link, State_Succeeded, 
link->action, "link up");
}
[...]

This seems suspicious. The "link data collection succeeded" preceedes
the check of the state, while the alert says "Link up eth0". So, if
I understand correctly, this yields a State_Succeeded / State_Failed
loop.

That's one point. I don't underdtand the code after "// State" either
(which may be another bug): because the "for" loops are under the
"if" and the "else", it seems to consider that *all* links are down
or *all* links are up. (In my case, I monitor only one link, so that's
not an issue, but it may be one in more complex settings.)

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

Bug#916911: nitrokey-app: Please announce supported hardware via appstream

[Paul Wise]

On Thu, 20 Dec 2018 13:02:31 +0100 Petter Reinholdtsen wrote:

> Here is a proposed patch to do so, based on the udev file included in
> libnitrokey:

Since these should be kept synchronised, I think it would be best to
have libnitrokey upstream export some data about which devices it
supports and then for nitrokey-app to copy those into the AppStream
file at build time, so a simple rebuild of nitrokey-app will update the
AppStream file to include the new devices.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#653386: bash-completion doesn't commands not first on line

[Gabriel F. T. Gomes]

On Tue, 27 Dec 2011 16:27:01 +0100 Jakob Bohm  wrote:
> Package: bash-completion
> Version: 1:1.2-3
> Severity: normal
> 
> The current "stable" version of bash-completion does not do
> command completion in many of the places where something else
> prefixes the command

Current unstable (2.8-4) still has this problem.

>, for example:
> 
> su johndoe -c sor

Completions for su are shipped by util-linux:

  # dpkg --search completions/su
  util-linux: /usr/share/bash-completion/completions/su

I'll forward this bug report to them, with a suggestion (see below)
on how to fix it.

> sh -c sor

I'm testing the following fix for the sh command:
https://github.com/gftg85/bash-completion/commit/d317efc82e41c5a58cd7712785a23439f7bc3fae

> bash -c sor

The fix for sh does not work for bash, because bash uses the _longopt
completion function, which is shared between many other commands, so I
have to think of a way to work around this.

> fakeroot sor
> LC_ALL=C sor

These work with bash-completion 1:2.8-4.


Kind regards.

Bug#895531: Unable to import neuron in python3

[Matthias Klumpp]

Am Mo., 16. Apr. 2018 um 10:18 Uhr schrieb Johannes Hjorth :
>
> I just found the problem while going through the verbose output. I have a 
> subdirectory named "hoc" in my work directory which must have caused a name 
> conflict.
>
> I did a test, started python3 in another directory, imported neuron, it 
> worked. Then I created a new subdirectory called hoc and again started 
> python3 and imported neuron, it then failed.

That is good to know! I'll be closing this bug, as the issue is
actually something else and likely intended upstream behavior.
It could be a good idea to contact NEURON upstream directly about
this, as it obviously is quite confusing behavior.

Cheers,
Matthias


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

Bug#917052: [Pkg-emacsen-addons] Bug#917052: elpa-xml-rpc: Hangs infinitely when compiling for emacs 1:26.1+1-2

[David Bremner]

Control: tag -1 unreproducible
Control: severity -1 important

Axel Beckert  writes:

> Package: elpa-xml-rpc
> Version: 1.6.12-2
> Severity: serious
>
> Hi,
>
> when upgrading emacs from 1:25.2+1-11 to 1:26.1+1-2, it hangs
> infinitely at "install/xml-rpc-1.6.12: byte-compiling for emacs".
>
>
> P.S.: This looks very similar to https://bugs.debian.org/917050
> against elpa-markdown-mode.

Yup, I also can't replicate this one.  Here's  what I did in both cases,
with the relevant elpa package installed:

% apt install emacs-common=1:25.2+1-11 emacs-bin-common=1:25.2+1-11 
emacs-gtk=1:25.2+1-11 emacs-el=1:25.2+1-11
% apt install -t unstable emacs

Byte compilation finishes smoothly.

For now I'm lowering the severity to help triage the emacs26 related
bugs.

Bug#917064: praat FTBFS on big endian: 2 tests segfault

[Adrian Bunk]

Source: praat
Version: 6.0.43-1
Severity: serious
Tags: ftbfs

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

...
= test_SpeechSynthesizer_alignment.praat
test_SpeechSynthesizer_alignment.praat
Segmentation fault
...
= test_alignment.praat
test_alignment.praat
Segmentation fault
...
113 tests passed, 111 ok
Failed test(s):

test_SpeechSynthesizer_alignment.praat
test_alignment.praat
make[1]: *** [debian/rules:86: override_dh_auto_test] Error 1

Bug#917037: ITP: python3-zeroconf -- Pure Python implementation of multicast DNS service discovery (Python3)

[Jonas Smedegaard]

Quoting Ruben Undheim (2018-12-21 21:59:46)
> python-zeroconf already exists in the Debian archive. However, 
> upstream has dropped support for Python 2, and there are reverse 
> dependencies in Debian which depend on the Python 2 package. This 
> makes it necessary with a separate source package for the Python 3 
> version.

Feels wrong to me to add a new source package, when reason is that the 
current/old source package is abandoned upstream!

A quick look seems to indicate these two reverse dependencies:

* pulseaudio-dlna
* python-pychromecast

Neither of those seem to have a bugreport warning that python-zeroconf 
is unmaintained upstream.  They seem to both a) have no reverse 
dependencies themselves, and b) having similar features as 
python3-pychromecast which uses python3-zeroconf.

It seems best to me to try get those few packages to either use a 
maintained library or maybe avoid shipping them with Buster.

Could you please file bugreports appropriately?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#917047: avahi: CVE-2018-1000845: DNS amplification and reflection to spoofed addresses

[Trent Lloyd]

I have pushed a fix upstream for the issue here:
https://github.com/lathiat/avahi/commit/e111def44a7df4624a4aa3f85fe98054bffb6b4f

I have only performed basic validation so far, however the following 
scapy query now fails:
send(IP(src="1.1.1.1",dst="DEST_IP")/UDP(sport=53, 
dport=5353)/DNS(rd=1,qd=DNSQR(qtype="PTR", qname="_ssh._tcp.local.")))


And the following legitimate legacy unicast query still works:
dig HOSTNAME.local @DEST_IP -p 5353


Note that for the test scapy to work, you have to publish an _ssh._tcp 
service, e.g. put the example ssh.service into /etc/avahi/services. To 
avoid that, you can query for the machine's mdns hostname as an A record 
instead.
send(IP(src="1.1.1.1",dst="DEST_IP")/UDP(sport=53, 
dport=5353)/DNS(rd=1,qd=DNSQR(qtype="A", qname="HOSTNAME.local.")))

Bug#917050: [Pkg-emacsen-addons] Bug#917050: Hangs infinitely when compiling for emacs 1:26.1+1-2

[David Bremner]

Control: tag -1 unpreproducible
Control: severity -1 important

Axel Beckert  writes:

> when upgrading emacs from 1:25.2+1-11 to 1:26.1+1-2, it hangs
> infinitely at "install/markdown-mode-2.3snapshot154: byte-compiling
> for emacs".
>

I can't duplicate this problem here (in a buster system). Can you tell
us anything more about the configuration where you see it?

d

Bug#917063: golang-gopkg-cheggaaa-pb.v2 FTBFS: FAIL: TestElementBar

[Adrian Bunk]

Source: golang-gopkg-cheggaaa-pb.v2
Version: 2.0.6-2
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-gopkg-cheggaaa-pb.v2.html

...
=== RUN   TestElementBar
--- FAIL: TestElementBar (0.43s)
element_test.go:34: Unexpected result: '⚑⚒ ⚟⚐'; want: '⚑⚒⚒⚒⚟⚐'
...

Bug#917061: lz4tools FTBFS on !x86: test_2_file segfaults

[Adrian Bunk]

Source: lz4tools
Version: 1.3.1.1-1
Severity: important
Tags: ftbfs

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

...
changing mode of build/scripts-3.7/lz4toolsCli from 664 to 775
   dh_auto_test -a -O--buildsystem=pybuild
I: pybuild pybuild:269: cp -r /<>/tests 
/<>/.pybuild/cpython3_3.6_lz4tools/build/;cp -r 
/<>/src /<>/.pybuild/cpython3_3.6_lz4tools/build/
I: pybuild base:217: cd /<>/.pybuild/cpython3_3.6_lz4tools/build; 
python3.6 -m nose -v tests
test_1_write (test.TestLZ4File) ... ok
test_2_file (test.TestLZ4File) ... Segmentation fault
E: pybuild pybuild:338: test: plugin distutils failed with: exit code=139: cd 
/<>/.pybuild/cpython3_3.6_lz4tools/build; python3.6 -m nose -v 
tests
dh_auto_test: pybuild --test --test-nose -i python{version} -p "3.6 3.7" 
returned exit code 13
make: *** [debian/rules:14: build-arch] Error 13

Bug#917062: python-bumps: binary-any FTBFS

[Adrian Bunk]

Source: python-bumps
Version: 0.7.11-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=python-bumps=sid

...
   debian/rules override_dh_installinfo
make[1]: Entering directory '/<>'
cd build/texinfo; \
for p in *.png; do mv $p bumps-$p; done; \
sed "s/@image{/@image{bumps-/" -i bumps.texi; \
makeinfo bumps.texi
/bin/sh: 1: cd: can't cd to build/texinfo
mv: cannot stat '*.png': No such file or directory
sed: can't read bumps.texi: No such file or directory
could not open bumps.texi: No such file or directory
make[1]: *** [debian/rules:57: override_dh_installinfo] Error 1


This can be reproduced with
  dpkg-buildpackage -B

Bug#917060: rust-nix: Please update to latest upstream version for sparc64 fixes

[John Paul Adrian Glaubitz]

Source: rust-nix
Version: 0.11.0-1
Severity: normal
Tags: upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

The latest upstream version of rust-nix, 0.12.0, contains build
fixes for sparc64 [1]. Since rust-nix is required for several
other Rust packages, it would be nice if the package could get
updated and therefore fixed for sparc64.

Thanks,
Adrian

> [1] https://github.com/nix-rust/nix/pull/987

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#917059: apt-listbugs: New error message /etc/cron.daily/apt-listbugs: logname: no login name

[Alex Gould]

Package: apt-listbugs
Version: 0.1.26
Severity: normal

Dear Maintainer,

After upgrade to the current version of apt-listbugs, I have been getting 
messages in my local mail from "Anacron job 'cron.daily'" to root:

/etc/cron.daily/apt-listbugs:
logname: no login name
logname: no login name
logname: no login name
logname: no login name
logname: no login name

I'm not sure what it means -- is apt-listbugs or anacron trying to run a 
process as a different user?

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

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

Versions of packages apt-listbugs depends on:
ii  apt 1.8.0~alpha2
ii  ruby1:2.5.1
ii  ruby-debian 0.3.9+b8
ii  ruby-gettext3.2.9-1
ii  ruby-soap4r 2.0.5-4
ii  ruby-unicode0.4.4-2+b9
ii  ruby-xmlparser  0.7.3-3+b2

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.8.3-1
ii  s6   2.7.2.2-1

Versions of packages apt-listbugs suggests:
ii  firefox-esr [www-browser]  52.9.0esr-1
ii  konqueror [www-browser]4:18.04.0-1+b2
ii  lynx [www-browser] 2.8.9rel.1-2
ii  reportbug  7.5.1
ii  sensible-utils 0.0.12
ii  w3m [www-browser]  0.5.3-36+b1
ii  xdg-utils  1.1.3-1

-- no debconf information

Bug#917058: ocaml-migrate-parsetree FTBFS:

[Adrian Bunk]

Source: ocaml-migrate-parsetree
Version: 1.0.10-2
Severity: serious
Tags: ftbfs

Some recent change in unstable makes ocaml-migrate-parsetree FTBFS:

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

...
make -j1 install DESTDIR=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp 
AM_UPDATE_INFO_DIR=no 
"INSTALL_ARGS=--destdir=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp 
--libdir=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp/usr/lib/ocaml 
--verbose"
make[2]: Entering directory '/build/1st/ocaml-migrate-parsetree-1.0.10'
jbuilder install --destdir=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp 
--libdir=/build/1st/ocaml-migrate-parsetree-1.0.10/debian/tmp/usr/lib/ocaml 
--verbose
# Workspace root: /build/1st/ocaml-migrate-parsetree-1.0.10
Running[0]: /usr/bin/nproc > /tmp/dune67e2fd.output 2> /dev/null
# # Workspace root: /build/1st/ocaml-migrate-parsetree-1.0.10
# Auto-detected concurrency: 16
Running[1]: /usr/bin/ocamlc.opt -config > /tmp/dune707986.output
# # # Workspace root: /build/1st/ocaml-migrate-parsetree-1.0.10
# # Auto-detected concurrency: 16
# Dune context:
#  ((name default)
#   (kind default)
#   (profile release)
#   (merlin true)
#   (for_host ())
#   (build_dir (In_build_dir default))
#   (toplevel_path ())
#   (ocaml_bin (External /usr/bin))
#   (ocaml (External /usr/bin/ocaml))
#   (ocamlc (External /usr/bin/ocamlc.opt))
#   (ocamlopt ((External /usr/bin/ocamlopt.opt)))
#   (ocamldep (External /usr/bin/ocamldep.opt))
#   (ocamlmklib (External /usr/bin/ocamlmklib.opt))
#   (env
#((CAML_LD_LIBRARY_PATH
#  
/build/1st/ocaml-migrate-parsetree-1.0.10/_build/install/default/lib/stublibs)
# (DUNE_CONFIGURATOR /usr/bin/ocamlc.opt)
# (INSIDE_DUNE 1)
# (MANPATH
#  /build/1st/ocaml-migrate-parsetree-1.0.10/_build/install/default/bin)
# (OCAMLFIND_IGNORE_DUPS_IN
#  /build/1st/ocaml-migrate-parsetree-1.0.10/_build/install/default/lib)
# (OCAMLPATH
#  /build/1st/ocaml-migrate-parsetree-1.0.10/_build/install/default/lib)))
#   (findlib_path ((External /usr/lib/ocaml)))
#   (arch_sixtyfour true)
#   (natdynlink_supported true)
#   (supports_shared_libraries true)
#   (opam_vars ())
#   (ocaml_config
#((version 4.05.0)
# (standard_library_default /usr/lib/ocaml)
# (standard_library /usr/lib/ocaml)
# (standard_runtime /usr/bin/ocamlrun)
# (ccomp_type cc)
# (c_compiler gcc)
# (ocamlc_cflags
#  (-O2
#   -fno-strict-aliasing
#   -fwrapv
#   -D_FILE_OFFSET_BITS=64
#   -D_REENTRANT
#   -fPIC))
# (ocamlopt_cflags
#  (-O2 -fno-strict-aliasing -fwrapv -D_FILE_OFFSET_BITS=64 -D_REENTRANT))
# (bytecomp_c_compiler
#  (gcc
#   -O2
#   -fno-strict-aliasing
#   -fwrapv
#   -D_FILE_OFFSET_BITS=64
#   -D_REENTRANT
#   -fPIC))
# (bytecomp_c_libraries (-lm -ldl -lcurses -lpthread))
# (native_c_compiler
#  (gcc
#   -O2
#   -fno-strict-aliasing
#   -fwrapv
#   -D_FILE_OFFSET_BITS=64
#   -D_REENTRANT))
# (native_c_libraries (-lm -ldl))
# (cc_profile (-pg))
# (architecture amd64)
# (model default)
# (int_size 63)
# (word_size 64)
# (system linux)
# (asm (as))
# (asm_cfi_supported true)
# (with_frame_pointers false)
# (ext_exe )
# (ext_obj .o)
# (ext_asm .s)
# (ext_lib .a)
# (ext_dll .so)
# (os_type Unix)
# (default_executable_name a.out)
# (systhread_supported true)
# (host x86_64-pc-linux-gnu)
# (target x86_64-pc-linux-gnu)
# (profiling true)
# (flambda false)
# (spacetime false)
# (safe_string false)
# (exec_magic_number Caml1999X011)
# (cmi_magic_number Caml1999I021)
# (cmo_magic_number Caml1999O011)
# (cma_magic_number Caml1999A012)
# (cmx_magic_number Caml1999Y015)
# (cmxa_magic_number Caml1999Z014)
# (ast_impl_magic_number Caml1999M020)
# (ast_intf_magic_number Caml1999N018)
# (cmxs_magic_number Caml2007D002)
# (cmt_magic_number Caml2012T009)
# (natdynlink_supported true)
# (supports_shared_libraries true)
# (windows_unicode false)))
#   (which
#((ocaml ((External /usr/bin/ocaml)))
# (ocamlc ((External /usr/bin/ocamlc.opt))
Running[2]: /usr/bin/opam config var prefix > /tmp/dune55264d.output
Output[2]:
[WARNING] Running as root is not recommended
[ERROR] Opam has not been initialised, please run `opam init'
Warning: Command [2] exited with code 50, but I'm ignoring it, hope that's OK.
...
   dh_install
dh_install: Cannot find (any matches for) 
"/usr/lib/ocaml/ocaml-migrate-parsetree/META" (tried in ., debian/tmp)

dh_install: libmigrate-parsetree-ocaml missing files: 
/usr/lib/ocaml/ocaml-migrate-parsetree/META
dh_install: Cannot find (any matches for) 
"/usr/lib/ocaml/ocaml-migrate-parsetree/opam" (tried in ., debian/tmp)

dh_install: 

Bug#916961: octave-symbolic FTBFS: test failures

[Mike Miller]

On Thu, Dec 20, 2018 at 22:29:16 +0200, Adrian Bunk wrote:
> Some recent change in unstable makes octave-symbolic FTBFS:
[…]
> * test
>  % performance: want roughly O(1) not O(n)
>  A = linspace(sym(0), sym(10), 3);  % do one first, avoid caching
>  tic; A = linspace(sym(0), sym(10), 3);   t1 = toc();
>  tic; A = linspace(sym(0), sym(10), 100); t2 = toc();
>  if (t2 >= 10*t1)
>assert (false);
>  end
> ! test failed
> assert (false) failed

This is comparing timing, I guess the results could be fragile and
depend so much on what else the system may be doing. May pass most of
the time but fail randomly. Turn into xtest?

> * test
>  % maple, matrix inputs
>  A = [5.61467232547723663908 20.6144884613920190965];
>  B = pochhammer ([0.9 0.8], [3.1 4.2]);
>  assert (A, B, -eps);
> ! test failed
> ASSERT errors for:  assert (A,B,-eps)
> 
>   Location  |  Observed  |  Expected  |  Reason
> (2)20.6145  20.6145  Rel err 5.1702e-16 exceeds tol 
> 2.2204e-16 by 3e-16

Confirmed in a virtualenv that this is due to the recently released
mpmath version 1.1.0.

Filed upstream issue: https://github.com/cbm755/octsympy/issues/918

Bumping the tolerance seems appropriate.

-- 
mike


signature.asc
Description: PGP signature

Bug#917057: libpolyclipping-dev: pjg-config file contains bogus includedir

[Adrian Bunk]

Package: libpolyclipping-dev
Version: 6.4.2-4
Severity: serious
Control: affects -1 src:cura-engine

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

...
CMake Error at 
/usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find Polyclipping (missing: Polyclipping_INCLUDE_DIRS)
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 
(_FPHSA_FAILURE_MESSAGE)
  cmake/FindPolyclipping.cmake:60 (find_package_handle_standard_args)
  CMakeLists.txt:20 (find_package)


-- Configuring incomplete, errors occurred!


Root cause:

$  cat /usr/lib/x86_64-linux-gnu/pkgconfig/polyclipping.pc
prefix=/usr
exec_prefix=/usr
libdir=lib/x86_64-linux-gnu
sharedlibdir=lib/x86_64-linux-gnu
includedir=include
...


I would suspect the #915267 change as root cause.

Bug#874003: Fixed by both #70 and #75

[Drew Vogel]

I tried both of the fixes mentioned in messages #70 and #75. They both
worked for me. Thanks everyone!

Bug#917056: python-libarchive-c FTBFS with libarchive 3.3.3

[Adrian Bunk]

Source: python-libarchive-c
Version: 2.1-3.1
Severity: serious
Tags: ftbfs buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-libarchive-c.html

...
=== FAILURES ===
_ test_check_archiveentry_using_python_testtar _

def test_check_archiveentry_using_python_testtar():
>   check_entries(join(data_dir, 'testtar.tar'))

tests/test_entry.py:63: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

test_file = '/build/1st/python-libarchive-c-2.1/tests/data/testtar.tar'
regen = False, ignore = []

def check_entries(test_file, regen=False, ignore=''):
ignore = ignore.split()
fixture_file = test_file + '.json'
if regen:
entries = list(get_entries(test_file))
with open(fixture_file, 'w', encoding='UTF-8') as ex:
json.dump(entries, ex, indent=2)
with open(fixture_file, encoding='UTF-8') as ex:
expected = json.load(ex)
actual = list(get_entries(test_file))
for e1, e2 in zip(actual, expected):
for key in ignore:
e1.pop(key)
e2.pop(key)
>   assert e1 == e2
E   AssertionError: assert {'isblk': Fal...': False, ...} == {'isblk': 
Fals...': False, ...}
E Common items:
E {u'isblk': False,
E  u'ischr': False,
E  u'isdev': False,
E  u'isdir': False,
E  u'isfifo': False,
E  u'islnk': False,
E  u'isreg': True,
E  u'issym': False,
E  u'linkpath': None,
E  u'mode': u'rw-r--r--',
E  u'mtime': 1041808783,
E  u'path': u'pax/regtype4'}
E Differing items:
E {'size': 7011} != {'size': 0}
E Full diff:
E {u'isblk': False,
E u'ischr': False,
E u'isdev': False,
E u'isdir': False,
E u'isfifo': False,
E u'islnk': False,
E u'isreg': True,
E u'issym': False,
E u'linkpath': None,
E u'mode': u'rw-r--r--',
E u'mtime': 1041808783,
E u'path': u'pax/regtype4',
E -  u'size': 7011}
E ?   - --
E +  u'size': 0}

tests/test_entry.py:96: AssertionError
-- Captured log call ---
ffi.py  82 WARNING  Pathname can't be converted from UTF-8 
to current locale.
= 1 failed, 15 passed in 0.30 seconds ==
make[1]: *** [debian/rules:9: override_dh_auto_test] Error 1

Bug#917055: blktool FTBFS with glibc 2.28

[Adrian Bunk]

Source: blktool
Version: 4-7
Severity: serious
Tags: ftbfs buster sid

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

...
blktool.c: In function 'detect_dev_class':
blktool.c:295:10: warning: implicit declaration of function 'major' 
[-Wimplicit-function-declaration]
  switch (major(st_rdev)) {
  ^
...
gcc -Wall -g -O2 -ffile-prefix-map=/build/1st/blktool-4=. 
-fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro -o 
blktool  blktool.o ata.o scsi.o util.o -lglib-2.0 
/usr/bin/ld: blktool.o: in function `detect_dev_class':
./blktool.c:295: undefined reference to `major'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:254: blktool] Error 1

Bug#917054: Template parse error near `in Sekunden.', in stanza #18 of /var/lib/dpkg/info/dump1090-mutability.templates

[Matthew W.S. Bell]

Package: dump1090-mutability
Version: 1.15~20180310.4a16df3+dfsg-4
Severity: grave

This version of the package is uninstallable:

Setting up dump1090-mutability (1.15~20180310.4a16df3+dfsg-4) ...
Template parse error near `in Sekunden.', in stanza #18 of 
/var/lib/dpkg/info/dump1090-mutability.templates
dpkg: error processing package dump1090-mutability (--configure):
 installed dump1090-mutability package post-installation script subprocess 
returned error exit status 25

Examining the package's template file reveals that, in the stanza for
dump1090-mutability/net-out-interval, wrapping of multiple lines is not as
rfc2822(?) records require. This seems to be the only issue, and resolving
it allows the package to finish installing.

Matthew W.S. Bell





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

Bug#917053: nmu: openmsx_0.15.0-2

[Adrian Bunk]

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

nmu openmsx_0.15.0-2 . amd64 . unstable . -m "Rebuild in clean sid chroot"

The maintainer-uploaded binary depends on libtcl8.5 which is
not even in unstable anymore.

Source-only uploads avoid such problems.

Bug#917052: elpa-xml-rpc: Hangs infinitely when compiling for emacs 1:26.1+1-2

[Axel Beckert]

Package: elpa-xml-rpc
Version: 1.6.12-2
Severity: serious

Hi,

when upgrading emacs from 1:25.2+1-11 to 1:26.1+1-2, it hangs
infinitely at "install/xml-rpc-1.6.12: byte-compiling for emacs".

Relevant parts of an "ps auxwwwf" output:

root  5644  0.0  0.0   2392   768 pts/4S+   00:54   0:00
  \_ /bin/sh /var/lib/dpkg/info/emacs-gtk.postinst configure 1:25.2+1-11
root  5647  0.0  0.0  19168 11604 pts/4S+   00:54   0:00
  \_ /usr/bin/perl -w /usr/lib/emacsen-common/emacs-install emacs
root  5893  0.0  0.0  0 0 pts/4Z+   00:54   0:00
  \_ [emacs-install] 
root  6179  0.0  0.0   2392   772 pts/4S+   00:55   0:00
  \_ /bin/sh /usr/lib/emacsen-common/packages/install/elpa-xml-rpc emacs
root  6182  0.0  0.0   2392   108 pts/4S+   00:55   0:00
  \_ /bin/sh /usr/lib/emacsen-common/packages/install/elpa-xml-rpc 
emacs
root  6183 99.9  0.0 274740 41712 pts/4Rl+  00:55  18:39
  \_ emacs -q -batch -l package --eval (add-to-list 
'package-directory-list "/usr/share/emacs/site-lisp/elpa-src") -f 
package-initialize -f batch-byte-compile xml-rpc-autoloads.el xml-rpc-pkg.el 
xml-rpc.el

Please note the over 18 minutes of CPU time of process 6183.

Please feel free to reassign this to emacs in case you think this is
an issue with emacs 26.1 itself and not with this elpa package.

P.S.: This looks very similar to https://bugs.debian.org/917050
against elpa-markdown-mode.

-- 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.18.0-3-amd64 (SMP w/8 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 elpa-xml-rpc depends on:
ii  emacsen-common  3.0.4

Versions of packages elpa-xml-rpc recommends:
iu  emacs  1:26.1+1-2
ih  emacs-gtk [emacs]  1:26.1+1-2

elpa-xml-rpc suggests no packages.

-- no debconf information

Bug#916979: Octave recent build only has grahics toolkit gnuplot; qt and fltk are missing

[Mike Miller]

On Fri, Dec 21, 2018 at 09:05:36 +0100, Sébastien Villemot wrote:
> I think it would make sense to add an autopkgtest for that specific
> issue, to detect it should it appear again.
> 
> The only drawback with respect to putting it as a failure in
> debian/rules is that autopkgtest are only routinely exercised on amd64.

Ok, how about something like the attached? This can be extended to check
for other features (arpack, SuiteSparse, etc) that we want to require.

Could this not also be run in the dh_auto_test target to cover all
arches at least once when they are built?

-- 
mike


octave-features.sh
Description: Bourne shell script


signature.asc
Description: PGP signature

Bug#917051: Debian test (10) installer, storage issues

[Brian Wengel]

Package: installer (debian-testing-amd64-DVD-1.iso

2018-12-17)
Version: test

I experience two issues in regards to the Detect disk and Modify partitions
parts of the installer.
I have an Samsung NVMe PM981 500GB, the installer couldn't see the drive at
all!
Secondly I could not any option to delete an existing partition.

I think to recall I could do this in ver <= 9.6

Boot from USB flash, EFI.
CPU i3 6100
Chipset: Intel C236

Bug#912048: obs-build: FTBFS: Test failures

[Santiago Vila]

On Fri, 21 Dec 2018, Hector Oron wrote:

> If you think the package still FTBFS, please reply this message and I'll
> re-try to reproduce it one more time.

Hello, I'm not Daniel, but I can reproduce this in my own autobuilders,
and the package still FTBFS in reproducible-builds:

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

The following message in the build log:

> Can't locate Date/Parse.pm in @INC (you may need to install the Date::Parse 
> module)

seems suspicious to me. Are you sure you tried to build the package in
a clean minimal chroot?

Thanks.

Bug#912048: obs-build: FTBFS: Test failures

[Adrian Bunk]

Control: severity -1 serious

On Fri, Dec 21, 2018 at 04:43:01PM +0100, Hector Oron wrote:
> Hello,
> 
> On Sat, Oct 27, 2018 at 08:45:29AM -0700, Daniel Schepler wrote:
> > Source: obs-build
> > Version: 20180831-1
> > Severity: serious
> > Tags: ftbfs
> 
> Sadly I am unable to reproduce it and the build runs fine here.
> I'll downgrade severity of this bug to allow it re-enter Buster again.
> 
> If you think the package still FTBFS, please reply this message and I'll
> re-try to reproduce it one more time.

Please try in a minimal environment without any surplus packages installed,
similar to what the buildds do.

As the error message already indicates, the package fails to build
without libtimedate-perl installed.

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#917050: Hangs infinitely when compiling for emacs 1:26.1+1-2

[Axel Beckert]

Package: elpa-markdown-mode
Version: 2.3+154-1
Severity: serious

Hi,

when upgrading emacs from 1:25.2+1-11 to 1:26.1+1-2, it hangs
infinitely at "install/markdown-mode-2.3snapshot154: byte-compiling
for emacs".

Relevant parts of an "ps auxwwwf" output:

root 20406  0.0  0.0   2388   764 pts/18   S+   Dec21   0:00  
\_ /bin/sh /var/lib/dpkg/info/emacs-gtk.postinst configure 1:25.2+1-11
root 20409  0.0  0.0  18984 11432 pts/18   S+   Dec21   0:00
  \_ /usr/bin/perl -w /usr/lib/emacsen-common/emacs-install emacs
root 20682  0.0  0.0  0 0 pts/18   Z+   Dec21   0:00
  \_ [emacs-install] 
root 20820  0.0  0.0   2388   764 pts/18   S+   Dec21   0:00
  \_ /bin/sh /usr/lib/emacsen-common/packages/install/elpa-markdown-mode 
emacs
root 20823  0.0  0.0   2388   100 pts/18   S+   Dec21   0:00
  \_ /bin/sh 
/usr/lib/emacsen-common/packages/install/elpa-markdown-mode emacs
root 20824 99.9  0.0 274260 41400 pts/18   Rl+  Dec21 526:43
  \_ emacs -q -batch -l package --eval (add-to-list 
'package-directory-list "/usr/share/emacs/site-lisp/elpa-src") -f 
package-initialize -f batch-byte-compile markdown-mode-autoloads.el 
markdown-mode-pkg.el markdown-mode.el

Please note 526 minutes (!) CPU time of process 20824.

Please feel free to reassign this to emacs in case you think this is
an issue with emacs 26.1 itself and not with this elpa package.

-- 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.18.0-3-amd64 (SMP w/8 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 elpa-markdown-mode depends on:
iu  emacs1:26.1+1-2
iu  emacs-gtk [emacsen]  1:26.1+1-2
ii  emacsen-common   3.0.4

elpa-markdown-mode recommends no packages.

elpa-markdown-mode suggests no packages.

-- no debconf information

Bug#878193: fails to start with minimal dependencies from testing

[Adrian Bunk]

On Fri, Dec 21, 2018 at 09:07:19AM +0100, intrigeri wrote:
> Hi,
> 
> AFAICT:
> 
>  - This bug is about installing packages from testing/sid on stable,
>i.e. partial upgrade, which is not supported.

This is kinda supported, and there are important usecases that have
a big overlap with it:
- ensuring everything continues working during an upgrade
  (might not be applicable in this specific case)
- ensuring the package does not migrate to testing too early
- ensuring the package works if backported

>  - Two different workarounds were documented (one visible here and one
>erroneously sent to cont...@bugs.debian.org:
>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878193;msg=7)
> 
> So I don't understand why this bug should be RC for Buster: it does
> not actually affect Buster and there's no supported upgrade path given
> PuppetDB was not part of any Debian stable release yet.
> 
> Adrian, what do you think? Thanks in advance!

Ignoring the severity question, versioning the dependencies
on the 5 packages mentioned in the workaround should not be
a controversial thing. It would at least ensure that noone
will create a broken backport to stretch.

But there is a real blocker hidden in the workaroud:
  # java-1.8 should be the default runtime, if it's not check 
update-alternatives

The date when the autopkgtest started failing also indicate that the
package might be broken with Java >= 9, and buster will use Java 11.

> Cheers,

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#917018: wget: Unusable - permanent segmentation fault

[Bernhard Übelacker]

Hello rwpenney,
just tried to reproduce and collect some information for the maintainer
on a minimal buster amd64 qemu VM.

Unfortunately I could not reproduce the crash
and after 700 files I stopped my test.

Maybe you could run the wget command like that:

gdb -q -ex 'set pagination off' -ex 'set width 0' -ex run -ex bt -ex detach 
-ex quit --args wget -r -k -l inf http://www.debian.org

Or you install a coredump collector like systemd-coredump and
provide the output of journalctl for that time.

In [1] are also some points to get more information into the backtrace.

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace

Bug#917049: ITP: erlang-horse -- Erlang library for integrated performance testing

[Nobuhiro Iwamatsu]

Package: wnpp
Severity: wishlist
Owner: Nobuhiro Iwamatsu 

* Package name: erlang-horse
  Version : 0+git20161117.0.4dc81d4
  Upstream Author : Loïc Hoguin 
* URL : https://github.com/ninenines/horse
* License : ISC
  Programming Lang: (Erlang)
  Description: Erlang library for integrated performance testing

 erlang-horse is designed to provide quick feedback on the performance
 of units of code, for example a function or a group of functions.
 .
 This works in a manner similar to the `eunit` application: it
 will export automatically all the performance test functions,
 run them one after another and give you a convenient report.

Bug#914373: documenting octave packages need to be loaded

[Mike Miller]

On Wed, Dec 19, 2018 at 20:01:44 +, David Pinto wrote:
> However, this does not happen for chi2inv which is the function
> mentioned on the bug report.  The issue here is that the internal list
> of functions belonging to packages need to be updated in Octave so the
> user gets a message informing that packages need to be loaded
> explicitly.

This is now done for Octave 5 [1], can be cherry-picked to fix #914391.

> This is another issue in Octave.  chi2inv used to be part of Octave
> core but got moved to the statistics package for Octave 4.4 version.
> The Octave manual should no longer be referring chi2inv.

I think the only place it is mentioned is Appendix C Obsolete Functions.
I've filed an upstream bug [2] to address that. Were there any other
mentions I missed?

[1]: https://hg.savannah.gnu.org/hgweb/octave/rev/d41d137af059
[2]: https://savannah.gnu.org/bugs/?55265

-- 
mike


signature.asc
Description: PGP signature

Bug#917026: xorg: All the system freezes when ejects an USB stick with Thunar

[Bernhard Übelacker]

Hello Alain,
just saw your report and though it sounds similar to another one [1].
Do you have linux-image in version 4.9.130-2 installed?
Were older kernels working like expected?
If possible you might want also check if reverting back
to 4.9.110-3+deb9u6 gives you a not hanging system on eject.

Kind regards,
Bernhard

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914696

Bug#917048: cargo: Please drop patch to disable incremental builds on sparc64

[John Paul Adrian Glaubitz]

Source: cargo
Version: 0.31.1-1
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

We have finally figured why incremental builds are not working on
sparc64 which turned out to be a bug in the file locking API of
the Rust compiler [1].

While upstream hasn't fixed the bug yet, I have provided a temporary
fix for the bug in #917000 [2]. Once this bug has been fixed, incremental
builds work fine on sparc64 and the patch to disable incremental builds
in cargo, 2007_sparc64_disable_incremental_build.patch, is no longer
needed.

I am therefore setting this bug as blocked by #917000.

Thanks,
Adrian

> [1] https://github.com/rust-lang/rust/issues/57007
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917000

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#916346: crrcsim: diff for NMU version 0.9.13-3.1

[Adrian Bunk]

Control: tags 916346 + patch
Control: tags 916346 + pending

Dear maintainer,

I've prepared an NMU for crrcsim (versioned as 0.9.13-3.1) and uploaded 
it to DELAYED/5. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

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

diff -Nru crrcsim-0.9.13/debian/changelog crrcsim-0.9.13/debian/changelog
--- crrcsim-0.9.13/debian/changelog	2018-12-01 17:49:34.0 +0200
+++ crrcsim-0.9.13/debian/changelog	2018-12-22 01:02:57.0 +0200
@@ -1,3 +1,11 @@
+crrcsim (0.9.13-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch back to the libjpeg that will be in buster.
+(Closes: #916346)
+
+ -- Adrian Bunk   Sat, 22 Dec 2018 01:02:57 +0200
+
 crrcsim (0.9.13-3) unstable; urgency=medium
 
   * Fix sys/io unsupported, defining dummy interfaces for io operations
diff -Nru crrcsim-0.9.13/debian/control crrcsim-0.9.13/debian/control
--- crrcsim-0.9.13/debian/control	2018-12-01 17:49:34.0 +0200
+++ crrcsim-0.9.13/debian/control	2018-12-22 01:02:43.0 +0200
@@ -10,7 +10,7 @@
  libboost-thread-dev,
  libplib-dev,
  libcgal-dev,
- libjpeg9-dev,
+ libjpeg-dev,
  portaudio19-dev,
 Standards-Version: 4.1.4
 Homepage: http://crrcsim.berlios.de

Bug#917047: avahi: CVE-2018-1000845: DNS amplification and reflection to spoofed addresses

[Salvatore Bonaccorso]

Source: avahi
Version: 0.6.32-2
Severity: important
Tags: security upstream
Forwarded: https://github.com/lathiat/avahi/issues/203
Control: found -1 0.7-4

Hi,

The following vulnerability was published for avahi, filling to start
tracking the issue.

CVE-2018-1000845[0]:
| Avahi version 0.7 contains a Incorrect Access Control vulnerability in
| avahi-daemon that can result in Traffic reflection and amplification
| for DDoS attacks.. This attack appear to be exploitable via unicast IP
| network packet with spoofed source address.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-1000845
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000845
[1] https://github.com/lathiat/avahi/issues/203
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1661252

Regards,
Salvatore

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Bernhard Übelacker]

Hello Brian Potkin,
you might have a look at following commands to build a
complete local cups-browsed package with the upstream
patch included.

That may work better, as a plain make built shared lib
might be not enough compatible with the executable from
the debian package.

Just if you do not want to wait until the upstream
change hits testing.

Kind regards,
Bernhard



(as root)
apt install dpkg-dev devscripts
apt build-dep cups-filters


(as user)
mkdir ~/source/cups-filters -p
cd~/source/cups-filters
apt source cups-filters
cd cups-filters-1.21.4
dch --local local "Rebuild for #916765"

wget 
https://github.com/OpenPrinting/cups-filters/commit/ef71337fc231eb712a737ffd9aa6d32a95920457.patch
 -O - | patch -p1
find -iname "*.rej"
# should just output ./NEWS.rej

dpkg-buildpackage -b


(as root)
cd /home/user/source/cups-filters

dpkg -l | grep -E " $(ls -1 *.deb | cut -d_ -f 1 | xargs echo | sed 's/ /|/g') 
" | awk '{print $2}' | sed 's/:i386//' | awk '{print $1 "_*.deb"}' | xargs echo 
dpkg -i
# check the output from above command and if ok execute it, should just install 
already installed files ...

Bug#916933: RFS: libgsm/1.0.18-1 [ITA]

[Felix Lechner]

Hi Adam,

On Fri, Dec 21, 2018 at 11:27 AM Adam Borowski  wrote:

>
> Hi;
> the package has been for some reason removed from mentors, despite no one
> uploading anything.  Could you tell me if there's a version you'd want in?
>

I removed the package from Mentors in order to upload another one, but made
a mistake and aborted with ^C. After that, Mentors refused additional
uploads with 403 Forbidden. In the past, I have had success after waiting
for Mentors to clean up the incoming queue. This morning I saw the RFS bug
was closed automatically as a result. It was an inadvertent chain of events.


> I'd be happy with either a hard break or a compat link -- it's up to you
> and
> your upstream wrt what is preferred.  I believe we know enough; thanks for
> your work so far.
>

The software is from 1992. I may contact them to get guidance.


> So please give me something to re-test and upload.
>

 I will be back with a new version in a few days. Thank you for your
cooperation so far!

Bug#915130: [debian-mysql] Bug#915130: Further information

[Faustin Lammler]

Yannik Sembritzki ,
21/12/2018 - 23:00:33 (+0100):

> thanks for linking the upstream bugreport!
> Seeing that it is from 2015, it would be great to get some traction on
> this and finally have this fixed in the debian repo as well :-)
Of course and I think this should not be so difficult. But currently
most of the forces are working on including 10.3 in the next stable
Debian release so I don't know when this issue will be resolved.

> By the way, did you check whether this is fixed in 10.3 only or also in
> the 10.1 package from the mariadb.org repositories.
As said, I have tested 10.1 and 10.3 from mariadb repo, they are both
OK.

If you have time and want to contribute on a patch, feel free to read
this :-)
https://wiki.debian.org/Teams/MySQL/patches

Have a nice week-end,
-- 
Faustin Lammler

Bug#917046: mesa: ease cross build dependency installability

[Héctor Orón Martínez]

Source: mesa
Version: 18.3.0-1
Severity: wishlist
Tags: patch

Dear Maintainer,

  Please consider easing cross dependency installability.
  Find propose patch:
  https://salsa.debian.org/xorg-team/lib/mesa/merge_requests/6

Regards

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

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

Bug#917045: mako: support nocheck build profiles

[Héctor Orón Martínez]

Source: mako
Version: 1.0.7+ds1-1
Severity: wishlist
Tags: patch

Dear Maintainer,

  Please consider adding build profile for nocheck.
  Find proposed patch at:
  https://salsa.debian.org/python-team/modules/mako/merge_requests/3

Regards

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

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

Bug#917044: mako: add support for nodoc

[Héctor Orón Martínez]

Source: mako
Version: 1.0.7+ds1-1
Severity: wishlist

Dear Maintainer,

  Please consider adding support for nodoc.
  Find proposed patch at:
  https://salsa.debian.org/python-team/modules/mako/merge_requests/2  

Regards

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

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

Bug#917043: mako: fix clean target

[Héctor Orón Martínez]

Source: mako
Version: 1.0.7+ds1-1
Severity: important

Dear Maintainer,

  When building `mako` twice the package fails to clean.

  Please consider
  https://salsa.debian.org/python-team/modules/mako/merge_requests/1

Regards

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

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

Bug#917042: dtfabric: Wrong name

[Hilko Bengen]

Package: dtfabric
Version: 20180808-1
Severity: serious
Control: tag -1 pending

Dear Maintainer,

the dtfabric package is a Python3 library which means that its name must
be prefixed with "python3-". (Python policy 3.3)

I am marking this bug as pending because I intend to upload a new
version that will fix this bug -- and will add a Python 2 package, in
order to be able to fix #914607 without having to migrate Plaso to
Python 3 _right now_.

Cheers,
-Hilko

Bug#916223: moonshot-gss-eap: FTBFS against xmltooling 3

[Sebastian Andrzej Siewior]

On 2018-12-11 18:26:24 [-0500], Sam Hartman wrote:
> Fixing moonshot-gss-eap and getting a new moonshot-ui is next up for me
> for Debian weekend tasks.

This means an upload from exp to unstable?

Sebastian

Bug#916054: procmeter3 FTBFS with glibc 2.28

[Aurelien Jarno]

control: tag -1 + patch

On 2018-12-09 19:12, Adrian Bunk wrote:
> Source: procmeter3
> Version: 3.6-1
> Severity: serious
> Tags: ftbfs buster sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/procmeter3.html
> 
> ...
> longrun.c:41:24: error: unknown type name 'loff_t'; did you mean 'off_t'?
>  static void read_cpuid(loff_t address, int *eax, int *ebx, int *ecx, int 
> *edx) {
> ^~

Please find below a patch to fix the issue.

diff -Nru procmeter3-3.6/debian/patches/loff_t.patch 
procmeter3-3.6/debian/patches/loff_t.patch
--- procmeter3-3.6/debian/patches/loff_t.patch  1970-01-01 00:00:00.0 
+
+++ procmeter3-3.6/debian/patches/loff_t.patch  2018-12-21 21:50:55.0 
+
@@ -0,0 +1,18 @@
+Description: Fix compilation with newer glibc
+Fixes compilation with newer glibc.
+If _XOPEN_SOURCE is defined _DEFAULT_SOURCE needs to be defined explicit
+to have the definition of loff_t.
+Author: Aurelien Jarno 
+Bug-Debian: https://bugs.debian.org/916054
+Last-Update: 2018-12-21
+
+--- procmeter3-3.6.orig/modules/longrun.c
 procmeter3-3.6/modules/longrun.c
+@@ -15,6 +15,7 @@
+   ***/
+ 
+ #define _XOPEN_SOURCE 500
++#define _DEFAULT_SOURCE
+ 
+ #include 
+ #include 
diff -Nru procmeter3-3.6/debian/patches/series 
procmeter3-3.6/debian/patches/series
--- procmeter3-3.6/debian/patches/series2014-03-22 15:38:22.0 
+
+++ procmeter3-3.6/debian/patches/series2018-12-21 21:50:55.0 
+
@@ -6,3 +6,4 @@
 #include.patch
 dont-override-flags.patch
 libX11.patch
+loff_t.patch

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

Bug#916012: emacs-gtk crashes when rendering U+2728 SPARKLES

[Daniel Kahn Gillmor]

Control: found 916012 1:26.1+1-2

running emacs-gtk 26.1 from unstable, I still get crashes on U+2728
SPARKLES .  I'm also seeing a crash when trying to render U+26C4 SNOWMAN
WITHOUT SNOW.

interestingly, U+1F332 EVERGREEN TREE gives no problems :)

A stderr transcript from one such crash:

X protocol error: BadLength (poly request too large or internal Xlib
length error) on protocol request 139
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
Fatal error 6: Aborted
(emacs:21625): GLib-WARNING **: 17:05:05.830: g_main_context_prepare()
called recursively from within a source's check() or prepare() member.

(emacs:21625): GLib-WARNING **: 17:05:05.830: g_main_context_check()
called recursively from within a source's check() or prepare() member.

Backtrace:
emacs[0x5114ae]
emacs[0x4f6eda]
emacs[0x511553]
emacs[0x4c3f83]
emacs[0x4c7da9]
emacs[0x4c7e2b]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x11a)[0x7f1d561cf11a]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x43077)[0x7f1d561cc077]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x4311d)[0x7f1d561cc11d]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XEventsQueued+0x55)[0x7f1d561cca55]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XPending+0x57)[0x7f1d561be7b7]
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x68fad)[0x7f1d56c44fad]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_prepare+0x1c9)[0x7f1d5673e379]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4dd7b)[0x7f1d5673ed7b]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_pending+0x27)[0x7f1d5673ef17]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_events_pending+0xd)[0x7f1d56f143ed]
emacs[0x4c4977]
emacs[0x4fe129]
emacs[0x4fe7d5]
emacs[0x5d8aa7]
emacs[0x586a84]
emacs[0x5db58a]
emacs[0x5db811]
emacs[0x5dbb1c]
emacs[0x4484c3]
emacs[0x44f790]
emacs[0x45458b]
emacs[0x467022]
emacs[0x46abeb]
emacs[0x56cdf6]
emacs[0x434862]
emacs[0x457d75]
emacs[0x459c85]
emacs[0x41d152]
emacs[0x56dc0c]
emacs[0x5a5130]
emacs[0x5704dc]
emacs[0x56db8b]
emacs[0x56dc98]
emacs[0x56cf32]
emacs[0x4f78c4]
...
Aborted

Regards,

--dkg

Bug#914607: Re-adding python-dfwinreg

[Hilko Bengen]

Good evening.

I am going to re-add the Python2 package for dfwinreg which was removed
by SZ Lin for 20181214-1. This might take a few days to resolve because
I think the package will have to go through NEW again.

A bunch of Plaso dependencies and eventually plaso itself will need to
be updated, too, I'll work on that over the next few days -- perhaps we
can even remove the Python2 packages before the buster release again.

Cheers,
-Hilko

Bug#915130: [debian-mysql] Bug#915130: Further information

[Yannik Sembritzki]

Hi Faustin,

thanks for linking the upstream bugreport!
Seeing that it is from 2015, it would be great to get some traction on
this and finally have this fixed in the debian repo as well :-)

By the way, did you check whether this is fixed in 10.3 only or also in
the 10.1 package from the mariadb.org repositories.

Best regards
Yannik

Bug#914440: photocollage: diff for NMU version 1.4.3-2.1

[Adrian Bunk]

Control: tags 914440 + patch
Control: tags 914440 + pending

Dear maintainer,

I've prepared an NMU for photocollage (versioned as 1.4.3-2.1) and 
uploaded it to DELAYED/9. Please feel free to tell me if I should
cancel it.

cu
Adrian

-- 

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

diff -Nru photocollage-1.4.3/debian/changelog photocollage-1.4.3/debian/changelog
--- photocollage-1.4.3/debian/changelog	2016-12-22 22:13:40.0 +0200
+++ photocollage-1.4.3/debian/changelog	2018-12-21 23:49:53.0 +0200
@@ -1,3 +1,10 @@
+photocollage (1.4.3-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing dependency on gir1.2-gtk-3.0. (Closes: #914440)
+
+ -- Adrian Bunk   Fri, 21 Dec 2018 23:49:53 +0200
+
 photocollage (1.4.3-2) unstable; urgency=medium
 
   * Add missing 'python3-six' to dependencies
diff -Nru photocollage-1.4.3/debian/control photocollage-1.4.3/debian/control
--- photocollage-1.4.3/debian/control	2016-12-22 22:13:10.0 +0200
+++ photocollage-1.4.3/debian/control	2018-12-21 23:49:53.0 +0200
@@ -15,6 +15,7 @@
  ${misc:Depends},
  ${python3:Depends},
  python3-gi-cairo,
+ gir1.2-gtk-3.0,
  python3-six,
 Description: Graphical tool to make photo collage posters
  PhotoCollage allows you to create photo collage posters. It assembles

Bug#915130: [debian-mysql] Bug#915130: Further information

[Faustin Lammler]

Hi Yannik,
thanks for your report!

I am able to reproduce this and the problem is only present in the
Debian package version of MariaDB.

This bug seems also described there:
https://jira.mariadb.org/browse/MDEV-8457

If this is an acceptable solution until the bug is resolved, you can use
the 10.1 (on 10.3 it is working too) version from official MariaDB
repository.
https://downloads.mariadb.org/mariadb/repositories/

Regards,
Faustin

Bug#917041: golang-github-influxdata-influxql: Outdated version produces empty results for some queries

[Guillem Jover]

Source: golang-github-influxdata-influxql
Source-Version: 0.0~git20180330.145e067-2
Severity: serious

Hi!

This package is a bit outdated and it causes some queries to produce
empty results. We noticed this with our internal influxdb version, when
grafana was not showing some graphs for some stuff, and packaging and
upgrading it to 0.0~git20180925.1cbfca8-0.1 and rebuilding influxdb with
that fixed the issues. I think there are multiple upstream reports about
this, which I'll be commenting on, as they seem to be undiagnosed there.

A reproducer with packages from Debian sid follows:

  ,---
  $ influx
  Connected to http://localhost:8086 version 1.6.4
  InfluxDB shell version: 1.6.4
  > quit
  $ curl https://s3.amazonaws.com/noaa.water-database/NOAA_data.txt \
  -o NOAA_data.txt
  $ influx -import -path=NOAA_data.txt -precision=s \
  -database=NOAA_water_database
  $ influx -database NOAA_water_database \
  -execute 'show tag values with key = "randtag"'
  $
  `---

While that should be returning something like:

  ,---
  name: h2o_quality
  key   value
  ---   -
  randtag   1
  randtag   2
  randtag   3
  `---

Thanks,
Guillem

Bug#917040: ITP: python-ifaddr -- Pure Python implementation for detecting IP addresses

[Ruben Undheim]

Package: wnpp
Severity: wishlist
Owner: Ruben Undheim 

* Package name: python-ifaddr
  Version : 0.1.6
  Upstream Author : Stefan C. Mueller
* URL : https://pypi.org/project/ifaddr/
* License : MIT
  Programming Lang: Python
  Description : Pure Python implementation for detecting IP addresses


ifaddr is a small Python library that allows you to find all the IP addresses
of the computer.

The library python-netifaces provides similar functionality but is harder to
install since it has C-components which must be built.


python-ifaddr is required in Debian since the newer versions of python-zeroconf
depends on it.

It will be maintained in the Python modules team.

Bug#916428: Info received (Bug#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7)

[Thadeu Lima de Souza Cascardo]

Bisecting python, I found out 019f0a0cb85ebc234356415f3638b9bd77528e55
("bpo-34536: raise error for invalid _missing_ results (GH-9147)")
causes the issue.

Yet another reduction was possible, and now I can reproduce that python
issue on python3.6 as well. I know this is not the best place to report
it, but as it's the root cause of this issue and I don't want to waste
the investigation effort before I head to a long holiday, here is the
reproducer.

By the way, I reverted said patch and the other reproducer worked fine,
yet have to test with autopkgtest-virt-qemu itself.

Cascardo.
import socket

def test_tty():
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
try:
raise ValueError("value error")
except ValueError as e:
exc = e
pass

test_tty()

Bug#917025: tracker.debian.org: 0 new commits since last upload

[Mattia Rizzolo]

Control: reassign -1 qa.debian.org

On Fri, Dec 21, 2018 at 07:11:18PM +0300, Sergey B Kirpichev wrote:
> Not sure if this is a duplicate of #910987, but I see the problem.

Not quite.  However, it's not a problem coming from tracker, rather by
the data source it uses.

> Right now interface on https://tracker.debian.org/pkg/monit shows:

FWIW, I see the issue is now gone from that package, however I saw it
elsewhere today (but was too lazy to report).

I'm reassigning to the right pseudo-package, CCing the maintainer of the
vcswatch service. :)

> -->8--
>  action needed
>  0 new commits since last upload, time to upload? normal
>  vcswatch reports that this package seems to have a new changelog entry
>  (version 1:5.25.2-2, distribution unstable) and new commits in its VCS.
>  You should consider whether it's time to make an upload.
> 
>  Here are the relevant commit messages:
> 
>  None
> 
>  Created: 2018-12-21 Last update: 2018-12-21 15:05
> -->8---
> 
> Latest commit is 727f110b (tagged then, after several minutes,
> everything was pushed to the public repo _before_ upload to
> the debian archive was done).
> 

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#917039: RFP: pyphen -- Python hyphenation module

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist

* Package name: pyphen
  Version : 0.9.5
  Upstream Author : Guillaume Ayoub 
* URL : https://pyphen.org/
* License : GPL 2.0+/LGPL 2.1+/MPL 1.1
  Programming Lang: Python
  Description : Python hyphenation module


Pyphen is a pure Python module to hyphenate text using existing
Hunspell hyphenation dictionaries. This module is a fork of
python-hyphenator, written by Wilbert Berendsen.

Pyphen is a dependency of weasyprint, which i want to see in debian,
because an upcoming version of xml2rfc is likely to use it (and
because weasyprint looks very useful more generally, RFP to follow
shortly).

Note that upstream pyphen ships a copy of all the hyphenation
libraries.  Packaging it for debian ought probably to Depend:
hyphen-hyphenation-patterns instead.

Bug#917038: RFP: weasyprint -- Visual rendering engine for HTML and CSS that can export to PDF

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist

* Package name: weasyprint
  Version : 43
  Upstream Author : Simon Sapin 
* URL : https://weasyprint.org/
* License : BSD
  Programming Lang: Python
  Description : Visual rendering engine for HTML and CSS that can export to 
PDF

WeasyPrint is a visual rendering engine for HTML and CSS that can
export to PDF. It aims to support web standards for printing.

It is based on various libraries but *not* on a full rendering engine like
WebKit or Gecko. The CSS layout engine is written in Python, designed for
pagination, and meant to be easy to hack on.

-

WeasyPrint is useful on its own, especially as other options for
generating pdf from html have often embedded unsupported or
unmaintained embedded rendering engines (like webkit or gecko).  It is
also likely to be a dependency for an upcoming version of xml2rfc, for
generating its PDF outputs, which is where i stumbled across it.

Bug#917037: ITP: python3-zeroconf -- Pure Python implementation of multicast DNS service discovery (Python3)

[Ruben Undheim]

Package: wnpp
Severity: wishlist
Owner: Ruben Undheim 

* Package name: python3-zeroconf
  Version : 0.21.3
  Upstream Author : Jakub Stasiak
* URL : https://github.com/jstasiak/python-zeroconf
* License : LGPL-2.1+
  Programming Lang: Python-3
  Description : Pure Python implementation of multicast DNS service 
discovery (Python3)


python-zeroconf already exists in the Debian archive. However, upstream has
dropped support for Python 2, and there are reverse dependencies in Debian
which depend on the Python 2 package. This makes it necessary with a separate
source package for the Python 3 version.

See https://tracker.debian.org/pkg/python-zeroconf for more infor about
python-zeroconf.

Bug#917036: libswagger2-perl: dead upstream

[Jonas Smedegaard]

Package: libswagger2-perl
Version: 0.89-1
Severity: serious

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Homepage https://metacpan.org/release/Swagger2 is a 404 Not Found error.

Package has no reverse dependencies.

Severity raised to avoid getting it included with Buster.
Please lower if someone disagrees.


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlwdVC4ACgkQLHwxRsGg
ASFP6w//TgHQTR5JcU6f5uZrwWc+0JbaOvj7Viy3s7vuKW3Kk2Z165NsDSBbApU2
ezyFnPviT+IwqEOCjytXiE5GnPhf4C39r5d9dB9qy9a8zywmURLWMe4wEsHUeYnx
qvOkrpaRT1XG3UUqSrNDrmkHqRgWOVEXLf0RkyaNRsWHuI2AfhYkLb/SuMQf1hdd
rpdBXnQwtUMMrV6OyJ7FzvEuTYE6iOzDV8fj0FbZsI0WsLKA7e44qkvqDZBZWQw+
YEoJK54kUQIBYTTZ6nESP0zrj8a8IEuVXBC4fbexrbX9Jql8VEEYRecaSWK8ps2q
19WKIa+h4WaTDj5YTWDbaf8J4zVXdkRp6Zg+zKJUa5myOXOuAAkMcGc/eJnLLk6T
Q+puxA/KwoUsLrNt9/web2Kp2UDJP9o/jrvntU+SRkmrlDxl2HWdgk8tlknBDlJg
73NP1vbv73UWt72SP8OwhgfUBizEOjw7zd++OI6ECa+lYZleZi4xpBl/A5cLXWbv
NKOaDzPjIf4xhg8kyeZgoEg6ZVLNo9AxVGIDFqLDlOYF4LeR9wOXJuzsEJVkR9zP
U3GCDw2X3xazcvorEQuaHE9QDsyUh0NtAs6dC7fAwXOkqQDhLsR5o21m5nWXVViF
1SLhz8Sj0eDT1zboFknwOQkyykXaDfH9VDNXrBealjMY1ZegoBM=
=MVBf
-END PGP SIGNATURE-

Bug#915198: [Python-modules-team] Bug#915198: python-molotov FTBFS: BrokenPipeError: [Errno 32] Broken pipe

[Ondrej Novy]

Hi,

I can't reproduce it and I can build this package locally without any
problem.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Brian Potkin]

On Fri 21 Dec 2018 at 20:39:55 +0100, Till Kamppeter wrote:

> Bernhard, thank you for your patches. I have applied them (slightly changed)
> to cups-browsed upstream. They actually do not do any functional changes, so
> if the BrowseFilter facility does not work as expected, this is another bug
> and this bug was probably there before.

  BrowseFilter NOT pdl pdf

works and then I do not see any queues advertised by remote CUPS servers.

But I do not see any IPP printers either. I would rather live without
filtering on the TXT record not working and have IPP printers shown, as
it was before this change.

-- 
Brian.

Bug#916986: Downgrade hard-dependency on mailutils to recommends

[John Zaitseff]

Dear Rob,

To add to this bug report: firstly, a big thanks for releasing Emacs
26 as a Debian package--I've been looking forward to this for quite
a while.

Secondly, if the dependencies could be changed, that would be
appreciated: apart from "normal" systems, I run Emacs (emacs-nox) in
a chroot build environment without any MTA, and the new dependencies
add 62MB... not counting the bother of having exim4-daemon-light and
cron installed in a chroot.

By the way, I don't know if I need to create a new bug report, but
emacs-nox 1:26.1+1-2 is 24.4MB larger than the previous version,
1:25.2+1-11.  Is there that much difference between the two
versions, or has something been included in the package by accident?

Yours truly,

John Zaitseff

-- 
John Zaitseff,--_|\The ZAP Group
Phone:  +61 2 9643 7737 /  \   Sydney, Australia
E-mail: j.zaits...@zap.org.au   \_,--._*   http://www.zap.org.au/
  v

Bug#916905: RFS: Jerry (Chess GUI) /3.1-0 -- looking for sponsor

[Dominik Klein]

Dear Adam,

thanks very much for your feedback.

I've filed an ITP under #917027.

Moreover I've
- changed the icon to a png, since the problem is likely that not all 
window manager are able to display .ico
- changed changelog to mark for unstable
- added regexp to track new releases via the watch-file
- modified the copyright file to clarify for all files who owns the 
copyright and which license
- The .bin is polyglot opening book. It's format is openly documented, 
e.g. here http://hardy.uhasselt.be/Toga/book_format.html

I also changed the changelog 
https://github.com/asdfjkl/jerry/releases/tag/v3.1.0 to automatically 
close #917027, i.e. if feedback for the ITP is positive and a sponsor 
would come forward, the current package might be suitable for inclusion...

kind regards

- Dominik

Am 20.12.2018 um 18:16 schrieb Adam Borowski:
> On Thu, Dec 20, 2018 at 08:33:16AM +, Dominik Klein wrote:
>> * Package name: jerry
>> Version : 3.1-0
>> Upstream Author : Dominik Klein / dominik.kl...@outlook.com
>> * URL : https://github.com/asdfjkl/jerry
> 
>> It builds those binary packages:
>>
>> Jerry - a chess program / GUI
> 
>> https://github.com/asdfjkl/jerry/releases/tag/v31
> 
> Hi!
> Functionally, the program works nearly fine: only nit I noticed is runtime
> icon missing.
> 
> You'd need to file an ITP bug, wait a bit for potential responses, and close
> it via the changelog,  Also, changelog for packages you request an upload
> for should be marked for unstable rather than UNRELEASED -- that's a marking
> meant to block packages in a state not yet meant to be uploaded.
> 
> The watch file should point at a wildcard that will match future releases;
> you have a static URL for the current tarball.
> 
> The copyright file needs work:
> * the vast majority of program sources include Karl Josef Klein
> * images have external authors
> * the "book"
> 
> The latter also appears to lack any sources.  How does one build/edit it?
> It's in some ".bin" format that appears to be a binary blob -- that would
> be bad except that the code refers to it as "Polyglot".  How does one deal
> with such Polyglot files?
> 
> You don't need to list binary files in debian/source/include-binaries;
> that's only for stuff that's changed during the packaging.  Anything within
> the upstream tarball is fine -- .jpg images are also binary, for example.
> 
> 
> Meow!
> 

Bug#910837: RFS: mle/1.2-1 [ITP] -- flexible terminal-based text editor (C)

[as]

On Wed, 17 Oct 2018 13:28:40 + Mo Zhou  wrote:
> ...
> Try to build against this termbox package, it's almost finished:
> https://salsa.debian.org/debian/termbox
>

Updated to build against uthash-dev, liblua5.3-dev, and libtermbox-dev.
(Thanks lumin!)

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

Adam

Bug#917035: flatpak-builder: Don't recommend subversion and bzr

[Jeremy Bicha]

Source: flatpak-builder
Version: 1.0.1-1
X-Debbugs-CC: s...@debian.org

I was surprised that installing gnome-builder automatically installs subversion.

Based on the defintion "packages that would be found together with
this one in all but unusual installations", I propose that
flatpak-builder drop its recommends on subversion and bzr | brz. I
don't think these are needed as Suggests either since someone who
needs svn or bzr can easily install them directly.

Thanks,
Jeremy Bicha

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

* Sven Joachim  [2018-12-21 20:38]:

> On 2018-12-21 20:16 +0100, Alexander Meyer wrote:
> 
>> Package: xterm
>> Version: 340-1
>> Severity: important
>> [...]
>> I've found a bug report from Arch Linux that looks similar:
>> https://bugs.archlinux.org/task/61115
> 
> Strange that you looked in the Arch bugtracker, but apparently not in
> the Debian BTS…

That came up via a web search as I had originally thought the bug had to
do with mutt.

>> But the last comment there claims the bug disappeared in 340 which is not the
>> case for me.
> 
> I could also still reproduce it, that's why I did not close #916349 in
> the xterm 340-1 upload.

I couldn't tell whether that bug was the same as mine, as none of the
error messages mentioned there came up for me, also that bug doesn't
talk about segfaulting.

If you think this is the same bug, then feel free to merge, of course.

Thanks
Alex

Bug#916765: cups-browsed: Aborts when restarted with "BrowseFilter pdl postscript"

[Till Kamppeter]

Bernhard, thank you for your patches. I have applied them (slightly 
changed) to cups-browsed upstream. They actually do not do any 
functional changes, so if the BrowseFilter facility does not work as 
expected, this is another bug and this bug was probably there before.


   Till

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Sven Joachim]

Control: merge 916349 -1

On 2018-12-21 20:16 +0100, Alexander Meyer wrote:

> Package: xterm
> Version: 340-1
> Severity: important
> [...]
> I've found a bug report from Arch Linux that looks similar:
> https://bugs.archlinux.org/task/61115

Strange that you looked in the Arch bugtracker, but apparently not in
the Debian BTS…

> But the last comment there claims the bug disappeared in 340 which is not the
> case for me.

I could also still reproduce it, that's why I did not close #916349 in
the xterm 340-1 upload.

Cheers,
   Sven

Bug#913946: llvm*-dbgsym still missing

[Adrian Bunk]

Control: reopen -1
Control: tags -1 = patch

On Fri, Dec 14, 2018 at 10:53:23PM +, Rebecca N. Palmer wrote:
> On 14/12/2018 21:21, Sylvestre Ledru wrote:
> > Maybe it will be automatically fixed as doko told me that he backported
> > the fix in binutils.
> 
> The original form of this bug (i.e. "failed to find link section" when using
> GNU strip) should be fixed in binutils 2.31.1-11.
> 
> To get back to that being our only problem, we need to revert at least the
> attempt to use LLVM strip (i.e. 
> https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/commit/d441237cacb871abfebec1353b4b64398a362b0b).
>...

The fix in 1:7.0.1-1 was not complete, there were two additional problems
(missing -g and missing BuildID) that are fixed in
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/merge_requests/28

> (There's also #914021, where llvm*-dbgsym do exist but don't actually work;
> I don't know whether that will affect 7 after these changes)

The above MR creates -dbgsym again and gives you the line numbers
in the backtrace back:

(gdb) bt full
#0  0x74d54040 in llvm::sys::Wait(llvm::sys::ProcessInfo const&, 
unsigned int, bool, std::__cxx11::basic_string, 
std::allocator >*)@plt () from /usr/lib/x86_64-linux-gnu/libLLVM-7.so.1
No symbol table info available.
#1  0x74f020f6 in ExecuteAndWait ()
at /tmp/llvm-toolchain-7-7.0.1/lib/Support/Program.cpp:41
No locals.
#2  0x009cdbc1 in Execute ()
at /tmp/llvm-toolchain-7-7.0.1/tools/clang/lib/Driver/Job.cpp:335
No locals.
#3  0x009ab3c3 in ExecuteCommand ()
at /tmp/llvm-toolchain-7-7.0.1/tools/clang/lib/Driver/Compilation.cpp:185
No locals.
#4  0x009ab58a in ExecuteJobs ()
at /tmp/llvm-toolchain-7-7.0.1/tools/clang/lib/Driver/Compilation.cpp:236
No locals.
#5  0x009bc3ae in ExecuteCompilation ()
at /tmp/llvm-toolchain-7-7.0.1/tools/clang/lib/Driver/Driver.cpp:1380
No locals.
#6  0x006a81c0 in main ()
at /tmp/llvm-toolchain-7-7.0.1/tools/clang/tools/driver/driver.cpp:462
No locals.
(gdb) 


Using -g instead of -g1 in the above MR gives a proper backtrace,
but that would cause build problems due to disk space usage.


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#916428: autopkgtest-virt-qemu: Fails to set up test environment when run with python3.7

[Thadeu Lima de Souza Cascardo]

I have been bitten by this same problem but managed to debug it to the
fact that autopkgtest-virt-qemu is not closing the sockets.

On python3.6 and python3.7.1 (likely, haven't tested this one out yet),
the socket is closed when its references are gone (this is done on
socket_finalized on Modules/socketmodule.c).

As you can see on that same code, a ResourceWarning is raised, but one
can only see that on debug builds. Both 3.6 and 3.7 raise that, but only
by using some strace I could notice that 3.7.2rc1 is not closing the
socket on a function exit. And that's only when the 'with timeout' is
used, because of calling signal.signal. I will attach my minimal case
where this happens as well.

The attached autopkgtest-virt-qemu patch also fixes the problem for me.
I don't close the socket on all failure paths. Maybe we should implement
a "With Context Manager" for that as well. Though thinking a little more
about that, the code would be pretty ugly, and we should just rely on a
working python doing the correct resource management.

Regards.
Cascardo.
import signal
import socket
import time

class Timeout(RuntimeError):
pass

def alarm_handler(*a):
raise Timeout()

def get_unix_socket():
s = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
signal.signal(signal.SIGALRM, alarm_handler)
return s

def test_tty():
sock = get_unix_socket()
signal.signal(signal.SIGALRM, alarm_handler)

test_tty()

time.sleep(1)
>From dcd5895b808ca377255f9cc980e9ba54bbed5f75 Mon Sep 17 00:00:00 2001
From: Thadeu Lima de Souza Cascardo 
Date: Fri, 21 Dec 2018 17:14:11 -0200
Subject: [PATCH] qemu: close sockets after being done with them

With Python 3.7.2-rc1, the socket won't be closed after being finalized.
That causes a problem when trying to connect to the same qemu unix socket
again. It won't be able to receive anything, and that breaks
autopkgtest-virt-qemu.

Closing the sockets before exiting the functions on the success cases will
make it work around that problem.

Signed-off-by: Thadeu Lima de Souza Cascardo 
---
 virt/autopkgtest-virt-qemu | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/virt/autopkgtest-virt-qemu b/virt/autopkgtest-virt-qemu
index 573bce7..8cdcc74 100755
--- a/virt/autopkgtest-virt-qemu
+++ b/virt/autopkgtest-virt-qemu
@@ -125,6 +125,7 @@ def wait_boot():
 # don't help to determine if the system is *really* booted; running
 # commands too early causes the system time to be all wrong
 time.sleep(3)
+term.close()
 
 
 def check_ttyS1_shell():
@@ -134,8 +135,10 @@ def check_ttyS1_shell():
 term.sendall(b'echo -n o; echo k\n')
 try:
 VirtSubproc.expect(term, b'ok', 1)
+term.close()
 return True
 except VirtSubproc.Timeout:
+term.close()
 return False
 
 
@@ -190,6 +193,7 @@ def login_tty_and_setup_shell():
 VirtSubproc.expect(term, None, 10, 'accepted ttyS1 shell command')
 term.sendall(b'exit\n')
 VirtSubproc.expect(term, b'\nlogout', 10)
+term.close()
 
 
 def setup_baseimage():
@@ -215,6 +219,8 @@ def setup_baseimage():
 
 term.sendall(b'udevadm settle --exit-if-exists=/dev/baseimage\n')
 VirtSubproc.expect(term, b'#', 10)
+term.close()
+monitor.close()
 
 
 def setup_shared(shared_dir):
@@ -275,6 +281,7 @@ while not os.path.exists(fexit):
 EOF
 ''')
 VirtSubproc.expect(term, b'# ', 5)
+term.close()
 
 
 def setup_config(shared_dir):
@@ -311,6 +318,8 @@ def setup_config(shared_dir):
 if b'\n# ' not in out:
 VirtSubproc.expect(term, b'# ', 5)
 
+term.close()
+
 
 def make_auxverb(shared_dir):
 '''Create auxverb script'''
@@ -513,6 +522,7 @@ def determine_normal_user(shared_dir):
 adtlog.debug('determine_normal_user: got user "%s"' % normal_user)
 else:
 adtlog.debug('determine_normal_user: no uid in [1000,5] available')
+term.close()
 
 
 def hook_open():
@@ -642,6 +652,7 @@ def hook_prepare_reboot():
 monitor = VirtSubproc.get_unix_socket(os.path.join(workdir, 'monitor'))
 monitor.sendall(b'device_del virtio-baseimage\n')
 VirtSubproc.expect(monitor, b'(qemu)', 10)
+monitor.close()
 
 
 def hook_wait_reboot():
-- 
2.20.1

Bug#916933: RFS: libgsm/1.0.18-1 [ITA]

[Adam Borowski]

On Fri, Dec 21, 2018 at 05:23:19AM +0100, Adam Borowski wrote:
> On Thu, Dec 20, 2018 at 01:14:01PM -0800, Felix Lechner wrote:
> > On Thu, Dec 20, 2018 at 12:10 PM Adam Borowski  wrote:
> > > audio_gsm.c:29:11: fatal error: GSM610/gsm.h: No such file or directory
> > >  # include "GSM610/gsm.h"
> > 
> > Thank you for taking a look. The errors you found are due to confusion
> > about the include path.
> 
> Full results of the rebuilds:
> 
> freerdp2_amd64.build:Status: attempted
> gmerlin-avdecoder_amd64.build:Status: attempted
> mediastreamer2_amd64.build:Status: attempted
> twinkle_amd64.build:Status: attempted

> > The previous version shipped gsm.h in two locations: It was in
> > /usr/include, and again in /usr/include/gsm---together with a bunch of
> > probably private headers that gave rise to #882176.

> > Either way, I uploaded a new version to Mentors that again ships the
> > same file in both locations. Would you please try again?

Hi;
the package has been for some reason removed from mentors, despite no one
uploading anything.  Could you tell me if there's a version you'd want in?

I'd be happy with either a hard break or a compat link -- it's up to you and
your upstream wrt what is preferred.  I believe we know enough; thanks for
your work so far.

So please give me something to re-test and upload.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in
⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned
⠈⠳⣄ to the city of his birth to die.

Bug#917034: xterm crashes on certain Unicode characters when font was selected with -fa

[Alexander Meyer]

Package: xterm
Version: 340-1
Severity: important

Dear Maintainer,

after updating from 337-1 to 338-1 in testing, xterm crashes with a segfault
when certain Unicode characters appear in the buffer. This only happens when I
have selected a font using the -fa option. It doesn't seem to matter which font
it is. (I've randomly tried a few from my fc-list.)

I've installed 340-1 from unstable, but the bug persists.

As I came across this issue while reading mails in mutt, I've tried to identify
the exact characters causing it. It turned out that these commands cause the
crash:

$ /usr/bin/printf "\U0001F384"# U+1F384 CHRISTMAS TREE
$ /usr/bin/printf "\U0001F385"# U+1F385 FATHER CHRISTMAS
$ /usr/bin/printf "\U0001F3E1"# U+1F3E1 HOUSE WITH GARDEN
$ /usr/bin/printf "\U0001F644"# U+1F644 FACE WITH ROLLING EYES

Whereas these commands work fine:

$ /usr/bin/printf "\U0001F601"# U+1F601 GRINNING FACE WITH SMILING EYES
$ /usr/bin/printf "\U0001F604"# U+1F604 SMILING FACE WITH OPEN MOUTH 
AND SMILING EYES

To reproduce this bug, run one of the aforementioned commands after starting
xterm with e.g.

$ xterm -fa 'Noto Mono'

When leaving out -fa, xterm doesn't crash.

Please find below a backtrace.

As the bug was introduced after updating xterm (libfontconfig1 remained
untouched during that update), I'm filing this under xterm for the time being.

xterm 337-1 doesn't crash. Interestingly, though, in 337-1 all six
above-mentioned characters are not displayed at all when running with e.g.
-fa 'Noto Mono'. I just see a two-glyph-wide blank space. Whereas in 338-1 and
340-1, the two non-crashing characters U+1F601 and U+1F604 are actually
displayed.

I've found a bug report from Arch Linux that looks similar:
https://bugs.archlinux.org/task/61115
But the last comment there claims the bug disappeared in 340 which is not the
case for me.

I don't know a great deal about X font handling, so in case you need more info,
please try to explain in detail what you need to know. Thanks in advance. Also,
I don't care that much if those special glyphs are actually displayed correctly
in my xterm or not, it's just that xterm shouldn't crash.


Backtrace:

Reading symbols from /usr/bin/xterm...Reading symbols from 
/usr/lib/debug/.build-id/e1/82f855c9d3aa8701e44c1fc1d41e81eb0b0bd6.debug...done.
done.
(gdb) run -fa 'Noto Mono'
Starting program: /usr/bin/xterm -fa 'Noto Mono'
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x77d662d1 in FcConfigEvaluate (p=0x556fdfd0, 
p_pat=0x559ea680, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
(gdb) bt full
#0  0x77d662d1 in FcConfigEvaluate (p=0x556fdfd0, 
p_pat=0x559ea680, kind=kind@entry=FcMatchFont, e=0x0) at fccfg.c:977
v = {type = FcTypeVoid, u = {s = 0x556fd670 "\300\326oUUU", 
i = 1433392752, b = 1433392752, d = 4.6355706243752135e-310, 
m = 0x556fd670, c = 0x556fd670, f = 0x556fd670, 
l = 0x556fd670, r = 0x556fd670}}
vl = {type = 1433007920, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
vr = {type = 1436460672, u = {s = 0x0, i = 0, b = 0, d = 0, m = 0x0, 
c = 0x0, f = 0x0, l = 0x0, r = 0x0}}
vle = 
vre = 
m = 
str = 
op = 
buf1 = {u = {d = 0, i = 0, l = 0, 
c = "\000\000\000\000\000\000\000\000 
\326oUUU\000\000H\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\320\325oUUU\000\000`\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000\200\325oUUU\000\000x\367iUUU\000\000\000\000\000\000\000\000\000\000\200\246\236UUU",
 '\000' , 
"\256m\326\367\377\177\000\000\000\000\000\000\000\000\000\000"...}}
buf2 = {u = {d = 0, i = 0, l = 0, 
c = 
"\000\000\000\000\000\000\000\000\340\324oUUU\000\000\250\367iUUU\000\000\000\000\000\000\000\000\000\000\025",
 '\000' , "\a\000\000\000\000\000\000\000 
\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\020\300aUUU\000\000\017\000\000\000\000\000\000\000@\000\000\000\000\000\000\000\260\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\060",
 '\000' , "[\000\000\000w", '\000' , 
"n\000\000\000|\000\000\000\t\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\025",
 '\000' , "\260\377\377\377\377\377\377\377"...}}
#1  0x77d66418 in FcConfigEvaluate (p=p@entry=0x556fdfd0, 
p_pat=p_pat@entry=0x559ea680, kind=kind@entry=FcMatchFont, 
e=e@entry=0x55683b38) at fccfg.c:1003
m = {xx = 1.4821969375237396e-323, xy = 6.9533490418283141e-310, 
  yx = 

Bug#916924: sbuild: doesn't run autodep8 autopkgtests

[Johannes Schauer]

Hi Sean,

Quoting Sean Whitton (2018-12-21 13:09:59)
> On Fri 21 Dec 2018 at 12:27pm +0100, Johannes Schauer wrote:
> > okay, but now I'm confused how autodep8 gets triggered at all. Isn't
> > autodep8 wrapping autopkgtest and not the other way round? Because sbuild
> > only executes autopkgtest itself which will fail if debian/tests/control is
> > missing.
> >
> > So how does the machinery involing autodep8 work? Can you explain in a bit 
> > more
> > detail?
> 
> I have not looked at the code, but I believe that autopkgtest invokes
> autodep8 when there is no debian/tests/control.  autodep8 then makes its
> own decision about whether to generate a debian/tests/control to pass
> back to autopkgtest.
> 
> The reason I believe this is that with older sbuild, when there is no
> d/tests/control, autopkgtest successfully runs the test suite.  So it must be
> that it is invoking autodep8.

could you check with the autopkgtest maintainers/developers about this?

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#917033: RFP: node-gulp-rtlcss -- Gulp plugin that uses RTL CSS to convert LTR CSS to RTL

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-gulp-rtlcss
  Version : 1.3.0
  Upstream Author : jjlharrison
* URL : 
https://notabug.org/themusicgod1/makenotabuggreatagain/gulp-rtlcss
* License : MIT
  Programming Lang: javascript
  Description : convert LTR CSS to RTL (Gulp plugin)

RTLCSS is a framework for transforming cascading style sheets (CSS) 
from Left To Right (LTR) to Right to Left (RTL) https://rtlcss.com.

Gulp-rtlcss is a gulp plugin that uses RTLCSS.

node-gulp-rtlcss is a dependency of node-semantic-ui ( #915062 )

Bug#917032: Please improve error message for not having PyQt5 installed

[Josh Triplett]

Package: electrum
Version: 3.2.3-1
Severity: wishlist

> Error: Could not import PyQt5 on Linux systems, you may try 'sudo apt-get 
> install python3-pyqt5'

First, please s/apt-get/apt/.

Second, "on Linux systems" seems like an odd and unnecessary addition here.

I would suggest:

Error: Could not import PyQt5, try 'sudo apt install python3-pyqt5'

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

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

Versions of packages electrum depends on:
ii  python3   3.7.1-3
ii  python3-electrum  3.2.3-1

Versions of packages electrum recommends:
ii  python3-pyqt5  5.11.3+dfsg-1+b2

Versions of packages electrum suggests:
pn  python3-btchip  
pn  python3-trezor  
pn  python3-zbar

-- no debconf information

Bug#761880: [Pkg-sysvinit-devel] Bug#761880: sysv-rc: support init scripts in /lib/init.d (or similar)

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2018-12-20 09:15] Ansgar Burchardt 
> > [2014-09-16 18:00] Ansgar Burchardt 
> >> The symlinks in /etc/rc?.d/* and /etc/default/* are configuration files,
> >> but init script themselves are not (and if admins are supposed to modify
> >> them, I would call them buggy).
> >
> > Your proposal contradicts Debian Policy (9.3.2):
>
> No, all scripts in /etc/init.d would still be treated as configuration
> files.  Just packages could choose to *not* do that (as is the sane
> way) by shipping init scripts in a different location.

Oh, complications. Here I support previous comment, complications,
shadowing system for little gain.

> Policy also seems to lag a decade behind reality:
> [...]
> 
> It's possible to disable services without editing /etc/init.d/*.
> It's possible to do that without editing /etc/init.d/*. (/etc/default/*)

There are other modifications admin may like to apply. We can't
anticipate them all. eatmydata? nice? unshare? nsenter?

> Allowing packages to not have init scripts as configuration files would
> help dealing with outdated init scripts (from removed, but not purged
> packages) which cause problems (for example when they lack LSB headers,
> have outdated dependencies which cause cirular dependencies, ...).

Yes, there is trade-off. But as I see it, your proposal favors solving
issues of past (missing LSB headers, outdated scripts), which will be
solved eventually, to flexibility of all current and future
installation.

In short: I value possibility to edit /etc/init.d/ scripts and do not
find logic complexity of your proposal warranted.

Bug#661314: Fixed upstream

[Dmitry Bogatov]

control: tags -1 +fixed-upstream

[2018-12-20 00:08] Jesse Smith 
>
> part   text/plain 576
> I can see how the existing text is unclear. Having done a few tests on
> this myself it looks like init.d services that are not executable are
> not added (or are even removed) when update-rc.d is run with the
> "enable" parameter. When update-rc.d is run with "disable" a link is set
> up for disabling scripts as expected, but the script might not run properly.
> 
> I'm going to make a slight change to the suggested wording and commit
> it. So let's consider this fixed upstream. Can probably close unless
> there are further suggestions on how to make the warning more clear.

Thank you for your work. Bug will be closed when upstream (your)
release is uploaded to Debian.

Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Dmitry Bogatov]

[2018-12-20 09:34] KatolaZ 
> On Wed, Dec 19, 2018 at 11:40:48PM +, Dmitry Bogatov wrote:
> > 
> > control: tags -1 +moreinfo
> > 
> > [2015-12-01 23:07] Petter Reinholdtsen 
> > > In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
> > > conffiles.  They should be moved to /lib/init/ instead.
> > 
> > Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
> > into /lib/init and adding symbolic links?
> > 
> > Any objections to this approach?
> 
> Why shall we move it at all?

Because sysadmin usually assume, that edits of anything under /etc
will be preserved between upgrades. And /etc/init.d/{rc,rcS} violate
this expectation.

Bug#838480: summary of disagreement

[Dmitry Bogatov]

I drafted following text, expressing my vision of problem. You may wish
to extend it with your vision.

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Technical Comitete,

  currently, inclusion of new init system into Debian requires inclusion into
pre-dependency of bin:init package, which is unsatisfactory.

As can be followed in #838480, current practice puts maintainer of any
new init system to be included into Debian at disadvantage, essentially
granting maintainer of bin:init (which happens to be `systemd' team now)
veto right. According to Constitution 3.1, individual developer poses
power of descision making only with regard their /own/ work.

Hereby, I ask TCCE to provide requirements init system must satisfy that
/warrants/ inclusion into pre-dependency of essential bin:init.
Alternatively, I ask to consider introducion of virtual package
'init-system'.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlwcvjsACgkQSBLY3qgm
EeYKLg//UxjrTQiM6kIpiHmJ8hdsO24ZcwzBjqsECZZDFns6n8lgWCqMbFzMZMaX
U93jengYK99teJ2KsvVXrLvJO/AXpvzZ78vL6AcPsQ7m4F+jPNvMvf2S5sNEyIj6
WOWhQxzVfIHxmqKrRzgkFN+fLh14pDLJl8rGAAvvHoCvl5AuB1Bt95J0uTTgNYqe
uK0Ro4Csc7mhPSLXfmeQnr8FTrARW4/qFTLjzfhTfkrjaAn+/ubJrxyAdvN4ebea
MZ1EK4MjSUui+qPFHdaCDx2r4qiWnZ4Fy6Oi+XKPDLlffzpttU6PvhT6RxpGFI3q
qEIOEkXwPU5VtBMO9j6pwfIrg/Ad0jTYiNdPYk9ytGWsb6uKTrIWgZIr4J+LZS8w
1iqm6FQer39PZ+cvvdCLtGb7yk+PPwd5YQ6Fp/hPJL16aiZHpb7ymZt9Dg8iY+Uh
E0Xs8Tph74yIoXJY4bMNHao+54Fk94vWaRnNlbA+tszpQRPzW5CatOoktB4hgLnj
V/w1WFO3/IkHH9l2YtVgGk8QZDS9OxZFf+AHEQCc13FqSHWWbQwFgJDcv40jNzz1
ac2WUZn5b30uKh+AsP2P4hdSWktAtBHtL5aYHH8ACWAjAG4TdAlVXLqArJhIyDUT
evw3yrCZMB01zwDA/5AdopxAbvLAKURKgypPCwk0X3b9/KZp8PY=
=KYX7
-END PGP SIGNATURE-

Bug#780364: [Pkg-sysvinit-devel] Bug#780364: The problem disappeared, when I removed /etc/adjtime file and rebooted

[Dmitry Bogatov]

control: tags -1 +moreinfo

[ Added initramfs-tools maintainer to thread ]

[2015-05-05 14:19] Michael Biebl 
> [...]
>
> Most likely, /etc/adjtime was configured to use local time and you ran
> into [1]. In systemd, we avoid that error by skipping the file system
> check if already done in the initramfs [2].
> I think sysvinit should do the same and test for the flag files created
> by initramfs-tools [3].
> [...]

Thank you. Seems reasonable.

Dear co-maintainers, I seek you advice how best approach this situation.
According to initramfs-tools(7), if /run/initramfs/fsck-{root,usr}
exits, corresponding partition was already checked and should be
skipped.

 * despite name, `checkroot.sh' also does another function: it enables
   swap. So it sounds reasonable to factor (there is quite a logic) swap
   manipulation code into another init script (swapon.sh, for example).

   But since currently `status' of `checkroot.sh' return 0 if either
   swap on or / is rw, such refactoring would slightly change semantics
   of `status' command. Would it cause breakages?

 * checking of /usr in `checkfs.sh' is performed by `fsck -A'. Any
   ideas, how should we tell it to skip /usr?

   One possible approach is that if sixth field in `/etc/fstab' is `0',
   `fsck -A' will ignore corresponding file system, but who have
   responsiblity to set it?

Bug#917031: nmh: co-installability with mmh

[Dmitry Bogatov]

Package: nmh
Severity: wishlist

Dear Maintainer,

please make `nmh' co-installable with `mmh'. I, as maintainer of `mmh',
took first step and made `mmh' alternative of /usr/bin/mh/mh and bunch
of slave links.


pgpGj7WI4lTcu.pgp
Description: PGP signature

Bug#916901: Bug #916901 in lintian marked as pending

[Chris Lamb]

Hi Andreas,

> > https://salsa.debian.org/lintian/lintian/commit/2b17404a6694ef966bab17e42b552cfa631eb523
[…]
> Isn't that too wide by allowing /usr/lib/$PACKAGE/stuff which should
> rather be in /usr/share ?

Good shout. Should be fixed better (I think!) in:

  
https://salsa.debian.org/lintian/lintian/commit/c91cb36280608c5ead1594945a788cb0f9bb99cd


Regards,

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

Bug#916043: qemu-user-static: qemu-arm-static running armel dash breaks globbing

[Michael Tokarev]

09.12.2018 18:19, Ian Campbell wrote:

Package: qemu-user-static
Version: 1:2.12+dfsg-3+b1
Severity: normal

Dear Maintainer,

While working on a new qcontrol package, using a cross-schroot via
qemu-arm-static on an amd64 host, I noticed that globs did not appear to be


Oh. It happens on amd64 host! I thought it is happening on ARM64 host! --
that's why I asked you to verify... Oh well.

I'll try it at home ;)

Thanks!

/mjt

Bug#841073: python-ruffus: Needs 18 GB of RAM to build

[Andreas Tille]

Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 https://github.com/cgat-developers/ruffus/issues/104

On Fri, Dec 21, 2018 at 06:44:24PM +0100, Santiago Vila wrote:
> In this case (python-ruffus), it used to be 18 GB for version 2.7,
> which made it to be the most memory demanding package in buster so far.
> 
> Now in version 2.8.1-3 and 2.8.1-4 I get 38 GB which is a lot worse.

Thanks a lot for your new investigation.
 
> A simple loop like this during the build will work:
> 
> while true; do grep Committed_AS /proc/meminfo; sleep 1; done

I can confirm this observation and have forwarded the issue upstream.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#473996: promptconfaction should offer vimdiff too

[Chris Lamb]

Hi Guillem,

>  - There is a desire to get 3-way merge support. This is currently
>just unreliable, as we do not keep all the information required.
>I'd rather not spend time on this until the conffiledb work is
>merged, which I just need to sit down and do. :)

Is there an ETA on this, just out of interest?

This feature seems like a fun problem to hack on, after all but
wouldn't want to get in your way or expend energy generating yet
another patch that won't ever be merged. :)


Best wishes,

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