Re: Quake 2 sources GPL'd
On Sat, Dec 22, 2001 at 05:55:46AM +0200, Juhapekka Tolvanen wrote: > > I just heard it through the www.linuxgames.com > > ftp://ftp.idsoftware.com/idstuff/source/quake2.zip > > Can we include that in Woody before too deep freeze? > > P.S: I don't subscribe to this list. I am smart enough to read > mailing-list archives via WWW, but you can Cc: me if you want. If you want one that works, wait until QF has finished sanitizing it. I wouldn't hold my breath for woody though. -- Adam Olsen, aka Rhamphoryncus
Re: Quake 2 sources GPL'd
On Sat, Dec 22, 2001 at 07:42:03AM -0500, Branden Robinson wrote: > On Fri, Dec 21, 2001 at 11:57:21PM -0800, Thomas Bushnell, BSG wrote: > > If the only practical use of the engine is to run non-free levels from > > id, then it belongs in contrib. > > But that's obviously not the case. A game engine, especially one coded > in large part by a luminary in the fieldlike John Carmack, is > interesting and useful (to programmers) in its own right. > > We wouldn't stick a Free compiler or interpreter for some new-fangled > programming language in contrib simply because no Free programs written > in that language were yet packaged for Debian. > > I would, however, be tempted to mark such an engine as Priority extra > until Free game levels were packaged for Debian, so that Debian's many > non-programming users would not get their hopes up at being able to play > the game in Debian as distributed. How about the fact that the engine requires the game data to run, meaning it needs a Depends: quake2-data. Without such data it shouldn't be packaged at all. No, I wouldn't stick a new compiler/interpreter in contrib. But I wouldn't package it at all either, unless I was either going to package a program that used it, or I had some local program that used it. And in the case of an interpreter, you could use it interactively. -- Adam Olsen, aka Rhamphoryncus
Re: Quake 2 sources GPL'd
On Sun, Dec 23, 2001 at 10:45:51AM +1100, Hamish Moffatt wrote: > On Sat, Dec 22, 2001 at 09:51:17AM -0500, David B Harris wrote: > > Maybe I'm splitting hairs, but I think that, at least morally, it's > > allright to put Quake2 in main. > > Why not wait until there really is free data? Doesn't seem like > much of an inconvenience. > > If we assumed all non-free data or software could be replaced, > then we wouldn't need contrib at all - everything could go in > main. Exactly. The GPL doesn't care that it could be used with a free alternative at some arbitrary point in the future, it cares that it can't be used with a free alternative NOW. If/when such an alternative becomes available, then the issue of putting it into main can be readdressed. -- Adam Olsen, aka Rhamphoryncus
Re: Quake 2 sources GPL'd
On Sun, Dec 23, 2001 at 12:01:47PM -0500, Ben Collins wrote: > On Sun, Dec 23, 2001 at 03:44:16AM -0500, Zephaniah E. Hull wrote: > > On Sat, Dec 22, 2001 at 11:50:00PM -0800, Thomas Bushnell, BSG wrote: > > > > > If there *are* playable levels available for quake2 (which need > > > nothing in the way of non-free game data) then of course it belongs > > > (along with those levels) in main. > > > > Uhm, guys. > > > > You need much more then just free maps, you also need replacement fonts > > and other graphics. (Stuff used for the console, the menu, the in game > > HUD, and a few other things.) > > > > Replacements for those are unlikely to exist now, and will take a while > > to generate. > > As I said. The engine is meant to develop games for. Just because no one > has developed games for a development system (the engine), doesn't make > it contrib. > > You people need to think of it as an interpreter of the data files. Do > not judge the engine based on the data files that are available for it > (else we'll have to start judging script interpreters and libraries the > same way). There is a distinction between data and a program. If the engine was just a gamecode interpreter then, yes, you could make the gamecode depend on the engine. But it's not, and the vast majority (or all, if the gamecode is serverside and the quake2 package doesn't include a server) is binary data. We have many packages already (such as amphetamine and it's -data) where the main package depends on the data (and vice versa), which sets a precedent. The way to package quake2 would be having quake2-client and quake2-server which depend on quake2-data, which is provided by quake2-data-nonfree. Now, if you DID have something that was just the gamecode, and you had a freestanding interpreter (such as the one in quakeforge), then you could have the interpreter with no depends[0], and make your gamecode depend on the interpreter. [0] technically with quakeforge's interpreter, it'd depend on the quakeforge libs, but that doesn't really matter. -- Adam Olsen, aka Rhamphoryncus
Re: Need some shell scripting help
On Sun, Dec 23, 2001 at 06:09:28PM +0100, martin f krafft wrote: > also sprach Torsten Landschoff <[EMAIL PROTECTED]> [2001.12.23.1755 +0100]: > > > print -l * > > > > What should this do in your opinion? For me, print is something > > quite different: > > it's a shell built-in of zsh, and -l prints the arguments as newlines > instead of separated by spaces. > > fishbowl:..b/pantsfullofunix.net> print -l * > adequacy.org_hacker.html > index.html > mirror/ > ms_white/ > www.unix-vs-nt.org/ > fishbowl:..b/pantsfullofunix.net> You mean like ls -1 ? -- Adam Olsen, aka Rhamphoryncus
Re: Quake 2 sources GPL'd
On Sun, Dec 23, 2001 at 10:49:33PM -0500, Ben Collins wrote: > On Sun, Dec 23, 2001 at 06:57:45PM -0800, Thomas Bushnell, BSG wrote: > > > > Ben Collins <[EMAIL PROTECTED]> writes: > > > > > But quake2-engine does not depend on anything to fulfill it's purpose. > > > It is a gaming engine, not a game. This is the same logic that applies > > > to libraries and interpreters. > > > > Huh? The purpose of quake2 is not to run quake levels and be a > > playable game? > > The purpose of the sources released is a gaming engine. They did not > release "quale2 the game", which is what the data files consist of. > Notice that lots of games from Id are based on the quake3 engine. They > aren't quake3, but they use the same engine, and different data files. > > Do not confuse a game engine (the source released) with the game itself > (the data files that they didn't release). But you do agree that it requires having *some* data, no matter what "game" it's for? Which means having a Depends: quake2-data? And if you wish to argue that it can be used to develop the data, then you should have no problem in providing such a package of it. -- Adam Olsen, aka Rhamphoryncus
Re: Quake 2 sources GPL'd
On Mon, Dec 24, 2001 at 01:42:45AM -0500, Ben Collins wrote: > On Mon, Dec 24, 2001 at 04:01:25AM +0000, Adam Olsen wrote: > > > > On Sun, Dec 23, 2001 at 10:49:33PM -0500, Ben Collins wrote: > > > On Sun, Dec 23, 2001 at 06:57:45PM -0800, Thomas Bushnell, BSG wrote: > > > > > > > > Ben Collins <[EMAIL PROTECTED]> writes: > > > > > > > > > But quake2-engine does not depend on anything to fulfill it's purpose. > > > > > It is a gaming engine, not a game. This is the same logic that applies > > > > > to libraries and interpreters. > > > > > > > > Huh? The purpose of quake2 is not to run quake levels and be a > > > > playable game? > > > > > > The purpose of the sources released is a gaming engine. They did not > > > release "quale2 the game", which is what the data files consist of. > > > Notice that lots of games from Id are based on the quake3 engine. They > > > aren't quake3, but they use the same engine, and different data files. > > > > > > Do not confuse a game engine (the source released) with the game itself > > > (the data files that they didn't release). > > > > But you do agree that it requires having *some* data, no matter what > > "game" it's for? Which means having a Depends: quake2-data? > > > > And if you wish to argue that it can be used to develop the data, then > > you should have no problem in providing such a package of it. > > Does python "Depend: some-python-script"? No, it doesn't. Python is an > interpreter. Same logic applies for the quake2 engine. Other things will > depend on it, not the other way around. No, it doesn't apply, because quake2 is an engine for a game, not an interpreter for a language. -- Adam Olsen, aka Rhamphoryncus
Re: Quake 2 sources GPL'd
On Mon, Dec 24, 2001 at 02:53:25PM +0100, Erich Schubert wrote: > > No, it doesn't apply, because quake2 is an engine for a game, not an > > interpreter for a language. > > Actually the quake2 engine IS. > It's a runtime environment (you might call it interpreter) for the graphics > files and the gamei386.so (or whatever it was called) > These graphics files and the gamei386.so can be exchanged to make a very > different game out of the same engine. > The gamei386.so for the original quake2 is GPL, too, but not necessary > (as this is, i think, the only part that really depends on the > commercial data files!!!) > > So the engine IS free; the original quake2 rules should go into contrib. > > Think of python running a compiled python script (?) > or java running a "java program". But it still depends on the -data, just as much as every other package that depends on a -data does. And until there actually IS an alternative, it has to live with the side effects of a dependency on a non-free. -- Adam Olsen, aka Rhamphoryncus
Re: An alarming trend (no it's not flaimbait.)
On Wed, Dec 26, 2001 at 09:38:24AM +0100, Pierfrancesco Caci wrote: > Nice bait I'll bite, but if you want to read it you'll have to > subscribe... It's not fair to throw the rock and hide the hand > > 1) learn how to properly format a mail message (i.e. fold at 75th >column) > > 2) learn how to package a deb and adopt whichever package you think >you're better at maintaining than the original maintainer > > 3) if the package is dead upstream, fork it and maintain it >yourself. Most free software licences allow it. While it is a bit of a bait, I agree with his assessment. And I believe his point is that debian needs a better way to handle packages that aren't properly maintained, rather than just letting them clutter up the archives. -- Adam Olsen, aka Rhamphoryncus
orphaned packages in DWN?
In response to the thread about old packages, I have a specific suggestion. How about we post a list of orphaned packages in the weekly news? That way the community is kept very aware of where they can help. And if somebody gets annoyed by seeing the same package from week to week, well, by that point it should get removed outright. -- Adam Olsen, aka Rhamphoryncus
Re: orphaned packages in DWN?
On Wed, Dec 26, 2001 at 09:18:55AM -0800, John H. Robinson, IV wrote: > On Wed, Dec 26, 2001 at 04:53:54PM +0000, Adam Olsen wrote: > > How about we post a list of orphaned packages in the weekly news? > > not every week! news is for _new_ stuff, not the same-old from the > previous week. If the same packages get posted repeatedly then they need more drastic measures. Reposting them just shows that they've yet to get a maintainer, and still need one. > perhaps a monthly/biweekly post to #debian-devel, or some other > (moderated) list set up just for such automated reports. > > keeping the community updated is a nice thing, this is why so very few > of our lists have closed subscriptions. using DWN as a forum for _this_ > purpose i believe is bad. Perhaps. Certainly, DWN isn't just for developers, so it's a bit off topic there. However, posting packages that have gone unmaintained for a long time, and which we're not planning on removing completely, would get a response if it was actually used by somebody. -- Adam Olsen, aka Rhamphoryncus
Re: orphaned packages in DWN?
On Wed, Dec 26, 2001 at 05:45:08PM +, Sean Neakums wrote: > begin Adam Olsen quotation: > > > On Wed, Dec 26, 2001 at 09:18:55AM -0800, John H. Robinson, IV wrote: > >> keeping the community updated is a nice thing, this is why so very few > >> of our lists have closed subscriptions. using DWN as a forum for _this_ > >> purpose i believe is bad. > > > > Perhaps. Certainly, DWN isn't just for developers, so it's a bit off > > topic there. However, posting packages that have gone unmaintained > > for a long time, and which we're not planning on removing completely, > > would get a response if it was actually used by somebody. > > How about listing packages that are orphaned on DWN once, when it > happens, with a pointer to the full list of orphaned packages? > Something like: > > Three packages were orphaned this week: blah, blorp and foop, > bringing the total to xxx. Please see > http://debian.org/wherever/the/list/lives for the full list. > > seems suitable for a user-oriented newsletter. I agree. Although we should perhaps have a second mailing to debian-devel listing packages that have been unmaintained for a while, and are getting old enough to remove. -- Adam Olsen, aka Rhamphoryncus
Re: orphaned packages in DWN?
On Wed, Dec 26, 2001 at 07:15:53PM +0100, Martin Schulze wrote: > Sean Neakums wrote: > > begin Adam Olsen quotation: > > > > > On Wed, Dec 26, 2001 at 09:18:55AM -0800, John H. Robinson, IV wrote: > > >> keeping the community updated is a nice thing, this is why so very few > > >> of our lists have closed subscriptions. using DWN as a forum for _this_ > > >> purpose i believe is bad. > > > > > > Perhaps. Certainly, DWN isn't just for developers, so it's a bit off > > > topic there. However, posting packages that have gone unmaintained > > DWN: Welcome to Debian Weekly News, a newsletter for the Debian developer > community. > (from <http://www.debian.org/News/weekly/>. Oops :) > > > > for a long time, and which we're not planning on removing completely, > > > would get a response if it was actually used by somebody. > > > > How about listing packages that are orphaned on DWN once, when it > > happens, with a pointer to the full list of orphaned packages? > > Something like: > > > > Three packages were orphaned this week: blah, blorp and foop, > > bringing the total to xxx. Please see > > http://debian.org/wherever/the/list/lives for the full list. > > > > seems suitable for a user-oriented newsletter. > > You are invited to provide such information on a regular basis > phrased similar to the recently added packages item. > > That's not said to stop you. A slap in the face in reality, but then, isn't that what this is all about? This is an important issue for debian, but there's many other important issues too, and in the end the ones that get improved are the ones that get improved. Anyway, I did some searching and found two interesting posts, although not the one by Bas Zoetekouw that was mentioned earlier. The first is http://www.geocrawler.com/archives/3/216/2001/11/100/7020148/, and it mentions a script to remove old bugs from wnpp[0]; Not directly useful. The second is http://lists.debian.org/debian-devel/2000/debian-devel-23/msg01353.html, which says there's a lintian error/warning called "ancient-standard-version", which I believe can detect when a debian package is far behind the upstream version. [0] Actually, the script is to generate wnpp summaries, which would help in clearing out old bugs. -- Adam Olsen, aka Rhamphoryncus
Re: An alarming trend (no it's not flaimbait.) (fwd)
On Wed, Dec 26, 2001 at 03:02:48PM -0800, Thomas Bushnell, BSG wrote: > > Seems to me that we came up with a solution for this problem a while > ago: the Debian QA team. Right now it has eight people, and an > overwhelming workload. I think a QA team is the right thing here; > presumably it can have the discussions about whether particular > packages are so stale they should be removed. I agree, but I was trying to get more obvious mechanisms for them to use. > > But I suspect that eight people is nowhere near enough people. Maybe > I could join... Indeed, maybe the problem would go away if everyone who > has posted a suggestion in this thread joined the QA team and started work. I'd be more than willing to help, but I'm not a debian developer. (heh, anybody live in edmonton alberta?) > > Maybe we need a way to make being on the QA team a sexy job, just like > maintaining glibc or the kernel or X is. I HOPE that's a joke. Mentioning the X maintainer (*cough* no names *cough) in the same sentance as "sexy" is just wrong imnsho. -- Adam Olsen, aka Rhamphoryncus
Re: An alarming trend (no it's not flaimbait.) (fwd)
On Wed, Dec 26, 2001 at 03:37:15PM -0800, Thomas Bushnell, BSG wrote: > Adam Olsen <[EMAIL PROTECTED]> writes: > > > > But I suspect that eight people is nowhere near enough people. Maybe > > > I could join... Indeed, maybe the problem would go away if everyone who > > > has posted a suggestion in this thread joined the QA team and started > > > work. > > > > I'd be more than willing to help, but I'm not a debian developer. > > (heh, anybody live in edmonton alberta?) > > You don't have to be a developer to be a QA person; see qa.debian.org > for details. > > And there are currently two developers who live in Edmonton. Oh, err umm... I need more excuses. Anybody got any suggestions? ;) -- Adam Olsen, aka Rhamphoryncus
Re: stat vs stat64 - ugly problem
On Mon, Jan 07, 2002 at 01:20:45AM +0100, Wichert Akkerman wrote: > Previously David N. Welton wrote: > > Right, so how do we fix this? It is our problem, in that we need to > > make the software we distribute work together. But are you also > > saying that upstream shouldn't be setting that bit in their header > > file? > > As long as the API (and ABI) never exports things like struct stat and > offset_t (ie things that are affected by enabling LFS) it should not > matter if you link things that are compiled with LFS with things that > are not. > > However that define should never be in a header file, especially > not one that other applications can use. Doing that should warrant > a hefty bugreport. And if they do require the LFS for their interface, then I'd go with: #ifndef _FILE_OFFSET_BITS #error _FILE_OFFSET_BITS must be defined for foo #endif Which leaves the app to explicitely enabling it, either at the top of the .c files, or with CFLAGS. -- Adam Olsen, aka Rhamphoryncus
Re: serious bug. Evolution and Microsoft mentality.
On Thu, Jan 10, 2002 at 12:38:30PM -0500, Jeffrey Stedfast wrote: > Actually the attached patch is the "correct one". There is no need to > memset and you should use PATH_MAX rather than 4096. No, the "correct" way is to malloc the space as needed. PATH_MAX doesn't exist on the Hurd. -- Adam Olsen, aka Rhamphoryncus
Re: problem with debconf and start-stop-daemon
On Fri, Jan 11, 2002 at 04:49:19PM +, Mark Brown wrote: > On Fri, Jan 11, 2002 at 10:34:18AM -0600, Steve Greenland wrote: > > > You can't, in general, close *all* open file descriptors. OPEN_MAX > > may not exist (and I would guess that it doesn't on the HURD). It's > > completely reasonable for a daemon to that doesn't open any extras to > > assume that only stdin, stdout, and stderr are open. > > If OPEN_MAX is undefined you could always use INT_MAX :-) . iirc, there has been a problem with a program closing all descriptors before, because they were used by libc (?) for something. So no, you shouldn't use INT_MAX either :) -- Adam Olsen, aka Rhamphoryncus
Re: Bug#141345: ITP: sextractor -- Builds a catalogue of objects from an astronomical image.
On Sat, Apr 06, 2002 at 02:59:32AM +0200, Russell Coker wrote: > What does a sex tractor have to do with astronomy? > > What is a sex tractor anyway? A google search turned up some amusing > results, especially the first one, but didn't seem to describe what you are > packaging. SExtractor Source-Extractor Like sex, the simple editor for X, it has nothing to do with the obvious :) > > On Fri, 5 Apr 2002 18:04, Stephen Quinney wrote: > > Package: wnpp > > Version: N/A; reported 2002-04-05 > > Severity: wishlist > > > > * Package name: sextractor > > Version : 2.2.2 > > Upstream Author : E. Bertin <[EMAIL PROTECTED]> > > * URL : http://terapix.iap.fr/soft/sextractor/index.html > > * License : Other (see below) > > Description : Builds a catalogue of objects from an astronomical > > image. > > > > License: > > > > This software is Copyrighted (C) E.BERTIN 1994-2001 > > It is freely distributable. > > If you make any change to this program, please indicate it clearly > > in the source and rename the executable to something else. > > > > ** > > * This program is distributed in the hope that it will be useful,* > > * but WITHOUT ANY WARRANTY; without even the implied warranty of * > > * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * > > ** > > -- > If you send email to me or to a mailing list that I use which has >4 lines > of legalistic junk at the end then you are specifically authorizing me to do > whatever I wish with the message and all other messages from your domain, by > posting the message you agree that your long legalistic sig is void. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Adam Olsen, aka Rhamphoryncus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The GNU FDL is a free license! (Was: Re: O: gnu-standards --GNU coding standards)
On Mon, Apr 08, 2002 at 01:22:51AM +0200, Michael Banck wrote: > On Sun, Apr 07, 2002 at 05:15:16PM -0500, Joe Wreschnig wrote: > > In fact, XML and HTML (and I would imagine therefore CSS and XSLT) are > > explicitly listed as transparent formats. I'm not going to argue that. > > The problems, although they're transparent, they're programs as well > > as documents. > > Blackbird:~$ ./index.html > bash: ./index.html: Permission denied > > hmm, doesn't work here :-/ echo '#!/usr/bin/lynx' > newindex.html cat index.html >> newindex.html chmod +x newindex.html ./newindex.html Seems to work for me :) (although the fact that the shebang gets displayed on the page shows either a glaring oversight in the design of html, or that linux needs to recognise tags) -- Adam Olsen, aka Rhamphoryncus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
