Bug#1081171: ITP: kweathercore -- Library to facilitate retrieval of weather information
Package: wnpp Severity: wishlist Owner: Hefee X-Debbugs-Cc: debian-de...@lists.debian.org, debian-qt-kde@lists.debian.org, he...@debian.org * Package name: kweathercore Version : 24.08.0 Upstream Contact: KDE Community * URL : https://invent.kde.org/libraries/kweathercore * License : LGPL-2+ Programming Lang: C++, QT Description : Library forretrieval of weather information Get weather forecast and alerts anywhere on the earth easy. It provides you a highly abstracted library for things related to weather. . Features: * Get local weather forecast. * Get weather of a location by name or coordinate. * Weather alerts of a country. The library is needed for KWeather, that I'll want packackage too and is actually the aim for packaging it. Actually more KDE software may start using it. KWeather is part of the plasma-mobile-desktop. It will be maintained by the Qt/KDE Debian team (debian-de...@lists.debian.org).
Bug#1081180: ITP: kweather -- Weather application for Plasma
Package: wnpp Severity: wishlist Owner: Hefee X-Debbugs-Cc: debian-de...@lists.debian.org, debian-qt-kde@lists.debian.org, he...@debian.org Control: block -1 with 1081171 * Package name: kweather Version : 24.8.0 Upstream Contact: KDE Community * URL : https://invent.kde.org/utilities/kweather * License : GPL-2+ Programming Lang: C++, Qt, QML Description : Weather application for Plasma A convergent weather application for Plasma. Has flat and dynamic/animated views for showing dailiy or hourly forecasts and other information. KWeather is part of the plasma-mobile-desktop. It will be maintained by the Qt/KDE Debian team (debian-de...@lists.debian.org).
Bug#1007743: kldap: BD-Uninstallable on s390x
Control: reassign -1 qtkeychain/0.13.2-4 Control: affects -1 kldap Control: tags -1 +patch That is more an issue of qtkeychain than of kldap ;) Qtkeychain does not build on s390x because of misssing Qt6 for s390x: https://tracker.debian.org/pkg/qtkeychain Ubuntu has already the needed patches to disable Qt6 for s390x: https://patches.ubuntu.com/q/qtkeychain/qtkeychain_0.13.2-4ubuntu1.patch So it should be easy to adopt it for Debian. hefee On Dienstag, 15. März 2022 23:20:32 CET Sebastian Ramacher wrote: > Source: kldap > Version: 21.08.1-1 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the > past) > > > kldap build-depends on missing: > - qt5keychain-dev:s390x > > Please get this fixed or request the removal of the s390x binaries of > kldap. > > Cheers signature.asc Description: This is a digitally signed message part.
Bug#1033383: unblock: itinerary/22.12.3-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: itiner...@packages.debian.org, debian-qt-kde@lists.debian.org, he...@debian.org Control: affects -1 + src:itinerary Please unblock package itinerary [ Reason ] The new version is only a small bugfix of itinerary and several updates of supported translations. So the only relevant change in code are two lines in src/app/localizer.cpp to show timezone information, if we are currently not in UTC. and one line in src/app/JourneySectionStopDelegate.qml to shorten long stop names in journey section view. Additionally I updated the list of all runtime QML depedencies to fix #1032889, that is the most relevant change to request the unblock request. [ Tests ] as the code fixes are only cosmetic, there are no special autotests and nothing big can break. I use itinerary myself so I can tell the app is still running. [ Risks ] trival changes / only a leaf package. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock itinerary/22.12.3-1
Bug#1034561: akonadi-server: Switch default Akonadi backend to SQLite
Package: akonadi-server Version: 4:22.12.3-1 Severity: normal X-Debbugs-Cc: he...@debian.org Hey, Upstream has changed their support for akonadi backends. Nowadays they recommend to use SQLite, Postgres and MySQL/MariaDB is not really recommend anymore. So we should change the Depends line for akonadi-server, after bullseye has been released. -- Forwarded Message -- Subject: Re: Is SQLite3 still not recommended? Date: Tuesday, 4. April 2023, 09:25:31 CEST Link: https://mail.kde.org/pipermail/kde-pim/2023-April/049426.html Hi, I think SQLite is a good choice these days. SQLite has made huge progress in the past many years since its support has been introduced to Akonadi. The documentation on wiki is certainly not up-to-date. While I was a big advocate for pushing PostgreSQL as the default backend for Akonadi in the past, I think nowadays going for anything else than SQLite as the default backend is silly. Especially with today's fast SSD drives, I don't think a regular user will notice any difference, it might actually turn out to be the fastest solution overall. Coincidentally, I recently learned that the SQLite shared cache mode, which Akonadi uses, has been deprecated for a while and WAL mode is now recommended for most usecases, so that's something to look into. There might be more new features in SQLite that have been introduced in the past years that Akonadi could leverage for better performance.
Bug#969171: Again, not even looked at the real problem.
Hey, On Sonntag, 11. April 2021 20:18:51 CEST Eric Valette wrote: > > I think it is not a bug of the package. But it is definitely not severity > > grave as Akonadi is perfectly usable here in exact the same version > > (usable to the extent Akonadi works reliable, but that is an upstream > > issue). So downgrading severity to normal. > > When only akonadi-backend-sqlite is installed as you can see in > installed packages I find normal that the default config file is changed > to use sqlite by default as I would expect that removing > akonadi-backend-mysql would remove the mysql backend if it was used with > a warning. > > But apparently, you are more interested in having the package without > bug than working to simplify your user's life. We see this as a bug, too. Otherwise we would close this bug as invalid ;) Debian can't easily distinguish, if you only installed one backend or differnt ones. Well we could add logic to detect this, but that would be very error prune. So the proper solution needs to be done upstream aka in Akonadi directly. Akonadi has no support to check what different backends are available but simply try to start mysql. And if you tried it once, than Akonadi has created a user config that selects the mysql database and it is outside our control to switch the backend. Because Debian packages are not allowed to touch any stuff in $HOME. Never the less in future for trixie the situation needs to be improved, as Akonadi switched its default backend over to SQLite (see #1034561). Detecting available backends is becoming a bigger issue. Any help from your side to fix the problem is highly welcome: merge request, upstream bug report, patch etc. Unfortunately the Debian maintainers team is a lot of work and not enough resources, to do all work. Regards, hefee #1034561: https://bugs.debian.org/1034561 signature.asc Description: This is a digitally signed message part.
Bug#924788: /usr/bin/akonadictl: aKonadi server with postgreSQL backend fails to start after buster upgrade
Control: tags -1 +moreinfo unreproducible Hey, Sorry that I haven't found time to look to it further. >From the file list it seems like you switched to from PostgresQL backend to Mysql backend by dist-upgrade and than started it. That removed all of the postgres cluster. Maybe the config that selected the PostgresQL was removed while the upgrade? I need more information in order to fix anything. > I expect that aKonadi should be using postgreSQL 11, not 9.6, but that it > will auto-migrate my data. I don't know when this support was added to Akonadi, but bookworm will support for sure automatic upgrades to new PostgresQL versions. Regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1035056: [pre-approval] plasma-desktop 5.27.X
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: plasma-desk...@packages.debian.org, pkg-kde-talk%40alioth-lists.debian.net, he...@debian.org Control: affects -1 + src:plasma-desktop Hey, before invest time, to do the debdiff and all paperwork for Plasma 5.27.X LTS packages, there's need to be a idea, how to get it into stable. Currently 5.27.3 on experimental. Upstream is relasing with a fibbonacci time frame, when stable will be release, we would be at ~5.27.5. I wanted to ask, if we find a solution together to get the new version into bookworm. Upstream wants to give bugfix releases over 2 years. Plasma 5.27 is a LTS branch, that is stable and only bug fixes with be released with next minor versions. No transitions nor API changes. By the time the most bug fixes are around multi screen support. From my point of view users would definitly benefit from these updates with no negative effect. Alternatives: * Using backport is not an option, because upstream is switching to Plasma 6 (based on Qt6), that will enter in sid soon after bookworm has released. * extract all bugfixes from Plasma 5.27.X and apply them as patches on top and remove the version bump. In the end it is a lot more work on our plate, with no benefit for users. Upstream has much more problems to understand, that Debian has all bugfixes included. It is the first time we the KDE manatiner are in this lucky situation that we can use the LTS releases from upstream. I hope we will find a good solution together to make the user experince better and not put a lot of work on yours/ours plate. The NACK on #1033271 made part of the team quite unmotivated to try it for Plasma. See the mail thread [1] Regards, hefee Plasma is ~50 pacakges - see a list of packages: https://salsa.debian.org/qt-kde-team/pkg-kde-dev-scripts/-/blob/master/tierdata/plasma.5.25.0.tier.sh [1] https://alioth-lists.debian.net/pipermail/pkg-kde-talk/2023-April/003467.html
Bug#906693: akonadi-server: Akonadi waits to short for password
Control: tags -1 +moreinfo unreproducible Hey, Sorry that I haven't found time to look to it further. Well times runs and we already have 20.8 version on current stable additionally upstream has moved from direct KWallet support to use QtKeychain so also support other key storages. So it is a good time to retest it again, if it is still an issue. Myself hasn't seen this issue for several years. Regards, hefee -- On Sonntag, 19. August 2018 20:57:07 CEST Valentin Petzel wrote: > Package: akonadi-server > Version: 4:17.12.3-3 > Severity: normal > > Dear Maintainer, > > When establishing a connection to an account, where the password is > stored in KWallet, Akonadi prompts the password apparently if it doesn't > respond for some time. This is set so short that on login one is often > prompted for the e-Mail accounts' passwords before one has the chance to > enter the password for KWallet's encryption. You might want to consider > increasing the time Akonadi waits for the passwords. > > -- System Information: > Debian Release: buster/sid > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, > 'oldstable-proposed-updates'), (500, 'unstable'), (500, 'oldstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.11-towo.2-siduction-amd64 (SMP w/4 CPU cores; PREEMPT) > Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de > (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages akonadi-server depends on: > ii akonadi-backend-mysql 4:17.12.3-3 > ii akonadi-backend-sqlite 4:17.12.3-3 > ii libc6 2.27-5 > ii libgcc11:8.2.0-2 > ii libkf5akonadiprivate5abi1 4:17.12.3-3 > ii libkf5akonadiwidgets5abi1 4:17.12.3-3 > ii libkf5configcore5 5.47.0-1 > ii libkf5coreaddons5 5.47.0-1 > ii libkf5crash5 5.47.0-1 > ii libkf5i18n55.47.0-1 > ii libqt5core5a 5.11.1+dfsg-6 > ii libqt5dbus55.11.1+dfsg-6 > ii libqt5gui5 5.11.1+dfsg-6 > ii libqt5network5 5.11.1+dfsg-6 > ii libqt5sql5 5.11.1+dfsg-6 > ii libqt5widgets5 5.11.1+dfsg-6 > ii libqt5xml5 5.11.1+dfsg-6 > ii libstdc++6 8.2.0-2 > > akonadi-server recommends no packages. > > Versions of packages akonadi-server suggests: > ii akonadi-backend-mysql 4:17.12.3-3 > pn akonadi-backend-postgresql > ii akonadi-backend-sqlite 4:17.12.3-3 > > -- no debconf information signature.asc Description: This is a digitally signed message part.
Bug#1008885: loops endlessly about (failed?) mariadb start
Control: tags -1 moreinfo
Hi,
About the loop: I never seen that before - It normally just fails and than not
try again to start up again. It maybe related with systemd integration of
Plasma. Or do you have any special autostart scripts? And with the newer
versions the wayland support got better, so maybe the issue is solved in
meanwhile?
if you don't use any Akonadi feature and don't want to remove meta-packages. I
would suggest to use akonadi-backend-sqlite and remove the mysql one.
Unfortunatelly you really need to modify your akonadiserverrc config. That at
least should make it start more easily. See the blog entry:
https://euroquis.nl//freebsd/2023/04/24/akonadi.html
Regards,
hefee
On Sonntag, 3. April 2022 13:57:05 CEST Marc Haber wrote:
> Package: akonadi-server
> Version: 4:21.12.3-2
> Severity: normal
>
> Hi,
>
> to see whether KDE Wayland works better when started via gdm3 instead of
> sddm (spoiler: No, same way of broken as with sddm), I exchanged sddm
> with gdm3. After going back to KDE X11 Session, I found my log being
> spammed with the following pattern, repeated endlessly:
>
> Apr 3 13:33:47 fan /usr/libexec/gdm-x-session[723825]:
> org.kde.pim.akonadiserver: Starting up the Akonadi Server... Apr 3
> 13:33:47 fan /usr/libexec/gdm-x-session[723821]:
> org.kde.pim.akonadicontrol: Service org.freedesktop.Akonadi.Control.lock
> already registered, terminating now. Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: database
> server stopped unexpectedly Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: Database
> process exited unexpectedly during initial connection! Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: executable:
> "/usr/sbin/mysqld" Apr 3 13:33:52 fan /usr/libexec/gdm-x-session[723825]:
> org.kde.pim.akonadiserver: arguments:
> ("--defaults-file=/home/mh/.local/share/akonadi/mysql.conf",
> "--datadir=/home/mh/.local/share/akonadi/db_data/",
> "--socket=/run/user/1001/akonadi/mysql.socket",
> "--pid-file=/run/user/1001/akonadi/mysql.pid") Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: stdout: ""
> Apr 3 13:33:52 fan /usr/libexec/gdm-x-session[723825]:
> org.kde.pim.akonadiserver: stderr: "2022-04-03 13:33:47 0 [Note]
> /usr/sbin/mysqld (server 10.6.7-MariaDB-3) starting as process 723831
> ...\n" Apr 3 13:33:52 fan /usr/libexec/gdm-x-session[723825]:
> org.kde.pim.akonadiserver: exit code: 1 Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: process
> error: "Unknown error" Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723825]: org.kde.pim.akonadiserver: Shutting
> down AkonadiServer... Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723819]: org.kde.pim.akonadicontrol: Application
> '/usr/bin/akonadiserver' exited normally... Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[716950]: qt.qpa.xcb: QXcbConnection: XCB error:
> 3 (BadWindow), sequence: 58290, resource id: 67108869, major code: 18
> (ChangeProperty), minor code: 0 Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723843]: Connecting to deprecated signal
> QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) Apr
> 3 13:33:52 fan /usr/libexec/gdm-x-session[723845]:
> org.kde.pim.akonadicontrol: Service org.freedesktop.Akonadi.Control.lock
> already registered, terminating now. Apr 3 13:33:52 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: Starting up
> the Akonadi Server... Apr 3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: database
> server stopped unexpectedly Apr 3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: Database
> process exited unexpectedly during initial connection! Apr 3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: executable:
> "/usr/sbin/mysqld" Apr 3 13:33:57 fan /usr/libexec/gdm-x-session[723849]:
> org.kde.pim.akonadiserver: arguments:
> ("--defaults-file=/home/mh/.local/share/akonadi/mysql.conf",
> "--datadir=/home/mh/.local/share/akonadi/db_data/",
> "--socket=/run/user/1001/akonadi/mysql.socket",
> "--pid-file=/run/user/1001/akonadi/mysql.pid") Apr 3 13:33:57 fan
> /usr/libexec/gdm-x-session[723849]: org.kde.pim.akonadiserver: stdout: ""
> Apr 3 13:33:57 fan /usr/libexec/gdm-x-session[723849]:
> org.kde.pim.akonadiserver: stderr: "2022-04-03 13:33:52 0 [Note]
> /usr/sbin/mysqld (server 10.6.7-MariaDB-3) starting as process 723855
> ...\n" Apr 3 13:33:57 fan /usr/libexec/gdm-x-session[723849
Bug#998325: akonadi-server: akonadi_indexing_agent crashes when kmail is active
Control: tags -1 +moreinfo Hey, that is properly a email, that triggers the indexer to crash. To get more details please install libkf5akonadisearchpim5-dbgsym to get a propper backtrace. Additionally, run akonadi with debug logging enabled: QT_LOGGING_RULES="*.debug=true;qt.*=false" akonadictl restart that should points you to the mail, that triggers this crash. Regards, hefee -- On Dienstag, 2. November 2021 13:44:03 CEST Hans-J. Ullrich wrote: > Package: akonadi-server > Version: 4:20.08.3-3 > Severity: important > > Dear Maintainer, > > I hope, this is the right package. I have the following problem with akonadi > on debian/bullseye, amd64. > > Problem: When I start kmail, then akoandi is crashing with the message, > "akonadi_indexing_agent is crashed" > > This is the output of the error: > > snip - > > > Application: akonadi_indexing_agent (akonadi_indexing_agent), signal: > Aborted > > [KCrash Handler] > #4 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 > #5 0x7f5ad974f537 in __GI_abort () at abort.c:79 > #6 0x7f5ad99a57ec in () at /lib/x86_64-linux-gnu/libstdc++.so.6 > #7 0x7f5ad99b0966 in () at /lib/x86_64-linux-gnu/libstdc++.so.6 > #8 0x7f5ad99b09d1 in () at /lib/x86_64-linux-gnu/libstdc++.so.6 > #9 0x7f5ad99b0c65 in () at /lib/x86_64-linux-gnu/libstdc++.so.6 > #10 0x7f5adb19bd0f in () at /lib/x86_64-linux-gnu/libxapian.so.30 > #11 0x7f5adb2516be in () at /lib/x86_64-linux-gnu/libxapian.so.30 > #12 0x7f5adb2517e2 in () at /lib/x86_64-linux-gnu/libxapian.so.30 > #13 0x7f5adb252e0c in () at /lib/x86_64-linux-gnu/libxapian.so.30 > #14 0x7f5adb23d7c9 in () at /lib/x86_64-linux-gnu/libxapian.so.30 > #15 0x7f5adb1b2101 in () at /lib/x86_64-linux-gnu/libxapian.so.30 > #16 0x7f5adb2b1140 in () at /lib/x86_64-linux-gnu/libxapian.so.30 > #17 0x7f5adb1c2fd8 in Xapian::Enquire::Internal::get_mset(unsigned int, > unsigned int, unsigned int, Xapian::RSet const*, Xapian::MatchDecider > const*) const () at /lib/x86_64-linux-gnu/libxapian.so.30 #18 > 0x7f5adb1c3245 in Xapian::Enquire::get_mset(unsigned int, unsigned int, > unsigned int, Xapian::RSet const*, Xapian::MatchDecider const*) const () at > /lib/x86_64-linux-gnu/libxapian.so.30 #19 0x7f5adb3be231 in () at > /lib/x86_64-linux-gnu/libKF5AkonadiSearchPIM.so.5 #20 0x7f5adb3be611 in > () at /lib/x86_64-linux-gnu/libKF5AkonadiSearchPIM.so.5 #21 > 0x55ebc1bd976a in () > #22 0x7f5ad9dbc5a6 in () at /lib/x86_64-linux-gnu/libQt5Core.so.5 > #23 0x7f5ada7aed29 in KJob::finished(KJob*, KJob::QPrivateSignal) () at > /lib/x86_64-linux-gnu/libKF5CoreAddons.so.5 #24 0x7f5ada7af97c in > KJob::finishJob(bool) () at /lib/x86_64-linux-gnu/libKF5CoreAddons.so.5 #25 > 0x7f5ad9db1ff1 in QObject::event(QEvent*) () at > /lib/x86_64-linux-gnu/libQt5Core.so.5 #26 0x7f5ada96b15f in > QApplicationPrivate::notify_helper(QObject*, QEvent*) () at > /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #27 0x7f5ad9d85fca in > QCoreApplication::notifyInternal2(QObject*, QEvent*) () at > /lib/x86_64-linux-gnu/libQt5Core.so.5 #28 0x7f5ad9d88a01 in > QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () > at /lib/x86_64-linux-gnu/libQt5Core.so.5 #29 0x7f5ad9ddde93 in () at > /lib/x86_64-linux-gnu/libQt5Core.so.5 #30 0x7f5ad83f1e6b in > g_main_context_dispatch () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #31 > 0x7f5ad83f2118 in () at /lib/x86_64-linux-gnu/libglib-2.0.so.0 #32 > 0x7f5ad83f21cf in g_main_context_iteration () at > /lib/x86_64-linux-gnu/libglib-2.0.so.0 #33 0x7f5ad9ddd51f in > QEventDispatcherGlib::processEvents(QFlags) > () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #34 0x7f5ad9d8498b in > QEventLoop::exec(QFlags) () at > /lib/x86_64-linux-gnu/libQt5Core.so.5 #35 0x7f5ad9d8cc00 in > QCoreApplication::exec() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #36 > 0x55ebc1bc8ca8 in () > #37 0x7f5ad9750d0a in __libc_start_main (main=0x55ebc1bc3090, argc=3, > argv=0x7ffccce092a8, init=, fini=, > rtld_fini=, stack_end=0x7ffccce09298) at > ../csu/libc-start.c:308 #38 0x55ebc1bc30ca in () > [Inferior 1 (process 12884) detached] > > > snap > > Restarting akonadi-server and mysql does not help. Dunno, if this has > something to do with it, but this appeared after the last upgrade of > openjdk (however, it is not clear for me, that openjdk should cause this > issue, maybe it is just a coincidence. > > Hope, this mails does help though. > > Best regards > > Hans > > > -- System Information: > Debian Release: 11.1 > APT prefers stable-updates > APT policy: (500, 'sta
Bug#1035593: unblock: kwin/4:5.27.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: k...@packages.debian.org, he...@debian.org
Control: affects -1 + src:kwin
Please unblock package kwin
[ Reason ]
Fix 1033212. For limba phones kwin is not usable at all, with that fix
it is usable again.
[ Impact ]
Plasma mobile is not usable on limba phones.
[ Tests ]
Marco Mattiolo, the author of the patch for kwin, tested it on their
devices.
[ Risks ]
The patch is very simple and straightforward. For me it seems not very
likly that it has bad outcome for other users. On experimental there is
also kwin 5.27.3 with that patch included and that is also tested be a
bunch of people.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
You do a great work and you are very fast responding ;)
unblock kwin/4:5.27.2-2
diff -Nru kwin-5.27.2/debian/changelog kwin-5.27.2/debian/changelog
--- kwin-5.27.2/debian/changelog2023-02-28 15:01:10.0 +0100
+++ kwin-5.27.2/debian/changelog2023-05-05 14:22:35.0 +0200
@@ -1,3 +1,12 @@
+kwin (4:5.27.2-2) unstable; urgency=medium
+
+ * Team upload.
+
+ [ Marco Mattiolo ]
+ * Backport patch to fix kwin for Lima (Pinephone) (Closes: #1033212)
+
+ -- Sandro Knauß Fri, 05 May 2023 14:22:35 +0200
+
kwin (4:5.27.2-1) unstable; urgency=medium
[ Aurélien COUDERC ]
diff -Nru kwin-5.27.2/debian/patches/fix-for-Lima-disabling-GLSL.patch
kwin-5.27.2/debian/patches/fix-for-Lima-disabling-GLSL.patch
--- kwin-5.27.2/debian/patches/fix-for-Lima-disabling-GLSL.patch
1970-01-01 01:00:00.0 +0100
+++ kwin-5.27.2/debian/patches/fix-for-Lima-disabling-GLSL.patch
2023-05-05 14:16:46.0 +0200
@@ -0,0 +1,47 @@
+From 64d682a646d111a0250bbe3bff77ef0cead91403 Mon Sep 17 00:00:00 2001
+From: Hannah Kiekens
+Date: Tue, 28 Feb 2023 21:04:37 +
+Subject: [PATCH] Enable GLSL for Mali (Lima) / PinePhone devices
+
+Commit 88cf8355 changed the behaviour of Mali (Lima) / PinePhone devices by
disabling GLSL
+88cf8355 got backported in 5.27.1 and broke PinePhone devices (White rectangle
on topright quarter of a black screen)
+
+This patch restores the behaviour of 5.27.0
+
+
+(cherry picked from commit 0543949df709c69c99c46c9abad483250b01c288)
+---
+ .../libkwineffects/data/glplatform/lima-mali400-desktop-3.0| 2 +-
+ src/libkwineffects/kwinglplatform.cpp | 3 +--
+ 2 files changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/autotests/libkwineffects/data/glplatform/lima-mali400-desktop-3.0
b/autotests/libkwineffects/data/glplatform/lima-mali400-desktop-3.0
+index 8e32a85af81..cf83810fd8b 100644
+--- a/autotests/libkwineffects/data/glplatform/lima-mali400-desktop-3.0
b/autotests/libkwineffects/data/glplatform/lima-mali400-desktop-3.0
+@@ -6,7 +6,7 @@ ShadingLanguageVersion=1.30
+
+ [Settings]
+ LooseBinding=true
+-GLSL=false
++GLSL=true
+ TextureNPOT=true
+ Mesa=true
+ Lima=true
+diff --git a/src/libkwineffects/kwinglplatform.cpp
b/src/libkwineffects/kwinglplatform.cpp
+index 82554ca755b..aa0f5b105a5 100644
+--- a/src/libkwineffects/kwinglplatform.cpp
b/src/libkwineffects/kwinglplatform.cpp
+@@ -1138,8 +1138,7 @@ void GLPlatform::detect(OpenGLPlatformInterface
platformInterface)
+
+ if (isLima()) {
+ m_recommendedCompositor = OpenGLCompositing;
+-// GLSL works but causes dramatic FPS drop on this GPU
+-m_supportsGLSL = false;
++m_supportsGLSL = true;
+ }
+
+ if (isVideoCore4()) {
+--
+GitLab
+
diff -Nru kwin-5.27.2/debian/patches/series kwin-5.27.2/debian/patches/series
--- kwin-5.27.2/debian/patches/series 2022-10-02 18:15:15.0 +0200
+++ kwin-5.27.2/debian/patches/series 2023-05-05 14:16:46.0 +0200
@@ -1 +1,2 @@
uninitialized-yuvformat.patch
+fix-for-Lima-disabling-GLSL.patch
Bug#1040180: bookworm-pu: package kf5-messagelib/22.12.3-2~deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: kf5-message...@packages.debian.org, he...@debian.org
Control: affects -1 + src:kf5-messagelib
[ Reason ]
KMail does can't verify signatures if they are signed with subkeys.
[ Impact ]
Users will see an invalid signature instead of a valid one.
[ Tests ]
Same package is on unstable for some days without any issue.
I also run KMail on a daily basis.
[ Risks ]
The patch is quite small and is a direct patch from upstream. It is very
unlikly that this has side effects.
[ Checklist ]
[*] *all* changes are documented in the d/changelog
[*] I reviewed all changes and I approve them
[*] attach debdiff against the package in bookworm
[*] the issue is verified as fixed in unstable
diff -Nru kf5-messagelib-22.12.3/debian/changelog
kf5-messagelib-22.12.3/debian/changelog
--- kf5-messagelib-22.12.3/debian/changelog 2023-03-01 21:33:30.0
+0100
+++ kf5-messagelib-22.12.3/debian/changelog 2023-07-02 23:21:13.0
+0200
@@ -1,3 +1,15 @@
+kf5-messagelib (4:22.12.3-2~deb12u1) bookworm; urgency=medium
+
+ * Rebuilt for bookworm.
+
+ -- Sandro Knauß Sun, 02 Jul 2023 23:21:13 +0200
+
+kf5-messagelib (4:22.12.3-2) unstable; urgency=medium
+
+ * Add upstream patch to search also for subkeys (Closes: #1037363).
+
+ -- Sandro Knauß Tue, 27 Jun 2023 14:09:30 +0200
+
kf5-messagelib (4:22.12.3-1) unstable; urgency=medium
[ Patrick Franz ]
diff -Nru kf5-messagelib-22.12.3/debian/patches/series
kf5-messagelib-22.12.3/debian/patches/series
--- kf5-messagelib-22.12.3/debian/patches/series2022-12-20
01:37:29.0 +0100
+++ kf5-messagelib-22.12.3/debian/patches/series2023-06-27
13:33:50.0 +0200
@@ -1 +1,2 @@
enable_debianabimanager.diff
+upstream-Look-for-matching-subkey-if-no-key-was-found-for-fin.patch
diff -Nru
kf5-messagelib-22.12.3/debian/patches/upstream-Look-for-matching-subkey-if-no-key-was-found-for-fin.patch
kf5-messagelib-22.12.3/debian/patches/upstream-Look-for-matching-subkey-if-no-key-was-found-for-fin.patch
---
kf5-messagelib-22.12.3/debian/patches/upstream-Look-for-matching-subkey-if-no-key-was-found-for-fin.patch
1970-01-01 01:00:00.0 +0100
+++
kf5-messagelib-22.12.3/debian/patches/upstream-Look-for-matching-subkey-if-no-key-was-found-for-fin.patch
2023-06-27 13:34:36.0 +0200
@@ -0,0 +1,44 @@
+From 70f39256784280d2034aa7bf1c4765f606c22d56 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ingo=20Kl=C3=B6cker?=
+Date: Wed, 3 May 2023 14:51:18 +0200
+Subject: Look for matching subkey if no key was found for fingerprint
+
+If the message was signed with a signing subkey instead of with the
+primary key of an OpenPGP certificate, then we won't find a key with
+findByFingerprint(). To look for a matching subkey we need to use
+findSubkeysByKeyID().
+
+FIXED-IN: 5.23.1
+BUG: 469304
+(cherry picked from commit 606ea1478d2d5b5aacdc6ef3f050655fe0352d87)
+---
+ mimetreeparser/src/messagepart.cpp | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+diff --git a/mimetreeparser/src/messagepart.cpp
b/mimetreeparser/src/messagepart.cpp
+index f1489d5e0..3e99e71c8 100644
+--- a/mimetreeparser/src/messagepart.cpp
b/mimetreeparser/src/messagepart.cpp
+@@ -848,8 +848,18 @@ void SignedMessagePart::sigStatusToMetaData()
+ // Search for the key by its fingerprint so that we can check for
+ // trust etc.
+ key =
Kleo::KeyCache::instance()->findByFingerprint(signature.fingerprint());
++if (key.isNull() && signature.fingerprint()) {
++// try to find a subkey that was used for signing;
++// assumes that the key ID is the last 16 characters of the
fingerprint
++const auto fpr = std::string_view{signature.fingerprint()};
++const auto keyID = std::string{fpr, fpr.size() - 16, 16};
++const auto subkeys =
Kleo::KeyCache::instance()->findSubkeysByKeyID({keyID});
++if (subkeys.size() > 0) {
++key = subkeys[0].parent();
++}
++}
+ if (key.isNull()) {
+-qCDebug(MIMETREEPARSER_LOG) << "Found no Key for Fingerprint"
<< signature.fingerprint();
++qCDebug(MIMETREEPARSER_LOG) << "Found no key or subkey for
fingerprint" << signature.fingerprint();
+ }
+ }
+
+--
+2.40.1
+
Bug#930168: Confirming the bug on Debian
I can confim the same behaviour on current Debian sid and I found a working solution for me. In the end it was an issue outside discover. appstream data update was disabled, I proplery did that because the files are that big. I sill could search apps via appstream, so I thought that is not the root issue. $ appstreamcli search kate Identifier: org.kde.kate.desktop [desktop-application] [...] So appstream was already installed and working. Steps I needed to do to list apps within discover: rename /etc/apt/apt.conf.d/#50appstream to /etc/apt/apt.conf.d/50appstream apt update That was all. So for others it is a good idea to check: * can I search apps vis appstream ( appstreamcli search kate ) * does the update command is successfull ( appstreamcli refresh --source=os); or the command that is triggered by /etc/apt/apt.conf.d/50appstream) * is /var/cache/swcatalog populated and writeable that at least should clearify the issue even more. regards, hefee On Mittwoch, 12. Juni 2019 01:07:03 CEST Alexander Kernozhitsky wrote: > I also encounter this bug on Debian Buster. > > But I manually disabled all the AppStream and DEP-11 metadata from apt > configs, so this may be the reason. > > Can anyone reproduce this on a clean system? signature.asc Description: This is a digitally signed message part.
Bug#1078918: libplasma5support6: Clock applet don't work module "org.kde.plasma.plasma5support" is not installed
Control: reassign plasma-workspace-data/4:6.1.4-2 Hi, that is fixed already in the salsa and the fix will be uploaded with the next version of plasma-workspace-data. The missing package is the qml binding of libplasma5support6, but this will not be installed automatically with libplasma5support6 but it needs to be the dependency of plsama-workspace-data. The package you need to install to fix that is: qml6-module-org-kde-plasma-plasma5support Regards, hefee -- On Samstag, 17. August 2024 19:21:34 CEST m...@gallifrey-blr.fr wrote: > Hi > > After some test, other applet don't work with the message : > module "org.kde.plasma.plasma5support" is not installed > > clipboard: > file:///usr/share/plasma/plasmoids/org.kde.plasma.clipboard/contents/ui/main > .qml:14:1: module "org.kde.plasma.plasma5support" is not installed > kscreen: > file:///usr/share/plasma/plasmoids/org.kde.kscreen/contents/ui/main.qml:14:1 > : module "org.kde.plasma.plasma5support" is not installed > device notifier: > file:///usr/share/plasma/plasmoids/org.kde.plasma.devicenotifier/contents/ui > /main.qml:14:1: module "org.kde.plasma.plasma5support" is not installed > > regards signature.asc Description: This is a digitally signed message part.
Bug#1024886: qt6-declarative-dev: Missing depdendency on libqt6opengl6-dev
Package: qt6-declarative-dev Version: 6.3.1+dfsg-5 Severity: normal X-Debbugs-Cc: he...@debian.org When I try to build the new qcoro version 0.7.0 I need Qt6Quick and install qt6-declativate-dev I get the following error in CMake. Please add libqt6opengl6-dev to the depdendency of qt6-declarative-dev. hefee -- Could NOT find Qt6OpenGL (missing: Qt6OpenGL_DIR) CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:223 (find_package): Found package configuration file: /usr/lib/x86_64-linux-gnu/cmake/Qt6Quick/Qt6QuickConfig.cmake but it set Qt6Quick_FOUND to FALSE so package "Qt6Quick" is considered to be NOT FOUND. Reason given by package: Qt6Quick could not be found because dependency Qt6OpenGL could not be found. Call Stack (most recent call first): CMakeLists.txt:83 (find_package) CMake Error at CMakeLists.txt:83 (find_package): Found package configuration file: /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake but it set Qt6_FOUND to FALSE so package "Qt6" is considered to be NOT FOUND. Reason given by package: Failed to find Qt component "Quick". Expected Config file at "/usr/lib/x86_64-linux-gnu/cmake/Qt6Quick/Qt6QuickConfig.cmake" exists
Bug#1024888: qt6-declarative-private-dev: Missing depdendency on qt6-base-private-dev
Package: qt6-declarative-private-dev Version: 6.3.1+dfsg-5 Severity: normal X-Debbugs-Cc: he...@debian.org When I try to build qcoro 0.7.0 I get the following CMake error. QCoro depends on Qt6::QmlPrivate and Qt6::QuickPrivate, both are shipped via qt6-declatiave-private-dev. But qt6-declativate-private-dev depends on qt6-base-private-dev (It searches /usr/include/x86_64-linux-gnu/qt6/QtCore/6.3.1). hefee CMake Error in qcoro/qml/CMakeLists.txt: Imported target "Qt::QmlPrivate" includes non-existent path "/usr/include/x86_64-linux-gnu/qt6/QtCore/6.3.1" in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include: * The path was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and references files it does not provide. CMake Error in tests/CMakeLists.txt: Imported target "Qt6::QuickPrivate" includes non-existent path "/usr/include/x86_64-linux-gnu/qt6/QtCore/6.3.1" in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include: * The path was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and references files it does not provide. CMake Error in qcoro/qml/CMakeLists.txt: Imported target "Qt::QmlPrivate" includes non-existent path "/usr/include/x86_64-linux-gnu/qt6/QtCore/6.3.1" in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include: * The path was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and references files it does not provide. CMake Error in tests/CMakeLists.txt: Imported target "Qt6::QuickPrivate" includes non-existent path "/usr/include/x86_64-linux-gnu/qt6/QtCore/6.3.1" in its INTERFACE_INCLUDE_DIRECTORIES. Possible reasons include: * The path was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and references files it does not provide.
Bug#1025162: akonadi-server won't start if the home directory is not immediately under /home
Hey,
thanks for your bugreport. The problem is not akonadiserver, it is AppArmor,
that is securing your system. Akonadi has a AppArmor profile, so you need to
adjust that profile for your setup ( or disable AppArmor - NOT RECOMMENDED).
To make it permanently you have to modify and your home path to the HOMEDIRS
setting in. After modifying you need to reload AppArmor profiles:
/etc/apparmor.d/tunables/home.d/site.local
See current state of AppArmor (you may also need to install apparmor-utils):
$ aa-status
(see usr.bin.akonadiserver is in enforce mode)
Disable AppArmor (only for testing ;)
$ aa-disable usr.bin.akonadiserver
enable it again:
$ aa-enforce usr.bin.akonadiserver
Maybe we need to forward this bugreport to AppArmor to be able to read the
users' home via /etc/passwd...
Regards,
hefee
--
On Mittwoch, 30. November 2022 15:09:10 CET Josep Guerrero wrote:
> Package: akonadi-server
> Version: 4:20.08.3-3
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>
> I updated from debian buster to debian bullseye. When logging in, akonadi
> always produced and error ("exit code 253 (unknown error)") and couldn't
> start kmail at all as a consequence.
>
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
>
> I discovered that newly created for users under /home akonadiserver would
> work. For newly created users under /home/directory wouldn't. I moved my
> home from /home/nodens/user to /home/user and linked /home/nodens to /home.
>
>* What was the outcome of this action?
>
> Akonadiserver started working againi for my user, but only when home was
> directly under /home. When it didn't work, dmesg showed some apparmor
> errors.
>
>* What outcome did you expect instead?
>
> I expected it to work wherever the home was.
>
>
> -- System Information:
> Debian Release: 11.5
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
> 'stable') Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.10.0-19-amd64 (SMP w/4 CPU threads)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages akonadi-server depends on:
> ii akonadi-backend-mysql4:20.08.3-3
> ii libaccounts-qt5-11.16-2
> ii libc62.31-13+deb11u5
> ii libgcc-s110.2.1-6 ii
> libkf5akonadiprivate5abi2 [libkf5akonadiprivate5-20.08] 4:20.08.3-3 ii
> libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08] 4:20.08.3-3 ii
> libkf5configcore55.78.0-4 ii
> libkf5coreaddons55.78.0-4 ii
> libkf5crash5 5.78.0-3 ii
> libkf5i18n5 5.78.0-2 ii
> libqt5core5a 5.15.2+dfsg-9 ii
> libqt5dbus5 5.15.2+dfsg-9 ii
> libqt5gui5 5.15.2+dfsg-9 ii
> libqt5network5 5.15.2+dfsg-9 ii
> libqt5sql5 5.15.2+dfsg-9 ii
> libqt5widgets5 5.15.2+dfsg-9 ii
> libqt5xml5 5.15.2+dfsg-9 ii
> libstdc++6 10.2.1-6
>
> akonadi-server recommends no packages.
>
> Versions of packages akonadi-server suggests:
> ii akonadi-backend-mysql 4:20.08.3-3
> pn akonadi-backend-postgresql
> pn akonadi-backend-sqlite
>
> -- no debconf information
signature.asc
Description: This is a digitally signed message part.
Bug#1025670: Bug#1025671: RM: marble [armel ppc64el s390x] -- RoQA; qtwebengine-opensource-src not available
Hey, you wrote those bugreports very fast. When I uploaded the new marble version I overseen, that QtWebEnigne is not built on all archs. But QtWebEngine is a optional build dependency, so it is easy to build marble without QtWebEngine. I uploaded marble 4:22.08.3-2 with QtWebEngine to be optional. Hefee -- On Mittwoch, 7. Dezember 2022 11:06:39 CET Bas Couwenberg wrote: > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-Cc: mar...@packages.debian.org > Control: affects -1 + src:marble > Control: block -1 by 1025670 > > Please remove marble from the architectures where qtwebengine5-dev is not > available to unblock testing migration. > > Kind Regards, > > Bas signature.asc Description: This is a digitally signed message part.
Bug#806717: Forwarding email with a long header causes longer than 998 byte lines
Hey, I think the fix will be published with KMime 22.12.0 (should reach unstable the next days), as there is a MR request that should fix that: https://invent.kde.org/pim/kmime/-/merge_requests/7 Regards, hefee -- On Dienstag, 13. Dezember 2022 20:14:28 CET Mikko Tuumanen wrote: > I received an email with a x-ms-exchange-antispam-messagedata-0: header > and I tried to forward it with kmail. > > That caused error message: > "The server said: maximum allowed line length is 998 octets, got 1702" > > In the original message, the header was split into multiple lines like > this: > > x-ms-exchange-antispam-messagedata-0: > =?iso-8859-1?Q?X9nvzr27qYcmEJpSHcp6K5gWYoBjPRlTmpppdR4VrmwY1cP0Mp4QNB9+kY?= > =?iso-8859-1?Q?ZWd5EsMdHUa4x0pKA1ObLVns8RuLFV3mCsHlMT31xBfLxra6jZ+p5hbSHx?= > > > But when the message was forwarded with kmail, the header > turned into one too long line: > > x-ms-exchange-antispam-messagedata-0: lwf7pdVSQS1T... > > > It seems that kmail has more than one header "fixing" problem. signature.asc Description: This is a digitally signed message part.
Re: Package deleted from repository?
Hey, > Problem is that lots of other software depends on libqt5core5a 5.15.2+dfsg-9 > and this breaks libqtcore4 < 4:4.8.7+dfsg-20~ > > I have libqtcore4 4:4.8.7+dfsg-18+deb10u1 which is nearly the required > version. But nowhere in debian repositories 4:4.8.7+dfsg-20 version is > seen. Is it deleted? Has it ever been present? Qt4 was deleted in the current Debian stable, so the version that was at this stage in testing ( the -20) got deleted and never ended in a stable release. You can find all old versions on https://snapshots.debian.org, just search for the binary pacakge: libqtcore4 > So either the dependency is wrong or some package is missing or I didn't get > some relevant point. The relevant point is Qt4 is dead and is not more mantained and supported by Debian! Regards hefee signature.asc Description: This is a digitally signed message part.
Bug#1006230: qt6-base-dev: Undefined target Qt::CorePrivate.
Package: qt6-base-dev Version: 6.2.2+dfsg-5 Severity: important X-Debbugs-Cc: he...@debian.org If I just use in CMake "find_package(Qt6 COMPONENTS Core REQUIRED)" I end up with the bug: "Targets not yet defined: Qt::CorePrivate" Also if I add qt6-base-private-dev explicitly to the Build-Depends list, I still get the same error. That's why it seems like a bug inside qt6-base. See the build of qtkeychain: https://salsa.debian.org/owncloud-team/qtkeychain/-/jobs/2496539#L1939 https://salsa.debian.org/owncloud-team/qtkeychain/-/pipelines/351397 and the correspondig CMakeLists.txt: https://salsa.debian.org/owncloud-team/qtkeychain/-/blob/master/CMakeLists.txt and relevant Debian files: https://salsa.debian.org/owncloud-team/qtkeychain/-/blob/work/hefee/qt6/debian/control https://salsa.debian.org/owncloud-team/qtkeychain/-/blob/work/hefee/qt6/debian/control Regards, hefee -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qt6-base-dev depends on: ii libqt6concurrent6 6.2.2+dfsg-5 ii libqt6core6 6.2.2+dfsg-5 ii libqt6dbus6 6.2.2+dfsg-5 ii libqt6gui66.2.2+dfsg-5 ii libqt6network66.2.2+dfsg-5 ii libqt6openglwidgets6 6.2.2+dfsg-5 ii libqt6printsupport6 6.2.2+dfsg-5 ii libqt6sql66.2.2+dfsg-5 ii libqt6test6 6.2.2+dfsg-5 ii libqt6widgets66.2.2+dfsg-5 ii libqt6xml66.2.2+dfsg-5 ii qmake66.2.2+dfsg-5 ii qt6-base-dev-tools6.2.2+dfsg-5 ii qt6-qpa-plugins 6.2.2+dfsg-5 Versions of packages qt6-base-dev recommends: ii libqt6opengl6-dev 6.2.2+dfsg-5 qt6-base-dev suggests no packages. -- no debconf information
Bug#1006230: qt6-base-dev: Undefined target Qt::CorePrivate.
In meanwhile we found a workaround: https://salsa.debian.org/owncloud-team/qtkeychain/-/merge_requests/3 aka: Add qtbase5-private-dev, qt6-tools-dev, qt6-tools-dev-tool, libgcrypt20- dev and qt6-l10n-tools to BDs. and no need to add qt6-base-private-dev. Fedora 34 has the same issue, when building qtkeychain: https://github.com/frankosterfeld/qtkeychain/issues/202 Regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1010576: akonadi cannot kill mysql due to apparmor rules
Hi, the fix is already in master, it is actually just a typo in the profile name: https://invent.kde.org/pim/akonadi/-/commit/ a6fb4c7de13eed9d90237388113425413bf4d733 that may be worth to backport. > If I set akonadi's profile to complain instead of enforce, akonadi can > kill mysql ok: > > sudo aa-complain /etc/apparmor.d/usr.bin.akonadiserver > sudo systemctl reload apparmor.service you don't need to restart apparmor after set akonadiserver to complain mode. > Somehow mysql should be running in the mysqld_akonadi profile but it is > running in fact unconstrained and therefore akonadiserver is not allowed > to send a signal to it. Don't know how to fix that, though. I see the same apparmor issue, but Akonadi is still not able to kill mariadb process. > I suspect the fact that mysql hangs after suspend/resume is a different > bug in mysql. yepp - But I have no idea how to debug this. regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1027689: Akregator Update
Control: forwarded -1 https://bugs.kde.org/show_bug.cgi?id=429444 Control: fixed -1 4:22.08.3-1 Hey, We cannot bring akregator 22.08.3 to stable without backport all other pim packages (~70). In principal it is doable but the Debian mantainer team is too small for this. See the direct build dependency graph (https:// salsa.debian.org/qt-kde-team/pkg-kde-dev-scripts/-/blob/master/tierdata/ kdepim.22.08.0.tier.png) On the other side we can backport individual commits to 20.08, if the apply clearly. That is the case for the referenced commit. So we can ship a fixed version in stable. BUT someone needs to test the fixed application, as it may introduce other bugs, as we cherry-pick one single commit. And it is not a one-line fix. Are you able to test the package, if I send you a link for the fixed debs? After we are sure, that the cherry-picking was successful. there is only some paperwork to do to ship the fixed package with the next stable point release. Cheers, hefee -- On Montag, 2. Januar 2023 00:14:28 CET Jeff Sacksteder wrote: > Package: Akregator > Version: 4:20.08.3-1 > > As of 11.6, Stable continues to include Akregator 4:20.08.3-1, which > includes this bug: > > https://bugs.kde.org/show_bug.cgi?id=429444 > https://invent.kde.org/pim/akregator/-/commit/546db72108cba99a1881e97349ce55 > db5d1da88e > > Testing includes 4:22.08.3-1 and presumably fixes this. Can it be added to > Stable? signature.asc Description: This is a digitally signed message part.
Bug#1028571: bullseye-pu: package akregator/20.08.3-1+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: akrega...@packages.debian.org, Jeff Sacksteder
, he...@debian.org
Control: affects -1 + src:akregator
Hey,
[ Reason ]
[#1027689] - Akregator is not able to delete feeds/folders. It can end
in request data from websites you don't want to.
[ Impact ]
Akregator seems broken for users.
[ Tests ]
Manual test were done to check the patch and tests are still ongoing.
[ Risks ]
The patch it self comes from upstream and is a simply backport (int
replacement with uint). I think the risk of sideeffects is quite small.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
diff -Nru akregator-20.08.3/debian/changelog akregator-20.08.3/debian/changelog
--- akregator-20.08.3/debian/changelog 2023-01-13 00:49:15.0 +0100
+++ akregator-20.08.3/debian/changelog 2020-12-16 01:50:53.0 +0100
@@ -1,11 +1,3 @@
-akregator (4:20.08.3-1+deb11u1) bullseye; urgency=medium
-
- [ Sandro Knauß ]
- * Add backport patch 2f6d4e233ae8178535d74c1da0cf75a54762d165.diff
-(Closes: #1027689).
-
- -- Sandro Knauß Fri, 13 Jan 2023 00:49:15 +0100
-
akregator (4:20.08.3-1) unstable; urgency=medium
[ Sandro Knauß ]
diff -Nru
akregator-20.08.3/debian/patches/2f6d4e233ae8178535d74c1da0cf75a54762d165.diff
akregator-20.08.3/debian/patches/2f6d4e233ae8178535d74c1da0cf75a54762d165.diff
---
akregator-20.08.3/debian/patches/2f6d4e233ae8178535d74c1da0cf75a54762d165.diff
2023-01-08 23:44:59.0 +0100
+++
akregator-20.08.3/debian/patches/2f6d4e233ae8178535d74c1da0cf75a54762d165.diff
1970-01-01 01:00:00.0 +0100
@@ -1,317 +0,0 @@
a/src/command/deletesubscriptioncommand.cpp
-+++ b/src/command/deletesubscriptioncommand.cpp
-@@ -124,7 +124,7 @@ public:
- void jobFinished();
-
- QWeakPointer m_list;
--int m_subscriptionId = -1;
-+uint m_subscriptionId = 0;
- };
-
- DeleteSubscriptionCommand::Private::Private(DeleteSubscriptionCommand *qq) :
q(qq)
-@@ -146,13 +146,13 @@ DeleteSubscriptionCommand::~DeleteSubscr
- delete d;
- }
-
--void DeleteSubscriptionCommand::setSubscription(const QWeakPointer
&feedList, int subId)
-+void DeleteSubscriptionCommand::setSubscription(const QWeakPointer
&feedList, uint subId)
- {
- d->m_list = feedList;
- d->m_subscriptionId = subId;
- }
-
--int DeleteSubscriptionCommand::subscriptionId() const
-+uint DeleteSubscriptionCommand::subscriptionId() const
- {
- return d->m_subscriptionId;
- }
a/src/command/deletesubscriptioncommand.h
-+++ b/src/command/deletesubscriptioncommand.h
-@@ -39,9 +39,9 @@ public:
- explicit DeleteSubscriptionCommand(QObject *parent = nullptr);
- ~DeleteSubscriptionCommand() override;
-
--void setSubscription(const QWeakPointer &feedList, int subId);
-+void setSubscription(const QWeakPointer &feedList, uint subId);
-
--int subscriptionId() const;
-+uint subscriptionId() const;
- QWeakPointer feedList() const;
-
- private:
a/src/command/editsubscriptioncommand.cpp
-+++ b/src/command/editsubscriptioncommand.cpp
-@@ -83,13 +83,13 @@ public:
- void jobFinished();
-
- QSharedPointer m_list;
--int m_subscriptionId;
-+uint m_subscriptionId;
- SubscriptionListView *m_subscriptionListView = nullptr;
- };
-
- EditSubscriptionCommand::Private::Private(EditSubscriptionCommand *qq) : q(qq)
- , m_list()
--, m_subscriptionId(-1)
-+, m_subscriptionId(0)
- , m_subscriptionListView(nullptr)
- {
- }
-@@ -108,13 +108,13 @@ EditSubscriptionCommand::~EditSubscripti
- delete d;
- }
-
--void EditSubscriptionCommand::setSubscription(const QSharedPointer
&feedList, int subId)
-+void EditSubscriptionCommand::setSubscription(const QSharedPointer
&feedList, uint subId)
- {
- d->m_list = feedList;
- d->m_subscriptionId = subId;
- }
-
--int EditSubscriptionCommand::subscriptionId() const
-+uint EditSubscriptionCommand::subscriptionId() const
- {
- return d->m_subscriptionId;
- }
a/src/command/editsubscriptioncommand.h
-+++ b/src/command/editsubscriptioncommand.h
-@@ -40,8 +40,8 @@ public:
- explicit EditSubscriptionCommand(QObject *parent = nullptr);
- ~EditSubscriptionCommand() override;
-
--void setSubscription(const QSharedPointer &feedList, int subId);
--int subscriptionId() const;
-+void setSubscription(const QSharedPointer &feedList, uint
subId);
-+uint subscriptionId() const;
- QSharedPointer feedList() const;
-
- SubscriptionListView *subscriptionListView() const;
a/src/command/expireitemscommand.cpp
-+++ b/src/command/expireitemscommand.cpp
-@@ -50,7 +50,7 @@ public:
- void jobFinished(KJob *);
-
- QWeakPointer m_feedList;
--QVector m_feeds;
-+QVector m_feeds;
- QSet m_job
Bug#1084829: qml6-module-qtlocation: Missing QML dependencies for MapView.qml
Package: qml6-module-qtlocation Version: 6.7.2-3 Severity: normal Tags: patch X-Debbugs-Cc: he...@debian.org Hey, the qml6-module-qtlocation is missing QML depdendecies for the shipped file /usr/lib/*/qt6/qml/QtLocation/MapView.qml, that file depdends on: qml6-module-qt-labs-animation qml6-module-qtpositioning qml6-module-qtquick I theory this is enough to run MapView.qml without a segfault, but without the plugins qt6-location-plugins the MapView is simply empty. I would add the plugins package a depend or recommend to the qml package. Best regards, hefee -- System Information: Debian Release: trixie/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.11.2-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qml6-module-qtlocation depends on: ii libc62.40-3 ii libqt6core6t64 6.7.2+dfsg-3 ii libqt6location6 6.7.2-3 ii libqt6qml6 6.7.2+dfsg-9 ii libstdc++6 14.2.0-6 qml6-module-qtlocation recommends no packages. qml6-module-qtlocation suggests no packages. -- no debconf information
Bug#1087840: (probably) unneeded dependence on kdeconnect
Hey, > The most recent version of kdeconnect has added the binary package > qml6-module-org-kde-kdeconnect, which is pulled in by libkf6purpose-bin. > The qml package in turn pulls in kdeconnect. > > I suspect both of these requirements are unnecessary, and this bug > is a request to remove the second dependence (qml-... depending on > kdeconnect). And without qml -kdeconnect part of purpose does not work -> that means removing it (completely again) is not an option. But I lowered the dependency from depends to recommends, so you are able to install libkf6purpose-bin with sid only (fixed in 6.6.0-3). The second dependency qml6-kdeconnect -> kdeconnect is added because qml6- kdeconnect uses libs that are shipped in kdeconnect package. We may need to split the package. Regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1089306: kdeconnect FTBFS (due to attempted network access?)
Hey, Yeah the test need to create a port and connect to it. As i also use sbuild locally I thought okay, it still works. Do the buildds not even allow to access to localhost? regards, hefee On Samstag, 7. Dezember 2024 19:56:35 CET Adrian Bunk wrote: > Source: kdeconnect > Version: 24.08.2-1 > Severity: serious > Tags: ftbfs > > https://buildd.debian.org/status/logs.php?pkg=kdeconnect&ver=24.08.2-1 > https://buildd.debian.org/status/fetch.php?pkg=kdeconnect&arch=arm64&ver=24. > 08.3-1&stamp=1733595328&raw=0 > > ... > 4: FAIL! : TestMdns::testAnounceAndDiscover() 'spy.wait(2000)' returned > FALSE. () 4:Loc: [./tests/mdnstest.cpp(55)] > 4: PASS : TestMdns::cleanupTestCase() > 4: Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1904ms > 4: * Finished testing of TestMdns * > 4/4 Test #4: mdnstest .***Failed2.02 sec > * Start testing of TestMdns * > Config: Using QtTest library 6.7.2, Qt 6.7.2 (arm64-little_endian-lp64 > shared (dynamic) release build; by GCC 14.2.0), debian unknown PASS : > TestMdns::initTestCase() > QWARN : TestMdns::testAnounceAndDiscover() kdeconnect.core: Failed to open > any MDNS client sockets QWARN : TestMdns::testAnounceAndDiscover() > kdeconnect.core: Failed to open any MDNS server sockets FAIL! : > TestMdns::testAnounceAndDiscover() 'spy.wait(2000)' returned FALSE. () Loc: > [./tests/mdnstest.cpp(55)] > PASS : TestMdns::cleanupTestCase() > Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1904ms > * Finished testing of TestMdns * > > > 75% tests passed, 1 tests failed out of 4 > > Total Test time (real) = 2.03 sec > > The following tests FAILED: > 4 - mdnstest (Failed) > Errors while running CTest > make[2]: *** [Makefile:74: test] Error 8 signature.asc Description: This is a digitally signed message part.
Bug#1091638: RM: neochat [armel mips64el ppc64el risc64 s390x] -- ROM; ANAIS - Cannot be built anymore on certain archs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: neoc...@packages.debian.org, he...@debian.org Control: affects -1 + src:neochat User: ftp.debian@packages.debian.org Usertags: remove Hi, with the update to Qt 6, nextcloud-desktop cannot be built anymore on the listed architectures due to qt6-webengine not being available on these archs. Please remove the package on those architectures. Thank you very much. Regards, hefee
Bug#1057346: qt6-base-dev-tools is wrongly marked Multi-Arch: foreign
Hi, (please remove me from direct response, i get your responses via the bug address). > Given the above, I more and more favour B, but with a twist. I think we > should move the symlinks /usr/bin/* from qt6-base-dev-tools to > qt6-base-dev as a means of actively breaking packages that abuse such a > dependency. Then, we may simply install -qtpaths6 into > qt6-base-dev as well and have it just work there. > > Going for (B) will likely make less than 30 packages FTBFS. Do you think > this can be fixed after breaking them or should we do a rebuild > beforehand? > > It may also be that they fall back to /usr/lib/qt6/bin/qtpaths and > continue working for native builds. In that case, we'd only have to fix > the FTCBFS later and the number of FTBFS would be lower. We may also > transition them immediately by renaming qt6-base-dev-tools to > qt6-base-dev-bin and then adding "Provides: qt6-base-dev-tools" to > qt6-base-dev. I think there are also some candidates, that use qt6-base-dev-tools, as they are do not need all the other parts of qt6-base-dev to get installed, because they simply do not want to compile code, but just need information where to find a qt resources. One example would be I write a QML app run by python. To get the list of QML dependencies I use dh_qmldeps. and dh_qmldeps only needs to know the path where to find the qml modules by execute qtpaths. Maybe there are more use cases for other binaries in Python code. (I do not remember the tasks, but I stumbled several times over that -dev- tools were missing on my system and all those use cases where to prepare a build, where i would have needed the header files anyways. But this was Qt5 times...) That's why I say, that dev-tools should be fine for packages to depend on. IMO I recommend to do this: create qtpaths6 (any:same) and qtpaths6-bin(any:foreign) like for qmake6. create dev-tools-config(arch:same) move everything from qmake6 except usr/bin/ rename qt6-base-dev-tools to qt6-base-dev-bin + provides and add qtpaths6. Regards, hefee [1] https://salsa.debian.org/qt-kde-team/pkg-kde-tools/-/blob/master/datalib/ qt_version_info.yml?ref_type=heads signature.asc Description: This is a digitally signed message part.
Re: Bug#1057346: qt6-base-dev-tools is wrongly marked Multi-Arch: foreign
Hey, > On Fri, Dec 13, 2024 at 03:51:58PM +0100, Hefee wrote: > > I think there are also some candidates, that use qt6-base-dev-tools, as > > they are do not need all the other parts of qt6-base-dev to get > > installed, because they simply do not want to compile code, but just need > > information where to find a qt resources. > > One example would be I write a QML app run by python. To get the list of > > QML dependencies I use dh_qmldeps. and dh_qmldeps only needs to know the > > path where to find the qml modules by execute qtpaths. > > This ^^^ is exactly the case > where qt6-base-dev-tools is insufficient as qtpaths is the thing that is > architecture-dependent and whatever you depend on to get qtpaths must > not be M-A:foreign. To make matters worse, any package that uses > qtpaths6 cannot be M-A:foreign either as it inherits the property of > being architecture-dependent. I'm not telling, that qt6-base-dev-tools in it current form should be usable it can be arch:same or something - I'm just telling, that we should not see qt6-base-dev-tools as implementation detail for fixing multi-arch, as there are other usecases. So any new solution should keep that in mind. > > create qtpaths6 (any:same) and qtpaths6-bin(any:foreign) like for qmake6. > > This much technically makes sense for cross building, but I am not > entirely convinced about using many small packages, because the Qt stack > has a web of dependencies, so in most practical situations I end up > with a pile of stuff. Whilst saving space is nice, I don't see the use > case for development tools. I understand your point. > > create dev-tools-config(arch:same) move everything from qmake6 except > > usr/bin/ > This makes sense in principle as qtpaths6 will need to depend on > dev-tools-config (<- this should probably carry "qt" somehwere in the > name). ACK the name should have a qt inside ;) > > rename qt6-base-dev-tools to qt6-base-dev-bin + provides and add qtpaths6. > > Can you elaborate what you mean here precisely? This is lacking slightly > too many details for me to fill in the gaps. > > When I suggested renaming qt6-base-dev-tools to qt6-base-dev-bin, the > point of the exercise was to actively break all users of > qt6-base-dev-tools such that each of them would require action > transitioning its dependency to whatever was really meant there. I cannot recall what I initially had in mind with this. But with our comments it is even better to do this: * rename to qt6-base-dev-bin, so we can make qt6-base-dev-tools multi- arch:same * ship the arch depended tools like qtpaths6 within qt6-base-dev-tools , that depends on qt6-base-dev-bin and qt6-base-dev-config That should make it easy for use to move more tools to multi-arch:same if we need to. Regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1090935: RM: itinerary [i386] -- ROM; Cannot be built anymore on certain archs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: itiner...@packages.debian.org, he...@debian.org Control: affects -1 + src:itinerary User: ftp.debian@packages.debian.org Usertags: remove Hi, with the update of KDE PIM, itinerary cannot be built anymore on the listed architectures due to poppler not being available on these archs. Please remove the binary packages on those architectures. Thank you very much. Regards, hefee
Bug#1087840: (probably) unneeded dependence on kdeconnect
Control: found -1 src:kf6-purpose/6.6.0-2 Control: notfound -1 src:kf6-purpose/6.6.0-3 Hey, > I consider this bug closed, too. Can you double check this BTS incantation? > (I always manage to mess up some detail.) > > Control: found -1 kf6-purpose/6.6.0-2 > Control: notfound -1 kf6-purpose/6.6.0-3 well you need to tell BTS, that you are referring to the source pkg. With that infos you do not close the bug. Btw. I do mess up the metadata in BTS often enough too. > I would not reassign this. ACK. But in this case, it is correct, as we need to look/check/fix the inter- package deps in kdeconnect . Regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1004833: kdeconnect: White on white, DPI breakages, etc
Control: tags -1 +moreinfo Hey, kdeconnect does not shipping an own theme, but there are Desktop environments (DE) that do not set the Qt theme. The result is kdeconnect use a fallback theme. In order to configure the qt theme you need qt5ct/qt6ct or e.g. adwaita-qt/ adwaita-qt6, so qt apps using the default Gnome theme. See the links for help. https://wiki.archlinux.org/title/ Qt#Configuration_of_Qt_5/6_applications_under_environments_other_than_KDE_Plasma https://wiki.archlinux.org/title/ Uniform_look_for_Qt_and_GTK_applications#Themes_originally_GTK_based_for_Qt_programs IMO it is nothing kdeconnect can do to improve the situation, it is more the DE that needs to fix that. Regards, hefee PS: I use Plasma Desktop with a white on black theme and kdeconnect follows this theme. On Mittwoch, 2. Februar 2022 00:03:04 CET Joseph Carter wrote: > Package: kdeconnect > Version: 21.08.3-1 > Severity: important > Tags: a11y > > It appears kdeconnect is forcing assumptions about your DPI/font scale > (96/1.0), your theme (black on white), and probably other things, then > hardcoding all of those details. This causes any change in these > settings to cause kdeconnect to be horribly broken to the point that the > thing is completely unusable with white on white text, missing controls, > a panel popup too small to contain even one line of text, etc. > > If you need those things changed because you're, say, legally blind, > kdeconnect is basically impossible to use. Workarounds exist depending > on your setup. A lot of fiddling may make the panel popup grow to > accomodate text. You can search the maze of inaccurate, obsolete, and > conflicting pages on theming Qt apps to figure out how to override a > theme for kdeconnect and set up wrapper scripts and .desktop files to do > that for specific apps and modify the GUI accordingly to use those > wrapper scripts. If you're using Compton, there's a plugin that'd let > you invert the window's colors and I guess there might be some way to > automate that, but I don't use it so am not sure. But at the point > you've done all that, you're scarcely using the Debian package as > provided and your hacks can be trivially broken by an upgrade of the > package. > > This combination of … what apparently seems to amount to a pretty common > dumpster fire for Qt5 apps with hardcoded colors/backgrounds/font sizes > …sigh… has rendered kdeconnect basically unusable by anyone who uses a > dark theme or scaled fonts for accessibility, to say nothing of anyone > who uses them for aesthetic or "I have a shiny new 4k+ monitor and want > to actually, y'know, use it as intended" reasons. > > Only workarounds I can think of involve forcing the theme to be the > default (since kdeconnect halfassedly does this anyway) and … I don't > know what to do about the DPI thing. > > -- System Information: > Debian Release: bookworm/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 > (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages kdeconnect depends on: > ii fuse33.10.5-1 > ii kio 5.88.0-1 > ii kpeople-vcard0.1-2 > ii libc62.33-5 > ii libfakekey0 0.3+git20170516-2 > ii libkf5configcore55.88.0-1 > ii libkf5configwidgets5 5.88.0-1 > ii libkf5coreaddons55.88.0-1 > ii libkf5dbusaddons55.88.0-1 > ii libkf5i18n5 5.88.0-2 > ii libkf5iconthemes55.88.0-1 > ii libkf5kcmutils5 5.88.0-1 > ii libkf5kiocore5 5.88.0-1 > ii libkf5kiofilewidgets55.88.0-1 > ii libkf5kiogui55.88.0-1 > ii libkf5kiowidgets55.88.0-1 > ii libkf5notifications5 5.88.0-2 > ii libkf5people55.88.0-1 > ii libkf5pulseaudioqt3 1.3-2 > ii libkf5service-bin5.88.0-1 > ii libkf5service5 5.88.0-1 > ii libkf5solid5 5.88.0-1 > ii libkf5waylandclient5 4:5.88.0-1
Bug#1091088: RM: konqueror [armel mips64el ppc64el riscv64 s390x] -- ROM; Cannot be built anymore on certain archs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: konque...@packages.debian.org, he...@debian.org Control: affects -1 + src:konqueror User: ftp.debian@packages.debian.org Usertags: remove Hi, konqueror cannot be built anymore on the listed architectures due to qt6-webengine not being available on these archs. Please remove the package on those architectures. Thank you very much. Regards, hefee
Bug#1094404: NeoChat has missing AppStream metadata
Control: tags -1 + unreproducible Hey, I can successfully find neochat in Plasma Discover and you already pointed out, the appstream file is also shipped within the package. (/usr/share/metainfo/org.kde.neochat.appdata.xml) You need to download the dep11 files in order to find application within discover or GNOME software center. Make sure that this file is not modified from you locally (part of appstreamcli package): /etc/apt/apt.conf.d/50appstream > https://appstream.debian.org/sid/main/metainfo/neochat.html Maybe this page does not scan for new packages that often? Regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1057346: qt6-base-dev-tools is wrongly marked Multi-Arch: foreign
Hey, I finally created a draft to fix it: https://salsa.debian.org/qt-kde-team/qt6/qt6-base/-/merge_requests/20 Regards, hefee -- On Donnerstag, 19. Dezember 2024 18:50:33 MEZ Hefee wrote: > Hey, > > > On Fri, Dec 13, 2024 at 03:51:58PM +0100, Hefee wrote: > > > I think there are also some candidates, that use qt6-base-dev-tools, as > > > they are do not need all the other parts of qt6-base-dev to get > > > installed, because they simply do not want to compile code, but just > > > need > > > information where to find a qt resources. > > > One example would be I write a QML app run by python. To get the list of > > > QML dependencies I use dh_qmldeps. and dh_qmldeps only needs to know the > > > path where to find the qml modules by execute qtpaths. > > > > This ^^^ is exactly the case > > where qt6-base-dev-tools is insufficient as qtpaths is the thing that is > > architecture-dependent and whatever you depend on to get qtpaths must > > not be M-A:foreign. To make matters worse, any package that uses > > qtpaths6 cannot be M-A:foreign either as it inherits the property of > > being architecture-dependent. > > I'm not telling, that qt6-base-dev-tools in it current form should be usable > it can be arch:same or something - I'm just telling, that we should not > see qt6-base-dev-tools as implementation detail for fixing multi-arch, as > there are other usecases. So any new solution should keep that in mind. > > > > create qtpaths6 (any:same) and qtpaths6-bin(any:foreign) like for > > > qmake6. > > > > This much technically makes sense for cross building, but I am not > > entirely convinced about using many small packages, because the Qt stack > > has a web of dependencies, so in most practical situations I end up > > with a pile of stuff. Whilst saving space is nice, I don't see the use > > case for development tools. > > I understand your point. > > > > create dev-tools-config(arch:same) move everything from qmake6 except > > > usr/bin/ > > > > This makes sense in principle as qtpaths6 will need to depend on > > dev-tools-config (<- this should probably carry "qt" somehwere in the > > name). > > ACK the name should have a qt inside ;) > > > > rename qt6-base-dev-tools to qt6-base-dev-bin + provides and add > > > qtpaths6. > > > > Can you elaborate what you mean here precisely? This is lacking slightly > > too many details for me to fill in the gaps. > > > > When I suggested renaming qt6-base-dev-tools to qt6-base-dev-bin, the > > point of the exercise was to actively break all users of > > qt6-base-dev-tools such that each of them would require action > > transitioning its dependency to whatever was really meant there. > > I cannot recall what I initially had in mind with this. But with our > comments it is even better to do this: > > * rename to qt6-base-dev-bin, so we can make qt6-base-dev-tools multi- > arch:same > * ship the arch depended tools like qtpaths6 within qt6-base-dev-tools , > that depends on qt6-base-dev-bin and qt6-base-dev-config > > That should make it easy for use to move more tools to multi-arch:same if we > need to. > > Regards, > > hefee signature.asc Description: This is a digitally signed message part.
Bug#1092963: korganizer: Each action in Korganizer are extremely slow since last debian testing update of kdepim6
Hey, > > Which database type are you using ? > > » dlg akonadi > rc akonadi-backend-mysql4:22.12.2-1 > ii akonadi-backend-sqlite 4:24.12.0-2 > > I'm not sure why the migration to 24.12 used sqlite instead of mysql. Could > that explain the extremely slow response time in Korganizer? The backend packages only exist, because it is impossible to express complex dependencies within one package. So those -backend- packages just install the needed packages to use this backend. > I'm not sure why the migration to 24.12 used sqlite instead of mysql. In akonadiserver we switched the ordering, to prefer sqlite over mysql for new installations, but for an upgrade apt shouldn't switch the backend packages. Aka apt should prefer upgrading the mysql backend over remove mysql & install sqlite. How did you do your updates? To see what backend you are using you have to look into ~/.config/akonadi/akonadiserverrc under [%General] you find the used backend. Regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1092963: korganizer: Each action in Korganizer are extremely slow since last debian testing update of kdepim6
Hey, > ...which is coherent with the fact that I upgraded from previous Debian > version the usual way (changing the repo in source.list, the apt update && > apt dist-upgrade). Okay somehow apt decided not to upgrade but prefer to remove and install... That is not great. > However my akonadi-backend-mysql package was in `rc` mode, so how could that work until now ? As stated before, I've (re-)installed akonadi-backend-mysql for now. As I said the backend packages only makes sure, that you have mariadb-server- core, mariadb-client and libqt6sql6-mysql installed. But you can install those also by hand and use the backend successfully. The backend packages should make it easier for a user to not search for those dependencies. Regards, hefee signature.asc Description: This is a digitally signed message part.
Bug#1096092: qxmpp: please package qxmpp 1.9+
Source: qxmpp Severity: wishlist X-Debbugs-Cc: debian-qt-kde@lists.debian.org, he...@debian.org Hi, please package a upstream version of qxmpp, at least >= 1.9, currently 1.9.4; The Qt6 variant is needed to update kaidan to 0.11.0+. Thanks! hefee
Bug#1006230: qt6-base-dev: Undefined target Qt::CorePrivate.
Hey, > I have also been hit by this when trying to build libqgpgmeqt6-15 from > the recently split-off https://dev.gnupg.org/source/gpgmeqt.git > > QGPME build gpgme wrappers for Qt5 and and Qt6, I ended up adding > qt6-base-dev qtbase5-dev qtbase5-private-dev > instead of just > qt6-base-dev qtbase5-dev Unfortunately the root cause is a CMake change that showed this wrong usage of private targets in Qt. Qt is aware of this issue and there are attempts to fix this (maybe it is already fixed in Qt upstream; I havn't followed on that). But so far we need to wait for a fixed Qt version (or a backport) in order to remove the -private-dev packages again. Regards, hefee signature.asc Description: This is a digitally signed message part.
packaging QXmmp
Hey, the Qt/KDE Maintainer team would like to update Kaidan to 0.11.0, that needs QXmmp >= 0.9+ with Qt6. If I look into the history of QXmmp I see that the last updates were done via NMU (#1039055, #1062768) as the current uploads didn't respond. Nor are the NMU added to salsa. From my point of view it looks like the repo is abandoned and the uploaders are MIA. Are you Boris Pek and Jeremy Lainé still do work on/care about QXmmp? Regards, hefee signature.asc Description: This is a digitally signed message part.
