Re: Bug#587886: future of maintaining of the bootloader LILO
Hi, I vote: 1 B 2 A 3 SQ manoj -- The most incomprehensible thing about the world is that it is comprehensible. Albert Einstein : Understanding the world Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20 05B6 CF48 9438 C577 9A1C pgpZymFCMx11n.pgp Description: PGP signature
Re: Call for votes: Bug#535645: Wrongful removal of ia32-libs-tools
On Tue, Sep 01 2009, Steve Langasek wrote: I'm calling for votes on this issue. The ballot options are given as short summaries of the resolutions; please see the provided links for the full text of the resolutions. 1. Decline to override the ftp team decision to remove ia32-libs-tools Message-ID: 20090823065342.ga14...@dario.dodds.net http://lists.debian.org/debian-ctte/2009/08/msg00079.html 2. Require the ftp team to reinstate ia32-libs-tools, or provide more information Message-ID: 1251227318.5849.738.ca...@rover http://lists.debian.org/debian-ctte/2009/08/msg00096.html 3. Further Discussion I vote: 1 2 3 manoj -- For a man to truly understand rejection, he must first be ignored by a cat. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpOOmqMkI7ha.pgp Description: PGP signature
Bug#510415: Call for votes on Bug#510415: tech-ctte: Qmail inclusion (or not) in Debian
On Thu, Aug 20 2009, Don Armstrong wrote: I'm calling for a vote on the following options[1]: | 1. Qmail is to be allowed into the archive without special | preconditions. Ftpmaster should perform standard NEW processing for | licensing, copyright, and general packaging issues as normal. | | Qmail is subject to the normal removal process for packages. | | 2. Qmail is to be allowed into the archive without special | preconditions, save the RC bug indicated below. Ftpmaster should | perform standard NEW processing for licensing, copyright, and general | packaging issues as normal. with the addition of an RC bug filed | immediately to preventing normal transition for a period of at least a | month after traversing NEW. | | During this period, additional RC (or non-RC) bugs should be filed by | interested parties, and updated qmail packages fixing these bugs | should be uploaded as usual. After a month, the RM or the maintainer | can continue to decide that the package is not acceptable for release | at their discretion, as happens for any package. [If the RM or | maintainer don't reaffirm the transition blocking bug, the ctte will | close the transition blocking bug.] | | Qmail is subject to the normal removal process for packages. | | 3. Qmail is to be allowed in to the archive after a patch to resolve | the delayed bounces issue, where mail sent to an invalid recipient | which a reasonable MTA is capable of knowing is invalid is accepted | instead of being rejected at RCPT TO time. After upload, the process | outlined in option #2 will take effect. | | 4. Qmail is not to be allowed into Debian. | | 5. Further discussion. I vote: 3 1 2 4 5 manoj -- The one charm of marriage is that it makes a life of deception a neccessity. Oscar Wilde Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpg7XRjYBjEh.pgp Description: PGP signature
Bug#535645: Wrongfull removal of ia32-libs-tools
On Thu, Aug 20 2009, Don Armstrong wrote: On Thu, 20 Aug 2009, Russ Allbery wrote: In the meantime, I think it's reasonable for ftpmaster to pick the poison that they want to live with between the two ugly solutions that have been put forward. If they think that ia32-libs is less broken in the short term than ia32-libs-tools, I don't want to argue with them, and I don't see a lot of compelling need to have both of them. Given that at least three of the ctte members have indicated that they're unwilling to override the ftpmasters,[1] should we go ahead and call for a vote along these lines: 1. The CTTE declines to override ftpmaster's decision to remove ia32-libs-tools. 2. Further Discussion or is there additional information which would convince the CTTE to override the ftpmasters which we feel wouldn't convince the ftpmasters to allow its inclusion? Don Armstrong At this point, I must confess that the ia32-libs-tools inclusion argument does not have the techical underpinnings it needs to convince me that inclusion would be a net benefit to Debian. While I am not sure that the rejection of the package, and the subsequent communication about the underlying reasons from the viewpoint of the ftp-masters were done as well as they cold have been, I do not feel that rises to the level that would justify a delegate override. I would add a suggestion to the resolution that the CTTE invites the ftp-masters to share their reasons with the package maintainer, but otherwise the draft above looks OK. manoj -- Life is like a bowl of soup with hairs floating on it. You have to eat it nevertheless. -- Flaubert Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Some coriousities about debian package maintaining
read in the chatlines. I were using freeBSD the last years, started using debian a few month ago. My requirement for security starts by installing as few software (and DAEMONS!!) as possible. It would be nice, if you could answer me if I am wrong using debian with that requirement. Nevertheless, weasel wasn’t able to answer me how to get apt-get working without using tsocks. Maybe you are able to. I don’t know how else to contact, so I hope you can help me out. This determination needs to be made by you. I do not see this as something that the TC needs take action on. manoj -- Double! Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#539158: Call for Votes on Bug#539158: [ …] assumes printf is a builtin
I'm calling on votes on the following options: | 1. The Technical Committee refuses to overrule the udev maintainer, as | requested by Bug 539158. The committee suggests that the policy | maintainers document in the policy what the current best practices on | providing printf (and similar functions used in the initrd like [ and | test) by shells. | 2. Further discussion (As there is already a bug on the policy on the issue of builtins, I'd like to leave it to the policy team in case of 1 whether they want to clone this bug report or not.) I vote 1 2. manoj -- If it glistens, gobble it! Zippy the Pinhead Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpijDhovahVc.pgp Description: PGP signature
Bug#484841: Call for votes
On Fri, Jul 24 2009, Andreas Barth wrote: Hi, I'm calling on votes now for these three options (the last one isn't a proposal, but by default in the option set). According to the consitution, the voting periode last for up to one week, or until the outcome is no longer in doubt. | 1. Keep /usr/local writeable by group staff (i.e. leave things as they | are). | 2. Decide to change the default so that /usr/local is not writeable by | group staff anymore. This change should only be implemented after an | appropriate transition plan exists which enables system administrators | to maintain the ability of group staff to write to /usr/local. | (Reasons for the change are the adaption of other tools like sudo on | most sites, and the concept of least surprise for novice users.) | 3. Further discussion. I vote: 2, 1, 3 manoj -- If you don't stand for something, you'll fall for everything. Jeff Stiles, Southern Baptist preacher Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpxNGPaZaWNS.pgp Description: PGP signature
Bug#422139: init script for git-daemon (summary; possible action)
On Sat, Jul 25 2009, Don Armstrong wrote: Just to summarize what I understand to be the current status of this bug: 1) git-daemon-run currently does not provide a sys-v init script because it is designed to be run by runit; no existing package provides a sys-v init script for git-daemon. 2) Gerrit Pape is willing to apply a patch to git-daemon (or produce an additional package) to provide a sys-v init script, which is to be written by contributors who desire to see such functionality, and plan to maintain the functionality. Since #2 is at most what the committee could decide to do, there's no decision for the technical committee to make regarding this bug. Thus, I suggest that this issue be reassigned to git-daemon, tagged with wontfix and help, and Aurélien Gérôme (or any other individual) prepare a patch, and work with Gerrit Pape to make it mutually agreeable. If at some point there is a workable patch, but there is an inability to come to agreement, it can be brought back to the CTTE for a decision. [At any time, specific questions which don't require a CTTE decision can of course be asked via the ctte mailing list.] Does anyone have any objections or suggestions? [I plan to reassign after 4 days if there are none.] Sounds good to me. manoj -- The hell with the prime directive, let's kill something. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpbtLJjE0Wr6.pgp Description: PGP signature
Re: foo2zjs
On Fri, Oct 31 2008, Andreas Barth wrote: As this bug didn't get a decision from the release team yet, I'd propose the following decision by the tech ctte: 1. Currently, the submitter claims that the bug is serious, the maintainer don't think so, and there is no decision by the release team yet. So the current state of the bug isn't serious, but important. The maintainers should continue to feel free to adjust the bug severity according to their decisions (unless of course the release team decides to overrule them). 2. As per constitution, we (the tech ctte) only makes decision as last resort. So currently, the next step would be for anyone who disagrees with this bug not being release critical to ask the release team to review the decision and maybe overrule it. 3. If there is a release team decision, and someone is still unhappy enough then one could ask the tech ctte to overrule the release teams decision. However, until the overruling actually happens, the bugs state remains to stay the way the release team decided. tech ctte members, any opinion from you on that? I concur. Additionally, I think I also agree with the maintainer, i that this does not seem like a DFSG violation; the package delivers free functionality relevant to at least one printer, a maintainer has seen fit to package that functionality for main, and if there is a script that the user can use to support hardware that requires non-free software, we understand. The example script is not central to the function for supported hardware, so it does not warrant shipping the whole package in contrib. This is, of course, a non-binding opinion at the moment. manoj -- People don't form relationships, they take hostages. anon Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: assigning to tech ctte (Re: status of this bug)
Hi, Isn't this kind of thing the normal fodder for the Release Notes? I seem to recall a number of upgrades where upgrading the package management tools _first_ was the only way to achieve a smooth upgrade, and this seems to be no different. If the decisions is between having the release notes specify that package management tools have to be upgraded first, and not allowing users the freedom to install on,ly bash, and not the auto-completion package, it is entirely reasonable that the release team picks the former. manoj -- Sattinger's Law: It works better if you plug it in. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes (Re: mixmaster /etc/default/*)
On Sun, 2 Dec 2007 22:13:38 +, Ian Jackson [EMAIL PROTECTED] said: I hereby call for a vote on the resolution below, which I sent round a draft of on Friday and formally proposed yesterday: -8 - (1) The REMAIL option should not be supplanted or supplemented by anything in an /etc/default file. The current behaviour of the mixmaster init script, to examine /etc/mixmaster/remailer.conf's REMAIL option, is correct. (2) Policy is clear and correct, and need not be changed. -8 - [1] Choice K: Keep current behaviour and existing policy, as above. [2] Choice F: Further discussion -- Inspiration without perspiration is usually sterile. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpy8BATkBqSy.pgp Description: PGP signature
Re: Call for Votes (getaddrinfo)
On Thu, 29 Nov 2007 19:51:37 +, Ian Jackson [EMAIL PROTECTED] said: This time can we _please_ try to get quorum ? You must send in your vote within 7 days of me sending this message, for it to count, ie by approximately 2007-12-06 19:50 +. -8 - 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses by Debian systems, and we DO overrule the maintainer. 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses by Debian systems. We do NOT overrule the maintainer. 3. We recommend to the IETF that RFC3484 s6 rule 9 should be abolished for IPv4, and that it should be reconsidered for IPv6. -8 - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [1] Choice X: Do not use rule 9, overrule maintainer, etc., as above. [3] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo [4] Choice M: Leave the choice up to the maintainers. [2] Choice F: Further discussion -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- As I have mentioned before, I think we should be deciding an issue purely on its merits; and how egregious the error is should not count towards determining what the correct solution is. If our deliberations conclude that a maintainer is incorrect, well, that is what we concluded. Everyone makes mistakes. manoj -- Whip me. Beat me. Make me maintain AIX. Stephan Zielinski Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpNKbzXcDsJD.pgp Description: PGP signature
Re: Technical Committee ping
Hi, On Tue, 27 Nov 2007 19:14:23 +, Ian Jackson [EMAIL PROTECTED] said: Please reply to if you get this email and let us know whether you are in a position to transact TC business. We seem to have a problem getting quorum and I'd like to know why. Ack. manoj -- Perhaps I'm missing the gene for making enemies. :-) Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Call for Votes
-8- 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses by Debian systems, and we DO overrule the maintainer. 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses by Debian systems. We do NOT overrule the maintainer. 3. We recommend to the IETF that RFC3484 s6 rule 9 should be abolished for IPv4, and that it should be reconsidered for IPv6. -8- -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [1] Choice X: Do not use rule 9, overrule maintainer, etc., as above. [3] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo [3] Choice M: Leave the choice up to the maintainers. [2] Choice F: Further discussion -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- I am not sure it is right to just leave things to the maintainers, no matter what they chose, once we have been called in to make a ruling. And I think we should advocate the behaviour we consider to be better when we make the ruling, whether or not we are changing Etch as well (personally, I would consider changing behaviour in Etch in a later point release, depending on the fallout of the change made in unstable). manoj -- You will wish you hadn't. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgp0hooeIN6Mj.pgp Description: PGP signature
Re: Call for Votes (Re: glibc's getaddrinfo() sort order)
On Thu, 20 Sep 2007 19:01:50 +0100, Ian Jackson [EMAIL PROTECTED] said: There is apparently no counterproposal, so I hereby propose and call for a vote on the following resolution: -8 - 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses by Debian systems, and we overrule the maintainer. If the maintainer has not uploaded a suitable change within 1 week, Ian Jackson is mandated to make an NMU in sid. 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses by Debian systems. However, we do not overrule the maintainer on this point and we do not authorise changing it via an NMU. 3. We recommend to the IETF that RFC3484 s6 rule 9 should be abolished, definitely for IPv4, and probably for IPv6 too. -8 - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [1] Choice X: Do not use rule 9, overrule maintainer, etc., as above. [3] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo [2] Choice F: Further discussion -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Sorry for the delay; I have been swamped at work. manoj -- Single tasking: Just Say No. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpER0eMFQ64h.pgp Description: PGP signature
Re: Bug#436093: Please decide on the ownership of the developers reference
On Mon, 6 Aug 2007 09:16:23 +0200, Andreas Barth [EMAIL PROTECTED] said: In case the TC decides I'm still the lead maintainer, I would like to try to find out if there is a procedure that still satisfies my quality requirements, and will allow Raphael to contribute in a way he likes. Somehow, I am currently quite annoyed (which is perhaps not best but natural), but I'm optimistic we can still work out something which is ok. (That's basically not different from any other package or area I'm responsible for.) Unfortunatly, that can't be done now, because as long as Raphael insists in having the exactly same say as I have, we won't find such a procedure (because the procedure needs to violate that wish). You might consider setting up individual branches, and a release branch; people commit to their own branch, solicit comments, and when the review is done, those changes can be pulled into the release branch. This is the way that the linux kernel works, and is also the way that policy is set up; and using git/arch/bzr/mercurial instead of CVS would also help. manoj -- In general, they do what you want, unless you want consistency. Larry Wall in the perl man page Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#436093: Please decide on the ownership of the developers reference
On Mon, 6 Aug 2007 12:24:56 +0200, Andreas Barth [EMAIL PROTECTED] said: * Manoj Srivastava ([EMAIL PROTECTED]) [070806 00:45]: I was not contacted at the time my name was removed from the uploaders list. If I remember correct, Manoj, I asked you on the developers reference on IRC (before I started my first commits), and you said that you're there only for historical reasons, and otherwise have no interesst in it. However, as I don't log IRC, I cannot prove it. (I'm quite sure I contacted you, because I was quite new and you were being such an oldtimer in Debian.) Fair enough. I did just review my email archives; my IRC logs only go back to 2005, and I certainly don't trust my memory on things like this. I am pretty sure I've never really had much of an interest in the dev ref, since I've never done anything with my commit rights when I had them. manoj -- The question of whether computers can think is just like the question of whether submarines can swim. -- Edsger W. Dijkstra Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436093: Please decide on the ownership of the developers reference
Hi, I am not sure that this is something that ought to be in the tech-ctte's jurisdiction; this seems a social problem, not a technical one, and thus is not something I think the tech ctte is competent to address (even though the constitution does explicitly mention this as a case of the tech ctte's powers). I would strongly urge all parties to try all possible means of rapprochement before escalating to the ctte (indeed, I think this is the type of issue that should go to the nascent social committee proposal currently under discussion). manoj -- Guard against physical unruliness. Be restrained in body. Abandoning physical wrong doing, lead a life of physical well doing. 231 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#436093: Please decide on the ownership of the developers reference
On Sun, 5 Aug 2007 17:15:33 +0100, Ian Jackson [EMAIL PROTECTED] said: Manoj Srivastava writes (Bug#436093: Please decide on the ownership of the developers reference): I am not sure that this is something that ought to be in the tech-ctte's jurisdiction; this seems a social problem, not a technical one, and thus is not something I think the tech ctte is competent to address (even though the constitution does explicitly mention this as a case of the tech ctte's powers). I would strongly urge all parties to try all possible means of rapprochement before escalating to the ctte (indeed, I think this is the type of issue that should go to the nascent social committee proposal currently under discussion). The constitution says that it's within our power and we should follow the process and appeal mechanism we currently have for resolving this issue, even if we think it should be dealt with by some as-yet-unformed body in the future. Note that I did not say that we should not take the issue up; I just exhorted the disputants to attempt to resolve the issue before bringing in the ctte, if possible, for the reasons mentioned. manoj -- Trespassers will be violated! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#436093: Please decide on the ownership of the developers reference
On Sun, 5 Aug 2007 17:24:02 +0100, Ian Jackson [EMAIL PROTECTED] said: So as I understand it: * Andreas argues that he became the lead/sole maintainer with his commit of 2005-02-02 and that he is therefore the current maintainer. * Raphael argues that that commit isn't definitive and that we should regard Raphael and Andreas as co-maintainers. ? This is relevant for deciding what the status quo is but not for any other purpose AIUI. The TC will probably tend towards the status quo by default, but it's certainly not definitive. I'd like to ask Andreas and Raphael how they each propose to handle the maintainership of this package in future. It seems clear to me that Andreas wants to be the primary maintainer and to reserve the authority to make changes, grant commit access, etc. Andreas: do you have any assistants/colleagues/etc. who would be willing to help you with that so that you don't become a bottleneck ? Raphael says he wants a team. Raphael: what team did you have in mind ? Who will help you ? If I recall correctly, the package started out as a team maintained one. I seem to recall having commit access at some point, though I certainly did not make use of it. So perhaps the original team could be candidates for the new team (provided, of course, they are interested -- though it is possible that some, like me, are no longer interested in the package) I'd also like each of you to answer: if the TC rules in your favour, how do you plan to deal with your opponent in this dispute ? Another possible way for the TC to decide on this kind of question is to ask the developers to each prepare a package and then for the TC to choose between them. Do you think that would be appropriate in this case ? Would it be a fair fight ? How long would you need ? manoj -- Intolerance is the last defense of the insecure. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#436093: Please decide on the ownership of the developers reference
On Sun, 5 Aug 2007 14:46:01 -0700, Steve Langasek [EMAIL PROTECTED] said: On Sun, Aug 05, 2007 at 03:08:02PM +0200, Raphael Hertzog wrote: 13:00 buxy sorry, you have no ownership on that package 13:00 aba I disagree. 13:00 aba and that is documented. buxy you removed me without asking aba I didn't remove you. buxy http://cvs.debian.org/ddp/manuals.sgml/developers-reference/debian/control?root=debian-docr1=1.23r2=1.24diff_format=h Andi, this looks like a fair point to me. If we're going to treat this as a question of who has the right to be maintainer of the package, then Raphaël also has some claim that you hijacked the package first. (You mention that you talked to people who were doing lots of QA -- but did you run this by the debian-qa mailing list so that there's a public record of the discussion and an opportunity for comments, and did you try at the time to contact the people that were listed as Uploaders?) I was not contacted at the time my name was removed from the uploaders list. As for Raphaël adding himself to the Uploaders: field, I have no particular opinion about it. I suggest discussing it within the team, too, and either reverting the change, or reaching a common agreement about upload rules (which I would obviously prefer). The team currently consists of me. That's not what the Maintainer field says. And the unix group associated is 'cvs_doc'. Raphaël, surely you're aware that there are many packages which give mailing lists as the maintainer, without implying that everyone subscribed to that mailing list is implicitly part of the team? (Moreover, haven't you said that you aren't/weren't subscribed to -doc, which implies that if the Maintainer field determines who the team is, you're not part of it anyway?) But, since the team of one was done merely by uploading a package with a changed uploaders field, one can argue the team has been expanded by uploading a package again with a different uploaders field -- unless there is a difference between these two uploads changing the Uploaders fields that I am missing? manoj -- F u cn rd ths u cnt spl wrth a dm! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#341839: Call for vote: coreutils: md5sum output format
Hi, I think that maintaining compatibility counts for more than not doing so. - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [ 2 ] Choice 1: the output of md5sum should be changed as per bug #341839 [ 1 ] Choice 2: the output of md5sum should not change despite bug #341839 [ 3 ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Since I am at Debconf, I do not have read access to my keys; I'll sign this mail in a week or so if doing so is critical. manoj -- If you're not part of the solution, you're part of the precipitate. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: Call for vote: ndiswrapper: Move to contrib
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [ 2 ] Choice 1: ndiswrapper should move to contrib as per bugs #353277, #353278 [ 1 ] Choice 2: ndiswrapper should remain in main despite bugs #353277, #353278 [ 3 ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- I tend to give more weight to the license of the software itself; which in this case is free; that the supposed intent of the users (there was the WEP cracker software recently introduced, despite people complaining it was a black hat only tool -- and countered by other people saying it can have security uses). I also found compelling the scenario that even if users used free software in conjunction with non-free data/drivers, there is potential for free data/drivers to be created, and then users shall find a tested, well known, free software suite ready to go the rest of the way. Let not perfect be the enemy of the good. manoj -- It's more than magnificent -- it's mediocre. Sam Goldwyn Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpAh5LGTXiBP.pgp Description: PGP signature
Re: Bug#413926: Call for vote: wordpress: Should not ship with Etch
- - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [ 2 ] Choice 1: wordpress should not be included in etch due to bug #413269 [ 1 ] Choice 2: wordpress should be included in etch in spite of bug #413269 [ 3 ] Choice 3: Further discussion - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- At this point, I have to decide between the prognostications of a security team member, versus the opinions of the debian maintainer and upstream's commitment to support. I tend to also consider the maintainers to be domain experts as far as their package is concerned, which counters the security team being domain experts in security issues and solutions. Additionally, lacking specifics, I would tend to let decisions of non-bugginess to the point of being unsupportable to lie with the maintainers, since they would have to support the package, so I am voting the way I did. manoj -- It's better to burn out than it is to rust. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpgDlpHLVeie.pgp Description: PGP signature
Re: Pending tech-ctte items
Hi, I have reviewed the pointers aj sent out in his omnibus email, and I think I am ready to vote on the issues pointed to in there. Any one care to start the processes? manoj -- A fool and his money are soon popular. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ndiswrapper
On Fri, 15 Sep 2006 13:17:07 -0400, Raul Miller [EMAIL PROTECTED] said: On 9/15/06, Raphael Hertzog [EMAIL PROTECTED] wrote: On Thu, 14 Sep 2006, Raul Miller wrote: Put differently, I do not understand the distinction between The purpose of the ndiswrapper package is to provide an ABI layer on top of the Linux kernel that is compatible with the interface for Windows NDIS drivers and wrapper packages or other sorts of free accessories for non-free programs. (That said, I do understand that ndiswrapper is free software. Everything in contrib is free software.) The different is that in one case, the package ndiswrapper doesn't need to change to work with a free NDIS wrapper. I don't see why ndiswrapper should be different, in this regard, than uae. As far as I can tell, there's far more free software that works specifically with uae than works specifically with ndiswrapper. For that matter, I can think of cases where the package ndiswrapper would have to change to work with some free software that depends on it, even as it is currently packaged. [If the hypothetical free package which depends on it is a higher priority, ndiswrapper would need to be changed to reflect the increased priority.] This is a minor bug, and mostly irrelevant to freeness of the package. That said, there is little value in packaging software around hypothetical packages which do not exist. And, for some odd reason, policy does not ask that we package software based on hypothetical packages which do not exist. Put differently, I still do not see any practical distinction between the two cases I originally quoted above. And, personally, I am not prepared to vote for or against a proposal I do not understand. Can you understand the difference between implementing an free interface, and having non-free software use the interface, and requiring non-free software to work? There was some free software that was used as a demo for ndiswrapper (no longer useful, since a free Linux driver appeared). Even now, if one wants to create a free windows driver and use ndiswrapper to load the same code on Linux, the package can be used to advance freedom. Since tools come first, and then come free packages using the tools, I think we should not be removing ndiswrapper from Debian. manoj -- broad-mindedness, n: The result of flattening high-mindedness out. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: ndiswrapper
On Thu, 14 Sep 2006 22:08:13 +1000, Anthony Towns aj@azure.humbug.org.au said: On Mon, Sep 11, 2006 at 11:58:57AM -0400, Raul Miller wrote: Every package in contrib must comply with the DFSG ... Examples of packages which would be included in contrib are: ... wrapper packages or other sorts of free accessories for non-free programs. It seems clear to me that ndiswrapper fits this policy rather exactly. I disagree with you on that -- I still think providing a compatable interface is the best way to look at this, as per: http://lists.debian.org/debian-ctte/2006/03/msg00037.html i like this proposal as well. manoj -- Whenever 'A' attempts by law to impose his moral standards upon 'B', 'A' is most likely a scoundrel. - H. L. Mencken Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgptLwTvZ1BSH.pgp Description: PGP signature
Re: devmapper: call for votes
On 6 Apr 2006, Steve Langasek said this: I'm calling for a vote on the following resolution regarding bug #329409. The only proposed amendment, by Raul, has been accepted; so this is the only option on the ballot (other than further discussion). I vote yes on this resolution. Cheers, I vote yes on the resolution below. manoj pgpFbLwbRK14x.pgp Description: PGP signature WHEREAS 1. It is a limitation of the current device-mapper implementation in Debian that all device nodes managed by libdevmapper are created with the same hard-coded ownership and permissions; and 2. The standard owning group for disk device nodes is group disk; and 3. The sole reason for the existence of this group on Debian systems is to control access to disk devices; and 4. The majority of device-mapper nodes expose data that is already available to members of the disk group via the component disks; and 5. The use of a different owning group in these cases therefore makes accessing the data more inconvenient but not more secure; and 6. The exception to the above is dm-crypt, whereby device-mapper nodes expose data that is not available in unencrypted form from the component disks; and 7. No single owning group satisfies all possible use cases for device-mapper; but 8. Users of dm-crypt have the option of not adding users to the disk group that they do not wish to have access to their unencrypted dm-crypt volumes; THE TECHNICAL COMMITTEE: 9. THANKS Bastian Blank for his continued maintenance of the devmapper package in Debian; and 10. ALSO THANKS Roger Leigh for bringing this issue before the committee; and 11. ENCOURAGES the devmapper maintainer to work towards support for configurable device-mapper device permissions in Debian; and 12. DETERMINES that the correct default permissions for all device-mapper nodes is root:disk 0660, with or without support for configurable device permissions; and 13. ASKS (with a 3:1 majority: REQUIRES) the devmapper maintainer to implement these permissions in unstable by applying Roger Leigh's patch from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329409;msg=87;att=0; and 14. RECOMMENDS policy be updated to reflect this determination on default block device permissions; and 15. AUTHORIZES Roger to implement these same permissions in stable via a non-maintainer upload. -- Darth Vader! Only you would be so bold! Princess Leia Organa Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#353277: ndiswrapper in main
On 3 Apr 2006, Ian Jackson said: Manoj Srivastava writes (Re: Bug#353277: ndiswrapper in main): Well, yes. Consider the case that I write up a compiler for a new language in C++ or ruby. Can I put this compiler in main? Even if there is no public repository of code in this new language? These arguments seemed entirely mystifying to me until I figured out what Manoj is trying to do. Manoj, you're trying to establish or find a rule which depends only on the direction of dependency interrelationships and formal copyright status, and other things that can be clearly determined without regard to actual existence of any software, usual or plausible use cases, and intents of packagers and users. Am I right ? Yes. I think I am fundamentally skeptical of a process that depends on the judgement of people, especially when conducted in an environment where such diverse views exist as were evinced in the GFDL vote. I also think of the effect it would have on people working on software and releasing it under a free license, if the wider community branded their work as non-0free anyway, through no fault of their own. If I write a free compiler/emulator/virtual machine generator (I actually have an unreleased UML/Xen one), but the only examples I can provide are seen to be toy ones, or there are better variants already around, why should my work not reach a community of users out there? Why would things change if third party decides to use my work for non-free purposes? Adding use cases and samples of third party software into the mix makes the classification process brittle, irreproducible, and controversial, and may end up penalizing authors of free software who want to reach the users in the community through Debian, Ubuntu, and other derived distributions. And for what benefit? Just like the FSF started by distributing and build software on non-free systems, putting out software that may initially be more heavily used with non-free input/output is still desirable, since it is a beachhead that can then be exploited for free purposes by someone out there, who may never be exposed to the software in question was its distribution to be severely limited. manoj -- If you really want pure ASCII, save it as text... or browse it with your favorite browser... -- Alexandre Maret [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 5 Apr 2006, Raul Miller stated: On 4/5/06, Manoj Srivastava [EMAIL PROTECTED] wrote: And for what benefit? Just like the FSF started by distributing and build software on non-free systems, putting out software that may initially be more heavily used with non-free input/output is still desirable, since it is a beachhead that can then be exploited for free purposes by someone out there, who may never be exposed to the software in question was its distribution to be severely limited. Has someone suggested that we should not build or distribute ndiswrapper? In Debian? Yes, I think that is exactly what we are talking about. We've suggested that we not consider it an integral part of our free operating system, but that doesn't seem to be what you're talking about. No one ias asking it to be an integral part of Debian (like, Essential: Yes). We are asking to make it an Optional part of Debian. I see this as software that is free (it meets all aspects of the DFSG) that improves the quality of implmentation of the OS by allowing user to help themselves in their attempts to make the Debian OS run on certain hardware with less than stellar free software support. I hink that the Quality of implementation would suffer if we disallow this DFSG-compliant software from being a part of Debian. manoj -- As well look for a needle in a bottle of hay. Miguel de Cervantes Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 29 Mar 2006, Raul Miller spake thusly: On 3/28/06, Manoj Srivastava [EMAIL PROTECTED] wrote: On 28 Mar 2006, Raul Miller spake thusly: I think the difference has to do with intent, and expected use patterns -- not just at the command line, but in overall terms. And a related question is: what free software effort would be harmed by putting ndiswrapper in config? Err, wrong question. End users benefit from having this interface to networking drivers around; it gives them more freedom in dealing with hardware they might not have a choice about. How was that the wrong question? Our goal isn't to dump as much stuff out of Debian as possible unless some free software effort is impacted. Our goal is to produce the best free OS out there, imparting maximal utility to our users. Shouldn't we make a distinction between short term benefits and long term benefits? I do not see a temporal dimension here, really. There is an implementation of a tool chain that allows users to wrap drivers written for another OS. The tool chain is licensed under a free license. Shouldn't we be focusing on development issues here? No, we should be trying for balance between development and unitlity to end users -- as long as the software under discussion is free. If the only issue was short-term end-user benefits, everything in non-free could go in main. Straw man. Helping users make use of hardware they are saddled with adds to the quality of implementation; and since users come high on our list of things to care about, we should not be looking at is some free software effort damaged if we move things out of debian, even if users selecting just debian (like, CD based users in areas with poor network connectivity) have to jump through hoops But what what distinguishes ndiswrapper from anything else in contrib? Like gcc, it is ready for tyhe user to provide input for it to process. Like gcc, it needs input to produce output (wrapped loadable kernel module), but does not _depend_ on the input, any more than gcc does. Basing classification on some nebulous “intent” rather than well defined licensing terms should be avoided -- and utility of software is also highly subjective. There is a free CIPE driver you can test your install of ndiswrapperon. Yup, there are better implementations -- native implementations -- of that driver, but the sub optimal utility does not prevent us from distributing (*shudder*) vi. Or brainfuck. If ndiswrapper is not in my universe, I may never get around to writing fee windows drivers that could also be used on Linux :) I don't understand this one. Why wouldn't Contrib be in your universe? It is not in Debian. manoj -- PURGE COMPLETE. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#353277: ndiswrapper in main
On 29 Mar 2006, Raul Miller said:
On 3/29/06, Manoj Srivastava [EMAIL PROTECTED] wrote:
But what what distinguishes ndiswrapper from anything else in
contrib?
Like gcc, it is ready for tyhe user to provide input for it to
process. Like gcc, it needs input to produce output (wrapped
loadable kernel module), but does not _depend_ on the input, any
more than gcc does.
Here's an example of the user providing input for gcc:
$ cat example.c END
#include stdio.h
main() {
printf(%g\n, 3.14159*7*7);
}
END
$ gcc example.c -o example; ./example
153.938
I don't know how to do something like this with ndiswrapper.
Since I'm ignorant, could you provide an example?
Does the fact we are boith ignorant mean that the authors and
users of ndiswrapper be penalized? I don't know how to use a large
number of interpreters and compilers in Debian (scheme, python,
...). Presumably, you, too, are not omniscient (If you are, I do
apologize, god). If there is an intersection of these sets, should it
have a bearing on the freeness of the packages that live in that
intersection?
If ndiswrapper is not in my universe, I may never get around to
writing fee windows drivers that could also be used on Linux :)
I don't understand this one.
Why wouldn't Contrib be in your universe?
It is not in Debian.
I don't understand why that means it's not in your universe.
Cause I am all fere and pure, dude. Do try to keep up :)
manoj
--
One man's mate is another man's passion. Jeff Daiell's description
of adultery
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 28 Mar 2006, Raul Miller spake thusly: I think the difference has to do with intent, and expected use patterns -- not just at the command line, but in overall terms. And a related question is: what free software effort would be harmed by putting ndiswrapper in config? Err, wrong question. End users benefit from having this interface to networking drivers around; it gives them more freedom in dealing with hardware they might not have a choice about. Helping users make use of hardware they are saddled with adds to the quality of implementation; and since users come high on our list of things to care about, we should not be looking at is some free software effort damaged if we move things out of debian, even if users selecting just debian (like, CD based users in areas with poor network connectivity) have to jump through hoops Also, you need to look at how many future efforts you are encouraging -- or discouraging -- by your treetment of this freely licensed module wrapping tool chain. If ndiswrapper is not in my universe, I may never get around to writing fee windows drivers that could also be used on Linux :) manoj not happy about the quote picking ai -- Every absurdity has a champion who will defend it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 26 Mar 2006, Raul Miller told this: The ambiguity is in the resolution's interpretation of the quoted policy: ... must not require a package outside of _main_ for compilation or execution ... Does no-operation or substandard operation satisfy requirements for execution? Well, yes. Consider the case that I write up a compiler for a new language in C++ or ruby. Can I put this compiler in main? Even if there is no public repository of code in this new language? My sense is yes, a compiler does not need the presence of code in order to be free -- as long as the license of the code itself is free. Should this change if I were to put code out there in the new language under a non-free license? I think not. Should things change again if I put freely licensed code on a web page? If I packaged that code for Debian? In my opinion, no. What if it was not a compiler, but an emulator of a virtual machine? Until there is code that can run on the virtual machine, there is nothing for the emulator to show. ndiswrapper seems to fall into similar situation: /usr/sbin/ndiswrapper -i filename.inf /usr/sbin/ndiswrapper -l /usr/sbin/ndiswrapper -m depmod -a modprobe ndiswrapper Looks very similar to a tool chain invocation: compile, link, install. The only argument I have seen so far seems to imply that I can't package up new emulators or compilers unless I also provide free source code for these to process, I am not sure I think that expands freedom in any tangible manner. manoj -- Language shapes the way we think, and determines what we can think about. Whorf Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 22 Mar 2006, Anthony Towns stated: On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote: On 3/7/06, Ian Jackson [EMAIL PROTECTED] wrote: Why does contrib exist ? [essay elided.] So is there an alternate proposal to http://lists.debian.org/debian-ctte/2006/03/msg00037.html so we can have a vote and make a decision? AFAICS we've discussed this pretty thoroughly. I am going to be out of town for the latter half of next week, so if a vote comes up when I am gone, I support the resolution in the mail: http://lists.debian.org/debian-ctte/2006/03/msg00037.html I am not sure I see that it is at variance with published policy, nor do I see why it makes contrib ambiguous, really. manoj -- The existence of god implies a violation of causality. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Flamewars and uncooperative disputants, and how to deal with them
Hi, If we fail to come to a conclusion for a given problem based on technical merit, I see no reason that we should not reward collegiality. IOW, I agree. manoj -- Signs of crime: screaming or cries for help. The Brown University Security Crime Prevention Pamphlet Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 6 Mar 2006, Anthony Towns said: Either way, I propose the following, call for a vote on it, and vote in favour: WHEREAS 1. The committee has been asked by Robert Millan, the submitter of Bug#353278 and a former developer, to overrule the decision by the maintainer of the ndiswrapper package, Andres Salomon, to include that package in the main component of the archive, and for it to be moved to the contrib component; and 2. The committee is empowered under section 6.1(4) of the constitution to overrule a maintainer by a 3:1 majority vote, and empowered under section 6.1(1) to decide on any matter of technical policy; and 3. The purpose of the ndiswrapper package is to provide an ABI layer on top of the Linux kernel that is compatible with the interface for Windows NDIS drivers, and that in order to provide this compatability layer, no non-free software is required; and 4. The primary use for this compatability layer is to run non-free Windows drivers for hardware not directly supported by Linux, though a very limited number of free drivers using the NDIS format also exist; and 5. The technical policy in this matter states that: (debian-policy 3.6.2.2, section 2.2.1) [...] packages in _main_ * must not require a package outside of _main_ for compilation or execution and: (debian-policy 3.6.2.2, section 2.2.2) Examples of packages which would be included in _contrib_ are: * free packages which require _contrib_, _non-free_ packages or packages which are not in our archive at all for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. THE COMMITTEE CONCLUDES THAT 6. It is appropriate for the committee to consider this request; and 7. The current ndiswrapper package does not require any non-free software at either compilation time or installation time to fulfill its designated purpose; and 8. As such the ndiswrapper package complies with current technical policy as regards to its suitability for main; and 9. If the ndiswrapper package come to depend on non-free software at compilation time or installation time, such as by prompting the user for a Windows driver CD, at that time the ndiswrapper package would be required to be moved to contrib. IN ADDITION 10. The committee endorses the decisions of the maintainer of ndiswrapper and the ftpmaster team in including the package in the main component as being in compliance with Debian technical policy; and 11. The committee endorses the existing policy on the suitability of packages for the main and contrib components; and 12. The committee offers its thanks to Robert Millan for raising the issue; to Wouter Verhelst and others for their input on the topic; and to Andres Salomon for his ongoing efforts in maintaining the ndiswrapper packages. I vote in favour of this motion. manoj -- ... all the modern inconveniences ... Mark Twain Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpfHbp33Tnvq.pgp Description: PGP signature
voting for the chair
Hi, 6.1.7: ... the committee votes starting one week before the post will become vacant (or immediately, if it is already too late). So, the voting period started when Ian said he was stepping down. The vote finishes when all the members have voted, or when the voting period has ended. So, no short circuit when the outcome is no longer in doubt. The result is determined using the method specified in section A.6 of the Standard Resolution Procedure. Since nothing is said about the voting period, I would say it defaults from the section 6.3 Procedure: 6.3.1 ... There is no minimum discussion period; the voting period lasts for up to one week, or until the outcome is no longer in doubt. Members may change their votes. There is a quorum of two. The since 6.1.7 explicitly talks about the ending period, it overrides the general procedure, but the period of one week applies from 6.3.1. Of course, a GR to disambiguate section 6.1.7 would be OK too :) manoj -- The only real way to look younger is not to be born so soon. Charles Schulz, Things I've Had to Learn Over and Over and Over Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Re: Induction of new members to the technical committee]
Hi, With bdale voting yes, along with me, and there being no responses for a week, the quorumn of two was met, and the motion passes. -- So I hereby propose that this committee recommend to the the Debian project leader the following individuals to be candidates for induction into the technical committee (as per section 6.2.2 of the constitution) o) Steve Langasek [EMAIL PROTECTED] o) Anthony Towns [EMAIL PROTECTED] o) Andreas Barth [EMAIL PROTECTED] -- So, these individuals are commended for inclusion in the technical committee, and the project leader is encouraged to extend these invitations. manoj -- I demand IMPUNITY! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Induction of new members to the technical committee
Hi, Given that some of the current members of the technical committee have been unavailable for a while, and others have moved on from an active involvement with Debian, the technical committee, in conjunction with the project leader, would like to appoint new members to bring the committee back up to strength. So I hereby propose that this committee recommend to the the Debian project leader the following individuals to be candidates for induction into the technical committee (as per section 6.2.2 of the constitution) o) Steve Langasek [EMAIL PROTECTED] o) Anthony Towns [EMAIL PROTECTED] o) Andreas Barth [EMAIL PROTECTED] I would like to call for a public vote on the appointment (subject to acceptance) as per section 6.3.4 of the constitution. manoj -- Would that my hand were as swift as my tongue. Alfieri Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpv7pc1bhDZt.pgp Description: PGP signature
Removing long inactive members from the technical committee
Hi, I am formally proposing a resolution to remove the following members from the technical committee: o) Wichert Akkerman, since he has indicated that he is no longer actively involved with the project, and asked to be let go, o) Guy Maor , since it has been literally years since there has been any communications from Guy on the tech ctte, o) Jason Gunthorpe, for the same reason. Branden and fellow committee members, please send in your votes for or against the removal of each of these individuals. For the record, I vote in favour of removing these folks from the committee, and I thank them for their service to the project in the past. manoj -- People will accept your ideas much more readily if you tell them that Benjamin Franklin said it first. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpefPxyqqwuX.pgp Description: PGP signature
Re: Always ask for root passowrd twice, even on critical priority installs?
On Mon, 13 Jun 2005 11:30:52 -0400, Raul Miller [EMAIL PROTECTED] said: If so, here's another way to look at this issue: It's a problem in the prompting facilities used by debconf. In principle whenever debconf prompts a user for type password, it should prompt twice (in other words, any prompting facility which treats password different from string should have been required to ask twice). What we're thinking you should be doing here is working around a flaw in the architecture of debconf where this doesn't happen automatically. Another way of looking at the interface is this: When one uses webforms, or windows password utilities -- there are two fileds, presented all at once to the user. You enter the password once for the first variable, and then you tab over and reenter it for the other variable. So, don't think of it as entering the value of the same variable twice -- it is two separate variables, which, the business logic states, need to be identical. You can do this in debconf by having _two_ variables -- passwd and confirmation; and the logic in the .config file determines if the two variables are identical or not. This way, you can let each of the two variables continue to have defaults (say, if optionally updating the password while modifying user profile). I think this better fits the needs of the business logic and the current implementation of debconf. manoj -- Oliver's Law: Experience is something you don't get until just after you need it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: testing committee email (and minor essay)
On Fri, 11 Mar 2005 20:25:05 -0500, Raul Miller [EMAIL PROTECTED] said: The committee has never been popular. People have objected to its actions, its inactions, its existence, and its members. Currently, there seems to be a number of people calling for new committee members. I would welcome fresh blood to the committee. I am not sure I agree wit the critics of the inaction. I have always felt that invoking the ctte was an action of the last resort, when all normal attempts at resolution had failed. Due to the broad powers over technical issues the ctte has, it is nice that it is not invoked more often. I am not sure that a body with so much power, and so little practical oversight, should be more proactive and go poking around without being invited, really. Unless my memory serves me incorrectly, the issues that have been brought forth before the ctte have come to a resolution, with or without a direct pronouncement ex-cathedra from the ctte. Indeed, that is a welcome outcome, rather than a failure; since the problem was resolved. The job is to see that the issues are settled, not to make pronouncements. Despite this (or perhaps because of this) there has been a singular lack of people saying anything resembling: I'd like to join the technical committee. Here's why I think I'd do a particularly good job ___... Would anyone like to step down and let me take their place, or could the active members allow me to replace someone inactive? We do not need people to step down in order to add new blood. And we could go about recruiting, either coming up with a list of names and discreetly asking people if they wanted to serve, or letting people nominate others. There are a number of people whose technical process of diplomatic abilities I admire in the project, it would be the time to ask such people. manoj -- Gallantry consists in saying the most empty things in an agreeable manner. La Rochefoucauld Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#266837: rpvm_0.6.2-1_hppa: FTBFS: relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
On Fri, 20 Aug 2004 08:21:11 -0400, Raul Miller [EMAIL PROTECTED] said: On Fri, Aug 20, 2004 at 01:22:44PM +0200, Steinar H. Gunderson wrote: The entire discussion here is whether #266762 is wishlist or not. I claim it is; the rpvm people claim it is serious. It's a serious bug for rpvm, it's a wishlist bug for pvm. This is my take on it as well. manoj -- An ounce of prevention is worth a pound of purge. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: release policy
On Wed, 7 Jul 2004 11:17:23 -0400, Raul Miller [EMAIL PROTECTED] said: Attached, below, is AJ's release critical policy, in the context of sarge. I'm thinking we should ratify it, as is. As soon as possible. I think we should edit the bit about dfsg freeness may become a policy post sarge bit: 1. DFSG-freeness Code in main and contrib must meet the DFSG, both in .debs and in the source (including the .orig.tar.gz). Documentation in main and contrib must be freely distributable, and wherever possible should be under a DFSG-free license. This will likely become a requirement post-sarge. That last sentence should not be ratified as such by the tech ctte, given the last two GR's. As it stands, it is not merely likely. This will be a hard requirement when SC 1.1 becomes effective post Sarge Apart from that, it is an excellent document. I'm thinking we should ratify a changed document [which is more restrictive on DFSG issues] for releases following sarge. The Social contract (v1.1) is pretty authoritative, no? What do you have in mind? manoj -- Of course, someone who knows more about this will correct me if I'm wrong, and someone who knows less will correct me if I'm right. David Palmer ([EMAIL PROTECTED]) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Social Contract GR's Affect on sarge
On Fri, 25 Jun 2004 20:06:25 +0100, Ian Jackson [EMAIL PROTECTED] said: Reading debian-vote, I think it would be helpful if we stated our opinion formally. There still seems to be some dispute. I agree with the first part of this. I therefore hereby propose the following resolution and call for a vote. I'm hoping we can get enough of the TC to vote in favour to get an official resolution well before the close of voting. Headline advice: we recommend that Developers vote as follows: either B,D,E,C,A,F,FD (2453167) Grandfather clause for Sarge or D,B,E,C,A,F,FD (4253167) Rescind Social Contract changes It seems to us that: * The Social Contract as amended is unambiguous, and prevents the release of Sarge as-is. * We would like to see Sarge's release go in parallel with the time-consuming fixes to the copyright problems. Therefore: * The Developers must decide whether to waive or amend the Social Contract. If no waiver is forthcoming, then Sarge will not be released until all of the problematic material has been sorted out. * If such a grandfather resolution does not pass with a 3:1 supermajority then the Social Contract is not waived and sarge should not be released until the non-free stuff is removed somehow. We are pleased to see this waiver process is happening and will probably result in a resolution in time. So: * The Release Manager should plan for such a resolution to either grandfather the existing situation, or permit the release of Sarge some other way. To do anything else would be to prejudge the issue. * Of the General Resolution currently being voted on, the effects as we see them on the Sarge release process are as follows: B,D,E: Sarge will go ahead (software quality permitting). C: Sarge will be delayed to remove certain non-free items not covered by the grandfather clause (see below). A: Sarge will go ahead if it can be done by 2004-09-01. F: Sarge will be delayed to remove the non-free `non-software'. OK so far. We offer the following observations advice to the Developers as they cast their votes: [SNIP] I strongly feel we should not be in the position of advising people how to vote. We also note that the Technical Committee has no formal authority in this area. The questions being disputed are not technical. Any authority we have derives only from Release Manager (who has delegated this controversial decision to us) and of course from our power to state our opinions. This paragraph is OK as well. manoj -- He who wonders discovers that this in itself is wonder. M.C. Escher Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: [Fwd: Re: Bug#254598: Name of the Debian x86-64/AMD64 port]
On Tue, 22 Jun 2004 20:46:17 +0100, Ian Jackson [EMAIL PROTECTED] said: Ian Jackson writes (Re: [Fwd: Re: Bug#254598: Name of the Debian x86-64/AMD64 port]): Pretty much all of these lead me to conclude that we should resolve along the following lines: I was slightly unclear about whether that was a formal proposal, and in any case didn't call for a vote. But people seem to like it so I hereby propose the following resolution, and call for a vote: The Technical Committee have considered the question of the name of the Debian x86-64/AMD64 port. We resolve that: * In our opinion the porting team are the right people to be deciding on the architecture name, in general. * In our opinion there is no significant technical reason to interfere with the porting team's decision; on the contrary, we largely agree with the porting team's choice of `amd64'. * In our opinion architecture names with underscores in should not be used because of the existing use of underscore as a separator in package filenames, etc.; accordingly we advise that these should be avoided. * Since names with hyphens in are currently only used when separating variant kernel-processor combinations, we advise that this practice should be continued. * Therefore, insofar as we are granted any authority by the constitution, we uphold the porting team's choice of `amd64'. * We request that dpkg should be changed to use `amd64'. Should the dpkg maintainers decline, we will seek clarification of the Constitution and consider using our powers in 6.1(1), 6.1(2) or 6.1(4) to overrule the dpkg maintainers. I vote yes. manoj -- The meat is rotten, but the booze is holding out. Computer translation of The spirit is willing, but the flesh is weak. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpRYspGMHIaI.pgp Description: PGP signature
Re: Bug#254598: Name of the Debian x86-64/AMD64 port
On Thu, 17 Jun 2004 16:36:05 -0400, Raul Miller [EMAIL PROTECTED] said: Does anyone have any reasonable objection to Stephen Frost's statement that the porting team should get to choose the name of the port? Sounds fair to me. manoj -- I don't know if it's what you want, but it's what you get. :-) Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: debian-ctte mailing list and spam
On Wed, 16 Jun 2004 19:12:42 -0400, Raul Miller [EMAIL PROTECTED] said: Personally, I think we need a better heuristic. I agree. My ideal would be a combination of: If the email is signed by some pgp key that we can validate, it's OK. Otherwise, send the user some token (with polite and informative instructions) and if they respond with that token to some control address within a week, forward the message to the list. Personally, I do not like this; especially since these may mean we are making people (domain experts) who are helping us resolve problems jump through hoops; my personal practice in this matters is not to respond to these challenge messages (unless the challenge message was in response to mail I did not send, where it depends on the degree of irritation I feel as to whether I respond or not). I deal with spam on about a dozen debian mailing lists, and I see this list as little different. I heartily recommend crm114 to people who want to eliminate spam from their inboxes. manoj -- I turned my air conditioner the other way around, and it got cold out. The weatherman said I don't understand it. I was supposed to be 80 degrees today, and I said Oops. In my house on the ceilings I have paintings of the rooms above... so I never have to go upstairs. I just bought a microwave fireplace... You can spend an evening in front of it in only eight minutes. Steven Wright Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Our supermajority requirement has changed !
On Tue, 25 May 2004 23:10:59 +0100, Ian Jackson [EMAIL PROTECTED] said: The plain language of the committee's power to overrule a developer, in 6.1(4), says `this requires a 3:1 majority'. However if one tech ctte member dissents the current wording of A.6(3) would _four_ other ctte members are required, ie a 4:1 majority, as otherwise the number of yay-sayers would not be _strictly greater_ than 3 times the number of nay-sayers. Yes, there is a discrepancy between 6.1(4) and A.6(3). If it were possible to have 9 members of the tech ctte, then a 3.5:1 super majority would also be possible, but the ctte seems to ve restricted to 8 members. The change also had the effect of remvoing the casting vote for choices between the default option and another option, so for example if we have 3 votes A:FD:B and 3 votes B:FD:A, then FD would win, whereas previously the casting vote would decide. So, I think this is a bug which should be fixed. This one is a difference, but not necessarily a bug. If the committee is so split upon a course of action, and each option is unpalatable to an equal number of members, it does seem reasonable that the default option prevail. If we did get votes like A B : FD (or equal numbers of A:B:FD and B : A : FD votes), then the chairperson still gets to decide between A and B; and again, this makes sense, since the committee wanted a resolution other than the default option, but were split on which option to select. Manoj, as Secretary, can you confirm that you agree with my interpretation of A.6(3) ? Do you have an opinion about the apparent conflict with the plain language of 6.1(4) ? I think the right fix is to delete the word `strictly'. If we do This is one of two possible options; one could just as easily add the word strictly to 6.1(4). I am personally inclined to remove the strictly greater requirement from A.6(3) (indeed, my initial coding up of the vote method in devotee did not adhere to strictly greater), but I guess the project membership could decide to go the other route. delete the word `strictly' it might be better to invent a different phrase for `defeat[s] the default option' in A.6(3) because `defeats the default option' in A.6(3) means something different to `defeats [an option which happens to be the default option]' in A.6(4) onwards. Perhaps replace `defeats' with `matches'. In a.6.4 onwards, there is no mention of the default option, since it is no longer treated any differently than any other option. I do not see any ambiguity here; perhaps I am missing something. manoj -- Any fool can tell the truth, but it requires a man of sense to know how to lie well. Samuel Butler Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Social Contract GR's Affect on sarge
On Tue, 27 Apr 2004 21:07:37 -0600, Bdale Garbee [EMAIL PROTECTED] said: [EMAIL PROTECTED] (Raul Miller) writes: [1] We need to make sure we know who is active. Maybe we should have a show of hands on who on the committee is actively reading this thread? I'm here, reading, and thinking. Nothing productive to inject into the discussion yet. Maybe there's some improvements that coud be made on that suggestion? Based on what I've heard today, I think we should expect at least one, and perhaps several, GRs to be proposed in the next few days. Well, we have a properly seconded proposal, and an amendment which has almost got enough seconds. Can we let the wording of the gr be, and just recommend that the GR under discussion is our recommended solution, and let the developers decide on the wording as they go along? manoj -- The real reason psychology is hard is that psychologists are trying to do the impossible. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Social Contract GR's Affect on sarge
On Mon, 26 Apr 2004 11:23:51 -0400, Theodore Ts'o [EMAIL PROTECTED] said: You forgot one other thing. We'll also have to strip **ALL** **FONTS** from Debian, since fonts come in binary form, and we don't have anything approaching the preferred form for modification for fonts. In particular, the Truetype Bitstream Vera fonts which were so generously donated by Vera was generated not only using propietary source files, but also using propietary non-free programs. Are you sure about that? The 100dpi, 75dpi (and other bitmapped fonts) do seem to come with the sources (indeed, I am given to undertand that when the uTF-8 extentions were added by Markus Kuhn, only free software was used). manoj -- Just remember: when you go to court, you are trusting your fate to twelve people that weren't smart enough to get out of jury duty! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Referring bug #166718 and the initial groups issue to the TC
On Wed, 31 Mar 2004 14:15:00 -0500 (EST), Sam Hartman [EMAIL PROTECTED] said: The problem is fairly simple. Some of our users actually want to use their systems once they get it installed. Particularly, they'd like to be able to do things like play sound, access their floppy drives and cdroms, etc. Currently, to do that, you need to be added to groups that have access to devices. I think some of this comes from the FHS rather than just decisions internal to Debian. Perhaps when Debian and the FHS originally made this decision, users could be expected to simply add themselves to groups if they noticed they needed the permissions associated with these groups. However as Debian has gained appeal to a wider audience and as peoples' expectations of usability increase, users want more reasonable default behavior. The proposal in bug #166718 and the bugs merged with it is for the initial user to be added to some set of groups. Karl does not like this proposal because it only solves the problem for the initial user. That's great until you actually start to take advantage of the fact your Debian system is multi-user. It seems to me that this ought to be local policy. Can you explain to me how the proposed solutions take site policy into account? Would it be feasible instead have a simple way of enabling one or more users (perhaps a site wide list of users, with exceptions for services) to use a specific service? Would there be security issues involved in giving wholesale access to hardware resources? Traditionally, UNIX has not been in the practice of automatically adding users to groups, and I think we need to be careful if we decide to break from universal practice. manoj -- Why did the Roman Empire collapse? What is the Latin for office automation? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console
Hi, I would like to add the dissenting opinion: Though I personally would probably include vesafb and fbcron in the kernel, I don't think I have heard strong enough arguments to justify overriding the maintainers judgment: a) Not every possible modules is included in even our modular kernels; people have to compile custom kernels for various hardware components b) Not all file systems are compiled into the kernel c) I do not see why vesafb users are special, and root on JFS people are not; why the former can't compile their own kerels, the latter must. d) Most users douse X, e) people can also use text consoles if they do not use X. I have not seen compelling arguments why one things vesa users are special, or indeed, numerous; not enough to convince me to substitute my own judgment over the person responsible for the package, and who does all the work for maintaining it. Historically, the debian developer has been allowed a fair degree of autonomy over their package; this is not really a technical problem, really, it is a judgment call; and I think we should strive not to override a developer unless we have more than gut feelings and opinions. For this reason, I hereby vote against the proposal. manoj -- In the same way that a wrongly handled blade of grass will cut one's hand, so a badly fulfilled life in religion will drag one down to hell. 311 Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpLZ3YlpbeAC.pgp Description: PGP signature
Re: [herbert@gondor.apana.org.au: Re: Bug#161931: kernel-image-2.4.19-k7: VESA driver for console]
Hi, All right. If we are embarking on the path of substituting the maintainers judgment by our own, I personally would include both vesafb and fbcon as builtin, and address the other non modular drivers as and when I feel the demand for them has increased to the point that including them is justified. Unfortunately, this is a matter of exercising judgment, and I do not have solid reasoning or datas to back up my gut feelings. What I am unsure about is whether I have the grounds to cause my judgment to override the maintainers in this case. I don't have the hubris to assume that I know so much better than the maintainer. manoj -- I figured there was this holocaust, right, and the only ones left alive were Donna Reed, Ozzie and Harriet, and the Cleavers. Wil Wheaton explains why everyone in Star Trek: The Next Generation is so nice Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Bug#119517: pcmcia-cs: cardinfo binary needs to move into a separate package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Here is my vote, though couched in terms biased the other way: 1BVersion B (split packages, ensure that properly installed packages actually work) 2FD Further Discussion 3AVersion A (Allow packages to be shipped broken by design) manoj - -- Lady Nancy Astor: Winston, if you were my husband, I'd put poison in your coffee. Winston Churchill: Nancy, if you were my wife, I'd drink it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Processed by: Debian GNU/Linux - Emacs - Gnus - Mailcrypt iD8DBQE9NuaXIbrau78kQkwRAu5eAJ4+LYrYXGKHjQ0xrTmJhd8vUrWtJgCgvqao bXSCQgpIu6QqnpnuyHVIN9Y= =tten -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#97671: RFD: Essential packages, /, and /usr
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden If: Branden * Release critical bugs are _very_ rare.; and Branden * Release critical bugs should be the domain of the Release Manager, Branden Then we really don't need a tight connection between the Branden serious severity and release-criticality at all. Branden Release-criticality can be a tag -- whether that is Branden expressed in debbugs along with security, moreinfo, Branden patch and so forth or in a webpage like bugscan is Branden immaterial. Branden This tag -- no matter how it is expressed -- is the Release Branden Manager's domain. People can propose that a bug be treated Branden as release-critical and, perhaps, if it seems warranted, we Branden can make this a debbugs tag and possibly automatically set Branden it for all critical, grave, and serious bugs. Branden The Release Manager can strip the release-critical tag off Branden of any bug he wants. This is how things have *always* Branden worked in reality. If a bug is truly a showstopper for a Branden release, we don't release with it. We either wait, fix the Branden bug, or drop the package. I find myself in strong and vehement agrement with Branden on this point. manoj -- I think the sky is blue because it's a shift from black through purple to blue, and it has to do with where the light is. You know, the farther we get into darkness, and there's a shifting of color of light into the blueness, and I think as you go farther and farther away from the reflected light we have from the sun or the light that's bouncing off this earth, uh, the darker it gets ... I think if you look at the color scale, you start at black, move it through purple, move it on out, it's the shifting of color. We mentioned before about the stars singing, and that's one of the effects of the shifting of colors. Pat Robertson, The 700 Club Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Anthony Towns writes (Re: Technical Committee: decision on #119517?): I think everyone agrees that it's a Bad Thing to have packages like this, the question is really whether it's completely unacceptable to ever do it, or if having packages with a single fairly trivial binary and different depends: is enough to justify it. If it is a Bad Thing, and we are trying to make the best distribution of Linux, does it not follow we consider this a bug, and try to fix it? Ian Indeed. I think that this kind of tradeoff between different Ian kinds of costs is best left to the package maintainer. Unfortunately, unless this determination matches the one the users make, we have an issue. If the user thinks the program is broken, they shall report a bug. If it is summarily closed with essentially the statement I do not agree, the result is frustating to the suer, who sees this as a flaw in the implementation (and we are all agreed it is a Bad Thing), and every such incident thwarts ones desires to report bugs. The BTS, and determinati0on of what is broken, do not exist in a vacuum. manoj -- A programmer from a very large computer company went to a software conference and then returned to report to his manager, saying: What sort of programmers work for other companies? They behaved badly and were unconcerned with appearances. Their hair was long and unkempt and their clothes were wrinkled and old. They crashed out hospitality suites and they made rude noises during my presentation. The manager said: I should have never sent you to the conference. Those programmers live beyond the physical world. They consider life absurd, an accidental coincidence. They come and go without knowing limitations. Without a care, they live only for their programs. Why should they bother with social conventions? They are alive within the Tao. Geoffrey James, The Tao of Programming Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Manoj, have I represented you fairly and accurately ? Is there Ian anything else you think you wanted to say ? Apart from my quality of distribution arguments, yes, that is a fair assessment. Actually, it was one of your arguments about renaming programs/packages that started me down this path -- if a user has a friend running some other distribution, and they both try program foo -- it works on the other distribution, but not on Debian, and both sets of packages are installed correctly, I think we shall not compare favourably. I would hate to get the reputation that programs on Debian do not necesarily work unless one systematically installs all supposedly optional packages (run time link failures are hard to explain as anything but broken programs to the non-cognoscenti) manoj -- The church saves sinners, but science seeks to stop their manufacture. Elbert Hubbard Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony On Sun, Apr 28, 2002 at 02:22:41PM -0500, Manoj Srivastava wrote: There is also the matter of perception (quality of implementation is a subjective matter). Anthony There're other quality of implementation issues that affect Anthony such perceptions too, though: Sure, there are bazillions of such cfriteria, and each one adds to the reputation. Or detracts from it Anthony one is the number of pointless little packages you have to Anthony find and install to have your system continue working the Anthony way it used to. If you are talking about holding the package count to a reasonable number, easily encompassed by a user, you have already lost. What we need is to make package selection, and presenting the user with related packages, and making package selection a useful, if not enjoyable, experience. By degrading user experience by presenting packages with programs that are broken when properly installed helps nobody. Anthony Programs is not a good division to make. Packages Anthony is. Features is. What's a program and what isn't is an Anthony implementation detail, and little more. But people interact with programs, really, not packages. We had an invariant: set up a package right, and things work as advertised. Anthony We've never had that invariant. pcmcia-cs has been this way Anthony for ever, apt-preconfigure has been this way since woody, Anthony and there're a handful of other packages which have moved Anthony from or to it at various times. And I posit these packages have had intermittent bugs. We certainly have never had a bug free release since I joined the project in '95, no. Anthony If you install all the dependencies, and nothing more, all Anthony your programs will work, except for a few that you don't Anthony care about anyway that have good reason to be as they are. I see. I think your telepathic abilities are working less well than you imagine. manoj -- This is a logical analogy too... anyone who's been around, knows the world is run by paenguins. Always a paenguin behind the curtain, really getting things done. And paenguins in politics--who can deny it? Kevin M. Bealer, commenting on the penguin Linux logo Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Err, the behaviour you see is AIUI the same you get from *any* failure Ian by fvwm to open or parse the config file; ie, it's fvwm's failsafe Ian response (which is reasonably good, but could do with better error Ian reporting in most configurations). Yes, it is. I did not see lionk failure, and, even in an airport in Zimbabwe, I can then edit my config file and make fvwm work. A misconfigured application is understood to be user error, a linker failure is hard to characterize in that fashion, and even harder to fix without access to the archive. manoj -- The two things that can get you into trouble quicker than anything else are fast women and slow horses. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release-critical bugs, and #97671
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Manoj Srivastava writes (SuperCite undone): Ian I don't think this quite follows, as you put it here. I agree Ian that it's unhelpful to rely on submitters' judgement to Ian accurately prioritise bugs, and that a good way to help Ian submitters do a useful thing is to give them objective criteria. So far, so good. Ian But, that doesn't mean that the severities need to remain set by Ian those objective criteria. Someone other than the submitter, Ian with a greater overview of the whole package or distribution, Ian might have a better idea, and might reasonably apply subjective Ian judgement. To what end? Why make the objective criteria malleable? When one discards objective criteria for classifying bugs, one merely opens the door for more disruptive disagreements between reporters, and even fellow maintainers. With around a 1000 developers and counting, there is unlikely to be agreement amongst developers. When you bring in policy conformance, and RCness, the maintainer may no longer be the one with the best knowledge of the issues. Also, just because a person is the maintainer does not mean they are more knowledeable than the reporter. (I would prefer not to name names here). Ian So, you think that the bug severity should not be used to record the Ian bug's releaseability. Indeed. Ian The question is then, what other useful information can we use it to Ian record, or are we trying to use it to record, in a way that supports Ian everyone in our work ? It represents impact on the system. It categorizes the bug. It helps people understand potential damage the bug could cause, at a glance. It keeps packages out of testing. Releases occur farly seldom, and whether a certain version of a package is releasable or not is of importance to a small number of people for relatively short intervals of time. I think we should stop overloading the BTS for a TODO list for the project and developers. In this day and age we have better tools both for personal todo lists, and groupware products for the project. If the project thinks it is so important, why do we not set up a wicki? or other such tool? It is easy enough to do so. Ian For some bugs, namely approximately the ones corresponding to Ian the current definitions of severity levels grave and critical, Ian it is very important to the whole project to get them fixed, Ian because they have bad effects which spread far beyond frequent Ian users of the package. These bugs are high-priority work items Ian for the whole distribution. Quite so. And a maintainer should not have the discretion to junk the objective criteria and label them wishlist on a whim, ot because they do not want to work on it, or it is too hard to fix right now. Ian For most other bugs, the package maintainer, and other people Ian closely involved with the package, are in the best position to Ian decide which bugs are the most serious and which should be Ian worked on first. Quite so. And if they do not violate policy must directives, for the most part they can. Ian If, then, we are not to encode in the BTS severities the Ian releaseability of bugs, but instead use them to prioritise work, it Ian seems clear that at least for bugs which are not `critical' or Ian `grave', the package maintainer should have discretion. Why? Apart from using the BTS as a poorly designed groupware TODO list (I say this, even though I designed policy proposals on top of the BTS, and I know the pitfalls of doing so), this does not seem to be useful. Indeed, by making the classification criteria fuzzy, we reduce the utility of the severity, I think. I mean, important is more or less left to the maintainer. normal i catch all. wishlist and serious should still be left objective. I can see things built on top of a new BTS that would benefit from well defined classification of bugs. Ian Do you follow this argument ? Do you agree with it ? As you can Ian probably tell, I think I'm still feeling my way around this issue. I do follow the argument, but I do not agree, I think we should stop overloading the BTS, and use it for the primary purpose _first_, especially if it causes friction between reporters and maintainers about the severities. And it shall, I fear. manoj -- (null cookie; hope that's ok) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Anthony == Anthony Towns aj@azure.humbug.org.au writes: You need to take this in context though. If they're running in X, then it'll work fine, because xlibs will already have been installed. If they're not running in X, one'll get a linker failure, the other will get a DISPLAY not set failure. Hey why doesn't cardinfo work? It's an X program and you don't have X installed. Doesn't seem particularly hard? (Seems a lot easier than explaining it to the cognoscenti tbh... :) ;-) In this particular case, you got me. In the general case, though, I still think my arguments have merit. I would leave it to the members to decide whether this should affect the recommendations we make in this case. I would like to point out, though, that recommendations of this committee are taken to set a precedence, and perhaps we should be thinking in gernal terms when we make the recommendations. manoj -- Our educational systems may very well be on the threshold of a new and even gloomier Dark Age of the 20th and 21st centuries, unless the anti- intellectualism and confused thinking creationists produce is overcome. Reverend James Skehan Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#97671: 88 Priority violations in woody
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden Yes, and aj's insistence that it should stay there, which does not Branden appear consistent with his decision that 88 other serious policy Branden violations should be closed outright. Quite. In the tech ctte mailing list, I am a proponent of the idea that bug severities, since they are set and changed by a large number of people (reporters, who may not be be debian developoers, and maintainers), the criteria for the bug severity ought to be as objective as possible. Whether a bug has enough impact on the system that releasing it would be detrimental is a judgment call, and we have appointed a single person whose judgment we all have agreed to trust for the duration on matters related to the release. These criteria is where a human can exercise common sense, and involves a number of criteria (some thing that is RC before may not longer be deemed to be such as the release nears). Based on his posting on -ctte, I thought aj agreed with me. But if the bug severity is supposed to be fixed and objective, and RCness is separate, I am confused why the xutils bug was _upgraded_ to serious, and these other serious bugs are downgraded. (We already have bugscan to prevent the count from getting confusing due to all these serious but not rc bugs). Branden My personal opinion is that the BTS should serve the Branden developers first and foremost. It *should* also be able to Branden serve the users, but until it has a conception of bugs Branden against versions of packages as opposed to a non-temporal Branden notion of a package, it's going to fill that role only Branden poorly. I think the Release Manager has other tools at his Branden disposal for discernment of release-criticality. Whether Branden those tools work to the satisfaction of a given Release Branden Manager or not is another question. Quite so. But I think a serious bug should still be a serious bug, and no subject to anyone whims -- including the package maintainer. manoj -- Spelling is a lossed art. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#97671: 88 Priority violations in woody
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden The issue is for me is twofold: about the package maintainer Branden being empowered to manage his own bug list for triage Branden purposes, and about the limits of the Release Manager' or Branden another developer's power to make decisions for another Branden developer. The bug severity is well defined: it violates a must directive of policy, and this makes it a serious bug, no matter what anyone, including the maintainer, thinks. (If my postinst does rm -rf /; it is a critical bug, no matter what I think) manoj -- Never put off till run-time what you can do at compile-time. Gries Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Anthony == Anthony Towns aj@azure.humbug.org.au writes: Anthony Drawing the line at the package level gives you a nice way Anthony of thinking about our current arrangements: Depends: ensure Anthony against complete failure whenever possible (contrib packages Anthony and kernel modules being the notable exceptions), leaving a Anthony trade-off between splitting packages or allowing for Anthony degraded functionality which the maintainer gets to Anthony consider. In the case of cardmgr and apt-preconfigure, Anthony degraded behaviour was considered the lesser evil than Anthony having an extra couple of trivial packages. There is also the matter of perception (quality of implementation is a subjective matter). The way it works is this: If a prorgram does not work (and a link failure is as classic a definition of does not work as one can get), the program is broken. If the program is broken, the package is broken (perhaps partially broken, but broken it is). Recommended and Suggested packages are supposed to be optional. Nt having optional packages installed ought not to cause programs to break. Anthony What, exactly, is the difference between having a package Anthony foo provide two binaries foo and xfoo, the former of Anthony which is what most people who use the package care about and Anthony always works, and the latter of which only works if the Anthony xlibs package is installed; and a package bar having a Anthony single binary bar that has a -x mode that pops up a GUI Anthony but dies with an error when the X libraries aren't Anthony installed. How is the latter a graceful degradation but Anthony the former not? The difference? Perception. Hmm. Consider this scenario: I am out in the field (client site, airport) with no connectivity. If an option -x does not work, I say, huh, lemme try it without that option, and I go on. Now, if foo is advertised as an alternative for xfoo, I can see why that is not a big deal (I'll consider the program broken, but the package is not in such a bad state): I'll use foo instead. However, if a program exists, that just does not work, and there is no advertised alternative, well, that is incredibly frustrating. Nothing I can do on the machine can make the program work. The package would be deemed to be broken (read buggy) in either case, but yes, there is a difference, with an advertised alternative, or if the breakage occurs only on some options, the impact of the bug is less. A perception of quality is one of the most treasured attributes we have garnered, in the eyes of the public, random program breakage would tarnish that. Anthony Programs is not a good division to make. Packages Anthony is. Features is. What's a program and what isn't is an Anthony implementation detail, and little more. But people interact with programs, really, not packages. We had an invariant: set up a package right, and things work as advertised. Now, we say, install all possible optional dependency packages, and all that they recommend/suggest, and then maybe, programs you just installed may work. manoj -- The worst thing about some men is that when they are not drunk they are sober. William Butler Yeats Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Manoj Srivastava writes (Re: Technical Committee: decision on #119517?): From reviewing the bug report, Ian Jackson sided with the maintainer, with the opinion that not all binaries shipped with a package need work when the dependencies are satisfied. Dale Scheetz, Jason Gunthorpe, and I disagreed. Ian So, the current situation is as follows: Ian The package pcmcia-cs contains, amongst many other more important Ian things, a binary `cardinfo' which is an X program. It declares a Ian Suggests dependency on the X libraries. Ian The complaint is that this is wrong, and instead either pcmcia-cs Ian should Depend on xlib6g, or the X11 cardinfo program should be split Ian into a separate package. (There was also a fudge suggested, making Ian cardinfo a wrapper script to do something completely different, to Ian avoid using X, if xlib6g wasn't present.) No. The suggestion, which you apprently did not follow, was to provide core functionality of the program regardless of X, and added functionality when X libs are present. In other words, the program, the interface the user sees, actually does something. Ian As I understand it, the supposed principle which is being applied is Ian that it is unacceptable to have a binary in the package which depends Ian on libraries not mentioned in Depends, and that Recommends or Suggests Ian are not sufficient. Nope. The objection is that a package presents an interface to a user to added functionality, and binaries provided by a package are the user interface most commonly seen by users towards that. Any binary that fails is a bug in the package. Mitigating factors are that a package may not be properly installed. If I install a package properly, all dependencies satisfied, all binaries work. Added recommended or suggested packages may enhance functionality; but the b i n a r i e s M U S T w o r k. Ian 1. I think the current situation is fine. The other suggested Ian approaches to this issue have much worse effects than a slightly ugly Ian but perfectly informative error message. I disagree strongly. This is a quality of implementation issue. When I go on a machine, fire off a binary, and it faults, I know the machine is broken. Ian Forcing the user to always install the X libraries with pcmcia-cs is Ian clearly unacceptable. Ok. Ian Splitting the package up is gross overkill - the general cost of an Ian additional package to maintain, update, select, install, cope with Ian dependencies of, find, etc. etc. is considerable. Really? I would rahtter add one more package to the nearly 10k list than have broken systems all over the place. Suggests does nto mean install suggested packages, or else some binaries are just going to fail. Why the hell have a dependency system with differeing levels at all, if you can no longer be sure what one needs install in order to have binaries work? Ian Note that a person who forgets to install X when they wanted Ian cardinfo is even more likely to fail to spot the proposed Ian pcmcia-cs-cardinfo package; when they want to run cardinfo Ian because they heard about it from a colleage running some other Ian distribution, we serve them better by giving them the ld.so Ian error message than by making the file vanish ! Debian is already different enough that this is not a major issue. The added package can be mentioned in the cardinfo description, be recommended by the non X package, and be mentioned in the documentation. Ian The only remaining approach suggested was to make cardinfo a wrapper Ian script which would either invoke the real X cardinfo program, or do Ian some kind of text-mode alternative if X wasn't available; I think this Ian is a hideous idea. Far better than giving the impramatur of approval to having randomly broken binaries unless you install every single darned suggests dependecy package. Ian It is a pointless piece of programming, since it adds no new Ian functionality or ease of use (people who wanted the text UI will Ian invoke it directly). yeah, it just makes sure that programs in debian kinda work, rather than be discovered randomly after the install phase is over, and one no longer has access to the install system. That is ridiculous. Ian In fact, it seems to me that much of the aim of the complainants Ian here is to suppress the error message. I think this is a You just don't get it. The aim of the complainnat is that when one installs a package, one should be sure that the programs included actually work. Ian Is this suggested principle, that binaries' dependencies on shared Ian libraries should always be declared as Depends: The binaries should actually work when the package install went fine. Ian There are many programs which just fail if you request the use
Re: Release-critical bugs, and #97671
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Looking at the situation, I think that the definition of `serious' bug Ian report is rather unhelpful and does not match up with the use of Ian `must' or `required' in policy. Incidentally, I think the serious severity was invented as a way of describing policy violations; which make the above statement, umm, not the correct inference. manoj -- Humans are communications junkies. We just can't get enough. Alan Kay Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Technical Committee: decision on #119517?
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Manoj Srivastava writes (SuperCite undone): Ian Jackson: As I understand it, the supposed principle which is being applied is that it is unacceptable to have a binary in the package which depends on libraries not mentioned in Depends, and that Recommends or Suggests are not sufficient. If I install a package properly, all dependencies satisfied, all binaries work. Added recommended or suggested packages may enhance functionality; but the b i n a r i e s M U S T w o r k. Ian Err, that's a more general restatement of what I said, isn't it ? Not quite. It is specifying a general principle, leaving the details of library dependencies out; it does not matter if the program does not work if it needs another program, script, data directory, configuration file, or shared library in order to work. Shared libraries are not special. Ian I'm afraid I still don't understand what is special about a feature Ian that's invoked by running a separate program, as opposed to a feature Ian invoked by a keystroke sequence, menu option, or command to a Ian program's built-in CLI. This is what us folks in the reliability field call the distinction between complete failure and graceful degradation: the former case, the program does not work, in the later case it works, perhaps with reduced functinality. Ian So it seems to me that if you forbid having programs installed which Ian do not work, you must even more strongly forbid having menu options or Ian what-have-you that don't work. But that's the opposite of your Ian position as I understand it. Nope; what do you think the definition of recommends and suggests implies? To the end user, it implies that the core functionality would continue to work, though adding recommended or suggested packages may allow additional behaviour. In an ideal world, I would like documentation to reflect that options that require the recommended packages to be labelled as such. I disagree strongly. This is a quality of implementation issue. When I go on a machine, fire off a binary, and it faults, I know the machine is broken. Ian You say it `faults'. To me that would mean that it receives a signal Ian whose default action is to terminate and dump core - SIGSEGV or SIGBUS Ian or the like. Perhaps I should have said fails. Ian It doens't do that. It prints an informative error message and Ian exits nonzero, just like gxditview: Ian -norway:~ really cardinfo Ian cardinfo: error in loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory Ian -norway:~ echo $? Ian 127 Ian -norway:~ Ian I'm not sure why you see this as a totally unacceptable behaviour, but Ian the behaviours of cron, minicom and fvwm as fine. For example, fvwm Ian does this if you run it without m4 installed: Total failure, with a diagnostic. Nothing I can do can change this, unless I install suposedly optional packages. Ian -norway:~ fvwm -cmd 'FvwmM4 .fvwmrc' Ian sh: m4: command not found Ian [ and then it runs with an empty config file using builtin defaults ] And it works. Not ideally, but it did not dump me back to the login screen. I can now put in place a second config file, which does not need m4, and it shall work even better -- perhaps not all the bells and whistles I might have, had I installed m4, but hey. It WORKS!! Suggests does nto mean install suggested packages, or else some binaries are just going to fail. Why the hell have a dependency system with differeing levels at all, if you can no longer be sure what one needs install in order to have binaries work? Ian The dependency system is intended to make *packages* work. The Ian different levels of dependency are there precisely to allow Ian different subsets of a package to be made to work, without Ian having to split packages up unnecessarily. Pedantry. To the end user, a package does not work when the included binaries do not work. Graceful degradation ius acceptable, total and complete failure is not. The latter is, for most people, synonymous with ``the package is broken''. Really? I would rahtter add one more package to the nearly 10k list than have broken systems all over the place. Ian You keep saying you think a system with cardinfo but not X Ian libraries is broken. If I considered it as broken as you do Ian then I'm sure I'd agree that it was bad and ought to be avoided Ian even if doing so has substantial costs. Ian Can you explain why you think this is such a terrible situation Ian ? I understand that the binary does not work in this Ian configuration, but I don't understand why you think this is flat Ian out unacceptable. What actual bad consequences are there ? Quality of implementation. Failing least surprise. Failure of the promised invariant that if I
Re: Release-critical bugs, and #97671
Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Looking at the situation, I think that the definition of Ian `serious' bug report is rather unhelpful and does not match up Ian with the use of `must' or `required' in policy. What makes you say that? Serious is defined as a violation of a must or required directive of policy; I fail to see how this could not match up with the use of `must' or `required' in policy; they are identical ways of saying the same thing. Ian The idea in the BTS seems to be that a serious bug is one which Ian makes a package unsuitable for release. This is where the disconnect is. The release manager decides what is or is not fit for release. The general guideline is that a violation of a must directive in policy is likely to be cause for the release manager to reject the package. The final decision lies with the release manager. Ian How about if we change the wording in `Severity levels' in the BTS Ian documentation (http://www.debian.org/Bugs/Developer#severities). Ian Currently it says: Ian serious Ian is a severe violation of Debian policy (that is, it violates a Ian must or required directive), or, in the package Ian maintainer's opinion, makes the package unsuitable for Ian release. Ian How about: Ian serious Ian is a severe violation of Debian policy or any other problem, Ian which makes the package unsuitable for release. This is bogus. You have changed a stright forward, objective criteria for a serious bug, softening it to where it has no meaning. The output of your program makes my nose twitch, this is obviously a problem, and this bug is thus critical. Ian This definition makes `serious' correspond identically to the Ian package's suitability for release. It avoids defining `severe' Ian violation of policy as a violation of a `must'; that seems to me to be Ian the core error. This change would avoid violations of exceptionless Ian policies (which are of course always bugs) always being treated as Ian release critical even if they're unimportant. No, the core error is that you are taking away from the release manager the task and responsibility of determining release criteria. Did you ignore everything that I and aj wrote? Would you please catch up instead of jumping in late, and ignoring the advances and arguments already made? The core error is that bug severities should not be rigidly connected to release criticalness. *THAT* is the place where we need to make case by case, subjective decisions Ian If you and Anthony agree then maybe we should see if we can get that Ian changed. If you disagree I'm sure you'll let us know :-). I strongly object to turning the criteria upside down and creating a situation where bug severities are even more subjective. This is a far worse situation than we find ourselves in now. manoj -- A lady with one of her ears applied To an open keyhole heard, inside, Two female gossips in converse free -- The subject engaging them was she. I think, said one, and my husband thinks That she's a prying, inquisitive minx! As soon as no more of it she could hear The lady, indignant, removed her ear. I will not stay, she said with a pout, To hear my character lied about! Gopete Sherany Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: yawn
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden I'm willing to recognize the decision of the Technical Branden Committee as binding if Anthony is. Is a vote in the works? I'll let other memebers of the ctte take some time to respond to my opinions. Branden This issue to my mind is what degree of discretion a package Branden maintainer is permitted to exercise over the bugs assigned Branden to his package. In the past, the amount of discretion Branden afforded the package maintainer was greater. I have been in Branden disputes over bug severity with package maintainers before Branden -- as the submitter and in the past the package maintainer's Branden discretion has been regarded as sacrosanct, or nearly so. The current matter is being treated as a technical dispute between two developers; and in cases like this, no general rule (The person who invokes the ctte is always right, or The maintainer is always right) make sense. Bug severities are a technical, though sometimes subjective, decisions; and the severity ought to be decided on the technical merits, on a case by case basis. I am hoping that these disputes are rare, and can in most cases be resolved amicably, or at least following adjudication by the tech ctte. I would rather not set down rules of enforcement until we are sure we actually need to (at least, wearing my ctte hat). manoj -- For certain people, after fifty, litigation takes the place of sex. Gore Vidal Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpP99qfUsuvh.pgp Description: PGP signature
Re: Technical Committee: decision on #119517?
Hi, From reviewing the bug report, Ian Jackson sided with the maintainer, with the opinion that not all binaries shipped with a package need work when the dependencies are satisfied. Dale Scheetz, Jason Gunthorpe, and I disagreed. The suggestion was to either: a) split off cardinfo and declare the X libraries in the Depends: field, or b) keep it in the current package and include the X libraries in the Depends: field. c) Create a wrapper for cardinfo that provides information on the current set of cards on stdout, and in the presence of a DISPLAY variable provides additional, X based functionality, I suggest that the quorum of two was met, and that the decision of the committee be formalized. manoj -- Most people have two reasons for doing anything -- a good reason, and the real reason. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C pgpClhfTs6qrZ.pgp Description: PGP signature
Re: request for Technical Committee ruling on Bug #109436
Raul == Raul Miller [EMAIL PROTECTED] writes: Raul It looks to me like the right thing to do here is: Raul [1] Do something so the new tar.gz file has a file name distinct from Raul the old one. [Guy Maor suggested incrementing the epoch.] This should work(well, not the epoch, but a rename of the source) , but I am not convinced this is the correct thing to do. Raul [2] File a bug report against ftp.debian.org to get the old Raul tar.gz file pulled. In this case, I would prefer this (because of the DFSG violations). In general, though, this could cause problems with licence violations until the other archs caught up (we would be distributing binaries without the corresponding source) Raul [3] File a bug report against policy so steps [1] and [2] are clearly Raul documented. Raul Currently policy on Epoch says: Raul It is provided to allow mistakes in the version numbers of Raul older versions of a package, and also a package's previous Raul version numbering schemes, to be left behind. Raul This is a bit too narrow as it doesn't talk about the need for Raul distinct instances of the same version of the upstream tarball. The epoch is not the solution here, so this is moot. epochs are for version number screwups, and do not affect the original sources. manoj -- Card readers? We don't need no stinking card readers. Peter da Silva (at the National Academy of Sciences, 1965, in a particularly vivid fantasy) Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Debian Crypto in Main document...
Hi, Bdale == Bdale Garbee [EMAIL PROTECTED] writes: Bdale [EMAIL PROTECTED] (Manoj Srivastava) writes: depending on how far the integration of crypto spreads into software that has traditionally not had crypto, and thus been in main, reverting may cause enough of software to have to go to non-us/main that the distribution left in main would be crippled. Bdale Instead, wouldn't this just force us to move the master site Bdale outside the US? Perhaps. But even that solution has drawbacks. Consider what happens to erstwhile non crypto packages, with maintainers that reside in the united states, who now have to let go of these packages when they move to non-US (since they may not be permitted to export the packages). Indeed, this prospect may well slow down the integration of crypto hooks into packages. There are also considerations of having a bandwidth donor, connectivity issues, and we shall have to revisit crypto and non crypto official CD images. Mirrors in the US may also have to be revisited, if the crypto rules are ever reversed. manoj -- Can you program? Well, I'm literate, if that's what you mean! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Debian Crypto in Main document...
Hi, Raul == Raul Miller [EMAIL PROTECTED] writes: Raul My first thought, on reading this, is: Do we care about stability? Raul If U.S. laws or regulations are likely to change significantly (because Raul of constitutional challenges, lobbying, etc.) do we care? If so, what Raul kinds of likely changes do we care about? [Does it matter to us if the Raul legal climate on cryptography requiers us to change our crypto policy Raul a couple times every year?] It matters from a viewpoint of administering the archives, the upload queues, etc. Suppose we merge the two archives, and then. as you put it, the cryptographic climate changes. Would there be any liability? We would still need to remove the software from the master site, and would have to hasten to remove it from sites which replicate the software repository (mirrors). CD vendors may be hesitant to offer Debian in bulk if ever their inventory is deemed illegal. We would have to reinstitute any dismantled upgrade and autobuild processes that were obsoleted when we moved all crypto software into main. Upgrade paths may be compromised by the vacillation. Indeed, depending on how far the integration of crypto spreads into software that has traditionally not had crypto, and thus been in main, reverting may cause enough of software to have to go to non-us/main that the distribution left in main would be crippled. As with all operating system vendors, Debian needs to include cryptographic software. This software provides security, allows users to engage in Internet commerce, and accomplishes other tasks requiring cryptography. Today, this software is stored on a server outside the United States. Currently Debian takes no measures to assist US developers in following export control regulations if they upload software to the non-US archive or to prevent them from uploading software. We would like to move cryptographic software from the server outside the US onto our main server in the US. Raul Would some of the reasons why we want this matter to a legal person? Well, ok. Usability: with the increasing networked nature of the work, and the fact that more and more critical functions are being placed on computing platforms, and the unfortunate growth of mischief and deliberate malice, security is going to be increasingly important. Cryptography is an important corner stone of a number of security processes. Any OS that does not make an effort to seamlessly integrate cryptography is unlikely to be competitive. Putting all software on a single source, and the corresponding ability to create a single set of CD's that have integrated cryptographic support makes it easier for the users, makes it easier for CD vendors, simplifies the task of developers uploading software to these sites, and simplifies the task of replicating the software repositories on the internet. manoj -- Whether you can hear it or not, The Universe is laughing behind your back. National Lampoon, Deteriorata Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: usr/man vs usr/share/man?
Hi, Raul == Raul Miller [EMAIL PROTECTED] writes: Raul On Tue, Aug 31, 1999 at 04:18:19PM -0700, Joseph Carter wrote: Didn't we come up with a good and reasonable solution to that problem? =p Raul Well, to deal with one particular aspect of incrementel upgrading there Raul are some people (very competent developers, overall) who are seriously Raul proposing that *every*single*package* must be changed and re-released Raul for potato. That means those that have not yet migrated to FHS as well Raul as those which have. And that inevitably means that potato's release Raul will be delayed. Is this not just an issue of swetting MANPATH defaults? The current /etc/manpath.config already contains -- MANDATORY_MANPATH /usr/man MANDATORY_MANPATH /usr/share/man MANDATORY_MANPATH /usr/X11R6/man MANDATORY_MANPATH /usr/local/man -- I also thought that the proposed updates area also contains a fixed man-db package. So incremental upgraders should be asked to also upgrade to packages from proposed upgrades before incrementally upgrading to potato. This does not require each and every package to be touched, nor does it require confusion. manoj -- Faster than a speeding bullet. More powerful than a locomotive. Able to leap tall buildings in a single bound. 'Look! Up in the sky!' 'It's a bird!' 'It's a plane!' 'No, it's Superman!' Yes, it's Superman, strange visitor from another planet who came to Earth with powers and abilities far beyond those of mortal men. Superman, who can change the course of mighty rivers; bend steel in his bare hands; and who, disguised as Clark Kent, mild-mannered reporter for a great metropolitan newspaper, fights a never ending battle for Truth, Justice, and The American Way! Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: please vote...
Hi, In case it was not clear, I, too, am voting for the forest of symlinks proposal. That makes two votes for it. manoj -- President Reagan has noted that there are too many economic pundits and forecasters and has decided on an excess prophets tax. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: please vote...
. Then you are at odds with everyone who has spoken on the -policy list, and on the IRC. Your opinions about the policy group, while amusing, have no real bearing on the request before the committee. Should you feel the need to vent your dissatisfaction with the incompetence of the polciy list, please take it to personal email, or to the list itself. Dale You may find it amusing that this committee has gotten itself Dale into this mess, I don't. The fact that you seem unwilling to Dale take any responsibility for the situation puts me in less of a Dale state of mind to try and help you out of the muck you in which Dale you are currently stuck. I am stuck? *I* am stuck? You have serious ego problems, it seems. The project is stuck , not I. And responsibility without power is silly. What responsibility? I have no special power in the policy mailing list, and can't be expected to have any more responsibility thatn any toher member. Dale The fact that the policy group is unwilling to support your proposal, Dale dispite the problems created by the new FHS policy, suggests that the Dale proposal is flawed. Rubbish. You do not seem to be aware that the policy group is designed for non-controversial amendments to policy. It is not designed for sound, but unpopular, technical amendments. There is no power given to the policy group to implemnt technical solutions that may be unpalatable to more than 4 members of the policy group. If you think that because a proposal is unpopular, it must be flawed, you should seripously reconsider your acceptance of the char of this committee. Dale The fact that you are unwilling to present a reasonable counter Dale proposal leaves the Technical committee with nothing to Dale deside. We are NOT an instrument for pushing through proposals Dale that do not pass ordinary creation processes within the In other words, you want a general resolution protocol. Deciding technical policy by popularity. If that is what Debian is reduced to, we shall indeed see quality plummet. I can't believe you said that. Dale group. Our sole reason for existance is to provide a mechanism Dale for resolving a deadlock between two opposing positions. You Where does it say that in the powers of the ctte? Where are you getting this stuff? Dale have only proposed one option, leaving the committee no choice Dale but to reject your request and suggest that you return to the Dale constitutional means for resolving such questions...a vote. I think that is you think that a vote is the correct way toi decide technical policy, you should resign from this committee. Sorry, but voting for technical policy is a really bad idea. manoj -- Flight Reservation systems decide whether or not you exist. If your information isn't in their database, then you simply don't get to go anywhere. Arthur Miller Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: please vote...
Hi, Dale == Dale Scheetz [EMAIL PROTECTED] writes: Dale On 9 Aug 1999, Manoj Srivastava wrote: Dale What I heard in the proposal was that without the symlinks Dale things break. The only things that I know of that break Dale are the helper tools and checker programs. If these are silly Dale reasons, then your argument that things break is silly, unless Dale you can provide evidence of more important breakage. User expectation. The user going ls /usr/doc/package[TAB] breaks. The location is not really that ijmportant, the fact that one may need to make two probes to find the docs can get to be irritating. And you may think that that is trivial, but a large number of people felt it was a quality of implementation issus. Dale No, this is exactly the kettle of fish you wish to us to stew Dale in. The policy group has made a faulty change to policy, and Dale now you want us to correct that failure by forcing the Dale acceptance of a new policy to fix the old, broken, policy Dale change. Rubbish. The move to FHS is not flawed, And since details should not go into policy by default, it was perfectly acceptable to agree to the move, and then make policy on things that needed it. You may disagree with how the pollicy group works, but that does not mean other think it so. I certainly do not. And we are not fixing old, broken policy. We are addressing a specific sub issue that was not foreseen as needing prior discussion. Unless you are god, you do not see all that has to be acted on first. Now stop being so high and all mighty and let us get to doing some work -- something we have failed to do, unlike the policy group you like to castigate. Dale A proposal that would be unnecessary if the policy group were Dale acting in a responsible fashion, and making reasonable changes Dale to the policy statements. Heh. This is so clueless. The policy group does not make policy amendments that are controversial. And expecting any open forum not to have controversies on at least some technical aspect is naive. Dale This is not in our mandate. We are NOT a policy making arm of this Dale organization. Then read the constitution.And go read the policy list archives. The BTS of the policy-list gives all proposals made on the issue. There is no requirement that the committee be spoonfed all the discussion. The discussion has been carried out, and the policy group seems deadlocked. -- The Technical Committee does not engage in design of new proposals and policies. Such design work should be carried out by individuals privately or together and discussed in ordinary technical policy and design forums. The Technical Committee restricts itself to choosing from or adopting compromises between solutions and decisions which have been proposed and reasonably thoroughly discussed elsewhere. Individual members of the technical committee may of course participate on their own behalf in any aspect of design and policy work. -- Dale We are a deadlock resolution mechanism, not a policy dictator. The project is indeed deadlocked on this. The only way out is a general resolution, and if you contend that is the sole solution, then this ctte has no utility. Because in the opinion of the majority, and given our track record, the transition shall not happen in a release interval Dale Were else does it happen? Your statement doesn't reply to my comments. We shall have to release potato in a transitional state, I think, as do a number of others. Dale I have not accurately described the difficulty of the change? I think you underestimate the time required to change all packages (even if helper packages are changed) Dale It is no more complex than changing /usr/doc to /usr/share/doc in the Dale appropriate locations in my rules files. How hard _is_ that? Not hard at all. And, it may take as much as a year to 18 months to do that. We are no longer small and nimble. o? Dale The constitution does not force us to vote on your proposal. We Dale all agreed during the preliminary discussion that the committee Dale could easily reject any proposal it thought flawed or otherwise Dale improper. I guess we can do that. I would not agre, but then it shall depend on the silent almost-majority of the ctte. Dale Either come back with two proposals, Justify that request. You may have to have the constituion changed while you are at it. Dale The constitution has nothing to do with this. This committee Dale can make any requirements of the proposers that it deems Dale necessary. I see. We can decide to cop out, despite the fact that the only way to resolve
Re: Technical committee mails ?
for help, I shall withdraw the proposal. There. The symlink proposal is now withdrawn. Dale I clearly have misundersood what you are trying to say here, so Dale I will resort to your tactics and just say, This is not Dale relevant. That does explain your arguments. When you do not understand anything, you say it is not relevant. Great. Dale But you _have_ asked for help. You can't simply say, well I Dale only want help if it comes to me in a specific form. Now that I have unasked, I guess this is all ok. I can say I only need help in one thing. Just because I ask for help on one issue does not mean that the tech ctte comes in and takes over evrythig, and one may as well dissolve the policy group. Dale I don't see that as being what is happening here. Reasonable Dale people are trying reasonable alternatives. If you have been Dale this inflexable in your position within the policy group, it is Dale understandable why you haven't gotten as much support as you Dale believe the idea deserves. Again, making the proposals personal. If indeed personalities are this important to you in a technical decision, I think you should reexamine that. Dale Ian's proposal _is_ a fix for the current problem. I realise it Dale isn't what you think is the right thing to do, but that's Dale life. You can't always get what you want(RS). It is a mad grab for control. At best, I saw: roll back all FHS relkated changes, even the oines that have been succesfully accomplished, cause we on hihg say you dod not pay homage to the right method. Dale Please stop assuming that since someone doesn't agree with you, Dale that they are trying to gain some power over you or this Dale group. Such is simply not the case, and if you were calmer That is quite stupid, dale. It is ot disagreement that makes me think it is a power grab. It is the expansion of the problem domain that makes it so. It is not a different ``form''; it goes from trying to decide how to resolve a subset of the FHS move to suddenly over ruling a working solution for all the other changes that have already beeen instituted, just cause we have the power to do so. You have not offered one iota of reason why we are rollig back succesful changes, and broadening the scope of this action beyond the /usr/doc move. Dale No, I haven't, that is not my job, and I thought that Ian's proposal had Dale lots of good reasoning behind it. What reasons? He disagreed with the way that the policy group went about doing the move (which is his right). However, rolling back decisions that are working, or are being resolved elsewhere, has no justification in the proposal. Just because the ctte members do not like the way the policy group works does not mena the ctte can just override that group. Give me a reson why we should be in charge of the whole move, when the mechanisms in place seem to be working. Dale I'm not sure I agree that we necessarily should repeal the whole move. Dale Why don't you try using your position on this committee in a Dale constructive way, and propose an ammendment to Ian's proposal Dale that limits the rollback to only the /usr/doc to /usr/share/doc Dale transition. I suspect that such an ammendment might be Dale acceptable to Ian. It certainly would be acceptable to me. Because I think even that is a mistake. Oh, probably a lesser one. I'll think about that. Offering an amendment that still creates a proposal I won't support seems so -- tacky, but this whole mess is a lot of unpalatable alternatives anyway. manoj -- Dave Barry Your digestive system is your body's Fun House, whereby food goes on a long, dark, scary ride, taking all kinds of unexpected twists and turns, being attacked by vicious secretions along the way, and not knowing until the last minute whether it will be turned into a useful body part or ejected into the Dark Hole by Mister Sphincter. We Americans live in a nation where the medical-care system is second to none in the world, unless you count maybe 25 or 30 little scuzzball countries like Scotland that we could vaporize in seconds if we felt like it. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Away notice
Hi, Ian == Ian Jackson [EMAIL PROTECTED] writes: Ian Does your message constitute a resignation from the Technical Ian Committee ? We need to know this so that we know what the quorum is, Ian etc. No. I would have said so if it was. Surely this is not a problem? We are going to be away on vacation and business from time to tiem, are we not? And I am merely pulling back the time I spend on the project, and still read this list, so I'll be available to resolve this issue. manoj -- The University of California Statistics Department; where mean is normal, and deviation standard. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: I'd like to coordinate a major update of stable
Hi, Joey == Joey Hess [EMAIL PROTECTED] writes: Joey You are the one who doesn't understant the problem. I see. Rather than berate each other about our obtuseness on this issue in particular, or a lack of acuity in general, I posit that there are two issues involved: a) frustration involved in readin the docs in two different locations The symlink solution addresses this b) incremental upgrades to unstable packages from unstable, which makes documentation not be accessable with tools such as dwww, man, ect. Your stable upgrades solution addresses that. The stable-upgrades solution has no impact on the former problem, and the symlinks solution only addresses the latter in a non optimal fashion. I agree that the symlinks solution does not handle 2; and your stable upgrades solution would be required. Joey I am hugely tired of trying to explin this to people, when Joey absolutly no one seems to get it. This is a large part of why I Joey proposed this in the first place. Since no one understand the Joey problem anyway, I doubt we will ever get a correct Joey solution. :-( If no one gets it, possibly the reason is not that every one is, umm, dumb? The proposal that I put forth before the -policy group, and before the tech ctte, has to do with the first problem. Yoiu did bring up the second solution, but never explained that the domain of the problem was different from the one that the symlink solution was addressing (adding to the confusion is the fact that the symlink solution seems to solve the second problem in a kludgy, suboptimal fashion). manoj -- Do not stop to ask what is it; Let us go and make our visit. Eliot, The Love Song of J. Alfred Prufrock Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: I'd like to coordinate a major update of stable
Hi, Joey == Joey Hess [EMAIL PROTECTED] writes: Joey Manoj Srivastava wrote: Rather than berate each other about our obtuseness on this issue in particular, or a lack of acuity in general, I posit that there are two issues involved: a) frustration involved in readin the docs in two different locations The symlink solution addresses this b) incremental upgrades to unstable packages from unstable, which makes documentation not be accessable with tools such as dwww, man, ect. Your stable upgrades solution addresses that. The stable-upgrades solution has no impact on the former problem, and the symlinks solution only addresses the latter in a non optimal fashion. I agree that the symlinks solution does not handle 2; and your stable upgrades solution would be required. Joey Er, what are you saying. Does the symlink solution fix b) in a non-optimal Joey way, or not at all (and what is 2)? I guerss I meant (b) above. The proposal that I put forth before the -policy group, and before the tech ctte, has to do with the first problem. Joey Why did you ignore the second problem? It's clear you knew Joey about it on July 17th, when you posted a proposal to fix it Joey that included: Because I felt that the former was important enough, and that was what I concentrated on. Since it has the added benefit of making the (b) less critical, and we probably would have fixed everyhing by the time woody has happened, I did not bother getting a better solution out there. Surely you are not berating me for not proposing a solution for both problems? Why am I supposed to be responsible for all the problems there were? I took (a), proposed a solution that also made (b) less critical, but did not optimally solve it. I had enough grief over the symlinks ot to push other developers to also make potentially complex changes to their code. I figured some one would take up the slack. Glad to see you have. * We should not break backwards compatibility during the transition period. This is a quality of implementation issue During the transition, we need to provide backwards Joey compatibility, firstly for programs ike `dwww', and `dhelp', and Joey ^ also for our users who have gotten used to looking under a single dir (`/usr/doc/') for docs (``/usr/doc/package''). During the transition, the documentation could be in in two places, and that is not good Nice goal, if I say so myself. Glad to see you covered it. The symlink proposal does push the need to do anything vis-a-vis dwww and dhelp to a later date, but it is not, as you point out, a solution. Joey I cannot belive you claim you are not aware of this issue, or I was. I did not have as facile a solution, and did not propose a fix for that to the tech ctte. The solution for (b) is to fix all programs, or something. I did not have a solution I liked for that. Joey that this is not at least half of the issue the techical Joey committe was called upon to fix. I can find numerous mentions The proposal that I put forth, before the ctte, and before the -policy, solved (a), and deferred (b). You now have proposed a solution to (b), and o one is objecting. Unless you feel like continuing this discussion, which has all the signs of degenerating into a flame fest, I think we either calm down, and move away from injecting personalities in here, or nothing really shall be achieved. Joey of problem b) throughout the policy list archives for last Joey month. It's not as if this were a concern I just brought up. No it is not. It is just not something that had a solution proposed until now. If you were to bring it up in -policy, it may well pass. manoj -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. Francois Fenelon Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
