[kdenlive] [Bug 399730] Segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
https://bugs.kde.org/show_bug.cgi?id=399730 ocumo changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |WORKSFORME --- Comment #7 from ocumo --- I just switched to Appimages, and haven't seen this particular error with those. It's been long time and that's now a very old version, I cannot test it any longer. I am changing the status to RESOLVED/WORKSFORME. Thank you so much for this excellent FOSS software. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396675] Could not save - Failed to save the annotations for layer ...
https://bugs.kde.org/show_bug.cgi?id=396675 --- Comment #10 from ocumo --- _ Argumentum ad hominem "A fallacious argumentative strategy whereby genuine discussion of the topic at hand is avoided by instead attacking the character, motive, or other attribute of the person making the argument, (...), rather than attacking the substance of the argument itself." (source: wikipedia). Q.E.D. None of what you say challenges the substance of the argument itself. Your intention is solely to offend and punish me because don't like the overwhelming argumentation I presented. According to you, my "offense" seems to be verbosity. But instead of addressing that as a criticism negative or constructively, you opt to demonstrate irrational hatred and distorted reality. In your own words, which unfortunately disprove and discredit yourself: "how you messed up your system" ...which is a lie, without any substance and disproved largely, as you have several times demonstrated it with your own words. It only intends to hurt me, as a person: "That guy messed up his system. What a ..." It is not substantiated in any reasoning that leads unequivocally to that. Or: can you explain, why is that a logical conclusion? Ergo: Ad hominem. "I am closing all reports that you made that are still open." ...just to "hurt me", not because they were fixed. So "let's punish him by hurting our project and the users!". Brilliant strategy. I will wait until you realize you are not "hurting" me. You are hurting your project, your users and your own image and reputation as leader of a relevant project for a big community. Not me. I am still waiting: don't you see it yet? I have time. What about now? Ergo: Ad hominem. The problem does exist, not in "my system". It is a bug affecting your product and your users, like it or not. Users less technically savvy and less resourceful than myself. Forget about me as a person. I am not relevant to you. Let alone the multiple experiments and evidence that can be read by everybody. Just tell them to read your words in your comment here: https://bugs.kde.org/show_bug.cgi?id=392251#c24 . Among many others. But you are trying to deflect from that. By insult. By diminishing me as an incompetent user that "messes up his system", although you have said the exact opposite many times. Deflection does works well as a strategy, but only with non intelligent, ignorant people, as any politician will tell you. But you have revealed your true position, although without justification or honest reasoning: "This is not my bug, it's somebody else's, I won't fix it." Good for you. Bad for krita. Not being right, makes you explode, so: Ad hominem. "Let's insult this guy to scare others that might come like him in the future". Bad news. You don't get to dictate what I do, what I say or where I say it. Anything. That is not how the real world works. bugs.kde.org is not your private property, neither the Internet. Equally grotesque would be me ordering you to refrain from insulting me personally and to stop believing you can give me orders or instructions, or order you to refrain from using fallacies to "argument" against concrete, objective technical issues. I would be delusional if I would think that would work. I will keep demonstrating that I am verbose with very good reasons, if and whenever I want, and you can keep demonstrating what you have demonstrated so concise but eloquently (thanks for that, really). If you would step down of such arrogant position for a little while you might find that there might be others reading your "argumentation" and find it a bit dictatorial and too obviously conveniently deviating the conversation from technically demonstrated issues. But is that how you solve issues in life? Insulting those who disagree with you or that you have offended and bullied previously? I have no idea what makes you think you command masses, but whatever it is, Well, with ignorant, low intelligence audience, fallacy, manipulation and bullying do work like a charm, I give you that. Those eventually end up following and obeying. With intelligent, highly educated people, doesn't work. So, no, I won't "obey your commands" or be intimidated by lies, attempt of bullying, threats and personal insult. Ad hominem. Shame on you. Is your next move to elevate the insulting to major cursing or lies to deflect the substance of the issue? Really you need help, at various levels. An apology wouldn't hurt you and could give better results, improving a little bit the shot you gave on your own foot and in krita project today. A person like that, who doesn't accept any criticism and uses bullying, fallacy, and personal attack as means of terminating a technical disagreement, is seriously incapable of normal, intelligent interaction with highly educated, intelligent audience. Q.E.D. _ -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396675] Could not save - Failed to save the annotations for layer ...
https://bugs.kde.org/show_bug.cgi?id=396675 ocumo changed: What|Removed |Added Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- Version|4.1.0 |unspecified --- Comment #8 from ocumo --- Sadly, this project behaves like a one man's show, despite of what other enthusiastic contexts say, where even big names like Intel or Google are mentioned. The truth is, when the leader is down (for understandable and worrying reasons), there is a huge impact. Not a criticism, it's hard reality, as has been rather rudely expressed several times in comments in bug reports. Some hard facts that don't play nicely about krita's "team" response to this serious issue: 1. Despite overwhelming demonstrations that this problem will (and I bet that it does) affect others in a valid use case, there has been no noticeable interest in this bug. 2. Not only there is lack of user's interest or, more likely, lack of knowledge and stomack for entering the ugly world of bugs reports. The problem extends more importantly to krita's team. "Doesn't affect me? Then too bad." Fact, there are not enough people to even look at what has cost me dozens of hours of troubleshooting and reporting, late at night, making huge efforts to painfully demonstrate a real problem in real case scenario. It is announced in some places that there is a team, but there is only one person looking at this bug report. With indeed only one person looking at this, it is impossible to manage the workload, and one could hardly blame such overwhelmed person, only wish him to take care of his health seriously. This is absolutely insane. 3. I have lost the count of the times I have been told that this is not a krita's code problem. Frankly, it's beyond irritating that such statement would be thrown in a bug report. Who is interested in fingerpointing? How old are we, 6? Who's problem it is that your product doesn't work in a VALID use case? Not a fantasy, not an edge case. A normal case. If krita doesn't recognize the strokes of my toothbrush on my monitor, I won't blame you or open a ticket on Oral-B's customer support or on the supermarket where I bought it for 2.35 Euros. I can't say this clearer or frequently enough: I do not care "who" forgot a semicolon or who wrote an idiotic API or 3rd party program or which criminal manufactures a disastrous piece of hardware. As long as that thing is required and supported by your product, then you own that problem. Your product doesn't work in a __valid_use_case__. If I wouldn't have proven a *valid use case*, I wouldn't be wasting my time here, late at night and with bad health. Why is it so hard to say: "yes, it is _our_ problem, because it affects _our_ product and _our_ users." ? I will never get it. Have you ever had a problem with your new car? would you accept they do nothing because they blame China, which produces such bad aluminium that your engine cracked? What about your stinky smoking "non-polluting" Volkswagen? Whether the root cause is bad Ubuntu, bad KDE, bad Qt, Wacom, Nvidia, bad Goverment, the NSA or climate changes: the only and absolute workable truth is that krita is _the_thing_ that doesn't work in a well documented, normal _valid_use_case_scenario_, demonstrated to exhaustion, literally. I don't see any interest to admit it and _document_ it for the existing and potential users. It seems it isn't interesting except to myself. No matter how moronic Linux, Ubuntu, Debian or Qt might be and how clean and elegant krita's code might be, it is krita's team lack of taking ownership of well demonstrated, well described valid failure modes and not providing vital information in the right places, what deeply frustrates any good intentions and all hard efforts I have made to help. No, it has nothing to do with work load, not after nearly a year of so much discussion and information offered from my side in the same topic. 4. No matter how overwhelming the work load of a one man's show might be, this 8 months late "response" is inequivocably poor and frustrating because you have known the issue and stated that you know the solution since very long time already (https://bugs.kde.org/show_bug.cgi?id=392251#c24) and yet no follow up action was taken to at least inform the users, other than "we need to think" in an obscure comment deep down in a long thread of some bug report more than half a year ago. Please no blame on overwhelming work load and loneliness. That has been demonstrated countless times, not in the kindest manners, which I reckon why, having been myself victim of burnout. So please, don't. I have been in worse situations than that, truly alone and without any resources at all, no Google, no Intel, no money.
[kdenlive] [Bug 406515] Installation or update from PPA fails in Ubuntu 18.04 - libmlt++3 and libmlt6 are too old in ppa:kdenlive/kdenlive-stable repository
https://bugs.kde.org/show_bug.cgi?id=406515 --- Comment #2 from ocumo --- Thank you so much for very prompt response and resolution. As always, also thank you so much for the extraordinary Kdenlive and its Team's hard work. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 406515] New: Installation or update from PPA fails in Ubuntu 18.04 - libmlt++3 and libmlt6 are too old in ppa:kdenlive/kdenlive-stable repository
https://bugs.kde.org/show_bug.cgi?id=406515 Bug ID: 406515 Summary: Installation or update from PPA fails in Ubuntu 18.04 - libmlt++3 and libmlt6 are too old in ppa:kdenlive/kdenlive-stable repository Product: kdenlive Version: 18.12.3 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: Installation Assignee: vpi...@kde.org Reporter: kxk-ocumoatbugs...@lugosys.com Target Milestone: --- SUMMARY This is almost a re-edition of bug #400264, but neither a re-opening nor a duplicate. This one can be easily avoided with a simple correction to the documentation and fixed with a simple step (see below). The first most important part is the "how to avoid" this problem from keep reappearing. The second important thing is how to fix it, see Additional Information below. Issue: In Ubuntu 18.04 is not possible to install (or update to) kdenlive 18.12.3+git201902280143~ubuntu18.04.1 using the official ppa:kdenlive/kdenlive-stable, because required libraries libmlt++3 and libmlt6 in that PPA are too old. STEPS TO REPRODUCE 1. In ubuntu 18.04, install -if never done before- the Kdenlive official ppa:kdenlive/kdenlive-stable, then sudo apt update. 2. sudo apt install kdenlive # OR sudo apt install --reinstall kdenlive if existing installation of previous version. OBSERVED RESULT Error is returned: The following packages have unmet dependencies: kdenlive : Depends: libmlt++3 (>= 6.13.0+git201903302059~ubuntu18.04.1) but 6.10.0+git201810170323~ubuntu18.04.1 is to be installed Depends: libmlt6 (>= 6.13.0+git201903302059~ubuntu18.04.1) but 6.10.0+git201810170323~ubuntu18.04.1 is to be installed E: Unable to correct problems, you have held broken packages. EXPECTED RESULT: Successful installation/upgrade, no error messages. ADDITIONAL INFORMATION 1) First, the _second_ most important thing: how an user can fix this problem (officially). If you have this issue, please add one more PPA with this command: sudo add-apt-repository ppa:kdenlive/mlt && sudo apt update With the official mlt PPA, now you should have access to the up-to-date libraries that are missing in ppa:kdenlive/kdenlive-stable, so you should now be able to install or upgrade kdenlive to 18.12.3+git201902280143~ubuntu18.04.1. 2) Finally, the most important thing: How to avoid this issue from hitting less experienced users. This is a job for the Kdenlive team, and it is very simple. Dear Kdenlive Team: Please, can you fix the instructions in the https://kdenlive.org/en/download/ web page, section "GNU/Linux Packages -> Ubuntu | LinuxMint | Elementary" Currently, and since a couple of years already, it states: "It is recommended to download the AppImage version until the release of Ubuntu 18.04." That sentence has at least two problems: First, it is obsolete because Ubuntu 18.04 has been released since... well, 2018-04. This could be understood as "at this point in time it is OK to use ppa:kdenlive/kdenlive-stable". But... Second: It IS actually OK to use that PPA. But unless you are a magician and guess that there is hidden secret to it in https://community.kde.org/Kdenlive/Development#Pre-requisites_and_Supported_Platforms, you are in for a ride that could bring you to read this bug report or perhaps to write another one similar to it. SOLUTION: The solution is very simple: Fix the Kdenlive website, by remove misleading/obsolete information about Kdenlive installation and replace it with a pointer to a SINGLE, up-to-date source of information. Sounds complicated, but it is not. I suggest this: Please replace the above mentioned incorrect/misleading sentence in https://kdenlive.org/en/download/ web page, section "GNU/Linux Packages -> Ubuntu | LinuxMint | Elementary" and replace it with something like this: "It is recommended to download the AppImage version. If you prefer the convenience of our PPA, please refer to these instructions: https://community.kde.org/Kdenlive/Development#Pre-requisites_and_Supported_Platforms.; Voilá ! You get the idea. Make that obscure link much more visible (why don't you give it a better, more explicit title/subtitle about "Installing via PPA"?) and do not write contradictory/easy to expire/duplicated information elsewhere, just links to the only place which is correct and updated. Something like that should free you from having to maintain more than one place with download/installation instructions. So far, you have at least two bug reports (from my self) on this issue, plus many unnecessary complaints and discussions. This is a Documentation problem that generates Installation problems, and the impact on Installation is bigger and exactly what the user will perceive and rant about in the first place. That's why I filed an Installation bug, although this might generate philosophical
[krita] [Bug 401039] Wrong flatpak installation instructions, install fails; at least two problems at same time
https://bugs.kde.org/show_bug.cgi?id=401039 --- Comment #3 from ocumo --- First of all, thank you very much for taking quick actions. I absolutely agree that this is probably the best solution, given the risks of overloading your limited resources. Just for completeness and clarification of your comment: as I wrote above, "I have notified and provided full details to Krita's team in another report (which is only indirectly related)", and here it is: https://bugs.kde.org/show_bug.cgi?id=392251#c20, including attachment with details, and your reply: https://bugs.kde.org/show_bug.cgi?id=392251#c21 . I didn't say it was a dedicated bug report. The original report in that thread is "only indirectly related" but it *is*, and it is explained there why. I didn't include the above links precisely to avoid entering into a pedantic ping pong of evidences and counter evidences, when the main goal was just to alert the team about an important issue with the documentation. Once again, I do not appreciate or indulge discussing semantics over the issues. I notified a problem, with a big deal of details, in a justified context; I got a main developer's attention, plus a direct reply to the specific issue and attached information. That's it. Not enough? Then the reply could have been specific: "Please do such and such to get this moving forward". No, the reply did not say what else I could/should do. So: The reply wasn't good, but the matter of fact is that the notification went through, to at least one notorious member of the team. So: was my job done? Apparently, not! I sincerely hope that you are not telling me that since I didn't write those words in another separate document with another layer of bureaucracy, is reason enough for you to have dismissed the alert. It's like somebody would yell at me that my house is on fire and I would ignore it because it didn't came in a certified letter. I used to work in a very bureaucratic and huge corporation, and yet nobody would ever dismiss a valid, clear complaint just because it was written in the Form A231b instead of the Form A231B. Why even a huge, slow, heavy corporation would get that and a small non-for-profit project wouldn't? I don't get it. That's probably why I get so cranky about this. My experience in the Kde bug tracking system proves me that my perception of a modern agile mindset is not compatible with older paradigms and bad habits that are still popular amongst many projects. It's getting really painful to contribute. Hopefully things get better in the future. Thanks for all the hard work you guys do, I really respect that. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401039] Wrong flatpak installation instructions, install fails; at least two problems at same time
https://bugs.kde.org/show_bug.cgi?id=401039 --- Comment #1 from ocumo --- Created attachment 116310 --> https://bugs.kde.org/attachment.cgi?id=116310=edit Snapshot of the bad instructions in krita.org download page Attached a snapshot of the bad instructions in https://krita.org/en/download/krita-desktop/ download page, as of 2018-11-14T17:06:50.014Z. It hasn't change since long time. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 401039] New: Wrong flatpak installation instructions, install fails; at least two problems at same time
https://bugs.kde.org/show_bug.cgi?id=401039 Bug ID: 401039 Summary: Wrong flatpak installation instructions, install fails; at least two problems at same time Product: krita Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Documentation Assignee: krita-bugs-n...@kde.org Reporter: kxk-ocumoatbugs...@lugosys.com Target Milestone: --- SUMMARY Instructions in https://krita.org/en/download/krita-desktop/ for installation of Krita via Flatpak are wrong. There are at least to problems: 1. Installation command is truncated/incomplete. Missing location causes error: 'LOCATION must be specified' 2. Even if user manages to discover what the "location" is, the installation command will fail again if the user had done a local flatpak installation: `Unable to load summary from remote flathub: GPG verification enabled, but no summary found (check that the configured URL in remote config is correct)`. This means the bad instructions in the Krita download page assume (and doesn't say it) that the user necessarily has a global installation (thus missing yet another piece in the command), generating such confusing error message that's very difficult for a non flatpak expert to figure out what's wrong. STEPS TO REPRODUCE FIRST PROBLEM 1. Paste the "official" Flatpak Krita installation command from https://krita.org/en/download/krita-desktop/ on a Linux/Mac console and press Enter. flatpak remote-add --if-not-exists flathub OBSERVED RESULT FIRST PROBLEM The following error appears immediately: 'LOCATION must be specified' STEPS TO REPRODUCE SECOND PROBLEM 2. In a system in which the Flapak installation is local (i.e., *not global*), paste the above command but fixed by adding with the missing location: flatpak remote-add --if-not-exists flathub flathub https://flathub.org/repo/flathub.flatpakrepo OBSERVED RESULT SECOND PROBLEM The following error appears immediately: `Unable to load summary from remote flathub: GPG verification enabled, but no summary found (check that the configured URL in remote config is correct)`. EXPECTED RESULT Installation instructions should be correct, they should work and don't generate error messages nor send the user into complicated troubleshooting. ADDITIONAL INFORMATION 1. There is an additional issue that may affect some users. This is not related with Krita's above instructions, it's a Flatpak issue, but I mention it here because it's important and nowhere in Krita's documentation I could find any mention to it: Once installed, the flatpak version of krita fails to automatically recognize and/or use any existing Krita resources/configuration folder, and will create its own, brand new one. This means that users installing krita via flatpak after having installed and configured krita with a different method, will get a totally unconfigured installation and big disappointment if the user is not comfortable making symbolic or hard links, or copying/moving around configuration folders, and the downsides and risks of the different options. 2. Last, but even **more important** that all above: These bad instructions have existed there since long time now and I have notified and provided full details to Krita's team in another report (which is only indirectly related). Reply was that this was some _other_ team's responsibility, not Krita (??..that's odd to me...). Since I didn't get specifics of who, and nothing happened in the mean time, I am opening this report in the hope that someone responsible from the Krita webpages may know who should take ownership for this problem or what to do, if anything. I very much appreciate if -please- this time this problem is not responded again with a "this is somebody else's problem" type of answer. The time I have invested in all these issues is *very* significant and it's not acceptable that such efforts are put down with a procedural/bureaucratic or semantics excuse without an effort to at least provide a positive acknowledge of this collaboration. To be clear: we users, don't really have to or even want to know how a team handles their internal affairs. If you expect that, you will loose credibility, loose support, and we all loose: supporters become detractors. Thanks for kindly understanding this request and taking it positively and professionally, if that's not asking too much. A no answer is better otherwise. I do not want to waste more of my time in this type of argumentations, it's a shame I have been forced to. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 400264] Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic
https://bugs.kde.org/show_bug.cgi?id=400264 --- Comment #7 from ocumo --- Oh, one more important thing, I had to come back and log in again. When I say thanks for prompt reply, I am not saying that what matters is that you fix things immediately. It is a known problem that a big percentage of FOSS developers are near the burnout syndrome. You do not have or should have to put your health at risk for any project. While users get happy their issues get resolved immediately, that should not be expected or demanded: a burnout is a very serious issue. I know what it is. I would have been very happy if you would have just acknowledge the problem and explaining it would take some patience because of work load. I would never support people demanding for quick fixes. So please, your health and private life are priority number one. Anybody not understanding that, doesn't deserve to be listened to, or work for, ever. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 400264] Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic
https://bugs.kde.org/show_bug.cgi?id=400264 --- Comment #6 from ocumo --- (In reply to Vincent PINON from comment #5) Thank you very much for very prompt and honest reply and actions taken. I have seen few minutes ago, on doing the daily update of my system, that the libmlt++3 and libmlt6 where ready to be updated to the 6.10 version, so I immediately did install Kdenlive successfully, no issues. I also had previously tested the appimage and managed to complete some work, although with some issues, but nothing as serious as the one you have fixed. Unfortunately I have been quite busy with other things so I am not able to make more thorough tests or comments. Let me clearly express my gratitude for your hard work and quick response. And that extends to @Nate Graham, without any doubt. Yes, I have reacted firmly to an initial misfortune comment, but in no way I have been unpolite or incorrect. I have the utmost respect for people who take their projects seriously and now you are demonstrating with actions a very professional response. That's very important to me, more than any code being perfect, because that will never exist. Risking repeating myself, I always think of users that have less knowledge, or less experience and are unsure or afraid of going through some of these bumps, that sometimes may put all sides on their toes and test patience and understanding. I feel the pain of those who depend on a "computer guy" to help them fix their issues. So while I have some resources that allow me to, if not fix, at least navigate through the "computer" issues, including arguing with developers more experienced and qualified than me, I cannot stay indifferent to posts like I have seen in some forums about same issue and unfair replies. What matters is, as far as I can tell, this issue has been reported promptly and also fixed promptly and users can now install Kdenlive in Ubuntu 18.04 using the Kdenlive PPA, so that makes my day. Thanks again! -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 400264] Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic
https://bugs.kde.org/show_bug.cgi?id=400264 --- Comment #4 from ocumo --- (In reply to Nate Graham from comment #3) > Ah, I missed that you were installing via the PPA. The PPA is indeed owned > by the Kdenlive developers, so it's appropriate to keep this open. > > I understand that you're frustrated, but let's try to keep the attitude to a > minimum. Thanks for the prompt reply. I totally agree that we have to keep it nice. Not only here, everywhere. There is also such thing "action and reaction". My remarks are assertive, not disrespectful, because the reply was crying for an assertive remark. I did say and repeat now that this is not about persons, it is a technical thing about code, and my report is about code and the impact of code on normal users, and I will keep it in that scope. That doesn't mean that a nonsense, not applicable, copy/paste reply that has all the characteristics of "not my fault, look elsewhere" doesn't deserve an assertive reaction, and as said in my comment, it can only be explained two ways: either a silly mistake (which seems to have been the case) or a questionable practice that is far too common in certain bug trackers on this Planet (and yes, the pun is intended: action and reaction, which is what we should try to stop). I would be delightful to prove with embarrassing evidences that what I am saying is dramatically true, but not in this thread. This bug tracker is one of the most blatant examples in my favor, but not exclusively, sadly. So while I support the use of more sugar and less vinegar, I also have to highlight that there is a good portion of the later in your comments. But to re-focus in what matters: 1. I appreciate that you recognize that I am right. This means the report is correct and valid and thus it should be processed appropriately. 2. Users that care to spend a big amount of time to produce bug reports and investigate things and follow up on FOSS programs, do so because they are committed to the project in their own way and that has also big costs for them. So it's not only the efforts of the devs. It is also the sacrifices that many users do in going through this type of things. It is dramatic that most users don't know how to or are afraid of trying reporting anything because the rule is, specially in certain bug trackers, that they are going to get either a patronizing or an evasive or yet a confusing mambojumbo dev talk about some procedural thing (equivalent to "lawyer talk") to deviate from what matters: The USER'S experience. 3. I have had so many bad experiences with Kdenlive that if I would open a bug report for each one I would get crazy. But when I decide to sacrifice a big portion of my time in order to help the developers (I program too) but most specially the USERs, the last thing I need to get through is enter in a discussion about bad attitudes or much less about semantics of what bugtrackers of the planet say an English word means. That is relevant for the owners of the project, but not at all for users. If users are treated as developers, then it's better not have bug trackers at all. Not everybody is a dev, same as not everybody is a lawyer. Though I am a developer, I have had my own bugtrackers and I know what does it mean to me when I RESOLVE something. But that is not relevant, it's NOT about me and I shall not discuss semantics here and ignore the real issue. Thanks again for rectifying your initial reply, I remain available for helping if and as I can, even if it is a small contribution. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 400264] Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic
https://bugs.kde.org/show_bug.cgi?id=400264 ocumo changed: What|Removed |Added CC||j...@kdenlive.org -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 400264] Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic
https://bugs.kde.org/show_bug.cgi?id=400264 ocumo changed: What|Removed |Added CC||vpi...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 400264] Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic
https://bugs.kde.org/show_bug.cgi?id=400264 --- Comment #2 from ocumo --- (In reply to Nate Graham from comment #1) > Since it's a distro packaging problem, there's unfortunately nothing we can > do about it here in KDE. You'll need to find another way to report this to > the Ubuntu folks. Since Launchpad isn't helpful, I would recommend filing a > Phabricator ticket (https://phabricator.kde.org/maniphest/task/edit/form/1/) > and tag "Kubuntu". Thanks! NO. This reply is unacceptable. The Launchpad page does not belong to "Ubuntu" or "Kubuntu" folks. It belongs to Kdenlive. The names of the owners is listed there, they are Kdenlive folks, not Canonical or anybody else. For courtesy I am not listing here those names because this is not personal. But it's not a secret, it's public and don't force me to make this about people's names. This type of reply is not new. I have seen this practically copy/paste even in your forum. And again, it's very annoying, not say a bit on the limits of what's honest, to not assume responsibilities and throw users in a crazy direction. If me or any other user starts opening bug reports in the wild nobody will take ownership of something that it's not theirs. This is either a plain and silly mistake, or a very irresponsible and insulting way of "RESOLVING" issues. By the way the issue is NOT mainstream, it is NOT resolved and I have marked reopened. I would like a reply from one of the members of the Kdenlive team that are active in the Official Kdenlive Launchpad project page, or a very clear and credible explanation of why there would be common names in both Kdenlive and Launchpad Official Kdenlive PPA projects. Coincidence? What is Kdenlive interest in have a PPA with broken packages and then deceptive communication with users to avoid debugging? Who is responsible for this? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 400264] Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic
https://bugs.kde.org/show_bug.cgi?id=400264 ocumo changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|DOWNSTREAM |--- -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 400264] New: Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic
https://bugs.kde.org/show_bug.cgi?id=400264 Bug ID: 400264 Summary: Installation fails in Ubuntu 18.04 - Depends on library from the future (libmlt++3 and libmlt6) unavailable in Bionic Product: kdenlive Version: 18.08.2 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: Installation Assignee: vpi...@kde.org Reporter: kxk-ocumoatbugs...@lugosys.com Target Milestone: --- SUMMARY The installation of Version: 4:18.08.2+git201810211954~ubuntu18.04.1 for (XK)Ubuntu 18.04 "Bionic" fails, with these errors: Depends: libmlt++3 (>= 6.10.0+git201810170323~ubuntu18.04.1) but 6.6.0-1build1 is to be installed Depends: libmlt6 (>= 6.10.0+git201810170323~ubuntu18.04.1) but 6.6.0-1build1 is to be installed Note that the regular Ubuntu repositories do not provide the libmlt6 or libmlt++3 v6.10 or greater for Ubuntu 18.04, as such version exists for Ubuntu Cosmic. So this is obviously a packaging problem. STEPS TO REPRODUCE 1. Install the Kdenlive official PPA, then sudo apt update. 2. sudo apt install 3. Error is returned. OBSERVED RESULT The following packages have unmet dependencies: kdenlive : Depends: libmlt++3 (>= 6.10.0+git201810170323~ubuntu18.04.1) but 6.6.0-1build1 is to be installed Depends: libmlt6 (>= 6.10.0+git201810170323~ubuntu18.04.1) but 6.6.0-1build1 is to be installed Recommends: dvdauthor but it is not going to be installed Recommends: recordmydesktop but it is not going to be installed E: Unable to correct problems, you have held broken packages. EXPECTED RESULT The installation of the ubuntu package for Bionic is successful with no errors on any Ubuntu Bionic system which is properly updated. SOFTWARE VERSIONS KDE Plasma Version: plasma-desktop 4:5.12.6-0ubuntu0.1 KDE Frameworks 5.44.0 Qt 5.9.5 (built against 5.9.5) The xcb windowing system ADDITIONAL INFORMATION Because the problem is with the packaging, which is hosted in Launchpad, I tried to create an error report in Launchpad. Turns out the Launchpad page specifies that bugs should be reported to the KDE bug tracking system, which is why I am doing. Indeed, the Launchpad page of this project does not allow to create bugs. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 399730] Segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
https://bugs.kde.org/show_bug.cgi?id=399730 --- Comment #5 from ocumo --- One additional comment in separate post. (In reply to emohr from comment #3) > 2. Linux ecosystem/derivate -> The Dev team going to thinking about to have > only 1 or 2 download types (AppImage / Flatpack). The tragic thing is that on one side alternative package system like appimage/flatpak/snaps (or even others) is that the "medicin", the "remedy" becomes an illness. Why? because now devs have to deal not with one universal systems (the dream), but with _many_ "universal" systems. So: what a dev does? But more important than devs are... users. Yes, without users, there are no projects, without projects, programming is only for personal fun (until your wife/mother/partner throws you out of home). Any dev that ignores that is a monumental fool and should change her/his life, perhaps to planting lettuce or something else, I don't know. Art without public is useless and futile. My point is: I don't think it is an intelligent move to abandon the Debian/Ubuntu/Mint/etc. ecosystem package system. It's not about equality/democracy, etc. It is about practicality and pragmatism. What is the most popular, successful, technically superior packaging system of all times in Linux? I am sorry, but FOSS is a meritocracy. It's the... Debian packaging system, by far, far, far, far away. It only takes a couple of hours of deep investigation to become absolutely overwhelmed by the undeniable stability and superiority of the Debian packaging system. Period. How many packaging systems have Suse, Red Hat and others tried in the last 15 years? I can't even start to remember the name of whatever is today the command line to install a package in some of those. It's a matter of consistency. Consistency means stability. Stability is what people trust, at the end of the day. I am not talking about minorities. Not everybody wants really to be experiencing every other year some distro that may die or may decide to revolutionize once again their installation system. As for the "universal" solutions: well, ...they are not without problems. I am struggling since so many months to demonstrate why certain appimage is being built somehow wrongly for one of my favorite and most useful programs and though huge evidence, countless hours of experiments, reports, suggestions, etc., all I got so far is "doing it differently may break things for more people". Meanwhile, their ubuntu PPA repo offers so far a version that runs absolutely fine for all. If they would say that they are planning to switch to only appimage they will kill me and many others like me because their appimages fail catastrophically with professional hardware. Is that a solution to anything? They would push away people with fancy hardware, which would be suicidal. So Kdenlive will decide whatever they want. But I have also tried several flatpak "solutions" and it is not all fancy and dandy. It is a much more complicated and convoluted process and it is also by good measure an inferior method than appimages. Not because I say, but because countless credible, independent people with merit demonstrate. Again, take some time of Google time and critical mindset without emotions, to get to the same conclusion. Don't take my word for it. Use your own impartial criteria. Bottom line for a dev today? Either don't offer compiled packages and wait until "the next thing" is invented, or... bite the bullet and stay with the winning team: bet on the stable, solid and most popular solution. A winning team should not be changed just for fun. Keep Debian family on top of your list, not second. The, second place, I would definitely bet on appimage if you don't want to go for RPM packaging. On top of the rest of the pack, Arch and Gentoo, although those have their own special ways. This is not emotional, cannot be. Be practical: how many users you want to impress and get loyal to you: are there more Fedora users than Debian/Ubuntu family? what about Suse? what about Damn Small Linux? -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 399730] Segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
https://bugs.kde.org/show_bug.cgi?id=399730 --- Comment #4 from ocumo --- (In reply to emohr from comment #3) Thank you indeed for your prompt reply and understanding. I will try the appimage as you suggest. It might take me a little while, though, since I am currently quite busy with studying for a hard exam/interview. However, let me already provide yet another important but frustrating news about Kdenlive. I have just seen that this morning finally there has been released the Kdenlive package Version: 4:18.08.2+git201810211954~ubuntu18.04.1 for ubuntu 18.04 in the Kdenlive PPA repository. It's only 12 hours old. I immediately tried to install it, (although I shouldn't because of priorities). The excitement died immediately. The installation of Version: 4:18.08.2+git201810211954~ubuntu18.04.1 for Ubuntu 18.04 fails because kdenlive: Depends: libmlt++3 (>= 6.10.0+git201810170323~ubuntu18.04.1) but 6.6.0-1build1 is to be installed Depends: libmlt6 (>= 6.10.0+git201810170323~ubuntu18.04.1) but 6.6.0-1build1 is to be installed In Ubuntu 18.04, the libmlt6 package, (required by libmlt++3) is an older version than the one required by libmlt3++. So the required libmlt6 v6.10 or greater, is what exists for Ubuntu 18.10. In other words, a mess with the package. Neither the PPA, nor the regular ubuntu repositories have the libmlt6 v6.10 or greater for ubuntu 18.04, so this is again another failed attempt. I hope that this mistake in the packaging gets fixed before other people with less knowledge or experience will fall into this trap and start ranting yet more about the Kdenlive project. Thanks again for all your support! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita appimages crash or hang when using touch on a wacom cintiq touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #22 from ocumo --- (In reply to Boudewijn Rempt from comment #21) > We don't support the flatpak version ourselves, and it's up to the people > maintaining the flatpak to update us when they change how flatpaks are > installed. Yeah, but you guys certainly do care that whatever shows up in Krita's webpage is not wrong, wouldn't you? I hope the missing/truncated part of your sentence is "...so I will of course ask them to check and fix that as soon as possible, thanks for catching that one mate!" Is it? Otherwise, it doesn't take much to prove, for example, that 'flatpak remote-add --if-not-exists flathub' is not a valid command and will fail; in case my report is not convincing, the man page should suffice. So... Seriously?? What would be the point on, knowingly, keep incorrect installation instructions on the download page of the product that takes so much effort and money to put together? Somebody else's problem? I don't get it. I'm just trying to report a problem on the Krita webpage, to the Krita developers, on something relevant to this thread. I though you guys, Krita owners, should be the natural choice. "The people" and "they" are too vague for me. But hey. Still: Would it be somehow possible to kindly forward this information to someone who could do something to fix wrong information in the official Krita download webpage, where potential Krita users will have trouble with bad instructions? I mean, I don't need it for myself any more, I've had my bad experience and frustrations already. I thought other people, less savvy with computers, should be saved from that "User Experience" (pissed users === detractors of your project). Sorry, this time I catastrophically fail to see or understand your position on this. In this case, it's _not_ about whoever creates flatpaks or whatnot: it's about *Krita users* using Krita official documentation that is wrong, whoever wrote it. As user, I don't care if it was Bob, Jane or Alice. It says "Krita" all over the place. Users are the reason of your (or any) project. Without them, no project. Users don't have any business in the innermost administrative details of who is assigned what or who steps/doesn't step on who's toes, etc. That's how laundry works at home. It's far, far too much beyond what any user needs or wants to know. Sadly, this reminds me of Public Services where one asks at the Information Counter about something and they redirect us to another Information Counter in which we can ask where to find information on who may have information about the proper Information Counter. I hope I am wrong, but that's how it looks to me. Please show me how incredibly wrong I am, and I will fully retract all the rants. Anyone, please ? > I don't have access to a cintiq with this particular touch functionality, so > I cannot test what's up with it, all I could think of is not shipping libxi, > but I fear that that would break appimages for everyone. I totally understand. I can only say that I maintain my humble offer of contribution. If you would like to try some isolated experiments, please by all means let me know if I can help in any way. This is _not_ about me, though. We are talking about one of the top models, professional class, most popular and arguably the best brand on its business. The point is not Wacom. It's its users. Not me, in particular. I can always find my way with other solutions if necessary, FOSS or not. It's the "top professional" ones. Anyone who is _really_ serious about digital illustration business, won't survive with a BambooFun tablet, period. They do use the big toys, as it's public. I don't think Krita is meant to be exclusively for hobbyists, poor students or people who can't afford and won't use pirate copies of Adobe/Corel products. It's for all. Fully supporting some of the top Wacom devices, the most popular amongst professionals, should be just a natural goal for Krita. And removing any annoyances that disturb that goal should therefore be equally important. Any serious professionals googling for "Krita + Wacom Cintiq 27QHD" would get to this thread. I hope they understand that it is possible and don't get frustrated with my experience. If Krita could have one of those giant professional names we all admire (Aaron Blaise, Jason Seiler, Mike Luckovich, why not?) acknowledging and endorsing this project, we all would be very happy. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita appimages crash or hang when using touch on a wacom cintiq touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #20 from ocumo --- Created attachment 115761 --> https://bugs.kde.org/attachment.cgi?id=115761=edit Problems with the installation of the flatpak version of krita 4.1.5: Documentation issues and other In the attached file, I am detailing a number of problems faced when installing the current release of krita (4.1.5) using the Flatpak method. This is part of the investigation for the bug in this thread, thus the need to put this here, despite the fact that this opens new problems not directly related to the current bug. The relevance of this report about the Flatpak method, is that the Flatpak is an obvious and valid alternative to the appimages, which this thread show that have catastrophic compatibility issues with a very important, professional class hardware (Wacom Cintiq) that krita and Linux otherwise do support. In this case, Flatpaks can provide at the very least a fallback solution to broken appimages and/or the kritalime PPA has not been updated, among other scenarios in which users prefer/have to use Flatpak in their systems. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita appimages crash or hang when using touch on a wacom cintiq touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #19 from ocumo --- I have been testing the flatpak installation of krita 4.1.5 for several minutes. The good news is that the flatpak version does NOT have the crash/hangup issue. Though I need to test more, it clearly is not failing as with the appimage versions, and touch functionality works exactly as with the kritalime PPA version (not perfect, but quite good). This seems to confirm that definitely there is something not well with the appimages 4.x.x, because neither 3.x.x appimages nor kritalime PPA installations, nor flatpak 4.1.5, have any of the reported problems. The bad news is that the installation instructions of flatpak in the https://krita.org/en/download/krita-desktop/ webpage are wrong and incomplete, and even the instructions in https://flathub.org/apps/details/org.kde.krita fail to provide important information. There is, in addition, another issue. I will provide an attachment with these notes and details, in my next post, so please I would really appreciate feedback/comments. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 399730] Segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
https://bugs.kde.org/show_bug.cgi?id=399730 --- Comment #2 from ocumo --- (In reply to emohr from comment #1) Thank you for your contribution. Unfortunately, this happens regardless of how up-to-date this system is (updated daily, sometimes twice a day). The good thing about Linux is that it doesn't suffer from the kind of issues one see in certain commercial Operating System since 30 years, in which the switching off and then on again ritual seem to somehow "cure" the oddest bugs. The bad thing about Linux is that there are so many ways to package your source code, that developers end up having a huge ecosystem of distros to package for, and then they fail to properly follow up on all of them. On top of that, some projects also fail to have their main webpages updated. The Kdenlive package that I have installed, is the current version in the Ubuntu repositories. Guess what, it's very dated: v18.04.01, compared to what I see is the latest release (18.08.2). To make things muddier than mud, the Kdenlive download page, in the "Ubuntu" section, says (quote as of the time of this post in https://kdenlive.org/en/download/, 2018-10-19T20:14:18.867Z): "It is recommended to download the AppImage version until the release of Ubuntu 18.04.". Well, two possible comments to that: 1) "Just use the Appimage, why complain?" Or...2) "Ubuntu 18.04 has been released 6 months ago, so I am good to use the normal repo." Now: who is right? We could be arguing for long time, but let's agree on this: If the documentation is confusing/outdated/obsolete... how can users know what is right without double checking every page against other pages, news, blogs, forums or whatever? Turns out there is some "News" page (which other projects call different names or simply don't have) mentions the new releases. I don't care for "news" pages except real world ones. But again: I have hundreds of applications that I need to update, besides the system's. Users seem to be expected to read all the "News" of all their applications, in pure Windows 95, 198x style. But then, since one couldn't trust the documentation anyway, one would be forced to double check through hundreds of webpages. Or... spend spend time writing bugs reports about obsolete things nobody should be using or caring. I am truly sympathetic with the F.O.S.S. developers, I do. But _precisely_ because of that, I know that the best projects are very difficult because they do handle the difficult part (the wild ecosystem) well. Not because they have a lot of resources. But because the do communicate the essential efficiently. If a project doesn't do the basic stuff reasonably, then we get a ridiculous situation like this: A fool writing a bug report on an obsolete package, wasting his and others time, plus polluting the kde bugs system. That's a shame, dear devs. Either update your documentation or don't document at all. You can only maintain or increase your users base if you help them do the basic: install, upgrade in time, not too late. Anything else is irrelevant if this is not done properly, you know? There is no point in offering code without helping people to avoid using obsolete one. Is there anyone around still convinced that basic installation/upgrading documentation is a luxury in the F.O.S.S. world? I am not going to start reading the Kdenlive news every morning together with my real world News sources. And I have not even tried the appimage version, nor I am very excited to try it right now, regardless of the bug existing or not. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita appimages crash or hang when using touch on a wacom cintiq touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #18 from ocumo --- Created attachment 115736 --> https://bugs.kde.org/attachment.cgi?id=115736=edit Installed libx11 related packages Ok, it seems that we need to understand whether the appimage is somehow built with an obsolete/inadequate library, or my system somehow has an inadequate/obsolete or somehow conflicting library. One thing that should be taken into consideration is that whatever you do to build the kritalime PPA version, is done OK and no one, including me, has complaints like this one about the hardware or system I am using with krita. What I can do is to analyse my system as thoroughly as needed to help reducing the scope of this investigation. I can't help with how the appimage is made, though. I can offer for starters, (please see the attached file), a list of all `libx11*` packages installed in my system; it's just the output of the command: `apt list libx11* --all-versions`. On top of that, the following information is relevant: All the installed packages come from the official ubuntu repos, either the bionic-updates or bionic sections. There are neither PPA versions nor manually compiled libraries, these or any others, as I am very careful with global systems files. If I ever have to compile anything, it's never a library or any kind of system files or files that somehow could have global scope. I actually almost never compile stuff and if I must, I would always do it in an isolated scope. Even Python programs that are not official are always enclosed in their specific environment. I know well how bad can it be to troubleshoot incompatible/conflicting dependencies. As for PPAs, I only risk those coming from serious projects, such as Krita. That being said, my interest is not to exclude my system out of the investigation. I certainly may have something bad in it, made some mistake or forgotten something. So, please if you could suggest more checks or system information that could help to simplify the troubleshooting, by all means, do. Important: is there a chance that someone from the appimage building team might also contribute their 5 cents? I also must remind the readers, because it's a long thread, that up to Krita 3.3.3, ALL those appimages work without any issue with my Wacom Cintiq device, even today! All the troubles started with the appimages of the Krita v4.x.x branch, all its versions. Apart from the Krita code: what else changed there? I am not yet convinced (though possible) that this is some kind of unique problem with my system, which is build on official Ubuntu packages on normal hardware. Finally: I don't like Flatpak, or Snaps: they are, by all comparisons I have been able to read online, quite inferior, by many reasons, to appimages. The reason why I would like to work with appimages, is for testing new versions of Krita, otherwise, I would just wait for your kritalime release and forget about it. So far I have seen Flatpak versions only for final releases. I'll try to find some time to test the available Flatpak, if you think that makes sense. Are there Flatpak versions of krita 4.2? In any case, I don't want to quit using appimages, unless Flatpak would work for me and there would be Flatpak versions for the testing Kritas. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita appimages crash or hang when using touch on a wacom cintiq touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #16 from ocumo --- I managed to do a quick test. Not good news. I have attached the outcome. This is exactly what I did: 1. Run the following in the terminal: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 2. Run krita with debugger: dbg ./krita-4.2.0-pre-alpha-539f7d0-x86_64.appimage 3. Create new document. 4. Draw a couple of color lines using the Stylus. Note that the krita pointer was covered by the normal mouse pointer from the window manager. 5. Touch the tablet touchscreen with a bare finger. 6. Krita crashes/hangs as soon as touchscreen is touched with bare finger or sometimes even before that, just while using the stylus to e.g. select some color or resize some panel. 7. Press to get back the gdb promp. Collect the backtrace with this gdb command: thread apply all backtrace 8. Attach the whole krita stdout session from the console, which includes the backtrace. Note that the backtrace command is at line #317, and before that there is info that might be useful. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita appimages crash or hang when using touch on a wacom cintiq touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #15 from ocumo --- Created attachment 115703 --> https://bugs.kde.org/attachment.cgi?id=115703=edit Backtrace and stdout of crash/hangup of krita-4.2.0-pre-alpha-539f7d0-x86_64.appimage Testing krita-4.2.0-pre-alpha-539f7d0-x86_64.appimage with a Wacom Cintiq 27QHD Touch display, in Kubuntu 18.04 (running Xfce). Outcome is not any better than with previous appimage versions, in fact first time the crash/hangup happened probably even touching the display with bare fingers. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita appimages crash or hang when using touch on a wacom cintiq touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #14 from ocumo --- Thank you very much Boudewijn. This is a step forward! I will try the appimage as soon as I can and post here the results. I need to find a bit of time, but I will. Meanwhile, I really appreciate your efforts, I know how much the Krita team is busy in making a very tough work with limited resources. You guys are doing such a great work. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 ocumo changed: What|Removed |Added Version|unspecified |4.1.5 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 ocumo changed: What|Removed |Added Platform|Ubuntu Packages |Appimage --- Comment #11 from ocumo --- UPDATE Problem happens exactly the same in krita versions 4.1.3, 4.1.5 and even in the available preview of krita 4.2, as long as the appimage is used. This means that ALL available appimage versions 4.x.x released or not, including nightly builds cannot be used with a Wacom Cintiq Wacom Cintiq 27QHD Touch display without catastrophic failure. I have updated the report's "platform" field to "Appimage", since the problem doesn't manifest in installations made from the kritalime PPA. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 399730] New: Segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
https://bugs.kde.org/show_bug.cgi?id=399730 Bug ID: 399730 Summary: Segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so Product: kdenlive Version: 18.04.1 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: User Interface Assignee: j...@kdenlive.org Reporter: kxk-ocumoatbugs...@lugosys.com Target Milestone: --- Created attachment 115605 --> https://bugs.kde.org/attachment.cgi?id=115605=edit Backtrace of the Kdenlive crash, includes additional info SUMMARY Kdenlive crashes when attempting to add a clip to a new project. The program just closes abruptly. Reproducible always. STEPS TO REPRODUCE 1. Open KDEnlive and click File -> New 2. In the Project Bin pane, click the "Add Clip" button. The Open File window opens. While browsing through to select some file, Kdenlive crashes unexpectedly. OBSERVED RESULT Kdenlive crashes unexpectedly, the application closes immediately, it's not possible to even get the clip added. EXPECTED RESULT The program should not crash while browsing for a clip to be added to a new project. It should just allow to browse, select a file and add it to the project. SOFTWARE VERSIONS KDE Plasma Version: plasma-desktop 4:5.12.6-0ubuntu0.1 KDE Frameworks 5.44.0 Qt 5.9.5 (built against 5.9.5) The xcb windowing system ADDITIONAL INFORMATION kdenlive version: 4:18.04.1+git201805021218~ubuntu18.04.1 Graphics Processor: GeForce GTX 1050 Ti Nvidia driver version: 390.77 When run via terminal, same problem, and the output to the console includes the following: " ... kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "" kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "" kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "" ERROR: Caught a segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so Please either: - remove it and restart. - run with --gst-disable-segtrap --gst-disable-registry-fork and debug. (kdenlive:3126): GStreamer-WARNING **: 18:31:19.848: Trying to join task 0x7ff510009050 from its thread would deadlock. You cannot change the state of an element from its streaming thread. Use g_idle_add() or post a GstMessage on the bus to schedule the state change from the main thread. (kdenlive:3126): GStreamer-CRITICAL **: 18:31:19.848: Failed to deactivate pad mpegaudioparse0:sink, very bad QObject::startTimer: Timers cannot be started from another thread QObject::killTimer: Timers cannot be stopped from another thread QObject::startTimer: Timers cannot be started from another thread QObject::startTimer: Timers can only be used with threads started with QThread Fatal Error: Accessed global static 'Phonon::FactoryPrivate *globalFactory()' after destruction. Defined at /build/phonon-ZAq3VA/phonon-4.10.0/phonon/factory.cpp:90 KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kdenlive path = /usr/bin pid = 3126 KCrash: Arguments: /usr/bin/kdenlive KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit sock_file=/run/user/1000/kdeinit5__0 [1]+ Stopped kdenlive " The crash can be reproduced every time. IMPORTANT: The KDE Crash Reporting Assistant failed multiple times (as always "unexpected error 143.. protocol died...") So it is impossible to send the report with that thing. So I am creating this manually, which is a very time costing effort. I am adding the backtrace as an attachment. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #10 from ocumo --- - CORRECTION TO MY PREVIOUS POST (ocumo from comment #9) --- > Created attachment 115313 [details] > Hangup backtrace files - three cases > > Attached three backtrace files (...) This system doesn't allow to edit my posts, so PLEASE DISREGARD my post comment #9, which has unrelated information, and instead consider this one: Steps to reproduce and references to the files: Experiment 1 (file: Exp1A_Krita_Hangup_Backtrace.txt) 1. Preparation: Run the following in the terminal: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 2. Run (with dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. At this exact moment, krita crashes/hangs(?). The GUI becomes irresponsive and doesn't refresh any longer. Collect the backtrace (needs to do to get the gdb prompt) and close gdb to kill the hanged krita. Experiment 2 (file: Exp2_Krita_Hangup_Backtrace.txt) 1. If preparation of Experiment 1, step 1 was done, no action needed here. Else, do that. 2. Run krita (dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. It did not crash/hang and zoom gesture was recognized. Draw and do touch gestures, all seem OK. Close the document, but let Krita open. --> Problem will happen now: 6. Open another document. (in our case a trivial krita document (with only few lines) created with krita v4.0.4). 7. Repeat steps 4 and 5. Krita crashes/hangs as soon as touchscreen is touched with bare finger. Collect the backtrace (needs to do to get the gdb prompt) and close gdb to kill the hanged krita. There are indeed three files attached, but only the two mentioned here are relevant. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 ocumo changed: What|Removed |Added CC||kxk-ocumoatbugskde@lugosys. ||com --- Comment #9 from ocumo --- Created attachment 115313 --> https://bugs.kde.org/attachment.cgi?id=115313=edit Hangup backtrace files - three cases Attached three backtrace files corresponding to three procedures, two of which caused hangup/crash, one that did not, as a control. Steps to reproduce and references to the files: Experiment 1 - 1A: (file: Exp1A_Krita_Hangup_Backtrace.txt) 1. Preparation: Run the following in the terminal: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 2. Run (with dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. At this exact moment, krita crashes/hangs(?). The GUI becomes irresponsive and doesn't refresh any longer. Collect the backtrace (needs to do to get the gdb prompt) and close gdb to kill the hanged krita. - 1B: (file: Exp1B_Krita_NOHangup_Backtrace.txt) 6. Open (with dbg) krita v4.1.2 (installed from kritalime ppa) in /usr/bin/krit. NOPROBLEM 7. Open a different krita document created with krita 4.1.1 from kritalime, which has reference images embedded in it. 8. Touchscreen works normally, as this is not an appimage. Draw for a while. 9. Add a reference image to the existing ones. 10. Draw for a while. 11. Save the file: => No problem. [ here it would have given the Error.] 12. Collect the backtrace "Exp1b" and quit krita Experiment 2 (file: Exp2_Krita_Hangup_Backtrace.txt) 1. If preparation of Experiment 1, step 1 was done, no action needed here. Else, do that. 2. Run krita (dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. It did not crash/hang and zoom gesture was recognized. Draw and do touch gestures, all seem OK. Close the document, but let Krita open. --> Problem will happen now: 6. Open another document. (in our case a trivial krita document (with only few lines) created with krita v4.0.4). 7. Repeat steps 4 and 5. Krita crashes/hangs as soon as touchscreen is touched with bare finger. Collect the backtrace (needs to do to get the gdb prompt) and close gdb to kill the hanged krita. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396675] Could not save - Failed to save the annotations for layer ...
https://bugs.kde.org/show_bug.cgi?id=396675 ocumo changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #6 from ocumo --- Changing the status to REPORTED -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396675] Could not save - Failed to save the annotations for layer ...
https://bugs.kde.org/show_bug.cgi?id=396675 ocumo changed: What|Removed |Added CC||kxk-ocumoatbugskde@lugosys. ||com --- Comment #5 from ocumo --- Created attachment 115312 --> https://bugs.kde.org/attachment.cgi?id=115312=edit Hangup backtrace files - three cases Attached three backtrace files corresponding to three procedures, two of which caused hangup/crash, one that did not, as a control. Steps to reproduce and references to the files: Experiment 1 - 1A: (file: Exp1A_Krita_Hangup_Backtrace.txt) 1. Preparation: Run the following in the terminal: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 2. Run (with dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. At this exact moment, krita crashes/hangs(?). The GUI becomes irresponsive and doesn't refresh any longer. Collect the backtrace (needs to do to get the gdb prompt) and close gdb to kill the hanged krita. - 1B: (file: Exp1B_Krita_NOHangup_Backtrace.txt) 6. Open (with dbg) krita v4.1.2 (installed from kritalime ppa) in /usr/bin/krit. NOPROBLEM 7. Open a different krita document created with krita 4.1.1 from kritalime, which has reference images embedded in it. 8. Touchscreen works normally, as this is not an appimage. Draw for a while. 9. Add a reference image to the existing ones. 10. Draw for a while. 11. Save the file: => No problem. [ here it would have given the Error.] 12. Collect the backtrace "Exp1b" and quit krita Experiment 2 (file: Exp2_Krita_Hangup_Backtrace.txt) 1. If preparation of Experiment 1, step 1 was done, no action needed here. Else, do that. 2. Run krita (dbg) krita-4.1.3-x86_64.appimage (or krita-4.1.1-x86_64.appimage). 3. Open some krita document, example: teste.kra (created originally with krita v3.3) 4. Draw a couple of color lines using the Stylus (this is optional, problems happens regardless). 5. Touch the tablet touchscreen with a bare finger. It did not crash/hang and zoom gesture was recognized. Draw and do touch gestures, all seem OK. Close the document, but let Krita open. --> Problem will happen now: 6. Open another document. (in our case a trivial krita document (with only few lines) created with krita v4.0.4). 7. Repeat steps 4 and 5. Krita crashes/hangs as soon as touchscreen is touched with bare finger. Collect the backtrace (needs to do to get the gdb prompt) and close gdb to kill the hanged krita. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396675] Could not save - Failed to save the annotations for layer ...
https://bugs.kde.org/show_bug.cgi?id=396675 --- Comment #4 from ocumo --- I have been trying various ways to reproduce the "Could not save (...) Failed to save the annotations for layer...", without success. The problem is that the original conditions are not met any more: The problem happened with Krita v4.1.0 and in the meantime I had to upgrade to v4.1.2, so this might mean either the problem was related to v4.1.0 OR it takes some conditions that I haven't managed to reproduce (yet). HOWEVER, I did manage to reproduce the second part of the problem and which is already described in bug #392251, and I have captured backtrace for that. I am attaching all that in this thread and also in bug #392251, because I cannot exclude that there might be something useful for BOTH bugs, i.e. something that you can see "should not be happening" that might help in either bug. So please don't close this bug until you have checked the backtrace and confirmed that it doesn't help THIS particular bug. If that is the case, since it can't be reproduced easily, this might need to be closed without a conclusion. Promised Information in my next post below. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 ocumo changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #8 from ocumo --- (In reply to Andrew Crouthamel from comment #7) > This bug has been in NEEDSINFO status with no change for at least 15 days. > Please provide the requested information as soon as possible ... It comes to my attention that this is a standard/automated message, thus its content may not be 100% accurate to this context. I did get back to this thread with all info I could collect, first to the more specific request in comment #1, and second to the more generic request on comment #2. Testing in Kubuntu 17.10 is no more relevant as we are now in 18.04 and things changed, as extensively reported in this thread, so I have provided significant amount of information and even workarounds to this issue and I am the one waiting for info that may help me to provide more help or at least some comment. Therefore, I am setting the bug status as REPORTED, per the recommendations. Thanks -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396675] Could not save - Failed to save the annotations for layer ...
https://bugs.kde.org/show_bug.cgi?id=396675 --- Comment #2 from ocumo --- Thank you for your reply. I didn't collect the backtrace. The one think I can say immediately is that ALL the troubles I have found with krita 4.x are _only_ happening when I use any krita 4.x *appimage* with my Wacom Cintiq display tablet. That is regardless of my system being kubuntu 16.04 or kubuntu 18.04. To make it as clear as possible: 1. It is not possible to use a Wacom Cintiq 27QHD Graphic Tablet in (K)ubuntu 16.04 or 18.04 with any appimage version of Krita >= v4. 2. If Krita v4.x is installed using the kritalime ppa, then it is possible to work, only with a couple of very minor issues, but with no significant issues. So: As soon as I finally was able to use the kritalime ppa and installed krita 4 from there, I confirmed that none of the the worst issues I have been experiencing with the appimage versions happened. But because I have been wasting so much time in trying to eliminate any possible causes from my side, and in the process nearly drying out my adrenal glands of any cortisol they might have left, with no help, you would understand what a relieve I had when I finally found a way to work with krita >= 4 and the Wacom Cintiq tablet. Whether this makes any sense for a bug report I don't know any more, but whenever I try any appimage of 4.x.x, it will crash and/or provoke strange issue as reported in this thread, as soon as I get my bare fingers on the touchscreen. So: yes, I can reproduce the thing. The question is, I would have liked a bit of guidance as to how to proceed, as in another bug report I asked, but unfortunately you guys are overwhelmed with so much work for a small but brave team of talented devs, that I can't expect you to prioritize this request. I do understand that I might be the only person on the planet that spent a few thousand euros on a Wacom Cintiq 27QHD Graphic Tablet to use it with Krita exclusively, and in Linux, although I do have a Windows partition with Photoshop in it. But I rather used Krita v3.x than Photoshop: it's been more than one year since I haven't logged on to Windows and I still think it's not worth doing that. So fixing whatever it is in appimages that doesn't like Wacom Cintiq tablets for only one user doesn't make any sense, especially when the installed versions from kritalime ppa do work reasonable well. Believe me, I am not going to boot any time soon my Windows partition, let alone switching to my (working) Photoshop CC2015. And to anyone interested and wondering: Yes, any cent you would invest in a Wacom Cintiq is absolutely the best investment you would have done in many years! You won't regret. You have to try some day. In Krita (from ppa)! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 ocumo changed: What|Removed |Added Version|4.0 |unspecified -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #6 from ocumo --- For what is worth, just in case anyone having troubles with krita using a Wacom Cintiq and looking for answers, this information, gathered after countless experiments with various versions of krita and Kubuntu, might be helpful: 1. The **appimage** executables for krita versions 4.0.0, 4.1.0 AND 4.1.1 crash/hang when using a Wacom Cintiq 27QHD Touch display as soon as one touches the display with a finger or very soon thereafter, in both Kubuntu 16.04 AND in Kubuntu 18.04 with whatever latest updates. 2. In Kubuntu 18.04, the kritalime PPA installation of krita 4.1 AND 4.1.1 do NOT have the above problem. The touchscreen works (with a minor glitches) AS LONG as the following command is issued before launching krita: xsetwacom -v --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off 3. Enabling OR disabling finger touch painting in the krita settings does NOT have any effect in any krita version 4.x.x so far, appimage OR kritalime PPA installed. The above xsetwacom command remains the only way to allow using touch gestures in the Wacom Cintiq in krita >= 4 in kubuntu 18.04 and older. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 396675] New: Could not save - Failed to save the annotations for layer ...
https://bugs.kde.org/show_bug.cgi?id=396675 Bug ID: 396675 Summary: Could not save - Failed to save the annotations for layer ... Product: krita Version: 4.1.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: kxk-ocumoatbugs...@lugosys.com Target Milestone: --- Could not save /home/user/somefile.kra Reason: Failed to save the annotations for layer Layer 6.. Failed to save the annotations for layer foo.. Failed to save the annotations for layer bar.. File was created from scratch on krita 4.1.0 (installed from kritalime ppa) with Cintiq tablet, all OK. Today v4.1.1 was released on appimage but not on the ppa. Wanted to try v4.1.1, so downloaded v4.1.1 appimage and run it. Open the somefile.kra with the v4.1.1. Touched touchscreen with finger and krita immediately crashed badly. Repeated twice with same outcome. Open krita v4.1.0 (the one installed with kritalime ppa). Touchscreen works normally. Draw for a while. Added a reference image to the existing ones. Draw for a couple of minutes. Tried to save => Above Error. >From this point it was impossible to save, always save error. So I had to close krita and loose what I had done. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #5 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- UPDATE: Krita 4.0.1 release does not change the situation (nor did it claim it, of course). All previous tests produce same results. After many tests, however, I think I can describe the problem in a better way now: I can now confirm, that there is a clear pattern: all points to the Touch function. 1. Crashes are always related with touching the canvas with bare finger(s). Either with documents created in krita 4 itself or krita 3.3.3 and even in the simplest document with default image color spaces, with only two or three brush strokes (any brush). Documents size is always the same: 2000px by 2500px and 300 dpi. 2. For these crashes to happen, at least one condition is needed: The Wacom Cintiq 27QHD touch Finger touch Gesture parameter (from xsetwacom) is set to off. 3. If the The Wacom Cintiq 27QHD touch Finger touch Gesture parameter is set to on (with xsetwacom, as explained before), I cannot reproduce the crashes as described previously. However: touching even barely with __any part of the hand__ on the canvas, will create a paint stroke, *regardless* of what the setting of the "Enable touch painting" setting is. This makes it impossible to work with krita 4 with a Wacom Cintiq 27QHD in (KX)ubuntu 16.04. 4. If the touch gesture parameter is set to off (xsetwacom), touching the canvas with bare fingers will end up in a crash, some times after a couple of minutes of working, but frequently (if not always) immediately if the first touch on the canvas is made with a bare finger instead of with the Stylus. 5. With the exact same system and conditions, Krita 3.3.3 works normally with the Wacom Cintiq 27QHD touch display, with the only exception that the "Enable touch painting" setting does not do anything at all, in both Krita 4.0.0/1 and Krita 3.3.3., which forces the user to issue: xsetwacom --set 'Wacom Cintiq 27QHD touch Finger touch' gesture off ...to be able to work, to have access to gestures (this is counter intuitive!) and not create strokes with every skin contact on the canvas. These questions remain: - Why is it that the "Enable touch painting" doesn't seem to to anything at all, forcing a workaround that seems to enable the crazy crashes in Krita 4 but not in Krita 3.3.3 ? - Why turning gesture OFF with xsetwacom is the only way to *enable* gestures? Shouldn't it be the opposite? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #4 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- (In reply to Boudewijn Rempt from comment #3) > Please get back to us when you've done those tests! I haven't been able yet to test in the Kubuntu 17.10 system, but in the meantime I have installed the Cinnamon package in my main one, just to see if I get any more clues. I launched it from the console, to monitor (and record) the output of the session. At first, it looked promising, since I couldn't crash it with the same sequence of events as described previously for KDE, Xfce or Enlightenment. The happiness lasted only for five full minutes: While drawing, I tried one of my own brushes (nothing special, just a small change on a basic default brush) and I saw this error repeated like 12 times while painting: `Accessing uninitialized random source!` ..so I changed to an 'official' brush and kept drawing for few more seconds and when I tried to zoom in with the touch gesture then Krita hanged immediately; no more response from any input. I was simultaneously monitoring the system with htop: The only value for which I am not sure is the resident memory (RES column) for one of the two krita processes: '1379M', which accounts to 8.6% of my total system's RAM (16GB), according to the MEM% column, so that would be around 1.3GB. The other process shows '2600' (no units) which shows in the MEM% column as 0.0, and frankly is lower than many other processes so because the man pages don't say anything about units, I will have to assume that this is MB or lower unit (I don't get the htop's units logic). As for CPU%, both processes showed 0% at the time it crashed/hanged. I have a snapshot (picture) of htop at the moment of crash, let me know if that's interesting to attach. Also: is this 1.3GB typical/acceptable for the resident memory (htop's RES column) or should I somehow try to focus more in the memory, as Wolthera suggested, perhaps a memory leak? Bottom line, so far: Krita 4.0.0 crashes/hangs in all flavors of desktop environment that I have, when using a Wacom Cintiq touch display. The problem varies in severity: from taking down (freezing) the entire X system in KDE, to allowing to draw some 5 minutes and hang only Krita, with no exact identifiable pattern of what triggers the crash or how to reproduce it, other than (_apparently_) use fingers to interact with krita, as in a zoom gesture (Cinnamon), using the popup palette with fingers (Xfce, Enlightenment) or possibly those or another one in KDE. As I am having more information, I'll update, but for now I definitely am not using Krita 4.0.0 except for these experiments. I can't be more impatient to update my Kubuntu system to v18.04 in the hope that things might be better then. The stable release is supposed to be on the last week of April. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 --- Comment #2 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- Thank you so much, Wolthera. I certainly will also watch that as well. I can't emphasize enough how exciting this new release is and how impatiently I have been waiting for it. I tried the alpha and beta versions and had same issues, so I kept waiting and watching krita's news every single day for the release. As soon as I can, I will try to test it in another computer which has Kubuntu 17.10, so perhaps with the Lima ppa and if I get pointers on how to, perhaps with the debug packages. Thanks a lot for all you do for this community. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 392251] New: Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display
https://bugs.kde.org/show_bug.cgi?id=392251 Bug ID: 392251 Summary: Krita crashes/hang (and sometimes takes with it the entire X system) when using Touch display Product: krita Version: 4.0 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: kxk-ocumoatbugs...@lugosys.com Target Milestone: --- Krita 4.0.0 (and sometimes the entire X system) crashes / hang when using a Wacom Cintiq Touch display. Context: My system is: Kubuntu 16.04 running on an 8 core AMD FX8350 processor, 16GB RAM and Nvidia GeForce GTX 1050 (details at the end) I have two fixed monitors (Philips and Samsung) and a Wacom Cintiq 27QHD Touch display connected to the GPU DisplayPort connector, that I switch on only when working with krita. It gets configured as the third monitor, at the far right. IMPORTANT: Krita 3.3.3 (appimage) works absolutely normally without any of the problems below described for Krita 4.0.0, either in KDE, in Xfce or in Enlightenment 0.22.2. Sequence, description of, and how the failure is triggered: (See below "Additional context information" for further pre-existing conditions) 1. Disable gesture issuing a `xsetwacom` command (see how and why below) so that fingers touching the screen won't paint. 2. Open krita 4.0.0 and create a new document. At this point: a) If in KDE: Fingers don't paint (OK) BUT also gestures are ignored (WRONG), namely the zooming or panning gestures don't work. Expected behaviour: fingers won't paint and gestures work (as in v3.3.x). Attempting at this point to change any Wacom configuration regarding touching, e.g. finger touch gesture on/off again will crash/hang Krita (it gets totally irresponsive) and sometimes the X system also (all input to X is ignored, including keyboard) and only solution is restart the system. Also, attempting to use Krita painting and zooming, rotating, at some point it crashes/hangs as explained. I could not figured out exactly what would crash it so badly, it's very annoying troubleshooting something this bad. So I changed to Xfce: b) If in Xfce: Fingers don't paint (OK) AND zooming and panning gestures do work (OK), as expected. BUT: open the pop-up palette and do some rotate of the canvas, using a finger to control the rotating slider. Click back on the document with the finger and now, bizarrely, the touch with the finger does PAINT and gestures are not recognized (the opposite to expected behaviours). Keep painting with the fingers. Bring back again the pop-up palette and try to rotate again the document using a finger, and the whole X system crash badly like described above. So I changed to Enlightenment: c) If in Enlightenment: Launching Krita4 with a desktop launcher doesn't work: there is an generic error from Enlightenment: "Krita stopped running unexpectedly. There was no error message". However, Krita appimage works if launched from the terminal: $ ./krita-4.0.0-x86_64.appimage The program launches. After creating a document: Fingers don't paint (OK) AND zooming and panning gestures do work (OK). HOWEVER: open the pop-up palette and do some rotate of the canvas, using a finger to control the rotating slider. Click back on the document with a finger and notice that it generates a stroke and gestures are not recognized (both unexpected wrong behaviours). Keep painting with the fingers. Bring back again the pop-up palette and try to rotate again the document using a finger, and Krita hangs badly as described above. The X system doesn't crash. These errors are displayed on the console after others (I will provide full listing if requested): krita.general: Could not find font QVariant(QString, "Source Sans Pro") with style QVariant(QString, "Light") krita.general: Could not find font QVariant(QString, "Source Sans Pro") with style QVariant(QString, "Regular") file:///tmp/.mount_krita-RfVPUL/usr/lib/qml/org/krita/sketch/components/Button.qml:84:9: QML Image: Failed to get image from provider: image://icon/opacity-decrease krita.input: KisAbstractInputAction "Zoom Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) krita.input: KisAbstractInputAction "Zoom Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) krita.input: KisAbstractInputAction "Pan Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) krita.input: KisAbstractInputAction "Zoom Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) krita.input: KisAbstractInputAction "Zoom Canvas" tried to process event data from an unhandled event type QEvent::Type(TouchUpdate) ...and 20 more like that. --- In general, in any system, if I avoid doing any of the things that provoke
[neon] [Bug 382812] Mouse icon artifacts block display of desktop content
https://bugs.kde.org/show_bug.cgi?id=382812 --- Comment #27 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- I can confirm that after upgrading my Kubuntu system from 17.04 to 17.10 the problem is not happening. I have to say that the real bug is/was never whatever they fixed. Honestly, after all these, whatever it was doesn't really matter: The real bug *IS the bad attitude* that _some_ (but an ever increasing number too!) KDE devs have adopted as standard, that generate ultra-defensive replies (if any at all). In some cases, it might not be bad personality or bad character: It might be a worrying sign of something else altogether. While I --having myself been victim of burnout like many others-- understand the symptoms of that condition and how important it feels to kick out any problems as small as they might be when you are in such condition, the cruel truth is that until recognize and accept what you are going through, you are just going to get worse. You'll find yourself raising your voice (or writing all in caps) more often than you would normally do before, and failing to make good decisions because frustration takes over the best of you. With all sincerity and good will, I strongly advise those who are felling like that, to seek for professional help before it's too late. For those who are just jerks, I think they should abandon the FOSS community altogether. I have been watching many threads in the KDE bug tracking and it's really scary what I see. As user, I must say that this really is getting the prize of the least friendly community and frankly the least helpful I have seen since a few years already. Of course with honorable exceptions: those reading will know. If not, please just spend a little more time reading through threads of this bug tracking system or just try and open a new one yourself. IMHO I think that the KDE project as a whole, should look at those devs that are burned out or in their way to that: they should not be allowed to "help" in this bug tracking system. I am not being sarcastic, I seriously mean that. The next sentence _is_ sarcastic, but I hope it somehow helps to make this dramatic point clear and no offence intended: To tell people that "this is not a KDE problem go complain somewhere else", an automatic script would suffice, no overwhelmed human needed. -- You are receiving this mail because: You are watching all bug changes.
[neon] [Bug 382812] Mouse icon artifacts block display of desktop content
https://bugs.kde.org/show_bug.cgi?id=382812 ocumo <kxk-ocumoatbugs...@lugosys.com> changed: What|Removed |Added CC||kxk-ocumoatbugskde@lugosys. ||com --- Comment #20 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- The bug is NOT only KDE Neon. It has been happening in Kubuntu ever since upgrade to 17.04 and it was not because any nvidia upgrade. It remains exactly the same today, with all possible ubuntu updates. Workaround: log out and login again. It is interesting that there are so many bug reports open for this bug in bugs.kde.org (at the very least: 381533, 382865 and 382812) and it keeps being pointed as "somebody else" problem, ranging from nvidia, KDE Neon, X11, etc. It looks as if a normal user that just wants to switch on her KDE system and sees that it won't work as advertised, only has the option to become a developer in order to determine herself what exact line of code is broken, instead of simply complaining to the KDE developers to figure it out themselves. It is very sad to see that users do not have the possibility of even just reporting a problem without getting a finger "talk to somebody else, we don't know". That's the point. What do you do when you find a "bug" in your TV set: do you go to the vendor and complain or do you start figuring out yourself every single possible component of that system that could be failing to avoid the unpleasant response "not our problem"? Could you at least lead all the users in a decent direction that doesn't involve quitting using KDE at all? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381533] Square box behind mouse cursor/pointer blocks and corrupts zones at which it's pointing
https://bugs.kde.org/show_bug.cgi?id=381533 ocumo <kxk-ocumoatbugs...@lugosys.com> changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #14 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- The bug remains exactly the same, it has not been fixed, mitigated or much less resolved. Why change the status to "RESOLVED MAINSTREAM"? "Resolved" as adjective means "firmly determined to do something" and as verb "decide firmly on a course of action". It's not clear what is going to be done. The status is misleading. After all updates possible in my system, Kubuntu 17.04 "Zesty", including nvidia driver 384.90, the symptoms and the workaround remain exactly as described four months ago. Kicking this discussion to another one where the only "action" taken is a rude post with caps on that this is a bug of nvidia driver -while multiple users show the opposite- is not helpful at all. Even if it where, the very minimum that a user expects, is that the devs take interest in whatever is crippling their software and enerving so many users. Ultimately, it's your software that isn't working, so at least one would expect some interest into what could be done to help, other than finger pointing somewhere else and remain in denial. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 386178] Invoking Color Selector, Show Common Colors or Show Color History deactivates keyboard and shortcuts in krita
https://bugs.kde.org/show_bug.cgi?id=386178 --- Comment #5 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- (In reply to Boudewijn Rempt from comment #4) > I don't mean the Ubuntu packagers, I mean the xcfe developers. > > I suspect that their window manager -- and I don't know which it is -- just > doesn't follow the spec correctly when it comes to popup widgets. Plasma's > kwin and Gnome's mutter seem to be fine. But I'm not an xfce user, I only > installed it to test the duplicate bug, and I couldn't reproduce it. > > But since it's not a bug in Krita itself it would be wrong to keep this bug > open; we could add a faq entry, but in the first place, the faq is pretty > long already, and in the second place, the issue is quite obscure -- and > finally, nobody ever seems to read the faq before reporting a bug, in my > experience. Thanks. I appreciate your comments and quick reply. I understand your point; still, I just think that "resolved" is not the correct status for this. It would seem that there was an issue and it was fixed, which is not true. Wouldn't it be more accurate something like "Won't fix"? I mean, that's what it is: an issue affecting Krita that its devs won't get into fixing it. If you were not able to reproduce it, you could say "can't reproduce", but not before actually testing on xfce on ubuntu -unless some other user would say "me too". If you, a Krita authority, qualify the issue as obscure: how do you think a Xfce dev will qualify it when he might not even have a clue of what Krita is, let alone reading a description of how to use it? My chances of getting this ever looked at are zero. If it is only me, then that's OK, only one guy with who know what strange constellation of variables that not even me would care about. But what if it's more people too? I have read that high profile users like David Revoy uses (or have used) Xfce, in his blog. I would be curious to know if it's only me. In any case, I do have difficulty in searching for information on googling for a legitimate issue in Krita and find that is has been "resolved", when it's not. It's not a matter of who to blame, it's a matter of document that there is an issue, fixable or not, that tells me that I better quit on using Krita in such context and choose instead another one. This strikes me as very uncomfortable, because when I write some JavaScript code that works in Firefox but it doesn't in e.g. Chrome, and I get a complaint from someone who uses Chrome, I cannot just go ahead and 'resolve' the complaint as a Chrome's problem. Why? Different browsers have different flavors of JavaScript. If I don't care about Chrome users, then I can say "sorry we don't support Chrome, please follow the instructions, you must use Firefox." Done. But if I do need to support Chrome users, I could never suggest 'hey, file a bug with Google to fix Chrome so that my code works in it'. It is me who have to ensure my code is compatible with whatever browsers I want to support, not the other way around. And those that I don't, I have to inform users about it: please don't run it on XYZ because it won't work! That's why browsers suck (not JavaScript). I can say here window managers suck too. Sorry for long post. I like so much Krita, I hope I can help somehow. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 386178] Invoking Color Selector, Show Common Colors or Show Color History deactivates keyboard and shortcuts in krita
https://bugs.kde.org/show_bug.cgi?id=386178 --- Comment #3 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- Oh, I forgot to say, that I run krita in Xfce, not KDE for a reason. It would be very sad if I have to assume that krita won't run in Xfce unless it's opensuse, which is not a distribution I am going to use any time soon. My point is, that ultimately, the fact is krita won't work in -at least- the ubuntu flavor of xfce. If that's what it is, too bad, but then it should be stated somewhere, and this thread is a good start. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 386178] Invoking Color Selector, Show Common Colors or Show Color History deactivates keyboard and shortcuts in krita
https://bugs.kde.org/show_bug.cgi?id=386178 --- Comment #2 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- Thank you for ultra-quick reply. However it's a bit ultra-short too. By "their" I suppose you mean the ubuntu Xfce packagers? Could you please provide some hint of how could this be pursued: I am painfully guessing that if I file a bug in Xfce or Ubuntu saying that three of the Krita widgets don't work they will also 'resolve' the ticket as "their (Krita) problem". Could you please provide some pointers of how to phrase or put the problem so that it's of interest of "them"? How could I get an Xfce developer's attention to three Krita widgets not working as intended in one of their flavors. I wouldn't like to let this die out of lack of direction or frustration. I also couldn't agree in having this bug 'resolved', as it's misleading someone else who is running krita in similar conditions as I am. Although I do have a KDE system where this issue is not there, anyone who sees this thread might conclude (I am close to that) that there will be no solution for this issue, or there is no issue, which is not true. Thank you -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 386178] Invoking Color Selector, Show Common Colors or Show Color History deactivates keyboard and shortcuts in krita
https://bugs.kde.org/show_bug.cgi?id=386178 ocumo <kxk-ocumoatbugs...@lugosys.com> changed: What|Removed |Added CC||kxk-ocumoatbugskde@lugosys. ||com Keywords||usability -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 386178] New: Invoking Color Selector, Show Common Colors or Show Color History deactivates keyboard and shortcuts in krita
https://bugs.kde.org/show_bug.cgi?id=386178 Bug ID: 386178 Summary: Invoking Color Selector, Show Common Colors or Show Color History deactivates keyboard and shortcuts in krita Product: krita Version: 3.3.1 Platform: Appimage OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: kxk-ocumoatbugs...@lugosys.com Target Milestone: --- Invoking the Color Selector, Show Common Colors, or Show Color History widgets disables (temporarily) the keybord and all Krita shortcuts, until moving the focus from Krita main window to any other place and returning back. It seems to be related to this particular type of Qt widget, which is different than the normal modal dialogs. It would seem as if the widget is not destroyed/exited properly or somehow doesn't return the focus properly until we perform one of the actions listed below, after which the shorcuts and keyboard work again. IMPORTANT: This problem happens in the Xfce window manager, and it does NOT happen in KDE (or at least I can't reproduce it there). The problem would appear to me to be related to the infamous "Qt in GTK" or "GTK in Qt" troubles; I wonder if it would also happen in other GTK environments. Please note that this bug is somewhat similar to Bug 366353, but I am opening it new here, because that one is not very well documented, no answer was ever provided to developer's question, it's old and seems dead. Krita 3.3.1 (appimage) in Kubuntu 16.04 running Xfce (system details below). Reproducible: Always Steps to reproduce: 0. Use Xfce window manager. (In my KDE system this problem does NOT exist.) 1. Open a krita file and paint some stroke. 2. Invoke the the Color Selector widget (e.g. Shift + I in my case). When it shows up, select a color. Note: The same problem will happen if you invoke the Show Common Colors or the Show Color History widgets. 3. Paint some stroke. From this moment on, shortcuts stop working, i.e. krita does not respond to any keyboard shortcut at all, e.g. Shift + I, ctrl + Z, U, etc. 4. Try any krita shortcuts, for example undo with ctrl + Z or any others. Krita does not react to any keyboard shortcuts. 5. To get the shortcuts working again, changing the focus from the main Krita window and then focus back again to Krita will "fix it". For example, doing any of the following actions works: a) Press + and release it. After this, the shortcuts work again. OR: b) Click on any other window that is open on your Desktop, to change the focus to that window, and immediately click back on Krita's window to get the focus on Krita again. OR: c) Minimize the Krita main window, and then restore it back. OR: d) Open any krita dialog by clicking menus, and then close that dialog. Examples: Click Settings > Configure Krita and just press Cancel to close the dialog. OR: Click File > New, then click Cancel or hit the Esc key to close the dialog. OR: Probably opening and closing any dialog would do. The shortcuts work again, but opening any of the mentioned widgets again, the problem reproduces again: it works, but then shortcuts stop working until you change focus of the window or open and cancel any dialog. Expected Results: Invoking and using any widget or tool should not cause any blockage of shortcuts or any other usability impairments. Additional notes: Although I'm not 100% sure these are related, I thought I should mention: The following error is shown on console output around the time we select Shift + I (Color Selector shortcut) for the first time, (but not necessarily anymore): QLayout: Attempting to add QLayout "" to QWidget "KritaShape/KisToolLine", which already has a layout In my .shotcuts file, 'KritaShape/KisToolLine' is set to 'none'. The following warning (and/or other similar ones) is also show during this time: krita.general: WARNING: The following shortcuts are not registered in the collection, they might have wrong shortcuts in the end: krita.general: "add_new_colorize_mask" krita.general: "show_tool_options" krita.general: "detailed_debug_paragraphs" krita.general: "file_print" krita.general: "file_print_preview" krita.general: "options_configure_keybinding" krita.general: "file_export_pdf" krita.general: "detailed_debug_styles" krita.general: "KritaShape/KisToolLazyBrush" krita.general: === end === System Information: Krita Version: 3.3.1 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.4.0-97-generic Pretty Productname: Ubuntu 16.04.3 LTS Product Type: ubuntu Product Version: 16.04 OpenGL Info Vendor: NVIDIA Corporation Renderer: "GeForce GTX 1050 Ti/PCIe/SSE2" Version: "4.5.0 NVIDIA 384.90"
[krita] [Bug 382628] G'Mic fails to start because could not find Qt platform plugin "xcb" - Krita v3.2.0-beta.2
https://bugs.kde.org/show_bug.cgi?id=382628 --- Comment #4 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- I have created the bug report and workaround in the gmic community site, as suggested by Boudewijn. It's been assigned the number 87. Here is the link: https://github.com/dtschump/gmic-community/issues/87 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 382628] G'Mic fails to start because could not find Qt platform plugin "xcb" - Krita v3.2.0-beta.2
https://bugs.kde.org/show_bug.cgi?id=382628 --- Comment #3 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- (In reply to Boudewijn Rempt from comment #2) -- Hi Boudewijn, Thank you for having a look and for good suggestion. I'll do. I was not sure to what extent this bug would be better owned by you guys as direct "consumer" and "co-implementers"/partners of the new feature from what I understood in the announcement of 3.2-, since it is an actual button in Krita (and a newly announced, important one) that doesn't work. Obviously I gladly will report (copy) this on the gmic forum as you suggest; I appreciate that no one exactly loves taking ownership of problems that might be a bigger percentage (even all) of responsibility of others. I've done that professionally for long time. But Krita's site says: "We’re still working with them to create binary builds...", which implies partnership, strongly suggesting that somehow this bug does relate to all the good people working hard to produce a nice 3.2 final product (though it doesn't imply that they are necessarily the "causers"). Please don't get me wrong: I'll report this wherever you tell me it's the best place to help devs to get their goals done, for the benefit of everybody. But still it should also exists here. Please just let me observe -with appreciation- that Krita's users should be aware or notified in the first place, that this bug affects Krita, no matter who's technically the final owner. As users of Krita, (exactly as say, our own car) we interact with Krita and when one of its major features is broken, we immediately see a bug in Krita. We (users) don't ought to know who's the one taking care of environmental variables, dependencies, or what not in a plugin partnership. Same with our own car. We don't know who should be inquired about a failing pump, other than the car's manufacturer. That's regardless of whether the issue is caused by the guy who installed it in the car, or a pump manufacturer's mistake, or a supplier of a sub-assembly of that third party (so, a fourth party), etc. But: my car is broken. I'd complain to the car's vendor, period. Who wouldn't? (Disclaimer: this example is for mere illustration, as a metaphor: it's NOT a comparison by any means! you guys are NOT a rich corporation that gets good money for their products Most people won't give you any money at all for Krita.) It's in that spirit that I decided to report in the first place (but not the last one!) here. That said: Thank you, again, for all you do to provide us with such an incredible and ever improving, formidable software called Krita! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 382628] G'Mic fails to start because could not find Qt platform plugin "xcb" - Krita v3.2.0-beta.2
https://bugs.kde.org/show_bug.cgi?id=382628 --- Comment #1 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- WORKAROUND I have been able to create a WORKAROUND until this bug is fixed. As stated in the error message, the gmic_krita_qt program fails to find some library, most likely due to an issue with environment path. Follow these steps: 1. Locate the libqxcb.so file in your system. In an Kubuntu installation, this file is in your qt5 installation directory, i.e. in: /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so (If wouldn't have that file, then you have more problems, this workaround wouldn't apply.) 2. Change directory to the directory where you put your gmic_krita_qt file. Once there, create a directory 'plugins' and then inside that directory, create a 'platforms' directory, with this command: (you have to be already in the gmic_krita_qt's directory): mkdir -p plugins/platforms 3. Copy the libqxcb.so file into the platforms directory, like so: cp /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so plugins/platforms/ (again: you are issuing this command from the directory where gmic_krita_qt is) 4. In the same directory as gmic_krita_qt, create a text file named 'qt.conf' with this content (two lines): [Paths] Plugins = plugins 5. After saving the qt.conf file, you can now restart Krita. Open an image file and run the G'Mic filter. It should work now. DONE. Summary: You need to have this directory structure where you have the gmic_krita_qt file: $ tree . ├── gmic_krita_qt ├── plugins │ └── platforms │ └── libqxcb.so ├── qt.conf └── README ...where: a) 'gmic_krita_qt' and 'README' were extracted from the downloaded GMic zip b) the 'qt.conf' file contains the above mentioned lines, and c) you have created the 'plugins/platforms' directories and copied the libqxcb.so file in the 'platforms' directory. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 382628] New: G'Mic fails to start because could not find Qt platform plugin "xcb" - Krita v3.2.0-beta.2
https://bugs.kde.org/show_bug.cgi?id=382628
Bug ID: 382628
Summary: G'Mic fails to start because could not find Qt
platform plugin "xcb" - Krita v3.2.0-beta.2
Product: krita
Version: unspecified
Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: G'Mic for Krita
Assignee: krita-bugs-n...@kde.org
Reporter: kxk-ocumoatbugs...@lugosys.com
Target Milestone: ---
G'Mic won't start and no information or visible reaction is shown on Krita's
GUI when 'Start GMic-Qt' is selected in the Filter menu.
When launching Krita on the console, this error is logged exactly when the
'Start GMic-Qt' button is pressed:
stateChanged QProcess::ProcessState(Starting)
stateChanged QProcess::ProcessState(Running)
Plugin started true QProcess::ProcessState(Running)
gmic-qt: socket Key: "{5e393e6a-8442-4d77-ba98-1cf48f9c929f}"
This application failed to start because it could not find or load the Qt
platform plugin "xcb"
in "".
Reinstalling the application may fix this problem.
stateChanged QProcess::ProcessState(NotRunning)
pluginFinished 6 QProcess::ExitStatus(CrashExit)
My system: Kubuntu 16.04; Krita 3.2.0-beta.2 (running the appimage from
/opt/krita/); G'Mic v2.02
Steps to reproduce:
1. Download the G'Mic plug-in for Krita in
http://gmic.eu/files/prerelease_linux/gmic_krita_qt_linux64.zip, and unzip the
files and "place it somewhere you can find it."
2. "Go to Settings → Configure Krita → G'Mic plugin and set G'MIC to the
filepath there; then restart Krita." (Quoted from Krita documentation).
3. Go to Krita's menu: Filter -> Start GMic-Qt, and when asked, enter the
location of the gmic_krita_qt file that was unzipped earlier. Alternatively, go
to Settings -> Configure Krita -> G'Mic-Qt Integration and enter (or browse to)
the gmic_krita_qt file path and click OK.
4. Restart Krita (don't know if it's necessary, but won't make a difference).
5. Open an image file, and select Filter -> 'Start GMic-Qt'.
At this point, nothing visible will happen in Krita's GUI. But if you have
launched Krita from the console, then you will see the aforementioned error
message.
Expected behaviour: G'Mic should launch when the 'Start GMic-Qt' button is
pressed.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 381533] Square box behind mouse cursor/pointer blocks and corrupts zones at which it's pointing
https://bugs.kde.org/show_bug.cgi?id=381533
ocumo <kxk-ocumoatbugs...@lugosys.com> changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DOWNSTREAM |---
--- Comment #6 from ocumo <kxk-ocumoatbugs...@lugosys.com> ---
(In reply to Christoph Feck from comment #5)
> Corrupted graphics is a video driver issue. Please report this issue to the
> bugtracker of your graphics driver vendor.
Thank you Christoph. Would you have, nevertheless, an idea why this problem is
"masked" ("fixed"??) by simply logging out of KDE and logging in again
immediately ? (no restart)
That is what I am currently doing: I boot my system, log in to KDE with my
password, then immediately logout from KDE and log in again, without any other
action at all, and this second time I login, all is OK. This has definitely
nothing to do with the selected theme, as I suspected in my previous posts.
If the problem is the driver, what could be the mechanism that "fixes" it
(until next reboot) by just logging in/out/in from KDE? does login/logout/login
somehow changes the environment/context, or perhaps it just allows something to
restart a second time?
If the problem would be with the nvidia proprietary driver, I --and anyone else
having the same issue-- may be screwed, given the known nvidia's relationship
with Linux since many years.
--
You are receiving this mail because:
You are watching all bug changes.
[konqueror] [Bug 373824] Konqueror 16.12 is missing the sidebar
https://bugs.kde.org/show_bug.cgi?id=373824 --- Comment #29 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- (In reply to Cochise César from comment #25) Thank you for the clarification. Sorry if I misunderstood you. In essence, we are basically all in agreement of the needs and the difficulties to fulfill all of them to the satisfaction of everyone, so honestly I don't recognize dispute here, just wishes of improvements. I must emphasize my gratitude to the developers of all these nice tools, (including Dolphin!) despite the challenges. Also, big thanks to David Faure for his good tips. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381533] Square box behind mouse cursor/pointer blocks and corrupts zones at which it's pointing
https://bugs.kde.org/show_bug.cgi?id=381533 --- Comment #4 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- Update: Bad news. As said in the previous update, the problem "apparently" was theme-dependent. Now I can confirm it IS NOT, because after having restarted the system, the problem is back again. So I switched from the "Air" desktop theme to the "Breeze light", and logout-login into KDE, the problem is __apparently__ "gone" again, i.e., there is no annoying square underneath the mouse pointer/cursor. So, whether in "Air" or "Breeze", the problem is there, at least sometimes. This makes this issue even more strange, because for some reason it seems to be possible to --at least temporarily-- mask the problem. Whether it's because changing theme and logout-login or just simply because logout-login alone or any other crazy condition that hides the problem, I cannot tell. Therefore, so far, it may seem that a possible workaround is to "logout-login" into KDE after (maybe) changing the Desktop Theme to any other theme. (?). Sounds crazy, but is how I am using my laptop now, until further notice. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381533] Square box behind mouse cursor/pointer blocks and corrupts zones at which it's pointing
https://bugs.kde.org/show_bug.cgi?id=381533 --- Comment #3 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- Update: The Desktop Theme that I have been using when I see this problem, is "Breeze". After changing the Desktop Theme (using System Settings -> Workspace Theme -> Desktop Theme) to "Air" and logout-login into KDE, the problem doesn't seem to exist in this Theme. So, _apparently_ this is Theme dependent and the suspect is then Breeze Desktop Theme. I haven't had time for a deeper troubleshooting, though, as to test other Desktop Themes and combinations. Perhaps other users may contribute while I find time to do some more experiments on my own. Notice, however, that just changing Cursor Themes doesn't seem to help. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381533] Square box behind mouse cursor/pointer blocks and corrupts zones at which it's pointing
https://bugs.kde.org/show_bug.cgi?id=381533 --- Comment #2 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- Created attachment 106231 --> https://bugs.kde.org/attachment.cgi?id=106231=edit Mouse pointer is corrupted. Example on konqueror drop-down menu. Zone around pointer is corrupted - example in konqueror drop-down menu -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381533] Square box behind mouse cursor/pointer blocks and corrupts zones at which it's pointing
https://bugs.kde.org/show_bug.cgi?id=381533 ocumo <kxk-ocumoatbugs...@lugosys.com> changed: What|Removed |Added Flags||X11+ --- Comment #1 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- I am not sure if "plasma/look & feel" is the right product/component; I'm not a KDE developer. Please kindly advise if this should be classified otherwise and how to do so. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 381533] New: Square box behind mouse cursor/pointer blocks and corrupts zones at which it's pointing
https://bugs.kde.org/show_bug.cgi?id=381533 Bug ID: 381533 Summary: Square box behind mouse cursor/pointer blocks and corrupts zones at which it's pointing Product: plasmashell Version: master Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: major Priority: NOR Component: Look & Feel package Assignee: plasma-b...@kde.org Reporter: kxk-ocumoatbugs...@lugosys.com CC: plasma-b...@kde.org Target Milestone: 1.0 Created attachment 106230 --> https://bugs.kde.org/attachment.cgi?id=106230=edit Zone around pointer is corrupted - example in Firefox drop-down menu There is a permanent box drawn behind the mouse pointer/cursor, which blocks and/or corrupts the view of what is being pointed at. This is more dramatic on drop-down menus and input boxes, making it extremely hard to use in some cases. See attachments. This happens no matter which mouse pointer theme is used. Problem started after upgrading to Kubuntu 17.04 (wouldn't happen in 16.04) CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz Graphics card: Nvidia GeForce GTX 980M Graphics driver: nvidia proprietary, version 375.66 Reproducible: Always. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 373824] Konqueror 16.12 is missing the sidebar
https://bugs.kde.org/show_bug.cgi?id=373824 --- Comment #24 from ocumo <kxk-ocumoatbugs...@lugosys.com> --- @Cochise César "What are the sidebar advantages?" Again. Just to repeat one of them: tree view. And again: not just the sidebar, but also this: Multiple splitting. Things like that have nothing to do with "power users". It's not correct to reduce this kind of healthy conversation to "power users" vs. "weak users" or whatever label is the current trend. That is so false and negative. Having the chance to look the tree in which one is and navigate it trivially with a single click, as opposed to "remember" where one is on his tree, has nothing to do with "power". If anything, the opposite: it actually has to do with the "lack of power" to memorize where on earth is this folder in relation with my other folders. It has been well explained here by the developer, that the feature was not "removed" because some kind of whim; it was a necessity due to obsolescence of whatever library that was necessary to implement it, which is way, way far different to imply that this is some kind of "evolutionary decision". No: it's a bad consequence of a number of unrelated problems, as explained above. For the record, neither History dialog, Bookmarks bar, and so on have anything to do with side tree view (and/or multiple splitting features for that matter) and hardly could ever be compared in function with that. Also, it's a bit disrespectful to imply that because someone doesn't use (or doesn't know or understand) a feature, that feature is "useless", ergo those that use it are wrong in doing so. This type of argumentation wrongly compartmentalize the opinions into false "sides" that don't exist. One thing seems to be clear and we agree: Dolphin is clearly not a replacement for Konqueror, it's something else, it has its place, but it has nothing to do with power or no power. In fact, as I see it, Dolphin is actually more difficult to use, and less friendly, because it lacks things that make it easier for me to manage, see and understand my file system in a graphical way, in a glance without so many clicks that hurt my arm's extensor muscles so much (typing with a pack of ice attached to your elbow is not nice). So, actually it's all about making life of users easier, not the opposite. And while I am fine working with just the command line, my bash or python scripts when I need it, that doesn't mean that I don't like to have a GUI that's easy and functional too, like old konqueror. I shouldn't need to be firing bash commands to have a glance at my directory trees, or to program myself my own thing to accomplish that. And others, whom are not so "powerful", may not be so lucky. -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 373824] Konqueror 16.12 is missing the sidebar
https://bugs.kde.org/show_bug.cgi?id=373824 --- Comment #21 from ocumo <yhcdr-devst...@yahoo.com> --- Oh, and I must add: one of the MAJOR features that konqueror has (until now) is the magnificent splitting feature. Dolphin doesn't even get close to that, because only splits once and vertically. How come this is not obviously a hugely useful feature that Dolphin should have, as file tree side pane, etc., and still Dolphin is the "chosen" one? Basically what we need, then, is that Dolphin becomes konqueror, and then Dolphin will be nice. How crazy is that? -- You are receiving this mail because: You are watching all bug changes.
[konqueror] [Bug 373824] Konqueror 16.12 is missing the sidebar
https://bugs.kde.org/show_bug.cgi?id=373824 ocumo <yhcdr-devst...@yahoo.com> changed: What|Removed |Added CC||yhcdr-devst...@yahoo.com --- Comment #20 from ocumo <yhcdr-devst...@yahoo.com> --- I must join those who very strongly miss and need back the left pane tree view in konqueror. Dolphin is in my opinion and for my workflow way inferior to konqueror. I never was able to stick to Dolphin although I have been trying it each time there is a new major release, ever since it was first created, ages ago. It is in much aspects bloatware that misses fundamental file management features, such as... the side tree view, which for many people is fundamental in their way to work, like in my case, since so many years of computing. And like someone said before, Thunar is not KDE, and though nice, it lacks a lot of things that a good file manager like konqueror offers. So, all in all, we are going backwards and are loosing a lot if we loose konqueror. I feel sorry for the difficulties that the only developer for konqueror has had and can only hope that good people like @Cochise César can help. Being myself a developer, I don't develop in C++ so I couldn't help, as much as I would like to. Thanks for all the efforts and good will, nevertheless! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361911] Overriding hotkeys won't work (conflict of new hotkey with old one)
https://bugs.kde.org/show_bug.cgi?id=361911 --- Comment #6 from ocumo <yhcdr-devst...@yahoo.com> --- Unfortunately the same problem is happening with krita-3.0.92-x86_64.appimage. I'm using Kubuntu 16.04. With current stable krita-3.0.1.1-x86_64.appimage I was forced to recreate all my customizations one by one because all existing ones just would have been replaced by default. I did not have time to make systematic troubleshooting, I just needed to move on with my work, and this is an old issue (similar bugs exist since at least 2014 with several releases) that is described sometimes with different titles, but when we read, there you find the infamous "sequence is ambiguous" that won't be possible to eliminate, and/or missing/overriden shortcut configurations. See for example: #352205 and #348033 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 372198] Shortcuts reset to default
https://bugs.kde.org/show_bug.cgi?id=372198 ocumo <yhcdr-devst...@yahoo.com> changed: What|Removed |Added CC||yhcdr-devst...@yahoo.com --- Comment #1 from ocumo <yhcdr-devst...@yahoo.com> --- I have experienced similar issue when I first changed to current stable version 3.0.1.1 in Kubuntu Linux (krita-3.0.1.1-x86_64.appimage). None of my customizations were there, and using the dropdown list to select different schemes gave any changes. Unfortunately I did not have the time to make a systematic troubleshooting, and out of the need to work and irritation this caused, I just created my customizations from scratch once again. I know this doesn't help to reproduce or even describes accurately the problem, but it is not the first time a new version of Krita breaks shortcuts or shortcuts creation for me. I started testing yesterday the 3rd beta for 3.1 and once again found that my customizations were not working and when I tried to create them from scratch, I had errors like "The L shortcut is ambiguous with the following shorcut...", which will keep popping anytime you reassign and retry. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361911] Overriding hotkeys won't work (conflict of new hotkey with old one)
https://bugs.kde.org/show_bug.cgi?id=361911 --- Comment #4 from ocumo <yhcdr-devst...@yahoo.com> --- Update: bad news. I have just downloaded krita-3.0-Beta-master-37389d5-x86_64.appimage and I have exactly the same problem, same symptoms, no improvement, despite what is in the "New Development Builds Ready" release notes from May 5, reporting various fixes to shortcut issues. My system is Kubuntu 16.04. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361325] shortcut schemes broken again
https://bugs.kde.org/show_bug.cgi?id=361325 ocumo <yhcdr-devst...@yahoo.com> changed: What|Removed |Added CC||yhcdr-devst...@yahoo.com --- Comment #11 from ocumo <yhcdr-devst...@yahoo.com> --- I have just downloaded krita-3.0-Beta-master-37389d5-x86_64.appimage and I have exactly the same problem described by this bug report. It is not fixed. I can see that there are a lot of bug reports on this issue, with minor or bigger differences, some are closed, some are in other states. Please is it possible to make this a bit less confusing? It doesn't make sense to see so many opened tickets for basically the same thing. It is not possible to set new shortcuts, overriding the default ones. Please reopen this bug or indicate what is the correct thread for this. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361911] Overriding hotkeys won't work (conflict of new hotkey with old one)
https://bugs.kde.org/show_bug.cgi?id=361911 ocumo <yhcdr-devst...@yahoo.com> changed: What|Removed |Added CC||yhcdr-devst...@yahoo.com --- Comment #3 from ocumo <yhcdr-devst...@yahoo.com> --- I can confirm that this problem is happening in krita-3.0-Beta-master-no_gmic-4336582-x86_64.appimage running in Kubuntu 16.04 . It doesn't seem to be possible to override default shortcuts, even creating new templates, saving or loading other existing templates that are working in Krita stable otherwise. In addition, maybe a minor thing, but in the above mentioned 3.0 pre version, there is no 'Configure Shortcuts' in the 'Settings' menu as it exists in Krita stable. If that would be a design decision rather than a bug, then it would be another topic, but then the "Ambiguous shortcut detected" dialog that pops up when we are trying to override an existing one, has to be updated, as its current text is: Ambiguous shortcut detected The key sequence 'W' is ambiguous. Use 'Configure Shortcuts' from the 'Settings' menu to solve the ambiguity. No action will be triggered. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 361577] Clone tool brush stroke causes crash
https://bugs.kde.org/show_bug.cgi?id=361577 ocumo <yhcdr-devst...@yahoo.com> changed: What|Removed |Added CC||yhcdr-devst...@yahoo.com --- Comment #1 from ocumo <yhcdr-devst...@yahoo.com> --- I can confirm this bug in Kubuntu 15.04 - 64bit. It is not only in Windows. Krita version used: Krita-3.0-Alpha-master-e5109c2-x86_64.AppImage Steps to reproduce the problem in Kubuntu 15.04: 1. From the command line, launch Krita-3.0-Alpha-master-e5109c2-x86_64.AppImage. 2. Open a krita supported format file like .kra or .jpg. 3. On the Brush Presets tab, select the Clone_tool brush. 4. Try to use the tool on the image, e.g. left-click on it a couple of times. The application crashes and the GUI closes (Segmentation fault). 5. In the terminal, the last few stdout/stderr lines are these: krita.lib.flake: "InteractionTool" : action "object_order_lower" conflicts with canvas action "rotate_canvas_left" shortcut: "Ctrl+[" krita.lib.flake: "InteractionTool" : action "object_order_raise" conflicts with canvas action "rotate_canvas_right" shortcut: "Ctrl+]" krita.lib.flake: "InteractionTool" : action "object_order_lower" conflicts with canvas action "rotate_canvas_left" shortcut: "Ctrl+[" krita.lib.flake: "InteractionTool" : action "object_order_raise" conflicts with canvas action "rotate_canvas_right" shortcut: "Ctrl+]" Segmentation fault (core dumped) -- You are receiving this mail because: You are watching all bug changes.
