Name change in case of fork, packaging

[eeickmeyer]

Hi there! Not so much an issue as I wanted to thank you for taking-on this project since the DisplayCAL author isn't willing or motivated. He hasn't even addressed Debian and Ubuntu dropping the Python2-based dependencies, or that various distributions have dropped DisplayCAL due to the lack of those dependencies. He seems to be only concerned with Windows and Arch, which means everyone else suffers.

Anyhow, I'm the leader of Ubuntu Studio, and as a photographer (among other things), it has been immensely frustrating for me to not have DisplayCAL available to myself and my users. So, I'm glad to see this happening.

The only issue that I can see is that you are keeping the name DisplayCAL. You might consider a different name for a proper fork (if necessary or if he doesn't accept your contribution, as he seems to not be interested in anyone else contributing) since, per that GPL at least, forks aren't allowed to carry the same name unless the original author has completely handed over the original project.

I'm a MOTU with Ubuntu, so I'd be happy to handle packaging and upload it. I can see it definitely landing in Ubuntu 21.10, but 21.04 closes for new packages late this month for beta freeze.

[RomanHargrave]

Thanks. Maybe I'll start getting this on the road again - since there's a possibility, what do you think in terms of names?

[mike-to-spec]

Cald
Calp
displayprof maybe, as in display profiler.
ProfDisplay
DisProf
CaliDis, ColorDis
DisplayAdjuster

[Wedge009]

I echo the thanks given above for taking this initiative. I'm only just getting exposed to Python now and on the learning topic of python2 to python3 conversion my thoughts went to DisplayCAL. Was saddened to see that things still appear to be unchanged since December 2019 but further searching led me here. Just wondering what the state of this project is - is it functional yet or still a work-in-progress? Just wondering if it's worth the time to try building this.

[RomanHargrave]

As for status, I would like to work on this but I've also just moved across the country. I've got a lot going on right now, but I also have displays to calibrate, so it's a tough one. Since putting this on github, I actually have not checked to see if anyone else has done work on porting - I would not be surprised either way.

[Wedge009]

Thanks for the update - I haven't seen any other (public) attempts to migrate to Python 3, hence my query. No worries about the busyness, I suppose it's no different from the busyness/reticence of the original author as well.

[eoyilmaz]

I'm an experienced Python Developer and a Photographer (also a VFX Supervisor, Pipeline Developer, Houdini FX Artist etc.). I'm using DisplayCAL for years and I'm willing to contribute. If you have any particular section of the code that you want me to focus in, I can look in to those.

[eoyilmaz]

Okay, with 2 days worth of work, I'm now able to build and install DispalyCAL with Python3.9. The RealDisplaySizeMM C-Extension module is also compiling with a couple of warnings. Running displaycal from the installed location is not working, complaining about the meta module is not found, which is normal, because it is not correctly imported, I'll fix that in the next commits... etc.

[Wedge009]

That sounds encouraging! If you do get something working - even partially - wondering if you should make a PR here or just make your own fork.

[Doomsdayrs]

Amazing work @eoyilmaz !

I shall share this news with my friends

[eoyilmaz]

Okay, it is alive :)

Still needs a ton of work.

I can do a PR. But, if everything goes as planned, I would love to be the new maintainer for the code.

[Doomsdayrs]

History is made!

[Wedge009]

Fantastic!

I can do a PR. But, if everything goes as planned, I would love to be the new maintainer for the code.

In lieu of any response from Roman I suppose you can just start your own fork. I suppose the issue regarding the name (that was brought up in the original issue report) still stands. I'm not an expert on licence issues, but DisplayCAL cites GPLv3 so I don't think there's any issue with you starting your own project based on the original work.

[eoyilmaz]

So, I'm returning back to my own repository and people are welcome there. I would probably need help with packaging things later on.

[ArchangeGabriel]

He seems to be only concerned with Windows and Arch, which means everyone else suffers.

Then I’m willing to drop it from Arch if it can help in anyway. I’m already using the flatpak version myself since I’ve got rid of py2 on my system.

But anyway, thanks to the awesome work of @eoyilmaz we might get a better solution! I’ll be glad to package a py3 version when it’s available (I won’t be able to test it soon though, because my ColorHug2 is ten thousands kilometres away from me). ;)