just making sure we're all really this quiet
Is it me, or are the Debian lists really quiet? My secondary list server hasn't transferred a single thing from the primary server in several hours, perhaps even a day. Am I crazy, or did I break something? I think I should suggest that we remove all of the editors except ae from the entire Debian project, just to rekindle our classic flame war (and verify that people are really out there!). If you've made any recent posts (within 24 hours) and haven't seen them come through, please let me know so I have something to look for. Thanks! Pete -- Peter J. Templin, Jr. Client Services Analyst Computer & Communication Services tel: (717) 524-1590 Bucknell University [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: wget... (was: Where is the mysql package?)
> "Tom" == Tom Lees <[EMAIL PROTECTED]> writes: Tom> wget can do this. It sounds like snarf is similar to this. I use wget to grab graphics via http for the 'imgsize.el' extension I wrote for XEmacs. It will measure the size of a graphic, and fill in the length and width attributes of an img tag, so that the browser will be able to preformat text around areas where a not-yet-arrived picture will be. `imgsize.el` is on my www page; click my forehead. -- Karl M. Hegbloom <[EMAIL PROTECTED]> http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.2 Linux 2.1.36 AMD K5 PR-133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org & qmail (was Re: Using CVS for package development)
On May 29, Bruce Perens wrote > I must admit to not understanding what that qmail alias file is for. > I do _all_ of my aliases with .qmail-* files . > > What I was trying to achieve was to have qmail forward a message without > messing around with the headers any more than necessary. Thus, I wanted > to have a .qmail-packages-default file to handle the packages.debian.org > domain, and that would look up the package name and map it to the maintainer > address, and remail messages to the maintainer. This is not a terribly > complicated hack, but I got busy. I don't understand why you need to use RFC822 style addresses here? You've got a message in-transit, so RFC821 seems more appropriate. Furthermore, qmail parses the destination addresses and stuffs it into various environmental variables, so parsing the dest address shouldn't be an issue. And, of course, identifying the proper smtp destination address for the package maintainer is something that should be done at the time the database is populated, not every time a message hits the system. Given these conditions, I can think of at least three different ways of implementing the forwarding: (1) user-map [if all package maintainers are local] (2) db lookup from -default (and of course there's lots of ways to implement db) (3) ~aliase/.q* [There's more ways .. you could generate an account for each package, ferinstance.] -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org & qmail (was Re: Using CVS for package development)
> (1) user-map [if all package maintainers are local] If you just want to be delivering mail to @packages.debian.org (rather than -@packages.debian.org), you can deliver to remote addresses with: In users/assign, create one line per package: =:alias:70:65534:/var/qmail/alias:+:fwd-: so in the case of my rsync package, that would be: =rsync:alias:70:65534:/var/qmail/alias:+:[EMAIL PROTECTED]: and in ~alias/.qmail+fwd-default: |forward "$EXT2" If you want to deal with mail to e.g. [EMAIL PROTECTED] then it is more complicated. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On Thu, 29 May 1997, Galen Hazelwood wrote: > Christian Schwarz wrote: > > > > Next step: GNU's "configure" utility. I thought that we had agreed on > > using > > i386-unknown-linux > > (and similar for the other architectures), but then I had just discovered > > that GCC uses > > /usr/lib/gcc-lib/i486-linux/2.7.2.1/ > > ^^ > > > > (first it says "i486" instead of "i386", second it ommits the "unknown"). > > > > Yes, for hysterical raisins, we use i486 instead of i386. > systems, these are identical. On Intel, they happen to be different. > We leave out the "unknown" becuase A) it's ugly, and B) nobody cares who > built your silly pc-clone box anyway. They're all the same, except for > the ways in which they are different. :) > > (Don't ask me what the historical reasons are, though. I might start to > whimper...) Sorry, but I couldn't resist :-) What are the reasons? If we make this policy, we should have some real arguments for it! Since we use "i386" in all our file names and since Debian actually runs on 386SX and higher I don't see why we should label this "i486". Does someone know if it makes any troubles if we ommit the (ugly) "unknown" in "i386-linux"? Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- "DIE ENTE BLEIBT DRAUSSEN!" -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
Christian Schwarz wrote: > > On Thu, 29 May 1997, Galen Hazelwood wrote: > > (Don't ask me what the historical reasons are, though. I might start to > > whimper...) > > Sorry, but I couldn't resist :-) What are the reasons? I don't know. That's why I whimper... > If we make this policy, we should have some real arguments for it! Since > we use "i386" in all our file names and since Debian actually runs on > 386SX and higher I don't see why we should label this "i486". Perhaps. Anybody have any serious arguments? I think the reason we configure gcc as i486 is so it automatically optimizes for the 486; it's a good middle ground. > Does someone know if it makes any troubles if we ommit the (ugly) > "unknown" in "i386-linux"? Not as far as I know. --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Copyright question
A program I am packaging has a copying policy as follows: Only NON-COMMERCIAL distribution allowed. Redistribution of modified versions by other people than myself is not allowed. However, commercial use is no problem as long as the software is NOT being commercially distributed. Please send your contributions, bugreports, hints etc. to the author. Thanks ! Should this go in contrib or non-free? -- John Goerzen | Running Debian GNU/Linux (www.debian.org) Custom Programming| [EMAIL PROTECTED] | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Infocom Games (Was: long list of give away or orphaned packages)
> Some background: In the '80s, Infocom produced a lot of excellent > adventure games, and they published them all in portable, completely > architecture-independant 'story files'. When you bought the game, you > got an interpreter and a story file, (although you normally didn't know > that). Since then, various people have decyphered the story file > format and produced a compiler (Inform) to generate these files, and > interpreters (Frotz being one) to play them. > > If we had Frotz, it would be simple to package up a large(ish) number > of the games available. Just so you know, I've already packaged up an Infocom parser (called "infocom") package. > I suspect a lot of the games would have to go in contrib, as they don't > have their Inform source with them, and Inform itself would have to be > non-free, 'cause it has restrictions on profit-making. I think Frotz > could go in the main distribution, but I'll have to check on that... None of the Infocom games can be distributed, however. You have to buy them. Brian ( [EMAIL PROTECTED] ) --- You can never be too good looking or too well equipped. -- Dilbert -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: long list of give away or orphaned packages
> Right now, I believe we have an old version of the ITF interpreter in > the "infocom" package. This should probably be scrapped, as it is > highly obsolete given our current Z-machine knowledge. I wasn't aware that the Z-machine knowledge had changed in the past half-dozen years or so. The "infocom" program handles all the games I've ever tried with it, so I don't see why it is obsolete. Brian ( [EMAIL PROTECTED] ) --- measure with micrometer, mark with chalk, cut with axe, hope like hell -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
> > E.g. boot-floppies. I regularly receive patches from the people doing > > the ports to other architectures. If they could merge them into the > > CVS repository, they needn't wait until I released a new version. > > What provision do you suggest for code-review? It's important for things > like boot-floppies where a patch for one architecture, done carelessly, > might break another. You can use branches to deal with this. Each "feature" is worked on in its own branch and then merged back to a "testing" branch for the code- review you speak of. When it passes that, you can merge that back to the main tree for use/release. At least, this is one way... Brian ( [EMAIL PROTECTED] ) --- He who laughs last usually make a backup. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: long list of give away or orphaned packages
Brian White wrote: > I wasn't aware that the Z-machine knowledge had changed in the past > half-dozen years or so. The "infocom" program handles all the games > I've ever tried with it, so I don't see why it is obsolete. Oh, it works fine in normal cases. But we now understand certain obscure v5 and v6 features (graphics, real-time input, streams) better than we did then. Try running "Border Zone" or "Beyond Zork" on ITF. You might find all sorts of subtle problems. I can send you my copy of the Specification version 0.99, which should be released as 1.0 RSN (i.e., don't hold your breath.) Interested? --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Bug#10089: Experiences with 1.3 ("bo")
On Mon, 26 May 1997, Dale Scheetz wrote: > > A few minor problems: > > > > In dselect, running "configure packages" multiple times, as suggested in > > the documentation, did not seem to correct some of the misinstalled > > packages (Xserver, xext). > > > The documentation should suggest re-running Install, not Configure. > Running Install until all errors cease is the prescribed work around > for dselect. Configure followed by Install is the best way. Configure will get all the packages which were installed before the packages they depended upon. Install will get all the restand will run faster because it won't have to re-install the packages which only failed to configure because of a minor dependancy problem. The usual order I run dselect in is: 1. I usually upgrade dpkg, ldso, libc[56], and other important packages by hand before starting dselect if there are new versions in my mirror. 2. run dselect. 3. UPDATE 4. SELECT 5. INSTALL 6. if there are problems, sometimes i press ^Z to suspend dselect, cd to the appropriate subdirectory of my debian mirror and install a few packages by hand...then type 'fg' to return to dselect. 7. CONFIGURE 8. sometimes REMOVE is required, e.g. when a package replaces another package but the control information is incorrect. 9. if there were any installation problems, repeat from step 5. (alternatively, repeat from step 4 and de-select problem packages or select extra packages) 10. QUIT Until dselect can install in dependancy order, this is the least hassle way to complete a dselect installation or upgrade. craig -- craig sanders networking consultant Available for casual or contract temporary autonomous zone system administration tasks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: just making sure we're all really this quiet
On Sat, 31 May 1997, Pete Templin wrote: > > Is it me, or are the Debian lists really quiet? My secondary list server > hasn't transferred a single thing from the primary server in several > hours, perhaps even a day. This message is the only think I've got all day from any of the debian lists.. So either everyone is.. otherwise occupied, or it's bork. Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: just making sure we're all really this quiet
> > > Is it me, or are the Debian lists really quiet? My secondary list server > hasn't transferred a single thing from the primary server in several > hours, perhaps even a day. > > Am I crazy, or did I break something? No you are not. During the last 24 hours I received only 2(!) debian lists-related messages. And one was actually reply on my message posted a few days ago (doesn't really count since it was replied directly to my address) and YOURS!! I tried to resubscribe to the different e-mail address several hours ago and didn't get even automatic confirmation. So I guess something really happend to the lists. Alex Y. > > I think I should suggest that we remove all of the editors except ae from > the entire Debian project, just to rekindle our classic flame war (and > verify that people are really out there!). > > If you've made any recent posts (within 24 hours) and haven't seen them > come through, please let me know so I have something to look for. Thanks! > > Pete > > -- > Peter J. Templin, Jr. Client Services Analyst > Computer & Communication Services tel: (717) 524-1590 > Bucknell University [EMAIL PROTECTED] > > > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: just making sure we're all really this quiet
Everybody's holding their breath waiting for the release to come out. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Infocom Games (Was: long list of give away or orphaned packages)
On Sat, 31 May 1997, Brian White wrote: > > None of the Infocom games can be distributed, however. You have to > buy them. Heh. I guess that means we cant package up any of these then ftp://ftp.gmd.de/if-archive SirDibos www.linuxos.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
On Sat, 31 May 1997, Richard G. Roberto wrote:
> Well, I promised myself I wasn't going to get involved in this kind of
> thing, but I'm about to get a private internet connection so I should
> be able to insulate my job from these discussions soon. I would like
> to make the following requests of those working on this project:
>
> Please do not create a proprietary configuration interface.
I couldn't agree more.
The config database should be regarded as a convenience for
{pre,post}{inst,rm} scripts and /etc/init.d/ boot time scripts only.
It should NOT attempt to be some universal replacement for
package-specific config files.
All that is needed is a set of "key=value" pairs in a plain text file. Take
a look at FreeBSD's /etc/sysconfig or NextStep's /etc/hostconfig for an
example.
This is not only simple to implement, but it is also simple to
parse...and it allows the sysadmin to change the setup with
vi/pico/ae/joe/emacs or whatever. Later, a GUI or web front end can be
layered ON TOP of this.
parsing the files in shell is simple:
source /etc/sysconfig
parsing it in perl is almost as easy. The following code fragment reads
/etc/sysconfig into an associative array called $config.
$sysconfig="/etc/sysconfig" ;
open(SYSCONFIG,"$sysconfig") || die "can't open $sysconfig: $!\n" ;
while () {
s/#.*$//; # strip out comments
next if /^$/ ; # ignore blank lines
($variable, $value) = /^(.*)=(.*)/ ;
$config{$variable} = $value ;
} ;
close(SYSCONFIG) ;
i'm not a great perl programmer, so the above can probably be improved.
i'm making myself NOT do everything in sh, and forcing myself to learn
how to do it in perl instead.
Here's some example usage of the array:
print $config{hostname} ;
print $config{ip_address} ;
# print out the entire array:
foreach $item (sort keys(%config)) {
print $item, "=", $config{$item}, "\n" ;
}
This perl fragment is good enough for simple assignments like:
domainname=taz.net.au
hostname=siva.taz.net.au
it's not yet smart enough to do:
domainname=taz.net.au
hostname=siva.$domainname
but it wouldn't be hard to modify it to do so.
So, a decision needs to be made: whether to allow only simple
assignments or to also allow complicated assignments like
"foo=`cat /etc/bar`". Parsing the former is easy in any scripting
language. Parsing the latter could get quite difficult in languages
other than sh.
at minimum, we need to support sh/bash/ksh/zsh, and perl. we should also
support csh and probably python. The sh family are easy. perl, csh,
python and others will require a "library" or set of standard code fragments
for parsing the /etc/sysconfig file.
we need code fragments in all of these languages to add, read, modify,
and delete (comment out) "name=value" pairsand do it WITHOUT
disrupting any comments or the order of assignment statements in the
file.
btw, i don't care what the file is called. /etc/sysconfig is just an
example.
craig
--
craig sanders
networking consultant Available for casual or contract
temporary autonomous zone system administration tasks.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Infocom Games (Was: long list of give away or orphaned packages)
however, there *are* freely-written z-code games, which can be distributed (and I think even have been already, for debian? I may have seen them somewhere else.) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
> Jim Pick <[EMAIL PROTECTED]> writes: > > > Besides, Qt is 'almost-free' software. If it doesn't become a runaway > > commercial success, I'd bet Troll Tech would re-release it as free > > software after a few years. > > Troll is using a different economic model for generating revenue than > other free software companies. They get other people to write free > software (for zero cost to them) on one platform so they can sell it > under their own license commercially on other platforms. They prevent > those same authors from redistributing the free software they wrote on > those other platforms (anything other than the X Window System). Sorry. I have to correct this inaccuracy. Free software authors CAN redistribute free software that they wrote on other non-X Window systems. They can also distribute the QT runtime with their software on those platforms for "free". The problem is that the toolkit cost a lot of money ($1470 US) on other platforms. The restrictions as I understand it are thus: -The free software author would have to have access to the non-free version of the Qt toolkit for the other platform. That is very expensive for the author and also for anyone who wanted to compile the free software. -Changes and patches to the Qt library itself can't be distributed without Troll Tech first integrating them into their product and "blessing" them. Qt wants to keep ownership and control of that. (This is true for the X Windows platform as well.) > The X Window System is likely to be replaced, at which point your > Qt-based free software will become very non-free. > > Sounds like a losing bet. > > Why exactly is Qt almost-free? It's a scam. Just because some free > software authors have been snookered into it, doesn't mean we should > put all of our hopes and dreams at the whim of a company that works > against our interests, our goals, and the free software community. > > If Linus, GNU, X11, or BSD had used such as license, would Debian > exist? Would Linux be what it is today? No. > > - - Dan Some people don't like Qt because it's not free per the debian and gnu definition of the word. (In fact it's downright expensive for platforms other than the X Windows system.) But please don't oppose it with untrue and misleading statements. Anyone interested can read the two Qt licenses for themselves at: http://www.trolltech.no -- Lee Olds [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
On Sat, 31 May 1997, Leland Olds wrote: > -Changes and patches to the Qt library itself can't be distributed > without Troll Tech first integrating them into their product and > "blessing" them. Qt wants to keep ownership and control of that. > (This is true for the X Windows platform as well.) This is also partially true for OSS, the Sound Drivers in the Kernel. Some form of commercial company developed these drivers and sells a more complete version and does some cross-platform stuff. If you dig around the web pages enough you realize that they also do not accept any old patch. There was actually a sentance about how a patch may be rejected if it is too large - it would be difficult to integrate into the original sources (the OSS in the kernel is generated from some super-set of sources) So this seems pretty common in the Linux community. Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
actually, a lot of us find the sound driver stuff objectionable too (because it leaves us with practically useless sound code, almost enough to drive one to NetBSD :-) I still don't have any way to use *both* ESS1688's in my laptop (when docked), which should be *trivial* if the module took arguments like every other module in the system... but no, that feature seems to only be in the "commercial" version. So no, "pretty common" isn't even close -- the OSS stuff is just *another* glaring diversion from Free Software. I'm surprised it ever got in to the kernel that way, but I didn't have any sound support on any of my machines until my newest [refurbished, 3year old] laptop... and didn't realize until now just how bad it was... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
-BEGIN PGP SIGNED MESSAGE- Daniel Quinlan wrote: >> Troll is using a different economic model for generating revenue than >> other free software companies. They get other people to write free >> software (for zero cost to them) on one platform so they can sell it >> under their own license commercially on other platforms. They >> prevent those same authors from redistributing the free software they >> wrote on those other platforms (anything other than the X Window >> System). Leland Olds writes: > Sorry. I have to correct this inaccuracy. Yeah, right. > Free software authors CAN redistribute free software that they wrote on > other non-X Window systems. They can also distribute the QT runtime > with their software on those platforms for "free". Not as free software, since the toolkit is not freely redistributed for other platforms. > The problem is that the toolkit cost a lot of money ($1470 US) on other > platforms. > > The restrictions as I understand it are thus: > -The free software author would have to have access to the non-free > version of the Qt toolkit for the other platform. That is very > expensive for the author and also for anyone who wanted to compile > the free software. I don't think you can call it free software if you can't compile it. What good is modifiable source code to users (and others) if compiling their modifications on non-X platforms requires a commercial license? > -Changes and patches to the Qt library itself can't be distributed > without Troll Tech first integrating them into their product and > "blessing" them. Qt wants to keep ownership and control of that. > (This is true for the X Windows platform as well.) False. Read the X Window System license: - --- start of cut text -- Copyright c 1996 X Consortium Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, dis- tribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the fol- lowing conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABIL- ITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABIL- ITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of the X Consortium shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the X Consortium. X Window System is a trademark of X Consortium, Inc. - --- end >> The X Window System is likely to be replaced, at which point your >> Qt-based free software will become very non-free. >> >> Sounds like a losing bet. >> >> Why exactly is Qt almost-free? It's a scam. Just because some free >> software authors have been snookered into it, doesn't mean we should >> put all of our hopes and dreams at the whim of a company that works >> against our interests, our goals, and the free software community. >> >> If Linus, GNU, X11, or BSD had used such as license, would Debian >> exist? Would Linux be what it is today? No. >> >> - - Dan > Some people don't like Qt because it's not free per the debian and gnu > definition of the word. (In fact it's downright expensive for platforms > other than the X Windows system.) You almost have the point. A big part of the word "free" is that it doesn't mean "use this unless you want to write Windows95 software", or "as long as you don't try to make a buck, you can use this". Read the X11 license, the X Consortium is giving away their software left and right. > But please don't oppose it with untrue and misleading statements. > > Anyone interested can read the two Qt licenses for themselves at: > http://www.trolltech.no I have read the "free" and "professional" Qt licenses. By the way, the URL is actually http://www.troll.no/ I don't understand why anyone would want to write free software under someone else's restrictive rules. A contrasting example: the LGPL. LGPL'ed code stays free, but allows non-free programs to use it. If you read the LGPL, the FSF doesn't cover up their motives, they don't mislead people. In fact, when people (especially Debian) complained that the GPL/LGPL kept bison from freely being used to develop software, the FSF changed the bison license. They didn't demand $1470 each time
Re: FreeQt ?
On 1 Jun 1997, Mark Eichin wrote: > actually, a lot of us find the sound driver stuff objectionable too > (because it leaves us with practically useless sound code, almost > enough to drive one to NetBSD :-) I still don't have any way to use > *both* ESS1688's in my laptop (when docked), which should be *trivial* > if the module took arguments like every other module in the > system... but no, that feature seems to only be in the "commercial" > version. So no, "pretty common" isn't even close -- the OSS stuff is > just *another* glaring diversion from Free Software. I'm surprised it > ever got in to the kernel that way, but I didn't have any sound > support on any of my machines until my newest [refurbished, 3year old] > laptop... and didn't realize until now just how bad it was... Yeah, I found it equally objectionable when I was reading it over, considering a few other things I'm -VERY- surprised it is in the kernel at all. But if OSS, X-Free and QT all operate along similar lines, thats 3, there are likely many more out there that have similar setups. Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian FTP Installation through Internet (fwd)
In article <[EMAIL PROTECTED]>, "Boris D. Beletsky" <[EMAIL PROTECTED]> writes: > Can somebody help this guy. Problem is that pppd tells him that > kernel lacks PPP support - I told him that he should recompile the > kernel but seems like it didn't work. I think I remember that there > was some other reason that pppd would act that way. I seem to remember this is what you get if you use an old version of pppd with a new kernel: is his one a debian version or is it left over from his slackware install?
Re: Infocom Games (Was: long list of give away or orphaned packages)
In article <[EMAIL PROTECTED]>, Brian White <[EMAIL PROTECTED]> writes: >> If we had Frotz, it would be simple to package up a large(ish) number >> of the games available. > > Just so you know, I've already packaged up an Infocom parser (called > "infocom") package. Yes, but it's crap. There are several better ones around which should be packaged for debian. We need a virtual package name, infocom-interpreter perhaps. > None of the Infocom games can be distributed, however. You have to > buy them. None of the ones by infocom can be distributed. There are lots of infocom-format games by other people, mostly produced by the inform compiler. In general the source code is not available (because that would make the games too easy :) so as Charles said, they would have to be in contrib.
Re: Copyright question
On 31 May 1997, John Goerzen wrote: > A program I am packaging has a copying policy as follows: > > Only NON-COMMERCIAL distribution allowed. This puts the package into non-free. However... > Redistribution of > modified versions by other people than myself is not allowed. We need at least the possibility to distribute a modified binary version of the package. If this isn't allowed by that sentence, than the package can't be included in the archive at all. Or do I miss something? > However, commercial use is no problem as long as the software > is NOT being commercially distributed. > Please send your contributions, bugreports, hints etc. to the > author. Thanks ! > > Should this go in contrib or non-free? Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- "DIE ENTE BLEIBT DRAUSSEN!" -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On May 31, Galen Hazelwood wrote > Perhaps. Anybody have any serious arguments? I think the reason we > configure gcc as i486 is so it automatically optimizes for the 486; it's > a good middle ground. If I remember right, configuring for pentium leaves an executable that might not run on 386 or 486. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
According to Yann Dirson: > That just go fine, until you try to use 'halt' or 'reboot': as > specified in the manpage (yes :), these only call shutdown when in > runlevel 1-5. Quite strange IMHO. *BE CAREFUL* trying to reproduce it, > it (probably among other unclean things) doesn't unmount cleanly > filesystems. > > I don't know the reason why RLs 7-9 are handled just like 0 and 6. I > think it should at least be possible to choose which behaviour they > have in this case, if the current behaviour is meaningful (IMHO, it is > only meaningful for halt/reboot-like actions). > > Should this be considered as a bug ? I'll fix it so that it test for (runlevel != 0 && runlevel != 6) instead of (runlevel > 0 && runlevel < 6) Mike. -- | Miquel van Smoorenburg | "I need more space" "Well, why not move to Texas" | | [EMAIL PROTECTED] | "No, on my account, stupid." "Stupid? Uh-oh.."| | PGP fingerprint: FE 66 52 4F CD 59 A5 36 7F 39 8B 20 F1 D6 74 02 | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
> On 31 May 1997, John Goerzen wrote: > > > A program I am packaging has a copying policy as follows: > > > > Only NON-COMMERCIAL distribution allowed. > > This puts the package into non-free. However... > > > Redistribution of > > modified versions by other people than myself is not allowed. > > We need at least the possibility to distribute a modified binary version > of the package. If this isn't allowed by that sentence, than the package > can't be included in the archive at all. Or do I miss something? Yes, if a modifying the package isn't allowed, then it cannot go into the main archive, and has to go into non-free, even if you're allowed to make money distributing it. Non-free it is -- joost witteveen, [EMAIL PROTECTED] #!/bin/perl -sp0777ihttp://www.dcs.ex.ac.uk/~aba/rsa/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
> On 1 Jun 1997, Mark Eichin wrote: > > actually, a lot of us find the sound driver stuff objectionable too > > (because it leaves us with practically useless sound code, almost > > enough to drive one to NetBSD :-) I still don't have any way to use > > *both* ESS1688's in my laptop (when docked), which should be *trivial* > > if the module took arguments like every other module in the ... > > laptop... and didn't realize until now just how bad it was... On May 31, Jason Gunthorpe wrote > Yeah, I found it equally objectionable when I was reading it over, > considering a few other things I'm -VERY- surprised it is in the kernel at > all. I'm puzzled. I just looked over the sound driver source code and didn't see anything but GPL licenses in there. I agree that configuration is lousy -- who ever thought that hard-coding interrupts, dma and io ports at compile time was a good idea? -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
In your email to me, Raul Miller, you wrote: > > I agree that configuration is lousy -- who ever thought that hard-coding > interrupts, dma and io ports at compile time was a good idea? Well, although you can't pass hw param at module load time, you *can* pass params via LILO, so you don't have to recompile to change the settings.. Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps "It is a damned poor mind indeed that can't think of at least two ways of spelling any word." Andrew Jackson ** Disclaimer: My views/comments/beliefs, as strange as they are, are my own.** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
Raul Miller wrote: > > On May 31, Galen Hazelwood wrote > > Perhaps. Anybody have any serious arguments? I think the reason we > > configure gcc as i486 is so it automatically optimizes for the 486; it's > > a good middle ground. > > If I remember right, configuring for pentium leaves an executable > that might not run on 386 or 486. > If gcc actually _did_ any pentium optimizations, that might be true. Unfortunately, we don't get that until 2.8. (still waiting...) --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Infocom Games (Was: long list of give away or orphaned packages)
[EMAIL PROTECTED] (Mark Baker) writes: > > None of the Infocom games can be distributed, however. You have to > > buy them. > > None of the ones by infocom can be distributed. There are lots of > infocom-format games by other people, mostly produced by the inform > compiler. In general the source code is not available (because that would > make the games too easy :) so as Charles said, they would have to be in > contrib. Just butting in on this thread to ask a question. Is there a de-compiler for Infocom games? Would such a de-compiler produce readable source code? Just a thought... (I know nothing about the Infocom game language or the binary format.) -- Ben Pfaff <[EMAIL PROTECTED]> 12167 Airport Rd, DeWitt MI 48820, USA *Note*: New PGP key available at http://www.msu.edu/user/pfaffben/pgp.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
> Daniel Quinlan wrote: > > >> Troll is using a different economic model for generating revenue than > >> other free software companies. They get other people to write free > >> software (for zero cost to them) on one platform so they can sell it > >> under their own license commercially on other platforms. They > >> prevent those same authors from redistributing the free software they > >> wrote on those other platforms (anything other than the X Window > >> System). > > Leland Olds writes: > > > Sorry. I have to correct this inaccuracy. > > > Free software authors CAN redistribute free software that they wrote on > > other non-X Window systems. They can also distribute the QT runtime > > with their software on those platforms for "free". > > Not as free software, since the toolkit is not freely redistributed for > other platforms. But the implication that Troll prevents authors from redistributing their own software free-of-charge on other platforms and instead sells it as part of their toolkit isn't true. If an author owns a license, or finds someone with a license willing to compile and link, the software and dynamic libs can be distributed without charge. > > > -Changes and patches to the Qt library itself can't be distributed > > without Troll Tech first integrating them into their product and > > "blessing" them. Qt wants to keep ownership and control of that. > > (This is true for the X Windows platform as well.) > > False. Read the X Window System license: > Sorry. My words were misleading here. I meant "(This is true for Qt under the X Windows platform as well.)" You are correct that The X Window System is "Free Software" per the Debian/Gnu definition. > >> The X Window System is likely to be replaced, at which point your > >> Qt-based free software will become very non-free. > >> > >> Sounds like a losing bet. > >> > >> Why exactly is Qt almost-free? It's a scam. Just because some free > >> software authors have been snookered into it, doesn't mean we should > >> put all of our hopes and dreams at the whim of a company that works > >> against our interests, our goals, and the free software community. "free" means different things to different people. Personally, I like the Debian/Gnu definition. But if someone else uses it in another way, that doesn't mean that they are scammers and are trying to mislead us. Qt is a commercial software product. There are restrictions on the use of their product - either buy the expensive commercial license, or don't sell your software - and buy the expensive commercial license if you want to compile for a non X-Windows platform. But calling Qt a Scam is a bit strong. I think they make it clear that they want to make money selling their product. I think it is also clear that they want to use their "Free-Software" License to encourage people to use and learn their product so they can sell more commercial licenses later. > > A big part of the word "free" is that it doesn't mean "use this unless > you want to write Windows95 software", or "as long as you don't try to > make a buck, you can use this". Read the X11 license, the X Consortium > is giving away their software left and right. > > > I have read the "free" and "professional" Qt licenses. By the way, the > URL is actually http://www.troll.no/ > > I don't understand why anyone would want to write free software under > someone else's restrictive rules. > > A contrasting example: the LGPL. LGPL'ed code stays free, but allows > non-free programs to use it. If you read the LGPL, the FSF doesn't > cover up their motives, they don't mislead people. In fact, when people > (especially Debian) complained that the GPL/LGPL kept bison from freely > being used to develop software, the FSF changed the bison license. They > didn't demand $1470 each time, either. -- Lee Olds [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
[EMAIL PROTECTED] (Galen Hazelwood) wrote on 31.05.97 in <[EMAIL PROTECTED]>: > Christian Schwarz wrote: > > > > On Thu, 29 May 1997, Galen Hazelwood wrote: > > > (Don't ask me what the historical reasons are, though. I might start to > > > whimper...) > > > > Sorry, but I couldn't resist :-) What are the reasons? > > I don't know. That's why I whimper... > > > If we make this policy, we should have some real arguments for it! Since > > we use "i386" in all our file names and since Debian actually runs on > > 386SX and higher I don't see why we should label this "i486". > > Perhaps. Anybody have any serious arguments? I think the reason we > configure gcc as i486 is so it automatically optimizes for the 486; it's > a good middle ground. That may be the reason that Linux gcc is usually configured that way. The reason Debian does it, AFAIR, is simply to be compatible with most of the Linux world. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
[EMAIL PROTECTED] (Craig Sanders) wrote on 01.06.97 in <[EMAIL PROTECTED]>:
> The config database should be regarded as a convenience for
> {pre,post}{inst,rm} scripts and /etc/init.d/ boot time scripts only.
Well, that was what started the discussion, anyway. Then the general-admin-
tool stuff merged with this discussion, and now everybody is talking about
different things.
I think we should try to separate these things out again.
AFAIKT, we actually have three problems to solve:
1. We have configuration info in scripts. This makes those scripts hard to
update.
This is where the text db should come in. Programs and data should be
separated. The scripts still need to be conffiles, because individual
admins will sometimes want to do things differently, but a stock Debian
system should not have any config data in scripts.
2. We need a general system administration tool. Lots of other Unix and
Unix-like Systems already have those, with varying quality. This thing
should ideally be able to configure everything that is globally
configurable on a Debian system, probably via modules provided by the
packages, and be able to run in text mode, under X, and via the web.
And it should not change the format of the configuration info, so
people can avoid it alltogether, and can exchange configuration files
with other systems.
[2a. An individual-user version of this would be good, too. (The dotfile
generator?)
]
3. We need a general way to separate configuration from installation. It
should be possible to take all or part of a system's global
configuration and put it on another system, either before the
installation of the respective packages, or automatically during that
installation.
One of the things we should have is a single-floppy net-or-CD automatic
install - make a customized floppy, put it in the machine, boot, go
away, come back, and find the machine up and running, fully configured.
Network administrators really need this feature, and even Windows has
it. We ought to be able to do what Windows can!
Of course, these these three things ultimately need to be able to work
together.
So, let's try for some terminology, just so we know what we are talking
about:
1. This thing essentially holds parameters for scripts. It's the
PARAMETER DB.
2. This beast is the SYSADMIN TOOL.
3. And this is about AUTOMATED CONFIGURATION.
I sure hope this helps to get the discussion productive again!
Back to Craig (who is talking about the parameter db).
> All that is needed is a set of "key=value" pairs in a plain text file. Take
> a look at FreeBSD's /etc/sysconfig or NextStep's /etc/hostconfig for an
> example.
Well, mostly. A simple way to do arrays would be good, too (think network
interface setup, for example).
This can, of course, be done on top of simple variables, and I have done
so in another context, but as soon as you try to write, say, a tool to
admin this stuff, you need at least to have some conventions.
One way to do this:
_N=4
_1=value1
_2=value2
_3=value3
_4=value4
On the other hand ...
> This is not only simple to implement, but it is also simple to
> parse...and it allows the sysadmin to change the setup with
> vi/pico/ae/joe/emacs or whatever. Later, a GUI or web front end can be
> layered ON TOP of this.
... having a real array syntax makes this less error prone - imagine
someone adding _5=value5 and not changing _N to have 5 as value.
> parsing the files in shell is simple:
>
> source /etc/sysconfig
And on the third hand (h?), this argues against automatic arrays. I
don't know.
Anyway, if we want to be able to do this, we need a name convention.
Something like PDB__ might do. Otherwise, this
is sure to break a script because a local var clashes with another
package's config var.
> parsing it in perl is almost as easy. The following code fragment reads
> /etc/sysconfig into an associative array called $config.
>
> $sysconfig="/etc/sysconfig" ;
> open(SYSCONFIG,"$sysconfig") || die "can't open $sysconfig: $!\n" ;
>
> while () {
> s/#.*$//; # strip out comments
> next if /^$/ ; # ignore blank lines
> ($variable, $value) = /^(.*)=(.*)/ ;
You might want to do something about spaces, too. And you may want to
allow # in values.
Maybe
/^\s*(\S+)\s*=\s*(\S.*?)\s*$/;
next unless defined $2;
($variable, $value) = ($1, $2);
This silently ignores syntax problems. Nothing this short can be perfect.
> $config{$variable} = $value ;
> } ;
>
> close(SYSCONFIG) ;
> print $config{hostname} ;
> print $config{ip_address} ;
If you're learning Perl, you might want to listen to the words of the
great guru (one L. Wall). You can debug your scripts faster if they all
start with these lines:
#! /usr/bin/perl -w
use strict;
However,
Re: FreeQt ?
On Jun 1, Leland Olds wrote > "free" means different things to different people. Personally, I like > the Debian/Gnu definition. But if someone else uses it in another way, > that doesn't mean that they are scammers and are trying to mislead us. Um... in principle. On the other hand, that doesn't mean that all uses are ethical. > Qt is a commercial software product. There are restrictions on the use > of their product - either buy the expensive commercial license, or > don't sell your software - and buy the expensive commercial license if > you want to compile for a non X-Windows platform. Excellent point. > But calling Qt a Scam is a bit strong. I think they make it clear that > they want to make money selling their product. I think it is also clear > that they want to use their "Free-Software" License to encourage people > to use and learn their product so they can sell more commercial licenses > later. Calling a commercial product with strong restrictions free software in misleading, at best. I think "scam" is a perfectly adequate way of labeling this kind of misleading labelling. -- Raul -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
Galen Hazelwood <[EMAIL PROTECTED]> writes: > Perhaps. Anybody have any serious arguments? I think the reason we > configure gcc as i486 is so it automatically optimizes for the 486; it's > a good middle ground. I think the only optimization gcc 2.7.* does for i486 is instruction alignment. The Pentium has a better fetch unit so doesn't need any alignment (it never incurs a misfetch penalty) so optimizing for i486 will at least give some code bloat. I don't think it does any optimization at all for pentium. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
[EMAIL PROTECTED] (joost witteveen) writes: > Yes, if a modifying the package isn't allowed, then it cannot go > into the main archive, and has to go into non-free, even if you're > allowed to make money distributing it. If modifying the package isn't allowed, it can't go anywhere! You better write to the author so he can clarify what a modification is. Usually it's not a problem. It would have to go in non-free in any case. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
> But if OSS, X-Free and QT all operate along similar lines, thats 3, there Umm, no, XFree86 does *not* work that way. Though they do release non-source timebombed betas, they always release full-source "real" releases. You can ignore the betas (as debian does, I mean they are *betas* after all.) But when 3.3 comes out, everyone will have the same up-to-date sources and binaries. Nothing similar to OSS and QT at all. As for OSS -- I had the impression that if I submitted patches to make the modules *accept* command line arguments, they wouldn't be included. But yeah, if they're straight GPL'ed that's good enough; I could still distribute such patches even if they weren't included. (and actually, everything in the *kernel* sources looks fine; I think I was probably interpreting stuff that I saw on the usslite website. So strictly speaking we're back to *one* bad example, which is QT...) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
> As for OSS -- I had the impression that if I submitted patches to make > the modules *accept* command line arguments, they wouldn't be > included. But yeah, if they're straight GPL'ed that's good enough; I > could still distribute such patches even if they weren't included. > (and actually, everything in the *kernel* sources looks fine; I think > I was probably interpreting stuff that I saw on the usslite website. > So strictly speaking we're back to *one* bad example, which is QT...) And then there's Cygnus, and cygwin32.dll - which is under the GPL, not the LPGL... (sorry for the cheap shot) Cheers, - Jim pgpKccdk9pWdC.pgp Description: PGP signature
Re: FreeQt ?
yeah, cygwin32.dll is under the GPL. So? It's a DLL, like libc5 and libc6 are... [the *only* thing I'm aware of that actually uses the LGPL is libg++; it was as much of an experiment as anything, and I'm not aware of any not-otherwise-free software taking advantage of those terms...] Just because libgcc is on "special" terms is no reason for cygwin32.dll to be (cygwin32 is *more* than even a libc, it's got a fair amount of emulation code in it, so it looks like you have unified file descriptors... and you don't want to look at the internals of select...] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
On 31 May 1997, John Goerzen wrote:
> A program I am packaging has a copying policy as follows:
>
> Only NON-COMMERCIAL distribution allowed. Redistribution of
> modified versions by other people than myself is not allowed.
> However, commercial use is no problem as long as the software
> is NOT being commercially distributed.
> Please send your contributions, bugreports, hints etc. to the
> author. Thanks !
>
> Should this go in contrib or non-free?
My own thoughts about the subject:
Q) Is "deb" packaging a modification? (philosophical doubt)
A1) No.
Then Package should go in non-free ("only non-commercial distribution
allowed" ==> "non-free section", Debian Policy Manual v2.1.3.2).
A2) Yes.
Then Program can't be distributed as a Debian package.
Best wishes,
--
Enrique Zanardi [EMAIL PROTECTED]
Dpto. Fisica Fundamental y Experimental
Univ. de La Laguna
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
cygwin.dll license (was Re: FreeQt ?)
> yeah, cygwin32.dll is under the GPL. So? It's a DLL, like libc5 and > libc6 are... [the *only* thing I'm aware of that actually uses the > LGPL is libg++; it was as much of an experiment as anything, and I'm > not aware of any not-otherwise-free software taking advantage of those > terms...] Just because libgcc is on "special" terms is no reason for > cygwin32.dll to be (cygwin32 is *more* than even a libc, it's got a > fair amount of emulation code in it, so it looks like you have unified > file descriptors... and you don't want to look at the internals of > select...] I just brought this up, since it was my understanding that if you want to write a commercial program (ie. not under the GPL), and link it against cygwin.dll, you've got to pay Cygnus $$$. Not all that different than the restrictions on Qt, really. I don't think this situation exists with libc5 or libc6 (ie. Netscape and Sun's JDK are linked against it). I'm not familiar with the licenses on everything though -- I hate reading the fine print. If I'm wrong on this issue (I hope I am), please correct me. Cheers, - Jim pgpLjYTjNzXwK.pgp Description: PGP signature
Re: RFC: Policy for arch specs
Guy Maor wrote: [gcc 2.7.2] >I don't think it does any optimization at all for pentium. Correct. Of course, there's the experimental pgcc (http://www.goof.com/, if anybody wants to look). I'd like to pack this up and stuff it into experimental, if I had a little more time *sigh*. -- Thomas Koenig, [EMAIL PROTECTED], [EMAIL PROTECTED] The joy of engineering is to find a straight line on a double logarithmic diagram. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Copyright question
On Sun, 1 Jun 1997, joost witteveen wrote: > > On 31 May 1997, John Goerzen wrote: > > > > > A program I am packaging has a copying policy as follows: > > > > > > Only NON-COMMERCIAL distribution allowed. > > > > This puts the package into non-free. However... > > > > > Redistribution of > > > modified versions by other people than myself is not allowed. > > > > We need at least the possibility to distribute a modified binary version > > of the package. If this isn't allowed by that sentence, than the package > > can't be included in the archive at all. Or do I miss something? > > > Yes, if a modifying the package isn't allowed, then it cannot go > into the main archive, and has to go into non-free, even if you're > allowed to make money distributing it. > > > Non-free it is No. If the author forbids distribution a changed (i.e. bug fixed) _binary_ version, I think the package may not even go into non-free. What do the others think? Thanks, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
why are shared libs chmod +x?
Hi! Can someone tell me why shared libs should be installed executable? (Actually, Christoph Lameter wants to know this, cf. #7129, but since I don't know this either I'll redirect the question to this list.) This is current policy and I want to add a small note to the paragraph stating the reasons for this. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Infocom Games (Was: long list of give away or orphaned packages)
On Sat, May 31 1997 20:15 - [EMAIL PROTECTED] writes: > On Sat, 31 May 1997, Brian White wrote: > > > > None of the Infocom games can be distributed, however. You have to > > buy them. > > Heh. I guess that means we cant package up any of these then > > ftp://ftp.gmd.de/if-archive Sure we can. These are not Infocom games, or, when they are, then they are Infocom sampler packages, which are IMO distributable. Most of if-archive is freeware (written by other people than Infocom, but in the Z-Language). What you of course cannot distribute -- as already mentioned -- are the real Infocom games (Trinity, Zork 1-3 etc.) David PS1: Frotz can AFAIK handle Z8 games PS2: Was anyone able to run `adventure' under Linux? Compiling went ok, but running gave an error about not finding the verb 'abcde' or similar. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Infocom Games (Was: long list of give away or orphaned packages)
Ben Pfaff wrote: > Just butting in on this thread to ask a question. Is there a > de-compiler for Infocom games? Would such a de-compiler produce > readable source code? Just a thought... (I know nothing about the > Infocom game language or the binary format.) Check out "txd" in the ztools package. It and all sorts of other cool infocom and adventure-related stuff can be found at the if-archive. ftp://ftp.gmd.de/if-archive/ --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
Guy Maor wrote: > I think the only optimization gcc 2.7.* does for i486 is instruction > alignment. The Pentium has a better fetch unit so doesn't need any > alignment (it never incurs a misfetch penalty) so optimizing for i486 > will at least give some code bloat. I think it also chooses some instructions differently for a 486, and these choices are also good on the pentium. That's why, when building binaries for my use, I use -m486 but add flags which turn off the alignment. > I don't think it does any optimization at all for pentium. True. 2.8 will have some stuff from pgcc, but not everything. --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
Mark Eichin wrote: > > yeah, cygwin32.dll is under the GPL. So? It's a DLL, like libc5 and > libc6 are... [the *only* thing I'm aware of that actually uses the > LGPL is libg++; it was as much of an experiment as anything, and I'm > not aware of any not-otherwise-free software taking advantage of those > terms...] Just because libgcc is on "special" terms is no reason for > cygwin32.dll to be (cygwin32 is *more* than even a libc, it's got a > fair amount of emulation code in it, so it looks like you have unified > file descriptors... and you don't want to look at the internals of > select...] My understanding was that if a shared library is GPL'd rather than LGPL'd, linking commercial programs against it is illegal unless you provide source. The LGPL removes that restriction, and that's why glibc (as well as libg++) uses the LGPL. Please correct me if I'm wrong, though. --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cygwin.dll license (was Re: FreeQt ?)
> I just brought this up, since it was my understanding that if you > want to write a commercial program (ie. not under the GPL), and > link it against cygwin.dll, you've got to pay Cygnus $$$. Not all > that different than the restrictions on Qt, really. Two questions: (1) in what way is cygwin32.dll different from libc5.so in this regard (since the license for both is the same: GPL) (2) the discussion wasn't writing *comercial* software with anything, but writing *free* software with a pseudo-free package like Qt... so how did we get here? There's *certainly* no problem writing gpl'ed software with cygwin32.dll :-) [I'm not representing Cygnus in this; though I've used and hacked on cygwin32, all of my current Cygnus work [Kerberos in particular] is under an X11-style license, though Federal Regulations make it "difficult" to redistribute...] ps. A friend of mine with whom I've been discussing this says that if we took all the time we've spent flaming about this and actually *wrote some code* we wouldn't have the problem in the first place :-) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cygwin.dll license (was Re: FreeQt ?)
Mark Eichin wrote: > > > I just brought this up, since it was my understanding that if you > > want to write a commercial program (ie. not under the GPL), and > > link it against cygwin.dll, you've got to pay Cygnus $$$. Not all > > that different than the restrictions on Qt, really. > > Two questions: (1) in what way is cygwin32.dll different from libc5.so > in this regard (since the license for both is the same: GPL) I believe libc5.so is LGPL... --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
On Sun, 1 Jun 1997, Raul Miller wrote: > > On 1 Jun 1997, Mark Eichin wrote: > > > actually, a lot of us find the sound driver stuff objectionable too > > > (because it leaves us with practically useless sound code, almost > > > enough to drive one to NetBSD :-) I still don't have any way to use > > > *both* ESS1688's in my laptop (when docked), which should be *trivial* > > > if the module took arguments like every other module in the > ... > > > laptop... and didn't realize until now just how bad it was... > > On May 31, Jason Gunthorpe wrote > > Yeah, I found it equally objectionable when I was reading it over, > > considering a few other things I'm -VERY- surprised it is in the kernel at > > all. > > I'm puzzled. > > I just looked over the sound driver source code and didn't see anything > but GPL licenses in there. The source in the kernel is GPL, however my understanding is that the Commercial version is not GPL (I'm not totally sure). The GPL version is generated from the commercial version by removing things. So, if I go and fiddle it and then send them my patches they would really like to put them into the commercial version so they don't have to do any work ;> Of course if I GPL my patches then they cannot do this. If my patches are very complex then they also may not want to spend the time to integrate it. All in all it really looks like the code is GPL but the development is closed. I could be wrong, that was my impression from their web pages when I looked a few months back. Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cygwin.dll license (was Re: FreeQt ?)
> I believe libc5.so is LGPL... I don't. /usr/doc/libc5//copyright doesn't *mention* the LGPL *at all*, though the libc6 one mentions both. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
On Sun, 1 Jun 1997, Jason Gunthorpe wrote: > Of course if I GPL my patches then they cannot do this. If my patches are > very complex then they also may not want to spend the time to integrate > it. All in all it really looks like the code is GPL but the development is > closed. Has anyone actually tried writing a patch to make the sound driver accept boot arguments from LILO and mailed it to the people who make OSS/OSS-Lite? -douglas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On 1 Jun 1997, Kai Henningsen wrote: > [EMAIL PROTECTED] (Galen Hazelwood) wrote on 31.05.97 in <[EMAIL PROTECTED]>: > > > Christian Schwarz wrote: > > > > > > On Thu, 29 May 1997, Galen Hazelwood wrote: > > > > (Don't ask me what the historical reasons are, though. I might start to > > > > whimper...) > > > > > > Sorry, but I couldn't resist :-) What are the reasons? > > > > I don't know. That's why I whimper... > > > > > If we make this policy, we should have some real arguments for it! Since > > > we use "i386" in all our file names and since Debian actually runs on > > > 386SX and higher I don't see why we should label this "i486". > > > > Perhaps. Anybody have any serious arguments? I think the reason we > > configure gcc as i486 is so it automatically optimizes for the 486; it's > > a good middle ground. > > That may be the reason that Linux gcc is usually configured that way. > > The reason Debian does it, AFAIR, is simply to be compatible with most of > the Linux world. Where is the arch specification string used, i.e. what will break if we change it to be "i386-linux" on intel systems? Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- "DIE ENTE BLEIBT DRAUSSEN!" -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cygwin.dll license (was Re: FreeQt ?)
On 1 Jun 1997, Mark Eichin wrote: > > I believe libc5.so is LGPL... > > I don't. /usr/doc/libc5//copyright doesn't *mention* the LGPL *at > all*, though the libc6 one mentions both. Yep, the copyright file does not mention the LGPL at all. This seems to me to be very limiting of commercial software running on linux. >From the GPL section 2: These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. I don't know what to make of that, it sounds like the binary has to be 'free'? Which would in turn mean all debian programs are 'free'? Bah, I have got to quit reading this GPL! Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On Sun, 1 Jun 1997, Galen Hazelwood wrote: > Raul Miller wrote: > > > > On May 31, Galen Hazelwood wrote > > > Perhaps. Anybody have any serious arguments? I think the reason we > > > configure gcc as i486 is so it automatically optimizes for the 486; it's > > > a good middle ground. > > > > If I remember right, configuring for pentium leaves an executable > > that might not run on 386 or 486. > > > > If gcc actually _did_ any pentium optimizations, that might be true. > Unfortunately, we don't get that until 2.8. (still waiting...) On every compiler I have used they don't actually use pentium instructions. The optimization is soley from choosing order and instructions based on clock cycle considerations and with pentiums, pipelining too. So code optimized for the pentium will run on a 386, but the timings will not be as good for code optimized for the 386. Now, if GCC is weird and decided to use 486, P5 or P6 specific instructions (are there any new general use ones in the P5?) then this might be a problem. BTW, anyone know when 2.8 is due? Jason -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cygwin.dll license (was Re: FreeQt ?)
> Two questions: (1) in what way is cygwin32.dll different from libc5.so > in this regard (since the license for both is the same: GPL) libc5 appears to be under the GPL, while libc6 appears to be under the LGPL. Weird. Does that mean that anything that is linked against libc5 has to be GPL'd? I'm surprised I haven't heard more about this - I obviously don't know the whole story. Maybe there is just widespread abuse of the GPL. If everyone is just ignoring it, that doesn't provide much legal protection for Cygnus if they're trying to make money off of cygwin.dll. > (2) the discussion wasn't writing *comercial* software with > anything, but writing *free* software with a pseudo-free package like > Qt... so how did we get here? There's *certainly* no problem writing > gpl'ed software with cygwin32.dll :-) There's not really any problem writing *free* software with Qt either. That's why I deliberately confused them together... Free software shouldn't be about confusion. > ps. A friend of mine with whom I've been discussing this says that > if we took all the time we've spent flaming about this and actually > *wrote some code* we wouldn't have the problem in the first place :-) I am working with cygwin.dll right now actually, trying to get dpkg to port to it (well, trying to hack it so I can get Perl to go, so then I can attempt to build dpkg). Klee is going to update the cross-compiler to assist me. Hopefully, cygwin.dll can become a part of the Debian distribution for a Win32 port, playing the same role as the Linux kernel. But it would be a shame if we have to reclassify the copyrights on every package in the distribution (and prohibit non-free stuff) just because of it. Cheers, - Jim pgpyPc6e7CsBE.pgp Description: PGP signature
ttys, setuid & security...
Has any of you had a look at this: ftp://sunsite.unc.edu/pub/Linux/Incoming/pttyd-0.9.tgz [its LSM file says: Description:The Pseudo-tty Daemon. Changes ownership on the slave pseudo-tty's in an appropriate manner, mainaining security without a suid root screen, xterm, or rxvt. ] Maybe we should consider packaging this, it will allow to remove the setuid bit of some programs like xterm, rxvt, ... Opinions? -- - ** Linux ** +---+ ** WAW ** - - [EMAIL PROTECTED] | RENARDIAS Vincent | [EMAIL PROTECTED] - - Debian/GNU Linux +---+ http://www.waw.com/ - - http://www.debian.org/ |WAW (33) 4 91 81 21 45 - --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On 1 Jun 1997, Guy Maor wrote: > Galen Hazelwood <[EMAIL PROTECTED]> writes: > > > Perhaps. Anybody have any serious arguments? I think the reason we > > configure gcc as i486 is so it automatically optimizes for the 486; it's > > a good middle ground. > > I think the only optimization gcc 2.7.* does for i486 is instruction > alignment. The Pentium has a better fetch unit so doesn't need any > alignment (it never incurs a misfetch penalty) so optimizing for i486 > will at least give some code bloat. > > I don't think it does any optimization at all for pentium. No not in 2.7.x, but there are noticable differences for P5 and P6 in gcc 2.8. Mike -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
On Jun 1, Kai Henningsen wrote: > 2. We need a general system administration tool. Lots of other Unix and >Unix-like Systems already have those, with varying quality. This thing >should ideally be able to configure everything that is globally >configurable on a Debian system, probably via modules provided by the >packages, and be able to run in text mode, under X, and via the web. >And it should not change the format of the configuration info, so >people can avoid it alltogether, and can exchange configuration files >with other systems. Can't we use something like our current menu system? The pdmenu package could be a good starting point for a sysadmin tool. Thanks, Peter -- Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02 04 62 89 6C 2F DD F1 3C -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FreeQt ?
Raul said: > > On Jun 1, Leland Olds wrote > > "free" means different things to different people. Personally, I like > > the Debian/Gnu definition. But if someone else uses it in another way, > > that doesn't mean that they are scammers and are trying to mislead us. > > Um... in principle. On the other hand, that doesn't mean that all > uses are ethical. > > But calling Qt a Scam is a bit strong. I think they make it clear that > > they want to make money selling their product. I think it is also clear > > that they want to use their "Free-Software" License to encourage people > > to use and learn their product so they can sell more commercial licenses > > later. > > Calling a commercial product with strong restrictions free software > in misleading, at best. I have not seen Troll Tech do this. They appear to consider things like KDE free software even though it uses Qt. But it's clear from their web pages that they consider Qt to be a commercial product, albeit with a somewhat restrictive cost free license that includes access to the Qt source code for authors of "free software". > I think "scam" is a perfectly adequate way of labeling this kind > of misleading labelling. -- Lee Olds [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
Galen Hazelwood <[EMAIL PROTECTED]> writes: > I think it also chooses some instructions differently for a 486, and > these choices are also good on the pentium. That's why, when building > binaries for my use, I use -m486 but add flags which turn off the > alignment. Right, I had heard that these were reasonably good flags for the pentium: -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cygwin.dll license (was Re: FreeQt ?)
Jason Gunthorpe wrote: > > On 1 Jun 1997, Mark Eichin wrote: > > > > I believe libc5.so is LGPL... > > > > I don't. /usr/doc/libc5//copyright doesn't *mention* the LGPL *at > > all*, though the libc6 one mentions both. > > Yep, the copyright file does not mention the LGPL at all. This seems to me > to be very limiting of commercial software running on linux. I believe that regardless of what our copyright file says, glibc 1.0 (libc5) and 2.0 (libc6) are both LGPL--at least the library parts. Other programs grouped with the libc package are probably GPL. If our copyright file says otherwise, our copyright file is wrong. This should be looked into. I'd grab the source and check myself, but it takes a long time over a 28.8k line. --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
Rob Browning wrote: > > Galen Hazelwood <[EMAIL PROTECTED]> writes: > > > I think it also chooses some instructions differently for a 486, and > > these choices are also good on the pentium. That's why, when building > > binaries for my use, I use -m486 but add flags which turn off the > > alignment. > > Right, I had heard that these were reasonably good flags for the pentium: > > -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 > Those are my personal favorites, at least. Best we can do until 2.8. --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cygwin.dll license (was Re: FreeQt ?)
[EMAIL PROTECTED] (Jason Gunthorpe) wrote on 01.06.97 in <[EMAIL PROTECTED]>: > On 1 Jun 1997, Mark Eichin wrote: > > > > I believe libc5.so is LGPL... > > > > I don't. /usr/doc/libc5//copyright doesn't *mention* the LGPL *at > > all*, though the libc6 one mentions both. > > Yep, the copyright file does not mention the LGPL at all. This seems to me > to be very limiting of commercial software running on linux. Yes, very limiting. The code actually cannot be linked statically! What a tragedy ... NOT. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
[EMAIL PROTECTED] (Christian Schwarz) wrote on 01.06.97 in <[EMAIL PROTECTED]>: > Where is the arch specification string used, i.e. what will break if we > change it to be "i386-linux" on intel systems? I'm not competent enough to answer this. Anything tightly integrated with gcc, but is there anything that doesn't break already when the version numbers don't match exactly? MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cygwin.dll license (was Re: FreeQt ?)
> Yes, very limiting. The code actually cannot be linked statically! Can't be linked dynamically either... read the GPL. Cheers, - Jim pgp6b75kk1gUm.pgp Description: PGP signature
