Re: Default value of net.ipv6.bindv6only should revert to 0

[Hendrik Sattler]

Am Dienstag 13 April 2010 20:11:34 schrieb Russ Allbery:
> Or are you saying that inetd implementations use IPV6_ADDRFORM before
> running the underlying program?  (All of the ones in Debian?)  If so,
> there's some missing connecting of the dots in your reply.

I guess not all of them. OTOH, not all of them might use AF_INET6 sockets for 
IPv4 connections (the two-sockets approach is always possible when using 
IPV6_V6ONLY socket option).

At least xinetd uses IPV6_ADDRFORM although that socket option is already 
deprecated again but still useful for such cases.

openbsd-inetd explicitely doesn't support IPv4-mapped addresses, configuration 
needs seperate IPv4 and IPv6 setup.

I didn't look at the other two.

HS


-- 
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/201004140714.37690.p...@hendrik-sattler.de

Re: Default value of net.ipv6.bindv6only should revert to 0

[Russ Allbery]

Hendrik Sattler  writes:

> I guess not all of them. OTOH, not all of them might use AF_INET6
> sockets for IPv4 connections (the two-sockets approach is always
> possible when using IPV6_V6ONLY socket option).

> At least xinetd uses IPV6_ADDRFORM although that socket option is
> already deprecated again but still useful for such cases.

> openbsd-inetd explicitely doesn't support IPv4-mapped addresses,
> configuration needs seperate IPv4 and IPv6 setup.

> I didn't look at the other two.

Thank you very much for the investigation!  That's really useful
information (at least to me) and I appreciate you taking the effort.

I took a quick look at the source of rlinetd, and so far as I can tell it
will do whatever the default IPv6 stack behavior is.  It iterates through
every return from getaddrinfo for AI_PASSIVE for a particular family, and
doesn't appear to do anything special with the resulting socket before
passing it along to the underlying server.  But I'm not sure that I'm
following the code.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/877hoafvp8@windlord.stanford.edu

Re: How does lintian detect embedded-zlib?

[Matthias Klumpp]

On Tue, 13 Apr 2010 16:41:20 -0400, James Vega  wrote:
>> So I started some research why this error is shown. FPC - generally -
>> does
>> not link any lib statically, so this ZLib error is bit strange.
>> How does Lintian detect the embedded zlib in binaries?
> 
> From /usr/share/lintian/checks/binaries:
> 
> if ($info->field('source') ne 'zlib' and $info->field('source') ne
> 'klibc'
> and $strings =~ /(?:in|de)flate (?:\d[ \w.\-]{1,20}[\w.\-])/m) {
> tag "embedded-zlib", $file;
> }
Thanks to everyone for this information! The embedded-zlib error which is
overriden in nearly every package which uses FPC seems to be a
false-positive in Lintian.
Russ Albery writes about this:
--
This is generally a false positive in that this is not the problem that
Lintian is trying to diagnose (although I don't understand why it only
sometimes shows up in builds of easymp3gain).  I'm trying to figure out a
good way of having Lintian avoid this problem.

I wonder if we can trigger off of that leading 4 to suppress this tag,
since that seems to be peculiar to the Pascal implementation.  I think
I'll give that a try for the next Lintian release.
--
Which means it will get fixed. (Yipee!)

Regards
  Matthias Klumpp


-- 
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/f15803754f6a8b8b2706f7de7f506...@mb8-2.1blu.de

Re: How does lintian detect embedded-zlib?

[Russ Allbery]

Russ Allbery  writes:
> James Vega  writes:
>> On Tue, Apr 13, 2010 at 10:22:55PM +0200, Matthias Klumpp wrote:

>>> Cause binaries generated by the FPC (FreePascalCompiler) produce the
>>> Lintian error "embedded-zlib", I cannot upload a new version of a
>>> package I maintain which overrides this error. (It's not allowed to
>>> override it at time)

>> You can override this.  I do so for plt-scheme.

