[digikam] [Bug 466856] New: Face Matching
https://bugs.kde.org/show_bug.cgi?id=466856 Bug ID: 466856 Summary: Face Matching Classification: Applications Product: digikam Version: 7.9.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: major Priority: NOR Component: Faces-Recognition Assignee: digikam-bugs-n...@kde.org Reporter: digi...@myfreedom.com.au Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Matching/naming faces 2. 3. OBSERVED RESULT after naming a face eg Don the app seems to be deliberately preverse! it does ANTHING but show the same (or similar) faces; instead it hides all same/similar faces, and instead show totally different faces! and this makes it actually FAR more difficult and tedious to match & name faces indeed, your app seems to do a REALLY lousy job of matching same or similar faces EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: win10 64 macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466856] Face Matching
https://bugs.kde.org/show_bug.cgi?id=466856 Dec changed: What|Removed |Added CC||digi...@myfreedom.com.au -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466856] Face Matching
https://bugs.kde.org/show_bug.cgi?id=466856 --- Comment #1 from Dec --- to clarify, it is NOT the face RECOGNITion that is t6he problem (if anything it is too 'good': it is the name (Tag) matching that is dysfunctional -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466856] Face Matching
https://bugs.kde.org/show_bug.cgi?id=466856 --- Comment #3 from Dec --- you do not seem to understand what i say or the actual ISSUE as i additionally clarified. face RECOGNITION is NOT the problem: that works exceptionally well it is the TAGGING that is PERVERSE! when you tag a face, it actually 'hides' all the same faces, and ONLY shows OTHER faces: it takes forever to actually find the SAME face again. the matching of the SAME face takes forever (after you have already tagged MULTIPLE!) - when in fact it should be amazingly easy and fast. in fact i have simply given up! it simply takes too long for something that should be very fast. it makes it like 'hide n seek' just perverse. it deliberately makes it as difficult as possible to find other same matches. it is like the algorithm is actually accidentality reversed the results -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466868] New: Basic Questions re Usage
https://bugs.kde.org/show_bug.cgi?id=466868 Bug ID: 466868 Summary: Basic Questions re Usage Classification: Applications Product: digikam Version: 7.9.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: major Priority: NOR Component: Setup-Database Assignee: digikam-bugs-n...@kde.org Reporter: digi...@myfreedom.com.au Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** having now installed and populated db , i now have simple questions that would take me forever to find here or in app ... 1A. can you exclude sub-directories from search? if so, where/how? 1B. can you exclude images/files with a wild card filter, eg *-old 2A. what happens if you move dirs OUTSIDE the root search directory? 2B. what happens if you delete a dir? 3. how do you re-include/rescan all excluded images? 4. now having looked at faces results, which includes many that are almost unrecognizable, it seems to me that the strategy should be to NOT tag all faces that are poorly defined. is that the idea? 5. finally, say the result i want is to arrange faces with all the same face tags into separate Albums. how would you do that? kind regards don -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466943] New: Image Quality Sorter - AI Option Does NOT Exist
https://bugs.kde.org/show_bug.cgi?id=466943 Bug ID: 466943 Summary: Image Quality Sorter - AI Option Does NOT Exist Classification: Applications Product: digikam Version: 7.9.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: major Priority: NOR Component: Setup-Quality Assignee: digikam-bugs-n...@kde.org Reporter: digi...@myfreedom.com.au Target Milestone: --- Created attachment 157042 --> https://bugs.kde.org/attachment.cgi?id=157042&action=edit Image Quality Select Options I see no AI Image Quality option as listed in Manual see attached you seem to allow only ONE attachment all this huge (unnecessary) complexity - and a basic critical function like no of attachments you screw up) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466943] Image Quality Sorter - AI Option Does NOT Exist
https://bugs.kde.org/show_bug.cgi?id=466943 Dec changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Dec --- unbelievable you have all this doco about functions that basically do NOT exist in (even) the latest release -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 466991] New: Remove Duplicates Not Active
https://bugs.kde.org/show_bug.cgi?id=466991 Bug ID: 466991 Summary: Remove Duplicates Not Active Classification: Applications Product: digikam Version: 7.9.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: critical Priority: NOR Component: Maintenance-Similarities Assignee: digikam-bugs-n...@kde.org Reporter: digi...@myfreedom.com.au Target Milestone: --- Created attachment 157074 --> https://bugs.kde.org/attachment.cgi?id=157074&action=edit Remove Dups you have created this MASSIVE software app - but you seem to have NO idea about how to make it easy to understand and use in this case, having run the Find Dups function - which it has successively done - i can find no way to select multiple duplicates or use the Remove Dups function (which is actually greyed out) also i see NO function to AutoSelect Dups, or any AutoSelect options on how to autoselect ... that is a massive FAIL. (there is also a separate niggle that Preview does NOT stay enabled, but has to be manually turned on for each image set) i am pretty much going to give up on this app. it is massive in scope, but impossibly difficult and frustrating to actually use (and btw i have been in IT and app design and Web design for over 20 years) btw, your bug reporting system reminds me a lot of something i used (and redeveloped) a long time ago - Mantis. oh. now i have the prob of only being to upload ONE screenshot/image/attachment instead of all this other dysfunctional bs, you could even get that very basic essential function right and as they would have pointed - no mention of Dups or Removing Dups in the list of functions regards don -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 467091] New: digiKAM will not open any files/album
https://bugs.kde.org/show_bug.cgi?id=467091 Bug ID: 467091 Summary: digiKAM will not open any files/album Classification: Applications Product: digikam Version: 7.9.0 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: critical Priority: NOR Component: Albums-Engine Assignee: digikam-bugs-n...@kde.org Reporter: digi...@myfreedom.com.au Target Milestone: --- Created attachment 157134 --> https://bugs.kde.org/attachment.cgi?id=157134&action=edit Cannot select any folder or album as per attached, DK will now not open any folders or files for existing or new Album as bg, i renamed the root album folder, which it happily finds in DB Migrate and Showfoto (and now we have prob again of only ONE attachment!) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 467091] digiKAM will not open any files/album
https://bugs.kde.org/show_bug.cgi?id=467091 --- Comment #1 from Dec --- Created attachment 157135 --> https://bugs.kde.org/attachment.cgi?id=157135&action=edit Album New think i have found a work-around to add additional attachments. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 478182] New: Stop forcing dependency on KF5Purpose
https://bugs.kde.org/show_bug.cgi?id=478182 Bug ID: 478182 Summary: Stop forcing dependency on KF5Purpose Classification: Applications Product: kdenlive Version: 23.08.3 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Installation Assignee: j...@kdenlive.org Reporter: moog...@gmail.com Target Milestone: --- SUMMARY *** When trying to update my system, I was denied it due to rejecting Wayland. I do not use KDE, I use a different DE that doesn't have Wayland support yet. I tried to edit the ebuild for 23.08.3, but it turns out that depending on KF5Purpose is now mandatory, whether the user wants kdenlive with share support or not. In fact - share support is force enabled. I don't even use share - there is no benefit for me to have this forced upon me. *** STEPS TO REPRODUCE 1. Use an Xorg-only DE. 2. Install kdenlive 23.08.03. OBSERVED RESULT The update will not happen. EXPECTED RESULT Should just install without share support. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux, LXQt (available in About System) KDE Plasma Version: irrelevant KDE Frameworks Version: irrelevant Qt Version: irrelevant ADDITIONAL INFORMATION I feel pretty terrible that my choice in video editing software is suddenly trying to influence my choice in desktop environments, by proxy of forcing dependency on a particular display server. Yeah yeah I know, iT's A pRoToCoL, I heard it a million times. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 478272] New: Because kwin's ebuild does not offer a choice for display protocols (X and Wayland) and instead pulls in both, other packages such as kdenlive can unexpectedly pull in Way
https://bugs.kde.org/show_bug.cgi?id=478272
Bug ID: 478272
Summary: Because kwin's ebuild does not offer a choice for
display protocols (X and Wayland) and instead pulls in
both, other packages such as kdenlive can unexpectedly
pull in Wayland as an indirect dependency
Classification: Applications
Product: kdenlive
Version: 23.08.3
Platform: Gentoo Packages
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Installation
Assignee: j...@kdenlive.org
Reporter: moog...@gmail.com
Target Milestone: ---
SUMMARY
***
I have filed a previous bug which has unfortunately been closed without any
investigation or discussion. I can hardly blame anyone since I might have come
across a little rough.
kdenlive 23.08.3 pulls in, indirectly, Wayland as a dependency which is
something unsuspected.
***
STEPS TO REPRODUCE
1. Have a Wayland-less Gentoo Linux system configured to reject Wayland.
2. Install kdenlive 23.04.3. This should work fine.
3. Update kdenlive to 23.08.3.
OBSERVED RESULT
kdenlive cannot install.
EXPECTED RESULT
kdenlive should install without issues.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Gentoo Linux without Wayland, configured to reject Wayland
(available in About System)
KDE Plasma Version: 5.110
KDE Frameworks Version: 5.110
Qt Version: 5.15.11-r1
ADDITIONAL INFORMATION
I have tracked down why this issue occurs.
Currently, the latest stable package of kdenlive in Gentoo is at version
23.08.3. This version's ebuild is located here:
https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-apps/kdenlive/kdenlive-23.08.3.ebuild
kdenlive pulls in, unconditionally, >=kde-frameworks/purpose-${KFMIN}:5 which
means KF5Purpose for KF5 with minimum version of 5.106.0.
Next, KF5Purpose sits at version 5.112.0 in Gentoo:
https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-frameworks/purpose/purpose-5.112.0.ebuild
>From this file, we can deduce that KF5Purpose pulls in
kde-apps/kaccounts-integration, if USE contains kaccounts. USEFLAGS for this
package are declared in line 15 where it says "IUSE="bluetooth +kaccounts"".
The + in front of kaccounts means that this flag is implicitly enabled unless
explicitly disabled, which is the likely culprit.
After explicitly disabling kaccounts for this package, the situation has been
resolved.
The reason why kaccounts pulls in Wayland indirectly, is because that pulls in
kde-apps/kaccounts-integration, which pulls in kde-plasma/kde-cli-tools-5.27.9,
which pulls in kde-plasma/libkworkspace-5.27.9, which pulls in
kde-plasma/kwin-5.27.9-r1.
According to
https://gitweb.gentoo.org/repo/gentoo.git/tree/kde-plasma/kwin/kwin-5.27.9-r1.ebuild,
this package pulls in Wayland support in several places. In fact, it pulls in
support for both Wayland and Xorg from Mesa.
I think the proper issue here is that kwin does not offer a choice between the
two for the user, exposed via USEFLAGS, so that is why it's unclear at first
glance why Wayland gets pulled in the dependency tree.
Please consider adding USEFLAGS for X and Wayland to kwin, and not make
kaccounts explicitly enabled in kde-frameworks/purpose. That should fix the
issue.
--
You are receiving this mail because:
You are watching all bug changes.
[kdenlive] [Bug 478272] Because kwin's ebuild does not offer a choice for display protocols (X and Wayland) and instead pulls in both, other packages such as kdenlive can unexpectedly pull in Wayland
https://bugs.kde.org/show_bug.cgi?id=478272 --- Comment #2 from Michał Dec --- (In reply to Nicolas Fella from comment #1) > I'd say it's very unlikely that KWin will gain the ability to build without > Wayland support. It's also not necessary to satisfy your situation. Alright, that's understandable. > I'm not sure why kaccounts-integration depends on kde-cli-tools, but the > link in the dependency chain that really should not be there is > kde-cli-tools -> kworkspace > > For Plasma 6/KDE Frameworks 6 things were moved around, so there it is not > an issues any more. > > The relevant line that pulls it in is > https://invent.kde.org/plasma/kde-cli-tools/-/blob/Plasma/5.27/kcmshell/main. > cpp?ref_type=heads#L172, which isn't even really relevant any more. If you > patched that (and the relevant CMake code) out there's no dependency between > kdenlive and kwin any more I didn't need to patch any code to fix this situation. I just added the file /etc/portage/package.use/no-wayland with such content: ``` kde-frameworks/purpose -kaccounts ``` With regards to actual source code of KF components, I think this is up for Gentoo's KDE maintainers to take care of. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 478272] Because kwin's ebuild does not offer a choice for display protocols (X and Wayland) and instead pulls in both, other packages such as kdenlive can unexpectedly pull in Wayland
https://bugs.kde.org/show_bug.cgi?id=478272 --- Comment #4 from Michał Dec --- (In reply to Andreas Sturmlechner from comment #3) > You shouldn't worry about "Wayland" being pulled in at all. I don't want Wayland though. Every time I tried to let it in, there was literally no benefit from doing it at least on LXQt. And when I tried to go back to normal, a lot of random Gtk applications were broken. The way they were broken looked like I was being punished for removing Wayland. I won't tolerate this. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 478272] Because kwin's ebuild does not offer a choice for display protocols (X and Wayland) and instead pulls in both, other packages such as kdenlive can unexpectedly pull in Wayland
https://bugs.kde.org/show_bug.cgi?id=478272 --- Comment #6 from Michał Dec --- (In reply to Andreas Sturmlechner from comment #5) > That's conjecture, without knowing what you did to "let it in". This offtopic discussion you started warrants a separate bug report in Gentoo. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 478272] Because kwin's ebuild does not offer a choice for display protocols (X and Wayland) and instead pulls in both, other packages such as kdenlive can unexpectedly pull in Wayland
https://bugs.kde.org/show_bug.cgi?id=478272 --- Comment #8 from Michał Dec --- (In reply to Andreas Sturmlechner from comment #7) > I'm mostly here because you filed a packaging support question with Gentoo > specific language upstream. Alright, sorry for the rash response. I should have filed a bug in Gentoo for what I've experienced with Wayland. I'm not sure if my experience even holds true in current times, because this was a problem somewhere 3-5 years ago. My bad. The reason why I appear allergic to Wayland is that I've tried a few times, over the span of 2018-2021, to globally enable Wayland in USE and try to use it in a productive manner. I couldn't and LXQt has not supported it at the time, so I did the obvious thing and reverted my course of actions. However, over the passing months since that action, I've noticed that completely unrelated applications, mostly Gtk ones, stopped working. Upon inspection, I've noticed that they don't because they can't find Wayland libraries. When they all were rebuilt after enabling Wayland, but before disabling it, they have been dynamically linking against Wayland libraries without communicating this through USE, which tricked Portage into thinking that upon disabling Wayland globally a rebuild of all those applications is not needed. I had to painstakingly investigate all imports of all installed binaries and libraries to hunt down every package that has decided to go down with the ship in a manner of speaking, and prevent me from using them if I remove Wayland. If I can reproduce this, I will file this bug in Gentoo, because this is a problem with ebuilds not controlling if the source configure stage can pull in Wayland as a dependency if it finds Wayland exists on the system. So, this is the experience that has put me off Wayland. As for the topic of this bug report, I think what Nicolas has proposed thus far is a good solution. I'm on the "default/linux/amd64/17.1" profile and as far as I know, neither X or Wayland are implicitly enabled here, because I had to explicitly enable X in pretty much everything I want to use with a DE, which means not every package that my dependencies can pull. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 Michał Dec changed: What|Removed |Added CC||moog...@gmail.com --- Comment #99 from Michał Dec --- I've just hit this bug and I can't properly work with AVX-512 instruction. I have to scp my entire projects to a machine that doesn't use AVX-512 at glibc level. This is very inconvenient and uncomfortable. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 --- Comment #102 from Michał Dec --- > You can compile with -mno-avx512f Would a minimum viable solution be to apply this only to glibc, and then reboot so that the whole system loads up the new glibc? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 383010] Add support for AVX-512 instructions
https://bugs.kde.org/show_bug.cgi?id=383010 --- Comment #107 from Michał Dec --- (In reply to Mark Wielaard from comment #103) > Normally glibc uses ifuncs which check whether avx512 is available. Since > valgrind doesn't advertise avx512 being available glibc should normally not > use it. Do you know why it does? How is your glibc build? What error do you > see under valgrind? > Do you know why it does? I don't know, that's why I'm asking. From what I understand in my next answer, I should disable multiarch and recompile glibc without AVX-512. But I don't wanna reboot for nothing. I have an AM5 system and I really hate rebooting it, it takes forever. > How is your glibc build? At the time of writing, this is the recipe for building the version of glibc considered stable on amd64: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.39-r6.ebuild?id=9adf7dbf124f3810b77c28a04f7dd7995d238854 The flags I have enabled in my build are pretty common ones: cet multiarch ssp stack-realign > What error do you see under valgrind? ``` vex amd64->IR: unhandled instruction bytes: 0x62 0xD2 0xFD 0x28 0x7C 0xC0 0x48 0x89 0xC6 0x31 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==28914== valgrind: Unrecognised instruction at address 0x484f0cf. ==28914==at 0x484F0CF: memset (vg_replace_strmem.c:1390) ==28914==by 0x4A47F71: memset (string_fortified.h:59) ==28914==by 0x4A47F71: CRYPTO_zalloc (mem.c:224) ==28914==by 0x4A5A220: CRYPTO_THREAD_lock_new (threads_pthread.c:684) ==28914==by 0x4B330FC: do_rand_init (rand_lib.c:51) ==28914==by 0x4B330FC: do_rand_init_ossl_ (rand_lib.c:48) ==28914==by 0x4DE340F: __pthread_once_slow (pthread_once.c:116) ==28914==by 0x4DE3526: pthread_once@@GLIBC_2.34 (pthread_once.c:143) ==28914==by 0x4A5A31C: CRYPTO_THREAD_run_once (threads_pthread.c:786) ==28914==by 0x4B33B4C: RAND_get_rand_method (rand_lib.c:190) ==28914==by 0x4B347DC: RAND_bytes_ex (rand_lib.c:368) ==28914==by 0x10996B: (a function that calls RAND_bytes) (src.c:191) ==28914==by 0x109427: main (src.c:516) ``` I've ran this program through valgrind on a machine that doesn't have AVX-512, and it runs fine. No leaks, not even a single complaint about uninitialized variables being read. -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 387532] Conflicting device IDs cause paired devices to become unpaired
https://bugs.kde.org/show_bug.cgi?id=387532 Damodara Dec Calvin changed: What|Removed |Added CC||calvinsupo...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
