New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mypaint has file conflict with libmypaint #918

Open
jbicha opened this Issue Apr 3, 2018 · 13 comments

Comments

Projects
None yet
8 participants
@jbicha

jbicha commented Apr 3, 2018

Description of the problem

Hi, I recently packaged libmypaint 1.3.0 for Debian and Ubuntu as a required dependency for gimp 2.10 RC1.

I just noticed that there is a file conflict. Both libmypaint and mypaint ship the translation files named libmypaint.mo

What do you recommend we do here?

  1. Is it practical to package a newer version of mypaint that uses the shared libmypaint?

  2. Should I disable translations in libmypaint for now? Are any of those translatable strings exposed in gimp's user interface?

Basic system details

MyPaint version: 1.2.0
Operating system: Ubuntu 18.04

@achadwick

This comment has been minimized.

Member

achadwick commented Apr 3, 2018

  1. Yes, eminently practical for Debian testing/unstable! I'd love to see this in the OS I use, but I haven't had the time to do it myself. We have an example here: https://github.com/mypaint/mypaint.deb (maintained as a separate repository to avoid breaking the Debian Python packaging team's workflow; there's one for libmypaint too). Would you like access?

  2. Please don't disable translations in libmypaint. They will be exposed in MyPaint's user interface (and possibly GIMP's).

@jbicha

This comment has been minimized.

jbicha commented Apr 3, 2018

@achadwick Are you recommending that all the Linux distros switch to a git snapshot of mypaint then?

Do you have any schedule for when the next major mypaint release will be?

Are there any major issues I should know about in git master?

Ubuntu 18.04 LTS will release in 3 weeks…

@achadwick

This comment has been minimized.

Member

achadwick commented Apr 3, 2018

May be worth calling it soon then, given that timescale.

There have been a few Wayland issues. I'm hoping they're fixed now, though.

@jbicha

This comment has been minimized.

jbicha commented Apr 27, 2018

Ubuntu 18.04 LTS was released yesterday and gimp 2.10.0 was released today.

While Ubuntu 18.04 does not include gimp 2.10, it does offer libmypaint.

@darix

This comment has been minimized.

darix commented May 2, 2018

openSUSE would appreciate a release as well. (for the same reasons)

@badshah400

This comment has been minimized.

badshah400 commented May 2, 2018

We have run into a similar issue for openSUSE too. It has become necessary to have libmypaint-devel (by which I mean the header files and so on needed for coding against libmypaint) for gimp 2.10, while mypaint-devel 1.1.x also provides the same files, leading to file conflicts between the two packages. Fwiw, on openSUSE we don't package mypaint 1.2.x because of dependency issues (we miss pygtkcompat), and would rather move on to mypaint 1.3.0 directly.

It would be helpful for us downstream packagers to know the current state of git master. Would it be ok to package a snapshot of git master and replace existing installs of mypaint on users' computers with that? Will there be a 1.3.0-beta tagged release at some point, or perhaps 1.3.0 release itself is imminent? Thanks for any clarifications.

@darkshram

This comment has been minimized.

darkshram commented May 11, 2018

I have already done gimp 2.10.0 packages for my Linux distro and they will be released this weekend. Would appreciate to know the status for git master too. We ship both gimp and mypaint (my son uses mypaint and really loves it), and we are considering to temporarily obsolete mypaint 1.2.x with libmypaint 1.3.0 —for a clean update— considering the relevance of gimp 2.10.0. For the time being we will be suggesting our users to install mypaint using flatpak until we can ship mypaint 1.3.x or until I figure out how to repackage mypaint to avoid conflicts.

@darkshram

This comment has been minimized.

darkshram commented May 11, 2018

I have modified a RPM spec file to allow mypaint 1.2 to coexist with Gimp 2.10. Basically just renamed mypaint package to mypaint12 and excluded *.mo files from libmypaint.
mypaint12.spec.zip

@rabarbar42

This comment has been minimized.

rabarbar42 commented May 28, 2018

The community is eagerly waiting to get, e.g. Gimp 2.10 in Debian (and has been for 6 years already). I'm hereby sending a lot of positive energy to myPaint devs to get on with it! :)

@nyov

This comment has been minimized.

nyov commented Jul 2, 2018

@jbicha, would you be able to follow up on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894757 please? Is there a workaround or not, since upstream seems to be asleep on the matter? That'd be awesome, thanks!

@darix

This comment has been minimized.

darix commented Oct 16, 2018

any progress?

@nyov

This comment has been minimized.

nyov commented Oct 16, 2018

For debian yes, in as far as Gimp 2.10 is now in testing (using libmypaint), and there is simply a conflict with mypaint which doesn't allow the installation of mypaint in parallel with gimp/libmypaint.

Considering the user-base of Gimp in debian is about an order of magnitude higher than mypaint (~11000 vs ~1200), that seems like a decent solution until mypaint fixes itself.

.
(N.B. next debian release freeze is upcoming (start of 2019) and average debian release lifetime in recent times is ~750 days. Might be nice to resolve this conflict before then, I think.)

@mariodebian

This comment has been minimized.

mariodebian commented Oct 27, 2018

Hi.

I made a patch for mypaint/libmypaint to rename locale domain and install with new Gimp 2.10

052-rename-locale-mypaint12.patch.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment