kwallet-pam: just provide plugin path for qtbase#84689
Merged
matthewbauer merged 1 commit intoNixOS:masterfrom Apr 9, 2020
Merged
kwallet-pam: just provide plugin path for qtbase#84689matthewbauer merged 1 commit intoNixOS:masterfrom
matthewbauer merged 1 commit intoNixOS:masterfrom
Conversation
ofborg
bot
added
6.topic: qt/kde
Member
Let's also add |
Member
|
The build fails for me: |
worldofpeace
approved these changes
Apr 8, 2020
Contributor
|
But please add a comment why we're doing this. Someone could easily look at this and be like "well this needs to be updated for wrapQtApp` and break it again because we have no testing. |
Member
Author
Updated with a fix for this - I was just passing in wrong args to wrapProgram. |
matthewbauer
force-pushed
the
fix-77290
branch
2 times, most recently
from
33ba091 to
8021f0a
Compare
worldofpeace
added
the
9.needs: port to stable
Contributor
|
This doesn't build for me. The build errorHowever, putting back the FYI: I guess that's also why the grahamcofborg builds fail. |
kwallet sets a limit of 1000 for a single characters for environment variables read from the socket[1]. wrapQtApps gives us a huge value for QT_PLUGIN_PATH (up to 13000 bytes on my system!) Since this was overflowing, the Qt plugin loading mechanism was hitting a segfault when it was trying to parse the truncated QT_PLUGIN_PATH. So for now, we can just unset QT_PLUGIN_PATH in the pam_kwallet_init script. kwalletd5 has its own QT_PLUGIN_PATH which it can use. This problem occured on 20.03, but not 19.09. It’s unclear what changes were made in that time, but likely that previously we weren’t getting a QT_PLUGIN_PATH set in the plasma5 startup at all. This means that in 19.09 our QT_PLUGIN_PATH value must have been small enough to fit into the 1000 char limit. Fixes NixOS#77290 [1]: https://github.com/KDE/kwallet/blob/bc9713e2725ab1c4311866f751c674a38584bd92/src/runtime/kwalletd/main.cpp#L44 /cc @ttuegel
ofborg
bot
added
10.rebuild-linux: 0
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
10 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
kwallet sets a limit of 1000 for a single characters for environment
variables read from the socket[1]. wrapQtApps gives us a huge value
for QT_PLUGIN_PATH (up to 13000 bytes on my system!) Since this was
overflowing, the Qt plugin loading mechanism was hitting a segfault
when it was trying to parse the truncated QT_PLUGIN_PATH.
So for now, we can just unset QT_PLUGIN_PATH in the pam_kwallet_init
script. kwalletd5 has its own QT_PLUGIN_PATH which it can use.
This problem occured on 20.03, but not 19.09. It’s unclear what
changes were made in that time, but likely that previously we weren’t
getting a QT_PLUGIN_PATH set in the plasma5 startup at all. This means
that in 19.09 our QT_PLUGIN_PATH value must have been small enough to
fit into the 1000 char limit.
Fixes #77290
/cc @ttuegel