Bug#890284: marked as done (RFS: textedit.app/5.0-2 [RC])

[Yavor Doganov]

>   * debian/maintscript: New file, replace Resources directory with a
> symlink (Closes: #890070).

> Well, the previous version did work for me with C.UTF-8 ...

What worked?  If you install 5.0-1 afresh, it will work.  Upgrades
will not work because dpkg will not replace a real directory with a
symlink (and vice-versa).  We handled this with a preinst before the
inception of dpkg-maintstript-helper.

Bug#890301: mcelog replaced with rasdaemon

[Andrey Rahmatullin]

Package: release-notes
Severity: wishlist

The "important obsolete packages" section should mention that mcelog is no
longer supported in kernels 4.12+ and was removed and rasdaemon should be
installed instead.

https://bugs.debian.org/889487

https://cateee.net/lkddb/web-lkddb/X86_MCELOG_LEGACY.html



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

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

Bug#889526: [Pkg-freeipa-devel] Bug#889526: pki-server: Dogtag stopped starting after libnss3 upgrade to 2:3.35-2

[Michal Kašpar]

Hallo.
Thank you for the explanation.

On 02/05/2018 11:18 AM, Timo Aaltonen wrote:

nss 3.35 apparently changed the default DB format to SQL..
certmonger, dogtag, mod_nss and freeipa all need changes to
support/migrate to that, but that's not upstream yet.



After last update of pki-server (to 10.5.5-1), the problem with jss 
appears even with older verison of nss. Is it connected with this 
problem or something different?


--
Michal Kašpar

Bug#890212: wxmaxima: Assertion failure: assert "m_group != NULL" failed in GetGroup()

[Gunter Königsmann]

Cool! Thanks a lot for this detailed information.

Seems like we have two options:
 - I can write a patch that fixes the problem for now.
 - Also I have resolved the problem upstream, which means the next
upstream release [which will take place in the next few weeks] will fix
this bug along with others. Which will save some work for getting the
patch into debian, but would mean that the bug is present a few weeks
longer than necessary.

If you say the 1st option is better (I guess you will) this weekend I'll
write the patch.

Thanks again,
and
Kind regards,

 Gunter.

Bug#888095:

[Andy Li]

This has been affecting neko (https://tracker.debian.org/pkg/neko) for a
while.
Would you fix it soonish?

Best regards,
Andy

Bug#840104: Encrypted uploads to the security archive

[Aurelien Jarno]

On 2018-02-01 22:17, Ansgar Burchardt wrote:
> Philipp Kern writes:
> > On 01.02.2018 10:30, Ansgar Burchardt wrote:
> [...]
> >> There is already a `buildd-uploader` role account on the upload hosts
> >> both main and security archive, a `rsync-ssh-wrap` script, and someone
> >> also set up authorized_keys.
> >> 
> >> I'm just not sure if it is already in use for security uploads?  I
> >> believe it was used for uploads to the main archive already (not sure if
> >> it currently is?).
> >
> > Indeed, it uses rsync over SSH through dupload. For security it uses
> > FTP. Interestingly an rsync-security dupload.conf entry exists, but it
> > doesn't seem to be used[1].
> 
> Hmm, maybe we should try if it does the right thing?  The wrapper script
> should ignore the `chmod` call I mentioned in #876900, so the uploaded
> files shouldn't even be readable by other DDs.

The problem there is that rsync when used with dupload forces the
uploaded file to be world readable, until the package is moved out from
the upload directory by dupload.

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

Bug#890300: ITP: fonts-eurofurence -- family of geometric rounded sans serif fonts

[Adam Borowski]

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: fonts-eurofurence
  Version : 4.0
  Upstream Author : Tobias Köhler
* URL : http://eurofurence.net/eurofurence.html
* License : SIL OFL 1.1
  Description : family of geometric rounded sans serif fonts
 Eurofurence is a family of fonts designed 1995-2000 by Tobias Köhler,
 originally for a convention these fonts are namesake of.
 .
 Provided variants are:
  * eurofurence (regular, bold, italic, bold italic) — meant for
signs, badges or text headings.
  * eurofurence classic (regular, bold, italic, bold italic, light, light
italic) — Futura-like, appropriate for body text.
  * unifur (regular) — {a,de}scender-less, titles and logos only.
 A monospaced variant, “monofur”, is provided as a separate package.

Bug#889270: advancecomp: heap buffer overflow while running advzip

[Andrea Mazzoleni]

Hi,

This issue has been fixed in AdvanceCOMP v2.1

https://github.com/amadvance/advancecomp/releases/tag/v2.1

Thanks for reporting!

Ciao,
Andrea Mazzoleni

Bug#889028: minissdpd (1.5.20161216-2) assumes IPV6

[M. Klonner]

Package: minissdpd
Version: 1.5.20161216-2
Followup-For: Bug #889028

Dear Maintainer,

During dist-upgrade minissdpd failed to install. It seems to try opening an 
IPV6 socket. 

-- Error message from apt:
Setting up minissdpd (1.5.20161216-2) ...
Job for minissdpd.service failed because the control process exited with 
error code.
See "systemctl status minissdpd.service" and "journalctl -xe" for details.
invoke-rc.d: initscript minissdpd, action "restart" failed.
● minissdpd.service - keep memory of all UPnP devices that announced 
themselves
   Loaded: loaded (/lib/systemd/system/minissdpd.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Sat 2018-02-10 16:29:47 CET; 
14ms ago
 Docs: man:minissdpd(1)
  Process: 3450 ExecStart=/usr/sbin/minissdpd -i 
$MiniSSDPd_INTERFACE_ADDRESS $MiniSSDPd_OTHER_OPTIONS (code=exited, 
status=1/FAILURE)
 Main PID: 966 (code=exited, status=0/SUCCESS)

Feb 10 16:29:47 Bantiger systemd[1]: Starting keep memory of all UPnP 
devices that announced themselves...
Feb 10 16:29:47 Bantiger minissdpd[3450]: socket(udp): Address family not 
supported by protocol
Feb 10 16:29:47 Bantiger minissdpd[3450]: Cannot open socket for receiving 
SSDP messages (IPv6), exiting
Feb 10 16:29:47 Bantiger systemd[1]: minissdpd.service: Control process 
exited, code=exited status=1
Feb 10 16:29:47 Bantiger minissdpd[3450]: unlink(/var/run/minissdpd.pid): 
No such file or directory
Feb 10 16:29:47 Bantiger systemd[1]: minissdpd.service: Failed with result 
'exit-code'.
Feb 10 16:29:47 Bantiger systemd[1]: Failed to start keep memory of all 
UPnP devices that announced themselves.
dpkg: error processing package minissdpd (--configure):
 installed minissdpd package post-installation script subprocess returned 
error exit status 1
Processing triggers for libc-bin (2.26-4) ...
Errors were encountered while processing:
 minissdpd
E: Sub-process /usr/bin/dpkg returned an error code (1)



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

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

Versions of packages minissdpd depends on:
ii  libc6  2.26-4
ii  libnfnetlink0  1.0.1-3+b1
ii  lsb-base   9.20170808

minissdpd recommends no packages.

minissdpd suggests no packages.

-- no debconf information

Bug#890299: Comparison for Gubbi versus Lohit Kannada

[ಚಿರಾಗ್ ನಟರಾಜ್]

The character is the same for both (ಚ್), but is rendered very differently 
depending on which font is being used. I should note that this only seems to be 
a problem in Emacs - for example, the font renders perfectly well in firefox. 
wrong.png is rendered using Gubbi. right.png is rendered using Lohit Kannada.
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Graduate Student at Brown University
Email: chiraag.nata...@gmail.com
Phone: 610-350-6329
Website: http://chiraag.nataraj.us


signature.asc
Description: PGP signature

Bug#890299: segfault log attached

[ಚಿರಾಗ್ ನಟರಾಜ್]

The output when emacs segfaults is attached. Please let me know if you need 
more information.
-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Graduate Student at Brown University
Email: chiraag.nata...@gmail.com
Phone: 610-350-6329
Website: http://chiraag.nataraj.us
Fatal error 11: Segmentation fault
Backtrace:
emacs25[0x502a5e]
emacs25[0x4e8fa9]
emacs25[0x5011ae]
emacs25[0x501368]
emacs25[0x5013f5]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x11f50)[0x7fc4312d2f50]
/usr/lib/x86_64-linux-gnu/libotf.so.0(+0xea95)[0x7fc431c81a95]
/usr/lib/x86_64-linux-gnu/libotf.so.0(+0xfe64)[0x7fc431c82e64]
/usr/lib/x86_64-linux-gnu/libotf.so.0(OTF_drive_gpos_with_log+0x2a)[0x7fc431c84a2a]
emacs25[0x5bad66]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x24f2)[0x7fc43183d4f2]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x5f67)[0x7fc431840f67]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x5f67)[0x7fc431840f67]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x5b53)[0x7fc431840b53]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x5f67)[0x7fc431840f67]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(+0x6b98)[0x7fc431841b98]
/usr/lib/x86_64-linux-gnu/libm17n-flt.so.0(mflt_run+0x2f1)[0x7fc431842e51]
emacs25[0x5bbcdd]
emacs25[0x5bf64e]
emacs25[0x56b9b9]
emacs25[0x55c0e5]
emacs25[0x590983]
emacs25[0x55e3ad]
emacs25[0x55befb]
emacs25[0x55b6a6]
emacs25[0x42b00c]
emacs25[0x438c3c]
emacs25[0x5af9c6]
emacs25[0x5b388c]
emacs25[0x4423c4]
emacs25[0x441fa8]
emacs25[0x440475]
emacs25[0x442702]
emacs25[0x444e35]
emacs25[0x44bfa1]
emacs25[0x44ee0e]
emacs25[0x42f4d8]
emacs25[0x453626]
emacs25[0x45392f]
emacs25[0x453a9c]
emacs25[0x5531be]
...
Segmentation fault


signature.asc
Description: PGP signature

Bug#890299: emacs25: Various problems with Kannada fonts

[Chiraag Nataraj]

Source: emacs25
Version: 25.2+1-6
Severity: normal

Dear Maintainer,

I've had a couple of issues with a couple of Kannada fonts.

The first is Noto Sans Kannada (from fonts-noto-hinted). When I have the font 
installed, it is the default for rendering Kannada characters. However, certain 
characters (such as ಚು and ಕು) rendered in the font cause Emacs to completely 
crash with a segfault (I will add the exact output of the crash in a follow-up 
email).

The second is Gubbi (from fonts-gubbi). This problem is hard to explain to 
someone who doesn't know Kannada, so I will attach pictures in to demonstrate.

At least one font which works perfectly well (as far as I'm aware) is Lohit 
Kannada (from fonts-lohit-knda).

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

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

Bug#883573: Call for vote on waiving libpam-systemd dependencies' ordering

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Fri, Feb 09, 2018 at 09:14:49AM +0100]:
> I call for votes on the following resolution with regards to #883573.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
> 
> === Resolution ===
> 
> In 2014, it was resolved in #746578 that the libpam-systemd binary package 
> alternative dependency on systemd-shim and systemd-sysv shall be set in that 
> order, in order to avoid unwanted init system changes accross upgrades. 
> Debian 
> Stretch has since been released.
> 
> The Committee therefore resolves that:
> 
> 1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed.
> 
> This means Debian's normal policies and practices take over and the
> libpam-systemd package's dependencies are set free from specific ordering 
> constraints.  The migration should be managed according to Debian's usual 
> backwards-compatibility arrangements.
> 
> === End Resolution ===
> 
> R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578.
> F: Further Discussion
> 
> --
>   OdyX

I vote:

R > F



signature.asc
Description: PGP signature

Bug#837146: [gnome-tweak-tool] press alt key make gnome-tweak-tool crash

[Yasushi SHOJI]

Hi guys,

I can reproduce this problem on my Sid, so I fire up gdb to see what's
going on.  It seems to me that ibus is causing Gdk Window to be NULL.
When I removed ibus, ibus-skk and im-config from my system, GNOME
Tweaks doesn't crash anymore.

Đặng, didn't you have some input method loaded?

Detail (gdb debug seesion log) is attached.

Thanks,
--
  yashi
Source directories searched: /tmp/gtk+3.0-3.22.26/gdk:$cdir:$cwd
Reading symbols from /usr/bin/python3...Reading symbols from 
/usr/lib/debug/.build-id/e7/1f68741e22cb60c0c643ecb4feff0a38af8a5e.debug...done.
done.
Starting program: /usr/bin/python3 /usr/bin/gnome-tweaks
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffec37e700 (LWP 17520)]
[New Thread 0x7fffebb7d700 (LWP 17521)]
[New Thread 0x7fffeb16f700 (LWP 17522)]
[New Thread 0x7fffe8b62700 (LWP 17524)]
[New Thread 0x7fffdbfff700 (LWP 17525)]
[New Thread 0x7fffcd22b700 (LWP 17527)]
[New Thread 0x7fffcca2a700 (LWP 17528)]
[New Thread 0x7fffc7fff700 (LWP 17530)]
[Thread 0x7fffe8b62700 (LWP 17524) exited]
[Thread 0x7fffdbfff700 (LWP 17525) exited]

Thread 1 "python3" received signal SIGSEGV, Segmentation fault.
0x73c2a102 in gdk_window_has_impl (window=) at 
../../../../gdk/gdkwindow.c:677
677 {
672 window->parent->window_type == GDK_WINDOW_ROOT;
673 }
674 
675 gboolean
676 _gdk_window_has_impl (GdkWindow *window)
677 {
678   return gdk_window_has_impl (window);
679 }
680 
681 static gboolean
$1 = 
#0  0x73c2a102 in gdk_window_has_impl (window=) at 
../../../../gdk/gdkwindow.c:677
#1  0x73c2a102 in _gdk_window_has_impl (window=window@entry=0x0) at 
../../../../gdk/gdkwindow.c:678
#2  0x73c615ee in gdk_x11_window_get_xid (window=0x0) at 
../../../../../gdk/x11/gdkwindow-x11.c:5560
#3  0x7fffe8dc41ab in gtk_im_context_xim_filter_keypress (context=0xca61e0 
[GtkIMContextXIM], event=0x1e87000)
at ../../../../../modules/input/gtkimcontextxim.c:673
#4  0x7fffeed56af3 in gtk_im_multicontext_filter_keypress (context=0xf570c0 
[GtkIMMulticontext], event=0x1e87000)
at ../../../../gtk/gtkimmulticontext.c:359
#5  0x75c7afce in ffi_call_unix64 () at ../src/x86/unix64.S:76
#6  0x75c7a93f in ffi_call (cif=cif@entry=0x1dd4268, fn=, rvalue=, 
rvalue@entry=0x7fffce08, avalue=) at 
../src/x86/ffi64.c:525
#7  0x7667adda in pygi_invoke_c_callable (function_cache=0x1dd41c0, 
state=, py_args=, py_kwargs=) at 
../../gi/pygi-invoke.c:682
#8  0x7667c9b8 in pygi_function_cache_invoke (function_cache=, py_args=py_args@entry=(, ), py_kwargs=) at 
../../gi/pygi-cache.c:863
#9  0x7667b648 in pygi_callable_info_invoke (info=, 
py_args=py_args@entry=(, ), kwargs=, cache=, 
user_data=user_data@entry=0x0) at ../../gi/pygi-invoke.c:725
#10 0x7667b67f in _wrap_g_callable_info_invoke (self=, 
py_args=py_args@entry=(, ), kwargs=) at ../../gi/pygi-invoke.c:762
#11 0x76670c29 in _callable_info_call (self=0x7fffec5945a8, 
args=(,), kwargs=0x0)
at ../../gi/pygi-info.c:561
#12 0x0045a0d3 in _PyObject_FastCallDict (func=, args=0x7fffdb7c5928, nargs=1, kwargs=0x0)
at ../Objects/abstract.c:2331
#13 0x0054fc17 in call_function 
(pp_stack=pp_stack@entry=0x7fffd038, oparg=, 
kwnames=kwnames@entry=0x0)
at ../Python/ceval.c:4848
#14 0x005545af in _PyEval_EvalFrameDefault (f=, 
throwflag=) at ../Python/ceval.c:3322
#15 0x0054efe8 in PyEval_EvalFrameEx (throwflag=0, f=Frame 
0x7fffdb7c5788, for file /usr/lib/python3/dist-packages/gtweak/tweakview.py, 
line 196, in _after_key_press (self=, '__spec__': , 
origin='/usr/lib/python3/dist-packages/gtweak/tweakview.py', loader_state=None, 
submodule_search_locations=None, _set_fileattr=True, 
_cached='/usr/lib/python3/dist-packages/gtweak/__pycache__/tweakview.cpython-36.pyc',
 _initializing=False) at 

Bug#890298: lintian: warn about problematic use of udevadm in maintainer scripts

[Stuart Prescott]

Package: lintian
Version: 2.5.67~bpo9+1
Severity: wishlist

udevadm can be present on the system but non-functional, due to being inside
a chroot for example. It seems that there are two common patterns used in
maintainer scripts that correctly handle that situation:

if udevadm control --reload; then …

udevadm control --reload || true

Could lintian detect the unprotected udevadm call that, with set -e, will
cause the maintainer script to fail?

(Context: https://bugs.debian.org/890224)

Bug#887659: RFS: urlwatch/2.7-1 [ITA]

[Paul Wise]

On Fri, 2018-02-09 at 07:29 +0100, Maxime Werlen wrote:

> Thanks for your time reviewing my packages.

Thanks for adopting urlwatch!

> I've tried to fix as much issues as I'm capable.

There is only the blocker of ftp-masters accepting minidb now.

It would be nice to fix these extra issues at some point:

Upstream released 2.8 on 2018-01-28.

The upstream thpinfo.com website has a broken TLS certificate:

The certificate is only valid for thp.io
The certificate expired on 22/03/17 04:52.

I would suggest switching Debian copyright/control to thp.io
and or contacting upstream about fixing their TLS certificate.

I would suggest wrapping debian/watch between the URL and regex.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#887660: RFS: minidb/2.0.2-1 [ITP]

[Paul Wise]

On Fri, 2018-02-09 at 07:31 +0100, Maxime Werlen wrote:

> Thanks for your time reviewing this package.

Thanks for adopting urlwatch :)

> I've tried to fix as much issues as I'm capable.

Excellent.

Since you fixed the two blockers, I've uploaded it to NEW.

A few more things that might be nice to fix at some point:

The example file gets compressed in the package, I wonder if it would
be better for it to be uncompressed or not.

The ISC license in debian/copyright is missing the blank line that is
in minidb.py. Please note that blank lines are encoded in Debian
copyright as lines " ." (space followed by a dot and then newline).

I would wrap the watch file between the URL and regex too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#890293: [PATCH] New binary package: wesperanto

[KAction]

Package: eo-spell
Version: 2.1.2000.02.25-54
Severity: wishlist

Hello! For some spell checking programs, like built-in Vim one, the most
simple way to setup spell-checking is to have raw, one word per line
list of correct words. It seems to be established practice to name
binary packages in format 'w{language}', like wamerican, wnorwegian or
wukrainian.

Attached debdiff adds new binary package 'wesperanto' to src:eo-spell. I
know, that it is not perfect, since it should also 'Provide: wordlist',
but, in my defense, wnorwegian also does not provide wordlist.

This patch creates list in utf-8 encoding (obliviously), but may it be
useful to have in addition, 'wesperanto-cx'?

Thank you for your attention, and please consider applying patch.
diffstat for eo-spell-2.1.2000.02.25 eo-spell-2.1.2000.02.25

 changelog  |7 +++
 control|9 +
 cx2utf8.sed|   13 +
 rules  |3 +++
 wesperanto.install |1 +
 5 files changed, 33 insertions(+)

diff -Nru eo-spell-2.1.2000.02.25/debian/changelog eo-spell-2.1.2000.02.25/debian/changelog
--- eo-spell-2.1.2000.02.25/debian/changelog	2015-09-22 13:16:05.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/changelog	2018-01-24 17:52:43.0 +0300
@@ -1,3 +1,10 @@
+eo-spell (2.1.2000.02.25-55) unstable; urgency=low
+
+  * New binary package: wesperanto, providing plain list of esperanto words.
++ Thanks: Dmitry Bogatov 
+
+ -- Agustin Martin Domingo   Wed, 24 Jan 2018 17:52:43 +0300
+
 eo-spell (2.1.2000.02.25-54) unstable; urgency=medium
 
   * debian/control::myspell-eo: Use Conflicts where needed.
diff -Nru eo-spell-2.1.2000.02.25/debian/control eo-spell-2.1.2000.02.25/debian/control
--- eo-spell-2.1.2000.02.25/debian/control	2015-09-22 13:13:55.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/control	2018-01-24 17:52:43.0 +0300
@@ -24,6 +24,15 @@
  Plena Ilustrita Vortaro, with additional country/language names.  It
  accepts Latin-3, 'cx' and '^c' forms.
 
+Package: wesperanto
+Architecture: all
+Depends: ${misc:Depends}
+Description: Esperanto dictionary words for /usr/share/dict
+ This package provides the file /usr/share/dict/esperanto,
+ containing a list of Esperanto words in utf-8 encoding. 
+ This list can be used by spelling checkers, and by programs
+ such as look(1).
+
 Package: myspell-eo
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru eo-spell-2.1.2000.02.25/debian/cx2utf8.sed eo-spell-2.1.2000.02.25/debian/cx2utf8.sed
--- eo-spell-2.1.2000.02.25/debian/cx2utf8.sed	1970-01-01 03:00:00.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/cx2utf8.sed	2018-01-24 17:52:43.0 +0300
@@ -0,0 +1,13 @@
+#/usr/bin/sed -f
+s/cx/ĉ/g
+s/hx/ĥ/g
+s/jx/ĵ/g
+s/sx/ŝ/g
+s/ux/ŭ/g
+s/gx/ĝ/g
+s/Cx/Ĉ/g
+s/Hx/Ĥ/g
+s/Jx/Ĵ/g
+s/Sx/Ŝ/g
+s/Ux/Ŭ/g
+s/Gx/Ĝ/g
diff -Nru eo-spell-2.1.2000.02.25/debian/rules eo-spell-2.1.2000.02.25/debian/rules
--- eo-spell-2.1.2000.02.25/debian/rules	2015-06-18 18:10:50.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/rules	2018-01-24 17:52:43.0 +0300
@@ -80,6 +80,9 @@
 	cat kune.txt | ispell -d ./eo -e | tr -s ' ' '\n' | sort -u > $(TMP_BUILD)/eo-cx.wl
 	cat $(TMP_BUILD)/eo-cx.wl | grep -v -e "-'$$" | prezip -s -c | gzip -9n -c > $(TMP_BUILD)/eo-cx.cwl.gz
 	install -m 0644 debian/aspell/eo-cx.dat debian/aspell/eo-cx.multi $(TMP_BUILD)
+	unmunch $(TMP_BUILD)/eo.dic $(TMP_BUILD)/eo.aff \
+		| iconv -f latin3 -t utf-8 \
+		| sed -f debian/cx2utf8.sed > $(TMP_BUILD)/esperanto
 
 	touch $@
 
diff -Nru eo-spell-2.1.2000.02.25/debian/wesperanto.install eo-spell-2.1.2000.02.25/debian/wesperanto.install
--- eo-spell-2.1.2000.02.25/debian/wesperanto.install	1970-01-01 03:00:00.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/wesperanto.install	2018-01-24 17:52:43.0 +0300
@@ -0,0 +1 @@
+esperanto /usr/share/dict

Bug#890297: [PATCH] ticgit: proposed completion script

[KAction]

Package: ticgit
Version: 1.0.2.17-2
Severity: wishlist

Hello! I wrote bash-completion script for tic(1).  While it is not
perfect and do not cover some options, I think it is still much better
than nothing. Please, consider including.

For your convenience, I attach both just script and debdiff.
# -*- shell-script -*-
# Copyright (C) 2017 Dmitry Bogatov
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see .
#

# Ticket is represented by directory in 'ticgit' branch, which has
# TICKET_ID file with directory name in it.
#
# Real ticketId, as references by all subcommands of 'ticgit' is a
# hash of blob, corresponding to content of that TICKET_ID file.
#
# This function enumerates all tickets with ID starting with ${1}.
#
# Use of low-level representation of TicGit tickets and Git blobs is about
# factor 30 faster than parsing output of `ti list'.
_ticgit_tickets () {
local prefix=${1};
local names=$(git ls-tree -d --name-only ticgit 2>/dev/null) || return

for name in ${names} ; do
ticket=$(printf "blob %d\0%s\n" $(( 1 + ${#name})) "${name}"|sha1sum)
if [[ $prefix = "${ticket:0:${#prefix}}" ]] ; then
echo "${ticket:0:6}"
fi
done
}

_ticgit_tags () {
local prefix=${1}
local tree=$(git ls-tree -r ticgit --name-only 2>/dev/null) || return
for tag in $(echo "${tree}" | awk -FTAG_ '{ print $2 }') ; do
if [[ $prefix = "${tag:0:${#prefix}}" ]] ; then
echo "${tag}"
fi
done
}

_ticgit_complete_ticket_or_options () {
case "${cur}" in
-*) COMPREPLY=($(compgen -W "${options}" -- "${cur}")) ;;
*) COMPREPLY=($(_ticgit_tickets "${cur}")) ;;
esac
}

# Completion functions for specific subcommands
_ticgit_complete_show () {
local options='--help --version --full'
_ticgit_complete_ticket_or_options
}

_ticgit_complete_assign () {
local options='--version --help --user --checkout'
case "${prev}" in
-c|--checkout) COMPREPLY=($(_ticgit_tickets "${cur}")) ;;
-u|--user) ;; # FIXME: how to complete user?
*) _ticgit_complete_ticket_or_options ;;
esac
}

_ticgit_complete_checkout () {
local options='--help --version'
_ticgit_complete_ticket_or_options
}

_ticgit_complete_comment () {
local options='--help --version --file --message'
case "${prev}" in
-f|--file) _filedir ;;
-m|--message) ;;
*) _ticgit_complete_ticket_or_options ;;
esac
}

_ticgit_complete_list () {
local options='--help --version --list --saveas --assigned
--states --tags --order'
case "${prev}" in
-S|--saveas) ;;
-a|--assigned) #FIXME: not implemented
;;
-t|--tags) COMPREPLY=($(_ticgit_tags "$cur")) ;;
-s|--states)
COMPREPLY=($(compgen -W "$states" -- "$cur"))
;;
-o|--order)
local orders='assigned state date title'
COMPREPLY=($(compgen -W "$orders" -- "$cur"))
;;
*) COMPREPLY=($(compgen -W "$options" -- "$cur")) ;;
esac
}

_ticgit_complete_new () {
local options='--help --version --title'
case "${prev}" in
-t|--title) ;;
*) _ticgit_complete_ticket_or_options ;;
esac
}

_ticgit_complete_points () {
local options='--help --version'
if [[ $cword -eq 2 ]] ; then
_ticgit_complete_ticket_or_options
fi
}

_ticgit_complete_state () {
if [[ $cword -eq 2 ]] ; then
COMPREPLY=( $(_ticgit_tickets "${cur}")
$(compgen -W "${states}" -- "${cur}") )
else
COMPREPLY=( $(compgen -W "${states}" -- "${cur}") )
fi
}

_ticgit_complete_tag () {
if [[ $cword -eq 2 ]] ; then
COMPREPLY=( $(_ticgit_tickets "${cur}") )
else
COMPREPLY=( $(compgen -W "--delete" -- "${cur}")
$(_ticgit_tags "${cur}") )
fi
}

_ticgit () {
local states='hold invalid open resolved'
local cur prev word cword
_init_completion || return

local commands='assign checkout comment help init list new points
recent show state sync tag'

if [[ $cword -eq 1 ]] ; then
COMPREPLY=($(compgen -W "$commands" -- "$cur"))
else
case ${COMP_WORDS[1]} in
help) COMPREPLY=($(compgen -W "$commands" -- "$cur")) ;;
init|resent)
COMPREPLY=($(compgen -W '--help --version' -- "$cur"))
;;

Bug#890295: gettext-el: missing defcustom

[KAction]

Package: gettext-el
Version: 0.19.8.1-2
Severity: normal

Hello!

po-mode runs `po-subedit-mode-hook' in po-mode.el:2447, but that hook is
only mentioned in description of `po-edit-string()' function, but is not
declared as customizable variable (defvar/defcustom).

It makes it impossible to configure it with Custom or locate that hook
with `describe-variable()'[1]. I would suggest adding following lines:

(defcustom po-subedit-mode-hook nil
  "List of functions to run in buffer, created by `po-edit-string'."
  :group 'po
  :typee 'hook)

[1] Personally, I found this hook by reading the sources. Not very
user-friendly.

Bug#890294: asymptote: complex eval-using code triggers assert failure

[KAction]

Package: asymptote
Version: 2.41-4
Severity: normal

Hello! Following piece of code is meant to create wrapper structures
around primitive types, simplifying creation of generic code.

var casts = quote {
public TWrap operator cast(TInner value)
{
var obj = new TWrap;
obj.value = value;
return obj;
}
public TInner operator cast(TWrap obj)
{
return obj.value;
}
};

void define_wrapper(string type)
{
string wrapper = 'A' + type;
string prog = 'public struct ' + wrapper + '{ ' + type + ' 
value; };';
eval(prog, true);
eval('typedef ' + wrapper + ' TWrap', true);
eval('typedef ' + type + ' TInner', true);
eval(casts, true);
}
define_wrapper('int');
define_wrapper('real');


Unfortunately, following error is produced instead:

asy: exp.cc:43: virtual void absyntax::exp::transAsType(trans::coenv&, 
types::ty*): Assertion `t->kind==ty_error || equivalent(t,target)' failed.

Problem is present in both versions in sid and stretch.

Bug#890296: xinit: startx ignores SIGTERM

[KAction]

Package: xinit
Version: 1.3.4-3+b1
Severity: normal

Hello!

*startx* script ignores many signals, SIGTERM in particular; it causes
problems with process supervision.

Please consider applying following patch, which fulfil intended purpose
of ``trap`` statement, keeping process resposible to signals. 

PS. Just curious, under what circumstances would a /bin/sh receive a SIGILL?

diff -rU7 xinit-1.3.4:original/startx.cpp xinit-1.3.4/startx.cpp
--- xinit-1.3.4:original/startx.cpp 2017-10-02 01:33:07.556320513 +0300
+++ xinit-1.3.4/startx.cpp  2017-10-02 01:33:35.828321881 +0300
@@ -266,15 +266,15 @@
 echo "Couldn't create cookie"
 exit 1
 fi
 dummy=0

 XCOMM create a file with auth information for the server. ':0' is a dummy.
 xserverauthfile=$HOME/.serverauth.$$
-trap "rm -f '$xserverauthfile'" HUP INT QUIT ILL TRAP KILL BUS TERM
+trap "rm -f '$xserverauthfile'" EXIT
 xauth -q -f "$xserverauthfile" << EOF
 add :$dummy . $mcookie
 EOF
 #if defined(__APPLE__) || defined(__CYGWIN__)
 xserverauthfilequoted=$(echo ${xserverauthfile} | sed "s/'/'''/g")
 serverargs=${serverargs}" -auth '"${xserverauthfilequoted}"'"
 #else

Bug#890136: libbpp-phyl: FTBFS on mipsel: Test took too much time

[Boyuan Yang]

2018-02-12 22:04 GMT+08:00 Andreas Tille :
> Control: severity -1 wishlist
>
> Hi,
>
> I'm sorry but I do not consider the fact that mips is to slow to run a
> long lasting test a release blocker.  Either mips can cope up or I'll
> exclude it from the list or architectures.  Please note that this program
> will most probably not be used on mips and I do not intend to spent time
> on this issue.

Okay, got it.

However please note that mipsel is a release architecture thus a missing
build would be the blocker to testing migration. Some adjustment might be needed
to solve this issue.

--
Thanks,
Boyuan Yang

Bug#890292: vlc: convert / save file selection unable to clear list / select multiple files from list

[marek]

Package: src:vlc
Version: 3.0.0~rc8-1
Severity: normal

To reproduce:
Start VLC (GUI).
Click Media, click Convert / Save, click  +Add..., select multiple files, click
open.

Expected:
It is possible to select multiple files in resulting list in "Open Media"
window "File Selection" "You can select local files with the followng list and
buttons." and remove them all in once by clicking -Remove.
It is possible to select all files by ctrl+a, it is possible to select files by
click, hold and drag mouse pointer, it is possible to select multiple files
using keyboard arrows when holding shift.

Actual:
It is not possible to select multiple files in resulting list in "Open Media"
window "File Selection" "You can select local files with the followng list and
buttons." and remove them all in once by clicking -Remove.
It is not possible to select all files by ctrl+a, it is not possible to select
files by click, hold and drag mouse pointer, it is not possible to select
multiple files using keyboard arrows when holding shift.



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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 vlc depends on:
ii  vlc-bin  3.0.0~rc8-1
ii  vlc-plugin-base  3.0.0~rc8-1
ii  vlc-plugin-qt3.0.0~rc8-1
ii  vlc-plugin-video-output  3.0.0~rc8-1

Versions of packages vlc recommends:
ii  vlc-l10n   3.0.0~rc8-1
ii  vlc-plugin-notify  3.0.0~rc8-1
ii  vlc-plugin-samba   3.0.0~rc8-1
ii  vlc-plugin-skins2  3.0.0~rc8-1
ii  vlc-plugin-video-splitter  3.0.0~rc8-1
ii  vlc-plugin-visualization   3.0.0~rc8-1

vlc suggests no packages.

Versions of packages libvlc-bin depends on:
ii  libc62.26-6
ii  libvlc5  3.0.0~rc8-1

Versions of packages libvlc5 depends on:
ii  libc62.26-6
ii  libvlccore9  3.0.0~rc8-1

Versions of packages libvlc5 recommends:
ii  libvlc-bin  3.0.0~rc8-1

Versions of packages libvlccore8 depends on:
ii  libc62.26-6
ii  libdbus-1-3  1.12.2-1
ii  libidn11 1.33-1

Versions of packages libvlccore8 recommends:
ii  libproxy-tools  0.4.14-3

Versions of packages vlc-bin depends on:
ii  libc6   2.26-6
ii  libvlc-bin  3.0.0~rc8-1
ii  libvlc5 3.0.0~rc8-1

Versions of packages vlc-plugin-base depends on:
ii  liba52-0.7.4 0.7.4-19
ii  libarchive13 3.2.2-2
ii  libaribb24-0 1.0.3-1
ii  libasound2   1.1.3-5
ii  libass9  1:0.14.0-1
ii  libavahi-client3 0.6.32-2
ii  libavahi-common3 0.6.32-2
ii  libavc1394-0 0.5.4-4+b1
ii  libavcodec57 7:3.4.1-1+b2
ii  libavformat577:3.4.1-1+b2
ii  libavutil55  7:3.4.1-1+b2
ii  libbasicusageenvironment12018.01.29-1
ii  libbluray2   1:1.0.1.deb1-2
ii  libc62.26-6
ii  libcairo21.15.10-1
ii  libcddb2 1.3.2-5
ii  libchromaprint1  1.4.2-1
ii  libcrystalhd31:0.0~git20110715.fdd2f19-12
ii  libdbus-1-3  1.12.2-1
ii  libdc1394-22 2.2.5-1
ii  libdca0  0.0.5-10
ii  libdvbpsi10  1.3.1-2
ii  libdvdnav4   5.0.3-3
ii  libdvdread4  5.0.3-2
ii  libebml4v5   1.3.5-2
ii  libfaad2 2.8.0~cvs20161113-1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.12.6-0.1
ii  libfreetype6 2.8.1-1
ii  libfribidi0  0.19.7-1+b1
ii  libgcc1  1:7.3.0-1
ii  libgcrypt20  1.8.1-4
ii  libglib2.0-0 2.54.3-2
ii  libgnutls30  3.5.8-6
ii  libgpg-error01.26-2
ii  libgroupsock82018.01.29-1
ii  libharfbuzz0b1.7.2-1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libkate1 0.4.1-7+b1
ii  liblirc-client0  0.9.4c-9
ii  liblivemedia62   2018.01.29-1
ii  liblua5.2-0  5.2.4-1.1+b2
ii  libmad0  0.15.1b-8+b2
ii  libmatroska6v5   1.4.5-2
ii  libmicrodns0 0.0.8-1
ii  libmpcdec6   2:0.1~r495-1+b1
ii  libmpeg2-4   0.5.1-7+b2
ii  libmpg123-0  

Bug#890200: PyQt5 package should provide an egg-info

[Scott Kitterman]

On Sunday, February 11, 2018 09:19:59 PM VA wrote:
> Package: python-pyqt5
> Version: 5.9.2+dfsg-1
> 
> Many Debian python packages include an egg-info folder, but python-pyqt5
> does not.

The PyQt5 upstream does not use standard Python tools for building the 
package.  As shipped by upstream, a source build of PyQt5:

python3 configure.py
make
sudo make install

does not install any egg information.  Only the upstream wheels provide 
anything.  They provide a PyQt5-5.10.dist-info directory which appears to 
perform a similar function.

This is probably not feasible in Debian as we split PyQt5 into a number of 
sub-packages to minimize the dependencies that get pulled in for various 
applications.  I'm not sure how to manage the egg-info for such a case.

Scott K

Bug#890212: wxmaxima: Assertion failure: assert "m_group != NULL" failed in GetGroup()

[John Scott]

Package: wxmaxima
Version: 17.10.1-1
Followup-For: Bug #890212

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've installed the relevant debugging symbols and got a better backtrace with 
gdb.

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

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

Versions of packages wxmaxima depends on:
ii  ibus-gtk3 1.5.17-3
ii  libc6 2.26-4
ii  libgcc1   1:7.2.0-19
ii  libstdc++67.2.0-19
ii  libwxbase3.0-0v5  3.0.3.1+dfsg2-1
ii  libwxgtk3.0-0v5   3.0.3.1+dfsg2-1
ii  maxima5.41.0-1

Versions of packages wxmaxima recommends:
ii  maxima-doc  5.41.0-1

Versions of packages wxmaxima suggests:
pn  fonts-jsmath 
ii  texlive-latex-extra  2017.20180110-1

- -- no debconf information

*** /home/john/wxMaxima/backtrace.txt
#0  0x74f7a000 in raise (sig=sig@entry=5) at 
../sysdeps/unix/sysv/linux/raise.c:51
#1  0x75ad389a in wxTrap() () at ../src/common/appbase.cpp:1070
#2  0x765e7f45 in wxGUIAppTraits::ShowAssertDialog(wxString const&) 
(this=, msg=...)
at ../src/gtk/utilsgtk.cpp:330
#3  0x75ad7a81 in ShowAssertDialog(wxString const&, int, wxString 
const&, wxString const&, wxString const&, wxAppTraits*) (file=..., 
line=line@entry=21845, func=..., cond=..., msgUser=..., traits=0x55ac4440, 
traits@entry=0x56449c80)
at ../src/common/appbase.cpp:1322
#4  0x75ada467 in wxAppConsoleBase::OnAssertFailure(wchar_t const*, 
int, wchar_t const*, wchar_t const*, wchar_t const*) 
(this=this@entry=0x55a82830, file=, line=21845, 
func=, cond=, msg=) at 
../src/common/appbase.cpp:801
#5  0x765b3b70 in wxApp::OnAssertFailure(wchar_t const*, int, wchar_t 
const*, wchar_t const*, wchar_t const*) (this=0x55a82830, file=, line=, func=, cond=, 
msg=)
at ../src/gtk/app.cpp:540
#6  0x75ada75f in wxDefaultAssertHandler(wxString const&, int, wxString 
const&, wxString const&, wxString const&) (file=..., line=215, func=..., 
cond=..., msg=...) at ../src/common/appbase.cpp:1112
#7  0x75ad45dc in wxOnAssert(char const*, int, char const*, char 
const*, wxString const&) (file=file@entry=0x557860d0 
"/build/wxmaxima-hiO5pO/wxmaxima-17.10.1/src/MathCell.cpp", 
line=line@entry=215, func=func@entry=0x557860c0 
 "GetGroup", cond=cond@entry=0x55785bed 
"m_group != NULL", msg=...)
at ../src/common/appbase.cpp:1162
#8  0x55685321 in MathCell::GetGroup() (this=0x562f2a90) at 
./src/MathCell.cpp:215
#9  0x5568997b in MathCtrl::CanDeleteSelection() (this=0x55ba6e20) 
at ./src/MathCtrl.cpp:2249
#10 0x5568de75 in MathCtrl::CanMergeSelection() (this=) 
at ./src/MathCtrl.cpp:6588
#11 0x55719340 in wxMaxima::UpdateMenus(wxUpdateUIEvent&) 
(this=this@entry=0x55aee270, event=...)
at ./src/wxMaxima.cpp:2943
#12 0x55747cc9 in wxMaxima::OnIdle(wxIdleEvent&) (this=0x55aee270, 
event=...) at ./src/wxMaxima.cpp:2788
#13 0x75c562ce in 
wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&) (entry=..., handler=, event=...) at 
../src/common/event.cpp:1390
#14 0x75c563d3 in wxEventHashTable::HandleEvent(wxEvent&, 
wxEvtHandler*) (this=, event=..., self=self@e
ntry=0x55aee270) at ../src/common/event.cpp:996
#15 0x75c5679b in wxEvtHandler::TryHereOnly(wxEvent&) 
(this=0x55aee270, event=...)
at ../src/common/event.cpp:1587
#16 0x75c56593 in wxEvtHandler::DoTryChain(wxEvent&) (this=, event=...)
at ../src/common/event.cpp:1552
#17 0x75c56885 in wxEvtHandler::ProcessEvent(wxEvent&) 
(this=0x55aee798, event=...)
at ../src/common/event.cpp:1493
#18 0x75c565e7 in wxEvtHandler::SafelyProcessEvent(wxEvent&) 
(this=, event=...)
at ../src/common/event.cpp:1611
#19 0x767b248c in wxWindowBase::HandleWindowEvent(wxEvent&) const 
(this=this@entry=0x55aee270, event=...)
at ../src/common/wincmn.cpp:1525
#20 0x767b2500 in wxWindowBase::SendIdleEvents(wxIdleEvent&) 
(this=this@entry=0x55aee270, event=...)
at ../src/common/wincmn.cpp:2828
#21 0x76647f3f in wxFrame::SendIdleEvents(wxIdleEvent&) 
(this=0x55aee270, event=...) at ../src/gtk/frame.cpp:249
#22 0x766890bd in wxAppBase::ProcessIdle() (this=) at 
../src/common/appcmn.cpp:375
#23 0x765af599 in wxApp::DoIdle() (this=0x55a82830) at 
../src/gtk/app.cpp:159
#24 0x765af693 in wxapp_idle_callback(gpointer) () at 
../src/gtk/app.cpp:107
#25 0x7392cdd5 in g_main_dispatch (context=0x55aad2b0) at 
../../../../glib/gmain.c:3142
#26 0x7392cdd5 

Bug#890211: [Pkg-fonts-devel] Bug#890211: fonts-noto-hinted: Certain font characters crash Emacs 25

[ಚಿರಾಗ್ ನಟರಾಜ್]

Hi Jonas,

On Mon, Feb 12, 2018 at 09:53:11AM +0100, Jonas Smedegaard wrote:
> Hi Chiraag,
> 
> Quoting Chiraag Nataraj (2018-02-12 02:00:06)
> > I went to open mpc in Emacs, and my artists (and song titles) are in 
> > multiple languages, including Kannada (the font for which I found this 
> > problem). A very specific character (ಕು) caused Emacs to crash. This 
> > was reproducible multiple times using both the GTK+ and Lucid builds 
> > of Emacs 25.
> > 
> > I uninstalled the package, which prevented the crash (that is, other 
> > fonts - e.g. the ones provided by fonts-knda - do not have this 
> > problem and do not cause Emacs to crash).
> > 
> > I can provide more information if needed.
> 
> Interesting!  I will make sure to pass this upstream to the developers 
> of Noto.

Great, thanks!

> 
> Please also file a separate bugreport against emacs, as I am sure they 
> would love to know about the crashing bug on their side (and I don't use 
> emacs myself so cannot sensibly report that on my own).
>

Yup, I'll file a report with them as well.

> 
>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private

- Chiraag

-- 
ಚಿರಾಗ್ ನಟರಾಜ್
Graduate Student at Brown University
Email: chiraag.nata...@gmail.com
Phone: 610-350-6329
Website: http://chiraag.nataraj.us


signature.asc
Description: PGP signature

Bug#644912:

[Adam Goode]

This should be fixed upstream. See
https://github.com/lathiat/nss-mdns/blob/master/NEWS.md

Please update this in Debian, and file bugs if there are problems:
https://github.com/lathiat/nss-mdns/issues/new


Thank you!

Bug#889968: RFS: inotify-tools/3.14-4

[KAction]

[2018-02-12 13:07] Sean Whitton 
> > Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe, you
> > could try again?
> 
> Still FTBFSs.  Log attached.
> 
> I suspect that the debomatic sid chroot is out-of-date.

Stange. Just did 'sbuild-update -udcar', and still fails to reproduce.
I have same version of build-essential, by the way.

Added debomatic admin into CC, maybe he has any opinion about situation.
If not, I could remove sanitize support, although I am not so happy with
it. Or maybe you could tar.gz your chroot and upload somewhere?

Bug#882159: Tim, your recent order 192014 Pmp2

[Timothy Merk]

I did my 1 response before 11:59 pm for the 50 dollar certificate/no
response, what now??

On Nov 27, 2017 1:16 PM, "Amazon FinalNotice"  wrote:

> Notice for Tim
>
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hello, Joachim Wiedorn schrob: > Hello Jan, FYI: >  original message
>  > From: e...@users.sourceforge.net > Date: Sun, 26 Nov 2017 21:55:28
> +0100 > To: Joachim Wiedorn , cont...@bugs.debian.org, >
> 882...@bugs.debian.org > > can the reporter maybe test the current
> snapshot? it should fix the issue. > http://duply.net/wiki/index.
> php/Duply-code#Latest_Development_Snapshot The "2.0.4dev" version I
> downloaded just now from http://duply.net/tmp/duply.sh works for me,
> outputs times like | --- Finished state OK at 19:34:48.724 - Runtime
> 00:00:00.075 --- and takes the "date_fix %s%N" branch (verified via debug
> printf). The diff looks good to me as well. Thanks a lot for the quick fix!
> I noticed two unrelated minor oddities: 1) On the first run (per profile)
> with the new version, duply would re-sync all the metadata. That's because
> of the bugfix for #117, which moved the metadata location from
> "$ARCH_DIR/duply_$profile" to "$ARCH_DIR/$profile". That leaves around the
> old, now-useless metadata folder. Not a big deal, but maybe it would have
> been better to adjust the comment to match the code instead of the other
> way around? 2) In line 2172, | # for sec�rity reasons, we url_encode
> username to protect special chars there's some (for me undisplayable)
> unicode (%EF%BF%BD) instead of the 'u' in "security". Funny, given the
> context. :D HTH and thanks again, Jan

Bug#882159: Tim, your recent order 304578 Ptfh

[Timothy Merk]

I did my 1 click as asked: I didn't get a response, what now??

On Nov 27, 2017 1:16 PM, "Amazon FinalNotice"  wrote:

> Notice for Tim
>
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hello, Joachim Wiedorn schrob: > Hello Jan, FYI: >  original message
>  > From: e...@users.sourceforge.net > Date: Sun, 26 Nov 2017 21:55:28
> +0100 > To: Joachim Wiedorn , cont...@bugs.debian.org, >
> 882...@bugs.debian.org > > can the reporter maybe test the current
> snapshot? it should fix the issue. > http://duply.net/wiki/index.
> php/Duply-code#Latest_Development_Snapshot The "2.0.4dev" version I
> downloaded just now from http://duply.net/tmp/duply.sh works for me,
> outputs times like | --- Finished state OK at 19:34:48.724 - Runtime
> 00:00:00.075 --- and takes the "date_fix %s%N" branch (verified via debug
> printf). The diff looks good to me as well. Thanks a lot for the quick fix!
> I noticed two unrelated minor oddities: 1) On the first run (per profile)
> with the new version, duply would re-sync all the metadata. That's because
> of the bugfix for #117, which moved the metadata location from
> "$ARCH_DIR/duply_$profile" to "$ARCH_DIR/$profile". That leaves around the
> old, now-useless metadata folder. Not a big deal, but maybe it would have
> been better to adjust the comment to match the code instead of the other
> way around? 2) In line 2172, | # for sec�rity reasons, we url_encode
> username to protect special chars there's some (for me undisplayable)
> unicode (%EF%BF%BD) instead of the 'u' in "security". Funny, given the
> context. :D HTH and thanks again, Jan

Bug#829002: konsole: unicode / utf characters not displayed correctly

[Arthur Marsh]

Package: konsole
Version: 4:17.08.3-1
Followup-For: Bug #829002

Dear Maintainer,

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

   * What led up to the situation?

randomly seems to change with upgrading packages (latest case was with mesa 
libraries)

konsole was displaying UTF-8 correctly on the tabs and top of the window for
a while but again shows the diamond with the question mark in it for the UTF-8
characters.

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

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


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

Kernel: Linux 4.16.0-rc1 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE= (charmap=UTF-8), LANGUAGE=en_GB 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages konsole depends on:
ii  kio   5.42.0-3
ii  konsole-kpart 4:17.08.3-1
ii  libc6 2.26-6
ii  libkf5completion5 5.42.0-2
ii  libkf5configcore5 5.42.0-2
ii  libkf5configgui5  5.42.0-2
ii  libkf5configwidgets5  5.42.0-2
ii  libkf5coreaddons5 5.42.0-2
ii  libkf5crash5  5.42.0-2
ii  libkf5dbusaddons5 5.42.0-2
ii  libkf5i18n5   5.42.0-2
ii  libkf5iconthemes5 5.42.0-2
ii  libkf5kiowidgets5 5.42.0-3
ii  libkf5notifyconfig5   5.42.0-2
ii  libkf5widgetsaddons5  5.42.1-2
ii  libkf5windowsystem5   5.42.0-2
ii  libkf5xmlgui5 5.42.0-2
ii  libqt5core5a  5.9.2+dfsg-10
ii  libqt5gui55.9.2+dfsg-10
ii  libqt5widgets55.9.2+dfsg-10
ii  libstdc++68-20180207-2

konsole recommends no packages.

konsole suggests no packages.

-- no debconf information

Bug#888917: ocrmypdf fails to run it's testsuite

[Sean Whitton]

control: retitle -1 Test suite failures

Hello James,

On Fri, Feb 02 2018, James R. Barlow wrote:

> Do you think you could take a few minutes to identify which test is
> taking this long and report it? This may be an upstream bug, if some
> input triggers an infinite loop.

I ran the test suite on one of Debian's machines, in an up-to-date
Debian unstable chroot.  It took 100 minutes and there were many
failures.  Some of the test failed due to timeouts, and some of them
failed for other reasons.  I'm attaching the full log.

I see you have released 5.6.0, but from the release notes it seems
likely there would be the same failures.

Please let me know if you still need me to run individual tests and see
how long they take.

> I have my suspicions. My guess is that:
>
> pytest tests/test_qpdf.py # will never finish
>
> and
>
> pytest -n0 tests/test_qpdf.py # will fail in 15 seconds
>
> If so, you might have qpdf < 7.0.0 and upgrading to qpdf >= 7.0.0 will
> fix it.

We have qpdf 7.1.1 in Debian unstable right now, so this can't be it.

-- 
Sean Whitton


ocrmypdf_5.5_tests.log
Description: Binary data


signature.asc
Description: PGP signature

Bug#890290: rmysql: Please build-depend on default-libmysqlclient-dev, not libmariadb-dev

[Dirk Eddelbuettel]

On 12 February 2018 at 17:53, Steve Langasek wrote:
| > Coincidentally, doesn't Ubuntu also default to MariaDB?  Who doesn't,
| > these days?
| 
| No, Ubuntu defaults to MySQL.

I mostly deploy on Ubuntu too (eg at work) and had issues with MySQL. I tend
to just build R package of the CRAN repo though.

Luckily, the code takes either one ...

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#890290: rmysql: Please build-depend on default-libmysqlclient-dev, not libmariadb-dev

[Steve Langasek]

On Mon, Feb 12, 2018 at 07:37:47PM -0600, Dirk Eddelbuettel wrote:

> On 12 February 2018 at 16:22, Steve Langasek wrote:
> | Package: rmysql
> | Version: 0.10.13-1
> | Severity: wishlist
> | Tags: patch
> | User: ubuntu-de...@lists.ubuntu.com
> | Usertags: origin-ubuntu bionic ubuntu-patch

> | Hi Dirk,

> | As discussed at
> | ,
> | packages in Debian should build-depend on default-libmysqlclient-dev, not
> | directly on either libmariadb-dev or libmysqlclient-dev.  Part of the
> | reasoning for this is to allow downstreams to make different decisions about
> | their "supported" implementations of MySQL.

> | The attached patch which implements this also fixes a build failure of
> | rmysql in Ubuntu, which appears to be an incompatibility between rmysql and
> | mariadb-connector-c version 3.0.3.  Since mariadb *is* the default mysql in
> | Debian, this won't help for any build failure there, but nevertheless
> | appears to be a correct change.

> Done!

> Coincidentally, doesn't Ubuntu also default to MariaDB?  Who doesn't,
> these days?

No, Ubuntu defaults to MySQL.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#890290: rmysql: Please build-depend on default-libmysqlclient-dev, not libmariadb-dev

[Dirk Eddelbuettel]

On 12 February 2018 at 16:22, Steve Langasek wrote:
| Package: rmysql
| Version: 0.10.13-1
| Severity: wishlist
| Tags: patch
| User: ubuntu-de...@lists.ubuntu.com
| Usertags: origin-ubuntu bionic ubuntu-patch
| 
| Hi Dirk,
| 
| As discussed at
| ,
| packages in Debian should build-depend on default-libmysqlclient-dev, not
| directly on either libmariadb-dev or libmysqlclient-dev.  Part of the
| reasoning for this is to allow downstreams to make different decisions about
| their "supported" implementations of MySQL.
| 
| The attached patch which implements this also fixes a build failure of
| rmysql in Ubuntu, which appears to be an incompatibility between rmysql and
| mariadb-connector-c version 3.0.3.  Since mariadb *is* the default mysql in
| Debian, this won't help for any build failure there, but nevertheless
| appears to be a correct change.

Done!

Coincidentally, doesn't Ubuntu also default to MariaDB?  Who doesn't, these 
days?

Cheers, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#890231: sagemath should use gdb, not gdb-python2, to be removed for buster

[Ximin Luo]

Ah, understood regarding gdb-python3.

sagemath uses cysignals-CSI from the cysignals-tools package to print out a 
more detailed backtrace containing native, cython and python code, when tests 
fail. 

cysignals-CSI starts gdb and writes the contents of cysignals-CSI-helper.py [1] 
into gdb. That script does things like "from Cython.Debugger import libpython, 
libcython". If gdb (instead of gdb-python2) is used then this fails with an 
error like:

Traceback (most recent call last):
  File "", line 26, in 
ModuleNotFoundError: No module named 'Cython'
Error while executing Python code.

because currently we only install cython for python2 when building sagemath. 
So, gdb's libpython3 can't find the Cython module.

After replacing gdb with gdb-python2 I get a nice Cython backtrace instead.

X

[1] The Debian package installs this file into 
/usr/lib/python3/dist-packages/cysignals_gdb/cysignals-CSI-helper.py but that 
is a Debian-specific innovation by the package maintainer that is slightly 
misleading; the file is just meant to be read into gdb rather than imported in 
a python program.

Matthias Klose:
> On 12.02.2018 15:41, Ximin Luo wrote:
>> Understood, but the entirety of sagemath is python2 at the moment and 
>> doesn't support python3 (upstream is working on it).
>>
>> What's the timeframe for removal of gdb-python2 and will there be a 
>> gdb-python3 alternative?
> 
> gdb is built using python3.  So maybe there is a misunderstanding, but how 
> does
> sagemath use python for debugging? Does it add it's own pretty printers so 
> that
> it needs python2? How is the gdb usage related to Python2?
> 


-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Ben Hutchings]

Control: tag -1 - moreinfo

On Mon, 2018-02-12 at 22:24 +0100, Gunnar Thorburn wrote:
> Hi,
> 
> Creating this file with COMPRESS=xz worked fine
> /etc/initramfs-tools/conf.d/compress
> 
> Obviously, with xz there is plenty of space left. There was a little
> warning though (see below).
> 
> Generating kernel u-boot image... done.
> Flashing kernel (using 2050440/2097152 bytes)... done.
> Flashing initramfs (using 2870792/4194304 bytes)... done.
> W: APT had planned for dpkg to do more than it reported back (0 vs 7).
>Affected packages: flash-kernel:armel initramfs-tools:armel
> 
> 
> Yes, this system has been upgraded several time. I think your web page
> even said that that is the correct/only way to do it.
> 
> I guess installing Stretch does COMPRESS=xz on its own.
> 
> Thank you so much. My problem is now solved. But perhaps xz could be
> part of the upgrade process.

It seems to me that there are two bugs:

1. flash-kernel gave a useless hint to use MODULES=dep, when that was
already the current configuration.

2. It didn't give the useful hint to use COMPRESS=xz, or make that
configuration change itself.

Now that I think about it, initramfs-tools does allow other packages to
override the configuration for mkinitramfs through shell scripts in
/usr/share/initramfs-tools/conf-hooks.d.  This seems like a good reason
to do that.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



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

Bug#890290: rmysql: Please build-depend on default-libmysqlclient-dev, not libmariadb-dev

[Steve Langasek]

Package: rmysql
Version: 0.10.13-1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Hi Dirk,

As discussed at
,
packages in Debian should build-depend on default-libmysqlclient-dev, not
directly on either libmariadb-dev or libmysqlclient-dev.  Part of the
reasoning for this is to allow downstreams to make different decisions about
their "supported" implementations of MySQL.

The attached patch which implements this also fixes a build failure of
rmysql in Ubuntu, which appears to be an incompatibility between rmysql and
mariadb-connector-c version 3.0.3.  Since mariadb *is* the default mysql in
Debian, this won't help for any build failure there, but nevertheless
appears to be a correct change.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -u rmysql-0.10.13/debian/control rmysql-0.10.13/debian/control
--- rmysql-0.10.13/debian/control
+++ rmysql-0.10.13/debian/control
@@ -2,8 +2,8 @@
 Section: gnu-r
 Priority: optional
 Maintainer: Dirk Eddelbuettel 
-Build-Depends: debhelper (>= 7.0.0), cdbs, r-base-dev (>= 3.4.1), 
libmariadb-dev, r-cran-dbi (>= 0.4), r-cran-viridislite
+Build-Depends: debhelper (>= 7.0.0), cdbs, r-base-dev (>= 3.4.1), 
default-libmysqlclient-dev, r-cran-dbi (>= 0.4), r-cran-viridislite
 Standards-Version: 4.0.0
 Homepage: https://github.com/rstats-db/RMySQL
 

Bug#890288: mbedtls: CVE-2018-0487 - Risk of remote code execution when verifying RSASSA-PSS signatures

[James Cowgill]

Source: mbedtls
Version: 2.1.2-1
Severity: grave
Tags: security

https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2018-01

Vulnerability
When RSASSA-PSS signature verification is enabled, sending a maliciously
constructed certificate chain can be used to cause a buffer overflow on
the peer's stack, potentially leading to crash or remote code execution.
This can be triggered remotely from either side in both TLS and DTLS.

RSASSA-PSS is the part of PKCS #1 v2.1 standard and can be enabled by
the compile time option MBEDTLS_PKCS1_V21 in config.h. If
MBEDTLS_PKCS1_V21 is disabled when compiling the library, then the
vulnerability is not present. RSASSA-PSS signatures are enabled in the
default configuration.

Impact
Depending on the platform, an attack exploiting this vulnerability could
lead to an application crash or remote code execution.

Resolution
Affected users should upgrade to Mbed TLS 1.3.22, Mbed TLS 2.1.10 or
Mbed TLS 2.7.0.

Workaround
Users should wherever possible upgrade to the newer version of Mbed TLS.
Where this is not practical, users should consider if disabling the
option MBEDTLS_PKCS1_V21 in the Mbed TLS configuration is practical for
their application. Disabling RSASSA-PSS signatures in the verification
profile at runtime is not a sufficient countermeasure.



signature.asc
Description: OpenPGP digital signature

Bug#890289: bibledit: embeds mbedtls - vulnerable to CVE-2017-2784, CVE-2017-14032, CVE-2018-0487, CVE-2018-0488

[James Cowgill]

Source: bibledit
Version: 5.0.331-1
Severity: grave
Tags: security

Hi,

I notice bibledit embeds mbed TLS 2.2.1. The embedded version is
vulnerable to at least these CVEs (based on the version number and
assuming they have not been manually patched):
 CVE-2017-2784
 CVE-2017-14032
 CVE-2018-0487
 CVE-2018-0488

[disclaimer: the mbedtls package is still vulnerable to the last two,
but I am working on fixing those]

I see you have overridden lintian which warns you about this:
> # For just now the mbed TLS library is included.
> # When using the system-provided libmbedtls, there currently is a 
> segmentation fault.
> # Pending investigation of this fault, temporarily include mbed TLS.
> # Here is the link to the issue: 
> https://github.com/bibledit/bibledit/issues/499
> # By the way, isn't it called "mbed" TLS, obviously intended to be "embedded"?
> # So Bibledit is doing that right now, it "embeds" mbed TLS.
> bibledit: embedded-library usr/bin/bibledit: mbedtls

"mbed" is the brand name ARM uses for its IOT operating system (of which
mbedtls is a component) and therefore is derived from "embedded systems".

IMO embedding a security library is unacceptable and the package should
not be in a stable release in its current state.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#890287: mbedtls: CVE-2018-0488 - Risk of remote code execution when truncated HMAC is enabled

[James Cowgill]

Source: mbedtls
Version: 2.1.2-1
Severity: grave
Tags: security

https://tls.mbed.org/tech-updates/security-advisories/mbedtls-security-advisory-2018-01

Vulnerability
When the truncated HMAC extension is enabled and CBC is used, sending a
malicious application packet can be used to selectively corrupt 6 bytes
on the peer's heap, potentially leading to a crash or remote code
execution. This can be triggered remotely from either side in both TLS
and DTLS.

If the truncated HMAC extension, which can be set by the compile time
option MBEDTLS_SSL_TRUNCATED_HMAC in config.h, is disabled when
compiling the library, then the vulnerability is not present. The
truncated HMAC extension is enabled in the default configuration.

The vulnerability is only present if
* The compile-time option MBEDTLS_SSL_TRUNCATED_HMAC is set in config.h.
  (It is set by default) AND
* The truncated HMAC extension is explicitly offered by calling
  mbedtls_ssl_conf_truncated_hmac(). (It is not offered by default)

Impact
Depending on the platform, an attack exploiting this vulnerability could
lead to an application crash or allow remote code execution.

Resolution
Affected users should upgrade to Mbed TLS 1.3.22, Mbed TLS 2.1.10 or
Mbed TLS 2.7.0.

Workaround
Users should wherever possible upgrade to the newer version of Mbed TLS.
Where this is not practical, users should consider disabling the
truncated HMAC extension by removing any call to
mbedtls_ssl_conf_truncated_hmac() in their application, and the option
MBEDTLS_SSL_TRUNCATED_HMAC in the Mbed TLS configuration is practical
for their application.



signature.asc
Description: OpenPGP digital signature

Bug#890286: rrdcached: "gmetad RRD_update [...] rrdcached: Permission denied" if limited socket specified first

[Chad W Seys]

Package: rrdcached
Version: 1.6.0-1+b2
Severity: normal

Hi,
  This is probably an upstream bug, with a workaround in Stretch.
  Upon upgrading from Jessie to Stretch ganglia gmetad could no longer use 
rrdcached to
write rrds .
  Here's an example line from /var/log/messages:
gangle /usr/sbin/gmetad[3554]: RRD_update 
(/var/lib/ganglia/rrds/GLOW-CMS/s17n08.hep.wisc.edu/cpu_speed.rrd): rrdcached: 
Permission denied.

  After fiddling with permissions on the socket, file, etc I found that 
changing the command line order
of the sockets works around the problem.  It appears as though the limited 
socket needs to be specified
first.  

# WORKS:
/usr/bin/rrdcached -w 3600 -f 7200 -j /var/lib/rrdcached/journal/ \
-s ganglia -m 664 -l unix:/var/run/rrdcached.sock \
-s www-data -m 777 -P FLUSH,STATS,HELP,FETCH -l 
unix:/var/run/rrdcached.limited.sock \
-b /var/lib/ganglia/rrds -B -p /var/run/rrdcached.pid

# DOES NOT WORK:
/usr/bin/rrdcached -w 3600 -f 7200 -j /var/lib/rrdcached/journal/ \
-s www-data -m 777 -P FLUSH,STATS,HELP,FETCH -l 
unix:/var/run/rrdcached.limited.sock \
-s ganglia -m 664 -l unix:/var/run/rrdcached.sock \
-b /var/lib/ganglia/rrds -B -p /var/run/rrdcached.pid

  Since -P flags in the limited socket can only be added to 
/etc/defaults/rrdcache BASE_OPTIONS,
the way to work around this in Stretch is to place BASE_OPTIONS in 
/etc/init.d/rrdcached after
the socket options like this:

RRDCACHED_OPTIONS="\
  # former location of $BASE_OPTIONS
  ${NETWORK_OPTIONS} \
  ${WRITE_TIMEOUT:+-w ${WRITE_TIMEOUT}} \
  ${WRITE_JITTER:+-z ${WRITE_JITTER}} \
  ${WRITE_THREADS:+-t ${WRITE_THREADS}} \
  ${BASE_PATH:+-b ${BASE_PATH}} \
  ${JOURNAL_PATH:+-j ${JOURNAL_PATH}} \
  ${DAEMON_GROUP:+-G ${DAEMON_GROUP}} \
  ${DAEMON_USER:+-U ${DAEMON_USER}} \
  -p ${PIDFILE} \
  ${SOCKFILE:+${SOCKGROUP:+-s ${SOCKGROUP}} ${SOCKMODE:+-m ${SOCKMODE}} -l 
unix:${SOCKFILE}} \
  ${BASE_OPTIONS}
"

(Also notice addition of FETCH on limited socket. Without this ganglia-web 
cannot draw all the graphs.)

Thanks!
C.


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

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

Versions of packages rrdcached depends on:
ii  libc62.24-11+deb9u1
ii  libcairo21.14.8-1
ii  libdbi1  0.9.0-4+deb9u1
ii  libglib2.0-0 2.50.3-2
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpng16-16  1.6.28-1
ii  librrd8  1.7.0-1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2

rrdcached recommends no packages.

rrdcached suggests no packages.

-- Configuration Files:
/etc/default/rrdcached changed:
BASE_OPTIONS="-f 7200 -s www-data -m 777 -P FLUSH,STATS,HELP,FETCH -l 
unix:/var/run/rrdcached.limited.sock"

-- no debconf information

Bug#888786: pound: CVE-2016-10711

[Markus Koschany]

Control: tags -1 patch

Dear maintainer,

please find attached a patch to fix CVE-2016-10711. This is simply the
security relevant diff between version 2.7 and 2.8a.

Regards,

Markus
diff -Nru pound-2.7/debian/changelog pound-2.7/debian/changelog
--- pound-2.7/debian/changelog  2017-02-19 15:13:02.0 +0100
+++ pound-2.7/debian/changelog  2018-02-12 23:57:49.0 +0100
@@ -1,3 +1,11 @@
+pound (2.7-1.4) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CVE-2016-10711: request smuggling via crafted headers.
+(Closes: #888786)
+
+ -- Markus Koschany   Mon, 12 Feb 2018 23:57:49 +0100
+
 pound (2.7-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pound-2.7/debian/patches/CVE-2016-10711.patch 
pound-2.7/debian/patches/CVE-2016-10711.patch
--- pound-2.7/debian/patches/CVE-2016-10711.patch   1970-01-01 
01:00:00.0 +0100
+++ pound-2.7/debian/patches/CVE-2016-10711.patch   2018-02-12 
23:57:49.0 +0100
@@ -0,0 +1,218 @@
+From: Markus Koschany 
+Date: Mon, 12 Feb 2018 23:56:27 +0100
+Subject: CVE-2016-10711
+
+This patch is based on the diff between the stable 2.7 version and 2.8a. Only
+the security relevant part was backported.
+---
+ http.c | 128 -
+ 1 file changed, 88 insertions(+), 40 deletions(-)
+
+diff --git a/http.c b/http.c
+index 749b279..f83aa73 100644
+--- a/http.c
 b/http.c
+@@ -31,7 +31,8 @@
+ static char *h500 = "500 Internal Server Error",
+ *h501 = "501 Not Implemented",
+ *h503 = "503 Service Unavailable",
+-*h414 = "414 Request URI too long";
++*h414 = "414 Request URI too long",
++*h400 = "Bad Request";
+ 
+ static char *err_response = "HTTP/1.0 %s\r\nContent-Type: 
text/html\r\nContent-Length: %d\r\nExpires: now\r\nPragma: 
no-cache\r\nCache-control: no-cache,no-store\r\n\r\n%s";
+ 
+@@ -83,7 +84,7 @@ redirect_reply(BIO *const c, const char *url, const int code)
+ safe_url, safe_url);
+ snprintf(rep, sizeof(rep),
+ "HTTP/1.0 %d %s\r\nLocation: %s\r\nContent-Type: 
text/html\r\nContent-Length: %d\r\n\r\n",
+-code, code_msg, safe_url, strlen(cont));
++code, code_msg, safe_url, (int)strlen(cont));
+ BIO_write(c, rep, strlen(rep));
+ BIO_write(c, cont, strlen(cont));
+ BIO_flush(c);
+@@ -126,11 +127,11 @@ static int
+ get_line(BIO *const in, char *const buf, const int bufsize)
+ {
+ chartmp;
+-int i, n_read;
++int i, n_read, seen_cr;
+ 
+ memset(buf, 0, bufsize);
+-for(n_read = 0;;)
+-switch(BIO_gets(in, buf + n_read, bufsize - n_read - 1)) {
++for(i = 0, seen_cr = 0; i < bufsize - 1; i++)
++switch(BIO_read(in, , 1)) {
+ case -2:
+ /* BIO_gets not implemented */
+ return -1;
+@@ -138,24 +139,49 @@ get_line(BIO *const in, char *const buf, const int 
bufsize)
+ case -1:
+ return 1;
+ default:
+-for(i = n_read; i < bufsize && buf[i]; i++)
+-if(buf[i] == '\n' || buf[i] == '\r') {
+-buf[i] = '\0';
++if(seen_cr)
++if(tmp != '\n') {
++/* we have CR not followed by NL */
++do {
++if(BIO_read(in, , 1) < 0)
++return 1;
++} while(tmp != '\n');
++return 1;
++} else {
++buf[i - 1] = '\0';
+ return 0;
+ }
+-if(i < bufsize) {
+-n_read = i;
++
++if(!iscntrl(tmp) || tmp == '\t') {
++buf[i] = tmp;
++continue;
++}
++
++if(tmp == '\r') {
++seen_cr = 1;
+ continue;
+ }
+-logmsg(LOG_NOTICE, "(%lx) line too long: %s", pthread_self(), 
buf);
+-/* skip rest of "line" */
+-tmp = '\0';
+-while(tmp != '\n')
+-if(BIO_read(in, , 1) != 1)
++
++if(tmp == '\n') {
++/* line ends in NL only (no CR) */
++buf[i] = 0;
++return 0;
++}
++
++/* all other control characters cause an error */
++do {
++if(BIO_read(in, , 1) < 0)
+ return 1;
+-break;
++} while(tmp != '\n');
++return 1;
+ }
+-return 0;
++
++/* line too long */
++do {
++if(BIO_read(in, , 1) < 0)
++return 1;
++} while(tmp != '\n');
++return 1;
+ }
+ 
+ /*
+@@ -393,22 +419,16 @@ get_headers(BIO *const in, BIO *const cl, const LISTENER 
*lstn)
+ 
+ /* HTTP/1.1 allows leading CRLF */
+ memset(buf, 0, MAXBUF);
+-while((res = BIO_gets(in, buf, MAXBUF - 1)) > 0) {
+-has_eol = 

Bug#886161: delayed NMU of auto-complete-el/1.5.1-0.1

[Hilko Bengen]

Control: Tag -1 patch

Hi Takaya,

I have prepared a package based on the current upstream version 1.5.1 of
auto-complete and uploaded to DELAYED/5. I have gone ahead and fixed
most of the outstanding bugs and modernized the package: It is now based
on dh-elpa.

Please feel free to cancel or reschedule as you see fit.

What do you think about maintaining the auto-complete-el as part of the
Debian Emacs addons team?

Cheers,
-Hilko


auto-complete-el_1.5.1-0.1_source.changes
Description: Binary data

Bug#884061: This bug severely affects anybody using intel graphics cards from 2015

[Vagrant Cascadian]

Control: fixed 884061 4.9.80-1

On 2018-01-22, Marga Manterola wrote:
> This bug can make machines that include the affected graphics card
> completely unusable.
...
> Any chance we can get a new kernel without that commit?

I can confirm 4.9.80-1 from stretch-proposed-updates fixes the issue for
me. I've been running it for several days without issue.

It appears 4.9.80-2 is out now as well.

Not sure how long till the next point release, but at least one can use
stretch-proposed-updates for now.

Thanks to everyone who helped resolve the issue!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#890115: xl2tpd: uncompatible configure with ppp

[Samir Hussain]

I noticed that in your /etc/ppp/opitions that you have +chap

Is that intentional? What happens if you remove that?

If you are are continuing to have problems, can you please provide the
error message you get. Also, did enabling debugging in your
/etc/ppp/options give you any useful information?

Bug#890115: xl2tpd: uncompatible configure with ppp

[Samir Hussain]

Hello,
  I noticed that in your /etc/ppp/opitions that you have +chap

  Is that intentional? What happens if you remove that?

  If you are are continuing to have problems, can you please provide the
error message you get. Also did enabling debugging in your
/etc/ppp/options give you any useful information?


Samir

Bug#890284: RFS: textedit.app/5.0-2 [RC]

[Yavor Doganov]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "textedit.app".

 * Package name: textedit.app
   Version : 5.0-2
   Upstream Author : Ali Ozer ,
 other Apple employees,
 Eric Wasylishen 
 * URL : https://github.com/ericwa/TextEdit
 * License : Apple permissive license
   Section : gnustep

It builds this binary package:

textedit.app - Text editor for GNUstep

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

  https://mentors.debian.net/package/textedit.app

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

  dget -x 
https://mentors.debian.net/debian/pool/main/t/textedit.app/textedit.app_5.0-2.dsc

Or checkout the Git repository:

  https://salsa.debian.org/gnustep-team/textedit.app

Changes since the last upload:

  * debian/maintscript: New file, replace Resources directory with a
symlink (Closes: #890070).
  * debian/patches/migrate-defaults.patch: New; fix exception with
existing defaults when the PlainTextEncoding key is set to the old
(4.0) value type.
  * debian/patches/ftbfs-hurd.patch: New; fix FTBFS on GNU/Hurd by
removing unnecessary string truncation.
  * debian/patches/fix-info-plist: Add patch description.
  * debian/patches/series: Update.
  * debian/menu: Get rid as per Policy requirement.
  * debian/control (Uploaders): Add myself as agreed with Gürkan.
(Build-Depends): Add icnsutils for extracting the .png icon.  Require
gnustep-make >= 2.7.0-3 for the optim variable definition.
(Vcs-Git, Vcs-Browser): New fields.
(Conflicts, Replaces): Remove; ancient.
  * debian/rules: Enable all hardening.  Remove optim definition.
(override_dh_auto_build): Extract a .png icon from the .icns for the
.desktop file.  Replace $(MAKE) with dh_auto_build so that buildds'
configuration for parallel building is taken into account.
  * debian/install: Install the .png icon.
  * debian/clean: New file; delete the generated icon.
  * debian/TextEdit.desktop: Use the new icon; Edit.tiff doesn't exist.
Add Keywords field and Bulgarian translations.  Remove Version field
as it makes the file invalid.
  * debian/copyright: Convert to format 1.0, add full text of Apple's new
license, add Debian packaging copyright holders.
  * debian/README.Debian: New file, document workaround for setting plain
text format as default.

Bug#890285: doxygen: Please drop LLVM build-dependency on powerpcspe

[John Paul Adrian Glaubitz]

Source: doxygen
Version: 1.8.13-9
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpcspe

Hi!

Since LLVM currently doesn't build on powerpcspe, we should drop
it as a build dependency from doxygen the architecture.

Thus:

diff -Nru old/doxygen-1.8.13/debian/control new/doxygen-1.8.13/debian/control
--- old/doxygen-1.8.13/debian/control   2017-08-31 13:36:21.0 +0200
+++ new/doxygen-1.8.13/debian/control   2018-02-12 23:18:32.403346518 +0100
@@ -12,8 +12,8 @@
   cmake,
   yui-compressor,
   ruby-compass,
-  llvm-5.0-dev [alpha amd64 armel armhf arm64 i386 mips mipsel mips64el 
powerpc powerpcspe ppc64 ppc64el s390x sparc64],
-  libclang-5.0-dev [alpha amd64 armel armhf arm64 i386 mips mipsel mips64el 
powerpc powerpcspe ppc64 ppc64el s390x sparc64]
+  llvm-5.0-dev [alpha amd64 armel armhf arm64 i386 mips mipsel mips64el 
powerpc ppc64 ppc64el s390x sparc64],
+  libclang-5.0-dev [alpha amd64 armel armhf arm64 i386 mips mipsel mips64el 
powerpc ppc64 ppc64el s390x sparc64]
 Build-Depends-Indep: texlive-fonts-recommended,
   texlive-generic-recommended,
   texlive-latex-extra,

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
diff -Nru old/doxygen-1.8.13/debian/control new/doxygen-1.8.13/debian/control
--- old/doxygen-1.8.13/debian/control   2017-08-31 13:36:21.0 +0200
+++ new/doxygen-1.8.13/debian/control   2018-02-12 23:18:32.403346518 +0100
@@ -12,8 +12,8 @@
   cmake,
   yui-compressor,
   ruby-compass,
-  llvm-5.0-dev [alpha amd64 armel armhf arm64 i386 mips mipsel mips64el 
powerpc powerpcspe ppc64 ppc64el s390x sparc64],
-  libclang-5.0-dev [alpha amd64 armel armhf arm64 i386 mips mipsel mips64el 
powerpc powerpcspe ppc64 ppc64el s390x sparc64]
+  llvm-5.0-dev [alpha amd64 armel armhf arm64 i386 mips mipsel mips64el 
powerpc ppc64 ppc64el s390x sparc64],
+  libclang-5.0-dev [alpha amd64 armel armhf arm64 i386 mips mipsel mips64el 
powerpc ppc64 ppc64el s390x sparc64]
 Build-Depends-Indep: texlive-fonts-recommended,
   texlive-generic-recommended,
   texlive-latex-extra,

Bug#888985: [pkg-go] Bug#888985: Bug#888985: RFS: irtt/0.9-1 [ITP] (#888985)

[Pete Heist]

> On Feb 12, 2018, at 10:22 PM, Michael Stapelberg  
> wrote:
> 
> Would you like me to sponsor the upload of irtt now?

Yes, if you would. Thanks!

Pete

Bug#890280: ufo2ft: please make the output reproducible

[Chris Lamb]

forwarded 890280 https://github.com/googlei18n/ufo2ft/pull/219
thanks

I've forwarded this upstream here:

  https://github.com/googlei18n/ufo2ft/pull/219


Regards,

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

Bug#890283: pulseaudio-dlna: Please package newer upstream snapshot

[Sebastian Reichel]

Package: pulseaudio-dlna
Version: 0.5.3+git20170406-1
Severity: wishlist

Hi,

Please package newer upstream release, which introduces proper
chromecast volume control.

Thanks,

-- Sebastian

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

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

Versions of packages pulseaudio-dlna depends on:
ii  flac   1.3.2-1
ii  lame   3.100-2
ii  opus-tools 0.1.10-1
ii  python 2.7.14-4
ii  python-chardet 3.0.4-1
ii  python-concurrent.futures  3.2.0-1
ii  python-dbus1.2.6-1
ii  python-docopt  0.6.2-1
ii  python-gi  3.26.1-2
ii  python-lxml4.1.0-1
ii  python-netifaces   0.10.4-0.1+b3
ii  python-notify2 0.3-3
ii  python-protobuf3.0.0-9.1
ii  python-psutil  5.4.2-1
ii  python-pyroute20.4.21-0.1
ii  python-requests2.18.4-1
ii  python-setproctitle1.1.10-1+b1
ii  python-setuptools  38.4.0-1
ii  python-zeroconf0.19.1-1
ii  python2.7  2.7.14-6
ii  sox14.4.2-3
ii  vorbis-tools   1.4.0-10.1

pulseaudio-dlna recommends no packages.

Versions of packages pulseaudio-dlna suggests:
ii  ffmpeg   7:3.4.1-1+b2
pn  gir1.2-rsvg-2.0  
pn  gir1.2-rsvg-3.0  
pn  libav-tools  
ii  python-cairo 1.15.4-2
pn  python-netaddr   

-- no debconf information

Bug#890282: getmail: please ship with shebang line of #!/usr/bin/env python2

[Daniel Kahn Gillmor]

Package: getmail
Version: 5.5-2
Severity: normal

Getmail does not work with python3, and upstream has indicated that
they are not likely to port it.

According to PEP 394 [0], it should use a python2 shebang line, so
that systems can eventually switch /usr/bin/python to be supplied by
python3.

Regards,

--dkg

[0] https://www.python.org/dev/peps/pep-0394


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

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

Versions of packages getmail depends on:
ii  python  2.7.14-4

getmail recommends no packages.

getmail suggests no packages.

-- no debconf information

Bug#890281: xkbset FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: xkbset
Version: 0.5-7
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: block -1 by 438298
Control: tags 438298 + patch

xkbset fails to cross build from source, because it uses the build
architecture toolchain. dh_auto_build fixes that. Then it fails to cross
build, because it uses the build architecture strip via install. The
easiest way to fix that (deferring stripping to dh_strip) happens to
also fix #438298. The attached patch contains both fixes. Please
consider applying it. In compat 11, dh_auto_install will do.

Helmut
diff --minimal -Nru xkbset-0.5/debian/changelog xkbset-0.5/debian/changelog
--- xkbset-0.5/debian/changelog 2017-10-16 01:11:01.0 +0200
+++ xkbset-0.5/debian/changelog 2018-02-12 22:38:40.0 +0100
@@ -1,3 +1,11 @@
+xkbset (0.5-7.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass CC to make. (Closes: #-1)
+  * Don't strip at make install time. (Closes: #438298)
+
+ -- Helmut Grohne   Mon, 12 Feb 2018 22:38:40 +0100
+
 xkbset (0.5-7) unstable; urgency=medium
 
   * Adopt package (closes: Bug#847599).
diff --minimal -Nru xkbset-0.5/debian/rules xkbset-0.5/debian/rules
--- xkbset-0.5/debian/rules 2017-02-26 17:01:37.0 +0100
+++ xkbset-0.5/debian/rules 2018-02-12 22:38:40.0 +0100
@@ -16,7 +16,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
-   $(MAKE)
+   dh_auto_build
touch build-stamp
 
 clean:
@@ -32,7 +32,7 @@
dh_prep
dh_installdirs
 
-   $(MAKE) install DESTDIR=$(CURDIR)/debian/xkbset
+   $(MAKE) install DESTDIR=$(CURDIR)/debian/xkbset 'INSTALL=install 
--strip-program=true'
 
 binary-indep: build install
 

Bug#890231: sagemath should use gdb, not gdb-python2, to be removed for buster

[Matthias Klose]

On 12.02.2018 15:41, Ximin Luo wrote:
> Understood, but the entirety of sagemath is python2 at the moment and doesn't 
> support python3 (upstream is working on it).
> 
> What's the timeframe for removal of gdb-python2 and will there be a 
> gdb-python3 alternative?

gdb is built using python3.  So maybe there is a misunderstanding, but how does
sagemath use python for debugging? Does it add it's own pretty printers so that
it needs python2? How is the gdb usage related to Python2?

Bug#890280: ufo2ft: please make the output reproducible

[Chris Lamb]

Source: ufo2ft
Version: 1.1.0-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], we noticed
that ufo2ft generates .otf files that are not reproducible.

For example, here is showotf output of fonts-league-spartan:

│ │ │ │ │  HEAD table (at 188)
│ │ │ │ │   Version=1
│ │ │ │ │   fontRevision=2
│ │ │ │ │ - checksumAdj=e32dbbe4
│ │ │ │ │ + checksumAdj=e3309724
│ │ │ │ │   magicNumber=5f0f3cf5 (0x5f0f3cf5, diff=0)
│ │ │ │ │   flags=3 baseline_at_0 lsb_at_0 
│ │ │ │ │   unitsPerEm=1250
│ │ │ │ │   create[0]=0
│ │ │ │ │ -  create[1]=d580d7b0
│ │ │ │ │ - File created: Tue Jul  4 05:27:12 2017
│ │ │ │ │ +  create[1]=d57f6a10
│ │ │ │ │ + File created: Mon Jul  3 03:27:12 2017

… which shows that it varies on the timezone.

Patch attached:

  --- a/Lib/ufo2ft/fontInfoData.py
  +++ b/Lib/ufo2ft/fontInfoData.py
  @@ -13,6 +13,7 @@ used externally as well.
   
   from __future__ import print_function, division, absolute_import, 
unicode_literals
   
  +import datetime
   import logging
   import math
   import time
  @@ -516,7 +517,8 @@ def intListToNum(intList, start, length):
   
   def dateStringToTimeValue(date):
   try:
  -t = time.strptime(date, "%Y/%m/%d %H:%M:%S")
  -return int(time.mktime(t))
  -except OverflowError:
  +dt = datetime.datetime.strptime(date, "%Y/%m/%d %H:%M:%S")
  +dt = dt.replace(tzinfo=datetime.timezone.utc)
  +return int(dt.timestamp())
  +except ValueError:
   return 0


 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/Lib/ufo2ft/fontInfoData.py b/Lib/ufo2ft/fontInfoData.py
index 786823a..a487c62 100644
--- a/Lib/ufo2ft/fontInfoData.py
+++ b/Lib/ufo2ft/fontInfoData.py
@@ -13,6 +13,7 @@ used externally as well.
 
 from __future__ import print_function, division, absolute_import, 
unicode_literals
 
+import datetime
 import logging
 import math
 import time
@@ -516,7 +517,8 @@ def intListToNum(intList, start, length):
 
 def dateStringToTimeValue(date):
 try:
-t = time.strptime(date, "%Y/%m/%d %H:%M:%S")
-return int(time.mktime(t))
-except OverflowError:
+dt = datetime.datetime.strptime(date, "%Y/%m/%d %H:%M:%S")
+dt = dt.replace(tzinfo=datetime.timezone.utc)
+return int(dt.timestamp())
+except ValueError:
 return 0

Bug#890279: gzip (x86) uses TEXTRELs, compiled without -fPIC?

[Marc Schiffbauer]

Package: gzip
Version: 1.6-5+b1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

   Using a PaX secured Kernel, gzip will be denied execution because it
   uses TEXTRELs which is a security problem


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

   trying to run gzip

   * What was the outcome of this action?

gzip: error while loading shared libraries: cannot make segment writable
for relocation: Permission denied

   * What outcome did you expect instead?

   working binary compiled with -fPIC

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


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

Kernel: Linux 3.14.43-hardened-r3 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE.utf8 (charmap=locale: Cannot set 
LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968), LANGUAGE=en_US.UTF-8 (charmap=locale: Cannot set LC_CTYPE to 
default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages gzip depends on:
ii  dpkg  1.18.24
ii  install-info  6.3.0.dfsg.1-1+b2
ii  libc6 2.24-11+deb9u1

gzip recommends no packages.

Versions of packages gzip suggests:
ii  less  481-2.1

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "de_DE.utf8",
LC_MONETARY = "de_DE.utf8",
LC_CTYPE = "de_DE.utf8",
LC_COLLATE = "de_DE.utf8",
LC_ADDRESS = "de_DE.utf8",
LC_TELEPHONE = "de_DE.utf8",
LC_MESSAGES = "en_US.utf8",
LC_NAME = "de_DE.utf8",
LC_MEASUREMENT = "de_DE.utf8",
LC_IDENTIFICATION = "de_DE.utf8",
LC_NUMERIC = "de_DE.utf8",
LC_PAPER = "de_DE.utf8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#883707: ace-freecell crashes on KDE desktops

[Esa Peuha]

That's very odd. Presumably a program can only cause that error message
by calling XGetImage, and freecell (like every other of these games
except taipei) can only do so from line 819 of xwin.c in build_image.
However, the only non-constant arguments to XGetImage are display and
window, and if one of those variables has an invalid value, I would
expect an error long before reaching that point. Looking at the sources,
the only obvious difference between freecell and everything else is that
freecell defaults to a window that is 640 pixels wide and 480 pixels
high, and I can just about imagine that some piece of code might treat
a window with those exact dimensions specially. That should be easy to
test; if "ace-freecell -width 700 -height 500" works when it would fail
without those arguments, and if the other games fail if you start them
with "-width 640 -height 480" then it's pretty clear this is the cause.

Bug#890278: scotch: Please add documentation

[Samuel Thibault]

Package: scotch
Version: 6.0.4.dfsg1-8
Severity: normal

Hello,

scotch 6.0.5 now includes the LaTeX source for the documentation, so
while packaging that version, please add rules to build and install it.

(cd doc/src/ptscotch && pdflatex p.tex && bibtex p && pdflatex p.tex && 
pdflatex p.tex)

(cd doc/src/scotch && pdflatex m.tex && pdflatex m.tex)

seem to be working fine.

Samuel

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

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

Versions of packages scotch depends on:
ii  libc6  2.26-4
ii  libopenmpi22.1.1-8
ii  libscotch-6.0  6.0.4.dfsg1-8
ii  zlib1g 1:1.2.8.dfsg-5

scotch recommends no packages.

scotch suggests no packages.

-- no debconf information

-- 
Samuel
***e trouve un .xls
***e passe un moment à se demander quelle version de xml c'est ça, le .xls
e: donc j'ai fait un file
 -+- #sos - on n'a pas forcément les mêmes références que tout le monde -+-

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Gunnar Thorburn]

Hi,

Creating this file with COMPRESS=xz worked fine
/etc/initramfs-tools/conf.d/compress

Obviously, with xz there is plenty of space left. There was a little
warning though (see below).

Generating kernel u-boot image... done.
Flashing kernel (using 2050440/2097152 bytes)... done.
Flashing initramfs (using 2870792/4194304 bytes)... done.
W: APT had planned for dpkg to do more than it reported back (0 vs 7).
   Affected packages: flash-kernel:armel initramfs-tools:armel


Yes, this system has been upgraded several time. I think your web page
even said that that is the correct/only way to do it.

I guess installing Stretch does COMPRESS=xz on its own.

Thank you so much. My problem is now solved. But perhaps xz could be
part of the upgrade process.

On 12 February 2018 at 22:05, Gunnar Thorburn  wrote:
> Hi Martin,
>
> I sincerely apologize for setting the wrong severity to the wrong
> package in the original report.
> (I thought the system could be in a state where it would not reboot at all)
>
> I am sorry to inform you that changing to MODULES=dep in
> initramfs.conf did not help.
> (driver-policy already had MODULES=dep).
>
> And no, I am not using LVM or RAID (just a standard ext2-partitions
> for /, /boot, /home/ and one for swap on a single SATA drive).
>
> The good thing is that the system reboots properly and seems to work
> fine with the old 3.16 kernel.
>
> There is no
> /etc/initramfs-tools/conf.d/compress
>
> I will try it out and get back.
>
> Thank you very much!
>
>
>
>
>
> On 12 February 2018 at 21:57, Martin Michlmayr  wrote:
>> Unfortunately my memory is quite bad.  I *thought* the current
>> installer configured XZ compression by default but it seems that's not
>> the case.  So the documentation on my web site is correct.
>>
>> * The installer sets MODULES=dep
>> * It has done so for a long time
>> * But you've upgraded from a really old release where this wasn't the case 
>> (I believe)
>>
>> * The installer doesn't configure XZ compression
>> * You don't need it for a normal installation
>> * If you want LVM or RAID, you have to use XZ, as per the hint at 
>> http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
>>
>> At least I *believe* that's the case.  I didn't investigate in detail.
>>
>> --
>> Martin Michlmayr
>> http://www.cyrius.com/

Bug#888985: [pkg-go] Bug#888985: RFS: irtt/0.9-1 [ITP] (#888985)

[Michael Stapelberg]

On Sun, Feb 11, 2018 at 4:04 PM, Pete Heist  wrote:

>
> On Feb 11, 2018, at 12:37 AM, Michael Stapelberg 
> wrote:
>
> On Sat, Feb 10, 2018 at 6:08 PM, Pete Heist  wrote:
>
>>
>> - I tried getting signatures working but punted because GitHub creates a
>> .tar.gz, which I signed with a .tar.gz.asc, but the build process expects a
>> .tar.xz.asc in the upstream, so lintian then warns with
>> 'orig-tarball-missing-upstream-signature'. Is there any pkg-go example
>> of signatures working with a GitHub hosted repo? Otherwise I’ll eventually
>> figure it out.
>>
>
> The process currently is a bit clunky. dh-make-golang hardcodes using xz
> (via tar J), so either you change that in dh-make-golang’s source, or you
> manually create the packaging git repository:
>
> # save GitHub .tar.gz as irtt_0.9.0.orig.tar.gz
> % mkdir irtt
> % cd irtt
> % git init
> % gbp import-orig ../irtt_0.9.0.orig.tar.gz
> % cp -r /tmp/dh-make-golang/irtt/debian .
> % git commit -a -m "Initial packaging”
>
>
>
>>
>> Let me know if anything else. Thanks!
>>
>
> It would be good to avoid copying the systemd .service file into debian/.
> I think you can instead install it with a debian/rules override. See e.g.
> https://sources.debian.org/src/forked-daapd/25.0-2/debian/rules/?hl=22#L22
>
> Let me know how you’d like to proceed regarding the signatures. It’s not a
> requirement to sign the releases for now, but note that after the initial
> upload, we don’t have the luxury of starting with a fresh repository
> anymore.
>
>
> Ok, I took the advice for the .service file (thanks, that’s smoother), and
> re-initialized the repo for the last time. :)
>
> I passed on signing for now. I modified dh-make-golang to make a .tar.gz
> (thought I might even submit a pull request with a new command line
> option), but the .tar.gz that’s created is not the same as the one GitHub
> automatically creates (different internal directory names for starters), so
> for each build it looks like I’d have to:
>

I’d recommend to use the tar.gz from GitHub for simplicity. This would
require using the workflow I described above.


> - Run gbp once to generate the .tar.gz
> - Sign it to get the .tar.gz.asc
> - Run gbp again with the .tar.gz.asc in place to see that lintian doesn’t
> complain
> - Manually upload the .tar.gz and .tar.gz.asc to GitHub
> In the interest of keeping my release process as simple as possible, I’ll
> smooth this out later when I have more time!
>
> One more thing: I switched to semantic versioning when I started
> CHANGES.md, so on ftp.upload.debian.org what was irtt_0.9-1* before is
> now irtt_0.9.0-1*, in case there are some dangling files there that should
> be cleaned up.
>

There’s no need to clean things up, the upload directory is cleaned
automatically.

Would you like me to sponsor the upload of irtt now?


>
> Thanks again!
>
> Pete
>
>


-- 
Best regards,
Michael

Bug#890277: gamin: circular build-dependency with glib2.0 on !linux-any

[Samuel Thibault]

Package: gamin
Version: 0.1.10-5
Severity: normal
Tags: patch

Hello,

gamin build-depends on glib2.0. It happens that on linux-any the glib2.0
source package build-depends on libgamin-dev.

The simplest way to avoid this circular build-dependency is to add a
stage1 profile to the gamin package build, which disables the build of
the gamin server, as the attached patch implements.

Samuel

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

Kernel: GNU-Mach 1.8+git20171101-486-dbg/Hurd-0.9
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gamin depends on:
ii  libc0.3   2.26-5
ii  libgamin0 0.1.10-5
ii  libglib2.0-0  2.54.2-5

gamin recommends no packages.

gamin suggests no packages.

-- no debconf information

-- 
Samuel Thibault 
--- debian/control.in.orig  2018-02-12 21:18:25.0 +
+++ debian/control.in   2018-02-12 21:18:27.0 +
@@ -5,7 +5,7 @@
 Uploaders: @GNOME_TEAM@
 Build-Depends: cdbs (>= 0.4.73),
debhelper( >= 5.0.37.2),
-   libglib2.0-dev,
+   libglib2.0-dev ,
gnome-pkg-tools,
python-all-dev (>= 2.3.5-11),
dh-python,
--- debian/control.orig 2018-02-12 21:18:45.0 +
+++ debian/control  2018-02-12 21:17:31.0 +
@@ -9,7 +9,7 @@
 Uploaders: Debian GNOME Maintainers 
, Emilio Pozuelo Monfort 
, Martin Pitt , Sebastian Dröge 

 Build-Depends: cdbs (>= 0.4.73),
debhelper( >= 5.0.37.2),
-   libglib2.0-dev,
+   libglib2.0-dev ,
gnome-pkg-tools,
python-all-dev (>= 2.3.5-11),
dh-python,
--- debian/rules.orig   2018-02-12 21:18:55.0 +
+++ debian/rules2018-02-12 21:18:56.0 +
@@ -18,6 +18,10 @@
 DEB_INSTALL_DOCS_ALL :=
 DEB_INSTALL_DOCS_gamin := AUTHORS NEWS README TODO
 
+ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)
+   DEB_CONFIGURE_EXTRA_FLAGS += --disable-server
+endif
+
 binary-install/python-gamin::
# force executable bit on files looking like python scripts
egrep -rlZ '^#!(.*)python' debian/python-gamin/usr/lib/ | xargs -0 
chmod a+x --

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Gunnar Thorburn]

Hi Martin,

I sincerely apologize for setting the wrong severity to the wrong
package in the original report.
(I thought the system could be in a state where it would not reboot at all)

I am sorry to inform you that changing to MODULES=dep in
initramfs.conf did not help.
(driver-policy already had MODULES=dep).

And no, I am not using LVM or RAID (just a standard ext2-partitions
for /, /boot, /home/ and one for swap on a single SATA drive).

The good thing is that the system reboots properly and seems to work
fine with the old 3.16 kernel.

There is no
/etc/initramfs-tools/conf.d/compress

I will try it out and get back.

Thank you very much!





On 12 February 2018 at 21:57, Martin Michlmayr  wrote:
> Unfortunately my memory is quite bad.  I *thought* the current
> installer configured XZ compression by default but it seems that's not
> the case.  So the documentation on my web site is correct.
>
> * The installer sets MODULES=dep
> * It has done so for a long time
> * But you've upgraded from a really old release where this wasn't the case (I 
> believe)
>
> * The installer doesn't configure XZ compression
> * You don't need it for a normal installation
> * If you want LVM or RAID, you have to use XZ, as per the hint at 
> http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
>
> At least I *believe* that's the case.  I didn't investigate in detail.
>
> --
> Martin Michlmayr
> http://www.cyrius.com/

Bug#890064: smbios-utils: properly clean up legacy config files

[Mario.Limonciello]

Thanks for the report.
I've added this for the next upload:
https://github.com/dell/libsmbios/commit/42379a462ec777cf5ae8ba87df40e5432faa8585

> -Original Message-
> From: Christoph Anton Mitterer [mailto:cales...@scientia.net]
> Sent: Saturday, February 10, 2018 11:28 AM
> To: Debian Bug Tracking System 
> Subject: Bug#890064: smbios-utils: properly clean up legacy config files
> 
> Package: smbios-utils
> Version: 2.4.0-1
> Severity: normal
> 
> 
> Hi.
> 
> Apparently the package smbios-utils used to contain:
> /etc/yum/pluginconf.d/dellsysid.conf
> but no longer does.
> 
> Therefore, the following happens on upgrade:
> Unpacking smbios-utils (2.4.0-1) over (2.3.1-2) ...
> dpkg: warning: unable to delete old directory '/etc/yum/pluginconf.d': 
> Directory
> not empty
> dpkg: warning: unable to delete old directory '/etc/yum': Directory not empty
> 
> 
> Please remove the obsolete config file on one of the next upgrades with the
> appropriate
> maintainer script helpers.
> 
> Thanks,
> Chris.

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Martin Michlmayr]

Unfortunately my memory is quite bad.  I *thought* the current
installer configured XZ compression by default but it seems that's not
the case.  So the documentation on my web site is correct.

* The installer sets MODULES=dep
* It has done so for a long time
* But you've upgraded from a really old release where this wasn't the case (I 
believe)

* The installer doesn't configure XZ compression
* You don't need it for a normal installation
* If you want LVM or RAID, you have to use XZ, as per the hint at 
http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/

At least I *believe* that's the case.  I didn't investigate in detail.

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

Bug#890276: RFS: wine/3.0-1~bpo9+1

[Jens Reyer]

Package: sponsorship-requests
Severity: normal


Dear mentors,

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

 * Package name: wine
   Version : 3.0-1~bpo9+1
   Upstream Author : see AUTHORS file
 * URL : winehq.org
 * License : LGPL-2.1+
   Section : otherosfs

It builds those binary packages:

fonts-wine - Windows API implementation - fonts
libwine- Windows API implementation - library
libwine-dev - Windows API implementation - development files
wine  - Windows API implementation - standard suite
wine-binfmt - Windows API implementation - binfmt support
wine32 - Windows API implementation - 32-bit binary loader
wine32-preloader - Windows API implementation - prelinked 32-bit binary
loader
wine32-tools - Windows API implementation - 32-bit developer tools
wine64 - Windows API implementation - 64-bit binary loader
wine64-preloader - Windows API implementation - prelinked 64-bit binary
loader
wine64-tools - Windows API implementation - 64-bit developer tools

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

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

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

  dget -x
https://mentors.debian.net/debian/pool/main/w/wine/wine_3.0-1~bpo9+1.dsc

or from our git repository, branch stretch-backports

 commit dc601b2480c66f577d2d38f1ecf1c2017ad0d175

Changes since the last upload:

  * Rebuild for stretch-backports.
  * Make versioned dependency on debhelper backports safe.



I'm a member of pkg-wine and DM with upload rights for this package.  I
still need a sponsor this time, because this is the first upload to
stretch-backports and therefore has to go through backports-new.

My usual sponsor (in bcc) from pkg-wine intended to upload this
(http://lists.alioth.debian.org/pipermail/pkg-wine-party/2018-January/007014.html),
but has gone mia since.  A private mail from a few days ago is also
still unanswered, yet (I hope you're well!).  Therefore I'm asking here
in the hope to speed up things.

To build this package you need debhelper and unicode-data from
stretch-backports.  AFAIK uploading to backports-new requires at least
an binary-indep build (not only source).

Thanks and greets
jre



signature.asc
Description: OpenPGP digital signature

Bug#890275: Please upgrade to version 2.2.0

[Thomas Goirand]

Source: python-munch
Severity: important

Hi Clint!

Could you please upgrade python-munch to version 2.2.0, as per:
https://github.com/openstack/requirements/blob/master/upper-constraints.txt
and also because python-openstacksdk for Queens needs it? This is currently
blocking me for the Queens release.

Also, it'd be nice if you could push this package to a team, so I could also
work in its packaging. You have the choice between DPMT, which has/is
currently moving to salsa.debian.org:

https://salsa.debian.org/python-team/modules

you can also move it to the OpenStack team:

https://salsa.debian.org/openstack-team/libs

I can add you to the OpenStack team if you want, or you can ask for access
to the DPMT if you don't have it yet.

Cheers,

Thomas Goirand (zigo)

Bug#890274: Invalid jquery-minicolors installation path

[Grzegorz Szymaszek]

Package: gitea
Version: 1.3.2+dfsg-3

Hello,

In [1], the jquery-minicolors library gets installed into the
`/usr/share/gitea/public/vendor` directory, while it is expected to land
into the `plugins` subdirectory (that’s where the web browser expects it).

Thanks!

[1]: 
https://anonscm.debian.org/cgit/pkg-go/packages/golang-code.gitea-gitea.git/tree/debian/gitea-common.links#n71



signature.asc
Description: PGP signature

Bug#889901: lttng-modules-dkms-2.9.0-1 fails to build with latest kernel (4.9.0-5-amd64) in debian 9.3

[srikanth krishnakar]

Excellent.

Thanks you so much Michael !

BR,
Srikanth


On Tue, Feb 13, 2018 at 12:46 AM, Michael Jeanson 
wrote:

> On 2018-02-08 10:27, srikanth krishnakar wrote:
> >
> > Do we have a fix or workaround available for this failure ?
> >
>
> This is fixed in the latest upstream stable-2.9 update:
>
> http://lttng.org/files/lttng-modules/lttng-modules-2.9.8.tar.bz2
>
>
> You might want to build from source, it will probably take a while for
> the updated package to land in stretch.
>
> Cheers,
>
> Michael
>
>

Bug#890273: ITP: python-os-service-types -- lib for consuming OpenStack sevice-types-authority data

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python-os-service-types
  Version : 1.1.0
  Upstream Author : OpenStack Foundation 
* URL : https://github.com/openstack/os-service-types
* License : Apache-2.0
  Programming Lang: Python
  Description : lib for consuming OpenStack sevice-types-authority data

 This package provides a Python library for consuming OpenStack
 sevice-types-authority data
 .
 The OpenStack Service Types Authority contains information about official
 OpenStack services and their historical service-type aliases.
 .
 The data is in JSON and the latest data should always be used. This simple
 library exists to allow for easy consumption of the data, along with a
 built-in version of the data to use in case network access is for some reason
 not possible and local caching of the fetched data.

Note: this is a new dependency for openstacksdk, itself needed by many
OpenStack API clients.

Bug#889968: RFS: inotify-tools/3.14-4

[Sean Whitton]

Hello,

On Mon, Feb 12 2018, kact...@gnu.org wrote:

> Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe, you
> could try again?

Still FTBFSs.  Log attached.

I suspect that the debomatic sid chroot is out-of-date.

-- 
Sean Whitton


inotify-tools_3.14-4_amd64-2018-02-12T20:05:02Z.build
Description: Binary data


signature.asc
Description: PGP signature

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Mario.Limonciello]

Pierre,

There have been a few times the patches got synced between the two, but I'll 
admit
I don't know the current home to the patches that live in the Debian package.

Hopefully some of the Debian maintainers can speak up since I haven't tracked 
it.

I think it would be good to make sure that all patches that are currently in 
2.3 in Debian
are no longer applicable in 2.5 and then update to 2.5 in Debian as well.

Thanks,

> -Original Message-
> From: Pierre Neyron [mailto:pierre.ney...@free.fr]
> Sent: Monday, February 12, 2018 11:54 AM
> To: Limonciello, Mario ; 832...@bugs.debian.org;
> pkg-dkms-ma...@lists.alioth.debian.org
> Subject: Re: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
> 
> Hi Marco,
> 
> Problem is Debian dkms (v2.3) seems to be an old fork of github/dell
> dkms (v2.5). Support for mkbmdeb comes from a patch in the Debian
> package but does not exist upstream. As a result my patch is not so
> relevant for upstream.
> 
> Do you know if the current Debian patches were already proposed to
> upstream ? Do you know the roadmap for a possible merge from upstream
> (bump Debian package version to 2.5) ?
> 
> Last be not least, since I do not have all the test cases in mind, I'd
> be glad to get a review from the Debian maintainers before sending upstream.
> 
> 
> Thanks,
> Best regards,
> Pierre
> 
> On 02/12/2018 06:27 PM, mario.limoncie...@dell.com wrote:
> >> -Original Message-
> >> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
> >> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of
> Pierre
> >> Neyron
> >> Sent: Monday, February 12, 2018 11:21 AM
> >> To: 832...@bugs.debian.org
> >> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
> >>
> >> Please find attached a patch for the dkms script (package version 2.3-3)
> >> that fixes the following issues:
> >>
> >> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
> >> package filename with -${debian_build_arch} instead of -all.
> >>
> >> - fix mkdeb (2): allow creating a dkms package without requiring to
> >> build the binary module beforehand . The patch actually makes
> >> --source-only de facto for mkdeb and mkdsc.
> >>
> >> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
> >>
> >> - fix usage: lacked mkdsc
> >>
> >> Regards
> >> Pierre
> >
> > Pierre,
> >
> > Can you please submit the patches to upstream at github?
> >

Bug#890272: RFH: qalculate-gtk -- Powerful and easy to use desktop calculator - GTK+ version

[shirish शिरीष]

Package: wnpp
Severity: normal

I request assistance on behalf of the maintainer with maintaining the
qalculate-gtk package.

The package description is:
 Qalculate! is small and simple to use but with much power and versatility
 underneath.  Features include customizable functions, units, arbitrary
 precision, plotting, and a graphical interface that uses a one-line
 fault-tolerant expression entry (although it supports optional traditional
 buttons).
 .
 This package contains the GTK+ user interface of qalculate.
 Qalculate! is small and simple to use but with much power and versatility
 underneath.  Features include customizable functions, units, arbitrary
 precision, plotting, and a graphical interface that uses a one-line
 fault-tolerant expression entry (although it supports optional traditional
 buttons).
 .
 This package contains the GTK+ user interface of qalculate.

While it would be best if you can commit sometime, but even  if not,
if you could help in
fixing #877733 and #877717 will be good. Qalculate depends upon
libqalculate so even that
would need to bumped up with new symbols and such.

Even an NMU (Non-maintainer upload) which improves the current state
woule be welcome.

-- 
  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#890271: libcgns: FTBFS with glibc 2.27: undefined reference to `matherr'

