Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-08-23 Thread Jack Underwood
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 ex

Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-08-15 Thread Jeremy Bicha
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

Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-08-15 Thread Adrian Bunk
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 > sev

Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-08-15 Thread Jeremy Bicha
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

Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-08-13 Thread Adrian Bunk
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: > > H

Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-07-08 Thread Chris Waters
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

Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-06-29 Thread Wojciech Aniszewski
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

Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-06-12 Thread Bernhard Schmidt
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 fil

Bug#894757: libmypaint-common: file conflict with mypaint-data

2018-04-03 Thread Jeremy Bicha
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