Re: Debian target audience
> > The problem of having both libc5 and libc6 run-time libraries is minor,
> > the main one is that those stuck with libc5-dev cannot use other
> > newly-available versions of *libraries* from hamm.
>
> How do you mean? You can install the *libraries* just fine, it's just
> the development versions that fail to install.
That's exactly what I meant, sorry if it wasn't clear.
>
> And even then, why not install lib5-altdev? Then there is no problem
> whatsoever.
>
I am sorry to say, but you are wrong. Even on this list there were
several postings regarding this matter. There are several known
problems and who knows how many unknown. You just can't afford to
experiment with "production" system this way. Anyway, I could take some
burden on myself to compile libc5 counterparts, but on my 486DX2/66 with
2k/sec connection it would take years.
Alex Y.
> --
> joost witteveen, [EMAIL PROTECTED]
> #!/usr/bin/perl -sp0777i $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> #what's this? see http://www.dcs.ex.ac.uk/~aba/rsa/
--
_
_( )_
( (o___
| _ 7 '''
\(") (O O)
/ \ \ +---oOO--(_)+
|\ __/ <-- | Alexander Yukhimets [EMAIL PROTECTED] |
|| | http://pages.nyu.edu/~aqy6633/ |
( / +-oOO---+
\ / |__|__|
) /(_ || ||
| (___)ooO Ooo
\___)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Upcoming Debian Releases
The following message is a list of items to be completed for the upcoming
releases of Debian GNU/Linux. If something is missing, incorrect, or you want
to take responsibility for one or more items, please send email to:
Brian White <[EMAIL PROTECTED]>
This document was last modified at Time-stamp: <97/06/16 22:08:39 bcwhite>
If you're replying about some of the ideas mentioned in this document, it is
often wise to change the subject to reflect that idea. This helps target
those people who are most likely to partake in discussions about it.
For each upcoming release, the name of the task and the person who has claimed
responsibility for it (or "???" if nobody) is listed. An asterisk (*) in front
means the job has yet to be completed and must be done before that release can
be made "stable". A dash (-) in front means it has not yet been completed,
but if not completed in time will just be pushed to the next release. A
space means that the task has been completed.
Footnotes are indicated by "[n]" and give more information on that item.
If you know of packages that do not conform to any of these tasks, please
report it as a bug against those packages. If that task is marked as critical
(i.e. with an asterisk "*"), then please let me know and I will mark the bug
as critical.
Critical bugs are those that you would seriously consider delaying the
upcoming release or removing that package from the distribution because
they are not fixed.
Upcoming Dates
~~
June 30, 1997 Bug reports against all non-libc6 packages.
July 1, 1997Bugs older than 9 months will be marked as overdue.
July 15, 1997 All uploaded libraries must depend on libc6.
July 31, 1997 All uploaded packages must depend on libc6.
August 1, 1997 Bugs older than 8 months will be marked as overdue.
August 31, 1997 All packages depending on libc4 or libc5 will be removed.
September 1,'97 Bugs older than 7 months will be marked as overdue.
Thoughts
---
Hamm (Debian 2.0)
~
* All packages are in the new package format.
* All packages in main distribution are compiled with libc6.
* Fix packages currently depending on 'libc5-dev'.
* Officially supports {i386,m68k,alpha,sparc} architectures (mips,ppc?).
* No more dependencies on obsolete virtual packages (X11R6, elf-x11r6libs, ...).
* No a.out executables anymore.
* Remove "--force-overwrite" flag from dpkg defaults
* Much improved dpkg/dselect.
* Use PAM within authentication programs [13]
* Link shared libs against other shared libs instead of static [14]
* Official Debian logo chosen.
- Fix remaining "overdue" bugs ([EMAIL PROTECTED])
- Appropriate pkgs should call "install-mime" in postinst ([EMAIL PROTECTED])
- Convert remaining a.out packages (???)
- configuring so non-ASCII characters work (???) [9]
- Make all web servers apply to /usr/doc/debmake/webstandard-3.0
- Make all startup messages apply to the new standard
- Use ttyS* devices instead of cua* devices (???) [10]
- Packages to call "update-menu" in postinst ([EMAIL PROTECTED]) [11]
- Move config information from install scripts to "cfgtool" (???)
- Some sort of package-grouping mechanism for dselect
- New run-level layout (???) [12]
- No bug reports older than 9 months at release time
---
Footnotes
~
9 - One of the things that most people outside the US and UK have to deal
with is configuring everything so that non-ASCII characters and other
locale specific stuff works right. For example, bash needs a ~/.inputrc
so that you write åäö on the command line, instead of getting
beeps. Emacs needs some other stuff. -- Lars Wirzenius <[EMAIL PROTECTED]>
10 - /dev/ttySxx devices are fully POSIX-compliant TTY devices. If you are
only going to be using one set of tty devices, you should be using
/dev/ttySxx.
/dev/cuaXX devices are different from /dev/ttySXX in two ways --- first
of all, they will allow you to open the device even if CLOCAL is not set
and the O_NONBLOCK flag was not given to the open device. This allows
programs that don't use the POSIX-mondated interface for opening
/dev/ttySxx devices to be able to use /dev/cuaXX to make outgoing phone
calls on their modem (cu stands for "callout", and is taken from SunOS).
The second way in which /dev/cuaXX differs from /dev/ttySXX is that if
they are used, they will trigger a simplistic kernel-based locking
scheme: If /dev/ttySXX is opened by one or more processes, then an
attempt to open /dev/cuaXX will return EAGAIN. If /dev/cuaXX is opened
by one or more processes, then an attempt to open /dev/ttySXX will result
the open blocking until /dev/cuaXX is closed, and the carrier detect line
goes high.
While this will allow for simple lockouts between a user using a
hamm and dftp
Is there a dftp.conf setup I can use that doesn't require me to do some sed work on the packages file? The paths are wrong for the mirrors in the one that's on the servers now. -douglas -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Orphaning dftp.
I'd like to officially offer dftp up for adoption. I don't use it anymore -- dselect works much better for me now that I came to terms with it -- and so I don't really have much interest in maintaining dftp anymore (that and the fact that I have a bunch of other things I'm supposed to be doing). Thanks -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
On 16 Jun 1997, Kai Henningsen wrote: > I meant the possibility for a customer to request the ISP exim to reject > any mail that comes from, say, savetrees.com. You know, what AOL does, > except I want individual customers to be able to configure individual > lists. I don't think that is possible with exim. There are no facilities for individual users to modify which messages are rejected at the SMTP conversation level. They can of course set up exim filters in their .forward files to junk anything they don't want, but that of course isn't rejecting the mail, technically. Tim. -- -- T J R Cutts Tel: +44 1223 333596 Dept. of Biochemistry, Tennis Court Rd., Fax: +44 1223 766002 Cambridge, CB2 1QW, UK -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
Santiago Vila Doncel <[EMAIL PROTECTED]> writes: [snip] > The simplest solution is to ship html in a different package. This way > the user will be able to choose to not install the html docs if he/she > believes info2www is enough. It might be nice if different types of duplicate documentation could be identified in the package and only selected types installed, or generated. For example, I could set up a system so that all the documentation installed was HTML: installed directly if present, or genrated using texi2html, info2www, man2html etc. if not, either on the fly with dwww or at installation time. Any unnecessary man pages or info documentation could be dropped. I don't really expect to see this soon though. > IMHO we should not drop .info from the main package, [...] I have to agree with this. I quite like Emacs' info reader, and tkinfo. -- Carey Evans <*> [EMAIL PROTECTED] "Our mail program accidentally deleted our remove list." - Real quote from UCE -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
On Mon, 16 Jun 1997, Erik B. Andersen wrote: > I cannot agree more. We should definatly add these fields to the > .deb package format! This will involve a bit of work, but will be > VERY worth it. No more licensing surprises, for instance. I second that! This would even make my proposed README.debian obsolete which would have had the problem, that each maintainer would use his own formatting in that file, so there is no easy way to automatically scan the README.debian for the upstream URL, for example. This is simple though, if the info is included in the control information. AFAIK, all dpkg related tools are designed to ignore all additional control fields. Thus, dpkg does _not_ have to be changed for this. We'd simply have to agree on certain fields and mention these in the policy manual. [snip] > > Author: name and email of main upstream author (copyright holder) Good. > > License: code describing license type This field is good for a "pre-selection" of packages. Thus, if we have a "License: GPL" package, no additional information is needed usually, but if you have a "License: cripleware" package, one has to check the "copyright" file for additional information. So, perhaps we should add a note here, that this field is for a short information about the license and one should check the copyright file for details. > > Original-Site: site/URL at which the package is originally stored Ok. I think "Original-Site" is used in the .lsm entries. Wouldn't something like "Upstream-Site" be better? [snip] > > The "Original-Site" field could be optional, since it is not that necesary > > to > > know it in normal cases. Of course, it should always be mentioned in > > the "README.debian" file, as you propose. This field is important if the package is handed from one maintainer to another. The second usually does not know where to get the upstream sources! And of course, the users probably would like to know the URL of the "official home page" of that program. Any comments? Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- "DIE ENTE BLEIBT DRAUSSEN!" -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
On Mon, 16 Jun 1997, Santiago Vila Doncel wrote: > On Sun, 15 Jun 1997, Christian Schwarz wrote: > > > TOPIC 7: new definition of ``free software'' > > This is only about the "main" section. > > In addition to that, I wonder why we are supporting this packages in the > `contrib' section: > > * whose copyright permission notices (or patent problems) allow only >distribution of compiled binaries (and thus of which only binaries >are available) > * allow free use only for a trial period (shareware) > * are demonstration programs lacking vital functionality >(crippleware) > > Are there many of them? In "bo" we had 33 of contrib packages. The reason for this is that due to the lack of source we are not able to fix any bugs in that package or to adopt the package to our needs (cf. discussion of file locking). If the package is only useable for a trial period, we can't put it into the main distribution since we would not allow a package to depend on such a package. And we seperate these packages from non-free since that section should be as small as possible to simplify the work necessary for CD vendors. I think the splitting into "main", "non-free", "contrib" (and "non-us") is quite reasonable and need not be changed in the near future. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Debian is looking [EMAIL PROTECTED], [EMAIL PROTECTED] for a logo! Have a look at our drafts PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA athttp://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Orphaning dftp.
> I'd like to officially offer dftp up for adoption. I don't use it > anymore -- dselect works much better for me now that I came to terms > with it -- and so I don't really have much interest in maintaining > dftp anymore (that and the fact that I have a bunch of other things > I'm supposed to be doing). I'd volunteer for maintaining dftp, at least for a while, if nobody else does. I also have a lot of things to do and not too much time left, but I need dftp for my two machines at home, and there are some things in dftp that really should be done (re-add the .installed file, at least some kind of dependency checking). Roman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
-BEGIN PGP SIGNED MESSAGE- Sorry, I didn't explain well. I said: *--- I wonder why we are supporting this packages in the `contrib' section: * whose copyright permission notices (or patent problems) allow only distribution of compiled binaries (and thus of which only binaries are available) * allow free use only for a trial period (shareware) * are demonstration programs lacking vital functionality (crippleware) Are there many of them? *-- I just meant: Why do we support these packages? (in *whatever* section). > In "bo" we had 33 of contrib packages. The reason for this is that due to > the lack of source we are not able to fix any bugs in that package or to > adopt the package to our needs (cf. discussion of file locking). Why do we want to have such packages in our FTP mirrors? Do we really want to distribute crippleware? I was talking about making contrib smaller, so that, by policy, some of the packages that are now allowed could not be distributed in *any* section at all. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBM6ZUbSqK7IlOjMLFAQHujAQAtOGMqhoC4hMcoMwn1xgthYukHMPLAOcy 1Udl8RjObgrngWoU8ZLzmVpe5KAxzyR8maXw5C38UXSrFKF+ywNo71L8z6DJnKVx k+lBYE+XVQqwSrP6KzasRhhy40k9M3J2BeoXjMVkUUGbRCdtBAeBiCdPwwMyRX3o ph5ieLMdIE8= =uTrw -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: inetd question
Yes, I use a proxy and both proxy and www-client run on the same machine. But it appears the ident calls came from my firewall where I run a http-gw. You're absolutely right that I should get rid of that traffic. There is no need for the firewall to ask identd on a local machine. But it should ask identd for connections from outside. Can I configure tcpd so that it only ask outside machines? Currently I have ALL:@@ALL in my /etc/hosts.allow file. Would it suffice to add a line http-gw: [EMAIL PROTECTED] Our local network is 172.26.0.0. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 >-Original Message- >From: Peter Tobias [SMTP:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 1997 2:37 AM >To:Kai Henningsen >Cc:Die Adresse des Empfängers ist unbekannt. >Subject: Re: inetd question > > >As far as I know Michael uses a proxy in the same lan (maybe the client >also runs on this machine). When you get some pages from the local >proxy and the proxy does an ident lookup for each connection you'll get >lots of ident lookups (getting pages from the proxy is quite fast so >you'll get lots of lookups in a very short time). > >> > Using "nowait.120" is of course a solution but it is probably better >> > to find the application that is causing the problem. >> >> It is not clear that there is a problem, other than heavy use. There may >> be, of course, such as ident queries actually causing more ident queries, >> but we don't know yet if something like that happens. > >Getting more than 40 ident lookups a minute is not a usual situation. The >best solution is to find the reason (the sender!) of the ident requests >(if it is a local service/system the ident lookups for that service/system >should probably be turned off). Setting the limit to 120 will keep the >system running but won't reduce the (maybe unnecessary) traffic. If the >number of requests can't be reduced the identd should be run in standalone >mode. > > >Thanks, > >Peter > >-- >Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> ><[EMAIL PROTECTED]> >PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02 04 62 89 6C 2F DD F1 >3C > > >-- >TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to >[EMAIL PROTECTED] . >Trouble? e-mail to [EMAIL PROTECTED] . > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: inetd question
On Jun 15, Kai Henningsen wrote: > > > I guess it's the ident service. So I try nowait.120 and see what > > > happens. > > > > Of course it is the ident service (that's what the error message of > > inetd said). But the ident service is not a service that is used > > alone. You have an application/service which is called as often > > as the ident service. You should have a look at this application. > > Your problem could also be an entry in hosts.allow or hosts.deny. > > If you use a username ([EMAIL PROTECTED]) there the tcp_wrapper will do an > > ident/auth lookup for that service (or for all services if the ALL > > keyword has been used). > > You are somewhat confused here. I don't think so :-). > The identd service is called from the _other_ end of the connection (to > find out who sits on your end). > > If you actually do have a econd service called just as often, then either > the ident connections are local (both ends on your machine), or else the > second service is some sort of forwarder (like a web proxy), so every time > it is called, it calls out to somewhere else, and that somewhere else then > does an ident query. As far as I know Michael uses a proxy in the same lan (maybe the client also runs on this machine). When you get some pages from the local proxy and the proxy does an ident lookup for each connection you'll get lots of ident lookups (getting pages from the proxy is quite fast so you'll get lots of lookups in a very short time). > > Using "nowait.120" is of course a solution but it is probably better > > to find the application that is causing the problem. > > It is not clear that there is a problem, other than heavy use. There may > be, of course, such as ident queries actually causing more ident queries, > but we don't know yet if something like that happens. Getting more than 40 ident lookups a minute is not a usual situation. The best solution is to find the reason (the sender!) of the ident requests (if it is a local service/system the ident lookups for that service/system should probably be turned off). Setting the limit to 120 will keep the system running but won't reduce the (maybe unnecessary) traffic. If the number of requests can't be reduced the identd should be run in standalone mode. Thanks, Peter -- Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02 04 62 89 6C 2F DD F1 3C -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: (bogus mailing list message)
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > I hope he has good arguments for it, since I would not like to have two > concurring menu systems in Debian: menu and dwww. I think it shouldn't be > too hard to change the menu package to dwww's needs, if this should be > necessary. It already does; in the past dwww had it's own menu system _as well_ using ..dwww-lib files in the /usr/doc directories. This is definitely a bad thing as it leads to documents being split into two menus, one generated by the menu package and one from dwww itself.
Re: When will bash 2.01 be packaged?
In article <[EMAIL PROTECTED]>, Christian Schwarz <[EMAIL PROTECTED]> writes: > Guy Maor is the current maintainer of the "bash" package. However, he told > us that he is offline for about 4 weeks. So I think someone else should > grab it and upload a non-maintainer (interim) release. Is that necessary just to work round a (long standing) bug in another program?
Re: locale errors
[EMAIL PROTECTED] (Kai Henningsen) writes: > [EMAIL PROTECTED] (Mark Baker) wrote on 15.06.97 in <[EMAIL PROTECTED]>: > > I got that (with perl only) before I installed debian; it doesn't like > > locale settings that other programs seem to get on with OK. Try removing the > > LANG variable and it ought to work. Is whatever sets LANG (your .bashrc?) > > something you copied off another system? > > Removing LANG is, of course, not an option, except maybe for people from > English-speaking countries. But setting LANG to _correct_ value (e.g. en or en_US) might help. -- Tomislav Vujec [EMAIL PROTECTED] --- To understand recursion, one must first understand recursion... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
On Jun 17, Santiago Vila Doncel wrote > Sorry, I didn't explain well. I said: > > *--- > I wonder why we are supporting this packages in the `contrib' section: > > * whose copyright permission notices (or patent problems) allow only >distribution of compiled binaries (and thus of which only binaries >are available) > * allow free use only for a trial period (shareware) > * are demonstration programs lacking vital functionality >(crippleware) > > Are there many of them? > *-- > > Why do we want to have such packages in our FTP mirrors? > Do we really want to distribute crippleware? > > I was talking about making contrib smaller, so that, by policy, some of > the packages that are now allowed could not be distributed in *any* > section at all. In general we should distribute the programs because people want them. Two programs that spring to mind are Netscape and possibly XFree86 beta releases (which I believe won't be produced anymore). ATM I still think that Netscape is the best browser and will have some features that other browsers (eg Mnenomic) won't have for a long time. I don't want to have to but up with a bad program just because someone else disagrees with the copyright statement. It is up to _me_ to choose whether I want non-free packages on my system - not Debian. Xfree86 betas were only available as binaries and were time-limited. However some of them supported important cards (e.g. Matrox or Diamond IIRC) or had important bug-fixes. As long as the user is warned of the expiry date in the description, I think these should be distributed. Maybe we should have a vote on what should be in the various sections. I for one found the choices a bit limited last time. Adrian -- email: [EMAIL PROTECTED] | Artificial intelligence - the http://www.poboxes.com/adrian.bridgett | art of making computers act PGP key available on public key servers | like those in the movies -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: locale errors
No! You cannot use libc5 compiled perl with glibc locales! Wait for a libc6 version of perl and everything should be fine again. Michael -- Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 >-Original Message- >From: Tomislav Vujec [SMTP:[EMAIL PROTECTED] >Sent: Tuesday, June 17, 1997 1:01 PM >To:debian-devel@lists.debian.org >Cc:Die Adresse des Empfängers ist unbekannt. >Subject: Re: locale errors > >[EMAIL PROTECTED] (Kai Henningsen) writes: > >> [EMAIL PROTECTED] (Mark Baker) wrote on 15.06.97 in >><[EMAIL PROTECTED]>: >> > I got that (with perl only) before I installed debian; it doesn't like >> > locale settings that other programs seem to get on with OK. Try removing >>the >> > LANG variable and it ought to work. Is whatever sets LANG (your .bashrc?) >> > something you copied off another system? >> >> Removing LANG is, of course, not an option, except maybe for people from >> English-speaking countries. > >But setting LANG to _correct_ value (e.g. en or en_US) might help. > >-- >Tomislav Vujec [EMAIL PROTECTED] >--- >To understand recursion, one must first understand recursion... > > >-- >TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to >[EMAIL PROTECTED] . >Trouble? e-mail to [EMAIL PROTECTED] . > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Upcoming Debian Releases
-BEGIN PGP SIGNED MESSAGE- On Mon, 16 Jun 1997, Brian C. White wrote: > August 31, 1997 All packages depending on libc4 or libc5 will be removed. This is too much strong. I would suggest to make their associated bug (the one saying "it's still libc5") "almost-critical" instead. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBM6Z2hSqK7IlOjMLFAQGX5wP/XScvtXHhm6e55xsNp+eIoxGDKO9EONA2 iJBxJ/2RWhD1tjsdoaYLCbC8VcCtiRDj3HPQF/Xsx4VHGDRv1J/948IBPtMUIsKm 4CBFcUjAytjAaR++ItHyhZmE/SgvsNzcFTT24qWbYeMZ63fDcS/CR9f2nsjgbh3Q rT4NBlmr1PQ= =PUDF -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: When will bash 2.01 be packaged?
[EMAIL PROTECTED] (Mark Baker) writes: > > Guy Maor is the current maintainer of the "bash" package. However, > > he told us that he is offline for about 4 weeks. So I think > > someone else should grab it and upload a non-maintainer (interim) > > release. > > Is that necessary just to work round a (long standing) bug in > another program? I don't care in the least about netrape, but one good reason for doing a non-maintainer release of bash would be to build it against glibc. I'm sure I'm not the only one who needs a libc6-based libreadline for some of my packages. Also, I'd imagine there were other bugs fixed in 2.01. -- James -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: locale errors
In article <[EMAIL PROTECTED]>, Tomislav Vujec <[EMAIL PROTECTED]> writes: > But setting LANG to _correct_ value (e.g. en or en_US) might help. perl was giving me errors when I had it set to en_GB (before I installed debian).
Re: Status of Debian Policy
[EMAIL PROTECTED] (Fernando) wrote: >Author: name and email of main upstream author (copyright holder) >License: code describing license type >Original-Site: site/URL at which the package is originally stored Yes. >We could even go further and specify the type of non-free license. >Common types are: >[...] >Shyware: free use and redistribution of binaries, sources not available > because author considers them still alpha. > >I don't think there are many more types. The precise terms should be available >in the "copyright" file, but since most packages would fall in one of >the previous categories, it would be really useful to have that shown >in a concise way before installing a package. There are also programs that fit this 'shyware' definition, but where the author doesn't consider the source code to be 'unfit' -- they just want to keep source to themselves. This usually seems to be for 'artistic' reasons... (justified or not...) I've come across this sort of license quite a lot recently, while trying to package up some of the adventure games from ftp.gmd.de -- the author doesn't give out source because he doesn't want you to be able to 'cheat' easily. For these games, porting is not an issue, because they are run using an interpreter, and the interpreter source is available. Bugs are handled by the upstream author, and in any case are not usually serious, by which I mean they don't usually affect anything other than the game player's enjoyment. If they crash the machine, it's the interpreter's fault, not the game's. I'm not saying that anyone -should- keep their source secret (quite the opposite), but it does happen. --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
Santiago Vila Doncel <[EMAIL PROTECTED]> wrote: >I think libraries should not need priorities (or they need them much less >than ordinary program packages). So if they have more or less priority, I >really don't mind. Go ahead. I have a suggestion for libraries: most users don't want or need to know about shared libraries when installing and upgrading their system, or when adding an app etc. There should be a flag, similar to "Essential: yes" -- perhaps "Internal: yes", which would be noticed by dselect. The user could then ask dselect to 'hide' all internal packages. This would mean that they wouldn't clutter up the dselect packages list, they would be selected -quietly- when a depending package is selected (not forcing a trip to the dependencies screen), and they might even be automatically marked for removal whenever no more packages depend on them. Of course, there must be a way to switch off this behaviour and make all packages visible, just as it's possible to override dependencies. If you think about it, there's really no reason to select a shared library package by hand; if you want a binary that uses it, it'll depend on it; if you want to build against it, you install the -dev package (which depends on it). The only time you really want to select it by hand is when another package had faulty dependencies, or when you're installing a non .deb'ed binary. What do you think? --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
How do we do modules?
G'day All, Now that I've taked over ax25 utilites from Bruce, I'm slowly working on the makefiles etc so that we will have a huge leap forward in versions to the latest and greatest. But there is a small associated problem. There is a lot of amateur radio device drivers in the kernel. Now having all these drivers in one kernel is a Bad Thing as there is at least three of them that will conflict that I know of. So the solution I guess is modules. So, how do we do this? What's the best way of having a set of modules or should they be included with the standard set of modules we already have. - Craig -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
tin copyright problems?
/usr/doc/tin/copyright says that tin is distributed under the GPL but lots of *.c files have one of the following copyright statements: * Copyright : (c) Copyright 1991-94 by Iain Lea * You may freely copy or redistribute this software, * so long as there is no profit made from its use, sale * trade or reproduction. You may not change this copy- * right notice, and it must be included in any copy made or * Copyright : (c) Copyright 1991-94 by Stan Barber & Iain Lea * Permission is hereby granted to copy, reproduce, redistribute * or otherwise use this software as long as: there is no * monetary profit gained specifically from the use or * reproduction or this software, it is not sold, rented, * traded or otherwise marketed, and this copyright notice * is included prominently in any copy made. Thanks, Peter -- Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02 04 62 89 6C 2F DD F1 3C -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Status of Debian Policy
On Jun 17, Christian Schwarz wrote: > > > Original-Site: site/URL at which the package is originally stored > > Ok. I think "Original-Site" is used in the .lsm entries. Wouldn't > something like "Upstream-Site" be better? It is important that more than one "Upstream-Site" field is allowed. Not for alternate sites but for packages which have more than one upstream site (for example netstd). Thanks, Peter -- Peter Tobias <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> PGP ID EFAA400D, fingerprint = 06 89 EB 2E 01 7C B4 02 04 62 89 6C 2F DD F1 3C -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Orphaning dftp.
Roman Hodek <[EMAIL PROTECTED]> writes: > I'd volunteer for maintaining dftp, at least for a while, if nobody > else does. I also have a lot of things to do and not too much time > left, but I need dftp for my two machines at home Right. Just in case you hadn't thought of it you could use dselect's ftp method and an (NFS) shared or mirrored download directory for the two machines. That of course presumes that you have a net connection at home and that you don't have expensive line charges. > and there are some things in dftp that really should be done (re-add > the .installed file, at least some kind of dependency checking). True. I just don't have time for it right now. I put in the interactive mode as a hack until I or someone else did the dependency ordering code. Looks like you might be able to use pkg-order now. I guess we can wait a bit and see if anyone else wants dftp. If not, it's yours. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Obsolete package CGI-modules (hamm)
Hi, >>"Scott" == Scott K Ellis <[EMAIL PROTECTED]> writes: Scott> Umm, actually perl5 only includes CGI.pm, and CGI::Apache, Scott> Carp, Fast, Push, and Switch. The libs from CGI-modules are Scott> NOT included. So we do still need a cgi-modules package, Scott> although perhaps in a renamed and cleaned up state Scott> (perl-cgi-modules), here's your chance to fix the Scott> capitilization :) Oh, I see that now. I'll in that case continue to provide cgi modules, though I'll wait until there is a naming policy in effect for CPAN modules (lib-perl-cgi-modules?) I may also then see if we need a lib-perl-cgi-pm package (depends on how frequently CGI.pm is updated relative to Perl itself) manoj -- Where love is there is no labor; and if there be labor, that labor is loved. Austin Manoj Srivastava mailto:[EMAIL PROTECTED]> Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
'Tim Cutts wrote:' >On 14 Jun 1997, John Goerzen wrote: >> Christoph Lameter <[EMAIL PROTECTED]> writes: >> > It might be good if we would replace smail in hamm with exim. Exim should >> > be the standard mailer for hamm: >> >> Exim doesn't provide UUCP capabilities *at all*, thus it is rather >> useless for sites that use UUCP (like me). Right now, I am using >> sendmail. (What, BTW, is the reason for not using sendmail?) > >Well, for one thing exim (and smail) are a hell of a lot easier to >configure than sendmail. That was what originally moved me towards exim >at work - I really didn't want to muck about fixing numerous broken >sendmail setups when in far less time I could just switch all the machines Could someone explain why people have so much trouble with sendmail setups? I've used sendmail commercially for several years now and the only misconfigurations I've ever seen are with the Cw directive (something which would need to be specified to any MTA). Virtual domain mail is tricky, but there are several web pages with instructions on configuring this and it is not difficult if you can follow instructions (even easier with 8.5). Virtual domains are the only reason to mess with rule sets and I freely admit to not having a clue about rule sets. Still I've never had problems with sendmail because all the rule sets one needs are included in sample sendmail.cf files. Copy, paste, tweak -- it works! /usr/sbin/sendmailconfig made my life even easier (though as I said I never had trouble with sendmail even though I never studied its config file). OK, I admit to reading through the well commented sendmail.cf and following the instructions in the comments for several parameters, but this is not too difficult. If I might speculate on my "winning" sendmail configuration strategy: ignore the irrelevant (like rule sets). The answer to all sendmail problems is with the easily configured parts in /etc/mail. grepping through /usr/doc/sendmail also helps. Hence I would appreciate it if the MTA debate could focus on design criteria other than ease of configuration. I'm more interested in performance and design considerations that impact on security and the ability to configure (flexibility). Chris "Just flabbergasted that anyone finds sendmail troublesome" Fearnley -- Christopher J. Fearnley | Linux/Internet Consulting [EMAIL PROTECTED] | Design Science Revolutionary http://www.netaxs.com/~cjf | Explorer in Universe ftp://ftp.netaxs.com/people/cjf | "Dare to be Naive" -- Bucky Fuller -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: How do we do modules?
I think you should build a 2.1.x boot disk using the boot-floppies scripts, since ax.25 is so much nicer in 2.1 it makes no sense to base new work on 2.0 . When you build the kernel, you get to decide what is a module and what is not in the configuration menu. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: tin copyright problems?
Ugh. Can someone write to them? Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
GNU stow
Hi, I hope no-one minds that I've gone ahead and dome this without asking first... I've packaged GNU stow 1.3.2. This may not sound useful, it being another package management system, but I find it pretty useful to manage my /usr/local directory, so there it is. It's at ftp://pcsw104b.ukc.ac.uk/pub/cpb4/>, and I will upload it as and when. Incidentally, there's a package there called 'curses', and I just realised it might get confused with the UNIX curses (which it has nothing to do with). I will rename it. Finally, I'm looking at GSPreview (similar to ghostview) and UPS (the graphical debugger) with a view to packaging them. Anyone else working on these already? --Charles Briscoe-Smith White pages entry, with PGP key: http://alethea.ukc.ac.uk/wp?95cpb4> PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
Charles Briscoe-Smith <[EMAIL PROTECTED]> wrote: > I have a suggestion for libraries: most users don't want or need to > know about shared libraries when installing and upgrading their system, > or when adding an app etc. I totally agree here. The Debian package format includes enough information to make manual selection of shared libraries unnecessary in most cases. The selections could be automatic depending on the choice of "user level" packages. > There should be a flag, similar to "Essential: yes" -- perhaps > "Internal: yes", which would be noticed by dselect. The user could > then ask dselect to 'hide' all internal packages. This would mean that > they wouldn't clutter up the dselect packages list, they would be > selected -quietly- when a depending package is selected (not forcing a > trip to the dependencies screen), and they might even be automatically > marked for removal whenever no more packages depend on them. Sounds good. Moreover, hiding "internal" packages should be the default behaviour, while displaying them should be reserved for experts. > Of course, there must be a way to switch off this behaviour and make > all packages visible, just as it's possible to override dependencies. > > If you think about it, there's really no reason to select a shared > library package by hand; if you want a binary that uses it, it'll > depend on it; if you want to build against it, you install the -dev > package (which depends on it). The only time you really want to select > it by hand is when another package had faulty dependencies, or when > you're installing a non .deb'ed binary. Agree again. Shared libraries (and even other support packages like, for example, those containing run time programs needed by libraries) could be selected in a totally automatic fashion. Even more, I don't think it's necessary that the user takes care of dependency problems directly. We should allow users to make a basically arbitrary selection of packages without signaling any conflict problems, and let dpkg automatically determine which packages are needed for the selections to run, and install them properly. All the information needed to do that is currently available, all we have to do is using it. Have the Deity guys considered something along these lines? M. S. Martin A. Soto J. Profesor Departamento de Ingenieria de Sistemas y Computacion Universidad de los Andes [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
create Packages.gz file from directory
Hello! I want to create a Packages.gz file for local files, i.e. on a CD-ROM or ZIP floppy. Using dpkg --record-avail -R /usr/src/deb it's possible to get the information "manually", but how can I write it to a file?? (dpkg version was 1.4.0.8) Thanks Christian -- Christian Leutloff, Aachen, Germany eMail: [EMAIL PROTECTED] http://www.oche.de/~leutloff/ Debian/GNU Linux! Mehr unter http://www.debian.org/ pgp7wptqBuQEb.pgp Description: PGP signature
Re: create Packages.gz file from directory
Christian Leutloff writes: > I want to create a Packages.gz file for local files, i.e. on a CD-ROM > or ZIP floppy. > > Using > > dpkg --record-avail -R /usr/src/deb > > it's possible to get the information "manually", but how can I write > it to a file?? There is dpkg-scanpackages somewhere. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / / If you come from outside of Finland, you live in wrong country / / Featuring Debian GNU/Linux motd von irc.funet.fi / -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Package priorities and dependencies.
Martin Alonso Soto Jacome wrote: > > If you think about it, there's really no reason to select a shared > > library package by hand; if you want a binary that uses it, it'll > > depend on it; if you want to build against it, you install the -dev > > package (which depends on it). The only time you really want to select > > it by hand is when another package had faulty dependencies, or when > > you're installing a non .deb'ed binary. > > Agree again. Shared libraries (and even other support packages like, > for example, those containing run time programs needed by libraries) > could be selected in a totally automatic fashion. Even more, I don't > think it's necessary that the user takes care of dependency problems > directly. We should allow users to make a basically arbitrary > selection of packages without signaling any conflict problems, and > let dpkg automatically determine which packages are needed for the > selections to run, and in > > Have the Deity guys considered something along these lines? We have indeed. In fact what you describe above is pretty much what I have specified for that part of the deity UI. Behan Webster (Deity User Interface designer) -- Behan Webster mailto:[EMAIL PROTECTED] +1-613-224-7547 http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: locale errors
[EMAIL PROTECTED] (Michael Meskes) wrote on 17.06.97 in <[EMAIL PROTECTED]>: > No! You cannot use libc5 compiled perl with glibc locales! Wait for a > libc6 version of perl and everything should be fine again. This is, of course, a problem nearly as serious as that about utmp. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Hamm: Exim + Chos standard?
[EMAIL PROTECTED] (Tim Cutts) wrote on 17.06.97 in <[EMAIL PROTECTED]>: > On 16 Jun 1997, Kai Henningsen wrote: > > > I meant the possibility for a customer to request the ISP exim to reject > > any mail that comes from, say, savetrees.com. You know, what AOL does, > > except I want individual customers to be able to configure individual > > lists. > > I don't think that is possible with exim. There are no facilities for > individual users to modify which messages are rejected at the SMTP > conversation level. They can of course set up exim filters in their > .forward files to junk anything they don't want, but that of course isn't > rejecting the mail, technically. There's no need to actually do that during the SMTP conversation. All that is necessary, from the view of those users, is filtering the stuff _somehow_. Furthermore, it's not quite as easy - remember, I said MX. The mail usually gets forwarded to another host (via UUCP). (Well, there are some POP3 users, as well.) >From reading the docs, I'm optimistic. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: locale errors
[EMAIL PROTECTED] (Tomislav Vujec) wrote on 17.06.97 in <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] (Kai Henningsen) writes: > > > [EMAIL PROTECTED] (Mark Baker) wrote on 15.06.97 in > > > <[EMAIL PROTECTED]>: I got that (with perl only) > > > before I installed debian; it doesn't like locale settings that other > > > programs seem to get on with OK. Try removing the LANG variable and it > > > ought to work. Is whatever sets LANG (your .bashrc?) something you > > > copied off another system? > > > > Removing LANG is, of course, not an option, except maybe for people from > > English-speaking countries. > > But setting LANG to _correct_ value (e.g. en or en_US) might help. Seeing as my LANG _is_ set to the correct value, de_DE (after all, it worked before installing libc6), no, it won't. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: hamm and dftp
[EMAIL PROTECTED] (Douglas L Stewart) wrote on 16.06.97 in <[EMAIL PROTECTED]>: > Is there a dftp.conf setup I can use that doesn't require me to do some > sed work on the packages file? The paths are wrong for the mirrors in the > one that's on the servers now. The paths in the Packages file certainly should not be wrong. What problem do you see? MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Processed: reassignments
Processing commands for [EMAIL PROTECTED]:
> reassign 10089 xbase
Bug#10089: Experiences with 1.3 ("bo")
Bug reassigned from package `project' to `xbase'.
> reassign 5583 boot-floppies
Bug#5583: Shortcomings of install.txt and debian-manual.txt
Bug reassigned from package `manual' to `boot-floppies'.
> reassign 5953 boot-floppies
Bug#5953: The installation manual does not mention alternate boot disks.
Bug reassigned from package `manual' to `boot-floppies'.
> reassign 5954 doc-debian
Bug#5954: The PostScript version of The Debian GNU/Linux FAQ lacks page numbers.
Bug reassigned from package `manual' to `doc-debian'.
> reassign 10433 dpkg
Bug#10433: dselect and broken pipe
Bug reassigned from package `dselect' to `dpkg'.
> reassign 10584 svgalib1
Bug#10584: svgalib uses /dev/console
Bug reassigned from package `svgalib' to `svgalib1'.
> reassign 10601 kernel
Bug#10601: Adaptec 2842 / Debian 1.2/1.3 problem
Bug reassigned from package `kernel-image' to `kernel'.
> reassign 10613 netscape
Bug#10613: Screen does not refresh/reload crashes Netscape
Bug assigned to package `netscape'.
> reassign 10614 netscape
Bug#10614: Screen does not refresh/reload crashes Netscape
Bug assigned to package `netscape'.
> --
Stopping processing here.
Please contact me if you need assistance.
Ian Jackson
(maintainer, Debian bug tracking system)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian-Policy Manual
> > David Frey <[EMAIL PROTECTED]> writes:
> > >>TOPIC 4: editor/pager policy
> > > What is the benefit of /usr/bin/sensible-{editor,pager}?
> > > Why don't we just default to EDITOR=/usr/bin/vi and PAGER=/usr/bin/more
> > > if both variables are unset? (auch, don't beat me)
> >
> > That might enable us to get rid of /usr/bin/{editor,pager} though it's an
> > inferior solution to what we're doing at the moment. It won't enable us to
> > get rid of /usr/bin/sensible-{editor,pager} which are for progams that don't
> > understand EDITOR and PAGER.
>
> Not exactly.
>
> The files /usr/bin/{editor,pager} will be managed through alternatives.
> Since alternatives can be changed by the sysadmin only, we allow the user
> to define EDITOR and PAGER to override this.
>
> That's why we need "sensible-{editor,pager}". These are two simply shell
> scripts that test if EDITOR/PAGER is set and launches either that program,
> or /usr/bin/{editor,pager}.
Im still confused. What do /usr/bin/{editor,pager} do then?
Are they hard links to vi and more? Or equivalently trivial shell scripts
of the form:
#!/bin/sh
/usr/bin/vi
Thanks for your patience,
David
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian-Policy Manual
On Tue, 17 Jun 1997, David Frey wrote:
> > The files /usr/bin/{editor,pager} will be managed through alternatives.
> > Since alternatives can be changed by the sysadmin only, we allow the user
> > to define EDITOR and PAGER to override this.
> >
> > That's why we need "sensible-{editor,pager}". These are two simply shell
> > scripts that test if EDITOR/PAGER is set and launches either that program,
> > or /usr/bin/{editor,pager}.
>
> Im still confused. What do /usr/bin/{editor,pager} do then?
> Are they hard links to vi and more? Or equivalently trivial shell scripts
> of the form:
> #!/bin/sh
> /usr/bin/vi
I believe that the plan is to have them managed by update-alternatives,
and therefore be symlinks. Less will probably have a higher priority than
more, although I don't know who gets to win the war over which editor is
best, although I suspect a vi varient on the grounds that that is what
happens on most unices.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: locale errors
[EMAIL PROTECTED] (Kai Henningsen) writes: > [EMAIL PROTECTED] (Michael Meskes) wrote on 17.06.97 in <[EMAIL PROTECTED]>: > > > No! You cannot use libc5 compiled perl with glibc locales! Wait for a > > libc6 version of perl and everything should be fine again. > > This is, of course, a problem nearly as serious as that about utmp. Not really. This is an issue only with `unstable' (as far as I can tell from the discussion), and `unstable' means exactly that--everything might not work properly. -- Ben Pfaff <[EMAIL PROTECTED]>http://www.msu.edu/user/pfaffben PGP key: http://www.msu.edu/user/pfaffben/pgp.html or a keyserver near you Linux: choice of a GNU generation -- Debian GNU/Linux: the only free Linux -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: GNU stow
In article <[EMAIL PROTECTED]>, Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > It's at ftp://pcsw104b.ukc.ac.uk/pub/cpb4/>, and I will upload it > as and when. Incidentally, there's a package there called 'curses', Assuming that's the game by Graham Nelson, great, I like being able to delete stuff from usr/local :)
Re: locale errors
-BEGIN PGP MESSAGE- Version: 2.6.3 owGFU1FoHFUUTdGiHRDUDz/Mh7dISAK7m92k2W2imybpbm1aW6ONSCUwfTt7Z/eR mfeW995ks/VDBJUWIRaqIOiHP6WC+FcQwUqp2g+L9ENBahXpT0Hqlyjoh+K9M0m7 1VDfwsybfe+ee8+5554cePue7QMTZx8/9sng0T1fXj2TbNvWHb934NQH62/MXfn0 tx9O/HhudXfxwfDb0Y+vvqPe+/Ds2LO/PpqrPX/gr+250+5CcOPSY6/g4NhS/feH qpevv3Xim2tHTvy0cuWJwYvvf3/p5Nd/PhJ+d+7c05/tL7/28O4DZ/wd9Ru1N1// 6uc/vjgfXL95/vQD1/acuvzLrpd3zn2+fvbV6O/1597Nv3Tz6IWP7oPG/TYsliYn SpMDtJ5RUKrAgYReU1OVHMyjgsVQhCF0jXY47XkzsCLk7Eo7toUuWheKCFWhiTBy UEjYj0pJ1bKoRilAOrTTFDADMdoVtLNOd2zPOozTgEMyaAuM4FB6OApZCtBcQqFY LkxVQCp4MqjW6kOi6g91qrfih6JqfeHwkSV65KcqxXKpUioRid0v5seLE7MoFV2S qtCfbyarJH3MwGG9E47qBAKhlHaQWIRINoJJCHTckRE2oYMmgq50bWjxCUQ6IKp2 J7wgpINQGxAbWHxchlU0VlLtOsxChWoC0p891yZFwLZ1EjWhgRBKhSBaguq7XdFS W1qQNsfhgU6MxRwI6BjdiDAGhcJEPRAWLBqpE8tb1xYOREMnVL6LOwzmMTEHBkUU 9QqwiUq10NMmrC3BpKSOJaSRIPRhGCGwUBjGXGBBCMVhFEFodExZEJrSBolldqO5 lFdfcIxCWcA1Ebiox5FUVT7fRzyWrbYDFrmrzQpTYnl6Bc9bYgJUnTMJsW0Qj0iu YJqRCW2yz4F0wzZFaGlGdJo2ILqi56GwMmW6QAZF6Arl+JhU5up42xar9AGZDaDb RoPQ0CRA1m5i42X9o2wtI2LLClALcE1al2NQQ8MgFUHd7keqYCo6a4wwzhhGGIkW YqFkJ4mE22DRlGFISRXJkwOrQYbQI+Mx6pZ1NKTKgNL+OtNjFv8CZUmghY6K1cYk HYdN0vOIjGXERslxEqqcx4CcsJEiMzDZj1ycg/+SHk7HwCP541uC9iOUt0CYvAsC NxhprgQpzs1zRq5KEW2KaJlXKNcyR1FMb5gSWSfpyf0zOqH/pfImINbKtS2TIpzU VOSaplZcX2oXNiE4GSMXDiImWVQom8huIBU9q2Pk610GpwknFTtZEymOrC5bbByr o8TxCIvQoUmBS4UJmqaIbIaeReeIOCXu0uR6dbPqefm8twNg8alFWEwakQzgIPam ecJbBNAVEeHMhvr4cYmFgFXp0iQVsJl4WdC+9GLHkL2mYW4S5uZhfBIqNajMwb4a 7KrBvjrAfB3GS7CrAuUiFPdCbS+UKzBVJ4z/WT4tD/K0qtV8HvwtL43RD5Zvfab3 +Xp+xB/1fQZJcdLNxvWxZVjecSdKHrC5wZf8S40glRkqReIYH5bplcWmKRnH56++ 5CnQBswdemWFVXlRkD/GkX7OzyB8Ahjz03Ubrq8g6xK2gu1X/y5r2d9cVCh4/wA= =juyy -END PGP MESSAGE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: locale errors
Damn, pinepgp is screwing up auto signatures. Sorry. === > On 17 Jun 1997, Ben Pfaff wrote: > > > [EMAIL PROTECTED] (Kai Henningsen) writes: > > > [EMAIL PROTECTED] (Michael Meskes) wrote on 17.06.97 in <[EMAIL > > > PROTECTED]>: > > > > > > > No! You cannot use libc5 compiled perl with glibc locales! Wait for a > > > > libc6 version of perl and everything should be fine again. > > > > > > This is, of course, a problem nearly as serious as that about utmp. > > > > Not really. This is an issue only with `unstable' (as far as I can > > tell from the discussion), and `unstable' means exactly > > that--everything might not work properly. > That is true, but like the utmp problem, it's not going to go away by itself. If we want to be able to have a system where both libc5 and libc6 programs can coexist, we run into a problem with utmp. The 2 libraries manipulate utmp differently, so if you run both libc5 and libc6 binaries that try to manipulate utmp, it gets corrupted. Similarly, if we install libc5 locale files, libc6 programs can't use them. If we install libc6 locale files, libc5 programs can't use them. These are not trivial problems to fix, and they'll still be around in 3 months if nothing is done in the mean time. I am confident that someone will come up with an elligant solution after the 1.3 release settles down. Erv -- PGP Public Key: finger [EMAIL PROTECTED] PGP Fingerprint: A5 AB 25 7D 7A FD 4D FE BE 21 47 60 0C DC 67 9E ==-- _ / / \ ---==---(_)__ __ __/ / /\ \ - [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / / /_/\ \ \- [EMAIL PROTECTED] -=/_/_//_/\_,_/ /_/\_\ /__\ \ \ - [EMAIL PROTECTED] \_\/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
