Bug#1013285: needrestart: Failed to check for processor microcode upgrades.

[Patrick Matthäi]

Hey

Am 21.11.2023 um 17:23 schrieb Antoine Beaupré:

Control: reopen -1
Control: subscribe -1

On 2023-11-15 15:46:24, Antoine Beaupré wrote:

Control: tags -1 +patch

On 2023-11-15 14:54:26, Antoine Beaupré wrote:

On 2022-06-20 13:54:38, Nick Lewycky wrote:

Package: needrestart
Version: 3.6-1
Severity: normal

`sudo needrestart -w` always prints "Failed to check for processor
microcode upgrades." on my AMD Ryzen 9 3900X 12-Core Processor.

[...]

There's now a PR for this upstream:

https://github.com/liske/needrestart/pull/285

People suffering from this issue are encouraged to test this and report
back upstream (or here, if you can't upstream).

I tested it and it doesn't work. It only *seemed* to work because the
author tested with -v, which *does* work around the issue.

I found the issue, and sent this PR upstream to fix it:

https://github.com/liske/needrestart/pull/288

Patch attached, people are again encouraged to test and report back.

I also attach upstream commit v3.6-9-ge85bfe3 which also seem necessary
to fix firmware checks on my end...

It doesn't *quite* fix it just yet. For platforms where the ucode is
*not* provided (e.g. in my case it's the pcengines APU that don't have
firmware upgrades), this *still* yields a UNKNOWN warning. After a brief
discussion in the issue tracker, I decided to submit *another* PR as
such:

https://github.com/liske/needrestart/pull/290

... and I think we should ship this in Debian as well.

I also think we should make a stable update for this. This affects a
bunch of machines on our end and we need this fixed in bookworm.

So I'll file a bug with the release team and prepare a stable
update.

Patrick: objections?

A.


I will upload this patch now with 3.6-7. I am fine with a stable update 
and would welcome it if you could do it in this case (I am a bit busy 
these weeks)


Thanks!

Bug#1054398: bing: error "not enough hosts were found to perform the bandwidth analysis"

[Patrick Matthäi]

Hey,

Am 23.10.2023 um 12:21 schrieb Sanjoy Mahajan:

Package: bing
Version: 1.3.5-5
Severity: grave
X-Debbugs-Cc: none, Sanjoy Mahajan 

Bing has not worked for me for many versions.  bing 1.1 works fine, but
1.3 in all versions that I've tried for years always fails.  Here's the
log from a typical example ("gw" is the router on the local network).
It always fails with the error "not enough hosts were found to perform
the bandwidth analysis".

# bing localhost gw
Found 2 key hosts
0: localhost (127.0.0.1)
1: gw (192.168.7.1)
--


What happens if you use bing 192.168.7.123 192.168.7.1

where .1 is your gw and .123 your own ipv4 in this subnet instead of 
localhost

Bug#1051570: Fwd: Bug#1051570: mlt: FTBFS with RtAudio 6

[Patrick Matthäi]

Hello,

I have got this patch for RTAudio 6 "support" (not tested, but it builds 
with 7.18.0). This patch also applies to the 7.20.0 version.
The problem is with the patch applied mlt builds against rtaudio 6.0.1, 
but it fails against 5.2.0 just with:


[ 57%] Linking CXX shared module ../../../out/lib/mlt/libmltmovit.so
cd /build/mlt-7.20.0/obj-x86_64-linux-gnu/src/modules/movit && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/mltmovit.dir/link.txt 
--verbose=1
/usr/bin/c++ -fPIC -g -O2 -ffile-prefix-map=/build/mlt-7.20.0=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -shared  -o ../../../out/lib/mlt/libmltmovit.so 
CMakeFiles/mltmovit.dir/factory.c.o 
CMakeFiles/mltmovit.dir/filter_glsl_manager.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_blur.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_convert.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_crop.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_deconvolution_sharpen.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_diffusion.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_flip.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_glow.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_lift_gamma_gain.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_mirror.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_opacity.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_rect.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_resample.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_resize.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_saturation.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_vignette.cpp.o 
CMakeFiles/mltmovit.dir/filter_movit_white_balance.cpp.o 
CMakeFiles/mltmovit.dir/mlt_movit_input.cpp.o 
CMakeFiles/mltmovit.dir/transition_movit_luma.cpp.o 
CMakeFiles/mltmovit.dir/transition_movit_mix.cpp.o 
CMakeFiles/mltmovit.dir/transition_movit_overlay.cpp.o 
CMakeFiles/mltmovit.dir/consumer_xgl.c.o 
-Wl,-rpath,/build/mlt-7.20.0/obj-x86_64-linux-gnu/out/lib: -lm 
../../../out/lib/libmlt++-7.so.7.20.0 
/usr/lib/x86_64-linux-gnu/libX11.so ../../../out/lib/libmlt-7.so.7.20.0 
/usr/lib/x86_64-linux-gnu/libGLX.so 
/usr/lib/x86_64-linux-gnu/libOpenGL.so 
/usr/lib/x86_64-linux-gnu/libmovit.so /usr/lib/x86_64-linux-gnu/libepoxy.so

make[3]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu'
[ 57%] Built target mltmovit
make[2]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu'
make[1]: *** [Makefile:139: all] Error 2
make[1]: Leaving directory '/build/mlt-7.20.0/obj-x86_64-linux-gnu'
dh_auto_build: error: cd obj-x86_64-linux-gnu && make -j2 
"INSTALL=install --strip-program=true" VERBOSE=1 returned exit code 2

make: *** [debian/rules:11: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit 
status 2



A better fix would be welcome :)


 Weitergeleitete Nachricht 
Betreff:Bug#1051570: mlt: FTBFS with RtAudio 6
Weitersenden-Datum: Sat, 09 Sep 2023 21:15:01 +
Weitersenden-Von:   IOhannes m zmoelnig 
Weitersenden-An:    debian-bugs-d...@lists.debian.org
Weitersenden-CC:Patrick Matthäi 
Datum:  Sat, 09 Sep 2023 23:10:59 +0200
Von:IOhannes m zmoelnig 
Antwort an: 	IOhannes m zmoelnig , 
1051...@bugs.debian.org

An: Debian Bug Tracking System 



Source: mlt
Version: 7.18.0-2
Severity: serious
Tags: ftbfs patch
Justification: fails to build from source (but built successfully in the 
past)


Dear Maintainer,

mlt ftbfs with RtAudio 6 (currently in experimental).

```
[ 89%] Building CXX object 
src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o
cd /build/mlt-zme0kO/mlt-7.18.0/obj-x86_64-linux-gnu/src/modules/rtaudio 
&& /usr/lib/ccache/c++ -Dmltrtaudio_EXPORTS 
-I/build/mlt-zme0kO/mlt-7.18.0/src/framework/.. -isystem 
/usr/include/rtaudio -g -O2 
-ffile-prefix-map=/build/mlt-zme0kO/mlt-7.18.0=. 
-fstack-protector-strong -fstack-clash-protection -Wformat 
-Werror=format-security -fcf-protection -Wdate-time -D_FORTIFY_SOURCE=2 
-std=c++14 -fPIC -mmmx -msse -msse2 -pthread -D__LINUX_ALSA__ 
-D__LINUX_PULSE__ -D__UNIX_JACK__ -D_REENTRANT -MD -MT 
src/modules/rtaudio/CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o -MF 
CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o.d -o 
CMakeFiles/mltrtaudio.dir/consumer_rtaudio.cpp.o -c 
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp: 
In member function ‘bool RtAudioConsumer::create_rtaudio(RtAudio::Api, 
int, int)’:
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:164:26: 
error: ‘struct RtAudio::DeviceInfo’ has no member named ‘probed’

164 | if (info.probed && info.name == resource) {
| ^~
/build/mlt-zme0kO/mlt-7.18.0/src/modules/rtaudio/consumer_rtaudio.cpp:212:16: 
error: ‘RtAudioError’ does not name a type; did you mean ‘RtAudioErrorType’?

212 | catch (RtAu

Bug#1041998: glusterfs uploaded to unstable

[Patrick Matthäi]

severity #1041999 serious
severity #1041998 serious
thanks

Hey,

glusterfs 11.0 is now in unstable

Bug#1035284: Znc nmu?

[Patrick Matthäi]

Hey
Would you Upload a nmu? I am on vac for another two weeks thanks!


Mit freundlichen Grüßen aus Paderborn

Patrick Matthäi
Leitung IT-Services

LEONEX Internet GmbH
Technologiepark 6
33100 Paderborn
Telefon: +49 (5251) 4142-500
Durchwahl: +49 (5251) 4142-525
Fax: +49 (5251) 4142-501

HRB 8694 AG Paderborn
Geschäftsführer: Stephan Winter



LEONEX ist Google Premier Partner.
Mit der staatlichen Förderung Go-Digital in die Digitalisierung. Wir sind Ihr 
Ansprechpartner für erfolgreiche Webauftritte, E-Commerce, individuelle 
Softwarelösungen, Online-Marketing und Hosting.

Bug#1030763: Do not migrate to testing/bookworm

[Patrick Matthäi]

Package: ckport
Version: 0.1~rc1-11
Severity: serious

Dont migrate again to testing

Bug#1030764: Do not migrate to testing/bookworm

[Patrick Matthäi]

Package: vclt-tools
Version: 0.1.4-9
Severity: serious

Dont migrate again to testing

Bug#1030762: Do not migrate to testing/bookworm

[Patrick Matthäi]

Package: roarplaylistd
Version: 0.1.9-10
Severity: serious

Dont migrate again to testing

Bug#1030761: Do not migrate to testing/bookworm

[Patrick Matthäi]

Package: muroar
Version: 0.1.13-8
Severity: serious

Dont migrate again to testing

Bug#1030759: Do not migrate to testing/bookworm

[Patrick Matthäi]

Package: muroard
Version: 0.1.14-9
Severity: serious

Dont migrate again to testing

Bug#1030760: Do not migrate to testing/bookworm

[Patrick Matthäi]

Package: roaraudio
Version: 1.0~beta12-5
Severity: serious

Dont migrate again to testing

Bug#1030661: cmus: Remove roaraudio dependency

[Patrick Matthäi]

Package: cmus
Version: 2.10.0-2+b1
Severity: grave
Tags: patch
Justification: renders package unusable

Hello,

I am maintaining the roaraudio packages. I have decided, because of the lack
of users and no new releses for years, to remove it from testing/bookworm and
maybe from unstable, too.
cmus is the only reverse dependency, so please remove the roaraudio support, so
I could go ahead with removing the package.

Patch:
diff -Naur old/cmus-2.10.0/debian/control cmus-2.10.0/debian/control
--- old/cmus-2.10.0/debian/control  2022-07-13 23:01:12.0 +0200
+++ cmus-2.10.0/debian/control  2023-02-06 10:17:03.431864752 +0100
@@ -25,7 +25,6 @@
  libncursesw5-dev,
  libopusfile-dev,
  libpulse-dev,
- libroar-dev,
  libsamplerate0-dev,
  libsystemd-dev,
  libvorbis-dev,
diff -Naur old/cmus-2.10.0/debian/files cmus-2.10.0/debian/files
--- old/cmus-2.10.0/debian/files1970-01-01 01:00:00.0 +0100
+++ cmus-2.10.0/debian/files2023-02-06 10:17:56.627639054 +0100
@@ -0,0 +1 @@
+cmus_2.10.0-2.1_source.buildinfo sound optional
diff -Naur old/cmus-2.10.0/debian/rules cmus-2.10.0/debian/rules
--- old/cmus-2.10.0/debian/rules2022-07-13 23:01:12.0 +0200
+++ cmus-2.10.0/debian/rules2023-02-06 10:17:31.383746159 +0100
@@ -21,7 +21,7 @@
 DPKG_EXPORT_BUILDFLAGS= 1
 include /usr/share/dpkg/buildflags.mk

-suggested_deps = pulse roar jack
+suggested_deps = pulse jack

 EXTRA_CMUS_DIR_OP_PLUGINS = debian/cmus/usr/lib/cmus/op/
 EXTRA_CMUS_PLUGINS := $(foreach plugin,$(suggested_deps),$(plugin).so)

Bug#1023555: fastnetmon: FTBFS with libbpf 1.0

[Patrick Matthäi]

Am 08.11.2022 um 17:55 schrieb Pavel Odintsov:

Hello!

Added copy to all.

I think I fixed it with these commits: 
https://github.com/pavel-odintsov/fastnetmon/commit/c48497a6f109fc1a9f5da596b055c3b7cffb96d4 
and 
https://github.com/pavel-odintsov/fastnetmon/commit/c718e88d0b25dcfbd724e9820f592fd5782eca6c
Thank you, I have uploaded a package with both patches and it builds 
fine again:


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




I've used 
https://lore.kernel.org/bpf/20220202225916.3313522-7-and...@kernel.org/ 
and 
https://lxr.missinglinkelectronics.com/linux+v5.19/samples/bpf/xdp1_user.c 
as examples as this code was my reference during implementation.


Would be great if you could review it a second time.

Thank you!

On Mon, 7 Nov 2022 at 11:59, Sudip Mukherjee 
 wrote:


Hi Pavel,

On Mon, Nov 7, 2022 at 11:53 AM Pavel Odintsov
 wrote:
>
> Hello!
>
> Thank you for reaching me.
>
> Sure, I'll be happy to check.
>
> May I kindly ask what exactly changed to trigger these errors? I
believe it was successfully built previously.

Its the update of libbpf to v1.0.1 which removed some of the
deprecated API.


-- 
Regards

Sudip



--
Sincerely yours, Pavel Odintsov

Bug#1023555: fastnetmon: FTBFS with libbpf 1.0

[Patrick Matthäi]

Hey,

Am 06.11.2022 um 19:32 schrieb Sudip Mukherjee:

On Sun, Nov 6, 2022 at 3:51 PM Sebastian Ramacher  wrote:

Source: fastnetmon
Version: 1.2.3-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: sramac...@debian.org, sudipm.mukher...@gmail.com

https://buildd.debian.org/status/fetch.php?pkg=fastnetmon&arch=amd64&ver=1.2.3-1%2Bb1&stamp=1667748889&raw=0

oops, sorry I missed it in my list of packages depending on libbpf. It
seems "fastnetmon" added the dependency on libbpf with the last upload
and I generated my list before that.   :(

Please let me know if you want me to help with a patch to port the
code to libbpf.



Yeah it is a new feature and was just added, dont worry :-)

@Pavel: This is for you, if you need help maybe dont hestiate to ask 
Sudip (thanks for your offer!)


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#986037: kdenlive: crashes on audio setup

[Patrick Matthäi]

severity #986037 important
thanks

Hi Norbert and Dan,

Am 28.03.21 um 14:11 schrieb Norbert Preining:

Package: kdenlive
Version: 20.12.3-1
Severity: grave



Since (for myself?) this issue does not affect Debian bullseye 
downgrading the severity, because this release could not migrate then..




Justification: renders package unusable

Hi

I am running kdenlive with the kde frameworks from experimental, but
that shouldn't be a problem I thought.

I see crashes/segfaults on every start of kdenlive. Backtrace is:
(gdb) bt
#0  0x7fff898862a0 in fftw_execute () from 
/usr/lib/x86_64-linux-gnu/libfftw3.so.3
#1  0x7fff894207f5 in ?? () from /usr/lib/x86_64-linux-gnu/mlt/libmltplus.so
#2  0x76d93b88 in mlt_frame_get_audio () from 
/usr/lib/x86_64-linux-gnu/libmlt.so.6
#3  0x76d722b8 in Mlt::Frame::get_audio(mlt_audio_format&, int&, int&, 
int&) () from /usr/lib/x86_64-linux-gnu/libmlt++.so.3
#4  0x558b8929 in ?? ()
#5  0x558b4aab in ?? ()
#6  0x556e25a5 in ?? ()
#7  0x752d6e72 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x752d3b81 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x74382ea7 in start_thread (arg=) at 
pthread_create.c:477
#10 0x74e2cdef in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

and when I enter "c" into gdb to continue another segfault happens:
(gdb) c
Continuing.
[Thread 0x7fff1a3fc700 (LWP 250120) exited]

Thread 1 "kdenlive" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7102d8c0 (LWP 250071)]
0x703ba570 in QXcbConnection::getSelectionOwner(unsigned int) const () 
from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
(gdb) bt
#0  0x703ba570 in QXcbConnection::getSelectionOwner(unsigned int) const 
() from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#1  0x703b4f88 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#2  0x7715c998 in QQuickTextInput::q_canPasteChanged() () from 
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#3  0x771691e3 in QQuickTextInput::qt_metacall(QMetaObject::Call, int, 
void**) () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#4  0x745bac76 in QQuickTextField::qt_metacall(QMetaObject::Call, int, 
void**) ()
from /usr/lib/x86_64-linux-gnu/libQt5QuickTemplates2.so.5
#5  0x754eb290 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x75ed0935 in QClipboard::emitChanged(QClipboard::Mode) () from 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#7  0x703b98a4 in QXcbConnection::handleXcbEvent(xcb_generic_event_t*) 
() from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#8  0x703bacd6 in 
QXcbConnection::processXcbEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#9  0x703dd7d3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#10 0x739bde6b in g_main_context_dispatch () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x739be118 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x739be1cf in g_main_context_iteration () from 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7550c4bf in 
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x754b392b in 
QEventLoop::exec(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x754bbba0 in QCoreApplication::exec() () from 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x556360d4 in ?? ()
#17 0x74d55d0a in __libc_start_main (main=0x55634c20, argc=1, 
argv=0x7fffd8a8, init=, fini=,
 rtld_fini=, stack_end=0x7fffd898) at 
../csu/libc-start.c:308
#18 0x5563d6ba in _start ()
(gdb)

and then a final continue
(gdb) c
Continuing.
QSocketNotifier: Invalid socket 7 and type 'Read', disabling...
QSocketNotifier: Invalid socket 13 and type 'Read', disabling...
QSocketNotifier: Invalid socket 14 and type 'Read', disabling...
Invalid read from eventfd: Bad file descriptor
Code should not be reached at pulsecore/fdsem.c:157, function flush(). Aborting.
[Thread 0x7fffefee3700 (LWP 250075) exited]
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kdenlive path = /usr/bin pid = 250071
KCrash: Arguments: /usr/bin/kdenlive
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
Cannot find user-level thread for LWP 250102: generic error
(gdb) Cannot find user-level thread for LWP 250098: generic error


Not sure whether this is a pulseaudio, kdenlive, or one of the
frameworks problems, though.



This does not look like kdenlive for me, maybe from mlt, what do you say 
Dan?


Norbert: Can you confirm it works/not with 20.12.2 and with Debian 
bullseye without experimental packages?




Best

Norbert

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

Ke

Bug#973297: Conflicting file with fonts-noto-mono

[Patrick Matthäi]

Package: fonts-noto-core
Version: 20201027-1
Severity: serious

Hi,

just today:

root@gnu:~# LC_ALL=C apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  fonts-noto-core
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
43 not fully installed or removed.
Need to get 0 B/10.8 MB of archives.
After this operation, 63.5 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
(Reading database ... 192329 files and directories currently installed.)
Preparing to unpack .../fonts-noto-core_20201027-1_all.deb ...
Unpacking fonts-noto-core (20201027-1) over (20200323-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/fonts-noto-core_20201027-1_all.deb (--unpack):
 trying to overwrite 
'/usr/share/fonts/truetype/noto/NotoMono-Regular.ttf', which is also in 
package fonts-noto-mono 20201027-1

dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/fonts-noto-core_20201027-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@gnu:~#

Bug#958408: etherape: crashes with "critical: read_all() failed on control socket"

[Patrick Matthäi]

Hi,

Am 28.04.2020 um 00:08 schrieb Bernhard Übelacker:
> Dear Maintainer,
> I could reproduce the issue on i386 and tried to collect
> some more information.
>
> It crashes with the backtrace below.
>
> The crash seems to be caused by using the wrong data type
> in the calls to variadic functions goo_canvas_ellipse_new
> and goo_canvas_polyline_new.
>
> The modifications below made it work at i386 too.
> (Just changing integer to floating point values).
> Tested it just shortly.
>
>
>
> (gdb) bt
> #0  __strchr_sse2_bsf () at 
> ../sysdeps/i386/i686/multiarch/strchr-sse2-bsf.S:60
> #1  0xb73243ce in g_param_spec_pool_lookup (pool=0x136e260, param_name=0x1 
> , owner_type=26014064, 
> walk_ancestors=1) at ../../../gobject/gparam.c:1071
> #2  0xb731fbce in g_object_set_valist (object=, 
> first_property_name=, var_args=0xbfb6a0b4 "") at 
> ../../../gobject/gobject.c:2289
> #3  0xb7f6e4be in goo_canvas_ellipse_new (parent=0x1685848, center_x=0, 
> center_y=0, radius_x=0, radius_y=0) at goocanvasellipse.c:214
> #4  0x0044feea in check_new_node (canvas=0x1650380, node=0x14b1600) at 
> diagram.c:935
> #5  diagram_update_nodes (canvas=0x1650380) at diagram.c:541
> #6  update_diagram (canvas=0x1650380) at diagram.c:735
> #7  0x00450828 in update_diagram_callback (data=0x0) at diagram.c:1910
> #8  0xb7076a51 in g_timeout_dispatch (source=0x14793c0, callback=0x450810 
> , user_data=0x0) at ../../../glib/gmain.c:4667
> #9  0xb7075e65 in g_main_dispatch (context=0x13b1fd0) at 
> ../../../glib/gmain.c:3182
> #10 g_main_context_dispatch (context=0x13b1fd0) at ../../../glib/gmain.c:3847
> #11 0xb7076269 in g_main_context_iterate (context=0x13b1fd0, 
> block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
> ../../../glib/gmain.c:3920
> #12 0xb7076609 in g_main_loop_run (loop=0x1478ea0) at 
> ../../../glib/gmain.c:4116
> #13 0xb799139e in gtk_main () at ../../../../gtk/gtkmain.c:1323
> #14 0x0044049e in main (argc=, argv=) at 
> main.c:316
>
>
>
>
>
> --- etherape-0.9.18.orig/src/diagram.c
> +++ etherape-0.9.18/src/diagram.c
> @@ -939,7 +939,7 @@ static gint check_new_node(node_t * node
>  0.0,
>  "fill-color", "white",
>  "stroke-color", "black",
> -"line-width", 0,
> +"line-width", 0.0,
>   "visibility", GOO_CANVAS_ITEM_INVISIBLE,
>   NULL);
>addref_canvas_obj(G_OBJECT(new_canvas_node->node_item));
> @@ -1480,16 +1480,16 @@ static gint check_new_link(link_id_t * l
>/* set the lines position using groups positions */
>new_canvas_link->src_item =
>  goo_canvas_polyline_new(rootgroup, TRUE, 2,
> -0,0,
> -1,1,
> +0.0,0.0,
> +1.0,1.0,
>  "fill-color", "tan",
>  NULL);
>g_object_ref(G_OBJECT (new_canvas_link->src_item));
>  
>new_canvas_link->dst_item =
>  goo_canvas_polyline_new(rootgroup, TRUE, 2,
> -0,0,
> -1,1,
> +0.0,0.0,
> +1.0,1.0,
>  "fill-color", "tan",
>  NULL);
>g_object_ref(G_OBJECT (new_canvas_link->dst_item));
>
>
>
>
>
>
>
> PS.: Could not install etherape on a multiarch amd64/i386 system because
>  it tells it depends on non-existing etherape-data:i386.

Thanks for your patch. I have tested it on my amd64 machine, where I
didn't had problems. Anyway it also builds fine with your patch and I
have uploaded it.

@rghetta:
Do you want to merge it?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: https://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#949695: thunderbird does not start anymore

[Patrick Matthäi]

Source: thunderbird
Version: 1:68.4.1-1+b1
Severity: serious

Hey,

one of the last days testing and or unstable updates let thunderbird stop 
starting.
I just get:

$ thunderbird
ExceptionHandler::GenerateDump cloned child 3482
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
me@gnu:~$ Exception ignored in: <_io.TextIOWrapper name='' mode='w' 
encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe

Also with a new profile, also with the version from testing and unstable. So I 
think some dependecie
crashes thunderbird

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

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

Bug#947678: FTBFS: /usr/bin/ld: cannot find -lGL

[Patrick Matthäi]

Am 29.12.2019 um 13:24 schrieb John Paul Adrian Glaubitz:
> On 12/29/19 1:11 PM, John Paul Adrian Glaubitz wrote:
>> I think it's more related to recent changes in libglvnd, see:
>>
>>> https://packages.qa.debian.org/libg/libglvnd/news/20191220T191934Z.html
>> I'll try a give-back on one of the buildds.
> Yep, that helped. I have given back the package on all architectures now:
>
>> https://buildd.debian.org/status/package.php?p=mlt
> Adrian

Thanks for your work!

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#947678: FTBFS: /usr/bin/ld: cannot find -lGL

[Patrick Matthäi]

Am 29.12.2019 um 10:51 schrieb John Paul Adrian Glaubitz:
> Hi!
>
> On 12/29/19 10:36 AM, Patrick Matthäi wrote:
>>> collect2: error: ld returned 1 exit status
>>> make[3]: *** [Makefile:61: ../libmltopengl.so] Error 1
>>> make[3]: Leaving directory '/<>/src/modules/opengl'
>> Yes, I already asked for help here:
>> https://lists.debian.org/debian-arm/2019/12/msg00017.html
> Did you try adding libgl1-dev to Build-Depends in debian/control?
>
> It pretty much looks like the development files for OpenGL are missing
> and the linker is complaining it can't find libGL to link against.


I think this just happens because of the added -latomic flag. See the
build logs and the changelog from -1 to -3


>
> Adrian
>

Bug#947678: FTBFS: /usr/bin/ld: cannot find -lGL

[Patrick Matthäi]

Hi

Am 29.12.2019 um 01:58 schrieb Lisandro Damián Nicanor Pérez Meyer:
> Source: mlt
> Version: 6.18.0-3
> Severity: serious
> Justification: FTBFS on all archs
>
> Hi! Your package failed to build form source on all archs:
>
> 
>
> The error seems to be:
>
> g++ -shared -o ../libmltopengl.so factory.o consumer_xgl.o 
> filter_glsl_manager.o filter_movit_blur.o filter_movit_convert.o 
> filter_movit_crop.o filter_movit_deconvolution_sharpen.o 
> filter_movit_diffusion.o filter_movit_flip.o filter_movit_glow.o 
> filter_movit_lift_gamma_gain.o filter_movit_mirror.o filter_movit_opacity.o 
> filter_movit_rect.o filter_movit_resample.o filter_movit_resize.o 
> filter_movit_saturation.o filter_movit_vignette.o 
> filter_movit_white_balance.o mlt_movit_input.o transition_movit_luma.o 
> transition_movit_mix.o transition_movit_overlay.o -L../../framework -lmlt -lm 
> -Wl,-z,relro -Wl,-z,now -Wl,--no-undefined -Wl,--as-needed -Wl,--no-undefined 
> -Wl,--as-needed -Wl,--no-undefined -Wl,--as-needed -L../../mlt++ -lmlt++ 
> -lmovit -lepoxy -lpthread -lGL -lX11
> /usr/bin/ld: cannot find -lGL
> collect2: error: ld returned 1 exit status
> make[3]: *** [Makefile:61: ../libmltopengl.so] Error 1
> make[3]: Leaving directory '/<>/src/modules/opengl'

Yes, I already asked for help here:
https://lists.debian.org/debian-arm/2019/12/msg00017.html

Bug#947678: Processed: Tag

[Patrick Matthäi]

tag 947678 + help
thanks

Am 29.12.2019 um 02:18 schrieb Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
>
>> tag 947678 ftbfs
> Bug #947678 [src:mlt] FTBFS: /usr/bin/ld: cannot find -lGL
> Added tag(s) ftbfs.
>> thanks
> Stopping processing here.
>
> Please contact me if you need assistance.

Bug#945251: otrs2: CVE-2019-18179 CVE-2019-18180

[Patrick Matthäi]

block #945251 by #945004
thanks

Am 21.11.2019 um 22:44 schrieb Salvatore Bonaccorso:
> Source: otrs2
> Version: 6.0.23-2
> Severity: grave
> Tags: security upstream
> Justification: user security hole
>
> Hi,
>
> The following vulnerabilities were published for otrs2
>
> CVE-2019-18179[0] and CVE-2019-18180[1].
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2019-18179
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18179
> 
> https://community.otrs.com/security-advisory-2019-14-security-update-for-otrs-framework/
> [1] https://security-tracker.debian.org/tracker/CVE-2019-18180
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-18180
> 
> https://community.otrs.com/security-advisory-2019-15-security-update-for-otrs-framework/
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
> Salvatore

Hi,

current otrs releases require an additional module, where I filled a RFP
for.

You are free to do new uploads (upstream releases, nmu etc), since I am
on vac now

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#914783: fixed in znc 1.7.4-2

[Patrick Matthäi]

Thanks, that was already fixed in my svn for the next upload:

* Add VERSION_EXTRA string again.
* Add cmake dependency to znc-dev package.

Am 16.07.2019 um 11:34 schrieb Gianfranco Costamagna:
> control: reopen -1
> control: notfixed -1
> control: severity -1 serious
> control: tags -1 patch
> control: affects -1 znc-backlog
>
>>* Switch to the cmake build system.
>>  Closes: #914783
> thanks for doing it, but due to a missing runtime dependency on cmake, now 
> reverse dependencies are FTBFS because of missing cmake
>
>
> The attached patch should fix the issue.
>
> thanks for considering it
>
> Gianfranco
>
> +znc (1.7.4-2.11) unstable; urgency=medium
> +
> +  * Add cmake dependency also as runtime dependency for reverse-dependencies 
> (Closes: #914783)
> +
> + -- Gianfranco Costamagna   Tue, 16 Jul 2019 
> 11:30:29 +0200
> +
>  znc (1.7.4-2) unstable; urgency=medium
>  
>* Switch to the cmake build system.
> diff -Nru znc-1.7.4/debian/control znc-1.7.4/debian/control
> --- znc-1.7.4/debian/control  2019-07-11 12:03:16.0 +
> +++ znc-1.7.4/debian/control  2019-07-16 09:30:28.0 +
> @@ -49,6 +49,7 @@
>  Architecture: any
>  Depends: ${misc:Depends},
>   ${python3:Depends},
> + cmake,
>   znc (>= ${binary:Version}),
>   libicu-dev,
>   libssl-dev,

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#918503: glusterfs-common: support files not separated from shared library

[Patrick Matthäi]

tag #918503 + pending
thanks

Am 06.01.2019 um 20:46 schrieb Helmut Grohne:
> Package: glusterfs-common
> Version: 5.2-1
> Severity: serious
> Justification: 8.2
> Tags: patch
> Control: block 881526 by -1
>
> glusterfs-common combines shared libraries with a lot of other files and
> even a glusterfs user. Doing so violates the Debian policy section 8.2:
>
> | If your package contains files whose names do not change with each
> | change in the library shared object version, you must not put them in
> | the shared library package.
>
> It is quite evident that the python module, firewalld integration,
> logrotate.d snippet and many other files will not change with an soname
> bump. Given that other packages (e.g. fio) link libglusterfs0, it is
> evident that libglusterfs0 is not a private shared library. Therefore
> glusterfs-common violates a policy must.
>
> The attached patch fixes that. I'm filing it as a separate bug, because
> the policy violation is much narrower in scope than #881526 is.
>
> Helmut

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#915345: Remove roar support for now? (Fixes FTBFS)

[Patrick Matthäi]

Am 09.01.2019 um 16:03 schrieb Helge Kreutzmann:
> Hello Ryan,
> cmus is marked for autoremoval, the freeze is approaching (where no
> removed packages are allowed to reenter testing) and I see no activity
> from the cmus side.
>
> Also at least the mpd developers are not very confident in the code
> quality of libroar
> https://github.com/MusicPlayerDaemon/MPD/commit/06ca08ce555
>
> I just checked, with the following patch cmus builds just fine
> (although of course without roaraudio), so I suggest to apply it at
> least until roaraudio is fixed:
>
> root@samd:/tmp# diff -u cmus-2.7.1+git20160225/debian/control 
> cmus-2.7.1+git20160225.new/debian/control
> --- cmus-2.7.1+git20160225/debian/control   2018-05-17 11:10:59.0 
> +0200
> +++ cmus-2.7.1+git20160225.new/debian/control   2019-01-09 15:21:35.615201691 
> +0100
> @@ -25,7 +25,6 @@
>   libncursesw5-dev,
>   libopusfile-dev,
>   libpulse-dev (>= 0.9.19),
> - libroar-dev,
>   libsamplerate0-dev,
>   libvorbis-dev,
>   libwavpack-dev,
> root@samd:/tmp# diff -u cmus-2.7.1+git20160225/debian/rules 
> cmus-2.7.1+git20160225.new/debian/rules
> --- cmus-2.7.1+git20160225/debian/rules 2018-05-17 11:10:59.0 +0200
> +++ cmus-2.7.1+git20160225.new/debian/rules 2019-01-09 15:47:02.105477216 
> +0100
> @@ -4,7 +4,7 @@
>  LDFLAGS+=-Wl,--as-needed
>  CFLAGS+=-I/usr/include/ncursesw
>
> -suggested_deps = pulse roar jack
> +suggested_deps = pulse jack
>
>  EXTRA_CMUS_DIR_OP_PLUGINS = debian/cmus/usr/lib/cmus/op/
>  EXTRA_CMUS_PLUGINS := $(foreach plugin,$(suggested_deps),$(plugin).so)
>
> Greetings
>
> Helge


Hello,

we just work on a fix for roaraudio currently. I just were on vacation
the whole december and got a longer backlog.





signature.asc
Description: OpenPGP digital signature

Bug#916764: znc-backlog: overly strict dependency on znc?

[Patrick Matthäi]

Am 28.12.2018 um 15:02 schrieb Felipe Sateler:
>
>
> On Fri, Dec 28, 2018 at 10:33 AM Patrick Matthäi  <mailto:pmatth...@debian.org>> wrote:
>
> Hola,
>
> Am 24.12.2018 um 12:44 schrieb Felipe Sateler:
>> > Perhaps znc could Provide: znc-plugin-$somenumber, which could
>> be used by
>>
>> > out-of-tree plugins? Adding the znc maintainers to the loop
>> for their input
>>
>> That's being used successfully by some packages ...
>>
>>
>> I'm creating a new bug for tracking this (better) solution.
>
>
> I dont know how this would help now after the relaxed dependency
> from znc-backlog, because..:
>
> * on changes znc-backlog still needs a binNMU or code changes,
> like now
>
>
> Right. But the current solution is still suboptimal. For example, if
> you upload a new package changing only metadata (say, the Vcs-*
> fields), znc-backlog would need a binNMU. In the more general case, a
> new upstream version of znc might not break the plugin ABI.
>  
>
> * I can provide a znc-plugin-$foobar package, but who ensures at
> an non stable api, if a change is necessary or not? I think it
> will make it more complicated or is there a nice solution for it?
>
> Indeed, this implies a lot more work for you.
>
>
Where a binNMU would be more safe and less work

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#916764: znc-backlog: overly strict dependency on znc?

[Patrick Matthäi]

Hola,

Am 24.12.2018 um 12:44 schrieb Felipe Sateler:
> > Perhaps znc could Provide: znc-plugin-$somenumber, which could be
> used by
>
> > out-of-tree plugins? Adding the znc maintainers to the loop for
> their input
>
> That's being used successfully by some packages ...
>
>
> I'm creating a new bug for tracking this (better) solution.


I dont know how this would help now after the relaxed dependency from
znc-backlog, because..:

* on changes znc-backlog still needs a binNMU or code changes, like now

* I can provide a znc-plugin-$foobar package, but who ensures at an non
stable api, if a change is necessary or not? I think it will make it
more complicated or is there a nice solution for it?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#917400: Depends: qtbase-abi-5-11-2 which is a virtual package and is not provided by any available package

[Patrick Matthäi]

Package: libkf5xmlgui5
Version: 5.51.0-1
Severity: serious

Hello,

currently libkf5xmlgui5 is not installable in sid (amd64):

The following packages have unmet dependencies:
 libkf5xmlgui5 : Depends: qtbase-abi-5-11-2 which is a virtual package and is 
not provided by any available package




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

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

Versions of packages libkf5xmlgui5 depends on:
ii  libc6 2.24-11+deb9u3
pn  libkf5attica5 
pn  libkf5configcore5 
pn  libkf5configgui5  
pn  libkf5configwidgets5  
pn  libkf5coreaddons5 
pn  libkf5globalaccel5
pn  libkf5i18n5   
pn  libkf5iconthemes5 
pn  libkf5itemviews5  
pn  libkf5textwidgets5
pn  libkf5widgetsaddons5  
pn  libkf5windowsystem5   
pn  libkf5xmlgui-data 
pn  libqt5core5a  
pn  libqt5dbus5   
pn  libqt5gui5
pn  libqt5network5
pn  libqt5printsupport5   
pn  libqt5widgets5
pn  libqt5xml5
ii  libstdc++66.3.0-18+deb9u1

Versions of packages libkf5xmlgui5 recommends:
pn  libkf5xmlgui-bin  

libkf5xmlgui5 suggests no packages.

Bug#912997: glusterfs: Several security vulnerabilities

[Patrick Matthäi]

fixed #912997 4.1.5-1
thanks

Hi


Am 05.11.2018 um 19:09 schrieb Markus Koschany:
> Package: glusterfs
> X-Debbugs-CC: t...@security.debian.org
> Severity: grave
> Tags: security
>
> Hi,
>
> The following vulnerabilities were published for glusterfs.
>
> CVE-2018-14651[0]:
> | It was found that the fix for CVE-2018-10927, CVE-2018-10928,
> | CVE-2018-10929, CVE-2018-10930, and CVE-2018-10926 was incomplete. A
> | remote, authenticated attacker could use one of these flaws to execute
> | arbitrary code, create arbitrary files, or cause denial of service on
> | glusterfs server nodes via symlinks to relative paths.
>
> CVE-2018-14652[1]:
> | The Gluster file system through versions 3.12 and 4.1.4 is vulnerable
> | to a buffer overflow in the 'features/index' translator via the code
> | handling the 'GF_XATTR_CLRLK_CMD' xattr in the 'pl_getxattr' function.
> | A remote authenticated attacker could exploit this on a mounted volume
> | to cause a denial of service.
>
> CVE-2018-14653[2]:
> | The Gluster file system through versions 4.1.4 and 3.12 is vulnerable
> | to a heap-based buffer overflow in the '__server_getspec' function via
> | the 'gf_getspec_req' RPC message. A remote authenticated attacker
> | could exploit this to cause a denial of service or other potential
> | unspecified impact.
>
> CVE-2018-14654[3]:
> | The Gluster file system through version 4.1.4 is vulnerable to abuse
> | of the 'features/index' translator. A remote attacker with access to
> | mount volumes could exploit this via the 'GF_XATTROP_ENTRY_IN_KEY'
> | xattrop to create arbitrary, empty files on the target server.
>
> CVE-2018-14659[4]:
> | The Gluster file system through versions 4.1.4 and 3.1.2 is vulnerable
> | to a denial of service attack via use of the
> | 'GF_XATTR_IOSTATS_DUMP_KEY' xattr. A remote, authenticated attacker
> | could exploit this by mounting a Gluster volume and repeatedly calling
> | 'setxattr(2)' to trigger a state dump and create an arbitrary number
> | of files in the server's runtime directory.
>
> CVE-2018-14660[5]:
> | A flaw was found in glusterfs server through versions 4.1.4 and 3.1.2
> | which allowed repeated usage of GF_META_LOCK_KEY xattr. A remote,
> | authenticated attacker could use this flaw to create multiple locks
> | for single inode by using setxattr repetitively resulting in memory
> | exhaustion of glusterfs server node.
>
> CVE-2018-14661[6]:
> | It was found that usage of snprintf function in feature/locks
> | translator of glusterfs server 3.8.4, as shipped with Red Hat Gluster
> | Storage, was vulnerable to a format string attack. A remote,
> | authenticated attacker could use this flaw to cause remote denial of
> | service.
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2018-14651
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14651
> [1] https://security-tracker.debian.org/tracker/CVE-2018-14652
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14652
> [2] https://security-tracker.debian.org/tracker/CVE-2018-14653
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14653
> [3] https://security-tracker.debian.org/tracker/CVE-2018-14654
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14654
> [4] https://security-tracker.debian.org/tracker/CVE-2018-14659
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14659
> [5] https://security-tracker.debian.org/tracker/CVE-2018-14660
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14660
> [6] https://security-tracker.debian.org/tracker/CVE-2018-14661
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-14661
>
> Please adjust the affected versions in the BTS as needed.
>
> Regards,
>
> Markus
>

If I see it correct, there is no issue open here?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#909551: qdirstat: Segfault immediately after choosing scan directory

[Patrick Matthäi]

Hi,


Am 25.09.2018 um 05:39 schrieb Ed Peguillan III:
> Package: qdirstat
> Version: 1.4-2
> Severity: grave
> Tags: a11y
> Justification: renders package unusable
>
> Dear Maintainer,
>
>* What led up to the situation?
>
>I installed qdirstat and launched it. It gave me a GTK(3?) prompt for
>choosing the directory I wish to scan. After choosing the directory
>and clicking "Open", it crashes. The message given when run from the
>terminal is "Segmentation fault". This happens when running
>with/without root privileges. Here is the log:
>
> 2018-09-24 22:36:10.956 [5046] Logger.cpp:143 openLogFile():  -- 
> Log Start --
> 2018-09-24 22:36:10.956 [5046] main.cpp:44 logVersion():  
> QDirStat-1.4 built with Qt 5.7.1
> 2018-09-24 22:36:11.070 [5046]DirTreeModel.cpp:549 sort():  
> Sorting by NameCol ascending
> 2018-09-24 22:36:11.070 [5046]TreemapView.cpp:124 
> setSelectionModel():  
> 2018-09-24 22:36:11.071 [5046] Cleanup.cpp:415 
> desktopSpecificApps():  Detected desktop "XFCE"
> 2018-09-24 22:36:11.071 [5046] Cleanup.cpp:468 
> desktopSpecificApps():  %filemanager => "thunar"
> 2018-09-24 22:36:11.071 [5046] Cleanup.cpp:468 
> desktopSpecificApps():  %terminal => "xfce4-terminal &"
> 2018-09-24 22:36:11.071 [5046]DebugHelpers.cpp:133 
> dumpExcludeRules():  
> 2018-09-24 22:36:11.071 [5046] MainWindow.cpp:818 
> toggleVerboseSelection():  Verbose selection is now off. Change this with 
> Shift-F7.
> 2018-09-24 22:36:12.818 [5046] DirTree.cpp:95 startReading(): 
> url: "/home/yankee"
> 2018-09-24 22:36:12.818 [5046] DirTree.cpp:98 startReading():  
> device: /dev/sda5
> 2018-09-24 22:36:12.818 [5046]DirReadJob.cpp:349 stat():  url: 
> "/home/yankee"
> 2018-09-24 22:36:12.818 [5046]MainWindow.cpp:589 
> expandTreeToLevel():  Expanding tree to level 1
> 2018-09-24 22:36:12.835 [5046]DirReadJob.cpp:248 startReading():  
> Found cache file .qdirstat.cache.gz
> 2018-09-24 22:36:12.836 [5046]DirReadJob.cpp:260 startReading():  
> Using cache file /home/yankee/.qdirstat.cache.gz for /home/yankee
> 2018-09-24 22:36:12.836 [5046]DirReadJob.cpp:544 killAll():  NOT 
> killing read job 
> 2018-09-24 22:36:12.836 [5046]DirReadJob.cpp:278 startReading():  
> Deleting subtree /home/yankee
> 2018-09-24 22:36:12.836 [5046]DirTree.cpp:237 
> deletingChildNotify():  Deleting child /home/yankee
> 2018-09-24 22:36:12.836 [5046]DirTreeModel.cpp:918 
> deletingChild():  Deleting child /home/yankee
> 2018-09-24 22:36:12.836 [5046]DirTreeModel.cpp:926 
> deletingChild():  beginRemoveRows for /home/yankee row 0
> 2018-09-24 22:36:12.836 [5046]DirTreeModel.cpp:984 
> invalidatePersistent():  Invalidating  >
>

Does it work again if you delete /home/yankee/.qdirstat.cache.gz ?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#898483: PHYSFS_setWriteDir creates an empty file

[Patrick Matthäi]

Hi,


Am 12.05.2018 um 17:40 schrieb Markus Koschany:
> Hello Patrick,
>
> Am 12.05.2018 um 16:19 schrieb James Cowgill:
> [...]
>> I think this is a bug in libphysfs 3.0.1. It seems that in this version
>> (unlike 2.0.3), PHYSFS_setWriteDir has the side effect of creating an
>> empty file if the path it is given does not exist. This will later cause
>> PHYSFS_mkdir to fail even if it's given the right path.
>>
>> This would also explain why this bug is not present in stretch.
> A bug was reported against lincity-ng but it looks more like this is a
> regression/bug in libphysfs 3.0.1. The setWriteDir function creates an
> empty file which makes the mkdir function fail later on. Shall I
> reassign this bug report to libphysfs?
>
> Regards,
>
> Markus

Maybe upstream can say something about it? :) =>:

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

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#820517: (no subject)

[Patrick Matthäi]

Hi,

I just want to wait on 1.7 and then everything is fine


Am 26.04.2018 um 20:35 schrieb Alexey Sokolov:
> Hi
> Can we just drop znc-tcl package? It's not necessary for the rest of
> ZNC, and is rarely used.
> But I'm going to release ZNC 1.7 soon where this is fixed.
>

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#894313: etherape: Crashes on startup

[Patrick Matthäi]

Hi,

with 0.9.15+hg20171110-1 it should be possible to run etherape without
libgnomeui?

Am 01.04.2018 um 00:44 schrieb John Scott:
> Package: etherape > Version: 0.9.16-1 > Followup-For: Bug #894313 >
> I am able to reproduce this issue, but installing libgnomeui-0
> (which provides libgnome.so) fixes it for me. Like the upstream
> report suggests, this looks like a missing dependency.
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing-debug
>   APT policy: (500, 'testing-debug'), (500, 'testing')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.15.0-2-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 etherape depends on:
> ii  etherape-data    0.9.16-1
> ii  libart-2.0-2 2.3.21-3
> ii  libatk1.0-0  2.28.1-1
> ii  libc-ares2   1.14.0-1
> ii  libc6    2.27-2
> ii  libcairo2    1.15.10-1
> ii  libfontconfig1   2.12.6-0.1
> ii  libfreetype6 2.8.1-2
> ii  libgdk-pixbuf2.0-0   2.36.11-2
> ii  libglade2-0  1:2.6.4-2+b1
> ii  libglib2.0-0 2.56.0-4
> ii  libgnomecanvas2-0    2.30.3-3
> ii  libgtk2.0-0  2.24.32-1
> ii  libpango-1.0-0   1.42.0-1
> ii  libpangocairo-1.0-0  1.42.0-1
> ii  libpangoft2-1.0-0    1.42.0-1
> ii  libpcap0.8   1.8.1-6
> ii  libpopt0 1.16-10+b2
> ii  libxml2  2.9.4+dfsg1-6.1
>
> etherape recommends no packages.
>
> etherape suggests no packages.
>
> -- no debconf information
>

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
    patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#876459: needrestart: Non-interactive mode not being detected properly

[Patrick Matthäi]

Am 22.02.2018 um 13:44 schrieb Dominik George:
> Hi Patrick,
>
>> I regularly see this bug cause important PostgreSQL databases to be
>> restarted on Debian stable.
>>
>> Can you please make sure to provide an update for the next Debian point
>> release? If you need help doing so, feel free to say that.
> Any news/opinion on that?
>
> If I do not hear anything from you within this week, I will start
> negotiating with therelease team about the patch for the next point
> release.
>
> Cheers,
> Nik

Hi,

I am sorry, your messages went to my junk folder, I just saw the
accepted upload now.
Many thanks for taking care of this!

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/




signature.asc
Description: OpenPGP digital signature

Bug#876462: Fwd: Bug#876462: otrs2: CVE-2017-14635: Code Injection / Privilege Escalation OTRS

[Patrick Matthäi]

Hello Martin and everyone else,

could you help here? Is this the correct commit for CVE-2017-14635?

 Weitergeleitete Nachricht 

On Fri, 22 Sep 2017 16:31:00 +0200 Salvatore Bonaccorso
 wrote:
[...]
> Unfortunately the patches are not referenced, so must be researched in
> the repository.

I had a look at this issue. I have found

https://github.com/OTRS/otrs/commit/a4093dc404fcbd87b235b31c72913141672f2a85

which was introduced in version 5.0.23 that fixed the vulnerability. It
is the only commit that mentions the keywords agent and statistics but
I'm not sure if the commit is sufficient. I suggest to contact upstream
about this and ask for a clarification.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#873878: [gluster-packaging] Fwd: Bug#873878: glusterfs-client: mount.glusterfs needs bash as /bin/sh

[Patrick Matthäi]

Am 01.09.2017 um 11:40 schrieb Niels de Vos:
> On Fri, Sep 01, 2017 at 09:36:16AM +0200, Patrick Matthäi wrote:
>> Hi,
>>
>> how should it be fixed for glusterfs now? Better shell code without
>> bashishm or do you want /bin/bash as shebang?
> Do you have a preference? I do not know how much work is it is to
> rewrite the mount.glusterfs script to remove all the Bashisms. At least
> in the Debian builds you may want to patch it to /bin/bash for the time
> being.

I would prefer a patch, so that it works without bash. Luckily the bug
reporter just wrote a patch :)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873878#10

If you would merge it, I also would add it to the repository. I have
attached two other patches for 3.12.x, too.

>
> Opinions welcome :) Thanks,
> Niels
>
>>
>>
>>  Weitergeleitete Nachricht 
>> Betreff: Bug#873878: glusterfs-client: mount.glusterfs needs bash as
>> /bin/sh
>> Weitersenden-Datum:  Thu, 31 Aug 2017 20:21:01 +
>> Weitersenden-Von:Michael Lundkvist 
>> Weitersenden-An: debian-bugs-d...@lists.debian.org
>> Weitersenden-CC: Patrick Matthäi 
>> Datum:   Thu, 31 Aug 2017 21:46:18 +0200
>> Von: Michael Lundkvist 
>> Antwort an:  Michael Lundkvist ,
>> 873...@bugs.debian.org
>> An:  Debian Bug Tracking System 
>>
>>
>>
>> Package: glusterfs-client
>> Version: 3.12.0-1
>> Severity: serious
>> Tags: upstream
>> Justification: Policy 10.4
>>
>> Version 3.12 of Glusterfs adds code in /sbin/mount.glusterfs that depends on 
>> bash.
>>
>> With dash as /bin/sh, I get the following error message when trying to mount 
>> a glusterfs volume:
>>> /sbin/mount.glusterfs: 667: /sbin/mount.glusterfs: Bad substitution
>> Line 667 is:
>> 667 [ ${volume_str:0:1} = '/' ] && {
>>
>> Modifying mount.glusterfs to use /bin/bash makes it possible to mount again.
>>
>> /Micke
>>
>>
>> -- System Information:
>> Debian Release: buster/sid
>>   APT prefers unstable
>>   APT policy: (500, 'unstable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=en_US:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages glusterfs-client depends on:
>> ii  fuse  2.9.7-1
>> ii  glusterfs-common  3.12.0-1
>> ii  libc6 2.24-17
>> ii  libssl1.1 1.1.0f-5
>> ii  python2.7.13-2
>>
>> glusterfs-client recommends no packages.
>>
>> glusterfs-client suggests no packages.
>>
>> -- no debconf information
>>
>> ___
>> packaging mailing list
>> packag...@gluster.org
>> http://lists.gluster.org/mailman/listinfo/packaging

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

# Fix syntax error in shell script.

diff -Naur 
glusterfs-3.11.1.orig/extras/hook-scripts/create/post/S10selinux-label-brick.sh 
glusterfs-3.11.1/extras/hook-scripts/create/post/S10selinux-label-brick.sh
--- 
glusterfs-3.11.1.orig/extras/hook-scripts/create/post/S10selinux-label-brick.sh 
2017-06-27 17:25:12.237136825 +0200
+++ glusterfs-3.11.1/extras/hook-scripts/create/post/S10selinux-label-brick.sh  
2017-07-03 16:21:05.113301642 +0200
@@ -43,7 +43,7 @@
 do
 # Add a file context for each brick path and associate with the
 # glusterd_brick_t SELinux type.
-semanage fcontext --add -t glusterd_brick_t -r s0 $b(/.*)?
+semanage fcontext --add -t glusterd_brick_t -r s0 $b
 
 # Set the labels on the new brick path.
 restorecon -R $b
# Fix new spelling errors.

diff -Naur glusterfs-3.12.0.orig/xlators/mgmt/glusterd/src/glusterd-geo-rep.c 
glusterfs-3.12.0/xlators/mgmt/glusterd/src/glusterd-geo-rep.c
--- glusterfs-3.12.0.orig/xlators/mgmt/glusterd/src/glusterd-geo-rep.c  
2017-08-30 14:46:33.875359178 +0200
+++ glusterfs-3.12.0/xlators/mgmt/glusterd/src/glusterd-geo-rep.c   
2017-08-31 10:43:14.228479030 +0200
@@ -3615,7 +3615,7 @@
 "geo-replication start failed",
 strerror (errno));
 snprintf (errmsg, sizeof(errmsg),
-  "fuse unvailable");
+ 

Bug#869837: kdenlive: busy loop

[Patrick Matthäi]

If I understood you correct you have started with .3, so if you upgrade,
delete again the config directories and try to use it again, still there
the issue?


Am 27.07.2017 um 10:23 schrieb Salvo Tomaselli:
> I deleted all my .kdenlive data and downgraded to .2 and it doesn't
> seem to have the issue.
>
> But now it might be difficult to reproduce, because I didn't think of
> keeping it or the cache.
>
> 2017-07-27 9:56 GMT+02:00 Patrick Matthäi :
>> Am 27.07.2017 um 00:32 schrieb Salvo Tomaselli:
>>> Package: kdenlive
>>> Version: 17.04.3-1
>>> Severity: grave
>>> Justification: renders package unusable
>>>
>>> Dear Maintainer,
>>> kdenlive does a busy loop, and is basically keeping the CPU too busy doing
>>> that, to actually do anything productive.
>>>
>>> When I start it, CPU jumps at 100%.
>> Could you reproduce this issue with kdenlive < 17.04.3? What happens if
>> you try it out with a fresh profile.
>>
>>> with strace I get this:
>>>
>>> futex(0x4aafe807c4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x4aafe807c0, 
>>> FUTEX_OP_SET<<28|0<<12|FUTEX_OP_CMP_GT<<24|0x1) = 1
>>> writev(3, 
>>> [{iov_base="\n\0\2\0\25\0\340\3\31\0\v\0\347\0\0\0\0\0\30\0\22\\tZ\347\0\0\0\25\0\340\3"...,
>>>  iov_len=52}], 1) = 52
>>> futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 1
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
>>> writev(3, [{iov_base="\2\0\4\0\33\0\340\3\0@\0\0\230\1\340\3", 
>>> iov_len=16}], 1) = 16
>>> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
>>> writev(3, [{iov_base="\22\0\7\0\33\0\340\3y\1\0\0\6\0\0\0 
>>> \0\0\0\1\0\0\0Sk\316\3\10\0\2\0"..., iov_len=40}], 1) = 40
>>> futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 1
>>> futex(0x7ffd5a745bd0, FUTEX_WAKE_PRIVATE, 1) = 1
>>> futex(0x7ffd5a745bd4, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource 
>>> temporarily unavailable)
>>> futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 0
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> write(5, "\1\0\0\0\0\0\0\0", 8) = 8
>>> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}])
>>> writev(3, [{iov_base="\22\0\7\0\25\0\340\3y\1\0\0\6\0\0\0 
>>> \0\0\0\1\0\0\0Sk\316\3\10\0\2\0"..., iov_len=40}], 1) = 40
>>> futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 1
>>> futex(0x7ffd5a745f40, FUTEX_WAKE_PRIVATE, 1) = 1
>>> futex(0x7ffd5a745f44, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EAGAIN (Resource 
>>> temporarily unavailable)
>>> futex(0x4aafe80798, FUTEX_WAKE_PRIVATE, 1) = 0
>>>
>>> Over and over.
>>>
>>> Best.
>>&g

Bug#869837: kdenlive: busy loop

[Patrick Matthäi]

.28.0-2
> ii  libkf5bookmarks5 5.28.0-1
> ii  libkf5codecs55.28.0-1+b2
> ii  libkf5completion55.28.0-1
> ii  libkf5configcore55.28.0-2
> ii  libkf5configgui5 5.28.0-2
> ii  libkf5configwidgets5 5.28.0-2
> ii  libkf5coreaddons55.28.0-2
> ii  libkf5crash5 5.28.0-1
> ii  libkf5dbusaddons55.28.0-1
> ii  libkf5filemetadata3  5.28.0-1+b2
> ii  libkf5guiaddons5 5.28.0-1
> ii  libkf5i18n5  5.28.0-2
> ii  libkf5iconthemes55.28.0-2
> ii  libkf5itemviews5 5.28.0-1
> ii  libkf5jobwidgets55.28.0-2
> ii  libkf5kiocore5   5.28.0-2
> ii  libkf5kiofilewidgets55.28.0-2
> ii  libkf5kiowidgets55.28.0-2
> ii  libkf5newstuff5  5.28.0-1
> ii  libkf5notifications5 5.28.0-1
> ii  libkf5notifyconfig5  5.28.0-1
> ii  libkf5service-bin5.28.0-1
> ii  libkf5service5   5.28.0-1
> ii  libkf5solid5 5.28.0-4
> ii  libkf5sonnetui5  5.28.0-2+b1
> ii  libkf5textwidgets5   5.28.0-1
> ii  libkf5widgetsaddons5 5.28.0-3
> ii  libkf5xmlgui55.28.0-1
> ii  libmlt++36.4.1-5+b1
> ii  libmlt6  6.4.1-5+b1
> ii  libqt5concurrent55.7.1+dfsg-4
> ii  libqt5core5a 5.7.1+dfsg-4
> ii  libqt5dbus5  5.7.1+dfsg-4
> ii  libqt5gui5   5.7.1+dfsg-4
> ii  libqt5network5   5.7.1+dfsg-4
> ii  libqt5qml5   5.7.1-2+b2
> ii  libqt5quick5 5.7.1-2+b2
> ii  libqt5script5        5.7.1~20161021+dfsg-2
> ii  libqt5svg5   5.7.1~20161021-2+b2
> ii  libqt5widgets5   5.7.1+dfsg-4
> ii  libqt5xml5   5.7.1+dfsg-4
> ii  libstdc++6   7.1.0-10
> ii  libv4l-0 1.12.5-1
> ii  melt 6.4.1-5+b1
> ii  oxygen-icon-theme5:5.28.0-1
> ii  qml-module-qtquick-controls  5.7.1~20161021-2
> ii  qml-module-qtquick2  5.7.1-2+b2
>
> Versions of packages kdenlive recommends:
> pn  dvdauthor
> pn  dvgrab   
> pn  frei0r-plugins   
> pn  genisoimage  
> pn  recordmydesktop  
> pn  swh-plugins  
>
> Versions of packages kdenlive suggests:
> pn  khelpcenter  
>
> -- no debconf information

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

[Patrick Matthäi]

Am 18.07.2017 um 13:29 schrieb Bernhard Schmidt:
>>>> I've browsed through the git commits between 2.4.0 and 2.4.3, these
>>>> might be relevant here
>>>>
>>>> https://community.openvpn.net/openvpn/ticket/812
>>>> https://community.openvpn.net/openvpn/ticket/887
>>>>
>>>> Are you able to build a version with these patches applied yourself?
>>> I will build it for one of the notworking nodes and see what happens and
>>> give a feedback
>> Yeah very nice! With both patches applied it is working :D Like the
>> version 2.4.3-4 I get now a "NOTE: Pulled options changed on restart,
>> will need to close and reopen TUN/TAP device", all routes are removed
>> and readded and the connection works again. Two hosts, which are not
>> working after a restart of the server, do not have got this and refuse
>> to work.
> Can you try to test which of those it is? I need a specific patch to get
> into stable.

I have tested it three times, it is definitly
https://community.openvpn.net/openvpn/ticket/812 which fixes this issue

>
>> Would love to see these patches in 9.1 :)
> 9.1 is already frozen, but I will submit it into 9.2 as soon as I know
> which patch it is.

Urgs right.. ;)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

[Patrick Matthäi]

Am 18.07.2017 um 13:05 schrieb Patrick Matthäi:
>> I've browsed through the git commits between 2.4.0 and 2.4.3, these
>> might be relevant here
>>
>> https://community.openvpn.net/openvpn/ticket/812
>> https://community.openvpn.net/openvpn/ticket/887
>>
>> Are you able to build a version with these patches applied yourself?
> I will build it for one of the notworking nodes and see what happens and
> give a feedback

Yeah very nice! With both patches applied it is working :D Like the
version 2.4.3-4 I get now a "NOTE: Pulled options changed on restart,
will need to close and reopen TUN/TAP device", all routes are removed
and readded and the connection works again. Two hosts, which are not
working after a restart of the server, do not have got this and refuse
to work.
Would love to see these patches in 9.1 :)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

[Patrick Matthäi]

Am 18.07.2017 um 12:58 schrieb Bernhard Schmidt:
> The notworking version does nothing like this. This smells like a bug.
>
> What I don't understand is that you claim the VPN endpoint is not
> reachable on the dead nodes (the outer IP I presume). Both nodes still
> have a hostroute towards the VPN gateway in their routing table
>
I mean not the external VPN endpoint address, but the VPN internal
server address (10.200.13.1 here).
>
> I've browsed through the git commits between 2.4.0 and 2.4.3, these
> might be relevant here
>
> https://community.openvpn.net/openvpn/ticket/812
> https://community.openvpn.net/openvpn/ticket/887
>
> Are you able to build a version with these patches applied yourself?

I will build it for one of the notworking nodes and see what happens and
give a feedback

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

[Patrick Matthäi]

Am 12.07.2017 um 16:17 schrieb Bernhard Schmidt:
> Am 12.07.2017 um 15:41 schrieb Patrick Matthäi:
>
> Hi,
>
>>>> we have got the same issue with all our VPNs upgraded to Stretch now.
>>>> Most VPNs are connected about a 1 GBit/s datacenter connection with each
>>>> other (also same LAN), the other ones are connected about a 100 MBit/s
>>>> connection.
>>>
>> I also uploaded the current testing version to stretch-bpo and deployed
>> it on one host, to see if there is a difference later
> Ah, I was already wondering who did.
>
>

Today I updated our Sophos UTM, which is one OpenVPN server, where are
here multiple vpn clients are connected with. While updating the UTM,
there are 2 reboots of the devices, so the client needs a reconnect.

The client with version openvpn_2.4.3-4~bpo9+1 still works, all
2.4.0-6+deb9u1 are dead. Also the VPN endpoint is not reachable on the
dead nodes.
Please note, that I replaced many IPs and hostnames with other stuff.

Working one (tun0 affected, tun1 is another VPN):

Jul 18 09:32:25 login ovpn-utm[8335]: [address.of.utm.de] Inactivity
timeout (--ping-restart), restarting
Jul 18 09:32:25 login ovpn-utm[8335]: SIGUSR1[soft,ping-restart]
received, process restarting
Jul 18 09:32:25 login ovpn-utm[8335]: Restart pause, 5 second(s)
Jul 18 09:32:30 login ovpn-utm[8335]: TCP/UDP: Preserving recently used
remote address: [AF_INET]EXT.IP.FROM.VPN:1197
Jul 18 09:32:30 login ovpn-utm[8335]: Socket Buffers: R=[212992->212992]
S=[212992->212992]
Jul 18 09:32:30 login ovpn-utm[8335]: UDP link local: (not bound)
Jul 18 09:32:30 login ovpn-utm[8335]: UDP link remote:
[AF_INET]EXT.IP.FROM.VPN:1197
Jul 18 09:32:30 login ovpn-utm[8335]: TLS: Initial packet from
[AF_INET]EXT.IP.FROM.VPN:1197, sid=4030f3bf 8b41b71f
Jul 18 09:32:31 login ovpn-utm[8335]: VERIFY OK: depth=1, C=de,
L=Paderborn, O=company Internet GmbH, CN=company Internet GmbH VPN CA,
emailAddress=tech...@company.de
Jul 18 09:32:31 login ovpn-utm[8335]: VERIFY X509NAME OK: C=de,
ST=Nordrhein-Westfalen, L=Paderborn, O=company Internet GmbH,
OU=Technik, CN=address.of.utm.de, emailAddress=tech...@company.de
Jul 18 09:32:31 login ovpn-utm[8335]: VERIFY OK: depth=0, C=de,
ST=Nordrhein-Westfalen, L=Paderborn, O=company Internet GmbH,
OU=Technik, CN=address.of.utm.de, emailAddress=tech...@company.de
Jul 18 09:32:33 login ovpn-utm[8335]: Control Channel: TLSv1.2, cipher
TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 4096 bit RSA
Jul 18 09:32:33 login ovpn-utm[8335]: [address.of.utm.de] Peer
Connection Initiated with [AF_INET]EXT.IP.FROM.VPN:1197
Jul 18 09:32:34 login ovpn-utm[8335]: SENT CONTROL [address.of.utm.de]:
'PUSH_REQUEST' (status=1)
Jul 18 09:32:35 login ovpn-utm[8335]: PUSH: Received control message:
'PUSH_REPLY,route-gateway 10.200.13.1,route-gateway 10.200.13.1,topology
subnet,ping 10,ping-restart 120,route INT.BEHIND.VPN2.0
255.255.255.0,route INT.BEHIND.VPN1.0 255.255.255.0,dhcp-option DNS
INT.BEHIND.VPN1.210,dhcp-option DNS INT.BEHIND.VPN2.250,dhcp-option
DOMAIN domäne.intern,ifconfig 10.200.13.4 255.255.255.0'
Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: timers and/or
timeouts modified
Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: --ifconfig/up
options modified
Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: route options modified
Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: route-related
options modified
Jul 18 09:32:35 login ovpn-utm[8335]: OPTIONS IMPORT: --ip-win32 and/or
--dhcp-option options modified
Jul 18 09:32:35 login ovpn-utm[8335]: Data Channel Encrypt: Cipher
'AES-256-CBC' initialized with 256 bit key
Jul 18 09:32:35 login ovpn-utm[8335]: Data Channel Encrypt: Using 256
bit message hash 'SHA256' for HMAC authentication
Jul 18 09:32:35 login ovpn-utm[8335]: Data Channel Decrypt: Cipher
'AES-256-CBC' initialized with 256 bit key
Jul 18 09:32:35 login ovpn-utm[8335]: Data Channel Decrypt: Using 256
bit message hash 'SHA256' for HMAC authentication
Jul 18 09:32:35 login ovpn-utm[8335]: Preserving previous TUN/TAP
instance: tun0
Jul 18 09:32:35 login ovpn-utm[8335]: NOTE: Pulled options changed on
restart, will need to close and reopen TUN/TAP device.
Jul 18 09:32:35 login ovpn-utm[8335]: /sbin/ip route del EXT.IP.FROM.VPN/32
Jul 18 09:32:35 login ovpn-utm[8335]: /sbin/ip route del
INT.BEHIND.VPN2.0/24
Jul 18 09:32:35 login ovpn-utm[8335]: /sbin/ip route del
INT.BEHIND.VPN1.0/24
Jul 18 09:32:35 login ovpn-utm[8335]: Closing TUN/TAP interface
Jul 18 09:32:35 login ovpn-utm[8335]: /sbin/ip addr del dev tun0
10.200.13.2/24
Jul 18 09:32:36 login ovpn-utm[8335]: ROUTE_GATEWAY
TWO.NETWORK.2.1/255.255.255.0 IFACE=eth0 HWADDR=00:0c:29:cd:45:cc
Jul 18 09:32:36 login ovpn-utm[8335]: TUN/TAP device tun0 opened
Jul 18 09:32:36 login ovpn-utm[8335]: TUN/TAP TX queue length set to 100
Jul 18 09:32:36 login ovpn-utm[8335]: do_ifconfig,
tt->did_ifco

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

[Patrick Matthäi]

Am 12.07.2017 um 12:10 schrieb Bernhard Schmidt:
> On Wed, Jul 12, 2017 at 09:35:53AM +0200, Patrick Matthäi wrote:
>
> Hi,
>
>> we have got the same issue with all our VPNs upgraded to Stretch now.
>> Most VPNs are connected about a 1 GBit/s datacenter connection with each
>> other (also same LAN), the other ones are connected about a 100 MBit/s
>> connection.
>
>> route remote_host 255.255.255.255 net_gateway
> This suggests that the VPN server is inside the netblocks routed through
> the tunnel, right?
If I understood you correct: yes - all VPNs are "clients"
>
> When the problem happens, can you check whether the static /32 route
> towards the VPN server still exists and points outside the tunnel.
We will check if it occurs again and give you the output of "ip {a,r,l}"
Anything else needed?
>
> Please also check a couple of minutes before the ping timeout whether you
> see anything network related. Are you using ifupdown or NetworkManager
> on the client?
>
> Bernhard
>

That is mostly hard to check, because that are many endpoints and
clients. One client is located in the hosteurope network, which had got
a maintainance this night (with a short outage), but also many other
customer VPNs (sophos, self hosted VPNs and so on) were affected from
different locations and links. So I dont think that this is the whole
thing triggering this bug.

I also uploaded the current testing version to stretch-bpo and deployed
it on one host, to see if there is a difference later

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

[Patrick Matthäi]

severity #863110 serious
thanks

Hi,

we have got the same issue with all our VPNs upgraded to Stretch now.
Most VPNs are connected about a 1 GBit/s datacenter connection with each
other (also same LAN), the other ones are connected about a 100 MBit/s
connection.

Example configuration:

client
dev tun
proto udp
remote XYZ 1197
verify-x509-name "C=de, ST=Nordrhein-Westfalen, L=, O=.,
OU=, CN=, emailAddress="
route remote_host 255.255.255.255 net_gateway
resolv-retry infinite
nobind
persist-key
persist-tun
ca 
cert 
key .
auth-user-pass 
cipher AES-256-CBC
auth SHA256
comp-lzo
route-delay 4
verb 3
reneg-sec 0

The only thing I have got in my logs is e.g. this:

Jul 12 03:02:39 HOST ovpn-ABC_network[20317]: [gateway01] Inactivity
timeout (--ping-restart), restarting
Jul 12 03:02:39 HOST ovpn-ABC_network[20317]: SIGUSR1[soft,ping-restart]
received, process restarting
Jul 12 03:02:39 HOST ovpn-ABC_network[20317]: Restart pause, 5 second(s)
Jul 12 03:02:44 HOST ovpn-ABC_network[20317]: TCP/UDP: Preserving
recently used remote address: [AF_INET].:3
Jul 12 03:02:44 HOST ovpn-ABC_network[20317]: Socket Buffers:
R=[87380->87380] S=[16384->16384]
Jul 12 03:02:44 HOST ovpn-ABC_network[20317]: Attempting to establish
TCP connection with [AF_INET]..:3 [nonblock]

Jul 12 03:04:44 HOST ovpn-ABC_network[20317]: TCP: connect to
[AF_INET]:3 failed: Connection timed out
Jul 12 03:04:44 HOST ovpn-ABC_network[20317]: SIGUSR1[connection
failed(soft),init_instance] received, process restarting
Jul 12 03:04:44 HOST ovpn-ABC_network[20317]: Restart pause, 5 second(s)
Jul 12 03:04:49 HOST ovpn-ABC_network[20317]: TCP/UDP: Preserving
recently used remote address: [AF_INET]:3
Jul 12 03:04:49 HOST ovpn-ABC_network[20317]: Socket Buffers:
R=[87380->87380] S=[16384->16384]
Jul 12 03:04:49 HOST ovpn-ABC_network[20317]: Attempting to establish
TCP connection with [AF_INET]..:3 [nonblock]

After this the connection was down, until we manualy restarted it.

Since all Stretch VPNs are affected here  raised the severity of this issue.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#867884: classic UI does not work because of missign javascript

[Patrick Matthäi]

Package: icinga2-classicui
Severity: serious
Version: 2.6.0-2

Hi,

icinga2 classic UI required jquery and jquery-ui. However you are not
using the embedded version and the icinga version in Debian is not
compatible(?) with the delivered versions from stable. This results in
many 404 (see screenshot) requests and a not working UI (missing
actions, dropdowns and so on). I checked some files and most of them do
not exist (anymore) in the stable repository. Most of them are embedded
in other packages. For example:

root@ims:~# LC_ALL=C dpkg -S jquery.ui.menu.js
dpkg-query: no path found matching pattern *jquery.ui.menu.js*

root@ims:~# apt-file search jquery.ui.menu.js
ganglia-webfrontend:
/usr/share/ganglia-webfrontend/contrib/jquery-ui-1.10.2/ui/jquery.ui.menu.js
mediawiki: /usr/share/mediawiki/resources/lib/jquery.ui/jquery.ui.menu.js
root@ims:~#

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#866993: glusterfs-common: broken symlink: /usr/share/glusterfs/scripts/gsync-sync-gfid -> ../../../lib/glusterfs/gsync-sync-gfid

[Patrick Matthäi]

tag #866993 + pending
severity #866993 normal
thanks

A broken symlink is not severity serious

Am 03.07.2017 um 11:58 schrieb Andreas Beckmann:
> Package: glusterfs-common
> Version: 3.11.1-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
>
> >From the attached log (scroll to the bottom...):
>
> 0m27.9s ERROR: FAIL: Broken symlinks:
>   /usr/share/glusterfs/scripts/gsync-sync-gfid -> 
> ../../../lib/glusterfs/gsync-sync-gfid
>
>
> The target seems to have disappeared recently.
>
>
> cheers,
>
> Andreas

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#864319: CVE-2017-9324

[Patrick Matthäi]

Am 06.06.2017 um 22:37 schrieb Moritz Muehlenhoff:
> Package: otrs
> Severity: grave
> Tags: security
>
> Hi,
> details are sparse on this one, could you get in touch with upstream to
> isolate this to the change in question?
> https://www.otrs.com/security-advisory-2017-03-security-update-otrs-versions/
>
> Cheers,
> Moritz

I will try. On which way should I fix Stretch? stretch-security updates
or direct upload to Stretch?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#854066: linux-image-4.9.0-1-amd64: Several HP desktops do not wake up anymore since 4.9

[Patrick Matthäi]

p=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.9.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.127
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.2

Versions of packages linux-image-4.9.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta3-3
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-1-amd64 is related to:
ii  firmware-amd-graphics 20161130-2
pn  firmware-atheros  
ii  firmware-bnx2 20161130-2
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20161130-2
ii  firmware-misc-nonfree 20161130-2
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20161130-2
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#851113: manaplus: violates font license

[Patrick Matthäi]

Hi Andrei,

please see the below report. This has to be fixed so that manaplus could
release with Stretch


On Thu, 12 Jan 2017 13:56:27 +0800 Paul Wise  wrote:
> Source:Â manaplus
> Version:Â 1.7.1.7-1
> Severity: serious
> User: pkg-fonts-de...@lists.alioth.debian.org
> Usertags: license-violation
> X-Debbugs-CC: pkg-fonts-de...@lists.alioth.debian.org
>
> Your source package contains an GPL/LGPL font:
>
> data/fonts/liberationsans.ttf
> data/fonts/liberationsansmono.ttf
> data/fonts/liberationsans-bold.ttf
> data/fonts/liberationsansmono-bold.ttf
>
> This looks to be from here:
>
> https://fedorahosted.org/liberation-fonts/
>
> The font's source code appears to be here:
>
> https://git.fedorahosted.org/cgit/liberation-fonts.git/tree/src
>
> Your source package does not contain the font source code, therefore
> your distribution of the font constitutes a violation of the license.
>
> Please notify your upstream that they are violating the font license.
>
> Please remove the font from the source package and build-depend or
> depend on the fonts-liberation binary font package instead.
>
> Please contact your upstream and ask them to use fontconfig or similar
> to get fonts for use by the software instead of using a specific font.
>
> This message is brought to you by the Debian Fonts Task Force:
>
> http://wiki.debian.org/Fonts
>
> --
> bye,
> pabs
>
> ht


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#818961: [Debian-ha-maintainers] Freeze status, Heartbeat plans

[Patrick Matthäi]

Am 21.12.2016 um 15:19 schrieb Christoph Berg:
> Re: Patrick Matthäi 2016-12-21 
> <89f2fc7d-a3a0-a01f-8105-7f795b0d2...@debian.org>
>> We tried out many test cases, workarounds, debugging on this issue and
>> the result was, that the v1 mode of heartbeat can not deal with the
>> dependency system of systemd and will never support it.
> Hmm, I don't get what the dependency system has to do with it, versus
> a plain "heartbeat invoking systemctl via init scripts" breakage, or
> something like that.
>
>> I still think, this is the best solution (since only v1 mode is affected):
>> "IMO the package should warn (debconf dialog prio high?) the user if he
>> upgrades heartbeat and systemd+v1 config is in use."
> That still requires someone to understand the problem and explain it
> in the warning. Just saying "it might be broken but we don't know
> which bits you need to check" won't work.

Simple service/host failovers will not work. the system will mostly stay
in a not working state. Dont ask me too much now, sorry just came back
from vacation and now I do not have the time to re-setup and debug
everything again.
Maybe someone else saved the irc logs (just search for the-me in the
debian-ha channel on oftc)

>
>> Removing the whole heartbeat package would not be a good solution, since
>> it is still required?
> It doesn't have any reverse dependencies anymore. At the moment it's
> the only HA package not in testing, so it isn't holding back any other
> package. Effectively, it is already removed now (from testing).
>
> Christoph

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#818961: [Debian-ha-maintainers] Freeze status, Heartbeat plans

[Patrick Matthäi]

Am 21.12.2016 um 13:27 schrieb Valentin Vidic:
> On Wed, Dec 21, 2016 at 01:15:12PM +0100, Patrick Matthäi wrote:
>> We tried out many test cases, workarounds, debugging on this issue and
>> the result was, that the v1 mode of heartbeat can not deal with the
>> dependency system of systemd and will never support it.
> Not sure what could be the problem with systemd dependencies.
> Do you remember which services were involved so we can do a
> quick test?
>

DRBD+lvm+ext4, apache and mariadb should be enough

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#818961: [Debian-ha-maintainers] Freeze status, Heartbeat plans

[Patrick Matthäi]

Am 21.12.2016 um 11:50 schrieb Christoph Berg:
> Re: Valentin Vidic 2016-12-20 
> <20161220134034.grvwdktsmtbij...@gavran.carpriv.carnet.hr>
>> And if there are big issues with systemd support I think there would be
>> more bug reports for the jessie version of this package already?
> It might be that with the previously poor state of HA in Jessie, users
> aren't really reporting issues of that kind anymore :(
>
> I guess the basic question is if we want to continue to ship&support
> heartbeat, or if that ship has sailed and we simply drop it.
>
> There are still users of the "simple" v1 mode. I'd assume they know
> that for anything more complex they should switch to
> corosync+pacemaker, so the question would be how much of the v1 mode
> is still working. If the "average" case is broken on systemd systems,
> we should fix or remove heartbeat. If the average case still works, we
> can continue to ship it.
>
> Patrick, what's your position here?
>
> The drbd/fs/ip/apache example shown in the serverfault question looks
> simple enough. Maybe someone could try a test setup?
>
> Christoph

We tried out many test cases, workarounds, debugging on this issue and
the result was, that the v1 mode of heartbeat can not deal with the
dependency system of systemd and will never support it.

Unfortunately I also do not have the logs from IRC anymore and no time
until the next freeze step to provide this setup again :/

I still think, this is the best solution (since only v1 mode is affected):
"IMO the package should warn (debconf dialog prio high?) the user if he
upgrades heartbeat and systemd+v1 config is in use."

Removing the whole heartbeat package would not be a good solution, since
it is still required?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#844605: X11 segfault with AMD GPU since 4.8.x / Firmware issue

[Patrick Matthäi]

 / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#841565: fraqtive: FTBFS: install: cannot create regular file '/usr/bin/fraqtive': Permission denied

[Patrick Matthäi]

Am 21.10.2016 um 15:44 schrieb Lucas Nussbaum:
> Source: fraqtive
> Version: 0.4.8-3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161021 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
>> make[2]: Entering directory '/<>/src'
>> install -m 755 -p "../debug/fraqtive" "/usr/bin/fraqtive"
>> install: cannot create regular file '/usr/bin/fraqtive': Permission denied
>> Makefile:1252: recipe for target 'install_target' failed
>> make[2]: [install_target] Error 1 (ignored)
>> mkdir: cannot create directory '/usr/share/applications/': Permission denied
>> Makefile:1261: recipe for target 'install_desktop' failed
>> make[2]: *** [install_desktop] Error 1
>

Hey,

this looks more like a failure (permission denied) in your buildd
environment?

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#841132: kid3: FTBFS: fatal error: chapterframe.h: No such file or directory

[Patrick Matthäi]

Am 17.10.2016 um 23:03 schrieb Aurelien Jarno:
> Package: kid3
> Version: 3.4.2-1
> Severity: serious
>
> kid3 fails to build from source on all architectures with the following
> error:
>
> | /«PKGBUILDDIR»/src/plugins/taglibmetadata/taglibfile.cpp:119:26: fatal 
> error: chapterframe.h: No such file or directory
> |  #include 
> |   ^
> | compilation terminated.
> | src/plugins/taglibmetadata/CMakeFiles/taglibmetadata.dir/build.make:93: 
> recipe for target 
> 'src/plugins/taglibmetadata/CMakeFiles/taglibmetadata.dir/taglibfile.cpp.o' 
> failed
> | make[4]: *** 
> [src/plugins/taglibmetadata/CMakeFiles/taglibmetadata.dir/taglibfile.cpp.o] 
> Error 1
>
> A full build log is available for example there:
>
> https://buildd.debian.org/status/fetch.php?pkg=kid3&arch=s390x&ver=3.4.2-1%2Bb2&stamp=1476154044
>
Thanks for your report. Just found out, that taglib is missing some new
include files which is already reported in #840825
Waiting on the upload :)

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#836614: animals sponsoring

[Patrick Matthäi]

Hi,

I am around, just a little bit busy but I did not forget it. I will give
you this week some feedback


Am 19.09.2016 um 12:43 schrieb alberto fuentes:
> This is the second time since I got this package 3 years ago that my
> mentor has to make an upload, so Im not sure hes around :)
>
> I messaged him privately a week ago, but im also putting it here in
> case somebody else can review the fix in this package since the
> severity has been raised
>
> Im sorry is not not a one liner to make easier the review, but I think
> its not very large fix either. I did switch to dh which I believe auto
> applies the hardening
>
> I also did some extra maintenance like dropping the -dbg package which
> I believe it auto generates the new -dbgsym packages
>
> you can review it here:
>
> https://mentors.debian.net/debian/pool/main/a/animals/animals_201207131226-2.dsc
> <https://mentors.debian.net/debian/pool/main/a/animals/animals_201207131226-2.dsc>
> https://mentors.debian.net/package/animals
> <https://mentors.debian.net/package/animals>
>
> Thanks!

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#833357: corosync: Update to 2.3.6 fails with specific configuration / upstream fixed

[Patrick Matthäi]

Package: corosync
Version: 2.3.6-2
Severity: serious
Tags: patch upstream

Hi,

updating corosync from 2.3.5 to 2.3.6 fails with some configurations (as I
already reported to the bpo list) with:
"can't autogenerate multicast address"

Upstream report and patch: https://github.com/corosync/corosync/issues/137

Please apply the patch and I would also welcome updated backports packages :)

Here is one of my /etc/corosync/corosync.conf configurations, with that it is
reproduceable:

totem {
version: 2
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
crypto_cipher: none
crypto_hash: none
transport: udpu
interface {
ringnumber: 0
bindnetaddr: 192.168.99.0
}
}

logging {
to_logfile: yes
logfile: /var/log/corosync/corosync.log
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}

quorum {
provider: corosync_votequorum
two_node: 1
wait_for_all: 1
}

nodelist {
node {
ring0_addr: nd1-1-cs
}
node {
ring0_addr: nd1-2-cs
}
}



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

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

Bug#825291: otrs2: fails to upgrade from 'jessie': DBUpdate-to-5.pl: DBD::Pg::db do failed: ERROR: invalid byte sequence for encoding "UTF8"

[Patrick Matthäi]

tag #825291 + moreinfo
severity #825291 important
tag #825291 + unreproduceable
thanks

Hi,

I can not reproduce your bug report, see attached logs.

Am 27.05.2016 um 16:37 schrieb Andreas Beckmann:
> On 2016-05-27 15:12, Patrick Matthäi wrote:
>> could you also test if it fails on your system if you update to 5.0.8
>> instead of 5.0.10?
> You are lucky, I some old jessie2stretch logfiles:
>   archive/pass/otrs_4.0.8-1.log.xz
>   archive/fail/otrs2_5.0.8+dfsg1-1.log.xz
> The first one succeeded and second one failed the upgrade in the same way.
> All other old logfiles were not helpful, mostly database connection
> failures (but these can be caused by the piuparts environment,
> i.e. postgresql running on the wrong port).
>
> rerunning the tests with old packages is not trivial and would mean more 
> manual work
>
> [...]
>   applying upgrade sql for 3.3.9-3 -> 5.0.0.
>   applying upgrade script for 3.3.9-3 -> 5.0.1.
>   
>   Migration started...
>   
>   Step 1 of 17: Refresh configuration cache...[Thu Apr  7 14:12:20 2016] 
> DBUpdate-to-5.pl: Subroutine Load redefined at (eval 16) line 2.
>   
>   If you see warnings about 'Subroutine Load redefined', that's fine, no need 
> to worry!
>   done.
>   
>   Step 2 of 17: Check framework version...[Thu Apr  7 14:12:21 2016] 
> DBUpdate-to-5.pl: Subroutine Load redefined at (eval 1727) line 2.
>   done.
>   
>   Step 3 of 17: Migrate Database Column Types...done.
>   
>   Step 4 of 17: Migrate charset to UTF-8 on auto_response table...done.
>   
>   Step 5 of 17: Migrate charset to UTF-8 on notification_event table...done.
>   
>   Step 6 of 17: Migrate event based notifications to support multiple 
> languages...done.
>   
>   Step 7 of 17: Migrate notifications to event based notifications...[Thu Apr 
>  7 14:12:21 2016] DBUpdate-to-5.pl: DBD::Pg::db do failed: ERROR:  invalid 
> byte sequence for encoding "UTF8": 0xeb 0x73 0x63 at /usr/sha
> re/otrs/Kernel/System/DB.pm line 449.
>   ERROR: OTRS-DBUpdate-to-5.pl-10 Perl: 5.22.1 OS: linux Time: Thu Apr  7 
> 14:12:21 2016
>   
>Message: ERROR:  invalid byte sequence for encoding "UTF8": 0xeb 0x73 
> 0x63, SQL: '
>   INSERT INTO notification_event_message
>   (notification_id, subject, text, content_type, language)
>   VALUES (?, ?, ?, ?, ?)'
>   
>Traceback (10036): 
>  Module: Kernel::System::NotificationEvent::NotificationAdd Line: 375
>  Module: main::_MigrateNotifications Line: 1115
>  Module: ./scripts/DBUpdate-to-5.pl Line: 162
>   
>   error.
>   
>   [Thu Apr  7 14:12:21 2016] DBUpdate-to-5.pl: Died at 
> ./scripts/DBUpdate-to-5.pl line 167.
>   error encountered processing 
> /usr/share/dbconfig-common/scripts/otrs2/upgrade/pgsql/5.0.1:
>   /usr/share/dbconfig-common/scripts/otrs2/upgrade/pgsql/5.0.1 exited with 
> non-zero status
>   dbconfig-common: otrs2 configure: aborted.
>   dbconfig-common: flushing administrative password
>   dpkg: error processing package otrs2 (--configure):
>subprocess installed post-installation script returned error exit status 1
>
> Andreas

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

root@debian:/home/me# apt-get install otrs2/jessie-backports
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen Fertig
Version »5.0.10-1~bpo8+1« (Debian Backports:jessie-backports [all]) für »otrs2« 
gewählt.
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
  javascript-common libjs-jquery libjs-jquery-ui
Verwenden Sie »apt-get autoremove«, um sie zu entfernen.
Die folgenden zusätzlichen Pakete werden installiert:
  libappconfig-perl libarchive-zip-perl libexcel-writer-xlsx-perl 
libhtml-truncate-perl liblingua-translit-perl libnet-smtp-tls-butmaintained-perl
  libpod-strip-perl libschedule-cron-events-perl libset-crontab-perl 
libtemplate-perl libxml-libxslt-perl libxslt1.1
Vorgeschlagene Pakete:
  libtemplate-perl-doc libtemplate-plugin-gd-perl libtemplate-plugin-xml-perl
Die folgenden NEUEN Pakete werden installiert:
  libappconfig-perl libarchive-zip-perl libexcel-writer-xlsx-perl 
libhtml-truncate-perl liblingua-translit-perl libnet-smtp-tls-butmaintained-perl
  libpod-strip-perl libschedule-cron-events-perl libset-crontab-perl 
libtemplate-perl libxml-libxslt-perl libxslt1.1
Die folgenden Pakete werden aktualisiert (Upgrade):
  otrs2
1 aktualisiert, 12 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 8.472 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 

Bug#825291: otrs2: fails to upgrade from 'jessie': DBUpdate-to-5.pl: DBD::Pg::db do failed: ERROR: invalid byte sequence for encoding "UTF8"

[Patrick Matthäi]

tag #825291 + moreinfo
tag #825291 + upstream
thanks

Hi,

could you also test if it fails on your system if you update to 5.0.8
instead of 5.0.10?

I already reported this to upstream:

http://bugs.otrs.org/show_bug.cgi?id=12103


Am 25.05.2016 um 17:49 schrieb Andreas Beckmann:
> Package: otrs2
> Version: 5.0.10-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
>
> Hi,
>
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'stretch' fails.
>
> >From the attached log (scroll to the bottom...):
>
> [...]
>   Migration completed!
>   applying upgrade sql for 3.3.9-3 -> 5.0.0.
>   applying upgrade script for 3.3.9-3 -> 5.0.1.
>   
>   Migration started...
>   
>   Step 1 of 17: Refresh configuration cache...[Mon May 23 13:17:50 2016] 
> DBUpdate-to-5.pl: Subroutine Load redefined at (eval 16) line 2.
>   
>   If you see warnings about 'Subroutine Load redefined', that's fine, no need 
> to worry!
>   done.
>   
>   Step 2 of 17: Check framework version...[Mon May 23 13:17:51 2016] 
> DBUpdate-to-5.pl: Subroutine Load redefined at (eval 1736) line 2.
>   done.
>   
>   Step 3 of 17: Migrate Database Column Types...done.
>   
>   Step 4 of 17: Migrate charset to UTF-8 on auto_response table...done.
>   
>   Step 5 of 17: Migrate charset to UTF-8 on notification_event table...done.
>   
>   Step 6 of 17: Migrate event based notifications to support multiple 
> languages...done.
>   
>   Step 7 of 17: Migrate notifications to event based notifications...[Mon May 
> 23 13:17:51 2016] DBUpdate-to-5.pl: DBD::Pg::db do failed: ERROR:  invalid 
> byte sequence for encoding "UTF8": 0xeb 0x73 0x63 at 
> /usr/share/otrs/Kernel/System/DB.pm line 449.
>   ERROR: OTRS-DBUpdate-to-5.pl-10 Perl: 5.22.2 OS: linux Time: Mon May 23 
> 13:17:51 2016
>   
>Message: ERROR:  invalid byte sequence for encoding "UTF8": 0xeb 0x73 
> 0x63, SQL: '
>   INSERT INTO notification_event_message
>   (notification_id, subject, text, content_type, language)
>   VALUES (?, ?, ?, ?, ?)'
>   
>Traceback (13340): 
>  Module: Kernel::System::NotificationEvent::NotificationAdd Line: 375
>  Module: main::_MigrateNotifications Line: 1115
>  Module: ./scripts/DBUpdate-to-5.pl Line: 162
>   
>   error.
>   
>   [Mon May 23 13:17:51 2016] DBUpdate-to-5.pl: Died at 
> ./scripts/DBUpdate-to-5.pl line 167.
>   error encountered processing 
> /usr/share/dbconfig-common/scripts/otrs2/upgrade/pgsql/5.0.1:
>   /usr/share/dbconfig-common/scripts/otrs2/upgrade/pgsql/5.0.1 exited with 
> non-zero status
>   dbconfig-common: otrs2 configure: aborted.
>   dbconfig-common: flushing administrative password
>   dpkg: error processing package otrs2 (--configure):
>subprocess installed post-installation script returned error exit status 1
>
>
>
> cheers,
>
> Andreas

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#819162: pacemaker: Missing dependency on dbus

[Patrick Matthäi]

Package: pacemaker
Version: 1.1.14-2
Severity: serious

Hello,

pacemaker is missing a dependency on "dbus", without it installation and start
will fail:

resource-agents (1:3.9.7-1~bpo8+1) wird eingerichtet ...
pacemaker-resource-agents (1.1.14-2~bpo8+1) wird eingerichtet ...
pacemaker (1.1.14-2~bpo8+1) wird eingerichtet ...
Failed to start pacemaker.service: Unit dbus.service failed to load: No such 
file or directory.
invoke-rc.d: initscript pacemaker, action "start" failed.
dpkg: Fehler beim Bearbeiten des Paketes pacemaker (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 6 zurück


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

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

Bug#818961: heartbeat: v1 config style not compatible with systemd

[Patrick Matthäi]

Package: heartbeat
Version: 1:3.0.5+hg12629-1.2
Severity: grave
Tags: upstream
Justification: causes non-serious data loss

Hello,

as previous reported on IRC the v1 config style does not work with systemd as
init system. Failovers are broken, because of the event based systemd, instead
of LSB ordering for services. I also tried out the 1:3.0.6-2 version, without
any luck.

Upstream also states (have not got the link now) that it is unsupported, since
v1 style does not get new features.

IMO the package should warn (debconf dialog prio high?) the user if he upgrades
heartbeat and systemd+v1 config is in use.

Why severity grave?
On setting up some test VMs I noticed that it looks like the cluster is working,
but on intensive testing (just some failovers or using /usr/share/heartbeat/
scripts) everything broke again and again. For productive setups this will fail
in a bigger downtime and the user could not identify the real problem (missing
support) from the logs, except of some coredumps and never taking over clients.

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

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

Bug#818446: roarplaylistd: FTBFS: error: 'SLP_OK' undeclared

[Patrick Matthäi]

config.h says, it has got LIB_SLP, which is not true and a fault.
But I can fix it for Debian with the --no-slp switch.

Am 18.03.2016 um 11:36 schrieb Philipp Schafft:

Good morning,

can you please provide the config.h from your build? (it's created by
configure). I don't see why exactly this fails as it builds without
OpenSLP fine for me.

Thank you for your additional information.

Bug#814589: otrs2: source-less files; undocumented copyrights/licenses; abuse of lintian-overrides; systematic DFSG violations

[Patrick Matthäi]

Am 03.03.2016 um 14:31 schrieb Julien Cristau:

On Wed, Mar  2, 2016 at 12:36:46 +0100, Patrick Matthäi wrote:


@Debian release team:
I would like to request a strech ignore for this bug. I am aware of these
problems, but I am not able to fix them nor did anyone ever offered me help
with this JS foo. If it would not be possible I had to resign otrs packaging
in Debian.


There's two issues as I understand it:
- embedded copies of third-party code
- lack of source for some of them

The former is not necessarily RC, and I'm not thrilled about ignoring
the latter.  Not to mention we're months away from freeze, so this isn't
the time to consider stretch-ignore tags, there's plenty of time to fix
bugs still.



Thanks for your answer.
I will try to fix the serious bugs in the next time. Just get a new 
notebook after my workstation crashed...

Bug#814589: otrs2: source-less files; undocumented copyrights/licenses; abuse of lintian-overrides; systematic DFSG violations

[Patrick Matthäi]

Am 15.02.2016 um 14:14 schrieb Dmitry Smirnov:

I am aware of those issues, that is
also why the embedded-code-copies bug is marked as "need help".

And this is why I provided some hints how you can address those problems in
my bug report. This is why I wrote to you after when I stabilised "ckeditor"
so you could use it.
I can use it, until ckeditor OR otrs upstreams broke it again, like with 
jquery.

Also it would prevent backports of otrs to jessie.


and mostly it is not possible to replace the
libjs thirdparty foo with the packages from Debian, mostly because of
version missmatches.

Hold on, you are answering the least important concern. There are cases when
replacing bundled library with system one could be fragile or not suitable.
But you can't ship and use untrusted pre-minified upstream files with who-
knows-what...


You reported a very general bug about the whole javascript mess. 
Replacing ckeditor will not solve the other problems or all those 
minified files and so on.






Nobody is willed (or in my case able) to fix those
JS issues, which appear here and then with different versions in
different places (ugly JS sh..).

At least I gave you "ckeditor" didn't I? That's one less problem to deal
with...


See above.




If everything is simple for you and just replacements have to be done
(which is not the case) then I would be happy to welcome you on the
otrs-packaging board.

It is simple enough. Although some system libraries should be safe to use you
do not have to use only system libraries. But you have to get rid of non-DFSG
precompiled binaries.
I appreciate your invitation but unfortunately I have no time for otrs.


IMO minified files are not as evil as the embedded libs, which should be 
addressed first.






Just a short example:
With 5.0.1-2 I had to drop (and inform the security team) about removing
again the use of the libjs-jquery* packages from Debian, because of #802938

I agree that using "libjs-jquery-ui" package of different version than
bundled one is fragile.
Though with "libjs-jquery" you'd probably be safe as long as you do not cross
1.9.0 boundary. However you must not use pre-minified "jquery-ui.js" as it is
shipped in orig.tar. As very minimum you have to replace it with original
uncompressed version that you have to ship in "debian/missing-sources" and
ideally report pre-built binaries as bug to upstream. If you believe in
minification then you can minify on build time. You can not trust source-
less, unreadable, unmodifiable pre-built binaries. I suppose lintian already
warned you long before I did.

I wrote the following wiki page that I use when I make upstream bug reports
about minified binaries -- I hope you might find it useful:

 https://wiki.debian.org/onlyjob/no-minification



Investing work in removing those files will not realy help and just 
burden the whole packaging and eat time to fix realy serious issues - 
like embedded libs.


@Debian release team:
I would like to request a strech ignore for this bug. I am aware of 
these problems, but I am not able to fix them nor did anyone ever 
offered me help with this JS foo. If it would not be possible I had to 
resign otrs packaging in Debian.


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#814589: otrs2: source-less files; undocumented copyrights/licenses; abuse of lintian-overrides; systematic DFSG violations

[Patrick Matthäi]

Am 13.02.2016 um 09:53 schrieb Dmitry Smirnov:

Source: otrs2
Version: 5.0.6-1
Severity: serious

I'm quite shocked to find how badly otrs2 packaging violates DFSG.
There are many non-distributrable pre-built (minified) source-less files in
orig tarball under "var/httpd/htdocs/js/thirdparty". No attemps to fix this
situation has been and some inconvenient lintian warnings (such as "source-
contains-prebuilt-javascript-object" and "source-contains-prebuilt-flash-
object") are hidden through use of lintian-overrides. Moreover many bundled
third party components are not even documented in "debian/copyright". :( :(

Fixing those problems is neigher optional nor hard. To comply with policy
sources of minified files can be shipped in "debian/missing-sources".
Minified files can be replaced on build time with their uncompressed original
files or even with files minified by build srcipts (if you believe in
minification). Where appropriate you can certainly use system libjs-*
packages and there is already bug for that: #695664.
At your convenience you can use "dh_linktree" or "dh_link" helpers to
facilitate replacement.
New `uscan` functionality allows to do DFSG-repackaging by utilising
"copyright/Files-Excluded" field -- you can read more about that in

 https://wiki.debian.org/UscanEnhancements

(Also it might be helpful to add "repacksuffix=+dfsg" to "debian/watch").
Finally you don't have to document copyrights and licenses for files that
were dropped from orig.tar.

You are not the only maintainer who have to deal with pesky bundled non-DFSG
third party components. Just recently yours truly had to fix package
"ckeditor" because one of my packages bundles it. Therefore I'm confident
that you can replace "ckeditor" bundled to "otrs2" with "ckeditor (>=
4.5.6~)" right now and that it is safe to do so.
Please address all those problems ASAP.



I do not comply with your report. I am aware of those issues, that is 
also why the embedded-code-copies bug is marked as "need help". OTRS 
packaging is a hard job and mostly it is not possible to replace the 
libjs thirdparty foo with the packages from Debian, mostly because of 
version missmatches. Nobody is willed (or in my case able) to fix those 
JS issues, which appear here and then with different versions in 
different places (ugly JS sh..).


If everything is simple for you and just replacements have to be done 
(which is not the case) then I would be happy to welcome you on the 
otrs-packaging board.


Just a short example:
With 5.0.1-2 I had to drop (and inform the security team) about removing 
again the use of the libjs-jquery* packages from Debian, because of #802938


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#804618: znc: FTBFS: error: ‘SSLv3_client_method’ was not declared in this scope

[Patrick Matthäi]

Thanks, will be uploaded in the next hour

Am 10.11.2015 um 04:03 schrieb Alexey Sokolov:

Hi,
This is fixed upstream in upcoming 1.6.2. I hope to release it in several days.
Upstream reference: https://github.com/znc/znc/issues/1146

2015-11-09 21:25 GMT+00:00 Chris West (Faux) :

Source: znc
Version: 1.6.1-1
Severity: serious
Justification: fails to build from source
Tags: sid stretch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

The package fails to build:

src/Csocket.cpp: In member function ‘virtual bool Csock::SSLClientSetup()’:
src/Csocket.cpp:1467:48: error: ‘SSLv3_client_method’ was not declared in this 
scope
m_ssl_ctx = SSL_CTX_new( SSLv3_client_method() );
 ^
src/Csocket.cpp: In member function ‘SSL_CTX* Csock::SetupServerCTX()’:
src/Csocket.cpp:1589:43: error: ‘SSLv3_server_method’ was not declared in this 
scope
pCTX = SSL_CTX_new( SSLv3_server_method() );
^
Makefile:116: recipe for target 'src/Csocket.o' failed
make[2]: *** [src/Csocket.o] Error 1
make[2]: Leaving directory '/znc-1.6.1'

Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/znc.html

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



--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie

[Patrick Matthäi]

Am 28.10.2015 um 21:25 schrieb Niko Tyni:

On Tue, Oct 27, 2015 at 12:24:26PM +0200, Niko Tyni wrote:

On Tue, Oct 27, 2015 at 10:24:23AM +0100, Patrick Matthäi wrote:

If it fixes the problem, do you have got an idea which changes to pick up
for fixing jessie?

I haven't looked at it properly yet, but I think there weren't too many
changes between the versions. I'll follow up on this later when I find
the time, but it might take a week or so.

I think the two attached patches from upstream r1636289 and r1676417 are
the only likely candidates and should most probably be included together.
They apply as-is to the jessie package.

Any testing would be very welcome.


Looks still good. Would you prepare a stable upload please?

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie

[Patrick Matthäi]

Am 28.10.2015 um 21:25 schrieb Niko Tyni:

If it fixes the problem, do you have got an idea which changes to pick up
for fixing jessie?

I haven't looked at it properly yet, but I think there weren't too many
changes between the versions. I'll follow up on this later when I find
the time, but it might take a week or so.

I think the two attached patches from upstream r1636289 and r1676417 are
the only likely candidates and should most probably be included together.
They apply as-is to the jessie package.

Any testing would be very welcome.


I have applied both patches to the jessie 2.0.9~1624218-2 version and it 
still looks good. I am unable to trigger both issues again :)


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie

[Patrick Matthäi]

Am 27.10.2015 um 08:34 schrieb Niko Tyni:

On Mon, Oct 26, 2015 at 11:21:12AM +0100, Patrick Matthäi wrote:

Package: libapache2-mod-perl2
Version: 2.0.9~1624218-2
Severity: grave
after upgrading our otrs2 server from wheezy/amd64 to jessie I noticed
dozens of apache segfaults per day on this machine. In dmesg it looks like
this:
Now the more curious thing. I have updated another server from Wheezy to
Jessie, which is just serving gitolite and subversion repositories (about
mod_svn). After the upgrade full svn checkouts were impossible, also because
of segfaults from Apache itself. Later I found, that mod_perl2 was installed
and activated on this system, but it was not used at all. So uninstalling
libapache2-mod-perl2 solved the issue on the server, where it was not
required.

Thanks for the report.

Would it be possible for you to test if 2.0.9-1 from stretch/sid has
the same behaviour? The binaries aren't quite installable in jessie,
but the build dependencies are so it's just a simple rebuild. I can also
provide binaries if you like.


No problem. Already deployed on both machines for testing:

svn/git machine:
Everything looks fine at the moment, I can not reproduce this issue

otrs issue:
There it is harder to reproduce. I would send you an update, if it still 
crashes.


But..:
If it fixes the problem, do you have got an idea which changes to pick 
up for fixing jessie?

Maybe it is relevant, that all our services are reachable about HTTPS?

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie

[Patrick Matthäi]

Hi again,

this happened while I checked out a svn repository:

root@git:/tmp/apache# gdb /usr/sbin/apache2 -c core
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/apache2...Reading symbols from 
/usr/lib/debug//usr/sbin/apache2...done.

done.

warning: core file may not match specified executable file.
[New LWP 8295]
[New LWP 8298]
[New LWP 8302]
[New LWP 8322]
[New LWP 8304]
[New LWP 8305]
[New LWP 8311]
[New LWP 8308]
[New LWP 8300]
[New LWP 8314]
[New LWP 8299]
[New LWP 8317]
[New LWP 8340]
[New LWP 8319]
[New LWP 8330]
[New LWP 8325]
[New LWP 8328]
[New LWP 8337]
[New LWP 8346]
[New LWP 8347]
[New LWP 8348]
[New LWP 8349]
[New LWP 8343]
[New LWP 8350]
[New LWP 8333]
[New LWP 8335]
[New LWP 8301]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f5918853add in read () at ../sysdeps/unix/syscall-template.S:81
81  ../sysdeps/unix/syscall-template.S: Datei oder Verzeichnis nicht 
gefunden.

(gdb) bt
#0  0x7f5918853add in read () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f59193b59c7 in read (__nbytes=1, __buf=0x7fffad821e83, 
__fd=) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44

#2  ap_mpm_podx_check (pod=) at mpm_unix.c:535
#3  0x7f5911a7fb34 in child_main (child_num_arg=0) at worker.c:1341
#4  0x7f5911a826c5 in make_child (s=0x7f59195afde0, slot=0) at 
worker.c:1427
#5  0x7f5911a82745 in startup_children (number_to_start=2) at 
worker.c:1452
#6  0x7f5911a8325e in worker_run (_pconf=0x7f59195d7028, 
plog=0x7f59195ab028, s=0x7f59195afde0) at worker.c:1811
#7  0x7f591938ee7e in ap_run_mpm (pconf=0x7f59195d7028, 
plog=0x7f59195ab028, s=0x7f59195afde0) at mpm_common.c:94

#8  0x7f59193883c3 in main (argc=3, argv=0x7fffad8222a8) at main.c:777
(gdb) bt full
#0  0x7f5918853add in read () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7f59193b59c7 in read (__nbytes=1, __buf=0x7fffad821e83, 
__fd=) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44

No locals.
#2  ap_mpm_podx_check (pod=) at mpm_unix.c:535
c = 25 '\031'
fd = 5
rc = 
#3  0x7f5911a7fb34 in child_main (child_num_arg=0) at worker.c:1341
threads = 0x7f591aa11910
ts = 0x7f5919529110
thread_attr = 0x7f5919529130
start_thread_id = 0x7f5919529190
#4  0x7f5911a826c5 in make_child (s=0x7f59195afde0, slot=0) at 
worker.c:1427

No locals.
#5  0x7f5911a82745 in startup_children (number_to_start=2) at 
worker.c:1452

i = 0
#6  0x7f5911a8325e in worker_run (_pconf=0x7f59195d7028, 
plog=0x7f59195ab028, s=0x7f59195afde0) at worker.c:1811

rv = -512
#7  0x7f591938ee7e in ap_run_mpm (pconf=0x7f59195d7028, 
plog=0x7f59195ab028, s=0x7f59195afde0) at mpm_common.c:94

pHook = 
n = 0
rv = -1
#8  0x7f59193883c3 in main (argc=3, argv=0x7fffad8222a8) at main.c:777
c = 0 '\000'
error = 0xfe00 address 0xfe00>

process = 0x7f59195e0118
pconf = 0x7f59195d7028
plog = 0x7f59195ab028
ptemp = 0x7f59195ad028
pcommands = 0x7f59195b5028
opt = 0x7f59195b5118
mod = 0x7f59195ec1c0 
opt_arg = 0x7f59195e0028 "(@^\031Y\177"
signal_server = 0xfe00
(gdb)

[Mon Oct 26 13:14:58.134998 2015] [core:notice] [pid 8291:tid 
140020654380928] AH00051: child pid 8295 exit signal Segmentation fault 
(11), possible coredump in /tmp/apache


And as I said it was enough here on this server to activate the perl 
module. Perl itself is not used.


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#803043: mod_perl2 / Apache segfaults after upgrading from Wheezy to Jessie

[Patrick Matthäi]

6d15868, 
bb=0x7fd3f6be2b58) at ssl_engine_io.c:1659

data = 0x0
len = 0
bucket = 0x7fd3f6be31a8
filter_ctx = 0x7fd3f6d15810
inctx = 0x0
rblock = APR_BLOCK_READ
#3  0x7fd3ef85577a in ssl_io_filter_coalesce (f=0x0, 
bb=0x7fd3f6be2b58) at ssl_engine_io.c:1558

ctx = 0x7fd3f6be2350
count = 0
#4  0x7fd3f6cd5b3d in ap_process_request_after_handler 
(r=0x7fd3f6bda0a0) at http_request.c:256

bb = 0x7fd3f6be2b58
b = 
c = 0x7fd3f6d152c8
#5  0x7fd3f6cd6820 in ap_process_request (r=0x7fd3f6bda0a0) at 
http_request.c:363

bb = 0x0
c = 0x7fd3f6d152c8
rv = 0
#6  0x7fd3f6cd3122 in ap_process_http_sync_connection 
(c=0x7fd3f6d152c8) at http_core.c:190

r = 0x7fd3f6bda0a0
cs = 0x0
csd = 0x0
mpm_state = 0
#7  ap_process_http_connection (c=0x7fd3f6d152c8) at http_core.c:231
No locals.
#8  0x7fd3f6cc9b10 in ap_run_process_connection (c=0x7fd3f6d152c8) 
at connection.c:41

pHook = 
n = 2
rv = -1
#9  0x7fd3f0da651b in process_socket (bucket_alloc=, 
my_thread_num=, my_child_num=,
sock=, p=, thd=) at 
worker.c:619

current_conn = 0x7fd3f6d152c8
conn_id = 140548355740360
sbh = 0x7fd3f6d152c0
#10 worker_thread (thd=0x0, dummy=0x0) at worker.c:978
process_slot = 0
thread_slot = 19
csd = 0x7fd3f6d150b0
bucket_alloc = 0x0
last_ptrans = 0x7fd3f6d150b0
ptrans = 0x7fd3f6d15028
is_idle = -154053944
#11 0x7fd3f61640a4 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0

No symbol table info available.
#12 0x7fd3f5e9904d in clone () from /lib/x86_64-linux-gnu/libc.so.6
---Type  to continue, or q  to quit---
No symbol table info available.
(gdb)

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#802287: kdenlive: Kdenlive for Debian 8 fails to load

[Patrick Matthäi]

Am 19.10.2015 um 04:31 schrieb Joe McEntire:
> Package: kdenlive
> Version: 0.9.2-2
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> Attempted to install and run kdenlive
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Installed kdenlive, kdenlive fails to start once I clicked the icon.  
> I
> then rolled back to the wheezy version of the packages kdenlive, 
> kdenlive-data,
> libmlt++3, libmlt5, melt holding these packages at the wheezy version level
> 
>* What was the outcome of this action?
> With the Jessie version the package fails to run.  kdenlive will not
> start
> With the Wheezy version the package works as expected.
> 
> The occurs on both my desktop and my laptop.  I cannot get the Jessie
> version to work no matter what I try.
> 
>* What outcome did you expect instead?
> Kdenlive should launch as expected once installed.
> 
> *** End of the template - remove these template lines ***
> 

Please install the package again with libmlt-dbg and kdenlive-dbg and
show me the following:

$ dpkg -l|egrep "mlt|ffmpeg|libav|kdenlive"
$ kdenlive
$ gdb kdenlive (=> run and bt full)


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#800920: [Pkg-fglrx-devel] Bug#800920: X segfaults during startup if fglrx is used

[Patrick Matthäi]

Am 05.10.2015 um 02:33 schrieb Florian Uekermann:

Upgrading to fglrx 1:15.9-1 on a fully upgraded stretch system led to the
following reproducible error (segfault) on X startup (xinit in this case):


Hi,

which was the last working version for you?

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#796074: [Pkg-fglrx-devel] Bug#796074: fglrx-driver: vterms broken when fglrx in use

[Patrick Matthäi]

Am 19.08.2015 um 10:37 schrieb Richard Jasmin:
> Package: fglrx-driver
> Version: 1:15.7-1
> Severity: grave
> Justification: renders package unusable
> 
> reported once as linux-firmware-nonfree but its the fglrx package.When its not
> installed and open source driver is enabled, linux complains about linux-
> firmware-nonfree and kms not being available.

Maybe just my english crashed.. So you want to say:
- without fglrx everything works
- without fglrx you do NOT have got KMS availble?
- did you purged fglrx?

With fglrx installed (and not purged) KMS is not available, because of
/etc/modprobe.d/fglrx-blacklists-radeon.conf

> 
> If and when your system breaks, (lets say you fubared a /var/tmp or /tmp entry
> in /etc/fstab or the rootfs gets mounted ro instead or rw) you get the console
> in a working state.It only breaks terminal output when using X11 under init-
> level 5. Sadly, you cant switch to another init level once 5 has fired up.If
> you try, you just get a black screen.You have to be in the console to do this.
> 
> You get slammed into init level 5 once the "issue" gets resolved and must 
> force
> a drop back into level 3 if you dont want X11 to fire.Something changed. This
> was not the usual case in the past.
> 

We do not have got anymore runlevels in testing/sid, where 15.7 is in,
but anyway: runlevel 5 is not a default init level from Debian, 3 it is
for multiuser with X11.
My intention: you have "customized" something, which breaks your system now.


> Using grub option "nomodeset" has no effect.
> If X11 bails on you, the only two options are "play whack a mole with the 
> reset
> button" or hit CTRL-ALT-DELETE.Even then, there is delay on X11 exit.

With fglrx installed nomodeset is already the default value.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#795863: [Pkg-fglrx-devel] Bug#795863: fglrx-driver: fglrx ASIC lockup: HID devices unusable

[Patrick Matthäi]

severity #795863 normal
tag #795863 + upstream
thanks

Am 17.08.2015 um 16:26 schrieb Tom Noonan:

Package: fglrx-driver
Version: 1:14.9+ga14.201-2
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Running the fglrx driver against a Advanced Micro Devices, Inc. [AMD/ATI] 
Bonaire [FirePro W5100] ASIC lockups have been seen on multiple occasions.
This is usually seen when the terminal is idle with the monitors in power save 
mode.
XScreenSaver is in use to lock the terminals however all screensavers are 
disabled (screen blanking only) to try and eliminate GL issues.


Both could be deactivated, so it is not a RC bug.

Anyway fglrx is closed source so we just can ask you: Is this issue 
fixed in 15.7-1 from stretch/sid?


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#789450: glusterfs-common: Should depend on libacl1-dev

[Patrick Matthäi]

tag #789450 + pending
thanks
Am 21.06.2015 um 07:03 schrieb Jonas Smedegaard:

Package: glusterfs-common
Severity: serious
Justification: Policy 3.5

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

/usr/include/glusterfs/api/glfs.h includes sys/acl.h so the package
need to depend on libacl1-dev.

Thanks for spotting this.

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#788278: [znc] Some sources are not included in your package

[Patrick Matthäi]

tag #788278 + upstream
severity #788278 important
thanks

Hi,

Am 10.06.2015 um 01:36 schrieb bastien ROUCARIÈS:

your package includes some files that seem to lack sources
in prefered forms of modification:

webskins/_default_/pub/jquery-1.11.2.min.js



just discussed with upstream about that a month ago. It is already fixed 
in git and a fix will be availble with the next upstream version.


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#784903: [Pkg-fglrx-devel] Bug#784903: fglrx-driver: broken depends on xorg-video-abi-18

[Patrick Matthäi]

Am 10.05.2015 um 14:18 schrieb Michael Tatge:
> Source: fglrx-driver
> Version: 1:14.9+ga14.201-2
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> fglrx-driver depends on xorg-video-abi-18 but xserver-xorg-core provides
> xorg-video-abi-19 thus rendering the package uninstallable.

I will check in the next days if the experimental 14.12 version is
compatible with it, but I do not think so.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#726500: [Pkg-fglrx-devel] Bug#726500: fglrx-legacy-driver in Jessie

[Patrick Matthäi]

Am 13.04.2015 um 09:24 schrieb Leopold Palomo-Avellaneda:

Hi,

may I understand that we won't have this driver in Jessie?


That is correct.

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781018: glusterfs: CVE-2014-3619

[Patrick Matthäi]

Am 23.03.2015 um 11:43 schrieb Moritz Muehlenhoff:

Package: glusterfs
Severity: grave
Tags: security
Justification: user security hole

Hi,
please see https://bugzilla.redhat.com/show_bug.cgi?id=1138145
for further information and patches.



Hi,

3.5.2-2 is uploaded and a unblock request is also filled. experimental 
is not affected.


If 3.2.7-3+deb7u1 from stable is also affected then we require a patch 
for it. The current upstream version could not be applied to 3.2.7 :(


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#781018: glusterfs: CVE-2014-3619

[Patrick Matthäi]

fixed #781018 3.6.2-1
thanks

Am 23.03.2015 um 11:43 schrieb Moritz Muehlenhoff:

Package: glusterfs
Severity: grave
Tags: security
Justification: user security hole

Hi,
please see https://bugzilla.redhat.com/show_bug.cgi?id=1138145
for further information and patches.

Cheers,
 Moritz


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#780334: please provide normal lib (with SOVERSION) and lib-dev packages for the libs

[Patrick Matthäi]

Am 13.03.2015 um 17:09 schrieb Michael Tokarev:
> Hello again.  It looks lile you overlooked the
> main part of my reply, here it goes again:

Oh you are right I have overseen the last paragraph, sorry!

>>>> If you need to build-depend on it, than you have to use the -common 
>>>> package,
>>>> but with the changes made in #630147 I also wanted to say (and that is 
>>>> conform):
>>>> better do not use this package as b-d.
>>>
>>> And this is something I don't understand.  In my case (see #775431), the
>>> question is about adding glusterfs to qemu packages.  Qemu can use 
>>> glusterfs,
>>> but it needs headers and libs (I'm not sure if it really needs libs, at 
>>> least
>>> the configure script sets up GLUSTERFS_LIBS and uses it for linking).  If
>>> this package is better NOT to be used as b-d, and if these libs are for
>>> internal use only, what to do?
> 
> So, Patrick, what do you suggest?

You are free to add glusterfs support to it and I also would be happy
about it :) But we can never say when upstream breaks compability, which
will make your life as qemu maintainer hard. So it is up to you, I would
support it.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#780334: please provide normal lib (with SOVERSION) and lib-dev packages for the libs

[Patrick Matthäi]

Am 13.03.2015 um 13:32 schrieb Michael Tokarev:

Thank you for the reply.

Can you believe I tried to search for similar bugs,
but overlooked the already existing bug, #630147?.. ;)


No problem :)



Maybe it's better to keep it open+wontfix than closed+wontfix,
so that it will be easier to find -- either this one or #630147?


Then the bug is marked as "open" in all overviews and I do not like it :D



13.03.2015 12:17, Patrick Matthäi wrote:

Hi,

this was changed with 3.2.1-1, see #630147
Upstream will not follow the standards of the library versioning schema, so it 
is not possible to maintain it in this way in Debian.

Ok, that makes sense, especially since it is an internal library.


If you need to build-depend on it, than you have to use the -common package,
but with the changes made in #630147 I also wanted to say (and that is conform):
better do not use this package as b-d.

And this is something I don't understand.  In my case (see #775431), the
question is about adding glusterfs to qemu packages.  Qemu can use glusterfs,
but it needs headers and libs (I'm not sure if it really needs libs, at least
the configure script sets up GLUSTERFS_LIBS and uses it for linking).  If
this package is better NOT to be used as b-d, and if these libs are for
internal use only, what to do?

Thanks,

/mjt


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#776309: [Pkg-fglrx-devel] Bug#776309: fglrx-driver: Hung PC with black screen and solid white cursor in upper left corner

[Patrick Matthäi]

severity #776309 important
tag #776309 + upstream
thanks

Am 26.01.2015 um 16:08 schrieb Greg Futia:

  When this package is installed the system boots to a completely hung 
state with a solid cursor in the upper left hand corner. The hang leaves the 
system unaccessible though ssh and not recoverable through the ctrl-alt F1 
mechanism. The log files indicate the fglrx-driver is loaded into the kernel as 
it should be. However the hang is so hard that no additional information is 
written to kernel.log messages Xorg.0.log or system.log.

  This error also occurs with a direct install of the latest upstream 
driver, AMD Catalyst Omega 14.12.


So this is a upstream bug, where we can not do anything except of 
tracking this bug (more work).



-- Package-specific info:
Full fglrx package list:
rc  fglrx  2:14.501-0ubuntu1  amd64  Video 
driver for the AMD graphics accelerators

What's this? Not that it broke your system!

Did it worked with previous fglrx versions? Which was the last one?

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775632: libdate-pcalc-perl: FTBFS in jessie: Tests failures

[Patrick Matthäi]

Hi Gregor,

is there any progress on this bug?
libdate-pcalc-perl is scheduled for removal in 25 days and my package 
otrs depends on it :)


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#775638: IPv6 database is corrupt

[Patrick Matthäi]

Hi Andrew,

do you have got any news? :)

Am 20.01.2015 um 18:43 schrieb Andrew Moise:


  Thanks Patrick. One note - just like the v6 issue, the gdnsd test 
suite is detecting a genuine problem in the city DB. It is something 
wrong with the city DB creation tools that's causing it (i.e. not just 
an issue with the gdnsd tests). I just haven't finished tracking down 
exactly what the issue is yet.

  -Andrew

On Jan 20, 2015 12:22 PM, "Patrick Matthäi" <mailto:pmatth...@debian.org>> wrote:


tag #775638 + confirmed
clone #775638 -1
reassign -1 geoip-bin
retitle -1 geoip-generator produces faulty v6/city database
severity -1 grave
found -1 1.6.2-3
thanks

Hi

Am 18.01.2015 um 05:21 schrieb Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org
<mailto:cont...@bugs.debian.org>:
>
>> reassign 775638 geoip-database 20141027-1
> Bug #775638 [src:gdnsd] gdnsd: FTBFS in jessie: dh_auto_test:
make -j1 test returned exit code 2
> Bug reassigned from package 'src:gdnsd' to 'geoip-database'.
> No longer marked as found in versions gdnsd/2.1.0-1.
> Ignoring request to alter fixed versions of bug #775638 to the
same values previously set
> Bug #775638 [geoip-database] gdnsd: FTBFS in jessie:
dh_auto_test: make -j1 test returned exit code 2
> Marked as found in versions geoip-database/20141027-1.
>> retitle 775638 IPv6 database is corrupt
> Bug #775638 [geoip-database] gdnsd: FTBFS in jessie:
dh_auto_test: make -j1 test returned exit code 2
> Changed Bug title to 'IPv6 database is corrupt' from 'gdnsd:
FTBFS in jessie: dh_auto_test: make -j1 test returned exit code 2'
>> severity 775638 grave
> Bug #775638 [geoip-database] IPv6 database is corrupt
> Severity set to 'grave' from 'serious'
>> thanks

thanks for spotting it. Curious that no one (also myself!) spotted it.
The patch for the v6 database is just:

--- geoip/branches/jessie/debian/src/geoip-csv-to-dat.cpp  2015-01-19
18:50:04 UTC (rev 5693)
+++ geoip/branches/jessie/debian/src/geoip-csv-to-dat.cpp  2015-01-20
08:31:03 UTC (rev 5694)
@@ -959,6 +959,7 @@
address_family = AF_INET;
break;
case '6':
+   database_type = GEOIP_COUNTRY_EDITION_V6;
address_family = AF_INET6;
break;
case 'i':

But Andrew found out that there is also an issue with the city
database,
which is working in general, but the gdnsd tests also fail.

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org <mailto:pmatth...@debian.org>
patr...@linux-dev.org <mailto:patr...@linux-dev.org>
*/



--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#775638: IPv6 database is corrupt

[Patrick Matthäi]

tag #775638 + confirmed
clone #775638 -1
reassign -1 geoip-bin
retitle -1 geoip-generator produces faulty v6/city database
severity -1 grave
found -1 1.6.2-3
thanks

Hi

Am 18.01.2015 um 05:21 schrieb Debian Bug Tracking System:
> Processing commands for cont...@bugs.debian.org:
> 
>> reassign 775638 geoip-database 20141027-1
> Bug #775638 [src:gdnsd] gdnsd: FTBFS in jessie: dh_auto_test: make -j1 test 
> returned exit code 2
> Bug reassigned from package 'src:gdnsd' to 'geoip-database'.
> No longer marked as found in versions gdnsd/2.1.0-1.
> Ignoring request to alter fixed versions of bug #775638 to the same values 
> previously set
> Bug #775638 [geoip-database] gdnsd: FTBFS in jessie: dh_auto_test: make -j1 
> test returned exit code 2
> Marked as found in versions geoip-database/20141027-1.
>> retitle 775638 IPv6 database is corrupt
> Bug #775638 [geoip-database] gdnsd: FTBFS in jessie: dh_auto_test: make -j1 
> test returned exit code 2
> Changed Bug title to 'IPv6 database is corrupt' from 'gdnsd: FTBFS in jessie: 
> dh_auto_test: make -j1 test returned exit code 2'
>> severity 775638 grave
> Bug #775638 [geoip-database] IPv6 database is corrupt
> Severity set to 'grave' from 'serious'
>> thanks

thanks for spotting it. Curious that no one (also myself!) spotted it.
The patch for the v6 database is just:

--- geoip/branches/jessie/debian/src/geoip-csv-to-dat.cpp   2015-01-19
18:50:04 UTC (rev 5693)
+++ geoip/branches/jessie/debian/src/geoip-csv-to-dat.cpp   2015-01-20
08:31:03 UTC (rev 5694)
@@ -959,6 +959,7 @@
address_family = AF_INET;
break;
case '6':
+   database_type = GEOIP_COUNTRY_EDITION_V6;
address_family = AF_INET6;
break;
case 'i':

But Andrew found out that there is also an issue with the city database,
which is working in general, but the gdnsd tests also fail.

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#768548: rpcbind: LSB headers should provide $portmap virtual facility

[Patrick Matthäi]

Hello systemd maintainers,

please CC me in your e-mails, I'm not subscribed to this list.

Am 20.11.2014 um 17:31 schrieb Simon McVittie:
It seems to me as though your dependency cycle is caused by 
vmware-tools.service. Please try removing the X-Start-Before from it 
and see whether that helps. If further analysis of your dependency 
cycle indicates that there is in fact some problem with 
rpcbind.service, I think it would make most sense for that to be a 
separate bug. 


Right, it is working without the X-Start-Before line.


Names=vmware-tools.service

...

Before=ntp.service postfix.service bacula-fd.service
nagios-nrpe-server.service bacula-director.service graphical.target
shutdown.target network-online.target bacula-sd.service
fail2ban.service sysstat.service multi-user.target
After=local-fs.target systemd-journald.socket basic.target
system.slice

Because of the X-Start-Before: $network, this wants to start before
network-online.target, which approximately corresponds to
/etc/init.d/networking in sysv-land; yet it is a rc2 service, so it
wants to start after basic.target.

In conjunction with basic.target (i.e. rcS) services like
rpcbind.service that apparently want to start *after*
network-online.target, this presents a problem. Consider the Before and
After ordering:

sysinit.target (must start before)
basic.target (which must start before)
vmware-tools.service (etc.)
network-online.target
rpcbind.service
sysinit.target (! back where we started)

There's no way that can work well.

The sysvinit scripts were presumably able to resolve this less
destructively by breaking the cycle in a different place, because they
didn't even think about rc2 until they had brought up rcS, by which
point it was too late for vmware-tools' X-Start-Before to take effect;
so it was simply ignored (I think). However, systemd doesn't force all
of rcS to happen before any of rc2 starts: it has a single large
dependency graph that covers both.

I think it's fairly clear that this is neither rpcbind's fault, nor the
same issue that I originally reported (which was wrong anyway).


ACK



It would seem reasonable to report a non-RC bug against systemd
(probably wishlist) for either or both of these:

- logging the whole path around the cycle(s) that it found, not just
   one of the units involved;
- a cleverer heuristic for where to break cycles, perhaps preferring
   to break them at a unit that has DefaultDependencies=no because those
   are less likely to be something important during early boot

It's entirely possible that one or both of those has been tried and
turned out not to be feasible, though.

 S

Thanks for your analyse of this problem. I think there should be a 
better solution, since this bug will be triggered on every VMware 
virtualized platform (since normaly you have to install their 
corresponding vmware-tools).


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768548: rpcbind: LSB headers should provide $portmap virtual facility

[Patrick Matthäi]

Am 20.11.2014 um 15:50 schrieb Simon McVittie:

On 20/11/14 13:44, Patrick Matthäi wrote:

Am 20.11.2014 um 14:03 schrieb Simon McVittie:

the output of:

  systemctl status nfs-common.service


root@backup-lvl3:~# systemctl status nfs-common.service
● nfs-common.service - LSB: NFS support files common to client and server
   Loaded: loaded (/etc/init.d/nfs-common)
   Active: active (running) since Do 2014-11-20 13:26:26 CET; 2h 26min ago
  Process: 1834 ExecStop=/etc/init.d/nfs-common stop (code=exited, 
status=0/SUCCESS)
  Process: 1841 ExecStart=/etc/init.d/nfs-common start (code=exited, 
status=0/SUCCESS)

   CGroup: /system.slice/nfs-common.service
   ├─1846 /sbin/rpc.statd
   └─1860 /usr/sbin/rpc.idmapd

Nov 20 13:26:26 backup-lvl3 rpc.statd[1846]: Version 1.2.8 starting
Nov 20 13:26:26 backup-lvl3 sm-notify[1847]: Version 1.2.8 starting
Nov 20 13:26:26 backup-lvl3 nfs-common[1841]: Starting NFS common 
utilities: statd idmapd.

root@backup-lvl3:~# systemctl status rpcbind.service
● rpcbind.service - LSB: RPC portmapper replacement
   Loaded: loaded (/etc/init.d/rpcbind)
  Drop-In: /run/systemd/generator/rpcbind.service.d
   └─50-rpcbind-$portmap.conf
   Active: active (running) since Do 2014-11-20 13:24:03 CET; 2h 29min ago
  Process: 1006 ExecStart=/etc/init.d/rpcbind start (code=exited, 
status=0/SUCCESS)

   CGroup: /system.slice/rpcbind.service
   └─1050 /sbin/rpcbind -w

Nov 20 13:24:03 backup-lvl3 rpcbind[1006]: Starting rpcbind daemon
root@backup-lvl3:~# systemctl status rpcbind.target
● rpcbind.target - RPC Port Mapper
   Loaded: loaded (/etc/insserv.conf.d/rpcbind; static)
  Drop-In: /run/systemd/generator/rpcbind.target.d
   └─50-hard-dependency-rpcbind-$portmap.conf
   Active: active since Do 2014-11-20 13:24:03 CET; 2h 29min ago
 Docs: man:systemd.special(7)
root@backup-lvl3:~# systemctl status paths.target
● paths.target - Paths
   Loaded: loaded (/lib/systemd/system/paths.target; static)
   Active: inactive (dead)
 Docs: man:systemd.special(7)
root@backup-lvl3:~# systemctl status basic.target
● basic.target - Basic System
   Loaded: loaded (/lib/systemd/system/basic.target; static)
   Active: active since Do 2014-11-20 13:23:59 CET; 2h 29min ago
 Docs: man:systemd.special(7)



  systemctl show nfs-common.service


root@backup-lvl3:~# systemctl show nfs-common.service
Type=forking
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=0
TimeoutStopUSec=0
WatchdogUSec=0
WatchdogTimestamp=Do 2014-11-20 13:26:26 CET
WatchdogTimestampMonotonic=153842467
StartLimitInterval=1000
StartLimitBurst=5
StartLimitAction=none
FailureAction=none
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=yes
GuessMainPID=no
MainPID=0
ControlPID=0
Result=success
ExecMainStartTimestampMonotonic=0
ExecMainExitTimestampMonotonic=0
ExecMainPID=0
ExecMainCode=0
ExecMainStatus=0
ExecStart={ path=/etc/init.d/nfs-common ; argv[]=/etc/init.d/nfs-common 
start ; ignore_errors=no ; start_time=[Do 2014-11-20 13:26:26 CET] ; 
stop_time=[Do 2014-11-20 13:26:26 CET] ; pid=1841 ; code=exited ; status=0 }
ExecStop={ path=/etc/init.d/nfs-common ; argv[]=/etc/init.d/nfs-common 
stop ; ignore_errors=no ; start_time=[Do 2014-11-20 13:26:26 CET] ; 
stop_time=[Do 2014-11-20 13:26:26 CET] ; pid=1834 ; code=exited ; status=0 }

Slice=system.slice
ControlGroup=/system.slice/nfs-common.service
CPUAccounting=no
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=(null)
BlockIOAccounting=no
BlockIOWeight=18446744073709551615
StartupBlockIOWeight=18446744073709551615
MemoryAccounting=no
MemoryLimit=18446744073709551615
DevicePolicy=auto
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=4096
LimitAS=18446744073709551615
LimitNPROC=104671
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=104671
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=5
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=no
IgnoreSIGPIPE=no
NoNewPrivileges=no
SystemCallErrorNumber=0
RuntimeDirectoryMode=0755
KillMode=process
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
Id=nfs-common.service
Names=nfs-common.service
Wants=system.slice
WantedBy=sysinit.target
Conflicts=shutdown.target
Before=console-setup.service sysinit.target shutdown.target kbd.service 
nfs-kernel-server.service
After=networking.service rpcbind.service

Bug#768548: rpcbind: LSB headers should provide $portmap virtual facility

[Patrick Matthäi]

Am 20.11.2014 um 14:03 schrieb Simon McVittie:

On Thu, 20 Nov 2014 at 13:30:58 +0100, Patrick Matthäi wrote:

I can reproduce it on a system, nfs- is not starting on boot.

This might actually be more relevant to nfs-common's existing RC bug
(since you presumably need to have nfs-common installed for this
configuration), but I would rather not attach yet more to that bug
since I think it's already mixing up somewhere between 3 and 5 related
issues.

Please specify your systemd, nfs-common and rpcbind versions,


# dpkg -l|egrep "portmap|rpcbind|nfs-"
ii  nfs-common 1:1.2.8-9 amd64NFS support 
files common to client and server
ii  nfs-kernel-server  1:1.2.8-9 amd64support for 
NFS kernel server
ii  rpcbind0.2.1-6 amd64converts RPC 
program numbers into universal addresses



the output of:

 systemctl status nfs-common.service
 systemctl show nfs-common.service

and the same for rpcbind.service, rpcbind.target, paths.target and
basic.target (i.e. the stuff implicated in your dependency loop).

If the "systemctl status" calls list any "Drop-In" files, please also
provide those.


Should I provide them after a reboot (without manual starting the nfs 
services) or just while they are running?




If you have local modifications to /etc/init.d/nfs-common,
/etc/init.d/rpcbind and/or /etc/insserv.conf{,.d} please attach those too.


No changes have been made.



The output of "reportbug --template systemd" might also be interesting,
but is rather long and hopefully unnecessary.


Package: systemd
Version: 215-5+b1

-- Package-specific info:

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-57
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1
ii  libblkid1   2.25.2-2
ii  libc6   2.19-13
ii  libcap2 1:2.24-6
ii  libcap2-bin 1:2.24-6
ii  libcryptsetup4  2:1.6.6-3
ii  libgcrypt20 1.6.2-4
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b1
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-5+b1
ii  sysv-rc 2.88dsf-57
ii  udev215-5+b1
ii  util-linux  2.25.2-2

Versions of packages systemd recommends:
pn  dbus
pn  libpam-systemd  

Versions of packages systemd suggests:
pn  systemd-ui  




I would also like to know whether you have a non-unified /usr (i.e.
not on the rootfs), or any networked or otherwise unusual filesystems
in fstab. (Just a wild guess, it might not be relevant at all.)


Nothing like that:

Filesystem  Size  Used Avail Use% Mounted on
/dev/mapper/backup--lvl3-root58G   23G   35G  40% /
udev 10M 0   10M   0% /dev
tmpfs   5.2G  8.8M  5.2G   1% /run
tmpfs13G  4.0K   13G   1% /dev/shm
tmpfs   5.0M 0  5.0M   0% /run/lock
tmpfs13G 0   13G   0% /sys/fs/cgroup
/dev/sda1   228M   52M  164M  24% /boot
/dev/mapper/lvl3--storage-data   28T   14T   15T  48% /mnt





Nov 20 13:23:56 backup-lvl3 systemd[1]: Cannot add dependency job for unit
display-manager.service, ignoring: Unit display-manager.service failed to
load: No such file or directory.
Nov 20 13:23:56 backup-lvl3 systemd[1]: Found ordering cycle on
basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Breaking ordering cycle by deleting
job paths.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Job paths.target/start deleted to
break ordering cycle starting with basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Found ordering cycle on
basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Breaking ordering cycle by deleting
job rpcbind.service/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Job rpcbind.service/start deleted to
break ordering cycle starting with basic.target/start

So this is Very Bad: systemd has found a dependency loop in early boot
(basic.target is approximately equivalent to the earlier parts of rcS.d),
and broken it in an essentially random place because that's somewhat
more likely to succeed than just refusing to continue.

The question is why this dependency loop exists. Presumably, one of
the dependencies is unnecessary or wrong.

I think I might actually have been wrong with the initial report of this
bug: /etc/init.d/rpcbind does not provide $portmap, but
/etc/insserv.conf.d/rpcbind does, and recent(ish) systemd is meant to
respect both. So systemd *s

Bug#769335: otrs2: fails to upgrade from 'wheezy': /usr/share/dbconfig-common/scripts/otrs2/upgrade/pgsql/3.2.1 exited with non-zero status

[Patrick Matthäi]

Hi,

I am closing this invalid bug (fixed with dbconfig-common).


Am 14.11.2014 um 17:36 schrieb Patrick Matthäi:

Am 14.11.2014 um 10:54 schrieb Paul Gevers:

=> dbconfig creates and handle database.pm and it is generated with the
following values:
dbc_generate_include_owner="otrs:www-data"
dbc_generate_include_perms="0640"

=> Can't locate /etc/otrs/database.pm:   Permission denied at
/usr/share/otrs/Kernel/Config.pm line 27.

=> line 26 checks for the existance of database.pm. if it exists (-f)
then a require is executed in line 27, which is the case here, but you
have got wrong permissions? which ones?

=> this whole issue is not triggered in my manual wheezy->jessie upgrade
process

=> and again, dbconfig-common handles this file, but I think the bug is
in your testing suite/piuparts

We had a bug in dbconfig-common exactly in this area. It might be that
this bug is a duplicate of bug 767248 that was fixed recently.

Much thanks for pointing to this Paul!

@Andreas:
Could you please retest with an up-to-date dbconfig-common?




--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#768548: rpcbind: LSB headers should provide $portmap virtual facility

[Patrick Matthäi]

severity #768548 serious
thanks

Hello,

I can reproduce it on a system, nfs- is not starting on boot. From 
journalctl:


Nov 20 13:23:56 backup-lvl3 kernel: PM: Hibernation image partition 
254:1 present

Nov 20 13:23:56 backup-lvl3 kernel: PM: Looking for hibernation image.
Nov 20 13:23:56 backup-lvl3 kernel: PM: Image not found (code -22)
Nov 20 13:23:56 backup-lvl3 kernel: PM: Hibernation image not present or 
could not be loaded.
Nov 20 13:23:56 backup-lvl3 kernel: EXT4-fs (dm-0): mounted filesystem 
with ordered data mode. Opts: (null)
Nov 20 13:23:56 backup-lvl3 systemd[1]: Cannot add dependency job for 
unit dbus.socket, ignoring: Unit dbus.socket failed to load: No such 
file or directory.
Nov 20 13:23:56 backup-lvl3 systemd[1]: Cannot add dependency job for 
unit display-manager.service, ignoring: Unit display-manager.service 
failed to load: No such file or directory.
Nov 20 13:23:56 backup-lvl3 systemd[1]: Found ordering cycle on 
basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Breaking ordering cycle by 
deleting job paths.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Job paths.target/start deleted 
to break ordering cycle starting with basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Found ordering cycle on 
basic.target/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Breaking ordering cycle by 
deleting job rpcbind.service/start
Nov 20 13:23:56 backup-lvl3 systemd[1]: Job rpcbind.service/start 
deleted to break ordering cycle starting with basic.target/start

Nov 20 13:23:56 backup-lvl3 kernel: loop: module loaded
Nov 20 13:23:56 backup-lvl3 systemd-journal[215]: Journal started
Nov 20 13:23:56 backup-lvl3 systemd-modules-load[211]: Inserted module 
'loop'
Nov 20 13:23:56 backup-lvl3 systemd-fsck[208]: ROOT: sauber, 
76335/3833856 Dateien, 6158364/15334400 Blöcke

Nov 20 13:23:56 backup-lvl3 systemd-udevd[232]: starting version 215
Nov 20 13:23:56 backup-lvl3 systemd-udevd[232]: Network interface 
NamePolicy= disabled on kernel commandline, ignoring.
Nov 20 13:23:57 backup-lvl3 systemd-udevd[232]: Network interface 
NamePolicy= disabled on kernel commandline, ignoring.
Nov 20 13:23:57 backup-lvl3 kernel: input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input2

Nov 20 13:23:57 backup-lvl3 kernel: ACPI: Power Button [PWRF]
Nov 20 13:23:57 backup-lvl3 kernel: ACPI: AC Adapter [ACAD] (on-line)
Nov 20 13:23:57 backup-lvl3 kernel: shpchp: Standard Hot Plug PCI 
Controller Driver version: 0.4

..

Later:
Nov 20 13:24:00 backup-lvl3 systemd-udevd[232]: Network interface 
NamePolicy= disabled on kernel commandline, ignoring.
Nov 20 13:24:00 backup-lvl3 kernel: RPC: Registered named UNIX socket 
transport module.

Nov 20 13:24:00 backup-lvl3 kernel: RPC: Registered udp transport module.
Nov 20 13:24:00 backup-lvl3 kernel: RPC: Registered tcp transport module.
Nov 20 13:24:00 backup-lvl3 kernel: RPC: Registered tcp NFSv4.1 
backchannel transport module.
Nov 20 13:24:00 backup-lvl3 acpid[739]: starting up with netlink and the 
input layer
Nov 20 13:24:00 backup-lvl3 kernel: Installing knfsd (copyright (C) 1996 
o...@monad.swb.de).
Nov 20 13:24:00 backup-lvl3 nfs-kernel-server[725]: Exporting 
directories for NFS kernel daemon

Nov 20 13:24:00 backup-lvl3 linuxlogo[728]: Updating the system logo...done.
Nov 20 13:24:00 backup-lvl3 nfs-kernel-server[725]: Starting NFS kernel 
daemon: nfsd
Nov 20 13:24:00 backup-lvl3 nfs-kernel-server[725]: Not starting: 
portmapper is not running ... (warning).

Nov 20 13:24:00 backup-lvl3 acpid[739]: 1 rule loaded
Nov 20 13:24:00 backup-lvl3 acpid[739]: waiting for events: event 
logging is off

Nov 20 13:24:00 backup-lvl3 vmware-tools[726]: [32B blob data]
Nov 20 13:24:00 backup-lvl3 vmware-tools[726]: Starting VMware Tools 
services in the virtual machine:

Nov 20 13:24:00 backup-lvl3 sshd[721]: Server listening on 0.0.0.0 port 22.
Nov 20 13:24:00 backup-lvl3 sshd[721]: Server listening on :: port 22.
Nov 20 13:24:01 backup-lvl3 vmware-tools[726]: [43B blob data]
Nov 20 13:24:01 backup-lvl3 vmware-tools[726]: /etc/init.d/vmware-tools: 
1153: [: =: unexpected operator

Nov 20 13:24:02 backup-lvl3 vmware-tools[726]: [40B blob data]
Nov 20 13:24:03 backup-lvl3 rpcbind[1006]: Starting rpcbind daemon
Nov 20 13:24:03 backup-lvl3 nrpe[1059]: Starting up daemon
Nov 20 13:24:03 backup-lvl3 nagios-nrpe-server[1010]: Starting 
nagios-nrpe: nagios-nrpe.
Nov 20 13:24:03 backup-lvl3 nrpe[1059]: Server listening on 0.0.0.0 port 
5666.

Nov 20 13:24:03 backup-lvl3 nrpe[1059]: Server listening on :: port 5666.


So the ordering is not correct. Upgrading to serious (ACK with Simon).

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#770035: kdenlive: Processed videos have image pauses or accelerations while sound goes well

[Patrick Matthäi]

Hi Dan,

do you have an idea to http://bugs.debian.org/770035 ?

Am 19.11.2014 um 14:54 schrieb Javier Ortega Conde (Malkavian):


Could you retest it with the libmlt*, mlt*, melt* packages from
experimental (not jessie/sid)?


Done, and problem persists.



--
Agur: Javier Ortega Conde (Malkavian)

MetaUniversidad: servicios de educación online http://metauniversidad.com


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#770035: kdenlive: Processed videos have image pauses or accelerations while sound goes well

[Patrick Matthäi]

Could you retest it with the libmlt*, mlt*, melt* packages from 
experimental (not jessie/sid)?


Am 19.11.2014 um 13:45 schrieb Javier Ortega Conde (Malkavian):

>Not everything is a release critical bug just because we are in freeze..

I didn't marked it as critical. For me is grave because I can't work 
with it, but change it if you think is better.


> Is the result also not working or do you mean the preview function 
from kdenlive?


The preview works well. The result is that my final videos, gotten by 
rendering them, aren't as expected.


Here you have two short examples of the problems I have with redered 
videos:


Pause not expected:
https://www.youtube.com/watch?v=sE-D8NkXCqk

Acceleration not expected:
https://www.youtube.com/watch?v=VuYURUzDTOk


--
Agur: Javier Ortega Conde (Malkavian)

MetaUniversidad: servicios de educación online http://metauniversidad.com



--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/

Bug#770035: kdenlive: Processed videos have image pauses or accelerations while sound goes well

[Patrick Matthäi]

Am 18.11.2014 um 15:10 schrieb Javier Ortega Conde (Malkavian):

Package: kdenlive
Version: 0.9.10-2
Severity: grave


Not everything is a release critical bug just because we are in freeze..


Justification: renders package unusable

I am editing some videos recorded with a camera "Canon Legria HF G25" at 1080p,
and then processing them to get a final video. When I watch the generated video
in the begining the image is paused or accelerated for some seconds, while the
audio works well (and so, it desynchronize). With Openshot all works well
(altought much slower). I can upload to a server short samples of original and
final videos if you want. Tell me if I can help to hunt the bug.

Mplayer says this about original videos from the camera:
Selected video codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [libavcodec]
Selected audio codec: ATSC A/52A (AC-3) [libavcodec]
AUDIO: 48000 Hz, 2 ch, floatle, 256.0 kbit/8.33% (ratio: 32000->384000)
AO: [pulse] 48000Hz 2ch floatle (4 bytes per sample)
Starting playback...
VIDEO:  1920x1080  50.000 fps0.0 kbps ( 0.0 kB/s)
VO: [xv] 1920x1080 => 1920x1080 Planar YV12



Is the result also not working or do you mean the preview function from 
kdenlive?


--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#769544: needrestart: prompts user without following Debian Configuration Management Specification - accesses /dev/tty

[Patrick Matthäi]

Am 15.11.2014 um 18:32 schrieb Thomas Liske:
> But that's just academic - the bug is silly and needs to be fixed
> for jessie without any doubt.

ACK.

> Paravirtualized using libvirt AFAIK - there are many other
> virtualization environments requiring a kernel image inside the
> container. But the bug should keep a severity of serious[1] if it
> violates the debian policy.

The severity is OK for me, since this bug affects some well known
container based virtualization platforms and also chroots, if /boot is
missing with kernel images. Common scenarios.

>> The current upload you want to get into jessie was only uploaded with
>> priority=low. If the upstream fix for this bug here gets backported
>> and uploaded with priority=medium it would be eligible for migration
>> at the same time. I think you should do that, especially since I do
>> not see an unblock request for the current version in sid.
> 
> The patch for #767370 and #769544 has not been uploaded by Patrick, yet.

I have just uploaded needrestart=1.2+git20141115-1 to experimental (for
additional testing).
The next jessie/unstable upload *will* fix this issue, but first I want
to see 1.2-4 in jessie (since it has got some more changes).

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#769582: amarok gets silent on manual song changes

[Patrick Matthäi]

Package: amarok
Version: 2.8.0-2.1+b1
Severity: grave

Hello,

first: I were not realy sure if severity grave is realy correct, since
most amarok functions are working. But after some hours I have decided
that this is a grave error, since it is not usable as media player anymore.

Problem description:
- If I start amarok and then start a song on the right side (eg
doubleclick) it starts playing. If I manualy change the song again on
the right side audio output is not working anymore until I restart amarok
- if I start  amarok and only using the back- and forward button to
change songs, everything is working. but if I start again a song
manualy, no audio output
- automatic song changes also work fine

So amarok is here not able to produce any audio output, after I have
changed (not initialy started) a song in my playlist.

I have started amarok with "--nofork --debug" and attached the full log.
It contains the following:
- starting of amarok with --nofork and --debug
- starting to play a song
- manualy switching the song again (no audio output anymore). _BEFORE_ I
switched the song, I have marked the location with ">>> now changing
manual" at line 955

Hope this will help you to identify the issue.
You can also contact me on IRC (the-me).

-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


amarok.debug.log.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#769335: otrs2: fails to upgrade from 'wheezy': /usr/share/dbconfig-common/scripts/otrs2/upgrade/pgsql/3.2.1 exited with non-zero status

[Patrick Matthäi]

Am 14.11.2014 um 10:54 schrieb Paul Gevers:
>> => dbconfig creates and handle database.pm and it is generated with the
>> following values:
>> dbc_generate_include_owner="otrs:www-data"
>> dbc_generate_include_perms="0640"
>>
>> => Can't locate /etc/otrs/database.pm:   Permission denied at
>> /usr/share/otrs/Kernel/Config.pm line 27.
>>
>> => line 26 checks for the existance of database.pm. if it exists (-f)
>> then a require is executed in line 27, which is the case here, but you
>> have got wrong permissions? which ones?
>>
>> => this whole issue is not triggered in my manual wheezy->jessie upgrade
>> process
>>
>> => and again, dbconfig-common handles this file, but I think the bug is
>> in your testing suite/piuparts
> 
> We had a bug in dbconfig-common exactly in this area. It might be that
> this bug is a duplicate of bug 767248 that was fixed recently.

Much thanks for pointing to this Paul!

@Andreas:
Could you please retest with an up-to-date dbconfig-common?


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature

Bug#769544: needrestart: prompts user without following Debian Configuration Management Specification - accesses /dev/tty

[Patrick Matthäi]

Am 14.11.2014 um 13:07 schrieb Andreas Beckmann:
> Well, there shouldn't any output get on that console ..., so let's look
> at the running processes:
> 
> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
> needresta 20673 root  cwdDIR   0,19   60 532392089 
> /tmp/piupartss/tmpubCt88/tmp
> needresta 20673 root  rtdDIR   0,19  460 532372904 
> /tmp/piupartss/tmpubCt88
> needresta 20673 root  txtREG   0,1910416 532382504 
> /tmp/piupartss/tmpubCt88/usr/bin/perl
> needresta 20673 root  memREG   0,1918728 532387760 
> /tmp/piupartss/tmpubCt88/usr/lib/x86_64-linux-gnu/perl/5.20.1/auto/IO/IO.so
> 
> needresta 20673 root  memREG   0,19  1827768 532387323 
> /tmp/piupartss/tmpubCt88/usr/lib/x86_64-linux-gnu/libperl.so.5.20.1
> needresta 20673 root  memREG   0,19   140928 532442638 
> /tmp/piupartss/tmpubCt88/lib/x86_64-linux-gnu/ld-2.19.so
> needresta 20673 root0r   CHR5,0  0t0 532392052 
> /tmp/piupartss/tmpubCt88/dev/tty
> needresta 20673 root1w   CHR5,0  0t0 532392052 
> /tmp/piupartss/tmpubCt88/dev/tty
> needresta 20673 root2w  FIFO0,8  0t0 532480261 pipe
> needresta 20673 root3r   REG   0,19 3485 532493945 
> /tmp/piupartss/tmpubCt88/usr/share/perl5/NeedRestart/UI/Debconf.pm
> needresta 20673 root4r  FIFO0,8  0t0 532499621 pipe
> needresta 20673 root5w  FIFO0,8  0t0 532499622 pipe
> needresta 20673 root6r  FIFO0,8  0t0 532579111 pipe
> 
> You may not access /dev/tty for prompting (or whatever) ...
> use debconf *properly*.

Hi,

I think this is a duplicate of bug #767370
Could you add a linux-image to your piuparts packages and test, if the
issue is gone away (not that there is another one)?


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/



signature.asc
Description: OpenPGP digital signature