Bug#1054919: kaccounts-providers: google authentication hang after username entry

2023-11-09 Thread Alexis Murzeau 

On 09/11/2023 03:04, Nicholas D Steeves wrote:

Hi,

I received a report from sney (in #debian-qt-kde on OFTC) that a
workaround is no longer necessary in either kaccounts-providers or
signon-ui.

Thus it sounds like this was a case #1 problem
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054919#24)

 1. Google refuses to talk to Qt webkit/QtWebEngine that identifies
 itself accurately.

and it appears that they've reverted the action that broke everyone's
access to their Google accounts.  This is the most correct solution and
the best possible outcome.

Alexis and Peter, would you please confirm that the workaround is no
longer necessary?  And please leave the bug open even if Google accounts
are working again, because the frequency of this breakage has been
mounting.


Yes it works again now (with the workaround removed).
I can login into my google account.

I found where I got this workaround, this is what has done dabiswas112
in a fedora COPR in hazel-bunny/ports:
https://github.com/hazel-bunny/rpm-packaging/blob/master/lib/signon/signon-ui/fake-user-agent.patch

This COPR was suggested here:
https://bugzilla.redhat.com/show_bug.cgi?id=2230099.


--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1054919: kaccounts-providers: google authentication hang after username entry

2023-11-06 Thread Alexis Murzeau 

On 06/11/2023 22:17, Nicholas D Steeves wrote:


Once again, thank you, much appreciated!  And yes, I think that you have
the right idea, and reported this bug in the right package.  By the way,
did you copy this solution from somewhere else (like Fedora's COPR or
somewhere in Arch Linux), or is



I've got this solution from someone on internet, but I can't find it 
again (something like reddit or a forum IIRC).


I will be able to check my browse history only this week-end as I'm not 
on the same PC currently.


--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



OpenPGP_0xE7BD1904F480937F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054919: kaccounts-providers: google authentication hang after username entry

2023-10-29 Thread Alexis Murzeau 

Hi,

Thanks for your reply!

On 29/10/2023 18:30, Nicholas D Steeves wrote:

The webpage issue is maybe caused by the use of Qt webkit, using an older
UserAgent probably causes Google to offer an older login page that works with
Qt webkit.


That sounds plausible to me.  If that's the case then it seems like it
may be better to patch Qt webkit.  I wonder if this is a case where
whatever UserAgent Qt webkit validated is the one the package declares
(where it shouldn't be overridden for the general case), or if everybody
involved just forgot to update it?


As the UserAgent is required to make the login work, can it be added to the
package ?


Agreed, either Qt webkit should be fixed, or else kaccount-providers
should begin overriding UserAgent.  It's nice to see a Google issue that
we can fix on our side!

Best,
Nicholas



I'm not sure how Qt webkit works, but I guess it behaves like a old
chrome browser. I don't know if it uses a different user agent, but
maybe Google doesn't recognize that it doesn't support newer web stuff.

Qt 6 doesn't seem to have Qt webkit anymore, but QtWebEngine instead.
I guess signon-ui should move to QtWebEngine instead but sadly upstream
seems rather dead :(, the previous signon-ui release was more than 5
years ago.

That's in fact why I've opened a report on this package, it seemed to be
the more feasible and realistic solution.
It is a chance that google signon can still work :)

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1054919: kaccounts-providers: google authentication hang after username entry

2023-10-28 Thread Alexis Murzeau 

Package: kaccounts-providers
Version: 4:22.12.3-2
Severity: important
Tags: patch

Dear Maintainer,

When trying to login to a google account to use google drive with kio-gdrive,
the authentication hang.

The reproduction steps are:
- Open systemsettings
- Go to online accounts
- Add a new account and choose "Google"
- A webpage dialog is opened with the google login page
- Enter the username then click on "Next" on the google login page
- The webpage hangs there and never goes to the next page


To fix this, I've put this line in /etc/signon-ui/webkit-
options.d/accounts.google.com.conf:
UserAgent = Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101
Firefox/77.0

The webpage issue is maybe caused by the use of Qt webkit, using an older
UserAgent probably causes Google to offer an older login page that works with
Qt webkit.

As the UserAgent is required to make the login work, can it be added to the
package ?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (950, 'unstable'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kaccounts-providers depends on:
ii  kio   5.107.0-1
ii  kpackagetool5 5.107.0-1
ii  libc6 2.37-12
ii  libkaccounts2 4:22.12.3-1
ii  libkf5coreaddons5 5.107.0-1
ii  libkf5declarative55.107.0-1
ii  libkf5i18n5   5.107.0-1+b1
ii  libkf5kiocore55.107.0-1
ii  libkf5package55.107.0-1
ii  libqt5core5a  5.15.10+dfsg-3
ii  libqt5gui55.15.10+dfsg-3
ii  libqt5qml55.15.10+dfsg-2
ii  libqt5webengine5  5.15.15+dfsg-2+b1
ii  libqt5webenginecore5  5.15.15+dfsg-2+b1
ii  libqt5xml55.15.10+dfsg-3
ii  libstdc++613.2.0-5
ii  plasma-framework  5.107.0-1
ii  qml-module-org-kde-kirigami2  5.107.0-1+b1
ii  qml-module-qtquick-controls   5.15.10-2
ii  qml-module-qtquick-layouts5.15.10+dfsg-2
ii  qml-module-qtquick2   5.15.10+dfsg-2
ii  qml-module-qtwebengine5.15.15+dfsg-2+b1
ii  signon-plugin-oauth2  0.25-2

Versions of packages kaccounts-providers recommends:
ii  libkf5purpose-bin  5.107.0-1

kaccounts-providers suggests no packages.

-- Configuration Files:
/etc/signon-ui/webkit-options.d/accounts.google.com.conf changed:
ViewportWidth = 480
ViewportHeight = 420
UsernameField = input[name="Email"]
PasswordField = input[name="Passwd"]
AllowedUrls = (https://.*|http://[^/]*google\\.[^.]+/accounts/.*)
UserAgent = Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/77.0


-- no debconf information

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1053615: partitionmanager: no device found

2023-10-07 Thread Alexis Murzeau 

Package: partitionmanager
Version: 22.12.3-1
Severity: important

Dear Maintainer,

When opening partitionmanager, it asks for the root password to retrieve all
disk devices.
Then is scan for devices, but find nothing.

gparted correctly shows all disks (and their partition).

The log is not very verbose:
$ partitionmanager
Loaded backend plugin:  "pmsfdiskbackendplugin"
"Using backend plugin: pmsfdiskbackendplugin (1)"
"Scanning devices..."
"Scan finished."

Recommends dependencies are not installed, but I still have dosfstools and
ntfs-3g (I only have ext4 and ntfs partitions across all disks).
Other recommended dependencies are about file system I don't use.

This makes partitionmanager unusable (but I don't know since when).

Thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (950, 'unstable'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages partitionmanager depends on:
ii  kio   5.107.0-1
ii  libc6 2.37-12
ii  libkf5configcore5 5.107.0-1
ii  libkf5configgui5  5.107.0-1
ii  libkf5configwidgets5  5.107.0-2
ii  libkf5coreaddons5 5.107.0-1
ii  libkf5crash5  5.107.0-1
ii  libkf5dbusaddons5 5.107.0-1
ii  libkf5i18n5   5.107.0-1+b1
ii  libkf5jobwidgets5 5.107.0-1
ii  libkf5kiocore55.107.0-1
ii  libkf5kiogui5 5.107.0-1
ii  libkf5widgetsaddons5  5.107.0-1
ii  libkf5windowsystem5   5.107.0-1
ii  libkf5xmlgui5 5.107.0-1+b1
ii  libkpmcore12  22.12.3-1
ii  libpolkit-qt5-1-1 0.114.0-2
ii  libqt5core5a  5.15.10+dfsg-3
ii  libqt5gui55.15.10+dfsg-3
ii  libqt5widgets55.15.10+dfsg-3
ii  libstdc++613.2.0-5

partitionmanager recommends no packages.

Versions of packages partitionmanager suggests:
pn  btrfs-progs
ii  dosfstools 4.2-1
pn  hfsplus
pn  hfsutils   
pn  jfsutils   
ii  ntfs-3g1:2022.10.3-1+b1
pn  reiser4progs   
pn  reiserfsprogs  
pn  xfsprogs   

-- no debconf information

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1052012: plasma-workspace: sddm presents a white screen with no background nor buttons

2023-09-16 Thread Alexis Murzeau 

Hi,

On Sat, 16 Sep 2023 00:55:12 +0200 Miguel Angel Rojas  
wrote:

Hi there,

Downgrading the following packages:

   - sddm-themes-breeze
   - sddm-theme-debian-breeze

to version 4:5.27.7-2 makes sddm fully usable again with no issues.

It seems some changes have been made on version 4:5.27.8-1 that have broken
sddm.

I hope this helps.

Regards



I have issues too with sddm-theme-debian-breeze 5.27.8-1, but the symptom is 
different.
I get a correct screen, but the password field has a very small font size and 
each character is 1 pixel.

Using diffoscope, it appears sddm-theme-debian-breeze 5.27.8-1 doesn't have the 
theme.conf file.
Adding back theme.conf from version 5.27.7-2 with 5.27.8-1 installed fix the 
issue for me.

Note: metadata.desktop was also removed in 5.27.8-1, maybe it shouldn't too.


@Miguel, can you try to do the same to check if theme.conf is also the cause of 
your issues ?

That is, adding `/usr/share/sddm/themes/debian-breeze/theme.conf` with this 
content:

```
[General]
showlogo=hidden
logo=/usr/share/sddm/themes/breeze/default-logo.svg
type=image
color=#1d99f3
fontSize=10
background=/usr/share/desktop-base/active-theme/login/background.svg
needsFullUserModel=false
```


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (950, 'unstable'), (500, 'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sddm-theme-debian-breeze depends on:
ii  plasma-framework   5.107.0-1
ii  plasma-workspace   4:5.27.8-1
ii  sddm-theme-breeze  4:5.27.8-1

Versions of packages sddm-theme-debian-breeze recommends:
ii  desktop-base  12.0.6+nmu1
ii  sddm  0.20.0-1

sddm-theme-debian-breeze suggests no packages.

-- no debconf information


--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1031243: plasma-workspace: mute icon on task bar appears on wrong applications

2023-02-13 Thread Alexis Murzeau 
 5.26.90-1
ii  plasma-workspace-data   4:5.26.90-1
ii  qdbus-qt5   5.15.8-2
ii  qml-module-org-kde-draganddrop  5.102.0-1
ii  qml-module-org-kde-kcoreaddons  5.102.0-1
ii  qml-module-org-kde-kholidays1:5.102.0-1
ii  qml-module-org-kde-kquickcontrols   5.102.0-1
ii  qml-module-org-kde-kquickcontrolsaddons 5.102.0-1
ii  qml-module-org-kde-ksysguard4:5.26.90-1
ii  qml-module-org-kde-kwindowsystem5.102.0-1
ii  qml-module-org-kde-prison   5.102.0-1
ii  qml-module-org-kde-quickcharts  5.102.0-1
ii  qml-module-org-kde-solid5.102.0-1
ii  qml-module-org-kde-userfeedback 1.2.0-2
ii  qml-module-qt-labs-folderlistmodel  5.15.8+dfsg-2
ii  qml-module-qtgraphicaleffects   5.15.8-2
ii  qml-module-qtqml-models25.15.8+dfsg-2
ii  qml-module-qtquick-controls 5.15.8-2
ii  qml-module-qtquick-dialogs  5.15.8-2
ii  qml-module-qtquick-layouts  5.15.8+dfsg-2
ii  qml-module-qtquick-window2  5.15.8+dfsg-2
ii  qml-module-qtquick2 5.15.8+dfsg-2
ii  udisks2 2.9.4-4
ii  x11-utils   7.7+5
ii  x11-xserver-utils   7.7+9+b1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages plasma-workspace recommends:
ii  kde-cli-tools4:5.26.90-1
ii  kio-extras   4:22.12.2-1
ii  ksystemstats 5.26.90-1
pn  libpam-kwallet5  
ii  powerdevil   4:5.26.90-1
pn  qml-module-org-kde-pipewire  
ii  systemsettings   4:5.26.90-1

plasma-workspace suggests no packages.

-- no debconf information

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023580: A recent Bookworm upgrade broke video playback in the VLC player

2022-11-13 Thread Alexis Murzeau 

Control: forwarded -1 https://bugreports.qt.io/browse/QTBUG-108407

On 12/11/2022 19:02, Alexis Murzeau wrote:

On 11/11/2022 21:50, Alexis Murzeau wrote:


I've tried to create a minimal Qt sample application that would reproduce the 
issue, but I can't get it.
Maybe there is something related with a specific feature or configuration.



Instead of trying to create a minimal Qt application that reproduce the 
problem, I've tried to reproduce the issue with rebuilt Qt binaries from 
upstream.
I'm successfully reproducing the issue with virtualbox and vlc with a Qt build 
of the tag v5.15.6-lts-lgpl but not with a build of v5.15.4-lts-lgpl.

So I'm going to bisect commits to find which one introduced the issue.



I've found the offending commit.
It's 290b405872602de931646fe4f769eff208f9bbef: xcb: implement missing bits
from ICCCM 4.1.4 WM_STATE handling.

See here: 
https://github.com/qt/qtbase/commit/290b405872602de931646fe4f769eff208f9bbef

It was made to fix https://bugreports.qt.io/browse/QTBUG-69515, but
reverted later in upcoming version 5.15.10.

I've tested v5.15.6 with this commit reverted, and vlc and virtualbox
doesn't have the issue anymore, so reverting only this commit seems
sufficient to fix this bug.

Because of 2 regressions bugs, this commit was already reverted in upstream
versions 5.15.10, 6.2.5, 6.3.1 and 6.4.0+ (see "resulted in" in QTBUG-69515).


I'm not sure if this bug (affecting vlc and virtualbox) is already known
in this form by upstream, existing upstream bugs only talk about to
window undocking and menus.

So I've created a bug upstream about it, as this affect popular
applications, to ensure upstream is aware of it:
https://bugreports.qt.io/browse/QTBUG-108407

Also as a reference, Debian bug #1022748 is caused by the same commit
290b405872602de931646fe4f769eff208f9bbef.


--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F |

Bug#1023580: A recent Bookworm upgrade broke video playback in the VLC player

2022-11-12 Thread Alexis Murzeau 

On 11/11/2022 21:50, Alexis Murzeau wrote:


I've tried to create a minimal Qt sample application that would reproduce the 
issue, but I can't get it.
Maybe there is something related with a specific feature or configuration.



Instead of trying to create a minimal Qt application that reproduce the 
problem, I've tried to reproduce the issue with rebuilt Qt binaries from 
upstream.
I'm successfully reproducing the issue with virtualbox and vlc with a Qt build 
of the tag v5.15.6-lts-lgpl but not with a build of v5.15.4-lts-lgpl.

So I'm going to bisect commits to find which one introduced the issue.

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#1023580: A recent Bookworm upgrade broke video playback in the VLC player

2022-11-11 Thread Alexis Murzeau 

Hi,

On 09/11/2022 14:00, Lisandro Damián Nicanor Pérez Meyer wrote:

tag 1023580 unreproducible moreinfo
thanks

Hi!




First of all thanks for the detailed reproduction steps. I don't seem
able to reproduce the bug on my machine, so something else must be
playing its part here. Are you running on Wayland or X? Which video
card do you have? Are you using the FLOSS drivers for it? If you can
think of any other detail that might be related here, please do not
hesitate in adding it.

Kinds regards, Lisandro.



I'm running on X and reproduced it with:
 - AMD Radeon RX 580 GPU (with xserver-xorg-video-amdgpu driver)
 - Intel HD Graphics 4000 (ivy bridge) (with xserver-xorg-video-intel driver)
 - VirtualBox VM with xserver-xorg-video-vmware and xserver-xorg-video-vesa 
drivers

I'm not running non-free or contrib driver on any of these hardware (except 
firmware-amd-graphics with AMD GPU and microcode firmwares (intel and amd 
physical machines)).
On the virtualbox VM, I'm not running anything outside main.

I'm not on the PC that has the VM right now, but will be next week.
The VM is containing these packages:
 - Debian Unstable without any tasks (nothing selected on Debian Installer)
 - xserver-xorg
 - vlc
 - icewm and fluxbox (or anything you like to have an X environment)
 - xinit (for startx)
 - You might be required to put your user in the `input` group
   (else the mouse and keyboard might not work)
 - Run startx, then run vlc with a video
- Play the video
- Stop the video
- Open the playlist (CTRL + L)
- Play the video again, stop it again
- Resize the VLC window (while the playlist is open)

This reproduce the issue for me with VirtualBox.
I think the emulated GPU controller is "VMSVGA", I will be able to
confirm this next week, but I've not installed guest additions.

I've tried to create a minimal Qt sample application that would reproduce the 
issue, but I can't get it.
Maybe there is something related with a specific feature or configuration.

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#1023580: A recent Bookworm upgrade broke video playback in the VLC player

2022-11-07 Thread Alexis Murzeau 

Control: found 1023580 5.15.7+dfsg-1

On 07/11/2022 22:27, local10 wrote:


Tried it again with the playlist window. This is how it works for me:

1. Open VLC > Ctrl+L > My Videos > Don't click on any of the videos > Start 
changing the size of the window > no scaling effect is observed, all border are redrawn 
properly

2. Open VLC > Ctrl+L > My Videos > Start playing one of the videos, then stop it > 
Ctrl+L > Start changing the size of the window > scaling effect is clearly observed, the 
video list right and bottom borders are NOT redrawn properly, the effect is very similar to what 
is shown in the qt_5.15.6+dfsg-2_vlc_glitches.mp4 video. See the enclosed file for details.

Regards,



Ok thanks, so you get it too, I'm not the only one to have this :)
(And if you playback the video again, it will show a black screen (if it wasn't 
the case the first time))


I guess the issue might appear a bit differently from user to user but is 
probably the same cause.
I'm trying to find a way to reproduce it easily and maybe find what goes wrong.
I've tried with the Qt version in experimental (5.15.7), but sadly the behavior 
is the same.


--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023372: kde-config-gtk-style: missing dependency on gsettings-desktop-schemas (causes kded5 to crash)

2022-11-02 Thread Alexis Murzeau 

Package: kde-config-gtk-style
Version: 4:5.26.0-1
Severity: important

Dear Maintainer,


   * What led up to the situation?

In a KDE environment and plasma-nm installed, WiFi is not connecting
automatically with the NetworkMaanger error "No agents were available for this
request".
Normally, agent requests are served using the KDE Wallet.

The cause of this is that kded5 wasn't running, thus the service handling agent
requests was probably not running too.

kded5 was not running because it crashed with this error (I've run it with
gdb):

(process:4612): GLib-GIO-ERROR **: 23:53:37.684: Settings schema
'org.gnome.desktop.interface' is not installed

Thread 1 "kded5" received signal SIGTRAP, Trace/breakpoint trap.
0x759287c7 in g_log_structured_array () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
(gdb) bt
#0  0x759287c7 in g_log_structured_array () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#1  0x75928bee in g_log_default_handler () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2  0x75928e57 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x759290ef in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fffd8c94a37 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0
#5  0x7fffd8b516ed in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#6  0x7fffd8b51f98 in ?? () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0
#7  0x7fffd8b53b33 in g_object_new_valist () from /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#8  0x7fffd8b54189 in g_object_new () from /lib/x86_64-linux-
gnu/libgobject-2.0.so.0
#9  0x7fffd8ddf340 in ?? () from /usr/lib/x86_64-linux-
gnu/qt5/plugins/kf5/kded/gtkconfig.so
#10 0x7fffd8ddb475 in GtkConfig::setFont() const () from
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#11 0x7fffd8ddda59 in GtkConfig::applyAllSettings() const () from
/usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#12 0x7fffd8dddf99 in GtkConfig::GtkConfig(QObject*, QList
const&) () from /usr/lib/x86_64-linux-gnu/qt5/plugins/kf5/kded/gtkconfig.so
#13 0x7fffd8ddef69 in ?? () from /usr/lib/x86_64-linux-
gnu/qt5/plugins/kf5/kded/gtkconfig.so
#14 0x7773ead3 in KPluginFactory::create(char const*, QWidget*,
QObject*, QList const&, QString const&) () from /lib/x86_64-linux-
gnu/libKF5CoreAddons.so.5
#15 0xdeee in ?? ()
#16 0x555611a3 in ?? ()
#17 0x55561533 in ?? ()
#18 0xb15e in ?? ()
#19 0x7684618a in __libc_start_call_main
(main=main@entry=0xaa90, argc=argc@entry=1,
argv=argv@entry=0x7fffdfe8) at ../sysdeps/nptl/libc_start_call_main.h:58
#20 0x76846245 in __libc_start_main_impl (main=0xaa90, argc=1,
argv=0x7fffdfe8, init=, fini=,
rtld_fini=,
stack_end=0x7fffdfd8) at ../csu/libc-start.c:381
#21 0xb541 in ?? ()
(gdb)

The crash occurs in gtkconfig.so kded5 plugin (installed by kde-config-gtk-
style pacakge) because gsettings-desktop-schemas is not installed.

After having installed this package, everything is back working as expected
(and the wifi connects once I input the asked KWallet password on login).



Thus, I think that kde-config-gtk-style should depends on gsettings-desktop-
schemas.

This does not apply to kde-config-gtk-style-preview which won't cause any
crashes even if gsettings-desktop-schemas is not installed (as long as kde-
config-gtk-style is not installed).



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

Kernel: Linux 6.0.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: 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)

Versions of packages kde-config-gtk-style depends on:
ii  libc6 2.35-3
ii  libglib2.0-0  2.74.0-3
ii  libgtk-3-03.24.34-3
ii  libkdecorations2-5v5  4:5.26.0-1
ii  libkdecorations2private9  4:5.26.0-1
ii  libkf5configcore5 5.98.0-1
ii  libkf5configwidgets5  5.98.0-1
ii  libkf5coreaddons5 5.98.0-1
ii  libkf5dbusaddons5 5.98.0-1
ii  libkf5guiaddons5  5.98.0-2
ii  libqt5core5a  5.15.6+dfsg-2
ii  libqt5dbus5   5.15.6+dfsg-2
ii  libqt5gui55.15.6+dfsg-2
ii  libqt5svg55.15.6-2
ii  libstdc++612.2.0-7

Versions of packages kde-config-gtk-style recommends:
pn  xsettingsd | xsettings-kde  

Versions of packages kde-config-gtk-style suggests:
pn  kde-config-gtk-style-preview  

-- no debconf information

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|


OpenPGP_signature
Description: OpenPGP digital signature

Bug#979577: qtcreator: Clang Code Model no longer finds 'stddef.h' since version 4.14.0-2

2021-01-09 Thread Alexis Murzeau 
Hi,

On Fri, 8 Jan 2021 17:49:57 +0100 Michael Weghorn  wrote:> 
> The issue is still reproducible after downgrading the LLVM/Clang 
> packages this way.
> 
> It disappears when downgrading qtcreator and qtcreator-data to 4.14.0-1, 
> though.
> 
> Michael
> 
> 

I have the same behavior, qtcreator 4.14.0-1 works fine, but upgrading
qtcreator to 4.14.0-2 (without upgrading any other package) cause
highlighting errors about stddef.h.


So to sum up details bellow, the issue comes from bad values in
CLANG_INCLUDE_DIR define.

CLANG_INCLUDE_DIR, CLANG_BINDIR and RELATIVE_LIBEXEC_PATH have different
path than before, partially caused by a probably wrong IDE_LIBEXEC_PATH
cmake variable.

Upstream has made a change to use system paths, probably helping with bad
IDE_LIBEXEC_PATH value:
https://bugreports.qt.io/browse/QTCREATORBUG-25142
https://codereview.qt-project.org/c/qt-creator/qt-creator/+/328958
Commit in 4.14 branch: c81baf1a9cc938a283f6c52c8fd10bab84183391

This can be backported maybe, but fixing CLANG_INCLUDE_DIR and probably
CLANG_BINDIR is still required to make the clang code model work again.



Details below:

By debugging clangbackend with a breakpoint on clang_parseTranslationUnit2,
and then printing args.m_arguments from 
TranslationUnitUpdater::createTranslationUnitIfNeeded

I've found that:
qtcreator 4.14.0-1 has "-isystem" "/usr/lib/llvm-11/lib/clang/11.0.1/include"
qtcreator 4.14.0-2 has "-isystem" "" instead

This path comes from the CLANG_INCLUDE_DIR preprocessor define used in
clangutils.cpp in LibClangOptionsBuilder constructor.

That define is set by qmake/cmake and has this value:
qtcreator 4.14.0-1 has 
-D"CLANG_INCLUDE_DIR=\"/usr/lib/llvm-11/lib/clang/11.0.1/include\""
qtcreator 4.14.0-2 has 
"-DCLANG_INCLUDE_DIR=\"libexec/qtcreator/clang/lib/clang/11.0.1/include\""

I guess the "libexec/qtcreator/clang/lib/clang/11.0.1/include" doesn't
exist and is replaced by an empty string somewhere and this explains why
it becomes empty in clangbackend process.

CLANG_INCLUDE_DIR is set in src/libs/clangsupport/CMakeLists.txt:
CLANG_INCLUDE_DIR="${IDE_LIBEXEC_PATH}/clang/lib/clang/${CLANG_VERSION}/include"

and in src/shared/clang/clang_defines.pri:
CLANG_INCLUDE_DIR=$$clean_path($${LLVM_LIBDIR}/clang/$${LLVM_VERSION}/include)


So while moving from qmake to cmake, the path became wrong, probably
because cmake scripts assume clang is bundled with qtcreator while qmake
scripts use LLVM_LIBDIR.

By checking the compiler command line used to compile clangutils.cpp,
there is other variables that have differences:
4.14.0-1:
-DCLANG_BINDIR=\"/usr/lib/llvm-11/bin\""
-DCLANG_INCLUDE_DIR=\"/usr/lib/llvm-11/lib/clang/11.0.1/include\""
-DRELATIVE_LIBEXEC_PATH="../lib/x86_64-linux-gnu/qtcreator/libexec"

4.14.0-2:
-DCLANG_BINDIR=\"libexec/qtcreator/clang/bin\"
-DCLANG_INCLUDE_DIR=\"libexec/qtcreator/clang/lib/clang/11.0.1/include\"
-DRELATIVE_LIBEXEC_PATH=\"../libexec/qtcreator\"

See build logs here:
https://buildd.debian.org/status/fetch.php?pkg=qtcreator&arch=amd64&ver=4.14.0-2&stamp=1608716918&raw=0
https://buildd.debian.org/status/fetch.php?pkg=qtcreator&arch=amd64&ver=4.14.0-1&stamp=1608260627&raw=0


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F|



signature.asc
Description: OpenPGP digital signature

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-14 Thread Alexis Murzeau 
Le 14/03/2020 à 12:54, Sylvestre Ledru a écrit :
> Le 14/03/2020 à 12:45, Alexis Murzeau a écrit :
>>
>> I still think there should be a Depends (not Recommends) on
>> libclang-common-8-dev instead somewhere. (that is, directly from
>> qtcreator or indirectly)
> What is wrong with this solution?
> 
> Sorry if I missed a potential answer for this question.
> 
> S

QtCreator's code model uses libclang-8.
If libclang-common-8-dev is not installed, QtCreator's code model won't
find some includes like  and highlight many false positive
errors in its editor.
This makes QtCreator's code model not fully working if
libclang-common-8-dev is not installed (that's why I would expect a
Depends instead of Recommends).

Installing the full clang-8 toolchain is overkill to me as only
libclang-common-8-dev is really needed to make the code model work fine,
and libclang-common-8-dev is rather small compared to the full clang
compiler.

I think the current clang Recommends is for the static analyzer given
this upstream commit bundling clang.exe for Windows:
https://github.com/qt-creator/qt-creator/commit/d02e80b87bc423f0ccb696c1b10378a74758a432
"Deploy clang binary for use by static analyzer"


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F





signature.asc
Description: OpenPGP digital signature

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-14 Thread Alexis Murzeau 
Hi,

Le 05/03/2020 à 01:12, Nicholas D Steeves a écrit :
> Hi Lisandro,
> 
> Lisandro Damián Nicanor Pérez Meyer  writes:
> 
>> Hi!
>>
>> On Wed, 4 Mar 2020 at 20:40, Nicholas D Steeves  wrote:
>>>
>>> Hi Lisandro,
>>>
>>> Out of curiosity, could this be solved for a Debian (and derivatives)
>>> context by changing the Recommends on clang and clang-tidy to their
>>> versioned package names (eg: clang-8 and clang-tidy-8)?
>>
>> No, this is not a versioning problem.
>>
> 
> I agree, ideally it should be solved upstream, but a side-effect of
> installing Recommends s/clang/clang-8/ is that it pulls in a dependency
> on libclang-common-8-dev, and
> [...]>
> My proposal would solve the Debian (and derivatives) case and is easy to
> update/maintain with a sed regex.  Is our team categorically opposed to
> working around upstream issues using Debian packaging facilities?
> 


When the recommends on clang was added, the changelog got this:
```
 * Make qtcreator recommend clang, as it has added quite interesting tools
that use it.

```

So I think the recommends is just a way so the user has recommended
tools available to qtcreator the same way `make` is recommended to build
a C/C++ project.

This is only a recommendation as the user may not want to use clang
stuff and just use, say, gcc and ninja instead for example.


I still think there should be a Depends (not Recommends) on
libclang-common-8-dev instead somewhere. (that is, directly from
qtcreator or indirectly)

This to ensure the clang code model of QtCreator (and perhaps other IDEs
that use it) works correctly and find its *builtin headers*.

Again, I emphasis on builtin headers as I do not talk about API headers
here; libclang's API headers are in a different package: libclang-8-dev.
See also my previous mail:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952718#70

@Lisandro, what do you think now given we were not talking about the
same headers before ?

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Alexis Murzeau 
Le 05/03/2020 à 00:03, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Hi again.
> 
> On Wed, 4 Mar 2020 at 19:45, Alexis Murzeau  wrote:
>>
>> Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit :
>>> Hi!
>>>
>>> El mié., 4 mar. 2020 18:11, Alexis Murzeau  escribió:
>>>
>>>> Hi,
>>>>
>>>> I've a question about whether libclang1-X should depend on
>>>> libclang-common-X-dev to always have the clang's builtin headers
>>>> available when libclang is installed.
>>>>
>>>
>>> Definitely not. Headers should depend upon the library, not the other way
>>> around.
>>>
>>>>
>>>
>>
>> Why do you think that ?
> 
> Because development files should depend upon the libraries they
> provide the headers for, not the other way around. It's the basics of
> library packaging.

libclang-common-X-dev contains clang's builtin headers which are not the
same as libclang API headers.

clang's builtin headers are not the ones providing the API of libclang
but compiler builtin functions like _mm_sqrt_ps using clang's specific
functions like __builtin_ia32_sqrtps.

The package that contains libclang's API headers is libclang-X-dev, not
libclang-common-X-dev.

So to sum up, clang has:
 - libclang-X-dev: libclang's API headers containing functions available
in libclang to manipulate AST, compile code, ... (for example
ASTMutationListener.h, CompilerInstance.h, CXCompilationDatabase.h, ...)

 - libc++-X-dev: clang's libc++ standard library headers (for example
vector, unordered_map, ...)

 - libc6-dev: GNU C standard library headers (for example stdlib.h,
stdio.h, ...)

 - libclang-common-X-dev: clang's builtin headers (for example,
immintrin.h, stddef.h, x86intrin.h, ...)

And there is also libllvm API headers:
 - libllvm-X-dev: llvm's API headers (for example IRReader.h,
LinkTimeOptimizer.h, ...)

> 
> [snip]
>> If libclang1-X should not depend on libclang-common-X-dev, then users of
>> libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile
>> code from source should depend themselves on libclang-common-X-dev as it
>> is required for them to work correctly.
> 
> And then again, wrong. Making an IDE show the header a compiler is
> **NOT** using it's plain **WRONG**. I already expressed that in the
> bug upstream and in Qt Creator's bug. Note that I did even stress the
> question in upstream's bug just to show that nobody could say
> otherwise. Neither Marko nor Thiago denied that.

This may be wrong, but having parse errors because of issues like "fatal
error: 'stddef.h' file not found" is not better. It makes qtcreator's
code model to fail to parse code, which is one of the key feature of an
IDE like this.

It's better have the IDE use clang's builtin headers than not being able
to parse code because of missing builtin headers.

> 
> So if you want a fix make clang understand other compiler's headers,
> or provide a better code parser.


Currently, whatever if this is right or wrong, the only way to fix
"fatal error: 'stddef.h' file not found" when using qtcreator or
kdevelop on Debian is to install the appropriate libclang-common-X-dev.



The toolchain used to parse the code model for qtcreator and the
toolchain used to actually compile the code can be different, but that
doesn't matter because clang already provide the appropriate *builtin*
headers to make other compilers specific functions also available with
clang.

For example, gcc provides the non standard function _get_ssp available
from immintrin.h [0], clang also does provide it in cetintrin.h builtin
header which is included by its own immintrin.h builtin header.

MSVC provides _InterlockedCompareExchange_HLEAcquire function (which is
specific to MSVC as said in [1]), clang also provides it in the same
immintrin.h builtin header (even on linux, these builtin headers are in
libclang-common-X-dev package. Or maybe guarded with some #ifdef).


So while clang support other compilers specifics, it still needs to have
its matching *builtin* headers (which are mostly only intrinsics or
platform specific stuff) as builtin headers of each compilers are
probably highly specific to the compiler they are made for (which are
different from API headers or C and C++ standard library headers).



> 
> Regards, Lisandro.
> 
> 

[0]
https://gcc.gnu.org/onlinedocs/gcc/x86-control-flow-protection-intrinsics.html#x86-control-flow-protection-intrinsics
[1]
https://docs.microsoft.com/fr-fr/cpp/intrinsics/interlockedcompareexchange-intrinsic-functions?view=vs-2019


-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Alexis Murzeau 
Le 04/03/2020 à 22:46, Lisandro Damián Nicanor Pérez Meyer a écrit :
> Hi!
> 
> El mié., 4 mar. 2020 18:11, Alexis Murzeau  escribió:
> 
>> Hi,
>>
>> I've a question about whether libclang1-X should depend on
>> libclang-common-X-dev to always have the clang's builtin headers
>> available when libclang is installed.
>>
> 
> Definitely not. Headers should depend upon the library, not the other way
> around.
> 
>>
> 

Why do you think that ?



My view on this is that libclang contains the compiler and the compiler
needs the headers but the headers don't really need the compiler to be used.
I agree that if you install the headers, you probably have to install
clang to use them anyway.

But actually, clang binaries (like clang-tidy) depends on
libclang-common-X-dev which depends on libllvm (that one is different
than libclang. libllvm is the backend of the compiler while libclang and
clang are the frontend)

So as of now, headers do not depends on libclang or clang, and clang
depends on these headers but not libclang.

clang also depends on libclang, as do QtCreator and kdevelop and other
IDE using libclang.

That's why I'm wondering if the dependency of clang-X =>
libclang-common-X-dev should be lifted to libclang1-X =>
libclang-common-X-dev.
For clang, this would start from:
clang-8 =>
libclang1-8
libclang-common-8-dev
to:
clang-8 =>
libclang1-8 =>
libclang-common-8-dev

The description of libclang1-X is:
The C Interface to Clang provides a relatively small API that exposes
facilities for:
- parsing source code into an abstract syntax tree (AST),
- loading already-parsed ASTs,
- traversing the AST,
- associating physical source locations with elements within the AST,
- and other facilities that support Clang-based development tools.

Some of them (like the one using already parsed AST) might not need
builtin headers, so it might be understandable to avoid a dependency
from libclang1 to libclang-common-X-dev.

binary rdepends on libclang1-{6.0,7,8} are:
 - doxygen
 - clang-X which also depends already on libclang-common-X-dev
 - clang-tools-X which also depends on clang
 - libclang-X-dev which also depends already on libclang-common-X-dev
 - bpftrace (high-level tracing language for Linux eBPF)
 - codelite (IDE for C, C++ and others)
 - gnat-ps (IDE for C and Ada)
 - gnome-builder which also depends on clang (IDE for C, C++ and others)
 - irony-server (Emacs C/C++ minor mode)
 - kdevelop which recommends clang (C/C++ IDE)
 - libclang-perl (libclang perl bindings)
 - qdoc-qt5 (tool to generate doc from C/C++ source files)
 - qtcreator which recommends clang (C/C++ IDE)
 - rtags which recommends libclang-common-X-dev (C/C++ client/server
indexer with integration for Emacs)
 - shiboken2 (CPython bindings generator for C++ libraries)
 - ycmd which recommends libclang-common-X-dev (code-completion &
comprehension server)

So many of them uses libclang to parse C/C++ code, but only bpftrace do
not I think (it parses the BPFTrace language instead which is based on C).

If libclang1-X should not depend on libclang-common-X-dev, then users of
libclang1-X (like QtCreator, kdevelop, ...) that use libclang to compile
code from source should depend themselves on libclang-common-X-dev as it
is required for them to work correctly.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-03-04 Thread Alexis Murzeau 
Hi,

I've a question about whether libclang1-X should depend on
libclang-common-X-dev to always have the clang's builtin headers
available when libclang is installed.

A bit of context:
QtCreator uses libclang for its code model. If clang's builtin headers
are not available in the system, libclang will fail to find its builtin
headers (like stddef.h) and might fail to parse code and flag "#include
" as an error because the header cannot be found (stddef.h is
one of the builtin headers).

