Bug#846996: Unable to compile with g++-6

2016-12-04 Thread Thomas Viehweger
Package: qtbase5-dev
Version: 5.7.1~20161021+dfsg-6
Severity: important

Trying to compile lxqt-panel with g++-6 and qtbase5-dev_5.7.1 results in the 
following errors:

In file included from /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:43:0,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:49,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/qplugin.h:43,
 from /usr/include/x86_64-linux-gnu/qt5/QtCore/QtPlugin:1,
 from 
/home/src/lxqt-panel-de/plugin-clock/../panel/ilxqtpanelplugin.h:32,
 from /home/src/lxqt-panel-de/plugin-clock/lxqtclock.h:34,
 from /home/src/lxqt-panel-de/plugin-clock/lxqtclock.cpp:32:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qalgorithms.h: In function ‘uint 
qCountTrailingZeroBits(quint16)’:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qalgorithms.h:630:32: error: 
‘__builtin_ctzs’ was not declared in this scope
 return v ? __builtin_ctzs(v) : 16U;
^
/usr/include/x86_64-linux-gnu/qt5/QtCore/qalgorithms.h: In function ‘uint 
qCountLeadingZeroBits(quint16)’:
/usr/include/x86_64-linux-gnu/qt5/QtCore/qalgorithms.h:693:32: error: 
‘__builtin_clzs’ was not declared in this scope
 return v ? __builtin_clzs(v) : 16U;
^

This is because g++ removed __builtin_clzs and __builtin_ctzs. See for example

https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg511530.html



Bug#846963: marked as done (Kolourpaint 16.08.2: It is not possible to navigate by directories in Save as... form.)

2016-12-04 Thread Debian Bug Tracking System
Your message dated Sun, 4 Dec 2016 19:17:24 +0100
with message-id 

Bug#846964: Kolourpaint 16.08.2: It is not possible to navigate by directories in Save as... form.

2016-12-04 Thread Innocent De Marchi
Package: kolourpaint4
Version: 4:16.08.2
Severity: normal

Dear Maintainer,

With the xfce desktop, the «Save as..» form don't show the directories.
I am ask to upstreams from this issue and it turns out that installing
the kio package solves the problem.

Consider to add kio package to kolourpaint dependencies.

Regards!

I. De Marchi

P.S. Sorry for the previus message: it was a mistake!


Bug#846963: Kolourpaint 16.08.2: It is not possible to navigate by directories in Save as... form.

2016-12-04 Thread Innocent De Marchi
Package: kolourpaint4
Version: 4:16.08.2
Severity: normal

Dear Maintainer,

With the xfce desktop, the «Save as..» form don't show

the directories.


Bug#845788: plasma-desktop: Incorrect values in ~/.config/plasma*

2016-12-04 Thread Jeroen N. Witmond

On 2016-11-29 14:43, Maximiliano Curia wrote:

Control: reassign -1 qtbase5-dev 5.7.1~20161021+dfsg-6

¡Hola Jeroen!

El 2016-11-26 a las 18:54 +0100, Jeroen N. Witmond escribió:

Package: plasma-desktop Version: 4:5.8.2-1 Severity: normal



jeroen@zandbak:~$ echo $LANG en_NL.UTF-8


Mmh, I see the en_NL option in the formats kcm, which isn't a valid
locales value. This seems to be a qt issue, the combos are filled
calling:
QList allLocales =
QLocale::matchingLocales(QLocale::AnyLanguage, QLocale::AnyScript,
QLocale::AnyCountry);

I'm attaching a minimal qlocale's ls names, that can be compiled with:
c++ -fPIC -lQt5Core main.cpp
-I/usr/include/x86_64-linux-gnu/qt5/QtCore
-I/usr/include/x86_64-linux-gnu/qt5 -o main

In the hope that this might ease the reproducibility of the issue. The
script returns error if the en_NL name is present.

This could be improved using the "official" list of valid locales
entries (/usr/share/i18n/SUPPORTED).

Happy hacking,


I have reset the language to its intended value of en_US.UTF-8 using 
`kcmshell5 formats`.


Thanks for your helpful answer.



Bug#846940: org.kde.KScreen floods journal log with RRNotify_OutputProperty (ignored)

2016-12-04 Thread koos vriezen
Package: libkf5screen-bin
Version:  4:5.8.4-1

On KDE startup and then periodically I get a huge burst of

org.kde.KScreen[1167]: kscreen.xcb.helper: RRNotify_OutputProperty (ignored)
org.kde.KScreen[1167]: kscreen.xcb.helper: Output:  67
org.kde.KScreen[1167]: kscreen.xcb.helper: Property:  Backlight
org.kde.KScreen[1167]: kscreen.xcb.helper: State (newValue, Deleted):  0

messages in the user journal log. The severity is warn and the PID is
from dbus-daemon -session

I couldn't find a way to limit these logs w/o also limiting system
messages. In the dbus sources though I saw that the stdio from the
spawned processes is apparently forwarded to the syslog. So I ended up
changing the
/usr/share/dbus-1/services/org.kde.kscreen.service
to

[D-BUS Service]
Name=org.kde.KScreen
Exec=/bin/sh -c
'/usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher
>/dev/null 2>/dev/null'

which indeed helps.
IMHO kscreen should log these warnings once.


Best regards,

Koos Vriezen



Bug#840652: any status on this?

2016-12-04 Thread Sune Vuorela
On Sunday 04 December 2016 01:30:27 Sandro Knauß wrote:
> messagelib[debian/sid] 16da74f8b884e02a2835c6c1c92f8c2041aa27a1
> kdepim[debian/sid] fe28dd2cc76a4c13b5f214fb8d024a529bf2bb9c
> kleopatra[debian/sid] f5bf98dabe305aa781eb43abcc0c345bd265a38d

These looks trivial and the kind of issues that would either work or fail to 
build.


> sune/maxy: please review
> 
> the tricky part is libkleo. Because parts of libkleo the moved into QGpgME,
> and we have changes of boost::shared_ptr -> std::shared_ptr and other such
> kind of changes. 

You need to give libkleo a full get rid of boost shared_ptr to get things to 
work. It should just be an advanced search/replace job. And this is abi-
changing.

I saw this:
+template std::shared_ptr make_shared_ptr(boost::shared_ptr& 
ptr)
+{
+return std::shared_ptr(ptr.get(), [ptr](T*) mutable 
{ptr.reset();});
+}

and I got quite worried. I at least need to read up a bit on how exactly a 
reference is captured into a lambda to say if it is quite good, or incredibly 
dangerous.  Is it captured by reference or by copy ?  The latter is good. the 
first is quite bad.


> /<>/messagecomposer/src/composer/keyresolver.cpp: In function
> 'bool ByKeyID(const GpgME::Key&, const GpgME::Key&)':

There are apparantly two of these ...


> At least one questino from my side, if we update all fist dependencies to
> not use gpgmepp, we would also need to recompile the second level of
> dependencies (f.ex. libkleo->messagelib->kdepim). This is normally handled
> by a transition, but now we have transitions freeze... So how we get rid of
> kf5gpgmepp for stretch smoothly( after we found a way to handle libkleo)?

Doing a transition is the way to do it smoothly.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank