[krdc] [Bug 486178] VNC plugin deadlocks on connection

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=486178

Thiago Macieira  changed:

   What|Removed |Added

 Status|REPORTED|CONFIRMED
 Ever confirmed|0   |1
   Severity|normal  |critical

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 486178] New: VNC plugin deadlocks on connection

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=486178

Bug ID: 486178
   Summary: VNC plugin deadlocks on connection
Classification: Applications
   Product: krdc
   Version: 24.02.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: VNC
  Assignee: uwol...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
VNC plugin deadlocks as soon as you try to connect


STEPS TO REPRODUCE
1. Launch KRDC
2. Attempt to connect to a VNC host
3. Close KRDC

OBSERVED RESULT
KRDC freezes and must be killed

EXPECTED RESULT
KRDC closes. Preferably, the connection does establish.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.1.0
Qt Version: 6.7.0

ADDITIONAL INFORMATION
Upon trying to connect, KRDC is still usable, but the debugger shows one thread
to be already frozen:
Thread 30 (Thread 0x7fffb4a006c0 (LWP 497638) "VncClientThread"):
#0  0x75711bcd in syscall () at /lib64/libc.so.6
#1  0x760dcca5 in QBasicMutex::lockInternal() () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#2  0x7fffe341886c in QBasicMutex::lock() (this=0x55b37208) at
/usr/include/qt6/QtCore/qmutex.h:41
#3  QMutexLocker::relock() (this=) at
/usr/include/qt6/QtCore/qmutex.h:257
#4  VncClientThread::run() (this=0x55b37180) at
/usr/src/debug/krdc-24.02.2/vnc/vncclientthread.cpp:521
#5  0x760dc1b8 in  () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#6  0x75692bb2 in start_thread () at /lib64/libc.so.6
#7  0x7571400c in clone3 () at /lib64/libc.so.6

QMutexLocker locker();

while (!m_stopped) { // try to connect as long as the server allows
locker.relock();
m_passwordError = false;

This will NEVER EVER work because the mutex is locked by that locker and
nothing can unlock it. This is a difference in behaviour between Qt 5 and Qt 6.
Qt 5:
https://codebrowser.dev/qt5/qtbase/src/corelib/thread/qmutex.h.html#_ZN12QMutexLocker6relockEv
Qt 6:
https://codebrowser.dev/qt6/qtbase/src/corelib/thread/qmutex.h.html#_ZN12QMutexLocker6relockEv

The change happened in Qt 6.4, commit 1b1456975347b044c11169458b53c9f6083dbc59

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 485093] openconnect plugin crashes after receiving answer from Palo Alto Networks GlobalProtect auth

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=485093

Thiago Macieira  changed:

   What|Removed |Added

 Status|REPORTED|CONFIRMED
 Ever confirmed|0   |1

--- Comment #1 from Thiago Macieira  ---
Still happening on 6.0.4

Backtrace:
#3  0x7f7d3ae41240 in  () at /lib64/libc.so.6
#4  0x7f7d16065a0b in OpenconnectAuthWidget::formLoginClicked()
(this=)
at /usr/src/debug/plasma-nm-6.0.4/vpn/openconnect/openconnectauth.cpp:833
#5  0x7f7d3b7c2c41 in QObject::event(QEvent*) () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#6  0x7f7d3cbc2f1e in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /lib64/libQt6Widgets.so.6
#7  0x7f7d3b77e618 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() at /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#8  0x7f7d3b77e95e in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () at /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#9  0x7f7d3b9af653 in  () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#10 0x7f7d3b112710 in  () at /lib64/libglib-2.0.so.0
#11 0x7f7d3b114358 in  () at /lib64/libglib-2.0.so.0
#12 0x7f7d3b114a0c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#13 0x7f7d3b9ad09c in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#14 0x7f7d3b78953b in
QEventLoop::exec(QFlags) () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#15 0x7f7d3b782082 in QCoreApplication::exec() () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#16 0x55882d76f532 in  ()
#17 0x7f7d3ae2a1f0 in __libc_start_call_main () at /lib64/libc.so.6
#18 0x7f7d3ae2a2b9 in __libc_start_main_impl () at /lib64/libc.so.6
#19 0x55882d76f895 in  ()

As before, d->passwordFormIndex = 1 and the layout's item list is:
$6 = {
  > = {
> = {}, }, 
  members of QList:
  d = {
d = 0x5588307c9270,
ptr = 0x5588307c9290,
size = 0
  }
}

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 486076] New: [openconnect] crashes inside libopenconnect: ctx->form->opts->_value not set

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=486076

Bug ID: 486076
   Summary: [openconnect] crashes inside libopenconnect:
ctx->form->opts->_value not set
Classification: Plasma
   Product: plasma-nm
   Version: 6.0.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
When connecting to Palo Alto Network's GlobalProtect, the openconnect plugin
causes a crash inside libopenconnect

STEPS TO REPRODUCE
1. Try to connect to a server that requires OAuth2 authentication (mine is
Microsoft's)
2. Disconnect
3. Connect again

This appears to happen more frequently when some credential is already cached.

OBSERVED RESULT
kded6 crashes

EXPECTED RESULT
Connection is successful

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.10
Qt Version: 6.7.0

ADDITIONAL INFORMATION
Backtrace:
#3  0x7f0ee2441240 in  () at /lib64/libc.so.6
#4  0x7f0ee257ff6c in __strlen_evex () at /lib64/libc.so.6
#5  0x7f0ee24aa762 in strdup () at /lib64/libc.so.6
#6  0x7f0ebd7bf319 in gpst_login (vpninfo=vpninfo@entry=0x556d4431ef00,
portal=portal@entry=1, ctx=ctx@entry=0x7f0e83dffbd0)
at /usr/src/debug/openconnect-9.12/auth-globalprotect.c:728
#7  0x7f0ebd7bf576 in gpst_obtain_cookie (vpninfo=0x556d4431ef00) at
/usr/src/debug/openconnect-9.12/auth-globalprotect.c:778
#8  0x7f0ebe0bf870 in OpenconnectAuthWorkerThread::run()
(this=0x556d4415dc30)
at
/usr/src/debug/plasma-nm-6.0.4/vpn/openconnect/openconnectauthworkerthread.cpp:125
#9  0x7f0ee2edc1b8 in  () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.7.0
#10 0x7f0ee2492bb2 in start_thread () at /lib64/libc.so.6
#11 0x7f0ee251400c in clone3 () at /lib64/libc.so.6

In frame 6, line 728

is:
if (!ctx->username)
ctx->username =
strdup(ctx->form->opts->_value);

(gdb) p ctx->form->opts->_value
$6 = 0x0

I can't tell if this is a libopenconnect bug or not. The code in libopenconnect
is hard to debug as it drives the functionality and only calls back into the
plugin for the web display. However, my colleagues using the GNOME counterpart
don't have this issue and this only appears to happen when there's some cookie
stored in kded, so I believe the bug is somehow in the plugin.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 485353] kwin_wayland forgets the highdpi scaling whenever you connect a new monitor

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=485353

--- Comment #6 from Thiago Macieira  ---
I must have made a mistake in testing previously. After ensuring
~/.local/share/kscreen was deleted, logging out and back in again, kwin_wayland
does not forget the laptop screen's settings when connecting the external
monitor.

PS: in kcm_display, you can't type %

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 485353] kwin_wayland forgets the highdpi scaling whenever you connect a new monitor

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=485353

--- Comment #5 from Thiago Macieira  ---
(In reply to Zamundaaa from comment #4)
> When you reproduced this issue with a new user account, did you also log
> into Xorg first, or does it even happen if you never do that?

I had used the account first with X, but I did go and delete all the config
files before trying this. I may have missed something, though. Which file is
this stored in? ~/.local/share/kscreen/ ?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 485353] kwin_wayland forgets the highdpi scaling whenever you connect a new monitor

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=485353

--- Comment #3 from Thiago Macieira  ---
No, I've just tried with a new account and the same problem happens.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 485353] kwin_wayland forgets the highdpi scaling whenever you connect a new monitor

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=485353

--- Comment #2 from Thiago Macieira  ---
(In reply to Nate Graham from comment #1)
> Is this reproducible in a new clean user account, by any chance?

Will test and let you know. This problem definitely happens on two different
laptops that I've recently migrated to Wayland... but both have the same
history of $HOME going back to 2015.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 485353] New: kwin_wayland forgets the highdpi scaling whenever you connect a new monitor

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=485353

Bug ID: 485353
   Summary: kwin_wayland forgets the highdpi scaling whenever you
connect a new monitor
Classification: Plasma
   Product: kwin
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: wayland-generic
  Assignee: kwin-bugs-n...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
Whenever you connect a new monitor (not a previously connected one), KWin
forgets the scaling for the monitor it is in. The physical size of existing
monitors does not change when you connect new outputs

STEPS TO REPRODUCE
1. Configure one monitor to something other than 100% (for example, laptop
display panel to 200% or 250%)
2. Connect another monitor

OBSERVED RESULT
The first-connected monitor goes back to 100%

EXPECTED RESULT
The first-connected monitor's scaling remains as it was configured

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.3

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 459161] Inconsistent cursor size on Wayland

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=459161

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 485093] New: openconnect plugin crashes after receiving answer from Palo Alto Networks GlobalProtect auth

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=485093

Bug ID: 485093
   Summary: openconnect plugin crashes after receiving answer from
Palo Alto Networks GlobalProtect auth
Classification: Plasma
   Product: plasma-nm
   Version: 6.0.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: applet
  Assignee: plasma-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
When trying to authenticate with PAN's GP server, the openconnect plugin
reliably crashes kded6 after receiving the answer. I am unsure if this is a
regression or not: I did manage to log in a few times, initially, but I don't
know if there's some setting stored away that may be influencing the result.

STEPS TO REPRODUCE
1. Start the VPN with PAN GP
2. Perform the OAuth2 authentication (including, in my case, the Microsoft
Authenticator's approval)

OBSERVED RESULT
The dialog disappears, the VPN does not come on, and kded6 has crashed.

EXPECTED RESULT
Connection comes up

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.3

ADDITIONAL INFORMATION
Backtrace:
#3  0x7f2200241240 in  () at /lib64/libc.so.6
#4  0x7f21db52e67b in OpenconnectAuthWidget::formLoginClicked()
(this=)
at /usr/src/debug/plasma-nm-6.0.3/vpn/openconnect/openconnectauth.cpp:833
#5  0x7f2200bbb441 in QObject::event(QEvent*) () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.6.3
#6  0x7f2201fc1a7e in QApplicationPrivate::notify_helper(QObject*, QEvent*)
() at /lib64/libQt6Widgets.so.6
#7  0x7f2200b782f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*)
() at /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.6.3
#8  0x7f2200b78635 in QCoreApplicationPrivate::sendPostedEvents(QObject*,
int, QThreadData*) () at /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.6.3
#9  0x7f2200da0c73 in  () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.6.3
#10 0x7f2200912710 in  () at /lib64/libglib-2.0.so.0
#11 0x7f2200914358 in  () at /lib64/libglib-2.0.so.0
#12 0x7f2200914a0c in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#13 0x7f2200d9e8ec in
QEventDispatcherGlib::processEvents(QFlags) ()
at /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.6.3
#14 0x7f2200b829bb in
QEventLoop::exec(QFlags) () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.6.3
#15 0x7f2200b7b752 in QCoreApplication::exec() () at
/lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.6.3
#16 0x55e1abd58522 in  ()
#17 0x7f220022a1f0 in __libc_start_call_main () at /lib64/libc.so.6
#18 0x7f220022a2b9 in __libc_start_main_impl () at /lib64/libc.so.6

Line 833 in this version is
:
QLayout *layout =
d->ui.loginBoxLayout->itemAt(d->passwordFormIndex)->layout();

The debuggers says this is a null pointer dereference. Because both itemAt()
and layout() are virtual functions, it's hard to follow in the disassembly
where exactly we are in this statement. I think it's between itemAt() and
layout().

The d pointer is valid:
(gdb) p d
$3 = {ui = {verticalLayout = 0x55e1ad165530, horizontalLayout_3 =
0x55e1ad7aa670, label_3 = 0x55e1ad102a30, cmbHosts = 0x55e1ad7aa750, 
btnConnect = 0x55e1ad5ff8f0, chkAutoconnect = 0x55e1ad5ff530,
chkStorePasswords = 0x55e1ad5ff560, loginBox = 0x55e1ad110820, 
loginBoxLayout = 0x55e1ad5ff590, serverLogBox = 0x55e1ad602df0, logLayout =
0x55e1ad602e20, horizontalLayout_2 = 0x55e1ad603140, 
viewServerLog = 0x55e1ad603330, lblLogLevel = 0x55e1ad5b9f30, cmbLogLevel =
0x55e1ad5b9f90, serverLog = 0x55e1ad5b6bd0}, setting = {
value = 0x55e1ad14b320, d = 0x55e1ad4050a0}, vpninfo = 0x55e1ad7ab500,
secrets = {d = {d = 0x55e1ad5ff1b0}}, tmpSecrets = {d = {d = 0x0}}, 
  mutex = { = {d_ptr = {_q_value = std::atomic =
{ 0x0 }}}, }, workerWaiting = {d = 0x55e1ad5bb230}, 
  worker = 0x55e1ad5fa120, 
  hosts = { >> =
{ >> = {}, }, d = {
  d = 0x55e1ad5ff150, ptr = 0x55e1ad5ff160, size = 1}}, userQuit = false,
formGroupChanged = true, cancelPipes = {48, 52}, 
  serverLog = { >> =
{ >> = {}, }, d = {d = 0x55e1ade09460, ptr = 0x55e1ade09470, size = 49}},
passwordFormIndex = 1, tokenMode = {d = {d = 0x55e1ad7ac500, 
  ptr = 0x55e1ad7ac510 "disabled", size = 8}}, token = {tokenMode =
OC_TOKEN_MODE_NONE, tokenSecret = {d = {d = 0x0, ptr = 0x0, size = 0}}}, 
  waitForWebEngineFinish = {> = {_q_value =
std::atomic = { 0x0 }}, }}

and so is d->ui.loginBoxLayout:
(gdb) p *d->ui.loginBoxLayout
$2 = { = { = { = {},
 = {_vptr.QLayoutItem = 0x7f2202534268 , 
align = {i = 0}}, }, }, }

It says QObject has no data fields because I didn't have the debugging info for
QtCore installed during this. But decoding memory shows its d pointer to be
0x55e1ad0cbe10, which is valid and decodes to:

$3 = { = { = 

[plasma-nm] [Bug 439612] plasma-nm Applet does not prompt for login credentials when connecting to GlobalProtect VPN

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=439612

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

--- Comment #1 from Thiago Macieira  ---
Pointing out that this has changed considerably in Plasma 6 because of the
update in qtwebengine. I suggest retrying.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 484296] New: Message header shows time in the sender's timezone, not the reader's

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=484296

Bug ID: 484296
   Summary: Message header shows time in the sender's timezone,
not the reader's
Classification: Applications
   Product: kmail2
   Version: 6.0.0
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: message list
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

Created attachment 167636
  --> https://bugs.kde.org/attachment.cgi?id=167636=edit
Screenshot showing the problem

SUMMARY
When displaying an email message, the headers (at least the fancy ones) show
the time as literally present in the message header, ignoring the conversion to
the local user's timezone

STEPS TO REPRODUCE
1. Open an email sent by someone not in your time zone

OBSERVED RESULT
The displayed time matches what's in the header, with no indication that it's
not your time zone. The date may therefore be in your future.

EXPECTED RESULT
The displayed time is either converted to your local time zone (preferred, what
every MUA does and KMail used to do) or the time zone is displayed.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

ADDITIONAL INFORMATION
See attached screenshot, where you can see the email display saying
  Date: Yesterday 16:35
And the header saying:
  Date: Fri, 22 Mar 2024 16:35:01 +

My timezone is not UTC.

This is not the same as bug 484119.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 484119] Smart dates in message list still show "today" for messages received yesterday

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=484119

--- Comment #1 from Thiago Macieira  ---
Created attachment 167535
  --> https://bugs.kde.org/attachment.cgi?id=167535=edit
Screenshot showing the problem

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 484119] New: Smart dates in message list still show "today" for messages received yesterday

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=484119

Bug ID: 484119
   Summary: Smart dates in message list still show "today" for
messages received yesterday
Classification: Applications
   Product: kmail2
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: message list
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
The smart dates for the message listing appears to be stuck on the day that
KMail was launched. So it will display "today" for any message received on that
day, but will not update it when the day changes.

STEPS TO REPRODUCE
1. Open KMail
2. Wait for midnight
3. Find a message received before midnight

OBSERVED RESULT
It displays "today"

EXPECTED RESULT
It should display "yesterday"

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2

ADDITIONAL INFORMATION
Same as #178035, but that was fixed 16 years ago. The problem has reoccurred.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 483060] Akonadi sending UTC timestamps as local time to MySQL (and this failing around DST change) - QMYSQL bug?

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=483060

Thiago Macieira  changed:

   What|Removed |Added

 CC||ch.ehrlic...@gmx.de

--- Comment #8 from Thiago Macieira  ---
> Another idea: have Akonadi set the client time zone to UTC when it connects. 
> BUT: I don't know what that might do to the times it returns in other 
> queries, so would require investigation, and if code would have to be changed 
> elsewhere.

Applying that fix to QMYSQL instead.
https://codereview.qt-project.org/c/qt/qtbase/+/546954

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 483060] Akonadi sending UTC timestamps as local time to MySQL (and this failing around DST change) - QMYSQL bug?

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=483060

Thiago Macieira  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED

--- Comment #5 from Thiago Macieira  ---
My reading of the MySQL API is that there's no way to pass the timestamp in
prepared queries as UTC. You can only pass it as a local timestamp. Feels so
1980s...

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 483060] Akonadi sending UTC timestamps as local time to MySQL (and this failing around DST change) - QMYSQL bug?

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=483060

Thiago Macieira  changed:

   What|Removed |Added

 CC||jos...@joshuakugler.com

--- Comment #4 from Thiago Macieira  ---
*** Bug 483061 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 483061] Akonadi server does not declare UTC times as UTC

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=483061

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org
 Resolution|--- |DUPLICATE
 Status|CONFIRMED   |RESOLVED

--- Comment #2 from Thiago Macieira  ---


*** This bug has been marked as a duplicate of bug 483060 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 483060] Akonadi sending UTC timestamps as local time to MySQL (and this failing around DST change) - QMYSQL bug?

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=483060

--- Comment #3 from Thiago Macieira  ---
(In reply to Christophe Marin from comment #2)
> Duplicate of 483061?

Looks like two people experienced the same problem at around the same time,
yes.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 483060] Akonadi sending UTC timestamps as local time to MySQL (and this failing around DST change) - QMYSQL bug?

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=483060

--- Comment #1 from Thiago Macieira  ---
Or use the SET GLOBAL time_zone command.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 483060] New: Akonadi sending UTC timestamps as local time to MySQL (and this failing around DST change) - QMYSQL bug?

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=483060

Bug ID: 483060
   Summary: Akonadi sending UTC timestamps as local time to MySQL
(and this failing around DST change) - QMYSQL bug?
Classification: Frameworks and Libraries
   Product: Akonadi
   Version: 5.24.4
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: server
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
CC: c...@carlschwan.eu
  Target Milestone: ---

SUMMARY
KMail started failing to send emails for me with a message saying the item
couldn't be stored. I did find this in the journal:

Mar 09 21:10:09 tjmaciei-mobl5 akonadiserver[745525]:
org.kde.pim.akonadiserver: DATABASE ERROR:
Mar 09 21:10:09 tjmaciei-mobl5 akonadiserver[745525]:
org.kde.pim.akonadiserver:   Error code: "1292"
Mar 09 21:10:09 tjmaciei-mobl5 akonadiserver[745525]:
org.kde.pim.akonadiserver:   DB error:  "Incorrect datetime value: '2024-03-10
02:10:09.341000' for column `akonadi`.`pimitemtable`.`atime` at row 1"
Mar 09 21:10:09 tjmaciei-mobl5 akonadiserver[745525]:
org.kde.pim.akonadiserver:   Error text: "Incorrect datetime value: '2024-03-10
02:10:09.341000' for column `akonadi`.`pimitemtable`.`atime` at row 1 QMYSQL3:
Unable to execute statement"
Mar 09 21:10:09 tjmaciei-mobl5 akonadiserver[745525]:
org.kde.pim.akonadiserver:   Values: QMap((":0", QVariant(QDateTime,
QDateTime(2024-03-10 02:10:09.341 UTC Qt::UTC)))(":1", QVariant(qlonglong,
770803)))
Mar 09 21:10:09 tjmaciei-mobl5 akonadiserver[745525]:
org.kde.pim.akonadiserver:   Query: "UPDATE PimItemTable SET atime = :0 WHERE (
( PimItemTable.id = :1 ) )"
Mar 09 21:10:09 tjmaciei-mobl5 akonadiserver[745525]:
org.kde.pim.akonadiserver: Unable to update item access time

After stressing a bit about whether this was a database or filesystem
corruption, I figured out that the issue was the actual time in that timestamp.
MySQL rejects it:

MariaDB [akonadi]> UPDATE PimItemTable SET atime = timestamp('2024-03-10
02:10:55.625000') WHERE ( ( PimItemTable.id = 770804 ) );
ERROR 1292 (22007): Incorrect datetime value: '2024-03-10 02:10:55.625000' for
column `akonadi`.`pimitemtable`.`atime` at row 1

If you look at the error message in the log, as well as the journalctl
timestamp, 02:10:55 is an UTC time. But when this was sent to the DB server,
there's no information that it is UTC. Thus the server rejects it thinking it's
local time.


STEPS TO REPRODUCE
1. Set your system time such that the universal time, if computed as local
time, would fall into the spring forward gap
2. Try to send an email

OBSERVED RESULT
Email sending fails.

EXPECTED RESULT
Email sending works.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.27.10
KDE Frameworks Version: 5.115.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
This is probably a QMYSQL bug, because the QVariant as printed did have UTC
time. The toMySqlDate() function was added for Qt 6.6, but I don't see a way to
specify the timezone with MYSQL_TIME.

But maybe Akonadi can work around the issue by starting mysqld with TZ=UTC.

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 479841] Remaining disk space is not detected properly on Btrfs disks

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=479841

--- Comment #6 from Thiago Macieira  ---
(In reply to Thiago Macieira from comment #4)
> Fixing in Qt.

Upstream fix landed in 6.7 as f3782300d2ebd4a70c594f1eb12a7d79de4b9602

-- 
You are receiving this mail because:
You are watching all bug changes.

[dolphin] [Bug 479841] Remaining disk space is not detected properly on Btrfs disks

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=479841

Thiago Macieira  changed:

   What|Removed |Added

 Resolution|--- |UPSTREAM
 Status|CONFIRMED   |RESOLVED
 CC||thi...@kde.org

--- Comment #4 from Thiago Macieira  ---
Fixing in Qt.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 455394] Vertically-arranged monitors' alignment is off by one pixel

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=455394

--- Comment #17 from Thiago Macieira  ---
(In reply to Harald Sitter from comment #16)
> Are you quite certain the config this happens with is from 5.27 (not older
> and incorrect from before 5.27)? I've been playing with the kcm for a while
> and haven't managed to get incorrect snapping out of it.

Yes, I am quite sure.

My guess is this is related to HighDPI: at 2x, the off-by-1 gets lost in the
rounding.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kwallet] [Bug 458085] Wallet system takes about 1 minute to start

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=458085

--- Comment #65 from Thiago Macieira  ---
> I don't know, but if you configure your system such that gpgconf can't do
> its job, then you have a broken configuration, IMO.
> If you really want ephemeral settings without writing to disk, you can mount
> them with overlayfs. But that's really an edge case.

gpgconf can do its job when *I* want to run it. It's a tool for me, not for
other applications. KWallet shouldn't change my GPG settings behind my back.

In any case, this doesn't prevent a race condition anyway. How about we try to
fix it the right way first?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kwallet] [Bug 458085] Wallet system takes about 1 minute to start

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=458085

--- Comment #63 from Thiago Macieira  ---
(In reply to michaelk83 from comment #62)
> > It also wouldn't work if I had my ~/.gnupg directory protected against
> > unwanted reads and writes.
> 
> The proposed patch doesn't attempt to write to ~/.gnupg directly. It makes
> calls to gpgconf.

Does it support setting ephemeral settings not saved to disk? I didn't see that
in the documentation.

Otherwise, you're just asking to write to disk, only indirectly. It's like
replacing the KConfig classes with a subprocess call to kwriteconfig5 and say.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kwallet] [Bug 458085] Wallet system takes about 1 minute to start

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=458085

--- Comment #61 from Thiago Macieira  ---
(In reply to michaelk83 from comment #60)
> Pinentry is asking for the passphrase through the same Secret Service API as
> any other client (see comment 31). KWallet has no way to tell it apart from
> any other client, so can't handle it differently. As far as KWallet can tell
> at this point, the passphrase that pinentry wants is inside the same wallet
> (but it's not).

That is understood. I did say that my idea would only work if there were a way
to break the loop. If there isn't, then it doesn't help.

> Currently pinentry's request blocks in the `OpenSession` call because
> KWallet is still waiting for GPG to unlock the wallet (for the original
> request of some other client app). If this was asynchronous, what would
> happen is KWallet would try to unlock the wallet a 2nd time to look for the
> passphrase there, which would invoke GPG and pinentry a 2nd time, which
> would ask KWallet again, and so on and on and on.

Only if it got coded this poorly. A proper implementation would realise that
the request for GPG to open the wallet is still pending and queue the request
to be answered when the wallet got opened. So the loop breaks, but doesn't
solve the problem.

> > But not the way you described it. Modifying ~/.gnupg/gpg-agent.conf is not
> > acceptable, because it's not atomic.
> 
> Yes, as I said, there could be timing issues and maybe other problems. That
> patch is still just an automated and time-limited workaround.
> I'm not aware of any other way to tell pinentry to not use the external
> cache, other than maybe by implementing the Assuan protocol.

It also wouldn't work if I had my ~/.gnupg directory protected against unwanted
reads and writes.

I really think we need to talk to the gpg-agent/pinentry folks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kwallet] [Bug 458085] Wallet system takes about 1 minute to start

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=458085

--- Comment #59 from Thiago Macieira  ---
> @Thiago, the issue is bigger than just synchronous vs asynchronous. The
> issue is that if you use a GPG wallet, with Secret Service provided by
> KWallet, and while allowing pinentry to read the key passphrase from Secret
> Service, what ends up happening is that KWallet asks for the key passphrase
> from itself instead of the user. It's like trying to unlock a safe with the
> key that's locked inside that same safe. Not going to work. Even if you
> make this asynchronous, you'll just end up with an infinite recursion.

I understand that we ended up with KWallet asking itself for the password. But
the fact is that if the query was asynchronous, then pinentry would have got
its answer instead of timing out, and then would have prompted the use for the
password. Or maybe not, maybe KWallet is storing the cached answer in memory
and would have provided it to pinentry. But do note I talked about KWallet
ensuring it doesn't recurse infinitely, which is why we'd need to figure out if
where this particular password could be saved if it is provided to KWallet;
refusing to store it is a way to break the chain.

I'm not saying it's easy to implement this.

Your idea from comment 40 -- to tell gpg-agent that we want a password with
no-external-cache -- is a solution too. Probably the Right Solution (with
capital R and S).

But not the way you described it. Modifying ~/.gnupg/gpg-agent.conf is not
acceptable, because it's not atomic. Other passwords may be getting requested
at the same time as KWallet is trying to open. In fact, if we are trying to
open the wallet now because something wants a stored password, then it stands
to reason another program could be trying to do the same. Moreover, because
we're waiting for user interaction, the time during which the gpg-agent.conf
file is modified is measured in human time.

Therefore, this solution requires that we inform gpg-agent that we want a
no-external-auth-cache answer for THIS query only and that it inform the
pinentry tool that it shouldn't query the external auth cache. That requires
those two tools to be updated and their updates deployed; plus probably
libgpgme too. It's probably the right thing to do, so we should interact with
upstream to get them to implement this.

But if there is a KWallet-only solution, we should investigate it.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kwallet] [Bug 458085] Wallet system takes about 1 minute to start

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=458085

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

--- Comment #57 from Thiago Macieira  ---
I disagree that no-allow-external-cache is a proper solution. It's a
workaround, but it prevents one from using GPG/pinentry for other tasks and
saving the credential cache in the KWallet-provided Secret Service. It's
probably the least-intrusive option because gpg-agent does caching on its own
anyway, but it's not a solution.

The solution would be to make kwalletd be able to answer this query coming from
pinentry. To do that, make the kwalletd code asking for the unlocking of GPG
wallet not block - if there's an asynchronous API for that, you can use it,
otherwise move the entire workload to a separate thread. QtDBus is already
threaded, so the query was received by the the process; however, the thread
owning the QObject that would've answered the call was blocked and didn't
answer.

You need to make sure this doesn't loop again: make sure this Secret Service
call isn't going to trigger another call back to pinentry and thus loop again.

This has the added benefit that kwalletd isn't frozen while pinentry is waiting
for the user to type the password. I've seen before that applications waiting
for kwalletd also freeze if kwalletd won't answer, though this particular
change may not affect the applications that are freezing, if kwalletd can't
answer the call in the first place. This benefit comes with its drawback
though: kwalletd needs to know that it's already waiting for the wallet to open
and queue the reply going back to the application.

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 455394] Vertically-arranged monitors' alignment is off by one pixel

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=455394

Thiago Macieira  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #14 from Thiago Macieira  ---
As kscreen set them:

Screen 0: minimum 320 x 200, current 7679 x 2400, maximum 16384 x 16384
eDP-1 connected primary 3840x2400+0+0 (normal left inverted right x axis y
axis) 288mm x 180mm
   3840x2400 59.99*+  48.00  
DP-3-2 connected 3840x2160+3839+0 (normal left inverted right x axis y axis)
597mm x 336mm
   3840x2160 29.98* 

After xrandr --output DP-3-2 --right-of eDP-1:

Screen 0: minimum 320 x 200, current 7680 x 2400, maximum 16384 x 16384
eDP-1 connected primary 3840x2400+0+0 (normal left inverted right x axis y
axis) 288mm x 180mm
   3840x2400 59.99*+  48.00  
DP-3-2 connected 3840x2160+3840+0 (normal left inverted right x axis y axis)
597mm x 336mm
   3840x2160 29.98*

-- 
You are receiving this mail because:
You are watching all bug changes.

[systemsettings] [Bug 455394] Vertically-arranged monitors' alignment is off by one pixel

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=455394

--- Comment #13 from Thiago Macieira  ---
I've just seen this again in 5.27.2

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 377167] Progress bar consumes WAY too much CPU

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=377167

--- Comment #5 from Thiago Macieira  ---
I haven't observed high CPU usage because the progress panel simply can't be
expanded. The button on the left of the progress bar does nothing besides
change the direction of the arrow.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 461213] Qt6.4 causing crashes linux/opensuse

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=461213

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

--- Comment #1 from Thiago Macieira  ---
This is probably the first thing that valgrind printed, but is not your issue.
The info parameter to waitid() does not need to be null. The man page says:
"Linux, if infop is NULL, waitid() succeeds, and returns the process ID of the
waited-for child.  Applications should avoid  relying  on this inconsistent,
nonstandard, and unnecessary feature."

That particular code testing the kernel, so we can rely on the
behaviour-specific content.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 383247] Attachments not displayed in message header

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=383247

Thiago Macieira  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |WORKSFORME
 Status|NEEDSINFO   |RESOLVED

--- Comment #3 from Thiago Macieira  ---
I haven't seen this in a while.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 379886] When in @2x HghDPI, VNC downscales and re-scales up

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=379886

Thiago Macieira  changed:

   What|Removed |Added

 Status|NEEDSINFO   |RESOLVED
 Resolution|WAITINGFORINFO  |WORKSFORME

--- Comment #3 from Thiago Macieira  ---
Problem does indeed appear to be gone.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 461127] New: KRDC needs the ability to scale the remote desktop's contents

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=461127

Bug ID: 461127
   Summary: KRDC needs the ability to scale the remote desktop's
contents
Classification: Applications
   Product: krdc
   Version: 22.08.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: RDP
  Assignee: uwol...@kde.org
  Reporter: thi...@kde.org
CC: aa...@kde.org
  Target Milestone: ---

SUMMARY
When KRDC is running locally on a High DPI monitor, it does not ask the remote
side to scale up using RDP. The VNC plugin has a sliding zoom factor (only
available in full screen mode, not in the regular KRDC window, and you zoom in
by moving to the left), but no such thing is available for RDP. Instead, it
appears the RDP protocol allows passing the scale information to the remote
side and the remote will do the necessary scaling.

xfreerdp has the /scale:[100|140|180], /scale-desktop: and
/scale-device:100|140|180 options. I tried using /scale-desktop and it didn't
do anything useful for me; /scale:180 did scale up but 180% is not sufficient
for me. rdesktop can be asked to scale up in the -g (geometry) option, as in:
-g 3840x2000@200.

STEPS TO REPRODUCE
1. Get a High DPI display
2. Connect to a remote device
3. Attempt to read the text

OBSERVED RESULT
Remote desktop's fonts and icons are too small, text cannot be read.

EXPECTED RESULT
Text is readable, icons have decent target area for clicking.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.26.1
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.6

-- 
You are receiving this mail because:
You are watching all bug changes.

[kwin] [Bug 444513] New: Initially full screen windows only shown on screen 0

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=444513

Bug ID: 444513
   Summary: Initially full screen windows only shown on screen 0
   Product: kwin
   Version: 5.23.0
  Platform: openSUSE RPMs
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: multi-screen
  Assignee: kwin-bugs-n...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
When an application creates a window that is initially full screen, it gets
shown only on screen 0, regardless of where the geometry or screen setting was.
If the window was not created/mapped full screen, but made full screen after
shown, it is located in the correct screen.

STEPS TO REPRODUCE
1. Connect a second monitor and extend it (to the right for me)
2. Press Ctrl+Alt+Del to show the Leave window

This can also be done with mpv -screen=1 -fs=yes

OBSERVED RESULT
Both Leave windows are on screen 0 (to the left for me) and screen 1 is still
usable. You can notice this because they're darker than usual and you can Alt+
or Meta+drag one of them to the other screen and you'll see another window
below it.

EXPECTED RESULT
One Leave window is displayed in each screen. In the mpv case, it's displayed
in the screen that was requested.

SOFTWARE/OS VERSIONS
OpenSUSE Tumbleweed 20211021
KDE Plasma Version: 5.23.0
KDE Frameworks Version: 5.87.0
Qt Version: 5.12.2 + kde patches

ADDITIONAL INFORMATION
This did not happen with kwin 5.22.5.

Using xprop, you can tell that one of the Leave windows has this property:
WM_NORMAL_HINTS(WM_SIZE_HINTS):
user specified location: 3840, 0
user specified size: 3840 by 2160
program specified resize increment: 2 by 2
program specified base size: -2 by -2
window gravity: Static

And yet it was displayed at location 0,0.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 441497] Scaling feature does not scale anything

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=441497

--- Comment #12 from Thiago Macieira  ---
(In reply to Rafal Lalik from comment #11)
> The presence of slider should be irrelevant for the old behaviour. Just a
> button Scale which toggles between 1:1 and fits-to-window view. The bug
> which is fixed already (new Merge Request) fixes that. You do not need
> slider to have the old behaviour.
> 
> But again, due to bug, you need sldier to change the scaling value. After
> the bug is fixed, you do not need sldier again. Just forget about it then.

It's still a UX issue if you have a button controlling the slider. When the
button is not pressed, the slider is greyed out. If you try to drag it, you
drag the entire window. And if the slider is left in fully zoomed out position,
the scale button does nothing.

Please reconsider and merge the two into one control only. I recommend getting
the zoom control from Okular, so one can select no scaling, 200% scaling, fit
to width, etc. Not a slider at all.

> Scale button is also toolbar only. No UX problem here.

It's in the menu: Session > Scale Remote Screen to Fit Window Size. At a
minimum, you must change this menu text, because "Fit Window Size" is not
correct any more, if the actual scaling factor is controlled by the slider. As
above, I recommend a simple Zoom option.

> > What? The left most position zooms in and the right most leaves no zoom?
> > Isn't that the inverse of all sliders? For example, if I open LibreOffice,
> > it has a zoom slider on the status bar and the middle is 100%; to the left,
> > it zooms out and to the right it zooms in.
> 
> No, there is no zoom-in/zoom-out. It is interpolation between "1:1 view"
> (left) and "fit-to-window" (right). Again, no UX problem but your
> interpretation of the slider.

Which is why it's a UX problem. It's not very discoverable and behaves the
opposite of most zoom sliders, which is what this will be compared to.

> If the remote is smaller than local, the slider works in an intuitive way.
> If remote is larger, then again - left side is larger that right, which may
> look weird, but remember - left side is 1:1 view, right side is fit to
> window.

I beg to differ. Moving the slider to the left so the content becomes bigger is
counter-intuitive.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 441497] Scaling feature does not scale anything

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=441497

--- Comment #10 from Thiago Macieira  ---
I've just noticed that if I go full screen, the toolbar that drops down has a
slider. But if I touch it and try to drag, the whole window is moved to the
other monitor.

Oh, wait, there's a button to its right. If I click it, the slider becomes
blue. Now I can move the slider to the left (which would be zooming out) so it
zooms in.

I count at least 5 UX problems here.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 441497] Scaling feature does not scale anything

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=441497

Thiago Macieira  changed:

   What|Removed |Added

 Status|REPORTED|CONFIRMED
 Ever confirmed|0   |1

--- Comment #9 from Thiago Macieira  ---
(In reply to Rafal Lalik from comment #8)
> I think your problem comes from having the slider hidden (indeed, this could
> be fixed) and being in the wrong position.

I've just re-checked the UI now that the existence of a slider became apparent.
It's nowhere. It's not in the toolbars and it's not in the menus anywhere. The
toolbar is showing.

If I go to edit the toolbar, apparently there's an option to add it. This is
not acceptable. I have not edited the toolbars since I installed this computer
in mid-June, so there's no reason why some old setting of mine would have
caused this. And even if I had some setting (like my previous computer, from
2016), you must somehow override it and cause meaningful controls to appear.

Second UX issue is that it's in the toolbar only. That's also unacceptable. It
must be reachable by the keyboard, using the menus or a configuration dialogue.
In order to get the most real estate for the remote system, I usually leave the
toolbar disabled for KRDC (I hadn't done it yet on this system).

And third UX problem is that there's a Scale button that does nothing.

> The most left position should fit
> remote to  local window size, the most right positions makes no scaling.
> Default value should be most left and then Scale button should work like
> before. If for some reasons slider was at the most right position (and this
> is bug), you would not see any scaling effect.

What? The left most position zooms in and the right most leaves no zoom? Isn't
that the inverse of all sliders? For example, if I open LibreOffice, it has a
zoom slider on the status bar and the middle is 100%; to the left, it zooms out
and to the right it zooms in.

> Please enable slider in the toolbar (toolbar settings) and move slider to
> the left, it should fix your problem.
> 
> I can confirm that after clearing my krdc config files, the default value
> for the slider is the most right. It must be fixed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 441497] Scaling feature does not scale anything

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=441497

--- Comment #7 from Thiago Macieira  ---
If I need to turn on a toolbar that isn't on by default, then the UX is wrong.

Either way, there's a button to scale. It's not doing anything. Either the
feature is broken or that button needs to be removed, possibly replaced by the
slider.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 441497] Scaling feature does not scale anything

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=441497

--- Comment #5 from Thiago Macieira  ---
(In reply to Albert Astals Cid from comment #3)
> Are you moving the scale slider?

What slider? I've never seen a slider before and there isn't one in the UI I'm
looking at.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krdc] [Bug 441497] New: Scaling feature does not scale anything

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=441497

Bug ID: 441497
   Summary: Scaling feature does not scale anything
   Product: krdc
   Version: 21.08.0
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: VNC
  Assignee: uwol...@kde.org
  Reporter: thi...@kde.org
CC: aa...@kde.org
  Target Milestone: ---

SUMMARY
This weekend I updated from 21.04 to 21.08. The scaling feature (at least with
VNC) has stopped working. Now krdc is unusable from a high DPI system
connecting to a low DPI one

STEPS TO REPRODUCE
1. Connect to a system via VNC
2. Click Scale

OBSERVED RESULT
Nothing happens

EXPECTED RESULT
Remote screen is scaled to fit the window.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.2 + KDE patches

ADDITIONAL INFORMATION
Remote system is a macOS Mojave.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 438874] Disk & Devices applet doesn't show USB removable devices and SD cards after disconnecting and re-connecting them

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=438874

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 441133] New: "Forever" is too short for self-signed certificate acceptance

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=441133

Bug ID: 441133
   Summary: "Forever" is too short for self-signed certificate
acceptance
   Product: Akonadi
   Version: 5.17.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: IMAP resource
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
I have an IMAP mail server I use to back up my emails. It has a self-signed
certificate. Up until this week, I hadn't been bothered by the self-signed
certificate warning aside from the first time I started KMail / Akonadi with
this server. But it's now bothering me every time it reconnects, which appears
to be once every hour, with two connections.

This is not the same as bug 203753 because kded is running.

The certificate is valid until 2029.

STEPS TO REPRODUCE
1. Add an account with a self-signed SSL certificate
2. Fetch emails from it
3. Accept the certificate Forever
4. Wait a while

OBSERVED RESULT
The dialogue telling me the certificate is self-signed and asking me if I want
to trust it shows up within a finite amount of time.

EXPECTED RESULT
The dialogue does not show up again unless I reset the settings.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2 + KDE patches

ADDITIONAL INFORMATION
Usually this is caused after a system upgrade (using OpenSUSE Tumbleweed here),
but this weekend's update did not touch anything related to SSL, Qt or KDE
applications.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440635] Scam detector is confused by links created by KMail itself

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440635

--- Comment #7 from Thiago Macieira  ---
> It was a bug created from a specific url found long time ago:
> "
> "href=\"http://g-ecx.images-amazon.com/images/G/01/barcodes/blank003.
> jpg%5CnUse\">http://g-ecx.images-amazon.com/images/G/01/barcodes/blank003.
> jpg/nUse"
> 
> => I fixed it and now all autotest works.

This one should have triggered the warning, because it isn't the same URL. You
may want to do the backslash replacement only on the path component instead of
the whole URL, if this case is still important.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440635] Scam detector is confused by links created by KMail itself

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440635

--- Comment #5 from Thiago Macieira  ---
Sorry, that can't can't be right. If you have to put the backslashes back,
something went wrong before and there may be more.

What were was the value of href and normalizedHref before the toDisplayString
call?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440635] Scam detector is confused by links created by KMail itself

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440635

Thiago Macieira  changed:

   What|Removed |Added

 Status|REPORTED|CONFIRMED
 Ever confirmed|0   |1

--- Comment #2 from Thiago Macieira  ---
I can file this as a separate bug report but here's another link. You'll
probably get a notification from KMail that the bugzilla email is a scam too.

https://www.google.com/search?q=%5C

The details window will say that link points to 
'https://www.google.com/search?q=/', which is incorrect. It does not. Neither
the status bar nor the actual link when opened in the browser suffered the
backslash-to-forwardslash transformation. You're incorrectly passing the full,
decoded URL through some path clean routine (QDir::cleanPath?). There are at
least two mistakes there.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 439769] Akonadi fails with Mariadb 10.6.3

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=439769

--- Comment #14 from Thiago Macieira  ---
Fix in Qt: https://codereview.qt-project.org/c/qt/qtbase/+/363880

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440635] New: Scam detector is confused by links created by KMail itself

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440635

Bug ID: 440635
   Summary: Scam detector is confused by links created by KMail
itself
   Product: kmail2
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: message list
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
For some emails, the message list shows "This message may be a scam" and shows
details saying that it had concluded to be so because the link target was
different from the link being displayed. The problem is that this was a
plain-text email and the links were generated by KMail. Therefore, the issue is
that the display and target are not what's in the plain text source.

For example:

This email contains a link which reads as
'https://codereview.qt-project.org/q/topic:%22api-change-review-6.2%22+(status:open
OR status:abandoned' in the text, but actually points to
'https://codereview.qt-project.org/q/topic:'. This is often the case in scam
emails to mislead the recipient

STEPS TO REPRODUCE
1. Open the following email body in an KMail

OBSERVED RESULT
Scam warning appears

EXPECTED RESULT
Scam warning should not appear

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2 + KDE patches

ADDITIONAL INFORMATION
The email in question was even received in base64 encoding, so it can't have
been improperly decoded. Do note it may have been mangled by the mailing list
manager, which appended a footer, but other than that the plain text shouldn't
have changed.

The offending line is:

Changes:
https://codereview.qt-project.org/q/topic:%22api-change-review-6.2%22+(status:open%20OR%20status:abandoned)

Full email:

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgZXZlcnlvbmUhCgpJdCBzZWVtcyBBUEkgcmV2aWV3IGlzIHN0aWxsIG9uZ29pbmcsIHNlZSBo
dHRwczovL2J1Z3JlcG9ydHMucXQuaW8vYnJvd3NlL1FUQlVHLTk0NDA3CgpQbGVhc2UgY29uY2x1
ZGUgdGhlIHJldmlldyBhc2FwOyB3ZSBzaG91bGQgZ2V0IGFsbCByZXZpZXcgcmVsYXRlZCBjaGFu
Z2VzIGluIGJldGEzIHBhY2thZ2VzCgpiciwKSmFuaQoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwpGcm9tOiBEZXZlbG9wbWVudCA8ZGV2ZWxvcG1lbnQtYm91bmNlc0Bx
dC1wcm9qZWN0Lm9yZz4gb24gYmVoYWxmIG9mIERhdmlkIFNrb2xhbmQgPGRhdmlkLnNrb2xhbmRA
cXQuaW8+ClNlbnQ6IFR1ZXNkYXksIEp1bmUgMjIsIDIwMjEgMTI6NDMgUE0KVG86IGRldmVsb3Bt
ZW50QHF0LXByb2plY3Qub3JnClN1YmplY3Q6IFtEZXZlbG9wbWVudF0gQVBJIENoYW5nZSBSZXZp
ZXcgZm9yIDYuMgoKSGVsbG8gZXZlcnlvbmUhCgpJbiBhY2NvcmRhbmNlIHRvIFFVSVAtMTAgKGh0
dHA6Ly9xdWlwcy1xdC1pby5oZXJva3VhcHAuY29tL3F1aXAtMDAxMC1BUEktcmV2aWV3Lmh0bWwp
LCBpdCBpcyBhZ2FpbiB0aW1lIGZvciBhIHJldmlldyBvZiB0aGUgY2hhbmdlcyB0byB0aGUgcHVi
bGljIEFQSSBmcm9tIDUuMTUgYW5kIDYuMSB0byA2LjIuIEFzIHlvdSBtYXkga25vdywgYSBmYWly
IG51bWJlciBvZiBtb2R1bGVzIHdlcmUgcmVpbnRyb2R1Y2VkIGluIDYuMiBmcm9tIDUuMTUgYW5k
IHdlcmUgYWRqdXN0ZWQgcXVpdGUgYSBiaXQuIE9uZSBub3RhYmxlIG9taXNzaW9uIGZyb20gdGhl
IHJldmlldyByb3VuZCBpcyBxdG11bHRpbWVkaWEsIHdoaWNoIHdhcyB0aG9yb3VnaGx5IHJld29y
a2VkIGFuZCBoZW5jZSBzdWJqZWN0IHRvIGEgc2VwYXJhdGUgcmV2aWV3IHByb2Nlc3MgKHJlZi4g
TGFycykuCgpSZWxldmFudCBKaXJhOiBodHRwczovL2J1Z3JlcG9ydHMucXQuaW8vYnJvd3NlL1FU
QlVHLTk0NDA3CkNoYW5nZXM6IGh0dHBzOi8vY29kZXJldmlldy5xdC1wcm9qZWN0Lm9yZy9xL3Rv
cGljOiUyMmFwaS1jaGFuZ2UtcmV2aWV3LTYuMiUyMisoc3RhdHVzOm9wZW4lMjBPUiUyMHN0YXR1
czphYmFuZG9uZWQpPGh0dHBzOi8vY29kZXJldmlldy5xdC1wcm9qZWN0Lm9yZy9xL3RvcGljOiJh
cGktY2hhbmdlLXJldmlldy02LjIiKyhzdGF0dXM6b3BlbiUyME9SJTIwc3RhdHVzOmFiYW5kb25l
ZCk+CkFsbCBtb2R1bGVzIGluIDYuMjogaHR0cHM6Ly93aWtpLnF0LmlvL1F0XzYuMi4wX01vZHVs
ZXMKClRoZSBtb3N0IGltcG9ydGFudCBjaGFuZ2VzIGFyZSBhcyB1c3VhbCBxdGJhc2UgYW5kIHF0
ZGVjbGFyYXRpdmUuCgpEbyBhbHNvIG5vdGUgdGhlIDYuMiByZWxlYXNlIHBsYW4sIGFzIHRoaXMg
c2hvdWxkIGJlIGNvbXBsZXRlZCBpbiBhIHRpbWVseSBtYW5uZXI6IGh0dHBzOi8vd2lraS5xdC5p
by9RdF82LjJfUmVsZWFzZQoKQSBmYWlyIG51bWJlciBvZiBtb2R1bGVzIGhhZCBubyBpbnRlcmVz
dGluZyBjaGFuZ2VzIGZyb20gNi4xLCBzbyB0aGV5IGhhdmUgbm8gR2Vycml0IGNoYW5nZSBhdCBh
bGwuIElmIHlvdSBoYXZlIGFueSBxdWVzdGlvbnMgYWJvdXQgYW55IG9mIHRoZSBjaGFuZ2VzLCBs
ZXQgbWUga25vdy4KCkNoZWVycywKCkRhdmlkIFNrb2xhbmQKCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fCkRldmVsb3BtZW50IG1haWxpbmcgbGlzdApEZXZl
bG9wbWVudEBxdC1wcm9qZWN0Lm9yZwpodHRwczovL2xpc3RzLnF0LXByb2plY3Qub3JnL2xpc3Rp
bmZvL2RldmVsb3BtZW50Cg==

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] Expiry settings not displayed properly from Akonadi config

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

