I have been running the 2.3b3 version from experimental. I have
had a few problem with it, assuming those problems were a result of it
being a beta version. I think the only reason 2.3b3 is in experimental
was because it was a beta version. Now that the final release is out, it
might be
Hamish Moffatt wrote:
On Jun 22, Galen Hazelwood wrote
Hamish Moffatt wrote:
Nope. What happens is most (single-cpu) developers upload the source
and binaries for one architecture. Then helpful and nice developers who
own other machines upload binaries for their cpu, built from the
Christoph == Christoph Lameter [EMAIL PROTECTED] writes:
Christoph Lilo 2.0 has the ability to display a file before the
Christoph prompt and also the ability to boot something with a
Christoph single keystroke. If someone could update the lilo
Christoph package and
ghughes == ghughes [EMAIL PROTECTED] writes:
ghughes True. However, it can't handle gzipped pages, and
ghughes hacking it to do so seems a) special case (because
Ermm... on my system it can. lynx 2.7-1 (self compiled).
netscape also handles it very well. I can't say about others
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?
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL
Thomas Koenig wrote:
An attractive alternative would be RIPEMD-160. SHA-1, another
alternative, has the main problem that its design parameters are secret.
Source code for RIPEMD-160 is avialiable, and the algorithm is in the
public domain. For more information, you can check out
Mathieu Guillaume wrote:
Package: cpp 2.7.2.2-5
This is the same kind of bug that was reported as #10753
(update-alternative).
When I try to upgrade to this version, I get an error related to
cross-device links (/lib/cpp is a symlink to /usr/bin/cpp, which is
mounted on a different
[EMAIL PROTECTED] (joost witteveen) writes:
No, what I had in mind is changing chmod, chown and frends, and make
them log the intended permissions in a file (specified somewhere in
a environment variable), and then changing tar to look for that file
(agian in that environment variable), and
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
--
TO
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.
Christian4. Someone (Karl?) should check the existing Perl
Christian module if it is compatible to this
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 either
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 menu
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,
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 systems
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
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
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
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
[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
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
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
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 --append,
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 file
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
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 and is
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]
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] |
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 [
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 and
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 that I
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, IMO.
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/chown
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 programs
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
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 think there
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...
[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
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*
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 an expert
-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
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
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
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]|
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.
Well,
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...
Fine with
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...
But at the
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. How
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
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
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
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*
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*
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
-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 useful
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,
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 the
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).
Rob Oh, right I
[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 code
[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 code
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 for each
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's
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 current
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
-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 that from
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 take
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
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 itself.
[...]
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 :) would
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
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 had a
70 matches
Mail list logo
