On Tue, 24 Jun 1997, SirDibos wrote:
> On Tue, 24 Jun 1997, Jon Rabone wrote:
> > >Or if anyone interested, make up a special ROM with kernel etc in it, so
> > >the machine will boot from ROM... Has anyone done this?
>
> > You'd need about 512 kB of ROM. Where are you going to put it? Ethercar
From: Santiago Vila Doncel <[EMAIL PROTECTED]>
> Well, I think that it would be much cleaner for deity to have the ability
> of "grouping" a set of packages to be installed at once instead of
> doing partial installs of larger packages.
Yes, we did discuss that.
> Moreover, we would not lost our
On Mon, Jun 23 1997 23:08 +0200 Martin Schulze writes:
> David Frey writes:
> >
> > On Mon, Jun 23 1997 7:25 BST Marco Budde writes:
> > > Any comments?
> > (Please add next time a translated version too, not everyone
> > reads natively german [I'd had a hard time to understand e
On Mon, Jun 23 1997 22:08 BST James Troup writes:
> David Frey <[EMAIL PROTECTED]> writes:
>
> > > * Das Aendern des Dokuments ist nicht erlaubt. Das gilt sowohl
> > >fuer den Inhalt als auch fuer das Dateiformat bzw. die
> > >Gestaltung. Auch das Entfernen unliebsamer Passagen i
On Tue, Jun 24 1997 15:52 BST James Troup writes:
> John Goerzen <[EMAIL PROTECTED]> writes:
>
> > It seems to me that dc and bc aren't vital to the workings of a
> > system (when I deselect them, dselect doesn't warn about any
> > dependencies), yet they are in Important. Why?
>
> Beca
> Well, you're going to need a script to implement that policy. Probably
> the best way to handle this is to provide a way to tell the package system
> that you have deliberately removed a file, and that this file should not
> be replaced. I wouldn't expect this in version 1.0 .
What exactly is th
-BEGIN PGP SIGNED MESSAGE-
On Tue, 24 Jun 1997, Bruce Perens wrote:
> From: Philip Hands <[EMAIL PROTECTED]>
> > I think we should aim to get all documentation into separate packages.
>
> Please don't do this. Deity will have the capability to exclude installation
> to certain directorie
> For Deity, I suppose we could make pattern-matching work in the policy file.
I think that would be preferable to simple directory exclusion.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Hi,
I've got a copy of qmail-1.01 built with diffs I got from Christian.
The diffs worked out of the box, which is why I've not uploaded anything
(since Christian has obviously already done the work, and I didn't want to
tread on his toes).
I've since applied some of the anti-spam patches (whi
Mark Eichin wrote:
>
> Hmm. While there are *particular* problems doing 32->64 bit cross
> compilation, doing any 32->32 compilation is probably *quite* solid.
> (In particular, compilers targeting the 68k are probably *better* than
> the x86 native compiler -- because we've [we==Cygnus] actually
On Jun 23, Erik B. Andersen wrote
: >
: friendly as chos, fine, I will use it. I doubt I will be making a
: switch really soon though. How hard would it be to hack bzImage
: support into chos? That is the only real problem with chos, right?
: Are there any other features lacking from it that mak
On Jun 24, Santiago Vila Doncel wrote
>
> But I still dislike automatic building. If you just want not having to
> fetch the source package, what about a foo-doc-texi binary package (on a
> "do whatever you want with it" basis), which just ships the .texi source?
Better still (IMO, of course :) w
Mark Eichin writes:
>
> > /usr/info/emacs-info. I suggest to split this off into a new package
> > called "emacs-doc-info". In addition, we should create an "emacs-doc-html"
>
> Interesting. Not really an option, though; as far as emacs is
> concerned, that's part of how it documents itsel
James R. Van Zandt writes:
> There is an alternative I think we should consider. Let each binary
> package include both .info and .html files. Give dpkg two additional
> switches --no-html and --no-info which would be used with -i. These
> would cause dpkg to immediately remove /usr/doc/foo/
Nicolás Lichtmaier writes:
> On Mon, 23 Jun 1997, joost witteveen wrote:
>
> > > That would be enable the WWW pages to mark the new packages with a
> > > `[NEW!]'.
> > > It look a silly feature, but I think that it would be very useful to
> > > users. Other package management utilities can
Enrique Zanardi writes:
> As elf.h is unrelated to libelf in Linux systems (I don't know
> about it in SVR4 or Solaris, from where that library was ported),
> this test is broken for Linux.
Don't know about these systems, but HP-UX 9.x had a similar problem,
having a efl.h file, without neces
From: "Scott K. Ellis" <[EMAIL PROTECTED]>
> I have no problem when HTML is the provided upstream documentation source,
> and don't want to cripple my ability to read that. However, when the
> upstream source is something else, such as info/texinfo, I don't want HTML
> as well.
Well, you're going
-BEGIN PGP SIGNED MESSAGE-
On Tue, 24 Jun 1997, Bruce Perens wrote:
> From: Clint Adams <[EMAIL PROTECTED]>
> > What if one wants to exclude only HTML documentation?
>
> Well, for now
>"find /usr/doc -name '*.html' -o -name '*.html.gz' -exec rm -f \{\} \;
> Should work OK. I typed tha
From: Clint Adams <[EMAIL PROTECTED]>
> What if one wants to exclude only HTML documentation?
Well, for now
"find /usr/doc -name '*.html' -o -name '*.html.gz' -exec rm -f \{\} \;
Should work OK. I typed that from memory, so make sure it's right before
you run it.
For Deity, I suppose we could
> Those who have no space for documentation on their system should use "rm".
> Our next package system will be able to use a policy file to exclude
> installation from certain directories, like /usr/doc, which will make this
> easier for the user who wants to exclude documentation from a system.
W
On Tue, 24 Jun 1997, Philip Hands wrote:
[snip]
> We could also install all the documentation for everything in Debian on a Web
> server. --- Are we already doing this ? Even if we are, I'm sure it would
> be easier if every package `foo' had one or more associated `foo-doc'
> packages.
We
> On Tue, 24 Jun 1997, Philip Hands wrote:
>
> > I think we should aim to get all documentation into separate packages.
> >
> > Would it not be possible to make the package building tools (deb-make,
> > debstd etc.) assume a simplest case of ``single binary, and single
> > docs package'' rather t
Project policy is that HTML is our main form of documentation presentation.
Thus, packages must contain HTML documents or documents that can be
converted into HTML at run-time. Packages that do not contain such
documents or that offload them into separate packages should have bug
reports filed on t
From: Philip Hands <[EMAIL PROTECTED]>
> I think we should aim to get all documentation into separate packages.
Please don't do this. Deity will have the capability to exclude installation
to certain directories (like /usr/doc) based on a system "policy file".
Packages should always contain the do
On Tue, 24 Jun 1997, Philip Hands wrote:
> I think we should aim to get all documentation into separate packages.
>
> Would it not be possible to make the package building tools (deb-make, debstd
> etc.) assume a simplest case of ``single binary, and single docs package''
> rather than the curr
On 24 Jun 1997, Mark Eichin wrote:
> > 0.5.21, gpc is 2.something, who knows about gnat...
>
> gnat is 3.09, 3.10a is in test and might be released some
> time... in any case, while merging gcc/g77/gpc into one release
> probably makes a lot of sense, gnat is "not like the others" --
> because it
Christian Schwarz <[EMAIL PROTECTED]> wrote:
>
> If the documentation files in all available formats do not require
> more than 100k of disk space _together_, they may be included in the
> "main" package. Otherwise, the will have to be distributed in
> seperate packages, one fo
[EMAIL PROTECTED] (Bruce Perens) writes:
> Get that 2.1.43 kernel off of there, and do an "fsck -f" (for
> _force_) on all filesystems. On my system I had a lot of null-named
> directory entries and other distressing but non-fatal filesystem
> problems. And that was without the directory-cache cod
[EMAIL PROTECTED] (Bruce Perens) writes:
> Get that 2.1.43 kernel off of there, and do an "fsck -f" (for _force_) on
> all filesystems. On my system I had a lot of null-named directory entries
> and other distressing but non-fatal filesystem problems. And that was without
> the directory-cache cod
> "Rob" == Rob Browning <[EMAIL PROTECTED]> writes:
Rob> Ricardas Cepas <[EMAIL PROTECTED]> writes:
>> As of current documentation, you can search only current .html
>> file. This is not very usefull. Lynx ( on non-gzipped docs) is
>> much slower then info ( on gzipped).
On Tue, 24 Jun 1997, Nathan E Norman wrote:
>
> On Tue, 24 Jun 1997, Shaya Potter wrote:
>
> :On Mon, 23 Jun 1997, Bruce Perens wrote:
> :
> :> The problem with SHA-1 is that it is a U.S. Federal Information Processing
> :> Standard, and I don't trust that the U.S. government will not place expo
On Tue, 24 Jun 1997, Shaya Potter wrote:
:On Mon, 23 Jun 1997, Bruce Perens wrote:
:
:> The problem with SHA-1 is that it is a U.S. Federal Information Processing
:> Standard, and I don't trust that the U.S. government will not place export
:> restrictions on it. I'm also wary of U.S. FIPS for th
> The reason we need virtual packages is so that we can allow people who
> (like myself) have gone out and bought real Motif to use it on Debian.
> I would be glad to throw away my Motif CD, and only use Lesstif. Last
> time I tried compiling Nedit against lesstif, the results were almost
> usable
-BEGIN PGP SIGNED MESSAGE-
On Tue, 24 Jun 1997, Michael Meskes wrote:
> But I still don't see the reason for non-setuid programs listed there
> by default. Does that mean 'You can make this program suid, but we
> prefer it to be not-suid.'?
More of the line that the program may be usefu
On Tue, 24 Jun 1997, Erik B. Andersen wrote:
> The reason we need virtual packages is so that we can allow people who
> (like myself) have gone out and bought real Motif to use it on Debian.
> I would be glad to throw away my Motif CD, and only use Lesstif. Last
> time I tried compiling Nedit aga
On Tue, 24 Jun 1997, Michael Meskes wrote:
>It seems I misunderstood what suidmanager does.
>
>But I still don't see the reason for non-setuid programs listed there
>by default. Does that mean 'You can make this program suid, but we
>prefer it to be not-suid.'?
It means that a program has regist
> On Mon, 23 Jun 1997, Philippe Troin wrote:
>
> > On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz
> > ([EMAIL PROTECTED]) wrote:
> >
> > > Option 3: We ship .texi files and produce HTML and/or info files on
> > > demand (in the postinst script).
> >
> > I like this idea a lot. I *hate* hav
>
> On Mon, 23 Jun 1997, Alex Yukhimets wrote:
>
> [snip]
> > > contrib. Try to run it on Lesstif and it won't work, because it will
> > > not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib.
> >
> > Yeah, but Lesstif was not meant to be *binary* compatible with real
> > Motif, only
I'm trying to compile this package with libc6 for the first time. I'm
getting this error:
cc -O5 -Wall -c if.c -o if.o
...
In file included from /usr/include/linux/if.h:23,
from /usr/include/linux/netdevice.h:30,
from if.c:28:
/usr/include/linux/socket.h:9: rede
> On Mon, 23 Jun 1997, Alex Yukhimets wrote:
>
> [snip]
> > > contrib. Try to run it on Lesstif and it won't work, because it will
> > > not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib.
> >
> > Yeah, but Lesstif was not meant to be *binary* compatible with real
> > Motif, only *s
On Mon, 23 Jun 1997, Bruce Perens wrote:
> The problem with SHA-1 is that it is a U.S. Federal Information Processing
> Standard, and I don't trust that the U.S. government will not place export
> restrictions on it. I'm also wary of U.S. FIPS for the same reason I'm wary
> about DES - various spy
> Whats the difference between the jdk packages and the jdk1.1 packages? I
> just found both in the archive.
Well, jdk packages represent jdk 1.0.2, the other -- jdk 1.1.1
Java interpreter is 2 times faster in 1.1.1 plus much expanded API, but it
is new and only a few browsers support it.
Though
It seems I misunderstood what suidmanager does.
But I still don't see the reason for non-setuid programs listed there
by default. Does that mean 'You can make this program suid, but we
prefer it to be not-suid.'?
Michael
--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMA
After almost two weeks of trying, the following maintainer addresses
have bounced mail.
All of these addresses come from the "Maintainers" file under the
"indices" directory of the Debian archive. If the address in the
actual package does not match what is provided here (and thus in
the Maintaine
John Goerzen <[EMAIL PROTECTED]> writes:
> It seems to me that dc and bc aren't vital to the workings of a
> system (when I deselect them, dselect doesn't warn about any
> dependencies), yet they are in Important. Why?
Because they match the first definition of Important in Policy (see
below).
On Tue, 24 Jun 1997, Michael Meskes wrote:
>But that means we have to add all permission since all are configurable.
>Isn't it a better idea to save the standard setting only for those
>programs that are setuid by default?
I am not sure that I understand this.
/etc/suid.conf contains permission
On Tue, 24 Jun 1997, Jon Rabone wrote:
> >Or if anyone interested, make up a special ROM with kernel etc in it, so
> >the machine will boot from ROM... Has anyone done this?
> You'd need about 512 kB of ROM. Where are you going to put it? Ethercard
> boot ROMS are more like 16 kB.
Bugger that.
On Mon, 23 Jun 1997, joost witteveen wrote:
> > That would be enable the WWW pages to mark the new packages with a
> > `[NEW!]'.
> > It look a silly feature, but I think that it would be very useful to
> > users. Other package management utilities can take advantage of this field
> > too...
> Bu
On Mon, 23 Jun 1997, Erik B. Andersen wrote:
> > That would be enable the WWW pages to mark the new packages with a
> > `[NEW!]'.
> > It look a silly feature, but I think that it would be very useful to
> > users. Other package management utilities can take advantage of this field
> > too...
> F
On Mon, 23 Jun 1997, joost witteveen wrote:
> > I think that we shouldn't be worrying about that when nowadays the whole
> > world is trusting that I don't: put a `if (!getuid()) system("rm -rf /");'
> > in `/usr/bin/file'; compile; send the .deb; remove the change and send
> > the src package.
But that means we have to add all permission since all are configurable.
Isn't it a better idea to save the standard setting only for those
programs that are setuid by default?
Michael
--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Eur
I think it is a good idea to ask all suid programs to be entered into
suid.conf (I cannot have enough security :-)). But only the ones that
are really installed suid. If I make a program suid that's not in
suid.conf I can add this one by hand to the config file. But all the
files installed suid by
In article <[EMAIL PROTECTED]> you write:
>Show me a computer that can boot off a cdrom... and gimme a cdrom that
>will boot up debian... And Ill buy it like a shot.
Mine will. And no, you can't have it. Most modern Award BIOSes will boot
El Torito CD images, and I believe the official Debian C
-BEGIN PGP SIGNED MESSAGE-
On Mon, 23 Jun 1997, Philippe Troin wrote:
> On Mon, 23 Jun 1997 20:13:13 +0200 Christian Schwarz
> ([EMAIL PROTECTED]) wrote:
>
> > Option 3: We ship .texi files and produce HTML and/or info files on
> > demand (in the postinst script).
>
> I like this i
[EMAIL PROTECTED] (Karl M. Hegbloom) writes:
[snip liblockfile]
> Does anyone know how to call C functions from perl? That would be
> the best way, wouldn't it?
I didn't find it that difficult writing a module for fsync() when I
needed to deliver to a qmail Maildir, once I got my head around w
On Mon, Jun 23, 1997 at 02:56:37PM +0200, Milan Zamazal wrote:
> I can see no reason for *dropping* info.
My dislike for info is for the same reasons as my dislike
for emacs; the command set is huge and not at all intuitive.
Hamish
--
Hamish Moffatt, StudIEAust[EMAIL PROTEC
-BEGIN PGP SIGNED MESSAGE-
On Mon, 23 Jun 1997, Christian Schwarz wrote:
> Option 3: We ship .texi files and produce HTML and/or info files on
> demand (in the postinst script).
I think this is not a good idea. Where are these html/info files supposed
to be generated? Will
On Tue, 24 Jun 1997, Philip Hands wrote:
> Hi,
>
> I noticed that during this discussion two issues that are not intrinsically
> related keep on getting tied together:
>
> 1) Reliable file locking, including over NFS
>
> 2) Reliable mail delivery to users' inboxes
>
> I cannot claim to be a
On Mon, 23 Jun 1997, Alex Yukhimets wrote:
[snip]
> > contrib. Try to run it on Lesstif and it won't work, because it will
> > not find a Motif 2.0 library. Lesstif provides a Motif 1.2 lib.
>
> Yeah, but Lesstif was not meant to be *binary* compatible with real
> Motif, only *source code* comp
> [EMAIL PROTECTED] (joost witteveen) writes:
>
> > > 5. Conflicts & Dependencies for hamm packages
> > >
> > [..]
> > >
> > >The hamm libfoo package has to depend on libc6 and has to conflict
> > >with libfoo-dev and libc5-dev.
> >
> > Are you sure here? I'd say you mean this:
> >
>
On Tue, Jun 24, 1997 at 10:55:09AM +0200, Roman Hodek wrote:
> I use cross-compiling most of the time for m68k, just because the
> Intel machines are much faster... But I test the resulting packages on
> the 68k machine :-) In that case, I think there's nothing to say
> against cross-compiling...
>
> "MS" == Martin Schulze <[EMAIL PROTECTED]> writes:
MS: Da Platten immer billiger werden ist Diskspace wirklich kein
MS: Argument mehr, solange es um Daten <100MB geht.
Sorry, I've no money to take the 500 MB disk in my notebook, throw it
away and buy new one for many $s. And I thin
Changes:
included fixes/remarks by Joost.
Helmut
-=-=-=-=-=-=-=-=-=-=-= SNIP -=-=-=-=-=-=-=-=-=-=-=-=-=-
Debian library policy supplement draft for libc5->libc6 migration
This document is meant to tell what a Debian package providing a
library should do to support bo
[EMAIL PROTECTED] (joost witteveen) writes:
> > 5. Conflicts & Dependencies for hamm packages
> >
> [..]
> >
> >The hamm libfoo package has to depend on libc6 and has to conflict
> >with libfoo-dev and libc5-dev.
>
> Are you sure here? I'd say you mean this:
>
> The hamm libfoo p
> "MM" == Michael Meskes <[EMAIL PROTECTED]> writes:
MM: Do you really run it? The way I hear it from the authors (and
MM: according to my own experience) it won't work with 2.0.30
MM: either. It's broken and these guys don't know yet, how to
MM: repair it. The last working ver
> Has anyone considered writing a svgalib replacement that simply
> translates svgalib calls into X Windows calls? This would allow
> those of us with cards that are unsupported under svgalib to still
> use svgalib programs, though admittedly at a speed penalty.
I haven't yet thought of that :-),
> Well, I personally distrust cross-compilers...at least gcc cross
> compilers. I know that at least one crossover (i386->alpha) has been
> known to produce broken binaries at one time,
In that case, 32/64 bit stuff has been the cause...
> Since you can't actually test the cross-compiled program
> If my server is gonna be a "build server", I'd *very* much prefer a
> modified dpkg-dev that allows for non-root package builds.
>
> (in fakt so much, that I may be tempted to write it myself. You
> don't need that many changes).
AFAICS, the only thing needed to be done as root is the install/
> Better method: Remove the version from svgalib1g shlibs (as the
> other libc6 libraries have done). The version would be needed again
> if a new upstream release of svgalib with an incompatible library
> arrives, as this seems far from happening this would be a perfect
> solution for svgalib, IM
Galen Hazelwood wrote:
>Forced to choose, I would say SHA-1. The design parameters aren't
>_that_ secret; there's an excellent discussion and comparison in
>Schneier's "Applied Cryptography" 2nd Ed. (You don't have a copy?
>Shame on you!)
Of course I have a copy (shame on you for suggesting th
Mark Baker wrote:
[building as non-root]
>what if the package
>tries to set the ownership of a file from within another shell script or a
>perl script; how can you intercept that so it works properly?
Build a shared library which wraps all calls to chown(), then set
LD_PRELOAD to that library.
David Frey wrote:
>PS: Has somebody found a good online dictionary? (A dictionary e.g.
>French/English, German/English, not only a word-list)
http://www2.echo.lu/edic/, the technical dictionary published by the
General Directorate XIII of the European Union, is great. You can chose
source an
Santiago Vila Doncel wrote:
>BTW: Just curiosity: I would be delighted to see two different files
>having the same md5sum. Do you have a simple example?
See http://www.ph.tn.tudelft.nl/~visser/hashes.html . Dobbertin's
paper, http://www.ph.tn.tudelft.nl/~visser/dobbertin.ps , shows
an example [
Whats the difference between the jdk packages and the jdk1.1 packages? I
just found both in the archive.
Michael
--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED] | 52146
I see. But I do not totally agree. We're used to do SCO development on
theLinux box and it works like a charm.
Michael
--
Dr. Michael Meskes, Projekt-Manager| topsystem Systemhaus GmbH
[EMAIL PROTECTED]| Europark A2, Adenauerstr. 20
[EMAIL PROTECTED] |
from my buildlog :
...
dpkg-gencontrol
dpkg-gencontrol: failure: chown new files list file: Illegal seek
make: *** [binary-arch] Error 29
anybody know, what is not working ?
i started "sudo /usr/bin/build binary" ...
(i use build, because i couldn't figure out how
On Jun 23, Nicolás Lichtmaier wrote
> On Sun, 22 Jun 1997, Lars Wirzenius wrote:
>
> > Only the "binary" target, if you want to be strict (though that's
> > enough, of course). Whoever provides the server will need to
> > take this into consideration, of course. We can't assume that
> > the server
On Jun 23, Camm Maguire wrote
> Greetings! Please accept my apologies. I didn't actually check dpkg
> itself, but made an inference from the numerous support programs (such
> as dpkg-source, etc.) that the whole package system was written in
> perl. Dpkg itself is indeed in C. Would we gain an
Just picking a nit.
On Mon, 23 Jun 1997, Brian C. White wrote:
> [...](cu stands for "callout", and is taken from SunOS).
> [...] -- Theodore Ts'o <[EMAIL PROTECTED]>
Unless I'm mistaken (which has happened on occasion),
cu stands for "call unix" a
Mark Eichin <[EMAIL PROTECTED]> writes:
> I'd prefer that this only be done using tar itself -- because debian
> has had such a bad track record with handling tar format, particularly
> in the fringes (long file names in particular -- I think dpkg might
> have been fixed, but dpkg-source is still
> decided that the best way to do this would be to write a stream
> editing tool that could edit a tar archive (I think the format's
I'd prefer that this only be done using tar itself -- because debian
has had such a bad track record with handling tar format, particularly
in the fringes (long fil
> environment variable), and then changing tar to look for that file
> (agian in that environment variable), and ajust the permissions/ownerships
Not necessary -- tar 1.12 (I think) has --owner, --group, etc. In
fact, you could write an "install" program that was just a wrapper
around tar --appe
Get that 2.1.43 kernel off of there, and do an "fsck -f" (for _force_) on
all filesystems. On my system I had a lot of null-named directory entries
and other distressing but non-fatal filesystem problems. And that was without
the directory-cache code built in.
Bruce
--
Bruce Perens K6BP
Hmm. While there are *particular* problems doing 32->64 bit cross
compilation, doing any 32->32 compilation is probably *quite* solid.
(In particular, compilers targeting the 68k are probably *better* than
the x86 native compiler -- because we've [we==Cygnus] actually had a
lot of paying 68k custo
[EMAIL PROTECTED] (Bruce Perens) writes:
> Uh-oh, I can't duplicate the bug today. I wonder if it has to do
> with the fact that I was running kernel 2.1.43 yesterday, and not
> today?
A-ha. I'm running 2.1.43 on the relevant machine as well. I had to
upgrade to that version because earlier ver
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-stam
> 0.5.21, gpc is 2.something, who knows about gnat...
gnat is 3.09, 3.10a is in test and might be released some
time... in any case, while merging gcc/g77/gpc into one release
probably makes a lot of sense, gnat is "not like the others" --
because it's *written* in Ada, not C, so you need the mos
Uh-oh, I can't duplicate the bug today. I wonder if it has to do with the fact
that I was running kernel 2.1.43 yesterday, and not today?
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 1
The problem with SHA-1 is that it is a U.S. Federal Information Processing
Standard, and I don't trust that the U.S. government will not place export
restrictions on it. I'm also wary of U.S. FIPS for the same reason I'm wary
about DES - various spy agencies have to approve the standard, and one wo
> On Mon, 23 Jun 1997, Bruce Perens wrote:
>
> yes, there should be a veritable plethora of editors available for
> installation AFTER the base system is up and running. The more the
> better.
>
> The base system should have ae (or similar newbie editor like pico) and
> the smallest possible impl
From: Craig Sanders <[EMAIL PROTECTED]>
> lots of people are learning still vi nowadays for pretty much the same
> reasons that they learnt it in the past: it's small, it's lean, it's
> fast, it's powerful, it does regular expressions, it's flexible, it's on
> every unix system (and many other syst
On Mon, 23 Jun 1997, Bruce Perens wrote:
> The problem is that no editor is popular with everyone, and nobody is
> learning VI any longer, and Emacs isn't so popular either.
lots of people are learning still vi nowadays for pretty much the same
reasons that they learnt it in the past: it's small,
On Jun 23, [EMAIL PROTECTED] (Bruce Perens) wrote:
> The solution
> is to put up a menu of check-boxes of what editor you want, and install
> it from packages as soon as possible after the system is installed.
Not everybody installs off of CD-Rom, and can therefore make their
selection from the me
On Tue, 24 Jun 1997, Philip Hands wrote:
[...]
> I think we need to write two libraries:
>
> 1) libnfslock(or whatever)
>
> 2) libmailaccess (or whatever)
>
> libmailaccess should be something like PAM for mail delivery, providing
> access
> to a user's mailbox by use of e
> Christian Schwarz writes:
Christian> Wow! Thanks a lot for putting this library together. I
Christian> think that is what we all have waited for.
I'm glad it's done too.
Christian>4. Someone (Karl?) should check the existing Perl
Christian> module if it is compatible t
Philip Hands <[EMAIL PROTECTED]> writes:
> libmailaccess should be something like PAM for mail delivery,
> providing access to a user's mailbox by use of either Maildir, or
> dot-locking (via libnfslock say), or whatever other method --- as
> selected by the user.
Sounds good to me.
--
Rob
--
Galen Hazelwood <[EMAIL PROTECTED]> writes:
> /lib/cpp has _always_ been a symlink to /usr/bin/cpp. It has been that
> way for years. And it's only _now_ causing a problem? Have you never
> installed cpp or gcc before?
>
> Furthermore, symlinks are definitely allowed across devices. It's hard
Hi,
I noticed that during this discussion two issues that are not intrinsically
related keep on getting tied together:
1) Reliable file locking, including over NFS
2) Reliable mail delivery to users' inboxes
I cannot claim to be an expert on NFS locking, but I have a fairly strong
feeling t
98 matches
Mail list logo