Thiago Macieira  changed:

   What|Removed |Added

Summary|Expiry settings not holding |Expiry settings not
   ||displayed properly from
   ||Akonadi config

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] Expiry settings not holding

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

--- Comment #8 from Thiago Macieira  ---
(In reply to Thiago Macieira from comment #7)
> After making this change, KMail / Akonadi does display the modified settings
> for this folder.

Looks like the setting does get reloaded properly if the expiry for unread
messages is activated. The moment I turn it off again, the setting is not
displayed properly on the Expiry tab.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] Expiry settings not holding

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

--- Comment #7 from Thiago Macieira  ---
> But the settings page is not reloading the settings.

I've just made a change to one of the folders to expire unread emails too. The
MySQL database reflects the change:

MariaDB [akonadi]> select type, hex(value) from collectionattributetable where
type='expirationcollectionattribute';
+---+--+
| type  | hex(value)   
   |
+---+--+
| expirationcollectionattribute |
00010078001E0100 |
| expirationcollectionattribute |
0001016D001E0100 |
| expirationcollectionattribute |
00F500010001001E0001001E0100 |
| expirationcollectionattribute |
00F6000100010015001E0100 |
+---+--+
4 rows in set (0.001 sec)

See the "1" in the third line, for the expiration of unread emails too.

After making this change, KMail / Akonadi does display the modified settings
for this folder.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] Expiry settings not holding

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

--- Comment #6 from Thiago Macieira  ---
(In reply to Thiago Macieira from comment #5)
> MariaDB [akonadi]> select type, hex(value) from collectionattributetable
> where type='expirationcollectionattribute';
> +---+
> --+
> | type  | hex(value)
> |
> +---+
> --+
> | expirationcollectionattribute |
> 00010078001E0100 |
> | expirationcollectionattribute |
> 0001016D001E0100 |
> | expirationcollectionattribute |
> 00F500010001001E001E0100 |
> | expirationcollectionattribute |
> 00F6000100010015001E0100 |
> +---+
> --+
> 4 rows in set (0.001 sec)

Given:

QByteArray ExpireCollectionAttribute::serialized() const
{
QByteArray result;
QDataStream s(, QIODevice::WriteOnly);

s << mExpireToFolderId;
s << (int)mExpireAction;
s << (int)mReadExpireUnits;
s << mReadExpireAge;
s << (int)mUnreadExpireUnits;
s << mUnreadExpireAge;
s << mExpireMessages;

return result;
}

Decode as:
   Read messages   Unread mesgs
FolderIdActionUnits   ReadAge  Units   Age   ExpireMessages
-1  0 1   120  0   30true
-1  0 1   365  0   30true
245 1 1   30   0   30true
246 1 1   21   0   30true

So I have 4 folders with expiry settings. Two of them delete (target folder ID
is -1) and two of them move to another folder.

The settings appear to be correct. This is indeed what I had configured.

But the settings page is not reloading the settings.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] Expiry settings not holding

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

--- Comment #5 from Thiago Macieira  ---
MariaDB [akonadi]> select type, hex(value) from collectionattributetable where
type='expirationcollectionattribute';
+---+--+
| type  | hex(value)   
   |
+---+--+
| expirationcollectionattribute |
00010078001E0100 |
| expirationcollectionattribute |
0001016D001E0100 |
| expirationcollectionattribute |
00F500010001001E001E0100 |
| expirationcollectionattribute |
00F6000100010015001E0100 |
+---+--+
4 rows in set (0.001 sec)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] Expiry settings not holding

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

--- Comment #4 from Thiago Macieira  ---
(In reply to Laurent Montel from comment #2)
> It seems that it works here.
> Which is the version ?

$ kmail --version
kmail2 5.17.3 (21.04.3)
$ akonadictl --version
akonadictl 5.17.3 (21.04.3)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] Expiry settings not holding

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

--- Comment #3 from Thiago Macieira  ---
In akonadiconsole, checking the properties of the folder in question, the
Attributes tab has a "expirationcollectionattribute", but it's empty. That
confirms the "not saving" part.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] Expiry settings not holding

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

Thiago Macieira  changed:

   What|Removed |Added

   Severity|normal  |grave

--- Comment #1 from Thiago Macieira  ---
This is a DATA LOSS issue for me. If I don't move emails from certain folders
before a deadline, they get removed.

This used to work a few weeks ago. It might have been a recent update that
caused this issue.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 440524] New: Expiry settings not holding

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=440524

Bug ID: 440524
   Summary: Expiry settings not holding
   Product: kmail2
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: folders
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
The folder properties for expiry are not getting saved.

STEPS TO REPRODUCE
1. Modify the expiry settings of a folder to expire (say) every 30 days
2. Click ok
3. Open the expiry dialog tab again

OBSERVED RESULT
The settings have disappeared.

EXPECTED RESULT
The settings are retained.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2 + kde patches

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 439786] Folder default identity not applied if identity UOID > 0x7fffffff

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=439786

Thiago Macieira  changed:

   What|Removed |Added

Summary|Folder default identity |Folder default identity not
   |does not obey account   |applied if identity UOID >
   |default identity|0x7fff

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 439786] Folder default identity does not obey account default identity

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=439786

Thiago Macieira  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|REPORTED|CONFIRMED

--- Comment #1 from Thiago Macieira  ---
Found it: the UOIDs are "negative":

Old machine, where it worked:

$ grep AccountIdentity= ~/.config/akonadi_imap*rc
/home/tjmaciei/.config/akonadi_imap_resource_0rc:AccountIdentity=1049262210
/home/tjmaciei/.config/akonadi_imap_resource_1rc:AccountIdentity=1804289383
/home/tjmaciei/.config/akonadi_imap_resource_4rc:AccountIdentity=1503410781
/home/tjmaciei/.config/akonadi_imap_resource_5rc:AccountIdentity=1503410781

New machine, where it didn't work:

$ grep AccountIdentity= ~/.config/akonadi_imap*rc
/home/tjmaciei/.config/akonadi_imap_resource_1rc:AccountIdentity=-936766798
/home/tjmaciei/.config/akonadi_imap_resource_3rc:AccountIdentity=-12177331
$ sed -n '/AccountIdentity=/s///p' akonadi_imap_resource_*rc | xargs printf
'%x\n'
c82a12b2
ff46304d

The negative numbers do match as two's complements in 32-bit of two of the
identities:

$ grep uoid emailidentities
uoid=2117733104
uoid=4282789965
uoid=3358200498
uoid=2643197268
$ sed -n '/uoid=/s///p' emailidentities | xargs printf '%x\n'
7e3a0af0
ff46304d
c82a12b2
9d8bfd54

After manually modifying the files so the high (sign) bit is not set, the
setting does work.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 439786] New: Folder default identity does not obey account default identity

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=439786

Bug ID: 439786
   Summary: Folder default identity does not obey account default
identity
   Product: kmail2
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: folders
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
The default email identity in any given folder in an IMAP account should be the
identity selected in that IMAP account's configuration. But it's not, it is
defaulting back to the global default.

The same KMail version has no problem on an older installation. So there must
be some hidden configuration somewhere that is preventing this from taking
effect. This is either an UX issue or a bug somewhere.

STEPS TO REPRODUCE
1. Add at least two email identities (KMail Settings > Accounts > Identities)
2. Add a new IMAP account, with an account default identity different from the
global default identity
3. Go to the new account's Inbox folder and create new email

OBSERVED RESULT
The new email's identity is the global default identity. If you check the
folder's properties, you will see that "Use default identity" is checked but
the selected identity is not the one from the account, but the global default.

EXPECTED RESULT
The new email should be using the per-account identity. The folder dialog
should be showing that account with the "Use default identity" checked.

SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 423963] Cannot spawn child process (unsupported clone flags) Qt

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423963

--- Comment #26 from Thiago Macieira  ---
That diff shows the original mistake in calling clone() without SIGCHLD.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 423963] Cannot spawn child process (unsupported clone flags) Qt

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423963

--- Comment #20 from Thiago Macieira  ---
(In reply to Christoph Cullmann from comment #19)
> I compiled now the 6.1 branch locally with
> 
> -DFEATURE_forkfd_pidfd=OFF
> 
> That triggers (at least if I don't read the Qt sources wrongly)
> 
> int ffdflags = FFD_CLOEXEC;
> 
> // QTBUG-86285
> #if !QT_CONFIG(forkfd_pidfd)
> ffdflags |= FFD_USE_FORK;
> #endif

> Naturally I assume that is not the "proper" fix.

No. That forces Qt to the old and pre-Linux 5.4 implementation that uses fork()
directly (which is a clone() call with only the flag SIGCHLD). Since it's not
using CLONE_PIDFD, it doesn't trigger whatever the issue in Valgrind is.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 423963] Cannot spawn child process (unsupported clone flags) Qt

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423963

--- Comment #18 from Thiago Macieira  ---
Yes, Qt uses CLONE_PIDFD. It was the first user of this feature (the feature
was written from our prompting and design). The flag has changed slightly since
the first time this bug was reported. It is now CLONE_PIDFD | SIGCHLD (the
SIGCHLD was missing in the original version).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 435167] IPv6: file browsing freezes on IPv4/IPv6 hydrid network due to nonsensical address passed to ssh

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=435167

--- Comment #5 from Thiago Macieira  ---
(In reply to 2wxsy58236r3 from comment #4)
> My network is also IPv4/IPv6 hybrid, and it seems that if I unpair and pair
> the devices again, and then browse the device via Dolphin, IPv6 will be used.
> 
> But after a period of time, it will fallback to IPv4 again. It seems that
> IPv4 is preferred most of the times.

That's not good. The selection should be deterministic, preferably using
established RFCs (3484 and 6724 come to mind, but I don't think they are
correct for this purpose). Since they are always intra-network (link-local)
addresses, I suppose we should prefer the local addresses to avoid accidentally
trafficking over routers and over the Internet, in which case the order should
be:

1) IPv6 link-local addresses, if possible (fe80::/64) - not always possible
because they need a scope identifier in the address and some tools will not
like that
2) IPv4 link-local addresses (169.254.0.0/16)
3) IPv6 realm-local addresses (you can probably ignore this)
4) IPv6 site-local addresses (fec0::/8 [deprecated], you can probably ignore
this)
5) IPv6 unique local addresses (fc00::/7)
6) IPv4 addresses reserved by RFC 1918 and 6598 (10.0.0.0/8, 100.64.0.0/10,
172.16.0.0/12, 192.168.0.0/16)
7) IPv6 global addresses
8) IPv4 global addresses

Or, alternatively speaking, sort addresses by ascending scope by grouping the
IPv6 local addresses with IPv4 private-use and shared-use ones, and IPv6
preferred over IPv4 in each scope. See
https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml#ipv6-scope
for the full list.

IPv6 v4-compat (::/96), Teredo (2001:0::/32) and 6to4 (2002::/16) addresses
should be excluded. IPv6 v4-mapped addresses (:::0.0.0.0/32) should be
treated like IPv4.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 435167] IPv6: file browsing freezes on IPv4/IPv6 hydrid network due to nonsensical address passed to ssh

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=435167

--- Comment #3 from Thiago Macieira  ---
(In reply to Bug Janitor Service from comment #2)
> A possibly relevant merge request was started @
> https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/389

I have a similar change that I was going to push to MR, but I can't test it.
After updating kdeconnect with my change, it starts sshfs with the IPv4 of my
phone.

How does the discovery decide what address(es) to try?

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 435167] IPv6: file browsing freezes on IPv4/IPv6 hydrid network due to nonsensical address passed to ssh

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=435167

