Bug#894757: libmypaint-common: file conflict with mypaint-data
Just a thought, but does the file conflict actually produce the exact same files? I.e. can we just disablethese files from either mypaint-data or libmypaint-common (probably from mypaint-data as this lookslike the older package, and then have it depend on the other to ensure that those files exist on the system? Then mypaint can take its own sweet time in releasing its next version :).
Bug#894757: libmypaint-common: file conflict with mypaint-data
On Wed, Aug 15, 2018 at 11:31 AM Adrian Bunk wrote: > The bug was RC, and this was fixed in 1.3.0-2. It wasn't fixed because I opened bug 894757 because of the Conflicts relationship so it's really the same as bug 906144. > No maintainer activity or answer to the suggestion for 4 months. You're welcome to NMU mypaint. The solution I prefer is packaging a git snapshot of mypaint but you're free to choose another solution. One advantage of having the new version of gimp stuck in unstable was that maybe it could encourage someone to care enough to try to fix this bug. But that didn't really happen here. Thanks, Jeremy Bicha
Bug#894757: libmypaint-common: file conflict with mypaint-data
On Wed, Aug 15, 2018 at 11:15:22AM -0400, Jeremy Bicha wrote: > On Mon, Aug 13, 2018 at 4:43 PM Adrian Bunk wrote: > > I'm closing this bug, and cloning a second to track that a proper > > solution is still required. > > Uh, respectfully, why did you do that? You could have just lowered the > severity of this bug if you think it's not RC. The bug was RC, and this was fixed in 1.3.0-2. > But even there I > disagree: it is clearly RC that gimp can't be co-installable with > mypaint. Feel free to change the severity of #906144. > Your action allowed the new version of gimp to migrate to Testing > which I know lots of people wanted, but I don't think it's a good idea > to knowingly introduce this kind of bug to Testing. No maintainer activity or answer to the suggestion for 4 months. And several packages waiting for it. I actually started looking at this for getting gmic from the autoremoval list. Short-term the breakage isn't that bad, it mainly makes it impossible for testing users who have both mypaint and gimp installed to upgrade the affected packages. > Thanks, > Jeremy Bicha cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#894757: libmypaint-common: file conflict with mypaint-data
On Mon, Aug 13, 2018 at 4:43 PM Adrian Bunk wrote: > I'm closing this bug, and cloning a second to track that a proper > solution is still required. Uh, respectfully, why did you do that? You could have just lowered the severity of this bug if you think it's not RC. But even there I disagree: it is clearly RC that gimp can't be co-installable with mypaint. Your action allowed the new version of gimp to migrate to Testing which I know lots of people wanted, but I don't think it's a good idea to knowingly introduce this kind of bug to Testing. Thanks, Jeremy Bicha
Bug#894757: libmypaint-common: file conflict with mypaint-data
Control: clone -1 -2 Control: close -1 1.3.0-2 Control: retitle -2 libmypaint-common needs solution to co-exist with mypaint-data Control: severity -2 important On Tue, Jun 12, 2018 at 10:28:04AM +0200, Bernhard Schmidt wrote: > On Tue, Apr 03, 2018 at 05:43:10PM -0400, Jeremy Bicha wrote: > > Hi Jeremy, > > > Package: libmypaint-common > > Version: 1.3.0-1 > > Severity: serious > > Forwarded: https://github.com/mypaint/mypaint/issues/918 > > > > libmypaint-common ships some of the same file names as mypaint-data > > (the libmypaint.mo files). > > > > I'm going to go ahead and add "Conflicts: mypaint-data" now. The way > > forward is to have mypaint use libmypaint. When that happens, we can > > add "Replaces: mypaint-data" too and close this bug. > > This bug is still open and preventing the migration of libmypaint and > GIMP 2.10 to testing. As far as I can see you worked around this issue > in 1.3.0-2, right? Setting this version as fixed would allow the stack > to migrate. I'm closing this bug, and cloning a second to track that a proper solution is still required. > Bernhard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#894757: libmypaint-common: file conflict with mypaint-data
One possible solution here is to change the translation domain used either by libmypaint or by mypaint. I think it would be better to change the domain used by mypaint (to, e.g., "mypaint12"), since that change would only have to be a temporary one, until the next version comes out, which will (if I understand correctly) *use* libmypaint. But of course, you'd have to coordinate with the maintainer(s) to make that happen. I took a look at the mypaint source, and unfortunately they don't have a centralized location where the translation domain is defined. (Say what you want about autoconf, but if they used it, this wouldn't have been a problem.) I think I *might* be able to make a patch, but it's enough effort (without autoconf) that I'd want to know the mypaint maintainer was interested before I bothered. Or you could change the translation domain used by libmypaint (perhaps to "libmypaint"), but that is a lesser solution, since the patch wouldn't have a clearly defined expiration date.
Bug#894757: libmypaint-common: file conflict with mypaint-data
I think it would be practical and justified to disable translations in libmypaint, as Jeremy suggested in here (https://github.com/mypaint/mypaint/issues/918). If that's a problem for mypaint itself, too bad, perhaps it will make the upstream wake up from their hibernation and finally act. Thing is, mypaint, with all respect due, has approx 1200 users in popcon. Gimp has 11; pushing it to 2.10 is important. best w -- /^..^\ ( (••) ) (|)_._(|)~ GPG key ID:AC66485E signature.asc Description: PGP signature
Bug#894757: libmypaint-common: file conflict with mypaint-data
On Tue, Apr 03, 2018 at 05:43:10PM -0400, Jeremy Bicha wrote: Hi Jeremy, > Package: libmypaint-common > Version: 1.3.0-1 > Severity: serious > Forwarded: https://github.com/mypaint/mypaint/issues/918 > > libmypaint-common ships some of the same file names as mypaint-data > (the libmypaint.mo files). > > I'm going to go ahead and add "Conflicts: mypaint-data" now. The way > forward is to have mypaint use libmypaint. When that happens, we can > add "Replaces: mypaint-data" too and close this bug. This bug is still open and preventing the migration of libmypaint and GIMP 2.10 to testing. As far as I can see you worked around this issue in 1.3.0-2, right? Setting this version as fixed would allow the stack to migrate. Bernhard
Bug#894757: libmypaint-common: file conflict with mypaint-data
Package: libmypaint-common Version: 1.3.0-1 Severity: serious Forwarded: https://github.com/mypaint/mypaint/issues/918 libmypaint-common ships some of the same file names as mypaint-data (the libmypaint.mo files). I'm going to go ahead and add "Conflicts: mypaint-data" now. The way forward is to have mypaint use libmypaint. When that happens, we can add "Replaces: mypaint-data" too and close this bug. I guess we're waiting for mypaint to do its 1.3 release then. Thanks, Jeremy Bicha
