[okular] [Bug 394775] Annotations in the separated XML files
https://bugs.kde.org/show_bug.cgi?id=394775 --- Comment #20 from ederag --- > I'm not clear why you would want the pdf file always non-writable? Because many of these pdf are no longer available, and I don't want any corruption risk. > Perhaps you have simultaneous multiple users viewing and annotating the same > pdf and > you want each user to save their own annotations? That would be a relevant use case, indeed. > If so, I see no way to do that without changing the Okular code. Actually, since there were no reply, I rolled my own take at this, and got a good proof of concept. As in comment #16, it is using sha512, but this time I took some of your ideas such as keeping pristine okular and working with binary deltas (except I used rdiff instead of plain tail). Currently, there are two bash scripts. The first script copies the original file, applies the former delta if it exists, and opens the working copy with the pristine okular. The other bash script, running in the background, monitors the diffs folder; when the working copy is updated (when the user saves the file in okular), the delta is recalculated (within a lock to prevent race conditions). I'm working on the second script to make it a dbus service, with automatic launch. It's a bit like your manager, but much simpler. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 283682] KMail duplicates filtered messages
https://bugs.kde.org/show_bug.cgi?id=283682 --- Comment #229 from ederag --- (In reply to r.kunschke from comment #228) > Is there any workaround or something? Adding this filter helped a lot here: - match all messages - Executed Command: /usr/bin/sleep 1, -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 394775] Annotations in the separated XML files
https://bugs.kde.org/show_bug.cgi?id=394775 --- Comment #18 from ederag --- I have not been able to fix the issues mentioned in comment #16, because the annotation saving into the pdf is deeply entangled with annotation handling in general now. It might be doable, but would be a huge change, and discussions gave little hope that it would be welcome, so I went back to okular-1.2. Hence I'm delighted to see another take. The idea to keep pristine okular, and store/apply the diff (tail) of the annotated files looks clever ! Did I read correctly that the pdf files have to be writable, and thus temporarily modified, which I don't want (I want a pure viewer) ? Are you open to discussions about this ? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 427908] Crash on zoom
https://bugs.kde.org/show_bug.cgi?id=427908 ederag changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #7 from ederag --- I'm back to openSUSE Leap-15.3 which ships 20.04, and do not have time to rig a test setup again, but all the needed information has been given. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 427908] Crash on zoom
https://bugs.kde.org/show_bug.cgi?id=427908 ederag changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 --- Comment #12 from ederag --- (In reply to Oded Arbel from comment #11) > I'm not sure what is the use case for the task bar right click menu [...] It is very nice to remove a window from an activity without bringing it to focus. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 --- Comment #17 from ederag --- Ditching the possibility to put a window to several activities would render activities almost useless at least to me. If delayed operation is acceptable (the settings are applied when the menu is closed), then the OP issue would be solved as well, wouldn't it ? (check new activity, uncheck old one; no need to reopen the menu) So the issue is really more about the menu being closed too early. Reading https://bugs.kde.org/show_bug.cgi?id=438197#c5, The described behavior seems actually good to me: the submenu with the checkboxes stays in place until it is left, either by going to the parent menu if still there, or by clicking outside, or hitting ESC. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 426416] crash after theme change
https://bugs.kde.org/show_bug.cgi?id=426416 --- Comment #3 from ederag --- The "resolved upstream" resolution is surprising. Couldn't systemsettings catch the crash and revert ? -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 426416] crash after theme change
https://bugs.kde.org/show_bug.cgi?id=426416 --- Comment #5 from ederag --- Sure, but since the buggy theme change was made in systemsettings, I expected to be able to revert that change, in systemsettings as well. Or by "upstream" do you mean that there is a general "theme handler" that should catch the crash and allow to revert ? That would be even better of course. (a quick "kde theming development" search did not show that information) -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 427290] New: Imported .ics calendar is named akonadi_ical_resource_* and looks empty
https://bugs.kde.org/show_bug.cgi?id=427290 Bug ID: 427290 Summary: Imported .ics calendar is named akonadi_ical_resource_* and looks empty Product: korganizer Version: 5.15.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: import/export Assignee: kdepim-b...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- Created attachment 132087 --> https://bugs.kde.org/attachment.cgi?id=132087&action=edit ICal file that cannot be imported Imported calendars are not displayed, as if they were empty. STEPS TO REPRODUCE 1. Right click in the calendars list > Add Calendar 2. Select ICal Calendar File 3. Enter the filename of an existing .ics file 4. Enter name 5. OK OBSERVED RESULT A new calendar appears in the list, but - its name is something like akonadi_ical_resource_1 (the actual number increases at each tentative), instead of the name given in step 4. - the event pane stays empty EXPECTED RESULT Correct name. Displayed events. SOFTWARE/OS VERSIONS openSUSE Leap 15.2 + KDE repos (but issue started with the Leap 15.1 to 15.2 upgrade, with shipped kde) KDE Frameworks 5.74.0 Qt 5.15.1 (built against 5.15.1) ADDITIONAL INFORMATION Also reproducible with a brand new user. Stripped down ICal file attached. akonadictl start ... Handler exception when handling command FetchCollections on connection akonadi_ical_resource_1 (0x562d90df2fb0) : Hierarchical RID does not specify an existing collection ... -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 427290] Imported .ics calendar is named akonadi_ical_resource_* and looks empty
https://bugs.kde.org/show_bug.cgi?id=427290 ederag changed: What|Removed |Added Attachment #132087|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 427290] Imported .ics calendar is named akonadi_ical_resource_* and looks empty
https://bugs.kde.org/show_bug.cgi?id=427290 --- Comment #1 from ederag --- Created attachment 132089 --> https://bugs.kde.org/attachment.cgi?id=132089&action=edit ICal file that cannot be imported -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 427290] Imported .ics calendar is named akonadi_ical_resource_* and looks empty
https://bugs.kde.org/show_bug.cgi?id=427290 --- Comment #4 from ederag --- It's close, but there's no "No file selected." error here, even with akonadictl stop akonadictl --verbose start -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 424648] Keep order of activities
https://bugs.kde.org/show_bug.cgi?id=424648 ederag changed: What|Removed |Added CC||ed...@gmx.fr -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 378693] Activities are listed with a black background although wallpaper is set
https://bugs.kde.org/show_bug.cgi?id=378693 ederag changed: What|Removed |Added CC||ed...@gmx.fr -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 ederag changed: What|Removed |Added CC||ed...@gmx.fr --- Comment #2 from ederag --- Agreed with Oded. Previous behavior was good. It is even clearer with 3 activities A, B and C. If one wanted an application on B and C, it was just a matter of checking B and C (and unchecking A). This is incompatible with the OP, but I guess that if the selection popup would stay up (as it used to do), to allow these changes in one go, the concern would vanish. In other words, right now, since only one change can be done at a time, it is normal to expect either only a single activity or all activities), but this would be too limiting. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 387901] Task manager loses windows with multi monitor
https://bugs.kde.org/show_bug.cgi?id=387901 ederag changed: What|Removed |Added CC||ed...@gmx.fr -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 430440] The "Show in Activities" menu does not work as expected
https://bugs.kde.org/show_bug.cgi?id=430440 --- Comment #4 from ederag --- (In reply to Oded Arbel from comment #3) Thanks for the information. Then here is a proposition: Popup with these radiobuttons: - All activities - only A - only B - only C - some And anytime the "some" is clicked, a new window appears, with checkboxes (like the old behavior), visible on all activities (in case the user would like to see if it worked). Advantage: - quick for simple use case (solves the OP concern) - still allows the important use case where a window should appear only on some activities. - no flicker, as this new window is separated from the taskbar. Not as good as seeing and setting checkboxes right away, but better than current state ? -- You are receiving this mail because: You are watching all bug changes.
[kile] [Bug 427908] New: Crash on zoom
https://bugs.kde.org/show_bug.cgi?id=427908 Bug ID: 427908 Summary: Crash on zoom Product: kile Version: 2.9.93 Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: michel.lud...@kdemail.net Reporter: ed...@gmx.fr Target Milestone: --- Application: kile (2.9.93) Qt Version: 5.15.1 Frameworks Version: 5.75.0 Operating System: Linux 5.3.18-lp152.44-default x86_64 Windowing system: X11 Distribution: "openSUSE Leap 15.2" -- Information about the crash: - What I was doing when the application crashed: .tex file opened, preview visible in the right panel. Hit the "Zoom" button (located to the top right). The crash can be reproduced every time. -- Backtrace: Application: Kile (kile), signal: Segmentation fault [New LWP 932] [New LWP 933] [New LWP 934] [New LWP 935] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x7fd8db0076db in __GI___poll (fds=0x7ffd3370de38, nfds=1, timeout=1000) at ../sysdeps/unix/sysv/linux/poll.c:29 29return SYSCALL_CANCEL (poll, fds, nfds, timeout); [Current thread is 1 (Thread 0x7fd8dba46980 (LWP 931))] Thread 5 (Thread 0x7fd8b6df3700 (LWP 935)): #0 0x7fd8d3e2387d in futex_wait_cancelable (private=, expected=0, futex_word=0x562bb640fc04) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x562bb640fbb0, cond=0x562bb640fbd8) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x562bb640fbd8, mutex=0x562bb640fbb0) at pthread_cond_wait.c:655 #3 0x7fd8d46f4d0b in QWaitConditionPrivate::wait (deadline=..., this=0x562bb640fbb0) at thread/qwaitcondition_unix.cpp:146 #4 QWaitCondition::wait (this=this@entry=0x562bb64265b8, mutex=mutex@entry=0x562bb64265b0, deadline=...) at thread/qwaitcondition_unix.cpp:225 #5 0x7fd8db52f47c in KileParser::ParserThread::run (this=0x562bb6426580) at /usr/src/debug/kile-2.9.93-lp152.39.3.x86_64/src/parser/parserthread.cpp:169 #6 0x7fd8d46ee38c in QThreadPrivate::start (arg=0x562bb6426580) at thread/qthread_unix.cpp:329 #7 0x7fd8d3e1d4f9 in start_thread (arg=0x7fd8b6df3700) at pthread_create.c:465 #8 0x7fd8db011fbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 4 (Thread 0x7fd8b75f4700 (LWP 934)): #0 0x7fd8d3e2387d in futex_wait_cancelable (private=, expected=0, futex_word=0x562bb6481550) at ../sysdeps/unix/sysv/linux/futex-internal.h:88 #1 __pthread_cond_wait_common (abstime=0x0, mutex=0x562bb6481500, cond=0x562bb6481528) at pthread_cond_wait.c:502 #2 __pthread_cond_wait (cond=0x562bb6481528, mutex=0x562bb6481500) at pthread_cond_wait.c:655 #3 0x7fd8d46f4d0b in QWaitConditionPrivate::wait (deadline=..., this=0x562bb6481500) at thread/qwaitcondition_unix.cpp:146 #4 QWaitCondition::wait (this=this@entry=0x562bb6426528, mutex=mutex@entry=0x562bb6426520, deadline=...) at thread/qwaitcondition_unix.cpp:225 #5 0x7fd8db52f47c in KileParser::ParserThread::run (this=0x562bb64264f0) at /usr/src/debug/kile-2.9.93-lp152.39.3.x86_64/src/parser/parserthread.cpp:169 #6 0x7fd8d46ee38c in QThreadPrivate::start (arg=0x562bb64264f0) at thread/qthread_unix.cpp:329 #7 0x7fd8d3e1d4f9 in start_thread (arg=0x7fd8b75f4700) at pthread_create.c:465 #8 0x7fd8db011fbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 3 (Thread 0x7fd8b7fff700 (LWP 933)): #0 0x7fd8db0076db in __GI___poll (fds=0x7fd8b00031e0, nfds=1, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29 #1 0x7fd8cbfaa779 in g_main_context_poll (priority=, n_fds=1, fds=0x7fd8b00031e0, timeout=, context=0x7fd8bbd0) at ../glib/gmain.c:4253 #2 g_main_context_iterate (context=context@entry=0x7fd8bbd0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../glib/gmain.c:3949 #3 0x7fd8cbfaa88c in g_main_context_iteration (context=0x7fd8bbd0, may_block=may_block@entry=1) at ../glib/gmain.c:4015 #4 0x7fd8d4946d1b in QEventDispatcherGlib::processEvents (this=0x7fd8bb10, flags=...) at kernel/qeventdispatcher_glib.cpp:425 #5 0x7fd8d48e2dea in QEventLoop::exec (this=this@entry=0x7fd8b7ffec00, flags=..., flags@entry=...) at kernel/qeventloop.cpp:232 #6 0x7fd8d46ece77 in QThread::exec (this=this@entry=0x7fd8d61d1da0 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread.cpp:547 #7 0x7fd8d5f59185 in QDBusConnectionManager::run (this=0x7fd8d61d1da0 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:179 #8 0x7fd8d46ee38c in QThreadPrivate::start (arg=0x7fd8d61d1da0 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:329 #9 0x7fd8d3e1d4f9 in start_thread (arg=0x7fd8b7fff700) at pthread_create.c:465 #10 0x7fd8db011fbf in
[kdesrc-build] [Bug 420630] Unable to find the okular component: The shared library was not found
https://bugs.kde.org/show_bug.cgi?id=420630
--- Comment #5 from ederag ---
The first steps fail here (openSUSE Leap 15.5), on kdesrc-build master
4324ceb ("Revert "Don't build all of extragear and playground by default"",
2023-08-29)
./kdesrc-build --initial-setup
...
No provider of 'cmake(packagekitqt6)' found.
'libdisplay-info-devel' not found in package names. Trying capabilities.
No provider of 'libdisplay-info-devel' found.
'pkgconfig(libattr)' not found in package names. Trying capabilities.
No provider of 'pkgconfig(libattr)' found.
'pkgconfig(pam)' not found in package names. Trying capabilities.
No provider of 'pkgconfig(pam)' found.
* Failed with exit status 104. Ran into an error with the installer!
* Creating sample configuration file: "~/.config/kdesrc-buildrc"...
* Update your ~/.bashrc? (y/N) y
- Added kdesrc-build directory into PATH
- Added kdesrc-run shell function
* Shell rc-file is successfully setup.
As an additional feed back, I find that it adds too much clutter to .bashrc.
I'm giving up.
--
You are receiving this mail because:
You are watching all bug changes.
[kdesrc-build] [Bug 420630] Unable to find the okular component: The shared library was not found
https://bugs.kde.org/show_bug.cgi?id=420630 --- Comment #7 from ederag --- (In reply to Andrew Shark from comment #6) > Have you followed this article carefully? > https://community.kde.org/Get_Involved/development/Set_up_a_development_environment Yes, this is the one I followed, with care. > I did not tested on OpenSuse, but on Arch Linux. > Have you tried to use suggested paths instead of `/usr/local`? If the issue > still persist, please specify it in more details and reopen. I do not understand. As said in comment #5, it fails at the ./kdesrc-build --initial-setup so well before any paths are mentioned ? Another thing that is unclear: my desktop is KDE Framework Version 5.103.0; yet kdesrc-build insist in getting qt6-related packages ? (I do not see any option to restrict to kf5, and there is no packagekitqt6 in base Leap-15.5, maybe it would just need an additional repo) Are you really interested in getting to the bottom of this ? (I'd rather spend time on this only if the developers find it helpful) -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 283682] KMail duplicates filtered messages
https://bugs.kde.org/show_bug.cgi?id=283682 --- Comment #227 from ederag --- (In reply to Alexandre Bonneau from comment #226) > For info (I posted that info in another related issue already), I found out > that I only get duplicates when I have 2 computers running akonadi-server. Here also, two computers once concurrently ran akonadi with the same configuration (synchronized with unison). But duplicates do appear, even when the other akonadi is stopped. (pgrep akonadi yields nothing on the other computer) [akonadictl 5.16.1 (20.12.0)] -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 426416] New: crash after theme change
https://bugs.kde.org/show_bug.cgi?id=426416 Bug ID: 426416 Summary: crash after theme change Product: systemsettings Version: 5.18.5 Platform: openSUSE RPMs OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- Application: systemsettings5 (5.18.5) Qt Version: 5.12.7 Frameworks Version: 5.71.0 Operating System: Linux 5.3.18-lp152.41-default x86_64 Windowing system: X11 Distribution: "openSUSE Leap 15.2" -- Information about the crash: After trying another theme (breeeze dark was OK), settings crashes when trying to click any icon. Can't remember the theme name. It was one of the first shown, dark, and produces huges buttons. Right click in any kde window (e.g. konsole or desktop), now generates an empty dark rectangle, instead of a popup. (as mentioned in bug 426202) The crash can be reproduced every time. -- Backtrace: Application: System Settings (systemsettings5), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". 29return SYSCALL_CANCEL (poll, fds, nfds, timeout); [Current thread is 1 (Thread 0x7f7a70264900 (LWP 8101))] Thread 3 (Thread 0x7f7a45c51700 (LWP 8113)): #0 0x7f7a6b7361d8 in __GI___libc_read (fd=14, buf=buf@entry=0x7f7a45c50a70, nbytes=nbytes@entry=16) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x7f7a64cf99a0 in read (__nbytes=16, __buf=0x7f7a45c50a70, __fd=) at /usr/include/bits/unistd.h:44 #2 g_wakeup_acknowledge (wakeup=0x7f7a480039a0) at ../glib/gwakeup.c:210 #3 0x7f7a64cb2298 in g_main_context_check (context=context@entry=0x7f7a4be0, max_priority=2147483647, fds=fds@entry=0x7f7a40004a90, n_fds=n_fds@entry=1) at ../glib/gmain.c:3732 #4 0x7f7a64cb2720 in g_main_context_iterate (context=context@entry=0x7f7a4be0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../glib/gmain.c:3951 #5 0x7f7a64cb288c in g_main_context_iteration (context=0x7f7a4be0, may_block=may_block@entry=1) at ../glib/gmain.c:4015 #6 0x7f7a6c0d019b in QEventDispatcherGlib::processEvents (this=0x7f7a4b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #7 0x7f7a6c07132a in QEventLoop::exec (this=this@entry=0x7f7a45c50c90, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225 #8 0x7f7a6be9710a in QThread::exec (this=this@entry=0x558691df7440) at thread/qthread.cpp:531 #9 0x7f7a699e5ba5 in QQmlThreadPrivate::run (this=0x558691df7440) at /usr/src/debug/libqt5-qtdeclarative-5.12.7-lp152.2.2.x86_64/src/qml/qml/ftw/qqmlthread.cpp:148 #10 0x7f7a6be988b2 in QThreadPrivate::start (arg=0x558691df7440) at thread/qthread_unix.cpp:361 #11 0x7f7a6740d4f9 in start_thread (arg=0x7f7a45c51700) at pthread_create.c:465 #12 0x7f7a6b744fbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 2 (Thread 0x7f7a502cf700 (LWP 8104)): #0 0x7f7a6b7361d8 in __GI___libc_read (fd=7, buf=buf@entry=0x7f7a502cea60, nbytes=nbytes@entry=16) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x7f7a64cf99a0 in read (__nbytes=16, __buf=0x7f7a502cea60, __fd=) at /usr/include/bits/unistd.h:44 #2 g_wakeup_acknowledge (wakeup=0x5586913845b0) at ../glib/gwakeup.c:210 #3 0x7f7a64cb2298 in g_main_context_check (context=context@entry=0x7f7a48000be0, max_priority=2147483647, fds=fds@entry=0x7f7a48004e90, n_fds=n_fds@entry=1) at ../glib/gmain.c:3732 #4 0x7f7a64cb2720 in g_main_context_iterate (context=context@entry=0x7f7a48000be0, block=block@entry=1, dispatch=dispatch@entry=1, self=) at ../glib/gmain.c:3951 #5 0x7f7a64cb288c in g_main_context_iteration (context=0x7f7a48000be0, may_block=may_block@entry=1) at ../glib/gmain.c:4015 #6 0x7f7a6c0d019b in QEventDispatcherGlib::processEvents (this=0x7f7a48000b10, flags=...) at kernel/qeventdispatcher_glib.cpp:424 #7 0x7f7a6c07132a in QEventLoop::exec (this=this@entry=0x7f7a502cec80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:225 #8 0x7f7a6be9710a in QThread::exec (this=this@entry=0x7f7a6c7b8d80 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread.cpp:531 #9 0x7f7a6c540cd5 in QDBusConnectionManager::run (this=0x7f7a6c7b8d80 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:178 #10 0x7f7a6be988b2 in QThreadPrivate::start (arg=0x7f7a6c7b8d80 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:361 #11 0x7f7a6740d4f9 in start_thread (arg=0x7f7a502cf700) at pthread_create.c:465 #12 0x7f7a6b744fbf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Thread 1 (Thread 0x7f7a70264900 (LWP 8101)): [KCrash Handler] #4 QPixmapStyle::drawControl (this=0x558691380d80, element=QStyle::CE_ShapedFrame, option=0x5586922fefd0, painter=0x7fffb9a746e0, widg
[systemsettings] [Bug 426416] crash after theme change
https://bugs.kde.org/show_bug.cgi?id=426416 --- Comment #1 from ederag --- Fixed by the following change in ~/.config/kdeglobals -widgetStyle=bb10dark +widgetStyle=Breeze -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 427908] Crash on zoom
https://bugs.kde.org/show_bug.cgi?id=427908 --- Comment #3 from ederag --- Created attachment 133798 --> https://bugs.kde.org/attachment.cgi?id=133798&action=edit blank article -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 427908] Crash on zoom
https://bugs.kde.org/show_bug.cgi?id=427908 ederag changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #4 from ederag --- It happens with any file. For instance a blank File > New > article (attached) The openSUSE KDE repo has been updated: KDE Frameworks 5.76.0 Qt 5.15.2 (built against 5.15.2) The xcb windowing system Kile 2.9.93 okular 20.11.90 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 492957] New: Text annotations with a zero-area bounding box can not be opened (no pop up).
https://bugs.kde.org/show_bug.cgi?id=492957 Bug ID: 492957 Summary: Text annotations with a zero-area bounding box can not be opened (no pop up). Classification: Applications Product: okular Version: 23.08.5 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- Created attachment 173539 --> https://bugs.kde.org/attachment.cgi?id=173539&action=edit File generated by LibreOffice Impress with a comment Annotations with a zero-area bounding box (x_min == x_max || y_min == ymax) seem impossible to open in okular. As an example, please find attached a PDF generated by LibreOffice Impress (a single page with some text and a comment below). I understand their idea: the reader is then allowed to choose the most appropriate area where the mouse should hover to popup the comment (for instance it could match the icon marking the comment presence). That's why it is tentatively reported here. If the okular devs have counter-arguments, I'd be glad to hear and turn the discussion to LibreOffice, of course. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Leap 15.6 KDE Plasma Version: 5.27.11 KDE Frameworks Version: 5.115.0 Qt Version: 5.15.12 ADDITIONAL INFORMATION Here is the line with the annotation bounding box in the PDF: <>/Rect[355.124 303.221 355.124 303.221] /Popup 9 0 R /M Increasing both xmax and ymax (say by 10.0) in a text editor allow to popup the comment normally in okular. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 492957] Text annotations with a zero-area bounding box can not be opened (no pop up).
https://bugs.kde.org/show_bug.cgi?id=492957 --- Comment #2 from ederag --- (In reply to Albert Astals Cid from comment #1) > You can open it from the annotations sidebar? Yes, it is readable in the annotation sidebar. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 492957] Text annotations with a zero-area bounding box can not be opened (no pop up).
https://bugs.kde.org/show_bug.cgi?id=492957 --- Comment #4 from ederag --- OK, reported to libreoffice then: https://bugs.documentfoundation.org/show_bug.cgi?id=162955 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 492957] Text annotations with a zero-area bounding box can not be opened (no pop up).
https://bugs.kde.org/show_bug.cgi?id=492957 --- Comment #5 from ederag --- Excerpt from this answer (https://bugs.documentfoundation.org/show_bug.cgi?id=162955#c2) from libreoffice: > Can't test Okular or other poppler based PDF viewers. But not sure I'd agree > this is a malformed PDF. And from https://bugs.documentfoundation.org/show_bug.cgi?id=162955#c4 > Yes, get a pop-up on mouseover in each of them [chrome, edge and reader]. WIth okular on windows, they find that a popup can appear, but one has to "hunt" for the right position. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 492957] Text annotations with a zero-area bounding box can not be opened (no pop up).
https://bugs.kde.org/show_bug.cgi?id=492957 --- Comment #6 from ederag --- Looking for the specs there https://pdfa.org/resource/pdf-specification-archive/ which links to https://web.archive.org/web/20080624230300/http://www.adobe.com/devnet/acrobat/pdfs/pdf_reference_1-7.pdf > BBox: rectangle > (Optional for Annot; required for any figure or table appearing in its > entirety on > a single page; not inheritable). An array of four numbers in default user > space > units giving the coordinates of the left, bottom, right, and top edges, > respec- > tively, of the element’s bounding box (the rectangle that completely encloses > its visible content). This attribute applies to any element that lies on a > single > page and occupies a single rectangle. I searched the spec, and nothing seems to prevent a zero-area bounding box. Rationale: the viewer then gets to choose the appropriate hover area. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 388869] continuing problem with duplicate and/or missing messages
https://bugs.kde.org/show_bug.cgi?id=388869 ederag changed: What|Removed |Added CC||ed...@gmx.fr --- Comment #1 from ederag --- Sometimes (once a week or so), I have to open akonadiconsole to delete few stray duplicates: org.kde.pim.akonadiconsole: Item fetch failed: "Unable to fetch item from backend (collection -1) : Unable to retrieve item from resource: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 233275 () (in collection 302) with dirty payload, aborting STORE." So the message is very similar to the OP. This happens only for gnu mailing lists. (e.g. Octave Maintainers List ), downloaded through pop3, with a filter moving the message to a dedicated subfolder (research/soft/octave/) -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 283682] KMail duplicates filtered messages
https://bugs.kde.org/show_bug.cgi?id=283682 --- Comment #217 from ederag --- (In reply to graham from comment #216) > Was a KMail for what seems like forever (~2000?) (I've been a KDE user since > it first came out in '96), but after dealing with workarounds and hacks for > two+ years I eventually gave in and abandoned KMail back in mid-2017. There was a commit in 2017-05-04 https://phabricator.kde.org/R206:43f2cde61f98317eb13d98222a57bc6df323a308 that was about this bug. And indeed in openSUSE Leap-15 (kdepim-runtime 17.12.3), there are much fewer duplicates than before. There is now a related bug about unreachable duplicates that has already been reported as #388869. (In reply to Tobias Leupold from comment #214) > I think one should rather wonder if this even can be fixed > inside this Akonadi monster I personally wouldn't even dare to look at > the code, or if one should reconsider the whole thing. kmail/akonadi handle my > 15GB maildir gracefully, which is quite a performance. Congratulations ! So it is not perfect, but to me it is an amazing piece of software. Please consider that it is very hard for maintainers to fix a bug that is not reproducible on their setup. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 283682] KMail duplicates filtered messages
https://bugs.kde.org/show_bug.cgi?id=283682 --- Comment #218 from ederag --- With a working link: bug #388869 -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 384264] Make it possible to disable media controls on lock screen
https://bugs.kde.org/show_bug.cgi?id=384264 --- Comment #21 from ederag --- > It's in the 'Appearance' tab of the 'Screen locking' settings. Definitely not there on my system described in comment #19. Only "Wallpaper type" and "Positioning". What's your system ? -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 384264] Make it possible to disable media controls on lock screen
https://bugs.kde.org/show_bug.cgi?id=384264 --- Comment #23 from ederag --- (In reply to Kishore Gopalakrishnan from comment #22) > I have a checkbox titled 'show media controls' on top of 'wallpaper type'. > I'm using Plasma 5.16.5 on Arch Linux. Thanks, despite v5.12.6 being in the commit tags https://phabricator.kde.org/source/kscreenlocker/tags/master/;e36101cd1b4857a23e05b9d1f039e9358bd1f49b, the checkbox is not there in v5.12.6. Thank you for the information, time to upgrade. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 420630] Unable to find the okular component: The shared library was not found
https://bugs.kde.org/show_bug.cgi?id=420630 --- Comment #3 from ederag --- Additional information: For okular, it was important to set QT_PLUGIN_PATH before the build, not after; otherwise the tests failed, because ctest is exclusively using a QT_PLUGIN_PATH defined during build. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 422827] New: Annotation toolbar fails to appear, unless rc-files are wiped out
https://bugs.kde.org/show_bug.cgi?id=422827
Bug ID: 422827
Summary: Annotation toolbar fails to appear, unless rc-files
are wiped out
Product: okular
Version: unspecified
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: okular-de...@kde.org
Reporter: ed...@gmx.fr
Target Milestone: ---
The new annotation toolbar remained invisible (e.g. F6 did nothing).
The toolbar appeared after following the test instructions and restart okular:
rm -i ~/.config/okularpartrc \
~/.config/okularrc \
~/.local/share/kxmlgui5/okular/part.rc \
~/.local/share/kxmlgui5/okular/shell.rc
(note: shell.rc was absent on my system)
SOFTWARE/OS VERSIONS
openSUSE Leap-15.1, with okular built through kdesrc-build.
KDE Frameworks Version: KDE Frameworks 5.71.0
Qt Version: Qt 5.14.2 (built against 5.14.2)
ADDITIONAL INFORMATION
First occurrence in 0b05d7ce9 ("Overhaul annotations UX", 2020-06-04)
--
You are receiving this mail because:
You are watching all bug changes.
[okular] [Bug 422828] New: New annotation toolbar button/action mismatch
https://bugs.kde.org/show_bug.cgi?id=422828
Bug ID: 422828
Summary: New annotation toolbar button/action mismatch
Product: okular
Version: unspecified
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: okular-de...@kde.org
Reporter: ed...@gmx.fr
Target Milestone: ---
The new annotation toolbar buttons and their actions do not match, e.g.:
Underline => new text note
Strike through => highlighter
Inline Note => Straight line
Freehand line => Underline
SOFTWARE/OS VERSIONS
openSUSE Leap-15.1, with okular built through kdesrc-build.
KDE Frameworks Version: KDE Frameworks 5.71.0
Qt Version: Qt 5.14.2 (built against 5.14.2)
ADDITIONAL INFORMATION
First occurrence in 0b05d7ce9 ("Overhaul annotations UX", 2020-06-04)
--
You are receiving this mail because:
You are watching all bug changes.
[okular] [Bug 422828] New annotation toolbar button/action mismatch
https://bugs.kde.org/show_bug.cgi?id=422828 --- Comment #2 from ederag --- It would be normal to have some adjustments after such a huge change, and my setup may be non-standard. okular was first built together with dependencies through kdesrc-build, with the build and the install directories on a dedicated drive. Then for testing, cd /usr/local/build/kde/build/okular cmake -v ~/share/prog/kde/dev/okular make install bash source ./prefix.sh okular exit There are no scripts run in the output of the make install step. I already wiped aside ~/.config/okularrc and ~/.config/okularpartrc And my old "quick annotations" are indeed gone. Note: wiped them out again, and even without touching the toolbar position, the mismatch still occurs. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 422828] New annotation toolbar button/action mismatch
https://bugs.kde.org/show_bug.cgi?id=422828 --- Comment #4 from ederag --- (In reply to Simone Gaiarin from comment #3) > Removing ~/.config/okularpartrc should solve the problem but does not seem > so in your case. Indeed, the old ~/.kde4/share/config/okularpartrc was picked up as a replacement. It had the same [Reviews] field as ~/.config/okularpartrc before 0b05d7ce9. Fixed by mv ~/.kde4 ~/.kde4_bck rm ~/.config/okularrc ~/.config/okularpartrc One mystery solved, thanks ! -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 422827] Annotation toolbar fails to appear, unless rc-files are wiped out
https://bugs.kde.org/show_bug.cgi?id=422827 --- Comment #4 from ederag --- Created attachment 129268 --> https://bugs.kde.org/attachment.cgi?id=129268&action=edit original part.rc Here is the backup file. If you find a way and look for a tester, I'm ready to help. Congratulations: it's cool for the annotations toolbar to be moveable. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 394775] Annotations in the separated XML files
https://bugs.kde.org/show_bug.cgi?id=394775 ederag changed: What|Removed |Added CC||ed...@gmx.fr --- Comment #6 from ederag --- (In reply to Ambrogio De Lorenso from comment #5) > 1. what was the last okular version used this function > 2. There are other PDF viewer that permit annotations without changing PDF? Version 1.2. Okular is too good to move away from ! A package for openSUSE can be found in https://build.opensuse.org/package/show/home:ederag/okular-1.2 Another description of use cases: in the last paragraph of https://bugs.kde.org/show_bug.cgi?id=397097#c2 and in https://bugs.kde.org/show_bug.cgi?id=397097#c3 An interface design was proposed in https://bugs.kde.org/show_bug.cgi?id=397097#c8 what do you think ? I'm ready to help implementing it, although my c++ is rusty and the task is daunting. Discussion and pointers would be appreciated. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 394775] Annotations in the separated XML files
https://bugs.kde.org/show_bug.cgi?id=394775 --- Comment #10 from ederag --- (In reply to David Hurka from comment #9) > * Drawings with popup note: I don’t think that makes sense. Here is my use case for that: highlight a sentence in orange to mean "there's an issue here", and give details in the popup. Very handy. > In case of Notes, it is understandable that the local note should stay when > the remote PDF changes. But this can be done with Bookmarks. Bookmarks were attached to pages (or did that change ?), the granularity was not fine enough for me. > In case of Drawings, they should not stay when the remote PDF changes, > because when the PDF gets fixed they become obsolete. Indeed. But why focus on pdf changes ? I only use annotations when the underlying pdf stays unaltered. (articles, or official documents) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 394775] Annotations in the separated XML files
https://bugs.kde.org/show_bug.cgi?id=394775 --- Comment #12 from ederag --- Thanks for the tip, xournal improved a lot! Yet xournalpp is fine for few pages, but currently slow to open books. (tested with a 56MB, 500 pages long pdf, xournalpp versions 1.0.8 and current master: 4d2e2fb) Development is active, that might improve quickly. I'm really fond of okular reactivity. The text/columns aware highlighter of okular is also amazing. The migration of docdata would also be an issue. And it does not look feasible to annotate a pdf attached to a mail, move the mail to its folder, reopen the pdf and see the annotations, as used to be possible with okular. But the LaTeX annotations of xournal are appealing. okular part.cpp was very readable (as often with kde code), and docdata capability is still around (for archives). That opens other possibilities. A workaround might be found, without bothering okular devs. Need to think. -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 420521] New: initial-setup fails on libattr
https://bugs.kde.org/show_bug.cgi?id=420521 Bug ID: 420521 Summary: initial-setup fails on libattr Product: kdesrc-build Version: Git Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mp...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- initial-setup fails on libattr, even if the package is installed. Steps to reproduce: git checkout ca90af91d60ca818d0104e8f8bebf9d4ed7c9500 ./kdesrc-build --initial-setup ... 'xcb-util-keysyms-devel' providing 'pkgconfig(xcb-keysyms)' is already installed. 'pkgconfig(libattr)' not found in package names. Trying capabilities. * Ran into an error with the installer! SOFTWARE/OS VERSIONS openSUSE 15.1 KDE Frameworks 5.55.0 Qt 5.9.7 (built against 5.9.7) Similar report: https://www.reddit.com/r/kde/comments/g4lb0u/kdesrcbuild_cannot_install_pkgconfignetworkmanager/ git bisect says 1b34b936490b652bf99e03197f18c53abf4eb3fd is the first bad commit Date: Mon Dec 16 22:33:23 2019 + Fix RPM dependencies -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 394775] Annotations in the separated XML files
https://bugs.kde.org/show_bug.cgi?id=394775 --- Comment #15 from ederag --- (In reply to David Hurka from comment #14) > So if you let a document be reviewed by multiple reviewers, ... > it would be useful to export all annotations ... > and import them into another document. > ... would that help the reporters of this bug? Interesting use case and feature, but we need an automatic, instant save of the annotations (as used to be). Another use case where separate annotations are necessary: when we receive a protected file. That will be prevented by https://invent.kde.org/kde/okular/-/merge_requests/105 > The current document is protected: All actions are disabled -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 420630] New: Unable to find the okular component: The shared library was not found
https://bugs.kde.org/show_bug.cgi?id=420630 Bug ID: 420630 Summary: Unable to find the okular component: The shared library was not found Product: okular Version: unspecified Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- When building from sources, okular just shows an error window. STEPS TO REPRODUCE ./kdesrc-build --initial-setup # change the following lines in ~/.kdesrc-buildrc : # (sources in my home, the rest on another drive) kdedir /usr/local/build/kde/install # Where to install KF5-based software qtdir /usr/local/build/kde/qt5 # Where to find Qt5 source-dir ~/share/prog/kde/dev # Where sources are downloaded build-dir /usr/local/build/kde/build # Where the source build is run ./kdesrc-build okular ./kdesrc-build --run okular fails with a small message window with "Unable to find the okular component: The shared library was not found", instead of opening a main window. SOFTWARE/OS VERSIONS openSUSE-15.1 KDE Frameworks 5.70.0 Qt 5.13.2 (built against 5.13.2) kdesrc-build 19.12 (v19.12) ADDITIONAL INFORMATION The build executable /usr/local/build/kde/build/okular/bin/okular works. workaround: cd /usr/local/build/kde/install/lib64 ln -s plugins/okularpart.so . -- You are receiving this mail because: You are watching all bug changes.
[kdesrc-build] [Bug 420630] Unable to find the okular component: The shared library was not found
https://bugs.kde.org/show_bug.cgi?id=420630 --- Comment #2 from ederag --- # Indeed, removed the link, fails, then export QT_PLUGIN_PATH=/usr/local/build/kde/install/lib64/plugins ./kdesrc-build --run okular works -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 415015] New: hide unread email count from taskbar icons
https://bugs.kde.org/show_bug.cgi?id=415015 Bug ID: 415015 Summary: hide unread email count from taskbar icons Product: kmail2 Version: 5.10.3 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- After upgrading to openSUSE Leap 15.1, kmail still works fine, good ! Yet I have been puzzled by the 9,999+ label over the icon in the task bar. This is actually the unread email count newly added by https://phabricator.kde.org/D9841 This is useless for + unread mails (a mailing list I'm either searching in, or filtering on previously read messages); but even if the count was meaningful, I would much prefer to hide this unread count when not in the task of consulting mails. Is there any way to turn this feature off ? (none found yet) KDE Plasma Version: 5.12.8 KDE Frameworks 5.55.0 Qt 5.9.7 (built against 5.9.7) -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 388869] continuing problem with duplicate and/or missing messages
https://bugs.kde.org/show_bug.cgi?id=388869 --- Comment #2 from ederag --- After adding a filter: - match all messages - Executed Command: /usr/bin/sleep 1, no duplicates for months. (on openSUSE Leap-15.0) This is only a workaround, and maybe a clue to find what's going on. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 415015] hide unread email count from taskbar icons
https://bugs.kde.org/show_bug.cgi?id=415015 ederag changed: What|Removed |Added Resolution|NOT A BUG |FIXED --- Comment #3 from ederag --- Indeed, not there yet. Good to know it is configurable in newer versions, thanks ! -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 388869] continuing problem with duplicate and/or missing messages
https://bugs.kde.org/show_bug.cgi?id=388869 --- Comment #3 from ederag --- Confirmed with KMail 5.10.3 shipped with openSUSE Leap-15.1: After disabling the delay filter described in comment #2, it took only a few days to get Unable to fetch item from backend (collection -1) : Unable to retrieve item from resource: [LRCONFLICT] Resource akonadi_maildir_resource_0 tries to modify item 107263 () (in collection 53) with dirty payload, aborting STORE. Again that came from a gnu mailing list (https://lists.gnu.org/mailman/listinfo/texmacs-dev) -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 421086] New: Import a project installed by kdesrc-build
https://bugs.kde.org/show_bug.cgi?id=421086 Bug ID: 421086 Summary: Import a project installed by kdesrc-build Product: kdevelop Version: 5.3.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Build tools: CMake Assignee: kdevelop-bugs-n...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- Importing in kdevelop the okular/CMakeLists.txt project installed through `kdesrc-build okular`, code navigation failed: Hovering on a method or hitting Alt does not bring any information (usually, it says where it has been defined, allowing easy navigation, it's great !) Note: grep build-dir ~/.kdesrc-buildrc build-dir /usr/local/build/kde/build # Where the source build is run (not in the standard place for disk space/speed/no-backup reasons) This report shares how this has been solved, thanks to help on freenode #kdevelop: [17:31] ederag: so in the project configuration, in the page "CMake", at the top you want to have the entry pointing to the toplevel build dir of okular you use with kdesrc-build. That's the directory shown by grep build-dir ~/.kdesrc-buildrc Now all the variables point to the /usr/local/build/kde ... great ! And a few minutes later (5-15 min ?), the semantic highlighting just came on. code navigation works ! Now configure the launch: workaround https://bugs.kde.org/show_bug.cgi?id=420630#c1 Settings > configure kdevelop > Environment > profile > Add "kde" add a line with variable: QT_PLUGIN_PATH value: /usr/local/build/kde/install/lib64/plugins run > Configure Launches > Add > choose a name, e.g. 'kdesrc-build run' Script interpreter: perl Always run the same file : file:///home/ederag/share/prog/kde/kdesrc-build/kdesrc-build Arguments: --run okular Environment: kde (the one created above) since the launch passes through a script, the process has to be attached manually: https://docs.kde.org/trunk5/en/extragear-kdevelop/kdevelop/attaching-the-debugger-to-a-running-process.html Of course it could be possible to add these instructions, e.g. in https://docs.kde.org/trunk5/en/extragear-kdevelop/kdevelop/setting-up-a-session-and-importing-an-existing-project.html#option-2--importing-a-project-that-is- already-on-your-hard-drive but it would be great if this could be integrated into the wizard itself. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 283682] KMail duplicates filtered messages
https://bugs.kde.org/show_bug.cgi?id=283682 --- Comment #221 from ederag --- (In reply to linuxfan from comment #220) > for ages there has been an error message in my mysql/mariadb log-file: > > [ERROR] Incorrect definition of table mysql.event: expected column > 'sql_mode' at position 14 to have type set ... Thanks for sharing. In which log file exactly did you find this error ? /var/log/mysql/ is empty here, so pgrep -af mysqld /usr/sbin/mysqld --defaults-file=/home/ederag/.local/share/akonadi/mysql.conf --datadir=/home/ederag/.local/share/akonadi/db_data/ --socket=/tmp/akonadi-ederag.Yqlbg1/mysql.socket --pid-file=/tmp/akonadi-ederag.Yqlbg1/mysql.pid grep -1 "error log" /home/ederag/.local/share/akonadi/mysql.conf # # error log file name, relative to datadir (default:hostname.err) log_error=mysql.err grep -i error /home/ederag/.local/share/akonadi/db_data/mysql.err That was with the "1 s" delay filter active, just deactivated; we'll see. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 394775] Annotations in the separated XML files
https://bugs.kde.org/show_bug.cgi?id=394775
--- Comment #16 from ederag ---
Good news: an experimental helper script seems to workaround our use case.
(there are issues, it's not ready to share yet)
It required a two line hack (not satisfying yet) to okular,
so that the archive holds the original file,
and the annotations in its metadata.xml.
The helper is using sha512sum, so the annotations follow file renames.
So if okular would keep the ability/option to store annotations in
metadata.xml,
together with an option to avoid https://bugs.kde.org/show_bug.cgi?id=397097,
then chances are we could all be happy.
Why think so ?
The reasons for burning things into the pdf were indeed compelling:
- confusion on renames,
- use cases opposite to ours (https://bugs.kde.org/show_bug.cgi?id=315552)
- and security issues with forms data
(https://bugs.kde.org/show_bug.cgi?id=267350)
The latter forces to burn the form data into the pdf.
So it was decided to burn annotations into as well.
Yet there is a strong difference between forms and annotations:
one writes *into* a form ("fill a form"), while
one *adds* an annotation *onto* a document.
Please don't get me wrong,
I'm not prying to change the default behavior at all.
Just advocating that our use case makes sense as well,
and would be a nice option to have.
--
You are receiving this mail because:
You are watching all bug changes.
[Akonadi] [Bug 283682] KMail duplicates filtered messages
https://bugs.kde.org/show_bug.cgi?id=283682 --- Comment #225 from ederag --- Well, only half a day before a duplicate is back. (again, from lists.gnu.org) Same status as in comment #221. And nothing suspicious in mysql.err (no ERROR). -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 397097] .okular archive should store the original file
https://bugs.kde.org/show_bug.cgi?id=397097 --- Comment #8 from ederag --- The okular developers have done a great job in general, so the following is just an idea, not prying at all. Here is a possible design that would clarify saving with annotations, while bringing back the great external annotations as an option: - keep two groups of annotations: internal/external (saved inside / saved outside document). This is possible since annotations overlap is already accepted. - global option to direct new annotations to internal or external by default. (and create an individual annotation property for that, so that it is possible to change an annotation destination at any time. This would also be a way to help migration if so desired ) - Potential concern: When an internal annotation is saved, the document size changes, so the external annotations file name, based on size, has to be updated. The number of annotation files might increase a lot ? not in the standard use cases: in my case, a pdf with an existing internal annotation is just complemented with external annotations. No pdf file change. Opposite use case is no external annotations at all. No problem either. For an unlikely hybrid workflow, it should be possible to provide a mean to chose between copying or just moving the external annotation file. => not blocking at all, actually. >From a user perspective this looks like the best of both worlds, but of course, that would complexify the code, and I do not know the internals of okular; that might be even too difficult to implement and maintain. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 393811] Inconsistent behaviour in saving comments
https://bugs.kde.org/show_bug.cgi?id=393811 ederag changed: What|Removed |Added Ever confirmed|0 |1 CC||ed...@gmx.fr Status|UNCONFIRMED |CONFIRMED --- Comment #1 from ederag --- confirmed, in okular 1.3.3 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 397097] New: .okular archive should store the original file
https://bugs.kde.org/show_bug.cgi?id=397097 Bug ID: 397097 Summary: .okular archive should store the original file Product: okular Version: 1.3.3 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- Save as .okular includes the annotations into the pdf. This is unexpected, as the .okular archive usually stores the original file together with the annotations in a separate metadata.xml So the current treatment of pdf is inconsistent with the treatment of png, for instance. The unfortunate but understandable change described in https://forum.kde.org/viewtopic.php?t=122750 means that the separate annotations will not be possible any longer, right ? In this case, a warning should be issued, such as "Warning: the pdf file that is about to be stored inside the .okular archive will not be the original one; it will be modified to include the annotations" (with a 'do no warn next time' option) -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 397186] New: adding calendar from jsp url does nothing
https://bugs.kde.org/show_bug.cgi?id=397186 Bug ID: 397186 Summary: adding calendar from jsp url does nothing Product: korganizer Version: 5.7.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: import/export Assignee: kdepim-b...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- Right click in the calendar list> Add Calendar> iCal Calendar file paste the url (looking like https://server/jsp/custom/modules/plannings/direct_cal.jsp?data=4011850addbbf02) in the Filename entry (should be allowed: "A URL of a remote file can also be specified") Check "Read only" OK The dialog closes, but no calendar appears. The url is valid, since after a direct download with curl https://server/jsp/custom/modules/plannings/direct_cal.jsp?data=4011850addbbf02 > remotecal.ics and giving the path to remotecal.ics, the calendar appears correctly. The reason why has possibly been given by Markus: https://bugs.kde.org/show_bug.cgi?id=308129#c2 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 397097] .okular archive should store the original file
https://bugs.kde.org/show_bug.cgi?id=397097 --- Comment #2 from ederag --- (In reply to Albert Astals Cid from comment #1) > Why would the user care that in that .okular file the pdf is not the > original one? This will be explained in point 1) below. > Moreover, do we promise that in the .okular file will have the > original file at all somewhere? No promises made that I could recall, but this is the way it has been working for years. The preservation of the original was a cool feature of okular. [once understood; I do agree that the beginning was uncomfortable] Just pointing out a possible surprise, that could be discovered too late by an unsuspecting user. > Why do you want the annotations to be separate? Please note that I do not "want" the annotations to be separate. This would be cool, but I also understand that developer time is precious. Sometimes it is good for orthogonality to have an intermediate structure (here the metadata), common to all types, so that it is well tested, and translate back and forth with backends. But here, if I read you correctly (?) elsewhere, keeping both would really be a burden for pdfs. So this report was more about not losing the original without a warning, and maybe having a possibility to save the original too. Now if the question was about the use case : 1) Articles can be sometimes difficult to obtain, so the original is precious. A backup is possible, but requires more bookkeeping (two locations for each article, for save, rename, deletion) Preserving the original in the zip would be a trade-off between risk of corruption by the zip process [still have to read about this] and ease of handling. This bookkeeping was also necessary for the infrequent rename and deletion in the previous - docdata - versions, but it was mitigated by the fact that a) the more frequent download step was straightforward (just one save at the desired location), b) disk space was optimized, contrary to the "backup" solution, and c) it was possible to open some pdf on a cloud (or any site) and annotate it with okular without having to upload it back. 2) separate annotations are easy to search for and to modify "by hand", and more importantly here, would provide a way to automatize the migration to the new scheme: take the original, create the metadata.xml from docdata, and zip together. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 369122] ~/.cache/kioexec/krun/_0_ does not exist
https://bugs.kde.org/show_bug.cgi?id=369122 ederag changed: What|Removed |Added CC||colpe...@gmail.com --- Comment #6 from ederag --- *** Bug 397385 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 397385] Error "A folder named $$ already exists"
https://bugs.kde.org/show_bug.cgi?id=397385 ederag changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ed...@gmx.fr Resolution|--- |DUPLICATE --- Comment #1 from ederag --- Looks like bug #369122 ? Please reopen with details if this bug is different. *** This bug has been marked as a duplicate of bug 369122 *** -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 397704] New: KIOExec: A folder named .cache/kioexec/krun/_0/ already exists.
https://bugs.kde.org/show_bug.cgi?id=397704
Bug ID: 397704
Summary: KIOExec: A folder named
.cache/kioexec/krun/_0/ already exists.
Product: frameworks-kio
Version: 5.45.0
Platform: openSUSE RPMs
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: fa...@kde.org
Reporter: ed...@gmx.fr
CC: kdelibs-b...@kde.org
Target Milestone: ---
This looks like bug #369122, except it occurs for any link,
in kmail, or even a simple url shortcut on the desktop.
This is probably a duplicate of bug #393673,
but easier to find since here the error is in english.
rm -r ~/.cache
does not solve anything, even after a logout.
With a new user, it works.
So something is wrong in my configuration.
But it would be better to diagnose the issue.
inspired by https://bugs.kde.org/show_bug.cgi?id=343329#c4:
/usr/lib64/libexec/kf5/kioexec cat ftp://ftp.gnu.org/README
command= "cat" args= ("cat", "ftp://ftp.gnu.org/README";)
Copying QUrl("ftp://ftp.gnu.org/README";) to
QUrl("file:///home/ederag/.cache/kioexec/krun/23201_0/README")
So this is perhaps not a kioexec issue ?
This does not seem related to firefox either, since
/usr/lib64/libexec/kf5/kioexec firefox ftp://ftp.gnu.org/README
opens the README in firefox.
--
You are receiving this mail because:
You are watching all bug changes.
[kio-extras] [Bug 369122] ~/.cache/kioexec/krun/_0_ does not exist
https://bugs.kde.org/show_bug.cgi?id=369122 ederag changed: What|Removed |Added CC||ed...@gmx.fr --- Comment #7 from ederag --- Same symptoms, but for any link, not only for phones: bug #397704 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 397704] KIOExec: A folder named .cache/kioexec/krun/_0/ already exists.
https://bugs.kde.org/show_bug.cgi?id=397704 --- Comment #3 from ederag --- Tested in kmail, dolphin, and a link on the desktop. Also happens after selecting some text in okular, and right click>search for ... in duckduckgo. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 397097] .okular archive should store the original file
https://bugs.kde.org/show_bug.cgi?id=397097 --- Comment #3 from ederag --- Another use case: An email with administrative instructions attached as pdf. With the previous version, it was possible to highlight the important parts, now it has to be written back in the mail, which is risky, and undesirable for official information like this. All considered, I'll try to downgrade to 1.2. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 397704] KIOExec: A folder named .cache/kioexec/krun/_0/ already exists.
https://bugs.kde.org/show_bug.cgi?id=397704 ederag changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #4 from ederag --- Another clue: the behavior depends on the link: for links like https://bitbucket.org/me_ydv_5/octave/wiki/Home firefox opens with file:///home/ederag/.cache/kioexec/krun/16436_0/Home in the url bar. For https://bitbucket.org/me_ydv_5/octave/wiki it opens with file:///home/ederag/.cache/kioexec/krun/16471_0/wiki For https://bitbucket.org/me_ydv_5/octave/wiki/ (mind the ending slash), error KIOExec: "A folder named /home/ederag/.cache/kioexec/krun/16497_0/ already exists." System Settings>Default applications>Web Browser>open http and https: changing the existing command: firefox => firefox "%u" solved it. This is definitely not a KIO bug. Closing as resolved, moved to opensuse https://bugzilla.opensuse.org/show_bug.cgi?id=1105623 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 397097] .okular archive should store the original file
https://bugs.kde.org/show_bug.cgi?id=397097 --- Comment #4 from ederag --- Done, here is the downgraded package, for openSUSE Leap15.0: https://build.opensuse.org/package/show/home:ederag/okular-1.2 -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 374780] Huge memory usage just for the calendar with korgac and ical resource
https://bugs.kde.org/show_bug.cgi?id=374780 --- Comment #8 from ederag --- The workaround described in comment #2 can be automated (backup ~/.kde4/share/apps/korganizer/std.ics first !): kquitapp korganizer kquitapp korgac akonadictl stop # wait a bit for akonadi to really stop sleep 2 # DISCLAIMER: This will modify the calendar IN-PLACE. BACKUP first ! # strip the .ics from wrong error messages perl -i -p -0 -e 's/X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE \R parameter with an illegal type for property: VALUE=DATE-TIME\R//g' ~/.kde4/share/apps/korganizer/std.ics -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 374780] Huge memory usage just for the calendar with korgac and ical resource
https://bugs.kde.org/show_bug.cgi?id=374780
ederag changed:
What|Removed |Added
CC||ed...@gmx.fr
--- Comment #1 from ederag ---
Created attachment 109689
--> https://bugs.kde.org/attachment.cgi?id=109689&action=edit
massif output for korganizer
Same symptom here, although with an older version
korganizer --version
Qt: 4.8.6
KDE Development Platform: 4.14.25
KOrganizer: 4.14.10
korgac quickly reaches 2GB, then remains stable.
massif.out.16937 generated as follow:
akonadictl stop
kquitapp korgac
akonadictl start
valgrind --tool=massif korganizer --nofork
# the korgac process reaches about 2GB memory in few seconds
# could not quit cleanly the korganizer window (no interaction)
# Ctrl-C
# this is an ical, not a deprecated kcal issue
ps -ef | grep akonadi | grep cal_
/usr/bin/akonadi_agent_launcher akonadi_ical_resource akonadi_ical_resource_4
# the .ics files are only few MB:
find .kde4 -name "*.ics" -exec du -sk {} \;
4 .kde4/share/apps/kalarm/calendar.ics
4 .kde4/share/apps/kalarm/displaying.ics
4 .kde4/share/apps/kalarm/expired.ics
2272.kde4/share/apps/korganizer/std.ics
1124.kde4/share/apps/ktimetracker/ktimetracker.ics
There might be something wrong in this database;
any advice for further investigation ?
--
You are receiving this mail because:
You are watching all bug changes.
[korganizer] [Bug 374780] Huge memory usage just for the calendar with korgac and ical resource
https://bugs.kde.org/show_bug.cgi?id=374780 --- Comment #2 from ederag --- Created attachment 109701 --> https://bugs.kde.org/attachment.cgi?id=109701&action=edit illegal type for property: VALUE=DATE-TIME Here is a clue: there were a lot of X-LIC-ERROR: RDATE;VALUE=DATE-TIME:19230527T23 X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DATE-TIME X-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR:Got a VALUE parameter with an illegal type for property: VALUE=DATE-TIME kquitapp korganizer, kquitapp korgac akonadictl stop removing them with kwrite search/replace mode "Escape sequences" (on a single line, without quotes) "\nX-LIC-ERROR;X-LIC-ERRORTYPE=PARAMETER-VALUE-PARSE-ERROR: Got a VALUE \n parameter with an illegal type for property: VALUE=DATE-TIME" replace: empty =>between 7000 and 8000 replacements... akonadictl start korganizer korgac memory < 170 MB As a check, brought back the previous std.ics. => 2GB. New one => fine. Unfortunately, each time akonadi is started or stopped, a new X-LIC-ERROR appear. (one for each RDATE;VALUE=DATE-TIME line) >From this rate, it seems that the problem started less than 2 months ago. System: openSUSE-Leap-42.2 The last update for kdepim was 5 months ago. https://build.opensuse.org/project/show/openSUSE:Leap:42.2:Update Maybe the last daylight change, about 2 months ago ? the RDATE;VALUE=DATE-TIME:19230527T23 format seems valid though https://www.kanzaki.com/docs/ical/rdate.html The years are weird (1923 ?), but removing those RDATE lines make all December appointments shift by 1 hour for instance. So they seem efficient somehow. head_18105ca.ics, which contains only the VTIMEZONE, is enough to reproduce the behavior. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 283682] KMail duplicates filtered messages
https://bugs.kde.org/show_bug.cgi?id=283682 ederag changed: What|Removed |Added CC||ed...@gmx.fr -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 349756] [patch] Run in terminal
https://bugs.kde.org/show_bug.cgi?id=349756 --- Comment #4 from ederag --- Don(In reply to Nate Graham from comment #3) > Hello ederag, > I'm sorry for the very long response time! We are still interested in this > patch; please use git to generate it, and submit it on > http://phabricator.kde.org/. If you need any additional assistance, I'd be > happy to provide it to the best of my ability. Done, phabricator accepted the patch easily. https://phabricator.kde.org/D9244 Thanks for your interest. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 397704] KIOExec: A folder named .cache/kioexec/krun/_0/ already exists.
https://bugs.kde.org/show_bug.cgi?id=397704 --- Comment #5 from ederag --- > firefox "%u" solved it. Not quite: urls are opened twice. firefox opens a new window, with two tabs holding the same urls. Removing the "%u" (i.e. back to the previous buggy state), the urls open normally, just once, in an already existing window. looks like a [2009 thread](https://forum.kde.org/viewtopic.php?t=39446). -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 398495] New: impossible to bring an imap folder online
https://bugs.kde.org/show_bug.cgi?id=398495 Bug ID: 398495 Summary: impossible to bring an imap folder online Product: kmail2 Version: 5.7.3 Platform: openSUSE RPMs OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: ed...@gmx.fr Target Milestone: --- An imap folder is offline, and impossible to bring back online. Update this folder> "Before syncing folder it is necessary to have the resource online. Do you want to make it online?" > Go Online org.kde.pim.akonadicontrol: Agent instance with identifier "akonadi_imap_resource_0" does not exist org.kde.pim.akonadicontrol: Agent instance with identifier "" does not exist org.kde.pim.akonadicontrol: Agent instance with identifier "akonadi_imap_resource_0" does not exist akonadictl restart does not solve anything. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 398495] impossible to bring an imap folder online
https://bugs.kde.org/show_bug.cgi?id=398495 --- Comment #2 from ederag --- looking further into it, two files were excluded from my synchronization setup. On the buggy desktop they were missing imap informations in agentsrc and mailtransports: .config/akonadi/agentsrc -akonadi_imap_resource\InstanceCounter=0 +akonadi_imap_resource\InstanceCounter=1 +akonadi_imap_resource_0\AgentType=akonadi_imap_resource .config/mailtransports [General] -default-transport=1927230780 +default-transport=1338476827 +[Transport 1338476827] +auth=true + ... imap setup stuff ... Now it works, but not tested for long. More relevant for this bug report: the kmail feedback could be improved (instead of just staying off-line), when an imap folder exists without the corresponding Transport. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 384264] Make it possible to disable media controls on lock screen
https://bugs.kde.org/show_bug.cgi?id=384264 ederag changed: What|Removed |Added Resolution|WORKSFORME |--- Status|RESOLVED|REOPENED CC||ed...@gmx.fr --- Comment #19 from ederag --- Any privacy breaking setting should be off by default. The "setting" mentioned in comment #15 is not visible on openSUSE Leap 15 (plasma 5.12.6) After reading https://phabricator.kde.org/D9684, Workspace>Desktop Behavior>Screen locking seemed the place to look at. Is it elsewhere ? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 375730] Starting Kwin with NVidia Proprietary drivers / libraries throws: "Plasma is unable to start as it could not correctly use OpenGL 2."
https://bugs.kde.org/show_bug.cgi?id=375730 ederag changed: What|Removed |Added CC||ed...@gmx.fr -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 323455] "Filter account is missing" after KMail startup
https://bugs.kde.org/show_bug.cgi?id=323455 --- Comment #24 from ederag --- (In reply to Andreas Hartmetz from comment #23) > Draft merge request for KMail, any "compilers" here who can test it? Couldn't compile here last time (https://bugs.kde.org/show_bug.cgi?id=420630); if still needed I can try again this week-end. -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 323455] "Filter account is missing" after KMail startup
https://bugs.kde.org/show_bug.cgi?id=323455 ederag changed: What|Removed |Added CC||ed...@gmx.fr --- Comment #20 from ederag --- Can reproduce every time here, with kontact Version 5.24.5 (23.08.5) shipped with openSUSE Leap 15.6 quit kmail akonadictl stop start kmail popup with Filter account is missing. Please select account to use with filter "um" Hit cancel and everything is fine. "um" is the name of a filter for an IMAP account. Here is its configuration: General> Filter criteria: Match all messages Filter actions: Move into folder: Local Folders/inbox Advanced> Apply this filter to incoming message: From selected account only: Apply this filter on manual filtering Add this filter to the Apply Filter menu Could it be that the corresponding akonadi_imap_resource is not started fast enough ? With `akonadictl start` prior to launching kmail, it's fine (no popup). -- You are receiving this mail because: You are watching all bug changes.