--- Comment #1 from Thiago Macieira  ---
sshfs command-line seems to be:

/usr/bin/sshfs kdeconnect@2601:1c0:::4501:635c:ccfc:6576:1c93:dd1d:/
/run/user/1000/2f299915d02c5133 -p 1743 -s -f -F /dev/null -o
IdentityFile=/home/tjmaciei/.config/kdeconnect/privateKey.pem -o
StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
HostKeyAlgorithms=+ssh-dss -o uid=1000 -o gid=100 -o reconnect -o
ServerAliveInterval=30 -o password_stdin

Which is also incorrect.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 435167] IPv6: file browsing freezes on IPv4/IPv6 hydrid network due to nonsensical address passed to ssh

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=435167

Thiago Macieira  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|IPv6: file freezes on   |IPv6: file browsing freezes
   |IPv4/IPv6 hydrid network|on IPv4/IPv6 hydrid network
   |due to nonsensical address  |due to nonsensical address
   |passed to ssh   |passed to ssh
 Status|REPORTED|CONFIRMED

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 435167] New: IPv6: file freezes on IPv4/IPv6 hydrid network due to nonsensical address passed to ssh

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=435167

Bug ID: 435167
   Summary: IPv6: file freezes on IPv4/IPv6 hydrid network due to
nonsensical address passed to ssh
   Product: kdeconnect
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: common
  Assignee: albertv...@gmail.com
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
On a network with both IPv4 and IPv6, KDE Connect does find my Android phone,
as shown by the system tray applet and the device itself (unlike bug 427310).
Most functions work. File browsing does not and causes Dolphin and Plasma to
freeze.

STEPS TO REPRODUCE
1. Connect both the computer and Android phone to a network with both IPv4 and
IPv6
2. Ensure that KDE connect connects
3. Attempt to browse files on the phone

OBSERVED RESULT
Dolphin and Plasma freeze for a time. After some time (a minute?), Dolphin
displays a message in red at the top like "The file or folder
/run/user/1000/x/primary does not exist" (it really doesn't).

EXPECTED RESULT
KDE Connect browses my files.

SOFTWARE/OS VERSIONS
openSUSE Tumbleweed
KDE Plasma Version: 5.21.3
KDE Frameworks Version:  5.80.0
Qt Version: 5.12.2
KDE Connect Version: 20.12.3

ADDITIONAL INFORMATION
When the freeze is active, ssh can be seen in ps to run with the following
arguments:

ssh -x -a -oClearAllForwardings=yes -oPort=1740 -F/dev/null
-oIdentityFile=/home/tjmaciei/.config/kdeconnect/privateKey.pem
-oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null
-oHostKeyAlgorithms=+ssh-dss -oServerAliveInterval=30
-oNumberOfPasswordPrompts=1 -2 kdeconnect@2601 -s sftp

That "2601" is nonsensical. It's causing ssh to attempt to connect to IP
0.0.10.41. That "2601" is the first part of my IPv6 network address (as a
Comcast subscriber, I'm given a network in the prefix 2601:1c0::/26).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdeconnect] [Bug 427310] device discovery not working in ipv6-only network

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=427310

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

--- Comment #2 from Thiago Macieira  ---
(In reply to Daniel from comment #1)
> The correct IPv6 equivalent of IPv4 broadcast is this multicast address:
> ff02::1%wlan0, where wlan0 is the interface, of which the local devices
> should be discovered.

Do not ever use ff02::1. Get a multicast address for KDE Connect instead.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 350365] Battery monitor in tray randomly shows there is no battery

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=350365

--- Comment #65 from Thiago Macieira  ---
Will provide that when it happens again.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 423963] Cannot spawn child process

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423963

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

--- Comment #1 from Thiago Macieira  ---
See also https://bugs.kde.org/show_bug.cgi?id=427433

Qt 5.15.0 is not acceptable. Please upgrade to 5.15.2, which contains
https://codereview.qt-project.org/c/qt/qtbase/+/314049

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 427433] Unable to run QProcess: invalid file descriptor in syscall clone()

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=427433

--- Comment #12 from Thiago Macieira  ---
You can get debug symbols by installing package valgrind-debuginfo (after
enabling  "repo-debug": zypper mr -e repo-debug).

But if it works on the current Git master, then I'll be satisfied with the bug
being closed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 427433] Unable to run QProcess: invalid file descriptor in syscall clone()

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=427433

--- Comment #10 from Thiago Macieira  ---
(In reply to Paul Floyd from comment #9)
> The 1st error that Valgrind is seeing comes from this (trimmed)
> 
> static int detect_clone_pidfd_support()
> {
> sys_waitid(P_PIDFD, INT_MAX, NULL, WEXITED|WNOHANG, NULL);
> return errno == EBADF ? 1 : -1;
> }
> 
> Passing a dummmy siginfo_t for arg3 would fix the error.

I know, but this error is innocuous and the kernel doesn't complain, so I
didn't feel the need to pass something there.

> However the detection function is still doing its job. Valgrind says
> 
> SYSCALL[1740,1](247) ... [async] --> Failure(0x9) 
> 
> where 9 is EBADF.
> 
> After that, the clone is succeeding. I need to do more analysis and
> debugging to see what is causing the fd warning and assert.

Thank you for the effort.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 427433] Unable to run QProcess: invalid file descriptor in syscall clone()

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=427433

--- Comment #5 from Thiago Macieira  ---
(In reply to Paul Floyd from comment #4)
> Is this specific to Arch, or can you reproduce with other distros?

I can reproduce it on OpenSUSE Tumbleweed.

Please note it has to be the original testcase from Matthias.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 427433] Unable to run QProcess: invalid file descriptor in syscall clone()

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=427433

Thiago Macieira  changed:

   What|Removed |Added

 Attachment #13|0   |1
is obsolete||

--- Comment #3 from Thiago Macieira  ---
Created attachment 132224
  --> https://bugs.kde.org/attachment.cgi?id=132224=edit
Simplified (but not working) testcase with 4 pipes

This more closely resembles what QProcess does, but still does not trigger the
assertion failure in Valgrind.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 427433] Unable to run QProcess: invalid file descriptor in syscall clone()

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=427433

--- Comment #2 from Thiago Macieira  ---
Relevant section of strace of attachment 13 (parent process):
eventfd2(0, 0)  = 3
waitid(P_PIDFD, 2147483647, NULL, WNOHANG|WEXITED, NULL) = -1 EBADF (Bad file
descriptor)
pipe([4, 5])= 0
clone(child_stack=NULL, flags=CLONE_PIDFD|SIGCHLD, parent_tid=[6]) = 601608
write(3, "\1\0\0\0\0\0\0\0", 8) = 8
close(5)= 0
waitid(P_PIDFD, 6, {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=601608,
si_uid=1000, si_status=0, si_utime=0, si_stime=0}, WEXITED|__WALL, NULL) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=601608, si_uid=1000,
si_status=0, si_utime=0, si_stime=0} ---

Child process:
read(3, "\1\0\0\0\0\0\0\0", 8)  = 8
close(3)= 0
close(4)= 0
dup2(5, 1)  = 1
execve("/bin/true", ["/bin/true"], 0x7ffc69cbd8d8 /* 109 vars */) = 0


Relevant sections of strace of attachment 132203 (parent):
pipe2([3, 4], O_CLOEXEC)= 0
pipe2([5, 6], O_CLOEXEC)= 0
pipe2([7, 8], O_CLOEXEC)= 0
pipe2([9, 11], O_CLOEXEC)   = 0
getcwd("/tmp/qtbug-87230", 4096)= 17
statx(AT_FDCWD, "/usr/bin/uname", AT_STATX_SYNC_AS_STAT, STATX_ALL,
{stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0755,
stx_size=31464, ...}) = 0
access("/usr/bin/uname", X_OK)  = 0
waitid(P_PIDFD, 2147483647, NULL, WNOHANG|WEXITED, NULL) = -1 EBADF (Bad file
descriptor)
clone(child_stack=NULL, flags=CLONE_PIDFD|SIGCHLD, parent_tid=[12]) = 601703
close(11)   = 0
close(3)= 0
fcntl(4, F_GETFL)   = 0x1 (flags O_WRONLY)
fcntl(4, F_SETFL, O_WRONLY|O_NONBLOCK)  = 0
close(6)= 0
fcntl(5, F_GETFL)   = 0 (flags O_RDONLY)
fcntl(5, F_SETFL, O_RDONLY|O_NONBLOCK)  = 0
close(8)= 0
fcntl(7, F_GETFL)   = 0 (flags O_RDONLY)
fcntl(7, F_SETFL, O_RDONLY|O_NONBLOCK)  = 0
ppoll([{fd=9, events=POLLIN}], 1, {tv_sec=10, tv_nsec=0}, NULL, 8) = 1 ([{fd=9,
revents=POLLHUP}], left {tv_sec=9, tv_nsec=999333222})
read(9, "", 12) = 0
close(9)= 0
ppoll([{fd=-1}, {fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=12,
events=POLLIN}], 4, {tv_sec=10, tv_nsec=0}, NULL, 8) = 1 ([{fd=5,
revents=POLLIN}], left {tv_sec=9, tv_nsec=999564841})
ioctl(5, FIONREAD, [115])   = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=601703, si_uid=1000,
si_status=0, si_utime=0, si_stime=0} ---

Child process:
rt_sigaction(SIGPIPE, {sa_handler=SIG_DFL, sa_mask=[PIPE],
sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f8434879530},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
dup3(3, 0, 0)   = 0
dup3(6, 1, 0)   = 1
dup3(8, 2, 0)   = 2
close(9)= 0
execve("/usr/bin/uname", ["/usr/bin/uname", "-a"], 0x7ffceab80858 /* 109 vars
*/) = 0


The QProcess example has 4 pipes instead of 1 and it stops on poll() instead of
waitid(). Otherwise, the code is supposed to be the same.

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 427433] Unable to run QProcess: invalid file descriptor in syscall clone()

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=427433

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

--- Comment #1 from Thiago Macieira  ---
Created attachment 13
  --> https://bugs.kde.org/attachment.cgi?id=13=edit
Simplified (but not working) testcase

The attached is a simplified testcase I had used to submit
https://sourceware.org/bugzilla/show_bug.cgi?id=26562. It uses clone with
CLONE_PIDFD directly. It does produce the first warning (the waitid one) in
Valgrind.

But it is not causing the assertion failure for me. So this is not a proper
testcase, just something to show what Qt is attempting to do.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 424259] plasmashell produces a lot of warnings in the journal

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=424259

--- Comment #3 from Thiago Macieira  ---
(In reply to David Edmundson from comment #1)
> This is in frameworks, KDE frameworks has to support Qt 5.12
> Qt 5.12 doesn't support the new connection syntax.
> 
> We can't port the code, it'd break
> We can't just add an #ifdef as it's QML (well, not without some external
> pre-processing)

Then please report this on the Qt bug tracker against QML. QML knows which
version of things you imported, so it shouldn't warn about things you can't use
in that version.

Or any other solution the QML developers feel you should use.

As a user, I don't care how this is solved. So long as it's solved. (cc me in
the bug report or paste the link here so I can say so).

> I did add a faux Qt logging category so one can turn them off.
> 
> My initial intention was I would just make Plasma ship an environment
> variable with that set, but it turns out that breaks other people's custom
> Qt logging rule files so I wasn't able to ship it. You have this as an
> option for yourself.
> 
> Maybe I could maybe add QLoggingCategory::installFilter() into every
> applicable app?

Unclean solutions. But since we need to put up with existing releases of Qt,
that might be needed.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krunner] [Bug 424260] New: krunner produces warning "QCommandLineParser: argument list cannot be empty, it should contain at least the executable name"

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=424260

Bug ID: 424260
   Summary: krunner produces warning "QCommandLineParser: argument
list cannot be empty, it should contain at least the
executable name"
   Product: krunner
   Version: 5.19.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: k...@privat.broulik.de
  Reporter: thi...@kde.org
CC: plasma-b...@kde.org
  Target Milestone: ---

SUMMARY
This warning is printed.

QCommandLineParser: argument list cannot be empty, it should contain at least
the executable name

SOFTWARE/OS VERSIONS
openSUSE Tumbleweed 20200701
Qt: 5.15.0
KDE Frameworks: 5.71.0
kf5-config: 1.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 424259] New: plasmashell produces a lot of warnings in the journal

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=424259

Bug ID: 424259
   Summary: plasmashell produces a lot of warnings in the journal
   Product: plasmashell
   Version: 5.19.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: k...@davidedmundson.co.uk
  Reporter: thi...@kde.org
