Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2
Georg Faerber: > Hi all, > > I've just uploaded 0.8.0-1 to unstable, which ships .epub support as > requested by some people and the patch to make the Nautilus extension > work. It should migrate on March 10 or the day after. > > On 19-02-26 11:31:21, Jonas Meurer wrote: >> After I slept a night over it, I realized that this plan doesn't take >> into account our options to still handle the mat1 -> mat2 transition >> in time for buster. After all we agreed on that mat(1) should better >> not be shipped with buster. Now that we have at least a Nautilus >> extension for mat2, there's no blocker for the mat -> mat2 transitoon >> anymore, no? > > You're right, I've missed this, thanks for keeping track of it. > >> If we ask ftpmasters and the Release Team for help, there might still >> be a chance to get a mat2 with a new transitional 'mat' binary package >> into buster, don't you think so? >> >> What do you think about the following: >> >> 1. Ask ftpmaster and Release Team for their opinions on this matter >> 2. Upload mat2 0.7.0-2 with new transitional binary package 'mat' >> 3. Since it will sit in NEW for a few days anyway, maybe 0.7.0-1 will >>transition to buster in the meantime. If not, no worries - we want to >>get 0.7.0-2 into buster anyway. >> >> Maybe you could give short replies on whether you're in favour of this >> plan. I would contact ftpmasters and Release Team as soon as I get >> some positive feedback. > > Sounds good -- in case you're too busy, I could also do it next week. I > think our chances that this gets accepted are pretty good. Turned out that it's much easier than that: * Source packages that take over existing binary packages don't have to go through NEW. After Georg uploaded 0.8.0-2 with the new transitional binary package to experimental yesterday, I went ahead today and uploaded mat2 0.8.0-3 to unstable just now. * The soft freeze only blocks new *source* packages from transitioning to buster. So if all goes well, mat2 0.8.0-3 with the new transitional binary package 'mat' will enter buster in time, without us needing to ask for a freeze exception at all. > I would also fill the RM bug against mat to get it removed; > @intrigeri / dkg: Could you give a short ACK on this? Well, we decided to go ahead. Hope that's fine with you, intrigeri and dkg. Cheers jonas signature.asc Description: OpenPGP digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2
Hi all, I've just uploaded 0.8.0-1 to unstable, which ships .epub support as requested by some people and the patch to make the Nautilus extension work. It should migrate on March 10 or the day after. On 19-02-26 11:31:21, Jonas Meurer wrote: > After I slept a night over it, I realized that this plan doesn't take > into account our options to still handle the mat1 -> mat2 transition > in time for buster. After all we agreed on that mat(1) should better > not be shipped with buster. Now that we have at least a Nautilus > extension for mat2, there's no blocker for the mat -> mat2 transitoon > anymore, no? You're right, I've missed this, thanks for keeping track of it. > If we ask ftpmasters and the Release Team for help, there might still > be a chance to get a mat2 with a new transitional 'mat' binary package > into buster, don't you think so? > > What do you think about the following: > > 1. Ask ftpmaster and Release Team for their opinions on this matter > 2. Upload mat2 0.7.0-2 with new transitional binary package 'mat' > 3. Since it will sit in NEW for a few days anyway, maybe 0.7.0-1 will >transition to buster in the meantime. If not, no worries - we want to >get 0.7.0-2 into buster anyway. > > Maybe you could give short replies on whether you're in favour of this > plan. I would contact ftpmasters and Release Team as soon as I get > some positive feedback. Sounds good -- in case you're too busy, I could also do it next week. I think our chances that this gets accepted are pretty good. I would also fill the RM bug against mat to get it removed; @intrigeri / dkg: Could you give a short ACK on this? Thanks, cheers, Georg signature.asc Description: Digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2
Hi all, Georg Faerber: > On 19-02-22 23:26:45, Jonas Meurer wrote: >> I skimmed through the patch and it looks good to me. I also did some >> rough testing and at least with my test files it worked as expected. >> >> I merged jvoisin's changes into the d/0.7.0-2 branch. > > Thanks a lot for your inputs, reviews and changes -- highly appreciated. > > I've got some serious issues currently with my keyboard, which makes > working at my PC quite a pain, but I'll take care of the upload in time > to ensure -2 will migrate before the full freeze on March 12th. > > My current plan looks like the following: > > - Let -1 migrate to testing, which should happen on Thursday, February > 28th. > > This is to ensure a minimal diff between testing and unstable, in case > the migration of -2 gets delayed for whatever reason, -2 won't > therefore migrate before the full freeze, and we need to ask for an > freeze exception. AFAIK, minimal diffs have a higher chance to be > accepted than bigger ones. > > - I'll upload -2 either tomorrow or the day after via the delayed queue, > or on Thursday. In any case, -2 should migrate on March 10th, if all > goes well. I'm on travel, so can't pinpoint a specific time now, but > be assured that the upload is upcoming. > > - I plan to pull in three upstream bug fixes as well, see [1], [2] and [3]. After I slept a night over it, I realized that this plan doesn't take into account our options to still handle the mat1 -> mat2 transition in time for buster. After all we agreed on that mat(1) should better not be shipped with buster. Now that we have at least a Nautilus extension for mat2, there's no blocker for the mat -> mat2 transitoon anymore, no? If we ask ftpmasters and the Release Team for help, there might still be a chance to get a mat2 with a new transitional 'mat' binary package into buster, don't you think so? What do you think about the following: 1. Ask ftpmaster and Release Team for their opinions on this matter 2. Upload mat2 0.7.0-2 with new transitional binary package 'mat' 3. Since it will sit in NEW for a few days anyway, maybe 0.7.0-1 will transition to buster in the meantime. If not, no worries - we want to get 0.7.0-2 into buster anyway. Maybe you could give short replies on whether you're in favour of this plan. I would contact ftpmasters and Release Team as soon as I get some positive feedback. Cheers jonas signature.asc Description: OpenPGP digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2
Hi all, On 19-02-22 23:26:45, Jonas Meurer wrote: > I skimmed through the patch and it looks good to me. I also did some > rough testing and at least with my test files it worked as expected. > > I merged jvoisin's changes into the d/0.7.0-2 branch. Thanks a lot for your inputs, reviews and changes -- highly appreciated. I've got some serious issues currently with my keyboard, which makes working at my PC quite a pain, but I'll take care of the upload in time to ensure -2 will migrate before the full freeze on March 12th. My current plan looks like the following: - Let -1 migrate to testing, which should happen on Thursday, February 28th. This is to ensure a minimal diff between testing and unstable, in case the migration of -2 gets delayed for whatever reason, -2 won't therefore migrate before the full freeze, and we need to ask for an freeze exception. AFAIK, minimal diffs have a higher chance to be accepted than bigger ones. - I'll upload -2 either tomorrow or the day after via the delayed queue, or on Thursday. In any case, -2 should migrate on March 10th, if all goes well. I'm on travel, so can't pinpoint a specific time now, but be assured that the upload is upcoming. - I plan to pull in three upstream bug fixes as well, see [1], [2] and [3]. In case you have any objections, please shout. Thanks again, cheers, Georg [1] https://0xacab.org/jvoisin/mat2/commit/c757a9b7ef3122ea19105ca47a323e81469da594 [2] https://0xacab.org/jvoisin/mat2/commit/524bae597209d775828bd176f6c00dd243f47c75 [3] https://0xacab.org/jvoisin/mat2/commit/545dccc3527fcdf851b30b072ae6c7222b711777 signature.asc Description: Digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2
Hi,
On 19-02-12 14:33:31, Georg Faerber wrote:
> On 19-01-27 22:44:24, intrigeri wrote:
> > Other data points & ideas:
> >
> > - Given the python-nautilus issue essentially requires a transition,
> >I doubt we'll find some way to provide desktop integration for mat2
> >via buster-backports.
> >
> > - One could quickly patch together a Python 2 Nautilus extension that
> >wraps mat2's CLI, or the simplest possible Python 3 GUI that does
> >not depend on python-nautilus. I'm sure lots of users would be
> >thankful if someone did this. There's very little time left to get
> >this done and through NEW. But it could be an option for
> >buster-backports.
>
> ... I would somehow continue what I said and try to tackle option one.
> Also, if I'm not mistaken, adding such an extension wouldn't need to
> go trough NEW, and IMHO, it is quite easy to justify adding this even
> now within the soft freeze: The change isn't that intrusive, we could
> test beforehand, and it clearly targets an "isolated" issue.
That is: option one of the second proposal ("quickly patch together a
Python 2 Nautilus extension that wraps mat2's CLI").
Cheers,
Georg
signature.asc
Description: Digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2
Hi, On 19-01-31 18:28:02, Jonas Meurer wrote: > Georg Faerber: > > I'll tacke this, although I might need support and of course, at least > > one review. > > Wow, that would be awesome. I think I would be up for a review. Great! :) > Jeremy said this to me when we privately discussed the topic on IRC. > Might still be a good idea to get his consensus on an official channel > (e.g. the bugreport). I just made this explicit via asking him in the issue. Cheers, Georg signature.asc Description: Digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2
Hey Georg! Georg Faerber: >> There's still a chance to get it in: if we craft a patch for >> nautilus-python that introduces a new package python3-nautilus which >> is co-installable (and doesn't conflict) with python-nautilus, then >> the nautilus-python maintainer already said that he would consider to >> accept it in time for Buster. [1] > > Thanks Jonas for your work over there! > >> That basically means that we have to copy libpython-nautilus.c to >> libpython3-nautilus.c, introduce a new extension include path for it >> (probably /usr/share/python3-nautilus/extensions/) and patch the build >> system to build libpython-nautilus.c only for python2 and >> libpython3-nautilus.c only for python3. >> >> Unfortunately I'm unsure whether I find time to work on such a patch >> within the next week (which probably would be necessary to get the >> package into the archive in time, since it has to pass NEW). >> >> If anybody wants to pick up the work, here's my related PR (which >> doesn't do what I explained above yet, but should be a starting >> point): >> >> https://salsa.debian.org/gnome-team/nautilus-python/merge_requests/1 > > I'll tacke this, although I might need support and of course, at least > one review. Wow, that would be awesome. I think I would be up for a review. > The only which wonders me: Jeremy Bicha, the maintainer, said in the > linked issue initially that this probably wouldn't make it into buster. > Granted, if we follow Jonas' proposal as per above, this expressed view > would change. Wouldn't it be a good idea to get consensus on this plan > of action before doing the actual work? So far, there was no response. Jeremy said this to me when we privately discussed the topic on IRC. Might still be a good idea to get his consensus on an official channel (e.g. the bugreport). Cheers jonas signature.asc Description: OpenPGP digital signature
Bug#910493: [Pkg-privacy-maintainers] Bug#910493: Bug#910493: Handle transition from MAT to MAT2
Hi all, Sorry for my late reply, I just returned from traveling six weeks without my PC. On 19-01-29 00:16:55, Jonas Meurer wrote: > thanks for picking up the discussion about mat/mat2 in Buster! Seconded, thanks a lot. > There's still a chance to get it in: if we craft a patch for > nautilus-python that introduces a new package python3-nautilus which > is co-installable (and doesn't conflict) with python-nautilus, then > the nautilus-python maintainer already said that he would consider to > accept it in time for Buster. [1] Thanks Jonas for your work over there! > That basically means that we have to copy libpython-nautilus.c to > libpython3-nautilus.c, introduce a new extension include path for it > (probably /usr/share/python3-nautilus/extensions/) and patch the build > system to build libpython-nautilus.c only for python2 and > libpython3-nautilus.c only for python3. > > Unfortunately I'm unsure whether I find time to work on such a patch > within the next week (which probably would be necessary to get the > package into the archive in time, since it has to pass NEW). > > If anybody wants to pick up the work, here's my related PR (which > doesn't do what I explained above yet, but should be a starting > point): > > https://salsa.debian.org/gnome-team/nautilus-python/merge_requests/1 I'll tacke this, although I might need support and of course, at least one review. The only which wonders me: Jeremy Bicha, the maintainer, said in the linked issue initially that this probably wouldn't make it into buster. Granted, if we follow Jonas' proposal as per above, this expressed view would change. Wouldn't it be a good idea to get consensus on this plan of action before doing the actual work? So far, there was no response. Thanks again, cheers, Georg signature.asc Description: Digital signature
