Re: Debian's "Modify & Redistribute" Policy
[EMAIL PROTECTED] (Brian White) wrote on 04.06.97 in <[EMAIL PROTECTED]>: > > > That depends on how you look at it. > > > > > > If the author does not do significant maintenence or has abandoned the > > > package then this is true. > > > > What if the author doesn't want you to do ports? We have one case of > > this already. We also have some cases of "author rudely dropped dead > > without first changing the copyright". > > This is a problem, I admit. What does the law say about copyrighted works > when the copyright holder dies? He/she presumably has heirs. They inherit this, too. Book copyrights (at least the Berne kind) stop after 70 years, AFAIR. That means the electronic text people are looking for works written 1927 or before. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
Andreas Jellinghaus <[EMAIL PROTECTED]> writes: > i'm missing the same thing: debian should have a database with error > reports and how to fix them. every big bug should be documented (we had > this bud , and you can solve it this way : . it's > also fixed in the new release debian and in the package xyz > ."). Perhaps this is something that gnats can be used for. I know FreeBSD is using gnats in this way. -- 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] .
Re: Debian's "Modify & Redistribute" Policy
Brian White <[EMAIL PROTECTED]> writes: > But your promise in not the point. The author wants this promise > from everybody. It's the best way to be assured that improvements > get distributed to everyone and not just a select group. What if the author decides to not accept a change? Say the author considers the intent of the change repugnant and simply will not accept patches, even if it's runtime configurable and defaults to off. (I'm thinking along the lines of adding MIME capabilities to a mailer written by Tom Christiansen :-) This is perfectly within the author's rights, and it would be unethical if not illegal for us to violate the authors wishes. If the license permits redistribution of modified binaries, then if our user base asks/demands that this feature be included, then we're able to keep our users happy. If not, we have a lot of users recompiling from source which largely defeats the purpose of having a binary distribution. And this isn't hypothetical, either; qmail is in this situation: in order to be compatible with Debian's locking scheme, one must apply the patches for .lock support, which Dan Bernstein has, I believe, declared will never go into the core. Mike. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> Regarding the assignment of copyright, I took that out of the draft > document. Yay! I knew you were a good guy! :-) Cheers, - Jim pgptBXGtMKzg2.pgp Description: PGP signature
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
Regarding the assignment of copyright, I took that out of the draft document. I think that every good license should include the provision that modifications must have the same license as the original software, not a more restrictive license, applied to them. The GPL includes something like this, as does the Artistic license. Thanks 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: top and window resizing
On Wed, 4 Jun 1997, Sam Ockman wrote: | Sure... | | Start with an 80x24 xterm... | | Run top...everything works fine... yes | Grab corner...expand to 80x32...everything still works...number of lines | shown expands... yes | Grab corner...expand to 90x32length of lines shown stays 80 (but | note...if I restart and expand from 80 to 90 as my first operation, the | line expands on any subsequent expansion of xterm, line lengths stay the | same...) yes | Go from 90x32 to 90x25...works okay... No. It starts at the top, and outputs (I assume) 32 lines, scrolling the top of top, as it were, out of the window. | Expand back to 90x32first shows a few lines from scroll back buffer, | then redraws and shows 25 lines only. | | Anyone else able to reproduce this behavior? I get the same behaviour with rxvt as well. | top -v says procps version 1.11 ~$ top -v procps version 1.11 | dpkg -l on procps says 1.11.6 ii procps 1.11.6 The /proc file system utilities. Is it possible that it is a bug in rxvt or xterm? Seems dubious, but I surely don't know. David Welton [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.efn.org/~davidw Se quest'email e` in Italiano, mi dispiace per gli errori:-) FORZA PANTANI! --Debian GNU/Linux-- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
Brian White <[EMAIL PROTECTED]> writes: > > What if the author doesn't want you to do ports? We have one case of > > this already. We also have some cases of "author rudely dropped dead > > without first changing the copyright". > > This is a problem, I admit. What does the law say about copyrighted works > when the copyright holder dies? I believe that he may have meant this in a figurative sense. If an author simply disappears from the net and there is no way to get in contact with him (her) then we're out of luck, because there is no way to get the copyright changed. -- 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: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> Well, it's fine for the author to _require_ that modifications in the > program be returned to the author. It's just not acceptable for the > author to not allow modifications to be distributed. I don't think we should accept licenses that require modifications to be returned to the author, or require assigning the copyright for modifications to the license holder. That's my (strong) opinion. There needs to be more debate. Cheers, - Jim pgpkkuccPIOcW.pgp Description: PGP signature
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
From: Brian White <[EMAIL PROTECTED]> > But your promise in not the point. The author wants this promise from > everybody. It's the best way to be assured that improvements get > distributed to everyone and not just a select group. Well, it's fine for the author to _require_ that modifications in the program be returned to the author. It's just not acceptable for the author to not allow modifications to be distributed. 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: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> > That depends on how you look at it. > > > > If the author does not do significant maintenence or has abandoned the > > package then this is true. > > What if the author doesn't want you to do ports? We have one case of > this already. We also have some cases of "author rudely dropped dead > without first changing the copyright". This is a problem, I admit. What does the law say about copyrighted works when the copyright holder dies? > > On the other hand, if the author is active, then forcing changes to go > > back through the orgininal author means that fixes and improvements don't > > get limited to a small subset of the user community. In this way, the > > restriction actually _improves_ the overall quality of the product for > > everyone. > > I think that feeding changes back to the author is a separate issue, and > one that we've already promised to do. But your promise in not the point. The author wants this promise from everybody. It's the best way to be assured that improvements get distributed to everyone and not just a select group. Brian ( [EMAIL PROTECTED] ) --- Seize the moment! Live now. Make "now" always the most important time. -- JLP -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
From: Brian White <[EMAIL PROTECTED]> > That depends on how you look at it. > > If the author does not do significant maintenence or has abandoned the > package then this is true. What if the author doesn't want you to do ports? We have one case of this already. We also have some cases of "author rudely dropped dead without first changing the copyright". > On the other hand, if the author is active, then forcing changes to go > back through the orgininal author means that fixes and improvements don't > get limited to a small subset of the user community. In this way, the > restriction actually _improves_ the overall quality of the product for > everyone. I think that feeding changes back to the author is a separate issue, and one that we've already promised to do. 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: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> > I agree with you on this. I personally believe that Debian should relax > > this requirement about non-modifiable & redistributable code not being > > suitable for the primary distribution. I've never seen how it helps any > > cause other than sticking a finger in the eye of those who might like > > to keep some medium of control over their work. > > We can't allow it because it prohibits ports, and it prohibits bug-fixes. That depends on how you look at it. If the author does not do significant maintenence or has abandoned the package then this is true. On the other hand, if the author is active, then forcing changes to go back through the orgininal author means that fixes and improvements don't get limited to a small subset of the user community. In this way, the restriction actually _improves_ the overall quality of the product for everyone. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: S-Lang for use with libc6 uploaded (source, i386)
On Jun 4, joost witteveen wrote > > Because the current slang0.99.34 and slang0.99.34-dev packages are > > implicitly for libc5, we can't "re-use" them and therefore need to use > > new package names for the new libc6 versions. I've been recommending > > people simply append a "g" to the package names in these cases to > > identify them as being for glibc/libc6. The new packages might then > > be slang0.99.34g and slang0.99.34g-dev. > > With libg++, I noticed that the upstream, version, patched by > HJ Lu for glibc, had a new soname (it's 272 now, was 27). So, I called H.J. probably did this so it wouldn't conflict. > the glibc compiled libg++ package "libg++272" (libc5: libg++27). > Do you think this was a good idea? If not, should I change it to This is fine. The bit about appending a "g" to package names and moving old libraries to libc5-compat is only needed when the sonames conflict. > libg++272g? (even though some packages already may depend on libg++272, > I don't know). No, you don't have to change it. > > First, the libraries can't be in the same directory as each other. To > > solve this problem, the current libc5 package provides two new > > directories, /lib/libc5-compat and /usr/lib/libc5-compat. These can > > be used to put old libc5-based libraries which conflict with new > > libc6-based ones. > > So, that means my libg++27 package (the old one) should be updated > to put it's shared libs in /usr/libc5-compat, right? At the moment, > it doesn't do so, but I don't have problems with that -- probably > because of the different sonames I'm using. Should I still put the > libc5-compat stuff in the right place? You can, but you don't have to. > > Second, the dynamic linkers need to be able to determine which > > libraries are for libc5 and which are for libc6. To facilitate this, > > each library must contain a run-time dependency on at least one of > > libc, libm and libdl. > > $ ldd /usr/lib/libg++.so.272.5.0 > libstdc++.so.272 => /usr/lib/libg++-dbg/libstdc++.so.272 (0x4003c000) > > So, I'm wrong here too? Does that mean I didn't have the same libc6-dev > version installed as libc6 version? If I recompile libg++272 now, will > it be fixed (I've got it correct now, I *though* I had it correct at > the time too). Did I do something else wrong? (And, why don't I notice > any problems -- well never mind, that must be because ldso is so clever). Again, since you used a non-conflicting soname, you don't strictly have to do this. Doing it anyway would still be a good idea though. We need to get people in the habit of doing it. The way to get the dependency included in the shared library is to link it with "-lc", "-lm" and/or "-ldl" when building it. For example, for a hypothetical libfoo, you would do: gcc -shared -o libfoo.so.1.0 -Wl,-soname,libfoo.so.1 foo.o -lc David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
1.3 release
The mirror on llug.sep.bnl.gov is almost caught up to master. However, master is not accepting ftp connections at this time... :( Happy release! :) Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps "Very Pete Townshendish." "Who?" "Exactly." -- Anon ** 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: 1.3 installation report
correct analysis except: > As it happens xdm-shadow works fine on non-shadow systems, so I believe the > maintainer has (or is about to) uploaded a copy where xdm and xdm-shadow are > the same (shadow enabled) binary. Not uploaded yet -- it's just one of the things I'll be sure the 3.3 upload gets right, but 3.3 isn't on the ftp site yet... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: top and window resizing
Message from Helmut Geyer ([EMAIL PROTECTED]) on 6-4-97: > Sam Ockman <[EMAIL PROTECTED]> wrote (in the thread on ncurses): > > >: Now that I think about it, the program "top" is another offender that it > >: would be nice to figure out someway to make it so the xterm-window can > >: resize it.) > > Well, it surely works for me (I wrote most of the currently used code > in top). top does a resize when it gets a SIGWINCH, which is what > xterm should send to it via the shell. > Could you please specify your problems? Sure... Start with an 80x24 xterm... Run top...everything works fine... Grab corner...expand to 80x32...everything still works...number of lines shown expands... Grab corner...expand to 90x32length of lines shown stays 80 (but note...if I restart and expand from 80 to 90 as my first operation, the line expands on any subsequent expansion of xterm, line lengths stay the same...) Go from 90x32 to 90x25...works okay... Expand back to 90x32first shows a few lines from scroll back buffer, then redraws and shows 25 lines only. Anyone else able to reproduce this behavior? top -v says procps version 1.11 dpkg -l on procps says 1.11.6 Thanks, Sam -- VA Research Linux Workstations| The World's Best Linux Workstations | Featuring RedHat http://www.varesearch.com | Now offering VarStation II Systems Sam Ockman - (415)934-3666, ext. 133 | Based on the Intel Pentium II -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
In your email to me, Andreas Jellinghaus, you wrote: > > On Jun 3, Jim Pick wrote > > This flaw needs to be publicized a bit more. I'm sure I would have > > figured out the problem via the bug system eventually - but I shouldn't > > have to do that. > > > > Is there a document where "Errata" can go? How about a release-specific > > FAQ that we can update after 1.3 has been release? I can think of > > a number of questions that could go onto it. This could be prominently > > featured on the web site and the ftp server. > > i'm missing the same thing: debian should have a database with error > reports and how to fix them. every big bug should be documented (we had > this bud , and you can solve it this way : . it's > also fixed in the new release debian and in the package xyz > ."). > > look at other distributions : they have support databases (www.suse.de, > maybe also www.suse.com and other distributions). the bug archive is ok > for us developers, but after a bug is closed, it wouldn't help. and a > user should not have to read the whole discussion, he only needs the bug > description and the solution to solve it. Matt Surico and I have been slowly (very) developing a call/problem tracking system/knowledge base system. Maybe we need to make it speed up a little more... Tim -- (work) [EMAIL PROTECTED] / (home) [EMAIL PROTECTED] - http://www.buoy.com/~tps "The squeaky wheel gets the grease, but gets changed at the next opportunity if it squeaks habitually." ** 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: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
From: Tomislav Vujec <[EMAIL PROTECTED]> > But, do we realy distribute modified versions? We distribute modified binary files. I've asked for an explicit permission in the ncurses license that is something like paragraph 1 in our free software guidelines, and Eric seems to be agreeable with that. Thanks 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: deleting binary soft link on ftp sites
-BEGIN PGP SIGNED MESSAGE- About the link binary -> binary-i386: On Wed, 4 Jun 1997, Charles Briscoe-Smith wrote: > >Very old versions of dselect use it. It's meant for backwards > >compatibility. > > Are these the same versions which have problems with Packages files > with epochs in them? If so, might removing these links help avoid > problems, by forcing them to install the latest dpkg by hand? Very good idea! -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBM5WKaSqK7IlOjMLFAQEk+QP/SbXErA35vm2Z8sWwWWOg3X+bYNwpo3Pf cbOgv9ksReE8KcQZ8CbpJPQvXJOajLfj7u1lKRGHeuccm0b1BOL8CrL3nfUiGsbV xeRYp3TaFPufKJXFr8H2uR0wo82u7GIpYUtLpyJebBxCOdXzMoLuTv4le+WNlPm+ VCXGvZVNYCg= =0naR -END PGP SIGNATURE- Santiago Vila <[EMAIL PROTECTED]> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Possible Xaw{3d,95} bug / Re: Debian freeciv bugs
> [EMAIL PROTECTED] (joost witteveen) writes: > > > One possible solution is to link Xaw statically in the freeciv binary. > > That's what I do with aXe. > > Or you can just use -rpath when you compile to force it to use a > particular dynamically linked libXa*. I think that was the solution > used in gv. Yeah, sorry. There goes another release of aXe! Thanks, -- 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: Possible Xaw{3d,95} bug / Re: Debian freeciv bugs
[EMAIL PROTECTED] (joost witteveen) writes: > One possible solution is to link Xaw statically in the freeciv binary. > That's what I do with aXe. Or you can just use -rpath when you compile to force it to use a particular dynamically linked libXa*. I think that was the solution used in gv. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: S-Lang for use with libc6 uploaded (source, i386)
> I'm replying to this on debian-devel since many developers are > probably still not clear on the issues that come up when converting to > libc6. Thanks, it's good to read this! > > On Jun 4, J.H.M. Dassen wrote > >* Non-maintainer release (OK-ed by Chris); slang should now be usable > > with libc6. [...] > Ray, converting a library to libc6 is not this simple. Only the most > trivial of libraries can actually be built to work both libc5 and > libc6 at the same time. Because of this, we need to provide separate > slang libraries for libc5 and libc6. > > Because the current slang0.99.34 and slang0.99.34-dev packages are > implicitly for libc5, we can't "re-use" them and therefore need to use > new package names for the new libc6 versions. I've been recommending > people simply append a "g" to the package names in these cases to > identify them as being for glibc/libc6. The new packages might then > be slang0.99.34g and slang0.99.34g-dev. With libg++, I noticed that the upstream, version, patched by HJ Lu for glibc, had a new soname (it's 272 now, was 27). So, I called the glibc compiled libg++ package "libg++272" (libc5: libg++27). Do you think this was a good idea? If not, should I change it to libg++272g? (even though some packages already may depend on libg++272, I don't know). > Making separate packages for libc5 and libc6 creates two problems > because both libraries will use the same file names and sonames. > > First, the libraries can't be in the same directory as each other. To > solve this problem, the current libc5 package provides two new > directories, /lib/libc5-compat and /usr/lib/libc5-compat. These can > be used to put old libc5-based libraries which conflict with new > libc6-based ones. So, that means my libg++27 package (the old one) should be updated to put it's shared libs in /usr/libc5-compat, right? At the moment, it doesn't do so, but I don't have problems with that -- probably because of the different sonames I'm using. Should I still put the libc5-compat stuff in the right place? > Second, the dynamic linkers need to be able to determine which > libraries are for libc5 and which are for libc6. To facilitate this, > each library must contain a run-time dependency on at least one of > libc, libm and libdl. $ ldd /usr/lib/libg++.so.272.5.0 libstdc++.so.272 => /usr/lib/libg++-dbg/libstdc++.so.272 (0x4003c000) So, I'm wrong here too? Does that mean I didn't have the same libc6-dev version installed as libc6 version? If I recompile libg++272 now, will it be fixed (I've got it correct now, I *though* I had it correct at the time too). Did I do something else wrong? (And, why don't I notice any problems -- well never mind, that must be because ldso is so clever). $ dpkg -l libc6* ii libc6 2.0.3-4 The GNU C library version 2 (run-time files) ii libc6-dbg 2.0.3-4 The GNU C library version 2 (debugging/profi ii libc6-dev 2.0.3-4 The GNU C library version 2 (development fil ii libc6-doc 2.0.3-4 The GNU C library version 2 (documentation f In short, thanks for the clarification. I hope I didn't mess up too badly with libg++, and I havent had/seen any problems yet from my packages, but with your post, I'm not too sure any more. -- 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: 1.3 installation report
On Jun 3, Jim Pick wrote > This flaw needs to be publicized a bit more. I'm sure I would have > figured out the problem via the bug system eventually - but I shouldn't > have to do that. > > Is there a document where "Errata" can go? How about a release-specific > FAQ that we can update after 1.3 has been release? I can think of > a number of questions that could go onto it. This could be prominently > featured on the web site and the ftp server. i'm missing the same thing: debian should have a database with error reports and how to fix them. every big bug should be documented (we had this bud , and you can solve it this way : . it's also fixed in the new release debian and in the package xyz ."). look at other distributions : they have support databases (www.suse.de, maybe also www.suse.com and other distributions). the bug archive is ok for us developers, but after a bug is closed, it wouldn't help. and a user should not have to read the whole discussion, he only needs the bug description and the solution to solve it. regards, andreas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
hare.sea.ixa.net ???
I keep seeing icmp packets leaving my system, in the `diald` Dctrl packet Q, from "hare.sea.ixa.net", and I don't know what they are from. Any ideas? -- Karl M. Hegbloom <[EMAIL PROTECTED]> http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.3 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: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
[EMAIL PROTECTED] (Bruce Perens) writes: > > I agree with you on this. I personally believe that Debian should relax > > this requirement about non-modifiable & redistributable code not being > > suitable for the primary distribution. I've never seen how it helps any > > cause other than sticking a finger in the eye of those who might like > > to keep some medium of control over their work. > > We can't allow it because it prohibits ports, and it prohibits bug-fixes. But, do we realy distribute modified versions? I think that our source distribution policy (orig, diff and dsc file) keeps source in almost unchanged form, and diffs are distributed separately. Does licence prohibits name change to .orig, and renaming of base directory? If the answer is yes, we can solve both problems with few entries in description file. -- Tomislav Vujec [EMAIL PROTECTED] --- To understand recursion, one must first understand recursion... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: S-Lang for use with libc6 uploaded (source, i386)
I'm replying to this on debian-devel since many developers are probably still not clear on the issues that come up when converting to libc6. On Jun 4, J.H.M. Dassen wrote > Description: > slang0.99.34 - A C programming library for user interfaces - shared library > slang0.99.34-dev - A C programming library for user interfaces - development > kit > Changes: > slang (0.99.38-2.1) unstable; urgency=medium > . >* Non-maintainer release (OK-ed by Chris); slang should now be usable > with libc6. >* Removed dynamic dependency on libc5's libm.so (which caused problems > when linking S-Lang programs against libc6) by changing ELF_LINK in > Makefile.in. >* Replaced -dev package's dependency on "libc5-dev" by "libc-dev". >* Ugly hack (through sed) to prevent libc5 dependency of -dev package > (Depends for -dev package is determined from demo executable "calc", > which is not actually included in the package; the package does not > include anything that is actually depending on libc5.) Ray, converting a library to libc6 is not this simple. Only the most trivial of libraries can actually be built to work both libc5 and libc6 at the same time. Because of this, we need to provide separate slang libraries for libc5 and libc6. Because the current slang0.99.34 and slang0.99.34-dev packages are implicitly for libc5, we can't "re-use" them and therefore need to use new package names for the new libc6 versions. I've been recommending people simply append a "g" to the package names in these cases to identify them as being for glibc/libc6. The new packages might then be slang0.99.34g and slang0.99.34g-dev. Making separate packages for libc5 and libc6 creates two problems because both libraries will use the same file names and sonames. First, the libraries can't be in the same directory as each other. To solve this problem, the current libc5 package provides two new directories, /lib/libc5-compat and /usr/lib/libc5-compat. These can be used to put old libc5-based libraries which conflict with new libc6-based ones. Second, the dynamic linkers need to be able to determine which libraries are for libc5 and which are for libc6. To facilitate this, each library must contain a run-time dependency on at least one of libc, libm and libdl. David -- David EngelODS Networks [EMAIL PROTECTED] 1001 E. Arapaho Road (972) 234-6400 Richardson, TX 75081 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RFC: Splitting manpages into 2 packages
=?iso-8859-1?Q?Nicol=E1s_Lichtmaier?= <[EMAIL PROTECTED]> wrote: > One package with misc/general manpages and another with development >manpages. What do you think? I think that (at least) the "undocumented.?" pages should go in a separate package, or even back into the man-db package. I don't have manpages installed (because they're big), so whenever man regenerates its database, I get warnings about bad symlinks from any packages which use "undocumented". --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GOAL: Consistent Keyboard Configuration
Tom Lees <[EMAIL PROTECTED]> wrote: >Ctrl+PrintScreen (=SysRq) should do a kernel info thing. Have you heard of the GGI project? One of the things they have is a SAK (secure attention key), which is guaranteed to kill all processes running on the current VC. The key they're using at the moment for SAK is SysRq. (The idea is so that you can kill hung X servers and so on, and be sure that you've got a real login prompt, not a spoof.) While GGI isn't in the 'real' kernel yet, and probably won't be ready for a while, it might not be a good idea to assign some other meaning to the key it'll be using... >What about W95 keys (3 of them)? Define as F20 or something? I heard it suggested that someone should get some keytops printed with little penguins and then sell pairs of them to Linux users with Win 95 keyboards... ;-) --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: reboot function
-BEGIN PGP SIGNED MESSAGE- On Wed, 4 Jun 1997, Michael Meskes wrote: > Could anyone tell me where the difference between the linuxlibc1 reboot() > function and the one in glibc is? The prototype has changed dramatically and > I cannot find it in the info files. I believe that the change is documented in the GLIBC FAQ. I believe it was changed to take 1 option, what was formerly the 3rd option to the libc5 reboot, but I haven't used it so check the FAQ first. ++ || Your friends will know you better in the | | Scott K. Ellis | first minute you meet than your acquaintances | | [EMAIL PROTECTED] | will know you in a thousand years.| ||-- Illusions | ++ -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv iQCVAwUBM5VpgKCk2fENdzpVAQEXpwP/fzl7nGTy3K+Ze+PEf9tXrNM4O5ChF57R GC7QwswBknStAoVvLVR+LoiKb1IRHmzMxDe/soydWO/tx6bZjXWwPXJcK/udkove RVMCvAVXwJWhSXALwsrymsxlzOdkFNdAn0XuRsgmZ1HUSuzX04a2qm0dNdo8BW3M WlCOrnPRsK8= =1ONp -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: deleting binary soft link on ftp sites
Guy Maor <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] writes: > >> In anticipation of Debian being released (publically)for platforms >> other than ix86 it would be a good idea to phase out the use of >> the binary -> binary-i386 link on the ftp sites as this could >> cause confusion. Is there anything that actually uses this link? > >Very old versions of dselect use it. It's meant for backwards >compatibility. Are these the same versions which have problems with Packages files with epochs in them? If so, might removing these links help avoid problems, by forcing them to install the latest dpkg by hand? --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
reboot function
Could anyone tell me where the difference between the linuxlibc1 reboot() function and the one in glibc is? The prototype has changed dramatically and I cannot find it in the info files. Michael -- Dr. Michael Meskes, Projekt-Manager | [EMAIL PROTECTED], [EMAIL PROTECTED] topsystem Systemhaus GmbH| Phone: (+49) 2405/4670-44 Europark A2, Adenauerstr. 20 | Fax: (+49) 2405/4670-10 52146 Wuerselen | Go SF 49ers! Use Debian GNU/Linux! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Possible Xaw{3d,95} bug / Re: Debian freeciv bugs
> After extensive testing, some code rewriting, etc., I finally have > determined that this problem only occurs when using Xaw3d or Xaw95. I > am CCing this message to the relevant maintainers. (Xaw maintainers: > package freeciv-1.0j that is in hamm causes coredump under Xaw3d and > Xaw95 but not the standard widget set). One possible solution is to link Xaw statically in the freeciv binary. That's what I do with aXe. -- 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] .
top and window resizing
Sam Ockman <[EMAIL PROTECTED]> wrote (in the thread on ncurses): >: Now that I think about it, the program "top" is another offender that it >: would be nice to figure out someway to make it so the xterm-window can >: resize it.) Well, it surely works for me (I wrote most of the currently used code in top). top does a resize when it gets a SIGWINCH, which is what xterm should send to it via the shell. Could you please specify your problems? Helmut -- Helmut Geyer[EMAIL PROTECTED] public PGP key available : finger [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
-BEGIN PGP SIGNED MESSAGE- Brian White <[EMAIL PROTECTED]> writes: > I agree with you on this. I personally believe that Debian should > relax this requirement about non-modifiable & redistributable code not > being suitable for the primary distribution. I've never seen how it > helps any cause other than sticking a finger in the eye of those who > might like to keep some medium of control over their work. The usual reasons (bug-fixes, porting, adding modified Makefiles, minor changes necessary to integrate a single package into a complete system, etc.) aside, what if an author gets run over by a car? There are "artistic control" measures such as ones adopted by the Perl Artistic License that allow distribution under the Debian policy. Dan -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv iQCVAwUBM5U2EKkybebRDjw1AQGvGgP9Fmnw0DXpqeH+THGhy8hJme6YMl5v+6oS kwip7IkOCwSTZiy9zJfB/34xxCGO/1zbu5BkQ9Dwoi1c6g+rk7BXHV19/T+Z01c7 jJ9lcx+e7yhHXkhltD479ZjXmaOkebHJ0XmzGu2s+XcE9ochXZpICNkFphb1bZfF GW1rzIUat98= =aVb+ -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: the ncurses "brushfire" -- anybody want to take over the project?
Message from Joey Hess ([EMAIL PROTECTED]) on 6-3-97: > Jim Pick: > > dselect (our package selection tool) will have to be rewritten to use > > some other library. This will probably take some time, though. I'm > > not sure how we will resolve having the core of our packaging system > > dependent on a "non-free" package. Maybe we're going to have to > > strip dselect out of the dpkg package, and put it into a separate > > package to go into the "contrib" directory. Ugly. > > Perhaps it can be ported to use slang. Slang has some slcurses.h file that > is supposed to emulate cureses to some degree. This might make a good quick > fix while we're waiting on longer-term things like diety. Even if we decide that ncurses is okay to use, it still would be a good thing to compile dselect with slang curses emulation. This would allow me to resize my terminal window on the fly, rather than attempting to do this, and then having to quit and restart every time. Right now dselect is the only program I use in Debian that runs in a terminal window that can't be on the fly resized (xterm windows mainly) Programs that can be resized include mutt and lynx (slang ncurses emulation...); slrn and jed (slang); less, and xemacs (proprietary stuff I guess...) Anyone know how to do slang curses emulation? My impression is nothing needs to be rewritten...but maybe I'm wrong... (Now that I think about it, the program "top" is another offender that it would be nice to figure out someway to make it so the xterm-window can resize it.) -- VA Research Linux Workstations| The World's Best Linux Workstations | http://www.varesearch.com | Now offering VarStation II Systems Sam Ockman - (415)934-3666, ext. 133 | Based on the Intel Pentium II -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: 1.3 installation report
> > The fix is very simple: ctrl-alt-F1; log in as root; shadowconfig off; > > return to x and log in normally. But you do have to know this.. and there > > is no warning when installing shadow or xdm. > > Arrrghhh! > > I spent two hours yesterday (past midnite) on the phone with a client > trying to figure out how we messed up the xdm install. Just in case you are under the impression that xdm doesn't support shadow, I thought I'd clear it up a bit. You can get shadow and xdm to work by doing this: shadowconfig off shadowconfig on So what's happening here ? The xdm package contains two binaries (xdm & xdm-shadow), the default /etc/init.d/xdm invokes xdm, but shadowconfig edits this to be xdm-shadow when you run shadowconfig on. The reason you see the problem, is that xdm gets installed after shadow, so shadowconfig doesn't get a chance to tweak the startup script. As it happens xdm-shadow works fine on non-shadow systems, so I believe the maintainer has (or is about to) uploaded a copy where xdm and xdm-shadow are the same (shadow enabled) binary. >From shadowconfig itself: # xdm-shadow works fine with non-shadowed systems also, so it's # not necessary to reverse this in shadowoff Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses
Brian White: > I personally believe that Debian should relax > this requirement about non-modifiable & redistributable code not being > suitable for the primary distribution. I've never seen how it helps any > cause other than sticking a finger in the eye of those who might like > to keep some medium of control over their work. Bruce Perens: > We can't allow it because it prohibits ports, and it prohibits bug-fixes. From: "Eric S. Raymond" <[EMAIL PROTECTED]> > And this IMO is an entirely cogent and reasonable objection. > > Fortunately there is a way to solve this problem within the Debian license > constraints. See paragraph 1 of the license constraints in the "Social > Contract" and consider the implications. Eric is implying here that he is satisfied to allow modification as long as he has the guarantee of trace-ability. Paragraph 1 allows you to prohibit modification of a source file as long as that file can be distributed along with patch files that modify the source at build time. If the work of people like Tom Dickey is contained in a patch file, you can easily point to who has made the modification, and you can see the original source provided by Eric and Zeyd. I think this brings us to a resolution of the situation. I've asked for a specific permission similar to paragraph 1 in their license. Thanks 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: Debian's "Modify & Redistribute" Policy (was: the ncurses
Bruce writes, replying to Brian White: > > I agree with you on this. I personally believe that Debian should relax > > this requirement about non-modifiable & redistributable code not being > > suitable for the primary distribution. I've never seen how it helps any > > cause other than sticking a finger in the eye of those who might like > > to keep some medium of control over their work. > > We can't allow it because it prohibits ports, and it prohibits bug-fixes. And this IMO is an entirely cogent and reasonable objection. Fortunately there is a way to solve this problem within the Debian license constraints. See paragraph 1 of the license constraints in the "Social Contract" and consider the implications. -- http://www.ccil.org/~esr";>Eric S. Raymond -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Possible Xaw{3d,95} bug / Re: Debian freeciv bugs
After extensive testing, some code rewriting, etc., I finally have determined that this problem only occurs when using Xaw3d or Xaw95. I am CCing this message to the relevant maintainers. (Xaw maintainers: package freeciv-1.0j that is in hamm causes coredump under Xaw3d and Xaw95 but not the standard widget set). I don't know which package is causing this... [EMAIL PROTECTED] (Karl Sackett) writes: > John Goerzen writes: > > > > Well, I don't know if the new server coredumps. But the new client > > coredumps every time I load it. > > > > I'll have to punt on this one. Send a copy of the core dump to the > FreeCiv team at [EMAIL PROTECTED] I've never had any coredumping > when I've test the package, so I don't know where to start looking for > your problem. > > I got a reply back from them on your "Rock Band" problem. They'll > work on it. > > > -- > Karl Sackett[EMAIL PROTECTED] > > "I have sworn upon the altar of God eternal hostility against every form > of tyranny over the mind of man." -- Thomas Jefferson > -- 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] .
Re: 1.3 installation report
and don't forget, there's *still* no written-down policy on shadow: % grep -i shadow /usr/doc/dpkg/programmer.html/* Exit 1 I mean, I will get this straightened out with 3.3, but the picky-detail side of me is still miffed that debian's shadow policy is still basically hearsay. :-} -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: the ncurses "brushfire" -- anybody want to take over the project?
Jim Pick: > dselect (our package selection tool) will have to be rewritten to use > some other library. This will probably take some time, though. I'm > not sure how we will resolve having the core of our packaging system > dependent on a "non-free" package. Maybe we're going to have to > strip dselect out of the dpkg package, and put it into a separate > package to go into the "contrib" directory. Ugly. Perhaps it can be ported to use slang. Slang has some slcurses.h file that is supposed to emulate cureses to some degree. This might make a good quick fix while we're waiting on longer-term things like diety. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
1.2.X -> 1.3 upgrade report
It went very well; I missed a few packages, and had to go back for a few things, then `dpkg --configure --pending` three or four times, while sorting out dependencies. I'd installed the experimental shadow packages, and `dpkg` wouldn't let me upgrade, since `shadow-login` was an essential package. I used '-r --force-essential' to remove the old one, then installed the new, no problem. I guess that works fine as long as you don't pull the rug out from under yourself... you have to put it back before you land. Secure-su failed to configure, complaining about diversions (and `gnu-su`), which I don't understand yet. I went in and put things right by hand (sort of, I think...); it's still not configured according to `dpkg`. There is no man page for dpkg-divert??? I will look again. It is a mystery. I used XEmacs-20 and 'ediff' to merge in the .dpkg-inst changes to many of the config files. I was able to update my "passwd" and "group" files, as well as "/etc/init.d/boot". I had some oddball gid's that I had to change to match the standard groups file, and a few odd userid's too... It was simple to `chown`/`chgrp` the directories, since it was 'majordom' and 'postgres' that were different from the standard of reference on this particular computer. After I cleaned up the "passwd" and "group" files, running `shadowconfig on` worked fine. XDM is functional also, and so is `xlockmore`. I don't know if turning the :!:'s to :*:'s in "/etc/passwd", and "/etc/group" helped the config or not. I just did that as a matter of course while the system was unshadowed and I was editting in them. `innd` depended on `cron`, which for some reason wasn't installed...?? I don't have any idea where it went. I re-installed it, and `innd` configged. Who knows, huh? I have not rebooted yet. I might wait for deity before I do. ;-) It will be good to have packages install in the proper sorted order, finally. -- 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: the ncurses "brushfire" -- anybody want to take over the project?
-BEGIN PGP SIGNED MESSAGE- On 3 Jun 1997, Michael Alan Dorman wrote: > >1. The software may be redistributed by anyone. The license may > restrict a source file from being distributed in modified form, > as long as it allows modified binary files, and files that are > distributed along with the source for the express purpose of > modifying the source. > > So Eric is entirely correct in pointing out that the project is being > contradictory. > Clearly, this means that the author can require that we provide the virgin source .tgz along with a patch file to change it to the way we want it (this is exactly how debian source is distributed in the new format). So we are still distributing change work (once the source is unpacked with dpkg-source. But the author can be content that people have his/her original source available too in a .tar.gz file. Erv - -- PGP Public Key: finger [EMAIL PROTECTED] PGP Fingerprint: A5 AB 25 7D 7A FD 4D FE BE 21 47 60 0C DC 67 9E ==-- _ / / \ ---==---(_)__ __ __/ / /\ \ - [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / / /_/\ \ \- [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ /__\ \ \ - [EMAIL PROTECTED] \_\/ -BEGIN PGP SIGNATURE- Version: 2.6.3 Charset: noconv iQCVAwUBM5TV9LkbWT/F2aV1AQEQQgP9GchMcYOxcXRFrUP7XBLDvOyjZIna0w+g pQN7M/s61a3OW4XwNnGjm8bcwDvbkyyO9dCdB/4mEfL07D9424oMhDliEyBt0zjm wbRFNnY7JxKvp6OtlqFUc1htZVkruQa1Owbq8l7RZTECLyUodkurJ4ppo58Bieeo yDdJ2P5ujE8= =OT6J -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packager needed for Freedom Desktop
I'll take a look at it, but I can't gurantee anything yet, with graduation in 2 weeks (yea), after that when I am working full time, I actually will have more time. Who knows, I might be able to get a Pentium pro 200, to do some work on. Well I'll look at it tomorow after I finish with my last final. Thanks, Shaya On Tue, 3 Jun 1997, Bruce Perens wrote: > There is a GPL-ed version of "Freedom Desktop Lite" at > ftp://fsw.com/pub/fdlite/FDlite1.32.tar.gz . > > Someone please volunteer to package this. They GPL-ed it > specifically at our request. > > Thanks > > 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] . > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Packager needed for Freedom Desktop
On Tue, 3 Jun 1997, Bruce wrote: Bruce> There is a GPL-ed version of "Freedom Desktop Lite" at Bruce> ftp://fsw.com/pub/fdlite/FDlite1.32.tar.gz . Bruce> Bruce> Someone please volunteer to package this. They GPL-ed it Bruce> specifically at our request. I will do it. thks borik -- Boris D. Beletsky [EMAIL PROTECTED] Network Administrator [EMAIL PROTECTED] Institute of Computer Science, [EMAIL PROTECTED] Hebrew University Home: +972 2 6411880 Jerusalem Israel Work: +972 2 6585690 -- 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 Jun 2, Jim Pick wrote > Just so you understand why I'm so interested - I'm working on porting dpkg > to cygwin32. Porting or re-implementing? If it's a port, dpkg is already under gpl, so cygwin32 being under gpl shouldn't be an issue. [Even if it wasn't, I don't understand how a gpl'd dll could be considered a problem.] -- Raul -- 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 Jun 2, Jim Pick wrote > > Just so you understand why I'm so interested - I'm working on porting dpkg > > to cygwin32. > > Porting or re-implementing? If it's a port, dpkg is already under > gpl, so cygwin32 being under gpl shouldn't be an issue. [Even if > it wasn't, I don't understand how a gpl'd dll could be considered > a problem.] That's true. I was just thinking about all the packages that use it. It's worth doing, even if Cygnus doesn't want to LGPL their license. At least we could port the 1000+ packages in the main distribution. The non-free stuff would be questionable. Let's kill this thread - I made my point - ie. "just 'cause it's GPL'd doesn't automatically make it as 'free' as humanly possible". When I actually get dpkg to work, we can start up a new mailing list, and continue the discussion there. Cheers, - Jim pgpClFc3F4Yxq.pgp Description: PGP signature
Re: 1.3 installation report
> The xserver packages want to setup x, this gets stuck because xinitrc is > missing because it is part of xbase - which is not installed at that Hmm. Yeah, I think I've probably always won because I use dpkg from the shell, and with globbing get everything in alphabetical order :-) The problem here is that the server packages don't need the X packages; only the configuration tools do. Would it be enough if the X server packages "suggest" xbase? That way normal users would get them, but people who really knew that they wanted to make a machine into an xterminal can just ignore the "suggestion". > The fix is very simple: ctrl-alt-F1; log in as root; shadowconfig off; > return to x and log in normally. But you do have to know this.. and there Or even, "shadowconfig off; shadowconfig on" -- I'm told that shadowconfig does the right thing with xdm *if* X is already installed... _Mark_ [9:30pm US/Eastern, still no 3.3 release...] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> I agree with you on this. I personally believe that Debian should relax > this requirement about non-modifiable & redistributable code not being > suitable for the primary distribution. I've never seen how it helps any > cause other than sticking a finger in the eye of those who might like > to keep some medium of control over their work. We can't allow it because it prohibits ports, and it prohibits bug-fixes. 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: the ncurses "brushfire" -- anybody want to take over the project?
> Eric then rightly pointed out that the way it is written, it *does* > permit the redistribution of packages that do not allow modification > of source---that is, in fact, the very first item. To wit: > >1. The software may be redistributed by anyone. The license may > restrict a source file from being distributed in modified form, > as long as it allows modified binary files, and files that are > distributed along with the source for the express purpose of > modifying the source. > > So Eric is entirely correct in pointing out that the project is being > contradictory. I'm not so sure. They'll have to spell out their position on modification explicitly. Currently they don't state it at all. 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: 1.3 installation report
> I did find a serious problem after rebooting (ok, I could probably have > done this more subtle) the machine to start xdm. From reading several > debian related lists I already knew that xdm will break with shadow > passwords. However, I doubt if everyone who just installed debian 1.3 will > realize that it is this combination that prevents him/her from logging in. > The fix is very simple: ctrl-alt-F1; log in as root; shadowconfig off; > return to x and log in normally. But you do have to know this.. and there > is no warning when installing shadow or xdm. Arrrghhh! I spent two hours yesterday (past midnite) on the phone with a client trying to figure out how we messed up the xdm install. This flaw needs to be publicized a bit more. I'm sure I would have figured out the problem via the bug system eventually - but I shouldn't have to do that. Is there a document where "Errata" can go? How about a release-specific FAQ that we can update after 1.3 has been release? I can think of a number of questions that could go onto it. This could be prominently featured on the web site and the ftp server. Cheers, - Jim pgppoWRhgYUGn.pgp Description: PGP signature
Re: Debian 1.3 and "alien"
> How can we cope with the fact that Slackware support of the Bo > release of "alien" is broken then? It's a bug. We'll have to release a bug fix in a later release. Thanks 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: Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
Brian White wrote: > I agree with you on this. I personally believe that Debian should relax > this requirement about non-modifiable & redistributable code not being > suitable for the primary distribution. I've never seen how it helps any > cause other than sticking a finger in the eye of those who might like > to keep some medium of control over their work. We do allow software licenses that require derived works to have a different name. I believe that adding that restriction to the ncurses license might allow Eric to retain control over the "ncurses" brand name, and still qualify for Debian's "Free" stamp of approval. Any derived works (like that ncurses 4.0 stuff) would have to be renamed, if they want to use the ncurses 3.0 code. That way, there's no confusion - and Eric's toes don't get trampled. But we should stick with the requirement for having all the code in the core distribution being modifiable. (that's the #1 reason I use and develop for Debian) Cheers, - Jim pgphoo3srd6qS.pgp Description: PGP signature
Packager needed for Freedom Desktop
There is a GPL-ed version of "Freedom Desktop Lite" at ftp://fsw.com/pub/fdlite/FDlite1.32.tar.gz . Someone please volunteer to package this. They GPL-ed it specifically at our request. Thanks 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] .
1.3 installation report
From: "J.P.D. Kooij" <[EMAIL PROTECTED]> On Mon, 2 Jun 1997, Bruce Perens wrote: > We are in the process of releasing Debian 1.3 . Tonight I made another attempt to install base + 300 packages. I've added the list to the end of this message. I experienced a _major_ problem with shadow and xdm, a minor problem with bind and some dselect annoyance with installation order, which tends to break installation in a way that cycling dselect "installation" doesn't solve the dependency problems. Mostly things went quite fine though. Base install from May 28 floppies is very smooth and without any problems on my hardware (pci p133 32mb) I made a 2+Gb ext2 partition without memory problems. I did install any modules, because I rolled my own 2.0.29 kernel with some patches to get my ne2000 recognised and I just compiled everything needed in. After rebooting and entering dselect I chose nfs access method. Every time the stable/binary tree is checked by dselect it prints an (apparently harmless) error about a broken pipe. Before, I had tried to select a whole bunch of packages, but this tends to give a lot of dependency problems. So this time I first did the already selected + all important packages + all packages suggested because of dependencies - no problems. Then all standard packages + depended on packages - no problems. Then all optional packages + depends. This included x, which gave some problems: The xserver packages want to setup x, this gets stuck because xinitrc is missing because it is part of xbase - which is not installed at that point. Also, sometimes xdm does get configured properly because of similar reasons - a missing Xservers file. This time it worked though, but only because I installed more than one xserver and xbase got installed before the one I actually use. This also saved the day for xsetup, so in fact I did get x running in one dselect run. Had to rerun dselect anyway because of the unconfigured xserver-vga16 etc. On the point of xsetup: I found that things hang really badly if I run xvidtune from xsetup. Maybe that is not so bad actually because it is quite a dangerous program to your monitor - I once found out. Apart from x, there were no obvious problems with the otional packages. I wound up in a catch-22 with some of the extra packages: - ghostview and gv both depend on gs. However, package gs-alladin which provides gs never gets installed because dselect tries to: gs-alladin is in non-free, which is never parsed because gv/ghostview doesn't install because there's no gs. Repeating the installation step doesn't solve this. - the problem with dselect not trying a section because there was an error in a previous section returns with pinepgp from contrib not installing because it depends on pine and pgp, in non-free resp. local. Here too, repeating the process doesn't solve the problem. This behaviour of dselect should be anticipated on when determining the proper (pre)dependecies, or otherwise a mention of it should be added to the documentation - along with a hint of possible solutions. Repeating the installation step (the current panacea) is no solution in these cases. So this makes more or less 3 problems with installation of more than 300 packages. Quite good actually! Add to that that these problems were not really serious - very good actually! I did find a serious problem after rebooting (ok, I could probably have done this more subtle) the machine to start xdm. From reading several debian related lists I already knew that xdm will break with shadow passwords. However, I doubt if everyone who just installed debian 1.3 will realize that it is this combination that prevents him/her from logging in. The fix is very simple: ctrl-alt-F1; log in as root; shadowconfig off; return to x and log in normally. But you do have to know this.. and there is no warning when installing shadow or xdm. IMHO a _big_ warning in CAPS should be added to the installation messages or, much better, this should be fixed in frozen before a release is made. If this isn't fixed in time, then I think we can consider shadow sort of broken in 1.3. Another problem that I have seen reprorts of is the problems with bind. I let the bind upgrade touch a working setup on a 1.2 machine and it broke it. I set it up on a fresh machine and I can't even do a "nslookup localhost". Haven't had thhe time to investigate what went wrong. So far my longish report at a rather late time - hope it is still of some use. Cheers, Joost Here are the install logs: adduser install < ae install < base-files install < base-passwd install < bashinstall < bsdutilsinstall < debianutils
Debian's "Modify & Redistribute" Policy (was: the ncurses "brushfire")
> > However now that I *have* done what I should have done two years ago > > and familiarized myself with the license, I think that there is a > > significant problem with the ncurses license as it stands---in that it > > does not guarantee anyone the right to distribute modified versions. > > > > Without this guarantee, written into the license, Debian cannot use > > ncurses. And even if you were to grant us special dispensation, our > > informal charter would forbid us using ncurses as the base of our > > product---it would be, at best, a compatability library. > > > > How do we resolve this issue? > > I don't yet know. I believe Debian's position on this is (a) > unreasonable, I agree with you on this. I personally believe that Debian should relax this requirement about non-modifiable & redistributable code not being suitable for the primary distribution. I've never seen how it helps any cause other than sticking a finger in the eye of those who might like to keep some medium of control over their work. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: the ncurses "brushfire" -- anybody want to take over the project?
Jim Pick <[EMAIL PROTECTED]> writes: > Debian is getting more consistent on this all of the time. > Obviously, we weren't too consistent when ncurses got into the > distribution, with a license that doesn't permit modifications. It > looks like it was introduced very early in the history of Debian, so > it escaped public scrutiny. Well, it's been around in various forms for quite some time, but it wasn't until the ELF move, and the subsequent dropping of BSD curses from the libc distribution that it because important. I must admit that I didn't study the license carefully when I took it over and ELF-ized it, because I assumed it had already been scrutinized. > Maybe Bruce could send Eric a copy of the draft "social contract", > just so he can see how consistent we are trying to be. Bruce did. Eric then rightly pointed out that the way it is written, it *does* permit the redistribution of packages that do not allow modification of source---that is, in fact, the very first item. To wit: 1. The software may be redistributed by anyone. The license may restrict a source file from being distributed in modified form, as long as it allows modified binary files, and files that are distributed along with the source for the express purpose of modifying the source. So Eric is entirely correct in pointing out that the project is being contradictory. And, I suppose, means that a lot of the discussion here, largely a result of my agitation, has been hogwash. Today is apparently my day for saying Mea Culpa. Which doesn't mean I don't find the current disputes tiresome, and I think some things have been said that I still do not like the tone of, and I'm still not sure at this time how much I want to be responsible for this puppy, *but* I must admit that I've been working under a number of mistaken assumptions at various points here, and Eric is obviously acting with a much better command of those pesky little fact thingies. Mike. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
