Re: make -j in Debian packages
On Sun, Jun 25, 2006 at 09:07:40PM +0200, Wouter Verhelst wrote: > It's not a question of legislating; it's more a question of picking a > good option and writing the specification in policy. I fully agree with Wouter on this. Although the specification doesn't necessarily have to be in policy (it could be in dev-ref or the package tools documentation). But I don't think policy is neecssarily a bad place for it either. Beyond telling us what we can and cannot do, policy helps our users understand what they can and cannot expect. I think having a standardized option here to allow "-j X" to be used if the packaging supports it is an excellent idea. If someone wanted to write up an actual proposal and post it to the policy list, well, we could at least judge the proposal on its merits, and, if it were a good proposal, I would definitely support it. But I don't actually care enough to write a proposal myself. Unless you guys want to wait until I _happen_ to find enough free time :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote: > How about this rule of thumb: If you get stuff from the > primary NON DEBIAN distribution site, that is what you call > upstream. What someone unconnected to debian, not using debian > archives, downloads is what we also offer as upstream orig.tar.gz > files. I think it's more important that our users *know what they're getting* than that we try to enforce some sort of arbitrary distinction between "Debian" and "upstream". Clarity is why I chose "107.0pre108" as a version number. I don't see how it's that much different from our various cvs-snapshot packages, except that in my case, upstream wasn't using any sort of version control at the time I made the package - they just had a loose collection of patches and replacement files available on their website. > Pristine upstream means pristine upstream. Either get your > notes added to upstream website, or put them in the diffs. We don't require "pristine upstream". For example, we remove non-DFSG compliant portions. Many licenses require that changes be documented. So if we modify the upstream source to remove the non-DFSG portions, and _don't document that_ (because of a new policy rule that forbids any debian-authored portions of _orig tarballs), then we may be violating licenses. > Do not prevaricate to our suers by pretending that some material is > the same as they can get upstream, when it is not. I don't think I am - I think it's quite clear that 107.0pre108 is quite different from 107. > >Anyway, I was upstream project leader for most of the > > last year, up until about a week ago, when I stepped down in favor > > of someone more enthusiastic. But I'm still an upstream developer. > That is quite irrelevant. Actually, I agree. I think the fact that I can solve "the problem" by sticking the tarball I made on the upstream website at any moment I choose is, or should be, irrelevant. I think the tarball I created should be acceptable in any case. I think it's quite clear what I created, and I don't think there's any intent to confuse our users, and I think that should be sufficient. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
On Mon, Nov 01, 2004 at 01:47:02PM -0600, Manoj Srivastava wrote: > On Mon, 1 Nov 2004 10:39:44 -0800, Chris Waters <[EMAIL PROTECTED]> said: > > I'm not at all sure how this rule would apply, for example, to my > > own pilot-manager_1.107.0pre108.orig.tar.gz. Everything in there is > > from upstream's website, except my own note on how I put the pieces > > together. Do I need to remove that note? > I think so, yes. So in other words, I'm to be punished for my negligent maintaining of the upstream website? And all I need to do to satisfy your silly complaint is to scp my note to the website somewhere? Do I need to provide a link anywhere? How about if I simply add a link on the upstream website to the tarball on Debian's servers? -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Documentation on handling of orig.tar.gz files for Developer's Reference or for Debian Policy
On Mon, Nov 01, 2004 at 10:22:12AM -0600, Manoj Srivastava wrote: > On Mon, 01 Nov 2004 10:58:55 +0100, Frank Küster <[EMAIL PROTECTED]> > said: > > > , > >> A repackaged .orig.tar.gz [...] must not contain any file that does > >> not come from the upstream author(s), or whose contents has been > >> changed by you. > > ` > That sounds reasonable to me. oir.tar.gz is supposed to be > _upstream's_ sources. not a mix of stuff from upstream plus stuff > added later. That assumes an easily measurable definition of "upstream". And a sharp distinction between "upstream" and "DD" that may not actually exist (e.g. a DD may be a member of upstream). I'm not at all sure how this rule would apply, for example, to my own pilot-manager_1.107.0pre108.orig.tar.gz. Everything in there is from upstream's website, except my own note on how I put the pieces together. Do I need to remove that note? That seems like a really bad idea. Anyway, I was upstream project leader for most of the last year, up until about a week ago, when I stepped down in favor of someone more enthusiastic. But I'm still an upstream developer. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
On Mon, Oct 20, 2003 at 12:15:17AM -0500, Chris Cheney wrote: > What needs to happen to get this into policy? The usual - see /usr/share/doc/debian-policy/policy-process.html (or .txt.gz or .sgml.gz) for details. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Proposal - Free the Debian Open Use logo
On Mon, Oct 06, 2003 at 04:48:59PM +0100, MJ Ray wrote: > On 2003-10-06 15:46:01 +0100 Eric Sharkey <[EMAIL PROTECTED]> wrote: > >However, if you look at the logo as a component of Debian as a whole, > >and consider derived works of the logo to be derived works of Debian, > Surely the logo is a work on its own, as well as part of the greater > "Debian" work? A logo is a graphical equivalent of a name. If I have (and I do) a BSDish licensed program that pops up a banner saying (among other things) "Sun Microsystems", you have the right to remove that banner, but not the right to use the name "Sun Microsystems" for your own company. The use of a trademarked logo (whether Debian's or someone else's) can very reasonably follow the same rules. > >and invoke the exception of clause 4 to allow Debian to require > >derived works to carry a diffent name (and by extension, logo), > > then it fits even the letter of the DFSG. > This seems a large and dubious extension of reasoning to me. Seems like Eric hit the nail right on the head to me. I think if you look, you'll find a bunch of logos here and there in Debian (the Apache Foundation's logo, for example). I hope you're not going to argue that we need to purge all logos from our system! > >The spirit of the clause 4 exception is [...] > Can you give a reference that supports your interpretation? I am not > convinced that trademarking in this way is really the spirit of the > fourth guideline. I think we have two choices: either accept that a logo is equivalent to a name and move on, or declare that logos are magically different from names because they're graphical, and start a witch-hunt to purge all "evil" logos (like the apache logo) from Debian. I think you can probably guess which one *I* think is more sane. :) Do you want to advance an argument that would allow us to keep shipping the Apache logo (and perhaps others, such as the FSF's logo or Sun's logo), but not our own? I'll listen, but I'm not holding my breath. :) > Furthermore, I don't think it benefits anyone to waste scarce effort > on enforcing the requirement that all derived works of the Open Use > Logo to only be used for Debian references. Now you're changing the subject. You're also engaging in the logical fallacy, "Affirmation of the Consequent" http://www.infidels.org/news/atheism/logic.html#consequent We may want to change the license - that's a separate argument. The question before us, though, is, do we NEED to change the license because it violates the DFSG? And I think the answer has to be a resounding NO! Now, if you want to ask, should we change the logo license because it'll make our lives easier, I'll answer with a qualified maybe. I'll argue that a logo is equivalent to a name, and therefore it benefits us just as much to protect our logo as it does to protect our name. However, I'll admit that we could change the image from being a logo to being a random glyph we just *happen* to put on all of our webpages. But if it doesn't _mean_ "Debian", then I don't think we can really call it a logo any more. I think we have to start calling it "a random glyph we just happen to have on all of our web pages". But I don't really have a problem with that. What I do have a problem with is the argument that the presence of an actual logo (or other mark, e.g. an actual name), whether ours or someone else's, constitutes a violation of the DFSG. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: New virtual package: myspell-dictionary?
On Thu, Jul 31, 2003 at 07:44:06PM +0200, Rene Engelhard wrote:
> "Packages MUST NOT use virtual package names (except privately, amongst
> a cooperating group of packages) unless they have been agreed upon and
> appear in this list."
Note that the exception ("except privately...") is large enough to
drive a truck through! :)
But yeah, I have no problem with this name. It seems well-formed,
consistent with existing practice, and doesn't conflict with anything
else I'm aware of, and, AFAIK, those are really the only valid reasons
for objecting to a proposed virtual package name.
--
Chris Waters | Pneumonoultra-osis is too long
[EMAIL PROTECTED] | microscopicsilico-to fit into a single
or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Do not link GNOME1 apps with libpng3
On Thu, Jan 10, 2002 at 09:16:30PM -0500, Steve M. Robbins wrote: > Moreover, nobody has produced a compelling reason to make the > switch other than "libpng3 is newer than libpng2". I have one, but I won't present it, because I think there are more compelling reasons NOT to switch. I say this based on my experience upgrading an app from libpng1 to libpng2, and what I learned during that adventure: * libpng1 had a rather low-level API, with direct access to many internal structures. * libpng2 introduced a new API, but kept partial compatibility with the old API. * libpng3 was supposed to have dropped the old API. (I haven't checked for sure, but I can't imagine any reason they would have done otherwise.) This means that programs which worked with libpng2 may not compile with libpng3. (Or, in some circumstances, they might compile, but not work, which is what happened to me with the libpng2 transition.) > In the absence of such, leaving imlib1 linked with libpng2 seems to > me to be the wisest course of action, *especially* during a freeze. Very much so, yes. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
On Mon, May 07, 2001 at 10:57:37AM +0200, Adrian Bunk wrote: > but you can't file 1060 RC bugs at the beginning of a freeze. Why would you want to? File 1060 normal bugs before the freeze! (If you must file 1060 bugs at all -- I hope that's not a habit of yours.) If we want, we can adjust the severity at freeze time, when, hopefully, many of those bugs will have been closed. Or we can say, "there's just too many left open, realistically, we'll have to leave this for the next release." And you still seem to be implying that filing bugs fixes things. I may have to retract my earlier apology. Filing RC bugs _is_ asking for packages to be removed (especially this close to a freeze) unless you're planning to NMU if necessary, or know for a fact that someone else *will* fix the problem. Saying "oh, it'll just get fixed at the next bug-squashing party" is a seriously irresponsible attitude, IMO. For a problem affecting that many packages, I'd rather tackle policy and see about getting a change that would allow those packages to remain in the system for a while longer. > > Note that the next paragraph mentions filing bug reports if the > > package becomes "too much out of date". If any is too much, why > > bother to say "too much"? > You mustn't have to upgrade the Standards-Version field when your package > doesn't comply with a more recent policy -> a package that doesn't follow > FHS will never rech Standards-Version 3.0 . I'm having trouble parsing that. It sounds like you're saying that you think it means that if a change in policy does not affect your package, you *must* reupload to change Standards-Version immediately or it's an RC bug, but if a change in policy *does* affect your package, then you don't have to reupload, and it's not a bug at all? That would be insane. Policy is not the word of God. It's our feeble attempt to codify what we consider to be best practices. And it needs to be read in that light. If your interpretation of policy leads to an insane conclusion, it's time to ask for a clarification or correction, not to blindly engage in insane behavior. > > Bottom line, I think there remains a lot of work checking the subtle > > and not-so-obvious stuff in the FHS before we can confidently claim > > FHS compatibility (and even *begin* to work on actual compliance). > Reading the last three sentence I'm glad to hear that you volunteer to do > all this checks... I'm not the one who came here saying, "I want to suggest to finish the FHS transition." And I'm not the one who came up with a simple two-step plan which fails to achieve that. Yes, I have been working on the issue. No, I probably can't do it alone. If you don't want to help, that's fine. But when someone who has been studying the issue for the last year tells you that it's not so easy, maybe -- just maybe -- you should consider listening. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 06:29:05PM -0400, Joey Hess wrote: > Chris Waters wrote: > > > - A change in the policy to remove the obsolete /usr/doc symlinks. > > This is supposed to happen once enough packages make the transition. > No, it is supposed to happen one release _after_ a release in which > all the packages have made the transition. So sarge at the earliest, > not woody. Right. Even better point. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 09:27:59PM +0200, Adrian Bunk wrote: > On Sun, 6 May 2001, Chris Waters wrote: > > Didn't we already have this discussion? The Standards-Version field > > is not a reliable indication of much of anything. I strongly object > Policy says: "Policy says" doesn't make the packages comply. And you can file all the bugs reports you want, but that doesn't magically fix the packages. And until they're fixed, you can't use them as a reliable indicator of FHS compatibility. QED. We have many packages with old Standards-Versions which actually comply with newer standards and *are* FHS compatible, and we have packages with newer Standards-Versions that are NOT FHS compatible. I think that if you really want to focus on FHS compatibility, you're better off ignoring the Standards-Version issues for now. Its just another can of worms. Picking the minimum Standards-Version for release is something we normally do at freeze time. > In the source package's `Standards-Version' control field, you must > specify the most recent version number of this policy document with > which your package complies. The current version number is 3.5.4.0. You're misinterpreting this. It does not mean that every package must be reuploaded every time policy changes. "Most recent" should be checked at the time you create the source package, not rechecked daily. Note that the next paragraph mentions filing bug reports if the package becomes "too much out of date". If any is too much, why bother to say "too much"? > > to removing packages because of what amount to cosmetic issues, and an > Where did I say that I want to remove the packages??? > I said that I want to send bug reports. RC bugs mean the package must be removed from the next release if it's not fixed. Unless you can guarantee that the bugs will be fixed (i.e., you're volunteering to fix them yourself), you _are_ asking for package to be removed when you file RC bugs. Anyway, I apologize for a reminder I'm sure you don't need. It's just a habit of mine, please forgive me. Bottom line, I think there remains a lot of work checking the subtle and not-so-obvious stuff in the FHS before we can confidently claim FHS compatibility (and even *begin* to work on actual compliance). The easy stuff, as your evidence shows, we're actually quite close on. It's the harder stuff, like /var/lib/games (which Kamion was going to investigate) and the random hard-to-identify files that need to move from /usr/lib to /usr/share that needs the most attention. So, anyway, that's a nice list of packages you made, and I think it's probably very useful -- all those packages should inspected -- I just don't think it's very useful for the purpose you intended. And I think mass filings of RC bugs would be premature at best. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
menu and FHS (was Re: Finishing the FHS transition)
On Sun, May 06, 2001 at 09:13:26PM +0200, Arthur Korn wrote: > /usr/lib/menu is not shareable Yes, it is. There's a reason why each entry starts: ?package() Anyway, that's not really relevent -- /usr/share is for architecture-independent static files. The FHS doesn't grant exceptions for files that would cause breakage if they actually were shared between different machines. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: Finishing the FHS transition
On Sun, May 06, 2001 at 07:31:43PM +0200, Adrian Bunk wrote: > I want to suggest to finish the FHS transition. This includes the > following steps: > - Packages with Standards-Version >= 3.0 must follow the FHS. Didn't we already have this discussion? The Standards-Version field is not a reliable indication of much of anything. I strongly object to removing packages because of what amount to cosmetic issues, and an incorrect Standards-Version (one that doesn't reflect the version of policy that the package _actually_ complies with) is really no more than a cosmetic issue (no software actually uses that field). I only have a few of the listed packages installed on my system, but most of the ones I checked did indeed use /usr/share/doc (and /usr/share/man, in those cases where man pages were present). I suspect that this is due to the use of debhelper, but anyway Checking for FHS violations should be done by checking for FHS violations, not by checking an unreliable and all-but-meaningless field in some configuration file. (Plus, as a side issue, by a strict reading of the FHS, we should be using /usr/share/menu rather than /usr/lib/menu, which means RC bugs against nearly every package in the system!) :-) > - A change in the policy to remove the obsolete /usr/doc symlinks. This is supposed to happen once enough packages make the transition. Now, if we're really down to 253 packages that use /usr/doc (with no symlink), then maybe it's time. But, unfortunately, that number, 253, measures *claimed* compliance, not actual compliance. Now, my poking around suggests that there are actually far *fewer* than 253 packages still using /usr/doc. And if that's true, then it's definitely time to remove the symlinks. But it might be nice to have some hard facts, rather than speculation based on unreliable claims made by inattentive package maintainers. > Ben Gertzfield ([EMAIL PROTECTED]) wmifs > Eric Leblanc ([EMAIL PROTECTED])groovycd > Eric Leblanc ([EMAIL PROTECTED])zangband > Gene McCulley ([EMAIL PROTECTED]) xcopilot > Javier Fernandez-Sanguino Pen a ([EMAIL PROTECTED]) spellcast > Luis Francisco Gonzalez ([EMAIL PROTECTED]) xgammon > Rob Browning ([EMAIL PROTECTED]) emacs20 > Robert Woodcock ([EMAIL PROTECTED]) cd-discid > Takuo KITAME ([EMAIL PROTECTED]) bbdb > Vincent Renardias ([EMAIL PROTECTED]) gdb > Vincent Renardias ([EMAIL PROTECTED]) gnumeric > Wichert Akkerman ([EMAIL PROTECTED]) sed I inspected these packages. Only emacs20 lacked the /usr/share/doc directory. If that ratio holds true (which I doubt), then we've only got 21 packages left to transition! :-) cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: ITH (Intent To Hijack) pilot-manager
On Wed, May 02, 2001 at 02:07:29PM -0700, Darren/Torin/Who Ever... wrote: > Feel free to adopt the pilot-manager package... Cool, then I guess it doesn't count as hijacking any more. Hi, Darren, glad to know you're still around and in one piece. I was starting to get a little worried. cheers -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Re: ITH (Intent To Hijack) pilot-manager
On Wed, May 02, 2001 at 12:36:45PM +0200, Adrian Bunk wrote: > On Wed, 2 May 2001, Chris Waters wrote: > > Just wanted to let people know that I'm going to hijack the > > pilot-manager package. The current maintainer seems to be completely > > MIA; he hasn't uploaded a version in over a year. I emailed him and > He seems to be MIA: How often did you try to contact him and how long ago? > (always remember that most of us work for Debian in our spare time). I first sent him an inquiry back when he was still the perl maintainer. After he turned perl over to Brendan, I figured he'd be able to concentrate on his other packages more, but it's been five months, and there's been no activity with pilot-manager at all, despite a long list of bugs. I sent him another message when I NMU'd at the last bug-fix party and still haven't heard back. I told him then that unless he objected, I would hijack the package, but that if I did that, he could have it back anytime for the asking. > > got no response. I use the package, and I did the most recent NMU. > > I'm cc'ing him this message -- Darren, you can have it back for the > > asking, but for now, it's mine, mine, all mine! Mwuah-ha-ha-ha-ha!! > Haeh? This sounds a bit as if you are kidding... Trying to inject a bit of humor -- I'm not real comfortable with this, but I'm also not comfortable making the drastic changes to pilot-manager that are needed at this point, as an NMU. The package needs some real surgery, and I doubt if Darren wants to be deluged with reports about *my* bugs, which is the most likely outcome if I do all the things that need doing. I'm trying to follow the golden rule here. If it were my package, and I'd been neglecting it this badly, this is how I'd prefer it to be handled -- in particular, with the offer to return it at any time. But maybe that's just me. If you guys really think I'm stepping over the line here, then I'll retract my ITH and just do massive patching as an NMU. But again, if it were me, I'd rather have a package hijacked than have a whole bunch of major patches suddenly dumped in my lap while I'm away. Especially if the hijacker used and cared about the package. > > p.s. I wonder if we shouldn't add ITH as an official category in > > WNPP. It's something that's probably going to come up more and more > > as more developers become MIA over time. > Martin usually marks packages of MIA maintainers as orphaned. I > think it's better if a few persons take care of this instead of many > more people sending ITHs. Ok. I'm just worried about growing pains. Seems like a lot of responsibility for one person to try to track all the packages and their maintainers. But if he's happy and you're happy, then I'm happy. cheers (Note: since this is on d-devel, please make sure replies go to me, as I'm not subscribed -- though I do browse the archives semi-regularly.) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
ITH (Intent To Hijack) pilot-manager
Just wanted to let people know that I'm going to hijack the pilot-manager package. The current maintainer seems to be completely MIA; he hasn't uploaded a version in over a year. I emailed him and got no response. I use the package, and I did the most recent NMU. I'm cc'ing him this message -- Darren, you can have it back for the asking, but for now, it's mine, mine, all mine! Mwuah-ha-ha-ha-ha!! Expect an upload as soon as I sort through the bug list a bit. cheers p.s. I wonder if we shouldn't add ITH as an official category in WNPP. It's something that's probably going to come up more and more as more developers become MIA over time. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku
Intent to Package: gtkpool
gtkpool is a simple simulation of the game of pool (i.e. similar to billiards and snooker), written and copyright 1999 by Jacques Fortier, licensed under the GPL. Because Debian *always* needs more games. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Intent to package: tuxeyes
William Ono <[EMAIL PROTECTED]> writes: > tuXeyes is a X toy that works like xeyes. It is licensed under the GPL > but uses Qt, so it will go into contrib. Um, no, if it's licensed under the GPL, but links to Qt, then it suffers under the same self-cancelling license issues that KDE does. And we can't distribute it at all. It needs to be licensed like Lyx (GPL with exception for Qt). -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: An 'ae' testimony
"Steve Lamb" <[EMAIL PROTECTED]> writes: > If ee does this (I dunno, but my friend swears by it), then so be it, > install it, move on. Again, ae is *half* the size of ee, and ee doesn't even offer the option of vi emulation. If we can't fix some of the more noticable problems of ae, and *still* come in smaller than ee, there's something wrong with us. I'd volunteer, but I've never had a problem with ae. And I don't know vi well enough to address people's complaints with ae's emulation. But I suppose I could be persuaded to look into it if no one else will. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: An 'ae' testimony
Joey Hess <[EMAIL PROTECTED]> writes: > All that's necessary for a functional jed. Not that it matters since > ee is clearly the right choice. I think ee is a good choice, I'm not sure it's the right choice, I'm not sure there is a right choice. If we put a vi on, we get a (probably deserved) reputation for newbie hostility. If we don't, we alienate all the experienced people, who expect vi to be a basic tool available everywhere. I'm not sure there's a way to win this. Something like ae, but which worked better and which had a better vi-alike mode would be the optimal choice, probably, but I'm not aware of such a beast. Anyone who really, truly hates ae should write us a better one. We need simple "four-banger" editing, and we need a vi-like mode. And it should be somewhere between ae and ee in size. What if we just *fix* ae's most noticable problems? Surely we can do that without doubling its size (ee is more than twice as large). This is an *emergency* editor we're talking about here, not something you'll end up using day after day. It really doesn't need to be perfect, just good enough. Let's not loose sight of the goal here. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: An 'ae' testimony
Craig Sanders <[EMAIL PROTECTED]> writes: > someone (miquel, perhaps) made elvis-tiny a year or two back, and it fit > on the boot disk. would be nice if it could be made to fit again. elvis > isn't as good as vim, but it's much better than ae. Better for the experts who know vi, not as good for the novices who have no idea what vi is or how to use it. Vi is a nightmare if you're used to programs like DOS edit or notepad. I do agree that ae should give some sort of warning that it's *not* true vi, though.
Re: evan leibovitch and the LPI certification tests
Manoj Srivastava <[EMAIL PROTECTED]> writes: > I can't speak for others, but *I* do it cause it pleases my > muse. Getting Debian out to the great unwashed masses rouses little > but mild curiosity in me, and certainly not eough to warrant the > amount of effort I put into my packages. Hear hear! I also like the idea of sharing my work with other *developers* so that *we* all have a better system. I'm not interested in cramming my work down anyone's throat, however. Anyone who *wants* to use it should feel free, but aside from that > Market share and World domination are not goals I strive to > achieve. Market share, no. But world domination? C'mon, admit it would be fun to have the downtrodden of the world grovelling at your feet. Dogbert has the right attitude. Oh wait, you mean world domination for Debian? Never mind. I don't care about the rest of you bums, I want those downtrodden grovelling at *my* feet! :-) -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: [ITP/mostly packaged] hftpd
Adrian Bridgett <[EMAIL PROTECTED]> writes: > On Tue, May 18, 1999 at 05:09:27PM -0400, Michael Stone wrote: > [snip] > > > We really should have a policy for things like this. How about adding > > > another Provides: to kernel images (built by the excellent make-kpkg): > > Because too many people don't use debian kernel images. > How about only making dependant packages "suggest" the appropriate kernel > version? That gets around this problem. Or make it conflict with inappropriate versions? (Actually, this would work better if kernel-image-2.0.xx provided the virtual package kernel-image-2.0, etc., but whatever.) > Personally I'm fairly inclined to making it a recommends after all - anyone > who doesn't use make-kpkg deserves what they get. I agree, let 'em roll their own or use equivs if they don't want to use the packaging system. The argument that people can compile libraries by hand doesn't hold water when it comes to library dependencies, why should it hold for kernel dependencies? It's not like make-kpkg is difficult to use, or limiting in any way. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Time to rewrite dpkg IN IDL! :)
Hamish Moffatt <[EMAIL PROTECTED]> writes: > On Thu, May 20, 1999 at 08:25:17PM +1000, Daniel James Patterson wrote: > > On Thu, May 20, 1999 at 02:50:38AM -0700, Chris Waters wrote: > > > I think an interesting approach would be to use CORBA. Make dpkg into > > > a networkable server for polymorphic package objects! G'wan, I dare > > > ya! :-) > > I don't see why not. > How about "it's complete overkill"? Sure, and without complete overkill, how will we take full advantage of the second-system effect? :-) > I don't see anything in the Debian packaging system which fits > OO very well at all. We have just one type of package; there are no > special sub-types, for example. Then you're not looking very carefully. "It's overkill" may turn out to be a valid objection, but "it couldn't benefit from OO" is, IMO, completely false. Elisp packages spring to mind. We *do* have different classes of package; we just force them all into the same mold. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Time to rewrite dpkg IN IDL! :)
Aaron Van Couwenberghe <[EMAIL PROTECTED]> writes: > I have grown increasingly aware of FUD of this type about C++ and OO > languages. OO is designed to *increase* interoperability, flexibility, and > extensibility -- definately not the other way around. OO isn't limited to C++, and C++ isn't limited to OO. The two overlap, but they are far from identical. Some people dislike C++ because it's not OO *enough*! C is generally far more interoperable with other languages (even other OO languages) than C++ is. C++ is great if you're *only* using C++, but if you're using a different language, with a different object model (or none), you're in trouble. References to alien, polymorphic, multiply-inherited objects are scary, especially when much of their structure and behavior is officially defined as "implementation defined" by the language standard. But C has its own problems, not least of which is that it's a primitive procedural language with no built-in OO features to speak of. And with emphasis on "primitive". I think an interesting approach would be to use CORBA. Make dpkg into a networkable server for polymorphic package objects! G'wan, I dare ya! :-) -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: [ITP/mostly packaged] hftpd
Michael Stone <[EMAIL PROTECTED]> writes: > > We really should have a policy for things like this. How about adding > > another Provides: to kernel images (built by the excellent make-kpkg): > Because too many people don't use debian kernel images. If people don't use the tools, then they don't get the benefits of the tools, which is hardly our fault. This is like saying that we shouldn't have dependencies on libgtk, because some people might compile their own, without using dpkg-source. As long as it works with make-kpkg, and doesn't require one of the *official* kernel images, I'm all for it; there's no valid excuses for not using make-kpkg that I've ever seen. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: (FINISH) Correct non-US solution
Jonathan Walther <[EMAIL PROTECTED]> writes: > No. The scheme makes us less liable than we already are, since it shows > that we are "trying". Excuse me? Are you a lawyer, or have you consulted with competent legal advisors in order to arrive at this *theory*? I suspect not, and I suspect that you are sadly mistaken. (But IANAL.) It could put us in the position of *seeming* to be offering legal advice, and could open us up to accusations of misrepresentation and practicing law without a license. I find it touching that you have such an innocent view of the world's legal systems, but in many cases, "trying" is worse than doing nothing. It's a sad but true fact that if you try and fail to save someone's life (and maybe even if you succeed), the family (or the state) may sue you for practicing medicine without a license. (Esp. if you happen to be in the US, where lawsuits are a Way Of Life.) I'm not saying we shouldn't do this, period, I'm saying we shouldn't do this without legal consultation first. Intuition and the Law are *often* directly opposed, so it would be foolish for us to be guided by pure intuition here. Ignorance of the law is not a valid legal excuse for doing something. Being earnest, having puppy-eyes, and protesting, "I was only trying to help," doesn't cut the mustard. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: new file nmu for testing
Shaleh <[EMAIL PROTECTED]> writes: > properly shows stripped/unstripped (comments from non-x86 people > here please and non-glibc2.1) Did you contact upstream about that flakey "fix" they made that didn't work? See what on earth that was all about? -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: fixing the wnpp was ITP rx(v)p
[EMAIL PROTECTED] writes: > The wnpp has become exceptionally incorrect and out of date. > What can we do as a group to fix this? One suggestion I just tossed out on IRC is to use the BTS -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Release Plans (1999-05-10)
Richard Braakman <[EMAIL PROTECTED]> writes: > Do you mean make GNOME 1.0 available for slink, separately? It's far > too large a change to be part of a stable revision. The current plan, as I understand it, is to build GNOME 1.0 debs for slink, and turn them over to the GNOME folks for distribution from ftp.gnome.org. This was, in fact, one of the original motivations for setting up the slink staging area. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Here's a diff to my .xsession (was Re: Here's my .xsession)
[EMAIL PROTECTED] writes: > Hi, > already found a problem: comment lines in /etc/X11/window-managers that > match the chosen favorite window manager cause the script to fail weirdly... > Problem reported by [EMAIL PROTECTED] > this patch filters comment lines first. (Note to Branden: you might want > to use this logic, or something like it, in the global Xsession.) Seems to me like it might be easier if the existing global Xsession simply had an option to check through ~/.window-managers if one exists, and only check /etc/X11/window-managers if there is no ~/.window-managers, or if no valid executables are found there. This would require less code, and would provide the user with more flexibility (rather than just *a* favorite, wmanagers could be ranked, as they are system-wide). This can be done in a .Xsession file too (untested code follows): wm= if [ -e ~/.window-managers ]; then for i in $(sed 's/^#.*//' ~/.window-managers) ; do if [ -x $i ]; then wm=$i; break fi done fi if [ -z "$wm" && -e /etc/X11/window-managers ]; then for i in $(sed 's/^#.*//' /etc/X11/window-managers) ; do if [ -x $i ]; then wm=$i; break fi done fi if [ -z "$wm" ]; then panic!!! # this line may need some work :-) fi exec $wm -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Install-time byte-compiling: Why bother?
<[EMAIL PROTECTED]> writes: > I suggest, therefore, that the install-time byte-compilation of elisp > files be either eliminated completely, or turned into an option, with > the default set to "off". I *strongly* oppose eliminating it, and I'm not real big on the idea of making the default be "off". Installing new packages takes a while, I don't mind a few extra moments there. I *do* mind run-time delays, even if they're small, and only once per session (and they're not if you unload features to save RAM). If there's a bug in the install, it should be reported and fixed, but I have yet to see one. That said, I'm perfectly happy to see it be optional, as long as it doesn't result in more install-time questions. But the *default* should be whatever is best for the novice running stable. Which is "on", since a novice may not be able to figure out how to byte-compile the package himself. And stable *better* not have problems in the install, so problems in the install aren't sufficient justification for a default of "off". If you really want something to happen, though, post a proposal to -policy. I *will* support the idea of making byte-compilation optional, even if I don't support eliminating it or defaulting to "off". -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Debian coding style?
[EMAIL PROTECTED] (Zygo Blaxell) writes: > This really just defers answering the question, though. > "Why 78 characters per line of code?" > "Because the laser printer wants that." I tend to think of it more like email -- "Why 72 chars per line?" "To leave room for quoting in 80 columns." "Why 80 columns?" "Because a lot of people only use 80 columns, some only *can* use 80 columns, others just prefer not to use any other width." > The real point is that decisions about the sizes of functions in a > program should not be controlled by accidents of history. Mild disagreement here. Like tabs=8, the 80-column limit is a good lowest-common-denominator rule that *will* work for everyone, where other choices may not. Yes, it's a historical accident, maybe, but it's a historical accident that is very firmly entrenched still, and you violate it at your peril. IOW, you really have stumbled across one of our unwritten rules here. Yes, I can change my tab size, but 8 is a standard, and I'll annoy a lot of people if I use something else. Yes I can change my editor's width, but 80 columns is a standard, and I'll annoy a lot of people if I use something else. So, I don't, and then I tend to get annoyed myself at people who do. The hard metric of 40-50 lines/function, on the other hand, is just plain silly. Write functions that perform one task, and only one task, and keep the line length under 80 columns, but use as many lines as you need. If the function really performs one-and-only-one function, it will rarely be that long in any case. I suspect that you'll be hard pressed to find any "open source" code that doesn't adhere to the 80 column rule. And if you do find some, you'll probably find an "open source" author who gets a lot of flames from his users. :-) BTW, I loved your analysis of some of the other Corel Guidelines. I nearly fell off my chair at the "passive voice should be avoided" comment! :-) cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: gnuserv/gnuclient problem
Steve Dunham wrote: > > ii xemacs20-bin20.4-13Editor and kitchen sink > > ii xemacs20-nomule 20.4-13Editor and kitchen sink > ^ > The problem only shows up with the mule versions of xemacs. Nope, because I only have the nomule version installed, and I have the same problem. Gnuclient causes xemacs to generate an error, and then exits immediately. Running slink. ~ $ dpkg --list 'xemacs*' | grep '^[ir]' ii xemacs20-bin20.4-13Editor and kitchen sink ii xemacs20-nomule 20.4-13Editor and kitchen sink ii xemacs20-suppor 20.4-13Editor and kitchen sink ~ $ ~ $ xemacs20 -batch -eval "(and (require 'gnuserv) (print gnuserv-program))" Loading [...stuff...] Symbol's value as variable is void: gnuserv-program XEmacs exiting. This may be a useful clue: from inside xemacs, I can determine that gnuserv-program's plist is (saved-value ((concat exec-directory "/gnuserv"))). When I evaluate that, it says that saved-value's function definition is void. If I execute (concat exec-directory "/gnuserv"), it looks fine. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Call for mascot! :-)
While I'm on the topic of the logo, it occurred to me that it might be nice to choose a mascot for the Debian project. Some sort of beast that we can use in the logo and in other Debian-related images. Much as Linux has its penguin, BSD has its devil, and GNU has its, erm, gnu. Debian should have its own mascot, IMO, separate from any of these. This is just an idea, and I won't be offended if it's rejected. Anyway, I just thought that if we picked a mascot, then we could mention it in the rules for the proposed GIMP contest for a new Debian logo. I brought this up on IRC, and got the following suggestions: 1. Dragon (well-liked choice on IRC) 2. Octopus (my own suggestion) 3. Monkey 4. Ant 5. Bee Personally, I think octopi are really cute, they're smart (for invertebrae), and I kind of like the symbolism of many arms working together as part of a whole, but perhaps I'm a little crazy. :-) -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Back to the logo license (semi-formal proposal)
We have free software guidelines, we have a logo. There may be room for improvement in both, but we do have them. What we lack is a license for the logo. This may be a minor issue, but I believe that it's rather critical right now. It has been suggested that we trademark the logo. This is a good idea, however, it requires time, money, and paperwork. Plus, if we want to change the logo later, we'll need to spend *more* time and money to get a new trademark for the new logo. Thus, I propose that we instead use the following license, which can be applied to any of our logos: DEBIAN LOGO LICENSE The Debian logo may be used AS IF it were a trademark of the Debian Project. It may be used freely within any software that is included in a Debian system. Outside of the Debian project, it may be used to refer to the Debian project. Short, sweet, and to the point. Feedback welcomed. Seconds welcomed. I would really like to see if we can avoid drowning in legalese for once. :-) cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
DFSG: list restrictions, not freedoms
Rather than attempt to list all the freedoms that Debian guarantees, why
not list the *restrictions* on freedom that we do allow, and say that
any other restrictions violate our guidelines.
IOW, instead of saying, "we allow this, we forbid this, we allow
this...", simply say, "we forbid all restrictions except these"
No need to mention, e.g., discrimination; if it's not a listed
restriction, it's an unacceptable restriction.
A preliminary outline of acceptable restrictions:
1. Credit where credit is due. (copyright notices, etc.)
2. Continued freedom ((L)GPL, MPL, QPL, etc.).
3. Identity (artistic)
4. "Non-contaminating" non-commercialism (artistic)
5. Integrity ("patch-clause" -- deprecated)
These obviously need to be fleshed out and pinned down a little. Number
one needs to be chopped off somewhere around (either including or
excluding) the terms of the BSD license. And we can drop the patch
clause if desired. But I think this approach of listing acceptable
restrictions on our freedoms is probably the most clear. I think it
might help make the DFSG brief and to-the-point.
Comments?
--
Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the
or[EMAIL PROTECTED] | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Re: Debian logo & its license
Wichert Akkerman wrote: > I propose that we vote on accepting both the logo and the current > license. I very much dislike the current license. I'm a debian developer, I'd like to put the debian logo on my home page, but I do *not* necessarily want to devote half or more of my home page to debian. I'd rather have pointers to the debian web site, and let debian speak for itself. Current (expired) license forbids this. I've previously raised issues about using the logo inside of packages too -- this one may be addressed by the current license, but it's certainly not clear. The logo should be a logo, it should be used to refer to or to advertise debian. It should *mean* debian. The current license isn't even *close* to filling this goal, imo. I asked on IRC about the logo license, and was basically told, "nobody cares, if we ignore the problem it will go away." A deplorable attitude, IMO, license issues are at the core of what debian is all about. The thread on -legal ends with a comment that we should take this up after revising the dfsg. I disagree *strongly*. We have free software guidelines -- some of us even feel that the ones we have are much better than any of the proposals so far. We *don't* have a reasonable license for the logo. It may not be quite as critical, but I feel it's more urgent at the moment. Debian is a free project to distribute a free OS. It should have a free logo. FREE THE LOGO!! FREE THE LOGO!! :-) cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: agreeing with the DFSG (was Re: non-free --> non-dfsg)
Joey Hess wrote: > > I think it's not necessary that a developer agree with the DFSG. It > should be enough that they indicate they understand it and will abide > by it in what they produce for debian. Yes, but OTOH, it's a little hard to fathom why someone would *want* to work on Debian if they didn't agree with at least the basic outlines of the DFSG and the Social Contract.... cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
libpam, cracklib, and slink (was Re: Release-critical...)
Wichert Akkerman wrote: > Previously Jean Pierre LeJacq wrote: > > There's no reason for this to be release-critical. The system works > > fine except for an annoying email message sent to root every day. > It's *highly* annoying I have to say, and is very likely to cause lots > of people to wonder where the number are coming from. Actually, I believe that the real problem is that libpam0g depends on cracklib. Surely that's not right? Cracklib has priority extra. At the moment, everyone who installs ppp-pam (like me) will be forced to install cracklib, and suffer with daily emails to root. We need to fix libpam0g. Unfortunately, the maintainer seems to be inactive, and we're dependent on NMUs. (Ray, that's you!) I think that there should be a release critical bug here, but I think it should be #30862: libpam0g depends on cracklib2. Unless someone objects strongly, I'd like to bump #30862 up to important. This is a pretty visible problem IMO. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or[EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Intent to package gnome-hack (pending gnome-gtkmm)
Martin Schulze wrote: > Just in case we misunderstand each other, you're not listed in my > list of new maintainers. Thus the new-maintainer have not yet > received your application. No -- maybe I'm missing something, but the Developer's Reference seems to say that I should subscribe and lurk in this list for a while (done), then post my intentions to work on something (done), then register as a developer. If I'm misreading that, then I apologize, and that last post should be considered an *informal* intent to package, pending my registration. The main reason my application hasn't arrived is that I still need to find someone to sign my key, but I live in Silicon Valley, so I expect that won't be difficult. I've already got feelers out. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: gnome and gtk--
Marcus Brinkmann wrote: > I'm working on it. But even if I get it to compile with Debian > sources, we still would need another soname for this. I was going to respond to your earlier message(s), but I see you're ahead of me. Ok, for now, I'm just going to assume that you will work this all out at some point in the not-too-distant future. And in the meantime, I'll try hacking something up as you suggest, so that I can get started on my package. If I get really stuck, I may scream for help. > run > dpkg-buildpackage -B -us -uc > in the source directory. This should compile you gtkmm packages with > gnome support. But you also need to edit the debian/control and > remove the dependency on libgtk-dev if you don't want to use source > depends. Note that this completely messes up binaries that are linked > to gtkmm, because the soname doesn't differ. But maybe you don't care I hope I don't care; I'll probably also rename the package and make it conflict with gtkmm just as a quick hack so I don't break my own system. I'll be anxiously awaiting a more official and reliable solution, however. :-) cheers -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Intent to package gnome-hack (pending gnome-gtkmm)
Ben Gertzfield wrote: > I'm the nethack maintainer. If you wish to package up and maintain > gnomehack, I'd be perfectly happy, so long as you use the same sort > of debian/* files that I use in the nethack package, and if you find > bugs in them you let me know :) Ok, then, pending 1) some resolution to the gnome-gtkmm issue, and 2) my acceptance as a maintainer, I'll call this a formal announcement of my intent-to-package. And yes, I'll be more than happy to follow your lead, Ben. Believe me! :-) Official announcement: I intend to package gnome-hack, a gnome-ized version of the classic game Nethack, published under the, er, Nethack license. BTW, while I'm at it, has the Nethack license been hashed out? It's obviously designed to look like a stripped-down GPL, but I'm a little worried about some of the anti-"commercial" clauses, especially since the term "commercial" is not really defined. I've read it twice, and I've come to three different opinions about whether it should be in non-free or not. But the license is long enough that I'd rather not post it if it's already been discussed. In any case, I won't be able to release this until Marcus sorts out the various flavors of gtk--, because I'll need one with gnome support. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: gnome and gtk--
Havoc Pennington wrote: > On Sun, 11 Oct 1998, Chris Waters wrote: > > I think it would really be nice to get a gnome-supporting version > > of gtk-- in before the slink freeze. Is anyone working on this? > Not really possible without hacking Gtk-- (which can be done, but > it's work). Gtk-- can be built with either Gtk 1.0 or Gtk 1.1, if you > install both things would get, uh, confused. 'Bout what I figured, but wouldn't it be possible to produce two versions which conflict? Not a perfect solution, but it would make it possible for people like me who want to work on gnome-related gtk-- stuff to do so. The conflicts could be cleaned up when someone had the time to hack on it (presumably post-slink). Just a thought -- I'm about to try building my own personal gnome-gtkmm package (which will conflict with gtkmm), but I don't yet have any experience at packaging libraries, so I'm a little scared. I doubt if I'll be able to finish in time for the freeze. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: intent to remove libglide from non-free
James A. Treacy wrote: > A number of people would like to see a 3dfx package of mesa. This can > not be done unless there is a legal package of glide (under the > current license I can't even get the libs since I don't own a 3dfx > card). Any reason, aside from the lack of volunteers, why we can't do what we do with netscape/staroffice/etc.? Even if we can't distribute it, can't we have a loader package? (No, I'm not volunteering, I don't own a 3dfx card either.) -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
gnome and gtk--
Perhaps I'm missing something, but I don't see any way of using gtk-- with gnome at the moment. I was going to try packaging gnome-hack (for my own use -- I'd want to check with the nethack maintainer before doing anything more with it), but it seems to require gtk-- and gtk1.1, and the two don't seem to work together at this point. I think it would really be nice to get a gnome-supporting version of gtk-- in before the slink freeze. Is anyone working on this? -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: Debian logo
> Ideally, we need a version of the logo that can be reproduced in one > or two colors. That way it can go directly on a CD or be printed > inexpensively. Full-color printing can be rather expensive. And it should scale well, from fairly large to quite small. This means lines and *simple* curves, and probably solid shapes rather than outlines. Red Hat did it right, Debian didn't, quite. (A rare exception to the usual rule.:) In any case, even if we do decide to make a better *logo*, we can keep ol' blue-eyes around as the official Debian mascot or something (in case people are worried that this is all some plot to get rid of him). -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
KDE hurts Qt (was Re: LICENSES)
> Now, I won't install Qt even for the parts of KDE I like. This is the really sad part about this whole mess. Qt is a nice library. Non-free, but not everything has to be free. But because of the refusal of the KDE developers to FIX THE KDE LICENSE PROBLEMS, a lot of people are being turned off of Qt! Qt doesn't deserve this, and I think the KDE team should: 1) fix their license problems, and 2) apologize to Trolltech. To the KDE team: it doesn't matter whether you believe that the GPL is compatible with Qt. The GPL may be open to interpretation, but that's not relevant -- the biggest problem with the KDE license is the existence of the controversy! Which isn't going to go away unless you persuade RMS to accept your interpretation (good luck!), or you add an exception clause to the license, or switch to a GPL-compatible library. Until one of those three things happens, KDE is doing Troll a disservice. (Fourth option: get a ruling from a judge in every country KDE is used in.) If I were building a linux distribution I would not include KDE even *if* I were willing to admit that your interpretation of the GPL *might* be right -- which I am. I'd want to be sure! (Unless I had deep enough pockets to feel that the risk was worth it.) But then I live in the USA, where people sue at the drop of a hat. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: LICENSES [was: Re: Have you seen this?]
Martin Konold <[EMAIL PROTECTED]> writes: > Will Debian remove Motif linked XEmacs from their ftp > server? I don't believe that Debian *has* a Motif-linked XEmacs on their ftp server, but if they do, then all it should take to get it removed is to file a bug report. That's what happened to KDE. Violations of policy (and law) are considered bugs. Some individual may have had a grudge against KDE which motivated them to file the bug report against KDE, but that doesn't mean that Debian is part of some anti-KDE conspiracy. > Will Debian remove LyX from their ftp server? According to > several Debian developers Xforms is not a DFSG compatible > library. LyX is in contrib. I don't have it installed, but if it is licensed under the GPL, then you're probably right, and you're free to file a bug report against it. If you don't want to do so, then I'll check it out and file the bug report myself if needed. If you (or I) file a bug report against LyX and it *doesn't* get removed (or recompiled with a more appropriate library if possible), *then* you'll have a reason to complain that Debian is playing favorites. As it is, Debian is run by volunteers, who don't always have time to track down every nit in the system, which is why the bug reporting system exists. I'm not a free software fanatic (I use Debian because I like the packaging system and menu system), but I honestly do *not* understand why the KDE team objects to clarifying the KDE license to explicitly allow linking with Qt. Care to elaborate? -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: X window logo
Michael Meskes wrote: > On Fri, Oct 09, 1998 at 11:16:27AM -0700, Kenneth Scharf wrote: > > Whenever you start a program running under X11, the windows created > > usually have the little 'X' logo in the upper left hand corner. If > > you are running RedHat linux however, the upper left hand corner of > > the windows contains the RedHat logo (head with a red hat). Why > > can't it (under Debian) have the blue eyed penguin logo? > Great idea IMO. Can we get that into slink? Last time I checked, the license for the logo didn't allow its use in a package (which I complained about, so maybe that's not true any more). I tried to do this myself, and found that the logo was unrecognizable when shrunk down that small. The lines are too thin, and critical detail gets lost. RH's logo is actually a lot cleaner and more elegant (IMO) than Debian's. I'd vote for a new logo if I thought anyone would listen to me. -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
Re: what's after slink
Matthew Parry wrote: > I like the Hitch Hikers idea: I would like to go on record as being *strongly* opposed to the Hitchhiker's Guide idea. I really don't want to give the impression that Debian is some sort of joke. I also find it extremely unoriginal, and rather puerile. (I didn't even find the original all that funny, though it had moments.) Nearly anything else would be acceptable, but let's show a little more maturity than this. I suppose I should be thankful that no one has suggested using names from Xanth or Goosebumps, but great Ghu, surely we can do better. I think I'd almost rather switch to Red Hat than use the "Beeblebrox" release. I mean, what's next? Putting pictures of maintainer's pets on the Debian web page? :-) -- Chris Waters [EMAIL PROTECTED] | I have a truly elegant proof of the or [EMAIL PROTECTED] | above, but it is too long to fit into http://www.dsp.net/xtifr | this .signature file.
