Re: Documentation license problem solved: OpenContent License (OPL)
Hi! Jens Ritter writes: [...] You may not charge a fee for the OC itself. JR ^^ JR As I understand it, GPL does not put this restriction on the JR content it licenses. That's one of the points I missed. Thanks for reading the fine print. JR GPL applied to documentation ensures the content is free, or JR doesn't it? Yes, it does. JR What`s the point with another license? It makes the intent of the author more obvious, for those who don't think about the full implications of the GPL. -- Gordon Matzigkeit [EMAIL PROTECTED] //\ I'm a FIG (http://www.fig.org/) Lovers of freedom, unite! \// I use GNU (http://www.gnu.org/) Copyright (C) 1998 FIG.org; the creator offers you this gift and wants it to remain free. See http://www.fig.org/freedom.html for details. This work may be copied, modified and distributed under the GNU General Public License (GPL). See http://www.gnu.org/copyleft/gpl.html.
Re: NAG messages.
On Tue, Sep 22, 1998 at 03:40:57PM -0400, Brian White wrote: I don't want to remove people. I feel the nag service is a helpful service for many people that just need a small push to encourage them to fix their outstanding bugs. I can understand the problem with receiving hundreds of pieces of email about it. Nag was never designed with the current system in mind. What I've done instead is to change nag so that it only sends one piece of email per maintainer which includes all bugs of a given type and severity. With this, you'll never receive more than one email on any given day. That's acceptable to me. What bothered me was the volume of messages, which makes it difficult for me to navigate throught the folder I have reserved for maintainer mail. Thanks for making that alteration. -- G. Branden Robinson | Purdue University | The software said it required Windows [EMAIL PROTECTED] | 3.1 or better, so I installed Linux. http://www.ecn.purdue.edu/~branden/ | pgp7p2QhhJtfY.pgp Description: PGP signature
Re: Unidentified subject! (fwd)
Anthony == Anthony C Zboralski [EMAIL PROTECTED] writes: Anthony On Fri, Sep 11, 1998 at 05:18:18PM +0200, Anthony Anthony C. Zboralski wrote: hey is there an easy way to print info manuals? Anthony No. In order to have acceptable quality output, you have Anthony to use the TeXinfo source files. for manuals like libg++ i am not going to print everypages manually; maybe i am stupid and there is an easier way to do this but when i need to print a texinfo manual, i have to grab the package source, run configure and make dvi. Anthony You could try getting policy extended to have .texi Anthony sources (in a form suitable for texi2dvi) included in the Anthony package (or in a separate documentation package) - Anthony propose it on debian-policy@lists.debian.org I think that the .texi source belongs in the package source. Why make yet another package out of things when it's already there? Perhaps there ought to be (ie, suggested by, but not required by policy) a debian/rules target for creating the .dvi or .ps, whenif the upstream Makefile doesn't perform that task adequately. muse It sure would be nice if someone would extend `gv' to have `Lectern' like keybinds, with searching and everything... and maybe some `info' keys too. sigh I've got a book about postscript, but haven't read it yet, and don't know C and X programming well enough to take it on yet. grin /muse
Re: Call for Seconds, Take II
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Hi Karl == Karl M Hegbloom [EMAIL PROTECTED] writes: Karl Also, ChangeLog files are named with capital `C' and `L' Karl when you use `C-x 4 a' with `add-log' in the emacsen. I Karl think we should permit that spelling, which is very standard Karl and more common than all lowercase, rather than symlinking Karl or renaming. I like it capitalized since that makes it sort Karl near the top of a directory listing in `dired' (or any other Karl file manager). Manoj Are you proposing this as an amendment to the Manoj proposal? Sure. Will anyone second? Another thing I've been doing... I use `pcl-cvs' (a recent beta, in XEmacs 21.2 beta; you can grab an _unofficial_ version and try it if you like, off my http site. It is greatly improved over the older version, and needs to be tested by someone who uses GNU Emacs, rather than XEmacs.), and have `change-log-default-name' customized to ChangeLog.local. When I make a changelog entry with `C-x 4 a', it puts that entry in my local changelog file, so that later joins with upstream sources don't create the inevitable conflicts in ChangeLog. I also put that ChangeLog.local into the doc directory... I only log packageing type changes in the Debian changelog, and code mods are in the ChangeLog.local file, since that works better with `pcl-cvs' and `add-log'. I guess the name could be other than *.local; leaving `local' for users who are CVS tracking the Debian version of a source ball? Hmmm. Any suggestions? -- mailto:[EMAIL PROTECTED] (Karl M. Hegbloom) http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 2.0 Linux 2.0.35 AMD K6-233 XEmacs-21.2beta
Re: Call for Seconds, Take II
[EMAIL PROTECTED] (Karl M. Hegbloom) writes: Manoj == Manoj Srivastava [EMAIL PROTECTED] writes: Manoj Hi Karl == Karl M Hegbloom [EMAIL PROTECTED] writes: Karl Also, ChangeLog files are named with capital `C' and `L' Karl when you use `C-x 4 a' with `add-log' in the emacsen. I Karl think we should permit that spelling, which is very standard Karl and more common than all lowercase, rather than symlinking Karl or renaming. I like it capitalized since that makes it sort Karl near the top of a directory listing in `dired' (or any other Karl file manager). Manoj Are you proposing this as an amendment to the Manoj proposal? Sure. Will anyone second? Seconded.
Re: Kachina Technologies as a maintainer
John Lapeyre wrote: On Thu, 17 Sep 1998, Ward Deng wrote: wdengWe really intend take over some numerical/scientific wdengapplications. However, none of us here are official Debian wdengdevelopers. We are asking question if a company can be a wdengdeveloper and nobody seems to know the answer. The easiest way would be for each of you to apply as maintainer and maintain the packages as a group - which is not yet allowed by policy. *sigh* Regards, Joey -- *** Fatal Error: Found [MS-Windows], repartitioning Disk for Linux ...
Re: {PROPOSAL} #7890: Policy manual contradicts itself about including docs
Adam == Adam P Harris [EMAIL PROTECTED] writes: Adam Manoj Srivastava [EMAIL PROTECTED] writes: I also further stated: I was not really suggesting replacing the info documentation (or the man pages, for that matter), I meant in addition to. The policy *does* say that HTML is our preferred format, so it should also be provided Adam Yes, I mostly agree. The *source* of the documentation Adam should also be shipped if possible (i.e., SGML, TeX). This Adam enables people to patch documenatation and send in diffs; it Adam also enables them to possibly format the source into Adam whatever media they like. The source is available in the source package.
Re: Finding a source package
John == John Lapeyre [EMAIL PROTECTED] writes:
John On Mon, 21 Sep 1998, Jason Gunthorpe wrote:
jgg
jgg We have rather a bit of a problem.. As it stands it is not
jgg possible to locate the source tar.gz and .dsc without
jgg searching in all cases,
There's so many packages now I end up searching using the CGI site
or `locate' on master anyhow. :-)
John I also sometimes wonder about the fact that, while we
John encourage people to look at the source, it is in fact kind
John of difficult to wade through the documents to find how to
John get and unpack debian source files. I hope apt-get source
John remedies this.
@drifting{
It just occured to me that perhaps it would be good to have a master
CVS archive of Debian, and the package source could be downloaded and
installed as now, using ftp or the new `apt-get'... I guess that
would also perform a `dpkg-source -x'. The source packages could
contain `CVS' directories that would link them back to the canonical
Debian anon ro-CVS, so folks could `cvs update' and `cvs diff'.
@offtopic{
I've tried to build Modula 3, (thinking of the fabled `cvsup'.) but
it bombed trying to build `m3gdb'. I've not tried to find out what's
wrong yet. It's huge; I think too big for a guy on the wrong end of
a modem connection to really do right. I think a small team at a
university ought to do this one. It looks like a neat language; very
archane syntax, perhaps, but good features, and LOTS of great example
code to learn from.}}
Re: Documentation license problem solved: OpenContent License (OPL)
On Tue, Sep 22, 1998 at 02:56:46PM -0600, Gordon Matzigkeit wrote: BG On slashdot.org today, an article about the OpenContent License BG (OPL, pronounced 'opal') was posted. OPL is nice because it is designed to be easy-to-understand. Maybe I misread it... It seems to suggest that selling it say in book form would not be acceptable if that's all there was in that book. If I write a book in SGML/HTML and put the thing on the web under this license, I would not mind someone taking that and printing it and charging a regular book's fee for it. However, the publisher must realize that they do this as a service and do not own copyright on the material they print---anyone else could print the same book verbatim and they could print it and sell it for less and people would buy from the less expensive source. And just because they print the book doesn't mean someone else isn't gonna burn the thing onto CDR and sell it or that someone isn't gonna just use the internet available versions for free! Did I misread the OPL? pgplaaWReYY51.pgp Description: PGP signature
Re: Call for Seconds, Take II
On Tue, Sep 22, 1998 at 11:16:04PM -0400, Ben Pfaff wrote: Manoj Are you proposing this as an amendment to the Manoj proposal? Sure. Will anyone second? Seconded. And by me as well. pgpTVZs2ypetU.pgp Description: PGP signature
ip-{up,down}.d scripts
An example ip-up.d script: /etc/ppp/ip-up.d/fetchmail There is also: /etc/ppp/ip-down.d/fetchmail I don't believe this is covered by policy, it's just provided there for packages to make easy use of it. I'd like to suggest we change this behavior, which would require a bit of a rewrite to policy sections 3.4.1 if people like my suggestion, so here goes: Why not put things in those two dirs above into /etc/init.d? They are system services, just services that are start'd when ip-up is run and stop'd by ip-down. This would also require an optional parameter added to run-parts in debianutils for a parameter to run with.. This line in ip-up run-parts /etc/ppp/ip-up.d would become: run-parts /etc/ppp/ip-updown.d start and similar in ip-down with stop. Files in ip-updown.d (better name appreciated if you can think of one) would be symlinks ala the runlevel stuff or something.. The rationale for this is that a lot of programs set these things up for ppp only. Cable modems for example--you'd still need fetchmail (their customers are usually windoze users, what did you expect?) but you'd want it on system startup because you'd be using it over a LAN as far as Linux is concerned. You'd want that in /etc/init.d then and you'd want to start it after /etc/init.d/network sometime. It also makes things more ... seemingly universal. It's noteworthy that /etc/init.d/network does not follow the format spelled out in the policy manual, but I'm not sure how you'd make it so it did really... pgpK9jFPKPYMb.pgp Description: PGP signature
Re: NAG messages.
On Tue, Sep 22, 1998 at 03:40:57PM -0400, Brian White wrote: I don't want to remove people. I feel the nag service is a helpful service for many people that just need a small push to encourage them to fix their outstanding bugs. I can understand the problem with receiving hundreds of pieces of email about it. Nag was never designed with the current system in mind. What I've done instead is to change nag so that it only sends one piece of email per maintainer which includes all bugs of a given type and severity. With this, you'll never receive more than one email on any given day. More info than what we have now w/ nags would be VERY much appreciated. As will the 1 mail thing. pgpHaXyymDUt3.pgp Description: PGP signature
PROPOSAL: daemons should run as root only if really needed
I can see there are some daemons (like junkbuster and maybe syslogd) which runs as root even if they could run as a non priviledged user. What about adding a policy statement to outlaw that? A --user option could be added to start-stop-daemon. -- ciao, Marco
Re: ip-{up,down}.d scripts
On Wed, Sep 23, 1998 at 10:36:37AM +0200, Paul Slootman wrote:
This would also require an optional parameter added to run-parts in
debianutils for a parameter to run with..
It would also require a rewrite of all such scripts, to take into account
a 'start' or 'stop' parameter.
Not necessarily, let me explain why not...
ip-{up,down}.d scripts take no parameter at this time, so any new parameter
would be ignored. I think it would be reasonable to add the init.d ability
and depreciate the older method, maintaining it for compatibility. The new
files would be symlinks, so...
This line in ip-up
run-parts /etc/ppp/ip-up.d
would become:
run-parts /etc/ppp/ip-updown.d start
and similar in ip-down with stop. Files in ip-updown.d (better name
appreciated if you can think of one) would be symlinks ala the runlevel
stuff or something..
You still might want to separate the start and stops, like the Sxx and Kxx
links in e.g. /etc/rc2.d . E.g., exim has an ip-up.d script but no
ip-down.d script. Of course, that could be handled by looking at the
parameter.
It should be really handled by the parameter.
If not, leave /etc/ppp/ip-up.d and /etc/ppp/ip-down.d as they are and just
have things put symlinks in place of the files. The old scripts would not
be affected as they take no parameters and these would therefore be ignored.
The rationale for this is that a lot of programs set these things up for ppp
only. Cable modems for example--you'd still need fetchmail (their customers
are usually windoze users, what did you expect?) but you'd want it on system
startup because you'd be using it over a LAN as far as Linux is concerned.
You'd want that in /etc/init.d then and you'd want to start it after
/etc/init.d/network sometime.
If that's your rationale, I think it would be better to either make an
/etc/init.d script or change the existing one, and configure what it
does during install (Must fetchmail be started on system boot, or only
when a PPP connection is made?).
Why? The question could be asked yes, but changing a symlink or two is
simple and can be done easily by either postinst or sysadmin. A similar
thread about asking whether or not to start a daemon that you might not need
comes to mind.
It also makes things more ... seemingly universal.
I think it would lead to confusion; it's currently clear that the stuff in
/etc/ppp/ip-{up,down}.d is for dialup links, and the stuff in /etc/init.d
is for stuff that gets done during runlevel (init) changes.
I tend to disagree that this would confuse, but that's why I brought it up,
for others to add their comments.
pgpzvbeSK6kcC.pgp
Description: PGP signature
Re: Unidentified subject! (fwd)
On 22 Sep 1998, Karl M. Hegbloom wrote: Anthony == Anthony C Zboralski [EMAIL PROTECTED] writes: Anthony On Fri, Sep 11, 1998 at 05:18:18PM +0200, Anthony Anthony C. Zboralski wrote: hey is there an easy way to print info manuals? Anthony No. In order to have acceptable quality output, you have Anthony to use the TeXinfo source files. for manuals like libg++ i am not going to print everypages manually; maybe i am stupid and there is an easier way to do this but when i need to print a texinfo manual, i have to grab the package source, run configure and make dvi. Anthony You could try getting policy extended to have .texi Anthony sources (in a form suitable for texi2dvi) included in the Anthony package (or in a separate documentation package) - Anthony propose it on debian-policy@lists.debian.org I think that the .texi source belongs in the package source. Why make yet another package out of things when it's already there? Perhaps there ought to be (ie, suggested by, but not required by policy) a debian/rules target for creating the .dvi or .ps, whenif the upstream Makefile doesn't perform that task adequately. oh well, it is normal to have to download 11Megs of source code to create the dvi files for egcs, libg++ and more.. info files are okay but they are not printable. I work a lot and i save some time by reading docs in the subway or in my bed when my girlfriend is asleep.
Re: NAG messages.
Dale Scheetz wrote: On Tue, 22 Sep 1998, Brian White wrote: This is a formal request for removal from the NAG distribution list. Receiving 100 useless messages, each indicating an outstanding bug, is the worst kind of spam. It imparts no information, either about the bugs, or any suggested fixes. It only adds useless mail to my inbox, which I must delete in order to see important mail. I don't want to remove people. I feel the nag service is a helpful service for many people that just need a small push to encourage them to fix their outstanding bugs. It's reduculous to have debian-policy and - with ~170 messages - debian-dpkg spammed with that mails. They can be helpful when there are only a few of them and one can react. If you receive tons of them, they don't make sense anymore. It would be more helpful to investigate the problems, bring them up on -devel, develop a solution, upload the patch, decrease the severity to fixed etc. This would be helpful. Tired of spam? See what you can do to fight it at: http://www.cauce.org/ Yes! I'm tired of your spam. STOP! *rotfl* Regards, Joey -- *** Fatal Error: Found [MS-Windows], repartitioning Disk for Linux ...
Re: NAG messages.
On Wed, 23 Sep 1998, Dale Scheetz wrote:
I don't want to remove people. I feel the nag service is a helpful service
for many people that just need a small push to encourage them to fix their
outstanding bugs.
You are the only person I have heard say that this spam is helpful. I
find it obnoxious, uninformative, and totally useless.
Maybe a reasonable compromise is to send only 1 mail by package; this
email giving the list of overdue bugs for the given package...?
--
- Vincent RENARDIAS[EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux:Open Hardware: WAW: -
- http://www.fr.debian.org http://www.openhardware.org http://www.waw.com -
---
-Depuis que ma voiture et mon ordinateur tournent au GPL, les 2 marchent -
- beaucoup mieux et pour moins cher... (Linux: Le seul OS non-polluant!) -
Re: NAG messages.
On Wed, 23 Sep 1998, Vincent Renardias wrote: On Wed, 23 Sep 1998, Dale Scheetz wrote: I don't want to remove people. I feel the nag service is a helpful service for many people that just need a small push to encourage them to fix their outstanding bugs. You are the only person I have heard say that this spam is helpful. I find it obnoxious, uninformative, and totally useless. Maybe a reasonable compromise is to send only 1 mail by package; this email giving the list of overdue bugs for the given package...? Even this is redundant. I already receive the Unresolved Problem Report every Friday. I do `grep Dale Scheetz problems.msg bugs.today` and get a useful list of all my outstanding bug reports. There is no additional information provided by the NAG message, so it is completely redundant, and useless. I can remove myself from the bug track mailing list if I desire, and stop receiving the Friday report. I have no such control over the NAG messages. I am only asking for control over what gets sent to my mailbox by an automated process. I am supposed to have legal recourse when someone unknown to me forces e-mail into my box. I find myself frustrated and disturbed that I can't get the same cooperation from a fellow developer. Waiting is, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: NAG messages.
More info than what we have now w/ nags would be VERY much appreciated. As will the 1 mail thing. What more information would you like to see? Brian ( [EMAIL PROTECTED] ) --- It's the weak who are cruel. Gentleness can only be expected from the strong.
Re: NAG messages.
I don't care that you don't want to remove people. This is unsolicited spam and I want you to stop sending it to me. This is untrue and you know it. You're registered as a Debian developer and all the perks/requisites that come with it. Brian ( [EMAIL PROTECTED] ) --- The squeaky wheel doesn't always get the grease. Sometimes it gets replaced.
Re: NAG messages.
On Wed, Sep 23, 1998 at 09:53:30AM -0400, Dale Scheetz wrote: Maybe a reasonable compromise is to send only 1 mail by package; this email giving the list of overdue bugs for the given package...? Even this is redundant. I already receive the Unresolved Problem Report every Friday. I do `grep Dale Scheetz problems.msg bugs.today` and get a useful list of all my outstanding bug reports. There is no additional information provided by the NAG message, so it is completely redundant, and useless. I can remove myself from the bug track mailing list if I desire, and stop receiving the Friday report. I have no such control over the NAG messages. I am only asking for control over what gets sent to my mailbox by an automated process. I am supposed to have legal recourse when someone unknown to me forces e-mail into my box. I find myself frustrated and disturbed that I can't get the same cooperation from a fellow developer. Even though we are obviously arguing for arguements' sake: Mailagent, Procmail. -- ___ Ean Schuessler An oderless programmer work-a-like Novare International Inc. Silent and motionless *** WARNING: This signature may contain jokes.
Re: ip-{up,down}.d scripts
ip-{up,down}.d scripts take no parameter at this time, so any new parameter
would be ignored. I think it would be reasonable to add the init.d ability
and depreciate the older method, maintaining it for compatibility. The new
files would be symlinks, so...
There's problem with this proposal.
The current setup allows you to force scripts to be executed in a fixed order,
by naming them like this, for example:
ip-up.d/00local-ipfwadm
ip-up.d/10local-qmail
ip-up.d/99local-getmail
So that in this example the ipfwadm setup happens before anything else. For
the ip-down scripts you are likely to want a different order (i.e. ipfwadm
last) but not necessarily just the reverse order.
---
Another thing that people tend to miss is that these scripts get run for every
ppp link that goes up and down, including inbound connections and connections
to non-ISP sites.
Most of the suggestions that people come up with for ip-up/down scripts assume
that the only link on the machine is going to be the one to an ISP. These
scripts can be something of a disaster on more complicated setups, and so IMO
should not be installed by default.
I'd like to come up with a way of dealing with the more complicated
permutations of PPP links and ip-up/down setups in a consistent way, but so
far I've not been able to think of a way to do it without causing some people
problems --- any suggestions gratefully accepted :-)
On my main PPP system, I do it by setting ``ipparam'' to ``internet'' for
the connections to my ISPs, so that I can have a case ${PPP_IPPARAM} ...
statement in the ip-{up,down}.d scripts. Any other suggestions need to be
able to deal with something like this.
Cheers, Phil.
Re: Kachina Technologies as a maintainer
Hi, J == J H M Dassen [EMAIL PROTECTED] writes: J On Wed, Sep 23, 1998 at 05:14:03AM +0200, Martin Schulze wrote: The easiest way would be for each of you to apply as maintainer and maintain the packages as a group - which is not yet allowed by policy. *sigh* J *sigh* indeed. Policy needs to be fixed then. J Several packages are succesfully maintained by a maintainer group (e.g. J egcs, bootdisks). As a concession to policy, one maintainer is named as the J primary maintainer (usually listing an email address that expands to the J maintainer group). Funnily enough, the policy document itself is maintained by this list, which does not even have a fixed set of people (and, incidentally, that set of peole contains those that are not Debian maintainers either). Certainly, policy shjould be changed. A proposal, anyone? manoj -- You recoil from the crude; you tend naturally toward the exquisite. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: Unidentified subject! (fwd)
Hi, [I'm including a CC to the -doc group, in case someone there has a comment on this] Anthony == Anthony C Zboralski [EMAIL PROTECTED] writes: Anthony On 22 Sep 1998, Karl M. Hegbloom wrote: I think that the .texi source belongs in the package source. Why make yet another package out of things when it's already there? What other package? All that is suggested is that the preferred source of the documentation be also included, so it may be rendered into different formats; and the preferred document format, HTML, be included as well. Are you suggesting that the binary-all packages, which may only contain shell scripts and perl scripts are redundant, since the full text of the scripts is already there in the source package? Perhaps there ought to be (ie, suggested by, but not required by policy) a debian/rules target for creating the .dvi or .ps, whenif the upstream Makefile doesn't perform that task adequately. Anthony oh well, it is normal to have to download 11Megs of source Anthony code to create the dvi files for egcs, libg++ and more.. You have a point. Anthony info files are okay but they are not printable. I work a lot Anthony and i save some time by reading docs in the subway or in my Anthony bed when my girlfriend is asleep. I suggest that the preferred source format of the documentation be also available. This means that we also ship texinfo, tex, and sgml versions of the documentation, as well as HTML formats (we may also ship man, info, ps formatted documentation too, but the source and HTML should always be there). manoj -- If you stop to think about it, you're already dead. Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: NAG messages.
On Wed, 23 Sep 1998, Brian White wrote: More info than what we have now w/ nags would be VERY much appreciated. As will the 1 mail thing. What more information would you like to see? 1. A synopsis of the bug log. In particular, any suggested solutions. 2. Clear examples that exhibit the bug. 3. A patch that fixes it. Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: NAG messages.
More info than what we have now w/ nags would be VERY much appreciated. As will the 1 mail thing. What more information would you like to see? 1. A synopsis of the bug log. In particular, any suggested solutions. 2. Clear examples that exhibit the bug. 3. A patch that fixes it. Well, I'm a little busy in the real world, but if you'll write the program that calculates those things, I'll be happy to include it. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: NAG messages.
Quoting Dale Scheetz ([EMAIL PROTECTED]): On Wed, 23 Sep 1998, Brian White wrote: What more information would you like to see? 3. A patch that fixes it. :) Mike Stone
clarification of statement in packaging manual requested
In section 7 of the Debian Packaging Manual it is stated: Every package should also have an extended description. I just wanted clarification on whether the 'should' is intentional or whether it should be 'must'. As the package descriptions are important it should be mandatory that every package provide one. As it stands it is not clear whether a bug should be filed against packages without an extended description. Jay Treacy
Bug#26995: fsstnd-1.2.dvi.gz is wrong.
Hi, Tomohiro == Tomohiro KUBOTA [EMAIL PROTECTED] writes: Tomohiro Large black blocks (large characeters?) sometimes appear Tomohiro in the TeX Version of fsstnd-1.2 and they hide the page. Tomohiro So I can't read such parts. Could you give more details? Like what pages this occurs on? Do you see this in xdvi, or is it in the printed output? However, I must confess that this seems more like a problem with your TeX processing environment than with the fsstnd, since I don't see the fsstnd doing anything special with fonts. I just viewd the dvi file using xdvi, and I do not see anything like what you report. manoj -- My mother loved children--she would have given anything if I had been one. Groucho Marx Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: NAG messages.
On Wed, 23 Sep 1998, Brian White wrote: More info than what we have now w/ nags would be VERY much appreciated. As will the 1 mail thing. What more information would you like to see? 1. A synopsis of the bug log. In particular, any suggested solutions. 2. Clear examples that exhibit the bug. 3. A patch that fixes it. Well, I'm a little busy in the real world, but if you'll write the program that calculates those things, I'll be happy to include it. So is everyone else, myself included. Please tell me again how useless messages improve my ability to repair bugs? Thanks, Dwarf -- _-_-_-_-_- Author of The Debian Linux User's Guide _-_-_-_-_-_- aka Dale Scheetz Phone: 1 (850) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
Re: clarification of statement in packaging manual requested
Hi, Jay == [EMAIL PROTECTED] writes: Jay In section 7 of the Debian Packaging Manual it is stated: JayEvery package should also have an extended description. Jay I just wanted clarification on whether the 'should' is intentional Jay or whether it should be 'must'. As the package descriptions are Jay important it should be mandatory that every package provide one. I personally think that the intent was MUST -- where must is defined as per RFC 2119. I think we should take the policy document, and change the MUST, MUST NOT, SHOULD, MAY, and SHOULD NOT instances to conform to the RFC. manoj -- To iterate is human, to recurse, divine. Robert Heller Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Bug#7890: {PROPOSAL} #7890: Policy manual contradicts itself about including docs
Hi, Adam == Adam P Harris [EMAIL PROTECTED] writes: Adam Manoj Srivastava [EMAIL PROTECTED] writes: I also further stated: I was not really suggesting replacing the info documentation (or the man pages, for that matter), I meant in addition to. The policy *does* say that HTML is our preferred format, so it should also be provided Adam Yes, I mostly agree. Does that mean you second the proposal? I suggest we implement this part of the proposal first, and leave the issue of the source of the documentation to another ptoposal, since that is turning out to be controversial. This proposal has only one second at the moment. I would like to see if there are others, and to move the non-controversial part of the proposal out of the way. Adam The *source* of the documentation should also be Adam shipped if possible (i.e., SGML, TeX). This enables people to patch Adam documenatation and send in diffs; it also enables them to possibly Adam format the source into whatever media they like. I personally tend to agree, but I think this is grist for another proposal. I shall retitle this bug and start the count down as soon as I get another second (I am saying that since it seems to me that the proposal I submitted is not controversial and can be handled quickly, reducing the number of open issues on policy). manoj not responsible for his sig generator -- You cannot see the wood for the trees. John Heywood Manoj Srivastava [EMAIL PROTECTED] http://www.datasync.com/%7Esrivasta/ Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Re: NAG messages.
On Wed, Sep 23, 1998 at 12:06:39PM -0400, Brian White wrote: I don't care that you don't want to remove people. This is unsolicited spam and I want you to stop sending it to me. This is untrue and you know it. You're registered as a Debian developer and all the perks/requisites that come with it. So if I unilaterally decide to set up an email service that reminds developers weekly what packages they have with lintian-warnings, that's automatically a Debian perk or requisite? I don't think so. I don't see the nag messages written anywhere as official policy, and I don't think they should be. Dale should be free to opt out of that system if he chooses. If this results in him neglecting to fix bugs in his packages for an egregious amount of time, there are always NMU's or simple reassignment of his packages to someone else. I, for one, doubt that Dale's removal from the nag list would result in any such irresponsibility. Please do not misrepresent your unilateral decisions as consensus by the corpus of the Debian devlopment community. If I am mistaken about the official status of the nag messages, please bring the relevant policy document to my attention. -- G. Branden Robinson | There's nothing an agnostic can't do Purdue University | if he doesn't know whether he believes [EMAIL PROTECTED] | in it or not. http://www.ecn.purdue.edu/~branden/ | -- Graham Chapman pgpxU4IWwRC0Z.pgp Description: PGP signature
Re: NAG messages.
On Wed, Sep 23, 1998 at 01:16:09PM -0400, Brian White wrote: I would be happy to comply with your request except that it no longer has any basis. You complained because you received hundreds of unrequested emails. That will never happen again. So why do you continue to complain? Dale is completely within his legal rights to request the cessation of unsolicited mail of any nature from any party. All Debian developers have that right, and we should respect it. Of course, refusing to receive certain kinds of mails is incompatible with one's retention of status as a Debian developer. Brian, do you contend that your nag messages (be they one or one hundred) are so important that Dale must be removed from the Project if he doesn't want to receive them? If so, I suggest you draft a policy proposal forthwith to legitimize your claim (and in the meantime, suspend the nagging of Dale). If not, I suggest you please grant Dale's request. It's a simple act of courtesy. -- G. Branden Robinson | Purdue University | Exercise your freedom of religion. Set [EMAIL PROTECTED] | fire to a church of your choice. http://www.ecn.purdue.edu/~branden/ | pgp31jth6Ry16.pgp Description: PGP signature
Bug#7890: {PROPOSAL} #7890: Policy manual contradicts itself about including docs
Manoj Srivastava [EMAIL PROTECTED] writes: Adam Yes, I mostly agree. Does that mean you second the proposal? I suggest we implement this part of the proposal first, and leave the issue of the source of the documentation to another ptoposal, since that is turning out to be controversial. This proposal has only one second at the moment. I would like to see if there are others, and to move the non-controversial part of the proposal out of the way. Yes, I second. I agree that the controversial part is worthy of it's own report (and is low priority too). .A. P. [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: NAG messages.
I would be happy to comply with your request except that it no longer has any basis. You complained because you received hundreds of unrequested emails. That will never happen again. So why do you continue to complain? Dale is completely within his legal rights to request the cessation of unsolicited mail of any nature from any party. All Debian developers have that right, and we should respect it. They do and I have in the past (packages, actually, not maintainers). The simple truth of this is that Dale refuses to conceed that any solution other than the one he proposed could possible solve the problem in a better way. The way I read it is that he continues to fight for what he asked for instead of what he claimed he wanted with his original hundreds of emails argument (which has been ripped from beneath him). He is unwilling to even give the new system a try, insistant that what he asked for was the correct solution regardless of the reasons why. Brian ( [EMAIL PROTECTED] ) --- `My name is Ozymandias, King of Kings: Look upon my works, ye Mighty, and despair!' Nothing besides remains. Round the decay of that colossal wreck, boundless and bare, the lone and level sands stretch far away. -- Shelly
Re: NAG messages.
On Wed, Sep 23, 1998 at 03:20:09PM -0400, Brian White wrote: Dale is completely within his legal rights to request the cessation of unsolicited mail of any nature from any party. All Debian developers have that right, and we should respect it. They do and I have in the past (packages, actually, not maintainers). The simple truth of this is that Dale refuses to conceed that any solution other than the one he proposed could possible solve the problem in a better way. The fact that you think his justification for his request is unreasonable doesn't mean he doesn't have the right to make the request. Having the right to request the cessation of unsolicited mail does not mean one is obligated to justify that request to the satisfactor of the one sending the unsolicited mail. I imagine no one could ever convince commercial spammers to quit with such tactics. That's why there are efforts to legislate against such abuse. -- G. Branden Robinson | When I die I want to go peacefully in Purdue University | my sleep like my ol' Grand Dad...not [EMAIL PROTECTED] | screaming in terror like his passengers. http://www.ecn.purdue.edu/~branden/ | pgpXpaZbiVF7x.pgp Description: PGP signature
Re: Documentation license problem solved: OpenContent License (OPL)
On Thu, Sep 24, 1998 at 12:54:06AM +0200, Jens Ritter wrote: OpenContent wants to make sure the content is free GPL wants to make sure the source is with you -- always. Currently, you are right. This is the reason why David made up a group. Maybe the old license should be removed from the website, as it does not reflect the current development. GPL applied to documentation ensures the content is free, or doesn't it? I'm not sure. The terms are at least confusing when applied to something other than software. Note that texinfo files from the GNU project are not covered by the GPL but by another license (much shorter and clearer). The goal of OpenContent is to write a license which is as free as the GPL but more clear and applicable to all data entities without guessing about the actual meaning. Thank you, Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: Documentation license problem solved: OpenContent License (OPL)
On Tue, Sep 22, 1998 at 11:24:03AM -0700, Ben Gertzfield wrote: I think our ongoing problem of finding an appropriate license for documentation has been solved. On slashdot.org today, an article about the OpenContent License (OPL, pronounced 'opal') was posted. Hello Ben, this really does surprise me now, as I've more or less been appointed (there were no objections) to be the official contact person for Debian to the OpenContent group. Please read in debian-private archive, starting from message Subject: request for approval [EMAIL PROTECTED]: Participation in Ad Hoc Group] Message-ID: [EMAIL PROTECTED] The current license has several problems, and David has build up a mailing list and a nice small group to work on it. The major consideration at the time I asked on debian-private about it was the question which position Debian holds. I answered that the goal was and is to write a free license, so it is a constructive goal. A license that complies to the dfsg. I also started a long discussion about eventual license terms, and this was the start of the whole discussion. Now, the ideas have to be incorporated in the license. We only started with it, and this will take some time. So, the OpenContent license should not be used, please wait until the OpenContent group will release a new license, which has hopefully solved some of the major problems. Gordon has mentioned the biggest problem, the notion of a source format. This will be adressed in the next version of the license. I don't agree with Gordon that the GPL is usable for documentation and other data entities. The terms are solely usable for software, and if you can't apply them to data entities, the terms of the license don't apply (so it does nullify itself). Please also take into account that the initiator (David Wiley) wants to use the license for learning objects, and we think we can write a general license for learning objects, pictures, books etc. The license will be GPL compatible, though. In fact, the GPL is very close to a good license for data entities, but the terms have to be clarified (for example, I've seen a GPL'ed book in a bookstore, and it had the remark how the terms of the GPL are applied to the book is left to the authors. Reproducing the printed book was explicitely forbidden. There's something wrong here). Also keep in mind that the LDP is implementing a (book specific) new license. Maybe we can join such efforts in the future. To put a long remark short: The contact to OpneContent is already build up and active, and as soon as something remarkable comes out of it, I'll let all of you know. Thank you, Marcus -- Rhubarb is no Egyptian god.Debian GNU/Linuxfinger brinkmd@ Marcus Brinkmann http://www.debian.orgmaster.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Re: Documentation license problem solved: OpenContent License (OPL)
Marcus == Marcus Brinkmann [EMAIL PROTECTED] writes: Ben I think our ongoing problem of finding an appropriate license Ben for documentation has been solved. Ben Ben On slashdot.org today, an article about the OpenContent Ben License (OPL, pronounced 'opal') was posted. Marcus this really does surprise me now, as I've more or less Marcus been appointed (there were no objections) to be the Marcus official contact person for Debian to the OpenContent Marcus group. Please read in debian-private archive, starting Marcus from message You're right. I'm sorry, I guess I missed the old discussion. :) *snip excellent discussion* Marcus To put a long remark short: The contact to OpneContent is Marcus already build up and active, and as soon as something Marcus remarkable comes out of it, I'll let all of you know. Okay. Thank you for setting the matter clear, Marcus. :) Ben -- Brought to you by the letters F and A and the number 13. It is sad. *Campers* cannot *dance*. Not even a *party*. -- Orz, SCII Debian GNU/Linux -- where do you want to go tomorrow? http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet and YiffNet IRC as Che_Fox.
/usr/doc/*/changelog required ?
A question regarding the /usr/doc policy: Python builds several packages from a single source. Until now, I kept all documentation in /usr/doc/python. The package's doc directories had only the copyright file (as requested by the policy) and a README.Debian that pointed the user to /usr/doc/python. IIRC, this was the proposed solution at that time. But now, lintian issues an error debian-changelog-file-missing for all these packages. The policy doesn't say that it's required to have the changelog in /usr/doc for every single package. Should I remove those sparse doc directories and instead install /usr/doc/PACKAGE as link to /usr/doc/python ? Gregor
Re: clarification of statement in packaging manual requested
James A. Treacy wrote: In section 7 of the Debian Packaging Manual it is stated: Every package should also have an extended description. I just wanted clarification on whether the 'should' is intentional or whether it should be 'must'. As the package descriptions are important it should be mandatory that every package provide one. The policy manual seems to use `should' and `must' interchangeably for mandatory things and `should usually' for optional things. The strongest example of a mandatory `should' is in section 3.1.2: As mandated by the FSSTND no package should place any files in `/usr/local', either by putting them in the filesystem archive to be unpacked by dpkg or by manipulating them in their maintainer scripts. Richard Braakman
Policy: library sonames
I had been under the impression that Debian had a written policy of respecting upstream choices for sonames, when possible, but when I checked today, I couldn't find it in the policy manual. (I believe it would go in section 3.3.3.) I think that this is an unwritten policy of Debian (I have been told that it is a policy of Red Hat). I'd like to see it in the policy manual: Shared libraries should use the upstream soname, when possible. The purpose of this is to maintain compatibility between distributions. (Here, by when possible, I mean: when it doesn't cause a conflict with another library or an incompatible version of the same library.) On a similar point, it would also be nice to have a policy about interlibrary references, namely: If a shared library calls functions in another library, then it should be explicitly reference the other library. (This is done with the -l option when the library is created.) The purpose of this is to improve the stability of programs. It makes it much easier to detect mismatched libraries both at link time and runtime. (It is particularly useful at detecting link-time problems.) Debian, in general does a very good job of adhering to both of these rules. In particular, adherence to the second rule, in combination with the packaging system, has saved Debian from a lot of the headaches that Red Hat is having with their gnome packages. (Lots of library mismatch problems - some occuring undetected at runtime.) Nonetheless, it would be nice to have them set down in the policy manual. (BTW, libjpeg6b_6b-1 has the wrong soname.) Steve [EMAIL PROTECTED] (CC: me or debian-devel, if you want me to read the response.)
