Bug#920885: ntp: segmentation fault in libc-2.24.so[7f9cf2783000+195000]

[Vincas Dargis]

Package: ntp
Version: 1:4.2.8p10+dfsg-3+deb9u2
Severity: normal

Dear Maintainer,

logcheck sent me email with this kernel log message:

```
Jan 30 04:10:18 hostname kernel: [1188466.407270] ntp_80.241.208.[30453]: 
segfault at 4000 ip 7f9cf2803676 sp 7ffd82efab38 error 4 in 
libc-2.24.so[7f9cf2783000+195000]
```

addr2line says:
```
$ addr2line -e /lib/x86_64-linux-gnu/libc-2.24.so 0x2F9B8
/build/glibc-yWQXbR/glibc-2.24/intl/loadmsgcat.c:691
```

Machine is absolutely not under any heavy load, only ~300MB/4GB ram is used.
This is first occurrance for this machine, and it has been running Jessie some
time ago.

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

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

Versions of packages ntp depends on:
ii  adduser3.115
ii  dpkg   1.18.25
ii  libc6  2.24-11+deb9u3
ii  libcap21:2.25-1
ii  libedit2   3.1-20160903-3
ii  libopts25  1:5.18.12-3
ii  libssl1.1  1.1.0j-1~deb9u1
ii  lsb-base   9.20161125
ii  netbase5.4

Versions of packages ntp recommends:
ii  perl  5.24.1-3+deb9u5

Versions of packages ntp suggests:
pn  ntp-doc  

-- no debconf information

Bug#919818: ruby-net-ssh breaks test-kitchen autopkgtest

[Adrian Bunk]

Control: severity -1 serious

On Sat, Jan 19, 2019 at 10:17:48PM +0100, Paul Gevers wrote:
> Source: ruby-net-ssh, test-kitchen
> Control: found -1 ruby-net-ssh/1:5.1.0-1
> Control: found -1 test-kitchen/1.23.2-1
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainers,
> 
> With a recent upload of ruby-net-ssh the autopkgtest of test-kitchen
> fails in testing when that autopkgtest is run with the binary packages
> of ruby-net-ssh from unstable. It passes when run with only packages
> from testing. In tabular form:
>passfail
> ruby-net-ssh   from testing1:5.1.0-1
> test-kitchen   from testing1.23.2-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report.
> 
> Currently this regression is blocking the migration of ruby-net-ssh to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package? If needed, please change the
> bug's severity.
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=ruby-net-ssh
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/t/test-kitchen/1734873/log.gz
> 
> Finished in 6.958238s, 317.6091 runs/s, 491.3600 assertions/s.
> 
>   1) Failure:
> Kitchen::SSH::#wait#test_0001_logs to info for each retry
> [/tmp/autopkgtest-lxc.z49qtfaj/downtmp/build.kGs/src/spec/kitchen/ssh_spec.rb:546]:
> Expected: 2
>   Actual: 0
> 
> 2210 runs, 3419 assertions, 1 failures, 0 errors, 0 skips

This is also a FTBFS:
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/test-kitchen.html

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#920882: libpmix2 and Open MPI

[Ron Lovell]

The libpmix2 update causes my MPI programs compiled with
gcc/gfortran/clang  to fail at runtime with the same messages.
-- 
James Ronald Lovell 

Bug#591781: texlive-base: texdoc barfs on gzipped files under gnome

[Hilmar Preuße]

On 30.01.19 00:23, Julian Gilbey wrote:

Hi Julian,

> I'm not sure if it's present any more, because I can't find a single
> .pdf.gz file in /usr/share/doc/texlive* - all of the pdf files are
> unzipped, so there is no need for texdoc to unzip them.
> 
> I tried zipping it and it still works, though I'm using xdg-open
> rather than gnome-open (as I'm running under XFCE now rather than
> Gnome).
> 
> So I guess closing this bug report is probably OK?
> 
I did some tests for #601237. In [1] I mentioned the document
ifsym.ps.gz I used for testing, which is still zipped.

Hilmar

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601237#25
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#714572: emacs-goodies-el: csv-mode customize-mode

[Kevin Ryde]

Nicholas D Steeves  writes:
>
> If you're able to, would you please submit a patch?

I don't have a whole setup to actually try, but :group 'CSV from my
original bug might be all it takes.  (There seems to be the same on
csv-field-index-mode already.)

Its absence doesn't hurt normal use of course, just gets the customize
right.

Bug#920884: change the debian VCS URL's in libsignon-qt5-1 debian/control file

[shirish शिरीष]

Package: libsignon-qt5-1
Version: 8.59-2
Severity: normal

Dear Maintainer,
Thank you for maintaining libsignond. I was looking at the VCSwatch at
https://qa.debian.org/cgi-bin/vcswatch?package=signond when I saw this
-

Error: The Vcs URL
git://anonscm.debian.org/pkg-kde/kde-extras/signond.git is
deprecated/defunct,
https://anonscm.debian.org/git/pkg-kde/kde-extras/signond.git was
tried instead. Please update the Vcs field in debian/control.

Please fix it with the next upload of signond i.e. 8.60 #911613.

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

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

Versions of packages libsignon-qt5-1 depends on:
ii  libc6 2.28-5
ii  libqt5core5a  5.11.3+dfsg-2
ii  libqt5dbus5   5.11.3+dfsg-2
ii  libstdc++68.2.0-15

libsignon-qt5-1 recommends no packages.

libsignon-qt5-1 suggests no packages.

-- no debconf information


-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#920883: RFA: hollywood -- fill your console with Hollywood melodrama technobabble

[Yangfl]

Package: wnpp
Severity: normal

I no longer use it. Feel free to adopt this package.

The package description is:
 This utility will split your console into a multiple panes of genuine
 technobabble, perfectly suitable for any Hollywood geek melodrama.
 It is particularly suitable on any number of computer consoles in the
 background of any excellent schlock technothriller.

Bug#920882: libpmix2: unable to open mca_pmix_ext2x: libpmix.so.2: No such file or directory

[Drew Parsons]

Package: libpmix2
Version: 3.1.2-1
Severity: grave
Justification: renders package unusable

The new version of libpmix2 is confusing client packages,
breaking CI tests in many packages, e.g. for petsc:

  run SNES testex19
  Possible error running C/C++ src/snes/examples/tutorials/ex19 with 1 MPI 
process
  See http://www.mcs.anl.gov/petsc/documentation/faq.html
  [ci-1548795660:12338] mca_base_component_repository_open: unable to open 
mca_pmix_ext2x: libpmix.so.2: cannot open shared object file: No such file or 
directory (ignored)
  [ci-1548795660:12338] [[65452,0],0] ORTE_ERROR_LOG: Not found in file 
ess_hnp_module.c at line 325

The error references mca_pmix_ext2x which I presume means
mca_pmix_ext2x.so from libopenmpi3. Does it simply mean that openmpi
needs to be rebuilt against the new pmix?  Please reassign this bug to
libopenmpi3 if needed.

Drew

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

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

Versions of packages libpmix2 depends on:
ii  libc62.28-5
ii  libevent-2.1-6   2.1.8-stable-4
ii  libevent-pthreads-2.1-6  2.1.8-stable-4
ii  libhwloc-plugins 2.0.0-1
ii  zlib1g   1:1.2.11.dfsg-1

libpmix2 recommends no packages.

libpmix2 suggests no packages.

-- no debconf information

Bug#920881: webext-debianbuttons should list firefox-esr as first dependency alternative

[Adrian Bunk]

Package: webext-debianbuttons
Version: 2.2-1
Severity: serious

* Migration status: Blocked. Can't migrate due to a non-migratable dependency. 
Check status below.
* Blocked by: firefox

The problem is:
  Depends: firefox (>= 50) | firefox-esr (>= 50)

The first alternative is special, since it is preferred
by package managers. It should therefore be the package
that is in releases.

While the practical relevance is likely close to zero
(who would install this package without already having
firefox installed?) it is easy to fix by changing the
order of the dependency alternatives.

Bug#920880: recover from unknown user in statoverride

[Harald Dunkel]

Package: dpkg
Version: 1.19.4

I got this error:

# apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libdbus-glib-1-2 libdbus-glib-1-dev libdbus-glib-1-dev-bin python-dbus
4 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/312 kB of archives.
After this operation, 210 kB disk space will be freed.
Do you want to continue? [Y/n] y
dpkg: unrecoverable fatal error, aborting:
 unknown user 'gerbera' in statoverride file
E: Sub-process /usr/bin/dpkg returned an error code (2)

# dpkg --get-selections | grep deinstall
#


dpkg should either resolve this issue, or provide some guidelines
to the user.


Regards
Harri

Bug#806852: change systemd scripts to drop to shell of user with sudo privileges

[Anchal Nigam]

I realize this is a very old thread but, from what I can tell, its still
the normal behavior with Debian and I had an idea.

As discussed the `--force` option is not very secure.

Instead, why not change the `systemd` scripts to open a shell as a regular
user who has login and `sudo` as `root` privileges? Like a system admin
maybe. That way they can login with their ID and then use `sudo` to become
root -- which would require their password again.

This seems like a far better and more secure option then currently
prescribed which is either to use `--force` or to not lock the `root`
account.

Thank you!
*_Nacho*

Bug#920879: RM: python-nanomsg -- ROM; Unmaintained upstream and in Debian, FTBFS

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

Needs porting to a newer nanomsg.  No one in Debian is working on this package
(I last touched at a year and a half ago to fix another RC bug) and there's
almost no activity upstream.

If it ever gets updated and someone interested in the package appears, then it
can be re-introduced.

Scott K

Bug#920878: lintian: please check for missing Build-Depends: qt5-qmake:native when using lrelease

[Helmut Grohne]

Package: lintian
Version: 2.5.124
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap

A number of qt-related projects manage their translations using
lrelease. The current packaging of qmake implies that lrelease only
works when you have a native qmake installed. When you only have a
foreign qmake (e.g. due to Build-Depends: qt5-qmake), lrelease prints an
error message and exists successfully. Arguably, this is a policy 4.6
violation. Sometimes it is noted due to missing files at dh_install
time. Other times, one gets a broken build.

In a discussion with Lisandro and Dmitry, we packages that use lrelease
are a minority. Therefore they should simply add qt5-qmake:native to
Build-Depends. This is a simple task once you know that it needs doing.