[Aurelien Jarno]

Source: libcgns
Version: 3.3.0-5
Severity: important
Tags: patch

libcgns 3.3.0-5 fails to build with glibc 2.27 (2.27-0experimental0 from
experimental):

| cd /<>/obj-x86_64-linux-gnu/src/cgnstools/cgnsview && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/cgiowish.dir/link.txt --verbose=1
| /usr/bin/cc -g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2  -Wl,-z,relro -rdynamic 
CMakeFiles/cgiowish.dir/cgiowish.c.o CMakeFiles/cgiowish.dir/cgiotcl.c.o  -o 
cgiowish  -L. 
-Wl,-rpath,.:/<>/obj-x86_64-linux-gnu/src:/usr/lib/x86_64-linux-gnu/hdf5/serial:
 ../../libcgns.so.3.3 -ltcl -ltk 
/usr/lib/x86_64-linux-gnu/hdf5/serial/libhdf5.so -lpthread -lsz -lz -ldl -lm 
-lX11 -lm 
| 
CMakeFiles/cgiowish.dir/cgiowish.c.o:./obj-x86_64-linux-gnu/src/cgnstools/cgnsview/./src/cgnstools/cgnsview/cgiowish.c:24:
 undefined reference to `matherr'
| collect2: error: ld returned 1 exit status
| src/cgnstools/cgnsview/CMakeFiles/cgiowish.dir/build.make:133: recipe for 
target 'src/cgnstools/cgnsview/cgiowish' failed
| make[3]: *** [src/cgnstools/cgnsview/cgiowish] Error 1
| make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| CMakeFiles/Makefile2:2735: recipe for target 
'src/cgnstools/cgnsview/CMakeFiles/cgiowish.dir/all' failed
| make[2]: *** [src/cgnstools/cgnsview/CMakeFiles/cgiowish.dir/all] Error 2
| make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| Makefile:165: recipe for target 'all' failed
| make[1]: *** [all] Error 2
| make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'
| dh_auto_build: cd obj-x86_64-linux-gnu && make -j1 returned exit code 2
| debian/rules:20: recipe for target 'build-arch' failed
| make: *** [build-arch] Error 2
| dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2

A full build logs is available there:
http://aws-logs.debian.net/2018/02/07/glibc-exp/libcgns_3.3.0-5_unstable_glibc-exp.log

Starting with glibc 2.27, support for matherr (part of SVID
specification) has been removed, causing this FTBFS. It is only used in
libcgns as a workaround for Sun shared libraries. The best way to fix
this FTBFS for Debian is therefore to just disable that part. This is
what the attached patch does.
diff -Nru libcgns-3.3.0/debian/patches/no-matherr.patch 
libcgns-3.3.0/debian/patches/no-matherr.patch
--- libcgns-3.3.0/debian/patches/no-matherr.patch
+++ libcgns-3.3.0/debian/patches/no-matherr.patch
@@ -0,0 +1,58 @@
+Description: Remove matherr hack
+ Remove matherr hack, that is only needed for Sun shared libraries and
+ causes an FTBFS with glibc 2.27 onwards, as SVID error handling has
+ been removed.
+Author: Aurelien Jarno 
+Last-Update: 2018-02-12
+
+--- libcgns-3.3.0.orig/src/cgnstools/cgnscalc/calcwish.c
 libcgns-3.3.0/src/cgnstools/cgnscalc/calcwish.c
+@@ -15,14 +15,6 @@
+ #include "tk.h"
+ #include "locale.h"
+ 
+-/*
+- * The following variable is a special hack that is needed in order for
+- * Sun shared libraries to be used for Tcl.
+- */
+-
+-extern int matherr();
+-int *tclDummyMathPtr = (int *) matherr;
+-
+ #ifdef TK_TEST
+ extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));
+ extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));
+--- libcgns-3.3.0.orig/src/cgnstools/cgnsplot/plotwish.c
 libcgns-3.3.0/src/cgnstools/cgnsplot/plotwish.c
+@@ -15,14 +15,6 @@
+ #include "tk.h"
+ #include "locale.h"
+ 
+-/*
+- * The following variable is a special hack that is needed in order for
+- * Sun shared libraries to be used for Tcl.
+- */
+-
+-extern int matherr();
+-int *tclDummyMathPtr = (int *) matherr;
+-
+ extern int Cgnstcl_Init _ANSI_ARGS_((Tcl_Interp *interp));
+ extern int Tkogl_Init _ANSI_ARGS_((Tcl_Interp *interp));
+ 
+--- libcgns-3.3.0.orig/src/cgnstools/cgnsview/cgiowish.c
 libcgns-3.3.0/src/cgnstools/cgnsview/cgiowish.c
+@@ -15,14 +15,6 @@
+ #include "tk.h"
+ #include "locale.h"
+ 
+-/*
+- * The following variable is a special hack that is needed in order for
+- * Sun shared libraries to be used for Tcl.
+- */
+-
+-extern int matherr();
+-int *tclDummyMathPtr = (int *) matherr;
+-
+ #ifdef TK_TEST
+ extern intTcltest_Init _ANSI_ARGS_((Tcl_Interp *interp));
+ extern intTktest_Init _ANSI_ARGS_((Tcl_Interp *interp));
diff -Nru libcgns-3.3.0/debian/patches/series 
libcgns-3.3.0/debian/patches/series
--- libcgns-3.3.0/debian/patches/series
+++ libcgns-3.3.0/debian/patches/series
@@ -2,3 +2,4 @@
 cgnstools-path.patch
 fix-p3dfout.patch
 no-rpath.patch
+no-matherr.patch

Bug#889968: RFS: inotify-tools/3.14-4

[KAction]

[2018-02-10 12:13] Sean Whitton 
> - It FTBFSs for me.  Log attached.

Look, debomatic build is succesful:

  
http://debomatic-amd64.debian.net/distribution#unstable/inotify-tools/3.14-4/buildlog

Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27
Maybe, you could try again?

Bug#890270: RFS: rhythmbox-plugin-alternative-toolbar/0.18.0-1

[foss.freedom]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

  I am looking for a sponsor for my package
"rhythmbox-plugin-alternative-toolbar"

 * Package name: rhythmbox-plugin-alternative-toolbar
   Version : 0.18.0-1
   Upstream Author : David Mohammed fossfree...@ubuntu.com
 * URL : github.com/fossfreedom/alternative-toolbar
 * License : GPLv3
   Section : misc

  It builds those binary packages:

rhythmbox-plugin-alternative-toolbar - Enhanced play controls and
interface for Rhythmbox

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

  https://mentors.debian.net/package/rhythmbox-plugin-alternative-toolbar


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

dget -x 
https://mentors.debian.net/debian/pool/main/r/rhythmbox-plugin-alternative-toolbar/rhythmbox-plugin-alternative-toolbar_0.18.0-1.dsc

Notes:

I am the author of this plugin and maintainer of the package in both
Debian and Ubuntu.

The following checks have been made:

lintian -i -I --pedantic on the built source.  This is lintian free
except for one pedantic - testsuite-autopkgtest-missing ; I don't
consider it necessary to create a autopkgtest suite for this python
plugin for rhythmbox

check-all-the-things has been run on the source - as you can see in
the changelog the key pickups have been addressed.

pbuilder-dist unstable build - this package was successfully built.

  Changes since the last upload:

  * New upstream release
- Latest Translations
- Headerbar button to toggle a source toolbar (LP: #1733438)
- Fixes for crashes with a german locale
- Add appdata metadata (LP: #1725457)
- Fix for crash when connecting and selecting a blank error source
  when connecting a phone (LP: #1723129)
- More logical help and about icons in the plugin window
- Translate Category heading
- Translate repeat button tooltip
  * Packaging Changes:
- debian/{control/compat} - bump debhelper version to v11
- debian/copyright - 2018 year change
- debian/control - bump Standards-Version to 4.1.3 (no changes required)
- debian/copyright - Add GPL-2+ copyright for debian/* files
- debian/copyright - Fix year issues from running
  check-all-the-things
- debian/upstream/metadata - fix warnings and errors from running
  check-all-the-things
- debian/upstream - move and rename signing-key

  Regards,
   David Mohammed

Bug#881494: chromium: chormium crash on startup

[Michel Meyers]

Package: chromium
Version: 64.0.3282.119-2
Followup-For: Bug #881494

Dear Maintainer,

Alas, this bug persists. When started with the Media Router Extension enabled, 
Chromium immediately crashes:

[19661:19661:0212/180641.943907:ERROR:background_mode_manager_aura.cc(13)] Not 
implemented reached in virtual void 
BackgroundModeManager::EnableLaunchOnStartup(bool)
[19661:19661:0212/180643.025328:ERROR:account_tracker.cc(278)] 
OnGetTokenFailure: Invalid credentials.
[19661:19661:0212/180643.025372:ERROR:account_tracker.cc(278)] 
OnGetTokenFailure: Invalid credentials.
[19661:19661:0212/180643.781786:ERROR:display_info_provider_aura.cc(31)] Not 
implemented reached in virtual void 
extensions::DisplayInfoProviderAura::UpdateDisplayUnitInfoForPla
tform(const display::Display&, 
extensions::api::system_display::DisplayUnitInfo*)
Received signal 11 SEGV_MAPERR 0010
#0 0x55f460767dee 
#1 0x55f45efe6ec8 
#2 0x55f4607681a7 
#3 0x7f2d35731160 
#4 0x55f45fa6d895 
#5 0x55f45fa6e817 
#6 0x55f45fa6ee82 
#7 0x55f45fa6f00f 
#8 0x55f4607cfbac 
#9 0x55f4607691ff 
#10 0x55f46078886e 
#11 0x55f46078969c 
#12 0x55f4607897fa 
#13 0x55f46078b1ca 
#14 0x55f4607b210a 
#15 0x55f4607d4b3f 
#16 0x55f4607cfaa1 
#17 0x7f2d3572651a start_thread
#18 0x7f2d29ea337f clone
 r8: 01b7f9118cd0 r9: 0004 r10: 55f463940650 r11: 
7f2d29f309e0
r12: 7f2cf6f8bf80 r13: 0008 r14:  r15: 
7f2cf6f8c190
 di:  si: 7f2cf6f8bf80 bp: 7f2cf6f8bf40 bx: 
7f2cf6f8bfa0
 dx: 0001 ax: 01b7f8be8e70 cx:  sp: 
7f2cf6f8bf20
 ip: 55f45fa6d895 efl: 00010206 cgf: 002b0033 erf: 
0004
trp: 000e msk:  cr2: 0010
[end of stack trace]
Calling _exit(1). Core file will not be generated.
-- System Information:
Debian Release: buster/sid
 APT prefers testing
 APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental'), (500, 
'oldoldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chromium depends on:
ii chromium-common 64.0.3282.119-2
ii libasound2 1.1.3-5
ii libatk-bridge2.0-0 2.26.1-1
ii libatk1.0-0 2.26.1-3
ii libavcodec57 10:3.2.2-dmo1
ii libavformat57 10:3.2.2-dmo1
ii libavutil55 10:3.2.2-dmo1
ii libc6 2.26-2
ii libcairo2 1.15.10-1
ii libcups2 2.2.6-4
ii libdbus-1-3 1.12.2-1
ii libevent-2.1-6 2.1.8-stable-4
ii libexpat1 2.2.5-3
ii libflac8 1.3.2-1
ii libfontconfig1 2.12.6-0.1
ii libfreetype6 2.8.1-1
ii libgcc1 1:7.2.0-19
ii libgdk-pixbuf2.0-0 2.36.11-1
ii libglib2.0-0 2.54.3-2
ii libgtk-3-0 3.22.26-2
ii libharfbuzz0b 1.7.2-1
ii libicu57 57.1-8
ii libjpeg62-turbo 1:1.5.2-2+b1
ii liblcms2-2 2.9-1
ii libminizip1 1.1-8+b1
ii libnspr4 2:4.18-1
ii libnss3 2:3.35-2
ii libopus0 1.2.1-1
ii libpango-1.0-0 1.40.14-1
ii libpangocairo-1.0-0 1.40.14-1
ii libpng16-16 1.6.34-1
ii libpulse0 11.1-4
ii libre2-3 20170101+dfsg-1
ii libsnappy1v5 1.1.7-1
ii libstdc++6 7.2.0-19
ii libvpx4 1.6.1-3
ii libwebp6 0.6.0-4
ii libwebpdemux2 0.6.0-4
ii libwebpmux3 0.6.0-4
ii libx11-6 2:1.6.4-3
ii libx11-xcb1 2:1.6.4-3
ii libxcb1 1.12-1
ii libxcomposite1 1:0.4.4-2
ii libxcursor1 1:1.1.15-1
ii libxdamage1 1:1.1.4-3
ii libxext6 2:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxi6 2:1.7.9-1
ii libxml2 2.9.4+dfsg1-6.1
ii libxrandr2 2:1.5.1-1
ii libxrender1 1:0.9.10-1
ii libxslt1.1 1.1.29-5
ii libxss1 1:1.2.2-1+b2
ii libxtst6 2:1.2.3-1
ii zlib1g 1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii fonts-liberation 1:1.07.4-5

Versions of packages chromium suggests:
pn chromium-driver 
pn chromium-l10n 
pn chromium-shell 
pn chromium-widevine 

-- no debconf information

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Martin Michlmayr]

The other thing you can do is to enable XZ compression:
http://www.cyrius.com/debian/orion/qnap/ts-109/troubleshooting/#bootable

I thought this was documented in the release notes but I can't find
it.

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

Bug#890236: exim4-daemon-heavy: /usr/sbin/exim4 -bV with log_selector = arguments logs to stderr

[Paul Slootman]

On Mon 12 Feb 2018, Andreas Metzler wrote:
> On 2018-02-12 Paul Slootman  wrote:
> > Package: exim4-daemon-heavy
> > Version: 4.90.1-1
> > Severity: normal
> 
> > After upgrading from 4.89-2 to 4.90-1.1 I get a mail from the cron.daily
> > run, due to /usr/sbin/exim4 -bV outputting this line to stderr instead
> > of to /var/log/exim4/mainlog like it used to:
> 
> > 2018-02-12 11:34:05.084 [29152] cwd=/tmp 2 args: /usr/sbin/exim4 -bV
> 
> > I do have "arguments" included in my log_selector, I find it useful to
> > see that, in the mainlog. Apparently something has changed so that it
> > now logs to stderr.
> 
> > Please revert to the old behaviour.
> 
> Hello,
> I am unable to verify that exim's behavior has changed from 4.89-2 to
> 4.90.1-1 in this respect:
> ametzler@argenau:/tmp/EXIM4$ exim4-daemon-light_4.89-1_amd64/usr/sbin/exim4 
> -bV > /dev/null
> 2018-02-12 19:02:03 cwd=/tmp/EXIM4 2 args: 
> exim4-daemon-light_4.89-1_amd64/usr/sbin/exim4 -bV
> ametzler@argenau:/tmp/EXIM4$ exim4-daemon-light_4.90.1-1_amd64/usr/sbin/exim4 
> -bV > /dev/null
> 2018-02-12 19:02:17 cwd=/tmp/EXIM4 2 args: 
> exim4-daemon-light_4.90.1-1_amd64/usr/sbin/exim4 -bV

Hmm, I was upgrading a bunch of systems yesterday, it could be that the
system with the "arguments" in log_selector was another one, previously
running 4.84.2-2+deb8u1.


Paul

Bug#732054: util-linux: Add cron job for regular SSD trimming

[Josh Triplett]

On February 12, 2018 12:22:45 PM EST, Laurent Bigonville  
wrote:
>On Wed, 12 Jul 2017 20:22:00 -0700 Josh Triplett
> 
>wrote:
> > On Wed, Jul 12, 2017 at 07:57:28PM +0200, Andreas Henriksson wrote:
> > > On Tue, Jul 11, 2017 at 08:23:07AM -0700, Josh Triplett wrote:
> > > [...]
> > > > Ideally, I would suggest that we start enabling the "discard" 
>option by
>> > > default in d-i. That would also avoid spinning up a periodic cron
>job
> > > > that runs regardless of actual need or disk activity.
> > >
> > > This doesn't help systems that are being upgraded though, so IMHO
> > > would be even more ideal if kernel just used it as default where
> > > suitable.
> >
> > Agreed. I'd like to see the kernel use the more reasonable default.
> >
>> > > (One of the things I really wish we could do more easily is
>eliminate
>> > > the numerous cron jobs that simply wake up, realize they have no 
>work to
> > > > do, and go back to sleep.)
> > >
>> > I see this problem but that's not my major concern. My personal
>biggest
>> > worry is about mixing mechanism (the util-linux tools) and policy
>(cron
>> > jobs, etc). I'd much rather see the two being separate and have
>higher
>> > level stuff put the policy in place rather than shipping the policy
>in
> > > an essential package.
> >
>> Agreed *completely*, and thank you for very clearly articulating this
> > concern.
> >
> > > This is exactly the same reason why I'm not
> > > entirely at ease with the suggestion in #855203 either.
> >
>> Agreed. Making that change would just move breakage around, fixing
>some
>> systems but breaking others. (There's a *reason* that job isn't run.)
> >
>> > Unfortunately I haven't been able to come up with a good package to
> > > point the finger to where we should put this policy.
> > > Suggestions would be very welcome!
> >
>> I think the right answer is always "fix the underlying package to
>have
>> the right default, rather than papering over it with configuration".
>If
>> we have some non-standard configuration we're shipping by default, we
>> should figure out how to make some kind of automatic detection that
>Just
> > Works the new default and eliminate the configuration.
> >
> >
>
>Marco has opened #889668 to just install the .service and the .timer 
>file at the correct location but not enabling them by default.

I can live with that.

>I guess that it would be a good compromise for now, I also think that 
>putting these file in an example directory is a bit meh.
>
>But I'm seeing something weird, all my disks on my laptops have the 
>"discard" option set but for some reasons when running "fstrim -v -a"
>it 
>still says that had trim data on all the FS.
>
>Do I miss something?

Do you have an encrypted root filesystem? Or LVM? You need to take additional 
steps to enable discard if so.

>Kind regards,
>
>Laurent Bigonville

Bug#889901: lttng-modules-dkms-2.9.0-1 fails to build with latest kernel (4.9.0-5-amd64) in debian 9.3

[Michael Jeanson]

On 2018-02-08 10:27, srikanth krishnakar wrote:
> 
> Do we have a fix or workaround available for this failure ?
> 

This is fixed in the latest upstream stable-2.9 update:

http://lttng.org/files/lttng-modules/lttng-modules-2.9.8.tar.bz2


You might want to build from source, it will probably take a while for
the updated package to land in stretch.

Cheers,

Michael

Bug#890264: openclonk FTBFS on armel/armhf: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'

[Adrian Bunk]

Control: forwarded -1 http://bugs.openclonk.org/view.php?id=1996

On Mon, Feb 12, 2018 at 08:02:14PM +0100, Philipp Kern wrote:
> On 02/12/2018 06:30 PM, Adrian Bunk wrote:
>...
> > If possible, this should be made working when Qt is using OpenGL ES.
> > 
> > If this is not easily possible,
> > - please lower the severity of this bug, and
> > - submit a bug against ftp.debian.org asking for the
> >   removal of the old armel+armhf binaries from unstable
> 
> I already filed a bug upstream about this: [1]. I know about the option
> space here. I will likely deactivate the editor, assuming that this
> works. Otherwise I'll ask for binary removal.

Thanks.

> I'll note that technically it doesn't need a serious bug because testing
> migration will be blocked anyhow until it either builds or the crufty
> binaries are deleted.

I'll note that the established way to inform the maintainer
(and everyone else who might be interested) that testing migration
is blocked by a problem in the package is by filing an RC bug.

An obvious example is that likely soon someone from Ubuntu
will check why 8.0-1 did FTBFS for them on armhf and arm64.

> Kind regards
> Philipp Kern
>...

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#857511: upstream release with fix

[David Gauchard]

Hello,

Transmission-2.93 with the fix is released (19 days ago).

david

Bug#890269: fonts-roboto: Upgrade to newest version from at least 2017

[Pander]

Package: fonts-roboto
Version: 2:0~20160106-2
Severity: normal

Dear Maintainer,

Please upgrade to the newest version from at least August 2nd from 2017. See
https://github.com/google/roboto/releases for the latest release.

Thanks,

Pander



-- System Information:
Debian Release: stretch/sid
  APT prefers artful-updates
  APT policy: (500, 'artful-updates'), (500, 'artful-security'), (500, 
'artful'), (100, 'artful-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fonts-roboto depends on:
ii  fonts-roboto-hinted  2:0~20160106-2

fonts-roboto recommends no packages.

fonts-roboto suggests no packages.

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Martin Michlmayr]

* Gunnar Thorburn  [2018-02-12 17:52]:
> The initial ramdisk is too large. This is often due to the unnecessary 
> inclusion
> of all kernel modules in the image. To fix this set MODULES=dep in one or both
> /etc/initramfs-tools/conf.d/driver-policy (if it exists) and

> Not enough space for initrd in MTD 'RootFS1' (need 4210887 but is
> actually 4194304).

Please check the various initramfs-tools configuration files to see if
you're using MODULES=dep.  Changing to MODULES=dep would be the fix.
However, given the size of your ramdisk, I fear you are already using
MODULES=dep.

Are you using RAID or LVM?  Unfortunately, since the MTD partition for
the ramdisk is very tiny on the TS-x09, you cannot use RAID or LVM.
(And this was possible in the past, which will lead to problems with
upgrades.)

> But given that TS-109 appears supported
>   http://www.cyrius.com/debian/orion/qnap/ts-109/install/
> and with no major issues
>   http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
> I would not expect this problem well into the upgrade.

I have to document the LVM/RAID issue.  In fact, the installation page
currently says "You can use LVM and RAID and a number of filesystems",
which is definitely no longer true to due to the size issue (even with
MODULES=dep).

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

Bug#890264: openclonk FTBFS on armel/armhf: error: conflicting declaration 'typedef khronos_ssize_t GLsizeiptr'

[Philipp Kern]

On 02/12/2018 06:30 PM, Adrian Bunk wrote:
> Source: openclonk
> Version: 8.0-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=openclonk=sid
> 
> ...
> In file included from 
> /usr/include/arm-linux-gnueabihf/qt5/QtGui/qopengl.h:105:0,
>  from /usr/include/arm-linux-gnueabihf/qt5/QtGui/QtGui:43,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QtWidgetsDepends:4,
>  from 
> /usr/include/arm-linux-gnueabihf/qt5/QtWidgets/QtWidgets:3,
>  from /<>/src/editor/C4ConsoleQt.h:34,
>  from /<>/src/editor/C4ConsoleQtState.h:27,
>  from /<>/src/editor/C4ConsoleQt.cpp:23:
> /usr/include/GLES3/gl31.h: At global scope:
> /usr/include/GLES3/gl31.h:77:25: error: conflicting declaration 'typedef 
> khronos_ssize_t GLsizeiptr'
>  typedef khronos_ssize_t GLsizeiptr;
>  ^~
> In file included from /<>/src/graphics/C4Shader.h:30:0,
>  from /<>/src/lib/StdMeshMaterial.h:20,
>  from /<>/src/graphics/C4Draw.h:22,
>  from /<>/src/landscape/C4Texture.h:26,
>  from /<>/src/editor/C4ConsoleQt.cpp:20:
> /usr/include/GL/glew.h:1680:19: note: previous declaration as 'typedef 
> ptrdiff_t GLsizeiptr'
>  typedef ptrdiff_t GLsizeiptr;
>^~
> 
> 
> If possible, this should be made working when Qt is using OpenGL ES.
> 
> If this is not easily possible,
> - please lower the severity of this bug, and
> - submit a bug against ftp.debian.org asking for the
>   removal of the old armel+armhf binaries from unstable

I already filed a bug upstream about this: [1]. I know about the option
space here. I will likely deactivate the editor, assuming that this
works. Otherwise I'll ask for binary removal.

I'll note that technically it doesn't need a serious bug because testing
migration will be blocked anyhow until it either builds or the crufty
binaries are deleted.

Kind regards
Philipp Kern

[1] http://bugs.openclonk.org/view.php?id=1996



signature.asc
Description: OpenPGP digital signature

Bug#890268: puppet: non-agent commands fail on puppet agent when environment is set

[Alex Kiousis]

Source: puppet
Version: 4.8.2-5
Severity: normal

Dear Maintainer,
puppet4 seems to always look inside 'environmentpath' for the currently
configured environment before doing any operation.
This doesn't make sense when a host acts as an agent.

By default environmentpath is set to '/etc/puppet/code/environments'.

Running any puppet command (except puppet agent) with an environment set
fails like this:

puppet config print --environment=testaki
/usr/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a 
directory environment named 'testaki' anywhere in the path: 
/etc/puppet/code/environments. Does the directory exist?  
(Puppet::Environments::EnvironmentNotFound)
from /usr/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in 
`push_application_context'
from /usr/lib/ruby/vendor_ruby/puppet/application.rb:337:in `run'
from /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:132:in `run'
from /usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in 
`execute'
from /usr/bin/puppet:5:in `'

