Re: Removing a package from unstable
sounds awesome :) On Sun, Jan 6, 2019 at 10:54 PM Svante Signell wrote: > > On Sun, 2019-01-06 at 18:37 +0100, Mattia Rizzolo wrote: > > On Sun, Jan 06, 2019 at 04:41:51PM +0100, Ole Streicher wrote: > > > That is a different thing: once the dependencies on Hurd are fixed, > > > you > > > > Of course the hurd issue turned out more complex once I actually read > > past the first post, btw… > > > > > get python3-astropy back on that platform, independently whether > > > python-astropy was removed or not. If the dependencies remain > > > unfixed, I will remove python-astropy anyway at some point. > > > > sure. > > > > > But if you fix it, I can wait a while before requesting removal. Is > > > a week enough? > > > > Hardly, I don't think I can squash in also that in my schedule. > > I have preliminary patches of python-psutil for kFreeBSD now, and will > soon have patches for Hurd too. How does that sound? > -- regards, Mattia Rizzolo GPG Key: 4096R/B9444540 http://goo.gl/I8TMB more about me: http://mapreri.org Launchpad User: https://launchpad.net/~mapreri Ubuntu Wiki page: https://wiki.ubuntu.com/MattiaRizzolo
Re: Removing a package from unstable
On Sun, 2019-01-06 at 18:37 +0100, Mattia Rizzolo wrote: > On Sun, Jan 06, 2019 at 04:41:51PM +0100, Ole Streicher wrote: > > That is a different thing: once the dependencies on Hurd are fixed, > > you > > Of course the hurd issue turned out more complex once I actually read > past the first post, btw… > > > get python3-astropy back on that platform, independently whether > > python-astropy was removed or not. If the dependencies remain > > unfixed, I will remove python-astropy anyway at some point. > > sure. > > > But if you fix it, I can wait a while before requesting removal. Is > > a week enough? > > Hardly, I don't think I can squash in also that in my schedule. I have preliminary patches of python-psutil for kFreeBSD now, and will soon have patches for Hurd too. How does that sound?
Re: Removing a package from unstable
On Sun, Jan 06, 2019 at 04:41:51PM +0100, Ole Streicher wrote: > That is a different thing: once the dependencies on Hurd are fixed, you Of course the hurd issue turned out more complex once I actually read past the first post, btw… > get python3-astropy back on that platform, independently whether > python-astropy was removed or not. If the dependencies remain unfixed, I > will remove python-astropy anyway at some point. sure. > But if you fix it, I can wait a while > before requesting removal. Is a week enough? Hardly, I don't think I can squash in also that in my schedule. > > As I stated, removing from testing looks much simpler > > But it would happen automatically once the package is not in unstable, > right? Yup. My suggestion was to get it out of buster sooner, as that would "fix" the autopkgtest regression of numpy. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Removing a package from unstable
Mattia Rizzolo writes: > On Sat, Jan 05, 2019 at 09:24:06PM +0100, Ole Streicher wrote: >> I have a source package (python-astropy) that I now want to remove from >> unstable. I took care that all reverse dependencies were removed now in >> recent uploads. As suggested in [1], I first issued >> >> $ ssh mirror.ftp-master.debian.org "dak rm -Rn python-astropy" >> >> to see whether it would run without errors. The output is however: > […] >> In total, more than 50 mpackages are listed. Many of them because of the >> python3-astropy (build) dependency in hurd (which is unavoidable to >> break, but that is not a release platform anyway); but also a lot of old >> cruft. I though that this would be removed automatically? > > cruft is not automatically removed as long as it would break stuff, > like in this case… > You say "unavoidable", but to me it seems: > * hurd is blocked because src:astropy doesn't build simply because >src:python-psutil is not building which is very simply because of >#676450 which has a patch for 6 years and is team maintained even! > * kbsd is not building because of a known issue in src:python3.7 that >misdetects the avalability of sem_open() on kbsd, but alas the kbsd >porters are too few and despute knowing the issue they can't work on >them; however I've also been assured that it's not that hard to fix, >so I guess somebody caring enough could try spending some time on >this (in which case, let me point you to James Clark, he looked a bit >at the issue in the past, he could tell you where to look). That is a different thing: once the dependencies on Hurd are fixed, you get python3-astropy back on that platform, independently whether python-astropy was removed or not. If the dependencies remain unfixed, I will remove python-astropy anyway at some point. >> So what is the correct way now to get the package removed? > > You could go ahead on the bug report, listing the rdeps that you > investigated and stating that you are willing to break them. > However, looking at how many there are, I think that would be rude and > as a supporter of the ports project I try my best to fix such issues > before going the way of breaking the rdeps. At least the hurd one looks > incredibly trivial to deal with from a quick glance. All these rdeps would come back automatically once someone fixes the dependencies. And I do not assume any user of Hurd-unstable-python3-astropy. But if you fix it, I can wait a while before requesting removal. Is a week enough? > As I stated, removing from testing looks much simpler But it would happen automatically once the package is not in unstable, right? Cheers Ole
Re: Removing a package from unstable
On Sat, Jan 05, 2019 at 09:24:06PM +0100, Ole Streicher wrote: > I have a source package (python-astropy) that I now want to remove from > unstable. I took care that all reverse dependencies were removed now in > recent uploads. As suggested in [1], I first issued > > $ ssh mirror.ftp-master.debian.org "dak rm -Rn python-astropy" > > to see whether it would run without errors. The output is however: […] > In total, more than 50 mpackages are listed. Many of them because of the > python3-astropy (build) dependency in hurd (which is unavoidable to > break, but that is not a release platform anyway); but also a lot of old > cruft. I though that this would be removed automatically? cruft is not automatically removed as long as it would break stuff, like in this case… You say "unavoidable", but to me it seems: * hurd is blocked because src:astropy doesn't build simply because src:python-psutil is not building which is very simply because of #676450 which has a patch for 6 years and is team maintained even! * kbsd is not building because of a known issue in src:python3.7 that misdetects the avalability of sem_open() on kbsd, but alas the kbsd porters are too few and despute knowing the issue they can't work on them; however I've also been assured that it's not that hard to fix, so I guess somebody caring enough could try spending some time on this (in which case, let me point you to James Clark, he looked a bit at the issue in the past, he could tell you where to look). > So what is the correct way now to get the package removed? You could go ahead on the bug report, listing the rdeps that you investigated and stating that you are willing to break them. However, looking at how many there are, I think that would be rude and as a supporter of the ports project I try my best to fix such issues before going the way of breaking the rdeps. At least the hurd one looks incredibly trivial to deal with from a quick glance. As I stated, removing from testing looks much simpler though: % dak rm -Rn -s testing python-astropy Will remove the following packages from testing: python-astropy |2.0.9-1 | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x Maintainer: Debian Astronomy Maintainers --- Reason --- -- Checking reverse dependencies... # Broken Build-Depends: pyregion: python-astropy veusz: python-astropy Dependency problem found. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
