Guy Maor writes ("Bug#342455: tech-ctte: Ownership and permissions of device
mapper block devices"):
> I agree with your technical assessment, Ian.
Do you have an opinion about 660 vs 640 ? And the question of
equivalence to root ?
> On 12/13/05, Ian Jackson <[EMAIL PROTE
Bastian Blank writes ("Re: Bug#342455: tech-ctte: Ownership and permissions of
device mapper block devices"):
> On Tue, Dec 13, 2005 at 03:55:01PM +, Ian Jackson wrote:
> > [Raul Miller:]
> > > 1) change devmapper defaults -- patch rejected, no reason given
&g
Our conclusions apply to the utility md5sum no matter
which version is chosen and no matter which package it is in.
Is there a patch available for coreutils ? I was going to produce one
but I got distracted.
> AFAICT this was dealt with in the tech ctte because
> it was a pet pee
Manoj Srivastava writes ("Re: [Fwd: Re: Induction of new members to the
technical committee]"):
> With bdale voting yes, along with me, and there being no
> responses for a week, the quorumn of two was met, and the motion
> passes.
For the record, I would have voted yes but I was away
Bastian Blank writes ("Bug#342455: tech-ctte: Ownership and permissions of
device mapper block devices"):
> 4) the two attached patches:
>- devmapper: export functions to set permissions
>- lvm2: add a config entry to overwrite the permissions for new
> devices
> I just try to get it
Thanks for organising those resolutions about the TC composition,
Manoj. I have just checked in the update to the TC web page.
Branden, I know we've had your support during our discussions, but it
seems like a good idea to clarify your options if for no other reason
than to set the right preceden
Bdale Garbee writes ("my thoughts on the devmapper question"):
> I believe my contributions to #329409 make my feelings on this issue
> completely clear.
Right.
> However, for the record of this tech-ctte discussion, I firmly believe
> that devmapper should be built with the configure options I
Anthony Towns writes ("Re: Technical committee removal/induction changes"):
> So should we be on the private ctte list now? How does that happen?
I'm waiting for Branden to formally approve you. Has he done so and
his mail got lost ?
The easiest thing with the private list is probably for me to
Steve Langasek writes ("Re: Technical committee removal/induction changes"):
> On Fri, Jan 06, 2006 at 11:09:40AM +, Ian Jackson wrote:
> > I'm waiting for Branden to formally approve you. Has he done so and
> > his mail got lost ?
>
> It went out on debia
Anthony Towns writes ("Re: Technical committee removal/induction changes"):
> On Fri, Jan 06, 2006 at 12:53:57PM +, Ian Jackson wrote:
> > Anthony, Andreas: the easiest way for you to join -private is for me
> > to add your email addresses to the local alias I have
Anthony Towns writes ("Re: Tech ctte tweaks"):
> So I propose we establish a rule that we won't make decisions on issues
> that aren't ready for an immediate NMU when we make that decision.
Except presumably in cases for which no immediate NMU would be
applicable anyway. (For example, we might be
Raul Miller writes ("Re: #342455"):
> I agree that the devmapper default should match other
> debian defaults, and vice-versa.
If I may try to channel Bastian Blank for a moment:
The proposed change to devmapper changes the permissions for all block
devices, doesn't it ? Whereas the other debian
Raul Miller writes ("Re: #342455"):
> On 2/10/06, Ian Jackson <[EMAIL PROTECTED]> channelled:
> > The proposed change to devmapper changes the permissions for all block
> > devices, doesn't it ? Whereas the other debian defaults vary from one
> > kind of
e for new chair?
Why don't we just do this instead:
...
> > - Feb 14th Ian Jackson
> >Feb 15th - Mar 31st Steve Langasek
> >Apr 1st - May 31st Bdale Garbee
> >Jun 1st - Jul 31st Andreas Barth
> >Aug 1st - Sep 30th Raul Mille
Anthony Towns writes ("Re: Tech ctte tweaks"):
> Yo, Ian? If you step down and vote [1] Steve, we're done on this... We're
> already a couple of days into Steve's nominal term as chair...
Err, yes, obviously.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". T
Raul Miller writes ("Re: Tech ctte tweaks"):
> I don't really care if we go about this formally or informally. I don't
> care if it involves a "stepping down" step or not. But I do think that
> Ian's opinion -- as the current chairman -- carries a lot of weight on
> this issue.
I think the right
,
Ian Jackson
Steve Langasek
Raul Miller
Manoj Srivastava
Anthony Towns
Andreas Barth
Bdale Garbee
Each Committee member will server for one calendar month UTC, and
then the cycle will repeat (starting again with Ian Jackson).
(This list was
Steve Langasek writes ("Re: Tech ctte tweaks"):
> As such, I'm in favor of having the chair propose such resolutions early and
> calling for votes, and dispense directly with any ambiguities regarding
> advisory opinions.
That's a reasonable way forward, yes.
Note that it doesn't have to be the c
I hereby propose the following motion and call for a vote.
WHEREAS
1. ndiswrapper's purpose is to allow non-free drivers to be used.
2. While there may be cases where ndiswrapper can be used
with a DFSG-free driver, these are exceptional.
3. The Committee is by and large satisfied with the i
hip rotation here.
Anyone can lead the discussion, propose motions, etc.
> > 4. The rota starts with Ian Jackson for February 2006.
>
> Didn't you just step down as chair?
At the moment we seem to be without a chair. My resolution would have
the effect of appointing me again for ab
I miswrote `achieved' as `required'. So I withdraw my previous motion
and propose the following instead, and call for a vote.
WHEREAS
1. ndiswrapper's purpose is to allow non-free drivers to be used.
2. While there may be cases where ndiswrapper can be used
with a DFSG-free driver, these are
Raul Miller writes ("Bug#353277: ndiswrapper in main"):
> It looks to me as if the sequence of events was:
>
> 1 "open source" windows driver available (can be used with ndiswrapper)
> 2 someone ports windows driver to linux
> 3 linux driver available
>
> These events are sequential, and event 3
Raul Miller writes ("Bug#353277: ndiswrapper in main"):
> On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > Was the open source windows driver ever available as a Debian
> > package ? It seems clear to me that anything which requires you to
> > ins
Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > I miswrote `achieved' as `required'. So I withdraw my previous motion
> > and propose the following instead, and call for a vote.
> &g
Steve Langasek writes ("Re: Technical committee chair rotation, draft
resolution"):
> Voting no, for the record. In addition to the points raised regarding the
> length of term, this resolution purports to be a "decision in advance" about
> who will be elected chair at various future points, whic
Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> This is my rephrasing of Ian's proposal. Changes:
>
> (*) Emphasize the debian dependency issue.
> (*) Emphasize that this is a recommendation, not a command.
>
> Basically, I'm repeating what Ian has already said.
>
> I'm proposing
Steve Langasek writes ("Re: Bug#353277: ndiswrapper in main"):
> 1+5. As noted in my follow-up comments to Ian's proposal, I think the
> rationale is great, but I draw the opposite conclusion from it. :)
I'm afraid you'll have to elaborate on that :-).
> I also didn't see that you had called for
Manoj Srivastava writes ("Re: Tech ctte tweaks"):
> (0) vote for new chair:
> 1) Steve Langasek
> 2) Bdale Garbee
> 3) Andreas Barth
> 4) Raul Miller
> 5) Anthony Towns
> 6) Ian Jackson
>
> (1) Rotating the tech ctte chair
> I vote yes
Steve Langasek writes ("Re: Technical committee chair rotation, draft
resolution"):
> Voting no, for the record. In addition to the points raised regarding the
> length of term, this resolution purports to be a "decision in advance" about
> who will be elected chair at various future points, whic
A. Chairman:
It is clear that:
1. I stepped down as Chairman;
2. Steve, Raul, Anthony and I, and perhaps Manoj,
have all voted for Steve as chairman; so:
3. Steve is now Chairman.
It is not clear whether Manoj voted during the voting period because
it's not clear exactly when I
I think we have had some, erm, procedural difficulties recently.
Without wanting to point fingers at anyone in particular, I have some
suggestions which might help. Many of the observations below are from
having seen the consequences of my own mistakes as well as those of
other TC members, so I fu
Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> After the discussions so far, I'm inclined towards the following two views
> of our policy on this:
>
> * first, that dependencies are one way -- programs depend on
> libraries, but libraries don't depend on the programs th
I've taken a look at the bug logs and I'm very disappointed with the
maintainer's lack of engagement. There seem to be a lot of people who
are interested in helping maintain this package.
Would any of the keen people we see involved in this bug report
consider contesting the maintainership of the
Raphael Hertzog writes ("Re: Bug#353277: ndiswrapper in main"):
> What's so different between my own non-free program and my own non-free
> card which requires a non-free driver to work with ?
You didn't make the card.
(Unless you want to argue that ndiswrapper is for helping hardware
developers
Andreas Barth writes ("Re: Status of resolutions about TC tweaks"):
> We establish a rule that we won't make decisions on issues that are
> ready. This means,
> - for overruling a package maintainer's decision, an appropriate package
> for an NMU exists, and if we overrule, we upload that NMU;
>
I'd like to try to think about this from another point of view. I'm
going to go back and say some things that we're all probably aware of
and then develop from there:
Why does contrib exist ?
1. Dependency-completeness for main:
There is one clear technical reason why
Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> [draft resolution]
I'm afraid I think that that's quite out of order.
Constitution s6.3(3):
3. Public discussion and decision-making.
Discussion, draft resolutions and amendments, and votes by
members of the committee,
Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> Either way, I propose the following, call for a vote on it, and vote
> in favour:
>
> WHEREAS
...
> 6. It is appropriate for the committee to consider this request; and
...
> 8. As such the ndiswrapper package complies with current
Steve Langasek writes ("Re: Bug#353277: ndiswrapper in main"):
> Given that the constitution does specify the use of the standard resolution
> procedure, I think the right answer here is to have a single ballot with
> both proposals on it, so that we have an opportunity to rank the options
> in glo
Raul Miller writes ("Bug#345067: [Yaird-devel] Re: Processed: Escalating
#345067 to the technical comittee, as the maintainer asked me to do so, and is
unable or unwilling to do his job without this."):
> It looks to me like that's a wiki page.
> In other words, you can fix problems on it directl
Here is a version of Anthony's `put it in main' resolution made into a
suggestion rather than an instruction. Below you'll find a diff for
your comfort and convenience.
WHEREAS
1. The committee has been asked by Robert Millan, the submitter of
Bug#353278 and a former developer, to overrule
Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> WHEREAS
I'd like to expand somewhat on my `no' vote. Many of the questions
here were addressed by my earlier messages and I will try to avoid
repeating myself.
> 5. The technical policy in this matter states that: (debian-policy
>
Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > Here is a version of Anthony's `put it in main' resolution made into a
> > suggestion rather than an instruction. Below you'll fi
Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> On Tue, Mar 07, 2006 at 07:39:01PM +, Ian Jackson wrote:
> > Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > > [draft resolution]
> > I'm afraid I think that t
I have overhauled and extended my old draft. See below, and please
comment. I'm not formally proposing this just yet. We should vote on
the alternatives together.
The draft below, broadly speaking:
* is advisory
* says `contrib'
Note that I'm going to be away from my email from Saturday the
Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > In our opinion the relevant principle is that:
> >
> > (i) If the user or administrator who is in charge of the Debian
> >installation
Jonas Smedegaard writes ("Re: Bug#345067: jonas, you are being dishonest."):
> Do you want the technical aspects of this conflict in purely my words?
> I wrote solely all initial editions of the earlier mentioned wiki page
> - do you want me to copy those[2] to an email and GPG-sign it for
> confid
Jonas Smedegaard writes ("Re: Escalating #345067 to the technical comittee, as
the maintainer asked me to do so, and is unable or unwilling to do his job
without this."):
> I disagree with other parts of Svens email, but will avoid commenting
> on those until certain that this is a matter for th
Sven Luther writes ("Bug#345067: [Yaird-devel] Re: Bug#345067: ide-generic on
poweprc"):
> [ a mixture of technical comments and egregious ranting ]
Sven, I am very disappointed that even after we have repeatedly asked
you, in public and in private, to keep your comments civil and
technical you'r
I think it might be a good idea to think somewhat about the more
general case of how we should deal with disputes that have some kind
of technical core to them but where we're not able to come to a solid
conclusion because one or both sides aren't able or willing to
coherently state their case.
Ob
Manoj Srivastava writes ("Re: Bug#353277: ndiswrapper in main"):
> Well, yes. Consider the case that I write up a compiler for a
> new language in C++ or ruby. Can I put this compiler in main? Even
> if there is no public repository of code in this new language?
These arguments seemed e
Steve, thanks for bringing this matter to our attention. I've looked
at the bug log and a summary seems to be:
* cdrtools's Makefiles as distributed by upstream (Joerg Schilling)
do not have a GPL-compatible licence, although the rest of the
code generally claims to be GPL'd
* there is so
I've gotten myself subscribed to pkg-cdrtools-devel and I would like
to quote Joerg Schilling:
Firstly, at the start of a large thread:
> Debian hat ein Kunstwerk von mir verändert und damit gegen das
> Urherberrecht gehandelt.
>
> Mit der Einführung einer Modifikation (buffer size patch)
Ian Jackson writes ("Re: Processed: Forwarding to the technical committee"):
> I've gotten myself subscribed to pkg-cdrtools-devel and I would like
> to quote Joerg Schilling:
>
> Firstly, at the start of a large thread:
> [stuff]
So, analysis:
It seems clear t
Joerg Jaspert writes ("Re: Processed: Forwarding to the technical committee"):
> On 10615 March 1977, Ian Jackson wrote:
> > Do you think it might be helpful if someone tried phoning up Joerg
> > Schilling and trying to negotiate ? Email discussion seems to have
> &g
Steve Langasek writes ("devmapper: call for votes"):
> I'm calling for a vote on the following resolution regarding bug #329409.
> The only proposed amendment, by Raul, has been accepted; so this is the only
> option on the ballot (other than further discussion).
Thanks for that. I'm still uneasy
Steve Langasek writes ("vote time again: stepping down as chair"):
> Regrettably, there hasn't been any discussion since the end of the last vote
> about how to manage these rotations properly without adding undue overhead,
> so I guess that may be something we need to discuss again this round. Fo
Here's a draft, which I hereby propose.
WHEREAS
1. Sven Luther complains that he has been deprived of commit access to
debian-installer's svn repository.
2. Access controls, and changes to them, are a standard response to
sociopolitical problems and it is not for the TC to overrule those
Martin Michlmayr writes ("Bug#366938: svn commit access to the d-i repo ..."):
> The DPL has already agreed that the decision of the d-i team was
> sound, see http://lists.debian.org/debian-boot/2006/05/msg00235.html
Aha! Right, well, I withdraw my earlier resolution and propose this
one instead:
Sven Luther writes ("Bug#366938: svn commit access to the d-i repo ..."):
> Do you want to have the full threads or copy of all the involved emails in
> addition or something ? How will the social mess help you in determining the
> technical nature of this request ?
Since I don't think this is a q
Sven Luther writes ("Bug#366938: svn commit access to the d-i repo ..."):
> As i startedto reply to Ian yesterday, no, i won't start a GR as is [...]
`As is' ?
> I am not sure about a GR to solve this problem
If you are so confident that you have been grievously wronged and that
the developers
Andreas Barth writes ("Re: Bug#366938: svn commit access to the d-i repo ..."):
> sorry for top-quoting. but network is here at debconf a bit flaky
> currently at Debconf. I spoke with Frans about this request, and Frans
> would accept / prefer if we do a real decision about this topic, and not
> s
Steve Langasek writes ("Re: Bug#366938: svn commit access to the d-i repo ..."):
> I don't. I think delegating a decision needs to be a bit more explicit than
> that, it's my understanding that this was just AJ telling Sven what his
> appeal options were. He can of course clarify if he disagrees,
Andreas Barth writes ("Re: Bug#366938: svn commit access to the d-i repo ..."):
> "there is some doubt" reads for me as non-native speaker as "basically,
> the DPL didn't intend, but we cannot prove".
I think that `there is some doubt that foo' usually means `probably
foo, but we are not sure'.
Andreas Barth writes ("Bug#366938: svn commit access to the d-i repo ..."):
> Well, I read the "you can go to the tech ctte" as a delegation by the
> DPL.
Err, I suppose so. In any case, your proposed resolution does no harm
and some good, so I hereby second it. (I'll quote it for completeness.)
Andreas Barth writes ("Re: Bug#366938: svn commit access to the d-i repo ..."):
> Ok, fine with me. So, I propose now the following resolution:
>
> WHEREAS
Excellent, thanks. I call for a vote and vote yes. (Note that you
have two paragraph 3's. We can fix that typo later ...)
Ian.
> 1. Sven
Anthony Towns writes ("Re: Bug#366938: svn commit access to the d-i repo ..."):
> Access controls to source code repos hosted on .debian.org seem a
> technical decision to me, so plausibly within the committee's domain. We
> can, of course, decline to consider the question anyway. I wasn't
> intend
Andreas Barth writes ("Re: Bug#366938: svn commit access to the d-i repo ..."):
> As aj told us he didn't delegate it to us, but rather thinks that we are
> able to decide about it anyways, I think the "Access controls"-paragraph
> needs to be changed, and I change my vote to No.
You are right, an
Raul Miller writes ("Chair rotation"):
> I see several options on how to proceed:
We should elect a new chair in the expectation that it'll be a
permanent appointment.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Andreas Barth writes ("Re: Chair rotation"):
> Well, I think having more often the chair being moved than never is
> still a good idea, but each month was perhaps a bit too often. How about
> trying to set down the rotation level to something like once per year?
Why don't we make a new post of cha
Raul Miller writes ("ndiswrapper"):
> We have a release critical bug filed against ndiswrapper.
...
> So, I'd like to propose that we issue an opinion that ndiswrapper
> needs to be in contrib, to comply with debian policy.
>
> Comments?
I agree.
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTEC
Raul Miller writes ("Re: ndiswrapper"):
> On 9/15/06, Anthony Towns wrote:
> > Other similar things that are in main include coldfire, dosbox, fceu,
> > gngb, pcsx, wine -- the difference there is also that they don't require
> > a non-free ROM to actually provide their emulation.
...
> I'm going
Steve Langasek writes ("Re: ndiswrapper"):
> Written as "free software A does not depend on any non-free software and
> free software C depends on A", I'm inclined to believe that this *is*
> sufficient reason to not exclude A from main.
I agree. But C has to be a real piece of software that peop
Sven Luther writes ("Renewed appeal to the technical committee about the
FransAndCo.Vs.Sven dispute"):
> In order to keep the objectivity and fairness of the technical
> comittee ruling, all those technical comittee members who have a
> vested interest in one side of this matter, and as thus are n
Sven Luther writes ("Re: Renewed appeal to the technical committee
about the FransAndCo.Vs.Sven dispute"):
> [stuff]
I'm glad to see that I'm not on your list of `one-sided' people. Not
that I expect you to be pleased when I tell you this: the reason all
these people are disagreeing with you isn'
Sven Luther writes ("Re: Renewed appeal to the technical committee about the
FransAndCo.Vs.Sven dispute"):
> On Fri, Nov 24, 2006 at 11:43:08AM +, Ian Jackson wrote:
> > 3. Whether or not someone should be permitted commit access to a
> >repository is a so
Steve Langasek writes ("Re: Renewed appeal to the technical committee about the
FransAndCo.Vs.Sven dispute"):
> I am reluctant to ratify this resolution. Although I'm largely in
> agreement, the only slight /potential/ good I see coming from this is that
> going forward, the technical committee m
Sven Luther writes ("Re: Renewed appeal to the technical committee about the
FransAndCo.Vs.Sven dispute"):
> Well, i base this bias on the mails you wrote where you fully sided
> with frans in this issue, and against me. I think you did so more
> than once, altough i don't remember exactly.
Note
Sven Luther writes ("Re: Renewed appeal to the technical committee about the
FransAndCo.Vs.Sven dispute"):
> On Mon, Nov 27, 2006 at 11:46:46AM +, Ian Jackson wrote:
> > Note that the TC makes decisions only as a last resort. This means
> > that for any high profil
Manoj Srivastava writes ("Re: Renewed appeal to the technical committee about
the FransAndCo.Vs.Sven dispute"):
> On Fri, 24 Nov 2006 11:43:08 +, Ian Jackson
> <[EMAIL PROTECTED]> said:
>
> >Please do not contact the committee again on this matter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Steve Langasek writes ("Bug#413926: Call for vote: wordpress: Should not ship
with Etch"):
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> [ 1 ] Choice 1: wordpress should not be included in etch due to bug #413269
> [ 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bdale Garbee writes ("Bug#353277: Call for vote: ndiswrapper: Move to contrib"):
> - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> [ 1 ] Choice 1: ndiswrapper should move to contrib as per bugs #353277...
> [ 3 ] Choice 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bdale Garbee writes ("Bug#385665: Call for vote: fluidsynth: Move to contrib"):
> - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> [ 3 ] Choice 1: fluidsynth should move to contrib as per bug #385665
> [ 1 ] Choice 2: flui
Bdale Garbee writes ("Bug#341839: Call for vote: coreutils: md5sum output
format"):
> As Anthony noted in his early March summary of open issues, the current
> md5sum behavior matches the formats used by upstream, and by related tools
> such as sha1sum, sha256sum, and sha512sum. He suggested th
Bdale Garbee writes ("Bug#367709 reopened"):
> [EMAIL PROTECTED] (Debian Bug Tracking System) writes:
> > reopen 367709
...
> Committee members, am I missing something? Some discussion may be in order
> at least to help me understand whether you now believe this is an issue we
> should vote on?
I
Anthony Towns writes ("Re: Bug#341839: Call for vote: coreutils: md5sum output
format"):
> This horse has bolted already.
>
> ] * Don't worry if md5sum from stdin adds a " -" after the md5sum. Should
> ] make debootstrap more usable on non-Debian Linuxes.
> ] -- Anthony Towns <[EMAIL PROTE
Steve Langasek writes ("Re: Bug#367709 reopened"):
> Other than not being a Debian Developer, I don't see any reason that Sven
> Luther is not "the right person" here; and in cases of overriding a
> Developer, the constitution doesn't actually say that the request has to
> come from a Developer. S
Bdale Garbee writes ("Bug#367709: Call for vote: gcc: requesting
libstdc++.udeb"):
> I hereby call for an immediate TC vote on the question of whether a
> libstdc++ udeb should be created to support the use of C++ in the
> debian-installer environment, as requested by bug #367709.
>
> The udeb s
Manoj Srivastava writes ("Bug#436093: Please decide on the "ownership" of the
developers reference"):
> I am not sure that this is something that ought to be in the
> tech-ctte's jurisdiction; this seems a social problem, not a technical
> one, and thus is not something I think the tech
So as I understand it:
* Andreas argues that he became the lead/sole maintainer with his
commit of 2005-02-02 and that he is therefore the current
maintainer.
* Raphael argues that that commit isn't definitive and that we should
regard Raphael and Andreas as co-maintainers.
?
This is re
Kurt Roeckx writes ("Re: glibc's getaddrinfo() sort order"):
> It's atleast in the spirit of the rfc to prefer one that's on the local
> network. It might be the intention of rule 9, but then rule 9 isn't
> very well written.
I agree that applying RFC3484 section 6 rule 9 to IPv4 addresses is a
m
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> On Fri, Sep 07, 2007 at 01:06:06AM +0200, Kurt Roeckx wrote:
> > It's atleast in the spirit of the rfc to prefer one that's on the local
> > network. It might be the intention of rule 9, but then rule 9 isn't
> > very well written.
>
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> I'm not familiar with how getaddrinfo() has been implemented in the
> past
I think this is an important point. If you're not familiar with the
history then perhaps I can help explain.
hostname-to-address lookups have up to recentl
Julien Danjou writes ("libconfig name clash"):
> My arguments are the following: abz's libconfig is old, non used
> (no reverse-dependencies) and has only 40 installs according to popcon[2].
> Furthermore, it's packaged as a native Debian package and does not seems
> to be distributed anywhere. I d
Andreas Barth writes ("Re: glibc's getaddrinfo() sort order"):
> [stuff]
So, trying to keep stuff simple, I propose:
1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
by Debian systems, and we overrule the maintainer.
2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses
b
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> So if getaddrinfo() has always behaved in this way, I don't see a great
> deal of justification in changing it. The bug log indicated that there
> were pre-rfc implementations of getaddrinfo() that behaved more like
> gethostbyname()
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> On Tue, Sep 18, 2007 at 05:09:43PM +0100, Ian Jackson wrote:
> > Andreas Barth writes ("Re: glibc's getaddrinfo() sort order"):
> > > [stuff]
> > So, trying to keep stuff sim
hin 1
week, Ian Jackson is mandated to make an NMU in sid.
2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses
by Debian systems. However, we do not overrule the maintainer
on this point and we do not authorise changing it via an NMU.
3. We recommend to the IETF that RFC3484
Ian Jackson writes ("Call for Votes (Re: glibc's getaddrinfo() sort order)"):
> -8<-
>
> 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
> by Debian systems, and we overrule the maintainer. If the
> maintainer has not uploaded a suitabl
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> On Thu, Sep 20, 2007 at 06:19:10PM -0700, Steve Langasek wrote:
> > So do you have a use case where you think the behavior described in rule 9
> > *is* desirable?
>
> Any application written assuming this behaviour, works correctly o
201 - 300 of 1203 matches
Mail list logo
