Processed: [bts-link] source package kde-runtime
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package kde-runtime > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # https://bts-link-team.pages.debian.net/bts-link/ > # > user debian-bts-l...@lists.debian.org Setting user to debian-bts-l...@lists.debian.org (was debian-bts-l...@lists.debian.org). > # remote status report for #533831 (http://bugs.debian.org/533831) > # Bug title: /usr/bin/kde4: NumLock led behaves inversely if num lock is > turned on kde4 startup > # * http://bugs.kde.org/show_bug.cgi?id=183308 > # * remote status changed: NEEDSINFO -> RESOLVED > # * closed upstream > tags 533831 + fixed-upstream Bug #533831 [kdebase-runtime] /usr/bin/kde4: NumLock led behaves inversely if num lock is turned on kde4 startup Added tag(s) fixed-upstream. > usertags 533831 - status-NEEDSINFO Usertags were: status-NEEDSINFO resolution-UPSTREAM. Usertags are now: resolution-UPSTREAM. > usertags 533831 + status-RESOLVED Usertags were: resolution-UPSTREAM. Usertags are now: status-RESOLVED resolution-UPSTREAM. > thanks Stopping processing here. Please contact me if you need assistance. -- 533831: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=533831 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: [bts-link] source package meta-kde
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package meta-kde > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # https://bts-link-team.pages.debian.net/bts-link/ > # > user debian-bts-l...@lists.debian.org Setting user to debian-bts-l...@lists.debian.org (was debian-bts-l...@lists.debian.org). > # remote status report for #493069 (http://bugs.debian.org/493069) > # Bug title: kde-core: numlock led works inversely > # * http://bugs.kde.org/show_bug.cgi?id=183308 > # * remote status changed: NEEDSINFO -> RESOLVED > # * closed upstream > tags 493069 + fixed-upstream Bug #493069 [kde-full] kde-core: numlock led works inversely Added tag(s) fixed-upstream. > usertags 493069 - status-NEEDSINFO Usertags were: resolution-UPSTREAM status-NEEDSINFO. Usertags are now: resolution-UPSTREAM. > usertags 493069 + status-RESOLVED Usertags were: resolution-UPSTREAM. Usertags are now: resolution-UPSTREAM status-RESOLVED. > thanks Stopping processing here. Please contact me if you need assistance. -- 493069: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493069 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: [bts-link] source package src:kholidays
Processing commands for cont...@bugs.debian.org: > # > # bts-link upstream status pull for source package src:kholidays > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > # https://bts-link-team.pages.debian.net/bts-link/ > # > user debian-bts-l...@lists.debian.org Setting user to debian-bts-l...@lists.debian.org (was debian-bts-l...@lists.debian.org). > # remote status report for #908870 (http://bugs.debian.org/908870) > # Bug title: korganizer: Tuen Ng Festival date in 2019 is wrong > # * http://bugs.kde.org/show_bug.cgi?id=398670 > # * remote status changed: (?) -> RESOLVED > # * remote resolution changed: (?) -> FIXED > # * closed upstream > tags 908870 + fixed-upstream Bug #908870 [src:kholidays] korganizer: Tuen Ng Festival date in 2019 is wrong Added tag(s) fixed-upstream. > usertags 908870 + status-RESOLVED resolution-FIXED There were no usertags set. Usertags are now: resolution-FIXED status-RESOLVED. > thanks Stopping processing here. Please contact me if you need assistance. -- 908870: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908870 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: preparation of KDE PIM 18.08 started in experimental
Hi Sandro Am Mittwoch, 19. September 2018, 00:03:45 CEST schrieb Sandro Knauß: > Why it takes so long till a kdepim version is ready? Well there is not > enough manpower doing the packaging. Additionally I was busy with other > stuff outside the computer the last weeks to make the version ready and I > needed to wait for the ftp masters to approve the library renaming. > Currently I hope that I can request the transition of kdepim 18.08 within > that month. I missed a file move and need another review of the ftp > masters. I am also not happy that it takes that long, but kdepim is not the > easy part to package... No need to apologise in any way! Your work is really appreciated, keep it goin' ! (And kdepim is a really big beast to hunt. ;-) ) signature.asc Description: This is a digitally signed message part.
[bts-link] source package kde-runtime
# # bts-link upstream status pull for source package kde-runtime # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #533831 (http://bugs.debian.org/533831) # Bug title: /usr/bin/kde4: NumLock led behaves inversely if num lock is turned on kde4 startup # * http://bugs.kde.org/show_bug.cgi?id=183308 # * remote status changed: NEEDSINFO -> RESOLVED # * closed upstream tags 533831 + fixed-upstream usertags 533831 - status-NEEDSINFO usertags 533831 + status-RESOLVED thanks
security update for okular in Stretch
Hi everybody,
in case you are interested, this is the debdiff to fix CVE-2018-1000801
of okular in Stretch.
Thorsten
diff -Nru okular-16.08.2/debian/changelog okular-16.08.2/debian/changelog
--- okular-16.08.2/debian/changelog 2016-10-19 12:34:55.0 +0200
+++ okular-16.08.2/debian/changelog 2018-09-20 21:03:02.0 +0200
@@ -1,3 +1,12 @@
+okular (4:16.08.2-1+deb9u1) stretch-security; urgency=medium
+
+ * Non-maintainer upload by the LTS Team.
+ * CVE-2018-1000801
+Fix for a directory traversal vulnerability that can result in
+arbitrary file creation on the user workstation.
+
+ -- Thorsten Alteholz Thu, 20 Sep 2018 21:03:02 +0200
+
okular (4:16.08.2-1) unstable; urgency=medium
[ Automatic packaging ]
diff -Nru okular-16.08.2/debian/patches/CVE-2018-1000801.patch
okular-16.08.2/debian/patches/CVE-2018-1000801.patch
--- okular-16.08.2/debian/patches/CVE-2018-1000801.patch1970-01-01
01:00:00.0 +0100
+++ okular-16.08.2/debian/patches/CVE-2018-1000801.patch2018-09-20
21:03:02.0 +0200
@@ -0,0 +1,45 @@
+From 8ff7abc14d41906ad978b6bc67e69693863b9d47 Mon Sep 17 00:00:00 2001
+From: Albert Astals Cid
+Date: Mon, 3 Sep 2018 21:14:30 +0200
+Subject: Fix path traversal issue when extracting an .okular file
+
+Summary:
+With specially crafted .okular files you can trick okular to create temporary
files outside the temporary folder
+
+We fix that by making sure the file doesn't have folders since the ones we
create don't
+
+BUGS: 398096
+
+Subscribers: okular-devel
+
+Tags: #okular
+
+Differential Revision: https://phabricator.kde.org/D15192
+---
+ core/document.cpp | 12
+ 1 file changed, 12 insertions(+)
+
+Index: okular-16.08.2/core/document.cpp
+===
+--- okular-16.08.2.orig/core/document.cpp 2018-09-19 12:35:09.690099888
+0200
okular-16.08.2/core/document.cpp 2018-09-19 12:35:09.678099888 +0200
+@@ -4368,6 +4368,19 @@
+ return OpenError;
+
+ const KArchiveDirectory * mainDir = okularArchive.directory();
++
++// Check the archive doesn't have folders, we don't create them when
saving the archive
++// and folders mean paths and paths mean path traversal issues
++//original: for ( const QString : mainDir->entries() )
++Q_FOREACH ( const QString , mainDir->entries() )
++{
++if ( mainDir->entry( entry )->isDirectory() )
++{
++qWarning() << "Warning: Found a directory inside" << docFile << "
- Okular does not create files like that so it is most probably forged.";
++return OpenError;
++}
++}
++
+ const KArchiveEntry * mainEntry = mainDir->entry( "content.xml" );
+ if ( !mainEntry || !mainEntry->isFile() )
+ return OpenError;
diff -Nru okular-16.08.2/debian/patches/series
okular-16.08.2/debian/patches/series
--- okular-16.08.2/debian/patches/series2016-10-19 12:34:55.0
+0200
+++ okular-16.08.2/debian/patches/series2018-09-20 21:03:02.0
+0200
@@ -1 +1,2 @@
temporarily_disable_failing_test
+CVE-2018-1000801.patch
[bts-link] source package src:kholidays
# # bts-link upstream status pull for source package src:kholidays # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #908870 (http://bugs.debian.org/908870) # Bug title: korganizer: Tuen Ng Festival date in 2019 is wrong # * http://bugs.kde.org/show_bug.cgi?id=398670 # * remote status changed: (?) -> RESOLVED # * remote resolution changed: (?) -> FIXED # * closed upstream tags 908870 + fixed-upstream usertags 908870 + status-RESOLVED resolution-FIXED thanks
Re: preparation of KDE PIM 18.08 started in experimental
Lisandro Damián Nicanor Pérez Meyer - 20.09.18, 19:50: > El martes, 18 de septiembre de 2018 19:03:45 -03 Sandro Knauß > escribió: [snip] > > > Why it takes so long till a kdepim version is ready? Well there is > > not enough manpower doing the packaging. > > I would like to point out that while we do lack manpower in general, > kdepim is a *huge* beast currently mostly done by Sandro (I might be > missing some other people, but not more than two more persons not > fully advocated to the task, ie, they do maintain other stuff too). > > So kudos for Sandro in this, and yes, users will need to wait... or > jump in and help. Fully seconded. And extended to all of the wonderful Debian Qt/KDE team. You are doing awesome work. Thank you. -- Martin
[bts-link] source package meta-kde
# # bts-link upstream status pull for source package meta-kde # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # https://bts-link-team.pages.debian.net/bts-link/ # user debian-bts-l...@lists.debian.org # remote status report for #493069 (http://bugs.debian.org/493069) # Bug title: kde-core: numlock led works inversely # * http://bugs.kde.org/show_bug.cgi?id=183308 # * remote status changed: NEEDSINFO -> RESOLVED # * closed upstream tags 493069 + fixed-upstream usertags 493069 - status-NEEDSINFO usertags 493069 + status-RESOLVED thanks
Re: preparation of KDE PIM 18.08 started in experimental
Hallo, Am Donnerstag, 20. September 2018, 22:33:44 CEST schrieb Dietz Proepper: snip > > No need to apologise in any way! Your work is really appreciated, keep it > goin' ! Same here > > (And kdepim is a really big beast to hunt. ;-) ) But imho it is worth to be hunted... ... and tamed! -- Mit freundlichen Grüßen Matthias Müller (Benutzer #439779 im Linux-Counter http://counter.li.org) PS: Bitte senden Sie als Antwort auf meine E-Mails reine Text-Nachrichten! signature.asc Description: This is a digitally signed message part.
ktp-contact-list is marked for autoremoval from testing
ktp-contact-list 17.08.3-1 is marked for autoremoval from testing on 2018-10-07 It is affected by these RC bugs: 907231: ktp-contact-list: FTBFS with Qt 5.11
xdg-desktop-portal-gtk is installed when user specifies to install xdg-desktop-portal-kde with flatpak
Hi everyone. tl;dr; Should xdg-desktop-portal-kde provide xdg-deskop-portal-backend? A bug was reported against Ubuntu [0] from a KDE user, they tried to install flatpak on their machine. But when installing xdg-desktop- portal-gtk is installed rather than xdg-desktop-portal-kde - even if you specify xdg-desktop-portal-kde. >From my understanding of xdg-desktop-portal, one only needs a single backend installed - either the -gtk or -kde - depending which desktop environment they want the portals to feel integrated into. Assuming my understanding is correct, flatpak has a recommends line of "xdg-desktop-portal-gtk | xdg-desktop-portal-backend," [1]. So it appears that xdg-desktop-portal-kde should "provide" xdg-desktop- portal-backend ? xdg-desktop-portal-gtk already does this [2] but I cannot see this for -kde [3]. Would this then allow the user to install flatpak with xdg-desktop-portal-kde and without installing -gtk ? Thanks, Andrew 0 - https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal-kde/+b ug/1793473 1 - https://salsa.debian.org/debian/flatpak/blob/debian/master/debian/c ontrol#L72 2 - https://salsa.debian.org/debian/xdg-desktop-portal-gtk/blob/debian/ master/debian/control#L32 3 - https://salsa.debian.org/qt-kde-team/kde/xdg-desktop-portal-kde/blo b/master/debian/control
Re: xdg-desktop-portal-gtk is installed when user specifies to install xdg-desktop-portal-kde with flatpak
On Thu, 20 Sep 2018 at 22:23:37 +0100, Andrew Hayzen wrote: > tl;dr; Should xdg-desktop-portal-kde provide xdg-deskop-portal-backend? Presumably. If it's a valid implementation of the same interfaces as xdg-desktop-portal-gtk (installs /usr/share/xdg-desktop-portal/portals/*.portal listing various interfaces of the form org.freedesktop.impl.portal.Foo) then it should implement the virtual package. I was about to report a bug, but https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=890910 already exists. > From my understanding of xdg-desktop-portal, one only needs a single > backend installed - either the -gtk or -kde - depending which desktop > environment they want the portals to feel integrated into. Almost, although it isn't quite that simple. There are several interfaces that can be provided (FileChooser, Print, Screenshot and so on). For each one, xdg-desktop-portal tries to find the most appropriate backend: - the first backend in alphabetical order where UseIn matches XDG_CURRENT_DESKTOP (e.g. -gtk has UseIn=gnome) that provides the interface; - or if there is no matching backend, the first backend in alphabetical order that provides the interface So on KDE (assuming you have UseIn=kde, or plasma, or whatever KDE uses for XDG_CURRENT_DESKTOP) you'll generally get the -kde backend - unless there are (new?) interfaces that are only implemented in the -gtk backend, in which case you'll get the -gtk implementation of those interfaces (if -gtk is also installed) and the -kde implementation of the rest. -gtk is the default implementation of the virtual package, because it's basically the reference implementation (it's maintained by the same people as flatpak and the desktop-agnostic x-d-p frontend) and it should fit reasonably well into multiple desktop environments (GNOME, XFCE, LXDE and the various GNOME forks like MATE and Cinnamon). It should be harmless to have both -gtk and -kde installed, other than wasting an insignificant amount of disk space. I'd suggest giving KDE/Plasma desktop metapackages a Recommends on xdg-desktop-portal-kde to make sure most KDE users have that one available. > Would this then allow the user to > install flatpak with xdg-desktop-portal-kde and without installing -gtk > ? That's already possible - it's only a Recommends. However, having -kde provide the virtual package would make that configuration easier to achieve. smcv
Bug#908730: kmail: Query string stripped from hyperlinks in kmail
Dne pátek 14. září 2018 9:25:41 CEST jste napsal(a): > Vladislav Kurz wrote: > > Since upgrading to debian 9, I have a problem with emails form our > > helpdesk system. Links have query string with ticket id, or even action to > > do (take, resolve,...), but the query string is ignored. It seems that > > kmail is stripping it, perhaps as some sort of security feature. It would > > be nice to have them back, at least for whitelisted websites. I was not > > able to find any setting that would allow that. > > I don't think it's kmail that is stripping this (it works just fine for me > in stretch), but rather a setting for how to determine in what application > the URL should be opened. > > What do you have in > > K → System settings → Applications → Default Applications → Web Browser > > I suspect that you have that set to "in an application based on the contents > of the URL". That setting has kmail (or rather underlying libraries) fetch > the resource (or at least the HEAD) and then picks your browser for HTML, > okular for a PDF, gwenview for a JPG etc. Yes it was set as above. > The sequence is (roughly): > > * kmail asks www server for resource or metadata about the resource (I > assume it's a HEAD request, I've not checked) > > * in doing this look-up, various http redirects are followed > > * when kmail's libraries look at your helpdesk URL you are not authenticated > (even though you might be in your browser) > > * the helpdesk server helpfully redirects you to a login form > > * the login form is HTML > > * HTML is for a www browser so your browser is opened pointing to the > current URL which is a login form > > (I can replicate what you see with password protected resources where no > query string is involved, just a redirect to a login form) After I submitted the bug report I have noticed that the query string was not stripped for bugs.debian.org (which does not need any login) > Changing the aforementioned setting to "in the following browser" may be > sufficient. Yes, it has fixed the problem. Thank you very much for this hint. However I think that, even if it is not a bug in kmail, it should be made clear to users, that the default setting will cause problems on sites that need authentication. Or that when the browser is opened, it shall go to the link I have clicked and not on any redirects that kmail has found out by himself. I'm not sure how other apps behave in such case, if the behavior is specific to kmail, or provided by some common KDE library routine. In that case this bug should be reassigned appropriately. Cheers Vladki
Bug#909246: [powerdevil] powerdevil closed unexpectedly when resuming from suspend
Package: powerdevil Version: 4:5.13.5-1 Severity: important Distro: Debian Sid Issue: powerdevil closes unexpectedly when resuming from suspend. I get KDE org_kde_powedevil dialog to notify me about the crash. The following is in the developer information. Application: org_kde_powerdevil (org_kde_powerdevil), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fbfeb6ea840 (LWP 2337))] Thread 6 (Thread 0x7fbfdbfff700 (LWP 2464)): #0 0x7fbff35e0739 in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fbff12bfe46 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fbff12bff6c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fbff3af023b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fbff3a9d24b in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fbff38ec176 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fbff38f5d47 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7fbff261bf2a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7fbff35eaedf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 5 (Thread 0x7fbfe8a5d700 (LWP 2458)): #0 0x7fbff35e0739 in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fbff12bfe46 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fbff12bff6c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fbff3af023b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4 0x7fbff3a9d24b in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5 0x7fbff38ec176 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fbff38f5d47 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7fbff261bf2a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7fbff35eaedf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 4 (Thread 0x7fbfe94cf700 (LWP 2352)): #0 0x7fbff1306509 in g_mutex_lock () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7fbff12bf1e7 in g_main_context_prepare () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fbff12bfd7b in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fbff12c01d2 in g_main_loop_run () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fbfea0767b6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #5 0x7fbff12e8135 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x7fbff261bf2a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x7fbff35eaedf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 3 (Thread 0x7fbfe9cd0700 (LWP 2351)): #0 0x7fbff35dc204 in read () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fbff1305180 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fbff12bf91f in g_main_context_check () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fbff12bfdf0 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fbff12bff6c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fbff12bffb1 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x7fbff12e8135 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x7fbff261bf2a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #8 0x7fbff35eaedf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 2 (Thread 0x7fbfeac0f700 (LWP 2348)): #0 0x7fbff35dc204 in read () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7fbff1305180 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x7fbff12bf91f in g_main_context_check () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fbff12bfdf0 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fbff12bff6c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fbff3af023b in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7fbff3a9d24b in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7fbff38ec176 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x7fbff3d43545 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 #9 0x7fbff38f5d47 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x7fbff261bf2a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #11 0x7fbff35eaedf in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 1 (Thread 0x7fbfeb6ea840 (LWP 2337)): [KCrash Handler] #6 0x7fbff4a596ff in PowerDevil::Core::onResumingFromIdle() () from /usr/lib/x86_64-linux-gnu/libpowerdevilcore.so.2 #7
Re: preparation of KDE PIM 18.08 started in experimental
El martes, 18 de septiembre de 2018 19:03:45 -03 Sandro Knauß escribió: [snip] > Why it takes so long till a kdepim version is ready? Well there is not > enough manpower doing the packaging. I would like to point out that while we do lack manpower in general, kdepim is a *huge* beast currently mostly done by Sandro (I might be missing some other people, but not more than two more persons not fully advocated to the task, ie, they do maintain other stuff too). So kudos for Sandro in this, and yes, users will need to wait... or jump in and help. -- May the source be with you. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part.
