Bug#960649: Removed package(s) from unstable
On Mon, 2020-05-18 at 20:40 +0200, Mattias Ellert wrote: > 1. Have you removed the 2.6.8-1 version? It is still listed as being > part of unstable here: https://packages.debian.org/unstable/gfal2 > I know there is some delay in those pages to be updated, but getting > THAT VERSION removed was the purpose of filing the bug in the first > place. If it is not removed, the problem is not solved. That page looks suspicious as it claims arm64 is an "unoffical port". Someone on IRC suspects it might use an ancient Packages index from ports.d.o from 2014 for arm64 that gets shown when the main archive no longer has the package... I would recommend either using the Packages/Sources indices from mirrors (with delayed updates) or the `rmadison` tool from the devscripts package which accesses the authoritative database used by dak. `rmadison` is probably better as there are no delays with updates and sometimes a package is not shown in the Packages index. The current state in the archive is this: $ rmadison -S -s unstable gfal2 gfal2| 2.17.3-1 | unstable | source, all gfal2-doc| 2.17.3-1 | unstable | all gfal2-plugin-dcap| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-file| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-gridftp | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-http| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-mock| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-sftp| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x gfal2-plugin-srm | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal-transfer2| 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal2-2 | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x libgfal2-dev | 2.17.3-1 | unstable | amd64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x > 2. Is a re-upload really necessary? A re-upload wouldn't end up in NEW > anyway, since no new binary packages would be created by the new upload > that are not already in unstable (except for on arm64). If the existing > binary arm64 build can't be put back in, a binnmu for arm64 should be > sufficient. It would be wasteful to rebuild the package for all > architectures. I restored the arm64 binaries (2.17.3-1). Ansgar
Bug#960649: Removed package(s) from unstable
If you can re-upload the package, I can give it a quick trip through New. Scott K On May 18, 2020 3:17:26 PM UTC, Mattias Ellert wrote: >> This message was generated automatically; if you believe that there >is >> a problem with it please contact the archive administrators by >mailing >> ftpmas...@ftp-master.debian.org. > >Hi FTP masters. > >Sorry, but What I tried to request from you was not what happened. >Possibly, my request was not clear. > >My request was to remove the BINARY package gfal2 built for arm64, not >all binary packages built for arm64 from the SOURCE package gfal2. > >As far as I could tell from the description of the "NBS" tag, I was >supposed to list binary packages in the request... > >Before this change was done the 2.17.3-1 version of gfal2 was built for >all architectures, including arm64. And I had no intent to request the >removal of any of those. They were all good. Including the arm64 >versions. > >The problem was that in addition to this, unstable also contains a very >old 2.6.8-1 version for arm64. It was this version I wanted to have >removed. > >Before you did your change, only the gfal2 binary package from this old >arm64 build was visible. The reason being that the new build did not >provide an arch specific arm64 gfal2 binary package, since this package >is arch independent in the current version. > >Now that you have removed the current version of all the arm64 binary >packages, the really really old 2.6.8-1 became the "current" version >for arm64 for all binary packages. > >So now, not only the gfal2 binary package for arm64 (which was the one >I wanted to remove, but it is still there) is at version 2.6.8-1 - but >all binary packages built from the gfal2 source package is at this >version for arm64. So your interpretation of my request made the >problem worse rather than fixing it. > >To recover - remove the 2.6.8-1 version that is now "current" for >arm64, then put back the 2.17.3-1 version that was removed in error. > > Mattias > > >sön 2020-05-17 klockan 05:07 + skrev Debian FTP Masters: >> We believe that the bug you reported is now fixed; the following >> package(s) have been removed from unstable: >> >> gfal2-plugin-dcap | 2.17.3-1 | arm64 >> gfal2-plugin-file | 2.17.3-1 | arm64 >> gfal2-plugin-gridftp | 2.17.3-1 | arm64 >> gfal2-plugin-http | 2.17.3-1 | arm64 >> gfal2-plugin-mock | 2.17.3-1 | arm64 >> gfal2-plugin-sftp | 2.17.3-1 | arm64 >> gfal2-plugin-srm | 2.17.3-1 | arm64 >> libgfal-transfer2 | 2.17.3-1 | arm64 >> libgfal2-2 | 2.17.3-1 | arm64 >> libgfal2-dev | 2.17.3-1 | arm64 >> >> --- Reason --- >> ROM; NBS >> -- >> >> Note that the package(s) have simply been removed from the tag >> database and may (or may not) still be in the pool; this is not a >bug. >> The package(s) will be physically removed automatically when no suite >> references them (and in the case of source, when no binary references >> it). Please also remember that the changes have been done on the >> master archive and will not propagate to any mirrors until the next >> dinstall run at the earliest. >> >> Packages are usually not removed from testing by hand. Testing tracks >> unstable and will automatically remove packages which were removed >> from unstable when removing them from testing causes no dependency >> problems. The release team can force a removal from testing if it is >> really needed, please contact them if this should be the case. >> >> Bugs which have been reported against this package are not >automatically >> removed from the Bug Tracking System. Please check all open bugs and >> close them or re-assign them to another package if the removed >package >> was superseded by another one. >> >> The version of this package that was in Debian prior to this removal >> can still be found using http://snapshot.debian.org/. >> >> Thank you for reporting the bug, which will now be closed. If you >> have further comments please address them to 960...@bugs.debian.org. >> >> The full log for this bug can be viewed at >https://bugs.debian.org/960649 >> >> This message was generated automatically; if you believe that there >is >> a problem with it please contact the archive administrators by >mailing >> ftpmas...@ftp-master.debian.org. >> >> Debian distribution maintenance software >> pp. >> Scott Kitterman (the ftpmaster behind the curtain)
Bug#960649: Removed package(s) from unstable
> This message was generated automatically; if you believe that there is > a problem with it please contact the archive administrators by mailing > ftpmas...@ftp-master.debian.org. Hi FTP masters. Sorry, but What I tried to request from you was not what happened. Possibly, my request was not clear. My request was to remove the BINARY package gfal2 built for arm64, not all binary packages built for arm64 from the SOURCE package gfal2. As far as I could tell from the description of the "NBS" tag, I was supposed to list binary packages in the request... Before this change was done the 2.17.3-1 version of gfal2 was built for all architectures, including arm64. And I had no intent to request the removal of any of those. They were all good. Including the arm64 versions. The problem was that in addition to this, unstable also contains a very old 2.6.8-1 version for arm64. It was this version I wanted to have removed. Before you did your change, only the gfal2 binary package from this old arm64 build was visible. The reason being that the new build did not provide an arch specific arm64 gfal2 binary package, since this package is arch independent in the current version. Now that you have removed the current version of all the arm64 binary packages, the really really old 2.6.8-1 became the "current" version for arm64 for all binary packages. So now, not only the gfal2 binary package for arm64 (which was the one I wanted to remove, but it is still there) is at version 2.6.8-1 - but all binary packages built from the gfal2 source package is at this version for arm64. So your interpretation of my request made the problem worse rather than fixing it. To recover - remove the 2.6.8-1 version that is now "current" for arm64, then put back the 2.17.3-1 version that was removed in error. Mattias sön 2020-05-17 klockan 05:07 + skrev Debian FTP Masters: > We believe that the bug you reported is now fixed; the following > package(s) have been removed from unstable: > > gfal2-plugin-dcap | 2.17.3-1 | arm64 > gfal2-plugin-file | 2.17.3-1 | arm64 > gfal2-plugin-gridftp | 2.17.3-1 | arm64 > gfal2-plugin-http | 2.17.3-1 | arm64 > gfal2-plugin-mock | 2.17.3-1 | arm64 > gfal2-plugin-sftp | 2.17.3-1 | arm64 > gfal2-plugin-srm | 2.17.3-1 | arm64 > libgfal-transfer2 | 2.17.3-1 | arm64 > libgfal2-2 | 2.17.3-1 | arm64 > libgfal2-dev | 2.17.3-1 | arm64 > > --- Reason --- > ROM; NBS > -- > > Note that the package(s) have simply been removed from the tag > database and may (or may not) still be in the pool; this is not a bug. > The package(s) will be physically removed automatically when no suite > references them (and in the case of source, when no binary references > it). Please also remember that the changes have been done on the > master archive and will not propagate to any mirrors until the next > dinstall run at the earliest. > > Packages are usually not removed from testing by hand. Testing tracks > unstable and will automatically remove packages which were removed > from unstable when removing them from testing causes no dependency > problems. The release team can force a removal from testing if it is > really needed, please contact them if this should be the case. > > Bugs which have been reported against this package are not automatically > removed from the Bug Tracking System. Please check all open bugs and > close them or re-assign them to another package if the removed package > was superseded by another one. > > The version of this package that was in Debian prior to this removal > can still be found using http://snapshot.debian.org/. > > Thank you for reporting the bug, which will now be closed. If you > have further comments please address them to 960...@bugs.debian.org. > > The full log for this bug can be viewed at https://bugs.debian.org/960649 > > This message was generated automatically; if you believe that there is > a problem with it please contact the archive administrators by mailing > ftpmas...@ftp-master.debian.org. > > Debian distribution maintenance software > pp. > Scott Kitterman (the ftpmaster behind the curtain) signature.asc Description: This is a digitally signed message part
