Bug#948087: future of aufs in Debian.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear all, I have create a RFH since I have currently no time due to personal issue s: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963191 I hope somebody can help with the maintaining. Best, Jan Am 26.05.20 um 16:33 schrieb Jan Luca Naumann: > Dear Peter, > > I am in general still active but due to private stuff I was quite > bad maintaining aufs the last months, I am really sorry. I will try > to take a look into the package at the weekend. Additionally, I > will create a RFH bug, maybe somebody wants to help me so there is > no single point of failure in the future. > > Best, Jan > > On 26.05.20 15:18, peter green wrote: >> The aufs package last saw a maintainer upload in September 2019 >> and was last-updated (by a NMU) in October 2019. It has had >> broken build-dependencies in testing for half a year now (since >> Linux 5.3.9-3 migrated to testing in November 2019). >> >> According to dak rm the aufs source-package has two >> reverse-dependencies, aufs-tools and fsprotect neither of which >> has any reverse-dependencies. >> >> Adrian filed a rc bug in November 2019 which received no >> maintainer response, however the package was not autoremoved from >> testing due to aufs and aufs-tools being considered a "key >> packages" due to high popcon. This popcon actually seems to be >> growing in both absolute and percentage terms. I presume the high >> popcon is due to some deriviative (hence debian-derivatives and >> debian-live in cc) using aufs in their live image builds (as far >> as I can tell debian's own live images seem to use overlayfs >> instead nowadays). >> >> aufs does seem to still be maintained upstream with upstream >> claiming support for Linux 5.6. >> >> According to contributors.debian.net Jan Luca Naumann (the aufs >> maintainer) was last active in September 2019. Jan: are you >> still around? and if so do you still intend to maintain the aufs >> package? if not is someone else going to step up to the plate? or >> should these packages be removed from testing? -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEwNbeTg2NJIWRcwSlfhHX8Rn5cbsFAl7t5xkACgkQfhHX8Rn5 cbtQIRAAoOQXpteSVFE/ssF81zS80AqOTSTCjLzh76oXc7/az6eHUZpdVrNkPqd/ Cbz+iZiO2NDdpfw0APPA3bKoC9s9R+J9EpOxx7zS5eb87R7xJDAvTk5oskHl8lYH V2oXcZvai8Rzf+l+sLKG2k3c4WRuoli/QxLZP8TnE0ySVqmtYOZCUUSeCRYwjLed qAT6vW/5mgCaIIynZMXwYNW5889h8AVIt+n9WOHYCYEtltRTDkJU+n6ZpNx2VhbE HdDS98T/RWhwNq2oZEIkQlfZfYp7yNP0MtThvCnPRML1dSZwuMTLd4/nrNaL3ITK MBjt0/IZ6wlp1E18kePfpaHFLX7ekqhBqTr5PmCiQzyPorcgCaEq6rTkwfReuLWR g58wQmx/8GkrYh4HcCziETSoODGscicskBkzipk6yT9lA9JDROFMqnu8mudUc5B5 /VocELuPiQaEql4h1G/tkoZ/KSkZterDFZ72ssYoYzLgJQxLLY1wSlVKovtKaMcX 5kJ3dzHjmjEO1IRfpbPyFJ5HaFlfTHAbkXx3Ll5saz08KiX+isHr6JGU+ZEt4O3R P4+rc8Z+gjTURY/2xHo8XRvehEyuoRYfHDaXOmR3a7pazt6e4TZ0bR1uyOsbJWhy StTmrl72U6dTEXk20IhJdMlG1pp7I0aMfoW85nl182TJwnhxFWc= =W+Dn -END PGP SIGNATURE-
Bug#948087: future of aufs in Debian.
On Wed, May 27, 2020 at 02:30:39PM -0700, Noah Meyerhans wrote: > On Tue, May 26, 2020 at 05:10:10PM +0300, Adrian Bunk wrote: > > > Adrian filed a rc bug in November 2019 which received no maintainer > > > response, however the package was not autoremoved from testing due to > > > aufs and aufs-tools being considered a "key packages" due to high popcon. > > > This popcon actually seems to be growing in both absolute and percentage > > > terms. I presume the high popcon is due to some deriviative (hence > > > debian-derivatives and debian-live in cc) using aufs in their live image > > > builds (as far as I can tell debian's own live images seem to use > > > overlayfs instead nowadays). > > >... > > > > It doesn't have to be a derivative, one webhoster who installs popcon by > > default is enough. > > It's very possible that it is the upstream Docker packaging that > accounts for the upward trend. The docker.io packages in the Debian > archive list aufs-tools as "Suggests", so they won't be pulled in by > default, but the upstream docker-ce packages distributed directly by > Docker still have them at Recommends. > > Docker no longer users aufs by default, though, having switched to > overlayfs some time ago. If it is wrong for them to pull in something they aren't using anymore, that's worth reporting. > I'm sure we could get them to drop the > Recommends if we're considering getting rid of it. Everything mentioned is only "it is possible that aufs might not be in Debian 11 when it releases mid-2021, unless someone fixes it in time for the release (which is likely)". Using it in buster is fine for any user even in the unlikely case it would not be in bullseye. It should be news to noone that popcon data is only very approximate for actual usage. It can give a hint regarding what is popular, but its data should be taken with a barrel of salt. > noah cu Adrian
Bug#948087: future of aufs in Debian.
On Wed, 27 May 2020 at 14:33, Noah Meyerhans wrote: > Docker no longer users aufs by default, though, having switched to > overlayfs some time ago. I'm sure we could get them to drop the > Recommends if we're considering getting rid of it. This is something I'd been considering for quite a while now and hadn't gotten around to, so thanks for the push! I've filed [1] now. :) [1]: https://github.com/docker/docker-ce-packaging/pull/472 ♥, - Tianon 4096R / B42F 6819 007F 00F8 8E36 4FD4 036A 9C25 BF35 7DD4
Bug#948087: future of aufs in Debian.
On Tue, May 26, 2020 at 05:10:10PM +0300, Adrian Bunk wrote: > > Adrian filed a rc bug in November 2019 which received no maintainer > > response, however the package was not autoremoved from testing due to aufs > > and aufs-tools being considered a "key packages" due to high popcon. This > > popcon actually seems to be growing in both absolute and percentage terms. > > I presume the high popcon is due to some deriviative (hence > > debian-derivatives and debian-live in cc) using aufs in their live image > > builds (as far as I can tell debian's own live images seem to use overlayfs > > instead nowadays). > >... > > It doesn't have to be a derivative, one webhoster who installs popcon by > default is enough. It's very possible that it is the upstream Docker packaging that accounts for the upward trend. The docker.io packages in the Debian archive list aufs-tools as "Suggests", so they won't be pulled in by default, but the upstream docker-ce packages distributed directly by Docker still have them at Recommends. Docker no longer users aufs by default, though, having switched to overlayfs some time ago. I'm sure we could get them to drop the Recommends if we're considering getting rid of it. noah
Bug#948087: future of aufs in Debian.
Dear Peter, I am in general still active but due to private stuff I was quite bad maintaining aufs the last months, I am really sorry. I will try to take a look into the package at the weekend. Additionally, I will create a RFH bug, maybe somebody wants to help me so there is no single point of failure in the future. Best, Jan On 26.05.20 15:18, peter green wrote: > The aufs package last saw a maintainer upload in September 2019 and was > last-updated (by a NMU) in October 2019. It has had broken > build-dependencies in testing for half a year now (since Linux 5.3.9-3 > migrated to testing in November 2019). > > According to dak rm the aufs source-package has two > reverse-dependencies, aufs-tools and fsprotect neither of which has any > reverse-dependencies. > > Adrian filed a rc bug in November 2019 which received no maintainer > response, however the package was not autoremoved from testing due to > aufs and aufs-tools being considered a "key packages" due to high > popcon. This popcon actually seems to be growing in both absolute and > percentage terms. I presume the high popcon is due to some deriviative > (hence debian-derivatives and debian-live in cc) using aufs in their > live image builds (as far as I can tell debian's own live images seem to > use overlayfs instead nowadays). > > aufs does seem to still be maintained upstream with upstream claiming > support for Linux 5.6. > > According to contributors.debian.net Jan Luca Naumann (the aufs > maintainer) was last active in September 2019. Jan: are you still > around? and if so do you still intend to maintain the aufs package? if > not is someone else going to step up to the plate? or should these > packages be removed from testing?
Bug#948087: future of aufs in Debian.
On Tue, May 26, 2020 at 02:18:48PM +0100, peter green wrote: >... > Adrian filed a rc bug in November 2019 which received no maintainer response, > however the package was not autoremoved from testing due to aufs and > aufs-tools being considered a "key packages" due to high popcon. This popcon > actually seems to be growing in both absolute and percentage terms. I presume > the high popcon is due to some deriviative (hence debian-derivatives and > debian-live in cc) using aufs in their live image builds (as far as I can > tell debian's own live images seem to use overlayfs instead nowadays). >... It doesn't have to be a derivative, one webhoster who installs popcon by default is enough. phpmyadmin in stretch was a similar case, it went up to 10% popcon despite nothing in Debian installing it by default and no reverse dependencies (only a Suggests from a package with single-digit popcon). When the release team went through RC bugs key packages closer to the freeze phpmyadmin was removed from testing (and is not in buster). cu Adrian
Bug#948087: future of aufs in Debian.
The aufs package last saw a maintainer upload in September 2019 and was last-updated (by a NMU) in October 2019. It has had broken build-dependencies in testing for half a year now (since Linux 5.3.9-3 migrated to testing in November 2019). According to dak rm the aufs source-package has two reverse-dependencies, aufs-tools and fsprotect neither of which has any reverse-dependencies. Adrian filed a rc bug in November 2019 which received no maintainer response, however the package was not autoremoved from testing due to aufs and aufs-tools being considered a "key packages" due to high popcon. This popcon actually seems to be growing in both absolute and percentage terms. I presume the high popcon is due to some deriviative (hence debian-derivatives and debian-live in cc) using aufs in their live image builds (as far as I can tell debian's own live images seem to use overlayfs instead nowadays). aufs does seem to still be maintained upstream with upstream claiming support for Linux 5.6. According to contributors.debian.net Jan Luca Naumann (the aufs maintainer) was last active in September 2019. Jan: are you still around? and if so do you still intend to maintain the aufs package? if not is someone else going to step up to the plate? or should these packages be removed from testing?
