Re: Proposal to delay the decition of the DPL of the withdrawal of the Package Policy Committee delegation
I just want to say that I am deeply dismayed by the turn events have been taking. I have a lot of respect for both A.J. and Manoj. But I don't see a reasonable basis for this disagreement -- this feels more like venting under high pressure (mostly the Etch release, I think). In that context, if I might take some liberties with each of their earlier position statements: AJ: 'decisions specific to this release should be thought about before they're applied to future releases.' Manoj: 'decisions specific to this release have relevance both now and in the context of future releases' Of course, more is involved here than just position statements. In addition to talking past each other, each seems to be taking action as he sees fit. [Which, frankly, is how we are supposed to approach problems.] Both statements are correct. Potential decisions made incorrectly under the aegis of either position are survivable. Albeit, painfully -- this entire process seems painful. I'm not going to recommend anything here -- I think that this whole situation is the rather inevitable fallout which tends to follow in the wake of mis-communication. And, recommendations do not solve mis-communication. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for votes for GR: Re-affirm support to the Debian Project Leader
On 10/7/06, Debian Project Secretary [EMAIL PROTECTED] Voting period starts 00:00:01 UTC on Sunday, Votes must be received by 23:59:59 UTC on Saturday, Fortunately, vote.debian.org provides the associated dates. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Recall the Project Leader
On 9/26/06, Denis Barbier [EMAIL PROTECTED] wrote: On Mon, Sep 25, 2006 at 09:02:19PM -0400, Raul Miller wrote: I don't understand how this proposal answers the question. One answer implied by your proposal: Dunc-tank is grounds for removing Debian's leader, that means it is a debian project. No. Again, I'm somewhat unsure what you mean. This time, I am going to guess you mean No, that implication is not the meaning that [Denis] intended. Do you remember the discussions about the Debian Core Consortium last year? http://lists.debian.org/debian-project/2005/07/msg00202.html Debian developers were concerned about trademark issues, and this consortium has been renamed into DCC Alliance. This does not mean that Debian was part of the DCC Alliance. This does not seem comparable. Talking about concerns is not the same thing as passing a GR to restructure the project in response to those concerns: If we do pass a GR, the results would say something about our thoughts on the underlying issue, its relevance to the project, and our thoughts on related issues. If this was the only answer implied by your proposal, I might agree that your proposal makes confusion vanish. But, it's one of many contradictory implied answers. Ok, let me clarify. Is dunc-tank perceived as an independant project when it is launched by the Debian Project Leader, and this project asks people to give money to help release Etch in time? In my opinion no, people believe that they give money to a Debian project whereas dunc-tank is not. If this is your belief, it seems to me that you are reinforcing the particular implication I suggested originally. Since my point is that your proposal increases confusion, I'll take this opportunity to point out another implication of your proposal: This proposal implies that the beliefs of uninformed outsiders take precedence over decisions made by anyone within Debian. Now, I'm not saying that everyone is going to take this meaning from your proposal. I am, however, saying that the number of people who believe this implication will be at least as large as the number of people believe that they give money to a Debian project whereas dunc-tank is not. That said, if there is fraud involved -- if people are taking money under false pretenses -- that is a criminal matter, and should be treated as such. We should not be waiting on a GR, if that were really the case. This is why I told that this recall procedure will make this confusion vanish. This recall procedure might make your own confusion vanish. It increases my confusion. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical list of proposal text
On 9/21/06, Manoj Srivastava [EMAIL PROTECTED] wrote: On Wed, 20 Sep 2006 12:17:18 +0100, Ian Jackson [EMAIL PROTECTED] said: 3. The person who calls for a vote states what they believe the wordings of the resolution and any relevant amendments are, and consequently what form the ballot should take. However, the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). The web page is not the ballot. But a web page may present the ballot. Personally, I do not think it's an abuse of power for the Secretary to arrange so that the web pages represent a best effort at what the proposals seem to be. Well, not in the general case. If quorum seconders have explicitly quoted the same identical text and that text differs from what the web page says, and there has been more than sufficient time since the seconds to update the web page, that could be abuse of power -- but that's not very much like a best effort. On the other hand, in the general case, refusing to exercise your responsibilities can be just as much an abuse of power as exercising them inappropriately. Sadly, this might leave you with an undue burden (and no good choices) -- particularly when the people presenting the material will not present their concepts clearly -- but I'm dubious that there's anything a person in a position of responsibility can do to deflect all criticism. Not even all unwarranted criticism. That said, if people are flooding you with nonsense, almost any response you can come up with has some validity. And, that includes deliberately operating at some minimum standard. At least, sometimes. This probably isn't very helpful... but I wanted to disagree with you about the web-page issue, and I felt that some of these other concepts were also relevant. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Recall the Project Leader
On 9/20/06, Denis Barbier [EMAIL PROTECTED] wrote: Anthony Towns [wrote]: A question that has been raised is whether the organisation can be sufficiently outside of Debian when the DPL is intimately involved. I don't have the answer to that - in my opinion it can be, but whether this one is will be up to Debian to decide. The article's title mentioned in the first paragraph is: Debian experiments with funding group to release 'etch' on time. Even if Anthony Towns and other Dunc-tankers claim that their project is not affiliated to Debian, external people will still see this project as being handled by the Debian Project Leader, and thus implicitly by the Debian project. ... But we, Debian developers, can make this confusion vanish, and I would like to propose that we answer to the valid question quoted in the second paragraph above by recalling our Project Leader, as allowed by our Constitution (section 4.1.1) and am seeking seconds for this proposal. I don't understand how this proposal answers the question. One answer implied by your proposal: Dunc-tank is grounds for removing Debian's leader, that means it is a debian project. If this was the only answer implied by your proposal, I might agree that your proposal makes confusion vanish. But, it's one of many contradictory implied answers. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Defer discussion about SC and firmware until after the Etch release
A couple weeks ago, Frans Pop [EMAIL PROTECTED] wrote: My rough summary: - (almost) everybody agrees that non-free drivers don't belong in main; - (almost) everybody agrees that sourceless firmware at least needs to be distributable before any kind of support can be considered; - most people agree that Etch should not be delayed for a solution to the sourceless firmware issue; - a fair number of people (though a percentage is hard to estimate) seem to feel that the current Social Contract is too restrictive when it comes to some types of files, forms of documentation and sourceless firmware; - probably a larger number feels that we should not kill the project by scaring away users with hardware that depends on sourceless firmware and is willing to consider solutions for that while still making the projects preference for firmware _with_ source clear to users and others. ... loading such packages from contrib/non-free would imply that these sections have to be added by default to the sources list for these users which is undesirable given the aims of the project It strikes me that our difficulty here is very similar to that behind the special exception written into GPLv2. It's a bootstrapping issue which exists in part because the free software communities need to co-exist with the non-free-software communities. One obvious issue is that the sources list is relevant in contexts where a person has access to the sources, and that installation typically happens when a person only has access to installation media. I think it's upsetting for some people to think about the fact that some people cannot run their computer system without software which, in some sense, we cannot maintain. In the context of the current discussion, such software is free (in terms of licensing fees), but not free (in the DFSG sense). Put differently, I think a lot of the angst, here, is centered around the idea that we should deprecate Contrib and Non-Free. Given how this issue has progressed, I think it's rather clear that we are not yet in a position to do that. Put differently, in the past we have washed our hands of issues associated with distributing Non-Free on different sorts of media. In essence: We are just making this available, but you're on your own when dealing with the legalities of this stuff.No one wants to deal with that problem, but that just makes the problem crop up in other ways. Especially, since it looks like [by our standards], the linux kernel currently belongs in Non-Free -- that's just painful for us to think about. No one wants the kernel to be in Non-Free, especially with how we've been trying to wash our hands of non-free. And yet those very reasons for us washing our hands are the sorts of reasons that would suggest it belongs in Non-Free. Perhaps we need something analogous to the GPL's special exception in our social contract? Something that lets us boot and run Debian on systems with special requirements, without suggesting that we will give up on our efforts to maintain and support free software. In other words, something like amendment text B at http://www.debian.org/vote/2006/vote_004 might be a good thing. But I think our current attitude towards non-free is off balance. And I think the fact that we cannot put reasonably the kernel in Non-Free, even though our standards say it should be in Non-Free, illustrates something about how our current attitudes are broken. And, no, I don't have a solution. [Make copyright law make sense so that copyright issues can be dealt with in a sensible fashion is an example of not a solution.] But I can easily understand why so many people are unhappy and/or upset. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
On 9/21/06, Nick Phillips [EMAIL PROTECTED] wrote: On which subject, does anyone else think that it would be useful to leave debian-vote for formal proposals/seconds (possibly moderated), and another list e.g. debian-vote-discuss (or even just -project) for the flame^Wdiscussions that follow? It would make it a lot easier to tell what was an actual proposal and what was not, what had been seconded and what had not (each proposal gets its own thread, to which the only responses are seconds). Except, that's solving the problem which did not occur. The question I see Manoj posing is not was this message intended to present a proposal, or not. The question I see Manoj posing is which part of this proposal message is the actual proposal. Personally, I'd say that if the situation is so ambiguous that it's not clear whether what people are seconding is the same as what the proposer has proposed that we are not dealing with a valid resolution. Consider a general case: Proposal message contains statements A B C D E Some sequential fragment of this message is the proposal. That means that the proposal might be A, AB, ABC, ABCD, ABCDE, B, BC, BCD, BCDE, C, CD, CDE, D, DE, E. This might dilute seconds by a factor as high as 15. In cases where the secretary feels the burden of interpretation is too high, I think the secretary should ask that the proposal and seconds be re-issued, with the ambiguities resolved. In cases where the secretary's request is refused, I think the secretary would be completely justified as treating each possible resolution as a separate proposal. Though, to be fair, the secretary might wish to present each plausibly seconded possibility as having been seconded, even where this means that a single seconded message seconds more than one potential resolution. And if someone is tempted to claim abuse of power here, I think that it's pretty obvious that the abuse would be on the part of those who refuse to participate in resolving the ambiguities they themselves presented. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The Sourceless software in the kernel source GR
On 9/21/06, I wrote: Personally, I'd say that if the situation is so ambiguous ... Note that nothing I said here in any way overrides the procedures the Secretary posted to dda -- I should have read that announcement before posting. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
On 9/8/06, Sven Luther [EMAIL PROTECTED] wrote: On Thu, Sep 07, 2006 at 05:08:28PM -0500, Bill Allombert wrote: On Fri, Sep 01, 2006 at 02:42:26PM -0400, Raul Miller wrote: Perhaps we should start addressing the CD distributor problem (perhaps tagging CD distributable software, and providing a simple mechanism to pull only CD distributable software for contrib/non-free). It will not work for firmware, be could be done for GFDL documentations: Could you perhaps give us some insight as to why it will not work for firmwares ? I think he means that for firmware there are additional technical hurdles. As I understand it, currently the kernel incorporates the firmware image in the kernel module that implements the driver. The reason for this is that these drivers are used at the abstraction level where we are implementing file systems -- the file system generally does not exist until after they are loaded. [There are exceptions, of course -- ram disk, for example.] This often means that that firmware needs to be included in the kernel source package, and that the module is built at the same time as the rest of the kernel. But note that I've not dealt with this in any detail, so I might have some details wrong. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
On 9/6/06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Suggesting the reverse would be a massive change of course for Debian as a whole. Would this massive change of course be a suggestion? Or would it be something that actually exists? If it's a suggestion, I'm not sure your assertion is valid, because Debian discussions have been full of all sorts of suggestions, and suggestions would hardly seem a massive departure from status quo. If it's something that actually exists, and your assertion is valid, then by inspection I'd say etch is significantly more free than any previous release, and thus the associated massive change seems like it must be something positive. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
On 9/6/06, Marco d'Itri [EMAIL PROTECTED] wrote: On Sep 06, Thomas Bushnell BSG [EMAIL PROTECTED] wrote: There is an absolute ranking in Debian, that *first* we must provide 100% free software, and *second* we do whatever we can to help our users consistent with the first. This is just your opinion, not a fact. I think he has something of a point here. We have Debian Free Software Guidelines, we don't have Debian User Support Guidelines. Maybe we should? We have commitments of degree in the social contract for software freeness. The mention of users, in contexts other than software freedom, is far less extensive. The implication, to me, is that our free software commitment and our user commitment are meant to dovetail. This implies that discussions of either which slight the other might be missing the point. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware Social Contract: GR proposal
Perhaps, before we spend too many more years on trying to solve this problem, we should agree on what this problem is? One issue here is that we are trying to make a statement about what direction we are heading. As M.J.Ray states: The GPL is far closer to 100% free than a source-withheld hard-to-edit blob of a program. And, as http://lwn.net/Articles/196641/ states: Adopting a policy which favors devices having their proprietary software in ROM (where it can never, ever be changed) over those which accept their firmware from the host (where, maybe, someday it could be rebuilt and tinkered with) seems like a step in the wrong direction. Though, the other side of the story is that the ground keeps shifting underneath us. (Which is hardly surprising. Tomorrow's hardware is new, every month.) The way I see it, we're drawing lines in the sand, and the sand is drifting. We're trying to compensate for where the sand is going to be next month, next year, and after that, but we're not omniscient. On top of that, each of us has different concepts about what's coming up. We can agree roughly about where we are going, but even there we often have little control: We did not design hardware which would not function unless we distribute some essential (but non-free) component, and we did not design the software which hard-wires these components into itself. If this is an accurate statement of the problem (is it? if not, what's a more accurate statement? is there an accurate statement of the problem which we can all agree on?), then either: (a) our lines in the sand are going to get broken, or (b) we are going to have to keep on drawing new lines in the sand, or (c) we are going to have to come up with some more resilient approach. As a further note, compromise might be inevitable (it usually is, when people can not agree on the details of what they are trying to do -- and our project has long since exceeded the size where complete agreement, let alone complete understanding, is possible), but compromises that result in new lines in the sand are going to suffer the same flaw -- the ground is going to keep shifting out from underneath us. As a further, further note, I can see the logic in including the firmware in the proposed etch release in etch, for practical reasons and because that firmware is far enough away from what some people consider the operating system and its applications. On the flip side, I can also see the logic in considering that firmware an essential part of the operating system, and can easily imagine a day when applications include components which are downloaded onto auxiliary processors (OpenGL is probably the best today example of this sort of thing). So... we are going to see this problem get bigger in the future, I think, no matter what we decide today. [But I'm cheating: this is a variable.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
What strikes me as ironic, with these proposals, is that we ran into something like this problem back in the 90s, back during the initial adoption of the DFSG, and we had to solve that problem then: we created the non-free and contrib sections. For some reason, these sections are no longer seen as adequate. As I understand it, one aspect of the problem is that CD/DVD distributors do not distribute these sections -- mostly because we have not made it easy for them to do so legally. Perhaps we should start addressing the CD distributor problem (perhaps tagging CD distributable software, and providing a simple mechanism to pull only CD distributable software for contrib/non-free). As for hex as source. I've written machine code in hex, so I have no problem believing that other people would do such a thing. That said, for such source to be useful, the target (whether some general purpose machine language, microcode, some specific set of registers driving hardware, or whatever) needs to be documented well enough that someone else has a chance to read and comprehend the code. Also, except for really small bits of code (a couple K or less), a list of (or system of finding) entry points, internal branch points, and the like is also important The current proposals I've seen here don't seem to address these readability issues. That said, are plenty of grey areas here, and I understand that many programmers have little tolerance for ambiguity. Myself included, sometimes. So... if we want to get these issues sorted out in a timely fashion, perhaps the place to start would be enumerating the packages and issues, in some fashion that makes it easy for other informed people to append useful comments. (For example, if there were BTS pages for each package in question, a top level page listing the urls of each of those BTS pages might be nice.) Has someone already made such a page? Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GR proposal - Restricted-media amendments to the DFSG
On 4/13/06, MJ Ray [EMAIL PROTECTED] wrote: Raul Miller [EMAIL PROTECTED] Your question, as stated, asks for an explanation for a state of affairs which does not exist. My question is: why do some people claim that the FDL wasn't drafted to prohibit all technical measures that obstruct or control reading or further copying? So, you claim that no-one claims the FDL wasn't drafted to cover *all* technical measures? No, I don't make that claim about what other people claim. I was not making a point about claims. I was making a point about the FDL, in the context of your question. I find it relatively trivial to show that this state of affairs does not exist. http://lists.debian.org/debian-vote/2006/04/msg00034.html That message is irrelevant because it is concerned with neither the FDL's drafting, nor the copyright law meaning of technical measures. It tells me that you don't think the FDL covers technical measures, but that seems to be because you have a personal definition of technical measures based on dictionaries rather than the bad laws. I was addressing your question as you stated it. You did not use the term technical measures. That term refers to a legal instrument which has become available to copyright holders. You did use a term which was similar to some [non-legal] dictionary definitions of the phrase technical measures. If my response was irrelevant, this seems to be because I was responding to something you wrote which was also irrelevant. -- Raul
Re: GR proposal - Restricted-media amendments to the DFSG
On 4/12/06, MJ Ray [EMAIL PROTECTED] wrote: Raul Miller [EMAIL PROTECTED] On 4/11/06, MJ Ray [EMAIL PROTECTED] wrote: Nevertheless, neither of us would be made happy by a detailed repeat of it on -vote. You'd remain unconvinced and I'd be annoyed by the lost time. Your comment, here, does not agree with the meaning conveyed by your April 7 comment: I keep asking why some people claim that the FDL wasn't drafted to prohibit all copy-control measures, as that seems to be a crucial question in this, and nobody answered yet AFAICT. You might claim that you're not satisfied with the answers, but that's not what you did claim. It agrees fine. Your messages are replies, not answers. So much is left unexplained in that reasoning and there's no suggestion that it has much to do with the drafting, rather than the interpretation by some FDL-fans. That's unnecessarily elliptical. Your question, as stated, asks for an explanation for a state of affairs which does not exist. I find it relatively trivial to show that this state of affairs does not exist. http://lists.debian.org/debian-vote/2006/04/msg00034.html You are never going to get a satisfactory answer for why something exists when it does not exist. The best you can hope for is replies. -- Raul
Re: GR proposal - Restricted-media amendments to the DFSG
On 4/11/06, MJ Ray [EMAIL PROTECTED] wrote: Raul Miller wrote: I was not convinced by this rebuttal. Nevertheless, neither of us would be made happy by a detailed repeat of it on -vote. You'd remain unconvinced and I'd be annoyed by the lost time. Your comment, here, does not agree with the meaning conveyed by your April 7 comment: I keep asking why some people claim that the FDL wasn't drafted to prohibit all copy-control measures, as that seems to be a crucial question in this, and nobody answered yet AFAICT. You might claim that you're not satisfied with the answers, but that's not what you did claim. Furthermore, I'm not sure what issue(s) you feel references are needed on. The drafters' intentions and beliefs as to what is actually covered by the prohibition, not just its primary target. It seems the drafters share your sentiment about wasted time. In any event, they do not seem inclined to discuss the issue here. I will agree that the GFDL does contain a prohibition on using certain copy control measures in certain contexts, but I see no reason to agree that it was written to prohibit all copy control measures. Maybe it's enough to agree that the boundary is unclear. I thought the issues I raised in my previous message were quite clear. Please do not cc me if you send to -vote, or at least mark it as a cc! My apologies -- I hit the wrong reply button. I tried to abort and resend to the list, but it looks like two independent replies went out. Thanks, -- Raul
Re: GR proposal - Restricted-media amendments to the DFSG
On 4/10/06, MJ Ray [EMAIL PROTECTED] wrote: Raul Miller [EMAIL PROTECTED] On 4/7/06, MJ Ray [EMAIL PROTECTED] wrote: I keep asking why some people claim that the FDL wasn't drafted to prohibit all copy-control measures, as that seems to be a crucial question in this, and nobody answered yet AFAICT. Power switches can be used as copy control measures. That claim has been rebutted in detail on debian-legal last month. Repeating it here does not help. You still offer no references. I was not convinced by this rebuttal. Furthermore, I'm not sure what issue(s) you feel references are needed on. As proof of the statement The FDL clearly was not drafted to prevent power switches, I offer the fact that text editors (which are a part of one of the requirements of the GFDL) are nearly universally used on machinery equipped with power switches. Do you need a reference proving that the GFDL specifies text editors as a part of its requirements? As proof of the statement Power switches can be used as copy control measure, I offer this example: I am offering copies of a GFDL'd document on a web server. People can make copies. I turn off the power on the web server. After I've turned off the power, people can not make copies. Do you need a reference showing that a web server ceases to deliver content when the power is turned off? I will agree that the GFDL does contain a prohibition on using certain copy control measures in certain contexts, but I see no reason to agree that it was written to prohibit all copy control measures. -- Raul
Re: GR proposal - Restricted-media amendments to the DFSG
On 4/7/06, MJ Ray [EMAIL PROTECTED] wrote: I keep asking why some people claim that the FDL wasn't drafted to prohibit all copy-control measures, as that seems to be a crucial question in this, and nobody answered yet AFAICT. Power switches can be used as copy control measures. If copies are being made, then flipping off the power switch prevents further copies from being made. The FDL clearly was not drafted to prevent power switches, so clearly its restrictions are more specific in nature. Perhaps you meant to be asking some other question? -- Raul
Re: GFDL position statement ballot invalid
On 2/28/06, Oliver Elphick olly@lfix.co.uk wrote: On Sat, 2006-02-25 at 17:21 -0600, Debian Project Secretary wrote: Majority Requirement Amendment B requires a 3:1 majority, since it require modifications to the Social contract, or the DFSG, both foundation documents. This makes no sense because the text of the modifications is not given. I disagree. Here are some definitions for modifications: http://www.answers.com/modifications And here's some definitions for the associated word modify: http://www.answers.com/modify In particular, note definition 1 for modify: To change in form or character; alter. Put more bluntly: the constitution does not require that the text be editted for 3:1 supermajority requirement cases. -- Raul
Re: GFDL position statement ballot invalid
On 2/28/06, Oliver Elphick olly@lfix.co.uk wrote: Put more bluntly: the constitution does not require that the text be editted for 3:1 supermajority requirement cases. Well, I am actually inhabiting the real world rather than the Debian parallel universe! I'd appreciate it if you limited yourself to saying stuff that's accurate. An amendment to a document (in the real world) always implies a change of text; that is how you can tell that it has changed. Sure -- if that option passes, the text of that option would be a foundation document. But that doesn't mean that the text of an existing foundation document is getting edited. -- Raul
Re: First call for votes for the GFDL position statement
[On 2/27/06, Anton Zinoviev [EMAIL PROTECTED] wrote: Since the way these choices are proposed to you is misleading, I have to sent this specifying message to you all. Without passing judgement, I'll note that a statement like this demands well stated proof. [...eliding background material...] When you vote, please understand, that the whole point of my proposal is that GFDL is compatible with the current text of DFSG. That is - with proper reading of DFSG, GFDL is compatible with our current guidelines. This seems a formal statement of the issue which needs to be proven. The third rule of DFSG says: The license must allow modifications and derived works. At first sight it seams that must allow modifications means that the license must allow us to make arbitrary modifications. As a matter of fact this interpretation is impossible because according to it even GPL would be a non-free license (please refer to my proposal for an explanation). This looks like an argument that the GFDL does not conflict with section 3 of the DFSG. Without passing judgement, I'll note that this does not address the other sections of the DFSG. Here's my opinion: First off, I've left out a lot of Anton Zinoviev's post. Frankly, I think a lot of it (including what I see as smear attacks on Manoj Srivastava) is irrelevant. I see a conflict between what Anton has said here and the obvious meaning of the DFSG -- not section 3 taken alone, but taking into account section 4 as well. And since this section 4 convlict has been raised, repeatedly, I think that if anyone was serious about addressing it there would be a page describing the issue -- in concise overview, and in detail -- and I think people would be posting links to that page. I think I would be in favor of a well thought out proposal for improving the DFSG -- one that starts with the goals and issues it attempts to address and works from there. (As I remember it, that's how the DFSG was originally written -- as I remember it, Debian was having problems with software that potentially couldn't be ported and there were also concerns about the need for security fixes and other sorts of maintenance.) But I don't think that we gain anything by trying to pretend the DFSG says anything other than what it says. I don't think that GRs would be useful if we had to change the truth to properly understand them. -- Raul
Re: A new practical problem with invariant sections?
On 2/14/06, olive [EMAIL PROTECTED] wrote: In every matter, it is virtually impossible to write a rule that can mechanically be interpreted to give a suitable result. I disagree. It's impossible to cover all aspects of all cases, but obtaining suitable results is entirely possible. The preamble of the GPL is also some king of invariant section: it says nothing about the license itself but has only political claims: I'll agree that invariant sections are similar to licenses. But I'll not agree that they are equivalent. But this shows at least that there can be sequence of octets which are not the software itself and must be preserved. I claim that the invariant sections is just the same: it is not part of the documentation (this is required by the GFDL) and there must be preserved. And we have no problem with maintaining things which are not the software -- in non-free. For the people who don't agree, I would kindly ask them to say if they would consider free a license which give you all the freedoms you like but must be preserved intact if this license contains a preamble of length similar to the invariant section of GFDL? I have ask the question in the past but nobody have answered because it was a facile argument. But if this argument is facile; please answer. It's true that the license associated with a copyrighted piece of software must be kept intact when distributing that piece of software. That's a fundamental requirement of copyright law. And where someone puts a political rant into an otherwise free license, we use it as-is. But the license serves a very specific role -- in free software, it is what says that the software is free. And we judge the licenses based on their content. Invariant sections do not fill this role. They fill other roles. And the license requirement that they not be removed is a restriction on modification. Modifying the DFSG to explicitly allow invariant sections should be pretty simple, right? The trick would be making the modification narrow enough that it won't come back to bite us in a few years. The other objections of the GFDL (DRM, etc...) is based on a bogus reading of the GFDL. Whatever bogus means in this context... ...and, nevertheless, this is a reading which is could be legally valid. This restriction should instead say something like When distributing the Document, you may not use technical measures to obstruct or control the rights of other people to read or further copy the copies you make or distribute. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/10/06, Steve Langasek [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 11:37:59AM -0500, Raul Miller wrote: And, likewise, you can't argue that the secretary must treat an option as accepted when preparing the ballot. Treating controversial general resolution proposals as if they'd already won the vote before the vote begins would be the very abuse of power you're alluding to. So by this reasoning, is the original GR proposal not controversial, whereas the other two amendments are? What's the key difference, if it isn't that the Project Secretary thinks one is correct and the others are not? Rather, the controversial elements of that option does not conflict with our historical interpretations of the DFSG. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/10/06, Anthony Towns aj@azure.humbug.org.au wrote: I didn't say anything about the ballot options being ignored -- I said the constitution doesn't say anything about ignoring foundation documents -- ie the social contract or the DFSG. We're actually doing that right now in a sense, by continuing to leave bugs like #199810 unfixed. So stick it in non-free for unstable, until the issue gets resolved. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/11/06, Glenn Maynard [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 03:21:57PM +1300, Nick Phillips wrote: The vote is not a means of rescinding the DFSG or SC, nor even of contradicting them. It is the *only* means we have of determining whether something is in compliance with them. If a majority say that that is the case, then for our purposes, it is so. This is silly. It seems like the constitution effectively says if the resolution passes it required a simple majority; if it failed, it needed 3:1. The only silliness is the verb tenses. Once some concept passes supermajority it doesn't need to pass again, because it has already passed. The real problem here is that the option in question uses poor grammar. For that reason alone, I think this option would be bad for the project. It's already spawning arguments because people think they agree with the option, but it's not clear what agreement with the option means. Fortunately, or unfortunately, our resolution mechanism for this kind of problem involves voting. Personally: I am reasonably confident that most of the developers will vote against something like this: where the grammar of the proposal is so poor that it spawns grammar based arguments about what it would mean if it were accepted -- before it's even voted on. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/10/06, Anthony Towns aj@azure.humbug.org.au wrote: Personally, I'd rather the secretarial role be as automatic as possible, even to the point where votes would be run without any human intervention. I've thought about that before, but I don't have the inclination to write any code for it. I don't know what this means. In general, humans are capable of understanding what is meant by a ballot option, while machines are not. I don't think incomprehensible ballot options are very useful, and we're already pushing that envelope. -- Raul
Re: GFDL GR, vote please!
On 2/11/06, Anthony Towns aj@azure.humbug.org.au wrote: Branden, under 4.2(4) you're empowered to vary the minimum discussion period of 2 weeks for this vote by up to one week; given the discussion The minimum discussion period is a lower bound on the time for the discussion. It's not an upper bound. Casting a discussion about when the voting should begin in terms of changing the minimum discussion period seems misleading. -- Raul
Re: GFDL GR, vote please!
On 2/11/06, I wrote: Casting a discussion about when the voting should begin in terms of changing the minimum discussion period seems misleading. P.S. I also think that the minimum discussion period is the minimum discussion period for a resolution or an amendment. P.P.S. I also think the Secretary also has the right to separate options into multiple ballots, should that be required. I don't think that that's called for in the current situation. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/11/06, Simon Richter [EMAIL PROTECTED] wrote: The problem case is where the option has majority, but fails supermajority. Another problem case is where we pass a GR that expresses some judgement about past events. For example, imagine a GR that says we have never received any spam. If that passes, what would it mean? Would it mean that the things we received which we thought were span are not in fact spam? Would it mean that the people who received spam are not part of the we in question? Would it mean that the spam was inflicted on us, rather than received by us? Fundamentally, a GR is a proposal which we accept. It can only change the future. We can't change the past, and we should not pretend that we will try. We should not be trying to hide past mistakes, even when we really think that they are mistakes. It could then be argued that since it has majority, it constitutes proof that there should never have been a supermajority requirement and thus the simple majority suffices, or it could be argued that it failed supermajority, hence modifies a foundation document, hence requires supermajority. And it *will* be argued, no doubt. Please notice that you used the phrase should never have been. If we avoid trying to claim that we can change the past, I think the first part of the above becomes: It could be argued that if an option receives a majority of the votes preferring it to all option then a supermajority requirement for that option was a mistake. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Feb 09, 2006 at 05:18:18PM -0500, Raul Miller wrote: On 2/9/06, Anthony Towns aj@azure.humbug.org.au wrote: As it happens, it says nothing about implicit changes to foundation documents, or even about having to act in accord with them. Section 4.1.5.3 seems to say something about this issue. It doesn't use the exact words you've used, but the meaning of the words it does use seems more than adequate. It says how the documents can be superceded or withdrawn; it doesn't say anything about ignoring them outright, or changing the way they're interpreted. That's a strawman argument. The ballot options are not being ignored. Manoj is not leaving them off the ballot. The 3:1 supermajority issue is only relevant for options which are not being ignored. And Manoj is not changing the option. The option in question is making a statement about the DFSG. It says GNU Free Documentation License protects the freedom, it is compatible with Debian Free Software Guidelines. But until the option has been accepted as a successful GR, the proposal is not something we as a project have agreed to. If it passes, then it will be true that this issue isn't a 3:1 supermajority issue, but if it does not pass then this will not be true. If it was true for us, without us having to vote on it, the this wouldn't be an issue I think it's a mistake for Manoj to have taken on that role in this case, but it's his choice. And that seems to be the right choice. I certainly would not want the secretary acting as if controversial proposals were a true of the project goals before they had been voted on. As far as the outcome's concerned, though, I don't think it matters either way -- I think Anton's amendment has received more than enough discussion that it ought to be voted above Further Discussion, and I think it's far better for us to decide what we want to do based on what we want and what we think, rather than attacking each other. I agree that voting on this issue is the best way to resolve it, and that attacking each other is not a good way of resolving anything. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Christopher Martin [EMAIL PROTECTED] wrote: To impose the 3:1 requirement requires, beforehand, a judgment concerning the DFSG. Since no one has found a Secretarial basis for that power, it follows that to arbitrarily impose 3:1 supermajorities (when doing so on the basis of a personal interpretation of the DFSG) is not proper. That the 3:1 bit is mentioned in the constitution is quite irrelevant. All debian developers are required to understand and apply the DFSG -- the DFSG is critical to Debian. You don't need special powers to understand and apply the DFSG. Package maintainers are supposed to make judgements about the DFSG in the context of their packages. The same goes for the Secretary in the context of preparing the ballot. You can't argue that since the constitution doesn't explicitly forbid the Secretary to take it upon him/herself to interpret the DFSG for everyone else, that therefore he/she must do so, in order to discharge the constitutional duty of placing 3:1 supermajorities on amendments, etc. That's backwards. Essentially you'd be asserting that any delegate has _any power_ he or she deems necessary to fulfill his or her view of their own constitutional duties, unless explicitly forbidden, item by item, by the constitution. That's not my argument. And, likewise, you can't argue that the secretary must treat an option as accepted when preparing the ballot. Treating controversial general resolution proposals as if they'd already won the vote before the vote begins would be the very abuse of power you're alluding to. Because that's the only way I can see for getting from the constitution mentions that some votes should require 3:1 supermajorities to therefore the Secretary must be the constitutionally ordained arbiter of DFSG correctness for all votes. And this despite other constitutional verbiage that suggests that developers have that power. Huh. The Secretary is a developer. Indeed, section 4.1 states that the developers, by way of GRs or elections, have the power to issue, supersede and withdraw nontechnical policy documents and statements. These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. They may also include position statements about issues of the day. The GFDL sounds like an issue of the day to me. Sure, and the constitution goes on and lists the procedure the developers follow when doing these things. And we're following those procedures. So where's the problem? The problem is that in the course of this procedure, the Secretary overstepped his authority, as I've explained above. You may not agree with that view, but I don't see why you should be so confused about my complaint. I've yet to see any description of your complaint that doesn't require me to accept that Anton's proposal is universally accepted by the project. But if I accept that Anton's proposal is universally accepted by the project, then the barrier you're talking about does not exist. So I'm faced with a contradiction: how can the Secretary be mis-using his power if this mis-use of power can only be a mis-use if it is not a mis-use? -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Anthony Towns aj@azure.humbug.org.au wrote: On Wed, Feb 08, 2006 at 08:58:39PM -0800, Thomas Bushnell BSG wrote: It's not about honor; it's about decision-making. When you raise the implication that your fellow developers can't be trusted, you make it about honour; when you think it's important to move a decision from one set of hands to another in order to ensure the right decision is made, that's a pretty direct implication that you don't trust the first group. Is this courtesy to be extended to the project secretary? If not, why not? If a majority sincerely believe that their proposal does not run afoul of the 3:1 requirement, does that mean that it therefore does not? If the secretary sincerely believes the proposal has a 3:1 requirement, does that mean it does? I think you're better off looking at the constitution, personally. This seems to be a moot distinction, given that the constitution says that the secretary is the judge in disputes about what the constitution means. (section 7.1.3) As it happens, it says nothing about implicit changes to foundation documents, or even about having to act in accord with them. Section 4.1.5.3 seems to say something about this issue. It doesn't use the exact words you've used, but the meaning of the words it does use seems more than adequate. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/8/06, Nick Phillips [EMAIL PROTECTED] wrote: On Wed, Feb 08, 2006 at 11:50:51AM -0500, Raul Miller wrote: If the GR is adopted by Debian, there is no significant difference between contradicts the foundation documents and modifies the foundation documents. First of all, you're assuming that it does contradict the foundation documents. It clearly asserts otherwise, and one might assume that developers voting for it would agree with that. If it won a majority, it would therefore seem to be the case that the majority of developers agreed with it. In which case those asserting that it needed supermajority wouldn't have a leg to stand on. So we'd be in a right mess. That would be a moot point, not a contradiction. Second, you're completely wrong. Of course there is a difference between modifying the foundation documents and appearing to contradict them. One modifies them and the other, well, doesn't. This can only be true where appearances are deceiving. -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Christopher Martin [EMAIL PROTECTED] wrote: Please cite the part of the constitution which grants the Secretary this extraordinary power. Despite what Raul Miller repeatedly asserts, a minor power to decide issues of constitutional interpretation in cases of deadlock DOES NOT mean that they have the power to interpret the DFSG, since the DFSG is not the constitution. Repeatedly asserts? I think, if you check my assertion, it included a direct reference to the text of the constitution that I was referring to. If you think I'm wrong, perhaps you could say specifically what it is about what I wrote which conflicts with that part of the constitution? Note also that the 3:1 supermajority requirement is not a part of the DFSG. So your explicit claim about DFSG interpretation being out of scope for the secretary doesn't seem to provide a basis for your implicit claim that the secretary does not have the right to impose the requirement on some of the options in this vote. Indeed, section 4.1 states that the developers, by way of GRs or elections, have the power to issue, supersede and withdraw nontechnical policy documents and statements. These include documents describing the goals of the project, its relationship with other free software entities, and nontechnical policies such as the free software licence terms that Debian software must meet. They may also include position statements about issues of the day. The GFDL sounds like an issue of the day to me. Sure, and the constitution goes on and lists the procedure the developers follow when doing these things. And we're following those procedures. So where's the problem? -- Raul
Re: Amendment to GR on GFDL, and the changes to the Social Contract
On 2/9/06, Christopher Martin [EMAIL PROTECTED] wrote: But why does the Secretary get to decide whether this barrier should be set or not? The constitution says: ... the final decision on the form of ballot(s) is the Secretary's - see 7.1(1), 7.1(3) and A.3(4). I think that's pretty clear. Also, you might want to read the references it lists. I think it's pretty clear here that the Secretary is not exceeding his powers in any way, shape or form. -- Raul
Re: Anton's amendment
On 2/1/06, Manoj Srivastava [EMAIL PROTECTED] wrote: Could some one tell me why including the invariant sections of a GFDL licensed work in main would not require us to modify the DFSG or the social contract? I think it's clear that the DFSG would have to be modified. If nothing else, the DFSG's may restrict ... _only_ clause does not allow include this case, because patches which would change invariant sections at build time are not allowed. More literally, the answer to your question seems to be: No, not meaningfully. On the other hand, we've had strong majorities for good suggestions in the past. So DFSG would have to be modified should not be considered an obstacle -- we just have a somewhat stiffer requirement that the idea be a good one. -- Raul
Re: followup to my time-management question
I wouldn't wait longer than a week after your initial post to pose such surrogate answers. On Wed, Mar 23, 2005 at 09:57:14AM -0800, Thomas Bushnell BSG wrote: I won't do this. I'll do it just before the end of the discussion period instead of just after, if that's a new rule for non-candidates. (Though, note, Manoj's email said that the rule only customary anyway, and only for the candidates.) Roughly a week is a good guideline, I think. You're right that it's not any kind of hard and fast rule. The point is to expect and require the candidates to give their *own* straightfoward estimation of their work, and not just say hey, you got me wrong here and here. I want the candidates to say, I did this well, I did that poorly, etc. Well... one issue here was that your question was very similar to another question, which the candidates answered. You felt that that was inadequate, but waited until it was far to late to before you even hinted that this was an issue for you. Anyways, please do NOT take my suggestions as any kind of formal requirement. I was making suggestions, and was not handing down laws. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: followup to my time-management question
On Tue, Mar 22, 2005 at 05:11:28PM -0800, Thomas Bushnell BSG wrote: So, rather than beat a dead horse, since I intend to ask the same question (or much the same question) next year, what should I do differently? Ideally, you should ask your question(s) at the begining of the campaigning period, or maybe immediately before, rather than half way through. If you're going to be providing answers for people who don't respond to your satisfaction, do this as soon as possible, rather than waiting for the voting period to start. I wouldn't wait longer than a week after your initial post to pose such surrogate answers. Or, if you've jumped the gun and asked during the nomination period, no more than a week after their nomination. It's simpler and probably better to just stick to the campaigning period for qa treatment of your issues. If you do feel it necessary to add coments after (or immediately before) the voting period has started, they should be wrapped in heavy disclaimers. By definition, comments introduced in the voting period are comments made after the campaigning period has ended. Read the Secretary's announcements for more clues. Jeroem van Wolffelaar's suggestions (http://lists.debian.org/debian-vote/2005/03/msg00010.html) might also be helpful. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: followup to my time-management question
On Mon, Mar 21, 2005 at 02:27:12PM -0800, Thomas Bushnell BSG wrote: way. If candidates felt that by ignoring my question they wouldn't need to explain their records in detail, they were incorrect. Between Feb 6 and Mar 19, you sent 74 messages to debian-vote, around half a megabyte of text. (For comparison, a number of popular books, written for adults, weigh in on the shy side of 150Kb -- you've written as much content here as is contained in some trilogies). So, anyways, I tried grepping for your original question, and I was not able to find it looking for substrings such as past or project. I did eventually find your post -- Date: 12 Mar 2005 04:27:47 -0800, Message-id: [EMAIL PROTECTED]. In other words, after you had written three fourths of your material. And you did not indicate that you were less than satisfied with the form of any candidate's answer until it was no longer appropriate for them to respond to you. Honestly, if the question was as important to you as your current attitude seems to indicate, I'd think that you would have attempted to express importance of the form of the answer you were expecting for this question a bit better. Basically, you've demanded that every candidate read every word of your posts, and (up until just recently) you've treated this particular issue as considerably less important than the other issues you were writing about. One candidate got lucky with you, and good for that candidate. But please don't pretend that you're being fair here. Unbiased? Maybe. But not fair (nor reasonable). Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Aliases for /dev/null: Clarification about krooger's platform
How can the tech-ctte override a developer by not acting? On Mon, Mar 07, 2005 at 10:55:21AM -0800, Thomas Bushnell BSG wrote: No, the question is whether a developer (by never acting) can avoid tech-ctte review of his work. What work? A developer who never acts would have no work to review. The technical committee would thus never have any reason to override any decisions this developer made -- because there would be no such decisions. In general, a developer who ensures that changes are made in a backwards compatible fashion is not likely to cause problems where the technical committee has to step in. But that's not never acting. Sometimes that means taking a great deal of action. There is another side to this (the clean up cruft side), but mostly debian developers are competent enough that they don't create technical conflicts. [Not entirely -- it could be argued that Sarge is taking so long to release because of technical conflicts, but these tend to be more of we need to figure out what to do than A says we need to do X and B says we need to do Y, but we can't do both X and Y.] All you have to do to avoid the tech committee stepping in is make sure your problems get resolved reasonably. Most people seem to be able to do this. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Aliases for /dev/null: Clarification about krooger's platform
Raul Miller [EMAIL PROTECTED] writes: What work? On Sun, Mar 20, 2005 at 02:46:17PM -0800, Thomas Bushnell BSG wrote: I have in mind, for example, the ifupdown script. The maintainer has not made a maintainer upload for years, and so maintenance of the package has been proceding by NMU. But NMUs cannot do more than fix a few kinds of crucial bugs. It is clear that the maintainer doesn't want to maintain this package and has had other priorities for a long time. There is nothing wrong with this. Other people have volunteered to maintain the package, and been rebuffed or ignored. As described, this is an administrative issue, rather than a technical issue. However, you strongly imply that technical issues exist. For the technical committee to weigh in on this, the interested parties would need to speak up (the constitution says so, and it makes sense). You don't have to have multiple parties speaking up, but the people that want action do need to lay out what the technical issues are. There's a huge amount of ground that could be covered at by a script like ifupdown -- there's no reason to not have alternatives for it. No reason, except that involves work. Beyond that... since you've not actually stated any technical issues, and since the maintainer of that package is one of the DPL candidates, I think you should make an effort to be clear about what you're saying here. There can be good reasons for leaving a package with NMU'd fixes (for example: if the maintainer has no way of testing the fixes, and has had no reason to upload changes for any other reason). Anyways, the technical committee is for resolving technical conflicts, and so far you've not specified any unresolved technical problems. You've mentioned administrative issues, and you've hinted at technical problems, but ... ... but ifupdown does not seem to me to be an example of how a package maintainer can avoid the technical committee by not acting. If there were actions the technical committee needed to take, inaction on the part of the package maintainer wouldn't prevent the technical committee from reaching a decision. Does that make sense? Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Aliases for /dev/null: Clarification about krooger's platform
On Sun, Mar 20, 2005 at 03:26:23PM -0800, Thomas Bushnell BSG wrote: My question is: when there is a technical issue, but one developer refuses to discuss it with tech-ctte or anyone else, can tech-ctte get involved? Yes. It does, but I recall in the past being told that tech-ctte doesn't get involved unless both developers in a dispute agree there is a dispute worth the tech-ctte's decision. That's a good heuristic, but not an absolute rule. If there's no technical conflict, there is no reason for the committee to be involved. If there's a conflict, but one of the developers is inactive, that could be a situation where the committee needs to get involved (but typically the result there would be an orphaned package, so this isn't a particularly likely situation). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-women obscurity, was: Clarification about krooger's platform
Raul Miller [EMAIL PROTECTED] wrote: [Note: I originally posted this to another list -- thinking this whole debian-women thread was off topic for debian-vote. M.J. Ray indicated only that he thinks debian-vote is the appropriate list, so I'm reposting it here, with minor edits.] On Sun, Mar 13, 2005 at 12:22:49AM +, MJ Ray wrote: What a load of cobblers. The another list was curiosa and I indicated I'm not going to discuss this right now with someone who thinks exclusion and discrimination are funny. There's a difference between a topic as a whole, and a sub-thread which does not appear to be going anywhere useful. If this thread were about proposing balanced gender representation across the site as a whole, I could agree that my attempt to divert this thread elsewhere was inappropriate. So far, I've not seen you make any such proposal. And, personally, I think that such a proposal would probably be either ineffective, or inappropriate, given the volunteer and dispersed nature of Debian. As a general rule, the way to get things done around here is to do them yourself. You're the one who seems confused, thinking that pointing and laughing that sex is an action too is on-topic. I specifically pointed out that I was ignoring that interpretation because it was a false implication. If you read laughter into what I wrote, it wasn't mine. Finally, you are all too willing to claim you don't understand the reasoning, yet attribute spurious reasoning to me, which isn't surprising, given your past anatagonism. I have made that sort of claim, at times (for example, when faced with a sentence structure that seemed garbled). However, that was not my claim, in the message you are responding to. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian-women obscurity, was: Clarification about krooger's platform
Amaya [EMAIL PROTECTED] wrote: [...] [...] As there's is absolutely no seggregation in the debian-women environment, men can benefit, and I'm sure *do* benefit, from this wellcoming climate too. On Wed, Mar 09, 2005 at 11:52:50PM +, MJ Ray wrote: Is a bus with a whites-only section at the front segregated? Is a bus with a white person sitting in a seat segregated? I guess I hope you can see some of the differences, between a web page, a bus, and a bus seat. One of the issues with a bus is that there tend to be more fumes in back than in the front. But the big difference is that the distance you have to walk to the back of the bus is quite a bit further than the difference you have to walk to the front of the bus (given that you're getting on, at the front), and there was this one little old lady who sat down at the front of the bus, after she got on. The results of that choice are what you're presumably referring to when you talk about a bus with a whites-only section at the front. And, personally, I really don't see the relevance in the context of this web page. If you're tired, and want to just get stuff done, don't you have your own web pages? It's not like you have to get on someone else's web page to go somewhere. It's not like this web page is forcing you onto some other server, or stealing bandwidth you could have been using on the same server. Really, it is simple to make the debian-women project not segregated, but it seems clear from http://lists.debian.org/debian-women/2004/08/msg00100.html that segregation is intended for some parts. Why wouldn't profiling friendly male contributors help? I think you're confusing that project with a web page. Anyways, if you want to profile friendly male contributors, I think you should go ahead and do so. But the kinds of segregation you're talking about has little to do with the sorts of unfair segregation you're alluding to. I think you should be fair about this -- either bring up a specific concrete problem where someone is being injured, or admit that you don't have any such issue in mind. You didn't put the people I want on your page sounds more like the whining of a petulant child than a serious issue. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Aliases for /dev/null: Clarification about krooger's platform
To: debian-vote@lists.debian.org This is why I suspect ftpmaster is a particular instance of some more general problem. At the moment, is there a constititional loophole that one can avoid tech-ctte overruling one (the only time complaints are mentioned) by never acting? I'm having trouble understanding this question. How can the tech-ctte override a developer by not acting? To override decisions made by individual developers, a number of very specific requirements need to be met. (Typically: a technical issue which isn't clearly within the scope of an individual developer, where the developers do not agree on how to resolve the problem, and where a significant majority of the technical committee do agree on how to resolve the problem). [That aside: people complain about things in general, and the technical committee in specific, on a far broader range of topics than overrulling one. But given that I might have completely misunderstood what's being asked, I'm not sure if this is relevant.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Sat, Jul 17, 2004 at 07:00:58AM +0200, Goswin von Brederlow wrote: Is this purely because of linking problems with shared libraries, or is there some other kind of need to support two diferent instances of the same application? Its a problem with avoiding archive bloat through biarch capabilities in dpkg. You end up with multiple /usr/share/doc/package/copyright files. You seem to be answering a question I'm not asking. Again, see past discussions. Which ones, specifically? Can you tell me why you think mixing 32bit and 64bit isn't a solvable problem? Because you won't get upstream to accpet patches and the same probably goes for the Debian maintainers for binutils and gcc. In other words, you'd have to fork those packages until the issues got resolved? You will always get the warnings there which I feel is unacceptable since its avoidable. Then leave that as a known bug until multiarch is ready. Doesn't sound like a showstopper for biarch. Or, if it is too annoying to tolerate, then it's worth addressing. For example, I can do without multiple instances of the same package under the same name for different architectures -- for the few important packages I have to have side by side, giving them new names and manually sticking them somewhere else is not that big a problem. You've already been doing this for IA32. That is what ia32-libs is doing. But its only ment to support thrid party binaries and not for ia32 debian packages. That's half the issue. Have you made a biarch package yet? If not, please do that and come back when you have. It's painful, to do it the right way. What do you mean by the right way? And, why is that way right? In a way that has a minimum impact on the tools and sources. The les that needs to be changed and the simpler the change the better. Like asking dpkg where libs should end up and using that as a variable instead of just replacing lib/ with foobar/ (as an example). Why does this need to be in dpkg? For contrast, what's wrong with some table represented in some file in /etc/? 'dpkg-buildpackage -aamd64' and 'dpkg-buildpackage -ai386'. Remember, you are aiming for multiarch support so the right arch/path is nothing fixed. Let me ask that question a different way: what's the sequence of events leading up to the point where dpkg-buildpackage -a works? Or do you expect that -a has to work before any other multiarch work can be done? I personally can probably live with LSB compatability for 32 bit, instead of LSB compliance. Maybe. Do you need to build libraries under debian to be used on a non debian amd64 LSB compatible system? Because that is the only thing breaking (the deb file contains the lib in the wrong dir) we know of. Me personally? No, I don't need that. But that's not the only thing breaking. For example, upgrade from i386 is broken. Which is sad. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Sat, Jul 17, 2004 at 03:33:17PM +0200, Tollef Fog Heen wrote: You're jumping through a lot of hoops to get to somewhere which is a bit like multiarch, but not quite. And you'll end up with something less capable, more ugly and a lot more work to support properly when upgrading to multiarch. Doing the full dance is less work. You don't know that. Multiarch isn't designed yet. [That's why some of my questions about what's what get answers like read these email discussions.] You're claiming, for some reason, that amd64 needs to prepare for multiarch migration in some other way than our 11 other architectures because you think that the amd64 porters should support solving problems for sarge a way none of the porters are willing to solve for sarge. There's no need to get so excited about this. I never claimed that those porters had to do that work. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 05:16:10AM +0200, Goswin von Brederlow wrote: The only thing special for amd64 is that at some point the /lib64 - /lib link might (or might not) be turned back into a real directoy. But that can/will only happen if it can happen silently without disturbance. Which means it's probably not going to change. This is an easy choice up through system install time, but a tough one upgrade time. No, the only thing referencing lib or lib64 is the ld.so. I thought you were building packages which referenced /lib, because the effort of changing them was too high? In other words, that dpkg -L would list files in that location. The changes to make the uniarch - multiarch transition go smoothly and in one release, while applying to amd64 too, are completly seperate to the issue and have to make the transition smoothly for i386, ppc, s390, mips, mipsel and sparc. Amd64 is just on of the affected archs and does in no way change the timeframe. Except, amd64 should be a biarch - multiarch transition, not a uniarch - multiarch transition. The change for /lib (as proposed by multiarch) is also going to happen for all architectures regardless if the architecture supports multiarch or if multiarch support is wanted. All architectures will move the libs from lib/ to lib/arch-kernel/. As an aside, I thought the dest was arch-kernel/lib/? I can guarantee you'd get more support for a 64/32 bit system than a pure 64 bit system. [As in, I'd contribute.] Then why don't you? The biarch proposal have been around longer than pure64 and multiarch (its successor so to speak) is still there. It might be that the only reason I have not is that I've mis-understood the current state of affairs. I'm still trying to understand your plans. [*] amd64 binaries can't be built from the sources in main, and Because there is no amd64 in main. There are no amd64 binaries in main. I'm talking about sources. [*] lack of a clear upgrade path to 64/32. That is as unclear (and not wanted for before sarge+1) as for all the other multiarch archs. See above for some clarifications. I'm glad you told me about how ld.so supports the transition. I'd forgotten about ld.so's role at execution time and hadn't realized how it would help. I'm still concerned about the physical aspects of managing the files. Ia32-libs includes X and even some GTK libraries. If you need more support we can certainly add more libs. But show us the need first. The ia32-libs package has been used on ia64 for some time and they didn't seem to need more libs in general. I'll check it out. If i386 debian can get screwed up by a chroot, what makes you think that amd64 debian would not? Because all the buildds run in chroots and most amd64 porters use chroots. Chroots have been well tested and the remaining problems should be very rare and jus as likely to appear on any arch. The buildd aspect helps. I still think this one needs more testing. And that's aside from problems like ok, I've got my 64/32 environment running X, and now I want to run a debian X app inside a chroot cage. Then you just do it and it works or you go and read the FAQ explaining you how to setup a chroot (which you should have done in the first place). Ok, let's consider the howto for a moment. Let's say I'm installing something like openoffice, but I want the 32 bit /etc/mime.types to use my 64 bit gimp when displaying images. How do I configure this? If ftp-master says we will add amd64 only when dpkg supports it you can be sure that the support will be there on the next dinstall run one way or another. Ok. Maybe if we can put to rest the 32-64 bit transition planning issues, ftp-master will speak up on this other one. And note that this is completely independent of buy-in issues, like the future of 32 bit support (which is the issue which was raised in #248043). Which have been explained and resolved or not? Not completely. But your explanation did clear some things up for me. PS: Most people don't see a future for 32bit support for amd64. Like noone uses 16bit windows apps anymore. By the time sarge+1 comes out you probably won't find a current application with just 32bit support. Contrast eventually, I won't need this app anymore because I'll be using a 64 bit version and there's a 64 bit version of this app, but it costs tens of thousands of dollars, so I'm using the 32 bit version -- despite its lameness -- for now. Both statements can be true. The value of 32 bit support is at transition time, and that's decided on a program by program (or package by package) basis for each user. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
If you don't provide a dual 32/64 bit amd64, your transition strategy is going to be install it on a different partition or backup, wipe and reinstall. On Fri, Jul 16, 2004 at 09:14:25AM +0200, Goswin von Brederlow wrote: That is the plan and the current implementation. As such pure64 has succeeded and fullfilled its expectations. There is no and never will be a transition plan from i386 to amd64. That is just not possible. You can't replace dpkg since then it lacks its libc and you can't replace libc since then dpkg lacks the old one. And so on for every other essential package. You could install a biarch glibc which supports both 32 and 64 bit dpkg. And I see nothing in the multiarch spec that makes migrating from a /lib64+/lib system any more difficult than migrating from a /lib system. Correct. Hence pure64 doesn't make the transition more difficult. As long as you're willing to provide a biarch glibc in pure64, I'd have to agree with you. What I don't see is any sane reason to not start out from a /lib64+/lib system. Maybe there is one, but telling me how it's clear to you what I have or haven't though doesn't convey any specifics to me. /lib64 requires at least 2000 source packages to be changed. For the details on those numbers see the biarch proposal discussions. But they don't all have to be changed right away. If we ever did get into a situation where everything has to change at the same time, we'd have a system we couldn't upgrade. Which seems to indicate to me that multiarch has no problem absorbing /lib64/. And you seem to be implying that asking for /lib64/ on amd64 is a bad thing to ask -- if that's not what you're saying, please try again. One doesn't change the other. Changing lib - lib64 is a lot of work and not possible with sarge pending. Any such changes are going to have to happen on a package by package basis anyways. [And, as for clean upgrade, just make the packages optional, and give them a Conflicts: task-amd64-multiarch-upgrade or some such and they'll be fairly easy to clear out of the way when the time comes.] Violates policy. Priorities must match with the Depends. We're talking about mixing architectures here. We've not yet developed formal policy for mixed architectures. http://alioth.debian.org/docman/view.php/1314/21/debian-amd64-howto.html I agree it's possible. But it's quirky. [And, tedious, when you have a lot of such apps.] Its one entry in your etc/fstab. Doesn't get more work for more apps. That depends on how you're using those apps. What the pure64 people said is that we don't even want to support 32/64 bit. And the outstanding bug report to ftpmasters has support 32/64 bit during the transition as the issue they've raised. We acknowledge the possibility and keep all possible ways open to add it at a later time (sarge+1 with multiarch) but for now we realy don't care. Except, it's when people are moving from 32 bit intel systems that 32/64 has the most value. That said, it doesn't have to be beautiful we support every 32 bit debian package. It just has needs to be of the form we support 32 bit forms of the base system such that anyone who needs to add 32 bit support for some other package has a way of doing so. Perhaps you've already got this, but you seem to be claiming otherwise. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 09:25:22AM +0200, Goswin von Brederlow wrote: No. You obviously never tried or read the mails about it. If you don't have lib64 - lib linked you get lots and lots of random breakages and misbuilds. In effect you have to touch and fix all 2000+ library packages. There is no such thing as just fix the base libs. We're obviously talking about two very different things. I'm talking about enough 32 bit support that it's possible to install and run more 32 bit packages after upgrading less important debian packages. If we have to have every package fixed before we fix any of them, we'll never get anything fixed. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 09:31:39AM +0200, Goswin von Brederlow wrote: apt-get install dchroot cdebootstrap read FAQ I've already raised this in another message, but how do I make 32 bit userland able to use 64 bit programs? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 10:53:02AM +0200, Tollef Fog Heen wrote: | Last time I checked [two days ago], the trivial change to dpkg to support | amd64 hadn't happened. I think making sure that the debian package tools | work right for the architecture should be considered pre-requisites for | using the package system to present the rest of the packages. http://cvs.debian.org/dpkg/archtable.diff?r1=1.21.2.11r2=1.21.2.12only_with_tag=v1_10cvsroot=dpkg I checked by installing the most recent dpkg, grepping its files for the strings amd64 and x86_64 and looking in the pool directory to see that there weren't any more recent versions available. I didn't check for a more recent upload. [I agree that this is a fairly minor and easily fixable issue. But it's also a rather obvious one.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 09:15:47AM -0400, Stephen Frost wrote: And get every package in the archive changed and updated for it .. This (every package changed) doesn't have to happen until multiarch is ready. [Before you explained about multiarch, my only objection was the lack of 32 bit LSB support.] That's not going to change. If ia32-libs works well enough for you, then great, if not, too bad. As long as the architecture allows me to fix bugs that are problems for me, I'm happy. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
You could install a biarch glibc which supports both 32 and 64 bit dpkg. On Fri, Jul 16, 2004 at 03:20:43PM +0200, Goswin von Brederlow wrote: Which would be a completly new glibc package adding extra bloat to the already streesed mirrors. We're talking about something several orders of magnitude smaller than what it will take to add the amd64 port to the ftp master. If we ever did get into a situation where everything has to change at the same time, we'd have a system we couldn't upgrade. They have to if you want sources to still be buildable (with configure defaulting to lib64 and all). And I think releasing debs with sources that don't compile on the arch itself (but have to be crosscompiled) is out of the question. You get some unpredictable errors from configure scripts or dpkg-dev utils errors that you only notice because the next package fails to get the right Depends and such. It has more problems than are obvious. Any such changes are going to have to happen on a package by package basis anyways. Did I mention that gcc/binutils will complain about any library not matching the ABI unless lib and lib64 are seperated completly, i.e. all lib packages are ported. I think that alone makes a partial port unsuitable for release. I'm not sure what you're saying here. Are you saying that gcc won't let you build a shared library to install in /lib if glibc is in /lib64? That said, it doesn't have to be beautiful we support every 32 bit debian package. It just has needs to be of the form we support 32 bit forms of the base system such that anyone who needs to add 32 bit support for some other package has a way of doing so. Perhaps you've already got this, but you seem to be claiming otherwise. We have ia32-libs but that is just a bonus that works very well and not an intended feature. 32bit support is there, pretty much as complete as other dists have it, but it's not considered (by the pure64 port) an essential feature for the port. Its just a bonus. We know its not ia32 LSB compliant but so far it is ia32 LSB compatible (which is what you would care about as debian user). That might be enough. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
| It's fairly simple for the port to be built to support both 32 and 64 | bit LSB apps, and still allow for migration to multiarch. On Fri, Jul 16, 2004 at 06:45:17PM +0200, Tollef Fog Heen wrote: As others have said -- it's not easy to support both 32 and 64 bit. If you want to do that properly, you should implement multiarch. Please keep migration to multiarch out of the equation -- as long as you stay out of /lib/$arch-$os (i[34]86-linux, x86_64-linux), you are fine. Is it just me or are these two paragraphs contradictory? Every upgrade up till now has managed to deal with replacing files in the same directory as what the new package supplies. What is it about multiarch that makes it such a pancea for the future, and such a horrible thing to start moving towards? | [For example: Have /lib64 be a symlink link to /x86_64-linux/lib and have | /lib be a symlink to /i486-linux/lib (similar for /usr/lib*). Make sure | that the libraries explicitly mentioned in LSB are installed in the 64 | bit library, leave the others as known bugs, to be fixed when people have | the time and inclination. Make sure your patches respect some env var | (perhaps MULTIARCH_HOST), and have that be set at a fairly high level.] If you're going to do this, then why not do the full multiarch dance? Because you can't do everything at once. Also, maybe it's good to keep some distinctions in mind here. There's the system on which the packages are installed (where lib and lib64 are symlinks to multiarch lib dirs), and there's the packages themselves (which install into /lib, /lib64, etc.). If you do that, you'll end up with fixing packages once, not twice. Assuming I make no mistakes, and am capable of fixing everything at the same time, sure. I don't know about you, but I'm just not that competent. | Uh, multiarch *will* be painful. biarch *would* have been painful too. | We're not disputing that, that's why we're *NOT* asking for biarch or | multiarch to be part of sarge. Not even close. We're interested in | having pure64 released with sarge so that Debian users can use their | amd64 systems reasonably. | | In my opinion, the only thing painful about my above example | implementation is that it make the things that need to be fixed painfully | obvious. Have you made a biarch package yet? If not, please do that and come back when you have. It's painful, to do it the right way. What do you mean by the right way? And, why is that way right? | My current objections are that you're not planning for compliance with | LSB and you're not planning for migration to multiarch. Both will be | a lot easier to achieve with just a little forethought. | | [Before you explained about multiarch, my only objection was the lack | of 32 bit LSB support.] .. and the multiarch migration is independent of this and will happen for all arches, not just multiarch-capable ones. (Because even though $random_arch might not be able to run some binaries doesn't mean that $some_other_random_arch can't run $random_arch's binaries.) I've never claimed otherwise. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
You could install a biarch glibc which supports both 32 and 64 bit dpkg. On Fri, Jul 16, 2004 at 03:20:43PM +0200, Goswin von Brederlow wrote: Which would be a completly new glibc package adding extra bloat to the already streesed mirrors. Raul Miller [EMAIL PROTECTED] writes: We're talking about something several orders of magnitude smaller than what it will take to add the amd64 port to the ftp master. On Fri, Jul 16, 2004 at 08:04:32PM +0200, Goswin von Brederlow wrote: You still need and want the amd64 port. I thought you were talking about adding rudimentary biarch packages to the amd64 port? The only things which would have to be biarch, as far as I can see, are glibc, and important shared libs. If space really is that tight, you could toss the single arch versions of those libs to save a few 10s of megs of archive space. Did I mention that gcc/binutils will complain about any library not matching the ABI unless lib and lib64 are seperated completly, i.e. all lib packages are ported. I think that alone makes a partial port unsuitable for release. I'm not sure what you're saying here. Are you saying that gcc won't let you build a shared library to install in /lib if glibc is in /lib64? No. But the 64bit linker will give you stupid warnings about unknown abis in all the 32bit libs and the 32bit linked will give you warnings about the 64bit libs. Or it will link 32bit and 64bit code together and totaly screw up. Sounds like a bug. Other packages (such as file) don't seem to have make this mistake, it shouldn't be that hard to fix gcc. And configure scripts will think libs are there even if they are only there for the wrong arch and such stuff. That sounds like a bug, too. GPLed code (and anyother code which includes the full sources) could probably be fixed by upgrading autoconf and rebuilding configure. That wouldn't address every case, but leaving this unresolved sounds painful. port) an essential feature for the port. Its just a bonus. We know its not ia32 LSB compliant but so far it is ia32 LSB compatible (which is what you would care about as debian user). That might be enough. Haven't heard complains to the contrary yet. That sounds promising. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
* Raul Miller ([EMAIL PROTECTED]) wrote: On Fri, Jul 16, 2004 at 11:32:22AM -0400, Stephen Frost wrote: Do you have an example of this case? I havn't heard of one yet, not even with Oracle. On Fri, Jul 16, 2004 at 04:51:05PM -0400, Stephen Frost wrote: They're going to charge you huge amounts to use their 64bit version instead of their 32bit version? That's kind of sad, really. Makes me glad that Debian exists and that I'm not forced to use such software. Their 32 bit version is mature, and they let you use it for free for small noncommercial uses (which is how I'm using it). Their 64 bit version is a rewrite from scratch (it's not a drop in replacement -- for example, it'll be providing sql99 once all the sql minutiae issues have been addressed, where the 32 bit version has sql92). It's not a mature product, and they're only selling it to people who really need it (as in, are willing to pay a lot of money for an advance copy). Remember the differences I outlined between aplus and k? Well, it looks like the 64 bit version will be further along that same trend (about half the size, some operations such as parsing will be at least an order of magnitude fasater, etc.). At some point, there will be a large body of people with 64 bit systems, and they won't have any more customers for the 32 bit version. At that point, I expect them to gpl the 32 bit version and start handing out no-cost versions of the 64 bit version. Yeah, I could wish for a business model where they offered their product on terms I liked better. But, sad? One thing I have to admire Arthur about: he doesn't go for bloat, and has managed to figure out how to make a living doing the opposite. That said, yeah, I'm extremely glad Debian exists and that I'm not forced to use such software. But I still appreciate that that software exists. And, I do have some uses for it (tool of thought type stuff) where I've not found [nor written] an adequate free replacement. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Fri, Jul 16, 2004 at 06:19:20PM -0700, Thomas Bushnell, BSG wrote: Now there is a *different* question: should the current amd64 be in sid? I can see no reason why not, but then, I wonder why you all didn't get it in sid *long* ago. We put hurd-i386 in sid almost from the very first day. To be fair, bug #248043 was filed some time ago. It seems to me, after reading that bug, that getting the port into sid has been stalled on questions about the treatment of biarch [actually, probably more from the lack of an adequate statement of the nature of IA32 support than anything else]. There also seem to be some purely mechanical issues (for example, amount of free space on the servers). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
Is it just me or are these two paragraphs contradictory? On Sat, Jul 17, 2004 at 04:28:32AM +0200, Goswin von Brederlow wrote: Yes, its just you. Multiarch will not be an issue for sid for a long time to come. If you want it work on it but it just confuses in the GR. Why? Is this completely based on gcc can't handle linking 64 bit shared libraries when there's a 32 bit libc in the target directory? Or are there other reasons why multiarch must be more complete before you're willing to tackle biarch? Every upgrade up till now has managed to deal with replacing files in the same directory as what the new package supplies. What is it about multiarch that makes it such a pancea for the future, and such a horrible thing to start moving towards? Replacing one file with two files with the same name and path from two different packages with the same name but different arch for example. Why is this a requirement? Is this purely because of linking problems with shared libraries, or is there some other kind of need to support two diferent instances of the same application? I'm trying to see the difference between nice to have and critically important issues, and your above sentence doesn't do it for me. If you're going to do this, then why not do the full multiarch dance? Because you can't do everything at once. Also, maybe it's good to keep some distinctions in mind here. There's the system on which the packages are installed (where lib and lib64 are symlinks to multiarch lib dirs), and there's the packages themselves (which install into /lib, /lib64, etc.). You can port all packages from pure64 or i386 to multiarch while still only using uniarch. You can move the libs around to the new place one by one by having both places in ld.so's search path. What can't be done without problems is mixing 32bit and 64bit libraries in the same dir. What also can't be done is use just lib64/ because of the extra work it entails porting all the library packages. To get anything useable within a short timeframe the pure64 hack of linking lib64 and lib into the same place and only having one ABI there is the only possibility. Can you tell me why you think mixing 32bit and 64bit isn't a solvable problem? That said, you could start porting the base libs to be installed where multiarch will put them now (or to where you say) starting with either 32bit or 64bit as base without including the actual multiarch dpkg/apt support. But hey, you would still be implementing parts of multiarch. I don't mind implementing parts of multiarch, as long as I don't have to wait on something that I can't make available right away. For example, I can do without multiple instances of the same package under the same name for different architectures -- for the few important packages I have to have side by side, giving them new names and manually sticking them somewhere else is not that big a problem. You've already been doing this for IA32. Have you made a biarch package yet? If not, please do that and come back when you have. It's painful, to do it the right way. What do you mean by the right way? And, why is that way right? In a way that has a minimum impact on the tools and sources. The les that needs to be changed and the simpler the change the better. Like asking dpkg where libs should end up and using that as a variable instead of just replacing lib/ with foobar/ (as an example). Why does this need to be in dpkg? For contrast, what's wrong with some table represented in some file in /etc/? I think only one thing has to still happen now: You have to understand that full biarch LSB compliance for amd64 requires most of the work of porting something to biarch already, that going to LSB compliance without going straight to multiarch is wasted work and that a clean LSB compliance can only be achived once everything has been ported. [as long as you want a 64bit system with the ability to also run 32bit and not the other way around] Personally, I could do with either -- as a general rule, I prefer to get things right before focussing on speed, so I'd probably actually prefer a 32 bit system with the ability to run 64 bit. I personally can probably live with LSB compatability for 32 bit, instead of LSB compliance. Maybe. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Wed, Jul 14, 2004 at 10:17:14PM -0800, D. Starner wrote: To become LSB compliant would involve changing half the packages in Debian to achieve a result to many AMD64 developers consider inelegant; furthermore, a multiarch design is being created that would allow us to install Linux binaries on NetBSD or Hurd, or ix86 binaries on PowerPC, provided an appropriate emulator, as well as 32-bit on a 64-bit system. This will require changing half the packages, but for a better design. It's not a hack, it's a feature. The most likely reason someone would pick the AMD64 architecture over the PowerPC architecture is that AMD64 can natively run I386 binaries. What you seem to be saying here (and I must admit that I've not tried to install the current debian amd64 system) is that you want Debian to go with some vaporware emulation capability, instead of providing that native support. If we're going for vaporware, why not just go for the vaporware filesystem shim which makes /lib and /lib32 appear as /lib64 and /lib for 32 bit binaries? That way, you could claim LSB compliance, too -- at least for 32 bit binaries. Vaporware can do anything. Or how about building the chroot cage that seems to do the equivalent, and debian install time. Maybe make it a package (amd64compat32). Oops, now you need something to automatically chroot 32 bit binaries. Well, you can use vaporware for that, too (at least this would be simpler vaporware). Anyways, vaporware or not, please realise that my 32 bit binaries won't work will be a significant issue for at least some of the people who would want to install a Debian amd64 system. And treatment of that issue would basically be the same as the outcome in the current situation: people install some other distribution, instead -- maybe with Debian in some chroot cage so they can play around with Debian. But making a chroot cage transparent to something like KDE or Gnome isn't completely trivial (the phrase inelegant comes to mind, for some of the obvious approaches). Of course, Debian in chroot is currently doable (it'll be i386 Debian, which isn't glamorous, but should at least be fairly stable). And, of course, when someone running a Debian hosted in some other OS system hits a low level bug, they're going to not be sure which OS it's a bug in, so might be reluctant to file a report on this issue. Which might mean they eventually give up on the chroot -- but at that point it really doesn't matter whether they have 64 bit debian in the chroot or 32 bit debian. The current mirroring system can hardly be considered a hack. There's mumblings about space restrictions, but that's really in the people who set up the mirror system's bailwick. Is this a claim that you're willing to wait for them to solve that problem? It is a little frustrating that s390 and friends could join, no questions ask, but AMD64 gets the third degree. I understand the frustration, but treating the people who are trying to help you like they're your enemies is not a good way to deal with it. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 02:04:54PM +0200, Andreas Metzler wrote: People choose ix86 (or amd64) over PowerPC because a) bang/buck ratio. b) runs windows (games.) Those are two reasons. Unfortunately, the current debian amd64 port doesn't look like it supports cedega (forinstance). More generally, by not providing 32 bit support, we're reducing the bang/buck ratio. It currently looks like ia32 will be replaced by amd64/ia32e as both AMD64 and intel are changing the products and adding the 64-bit extension does not seem to be very expensive for the CPU manufacturers. Agreed. And, Debian's amd64 currently isn't positioned to be useful in this sense. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
* Raul Miller ([EMAIL PROTECTED]) wrote: The most likely reason someone would pick the AMD64 architecture over the PowerPC architecture is that AMD64 can natively run I386 binaries. On Thu, Jul 15, 2004 at 08:33:23AM -0400, Stephen Frost wrote: That's quite an assumption you're making there. One that I, personally, seriously doubt is accurate considering most of the people I know w/ AMD64's (including myself) didn't buy it because it can run I386 binaries. It is an assumption. It's based on some simple observations on how the marketplace has treated various 64 bit architectures. That said, the accuracy of this assumption also depends on the group of people you apply it to. I think it's safe to say that it's not likely to be accurate for any of the current debian amd64 porters. What you seem to be saying here (and I must admit that I've not tried to install the current debian amd64 system) is that you want Debian to go with some vaporware emulation capability, instead of providing that native support. Providing that 'native' support for I386 isn't an option for sarge. Sure it is -- that's the i386 port. [Yeah, but that doesn't take advantage of the amd64 architecture... hold that thought.] Everyone knows that. If it was, we'd be doing it and sarge would be released in 2006 at best. That does NOT provide justification to not support AMD64 at *all*. The question is, what's the upgrade path to an amd64 system which supports 32 bit code? Is that going to be easier from i386 than from amd64? Without a really solid reason to believe that the current amd64 would make that easier than i386, it's kinda hard to rationalize squeezing amd64 into sarge. If we release an amd64 in sarge, we're committing to supporting it. If the current port paints us into a corner, that's a good reason to not start supporting it yet. It seems to me that migrating from a 64 bit /lib would require several steps: First, you'd have to build a system which references /lib64 instead of /lib, once you've upgraded to that system you could then get rid of /lib and replace it with a 32 bit /lib/. Which means we'd be ready take advantage of amd64 native support for i386 binaries sometime around 2010. Maybe. That's not a very exciting prospect to consider if the reason we're trying to get amd64 in sarge is that not offering the support for the architecture that other distributions do would make us a laughingstock. If we're going for vaporware, why not just go for the vaporware filesystem shim which makes /lib and /lib32 appear as /lib64 and /lib for 32 bit binaries? That way, you could claim LSB compliance, too -- at least for 32 bit binaries. Vaporware can do anything. There are quite a few very happy people running Debian/amd64 systems. They're not interested in closely-integrated I386 support, they would, however like *some* support for what they're currently running. You mean more support than they're currently getting, I presume? I can guarantee you'd get more support for a 64/32 bit system than a pure 64 bit system. [As in, I'd contribute.] Anyways, vaporware or not, please realise that my 32 bit binaries won't work will be a significant issue for at least some of the people who would want to install a Debian amd64 system. And treatment of that issue would basically be the same as the outcome in the current situation: Yes, it will be a significant issue for some people. That's not a justification to not support the architecture at all because for alot of other people the support Debian has for AMD64 will be more than sufficient. Not in and of itself, certainly. The reasons to keep it out of main include: [*] amd64 binaries can't be built from the sources in main, and [*] lack of a clear upgrade path to 64/32. people install some other distribution, instead -- maybe with Debian in some chroot cage so they can play around with Debian. But making a chroot cage transparent to something like KDE or Gnome isn't completely trivial (the phrase inelegant comes to mind, for some of the obvious approaches). The *reality* is that KDE and Gnome aren't the things people are going to need chroot'd, it's things like Oracle (though I've heard even they have an AMD64 version now, though I've heard nothing of a PowerPC one), commercial compilers and other closed-source/binary things. It's not KDE and Gnome themselves which are the issue, but applications which people would want to run from within KDE and GNOME (or just plain X). It's the integration which is painful. Of course, Debian in chroot is currently doable (it'll be i386 Debian, which isn't glamorous, but should at least be fairly stable). Right, so you'd be able to run AMD64 Debian and i386 Debian. What you're proposing is that we only offer i386 Debian. How is that better? Less complex upgrade path to AMD64 with 32 bit support. And, of course, when someone running
Re: -= PROPOSAL =- Release sarge with amd64
Unfortunately, the current debian amd64 port doesn't look like it supports cedega (forinstance). On Thu, Jul 15, 2004 at 04:16:48PM -0400, Stephen Frost wrote: It does support a number of commercial binaries though already, for those that need them. Many of us don't. I don't know what you mean here. Is It amd64 or cedega? I'm guessing amd64. Are the commercial binaries i386 or amd64? I'm guessing amd64. Unless the debian amd64 port supports 32 bit binaries (the 32 bit binaries I'm using on an amd64 system are available for free, though they're not dfsg free) I think you're missing my point. More generally, by not providing 32 bit support, we're reducing the bang/buck ratio. Not by much considering the only place this is really a problem is where you need both 32bit and 64bit applications running at the same time and interoperating with each other - rather rare in *reality*. I don't know how you quantify *reality*, but when I was first putting together my amd64 system, I was certain I could get by without any 32 bit apps. It turns out I was wrong. It currently looks like ia32 will be replaced by amd64/ia32e as both AMD64 and intel are changing the products and adding the 64-bit extension does not seem to be very expensive for the CPU manufacturers. Agreed. And, Debian's amd64 currently isn't positioned to be useful in this sense. Not positioned to be useful? Where the hell do you get that idea from? Did you bother reading what you were replying to? I'm saying that Debian's current amd64 port isn't positioned to be useful in as providing extensions to a 32 bit environment. That's not saying it's not useful. It's saying that it's not providing a very specific form of use. Do you even *use* Debian? Do you realize that 97% (or whatever) of Debian is already *available* on Debian's amd64? I use Debian. On amd64. For now, I'm using it (the i386 flavor) in a chroot jail on a gentoo base, or by rebooting into it. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
Those are two reasons. Unfortunately, the current debian amd64 port doesn't look like it supports cedega (forinstance). More generally, by not providing 32 bit support, we're reducing the bang/buck ratio. On Thu, Jul 15, 2004 at 09:18:39PM +0100, [EMAIL PROTECTED] wrote: Let me put it that way: You Do Not Get To Decide What Hardware People Buy. Agreed? Sure. Fact of life: amd64 boxen are going to be very common. Fact of life: for very large subset of debian userland, pure64 works and on these boxen it works better than debian/i386. I'm disputing this. So far, I offer as evidence the fact that 32 bit userland has been a crucial element in amd64's success. So far as counter evidence, I'm getting handwaving and that's not how I built my machine. Fact of life: multiarch is vapour and will not be usable for quite a while. I'm talking about 64/32 bit userland -- which is something other distributions already offer. That's not vapor. Care to explain how not having any 64bit userland would be better? It'll be a lot easier to support 64/32 bit userland this way. It currently looks like ia32 will be replaced by amd64/ia32e as both AMD64 and intel are changing the products and adding the 64-bit extension does not seem to be very expensive for the CPU manufacturers. Agreed. And, Debian's amd64 currently isn't positioned to be useful in this sense. In which sense? Given an amd64 box (and that's not up to you), having that beast is better than not having it. If nothing else, i386 with amd64 kernel and pure64 in chroot is *obviously* better than i386 alone. In the sense of sane a straightforward 32+64 bit environment. I have an amd64 box -- that is indeed up to me. I've got 64+32 bit userland because my toolchain (binutils+gcc+libc) was built that way. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
If we release an amd64 in sarge, we're committing to supporting it. If the current port paints us into a corner, that's a good reason to not start supporting it yet. On Thu, Jul 15, 2004 at 09:28:57PM +0100, [EMAIL PROTECTED] wrote: Correct. However, that does not apply to putting it into sid. And that's what more or less sane people were talking about - the rest, AFAICS, is a usual wankfest from usual bunch of kooks with agenda. Ok. We might want to change the subject line if we're going to talk about releasing sid with amd64 instead of sarge. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
It is an assumption. It's based on some simple observations on how the marketplace has treated various 64 bit architectures. On Thu, Jul 15, 2004 at 05:11:29PM -0400, Stephen Frost wrote: Right, my observation is from talking with real people who really bought amd64 systems and who really would like to run Debian on their systems. How many people? That said, the accuracy of this assumption also depends on the group of people you apply it to. I think it's safe to say that it's not likely to be accurate for any of the current debian amd64 porters. No, and also not likely to be true for most people who run *Debian*, or most people who have asked about Debian's amd64 support on the mailing lists. That's a self selected group of early adopters. Debian supporting amd64 isn't likely to make a bunch of Windows users jump ship to Debian and then want to run all their Windows binaries. I don't care about that. What you seem to be saying here (and I must admit that I've not tried to install the current debian amd64 system) is that you want Debian to go with some vaporware emulation capability, instead of providing that native support. Providing that 'native' support for I386 isn't an option for sarge. Sure it is -- that's the i386 port. [Yeah, but that doesn't take advantage of the amd64 architecture... hold that thought.] No, I said *that* native support, as in, the ability to run both on amd64. Try to keep things straight. I'm running native i386 debian on an amd64 right now. I have a good idea what you think I don't have straight, but I'm disagreeing with you. Everyone knows that. If it was, we'd be doing it and sarge would be released in 2006 at best. That does NOT provide justification to not support AMD64 at *all*. The question is, what's the upgrade path to an amd64 system which supports 32 bit code? Is that going to be easier from i386 than from amd64? Without a really solid reason to believe that the current amd64 would make that easier than i386, it's kinda hard to rationalize squeezing amd64 into sarge. It's not all about the upgrade path, sorry. That doesn't make upgrade path irrelevant. Additionally, the reality is that, guess what, it'd probably be *easier* to move to multiarch from amd64 on amd64 than from i386. Maybe. I've yet to see that designed, so I'm not in a position to comment on it. We're going to be dealing with the i386 to multiarch transistion, at least this way it'll look reasonably the same on all the platforms as opposted to special on amd64 because you also have to change the base architecture type from amd64 to i386. It's certainly very unlikely to be harder. If you don't provide a dual 32/64 bit amd64, your transition strategy is going to be install it on a different partition or backup, wipe and reinstall. Oh, yeah, and guess what else that means? Debian won't support amd64 in the next release, which will make alot of people unhappy. What we have now is not ready for release. If we release an amd64 in sarge, we're committing to supporting it. Yes, which is what people want from Debian, a supported amd64 architecture. It's what our *users* who have amd64 systems would like to see. I hope by support you don't mean backup, wipe and reinstall as the upgrade path. If the current port paints us into a corner, that's a good reason to not start supporting it yet. I honestly just don't see this as the case. It might indeed be that the current port doesn't paint us into a corner -- but if that's the case, that's what I'm not seeing. It seems to me that migrating from a 64 bit /lib would require several steps: First, you'd have to build a system which references /lib64 instead of /lib, once you've upgraded to that system you could then get rid of /lib and replace it with a 32 bit /lib/. Which means we'd be ready take advantage of amd64 native support for i386 binaries sometime around 2010. Maybe. Uh, have you *read* the multiarch proposal? Are you talking about http://raw.no/debian/amd64-multiarch-2 The one that says We are not trying to solve the issue of having multiple applications with different ABIs installed at the same time, so having both a i386 and an amd64 perl installed at the same time is out of scope for this document.? Why do you ask? Do you understand it? Do you realize that /lib64 is *not* where we're going? By we, do you mean everyone in debian who has agreed with the social contract? Note that there's nothing in the multiarch proposal which prevents the support of 32 bit binaries compiled for /lib nor 64 bit binaries compiled for /lib64. This is a good thing. But you'd still need to migrate to multiarch before you could migrate to a 64/32 bit system. And I see nothing in the multiarch spec that makes migrating from a /lib64+/lib system any more difficult than migrating from a /lib system. It seems
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 05:56:51PM -0400, Stephen Frost wrote: The Debian amd64 port does support some 32 bit binaries through the use of ia32-libs. Ok, I was under the impression that it did not. I'll try to install it this weekend. I'm very curious as to what, specifically, *you* need. Though I would appriciate it if you could look beyond that to what the rest of the community needs as well. In 32 bit land? I can probably live with: accept bind connect fcntl fsync fork ftruncate gethostbyaddr gethostbyname listen lseek mkdir mmap msync munmap open read recv select send setsockopt socket stat unlink waitpid and write But, yeah, other people likely have other needs. I use Debian. On amd64. For now, I'm using it (the i386 flavor) in a chroot jail on a gentoo base, or by rebooting into it. This is mildly interesting. You would prefer to have to continue to do that until sarge+1? No. Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
Care to explain how not having any 64bit userland would be better? It'll be a lot easier to support 64/32 bit userland this way. On Thu, Jul 15, 2004 at 06:15:23PM -0400, Stephen Frost wrote: Uh, nope, wrong... We're going to be moving to multiarch on all archs, so this just isn't accurate. You've yet to demonstrate any conflict between 64/32 bit userland and multiarch. The only conflict I've seen is the decision to make /lib be the default directory for 64 bit libraries on amd64. This has little if anything to do with multiarch -- multiarch certainly does not require this. I've got 64+32 bit userland because my toolchain (binutils+gcc+libc) was built that way. That doesn't work for Debian though, it's no where near that simple. At one point we did have a biarch toolchain almost entirely built, but that's not really the issue here- it's changing all of the library packages which will be quite a bit of pain. How much pain? Why did you give up on biarch? [Was it only because multiarch is better than biarch?] Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 06:25:31PM -0400, Stephen Frost wrote: Well, there aren't any 32bit apps in Debian, so it'd have to be something you got from somewhere else. Does this mean you've a valgrind package for amd64? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 06:45:59PM -0400, Raul Miller wrote: If so, which part of I'm talking about 64/32 bit userland -- which is something other distributions already offer. or That's not vapor are you having problems with? On Fri, Jul 16, 2004 at 01:05:29AM +0200, Michael Banck wrote: The part about 'other distributions' and the fact that this is a Debian- related mailing-list. Ok: it's vapor for debian even though it's trivial for other distributions. Is that the way you wanted me to say that? Or were you trying to get me to hide that problem? If you want to install some other distribution with 32/64 bit userland, fine. If you want to have multiarch in Debian be more than vapour, well: Put up or shut up -- GangStarr. I have every intention of implementing 32/64 bit amd64 for debian if no one else beats me to it. That said, I don't have large amounts of time to put in on this, and there's a number of people who are way ahead of me on these issues. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
It does support a number of commercial binaries though already, for those that need them. Many of us don't. On Thu, Jul 15, 2004 at 04:36:30PM -0400, Raul Miller wrote: I don't know what you mean here. Is It amd64 or cedega? I'm guessing amd64. Are the commercial binaries i386 or amd64? I'm guessing amd64. On Fri, Jul 16, 2004 at 02:22:17AM +0200, Frederik Schueler wrote: Sorry for being pedantic, but according to www.transgaming.com cedega is emulating WIN32, you know. Cedega is not emulating windos64 nor the windows on windows layer M$ named their biarch setup. And there is no amd64 release of cedega from upstream. Bug them, not the debian amd64 port, please. Yes. Cedega does not support 64bit mode, but it will for sure run without a problem in a i386 chroot setup according to the amd64 howto found on alioth. If you setup the chroot and nvidia drivers correctly, you will for sure be able to run doom3 as it is inteded to run as soon as it hits stores. We'll see next month =) Maybe. That's certainly not the case for my system -- nvidia drivers are of no use to me. And, I've run into problems in the context of chroot. Statements of the form it works are not anywhere near as convincing as evidence of the form people have been using it, and they're no longer filing significant bug reports. Unless the debian amd64 port supports 32 bit binaries (the 32 bit binaries I'm using on an amd64 system are available for free, though they're not dfsg free) I think you're missing my point. The debian port DOES support 32bit binaries. You can run them without a problem, if you install them correctly. Just check the howto on alioth. Only non-free stuff needing a 32bit kernel will not work until vendors reconsider: ATI proprietary drivers, vmware. We're back to maybe here. It works fine for some people. It needs testing. And, chroot (install debian twice, once for 64 bit support, once for 32 bit support, then crosswire the two systems so you can access each from the other) is painful and quirky, no matter how much people claim it's easy. When compared to porting, chroot is easy. But porting isn't something we'd want to ask of most of our users, either. I'm saying that Debian's current amd64 port isn't positioned to be useful in as providing extensions to a 32 bit environment. Feel free to help in multiarch development, and consider the actual port a transitional stage. Do you prefer running i386 binaries and kernel on your amd64 system, wasting the additional registers, sse2 support and the improved memory management? Apparently not, considering: I use Debian. On amd64. For now, I'm using it (the i386 flavor) in a chroot jail on a gentoo base, or by rebooting into it. My condolences. Wheren't you able to install debian-amd64 or why do you use gentoo, looking at your DD status? very, very strange. Why did I never read anything from you on debian-amd64 and never saw you in #debian-amd64 on opn? First off, my requirement is not efficiency. My requirement is I sometimes need to do stuff in a 64 bit environment. That's just plain not something you can do stock i386 debian -- you need something to provide a 64 bit kernel and 64 bit libraries. I gave up on the amd64 port last year, because I didn't have the time to deal with it. I also gave up on building my own gcc (for the same reason), and went with someone else's version because I just wanted something that worked. Given that, I didn't think it was worth wasting the time of the people on debian-amd64. Also, I'm almost never on IRC. I'm rarely in a network situation where it's even possible. [Because I don't have the time to deal with the security issues, I never run ip servers of any sort on my home equipment -- and, yes, that means I don't run debian's KDE, even though I've wanted to more than occasionally.] I don't expect that anyone else needs my particular set of apps, or that they have my requirements, but I do expect other people will want to use debian to run commonly available commercial apps. Here's a question for you, what good does it do to port debian's alien package to amd64 for people who want to use it to install LSB compliant rpms, if Debian's amd64 isn't LSB compliant? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 08:38:46PM -0400, Stephen Frost wrote: Apparently you have woody/i386 (our stable arch) running on an amd64 box today and are concerned about an upgrade path to amd64 in sarge. Actually, it's sarge. You're right, there isn't one. The answer is very simple- wait for sarge+1 and multiarch. If you're happy with i386 on amd64 today then feel free to continue to use it, I don't believe anything we're introducing would cause you any problems there. That's not my concern. I can deal with the issues on my machine, just fine. But this is reminding me of some of the pain from the /usr/doc - /usr/share/doc/ transition. [Where most everyone thought it was easy right up until it became a big hairy mess.] I'd rather not go through something like that again. [And why did we go through that at all? For LSB compliance.] I hope this clears up what your complaint with pure64 is so that other people can read it and judge themselves how they feel about it. Not even close. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
* Raul Miller ([EMAIL PROTECTED]) wrote: This isn't official or anything, but I think that /lib and /lib64 being symlinks are perfectly adequate. As long as they're not symlinks to the same place. On Thu, Jul 15, 2004 at 08:50:22PM -0400, Stephen Frost wrote: Yeah, sorry, not gonna be the way it works. They need to be the same place for packages to work w/o modification and to be LSB compliant. packages to work w/o modification sounds an awful lot like without porting the packages. They would have to be modified to install packages into /lib64 for amd64 instead of into /lib like every other arch. This only matters for packages which provide libraries. You're talking a few dozens of packages which might need a fairly trivial patch. Uh.. I could 921 binary packages currently *installed* on my system that would need to be changed.. I've got 620 on mine, but most of those don't matter. I mean, yeah, getting them all fixed would be nice, and not fixing them is ugly, but all that's really important are the libraries listed in LSB. For the rest, it's probably wise to treat this as a non-release critical bug. I've heard counts of at *least* a couple hundred source packages from other people (in case my method of counting was less than perfect for some reason- dpkg -S lib/*.so* usr/lib/*.so*| cut -f1 -d: | sort -u | wc -l ). The change isn't always all that trivial either. Though, regardless, it would be duplicated work since it would have to be done for multiarch again. Not if it's done right. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 09:09:46PM -0400, Stephen Frost wrote: Those funcs may be available through ia32-libs... I was actually wondering more about specific programs. The no-cost linux downloads from kx.com and jsoftware.com are the ones I'm most concerned about (in that order). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Thu, Jul 15, 2004 at 09:45:19PM -0400, Stephen Frost wrote: sarge isn't supported/released, therefore this is not an issue when discussing if amd64 should be released with sarge. You've confused the configuration of my machine with the issues I'm discussing. That's not my concern. I can deal with the issues on my machine, just fine. Do you have some issue that's relevent to the GR to discuss then? Or to pure64's inclusion in sarge? If not, then let's move this to debian-amd64 where it'd be at least closer to on-topic. Yes. LSB compliance for both 32 and 64 bit apps is relevant to the GR. It's fairly simple for the port to be built to support both 32 and 64 bit LSB apps, and still allow for migration to multiarch. [For example: Have /lib64 be a symlink link to /x86_64-linux/lib and have /lib be a symlink to /i486-linux/lib (similar for /usr/lib*). Make sure that the libraries explicitly mentioned in LSB are installed in the 64 bit library, leave the others as known bugs, to be fixed when people have the time and inclination. Make sure your patches respect some env var (perhaps MULTIARCH_HOST), and have that be set at a fairly high level.] But this is reminding me of some of the pain from the /usr/doc - /usr/share/doc/ transition. [Where most everyone thought it was easy right up until it became a big hairy mess.] I'd rather not go through something like that again. [And why did we go through that at all? For LSB compliance.] Uh, multiarch *will* be painful. biarch *would* have been painful too. We're not disputing that, that's why we're *NOT* asking for biarch or multiarch to be part of sarge. Not even close. We're interested in having pure64 released with sarge so that Debian users can use their amd64 systems reasonably. In my opinion, the only thing painful about my above example implementation is that it make the things that need to be fixed painfully obvious. I hope this clears up what your complaint with pure64 is so that other people can read it and judge themselves how they feel about it. Not even close. You could have used that as an opportunity to clarify yourself. Unfortunately you didn't, so I'm not really sure what your complaint w/ pure64 being part of sarge is now. My current objections are that you're not planning for compliance with LSB and you're not planning for migration to multiarch. Both will be a lot easier to achieve with just a little forethought. [Before you explained about multiarch, my only objection was the lack of 32 bit LSB support.] -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Tue, Jul 13, 2004 at 02:43:59PM +0200, Josselin Mouette wrote: The only valid reasons for not including it are lack of LSB compliance (which can still be easily achieved with a i386 chroot) and mirror space (which will be saved using partial mirroring). Is this a claim that all of the amd64 patches are present in the sources in main? In other words, that the only thing we're talking about is distribution of binaries built from sarge sources? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Tue, Jul 13, 2004 at 02:43:59PM +0200, Josselin Mouette wrote: 1. that the next Debian GNU/Linux release, codenamed sarge, will include the amd64 architecture, based on the work currently hosted at http://debian-amd64.alioth.debian.org/ ; I think this is the wrong way to approach this issue. The difference between testing, and a stable release, is the time and effort spent testing the system. There's no good reason for insisting that sarge not be released until that testing can occur. In fact, seeing as the amd64 port is being introduced to debian as of this year, waiting for the next release is almost perfect timing. That said: it would be Really Nice if we could get releases out faster than we have been. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
On Tue, Jul 13, 2004 at 11:07:04PM +0200, Florian Weimer wrote: In my eyes, voting on technical issues is still better than no explicit decision at all. Both options are horrible, but explicit decisions are still better than implicit ones, no matter how they are made. It's probably worth noting that the dpkg I downloaded as of 5 minutes ago still doesn't support the amd64 architecture. This is a trivial patch, but it's rather important. [And, but one of many steps that needs to be accomplished to bring the amd64 port into main. The whole point of the DFSG and the social contract is that we be able to do these kinds of steps -- and that we do so.] Trying to solve a problem while avoiding talking about the critical issues isn't going to get us very far. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: -= PROPOSAL =- Release sarge with amd64
It's probably worth noting that the dpkg I downloaded as of 5 minutes ago still doesn't support the amd64 architecture. This is a trivial patch, On Wed, Jul 14, 2004 at 12:50:29AM +0100, Scott James Remnant wrote: I haven't uploaded one that does yet. Thanks, that's somewhat informative. Feel free to propose a GR to force me to do it. This, on the other hand, is completely unhelpful. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What your ballot should look like if you're in favor of releasing sarge
On Fri, Jun 25, 2004 at 05:42:04AM +0100, Andrew Suffield wrote: Ah, so suddenly you're not allowed to discuss issues in case you cause anybody to change their mind. That really is what Manoj has been complaining about. No. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussions in Debian
On Fri, Jun 25, 2004 at 05:25:28AM +0100, Andrew Suffield wrote: [You have quite neatly just demonstrated what argumentum ad hominem actually is, though]. On Fri, Jun 25, 2004 at 03:05:08PM +1000, Hamish Moffatt wrote: Do you have that phrase on a macro key yet? He was right that time. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussions in Debian
He was right that time. On Fri, Jun 25, 2004 at 02:07:04PM +0200, Josip Rodin wrote: No, he wasn't. An ad hominem argument appeals to non-rational things, whereas Hamish pointed out two facts: that Andrew started two general resolutions and that both of them were rather divisive. I believe you're thinking of http://www.nizkor.org/features/fallacies/personal-attack.html I was thinking of http://www.nizkor.org/features/fallacies/ad-hominem-tu-quoque.html -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Discussions in Debian
On Wed, Jun 23, 2004 at 09:12:52PM -0500, Manoj Srivastava wrote: An easier way is to look at the votes when they come out. Anyone who votes further discussion in the top 3 is not interested in compromise or consensus, and has decided My way or the Highway. On Thu, Jun 24, 2004 at 10:19:04AM +0100, Jochen Voss wrote: Sorry, but I think this is not true. ... In my opinion the best strategy [*] with our current voting system is to rank further discussion second, directly after your favourite option. This can only true if you're not interested in compromise or consensus. Interestingly enough, you did not offer any reasons to believe that Manoj's statement is not true. You did offer a number of justifications for your own view (which I choose not to quote), but it looks like you missed Manoj's point -- not like you have any reason to disagree with it. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What your ballot should look like if you're in favor of releasing sarge
On Wed, Jun 23, 2004 at 12:16:26PM -0400, Clint Adams wrote: You're implying here that those things were allowed under a valid interpretation of the original SC. Given historical practice, that's not an unreasonable interpretation. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
| ... It would be a bad idea to write a long document `under the gun'. ... On Wed, Jun 23, 2004 at 01:41:22AM +0200, Arthur de Jong wrote: This pretty much pleads agains proposal E. The constitution is long. Proposal E is not long. Would it be correct to assume that only the passing of proposal C will allow for a speedy release of sarge if it were up to the TC? No. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
On Mon, Jun 21, 2004 at 08:41:55AM +0200, Milan Zamazal wrote: be abused by focusing on the exact wording of the SC. Taking the wording literally and solving the problems by postponing or reverting the SC changes looks like an ugly hack to me. At least three of the ballot options do not have this character. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
On Mon, Jun 21, 2004 at 05:19:22PM +0200, Arthur de Jong wrote: And to not make the same mistake twice, is there some statement from the release manager somewhere regarding this vote? The release manager has said that he feels making release policy without the involvement of the rest of the project was a mistake, and he's delegated this issue to the technical committee. The technical committee is waiting to see the outcome of this GR, but informally http://lists.debian.org/debian-ctte/2004/06/msg2.html -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
Software which can't be ported, which can't have security problems resolved, which can't be delivered, and which can't be used are all examples of problems we're trying to avoid. On Sun, Jun 20, 2004 at 01:39:39PM +1000, Ben Burton wrote: Does can't be used include had its documentation removed? Obviously, that's one of the problems we're trying to decide how to address. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Analysis of the ballot options
Ah, never retain from a ad-hominem attacks, eh? On Mon, Jun 21, 2004 at 12:00:58AM +0100, Andrew Suffield wrote: Oh, come on. That was not an argument, therefore it cannot *possibly* be an instance of argumentum ad hominem. How is missing the point of what he said relevant? -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Vote on GR 2004-004
On Wed, Jun 16, 2004 at 11:54:05AM +0100, Andrew Suffield wrote: Personally, I don't buy the notion that this is a release issue at all. Dropping non-free stuff just isn't that hard; it wouldn't take long. I don't think the time is only for dropping non-free stuff. I think it's also for going over the remaining packages to make sure they comply with the new policy, and for release management (such as testing). -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal G
On Wed, Jun 02, 2004 at 10:27:58AM +0200, Andreas Barth wrote: However, as the 3:1-majority is needed anyways(*), I don't mind to add something like: In the opinion of the Secretary, this proposal overrules the social contract, and needs therefor a 3:1-majority. In the opinion of the proponent, it doesn't overrules the social contract, but just put more siginficance on the interests of our users (as in SC #4). When there's a dispute about the constitution (and the 3:1 majority issue is a constitutional thing), the secretary chooses the right interpretation. (http://www.debian.org/devel/constitution, search for interpret) -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal G (was: Proposal - Deferment of Changes from GR 2004-003)
On Tue, Jun 01, 2004 at 10:31:21AM +0100, Andrew Suffield wrote: Objection. Common sense is what tells you that the world is flat. Common sense tells me that if the world was flat the horizon would always be obscured. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Deferment of Changes from GR 2004-003
On Tue, Jun 01, 2004 at 10:39:10AM +0200, Andreas Barth wrote: Reason: Please be specific what you want. As long as a GR doesn't say that it might touch a foundation document, it doesn't do. It might be nice if the constitution (or some foundation document) said this. As it happens, people have rejected some foundation document proposals (for example, Ian Jackson's) for being overly specific. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Deferment of Changes from GR 2004-003
On Tue, Jun 01, 2004 at 06:22:09PM +0200, Andreas Barth wrote: In my opinion it's as this: - If a GR has normal majority, and does not conflict with a foundation document, it's ok. Until the vote is held, it's not reasonable to act on any specific outcome for the vote -- we can't know whether the winning option will receive a normal majority. We can't even know which option will win. - If a GR has 3:1 majority and specifies to (possible) override a foundation document, it's ok. And if the override is implicitly specified, but not explicitly specified, then what? - Everything else will create noise on d-vote, and should therefore be avoided. (This is no statement about such a GR being acceptable - I'm just more happy to don't discuss it to every detail.) Ok? Even in the absence of any override, a position of the day has quite a bit of force -- it just needs to not explicitly conflict with any foundation documents. Ambiguities in documents give a fair degree of latitude. That said, I don't think that discussing what proposals which have not yet been voted on might mean is noise. I think that if we had had more talk of the potential implications in discussion period for the last GR that we wouldn't have people wanting another GR to fix the problem. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Deferment of Changes from GR 2004-003
Position of the day statements can overrule foundation documents if they achieve a 3:1 majority seems to be a valid interpetation of the constitution. On Tue, Jun 01, 2004 at 02:23:51AM +0200, Robert Millan wrote: Note the difference between overruling and reaffirming. Note the difference between the social contract and proposal F. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal F on the ballot now.
Does that mean non-free must be empty for Sarge? On Tue, Jun 01, 2004 at 02:40:25AM +0200, Robert Millan wrote: You're impliing that, under your interpretation of the SC, non-free is part of Debian. This interpretation would make the SC contradict itself, and bring us to the silly situation in which a position statement that merely reaffirms the SC is actualy violating it. Being a part of the debian archives doesn't mean that something is a part of the debian [operating/application/...] system. Otherwise, for example, the part of our archives which hold list traffic would need release management. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Deferment of Changes from GR 2004-003
On Fri, May 28, 2004 at 03:38:47PM +0100, Andrew Suffield wrote: While we're on the subject of interpretations, the first clause (The Debian project resolves that it will not compromise on freedom) constitutes a position statement about an issue of the day, under 4.1.5. Anybody who tries to give it a stronger meaning is invited to stop being a dick. That meaning is plenty strong as it is. Position of the day statements can overrule foundation documents if they achieve a 3:1 majority seems to be a valid interpetation of the constitution. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal F on the ballot now.
On Wed, May 26, 2004 at 09:03:47PM -0500, Manoj Srivastava wrote: You can put whatever you want in your sources.list, and they can point whereever they want, but that does not make it part of Sarge, which we, as a project, release. Nevertheless, there is a non-free accompaniment to Sarge. deb ftp://kalle.csb.ki.se/pub/linux/debian/ sarge main contrib non-free -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal - Deferment of Changes from GR 2004-003
On Wed, May 26, 2004 at 09:02:33PM -0500, Manoj Srivastava wrote: The social contract currently reads: == 1 Debian will remain 100% free ... system require the use of a non-free component. == So, such an ambiguity is not introduced by proposal F, it resides in the social contract itself -- notice how the first promise is that Debian will remain 100% free, not the debian system? You left out four of the five sections of the Social Contract, and all but one of those sections use the word free. Two of those sections draw a contrast between free and something else. Proposal F says The Debian project resolves that it will not compromise on freedom. I see nothing here that limits that lack of compromise to section 1 of the social contract. It's certainly not the case that it's the social contract which introduces an ambiguity on whatever it is that we don't compromise on. You won't find will not compromise anywhere in the social contract. Arguably, the usage is that the former is shorthand for the latter, but I tend to think we make statements (as in the social contract, and in position statements) as statements -- not lawerly tomes with riders and codicils extending into several volumes, which is what some of the nit picking seems to require. I will agree that that was how the social contract was intended. I'm not sure that that's how the social contract is being used in this context. And if you have two priorities, one of which you won't compromise on, and the other where nothing has been said about compromising, in a conflict where you have to choose between the two, the one that you won't compromise on automatically wins that conflict. If I say Scylla is undefeatable, does that imply that charybdis is navigable? This isn't a great analogy, because [a] their undefeatability and unnavigability have already been determined, and [b] you won't be in a position of authority over this aspect of either Scylla or Charbdis. If your statement were somehow to be made into something that would affect both AND if neither previously had this sort of characteristic, then you'd have a great analogy. That said, this analogy strikes me as being very much like [c] in http://lists.debian.org/debian-vote/2004/05/msg00426.html -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: DFSG#10
On Wed, May 26, 2004 at 11:49:12PM -0400, Walter Landry wrote: For anything not in the distribution (e.g. the web pages), I would agree. However, I _do_ think that the social contract is saying that anything in the distribution must be free software. Sure. But what you're showing here is that your interpretation is plausible. That was never the question. What we have is another plausible interpretation which happens to be different than yours for the prior social contract. In other words, before the release of the new social contract, there was ambiguity as to which definition of software was intended in the DFSG -- the release manager picked the most typical definition, and this was supported in his opinion by historical practice. It was disallowed by the old social contract. There was a clear consensus, and I'm not the only one saying that [1] [2] [3]. It? The distinction. Anthony Towns already addressed that point. We had some agreement on the point, but not a consensus of debian developers. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