> If people have an idea for a better way of doing this test, do let us
> know, since we'd prefer to not have people have to override if it can be
> avoided.  We're trying to match on version strings that are somewhat
> peculiar to the zlib implementation, hopefully.

Oh, never mind, I see.  plt-scheme isn't a false positive, just a case
where upstream is embedding the library and the bug and fixes haven't been
worked through yet.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/877hobrrtv@windlord.stanford.edu

Re: How does lintian detect embedded-zlib?

[Russ Allbery]

James Vega  writes:
> On Tue, Apr 13, 2010 at 10:22:55PM +0200, Matthias Klumpp wrote:

>> Cause binaries generated by the FPC (FreePascalCompiler) produce the
>> Lintian error "embedded-zlib", I cannot upload a new version of a
>> package I maintain which overrides this error. (It's not allowed to
>> override it at time)

> You can override this.  I do so for plt-scheme.

If people have an idea for a better way of doing this test, do let us
know, since we'd prefer to not have people have to override if it can be
avoided.  We're trying to match on version strings that are somewhat
peculiar to the zlib implementation, hopefully.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87bpdnrrxe@windlord.stanford.edu

Re: Default value of net.ipv6.bindv6only should revert to 0

[Thorsten Glaser]

Russ Allbery dixit:

>>> architectures which are expected to be part of Debian.  Debian has
>>> needed to adapt to BSD behavior, non-standard or not, since the project
>>> decided to include the kfreebsd architectures.  That's part of porting.
>
>> What is wrong with porting kfreebsd behaivour instead?
>
>I don't know.  What do the BSD porters think about it?

I'd rather say it's not exactly non-standard behaviour but "the other
one" (dual-stack vs doble-stack). From an implementor's PoV: what does
IPv6 have to do with IPv4 and why should it listen there too? From a
security PoV, the doble-stack setup is preferable (although I perso-
nally would like to see it configurable).

Maybe like this: kfreebsd-* will be relatively buggy in squeeze anyway,
so put it back to 0 for squeeze but not unstable or squeeze+1 and fix
the apps in the meantime. I fixed one (that got removed later tho…), so
it's possible.

bye,
//mirabilos
-- 
FWIW, I'm quite impressed with mksh interactively. I thought it was much
*much* more bare bones. But it turns out it beats the living hell out of
ksh93 in that respect. I'd even consider it for my daily use if I hadn't
wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh


--
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/pine.bsm.4.64l.1004132024070.2...@herc.mirbsd.org

Re: How does lintian detect embedded-zlib?

[James Vega]

On Tue, Apr 13, 2010 at 10:22:55PM +0200, Matthias Klumpp wrote:
> Hello!
> Cause binaries generated by the FPC (FreePascalCompiler) produce the
> Lintian error "embedded-zlib", I cannot upload a new version of a package I
> maintain which overrides this error. (It's not allowed to override it at
> time)

You can override this.  I do so for plt-scheme.

> So I started some research why this error is shown. FPC - generally - does
> not link any lib statically, so this ZLib error is bit strange.
> How does Lintian detect the embedded zlib in binaries?

From /usr/share/lintian/checks/binaries:

if ($info->field('source') ne 'zlib' and $info->field('source') ne 'klibc'
and $strings =~ /(?:in|de)flate (?:\d[ \w.\-]{1,20}[\w.\-])/m) {
tag "embedded-zlib", $file;
}

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega 


signature.asc
Description: Digital signature

Bug#577712: ITP: unicorn -- Rack HTTP server for fast clients and Unix

[Laurent Arnoud]

Package: wnpp
Severity: wishlist
Owner: Laurent Arnoud 
Owner: Laurent Arnoud 

* Package name: unicorn
  Version : 0.97.0
  Upstream Author : Eric Wong 
* URL : http://unicorn.bogomips.org/
* License : GPL-2
  Programming Lang: C, Ruby
  Description : Rack HTTP server for fast clients and Unix

 Unicorn is an HTTP server for Rack applications designed to only serve fast
 clients on low-latency, high-bandwidth connections and take advantage of
 features in Unix/Unix-like kernels. Slow clients should only be served by
 placing a reverse proxy capable of fully buffering both the the request and
 response in between Unicorn and slow clients.



-- 
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/20100413201539.10581.76634.report...@r32988.ovh.net

Re: How does lintian detect embedded-zlib?

[David Paleino]

Hello,

Matthias Klumpp wrote:
> Does someone know more about Lintians way of finding embedded ZLibs?

>From /usr/share/lintian/checks/binaries:

if ($info->field('source') ne 'zlib' and $info->field('source') ne 'klibc'
and $strings =~ /(?:in|de)flate (?:\d[ \w.\-]{1,20}[\w.\-])/m) {
tag "embedded-zlib", $file;
}

$strings is:

my $strings = slurp_entire_file("strings/$file");

You might want to have a lintian run with --keep-lab, and check whatever
is in strings/, if anything there matches with the regex above.

Kindly,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 |
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174



-- 
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/hq2kkf$55...@dough.gmane.org

How does lintian detect embedded-zlib?

[Matthias Klumpp]

Hello!
Cause binaries generated by the FPC (FreePascalCompiler) produce the
Lintian error "embedded-zlib", I cannot upload a new version of a package I
maintain which overrides this error. (It's not allowed to override it at
time)
So I started some research why this error is shown. FPC - generally - does
not link any lib statically, so this ZLib error is bit strange.
How does Lintian detect the embedded zlib in binaries? If it scans for some
patterns, it might be a false positive because FPC itself has a similar
algorithm in its RTL.
Does someone know more about Lintians way of finding embedded ZLibs?
Thanks & kind regards
  Matthias Klumpp


-- 
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/b0390b261971d57972ee12a124fc4...@mb8-2.1blu.de

Re: Default value of net.ipv6.bindv6only should revert to 0

[Russ Allbery]

"John H. Robinson, IV"  writes:
> Russ Allbery wrote:

>> My understanding is that part (although certainly not all) of the
>> reason behind the default change is consistency with the kfreebsd
>> architectures which are expected to be part of Debian.  Debian has
>> needed to adapt to BSD behavior, non-standard or not, since the project
>> decided to include the kfreebsd architectures.  That's part of porting.

> What is wrong with porting kfreebsd behaivour instead?

I don't know.  What do the BSD porters think about it?

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87k4sbt9bd@windlord.stanford.edu

Re: Default value of net.ipv6.bindv6only should revert to 0

[Eduard Bloch]

#include 
* Salvo Tomaselli [Tue, Apr 13 2010, 12:05:08PM]:
> On Tuesday 13 April 2010 11:33:15 George Danchev wrote:
> > It is legit to change a default value (regardless what standards says, if
> > you can't change a default value it it then a hard-coded one), and it is
> > pretty lame to assume a default value will never be changed. This assumption
> > also fails on systems where IPv6 sockets are always IPv6-only.
> Do you have any example of a posix system call that in a certain version had 
> a 
> different semantic than the previous posix version?

How is that question related to his statement? Even if it was, it's up
to you to show the POSIX part which makes v6/v4 mapping mandatory.

> I can hardly believe this could ever happen.

Not sure about POSIX but an example for such insanity in popular APIs
comes quickly to my mind... see strerror(3).

Regards,
Eduard.

-- 
* h01ger vermutet, white studiert wie er autofaehrt


-- 
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/20100413192644.ga17...@rotes76.wohnheim.uni-kl.de

Re: Default value of net.ipv6.bindv6only should revert to 0

[John H. Robinson, IV]

Russ Allbery wrote:
> 
> My understanding is that part (although certainly not all) of the reason
> behind the default change is consistency with the kfreebsd architectures
> which are expected to be part of Debian.  Debian has needed to adapt to
> BSD behavior, non-standard or not, since the project decided to include
> the kfreebsd architectures.  That's part of porting.

What is wrong with porting kfreebsd behaivour instead?

-- 
John H. Robinson, IV  jaq...@debian.org
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


-- 
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/20100413181449.ga19...@a.mx.sbih.org

Re: Default value of net.ipv6.bindv6only should revert to 0

[Russ Allbery]

Hendrik Sattler  writes:
> Zitat von Russ Allbery :

>> It's not an assumption.  It's reality that one has to write code
>> against, because different platforms do different things.  Even if you
>> could remove the option from the Linux kernel (retroactively, changing
>> time to remove all the systems that already exist), that doesn't change
>> the fact that Solaris and BSD behave differently.

> But that was not the reason why the default was changed for _linux_ in
> Debian.  Since when do we need to adapt non-standard Solaris and BSD
> behaviour?

My understanding is that part (although certainly not all) of the reason
behind the default change is consistency with the kfreebsd architectures
which are expected to be part of Debian.  Debian has needed to adapt to
BSD behavior, non-standard or not, since the project decided to include
the kfreebsd architectures.  That's part of porting.

Also please note that I've stated several times that I think both
decisions have problems.  I'm not just defending the default change.  The
problem with Java is fairly serious, and it may be better for our users to
go back to setting bindv6only to 0.  But we should do so for the right
reasons and understanding the situation; that setting isn't *also* without
problems that we will have to deal with.

>>> Read about IPV6_ADDRFORM in ipv6(7). Use it. Change back to the
>>> default and forget about this discussion how hard it is to convert
>>> addresses to AF_INET style, so ACLs do match. Enjoy life :)

