On Mon, Sep 14, 2015 at 09:37:28AM -0400, Sam Hartman wrote:
> What I'm hearing is that there seems to be general support for TC
> members calling for quick votes in cases like this. If I were doing it
> I'd probably give 24 hours to comment on an interim ballot and then do a
> CFV.
It seems to m
(bug dropped, subject changed)
On Thu, Sep 10, 2015 at 01:32:16PM -0400, Sam Hartman wrote:
> > "josh" == josh writes:
> josh> That's not a bad plan, actually. The three standard options
> josh> could be, in effect, "preliminary injunction against the
> josh> maintainer to avoid
On Wed, Sep 09, 2015 at 10:31:24PM +0100, Wookey wrote:
> +++ Steve Langasek [2015-09-09 12:17 -0700]:
> > On Wed, Sep 09, 2015 at 05:30:03PM +0100, Wookey wrote:
> > > So what I learned from this is that, as currently operating, the
> > > committee is incapable of making quick 'overrule unreasonab
On Tue, Mar 31, 2015 at 12:40:00AM +, Sam Hartman wrote:
> Steve, in one of the TC meetings last year, you made the claim that the
> policy process was not a rough consensus process.
I believe this was:
keithp: our policy process isn't based on "rough
consensus", but on a stricter d
Packard:
3. We propose to the DPL that Keith Packard should be appointed
to the TC. (Constitution 6.2(2))
Option Kern:
4. We propose to the DPL that Philipp Kern should be appointed
to the TC. (Constitution 6.2(2))
That seems like a sensible structure to continue to me?
Cheers,
aj
--
Anthony Towns
ter the 1st new ctte member nomination gets approved by the DPL?
Cheers,
aj
--
Anthony Towns
ight go some distance to re-establishing some trust. The systemd
developers (both upstream and the Debian maintainers) certainly seem to
have had more "demonisation" than the committee to me.
Cheers,
aj
--
Anthony Towns
ject or resign from a particular post
they hold, at any time, by stating so publicly.
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
suckah"
To make that provision work, I think you'd have to have a minimum
voting period, in which case I don't think there's any value beyond
just having a minimum discussion period.
But ultimately, if a majority of the ctte want to vote on a particular
question that's within
ms like
having that be separate from the ctte's duties in general would be a
better plan than allowing discussions to go secret whenever someone
thinks it would be "counterproductive".
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debia
I
don't know how you could do that more effectively; must/should/may
still seems reasonable to me, but it doesn't seem that effective.
Splitting them as three separate documents (distro/release
requirements, policy, suggested practices) might be an option. Maybe
it would be more e
On Sat, Feb 08, 2014 at 12:56:56PM -0700, Bdale Garbee wrote:
> Bdale Garbee writes:
> > - - - start ballot - - -
> > We exercise our power to decide in cases of overlapping jurisdiction
> > (6.1.2) by asserting that the default init system for Linux
> > architectures in jessie should be
> > D
On 10 February 2014 06:41, Serge Kosyrev wrote:
> False. Three messages on this list brought this conflict of interest
> into light:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#2810 by Anthony Towns
> [...]
> There was no answer.
So, fwiw, I thought the above was
n that case, wouldn't it make sense to have a quick chat with the
other policy editors about officially delegating the task of deciding
on policy for depending on init systems to the tech ctte?
Could even open a new bug for it!
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-
On 8 February 2014 18:26, Adrian Bunk wrote:
> On Sat, Feb 08, 2014 at 04:40:22AM +0000, Anthony Towns wrote:
>> I'd consider that tactical voting. Basically, I think the value in the
>> FD option is to be able to say "this option has not been fully baked,
>> and m
Bug cc dropped, replaced with -ctte.
On Fri, Feb 07, 2014 at 08:29:27AM +0200, Adrian Bunk wrote:
> On Fri, Feb 07, 2014 at 08:59:59AM +1000, Anthony Towns wrote:
> > It's really pretty terrible to actively use FD to try to block options
> > that aren't your favourite.
y allowing
proposals to be blocked by 1/N voters voting for FD where N > 2)
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debia
er ctte members will also vote FD above
T or DT (given UT is irrelevant); which based on the already expressed
preferences and votes, isn't actually going to happen.
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "uns
On 6 February 2014 16:27, Anthony Towns wrote:
> Rankings between remaning actual outcomes is:
> 4x UL > DL > UT > DT (steve, colin, ian, andi)
> 2x DT > DL > UT > UL (russ, don)
Ah! I thought there was something to add here
The above votes divide neatly i
:2
UL > UT > DT 4:2
DL > UT 6:0
It seems to me that if this ballot fails to FD, any future ballots
should skip options:
OT, VT (insufficient support over FD)
OL, VL (at least 6 of 8 committee members prefer UL and DL over
these options)
It seems unlikely that there's
Hey Colin,
On 29 January 2014 21:13, Colin Watson wrote:
> On Wed, Jan 29, 2014 at 07:21:43AM +1000, Anthony Towns wrote:
>> > Q2: Is it OK for packages to depend on a specific init system as
>> > pid 1 ?
>> Q2a: Is it OK for packages providing init systems to p
On 2 February 2014 04:05, Uoti Urpala wrote:
> On Sat, 2014-02-01 at 17:10 +, Ian Jackson wrote:
>> Sébastien Villemot writes ("Bug#727708: TC resolution revised draft"):
>> > P1: DT > UT > DL > UL
> So his example was one where the D/U and L/T choices were independent
> for every voter,
For
ust be able to apt-get install it and be just as
cool as aj is". I don't think that's a win.
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cajs_lcxhqy5ubbtm6s9pujagdos_uxkjqbd9lxhmrvfstr-...@mail.gmail.com
ions in
step A.6.3 of the vote tallying, leaving FD the only undropped otpion
in A.6.4, and hence the winner)
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@l
On 20 January 2014 14:29, Russ Allbery wrote:
> Steve Langasek writes:
>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
>> For my part I think this is generally a good idea, but I have the
>> impression that at least Russ would be strongly opposed to thi
On 20 January 2014 14:29, Russ Allbery wrote:
> Steve Langasek writes:
>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
>>> I think (a) and (b) are pretty non-controversial. (c) and (d) are
>>> required if we want to deal with new GNOME stuff and anyt
On 17 January 2014 03:52, Ian Jackson wrote:
> What is Debian ? In one respect, Debian is an operating system. And
> of course in another respect Debian is a community.
> * Debian is a forum for cooperation and technical development.
> * Debian, as a piece of software, tries to be all things to
g myself that in an ideal world I'd
prefer the event model. upstart doesn't seem to implement that
sufficiently though at this point. Sigh, now I'm imagining an event
based init system written in haskell...)
Cheers,
aj
[0] http://upstart.ubuntu.com/cookbook/#restarting-jo
On 31 December 2013 12:55, Colin Watson wrote:
> The criticisms of Upstart's event model in the systemd position
> statement simply do not make sense to me. Events model how things
> actually happen in reality; dependencies are artificial constructions on
> top of them, and making them work requi
On 15 January 2014 20:36, Martin Pitt wrote:
> It's not realistic for a maintainer to continuously test three init
> systems;
It's not realistic for a maintainer to continuously test against 13
architectures (including three different kernel trees) either. So we
don't do that and instead let main
On Jan 5, 2014 10:40 AM, "Russ Allbery" wrote:
> Anthony Towns writes:
> > How hard would it be to write an external wrapper that converts the
> > systemd style socket activation to the SIGSTOP protocol (for upstart
> > invoking a systemd compatible daemon)?
On s
On Jan 5, 2014 2:39 AM, "Russ Allbery" wrote:
> I'm doubtful that either of us are going to convince the other on this
> point. I don't consider it comparable to the other examples you're
> citing, and I think it's inobvious that raise(SIGSTOP) is a good technical
> choice. Simple, yes, but that
uld/should/would manage.
Forced to make a choice, should Debian go for smoother/tighter
integration between apps, or more choice for users/sysadmins? I'd
expect Debian to choose the latter; though Ubuntu, Red Hat and
possibly Fedora might choose the former.
Cheers,
a "por que no los dos?" j
--
Anthony Towns
Not speaking for my employer...
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/cajs_lcuwkje-hxq85kj_11ov_3o0deknct6q86slkjf7oz0...@mail.gmail.com
Okay, let's see how replying to a mail on my phone while in flight mode
goes. Apologies in advance for formatting, quoting and vocabulary issues.
On Dec 31, 2013 4:48 AM, "Russ Allbery" wrote:
> 2. Impact of Multiple Init Systems
> Obviously, the ideal situation for project-wide integration and
013
> - the latest of these uploads breaks the installer, [...]
Isn't this a rationale for d-i to use the stable builds of syslinux
present in testing (or potentially testing-proposed-updates) rather
than unstable?
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-ctte
On Fri, Jul 13, 2012 at 12:41 PM, Ian Jackson
wrote:
> Anthony Towns writes ("Re: Draft GR for supermajority fix"):
> How about this. I have dropped your change to the at the end
> of the Standard Resolution Procedure.
Looks good to me.
Cheers,
aj
--
Anthony Towns
for this issue changed those to refer to a
supermajority requirement:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636783#10
Using the term "supermajority" consistently to refer to 3:1 etc but
not 1:1 seems like the clearer approach to me.
Cheers,
aj
--
Anthony Towns
--
uorum (and default option) to be used.
+ what the voting period is. It must also specify the default option to be
+ used, the quorum required, and any supermajority requirements.
B. Use of language and typography
Cheers,
aj
--
Anthony Towns
--
Anthony Towns
--
To UNSU
pecify the default option to be
+ used, the quorum required, and any supermajority requirements.
B. Use of language and typography
Cheers,
aj
--
Anthony Towns
--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? C
Hi,
I'm still getting duplicates of the -ctte lists via:
Received: from chiark.greenend.org.uk ([212.13.197.229])
by azure.erisian.com.au with esmtp (Exim 4.63 #1 (Debian))
id 1LLRLI-0008BV-QK
for ; Sat, 10 Jan 2009 10:04:45 +1000
Received: from liszt.debian.org ([82.195.7
Hi *,
So, as of today, it's been three years since I was appointed to the
technical ctte. To me, that seems about the right length to stay on the
committee -- anything you can't get done in three years doesn't seem
likely to get finished just by sticking around longer, and in a project
with hundre
On Fri, Oct 31, 2008 at 03:52:31PM +0100, Andreas Barth wrote:
> 1. Currently, the submitter claims that the bug is serious, the
> maintainer don't think so, and there is no decision by the release team
> yet. So the current state of the bug isn't serious, but important.
ie, the views (on serious
On Wed, Mar 12, 2008 at 10:38:16PM -0700, Steve Langasek wrote:
> On Thu, Mar 13, 2008 at 02:19:14PM +1000, Anthony Towns wrote:
> > On Tue, Mar 11, 2008 at 04:14:45PM -0700, Steve Langasek wrote:
> > > Because this is being done *in lieu of* merging the triggers branch, with
>
On Tue, Mar 11, 2008 at 04:14:45PM -0700, Steve Langasek wrote:
> Because this is being done *in lieu of* merging the triggers branch, with
> the result that the triggers branch becomes harder to merge afterwards.
The triggers branch is already difficult to merge because it has numerous
unrelated
On Tue, Dec 18, 2007 at 03:35:51PM +0100, Josip Rodin wrote:
> On Mon, Dec 17, 2007 at 07:51:18PM +0100, Martin Schulze wrote:
> > > I've asked DSA for server-status already, and mentioned the logs too,
> > > we'll see (they haven't replied yet).
> > Server status is configured on localhost.
> OK,
On Tue, Dec 18, 2007 at 12:24:21PM -0500, Noah Meyerhans wrote:
> This is done. Steffani now has interface eth0.64 with address 18.24.0.11
Hrm, if you had security.debian.org pointing at:
18.24.0.11
212.211.132.032
212.211.132.250
The rule9-prediction scripts says you get:
000.0
On Mon, Dec 17, 2007 at 12:07:04AM +0100, Josip Rodin wrote:
> FWIW, the last reading is:
> * villa 5.33 MB/s
> * lobos 4.92 MB/s
> * steffani 14.58 MB/s
The original was:
> * villa 4.29 MB/s
> * lobos 3.91 MB/s
> * steffani 14.86 MB/s
Interesting that it got somewhat more balanced.
For referenc
On Sun, Dec 16, 2007 at 06:28:39PM +1000, Anthony Towns wrote:
> Going back to steffani, that gives B = 14.86 MB/s - 3.53 MB/s = 11.33 MB/s,
> and we thus have:
> A = 10.59 MB/s
> B = 11.33 MB/s
> C + F = 1.14 MB/s
> D = 0MB/s (by assumption
On Sun, Dec 16, 2007 at 06:07:24PM +1000, Anthony Towns wrote:
> Ah, like that. Attached.
> $ ./rule9-prediction.py ftp.us.debian.org
No, really.
Cheers,
aj
#!/usr/bin/env python
import socket, sys
def ip2bits(ip):
return "".join(
[ "".join(
[ ("%d
On Sat, Dec 15, 2007 at 03:43:22PM +0100, Josip Rodin wrote:
> On Sat, Dec 15, 2007 at 03:38:01PM +0100, Josip Rodin wrote:
> > Steve pointed me to [...]
> BTW, if anyone reading has some time to do the math again (hi aj :)
Hrm. How do you generalise it?
...
Ah, like that. Attached.
$ ./rule9-p
On Sun, Dec 16, 2007 at 03:45:37AM +0100, Josip Rodin wrote:
> After around 11 hours, we've had:
> * villa 4.29 MB/s
> * lobos 3.91 MB/s
> * steffani 14.86 MB/s
The rule9 prediction was:
A: 000.000.000.000-127.255.255.255: steffani, villa, lobos
B: 128.000.000.000-191.255.255.255: steffani
C: 192
On Sat, Dec 08, 2007 at 10:09:37AM +0100, Peter Palfrader wrote:
> > [0] http://lists.debian.org/debian-ctte/2007/09/msg00049.html
> I'm a bit confused by this code or rather its result, mainly because it
> seems that on all the etch hosts I tried it the results are distributed
> (even if not even
On Fri, Dec 07, 2007 at 09:17:02PM +0100, Peter Palfrader wrote:
> We had servers that ended up with twice or three times the number of
> users than other servers in the rotation, and explaining it all away
> with "well, the network of the less loaded server simply must suck, so
> clients cannot st
On Fri, Dec 07, 2007 at 01:55:28AM -0800, Steve Langasek wrote:
> > I haven't seen any concrete reports we could pass on, or any indication
> > we're likely to come up with a better mechanism, though, which leaves us
> > as doing nothing by default.
> I've previously argued that there are at least
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
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
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
> maint
On Tue, Dec 04, 2007 at 07:52:10PM +, Ian Jackson wrote:
> Perhaps we have different ideas about the proper way for TC members to
> behave after our positions have become clear on the main question at
> hand, and the main substantive questions have been fully explored.
The substantive questio
On Sun, Dec 02, 2007 at 10:13:38PM +, Ian Jackson wrote:
> (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 c
On Sun, Dec 02, 2007 at 11:11:43PM -0800, Steve Langasek wrote:
> In what way are the reports that this has adversely affected Debian mirrors
> unsatisfactory?
Have there been any reports? I've only seen Josip's second hand comments:
] I'm told that this bug also broke round-robin DNS functiona
On Sun, Dec 02, 2007 at 09:49:54PM +, Ian Jackson wrote:
> Everyone (even AJ, it seems) agrees that glibc in sid and lenny should
> be changed immediately.
No, I have not seen any reason to overrule the maintainers in this
entire thread. I don't see how I could have indicated that any more
c
On Sun, Dec 02, 2007 at 10:00:31PM +, Ian Jackson wrote:
> Anthony Towns writes ("Re: Bug#441200: libconfig name clash"):
> > I can't see any record of anyone suggesting [libconfig1] though, and
> > I'd really hope that it wouldn't be accepted at NEW
Hey all,
No one on the ctte seems to have taken any interest in:
* #429671: exim4 username
* #436093: Please decide on the "ownership" of the developers reference
* #439006: tech-ctte: Efika and sony PS3 patches in linux-2.6
They're all requests for dispute resolution, though 429671 also
On Thu, Nov 29, 2007 at 08:15:47PM +, Ian Jackson wrote:
> So just to be clear, you conclude as I did that both packages should
> be required to select new names ?
Yes. I can't see any technical reason whatsoever not to do that.
> > If either maintainer *wants* to use a different package name
On Sun, Dec 02, 2007 at 02:37:43AM -0800, Don Armstrong wrote:
> > No it doesn't, it just requires not noticing an issue -- eg, by it
> > not being brought to the tech ctte's attention at all (most
> > decisions in Debian), or by the tech ctte missing it when it is
> > (429761, 439006), or by the t
On Fri, Nov 30, 2007 at 06:40:36PM -0800, Don Armstrong wrote:
> Deciding that an issue isn't important enough to make a decision
> requires making some sort of decision.
No it doesn't, it just requires not noticing an issue -- eg, by it not
being brought to the tech ctte's attention at all (most
On Sat, Dec 01, 2007 at 01:16:05PM -0800, Steve Langasek wrote:
> On Sat, Nov 17, 2007 at 11:20:22AM +1000, Anthony Towns wrote:
> > Given the discussion we've had it's clear we're not willing to consider
> > this RC, which means stable will remain with its exist
On Sat, Dec 01, 2007 at 06:19:00PM +, Ian Jackson wrote:
> Anthony Towns writes ("Re: mixmaster /etc/default/*"):
> > This is exactly the sort of thing I think we should simply ignore rather
> > than issue any sort of ruling on. It's simply not important enough
On Fri, Nov 30, 2007 at 06:53:57PM +, Ian Jackson wrote:
> Anthony Towns writes ("Re: Call for Votes (getaddrinfo)"):
> > Again, if we don't think this bug is severe enough to need to be fixed
> > in stable (and thus qualifies as RC), I don't think we shou
On Fri, Nov 30, 2007 at 07:38:00PM +, Ian Jackson wrote:
> Having read the bug report I don't think there is very much to be said
> in favour of the submitter's point of view.
This is exactly the sort of thing I think we should simply ignore rather
than issue any sort of ruling on. It's simply
On Thu, Nov 29, 2007 at 02:07:47PM +0200, Jari Aalto wrote:
> [BTS control messages were sent separately]
AFAICS that didn't actually happen...
> To ease the burden on the system administrator, such
> configurable values should not be placed directly in the script.
> !In
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
severity 438179 wishlist
thanks
On Tue, Nov 27, 2007 at 07:09:04PM +, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
> > severity 438179 serious
> Bug#438179: Please provide a way to override RFC3484
> Severity set to `serious' from `wishlist'
Josip, there's be
On Tue, Nov 27, 2007 at 09:25:02PM +, Ian Jackson wrote:
> [Option D:]
> (1) The existing libconfig in Debian may retain its name.
The maintainer of that package writes:
] Here's my argument(s). I'll try to keep it short:
]
] a) First come, first serve. I'm both the upstream author an
On Thu, Nov 15, 2007 at 07:16:17PM +, 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
> [ ] Choice F: Furthe
On Tue, Oct 02, 2007 at 10:37:42AM +0200, Florian Weimer wrote:
> * Anthony Towns:
> > Updating the proposed standard has not been tried.
> Just to give you an idea of the time scale involved: moving RFC 3484
> to HISTORIC (which is the most likely result, at least for the Rule 9
&g
On Mon, Oct 01, 2007 at 04:30:17PM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Re: getaddrinfo() behaviour"):
> > Limiting the TC's power to overrule a technical decision to only cases
> > where the TC believes that the wrong behaviour makes the package
> > unsuitable for release would eviscer
On Mon, Oct 01, 2007 at 10:44:48AM +0200, Andreas Barth wrote:
> * Anthony Towns ([EMAIL PROTECTED]) [071001 03:46]:
> > One of the rules for RCness is "in the package maintainer's opinion,
> > makes the package unsuitable for release". Not quite the same, but
>
On Fri, Sep 28, 2007 at 08:10:33PM +0200, Andreas Barth wrote:
> * Ian Jackson ([EMAIL PROTECTED]) [070928 17:48]:
> > Anthony Towns writes ("getaddrinfo() behaviour"):
> > > I'd be interested to see explanations of why this should be
> > > considered RC
On Fri, Sep 28, 2007 at 04:47:34PM +0100, Ian Jackson wrote:
> Since I did the backport for Ubuntu I'm probably the right person to
> prepare the update for etch (not that it's very hard).
For concreteness, thanks to Aurelien's original addition to gai.conf
before this was brought to the ctte, the
On Fri, Sep 28, 2007 at 05:12:57PM +, Pierre Habouzit wrote:
> This argument is pure crap and prevent anyone interested to post to
> the TC list. This has pissed me beyond repair on this problem, and I
> believe I wasn't the only one. IMHO, the TC isn't functional with a
> restricted mailing
On Fri, Sep 28, 2007 at 04:56:31PM +0100, Ian Jackson wrote:
> We have to decide whether we want to make the same change to etch.
> The main upside would be that the ftpmasters would once again be able
> to use round robin DNS for eg ftp.us.debian.org.
$ host ftp.us.debian.org
ftp.us.debian.org
So here's my understanding of where we're at.
First, fact finding. Everything here should be able to be agreed by
everyone.
getaddrinfo() is a new interface that replaces gethostbyname(). It
hasn't different semantics that are intended to make it superior
to gethostbyname() and other functions, b
On Sun, Sep 23, 2007 at 04:21:58AM -0700, Steve Langasek wrote:
> On Fri, Sep 21, 2007 at 01:07:49PM +1000, Anthony Towns wrote:
> > 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
&g
On Sun, Sep 23, 2007 at 04:00:44PM +0200, Florian Weimer wrote:
> * Clint Adams:
> > I have heard, though not confirmed first-hand, that modern
> > versions of FreeBSD, Windows, and Solaris do as well.
> FreeBSD 6.2-RELEASE doesn't do it. [...]
Code:
09:59 import socket
09:59 k = [ socket
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 on
Windows, Solaris, *BSD and glibc based systems in general, but not
on D
On Thu, Sep 20, 2007 at 07:01:50PM +0100, Ian Jackson wrote:
> There is apparently no counterproposal, so I hereby propose and call
> for a vote on the following resolution:
>
> -8<-
> 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
> by Debian systems, and we overrule the mainta
On Wed, Sep 19, 2007 at 04:52:35AM +1000, Anthony Towns wrote:
> Ah, that'll be because the ordering's simply rotating, rather than being
> random: so we're assuming from A > B,C,D > E and getting:
> ABCDE -> ABCDE
> BCDEA -> ABCDE
>
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
> On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote:
> > So if getaddrinfo() has always behaved in this way, I don't see a great
> > deal of justification in changing it. [...]
> glibc is the only i
On Tue, Sep 18, 2007 at 07:18:40PM +0100, Ian Jackson wrote:
> There are only three possibilities:
> (a) It is correct that the behaviour of applications (and hence of
> hosts) should be changed to comply with rule 9.
> (b) Application behaviour should not change; getaddrinfo should
> behav
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 simple, I propose:
> 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
>by Debian systems, and we overrule the maintain
On Tue, Sep 18, 2007 at 03:33:51PM +0100, Ian Jackson wrote:
> 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&#
On Thu, Sep 13, 2007 at 12:06:40AM +0100, Ian Jackson wrote:
> Does anyone have an answer to my point that application of rule 9
> changes the long-established meaning of existing DNS data ?
I'm not familiar with how getaddrinfo() has been implemented in the
past -- but I think it makes more sense
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.
Rule 9 seems perfectly well written, it just does something you
(reason
On Mon, Aug 06, 2007 at 10:35:30AM +0200, Andreas Barth wrote:
> * Anthony Towns ([EMAIL PROTECTED]) [070806 10:18]:
> > On Mon, Aug 06, 2007 at 09:16:23AM +0200, Andreas Barth wrote:
> > > 1. at the moment something is commited to CVS, the changes are already
> > > acti
On Mon, Aug 06, 2007 at 09:16:23AM +0200, Andreas Barth wrote:
> 1. at the moment something is commited to CVS, the changes are already
> active on the website;
That seems an important point to me -- if that's the case, then committing
is publishing, so changes simply shouldn't be committed until
On Fri, Jun 22, 2007 at 12:09:46AM +0100, Bdale Garbee wrote:
> The udeb structure was invented for debian-installer, and to date
> Debian has not supported the use of udebs for any other purpose.
(With ftpmaster hat: I would expect non d-i uses of udebs to be in a
different section of the archiv
#341839
> [ 2 ] Choice 3: Further discussion
> - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
This horse has bolted already.
] * Don't worry if md5sum from stdin adds a " -" after the md5sum. Should
] make debootstrap more usable o
On Thu, Mar 29, 2007 at 10:16:52AM -0600, Bdale Garbee wrote:
> - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> [ 2 ] Choice 1: ndiswrapper should move to contrib as per bugs #353277,
> #353278
> [ 1 ] Choice 2: ndiswrapper should remain in main despite bugs #353277,
On Thu, Mar 29, 2007 at 10:18:49AM -0600, Bdale Garbee wrote:
> - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
> [ 2 ] Choice 1: fluidsynth should move to contrib as per bug #385665
> [ 1 ] Choice 2: fluidsynth should remain in main despite bug #385665
> [ 3 ] Choice 3
1 - 100 of 183 matches
Mail list logo