Running puppet agent works fine though.

Our puppet.conf looks like this:
[main]
logdir = /var/log/puppet
vardir = /var/lib/puppet
ssldir = /var/lib/puppet/ssl
rundir = /var/run/puppet
factpath = $vardir/lib/facter
ca_server =  
server = 

Creating an empty directory named after the environment under environmentpath
seems to workaround this problem.

Bug#890242: perl: FTBFS with glibc-2.27: some symbols or patterns disappeared in the symbols file

[Niko Tyni]

On Mon, Feb 12, 2018 at 12:53:12PM +0100, Aurelien Jarno wrote:
> Package: perl
> Version: 5.26.1-4
> Severity: important
> Tags: patch
> User: debian-gl...@lists.debian.org
> Usertags: 2.27
> 
> perl 5.26.1-4 fails to build with glibc 2.27 (2.27-0experimental0 from
> experimental):

> | - _LIB_VERSION@Base 5.26.0~rc1
> | +#MISSING: 5.26.1-4# _LIB_VERSION@Base 5.26.0~rc1

> The solution for it to work with both glibc 2.27 and older version is to
> mark the symbol as optional. This should not be a problem, as a package
> which needs the "ieee" library has to link against libieee.a which will
> then provide the symbols. In addition no such package perl package has
> been found during the archive rebuild.
> 
> Therefore the following simple patch should be enough to fix the issue:

Many thanks! Will fix once the gdbm transition is over.
-- 
Niko

Bug#884865: Response?

[Brett Johnson]

Excellent, thank you for the update!

On Sat, Feb 10, 2018 at 7:55 AM, Timo Aaltonen  wrote:

> Brett Johnson kirjoitti 09.02.2018 klo 18:50:
> > Any chance of a response to this request?  If y'all think it's a bad
> > idea, or don't want to do it, that's OK, I'll go back to the drawing
> > board and try to figure out some sane way to package/version glslang and
> > spirv-tools independently (although that's going to be difficult, as
> > they don't have any kind of internal versioning).  But I'd sure
> > appreciate some kind of response.  Thanks!
>
> Sorry about the delay, current git has packaging for these but I wanted
> to let folks have a look at it first before uploading (which will happen
> soon now).
>

Bug#890267: URL check by cme reports that salsa.debian.org is not canonical

[gregor herrmann]

Control: reassign -1 libconfig-model-dpkg-perl
Control: forcemerge 889732 -1

On Mon, 12 Feb 2018 16:13:39 -0200, Gabriel F. T. Gomes wrote:

> Package: cme
> Version: 1.026-1
> 
> Running 'cme check dpkg' on a package maintained with git and that has
> already moved the repository to salsa.debian.org produces warnings for
> the fields 'Vcs-Browser' and 'Vcs-Git'.  The warning states that the
> "URL is not the canonical one for repositories hosted on Alioth".

The issue is actually in libconfig-model-dpkg-perl and already
reported as #889732; merging the two bugs.
 

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#883838: [Pkg-openldap-devel] Bug#883838: slapd: Overlay ppolicy: When pwdFailureCountInterval (!=0) is reached the password failures are not purged.

[Ryan Tandy]

Control: tag -1 + upstream moreinfo

Hello Mats,

Thank you for the report, and I apologize for not responding promptly.

It looks like this is a general OpenLDAP issue, rather than a 
Debian-specific one. If that's the case, it would be best if you could 
send your proposed change directly to the ITS, following upstream's 
guidelines for contributing:


http://www.openldap.org/devel/contributing.html

Due to upstream's IPR requirements I'm afraid I cannot simply forward 
the patch on your behalf.


I would strongly prefer the change be reviewed and ideally accepted 
upstream before we consider pulling it in as a Debian patch.


Thank you,
Ryan

Bug#890267: URL check by cme reports that salsa.debian.org is not canonical

[Gabriel F. T. Gomes]

Package: cme
Version: 1.026-1

Running 'cme check dpkg' on a package maintained with git and that has
already moved the repository to salsa.debian.org produces warnings for
the fields 'Vcs-Browser' and 'Vcs-Git'.  The warning states that the
"URL is not the canonical one for repositories hosted on Alioth".

This is the output of 'cme check dpkg' for bash-completion ITA:

  $ cme check dpkg
  cme: using Dpkg model
  loading data
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Warning in 'control source Vcs-Browser' value 
'https://salsa.debian.org/debian/bash-completion': URL is not the canonical one 
for repositories hosted on Alioth.
  Warning in 'control source Vcs-Git' value 
'https://salsa.debian.org/debian/bash-completion.git': URL is not the canonical 
one for repositories hosted on Alioth.
  checking data
  check done

Should salsa.debian.org also be considered a canonical URL now that it
is out of beta [1]?

[1] https://lists.debian.org/debian-devel-announce/2018/01/msg4.html

Bug#887189: golang-github-docker-docker-dev should depend on e2fsprogs explicitly

[Tianon Gravi]

On 12 February 2018 at 08:56, Andreas Henriksson  wrote:
> Apart from my first comment I'm not sure how useful it is to declare
> a dependency in the package shipping go *source* that utilizes a
> certain command. AIUI building go basically means you end up with
> something statically linked and the consumer of the go source needs
> to declare the dependency themselves (or atleast I'm not aware of any
> way for go packages to propagate dependencies via a substvar or
> similar).
>
> Thus my conclusion is that it's probably best to just close this bug
> report.

I agree that this bug as filed doesn't make much sense, but it does
point to one that does make sense IMO, which would be adding the two
packages mentioned (e2fsprogs and xfsprogs) to Suggests over in
docker.io instead (since there are configurations of Docker where it'd
be appropriate and necessary to have those packages installed).

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

Bug#890266: php5-common: 0050-Detect-invalid-port-in-xp_socket-parse-ip-address.patch incomplete

[jfot]

Package: php5-common
Version: 5.6.33+dfsg-0+deb8u1
Severity: important
Tags: patch

There was a bug reported and fixed:
https://bugs.php.net/bug.php?id=74216
https://security-tracker.debian.org/tracker/CVE-2017-7272

The fix consisted of two parts, first:
https://github.com/php/php-src/commit/bab0b99f376dac9170ac81382a5ed526938d595a
the fix had a big impact on applications relying on the "feature"
```
php5 -r 'print fsockopen("tcp://127.0.0.1:80/foo");'
```

Because of the heavy impact, a fixfix was released:
https://github.com/php/php-src/commit/cda7dcf4cacef3346f9dc2a4dc947e6a74769259

Now, security.debian.org offers 5.6.33+dfsg-0+deb8u1 whcih includes the
following patch:
https://sources.debian.org/src/php5/5.6.33+dfsg-0+deb8u1/debian/patches/0050
-Detect-invalid-port-in-xp_socket-parse-ip-address.patch/

But this is only part 1 of the fix. With this patch, the provided call above
doesn't work anymore.
This means we have to hold back the update. Magento(ecommerce) + Redis won't
work with this incomplete patch.

Please consider removing the patch or completing it with the fixfix.



-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-42-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From cda7dcf4cacef3346f9dc2a4dc947e6a74769259 Mon Sep 17 00:00:00 2001
From: Sara Golemon 
Date: Tue, 25 Apr 2017 12:52:48 +0200
Subject: [PATCH] Follow up patch regarding bug #74216, see bug #74429

While the case in bug #74429 is not documented and is only worky due to
an implementation bug, the strength seems to breach some real world
apps. Given this patch doesn't impact the initial security fix for
bug #74216, it is reasonable to let the apps keep working. As mentioned
in the ticket, this behavior is a subject to change in future versions
and should not be abused.
---
 main/streams/xp_socket.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/main/streams/xp_socket.c b/main/streams/xp_socket.c
index 3ff64787aa14..92be33326081 100644
--- a/main/streams/xp_socket.c
+++ b/main/streams/xp_socket.c
@@ -581,7 +581,7 @@ static inline char *parse_ip_address_ex(const char *str, size_t str_len, int *po
 			return NULL;
 		}
 		*portno = strtol(p + 2, , 10);
-		if (e && *e) {
+		if (e && *e && *e != '/') {
 			if (get_err) {
 *err = strpprintf(0, "Failed to parse address \"%s\"", str);
 			}
@@ -600,7 +600,7 @@ static inline char *parse_ip_address_ex(const char *str, size_t str_len, int *po
 	if (colon) {
 		char *e = NULL;
 		*portno = strtol(colon + 1, , 10);
-		if (!e || !*e) {
+		if (!e || !*e || *e == '/') {
 			return estrndup(str, colon - str);
 		}
 	}
>From cda7dcf4cacef3346f9dc2a4dc947e6a74769259 Mon Sep 17 00:00:00 2001
From: Sara Golemon 
Date: Tue, 25 Apr 2017 12:52:48 +0200
Subject: [PATCH] Follow up patch regarding bug #74216, see bug #74429

While the case in bug #74429 is not documented and is only worky due to
an implementation bug, the strength seems to breach some real world
apps. Given this patch doesn't impact the initial security fix for
bug #74216, it is reasonable to let the apps keep working. As mentioned
in the ticket, this behavior is a subject to change in future versions
and should not be abused.
---
 main/streams/xp_socket.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/main/streams/xp_socket.c b/main/streams/xp_socket.c
index 3ff64787aa14..92be33326081 100644
--- a/main/streams/xp_socket.c
+++ b/main/streams/xp_socket.c
@@ -581,7 +581,7 @@ static inline char *parse_ip_address_ex(const char *str, size_t str_len, int *po
 			return NULL;
 		}
 		*portno = strtol(p + 2, , 10);
-		if (e && *e) {
+		if (e && *e && *e != '/') {
 			if (get_err) {
 *err = strpprintf(0, "Failed to parse address \"%s\"", str);
 			}
@@ -600,7 +600,7 @@ static inline char *parse_ip_address_ex(const char *str, size_t str_len, int *po
 	if (colon) {
 		char *e = NULL;
 		*portno = strtol(colon + 1, , 10);
-		if (!e || !*e) {
+		if (!e || !*e || *e == '/') {
 			return estrndup(str, colon - str);
 		}
 	}
>From cda7dcf4cacef3346f9dc2a4dc947e6a74769259 Mon Sep 17 00:00:00 2001
From: Sara Golemon 
Date: Tue, 25 Apr 2017 12:52:48 +0200
Subject: [PATCH] Follow up patch regarding bug #74216, see bug #74429

While the case in bug #74429 is not documented and is only worky due to
an implementation bug, the strength seems to breach some real world
apps. Given this patch doesn't impact the initial security fix for
bug #74216, it is reasonable to let the apps keep working. As mentioned
in the ticket, this behavior is a subject to change in future versions
and should not be abused.
---
 

Bug#890236: exim4-daemon-heavy: /usr/sbin/exim4 -bV with log_selector = arguments logs to stderr

[Andreas Metzler]

On 2018-02-12 Paul Slootman  wrote:
> Package: exim4-daemon-heavy
> Version: 4.90.1-1
> Severity: normal

> After upgrading from 4.89-2 to 4.90-1.1 I get a mail from the cron.daily
> run, due to /usr/sbin/exim4 -bV outputting this line to stderr instead
> of to /var/log/exim4/mainlog like it used to:

> 2018-02-12 11:34:05.084 [29152] cwd=/tmp 2 args: /usr/sbin/exim4 -bV

> I do have "arguments" included in my log_selector, I find it useful to
> see that, in the mainlog. Apparently something has changed so that it
> now logs to stderr.

> Please revert to the old behaviour.

Hello,
I am unable to verify that exim's behavior has changed from 4.89-2 to
4.90.1-1 in this respect:
ametzler@argenau:/tmp/EXIM4$ exim4-daemon-light_4.89-1_amd64/usr/sbin/exim4 -bV 
> /dev/null
2018-02-12 19:02:03 cwd=/tmp/EXIM4 2 args: 
exim4-daemon-light_4.89-1_amd64/usr/sbin/exim4 -bV
ametzler@argenau:/tmp/EXIM4$ exim4-daemon-light_4.90.1-1_amd64/usr/sbin/exim4 
-bV > /dev/null
2018-02-12 19:02:17 cwd=/tmp/EXIM4 2 args: 
exim4-daemon-light_4.90.1-1_amd64/usr/sbin/exim4 -bV

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Pierre Neyron]

Hi Marco,

Problem is Debian dkms (v2.3) seems to be an old fork of github/dell
dkms (v2.5). Support for mkbmdeb comes from a patch in the Debian
package but does not exist upstream. As a result my patch is not so
relevant for upstream.

Do you know if the current Debian patches were already proposed to
upstream ? Do you know the roadmap for a possible merge from upstream
(bump Debian package version to 2.5) ?

Last be not least, since I do not have all the test cases in mind, I'd
be glad to get a review from the Debian maintainers before sending upstream.


Thanks,
Best regards,
Pierre

On 02/12/2018 06:27 PM, mario.limoncie...@dell.com wrote:
>> -Original Message-
>> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
>> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of 
>> Pierre
>> Neyron
>> Sent: Monday, February 12, 2018 11:21 AM
>> To: 832...@bugs.debian.org
>> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
>>
>> Please find attached a patch for the dkms script (package version 2.3-3)
>> that fixes the following issues:
>>
>> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
>> package filename with -${debian_build_arch} instead of -all.
>>
>> - fix mkdeb (2): allow creating a dkms package without requiring to
>> build the binary module beforehand . The patch actually makes
>> --source-only de facto for mkdeb and mkdsc.
>>
>> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
>>
>> - fix usage: lacked mkdsc
>>
>> Regards
>> Pierre
> 
> Pierre,
> 
> Can you please submit the patches to upstream at github?
> 

Bug#889829: ghc: error while loading shared libraries: libHShaskeline-0.7.3.0-ghc8.0.2.so

[James Clarke]

On 12 Feb 2018, at 15:18, John Paul Adrian Glaubitz 
 wrote:
> On 02/12/2018 04:16 PM, Holger Levsen wrote:
>> Downgrading the bug to normal, though I guess you can also close it. The
>> openjdk packages have the same issue. (But maybe you want to keep it
>> open to implement a message to the user saying "arg, /proc not mounted,
>> but we need it, aborting" or some such.)
> The Rust compiler has the same issue. Without /proc, it won't be able
> to find it's shared libraries. I'm not 100% sure, but I guess it's
> an issue when using dlopen() to load the libraries afterwards, but I never
> bothered to look into the details.

Ok, found it: _dl_get_origin tries to readlink /proc/self/exe to find the value
of $ORIGIN, falling back on the (empty) LD_ORIGIN_PATH environment variable
when that fails; I assume it does this instead of using readlink on the value of
AT_EXECFN in auxv due to the possible race condition.

This isn't really a bug in ghc, as it's a system limitation, though I guess for
Debian we could avoid the use of $ORIGIN as we know where ghc will be
installed, though given ghc-stageX are executed during the build that might be
awkward without either re-linking or setting LD_LIBRARY_PATH (or equivalent).

James

Bug#890067: libgl1-mesa-dri: breaks kde experimental (sddm or sddm-greeter crash, ksplashscreen crash)

[Eric Valette]

On 2/12/18 10:36 AM, Timo Aaltonen wrote:

On 10.02.2018 20:57, Eric Valette wrote:

Package: libgl1-mesa-dri
Version: 18.0.0~rc2-1
Severity: critical
Justification: breaks unrelated software

After sucesfully upgrading this machine with experimental kde; libc6, mesa, I 
went down and upgraded htpc and kids pc that are

AMD A4-5000
AMD E2-1800
AMD E1

respectively and all did break preventing to log in any way in kde session.
Becasue one of the crash in one machine reported once  a bug in r600_dri.so
ksplashqml[1148]: segfault at 7ffcac73c000 ip 7f9bf07d5be5 sp 
7ffcac739bf8 error 6 in r600_dri.so[7f9bf0394000+a86000]


18.0.0-rc4 is now pushed to experimental, please try with it once it's
built but if the driver still crashes, file a bug upstream.
Only tested on one of the failing machines (AMD A4-5000) : works 
correctly this time (no crash in sddm or sddm-gretter or ksplashscreen, 
and I manage to log in and get my session)


Only strange message in dmesg output is: radeon_dp_aux_transfer_native: 
74 callbacks suppressed.


Note sure I will try to break again kids PC after the nightmare week-end 
I got due this bug, even if I know how to fix now :-)


So I hope it means they really fixed it upstream for all amd devices...

-- eric

Bug#832558: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb

[Mario.Limonciello]

> -Original Message-
> From: Pkg-dkms-maint [mailto:pkg-dkms-maint-
> bounces+mario_limonciello=dell@lists.alioth.debian.org] On Behalf Of 
> Pierre
> Neyron
> Sent: Monday, February 12, 2018 11:21 AM
> To: 832...@bugs.debian.org
> Subject: [Pkg-dkms-maint] Bug#832558: Fix dkms mkdeb / mkdsc / mkbmdeb
> 
> Please find attached a patch for the dkms script (package version 2.3-3)
> that fixes the following issues:
> 
> - fix mkdeb (1): mkdeb failed because a mv command was looking for a
> package filename with -${debian_build_arch} instead of -all.
> 
> - fix mkdeb (2): allow creating a dkms package without requiring to
> build the binary module beforehand . The patch actually makes
> --source-only de facto for mkdeb and mkdsc.
> 
> - fix mkbmdeb: make --binary-only de facto for mkbmdeb
> 
> - fix usage: lacked mkdsc
> 
> Regards
> Pierre

Pierre,

Can you please submit the patches to upstream at github?