Your message dated Sat, 22 Jul 2017 07:58:35 +0000 with message-id <e1dypj5-0006zq...@fasolo.debian.org> and subject line Bug#864783: Removed package(s) from stable has caused the Debian Bug report #864783, regarding RM: aiccu -- RoM; useless since shutdown of SixXS to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 864783: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864783 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: release.debian.org Severity: normal User: release.debian....@packages.debian.org Usertags: rm Control: severity 863720 serious Control: found 863720 20070115-14 Hi, the sunset of SixXS has passed, see https://bugs.debian.org/863720 for details and discussion. And unfortunately, neither * SixXS changed their mind, nor * did SixXS open-source the server implementation, nor * did someone else come up with an AYIYA(*) server implementation or a comparable service. There though seems to be one ISP though which uses aiccu to setup tunnels for his own customers, but also only for them as the authentication seems to be based on the MAC address from where the TIC(**) request comes from. See https://en.wikipedia.org/wiki/AICCU#Usage and http://n6.netbox.cz/mediawiki/index.php/AICCU (the latter is in Czech language only.) I also doubt that they've implemented an AYIYA server for the tunnel and suspect they use other tunnel types. https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers also lists AARNet as existing tunnel broker and at least in the past this broker was supported by aiccu officially. (See https://web.archive.org/web/20061026034634/http://www.sixxs.net/tools/aiccu/brokers/.) And http://broker.aarnet.net.au/ indeed still exists. But then again they're listed as "broken" on Wikipedia. And the TIC server implementation I found on CPAN (https://metacpan.org/pod/Net::SixXS::TIC::Server) is rather esoteric respectively academic. While it seems to be able to communicate with aiccu, no according AYIYA server implementation showed up so you can only use it with tunnel protocols where better clients exist anyways. So the only production-mode way to still use aiccu is with Netbox.cz while being one of their customers. But neither Mike (AFAIK) nor I are customers of Netbox.cz. Hence I must agree with a heavy heart that it indeed is better to remove aiccu from Stretch as we can't really fully test it anymore for e.g. stable security updates or so. Other distributions have removed aiccu as well, e.g. OpenWRT at https://github.com/openwrt/packages/commit/441f8a3e So please remove aiccu from Stretch. There seem to be no reverse dependencies and also no reverse build dependencies. Mike and me agreed to keep it around in Debian Unstable for at least a few more months in the hope that any of the above mentioned events still happen. If neither of these events happen (within a year or so), we'll likely let aiccu also be removed from Debian Unstable. Accordingly I'm setting #863720 back to serious with this mail to keep it out of testing for now. I'll probably also open an RFA with the explicit mention that the only known use case are customers of Netbox.cz. *sigh* (*) AYIYA is aiccu's most used tunneling protocol and the only one suitable for NAT traversal and dynamic IPs. Unfortunately there's no publically available server implementation. (**) TIC is the Tunnel Information and Control protocol, i.e. a protocol to gather the necessary information to setup tunnels. Regards, Axel -- ,''`. | Axel Beckert <a...@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---We believe that the bug you reported is now fixed; the following package(s) have been removed from stable: aiccu | 20070115-17 | source aiccu | 20070115-17+b1 | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x ------------------- Reason ------------------- RoM; useless since shutdown of SixXS ---------------------------------------------- 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 864...@bugs.debian.org. The full log for this bug can be viewed at https://bugs.debian.org/864783 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. Archive Administrator (the ftpmaster behind the curtain)
--- End Message ---
