[KDE Config Driver Manager] [Bug 402901] kdesrc-build --initial-setup reports "* No installer for linux!" when executing the command on Debian 9 stable
https://bugs.kde.org/show_bug.cgi?id=402901 --- Comment #8 from Michael Pyne --- Git commit a5d286145e9b9374b5e9c6ec6045de1e58f812e9 by Michael Pyne. Committed on 06/01/2019 at 02:39. Pushed by ashark into branch 'no-ff-recreate'. first-run: Add basic installer and packages for Debian distros. This adds the installer to allow Debian-based distros to run and a basic set of packages needed to at least allow kdesrc-build to successfully run --initial-setup, as tested under a Docker image of debian 9. This will still miss the dependencies required to fully make it through any kind of reasonable KDE software build. In particular even if I included the list of Qt modules that Debian 9 stable has available, they are too old for current git-based applications. But other modules are probably needed and still missing (suggestions accepted! :). So there's still more to do here, which is why the bug remains open. See issue #15 Original commit: 845e9da4 https://invent.kde.org/sdk/kdesrc-build/-/commit/845e9da4ac262e14161bb777449d85972cfe6103 M +3-1distro-dependencies/debian.ini https://invent.kde.org/sysadmin/repo-metadata/-/commit/a5d286145e9b9374b5e9c6ec6045de1e58f812e9 -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 402484] kdesrc-build's initial setup needs to install perl-io-socket-ssl on Arch et al.
https://bugs.kde.org/show_bug.cgi?id=402484 Michael Pyne changed: What|Removed |Added Latest Commit|e84022a7acd6347b34cefd58a5c |https://invent.kde.org/sysa |002e4bf03f440 |dmin/repo-metadata/-/commit ||/0ff608a2cf7b58dfa7fef9e247 ||4bbb8d873065fa --- Comment #3 from Michael Pyne --- Git commit 0ff608a2cf7b58dfa7fef9e2474bbb8d873065fa by Michael Pyne, on behalf of Nate Graham. Committed on 26/12/2018 at 01:28. Pushed by ashark into branch 'no-ff-recreate'. Add Arch package for IO::Socket::SSL as a kdesrc-build dep. Fixes #3 Differential Revision: https://phabricator.kde.org/D17768 FIXED-IN:19.01 Original commit: e84022a7 https://invent.kde.org/sdk/kdesrc-build/-/commit/e84022a7acd6347b34cefd58a5c002e4bf03f440 M +1-1distro-dependencies/arch.ini https://invent.kde.org/sysadmin/repo-metadata/-/commit/0ff608a2cf7b58dfa7fef9e2474bbb8d873065fa -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 473859] Add short options for --include-dependencies and --no-include-dependencies
https://bugs.kde.org/show_bug.cgi?id=473859 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/sdk/ ||kdesrc-build/-/commit/5b155 ||c5e29dd2d377fd1f84fb42d0e62 ||9a9f368b Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Michael Pyne --- Git commit 5b155c5e29dd2d377fd1f84fb42d0e629a9f368b by Michael Pyne. Committed on 07/09/2023 at 02:34. Pushed by mpyne into branch 'master'. Add short options for --[no-]include-dependencies. This adds and documents -d as a short alias for --include-dependencies, and a corresponding -D as its negation. While I'm at it, and at user request, this also adds short options for: * --help * --no-src * --src-only * --refresh-build * --ignore-modules * --resume-from and --resume-after M +11 -11 doc/index.docbook M +28 -10 doc/man-kdesrc-build.1.docbook M +37 -21 modules/ksb/Cmdline.pm https://invent.kde.org/sdk/kdesrc-build/-/commit/5b155c5e29dd2d377fd1f84fb42d0e629a9f368b -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 456593] plasma-wayland-protocol builds, but doesn't install properly
https://bugs.kde.org/show_bug.cgi?id=456593 --- Comment #7 from Michael Pyne --- Git commit 7e1a75e66d5b6ac4fc0db3e828d13728cd04f83c by Michael Pyne. Committed on 14/07/2022 at 22:47. Pushed by mpyne into branch 'master'. buildsystem: Be more restrictive on when to skip install. This fixes a bug where the documentation of how to force kdesrc-build to proceed with the install "--refresh-build this module to force install" did not match kdesrc-build's behavior. But in addition this adds a check that the module was ever successfully installed by checking for a matching persistent option. I suspect this might be part of the problem experienced by a user in bug 456593. M +6-3modules/ksb/Module.pm https://invent.kde.org/sdk/kdesrc-build/commit/7e1a75e66d5b6ac4fc0db3e828d13728cd04f83c -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kjobwidgets] [Bug 450325] Ark crashes in KUiServerV2JobTracker::registerJob() when turning on second monitor
https://bugs.kde.org/show_bug.cgi?id=450325 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/fram |https://invent.kde.org/fram |eworks/kjobwidgets/commit/b |eworks/kjobwidgets/commit/5 |8752085d2a480dfc93d2d422c46 |aeba3f01ef8cdf723813cacdd29 |3a59d46af5ee|945328288663 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #27 from Michael Pyne --- Git commit 5aeba3f01ef8cdf723813cacdd29945328288663 by Michael Pyne. Committed on 09/07/2022 at 18:42. Pushed by mpyne into branch 'master'. ui-server: Fix crash by only re-registering live KJobs. This addresses a frequently-reported crash in the job tracker for KUiServerV2 that occurs when attempting to re-register new job views for active KJobs after a new UI server comes online. Although I have not been able to reproduce the crash myself, (by attempting to use both long-lived and short-lived file transfers from Dolphin and restarting plasmashell), inspection of the code shows that it is possible for there to be deleted KJobs pointing to JobView objects during some portions of the job tracker's lifetime. The current code deals with this in situations including DBus calls to create a U/I view for a KJob (the KJob may terminate before the DBus reply is received) and even a short delay that can be optionally introduced (the KJob may terminate before the delay elapses). A QPointer is used as a guard in these situations, but there is no similar guard for the re-registration code. In this case we cannot use QPointer to guard the job's lifetime because the KJob must be alive when the QPointer is created, and this crash occurs when the KJob is terminated. However the KJob's destruction should lead to the unregisterJob() function being called, which handles removing the terminated KJob from the map of job views with only one exception, where instead the job view for the KJob has its "terminated" pending status set. So the fix here checks for the "terminated" state in the same way as performed in requestView(), and if the KJob is terminated, handles requesting the job view to terminate the U/I and finally removing the terminated KJob from the map of job views. By doing this, we avoid passing a deleted KJob to the registerJob() function, which will attempt to dereference it and crash the application. See also merge request !22 M +16 -4src/kuiserverv2jobtracker.cpp https://invent.kde.org/frameworks/kjobwidgets/commit/5aeba3f01ef8cdf723813cacdd29945328288663 -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 436739] kdesrc-build fails to update packages that don't have a "master" branch
https://bugs.kde.org/show_bug.cgi?id=436739 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/sdk/ ||kdesrc-build/commit/f1d429d ||147f8ec0240e6ac0f6ab2eec797 ||a6c4dd Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Michael Pyne --- Git commit f1d429d147f8ec0240e6ac0f6ab2eec797a6c4dd by Michael Pyne. Committed on 08/07/2022 at 00:52. Pushed by mpyne into branch 'master'. git: Don't fail to clone due to branch name if none required. There is a wider variety of potential default branch names from a git repository that we might want to clone. Many use now 'main' but not all of them. We also have modules that use something else entirely, like 'dev' (as reported in bug 436739). Most of the time the user doesn't actually care about the branch, they just want whatever the mainline trunk is. To handle this we had previously defaulted to assuming the branch was 'master' so we could optimize the amount of data transferred during initial clone. Now this is likely to lead to an error. Instead, if the user hasn't specified otherwise, just perform the git clone as normal. To do this right there's a wee bit of other work elsewhere to detect which branch head we actually got from the remote git repository but that's not difficult to do either. M +21 -6modules/ksb/Updater/Git.pm https://invent.kde.org/sdk/kdesrc-build/commit/f1d429d147f8ec0240e6ac0f6ab2eec797a6c4dd -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kjobwidgets] [Bug 450325] Ark crashes in KUiServerV2JobTracker::registerJob() when turning on second monitor
https://bugs.kde.org/show_bug.cgi?id=450325 Michael Pyne changed: What|Removed |Added Ever confirmed|0 |1 Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #23 from Michael Pyne --- I thought that a MR needed to be merged to master to have its BUG: close a bug, reopening until a fix is merged. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kjobwidgets] [Bug 450325] Ark crashes in KUiServerV2JobTracker::registerJob() when turning on second monitor
https://bugs.kde.org/show_bug.cgi?id=450325 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/fram ||eworks/kjobwidgets/commit/b ||8752085d2a480dfc93d2d422c46 ||3a59d46af5ee Status|REPORTED|RESOLVED --- Comment #22 from Michael Pyne --- Git commit b8752085d2a480dfc93d2d422c463a59d46af5ee by Michael Pyne. Committed on 02/07/2022 at 22:13. Pushed by mpyne into branch 'work-bug-450325-fix-crash'. ui-server: Fix crash by only re-registering live KJobs. This addresses a frequently-reported crash in the job tracker for KUiServerV2 that occurs when attempting to re-register new job views for active KJobs after a new UI server comes online. Although I have not been able to reproduce the crash myself, (by attempting to use both long-lived and short-lived file transfers from Dolphin and restarting plasmashell), inspection of the code shows that it is possible for there to be deleted KJobs pointing to JobView objects during some portions of the job tracker's lifetime. The current code deals with this in situations including DBus calls to create a U/I view for a KJob (the KJob may terminate before the DBus reply is received) and even a short delay that can be optionally introduced (the KJob may terminate before the delay elapses). A QPointer is used as a guard in these situations, but there is no similar guard for the re-registration code. In this case we cannot use QPointer to guard the job's lifetime because the KJob must be alive when the QPointer is created, and this crash occurs when the KJob is terminated. However the KJob's destruction should lead to the unregisterJob() function being called, which handles removing the terminated KJob from the map of job views with only one exception, where instead the job view for the KJob has its "terminated" pending status set. So the fix here checks for the "terminated" state in the same way as performed in requestView(), and if the KJob is terminated, handles requesting the job view to terminate the U/I and finally removing the terminated KJob from the map of job views. By doing this, we avoid passing a deleted KJob to the registerJob() function, which will attempt to dereference it and crash the application. M +16 -4src/kuiserverv2jobtracker.cpp https://invent.kde.org/frameworks/kjobwidgets/commit/b8752085d2a480dfc93d2d422c463a59d46af5ee -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kjobwidgets] [Bug 450325] Ark crashes in KUiServerV2JobTracker::registerJob() when turning on second monitor
https://bugs.kde.org/show_bug.cgi?id=450325
--- Comment #21 from Michael Pyne ---
(In reply to Christoph Cullmann from comment #20)
> Sounds like a reasonable explanation.
well, maybe. I did find the code meant to update the jobView structure when the
KJob is finished, but it is a) called indirectly (from
KUiServerV2JobTracker::unregisterJob), and b) has a weird special case to
handle terminated KJobs that don't have an existing view (presumably because
the signal that would create it being later in the event loop):
// Remember that the job finished in the meantime and
// terminate the JobView once it arrives
d->scheduleUpdate(job, QStringLiteral("terminated"), true);
if (job->error()) {
d->scheduleUpdate(job, QStringLiteral("errorCode"),
static_cast(job->error()));
d->scheduleUpdate(job, QStringLiteral("errorMessage"),
job->errorText());
}
But scheduleUpdate() simply recreates the jobView mapping to the soon-to-be
dead KJob and if the re-registration happens before the "terminate the JobView
once it arrives" occurs we're in for a bad time, as the re-registration code
assumes all entries in the map of jobs to jobViews have valid KJobs.
I'll take a look at how best to handle the weird lifetimes here and try to open
the MR tonight.
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kjobwidgets] [Bug 450325] Ark crashes in KUiServerV2JobTracker::registerJob() when turning on second monitor
https://bugs.kde.org/show_bug.cgi?id=450325
Michael Pyne changed:
What|Removed |Added
CC||mp...@kde.org
--- Comment #19 from Michael Pyne ---
I suspect the issue is in using a deleted KJob when re-registering a job view
(kuiserverv2jobtracker.cpp:197)
// Watch the server registering/unregistering and re-register the jobs as
needed
if (!d->serverRegisteredConnection) {
d->serverRegisteredConnection = connect(serverProxy(),
::serverRegistered, this, [this]() {
const auto staleViews = d->jobViews;
// elided
for (auto it = staleViews.begin(), end = staleViews.end(); it !=
end; ++it) {
KJob *job = it.key();
const JobView = it.value();
// elided
registerJob(job);
In the section of code right after this in registerJob, the code is careful to
ensure that a QPointer is used in order to verify that the KJob being
registered won't have been deleted in the functor to be added to the event loop
by QTimer (kuiserverv2jobtracker.cpp:248):
QPointer jobGuard = job;
QTimer *delayTimer = new QTimer();
delayTimer->setSingleShot(true);
connect(delayTimer, ::timeout, this, [this, job, jobGuard,
desktopEntry] {
// elided
});
This part of the code also references the d->jobViews the re-registration code
uses earlier, so if it were possible to assume that a KJob* held in d->jobViews
was enough to guarantee the KJob were still valid, the later delay timer could
have done the same thing. It would take more code to do this so that's not
airtight evidence, but I can't find anywhere else that guarantees a KJob ending
also removes its JobView (the re-registration code as much as calls it a
"stale" job view...) so I suspect this is the cause of this crash.
I'll put together a patch that uses the same QPointer jobGuard trick and
open an MR.
--
You are receiving this mail because:
You are watching all bug changes.
[kdesrc-build] [Bug 289754] kdesrc-build should flag module as unbuilt if last build for that module was interrupted
https://bugs.kde.org/show_bug.cgi?id=289754 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/sdk/ ||kdesrc-build/commit/8f80fdf ||17cb5c49b9993f5a0bf395402da ||ab5d8e Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #2 from Michael Pyne --- Git commit 8f80fdf17cb5c49b9993f5a0bf395402daab5d8e by Michael Pyne. Committed on 24/06/2022 at 02:40. Pushed by mpyne into branch 'master'. build: Ensure a rebuild following an interrupted build is attempted. Previously, interrupting a module build during the build was not treated as a build failure, so the module's persistent options were not changed. In the normal scenario this means the module's last build was remembered as a success. Then by default, when you'd go to rebuild the module right after, the build would be skipped because the source didn't change. M +10 -3modules/ksb/Application.pm https://invent.kde.org/sdk/kdesrc-build/commit/8f80fdf17cb5c49b9993f5a0bf395402daab5d8e -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 431921] Black square appears sometimes in KMail
https://bugs.kde.org/show_bug.cgi?id=431921 --- Comment #7 from Michael Pyne --- If it occurs in multiple programs it is likely a style bug (presumably breeze). If you're up to it, you could try running kmail as "kmail -style fusion" to try a different theme (Qt has a "Fusion" theme built-in) and see if the black square still comes up at random intervals. Note that KMail will look a bit different if you run it this way since the style is different. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 317666] juk startup is slow if using tree mode
https://bugs.kde.org/show_bug.cgi?id=317666 --- Comment #8 from Michael Pyne --- Git commit a65a4e8a037bae5d2731267b60ed61bf09526413 by Michael Pyne. Committed on 26/03/2021 at 01:52. Pushed by mpyne into branch 'release/21.04'. tag_scan: Fix painful rescan of music metadata on startup. For the longest time, JuK has suffered from a problem where its intended behavior to load music metadata from a cached database, instead of re-scanning every individual track on startup, was not working right. There has been debugging lines in JuK since all the way back to 2013 trying to trace what area of startup sequence was taking up all the time, but to no avail in helping me fix the bug. The Problem === Recently I took a different approach, of adding a debug-only crash whenever we would load a music track tag the "slow" way, and long story short there were two bugs that each would cause slowdown: 1. Playlists aside from the CollectionList would cause every music track in that playlist to be re-scanned. What this means is that every though the music in the CollectionList would be loaded quickly, if you had that same music track in a separate Playlist, that music track would reload the same tags from disk rather than copying from the existing CollectionList item. This was especially bad for users of the old "tree mode" view, since every individual artist *and* album were rendered as individual playlists, which would therefore each re-scan the music over and over again. 2. JuK supports a "folder scan" feature, and in fact really wants the user to have at least one folder assigned. Any music identified in this folder is added to the CollectionList automatically on startup and, you guessed it, causes the music track information to be loaded from disk, even if the music was already in the CollectionList! :( The net effect is that most music would be re-scanned on startup unless you were a user who used CollectionList exclusively, and had most of your music not visible to the folder scanner. The Solution Due to how painful this problem has been, I had ended up adding a threaded solution for the folder scan process. This didn't help make things any faster but at least the GUI wasn't frozen. But now that the threading code is present I judged it would be easier and safer to make the central object holding track metadata (CollectionList's m_itemsDict) available in thread-safe fashion. This then permitted me to check for whether a track has already been loaded when performing folder scan, and to check whether a track has already been loaded when creating a new (non-CollectionList) Playlist. In either event if the track already exists, then we copy the FileHandle rather than create a new one. The combination speeds up loading significantly, taking anywhere from 60% to 70% off of the total time to load on my system, with mostly a CollectionList under folder scan and few additional playlists. In this configuration I go from about 5.4 seconds to 1.5 seconds with cold caches. The difference should be even more stark on systems where disk I/O is expensive, or where there are a great number of tracks in playlists outside of the CollectionList. I consider this a bugfix (and there are even multiple bug reports) so I will backport shortly. CHANGELOG:Reduce startup time by 60-70% or more. Related: bug 428772 FIXED-IN:21.04 (cherry picked from commit d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab) M +58 -25 collectionlist.cpp M +5-3collectionlist.h M +11 -3directoryloader.cpp M +6-1filehandle.cpp M +10 -1playlist.cpp https://invent.kde.org/multimedia/juk/commit/a65a4e8a037bae5d2731267b60ed61bf09526413 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 428772] JuK painful folder scanning at the EVERY (Re)start
https://bugs.kde.org/show_bug.cgi?id=428772 --- Comment #2 from Michael Pyne --- Git commit a65a4e8a037bae5d2731267b60ed61bf09526413 by Michael Pyne. Committed on 26/03/2021 at 01:52. Pushed by mpyne into branch 'release/21.04'. tag_scan: Fix painful rescan of music metadata on startup. For the longest time, JuK has suffered from a problem where its intended behavior to load music metadata from a cached database, instead of re-scanning every individual track on startup, was not working right. There has been debugging lines in JuK since all the way back to 2013 trying to trace what area of startup sequence was taking up all the time, but to no avail in helping me fix the bug. The Problem === Recently I took a different approach, of adding a debug-only crash whenever we would load a music track tag the "slow" way, and long story short there were two bugs that each would cause slowdown: 1. Playlists aside from the CollectionList would cause every music track in that playlist to be re-scanned. What this means is that every though the music in the CollectionList would be loaded quickly, if you had that same music track in a separate Playlist, that music track would reload the same tags from disk rather than copying from the existing CollectionList item. This was especially bad for users of the old "tree mode" view, since every individual artist *and* album were rendered as individual playlists, which would therefore each re-scan the music over and over again. 2. JuK supports a "folder scan" feature, and in fact really wants the user to have at least one folder assigned. Any music identified in this folder is added to the CollectionList automatically on startup and, you guessed it, causes the music track information to be loaded from disk, even if the music was already in the CollectionList! :( The net effect is that most music would be re-scanned on startup unless you were a user who used CollectionList exclusively, and had most of your music not visible to the folder scanner. The Solution Due to how painful this problem has been, I had ended up adding a threaded solution for the folder scan process. This didn't help make things any faster but at least the GUI wasn't frozen. But now that the threading code is present I judged it would be easier and safer to make the central object holding track metadata (CollectionList's m_itemsDict) available in thread-safe fashion. This then permitted me to check for whether a track has already been loaded when performing folder scan, and to check whether a track has already been loaded when creating a new (non-CollectionList) Playlist. In either event if the track already exists, then we copy the FileHandle rather than create a new one. The combination speeds up loading significantly, taking anywhere from 60% to 70% off of the total time to load on my system, with mostly a CollectionList under folder scan and few additional playlists. In this configuration I go from about 5.4 seconds to 1.5 seconds with cold caches. The difference should be even more stark on systems where disk I/O is expensive, or where there are a great number of tracks in playlists outside of the CollectionList. I consider this a bugfix (and there are even multiple bug reports) so I will backport shortly. CHANGELOG:Reduce startup time by 60-70% or more. Related: bug 317666 FIXED-IN:21.04 (cherry picked from commit d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab) M +58 -25 collectionlist.cpp M +5-3collectionlist.h M +11 -3directoryloader.cpp M +6-1filehandle.cpp M +10 -1playlist.cpp https://invent.kde.org/multimedia/juk/commit/a65a4e8a037bae5d2731267b60ed61bf09526413 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 428772] JuK painful folder scanning at the EVERY (Re)start
https://bugs.kde.org/show_bug.cgi?id=428772 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/d6b28a9b4 ||c8e21a0b9ccd5bb7585091e501d ||94ab Version Fixed In||21.04 Status|REPORTED|RESOLVED --- Comment #1 from Michael Pyne --- Git commit d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab by Michael Pyne. Committed on 26/03/2021 at 01:48. Pushed by mpyne into branch 'master'. tag_scan: Fix painful rescan of music metadata on startup. For the longest time, JuK has suffered from a problem where its intended behavior to load music metadata from a cached database, instead of re-scanning every individual track on startup, was not working right. There has been debugging lines in JuK since all the way back to 2013 trying to trace what area of startup sequence was taking up all the time, but to no avail in helping me fix the bug. The Problem === Recently I took a different approach, of adding a debug-only crash whenever we would load a music track tag the "slow" way, and long story short there were two bugs that each would cause slowdown: 1. Playlists aside from the CollectionList would cause every music track in that playlist to be re-scanned. What this means is that every though the music in the CollectionList would be loaded quickly, if you had that same music track in a separate Playlist, that music track would reload the same tags from disk rather than copying from the existing CollectionList item. This was especially bad for users of the old "tree mode" view, since every individual artist *and* album were rendered as individual playlists, which would therefore each re-scan the music over and over again. 2. JuK supports a "folder scan" feature, and in fact really wants the user to have at least one folder assigned. Any music identified in this folder is added to the CollectionList automatically on startup and, you guessed it, causes the music track information to be loaded from disk, even if the music was already in the CollectionList! :( The net effect is that most music would be re-scanned on startup unless you were a user who used CollectionList exclusively, and had most of your music not visible to the folder scanner. The Solution Due to how painful this problem has been, I had ended up adding a threaded solution for the folder scan process. This didn't help make things any faster but at least the GUI wasn't frozen. But now that the threading code is present I judged it would be easier and safer to make the central object holding track metadata (CollectionList's m_itemsDict) available in thread-safe fashion. This then permitted me to check for whether a track has already been loaded when performing folder scan, and to check whether a track has already been loaded when creating a new (non-CollectionList) Playlist. In either event if the track already exists, then we copy the FileHandle rather than create a new one. The combination speeds up loading significantly, taking anywhere from 60% to 70% off of the total time to load on my system, with mostly a CollectionList under folder scan and few additional playlists. In this configuration I go from about 5.4 seconds to 1.5 seconds with cold caches. The difference should be even more stark on systems where disk I/O is expensive, or where there are a great number of tracks in playlists outside of the CollectionList. I consider this a bugfix (and there are even multiple bug reports) so I will backport shortly. CHANGELOG:Reduce startup time by 60-70% or more. Related: bug 317666 FIXED-IN:21.04 M +58 -25 collectionlist.cpp M +5-3collectionlist.h M +11 -3directoryloader.cpp M +6-1filehandle.cpp M +10 -1playlist.cpp https://invent.kde.org/multimedia/juk/commit/d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 317666] juk startup is slow if using tree mode
https://bugs.kde.org/show_bug.cgi?id=317666 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/d6b28a9b4 ||c8e21a0b9ccd5bb7585091e501d ||94ab Version Fixed In||21.04 Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Michael Pyne --- Git commit d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab by Michael Pyne. Committed on 26/03/2021 at 01:48. Pushed by mpyne into branch 'master'. tag_scan: Fix painful rescan of music metadata on startup. For the longest time, JuK has suffered from a problem where its intended behavior to load music metadata from a cached database, instead of re-scanning every individual track on startup, was not working right. There has been debugging lines in JuK since all the way back to 2013 trying to trace what area of startup sequence was taking up all the time, but to no avail in helping me fix the bug. The Problem === Recently I took a different approach, of adding a debug-only crash whenever we would load a music track tag the "slow" way, and long story short there were two bugs that each would cause slowdown: 1. Playlists aside from the CollectionList would cause every music track in that playlist to be re-scanned. What this means is that every though the music in the CollectionList would be loaded quickly, if you had that same music track in a separate Playlist, that music track would reload the same tags from disk rather than copying from the existing CollectionList item. This was especially bad for users of the old "tree mode" view, since every individual artist *and* album were rendered as individual playlists, which would therefore each re-scan the music over and over again. 2. JuK supports a "folder scan" feature, and in fact really wants the user to have at least one folder assigned. Any music identified in this folder is added to the CollectionList automatically on startup and, you guessed it, causes the music track information to be loaded from disk, even if the music was already in the CollectionList! :( The net effect is that most music would be re-scanned on startup unless you were a user who used CollectionList exclusively, and had most of your music not visible to the folder scanner. The Solution Due to how painful this problem has been, I had ended up adding a threaded solution for the folder scan process. This didn't help make things any faster but at least the GUI wasn't frozen. But now that the threading code is present I judged it would be easier and safer to make the central object holding track metadata (CollectionList's m_itemsDict) available in thread-safe fashion. This then permitted me to check for whether a track has already been loaded when performing folder scan, and to check whether a track has already been loaded when creating a new (non-CollectionList) Playlist. In either event if the track already exists, then we copy the FileHandle rather than create a new one. The combination speeds up loading significantly, taking anywhere from 60% to 70% off of the total time to load on my system, with mostly a CollectionList under folder scan and few additional playlists. In this configuration I go from about 5.4 seconds to 1.5 seconds with cold caches. The difference should be even more stark on systems where disk I/O is expensive, or where there are a great number of tracks in playlists outside of the CollectionList. I consider this a bugfix (and there are even multiple bug reports) so I will backport shortly. CHANGELOG:Reduce startup time by 60-70% or more. Related: bug 428772 FIXED-IN:21.04 M +58 -25 collectionlist.cpp M +5-3collectionlist.h M +11 -3directoryloader.cpp M +6-1filehandle.cpp M +10 -1playlist.cpp https://invent.kde.org/multimedia/juk/commit/d6b28a9b4c8e21a0b9ccd5bb7585091e501d94ab -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 303901] Restart album when using random album
https://bugs.kde.org/show_bug.cgi?id=303901 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/mult |https://invent.kde.org/mult |imedia/juk/commit/6aef3be86 |imedia/juk/commit/b46844f6a |82d829f07ab86901ceff8755fee |ad1359f971ad2c876d7c0728cec |8610|77d5 --- Comment #5 from Michael Pyne --- Git commit b46844f6aad1359f971ad2c876d7c0728cec77d5 by Michael Pyne. Committed on 25/03/2021 at 01:38. Pushed by mpyne into branch 'release/21.04'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 336637, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 (cherry picked from commit 6aef3be8682d829f07ab86901ceff8755fee8610) M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +1-0juk.cpp M +19 -29 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +21 -22 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/b46844f6aad1359f971ad2c876d7c0728cec77d5 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 404157] Track length is not updated when advancing in the playlist
https://bugs.kde.org/show_bug.cgi?id=404157 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/mult |https://invent.kde.org/mult |imedia/juk/commit/6aef3be86 |imedia/juk/commit/b46844f6a |82d829f07ab86901ceff8755fee |ad1359f971ad2c876d7c0728cec |8610|77d5 --- Comment #3 from Michael Pyne --- Git commit b46844f6aad1359f971ad2c876d7c0728cec77d5 by Michael Pyne. Committed on 25/03/2021 at 01:38. Pushed by mpyne into branch 'release/21.04'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 303901, bug 336637, bug 353259, bug 417551 FIXED-IN:21.04 (cherry picked from commit 6aef3be8682d829f07ab86901ceff8755fee8610) M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +1-0juk.cpp M +19 -29 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +21 -22 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/b46844f6aad1359f971ad2c876d7c0728cec77d5 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 353259] Juk player will not play tracks added to play queue
https://bugs.kde.org/show_bug.cgi?id=353259 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/mult |https://invent.kde.org/mult |imedia/juk/commit/6aef3be86 |imedia/juk/commit/b46844f6a |82d829f07ab86901ceff8755fee |ad1359f971ad2c876d7c0728cec |8610|77d5 --- Comment #3 from Michael Pyne --- Git commit b46844f6aad1359f971ad2c876d7c0728cec77d5 by Michael Pyne. Committed on 25/03/2021 at 01:38. Pushed by mpyne into branch 'release/21.04'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 303901, bug 336637, bug 404157, bug 417551 FIXED-IN:21.04 (cherry picked from commit 6aef3be8682d829f07ab86901ceff8755fee8610) M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +1-0juk.cpp M +19 -29 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +21 -22 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/b46844f6aad1359f971ad2c876d7c0728cec77d5 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 336637] After playing queued items, juk returns to "collection" not previous playlist
https://bugs.kde.org/show_bug.cgi?id=336637 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/mult |https://invent.kde.org/mult |imedia/juk/commit/6aef3be86 |imedia/juk/commit/b46844f6a |82d829f07ab86901ceff8755fee |ad1359f971ad2c876d7c0728cec |8610|77d5 --- Comment #4 from Michael Pyne --- Git commit b46844f6aad1359f971ad2c876d7c0728cec77d5 by Michael Pyne. Committed on 25/03/2021 at 01:38. Pushed by mpyne into branch 'release/21.04'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 303901, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 (cherry picked from commit 6aef3be8682d829f07ab86901ceff8755fee8610) M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +1-0juk.cpp M +19 -29 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +21 -22 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/b46844f6aad1359f971ad2c876d7c0728cec77d5 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 165899] juk take to much CPU / Power when IDLE
https://bugs.kde.org/show_bug.cgi?id=165899 --- Comment #5 from Michael Pyne --- Git commit b64b37616f0490f60526defaf5335c4731dd41b4 by Michael Pyne. Committed on 25/03/2021 at 01:29. Pushed by mpyne into branch 'release/21.04'. systemtray: Cleanups and modernization. Also a timer bugfix. The bug: When using the track popup announcement, a timer kicks off to tell the popup to fade out. A second timer is used to incrementally fade the popup a bit every few milliseconds until the popup can finally be hidden. However the first timer was never stopped, and would kick off the fadeout sequence again, over and over, only hidden to view since the popup is no longer visible. This might be related to the old bug 165899 (which I tried to fix a different way). I believe this happened in the Qt3/4 transition since the code seems to assume the first timer was a "single shot" timer, but it could have been wrong forever. (cherry picked from commit 62561ad031a2c1c03f9abc266c621d83e48f6b8b) M +80 -84 systemtray.cpp M +12 -14 systemtray.h https://invent.kde.org/multimedia/juk/commit/b64b37616f0490f60526defaf5335c4731dd41b4 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 417551] Juk ignores the queue if a file gets dragged there
https://bugs.kde.org/show_bug.cgi?id=417551 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/mult |https://invent.kde.org/mult |imedia/juk/commit/6aef3be86 |imedia/juk/commit/b46844f6a |82d829f07ab86901ceff8755fee |ad1359f971ad2c876d7c0728cec |8610|77d5 --- Comment #2 from Michael Pyne --- Git commit b46844f6aad1359f971ad2c876d7c0728cec77d5 by Michael Pyne. Committed on 25/03/2021 at 01:38. Pushed by mpyne into branch 'release/21.04'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 303901, bug 336637, bug 353259, bug 404157 FIXED-IN:21.04 (cherry picked from commit 6aef3be8682d829f07ab86901ceff8755fee8610) M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +1-0juk.cpp M +19 -29 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +21 -22 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/b46844f6aad1359f971ad2c876d7c0728cec77d5 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 166711] random playing is not so random
https://bugs.kde.org/show_bug.cgi?id=166711 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/mult |https://invent.kde.org/mult |imedia/juk/commit/6aef3be86 |imedia/juk/commit/b46844f6a |82d829f07ab86901ceff8755fee |ad1359f971ad2c876d7c0728cec |8610|77d5 --- Comment #7 from Michael Pyne --- Git commit b46844f6aad1359f971ad2c876d7c0728cec77d5 by Michael Pyne. Committed on 25/03/2021 at 01:38. Pushed by mpyne into branch 'release/21.04'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 302250, bug 303901, bug 336637, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 (cherry picked from commit 6aef3be8682d829f07ab86901ceff8755fee8610) M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +1-0juk.cpp M +19 -29 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +21 -22 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/b46844f6aad1359f971ad2c876d7c0728cec77d5 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 100356] double-click to play item only works, till play-queue was used
https://bugs.kde.org/show_bug.cgi?id=100356 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/mult |https://invent.kde.org/mult |imedia/juk/commit/6aef3be86 |imedia/juk/commit/b46844f6a |82d829f07ab86901ceff8755fee |ad1359f971ad2c876d7c0728cec |8610|77d5 --- Comment #7 from Michael Pyne --- Git commit b46844f6aad1359f971ad2c876d7c0728cec77d5 by Michael Pyne. Committed on 25/03/2021 at 01:38. Pushed by mpyne into branch 'release/21.04'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 166711, bug 302250, bug 303901, bug 336637, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 (cherry picked from commit 6aef3be8682d829f07ab86901ceff8755fee8610) M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +1-0juk.cpp M +19 -29 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +21 -22 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/b46844f6aad1359f971ad2c876d7c0728cec77d5 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 302250] juk album random play does not play album
https://bugs.kde.org/show_bug.cgi?id=302250 Michael Pyne changed: What|Removed |Added Latest Commit|https://invent.kde.org/mult |https://invent.kde.org/mult |imedia/juk/commit/6aef3be86 |imedia/juk/commit/b46844f6a |82d829f07ab86901ceff8755fee |ad1359f971ad2c876d7c0728cec |8610|77d5 --- Comment #5 from Michael Pyne --- Git commit b46844f6aad1359f971ad2c876d7c0728cec77d5 by Michael Pyne. Committed on 25/03/2021 at 01:38. Pushed by mpyne into branch 'release/21.04'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 303901, bug 336637, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 (cherry picked from commit 6aef3be8682d829f07ab86901ceff8755fee8610) M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +1-0juk.cpp M +19 -29 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +21 -22 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/b46844f6aad1359f971ad2c876d7c0728cec77d5 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 356224] Always move the caret to the currently playing item
https://bugs.kde.org/show_bug.cgi?id=356224 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Version Fixed In||21.04 Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/cbfe92c37 ||14ba1edf1403a46ae79d905db28 ||1aaf Resolution|--- |FIXED --- Comment #2 from Michael Pyne --- Git commit cbfe92c3714ba1edf1403a46ae79d905db281aaf by Michael Pyne. Committed on 24/03/2021 at 03:08. Pushed by mpyne into branch 'master'. playlist: Ensure playing track is visible when it changes. I tried to ensure this only causes the playlist to jump when the user isn't directly interacting with the track (e.g. double click to play). FIXED-IN:21.04 M +1-1playermanager.cpp M +10 -2playlist.cpp M +1-1playlist.h M +6-0playlistcollection.cpp https://invent.kde.org/multimedia/juk/commit/cbfe92c3714ba1edf1403a46ae79d905db281aaf -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 210384] Juk starts(?) but no window ever comes up
https://bugs.kde.org/show_bug.cgi?id=210384 Michael Pyne changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|RESOLVED --- Comment #11 from Michael Pyne --- I remember this bug and fixed it a few years back. Though I don't seem to have made it easy to find the commit that did it. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 100571] Wrong playlist after last song in Play Queue finished
https://bugs.kde.org/show_bug.cgi?id=100571 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Latest Commit||6aef3be8682d829f07ab86901ce ||ff8755fee8610 Version Fixed In||21.04 Resolution|--- |FIXED CC||mp...@kde.org --- Comment #3 from Michael Pyne --- I believe this is fixed with a recent commit to JuK. In some of my testing I was able to reproduce ways for the Play Queue to end up switching to the CollectionList instead of the last item's playlist but I can't reproduce that myself now... this mostly seems to work for me. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 222919] Juk: clicking on Album name of current played song produces list with false entries
https://bugs.kde.org/show_bug.cgi?id=222919 Michael Pyne changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #4 from Michael Pyne --- I haven't been able to reproduce this in years, though I have refactored this code a bit to fix some other bugs which should hopefully address this as well. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 373056] The player works, but no music
https://bugs.kde.org/show_bug.cgi?id=373056 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED Latest Commit||6aef3be8682d829f07ab86901ce ||ff8755fee8610 Version Fixed In||21.04 --- Comment #2 from Michael Pyne --- I believe this is fixed with a recent commit that should be included in the upcoming 21.04 release. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 336250] Hide action using a wrong icon
https://bugs.kde.org/show_bug.cgi?id=336250 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/83cb227ee ||4e7b2b713f3c0799960adc04c1f ||fd5e Status|REOPENED|RESOLVED Resolution|--- |FIXED Version Fixed In||21.04 --- Comment #3 from Michael Pyne --- Git commit 83cb227ee4e7b2b713f3c0799960adc04c1ffd5e by Michael Pyne. Committed on 23/03/2021 at 03:50. Pushed by mpyne into branch 'master'. playqueue: Use an appropriate icon for rebadged "remove playlist" action. A JuK user pointed out that the Play Queue context menu shows "Hide" instead of "Remove Playlist" on the context menu, but that the icon still looks like a trash can, which is not appropriate for "Hide". I wasn't sure of a great icon to use either, but "list-remove" at least does not imply that the Play Queue is being tossed in the rubbish. FIXED-IN:21.04 M +14 -10 playlistbox.cpp https://invent.kde.org/multimedia/juk/commit/83cb227ee4e7b2b713f3c0799960adc04c1ffd5e -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 420500] Please make "Use random play" toggleable
https://bugs.kde.org/show_bug.cgi?id=420500 Michael Pyne changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|RESOLVED --- Comment #1 from Michael Pyne --- Please try using the "Random Play" action for the toolbar. This is a dropdown button or a context menu that contains all the potential random playback toggles (there are 3 rather than 2 so it's not directly suitable to be a toggle button). -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 166711] random playing is not so random
https://bugs.kde.org/show_bug.cgi?id=166711 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/6aef3be86 ||82d829f07ab86901ceff8755fee ||8610 Version Fixed In||21.04 --- Comment #6 from Michael Pyne --- Git commit 6aef3be8682d829f07ab86901ceff8755fee8610 by Michael Pyne. Committed on 23/03/2021 at 02:59. Pushed by mpyne into branch 'master'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 302250, bug 303901, bug 336637, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +0-1juk.cpp M +2-21 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +14 -18 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/6aef3be8682d829f07ab86901ceff8755fee8610 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 303901] Restart album when using random album
https://bugs.kde.org/show_bug.cgi?id=303901 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED Version Fixed In||21.04 Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/6aef3be86 ||82d829f07ab86901ceff8755fee ||8610 --- Comment #4 from Michael Pyne --- Git commit 6aef3be8682d829f07ab86901ceff8755fee8610 by Michael Pyne. Committed on 23/03/2021 at 02:59. Pushed by mpyne into branch 'master'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 336637, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +0-1juk.cpp M +2-21 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +14 -18 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/6aef3be8682d829f07ab86901ceff8755fee8610 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 417551] Juk ignores the queue if a file gets dragged there
https://bugs.kde.org/show_bug.cgi?id=417551 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/6aef3be86 ||82d829f07ab86901ceff8755fee ||8610 Resolution|--- |FIXED Status|REPORTED|RESOLVED Version Fixed In||21.04 --- Comment #1 from Michael Pyne --- Git commit 6aef3be8682d829f07ab86901ceff8755fee8610 by Michael Pyne. Committed on 23/03/2021 at 02:59. Pushed by mpyne into branch 'master'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 303901, bug 336637, bug 353259, bug 404157 FIXED-IN:21.04 M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +0-1juk.cpp M +2-21 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +14 -18 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/6aef3be8682d829f07ab86901ceff8755fee8610 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 404157] Track length is not updated when advancing in the playlist
https://bugs.kde.org/show_bug.cgi?id=404157 Michael Pyne changed: What|Removed |Added Version Fixed In||21.04 Resolution|--- |FIXED Status|REPORTED|RESOLVED Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/6aef3be86 ||82d829f07ab86901ceff8755fee ||8610 --- Comment #1 from Michael Pyne --- Git commit 6aef3be8682d829f07ab86901ceff8755fee8610 by Michael Pyne. Committed on 23/03/2021 at 02:59. Pushed by mpyne into branch 'master'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 303901, bug 336637, bug 353259, bug 417551 FIXED-IN:21.04 M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +0-1juk.cpp M +2-21 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +14 -18 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/6aef3be8682d829f07ab86901ceff8755fee8610 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 353259] Juk player will not play tracks added to play queue
https://bugs.kde.org/show_bug.cgi?id=353259 Michael Pyne changed: What|Removed |Added Version Fixed In||21.04 Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/6aef3be86 ||82d829f07ab86901ceff8755fee ||8610 Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Michael Pyne --- Git commit 6aef3be8682d829f07ab86901ceff8755fee8610 by Michael Pyne. Committed on 23/03/2021 at 02:59. Pushed by mpyne into branch 'master'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 303901, bug 336637, bug 404157, bug 417551 FIXED-IN:21.04 M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +0-1juk.cpp M +2-21 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +14 -18 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/6aef3be8682d829f07ab86901ceff8755fee8610 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 100356] double-click to play item only works, till play-queue was used
https://bugs.kde.org/show_bug.cgi?id=100356 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/6aef3be86 ||82d829f07ab86901ceff8755fee ||8610 Status|CONFIRMED |RESOLVED Version Fixed In||21.04 Resolution|--- |FIXED --- Comment #6 from Michael Pyne --- Git commit 6aef3be8682d829f07ab86901ceff8755fee8610 by Michael Pyne. Committed on 23/03/2021 at 02:59. Pushed by mpyne into branch 'master'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 166711, bug 302250, bug 303901, bug 336637, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +0-1juk.cpp M +2-21 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +14 -18 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/6aef3be8682d829f07ab86901ceff8755fee8610 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 302250] juk album random play does not play album
https://bugs.kde.org/show_bug.cgi?id=302250 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/6aef3be86 ||82d829f07ab86901ceff8755fee ||8610 Status|CONFIRMED |RESOLVED Version Fixed In||21.04 Resolution|--- |FIXED --- Comment #4 from Michael Pyne --- Git commit 6aef3be8682d829f07ab86901ceff8755fee8610 by Michael Pyne. Committed on 23/03/2021 at 02:59. Pushed by mpyne into branch 'master'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 303901, bug 336637, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +0-1juk.cpp M +2-21 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +14 -18 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/6aef3be8682d829f07ab86901ceff8755fee8610 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 336637] After playing queued items, juk returns to "collection" not previous playlist
https://bugs.kde.org/show_bug.cgi?id=336637 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/6aef3be86 ||82d829f07ab86901ceff8755fee ||8610 Resolution|--- |FIXED Version Fixed In||21.04 --- Comment #3 from Michael Pyne --- Git commit 6aef3be8682d829f07ab86901ceff8755fee8610 by Michael Pyne. Committed on 23/03/2021 at 02:59. Pushed by mpyne into branch 'master'. Improve track sequencing by removing the track sequencing classes. This removes one of my first contributions to JuK :( But it's worth it because the extra code is not worth the complexity, seeing as how the job is really pretty simple in the first place, even with album random play and randomized playback. I believe this also fixes some bugs, including some longstanding ones. Bug 417551 (being unable to drag and drop into Play Queue) had some related work in a recent commit but was still broken until now. Related: bug 100356, bug 166711, bug 302250, bug 303901, bug 353259, bug 404157, bug 417551 FIXED-IN:21.04 M +0-2CMakeLists.txt M +7-20 dynamicplaylist.cpp M +2-0dynamicplaylist.h M +0-1juk.cpp M +2-21 playermanager.cpp M +0-1playermanager.h M +62 -51 playlist.cpp M +14 -1playlist.h M +14 -18 playlistbox.cpp M +3-1playlistbox.h M +2-4playlistcollection.cpp M +4-0playlistcollection.h M +11 -0playlistitem.cpp M +1-0playlistitem.h M +0-2playlistsplitter.cpp D +0-316 tracksequenceiterator.cpp D +0-233 tracksequenceiterator.h D +0-182 tracksequencemanager.cpp D +0-187 tracksequencemanager.h M +36 -166 upcomingplaylist.cpp M +11 -133 upcomingplaylist.h https://invent.kde.org/multimedia/juk/commit/6aef3be8682d829f07ab86901ceff8755fee8610 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 276753] Time Slider freezes some times
https://bugs.kde.org/show_bug.cgi?id=276753 Michael Pyne changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #3 from Michael Pyne --- No response from submitter. But in any event I've never been able to reproduce, and I've recently significantly restructured the playback code in a way that I think is pretty solid (I had encountered bugs in the time slider being wrong, which I've fixed, which did not match the reported behavior here but may have been related). -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 243105] No playback possible
https://bugs.kde.org/show_bug.cgi?id=243105 Michael Pyne changed: What|Removed |Added Resolution|--- |WORKSFORME Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 413065] Untranslatable file dialog filter "Playlists"
https://bugs.kde.org/show_bug.cgi?id=413065 Michael Pyne changed: What|Removed |Added Version Fixed In||21.04 Latest Commit||https://invent.kde.org/mult ||imedia/juk/commit/14731917b ||abaa45afca49c24965401354066 ||212b Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Michael Pyne --- Git commit 14731917babaa45afca49c24965401354066212b by Michael Pyne. Committed on 21/03/2021 at 18:33. Pushed by mpyne into branch 'master'. mediafiles: Make Playlist Save As file type message translatable. Sorry for missing this for so long. :( FIXED-IN:21.04 M +1-1mediafiles.cpp https://invent.kde.org/multimedia/juk/commit/14731917babaa45afca49c24965401354066212b -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 165899] juk take to much CPU / Power when IDLE
https://bugs.kde.org/show_bug.cgi?id=165899 --- Comment #4 from Michael Pyne --- Git commit 62561ad031a2c1c03f9abc266c621d83e48f6b8b by Michael Pyne. Committed on 21/03/2021 at 18:19. Pushed by mpyne into branch 'master'. systemtray: Cleanups and modernization. Also a timer bugfix. The bug: When using the track popup announcement, a timer kicks off to tell the popup to fade out. A second timer is used to incrementally fade the popup a bit every few milliseconds until the popup can finally be hidden. However the first timer was never stopped, and would kick off the fadeout sequence again, over and over, only hidden to view since the popup is no longer visible. This might be related to the old bug 165899 (which I tried to fix a different way). I believe this happened in the Qt3/4 transition since the code seems to assume the first timer was a "single shot" timer, but it could have been wrong forever. M +80 -84 systemtray.cpp M +12 -14 systemtray.h https://invent.kde.org/multimedia/juk/commit/62561ad031a2c1c03f9abc266c621d83e48f6b8b -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcoreaddons] [Bug 387663] Dolphin doesn't update view (doesn't show new files)
https://bugs.kde.org/show_bug.cgi?id=387663 --- Comment #30 from Michael Pyne --- NFS might be a different thing. But I have a merge request open for the potential inotify bug, at https://invent.kde.org/frameworks/kcoreaddons/-/merge_requests/81 if anyone who can reproduce the bug is able to take a look at testing. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcoreaddons] [Bug 433402] KJobsTest in test suite flags undefined behavior sanitizer
https://bugs.kde.org/show_bug.cgi?id=433402 Michael Pyne changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/fram ||eworks/kcoreaddons/commit/c ||1f6b6f437cb6764875e1bf67cb8 ||59f10adcb4d7 --- Comment #2 from Michael Pyne --- Git commit c1f6b6f437cb6764875e1bf67cb859f10adcb4d7 by Michael Pyne. Committed on 23/02/2021 at 00:43. Pushed by mpyne into branch 'master'. autotests: Fix autotests to pass under gcc ubsan and leak sanitizer. The GCC undefined behavior sanitizer (ubsan) flags our deliberate usage of undefined behavior within the KJob autotests, and the leak sanitizer flags some memory leaks from the use of KAutoSaveFile. It would be good to be able to consistently run the autotests under the use of compiler sanitizers to catch bugs in kcoreaddons libraries, but this relies on the code still passing the test suite in this case. It appears to me that the use of undefined behavior in KJobTest is as a simple sanity check that KJob::isFinished is consistent with the fact that we just called a slot connected to `KJob::finished()`. But `KJob::isFinished()` is a protected method and in the context of a `KJob::finished()` signal emitted from `KJob::~KJob()` there can be no subclasses to interrogate `KJob::isFinished()` anyways. I try to go about the sanity check instead by counting specific number of `finished` calls from each individual job, ensuring that no job ever emits `finished` more than once, that the corresponding `slotResult` call (on success) comes after one (and only one) `finished` signal for the job, and that the number of KJob test that emit `finished` but do not emit `result` is exactly equal to the number of expected failed jobs It might be simpler just to use `qobject_cast` or `dynamic_cast` and only perform the sanity check when we know the `finished` call is happening from a subclass. For KAutoSaveFile, it's just a matter of remembering to call delete on the list of returned KAutoSaveFile* objects. This is worth fixing just because autotests are sometimes treated as documentation on proper usage, but I also make sure to clarify in the API documentation (the code examples in the API docs show correct usage but the per-method documentation does not make clear that the application owns the returned pointers). M +9-3autotests/kautosavefiletest.cpp M +16 -8autotests/kjobtest.cpp M +2-0autotests/kjobtest.h M +10 -0src/lib/io/kautosavefile.h https://invent.kde.org/frameworks/kcoreaddons/commit/c1f6b6f437cb6764875e1bf67cb859f10adcb4d7 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcoreaddons] [Bug 433402] New: KJobsTest in test suite flags undefined behavior sanitizer
https://bugs.kde.org/show_bug.cgi?id=433402 Bug ID: 433402 Summary: KJobsTest in test suite flags undefined behavior sanitizer Product: frameworks-kcoreaddons Version: 5.79.0 Platform: Compiled Sources OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: mp...@kde.org Reporter: mp...@kde.org CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY The autotest "kjobtest" causes errors and warning messages about use of undefined behavior. This makes it problematic to run the test suite under aggressive compiler sanitizing because it will then be expected to fail, which reduces the viability of using sanitizers to catch bugs. STEPS TO REPRODUCE 1. Ensure that kcoreaddons is configured to build autotests by CMake. 2. Compile kcoreaddons with Address Sanitizer (asan) and Undefined Behavior Sanitizer (ubsan). I used in my kdesrc-buildrc: options kcoreaddons cmake-options -DBUILD_TESTING:BOOL=ON cxxflags -fsanitize=address -fsanitize=undefined -ggdb end options ***NOTE*** if you do this only for kcoreaddons and install the result, your other Qt/KDE applications may fail to launch. I believe this is due to something about the Qt platform plugin because running something like "XDG_CURRENT_DESKTOP=GNOME assistant" succeeds in this case when just running "assistant" would not. 2. Go to kcoreaddons build directory and run ./bin/kjobtest OBSERVED RESULT user@domain /kdesrc/build/kf5/frameworks/kcoreaddons $ ./bin/kjobtest * Start testing of KJobTest * Config: Using QtTest library 5.15.1, Qt 5.15.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 10.2.0), gentoo unknown PASS : KJobTest::initTestCase() PASS : KJobTest::testEmitResult(no error) PASS : KJobTest::testEmitResult(error no text) PASS : KJobTest::testEmitResult(error with text) PASS : KJobTest::testProgressTracking() PASS : KJobTest::testExec(no error) PASS : KJobTest::testExec(error no text) PASS : KJobTest::testExec(error with text) PASS : KJobTest::testKill(killed with result) PASS : KJobTest::testKill(killed quietly) /kdesrc/src/kf5/frameworks/kcoreaddons/autotests/kjobtest.cpp:439:5: runtime error: downcast of address 0x60303be0 which does not point to an object of type 'TestJob' 0x60303be0: note: object is of type 'KJob' 02 00 00 45 b8 a2 71 5f 1c 7f 00 00 20 24 00 00 80 60 00 00 a0 24 00 00 80 60 00 00 00 00 00 00 ^~~ vptr for 'KJob' PASS : KJobTest::testDestroy() PASS : KJobTest::testEmitAtMostOnce(Start-Start-autoDelete) PASS : KJobTest::testEmitAtMostOnce(Start-KillQuietly-autoDelete) PASS : KJobTest::testEmitAtMostOnce(Start-KillVerbosely-autoDelete) PASS : KJobTest::testEmitAtMostOnce(KillQuietly-Start-autoDelete) PASS : KJobTest::testEmitAtMostOnce(KillQuietly-KillQuietly-autoDelete) PASS : KJobTest::testEmitAtMostOnce(KillQuietly-KillVerbosely-autoDelete) PASS : KJobTest::testEmitAtMostOnce(KillVerbosely-Start-autoDelete) PASS : KJobTest::testEmitAtMostOnce(KillVerbosely-KillQuietly-autoDelete) PASS : KJobTest::testEmitAtMostOnce(KillVerbosely-KillVerbosely-autoDelete) PASS : KJobTest::testEmitAtMostOnce(Start-Start) PASS : KJobTest::testEmitAtMostOnce(Start-KillQuietly) PASS : KJobTest::testEmitAtMostOnce(Start-KillVerbosely) PASS : KJobTest::testEmitAtMostOnce(KillQuietly-Start) PASS : KJobTest::testEmitAtMostOnce(KillQuietly-KillQuietly) PASS : KJobTest::testEmitAtMostOnce(KillQuietly-KillVerbosely) PASS : KJobTest::testEmitAtMostOnce(KillVerbosely-Start) PASS : KJobTest::testEmitAtMostOnce(KillVerbosely-KillQuietly) PASS : KJobTest::testEmitAtMostOnce(KillVerbosely-KillVerbosely) PASS : KJobTest::testDelegateUsage() PASS : KJobTest::testNestedExec() PASS : KJobTest::cleanupTestCase() Totals: 32 passed, 0 failed, 0 skipped, 0 blacklisted, 302ms * Finished testing of KJobTest * = ==131922==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16 byte(s) in 2 object(s) allocated from: #0 0x7f1c60269b48 in __interceptor_realloc /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/gcc-10.2.0/libsanitizer/asan/asan_malloc_linux.cpp:164 #1 0x7f1c5e0d5f42 in d_growable_string_resize /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4036 #2 0x7f1c5e0d5f42 in d_growable_string_append_buffer /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4060 #3 0x7f1c5e0d5f42 in d_growable_string_callback_adapter /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4077 SUMMARY: AddressSanitizer: 16 byte(s) leaked in 2
[frameworks-kcoreaddons] [Bug 410851] K_PLUGIN_FACTORY_DECLARATION_WITH_BASEFACTORY_SKEL doesn't use basefactory
https://bugs.kde.org/show_bug.cgi?id=410851 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/fram ||eworks/kcoreaddons/commit/d ||aec110942baed6c7e8bcb7684e6 ||5411fe8acbe8 Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Michael Pyne --- Git commit daec110942baed6c7e8bcb7684e65411fe8acbe8 by Michael Pyne, on behalf of Adriaan de Groot. Committed on 19/02/2021 at 02:29. Pushed by mpyne into branch 'master'. kpluginfactory: Use the user-provided base factory in our factory macro. The existing macro always inherits from KPluginFactory -- making it hard to use when sub-classing KPluginFactory in order to extend it. The parameter baseFactory to the macro isn't used. Use baseFactory as the base class for the plugin. -- Commentary by committer: This closes out merge request !1. Due to the length of time between when the MR was authored and when we could finally land it, this also includes other commits added as part of the MR to: * Use @-style Doxygen comments consistently * Adapt other Doxygen API documentation to our style guide * Some other miscellaneous editorial improvements On top of those changes, I have ensured that the other changes to this header made in the meantime now conform to the consistent API documentation (i.e. other \ to @ conversions), and to update the @since version to be accurate again. M +148 -117 src/lib/plugin/kpluginfactory.h https://invent.kde.org/frameworks/kcoreaddons/commit/daec110942baed6c7e8bcb7684e65411fe8acbe8 -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 420933] kdesrc-build fails to update modules randomly (git stash failure)
https://bugs.kde.org/show_bug.cgi?id=420933 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/sdk/ ||kdesrc-build/commit/c4ad3db ||b9038f9e0339f898a75fa48ce4f ||dc9cea Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Michael Pyne --- Git commit c4ad3dbb9038f9e0339f898a75fa48ce4fdc9cea by Michael Pyne. Committed on 11/10/2020 at 22:36. Pushed by mpyne into branch 'master'. git: Automatically reapply stashed changes if possible. In the event that the stash does not apply a "post-build" message is issued to warn the user. Otherwise there is an in-situ message. This addresses user feedback I have received on Invent and IRC. In particular re-fixes #42 and bug 420933, and fixes #49. All that I do here is to use the existing logic and add "git stash pop" after the update phase has completed. I've previously tried --autostash (see !32 and !45) and that had issues of its own. Using this approach allows us to use rely on git directly without risk of missing a merge conflict that git sometimes seems to generate with `git pull --autostash` (see https://invent.kde.org/sdk/kdesrc-build/-/merge_requests/32#note_46926). The merge request !61 may still be applicable. I haven't looked long enough to tell if there's more on it than the --autostash feature which still causes us problems... it's possible that there's a more reliable method than what we're doing though we've already taken pains to simplify this routine because of the recurring stash failures that we've seen previously. M +18 -7modules/ksb/Updater/Git.pm https://invent.kde.org/sdk/kdesrc-build/commit/c4ad3dbb9038f9e0339f898a75fa48ce4fdc9cea -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 426219] Add a way to disable installing udev rule
https://bugs.kde.org/show_bug.cgi?id=426219 --- Comment #5 from Michael Pyne --- Git commit 2317c3a32e5aee1e926bd912275fd2149757f69a by Michael Pyne. Committed on 27/09/2020 at 19:15. Pushed by mpyne into branch 'master'. setup: Make include-dependencies optional, show module groups not chosen. My hope is to make it easier for new users to understand how to add module groups if they are desired later, since there has previously been no generated note or warning in the generated kdesrc-buildrc if the user chose no major groups. In this case we had a user who, even though they didn't select any module groups, still had kdesrc-build trying to build bluez-qt due to include-dependencies being set to 'true' (the default). However bluez-qt needs a CMake option to be passed to build with kdesrc-build; this option isn't set unless the kf5-frameworks-build-include file is read in. That fix will happen in a separate commit, this should hopefully make it easier to read through the generated kdesrc-buildrc in any case. M +74 -39 kdesrc-build-setup https://invent.kde.org/sdk/kdesrc-build/commit/2317c3a32e5aee1e926bd912275fd2149757f69a -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 426219] Add a way to disable installing udev rule
https://bugs.kde.org/show_bug.cgi?id=426219 --- Comment #6 from Michael Pyne --- Git commit ed1545b71654c7e9dc3f3ca65e0c29ef1f6d92c5 by Michael Pyne. Committed on 27/09/2020 at 19:52. Pushed by mpyne into branch 'master'. setup: Break out common 'options' blocks for kdesrc-build-setup to always use. This change should address the immediate breakage that a user had when using kdesrc-build-setup, choosing no major module groups, and then using kdesrc-build to eventually build bluez-qt. In that case, bluez-qt had an 'options' block in kf5-frameworks-build-include to address the error he'd experienced, however since kdesrc-build-setup didn't generate a include to that file, the options weren't picked up either. kdesrc-build later found the module via include-dependencies and built it anyways. To fix this, break out "always-set" options into a dedicated file (kf5-common-options-build-include) and include that from kdesrc-build-setup-generated files always. I moved these from kf5-frameworks-build-include so I added an include from that file back to kf5-common-options-build-include for backwards compatibility for existing users. This relies on duplicate options blocks continuing to work (similar to C++'s One Definition Rule) so I've documented that in the code for now. M +1-0CMakeLists.txt M +10 -5kdesrc-build-setup A +19 -0kf5-common-options-build-include M +4-15 kf5-frameworks-build-include M +2-0kf5-qt5-build-include M +2-0kf5-workspace-build-include M +5-0modules/ksb/Application.pm M +6-1modules/ksb/FirstRun.pm https://invent.kde.org/sdk/kdesrc-build/commit/ed1545b71654c7e9dc3f3ca65e0c29ef1f6d92c5 -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 426219] Add a way to disable installing udev rule
https://bugs.kde.org/show_bug.cgi?id=426219 --- Comment #2 from Michael Pyne --- As of commit cbf96256, the suggested CMake option is already passed to bluez-qt. Someone else has reported this as a bug on IRC. Could I ask how kdesrc-build was installed (cloned from git or distribution packages) and how the kdesrc-build configuration was generated (kdesrc-build-setup, modification of the sample configuration, kdesrc-build --initial-setup, something else)? -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 420718] juk segfaut on every startup
https://bugs.kde.org/show_bug.cgi?id=420718 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Version Fixed In||20.04.1 Status|REPORTED|RESOLVED Latest Commit||https://invent.kde.org/kde/ ||juk/commit/e843f457d5656d77 ||8396d8045289117443b70975 --- Comment #5 from Michael Pyne --- Git commit e843f457d5656d778396d8045289117443b70975 by Michael Pyne. Committed on 10/05/2020 at 15:52. Pushed by mpyne into branch 'master'. playlist: Fix crasher with playlists using reserved columns. I introduced this bug in commit a800c1b3ffeb trying to fix a different memory mis-using bug. Sigh. In this case playlists that reserve additional columns would get a valid memory assignment but would be copied into the memory block incorrectly. This needed a back_inserter as well. Thanks to Markus for pointing out the regression, then opening a bug, then leaving a comment to point out both of these, and then drafting a patch that fixes the bug. I can confirm it works in my testing, it also seems to address a bug relating to playback stopping abrupting at the end of a track instead of skipping to the next track, but who knows at this point. FIXED-IN:20.04.1 M +1-1playlist.cpp https://invent.kde.org/kde/juk/commit/e843f457d5656d778396d8045289117443b70975 -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 420933] kdesrc-build fails to update modules randomly (git stash failure)
https://bugs.kde.org/show_bug.cgi?id=420933 --- Comment #2 from Michael Pyne --- Git commit 5019317f41977d67f1932cacb68850bda83ec73b by Michael Pyne. Committed on 02/05/2020 at 23:21. Pushed by mpyne into branch 'master'. git: Capture basic git-status info before error-prone ops. There have long been bug reports around git-stash handling. I just had to enter another one, but it's hard to troubleshoot what git was seeing after the fetch and rebase has already happened, even if you try to rewind with reflog. For now this will just run a simple 'git-status' as a smoke check before the update, and optionally if a stash or error occur. My hope is this will permit more detail to be provided with subsequent bug reports. M +6-0modules/ksb/Updater/Git.pm https://invent.kde.org/kde/kdesrc-build/commit/5019317f41977d67f1932cacb68850bda83ec73b -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 420933] kdesrc-build fails to update modules randomly (git stash failure)
https://bugs.kde.org/show_bug.cgi?id=420933 Michael Pyne changed: What|Removed |Added CC||fa...@kde.org --- Comment #1 from Michael Pyne --- David, I'm not able to immediately resolve so entering a bug. I will update kdesrc-build to include 'git-status' output before update and stash operations to potentially improve on the error reporting available. I suspect something to do with long periods of changes between updates. For clarity in case you look yourself, the basic sequence kdesrc-build for updates to existing modules is: cd $srcdir git fetch --tags $remote DO_STASH = git diff-index --quiet HEAD != 0 if DO_STASH: git stash save --quiet git checkout $branch ; unconditionally done git rebase origin/$branch if DO_STASH: git stash pop -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 420933] New: kdesrc-build fails to update modules randomly (git stash failure)
https://bugs.kde.org/show_bug.cgi?id=420933
Bug ID: 420933
Summary: kdesrc-build fails to update modules randomly (git
stash failure)
Product: kdesrc-build
Version: Git
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: mp...@kde.org
Reporter: mp...@kde.org
Target Milestone: ---
Created attachment 128105
--> https://bugs.kde.org/attachment.cgi?id=128105=edit
kdesrc-build logs from my failed kactivitymanagerd run
SUMMARY
dfaure reports that kdesrc-build can consider a module failed to update (even
though it successfully fetches updates from the git server and successfully
rebases the module to the updated 'master' branch). It complains about being
unable to restore stashed local changes. See
https://invent.kde.org/snippets/868. The pertinent error:
user@localhost:~/release-tools$ cd ../src && ./kdesrc-build --src-only
Updating kde-build-metadata (to branch master)
Local changes detected, stashing them away...
Module updated, reapplying your local changes.
*
* Unable to re-apply stashed changes to kde-build-metadata!
*
* These changes were saved using the name "kdesrc-build auto-stash at
2020-05-02-21:48"
* and should still be available using the name stash@{0}, the command run
* to re-apply was git stash pop --index. Resolve this before you run
* kdesrc-build to update this module again.
*
* If you do not desire to keep your local changes, then you can generally
run
* git reset --hard HEAD, or simply delete the source directory for
* kde-build-metadata. Developers be careful, doing either of these options
will remove
* any of your local work.
* Unable to download required metadata for build process
* Will attempt to press onward...
* Exception message: Runtime Error: Failed to re-apply stashed changes for
kde-build-metadata
STEPS TO REPRODUCE
1. Change to desired config directory
2. Run kdesrc-build --src-only
OBSERVED RESULT
Modules randomly fail to update complaining of re-application of stashed
changes. Different modules fail on subsequent builds.
[18:17] thanks
[18:17] it seems like ot happened randomly in various repos
[18:17] it
[18:17] git version 2.26.1, if it matters
[18:33] mpyne happened twice in a row upon "kdesrc-build frameworks",
but on different modules every time
[18:34] thanks
[18:34] mpyne: once kde-build-metadata, once kio and kdesrc-build
itself... pretty random
In my own testing from an old checkout, applying to master as of 2020-05-02, I
had one module fail for this reason, kactivitymanagerd. I believe this may be
related to a commit that removed a file, but I cannot understand what situation
kactivitymanagerd had been in before that would have led kdesrc-build to think
a local change had occurred. I was not able to reproduce random modules having
this failure.
EXPECTED RESULT
The source code modules cleanly update, since there were no local modifications
to worry about.
SOFTWARE/OS VERSIONS
kdesrc-build: v19.12-44-geaf569d
ADDITIONAL INFORMATION
There have been recent changes to git-stash handling to fix other "fake local
change detected" bugs.
--
You are receiving this mail because:
You are watching all bug changes.
[kdesrc-build] [Bug 420486] Bump Qt5 requirement to match other packages requirements
https://bugs.kde.org/show_bug.cgi?id=420486 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Michael Pyne --- Thanks. This has been applied on git master. See https://invent.kde.org/kde/kdesrc-build/-/merge_requests/28 -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 402511] When using the --stop-on-failure argument, print contents of log file for failed build to the console
https://bugs.kde.org/show_bug.cgi?id=402511 Michael Pyne changed: What|Removed |Added CC||mklape...@kde.org --- Comment #4 from Michael Pyne --- *** Bug 331203 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 331203] Display error in 'less' after build set finishes
https://bugs.kde.org/show_bug.cgi?id=331203 Michael Pyne changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Michael Pyne --- *** This bug has been marked as a duplicate of bug 402511 *** -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 411419] kdesrc-build dolphin --include-dependencies fails with gpgme
https://bugs.kde.org/show_bug.cgi?id=411419 --- Comment #5 from Michael Pyne --- I've updated the Qt branch that is built by default to 5.13 now (for bug 410921). I've also reduced a bit of the error message spam you get for the first major failing module, libdbusmenu-qt. Unfortunately I've not been able to reproduce the libdbusmenu-qt failure myself. Someone else has reported a very similar bug (bug 413031). As your StackOverflow question mentioned, you may have to remove build directories (can be done using the --refresh-build flag to kdesrc-build) after you make potential fixes. You might also use the --stop-on-failure flag until things get stable on your system, that will stop the entire build if a single module fails to avoid wasting time trying to build modules where the dependencies didn't make it through. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 410921] Respect XDG Base Directory Specification.
https://bugs.kde.org/show_bug.cgi?id=410921 --- Comment #1 from Michael Pyne --- For those who come across this bug, a merge request that would fix this is at https://invent.kde.org/kde/kdesrc-build/merge_requests/11 -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 410915] Arch Partial Upgrade
https://bugs.kde.org/show_bug.cgi?id=410915 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||673ef32a28e79c6325ed24e4f65 ||84ea7deab0b49 Status|CONFIRMED |RESOLVED --- Comment #3 from Michael Pyne --- The improved command referenced in the Phabricator change request was merged to fix this bug back in August. Not sure why I missed this bug report in the meantime but this has been already fixed. Thanks for reporting! -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 412989] Please update Qt to 5.13
https://bugs.kde.org/show_bug.cgi?id=412989 Michael Pyne changed: What|Removed |Added Latest Commit||46e06a53fd04cd4e322de782aad ||2611b3d1d4600 Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Michael Pyne --- Addressed in commit 46e06a53fd04cd4e322de782aad2611b3d1d4600 I have not been able to get OpenSUSE Leap to build to verify this is all that's needed so expect some residual breakage that may be needed to make Qt 5.13 happy. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 411595] kdesrc-build l10n crashes
https://bugs.kde.org/show_bug.cgi?id=411595 --- Comment #1 from Michael Pyne --- Well, it's supposed to build and install translations but on the other hand I've not used that myself in years and you're the first to mention it one way or the other. It shouldn't be far off as long as the l10n-kde4 stuff hasn't changed much in the meantime. I'm trying to remember why 'snapshots' would have made its way into the module list (what this part of the codebase is complaining about). I remember l10n-kde4 had a '/scripts' directory that had required special handling but I don't remember a 'snapshots' dir... -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 413031] libdbusmenu-qt fails to update with kdesrc-build
https://bugs.kde.org/show_bug.cgi?id=413031 --- Comment #1 from Michael Pyne --- Thanks for including the error.log. I've just tried it with recent kdesrc-build and bzr 2.7.0, and my output was: libdbusmenu-qt/bzr-pull.log === # kdesrc-build running: 'bzr' 'pull' # from directory: /kdesrc/src/kf5/libdbusmenu-qt Using saved parent location: http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu-qt/trunk/ No revisions or tags to pull. If I try forcibly removing the source directory for libdbusmenu-qt before running kdesrc-build, kdesrc-build is able to succeed at checking out libdbusmenu-qt, with output of: libdbusmenu-qt/bzr-branch.log = # kdesrc-build running: 'bzr' 'branch' 'lp:libdbusmenu-qt' '/kdesrc/src/kf5/libdbusmenu-qt' # from directory: /kdesrc/src/kf5/sysadmin/repo-metadata You have not informed bzr of your Launchpad ID, and you must do this to write to Launchpad or access private data. See "bzr help launchpad-login". Branched 271 revisions. Although the process is run from the wrong directory (sysadmin/repo-metadata) the full destination path is still passed to bzr so the operation still succeeds. At this point I would recommend completely deleting the existing source directory and trying again. I think bzr itself is throwing an error and that seems like the fastest potential option to unstick it. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 379464] JuK 3.14 won't remember the "Dock in System Tray" setting
https://bugs.kde.org/show_bug.cgi?id=379464 Michael Pyne changed: What|Removed |Added Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #1 from Michael Pyne --- I remember running into this and I fixed it at some point, but I don't remember the exact commit that did it. If you're still using this could you report back with whether the bug has been fixed or not? -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 353124] Juk ignores folder removal
https://bugs.kde.org/show_bug.cgi?id=353124 --- Comment #2 from Michael Pyne --- To be honest JuK is only poorly maintained, that much is true. We've at least setup JuK so that its Bugzilla versions are added automatically at each major release. As for your bug, saying that removing a music folder doesn't remove its corresponding music from the Collection List, I have to admit that it's working as designed, the feature is meant to guide music scanning on startup, rather than to directly control the contents of the Collection List. But I think it would make sense to work as you describe it, and certainly it isn't easy to identify the files yourself otherwise without using the "Full Path" column and then filtering on it. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 238941] Juk causes excessive IO and CPU load on startup
https://bugs.kde.org/show_bug.cgi?id=238941 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Michael Pyne --- I've been able to reproduce that JuK does take a lot of I/O at start up (because it loads the metadata for all music in its collection, including music that may be present in default music folder paths). I've progressively worked to address the worst bits of that, including by moving the music scanner into a separate thread last year and by fixing a bug causing music to be unnecessarily rescanned after first startup. I think that should address much of what this bug is describing, although I'm sure there's even better that could be done. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 406791] Cant find lyrics no songs anymore.
https://bugs.kde.org/show_bug.cgi?id=406791 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/kde/ ||juk/commit/d161bae4530bc288 ||71c6951939100bf7a7a3b924 Version Fixed In||19.08 Status|REPORTED|RESOLVED --- Comment #3 from Michael Pyne --- Git commit d161bae4530bc28871c6951939100bf7a7a3b924 by Michael Pyne, on behalf of Luigi Toscano. Committed on 04/08/2019 at 21:58. Pushed by mpyne into branch 'Applications/19.08'. Adjust lyrics to use new URLs. This uses TLS to secure the lookup, avoids a required redirect that was impacting the lookup, and pulls out repeated uses of the same URL into a central constant. See !9, which can be closed. FIXED-IN:19.08 M +9-6lyricswidget.cpp https://invent.kde.org/kde/juk/commit/d161bae4530bc28871c6951939100bf7a7a3b924 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 409936] every start asks for "folder where you keep your music"
https://bugs.kde.org/show_bug.cgi?id=409936 Michael Pyne changed: What|Removed |Added Latest Commit||98ce99c2d7502a9eb2f0b96562e ||d68fb0c293276 Resolution|--- |FIXED Status|REPORTED|RESOLVED Version Fixed In||19.08 --- Comment #7 from Michael Pyne --- Guo Yunhe has, I think, fixed the most immediate issue (opening folder list even when folders have been selected), so closing this bug. If there are filename encoding issues I would open it as a separate bug, please. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 315105] kdesrc-build should treat "obvious" dependencies as implicit
https://bugs.kde.org/show_bug.cgi?id=315105 --- Comment #2 from Michael Pyne --- Hi Aasif! We recently had a new contributor add a new dependency resolver to kdesrc-build which also helps set the right conditions for treating non-KDE modules as dependencies. Please see the long thread at https://invent.kde.org/kde/kdesrc-build/merge_requests/6 as a starter. You might also look at https://invent.kde.org/kde/kdesrc-build/tree/master/doc/source-reference which has a little bit of detail on kdesrc-build internals. Depending on your waking hours I'm also sometimes available on Freenode IRC in #kde-devel as the user "mpyne". I'm typically there from 1900-2300 New York time during the work week and somewhat longer on weekends. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 409936] every start asks for "folder where you keep your music"
https://bugs.kde.org/show_bug.cgi?id=409936 --- Comment #6 from Michael Pyne --- Odd. I wonder if maybe it's a filename encoding confusion issue with the encoded playlists? In JuK's case there's two ways playlists are saved: 1) A QDataStream which serializes the internal Playlist* objects to $XDG_DATA_HOME/playlists, which itself refers to PlaylistItem* objects that were serialized in $XDG_DATA_HOME/cache ($XDG_DATA_HOME is normally ~/.local) 2) Optionally, some playlists are also saved as *.m3u files This code is convoluted, slow and probably should be scrapped but I haven't done that yet. But let's just say that it's not by accident that there's a debugging message wondering why an empty filename has been introduced into an import file codepath. I've had that happen to me in testing and could never figure out why in a way that I could eliminate the bug. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 409936] every start asks for "folder where you keep your music"
https://bugs.kde.org/show_bug.cgi?id=409936 --- Comment #1 from Michael Pyne --- So looking through the code, the only way I can see for this to be happening is if the folder you've selected is empty. I would agree that this is still a bug in this case, but is the folder you have selected empty of music? If not I'll have to look at other possibilities. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 409665] kdesrc-build should be able to clone repos from invent.kde.org
https://bugs.kde.org/show_bug.cgi?id=409665 --- Comment #2 from Michael Pyne --- kdesrc-build has also migrated to Gitlab in case you want to report future bugs at https://invent.kde.org/kde/kdesrc-build/issues ;) With all seriousness, as long as the metadata is available in sysadmin/repo-metadata to figure out whether kdesrc-build should source from gitlab or anongit.kde.org then this shouldn't be that hard. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 409659] kdesrc-build points to non-existing wiki page
https://bugs.kde.org/show_bug.cgi?id=409659
Michael Pyne changed:
What|Removed |Added
Latest Commit||https://invent.kde.org/kde/
||kdesrc-build/commit/21afc50
||ed5fa8519277a3b8cb24f9e022e
||d18565
Status|REPORTED|RESOLVED
Version Fixed In||19.08
Resolution|--- |FIXED
--- Comment #1 from Michael Pyne ---
Git commit 21afc50ed5fa8519277a3b8cb24f9e022ed18565 by Michael Pyne.
Committed on 10/07/2019 at 01:00.
Pushed by mpyne into branch 'master'.
buildsystem: Remove link to deleted wiki page.
As David points out, this bit of advice ("see this page for list of
packages for your distro") is probably not that helpful for a user who
has surely run into having to find a single package on their distro
already.
FIXED-IN:19.08
M +1-5modules/ksb/Application.pm
https://invent.kde.org/kde/kdesrc-build/commit/21afc50ed5fa8519277a3b8cb24f9e022ed18565
--
You are receiving this mail because:
You are watching all bug changes.
[kdesrc-build] [Bug 409198] kdesrc-build does not know to which module qca belongs
https://bugs.kde.org/show_bug.cgi?id=409198 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Version Fixed In||19.08 Latest Commit||https://invent.kde.org/kde/ ||kdesrc-build/commit/99c87f4 ||922cd994032405cc2a29d4c603e ||83e210 Status|REPORTED|RESOLVED --- Comment #1 from Michael Pyne --- Git commit 99c87f4922cd994032405cc2a29d4c603e83e210 by Michael Pyne. Committed on 04/07/2019 at 15:51. Pushed by mpyne into branch 'master'. sample-rc: Give the only anon module-set a name. It is optional for module-sets to have names, but it's still a good idea to *have* a name since kdesrc-build will try to provide you information on which module-set a given module is being built from. If no name is present then you'll get an ugly name for the set like "Building qca from ". As long as the user doesn't mind that's fine, but our base configuration should set a higher standard. This was the only anonymous module-set in the current base configuration. Thanks to Laurent for the report. FIXED-IN:19.08 M +1-1kf5-frameworks-build-include https://invent.kde.org/kde/kdesrc-build/commit/99c87f4922cd994032405cc2a29d4c603e83e210 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 408657] m3u playlist are loaded in reversed order
https://bugs.kde.org/show_bug.cgi?id=408657 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Latest Commit||https://invent.kde.org/kde/ ||juk/commit/4c921d333a50f903 ||56ce55dae566be4556abb76e Version Fixed In||19.04.3 --- Comment #1 from Michael Pyne --- Git commit 4c921d333a50f90356ce55dae566be4556abb76e by Michael Pyne. Committed on 23/06/2019 at 21:40. Pushed by mpyne into branch 'Applications/19.04'. m3u: Add M3U tracks to playlist in the order provided in the file. Turns out the return value of createItem was useful, who knew? FIXED-IN:19.04.3 M +3-1playlist.cpp https://invent.kde.org/kde/juk/commit/4c921d333a50f90356ce55dae566be4556abb76e -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 408376] Rename prompt buttons missing or not visible
https://bugs.kde.org/show_bug.cgi?id=408376 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Latest Commit||https://invent.kde.org/kde/ ||juk/commit/f23803e7e0c4c96d ||4b40f68684c602416838b517 Version Fixed In||19.04.3 Status|REPORTED|RESOLVED --- Comment #2 from Michael Pyne --- Git commit f23803e7e0c4c96d4b40f68684c602416838b517 by Michael Pyne. Committed on 23/06/2019 at 21:13. Pushed by mpyne into branch 'Applications/19.04'. renamer: Fix missing accept button in confirm dialog. I messed this up in porting to QDialogButtonBox somehow. FIXED-IN:19.04.3 M +1-1filerenamer.cpp https://invent.kde.org/kde/juk/commit/f23803e7e0c4c96d4b40f68684c602416838b517 -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 392705] Drag and drop does not work: Sorting in play lists and play queue does not work
https://bugs.kde.org/show_bug.cgi?id=392705 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Version Fixed In||19.04.3 Latest Commit||https://invent.kde.org/kde/ ||juk/commit/55a6bd7170e5b2ca ||6e9f826232574f2136a1648a --- Comment #4 from Michael Pyne --- Git commit 55a6bd7170e5b2ca6e9f826232574f2136a1648a by Michael Pyne. Committed on 23/06/2019 at 19:13. Pushed by mpyne into branch 'Applications/19.04'. Fix drag-and-drop of playlist items onto a playlist icon. This allows you to drag music tracks onto a different playlist, by dropping the selected tracks onto the name of a different playlist. There still seem to be other bugs (Dragging items onto play queue doesn't enable play queue automatically; some playlists aren't properly saved for some reason). But those will have to be fixed in other commits. FIXED-IN:19.04.3 M +45 -2playlistbox.cpp M +3-0playlistbox.h https://invent.kde.org/kde/juk/commit/55a6bd7170e5b2ca6e9f826232574f2136a1648a -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 407139] kglobalaccel fails with QDBusObjectPath: invalid path "/component/vlc_bébé_desktop"
https://bugs.kde.org/show_bug.cgi?id=407139
Michael Pyne changed:
What|Removed |Added
CC||mp...@kde.org
--- Comment #3 from Michael Pyne ---
Oddly, KGlobalAccel does appear to have some code in its DBus component handler
to try to clean up paths to conform to DBus requirements. See
src/runtime/component.cpp:203:
QDBusObjectPath Component::dbusPath() const
{
QString dbusPath = _uniqueName;
// Clean up for dbus usage: any non-alphanumeric char should be turned into
'_'
const int len = dbusPath.length();
for ( int i = 0; i < len; ++i )
{
if ( !dbusPath[i].isLetterOrNumber() )
dbusPath[i] = QLatin1Char('_');
}
// QDBusObjectPath could be a little bit easier to handle :-)
return QDBusObjectPath( _registry->dbusPath().path() + "component/" +
dbusPath);
}
The problem seems to be the ".isLetterOrNumber" check, which doesn't actually
strip non-ASCII characters. Since every character in "bébé" is a Unicode
letter, no translation happens here. Added a check that the QChar returned by
dbusPath[i] is actually a latin-1 characters (e.g. with QChar::toLatin1) would
seem to be necessary.
--
You are receiving this mail because:
You are watching all bug changes.
[juk] [Bug 392705] Drag and drop does not work: Sorting in play lists and play queue does not work
https://bugs.kde.org/show_bug.cgi?id=392705 --- Comment #3 from Michael Pyne --- Git commit dc2d9c8e0fe64ff6059b0f5ca927ff338e7eeca4 by Michael Pyne. Committed on 18/05/2019 at 04:27. Pushed by mpyne into branch 'Applications/19.04'. Add 'override' decl to fix compiler warnings, fix drag-and-drop. This should shave off some 1,000+ warnings over the course of a build with GCC 9.1. This only addresses class declarations native to JuK, but Taglib and to a lesser extent Qt5 moc still have (or generate) code that can result in compiler warnings about suggested override declarations. In the process I noticed that an existing drag-and-drop support function (Playlist::decode) is no longer overriding Qt virtual functions, so it has been turned into an auxiliary function to fix existing drag-and-drop bugs from the KF5 port (tested by dropping files from Dolphin into a playlist view). Drag-and-drop from a playlist to another playlist (by dropping on the playlist name) still remains broken for now. FIXED-IN:19.04.2 M +0-5collectionlist.cpp M +10 -10 collectionlist.h M +2-2coverdialog.cpp M +2-2coverinfo.cpp M +1-1deletedialog.h M +1-1directorylist.h M +2-1dynamicplaylist.cpp M +5-5dynamicplaylist.h M +2-2exampleoptions.h M +3-3filehandleproperties.h M +22 -22 filerenamer.h M +1-1filerenamerconfigdlg.h M +1-1filerenameroptions.h M +2-2folderplaylist.h M +5-5historyplaylist.h M +2-2juk-exception.h M +2-2juk.h M +1-3lyricswidget.h M +9-9nowplaying.h M +12 -15 playlist.cpp M +22 -23 playlist.h M +15 -15 playlistbox.h M +8-8playlistcollection.h M +1-1playlistitem.h M +2-2searchplaylist.h M +1-1searchwidget.h M +8-8slider.h M +1-1statuslabel.h M +6-6systemtray.h M +7-7tageditor.cpp M +1-1tageditor.h M +1-1tagguesserconfigdlg.h M +8-8tracksequenceiterator.h M +1-1treeviewitemplaylist.h M +9-9upcomingplaylist.h M +17 -12 viewmode.h M +2-2volumepopupbutton.h https://invent.kde.org/kde/juk/commit/dc2d9c8e0fe64ff6059b0f5ca927ff338e7eeca4 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcoreaddons] [Bug 407271] KAboutData crashes when using git svn with KWallet
https://bugs.kde.org/show_bug.cgi?id=407271 --- Comment #1 from Michael Pyne --- I suspect some kind of race condition during shutdown, where the global-static tries to delete an already-deleted KAboutData in the registry. I'm having trouble reproducing but I also don't have git-svn setup for kwallet. Based on the platform plugin message I've tried various settings of the environment variable QT_QPA_PLATFORM (xcb, minimal, eglfs) but that hasn't helped me reproduce either. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kinit] [Bug 407393] kdeinit5 Signal: Segmentation fault (11)
https://bugs.kde.org/show_bug.cgi?id=407393 Michael Pyne changed: What|Removed |Added CC||mp...@kde.org --- Comment #3 from Michael Pyne --- Seems to be something with the thumbnailer trying to make previews of a media file somewhere. The backtrace points to taglib (a separate library) but I would also think that a thumbnailer crash shouldn't bring down all of kdeinit5. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 406268] telepathy-accounts-signon does not seem to have a build system to use
https://bugs.kde.org/show_bug.cgi?id=406268 --- Comment #3 from Michael Pyne --- Git commit 6385f5e429dd11393b48690a33d67a66edeacfd2 by Michael Pyne. Committed on 04/05/2019 at 20:15. Pushed by mpyne into branch 'master'. Add support for Meson build system. New/updated config file options: * 'configure-flags', reused as the way to pass cmdline options to the meson setup command. * 'ninja-options', a new option to pass cmdline options to the `ninja` command. Note that ninja is mandated by Meson as the underlying build tool. Tested with https://github.com/plibither8/2048.cpp Fixes #27, reviewed in !8. Test suite passes and I continue to be able to build 2048.cpp. I've also validated that ninja-options is passed to ninja when building 2048.cpp, though this was a manual verification. M +1-0CMakeLists.txt M +43 -2doc/index.docbook M +1-0modules/ksb/Application.pm M +2-1modules/ksb/BuildSystem.pm A +71 -0modules/ksb/BuildSystem/Meson.pm M +8-0modules/ksb/Module.pm M +3-2vim/syntax/kdesrc-buildrc.vim https://invent.kde.org/kde/kdesrc-build/commit/6385f5e429dd11393b48690a33d67a66edeacfd2 -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 406722] KUserFeedback is not included in Frameworks group
https://bugs.kde.org/show_bug.cgi?id=406722 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED CC||bcooks...@kde.org Resolution|--- |UPSTREAM --- Comment #2 from Michael Pyne --- Juan, I took a look at sysadmin/repo-metadata and it seems that kuserfeedback is part of extragear/libs. So from that perspective kdesrc-build is doing the right thing. I know there's been a module or two over time that have been developed outside of kde/frameworks while they were getting into shape for KF5, but I'm not aware of any that were deliberately left outside of kde/frameworks/* even while they were meant to be treated as a part of KF5. Ben might know more, I've CC'ed him. But if KUserFeedback is meant to be part of KF5 then I would recommend asking its maintainer to work with kde-frameworks-devel to get the module proposed for and approved for inclusion into KF5, and from there the sysadmins can update sysadmin/repo-metadata. If KUserFeedback is required for kdesrc-build in the meantime, then a module-set config like this would work, and could be made part of the sample and generated configuration files: module-set kf5-frameworks repository kde-projects use-modules frameworks kuserfeedback end module-set However note that kuserfeedback does not presently contain any dependency data within kde-build-metadata, that's another thing that would need to be fixed to work well with kdesrc-build and build.kde.org -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 406722] KUserFeedback is not included in Frameworks group
https://bugs.kde.org/show_bug.cgi?id=406722 --- Comment #1 from Michael Pyne --- The metadata used to figure out if KUserFeedback is a framework at all should actually be sysadmin/repo-management. The metadata used to find dependencies for KUserFeedback would be in kde-build-metadata. (Long story) I'll look into this, if those metadata sets are inconsistent it wouldn't surprise me if it causes issues elsewhere. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 406268] telepathy-accounts-signon does not seem to have a build system to use
https://bugs.kde.org/show_bug.cgi?id=406268 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |MOVED --- Comment #2 from Michael Pyne --- Thanks for the report. Seems we (finally) need to support Meson in kdesrc-build. I've added an entry to the kdesrc-build issue tracker at Gitlab where we can track progress on this. See https://invent.kde.org/kde/kdesrc-build/issues/27 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 404474] kde-frameworks/kio-5.55.0 Gentoo package - src/core/job_p.h:266:44: warning: ‘opType’ is used uninitialized in this function [-Wuninitialized]
https://bugs.kde.org/show_bug.cgi?id=404474 Michael Pyne changed: What|Removed |Added Resolution|--- |FIXED Version Fixed In||5.57 Status|REPORTED|RESOLVED Latest Commit||https://commits.kde.org/kio ||/920d2c4ca7d59695205c1b3675 ||f9a1efa89dd966 --- Comment #5 from Michael Pyne --- Git commit 920d2c4ca7d59695205c1b3675f9a1efa89dd966 by Michael Pyne. Committed on 24/03/2019 at 17:12. Pushed by mpyne into branch 'master'. kjobs: Fix compiler warning for uninit value in SimpleJobPrivate. GCC 8.2 gives a warning about using an uninitialized value in SimpleJobPrivate, in a factory function for SimpleJobs that can also apply relevant JobFlags based on the job's command. The warning is because the compiler is unable to recognize that the 'command' flag is only able to take the three listed values in this codepath. Warning fixed by adding a default case. FIXED-IN: 5.57 Differential Revision: https://phabricator.kde.org/D20008 M +2-0src/core/job_p.h https://commits.kde.org/kio/920d2c4ca7d59695205c1b3675f9a1efa89dd966 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 404474] kde-frameworks/kio-5.55.0 Gentoo package - src/core/job_p.h:266:44: warning: ‘opType’ is used uninitialized in this function [-Wuninitialized]
https://bugs.kde.org/show_bug.cgi?id=404474 Michael Pyne changed: What|Removed |Added CC||mp...@kde.org --- Comment #4 from Michael Pyne --- Potential fix under review at https://phabricator.kde.org/D20008 -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 281509] knotify4 memory leak while recompiling the whole system
https://bugs.kde.org/show_bug.cgi?id=281509 Michael Pyne changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #20 from Michael Pyne --- Good idea Ben, and I've not been able reproduce in the meantime. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 404487] When building Qt 5, global make options are ignored
https://bugs.kde.org/show_bug.cgi?id=404487
--- Comment #2 from Michael Pyne ---
Interesting. I suspect this might be because of a feature I'd added a couple of
years back to filter out global build flags for build systems that weren't
using the CMake ("KDE4") build system, since that was also sometimes causing
problems for people trying to add global make options that worked under CMake's
Makefiles but not in autotools or qmake-descended makefiles.
--
You are receiving this mail because:
You are watching all bug changes.
[kdesrc-build] [Bug 404484] --include-dependencies does not pull in qt5
https://bugs.kde.org/show_bug.cgi?id=404484 --- Comment #3 from Michael Pyne --- It's both metadata and logic, to some extent. Qt5 is inherently a base dependency in the metadata itself, which kdesrc-build ignores and filters out because (at that time) Qt5 was meant to be provided by the base system. I'm really not sure I want to add "all of Qt5" as a mandatory kdesrc-build dependency, though there may be no other easier way to bootstrap the initial setup / "first run" process. But in your case you specifically add qt5-build-include and the script still aborts. This case should be made to work no matter what. I suspect that kdesrc-build is including qt5 in the build list, but not recognizing that qt5 will eventually come up with the missing qmake during the build. The check that fails here is made very early in the run to allow the user to fix without wasting an hour first on a 100+ failed git repo builds. In fact I think you may have already fixed this in your other commit to add Qt's paths to the search for essential build programs. I would avoid adding qt5 as a dependency as you're tracking in D19171 because that is meant for things that *have* to be built by kdesrc-build and/or build.kde.org, and I want to continue to support users who either build their own Qt 5 or use system packages. I'll comment there as well. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 404486] kdesrc-build should consider adjusting PATH to find tools in qtdir
https://bugs.kde.org/show_bug.cgi?id=404486 --- Comment #5 from Michael Pyne --- (In reply to jm.ouwerkerk from comment #4) > I am getting a bit confused about how to track issues here. To me it looks > like we have 3 separate places: > > - bugs.kde.org > - phabricator.kde.org (the kdesrc-build workboard) > - invent.kde.org (the kdesrc-build Gitlab repo/project) > > How are these systems related? Am I still supposed to file bugs on > bugs.kde.org at all, anymore? For kdesrc-build, prefer https://invent.kde.org/ for now. b.k.o will remain and if the gitlab experiment doesn't work out then we'll fall back to b.k.o. I can close down the phab board (or just point it to https://invent.kde.org/). > Also looking at the git remotes, I don't see invent.kde.org there at all so > I also don't see how I am supposed to tag my commit message properly for > Gitlab. You don't have to do anything special to write your commit message for invent.kde.org in most situations, except to say something like "Fixes #4" (where '4' is the issue number that is impacted on the Gitlab instance). If/when the Git commit fixing the bug gets pulled into the gitlab-hosted repository, gitlab will close the matching issue itself. For an example please see https://invent.kde.org/kde/kdesrc-build/commit/0ceb50e9fefbc43c037e7303fa66b0e793987b3c You don't actually need to add gitlab as a remote to develop against it, the gitlab-hosted repo syncs back to anongit like normal. It can be more convenient to do so, however. The gitlab instance should be able to point out which commands to run if you want to add gitlab as a remote to submit a Merge Request, or you can always just add the diff to the issue. And if it's all too annoying, feel free to continue to work here or in phab. -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 402355] Music player crashes after click on title or album of the currently playing song
https://bugs.kde.org/show_bug.cgi?id=402355 Michael Pyne changed: What|Removed |Added Latest Commit||https://invent.kde.org/kde/ ||juk/commit/5c1470d2f7f4b3f8 ||ba73644fbfa2206bc22063dd Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Version Fixed In||18.12.3 --- Comment #4 from Michael Pyne --- Git commit 5c1470d2f7f4b3f8ba73644fbfa2206bc22063dd by Michael Pyne. Committed on 19/02/2019 at 00:34. Pushed by mpyne into branch 'Applications/18.12'. Fix crash in filtering playlist to playing album/artist. This was caused by infinite recursion in trying to grab the list of playlist items while trying to update the list of playlist items, which could be most easily caused by clicking on the artist or album link in the "now playing" bar while playing a song. FIXED-IN:18.12.3 M +2-1playlist.cpp https://invent.kde.org/kde/juk/commit/5c1470d2f7f4b3f8ba73644fbfa2206bc22063dd -- You are receiving this mail because: You are watching all bug changes.
[juk] [Bug 402355] Music player crashes after click on title or album of the currently playing song
https://bugs.kde.org/show_bug.cgi?id=402355 Michael Pyne changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #3 from Michael Pyne --- I've been able to reproduce, but still need to narrow down the bug and come up with a fix. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 404486] kdesrc-build should consider adjusting PATH to find tools in qtdir
https://bugs.kde.org/show_bug.cgi?id=404486 Michael Pyne changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #2 from Michael Pyne --- Can confirm, I had to work through this myself when I added Qt5 build support, and noted it as something that would need to be fixed. See https://invent.kde.org/kde/kdesrc-build/issues/18 I would rather we track this bug up there... maybe resolve as "UPSTREAM" here to make it clear the bug remains valid? To answer your question about closing bugs, though, you can use the BUG:n keyword in your commit message for most KDE repositories to indicate the Bugzilla bug can be closed as fixed. For the repositories participating in the Gitlab pilot at invent.kde.org (like kdesrc-build), you can close their Gitlab issues by just mentioning "Fixes #n" in the commit message somewhere. Last I tried the Gitlab instance can't actually close Bugzilla bugs because the hooks aren't setup for that. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 402901] kdesrc-build --initial-setup reports "* No installer for linux!" when executing the command on Debian 9 stable and Fedora 29
https://bugs.kde.org/show_bug.cgi?id=402901 --- Comment #5 from Michael Pyne --- Current kdesrc-build master should work with Fedora 29 with only one added manual step. Fedora doesn't include any Perl version at all in the base Docker image, not even the broken ones other distros include, so you'll need to run "dnf install perl" manually before "kdesrc-build --initial-setup" would work. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 402901] kdesrc-build --initial-setup reports "* No installer for linux!" when executing the command on Debian 9 stable and Fedora 29
https://bugs.kde.org/show_bug.cgi?id=402901 --- Comment #4 from Michael Pyne --- Right, the Qt would be fine but there is no existing support in kdesrc-build for Fedora package installer and package list until someone adds it. Guess I'll do that too. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 402536] Consider using a condensed folder structure for src and build directories
https://bugs.kde.org/show_bug.cgi?id=402536 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Version Fixed In||19.04 Latest Commit||https://invent.kde.org/kde/ ||kdesrc-build/commit/0ceb50e ||9fefbc43c037e7303fa66b0e793 ||987b3c Resolution|--- |FIXED --- Comment #6 from Michael Pyne --- Git commit 0ceb50e9fefbc43c037e7303fa66b0e793987b3c by Michael Pyne. Committed on 08/02/2019 at 21:07. Pushed by mpyne into branch 'master'. first-run: Ignore kde structure by default. As suggested by Nate. And as he and Gregor point out, this is a safe and easy change to make as it only affects new users who use --initial-setup. Fixes #6 FIXED-IN:19.04 M +2-0modules/ksb/FirstRun.pm https://invent.kde.org/kde/kdesrc-build/commit/0ceb50e9fefbc43c037e7303fa66b0e793987b3c -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 403177] kdesrc-build fails after upgrade to perl 5.26
https://bugs.kde.org/show_bug.cgi?id=403177 Michael Pyne changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Michael Pyne --- Thanks for the report. This particular crash is actually a kdesrc-build fault that shouldn't be related to Perl 5.26. The bug was fixed shortly after it was introduced, please see my comment in bug 403171. You may have to manually update kdesrc-build to obtain the fix, you can do this by changing to the kdesrc-build directory and running "git pull". *** This bug has been marked as a duplicate of bug 403171 *** -- You are receiving this mail because: You are watching all bug changes.
