Bug#907624: Help for SIGSEGV in test suite needed when built with gcc 8.2 what works nicely with gcc 6.3

[Sune Vuorela]

On 2019-01-09, Andrey Rahmatullin  wrote:
> As usual: reading the code, debugging, printfs. Address sanitizer and/or
> valgrind may or may not help too.

I just tried throwing some tools at it.

Apparantly you need a three step thing to get to it.

address-sanitizer. First issue. The command to create the test data to
get the error.

$ ./ffindex_build -s ./test.data ./test.ffindex test/data test/data2

=
==824==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 304 byte(s) in 1 object(s) allocated from:
#0 0x7f3393888ed0 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xe8ed0)
#1 0x7f33937994f1 in ffindex_index_parse 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:325
#2 0x56072c890783 in main 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex_build.c:243
#3 0x7f33935f9b16 in __libc_start_main ../csu/libc-start.c:310

SUMMARY: AddressSanitizer: 304 byte(s) leaked in 1 allocation(s).


Oh well. rebuild without address sanitizer and run the first two steps.
Then rebuild with address sanitizer for the last step.

$ ./ffindex_modify -u ./test.ffindex b
AddressSanitizer:DEADLYSIGNAL
=
==1453==ERROR: AddressSanitizer: SEGV on unknown address 0x000ca3ff8001 (pc 
0x7f459600a9f7 bp 0x7ffd6674b8d0 sp 0x7ffd6674b8a0 T0)
==1453==The signal is caused by a READ memory access.
#0 0x7f459600a9f6 in action 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:554
#1 0x7f45960076ed in trecursemisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:26
#2 0x7f459600775d in trecursemisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:31
#3 0x7f4596007827 in twalkmisc 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/twalkmisc.h:44
#4 0x7f459600aac3 in ffindex_tree_write 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:563
#5 0x7f4596009f60 in ffindex_write 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:443
#6 0x55c8564c3fa8 in main 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex_modify.c:182
#7 0x7f4595e69b16 in __libc_start_main ../csu/libc-start.c:310
#8 0x55c8564c3259 in _start 
(/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/build/src/ffindex_modify+0x2259)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV 
/home/sune/src/ffindex-0.9.9.7.soedinglab+git20171201.74550c8/src/ffindex.c:554 
in action
==1453==ABORTING

I'm not sure that gives more new info.

Lets try valgrind.

$ valgrind ./ffindex_modify -u ./test.ffindex b
==32176== Memcheck, a memory error detector
==32176== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==32176== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==32176== Command: ./ffindex_modify -u ./test.ffindex b
==32176== 
==32176== Invalid read of size 8
==32176==at 0x4846525: trecursemisc (twalkmisc.h:25)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  Address 0x4a536e1 is 17 bytes inside a block of size 24 alloc'd
==32176==at 0x483577F: malloc (vg_replace_malloc.c:299)
==32176==by 0x4986160: tsearch (tsearch.c:338)
==32176==by 0x4847C02: ffindex_index_as_tree (ffindex.c:533)
==32176==by 0x1094D7: main (ffindex_modify.c:122)
==32176== 
==32176== Invalid read of size 8
==32176==at 0x4847C6D: action (ffindex.c:554)
==32176==by 0x4846543: trecursemisc (twalkmisc.h:26)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  Address 0x4a53d is not stack'd, malloc'd or (recently) free'd
==32176== 
==32176== 
==32176== Process terminating with default action of signal 11 (SIGSEGV)
==32176==  Access not within mapped region at address 0x4A53D
==32176==at 0x4847C6D: action (ffindex.c:554)
==32176==by 0x4846543: trecursemisc (twalkmisc.h:26)
==32176==by 0x484658E: trecursemisc (twalkmisc.h:31)
==32176==by 0x4846633: twalkmisc (twalkmisc.h:44)
==32176==by 0x4847CE0: ffindex_tree_write (ffindex.c:563)
==32176==by 0x48477C2: ffindex_write (ffindex.c:443)
==32176==by 0x10985E: main (ffindex_modify.c:182)
==32176==  If you believe this happened as a result of a stack
==32176==  overflow in your program's main thread (unlikely but
==32176==  possible), you can try to increase the 

Bug#910531: Severity

[Sune Vuorela]

severity 910531 normal
thanks

This doesn't make it unusable for everyone, so lowering severity.

/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

Bug#875100: [plasma-widget-yawp] Future Qt4 removal from Buster

[Sune Vuorela]

I'm not sure we have any plasma4 shells left in the archive, so if there is no 
Plasma5 progress, maybe just removing it is the way forward.

I suggest if no reply, RoQA it in a month. That's also the 1 year anniversary 
of this bug.

/Sune