CC: plasma-b...@kde.org
  Target Milestone: 1.0

SUMMARY
There are a LOT of warnings in the log:

[320269.615587] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320407.541390] plasmashell[2176]:
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ScrollViewStyle.qml:60:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320407.552092] plasmashell[2176]:
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:209:13:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320407.556901] plasmashell[2176]:
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:209:13:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320407.559680] plasmashell[2176]:
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/ToolButtonStyle.qml:209:13:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320407.560003] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationHeader.qml:78:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320817.541187] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320817.577108] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320817.604298] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320817.639130] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320817.661544] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320853.312257] plasmashell[2176]:
file:///usr/lib64/qt5/qml/QtQuick/Controls/Styles/Plasma/BusyIndicatorStyle.qml:39:9:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320853.313665] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }
[320854.194550] plasmashell[2176]:
file:///usr/share/plasma/plasmoids/org.kde.plasma.taskmanager/contents/ui/Task.qml:285:5:
QML Connections: Implicitly defined onFoo properties in Connections are
deprecated. Use this syntax instead: function onFoo() { ... }


STEPS TO REPRODUCE
1. Start Plasmashell

OBSERVED RESULT
Warnings are logged.

EXPECTED RESULT
No warnings are logged.

SOFTWARE/OS VERSIONS
openSUSE Tumbleweed 20200701
Qt: 5.15.0
KDE Frameworks: 5.71.0
kf5-config: 1.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 424246] New: KMail sometimes won't exit (closes the windows but stays running)

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=424246

Bug ID: 424246
   Summary: KMail sometimes won't exit (closes the windows but
stays running)
   Product: kmail2
   Version: 5.14.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
Under certain conditions I am not sure how to reproduce reliably, but can
describe, the KMail process will not exit after Ctrl+Q. All windows close, but
the process stays running in the background.

This usually happens after selecting an email that, for reasons unknown, fails
to be displayed. The KMail message window says it's fetching the email (from an
offline-cached IMAP account, so there's nothing to be fetched) and stays there
forever. No amount of time waited will get it out of this condition.

STEPS TO REPRODUCE
1. Cause the condition.
2. Exit KMail by Ctrl+Q, File > Exit or clicking the X button at the top right

OBSERVED RESULT
KMail windows close, but process stays running in the background. Forever.

EXPECTED RESULT
KMail process exits within reasonable time (less than 15 seconds).

SOFTWARE/OS VERSIONS
openSUSE Tumbleweed 20200701
Qt: 5.15.0
KDE Frameworks: 5.71.0
kf5-config: 1.0

ADDITIONAL INFORMATION
Hypothesis for the fault is the same as bug #424244: an Akonadi::Job fails to
finish, holding the reference count up from 0.

In fact, using the Akonadiconsole's job tracker, I can see there's a job that
never finishes. That is, by itself, a bug. But KMail needs to exit even if
there's a valid reason for the job to take a long time (say, you've clicked on
an email with a Blu-Ray attached on an online-IMAP account).

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 424245] New: Agent says "Connection established" without having any connection

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=424245

Bug ID: 424245
   Summary: Agent says "Connection established" without having any
connection
   Product: Akonadi
   Version: 5.14.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: IMAP resource
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
In Akonadiconsole, the IMAP agent may display "Connection Established" but have
no active IP socket open.

STEPS TO REPRODUCE
1. Disable Qt bearer plugins: chmod 0 /usr/lib64/qt5/plugins/bearer
2. Restart IMAP agent

OBSERVED RESULT
"Connection Established" is shown, never changes, but there's no outgoing
socket open.

EXPECTED RESULT
Either there's an active socket connection or the state is something different.

SOFTWARE/OS VERSIONS
openSUSE Tumbleweed 20200701
Qt: 5.15.0
KDE Frameworks: 5.71.0
kf5-config: 1.0

ADDITIONAL INFORMATION

$ lsof -n -p `pgrep -f akonadi_imap_resource_5` | grep -v 'mem'
COMMAND  PID USER   FD  TYPE DEVICE  SIZE/OFF NODE
NAME
akonadi_i 924121 tjmaciei  cwd   DIR  254,8  4096  1441793
/home/tjmaciei
akonadi_i 924121 tjmaciei  rtd   DIR   0,46   174  256
/
akonadi_i 924121 tjmaciei  txt   REG   0,46725896 14384221
/usr/bin/akonadi_imap_resource
akonadi_i 924121 tjmaciei  DEL   REG   0,24  30475
/run/nscd/dbs0pP3p
akonadi_i 924121 tjmaciei0r FIFO   0,12   0t0 11057102
pipe
akonadi_i 924121 tjmaciei1w  CHR1,3   0t0 1028
/dev/null
akonadi_i 924121 tjmaciei2w  REG  254,8   3956351  2398618
/home/tjmaciei/.local/share/sddm/xorg-session.log
akonadi_i 924121 tjmaciei3u unix 0x   0t0 11057519
type=STREAM
akonadi_i 924121 tjmaciei4u  a_inode   0,13 013421
[eventfd]
akonadi_i 924121 tjmaciei5u  a_inode   0,13 013421
[eventfd]
akonadi_i 924121 tjmaciei6u  CHR  226,0   0t014125
/dev/dri/card0
akonadi_i 924121 tjmaciei7u  CHR  226,0   0t014125
/dev/dri/card0
akonadi_i 924121 tjmaciei8u  a_inode   0,13 013421
[eventfd]
akonadi_i 924121 tjmaciei9u unix 0x   0t0 11052964
type=STREAM
akonadi_i 924121 tjmaciei   10u  a_inode   0,13 013421
[eventfd]
akonadi_i 924121 tjmaciei   11u unix 0x   0t0 11057108
type=STREAM
akonadi_i 924121 tjmaciei   12u unix 0x   0t0 11054925
type=STREAM
akonadi_i 924121 tjmaciei   13u unix 0x   0t0 11052967
type=STREAM
akonadi_i 924121 tjmaciei   14u  a_inode   0,13 013421
[eventfd]

As you can see, there's no "inet" file descriptor.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Akonadi] [Bug 424244] New: Agents sometimes don't exit after being told to restart

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=424244

Bug ID: 424244
   Summary: Agents sometimes don't exit after being told to
restart
   Product: Akonadi
   Version: 5.14.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: libakonadi
  Assignee: kdepim-b...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
Sometimes, an agent is in a weird state. If you go to KMail, right-click and
select Restart Account, or in Akonadiconsole select Restart Agent, the agent
doesn't exit.

STEPS TO REPRODUCE
1. Get into this condition (unknown how; probably related to network interfaces
going up and down)
2. Open Akonadiconsole, select affected agent, get its Identifier and find it
in the ps process list
3. Right-click the agent, Restart Account

OBSERVED RESULT
The same process is still running.


EXPECTED RESULT
A new process shows up in the process list

SOFTWARE/OS VERSIONS
Qt: 5.15.0
KDE Frameworks: 5.71.0
kf5-config: 1.0

ADDITIONAL INFORMATION
strace shows the process received a D-Bus message asking it to exit:

[pid  2894] recvmsg(9, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="l\1\0\1\0\0\0\0q\210\2\0\236\0\0\0\1\1o\0\1\0\0\0/\0\0\0\0\0\0\0\6\1s\0005\0\0\0org.freedesktop.Akonadi.Agent.akonadi_imap_resource_5\0\0\0\2\1s\0%\0\0\0org.freedesktop.Akonadi.Agent.Control\0\0\0\3\1s\0\4\0\0\0quit\0\0\0\0\7\1s\0\5\0\0\0:1.31\0\0\0",
iov_len=2048}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_CMSG_CLOEXEC},
MSG_CMSG_CLOEXEC) = 176

It replied confirming it received this message:

[pid  2894] sendmsg(9, {msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="l\2\1\1\0\0\0\0\5#\1\0\30\0\0\0\6\1s\0\5\0\0\0:1.31\0\0\0\5\1u\0q\210\2\0",
iov_len=40}, {iov_base="", iov_len=0}], msg_iovlen=2, msg_controllen=0,
msg_flags=0}, MSG_NOSIGNAL 

But didn't exit.

Hypothesis: there's a job inside the process that is holding the event loop
counter above 0. So the event loop doesn't exit.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 423940] Unable to bring up the lower interfaces in a bond

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423940

--- Comment #4 from Thiago Macieira  ---
(In reply to Jan Grulich from comment #3)
> Created attachment 129955 [details]
> Patch to fix this issue
> 
> We are filtering out the slaves in the model. To be honest I don't know much
> about bond, bridge or team connections, I assumed they will be always
> managed by their master connection. 
> 
> Does the patch make sense to you? It should not filter slaves in case
> virtual connections are allowed to be shown. And most importantly, does it
> work?

That's a good question, I don't know how they should be properly managed in a
well-designed UX. I would indeed expect that bringing the controlling layer up
enabled the controlled interfaces too, but that's not how NM seems to be
behaving. You need to bring each one up.

Maybe we do that filtering: if any of the lower interfaces can be enabled, the
bond or bridge can be enabled and that's what shows up in the menu. Once you do
turn that on, then the other interfaces show up in the menu so you can select
which of them you want to turn on (if they're automatic connection, then they
get turned on automatically).

The patch looks correct for a simple solution to my problem, not what I
described.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 423940] Unable to bring up the lower interfaces in a bond

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423940

--- Comment #2 from Thiago Macieira  ---
(In reply to Jan Grulich from comment #1)
> Have you tried opening the KCM, going into configuration and check "Show
> virtual connections?

Yes, that is how I added the upper connection in the first place. The bonded
(lower) connections do show up in the editor dialog on the right side (in the
Bond tab), but not on the left. That means I can't right-click to activate
them.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 423942] New: Unable to set a bond's MAC address

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423942

Bug ID: 423942
   Summary: Unable to set a bond's MAC address
   Product: plasma-nm
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: editor
  Assignee: jgrul...@redhat.com
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
When one of the lower connections of a bond is WiFi, you have to set the bond's
MAC address to match the WiFi's, otherwise your AP will generally not accept
your wireless frames. This should be possible with Plasma-NM.

Note that nmcli edit does not offer to set "ethernet.cloned-mac-address"
either, but you can set it and it works.

STEPS TO REPRODUCE
1. Open the connection editor
2. Add a new Bond-type connection (or edit the one you have)

OBSERVED RESULT
No way to set or change the MAC address of the bond.

EXPECTED RESULT
Like for Wired or Wireless connections, there should be a way to specify the
cloned MAC address.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 5.7.5, openSUSE Tumbleweed 20200701
KDE Plasma Version: 5.19.2
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0

ADDITIONAL INFORMATION
See Bug 423940 for a working configuration of this set up.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 423941] New: Unable to create lower WiFi connection for Bond

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423941

Bug ID: 423941
   Summary: Unable to create lower WiFi connection for Bond
   Product: plasma-nm
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: editor
  Assignee: jgrul...@redhat.com
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
It is possible to create a bond over WiFi, but it can't be done in the
plasma-nm connection editor. Once you create a bond and you can add/edit the
lower interfaces, the option to add a Wireless interface is not there. 

It is there for Bridges, but WiFi can't be added to bridges unless you enable
WiFi 4Addr or run the WiFi in AP mode (with hostapd).

STEPS TO REPRODUCE
1. Open the connection editor
2. Add a new Bond interface (or edit one you already have)
3. Click the "+ Add" button

OBSERVED RESULT
Options available are "Ethernet" and "Infiniband"

EXPECTED RESULT
Options should include WiFi

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 5.7.5, openSUSE Tumbleweed 20200701
KDE Plasma Version: 5.19.2
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0

ADDITIONAL INFORMATION
See Bug 423940 for a working configuration of this set up.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 423940] New: Unable to bring up the lower interfaces in a bond

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423940

