Re: Call for Votes (Re: mixmaster /etc/default/*)
On Sun, Dec 02, 2007 at 10:13:38PM +, Ian Jackson wrote: -8- (1) The REMAIL option should not be supplanted or supplemented by anything in an /etc/default file. The current behaviour of the mixmaster init script, to examine /etc/mixmaster/remailer.conf's REMAIL option, is correct. (2) Policy is clear and correct, and need not be changed. -8- [1] Choice K: Keep current behaviour and existing policy, as above. [2] Choice F: Further discussion I agree with the rationale provided by Ian with his vote. To the issue of whether it's proper for the TC to rule on this question, constitutionally there is nothing that requires that bug reports be successfully assigned to the tech-ctte virtual package in the Debian BTS before the TC will consider it. Indeed, the /intent/ to bring the question before the TC is clear, and the committee has already been considering the question in detail. I see no reason not bring this to a speedy resolution, answering the technical question that has been put to us; and any other course of action would appear to have a greater impact on the time of this body. To whether this ruling could be misinterpreted as a decision to override the maintainer, I don't find any ambiguity here. Reaffirming the maintainer's current decision, as this resolution does, should not be understood as overriding any hypothetical future decisions on the part of the maintainer, although it should certainly guide those decisions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Call for Votes (Re: mixmaster /etc/default/*)
* Ian Jackson ([EMAIL PROTECTED]) [071202 23:14]: -8- (1) The REMAIL option should not be supplanted or supplemented by anything in an /etc/default file. The current behaviour of the mixmaster init script, to examine /etc/mixmaster/remailer.conf's REMAIL option, is correct. (2) Policy is clear and correct, and need not be changed. -8- [1] Choice K: Keep current behaviour and existing policy, as above. [2] Choice F: Further discussion I agree to the rational provided by Ian. I assume the voting means we are not overriding the maintainer, i.e. this vote doesn't restrict the right of the maintainer to adjust the behaviour as he considers appropriate. Cheers, Andi -- http://home.arcor.de/andreas-barth/ signature.asc Description: Digital signature
Re: Call for Votes (getaddrinfo)
On Thu, Dec 06, 2007 at 01:58:47AM -0800, Steve Langasek wrote: I do think that this bug warrants fixing in stable, I just don't agree that RCness is the relevant and appropriate standard for whether the TC should override a maintainer. You seem to be ok with overriding the libconfig maintainer's choice of source package name, but I haven't seen it suggested that the libconfig package needs to be renamed in stable? The rationale given for overriding the maintainer is that this is a horrible bug that's breaking Internet servers everywhere, including our own. I haven't seen any evidence of that, but if it's the case, or at least the basis for us to overrule the maintainer, then in order to stop it from happening we should be ensuring it's fixed in stable as well. It seems to me absolutely irresponsible to say an issue's a blight on the Internet, and then not worry about what happens for stable. Well, either that, or dishonest, in that we're not worrying about fixing it in stable because it isn't a major problem, even though we're saying it is. If that's not our rationale, the only other one I've seen is essentially this is daft behaviour that doesn't do any one any good and shouldn't be in the RFC, which I agree with, but don't think warrants overruling the maintainer's decision that it's not important enough to warrant changing the default behaviour versus upstream. I'm amenable to including a statement about RCness in the resolution if that's relevant to getting it passed, I just don't believe it's necessary for getting the bug fixed in etch. If we're saying this is a major issue that needs to be fixed throughout Debian, and we trust the maintainers and release team to give that appropriate priority, without explicitly saying release critical, that's fine, but TBH I don't see any practical difference between saying the above and saying this is RC, at all. I'm pretty sure I dislike the idea of being eager to dive into issues where we're looking at overruling package maintainers (mixmaster, libconfig and exim, atm eg) and extremely reluctant to even make suggestions about release policy. Particularly when there're plenty of ways of overruling package maintainers (uploading a differently named version of the same software, NMUs, ftpmaster NEW/REJECT handling, peer pressure on -devel, QA monitoring and removal requests, policy guidelines from -policy, RMs setting RC severities, tech-ctte, and GR) and very few of overruling RM decisions (tech-ctte, GR, and conceivably DPL redelegation). Josip was not the first or only person that I heard say this, but I think the other comments were made on IRC. I'll try to track down some hard data on this. From memory, the server in the http.us.debian.org rotation that was being hit out of proportion was ike.egr.msu.edu, but I don't know yet that this was confirmed as being a jump in relative traffic as opposed to a jump in absolute traffic. It would be consistent with RFC3484 behavior on the part of hosts on 10.x.x.x intranets, though. Well, okay... but shouldn't it still be happening if that's the case? Unless we've somehow lost a significant number of 10.0.0.0/8 hosts that were pointing at ftp/http.us.d.o at that point and now aren't, ike is still the host that they should be all hitting so demonstrating the load imbalance caused by 10.0.0.0 hosts should be trivial if we have any access to ike's logs. Actually, almost every apt host hitting ike via an address above 64.0.0.0 ought to be a NATed 10.0.0.0/0 host (unless it's being proxied from a 64.0.0.0 by a 64.0.0.0 address, or has a real IP 64.0.0.0 but is being NATed to 64.0.0.0 anyway for some reason). If we had logs from ike, that should be enough to give us an estimate on how many 10.0.0.0 hosts we have (x = real hosts for ike, y = 10.0.0.0 hosts; a = 64.0.0.0 address hitting ike, b = 64.0.0.0 addresses hitting ike; b ~= 3/4y; a+b = x+y; y ~= 4b/3; x = a+b-y ~= a+b/4; proportion of 10.0.0.0 hosts to all real addresses ~= y / 4x ~= 4b / (12a+3b)). At some point ftp.us.d.o was just one host, which could also have (obviously) caused one host to get more traffic than the others; but I don't recall when that was, or which host it was though. Cheers, aj signature.asc Description: Digital signature
Re: Call for Votes (Re: mixmaster /etc/default/*)
Andreas Barth writes (Re: Call for Votes (Re: mixmaster /etc/default/*)): I assume the voting means we are not overriding the maintainer, i.e. this vote doesn't restrict the right of the maintainer to adjust the behaviour as he considers appropriate. Absolutely. For the avoidance of any doubt, I don't think that decisions of the TC should be interpreted as overruling the maintainer unless that is the only possible interpretation of the resolution's text. In the past it has always been clearly stated if we intend to overrule the maintainer. We should continue that practice. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package-created usernames
Bdale Garbee writes (Re: Package-created usernames): The second is whether it's acceptable for a Debian package to *require* a specific username. There seems to be at least an implication that if the namespace clash potential is eliminated or significantly reduced, that this would remove the need for supporting configurability of the username used by a package or set of packages. I'm very concerned about this, since I believe that no matter how well we solve the namespace potential collision problem, there will always be users of our packages in large installation environments who have already made decisions about their username namespace that they want Debian systems to be able to fit in to without requiring rework or recompilation of packages. I can see your point but I think it is in general impractical to require programs not to have compiled-in usernames. A great many of our standard daemons work that way. If we choose a `sufficiently good' naming scheme then I think problems are very unlikely. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (getaddrinfo)
On Thu, Dec 06, 2007 at 10:22:51PM +1000, Anthony Towns wrote: Well, okay... but shouldn't it still be happening if that's the case? Unless we've somehow lost a significant number of 10.0.0.0/8 hosts that were pointing at ftp/http.us.d.o at that point and now aren't, ike is still the host that they should be all hitting so demonstrating the load imbalance caused by 10.0.0.0 hosts should be trivial if we have any access to ike's logs. Afaik, there is a whole bunch of cable users in the 24.0.0.0/8 range in the US. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (Re: mixmaster /etc/default/*)
Steve Langasek writes (Re: Call for Votes (Re: mixmaster /etc/default/*)): On Sun, Dec 02, 2007 at 10:13:38PM +, Ian Jackson wrote: [1] Choice K: Keep current behaviour and existing policy, as above. [2] Choice F: Further discussion I agree with the rationale provided by Ian with his vote. Thanks for your vote and your additional rationale in response to AJ, (which as I say I agree with). I'd like to make one small suggestion: when we members of TC member vote, it would probably best if we remove the `' quotation marks from the LHS of the ballot. Likewise, if we quote someone else's vote when replying to their message, we should remove the ballot entirely or at least remove the cut lines (Don't Delete Anything Between These Lines). Perhaps we should rename the cut lines Actual Ballot Is Between These Lines. This will make it quite clear when the message is a vote, and when it is just quoting of someone else's vote. As an example of the confusion that can arise otherwise: Resent-Message-ID: [EMAIL PROTECTED] To: debian-ctte@lists.debian.org ... On Fri, Nov 30, 2007 at 12:54:51PM +1000, Anthony Towns wrote: On Thu, Nov 29, 2007 at 07:51:37PM +, Ian Jackson wrote: -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above. [ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo [1] Choice M: Leave the choice up to the maintainers. [2] Choice F: Further discussion -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- The don't delete anything between these lines seems pointless since we're not using a program to tally votes... [more discussion deleted - iwj] I do think that this bug warrants fixing in stable, [ rest of response deleted -iwj] It seems clear to me from context and content that the author of jS15UNlaTtL.A.umB.sf8VHB did not intend to vote 1:M,2:F on this ballot, but was merely quoting AJ. But if we continue the habit of voting with `' at the LHS of our ballots, and quoting other people's ballots in their entirity, messages where the intent is unclear are likely to arise. For the avoidance of any doubt, I do not intend this message to be casting any vote :-). Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Flogging dead horses
Anthony Towns writes (Re: TC voting and amendment procedure): The substantive questions haven't been explored. I've been the only one doing that, and we _remain_ with absolutely no evidence [...] Well, I think it must be clear to you that I (and others on the committee) disagree. The question is whether to argue some point, or whether to consider the conversation essentially finished. Whether to pursue a point depends not on whether in some objective sense the case for one side or the other has been made sufficiently. Is it not clear to you that in my opinion the case has been fully made out ? Can you not see that in my opinion there is nothing more I could say (or with reasonable effort provide) that would convince you ? (If not I don't see how I could have made myself plainer.) There is no point in telling us over and over again that you are unconvinced. We know you are unconvinced. There is no point in telling us over and over again that you think further discussion or investigation would be helpful, and repeating your reasons ad nauseam. We know. It is beside the point to complain that we are moving to a vote when you remain unconvinced that we are right - even if you think that in there might well be evidence which would convince you if only we could be bothered to collect it. It will sometimes be the case that a sufficient majority will conclude that the discussion is essentially finished, and all relevant information is collected and argument had, and that evidence that their proposed decision is wrong is not going to show up - even though a minority disagrees and thinks that there are still open questions. It is of course good for us all to try to convincing each other, honestly, and to try to bring the whole of the committee (and indeed all of the other parties) along with our conclusions. But there will sometimes come a point where a sufficient majority exists who agree both about how the matter should be decided and that further discussion or investigation is not going to be helpful. The right answer in that situation is for us to vote and get the matter over with. The dissenter(s) should write their reasons up in a coherent rationale and attach it to their vote(s). You haven't tried convincing me; you've gathered absolutely no evidence, Are you accusing me of bad faith ? I feel that I have presented what I felt were convincing arguments which you have rejected. I understand that you feel that further evidence of operational problems is necessary and might be convincing to you. But I feel that, given your response to the information and arguments which have been provided so far, the quality of the evidence which is likely to be available within a reasonable time and with reasonable effort is unlikely to be sufficiently convincing to you. Note, I'm not saying you're refusing to be convinced. I just think that your starting point is sufficiently far away from my view that it would be disproportionately difficult to collect sufficient evidence to convince you. I may well be wrong. All of what I've just said about the merits of further evidence, the effort of collecting it, the likelihood of it convincing you, and so on, is just my opinion. Obviously you disagree or you wouldn't be asking for more evidence. That's fine by me. You're allowed to disagree with me. Will you please accept that I am allowed to disagree with you ? Even about meta-questions like whether a particular argument is convincing, whether enough evidence has been collected or is likely to be, who is likely to be convinced by what, and so on ? Thorough discussion of these kind of meta-questions is usually worthless because one's views depend so much on one's views on the substance. Decisions in Debian are meant to be made by maintainers, not some core team. If your time with Canonical has made you come to another view, that's fine, but it's not the way Debian does or should work. If your lifestyle changes mean you've just got too much time on your hands, you should be spending it hacking on Debian, not bossing other developers around. That is an unwarranted personal attack. Please withdraw it. For the avoidance of any doubt, my time with Canonical did not lead me to look more favourably on more centralised decisionmaking models. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (getaddrinfo)
Ian Jackson writes (Call for Votes (getaddrinfo)): -8- 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses by Debian systems, and we DO overrule the maintainer. 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses by Debian systems. We do NOT overrule the maintainer. 3. We recommend to the IETF that RFC3484 s6 rule 9 should be abolished for IPv4, and that it should be reconsidered for IPv6. -8- [ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above. [ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo [ ] Choice M: Leave the choice up to the maintainers. [ ] Choice F: Further discussion The following people appear to me to have voted as follows, within the 7-day period, which has just expired: X F S M Ian, Manoj X F M S Andi M F AJ F defeats S by 4:0, so S is eliminated. F defeats M by 3:1, so M is eliminated. The remaining non-default option is X. It has a 3:1 supermajority requirement. X defeats F by 3:1, which is exactly sufficient. Thus X wins and the resolution between -8- above has been passed, overruling the maintainer. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (Re: mixmaster /etc/default/*)
* Ian Jackson ([EMAIL PROTECTED]) [071206 20:08]: For the avoidance of any doubt, I don't think that decisions of the TC should be interpreted as overruling the maintainer unless that is the only possible interpretation of the resolution's text. In the past it has always been clearly stated if we intend to overrule the maintainer. We should continue that practice. Good that we agree. :) Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFC3484 s6 rule 9 should not apply
reassign 438179 glibc thanks The Technical Committee has decided as follows: 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses by Debian systems, and we DO overrule the maintainer. 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses by Debian systems. We do NOT overrule the maintainer. 3. We recommend to the IETF that RFC3484 s6 rule 9 should be abolished for IPv4, and that it should be reconsidered for IPv6. The supermajority requirement for overruling the maintainer was met. To the glibc maintainer: would you like to take responsibility for implementing the Committee's decision, or would you prefer someone to make an NMU ? Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC3484 s6 rule 9 should not apply
On Thu, Dec 06, 2007 at 08:11:51PM +, Ian Jackson wrote: reassign 438179 glibc thanks The Technical Committee has decided as follows: 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses by Debian systems, and we DO overrule the maintainer. 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses by Debian systems. We do NOT overrule the maintainer. 3. We recommend to the IETF that RFC3484 s6 rule 9 should be abolished for IPv4, and that it should be reconsidered for IPv6. The supermajority requirement for overruling the maintainer was met. To the glibc maintainer: would you like to take responsibility for implementing the Committee's decision, or would you prefer someone to make an NMU ? Next time, please Cc: the maintainer if you want to be sure to have an answer (hopefully I have seen that the bug has been reassigned). Please DON'T NMU the glibc, we will do the necessary in the next upload to unstable. Does this also apply to stable? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (getaddrinfo)
Ian Jackson writes (Re: Call for Votes (getaddrinfo)): Thus X wins and the resolution between -8- above has been passed, overruling the maintainer. I think we should send our rationales, including dissents, to the bug report. I've collated the opinions that people attached to their votes and the result is below. I've included the assenting views in the order they were emailed, as that seems to make them easiest to make sense of. There was one dissent, which I put at the end. If there were several they too should probably have come in chronological order. It makes most sense to put dissents after assents as they're more likely to be responsive to assents than vice versa, and also to avoid confusing readers with a conflicting view at the start of the text. Normally I think we should just send a collation like the one below straight to the bug report and other interested parties along with the actual decision text, but since this is a new process for dealing with rationales I thought people might want a chance to comment. I definitely think we should probably take the rationale text attached to votes as definitive, and not look through the whole mail thread. If a TC member wishes to amend or augment their rationale after voting they should do so very explicitly. Ian. Ian Jackson, assenting: Introduction 1. We have been asked to rule on the application of RFC3484 section 6 rule 9 by the resolver in glibc. 2. Rule 9 requires a host to sort addresses according to the length of the initial prefix common with the host's own address, when deciding which of a peer's addresses to try in which order. Thus eg, a host 172.18.45.11 would prefer to make a connection to 172.18.45.6 rather than to 172.31.80.8. 3. This has been implemented in glibc upstream by having the DNS resolver sort addresses before passing them to the application via getaddrinfo. Background and history 4. Prior to the publication and implementation of RFC3484, and prior to the introduction of getaddrinfo, most hosts would use an implementation of gethostbyname to find IPv4 addresses to use for a peer, given its hostname. gethostbyname has almost universally returned the addresses in the order supplied by whatever DNS nameserver it was using. 5. In 1993, the then-ubiquitous nameserver implementation BIND was modified to implement a feature known as `DNS Round Robin'. This does not need to be explained in detail, but the intended and actual effect was that clients would be provided addresses (and other records) in a deliberately varying order, so that in the aggregate clients' choice of address to use would be distributed uniformly across the published addresses. 6. Between then and the recent implementation of rule 9 by some hosts, DNS round robin became universally deployed. It has been implemented by other nameservers and has become a de facto standard at least for the interpretation of multiple IPv4 addresses in the global DNS. IPv6 transition 7. The primary use of getaddrinfo is to replace gethostbyname when an application is converted to support IPv6. gethostbyname cannot be sensibly used to support IPv6; while there are other interfaces that can be used instead, the routine practice has been to make certain very consistent sets of changes to applications, which include replacing the use of gethostbyname by getaddrinfo. 8. gethostbyname in current glibc does not implement rule 9. The effect therefore is that whether a particular host follows rule 9 for a particular protocol depends mainly on whether that particular version of the application in question has been updated in the host's operating system to support IPv6. (As well as, of course, whether the operating system's getaddrinfo uses rule 9.) 9. There are no known applications which specifically desire the rule 9 behaviour; we know of no case where an application uses getaddrinfo specifically to get rule 9. 10. There is therefore no rational reason for the difference between the behaviour of gethostbyname and getaddrinfo, other than perhaps implementation convenience. Compatibility and benefits 11. Rule 9 is incompatible with the DNS Round Robin. Prior to rule 9, a system administrator would publish multiple addresses in the intent and expectation of getting roughly equal client load on each address. 12. When Debian's apt changed its behaviour to follow rule 9, it broke ftp.us.debian.org because the load suddenly became very unbalanced. Thus this incompatibility causes actual operational problems. 13. We know of no situations where multiple IPv4 addresses on the global Internet are published with the intent and expectation that rule 9 will be followed by
Re: RFC3484 s6 rule 9 should not apply
* Aurelien Jarno ([EMAIL PROTECTED]) [071206 21:41]: Please DON'T NMU the glibc, we will do the necessary in the next upload to unstable. Does this also apply to stable? The tech ctte didn't do a decision about stable, though it seems that most of us consider it appropriate. So I would prefer the usual way: First upload the fix to unstable, wait till it is properly tested and then get it into the next stable point release via d-release (and give the SRMs the possibility to test it, I'm not speaking with my SRM hat on here). Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (getaddrinfo)
Steve Langasek writes (Re: Call for Votes (getaddrinfo)): On Thu, Nov 29, 2007 at 07:51:37PM +, Ian Jackson wrote: This time can we _please_ try to get quorum ? You must send in your vote within 7 days of me sending this message, for it to count, ie by approximately 2007-12-06 19:50 +. Well, not much leeway here it seems. FWIW, my vote on this resolution was going to be: The 7-day limit was not imposed by me and is not discretionary. It is specified in the Constitution, section 6.3(1): ... The voting period lasts for up to one week, or until the outcome is no longer in doubt. ... If there had been a timezone change the question of exactly what `one week' might mean might be relevant but in this case I can't see how it could mean anything other than 7 24-hour days. My call for votes was timestamped by my own system and then by Debian's listprocessing system with Date: Thu, 29 Nov 2007 19:51:37 + Resent-Date: Thu, 29 Nov 2007 19:52:32 + (UTC) No-one (including you) challenged this interpretation during the intervening week (or indeed on previous occasions). No-one complained that my message had been delayed in transit or that there was some error with the timestamps, and you don't allege such a problem here. Your message was timestamped by your own system with Date: Thu, 6 Dec 2007 15:37:18 -0800 with is the same as 2007-12-06 23:37:18 +, and the timestamps in the other headers agree. So I conclude that your message arrived a shade under 3h45m after the constitutionally specified deadline. I even clearly stated the deadline in my call for votes, precisely to try to avoid anyone who wanted to vote failing do so within the specified period. I don't see how my warning could have been more clear and explicit (given that of course the precise datestamp on my message exists only after I have sent it). And of course it's irrelevant whether or not I warned anyone of this deadline; it was not my responsibility to do so and the deadline does not depend on whether or not I announced it in advance, and nor do any of us have the power to waive it. I think 7 days is plenty of leeway. You sent plenty of messages yourself in the intervening week and there were reminders in the form of votes from other TC members as well as of course the informal messages of various kinds. If you thought you might want to change your mind you even had the option of sending in a vote for FD right away and changing your vote later. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (getaddrinfo)
On Thu, Dec 06, 2007 at 08:08:06PM +, Ian Jackson wrote: Ian Jackson writes (Call for Votes (getaddrinfo)): -8- 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses by Debian systems, and we DO overrule the maintainer. 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses by Debian systems. We do NOT overrule the maintainer. 3. We recommend to the IETF that RFC3484 s6 rule 9 should be abolished for IPv4, and that it should be reconsidered for IPv6. -8- [ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above. [ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo [ ] Choice M: Leave the choice up to the maintainers. [ ] Choice F: Further discussion The following people appear to me to have voted as follows, within the 7-day period, which has just expired: X F S M Ian, Manoj X F M S Andi M F AJ F defeats S by 4:0, so S is eliminated. F defeats M by 3:1, so M is eliminated. The remaining non-default option is X. It has a 3:1 supermajority requirement. X defeats F by 3:1, which is exactly sufficient. I may wish this was true, but when reading the constitution again, I'm not sure at all we have a 3:1 ratio. It says: 3. Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration. 1. Given two options A and B, V(A,B) is the number of voters who prefer option A over option B. 2. An option A defeats the default option D by a majority ratio N, if V(A,D) is strictly greater than N * V(D,A). 3. If a supermajority of S:1 is required for A, its majority ratio is S; otherwise, its majority ratio is 1. V(X,F) seem to be 2, V(F,X) seem to be 1, or a ratio of 2:1. So if 1 person ranks X below F, you need *4* people to rank option X above F. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: kangaroos
Processing commands for [EMAIL PROTECTED]: tag 438179 - pending Bug#438179: Please provide a way to override RFC3484 Tags were: pending confirmed Tags removed: pending quit Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: RFC3484 s6 rule 9 should not apply
Processing commands for [EMAIL PROTECTED]: reassign 438179 tech-ctte Bug#438179: Please provide a way to override RFC3484 Bug reassigned from package `glibc' to `tech-ctte'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC3484 s6 rule 9 should not apply
reassign 438179 tech-ctte thanks On Thu, Dec 06, 2007 at 08:11:51PM +, Ian Jackson wrote: The Technical Committee has decided as follows: This is incorrect. The supermajority requirement was not met, see: http://lists.debian.org/debian-ctte/2007/12/msg00067.html As such, no decision's been made. The Glibc team may, of course, decide to change the default behaviour themselves in the meantime while the ctte continues to go round in circles. Cheers, aj signature.asc Description: Digital signature
Re: Call for Votes (getaddrinfo)
On Fri, Dec 07, 2007 at 01:25:29AM +0100, Kurt Roeckx wrote: 7-day period, which has just expired: X F S M Ian, Manoj X F M S Andi M F AJ F defeats S by 4:0, so S is eliminated. F defeats M by 3:1, so M is eliminated. The remaining non-default option is X. It has a 3:1 supermajority requirement. X defeats F by 3:1, which is exactly sufficient. I may wish this was true, but when reading the constitution again, I'm not sure at all we have a 3:1 ratio. We don't. See also http://lists.debian.org/debian-ctte/2004/05/msg00027.html Cheers, aj signature.asc Description: Digital signature
Bug#438179: marked as done (Please provide a way to override RFC3484)
Your message dated Fri, 07 Dec 2007 07:17:05 + with message-id [EMAIL PROTECTED] and subject line Bug#438179: fixed in glibc 2.7-4 has caused the attached Bug report 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 I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: glibc Version: 2.6.1-1 Severity: important Hi, It seems that getaddrinfo() seems to sort the results, which defeats the point of having multiple A-records in the first place. If I look up 0.pool.ntp.org I (now) get: 0.pool.ntp.org has address 193.39.78.2 0.pool.ntp.org has address 195.34.187.132 0.pool.ntp.org has address 202.73.37.27 0.pool.ntp.org has address 212.24.114.156 0.pool.ntp.org has address 217.116.227.3 0.pool.ntp.org has address 62.75.136.76 0.pool.ntp.org has address 62.245.224.171 0.pool.ntp.org has address 64.5.1.129 0.pool.ntp.org has address 66.180.136.186 0.pool.ntp.org has address 80.86.83.133 0.pool.ntp.org has address 81.169.172.219 0.pool.ntp.org has address 85.25.252.58 0.pool.ntp.org has address 88.198.8.101 0.pool.ntp.org has address 91.121.13.62 But getaddrinfo() will always return ip's in this order: 62.75.136.76 62.245.224.171 64.5.1.129 [...] There seems to be some variation in the list, but the first 4 or 5 are always the same. I only care about the first one. It should keep the order of the A-records the same as they were returned by the dns server. Kurt ---End Message--- ---BeginMessage--- Source: glibc Source-Version: 2.7-4 We believe that the bug you reported is fixed in the latest version of glibc, which is due to be installed in the Debian FTP archive: glibc-doc_2.7-4_all.deb to pool/main/g/glibc/glibc-doc_2.7-4_all.deb glibc_2.7-4.diff.gz to pool/main/g/glibc/glibc_2.7-4.diff.gz glibc_2.7-4.dsc to pool/main/g/glibc/glibc_2.7-4.dsc libc6-dbg_2.7-4_amd64.deb to pool/main/g/glibc/libc6-dbg_2.7-4_amd64.deb libc6-dev-i386_2.7-4_amd64.deb to pool/main/g/glibc/libc6-dev-i386_2.7-4_amd64.deb libc6-dev_2.7-4_amd64.deb to pool/main/g/glibc/libc6-dev_2.7-4_amd64.deb libc6-i386_2.7-4_amd64.deb to pool/main/g/glibc/libc6-i386_2.7-4_amd64.deb libc6-pic_2.7-4_amd64.deb to pool/main/g/glibc/libc6-pic_2.7-4_amd64.deb libc6-prof_2.7-4_amd64.deb to pool/main/g/glibc/libc6-prof_2.7-4_amd64.deb libc6-udeb_2.7-4_amd64.udeb to pool/main/g/glibc/libc6-udeb_2.7-4_amd64.udeb libc6_2.7-4_amd64.deb to pool/main/g/glibc/libc6_2.7-4_amd64.deb libnss-dns-udeb_2.7-4_amd64.udeb to pool/main/g/glibc/libnss-dns-udeb_2.7-4_amd64.udeb libnss-files-udeb_2.7-4_amd64.udeb to pool/main/g/glibc/libnss-files-udeb_2.7-4_amd64.udeb locales-all_2.7-4_amd64.deb to pool/main/g/glibc/locales-all_2.7-4_amd64.deb locales_2.7-4_all.deb to pool/main/g/glibc/locales_2.7-4_all.deb nscd_2.7-4_amd64.deb to pool/main/g/glibc/nscd_2.7-4_amd64.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Aurelien Jarno [EMAIL PROTECTED] (supplier of updated glibc package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 07 Dec 2007 00:49:02 +0100 Source: glibc Binary: libc0.1-prof libc6.1-alphaev67 libc6-dev-amd64 locales-all libc6-i686 libc6-dev-ppc64 libc0.3-pic glibc-doc libc0.3 libc6-dev-mipsn32 libc0.1-i686 libc0.1-i386 libc6-mips64 libc6.1-dev libc6-s390x libnss-files-udeb libc0.1-dev-i386 libc6-dev-sparc64 libc6-i386 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc0.1-udeb libc6-dev-i386 libc6.1-prof libc6-mipsn32 libc0.1-dev locales libc6-pic libc0.3-udeb libc6-dev-powerpc libc0.1-pic libc6-ppc64 libc0.3-dbg libc0.1-dbg libc6-amd64 libc0.1 libc6-prof libc6-xen libc6-dev-mips64 libc6-powerpc libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc6-dev-s390x Architecture: source amd64 all Version: 2.7-4 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno [EMAIL PROTECTED] Changed-By: Aurelien Jarno [EMAIL PROTECTED] Description: glibc-doc - GNU C Library: Documentation libc6 - GNU C Library: Shared libraries libc6-dbg - GNU C Library: Libraries with debugging symbols libc6-dev - GNU C Library: Development Libraries and Header Files libc6-dev-i386 - GNU C Library:
