Bug#811432: Krita no longer part of Calligra

2016-09-04 Thread James Cowgill 
Hi,

On 04/09/16 05:42, juichenieder-deb...@yahoo.co.uk wrote:
> Just found out about Krita, and thinking about giving it a try...
> 
> 
> Does the fact that the latest stable version of Krita upstream (3.x) has now 
> split from Calligra have any bearing
> on this bug?
> 
> I.e. instead of trying to fix these issues, we should just start from a clean 
> slate with Calligra?

My guess is that most of these bugs will fix themselves once 2.9 is
packaged. I think there were some attempts to fix these before, but the
package was rejected by the ftpmasters on copyright grounds - so they'll
need to be some work to sort that out.

However since Krita is now separate, I think it should be packaged
separately in its own source package. Krita also forked calligra-libs so
they'll be some code duplication, but I don't see any way around that.
The new Krita package could then ignore the bugs that don't apply to it
anymore.

I was thinking about helping packaging Krita, but I haven't found the
time as of yet.

James



signature.asc
Description: OpenPGP digital signature

Bug#836608: qtcreator: Please use llvm 3.8 or, better, 3.9

2016-09-04 Thread Sylvestre Ledru 

Source: qtcreator
Severity: important
Control: block 836604 by -1

Hello,

This package depends on llvm-toolchain-3.6.

To limit the number of llvm versions in the next Debian stable, we
would like all packages using/depending llvm/clang/lldb to move to version
3.8 or 3.9 so that we can remove LLVM 3.5, 3.6 and 3.7 from the Debian archive.

This package also blocks the transition to llvm 3.8
https://release.debian.org/transitions/html/llvm-defaults-3.8.html

Thanks,
Sylvestre

Processed: qtcreator: Please use llvm 3.8 or, better, 3.9

2016-09-04 Thread Debian Bug Tracking System 
Processing control commands:

> block 836604 by -1
Bug #836604 [ftp.debian.org] RM: llvm-toolchain-3.6 -- ROM; We should ship only 
3.8, 3.9 and maybe 4.0 in the next stable
836604 was blocked by: 836607 836606
836604 was not blocking any bugs.
Added blocking bug(s) of 836604: 836608

-- 
836604: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836604
836608: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836608
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#811432: Krita no longer part of Calligra

2016-09-04 Thread juichenieder-debbie 


Hi,

> My guess is that most of these bugs will fix themselves once 2.9 is
> packaged. I think there were some attempts to fix these before, but the
> package was rejected by the ftpmasters on copyright grounds - so they'll
> need to be some work to sort that out.


Yes, pretty much my philosophy.  Why put time and energy into fixing something
that you plan to discard for a newer version shortly after you have fixed it.
When for all one knows, the upgraded package might auto-fix the problems you
were trying to fix.

That said, the copyright grounds don't seem too severe... I guess the file that
they object to appeared in the build before, as they do not upload a new 
version,
thus it must also appear in Jessie and Sid ports, and only one file that could
get downloaded seperately.



How much of a task goes into packaging something like Calligra?  I see that
calligra-2.9.10 went into the debian VCS on 2015-12-31 (last entry).  I have
no experience in packaging, slowly as time goes on I learn more and more about
this dark art, until I reach the point where I feel ready to take the plunge.

> However since Krita is now separate, I think it should be packaged
> separately in its own source package. Krita also forked calligra-libs so
> they'll be some code duplication, but I don't see any way around that.
> The new Krita package could then ignore the bugs that don't apply to it

> anymore.

Aye, and it allows for more streamlined development, both for us and for them.
Calligra still on 2.9, whilst Krita had landed 3.0.  A shame though that they
felt they had to fork calligra-libs, I always hate code duplication.  I would
have hoped that they could find a way to compromise on how they want the
library to operate.

> I was thinking about helping packaging Krita, but I haven't found the

> time as of yet.

I would consider packaging it myself, but as I say, I don't feel quite ready
to take the plunge just yet, and the time commitment puts me of a bit.  I have
reached the stage where ${misc:Depends} and ${shlibs:Depends} now pique my
curiosity as that seems part of the initial problem here in this bug.  That
debian autodetects the wrong library (to link against?).  As far as I 
understand.


Jack

Bug#836431: ksnapshot: Update dependency from libkipi11 to libkf5kipi31.0.0

2016-09-04 Thread Alex Henry 
Thank you Diederik. I see the unstable knaspshot package is now a
transitional package. I'm not sure if I didn't notice this before or if
this was maybe prompted by this bug report here. Anyway, thank you for the
info and work as a Debian maintainer :)

On 3 September 2016 at 13:42, Diederik de Haas 
wrote:

> On zaterdag 3 september 2016 00:00:31 CEST Alex Henry wrote:
> > ksnapshot is holding back gwenview
>
> Switch to kde-spectacle which is the successor to ksnapshot.
> Ksnapshot is no longer developed and it is likely it will be removed from
> the
> archives.

Bug#836513: Removed package(s) from unstable

