Bug#354070: kmail: I can confirm the problem on etch
Package: kmail Version: 4:3.5.5.dfsg.1-6 Followup-For: Bug #354070 Same problem on etch, exactly as described here : https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/128643 It's quite annoying, making the use of the groupware feature of kmail not so clean. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (990, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.21-2-powerpc Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Versions of packages kmail depends on: ii kdebase-kio-plugins4:3.5.5a.dfsg.1-6 core I/O slaves for KDE ii kdelibs4c2a4:3.5.5a.dfsg.1-8 core libraries and binaries for al ii kdepim-kio-plugins 4:3.5.5.dfsg.1-6 KDE pim I/O Slaves ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libaudio2 1.8-4 The Network Audio System (NAS). (s ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libfontconfig1 2.4.2-1.2 generic font configuration library ii libfreetype6 2.2.1-5+etch1 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-21GCC support library ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libidn11 0.6.5-1 GNU libidn library, implementation ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libkcal2b 4:3.5.5.dfsg.1-6 KDE calendaring library ii libkdepim1a4:3.5.5.dfsg.1-6 KDE PIM library ii libkleopatra1 4:3.5.5.dfsg.1-6 KDE GnuPG interface libraries ii libkmime2 4:3.5.5.dfsg.1-6 KDE MIME interface library ii libkpimidentities1 4:3.5.5.dfsg.1-6 KDE PIM user identity information ii libksieve0 4:3.5.5.dfsg.1-6 KDE mail/news message filtering li ii libmimelib1c2a 4:3.5.5.dfsg.1-6 KDE mime library ii libpng12-0 1.2.15~beta5-1PNG library - runtime ii libqt3-mt 3:3.3.7-4 Qt GUI Library (Threaded runtime v ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxft22.1.8.2-8 FreeType-based font drawing librar ii libxi6 1:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii perl 5.8.8-7 Larry Wall's Practical Extraction ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages kmail recommends: ii procmail 3.22-16Versatile e-mail processor -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#438147: kaddressbook : important fields missing when using the "Detailled Style" for printing
Package: kaddressbook
Version: 4:3.5.5.dfsg.1-6
Severity: normal
When using the "Detailled Style" ("Style Détaillé") some suite important
fields are not printed : Organization and Role are the most important
(Organization being part of the address itself, it's quite surprising
not to have it in a printed addressbook). In fact, only a few fields are
processed to be printed : Name, (incomplete) addresses, phones, birth date,
homepage and
notes.
The "Mike Style" is not more usable : fields are not adapted to their actual
length : when data is too long it's simply cropped.
I remembered better results when printing an addressbook with
kaddressbook quite a long time ago.
It would be nice to have at least Organization and Role printed
correctly, possibly in etch.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (990, 'stable')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.21-2-powerpc
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8)
Versions of packages kaddressbook depends on:
ii kdelibs4c2a4:3.5.5a.dfsg.1-8 core libraries and binaries for al
ii libacl12.2.41-1 Access control list shared library
ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi
ii libattr1 2.4.32-1 Extended attribute shared library
ii libaudio2 1.8-4 The Network Audio System (NAS). (s
ii libbluetooth2 3.7-1 Library to use the BlueZ Linux Blu
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libfam02.7.0-12 Client library to control the FAM
ii libfontconfig1 2.4.2-1.2 generic font configuration library
ii libfreetype6 2.2.1-5+etch1 FreeType 2 font engine, shared lib
ii libgcc11:4.1.1-21GCC support library
ii libgnokii3 0.6.14-1 Gnokii library
ii libice61:1.0.1-2 X11 Inter-Client Exchange library
ii libidn11 0.6.5-1 GNU libidn library, implementation
ii libjpeg62 6b-13 The Independent JPEG Group's JPEG
ii libkcal2b 4:3.5.5.dfsg.1-6 KDE calendaring library
ii libkdepim1a4:3.5.5.dfsg.1-6 KDE PIM library
ii libkleopatra1 4:3.5.5.dfsg.1-6 KDE GnuPG interface libraries
ii libktnef1 4:3.5.5.dfsg.1-6 Library for handling KTNEF email a
ii libpng12-0 1.2.15~beta5-1PNG library - runtime
ii libqt3-mt 3:3.3.7-4 Qt GUI Library (Threaded runtime v
ii libsm6 1:1.0.1-3 X11 Session Management library
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
ii libx11-6 2:1.0.3-7 X11 client-side library
ii libxcursor11.1.7-4 X cursor management library
ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar
ii libxft22.1.8.2-8 FreeType-based font drawing librar
ii libxi6 1:1.0.1-4 X11 Input extension library
ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library
ii libxpm41:3.5.5-2 X11 pixmap library
ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library
ii libxrender11:0.9.1-3 X Rendering Extension client libra
ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library
ii zlib1g 1:1.2.3-13compression library - runtime
kaddressbook recommends no packages.
-- no debconf information
Bug#953328: sddm: No login prompt on tty1
Hello, I confirm this is still present in latest bullseye having sddm version 0.19.0-2 (amd64) Maybe this is somehow linked to https://github.com/systemd/systemd/issues/ 12345 ? Is that actually a sddm or a systemd bug ? Regards On Sat, 07 Mar 2020 20:55:57 + Andy Wood wrote: > Package: sddm > Version: 0.18.1-1 > Severity: important > Tags: patch > > Dear Maintainer, > > * What led up to the situation? > Installed version 0.18.1-1 as provided in bullseye [reboot] > > * What was the outcome of this action? > No login prompt on tty1 [but it is present on other tty's] > > * What outcome did you expect instead? > Normal login prompt on tty1 > > This seems to be caused by entries in /lib/systemd/system/sddm.service > > Changing: >Conflicts=getty@tty1.service getty@tty7.service >After=getty@tty1.service getty@tty7.service > > back to [as per the previous version]: >Conflicts=getty@tty7.service >After=getty@tty7.service > > fixes the problem. > > Andy. > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (900, 'testing'), (300, 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages sddm depends on: > ii adduser 3.118 > ii debconf [debconf-2.0] 1.5.73 > ii libc6 2.29-10 > ii libgcc-s1 10-20200222-1 > ii libpam0g 1.3.1-5 > ii libqt5core5a 5.12.5+dfsg-9 > ii libqt5dbus5 5.12.5+dfsg-9 > ii libqt5gui55.12.5+dfsg-9 > ii libqt5network55.12.5+dfsg-9 > ii libqt5qml55.12.5-5 > ii libqt5quick5 5.12.5-5 > ii libstdc++610-20200222-1 > ii libsystemd0 244.3-1 > ii libxcb-xkb1 1.13.1-5 > ii libxcb1 1.13.1-5 > ii qml-module-qtquick2 5.12.5-5
Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"
Package: k3b
Version: 20.12.2-1
Severity: normal
Tags: patch
Dear Maintainer,
With k3b, when wanting to set the external program permissions, it wants to
set
them with user "operator" instead of "cdrom" which may be more adequate
according to the description of the groups in
https://wiki.debian.org/SystemGroups
- operator: Operator was (historically) the only 'user' account that could
login remotely.
- cdrom: This group can be used locally to give a set of users access to a
CDROM drive and other optical drives.
This will patch k3b to use "cdrom" instead.
BTW, in buster, permissions used to be set to "root.root". I don't know why
it's not the same since that piece of code didn't change.
-- Package-specific info:
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
Device type: Removable CD-ROM
Version: 5
Response Format: 2
Capabilities :
Vendor_info: 'HL-DT-ST'
Identification : 'DVD+-RW GSA-H31L'
Revision : 'W618'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (991, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages k3b depends on:
ii cdparanoia 3.10.2+debian-13.1
ii cdrdao 1:1.2.4-2
ii genisoimage9:1.1.11-3.2
ii k3b-data 20.12.2-1
ii kio5.78.0-4
ii libc6 2.31-9
ii libk3b720.12.2-1
ii libkf5archive5 5.78.0-2
ii libkf5authcore55.78.0-2
ii libkf5bookmarks5 5.78.0-2
ii libkf5cddb54:20.12.0-1
ii libkf5completion5 5.78.0-3
ii libkf5configcore5 5.78.0-4
ii libkf5configwidgets5 5.78.0-2
ii libkf5coreaddons5 5.78.0-2
ii libkf5i18n55.78.0-2
ii libkf5iconthemes5 5.78.0-2
ii libkf5jobwidgets5 5.78.0-2
ii libkf5kcmutils55.78.0-3
ii libkf5kiocore5 5.78.0-4
ii libkf5kiofilewidgets5 5.78.0-4
ii libkf5kiowidgets5 5.78.0-4
ii libkf5newstuff55.78.0-2
ii libkf5notifications5 5.78.0-2
ii libkf5notifyconfig55.78.0-2
ii libkf5service-bin 5.78.0-2
ii libkf5service5 5.78.0-2
ii libkf5solid5 5.78.0-2
ii libkf5widgetsaddons5 5.78.0-2
ii libkf5xmlgui5 5.78.0-2
ii libqt5core5a 5.15.2+dfsg-4
ii libqt5dbus55.15.2+dfsg-4
ii libqt5gui5 5.15.2+dfsg-4
ii libqt5webkit5 5.212.0~alpha4-11
ii libqt5widgets5 5.15.2+dfsg-4
ii libqt5xml5 5.15.2+dfsg-4
ii libstdc++6 10.2.1-6
ii udisks22.9.2-1
ii wodim 9:1.1.11-3.2
Versions of packages k3b recommends:
ii dvd+rw-tools 7.1-14+b1
ii growisofs7.1-14+b1
ii libk3b7-extracodecs 20.12.2-1
ii vcdimager2.0.1+dfsg-5
Versions of packages k3b suggests:
pn k3b-extrathemes
ii k3b-i18n 20.12.2-1
ii kde-config-cddb 4:20.12.0-1
pn movixmaker-2
ii normalize-audio 0.7.7-16
ii sox 14.4.2+git20190427-2
-- no debconf information
Description:
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
k3b (20.12.2-1.0~fab1) UNRELEASED; urgency=medium
.
* Personnal changelog entry 03/02/21 11:53:38
Author: Anonymous
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded:
Reviewed-By:
Last-Update: 2021-03-02
--- k3b-20.12.2.orig/src/option/k3bexternalbinwidget.cpp
+++ k3b-20.12.2/src/option/k3bexternalbinwidget.cpp
@@ -152,9 +152,7 @@ K3b::ExternalBinWidget::ExternalBinWidge
while (::group *g = ::getgrent()) {
const QString groupName = QString::fromLocal8Bit(g->gr_name);
-if (groupName == "cdrom" ||
-groupName == "optical" ||
-groupName == "operator" ) {
+if (groupName == "cdrom") {
m_permissionModel->setBurningGroup(groupName);
}
}
Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"
Hello,
> Well, the original code is rather bad indeed, because it relies on the
> order of groups returned by getgrent, and picks the *last* available
> one. In your case, if you have an "operator" group, it will be used.
Ok, this explains it then.
Well it's a fresh debian install of testing/bullseye to find some bugs before
the upcoming release. And on a fresh install "operator" group is present.
If k3b's deb could be fixed for the next release of debian so that the package
conforms debian's policies that would be great. I think this patch is
sufficient since the group that fits this purpose, according to the group
definition is "cdrom", so no need to search any other, and on debian it does
exist.
Regards
Le mardi 2 mars 2021, 14:31:12 CET Norbert Preining a écrit :
> Hi,
>
> not that I am an expert, and cd burning is anyway only for maniacs (like
> me!!!) who want to get into contact with whom-who-must-not-be-named.
>
> > With k3b, when wanting to set the external program permissions, it wants
> > to
> > set them with user "operator" instead of "cdrom" which may be more
> > adequate
> >
> > while (::group *g = ::getgrent()) {
> >
> > const QString groupName = QString::fromLocal8Bit(g->gr_name);
> >
> > -if (groupName == "cdrom" ||
> > -groupName == "optical" ||
> > -groupName == "operator" ) {
> > +if (groupName == "cdrom") {
> >
> > m_permissionModel->setBurningGroup(groupName);
> >
> > }
> >
> > }
>
> Well, the original code is rather bad indeed, because it relies on the
> order of groups returned by getgrent, and picks the *last* available
> one. In your case, if you have an "operator" group, it will be used.
>
> I am not sure, maybe this is intended, but I guess there should be
> either a break out of the loop after the first groupname is found,
> or something else.
>
> Best
>
> Norbert
>
> --
> PREINING Norbert https://www.preining.info
> Fujitsu Research Labs + IFMGA Guide + TU Wien + TeX Live + Debian Dev
> GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#983861: k3b: Permissions of external program should be of group "cdrom" and not "operator"
Hello Norbert,
This is still relevant for 22.04.2-1
Would you please add that patch to the package?
Since the "operator" group is present on a fresh install of Debian, and since
it is prefered to have group "cdrom" used by k3b, I think it would be better
if the patch was applied.
Rgds
Fab
Le mardi 2 mars 2021, 16:59:35 CEST Fab Stz a écrit :
> Hello,
>
> > Well, the original code is rather bad indeed, because it relies on the
> > order of groups returned by getgrent, and picks the *last* available
> > one. In your case, if you have an "operator" group, it will be used.
>
> Ok, this explains it then.
>
> Well it's a fresh debian install of testing/bullseye to find some bugs
> before the upcoming release. And on a fresh install "operator" group is
> present.
>
> If k3b's deb could be fixed for the next release of debian so that the
> package conforms debian's policies that would be great. I think this patch
> is sufficient since the group that fits this purpose, according to the
> group definition is "cdrom", so no need to search any other, and on debian
> it does exist.
>
> Regards
>
> Le mardi 2 mars 2021, 14:31:12 CET Norbert Preining a écrit :
> > Hi,
> >
> > not that I am an expert, and cd burning is anyway only for maniacs (like
> > me!!!) who want to get into contact with whom-who-must-not-be-named.
> >
> > > With k3b, when wanting to set the external program permissions, it wants
> > > to
> > > set them with user "operator" instead of "cdrom" which may be more
> > > adequate
> > >
> > > while (::group *g = ::getgrent()) {
> > >
> > > const QString groupName = QString::fromLocal8Bit(g->gr_name);
> > >
> > > -if (groupName == "cdrom" ||
> > > -groupName == "optical" ||
> > > -groupName == "operator" ) {
> > > +if (groupName == "cdrom") {
> > >
> > > m_permissionModel->setBurningGroup(groupName);
> > >
> > > }
> > >
> > > }
> >
> > Well, the original code is rather bad indeed, because it relies on the
> > order of groups returned by getgrent, and picks the *last* available
> > one. In your case, if you have an "operator" group, it will be used.
> >
> > I am not sure, maybe this is intended, but I guess there should be
> > either a break out of the loop after the first groupname is found,
> > or something else.
> >
> > Best
> >
> > Norbert
> >
> > --
> > PREINING Norbert https://www.preining.info
> > Fujitsu Research Labs + IFMGA Guide + TU Wien + TeX Live + Debian Dev
> > GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Bug#1025663: qmake6: how should users query for QT_INSTALL_PLUGINS?
Hello, Not sure this fits your issue and if this could work. I used to produce android-builds that are sort of 'target' builds (and not host builds). There is a specific qmake to be called when building with a target-build. That qmake is in the bin directory of the target build. And that qmake uses the "target_qt.conf" file which should contain the path you expect. However, for now, not all path are there and especially the Plugins dir isn't there. They will be once this is merged: https://codereview.qt-project.org/c/qt/qtbase/+/436758/19/cmake/ QtQmakeHelpers.cmake Maybe a solution could be to run qmake by specifying your own target_qt.conf that has the values you need ? Regards Fab On Wed, 7 Dec 2022 08:04:54 +0100 Helmut Grohne wrote: > Package: qmake6 > Version: 6.3.1+dfsg-10 > Severity: important > Control: affects -1 + src:fcitx-qt5 > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > X-Debbugs-Cc: debian-cr...@lists.debian.org > > Hi, > > we've hit an interesting issue with qmake for QT6. This almost certainly > is a pattern and I'll use fcitx-qt5 as an example. > > fcitx-qt5 looks for a target Qt6::qmake and queries its LOCATION > property to be able to run it. Then it runs that with -query > QT_INSTALL_PLUGINS to locate the installation directory for plugins. > Unfortunately, what it gets is the build architecture one rather than > the host architecture one. > > The crux of this is that /usr/bin/qmake6 cannot know about the host > architecture. That information is a parameter of the build and nothing > has passed this information along to it. It cannot just pull this > information out of nothing. So we basically have two options: > > a) Make sure that Qt6::qmake's LOCATION resolves to something that >includes the information of the host architecture somehow. > b) Declare that this method of querying qmake is unsupported and fix >every package (including fcitx-qt5) in some other way. > > For b), I have no clue what that other way would be. If someone knows, > that would be great. I also have little clue how frequent this pattern > is and how many packages we would have to fix. The expectation is "many" > from my experience with QT5. > > The implications of a) are quite well understood, because that's the > route we opted for with QT5. It's a fairly involved route that took us > more than a year to work properly, but maybe we can speed up by learning > from earlier mistakes, so how does it work? > > The qmake6 package gains new binaries /usr/bin/-qmake6. These > actually are shell scripts that wrap qmake6 and inject the information > about the host architecture into the command line. Then, we centrally > divert Qt6::qmake to this location and everything will magically work. > To get an idea how this works, install qt5-qmake and look at > /usr/bin/$(dpkg -qDEB_BUILD_GNU_TYPE)-qmake. That should be fairly > obvious. We're in a far better position than we started with QT5 as we > already have the necessary qmake6 vs qmake6-bin split in place in > exactly the way it needs to be. Also a number of client packages have > been switched from AC_PATH_PROG to AC_PATH_TOOL for locating qmake > already. > > What we need now is a choice on which way we do it. The choice > essentially is: > > a) Add architecture-specific qmake wrappers for QT6. > b) Declare that running qmake6 -query SOMEVAR is unsupported. > > Patrick and Pino, what's your thoughts on this? If you feel like you > cannot make such a choice, let us figure out what information is > missing.
Qt4Android, building 4 archs/binary packages from 1 source archive
Hello, I'm trying to package Qt for Android. With v5.12, one has to run ./configure with -android-arch option This options takes only one value at a time. So I can compile once for armeabi-v71. Then after that, restart and compile the arm64-v8a version, and the x86 & x86_64... That makes 4 times the same run except that I just change one parameter. That would lead to have 4 almost identical debian/rules Instead of multiplying debian/rules (and debian.tar.xz...), is it possible in some way to have only one debian/rules that would build 4 binary packages named qt4android-armeabi-v71, qt4android-arm64-v8a, qt4android-x86...? I would have defined these binary packages in debian/control. Or do I have to create 4 packages (ie .debian.tar.xz) with 4 times the same .orig.tar.xz ? Thanks a lot Fab
Bug#988596: akonadi-server: akonadi crashes permanently; akonadiconsole does not start
Hello, I had the same problem after migrating from Buster to Bullseye. However, I remembered that in the past I moved the akonadi folder in ~/.local/ share/ to another partition and then created a symbolic link to it. I reverted that and relocated the akonadi folder to its initial place, what fixed the problem for me. I don't really know AppArmor, but I noticed that akonadiserver didn't have a profile in buster but has one in bullseye. Maybe this can help someone. Regards On Tue, 24 Aug 2021 18:10:27 +0200 Matteo Semplice wrote: > Hi. > > Same issue on my machine after upgrading it to Debian 11. > > The file .local/share/akonadi/Akonadi.error contains > > 2021-08-24T18:02:17 [WARN ] default: Connecting to deprecated signal > QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) > 2021-08-24T18:04:38 [WARN ] org.kde.pim.akonadicontrol: ProcessControl: > Application '/usr/bin/akonadiserver' returned with exit code 253 (Errore > sconosciuto) > 2021-08-24T18:05:39 [WARN ] org.kde.pim.akonadicontrol: ProcessControl: > Application '/usr/bin/akonadiserver' returned with exit code 253 (Errore > sconosciuto) > > Thanks, > > Matteo > > >
Bug#1030211: qt6-charts-dev should depend on qml6-module-qtcharts?
Package: qt6-charts-dev Version: 6.4.2-1 Severity: normal Dear Maintainer, I was trying to configure a project which Build-Depends on qt6-charts-dev At build time I have the error below. If I install also qml6-module-qtcharts, then configure is made successfully. Should this be added as a dependency in qt6-charts-dev? Error: CMake Error at /usr/lib/x86_64-linux- gnu/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Targets.cmake:96 (message): The imported target "Qt6::qtchartsqml2" references the file -- Configuring incomplete, errors occurred! "/usr/lib/x86_64-linux-gnu/qt6/qml/QtCharts/libqtchartsqml2plugin.so" See also "/home/runner/work/welle.io/welle.io/build/CMakeFiles/CMakeOutput.log". but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/x86_64-linux- gnu/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Targets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/x86_64-linux- gnu/cmake/Qt6Qml/QmlPlugins/Qt6qtchartsqml2Config.cmake:61 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt6Qml/Qt6QmlPlugins.cmake:18 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt6Qml/Qt6QmlConfig.cmake:133 (include) /usr/local/share/cmake-3.25/Modules/CMakeFindDependencyMacro.cmake:47 (find_package) /usr/lib/x86_64-linux-gnu/cmake/Qt6/QtPublicDependencyHelpers.cmake:108 (find_dependency) /usr/lib/x86_64-linux-gnu/cmake/Qt6Quick/Qt6QuickDependencies.cmake:39 (_qt_internal_find_qt_dependencies) /usr/lib/x86_64-linux-gnu/cmake/Qt6Quick/Qt6QuickConfig.cmake:50 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:167 (find_package) CMakeLists.txt:58 (find_package) CMake Warning at /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:167 (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. Call Stack (most recent call first): CMakeLists.txt:58 (find_package) -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (991, 'stable-updates'), (991, 'stable'), (95, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qt6-charts-dev depends on: pn libqt6charts6 pn libqt6chartsqml6 pn qt6-base-dev qt6-charts-dev recommends no packages.