>> This doesn't have much to do anything to do with the conversation that
>> we're having, though.  Once you're modifying the application, there's a
>> bunch of things that you can do to address this problem in different
>> ways.  The question that we're debating is what the default should be
>> for applications that are not expressing an explicit preference.

> You forgot to cite yourself! This was an answer to your "BTW" question.

I don't see how this is related to the question that I'm asking:

BTW, I've not tried this myself: does someone know what happens if a
daemon called from an inetd equivalent calls getpeername() on a socket
bound by an IPv6-aware inetd using mapped addresses?  For IPv4
connections, does it get back an IPv4 address or an IPv6 mapped
address?  Do the inetd implementations currently in Debian separately
bind IPv4 and IPv6 sockets, or do they use mapped addresses?

Or are you saying that inetd implementations use IPV6_ADDRFORM before
running the underlying program?  (All of the ones in Debian?)  If so,
there's some missing connecting of the dots in your reply.

The point of the question is that programs run from inetd may get IPv6
sockets without knowing anything at all about IPv6 and without having any
special modifications made to use IPv6, particularly in the case of an
IPv6-aware inetd that uses mapped addresses.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/87zl1743zd@windlord.stanford.edu

Re: Default value of net.ipv6.bindv6only should revert to 0

[Russ Allbery]

Salvo Tomaselli  writes:

> Solaris is a little bit tricky, i would be very careful talking about
> it.

Thanks for your caution and concern about what I might or might not
understand, but I have been administering Solaris systems and writing code
for Solaris for 15 years.

> After having enabled the posix compatibility, it works as expected on
> posix with ipv6only=0.

> The bug is bsd-only.

That was my point.  Solaris and BSD work differently, so code that cares
about portability already has to explicitly state its desired behavior,
even if you eliminate Linux from the mix entirely.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/874ojf5iwr@windlord.stanford.edu

Free Website for 30 Days with Upgrade BONUS!

[offers]

Dear Health & Fitness Owner,

We'd like to give you the next 30 days to try out our easy-to-use website 
management service for your club.   We've added a number of new features and 
benefits and we'd like to give you a month to check them out. And if you decide 
to stay with us and activate your account at the Premium package, we'll sweeten 
your deal.

NEW FEATURES:
* Social Media Bar
* Embed Videos and Photos
* Email Blaster
* Lead Collection

Click here to give us a try (use promo code: UPFREE): 

http://www.healthclubsites.com/step1.cfm

Sign up now! If you activate your account at the Premium level before the end 
of your trial we'll upgrade you to Premium Plus package for FREE! Or if you 
activate at the Premium Plus package, you will receive a free logo insertion to 
any of our existing designs. Offer expires: Friday, April 23, 2010 at 8PM EST. 

Best regards,
 
Christine Barnes
HealthClubSites
http://www.healthclubsites.com







  
If you no longer wish to receive information about special offers, please click 
the following link to UNSUBSCRIBE:
https://secure.healthclubsites.com/unsubscribe.cfm?e=debian-de...@lists.debian.org.

  


-- 
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/15749800.1271173871348.javamail.cfser...@wsm2

Bug#577667: ITP: weboob -- Allows for out-of-browser interaction with websites implementing specific capabilities

[Sebastien Delafond]

Package: wnpp
Severity: wishlist
Owner: Sebastien Delafond 

* Package name: weboob
  Version : 0.1.0
  Upstream Author : Romain Bignon 
* URL : http://weboob.org/
* License : GPL
  Programming Lang: Python
  Description : Provides clients capable of interacting with various 
websites
  
  Weboob allows frontend applications to query, through a set of
  backends, some websites implementing a subset of pre-defined
  capabilities (forum, bank, travel, weather, etc).
  .
  This allows the user to extract information out of those websites
  without using a browser.

-- System Information:
Debian Release: 5.0.4
  APT prefers stable
  APT policy: (999, 'stable'), (500, 'proposed-updates'), (100, 'testing'), (1, 
'unstable')
Architecture: i386 (i686)



-- 
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/20100413134053.523.39063.report...@proliant.untangle.com

Re: document meaning of transition?

[Joachim Wiedorn]

Thomas Koch  wrote:

> I'm reading debian-devel to get to know all that's needed to become a Debian 
> Developer. I noticed, that I did not find any documentation about transitions 
> or their workflow and that I can only guess, what this thread is about.
> Maybe this is something that would be worth to be written down?

You need the New-Maintainer (NM) process to become DD.
Details can be found here: http://www.debian.org/devel/join/newmaint


Fondest regards,
 Joachim Wiedorn



signature.asc
Description: PGP signature

Bug#577656: ITP: github-cli -- command-line interface to the GitHub Issues API

[David Paleino]

Package: wnpp
Severity: wishlist
Owner: David Paleino 

* Package name: github-cli
  Version : 0.2.8
  Upstream Author : Name 
* URL : http://www.example.org/
* License : BSD
  Programming Lang: Python
  Description : command-line interface to the GitHub Issues API

 github-cli provides an executable called ghi, that can be used to access
 all of GitHub's documented Issues API (v2) functionality from the command
 line.

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 |
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: This is a digitally signed message part.

Re: Default value of net.ipv6.bindv6only should revert to 0

[Salvo Tomaselli]

