Re: debian and lilypond 2.12
I don't object to a suitable Debian developer who wants to take over maintenance of lilypond. They should contact me directly. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, 2008-12-29 at 15:02 +1000, Anthony Towns wrote: > For example, having "non-free" in the archive and the BTS (and potentially > buildds and elsewhere) is implied by point (3) (ie, supporting Debian > users who choose to use non-free software to the best of our ability), > and potentially using non-free software ourselves (such as qmail or pgp > in the past) may be implied by point (2) (using the best available tools > and techniques to do the best job we can). I would personally prefer > for the project to have the freedom to decide those sorts of things > on a day-to-day basis through regular decision making (maintainers, > list debate, DPL, ftpmaster, RM, tech-ctte, simple majority vote), but > I don't know if the rest of the project will buy that these days. I'm > fairly sure some people won't, at any rate. I would prefer this. But I am afraid of it, and so I would vote against it. I am afraid that there are folks in the project who really don't care if Debian is 100% free--even as a goal. I think that Ted Tso is even one of them. My fear is that if we say, "It is a goal that Debian be 100% free", and leave it up to the ordinary process of people doing their work, then people who oppose that goal, who think it is a foolish goal, or an unworthy one, will simply obstruct it. It is this which bothered me about the release team's methodology vis-a-vis this issue this time around. Not that I thought they were deliberately obstructing our goals--I have no reason to think they were doing anything but making a pragmatic decision as best as they could at the time--but because I can't know for sure. And, then when the controversy erupted, there were people expressing views that I *do* think are simply contrary to our goals, lauding the release team for ostensibly obstructing the social contract's "absolutism". I wish we could have in the world of GNU/Linux one, just one, please--just one--distribution which really took free software as of cardinal importance. Debian has promised to be that, while living up to the promise only in fits and starts. That's ok with me. But I'm afraid that if we stopped the promise, and simply decided it would be our goal, the folks who are against the promise will be against the goal, and will see this as permission to simply *never* work toward the goal, and to obstruct others who do. > Since it's worded as a pledge, it might make sense that if it (or > something like it) is ever adopted, that existing developers membership > being dependent on them agreeing to the pledge. That didn't happen with > the previous SC change, but it seems strange to claim to have a social > contract when a significant number of members don't actually support > it 100%. In my opinion, developers who are unwilling to abide by the Social Contract in their Debian work should resign. But they don't, and this is what has me afraid. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, 2008-12-28 at 20:45 -0500, Theodore Tso wrote: > On Mon, Dec 29, 2008 at 12:48:24AM +, Simon Huggins wrote: > > > > I wonder how many DDs were ashamed to vote the titled "Reaffirm the > > social contract" lower than the choices that chose to release. > > > > I'm not ashamed at all; I joined before the 1.1 revision to the Debian > Social Contract, which I objected to them, and I still object to now. > If there was a GR which chainged the Debian Social contract which > relaxed the first clause to only include __software__ running on the > Host CPU, I would enthusiastically vote for such a measure. Can you please define "host CPU" for us? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DFSG violations in Lenny: Summarizing the choices
On Sun, 2008-11-09 at 06:55 -0500, Theodore Tso wrote: > Because according to you, Debian isn't allowed to ship any non-free > bits, right? No, not right. Please pay attention. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: Summarizing the choices
On Sun, 2008-11-09 at 00:39 -0500, Theodore Tso wrote: > > And none of this is really relevent: the DFSG and the Social Contract do > > not contain an exception for dishonest or scared hardware manufacturers, > > or stupid FCC policies. > > Neither does it (currently) contain an exception for debian.org > machines, or very popular Dell machines with Broadcom ethernet > firmware. Great! Cut them off!! Let's see how quickly we can get > users moving to non-official kernels and installers when the official > ones don't work for them. Then we can stop fighting about it. The > DFSG hard liners can go on using the DFSG free kernels, and everyone > else can either move to another distribution or use an unofficially > forked kernel package and installer. Why not just support it in non-free exactly the way we do other things? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: Summarizing the choices
On Sat, 2008-11-08 at 18:55 -0500, Theodore Tso wrote: > > The FCC understands that you can't make it *impossible*. Even before > software radios, it was understood that someone posessing the skills, > say, of an amateur radio operator might be able to add a resistor or > capacitor in parallel with an RC/LC tuning circuit, and modify the > length of the antenna, etc., thus making a radio transmit outside of > the band which it was type-certified to operate on. That's right. The FCC says that modifications of hardware make you, the modifier, the one responsible for the transgressing equipment. But now we have this claim that the FCC's well-understood rule about hardware does not apply to software: that software modifications *are* traceable back to the manufacturer, even though hardware modifications are not. Oddly, however, in all these conversations, we've never seen any indication that this is really the FCC's policy. And none of this is really relevent: the DFSG and the Social Contract do not contain an exception for dishonest or scared hardware manufacturers, or stupid FCC policies. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations in Lenny: Summarizing the choices
On Sat, 2008-11-08 at 14:11 -0500, Theodore Tso wrote: > There are corporate lawyers who are very much afraid that the FCC > could, if they were alerted to the fact that someone had figured out > how to reverse engineer the HAL and/or the firmware to cause their > WiFi unit to become a "super radio" that could transmit on any > frequency, that the FCC could prohibit the *hardware* from being sold > anywhere in the US. I've heard this claim before. Can you substantiate it in some way? It seems to me that, if this is really true, then the hardware manufacturers have been lying to the FCC for years, claiming that the user cannot reprogram the card, without explaining that, in fact, it's just that users may not know how to, but that they can do so without any hardware mucking. Regardless, the DFSG doesn't say anything about "unless the FCC has an annoying rule". We don't distribute non-free software in Debian. And that's not some sort of choice we might make--it's a a choice we have already made. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Wed, 2008-11-05 at 18:06 +, David Given wrote: > So having the source doesn't actually gain you anything --- you would > neither be able nor allowed to do anything with it, apart from printing > it on T-shirts. You can learn about it. Remember the educational purpose of free software? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DFSG violations: non-free but no contrib
On Thu, 2008-10-30 at 16:33 -0400, Lennart Sorensen wrote: > So if any of the hardware that requires non-free firmware to operate and > currently works in etch was to not work with Lenny, then that's > completely unacceptable? > > If that's the case, then there is no way EVER to make Debian comply with > the DFSG since you aren't going to get free firmware for all those > devices. Um, yes there is. We could do the same thing we do with codecs, file formats, and all the rest--in the absence of support with free software, we don't support it in Debian. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Thu, 2008-10-30 at 13:23 -0400, Michael Casadevall wrote: > I have some experience with radios. The FCC requires all radios to be > certified before they can be sold, and there is a requirement that you > must not make a device that is easily modifiable to operate outside > the limits put forth by the FCC. In this case, it would be illegal to > release the firmware's source code since it would violate the FCC > rules, violate and void the radio's certification (and this also > applies to Wifi/Bluetooth devices). The mere fact that the firmware can be loadable--with or without source code--means that it can be easily modified. The ease of modification is not about the obfuscation of the blob, but about the mere fact that it can be loaded. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Thu, 2008-10-30 at 17:34 +0100, Michelle Konzack wrote: > So now as a Manufacturer I have the choice between > > 1) Use a huge NV/FLASH/EEPROM Memory which make the Hardware maybe > 10-20 Euro more expensive and I will lost customers. > > 2) Use huge external SRAM (makes the Hardware expensive too) to let > users load there own non tested and non-optimised blob and become > sued if something goes wrong. Um, no. See, what you don't seem to understand is that users can load their own non-tested and non-optimized blob whether you release source or not. In fact, by not releasing source, you *increase* the risk that users' modifications will damage the hardware. The point here is that loadable firmware exposes you to a risk. The refusal to provide source has nothing to do with whether the risk is exposed; but providing source would *reduce* it. > So, the Open-Source System does not realy work on Hardware... Of course, we're not talking about Hardware, we're talking about firmware, which is, of course, a kind of software. > I do not know HOW OpenMoko do this, but the certification for GSM > software/firmware IS expensive and it IS required by law. If I understand correctly, then you (and perhaps many others), are not being honest in attaining GSM certification. You seem to be saying that the certification is contigent upon it being impossible for the user to change the behavior of the device in a non-compliant way. But the mere fact that you are using loadable firmware means that the user can make such a change. It has nothing to do with the license for the firmware, or whether there is source, or even whether your or Debian or anyone else distribute the firmware. The device, in fact, *cannot* be guaranteed to meet the certification, because it provides the capacity for users to load non-compliant firmware. Now whether that's a serious problem or not, I don't know, but it is entirely distinct from the license terms on the firmware blob. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Thu, 2008-10-30 at 01:48 -0500, William Pitcock wrote: > On Wed, 2008-10-29 at 22:52 -0700, Thomas Bushnell BSG wrote: > > But regardless, Debian has promised that Debian is only free software. > > Then why does Debian have non-free? Is that not part of Debian? No, it's not part of Debian. Non-free is distributed by Debian, but it does not form a part of the Debian system. > If non-free is meant to be an opt-in part of Debian, then put the > distributable firmware there and be done with it. Of course, what I would be happy to see is the firmware moved to the non-free respository. That's exactly what we're talking about. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Wed, 2008-10-29 at 22:53 +0100, Michelle Konzack wrote: > What does have the FIRMWARE to do with a DEVICE DRIVER? For the DEVICE DRIVER to work, a FIRMWARE must be loaded on some hardware, as you well know. Debian has promised that the Debian distribution will only be free software. Some of that software is device drivers, but other parts of it are compilers, window systems, music playing programs, email systems, databases...and firmware. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Wed, 2008-10-29 at 21:47 +0100, Michelle Konzack wrote: > There are SDKs called "Builder" where you will have NEVER source code, > even as Developer, since the "Builder" create an IMAGE which will be > uploaded into the the SRAM of a Microcontroller (I have some 8051 > compatibles) and then after uploading it is executed... So suppose you have this IMAGE and you discover it has a problem; how do you modify it to fix the problem? I'm assuming you load it into "Builder", and then "Builder" can display for you something sensible and comprehensible, better than simply editing bits, right? More details would be helpful here.thout VAT) in Low-Cost. > I do not know, whether my customers accepet 5 US$ more. > > However, my Firmware Loader must be there anyway for upgrades... > > The question is, what do you want with the Sourcecode? Your English is a little confusing for me, so I'm not sure what this question is asking. If you mean, what is the source code which Debian promises to make available to its users, it's generally understood to be the preferred form of the program for making modifications to it. If you mean, why does Debian want the source code, there can be many reasons. One is to learn about the program; how it works, how other programs doing similar tasks could be built, and so forth. Another is to deal with the day when you are gone and people still have the hardware and wish to make it do something you never thought of. But regardless, Debian has promised that Debian is only free software. > Reprogramming? A singel error in the parameters will cook your computer > hardware and HOW do you want to recode something or add functionality? > > I have choosen the smallest Microcontroller required to save money... > > Yes, I can reploaye a MC with 16 kByte SRAM with one which has 256 kByte > and then OSS frickler can add stuff, but this would make the controller > over 10 times more expensive... > > Please think about it. About what? Debian has no objection to the use of loadable firmware. But notice that part of the reason you would save money with the loadable firmware is that you can ask Debian to undertake the cost of distributing it for you (and thus saving you the cost of the SRAM, which is the way you would distribute it yourself). Debian will distribute it, but in order for it to be a part of Debian itself, it needs to be free software. There is no reason your interest in making the hardware affordable can't go along with that at the same time: just provide the source. > I have the hell striping down the firmware of my hardware to fit into > 32 kByte and you are talking about modifications to it... > > I am sure, my enterprise is not the only one wondering about such > requirement to let users modify firmware of sensibel hardware which CAN > destuct the whole computer since they have to leafe out some stuff to > get it into the small memories... How is this a reason not to provide source code? > It is useless because I am building a hardware which take me several > month to develop plus coding testing the software in a secured > environement where hardware can not be destucted... > > The lifetime of such hardware would be maybe 3-5 years and now, you can > explain me, HOW you would develop/recode the firmware, if you have NOT > the requirement environement, risking damages to the hardware and more. > > You do not know the internals of my hardware and have to guess things. > Without the hardware developer tools you can not even DEBUG the Hardware > while loading YOUR hacked firmware. Even if my hardware has a JTAG > connector... I don't understand why this matters to you. Provide the source code; Debian ships it, and nobody is hurt. If nobody ever makes use of it, how has it harmed you? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Thu, 2008-10-23 at 22:08 +0200, Ansgar Burchardt wrote: > > The FSF seems to disagree on this[1]: > > Can I release a non-free program that's designed to load a GPL-covered > plug-in? > > It depends on how the program invokes its plug-ins. For instance, if > the program uses only simple fork and exec to invoke and communicate > with plug-ins, then the plug-ins are separate programs, so the > license of the plug-in makes no requirements about the main program. > > The general idea seems to be that (at least the FSF) only linked modules > are considered as a "single program" and only in this case all parts > have to be GPL-compatible (not necessarily released under the GPL > itself). This is (or when the text was originally written), about programs *as released by the FSF*, but not about the GPL in general. It may be that the older text is now getting used in a broader context. I do not know if this represents a change in the FSF's position. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Thu, 2008-10-23 at 21:13 +0200, Vincent Danjean wrote: > Ben Hutchings wrote: > > On Wed, 2008-10-22 at 11:38 +0200, Bastian Blank wrote: > >> The iwl4965 firmware changed 2 times incompatible since the driver > >> exists. > > > > That makes me wonder just how separate the driver and firmware are. If > > they are tightly coupled then the firmware may become subject to the GPL > > as well. > > Firmware and driver do not run on the same CPU. There is no 'linkage' > between them. With a client/server application, a GPL client does not > enforce the server to be GPL, even if client and server are tightly > coupled. That is not true. It simply depends on whether they are one program or not, which is a human-level concept, and not a technical one. There is no "magic boundary" at which the GPL would neve cross. For example, if you were to split GCC into two executables, one which parsed and generated intermediate code, and another which did optimization and codegen, the result would still be the one GCC, covered by the GPL. And this is true even if you then write your own version of the first part, implementing your seekrit proprietary language: the GPL on the back end would require that the *whole program* be distributed under the GPL, any separation into different executables notwithstanding. There is nothing in the GPL about "running on the same CPU" or "client/server" exceptions. If you use GPLd code, then the *whole program* (whatever that is, it is a human-level concept requiring understanding and not rote following of rigid rules) must be distributable under terms no more restrictive than the GPL itself. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Thu, 2008-10-23 at 18:13 +0100, Neil McGovern wrote: > Perhaps I'm mis-reading the above. Which bit of the foundation documents > do you think would need overriding for the tech-ctte to rule on which > fix to take? One might think that this is the situation: two alternative fixes for the DFSG problem, and a dispute about which one is better. But actually, that's not the situation. We have instead an easy trivial fix, all but complete. (Really, just disabling the hardware, or the accelerations, depending on the case.) And maintainers saying that this is an unacceptable fix--and no actual alternative fix sitting around. I think everyone would regard the fix preferred by the maintainers as superior--there is no technical dispute. The dispute is *not* between the two fixes. It is between these two approaches: 1) Install easy fix now; install fancy fix when it's ready, thus complying with the DFSG at all times; 2) Install no fix now; install fancy fix when it's ready, thus violating the DFSG in the meanwhile. This is not a dispute about technical means or which is the best solution to a technical problem; it is a dispute about whether we are actually supposed to be doing our best to comply with the DFSG at all times. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 18:45 -0500, Ean Schuessler wrote: > I guess the question is, staying in the arena of "100% Free", what if > DRM technologies become pervasive in the United States and Europe and > it literally becomes illegal to have a computer without some > proprietary software in it? What if it becomes impossible to develop > on a computer, legally, without compromising? Would it still be better > to have a computer that is 99.9% free? Keep in mind that I'm asking > this in the scenario where providing the last 0.01% as Free Software > would be illegal. If that happens, we will have to make some difficult choices. But we are nowhere near that now. For example, I vote, as a matter of principle. But if I lived in various extreme situations, I would not vote, for example, if I were in a one-party state with no real elections. And then *that* principle might well be one I would compromise on if the state in question enforced serious criminal penalties on non-voters. And so it goes. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 17:06 -0500, William Pitcock wrote: > I worded that rather badly. You should imply "within acceptable terms of > the DFSG" here... in this case, putting stuff in the nonfree firmware > package in non-free is an acceptable solution. Of course; that's an excellent solution. Right now, the failure to have that solution implemented is being used as an excuse for violating SC#1. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 16:27 -0500, William Pitcock wrote: > On Tue, 2008-10-21 at 14:20 -0700, Thomas Bushnell BSG wrote: > > On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: > > > Would it be a good compromise between SCs #1, #3 and #4 if we made an > > > exhaustive list of non-free bits in main, and make it our goal that the > > > list gets smaller between each release and not to add anything to > > > that list? > > > > I would be entirely happy with that. But I have just been told by > > William Pitcock that apparently we are required somehow to support new > > hardware with non-free software too. So it's not a decreasing list, > > it's an accordion list with no real commitment to the DFSG at all. > > Do not put words into my mouth. I simply stated that user experience is > an important factor, and that if free drivers (*FREE*) which depend on > non-free firmware are available, and the firmware is inline, then it > should not block Lenny's release. Huh? So you would be willing to agree to a rule that we never add anything new to the list of non-free bits? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 23:23 +0200, Frans Pop wrote: > On Tuesday 21 October 2008, you wrote: > > But, in fact, fixes are not welcome from the team. They have raised a > > major roadblock, allowing only one kind of fix which requires a lot of > > work, and rejecting anything simpler. > > Ever hear of the Technical Committee? This is a technical dispute? Whether your packages need to comply with the DFSG? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 23:28 +0300, Kalle Kivimaa wrote: > Would it be a good compromise between SCs #1, #3 and #4 if we made an > exhaustive list of non-free bits in main, and make it our goal that the > list gets smaller between each release and not to add anything to > that list? I would be entirely happy with that. But I have just been told by William Pitcock that apparently we are required somehow to support new hardware with non-free software too. So it's not a decreasing list, it's an accordion list with no real commitment to the DFSG at all. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 16:00 -0500, William Pitcock wrote: > Unfortunately, those who contribute to Debian must be dedicated to > ensuring future releases of Debian support the latest available hardware > at time of release. No matter what our principles are? Wow. Why are we not equally committed to supporting the latest proprietary codecs? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 22:47 +0200, Frans Pop wrote: > On Tuesday 21 October 2008, Thomas Bushnell BSG wrote: > > I see. So the previous statement that "nobody is standing in the way" > > of a fix is simply not so. People certainly are standing in the way. > > That's nonsense. Uncoordinated NMUs are never acceptable for packages that > are in general actively maintained (which the kernel is), especially not > when it concerns controversial or technically complex changes [1]. > Doing so would be a violation of basic NMU policy. The claim was, hey, nobody is stopping anyone from fixing it, if it's not fixed, it's lame for people to complain, they should have fixed it. But, in fact, fixes are not welcome from the team. They have raised a major roadblock, allowing only one kind of fix which requires a lot of work, and rejecting anything simpler. Yes, certainly the team has the right to make such roadblocks if they think it best, in principle. But then that's what's happening: they are standing in the way of implementing a quicker simpler fix. You can either blame people for not uploading their own fix or prohibit them from doing so, but you can't do both at the same time. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 14:59 -0500, William Pitcock wrote: > If we waited for a release to be 100% perfect, it will likely take > several more years. The good news is that the amount of inline firmware > in the kernel is decreasing. So, eventually, all non-DFSG > redistributable firmware can belong in firmware-nonfree. Do we have an ironclad commitment to not add any additional non-DFSG firmware, period, no matter what? I would accept a compromise which guaranteed an increasing slope. But not a back-and-forth thing. Your reply focuses on regression issues, so is that really sufficient? We guarantee that, say, there will always be *less* non-DFSG firmware in each release, and we guarantee that there will never be *new* non-DFSG firmware. > If the NMU involves removing support for hardware, then no, the NMU's > solution would be in my opinion unacceptable, and hopefully enough > people agree that it would be rejected. Thought so. So the claim that "nobody is standing in the way" was simply false. People are standing in the way of a simple fix for a simple bug, and insisting on a more complex fix. I agree completely that the more complex fix is better, but it is simply not true that nobody is standing in the way of a fix. Rather, they have declared that only one sort of fix is tolerable, and mostly refused to discuss the question. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 21:21 +0200, Frans Pop wrote: > Thomas Bushnell BSG wrote: > > I am *happy* to code an acceptable solution, but I regard "not support > > the hardware for installation" as acceptable. > > I'm very glad that history has shown most developers disagree with you. > > > So I can upload an NMU right now that fixes the problem? > > No, it's not OK. See <[EMAIL PROTECTED]> for a good > description of an approach that would be welcome. I see. So the previous statement that "nobody is standing in the way" of a fix is simply not so. People certainly are standing in the way. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [DRAFT] resolving DFSG violations
On Tue, 2008-10-21 at 20:24 +0200, Pierre Habouzit wrote: > On Tue, Oct 21, 2008 at 05:52:28PM +, Manoj Srivastava wrote: > > This is the part I am not comfortable with. I do not think the > > delegates have the powers to decide when enough progress has been made > > to violate a foundation document in our release. Just like an > > individual developer does not have a right to decide to violate the > > DFSG in their work, I think the release team, which prepares the > > release, can do so unilaterally either (I did not vote for Bush). > > And you're comfortable with ftp-master ruling DFSG-iness through NEW > then ? I don't really see the difference. I can't speak for Manoj, but for my own part, I have not seen any evidence that ftp-master is letting things through NEW which are in clear violation of the DFSG, so it doesn't come up. > FWIW you can query all the lenny-ignore bugs on the BTS, there arent a > lot, and check if you agree. Unlike Bush (and the reference is quite > offensive, really) we don't hide such matters, and we never said we're > not open to discussion. > > BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're > delegated for that (among other things). So far, the release team has shown no awareness in this thread that ignoring a technical RC bug is entirely different from ignoring a violation of the core documents of the project. Nobody is talking about technical bugs, and it would be helpful if y'all stopped bringing them up. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 15:22 +, Anthony Towns wrote: > Thomas: your continued inaction and unwillingness to code an acceptable > solution to this issue, in spite of being aware of the problem since > at least 2004 -- over four years ago! -- means we will continue to do > releases with non-free software. I am *happy* to code an acceptable solution, but I regard "not support the hardware for installation" as acceptable. I ask simply that the project's standards be *applied*, or that at the very least, we have a resolution as we did before. And yes, I would likely vote against it, as I did before. But in a democratic system, people generally are well advised to accept the result of past votes gracefully and work towards the next one. That's what I did; my vote did not carry the day last time, and I have not objected about that decision since. But I *do* object to the apparent new rule that the ftpmasters and release engineers are now empowered to ignore DFSG violations without any review by anyone else. And now we have people saying, "hey, let's exempt firmware from the DFSG!" again, even though we have a GR on topic which decided that, no, firmware counts. > "Hey, you've had four years; we're just going to keep releasing until > you fix the bug." > > Hint: you're not being held hostage by anyone, seriously. You know how > you can tell? Two words: Stockholm syndrome. So I can upload an NMU right now that fixes the problem? That will be ok? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Tue, 2008-10-21 at 08:29 +0200, Marc Haber wrote: > On Mon, 20 Oct 2008 15:49:40 -0700, Thomas Bushnell BSG > <[EMAIL PROTECTED]> wrote: > >On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: > >> No, really. The kernel team are volunteers. Ordering them to do things > >> doesn't help at all; one could equally well send the same message to > >> everyone working on Debian (or, indeed, the wider community) since they > >> could also step up to the plate and help fix this issue. > > > >Of course. These are RC bugs. I would be happy to upload an NMU that > >fixed the RC issue by removing support for the relevant hardware, and > >dropping blobs from the source. I don't think it's a very challenging > >task, but I'm happy to do so. Will that be ok? > > You're not seriously thinking that a release without E100 support does > make any sense and is any good for Debian, right? Yes, I am thinking exactly that. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, 2008-10-20 at 22:26 +0100, Mark Brown wrote: > No, really. The kernel team are volunteers. Ordering them to do things > doesn't help at all; one could equally well send the same message to > everyone working on Debian (or, indeed, the wider community) since they > could also step up to the plate and help fix this issue. Of course. These are RC bugs. I would be happy to upload an NMU that fixed the RC issue by removing support for the relevant hardware, and dropping blobs from the source. I don't think it's a very challenging task, but I'm happy to do so. Will that be ok? > If they were actively stopping people working on these issues then that > would be different but I have not seen them doing this. Great, so since there won't be any active attempts to stop, I can just go ahead with the work, right? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Mon, 2008-10-20 at 20:18 +0200, Robert Millan wrote: > Apparently, our control structures are not reliable enough to _enforce_ > what we have decided. It seems we relied primarily on the release team, > which has betrayed the goals of the project, and only count on the FTP > team as a fallback, which so far has done nothing about it. > > Looks clear that we need to change something don't it? Yes, we need a rule that we never release with non-free software. I thought we already had such a rule, but if the release team needs us to vote on the social contract again, we can do so. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ???lenny-ignore????
On Mon, 2008-10-20 at 19:11 +0100, Mark Brown wrote: > On Mon, Oct 20, 2008 at 10:55:00AM -0700, Thomas Bushnell BSG wrote: > > > I object to a second round of this. I was ok with it once, as a > > compromise, but the understanding I had then was that it was a one-time > > thing, to give time to actually *fix* the problem. > > Note that there is currently active upstream work to allow us to address > these issues - some of the patches are present in 2.6.27, others are > still in flight. This is a vast step forward on where we were with etch > if we do decide to go down the route of releasing with exceptions again. I think we have no need to go "down that route". We do not have to support the hardware at all. That is an option. The fact that the kernel maintainers would prefer a fancier thing is not the point. We can simply not ship support for that hardware *at all*. That's perfectly acceptable to me--even as a user of such hardware. A patch to fix the bug--which is the inclusion of non-free things in main--can be quickly and easily implemented. I'm oh-so-sorry if a fancier fix is not available--but there has been plenty of time. I'm not willing to see another release with non-free blobs in the kernel, especially since it is really quite trivial to remove them. > > We need the relevant maintainers to be told "your unwillingness to fix > > this means we will not be able to release". > > I don't think that's a particularly constructive approach to take, > especially not in a volunteer project. I think that it is singularly non-constructive to see the maintainers of packages regard compliance with our foundational documents as wishlist items, and the release team regard such things as anything other than show-stoppers. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Mon, 2008-10-20 at 11:43 -0500, Manoj Srivastava wrote: > Actually, I think we need a GR on the lines of > , > | http://www.debian.org/vote/2006/vote_007 > | General Resolution: Handling source-less firmware in the Linux kernel > ` > > To get a special dispensation for lenny. I think this would be insane. It smacks of the nonsense of the US Congress extending copyright over and over again, always for a "limited term", but such that the terms just never actually expire. I object to a second round of this. I was ok with it once, as a compromise, but the understanding I had then was that it was a one-time thing, to give time to actually *fix* the problem. The kernel team should *fix the bug* and not just sit on their hands. We should not release until it's fixed. But the continued dishonesty of holding out one set of principles and guarantees, while granting ourselves exceptions on every release, is not tolerable to me. > I do not think that willfully violating the social contract is a > decision for a few delegates to make -- we, as a project, should > acknowledge the need for and make a special exception to release Debian > with known non-free bits in it. We did that once. With the understanding that we wouldn't do it again--or at least, that was my understanding--it was proffered as a special case, a one-time thing, because of the urgency of the case. Moreover, at the time, there was an amendment proposed to make it "as long as required" and it got fewer votes than the one-time thing. Pretty clearly, we *already decided* this issue, and we need no vote. We need the relevant maintainers to be told "your unwillingness to fix this means we will not be able to release". I object very strongly to the feeling that I am being held hostage by developers who will not fix the bug, and then protest "emergency! we must release! no delay! we'll do it next time!" and then sit on their hands again for another go-round. The solution is to refuse to play along, and to say, "hey, you had two years; we're just going to wait until you fix the bug." Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged ‘lenny-ignore’?
On Mon, 2008-10-20 at 16:08 +0200, Robert Millan wrote: > On Mon, Oct 20, 2008 at 08:41:16AM -0500, Manoj Srivastava wrote: > > > > Has the current release team lowered the bar on Debian actually > > trying to follow the social contract? > > Yes, they have. > > Furthermore, the FTP team (which is supposed to be in charge of DFSG > enforcement) has decided to look the other way: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497823 I had understood that we had passed a GR to allow--ONCE--a past release with these bugs not fixed, with the understanding they would be fixed the next time. Have I missed something? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh.upload.debian.org
On Mon, 2008-09-29 at 07:59 +0200, Joerg Jaspert wrote: > Also, is it really interesting to the average DD where this queue is? > People should be able to upload and expect their packages to end up in > the archive. It really *absolutely* does not matter if that upload goes > straight to ftp-master or to a different host first?! You're missing the point. It doesn't matter to me at all that the queue is on ries; I didn't know that until I looked it up. It is "ries.debian.org" which is the host name. You are continuing to scold people for using machine names, when that's not the issue. You are asking people to switch from one symbolic name to using a different symbolic name. Nobody is using the machine name, I'll venture to say. Moreover, I use ftp-master.debian.org because that's what I was told to do when we switched to the current upload procedure via anonymous-ftp. I don't object to you deciding that we should switch names again. But please just say, "you used to use symbolic name X, but that is tied with several other services. we want to split those services into different symbolic names. so for uploads, please use the new name Y." Instead, you seem to be saying, "how could anyone be so stupid as to use a non-symbolic name?" when nobody is actually being that stupid. We're just using the symbolic name we were told to use the last time the names were changed. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh.upload.debian.org
On Sun, 2008-09-28 at 21:51 -0700, Steve Langasek wrote: > On Sun, Sep 21, 2008 at 04:59:58PM +0200, Joerg Jaspert wrote: > > Please always only use the symbolic names for the places to upload to > > (ie ftp.upload.debian.org and ssh.upload.debian.org), do not use any > > machine name directly. Queues may move at any time, without further > > notice and the symbolic names will be updated. > > What conceivable reason is there for ever moving the ftp queue off of > ftp-master? It doesn't make sense to force everyone to switch their configs > from ftp-master.debian.org to ftp.upload.debian.org unless there was an > expectation that the queue would be moved, and I can't see any way that this > would ever be desirable. What byzantine model for uploads is being > proposed, and why? The best part is that I thought ftp-master.debian.org *IS* a symbolic name, as opposed to ries.debian.org which seems like the actual machine name. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh.upload.debian.org
On Sun, 2008-09-28 at 21:51 -0700, Steve Langasek wrote: > On Sun, Sep 21, 2008 at 04:59:58PM +0200, Joerg Jaspert wrote: > > Please always only use the symbolic names for the places to upload to > > (ie ftp.upload.debian.org and ssh.upload.debian.org), do not use any > > machine name directly. Queues may move at any time, without further > > notice and the symbolic names will be updated. > > What conceivable reason is there for ever moving the ftp queue off of > ftp-master? It doesn't make sense to force everyone to switch their configs > from ftp-master.debian.org to ftp.upload.debian.org unless there was an > expectation that the queue would be moved, and I can't see any way that this > would ever be desirable. What byzantine model for uploads is being > proposed, and why? The best part is that I thought ftp-master.debian.org *IS* a symbolic name, as opposed to ries.debian.org which seems like the actual machine name. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: dash bug which is affecting release goal
On Mon, 2008-02-11 at 11:20 +0100, Cyril Brulebois wrote: > On 11/02/2008, Mike Bird wrote: > > Debian should ensure that millions of Debian users around the world > > who have written and tested millions of tiny shell scripts with no > > thought to the possibility that /bin/sh may one day become not-bash > > will not suffer millions of hours of down time (or worse - bad data) > > due to a Debian change. > > If those users are running unstable or testing, that's their job to > track such changes. If they are running stable, that's where Release > Notes can be used. Release Notes do not magically fix millions of tiny shell scripts. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon, 2008-02-11 at 01:54 -0600, William Pitcock wrote: > It's possible for programs to completely change between versions. There > really is no difference in reality between switching from program A to > program B and switching from program A 1.1 to 1.2. The risk of problems > is exactly the same. That's ludicrous. Most developers try to help users with backward compatibility. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 20:39 -0800, Steve Langasek wrote: > So we should also never upgrade /usr/bin/python, /usr/bin/perl, or > /usr/bin/gcc to point at a new upstream version because users may have local > programs that assume particular non-standard behavior from these programs, > right? I think that's a different case. There is a big difference between a newer version of the same program and a totally different program with fewer features. Still, I understand the motivation for the change and I am in support of it. I'm just worried also. Perhaps I'm a needless worrywort. But all the attention does seem to have been focused on one specific case--Debian packages--and not the others. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 19:36 -0800, Russ Allbery wrote: > Raphael Geissert <[EMAIL PROTECTED]> writes: > > > I just replied to Thomas on the bug report including some information > > that demonstrates that his arguments on dash not implementing some (at > > least the one mentioned on the report) /usr/bin/test features is not > > valid. For further reference please see #464995, which is the bug > > report Thomas is talking about. > > So, to sum up the results of that bug, Thomas was specifically using a > bash feature and this entire business of the behavior of /usr/bin/test is > a red herring for the problem that started this whole discussion. Actually, it's upstream's script, a genuine shell program, not just a Debian maintainer script (the more usual case), so the right fix was to specify /bin/bash since that is obviously what upstream was expecting all along. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 21:10 -0600, Raphael Geissert wrote: > > On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote: > > > >> This applies to everything from tarballs of packages which are not yet > >> in Debian to the dozens of tiny custom scripts that everyone has for > >> backups or nagios extensions or adding users or emptying cameras etc etc. > > > > Yes, that's right. > > > > I think the idea of making dash the default /bin/sh is sure to be a > > disaster. But I have no power in that regard. I can only hope I'm > > wrong. > > FYI Ubuntu already made the switch some time ago and they have all of the > packages from unstable + some more. > By filling bug reports I try to reduce the impact of making the move that in > theory should be more than safe (except for two or three known bugs on > dash). I think you're ignoring Mike Bird's concern. What about custom scripts, non-Debian things, user-written scripts, etc.? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 18:12 -0800, Mike Bird wrote: > On Sun February 10 2008 15:54:36 Thomas Bushnell BSG wrote: > > Or to follow Colin's suggestion from the policy discussion a few years > > ago, and grant a special exception, carefully crafted, for particular > > shell builtins. I have no objection to that solution. > > As a Debian user rather than a DD I hope that Debian will ensure that > this solution has absolutely no effect on non-Debian scripts which > use #!/bin/sh and (perhaps unconsciously) expect test to work as in bash. I'm afraid, that the problem here is just that. Debian doesn't promise that /bin/sh is bash. Scripts which need bash are supposed to specify bash. At least, that's the theory. > This applies to everything from tarballs of packages which are not yet > in Debian to the dozens of tiny custom scripts that everyone has for > backups or nagios extensions or adding users or emptying cameras etc etc. Yes, that's right. I think the idea of making dash the default /bin/sh is sure to be a disaster. But I have no power in that regard. I can only hope I'm wrong. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Mon, 2008-02-11 at 01:54 +0100, Pierre Habouzit wrote:
> Well, policy describes usage, and usage (I think) is to assume that
> /bin/sh gives you a decently recent POSIX environment (I said POSIX not
> GNU) and that if you rely on GNU extensions of tools (like echo -e) you
> should call those commands using their full path wich can be done using
> really simple tricks like:
>
> echo() { /bin/echo "$@" }
I believe Policy prohibits the use of full paths to specify programs in
the standard PATH.
> Policy has absolutely no valid reasons to dictate to shells how they
> are implemented, and it's a perfectly sane thing for an efficient enough
> shell to implement echo, test, [, true, false and probably which as
> shell builtins given their pervasive use in shell idioms.
Policy requires that programs which provide the same names as each other
provide equivalent functionality. No exception (currently) is made for
test. I am not at all opposed a carefully written exception for test;
that is the substance of Colin's proposal.
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 22:11 +, brian m. carlson wrote: > On Sun, Feb 10, 2008 at 02:34:37PM -0500, Thomas Bushnell BSG wrote: > >On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote: > >> Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > >> > >> > Dash has a serious bug which is causing grief. > >> > > >> > The problem is that it overrides the system's "test" command (in > >> > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is > >> > inconsistent with the Debian versions. > > As far as I can tell, /usr/bin/test and /usr/bin/[ are completely > useless, because none of bash, dash, posh, or zsh use them. Maybe pdksh > does, but that's pretty much the list of shells that could be coerced > into being /bin/sh. I propose we remove those executables from > coreutils if it turns out that they are never executed. There are many cases where one may well want the test program. We need them regardless. > >The only builtin which we identified needed to be on that list was test > >itself, and the problem here was that the deviations in posh's > >implementation of test would pose serious problems. > > The standard posh follows is Debian Policy. If you change Policy, I am > pretty sure that posh will follow[0]. Policy currently specifies a set > of features that are required above and beyond minimal POSIX standards > (echo -n). I don't know what the particular issue is with posh. It was brought up as an example in the policy discussion a while ago. > I don't see what your problem is with posh. It serves a legitimate > purpose: providing the bare minimum required by Policy. It's useful as > a test of Policy-compliance, and not much more, which is fine. I don't have a problem with posh. It was brought up in the policy discussion the last time. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 11:26 -0800, Mike Bird wrote: > On Sun February 10 2008 10:16:44 Thomas Bushnell BSG wrote: > > Shells can override commands, but only if they don't play games with the > > syntax. > > Agreed. Within the Debian world, dash has redefined test rather > than building in test. Therefore, within the Debian world, dash > is not Posix compliant. Within the Debian world, this is a dash > bug. Possible solutions include Debian-specific patches to either > make dash's test compatible or to disable dash's incompatible test. Or to follow Colin's suggestion from the policy discussion a few years ago, and grant a special exception, carefully crafted, for particular shell builtins. I have no objection to that solution. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 20:34 +0100, Pierre Habouzit wrote: > On Sun, Feb 10, 2008 at 07:17:58PM +0000, Thomas Bushnell BSG wrote: > > > > Or are you saying that it's ok for dash to override random Debian > > commands in incompatible ways? > > Well, let's drop bash right away then ! > > $ bash -c 'type test'; zsh -c 'type test'; posh -c 'type test'; dash -c 'type > test' > test is a shell builtin > test is a shell builtin > posh: type: not found > test is a shell builtin Right. The problem is that Debian policy on the question is incoherent. It was wrong of me to describe it as a dash bug. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > Dash has a serious bug which is causing grief. > > > > The problem is that it overrides the system's "test" command (in > > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is > > inconsistent with the Debian versions. > > Onlookers should see http://bugs.debian.org/267142 for the long history of > the previous discussions of this. Indeed, I had forgotten that we had actually reached consensus and then stalled at the point of getting the list of allowed-to-deviate builtins settled. Colin had proposed the winning solution, IIRC. The only builtin which we identified needed to be on that list was test itself, and the problem here was that the deviations in posh's implementation of test would pose serious problems. That could be solved by saying something like "test may be builtin in inconsistent ways, provided that X, Y, and Z features still are supported." That could be written (by careful choice of X, Y, and Z) to enable bash and dash to pass muster and still avoid the problems that supposedly are raised with posh. The other solution--which may be an acceptible short-term one, is to specify explicitly that shell scripts must work with Debian bash and Debian dash. I have no objection to that, and continue to think it is the simplest approach. As always, I am happy with just about any of these solutions, but the charge-blindly-ahead method is not good. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 10:57 -0800, Russ Allbery wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > Dash has a serious bug which is causing grief. > > > > The problem is that it overrides the system's "test" command (in > > Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is > > inconsistent with the Debian versions. > > Onlookers should see http://bugs.debian.org/267142 for the long history of > the previous discussions of this. Thank you for adding that Russ; I looked and couldn't find it right away. I think we need to address this before we change /bin/sh as default. Merely papering it over is not suitable, because it means we must deal with a changing target; every new "Posix shell" that implements slightly different builtins will cause yet more problems. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dash bug which is affecting release goal
On Sun, 2008-02-10 at 19:58 +0100, Pierre Habouzit wrote: > On Sun, Feb 10, 2008 at 06:16:44PM +0000, Thomas Bushnell BSG wrote: > > Dash has a serious bug which is causing grief. > > > > [ strip whining ] > > > Alas, dash does change the syntax of the command. > > > > [ whine whine whine ] > > What is that change please ? Last time I checked dash supported the > proper POSIX required options, so I'm surprised. Instead of whining, > actually giving a bug's reference and an example of package that is > hindert by this issue would've helped. Dash does not implement the features of Debian /bin/test. It is not sufficient to implement only the features of Posix /bin/test. The policy requires that I adapt to other Posix shells, not other Posix implementations of test, ls, and other things. Or are you saying that it's ok for dash to override random Debian commands in incompatible ways? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dash bug which is affecting release goal
Dash has a serious bug which is causing grief. The problem is that it overrides the system's "test" command (in Debian, /usr/bin/test and /usr/bin/[) and does so in a way which is inconsistent with the Debian versions. Nothing in Posix permits this behavior, but it is tolerated by the standard *provided* the shell does not change the syntax of the command. Alas, dash does change the syntax of the command. Now bug reports are being filed claiming that failure to conform to dash's non-Posixism is a bug. Programs which expect the behavior of Debian's "test" command are not buggy. What is buggy is a shell which overrides the test command in an inconsistent way. There is nothing bash-specific about expecting the "test" command to be implemented in the normal way that Debian's "test" program is implemented. There is no reliance on a non-Posix *shell* feature when one expects *other programs* to work normally. Shells can override commands, but only if they don't play games with the syntax. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
On Wed, 2008-01-30 at 00:21 +0100, Moritz Muehlenhoff wrote: > Thomas Bushnell BSG wrote: > > For my money, you blew it. You don't bootstrap a discussion by > > presenting a pseudo-official email like the one you posted. But we can > > get back to that discussion: cancel the email by saying "whoops, we're > > not ready yet" and then having the discussion first. > > Of course we've discussed this in depth internally before before > proposing it and there was no intention to make it sound "official". > There is no need to become aggressive. I'm sorry for my tone. I know that it was discussed internally; but what I mean is that it needs to be discussed externally as the next step, long before it becomes the expected practice. If there were not important trade-offs, then it wouldn't matter, but the problem is that some of these options do impose significant costs. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introducing security hardening features for Lenny
On Tue, 2008-01-29 at 23:31 +0100, Moritz Muehlenhoff wrote: > Pierre Habouzit wrote: > There are certainly performance trade-offs involved and the final > selection of features will depend on the testing of the respective > maintainers (testing should be eased by hardening-wrapper). What bothers me is that this kind of analysis should have preceded your announcement. I think that hardening is extremely important, but it is not the only important thing. It would be very helpful if your team would consider thinking about the tradeoffs, describing them so people can make some judgments. But that's not what you did: you instead posted a note, designed to sound as official as possible, asking every maintainer to add these flags. That's not right! We should instead discuss it. > We're mostly trying to bootstrap a discussion here, the details on > how to put this into effect archive-wide will depend heavily on the > toolchain configuration proposal by Matthias Klose. Maybe "classes" > of security-sensitivity of applications can be defined, which specify > a set of selected options. For my money, you blew it. You don't bootstrap a discussion by presenting a pseudo-official email like the one you posted. But we can get back to that discussion: cancel the email by saying "whoops, we're not ready yet" and then having the discussion first. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome 1.x removal
On Tue, 2008-01-15 at 19:56 +0100, Luk Claes wrote: > We can surely keep all old cruft in the archive and never release again > (or not with these packages anyway), though I don't think that is > preferred from a quality assurance, security nor release point of view... Of course, this isn't what I suggested. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome 1.x removal
On Tue, 2008-01-15 at 17:02 +, Neil McGovern wrote: > On Tue, Jan 15, 2008 at 11:35:54AM -0500, Thomas Bushnell BSG wrote: > > So please, let these maintainers choose, rather than ordering them > > about. It is *they* who are in a position to decide whether maintaining > > gnome 1.x is worth it. Of course, it will also be up to them to do the > > maintenance. > > > > gnome-libs has now been orphaned for more than a year. I would have > expected it to have been picked up by now. I wouldn't. I don't keep tabs on every package that my packages depend on. One of them could be orphaned and I would never know. > > Most? Really? Wow, I'm impressed. Are you sure? People said this the > > last time around, and they forgot gnucash. How about we let these > > maintainers make that determination rather than you making it for them? > > > Do you know of any specific examples that would cause a problem? No; I haven't investigated it. That's why I am asking to let those maintainers decide. Thinking up yet one more way to make the decision without involving them seems like a poor strategy. There is no need for me to figure out whether there is a specific example or not. Instead, just tell the maintainers, and give them the option. Thomas - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome 1.x removal
On Tue, 2008-01-15 at 13:39 +0100, Marc 'HE' Brockschmidt wrote: > "cobaco (aka Bart Cornelis)" <[EMAIL PROTECTED]> writes: > > "As long as there's interest the software will stay alive" is one of the > > main tenets of Free Software. Consequently, IMHO, as long as there's people > > willing to maintain it, it shouldn't be removed regardless of how old it > > is. > > GNOME 1.x is neither maintained in Debian nor upstream. Noone has > stepped forward to keep it alive. The main reason that it's still in > Debian is that we don't clean up often enough. This is what was said the last time. But nobody asked the maintainers of gnome 1.x packages whether they would maintain it; the team just decreed that nobody would step forward, and started deleting packages. It caused a major headache. I'm asking for a more orderly process this time. Instead of saying "we're deleting this, you will all have to adapt", say, "we aren't maintaining this anymore; if you want it, you'll have to start taking it over." Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome 1.x removal
On Tue, 2008-01-15 at 17:56 +0100, Pierre Habouzit wrote: > > So please, let these maintainers choose, rather than ordering them > > about. It is *they* who are in a position to decide whether maintaining > > gnome 1.x is worth it. Of course, it will also be up to them to do the > > maintenance. > > Now explain me why _you_ who aren't concerned by the transition are from > far the most vocal about it ? Because the last time you all did this it got all the way to deleting the packages and I had to run around and clean that up. I'm asking you to give the maintainers a chance. That's all. Is it really that hard to do? > I opened bugs on the packages so that people can discuss it, and I'll > monitor them closely I said it. The fact that you don't seem to trust my > word that it's exactly what I'll do is insulting. I didn't say I didn't trust your word. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome 1.x removal
On Tue, 2008-01-15 at 10:34 +0100, Pierre Habouzit wrote: > On Tue, Jan 15, 2008 at 01:10:26AM +0000, Thomas Bushnell BSG wrote: > > Don't start filing remove requests until other maintainers have a > > chance. Take the step of contacting those who maintain packages that > > depend on the libraries you want to remove, post RFAs instead of remove > > requests, and only post remove requests after people have had a goodly > > chance to take over maintenance themselves. > > Please, gnome 1.x is discontinued for years now, and the number of > packages that depends upon gnome-libs is fairly limited now, it's a > bearable task. FWIW the current list of package is: This is what people said before, and gnucash nearly vanished from Debian because the gnome team hadn't bothered to alert me or arrange an orderly transition. So please, let these maintainers choose, rather than ordering them about. It is *they* who are in a position to decide whether maintaining gnome 1.x is worth it. Of course, it will also be up to them to do the maintenance. > Most of those package either have far better alternatives (gabber, > gtoaster, …), are libs (lib*, gnomemm, …) or will probably easily drop > the dependency (xemacs21, nethack, …). Most of the upstreams of those > applications are dead, and the applications don't budge, and there is > little point in having them in lenny when you can use the version in > etch on your lenny without a problem. Most? Really? Wow, I'm impressed. Are you sure? People said this the last time around, and they forgot gnucash. How about we let these maintainers make that determination rather than you making it for them? Thomas
Re: gnome 1.x removal
On Tue, 2008-01-15 at 02:20 +0100, Cyril Brulebois wrote: > (Dropping -release, which is not a discussion list, and Pierre, who is > obviously subscribed to both.) > > On 15/01/2008, Thomas Bushnell BSG wrote: > > This is not the right process for something like this. Instead, I > > believe you should find out specifically which packages depend on > > gnome 1.x, and offer those maintainers the option of taking over > > maintenance. > > Although getting recursive rdepends is interesting, are you suggesting > that the release team is supposed to take over the maintenance of > one-could-say obsolete software? No, I said just what I meant: the maintainers of packages dependent on gnome 1.x should be offered the option of taking over maintenance. The release team certainly should not bear that task, unless individuals within it for their own reasons choose to. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gnome 1.x removal
On Tue, 2008-01-15 at 00:07 +0100, Pierre Habouzit wrote: > Then I'll do some more runs of the same principle on other gnome 1.x > related libs until we got rid of them al. > > If you know your package depends on gnome 1.x one way or the other, now > is the time to fix that, package a new upstream, or ask for its removal, > so that it eases our work. This happened once before when the issue was gnucash. I was the gnucash maintainer, and the gnome maintainers had decreed that "Debian must not have gnome 1.x in it!" And all the libraries were about to vanish. This is not the right process for something like this. Instead, I believe you should find out specifically which packages depend on gnome 1.x, and offer those maintainers the option of taking over maintenance. It is not a trivial task to port many programs to gnome 2; it took gnucash a long time. Don't screw over other maintainers; make it easy for them. Don't start filing remove requests until other maintainers have a chance. Take the step of contacting those who maintain packages that depend on the libraries you want to remove, post RFAs instead of remove requests, and only post remove requests after people have had a goodly chance to take over maintenance themselves. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: who are the kernel maintainers?
On Wed, 2007-07-04 at 19:53 +0200, Holger Levsen wrote: > Hi debian-kernel ;) > > for those of you who dont read debian-devel... :-) > > On Wednesday 04 July 2007 18:14, Thomas Bushnell BSG wrote: > > I'm trying to find out who has responsibility for Bug #430646. > > Thomas, if you think that a bug has fallen under the radar of a maintainers > team, why do you send a mail to debian-devel instead to the bug to get the > attention back? I already sent mail to the maintainers. I have also already said that. Thomas signature.asc Description: This is a digitally signed message part
Re: who are the kernel maintainers?
On Wed, 2007-07-04 at 18:18 +0200, Julien Cristau wrote: > On Wed, Jul 4, 2007 at 09:14:24 -0700, Thomas Bushnell BSG wrote: > > > I'm trying to find out who has responsibility for Bug #430646. It's a > > critical bug, which should normally get some attention, and mail to > > debian-kernel on the question, by at least a half-dozen people, has > > gotten no response that I can see. > > > Package: linux-modules-contrib-2.6 > Maintainer: Debian Kernel Team <[EMAIL PROTECTED]> > Uploaders: Daniel Baumann <[EMAIL PROTECTED]> > > Are you really unable to find that out for yourself? Nope. But Daniel Baumann is clearly not the only maintainer. Or is he? If he is the only one responsible, then why is "Debian Kernel Team" listed? I got that part. Daniel Baumann, check. Now, my question is, "Who is Debian Kernel Team?" Just a list of the people, or some description of who is responsible for fixing critical bugs when the uploader hasn't attended to them. Thomas signature.asc Description: This is a digitally signed message part
Re: who are the kernel maintainers?
On Wed, 2007-07-04 at 18:35 +0200, Frans Pop wrote: > On Wednesday 04 July 2007 18:30, Thomas Bushnell BSG wrote: > > > I doubt that that BR deserves an RC severity to be honest. > > > > Really? The package *has no module*. It is a package which exists > > *only to provide a module*. > > Let me phrase it differently then: not all RC bugs are equally urgent. I installed the package, which was automatically upgraded since I have the previous version of the module which you had to build yourself. My network immediately failed. At that point, I had to walk across campus where I could plug in to a wired ethernet, identify the problem, rebuild the module, forcibly install the new package, and now place the package on hold until a fix arrives. The bug bites unsuspecting people by disabling their network. It could even thus be of severity "critical". Thomas signature.asc Description: This is a digitally signed message part
Re: who are the kernel maintainers?
On Wed, 2007-07-04 at 18:26 +0200, Frans Pop wrote: > On Wednesday 04 July 2007 18:14, Thomas Bushnell BSG wrote: > > I'm trying to find out who has responsibility for Bug #430646. It's a > > critical bug, which should normally get some attention, and mail to > > debian-kernel on the question, by at least a half-dozen people, has > > gotten no response that I can see. > > I doubt that that BR deserves an RC severity to be honest. Really? The package *has no module*. It is a package which exists *only to provide a module*. Therefore it seems squarely to be one which "makes the package in question unusable or mostly so". It's like shipping a bash package which doesn't have bash. > Sure. I know the team is somewhat understaffed when it comes to general > issues like this. They'll probably get around to it with the next > scheduled upload. > > I personally think that just sending a polite reminder to the BR or trying > to ping someone on IRC (#debian-kernel surprisingly enough) would likely > be more effective than posturing on this list. Instead of assuming that I'm posturing. Let's see: I did try to send such a polite reminder, of course. Did you check the debian-kernel logs? Or even this very thread, where a half-dozen mails have been sent? How am I supposed to guess what IRC channel it is? Hint: asking. But you object to asking; you call it "posturing". Not *everything* is an attack. I would just like to have someone responsible for the package say *something* about their intentions. Thomas signature.asc Description: This is a digitally signed message part
Re: who are the kernel maintainers?
On Wed, 2007-07-04 at 18:05 +0200, Frans Pop wrote: > On Wednesday 04 July 2007 17:58, Thomas Bushnell BSG wrote: > > Who are the actual kernel maintainers? debian-kernel is listed, but > > that's surely not right, since anyone can join that list. I assume > > that not just anyone who joins debian-kernel is therefore a maintainer > > of Debian kernel packages. > > Is this a trick question or something? Nope. > Are you going to ask the same question about the D-I team or any other > team-maintained package? > > How about: > - those with commit access to the source repository > - those listed as uploaders > - possibly corrected for no longer active people I'm trying to find out who has responsibility for Bug #430646. It's a critical bug, which should normally get some attention, and mail to debian-kernel on the question, by at least a half-dozen people, has gotten no response that I can see. It looks easily fixable, as well. In team-maintained packages, there is a common problem where a mail sent to the giant mailing list doesn't get a reply, because everyone on the list thinks that someone else will reply. Thomas signature.asc Description: This is a digitally signed message part
who are the kernel maintainers?
Who are the actual kernel maintainers? debian-kernel is listed, but that's surely not right, since anyone can join that list. I assume that not just anyone who joins debian-kernel is therefore a maintainer of Debian kernel packages. Thomas signature.asc Description: This is a digitally signed message part
Re: discussion with the FSF: GPLv3, GFDL, Nexenta
On Mon, 2007-06-04 at 02:45 +0200, Wouter Verhelst wrote: > What I was trying to show is that the relevance of a copyright case > brought against you in a jurisdiction outside of your immediate concern > is zero, for all practical matters; that means you can simply ignore it, > and nothing Bad will happen. Therefore, I don't think it makes it > anything even remotely representing non-freeness. This is not true. There is such a thing as "comity", in which those who have won judgments in one court can get another court to recognize the judgment and compel payment. This happens in international contexts, even without a treaty. For example, if a French court issues a judgment against a US citizen, a US court will at least seriously consider giving effect to the judgment. And this happens *without* anything like retrying the case. In federal states, such as the US, this is particularly serious, because the federal constitution *compels* states to give effect to each other's court judgments. Thomas signature.asc Description: This is a digitally signed message part
Re: Bug#427297: ITP: sturmbahnfahrer -- simulated obstacle course for automobiles
On Sun, 2007-06-03 at 12:49 +0200, Andreas Tille wrote: > On Sun, 3 Jun 2007, Andrew M.A. Cater wrote: > > > ... > > This is only my (ill-informed) opinion - I am neither a German, nor a > > German lawyer :) > > I'm not really picky about names and would be quite relaxed if the official > homepage http://www.sturmbahnfahrer.com/ would not support the suspicion > by using a font that at least supports the ill feeling. So even if I don't > want to spekulate about lawyers opinions - it seems to show at least bad > taste of the authors. Isn't this just a standard blackletter font? Thomas signature.asc Description: This is a digitally signed message part
Re: Disable ipv4 fragmentation
On Tue, 2007-04-24 at 17:39 +, J HU wrote: > Dear experts, > > I'm working with sockets in a debian with a version of kernel 2.6.x, and I'd > like to disable the fragmentation of the ipv4 introduce. > I have read that there was the option of modified the file > /proc/sys/net/ipv4/ip_always_defrag but it doesn't exist. > So I'm totally lost and I need to disable that fragmentation or change the > size to the maximum of 65535. > Anyone can help me? Fragmentation is part of IP. Changing the MTU does not prevent fragmentation. Routers and everything in between is permitted to fragment traffic. You can set the DF (don't fragment) bit in various ways, but the result is that routers which need to fragment will instead drop your packets. IP guarantees that "small enough" packets can be transmitted without fragmentation, but that limit is a part of the protocol and not something you can configure. What is the problem you are trying to solve? Thomas signature.asc Description: This is a digitally signed message part
gnucash and etch freeze
One of the unfortunate side-effects of a freeze is that it becomes very hard to get necessary changes into etch when an upstream package is a more rapidly moving target. In the four months since gnucash 2.0.2 was released, much development has happened, and upstream has released several more versions. The general reliability of the program is much improved, with a thousand small annoyances and crashes fixed. I am told also that some of these fixes include security-related issues (most importantly, vulnerabilities through /tmp). Now I simply do not have the time to go through the changelog, pick out changes that I think should be in etch and do them. If the release team shrugs and says, well, ok, go ahead and upload the new version and we'll consider it as-is for etch, that would be great, but my understanding is that this is contrary to the release policy. Is my understanding correct? What is therefore needed, is someone to help with the triage of the changes which have been made so that a more careful etch-targeted upload can be made with the necessary changes, complete with documentation. If anyone is willing to help out in this way, please let me know. Thanks. Thomas signature.asc Description: This is a digitally signed message part
Re: Icons and instructions for the FreeDesktop menu.
On Wed, 2007-01-17 at 10:37 +0100, Loïc Minier wrote: > On Wed, Jan 17, 2007, Thomas Bushnell BSG wrote: > > Unless I'm confused, this is what makefiles are for. How much trouble > > is it to set it up, which must only be done once? > > Why convert it at build time? Can't update-menus do it only when it's > needed (i.e. the menu display only supports XPM)? And even if it's > done at build time, I see no reason each individual maintainer would > reinvent the same .desktop -> .menu snippet, and why hundreds of > packages would maintain a different snippet or a copy of the same > snippet. I have no objection to update-menu doing it, but it doesn't right now, and we are supposed to implement policy as it is, not as we dream it would be if it were better. As for the second part, yes, this is what debhelper is for. A snippet could presumably be put together without much trouble. Thomas signature.asc Description: This is a digitally signed message part
Re: Icons and instructions for the FreeDesktop menu.
On Wed, 2007-01-17 at 09:22 +0100, Loïc Minier wrote: > On Wed, Jan 17, 2007, Charles Plessy wrote: > > am I wrong or one can have foo.png in foo.desktop, and foo.xpm in > > foo.menu? If upstream does not provide an xpm icon, the "convert" > > command of the imagemagick package can easily create one at build time. > > My point is that I shouldn't have to maintain both, or to run convert > each time this is necessary. Unless I'm confused, this is what makefiles are for. How much trouble is it to set it up, which must only be done once? > "Reinventing the wheel" was perhaps not the best way to describe the > problem; I wanted to point out that the Debian meny system has > antediluvian requirements and duplicates the functionality of the GNOME > menu for me. I suggested the Debian menu system would handle or import > the data from the .desktop files instead of requiring me to do it > manually. This does not excuse you, as a Debian maintainer, from conforming to the Debian menu policy, which is designed for more than just GNOME. I agree completely that something better could be found to integrate them, but that's not at all the same question. A Debian maintainer's job is *not* just to package things the way upstream normally does, and refuse to do anything more. > No, but in some use cases they are mutually exclusive. The Debian menu > system is completely useless to me, and I expect to most GNOME and KDE > users. I'm not saying we should drop it since I can't claim it's > useless for everybody. I am saying that the fact it is useless to me > and to most of the users of the GNOME packages I maintain doesn't call > for a good maintenance of the menu entries of these packages; and I am > proposing technical ways to solve this. Supposedly a gnome program will run under KDE. Right? How will a KDE user find it, if not through the Debian menu system? Thomas signature.asc Description: This is a digitally signed message part
Re: python 2.3
On Sun, 2006-12-24 at 02:22 -0200, Henrique de Moraes Holschuh wrote: > On Thu, 21 Dec 2006, Thomas Bushnell BSG wrote: > > On Fri, 2006-12-22 at 00:38 +0100, Matthias Klose wrote: > > > To conclude, the support of multiple python versions is not meant at > > > all as an excuse for lazy debian maintainers depending on python for > > > not following upstream python development. > > > > Are you calling me lazy for not fixing a bug that you never bothered to > > report before you uploaded an illegal NMU? > > WTF is an illegal NMU? Matthias uploaded an NMU where there was no bug report filed. (The filing of a patch is not a substitute for a regular bug report for the bug you think the patch fixes.) Moreover, the bug is a *wishlist* bug and there is no cause for uploading NMUs for wishlist bugs, let alone anything but a release-critical bug. Moreover, Matthias made absolutely no attempt to contact me; he simply went ahead and uploaded. In no way did he follow the procedures to be followed before making NMUs. Thomas signature.asc Description: This is a digitally signed message part
Re: python 2.3
On Fri, 2006-12-22 at 00:38 +0100, Matthias Klose wrote: > An explicitely stated goal of the release team was to reduce the > number of supported python versions for the next stable release. We > did include three python versions for sarge (2.[123]). To reduce that > count we do have to drop 2.3 (prefering 2.5 over 2.3). I've got no complaint against reducing the number of versions, but I think that there should be at least one version of overlap. Thomas signature.asc Description: This is a digitally signed message part
Re: python 2.3
On Fri, 2006-12-22 at 00:38 +0100, Matthias Klose wrote: > To conclude, the support of multiple python versions is not meant at > all as an excuse for lazy debian maintainers depending on python for > not following upstream python development. Are you calling me lazy for not fixing a bug that you never bothered to report before you uploaded an illegal NMU? signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Sat, 2006-11-25 at 21:33 +0100, Mike Hommey wrote:
> > As I said, it is perfectly possible for a maintainer to write a script
> > which works on any shell and allows the user to pick at installation
> > time (heck, or even per-user!) which shell to use.
>
> How cool that would be to be asked 1 times at installation time
> which shell should be used for ${SCRIPT}.
How about once? I think that perhaps there is some non-thinking going
on here, as if one must do everything in the stupidest possible way.
Thomas
signature.asc
Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Sat, 2006-11-25 at 11:31 +0100, Petter Reinholdtsen wrote: > [Thomas Bushnell] > > I'm interested in why we should care at all. Perl is a far bigger space > > hog than bash. > > Debian Edu had to switch /bin/sh from bash to dash to get shutdown to > umount /usr/ when we use libnss-ldap (bug #159771). Bash loads user > information using nss when it starts, and thus loads the shared ldap > library from /usr/ on invocation. This make it unusable in a system > with LDAP users. This is an excellent example of doing the wrong thing, in my opinion. Why not fix the bash bug instead?? Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Sat, 2006-11-25 at 09:51 +0200, Jari Aalto wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > On Fri, 2006-11-24 at 23:55 +0200, Jari Aalto wrote: > > > > Instead of focusing and hammering again and again on /bin/sh, why not > > > > instead ask maintainers to do #!/bin/dash? > > > > > > Because the correct is #!/bin/sh and not to be tied on particular shell. > > > > I can't tell what you mean. There is nothing wrong with using > > #!/bin/dash if that's what the maintainer wants to specify. > > And if the system does not have dash installed? And if the scrpts work > fine with the /bin/sh of his choice? Obviously if you #!/bin/dash you must add a dependency, because dash is not an Essential package. As I said, it is perfectly possible for a maintainer to write a script which works on any shell and allows the user to pick at installation time (heck, or even per-user!) which shell to use. Thomas signature.asc Description: This is a digitally signed message part
Re: Question about "Depends: bash"
On Fri, 2006-11-24 at 18:55 -0800, Steve Langasek wrote: > On Fri, Nov 24, 2006 at 02:21:43PM -0800, Thomas Bushnell BSG wrote: > > If we can support low end systems with *minimal* effort, fine, but you > > are asking lots of *extra* effort. > > I think the two of you are spending far more effort *arguing* about this > than it actually takes, in practice, to keep Debian scripts invoking /bin/sh > compatible with dash. That is, after all, the point you're currently > arguing against, even though this result is already implied by policy's > current mandate for POSIX-compliant maintainer scripts when using /bin/sh as > an interpreter. Has this requirement ever cost you (or anyone) so much > development time that this thread is anything other than absurdly > disproportionate? Actually, I am not arguing against the desire to make scripts compatible with dash. That you think so indicates to me that I have been entirely unsuccessful in getting people to believe me when I have (repeatedly) tried to explain carefully what I *am* arguing. I am arguing that the current policy requirement simply does not mean what people think it means. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Fri, 2006-11-24 at 16:28 -0700, Bruce Sass wrote: > > > but it is Debian's job to be responsive to its users needs and > > > Debian has made a choice to strive for susv3 compatibility > > > > I don't think you understand what "compatibility" means in this > > context. It does not mean that you can substitute any component of > > the system with a different standards-compliant version and > > everything must continue to work. > > So, what does "compatibility" mean in this context? Debian has *achieved* susv3 compatibility. There is nothing more to be done. A compatible implementation is allowed to have special options "behind the scenes" which it uses to implement things. Compatibility (actually, I believe the term is compliance) refers to the entire system, not its individual components. > > > Our users needs do not, by and large, include embedded systems. > > I am glad that "by and large" is not the standard, for that would make > Debian somewhat less universal than it is. *Yawn*. I don't care about making a distribution suitable for every possible purpose. I see no shame in saying that we are suitable for some purposes and not others. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Fri, 2006-11-24 at 15:12 -0700, Bruce Sass wrote: > Sure, but since all "sh" scripts would be better off if they specified > dash as their command interpreter... #!/bin/sh use would disappear. So? > > I don't think it's my job to start saying what *other* distributions, > > which are not Debian, should do. > > but it is Debian's job to be responsive to its users needs and Debian > has made a choice to strive for susv3 compatibility I don't think you understand what "compatibility" means in this context. It does not mean that you can substitute any component of the system with a different standards-compliant version and everything must continue to work. Our users needs do not, by and large, include embedded systems. Thomas signature.asc Description: This is a digitally signed message part
Re: Question about "Depends: bash"
> I'm not sure I follow. I' puzzled why you do not seem benefit in: > > - Making scripts sh-agnostict. That is making them portable > - Supporting low end systems with minimal of effort > - Improving the overall awaress of shells I don't care about the "awareness" of shells, no. If we can support low end systems with *minimal* effort, fine, but you are asking lots of *extra* effort. I don't care about making anything sh-agnostic. bash is just a language; dash is just a language. We don't insist that our C programs be C-compiler-agnostic; we don't insist that lisp or scheme programs be dialect-agnostic; why should we insist this for shell programs? If a maintainer wants to make a script that works with dash and posh and busybox, they can do that too. They can even have a debconf option that asks the user which #! line to use. None of this requires this obsessive nattering about /bin/sh. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Fri, 2006-11-24 at 23:57 +0200, Jari Aalto wrote: > And why do you think that? please take a look at the RES values. I know you don't understand it, because you just appealed to the RSS values. If many processes are sharing text, they all get accounted with the size of the resident text in their RSS, but they are sharing the segment; they are not each getting their own copy. Thomas signature.asc Description: This is a digitally signed message part
Re: Question about "Depends: bash"
On Sat, 2006-11-25 at 00:02 +0200, Jari Aalto wrote: > "fast enought" is in the eye of a beholder. Try with PII/64M with > X deskop with 20 sessions of bash open. And opening firefox and xchat. What on earth is this nonsense about multiple invocations? Do you not understand what shared text is? > > Anyway. What works for some is no indication of that it works for all. > I'm not sure why people are so enthustiastic with bash. It's just a > shell and there are alternatives to it - which are quite nice. I never understood what was so wonderful about perl. Yet, Debian decided to make perl Essential, so there it is. Such decisions have to be made. Nobody is telling you not to use the alternatives. Go ahead! Use them! Encourage other people to! But don't tell me that I *must* use the alternative. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Fri, 2006-11-24 at 23:55 +0200, Jari Aalto wrote: > > Instead of focusing and hammering again and again on /bin/sh, why not > > instead ask maintainers to do #!/bin/dash? > > Because the correct is #!/bin/sh and not to be tied on particular shell. I can't tell what you mean. There is nothing wrong with using #!/bin/dash if that's what the maintainer wants to specify. > Bash is not there "nayway". It is posisble to substitute it for the > reasons explained (memory consumption), without any significant loss of > interactive functionality. And around and around we go. Dash itself say it is not suitable for interactive use, and, bash is an Essential part of Debian. > > The point was making script sh-agnostic. dash is just an > implementation of sh. Someone may very well use busybox or /bin/posh. Sure, if the maintainer thinks one of those is best, they could be used too. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Fri, 2006-11-24 at 14:03 -0700, Bruce Sass wrote: > On Fri November 24 2006 13:15, Thomas Bushnell BSG wrote: > > Instead of focusing and hammering again and again on /bin/sh, why not > > instead ask maintainers to do #!/bin/dash? > > because bash offers a larger superset of sh features than dash, and "sh" > is a standard part of System V-like unix systems like Linux But #!/bin/sh scripts aren't allowed to use those. What I'm saying is that the energy spent on making rules about #!/bin/sh would be better spent encouraging people to simply switch--when appropriate--to #!/bin/dash. > > There may well be advantages to dash for this or that application. > > So then, maintainers should be encouraged to use it. The best way, > > of course, is #!/bin/dash. > > and stop using "sh" altogether, or should the www.emdebian.org people > fork the entire distribution? What I said was that *if* it is better for a given script to run with dash than with bash, the maintainer should be encouraged to say #!/bin/dash. I don't think it's my job to start saying what *other* distributions, which are not Debian, should do. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Fri, 2006-11-24 at 21:08 +0100, David Weinehall wrote: > You can use whatever bashisms you like when you're working > interactively, that won't hinder dash from executing shells on boot and > elsewhere. Using bashisms in scripts does however cause a problem. I think it's time to realize that "bash" specifies a programming language, and so does "dash". Instead of focusing and hammering again and again on /bin/sh, why not instead ask maintainers to do #!/bin/dash? > Oh, and there *are* other suitable interactive shells than bash. tcsh, > ksh, zsh, rc... Whether any of these actually consume less memory than > bash, I cannot say, since I'm a bash user myself on the desktop. Yet > all the scripts I write run perfectly well (and faster) in dash. I said that dash was not a substitute for bash, by its own claim. This is like a game of whackamole. If the claim is made that dash involves less disk space or memory use, it's nearly irrelevant, because bash will be there anyway. There may well be advantages to dash for this or that application. So then, maintainers should be encouraged to use it. The best way, of course, is #!/bin/dash. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Thu, 2006-11-23 at 22:54 +0200, Jari Aalto wrote: > David Weinehall <[EMAIL PROTECTED]> writes: > > > On Thu, Nov 23, 2006 at 07:09:49PM +0100, Steinar H. Gunderson wrote: > > > > Now the choice of 464kB or 4528kB on a desktop where you're actually > > using the shell for interactive things is probably not a big deal, > > personally I'd never use dash, posh, or busybox (except for rescue > > purposes) on a desktop (or server, for that matter) other than for > > scripts. > > Actually it is. In desktop (low memory PC; 64M or less), you open > several terminals to work efficiently. It's quite natural to have > 10-20 open. > > Count 20 x bash against some other alternative shell and the > consumed memory becomes apparent. Somebody needs to explain to Jari the concept of a shared text segment. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Thu, 2006-11-23 at 22:56 +0200, Jari Aalto wrote: > Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > > > On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote: > > > I don't see perl used that much for maintainer scripts, or daemon > > > scripts. > > > > Exactly the *point*. So why isn't this your target? > > > > > Some prefer bash and see no problems. Others consider bash's memory > > > consumption a problem when compared to other alternatives. > > > > The only alternative in Debian is dash, which explicitly says it's not a > > replacement: > > > > "bash" is a better shell for most users, since it has some nice > > features absent from "dash", and is a required part of the system. > > This refers to inteactive use. dash suits well for scripts. You miss the point. If there is any interactive use at all, then bash needs to be on the system. Embedded systems are nifty, but they are not an issue for Debian. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Thu, 2006-11-23 at 20:46 +0100, David Weinehall wrote: > Well, let's hope people don't use any of the non-SuSv3 features of cat > in their shell scripts... Why? Who cares? This is some huge amount of work for some very little benefit. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Thu, 2006-11-23 at 20:07 +0100, David Weinehall wrote: > On Thu, Nov 23, 2006 at 07:49:10PM +0100, Martijn van Oosterhout wrote: > [snip] > > > > There's a difference between requiring maintainer scripts to say > > /bin/bash if they need bash constructs and rewriting existing scripts > > to work with some generic shell. The former is going to be *much* > > easier. Isn't that enough? > > If you just want to avoid things breaking, it's enough. If you want to > be able to use the scripts on an embedded platform, or to take advantage > of the performance boost of using dash instead of bash, it isn't. Debian does not support every need. signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Thu, 2006-11-23 at 13:50 +0200, Jari Aalto wrote: > I'm not suggesting to remove features from essential, but I think the > policy should take the shells as special case, because the > sh-compliances (SusV/POSIX) itself is a matter of its own. There are > no viable alternative implementation of Perl which is in essential, likewise > for the rest. Why should shells be a special case and all the other things mentioned by SusV/POSIX are not? Why do we not want users to have the ability to substitute a different ls, a different du, a different cp, a different cat, a different grep? Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Thu, 2006-11-23 at 19:33 +0200, Jari Aalto wrote: > I don't see perl used that much for maintainer scripts, or daemon > scripts. Exactly the *point*. So why isn't this your target? > Some prefer bash and see no problems. Others consider bash's memory > consumption a problem when compared to other alternatives. The only alternative in Debian is dash, which explicitly says it's not a replacement: "bash" is a better shell for most users, since it has some nice features absent from "dash", and is a required part of the system. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Thu, 2006-11-23 at 13:43 +0200, Jari Aalto wrote: > > Bash is not essential for running Debian. It is possible to run old > PCs and old laptops completely free of bash. The point here is not the > disk consumption, but the reduced memory constrainsts. When scripts > are written with only "sh" in mind, they become portable to even > embedded systems (think busybox). Every bash-dependent scipt that runs > on the system, takes memory out from other processes. What about "perl". Is that essential? Why are you not going for big targets? > Education sector and 3rd world still have PCs that are *years* and > *tears* old. Everybody do not live in countries where computers or > hardware are cheap. Guess what? I used bash on that old hardware when it was shiny and new also. Didn't seem to have any problems. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy, version two
On Thu, 2006-11-23 at 01:15 +0200, Jari Aalto wrote: > > I would drop that "special" case and always require explicit > requirement for the shell. It's more clear to see which packages > "need" bash to make them work. someone may then provide a patch to > "make bash go away". I suggest removing the Russ has already explained why this would violate other parts of policy. I'm interested in why we should care at all. Perl is a far bigger space hog than bash. Someone somewhere told a Big Lie: "bash isn't essential to Debian". Lots of people perhaps believe this lie, and have a Grand Quest to "make bash go away". What is the reason? Why is it worth energy on the part of *everyone else*? Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy
On Sun, 2006-11-19 at 15:47 -0700, Bruce Sass wrote: > > Posix puts grep, ls, kill, test, and echo all in *exactly the same > > category*. So why does posh treat them so differently? > > In the case of ls, because the author "cannot think of a legitimate > reason for anyone to use ls in a shell script", and he thinks "it would > add little value." Presumably grep is in the same boat. Care to know how many scripts in Debian call grep? I checked. It's not a small number. > > > Why is > > catching non-Posix uses of test and echo important, and non-Posix > > uses of ls grep not important? > > I would expect that sh scripts which use non-spec'd features of ls or > grep would be open to receiving bug reports for violating Policy. Why > do you think that is not the case? Because Policy does not mandate compliance with arbitrary Posix implementations. It mandates this only for the shell, under the illusion (apparently) that there is some sense to saying "you can only use Posix shell features" and "you are free to use Debian features of Debian programs". The fact that the shell does not happen to declare any random Debian command as a builtin, and then do something weird with it, is also a non-spec'd feature of the shell. So by your reasoning there is almost no #!/bin/sh shell script in Debian which does not violate Policy. Clearly Policy must not be read in such a way that nearly every script violates it. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy
On Sun, 2006-11-19 at 14:53 -0700, Bruce Sass wrote: > On Sun November 19 2006 14:03, Thomas Bushnell BSG wrote: > > On Sun, 2006-11-19 at 18:43 +0100, David Weinehall wrote: > > > On Sat, Nov 18, 2006 at 08:01:04AM -0800, Thomas Bushnell BSG wrote: > > > > On Sat, 2006-11-18 at 11:30 +0100, Andreas Metzler wrote: > > > > > > Well, the goal was (in part) to catch scripts which use > > > > > > non-Posix features of echo and test; why are non-Posix > > > > > > features of ls not an issue? > > > > > > > > > > > > > > > Since I cannot think of a legitimate reason for anyone to use > > > > > ls in a shell script, I think it would add little value. > > > > > > > > > > > > > Makes you wonder why it's in Posix.2 at all, huh? (Posix.2 is > > > > about scripts, not user interaction.) > > > > > > "The ls utility shall conform to the Base Definitions volume of > > > IEEE Std 1003.1-2001, Section 12.2, Utility Syntax Guidelines." > > > > > > It's a *utility*, not a shell function. > > > > Right. "test" and "echo" are also defined as utilities, not shell > > functions. > > IEEE Std 1003.1, 2004 Edition, section 2.14: > "The term "built-in" implies that the shell can execute the utility > directly and does not need to search for it. An implementation may > choose to make any utility a built-in..." Right. Just like ls, or debconf. Posix puts grep, ls, kill, test, and echo all in *exactly the same category*. So why does posh treat them so differently? Why is catching non-Posix uses of test and echo important, and non-Posix uses of ls grep not important? Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy
On Sun, 2006-11-19 at 18:43 +0100, David Weinehall wrote: > On Sat, Nov 18, 2006 at 08:01:04AM -0800, Thomas Bushnell BSG wrote: > > On Sat, 2006-11-18 at 11:30 +0100, Andreas Metzler wrote: > > > > Well, the goal was (in part) to catch scripts which use non-Posix > > > > features of echo and test; why are non-Posix features of ls not an > > > > issue? > > > > > > > > > Since I cannot think of a legitimate reason for anyone to use > > > ls in a shell script, I think it would add little value. > > > > > > > Makes you wonder why it's in Posix.2 at all, huh? (Posix.2 is about > > scripts, not user interaction.) > > "The ls utility shall conform to the Base Definitions volume of IEEE Std > 1003.1-2001, Section 12.2, Utility Syntax Guidelines." > > It's a *utility*, not a shell function. Right. "test" and "echo" are also defined as utilities, not shell functions. Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy
On Sat, 2006-11-18 at 11:30 +0100, Andreas Metzler wrote: > > Well, the goal was (in part) to catch scripts which use non-Posix > > features of echo and test; why are non-Posix features of ls not an > > issue? > > > Since I cannot think of a legitimate reason for anyone to use > ls in a shell script, I think it would add little value. > Makes you wonder why it's in Posix.2 at all, huh? (Posix.2 is about scripts, not user interaction.) How about grep? Is there a legitimate reason to use grep? Can we have a list of which Posix.2 shell commands may not be legitimately used in shell scripts? Thomas signature.asc Description: This is a digitally signed message part
Re: Proposed new POSIX sh policy
On Fri, 2006-11-17 at 18:15 -0500, Clint Adams wrote: > A builtin ls might be a good idea for disaster recovery shells, > though zsh-static does not have it. posh is not intended to be > such a shell, nor to be particularly useful interactively. > Since I cannot think of a legitimate reason for anyone to use > ls in a shell script, I think it would add little value. Well, the goal was (in part) to catch scripts which use non-Posix features of echo and test; why are non-Posix features of ls not an issue? Thomas signature.asc Description: This is a digitally signed message part