On Saturday, September 9, 2017 10:18:49 PM CEST Lisandro Damián Nicanor Pérez 
Meyer wrote:
> Source: plasma-widget-yawp
> Version: 0.4.2-1
> Severity: wishlist
> User: debian-qt-...@lists.debian.org
> Usertags: qt4-removal
> 
> 
> Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
> as [announced] in:
> 
> [announced]
> 
> 
> Currently Qt4 has been dead upstream and we are starting to have problems
> maintaining it, like for example in the [OpenSSL 1.1 support] case.
> 
> [OpenSSL 1.1 support]
> 
> 
> In order to make this move, all packages directly or indirectly depending on
> the Qt4 libraries have to either get ported to Qt5 or eventually get
> removed from the Debian repositories.
> 
> Therefore, please take the time and:
> - contact your upstream (if existing) and ask about the state of a Qt5
> port of your application
> - if there are no activities regarding porting, investigate whether there
> are suitable alternatives for your users
> - if there is a Qt5 port that is not yet packaged, consider packaging it
> - if both the Qt4 and the Qt5 versions already coexist in the Debian
> archives, consider removing the Qt4 version
> 
> = Porting =
> 
> Some of us where involved in various Qt4 to Qt5 migrations [migration] and
> we know for sure that porting stuff from Qt4 to Qt5 is much much easier and
> less painful than it was from Qt3 to Qt4.
> 
> We also understand that there is still a lot of software still using Qt4.
> 
> Don't forget to take a look at the C++ API changes page [apichanges]
> whenever you start porting your application.
> 
> [migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
> [apichanges] http://doc.qt.io/qt-5/sourcebreaks.html
> 
> For any questions and issues, do not hesitate to contact the Debian Qt/KDE
> team at debian-qt-...@lists.debian.org
> 
> The removal is being tracked in 
> 
> Lisandro,
> on behalf of the Qt4 maintainers

Bug#874888: Patch

[Sune Vuorela]

With these patches, things build and seems to work. Have fun.

/Sunediff -Nru fraqtive-0.4.8/debian/changelog fraqtive-0.4.8/debian/changelog
--- fraqtive-0.4.8/debian/changelog	2018-03-15 14:34:14.0 +0100
+++ fraqtive-0.4.8/debian/changelog	2018-08-15 11:34:18.0 +0200
@@ -1,3 +1,10 @@
+fraqtive (0.4.8-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Qt5
+
+ -- Sune Vuorela   Wed, 15 Aug 2018 11:34:18 +0200
+
 fraqtive (0.4.8-6) unstable; urgency=medium
 
   * Set a save URL in the homepage field.
diff -Nru fraqtive-0.4.8/debian/control fraqtive-0.4.8/debian/control
--- fraqtive-0.4.8/debian/control	2018-03-15 14:34:14.0 +0100
+++ fraqtive-0.4.8/debian/control	2018-08-15 10:58:36.0 +0200
@@ -17,8 +17,7 @@
  libglu1-mesa-dev,
  libgl1-mesa-dev,
  libpcre3-dev,
- libqt4-dev,
- libqt4-opengl-dev
+ qtbase5-dev
 Standards-Version: 4.1.3
 
 Package: fraqtive
diff -Nru fraqtive-0.4.8/debian/patches/fixinludes fraqtive-0.4.8/debian/patches/fixinludes
--- fraqtive-0.4.8/debian/patches/fixinludes	1970-01-01 01:00:00.0 +0100
+++ fraqtive-0.4.8/debian/patches/fixinludes	2018-08-15 11:34:18.0 +0200
@@ -0,0 +1,29 @@
+Description: Add missing includes
+ Qt5 has had a bit of includes cleanups. Apply those.
+Author: Sune Vuorela 
+
+---
+Origin: other
+Forwarded: no
+Last-Update: 2018-08-15
+
+--- fraqtive-0.4.8.orig/src/configurationdata.cpp
 fraqtive-0.4.8/src/configurationdata.cpp
+@@ -27,6 +27,7 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ ConfigurationData::ConfigurationData()
+ {
+--- fraqtive-0.4.8.orig/src/fractalgenerator.h
 fraqtive-0.4.8/src/fractalgenerator.h
+@@ -22,6 +22,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "abstractjobprovider.h"
+ #include "datastructures.h"
diff -Nru fraqtive-0.4.8/debian/patches/series fraqtive-0.4.8/debian/patches/series
--- fraqtive-0.4.8/debian/patches/series	2018-03-15 14:34:14.0 +0100
+++ fraqtive-0.4.8/debian/patches/series	2018-08-15 11:27:50.0 +0200
@@ -1,2 +1,4 @@
 01-desktop-keywords.diff
 02-spelling-error.diff
+Use-Qt5
+fixinludes
diff -Nru fraqtive-0.4.8/debian/patches/Use-Qt5 fraqtive-0.4.8/debian/patches/Use-Qt5
--- fraqtive-0.4.8/debian/patches/Use-Qt5	1970-01-01 01:00:00.0 +0100
+++ fraqtive-0.4.8/debian/patches/Use-Qt5	2018-08-15 11:34:18.0 +0200
@@ -0,0 +1,18 @@
+Description: Fix bulid system to use Qt5 instead of Qt4
+Author: Sune Vuorela 
+
+---
+Origin: other
+Last-Update: 2018-08-15
+
+--- fraqtive-0.4.8.orig/configure
 fraqtive-0.4.8/configure
+@@ -81,7 +81,7 @@ for i in $paths; do
+   if test "$version" != "**Unknown**"; then
+ major=`echo $version | sed -e "s/\([0-9][0-9]*\).*/\1/"`
+ minor=`echo $version | sed -e "s/[0-9][0-9]*\.\([0-9][0-9]*\).*/\1/"`
+-if test $major -eq 4 -a $minor -ge 3; then
++if test $major -eq 5 -a $minor -ge 3; then
+   QMAKE=$i
+   break
+ fi

Bug#905659: psi-plus FTBFS: cannot find -lsecret-1

[Sune Vuorela]

reassign -1 qt5keychain-dev
thank you

After a quick investigation, the issue seems to be the cmake configuration 
files in qt5keychain-dev:

$ grep -i secret /usr/lib/x86_64-linux-gnu/cmake/Qt5Keychain/*
/usr/lib/x86_64-linux-gnu/cmake/Qt5Keychain/Qt5KeychainLibraryDepends-
debian.cmake:  IMPORTED_LINK_INTERFACE_LIBRARIES_DEBIAN 
"Qt5::Core;secret-1;gio-2.0;gobject-2.0;glib-2.0;Qt5::DBus"

which basically tells users that "whenever you link Qt5Keychain, you should 
also link these...".

Given that Qt5Keychain seems to only expose QtCore types on the api, all the 
others seems to not be needed and should be removed.

The fix is probably that QtKeychain always link everything PUBLIC in 
target_link_libraries in CMakeLists.txt.

The CMakeLists.txt in general could need a bit of modern cmake love.

/Sune

On Tuesday, August 7, 2018 9:51:42 PM CEST Helmut Grohne wrote:
> Source: psi-plus
> Version: 1.3.384-1
> Severity: serious
> Tags: ftbfs
> 
> psi-plus fails to build from source in unstable on amd64. A build ends
> 
> with:
> | /usr/bin/c++  -g -O2 -fdebug-prefix-map=/<>=.
> | -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> | -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -Wall
> | -Wextra  -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -rdynamic
> | CMakeFiles/psi-plus.dir/accountmanagedlg.cpp.o
> | CMakeFiles/psi-plus.dir/actionlist.cpp.o
> | CMakeFiles/psi-plus.dir/activecontactsmenu.cpp.o
> | CMakeFiles/psi-plus.dir/ahcommanddlg.cpp.o
> | CMakeFiles/psi-plus.dir/ahcservermanager.cpp.o
> | CMakeFiles/psi-plus.dir/alerticon.cpp.o
> | CMakeFiles/psi-plus.dir/avatars.cpp.o
> | CMakeFiles/psi-plus.dir/contactlistaccountmenu.cpp.o
> | CMakeFiles/psi-plus.dir/discodlg.cpp.o
> | CMakeFiles/psi-plus.dir/eventdlg.cpp.o
> | CMakeFiles/psi-plus.dir/filetransdlg.cpp.o
> | CMakeFiles/psi-plus.dir/gcuserview.cpp.o
> | CMakeFiles/psi-plus.dir/groupchatdlg.cpp.o
> | CMakeFiles/psi-plus.dir/htmltextcontroller.cpp.o
> | CMakeFiles/psi-plus.dir/httpauthmanager.cpp.o
> | CMakeFiles/psi-plus.dir/mainwin_p.cpp.o
> | CMakeFiles/psi-plus.dir/msgmle.cpp.o CMakeFiles/psi-plus.dir/proxy.cpp.o
> | CMakeFiles/psi-plus.dir/psiaccount.cpp.o
> | CMakeFiles/psi-plus.dir/psiactionlist.cpp.o
> | CMakeFiles/psi-plus.dir/psichatdlg.cpp.o
> | CMakeFiles/psi-plus.dir/psicon.cpp.o
> | CMakeFiles/psi-plus.dir/psicontactlistview.cpp.o
> | CMakeFiles/psi-plus.dir/psievent.cpp.o
> | CMakeFiles/psi-plus.dir/psioptionseditor.cpp.o
> | CMakeFiles/psi-plus.dir/psipopup.cpp.o
> | CMakeFiles/psi-plus.dir/psirosterwidget.cpp.o
> | CMakeFiles/psi-plus.dir/registrationdlg.cpp.o
> | CMakeFiles/psi-plus.dir/searchdlg.cpp.o
> | CMakeFiles/psi-plus.dir/xdata_widget.cpp.o
> | CMakeFiles/psi-plus.dir/dbus.cpp.o
> | CMakeFiles/psi-plus.dir/chatview_te.cpp.o
> | CMakeFiles/psi-plus.dir/moc_aboutdlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_abstracttreemodel.cpp.o
> | CMakeFiles/psi-plus.dir/moc_accountadddlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_accountlabel.cpp.o
> | CMakeFiles/psi-plus.dir/moc_accountmanagedlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_accountmodifydlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_accountregdlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_accountscombobox.cpp.o
> | CMakeFiles/psi-plus.dir/moc_accountstatusmenu.cpp.o
> | CMakeFiles/psi-plus.dir/moc_actionlist.cpp.o
> | CMakeFiles/psi-plus.dir/moc_activecontactsmenu.cpp.o
> | CMakeFiles/psi-plus.dir/moc_activeprofiles.cpp.o
> | CMakeFiles/psi-plus.dir/moc_activitydlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_adduserdlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_ahcformdlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_ahcommanddlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_alertable.cpp.o
> | CMakeFiles/psi-plus.dir/moc_alerticon.cpp.o
> | CMakeFiles/psi-plus.dir/moc_alertmanager.cpp.o
> | CMakeFiles/psi-plus.dir/moc_avatars.cpp.o
> | CMakeFiles/psi-plus.dir/moc_bobfilecache.cpp.o
> | CMakeFiles/psi-plus.dir/moc_bookmarkmanagedlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_bookmarkmanager.cpp.o
> | CMakeFiles/psi-plus.dir/moc_bosskey.cpp.o
> | CMakeFiles/psi-plus.dir/moc_bytearrayreply.cpp.o
> | CMakeFiles/psi-plus.dir/moc_captchadlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_changepwdlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_chatdlg.cpp.o
> | CMakeFiles/psi-plus.dir/moc_chateditproxy.cpp.o
> | CMakeFiles/psi-plus.dir/moc_chatsplitter.cpp.o
> | CMakeFiles/psi-plus.dir/moc_coloropt.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistaccountmenu.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistdragmodel.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistdragview.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistgroupmenu.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistgroupmenu_p.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistitemmenu.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistmodel.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistmodel_p.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistmodelselection.cpp.o
> | CMakeFiles/psi-plus.dir/moc_contactlistproxymodel.cpp.o
> | 

Bug#904688: qttools-opensource-src: FTBFS: please drop the libclang-dev B-D on some architectures

[Sune Vuorela]

On Tuesday, July 31, 2018 8:48:42 PM CEST John Paul Adrian Glaubitz wrote:
> It's still a bad practice, in my personal opinion, because it adds
> redundancy.

It is kind of - from an upstream POV - what kind of situation you optimize 
for. 

 - embedding the resources in the executable or library  might add redundancy 
if someone distributes several versions, but disk space is cheap in these 
sizes.
 - not embedding the resources on some platforms gives different code paths. 
Code paths are quite expensive from a testing POV.
 - not embedding the resources on all platforms gives quite bigger deployment 
issues on some platforms. (windows, mac, some mobile targets)
 - embedding resources make the resources harder to hack/modify on disk. Some 
think it is an advantage. Others a disadvantage.
 - on some platforms, embedding resources gives faster startup and resource 
access. (Especially windows)

So embedding resources if you target cross platformness, and your resources 
aren't too big and not actually shared with others often the easiest and 
cheapest way forward. It costs mirroring linux distributions a slight disk 
overhead, but I don't think that is too big of a problem.

But, more and more are going to need libclang. Given libclang is mostly a c++ 
parser, I don't see why it shouldn't be buildable on most platforms ? Can't 
the compiler bits be stripped from the llvm source package on some archs?

/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

Bug#894476: #894476: Solved from the Qt side. (rcc: please honour SOURCE_DATE_EPOCH)

[Sune Vuorela]

On Wednesday, July 11, 2018 10:08:23 PM CEST Vagrant Cascadian wrote:

> Ideally QT_RCC_SOURCE_DATE_OVERRIDE would get set based on
> SOURCE_DATE_EPOCH, otherwise build tools have an arbitrary growing

No. As explained, we need to look at each individual package to check if the 
timestamp is actually used for anything. It can be. It probably is. 

I think a better fix might be to specifically mark in the rcc file if the 
dates are important or not. But it requires involvement upstream. (Or maybe if 
the rcc file is autogenerated or not). I don't think it is a problem for non-
autogenerated rcc files.

/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

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Sune Vuorela]

On Tuesday, April 3, 2018 9:24:58 PM CEST Chris Lamb wrote:
> I'm not /entirely/ sure what the difference is as I'm not in the
> Qt/RCC world too often these days (alas !), but why just not use
> SOURCE_DATE_EPOCH *iff* it is exported?
> 
> Normal systems simply do not have this envvar set, so there is really
> no danger of it leaking elsewhere or causing unintended side-effects.

We don't know how application users are using this.

The following is some theoretical example, that I'm quite sure could be used 
in some real world applications:

QFileInfo embeddedFile(":/foo/data.xml"); // fallback downloaded in the 
ancient past
QFileInfo systemfile("/usr/share/foo/data.xml");

if (systemfile.lastModified() > embeddedFile.lastModified())
{
   data = readFromFile(systemFile);
}
else
{
   data = readFromFile(embeddedFile);
}

If S_D_E gets used, rather than the data.xml modified date in the source, this 
will end up using the wrong file if S_D_E is newer than the system copy of the 
file.

This is not a unused databit, but a fully available piece of metadata for the 
files.

/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

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Sune Vuorela]

On Tuesday, April 3, 2018 9:14:23 PM CEST Chris Lamb wrote:
> Hi Sune!
> 
> > I don't think honouring SOURCE_DATE_EPOCH is the right idea under normal
> > circumstances
> 
> Can you elaborate on what you mean by "normal circumstances"? :)

"normal circumstances" is rcc on a source file, as opposed to an autogenerated 
file.

> How about e use S_D_E if it is setup/exported, otherwise use the mtime
> of the file as before?

I think that using S_D_E only makes sense if rcc is run on an autogenerated 
file, but I do think that most rcc runs is run on existing source files.


I don't have a good idea to differentiate those.

/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

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Sune Vuorela]

On Tuesday, April 3, 2018 8:46:51 PM CEST Thomas Preud'homme wrote:
> The problematic files are Qt message files (ie .qm files) generated at build
> time via lrelease from translation files (ie .ts files). Therefore two

Right. I didn't think about autogenerated files during build.

> I think it would be nice if there was a way for
> rcc to avoid doing that manually. I agree with Chris that honouring
> SOURCE_DATE_EPOCH in rcc would be a nice solution.

I don't think honouring SOURCE_DATE_EPOCH is the right idea under normal 
circumstances, given that I do think that having the actual timestamp of the 
non-generated files makes sense.

I have reached out to upstream about it.

/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

Bug#894476: RCC: provide option to encode EPOCH timestamp

[Sune Vuorela]

On Saturday, March 31, 2018 12:05:02 PM CEST Chris Lamb wrote:
> > While investigating ultracopier's lack of build reproducibility, I found
> > out that rcc encodes the timestamp of the files the QRC file being
> > compiled references

I don't actually see why this should be a problem. If input changes, output 
changes.
I do think that using touch(1) on the input should allow different output.

It is quite easy to reproduce:

qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version 2 ../
qimage.qrc -o 1
qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version 2 ../
qimage.qrc -o 2
qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version 2 ../
qimage.qrc -o 3

Gives same output.
Even adding in touch ../qimage.qrc keeps the same output.

qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version 2 ../
qimage.qrc -o 4

touch ../images/image.bmp

qtbase/tests/auto/gui/image/qimage/foo (dev $%=)$ rcc --format-version 2 ../
qimage.qrc -o 5

is needed to get different output

14ef6dae8e4992ce907948c1c4af272b  1
14ef6dae8e4992ce907948c1c4af272b  2
14ef6dae8e4992ce907948c1c4af272b  3
14ef6dae8e4992ce907948c1c4af272b  4
54c6f8c09a347955ae2f36e68bbd2539  5


So. What touches the files?

/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

Bug#818875: konqueror: green SSL checkbox despite expired server certificate

[Sune Vuorela]

severity 818875 normal
thanks

On Sunday, January 15, 2017 11:30:35 PM CET Lisandro Damián Nicanor Pérez 
Meyer wrote:
> > > See attached screenshot – konqueror does not error out when the
> > > certificate is expired and even shows a green checkbox. (I may
> > > or may not have ACK’d the certificate in an earlier session, I
> > > don’t know right now, but showing a green checkbox is still
> > > wrong.)
> > 
> > https://expired.identrustssl.com/ is an online example to test that
> > use-case, which I can reproduce.

Konqueror does error out.  See attachment.  You then get a chance of aborting, 
or continuing.
Continuing then gives you the choice of "this session" or "forever".  If you 
select forever, you get that. I don't see a problem with marking a certificate 
as trusted if the user explicitly have asked for it.

My system is a debian unstable updated this year

/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

Bug#840652: any status on this?

[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

Bug#832748: ITP: greatcmakecookoff -- Usefull and less than usefull cmake recipes

[Sune Vuorela]

On Thursday 28 July 2016 20:57:30 Ole Streicher wrote:
> Hi Sune,

> However, it is not just "works-for-me", since it is used in a different
> place from where it was developed, so the code found its friends
> (unfortunately).

And it might even find more friends if available in debian.

And then more users. and then all the bugs starts to show up, some likely 
requires api changes to fix. Then a lot of build failures and ...

> If I can't remove it, I in principle have two choices here: either I
> include it in each package; this would however violate the policy §4.13.
> Or I package it separately, then I am close to the "must not be so buggy
> that we refuse to support them" requirement in §2.2.1.

I do think that code duplication and keeping it private would be preferred in 
this case over packaging it separately.

Which parts is actually used ?

And the ones that are used to download an internet as part of the build needs 
to be fixed/changed/replaced anyways.


 
> If you (or someone else) could volunteer to help me in removing this
> dependency, I would be glad, and would withdraw the ITP.

I'm at least not volunteering to help to do anything with non-public sources.


/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

Bug#832748: ITP: greatcmakecookoff -- Usefull and less than usefull cmake recipes

[Sune Vuorela]

On Thursday 28 July 2016 15:33:55 Ole Streicher wrote:

>   URL : https://github.com/UCL/GreatCMakeCookOff/wiki
>   Description : Bunch of CMake pain in the baker
> This is a repository of useful and less than useful CMake recipes.

After reading it thru, I would really like to question the inclusion into the 
archive. 

It seems like undertested, fragile works-for-me-and-probably-no-one-else cmake 
code.

There is a couple of find modules that might be interesting, but I would 
really suggest to get those upstreamed into either cmake or extra-cmake-
modules and the rest of the hacks should preferably not be used.

I took a look at sopt and purify upstreams, and couldn't find that they used 
cmake at all?

/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

Bug#831730: desktop-base: Integration with KDE's plasma-desktop seems to no longer work with current version

[Sune Vuorela]

On Monday 18 July 2016 21:43:58 Raphaël Hertzog wrote:
> When you install KDE on a fresh system, the default wallpaper that you get
Plasma
> is not the one provided by desktop-base. So it looks like that the
> integration provided by
> /usr/share/kde4/apps/plasma-desktop/init/10-desktop-base.js is no longer
> working as expected and might need an update to work with the version of
> KDE currently in testing/unstable.
Plasma
> 
> $ cat kde-wallpaper/10-desktop-base.js
> // Placed in /usr/share/kde4/apps/plasma-desktop/init/

yeah. that looks kind of old.

> (This has been identified on a Kali Linux system but I have all the
> reasons to believe that it also applies to a Debian testing system)

Without having investigated a single thing, I also have all the reasons to 
believe it doesn't work in a current Debian testing/unstable Plasma 
installation.

/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

Bug#808781: musescore: Please remove unneeded build depends

[Sune Vuorela]

Source: musescore
Version: 2.0.2+dfsg-2
Severity: important

Dear Maintainer,

The package seems to be build-depending on qtquick1-5-dev, which is soon
going away.
I couldn't find any traces of QtQuick1 inside the application, so it is
likely an oversight from the past. Please remove the build-dep.

If I'm wrong, please speak up and I'll be happy to help.

/Sune

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

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

Bug#808780: wkhtmltopdf: Unneeded build-dep on qtquick1-5-dev

[Sune Vuorela]

Source: wkhtmltopdf
Version: 0.12.2.4-1
Severity: important

Dear Maintainer,

It looks like there is a unneeded build-dep on qtquick1-5-dev (I can't
find any traces of it in the actual sources). 

QtQuick1 for qt5 is going away soon (superceded quite some time ago by
QtQuick2)

If any help is needed, feel free to speak up.

/Sune


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

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

Bug#808698: [Debian-astro-maintainers] Bug#808698: stellarium: Please move away from qtquick1

[Sune Vuorela]

On Tuesday 22 December 2015 12:57:41 Tomasz Buchert wrote:
> Hi Alexander,
> thank you for fast response.
> @Sune: expect an upload soon!

That was amazingly fast

Thanks

/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

Bug#808697: kadu: Uses qtquick1 which is going away

[Sune Vuorela]

Source: kadu
Version: 2.1-2
Severity: important

Dear Maintainer,

QtQuick1 is going away real soon. Please migrate to QtQuick2. If you
need help, feel free to ask, including providing guidance on how to use
the current qtquick1 thing in kadu.

/Sune

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

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

Bug#808698: stellarium: Please move away from qtquick1

[Sune Vuorela]

Source: stellarium
Version: 0.14.1-1
Severity: important

Dear Maintainer,

Hi

QtQuick1 is going away real soon now. I can't figure out how stellarium
is actually using it, except if it is not. I can only find references in
debian/control

Once removing those, it looks like stellarium still builds. Unless I
missed something, please upload a stellarium without the qtquick1
references.

If I missed something, feel free to ask for help.

/Sune

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

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

Bug#792594: libqt5qml5 requires SSE2 on i386

[Sune Vuorela]

On Saturday 10 October 2015 15:21:19 Guillem Jover wrote:
> > [cla] 
> 
> I've read the CLA, and I don't think I can agree with point §3.1 which
> states:
> 
> «… under license terms of The Qt Company’s choosing including any Open
> Source Software license.»
> 
> Which to me implies an unfair advantage towards “The Qt Company” as


Hi Guillem and others reading along at home.

I fully understand your take against CLA's, and I kind of agree. What still 
made me sign the Qt Project CLA is the fact that there is also the slightly 
less advertised KDE Free Qt Foundation agreement between Trolltech/Nokia/Digia 
and KDE on the other side:

https://www.kde.org/community/whatiskde/kdefreeqtfoundation.php

 - in case Trolltech/Nokia/Digia/... stop developing open source Qt for X11 or 
successors of X11, KDE Free Qt Foundation gets the Qt sources under a specific 
BSD license. (The android code is also under this agreement)

The Qt Company (A Digia subcompany) does also sell commercial licenses of Qt 
to people who can't or won't live up to the lgpl/gpl requirements, and is how 
The Qt Company keeps the 100+ people working on and around Qt.

/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

Bug#797980: kdevelop: Missing .so file in kdevelop.install

[Sune Vuorela]

Hi

Can you submit the patch upstream on reviewboard to get them to take a look at 
it?

Patches in bugzilla is often missed.

Thanks,

/Sune

On Saturday 26 September 2015 18:43:18 Zhang Jingqiang wrote:
> Hello,
> there is another patch needed to avoid the reference usage crash
> 
> > I submit a bug report today to solve the last one:
> > https://bugs.kde.org/show_bug.cgi?id=352618
> > 
> > Now kdevelop don't crash and KDevDefinesAndIncludesManager works.
> 
> And this bug report could be closed.

-- 
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

Bug#798523: ITP: cen64-qt -- cen64-qt: Cross-platform graphical frontend for the CEN64 emulator.

[Sune Vuorela]

On Thursday 10 September 2015 10:58:29 John Paul Adrian Glaubitz wrote:
> Package: wnpp
> Severity: wishlist
> Owner: John Paul Adrian Glaubitz 
> 
> * Package name: cen64-qt
>   Version : 0.0+gitMMDD
>   Upstream Author : Dan Hasting 
> * URL : https://github.com/dh4/cen64-qt
> * License : BSD-3-clause
>   Programming Lang: C++
>   Description : cen64-qt: Cross-platform graphical frontend for the
> CEN64 emulator.

Hi

Please ensure that you build it with Qt5 and not Qt4 (which we try to slowly 
retire)

Thanks,
/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

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sune Vuorela]

On Friday 28 August 2015 19:58:02 Matthew Vernon wrote:

 That's not much comfort to folk like me who use the trad menu (I'm an
 FVWM user) - you're proposing getting rid of something that currently
 works, and leaving nothing to replace it with.

https://wiki.archlinux.org/index.php/Xdg-menu

There. something to replace it with.

/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

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sune Vuorela]

On Thursday 27 August 2015 18:11:56 Ian Jackson wrote:
 So the real dispute is: should the existing application metadata
 database (currently represented by the Debian trad menu files in
 existing packages):
 
  (a) continue to be maintained in its existing file format
 
  (b) be translated to a new and more modern file format
  (perhaps only for some packages)
 
  (c) be destroyed.
 
 Given that there are people who want to maintain it, I think (c) is
 unacceptable.[1]

Unfortunately, the people who wants to maintain it are not the same people who 
has to carry the maintenance work (shipping, checking, fixing and managing the 
menu files across the packages of the distribution, which is why a) is 
unacceptable.
I haven't seen anyone interested in working on tooling[1] to accomplish b) 
which leaves just c) as a possibility.

Personally, I'd rather throw away work made by people in the past, than having 
people in the current and in the future keep wasting time.

/Sune

[1] Except the desktop2menu tool that I wrote eons ago that creates a good 
starting point for creating a menu file, but needs quite some work to be used 
on a automatic archive wide scale. I'd also suggest people to start off from 
Arch's xdg-menu that has been linked multiple times as a starting ground to 
build a menu for the window managers targetting advanced users.

-- 
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

Bug#741573: Proposed draft of ballot to resolve menu/desktop question

[Sune Vuorela]

On Wednesday 19 August 2015 10:57:43 Sam Hartman wrote:
  Don == Don Armstrong d...@debian.org writes:
  While we're not overturning anything in the sense of an override
  here, I think we owe an explanation for our actions, and I feel
  really strongly about that.
 
 Don Ideally the patch and its rationale should stand alone without
 Don the need for a separate text. But that said, if you disagree
 Don that the rationale is not sufficient once it exists, I'll
 Don either try to modify it or draft a separate text.
 
 No, a rationale that explains why option D is better than A/B is all I'm
 asking for.

From my technical POV I think Option D is better than A/B because it is a more 
clear technical solution, and saying there is one menu to care about

The current A/B thing ended up as a standard compromise that tries to leave 
everyone equally unhappy, and ending everyone having to decide for them selves 
which menus to cater for.

I don't think A/B is a particular good solution but is immensely better than 
doing nothing. Option D is what I was hoping for we would end up with in some 
years after letting the debian menu bitrot for another couple of years.

In option D4, I'd though like if Debian Desktop or similar was involved, as 
it is likely the debian desktop maintainers (XFCE, Plasma, Gnome, LX(DE|Qt), 
..) who are closest to the users in this regard.

From my social POV I'd love to see B win because I really think that there was 
a good enough consensus to be able to move on with issues like that. If we 
hadn't had the double-role of menu maintainer and policy editor, I'm pretty 
sure we wouldn't have gotten here in the first place.

But as Debian is a technical project consisting of social individuals, I would 
hope to see DBAZC as the final result.

/Sune
 - the one who initiated this mess

Bug#796032: kwindowsystem: Strange behavior of lxqt-runner and lxqt-panel, may be related to #795884

[Sune Vuorela]

On Tuesday 18 August 2015 19:23:08 Alf Gaida wrote:
 Dear Maintainer,
 after upgrading to latest kwindowsystem lxqt-panel and lxqt-runner behave
 strange, the attached patch fixed this. Please note that amd64 will work
 without further changes, i386 will FTBFS because of symbol changes. I'm not
 familar with the kde symbols system so i leave it up to you.

The patch here puts the plugins in the -dev package which is definitely wrong. 
IIRC upstream (mgraesslin) had an opinion on how the plugins should be 
shipped. CC'ing him for his input.

(full report including patch is on http://bugs.debian.org/796032 - and 
replying to the bug email address is available for everyone)

/Sune

Bug#741573: #741573: Menu Policy and Consensus

[Sune Vuorela]

On Monday 20 July 2015 17:14:03 Josselin Mouette wrote:
 Bill used his position as a policy editor to reject a change, not
 because it was against consensus or against the policy process, but
 because it was against his own opinion. Not as policy editor, but as
 menu maintainer.
 
 This is the root of the problem. By asking whether the policy process
 has been respected, you are reversing the responsibility. It was Bill’s
 responsibility from day one to recuse himself from policy decisions on
 the menu.
 It was also Bill’s responsibility, from day one, to raise his own
 concerns to the policy change being discussed, not to rely on other
 people’s nitpicks *after* the new policy had been approved and
 committed.
 
 Maybe, after all, this issue should not have been sent to the TC but to
 the DPL, to ask for the revocation of the abused delegation.

Seconded.

The debian menu is de facto dead; it is time to put it out of its misery.

/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


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

Bug#787689: Fix upstream

[Sune Vuorela]

Hi

http://patchwork.openembedded.org/patch/92055/ seems to point to a upstream 
fix:

https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=212178

/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


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

Bug#786715: stellarium: Uses private copies of external headers

[Sune Vuorela]

On Tuesday 02 June 2015 10:07:30 Thibaut Paumard wrote:

 Quoting: https://www.debian.org/Bugs/Developer.en.html#severities
 
 serious
 is a severe violation of Debian policy (roughly, it violates a
 must or required directive), or, in the package maintainer's or
 release manager's opinion, makes the package unsuitable for release.
 
 In this instance, I fail to see which section of the Policy is being
 violated.

I'm maintainer of Qt. that should be sufficient. This issue makes it 
approximately 25% more work every time we introduce a new Qt version to the 
archive, because it relies on Qt *internals*, and packages that does that just 
requires more work for the Qt maintainers on each new update. And there is no 
reason for stellarium to actually give the Qt maintainers that extra work.

So please, pretty please, let's get it fixed fast.

/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


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

Bug#786715: stellarium: Uses private copies of external headers

[Sune Vuorela]

On Monday 01 June 2015 16:21:59 Thibaut Paumard wrote:
 Le 24/05/2015 20:46, Sune Vuorela a écrit :
  Source: stellarium
  Version: 0.13.3-1
  Severity: serious
 
 Hi,
 
 I think the severity of this bug is overstated. There is no reason why
 this should warrant removing stellarium from testing.

It is fragile and broken and just waiting to fall apart.

 Upstream is working on the issue, I suggest downgrading the severity to
 normal or important at most.

3) in my case would have been 'normal' or 'important', but the fact that it 
uses *its own* copy of headers and the actual symbols from Qt is just broken.
Had it at least used it's own copy of qzip.cpp,  we could have started a 
discussion, but this isn't the case. (src/CMakeLists.txt in the archive 
contains IF(!WIN32), and given it is more or less nonsense from a cmake pov, 
it just evaluates to false. IF(NOT WIN32) would likely have given closer to 
expected behaviour )

/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


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

Bug#786715: stellarium: Uses private copies of external headers

[Sune Vuorela]

On Monday 25 May 2015 14:14:53 Tomasz Buchert wrote:
 Hi,
 thanks for the report. The upstream is already looking at this.

Great. My suggestion would be to go for KArchive on this.

 I'll also mention a relevant bug: https://bugreports.qt.io/browse/QTBUG-3897

Yeah. That's kind of what my option 4) describes. Likely not going to happen. 
The QZip classes is just good enough for what Qt internally needs, and there 
are better external options available. (KArchive, quazip, probably others)

/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


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

Bug#786715: stellarium: Uses private copies of external headers

[Sune Vuorela]

Source: stellarium
Version: 0.13.3-1
Severity: serious

Dear Maintainer,

Stellarium has a copy of qzipreader/writer header files taken out of Qt,
and uses the internal, but unfortuantely available, symbols out of Qt
Gui. It can be directly seen due to the dependency on the internal qt
versioning as in qtbase-abi-5-3-2 which is generally a sign of doing
something dirty, and will require a rebuild on each new Qt upload.

If the QZipReader/writer classes changes (they can do that, they are an
internal thing to Qt), stellarium will not work or maybe even crash
randomly.

I'd suggest one of the following solutions:

1) Use an actual public zipping library. KArchive and quazip are two
currently available in Debian

2) Copy out the relevant bits from Qt *and rename* them (like add a
namespace or something).  (The current qzip.cpp found in the external
directory could be used, but needs to actually be built. Hint: ! is not
a valid negation operator in cmake)

3) much discouraged, but still better than status quo. Use the privately
exposed headers in qtbase5-private-dev of qzipreader_p.h and
qzipwriter_p.h to at least ensure that things are in sync. This also
requires changes to the build system.

4) convince Qt upstream to make QZip* public api. That's likely not
going to happen, and even if it was, we would need a interrim solution.

Getting something going soon would be nice to detangle stellarium from
the next qt upload. And 3) doesn't solve that.

I do somewhere have a quick and dirty patch for 2), but I really think
you should consider 1).

/Sune


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

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


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

Bug#785329: lintian: Add check for CMake private files

[Sune Vuorela]

On Friday 15 May 2015 23:53:36 Bastien ROUCARIES wrote: 
 But I find title misleading and description too short. Moreover you
 should add link to normative or documentation. Why it is bad for
 instance to carry cmake file here ?

The main practical reason why it is bad to carry a cmake file in e.g. 
/usr/share/cmake-3.0 is that when e.g. cmake 3.2 gets uploaded, it doesn't 
look there automatically any more.

The main conceptual reason is that installing files there is that it is like 
burying the treasure map together with the treasure.

FooConfig files have - since cmake 2.6 or something like that - been the 
preferred way for a shared component to tell cmake where it is installed.

/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


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

Bug#783293: browsers crash with 'illegal instruction' on i586

[Sune Vuorela]

tags 783293 +wontfix
thanks

On Saturday 25 April 2015 20:29:57 Bernhard Übelacker wrote:
 I tried as a workaround to build a libqtwebkit package with attached
 little modification (does disable JIT, like for other archs).
 With this the browser does not crash.
 
 Again unfortunately this packages have not distinct files for i586 and
 i686 like e.g. libav.
 Therefore would such a change affect every x86 user of this package.
 So this is also just a workaround.

I agree that just disabling the JITter is not an option. If someone improves 
the jitter, or making jitting optional for these architectures, we can look 
into it again. Until a patch shows up that does that, I'm going to mark this 
wontfix from the qt side of things.

/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


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

Bug#781743: unblock (pre-approval): kde-workspace/4:4.11.13-2.1

[Sune Vuorela]

On Thursday 02 April 2015 21:10:00 John Paul Adrian Glaubitz wrote:
 On 04/02/2015 04:26 PM, John Paul Adrian Glaubitz wrote:
  Attaching revision 2 of my debdiff.
 
 While reviewing my own patch, I noticed a typo in the change I made
 in the debian/rules file (overriden_command - overridden_command).
 
 I have fixed this now and made the changelog entry slightly more
 accurate. Attaching revision 3 of my patch.

I wouldn't mind a better systemd integration, but your patch seems half done.

You have lost the integration with the desktop-base package and the related 
theming.

Do you even get a valid kdm configuration by this patch in a new setup? 

the setup_config() function in the current init script is there for a reason.

/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


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

Bug#781743: unblock (pre-approval): kde-workspace/4:4.11.13-2.1

[Sune Vuorela]

On Monday 06 April 2015 20:29:27 John Paul Adrian Glaubitz wrote:

 I wasn't actually aware that there additional code in the sysvinit init
 script that would customize or even create a new kdmrc. The kdm package
 actually ships a kdmrc file, so I just added a few lines to make the
 package systemd-aware.

The shipped kdmrc file is invalid (on purpose) and needs preprocessing to 
actually work.

What is needed for testing things is:

new install with desktop-base installed: Debian lines theme should be used

New install without desktop-base installed: The upstream provided theme 
(elarun?) should be used

new install with desktop-base installed, and then removed: The upstream 
provided theme should be used.

new install with user configured theming. The user configured theme should be 
used

New install with another desktop theme provider than desktop-base installed: 
The selected theme should be used

Debian live with autologin should also be tested.

And then there is all the upgrading cases.

IT is not a small task, and that's part of the reason why it has been 
postponed so far.

I wouldn't mind taking a 'less' tested approach in another point in the Debian 
release cycle, but at this point, it needs really some testing and people 
looking at the code. Unfortunately, I'm not volunteering for that.

/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


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

Bug#773617: ITP: kcmsystemd -- A KDE Control Center module for systemd

[Sune Vuorela]

Hi Shawn

On Saturday 20 December 2014 13:55:42 Shawn Sörbom wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Shawn Sörbom sh...@sorbom.com
 
 * Package name: kcmsystemd

Looks interesting. 

Note though, that KDE Configuration modules are packaged as kde-config-foo, not 
as kcmfoo.

Also note that post-jessie, there is a plan to retire as much as the qt4 based 
codebase as possible.


/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


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

Bug#770098: Request for a debian-nordic mailing list

[Sune Vuorela]

On Wednesday 19 November 2014 13:36:53 Jonas Smedegaard wrote:
 Quoting Per Andersson (2014-11-18 22:32:44)
 
  Please create a debian-nordic mailing list, for the Nordic Debian
  Community.
 
 Seconded!

Thirded.

/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

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

Bug#767164: extra-cmake-modules: Should not be in Jessie

[Sune Vuorela]

Package: extra-cmake-modules
Severity: serious

e-c-m is not fully ready for jessie, and nothing should be using it, so
let's wait a bit with it.

/Sune

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

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


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

Bug#765829: installation-reports: selecting KDE task in early installer also pulls in gnome

[Sune Vuorela]

Package: installation-reports
Severity: important

Dear Maintainer,

I'm using 
901282f309d744832586223b7332526a debian-jessie-DI-b1-i386-netinst.iso
and in the boot menu, I choose alternate desktop  KDE.

When I some time later get to closer choose what I want to install, both
KDE and Gnome is marked with asterisks. 
I had expected to not have to deselect Gnome at a later point in the
installer.

/Sune


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

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


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

Bug#744006: Package: arora: Arora does not start due to a segmentation fault.

[Sune Vuorela]

severity 744006 important
thanks

On Sunday 12 October 2014 22:23:16 Patrick Häcker wrote:
  The following is the gdb output. As I found neither arora nor libqtgui
 
 debugging packages, it might not be that helpful, though.
 
 I forgot to append the stack trace. It's appended in this mail. What looks
 suspicious to me is that libQt5WebKit is calling libQt5Core which is
 indirectly calling libQtGui.so.4. This might be an unsupported mixture of Qt
 versions.

QtWebkit tries to load plugins from /usr/lib/mozilla/plugins where you seem to 
have a plugin installed that loads in libQtGui.so.4. And yes. that is not 
supported. I'm not fully sure how to workaround it, but the workaround likely 
needs to happen in qtwebkit and not in arora.

You can uninstall kpartsplugin for now as a local workaround

/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


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

Bug#744006: Package: arora: Arora does not start due to a segmentation fault.

[Sune Vuorela]

reassign -1 libqt5webkit5
tag -1 +patch
thanks

On Sunday 12 October 2014 22:23:16 Patrick Häcker wrote:
  The following is the gdb output. As I found neither arora nor libqtgui
 
 debugging packages, it might not be that helpful, though.
 
 I forgot to append the stack trace. It's appended in this mail. What looks
 suspicious to me is that libQt5WebKit is calling libQt5Core which is
 indirectly calling libQtGui.so.4. This might be an unsupported mixture of Qt
 versions.

Yep. Patch submitted upstream:
https://codereview.qt-project.org/#/c/96946/

Let's reassign this bug to qt5 qtwebkit

Lisandro: I think we should consider cherrypicking this patch, as it makes 
quite some systems crash.

/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


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

Bug#689230: virtuoso 7.1 to Debian proper [Was: Bug#689230: new version is needed!]

[Sune Vuorela]

On Wednesday 01 October 2014 13:07:13 Kjetil Kjernsmo wrote:
 Hi all!

 Alternatively, a more conservative approach is to upload 6.1.8 to unstable,
 and 7.1 to experimental. If no problems occurs with 6.1.8, it is likely that
 the assumption that exactly 6.1.6 is required is wrong, then 6.1.8 makes it
 to testing, and then 7.1 can be uploaded to unstable, and see if it makes
 the successful transition organically.

It is known that 6.1.7 does *not* work for KDE's purpose, and I haven't heard 
anything abouth 6.1.8 should have fixed the relevant issues, and it is also 
known that virtuoso's handling of compatibility has room for improvement.

I'd really prefer to leave the virtuoso 6.1 series at it's current version 
until jessie is out.

/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


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

Bug#763518: gdb --batch mode broken

[Sune Vuorela]

Package: gdb
Version: 7.8-1
Severity: important

Dear Maintainer,

Gdb in batch mode is broken (Upstream). Please don't push it to unstable
until it is fixed.

Upstream link:

https://sourceware.org/bugzilla/show_bug.cgi?id=17446

/Sune



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

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

Versions of packages gdb depends on:
ii  libc6 2.19-11
ii  libexpat1 2.1.0-6
ii  liblzma5  5.1.1alpha+20120614-2
ii  libncurses5   5.9+20140913-1
ii  libpython2.7  2.7.8-7
ii  libreadline6  6.3-8
ii  libtinfo5 5.9+20140913-1
ii  zlib1g1:1.2.8.dfsg-2

Versions of packages gdb recommends:
ii  gdbserver 7.7.1+dfsg-3
ii  libc6-dbg [libc-dbg]  2.19-11

Versions of packages gdb suggests:
pn  gdb-doc  none

-- no debconf information


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

Bug#757844: [akonadi-server] File system cache is inneficient: too many file per directory

[Sune Vuorela]

On Monday 11 August 2014 21:11:33 bastien ROUCARIES wrote:
 Package: akonadi-server
 Version: 1.12.1-1+b1
 Severity: important
 
 ~/.local/share/akonadi/file_db_data/ is completly inneficient and render the
 whole system slow.

What locate do you use? mlocate? slocate?

/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


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

Bug#759422: please follow upstream versionning scheme

[Sune Vuorela]

On Tuesday 26 August 2014 23:26:15 Antoine Beaupré wrote:
 Package: marble
 Version: 4:4.8.4-3
 Severity: wishlist
 
 In trying to determine the availability of features in the Debian
 version of marble, i have had some difficulty of mapping between the
 version number of this package (e.g. 4.8.4 in wheezy) with the version
 numbers documented upstream (e.g. http://marble.kde.org/history.php).
 
 It would be nice to follow the upstream version numbers. I understand
 that this package may be following the KDE version numbers, but i don't
 use KDE yet marble is still an interesting product for me...

We are following the version numbers that matches the tarballs we receive. 
There is no plans to change that.

So, I think 'wontfix' is the best solution for this.

/Sune


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

Bug#759494: transition: kdevplatform

[Sune Vuorela]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi

We would love to be able to ship jessie with a not one-year-old kdevelop
at freeze time. And a new one is just about to come out (packagers have
received tarballs for final testing)

A transition slot by middle/end september would be nice.

involved source packages are kdevelop and kdevelop-php

Ben file:

title = kdevplatform;
is_affected = .depends ~ kdevplatform7-libs | .depends ~ kdevplatform9-libs;
is_good = .depends ~ kdevplatform9-libs;
is_bad = .depends ~ kdevplatform7-libs;


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

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


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

Bug#756110: libqcustomplot-dev: Doesn't install on a system with qt4 set as default

[Sune Vuorela]

Source: libqcustomplot-dev
Version: 1.2.1-1
Severity: serious

Dear Maintainer,

Hi

This package doesn't install on a system that is configured to use Qt4
as default.

Please note that the qt5-default and qt4-default packages not are meant
to be depended on by other packages, but rather convenience packages for
end users.

Also note that similarily, you shouldn't build-dep on it, but rather
in your rules file select what Qt you want to use.

Thanks in advance
/Sune

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

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


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

Bug#756098: libqtwebkit4: please rebuild with GStreamer 1.0

[Sune Vuorela]

It is a (slow) work in progress, but in order to get it working, we need 
phonon, qtwebkit, qtgstreamer and maybe others to be uploaded at the same 
time.

Various components in the archive uses more than one of these components.

/Sune

On Saturday 26 July 2014 11:32:31 Martin-Éric Racine wrote:
 Package: libqtwebkit4
 Version: 2.2.1-7
 Severity: normal
 
 libqtwebkit4 is one of the last few packages left in Jessie that
 require the deprecated Gstreamer 0.10. Could it be either rebuilt
 using Gstreamer 1.0 or upgraded to a newer release that does?
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers testing
   APT policy: (1001, 'testing'), (1001, 'oldstable'), (101, 'stable')
 Architecture: i386 (i686)
 
 Kernel: Linux 3.14-1-686-pae (SMP w/1 CPU core)
 Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages libqtwebkit4 depends on:
 ii  libc62.19-7
 ii  libgcc1  1:4.9.1-1
 ii  libglib2.0-0 2.40.0-3
 ii  libgstreamer-plugins-base0.10-0  0.10.36-1.1
 ii  libgstreamer0.10-0   0.10.36-1.2
 ii  libqt4-network   4:4.8.6+dfsg-2
 ii  libqtcore4   4:4.8.6+dfsg-2
 ii  libqtgui44:4.8.6+dfsg-2
 ii  libsqlite3-0 3.8.5-2
 ii  libstdc++6   4.9.1-1
 ii  libx11-6 2:1.6.2-2
 ii  libxrender1  1:0.9.8-1
 ii  multiarch-support2.19-7
 
 libqtwebkit4 recommends no packages.
 
 libqtwebkit4 suggests no packages.
 
 -- no debconf information

-- 
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


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

Bug#756158: lintian: Please make an error if Depends or Build-Depends is qt5-default or qt4-default

[Sune Vuorela]

Package: lintian
Version: 2.5.24
Severity: wishlist

Dear Maintainer,

In the Qt/KDE team, we have provided a couple of 'user oriented'
configuration packages that sets the system up to have either qt4 or qt5
as the default Qt when invoking qmake and similar tools.

But these are end user oriented and should not be used for neither
package building nor other packages should depend on it.

A special exception to the above is that there might be some cases where
debian-qt-...@lists.debian.org might want to do it for 'chained'
configuration packages.

So, if you could add an Error for that.

If a suggested solution should be presented, likely the following:

build-dep qt4-default

Instead of Build-Depending on qt4-default, replace it with libqt4-dev,
and if your build system is qmake, please invoke qmake with the -qt4
first argument. If you use CMake, it should be picked up without further
changes.

build-dep on qt5-default

Instead of Build-Depending on qt5-default, replace it with qtbase5-dev,
and if your build system is qmake, please invoke qmake with the -qt5
first argument. If you use CMake, it should be picked up without further
changes.

dep on qtX default.

Depending on qtX-default is bad, because it forces a specific
configuration of the underlying system, a configuration that might not
be what the system owner actually wants, so please don't put it in your
Depends line


Thanks for your considerations

/Sune

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

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

Versions of packages lintian depends on:
ii  binutils   2.24.51.20140617-1
ii  bzip2  1.0.6-5
ii  diffstat   1.58-1
ii  file   1:5.19-1
ii  gettext0.18.3.2-2
ii  hardening-includes 2.5
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b1
ii  libarchive-zip-perl1.37-2
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.37-1
ii  libdpkg-perl   1.17.10
ii  libemail-valid-perl1.194-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-2
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.09-1
ii  libtimedate-perl   2.3000-2
ii  liburi-perl1.60-1
ii  man-db 2.6.7.1-1
ii  patchutils 0.3.3-1
ii  perl [libdigest-sha-perl]  5.18.2-4
ii  t1utils1.37-2

Versions of packages lintian recommends:
ii  libautodie-perl 2.25-1
ii  libperlio-gzip-perl 0.18-3
ii  perl-modules [libautodie-perl]  5.18.2-4

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.17.10
ii  libhtml-parser-perl3.71-1+b1
pn  libtext-template-perl  none
pn  libyaml-perl   none
ii  xz-utils   5.1.1alpha+20120614-2

-- no debconf information


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

Bug#755678: kdepim-runtime: /usr/bin/akonadi_kolabproxy_resource missing in package, breaking any setup with kolab integration

[Sune Vuorela]

On Tuesday 22 July 2014 12:35:46 Jan Binder wrote:
 After upgrading to the KDE 4.13 packages in experimental, all Akonadi
 resources based on Kolab
 silently stopped working.

This is the main reason why kdepim-runtime is still in experimental.

It needs a newer set of libkolab* packages which was just now uploaded to the 
archive.

So, it is known, will be fixed - and welcome to experimental.

/Sune


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

Bug#753898: RFS: Looking for sponsor for apg-gui

[Sune Vuorela]

On Saturday 05 July 2014 23:36:12 Tymon Radzik wrote:
 I have just uploaded to mentors my package - it is called apg-gui and is
 complex Graphical User Interface for Automated Password Generator. It
 supports all it functions. I have made it in C++ Qt. I think it should be
 put into Debian archive, because:

I think - after a quick browse over the upstream source code, that the project 
isn't yet ready to be shipped by Debian.

Some of the initial issues I noted in the first file I looked at:

|int n,m,sx,a;
|QString mode, exclude, salt;

These looks like they are treated as class members. Please make them class 
members rather than file local variables.
The variable names also is kind of ... brief.


|std::string Scores::exec(char* cmd) {
|FILE* pipe = popen(cmd, r);
|if (!pipe) return ERROR;
Using 'magic strings' instead of enums usually makes code harder to understand
|char buffer[128];
|std::string result = ;
|while(!feof(pipe)) {
|if(fgets(buffer, 128, pipe) != NULL)
|result += buffer;
|}
|pclose(pipe);
|return result;
|}
Try look into using QProcess instead of trying to do process handling by hand.


|ui-progressBar-setValue(5);
progressBar looks like a autogenerated value. Please use descriptive variable 
names.


|std::string wyniki = std::string(apg -q -n ) + std::to_string(n) +  -m 
|  + std::to_string(m) +  -x  + std::to_string(sx) +  -a  + 
|   std::to_string(a);
Instead of playing hard-to-read scrabble with the strings, try use some 
simpler substitution pattern, maybe even QString, since you have it handy and 
use it already.

But given this is to be passed on to a process handling tool, putting every 
component seperately in a QStringList and then handing it off to QProcess could 
improve the readability.

|if(exclude != ) wyniki+= -E  + exclude.toStdString();
Try use the empty/isEmpty function rather than comparing to the empty string.

|char *cstr = new char[wyniki.length() + 1];
|strcpy(cstr, wyniki.c_str());
Where is cstr free'd ?


| void Scores::on_pushButton_clicked()
what's the pushButton ?

| void Scores::on_pushButton_2_clicked()
What's pushButton_2

And the body of this function has all the same issues as mentioned in the 
ctor, including the unhandled memory. 

/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


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

Bug#730600: [Kolab-devel] [pkg-kolab] Bug#730600: Bug#730600: libkolab(xml): New upstream version available

[Sune Vuorela]

On Wednesday 02 July 2014 13:36:52 Sandro Knauß wrote:
 Hey,
 
 I have some comments/questions:
  1) libcalendaring-* doesn't have a single symbol in common with kdepimlibs
  *and* 
 why is that needed? all libs are named differently, have a different version
 and the headers will lay in /usr/include/calendaring/  -I don't see the
 point, why compile two times one with kdepimlibs and the other one with
 libcalendering is not enough?

To ensure that if something ends up loading libcalendaring into the kontact 
process that everything still works.


  2) there are two versions of libkolab(-xml) that doesn't conflict and
 that should be easy solvable with different install destinations.

All libs in Debian go to a shared install directory, /usr/lib (or 
/usr/lib/TRIPLET ), so different destinations are not good enough. That also 
implies different SONAME's for the libraries.

  3) these versions of libkolab(-xml) doesn't share symbols.
 
 Well actually, if the both versions have different symbols, than all
 applications has be updated to have the support for libcalendering.

What applications would have to use it interchangeable ? I'd expect the kolab 
server people to just use the libcalendaring versions, while the kontact users 
would use the kdepimlibs versions.  

 Why it should blow up, if there are two libs lying around with same symbols?
 The linking is done against a library and not against the symbols. Or do

I want to ensure that neither of us gets to debug weird crashes if both 
libraries are loaded into the same application.

/Sune


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

Bug#741573: Two menu systems

[Sune Vuorela]

On Monday 30 June 2014 23:23:53 Russ Allbery wrote:
 Isn't this the tool that Sune wrote and mentioned earlier in this bug as
 being incomplete and primarily useful for generating a template that
 requires subsequent work?

Correct.

The primary issue is that there isn't a 1:1 mapping between all categories. I 
don't exactly remember the exact categories, but an example could be that the 
debian menu format generally have a 'game' category, whereas the desktop file 
based spec has a hierarchy of game categories, where the top level should be 
empty.

by looking in the desktop2menu script in the giant mapping table for !WARN 
should show where the mapping can't be done, or there are no good actual 
match.

There is also, iirc, a couple of other oddities here and there that says I 
wouldn't want to use it in a automatic fashion.

I do think that arch's XdgMenu package is a much better approach for getting a 
xdg-based menu into various window managers, but it should really be 
maintained by someone in debian who has a use for it. (that will likely 
exclude Plasma users like me and Gnome users like Joss)

/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


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

Bug#751780: transition: libstdc++6 unordered_{map,set} ABI changes between GCC 4.8/4.9 in c++11 mode

[Sune Vuorela]

On Monday 16 June 2014 17:02:39 Matthias Klose wrote:
 is an ABI incompatible change in the unordered_{map,set} classes built in

   qtbase-opensource-src-gles 5.2.1+dfsg-1
 
 For those transitions should be considered.

I assume you mean qtbase-opensource-src - we don't have a -gles variant in 
debian.

qtbase-opensource-src references unordered_map in a test case, in some 
documentation/example code and in the embedded ANGLE convenience code copy 
(ANGLE is windows specific)

So, I don't think a transition should be considered here.

/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


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

Bug#689230: virtuoso 7.1 to Debian proper [Was: Bug#689230: new version is needed!]

[Sune Vuorela]

On Monday 16 June 2014 12:20:24 Yaroslav Halchenko wrote:
 Do you see any dependent packages present in Debian which require those
 binaries and would not be compatible somehow with 8.1?

The entire KDE stack needs the exact current version in the archive. And no, 
it is not compatible with something newer.

The fact that the KDE stack needs it is also why it is maintained by the KDE 
team.

/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


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

Bug#689230: virtuoso 7.1 to Debian proper [Was: Bug#689230: new version is needed!]

[Sune Vuorela]

On Monday 16 June 2014 12:43:25 Yaroslav Halchenko wrote:
 Great -- thanks Sune for the feedback.  It is just from previous
 comments I was not sure if KDE is still relying/using virtuoso.
 But if you state so -- must be so.

There is a move away from virtuoso - but the kde stack in stable uses virtuoso 
and if users should have a chance to migrate their data out, they need a kde 
stack that can communicate with it.

 Do you think it would be feasible to proceed for now with a
 versioned (e.g.  virtuoso-7) source package for virtuoso while excluding
 all the non-versioned meta- packages, thus providing recent virtuoso for
 those users who want it, while keeping KDE team and users happy?

If everytihng is properly versioned, I don't see a issue with providing an 
extra source package, and we could probably even strip down the kde-virtuoso 
source package from a lot of the 'generic components'. It is really just the 
odbc driver and the virtuoso executable that kde relies on. I think patches 
would be more than welcome.

 what components of KDE require virtuoso? (only napomuk?) and which
 tools/libraries in particular?

It is the nepomuk/soprano chain that requires it. and it is used by the 
activities system, by the file manager (dolphin), the image viewer (gwenview), 
the mail stack and probably some I forgotten. But everything is happening thru 
nepomuk and soprano.

oh. and the Debian Krap Team is for packages we don't really love but have to 
care for anyways.

/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


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

Bug#721283: [www.debian.org] Please mention Bytemark's donation

[Sune Vuorela]

On Thursday 08 May 2014 22:56:35 Bernd Zeimetz wrote:
 I object against adding new (and incomplete stuff) to a completely outdated
 page. We have a lot of people sponsoring hardware, parts, or monkey for
 hardware, including some who did never ever ask for a press release - or
 don't even want to have one and maybe don't want to be mentioned at all.

I'd like to point to an example in this debate:

http://kde.org/thanks.php  managed by  
http://ev.kde.org/rules/thankyou_policy.php

/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


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

Bug#741573: Two menu systems

[Sune Vuorela]

On Thursday 10 April 2014 14:06:11 Ian Jackson wrote:
 Has anyone described any actual difficulties with supporting the
 traditional menu ?

I am in the uploaders field of packages that probably requires 300 menu files 
to 
be available and of one consumer of menus.

if it takes 5 minutes to write a menu file and 5 minutes to switch to one of 
those 'old style' window managers and test that it shows up as it should, it 
is 3000 minutes. Or 1 hour per week in a year. And I guess that  on some 
uploads, it should be tested again that it still shows up as it should. if 
that happens once pr year pr package, it is 30 minutes pr week pr year.

Isn't that time better spent elsewhere?

From the 'consumer' point of view. I have been of the opinion that as long as 
the Debian menu is *the* thing documented in the policy, consumers should 
display the Debian menu. I even at one point put my time where my mouth was 
and wrote the desktop2menu tool available in devscripts to help the Debian 
menu.

But for various reasons[0], I don't think the Debian Menu is the thing to show 
to most users. And we should get policy fixed to allow this, which is why I 
filed the initial bug+patch that later actually got consensus thru the normal 
policy process, and was heading into the policy until Bill Allombert short 
circuited the policy process in order to defend his kingdom. 

And if one shouldn't 'consume' the menu, why should one provide data for it? 
[2]

No. It is not difficult. It is just work. And give a bad experience to users.

And once again, I'll link to the tool by Arch that builds menus based upon the  
.desktop files that fits in many 'old style' window managers.  
https://wiki.archlinux.org/index.php/Xdg-menu

/Sune

[0] 
 - it is ugly (see the icon format subthread, for example)
 - it duplicates the entries already provided by the desktop files
 - the menu-xdg package generates categories that icon themes doesn't have 
icons for and the menu-xdg maintainer refuses to fix it
 - it contains useless entries for many things that helps hiding what you look 
for [1]
 - having two similar menu structures is confusing.

[1] Shells and interactive interpreters and such.

[2] afaik, the gnome maintainers have added code to the gnome menu building 
thing that does foreach desktopfile in desktopfiles { 
if(!desktopfile.path.contains(menu-xdg)) addtomenu(desktopfile); }
I am planning something similar for the kdelibs menu building code.

-- 
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


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

Bug#741573: Two menu systems

[Sune Vuorela]

Hi

I think there is a couple of facts that aren't fully accurate. I'll try to 
mention them here. I'll try to keep opinions out of this mail.

On Tuesday 08 April 2014 18:30:26 Ian Jackson wrote:
 Consumers: The trad menu is already consumable by a very wide range of
 window managers etc.; the desktop menu is consumed primarily by
 desktop environments.

Note that a very wide range of window managers neither supports the trad. menu 
nor the desktop menu, but has a series of scripts to modify one or the other 
into their native format. In Debian, most of these window managers only has 
the scripts for the trad. menu, while the rest of the internet have the 
scripts that uses the desktop menu.

 Both menu systems have sufficient supporters and users that they are
 independently viable projects.  Some people will say that the trad
 menu is dead and no-one uses it, but that's clearly not true.
 Consider the package
http://qa.debian.org/popcon.php?package=menu-xdg
 which provides a view of the trad menu in desktop system which
 supports the desktop (XDG) menus.

Note that the KDE Desktop task until earlier this year did install menu-xdg, 
and still does it, and the Gnome and XFCE desktops tasks also installed it at 
one point, so these numbers aren't fully usable.

 But if a maintainer wants (for example) to generate a trad menu file
 from an desktop file, then that's fine.  BUT this is ONLY PROVIDED
 that the generated trad menu file is properly confirming to the trad
 menu specification and has the descriptive text, categorisation, etc.,
 preferred by the trad menu maintainers.

As the author of desktop2menu, I can tell that in some cases it is possible to 
generate it, but in the general case it is not possible to use autogeneration. 
It is - like the help2man script - good to create a template. 

/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


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

Bug#743766: konsole: Please mark konsole Multi-Arch foreign

[Sune Vuorela]

On Sunday 06 April 2014 09:57:08 Daniel Schaal wrote:
 Package: konsole
 Version: 4:4.12.3-1
 Severity: wishlist
 Tags: patch
 
 Please mark the konsole package Multi-Arch foreign, so it can
 be used to satisfy dependencies on x-terminal-emulator for
 foreign arch packages (e.g. steam:i386 on amd64).

Note that packages that depends on konsole doesn't just do it for the konsole 
executable, but also for the konsole kpart. Same-arch is needed for packages 
that uses the konsole kpart, here a foreign konsole won't work. (this is for 
packages like yakuake and the console thing apps like kdevelop and kate).

So I'm not sure this is the good fix.

/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


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

Bug#739229: arora: Supports insecure SSL ciphers

[Sune Vuorela]

tag 739229 +patch pending
thanks

 Arora is using insecure SSL ciphers. Please consider disabling following:

I have disabled many insecure ciphers here:

https://github.com/svuorela/arora/commit/8990bf9fc54963aae071560247fc714c6ea3a733

As I have also pulled in patches for Qt5 support, I'm testing for a day or two 
before uploading.

/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


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

Bug#743250: ITP: hotpaultag -- Graphical System Activity Monitor

[Sune Vuorela]

Package: wnpp
Severity: wishlist
Owner: Sune Vuorela s...@debian.org

* Package name: hotpaultag
  Version : snapshot
  Upstream Author : Paultag fanclub 
* URL : http://babe.debian.plumbing
* License : code MIT/X11, artwork needs clarification
  Programming Lang: C++, QtQuick
  Description : Graphical System Activity Monitor

small graphical utility which display the system activity in a
very special way. 
.
Shows various images of his majTAGsty that get hotter and hotter while
your cpu gets hotter.
.
Of course, if you can be shocked by hotness, don't use it!


The package will be maintained by the Paultag fanclub.
There is still a need to fully solve licensing around the artwork.

To test yourself, install cmake, qtbase5-dev, qtdeclarative5-dev and
qtdeclarative5-qtquick2-plugin


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

Bug#707851: Processed: tagging 707851

[Sune Vuorela]

On Tuesday 25 February 2014 23:46:00 Bill Allombert wrote:
 This is a list of MSGID which have not received proper consideration:
 
 20130512130335.ga4...@client.brlink.eu

I think that most of this is 'sorting out details that we might hit in the 
future'. I think that sorting them out when we might hit them is a better 
approach. 

 20130512100730.GA10956@yellowpig

I do think that it has been taken into consideration - see last paragraph in 
https://lists.debian.org/debian-policy/2013/05/msg00071.html for example.

 52e3bde3.80...@gambaru.de
 20140125151743.ga25...@khazad-dum.debian.net
 52ee6a15.8090...@gambaru.de

These three has been taken into consideration by adding

| Packages can, to be compatible with Debian additions to some window
| managers that do not support the FreeDesktop standard, also provide a
| emDebian menu/em file, following the emDebian menu policy/em,
| which can be found in the ttmenu-policy/tt files in the
| ttdebian-policy/tt package.  It is also available from the Debian
| web mirrors at tturl name=/doc/packaging-manuals/menu-policy/
| id=http://www.debian.org/doc/packaging-manuals/menu-policy/;/tt.

to the text.

 Thus there is no consensus in favor of this change, so commiting to
 policy was premature. I reverted it in the GIT repository.

So yes, the comments has been taken into consideration, and I do think that 
there is a consensus. Note that consensus doesn't mean unanimous.

It is time to move on from the debian menu.

/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


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

Bug#707851: Let's remove the Debian menu from the Debian Policy ?

[Sune Vuorela]

Hi peoples

fullquote at bottom

I have the impression that most people seems to agree on something like this. 
I think I might even stretch it and call it a 'rough consensus' with a couple 
of people in the rough end of it.

Can we please move it forward?

Thanks

Sune

On Saturday 11 January 2014 11:46:10 Charles Plessy wrote:
 Hello everybody,
 
 I have read a lot of scepticism about the Debian menu in this thread, and no
 actual support for it.  Perhaps I was trying to be too consensual and
 proposed an over-complicated solution while it is clear that the
 FreeDesktop system is superior.
 
 I attached a new patch, where the Debian menu is removed, and pasted below a
 text export of the 9.6 and 9.7 sections after application of the patch.
 
 Note that for the media types, there is some homework to do before
 recommending to replace all mailcap entries by desktop entries (with
 NoDisplay=true for command-line programs), so I am not proposing this for
 the moment (and welcome help with the “mime-support” package).
 
 I welcome your comments, but I am not calling for seconds (this is not a
 vote). Please if you make objections, indicate what are your stakes
 regarding the menu (user ? developer ? provider of entries ? etc.).
 
 9.6. Menus
 --
 
  Packages shipping applications that comply with minimal requirements
  described below for integration with desktop environments should
  register these applications in the desktop menu, following the
  _FreeDesktop_ standard, using text files called _desktop entries_.
  Their format is described in the _Desktop Entry Specification_ at
  http://standards.freedesktop.org/desktop-entry-spec/latest/ and
  complementary information can be found in the _Desktop Menu
  Specification_ at http://standards.freedesktop.org/menu-spec/latest/.
 
  The desktop entry files are installed by the packages in the directory
  `/usr/share/applications' and the FreeDesktop menus are refreshed
  using _dpkg triggers_.  It is therefore not necessary to depend on
  packages providing FreeDesktop menu systems.
 
  Entries displayed in the FreeDesktop menu should conform to the
  following minima for relevance and visual integration.
 
 * Unless hidden by default, the desktop entry must point to a PNG
   or SVG icon with a transparent background, providing at least the
   22x22 size, and preferably up to 64x64.  The icon should be
   neutral enough to integrate well with the default icon themes.
   It is encouraged to ship the icon in the default _hicolor_ icon
   theme directories, or to use an existing icon from the _hicolor_
   theme.
 
 * If the menu entry is not useful in the general case as a
   standalone application, the desktop entry should set the
   `NoDisplay' key to true, so that it can be configured to be
   displayed only by those who need it.
 
 * In doubt, the package maintainer should coordinate with the
   maintainers of menu implementations through the _debian-desktop_
   mailing list in order to avoid problems with categories or bad
   interactions with other icons.  Especially for packages which are
   part of installation tasks, the contents of the
   `NotShowIn'/`OnlyShowIn' keys should be validated by the
   maintainers of the relevant environments.
 
  Since the FreeDesktop menu is a cross-distribution standard, the
  desktop entries written for Debian should be forwarded upstream, where
  they will benefit to other users and are more likely to receive extra
  contributions such as translations.
 
 
 9.7. Multimedia handlers
 
 
  Media types (formerly known as MIME types, Multipurpose Internet Mail
  Extensions, RFCs 2045-2049) is a mechanism for encoding files and data
  streams and providing meta-information about them, in particular their
  type and format (e.g.  `image/png', `text/html', `audio/ogg').
 
  Registration of media type handlers allows programs like mail user
  agents and web browsers to invoke these handlers to view, edit or
  display media types they don't support directly.
 
  There are two overlaping systems to associate media types to programs
  which can handle them.  The _mailcap_ system is found on a large
  number of Unix systems.  The _FreeDesktop_ system is aimed at Desktop
  environments.  In Debian, FreeDesktop entries are automatically
  translated in mailcap entries, therefore packages already using
  desktop entries should not use the mailcap system directly.
 
 9.7.1. Registration of media type handlers with desktop entries
 ---
 
  Packages shipping an application able to view, edit or point to files
  of a given media type, or open links with a given URI scheme, 

Bug#707851: [call for seconds] Re: Bug#707851: Let's remove the Debian menu from the Debian Policy ?

[Sune Vuorela]

Hi

On Friday 14 February 2014 08:46:01 Charles Plessy wrote:
 Thanks also Markus for your comments during the last round of dicussion on
 debian-devel.

 In his original wording, Josselin proposed to add at the end of section 9.6
 one sentence pointing to the Debian menu as an option.  Here it is,
 rephrased to replace “legacy window managers” by “window managers that do
 not support the FreeDesktop standard”, which is more techically precise.

I do think a paragraph like that still makes the changes better than 'status 
quo', but I do also think that it would be better to 1) not ship this 
paragraph and 2) apologize to Markus and the games team for having wasted 
their time with menu files.  This ensures that we in a year don't have to 3) 
apologize to the rest of the Debian community for having wasted their time 
with menu files.

But still. Better than status quo.

/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


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

Bug#727708: init system other points, and conclusion

[Sune Vuorela]

On Thursday 02 January 2014 14:27:14 Steve Langasek wrote:
 For several years the GNOME Team ignored section 9.7 of Policy, concerning
 integration with the MIME handling system.  They did this in favor of
 implementing the related freedesktop.org on the grounds that the fd.o
 standard is technically superior (and less work, since it was already
 implemented upstream).

Normally my interactions with the GNOME Team is friendly mockery. But 
sometimes one has to stand up next to them.

I've ignored the mime handling system as a part of the KDE Team.
I've ignored the menu system as a part of the KDE Team. And I have a plan to 
even more aggressively ignore it (as in, hide it from the menu).

Both things are ancient relics that should have been dealt with by removal. 

I tried bring the latter thru the policy process, but given one of the few 
people who cares strongly about the debian menu is also a policy delegate, it 
is just a uphill battle and much easier to just move on.

  But if the members of the TC do
 *not* think this is true - if, indeed, our collective preference is for
 upstart rather than for systemd - then I don't think we should be swayed by
 assertions that GNOME upstream is tethering itself to a specific init system

It is not only GNOME upstream that is heading towards systemd as the way to do 
things. It is also where stuff is heading in KDE land.

/Sune
-- 
Genius, I'm not able to cancel the mousepad of a SIMM, how does it work?

The point is that you neither can ever explore the analogic program, nor have 
to ping a printer for saving the SCSI gadget on a proxy over a parallel 
button.


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

Bug#731261: transition: Qt5 switching qreal == double for all platforms

[Sune Vuorela]

On Wednesday 04 December 2013 20:38:09 Julien Cristau wrote:
 On Tue, Dec  3, 2013 at 15:09:18 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
  So I would like what the RT and arm* porters thinks.
 
 This is just my opinion, but if you decide to break ABI, I think you
 should bump SONAME, and I think you must change package names.

Had it been part of a stable release or had it been used by more packages than 
what I can count on my fingers. Then maybe.
Had it been on all architectures. Then maybe.
Or hadn't it been a package where in general the abi is actually the same 
across several distributions, then maybe.

But all in all, the fallout is minimal, and breaking compatibility with the 
rest of the world isn't worth it.

So let's paper it over and not repeat it again in the future.

/sune
-- 
Genius, I cannot explore a tool from the control drawer menu inside Flash 3.2, 
how does it work?

From the file within Office you should never link with the FPU, in such way 
then 
from the control options menu inside Outlook Express you must disable a Fast 
periferic of the memory for saving the controller to the secret code.


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

Bug#727708: systemd (security) bugs (was: init system question)

[Sune Vuorela]

On Thursday 28 November 2013 13:43:27 Ian Jackson wrote:
  CVE summary Debian BTS  Redhat
  2012-0871   systemd-logind insecure file creation   ?   795853

 Furthermore, I think it is fair to look at bugs in non-pid-1 parts of
 the systemd codebase when assessing the likely code quality of the pid
 1 parts.

Note that the non-pid1-parts of systemd, like logind for example, are pieces 
we need no matter what init system we choose. The question is more if we can 
use them as provided by upstream or we need to adapt them in Debian.

/Sune
-- 
How to close the space bar?

First from the control drawer inside Office 8.7.5 you should ping the site of 
the controller for logging on a BIOS.


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

Bug#727708: systemd (security) bugs (was: init system question)

[Sune Vuorela]

On Sunday 01 December 2013 21:50:49 Ian Jackson wrote:
 This leads me to a question which I find myself asking, after reading
 the systemd debate page:
 
 If we were to adopt systemd as pid 1, which sections of the systemd
 source code would we probably want to adopt as well ?  Or to put it
 another way, which other existing programs would be obsoleted ?

logind is obsoleting consolekit and libpam-xdg. (Consolekit tracks wether or 
not a user is sitting on the physical console or logged in. libpam-xdg ensures 
that XDG_RUNTIME_DIR is handled according to the spec). Logind also ensures 
that a user session actually can be terminated when she logs out.

Logind is the most important one, and within a year or two all desktop 
environments that wants to be slightly more advanced than TWM is going to need 
it. Even Ubuntu is using logind and is iirc maintained there by Steve 
Langasek.

Consolekit was written by the same people as involved in systemd and is now 
hopefully getting it right. Consolekit is abandoned upstream a couple of years 
ago. Libpam-xdg was written by Steve Langasek for Ubuntu and has since been 
abandoned in in Ubuntu favour of the systemd bits .

Beside that, there are among others:
the timezoned is ensuring a common way that applications can get notified when 
the hosts timezone changes. KDE does have something for that that would be 
obsoleted. I think most other systems requires restart of applications or 
manual magic in each app.

hostnamed is for notifying when hostname changes. KDE does have something for 
that. I don't know who else.

There are more parts, but that's where my research has ended so far. 

/Sune
-- 
How to cancel a mailer to the proxy from Flash and from the folder inside DOS 
97?

You must log on a driver to debug a monitor.


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

Bug#729215: kate: Please include pate/python-plugins files with kate/kate-data packages

[Sune Vuorela]

On Sunday 10 November 2013 23:38:22 Jason Alavaliant wrote:
 Package: kate
 Version: 4:4.11.3-1
 Severity: wishlist
 
 Dear Maintainer,
 Please consider enabling/adding the pate/python-plugins files to the
 kate/kate-data packages so the python plugins in the upstream kate source
 are made available to debian users.

It has been considered a couple of times, but there is a circular issue that 
we would haven't yet found a good way to solve.

  python-kde4-dev (= 4:4.9.80),

Installing python-kde4 requires kde-runtime which requires kdelibs5-plugins 
which requires katepart which is going to be built by kate.

So the circle has to be broken somehow, and ubuntu iirc has chosen to just 
require to have kate built in order to build kate.

/Sune
-- 
How to boot a board from Internet Explorer?

First of all you either must reset the memory address on the level-9 SIMM, or 
should never disconnect a folder for turning off the mousepad over a Fast shell 
to a MIDI ethernet application.


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

Bug#727242: kmail: Kmail does not import filters from previous version

[Sune Vuorela]

severity 727242 important
thanks

This might be a inconvenient loss of some configuration, but given all emails 
stays in Inbox, they aren't lost, so downgrading to important.

/Sune


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

Bug#719058: libgc symbols error on mips64(el)

[Sune Vuorela]

On Sunday 11 August 2013 21:47:59 Christoph Egger wrote:
 Hi!
 
 YunQiang Su wzss...@gmail.com writes:
  Mips64(el) 's symbols is a little different, or it will ftbfs.
 
 Hmm strange. Maybe the symbols helper doesn't know mips64(el) yet?

I would be quite surprised if pkgkde-symbolshelper knew about mips64(el) (and 
n32 for that sake) without any patches.

Patches are most welcome.

/Sune
-- 
How can I uninstall the mousepad?

From the panel within Photoshop 8.4 you either need to get access over a RW 
cache, or have not to boot with the tool to a Fast PCI kernel to the shell 
over the analogic BIOS password on a folder of a directory for uploading the 
DVD window.


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

Bug#718893: RFS: coinutils/2.9.4-1 [ITA] -- CoinOR base library

[Sune Vuorela]

On Wednesday 07 August 2013 15:45:37 Etienne Millon wrote:
 There are tarballs containing the full distribution at:
 http://www.coin-or.org/download/source/CoinAll/
 
 It seems to be a a little older (the last release is from january
 2012), but it would be massively easier to maintain than having N
 source packages. What do you think?

In the general case, it is normally much easier to maintain N smaller packages 
than one giant that combines everything. It makes 'release early, release 
often' much simpler since you can just push a fix to e.g. coinutils without 
having to also push a fix to cgl, cbc and others. Like the bugfix I pushed to 
cbc: http://packages.qa.debian.org/c/coinor-cbc/news/20110701T100215Z.html - 
much simpler just to push that than to push a entire new CoinAll.

And in this specific case, the coinor build systems in general is so full of 
weirdnesses that just adapting it in smaller bits is much more feasable than 
adapting all of it.

And given the different parts of coinor also have different release schedules 
it 
is also easier to provide the actual newest fixed bits with separate packages 
rather than large combined packages.

So from my experience, both with coinor and with other large source packages, 
(KDE*, Qt*), separate sources is just the thing to do.

/Sune


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

Bug#717040: kmail: Can't send mail since upgrading to 4:4.10.5-1

[Sune Vuorela]

Hi Russell 

It would be great if you could provide the info below.

/Sune

On Wednesday 24 July 2013 00:00:55 Sune Vuorela wrote:
 Hi Russel
 
 The following is using the 'akonadiconsole' tool which is kind of a
 specialist toolbox. Looking around should be fine, but be very careful with
 changing anything. (it also warns you on startup)
 
 If you in the browser tab can navigate to the relevant outbox (check that it
 has the right content)
 
 Right click on the folder in and select properties. Go to the attributes
 tab. Is there a SpecialCollectionAttribute? what is it set to?
 Is there a ENTITYDISPLAY? what is it set to?
 
 /Sune
 
 On Tuesday 16 July 2013 18:55:05 Russell Coker wrote:
  Package: kmail
  Version: 4:4.10.5-1
  Severity: important
  
  Since upgrading to 4:4.10.5-1 from 4:4.4.11.1+l10n-3+b1 I have been unable
  to send mail.  Mail stays in the Outbox folder forever and the
  Send Queued Messages option has no effect.
  
  I have tried deleting the sending accounts and creating a new entry (which
  sends mail to localhost port 587) and that makes no difference.
  
  -- System Information:
  Debian Release: jessie/sid
  
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
  
  Architecture: amd64 (x86_64)
  
  Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores)
  Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
  Shell: /bin/sh linked to /bin/dash
  
  Versions of packages kmail depends on:
  ii  kde-runtime   4:4.10.5-1
  ii  kdepim-runtime4:4.10.5-1
  ii  kdepimlibs-kio-plugins4:4.10.5-1
  ii  libakonadi-contact4   4:4.10.5-1
  ii  libakonadi-kde4   4:4.10.5-1
  ii  libakonadi-kmime4 4:4.10.5-1
  ii  libakonadiprotocolinternals1  1.9.2-2
  ii  libc6 2.17-7
  ii  libcalendarsupport4   4:4.10.5-1
  ii  libgcc1   1:4.8.1-6
  ii  libgpgme++2   4:4.10.5-1
  ii  libincidenceeditorsng44:4.10.5-1
  ii  libkabc4  4:4.10.5-1
  ii  libkcalcore4  4:4.10.5-1
  ii  libkcalutils4 4:4.10.5-1
  ii  libkcmutils4  4:4.10.5-1
  ii  libkdecore5   4:4.10.5-1
  ii  libkdepim44:4.10.5-1
  ii  libkdeui5 4:4.10.5-1
  ii  libkio5   4:4.10.5-1
  ii  libkleo4  4:4.10.5-1
  ii  libkmime4 4:4.10.5-1
  ii  libknotifyconfig4 4:4.10.5-1
  ii  libkontactinterface4  4:4.10.5-1
  ii  libkparts44:4.10.5-1
  ii  libkpgp4  4:4.10.5-1
  ii  libkpimidentities44:4.10.5-1
  ii  libkpimtextedit4  4:4.10.5-1
  ii  libkpimutils4 4:4.10.5-1
  ii  libkprintutils4   4:4.10.5-1
  ii  libksieveui4  4:4.10.5-1
  ii  libktnef4 4:4.10.5-1
  ii  libmailcommon44:4.10.5-1
  ii  libmailimporter4  4:4.10.5-1
  ii  libmailtransport4 4:4.10.5-1
  ii  libmessagecomposer4   4:4.10.5-1
  ii  libmessagecore4   4:4.10.5-1
  ii  libmessagelist4   4:4.10.5-1
  ii  libmessageviewer4 4:4.10.5-1
  ii  libnepomukcore4   4:4.10.5-1
  ii  libpimcommon4 4:4.10.5-1
  ii  libqt4-dbus   4:4.8.5+dfsg-2
  ii  libqt4-network4:4.8.5+dfsg-2
  ii  libqt4-xml4:4.8.5+dfsg-2
  ii  libqtcore44:4.8.5+dfsg-2
  ii  libqtgui4 4:4.8.5+dfsg-2
  ii  libqtwebkit4  2.2.1-6
  ii  libsolid4 4:4.10.5-1
  ii  libsoprano4   2.9.2+dfsg.1-1
  ii  libstdc++64.8.1-6
  ii  libtemplateparser44:4.10.5-1
  ii  perl  5.14.2-21
  
  Versions of packages kmail recommends:
  ii  gnupg-agent   2.0.20-1
  ii  gnupg22.0.20-1
  ii  pinentry-gtk2 [pinentry-x11]  0.8.1-1
  
  Versions of packages kmail suggests:
  pn  clamav | f-prot-installer   
  none
  ii  kaddressbook
  4:4.10.5-1 ii  kleopatra
  
  4:4.10.5-1 ii  procmail
  
  3.22-20 pn  spamassassin | bogofilter | annoyance-filter |
  
  spambayes | bsfi  none
  
  -- no debconf information


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

Bug#718348: qtbase5-dev: Unable to configure cmake project using qt5 without qtbase5-private-dev

[Sune Vuorela]

On Tuesday 30 July 2013 17:27:59 WANA wrote: 
 With Qt5 (at time of writing 5.1.0+dfsg-1 is in experimental) you will get
 this error, if the package qtbase5-private-dev is not installed:

Yep. It is a bug in the cmake files. They are fixed upstream for 5.1.1, iirc. I 
think we will include it in the next upload if we do any more 5.1.0 uploads.
 
 I don't know if this behavior was intended. But it might be more intuitive
 to just install qtbase5-dev and everything works out of the box. 

It is expected that everything works with using the public headers.

 Perhaps a
 dependency or recommendation in qtbase5-dev on qtbase5-private-dev might
 help here.

The private headers is not something you should install under normal 
conditions.

/Sune


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

Bug#717040: kmail: Can't send mail since upgrading to 4:4.10.5-1

[Sune Vuorela]

Hi Russel

The following is using the 'akonadiconsole' tool which is kind of a specialist 
toolbox. Looking around should be fine, but be very careful with changing 
anything. (it also warns you on startup)

If you in the browser tab can navigate to the relevant outbox (check that it 
has the right content)

Right click on the folder in and select properties. Go to the attributes tab. 
Is there a SpecialCollectionAttribute? what is it set to?
Is there a ENTITYDISPLAY? what is it set to?

/Sune

On Tuesday 16 July 2013 18:55:05 Russell Coker wrote:
 Package: kmail
 Version: 4:4.10.5-1
 Severity: important
 
 Since upgrading to 4:4.10.5-1 from 4:4.4.11.1+l10n-3+b1 I have been unable
 to send mail.  Mail stays in the Outbox folder forever and the
 Send Queued Messages option has no effect.
 
 I have tried deleting the sending accounts and creating a new entry (which
 sends mail to localhost port 587) and that makes no difference.
 
 -- System Information:
 Debian Release: jessie/sid
   APT prefers unstable
   APT policy: (500, 'unstable'), (1, 'experimental')
 Architecture: amd64 (x86_64)
 
 Kernel: Linux 3.9-1-amd64 (SMP w/2 CPU cores)
 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages kmail depends on:
 ii  kde-runtime   4:4.10.5-1
 ii  kdepim-runtime4:4.10.5-1
 ii  kdepimlibs-kio-plugins4:4.10.5-1
 ii  libakonadi-contact4   4:4.10.5-1
 ii  libakonadi-kde4   4:4.10.5-1
 ii  libakonadi-kmime4 4:4.10.5-1
 ii  libakonadiprotocolinternals1  1.9.2-2
 ii  libc6 2.17-7
 ii  libcalendarsupport4   4:4.10.5-1
 ii  libgcc1   1:4.8.1-6
 ii  libgpgme++2   4:4.10.5-1
 ii  libincidenceeditorsng44:4.10.5-1
 ii  libkabc4  4:4.10.5-1
 ii  libkcalcore4  4:4.10.5-1
 ii  libkcalutils4 4:4.10.5-1
 ii  libkcmutils4  4:4.10.5-1
 ii  libkdecore5   4:4.10.5-1
 ii  libkdepim44:4.10.5-1
 ii  libkdeui5 4:4.10.5-1
 ii  libkio5   4:4.10.5-1
 ii  libkleo4  4:4.10.5-1
 ii  libkmime4 4:4.10.5-1
 ii  libknotifyconfig4 4:4.10.5-1
 ii  libkontactinterface4  4:4.10.5-1
 ii  libkparts44:4.10.5-1
 ii  libkpgp4  4:4.10.5-1
 ii  libkpimidentities44:4.10.5-1
 ii  libkpimtextedit4  4:4.10.5-1
 ii  libkpimutils4 4:4.10.5-1
 ii  libkprintutils4   4:4.10.5-1
 ii  libksieveui4  4:4.10.5-1
 ii  libktnef4 4:4.10.5-1
 ii  libmailcommon44:4.10.5-1
 ii  libmailimporter4  4:4.10.5-1
 ii  libmailtransport4 4:4.10.5-1
 ii  libmessagecomposer4   4:4.10.5-1
 ii  libmessagecore4   4:4.10.5-1
 ii  libmessagelist4   4:4.10.5-1
 ii  libmessageviewer4 4:4.10.5-1
 ii  libnepomukcore4   4:4.10.5-1
 ii  libpimcommon4 4:4.10.5-1
 ii  libqt4-dbus   4:4.8.5+dfsg-2
 ii  libqt4-network4:4.8.5+dfsg-2
 ii  libqt4-xml4:4.8.5+dfsg-2
 ii  libqtcore44:4.8.5+dfsg-2
 ii  libqtgui4 4:4.8.5+dfsg-2
 ii  libqtwebkit4  2.2.1-6
 ii  libsolid4 4:4.10.5-1
 ii  libsoprano4   2.9.2+dfsg.1-1
 ii  libstdc++64.8.1-6
 ii  libtemplateparser44:4.10.5-1
 ii  perl  5.14.2-21
 
 Versions of packages kmail recommends:
 ii  gnupg-agent   2.0.20-1
 ii  gnupg22.0.20-1
 ii  pinentry-gtk2 [pinentry-x11]  0.8.1-1
 
 Versions of packages kmail suggests:
 pn  clamav | f-prot-installernone
 ii  kaddressbook
 4:4.10.5-1 ii  kleopatra   
 4:4.10.5-1 ii  procmail
 3.22-20 pn  spamassassin | bogofilter | annoyance-filter |
 spambayes | bsfi  none
 
 -- no debconf information
-- 
I cannot cancel the RO window, how does it work?

You neither should explore with a display, nor have to log in a command prompt 
over the LCD operating system to the CD URL on a graphic TCP e-mail but you 
should never ping the virus but therefore you cannot turn off a CD driver for 
connecting to a desktop of the icon of a hard disk over the AGP kernel to the 
processor on the button over a GPU to a LCD modem.


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

Bug#707018: transition: New release of KDE Plasma Workspaces, KDE Platform and KDE Applications

[Sune Vuorela]

On Sunday 30 June 2013 16:31:08 Julien Cristau wrote:
 On Tue, May  7, 2013 at 00:19:05 +0200, Sune Vuorela wrote:
  It is mostly digikam, calligra and a couple of 3rd party
  plasma-widget-foo that will be affected outside our group of pacakges.
 
 Does that involve source changes in those packages?

It involves source changes in digikam (and is ready in exp). No source changes 
in calligra.  There might be minor changes needed in some third party plasma 
widgets, but they can  at the worst case be dropped.

/Sune
-- 
Genius, I'm not able to uninstall on the controller from the preferences menu 
inside LinuxPPC, how does it work?

The point is that from DOS 6000 and from Mac you neither can debug the driver, 
nor should explore with a jumper on a SCSI program over the SIMM, this way you 
must close the pointer to the port to rename the MIDI OpenGL mailer.


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

Bug#710140: gpgme1.0 (=1.3.2) dropping libgpgme-pth.so

[Sune Vuorela]

On Wednesday 29 May 2013 17:25:36 Daniel Leidert wrote:
 So to me it looks like, that libgpgme++2 is the only affected package
 and might probably be fixed by a rebuild of kdepimlibs.

Please get a release-team ack for papering over the abi breakage if you really 
think it is the right thing to do.

/Sune

-- 
Genius, I'm not able to open the editor to a CPU over a front-end from 
Outlook, how does it work?

You either must reset the IP controller, or should never insert the 
attachment, so that you neither need to save on a monitor, nor can ever log on 
a server on the 9X 2D head on a memory address on the RW pointer in order to 
mount the driver.


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

Bug#710140: [Fwd: About gpgme1.0 (1.4.1-0.1) and libpth-dev]

[Sune Vuorela]

Package: libgpgme11
Severity: serious
Version: 1.4.1-0.1

On Tuesday 28 May 2013 15:35:07 Maximiliano Curia wrote:
 ¡Hola Daniel!
 
 El Tuesday, May 28, 2013 a las 08:06 escribiste:
  The build-time dependency on libpth-dev has been dropped in upstream
  release 1.3.2. Check out the NEWS file.
 
 Ok, great.

So you broke the abi of the package. That needs a proper transition, not 
papering stuff over with rebuilds. And it means we also need to do a transition 
with libgpgme++. Alterantively, we need to bring it back. If it is abi 
compatible with one of the other libraries, we might be able to get away with 
a couple of symlinks.

Libraries isn't hard. It just needs a bit of consideration.

/Sune


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

Bug#643726: Still happening

[Sune Vuorela]

On Monday 27 May 2013 01:39:42 brian m. carlson wrote:
 Please address this issue.

Sorry that we haven't addressed this issue yet, but we are a bit swamped in 
1300 bug reports and sometimes things fall past the cracks. If this is 
unsatisfactory, you are most welcome to join in or alternatively contact your 
software vendor and ask for a refund.

/Sune
-- 
Man, do you know how may I do for clicking a parallel LCD jumper?

From the drawer inside Office you must insert in the hardware for sending a 
analogic IP icon over a Ultraflat mailer of the server on the front-end of a 
CPU.


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

Bug#709382: mksh: broken Built-Using handling

[Sune Vuorela]

Package: mksh
Version: 46-1
Severity: serious

Dear Maintainer,

The handling of built-using is wrong. It is not meant to encode the
compiler used, nor binutils or kernel headers should be recorded there

It is specifically for building against -source packages and for hacks
like ia32libs where binaries are copied into a source package. Not for
'everything'.

What you effectively are doing is asking for a mksh rebuild on each
upload of the kernel, of gcc and what else you have put there. Imagine
if we all did that. Buildd power. or mirror size. or both.

/Sune

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

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

Versions of packages mksh depends on:
ii  libc62.17-3
ii  libgcc1  1:4.8.0-7

mksh recommends no packages.

Versions of packages mksh suggests:
ii  ed  1.8-1

-- no debconf information


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

Bug#708957: [src:kde4libs] Please override lintian warnings about ghdl

[Sune Vuorela]

reassign 708957 lintian
thanks

Hi

Thanks for working on gfdl issues.

This is, though, a bug in lintian and should be fixed there.
These are template files and as such it doesn't tell *anything* about the 
license of stuff.

You could just look for the entities 
FDLInvariantSections;
FDLFrontCoverText;
FDLBackCoverText;

and don't do any  errors/warnings about it.

/Sune

On Sunday 19 May 2013 19:32:26 bastien ROUCARIES wrote:
 Package: src:kde4libs
 Severity: wishlist
 
 On the template file lintian choke. I could not found a way to automatically
 guess it (as the maintener of the test), so please manually override the
 error:
 
 # this is template only with entity for invariant section. It is free
 E: kde4libs source: license-problem-gfdl-invariants
 kdoctools/customization/fr/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/fr/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/fr/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/ru/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/ru/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/ru/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sl/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sl/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sl/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/ja/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/ja/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/ja/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sk/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sk/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sk/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/lt/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/lt/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/lt/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/zh-TW/entities/gpl-notice.docbook E: kde4libs
 source: license-problem-gfdl-invariants
 kdoctools/customization/zh-TW/entities/lgpl-notice.docbook E: kde4libs
 source: license-problem-gfdl-invariants
 kdoctools/customization/zh-TW/entities/fdl-notice.docbook E: kde4libs
 source: license-problem-gfdl-invariants
 kdoctools/customization/pl/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/pl/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/pl/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/da/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/da/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/da/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/el/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/el/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/el/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sv/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sv/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/sv/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/fi/entities/gpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/fi/entities/lgpl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/fi/entities/fdl-notice.docbook E: kde4libs source:
 license-problem-gfdl-invariants
 kdoctools/customization/zh-CN/entities/gpl-notice.docbook E: kde4libs
 source: license-problem-gfdl-invariants
 kdoctools/customization/zh-CN/entities/lgpl-notice.docbook E: kde4libs
 source: license-problem-gfdl-invariants
 kdoctools/customization/zh-CN/entities/fdl-notice.docbook E: 

Bug#707851: debian-policy: soften the wording recommending menu files

[Sune Vuorela]

On Sunday 12 May 2013 12:07:30 Bill Allombert wrote:

  And it is probably similar for many other window managers and desktop
  environments.
 
 How many window managers support the XDG menu specification ?

Most[tm]

It is *the* menu in Gnome, in KDE's workspaces, in XFCE, in LXDE, in razor-qt, 
in trinity, mate, cinnamon.

For fluxbox, openbox, blackbox, fvwm, icewm, windowmaker, gnustep and probably 
others, there exists scripts that convert a XDG menu structure into their own 
formats, not unlike currently where scripts is used to convert the debian menu 
structure into their own formats.

/Sune
-- 
Do you know how can I overclock the connector?

From the tools inside Outlook you must install a firewall in order to unlink a 
window of a virus.


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

Bug#639300: Bug#707301: release-notes: odbcinst1debian2 : Breaks: tdsodbc ( 0.82-8) but 0.82-7 is to be installed

[Sune Vuorela]

[recipients trimmed]
 I recommend applying the patch from bug #639300 in a stable update, instead
 of leaving akonadi/virtuoso un-coinstallable with all ODBC drivers in
 wheezy.  Attached is an updated patch for this issue.

My recommendation is to have unixodbc drop the useless and broken Breaks.

 KDE maintainers: would you prefer to prepare a different fix yourselves for
 this issue, or upload this patch yourself?

I guess I can NMU unixodbc if you prefer, given that is the good fix.

iodbc is what upstream and most distributions uses here, and I see no reason 
to deviate from upstream here. 

iodbc is the one supported and written by virtuoso upstream, so that's the one 
we prefer to use.

/Sune
 - member of KDE team.
-- 
Do you know how can I cancel the periferic?

First you either should close the cache, or need to send to a ISA sendmail in 
order to overclock the digital memory.


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

Bug#707851: debian-policy: soften the wording recommending menu files

[Sune Vuorela]

Package: debian-policy
Severity: normal

Dear Maintainer,

In the default desktop installation of Debian, the Debian menu is
actively hidden (On GNOME by a patch to gnome-menus). 

In the - I think - most common alternate used desktop setup (KDE Plasma 
Desktop), the Debian menu looks like a weird icon-less graft-on mostly
duplicating what is already in the menu structure elsewhere. And there
is people around KDE in Debian considering the same approach as Gnome.

And it is probably similar for many other window managers and desktop
environments.

Also, many popular packages have stopped providing menu-files for the
Debian menu.

So let's soften the wording a little around debian menu files in policy
so that people don't feel like they *have* to create menu files that
aren't much used.

So, I would suggest the following:

--- a/policy.sgml
+++ b/policy.sgml
@@ -7984,20 +7984,8 @@ Reloading vardescription/var configuration...done.
   sect id=menus
headingMenus/heading
 
-   p
- The Debian ttmenu/tt package provides a standard
- interface between packages providing applications and
- emmenu programs/em (either X window managers or
- text-based menu programs such as prgnpdmenu/prgn).
-   /p
-
-   p
- All packages that provide applications that need not be
- passed any special command line arguments for normal
- operation should register a menu entry for those
- applications, so that users of the ttmenu/tt package
- will automatically get menu entries in their window
- managers, as well in shells like ttpdmenu/tt.
+   pPackages can, to be compatible with legacy debian additions
+ to some legacy window managers, provide a menu file.
/p
 
p


Thank you for considering

/Sune

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

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


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

Bug#707851: debian-policy: soften the wording recommending menu files

[Sune Vuorela]

On Saturday 11 May 2013 13:36:36 Russ Allbery wrote:
 I think I agree with this move, but I'd really like it to come in
 conjunction with adding a recommendation to include a desktop file, since
 that's what most of the desktop environments actually use.  That way, we
 don't lose functionality.
 
 Would you be willing to take a first stab at writing something like that?

Something like:

--- a/policy.sgml
+++ b/policy.sgml
@@ -7984,20 +7984,18 @@ Reloading vardescription/var configuration...done.
   sect id=menus
headingMenus/heading
 
-   p
- The Debian ttmenu/tt package provides a standard
- interface between packages providing applications and
- emmenu programs/em (either X window managers or
- text-based menu programs such as prgnpdmenu/prgn).
+   pApplications that belongs in the menu of a desktop environment
+ or a window manager should provide desktop files for integrating
+ with the menus.
/p
 
-   p
- All packages that provide applications that need not be
- passed any special command line arguments for normal
- operation should register a menu entry for those
- applications, so that users of the ttmenu/tt package
- will automatically get menu entries in their window
- managers, as well in shells like ttpdmenu/tt.
+   pFor desktop files, see the Desktop Menu Specification available at
+ tturl name=http://standards.freedesktop.org/menu-spec/latest/; 
+id=http://standards.freedesktop.org/menu-spec/latest///tt
+   /p
+
+   pPackages can, to be compatible with legacy debian additions
+ to some legacy window managers, provide a menu file.
/p
 
p


/Sune
-- 
Man, how to telnet from the tool?

You cannot receive the hardware, so that from Word you neither must send to a 
9-inch SCSI terminale to a graphic connection, nor need to load from the BIOS 
jumper for pinging a RW SMTP BIOS over a LCD processor of a IP hard disk of 
the bus on the sendmail.


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

Bug#707851: debian-policy: soften the wording recommending menu files

[Sune Vuorela]

Hi Charles

Thank you for your questions

On Sunday 12 May 2013 10:08:52 Charles Plessy wrote:
 If we were to recommend FreeDesktop menu entries instead of Debian menu
 entires, and if this recommendation were followed carefully, this would
 increase the number of entries in the Gnome and KDE menus on some sytems
 where the user has installed extra packages.  In particular, some entries
 will be redundant with the default applications, and provide only an XPM
 icon or no icon at all.

Currently Plasma Desktop shows both the Debian menu and the 'real' menu - with 
loads of overlaps between them. All these overlaps comes with one with a 'good 
icon' and nice descriptions and everything. The other comes with a poor xpm 
icon or no icon at all, and not always good descriptions of the program. I 
think that if we stopped using the Debian menu and just used the Desktop Menu 
Spec, it would result in *fewer* items in the menu, and best of all no 
duplicates.

 It looks to me that the scope of the Debian menu system is broader than
 the FreeDesktop system.

It looks to me that the scopes are very similar, and the XDG system is 
supported outside debian in most users systems without any extra effort. And in 
many cases the XDG files are even translated by upstream.


 http://wiki.debian.org/Proposals/DebianMenuUsingDesktopEntries

I think this proposal is entirely orthogonal to what I'm suggesting.

 About the current patch, I think that the mention of legacy debian
 additions to some legacy window managers is not informative as it does not
 provide guidance.  For the both menu systems, I would like to have
 explanations about 1) what is the scope of this menu, 2) what is the
 standard syntax for the entries, and 3) how packages should implement this.

I think that for 2) and 3) pointing to the existing specs is the right thing 
to do, not trying to summarize the specs.

I'm not sure what you mean by 1)

 For the FreeDesktop entries, can you summarise the expectations, in
 particular about the scope and whether it is better to have a FreeDestkop
 entry with an awful or missing icon or no entry at all ?  

I'm not sure what you mean by scope.  
If the app is useful to have in the menu, then I have no opinion on bad 
artistry. And luckily the artistry can actualy be overridden by regular icon 
themes if the entries here are named matching the XDG icon spec, which I think 
the desktop file spec references.

 Lastly, the FreeDesktop entry files have also associate programs with media
 types, and as you probably noticed, this is in the scope of section 9.7
 (Multimedia handlers), so please let us know your thougts or suggestions

It hasn't been within what I have been looking at so far, but I think that we 
could gain a lot by consolidating on desktop files also for this type of 
information.

/Sune
-- 
Do you know how may I explore with the SCSI space bar?

From Flash you either should mount a AGP software, or never have to telnet 
from the connector for unmounting the hardware.


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

Bug#707851: debian-policy: soften the wording recommending menu files

[Sune Vuorela]

On Saturday 11 May 2013 19:44:13 Russ Allbery wrote:
console apps 
 Do you want them to?  A straightforward reading of this modification to
 Policy, were I the bc and dc maintainer, would indicate that I should add
 a desktop file to the package.

There is as such nothing wrong with it, and the spec even supports defining 
wether or not a app runs in a terminal window.

if they are categorized properly, I don't see a issue with having them around, 
but I personally might not want to encourage them.

/Sune
-- 
How might I do for disabling the submenu?

You neither should ever reinstall on the jumper, nor need to ping to the line 
of a processor over a graphic directory but from Netscape and from the control 
folder menu inside MS-DOS you either must remove from the fan, or can never 
telnet on a MIDI ADSL case.


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

Bug#707851: debian-policy: soften the wording recommending menu files

[Sune Vuorela]

On Sunday 12 May 2013 12:09:28 Charles Plessy wrote:
 Hi again,
 
 here are a few clarification in addition to the answer from Russ.  I assume
 that, as for Gnome, it is possible for KDE to hide the whole Debian menu if
 wanted, so the question is about possible proliferation of FreeDestkop
 entries.

Thank you for the clarification.  for Gnome, the disabling is very hardcoded in 
the sources. nothing coming from menu-xdg will ever be shown. I have been 
considering something similar in KDE-land.

 For 1) it could be any directive such as:

I'm not sure I see the need for any such directives.

 
 For 2), in the case of FreeDesktop, it is the link to the spec.
 
 For 3), it is a brief explanation that the entries should be deposited
 in /usr/share/applications, and that the packages should not depend
 or recommend desktop-file-utils, nor call its functions in their postinst,
 because there are Dpkg triggers for this.

I'll try to cook up something around this.

 If there are other or similar recommendations, for instance regarding the
 icon files, etc., please let us know.

The desktop file spec references the icon spec. I'm not sure if we should be 
more explicit than that. Maybe mentioning a basedir.

/Sune
-- 
I cannot get access over the hard disk from the drawer menu within Explorer, 
how does it work?

You have to enable a board for renaming the desktop of the pointer.


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

Bug#707018: transition: New release of KDE Plasma Workspaces, KDE Platform and KDE Applications

[Sune Vuorela]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi

We have a new set of magic by KDE prepared in experimental as much as
aptitude has allowed us.

We would love to bring it to unstable whenever it fits you. We can bring
it in as one big blob or as several smaller blobs.

There is some shlib bumps and a handful of intertwined soname changes
without too many rdeps outside our own chunk.

Of interesting bits, src:kdemultimedia and src:kdegames has been split
upstream in ~30 source packages. And there is soname changes for
libkipi, libkdcraw, libkexiv2, some of the kde-workspace libraries,
libmarble, libkdegames, libokular-core and probably a bit more.

It is mostly digikam, calligra and a couple of 3rd party
plasma-widget-foo that will be affected outside our group of pacakges.


/Sune


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

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


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

Bug#705972: ITP: qupzilla -- lightweight web browser based on libqtwebkit

[Sune Vuorela]

On Tuesday 23 April 2013 00:18:37 Georges Khaznadar wrote:
   Description : lightweight web browser based on libqtwebkit

Please define lightweight. 

Two good links to descriptions of the term lightweight.

http://blog.martin-graesslin.com/blog/2013/04/what-makes-a-lightweight-desktop-environment-lightweight/
http://mjg59.livejournal.com/136274.html


  There are already a lot of QtWebKit
  browsers available, but they are either bound to the KDE environment
  (rekonq),

This is just plain wrong. *nothing* binds for example rekonq to a kde 
environment. Please stop spreading such clueless wrong statements.

  are not actively developed or very unstable and miss
  important features. 

This is also wrong. THere is both rekonq and konqueror around.

  But there is missing a multiplatform, modern and
  actively developed browser. 

There is both rekonq and konqueror around.

So, I hope you will polish up the descriptions to get the facts straight 
before uploading the package.

/Sune
-- 
Man, how can I save on the head from Office 2.3.2?

From LinuxPPC 97 and from the tools within Flash you have to boot from a 
hardware over a 65-bit menu on a driver over the FPU on the case to a ROM 
attachment to get access on the display.


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

Bug#705714: unblock: meta-kde/5:77+deb7u1

[Sune Vuorela]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package meta-kde

The default install of KDE Plasma Workspace ended up with two
applications notifying the user about available updates,
update-notifier-kde and apper. The latter can also actually help with
applying the updates so it is generally preferred. So let's remove
update-notifier-kde from the default install. 

unblock meta-kde/5:77+deb7u1

Thanks in advance

Here comes the full diff according to my git.

Hugs and kisses.

/Sune

diff --git a/debian/changelog b/debian/changelog
index 5021c56..3bd126e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+meta-kde (5:77+deb7u1) unstable; urgency=low
+
+  * Drop update-notifier-kde relations. The default install contains
+apper, which notifies the user about available upgrades which is
+the same as what update-notifier-kde does, so the user would get
+two notifications about available upgrades. (Closes: 705646)
+
+ -- Sune Vuorela s...@debian.org  Fri, 19 Apr 2013 01:18:11 +0200
+
 meta-kde (5:77) unstable; urgency=low
 
   * Team upload.
diff --git a/debian/control b/debian/control
index 549bf90..8a093fd 100644
--- a/debian/control
+++ b/debian/control
@@ -63,8 +63,7 @@ Depends: ${misc:Depends}, kde-plasma-desktop (= 
${source:Version}) | kde-plasma
  okular (= ${kde:Version}), plasma-desktopthemes-artwork (= ${kde:Version}), 
sweeper (= ${kde:Version}),
  khelpcenter4 (= ${kde:Version})
 Recommends: konq-plugins (= ${kde:Version}), plasma-widget-networkmanagement,
- freespacenotifier (= ${kde:Version}),
- update-notifier-kde
+ freespacenotifier (= ${kde:Version})
 Suggests: kde-l10n (= ${kde:Version}), kde-plasma-desktop (= 
${source:Version}),
  kde-plasma-netbook (= ${source:Version}), skanlite
 Breaks: kde-minimal ( 5:57)
-- 
I'm not able to insert the pin of a button over the e-mail, how does it work?

You should reinstall a forward.


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

Bug#693921: [Aptitude-devel] Bug#693921: fails to resolve empathy/experimental dependencies, fails with signal 6

[Sune Vuorela]

On Friday 29 March 2013 09:33:37 Sjoerd Simons wrote:
  [1] aptitude -y --without-recommends -o Dpkg::Options::=--force-confold
  -o Aptitude::CmdLine::Ignore-Trust-Violations=false -o
  Aptitude::ProblemResolver::StepScore=100 -o
  Aptitude::ProblemResolver::SolutionCost=safety, priority,
  non-default-versions -o
  Aptitude::ProblemResolver::Hints::KeepDummy=reject empathy-build-deps
  :UNINST -o Aptitude::ProblemResolver::Keep-All-Level=55000 -o
  Aptitude::ProblemResolver::Remove-Essential-Level=maximum install
  empathy-build-deps
 
 I used this method to reproduce the issue for current
 gnome-shell/experimental. The trigger seems to be the usage of
 non-default-versions in the SolutionCost, using the default (safety,
 priority) like e.g. pbuilder does results in aptitude successfully
 finding a solution.

I tried this as well, hoping it would kind of work. But while it resolved stuff 
quite fast, I'm not sure it actually resolves good.

I ended up with some cairo and python bits from experimental even though I 
should have no requirements for that (when building kde-runtime 4:4.10.2-1)

So while it was a good idea to just use default for SolutionCost, I'm not sure 
it actually was so.

And to the aptitude maintainers. Getting a fix for this bug would be really 
nice, since it is stalling autobuilding in experimental.

/Sune
-- 
Man, how to log in the head?

You either should never disable the coaxial virus, or must overclock a LCD AGP 
provider, so that you neither have to digit from a MIDI submenu, nor can 
receive a BIOS over a password of the LCD connector on the hard disk and from 
ICQ and from the control panel inside Office 96 you need not to cancel the 
device of the gadget but you can never unmount the IRC software for booting a 
ethernet display to the server of a front-end to a mouse.


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

Bug#700530: qt frames empty

[Sune Vuorela]

So, after a lot of testing and involving like 10 different people there is now 
actually kind of a fix.

The fix is surprisingly in xorg-server and can be found here:
http://people.debian.org/~jcristau/kbsd-peercred.diff

having it real-life tested on linux and on kbsd on squeeze and wheezy/sid 
would be much appreciated. success reports go to me somehow.

Thanks to
Thiago Macieira, Andrey Rahmatullin, Julien Cristau, Pino Toscano, Bernhard R. 
Link and probably someone I forgotten.

/Sune
-- 
How may I insert the computer from Flash MX and from the options inside Office 
NT?

First of all from the control preferences menu within Word you must send to 
the device for debugging the controller over a analogic forward.


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

Bug#700677: Incorrect upstream versioning / ABI breakage

[Sune Vuorela]

On Saturday 16 February 2013 20:54:47 Daniel Baumann wrote:

 Shared libraries that are internal [...] are not subject to [these]
 requirements.

Internal libraries usually don't have a -dev package attached to them.

/Sune
-- 
Man, how can I save the printer?

From the drawer inside AutoCAD you must reset the floppy disk, so that from 
the control panel menu within Windows 6000 you neither have to reset a serial 
gadget of a graphic CD site, nor should ever install a controller on a 
wordprocessor over the POP monitor over a mouse in order to turn on the 8-inch 
pointer to the hardware.


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

Bug#699862: qt4-x11: FTBFS on x32: qatomic_generic.h doesn't work with QtDBus

[Sune Vuorela]

On Wednesday 06 February 2013 01:33:35 Daniel Schepler wrote:
 The qt4-x11 source package is getting this build failure on the
 unofficial x32 Debian port:

Hi Daniel. Thanks for the work on this. I do have a few questions though.

What's the Build key set to on x32?
|$ strings /usr/lib/i386-linux-gnu/libQtCore.so | grep g++

 I'm attaching a debdiff of the changes I used to port Qt (with the
 Debian changes) to x32.  (See also
 URL:https://sites.google.com/site/x32abi/x32-patches/Qt4_x32_config.patch?
 attredirects=0d=1 for a version of the patch meant for unpatched Qt.)

For some reason it seems to be using the i386 assembly code for atomics in 
that patch. Shouldn't it be using the x86_64 assembly code?

/Sune
-- 
Man, do you know how to close the provider from LinuxPPC or from Flash MX and 
from Word 8.2?

The point is that you neither must digit from a cache on a gadget, nor have to 
click on the Web address on the GUI for linking from the LCD tower over a LCD 
BIOS pointer to the mail.


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

Bug#696054: kdepim-runtime: Shouldn't ship the nepomuk feeders

[Sune Vuorela]

Package: kdepim-runtime
Version: 4:4.4.11.1-5
Severity: serious
Justification: Maintainer says so

kdepim-runtime should not ship the nepomuk feeder files.

To implement, just don't ship the 4 relevant files for nepomuk feeders.

This is a result of a discussion with upstream.

/Sune

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-3-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_DK.ISO-8859-15, LC_CTYPE=en_DK.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash

Versions of packages kdepim-runtime depends on:
ii  akonadi-server1.7.2-1
ii  kde-runtime   4:4.8.4-1
ii  kdepimlibs-kio-plugins4:4.8.4-1
ii  libakonadi-kabc4  4:4.8.4-1
ii  libakonadi-kcal4  4:4.8.4-1
ii  libakonadi-kde4   4:4.8.4-1
ii  libakonadi-kmime4 4:4.8.4-1
ii  libakonadiprotocolinternals1  1.7.2-1
ii  libc6 2.13-35
ii  libgcc1   1:4.7.1-6
ii  libkabc4  4:4.8.4-1
ii  libkcal4  4:4.8.4-1
ii  libkcalcore4  4:4.8.4-1
ii  libkcalutils4 4:4.8.4-1
ii  libkcmutils4  4:4.8.4-3
ii  libkdecore5   4:4.8.4-3
ii  libkdeui5 4:4.8.4-3
ii  libkimap4 4:4.8.4-1
ii  libkio5   4:4.8.4-3
ii  libkmime4 4:4.8.4-1
ii  libkpimutils4 4:4.8.4-1
ii  libkresources44:4.8.4-1
ii  libmailtransport4 4:4.8.4-1
ii  libmicroblog4 4:4.8.4-1
ii  libnepomuk4   4:4.8.4-3
ii  libqt4-dbus   4:4.8.2-2
ii  libqt4-network4:4.8.2-2
ii  libqt4-qt3support 4:4.8.2-2
ii  libqt4-xml4:4.8.2-2
ii  libqtcore44:4.8.2-2
ii  libqtgui4 4:4.8.2-2
ii  libsolid4 4:4.8.4-3
ii  libsoprano4   2.7.6+dfsg.1-1
ii  libstdc++64.7.1-6
ii  libstreamanalyzer00.7.7-3
ii  libxml2   2.8.0+dfsg1-5

kdepim-runtime recommends no packages.

kdepim-runtime suggests no packages.

-- no debconf information


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