Aladdin Ghostscript
Bruce, what do you think of the following? It has to do with including the latest Aladdin Ghostscript with debian... The first was my inquiry, the second was the response. Would you like to respond personally, or go through me? If it turns out positively, I will undertake to debianize the ghostscript system. -Andrew. <[EMAIL PROTECTED]> ===8<- >From adfernan Thu Feb 7 03:52:36 2036 To: [EMAIL PROTECTED] Subject: CDROM license Status: RO Hello, I have a question regarding the Aladdin Ghostscript Public License. It seems that you allow distribution on CDROM as long as (a) the sources are distributed verbatim with the program and (b) the cdrom is a freely redistributable for non-commercial use software compendium. Is this correct? If so, I am requesting clarification regarding part (a). I am making this inquiry on behalf of the GNU/Debian Linux developer network. You may not be aware that the "Debian" distribution of Linux is the FSF's "official" distribution of linux. It was created to ease the general pain of having to constantly incrementally upgrade the system software, and it does this by a generalized "package" system. Executables, documentation, copyright information, and configuration files are packaged up into a format that allows for quick and easy installation, setup, and possibly for eventual removal and/or upgrading. As part of the GNU philosophy, Source code for everything *must* be available with a generalized makefile that can build the binary distribution and "package" it, or build the sourcefile distribution (a standard tar.gz of the directory). Here is the problem. Does adding the makefile and a few information files constitute a violation of the AGPL? Quite literally, the modifications to the GS sources would be nothing more than adding a set of configuration files to the GS distribution. This can even be done in a very clear manner, such as having the Debian-specific files in the current directory and the pristene GS sources in a subdirectory. Just to make it clear: binaries and the sources to build those binaries would be distributed together on a cdrom that contained (as far as I know, and this can be verified) only freely-redistributable-for-non-commercial use software. Can I have your comments on this? Thank you, -Andrew D. Fernandes <[EMAIL PROTECTED]> =8<- >From [EMAIL PROTECTED] Tue Oct 24 17:40:44 1995 Return-Path: [EMAIL PROTECTED] Received: from sun13.cs.wisc.edu (sun13.cs.wisc.edu [128.105.40.13]) by hank.cnd.mcgill.ca (8.6.9/8.6.9) with SMTP id RAA12286 for <[EMAIL PROTECTED]>; Tue, 24 Oct 1995 17:40:44 -0400 Date: Tue, 24 Oct 95 16:38:42 -0500 Message-Id: <[EMAIL PROTECTED]> Received: by sun13.cs.wisc.edu; Tue, 24 Oct 95 16:38:42 -0500 From: "L. Peter Deutsch" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] In-Reply-To: <[EMAIL PROTECTED]> ([EMAIL PROTECTED]) Subject: Re: CDROM license Status: RO Hello. Thanks for your inquiry. I'm sure you appreciate that the AGFPL is *not* the GNU License, and that I don't subscribe to the GNU approach unqualifiedly. The AGFPL deliberately draws the line for free distribution in a slightly more restrictive place than the GPL. > It seems that you allow distribution on CDROM as long as (a) the sources > are distributed verbatim with the program and (b) the cdrom is a freely > redistributable for non-commercial use software compendium. Is this correct? Yes. (That's just a paraphrase from the AGFPL.) > Here is the problem. Does adding the makefile and a few information files > constitute a violation of the AGPL? No. In general, I don't consider *addition* of files to violate the "verbatim" nature of the distribution, especially if, as you propose, the Debian-specific files are put in a separate directory. As it happens, I have already been considering switching from the Yggdrasil to the Debian Linux distribution for my own use. Yggdrasil insists on GNU-licensing, so they refuse to include Aladdin Ghostscript on their CD-ROMs (and also refuse to include kermit), and I have also been less than impressed with the quality of some of the less central code (e.g., UUCP). Would it be possible for me to get a free copy of the Debian distribution on the basis of my Ghostscript work? L. Peter Deutsch [EMAIL PROTECTED]
Re: Source packages
> > I propose that Debian source packages be constructed this way: > > The source package "hello.dsr" is a compressed tar archive containing > four files. I like this, but perhaps there should be two DELTA files, or one DELTA file with the patch program taking arguments... remember some patches will be debian-specific-platform-independent, while other patches will be debian-independent-platform-specific. We *do* hope to get debian ready for alphas and powerpcs some time in the far future... :-) -Andrew. <[EMAIL PROTECTED]>
packaging X things
Perhaps those with experience can help me with this... I am in the process of packaging up x3270 for debian, and while I have built X-stuff via imake before, I have never had to modify things. Until now. Is there an easy way of modifying the (i)makefiles to install the software in a non-root subdirectory, but make sure that these paths don't get compiled into the program, or am I going to have to bite the bullet and comb the source by hand and by grep? -Andrew. <[EMAIL PROTECTED]>
sbpcd module init
Ian, Of course, your problem was with the loadable kernel module... so much for "think first, post later..." Anyway, here is the answer you want. From the 1.2.13 README.sbpcd in the "drivers" directory... = Using sbpcd as a "loadable module": --- If you do NOT select "Matsushita/Panasonic CDROM driver support" during the "make config" of your kernel, you can build the "loadable module" sbpcd.o. Read /usr/src/linux/README.modules on this. If sbpcd gets used as a module, the support of more than one interface card (i.e. drives 4...15) is disabled. You can specify interface address and type with the "insmod" command like: # insmod /usr/src/linux/modules/sbpcd.o sbpcd=0x340,0 or # insmod /usr/src/linux/modules/sbpcd.o sbpcd=0x230,1 where the last number represents the SBPRO setting (no strings allowed here). = Note the number coming after the address argument is defined in sbpcd.h... for a soundblaster, as it says, the value should be one. Lastly, I presume (but have not tried) using arguments in the /etc/modules file. If it won't take them, it should only be a bit of tweaking to get it to go. It *should* allow the modules to take arguments... -Andrew. <[EMAIL PROTECTED]>
e2fsprogs-dif
I have uploaded the context diff for e2fsprogs-1.01-1.diff.gz to ftp.debian.org: 89d24e4bedccc995314c18fe2bcc4af2 e2fsprogs-1.01-1.diff.gz Note that I accidentally uploaded the same file as e2fsprogs-1.01.diff.gz: that file should be deleted. -Andrew.
Bug#1851: gopher-client-2.1.1 has quotes around version and revision numbers
Package: gopher-client Version: 2.1.1-2 [Gothe:652]$ dpkg --info gopher-client-2.1.1-2.deb old debian package, version 0.939000. size 95170 bytes: control archive= 348, main archive= 94809. 36 bytes, 2 lines conffiles 215 bytes, 7 lines control PACKAGE: gopher-client VERSION: "2.1.1" PACKAGE_REVISION: "2" MAINTAINER: Ted Hajek <[EMAIL PROTECTED]> DESCRIPTION: Client software to access stuff on gopher servers. Gopher+ aware. DEPENDS: netbase -Andrew. <[EMAIL PROTECTED]>
Bug#1849: includes,source do not conflict
Package: includes Version: 1.2.13-5 includes should conflict with source -Andrew. <[EMAIL PROTECTED]>
Bug#1850: includes,source do not conflict
Package: source Version: 1.2.13-5 includes should conflict with source -Andrew. <[EMAIL PROTECTED]>
Re: md5sum passwords
> A mixed solution may be possible, supplying DES (from both a US and a > non-US site) to those who require YP support. I'm still not in favor > of Debian doing this alone in the Linux community, though. Yep, another "me too" reply... I see quite often, like here at McGill University, what you get quite often are mixtures of older machines (suns, sgi, etc) and a few people running linux boxes and wanting to network. Try telling people that you can't interoperate a linux box on the net, and you seriously damage linux's credibility. Also, when it comes to the fixed vs. variable length password issue, I think compatability should be the key focus, not security. Why? Well, at an 8 character limit, if we use upper/lower case letters, numbers, and just a few symbols, we get at *least* 64 possible characters per password position -> at *least* 6 bits of entropy per character -> at least 48 bits per password. That's plenty for most installations. Longer passwords, while they may preclude compatablility with other systems, are no excuse for not choosing good passwords: "I love Francesca" may have more than 8 characters, but it certainly is not more secure than "R8#cjs;)". There are plenty of references on how to pick good passwords in 8 characters. Just my 0.02$, -Andrew. <[EMAIL PROTECTED]>
e2fsprogs-1.01
I just thought I'd notify people that I will be uploading a new version of the e2fsprogs in the next day or so that incorporate the changes suggested by Rolf . I've been a bit too busy for it yet... -Andrew. <[EMAIL PROTECTED]>
Re: Bug#1896: fsck won't go because of elf?
> During boot up the harddisk is checked before the modules (binfmt_elf) > are loaded. The fsck/e2fsck utility is elf dependend but can't run > without the module being loaded. Ah! Good point. Ok, guys... how to handle this? I have recompiled elf support directly into the kernel (seeing as how the move is on the way!) but I can see where this problem comes in from. The trouble is, I don't know how to specify a dependency like this. So, since the elf move is on, do we assume that elf support must be compiled in the kernel? -Andrew. <[EMAIL PROTECTED]>
Bug#1896: fsck won't go because of elf?
done
Re: inline-math-1.7 (fwd)
> Version 1.7 of inline-math has been uploaded to sunsite: > /pub/Linux/libs/inline-math-1.7.tar.gz. I think that these would be a *great* thing to include in debian. Having a good, solid linux release (debian) with *good* math libs will encourage commercial developers to build mathematical software for linux. -Andrew. <[EMAIL PROTECTED]>
