Re: Clarification for broken packages in IPv6-only environments
Hi Vincent, Simon, On Fri, Dec 01, 2023 at 09:24:00AM +0100, Vincent Bernat wrote: > I don't think this is a good use of time to fix builds broken because > there is no IPv4 loopback. On Fri, Dec 01, 2023 at 11:30:50AM +, Simon McVittie wrote: > I agree that we should consider a working 127.0.0.1 to be "part of the > API" that packages (and in particular their test-suites) can assume, > even if there is no other IPv4 connectivity. I'd liket to offer a different perspective: complete IPv4 stack removal including loopback addressing is inevitable even if still a fair way off, it's a good idea to get an early start here. It's valuable for us to give upstreams backpressure on having legacy IP requirements in the package build process of all places and I don't think this is onerous requirement, it's just exposing holes in IPv6 support that should really be there already. Requiring support for IPv6 singlestack at runtime is a whole different beast ofc, but are we really seeing an insurmountable number of issues due to build time problems only? Either way I'd be happy to help get issues like this fixed upstream. --Daniel signature.asc Description: PGP signature
Re: Clarification for broken packages in IPv6-only environments
On 2023-11-30 22:42, Dale Richards wrote: I recently submitted a patch for uvloop that was FTBFS on IPv6-only builds (#1024079) and it really didn't take very long. While building/running in IPv6-only environments is not currently mandated in the Policy it's a fairly safe bet that it could/should be in future updates, so it makes sense to start making all packages agnostic of IP version now. This one seems to be because localhost was resolved to ::1, which is not Debian-default configuration where localhost is 127.0.0.1. Also, the patch is overly complex and is not upstreamed. While correct (even if the original test was testing with and without name resolution), this may become a maintenance hurdle in the future.
Re: Clarification for broken packages in IPv6-only environments
On 2023-11-30 21:38, Paul Tagliamonte wrote: Now I would like to know if being able to run in an IPv6-only environment is a must have feature for any debian package? I run an IPv6 only LAN on my home network, where I use `jool`, and `dns64-prefix`+`unbound` to interoperate with legacy IP space. There's no assigned IPv4 addresses for hosts on that LAN. This does not prevent to have 127.0.0.1. I don't think this is a good use of time to fix builds broken because there is no IPv4 loopback. This is the same kind of artificial conditions as the 1-core builders.
Re: Clarification for broken packages in IPv6-only environments
On Thu, Nov 30, 2023 at 08:24:18PM +0100, Thomas Braun wrote: > Now I would like to know if being able to run in an IPv6-only environment is > a must have feature for any debian package? As Debian uses package builders in this configuration, packages needs to build in such an environment. Bastian -- Captain's Log, star date 21:34.5...
Re: Clarification for broken packages in IPv6-only environments
On Thu, 2023-11-30 at 15:38 -0500, Paul Tagliamonte wrote: > On Thu, Nov 30, 2023 at 08:24:18PM +0100, Thomas Braun wrote: > > Now I would like to know if being able to run in an IPv6-only > > environment is > > a must have feature for any debian package? > > I have no idea what the project's stance is, but I don't regard this > as > a particularly high bar, it tends to take some pretty heavy and > gnarly usage > of legacy api surface to render programs show stoppingly broken. I'd be inclined to agree. Running IPv6-only is relatively rare but not unheard of, especially in larger environments where IPv4 address space is in short supply. I recently submitted a patch for uvloop that was FTBFS on IPv6-only builds (#1024079) and it really didn't take very long. While building/running in IPv6-only environments is not currently mandated in the Policy it's a fairly safe bet that it could/should be in future updates, so it makes sense to start making all packages agnostic of IP version now. Best regards, Dale Richards
Re: Clarification for broken packages in IPv6-only environments
On Thu, Nov 30, 2023 at 08:24:18PM +0100, Thomas Braun wrote: > Now I would like to know if being able to run in an IPv6-only environment is > a must have feature for any debian package? I run an IPv6 only LAN on my home network, where I use `jool`, and `dns64-prefix`+`unbound` to interoperate with legacy IP space. There's no assigned IPv4 addresses for hosts on that LAN. Most packages work fine IPv6 only -- but some things break once in a while. Show-stopping breakage is rare and usually results in me filing a bug report. I have no idea what the project's stance is, but I don't regard this as a particularly high bar, it tends to take some pretty heavy and gnarly usage of legacy api surface to render programs show stoppingly broken. paultag -- ⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte ⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/ ⢿⡄⠘⠷⠚⠋Debian, the universal operating system. ⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3 signature.asc Description: PGP signature
Clarification for broken packages in IPv6-only environments
(please CC me, as I'm not subscribed) Hi, I'm one of the upstream authors of cppTango [1] and that is a direct dependency of pytango [2]. Some time ago a bug report titled "pytango FTBFS on IPv6-only buildds" [3] was filed (tagged: serious) and the package maintainer "hacked" around the problem and could close the issue. Now I would like to know if being able to run in an IPv6-only environment is a must have feature for any debian package? I've found a long-standing release goal [4] and some prior discussion [5] but no definite answer. The thing is from our users we have zero requests for this kind of setup so I'm having a hard time justifying the effort. Thanks, Thomas [1]: https://packages.debian.org/trixie/libtango9-4 [2]: https://packages.debian.org/trixie/python3-tango [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014179 [4]: https://wiki.debian.org/ReleaseGoals/FullIPv6Support [5]: https://lists.debian.org/debian-devel/2022/02/msg00061.html