2016-09-04 Thread Debian FTP Masters 
We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

 ksnapshot | 4:15.04.3-1 | source, kfreebsd-amd64, kfreebsd-i386
 ksnapshot | 4:15.08.0-1 | source, amd64, arm64, armel, armhf, hurd-i386, i386, 
mips, mips64el, mipsel, powerpc, ppc64el, s390x

--- Reason ---
ROM; dead upstream, replaced by kde-spectacle
--

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive and will not propagate to any mirrors until the next
dinstall run at the earliest.

Packages are usually not removed from testing by hand. Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems. The release team can force a removal from testing if it is
really needed, please contact them if this should be the case.

We try to close bugs which have been reported against this package
automatically. But please check all old bugs, if they were closed
correctly or should have been re-assigned to another package.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 836...@bugs.debian.org.

The full log for this bug can be viewed at https://bugs.debian.org/836513

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Chris Lamb (the ftpmaster behind the curtain)

Bug#836412: qtwebchannel-opensource-src: FTBFS (big-endian): qtbug46548_overriddenProperties() Received signal 11

2016-09-04 Thread Aaron M. Ucko 
[Oops, accidentally sent a private reply the first time.]

Hi, Sandro.

In general, it's possible to request temporary guest access to specific
porterboxes, but I don't know how promptly such requests tend to go
through.  For the record, you can find relevant documentation at

https://dsa.debian.org/doc/guest-account
https://dsa.debian.org/doc/schroot

At any rate, I've obtained a full backtrace from a powerpc system
(partch).  Sorry for not getting it to you earlier; I've had a busy
weekend.

[New LWP 16527]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc-linux-gnu/libthread_db.so.1".
0x0f203f38 in waitpid () from /lib/powerpc-linux-gnu/libc.so.6
(gdb) 
Thread 2 (Thread 0xf7cff440 (LWP 16527)):
#0  0x0ede0138 in pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib/powerpc-linux-gnu/libpthread.so.0
No symbol table info available.
#1  0x0f2556c8 in pthread_cond_timedwait ()
   from /lib/powerpc-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0f605378 in QWaitCondition::wait(QMutex*, unsigned long) ()
   from /usr/lib/powerpc-linux-gnu/libQt5Core.so.5
No symbol table info available.
#3  0x0fb24c9c in ?? () from /usr/lib/powerpc-linux-gnu/libQt5Test.so.5
No symbol table info available.
#4  0x0f6040e0 in ?? () from /usr/lib/powerpc-linux-gnu/libQt5Core.so.5
No symbol table info available.
#5  0x0edd7500 in start_thread () from /lib/powerpc-linux-gnu/libpthread.so.0
No symbol table info available.
#6  0x0f2438ec in clone () from /lib/powerpc-linux-gnu/libc.so.6
No symbol table info available.

Thread 1 (Thread 0xf7d48dd0 (LWP 16526)):
#0  0x0f203f38 in waitpid () from /lib/powerpc-linux-gnu/libc.so.6
No symbol table info available.
#1  0x0f189990 in ?? () from /lib/powerpc-linux-gnu/libc.so.6
No symbol table info available.
#2  0x0fb1aa38 in ?? () from /usr/lib/powerpc-linux-gnu/libQt5Test.so.5
No symbol table info available.
#3  0x0fb1ab7c in ?? () from /usr/lib/powerpc-linux-gnu/libQt5Test.so.5
No symbol table info available.
#4  
No symbol table info available.
#5  0x0fd01e18 in QV4::ExecutionContext::getFunctionObject() const ()
   from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#6  0x0fcf73e8 in QV4::ExecutionEngine::stackTrace(int) const ()
   from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#7  0x0fd2c634 in ?? () from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#8  0x0fcfc264 in ?? () from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#9  0x0fcf7e00 in QV4::ExecutionEngine::throwReferenceError(QV4::Value const&)
() from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#10 0x0fd00c48 in QV4::ExecutionContext::getProperty(QV4::String*) ()
   from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#11 0x0fdb3ef0 in QV4::Runtime::typeofName(QV4::ExecutionEngine*, int) ()
   from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#12 0x0fd9a29c in ?? () from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#13 0x0fd9bff4 in ?? () from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#14 0x0fd650f4 in QV4::Script::run() ()
   from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#15 0x0fcb7528 in QJSEngine::evaluate(QString const&, QString const&, int) ()
   from /usr/lib/powerpc-linux-gnu/libQt5Qml.so.5
No symbol table info available.
#16 0x10006568 in TestJSEngine::TestJSEngine (this=0xffa17ce0)
at tst_webchannel.cpp:168
webChannelJSPath = {static null = {}, 
  d = 0x100147fc 
}
webChannelJS = 
source = {static null = {}, d = 0x1010d300}
#17 0x1000bee0 in TestWebChannel::qtbug46548_overriddenProperties (
this=) at tst_webchannel.cpp:602
obj = { = { = {}, 
static staticMetaObject = {d = {
superdata = 0xfae6970 , 
stringdata = 0x1001569c , 
data = 0x10016464 , 
static_metacall = 0x100116b0 
, 
relatedMetaObjects = 0x0, 
extradata = 0x0}}, mObjectProperty = 0x0}, 
  static staticMetaObject = {d = {
  superdata = 0x1002fbec , 
  stringdata = 0x10014638 
, data = 0x10014bc0 
, 
  static_metacall = 0x10005610 
, relatedMetaObjects = 0x0, 
  extradata = 0x0}}}