This was reported to QtCreator's upstream in [2].


As seen in [0] and [1], libclang expect to have its builtin headers
available to work correctly.

While analyzing this bug, I found that kdevelop has the exact same issue
as QtCreator.
That is, if they are installed without the libclang's builtin headers,
they both fail to parse "#include " as libclang can't find it.

Codelite is probably in the same case as it uses libclang too but I've
not tested it.


So, I'm thinking that libclang1-X should have a dependency on
libclang-common-X-dev as it seems all users of libclang will likely need
the builtin headers too. (For example, libclang1-8 should depend on
libclang-common-8-dev).

@LLVM Packaging Tream, what do you think about adding this dependency ?

Thanks :)

[0] http://lists.llvm.org/pipermail/cfe-dev/2018-April/057688.html
[1] http://clang.llvm.org/docs/LibTooling.html#builtin-includes
[2] https://bugreports.qt.io/browse/QTCREATORBUG-23451

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#952718: qtcreator: Clang code model fail to find stddef.h if libclang-common-8-dev package is not installed

2020-02-27 Thread Alexis Murzeau 
Subject: qtcreator: Clang code model fail to find stddef.h if 
libclang-common-8-dev package is not installed
Package: qtcreator
Version: 4.11.0-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Install `qtcreator` but not the `libclang-common-8-dev` package
Note: Installing `clang` package will install `clang-9` and not `clang-8`.

When opening a CMake project in qtcreator that does `#include
`, an error is reported by the clang code model in `cstddef`:
`cstddef:50:10: fatal error: 'stddef.h' file not found`



   * What exactly did you do (or not do) that was effective (or
ineffective)?

When installing the `libclang-common-8-dev` package, the clang code
model error goes away and no error is reported anymore.


   * What outcome did you expect instead?

I expect the clang code model to work out of the box with all depends
and recommends dependencies of `qtcreator`.
As of now, `libclang-common-8-dev` seems required by the clang code
model to work correctly, but that package is not a direct or indirect
dependency of `qtcreator`.

The simplest solution (if it is the right one) is to add
`libclang-common-8-dev` as depends or recommends dependency to qtcreator.
Or maybe it should be a dependency of `libclang1-8` instead (which
qtcreator depends on).



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

Kernel: Linux 5.4.8-amdnoflr-20200109 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
LANGUAGE=fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qtcreator depends on:
ii  libc6  2.29-10
ii  libclang1-81:8.0.1-7
ii  libgcc-s1 [libgcc1]10-20200222-1
ii  libgcc11:10-20200222-1
ii  libkf5syntaxhighlighting5  5.62.0-3
ii  libllvm8   1:8.0.1-7
ii  libqbscore1.13 1.13.1-2
ii  libqt5concurrent5  5.12.5+dfsg-8
ii  libqt5core5a [qtbase-abi-5-12-5]   5.12.5+dfsg-8
ii  libqt5designer55.12.5-2+b2
ii  libqt5designercomponents5  5.12.5-2+b2
ii  libqt5gui5 5.12.5+dfsg-8
ii  libqt5help55.12.5-2+b2
ii  libqt5network5 5.12.5+dfsg-8
ii  libqt5printsupport55.12.5+dfsg-8
ii  libqt5qml5 [qtdeclarative-abi-5-12-5]  5.12.5-5
ii  libqt5quick5   5.12.5-5
ii  libqt5quickwidgets55.12.5-5
ii  libqt5script5  5.12.5+dfsg-2
ii  libqt5serialport5  5.12.5-1
ii  libqt5sql5 5.12.5+dfsg-8
ii  libqt5sql5-sqlite  5.12.5+dfsg-8
ii  libqt5widgets5 5.12.5+dfsg-8
ii  libqt5xml5 5.12.5+dfsg-8
ii  libstdc++6 10-20200222-1
ii  qml-module-qtqml-models2   5.12.5-5
ii  qml-module-qtquick-controls5.12.5-1+b1
ii  qml-module-qtquick25.12.5-5
ii  qtchooser  66-2
ii  qtcreator-data 4.11.0-2

Versions of packages qtcreator recommends:
ii  clang  1:9.0-49
ii  clang-tidy 1:9.0-49
ii  gdb-minimal [gdb]  9.1-1
ii  konsole [x-terminal-emulator]  4:19.08.1-2+b1
ii  make   4.2.1-1.2
pn  qmlscene   
pn  qt5-doc
pn  qt5-qmltooling-plugins 
pn  qtbase5-dev-tools  
pn  qtcreator-doc  
pn  qtdeclarative5-dev-tools   
pn  qttools5-dev-tools 
pn  qttranslations5-l10n   
pn  qtxmlpatterns5-dev-tools   

Versions of packages qtcreator suggests:
pn  clazy   
ii  cmake   3.16.3-1
ii  g++ 4:9.2.1-3.1
ii  git 1:2.25.1-1
pn  kate-data   
pn  subversion  
ii  valgrind1:3.15.0-1


Versions of libclang-common-8-dev that fix the issue:
libclang-common-8-dev  1:8.0.1-7

-- no debconf information

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F







signature.asc
Description: OpenPGP digital signature