Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Steve Greenland wrote: You might consider including a default filter so that the only candidates for automatic removal begin with 'lib' and don't end with '-dev'. This seems rather silly. The whole point of this feature is to distinguish those packages that you manually requested from those that were installed solely because of Depends, Recommends, or Suggests in another package. The idea here, rather obviously, is that if I install package A, then remove it, I should have my system pretty much back to the state it was in before I installed A (modulo any conffiles that may be left behind, since aptitude doesn't purge auto-removed packages, just removes them). This isn't true with dselect because everything that A depends on that I didn't already have is left behind. Aptitude fixes this problem in a general way that applies to all types of packages. Limiting it to lib packages, and/or excluding -dev packages, makes the fix less generally effective. Specific examples that would be broken by your suggestion: - debian-goodes, wmget, and a handful of other packages depend on curl. If they are all removed, and the auto-remove flag is set on curl (indicating that you don't want curl for itself, but only because the other packages use it), then curl should also be removed. - kde-devel depends on several other packages, some of which don't begin with lib, others of which are lib-*dev. Again, if these packages were only installed because of kde-devel, they should be removed when kde-devel is removed. Clear the auto-remove flag if you want to keep them. Note also that aptitude will always show you what it's going to do before it does it, so it's trivial to hit '+' on packages that are about to be auto-removed if you want to keep them. Craig signature.asc Description: Digital signature
Re: Annoyances of aptitude (Was: Where are we now?) (Was: Bits from the RM)
Wouter Verhelst wrote: The way this garbage collection is implemented is one of the main dislikes I have about aptitude. Aptitude contains a database with packages that have been installed through aptitude; as such, it contains no information on packages that were installed through a different dpkg-frontend. Which is no problem in itself, except that aptitude assumes a package which has not been installed through aptitude is not wanted; this makes a transition from a different dpkg-frontend to aptitude cumbersome, to say the least. I don't know if this might be a bug that has crept in at some point, but when I first used aptitude, it assumed that everyone on my machine was _not_ to be automatically removed. Which seems like the right default. Craig signature.asc Description: Digital signature
Re: About NM and Next Release
Steve Lamb wrote: No. But you said that the opposite is the wrong reason. If we like Debian it is a bad reason to want to contribute. So the it is only logical to presume that if you feel liking is a bad reason disliking might very well be a good one. This is logical? In what universe? Andrew said that merely liking Debian wasn't a good enough reason to want to join the project. His point, I think, was that you should have a desire to _do_ something in particular, whether or not you are a Debian developer. Is your goal to be a Debian developer, and you're willing to do some work in order to be accepted into the project? Or is your goal to get some useful work done, in which case being an official developer is just a convenience? Obviously you want people who like the project to contribute. For meaningful values of contribute, sure. But being a project member with a d.o account is not essential to contributing, and its arguable how significant a contribution it is to just maintain a few packages when Debian is so big already (unless they're important packages, in which case it seems you are more likely to get through the NM process quickly). I don't deny that the sponsorship requirement for non-developers is annoying, but if worse comes to worst, you can simply set up your own repository and Bugzilla somewhere and publicize its location for the benefit of those users who want your packages. If you don't have the bandwidth or full-time connection or hosting arrangements to do such a thing, well, gee. Life is hard, isn' t it. No, I am pointing out that it appears that Debian, on the whole, needs an attitude readjustment. On the one hand you have d.o people blasting people for not contributing and on the other you have d.o people discouraging people from contributing. You cannot have it both ways. Either you accept the contributions that come or you stop blasting people because they don't contribute. The NM process, viewed from the outside (and I'm on the outside too), looks like quite a mess. I dislike the obvious dishonesty of the project having a documented process for new maintainers, important aspects of which are ignored by the people responsible for running it. That this is excused by various other project members is rather sad. If the Debian project and its leadership are unwilling to require (and enforce the requirement) that the DAM follow the NM procedure as written, including formally rejecting people if they're not going to be approved, then the documentation should be updated to reflect this. At least it would be honest, whatever else one might say about it, to say openly that unacceptable applicants will be ignored until they go away. Craig pgpCPXutAV28z.pgp Description: PGP signature
Re: About NM and Next Release
Chris Cheney wrote: The only people actually waiting that long now (aiui) are people James does not want in the project at all. Then why are they left hanging indefinitely rather than being rejected? Also, it seems like most DD's don't maintain many packages anyway. Yes there are other things that a DD can do other than just maintain packages, like help with web translations, boot floppies, etc. But nearly two thirds of the developers/sponsored developers maintain 4 sources or less [0]. If even half of those 746 maintainers focused on helping close RC bugs we would probably be close to releaseable today. We don't need more people to throw at the problem, we need more people willing to do work for the project. Is there something wrong with maintaining only a few packages, especially if the time has one has available to do Debian work is quite limited? Are you suggesting that someone who maintains only a few packages is more trouble than they're worth, and that the project would be better off if they just quit? Craig pgpxp4aKMXmoY.pgp Description: PGP signature
Re: i386 compatibility libstdc++
Ben Collins wrote: I bet someone would rebuild base+some extras using i386 target compiler and make it available, if Debian did that. They would probably serve a few hundred users total, at best. I don't think it would be too much to expect debian-i386 to become a side-project. debian-i386 could be a much smaller distro, too. Is anyone really running XFree86 4.2 or similarly heavyweight programs on such ancient machines? The slowest machine I ever work with these days is an old Pentium-90 with 32 MB RAM. I won't even put X on that anymore, though it did have X back when it was my only Linux machine. Craig pgpw6hHv8lgmE.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
David Nusinow wrote: Honestly, how bad is removing this message? Is removing this really plagiarism? No, as credits will be given as due in the credits file. Right. Plagiarism would be replacing the credits with other credits, claiming to have written someone else's work. That word has no relevance whatsoever to this situation. Nobody's trying to take credit for Reiser's work. Is this bowlderization? Bowdler is a man who took Shakespeare and re-wrote it to remove the sexual bits, trying to sterilize it. Somehow, I don't think that's what's happening here in any fashion. Right again. Bowdlerization would be if we went through Reiser's code taking out all the sexual innuendos in the comments and variable names. Or maybe just changing all his recursions to loops in a fit of C-bigot anti-functional-programming mania. Has anyone done this? Of course not. Once again, the word has no relevance to this situation. Is Hans' art as a programmer really hanging on this piece of code? It's not like this affects the ability of the program to function properly, and in fact probably makes it function better in more cases. So it's not like this move is hurting anyone's reputation. Of course not. Reiser is hurting his own reputation with infantile, irrational behavior like these accusations more than anyone could hurt him by trying to plagiarise or bowdlerize his work. Craig pgpJ3LJuvzRfG.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
Martin Pool wrote: For example, at least two people called Hans a troll. An upstream author expressing concern about the way their code is packaged is not trolling (i.e. making random arguments just to provoke flames.) Considering that Reiser waved his arms frantically but said nothing of substance, accused people of plagiarism and bowdlerizing without saying exactly what they did (and he STILL hasn't said!), I think the accusation of trolling holds up quite well. I'm glad to see people are trying to find a compromise. I'm sure one is possible with some goodwill. You may be giving Reiser too much credit there, but we'll see... Craig pgpZPJAlmgYQd.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
Colin Watson wrote: I note that few people are cc'ing Hans Reiser on things they seem to expect him to respond to; is everybody assuming that he's subscribed to debian-devel? If he sends mail to debian-devel, it's nobody's fault but his if he never sees the replies. I didn't see any Mail-Followup-To headers in his messages, and I have not manually or otherwise intentionally removed him from the Cc list in any of my messages. We do have more or less real-time web archiving, so it's not essential that he actually be subscribed. Craig pgp15yehBHGBk.pgp Description: PGP signature
Re: If Debian decides that the Gnu Free Doc License is not free...
Florian Weimer wrote: Hans Reiser [EMAIL PROTECTED] writes: I want the same visibility of credits for reiserfs that movies give for their actors. So you are concerned with the missing ad when mkreiserfs runs? In this case, your analogy is wrong. The message does not give proper credit to developers (actors), but those who help to fund the development (the film studio, the producers or some VCs). Well, I certainly hope he doesn't want the kind of visibility that the studio and producer have. Can you imagine it? # mkreiserfs [clear screen] N A M E S Y S and H A N S R E I S E R in association with M P 3 . C O M present a H A N S R E I S E R production of a H A N S R E I S E R program M K R E I S E R FS etc. etc. etc. pgprJBDlSuJqd.pgp Description: PGP signature
Re: plagiarism of reiserfs by Debian
Chris Cheney [EMAIL PROTECTED] wrote: First of all emacs is pure bloat so who cares what it does... Don't be an ass. There are a lot of people who would say the same of KDE, so it's silly for one of the main Debian KDE maintainers to be saying such a thing. Craig
Re: Bug#189347: stop the manage with debconf madness
Andrew Suffield wrote: On Thu, Apr 17, 2003 at 12:47:38PM +0200, Mike Hommey wrote: On Thursday 17 April 2003 02:32, Colin Walters wrote: On Wed, 2003-04-16 at 20:21, Chris Hanson wrote: I'd rather fix this properly; what you suggest is a workaround. What I consider a proper fix is to redefine the configuration files so that they can be parsed. I have learned, the hard way, that using shell scripts for configuration files is a bad idea. That's true, it's definitely a workaround. The way I did it in fontconfig is the way I think it should be done in packages which can't (or can't easily) losslessly parse their configuration files. OTOH, xml config files (like fontconfig's config) could be losslessly parsed through xslt processing... Much like any other config file can be losslessly parsed by processing them. That's not really very helpful. Yes, but with a standard format such as XML, you don't have to write your own code to parse or generate them. On the other hand, I don't think we really want package configuration scripts to require XML tools, do we? Craig pgpQykjQguk42.pgp Description: PGP signature
Re: location of UnicodeData.txt
Branden Robinson wrote: On Mon, Dec 02, 2002 at 12:20:26PM -0500, Jim Penny wrote: So, can a standard be DSFG free? Strictly speaking, no. A standard is an idea, or a collection of ideas. There are many ways to express an idea, so there are many ways to express a standard. Some of these expressions may receive copyright protection. The correct question, I think, is Can a standards _document_ be DFSG free? I think it could be, but most probably are not; a standards document is usually copyrighted by the organization that governs the standard, and in the absence of an explicit grant of the right to make derivative works, such a document would not be DFSG free (to the best of my understanding). Craig
Re: description writing guide
Steve Greenland wrote: (Of course, if this is the worst problem we have with Debian package descriptions, I say flip a coin and forget about it.) I have a better idea -- just forget it altogether. It doesn't need to be standardized in Debian; it certainly isn't standardized in the publishing industry, which has more need to worry about typographic quality than Debian needs to be. An extra space character, or the absence of one, hurts nobody. Craig
Re: description writing guide
David B Harris wrote: Also, in the description template, two spaces are used after a period - is that standard nowadays? (My understanding was that they were primarily used for variable-width fonts, where a single space would take up very little page space. There was an interesting discussion about this in debian-user a few months back, with inconclusive results. People who learned to type on mechanical typewriters with fixed-width fonts generally were taught to use two spaces between sentences (and perhaps after colons as well). So to say that two spaces were primarily used for variable-width fonts is historically wrong; if anything, they were, and are, more commonly used with fixed-width fonts. Technical writing teachers usually go out of their way to get their students to unlearn the two-spaces rule, and use only one space. I do not know whether this is related to the fact that most documents produced by technical writers are typeset with variable-width fonts. During the debian-user thread on this subject, I did a quick survey of several professionally-typeset books that were near at hand at the time. IIRC, I found that about 70-80% of them did not use extra space between sentences. This seems like enough to show that the general bias in typesetting is to use a single space between sentences, but it also shows that it's not an absolute. As you can see from this message, I have completely given up on two spaces, and always put only one space between sentences. I originally learned to type on a typewriter, and was told to use two spaces; I did this religiously until I did some technical writing and was told by the other tech writers on staff to use only one space. I then observed that my documents looked better without the extra space leaving ugly holes in my paragraphs, and that most books and magazines didn't have the extra space. I have been a single-space writer ever since. Since the descriptions should be presented in a fixed-width font (for many reasons, this also includes GUI package browsers), they're a bit redundant.) I don't see any reason why package descriptions shouldn't be presented in variable-width fonts. The right margin might look a bit ragged (assuming the program preserves line breaks, which is probably a good idea to avoid messing up bulletted lists in the description), but so what? Package descriptions don't usually include tabular data that would be seriously messed up by variable-width fonts. Craig
Re: description writing guide
Scott James Remnant wrote: In correct English grammar and typography the space after a full stop (period in Merkin) is supposed to be a wider space then that between words and after commas and suchlike. Therefore typists were always taught to press the space key twice after a full stop. This rule applies to any *fixed*-width font. So it would be correct to use two spaces after the full stop in a package description, because those are renfered with a fixed-width font. They are? Everywhere? By everyone? I would probably agree that _most_ package managers (especially non-GUI ones, of course) display descriptions in a fixed-width font, but you can't guarantee that they all do. Nor am I aware of anything in Debian policy that says they should. I suppose you could argue that the convention should be in accordance with the most common user experience, but the whole idea of having different rules for fixed vs. variable-width fonts runs into trouble when you don't know what kind of font will ultimately be used by any given user's configuration. If you are writing text in something that uses variable width fonts, the program should know about English grammar and render the wider space itself on any whitespace. (LaTeX is about the only thing that gets it right though). Hmm, you just gave a rule specifically for fixed-width fonts, and now you're tacitly assuming that it applies to variable-width fonts as well? (If this is wrong, blame the secretary I just asked :) There are certainly a lot of professionally-typeset books and magazines out there that don't use extra space between sentences. It's not universal, however. Some do, and some don't. My impression is that the majority of professionally-typeset material does not use extra space. I'm not sure how useful a rule is, regardless of its authority, if most of the people who ought to know enough to follow it choose not to do so. Shall we rigorously avoid splitting infinitives, as well? (That's sort of a cheap shot, since IIRC recent editions of Strunk White no longer argue against split infinitives, but then again, that rule was dropped because it was so commonly violated, not because the community of professional grammarians changed their mind about it.) Craig
Re: Fwd: Please confirm your message
Brian May wrote: On Tue, Dec 03, 2002 at 10:22:32AM +1300, Corrin Lakeland wrote: Personally I think bayesian based spam filters are a godsend. They're a bit naive in places such as being unigram or bigram based, but that'll probably get fixed in version two. And already they are still amazingly good. Are these packaged for Debian? dpkg -p bogofilter apt-cache search Bayes Where can I find more information? Google is your friend. This is the first thing it finds for Bayesian spam filter -- the article that got the whole idea going in the first place: http://www.paulgraham.com/spam.html Craig
Re: GNOME not starting
Thomas Hood wrote: Arthur de Jong [EMAIL PROTECTED] wrote: (I had to downgrade from 2.1.0-1 to 1.0.3-2.2) If you don't have them anymore, you can get them from: ftp://ftp.debian.org/debian/pool/main/b/bonobo-activation/ Unfortunately, version 1.0.3-2.2 is disappearing from mirrors, leaving only 2.1.0-1 and 0.9.6-1. I was lucky to be able to get version 1.0.3-2.2 from a slow-to-update mirror. There are private repositories and web sites that are intentionally retaining the working versions. Such as mine: http://crdic.ath.cx/debian/ which is NOT an apt-gettable repository, just a web site with copies of recent-but-not-quite-current Sid packages. Craig
Re: broken dependencies gphoto2
Mathias Klein wrote: just to let you know: +++cut+++ :# apt-get install gphoto2 Reading Package Lists... Building Dependency Tree... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: Sorry, but the following packages have unmet dependencies: gphoto2: Depends: libexif5 but it is not installable +++cut+++ Shouldn't gphoto2 depend on libexif7 ? There is already a bug filed about this: #170292. The maintainer replies: gphoto2 2.1.0 is not compatible with the new libexif in debian/sid. gphoto2 2.1.1 will be out soon, the package is ready. I will upload gphoto2 2.1.1 as soon as possible. Craig
Re: Are we losing users to Gentoo?
Eduard Bloch wrote: #include hallo.h * Branden Robinson [Fri, Nov 22 2002, 10:34:21AM]: On Fri, Nov 22, 2002 at 02:20:04AM -0800, Jim Lynch wrote: (1) Why are you blatently insulting people on the lists?? Why are you blatanly misspelling blatant? Best example for the difference between you and most other top developers - stupid personal attacks when running out of arguments. A good reason for not voting for you in the next DPL election. Didn't look like a personal attack to me -- more like a joke. I even found it mildly amusing. Craig
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
Fabien Penso wrote: I think you will hear soon than the person who posted that to Slashdot was wrong and misunderstood the license. See the following... , | From: Steve Syatt [EMAIL PROTECTED] | To: [EMAIL PROTECTED] | Cc: [EMAIL PROTECTED] | Subject: mp3 licensing | Date: 28 Aug 2002 11:40:10 -0700 | | Dear Patrick, | | I am the public relations person for Thomson multimedia (mp3 licensing) and | was copied on your email. Please take a look below at the company statement | response from Thmomson multimedia regarding the Slashdot posting - which was | written by someone who completely misunderstood the mp3 licensing program! | Most important, there is no change whatsoever to the mp3 licensing program, | which has pretty much stayed intact since its inception in 1995! Please | stay with mp3 - it has always been Thomson's biggest objective to be totally | accessible and fair to the consumer, and always will be! | | Sincerely, | | Steve Syatt | SSA Public Relations (for Thomson multimedia, mp3 Licensing) ` So, once again, we see that the folks at Slashdot are not journalists and have no conception of even the most simple forms of fact-checking. Thank you, Slashdot, specifically Chris di Bona, who posted the original story about this. Okay. So apparently there's no need to drop mp3 decoders from Debian or other Linux distros (certainly not the non-commercial ones, at least). In which case, there is no pressing need for people to convert their mp3 files to some other format just to avoid legal difficulties. Craig pgpieaeKzGgYJ.pgp Description: PGP signature
Re: Bug#158631: ITP: mp32ogg -- Converts mp3 file to Ogg Vorbis
Julien Danjou wrote: Package: wnpp Version: N/A; reported 2002-08-28 Severity: wishlist * Package name: mp32ogg Version : 0.11 Upstream Author : Nathan Walp [EMAIL PROTECTED] * URL : http://faceprint.com/software.phtml * License : Artistic License Description : Converts mp3 file to Ogg Vorbis Aside from the possible legal difficulties involved in adding to Debian yet another program that needs or incorporates an mp3 decoder, I object to this program on the grounds of stupidity. Transcoding from mp3 to vorbis cannot improve sound quality, and will almost certainly degrade it, since the resulting vorbis file will retain all the mp3 artifacts and add vorbis artifacts as well (which are admittedly much more subtle than mp3 artifacts, but still quite real). It is much better to re-encode from the original source material if at all possible; if you can't do that, and can't leave it in mp3 format for whatever reason, then transcoding to vorbis is as easy as converting the mp3's to .wav format and then running them through oggenc. This is so trivial that there's no need for a dedicated program in the Debian repository to do it. Whenever the subject of mp3-vorbis (or wma-vorbis, or any other lossy codec to vorbis) transcoding comes up on the vorbis mailing list, the reaction from the vorbis developers and the more knowledgeable vorbis users is don't do it. Aside from the effect on quality, the vorbis developers are also concerned with the effect on vorbis's reputation of the P2P sharing networks becoming flooded with crappy-sounding mp3-vorbis transcoded files. Craig pgp5YwP6DHBYo.pgp Description: PGP signature
Re: Bug#158631: ITP: mp32ogg -- Converts mp3 file to Ogg Vorbis
Reagan Blundell wrote: However, if I decided to stop using MP3 decoders today, Why do you have to stop? You already have one. Keep using it until you don't need it anymore. In the meantime, gradually re-rip/encode your CDs one by one. Craig pgphngQCMQnYh.pgp Description: PGP signature
Re: Bug#158683: ITP: oggasm -- MP3 to Ogg converter
Robert Millan wrote: * Package name: oggasm Upstream: Sean Kellogg [EMAIL PROTECTED] * URL : http://oggasm.sourceforge.net/ * License : GPL Description : MP3 to Ogg converter I'm not the ITPer, Sean Kellogg [EMAIL PROTECTED] packaged orgasm but haven't moved to include it in debian. I'm contacting him. Funny you should bring this up today; we've just been debating an ITP of another mp3-vorbis converter, with several of us arguing that such programs are 1) a bad idea because converting mp3 to vorbis creates bad-quality vorbis files full of mp3 artifacts; and 2) unnecessary, because the conversion is trivial. When this question comes up on the vorbis mailing list, the vorbis developers and the more knowledgeable users all say don't transcode from other lossy codecs to vorbis. Furthermore, with the recent announcement of patent royalties from Frauenhofer, it seems that Debian may need to remove all packages that are covered by the mp3 patents, at which point an mp3-to-vorbis converter would either be removed, or would be dependent on software that is no longer part of Debian. So my comment on this ITP is the same as for mp32ogg: let's not have it in Debian. Craig pgpaiQGodS8D9.pgp Description: PGP signature
Re: chroot administration
John Hasler wrote: Russell Coker writes: They don't apply to SE Linux either, the NSA says that SE Linux is licensed under the GPL only. If anyone wants to dispute that then they have to sue the NSA... The licensing of the software is orthogonal to the licensing of the patents. Not entirely. See Section 7 of the GPL. Craig pgp2Lxx9UkyW9.pgp Description: PGP signature
Re: spamasassin/razor (do not upgrade)
begin Robert van der Meulen quotation: Sorry, i was referring to 1.20-1 indeed. Interesting. 1.20-1 seemed to be working for me. However, just to be safe, I've downgraded to 1.19-1 and marked the package hold. Can we expect a fixed 1.20-2 shortly? I don't see one in Sid or incoming. Craig pgpfXEFeSux8B.pgp Description: PGP signature
Re: spamasassin/razor (do not upgrade)
begin Robert van der Meulen quotation: Please don't upgrade spamasassin/razor today, as it, ehm, doesn't work. I made a boo-boo in yesterday's upload, which basically f*cks it up. A new upload will follow later today, adressing these issues. There was no new spamassassin or razor in Sid today. The last update of spamassassin was on 9 April (2.11-4), and of razor, 15 April (1.20-1). Nor is there a new spamassassin or razor in incoming.debian.org. So, since you neglected to supply the version numbers of the faulty packages, I am unsure whether you're referring to an upload that didn't make it into Sid today, or to razor 1.20-1. Should we all downgrade to razor 1.19-1, or is that one okay? (It seems to be working, but you also didn't tell us what the bad package's symptoms are, so I can't evaluate this with certainty either.) I'm glad you take the effort to package these things for us. I use them and appreciate them. But your problem report is so lacking in information that it's basically useless. Craig pgpNwmDYKd3PJ.pgp Description: PGP signature
Re: Why XFree86 4.2 Isn't in Woody
begin Branden Robinson quotation: A couple of people on a recent thread in debian-devel linked to a message I recently posted on Slashdot on this subject. I had thought about posting this information to Debian's lists as well, but at the time, didn't see a need. Thanks to that recent thread, now I see a need. :) [snip] Branden, as one Debian user, I would like to thank you for the tremendous job you do on the X packages. Debian's X has worked flawlessly on my machines. Unlike many less-complex packages, I have never installed a new X package and found it fundamentally broken. (And this is running Sid, mind you, so I'm not getting the benefit of two weeks of other users' testing.) I await 4.2 patiently. I don't want to see it until you feel it's ready, and as long as there are 4.1 issues to deal with for Woody, obviously that should be your focus. I'll also add that some of my time (some of it paid for by my employer) has being going towards trying to solve a problem that people have been complaining about even more loudly -- and for a greater duration -- than the absence of XFree86 4.2 Debian packages: Debian's installer. Some people just don't like Debian's existing text-mode installer, no matter how flexible it is. They want a GUI installer, darn it. Progeny's version of Debian got pretty positive reviews, and several people said Progeny solved the problem with Debian's installer. If we get a nice GUI installer, that's great, but it's JUST PLAIN STUPID for people to claim that there is anything wrong with a text-mode one. I've installed Potato several times (usually dist-upgrading to Sid almost immediately thereafter). I _like_ that installer. It may not be as pretty as Red Hat's, but it's more than adequate, and it makes sense to me that an OS installer should make minimal demands on the system. Still, as I said, a GUI installer's fine with me as long as it works well, so I look forward to seeing the fruits of your labors in Woody+1. I'll take a look at your work-in-progress next time I do an install. Craig pgptloKRLAEOc.pgp Description: PGP signature
Re: Please see the GNU FDL discussion on debian-legal
begin Gustavo Noronha Silva quotation: Em Tue, 9 Apr 2002 14:26:39 +0300, Richard Braakman [EMAIL PROTECTED] escreveu: If the GFDL were a free to use and modify license, then we would not be having this discussion. The problem is that the GFDL specifies parts that we are _not_ free to modify, or even to delete. indeed, I would not like to see people modifying my points of view and redistributing saying that's what I think, you see Come off it. The license can specify that changes be identified without requiring that sections never be changed or removed. You might as well argue against the GPL on the grounds that someone might add a lot of stupid bugs into your program and then redistribute it, thus making you look like an incompetent programmer. This is why Section 2 of the GPL requires prominent notice of any changes made. I am less familiar with the GFDL, but I expect it includes a similar requirement. So leave the straw men out of this, please. (Though admittedly we might have less to discuss then.) Craig pgpp09vHSdsXk.pgp Description: PGP signature
Re: The GNU Free Documentation License (GFDL) and /usr/share/common-licenses
begin Dale Scheetz quotation: On Sun, 7 Apr 2002, Branden Robinson wrote: As usual, this issue has been beaten to death on a list you don't read. Please review the archives of debian-legal for the past several months. In a nutshell: 1) The current version of the GNU FDL is uncontroversially DFSG-free if there are no Cover Texts and no Invariant Sections. Note that your license notice is supposed to indicate the presence or absence of Cover Texts and Invariant Sections. 2) The Open Publication License (OPL), is also uncontroversially DFSG-free when none of the license options are exercised. So, in fact, both of these licenses are non-free, as they contain clauses that can be used, and will be considered non-free. No. Specific optional aspects of the licenses, which are required by the licenses themselves to be declared in the license notice contained in the covered document, are non-free. The licenses can be used to make documents DFSG-free, and I believe DFSG/OPL documents are essentially DFSG-free by default, since the conflicts arise only when these options are explicitly invoked by the copyright holder in the license notice. I find it ... foolish to declare a license to be free IFF some clauses of the license are not exercised. Using this language, any proprietary license becomes free as long as none of the proprietary sections are inforced by the author... Let's try this again, as you seem to have misunderstood what Branden wrote. If a document is covered by GFDL and contains no Cover Texts or Invariant Sections, then that document is, according to Branden, uncontroversially DFSG-free. (I say according to Branden because I don't read debian-legal either, nor have I taken the time to check the archives.) If a document is covered by OPL, and the license notice does not declare any non-DFSG-free options, then that document is, according to Branden, uncontroversially DFSG-free. This has nothing to do with enforcing license terms after the fact, so your claim that any proprietary license becomes free ... [if] not [e]nforced by the author is a complete non sequitur. It has, instead, to do with how the license is applied to the document in the first place. If a GFDL document has Cover Texts or Invariant Sections, those sections must be explicitly identified by the copyright holder in the document's license notice (I believe this is a requirement of the GFDL itself). If no such sections are identified, then the document is fully modifiable, and therefore DFSG-free. Why you find this hard to understand is a bit of a mystery to me. Craig pgpI1NENdpLGL.pgp Description: PGP signature
Re: Please don't do this (code fragment)
[EMAIL PROTECTED] wrote:
On Mon, Jan 14, 2002 at 07:01:17AM +0100, Samuel Tardieu wrote:
On 13/01, [EMAIL PROTECTED] wrote:
| int i;
| for (i = 0; i -1; i += 1) {
| // ...
| if (terminal_condition)
| break;
| // ...
| }
[...]
| Moreover, i is never used. The loop could be reduced to
|
| while ((file = fts_read (dir)) != NULL) {
| // ...
| }
Those are not equivalent: the first loop, while ugly, has a guard against
endless looping if fts_read always returns non-NULL for any reason (not
knowing what fts_read contains, it is hard to tell whether there is a
reason for this or not).
A poor reason to write that code for several reasons.
Samuel wasn't defending the original code; he was just observing that
your suggested replacement was not functionally equivalent. Which it
wasn't.
1) It bounds the loop to the size of the integer /2 without
explicitly indicating so.
It's pretty clear if you understand how twos-complement arithmetic
works. Which is not to say it's the right thing to do, but I've seen
code that is much harder than this to understand.
2) If there is a problem, it silently hide the fact.
It's impossible to know that based on the code fragment you posted.
There's no indication of what happens after the loop, or even most of
the inside of the loop. I'm sure you're familiar with the rest of the
code, but the rest of us probably aren't.
3) It is non-deterministic. Should the loop fail to terminate
properly, the program will run for a relatively long time. 15
seconds on the PIII 700MHz I'm using.
The original code is deterministic (the loop will definitely exit sooner
or later); your suggested replacement is not, unless it is guaranteed
that fts_read will eventually return NULL.
While I don't agree that this is an appropriate method for
guaranteeing termination, the same result with clearer expression
would be
int loop_max = MAX_INT;
while ((file = fts_read (dir)) != NULL --loop_max) {
}
That's clearer, yes. It still sucks, unless there's a really good reason
to use MAX_INT as the limit. It's hard to say without knowing more about
the context of this tiny fragment of code, but I would guess that since
the loop condition is only used to guarantee eventual termination, the
limit could reasonably be set to a constant that is consistent across
platforms (whatever that constant might be -- 10^3, 10^6, 10^9,
whatever), rather than one that will vary by multiple orders of
magnitude depending on whether the target system uses 16-, 32-, or
64-bit ints.
I'd rather see the program fail to terminate so that I knew something
was awry instead of imposing an unforseen limitation on the program.
I'd rather see the program send a useful diagnostic message to stderr or
a log file, and either exit or properly recover from the error.
Craig
pgprIVUWj8rck.pgp
Description: PGP signature
Re: Please don't do this (code fragment)
Richard Kettlewell wrote: Even if you don't care about weird platforms, x -1 is a ridiculously obscure test in this context; to achieve the same effect it would be much clearer to make x unsigned and do x = (unsigned)INT_MAX. I find x = (unsigned) INT_MAX to be more obscure than the original. When I first glanced at it, I thought, That's dumb, x is ALWAYS less than or equal to INT_MAX by definition! Then my second thought was that the cast on the constant will cause x to also be converted to unsigned. In contrast, when I saw x -1, I immediately realized it was testing for wraparound. To achieve almost the same effect (probably close enough in this situation), it would be better to simply test for x INT_MAX -- it's clearer than either the original or your cast-dependent version, and only stops one iteration sooner. Since in this case the actual number of iterations was not the point (rather, merely that the loop should be guaranteed to terminate eventually), it ought to be sufficient. In any case, trying to find the best way to express a really bad idea is futile. Craig pgpUi7TYwuAJK.pgp Description: PGP signature
Re: Appropriate? mutt/mailx requires mail-transport-agent
Ilia Lobsanov wrote: Perhaps creating a new package, eg. 'mutt-reader' with no MTA dependency, could solve this problem. Would the only difference between mutt and mutt-reader be that one dependency? If so, then it would be better, I think, to simply change Depends: mail-transport-agent to Recommends: mail-transport-agent in the existing mutt package, and not create a new mutt-reader package. Craig
Re: An alarming trend (no it's not flaimbait.)
Karl M. Hegbloom wrote: If a package has gotten very stale, and nobody has taken up maintainence, isn't that a pretty good indication that nobody is using it anyhow? Is it? Is the average Debian user both able and willing to be a maintainer, and sufficiently aware of ongoing developments that he would both know that the package is out of date, and how to go about doing something about it (in terms of the process for taking over an abandoned package)? Craig
Re: An alarming trend (no it's not flaimbait.)
Darrell Rene Dupas wrote: no it isnt flame bait but it is newbie bait! Not if you read it correctly. Try again. there is an good discussion on this very topic at the following url http://www.tuxedo.org/~esr/writings/cathedral-bazaar/ I was talking about Debian policy and procedures, not general open-source practice, with which I am sufficiently familiar. Craig
Re: EURO and CENT signs in the console keymaps
Marco d'Itri wrote: On Jan 02, Paul Dwerryhouse [EMAIL PROTECTED] wrote: Maybe I'm missing something here, but it's actually quite annoying to Yes, you are. echo 'en_AU.ISO8859-15 ISO-8859-15' /etc/locale.gen locale-gen Possibly dumb question: does it matter that the above is not listed in /usr/share/doc/locales/SUPPORTED.gz? Will 'en_US.ISO8859-15 ISO-8859-15' also work? Craig
Re: 2.4.17 kernel compilation
Douglas Bates wrote: On a Debian 3.0 (testing) system updated to binutils 2.11.92.0.12.3-4, I get a failure when trying to compile a 2.4.17 kernel. The last part of the transcript is enclosed. ld -m elf_i386 -T /usr/src/linux-2.4.17/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o \ --start-group \ arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o drivers/video/video.o drivers/i2c/i2c.o \ net/network.o \ /usr/src/linux-2.4.17/arch/i386/lib/lib.a /usr/src/linux-2.4.17/lib/lib.a /usr/src/linux-2.4.17/arch/i386/lib/lib.a \ --end-group \ -o vmlinux drivers/sound/sounddrivers.o(.data+0x1d4): undefined reference to `local symbols in discarded section .text.exit' My .config file has CONFIG_SOUND=y CONFIG_SOUND_TRIDENT=y and all other CONFIG_SOUND_* unset. I can compile successfully if I unset all CONFIG_SOUND*. Suggestions? Downgrade to binutils 2.11.92.0.10-4. Newer versions may run into exactly this problem when compiling recent 2.4 kernels, depending on your kernel configuration. You can find binutils 2.11.92.0.10-4 in my archive of not-quite-current Debian unstable packages for i386 at http://crdic.ath.cx/debian . Access it with a web browser, not with dpkg; it's not a formal package repository, just a directory full of .debs. Craig
Re: VIM features
Caleb Shay wrote: However, as was pointed out below, vim is NOT the default vi when you install, Only true if you install nvi (or some other higher-precedence vi clone), which isn't required. (g)vim is the only vi-like editor I have installed. Craig
Re: Bug#126567: libreadline4 no longer respects directory separators in tab-completion
Simon Law wrote: On 27 Dec 2001, Bill Gribble wrote: On Thu, 2001-12-27 at 10:54, Simon Law wrote: Hrm... Could you list the output of `complete` and `set -o` for me? I have the same inputrc, and am unable to reproduce the problem. I am running libreadline4 4.2a-3 and bash 2.05a-3. ok. Please let me know if there's any other diagnostic info I can send. b.g. I've duplicated your inputrc, your complete, and your options. Nothing... However, I just saw this appear on debian-devel: [snipped] This leads me to suspect that you might have the same problem. Can you test to see if it works in the console or not? As well, can you test to see if you've been getting double tabs in your terminal? (Which terminal are you using? xterm?) If you just type TAB at an empty prompt, and you get Display all 1 possibilities? (y or n) then your terminal is passing tabs twice. On further analysis, I find that this only happens in gnome-terminal, not in xterm. That may help to narrow down the problem, and it does seem to exonerate libreadline4, does it not? Bill, does this fit what you're seeing? If you're a gnome-terminal user, can you try it in xterm to verify that the problem is unique to gnome-terminal? Craig
Re: Bug#126567: libreadline4 no longer respects directory separators in tab-completion
Jeff Lightfoot wrote: I think libzvt2 is the culprit. A downgrade of this package removed the 2 tabs problem. Downgrading to libzvt2_1.4.1.2-8 fixed the problem for me too. Craig
Re: Bug#126498: ITP: spambouncer -- a powerful user-based anti-spam solution
martin f krafft wrote: The SpamBouncer is a set of procmail recipes, or instructions, which search the headers and text of your incoming email for indications of spam. If spam is identified, there is a plethora of actions you can take, ranging from tagging, deletion, to complaining to upstream, or simulating mailer-daemon bounces. It's updated frequently so as to accomodate for spammers' volatility, and the package would include an easy way to deal with this. Please inform me if there is anything that speaks against me packaging this program. Maybe the answer is obvious to experienced package developers, but what is the easy way you plan to handle SpamBouncer's frequent updates? It's not an issue for unstable as long as you keep up with the changes, but how is this going to work in a stable release? A badly-outdated copy of SpamBouncer isn't terribly useful, and is even mildly dangerous if you have it configured to automatically send complaints. Craig
