Re: a question about BTS severities
Herbert Xu wrote: Joey Hess [EMAIL PROTECTED] wrote: Similarly, I don't think a bug is grave if it makes a package unusable by just one person in an odd sitution. On the other hand, I think all security and data loss bugs are grave, even if only a few people can trigger them. I disagree. If a package causes a remote root exploit to be available, even if it's only in a very specific configuration, I would say that it is critical. No, it's grave. All security bugs are grave, it's part of the definition of that priority. And later in my message, I said: Similarly, I don't think a bug is grave if it makes a package unusable by just one person in an odd sitution. On the other hand, I think all security and data loss bugs are grave, even if only a few people can trigger them. -- see shy jo
Attention Herbert Xu: FWD: failure notice
Your mail is bouncing. - Forwarded message from [EMAIL PROTECTED] - Date: 27 Sep 1999 23:14:48 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: failure notice Hi. This is the qmail-send program at kitenet.net. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: Connected to 203.14.152.114 but sender was rejected. Remote host said: 550 Access denied --- Below this line is a copy of the message. Return-Path: [EMAIL PROTECTED] Received: (qmail 19669 invoked by uid 500); 27 Sep 1999 23:14:43 - Date: Mon, 27 Sep 1999 16:14:43 -0700 From: Joey Hess [EMAIL PROTECTED] To: Herbert Xu [EMAIL PROTECTED] Cc: debian-devel@lists.debian.org Subject: Re: a question about BTS severities Message-ID: [EMAIL PROTECTED] Mail-Followup-To: Herbert Xu [EMAIL PROTECTED], debian-devel@lists.debian.org References: [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0pre2i In-Reply-To: [EMAIL PROTECTED] Herbert Xu wrote: Joey Hess [EMAIL PROTECTED] wrote: Similarly, I don't think a bug is grave if it makes a package unusable by just one person in an odd sitution. On the other hand, I think all security and data loss bugs are grave, even if only a few people can trigger them. I disagree. If a package causes a remote root exploit to be available, even if it's only in a very specific configuration, I would say that it is critical. No, it's grave. All security bugs are grave, it's part of the definition of that priority. And later in my message, I said: Similarly, I don't think a bug is grave if it makes a package unusable by just one person in an odd sitution. On the other hand, I think all security and data loss bugs are grave, even if only a few people can trigger them. -- see shy jo - End forwarded message - -- see shy jo
Re: a question about BTS severities
Joey Hess [EMAIL PROTECTED] wrote:
Herbert Xu wrote:
I disagree. If a package causes a remote root exploit to be available, even
if it's only in a very specific configuration, I would say that it is
critical.
No, it's grave. All security bugs are grave, it's part of the definition of
that priority. And later in my message, I said:
Actually, it should be critical if it's a root exploit. Grave only includes
those that only comprise the user's account.
Similarly, I don't think a bug is grave if it makes a package unusable by
just one person in an odd sitution. On the other hand, I think all security
and data loss bugs are grave, even if only a few people can trigger them.
Sorry for missing that bit.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: /usr/share/doc?
On Mon, Sep 27, 1999 at 03:35:12PM -0400, Peter S Galbraith wrote: package itself due to problems with dpkg. One reasonable way to accomplish this is to put the following in the package's postinst: if [ $1 = configure ]; then if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# -a -d /usr/share/doc/#PACKAGE# ]; then ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE# fi fi And the following in the package's prerm: if [ \( $1 = upgrade -o $1 = remove \) -a -L /usr/doc/#PACKAGE# ]; then rm -f /usr/doc/#PACKAGE# fi ok, that stuff sounds good, does work but lintian doesn't like it. lintian prefers a naked rm -f in prerm. what to do? -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://www.freeweb.org/free/cavok/
Re: a question about BTS severities
Herbert Xu wrote: Joey Hess [EMAIL PROTECTED] wrote: Herbert Xu wrote: I disagree. If a package causes a remote root exploit to be available, even if it's only in a very specific configuration, I would say that it is critical. No, it's grave. All security bugs are grave, it's part of the definition of that priority. And later in my message, I said: Actually, it should be critical if it's a root exploit. Grave only includes those that only comprise the user's account. Last I checked, root is a user. This is not a formal definition we're working from, please use common sense. (Note: grave is a _higher_ priotity than critical. Note also: root exploits tend to turn into user account exploits as soon as the attacker wants them to.) -- see shy jo
Re: a question about BTS severities
* Joey == Joey Hess [EMAIL PROTECTED] wrote: Joey (Note: grave is a _higher_ priotity than critical. I don't think so. http://www.debian.org/Bugs/Developer#severities The severity levels are: critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. grave makes the package in question unuseable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. Ciao, Martin
Re: Useless packages (was Re: anarchism_7.7-1.deb)
On Mon, Sep 27, 1999 at 11:43:50AM +0100, Matthew Vernon wrote: David Starner writes: Instead of each developer chose what packages are and aren't useful to them, why don't we look at the popularity contest? A simple, bias-free way of seperating programs on to the CD's, by actual use. That is what it was made for. And how difficult would it be to fiddle the results of this??? Not very. So? It shouldn't be hard to detect, and it's not a big deal for the most part. As for the other guy, talking about world domination - that's what you have to do to get world domination. If it ever gets near that point, then Debian will have to consider whether that's what the developers want to be working on. As for a realistic, near term (next 3 years) event it's rather implausable. David Starner - [EMAIL PROTECTED]
Re: a question about BTS severities
In article [EMAIL PROTECTED] you wrote: What do other think, and have you seen seeing the same runaway bug severity inflation I have? Yes. Submitters seem to think that if they crank up the severity, the bug will get more/quicker attention. At least in my case, that just isn't true. I'm not at all shy about lowering the severity of bugs submitted against my packages that are reported with excessive severity. Bdale
Re: /usr/share/doc?
On Mon, Sep 27, 1999 at 11:19:05PM +0200, [EMAIL PROTECTED] wrote: On Mon, Sep 27, 1999 at 03:35:12PM -0400, Peter S Galbraith wrote: package itself due to problems with dpkg. One reasonable way to accomplish this is to put the following in the package's postinst: if [ $1 = configure ]; then if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# -a -d /usr/share/doc/#PACKAGE# ]; then ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE# fi fi And the following in the package's prerm: if [ \( $1 = upgrade -o $1 = remove \) -a -L /usr/doc/#PACKAGE# ]; then rm -f /usr/doc/#PACKAGE# fi ok, that stuff sounds good, does work but lintian doesn't like it. lintian prefers a naked rm -f in prerm. what to do? -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://www.freeweb.org/free/cavok/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] As of the latest upload of lintian, it does not like shell variables in the place of the package name.. it looks for \w+ after the /usr/doc/ -- Please cc all mailing list replies to me, also. = * http://benham.net/index.html[EMAIL PROTECTED] * * * ---* * Debian Developer, Debian Project Secretary, Debian Webmaster * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * * [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] * = pgpHnbTlwJ7qF.pgp Description: PGP signature
ITP: bonobo
The bonobo framework for GNOME componentry has just hit its first public release. I intend to package it up. See attachment for details. Mike. ---BeginMessage--- Hello guys, I have just released the first public version of Bonobo (bonobo-0.4), the GNOME component system and compound document system. Bonobo has been on development for about ten months and it is almost ready. This release is still an alpha version of the code, but it will enable people to try out Bonobo and some of the GNOME applications that depend on Bonbo (the PDF file viewer, the Gnumeric Bonobo extensions, the new file manager and a few other toys). Keep in mind that the API *will* change (not a lot, but it will change), I will try to keep the API changes well documented though. * Availability ftp://ftp.gnome.org/pub/GNOME/sources/bonobo/bonobo-0.4.tar.gz * What does Bonobo 0.4 provide . The GNOME component foundation based on the GNOME::Unknown CORBA interface. Component can be graphical and non-graphical. . The Bonobo framework for building new components using the Gtk object system. . Structured Storage interfaces for loading/saving compound documents. . The interfaces for visual component embedding, both simple rectangule-based embeddings (GtkWidget embedding) as well as arbitrarly-shaped components. * Still left to do We could use the help of various people to help improve various things in Bonobo: . API documentation layout should be improved as well as adding introductory pieces to various Bonobo pieces. . A web page tracking down the development and carrying out information about Bonobo as well as a software map for Bonobo-based components. * Upcoming Changes . I am expecting to provide control support for the next Bonobo version (ie, creating components that have a single view) as well as providing a way to load/save their state using properties (you can see the interface in idl/gnome-control.idl). . The Shaped components and the Views might have an API change to make them more sensible, it is sort of hacked right now. . Bounding box support for the arbitrarly shaped components as well as activation/deactivation for those. * The Bonobo Team The Bonobo core team is: Dietmar Maurer (libefs hacker) Elliot Lee (CORBA guardian angel). Ettore Perazzoli (Bonobo hacking device #2). Federico Mena (Bonobo helper). Matt Loper (Persistent hacker). Michael Meeks (Bonobo and component hacker) Miguel de Icaza (main designer/implementor) Nat Friedman (Bonobo hacking device) Bonobo components/GUI is: Chris Lahey (Audio/ulaw). Richard Hestilow (Bonobo dialog hacker) Bonobo maintainers: Miguel de Icaza ([EMAIL PROTECTED]) Nat Friedman ([EMAIL PROTECTED]) * Mailing lists [EMAIL PROTECTED] To subscribe, send mail to [EMAIL PROTECTED] and in the body of the message put the word subscribe. Archive of the mailing list is available at: http://www.gnome.org/mailing-lists/archives/gnome-components-list Enjoy! Miguel. -- FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject. ---End Message---
Re: a question about BTS severities
On Mon, Sep 27, 1999 at 05:30:51PM -0700, Joey Hess wrote:
Actually, it should be critical if it's a root exploit. Grave only includes
those that only comprise the user's account.
Last I checked, root is a user. This is not a formal definition we're
working from, please use common sense. (Note: grave is a _higher_ priotity
than critical. Note also: root exploits tend to turn into user account
exploits as soon as the attacker wants them to.)
Root may be a user, but he is a special one at that :) root has privileges
that no other users have. If a user account was compromised, the attacker
is only able to perform tasks that user was allowed to, however, if the
root account is compromised, then that implies the compromise of all user
accounts on that machine, and things like using privileged ports, or
doing port IO, etc.
Also, AFAIK, critical is listed above grave (and important and others) in
all the relevant docos that I've seen.
--
Debian GNU/Linux 2.1 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Status of new packages in Incoming?
On Mon, Sep 27, 1999 at 11:22:32AM -0500, Steve Greenland wrote: I think the key difference is that if some one screws with the BTS or the Debian web site, it's not going to *me* any harm during the time it takes to discover and undo the damage. If someone installs a bad or malicious libc6 in the archive, a buncha people could get seriously screwed. Depending on mirror cycles and timing, I suspect it could take *days* to completely correct the damage in the archive and its mirrors, and who tells how long for the victims to correct their local situation. Which implies that we should validate packages against developer's key before install, and that we should have some kind of list indicating which developers are working on which package for which architecture which is maintained under tighter control than the mirrors. We probably don't want to forbid install if package is signed by the wrong key -- but we want to do everything we can to help the sysadmin examine the package under that circumstance. Also, we don't want to lock people in to just the Debian keyring. If they're getting packages from somewhere else they should be able to start trusting that source, if that's what they want. That, and people should be able to build up reputations. -- Raul
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
Craig Sanders [EMAIL PROTECTED] writes: [...] if it's free and it's packaged then we accept it into the dist in the location defined by policy - at the moment, that's debian main. we probably should, as has been discussed before, have an etexts and a data section for this kind of stuff. That's what I am asking for. if something is free and someone does the work to package it then we accept it in the distribution. There should be one for the main distribution. Assume I want to go into the CD business providing support for packages in the main dist. No major problem with most of the packages, but I am not willing to support packages with philosophical, political or religious contents. that's ludicrous. what support is needed for texts? customer: i can't read foo-text. tech support: have you tried opening your eyes sir? customer: I don't get verse to show me my daily devotional support: Use your brain. More serious: customer: I found a typo ... |I don't understand that ancient word (very likely in over here) |Luther's bible says ... but what you sold me is completely different. |Why do you include philosophical texts support: Sorry, if you buy Debian, you always get it. The opinions expressed in Debian packages are not necessarily ours. At present it's a bit biased since no one volunteered to package opposite views. -- noch nichts Aufregendes: Siggy Brentrup - [EMAIL PROTECTED] - voice: +49-441-6990134
Re: a question about BTS severities
On 27-Sep-99, 11:33 (CDT), Joey Hess [EMAIL PROTECTED] wrote: grave makes the package in question unuseable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. I've noticed that in many of the cases where I think the bug has too high severity, the bug doesn't affect all users of the package. A specific example: I've a rvplayer bug saying that it segfaults, marked important. But since people have been using that binary for about 9 months, with general success (and since the package in question is only in stable, and has not changed in any way in that time period), the bug is clearly not affecting everyone, or even many people. It's clear to you, but perhaps not to the user who submitted it; for him/her, it makes the package in question unuseable. You look at it, realize that it's unique to that user, and send a message to [EMAIL PROTECTED] to re-priotize it. What's the big deal? I think we should clarify the description of important to note that the bug has to affect a large group of people to be important severity. Similarly, I don't think a bug is grave if it makes a package unusable by just one person in an odd sitution. On the other hand, I think all security and data loss bugs are grave, even if only a few people can trigger them. I agree with this conceptually, but again, it doesn't seem like that big a deal to me. Steve -- Steve Greenland [EMAIL PROTECTED] (Please do not CC me on mail sent to this list; I subscribe to and read every list I post to.)
Re: anarchism_7.7-1.deb
On Sun, 26 Sep 1999, Ed Boraas wrote: I can't help but infer from this statement that you feel the anarchism package is of low worth. If this was not your intent, please feel free to clarify. For myself, no I don't. But it is only a concern of Debian if for instance there was a real space crunch or something. Mainly I was trying to address the notion that such choices couldn't be made or Debian would lose it's soul (if some people will pardon the expression :-) if it did. or if you remove one you have to remove them all etc. I don't believe those are good arguments. The concept of worth is by its nature a qualitative assesment, and therefore subjective. I would be inclined to say that it would be impossible to correctly judge the worth of a given package. Nevertheless, there are other properties we can consider: general quality and fitness for a particular purpose. For instance, if a package is ridden with bugs (be they shortcomings in code, or grammatical errors in text), one could judge it to be of low quality, possibly low enough to warrant removing it from the distribution. Contextual fitness, on the other hand, rates a package as having worth in a particular situation. Sure, the anarchist FAQ may not be useful in learning to write applications in GTK+, but that doesn't mean it's not applicable to debian's userbase. Probably many users of debian will never find use for the anarchism package. So be it. The fact remains that there are quite a few debian users who do find it useful. [The number of emails i got when i was late packaging the most recent version of the FAQ is testament to that. g] Well I have no problems whatsoever with that. In fact the more we know about what our users like the better we can make Debian. We should ask. Maybe it's time we had some market research. Not the we can increase sales 18% if we put a pink stripe on the box kind but some kind of survey of who exactly our users our and what they like and dislike. There are some logistical problems in doing this right so i'm going to think about this a bit and comeback with a proposal before saying anymore. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: a question about BTS severities
Steve Greenland wrote: It's clear to you, but perhaps not to the user who submitted it; for him/her, it makes the package in question unuseable. You look at it, realize that it's unique to that user, and send a message to [EMAIL PROTECTED] to re-priotize it. What's the big deal? Aside from the waste of my time in doing this, and then the additional time wasted when the user writes back in to try to justsify their choice of severity, none. But I'd rather be fixing the bug report. I only have 8 to 10 hours a day to work on debian. -- see shy jo
Re: Status of new packages in Incoming?
Raul Miller wrote: Which implies that we should validate packages against developer's key before install, and that we should have some kind of list indicating which developers are working on which package for which architecture which is maintained under tighter control than the mirrors. We probably don't want to forbid install if package is signed by the wrong key -- but we want to do everything we can to help the sysadmin examine the package under that circumstance. As I have already posted, the situtation you are talking about is the status quo. And as far as I know nobody has gotten a trojan package in to Incoming, so I'm confused why you are try to fix what's not broken. I hope we get signed packages RSN. We need them badly, for completly unrelated reasons. However, I am firmly opposed to any system that makes it harder to do NMU's, and what you're proposing seems to do that. -- see shy jo
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On 28 Sep 1999, Siggy Brentrup wrote: More serious: Hahaha. customer: I found a typo ... |I don't understand that ancient word (very likely in over here) | Luther's bible says ... but what you sold me is completely different. |Why do you include philosophical texts support: Sorry, if you buy Debian, you always get it. The opinions expressed in Debian packages are not necessarily ours. At present it's a bit biased since no one volunteered to package opposite views. Oh for crying out loud. I apologize to the entire list for my part in bringing about this silliness. -- Jaldhar H. Vyas [EMAIL PROTECTED]
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Tue, Sep 28, 1999 at 12:05:37AM -0400, Jaldhar H. Vyas wrote: Why even involve debhelper? At least in the case of the Project Gutenberg files some of which I have, they are just long ascii files so the rules file could just stick them into (for example) /usr/share/doc/etexts call doc-base and be done with it. AFAIK all the project Gutenberg files are public domain so one generic fill in the blanks copyright file would suffice. Voila you almost instantly have 2000 works containing more than a gig of text. I'd buy such a CD if it were offered. And I know plenty of people who would too. Works for me. Real question is: does anyone care enough to bother? Alternate question: why do we even have to package up flat text files? Why can't we just import them into debian in some regular manner? [I can see that naming convention is important, but are there any other issues beyond that? -- I mean, besides the issue of the current implementation of dpkg.] -- Raul
Re: /usr/share/doc?
On Mon, Sep 27, 1999 at 06:10:58PM -0700, Darren O. Benham wrote: As of the latest upload of lintian, it does not like shell variables in the place of the package name.. it looks for \w+ after the /usr/doc/ Please fix that. I'm not going to add to the possibility of a major screwup by editing the code. I just edit the shell variable which is defined at least one line away from the magic code. -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% (John Cage)
Re: [RHSA-1999:035-02] Updated XFree86 3.3.5 packages available
My apologies if you replied to the mail quoted below; I never received one. As far as I can tell, Red Hat's webpages have not been updated with the corrected information. Are there any plans to do so? On Mon, Sep 20, 1999 at 12:30:04AM -0400, branden wrote: Hi Preston, In Red Hat's recent announcement, there is the following text: Thanks go to Branden Robinson [EMAIL PROTECTED] for discovering a possible symlink attack in the xkb extension initialization at server startup time. I appreciate the mention, but I cannot claim credit for having discovered this vulnerability. Credit for that, as far as I know, goes to Olaf Kirch [EMAIL PROTECTED], who announced it to the vendor-sec list. I did, however, author the fix, which was accepted into the XFree86 source tree upstream and which I mailed to you. -- G. Branden Robinson | Debian GNU/Linux | Music is the brandy of the damned. [EMAIL PROTECTED] | -- George Bernard Shaw cartoon.ecn.purdue.edu/~branden/ | pgpH6G0QmzqUj.pgp Description: PGP signature
Re: Re^2: strange behavior of dh_dhelp
* Marco == Marco Budde [EMAIL PROTECTED] wrote: Hi, Am 25.09.99 schrieb roland # spinnaker.de ... RR It is always a good idea to use a generic format which can RR automatically converted to all useful formats instead of using one RR special format. Marco No, sorry, but this is wrong. Why should we convert files Marco during the installation process? There#re two better solutions: Marco 1) All programs use the same file format. 2) You can convert Marco the files during dpkg- buildpackage offline. To 1), I propose dhelp and dwww read doc-base files directly. To 2), this is a _very_ bad idea. How many packages still support dwww, but not dhelp? How long did it take to bring support for dhelp into the packages? If doc-base had been around form the beginning, everyone would have used it instead of creating specific dwww support. As soon as a new package like dhelp is installed into the distribution, it is supported by _every_ package having registered documentation. Converting to the different formats during package build is a _very_ bad idea. RR If you think, that install-docs is too slow and dhelp-parse in Marco One reason to write dhelp was the speed of dwww. This is a completely different thing. install-docs is run once during installation. This has nothing to do with dwww's speed, RR package that uses /usr/share/doc/pkg has to create a symlink RR /usr/doc/pkg pointing to /usr/share/doc/pkg. So all documentation RR should be available as /usr/doc/pkg. Marco No. A http daemon will never follow this symlinks. They#re 100% Marco useless when using the http protocol. *No*, this is not true. I can assure you, that my httpd follows these symlinks quite happily. Ciao, Martin
ITA: libforms
Since I need a new version of libforms myself I will adopt the package. However, I do not have the time to actively maintain it. I will try to fix as many bugs as possible but then libforms will be up for adoption yet again. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz| Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael@Fam-Meskes.De | Use PostgreSQL!
Swap setup on Debian
Hi, I've noticed when installing Debian that the installer always shrinks my swap partition to 128MB, so I have to do a swapoff;mkswap -v1 ..;swapon manually afterwards. Also, the message that it has done this is easily missed. Why doesn't the installer use -v1 so that larger swaps that 128MB can be used? Is this something that is going to be fixed when potato is released as the stable distribution? /Staffan
Re: ITP: pptpd
Is it okay to go into the primary distribution, or would it be forced into nonus? If it's okay for ftp.debian.org, I can sponsor it for you. I am not sure about this. pptpd itself should be ok in main, but the modified ppp and kernel packages (these are needed for the data encryption) contain RC4, MD4, MD5 and SHA codes with a key length of up to 128 bit. Please excuse my total ignorance of the algorithms at this point. I only know from the source codes that these algorithms are used and that MPPE (Microsoft Point-to-Point Encryption) is used with up to 128 bit encryption. Another problem is that the Microsoft-crypto patches for pppd and the kernel ppp implementation contain code with this license: /* crypto/sha/sha.h */ /* Copyright (C) 1995-1997 Eric Young ([EMAIL PROTECTED]) * All rights reserved. * * This package is an SSL implementation written * by Eric Young ([EMAIL PROTECTED]). * The implementation was written so as to conform with Netscapes SSL. * * Added Microsoft's Get_Key() per mppe draft by mag [EMAIL PROTECTED] * * This library is free for commercial and non-commercial use as long as * the following conditions are aheared to. The following conditions * apply to all code found in this distribution, be it the RC4, RSA, * lhash, DES, etc., code; not just the SSL code. The SSL documentation * included with this distribution is covered by the same copyright terms * except that the holder is Tim Hudson ([EMAIL PROTECTED]). * * Copyright remains Eric Young's, and as such any Copyright notices in * the code are not to be removed. * If this package is used in a product, Eric Young should be given attribution * as the author of the parts of the library used. * This can be in the form of a textual message at program startup or * in documentation (online or textual) provided with the package. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: *This product includes cryptographic software written by * Eric Young ([EMAIL PROTECTED]) *The word 'cryptographic' can be left out if the rouines from the library *being used are not cryptographic related :-). * 4. If you include any Windows specific code (or a derivative thereof) from *the apps directory (application code) you must include an acknowledgement: *This product includes software written by Tim Hudson ([EMAIL PROTECTED]) * * THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * The licence and distribution terms for any publically available version or * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] */ I think it will have to go into non-free, but I am not sure about non-US. I am CC-ing this to debian-devel in th hope that somebody can answer if the codes have to go into non-US. thanks Rene
Re: /usr/share/doc?
On Mon, Sep 27, 1999 at 10:47:38PM -0400, Peter S Galbraith wrote: I get no error with lintian version 1.7 you are right. i was completely wrong last night. i leaved #PACKAGE# entries despite of the real package name!!! no comment -[ Domenico Andreoli, aka cavok [EMAIL PROTECTED] --[ get my public pgp key at http://www.freeweb.org/free/cavok/
Lizard / Debian
I have read this morinig ,, that lizard from caldera has gone open to the public.( I might be slow to discover this) My question is : Has Debian got any interest in this , and is there anny plans for future releases made to make use of the Lizard. I am pretty sure that this software will give Debian a great boost. Regards Wayne. Here are the links to Lizard. http://www.openlinux.org/lizard/qpl.html http://www.openlinux.org/lizard/
Re: Lizard / Debian
On Tue, Sep 28, 1999 at 11:59:47AM +0200, wayne forrest wrote: My question is : Has Debian got any interest in this , and is there anny plans for future releases made to make use of the Lizard. Personally, I would say Yes it is interesting, BUT: Lizard is released under the QPL, which is incompatible to the GPL. I'm quite sure that somehow this will prevent us from using it without worrying about license issues again. But I hope someone can prove me wrong in that respect. Thomas -- GnuPG: ID=B0FA4F49, PGP2: ID=2EA7BBBD http://www.debian.org/debian/doc/debian-keyring.tar.gz pgpT7bUVPdSmw.pgp Description: PGP signature
Re: Re^2: strange behavior of dh_dhelp
On Mon, Sep 27, 1999 at 06:56:00PM +0100, Marco Budde wrote:
RR I just installed it, but as far as I can see this doesn't integrate
RR FHS and FSSTND
Right, because this is not possible.
Counter-example:
(
dump() {
lynx -dump -source -width=1000 $1 |
sed 1,7d;s-^HREF=\-HREF=\$2/- |
perl -pe 'unless (m(/A)) {chop; $_.= }'
}
dump /usr/share/doc fhs
dump /usr/doc fsstnd
) | (
echo 'HTMLHEADTITLEDocumentation/TITLE/HEADBODY'
sort -u -t '' -k 3
) docs.html
--
Raul
mtools
How comes mtools depend on xlib6g? I don't use X, and thus I consider it very stupid to have both xlib6g xfree86-common installed, but I have to if I want mtools installed... Rationale? If there's no good explanation, I'll submit a bug-report. And if there's something in xlib6g that mtools really needs, why not break it out of xlib6g and make it a separate package? Oh, and why does xlib6g depend on xfree86-common? Wouldn't it be more natural the other way around only? /David Weinehall _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire /
Re: Packages should not Conflict on the basis of duplicate funct
On Mon, 27 Sep 1999, Sean 'Shaleh' Perry wrote: b) if you know what you are doing, compile the packages by hand, fix their install scripts, and remove the conflicts. You are trying to circumvent the norm. But I think, to be fair, that what he's proposing *isn't* necessarily `not the norm' -- any decent-sized ISP could easily have cause to do this, and it would seem better just to tweak the packages slightly to let them both install than make a back-to-the-grindstone exercise. Debian is operating on making the easy case easy. 90+% of our users want to just install a package and go. Oh jeezus. This sounds like a Microsoft slogan. I thought Debian was about handling every case -- for the novice, to the guru -- flexibly, powerfully and elegantly. I had no such idea that was a lowest common denominator appeal element here. It sounds like a crude idea/slogan to try and reverse ratings like PCPlus hands out: Debian -- for pros, don't touch it (which I agree is a problem). -- Chris [EMAIL PROTECTED] ( http://www.fluff.org/chris )
warning: lilo 22dev0-1 can make your system unbootable !
Package: lilo Version: 22dev0-1 it bootet only 2.0.36, but booting 2.2.12 gave a crc error - system halted when unpacking. after replaceing lilo with the old 21-5 version, it works again. andreas
Re: strange behavior of dh_dhelp
Marco Budde [EMAIL PROTECTED] wrote: RR It is always a good idea to use a generic format which can RR automatically converted to all useful formats instead of using RR one special format. No, sorry, but this is wrong. Why should we convert files during the installation process? There#re two better solutions: 1) All programs use the same file format. Okay, simply change dhelp to use the doc-base directly and were are done. 2) You can convert the files during dpkg-buildpackage offline. That's a bad idea, because this restricts you from adding new documentation systems which use another new format. Have a look how many packages still only support dwww and not dhelp. So you see, that creating these files at build time is a bad idea, while using a generic format like doc-base is much more flexible, because you only have to extend install-docs to support new formats and you're done (okay when installing the new documentation system the first time, you will have to run the new install-docs for all existing doc-base files once, but this shouldn't be a problem). RR documentation system next to dwww and dhelp (both are horribly RR broken at the moment, so another one may be a good idea) without RR changing all the packages. Why is dhelp broken? Because it doesn't support /usr/doc symlinks in the /usr/doc tree when the .dhelp file (created by a doc-base file) mentions the real (/usr/share/doc) path. RR If you think, that install-docs is too slow and dhelp-parse in One reason to write dhelp was the speed of dwww. Why do you mix the speed of install-docs and dwww here? The first one is run at install time, while the latter one is run at documentation browsing. As far as I can see one has nothing to do with the other. RR combination with dhelp2dwww.pl is so much faster, why don't you RR simply rewrite install-docs in C? Then we have a generic and RR fast solution. Because some authors are not interested to solve problems :(. We don#t need something like doc-base. When I read the second sentence, it seems that you're talking about yourself in the first one =;-) We need only a small shell script, that calls dwww and dhelp_parse. And we need *one* file format for dwww and dhelp. So why not use doc-base as this one file format? All file formats (doc-base, dhelp, menu,...) will have advantages and disadvantages. As far as I can see doc-base is a little bit more flexible than dhelp (the latter only supports HTML and no other formats) and doc-base is widely used and supported by debhelper and dh_make for a long time now. So doc-base may be a good compromise as the one file format. RR I just installed it, but as far as I can see this doesn't RR integrate FHS and FSSTND Right, because this is not possible. I think that it is possible, proposed that all packages which use only /usr/share/doc at the moment, will soon add a symlink in /usr/doc, to follow the technical committee decision. Than you only have to support /usr/doc with one problem: the doc-base and .dhelp files point to the real location in /usr/share/doc, while the files are also accessible via the symlink as /usr/doc/package. There needs to be some work around for this, but this should be possible with some Perl or Shell knowledge. There#s no solution for this problem, because dhelp supports reading documents via the local file system and via the http protocol. No problem when you see /usr/doc as the one and only directory for accessing the files. The documentation of every package should be available as /usr/doc/package in potato (this will change in the far future, but now we are working on potato). RR possible for most packages, because the tech-ctte decided that every Were can I read this? In the debian-ctte and debian-policy mailing lists and in the Debian weekly news as of September 7th, 1999: The technical committee has [8]spoken: /usr/doc/package will be provided as a symlink in FHS compliant packages. This started an avalanche of updated, FHS compliant packages. For implementation details, see [9]this message (debhelper will handle most of this automatically). 8. http://www.debian.org/Lists-Archives/debian-ctte-9909/msg00023.html 9. http://www.debian.org/Lists-Archives/debian-ctte-9908/msg00038.html I#ve found nothing about this in the latest policy. The policy 3.0.1 is broken in this point. It was a fault to change the complete policy to FHS without thinking about how to handle the migration from /usr/doc to /usr/share/doc. We couldn't find a compromise in debian-policy so the technical committee had to decide and they decided to create a farm of symlinks in /usr/doc to make every package documentation available as /usr/doc/package in potato. The symlinks have to be created and deleted by postinst and prerm, because otherwise dpkg will have problems with this. We are all waiting for the new policy, which will realize this decision. Maybe you noticed, that newer versions
Procedure Questions
Hello, I'm almost ready to upload a new release of PCCTS. It is based on a new upstream version in addition to containing some bug fixes. Also, the upstream source now also includes sorcerer and is seems appropriate to include sorcerer as part of PCCTS. The questions that I have are: 1. Who needs to be contacted about removing the sorcerer package? 2. Should I, at least temporarily, put include a package conflict for sorcerer in PCCTS? Thanks. -- Ed Petron [EMAIL PROTECTED]
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Tue, 28 Sep 1999, Jaldhar H. Vyas wrote: Why even involve debhelper? At least in the case of the Project Gutenberg files some of which I have, they are just long ascii files so the rules file could just stick them into (for example) /usr/share/doc/etexts call doc-base and be done with it. AFAIK all the project Gutenberg files are public domain so one generic fill in the blanks copyright file would suffice. Voila you almost instantly have 2000 works containing more than a gig of text. I'd buy such a CD if it were offered. And I know plenty of people who would too. I would, too. But I don't see the need to *package* large ascii files. What would be the difference between Gutenberg Debian-packaged and Gutenberg gzipped on CD or ftp? There *is* a difference for documents that require some technical setup to work (like the kjv-bible that needs a special viewer program) or are processed by other programs (like verse). Bjorn Brill [EMAIL PROTECTED] Frankfurt am Main, Germany
Re: mtools
On Tue, Sep 28, 1999 at 01:31:23PM +0200, David Weinehall wrote: How comes mtools depend on xlib6g? I don't use X, and thus I consider it very stupid to have both xlib6g xfree86-common installed, but I have to if I want mtools installed... Rationale? If something supports X it should be compiled with X. This means exactly two packages (xlib6g and xfree86-common) are also required, but they're reasonably smallish and anything which supports X is going to require them anyway, not just mtools. -- Joseph Carter [EMAIL PROTECTED] Debian GNU/Linux developer GnuPG: 2048g/3F9C2A43 - 20F6 2261 F185 7A3E 79FC 44F9 8FF7 D7A3 DCF9 DAB3 PGP 2.6: 2048R/50BDA0ED - E8 D6 84 81 E3 A8 BB 77 8E E2 29 96 C9 44 5F BE -- netgod my client has been owned severely netgod this guy got root, ran packet sniffers, installed .rhosts and backdoors, put a whole new dir in called /lib/ , which has a full suite of smurfing and killing tools netgod the only mistake was not deleting the logfiles netgod question is how was root hacked, and that i couldnt tell u netgod it is, of course, not a debian box * netgod notes the debian box is the only one left untouched by the hacker -- wonder why pgpd9JG2m7Fip.pgp Description: PGP signature
Re: Lizard / Debian
On Tue, Sep 28, 1999 at 11:59:47AM +0200, wayne forrest wrote: My question is : Has Debian got any interest in this , and is there anny plans for future releases made to make use of the Lizard. I am pretty sure that this software will give Debian a great boost. I am not so sure. First, I can't see much difference to our installation except that it has funky graphics, a hell lot of warnings allaround the place (EXPERS only. ONLY do that uf you KNOW what you are doing. Please use the default if you don't know what you do). Those get in the way if you know what you do. The package selection only allows one profile to be selected, not multiple. Then, they make the mistake of configuring everything in this tool. Video card, sound card, adding new logins etc. In short, it looks like a better yast. In Debian, we use a more distributed approach. What may be useful is to snarf some of the code and put it in various places (The qpl makes this hard, though). For example the mouse detection code, but only if it is really reliable (and I mean more reliable than the gpm mouse detection code, which is pretty good). And I don't think a tetris belongs in the installation program, point. I think with debconf we are on a better track. I don't want to say that Lizard is bad software, it is probably very good for what it does. But it doesn't fit into Debian, neither from the concept, nor from the implementation (has it a frontend which is usable over a serial line?), nor from the license (IMHO). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: mtools
On Tue, Sep 28, 1999 at 07:13:58AM -0700, Joseph Carter wrote: How comes mtools depend on xlib6g? I don't use X, and thus I consider it very stupid to have both xlib6g xfree86-common installed, but I have to if I want mtools installed... If something supports X it should be compiled with X. This means exactly two packages (xlib6g and xfree86-common) are also required, but they're reasonably smallish and anything which supports X is going to require them anyway, not just mtools. Better to fork off another package, which would include X support, and leave the original package X-free. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Tue, Sep 28, 1999 at 01:12:06AM -0400, Raul Miller wrote: Alternate question: why do we even have to package up flat text files? Why can't we just import them into debian in some regular manner? [I can see that naming convention is important, but are there any other issues beyond that? -- I mean, besides the issue of the current implementation of dpkg.] Exactly. A better designed package manager would support modular package format handling. then we could simply do (let's call the package manager hpm for now): hpm -i blacksteel.etheme instead dpkg -i etheme-blacksteel.deb hpm -i realvideo.tar.gz instead alien; dpkg hpm -i somestuff.rpm instead alien; dpkg hpm -i CPAN:mymodule hpm -i CTAN:mytexstyle hpm -i gutenberg:faust and so on. I think we will be able to do this in a few years, because we have to to cope with the grow of free information and data available. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: mtools
*- On 28 Sep, Josip Rodin wrote about Re: mtools On Tue, Sep 28, 1999 at 07:13:58AM -0700, Joseph Carter wrote: How comes mtools depend on xlib6g? I don't use X, and thus I consider it very stupid to have both xlib6g xfree86-common installed, but I have to if I want mtools installed... If something supports X it should be compiled with X. This means exactly two packages (xlib6g and xfree86-common) are also required, but they're reasonably smallish and anything which supports X is going to require them anyway, not just mtools. Better to fork off another package, which would include X support, and leave the original package X-free. What about the [x]emacs packages. I would hate to see forks of all those things on the mirrors. Maybe a Suggests or Recommends would be better than a Depends. -- Brian - Mechanical Engineering [EMAIL PROTECTED] Purdue University http://www.ecn.purdue.edu/~servis -
uscan and those debian/watch files?
I finally decided to try out uscan and those debian/watch files, but I can't get it to work: $ more /opt/gri/src/deb/2.2.1/gri-2.2.1/debian/watch # Example watch control file for uscan # Rename this file to watch and then you can run the uscan command # to check for upstream updates and more. # Site Directory Pattern Version Script ftp.phys.ocean.dal.ca users/kelley/gri/ gri-*.tgz debian uupdate $ uscan /opt/gri/src/deb/2.2.1/gri-2.2.1/ -- Scanning for watchfiles in /opt/gri/src/deb/2.2.1/gri-2.2.1/ -- Found watchfile in /opt/gri/src/deb/2.2.1/gri-2.2.1 No match on site ftp.phys.ocean.dal.ca pattern gri-*.tgz -- Scan finished The uscan program is returning so quickly with it's answer that I know it's not attempting to log in correctly, and also the file ftp://ftp.phys.ocean.dal.ca/users/kelley/gri/gri-2.2.3.tgz exists. It also tried watch like: ftp.phys.ocean.dal.ca /users/kelley/gri gri-*.tgz debian uupdate ftp.phys.ocean.dal.ca users/kelley/grigri-*.tgz debian uupdate Am I doing something obviously wrong? Thanks, -- Peter Galbraith, research scientist [EMAIL PROTECTED] Maurice Lamontagne Institute, Department of Fisheries and Oceans Canada P.O. Box 1000, Mont-Joli Qc, G5H 3Z4 Canada. 418-775-0852 FAX: 775-0546 6623'rd GNU/Linux user at the Counter - http://counter.li.org/
Re: warning: lilo 22dev0-1 can make your system unbootable !
Just to verify, I also experienced the same problem. Did you assign a bug against the package yet? Brad Hilton VPOP Technologies [EMAIL PROTECTED] Andreas Jellinghaus wrote: Package: lilo Version: 22dev0-1 it bootet only 2.0.36, but booting 2.2.12 gave a crc error - system halted when unpacking. after replaceing lilo with the old 21-5 version, it works again. andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: uscan and those debian/watch files?
On Tue, Sep 28, 1999 at 11:22:34AM -0400, Peter S Galbraith wrote: ftp.phys.ocean.dal.ca users/kelley/gri/ gri-*.tgz debian uupdate Am I doing something obviously wrong? IIRC you can use this: ftp.phys.ocean.dal.ca /users/kelley/gri gri-(.*)\.tgz debian uupdate See the manpage, too. -- enJoy -*/\*- don't even try to pronounce my first name
Re: mtools
Subject: mtools: please put X related stuff in another package Package: mtools Severity: normal On Tue, Sep 28, 1999 at 10:16:20AM -0500, Brian Servis wrote: How comes mtools depend on xlib6g? I don't use X, and thus I consider it very stupid to have both xlib6g xfree86-common installed, but I have to if I want mtools installed... If something supports X it should be compiled with X. This means exactly two packages (xlib6g and xfree86-common) are also required, but they're reasonably smallish and anything which supports X is going to require them anyway, not just mtools. Better to fork off another package, which would include X support, and leave the original package X-free. What about the [x]emacs packages. I would hate to see forks of all those things on the mirrors. Maybe a Suggests or Recommends would be better than a Depends. Correction: mtools in slink does *not* depend on anything but libc6, so there is still time to do it, cleanly. Maintainer, please do it. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Debian 2.1r3
Chris Rutter wrote: The current `sub-release' (whatever) of Debian 2.1 is r3, right? I was just wondering, as all references on the web site are to r2, but I thought I received a message from the security team about r3 last week somtime. Just wanted to check before I filed a boring bug report, or something. /pedant Debian GNU/Linux 2.1r3 is the current official release that should be present on all ftp mirrors of Debian. There are CD images as well. Last I checked an announcement to debian-announce was missing, though. It was released by the Security Team, FTP Maintainers and Stable Release Officer. Thus if there are problems with references on the web pages, please talk to [EMAIL PROTECTED] Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists.
Re: Shortening release cycles
Steve Greenland wrote: I liked a lot of these ideas, but: On 12-Sep-99, 20:22 (CDT), Martin Schulze [EMAIL PROTECTED] wrote: Our current situation results in our stable release being hopelessly out-dated and the unstable release not being releaseable. That's quite bad for a lot of our fellow users and developers. and then wrote: No major changes are allowed to go into the distribution after two months after the last release. (e.g. release on december 1st, major changes are only allowed to happen until february 1st). If you release every six months, this leads to up to 10 months before a new release of a package makes it into stable. Suppose Xfree86 4.0 is released on feb 10th. That's too late for the june 1 release (which froze on feb 1) so it won't be released until dec 1. People will complain. It would be up to the release manager to get convinced about exceptions. I'm willing to appreciate them. However, what you miss is that we are worst than that, slink was frozen in Nov '98 or so, that's about *at least* 12 months before the next release (assuming that potato will be released in December this year). (Not me, as I'm not one of those who believes anything more than a month old is hopelessly outdated.) Granted. Though, we still need testing which takes time, we also need to give other packages time to keep up (e.g. a major perl update requires to recompile some 50 packages or so, X is too fuzzy for me to make assumptions). Regards, Joey -- The only stupid question is the unasked one. Please always Cc to me when replying to me on the lists.
Re: warning: lilo 22dev0-1 can make your system unbootable !
On Tue, 28 Sep 1999, Brad Hilton wrote:
Just to verify, I also experienced the same problem. Did you assign a
bug
against the package yet?
short summary:
lilo v22 works only with 2.0 kernels; it won't boot a 2.2.x or a 2.3.y.
a v21 version has been reuploaded to master this morning.
Andreas Jellinghaus wrote:
Package: lilo
Version: 22dev0-1
it bootet only 2.0.36, but booting 2.2.12 gave a crc error - system halted
when unpacking. after replaceing lilo with the old 21-5 version, it works
again.
--
- Vincent RENARDIAS [EMAIL PROTECTED],pipo}.com,{debian,openhardware}.org} -
- Debian/GNU Linux: http://www.openhardware.orgExecutive Linux: -
- http://www.fr.debian.org Open Hardware: http://www.exelinux.com -
---
J'adore la France :
c'est un pays superbe et surtout il n'y a pas d'Anglais. [Mick Jagger]
GNOME package versions
I took a few minutes to check what versions of gnome packages were in potato and in /incoming to compare against the current gnome ftp site. The first column shows the version in debian and the filename is the version on the ftp site. *** means it does not appear to be packaged yet. -Chris PS - Thanks to all who are updating the packages :) *** 541066 Aug 2 17:32 Gtk---1.0.2.tar.gz 0.4.95 981072 Sep 27 15:46 ORBit-0.4.96.tar.gz 1.0.5 1136447 Sep 20 22:41 control-center-1.0.40.tar.gz 0.3.9 385472 Aug 30 19:44 ee-0.3.10.tar.gz 0.2.10 244873 Sep 16 16:56 esound-0.2.14.tar.gz 0.4.1 1166853 Sep 24 16:56 glade-0.5.3.tar.gz 1.0.2 3543133 Sep 24 11:21 gnome-games-1.0.40.tar.gz 1.0.40 3196381 Sep 27 15:19 gnome-libs-1.0.42.tar.gz *** 313788 Sep 20 17:58 gnome-objc-1.0.40.tar.gz 0.5 638350 Sep 21 16:12 gtk-engines-0.7.tar.gz 1.0.2 370197 Sep 24 01:27 gtop-1.0.4.tar.gz *** 101650 Aug 25 16:52 java-gnome-0.3.tar.gz 0.4 310798 Sep 19 23:10 libglade-0.6.tar.gz 1.0.1 712283 Sep 24 01:26 libgtop-1.0.4.tar.gz 1.4.0 729312 Sep 26 06:40 libxml-1.7.2.tar.gz pgpUvsef5u8ug.pgp Description: PGP signature
Re: mtools
On Tue, Sep 28, 1999 at 06:08:48PM +0200, Josip Rodin wrote: Correction: mtools in slink does *not* depend on anything but libc6, so there is still time to do it, cleanly. Maintainer, please do it. The bug tracking system has a weird X-Debian-CC system set up so you don't create several bugs through people replying to messages like this, and messages like this get added to the bug. First, I believe this is against policy. Do not create two versions (one with X support and one without) of your package. Second, shouldn't this be wishlist anyway? It's not like it's an error in the program, it's just something you don't like. David Starner - [EMAIL PROTECTED]
Re: Packages should not Conflict on the basis of duplicate funct
On 27-Sep-99 Clint Adams wrote: a) I would not test a new daemon on a working machine, I would use a separate So? b) if you know what you are doing, compile the packages by hand, fix their install scripts, and remove the conflicts. You are trying to circumvent the norm. If I wanted to compile them by hand, why would I even bother with the Debian packaging system? Debian is operating on making the easy case easy. 90+% of our users want to just install a package and go. Perhaps we would have more users if we didn't maintain such a mentality. 90+% of our users probably don't run production servers. Is there some reason you don't want to cater to 100% of our users if possible? Because as everyone knows the last 10% takes 90% of the work and often ends up hurting the other 90%. The point is Debian needs to work for as many people as possible. We are doing near this currently. One of our strong advantages is that after install, you have a working system. Compared to most other dists, we are far ahead here. To then say but some people dont want that and hurt every one is bunk. I used to work at an isp, there is a debian-isp mailing list, and debian's largest use is in the server market. We are currently pleasing most people I talk to in this regard. The point is that supporting what you want runs contrary to how Debian currently works and how most people expect it to. Is it so hard to type: apt-get source qpopper cd qpopper-version $EDITOR debian/control s/Conflicts: pop-server// s/Replaces: pop-server// s/Provides: pop-server// save, quit fakeroot debian/rules binary cd .. dpkg -i qpopper-version.deb That is about all you need do. To be fancy, you could fix the postinst and what not to not have the two stomp on each other. The point is if you are claiming to know enough to test devel code, experiment with server configs and the like, but are not willing or know enough to compile a few apps, then maybe you are in the wrong line of work. And by first point still stands, what you want runs against what most people would call a production server. I would never run an untested daemon on a box w/ clients. God knows what will happen. Now I do agree with your initial statement, not all things should conflict. wmcdplay and xmcd both play cd's -- they dont conflict. However a deamon provides a known service that only one should be performing at ALL times.
Re: mtools
severity 46184 wishlist thanks On Tue, Sep 28, 1999 at 12:28:08PM -0500, David Starner wrote: Correction: mtools in slink does *not* depend on anything but libc6, so there is still time to do it, cleanly. Maintainer, please do it. The bug tracking system has a weird X-Debian-CC system set up so you don't That was changed to X-Debbugs-CC: , IIRC. create several bugs through people replying to messages like this, and messages like this get added to the bug. There was no such bug filed, AFAIK, so I didn't do anything wrong (except forgetting to set Reply-To: which would exclude [EMAIL PROTECTED]). First, I believe this is against policy. Do not create two versions (one with X support and one without) of your package. This does not mean you can't split off the *different* binaries in two packages. Anyway, what is there X related in mtools? If this request does indeed conflict with the Policy, I'll close it, of course. Anyway, why is this in the policy (section 5.8), can someone enlighten me? We split off various versions of our packages, like all those programs that have GTK+, GNOME, KDE, OpenGL, SSL, ALSA, insert-whatever support... seems perfectly legal to do the same for X packages. Second, shouldn't this be wishlist anyway? It's not like it's an error in the program, it's just something you don't like. Yeah. -- enJoy -*/\*- don't even try to pronounce my first name
Re: Censoring :) (was: Re: anarchism_7.7-1.deb)
On Tue, 28 Sep 1999, Marcus Brinkmann wrote: Exactly. A better designed package manager would support modular package format handling. then we could simply do (let's call the package manager hpm for now): hpm -i blacksteel.etheme instead dpkg -i etheme-blacksteel.deb hpm -i realvideo.tar.gz instead alien; dpkg hpm -i somestuff.rpm instead alien; dpkg hpm -i CPAN:mymodule hpm -i CTAN:mytexstyle hpm -i gutenberg:faust and so on. If you make such a tool and people start to use it on a large scale, you'd better be sure you get the package dependencies right. RPM files have file dependencies, not package dependencies like DEB files have. TAR files have no dependencies at all. How are you going to find out which packages a TAR file depends on (and which versions of those packages)? And how would you handle conflicts between packages that should be there but aren't? It is already a problem to install RedHat RPMs on a SuSE system and vice versa. Please don't encourage people to install RPMs on a Debian system if they don't know exactly what they are doing. Their systems *will* break. And they will blame Debian for it. The idea to install E themes, CPAN modules, CTAN modules etc. this way seems nice to me, though. Just make sure all files within the themes / modules are in the right place. And add the right dependencies. For example, E14 themes should have something like Depends: enlightenment (= 0.14), enlightenment ( 0.15). Of course, you'd have to detect the version automatically. Not to say it's a bad idea, just that it will be a helluva lot of work to make it work the right way. Remco -- rd1936: 7:35pm up 6 days, 23:24, 6 users, load average: 1.26, 1.44, 1.77
Re: Packages should not Conflict on the basis of duplicate funct
Because as everyone knows the last 10% takes 90% of the work and often ends up hurting the other 90%. Then it's being done wrong. The point is Debian needs to work for as many people as possible. We are doing Yes, that's exactly the point. apt-get source qpopper [...] dpkg -i qpopper-version.deb That is about all you need do. To be fancy, you could fix the postinst and what not to not have the two stomp on each other. What's so hard about wget ftp://ftp.qualcomm.com/eudora/servers/unix/popper/qpopper2.53.tar.Z tar zxvf qpopper2.53.tar.Z cd qpopper-2.53 ./configure --options make su make install The point is if you are claiming to know enough to test devel code, experiment with server configs and the like, but are not willing or know enough to compile a few apps, then maybe you are in the wrong line of work. That's ridiculous. What you're implying is that Debian is for people that don't know how to compile their own software. It's not. If anything, mucking about with debian/control is more work than getting the pristine source and installing into /usr/local. Why even bother with packages then? Why do we waste valuable disk space on master by compiling for other architectures when they can quite easily do apt-get -b source? I mean, the majority of Debian users have to be i386ers. Why waste all that work providing a binary distribution for m68k? Most Debian users are never going to have any use for a m68k .deb. And Debian SPARC? Please. Why should we waste our time when Solaris works just fine? And Alpha? Those people are always sending in patches complaining about 64-bit compilation problems. It just complicates things for everybody. There can't be that many people using Alpha. Obviously they can patch their own sources and not bother us with fixing the upstream. Why should we? I'll tell you why. Because if it won't compile on that arch, it's BROKEN. Just like having POP servers conflict is BROKEN. And by first point still stands, what you want runs against what most people would call a production server. I would never run an untested daemon on a box w/ clients. God knows what will happen. I could show you entire engineering departments that insist on confusing development and production. Running a test daemon on an alternate port is hardly as ridiculous as changing live code. I would never run KDE on a production server, but bet there are quite a few people who would. (Yes, I said server.) Guess what, Debian lets them. Now I do agree with your initial statement, not all things should conflict. wmcdplay and xmcd both play cd's -- they dont conflict. However a deamon provides a known service that only one should be performing at ALL times. That is a very narrow viewpoint. I am looking right now at a machine with 4 inetd.confs (one for each IP). This is FreeBSD, so they can do that. They aren't running anything on the auth ports (and there are 4 auth ports--1 primary IP, 2 aliases, and 1 localhost). They could quite easily run 4 different identds out of the four different inetds, with no conflict except the one in your mind. Now, of course, Debian's inetd doesn't support binding to specific IP, but hopefully that will be fixed in future.
Re: Swap setup on Debian
On Tue, 28 Sep 1999, Staffan Hamala wrote: I've noticed when installing Debian that the installer always shrinks my swap partition to 128MB, so I have to do a swapoff;mkswap -v1 ..;swapon manually afterwards. Also, the message that it has done this is easily As an aside to this, I use two 64MB swap partitions in my system so it will interleave the data between the two hd's. As far as I could tell, the installer can only setup one swap partition. The option to setup more than one swap partition and also possibly set their priority (to the same thing, in my case) at install time would be useful for me. Laters, Rick ([EMAIL PROTECTED]) http://rick.chillin.org As long as you want to live, everywhere will become heaven. Isn't that right? Because you are still alive. The chance to achieve happiness, you can find it anywhere. Yui Ikari Neon Genesis Evangelion, The End Of Evangelion
Re: Packages should not Conflict on the basis of duplicate funct
Ok, let's bring this back to implementation. How would you propose we handle this? Currently daemons install, set themselves up, and begin running. a) we can prompt. b) we leave everything off and let the admin turn it on (not an option for obvious reasons) c) first come first serve -- first daemon installed does its job, the rest install unconfigured any others?
Re: Packages should not Conflict on the basis of duplicate funct
Ok, let's bring this back to implementation. How would you propose we handle this? Currently daemons install, set themselves up, and begin running. a) we can prompt. b) we leave everything off and let the admin turn it on (not an option for obvious reasons) c) first come first serve -- first daemon installed does its job, the rest install unconfigured any others? d) have something that keeps track of installed services, perhaps with priorities akin to alternatives. If there weren't an issue of services being run either in inetd or standalone, this could be accomplished with a souped-up update-inetd.
Re: warning: lilo 22dev0-1 can make your system unbootable !
On Tue, Sep 28, 1999 at 05:01:34PM +, Vincent Renardias wrote: short summary: lilo v22 works only with 2.0 kernels; it won't boot a 2.2.x or a 2.3.y. But this will not stay this way, will it? Thomas -- GnuPG: ID=B0FA4F49, PGP2: ID=2EA7BBBD http://www.debian.org/debian/doc/debian-keyring.tar.gz pgppxfE2Jm3kz.pgp Description: PGP signature
Re: GNOME package versions
Chris Cheney [EMAIL PROTECTED] writes: *** means it does not appear to be packaged yet. Well, no, it just means you're not aware of Debian's naming schemes for library packages. *** 541066 Aug 2 17:32 Gtk---1.0.2.tar.gz look for *gtkmm *** 313788 Sep 20 17:58 gnome-objc-1.0.40.tar.gz libgnobjc or something to that effect. *** 101650 Aug 25 16:52 java-gnome-0.3.tar.gz Probably not packaged, but I'm uncertain. Mike.
Re: GNOME package versions
Chris Cheney [EMAIL PROTECTED] writes: Well, no, it just means you're not aware of Debian's naming schemes for library packages. *** 541066 Aug 2 17:32 Gtk---1.0.2.tar.gz look for *gtkmm Ok I see it now. :) *** 313788 Sep 20 17:58 gnome-objc-1.0.40.tar.gz libgnobjc or something to that effect. I still don't see this package anywhere, I am either overlooking it or it is not packaged? Thanks, Chris pgpBage1zJ2Jp.pgp Description: PGP signature
Re: GNOME package versions
Chris Cheney [EMAIL PROTECTED] writes: libgnobjc or something to that effect. I still don't see this package anywhere, I am either overlooking it or it is not packaged? I'm sure it's packaged. Don't remember the exact name (don't use objective-c much :-). Mike.
RE: data section! [was: Re: Censoring :) (was: Re: anarchism_7.7
On 27-Sep-99 Josip Rodin wrote: We are already doing that - the proposal on the policy list regarding a new, data section of the FTP server has passed. Hopefully, it will be implemented in practice soon. Yes, but I think that it doesn't solve the problem. I think there are some data not necessary for the distribution. There are data for packages and simple data. This two things should be divided, IMHO. bye --- Christian Surchi| Debian GNU/Linux User [EMAIL PROTECTED] | http://www.debian.org www.firenze.linux.it/~csurchi | Linux, the choice of a GNU generation Some of my readers ask me what a Serial Port is. The answer is: I don't know. Is it some kind of wine you have with breakfast?
Re^2: strange behavior of dh_dhelp
Am 27.09.99 schrieb GalbraithP # dfo-mpo.gc.ca ... Moin Peter! PSG I have a recent potato install and dhelp 0.3.14 and _don't_ have PSG http://localhost/fhs/ support. I don#t have it, too :). Is this directory a Debian standard, Roland? PSG I could see http://localhost/doc/HTML/, but all new docs visible PSG as file:/usr/share/doc/HTML/index.html could not be seen under PSG the http://localhost interface to dhelp. Is `fhs' supposed to be PSG a new Alias? localhost/doc/ should point to /usr/share/doc. Please submit a bug report for your http daemon. PSG Am I doing anything wrong? Nothing, but the maintainers of the packages. PSG [I also agree that it would be annoying to have two distint PSG directories to point a browser at (if it worked at all for me).] PSG Marco, do you have upgrade plans for dhelp? Off course I will support the latest policy. But it#s not possible to support *one* index for /usr/doc *and* /usr/share/doc. This is security feature of all http daemons. cu, Marco -- Linux HOWTOs - Die besten Loesungen der Linuxgemeinde ISBN 3-8266-0498-9 Uni: [EMAIL PROTECTED] Fido: 2:240/6298.5 Mailbox: [EMAIL PROTECTED]http://www.tu-harburg.de/~semb2204/
Re: mtools
On Tue, 28 Sep 1999, Brian Servis wrote: *- On 28 Sep, Josip Rodin wrote about Re: mtools On Tue, Sep 28, 1999 at 07:13:58AM -0700, Joseph Carter wrote: How comes mtools depend on xlib6g? I don't use X, and thus I consider it very stupid to have both xlib6g xfree86-common installed, but I have to if I want mtools installed... If something supports X it should be compiled with X. This means exactly two packages (xlib6g and xfree86-common) are also required, but they're reasonably smallish and anything which supports X is going to require them anyway, not just mtools. Better to fork off another package, which would include X support, and leave the original package X-free. What about the [x]emacs packages. I would hate to see forks of all those things on the mirrors. Maybe a Suggests or Recommends would be better than a Depends. Guys, guys, guys... This is a discussion that was had quite a while ago, and which lead to the creation of xlib6. The whole point was that it was unnecessary glut to include a console version _and_ an X aware version of packages like emacs (and others), when a small library could provide all that was necessary to make a single program both console and X compatible. xfree86-common is simply a recent way to remove the architectural independent pieces from xlib6 and provide them in an independent fashion. You cannot simply reduce the dependency to a lower level, like Recommends, or Suggests, as the program, linked against xlib6 will have unsatisfied references, if the library is not installed. While it may seem a bit insensitive to force these two packages on everyone. It seems a better situation than requiring you to load two complete versions of emacs just to get console _and_ X aware editors. The fact that this impacts every application that would be useful in an X environment, makes insisting that everyone install xlib6 a very good thing. Luck, 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 _-_-_-_-_-_- See www.linuxpress.com for more details _-_-_-_-_-_-_-
Re: Re^2: strange behavior of dh_dhelp
[EMAIL PROTECTED] (Marco Budde) writes: PSG I could see http://localhost/doc/HTML/, but all new docs visible PSG as file:/usr/share/doc/HTML/index.html could not be seen under PSG the http://localhost interface to dhelp. Is `fhs' supposed to be PSG a new Alias? localhost/doc/ should point to /usr/share/doc. Please submit a bug report for your http daemon. It should point to /usr/doc/ as a result of the technical committee decision. - Ruud de Rooij. -- ruud de rooij | [EMAIL PROTECTED] | http://ruud.org
Re: Re^2: strange behavior of dh_dhelp
Marco Budde wrote: PSG I have a recent potato install and dhelp 0.3.14 and _don't_ have PSG http://localhost/fhs/ support. I don#t have it, too :). Is this directory a Debian standard, Roland? It isn't. PSG I could see http://localhost/doc/HTML/, but all new docs visible PSG as file:/usr/share/doc/HTML/index.html could not be seen under PSG the http://localhost interface to dhelp. Is `fhs' supposed to be PSG a new Alias? localhost/doc/ should point to /usr/share/doc. Please submit a bug report for your http daemon. That would be apache. PSG [I also agree that it would be annoying to have two distint PSG directories to point a browser at (if it worked at all for me).] PSG Marco, do you have upgrade plans for dhelp? Off course I will support the latest policy. But it#s not possible to support *one* index for /usr/doc *and* /usr/share/doc. This is security feature of all http daemons. Yeah, I guess most of this issue will have to be resolved by httpd maintainers. The problem is many people will keep their old conf files and the system will be broken wrt dhelp and dwww. Peter
Re: GNOME package versions
Scavenging the mail folder uncovered Chris Cheney's letter:
0.4.1 1166853 Sep 24 16:56 glade-0.5.3.tar.gz
I have a package ready (I use glade heavily and I didn't wanted to
wait.) If the author doesn't have the time to update it, I can NMU.
Ciao,
Federico
--
Federico Di Gregorio [http://www.bolinando.com/fog] {Friend of Penguins}
Debian GNU/Linux Developer Italian Press Contact[EMAIL PROTECTED]
Best friends are often failed lovers. -- Me
Re: GNOME package versions
Michael Alan Dorman [EMAIL PROTECTED] writes: Chris Cheney [EMAIL PROTECTED] writes: libgnobjc or something to that effect. I still don't see this package anywhere, I am either overlooking it or it is not packaged? I'm sure it's packaged. Don't remember the exact name (don't use objective-c much :-). Package: libobgnome0 Version: 1.0.2-2 Priority: optional Section: libs Maintainer: Chris Waters [EMAIL PROTECTED] Depends: libobgtk1 (= 1.0.2-2), gdk-imlib1, libart2 (= 1.0.10-3), libaudiofile0 Architecture: i386 Filename: dists/unstable/main/binary-i386/libs/libobgnome0_1.0.2-2.deb Size: 26848 MD5sum: 7d4b427023c6504bd5afd649eb7d93ab Description: Objective-C - Gnome bindings Bye.
Re: GNOME package versions
On Tue, Sep 28, 1999 at 12:17:22PM -0500, Chris Cheney wrote: Content-Description: Message Body I took a few minutes to check what versions of gnome packages were in potato and in /incoming to compare against the current gnome ftp site. The first column shows the version in debian and the filename is the version on the ftp site. *** means it does not appear to be packaged yet. *** 541066 Aug 2 17:32 Gtk---1.0.2.tar.gz Look for libgtkmm* binaries and gtkmm source package. 0.4.1 1166853 Sep 24 16:56 glade-0.5.3.tar.gz I only need to download: 1.0.40 3196381 Sep 27 15:19 gnome-libs-1.0.42.tar.gz and recompile. Will be done in no time. Don't worry. But only if it is installed in the archive by now (last time I checked it was stuck in incoming). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/
Re: Re^2: strange behavior of dh_dhelp
Ruud de Rooij wrote: [EMAIL PROTECTED] (Marco Budde) writes: PSG I could see http://localhost/doc/HTML/, but all new docs visible PSG as file:/usr/share/doc/HTML/index.html could not be seen under PSG the http://localhost interface to dhelp. Is `fhs' supposed to be PSG a new Alias? localhost/doc/ should point to /usr/share/doc. Please submit a bug report for your http daemon. It should point to /usr/doc/ as a result of the technical committee decision. - Ruud de Rooij. Then we'll have to agree where we register docs. I have the following directories on a fresh potato system (with few packages): /usr/share/doc/HTML/ /usr/doc/HTML/ And they are _not_ symlinks. They get created by different paths set in .menu files: # cd /usr/lib/menu # grep usr/share/doc * doc-base-doc-base: command=/usr/share/doc/doc-base/doc-base.html/index.html doc-base-install-docs-man: command=/usr/share/doc/doc-base/install-docs.html doc-base-tdlug: command=/usr/share/doc/tdlug/html/debusered2.html.gz # grep usr/doc/ * README:For more info, please read /usr/doc/menu/html lynx: command=/usr/doc/lynx/lynx_help/lynx_help_main.html man-db: command=/usr/doc/man-db/man-db-manual.html menu: command=/usr/doc/menu/html/index.html Peter
Re: GNOME package versions
Marcus Brinkmann [EMAIL PROTECTED] writes: 1.0.40 3196381 Sep 27 15:19 gnome-libs-1.0.42.tar.gz and recompile. Will be done in no time. Don't worry. But only if it is installed in the archive by now (last time I checked it was stuck in incoming). I just uploaded 1.0.42. I believe 1.0.40 has gotten in the archive, though. 1.0.42 will probably get in tomorrow. Mike.
Re: Re^2: strange behavior of dh_dhelp
* Marco == Marco Budde [EMAIL PROTECTED] wrote: Marco, please show a little common sense. You are beating a dead horse. Marco localhost/doc/ should point to /usr/share/doc. Please submit a Marco bug report for your http daemon. The decision was made by the ctte, it is not yet implemented in the policy document, but it will be soon. There is no requirement for Potato, that all packages support the latest policy. policy 2.4.x is still allowed. And these have the docs in /usr/doc. With the decision on the /usr/doc - /usr/share/doc transition, every packages docs are accessable through /usr/doc/package. So the only sensible point is to read /usr/doc. What do you demand for the short time, until the revised policy is released? All packages using the symlink have to remove him? Lintian must not report a missing symlink? Debhelper has to cease installing this link? My god, Marco, show some reason. Ciao, Martin
pine in other distributions?
I'm a little suprised. I found pine package in redhat-contrib which has a few additional patches. The most interesting is pine4.10-qtcolor-0.1.patch. pine.README.colours: --- To turn on the pretty colours patch set the PINECOL environment variable to true. 08/02/99 Simon Liddington [EMAIL PROTECTED] --- BTW, other pine's version is a part of official RedHat distribution, but I don't know is it legal? Will the pine return back to distribution? Well, this is the mostly used mailer by my users (and me). -- Piotr Dexter Roszatycki mailto:[EMAIL PROTECTED]
Re: pine in other distributions?
Quoting Piotr Roszatycki: BTW, other pine's version is a part of official RedHat distribution, but I don't know is it legal? Will the pine return back to distribution? Well, this is the mostly used mailer by my users (and me). From http://linuxmafia.com/debian/tips (and based on some suggestions by yours truly): pine/pico: Debian does not by default install non-free packages -- those under restrictive software licences (although many are provided and available for installation). If you are a user of the pine e-mail client or the pico text editor that pine provides, please be aware that pine is non-free and therefore is not a default installation item. The U. of Washington's licence forbids distribution of pine/pico in binary form. This restriction is routinely violated by many GNU/Linux distributions, but not by Debian. (U. of Washington is aware of this licencing problem, but elects not to fix it.) You can thus install pine and pico (in Debian) by installing the pine source-code package and then compiling the programs. However, there's a better alternative. Just put the following script in /usr/local/bin as pine, and chmod it to 755 (executable): #!/bin/sh /usr/bin/mutt -F /usr/doc/mutt/examples/Pine.rc pico can be emulated by a symbolic link to the simple editor ae, which is really very close to pico: cd /usr/local/bin ln -s ../../../bin/ae pico -- ((lambda (x) (list x (list (quote quote) x))) (quote (lambda (x) (list x (list (quote quote) x) -- A LISP quine written by Seth David Schoen +++ath
Re: Packages should not Conflict on the basis of duplicate functionality
On Mon, Sep 27, 1999 at 03:21:34AM -0400, Raul Miller wrote: On Mon, Sep 27, 1999 at 01:05:58PM +1000, Craig Sanders wrote: then don't install those services. installing a package *IS* an explicit OK. You're saying that packages reliably say when they provide daemons? no, but it should be pretty obvious from the description. e.g. a pop server package is going to install a pop server. a web server package is going to install a web server. etc. this should be self-evident. craig -- craig sanders
Re: pine in other distributions?
You may have noticed that the other distributions also have KDE included in them. Because of the license flaw, Debian does not allow KDE in main. Redhat and others include it because there is little chance of legal action against them for this inclusion. The same applies here, Redhat seems to include as many good packages as it can, but will also ignore any potential legal issues if the risk of a lawsuit is low. From a business standpoint, this is good behavior, but doesn't speak very highly of the morals of those who select what goes into their distributions. Dave Bristel On Tue, 28 Sep 1999, Piotr Roszatycki wrote: Date: Tue, 28 Sep 1999 22:48:08 +0200 (CEST) From: Piotr Roszatycki [EMAIL PROTECTED] To: Debian Development Mailing List debian-devel@lists.debian.org Subject: pine in other distributions? Resent-Date: 28 Sep 1999 20:48:12 - Resent-From: debian-devel@lists.debian.org Resent-cc: recipient list not shown: ; I'm a little suprised. I found pine package in redhat-contrib which has a few additional patches. The most interesting is pine4.10-qtcolor-0.1.patch. pine.README.colours: --- To turn on the pretty colours patch set the PINECOL environment variable to true. 08/02/99 Simon Liddington [EMAIL PROTECTED] --- BTW, other pine's version is a part of official RedHat distribution, but I don't know is it legal? Will the pine return back to distribution? Well, this is the mostly used mailer by my users (and me). -- Piotr Dexter Roszatycki mailto:[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mtools
On Tue, 28 Sep 1999, Dale Scheetz wrote: [snip] Guys, guys, guys... This is a discussion that was had quite a while ago, and which lead to the creation of xlib6. The whole point was that it was unnecessary glut to include a console version _and_ an X aware version of packages like emacs (and others), when a small library could provide all that was necessary to make a single program both console and X compatible. xfree86-common is simply a recent way to remove the architectural independent pieces from xlib6 and provide them in an independent fashion. This is ok with me for stuff like emacs (eventhough I'd really become aggressive if someone removed the vim-tty package.), but when it comes to mtools, it's only one single file; a daemon (floppyd, if I'm not all wrong) that needs xlib6g. It'd be simple to extract this daemon from mtools and create an extra package with just this file, and make this file recommended by mtools, and make mtools required by the extra-package. /David Weinehall _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire /
Re: Packages should not Conflict on the basis of duplicate funct
On Tue, 28 Sep 1999, Clint Adams wrote: Ok, let's bring this back to implementation. How would you propose we handle this? Currently daemons install, set themselves up, and begin running. a) we can prompt. b) we leave everything off and let the admin turn it on (not an option for obvious reasons) c) first come first serve -- first daemon installed does its job, the rest install unconfigured any others? d) have something that keeps track of installed services, perhaps with priorities akin to alternatives. If there weren't an issue of services being run either in inetd or standalone, this could be accomplished with a souped-up update-inetd. a) is possible, but I don't really like it. It may be not too bad if 'prompt' means 'ask debconf'. d) is perhaps the right thing, but sounds like a lot of work and changes to dozens of packages. Until this is done, c) could be a possible solution. It would also allow to inhibit automatic start of services at all by providing packages noop-httpd, noop-fingerd, ... (in extra and with appropriate warning in the description) to be installed as 'first ones' by the knowing sysadmin. The main problem I see with c) is how to determine if we are the first one regarding the standalone/inetd mess without introducing parts of d). c) should the be designed so that it makes later transition to d) easy (in fact c) could be just one of the policies implemented by d)). But then decisions on flexibility (how highly-customized and possibly problematic setups are to be supported: multiple interfaces - some secure and some not, multiple IPs - virtual hosting etc., ...) have to be made early or daemon package maintainers will become badly-behaved daemons themselves. Some basic ideas for c) - d) : /var/state/servicemgr/daemons: #the supergeneric version, perhaps drop/ignore some fields #package service interface ip port protocol inetd|standalone mtime apache www * * 80 tcp standalone 28 Sep 1999 \ 18:30:16 - interface and ip would have to be * by default or things will badly suck on machines without permanent network connection. interface can be determined by IP most of the time, but not for dial-up connections. fetchmail tries to care for the right (secure) interface if asked to but is no real example for the kind of daemon addressed here because it doesn't listen ports but polls. Are there any? A package providing a daemon would then have to supply a canonically-named script or executable, e.g. package.dmconf with canonical options/arguments (including service, because one excutable may provide several at once) to de/configure and register all that stuff with the help of some scripts supplied by 'servicemgr'. package.dmconf should be allowed to fail (gracefully) if the setup is more complex than it can handle (which could include, for a start, interface != *, ip != *, moving services into/out of inetd.conf, using non-standard ports or setting up coexistence with another package already providing the same service so we're back to c)). The nicest thing would be to make what I called package.dmconf a new kind of maintainer script or include it in one of the existing. To make things even more complex, the default configuration for the first or only daemon providing a service should be taken from debconf if one has been chosen there. This could require that parts of the per-package configuration are in a cononical format, too if settings of the kind 'whatever httpd I use, I want it on port 81!' should be supported. Does this mean a) - d) is the better way of migration? Bjorn Brill [EMAIL PROTECTED] Frankfurt am Main, Germany
Re: pine in other distributions?
On Tue, 28 Sep 1999, Nick Moffitt wrote: Quoting Piotr Roszatycki: BTW, other pine's version is a part of official RedHat distribution, but I don't know is it legal? Will the pine return back to distribution? Well, this is the mostly used mailer by my users (and me). From http://linuxmafia.com/debian/tips (and based on some suggestions by yours truly): pine/pico: Debian does not by default install non-free packages -- those under restrictive software licences (although many are provided and available for installation). If you are a user of the pine e-mail client or the pico text editor that pine provides, please be aware that pine is non-free and therefore is not a default installation item. The U. of Washington's licence forbids distribution of pine/pico in binary form. This restriction is routinely violated by many GNU/Linux distributions, but not by Debian. (U. of Washington is aware of this licencing problem, but elects not to fix it.) You can thus install pine and pico (in Debian) by installing the pine source-code package and then compiling the programs. This is incorrect. I quote: Pine and Pico are registered trademarks of the University of Washington. No commercial use of these trademarks may be made without prior written permission of the University of Washington. Pine, Pico, and Pilot software and its included text are Copyright 1989-1999 by the University of Washington. Use of Pine/Pico/Pilot: You may compile and execute these programs for any purpose, including commercial, without paying anything to the University of Washington, provided that the legal notices are maintained intact and honored. Local modification of this release is permitted as follows, or by mutual agreement: In order to reduce confusion and facilitate debugging, we request that locally modified versions be denoted by appending the letter L to the current version number, and that the local changes be enumerated in the integral release notes and associated documentation. Redistribution of this release is permitted as follows, or by mutual agreement: (a) In free-of-charge or at-cost distributions by non-profit concerns; (b) In free-of-charge distributions by for-profit concerns; (c) Inclusion in a CD-ROM collection of free-of-charge, shareware, or non-proprietary software for which a fee may be charged for the packaged distribution. Redistribution of binary versions is further constrained by license agreements for incorporated libraries from third parties, e.g. LDAP, GSSAPI. The University of Washington encourages unrestricted distribution of individual patches to the Pine system. By patches we mean difference files that can be applied to the University of Washington Pine source distribution in order to accomplish bug fixes, minor enhancements, or adaptation to new operating systems. Submission of these patches to University of Washington for possible inclusion in future Pine versions is also encouraged. [legal blurp with disclaimers concerning functionality stripped] End of Quote Thus we are free to distribute even a patched Pine, as long as we apply an L at the end of the version#. Not too big a sacrifice, huh? We'll still have to keep it in the non-free area, of course, as it's a BSD-style license, but... I'd love to see Pine 4.10 (in a Debian-modified state that has the pretty colours patch + a fix for the VERY annoying bug that removes backslashes from signatures) /David Weinehall _ _ // David Weinehall [EMAIL PROTECTED] / Northern lights wander \\ // Project MCA Linux hacker// Dance across the winter sky // \ http://www.acc.umu.se/~tao// Full colour fire /
Re: pine in other distributions?
David == David Weinehall [EMAIL PROTECTED] writes: David On Tue, 28 Sep 1999, Nick Moffitt wrote: David Redistribution of binary versions is further constrained by David license agreements for incorporated libraries from third David parties, e.g. LDAP, GSSAPI. Hm, what happened to this text: Although the above trademark and copyright restrictions do not convey the right to redistribute derivative works, the University of Washington encourages unrestricted distribution of patch files which can be applied to the University of Washington Pine distribution. Did something change? Have they seen the Light? netgod _Anarchy_ Argh.. who's handing out the paper bags 8)
Re: mtools
On Tue, 28 Sep 1999, David Weinehall wrote: On Tue, 28 Sep 1999, Dale Scheetz wrote: [snip] Guys, guys, guys... This is a discussion that was had quite a while ago, and which lead to the creation of xlib6. The whole point was that it was unnecessary glut to include a console version _and_ an X aware version of packages like emacs (and others), when a small library could provide all that was necessary to make a single program both console and X compatible. xfree86-common is simply a recent way to remove the architectural independent pieces from xlib6 and provide them in an independent fashion. This is ok with me for stuff like emacs (eventhough I'd really become aggressive if someone removed the vim-tty package.), but when it comes to mtools, it's only one single file; a daemon (floppyd, if I'm not all wrong) that needs xlib6g. It'd be simple to extract this daemon from mtools and create an extra package with just this file, and make this file recommended by mtools, and make mtools required by the extra-package. I agree it seems unnatural that something as fundamental as mtools depends on xlib6g, be it small or not. *But* in this case, it seems hard to avoid. As I understand it, the *whole* mtools package makes 'parasitic' use of the X protocol (in fact of an existing X connection) to give authenticated access to remote floppy drives. Floppyd is the server, and most or all of the other commands can act as clients. So the whole package has to be compiled with or without X. Bjorn Brill [EMAIL PROTECTED] Frankfurt am Main, Germany
Re: Packages should not Conflict on the basis of duplicate funct
On Tue, Sep 28, 1999 at 11:13:53AM -0700, Sean 'Shaleh' Perry wrote: Ok, let's bring this back to implementation. How would you propose we handle this? Currently daemons install, set themselves up, and begin running. a) we can prompt. b) we leave everything off and let the admin turn it on (not an option for obvious reasons) c) first come first serve -- first daemon installed does its job, the rest install unconfigured How about this: The install program will scan the list of installed programs, and for each package that Provides: service, it will offer a choice of which to configure by default. Perhaps it could look like this: You have selected 4 programs that Provide: pop-server. [0] configure none [1] configure qpopper [2] configure pop3d [3] configure magicpop [4] configure sillypopd [a] configure all Enter the numbers of which to configure now: Before complaining about 'Debian asks too many questions' -- my view is, if not answering the questions holds up the package copying and such, as it does now, yes debian does ask too many questions. If some set of sensible questions were asked first, and all the rest delayed until the end of package copying, then no, debian does not ask too many questions. :) As for actually implementing this thing, I am hoping debconf is this good. I will give it a shot when it stabilizes a bit (eg, fewer updates per week.. :) Comments/suggestions/flames welcome. -- Seth Arnold | http://www.willamette.edu/~sarnold/ Hate spam? See http://maps.vix.com/rbl/ for help Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Re: pine in other distributions?
On Tue, 28 Sep 1999, David Weinehall wrote: Thus we are free to distribute even a patched Pine, No! Anyone is allowed to _locally_ modify Pine, but there's no statement about distributing such modified versions. And Redistribution of this release is permitted as follows [...] of course only covers this release as provided from U. of Washington. We'll still have to keep it in the non-free area, of course, as it's a BSD-style license, but... When did the BSD license change to non-free? From the Debian Policy section 2.1.1.: Example Licenses The ``GPL,'' ``BSD,'' and ``Artistic'' licenses are examples of licenses that we consider _free_. Thomas -- GnuPG: ID=B0FA4F49, PGP2: ID=2EA7BBBD http://www.debian.org/debian/doc/debian-keyring.tar.gz