The question of when a package uses lrelease is harder. Assuming that
all packages build from source, we could search for
/usr/share/*/translations/*.qm in the resulting binary packages. So we
could conceive a lintian tag that fires on the presence of such a *.qm
file and the absence of qt5-qmake from any of
Build-Depends{,-Arch,-Indep}. Let me propose a tag description:

The package installs qt translations and likely runs lrelease during
build to generate them. Running lrelease requires a build dependency
on "qt5-qmake:native", which is presently missing. If it doesn't run
lrelease, the translations are not built from source and running
lrelease manually is recommended.

Now such a tag requires lintian to look at the source and binary
packages simultaneously. Can lintian do that?

Helmut

Bug#920877: unicon FTCBFS: build system fails to forward detected compiler

[Helmut Grohne]

Source: unicon
Version: 3.0.4+dfsg1-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

unicon fails to cross build from source, because the upstream build
system fails to forward the detected compiler to the generated
Makefiles. For the C++ parts, ./configure doesn't even detect the
compiler yet. The attached patch fixes this aspect. Given that unicon
does not build from source, I couldn't test it though. Likely, unicon
won't cross build after applying it. Please close this bug anyhow after
resolving the compiler forwarding issue.

Helmut
--- unicon-3.0.4+dfsg1.orig/unicon/client/Makefile.in
+++ unicon-3.0.4+dfsg1/unicon/client/Makefile.in
@@ -1,3 +1,5 @@
+CC=@CC@
+CXX=@CXX@
 prefix=@prefix@
 CFLAGS = @CFLAGS@
 CFLAGS += -I.
@@ -15,23 +17,23 @@
 libimmclient.a: $(DLIB_OBJS)
 	ar rc $(PROG_LIB) $(DLIB_OBJS)
 TLC_LibImmClient.o: TLC_LibImmClient.cpp
-	gcc $(CFLAGS) -c TLC_LibImmClient.cpp -o TLC_LibImmClient.o
+	$(CC) $(CFLAGS) -c TLC_LibImmClient.cpp -o TLC_LibImmClient.o
 
 slib: $(SLIB_OBJS)
 	ar rc $(PROG_LIB) $(SLIB_OBJS)
 TLC_LIB_OBJS TLC_TcpipImmClient.o: TLC_TcpipImmClient.cpp 
-	gcc $(CFLAGS) -c TLC_TcpipImmClient.cpp -o TLC_TcpipImmClient.o
+	$(CC) $(CFLAGS) -c TLC_TcpipImmClient.cpp -o TLC_TcpipImmClient.o
 TLC_ImmServer.o: TLC_ImmServer.cpp TLC_ImmServer.hpp
-	gcc $(CFLAGS) -c TLC_ImmServer.cpp -o TLC_ImmServer.o
+	$(CC) $(CFLAGS) -c TLC_ImmServer.cpp -o TLC_ImmServer.o
 TLC_Utils.o: TLC_Utils.cpp
-	gcc $(CFLAGS) -c TLC_Utils.cpp -o TLC_Utils.o
+	$(CC) $(CFLAGS) -c TLC_Utils.cpp -o TLC_Utils.o
 TLC_MemFile.o: TLC_MemFile.cpp TLC_MemFile.hpp
-	gcc $(CFLAGS) -c TLC_MemFile.cpp -o TLC_MemFile.o
+	$(CC) $(CFLAGS) -c TLC_MemFile.cpp -o TLC_MemFile.o
 TLC_SocketClient.o: TLC_SocketClient.cpp TLC_SocketClient.hpp
-	gcc $(CFLAGS) -c TLC_SocketClient.cpp -o TLC_SocketClient.o
+	$(CC) $(CFLAGS) -c TLC_SocketClient.cpp -o TLC_SocketClient.o
 
 test: all $(SERVER_LIB)
-	g++ $(CFLAGS) -D__DLL_SUPPORT__ -ldl -lpth test.cpp $(PROG_LIB) $(SERVER_LIB) -o test
+	$(CXX) $(CFLAGS) -D__DLL_SUPPORT__ -ldl -lpth test.cpp $(PROG_LIB) $(SERVER_LIB) -o test
 
 install: all
 #	mkdir -p $(prefix)/lib
--- unicon-3.0.4+dfsg1.orig/unicon/server/Makefile.in
+++ unicon-3.0.4+dfsg1/unicon/server/Makefile.in
@@ -15,7 +15,7 @@
 
 # CFLAGS = -g -D__IMM_DEBUG__ -Wall -I. -I/usr/include -I../include 
 CFLAGS = -fPIC -g -Wall -I. -I../include
-CC=g++
+CC=@CXX@
 
 all: $(DLIB_PROG)
 
--- unicon-3.0.4+dfsg1.orig/configure.in
+++ unicon-3.0.4+dfsg1/configure.in
@@ -8,6 +8,7 @@
 dnl Checks for programs.
 AC_PROG_AWK
 AC_PROG_CC
+AC_PROG_CXX
 AC_PROG_INSTALL
 AC_PROG_MAKE_SET
 
--- unicon-3.0.4+dfsg1.orig/unicon/ImmModules/cce/Makefile.in
+++ unicon-3.0.4+dfsg1/unicon/ImmModules/cce/Makefile.in
@@ -1,4 +1,5 @@
 # $Id$
+CC=@CC@
 prefix=@prefix@
 CFLAGS = @CFLAGS@
 CFLAGS += -I.
@@ -11,30 +12,30 @@
 all: cce_hzinput.so cce_pinyin.so gb18030_intcode.so 
 
 CCE_hzinput.o : CCE_hzinput.c
-	gcc $(CFLAGS) -c CCE_hzinput.c -o CCE_hzinput.o
+	$(CC) $(CFLAGS) -c CCE_hzinput.c -o CCE_hzinput.o
 xl_hzinput.o : xl_hzinput.c
-	gcc $(CFLAGS) -c xl_hzinput.c -o xl_hzinput.o
+	$(CC) $(CFLAGS) -c xl_hzinput.c -o xl_hzinput.o
 cce_hzinput.so: CCE_hzinput.o xl_hzinput.o
-	gcc CCE_hzinput.o xl_hzinput.o -fPIC -shared -o cce_hzinput.so $(LDFLAGS)
+	$(CC) CCE_hzinput.o xl_hzinput.o -fPIC -shared -o cce_hzinput.so $(LDFLAGS)
 
 xl_pinyin.o : xl_pinyin.c xl_pinyin.h
-	gcc $(CFLAGS) -c xl_pinyin.c -o xl_pinyin.o
+	$(CC) $(CFLAGS) -c xl_pinyin.c -o xl_pinyin.o
 CCE_pinyin.o : CCE_pinyin.c
-	gcc $(CFLAGS) -c CCE_pinyin.c -o CCE_pinyin.o
+	$(CC) $(CFLAGS) -c CCE_pinyin.c -o CCE_pinyin.o
 cce_pinyin.so : xl_pinyin.o CCE_pinyin.o
-	gcc CCE_pinyin.o xl_pinyin.o -fPIC -shared -o cce_pinyin.so $(LDFLAGS)
+	$(CC) CCE_pinyin.o xl_pinyin.o -fPIC -shared -o cce_pinyin.so $(LDFLAGS)
 
 intcode.o : xl_intcode.c
-	gcc $(CFLAGS) -c xl_intcode.c -o intcode.o
+	$(CC) $(CFLAGS) -c xl_intcode.c -o intcode.o
 gb18030_intcode.so : intcode.o
-	gcc intcode.o  -shared -o gb18030_intcode.so $(LDFLAGS)
+	$(CC) intcode.o  -shared -o gb18030_intcode.so $(LDFLAGS)
 
 test: hzinput_test intcode_test
 
 hzinput_test:  xl_hzinput.c CCE_hzinput.c hzinput_test.c
-	gcc $(CFLAGS) xl_hzinput.c CCE_hzinput.c hzinput_test.c -o hzinput_test
+	$(CC) $(CFLAGS) xl_hzinput.c CCE_hzinput.c hzinput_test.c -o hzinput_test
 intcode_test:  xl_intcode.c intcode_test.c
-	gcc $(CFLAGS) xl_intcode.c intcode_test.c -o intcode_test
+	$(CC) $(CFLAGS) xl_intcode.c intcode_test.c -o intcode_test
 
 install: all
 	mkdir -p $(prefix)/lib/unicon/modules/cce
--- unicon-3.0.4+dfsg1.orig/unicon/ImmModules/turbo/Makefile.in
+++ unicon-3.0.4+dfsg1/unicon/ImmModules/turbo/Makefile.in
@@ -1,3 +1,4 @@
+CC=@CC@
 prefix=@prefix@
 CFLAGS=@CFLAGS@
 # CFLAGS += -V2.7.2.3 -I.
@@ -11,17 +12,17 @@
 dlib: $(PROG)
 
 xl_mfile.o : xl_mfile.c xl_mfile.h
-	gcc $(CFLAGS) -c xl_mfile.c -o xl_mfile.o
+	$(CC) $(CFLAGS) -c xl_mfile.c -o xl_mfile.o
 TL_hzinput.o : TL_hzinput.c
-	gcc $(CFLAGS) -DUNICON_LIB=\"$(prefix)/lib/unicon\" -c 

Bug#920876: xfce4-notes: Not functioning

[Dmitry Smirnov]

Package: xfce4-notes
Version: 1.8.1-2
Severity: important

In Cinnamon xfce4-notes does not work any more: it starts without showing its 
window or tray icon and uses ~55% CPU continuously. The following is printed 
to console:


/usr/share/themes/Breeze/gtk-2.0/widgets/styles:1: error: invalid string 
constant "default", expected valid string constant


Also it is too easy to run it more than once and have multiple `xfce4-notes` 
consuming even more CPU in the background...


--- System information. ---
Architecture: 
Kernel:   Linux 4.19.0-1-amd64

Debian Release: buster/sid
  500 unstable-debug  debug.mirrors.debian.org 
  500 testing-debug   debug.mirrors.debian.org 
  500 testing deb.debian.org 
  222 unstabledeb.debian.org 
1 experimentaldeb.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-=
libc6  (>= 2.4) | 
libcairo2(>= 1.2.4) | 
libgdk-pixbuf2.0-0  (>= 2.22.0) | 
libglib2.0-0(>= 2.24.0) | 
libgtk2.0-0(>= 2.24.32) | 
libpango-1.0-0  (>= 1.14.0) | 
libunique-1.0-0  (>= 1.0.0) | 
libx11-6| 
libxfce4ui-1-0   (>= 4.8.0) | 
libxfce4util7(>= 4.9.0) | 
libxfconf-0-2(>= 4.6.0) | 


-- 
Cheers,
 Dmitry Smirnov

---

The curse of man, and the cause of nearly all his woe, is his stupendous
capacity for believing the incredible.
-- H. L. Mencken


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

Bug#920875: zita-bls1 FTCBFS: uses build architecture build tools

[Helmut Grohne]

Source: zita-bls1
Version: 0.1.0-3.1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

zita-bls1 fails to cross build from source, because its upstream
Makefile hard codes build architecture build tools. After making them
substitutable, it cross builds successfully. Please consider applying
the attached patch.

Helmut
--- zita-bls1-0.1.0.orig/source/Makefile
+++ zita-bls1-0.1.0/source/Makefile
@@ -19,6 +19,7 @@
 # --
 
 
+PKG_CONFIG ?= pkg-config
 PREFIX = /usr
 SUFFIX := $(shell uname -m | sed -e 's/^unknown/$//' -e 's/^i.86/$//' -e 's/^x86_64/$/64/')
 LIBDIR = lib$(SUFFIX)
@@ -36,11 +37,11 @@
 
 ZITA-BLS1_O = zita-bls1.o styles.o jclient.o mainwin.o png2img.o guiclass.o rotary.o \
 	hp3filt.o lfshelf2.o shuffler.o
-zita-bls1:	CPPFLAGS += -I/usr/X11R6/include `pkg-config --cflags xft`
+zita-bls1:	CPPFLAGS += -I/usr/X11R6/include `$(PKG_CONFIG) --cflags xft`
 zita-bls1:	LDLIBS += -lzita-convolver -lfftw3f -lclxclient -lclthreads -ljack -lcairo -lpthread -lpng -lXft -lX11 -lrt
 zita-bls1:	LDFLAGS += -L/usr/X11R6/lib
 zita-bls1:	$(ZITA-BLS1_O)
-	g++ $(LDFLAGS) -o $@ $(ZITA-BLS1_O) $(LDLIBS)
+	$(CXX) $(LDFLAGS) -o $@ $(ZITA-BLS1_O) $(LDLIBS)
 
 $(ZITA-BLS1_O):
 -include $(ZITA-BLS1_O:%.o=%.d)

Bug#920874: uscan: Error when using USCAN_SYMLINK value described in manual page

[Ben Finney]

Package: devscripts
Version: 2.19.2
Severity: normal

The ‘uscan(1)’ manual page describes the environment variable ‘USCAN_SYMLINK’, 
giving examples of values accepted::

USCAN_SYMLINK
[…] If it is set to `yes` or `symlink`, then the symlinks will be made. […]

The ‘uscan’ program evidently does not support that. When setting 
‘USCAN_SYMLINK=symlink’ the following error occurs::

$ USCAN_SYMLINK=symlink uscan
Argument "symlink" isn't numeric in numeric eq (==) at 
/usr/share/perl5/Devscripts/Uscan/Config.pm line 183.

The error indicates some Perl module is attempting to parse the text value 
“symlink” as a number.

Instead, the program should accept all the values specified for the 
‘USCAN_SYMLINK’ variable and behave with the corresponding semantics.


-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
. $HOME/.profile
USCAN_DESTDIR="../tarballs"
USCAN_SYMLINK=symlink

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.2
ii  fakeroot  1.23-1
ii  file  1:5.35-2
ii  gnupg 2.2.12-1
ii  gnupg22.2.12-1
ii  gpgv  2.2.12-1
ii  libc6 2.28-5
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-1
ii  patchutils0.3.4-2
ii  perl  5.28.1-3
ii  python3   3.7.2-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.0~beta1
ii  at  3.1.23-1
ii  curl7.63.0-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2018.12.24
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.20
ii  libdpkg-perl1.19.2
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.15-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.5.123
ii  man-db  2.8.5-1
ii  patch   2.7.6-3
ii  python3-apt 1.8.1
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.20.0-2
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-4
ii  strace  4.21-1
ii  unzip   6.0-21
ii  wget1.20.1-1
ii  xz-utils5.2.2-1.3

Versions of packages devscripts suggests:
ii  adequate  0.15.1
ii  autopkgtest   5.8
pn  bls-standalone
ii  build-essential   12.5
pn  check-all-the-things  
ii  cvs-buildpackage  5.26
ii  debhelper 12
pn  devscripts-el 
ii  diffoscope108
ii  disorderfs0.5.6-1
pn  dose-extra
ii  duck  0.13
ii  faketime  0.9.7-3
ii  gnuplot-qt [gnuplot]  5.2.6+dfsg1-1
ii  how-can-i-help16
ii  libauthen-sasl-perl   2.1600-1
pn  libdbd-pg-perl
ii  libfile-desktopentry-perl 0.22-1
pn  libnet-smtps-perl 
ii  libterm-size-perl 0.209-1+b1
ii  libtimedate-perl  2.3000-2
pn  libyaml-syck-perl 
ii  mailutils [mailx] 1:3.5-2
pn  mozilla-devscripts
ii  mutt  1.10.1-2
ii  openssh-client [ssh-client]   1:7.9p1-5
ii  piuparts  0.96
ii  postgresql-client 11+198
ii  postgresql-client-11 [postgresql-client]  11.1-2
ii  quilt 0.65-3
pn  ratt  
ii  reprotest   

Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown

[Antoine Beaupré]

On 2019-01-29 21:32:24, Gabriel Filion wrote:
> Hi there,
>
> On 2019-01-29 9:26 p.m., Antoine Beaupre wrote:
>> We'd need an easier way to reproduce this however. Has anyone worked on
>> getting some virtual machine images up to try and orchestrate a
>> reproducer for this? That would be ideal but a step-by-step set of
>> minimal instructions starting from a clean install would be an
>> acceptable compromise.
>
> The bug is hard to reproduce since it's a run condition that might not
> happen sometimes.

It's pretty reliable on the vero 4k+, for what that's worth. But it's a
slower ARM machine...

> The simplest way to reproduce is to have an nfs (or maybe sshfs if it's
> possible to reproduce with this) server, then on a buster machine to add
> the nfs mount as a line to the fstab file, then reboot.
>
> when the mount does not work, it is quite apparent: the boot process
> hangs for some time before NFS decides to timeout.

understood. do you think it would be possible to setup a vagrant box
with this somehow?

a

-- 
>From the age of uniformity, from the age of solitude, from the age of
Big Brother, from the age of doublethink - greetings!
- Winston Smith, 1984

Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown

[Gabriel Filion]

Hi there,

On 2019-01-29 9:26 p.m., Antoine Beaupre wrote:
> We'd need an easier way to reproduce this however. Has anyone worked on
> getting some virtual machine images up to try and orchestrate a
> reproducer for this? That would be ideal but a step-by-step set of
> minimal instructions starting from a clean install would be an
> acceptable compromise.

The bug is hard to reproduce since it's a run condition that might not
happen sometimes.

The simplest way to reproduce is to have an nfs (or maybe sshfs if it's
possible to reproduce with this) server, then on a buster machine to add
the nfs mount as a line to the fstab file, then reboot.

when the mount does not work, it is quite apparent: the boot process
hangs for some time before NFS decides to timeout.



signature.asc
Description: OpenPGP digital signature

Bug#920873: RFP: python3-srht -- core sr.ht shared code

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: python3-srht
  Version : 1.0.0
  Upstream Author : Drew DeVault ( @SirCmpwn@mastodon.social )
* URL : https://git.sr.ht/~sircmpwn/core.sr.ht
* License : BSD-3-Clause
  Programming Lang: python & javascript
  Description : core sr.ht shared code

This repository contains code shared among all sr.ht projects.

sr.ht is a platform to offer git hosting, bug tracking, wikis, manuals, 
accounts, etc.

This is a Python package that provides shared functionality across 
all sr.ht services.  It also contains the default templates and 
stylesheets that give sr.ht a consistent look and feel.  As well as
nodejs code under the hood.

Bug#860264: similar bug with sshfs, maybe in systemd/ifupdown

[Antoine Beaupre]

I still need to reproduce this in a normal Debian install, but I have
had similar problems than this with sshfs, in a OSMC (Debian derivative)
install:

https://discourse.osmc.tv/t/how-to-sshfs-tutorial/77852/11

There's an easy workaround for sshfs: the `delay_connect` option delays
network operations until the mountpoint is accessed. It would still be
nice to fix this for sshfs as it will bite novice users pretty badly.

All this leads me to believe this is a bug in systemd, and not NFS. I
wonder if we should reassign this bug to the systemd (or ifupdown?)
package to get more visibility into it (and keep nfs/sshfs as affected).

We'd need an easier way to reproduce this however. Has anyone worked on
getting some virtual machine images up to try and orchestrate a
reproducer for this? That would be ideal but a step-by-step set of
minimal instructions starting from a clean install would be an
acceptable compromise.

Once we have that, we can try to reproduce in buster as well and figure
out if the bug is actually fixed there or not.

Thanks for the bug report!

A.

-- 
Never be deceived that the rich will allow you to vote away their wealth.
- Lucy Parsons


signature.asc
Description: PGP signature

Bug#920872: libomp not multiarch-installable

[Mo Zhou]

Package: libomp5-7
Version: 1:7.0.1-4

Preparing to unpack .../libomp5-7_1%3a7.0.1-4_i386.deb ...
Unpacking libomp5-7:i386 (1:7.0.1-4) ...
dpkg: error processing archive 
/var/cache/apt/archives/libomp5-7_1%3a7.0.1-4_i386.deb (--unpack):
 trying to overwrite shared '/usr/lib/llvm-7/lib/libomp-7.so.5', which is 
different from other instances of package libomp5-7:i386
Errors were encountered while processing:
 /var/cache/apt/archives/libomp5-7_1%3a7.0.1-4_i386.deb
needrestart is being skipped since dpkg has failed
E: Sub-process /usr/bin/dpkg returned an error code (1)


~ ❯❯❯ apt list libomp5-7 -a
Listing... Done
libomp5-7/unstable,unstable,unstable,now 1:7.0.1-4 amd64 [installed,automatic]
libomp5-7/unstable,unstable 1:7.0.1-4 i386

Bug#821397: intent to sponsor an upload to NEW

[Sean Whitton]

Dear Birger, Nicolas,

On Fri 11 Jan 2019 at 08:19AM +01, Birger Schacht wrote:

> I've sent nicoo another mail about this and i'll let you know as soon as
> i hear back.

Thank you to both of you for your recent work on the sway package.  I
want to unblock inclusion of swaywm in Debian by sponsoring the upload.

There are a few social issues to resolve.

Firstly, I want to ensure that Nicolas is adequately credited for having
done the majority of the packaging work (so far as I can tell); at the
time of writing, where master is at 9303b617, I don't think this is
true.

Secondly, I want to ensure that the Maintainer and Uploaders fields
adequately reflect Debian's social conventions about who gets final say
over the contents of the package.  Right now only Birger is listed.  As
has already been pointed out this could be interpreted as a kind of
package hijack, which we don't want.

I have a few technical questions about the packaging, but they are not
sufficiently severe to block uploading to experimental, so I'm not
addressing them in this e-mail.

This is what I propose we do:

(1) use the [ square brackets ] convention to make it clear that the
initial packaging work was done mainly by Nicolas;

(2) set the Maintainer field to Nicolas; and

(3) set the Uploaders field to Birger,

i.e. apply this diff:

diff --git a/debian/changelog b/debian/changelog
index ac2d939f..e5e6ccd5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
 sway (1.0~beta.2-1) experimental; urgency=medium

+  [ Nicolas Braud-Santoni & Birger Schacht ]
   * Initial packaging (Closes: 897246, 821397)

  -- Birger Schacht   Sun, 02 Dec 2018 20:14:53 +0100
diff --git a/debian/control b/debian/control
index 384a91ee..df3e0d0c 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,8 @@
 Source: sway
 Section: x11
 Priority: optional
-Maintainer: Birger Schacht 
+Maintainer: Nicolas Braud-Santoni 
+Uploaders: Birger Schacht 
 Build-Depends:
  debhelper-compat (= 12),
  libwlroots-dev (>= 0.2),

According to Debian's social conventions, this would mean that both
Birger and Nicolas are allowed to make uploads of the package, but
Nicolas has final say over the contents of the package, and would be
allowed to remove Birger from the Uploaders field.

The last e-mail we have from Nicolas, saying that they are waiting for
sponsorship, indicates that they still want to maintain this package in
Debian.  On the other hand, Birger has worked on the package recently,
and I want to unblock him.  So I think this is a suitable compromise.

Birger, if this sounds good to you, please apply my diff, and then run
`dch -r` again to refresh the timestamp in d/changelog.

I will then upload the package to DELAYED/X where X=15-N, and N is the
number of days that have passed since the date of this e-mail.

Nicolas, if you are not okay with having Birger in the Uploaders field,
you can NACK my sponsorship and do an upload yourself, now that you are
in the uploading keyring.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#920871: RFP: node-xo -- JavaScript happiness style linter

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-xo
  Version : 0.21.1
  Upstream Author : Sindre Sorhus  
* URL : https://notabug.org/makenotabuggreatagain/xo/
* License : MIT
  Programming Lang: javascript
  Description : JavaScript happiness style linter

>From the git repo:

"Opinionated but configurable ESLint wrapper with lots of goodies included. 
Enforces strict and readable code. Never discuss code style on a pull request 
again! 
No decision-making. No .eslintrc or .jshintrc to manage. It just works!"

Uses ESLint ( #743404 ) underneath.

node-xo is a dependency of node-gulp-watch ( #916664 ).

Bug#920682: Ships file in /var/cache

[Josh Triplett]

On Mon, Jan 28, 2019 at 01:24:34PM +0100, intrigeri wrote:
> Josh Triplett:
> > I've submitted a debian-policy patch to document it.
> 
> Amazing! :)

Bug 920692 against policy, if you'd be interested in seconding the
proposal.

Bug#920692: Packages must not install files or directories into /var/cache

[Josh Triplett]

On Tue, Jan 29, 2019 at 01:18:53PM +, Ian Jackson wrote:
> Josh Triplett writes ("Bug#920692: Packages must not install files or 
> directories into /var/cache"):
> > It's well-established in Debian (but not documented in Policy) that
> > packages must not install files or directories under /var/cache.
> 
> I think `install' is a bit less clear than it should be.  I think it's
> clearer when you say `ship'.

Policy currently uses "must not install" and "should not install" many
times over, with the same meaning.

If you're suggesting an ambiguity between "must not install" (as part of
the package) and "must not write" (at runtime), as far as I can tell
Policy generally uses "write" for things done by software at runtime,
and in such cases refers to things like "applications", "programs", or
"software", rather than "packages".

Bug#920692: Packages must not install files or directories into /var/cache

[Josh Triplett]

On Tue, Jan 29, 2019 at 01:20:31PM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: Bug#920692: Packages must not install files or 
> directories into /var/cache"):
> > Josh Triplett writes ("Bug#920692: Packages must not install files or 
> > directories into /var/cache"):
> > > It's well-established in Debian (but not documented in Policy) that
> > > packages must not install files or directories under /var/cache.
> > 
> > I think `install' is a bit less clear than it should be.  I think it's
> > clearer when you say `ship'.
> 
> Also: do we really need to say this in policy ?  Those three packages
> are almost certainly violating the FHS rule, which is imported by
> reference,

I carefully read the FHS, and while it mentions that software must
recover from deletion of files in /var/cache, it doesn't suggest
anything about not shipping files in /var/cache. While it's possible to
reason your way to "this is probably not a good idea" (don't ship files
that the sysadmin is allowed to delete, as that would lead tools like
debsums to flag them as missing from the package), as far as I can tell,
there's nothing in Policy *or* the FHS that proscribes this.

> and probably just filing bugs will fix it.

I have filed bugs already on the packages that didn't already have them.
In one such bug, the response asked where this was documented.

> It only *needs*
> to state things which are not otherwise clear,

I don't believe this is "otherwise clear" from existing policy.

> though it is of course
> useful for it to mention *common* bugs.  3x in Debian doesn't seem
> common to me.

Policy changes should not in general make packages instantly buggy; if
this were more common it wouldn't yet be appropriate to propose this
policy change. :)

It's worth documenting things that some packages have gotten wrong when
the reason why they're wrong isn't obvious and isn't currently
documented anywhere.

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Axel Beckert]

Control: tag -1 moreinfo

Hi!

Gedalya wrote:
> > It just happened again, triggered by wireshark-dkms
> s/wireshark/wireguard/

Ehm, yes. :-)

> Also, on my router, ntpd is moved to another cgroup (for routing
> purposes). This is done in cgroup2, old cgroup is not mounted at
> all. ntpd remains the only running process apart from init.
> 
> Moving udev into its own special cgroup didn't change anything: udev
> is still running, same PID, and and the same goes for ntpd.
> Everything else is killed.

And here you gave me the right hint: cgroups!

I don't have systemd, but I wanted to play with anbox, which
pulled in lxc and cgroupfs-mount besides others. And while I was able
to kill all processes with "udevadm control --reload-rules" just
beforehand, removing these packages made the issue vanish for me:

[REMOVE, NOT USED] bridge-utils:amd64 1.6-2
[REMOVE, NOT USED] dnsmasq-base:amd64 2.80-1
[REMOVE, NOT USED] liblinux-lvm-perl:amd64 0.17-2
[REMOVE, NOT USED] redir:amd64 3.2-1
[REMOVE, DEPENDENCIES] anbox:amd64 0.0~git20181210-1
[REMOVE, DEPENDENCIES] liblxc1:amd64 1:3.1.0+really3.0.3-2
[REMOVE, DEPENDENCIES] lxc:amd64 1:3.1.0+really3.0.3-2
[REMOVE, DEPENDENCIES] lxctl:amd64 0.3.1+debian-4
[REMOVE, DEPENDENCIES] python3-lxc:amd64 1:3.0.3-1
[REMOVE, DEPENDENCIES] vagrant-lxc:amd64 1.4.3-1
[REMOVE] cgroupfs-mount:amd64 1.4

(from /var/log/aptitude)

So I tried to figure out which of these packages actually trigger the
change and installed one by one again. Inbetween each package
installation run I did the following three commands to see if anything
killed my SSH session:

# udevadm control --reload-rules
# service udev restart
# udevadm control --reload-rules

But none did directly. The issue came back later. though and I
rebooted.

Then I uninstalled not all of them at once but each of them one by
one. And the one after whose purging

# service udev restart
# udevadm control --reload-rules

didn't kill my processes anymore was cgroupfs-mount.

So for some reason this killing only seems to happen on my box if
cgroupfs-mount is installed. Then again, this is only necessary if
systemd is not installed. But we also had reports where this happend
with systemd, so this doesn't seem to be depend on the init system (at
most at the init system's default features) and hence also the package
cgroupfs-mount can't be held guilty for this.

Which IMHO again leaves either src:systemd or src:linux as rc-buggy
package.

I've allowed myself to remove at least the moreinfo tag as there are
now multiple hints on how to reproduce this issue.

Will now run my systemd without cgroupfs-mount and see if I ran into
this issue again soon.

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#920870: Clearer NAME section

[積丹尼 Dan Jacobson]

Package: devscripts
Version: 2.19.2
Severity: wishlist
File: /usr/share/man/man1/bts.1.gz

$ apropos bts
bts (1)  - developers' command line interface to the BTS

Please have it say
bts (1)  - Developers' command line interface to the Debian Bug 
Tracking System

even if mentioned further in the man page.

Bug#920869: Mention meaning of NMU at least once

[積丹尼 Dan Jacobson]

Package: devscripts
Version: 2.19.2
Severity: wishlist
File: /usr/share/man/man1/nmudiff.1.gz

$ apropos nmudiff
nmudiff (1)  - email an NMU diff to the Debian BTS
$ man nmudiff

Please mention what NMU stands for, somewhere in the man page.

You mention what BTS stands for right off the bat, but not NMU.

Bug#920868: #920868 : please add (some) support to cross-compile debian-installer

[jhcha54008]

Hi again,

The proposed patch is not arch-specific. 

I tested only for alpha so far - with a 
python 3 script 'netabootwrap.py' (attached) 
to assemble the netboot image : the build 
dependency 'aboot' for alpha is not usable
on amd64. The build dependency check needs to
be switched off altogether to proceed.
The build finished succesfully.

I hope it will help !

Regards,
JH Chatenet

Here are the details :

1/ Make a sid chroot (as in #919596) but there is no
need for a toolchain.

debootstrap --variant=buildd sid mychroot
export LANG=C
mount -t proc proc mychroot/proc
chroot mychroot
mount -t sysfs sysfs sys
mount -t devpts devpts dev/pts -o gid=5,mode=620

2/ Install build-dependencies (amd64 part)

sed -i "s/^deb /&[ arch=$(dpkg --print-architecture) ] /" etc/apt/sources.list
apt-get update && apt-get upgrade
apt-get install fakeroot
apt-get install debian-ports-archive-keyring
apt-get install python3

cat > /etc/apt/sources.list.d/sources.list  /etc/apt/sources.list.d/alpha.list > debian-installer-20190118/build/config/local

gunzip netabootwrap.py.gz && \
mv netabootwrap.py debian-installer-20190118/build/util/netabootwrap
chmod ugo+rx debian-installer-20190118/build/util/netabootwrap

At the time of writing, the kernel abi number should be increased 
(alpha-specific) :

echo "LINUX_KERNEL_ABI = 4.19.0-2" >> 
debian-installer-20190118/build/config/local

6/ Build it :

cd debian-installer-20190118
dpkg-buildpackage -a alpha -d -uc -us


netabootwrap.py.gz
Description: application/gzip

Bug#591781: texlive-base: texdoc barfs on gzipped files under gnome

[Julian Gilbey]

On Tue, Jan 29, 2019 at 10:16:46PM +0100, Hilmar Preuße wrote:
> On 05.08.10 16:41, Julian Gilbey wrote:
> 
> Hi Julian,
> 
> This seems to be similar to #601237. Is the issue still present?
> 
> Hilmar

Hi Hilmar,

I'm not sure if it's present any more, because I can't find a single
.pdf.gz file in /usr/share/doc/texlive* - all of the pdf files are
unzipped, so there is no need for texdoc to unzip them.

I tried zipping it and it still works, though I'm using xdg-open
rather than gnome-open (as I'm running under XFCE now rather than
Gnome).

So I guess closing this bug report is probably OK?

Best wishes,

   Julian

> > Running  texdoc pgf  opens an evince window, but evince complains that
> > there is No such file or directory.
> > 
> > I have tracked down the problem: view.tlu runs the command (split over
> > two lines; the Xb... is of course a unique directory name):
> > 
> > (gnome-open "/tmp/texdoc.Xbpoq3/pgfmanual.pdf"; rm -f
> > "/tmp/texdoc.Xbpoq3/pgfmanual.pdf"; rmdir /tmp/texdoc.Xbpoq3) &
> > 
> > What happens is that gnome-open is called, but gnome-open disconnects
> > from the running process very quickly, so that by the time evince
> > fires up, the file and directory have already been deleted.
> > 
> > I am unsure what the correct solution would be.  I think that the
> > simplest might be to have a "wait" command after the file opening
> > command; the presence of the backgrounding process should alleviate
> > problems this causes.

Bug#920776: sparse: new upstream release

[Ramsay Jones]

On 29/01/2019 20:57, Jonathan Nieder wrote:
> Hi Uwe,
> 
> Uwe Kleine-König wrote:
>> On 1/29/19 2:38 AM, Jonathan Nieder wrote:
> 
>>> Thoughts of all kinds welcome, as always.  If you'd prefer this in the
>>> form of a "git pull"-able repository, a push to salsa, or an NMU, just
>>> ask.
>>
>> I didn't follow sparse development in the nearer past. Is there a
>> problem with sparse 0.5.2 that would be fixed by going to 0.6.0?
>>
>> My thought was not to touch it for buster and go to 0.6.0 only afterwards.
> 
> Cc-ing Ramsay Jones and Luc to find out.  In [1] I find
> 
> | [I was a little surprised that Linux Mint 19.1 (based on Ubuntu
> | 18.04) has v0.5.1 - Debian unstable has v0.5.2, but both of those
> | are just a little too old for use with git on recent Linux.]
> 

see, eg. https://marc.info/?l=linux-sparse=152668057308589=2
 et. seq.

> but I wasn't able to reproduce a problem with v0.5.2 analyzing git.git
> myself.

The problem, which was actually due to the version of glibc, appeared
for me when updating to Ubuntu 18.04 (as a test run for Linux Mint 19
;-) ). It was also present in fedora 27, 28 and 29 (I assume also in
Ubuntu 18.10, but I haven't tried that).

>  That said, v0.6.0 has been working well for me, so I suspect
> upgrading is not too risky.
> 
> One example improvement is
> 
> commit fdf8252f312a40df9aa51c6e30c0d07fa29ebd12
> Author: Ramsay Jones 
> Date:   Sun Nov 18 23:52:23 2018 +
> 
> constant: add -Wconstant-suffix warning
> 
> Currently, when used on the kernel, sparse issues a bunch
> of warnings like:
> warning: constant 0x1 is so big it is long
> 
> These warning are issued when there is a discrepancy
> between the type as indicated by the suffix (or the absence
> of a suffix) and the real type as selected by the type
> suffix *and* the value of the constant.
> 
> Since there is nothing incorrect with this discrepancy,
> (no bits are lost) these warnings are more annoying than useful.
> So, make them depending on a new warning flag -Wconstant-suffix
> and make it off by default.
> 

Although it mentions the kernel, this was indeed the 'fix' for the
problem on 'newer Linux distros'. (I still think glibc should have
been fixed ... ).

This version also adds many fixes for sparse on cygwin and quite a
few for kernel development. See the release notes on the sparse
wiki (https://sparse.wiki.kernel.org/index.php/Sparse_0.6.0_released).

ATB,
Ramsay Jones

Bug#920868: please add (some) support to cross-compile debian-installer

[jhcha54008]

Package: debian-installer
Version: 20190118
Severity: wishlist
Tags: patch

Dear Maintainer,

It would be handy to cross-compile the
debian-installer on amd64 for other architectures.

The patch below aims to suppress some errors
related to build-dependency check and to
packages of a foreign architecture.

I added a new variable 'NO_CHECK_BUILD_DEPS' 
in the makefile to inhibit the build-dependency 
check if needed (dpkg-buildpackage checks build 
dependencies and the makefile calls check-builddeps
as well)

The support of cross-compilation is still partial :
- it doesn't address mklibs (but mklibs-copy is in use
nowadays)
- not all use cases are tested

Thanks in advance for your comments !

Regards,
JH Chatenet

diff -Naur a/build/Makefile b/build/Makefile
--- a/build/Makefile
+++ b/build/Makefile
@@ -309,7 +309,10 @@
 $(STAMPS)tree-unpack-$(targetstring)-stamp: 
$(STAMPS)get_udebs-$(targetstring)-stamp
dh_testroot
@[ -d ../debian ] || { echo "directory '../debian' not found; complete 
source of 'debian-installer' package is required"; false; }
-   cd .. && dpkg-checkbuilddeps
+
+ifeq ($(NO_CHECK_BUILD_DEPS),)
+   cd .. && dpkg-checkbuilddeps -a $(DEB_HOST_ARCH)
+endif
@rm -f $@
 
# This build cannot be restarted, because dpkg gets confused.
@@ -322,6 +325,9 @@
# Only dpkg needs this stuff, so it can be removed later.
mkdir -p $(DPKGDIR)/updates/
touch $(DPKGDIR)/available
+ifneq ($(CROSS),)
+   echo $(ARCH) > $(DPKGDIR)/arch
+endif
 
 ifdef TRANSSTATUS
# Include translation status file; warn if older than 2 weeks.
@@ -499,6 +505,9 @@
mkdir -p $(EXTRAUDEBSDIR)
mkdir -p $(EXTRAUDEBSDPKGDIR)/info $(EXTRAUDEBSDPKGDIR)/updates
touch $(EXTRAUDEBSDPKGDIR)/status $(EXTRAUDEBSDPKGDIR)/available
+ifneq ($(CROSS),)
+   echo $(ARCH) > $(EXTRAUDEBSDPKGDIR)/arch
+endif
 
 ifdef EXTRADRIVERS
# Unpack the udebs of additional driver disks, so mklibs runs on them 
too.
diff -Naur a/build/README b/build/README
--- a/build/README
+++ b/build/README
@@ -477,6 +477,9 @@
 PRESEED
   An initrd preseed file to put in the initrd.
 
+NO_CHECK_BUILD_DEPS
+  If set to a non empty value, this variable inhibits build dependency
+  checks.
 
 Rules invoked from the various targets:
 
diff -Naur a/build/util/gen-sources.list.udeb b/build/util/gen-sources.list.udeb
--- a/build/util/gen-sources.list.udeb  
+++ b/build/util/gen-sources.list.udeb
@@ -34,14 +34,33 @@
local file
for file in $@; do
[ -s $file ] || continue
-   grep '^deb[[:space:]]' $file | \
-  grep -v '^deb[[:space:]]\+cdrom:' | \
-  sed 's,^deb \[[^]]*\] ,deb ,' | \
-  grep -v 
'\(security.debian.org\|volatile.debian.\(net\|org\)\)' | \
-  grep '[[:space:]]main' | \
-  awk '{print $1 " " $2}' | \
-  sed 's,^deb file,deb copy,' | \
-  sed 's,/* *$,,'
+   if [ -n "$CROSS" ] && [ -n "$DEB_HOST_ARCH" ]; then
+   grep '^deb[[:space:]]' $file | \
+  sed -n -e "
+# Do not consider mirrors which don't carry the 
requested architecture
+# They might cause errors if they are signed with 
another keyring
+# No arch=... option : all architectures should be 
there
+/^deb[[:space:]]\+\[[^]]*arch[[:space:]]*=/! p
+# There is an arch=... option : is the requested 
architecture present ?
+
/^deb[[:space:]]\+\[[^]]*arch[[:space:]]*=[[:space:]]*\([^] 
]\+,\)*${DEB_HOST_ARCH}\(,[^] ]\+\)*\([[:space:]]\+\|\]\)/p
+  "  | \
+  grep -v '^deb[[:space:]]\+cdrom:' | \
+  sed 's,^deb \[[^]]*\] ,deb ,' | \
+  grep -v 
'\(security.debian.org\|volatile.debian.\(net\|org\)\)' | \
+  grep '[[:space:]]main' | \
+  awk '{print $1 " " $2}' | \
+  sed 's,^deb file,deb copy,' | \
+  sed 's,/* *$,,'
+   else
+   grep '^deb[[:space:]]' $file | \
+  grep -v '^deb[[:space:]]\+cdrom:' | \
+  sed 's,^deb \[[^]]*\] ,deb ,' | \
+  grep -v 
'\(security.debian.org\|volatile.debian.\(net\|org\)\)' | \
+  grep '[[:space:]]main' | \
+  awk '{print $1 " " $2}' | \
+  sed 's,^deb file,deb copy,' | \
+  sed 's,/* *$,,'
+   fi
done
 }
 
diff -Naur a/build/util/pkg-list b/build/util/pkg-list
--- a/build/util/pkg-list
+++ b/build/util/pkg-list
@@ -66,6 +66,8 @@
-o Dir::Etc::Preferences=./preferences.udeb.local \\
 

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Evan Miller]

I will do an official release of libxls 1.5 this week or next.

Sent from my iPad

> On Jan 29, 2019, at 18:44, Jennifer Bryan  wrote:
> 
> I will kick off my process then.
> 
> Will you do something nice and official re: a release and I should keep my 
> eyes open for it?
> Or am I rolling on my own schedule now, knowing that I am embedding a libxls 
> release in the moral sense?
> 
> -- Jenny
> 
>> On Tue, Jan 29, 2019 at 11:38 AM Evan Miller  wrote:
>> Thanks Jenny. In that case I am not planning any additional code changes, 
>> just documentation and maybe tweaks to the build scripts.
>> 
>> Sent from my iPad
>> 
>>> On Jan 29, 2019, at 11:47, Jennifer Bryan  wrote:
>>> 
>>> Yes, all is good. I had pulled libxls again yesterday after you merged your 
>>> PR and readxl still passes checks on all platforms.
>>> 
>>> https://github.com/tidyverse/readxl/pull/543
>>> 
>>> -- Jenny
>>> 
 On Tue, Jan 29, 2019 at 7:31 AM Evan Miller  wrote:
 All issues identified by OSS-Fuzz are now fixed in libxls master. @Jenny 
 if the code passes your readxl tests I will begin preparing a 1.5 release 
 candidate.
 
 In other news, I heard back from the researcher who initially reported the 
 issues. His GitHub account was marked as spam, which explains why the 
 issues he filed disappeared without warning.
 
 Sent from my iPad
 
 > On Jan 27, 2019, at 10:27, Dirk Eddelbuettel  wrote:
 > 
 > 
 > On 27 January 2019 at 09:25, Evan Miller wrote:
 > | 
 > | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel  wrote:
 > | > 
 > | > 
 > | > On 26 January 2019 at 15:59, Jennifer Bryan wrote:
 > | > | I'll still wait a bit to see if libxls can get to an official 
 > release soon.
 > | > | 
 > | > | But readxl builds and passes tests everywhere with the current 
 > libxls, so
 > | > | that's good news:
 > | > | 
 > | > | https://github.com/tidyverse/readxl/pull/543
 > | > 
 > | > Nice -- should I fold that into an interim release to address the 
 > CVE?
 > | > I can then follow-up with real release whenever you push to CRAN.
 > | 
 > | This would be fine from my end. I am hunting down one last hang 
 > identified by OSS-Fuzz (I.e. potential denial of service), but the CVEs, 
 > buffer overruns, and memory leaks are all fixed in Jenny’s pull request.
 > 
 > Ok I did the easy part: updating our current package (based on Jenny's 
 > readxl
 > 1.2.0 from December 2018) to her current dev branch with your updates. 
 > The
 > delta is small and clean so that was no work. In Debian unstable now.
 > 
 > And I then bravely/foolishly attempted the harder part of backporting to 
 > the
 > (old !!) version in stable.  Turns out it was not so bad and similar to 
 > the
 > fix in April -- I updated the relevant files 'en block':
 > 
 > edd@rob:~/temp-sec$ diff -rq r-cran-readxl-0.1.1.orig/ 
 > r-cran-readxl-0.1.1
 > Files r-cran-readxl-0.1.1.orig/src/libxls/ole.h and 
 > r-cran-readxl-0.1.1/src/libxls/ole.h differ
 > Files r-cran-readxl-0.1.1.orig/src/libxls/xlstool.h and 
 > r-cran-readxl-0.1.1/src/libxls/xlstool.h differ
 > Files r-cran-readxl-0.1.1.orig/src/ole.c and 
 > r-cran-readxl-0.1.1/src/ole.c differ
 > Files r-cran-readxl-0.1.1.orig/src/xls.c and 
 > r-cran-readxl-0.1.1/src/xls.c differ
 > Files r-cran-readxl-0.1.1.orig/src/xlstool.c and 
 > r-cran-readxl-0.1.1/src/xlstool.c differ
 > edd@rob:~/temp-sec$ 
 > 
 > I do get a segfault on the .xls example but _vaguely_ recall that we had
 > issue in April too.  The "example(read_excel)" using the xlsx file works 
 > fine.
 > 
 > Moritz: I'll proceed and send the required debdiff to security@d.o.  I 
 > may
 > need to lean on you once again for 'process' as I don't do this all that 
 > often.
 > 
 > Thanks everybody for the help, particularly Evan of course for the 
 > upstream
 > work, and also Jenny for the clean new branch.
 > 
 > Dirk
 > 
 > | Evan
 > | 
 > | > 
 > | > Dirk
 > | > 
 > | > | -- Jenny
 > | > | 
 > | > | On Sat, Jan 26, 2019 at 7:23 AM Evan Miller  
 > wrote:
 > | > | 
 > | > | >
 > | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel  
 > wrote:
 > | > | > >
 > | > | > >
 > | > | > > On 24 January 2019 at 19:54, Evan Miller wrote:
 > | > | > > |
 > | > | > > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel 
 >  wrote:
 > | > | > > | >
 > | > | > > | >
 > | > | > > | > On 24 January 2019 at 16:36, Evan Miller wrote:
 > | > | > > | > |
 > | > | > > | > | > On Jan 23, 2019, at 01:16, Evan Miller 
 > 
 > | > | > wrote:
 > | > | > > | > | >
 > | > | > > | > | > #34 and #35 have returned from the dead on GitHub. 
 > I’ll take a
 > | > | > closer look later 

Bug#786476: redmine: minor error during postinst

[xia boles]

On Fri, 22 May 2015 15:21:17 +1000 Vincent McIntyre  
wrote:
> Package: redmine
> Version: 2.5.1-2~bpo70+6
> Severity: normal
> Tags: patch
>
> During installation the postinst throws an error.
>
>   Setting up redmine (2.5.1-2~bpo70+6) ...
>
>   Creating config file /etc/redmine/default/session.yml with new version
>   A new secret session key has been generated in 
> /etc/redmine/default/session.yml
>   Redmine instance "default" database must be configured manually.
>   Clearing the cache directory for redmine instance "default".
>   This may take a while.
>   /var/lib/dpkg/info/redmine.postinst: 297: [: -ne: unexpected operator
>
>
> This should fix it:
>
> --- postinst.orig   2015-02-23 03:07:15.0 +1100
> +++ postinst2015-05-22 15:09:53.178357302 +1000
> @@ -293,6 +293,7 @@
> fi
> echo "Clearing the cache directory for redmine 
> instance \"${lInstance}\".
>  This may take a while."
> +   fCode=0
> rake -s tmp:cache:clear RAILS_ENV=$fRailsEnv 
> X_DEBIAN_SITEID="${lInstance}" VERBOSE=$RAKE_VERBOSE || fCode=$?
> if [ $fCode -ne 0 ]; then
> echo "Error when clearing cache. You might 
> need to clear the cache directory /var/cache/redmine/${lInstance}/ manually."
>
> Kind regards
> Vince
>
> -- System Information:
> Debian Release: 7.8
>   APT prefers oldstable
>   APT policy: (990, 'oldstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
>
> --
>
>
Have you tried updating to Debian 8?
Sent from Mail for Windows 10

Bug#919324: CVE-2018-20450 CVE-2018-20452

[Jennifer Bryan]

I will kick off my process then.

Will you do something nice and official re: a release and I should keep my
eyes open for it?
Or am I rolling on my own schedule now, knowing that I am embedding a
libxls release in the moral sense?

-- Jenny

On Tue, Jan 29, 2019 at 11:38 AM Evan Miller  wrote:

> Thanks Jenny. In that case I am not planning any additional code changes,
> just documentation and maybe tweaks to the build scripts.
>
> Sent from my iPad
>
> On Jan 29, 2019, at 11:47, Jennifer Bryan  wrote:
>
> Yes, all is good. I had pulled libxls again yesterday after you merged
> your PR and readxl still passes checks on all platforms.
>
> https://github.com/tidyverse/readxl/pull/543
>
> -- Jenny
>
> On Tue, Jan 29, 2019 at 7:31 AM Evan Miller  wrote:
>
>> All issues identified by OSS-Fuzz are now fixed in libxls master. @Jenny
>> if the code passes your readxl tests I will begin preparing a 1.5 release
>> candidate.
>>
>> In other news, I heard back from the researcher who initially reported
>> the issues. His GitHub account was marked as spam, which explains why the
>> issues he filed disappeared without warning.
>>
>> Sent from my iPad
>>
>> > On Jan 27, 2019, at 10:27, Dirk Eddelbuettel  wrote:
>> >
>> >
>> > On 27 January 2019 at 09:25, Evan Miller wrote:
>> > |
>> > | > On Jan 26, 2019, at 23:09, Dirk Eddelbuettel 
>> wrote:
>> > | >
>> > | >
>> > | > On 26 January 2019 at 15:59, Jennifer Bryan wrote:
>> > | > | I'll still wait a bit to see if libxls can get to an official
>> release soon.
>> > | > |
>> > | > | But readxl builds and passes tests everywhere with the current
>> libxls, so
>> > | > | that's good news:
>> > | > |
>> > | > | https://github.com/tidyverse/readxl/pull/543
>> > | >
>> > | > Nice -- should I fold that into an interim release to address the
>> CVE?
>> > | > I can then follow-up with real release whenever you push to CRAN.
>> > |
>> > | This would be fine from my end. I am hunting down one last hang
>> identified by OSS-Fuzz (I.e. potential denial of service), but the CVEs,
>> buffer overruns, and memory leaks are all fixed in Jenny’s pull request.
>> >
>> > Ok I did the easy part: updating our current package (based on Jenny's
>> readxl
>> > 1.2.0 from December 2018) to her current dev branch with your updates.
>> The
>> > delta is small and clean so that was no work. In Debian unstable now.
>> >
>> > And I then bravely/foolishly attempted the harder part of backporting
>> to the
>> > (old !!) version in stable.  Turns out it was not so bad and similar to
>> the
>> > fix in April -- I updated the relevant files 'en block':
>> >
>> > edd@rob:~/temp-sec$ diff -rq r-cran-readxl-0.1.1.orig/
>> r-cran-readxl-0.1.1
>> > Files r-cran-readxl-0.1.1.orig/src/libxls/ole.h and
>> r-cran-readxl-0.1.1/src/libxls/ole.h differ
>> > Files r-cran-readxl-0.1.1.orig/src/libxls/xlstool.h and
>> r-cran-readxl-0.1.1/src/libxls/xlstool.h differ
>> > Files r-cran-readxl-0.1.1.orig/src/ole.c and
>> r-cran-readxl-0.1.1/src/ole.c differ
>> > Files r-cran-readxl-0.1.1.orig/src/xls.c and
>> r-cran-readxl-0.1.1/src/xls.c differ
>> > Files r-cran-readxl-0.1.1.orig/src/xlstool.c and
>> r-cran-readxl-0.1.1/src/xlstool.c differ
>> > edd@rob:~/temp-sec$
>> >
>> > I do get a segfault on the .xls example but _vaguely_ recall that we had
>> > issue in April too.  The "example(read_excel)" using the xlsx file
>> works fine.
>> >
>> > Moritz: I'll proceed and send the required debdiff to security@d.o.  I
>> may
>> > need to lean on you once again for 'process' as I don't do this all
>> that often.
>> >
>> > Thanks everybody for the help, particularly Evan of course for the
>> upstream
>> > work, and also Jenny for the clean new branch.
>> >
>> > Dirk
>> >
>> > | Evan
>> > |
>> > | >
>> > | > Dirk
>> > | >
>> > | > | -- Jenny
>> > | > |
>> > | > | On Sat, Jan 26, 2019 at 7:23 AM Evan Miller 
>> wrote:
>> > | > |
>> > | > | >
>> > | > | > > On Jan 26, 2019, at 10:05, Dirk Eddelbuettel 
>> wrote:
>> > | > | > >
>> > | > | > >
>> > | > | > > On 24 January 2019 at 19:54, Evan Miller wrote:
>> > | > | > > |
>> > | > | > > | > On Jan 24, 2019, at 19:10, Dirk Eddelbuettel <
>> e...@debian.org> wrote:
>> > | > | > > | >
>> > | > | > > | >
>> > | > | > > | > On 24 January 2019 at 16:36, Evan Miller wrote:
>> > | > | > > | > |
>> > | > | > > | > | > On Jan 23, 2019, at 01:16, Evan Miller <
>> emmil...@gmail.com>
>> > | > | > wrote:
>> > | > | > > | > | >
>> > | > | > > | > | > #34 and #35 have returned from the dead on GitHub.
>> I’ll take a
>> > | > | > closer look later this week.
>> > | > | > > | > | >
>> > | > | > > | > | > Evan
>> > | > | > > | > |
>> > | > | > > | > |
>> > | > | > > | > | OK — I can confirm that all of the reported libxls bugs
>> are fixed.
>> > | > | > > | >
>> > | > | > > | > As in: in the current libxls GH version?  I can make a
>> patched Debian
>> > | > | > > | > release of that.
>> > | > | > > |
>> > | > | > > | Yes, they are fixed in master on GitHub. Note that there
>> are quite a
>> > | > | > few 

Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init

[Axel Beckert]

Control: found -1 240-5

Hi again,

Axel Beckert wrote:
> Another case which predates my original bug report by a few weeks
> (week before christmas or maybe even mid-december), but which I now
> noticed that it had the exact same symptoms:
> 
> I have three screens connected to my workstation:
> 
> 1x DisplayPort
> 1x HDMI
> 1x DVI-D
> 
> All three screens are powered via the same switchable power strip.
> Everything was fine when I powered all three screens of by turning of
> the powerstrip.
> 
> But when I powered them on again by turning on the power strip again,
> the machine showed the same symptoms. I remember that because I was
> confused that the machine just "crashed" that moment I wanted to use
> it again after a long weekend where I was only logged in remotely, if
> at all.

This is now confirmed to be the same issue. If I power on my three
screens via a mechanical power switch in the power strip, it kills all
my processes. (Maybe only one of them is the cause, please ping if
this might be relevant, otherwise I won't test more details.)

> I also plan to check if my "does not happen in the first 20 minutes
> after reboot" is actually the "does not happen until udev is restarted
> at least once after reboot" mentioned by some other victim of this
> bug.

Also verified. "udevadm control --reload-rules" doesn't kill processes
directly after reboot (tested with 4.20-1~exp1), but as soon as I've
called "service udev restart", the next "udevadm control
--reload-rules" kill's all processes again.

> And if that's the case and powering on a monitor triggers it, too, it
> looks to me as this indeed a bug in udev.

Looks like it, yes, but in the meanwhile I was also able to stop this
issue by uinstalling some other packages. I though still haven't
figured out which package exactly is relevant.

Will sent another mail with details once I've figured out the details.

But I already want to say thanks to Gedalya for giving the right hints
on that! :-)

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#920158: stterm: Crash when displaying emoji

[Timothy Allen]

On Tue, 2019-01-29 at 23:56 +0100, Paride Legovini wrote:
> I will report it there, unless you want to report it
> yourself (see https://suckless.org/community/).

Please, go ahead!

Bug#3251: closed by Marcos Fouces (Bug#3251: Any reason to keep a wontfix bug opened for years?)

[Ian Jackson]

reopen -1 ijack...@chiark.greenend.org.uk
severity -1 normal
retitle -1 please work around corruption due to partial records on accton

> Now, it is really closed.

I'm afraid I don't really agree with this bug closure.  Note that
Christian Perrier's message was not sent to me, so I did not have the
opportunity to comment.

The reasons for closure given are:

 * it is is the 6th oldest opened bug in Debian

   Not sure if this is actually being advanced as a reason for closing
   the bug but if so I don't think it is a good one.

 * It is marked `upstream' and upstream is dead.

   If upstream is dead then it is a mistake to mark the bug as
   `upstream'.  Instead, we are now upstream.  That upstream is dead
   is a terrible reason to close a bug.

 * It is marked as `wishlist'

   This is IMO a mistake.  My report describes data corruption
   resulting in entirely wrong output.

 * "nothing will ever be done about it"

   If someone tells me my patch will be considered on its merits, I
   will write a patch.

Sorry to be awkward.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#920158: stterm: Crash when displaying emoji

[Paride Legovini]

Timothy Allen wrote on 25/01/2019:
> On Thu, 2019-01-24 at 13:17 +0100, Paride Legovini wrote:
>> Thanks for your report. Unfortunately I can't reproduce the crash (I
>> actually get an octagonal sign with that printf), so it is difficult
>> for me to debug the issue or forward the bug upstream.
> 
> Thanks for looking into it!
> 
> Out of curiosity, what fonts do you have installed? When I search for
> fonts on my system that provide OCTAGONAL SIGN, I only get one match:
> 
> $ fc-list :charset=0x1F6D1
> /usr/share/fonts/truetype/noto/NotoColorEmoji.ttf: Noto Color 
> Emoji:style=Regular
> 
> (from the fonts-noto-color-emoji package)
> 
> It looks like st does glyph-scavenging so it can display glyphs that
> aren't in the selected font; perhaps it's not prepared to handle fonts
> that provide colour bitmaps.
I had Noto and two more fonts providing U+1F6D1. I uninstalled the other
two, leaving only Noto, and now I can reproduce the crash. It is
definitely an upstream bug that happens even with the latest git tip (as
of 3be4cf11). I will report it there, unless you want to report it
yourself (see https://suckless.org/community/).

Cheers,

Paride

Bug#920867: python3-lib2to3: descriptions still mention Python 3.6

[Gabriele Stilli]

Package: python3-lib2to3
Version: 3.7.2-3

Hi,

both long and short descriptions mention Python 3.6 even though lib2to3
has reached 3.7.2; maybe this is worth updating (perhaps leaving just
"3" and disregarding the subversion?).

Regards,
Gabriele Stilli

Bug#920866: linux-source-4.19: arm64 kernel should have workaround for ARM Cortex-A53 erratum 843419 enabled

[Ard Biesheuvel]

Package: linux-source-4.19
Severity: important

Dear Maintainer,

Currently, the linux-image-arm64 kernel is built with
CONFIG_ARM64_ERRATUM_843419 explicitly disabled, while it defaults to on
in the Kconfig definition.

The GCC toolchain enables a link time workaround for this erratum, and
so all fully linked binaries such as userland executables and shared
libraries, as well as the core kernel (vmlinux), are built with
mitigations that prevent this erratum from being triggered. However,
kernel modules are not fully linked binaries (they are partially linked
object files), and so without this CONFIG option enabled, the resulting
modules may trigger the erratum and crash or corrupt data (or both).

Note that the Cortex-A53 used in the Raspberry Pi 3 is affected by this
erratum.

So please enable CONFIG_ARM64_ERRATUM_843419.

-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages linux-source-4.19 depends on:
ii  binutils  2.28-5
ii  xz-utils  5.2.2-1.2+b1

Versions of packages linux-source-4.19 recommends:
ii  bc1.06.95-9+b3
ii  gcc   4:6.3.0-4
ii  libc6-dev [libc-dev]  2.24-11+deb9u3
pn  linux-config-4.19 
ii  make  4.1-9.1

Versions of packages linux-source-4.19 suggests:
ii  libncurses5-dev [ncurses-dev]  6.0+20161126-1+deb9u2
pn  libqt4-dev 
ii  pkg-config 0.29-4+b1

Bug#918661:

[StalkR]

I also just discovered dnsflagday.net, ran edsncomp against my zone on
stretch pdns-server 4.0.3-1+deb9u2 and it complained about
"edns1=noerror,badversion,soa" (https://ednscomp.isc.org/ednscomp/1fa3f65433).
Not fatal for dnsflagday apparently, but still failures.
So I pinned https://repo.powerdns.com/ to get pdns-server
4.1.5-1pdns.stretch and now it passes (
https://ednscomp.isc.org/ednscomp/15a52244dd) - didn't even have to change
anything in pdns.conf.
If at all possible, consider backporting to 4.0 whatever patches fixed edns
compliance in 4.1?

> To get a clean slate on 4.0, you need to disable the packet cache.
How do you disable it exactly? I also found
https://github.com/PowerDNS/pdns/issues/6806 saying this but it doesn't
mention a setting.
I tried disable-packetcache per
https://doc.powerdns.com/md/recursor/settings/#disable-packetcache but it
seems to be a recursor setting, not authoritative.
I couldn't find a packet cache setting on
https://doc.powerdns.com/md/authoritative/settings/ or
https://doc.powerdns.com/md/authoritative/performance/#packet-cache other
than cache-ttl/max-cache-entries.
(I'm using a bind backend, in case it matters.)

Bug#918182: dpkg: warning: unable to delete old directory '/usr/lib/python3.6/

[Gabriele Stilli]

Hi,

maybe there's yet something left to trim. Here's what I got when
updgrading to python3-lib2to3 (3.7.2-3):

Estrazione di python3-lib2to3 (3.7.2-3) su (3.7.1-1)...
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/lib2to3/pgen2": Directory non vuota
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/lib2to3/fixes": Directory non vuota
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/lib2to3": Directory non vuota
Preparativi per estrarre .../13-python3-distutils_3.7.2-3_all.deb...
Estrazione di python3-distutils (3.7.2-3) su (3.7.1-1)...
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/distutils/command": Directory non vuota
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/distutils": Directory non vuota
Preparativi per estrarre .../14-python3-tk_3.7.2-3_amd64.deb...
Estrazione di python3-tk:amd64 (3.7.2-3) su (3.7.1-1)...
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/tkinter": Directory non vuota
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6": Directory non vuota

(Sorry for the Italian; the message mean "warning: unable to delete old
directory […]: Directory not empty")

After upgrading, here's the content of /usr/lib/python3.6:

$ ls -aR /usr/lib/python3.6
/usr/lib/python3.6:
.  ..  tkinter

/usr/lib/python3.6/tkinter:
.  ..  __pycache__

/usr/lib/python3.6/tkinter/__pycache__:
.font.cpython-36.pyc
..   __init__.cpython-36.pyc
colorchooser.cpython-36.pyc  __main__.cpython-36.pyc
commondialog.cpython-36.pyc  messagebox.cpython-36.pyc
constants.cpython-36.pyc scrolledtext.cpython-36.pyc
dialog.cpython-36.pycsimpledialog.cpython-36.pyc
dnd.cpython-36.pyc   tix.cpython-36.pyc
filedialog.cpython-36.pycttk.cpython-36.pyc

Regards,
Gabriele Stilli

Bug#920865: havp: add support for clamav 0.101

[Sebastian Andrzej Siewior]

Source: havp
Version: 0.92a-4
Severity: important
tags: patch

havp does not compile against new clamav. The patch attached does solve
the issue.

Sebastian
From: Sebastian Andrzej Siewior 
Date: Tue, 29 Jan 2019 23:21:02 +0100
Subject: [PATCH] havp: Update to clamav 0.101
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The API changed slightly: The cl_scanfile() expects now a struct which
options set. CL_SCAN_GENERAL_ALLMATCHES enables all-match mode.
The ~0 for parse enables all possible parses like PE/PDF/…
The heuristic part (which needs to be enabled) matches to the old
behaviour which blocked encrypted archives or doc files.

Signed-off-by: Sebastian Andrzej Siewior 
---
 havp/scanners/clamlibscanner.cpp | 22 +-
 havp/scanners/clamlibscanner.h   |  2 +-
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/havp/scanners/clamlibscanner.cpp b/havp/scanners/clamlibscanner.cpp
index f851552..0abd5b0 100644
--- a/havp/scanners/clamlibscanner.cpp
+++ b/havp/scanners/clamlibscanner.cpp
@@ -204,7 +204,7 @@ int ClamLibScanner::ReloadDatabase()
 string ClamLibScanner::Scan( const char *FileName )
 {
 #ifdef CL_INIT_DEFAULT
-int ret = cl_scanfile(FileName, , NULL, engine, scanopts);
+int ret = cl_scanfile(FileName, , NULL, engine, _options);
 #else
 int ret = cl_scanfile(FileName, , NULL, engine, , scanopts);
 #endif
@@ -280,20 +280,32 @@ ClamLibScanner::ClamLibScanner()
 }
 
 //Set scanning options
-scanopts = CL_SCAN_STDOPT;
+memset(_options, 0, sizeof(struct cl_scan_options));
+
+cl_options.general = CL_SCAN_GENERAL_ALLMATCHES;
+cl_options.parse = ~0;
+
+/* scanopts = CL_SCAN_STDOPT; */
 
 if ( Params::GetConfigBool("CLAMBLOCKMAX") )
 {
-scanopts = scanopts | CL_SCAN_BLOCKMAX;
+/* cl_options = cl_options | CL_SCAN_BLOCKMAX; */
+	cl_options.heuristic |= CL_SCAN_HEURISTIC_EXCEEDS_MAX;
 }
 if ( Params::GetConfigBool("CLAMBLOCKENCRYPTED") )
 {
-scanopts = scanopts | CL_SCAN_BLOCKENCRYPTED;
+/* scanopts = scanopts | CL_SCAN_BLOCKENCRYPTED; */
+	cl_options.heuristic |= CL_SCAN_HEURISTIC_ENCRYPTED_ARCHIVE;
+	cl_options.heuristic |= CL_SCAN_HEURISTIC_ENCRYPTED_DOC;
 }
 if ( Params::GetConfigBool("CLAMBLOCKBROKEN") )
 {
-scanopts = scanopts | CL_SCAN_BLOCKBROKEN;
+/* scanopts = scanopts | CL_SCAN_BLOCKBROKEN; */
+	cl_options.heuristic |= CL_SCAN_HEURISTIC_BROKEN;
+
 }
+if (cl_options.heuristic != 0)
+	cl_options.general |= CL_SCAN_GENERAL_HEURISTICS;
 
 //Set up archive limits
 #ifndef CL_INIT_DEFAULT
diff --git a/havp/scanners/clamlibscanner.h b/havp/scanners/clamlibscanner.h
index f9c63e6..8d2f952 100644
--- a/havp/scanners/clamlibscanner.h
+++ b/havp/scanners/clamlibscanner.h
@@ -42,7 +42,7 @@ struct cl_limits limits;
 struct cl_stat dbstat;
 char dbdir[255];
 
-int scanopts;
+struct cl_scan_options cl_options;
 
 public:
 
-- 
2.20.1

Bug#919802: Bug#919803: Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Markus Koschany]

Am 29.01.19 um 23:09 schrieb Santiago Vila:
> On Tue, Jan 29, 2019 at 11:00:25PM +0100, Gilles Filippini wrote:
> 
>> No, this is a misunderstanding: the code snippet above scans
>> Build-Depends* fields from debian/control. If default-jdk-doc is
>> installed but not referenced in Build-Depends*, then the package will
>> build fine. I've tested this configuration.
> 
> Ah, yes, I see it now.
> 
> Simple question: Is this solution (dropping default-jdk-doc from
> build-depends) valid in general for all the packages failing in a
> similar way? (Do other packages have the same construct which scans
> debian/control?).
> 
> (I started to report them, then I stopped when I was told there was a
> common cause, then I was told each package was to be fixed separately,
> and I suspect there are still a bunch of packages to be reported).
> 
> Thanks a lot.

I think this is a Debian Java toolchain issue and we should not fix this
at the package level. The latest OpenJDK 11 release introduced a change
that broke javadoc generation. We should discuss this on
debian-j...@lists.debian.org. Tony Mancill already provided some hints
for Maven based packages. [1] Javahelper based packaged could be
salvaged as well. Please do not try to fix this individually but engage
in a general solution.

Regards,

Markus

[1] https://lists.debian.org/debian-java/2019/01/msg00049.html



signature.asc
Description: OpenPGP digital signature

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

[John Paul Adrian Glaubitz]

Hi!

On 12/22/18 12:15 AM, John Paul Adrian Glaubitz wrote:
> 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.
Blocker bug in rustc has been fixed now. Could you remove the sparc64 patch
to disable incremental builds in the next upload to close this bug?

Then incremental builds will just work on sparc64!

Thanks,
Adrian

-- 
 .''`.  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#920864: mouse invisible lightdm intel graphics

[franz . danzi]

Package: lightdm
Version: 1.18.3-1

At first login after boot the mouse pointer will disappear. It still works but 
is invisible. Logout and login again will bring the mouse pointer back. This 
behavior is new after I updated stretch today - presumably to stretch 9.7
With some web reasearch I found this to be an old well known problem with 
lightdm and intel graphic chips. I can provide three web links which seem 
helpful:
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1568604
https://antergos.com/wiki/de/hardware/graphics/invisible-mouse-cursor/
https://forum.antergos.com/topic/4375/invisible-mouse-cursor-after-sleep-lock

I am using Debian GNU/Linux 9.7 with Kernel 4.9.0-8-amd64 #1 SMP Debian 
4.9.130-2 (2018-10-27) x86_64 GNU/Linux and XFCE 4.12.3 desktop environment and 
lightdm 1.18.3-1 , light-locker 1.7.0-3
The graphics chip identifies as Intel Corporation Atom Processor 
D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller with Kernel Modul i915

Bug#3251: Any reason to keep a wontfix bug opened for years?

[Marcos Fouces]

Hello

I also believe that this bug report is useless. As today (January 2019)
it is almost 23 years old!

Upstream is dead and, as far as i know, nobody took over upstream
maintenance.

For this reason i close this bug now.

Greetings,

Marcos

Bug#918719: task-spooler option -w does not appear to work as intended

[Marco Ricci]

Greetings!

Thus spoke Alexander Inyukhin:
> On Tue, Jan 08, 2019 at 06:08:00PM +0100, Davide Monsorno
> wrote:
> > I have tried to use task spooler in order to launch 2 tasks
> > (a1,a2) in parallel, followed by 3 tasks (b1,b2,b3) in
> > parallel. To this end, I have increased the maximum number
> > of slots to 3, with the option -S [number of slots].
> 
> Task spooler has a limited support for dependencies. Probably,
> an external logic is required to handle this case.
> 
> [...]
> 
> I could forward request upstream to support multiple
> dependencies.

+1 for multiple dependency support. task-spooler 1.0-1 indeed
sadly only supports single dependencies; it's baked into the
"queue item" data structure it employs.

I see two ways to implement the "external logic" you mention
above, and both of them have drawbacks.

The straight-forward way is to submit a task that first waits for
all dependencies in turn and then runs the real task. This blocks
at least one slot, and may block one of its own dependencies from
actually running because there are no more free slots left,
creating a livelock.

The less straight-forward way is to wrap the task in a chain of
task-spooler submissions, each with one dependency less than the
previous link in the chain. For example, assume task D depends on
C, B, and A. First, submit A as usual. Then create task B' which
depends on A and whose action is to submit task C'. Task C'
depends on B and its action is to submit task D'. Task D' depends
on C and its action is to submit task D. Task D shall depend on
no other tasks. Once A, B and C are done, then task D' will
succeed in submitting task D, effectively making D depend on A,
B and C.

This approach does not unnecessarily block task-spooler slots
since task-spooler is keeping track of when to actually run the
respective tasks. But because it creates intermediate tasks it
is difficult to use when A, B or C themselves have multiple
dependencies and must be chained as well; the final task IDs of
A, B and C are only known once the true A, B and C tasks are
submitted.

Having upstream support for multiple dependencies would move this
logic into the task-spooler itself, where such dependency checks
can be done without running a task too early or starting multiple
intermediate tasks, and thus sidestepping the above-mentioned
drawbacks. So yes, please do forward this request for support to
upstream.

Thank you, and kind regards,
Marco


signature.asc
Description: PGP signature

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Santiago Vila a écrit le 29/01/2019 à 22:55 :
> On Tue, Jan 29, 2019 at 09:44:40PM +0100, Gilles Filippini wrote:
> 
>> Looking at the jh_build code, the list of -link javadoc options is 
>> constructed from this snippet:
>>CLASSPATHDOCS="`for i in $(grep-dctrl --no-field-names --show-field 
>> Build-Depends,Build-Depends-Indep -F source "$pkg" debian/control | tr , ' ' 
>> | sed 's/([^)]*)//g') ; do dpkg -L $i 2>/dev/null | grep 
>> /usr/share/doc/.*/api$; done | sed 's/^/-link /' | xargs`"
>>
>> Then dropping default-jdk-doc from Build-Depends did the trick!
> 
> Please note that if the package does not build when default-jdk-doc is
> present, then (imo) you should probably use build-conflicts against it and
> any similar package which we know makes the package to FTBFS, not just
> remove it from build-depends.
> 
> (At least this is what build-conflicts was invented for).

No, this is a misunderstanding: the code snippet above scans
Build-Depends* fields from debian/control. If default-jdk-doc is
installed but not referenced in Build-Depends*, then the package will
build fine. I've tested this configuration.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Santiago Vila]

On Tue, Jan 29, 2019 at 11:00:25PM +0100, Gilles Filippini wrote:

> No, this is a misunderstanding: the code snippet above scans
> Build-Depends* fields from debian/control. If default-jdk-doc is
> installed but not referenced in Build-Depends*, then the package will
> build fine. I've tested this configuration.

Ah, yes, I see it now.

Simple question: Is this solution (dropping default-jdk-doc from
build-depends) valid in general for all the packages failing in a
similar way? (Do other packages have the same construct which scans
debian/control?).

(I started to report them, then I stopped when I was told there was a
common cause, then I was told each package was to be fixed separately,
and I suspect there are still a bunch of packages to be reported).

Thanks a lot.

Bug#920863: RM: phast [arm64 armel armhf ppc64el s390x powerpc ppc64 riscv64] -- ROM; Latest upstream version does not build on architectures where char is signed

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi ftpmasters,

please remove phast for these architectures to let the package migrate
to testing.

Thanks for you work as ftpmaster, Andreas.

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Santiago Vila]

On Tue, Jan 29, 2019 at 09:44:40PM +0100, Gilles Filippini wrote:

> Looking at the jh_build code, the list of -link javadoc options is 
> constructed from this snippet:
>CLASSPATHDOCS="`for i in $(grep-dctrl --no-field-names --show-field 
> Build-Depends,Build-Depends-Indep -F source "$pkg" debian/control | tr , ' ' 
> | sed 's/([^)]*)//g') ; do dpkg -L $i 2>/dev/null | grep 
> /usr/share/doc/.*/api$; done | sed 's/^/-link /' | xargs`"
> 
> Then dropping default-jdk-doc from Build-Depends did the trick!

Please note that if the package does not build when default-jdk-doc is
present, then (imo) you should probably use build-conflicts against it and
any similar package which we know makes the package to FTBFS, not just
remove it from build-depends.

(At least this is what build-conflicts was invented for).

Thanks.

Bug#901422: gpaste-daemon: random crash (SIGSEGV)

[Jérémy Lal]

Package: gpaste
Followup-For: Bug #901422

Hi,

did you see it recently happen with version 3.30.2-1 ?

Regards,
Jérémy

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

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

Versions of packages gpaste depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libc62.28-5
ii  libglib2.0-0 2.58.2-4
ii  libgpaste11  3.30.2-1
ii  libgtk-3-0   3.24.4-1

gpaste recommends no packages.

gpaste suggests no packages.

-- no debconf information

Bug#189616: jadetex: Japanese JadeTeX

[Hilmar Preuße]

On 19.04.03 01:47, OHURA Makoto wrote:

Dear OHURA,

https://bugs.debian.org/189616

>   The following patch is for Japanese JadeTeX.
> 
>   pTeX is a variant of plain TeX, which can handle Japanese.  If
> you use pTeX instead of Knuth's TeX when making fmt file and
> typesetting jadetex file, you can convert Japanese Docbook SGML
> file to dvi.
> 
>   The following patch makes two binary packages, jadetex and
> jadetex-ptex.  The former is the same as your original jadetex
> package, I think.  The latter is Japanese JadeTeX depending
> ptex-bin which is in Debian archive.
> 
Is this patch still needed or are current TeX / jadetex variants able to
convert Japanese Docbook SGML to dvi/pdf natively?

Many thanks!
  Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#920861: Use same $HOSTNAME for hosts on LAN and WiFi

[Mike Gabriel]

Hi,

On  Di 29 Jan 2019 22:32:40 CET, Dominik George wrote:


Hi,


at the schools we maintain in Schleswig-Holstein, we regularly run into an
issue that becomes more and more pressing.

We add puppet on top of Debian Edu to maintain the system over the years and
deploy customer requested changes on top of Debian Edu systems.

Puppet is really picky on the $HOSTNAME of a system that has been joined to
the puppet master server. That is, hostname and puppet certificate CN must
match.

This becomes really problematic on systems that flip-flop regarding their IP
address / hostname. We support several workstations that are sometimes used
on the LAN and sometimes on the WiFi network. The Debian Edu hostname update
mechanism let's these host flip-flop between the DNS name for their LAN IP
and the DNS name for the WiFi IP.


Why have two IPs in the first place? Here, we normally just hand out the
same IP to both interfaces, and prevent both being used with ifplugd.

-nik


tell me more... How do you set up ifplugd and how do you persuade  
GOsa's DHCP stuff to accept duplicate IPs?


Mike
--

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

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



pgpUCMcae8gaP.pgp
Description: Digitale PGP-Signatur

Bug#920767: e2fsprogs: [REGRESSION] e4defrag version 1.44.5-1 segfaults on an armel system (but 1.44.4-2 doesn't)

[Edmund Grimley Evans]

grep defraged_file_count `find * -type f`

reveals suspicious discrepency between declaration and format strings:

misc/e4defrag.c:static unsigned long longdefraged_file_count;
misc/e4defrag.c:"  extents: %d -> %d\n", defraged_file_count,
misc/e4defrag.c:"  extents: %d -> %d\n", defraged_file_count,
misc/e4defrag.c:printf("[%u/%u]", defraged_file_count, total_count);
misc/e4defrag.c:printf("[%u/%u]", defraged_file_count, total_count);

Note that other declarations changed between 1.44.4 and 1.44.5 so
there may be other similar problems.

Something like printf("...%d...%s...", long_long_int, pointer_to_char)
could lead to a segfault on armel, though usually there would be a
conspicuous warning from the compiler.

Bug#920862: xorg: Input doesn't work on LTSP clients while X is running, works otherwise

[Lasse Flygenring-Harrsen]

Package: xorg
Version: 1:7.7+19
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I have been running a Fat-client LTSP (pxe network booted clients getting their 
software from NBD on a server) system at the school were i work
for a couple of months, however recently input stopped working an all
physical hardware, the system boots fine and the Displaymanager (LDM in
my case) works fine except for the fact that keyboard and mouse input
doesn't work. I have managed to get to a shell on the machines and in
text mode TTY's keyboard input works fine and i have confirmed that
both mouse and keyboard is being detected with lsusb. I also tried
starting KDE with startkde, and X seems to work fine there as well except
for the lack of keyboard input, same with xinit and xterm. I have also tried 
PS/2 input on the
machines with the same results. The weirdest
thing however is that virtual machines that boot from the same server do
work, both with KVM and VirtualBox that are configured to simulate USB inputs. 
I have
included the contents of /var/log/Xorg.0.log from one of the affected
physical computers below. The problem seems to affect both the stable
and testing branch, I have tried reinstallintg with both. With the same
results.  
i

 /var/log/Xorg.0.log 
[  1356.849] 
X.Org X Server 1.20.3
X Protocol Version 11, Revision 0
[  1356.849] Build Operating System: Linux 4.9.0-8-amd64 x86_64 Debian
[  1356.849] Current Operating System: Linux ltsp982 4.18.0-1-amd64 #1 SMP 
Debian 4.18.6-1 (2018-09-06) x86_64
[  1356.849] Kernel command line: BOOT_IMAGE=vmlinuz-4.18.0-1-amd64 ro 
initrd=initrd.img-4.18.0-1-amd64 init=/sbin/init-ltsp quiet root=/dev/nbd0 
BOOTIF=01-2c-fd-a1-e2-9f-70
[  1356.849] Build Date: 25 October 2018  06:15:23PM
[  1356.849] xorg-server 2:1.20.3-1 (https://www.debian.org/support) 
[  1356.849] Current version of pixman: 0.36.0
[  1356.849]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[  1356.849] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[  1356.849] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jan 29 19:31:33 
2019
[  1356.849] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[  1356.850] (==) No Layout section.  Using the first Screen section.
[  1356.850] (==) No screen section available. Using defaults.
[  1356.850] (**) |-->Screen "Default Screen Section" (0)
[  1356.850] (**) |   |-->Monitor ""
[  1356.850] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[  1356.850] (==) Automatically adding devices
[  1356.850] (==) Automatically enabling devices
[  1356.850] (==) Automatically adding GPU devices
[  1356.850] (==) Max clients allowed: 256, resource mask: 0x1f
[  1356.850] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[  1356.850]Entry deleted from font path.
[  1356.850] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[  1356.850] (==) ModulePath set to "/usr/lib/xorg/modules"
[  1356.850] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[  1356.850] (II) Loader magic: 0x55d74ed61e20
[  1356.850] (II) Module ABI versions:
[  1356.850]X.Org ANSI C Emulation: 0.4
[  1356.850]X.Org Video Driver: 24.0
[  1356.850]X.Org XInput driver : 24.1
[  1356.850]X.Org Server Extension : 10.0
[  1356.851] (--) using VT number 2

[  1356.851] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[  1356.853] (--) PCI:*(9@0:0:0) 1002:15dd:1002:15dd rev 198, Mem @ 
0xe000/268435456, 0xf000/2097152, 0xfe50/524288, I/O @ 
0xe000/256, BIOS @ 0x/131072
[  1356.853] (II) LoadModule: "glx"
[  1356.853] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[  1356.854] (II) Module glx: vendor="X.Org Foundation"
[  1356.854]compiled for 1.20.3, module version = 1.0.0
[  1356.854]ABI class: X.Org Server Extension, version 10.0
[  1356.854] (==) Matched ati as autoconfigured driver 0
[  1356.854] (==) Matched modesetting as autoconfigured driver 1
[  1356.854] (==) Matched fbdev as autoconfigured driver 2
[  1356.854] (==) Matched vesa as autoconfigured driver 3
[  1356.854] (==) Assigned the driver to the xf86ConfigLayout
[  1356.854] (II) LoadModule: "ati"
[  1356.854] (II) Loading /usr/lib/xorg/modules/drivers/ati_drv.so
[  1356.854] (II) Module ati: vendor="X.Org Foundation"
[  1356.854]compiled for 1.20.1, 

Bug#896971: ghc-mod

[Clint Adams]

It appears as though ghc-mod has been deprecated in favor
of haskell-ide-engine.

Bug#562657: tex4ht: Incorrect output

[Hilmar Preuße]

On 26.12.09 19:57, Andrey wrote:

Hi Andrey,

https://bugs.debian.org/562657

> To reproduce:
> 
> $ cat >test.tex
> \documentclass{minimal}
> 
> \usepackage[T2A]{fontenc}
> \usepackage[utf8]{inputenc}
> \usepackage[russian]{babel}
> 
> \begin{document}
> 
> \textbf{Test Тест}
> \textit{Test Тест}
> \textbf{\textit{Test Тест}}
> 
> \end{document}
> ^D
> $ htlatex test "xhtml,charset=utf-8" " -cunihtf -utf8"
> $ cat test.html
>  
>"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>  
>  
>  
>  
>  
> >
>  class="labx-1000">Test Тест  class="lati-1000">Test Тест  class="labi-1000">Test 
>  
>  
> 
> Bold italic Cyrillic symbols are output as italic symbols are Ok.
> 
Currently we have:

hille@sid:~ $ tail -n 10 test.html
Test Тест Test Тест Test Тест




, which looks OK to me. Do you agree to close the issue?

H.
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#920861: Use same $HOSTNAME for hosts on LAN and WiFi

[Dominik George]

Hi,

> at the schools we maintain in Schleswig-Holstein, we regularly run into an
> issue that becomes more and more pressing.
> 
> We add puppet on top of Debian Edu to maintain the system over the years and
> deploy customer requested changes on top of Debian Edu systems.
> 
> Puppet is really picky on the $HOSTNAME of a system that has been joined to
> the puppet master server. That is, hostname and puppet certificate CN must
> match.
> 
> This becomes really problematic on systems that flip-flop regarding their IP
> address / hostname. We support several workstations that are sometimes used
> on the LAN and sometimes on the WiFi network. The Debian Edu hostname update
> mechanism let's these host flip-flop between the DNS name for their LAN IP
> and the DNS name for the WiFi IP.

Why have two IPs in the first place? Here, we normally just hand out the
same IP to both interfaces, and prevent both being used with ifplugd.

-nik

-- 
Dominik George (1. Vorstandsvorsitzender, pädagogischer Leiter)
Teckids e.V. — Digitale Freiheit mit Jugend und Bildung
https://www.teckids.org/


signature.asc
Description: PGP signature

Bug#920834: mlucas: FTBFS and baseline vioiation on i386

[Alex Vong]

Dear Adrian Bunk,

Regarding FTBFS, I've commented it at .

Regarding baseline vioiation on i386, the autotool build system builds 2
versions of the binary: generic-c and SSE2, and install it to
libexecdir. Then the wrapper script selects the right binary at
run-time. Does this approach satifies the current policy?

Cheers,
Alex

Adrian Bunk  writes:

> Source: mlucas
> Version: 17.1-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/fetch.php?pkg=mlucas=i386=17.1-1=1548777459=0
>
> ...
> gcc -pthread -O2 -O3 -Ofast -flto -pipe -ftree-vectorize
> -floop-nest-optimize -fomit-frame-pointer -g -g3
> -fstack-protector-strong -fstack-clash-protection -mmitigate-rop
> -fwrapv -m32 -msse2
> -fdebug-prefix-map=/<>=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wl,-z,relro -Wl,-z,now -o
> mlucas-sse2 src/mlucas_sse2-Mlucas.o src/mlucas_sse2-br.o
> src/mlucas_sse2-dft_macro.o src/mlucas_sse2-factor.o
> src/mlucas_sse2-fermat_mod_square.o src/mlucas_sse2-fgt_m61.o
> src/mlucas_sse2-gcd_lehmer.o src/mlucas_sse2-getRealTime.o
> src/mlucas_sse2-get_cpuid.o src/mlucas_sse2-get_fft_radices.o
> src/mlucas_sse2-get_fp_rnd_const.o
> src/mlucas_sse2-get_preferred_fft_radix.o src/mlucas_sse2-imul_macro.o
> src/mlucas_sse2-mers_mod_square.o src/mlucas_sse2-mi64.o
> src/mlucas_sse2-pairFFT_mul.o src/mlucas_sse2-qfloat.o
> src/mlucas_sse2-radix1008_ditN_cy_dif1.o
> src/mlucas_sse2-radix1024_ditN_cy_dif1.o
> src/mlucas_sse2-radix104_ditN_cy_dif1.o
> src/mlucas_sse2-radix10_ditN_cy_dif1.o
> src/mlucas_sse2-radix112_ditN_cy_dif1.o
> src/mlucas_sse2-radix11_ditN_cy_dif1.o
> src/mlucas_sse2-radix120_ditN_cy_dif1.o
> src/mlucas_sse2-radix128_ditN_cy_dif1.o
> src/mlucas_sse2-radix12_ditN_cy_dif1.o
> src/mlucas_sse2-radix13_ditN_cy_dif1.o
> src/mlucas_sse2-radix144_ditN_cy_dif1.o
> src/mlucas_sse2-radix14_ditN_cy_dif1.o
> src/mlucas_sse2-radix15_ditN_cy_dif1.o
> src/mlucas_sse2-radix160_ditN_cy_dif1.o
> src/mlucas_sse2-radix16_dif_dit_pass.o
> src/mlucas_sse2-radix16_ditN_cy_dif1.o
> src/mlucas_sse2-radix16_dyadic_square.o
> src/mlucas_sse2-radix16_pairFFT_mul.o
> src/mlucas_sse2-radix16_wrapper_ini.o
> src/mlucas_sse2-radix16_wrapper_square.o
> src/mlucas_sse2-radix176_ditN_cy_dif1.o
> src/mlucas_sse2-radix18_ditN_cy_dif1.o
> src/mlucas_sse2-radix192_ditN_cy_dif1.o
> src/mlucas_sse2-radix208_ditN_cy_dif1.o
> src/mlucas_sse2-radix20_ditN_cy_dif1.o
> src/mlucas_sse2-radix224_ditN_cy_dif1.o
> src/mlucas_sse2-radix22_ditN_cy_dif1.o
> src/mlucas_sse2-radix240_ditN_cy_dif1.o
> src/mlucas_sse2-radix24_ditN_cy_dif1.o
> src/mlucas_sse2-radix256_ditN_cy_dif1.o
> src/mlucas_sse2-radix26_ditN_cy_dif1.o
> src/mlucas_sse2-radix288_ditN_cy_dif1.o
> src/mlucas_sse2-radix28_ditN_cy_dif1.o
> src/mlucas_sse2-radix30_ditN_cy_dif1.o
> src/mlucas_sse2-radix31_ditN_cy_dif1.o
> src/mlucas_sse2-radix32_dif_dit_pass.o
> src/mlucas_sse2-radix32_ditN_cy_dif1.o
> src/mlucas_sse2-radix32_dyadic_square.o
> src/mlucas_sse2-radix32_wrapper_ini.o
> src/mlucas_sse2-radix32_wrapper_square.o
> src/mlucas_sse2-radix36_ditN_cy_dif1.o
> src/mlucas_sse2-radix4032_ditN_cy_dif1.o
> src/mlucas_sse2-radix40_ditN_cy_dif1.o
> src/mlucas_sse2-radix44_ditN_cy_dif1.o
> src/mlucas_sse2-radix48_ditN_cy_dif1.o
> src/mlucas_sse2-radix512_ditN_cy_dif1.o
> src/mlucas_sse2-radix52_ditN_cy_dif1.o
> src/mlucas_sse2-radix56_ditN_cy_dif1.o
> src/mlucas_sse2-radix5_ditN_cy_dif1.o
> src/mlucas_sse2-radix60_ditN_cy_dif1.o
> src/mlucas_sse2-radix63_ditN_cy_dif1.o
> src/mlucas_sse2-radix64_ditN_cy_dif1.o
> src/mlucas_sse2-radix6_ditN_cy_dif1.o
> src/mlucas_sse2-radix72_ditN_cy_dif1.o
> src/mlucas_sse2-radix768_ditN_cy_dif1.o
> src/mlucas_sse2-radix7_ditN_cy_dif1.o
> src/mlucas_sse2-radix80_ditN_cy_dif1.o
> src/mlucas_sse2-radix88_ditN_cy_dif1.o
> src/mlucas_sse2-radix8_dif_dit_pass.o
> src/mlucas_sse2-radix8_ditN_cy_dif1.o
> src/mlucas_sse2-radix960_ditN_cy_dif1.o
> src/mlucas_sse2-radix96_ditN_cy_dif1.o
> src/mlucas_sse2-radix992_ditN_cy_dif1.o
> src/mlucas_sse2-radix9_ditN_cy_dif1.o src/mlucas_sse2-rng_isaac.o
> src/mlucas_sse2-test_fft_radix.o src/mlucas_sse2-threadpool.o
> src/mlucas_sse2-twopmodq.o src/mlucas_sse2-twopmodq100.o
> src/mlucas_sse2-twopmodq128.o src/mlucas_sse2-twopmodq128_96.o
> src/mlucas_sse2-twopmodq160.o src/mlucas_sse2-twopmodq192.o
> src/mlucas_sse2-twopmodq256.o src/mlucas_sse2-twopmodq64_test.o
> src/mlucas_sse2-twopmodq80.o src/mlucas_sse2-twopmodq96.o
> src/mlucas_sse2-types.o src/mlucas_sse2-util.o -lm
> /usr/bin/ld: /usr/bin/ld: DWARF error: could not find abbrev number 222
> /tmp/ccxqWoW9.ltrans26.ltrans.o: in function `radix16_dyadic_square':
> :(.text+0x1213e): undefined reference to
> `SSE2_RADI16_CALC_TWIDDLES_1_2_4_8_13'
> collect2: error: ld returned 1 exit status
> make[1]: *** [Makefile:3685: mlucas-sse2] Error 1
>
>
> SSE i  not part of the i386 baseline.


signature.asc
Description: PGP signature

Bug#920649: wine backports: include stub for SetWindowThemeAttribute

[Jens Reyer]

HI

On 27.01.19 22:39, Axel Huebl wrote:
> I am using wine 3.0.3 from stretch-backports.
> 
> With the latest update (v1.6.0) of the reMarkable desktop GUI, the upgrade
> breaks on an unimplemented function.
> 
>   https://remarkable.com
>   https://remarkable.engineering
> 
> Wine 3.1.0 fixes this via commit
>   https://github.com/wine-
> mirror/wine/commit/28613fcd934bffb3a581830a8fa7568ab35e4140
> 
> Can you please add either wine 3.1.0 or just the little stub patch to
> stretch-
> backports?

Thanks for your report.  I'll soon upload 4.0 to stretch-backports, that
should fix it.

Greets
jre

btw, you may also update your fonts-wine to the backports version.

Bug#920861: Use same $HOSTNAME for hosts on LAN and WiFi

[Mike Gabriel]

Package: debian-edu-config
Version: 2.10.58
Severity: wishlist

Hi,

at the schools we maintain in Schleswig-Holstein, we regularly run  
into an issue that becomes more and more pressing.


We add puppet on top of Debian Edu to maintain the system over the  
years and deploy customer requested changes on top of Debian Edu  
systems.


Puppet is really picky on the $HOSTNAME of a system that has been  
joined to the puppet master server. That is, hostname and puppet  
certificate CN must match.


This becomes really problematic on systems that flip-flop regarding  
their IP address / hostname. We support several workstations that are  
sometimes used on the LAN and sometimes on the WiFi network. The  
Debian Edu hostname update mechanism let's these host flip-flop  
between the DNS name for their LAN IP and the DNS name for the WiFi IP.


We recommend to customers using a name pattern where the LAN IP is  
assigned to "" and the WiFi IP is assigned to  
"-wifi", if hosts are more often on LAN than on WiFi.


For hosts, being more online on WiFi, we recommand "" for  
the WiFi IP and "-lan" for the LAN IP.


This could all be avoided if the update-hostname-from-ip could be  
taught the above (or a similar) hack.


Is this something, we can provide via Debian Edu directly? Our  
alternative here is to override update-hostname-from-ip with  
dpkg-divert here locally, which I would like to avoid.


Request for feedback and comments,
Thanks,
Mike
--

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

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



pgpO8ttD062oq.pgp
Description: Digitale PGP-Signatur

Bug#920835: mlucas FTBFS on !amd64: test failures

[Alex Vong]

Hello Adrian Bunk,

The test log is not useful at all. I want to add a patch to enable
verbose test log and let it build again to identify the issues.

Is it possible for me to get access to porter machine or should I upload
to experimental and let buildd to build it?

Thanks for your great work in Debian!

Cheers,
Alex

Adrian Bunk  writes:

> Source: mlucas
> Version: 17.1-1
> Severity: serious
> Tags: ftbfs
>
> https://buildd.debian.org/status/package.php?p=mlucas=sid
>
> ...
> FAIL: tests/spot-check
> ==
>
> ./tests/..//mlucas: 149: exec: ./tests/../: Permission denied
> FAIL tests/spot-check (exit status: 126)
>
> FAIL: tests/self-test
> =
>
> ./tests/..//mlucas: 149: exec: ./tests/../: Permission denied
> FAIL tests/self-test (exit status: 126)
>
> FAIL: tests/fermat-test
> ===
>
> ./tests/..//mlucas: 149: exec: ./tests/../: Permission denied
> FAIL tests/fermat-test (exit status: 126)
>
> 
> Testsuite summary for Mlucas 17.1
> 
> # TOTAL: 3
> # PASS:  0
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  3
> # XPASS: 0
> # ERROR: 0
> 
> See ./test-suite.log
> Please report to ewma...@aol.com
> 
> make[3]: *** [Makefile:12510: test-suite.log] Error 1


signature.asc
Description: PGP signature

Bug#920856: notmuch-emacs: muttprint/evince fails to show "print"

[David Bremner]

Control: -1 patch

Joerg Jaspert  writes:

> Package: notmuch-emacs
> Version: 0.28-2~bpo9+1
> Severity: normal
>
> Dear Maintainer,
>
>  (setq notmuch-print-mechanism 'notmuch-print-muttprint/evince)
>
> and then pressing # while having a mail displayed leads to an evince
> that displays a plenty unhelpful message about not being allowed to open
> the file file:///tmp/dir/notmuch$RANDOM
>
> Looking at the file, it has nice rights so i am allowed to open it. file
> on it reports it as postscript. But silly evince hates it. mv to the
> rescue: Put a ".ps" at the end and boo, evince opens it all fine.
>
> Guess you want to adjust the tempfile name...

Hi Ganneff;

Thanks for the detailed report. I think the following fixes it. I want to
take a look for similar problems in the other print methods, then I'll
do an upload.  If you have the unpacked source, you can test by applying
this patch, and run ./devel/try-emacs-mua

diff --git a/emacs/notmuch-print.el b/emacs/notmuch-print.el
index bca759fa..fbc60ce5 100644
--- a/emacs/notmuch-print.el
+++ b/emacs/notmuch-print.el
@@ -82,7 +82,7 @@ Optional OUTPUT allows passing a list of flags to muttprint."
 
 (defun notmuch-print-muttprint/evince (msg)
   "Preview a message buffer using muttprint and evince."
-  (let ((ps-file (make-temp-file "notmuch")))
+  (let ((ps-file (make-temp-file "notmuch" nil ".ps")))
 (notmuch-print-run-muttprint (list "--printer" (concat "TO_FILE:" 
ps-file)))
 (notmuch-print-run-evince ps-file)))
 

Bug#876428: No 'standard' image of Debian-Live

[Daniel Lewart]

Good news!

Nov 17-18, 2018: Steven Monai's merge requests were accepted

Jan 10, 2019: Accepted live-tasks 0.5 (source all) into unstable

Jan 16, 2019: live-tasks 0.5 MIGRATED to testing

Jan 27, 2019: My live-setup patch was applied:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920244

Jan 28, 2019: Weekly live images were successfully generated:
  https://cdimage.debian.org/cdimage/weekly-live-builds/i386/iso-hybrid/
  https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/

Thus, I believe that this bug should be tagged as 'fixed'.

Peace!
Dan

Bug#920860: RFS: urlwatch/2.16-1

[Maxime Werlen]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: urlwatch
   Version : 2.16-1
   Upstream Author : Thomas Perl
 * URL : https://thp.io/2008/urlwatch/
 * License : BSD-3-clause
   Section : web

It builds those binary packages:
  urlwatch   - monitors webpages for you

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/urlwatch

Alternatively, one can download the package with dget using this command:
  dget -x 
https://mentors.debian.net/debian/pool/main/u/urlwatch/urlwatch_2.16-&.dsc

More information about urlwatch can be obtained from
https://github.com/thp/urlwatch.

Changes since the last upload:

urlwatch (2.16-1) unstable; urgency=medium

  * New upstream release
  * Updated patches
  * Updated Standards-Version to 4.3.0
  * Updated package description

Regards,

Maxime Werlen

Bug#920859: libreoffice-kde5: Crash when minimizing file save dialog

[Helmar Gerloni]

Package: libreoffice-kde5
Version: 1:6.1.5~rc1-2
Severity: normal

Dear Maintainer,

LibreOffice crashes when minimizing the file save dialog. Steps to reproduce:

1. Start LibreOffice
2. File -> New -> Text Document (or other)
3. File -> Save As... - save dialog appears
4. Minimize dialog window - dialog and LibreOffice windows get minimized
5. Maximize windows again

Dialog window crashes, KDE crash pop-up menu appears "lo_kde5filepicker Closed 
Unexpectedly". LibreOffice remains blocked and can only be killed.

Always reproducable in testing & sid with version 1:6.1.5~rc1-2 and in version 
1:6.2.0~rc2-1 from experimental.

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

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

Versions of packages libreoffice-kde5 depends on:
ii  kio5.54.1-1
ii  libatk1.0-02.30.0-2
ii  libboost-filesystem1.67.0  1.67.0-12
ii  libc6  2.28-5
ii  libcairo-gobject2  1.16.0-2
ii  libcairo2  1.16.0-2
ii  libdbus-1-31.12.12-1
ii  libdbus-glib-1-2   0.110-3
ii  libepoxy0  1.5.3-0.1
ii  libgcc11:8.2.0-15
ii  libgdk-pixbuf2.0-0 2.38.0+dfsg-7
ii  libglib2.0-0   2.58.2-3
ii  libgraphite2-3 1.3.13-7
ii  libgtk-3-0 3.24.4-1
ii  libharfbuzz-icu0   2.3.0-1
ii  libharfbuzz0b  2.3.0-1
ii  libice62:1.0.9-2
ii  libkf5configcore5  5.54.0-1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5i18n55.54.0-1
ii  libkf5kiocore5 5.54.1-1
ii  libkf5kiofilewidgets5  5.54.1-1
ii  libkf5kiowidgets5  5.54.1-1
ii  libkf5windowsystem55.54.0-1
ii  libpango-1.0-0 1.42.4-6
ii  libpangocairo-1.0-01.42.4-6
ii  libqt5core5a   5.11.3+dfsg-2
ii  libqt5gui5 5.11.3+dfsg-2
ii  libqt5network5 5.11.3+dfsg-2
ii  libqt5widgets5 5.11.3+dfsg-2
ii  libqt5x11extras5   5.11.3-2
ii  libreoffice-core   1:6.1.5~rc1-2
ii  libsm6 2:1.2.2-1+b3
ii  libstdc++6 8.2.0-15
ii  libx11-6   2:1.6.7-1
ii  libxcb11.13.1-2
ii  libxext6   2:1.3.3-1+b2
ii  uno-libs3  6.1.5~rc1-2
ii  ure6.1.5~rc1-2

Versions of packages libreoffice-kde5 recommends:
ii  libreoffice-style-breeze  1:6.1.5~rc1-2

libreoffice-kde5 suggests no packages.

-- no debconf information

Bug#814089: Please call fdatasync on the target file before removing the source file

[Sebastian Andrzej Siewior]

On 2016-02-08 13:42:47 [+0100], Enrico Zini wrote:
> Hello,
Hi,

> I was archiving and xz-compressing mail from last year when my laptop
> tripped thermal protection and switched off. The resulting filesystem
> situation is this:
…
> The source files are gone, and the target files are empty.
> 
> I have not checked xz's sources, but this looks like the result of a
> missing fdatasync on the target file before the source has been removed.

First all, I'm sorry for your loss. I've been looking at this a few
years ago and then somehow forgot about it. Now I kinda remembered.
I *think* the problem (was/is) that
write()
close()
unlink()
ended up with commited metadata but not data so you see the file but
data did not hit the disk (completely). That probably was the time
before ext4 changed its default behaviour with a few hacks once user
reported that KDE lost all its configurations files because there were
rewritten at boot time.

A fdatasync() would probably avoid that[0]. Should we really try to do
that? If so, we should also go after gzip, bzip2, … and make the change
there, too. They don't do that (behave like xz does) but I think if we
make such a change we should behave consistenly across those tools.

In theory we might have worse performance due to that sync but this
shouldn't hit most users. I think most ppl use xz via a pipe (say 
`tar J') so they won't be affected by that sync. We probably could also
avoid that sync together with the `--keep' option. And then we would be
able to catch errors before close() and unlink of the original.

[0] I would check if linux's fs ppl if we really consider it.

> Enrico

Sebastian

Bug#591781: texlive-base: texdoc barfs on gzipped files under gnome

[Hilmar Preuße]

On 05.08.10 16:41, Julian Gilbey wrote:

Hi Julian,

This seems to be similar to #601237. Is the issue still present?

Hilmar

> Running  texdoc pgf  opens an evince window, but evince complains that
> there is No such file or directory.
> 
> I have tracked down the problem: view.tlu runs the command (split over
> two lines; the Xb... is of course a unique directory name):
> 
> (gnome-open "/tmp/texdoc.Xbpoq3/pgfmanual.pdf"; rm -f
> "/tmp/texdoc.Xbpoq3/pgfmanual.pdf"; rmdir /tmp/texdoc.Xbpoq3) &
> 
> What happens is that gnome-open is called, but gnome-open disconnects
> from the running process very quickly, so that by the time evince
> fires up, the file and directory have already been deleted.
> 
> I am unsure what the correct solution would be.  I think that the
> simplest might be to have a "wait" command after the file opening
> command; the presence of the backgrounding process should alleviate
> problems this causes.
> 


-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#920856: notmuch-emacs: muttprint/evince fails to show "print"

[Joerg Jaspert]

On 15297 March 1977, Joerg Jaspert wrote:

Looking at the file, it has nice rights so i am allowed to open it. file
on it reports it as postscript. But silly evince hates it. mv to the
rescue: Put a ".ps" at the end and boo, evince opens it all fine.



Guess you want to adjust the tempfile name...


And here is a simple diff that makes it work. I guess the other print
methods may need it too.

--- /usr/share/emacs/site-lisp/elpa-src/notmuch-0.28/notmuch-print.el 
   2018-10-20 19:25:09.0 +0200

+++ notmuch-print.el2019-01-29 22:03:40.098623179 +0100
@@ -82,7 +82,7 @@

(defun notmuch-print-muttprint/evince (msg)
  "Preview a message buffer using muttprint and evince."
-  (let ((ps-file (make-temp-file "notmuch")))
+  (let ((ps-file (make-temp-file "notmuch" nil ".ps")))
(notmuch-print-run-muttprint (list "--printer" (concat "TO_FILE:" 
ps-file)))

(notmuch-print-run-evince ps-file)))

--
bye, Joerg

Bug#920858: twitter-bootstrap4: contains generated code not included as source

[Jonas Smedegaard]

Source: twitter-bootstrap4
Version: 4.2.1+dfsg1-1
Severity: serious
Justification: Policy 2.1

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Source package contains below  several files embedding code from
external project fileOverview Kickass, without source included.

Thanks to Xavier for noticing (although only as comment in copyright
file).


 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlxQws0ACgkQLHwxRsGg
ASHW+A//ZeD9o9J69NnfOMBYLDRmX7LLSFrzcBpN9UUjIpjL0gcUuvzYBBVftXea
LQKrAYwspymsSOaA9yUImVB3U812zsuZOLcB7wXOJcuMAEIRs1NM8+vkQM0n28Sp
xu1WmADBmUKOoWpwstlwYwiTAr2T82Fb1zUSDgiw/zUiOZnVZZIGBN6ei9HJBKpx
QwICTAuIVO1vovpGnrFNas4kbi0xvEQOUW5tFxo28R9gXSukEOEJWrU6EXjD4njb
xc8mxH49774VL8lmKpo/vA+aWQ29xrw4uMT1uuSIY/0LP6nU/cpYh5OBSbSrDZxo
BqLMpZIfx+sVhomP/sbCalKGJ8fsyl2bNn+nGXioXp5gTG1CUrDtHc8TT/3EI7z+
YN2tL5hnMeUvsI+sxeY0/SXB0Q5vHHPrR2FOmULdFVf52yAVivTjvyzrwOkAnTeR
RTi+K866ayM9A6bkV3n5yVaOqa9DO/WIa20LApRCZ7QDz5IpkBNKvcz92ZlaZzpG
iTy7pdxop+ynjp2bme493gdW4pxzuOw7M0OhK2h+8VX7gD9Yr9GcCozJoccHp28T
SMTS6L4NgOEWAPWYicxWwYdRRAmE90PZx7QrJWmCna0OlZJIHhv70rfxGNIHdxkK
j6uzLVcMq4X12klIh5BQlIXkGYMFJdn07Gi7AdO6KTT80Vyv8BM=
=7bXE
-END PGP SIGNATURE-

Bug#920853: binaryen: CVE-2019-7151 CVE-2019-7152 CVE-2019-7153 CVE-2019-7154

[Markus Koschany]

Control: tags -1 pending

Hi!

Am 29.01.19 um 21:40 schrieb Salvatore Bonaccorso:
> Source: binaryen
> Version: 64-1
> Severity: important
> Tags: security upstream
> 
> Hi,
> 
> The following vulnerabilities were published for binaryen.
> 
> I was initially confused about the intersting versioning scheme, but
> the issues are present in 64-1 and I think all of those fixed in 65
> upstream (but please double-check the referenced upstream issues and
> fixing commits as commited by upstream).

[...]

I always love it when packages are affected by security issues that I
merely need to compile stuff from source.

Indeed the versioning scheme is slightly confusing. Apparently the float
number 1.38.x is in sync with Emscripten releases. The integer version
is the "standalone" version of binaryen, at least that's what I think.
Since Emscripten in Debian is pretty much broken and I don't want to be
bound to the further packaging of it, I have chosen to use the integer
version.

To me it looks like everything was fixed in 65, a couple of minutes ago
66 was released, which I am going to upload now.

Cheers,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#601237: texlive-base: texdoc fails to open gzip'ed pdf files like pgfmanual.pdf.gz

[Norbert Preining]

On Tue, 29 Jan 2019, Hilmar Preuße wrote:
> I suggest to simply close that bug. What do you think?

Fine with me!

Thanks a lot!

Norbert

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

Bug#532093: AleVT in dvb-apps

[Göran Weinholt]

Hello VDR Team,

I've been eyeing the orphaned alevt package for a while and decided to
adopt it. However, some quick investigation showed that it has been
abandoned upstream, forked and is now part of dvb-apps. I've tested
alevt in dvb-apps and it works.

>From what I can tell, there is no point in keeping the alevt package.
I would suggest removing it. What do you think?

Regards,

-- 
Göran Weinholt
Debian Developer
https://weinholt.se/

Bug#920856: notmuch-emacs: muttprint/evince fails to show "print"

[Joerg Jaspert]

Package: notmuch-emacs
Version: 0.28-2~bpo9+1
Severity: normal

Dear Maintainer,

(setq notmuch-print-mechanism 'notmuch-print-muttprint/evince)

and then pressing # while having a mail displayed leads to an evince
that displays a plenty unhelpful message about not being allowed to open
the file file:///tmp/dir/notmuch$RANDOM

Looking at the file, it has nice rights so i am allowed to open it. file
on it reports it as postscript. But silly evince hates it. mv to the
rescue: Put a ".ps" at the end and boo, evince opens it all fine.

Guess you want to adjust the tempfile name...

--
bye, Joerg

Bug#920857: ITP: scoary -- pangenome-wide association studies

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: scoary
  Version : 1.6.16
  Upstream Author : Ola Brynildsrud 
* URL : https://github.com/AdmiralenOla/Scoary
* License : GPL-3.0
  Programming Lang: Python
  Description : pangenome-wide association studies
 Scoary is designed to take the gene_presence_absence.csv file from
 Roary as well as a traits file created by the user and calculate the
 associations between all genes in the accessory genome and the traits. It
 reports a list of genes sorted by strength of association per trait.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/scoary

Bug#920791: New libglm-dev

[Guus Sliepen]

retitle 920791 FTBFS on all non-SIMD architectures
forwarded 920791 https://github.com/g-truc/glm/issues/865
thanks

On Tue, Jan 29, 2019 at 07:50:44AM +0100, Guus Sliepen wrote:

> I cannot reproduce it either, but according to the logs it looks like it
> might be some #defines not working properly on some architectures.

The issue is that the new version of GLM conditionally adds constexpr to
some member functions where that would cause a compiler error. It so
happens that constexpr is not used on any architecture with SIMD
instructions supported by GLM, which are amd64 and arm64 as far as I can
tell.

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


signature.asc
Description: PGP signature

Bug#920846: syslog-ng-mod-examples: Package short description mentions another plugin

[Peter Kokai]

Hello,

Thanks for reporting, I just opened a counterpart issue in github to
speed up its correction :)

--
Kokan


On Tue, Jan 29, 2019 at 08:58:47PM +0100, Beatrice Torracca wrote:
> Package: syslog-ng-mod-examples
> Severity: minor
> 
> Hi!
> 
> the package short description now reads "Enhanced system logging
> daemon (map-value-pairs plugin)" which is already the description of
> the syslog-ng-mod-map-value-pairs package, while this is the examples
> package.
> 
> Thanks,
> 
> beatrice
> 


signature.asc
Description: PGP signature

Bug#919929: blis breaks python-scipy autopkgtest

[Paul Gevers]

reassing 919929 src:python-scipy 1.1.0-2
retitle 919929 python-scipy: autopkgtest fails intermittently
user debian...@lists.debian.org
usertags 919929 - breaks needs-update
usertags 919929 flaky
severity 919929 important
thanks

Hi Graham, Julian,

On 29-01-2019 18:59, Julian Taylor wrote:
> On 29.01.19 12:01, Graham Inggs wrote:
>> On 2019/01/20 21:09, Paul Gevers wrote:
>> From testing's test logs [1], python-scipy 1.1.0-2 passed with
>> blis/0.5.1-5 on 2019-01-21 05:22:48 UTC.  It then passed with
>> blis/0.5.1-6 and blis/0.5.1-7, but failed with blis/0.5.1-7 on
>> 2019-01-27 17:55:32 UTC.
>>
>> From unstable's test logs [2], python-scipy 1.1.0-2 seems to have many
>> intermittent failures since 2018-12-02.

That is what we call flaky behavior.

>> I'm unsure what to do with this bug, perhaps re-assign to python-scipy
>> only?

Done so.

> I am confused, scipy does not use blis.

Indeed, and in the failing log one can search for "blis" and not find it
at all, except for the call to autopkgtest. So the failure can't be
caused by blis.

> It tests libblas, openblas and atlas but blis was so far I know never
> configured as a blas source in the tests.
> Unless something has changed with those packages that they pull blis
> this might be a false positive.

Yes it is. Julian, can you please investigate the failing log files and
please make the tests robust against whatever goes wrong. If you really
can't fix it and still want the tests to run, consider adding the
"flaky" restriction to the tests that intermittently fail.

> If blis is ready enough to be used prime time, let me know we can add it
> to numpy's and scipy's testsuites.

No idea, and no opinion about that.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#920776: sparse: new upstream release

[Jonathan Nieder]

Hi Uwe,

Uwe Kleine-König wrote:
> On 1/29/19 2:38 AM, Jonathan Nieder wrote:

>> Thoughts of all kinds welcome, as always.  If you'd prefer this in the
>> form of a "git pull"-able repository, a push to salsa, or an NMU, just
>> ask.
>
> I didn't follow sparse development in the nearer past. Is there a
> problem with sparse 0.5.2 that would be fixed by going to 0.6.0?
>
> My thought was not to touch it for buster and go to 0.6.0 only afterwards.

Cc-ing Ramsay Jones and Luc to find out.  In [1] I find

| [I was a little surprised that Linux Mint 19.1 (based on Ubuntu
| 18.04) has v0.5.1 - Debian unstable has v0.5.2, but both of those
| are just a little too old for use with git on recent Linux.]

but I wasn't able to reproduce a problem with v0.5.2 analyzing git.git
myself.  That said, v0.6.0 has been working well for me, so I suspect
upgrading is not too risky.

One example improvement is

commit fdf8252f312a40df9aa51c6e30c0d07fa29ebd12
Author: Ramsay Jones 
Date:   Sun Nov 18 23:52:23 2018 +

constant: add -Wconstant-suffix warning

Currently, when used on the kernel, sparse issues a bunch
of warnings like:
warning: constant 0x1 is so big it is long

These warning are issued when there is a discrepancy
between the type as indicated by the suffix (or the absence
of a suffix) and the real type as selected by the type
suffix *and* the value of the constant.

Since there is nothing incorrect with this discrepancy,
(no bits are lost) these warnings are more annoying than useful.
So, make them depending on a new warning flag -Wconstant-suffix
and make it off by default.

I'd be happy to keep an eye on reports through the PTS and help with
any followups for the new release.

Thanks,
Jonathan

[1] 
https://public-inbox.org/git/a6b689da-b002-0aa2-e9d6-755d004bc...@ramsayjones.plus.com/

Bug#920607: Debian Buster installer on qnap ts-21x / Fujitsu Q700 : /dev/mtdblock* missing

[Uwe Kleine-König]

On 1/27/19 12:13 PM, Lukas Straub wrote:
> Package: linux
> Version: 4.19.12-1
> 
> Hello Everyone,
> I tried the latest Buster Installer on my Fujitsu Q700 (rebranded
> qnap ts-21x) and Everything works except that /dev/mtdblock* devices
> are missing so flashing the kernel and initrd fails.

I see the spi-orion-Driver is not loaded. Does /dev/mtd* appear if you do

modprobe spi-orion
modprobe m25p80

? If not, can you please provide the output of

ls /sys/bus/{platform,spi}/{devices,drivers}

?

BTW: flash-kernel shouldn't need mtdblock* but only mtd*.

Best regards
Uwe



signature.asc
Description: OpenPGP digital signature

Bug#920855: mariadb-10.1: FTBFS on mips{,{,64}el}: linker failures

[Julien Cristau]

Source: mariadb-10.1
Version: 10.1.37-0+deb9u1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Control: affects -1 + release.debian.org security.debian.org

Hi,

The mariadb-10.1 on security.debian.org fails to build on all mipsen, with 
similar errors:

> [ 99%] Linking CXX executable explain_filename-t
> cd /<>/builddir/unittest/sql && /usr/bin/cmake -E 
> cmake_link_script CMakeFiles/explain_filename-t.dir/link.txt --verbose=1
> /usr/bin/mips-linux-gnu-g++   -g -O2 -fdebug-prefix-map=/<>=. 
> -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat 
> -Werror=format-security -pie -fPIC -Wl,-z,relro,-z,now -fstack-protector 
> --param=ssp-buffer-size=4 -DWITH_INNODB_DISALLOW_WRITES -fno-exceptions 
> -fno-rtti -O3 -g -static-libgcc -fno-omit-frame-pointer -fno-strict-aliasing 
> -Wno-uninitialized -D_FORTIFY_SOURCE=2 -DDBUG_OFF  
> -specs=/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now 
> CMakeFiles/explain_filename-t.dir/explain_filename-t.cc.o  -o 
> explain_filename-t  -lpthread ../../sql/libsql.a ../mytap/libmytap.a 
> ../../storage/csv/libcsv.a ../../storage/heap/libheap.a 
> ../../storage/maria/libaria.a ../../storage/myisam/libmyisam.a 
> ../../storage/myisammrg/libmyisammrg.a 
> ../../storage/perfschema/libperfschema.a ../../storage/sequence/libsequence.a 
> ../../storage/xtradb/libxtradb.a -laio 
> ../../plugin/auth_socket/libauth_socket.a ../../plugin/feedback/libfeedback.a 
> ../../plugin/userstat/libuserstat.a ../../sql/libpartition.a 
> ../../mysys/libmysys.a ../../mysys_ssl/libmysys_ssl.a ../../dbug/libdbug.a 
> ../../mysys/libmysys.a ../../mysys_ssl/libmysys_ssl.a ../../dbug/libdbug.a 
> -lz -lm ../../extra/yassl/libyassl.a ../../extra/yassl/taocrypt/libtaocrypt.a 
> ../../strings/libstrings.a ../../vio/libvio.a ../../pcre/libpcre.a -lcrypt 
> -ldl ../../wsrep/libwsrep.a -lsystemd -latomic -lpthread 
> /usr/bin/ld: ../../mysys/libmysys.a(stacktrace.c.o): undefined reference to 
> symbol '__bss_start'
> //lib/mips-linux-gnu/libselinux.so.1: error adding symbols: DSO missing from 
> command line
> collect2: error: ld returned 1 exit status

Cheers,
Julien

Bug#920854: mariadb-10.1: FTBFS on s390x (test failure)

[Julien Cristau]

Source: mariadb-10.1
Version: 10.1.37-0+deb9u1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
Control: affects -1 + release.debian.org security.debian.org

The mariadb-10.1 package on security.d.o doesn't build on s390x, one test fails:

> CURRENT_TEST: unit.pcre_test
> 
> PCRE C library tests using test data from /<>/pcre/testdata
> PCRE version 8.42 2018-03-20
> 
>  Testing 8-bit library 
> 
> Test 1: Main functionality (Compatible with Perl >= 5.10)
>   OK
>   OK with study
> Test 2: API, errors, internals, and non-Perl stuff (not UTF-8)
> Segmentation fault
>  
> ** Test 2 requires a lot of stack. If it has crashed with a
> ** segmentation fault, it may be that you do not have enough
> ** stack available by default. Please see the 'pcrestack' man
> ** page for a discussion of PCRE's stack usage.
> 
>  - saving '/<>/builddir/mysql-test/var/1/log/unit.pcre_test/' to 
> '/<>/builddir/mysql-test/var/log/unit.pcre_test/'
> 
> Retrying test unit.pcre_test, attempt(2/3)...
> 
> unit.pcre_test   w1 [ retry-fail ]
> Test ended at 2018-11-15 12:08:22
> 
> CURRENT_TEST: unit.pcre_test
> 
> PCRE C library tests using test data from /<>/pcre/testdata
> PCRE version 8.42 2018-03-20
> 
>  Testing 8-bit library 
> 
> Test 1: Main functionality (Compatible with Perl >= 5.10)
>   OK
>   OK with study
> Test 2: API, errors, internals, and non-Perl stuff (not UTF-8)
> Segmentation fault
>  
> ** Test 2 requires a lot of stack. If it has crashed with a
> ** segmentation fault, it may be that you do not have enough
> ** stack available by default. Please see the 'pcrestack' man
> ** page for a discussion of PCRE's stack usage.
> 
>  - saving '/<>/builddir/mysql-test/var/1/log/unit.pcre_test/' to 
> '/<>/builddir/mysql-test/var/log/unit.pcre_test/'
> 
> Test unit.pcre_test has failed 2 times, no more retries!

Apparently such failures are somehow expected, can we disable that test if not
fix it?

Cheers,
Julien

Bug#920284: debian-installer: Installing Debain 9.6 on amd64 KVM via netinst fails in "select and install software"

[Zachary Palmer]

Cyril,

Thanks for the response!  I was able to consistently reproduce the 
problem I described as of January 23rd.  As of today, a clean 
installation of Debian 9.6 on my VM worked without difficulty. Looking 
at the error message, it would seem that the hash that apt was using for 
something in security-cdb.debian.org didn't match what I downloaded.


In fact, I just finished the install and got a similar message by 
running "sudo apt-get install lxde" on the terminal:


    Err:4 http://security-cdn.debian.org/debian-security 
stretch/updates/main amd64 libqt5gui5 amd64 5.7.1+fsg-3+deb9u1

  Hash Sum mismatch
  Hashes of expected file:
   - 
SHA256:aa740aa9fada96791cd254a26afbebca52267a14b072c33f93ada1e3791c8aec

   - SHA1:2b50202d9bb2ee257027035498b9f826fc2202fe [weak]
   - MD5Sum:7be38aee5f595e7ebd95b0f77bf60580 [weak]
   - Filesize:2449840 [weak]
  Hashes of received file:
   - 
SHA256:0611d7b8e5113bdc7257aa38f8500e2b78ff9fd91a6555114a482a101b7db835

   - SHA1:07861e147f8df4e45336d17381731d6d95e5801c [weak]
   - MD5Sum:f45d307aea95e1ccacb6e7c13a32b33e [weak]
   - Filesize:43776 [weak]
  Last modification reported: Thu, 06 Dec 2018 18:05:06 +

This occurred immediately upon running "sudo apt-get install lxde"; 
there was no visible timeout.  That said, while the expected file size 
seems sensible (https://packages.debian.org/stretch/libqt5gui5 seems to 
indicate that the file should be ~2392.4kb), the received filesize is 
ridiculously small.  It's possible, if no else else can reproduce this 
problem, that it may be the result of an errant proxy or similar 
interference on my network: something that's essentially truncating the 
file.  If that's true, though, shouldn't apt-get be producing a 
corresponding error message (e.g. "download failed due to interrupted 
connection") rather than assuming that the download is complete?  That 
is, if the HTTP request gets a response with the file size in the 
header, apt should be able to tell if it successfully downloaded the 
whole thing, right?


The problem itself seems to be less reproducible than it was several 
days ago: simply re-running the "apt-get" command on the installed 
system seems to have solved it for now (while, on January 23rd, I was 
unable to get past the "Select and Install Software" step in the 
installer).  This seems like more of a bug with how apt-get handles 
failure.  Is there a way to reassign this bug to that package?


Thanks,

Zach

Control: tag -1 - d-i


Hi Zachary,

And thanks for your report.

Zachary Palmer  (2019-01-23):

I am installing Debian 9.6 using a netinst image on an amd64 virtual
machine (kvm).  Everything runs as expected until the "Select and
Install Software" step, which fails with the generic message
"Installation step failed".  Terminal
4 shows some interesting output:

     Failed to fetch 
http://security-cdn.debian.org/debian-security/pool/updates/main/o/openssl/libssl1.1_1.1.0j-1~deb9u1_amd64.deb
Writing more data than expected (1235886 > 1231594)

     Hashes of expected file:

  - SHA256:dddf4ff686845b82c6c778a70f1f607d0bb9f8aa43f2fb7983db4ff1a55f5fae

  - SHA1:5d754764288ae1751d7a05d11c801cde71456602 [weak]

  - MD5Sum:5e3b6c66100964833307d3a943918275  [weak]

     E
     :
     Unable to fetch some archives, maybe run apt-get update or try with
--fix-issing?

I don't think that this is the only file it failed to fetch, as I see
the tail of a similar message further up in the terminal.  (I wasn't
able to scroll to see it.)

Please hit “reply all”, attaching /var/log/installer/syslog (compressed,
to make sure it doesn't get rejected due to size on mailing lists), so
that we have a look at the whole log.


Cheers,

Bug#611408: texi2dvi: swallow error messages

[Hilmar Preuße]

On 29.01.11 00:41, Jakub Wilk wrote:

Hi Jakub,

> This part of /usr/bin/texi2dvi
> 
>     if test $? != 0; then
>   cat "$version_test_dir/txiversion.out"
>   cat "$version_test_dir/txiversion.err" >&2
>   error 1 "texinfo.tex appears to be broken, quitting."
>     fi
> 
> is dead code. The whole script is run under "set -e", so if $TEX fails,
> the script will be termined with no error message shown.
> 
I reviewed the issue. W/ current texinfo I tried to provoke some errors.

1. Renamed the TeX compiler to make sure it is not found any more:

hille@sid:~ $ texi2dvi latex2man.texi
You don't have a working TeX binary (tex) installed anywhere in
your PATH, and texi2dvi cannot proceed without one.  If you want to use
this script, you'll need to install TeX (if you don't have it) or change
your PATH or TEX environment variable (if you do).  See the --help
output for more details.

For information about obtaining TeX, please see http://tug.org/texlive,
or do a web search for TeX and your operating system or distro.

On Debian you can install a working TeX system with
  apt-get install texlive

2. Issued a broken texi file:

Loading texinfo [version 2018-01-09.11]: pdf, fonts, markup, glyphs,
page headings, tables, conditionals, indexing, sectioning, toc,
environments,
defuns, macros, cross references, insertions,
(/usr/share/texlive/texmf-dist/tex/generic/epsf/epsf.tex
This is `epsf.tex' v2.7.4 <14 February 2011>
) localization, formatting, and turning on texinfo input format.) [1]
(latex2man) (/home/hille/latex2man.aux)
Runaway argument?
{CSSfile as an argument. CSS (Cascading Style Sheets) allows you to c@ETC.
./latex2man.texi:91: Paragraph ended before @var was complete.

   @par
l.91

? s
OK, entering @scrollmode...
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12]
Underfull \hbox (badness 1) in paragraph at lines 958--960
 @textrm a sub-sub-sec-tion ti-tle