Bug ID: 423940
   Summary: Unable to bring up the lower interfaces in a bond
   Product: plasma-nm
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jgrul...@redhat.com
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
I have created a bonded group of interfaces, with my WiFi and Ethernet (source:
https://fedoramagazine.org/bond-wifi-and-ethernet-for-easier-networking-mobility/).
I see no way to bring up the two lower interfaces with the plasma-nm applet; I
have to do it with nmcli c up.

STEPS TO REPRODUCE
1. Click the plasma-nm applet icon in plasma

OBSERVED RESULT
None of the lower bonded connections are displayed.

EXPECTED RESULT
There should be a way to bring up the lower connections.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 5.7.5, openSUSE Tumbleweed 20200701
KDE Plasma Version: 5.19.2
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0

ADDITIONAL INFORMATION
# tail -n50 Docked@Home*
==> Docked@Home WiFi.nmconnection <==
[connection]
id=Docked@Home WiFi
uuid=cf70e61d-b8a1-4085-b426-50138f9263a5
type=wifi
master=7da92a4c-032d-42be-b5f2-ec173a90d1ee
permissions=
slave-type=bond
timestamp=1593991638

[wifi]
mac-address-blacklist=
mode=infrastructure
ssid=REDACTED

[wifi-security]
key-mgmt=wpa-psk
psk=REDACTED

==> Docked@Home Wired.nmconnection <==
[connection]
id=Docked@Home Wired
uuid=6224ea40-801a-4932-846c-0fb909025965
type=ethernet
interface-name=enp57s3
master=7da92a4c-032d-42be-b5f2-ec173a90d1ee
permissions=
slave-type=bond
timestamp=1593701652

[ethernet]
mac-address-blacklist=

==> Docked@Home.nmconnection <==
[connection]
id=Docked@Home
uuid=7da92a4c-032d-42be-b5f2-ec173a90d1ee
type=bond
interface-name=bond0
permissions=

[ethernet]
cloned-mac-address=REDACTED
mac-address-blacklist=

[bond]
mode=active-backup
primary=enp57s3

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

[proxy]

-- 
You are receiving this mail because:
You are watching all bug changes.

[KScreen] [Bug 423939] New: off-by-one pixel activating secondary monitor (hidpi)

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=423939

Bug ID: 423939
   Summary: off-by-one pixel activating secondary monitor (hidpi)
   Product: KScreen
   Version: 5.19.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: common
  Assignee: kscreen-bugs-n...@kde.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
When activating my second 4K monitor via the KCM, the position of the second
screen is off-by-1 pixel. It overlaps 1 pixel with the primary screen, causing
weird window maximisation issues.

STEPS TO REPRODUCE
1. Plug second monitor (HiDPI for both in my case)
2. Enable it via the KCM

OBSERVED RESULT
DP1-2 connected 3840x2160+3199+0 (normal left inverted right x axis y axis)
600mm x 340mm

EXPECTED RESULT
DP1-2 connected 3840x2160+3200+0 (normal left inverted right x axis y axis)
600mm x 340mm

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux 5.7.5, openSUSE Tumbleweed 20200701
KDE Plasma Version: 5.19.2
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0

ADDITIONAL INFORMATION
$ kscreen-console bug  
[ 31522.903] kscreen-console(69013 69013)(unknown): START: Requesting
Config
[ 31522.921] kscreen-console(69013 69013)(unknown): Received config. Took
18 milliseconds

xrandr --verbose==
Screen 0: minimum 8 x 8, current 7040 x 2160, maximum 32767 x 32767
eDP1 connected primary 3200x1800+0+0 (0x4a) normal (normal left inverted right
x axis y axis) 290mm x 170mm
Identifier: 0x43
Timestamp:  30250214
Subpixel:   unknown
Gamma:  1.0:1.0:1.0
Brightness: 1.0
Clones:
CRTC:   0
CRTCs:  0 1 2
Transform:  1.00 0.00 0.00
0.00 1.00 0.00
0.00 0.00 1.00
   filter: 
EDID: 
00004d102114
32180104a51d11780ede50a3544c9926
0f50540001010101010101010101
010101010101cd9180a0c00834703020
350026a510180010
00fe0030
35503748854c51315a31
000241032800120b010a2020001b
BACKLIGHT: 290 
range: (0, 937)
Backlight: 290 
range: (0, 937)
scaling mode: Full aspect 
supported: Full, Center, Full aspect
Colorspace: Default 
supported: Default, RGB_Wide_Gamut_Fixed_Point,
RGB_Wide_Gamut_Floating_Point, opRGB, DCI-P3_RGB_D65, BT2020_RGB, BT601_YCC,
BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, BT2020_CYCC, BT2020_YCC
max bpc: 12 
range: (6, 12)
Broadcast RGB: Automatic 
supported: Automatic, Full, Limited 16:235
panel orientation: Normal 
supported: Normal, Upside Down, Left Side Up, Right Side Up
link-status: Good 
supported: Good, Bad
non-desktop: 0 
range: (0, 1)
  3200x1800 (0x4a) 373.250MHz -HSync -VSync *current +preferred
h: width  3200 start 3248 end 3280 total 3360 skew0 clock 111.09KHz
v: height 1800 start 1803 end 1808 total 1852   clock  59.98Hz
  3200x1800 (0x1b7) 373.000MHz +HSync -VSync
h: width  3200 start 3248 end 3280 total 3360 skew0 clock 111.01KHz
v: height 1800 start 1803 end 1808 total 1852   clock  59.94Hz
  2880x1620 (0x1b8) 303.750MHz +HSync -VSync
h: width  2880 start 2928 end 2960 total 3040 skew0 clock  99.92KHz
v: height 1620 start 1623 end 1628 total 1666   clock  59.97Hz
  2560x1600 (0x1b9) 348.500MHz -HSync +VSync
h: width  2560 start 2760 end 3032 total 3504 skew0 clock  99.46KHz
v: height 1600 start 1603 end 1609 total 1658   clock  59.99Hz
  2560x1600 (0x1ba) 268.500MHz +HSync -VSync
h: width  2560 start 2608 end 2640 total 2720 skew0 clock  98.71KHz
v: height 1600 start 1603 end 1609 total 1646   clock  59.97Hz
  2560x1440 (0x1bb) 312.250MHz -HSync +VSync
h: width  2560 start 2752 end 3024 total 3488 skew0 clock  89.52KHz
v: height 1440 start 1443 end 1448 total 1493   clock  59.96Hz
  2560x1440 (0x1bc) 311.827MHz -HSync +VSync
h: width  2560 start 2744 end 3024 total 3488 skew0 clock  89.40KHz
v: height 1440 start 1441 end 1444 total 1490   clock  60.00Hz
  2560x1440 (0x1bd) 241.500MHz +HSync -VSync
h: width  2560 start 2608 end 2640 total 2720 skew0 clock  88.79KHz
v: height 1440 start 1443 end 1448 total 1481   clock  59.95Hz
  2048x1536 (0x1be) 266.950MHz -HSync +VSync
h: width  2048 start 2200 end 2424 total 2800 skew0 clock  95.34KHz
v: 

[valgrind] [Bug 417906] clone with CLONE_VFORK and no CLONE_VM fails

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=417906

--- Comment #6 from Thiago Macieira  ---
Want me to open a separate report for P_PIDFD? Crude adapting your testcase:

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
  int pid;
  int fd;

  if ((pid = syscall(SYS_clone, CLONE_VFORK | CLONE_PIDFD, NULL, , NULL, 0))
< 0)
{
  perror("clone");
}
  else if (pid > 0)
{
  struct siginfo si;
  struct rusage usage;

  printf("pidfd = %d\n", fd);
  syscall(SYS_waitid, fd, P_PIDFD, , WEXITED | __WALL, );
}

  exit(0);
}

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 417906] Please add support for Linux 5.2 CLONE_PIDFD flag to clone()

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=417906

--- Comment #1 from Thiago Macieira  ---
First reported at https://bugreports.qt.io/browse/QTBUG-82351

-- 
You are receiving this mail because:
You are watching all bug changes.

[valgrind] [Bug 417906] New: Please add support for Linux 5.2 CLONE_PIDFD flag to clone()

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=417906

Bug ID: 417906
   Summary: Please add support for Linux 5.2 CLONE_PIDFD flag to
clone()
   Product: valgrind
   Version: 3.15 SVN
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jsew...@acm.org
  Reporter: thi...@kde.org
  Target Milestone: ---

SUMMARY
Linux 5.2 added CLONE_PIDFD flag to the clone() system call, which returns a
file descriptor representing the child process. Qt 5.15 will use this flag to
have a better representation of child processes, without the need to use a
SIGCHLD handler. This is also, finally, thread-safe.

Running Valgrind on an application using Qt 5.15's QProcess class produces:

==180074== Unsupported clone() flags: 0x5000
==180074== 
==180074== The only supported clone() uses are:
==180074==  - via a threads library (LinuxThreads or NPTL)
==180074==  - via the implementation of fork or vfork
==180074== 
==180074== Valgrind detected that your program requires
==180074== the following unimplemented functionality:
==180074==Valgrind does not support general clone().
==180074== This may be because the functionality is hard to implement,
==180074== or because no reasonable program would behave this way,
==180074== or because nobody has yet needed it.  In any case, let us know at
==180074== www.valgrind.org and/or try to work around the problem, if you can.
==180074== 
==180074== Valgrind has to exit now.  Sorry.  Bye!

CLONE_PIDFD is 0x1000. CLONE_VFORK is 0x4000.

Without CLONE_VFORK, execution seems to continue but produce nonsensical
results.

OBSERVED RESULT
Valgrind either terminates or produce nonsensical reports when CLONE_PIDFD is
used.

EXPECTED RESULT
CLONE_PIDFD is understood properly

SOFTWARE/OS VERSIONS
Linux 5.5.2

ADDITIONAL INFORMATION
Please also implement the P_PIDFD argument to waitid(), available since Linux
5.4. Linux 5.3 added clone3 system call, but we're not using it yet.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kio-extras] [Bug 204423] Spaces in Domains makes SMB:// useless

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=204423

--- Comment #8 from Thiago Macieira  ---
(In reply to Harald Sitter from comment #7)
> Thanks.
> 
> With that in mind we cannot really support spaces while also following the
> smb URI format [1]. I suppose we'll just have to deviate a bit iff the
> workgroup name contains a space by using a variant of the notation that
> stuffs the workgroup into the userinfo `smb://work group;@/` and then
> translate that back to an smb URI for libsmbclient again. Means the urls
> wont be portable but at least navigation within our tech works.
> 
> [1] https://www.iana.org/assignments/uri-schemes/prov/smb

You may need the user info for the actual user name that is being used to
search that work group. I would recommend using the path or query component
instead:

smb://userwg;user:password@/browsed_workgroup
smb://userwg;user:password@/?=search=browsed_workgroup

This searches the workgroup named "browsed_workgroup" with the user
"userwg\user".

The query has the added benefit a server inside the workgroup is a proper
sub-URL:

smb://userwg;user:password@server/share/folder/file.txt?search=browsed_workgroup

That is,

  QUrl wg("smb://user@/?search=WG");
  QUrl relative("/share/folder/file.txt");
  qDebug() << wg.resolved(relative);  //
"smb://user@/share/folder/file.txt?search=WG"

-- 
You are receiving this mail because:
You are watching all bug changes.

[kio-extras] [Bug 204423] Spaces in Domains makes SMB:// useless

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=204423

Thiago Macieira  changed:

   What|Removed |Added

 CC||thi...@kde.org

--- Comment #6 from Thiago Macieira  ---
QUrl's behaviour is intentional. The hostname component of the URL has to be a
valid hostname.

Do not store anything in that component that is not a hostname. Like a
workgroup name. Store that elsewhere.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 415597] "No Batteries Available" despite detecting a battery

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=415597

--- Comment #6 from Thiago Macieira  ---
(In reply to Kai Uwe Broulik from comment #5)
> Looks like a race or timing issue to me.. I've had similar reports in the
> past but I have never seen it happen on my system. :/
> 
> Maybe the DataModel (that turns Plasma DataEngine data into a QAIM) gets
> confused when the battery is added later, or something isn't initialized yet
> on login when Plasmashell starts initially but works later.
> 
> Did this happen after suspend or on fresh login?

I didn't notice when it started happening. I don't usually use my system on
battery power, so it was running for 5 days until I realised I wasn't seeing
the battery icon.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 415597] "No Batteries Available" despite detecting a battery

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=415597

--- Comment #4 from Thiago Macieira  ---
Huh, the battery does show then.

After restarting Plasma, the battery does show now. I don't know why or when
this started. Do you want me to investigate more or shall we close?

-- 
You are receiving this mail because:
You are watching all bug changes.

[Powerdevil] [Bug 415597] "No Batteries Available" despite detecting a battery

[Thiago Macieira]

https://bugs.kde.org/show_bug.cgi?id=415597

--- Comment #2 from Thiago Macieira  ---
(In reply to Kai Uwe Broulik from comment #1)
> Does plasmaengineexplorer (part of plasma-sdk) also show it in power
> management engine? That's where data for the battery monitor comes from.

Yes, it does.

I have a Battery and a Battery0, with the latter showing the correct energy
level and remaining time, as Solid shows.

-- 
You are receiving this mail because:
You are watching all bug changes.