On Tuesday 13 April 2010 11:33:15 George Danchev wrote:
> It is legit to change a default value (regardless what standards says, if
> you can't change a default value it it then a hard-coded one), and it is
> pretty lame to assume a default value will never be changed. This assumption
> also fails on systems where IPv6 sockets are always IPv6-only.
Do you have any example of a posix system call that in a certain version had a 
different semantic than the previous posix version?

I can hardly believe this could ever happen.

Bye
-- 
Salvo Tomaselli


-- 
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/201004131205.08689.tipos...@tiscali.it

Re: Default value of net.ipv6.bindv6only should revert to 0

[George Danchev]

Quoting "Salvo Tomaselli" :


On Tuesday 13 April 2010 07:46:10 Russ Allbery wrote:

It's not an assumption.  It's reality that one has to write code against,
because different platforms do different things.  Even if you could remove
the option from the Linux kernel (retroactively, changing time to remove
all the systems that already exist), that doesn't change the fact that
Solaris and BSD behave differently.

Solaris is a little bit tricky, i would be very careful talking about it.
I've tried opensolaris and it is not posix by default, many calls behave in a
non-posix way because they were introduced in solaris before they were
introduced in posix, so they have different parameters or semantic.

To have posix in solaris, one must use a bunch of flags at compile-time, for
example: -D_POSIX_PTHREAD_SEMANTICS -lsocket -lnsl
After having enabled the posix compatibility, it works as expected on posix
with ipv6only=0.

The bug is bsd-only.


This is the wrong conclusion. The bug is in the apps which rely on a  
certain default global value to be ever set the way they expect, and  
behave incorrectly when the default is changed. It is legit to change  
a default value (regardless what standards says, if you can't change a  
default value it it then a hard-coded one), and it is pretty lame to  
assume a default value will never be changed. This assumption also  
fails on systems where IPv6 sockets are always IPv6-only.



--
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/20100413123315.17386hdegpp1x...@webmail.spnet.net

Re: document meaning of transition?

[Thomas Koch]

Hi Raphael,

I'm reading debian-devel to get to know all that's needed to become a Debian 
Developer. I noticed, that I did not find any documentation about transitions 
or their workflow and that I can only guess, what this thread is about.
Maybe this is something that would be worth to be written down?

Best regards,

Thomas Koch, http://www.koch.ro


-- 
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/201004130929.16329.tho...@koch.ro

Re: Default value of net.ipv6.bindv6only should revert to 0

[Hendrik Sattler]

Zitat von Russ Allbery :


Hendrik Sattler  writes:


It's a trade-off with a different goal in mind. So what. Both settings
of bindv6only are if you cannot assume standard behaviour. Maybe we
should patch this option _out_ of the linux kernel to get rid of the
assumption that the default may be changed.


It's not an assumption.  It's reality that one has to write code against,
because different platforms do different things.  Even if you could remove
the option from the Linux kernel (retroactively, changing time to remove
all the systems that already exist), that doesn't change the fact that
Solaris and BSD behave differently.


But that was not the reason why the default was changed for _linux_ in Debian.
Since when do we need to adapt non-standard Solaris and BSD behaviour?


Read about IPV6_ADDRFORM in ipv6(7). Use it. Change back to the default
and forget about this discussion how hard it is to convert addresses to
AF_INET style, so ACLs do match. Enjoy life :)


This doesn't have much to do anything to do with the conversation that
we're having, though.  Once you're modifying the application, there's a
bunch of things that you can do to address this problem in different ways.
The question that we're debating is what the default should be for
applications that are not expressing an explicit preference.


You forgot to cite yourself! This was an answer to your "BTW" question.

It was proposed to fix programs that may not work with bindv6only=1.  
This is correct. But it was also noted that the change was done to  
have less problems with some other applications (ACLs, etc.). If you  
need AF_INET addresses to make e.g. your ACLs to work correctly, the  
above socket option _is_ a solution. An easy solution. You need to  
patch those programs then? So what! That's exactly what you request  
from others.


What again was the list of "reasons" to change the default value of  
bindv6lonly from 0 to 1? I have not seen any good reasons so far.


HS



--
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/20100413090739.p0jr7lt2as40g...@v1539.ncsrv.de

Re: Default value of net.ipv6.bindv6only should revert to 0

[Salvo Tomaselli]

On Tuesday 13 April 2010 07:46:10 Russ Allbery wrote:
> It's not an assumption.  It's reality that one has to write code against,
> because different platforms do different things.  Even if you could remove
> the option from the Linux kernel (retroactively, changing time to remove
> all the systems that already exist), that doesn't change the fact that
> Solaris and BSD behave differently.
Solaris is a little bit tricky, i would be very careful talking about it.
I've tried opensolaris and it is not posix by default, many calls behave in a 
non-posix way because they were introduced in solaris before they were 
introduced in posix, so they have different parameters or semantic.

To have posix in solaris, one must use a bunch of flags at compile-time, for 
example: -D_POSIX_PTHREAD_SEMANTICS -lsocket -lnsl
After having enabled the posix compatibility, it works as expected on posix 
with ipv6only=0.

The bug is bsd-only.

Bye
-- 
Salvo Tomaselli


-- 
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/201004130907.03535.tipos...@tiscali.it