Underfull \hbox (badness 1) in paragraph at lines 958--960
 @textrm to the @textit sub-sub-sec-tion
[13] [14] [15] [16] [17] )
(see the transcript file for additional information)
Output written on latex2man.dvi (18 pages, 33676 bytes).
Transcript written on latex2man.log.
/usr/bin/texi2dvi: etex exited with bad status, quitting.

What else kind of error situations need to be handled in your opinion?

Thanks,
  Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#919802: libjstun-java: FTBFS (The code being documented uses packages in the unnamed module)

[Gilles Filippini]

Hi,

Gilles Filippini a écrit le 21/01/2019 à 16:58 :
> Hi,
> 
> On Sun, 20 Jan 2019 13:28:57 +0800 "Ying-Chun Liu (PaulLiu)"
>  wrote:
>> Santiago Vila 於 2019/1/20 上午1:35 寫道:
>>> Package: src:libjstun-java
>>> Version: 0.7.3+dfsg-1
>>> Severity: serious
>>> Tags: ftbfs
>>>
>>> Dear maintainer:
>>>
>>> I tried to build this package in buster but it failed:
>>>
>>> 
>>> [...]
>>>  debian/rules build-indep
>>> dh build-indep --with javahelper
>>>dh_update_autotools_config -i
>>>jh_linkjars -i
>>>jh_build -i
>>> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
>>> /usr/lib/jvm/default-java/bin/javac -g -cp 
>>> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
>>>  -d debian/_jh_build.libjstun-java -source 1.7 -target 1.7 -encoding 
>>> ISO8859-1
>>> warning: [options] bootstrap class path not set in conjunction with -source 
>>> 7
>>> Note: src/de/javawi/jstun/test/demo/ice/ICENegociator.java uses unchecked 
>>> or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> 1 warning
>>> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0 
>>> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link 
>>> /usr/share/doc/default-jdk-doc/api -link 
>>> /usr/share/doc/default-jre-headless/api -classpath 
>>> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
>>>  -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp 
>>> -source 1.7
>>> Creating destination directory: "debian/_jh_build.javadoc/api/"
>>> javadoc: error - The code being documented uses packages in the unnamed 
>>> module, but the packages defined in /usr/share/doc/default-jdk-doc/api/ are 
>>> in named modules.
>>> javadoc: error - The code being documented uses packages in the unnamed 
>>> module, but the packages defined in 
>>> /usr/share/doc/default-jre-headless/api/ are in named modules.
>>> 2 errors
>>> make: *** [debian/rules:11: build-indep] Error 123
>>> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
>>> status 2
>>> 
>>>
>>> (The above is just how the builds ends and not necessarily the most 
>>> relevant part)
>>>
>>> The build was made in my autobuilder with "dpkg-buildpackage -A"
>>> and it also fails here:
>>>
>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libjstun-java.html
>>>
>>> where you can get a full build log if you need it.
>>>
>>> If this is really a bug in one of the build-depends, please use reassign 
>>> and affects,
>>> so that this is still visible in the BTS web page for this package.
>>>
>>> Thanks.
>>>
>>
>> Hi Santiago,
>>
>> It seems to me that this line causes the problem.
>> find src/de -name *.java -and -type f -print0 | xargs -s 512000 -0
>> /usr/lib/jvm/default-java/bin/javadoc -locale en_US -link
>> /usr/share/doc/default-jdk-doc/api -link
>> /usr/share/doc/default-jre-headless/api -classpath
>> /usr/share/java/slf4j-jdk14.jar:/usr/share/java/slf4j-api.jar:/usr/share/java/junit.jar:debian/_jh_build.libjstun-java
>> -d debian/_jh_build.javadoc/api -quiet -encoding ISO8859-1 -notimestamp
>> -source 1.7
>>
>> But if remove "-link /usr/share/doc/default-jdk-doc/api -link
>> /usr/share/doc/default-jre-headless/api", then it will pass.
>>
>> I'm wondering if javahelper needs to call javadoc in different way.
> 
> I've got the very same result for #919803 affecting src:mac-widgets.

