glibc's getaddrinfo() sort order
Hi, I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo() should sort the results or not. I think the current way it sorts things does not work at all in IPv4, and I think it hurts more than it does good. I'm seeking input from the tech-ctte on how to handle this. Kurt signature.asc Description: Digital signature
Re: glibc's getaddrinfo() sort order
On Fri, Sep 07, 2007 at 06:54:21PM +1000, Anthony Towns wrote: > OTOH, getaddrinfo is meant to give a "close" answer, and doing prefix > matching on NATed addresses isn't the Right Thing. For IPv6, that's fine > because it's handled by earlier scoping rules. For NATed IPv4 though the > prefix we should be using is whatever the host is going to be NATed *to*. > And that would imply that the Right Thing would be to have an option > more like: > > pretend-that 10/8 is-really 1.2.3.4/32 > > That doesn't seem likely to work though because it requires extra > manual configuration, which won't happen. > > Giving up on actually getting getaddrinfo to give "close" answers for > NATed boxes leaves the option of trying to avoid getaddrinfo going out > of its way to give "far" answers instead, which would mean turning off > prefix-matching for NATed boxes; which could be done by ignoring rule > 9 by default for private IPv4 addresses. The problem with IPv4 is not only about NAT. It just happens to show the problem better. With the IPv6 allocation policies, it's likely that the more higher bits match, the closer it is network wise. It is rather unlikly in the IPv4 case, specially if you go above /16. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc's getaddrinfo() sort order
On Fri, Sep 07, 2007 at 12:34:10AM +0200, Pierre Habouzit wrote: > the Ctte may want to read: > - http://udrepper.livejournal.com/16116.html > - http://people.redhat.com/drepper/linux-rfc3484.html The first one makes a point to which I party agree, but also disagree. 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. In the case the server has 2 addresses assigned, I doubt that you're going to advertise the local one outside. So you're atleast have a different response for an internal and external query. I don't see why the interal query should also return the external address. I already suggested that maybe rule 9 should be limited to the common prefix length of the netmask you're using. An other option is that you extend rule 2 to have the same behaviour with ipv4, and that 10/8, 172.16/12 and 192.168/16 should be considered organization-local. Ulrich Drepper actually called site-local in the second document, but I think organization-local would be the right "scope" for it. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc's getaddrinfo() sort order
On Wed, Sep 19, 2007 at 03:03:51AM +1000, Anthony Towns wrote: > > > > Heedless of the effect on the DNS round-robin functionality I describe > > above, the authors of RFC3484 specified (s6 rule 9) that all addresses > > should be sorted by "proximity" to the host making the choice - where > > "proximity" is defined as the length of the common initial address > > prefix. > > 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() at least wrt round-robin DNS; but I've got no way of > verifying that. glibc is the only implementation I know of that does this. I've attached a small test program. The results are: sarge: libc6 2.3.2.ds1-22sarge5: random order etch: libc6 2.3.6.ds1-13etch2: ordered results On other implementations I'm aware of is in libbind. You'll need to run configure with the --enable-libbind for that. It doesn't reorder it. I don't know of any of the other libcs in debian actually provide getaddrinfo(), but I doubt they'll reorder. There are also lots of applications that have a wrapper around gethostbyname() in case the libc doesn't provide it. It's highly unlikely any of those will do any reordering. > > This may have been a disputed but arguable definition of real network > > proximity for IPv6 in at the time 3484 was written. But it is clear > > now that it is not such a measure in the real IPv6 internet, and it > > has never been such a measure in the IPv4 internet. > > I hadn't seen any indication it was disputed for IPv6 prior to your mail. > The patch in glibc only affected IPv4 addresses, for that matter. I've also stated that it might not work properly for IPv6. It's likely that something in the same /32 is close network wise, it's even more likely for /48 and /64, but you probably don't want to go below the /32. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: glibc's getaddrinfo() sort order
On Tue, Sep 18, 2007 at 08:41:45PM +0200, Kurt Roeckx wrote:
> I've attached a small test program. The results are:
> sarge: libc6 2.3.2.ds1-22sarge5: random order
> etch: libc6 2.3.6.ds1-13etch2: ordered results
Maybe I should attach it.
Kurt
#include
#include
#include
#include
#include
int main()
{
struct addrinfo *res, *p, hints;
hints.ai_flags = 0;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
hints.ai_protocol = 0;
hints.ai_addrlen = 0;
hints.ai_addr = NULL;
hints.ai_canonname = NULL;
hints.ai_next = NULL;
getaddrinfo("0.pool.ntp.org", "ntp", &hints, &res);
for (p = res; p; p = p->ai_next)
{
if (p->ai_family == AF_INET)
{
char ip[INET_ADDRSTRLEN];
if (inet_ntop(p->ai_family,
&(*(struct sockaddr_in *)p->ai_addr).sin_addr,
ip, sizeof(ip)) != NULL)
{
printf("%s\n", ip);
}
}
}
freeaddrinfo(res);
return 0;
}
Re: glibc's getaddrinfo() sort order
On Mon, Sep 24, 2007 at 11:23:19AM +1000, Anthony Towns wrote: > FreeBSD 6.2, Jan 2007: stable, but not rule 9 > Fedora Core 5, March 2005: stable > Ubuntu 7.04, April 2007: rule 9 > Debian 3.1, sarge (June 2005): not stable > OS X 10.4 Tiger (April 2005): not stable > Windows 2003: stable, but not rule 9 So, to sum this up, we have 3 types: 1: stable, rule 9 2: not stable 3: stable, but not rule 9 So far, all those we know about that implment rule 9 are based on glibc. We've seen that FreeBSD is reported both as 2 and 3. I think it's higly likely that all those OSs reported as 3 are behind a caching nameserver that doesn't rotate and are really type 2. It would be nice if we could collect information about other OSs too. But I don't think it's really relevant. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: A comment about RFC 3484 address selection]
> Date: Mon, 24 Sep 2007 17:48:06 +0200 > From: Juliusz Chroboczek <[EMAIL PROTECTED]> > To: Steve Langasek <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED], Clint Adams <[EMAIL PROTECTED]> > Subject: Re: A comment about RFC 3484 address selection > > > FWIW, I believe non-subscriber posts are accepted to the list if they're > > sent by way of the BTS. As far as I know, if you're not subscribed you should sign your message. > Let's see how it goes. > > >> > RFC 3484 clarifies that the list of addresses returned by getaddrinfo > >> > is in an order that takes into account both the server's and local > >> > preferences. > > > no, the software authors cannot expect to rely on addresses to be > > sorted in any particular order; > > Software authors can expect that the list is in an arbitrary order > that reflects the local address selection policies. There are 2 ways to look at this. One is from the point of people writing an application that connects to some server. The other is from people running the servers. There are dns server implementations that rotates the list of A-records, so that the load gets distributed over the servers. People setting up that software know that, and rely on the behaviour. They expect the client software to select a semi random IP address. What client software might want to do is connect to the one that is network-wise the closest. The RFC defines a few rules for that and basicly suggest an order in which you should prefer one over the other. You should be able to change the order of those rules based on local policies. And then says that if all those rules are applied, you shouldn't change the order anymore. The reason it says it shouldn't sort anymore is probably because of the behaviour of the rotating dns server. If you don't know which to prefer, a semi random one is better then everyone connecting to the same. What rule 9 does is try to "guess" which of the destination addresses might be closer network wise. And it's doing a very poor job in alot of cases. What it does seem to be good at however is breaking the expectations of the dns server administrators. When implemented, the dns servers can even give a much better guess on what might be network-wise closer based on the IP address of the client sending the query. > But that is not my point. If, like many people, you believe that > another semantics is useful, please do not pull an OpenBSD. Stick to > the standard semantics for the standard interface, and define a new > interface for the semantics you find useful. Someone still needs to explain me why rule 9 _might_ be useful in the real world (for IPv4). The only argument I'm seeing is "that's what the standard says". I don't find that a very good argument, specially if that standard says that if you know better, you shouldn't implement it. What I really want to know is what do we break by not following it. Is there any application that depends on this behaviour? Like you say yourself, the order might be based on the local policies, so I think anything that relies on this behaviour is broken. > > RFC 3484 is not a standard. > > I'm not sure you are familiar with IETF terminology. 3484 is > a Proposed Standard. So is 2464 (IPv6 over Ethernet). Even if rfc 2464 isn't a standard yet, you can already consider it a de facto standard, which you can't say about rfc 3484. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A comment about RFC 3484 address selection
On Tue, Sep 25, 2007 at 03:21:09AM +0200, Kurt Roeckx wrote: > > There are 2 ways to look at this. One is from the point of people > writing an application that connects to some server. The other is from > people running the servers. > > There are dns server implementations that rotates the list of A-records, > so that the load gets distributed over the servers. People setting up > that software know that, and rely on the behaviour. They expect > the client software to select a semi random IP address. Nobody seems to have explained the different cases yet someone might want to add several addresses to a hostname. So I'm going to try and sum up what I think are the use cases for it, and how rule 9 affects it. - You might want to set up several servers in the same network segment, and all your clients are in the same segment too. For instance you add 1.0.0.2 and 1.0.0.3. All clients are in 1.0.0.0/24. In this case, there is no need for rule 9. It might result in clients prefering one over another in some cases, but it's probably not harmful. - A simular case is that you have 2 segments, 1.0.0.0/24 and 1.0.1.0/24, and you add a 1.0.0.2 and 1.0.1.2. Now you want clients to connect to the one from it's own segment, and fall back to the other if it fails. In this case rule 9 might be useful. But I would rather see that this fall under rule 2 and/or 8, and that such address would be considered one with a site-local scope. It could potentially also fall under rule 4. It's also something that can perfectly be configured in the policy. - You might want to have several server in the same network segment but have your clients in an other network segment. For instance the servers are in 1.0.0.0/24 and the clients in 1.0.1.0/24. In this case rule 9 is not going to have any effect. - Another example is that the servers are provided by different people, and they're spread over the internet. There generally is no relation between the clients and the servers. This is the case were we have a problem with rule 9. It tries to guess which network might be closer, and the guess doesn't really make sense in alot of cases. - A last case is that you set it up with global and a private (site-local) address. This is already covered by rule 2 and rule 8. I think in general setting things up that way doesn't make much sense. So my conclusion is that rule 9 as it is now is only useful in 1 case, and that in that case either one of the other rules should be used instead, or the local policy modified. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
On Fri, Sep 28, 2007 at 06:23:06PM +, Pierre Habouzit wrote: > DNS RR is "broken" on Windows XP since SP2, Windows Vista, most *BSDs, > Redhat and Fedora, and probably any Linux distribution out there I've just tested XP SP2 myself in various ways. I've tried things like internet explorer, ping, Anthony's python script under cygwin. They all fall under the "not stable", and use a different IP each time. I let someone test it on Vista, and that does follow rule 9, making it 2 implementations I know of that actually do it. I haven't seen anybody claim that any of the *BSDs implemented rule 9 that also says he tested it, I've only seen reported of FreeBSD saying it didn't. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
On Sat, Sep 29, 2007 at 11:56:35AM +0200, Wolf Wiegand wrote: > Hi, > > Kurt Roeckx wrote: > > > I haven't seen anybody claim that any of the *BSDs implemented rule 9 > > that also says he tested it, I've only seen reported of FreeBSD saying > > it didn't. > > I just tested this: > > ~/> uname -sr > FreeBSD 6.2-STABLE > ~/> ping -c 1 ftp.us.debian.org | grep PING > PING ftp.us.debian.org (204.152.191.7): 56 data bytes > ~/> ping -c 1 ftp.us.debian.org | grep PING > PING ftp.us.debian.org (35.9.37.225): 56 data bytes I don't know about ping on FreeBSD, but atleast on Debian, ping does not use getaddrinfo(). Please use one of the test programs that were send on the list that actually do use getaddrinfo(). Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
On Sat, Sep 29, 2007 at 02:07:02PM +0200, Wolf Wiegand wrote:
>
> The machine I have access to doesn't support ahosts. getent host
> returns different addresses for ftp.us.debian.org on subsequent calls.
Please either try this python script:
import socket
k = [ socket.getaddrinfo("rule9.erisian.com.au", "http")[0][4][0] for blah in
range(1000) ]
print dict([ (l, k.count(l)) for l in k ])
Or compile the attached C file and run it multiple times.
Kurt
#include
#include
#include
#include
#include
int main()
{
struct addrinfo *res, *p, hints;
hints.ai_flags = 0;
hints.ai_family = PF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
hints.ai_protocol = 0;
hints.ai_addrlen = 0;
hints.ai_addr = NULL;
hints.ai_canonname = NULL;
hints.ai_next = NULL;
getaddrinfo("0.pool.ntp.org", "ntp", &hints, &res);
for (p = res; p; p = p->ai_next)
{
if (p->ai_family == AF_INET)
{
char ip[INET_ADDRSTRLEN];
if (inet_ntop(p->ai_family,
&(*(struct sockaddr_in *)p->ai_addr).sin_addr,
ip, sizeof(ip)) != NULL)
{
printf("%s\n", ip);
}
}
}
freeaddrinfo(res);
return 0;
}
Re: A comment about RFC 3484 address selection
On Sun, Sep 30, 2007 at 09:07:16PM +0200, Florian Weimer wrote: > * Kurt Roeckx: > > > - A simular case is that you have 2 segments, 1.0.0.0/24 and 1.0.1.0/24, > > and you add a 1.0.0.2 and 1.0.1.2. Now you want clients to connect > > to the one from it's own segment, and fall back to the other if it > > fails. > > > > In this case rule 9 might be useful. But I would rather see that this > > fall under rule 2 and/or 8, and that such address would be considered > > one with a site-local scope. It could potentially also fall under > > rule 4. It's also something that can perfectly be configured in the > > policy. > > Scope is not defined for IPv4 addresses (neither in RFC 3484 or > elsewhere), so Rule 2 and Rule 8 do not apply in this case. rfc3484 section 3.2 has: IPv4 addresses are assigned scopes as follows. IPv4 auto- configuration addresses [9], which have the prefix 169.254/16, are assigned link-local scope. IPv4 private addresses [12], which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-local scope. IPv4 loopback addresses [12, section 4.2.2.11], which have the prefix 127/8, are assigned link-local scope (analogously to the treatment of the IPv6 loopback address [11, section 4]). Other IPv4 addresses are assigned global scope. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (was Re: glibc's getaddrinfo() sort order)
On Thu, Nov 15, 2007 at 07:16:17PM +, Ian Jackson wrote: > > (I'm resending this lost mail from the 8th of November, intending to > restart the 7-day clock:) It seems the 7 day clock has stopped again a few days ago. We actually saw a total of 1 votes for this ballot, and 2 for one with an additional option. We seem to have: X S M F Ian 1 3 X 2 aj - - 1 2 Manoj 1 3 3 2 As far as I know, we have a quorum of 2. Option X seems to reach quorum with 2 >= 2. Option S and M don't reach quorum. Option X has a majority ratio of 2:1, which is smaller than the required 3:1. I think either way you look at it, we ended up with option F "Further discussion" > It seems that discussion on this has dried up. Although my very > similar proposal was defeated the first time, I think it probably by > now falls to me by default to propose a new version. So: I just wonder why so few people seem to have voted. Is there still a problem with the lists? Kurt > -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<- > > For the sake of clarity, we should at least have the libc maintainer's > position on the ballot, so I propose and call for a vote. > > -=-=-=-=-=- 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: Further discussion > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > I've left off `do not use rule 9, do not overrule maintainer' as a > choice as no-one seemed to be arguing for it. > > -8<- > > Here is my vote and my opinion: > > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > [1] Choice X: Do not use rule 9, overrule maintainer, etc., as above. > [2] Choice F: Further discussion > [3] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo > -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > 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 operatin
Re: Bug#412976 repoened - reassign tech-ctte (mixmaster /etc/default/*)
On Sun, Dec 02, 2007 at 10:10:38PM +, Ian Jackson wrote:
> Florian Weimer writes ("Re: Bug#412976 repoened - reassign tech-ctte
> (mixmaster /etc/default/*)"):
> > Really? Won't upgrades re-enable disabled services if update-rc.d is
> > used?
>
> Only if you delete _all_ of the links. If you leave the K links in
> the shutdown and reboot runlevels, they will not be put back.
>
> This ought to be documented somewhere ...
It is documented in the update-rc.d manpage:
If any files /etc/rcrunlevel.d/[SK]??name already exist then update-
rc.d does nothing. The program was written this way so that it will
never change an existing configuration, which may have been customized
by the system administrator. The program will only install links if
none are present, i.e., if it appears that the service has never been
installed before.
Kurt
--
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 (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]
Bug#438179: RFC3484 rule 9 active again in glibc 2.7-5.
For those that didn't notice this yet, 2.7-5 reverted the change of 2.7-4. So testing and unstable uses rule 9 again. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Functionality of the committee, and maintainership disputes
On Sun, Mar 09, 2008 at 12:17:18PM +, Ian Jackson wrote: > Firstly, I think the committee is not doing its job. I've been very > frustrated with the lack of progress. I think we need to fix this. > I'm all ears for suggestions but I think more is needed than promises > to try harder. One possibility would be a radical expansion (to up > to 15, perhaps), which with a sqrt(N) quorum would leave a quorum of > 3. The constitution has: 1. The Technical Committee consists of up to 8 Developers, and should usually have at least 4 members. So you'll atleast need to change the constitution for that. It also says that the quorum is always 2. Using the quorum rules as used for DDs, with 15 you would get a quorum of 1.93. (Sqrt(15)/2). I'm also not conviced that adding more people will actually solve anything. > So I would suggest that the Constitution should be amended to say that > a TC member may not vote (other than a casting vote) on whether or not > they are the maintainer of some package. And of course we should all > pretend that that is what it says. You could agrue that it's one of the potential maintainers and that both can be overriden and so would be implied. But it's not clearly spelled out. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: foo2zjs dispute
On Tue, Oct 28, 2008 at 02:41:41PM +0100, Giacomo A. Catenazzi wrote: > The "contrib" section includes (historically) also the reduced > quality package, so the uninstability of a contrib package could > be temporary accepted. contrib already contains such packages as b43-fwcutter, which look very simular to me. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New Technical Committee Members
On Sun, Jan 11, 2009 at 11:57:31AM -0700, Bdale Garbee wrote: > Anthony Towns recently announced his decision to step down from > the Debian Technical Committee: > > http://lists.debian.org/debian-ctte/2009/01/msg6.html > > I thank him on behalf of the rest of the committee and the > project for his contributions over the last three years! > > With this change, the remaining members of the committee are: > > chairman Bdale Garbee > member Andreas Barth > member Ian Jackson > member Steve Langasek > member Manoj Srivastava > > As per Constitution section 6.2, we discussed a number of > potential additions to the committee, with the full engagement > and support of Debian Project Leader Steve McIntyre. > > It gives me great pleasure to welcome Russ Allbery and Don > Armstrong as the newest members of the Technical Committee. If I understand things right, you can add new members until the number reaches 6 and can then proposed new members to the DPL. And Steve organised the vote to add Russ (which got approved), and propose Don to the DPL. Andreas said that with 3 of the 5 votes for proposing Don the vote is over. But I think it's only 3 of 6 at that point, and the DPL still needs to approve it. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fwd: Bug#422139: git #422139 - summary for the Techical Committee
All policy seems to have to say about this is: Packages that include daemons for system services should place scripts in `/etc/init.d' to start or stop services at boot time or during a change of runlevel. These scripts should be named `/etc/init.d/' It's only a should and not a must. But it has also been pointed out that this is what administrators expect. And I see no good reason not to provide that interface to our users. Only providing the runit version seems to cause more problems for the users that are not familiar with it. It could even be argued that if you provided an init.d script you would have less bug reports. I would recommend putting the init script in the same binary package as the daemon itself. Having it in an other package will most likely result in the service being stopped and not started again on upgrades. And I don't think having a new source package just to provide an init script is a good idea Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#422139: Please supply a sysvinit script
On Wed, Jan 21, 2009 at 01:13:17PM -0800, Russ Allbery wrote: > First off, I disagree with the initial bug that opened this report and > agree with Gerrit's response. The purpose of the git-daemon-run package > is to provide a runit interface for git-daemon; asking that it not use > runit is missing the point of the package. > > I think there is a normal-severity bug in the git-daemon-run package in > that the long description doesn't clearly state that it uses runit, and > that might be surprising to some users, but I don't think any action is > needed on that package other than changing the long description to more > clearly note that it uses runit. > > It seems like the remaining issue is whether the git-daemon package should > also provide an init script via some mechanism for people who don't want > to use runit. If one does so, one has to be careful to not have both a > runit configuration and an init script active at the same time, so it's > not an entirely trivial exercise. The suggestion of providing a different > package would work, but I agree that it's not ideal; that package would be > extremely small and Policy recommends that init scripts be used as the > default daemon management mechanism. I have to agree with all this, and it basicly seems to be about supporting users who don't want to use runit. > runit, for runit-aware services and when the system administrator is > familiar with the system, offers substantial features above what's > available from the init system. It provides some capabilities similar to > what upstart provides, including service monitoring, automatic restart, > and a better-defined interface for controlling the service that doesn't > require anywhere near as much fiddling as getting start-stop-daemon > working properly with the right output. So I can certainly understand why > Gerrit wants a runit-managed git-daemon and doesn't want to mess with a > traditional init script. > > Were this my package, I think what I'd do is offer an init script that > automatically switches to using runit if git-daemon-run is installed, > detecting that in some reasonable fashion. I can understand Gerrit's lack > of enthusiasm for writing that script and maintaining it, though. But if > someone else contributes it, it's fairly simple and straightforward, and > it doesn't break git-daemon-run, maybe he'd be willing to consider it? An alternative would be that git-core would contain the files that git-daemon-run has now and a normal init.d script, and that if you install runit it would use the runit way of running things and else use the sysvinit way. It now seems to have an executable file in /etc/init.d that can only report the status, and only after it has run atleast once. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#422139: Please supply a sysvinit script
On Tue, Feb 03, 2009 at 08:34:45AM +, Gerrit Pape wrote: > > A separate binary package named git-daemon-sysv or so, that conflicts > and provides git-daemon-run, is the way I'd do the integration. Why should it provide git-daemon-run? In my experience, having the init script in a different binary package than the daemon causes problems on upgrade. Mostly that the daemon isn't running aymore after an upgrade. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Thu, Aug 20, 2009 at 09:00:47PM -0700, Don Armstrong wrote: > > I'm calling for a vote on the following options[1]: > > | 1. Qmail is to be allowed into the archive without special > | preconditions. Ftpmaster should perform standard NEW processing for > | licensing, copyright, and general packaging issues as normal. > | > | Qmail is subject to the normal removal process for packages. > | > | 2. Qmail is to be allowed into the archive without special > | preconditions, save the RC bug indicated below. Ftpmaster should > | perform standard NEW processing for licensing, copyright, and general > | packaging issues as normal. with the addition of an RC bug filed > | immediately to preventing normal transition for a period of at least a > | month after traversing NEW. > | > | During this period, additional RC (or non-RC) bugs should be filed by > | interested parties, and updated qmail packages fixing these bugs > | should be uploaded as usual. After a month, the RM or the maintainer > | can continue to decide that the package is not acceptable for release > | at their discretion, as happens for any package. [If the RM or > | maintainer don't reaffirm the transition blocking bug, the ctte will > | close the transition blocking bug.] > | > | Qmail is subject to the normal removal process for packages. > | > | 3. Qmail is to be allowed in to the archive after a patch to resolve > | the delayed bounces issue, where mail sent to an invalid recipient > | which a reasonable MTA is capable of knowing is invalid is accepted > | instead of being rejected at RCPT TO time. After upload, the process > | outlined in option #2 will take effect. > | > | 4. Qmail is not to be allowed into Debian. > | > | 5. Further discussion. We have 6 of the 7 votes now: 32145 rra 32145 don 31245 srivasta 53421 vorlon 34215 aba 12354 bdale Note that the constitution has a 1 week voting period for this. Bdale's mail is about 1 week and 1 day after don's CfV, but couting it or not doesn't seem to make any difference. This seems to fall under constitution 6.1.3, and so has a normal 1:1 majority requirement. There is a quorum of 2, all option reach quorum. All option also reach the 1:1 majority requirement. I think it's clear that option 3 wins. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools
On Tue, Sep 01, 2009 at 09:40:31PM -0700, Steve Langasek wrote: > I'm calling for votes on this issue. The ballot options are given as short > summaries of the resolutions; please see the provided links for the full > text of the resolutions. > > 1. Decline to override the ftp team decision to remove ia32-libs-tools > Message-ID: <20090823065342.ga14...@dario.dodds.net> > http://lists.debian.org/debian-ctte/2009/08/msg00079.html > > 2. Require the ftp team to reinstate ia32-libs-tools, or provide more > information > Message-ID: <1251227318.5849.738.ca...@rover> > http://lists.debian.org/debian-ctte/2009/08/msg00096.html > > 3. Further Discussion I haven't really been following this, but I don't think the ctte has the power to override a delegate, and last I heard ftp-master was a delegation. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools
On Wed, Sep 02, 2009 at 09:32:20AM -0700, Don Armstrong wrote: > On Wed, 02 Sep 2009, Kurt Roeckx wrote: > > I haven't really been following this, but I don't think the ctte has > > the power to override a delegate, and last I heard ftp-master was a > > delegation. > > My reading that it does, but only in the case where a delegate is > implementing a technical policy or decision. I wasn't sure that allowing a package in the archive is a "technical policy". But you do have technical reasons why you don't want it. And you can argue that it doesn't meet the "must not be so buggy that we refuse to support it" part that allows it in the archive. I guess my problem is that the wording seems to indicate this is under 6.1.4, while you think this is under 6.1.1. > 6.1.1 empowers the CTTE to make any technical decision, but 6.1.4 > modifies that to require a 3:1 majority when the decision has already > been made. Furthermore, if 6.1.4 doesn't apply to technical decisions > of a delegate, than only 6.1.1 applies, and only a simple majority is > needed. > > For example, the policy editors are currently delegated, but 6.1.1 > speaks specifically to policy. In a case where we were going to > override the policy editors, I think 6.1.4 and 6.1.1 should both > apply, but I'm certain that 6.1.1 does. As I understand it, policy is not made by the delegates, it's DDs that make proposals and approve it, and the delegates are just there to help the process. But I think 6.1.1 and 6.1.4 are different things, and 6.1.4 does not extend/modify 6.1.1. Changes to policy would fall under 6.1.1 and not 6.1.4. But I guess this is getting a little off topic for here, and is something we'll deal with when that happens. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#587886: future of maintaining of the bootloader LILO
On Tue, Nov 30, 2010 at 12:20:55PM +, Ian Jackson wrote:
> Ian Jackson writes ("Bug#587886: future of maintaining of the bootloader
> LILO"):
> > No, I don't think so. There's nothing more to be said.
> >
> > > [for reference:
> > >
> > > A. lilo should be removed. In the meantime, William is to be sole
> > > maintainer of lilo. His promised request to the ftp team to
> > > remove lilo should be honoured, after which the ftp masters should
> > > not permit Matt and/or Joachim to reupload a new lilo package.
> > >
> > > B. lilo should be retained in unstable. Matt and Joachim are to be
> > > joint maintainers of lilo.
> ...
> > I vote:
>
> I'm changing my vote as follows:
>
>1: B
>2: A
>3: SQ
I'd like to point out that neither of your votes are signed.
Kurt
--
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/20101130175200.ga10...@roeckx.be
Re: Bug#636783: proposed constitution fix for super-majority within the tech ctte
On Sat, Aug 27, 2011 at 05:43:30PM +0100, Ian Jackson wrote: > * Possibly increasing the maximum size of the committee. I would be > happy with 12, given the busy nature of the existing members. I assume you want to do that without changing the minimum size (4) or quorum (2)? If you change the amount of people in the team, do you still think it's needed to change it from "strictly greater" to "greater than or equal"? Kurt -- 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/20110827180928.ga31...@roeckx.be
Re: Bug#640874: leave: debian/rules is not a Makefile
On Thu, Apr 05, 2012 at 04:16:32PM -0700, Russ Allbery wrote: > Russ Allbery writes: > > > Based on Ian's last response, I think the ballot has two options plus > > further discussion, since I'm quite sure that we're not going to outlaw > > dh: > > > A. debian/rules is not required to be a makefile, only to implement the > >same interface as a debian/rules file implemented as a makefile > >(including handling of arguments and exit status). Debian Policy > >should be updated to change the requirement to a recommendation, and > >new versions of the leave package should be permitted to be uploaded to > >the archive without changing debian/rules to be a makefile. > > > B. The Technical Committee affirms the Debian Policy requirement that > >debian/rules must be a makefile. All packages in the archive, > >including leave, are required to follow this requirement. This > >makefile may, as is common practice, delegate implementation of its > >targets to a script. > > > C. Further discussion. > > At the conclusion of our standard voting period of one week, there were > three votes of BAC and one vote of AB. (One additional vote of BAC came > in after the voting period had ended.) > > As this is, depending on how one looks at it, a conflict between a > maintainer and ftp-master policy or a maintainer and the current > requirements of Debian Policy, I don't believe the 3:1 super-majority > requirement applies here and the ballot should be decided by simple > majority rule. Both text clearly talk about policy, and not about overriding ftp-master. Overriding ftp-master would be overriding a delegate of the DPL, and I don't think you have that power to begin with. B isn't overriding anything, so clearly doesn't need a 3:1 majority requirement, and can win with a simple majority. Kurt -- 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/20120406171030.ga13...@roeckx.be
Re: Bug#640874: leave: debian/rules is not a Makefile
On Fri, Apr 06, 2012 at 12:07:38PM -0700, Steve Langasek wrote: > On Fri, Apr 06, 2012 at 07:10:30PM +0200, Kurt Roeckx wrote: > > > At the conclusion of our standard voting period of one week, there were > > > three votes of BAC and one vote of AB. (One additional vote of BAC came > > > in after the voting period had ended.) > > > > As this is, depending on how one looks at it, a conflict between a > > > maintainer and ftp-master policy or a maintainer and the current > > > requirements of Debian Policy, I don't believe the 3:1 super-majority > > > requirement applies here and the ballot should be decided by simple > > > majority rule. > > > Both text clearly talk about policy, and not about overriding > > ftp-master. Overriding ftp-master would be overriding a delegate > > of the DPL, and I don't think you have that power to begin with. > > This is a surprising claim, but upon review, I see that the constitution > states only that the TC may overrule Developers, not Delegates, and a strict > constructionist reading of the constitution would support the idea that a > Developer, when acting as a Delegate, can not be overruled by the TC. > > I think this is a bug in the wording of the constitution however, and not a > position that is supported by historical practice. I'm fairly certain that > this is not what our DPLs expected when expanding the scope of delegated > roles within the project. > > Perhaps Ian would like to chime in here wearing his "I wrote the > constitution" hat. :) I've been wondering how to interprete that for some time. My current idea is that it would require a GR to do that. Kurt -- 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/20120407110001.ga4...@roeckx.be
Re: Technical Committee proposed GRs
On Thu, May 31, 2012 at 07:56:47PM +0100, Ian Jackson wrote: > It looks like the TC are going to be proposing some GRs within the > next few months. Very likely there will be three: > > - Constitutional change to fix the supermajority bug > - Constitutional change to permit the TC to have private discussion > - Position statement regarding when TC should overrule maintainers > > I'm emailing you to give you a heads-up and get your opinion about > procedure. > > These are all independent issues and we think they should be discussed > and voted on concurrently, but voted on separately. How should this > be done ? As three concurrent but entirely separate GRs ? I don't > know whether your GR processes can do a single GR proposal with > multiple sub-ballots each with their own set of options, so that each > sub-ballot can be separately accepted or rejected. As far as I know the only option is to actually start 3 votes at th same time, and have a ballot for each of them, and so have people send it to a a different address. > Also, the constitution gives the proposer the power to accept > amendments. If a GR was initiated by the TC, who has the power to > accept amendments ? I don't see the TC having a power to propose a GR. Kurt -- 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/20120531201957.ga13...@roeckx.be
Re: Technical Committee proposed GRs
On Thu, May 31, 2012 at 07:56:47PM +0100, Ian Jackson wrote: > > Also, the constitution gives the proposer the power to accept > amendments. If a GR was initiated by the TC, who has the power to > accept amendments ? Is it just the TC as a whole by its own > resolutions (which would be rather cumbersome) ? Or is it the > TC member who proposed the TC resolution which started the GR ? I think that if you as TC propose a resolution (that you voted on), the TC is the proposer, not the member, and that the TC as a whole needs to accept the amendments, and so have a vote to accept it or not. But I do see why you would like to avoid that. To avoid that, you can just propose this as an individual, I see no reason why you would need to do this as the TC. > I'm hoping that you'll say that it's just the TC as a whole but that > the TC can delegate that power. I don't see anything giving the TC the power to delegate anything, while I do see it for the project leader and the secretary. So if you want to do this, I will have to think about this some more. > If so, the TC's own resolution > starting the GR can contain something like this: > >For the purposes of accepting or rejecting amendments to this GR >proposal, according to Constitution A.1(2), we delegate to >the power to accept amendments, and to each of our other members >the power to veto the acceptance of amendments (as if each TC >member was a sponsor). The Committee reserves the right to >overrule, by means of a TC resolution on whether to accept an >amendment. I think something like that might make sense for an addition in the constitution. But I'm personally having doubts about this veto power. Kurt -- 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/20120531213004.ga14...@roeckx.be
Re: Technical Committee proposed GRs
On Thu, May 31, 2012 at 01:43:51PM -0700, Don Armstrong wrote: > On Thu, 31 May 2012, Kurt Roeckx wrote: > > On Thu, May 31, 2012 at 07:56:47PM +0100, Ian Jackson wrote: > > > Also, the constitution gives the proposer the power to accept > > > amendments. If a GR was initiated by the TC, who has the power to > > > accept amendments ? > > > > I don't see the TC having a power to propose a GR. > > The TC has the power under §4.2.1; it probably should also be listed > under §6.1 too. So as the TC you can propose something to be voted on without needing seconds, while as individuals you can just propose it and have the members of the TC sponsor it. Kurt -- 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/20120531214204.ga15...@roeckx.be
Re: Number typo in the Constitution
On Thu, Jun 07, 2012 at 11:56:35AM -0400, David Prévot wrote: > Hi Secretary, Technical Committee, > > Stéphane, in the d-l10n-french list, spotted a number issue in the > constitution, A.1 being present twice: > A.1. Proposal > A.1. Discussion and Amendment This was already mentioned in #367787. As far as I can see nothing points to A.1, but things do point to A.6, so changing everything 1 higher does not seem like something you want to do. > If this tiny issue can't be solved directly without a constitutional > amendment vote (our secretary will confirm), maybe the Technical > Committee will be willing to include this fix (renumbering the A.# > stuff) with other constitutional amendments they are preparing, > according to some rumors. I would clearly prefer things where done via a GR. I don't see the harm in the current situation. Kurt -- 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/20120607201831.ga22...@roeckx.be
Re: Bug#678679: Spice, current status and the fueture in Debian
On Sun, Jun 24, 2012 at 01:26:47AM +0800, Liang Guo wrote: > Package: tech-ctte > Severity: normal > > Hi, Technical Committee, > > We'd like to decide how the spice[1] should be maintained in Debian. [ ... background ... ] This contains a lot of information about what the state of the package is, and what problems you're facing. But I didn't see you ask a question. Do you just seek advice on what you should do? Do you want to have more options? Do you want to override the decision of some maintainer? Do you want to delegate a decision to the ctte? Kurt -- 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/20120623204710.ga13...@roeckx.be
Re: Number typo in the Constitution
On Mon, Jul 09, 2012 at 04:07:38AM +0100, Ian Jackson wrote: > > = TC RESOLUTION STARTS = > > 1. The Debian Technical Committee hereby exercises its power in >4.2(1) of the Debian Constitution to propose the following >General Resolution: > >- GENERAL RESOLUTION STARTS - > >Constitutional Amendment: Fix duplicate section numbering. > >The current Debian Constitution has two sections numbered A.1. >This does not currently give rise to any ambiguity but it is >undesirable. > >Fix this with the following semantically neutral amendment: > > - Increment the section numbers of sections A.2 to A.6; > - Renumber the second section A.1 to A.2; > - Amend the references into A from elsewhere in the constitution > accordingly. Specifically change the references to A.6 in > 5.2(7) and 6.1(7) to refer to that section under its new > number A.7. > >- GENERAL RESOLUTION ENDS - Works for me. Kurt -- 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/20120709032115.ga9...@roeckx.be
Re: Technical Committee proposed GRs, and amendments, again
On Mon, Jul 09, 2012 at 04:07:04AM +0100, Ian Jackson wrote: > > (a) the TC will use its own power under A.1(1) to arrange that > the amendment appears on the GR ballot as an option; > > (b) the TC will use its power under A.1(1) to propose and > its power under A.1(2) to accept the amendment, so that > the amendment is incorporated in the version voted on; or I assume this is the second A.1? Kurt -- 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/20120709033041.ga9...@roeckx.be
Re: Technical Committee proposed GRs, and amendments, again
On Mon, Jul 09, 2012 at 04:19:36AM +0100, Ian Jackson wrote:
> Ian Jackson writes ("Technical Committee proposed GRs, and amendments,
> again"):
> >Therefore, to achieve roughly the same effect, the TC makes the
> >following promise. If any TC member gives notice that the TC
> >accepts an amendment, then at least one of the following will
> >happen:
>
> The way I imagine this working is that we nominate one TC member (me,
> I guess) to do the work of soliciting second opinions from other TC
> members, actually formally accepting obvious amendments, and so on.
So basicly you're going to say: "We will probably accept it, but
need to vote on it"? And you'll just wait a while for all the
different amendments to be available and then vote on it?
Kurt
--
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/20120709033650.gb9...@roeckx.be
Re: Draft GR for supermajority fix
On Mon, Jul 09, 2012 at 04:11:21AM +0100, Ian Jackson wrote: >Therefore, in the Debian Constitution amend A.6(3) as follows: > >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. > + 2. An option A defeats the default option D by its > + required majority ratio if: > + (a) V(A,D) is strictly greater than V(D,A); and > + (b) if a supermajority of N:M is required for A, > + M * V(A,D) is greater than or equal to N * V(D,A). M currently can only be 1. I'm also not very happy with the wording of supermajority. It's not really defined what it means, but is used. For instance 4.1.5.3 talks about a "3:1 majority" and not about a supermajority. I will probably translate this to if N > 1 for use in devotee. >For the avoidance of any doubt, this change does not affect any >votes (whether General Resolutions or votes in the Technical >Committee) in progress at the time the change is made. This also means that either all votes will start and stop at the same time, or the next one will have to wait until this vote is over. I don't want to run 2 instances of devotee. Kurt -- 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/20120709040207.gc9...@roeckx.be
Re: Technical Committee proposed GRs, and amendments, again
On Mon, Jul 09, 2012 at 04:38:20AM +0100, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Technical Committee proposed GRs, and amendments,
> again"):
> > On Mon, Jul 09, 2012 at 04:19:36AM +0100, Ian Jackson wrote:
> > > The way I imagine this working is that we nominate one TC member (me,
> > > I guess) to do the work of soliciting second opinions from other TC
> > > members, actually formally accepting obvious amendments, and so on.
> >
> > So basicly you're going to say: "We will probably accept it, but
> > need to vote on it"? And you'll just wait a while for all the
> > different amendments to be available and then vote on it?
>
> Yes.
That works for me.
Kurt
--
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/20120709041155.ga10...@roeckx.be
Re: Draft GR for supermajority fix
On Mon, Jul 09, 2012 at 06:16:42PM +0100, Ian Jackson wrote: > > I'm also not very happy with the wording of supermajority. It's > > not really defined what it means, but is used. For instance > > 4.1.5.3 talks about a "3:1 majority" and not about a > > supermajority. I will probably translate this to if N > 1 > > for use in devotee. > > Please do feel free to suggest improvements to the wording. I want > this to be clear and unambiguous. > > How about if we s/supermajority/majority/ in what I just proposed ? No, that's clear at all. The 1:1 majority would fall under that too. How about something where N > M? > > >For the avoidance of any doubt, this change does not affect any > > >votes (whether General Resolutions or votes in the Technical > > >Committee) in progress at the time the change is made. > > > > This also means that either all votes will start and stop at the > > same time, or the next one will have to wait until this vote is > > over. I don't want to run 2 instances of devotee. > > How you implement this is up to you, I think, but 1. clearly it would > be wrong to have a GR which affected the rules for a vote currently in > progress and 2. we don't want to hold the whole lot sequentially. > > Certainly we would like to run all the votes concurrently. So just make you call for vote for all of them during the same week. Kurt -- 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/20120709172652.ga22...@roeckx.be
Re: Draft GR for supermajority fix
On Mon, Jul 09, 2012 at 06:36:07PM +0100, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Draft GR for supermajority fix"):
> > On Mon, Jul 09, 2012 at 06:16:42PM +0100, Ian Jackson wrote:
> > > Please do feel free to suggest improvements to the wording. I want
> > > this to be clear and unambiguous.
> > >
> > > How about if we s/supermajority/majority/ in what I just proposed ?
> >
> > No, that's clear at all. The 1:1 majority would fall under that
> > too. How about something where N > M?
>
> If the 1:1 majority falls under it too then the proposed text works
> correctly, surely ?
Oh, you would interprete it as that both (a) and (b) would need
to be true. And I already wondered what your intention there was.
Kurt
--
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/20120709174615.ga22...@roeckx.be
Re: Draft GR for supermajority fix
On Mon, Jul 09, 2012 at 06:52:40PM +0100, Ian Jackson wrote: > > Yes. That's what I meant. How about this: > >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. > + 2. An option A defeats the default option D by its > + required majority ratio if both: > + (a) V(A,D) is strictly greater than V(D,A); and > + (b) if a majority of N:M is required for A, > + M * V(A,D) is greater than or equal to N * V(D,A). Looks good to me. Kurt -- 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/20120709180216.ga23...@roeckx.be
Re: Number typo in the Constitution [and 1 more messages]
On Mon, Jul 09, 2012 at 07:04:42PM +0100, Ian Jackson wrote:
> Thijs Kinkhorst writes ("Re: Number typo in the Constitution"):
> > This would of course break previous references to the section numbers, and
> > may be confusing e.g. when browsing older mail archives referencing a
> > specific section. To me an obvious solution would be to renumber the first
> > 'A.1.' to 'A.0.', a numbering convention not quite unknown to us all.
> > Would there be a drawback in that approach?
>
> I didn't think that the references in old archives were important but
> I think actually you are right and they are.
>
> Bastian Blank writes ("Re: Number typo in the Constitution"):
> > I don't think this is a good idea, because it breaks _all_ existing
> > references. At least in germany, they add a letter in this cases. So
> > this would be A.1 and A.1a.
>
> Is it more important to retain unchanged the numbering of the first,
> or the second, A.1 ?
Well you already made references to the second. I don't think
there would be many references to the first.
Kurt
--
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/20120709181344.ga23...@roeckx.be
Re: Bug#681834: network-manager, gnome, Recommends vs Depends
On Tue, Jul 17, 2012 at 10:22:39AM -0700, Russ Allbery wrote: > > Do we know for certain that installation of network-manager excludes > alternatives? Tollef replied to me on debian-devel wondering why people > who don't want to use network-manager just disable it, which implies that > there's some means to turn it off while it's still installed. (I don't > think I ever investigated that.) I think "disable" means you need to tell network-manager that it's not managing that interface. I think I at least once saw that after I stopped it manually it was restarted automaticly over dbus or something. I've set things up in /etc/network/interfaces, and that seems to be having the effect that network-manager doesn't manage that interface. Kurt -- 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/20120718053139.ga16...@roeckx.be
Re: Draft GR for permitting private discussion
On Wed, Jul 18, 2012 at 10:31:15AM +0200, Stefano Zacchiroli wrote: > > The current wording, read literally, means that if I happened to run into > > Steve Langasek, say, at a social occasion, I am not permitted to mention > > network-manager and GNOME to him, because that conversation isn't public > > and that's an issue currently before the technical committee. > > I would agree that if yours here is the common interpretation of the > current wording of the Constitution, then we have a problem. (It is not > *my* reading, but that's meaningless.) I don't think that anyone would > want to inhibit private discussions to happen at all. But I do think > people would expect them to be reported ex-post. I have no problem interpreting "are made public" to mean that a summary is send to the list. Kurt -- 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/20120718162445.ga26...@roeckx.be
Re: Bug#681687: missing mime entry
On Thu, Jul 26, 2012 at 09:58:37AM +0100, Neil McGovern wrote: > On Sun, Jul 22, 2012 at 01:51:32PM -0700, Steve Langasek wrote: > > > If it's the solution that the TC decide on to resolve the issue, it > > > sounds like something we could work with, at least imho, from what I've > > > seen so far. I've CCed -release for any further comments, as I don't > > > know how many members of the team are following -ctte and/or this bug. > > > > Broadly speaking, I think the correct long-term solution is to first add > > support to update-mime for reading both .desktop files and mime files, and > > then to update policy to tell maintainers to use .desktop files instead of > > mime files. And I think it's better for Debian if we can get the first part > > done prior to the wheezy release. But I would like the release team to make > > their own determination of whether the patch that's currently up for > > consideration is of sufficient quality, and sufficiently safe, to be granted > > a freeze exception. > > > > I completely agree with getting rid of the manual mime entries where > they can be automatically generated. I have concerns that the .desktop > format means that it won't work for some packages, but those could > always carry manual entires. > > However, I really do think that pushing in a system wide change at this > stage in the release is not desireable at all, so woudn't be happy to > see it in Wheezy. If we wanted to do this, it should have been started > about two years ago. So I think there are 3 options for wheezy: 1) Have update-mime read the .desktop file, but don't update any packages to replace mime files with .desktop files. 2) Change all mime files to .desktop files (where possible), and have update-mime read the .desktop file. 3) Don't change update-mime to read the .desktop file, have packages ship both .desktop and mime files, re-adding mime files where needed. There are probably other options, but I don't think we want those for wheezy. It's my understanding that Steve suggested option 1), but I have the feeling you're saying 2) is what we want in the long run but not for wheezy. Kurt -- 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/20120726112636.ga30...@roeckx.be
Re: Bug#681834: network-manager, gnome, Recommends vs Depends
On Wed, Aug 08, 2012 at 04:54:36PM +0100, Ian Jackson wrote: > > 2. Our technical objectives do NOT include: [...] > (iii) Users who choose to globally disable Recommends should still > get the desired behaviours as described above in point 1. This whole "NOT" part is very confusing to me. I think you're trying to say here that enable/disabling Recommends globably isn't something you care about, just that there is the possibility to remove it if desired by the user. > > 3. The solution recommended by the gnome-core maintainers is > that users who do not wish to use network-manager should have it > installed but disable it. > > Installing network-manager in these circumstances does > not fully meet any of the above objectives apart from 1(i). > > 5. The alternative solution rejected by the gnome-core maintainers > is downgrade the dependency to Recommends. > > This solution meets all of the objectives from point 1, except > that infelicities in teh package manager may mean that the user ^^^ the Kurt -- 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/2012080848.ga26...@roeckx.be
Bug#700759: Shared library policy on private libs
On Sat, Feb 16, 2013 at 08:24:09PM -0500, Phillip Susi wrote: > Package: tech-ctte > > I filed bug #700677 because ntfs-3g has a shared library that ubuntu's > testdisk links to, but it does not follow the SONAME rules. It seems > that upstream breaks ABI on every release, and the maintainer feels > that the library is not intended for other packages to link to, and > therefore, does not have to comply with section 8.1 of the policy manual. > > I believe that a strict and literal interpretation of the language of > section 8 means that whether you intend the library for other packages > to link to or not, if it is placed in a directory on the default > library search path, it is bound by section 8.1. The statement in > question is: > > "This section deals only with public shared libraries: shared > libraries that are placed in directories searched by the dynamic > linker by default or which are intended to be linked against normally > and possibly used by other, independent packages." > > The use of the word OR there means that whether or not you intend the > lib to be linked against normally and used by other packages, if it is > in a directory on the library search path, then section 8.1 applies. I think that section 8.1 applies. It seems to even match both cases of the or since it: - Actually has an soname - Is shipped in a dir the dynamic linker searches - You say other binaries link against it. - Has a ntfs-3g-dev package > Also there should be something in > place in the debian build system to make sure that linking to such > private libraries either is flagged as an error, or generates a > dependency on the exact version of the library package that the > linking package was built against, in order to prevent packages from > being installable, but unrunnable due to a newer version of the > private library with a different SONAME being installed. What could be done is that the shlibs file sets up a strict version dependency. It currently says: libntfs-3g 837 ntfs-3g udeb: libntfs-3g 837 ntfs-3g-udeb That is without any version at all, and it really should have a version there. I think more than 99% of the packages should have a version there, and it seems lintian doesn't warn about it. An other way to avoid the problem is only providing a static version of the library, but we want to avoid that. Yet an other solution is to provide an API that is stable, and put that in a library with a fixed soname and move the rest to a private library. Kurt -- 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/20130218180440.ga8...@roeckx.be
Re: FTP masters willingly blocking OpenStack nova 2013.1 just right before the OpenStack summit
On Mon, Apr 15, 2013 at 02:50:10PM +0200, Lucas Nussbaum wrote: > the TC is probably a much more suitable body to rule on this I'd like to point out that if the DPL delegated that decision to ftp-master, and ftp-master made a decission, the DPL can't override that. Kurt -- 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/20130415200956.ga28...@roeckx.be
Bug#727708: systemd jessie -> jessie+1 upgrade problems
On Tue, Dec 17, 2013 at 09:38:56PM +0200, Adrian Bunk wrote: > On Tue, Dec 17, 2013 at 10:29:35AM -0800, Russ Allbery wrote: > > Adrian Bunk writes: > > > > > this hits exactly the core of the problem: > > > > > The minimum supported Linux kernel version in glibc is currently 2.6.16, > > > released in 2006. And I'd trust glibc upstreamt that this requirement > > > won't suddenly be bumped to a quite recent version. > > > > > Is there any explicit commitment from systemd upstream that releases of > > > systemd releases around 2017 will still contain fallback code to work > > > on kernels from 2013/2014? > > > > I'd really like to keep this bug and this discussion focused on what's > > relevant to Debian as a project, so let's put this in that perspective. > > The oldest kernel that Debian supports is 2.6.32, released in 2009. But > > the oldest kernel that we support for upgrades, which is the only point at > > which systemd backward compatibility matters for Debian's support model, > > is 3.2.0, released in 2012. > > Nitpick: > 3.2.0 was released on January 5th 2012, so nearly 2011 And that is why it's up to 3 years. We release about every 2 years, but the kernel we have in wheezy was already about 16 months old when wheezy was released. Jessie will freeze in november 2014, so that the kernel will then be about 3 years old. I'm going to assume that the release team is not going to accept new systemd versions from that point on, so systemd should only support a kernel that's 3 years old. Kurt -- 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/20131217200907.ga26...@roeckx.be
Re: call for votes on default Linux init system for jessie
On Mon, Jan 27, 2014 at 05:30:36PM +, Colin Watson wrote: > On Mon, Jan 27, 2014 at 08:53:39AM -0700, Bdale Garbee wrote: > > I do not expect this to be the TC's last word on the issue, just a first > > step, so I didn't think about the GR super-majority in the context of > > this question. But I see your point, and would certainly have been > > willing to include such text. > > Could we perhaps just revote on an amended resolution then, rather than > finishing this vote? Seems better for all the committee members to be > happy with what we're voting on. I would like to point out that there is a quorum of 2, which has been reached, and that you have 1 week to vote. I suggest you take this into account, or this might result in a decision you did not intend. Kurt -- 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/20140127203027.ga16...@roeckx.be
Re: call for votes on default Linux init system for jessie
On Tue, Jan 28, 2014 at 09:21:10AM -0700, Bdale Garbee wrote: > Kurt Roeckx writes: > > > I would like to point out that there is a quorum of 2, which has > > been reached, and that you have 1 week to vote. > > Kurt, > > It has been suggested to me that now that we have 4 votes for FD, that > this vote is effectively terminated regardless of whether I take action. > In your official capacity, do you agree with that interpretation, or > must I take action to explicitly withdraw the call for votes? If so, > what is the appropriate action? So to clarify, I think a proposal can be withdrawn, but once the vote has been called it can't be withdrawn, and you're left with things like not reaching quorum of voting FD over the other options. So looking at the votes, I found: Bdale: 12345 Russ: 12534 Ian: FD, sysvinit, upstart, openrc, systemd Keith: 12435 Don: 5 (4=3=2=1) Steve: 52134 Andi: 52134 (I didn't see anybody change his vote, and didn't see Colin vote?) Anyway, I'm really only sure what Ian and Don vote. The way I see it there are 2 ways to represent your votes with only numbers. The one that devotee uses is you give the rank for each of the options in order of the options, because that way you can represent votes that you consider equal. What I think some people here use is the order of the options which gets confusing because they're also numbers. I think it would be good that you all agree on some short notation to avoid confusion, like Don's. What I think people vote in devotee's notation is: 12345 12453 53421 12435 1 32451 32451 So even if Colin would vote you couldn't beat the default option (FD), and all the other options would be dropped. As such I think the result is no longer in doubt and FD wins. Kurt -- 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/20140128175204.ga4...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Wed, Feb 05, 2014 at 04:33:57PM +, Ian Jackson wrote: > == rider for all versions except GR == > >This decision is automatically vacated by any contrary General >Resolution which passes by a simple majority. In that case the >General Resolution takes effect and the whole of this TC resolution >is to be taken as withdrawn by the TC, just as if the TC had >explicitly withdrawn it by a subsequent TC resolution. I'm not sure I like the way this is worded, I would have prefered that you asked me about this before calling for votes. Kurt -- 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/20140205191925.ga4...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Wed, Feb 05, 2014 at 04:33:57PM +, Ian Jackson wrote:
> Ian Jackson writes ("Bug#727708: package to change init systems"):
> > I now intend to do the CFV at 16:30 UTC on Wednesday.
>
> I hereby call for votes on my previously proposed resolution and
> amendments. All the options require a simple majority.
>
> The list of options, and full resolution text, are reproduced below.
I would really like it that you indicated under which power the
CTTE is making decisions, and the majority requirements that go
with that the options, for all your votes.
Kurt
--
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/20140205200856.ga6...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Wed, Feb 05, 2014 at 10:15:00PM +0100, Andreas Barth wrote:
> * Kurt Roeckx (k...@roeckx.be) [140205 21:09]:
> > On Wed, Feb 05, 2014 at 04:33:57PM +, Ian Jackson wrote:
> > > Ian Jackson writes ("Bug#727708: package to change init systems"):
> > > > I now intend to do the CFV at 16:30 UTC on Wednesday.
> > >
> > > I hereby call for votes on my previously proposed resolution and
> > > amendments. All the options require a simple majority.
> > >
> > > The list of options, and full resolution text, are reproduced below.
> >
> > I would really like it that you indicated under which power the
> > CTTE is making decisions, and the majority requirements that go
> > with that the options, for all your votes.
>
> Hm, the same would be valid for Bdales call for votes recently? Or
> what is the difference here?
I'm really asking about all votes.
Kurt
--
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/20140205215244.ga10...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Wed, Feb 05, 2014 at 10:05:45PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > I would really like it that you indicated under which power the
> > CTTE is making decisions, and the majority requirements that go
> > with that the options, for all your votes.
>
> Sorry not to give you an explicit heads-up about this resolution. (It
> has been proposed in this form for some time now though.)
Please do not assume I have time to read everything. I don't. I
actually think I gave advice about this before which you seem to
have ignored.
> Anyway, I think as regards T vs L we are chiefly exercising our power
> to set technical policy. As regards the default init system we are
> making a decision which has been requested of us by the people
> normally responsible (which would be the d-i maintainersI think).
I would like to point out that this was requested by Paul
Tagliamonte, who as far as I know is not in the d-i team. I
didn't see anybody from the d-i team request that you make a
decision for them, but I might have missed that.
Kurt
--
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/20140205223540.ga11...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Wed, Feb 05, 2014 at 11:09:25PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > I'm not sure I like the way this is worded, I would have prefered
> > that you asked me about this before calling for votes.
>
> So assuming that the current vote is cancelled due to 4 people ranking
> FD first: would you care to say what the wording should be ? I don't
> think any of us care very much about this wording and we all agree
> about the intent, so it shouldn't be controversial.
My biggest concern is that you can only do this if the result of
the GR is FD. It should be more explicit that if the option is
trying to override the ctte but failed to reach the 2:1 majority
requirement you will re-evaluate the results with the 2:1 majority
requiremented to override the ctte changed to 1:1 and adopt the
outcome of that (which might still be FD).
Kurt
--
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/20140205233253.ga13...@roeckx.be
Re: Bug#727708: Call for votes on init system resolution
On Thu, Feb 06, 2014 at 12:40:22AM +0100, Philipp Kern wrote: > > I'd prefer if CTTE members would actually sign their votes. (But I > guess it's up to the secretary.) I've actually asked that they do that before, but it's not really a requirement. Kurt -- 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/20140205234631.ga13...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Thu, Feb 06, 2014 at 12:32:53AM +0100, Kurt Roeckx wrote:
> On Wed, Feb 05, 2014 at 11:09:25PM +, Ian Jackson wrote:
> > Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > > I'm not sure I like the way this is worded, I would have prefered
> > > that you asked me about this before calling for votes.
> >
> > So assuming that the current vote is cancelled due to 4 people ranking
> > FD first: would you care to say what the wording should be ? I don't
> > think any of us care very much about this wording and we all agree
> > about the intent, so it shouldn't be controversial.
>
> My biggest concern is that you can only do this if the result of
> the GR is FD.
So let me expand on that a little. Image the following options
- A: something that doesn't overrule the ctte (1:1)
- B: something that does overrule the ctte (2:1)
- FD
If option B would win but is dropped because of the 2:1 majority
and option A wins instead the project would have made a decision
and you can't overrule that anymore.
Kurt
--
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/20140205235618.gb13...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Wed, Feb 05, 2014 at 10:31:24PM -0800, Russ Allbery wrote: > Don Armstrong writes: > > On Thu, 06 Feb 2014, Kurt Roeckx wrote: > > >> So let me expand on that a little. Image the following options > >> - A: something that doesn't overrule the ctte (1:1) > >> - B: something that does overrule the ctte (2:1) > >> - FD > > > In this case, I don't know A could be anything but 2:1, baring riders > > from the CTTE. If A is technical, it needs the power of the CTTE under > > §4.1.4 which requires 2:1. [I suppose something could be written which > > would fall under the DPL's remit.] > > > As I understand it, we'd like to make everything be 1:1, and the method > > we're trying is to write a proposal in such a way that it automatically > > enshrouds a non-technical statement by the project in the power of the > > CTTE. > > > It may be that we can't actually do that, and should instead just have > > an agreement between CTTE members to enact a decision which followed a > > position statement GR under §4.1.5. > > I think what we're trying to say looks something like this: > > If the project holds a GR vote on the topic of the default init > system, the winning option of that vote replaces this text in its > entirety and becomes the decision of the Technical Committee. The > winning option of the GR vote for this purpose will be decided > following the normal rules for deciding the outcome of a General > Resolution, with the exception that the 2:1 majority normally required > to overule the Technical Committee will not be taken into account. I think there are basicly 2 ways to go about this: - You revoke your decision during the GR process so that when the GR is being voted on your decision no longer applies and the GR isn't trying to override the ctte. You could for instance do this at the call for votes point. - The GR will be with 2:1 majority and if it comes to a decision other than FD, that will be the result. If the decision of the GR is FD you could go and re-intreprete it with the 2:1 majority dropped. I suggest you go for the first option. Kurt -- 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/20140206175902.ga5...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Wed, Feb 05, 2014 at 10:58:06PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > Please do not assume I have time to read everything. I don't. I
> > actually think I gave advice about this before which you seem to
> > have ignored.
>
> I'm sorry if I also missed a mail.
>
> > > Anyway, I think as regards T vs L we are chiefly exercising our power
> > > to set technical policy. As regards the default init system we are
> > > making a decision which has been requested of us by the people
> > > normally responsible (which would be the d-i maintainersI think).
> >
> > I would like to point out that this was requested by Paul
> > Tagliamonte, who as far as I know is not in the d-i team. I
> > didn't see anybody from the d-i team request that you make a
> > decision for them, but I might have missed that.
>
> I assume you would like us to cancel the current vote and address
> these points.
I have no problem with the vote being held. However I might feel
the need partially revoke the decision at some point.
Kurt
--
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/20140206180453.gb5...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Thu, Feb 06, 2014 at 10:22:15AM -0800, Don Armstrong wrote: > On Thu, 06 Feb 2014, Kurt Roeckx wrote: > > I think there are basicly 2 ways to go about this: > > - You revoke your decision during the GR process so that when > > the GR is being voted on your decision no longer applies and > > the GR isn't trying to override the ctte. You could for > > instance do this at the call for votes point. > > - The GR will be with 2:1 majority and if it comes to a decision > > other than FD, that will be the result. If the decision of the > > GR is FD you could go and re-intreprete it with the 2:1 majority > > dropped. > > Either of these options will require 2:1, though. > > Let me quote §4.1.4: > >Together, the Developers may: [...] Make or override any decision >authorised by the powers of the Technical Committee, provided they >agree with a 2:1 majority. > > As you can see, there's no difference between making a decision which > requires the CTTE powers (first proposed method), or overriding a > decision which requires the CTTE powers (second proposed method). It's not clear to me which powers of the the ctte they would be overriding. I can't say anything about that until someone actually makes a draft text for that GR. Kurt -- 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/20140206183701.ga7...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Thu, Feb 06, 2014 at 06:26:09PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > I think there are basicly 2 ways to go about this:
> > - You revoke your decision during the GR process so that when
> > the GR is being voted on your decision no longer applies and
> > the GR isn't trying to override the ctte. You could for
> > instance do this at the call for votes point.
> > - The GR will be with 2:1 majority and if it comes to a decision
> > other than FD, that will be the result. If the decision of the
> > GR is FD you could go and re-intreprete it with the 2:1 majority
> > dropped.
> >
> > I suggest you go for the first option.
>
> The Developers have, by way of GR, the ability to express opinions as
> a non-binding "position statement on a matter of the day". This
> requires a 1:1 majority.
That assumes that the text is actually a position statement. I'm
not sure that I can interprete all texts as position statements.
As always, I have to see the text first.
> Do you think the Developers lose that ability if their non-binding
> position statement expresses views which are contrary to a decision of
> the TC ?
I don't see how Developers by way of GR can lose any power by a
body inside or outside Debian.
> Do you think the TC can take into account, in its decisionmaking, the
> non-binding views expressed by bodies such as the Developers in
> General Resolution ? I think, yes.
Yes.
> Do you think the TC can make its decisions conditional on future
> events ? I think, yes. Is that in any way limited to the kinds of
> future events ? I think not.
I already said they can. But I also said it will depend on the
wording.
> If you agree with this reasoning then I'd be grateful if you'd advise
> what form of words should be used to achieve the desired effect. The
> desired effect is that:
>
> * A GR option containing a non-binding position statement, requiring
>a 1:1 majority, can trigger:
>
> * Provisions in a TC resolution which is conditional on such a GR,
>
> * such that the TC declares in advance that the GR's views are to be
>substituted for the TC's.
I guess it should mention that the option in the GR should be a
position statement (and should not try to override the CTTE).
Kurt
--
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/20140206184954.gb7...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Thu, Feb 06, 2014 at 06:53:56PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Re: Bug#727708: Call for votes on init system
> resolution"):
> > On Thu, Feb 06, 2014 at 06:26:09PM +, Ian Jackson wrote:
> > > If you agree with this reasoning then I'd be grateful if you'd advise
> > > what form of words should be used to achieve the desired effect. The
> > > desired effect is that:
> > >
> > > * A GR option containing a non-binding position statement, requiring
> > >a 1:1 majority, can trigger:
> > >
> > > * Provisions in a TC resolution which is conditional on such a GR,
> > >
> > > * such that the TC declares in advance that the GR's views are to be
> > >substituted for the TC's.
> >
> > I guess it should mention that the option in the GR should be a
> > position statement (and should not try to override the CTTE).
>
> Yes. What did you think of my proposal earlier ? If you don't think
> that has the right effect, please suggest something else.
Yes, I think that should be fine.
> > That assumes that the text is actually a position statement. I'm
> > not sure that I can interprete all texts as position statements.
> > As always, I have to see the text first.
>
> If the text explicitly says that it is a non-binding position
> statement issued under s4.1.5 of the Constitution, would that suffice ?
Yes.
Kurt
--
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/20140206185750.ga7...@roeckx.be
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 01:30:25PM +0100, Didier 'OdyX' Raboud wrote: > > Finally, I have hard time seeing under which powers could L be decided > by the tech-ctte: the policy team hasn't worked on that (§6.1.1), there > is no juridiction overlap that I could see (nor a disagreement about the > matter, §6.1.2), and it's not formulated as an overrule (§6.1.4) or an > advice (§6.1.5). The only relevant bit would be §6.1.3 as Paul > specifically asked for in <20131025184344.gb4...@helios.pault.ag>: So Didier recently forwarded this to the secretary, saying: > I've mailed Message-ID <1997214.E2693zAoXp@gyllingar> to the init system > bug, but forgot to CC you for a more binding advice on the > constitutionality of L. I'm therefore hereby writing to you explicitely; > my original message is attached. > > Don't hesitate to prove me wrong publically, I'm only interested in > having a constitutionally sane decision out, rather sooner than later. I have also asked them under which power they decide things. This makes things so much clearer for everybody. The text from the last vote said: > == dependencies rider version L (Loose coupling) == > > Software outside of an init system's implementation may not require > a specific init system to be pid 1, although degraded operation is > tolerable. > > Maintainers are encouraged to accept technically sound patches > to enable improved interoperation with various init systems. I'm guessing that under you're asking for the interpretation of this in 6.1.1: | In each case the usual maintainer of the relevant software or | documentation makes decisions initially And think that because the policy maintainers didn't try to make any decision yet, the ctte can't make that decisions? I can certainly understand that that is one way of looking at it. I'm not yet sure about this and would like to receive some input. Kurt -- 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/20140206193825.ga8...@roeckx.be
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote: > > I'm guessing that under you're asking for the interpretation of > this in 6.1.1: > | In each case the usual maintainer of the relevant software or > | documentation makes decisions initially > > And think that because the policy maintainers didn't try to make > any decision yet, the ctte can't make that decisions? > > I can certainly understand that that is one way of looking at it. > > I'm not yet sure about this and would like to receive some input. I'm currently of the opinion that gnome made an initial decisions and as reaction to that they are setting policy and that this will be allowed under 6.1.1. Kurt -- 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/20140206201936.ga9...@roeckx.be
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Fri, Feb 07, 2014 at 04:01:12PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Both T and L are wrong, plea for something
> simpler (was: Re: Call for votes on init system resolution)"):
> > I'm currently of the opinion that gnome made an initial decisions
> > and as reaction to that they are setting policy and that this will
> > be allowed under 6.1.1.
>
> It's clear that whether this kind of dependency is allowed is a key
> issue (perhaps even _the_ key issue) in this dispute. The question of
> the default init system is in some ways a proxy for the coupling
> question. And the extent and timing of such dependencies is clearly a
> matter that ought to be dealt with in the policy manual. So it is
> definitely a matter of technical policy.
I don't think anybody is arguing that it's not technical policy.
> Whether the matter is ripe for the TC is not something that I would
> expect the Secretary to rule on. I think that's a matter for the TC.
> (The alternative would be to contemplate the TC making a decision on
> policy and the Secretary then stating that the TC decision was invalid
> and of no effect.)
I think we all want to avoid that I have to retract the decision
and so maybe it's best that we try to find the answer before the
vote. Anyway, I've already been asked about this, so I see little
point in waiting.
Kurt
--
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/20140207175544.gb31...@roeckx.be
Bug#727708: Call for votes on init system resolution
On Fri, Feb 07, 2014 at 02:04:42PM +, Ian Jackson wrote:
> Kurt Roeckx writes ("Bug#727708: Call for votes on init system resolution"):
> > I would really like it that you indicated under which power the
> > CTTE is making decisions, and the majority requirements that go
> > with that the options, for all your votes.
>
> I have added the following texts to the drafts in git:
>
> + == introduction (all versions except GR) ==
> +
> + We exercise our powers to set technical policy (Constitution 6.1.1)
> + and decide in cases of overlapping jurisdiction (6.1.2):
Could you instead add that to the individual options, so it's
clear for which part of the text you use which power?
Kurt
--
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/20140207182930.gb...@roeckx.be
Bug#727708: Both T and L are wrong, plea for something simpler (was: Re: Call for votes on init system resolution)
On Fri, Feb 07, 2014 at 04:43:33PM +0100, Didier 'OdyX' Raboud wrote: > Hi Kurt, > > Le jeudi, 6 février 2014, 21.19:36 Kurt Roeckx a écrit : > > On Thu, Feb 06, 2014 at 08:38:25PM +0100, Kurt Roeckx wrote: > > > I'm guessing that under you're asking for the interpretation of > > > > > > this in 6.1.1: > > > | In each case the usual maintainer of the relevant software or > > > | documentation makes decisions initially > > > > > > And think that because the policy maintainers didn't try to make > > > any decision yet, the ctte can't make that decisions? > > Yes. I stand to this interpretation, see below. > > > I'm currently of the opinion that gnome made an initial decisions > > and as reaction to that they are setting policy and that this will > > be allowed under 6.1.1. > > Back then, the gnome maintainers added a dependency on another package, > which happened to be providing an /sbin/init. This was allowed by the > Debian Policy of the time as well as by the Debian archive. The > maintainers of the Policy maintainers haven't tried to rule on this at > all since then. How is this matter now magically taken off the Policy > maintainers' hands (while it _is_ a matter of Policy) and become a > matter for the technical committee? Do you agree that the ctte can decide policy? Under what conditions? I think it all boils down to what "relevant software or documentation" means. > I feel compelled to write that I'm quite concerned to see technical > committee members propose to rule on things they see fit, just because > it's sufficiently important to their eyes. As I detailed in > <1756169.he50hsLr7Y@gyllingar>, I'm quite firmly convinced that any > ruling restricting software dependencies fails §6.1.1 (as the powers > invoked), §6.3.5 and §6.3.6 at this point in time. About detailed design work: You could argue that they proposed the alternative solutions and aren't just deciding between them. As far as I know those proposols come from the ctte itself, in which case it should probably go under 6.1.5 to give advice. About 6.3.6: I think trying to resolve this via consensus failed. Anyway, I'm still not sure. Kurt -- 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/20140207174751.ga31...@roeckx.be
Bug#727708: Both T and L are wrong, plea for something simpler
On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote: > "Didier 'OdyX' Raboud" writes: > > > Back then, the gnome maintainers added a dependency on another package, > > which happened to be providing an /sbin/init. This was allowed by the > > Debian Policy of the time as well as by the Debian archive. The > > maintainers of the Policy maintainers haven't tried to rule on this at > > all since then. How is this matter now magically taken off the Policy > > maintainers' hands (while it _is_ a matter of Policy) and become a > > matter for the technical committee? > > I appreciate what you're saying here (although I think 6.1.1 overrides > that), but as one of the delegated Policy Editors, I would immediately > punt such a question arising in the Policy context to the TC under 6.1.1 > and 6.1.3. There is absolutely no way the normal Policy maintenance > process could deal with this debate. > > If it makes you feel more comfortable with this process, please assume > that's happened. It would be nice that other members from the policy tean could agree to that. Kurt -- 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/20140207211351.ga4...@roeckx.be
Bug#727708: Both T and L are wrong, plea for something simpler
On Sat, Feb 08, 2014 at 05:45:19PM +0100, Bill Allombert wrote: > On Fri, Feb 07, 2014 at 10:13:52PM +0100, Kurt Roeckx wrote: > > On Fri, Feb 07, 2014 at 11:04:12AM -0800, Russ Allbery wrote: > > > "Didier 'OdyX' Raboud" writes: > > > > > > > Back then, the gnome maintainers added a dependency on another package, > > > > which happened to be providing an /sbin/init. This was allowed by the > > > > Debian Policy of the time as well as by the Debian archive. The > > > > maintainers of the Policy maintainers haven't tried to rule on this at > > > > all since then. How is this matter now magically taken off the Policy > > > > maintainers' hands (while it _is_ a matter of Policy) and become a > > > > matter for the technical committee? > > > > > It would be nice that other members from the policy tean could > > agree to that. > > The policy maintainers job is to maintain the policy document, not > to adjudicate conflicts. I would have to disagree with that. The recent delegation among other things says "defines [...] technical requirements that all packages must satisfy". What the ctte here wants to do is set policy about having a Depends on an init system. Under the delegation I think this is something for the policy editors to decide. > We can offer advice whether some practice is compliant with the policy > document, but that is about it. We do not have more authority to report RC bug > than any other DD. This is not about being RC or not. This is about setting policy. > The policy document does not cover every issue. It is restricted to situation > when there is a consensus to pick one possible implementation and to codify > in policy. > > Whether the policy allows or not gnome to depend on non-default /sbin/init is > a > side issue until we know what the default init is going to be. What is going on here is that as policy editors you need to set policy and that the ctte here is setting policy instead of you. The question has been asked that it is at this time allowed for them to do so. It's not up to the ctte to do detailed design work, and that they should decide between the options discussed somewhere else if they can not come to a consensus. It has been argued that this has not been discussed somewhere else, and so that it's not yet up to the ctte to decide this. What I understand that Russ is now saying is that if this was brought to the policy team, he would refer it to ctte. As delegate he can decide this on his own, but it would be nice that the other delegates didn't disagree with that. Kurt -- 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/20140208171552.ga29...@roeckx.be
Bug#727708: Both T and L are wrong, plea for something simpler
On Sat, Feb 08, 2014 at 03:13:36PM -0800, Steve Langasek wrote: > > I question the whole notion of DPL delegation of policy powers to the policy > editors. Can I suggest you start a GR about if you think the DPL is maing decisions he can not make? I also suggest you re-read Neil's text on the subject, because it does have room for interpretation. Kurt -- 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/20140209112118.ga13...@roeckx.be
Re: Quorum on recent votes
On Sun, Feb 09, 2014 at 12:55:53PM -0800, Russ Allbery wrote: > Hello everyone, > > I want to remind everyone on the committee that our quorum on votes is 2. I understand that there might be confusion on what this quorum means exactly, and what Steve's vote on those has as effect. The quorum is per option, see A.6.2. That is, the option should have that many votes over the default (FD) to be considerd. Steve's vote did not have as effect that the quorum for any of the options was reached. Kurt -- 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/20140209220626.ga25...@roeckx.be
Re: Understanding the current state
On Tue, Feb 11, 2014 at 02:13:46PM +, Sam Hartman wrote: > > > 3) Ian's resolution on coupling (approximately L from the previous > ballot) currently has two votes cast and meets quorum. If the voting > period expires with no additional votes cast, that resolution would > pass. You mean that one that now has 2 that are for it and 3 that voted FD? At no point in time did the option reach quorum as far as I know. Kurt -- 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/20140211185743.ga9...@roeckx.be
Re: Understanding the current state
On Tue, Feb 11, 2014 at 07:57:43PM +0100, Kurt Roeckx wrote: > On Tue, Feb 11, 2014 at 02:13:46PM +, Sam Hartman wrote: > > > > > > 3) Ian's resolution on coupling (approximately L from the previous > > ballot) currently has two votes cast and meets quorum. If the voting > > period expires with no additional votes cast, that resolution would > > pass. > > You mean that one that now has 2 that are for it and 3 that voted > FD? At no point in time did the option reach quorum as far as I know. Of course it did reach quorum, since 2 actually put it as far option. Kurt -- 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/20140211190223.ga9...@roeckx.be
Bug#727708: call for votes on default Linux init system for jessie
On Tue, Feb 11, 2014 at 10:59:34AM -0800, Steve Langasek wrote: > On Tue, Feb 11, 2014 at 12:18:41PM -0500, Sam Hartman wrote: > > > "Bdale" == Bdale Garbee writes: > > > Bdale> Steve Langasek writes: > > >> FWIW I have always assumed that the casting vote is implicit in > > >> the chair's ballot. To require the chair to explicitly exercise > > >> their casting vote, as opposed to the chair's preferences as > > >> expressed on the ballot being applied automatically, opens up > > >> another set of vote gaming strategies that we really shouldn't > > >> get into. > > > Bdale> I would have assumed that, too, but since others did not > > Bdale> share the assumption, it seemed prudent to be explicit about > > Bdale> it. > > > This assumption does not make sense to me in the following cases: > > > * Chair ranks multiple options equilly > > If the chair ranked them equally in his ballot, why should he express a > different preference when it comes to the casting vote? I think the vote should always result in something, and as such the person having the casting vote needs to pick one of the options that are left in the Schwartz set. If there was no preference between them, a choise will still need to be made. I've actually been wondering about this issue myself the past few days, and this seems to me the only good reason why the casting vote should be a different vote than the earlier vote. Kurt -- 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/20140211192219.ga9...@roeckx.be
Bug#727708: Both T and L are wrong, plea for something simpler
On Sat, Feb 08, 2014 at 03:13:36PM -0800, Steve Langasek wrote: > > package maintenance is not > something that I believe it's in the purview of the DPL to delegate. I have to agree with this part. I think this is a power that belongs to the developers. I think that in such delegation the policy editors should be seen as upstream, but they might happen to be the same group that does the packaging. Kurt -- 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/20140212010523.ga18...@roeckx.be
Bug#727708: Call for Votes on init system coupling
On Tue, Feb 25, 2014 at 10:58:25AM -0800, Don Armstrong wrote: > On Mon, 24 Feb 2014, Andreas Barth wrote: > > * Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 19:06]: > > > The options on the ballot are: > > > > > > L Software may not depend on a specific init system > > > N No TC resolution on this question at this time > > > A Advice: sysvinit compatibility in jessie and multiple init support > > > FD Further discussion > > > > I vote L A N FD. > > With this vote, the outcome is potentially in doubt; if Steve ranks L > > A, then Bdale has the casting vote between L and N. If Steve ranks A > > L, or does not vote, then N is the winner. [Presumably in the first > case, Bdale will select N, but I'm not sure if that's enough to call the > vote no longer in doubt.] Assuming this is all the case, I haven't really checked, I think that N is the winner in any case. I see no reason why Bdale would suddenly pick L over N since he already put N first and L below FD. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140225202208.ga5...@roeckx.be
Bug#717076: libjpeg draft resolution
On Thu, Mar 20, 2014 at 05:37:01PM +, Colin Watson wrote: > > To the Project Secretary: Ian raised the point that he feels that option > A should not require 3:1. The "Provides: libjpeg-dev" here is > essentially a technical device to ensure that packages can declare > Build-Depends: libjpeg-dev and that we get consistent results across the > archive without having to make hundreds of changes to individual > packages. Ian's opinion is that this is a simple case of overlapping > jurisdiction (essentially, maintainership of a package, albeit a virtual > one, under 6.1(2)), and therefore does not require a supermajority. > > Could you please interpret the constitution for us? Does option A > require 3:1, or only a simple majority (perhaps with some trivial > rewording)? Thanks. The text says that you're using your power to decide something under 6.1(4). I can't see how that doesn't require a 3:1 majority. The text is also saying what a specific package should do, and that does sound a lot like overriding a maintainer. So if you really want to prevent using a supermajority, I suggest you write is so that you at least don't mention the other package by name but make it more general. I also suggest you don't mention the name libjpeg-dev directly but instead use words to describe it so that it still applies when it needs to be renamed for whatever reason. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140321200014.ga8...@roeckx.be
Bug#717076: libjpeg draft resolution
On Fri, Mar 21, 2014 at 11:38:15PM +, Ian Jackson wrote: > In general I worry that your interpretation of resolution texts > focuses far too much on the exact words used, and far too little on > the substance of the underlying issues. > > In this particular case we have two packages both of which want to > claim the libjpeg-dev virtual package name, which for technical > reasons ought to be provided by only one of them. Clearly this is a > question of overlapping jurisdictions. My understanding is that the point of virtual packages is so that several *can* provide it. But you're now telling 1 package that it can't do that, while you instead could say only one (other) package can do it in this case. The difference in my view is that you decide between how a set of related packages should interact with each other or that you prevent 1 package from following the normal rules. I have no problem interpreting the first case as falling under 6.1(2), but I'm not yet sure about the second. > The fact that the resolution to this matter of overlapping > jurisdictions will result in specific changes having to be made to one > or more packages does not mean that the decision is about overruling > the maintainer of the "losing" package. _Any_ decision about > overlapping jurisdictions will necessarily involve directing that > certain changes be made to one or more packages which their respective > maintainers will not be happy with. > > I.e. your interpretation as I understand it so far entirely > eviscerates the TC's power to rule in case of overlapping > jurisdictions. In your view as you have presented it here it appears > the TC could say something vague and abstract with 1:1 but if we > actually want the losing maintainer to give up the virtual package > name we will need to vote again with 3:1. I have to guess that as ussual we don't understand each other yet, and probably have a different way of looking at things. And I guess I'm ussually going to try suggesting things so that it's unlikely that people doubt that you do have the power to do something. As ussual this was not an official interpreatation of the constituion yet and I do welcome discussions about such topics, so that we can find a consensus what it says in case of doubt. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140322003426.ga26...@roeckx.be
Bug#717076: libjpeg draft resolution
On Fri, Mar 21, 2014 at 06:00:04PM -0700, Russ Allbery wrote: > Kurt Roeckx writes: > > > My understanding is that the point of virtual packages is so that > > several *can* provide it. But you're now telling 1 package that it > > can't do that, while you instead could say only one (other) package can > > do it in this case. > > That's one use of virtual packages. However, that's not the primary use > of virtual packages for -dev packages. As a general rule, we do not want > multiple packages in the archive providing the same -dev package name, > because that leads to nondeterministic builds for any package that > Build-Depends on the virtual -dev package name, and nondeterministic > builds are bad. And I believe the buildds don't even allow it. At least we wants to have that fail but I'm not sure it's still the case. So I keep with my suggestion that you say only 1 package should be providing it instead of saying 1 shouldn't provide it. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140322090537.ga3...@roeckx.be
Bug#746715: Shocking read ...
On Sat, May 03, 2014 at 06:53:29PM +0100, Ian Jackson wrote: > > For the record, the TC expects maintainers to continue to support > the multiple available init systems in Debian. That includes > merging reasonable contributions, and not reverting existing > support without a compelling reason. Did the TC previously agree that we should support multiple init systems? As far as I know only a default was selected, and I'm not sure if something like that this was ever voted on or not. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140503230113.ga19...@roeckx.be
Bug#762194: Initial draft of affirming transition to systemd as default for #762194
On Mon, Jan 26, 2015 at 01:56:41PM -0800, Don Armstrong wrote: > > Using its power under §6.1.5 to make statements: > > 3. The CTTE affirms the decision of the init system package >maintainers to transition to systemd by default on upgrades and to >install systemd by default on new installs. What does it mean to affirm a decision, and how is that a statement? Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150129190828.ga13...@roeckx.be
Bug#762194: Affirm Transition option wins
On Tue, Feb 03, 2015 at 09:47:02AM -0800, Don Armstrong wrote: > On Mon, 26 Jan 2015, Don Armstrong wrote: > > I vote > > > > A > FD. > > On Mon, 26 Jan 2015, Steve Langasek wrote: > > I vote A > FD. > > The 1 week constitutional voting period has now closed; with two votes, > we meet quorum, and option A is the winner. To be more correct, option A reaches quorum because there were 2 votes that ranked A above FD. (I'm assuming that "at least" means >=, not >.) Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150205000834.ga13...@roeckx.be
Re: bastardizing packages or stepping down
On Thu, Mar 05, 2015 at 01:38:29PM +0300, Michael Tokarev wrote: > But once I > uploaded a next release of busybox to the archive, it was rebuilt > using older, unfixed glibc, and the original problem reappeared. I didn't see any request to make sure the chroots are updated. Not having read the whole thing, would this solve your problem? Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150306094626.ga32...@roeckx.be
Re: bastardizing packages or stepping down
On Fri, Mar 06, 2015 at 12:33:20PM -0800, Don Armstrong wrote: > If so, it should be possible to take out a lock to prevent new sbuild > processes on an lvm source chroot, update the source, and then remove > the lock. But maybe there are buildds which aren't using lvm? Almost all buildds have stopped using lvm because of kernel bugs where after running a few hours we had to go and reboot it. There are plans to automate the creation of a new tar on regular basis, but nobody has done it yet. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150307134528.ga15...@roeckx.be
Re: Call for Votes for new CTTE Chairman
On Tue, Mar 10, 2015 at 12:33:49PM -0700, Don Armstrong wrote: > Option A Reached quorum: 5 > 2 > Option B Reached quorum: 4 > 2 > Option C Reached quorum: 3 > 2 > Option D Reached quorum: 4 > 2 > Option E Reached quorum: 4 > 2 > Option F Reached quorum: 4 > 2 > Option G Reached quorum: 4 > 2 Since there is no default option, there can't be a quorum. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150310194904.ga32...@roeckx.be
Re: Call for Votes for new CTTE Chairman
On Tue, Mar 10, 2015 at 08:49:04PM +0100, Kurt Roeckx wrote: > On Tue, Mar 10, 2015 at 12:33:49PM -0700, Don Armstrong wrote: > > Option A Reached quorum: 5 > 2 > > Option B Reached quorum: 4 > 2 > > Option C Reached quorum: 3 > 2 > > Option D Reached quorum: 4 > 2 > > Option E Reached quorum: 4 > 2 > > Option F Reached quorum: 4 > 2 > > Option G Reached quorum: 4 > 2 > > Since there is no default option, there can't be a quorum. I guess whatever you're using is assuming option H is the default option. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150310195047.gb32...@roeckx.be
Bug#741573: Bug #741573:Process Approach vs Others
On Wed, May 27, 2015 at 09:19:07PM -0400, Sam Hartman wrote: > [moving back to the bug, because we're starting to discuss the issue > rather than a TC communications matter.] > > > > "Bdale" == Bdale Garbee writes: > Bdale> I hear you, I just don't have any idea what to do differently > Bdale> on this specific issue in response to knowing how you feel > Bdale> about it. > > I made a specific proposal in #741573. > I'd be a lot happier if you'd say "No, I think we've already reached > agreement that the policy team didn't have consensus., so we don't need to > evaluate whether the process was followed." > I wouldn't agree with that, but sometimes people disagree with you. I'm > OK with that outcome. > > If we've already agreed that the policy team didn't have consensus, my > preference would be to ask the policy community whether they want us to > take up the issue, rather than just asserting a decision from on high. > That is, we communicate to them that we believe that they didn't have > consensus rather than just jumping to a conclusion. > I don't think we need to vote for that if we have internal rough > consensus, although I'd be fine voting on that if we wish to do so. I also feel that we should check that the policy change process has been followed as documented or not. So from reading the policy bug, it seems some of the Policy Editors think that there is a consensus but that Bill Allombert doesn't agree that there is one. The DPL delegation text has this in it: | Count seconds and weight objections to proposals, to determine whether | they have reached sufficient consensus to be included, and accept | consensual proposals. The Policy Change Process does not document on how to handle conflicts between the Policy Editors. I would expect that each Policy Editor can make those decision, and that once it's made an other Policy Editor can't just revert that without following the Policy Change Process. Kurt -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150530154146.ga22...@roeckx.be
Bug#802159: New OpenSSL upstream version
Package: tech-ctte Hi, I've been waiting for the release team for a while to make a decision on #765639 for a year now. Could you help in getting a decision? I've actually been waiting for longer than that, I can't directly find all links, but previous discussions about it are at least: https://lists.debian.org/debian-devel/2013/09/msg00466.html https://lists.debian.org/debian-project/2013/12/msg00140.html Kurt
Bug#802159: New OpenSSL upstream version
On Tue, Oct 20, 2015 at 09:57:04AM -0500, Don Armstrong wrote: > On Sat, 17 Oct 2015, Kurt Roeckx wrote: > > I've been waiting for the release team for a while to make a decision > > on #765639 for a year now. Could you help in getting a decision? > > > > I've actually been waiting for longer than that, I can't directly find > > all links, but previous discussions about it are at least: > > https://lists.debian.org/debian-devel/2013/09/msg00466.html > > https://lists.debian.org/debian-project/2013/12/msg00140.html > > Is there anything that it would be helpful for the technical committee > to do here to help facilitate coming to a decision on this? > > Specifically, this being (FWICT), bringing a new(er) version of openssl > into jessie and/or wheezy. > > I personally don't have enough information to form an opinion yet, but > I recognize that some decision should be made. So to clarify my point of view, I just want to have a decision on my issue. I understand that the release team is having a hard time making a decision, but I'm not sure why. So I guess my initial question is to try and understand why they don't make a decision. I also wonder if it would help them if they delegated the decision to the ctte. There might also be a need to clarify the policy for such updates. Kurt
Bug#802159: New OpenSSL upstream version
On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote: > On Tue, 20 Oct 2015, Don Armstrong wrote: > > On Sat, 17 Oct 2015, Kurt Roeckx wrote: > > > I've been waiting for the release team for a while to make a decision > > > on #765639 for a year now. Could you help in getting a decision? > > > > > > I've actually been waiting for longer than that, I can't directly find > > > all links, but previous discussions about it are at least: > > > https://lists.debian.org/debian-devel/2013/09/msg00466.html > > > https://lists.debian.org/debian-project/2013/12/msg00140.html > > > > Is there anything that it would be helpful for the technical committee > > to do here to help facilitate coming to a decision on this? > > From discussions (briefly) on IRC: > >my general thoughts offhand are that new upstream versions in > stable always make me twitchy, new upstream versions that > introduce features or are sensitive / important packages more > so, new upstream versions that do both doubly. and we try and > avoid ending up saying no to people, which often ends up > actually making things worse as they linger (and we're not > doing that well at keeping up with the "easy" requests right > now) So as already pointed out before, since the 1.0.0 release there is a new release strategy that in the 1.0.x series, where x doesn't change, no new features are added unless it's really needed for either security reasons or compatibility reasons. As far as I know between the version in oldstable (a patched 1.0.1e) and 1.0.1p only 1 feature got added, and people really have been asking for that one. OpenSSL upstream also already has a policy that at least 2 people from the team should review all the changes. Since there are so many changes I don't think it's reasonable for the release team to review all of them. The alternative is that I go and cherry pick the important bug fixes. By this time there are really a lot that I would like to have in the stable releases and I think going that way actually has a higher chance of breaking things. > So from what I'm gathering, this looks like a case where there isn't > enough eyeballs to adequately review this particularly set of updates, > coupled with the importance of making sure that these updates are > correct and don't cause any unintended issues. There is always the case that one persons bug is an other persons feature. But those new upstream versions have been in stable and testing for a while now without actually breaking anything. Kurt
Bug#802159: New OpenSSL upstream version
On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote: > On Tue, 20 Oct 2015, Don Armstrong wrote: > > If there's something specific that you'd like the CTTE to try to do > > beyond what I've just reported now, let me know. > > Let me know if you'd like the CTTE to do something beyond what I've > already done. I guess I would like to know what the options are. The way I see it: - The release team makes a decision - The release team asks someone else to make the decision - Someone makes a policy of what is acceptable, not the current situtation where there don't seem to be any rules. - The DPL removes that power from their delegation. (One can argue that the DPL didn't have the power to delegate that in the first place.) - Start a GR to overrule the DPL's delegate. And I guess I would like advise on how to proceed. Kurt
Bug#802159: New OpenSSL upstream version
On Sat, Oct 31, 2015 at 02:22:04PM +, Adam D. Barratt wrote: > On Sat, 2015-10-31 at 00:02 +0100, Kurt Roeckx wrote: > > On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote: > > > On Tue, 20 Oct 2015, Don Armstrong wrote: > > > > If there's something specific that you'd like the CTTE to try to do > > > > beyond what I've just reported now, let me know. > > > > > > Let me know if you'd like the CTTE to do something beyond what I've > > > already done. > > > > I guess I would like to know what the options are. The way I see > > it: > > - The release team makes a decision > > - The release team asks someone else to make the decision > > - Someone makes a policy of what is acceptable, not the current > > situtation where there don't seem to be any rules. > > If one of those things happened and the resulting decision was that new > OpenSSL upstream releases don't get blanket exceptions, would that be > the end of this discussion? Yes. Kurt
Bug#802159: New OpenSSL upstream version
On Wed, Nov 04, 2015 at 11:57:00AM -0600, Don Armstrong wrote: > > In this specific case, the specific set of changes which have been made, > coupled with documenting the policy of upstream for testing and making > changes to openssl would be a good start. I've pointed to upstream's policy before, but the URL has actually changedin the mean time: https://www.openssl.org/policies/releasestrat.html I've also gave some information about testing that is happening in the stable branches at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765639#110 I'm not sure what you mean with "specific set of changes which have been made". There have been more than 900 upstream commits since the 1.0.1e release that's in wheezy. Most of those are security issues being solved and bug reports that are getting fixed. Then there are lots of things we notice in the master branch that we also fix in the other branches like not checking return values, memory leaks, and so on. But there really is too much to get into details here I think and if you really want to know just look at the git commit messages. Kurt
Bug#802159: New OpenSSL upstream version
On Tue, Dec 15, 2015 at 08:00:59PM +, Adam D. Barratt wrote: > > Even a naively filtered diff - excluding documentation and tests - > between the 1.0.1k tag and HEAD on upstream's stable branch is much > larger than I'd imagined (1091 files changed, 73609+, 68591-), but > paging through it there's a significant amount of "no-op" changes such > as > > - seed_len, > - param_len; > + seed_len, param_len; > > that git diff is sadly too dumb to be able to ignore (or I'm too dumb to > be able to drive it to do so). There was a reformat of the code between those releases. See: https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/ It includes the tags before and after the reformat. Kurt
Bug#802159: New OpenSSL upstream version
On Tue, Dec 15, 2015 at 08:00:59PM +, Adam D. Barratt wrote: > [dropped explicit CCs to RT and TC members] > > On Tue, 2015-10-20 at 20:37 +0200, Kurt Roeckx wrote: > > On Tue, Oct 20, 2015 at 01:12:42PM -0500, Don Armstrong wrote: > > > So from what I'm gathering, this looks like a case where there isn't > > > enough eyeballs to adequately review this particularly set of updates, > > > coupled with the importance of making sure that these updates are > > > correct and don't cause any unintended issues. > > > > There is always the case that one persons bug is an other persons > > feature. But those new upstream versions have been in stable and > > testing for a while now without actually breaking anything. > > (I'm assuming "unstable".) I really meant stable. stable has a newer version than oldstable from the same 1.0.1 series. Kurt
Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
On Sun, Dec 06, 2015 at 11:46:01AM +0100, Moritz Mühlenhoff wrote: > Hi, > Personally I'm in favour of following the openssl point updates and I'd > like to add an additional data point to the discussion: > > CVE-2015-3196 was already fixed as a plain bugfix in an earlier point > release, but the security impact was only noticed later on, so following > the point updates would have fixed this bug five months ago. So now CVE-2015-7575 (SLOTH) has been made public. This is yet an other example of an issue fixed a long time ago. It only affected wheezy because was fixed just after the version in wheezy. Kurt
Bug#802159: Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, Jan 26, 2016 at 06:38:31AM +, Adam D. Barratt wrote: > On Thu, 2015-12-17 at 23:38 +, Adam D. Barratt wrote: > > However 1.0.1q hasn't been in stable at all, which is presumably what > > you'd be proposing introducing to oldstable at this juncture. (and which > > we'd therefore need to introduce to stable first, if we were to agree to > > follow that path.) > > Picking this up again (I hadn't realised the above was so many weeks > ago :-|), updating OpenSSL in Wheezy to anything newer than 1.0.1k > really needs a newer upstream version to be in Jessie first. We also > likely only have two opportunities to get a package in to "Wheezy > proper" before it moves to LTS status - likely a point release in March > and then a "mop up" after the EOL of the base suite. > > > Admittedly, the description of the changes between 1.0.1k and 1.0.1q, > > according to NEWS/CHANGES don't immediately look crazy. > > Comparing those against the package changelog and Security Tracker and > ignoring changes which are apparently only relevant if SSLv2 is enabled > leaves us with: > > *) dhparam: generate 2048-bit parameters by default. > [Kurt Roeckx and Emilia Kasper] > > *) Rewrite EVP_DecodeUpdate (base64 decoding) to fix several bugs. > This changes the decoding behaviour for some invalid messages, > though the change is mostly in the more lenient direction, and > legacy behaviour is preserved as much as possible. > [Emilia Käsper] > > *) In DSA_generate_parameters_ex, if the provided seed is too short, > return an error > [Rich Salz and Ismo Puustinen ] > > *) Build fixes for the Windows and OpenVMS platforms > [Matt Caswell and Richard Levitte] > > The last of those is obviously irrelevant. Have there been any reports > of issues related to the other fixes listed? I can't remember any report about one of the above changes, nor can I find any. The base64 change is that it did weird things when receiving invalid base64, which you shouldn't get in practice, and now at least acts sane. The DSA entry in CHANGES is actually wrong, that's how it was changed in the master branch. It was merged to the stable branches and then reverted without reverting the CHANGES, and then fixed to instead do what was previously documented and uses a random seed if the seed is too short. I'll see about getting that CHANGES entry fixed. We reverted that because we think it wasn't an acceptable change in behaviour in the stable branches. The dhparam thing is really about a default that if you generate DH parameters that it defaults to 2048 instead of 1024. This shouldn't break anything itself, nor do I know of any other software that would get broken by this. You can always override this default when generating them. The most reports about breakage we get actually have to do with the security fixes themself, like enforcing the minimum size of 768 bit when using DH and then finding out that there is software that uses 512 bit DH. (The upcomming release will actually change that to 1024, as announced.) Kurt
