Well it’s mostly me talking there. 
I guess it’s not that easy to find people having linux, lcms2.10 and profiled displays together.
I also reported to Arch forums and wrote a bug report for lcms2 package with no reply, so far.
Excellent, at least I have one person having the issue, meaning it’s not my settings, hardware or such. Thank you very much!
1 Like
I talked with the dev earlier. I got a seg-faulting in GIMP due to his lcms 2.10 but my stack traces helped him fix 2 bugs there. Unfortunately he couldn’t help as he’s not using gimp and this bug leaves no trace. :-/
But considering the buggy nature of new lcms 2.10, I’m almost 95% sure it’s lcms2 bug and not GIMP’s, but oh well…
A silly thought, but you used a v4 profile?
What if you used a v2 profile?
1 Like
It’s not silly at all. I tested v4_wide earlier and got the same results. Then I stopped.
However, v2_xyz is working! Not sure what to think now… Still looks like something is making lcms 2.10 rendering this badly and not GIMP. Because everything works in lcms 2.9. Wish Gimp devs could provide more info on this.
well not every breakage is a crash … and i mean … only changing lcms breaks this.
Agree… well I wrote him another email with the same steps. I’ll see if he will be able to reproduce it now.
Apparently GIMP’s own dev found the bug that was causing this in lcms2, so hopefully the original author of lcms2 will be able to fix it.
1 Like
Thanks; I was about to pull LittleCMS 2.10 from github, and encountered your thread. I recently early-adopted Ubuntu 20.04, and minorly regret it, for all the regressions… 
1 Like
If you can, stay away from lcms 2.10 until this is solved. It appears bugged and not much tested. This is the 2nd time I’m reporting critical bugs to lcms dev for 2.10. First one was seg-faulting gimp, this one impairs functionality.
I’m using Arch Linux so everything is latest here, part of the reason I’m loving it, but this time I’ve forced lcms to v2.9.
My day job is about software and large-scale systems engineering, and the LittleCMS regressions demonstrate a dynamic i see quite a lot: a very correlated relationship between component complexity and test coverage in the measures of quality and reliability. FOSS projects particularly suffer this, as with limited numbers of developers, who are also the testers, not as much coverage of the intended uses can be done before release. In any endeavor, the more complicated the behaviors and interactions, the more reliance on testing to drive this stuff out, as the ability for humans to see all the implications is easily overwhelmed.
in FOSS-land, a bit of patience for this is rewarded by direct contact with the development celebrities and very, very responsive action to consideration for different things. May not seem that way sometimes, but consider the (commercial) alternative…
I agree with you completely. I always say that in the Open Source world when you think something needs to be changed or have a better idea, even if you’re not a programmer, you can easily report that to devs directly. And if your logic was sound and could be done technically, in 9 out of 10 you’d be pleased!
One of the reason why I love GIMP so much, I can feel they all share the same passion for that software. It advanced tremendously. I’m using it professionally for my work.
However, as far as lcms2 goes, I think dev could communicate better with this, not to mention that he somewhat pointed out at GIMP, rather than looking at his own code. And it was so obvious - if your lcms 2.9 is working while 2.10 is not and we just fixed 2 critical bugs, there’s 99% chance it’s lcms again and not GIMP.
If I didn’t push this through on many different websites, asking a lot of people, he wouldn’t move a centimeter with this. He’d simply let it go, shrugging. I’m still waiting for his response, to fix stuff what GIMP dev found in his code.
Technically speaking … both sides could have been at fault in this case. Incorrect API usage that leads to bugs in the program using the library is a common problem. A recent example would be the fwupd gpg signature bypass bug. The lcms case shows the other way, where the library introduced a regression.
Do you know if the bug is fixed in lcms already?
Indeed. Though he was pointing at gimp devs as soon as I reported this to him, without even looking at his code about this issue. Then I sent him this step-by-step troubleshoot and no reply since then.
Maybe I’m too pedantic, but if I wrote and maintained something, I know I’d be first in line to check all thoroughly, esp. if new version was released and someone reported issues where prior version was working, while new one did not.
He suspected about alpha channel not being used correctly, but pointed at GIMP’s color engine. Turned out it was alpha formatter bounds he forgot to update in his code.
Anyway, no, the bug is still there. He hasn’t replied. I will write here when things get solved.
I think your expectations are too high. Also you should have sent the steps to reproduce in the original message.
Hi maboleth, I use slackware current with the new kde5 from alien bob which uses kde5 instead kde4 and i noted with the latest massive distro upgrade gimp has segmentation fault As you If I import a v4 instead v2 output profile from rawtherapee and I use the brush tool. I didn’t make any bug report because I’m very busy actually… I hope with your bug report all will go well.
I write this for witness… 
You mean like in gnome bug report? Because I provided the steps here from the beginning.
Those above are the easiest, because you already have the file that 100% affects the alpha channel bug. You don’t have to have Rawtherapee. If you get the bug with this file, you will get with any 16bit integer v4 profile.
Sorry to hear that @dafrasaga . I’m not familiar how slackware pushes the upgrades. But one possibility is that it used old (original) lcms 2.10. Few days after the initial release I reported the seg-fault bug and dev fixed it, although he didn’t change version number (still 2.10). If you can, download the git version and seg-fault should be fixed.
Then again, this brushes bug isn’t fixed - yet. Though no sign of the dev.
I mean your expectations of the developer.
Alright, my 3rd email with the dev was a success. He fixed it and expect v2.11 soon. It’s already on git, if you compile on your own.
So this bug is now fixed.