webChannel = { = {}, 
  static staticMetaObject = {d = {
  superdata = 0xfae6970 , 
  stringdata = 0xffca994 , 
  data = 0xffcab2c , 
  static_metacall = 0xffb7510 
, 
relatedMetaObjects = 0x0, 
  extradata = 0x0}}}
engine = { = {}, static staticMetaObject = {
d = {superdata = 0xff87620 , 
  stringdata = 0x10014b30 , 
  data = 0x10014c24 , 
  static_metacall = 0x100047e0 
, 
relatedMetaObjects = 0x0, 
  extra

Bug#836564: Missing OnlyShowIn=KDE; in klipper autostart file

2016-09-04 Thread Lisandro Damián Nicanor Pérez Meyer 
On domingo, 4 de septiembre de 2016 3:03:12 A. M. ART Michael Biebl wrote:
> Am 04.09.2016 um 02:44 schrieb Lisandro Damián Nicanor Pérez Meyer:
> > I have friends that used to use klipper in gnome, although i don't know
> > if that's still possible.
> 
> They can easily remove the key from the desktop file, but this shouldn't
> be the default.

Agree with that.

> It's irritating that this is started in a default GNOME desktop and
> half-broken, you don't see any icon only an empty space that is taken up
> in the systray.

That's a bug which *might* probably related to #803423 for which we don't have 
a proper solution yet (we do have workarounds). But it might still be 
something else.

By the way, it would be really cool if you can confirm if it's this bug or 
not.

> If you don't want to make it KDE specific, please at least add
> NotShowIn=GNOME;

I personally don't think that's the right way to go. The fact that an app/lib 
has a bug doesn't means it should be restricted from an specific desktop. But 
I'll leave this decision to Maxy, he's the one doing the big job here.

> As a side note, the desktop file had OnlyShowIn=KDE; a while ago, but
> for some reason this was dropped.

To make it available in other desktops, see:



Kinds regards, Lisandro.

-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#836564: Missing OnlyShowIn=KDE; in klipper autostart file

2016-09-04 Thread Michael Biebl 
Am 04.09.2016 um 23:57 schrieb Lisandro Damián Nicanor Pérez Meyer:
> On domingo, 4 de septiembre de 2016 3:03:12 A. M. ART Michael Biebl wrote:
>> Am 04.09.2016 um 02:44 schrieb Lisandro Damián Nicanor Pérez Meyer:
>>> I have friends that used to use klipper in gnome, although i don't know
>>> if that's still possible.
>>
>> They can easily remove the key from the desktop file, but this shouldn't
>> be the default.
> 
> Agree with that.

I guess you misread what I wrote. With "this" i meant that it's run
everywhere. So to make it clear, I don't think klipper should run under
every available desktop by default. It should be up to the individual
desktops to decide which clipboardmanager they want to use. Having it
run by default under KDE/Plasma seems fine, but not GNOME (aside from
the bugs that currently affect it, like messing up the systray and
having messed up window placement).

Please reconsider.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#836564: Missing OnlyShowIn=KDE; in klipper autostart file

2016-09-04 Thread Lisandro Damián Nicanor Pérez Meyer 
On lunes, 5 de septiembre de 2016 12:07:49 A. M. ART Michael Biebl wrote:
> Am 04.09.2016 um 23:57 schrieb Lisandro Damián Nicanor Pérez Meyer:
> > On domingo, 4 de septiembre de 2016 3:03:12 A. M. ART Michael Biebl wrote:
> >> Am 04.09.2016 um 02:44 schrieb Lisandro Damián Nicanor Pérez Meyer:
> >>> I have friends that used to use klipper in gnome, although i don't know
> >>> if that's still possible.
> >> 
> >> They can easily remove the key from the desktop file, but this shouldn't
> >> be the default.
> > 
> > Agree with that.
> 
> I guess you misread what I wrote. With "this" i meant that it's run
> everywhere. So to make it clear, I don't think klipper should run under
> every available desktop by default. It should be up to the individual
> desktops to decide which clipboardmanager they want to use. Having it
> run by default under KDE/Plasma seems fine, but not GNOME (aside from
> the bugs that currently affect it, like messing up the systray and
> having messed up window placement).
> 
> Please reconsider.

Indeed I missread you, sorry for that. yes, it shouldn't be run by default 
except the user or the desktop upstreams decide so.

Jonathan: please take a look at the bug. I think Michael is right here, users 
should be able to use Klipper on non-plasma desktops but it shouldn't happen 
by default. Of course a fix directly in upstream will be preferable here :)

Thanks!


-- 

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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