Looking at the jh_build code, the list of -link javadoc options is constructed 
from this snippet:
   CLASSPATHDOCS="`for i in $(grep-dctrl --no-field-names --show-field 
Build-Depends,Build-Depends-Indep -F source "$pkg" debian/control | tr , ' ' | 
sed 's/([^)]*)//g') ; do dpkg -L $i 2>/dev/null | grep /usr/share/doc/.*/api$; 
done | sed 's/^/-link /' | xargs`"

Then dropping default-jdk-doc from Build-Depends did the trick!

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#920853: binaryen: CVE-2019-7151 CVE-2019-7152 CVE-2019-7153 CVE-2019-7154

[Salvatore Bonaccorso]

Source: binaryen
Version: 64-1
Severity: important
Tags: security upstream

Hi,

The following vulnerabilities were published for binaryen.

I was initially confused about the intersting versioning scheme, but
the issues are present in 64-1 and I think all of those fixed in 65
upstream (but please double-check the referenced upstream issues and
fixing commits as commited by upstream).

CVE-2019-7151[0]:
| A NULL pointer dereference was discovered in
| wasm::Module::getFunctionOrNull in wasm/wasm.cpp in Binaryen 1.38.22. A
| crafted input can cause segmentation faults, leading to
| denial-of-service, as demonstrated by wasm-opt.

CVE-2019-7152[1]:
| A heap-based buffer over-read was discovered in
| wasm::WasmBinaryBuilder::processFunctions() in wasm/wasm-binary.cpp
| (when calling wasm::WasmBinaryBuilder::getFunctionIndexName) in
| Binaryen 1.38.22. A crafted input can cause segmentation faults,
| leading to denial-of-service, as demonstrated by wasm-opt.

CVE-2019-7153[2]:
| A NULL pointer dereference was discovered in
| wasm::WasmBinaryBuilder::processFunctions() in wasm/wasm-binary.cpp
| (when calling wasm::WasmBinaryBuilder::getFunctionIndexName) in
| Binaryen 1.38.22. A crafted input can cause segmentation faults,
| leading to denial-of-service, as demonstrated by wasm-opt.

CVE-2019-7154[3]:
| The main function in tools/wasm2js.cpp in Binaryen 1.38.22 has a
| heap-based buffer overflow because Emscripten is misused, triggering an
| error in cashew::JSPrinter::printAst() in
| emscripten-optimizer/simple_ast.h. A crafted input can cause
| segmentation faults, leading to denial-of-service, as demonstrated by
| wasm2js.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-7151
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7151
[1] https://security-tracker.debian.org/tracker/CVE-2019-7152
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7152
[2] https://security-tracker.debian.org/tracker/CVE-2019-7153
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7153
[3] https://security-tracker.debian.org/tracker/CVE-2019-7154
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-7154

Regards,
Salvatore

Bug#920852: ...slightly odd choice of shell syntax in patch

[Chris West]

Package: binstats
Version: 1.08-8.2
Severity: normal

The patch for binstats adds this line to binstats. It ends up in the
resulting package It.. I.. I'm not sure what it is doing.

   if [ $USEMANPATH -eq 1 -a -n "^Type -p manpath" ];then

That's not a ^ and a T. That's an actual ctrl+t, ascii 0x14.

Even if it read [ -n "type -p manpath" ], that would always be true?

I noticed, as file(1)-like tools declare the patch and binstats as a
binary file, due to the presence of this non-printable junk.

Please remove it, and/or change the shell to do something meaningful?

Cheers,
Chris.

Bug#920851: gyp: OS variable on non-Linux systems

[Коля Гурьев]

Package: gyp
Version: 0.1+20180428git4d467626-2
Severity: minor

I have a simple test consisting of two files (see attachments). As you
can see, it sets the GYP_OS_VAL macro equal to the value of the OS
predefined variable, and the main.cpp file prints this value to stdout.
In that way I examined the initial value of the OS variable set by gyp.
But I am puzzled by the results on kFreeBSD, the Debian port, and on
GNU/Hurd. The variable contains a string "linux". Which I think is not
quite correct as these systems have no connection with the Linux kernel
and sometimes require special handling.

Below I am showing what I have gotten on kFreeBSD.

$ uname -a
GNU/kFreeBSD nola 9.0-2-686 #0 Sun May 17 22:06:56 UTC 2015 i386 i386 
Intel(R) Core(TM) i3-6006U CPU @ 2.00GHz GNU/kFreeBSD
$ gyp --no-parallel --depth .
$ make
CC(target) out/Default/obj.target/ttt/main.o
LINK(target) out/Default/ttt
$ out/Default/ttt
GYP_OS_VAL=linux

And here is what happened on GNU/Hurd.

$ uname -a
GNU debian 0.9 GNU-Mach 1.8+git20190109-486/Hurd-0.9 i686-AT386 GNU
$ gyp --no-parallel --depth .
$ make
CC(target) out/Default/obj.target/ttt/main.o
LINK(target) out/Default/ttt
$ out/Default/ttt
GYP_OS_VAL=linux

Please provide a built-in mechanism to distinguish Linux as target
system from kFreeBSD or GNU/Hurd.
#include 
int main()
{
  printf("GYP_OS_VAL=%s\n", GYP_OS_VAL);
  return 0;
}
{
  'targets': [
{
  'target_name': 'ttt',
  'type': 'executable',
  'defines': [
'GYP_OS_VAL="<(OS)"',
  ],
  'sources': [
'main.c',
  ],
},
  ],
}

Bug#600733: Examples from the documentation do not run

[Hilmar Preuße]

On 19.10.10 18:05, Toomas Tamm wrote:

Hi Toomas,

http://bugs.debian.org/600733 . Old bug, I know.

> An attempt to run the examples from the tutorial:
> http://www.xindy.org/doc/tutorial-2.html
> 
> eg the command:
> $ xindy -l ex1.xlg style1.xdy ex1.raw
> results in the error message:
> 
> Unknown option: l
> 
> usage: xindy [-V?h] [-qv] [-d magic] [-o outfile.ind] [-t log] \
> [-L lang] [-C codepage] [-M module] [-I input] \
> [--interactive] [--mem-file xindy.mem] \
> [idx0 idx1 ...]
> 
> [rest of message truncated for brevity of bug report - TT ]
> 
The examples are still broken on the xindy web page (project seems to be
rather dead). But the samples in the documentation delivered w/ Debian
are fixed. I tend to close the issue.

Do you agree here?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#920850: vym FTCBFS: missing Build-Depends: qt5-qmake:native

[Helmut Grohne]

Source: vym
Version: 2.6.11-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

vym fails to cross build from source, because running lrelease fails.
lrelease only works when qt5-qmake:native is added to Build-Depends.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru vym-2.6.11/debian/changelog vym-2.6.11/debian/changelog
--- vym-2.6.11/debian/changelog 2018-04-30 09:55:34.0 +0200
+++ vym-2.6.11/debian/changelog 2019-01-29 14:19:50.0 +0100
@@ -1,3 +1,11 @@
+vym (2.6.11-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add missing Build-Depends: qt5-qmake:native for using lrelease.
+(Closes: #-1)
+
+ -- Helmut Grohne   Tue, 29 Jan 2019 14:19:50 +0100
+
 vym (2.6.11-2) unstable; urgency=medium
 
   * Add missing translation files
diff --minimal -Nru vym-2.6.11/debian/control vym-2.6.11/debian/control
--- vym-2.6.11/debian/control   2018-04-29 13:49:15.0 +0200
+++ vym-2.6.11/debian/control   2019-01-29 14:19:48.0 +0100
@@ -9,6 +9,7 @@
 qttools5-dev-tools,
 libqt5svg5-dev,
 patchutils,
+qt5-qmake:native,
 quilt
 Standards-Version: 4.1.4
 Homepage: http://www.insilmaril.de/vym/

Bug#920849: libsbml5-dev: broken symlink: /usr/lib/libsbml.so -> libsbml.so.5

[Andreas Beckmann]

Package: libsbml5-dev
Version: 5.17.2+dfsg-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package ships (or creates)
a broken symlink.

>From the attached log (scroll to the bottom...):

0m27.4s ERROR: FAIL: Broken symlinks:
  /usr/lib/libsbml.so -> libsbml.so.5 (libsbml5-dev)


Has the package been multiarchified recently?


cheers,

Andreas


libsbml5-dev_5.17.2+dfsg-2.log.gz
Description: application/gzip

Bug#920848: dump1090-mutability: no HTTP interface when using --net

[Yves-Alexis Perez]

Package: dump1090-mutability
Version: 1.15~20180310.4a16df3+dfsg-6
Severity: normal

Hi,

I just tried the Debian package for dump1090-mutability, and it seems
that the HTTP interface doesn't work.

When running with --net and looking at netstat output, I get:

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
User   Inode  PID/Program name
tcp0  0 0.0.0.0:30001   0.0.0.0:*   LISTEN  
1000   707959612528/dump1090-muta 
tcp0  0 0.0.0.0:30002   0.0.0.0:*   LISTEN  
1000   707958412528/dump1090-muta 
tcp0  0 0.0.0.0:30003   0.0.0.0:*   LISTEN  
1000   707959212528/dump1090-muta 
tcp0  0 0.0.0.0:30004   0.0.0.0:*   LISTEN  
1000   707960012528/dump1090-muta 
tcp0  0 0.0.0.0:30005   0.0.0.0:*   LISTEN  
1000   707958812528/dump1090-muta 
tcp0  0 0.0.0.0:30104   0.0.0.0:*   LISTEN  
1000   707960412528/dump1090-muta 

but nothing on port 8080. Trying with --net-http-port I get a warning:

dump1090-mutability --net --quiet --net-http-port 8080
warning: --net-http-port not supported in this build, option ignored.
Tue Jan 29 21:18:01 2019 CET  EB_SOURCE EB_VERSION starting up.
Using sample converter: UC8, integer/table path
Found 1 device(s):
0: Realtek, RTL2838UHIDIR, SN: 0001 (currently selected)
Found Rafael Micro R820T tuner
Max available gain is: 49.60 dB
Setting gain to: 49.60 dB
Gain reported by device: 49.60 dB
Allocating 15 zero-copy buffers

I know the internal webserver is not really recommended, but here it's
more about quick testing than running a long process.

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

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

Versions of packages dump1090-mutability depends on:
ii  adduser   3.118
ii  debconf [debconf-2.0] 1.5.70
ii  libc6 2.28-5
ii  libjs-excanvas0.r3-4
ii  libjs-jquery-ui   1.12.1+dfsg-5
ii  libjs-jquery-ui-theme-smoothness  1.12.1+dfsg-1
ii  librtlsdr00.6-1
ii  lsb-base  10.2018112800

Versions of packages dump1090-mutability recommends:
pn  lighttpd  
ii  python2.7.15-4

dump1090-mutability suggests no packages.

-- debconf information:
  dump1090-mutability/stats-interval: 3600
  dump1090-mutability/invalid-is_number:
  dump1090-mutability/net-bo-port: 30005
  dump1090-mutability/net-bind-address: 127.0.0.1
  dump1090-mutability/invalid-is_port_list:
  dump1090-mutability/run-as-user: dump1090
  dump1090-mutability/invalid-is_port_number:
  dump1090-mutability/invalid-is_unsigned_number:
  dump1090-mutability/net-heartbeat: 60
  dump1090-mutability/invalid-is_signed_int_or_empty:
* dump1090-mutability/auto-start: false
  dump1090-mutability/invalid-is_ipaddrish_or_empty:
  dump1090-mutability/json-interval: 1
  dump1090-mutability/decode-fixcrc: true
  dump1090-mutability/rtlsdr-device:
  dump1090-mutability/invalid-is_number_or_empty:
  dump1090-mutability/rtlsdr-gain: max
  dump1090-mutability/rtlsdr-ppm: 0
  dump1090-mutability/net-bi-port: 30004,30104
  dump1090-mutability/invalid-is_signed_int:
  dump1090-mutability/net-out-size: 500
  dump1090-mutability/net-sbs-port: 30003
  dump1090-mutability/decode-lon:
  dump1090-mutability/json-location-accuracy: approximate
  dump1090-mutability/net-ri-port: 30001
  dump1090-mutability/extra-args:
  dump1090-mutability/decode-lat:
  dump1090-mutability/invalid-is_not_empty:
  dump1090-mutability/invalid-is_non_root_user:
  dump1090-mutability/invalid-is_unsigned_int_or_empty:
  dump1090-mutability/invalid-is_valid_gain:
  dump1090-mutability/decode-max-range: 300
  dump1090-mutability/net-ro-port: 30002
  dump1090-mutability/invalid-is_unsigned_int:
  dump1090-mutability/log-decoded-messages: false
  dump1090-mutability/net-buffer: 262144
  dump1090-mutability/invalid-is_positive_int:
  dump1090-mutability/log-file: /var/log/dump1090-mutability.log
  dump1090-mutability/use-lighttpd: true
  dump1090-mutability/json-dir: /run/dump1090-mutability
  dump1090-mutability/net-out-interval: 1

Bug#920776: sparse: new upstream release

[Uwe Kleine-König]

Hello Jonathan,

On 1/29/19 2:38 AM, Jonathan Nieder wrote:
> Thoughts of all kinds welcome, as always.  If you'd prefer this in the
> form of a "git pull"-able repository, a push to salsa, or an NMU, just
> ask.

I didn't follow sparse development in the nearer past. Is there a
problem with sparse 0.5.2 that would be fixed by going to 0.6.0?

My thought was not to touch it for buster and go to 0.6.0 only afterwards.

Best regards
Uwe




signature.asc
Description: OpenPGP digital signature

Bug#920746: [Pkg-zsh-devel] Bug#920746: zsh-common: lost menu entry on upgrade

[Axel Beckert]

Hi Sven,

Sven Joachim wrote:
> In the latest uploads (5.7-1 and 5.7-2) I noticed that the Debian menu
> entry for zsh got lost when upgrading zsh and zsh-common.

JFTR: I've got a Zsh menu entry.

> Manually running "update-menus" brought it back.

Could though have been that another tool ran update-menus in the meanwhile.

Hrm. Could this be the switch from debhelper compat 11 to 12? Then
again, /var/lib/dpkg/info/zsh-common.postinst has this code inserted
by debhelper:

# Automatically added by dh_installmenu/12
if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ]; then
update-menus
fi
# End automatically added section

Looks good to me, i.e. doesn't explain that sudden difference. In
contrary, this looks like a bug elsewhere. I also see nothing related
in the "Changes from v11" section of debhelper(7)…

> There does not seem to be a change in zsh itself which could have
> triggered this, rather I suspect some change in dpkg 1.19.3 has caused
> it.  Related bugs in menu are #628574, #518919 (archived) and #900838.

Hrm.

> A possible solution is to move the menu file back to zsh where it
> arguably belongs (it was moved to zsh-common in commit be35418de3).

I a) doubt that this helps because that commit is from 2012. I also
don't see why it should be in the architecture-dependent package while
being an architecture-independent file.

> Or remove the menu file altogether.

Indeed an option, but IMHO not because of this issue. IMHO shells are
nothing to be used via some menu.

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#601237: texlive-base: texdoc fails to open gzip'ed pdf files like pgfmanual.pdf.gz

[Hilmar Preuße]

On 29.01.19 20:50, Hilmar Preuße wrote:
> On 24.10.10 16:28, Dylan Thurston wrote:

Hi Norbert,

> Are you the one who submitted https://bugs.debian.org/601237 ?
> 
>> texdoc and texdoctk both seem to fail to open gzip'ed PDF files.
>> I only have two relevant files in my installed TeX packages:
>>
I tried two times to send a E-Mail to the submitter. The current
submitters address is outdated, another one failed to receive the mail
due to SPF.

I suggest to simply close that bug. What do you think?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature