Re: Bindv6only once again
On Mon, 14 Jun 2010, Brian May wrote: On 14 June 2010 16:35, Marco d'Itri m...@linux.it wrote: I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. Is there software that still requires this proprietary Java implementation? I hear openjdk is getting better all the time. Yes. OpenJDK doesn't have all the crap required for crypto (or something like that. All I know is that no Brazilian linux user can file his Income Tax forms with OpenJDK, we have to use the Sun JDK). Is proprietary Java the only reason we should keep having bindv6only=0? No. Other software not in Debian will also have the same problem. Not all of it will be fixed/fixable. For me, bindv6only=0 seems like an ugly hack designed to make existing applications work without change. Although all these arguments have been hashed out before, no point to repeat them. Actually, one probably has to mess with /etc/gai.conf to get glibc to not do anything surprising for IPv6-braindamaged applications (i.e. those who work partially, maybe depending on the bindv6only setting) if one wants to be safe from IPv4/IPv6 misbehaviour. On a dual stack box and any application that does NOT work in ipv6only=1 mode, you likely have to firewall/ACL off IPv4, IPv6, IPv4-mapped-in-IPv6 ([:::a.b.c.d]) and IPv6-compatible-IPv4 ([::a.b.c.d]). Icky. Expect a lot of problems over this as IPv6 connectivity becomes more widely used. BTW, this is a problem MS Windows won't have. They require explicit IPv6 sockets, so it is basically ipv6only=1 for them. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630202310.gb30...@khazad-dum.debian.net
Re: Bindv6only once again
Why is it that suddenly everyone is an expert in double-stack programming? Brian May: For me, bindv6only=0 seems like an ugly hack designed to make existing applications work without change. Bindv6only=0 is a way to allow servers to be written to listen to just one socket, which allows making blocking accept calls. With bindv6only=1, you need to listen on two sockets simultaneously, which requires some mildly more complex code (either forking or calling select/poll.) (Yes, I know about setsockopt(IPV6_V6ONLY), and I use it whenever possible, but that's not portable.) Henrique de Moraes Holschuh: one probably has to mess with /etc/gai.conf [...] On a dual stack box and any application that does NOT work in ipv6only=1 mode, you likely have to firewall/ACL off IPv4, IPv6, IPv4-mapped-in-IPv6 ([:::a.b.c.d]) and IPv6-compatible-IPv4 ([::a.b.c.d]). Icky. I suspect you don't really don't know what you're speaking about. With bindv6only=0, a v6 socket bound to :: will not accept v4 connections, full stop. With bindv6only=0, connecting a v6 socket to a v4-mapped address will not work, full stop. No amount of tweaking /etc/gai.conf, no amount of firewalling will change the above facts. Juliusz pgpVsWjX2jDN7.pgp Description: PGP signature
Re: Bindv6only once again
(cc's dropped, sorry, I was in kernel ML netiquete mode). On Wed, 30 Jun 2010, Juliusz Chroboczek wrote: Henrique de Moraes Holschuh: one probably has to mess with /etc/gai.conf [...] On a dual stack box and any application that does NOT work in ipv6only=1 mode, you likely have to firewall/ACL off IPv4, IPv6, IPv4-mapped-in-IPv6 ([:::a.b.c.d]) and IPv6-compatible-IPv4 ([::a.b.c.d]). Icky. I suspect you don't really don't know what you're speaking about. Maybe. With bindv6only=0, a v6 socket bound to :: will not accept v4 connections, full stop. With bindv6only=0, connecting a v6 socket to a v4-mapped address will not work, full stop. Well: http://www.mail-archive.com/debian-devel@lists.debian.org/msg277726.html says: When net.ipv6.bindv6only is set to 0, an application binding an AF_INET6 listening socket to any will receive on the same socket IPv4 connections as well, with the endpoint addresses converted in the form :::1.2.3.4[1]. So, which one is correct? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630220935.ge30...@khazad-dum.debian.net
Re: Bindv6only once again
With bindv6only=0, a v6 socket bound to :: will not accept v4 connections, full stop. With bindv6only=0, connecting a v6 socket to a v4-mapped address will not work, full stop. That's obviously a typo -- I meant bindv6only=1. Juliusz pgpEstR4godnU.pgp Description: PGP signature
Re: Bindv6only once again
On Thu, 01 Jul 2010, Juliusz Chroboczek wrote: With bindv6only=0, a v6 socket bound to :: will not accept v4 connections, full stop. With bindv6only=0, connecting a v6 socket to a v4-mapped address will not work, full stop. That's obviously a typo -- I meant bindv6only=1. Then, what does it have to do with my email, which is concerned with half-converted ipv6 applications running in bindv6only=0 mode? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630224911.ga11...@khazad-dum.debian.net
Re: Bindv6only once again
On 14 June 2010 22:13, Adam Borowski kilob...@angband.pl wrote: For me, bindv6only=0 seems like an ugly hack designed to make existing applications work without change. without change? Except, you know, the whole conversion from gethostname() and friends to getaddrinfo()? V4-mapped addresses won't show for you if you do nothing -- they're a part of the package for the new API. It's not an ugly hack, it is careful design aimed to make software protocol agnostic. Without having to deal separately with every protocol, you get forward-compatibility to any other future protocol, be it IPv17, IPX (if someone bothers extending it), or any other private use development -- without having to modify or even recompile any existing software. It also lets programs to bind a socket in one go without having to separately handle IPv4 and v6. Ok, maybe I got something wrong in skimming of these arguments then. It was my understanding that bindv6only=0 is IPv4 specific, so a server only has to listen to one IPv6 socket and will always receive IPv6 addresses even if it was an IPv4 client - this is done be mangling the IPv4 address into a IPv6 address. Where as you seem to be saying a server can create a socket that will work with any protocol and is in no way specific to IPv4 or IPv6. -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin3rqvqrwb1i-7btpkfd921s7-ljad4i669o...@mail.gmail.com
Re: Bindv6only once again
Sylvestre Ledru sylves...@debian.org wrote: Hi, It is not the case. The OpenJDK has some problems with font management, slower with Swing and a few other problems. However, I am not aware of software not working with the OpenJDK (ie requiring the proprietary Java). ISTR OpenJDK and JDBC4 do not exactly work well together (read: not at all). Do you know anything about that? I've run into this myself and am forced to use Sun's JDK in this case. In case you'd like to check it out, this is with OpenBravo POS using PostgreSQL. The database code just doesn't work at all with OpenJDK 6. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87iq5ku7iz@sonic.technologeek.org
Re: Bindv6only once again
Na grupie linux.debian.devel napisałe(a)ś: I see only two ways of fixing proprietary Java (apart from fixing it upstream or ignoring the problem): * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in Debian package) This won't work in some cases. Some native programs instantiate a JVM from C/C++. I thought in this case java_vm is executed. * allow sun-java6-* packages to override bindv6only sysctl. Is it allowed by the Debian policy ? In this case probably some mechanism to do it must be developed. I'm not sure if it's worth it. I hope Oracle will eventually fix the bug in Java allowing the change in (some) stable Debian release There is no interest from Oracle on this issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342561 I know, since I've reported this bug they only action was lowering its severity. (or OpenJDK will replace Sun's Java completely). Last time I heard, Java 7 was expected for September 2010 but I am not counting on it. It will happen eventually. If not before squeeze, then maybe before squeeze+1. Jarek. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100615181207.ga31...@vilo.eu.org
Re: Bindv6only once again
Na grupie linux.debian.devel napisałe(a)ś: I see only two ways of fixing proprietary Java (apart from fixing it upstream or ignoring the problem): * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in Debian package) or * allow sun-java6-* packages to override bindv6only sysctl. * allow bindv6only to be overridden by process instead of system-wide. You mean modifying kernel? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100615181336.ga26...@vilo.eu.org
Re: Bindv6only once again
Jarek Kamiński writes: Na grupie linux.debian.devel napisałe(a)ś: I see only two ways of fixing proprietary Java (apart from fixing it upstream or ignoring the problem): * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in Debian package) or * allow sun-java6-* packages to override bindv6only sysctl. * allow bindv6only to be overridden by process instead of system-wide. You mean modifying kernel? Of course not, the kernel already provides everything needed for years, and these dummy apps can still request bindv6only to 0 on the sockets they listen on their own, which is also discussed at debian-ctte[1]: int b = 0; if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, (char *)b, sizeof(b))==-1) perror(failed blah); they would be still inferior to those opening two separate sockets (which means more fine-grained control like listening on v4 or v6 or both, or establish means to threat them specifically if necessary), but this is at least easily doable for brain-damaged apps badly in need for 0. [1] http://lists.debian.org/debian-ctte/2010/06/msg2.html -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006160018.47252.danc...@spnet.net
Re: Bindv6only once again
Am 15.06.2010 23:18, schrieb George Danchev: Jarek Kamiński writes: Na grupie linux.debian.devel napisałe(a)ś: I see only two ways of fixing proprietary Java (apart from fixing it upstream or ignoring the problem): * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in Debian package) or * allow sun-java6-* packages to override bindv6only sysctl. * allow bindv6only to be overridden by process instead of system-wide. You mean modifying kernel? Of course not, the kernel already provides everything needed for years, and these dummy apps can still request bindv6only to 0 on the sockets they listen on their own, which is also discussed at debian-ctte[1]: int b = 0; if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, (char *)b, sizeof(b))==-1) perror(failed blah); they would be still inferior to those opening two separate sockets (which means more fine-grained control like listening on v4 or v6 or both, or establish means to threat them specifically if necessary), but this is at least easily doable for brain-damaged apps badly in need for 0. You have forget, that most apps, which does not work with = 1, are non-free and mostly completly closed-source. Yeah we could follow this way and say f*** on non-free SW, but many companies, which are using Debian, are also hosting non-free software on it (we also do it); and it just breaks with this value. What would our CEO say? It is not working with Debian, but with every other distro? Then install distro XYZ! I don't think, that this is a good idea : -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c17f1a0.9070...@debian.org
Re: Bindv6only once again
OoO La nuit ayant déjà recouvert d'encre ce jour du mardi 15 juin 2010, vers 23:18, George Danchev danc...@spnet.net disait : they would be still inferior to those opening two separate sockets (which means more fine-grained control like listening on v4 or v6 or both, or establish means to threat them specifically if necessary), but this is at least easily doable for brain-damaged apps badly in need for 0. How an application which is working at level 7 and that don't want to care about level 3 is a brain-damaged app? No doubt that IPv6 support is so slow. -- I DID NOT WIN THE NOBEL FART PRIZE I DID NOT WIN THE NOBEL FART PRIZE I DID NOT WIN THE NOBEL FART PRIZE -+- Bart Simpson on chalkboard in episode AABF19 pgpPoVl9UzXO3.pgp Description: PGP signature
Re: Bindv6only once again
On Jun 13, Sune Vuorela nos...@vuorela.dk wrote: You are taking the wrong approach to things. We should see if it is still a major problem at freeze time, or if we have managed to fix all the buggy software before freeze. I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. Unless the maintainer believes that we can get a fixed version before the release then I propose to stop setting bindv6only=1 by default. While it was a useful experiment, since it allowed to expose and fix a fair number of bugs, it should not compromise the general usability of Debian systems. I do not consider the POSIX-related arguments interesting. -- ciao, Marco signature.asc Description: Digital signature
Re: Bindv6only once again
On 14 June 2010 16:35, Marco d'Itri m...@linux.it wrote: I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. Is there software that still requires this proprietary Java implementation? I hear openjdk is getting better all the time. Is proprietary Java the only reason we should keep having bindv6only=0? Why not just set bindv6only=0 if this is installed on a system? e.g. you could make it part of the installer deb. Unless the maintainer believes that we can get a fixed version before the release then I propose to stop setting bindv6only=1 by default. While it was a useful experiment, since it allowed to expose and fix a fair number of bugs, it should not compromise the general usability of Debian systems. I do not consider the POSIX-related arguments interesting. I would be disappointed to think Debian has decided not to do the right thing for all of Debian because it might break a proprietary application that some people might use. For me, bindv6only=0 seems like an ugly hack designed to make existing applications work without change. Although all these arguments have been hashed out before, no point to repeat them. -- Brian May br...@microcomaustralia.com.au -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimsxdl3ekus_5fsmma0pfrravlf6ug5b3vrw...@mail.gmail.com
Re: Bindv6only once again
Le lundi 14 juin 2010 à 20:45 +1000, Brian May a écrit : On 14 June 2010 16:35, Marco d'Itri m...@linux.it wrote: I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. Is there software that still requires this proprietary Java implementation? I hear openjdk is getting better all the time. It is not the case. The OpenJDK has some problems with font management, slower with Swing and a few other problems. However, I am not aware of software not working with the OpenJDK (ie requiring the proprietary Java). Sylvestre -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1276512754.21869.18898.ca...@korcula.inria.fr
Re: Bindv6only once again
Na grupie linux.debian.devel napisałe(a)ś: I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. Unless the maintainer believes that we can get a fixed version before the release then I propose to stop setting bindv6only=3D1 by default. While it was a useful experiment, since it allowed to expose and fix a fair number of bugs, it should not compromise the general usability of Debian systems. I see only two ways of fixing proprietary Java (apart from fixing it upstream or ignoring the problem): * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in Debian package) or * allow sun-java6-* packages to override bindv6only sysctl. I can't say I like any of these approaches (although I currently do the first on my systems). I hope Oracle will eventually fix the bug in Java allowing the change in (some) stable Debian release (or OpenJDK will replace Sun's Java completely). Jarek. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614112511.ga10...@vilo.eu.org
Re: Bindv6only once again
Le lundi 14 juin 2010 à 13:25 +0200, Jarek Kamiński a écrit : Na grupie linux.debian.devel napisałe(a)ś: I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. Unless the maintainer believes that we can get a fixed version before the release then I propose to stop setting bindv6only=3D1 by default. While it was a useful experiment, since it allowed to expose and fix a fair number of bugs, it should not compromise the general usability of Debian systems. I see only two ways of fixing proprietary Java (apart from fixing it upstream or ignoring the problem): * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in Debian package) This won't work in some cases. Some native programs instantiate a JVM from C/C++. or * allow sun-java6-* packages to override bindv6only sysctl. Is it allowed by the Debian policy ? I can't say I like any of these approaches (although I currently do the first on my systems). I hope Oracle will eventually fix the bug in Java allowing the change in (some) stable Debian release There is no interest from Oracle on this issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342561 (or OpenJDK will replace Sun's Java completely). Last time I heard, Java 7 was expected for September 2010 but I am not counting on it. Sylvestre -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1276516044.21869.19032.ca...@korcula.inria.fr
Re: Bindv6only once again
On Mon, Jun 14, 2010 at 01:25:11PM +0200, Jarek Kamiński wrote: Na grupie linux.debian.devel napisałe(a)ś: I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. Unless the maintainer believes that we can get a fixed version before the release then I propose to stop setting bindv6only=3D1 by default. While it was a useful experiment, since it allowed to expose and fix a fair number of bugs, it should not compromise the general usability of Debian systems. I see only two ways of fixing proprietary Java (apart from fixing it upstream or ignoring the problem): * wrap java and java_vm binaries in some scripts setting LD_PRELOAD (in Debian package) or * allow sun-java6-* packages to override bindv6only sysctl. * allow bindv6only to be overridden by process instead of system-wide. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614114750.ga9...@glandium.org
Re: Bindv6only once again
On Mon, Jun 14, 2010 at 08:45:58PM +1000, Brian May wrote: On 14 June 2010 16:35, Marco d'Itri m...@linux.it wrote: I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. There's no bug, so there is nothing to fix there. Non-proprietary packages are more prone to bikeshedding -- if you want to introduce a workaround to a problem elsewhere, you can do that. This is usually good -- but you can't blame Sun for refusing to pander to regressions in outside software. Both values of bindv6only have their upsides and downsides. In my opinion, =0 is vastly superior for anything but a few improperly ported programs, in Marco's opinion =1 is better -- but they are still different colours of paint you can cover your bikeshed with. And proprietary software is harder to repaint. For me, bindv6only=0 seems like an ugly hack designed to make existing applications work without change. without change? Except, you know, the whole conversion from gethostname() and friends to getaddrinfo()? V4-mapped addresses won't show for you if you do nothing -- they're a part of the package for the new API. It's not an ugly hack, it is careful design aimed to make software protocol agnostic. Without having to deal separately with every protocol, you get forward-compatibility to any other future protocol, be it IPv17, IPX (if someone bothers extending it), or any other private use development -- without having to modify or even recompile any existing software. It also lets programs to bind a socket in one go without having to separately handle IPv4 and v6. It is bindv6only=1 what is an ugly hack, since it tries to hide errors that result from partially botched conversions from IPv4-only to multiprotocolness. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100614121353.ga9...@angband.pl
Re: Bindv6only once again
m...@linux.it (Marco d'Itri) writes: I believe that now we fixed ~everything which can be fixed, so this leaves us with the proprietary Java implementation which apparently Sun is unwilling to fix. I think there are probably other proprietary applications that people just haven't tried using with testing yet. I suspect most uses of proprietary applications are in environments where it's rare to use something other than stable. Unless the maintainer believes that we can get a fixed version before the release then I propose to stop setting bindv6only=1 by default. While it was a useful experiment, since it allowed to expose and fix a fair number of bugs, it should not compromise the general usability of Debian systems. I agree with this decision. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk4py1m3@windlord.stanford.edu
Re: Bindv6only once again
On Sat, Jun 12, 2010 at 01:58:30AM +0200, Juliusz Chroboczek wrote:
I am very much surprised at the Debian community's passivity with
respect to what I see as a clear violation of Debian's commitment to
collective decision taking.
I think this is because you do not fully understand how decision making
in Debian works. With the above sentence you seem to believe that in
Debian we *first* discuss any single decision collectively and only then
we go ahead and implement it. This is not the case. If it were, in a
project the sheer size of Debian, we will be just discussing and doing
nothing else.
In fact Debian is first of all a do-ocracy and our actual commitments
read « An individual Developer may make any technical or nontechnical
decision with regard to their own work; » (Constitution §3.3.1.1). This
is not to say that we are not a democratic project, quite the contrary:
we have democratic ways to override any single entity in the project,
but they are just not the default. Therefore, your claims about Debian
community's passivity are quite inappropriate, even if I do understand
that they help your cause and that you might be advancing them for that
reason.
Now, the above is used routinely cum grano salis by individual
maintainers, that before pushing big changes that affect others discuss
them first and listen to feedback of the others. As reported by Julien
in this thread already, that has happened in this specific case and the
maintainer position is still (AFAIU) that the decision will be
re-evaluated at freeze time.
Given that context, I fail to understand what exactly your n-th
re-iteration of this issue on -devel adds.
If you really care about the issue, you should rather consider: (1)
rolling up your sleeves and helping out fixing RC bugs (you will obtain
that the freeze will happen sooner, as well as decision re-evaluation
happen sooner), or (2) engage the technical committee in this issue
(which is our *technocratic* way to override decisions), or finally (3)
start a GR (which is our *democratic* way to override decisions). Note
that you'll need to be a Developer for the latter, but not for the
former.
In the meantime, please refrain to claim that the Debian community is
falling shorts of its commitments due to this.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Bindv6only once again
OoO En cette matinée pluvieuse du dimanche 13 juin 2010, vers 10:09, Stefano Zacchiroli z...@debian.org disait : Now, the above is used routinely cum grano salis by individual maintainers, that before pushing big changes that affect others discuss them first and listen to feedback of the others. As reported by Julien in this thread already, that has happened in this specific case and the maintainer position is still (AFAIU) that the decision will be re-evaluated at freeze time. It is difficult to understand why we should wait freeze time to change anything. Some people (including me) may be afraid that the problem may not be corrected because of the freeze. Moreover, in the meantime, some applications don't work with IPv6 for people that are unaware of the possibility to modify the sysctl. -- Test input for validity and plausibility. - The Elements of Programming Style (Kernighan Plauger) pgpoPxe2mxiGi.pgp Description: PGP signature
Re: Bindv6only once again
On 2010-06-13, Vincent Bernat ber...@debian.org wrote: It is difficult to understand why we should wait freeze time to change anything. Some people (including me) may be afraid that the problem may not be corrected because of the freeze. Moreover, in the meantime, some applications don't work with IPv6 for people that are unaware of the possibility to modify the sysctl. You are taking the wrong approach to things. We should see if it is still a major problem at freeze time, or if we have managed to fix all the buggy software before freeze. The fix is not to revert the changes, but to fix the software that this change exposes bugs in. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrni197g4.rvp.nos...@sshway.ssh.pusling.com
Re: Bindv6only once again
OoO En cette matinée pluvieuse du dimanche 13 juin 2010, vers 10:59, Sune Vuorela nos...@vuorela.dk disait : It is difficult to understand why we should wait freeze time to change anything. Some people (including me) may be afraid that the problem may not be corrected because of the freeze. Moreover, in the meantime, some applications don't work with IPv6 for people that are unaware of the possibility to modify the sysctl. You are taking the wrong approach to things. We should see if it is still a major problem at freeze time, or if we have managed to fix all the buggy software before freeze. The problem is not the software that are in Debian and have bugs already reported, the problem is the software that are not in Debian and that won't work with Debian but with any other distribution. — XXX does not work with my Debian, it just fails with some network error — I just tested, it works fine on my Arch — Oh, Debian just sucks, let's try something else *That* is a real situation case. Nobody will set bindv6only to 1 on her own. -- SPITWADS ARE NOT FREE SPEECH SPITWADS ARE NOT FREE SPEECH SPITWADS ARE NOT FREE SPEECH -+- Bart Simpson on chalkboard in episode 8F01 pgpVbHfMUlS9t.pgp Description: PGP signature
Re: Bindv6only once again
On Sunday 13 June 2010, Sune Vuorela wrote: On 2010-06-13, Vincent Bernat ber...@debian.org wrote: It is difficult to understand why we should wait freeze time to change anything. Some people (including me) may be afraid that the problem may not be corrected because of the freeze. Moreover, in the meantime, some applications don't work with IPv6 for people that are unaware of the possibility to modify the sysctl. You are taking the wrong approach to things. We should see if it is still a major problem at freeze time, or if we have managed to fix all the buggy software before freeze. The fix is not to revert the changes, but to fix the software that this change exposes bugs in. /Sune Except that some of the software that will have problems with is non-free software (or worse) and none of that (by definiton) is part of the RC bug process that controls releases. While that software is not the part of Debian, many users of Debian use such software on Debian platforms. David -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201006131010.37717.david.goodeno...@btconnect.com
Re: Bindv6only once again
Sune Vuorela writes: On 2010-06-13, Vincent Bernat ber...@debian.org wrote: It is difficult to understand why we should wait freeze time to change anything. Some people (including me) may be afraid that the problem may not be corrected because of the freeze. Moreover, in the meantime, some applications don't work with IPv6 for people that are unaware of the possibility to modify the sysctl. You are taking the wrong approach to things. We should see if it is still a major problem at freeze time, or if we have managed to fix all the buggy software before freeze. The fix is not to revert the changes, but to fix the software that this change exposes bugs in. The behavior with net.ipv6.bindv6only=0 is mandated by both POSIX and the governing RFC. How can you call it a bug for software to expect that behavior? The true bug is that Debian intentionally violates these standards. If people decide (as Vincent Bernat suggested) that Debian is a buggy piece of junk because of that, they will be right. Michael Poole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk4rci3y@troilus.org
Re: Bindv6only once again
On Sun, Jun 13, 2010 at 7:00 PM, Michael Poole mdpo...@troilus.org wrote: The behavior with net.ipv6.bindv6only=0 is mandated by both POSIX and the governing RFC. How can you call it a bug for software to expect that behavior? The true bug is that Debian intentionally violates these standards. If people decide (as Vincent Bernat suggested) that Debian is a buggy piece of junk because of that, they will be right. How many times will this discussion will go round and round in circles? I'm getting dizzy. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimxubmrh_y8ouoel5hkpe8cwe8ips16nxahv...@mail.gmail.com
Re: Bindv6only once again
Paul Wise writes: On Sun, Jun 13, 2010 at 7:00 PM, Michael Poole mdpo...@troilus.org wrote: The behavior with net.ipv6.bindv6only=0 is mandated by both POSIX and the governing RFC. How can you call it a bug for software to expect that behavior? The true bug is that Debian intentionally violates these standards. If people decide (as Vincent Bernat suggested) that Debian is a buggy piece of junk because of that, they will be right. How many times will this discussion will go round and round in circles? I'm getting dizzy. Probably as many times as it takes for people to give a reasonable answer for the question I asked. So far I have seen these reasons provided to keep bindv6only=1: 1) BSDs only act as if bindv6only=1. (False.) 2) BSDs do (or did) this because of vague language in the standards. (Maybe true once, but not now.) 3) There are potential security bugs if an application black- or white-lists IPv4 addresses and someone uses an v6-mapped IPv4 address to connect. (Handwavy and, as far as I've seen, purely hypothetical. Also ties the hands of the system administrator, who may want to treat v6-mapped addresses differently than the corresponding native IPv4 address.) 4) It only affects software outside of the Debian archive. (Irrelevant at best. Callous because it requires developers to cater to the whims of Debian.) and most often: 5) Software that doesn't expect it is buggy. (Circular.) Have I missed anything? Michael Poole -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocffcgsq@troilus.org
Re: Bindv6only once again
Paul Wise p...@debian.org writes: How many times will this discussion will go round and round in circles? I'm getting dizzy. I believe it will continue until someone finds the end of the circle. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/874oh7b1gi@nemi.mork.no
Re: Bindv6only once again
Na grupie linux.debian.devel napisałe(a)ś: 3) There are potential security bugs if an application black- or white-lists IPv4 addresses and someone uses an v6-mapped IPv4 address to connect. (Handwavy and, as far as I've seen, purely hypothetical. I don't want to blow the discussion once again, but the security issue is not only hypothetical. When I started using IPv6 I was deeply disappointed when one daemon started ignoring my acls because of that. Of course the daemon is fixed now, but the accident proves the risk is real. Also ties the hands of the system administrator, who may want to treat v6-mapped addresses differently than the corresponding native IPv4 address.) I have no idea why one might want to do that. Jarek. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100613172629.ga31...@vilo.eu.org
Re: Bindv6only once again
On Sat, Jun 12, 2010 at 01:58:30AM +0200, Juliusz Chroboczek wrote: In netbase 4.38, Marco d'Itri has unilaterally decided to change the value of the net.ipv6.bindv6only sysctl to 1. This change has the following effects: (1) it violates POSIX 2008, Volume 2, Section 2.10.20; (2) it violates RFC 3493, Section 5.3; (3) it breaks software that is written to comply to POSIX, most notably Sun's Java. Please start with fixing the FreeBSD kernel. It only supports this mode of operation. Bastian -- Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100612090150.ga8...@wavehammer.waldi.eu.org
Re: Bindv6only once again
Le samedi 12 juin 2010 à 11:01 +0200, Bastian Blank a écrit : Please start with fixing the FreeBSD kernel. It only supports this mode of operation. I agree this should be done, but why should it be done before changing the default for the Linux ports? -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Re: Bindv6only once again
* Bastian Blank wa...@debian.org, 2010-06-12, 11:01: In netbase 4.38, Marco d'Itri has unilaterally decided to change the value of the net.ipv6.bindv6only sysctl to 1. This change has the following effects: (1) it violates POSIX 2008, Volume 2, Section 2.10.20; (2) it violates RFC 3493, Section 5.3; (3) it breaks software that is written to comply to POSIX, most notably Sun's Java. Please start with fixing the FreeBSD kernel. It only supports this mode of operation. http://lists.debian.org/debian-devel/2010/04/msg00256.html -- Jakub Wilk signature.asc Description: Digital signature
Re: Bindv6only once again
On Sat, Jun 12, 2010 at 11:01:50AM +0200, Bastian Blank wrote: On Sat, Jun 12, 2010 at 01:58:30AM +0200, Juliusz Chroboczek wrote: In netbase 4.38, Marco d'Itri has unilaterally decided to change the value of the net.ipv6.bindv6only sysctl to 1. This change has the following effects: (1) it violates POSIX 2008, Volume 2, Section 2.10.20; (2) it violates RFC 3493, Section 5.3; (3) it breaks software that is written to comply to POSIX, most notably Sun's Java. Please start with fixing the FreeBSD kernel. It only supports this mode of operation. Please start with not saying bullshits. The FreeBSD kernel support both modes even if the default is bindv6only=1. Please note that the GNU/kFreeBSD people have never been contacted about changing this default value. As the FreeBSD kernel seems to be the new model in Debian, I will be happy to change the default value of net.inet6.ip6.v6only to 0 and report a serious bug against netbase as the default value of the Linux kernel doesn't match the one of the FreeBSD kernel. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100612155904.ga6...@ohm.aurel32.net
Re: Bindv6only once again
Dear Juliusz, On Sat, Jun 12, 2010 at 01:58:30 +0200, Juliusz Chroboczek wrote: Dear all, I would like to raise the issue of #560238 once again. In netbase 4.38, Marco d'Itri has unilaterally decided to change the value of the net.ipv6.bindv6only sysctl to 1. This change has the following effects: (1) it violates POSIX 2008, Volume 2, Section 2.10.20; (2) it violates RFC 3493, Section 5.3; (3) it breaks software that is written to comply to POSIX, most notably Sun's Java. Now, violating POSIX when there is good reason to do sois not something Debian should shy from -- that's what we have POSIXLY_CORRECT for. However, I don't think that such a decision should be taken lightly, and certainly not without at least some discussion and advance warning. There was discussion on this list before the change, and then more after the change. And Marco said he was going to reconsider the issue at the time of the squeeze freeze. So if you want that to happen faster, I suggest you get started on fixing a few of the release critical bugs that may delay said freeze from happening. I'm hoping the change will be reverted in the end, but in the mean time I'm tired of the rehashing of the same arguments here. Cheers, Julien signature.asc Description: Digital signature
