[rkward] [Bug 473254] Graphics version mismatch
https://bugs.kde.org/show_bug.cgi?id=473254 --- Comment #3 from m.eik michalke --- the package may technically not be out-of-date, it is just not compatible with the R version installed. that is if it still works with the R version shipped with arch and you upgraded R from a third party repo. how did you upgrade R? -- You are receiving this mail because: You are watching all bug changes.
[rkward] [Bug 473254] Graphics version mismatch
https://bugs.kde.org/show_bug.cgi?id=473254 m.eik michalke changed: What|Removed |Added CC||bugs.kde.org@ad.geldunterga ||ng.biz --- Comment #1 from m.eik michalke --- thanks for the report. from the information you provided it looks like your installation of RKWard was built with R 4.2.2 and you later replaced this with R 4.3.1, which also upgraded the R graphics engine from version 15 (compile time) to 16 (runtime). your build of RKWard can't fully handle that newer version, but needs to be recompiled in order to also support R 4.3. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 466851] New: support custom highlighting markers
https://bugs.kde.org/show_bug.cgi?id=466851 Bug ID: 466851 Summary: support custom highlighting markers Classification: Applications Product: kate Version: 22.04.3 Platform: Other OS: All Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: bugs.kde@ad.gelduntergang.biz Target Milestone: --- i would like to see a kate module that adds support for easily customizable highlighting markers in the form of specially formatted comments, with the ability of also defining colors. there's multiple use cases for this. for instance, people working in teams on the same document might like to write comments that others can visually attribute to their authors. also, when i'm working on larger markdown documents or similar, i would like to be able to add comments to myself in various categories, like "check reference" or "add literature". these categories would be highly subjective and even differ from document to document. what i would like to suppose is for kate to recognize a special format of comments that is evaluated when the module is active. an arbitrary example: # ~:check reference: #44bb22 #fff # ~:add literature: #d4bde5 #333 in this example, "# ~:" would mark the beginning of a marker definition, wehre the marker itself is put between two colons, followed by two color definitions (background and foreground). it could also be four colors, with the latter two defining background and foreground of the text that follows the marker when it is used in the document: # check reference: is this year correct? ... # add literature: wasn't there an article by foo & bar? here, the comments begin with previously defined markers and a colon. they should then be colored as defined so you can quickly see them. i imagine that many users would find such a feature helpful. especially if would work independent of the language used, e.g. % ~:check reference: #44bb22 #fff ... i hope this was already implemented and i was just too dumb to find it ;) -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 381366] keep folder specific configuration after adjustements to mail server
https://bugs.kde.org/show_bug.cgi?id=381366 m.eik michalke changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #3 from m.eik michalke --- i currently don't see how i could check this without the risk of losing my configuration again, or setting things up in a new VM which unfortunately i don't have the time to ATM. however, assuming that kmail still behaves the same so the issue persists, i'd propose a different approach to it. currently the import/export dialog for KDE-PIM data only offers a very general selection of data to store. if there was an option to store configuration data on a per-account basis, so that you could export all relevant configuration before changing the server and import your config again, that would do it for me. i'll set this to REPORTED as it is likely still a thing. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 381715] saving sent mail with BCC address loses those addresses if mail is encrypted
https://bugs.kde.org/show_bug.cgi?id=381715 m.eik michalke changed: What|Removed |Added Status|CONFIRMED |REPORTED Ever confirmed|1 |0 -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 381715] saving sent mail with BCC address loses those addresses if mail is encrypted
https://bugs.kde.org/show_bug.cgi?id=381715 m.eik michalke changed: What|Removed |Added Ever confirmed|0 |1 Status|NEEDSINFO |CONFIRMED Resolution|WAITINGFORINFO |--- --- Comment #3 from m.eik michalke --- i have just tested this with kontact 5.20.3, and the bug is still present as described five years ago. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 343186] Timeout trying to get lock on start of kmail
https://bugs.kde.org/show_bug.cgi?id=343186 --- Comment #6 from m.eik michalke --- i no longer face this issue. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 375843] names of akonadi resources in kwallet makes sharing wallets difficult
https://bugs.kde.org/show_bug.cgi?id=375843 m.eik michalke changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #2 from m.eik michalke --- unfortunately, it seems like nothing has changed since i reported the issue five years ago. akonadi still uses mere numbers to identify resources instead of giving them a reproducable name, and i don't find an option to use a specific wallet per application. -- You are receiving this mail because: You are watching all bug changes.
[rkward] [Bug 404431] RKWard crashes when changing the class of an opened object
https://bugs.kde.org/show_bug.cgi?id=404431 --- Comment #5 from m.eik michalke --- (In reply to Matthias from comment #4) > Sorry, my bad. The bug can be triggered with this script: yes, thanks. i can replicate the issue with this code. -- You are receiving this mail because: You are watching all bug changes.
[rkward] [Bug 404431] RKWard crashes when changing the class of an opened object
https://bugs.kde.org/show_bug.cgi?id=404431
m.eik michalke changed:
What|Removed |Added
CC||bugs.kde.org@ad.geldunterga
||ng.biz
--- Comment #3 from m.eik michalke ---
(In reply to Matthias from comment #0)
> STEPS TO REPRODUCE
> 1. Run:
>
> library(likert)
> library(dplyr)
>
> df <- data.frame(x = c("A lot", "Some", "Not at all"))
> df <- mutate(mydata, x_recoded = recode(x, "A lot" = 1, "Some" = 2, "Not at
> all" = 3))
>
> 2. Open df in RKWards viewer
>
> 3. Run "df <- likert(df)
using RKWard 0.7.4z+0.7.5+devel3 with R 4.2, i can't run this code. assuming,
that "mydata" is to be replaced with "df", the call to likert() results in:
Error in likert(df) :
All items (columns) must have the same number of levels
--
You are receiving this mail because:
You are watching all bug changes.
[kmail2] [Bug 459050] New: snippet variable reliably picks middle name instead of family name
https://bugs.kde.org/show_bug.cgi?id=459050 Bug ID: 459050 Summary: snippet variable reliably picks middle name instead of family name Product: kmail2 Version: 5.20.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: composer Assignee: kdepim-b...@kde.org Reporter: bugs.kde@ad.gelduntergang.biz Target Milestone: --- SUMMARY when you use the family name variable in a text snippet for kmail, but the from/to address name consists of more than two text strings, kmail consistently uses the second string for family name. most of the time, this is wrong and picks a middle name (perhaps depends on the language). STEPS TO REPRODUCE 1. add a new text snippet in kmail's mail editor, e.g. call it "family name" 2. from variables, choose "To" -> "family name in To: field" 3. put "first middle last " in the To: field of the new email 4. use the "family name" template (drag & drop or double click) OBSERVED RESULT editor shows "middle". EXPECTED RESULT editor should show "last". SOFTWARE/OS VERSIONS this is the current backports packages for kubuntu 22.04, but this issue is acutally bugging me for years, it's not exclusive to a certain version or setup and likely still not fixed. ADDITIONAL INFORMATION handling addresses in the form of "last, first" also seems to be broken (produces an empty string). -- You are receiving this mail because: You are watching all bug changes.
[rkward] [Bug 454723] RKWard native device fails: R Graphics Engine version has changed
https://bugs.kde.org/show_bug.cgi?id=454723 m.eik michalke changed: What|Removed |Added CC||bugs.kde.org@ad.geldunterga ||ng.biz --- Comment #1 from m.eik michalke --- how did you install RKWard? if you are combining CRAN versions of R with older versions of ubuntu, you must install a version of RKWard that was copiled for your particular R version. to make this easier, we are offering this PPA repository: https://launchpad.net/~rkward-devel/+archive/ubuntu/rkward-stable-cran -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 453121] calender can't connect to nextcloud
https://bugs.kde.org/show_bug.cgi?id=453121 --- Comment #19 from m.eik michalke --- (In reply to m.eik michalke from comment #18) > after that kontact was *instantly* able to fetch contacts and calendars. so > all i'm missing is a way to tell kontact/akonadi to try IPv4 first. i've tried configuring the port forwarding for IPv6, but am still struggling with that (the router has an IPv6 address, but the server i'm trying to reach uses a local IPv4 address and is therefore only available via NAT and the router's IPv4 address). actually, i really think this should be considered a bug. there is a working network configuration via IPv4 that all other clients i tried are able to discover and use without any warnings or errors, only akonadi is now unable to do the same, alltough older versions are also perfectly fine with this setup. i'm ok with preferring IPv6 by default, but if that fails, kontact shouldn't simply give up but try IPv4 as well. i configured /etc/gai.conf so that the system prefers IPv4 over IPv6 globally, but kontact seems to ignore this. if i can't find any solution or at least a usable workaround for this problem, i'm stuck with kubuntu 20.04 on multiple machines, as i can't afford to break contacts and calendars on those, too. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 453121] calender can't connect to nextcloud
https://bugs.kde.org/show_bug.cgi?id=453121 --- Comment #18 from m.eik michalke --- (In reply to m.eik michalke from comment #17) > turns out: using a custom port > an the server behind a NAT router might be the real issue in my case. at > first 'openssl' kept waiting for a response until i aborted the call. i then > tried the '-4' switch to force using an IPv4 address, and that resulted in a > successful connection. TLS connection war ok for both TLS v1.2 and v1.3. > this led me to assume that, while web browsers, the seafile client and > vdirsyncer seem to fall back to IPv4 (because of the explicitly set port?), > akonadi might only be trying IPv6 and doesn't get a response because there's > not NAT. yes, that's really it. i called 'ping -4' on the server and temporarily added it's current IPv4 address to /etc/hosts to resolve the domain locally, after that kontact was *instantly* able to fetch contacts and calendars. so all i'm missing is a way to tell kontact/akonadi to try IPv4 first. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 453121] calender can't connect to nextcloud
https://bugs.kde.org/show_bug.cgi?id=453121 --- Comment #17 from m.eik michalke --- (In reply to Benjamin from comment #15) > - Update nextcloud to the newest release > - Install openssl 3 on the server where the nc instance is running actually, i'm already running nextcloud 24 and the system also uses backports, so iguess that's not an issue. i'm usually not a friend of replacing packages without some proof that that's actually the problem. so i was examining the TLS connection to the server in question using 'openssl s_client'. turns out: using a custom port an the server behind a NAT router might be the real issue in my case. at first 'openssl' kept waiting for a response until i aborted the call. i then tried the '-4' switch to force using an IPv4 address, and that resulted in a successful connection. TLS connection war ok for both TLS v1.2 and v1.3. this led me to assume that, while web browsers, the seafile client and vdirsyncer seem to fall back to IPv4 (because of the explicitly set port?), akonadi might only be trying IPv6 and doesn't get a response because there's not NAT. > > on your desktop: > check out the issue i have posted above maybe there is a different solution > to your problem. > > ...besides: I use backports ppa on my kubuntu to ensure that the newest > packages are installed and updated... > > This is all I can say sofar. > But to be honest: I don't think that the problem is within nextcloud or > serverside. It seems more a problem with akonadi/openssl/kontact (as this > work together)... -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 453121] calender can't connect to nextcloud
https://bugs.kde.org/show_bug.cgi?id=453121 --- Comment #14 from m.eik michalke --- i checked with "akonadictl --verbose start" and don't see any errors regarding "qt.network.ssl", it just shows the HTTP error (0) without any further warnings or errors. i also configured nextcloud to use log level 0 (debug, most verbose) and checked the logs: i don't even see a communication attempt, let alone any errors. there's also nothing logged by apache2. after that, i installed vdirsyncer in my kubuntu 22.04 client and configured it to use the same auth data i was trying to use with kontact. it took quite a while, but i was able to discover and sync both calendars and contacts with vdirsyncer. also, i can see that in the nextcloud logs as expected. any theories why kontact might noch even try to reach the nextcloud server? i am using a custom port (not 443) for HTTPS, is it possible that kontact/akonadi are ignoring it allthough it's given in the URL? -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 453121] calender can't connect to nextcloud
https://bugs.kde.org/show_bug.cgi?id=453121 --- Comment #13 from m.eik michalke --- glad you solved the problem on your side! however, installing libssl-dev didn't solve it for me, i'm still getting the "HTTP error (0)" response. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 453121] calender can't connect to nextcloud
https://bugs.kde.org/show_bug.cgi?id=453121 --- Comment #8 from m.eik michalke --- (In reply to gjditchfield from comment #7) > My second wild guess is that Qt and your browser use different > configurations; > Chrome uses a different SSL library, for instance. that would explain why access via browser is possible. > My third is that the Nextcloud CalDAV server is using a really old > certificate that could be > upgraded, but I'm way outside my knowledge. i doubt that's the issue, at least im running with let's encrypt certs. rather i suspect apache's TLS configuration could be causing this. can anyone suggest how to best debug this, e.g. getting some informative logs of the communication with the nextcloud server to get a hint what's going wrong? the server itself doesn't log any errors; it hardly logged anything, actually, as if it doesn't even get a request. -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 453121] calender can't connect to nextcloud
https://bugs.kde.org/show_bug.cgi?id=453121 --- Comment #5 from m.eik michalke --- (In reply to gjditchfield from comment #4) > I use KOrganizer 5.20.0 successfully with two different Nextcloud servers, > running on KDE Neon (which is basically Ubuntu 20.04). As a wild guess, > perhaps the minimum supported TLS version was raised in Kubuntu 22.04? looks like it: https://askubuntu.com/a/1407781 however, i can login to the same nextcloud server with a web browser without warnings. the same server also runs seafile behind the same apache, and neither the seafile desktop client nor web browser have any problems reaching it. shouldn't these be affected as well? -- You are receiving this mail because: You are watching all bug changes.
[korganizer] [Bug 453121] Flatpak calender can't connect to nextcloud
https://bugs.kde.org/show_bug.cgi?id=453121 m.eik michalke changed: What|Removed |Added CC||bugs.kde.org@ad.geldunterga ||ng.biz --- Comment #3 from m.eik michalke --- i got the same issue with deb packages for freshly installed kubuntu 22.04 (kubuntu backports, kontact 5.20). i have two machines still running kubuntu 20.04 (kontact 5.13.3), both connect flawlessly with the same nextcloud server. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 408272] The default scaling method should be "Fit to Full Page"
https://bugs.kde.org/show_bug.cgi?id=408272 m.eik michalke changed: What|Removed |Added CC||bugs.kde.org@ad.geldunterga ||ng.biz --- Comment #10 from m.eik michalke --- i'm using okular 1.10, and it looks like not much has changed, so i would like to draw some attention on this issue again. my problem is that i often have to print letters for use with windowed envelopes. everytime i forget to adjust the default setting for each of these printing jobs, i end up with paper waste because okular downscaled the pages so that the address field doesn't fit the window. i wouldn't put too much effort into the debate over a best default, but instead just make these defaults *configurable*. personally, i don't have any use for the current default at all and must adjust settings all the time; maybe others have. please let them decide what they need per default. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 428431] New: support the "memory hole" spec to encrypt/decrypt mail headers
https://bugs.kde.org/show_bug.cgi?id=428431 Bug ID: 428431 Summary: support the "memory hole" spec to encrypt/decrypt mail headers Product: kmail2 Version: 5.13.3 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: crypto Assignee: kdepim-b...@kde.org Reporter: bugs.kde@ad.gelduntergang.biz Target Milestone: --- for a long time, thunderbird + enigmail offer a feature to move certain mail headers to the encrypted mail body. that way, it was possible to hide information like the mail subject (it's replaced by "..."). with current versions of thunderbird 78, this feature became mandatory for OpenPGP encrypted mails and cannot be disabled. this currently can create a mess in your inbox. STEPS TO REPRODUCE 1. have someone send you an OpenPGP encrypted mail using thunderbird >= 78 OBSERVED RESULT kmail shows the subject as "...". when the mail is decrypted, you find the missing headers at the top of the mail body. in grouped folder view, all messages sent by thunderbird users form one huge thread with subject "...", it is literally impossible to quickly find mails or even a particular mail thread. EXPECTED RESULT kmail should be able to replace the hidden subject with the actual one. it should also be able to keep the memory hole format in replies. ADDITIONAL INFORMATION i personally wouldn't want to use such a feature. but in order to be able to communicate with people who are unable to disable it, kmail should support it so that you can get human readable subject lines back. here's the spec: https://github.com/autocrypt/memoryhole/blob/master/specs/draft-memoryhole.md -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 353317] kMail 5.0: Wrong signature issuer shown for OpenPGP signed mails (SMIME not tested).
https://bugs.kde.org/show_bug.cgi?id=353317 m.eik michalke changed: What|Removed |Added CC||bugs.kde.org@ad.geldunterga ||ng.biz Ever confirmed|0 |1 Version|unspecified |5.13.3 Status|REPORTED|CONFIRMED --- Comment #2 from m.eik michalke --- i can replicate the issue, i.e., i actually just ran into the same thing, using kmail 5.13.3. this should be considered as a security issue, as someone can be tricked into believing an e-mail came from a certain person when it actually did not. this probably was less of a problem in 2015, but today web key directory support (which is a good thing!) automatically imports available OpenPGP keys into your keyring as soon as you have a fitting mail address in the To: field of the editor (you don't even have to send a mail). even if those addresses aren't signed by you, here's a potential for confusion. kmail should always verify that the sender address is a valid identity of the OpenPGP key used for signing. i would also add that info to the details. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 423794] 'kmail --identity' doesn't set the identity's sent folder
https://bugs.kde.org/show_bug.cgi?id=423794 --- Comment #2 from m.eik michalke --- i can confirm the problem is also solved in kmail 5.13.3. i do agree that 5.7.3 is pretty old. however, users of widely used distros like kubuntu 18.04 LTS will continue to run KDE plasma 5.12 LTS and older versions of kontact for some more years, so it is probably still worth backporting the patch. that is because storing outgoing mail on a wrong IMAP server can quickly become a serious privacy issue (GDPR), especially if it happens unnoticed. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 423794] New: 'kmail --identity' doesn't set the identity's sent folder
https://bugs.kde.org/show_bug.cgi?id=423794 Bug ID: 423794 Summary: 'kmail --identity' doesn't set the identity's sent folder Product: kmail2 Version: 5.7.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: misc Assignee: kdepim-b...@kde.org Reporter: bugs.kde@ad.gelduntergang.biz Target Milestone: --- SUMMARY when i'm composing new mails on the command line including the '--identity' option, it looks like the identity was successfully selected when sending. however, sent mails are still being stored in the sent mails folder defined with the default identity, not in the folder the selected identity should use. STEPS TO REPRODUCE 1. generate a mail with 'kmail --identity ...', selecting a non-default identity 2. send the mail 3. examine the sent mails folders of the chosen identity and the default identity OBSERVED RESULT mails reliably end up in the default sent mail folder. EXPECTED RESULT sent mails should be archived in the respective folder of the chosen identity. SOFTWARE/OS VERSIONS Linux/KDE Plasma: kubuntu 18.04 (available in About System) KDE Plasma Version: 5.12.9.1 KDE Frameworks Version: 5.47.0 Qt Version: 5.9.5 -- You are receiving this mail because: You are watching all bug changes.
[Akonadi] [Bug 401198] kmail fetches new mails twice
https://bugs.kde.org/show_bug.cgi?id=401198 --- Comment #1 from m.eik michalke --- my workaround stopped working. i am losing mails on a daily basis! there are two choices: either i leave the duplicate mails in the folders, in which case akonadi is stuck and doesn't fetch new mails. or i remove duplicate copies from the folders and restart the account, which now causes kmail to remove *all* new mails from the folder completely. if i'm lucky, i have copies in the trash. this is totally unusable, please fix this. -- You are receiving this mail because: You are watching all bug changes.
[rkward] [Bug 403706] RKWard crashes on startup
https://bugs.kde.org/show_bug.cgi?id=403706 m.eik michalke changed: What|Removed |Added Status|REPORTED|RESOLVED CC||bugs.kde.org@ad.geldunterga ||ng.biz Resolution|--- |NOT A BUG --- Comment #1 from m.eik michalke --- you need RKWard >= 0.7.0 for R 3.5, and it must be compiled for the R version you're actually running. please see https://rkward.kde.org/Binaries_and_Build_Scripts for more detailed information on this. -- You are receiving this mail because: You are watching all bug changes.
