Re: 2.0.32, XNvidia, Vtk

[Karl M. Hegbloom]

> "Arto" == Arto Astala <[EMAIL PROTECTED]> writes:

Arto> When configuring kernel it asks if I want to make boot disk.
Arto> I did want. Then it asks something like "Hmm. You seem to
Arto> have new superformat, want to use it?" and I felt I'm taking
Arto> risks already and I don't want to answer yes to anything
Arto> this dubious.  Then it tried to create floppy with old
Arto> format (and with non-existing device as well?) but didn't
Arto> succeed. There was no obvious way to back up to "Hmmm. ..."
Arto> or otherwise correct the situation.

 I've found that during installation, I often want a way to go back to
 the previous thing like that, in case I've made a mistake.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Does `dpkg' track the installation date of a package?

[Remco Blaakmeer]

On Thu, 18 Dec 1997, Raul Miller wrote:

> Todd Graham Lewis <[EMAIL PROTECTED]> wrote:
> > Count mine as one vote for a new LOG_DEBIAN facility.
> 
> Is syslogd guaranteed to not lose events under debian?

No, you could go into single user mode, where syslogd is simply turned
off, and use dpkg to do anything it normally does. Syslogd would obviously
miss the whole event.

I think the log file(s) would have to be updated by dpkg itself.

> [It has no such guarantee for the general case.]

Indeed.

Remco
-- 
If you can't beat your computer at chess, try kick-boxing


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: writev broken in linux?

[Mark W. Eichin]

linux 1.x/libc4 had writev implemented in libc, with no kernel
support.  This implementation was, to put it kindly, "marginal".  I
think libc5 added code to check if you had SYS_writev and use it, if
not, fall back to the old code.  I'm not sure which kernel actually
added the writev syscall, nor am I sure of how good it is.  There are
some subtle "corner" cases which are hard to get right.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Questions about emacs20 file system layout.

[Mark W. Eichin]

> .elc files compiled with emacs 19.z with z >= 29 will only work on
> emacs 19.29 or later.

Doesn't setting byte-compile-compatibility help with this, or is it
too much of a performance loss?


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Emacs20 and mail file locking.

[Mark W. Eichin]

I'll note that emacs19 does what was right at one point, *before*
liblockfile was written; I don't know if they're compatible but figure
that before debian 2.0 it would be safest to code up a fix.  (Or steal
your code from emacs20 :-)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Does `dpkg' track the installation date of a package?

[Dirk Eddelbuettel]

  Karl>  I wonder if `dpkg' tracks the installation date of a package,
  Karl> whether it should if it doesn't, or why it doesn't if that is the
  Karl> case.

Yes, at least sort of, provided you use dselect with the dpkg-mountable
package. Then at least all uses of dpkg that stem from dselect are logged.
dpkg-mountable is pretty cool, it also liberates you from the 'dselect uses
stat() on every file' problem by constructing a list of what needs to be
installed. 

Real-life example of the logfile:

[EMAIL PROTECTED]:~> head -20 /var/log/dpkg-mountable


===
dpkg-mountable, run on Sun Dec 14 09:48:58 1997

---
Run details:

Installing package fmirror version 0.8.2-1 from 
/mirror/debian/dists/unstable/main/binary-i386/net/fmirror_0.8.2-1.deb
MD5 checksum 56f4589d4bca4965a54ebf5b0f542e92 matches.
Upgrading kernel-package from 3.47 to 3.48 from 
/mirror/debian/dists/unstable/main/binary-i386/misc/kernel-package_3.48.deb
MD5 checksum 8f03421f1c67691597b0db84f07f8bab matches.
Upgrading mount from 2.7f-1 to 2.7g-1 from 
/mirror/debian/dists/unstable/main/binary-i386/base/mount_2.7g-1.deb
MD5 checksum e48c24aebc574d737ca2e970738f2d7e matches.

[...]

--
[EMAIL PROTECTED]   According to the latest official figures, 
http://rosebud.ml.org/~edd43% of all statistics are totally worthless.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Emacs20 and mail file locking.

[Rob Browning]

[EMAIL PROTECTED] (Mark W. Eichin) writes:

> I'll note that emacs19 does what was right at one point, *before*
> liblockfile was written; I don't know if they're compatible but figure
> that before debian 2.0 it would be safest to code up a fix.  (Or steal
> your code from emacs20 :-)

My suspicion is that the way it's done now in emacs 19 will still work
as well as it did before, which is probably fine for everything but
NFS.  Using maillock would fix the problem completely, but will
probably require some code weaselry.

Unfortunately, the policy says to check the implementation in maillock
to see if you're compatible, and the manpage for maillock says to see
lockfile_create(3), which doesn't exist.  I'll have to UTLSL, but I
may release an initial package before doing all that.  Things won't be
any worse than they are now, and then then I can see about fixing
both emacsen.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

New package wzip

[Andreas Franzen]

Hi,

wavelet transformation can be effectively used for lossy compression
of measurement/process data. This gets more and more important because
of modern quality management systems. Data compression is usually very
complicated. While I was working on the denoising of EDX-scans with
wavelet transformation, I found it possible to do lossy data compression
very easily by putting wavelet transformation followed by
quantization to small integers in front of loss-less compression with
gzip.

I am intending to make a program wzip to do this preprocessing,
leaving the difficult task to gzip. The program will use the
Haar-wavelet transformation.

Any suggestions are welcome.

Andreas Franzen <[EMAIL PROTECTED]>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

New package: makeports

[Elie Rosenblum]

After talking with some *BSD-using friends, I decided this might be an
interesting project...basically, it would read the available file (yes, I
know this is frowned upon, but this seems to be the best way to get some
of this stuff) and construct a ports tree, similar to /usr/ports in the
free BSD's. When you enter the directory for a package you can run make
with several options, to build .deb's, just build binaries, or just get
the latest version of the source packages.

Anyway, just wanted to hear some comments before I decide whether it's
worthwhile to code.

-- 
Elie Rosenblum <[EMAIL PROTECTED]>   That is not dead which can eternal lie,
 <[EMAIL PROTECTED]>  And with strange aeons even death may die.
Developer / Mercenary / System Administrator - _The Necromicon_


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: New package: makeports

[Turbo Fredriksson]

On Fri, 19 Dec 1997, Elie Rosenblum wrote:

> When you enter the directory for a package you can run make
> with several options, to build .deb's, just build binaries, or just get
> the latest version of the source packages.

Do you meen 'Debian-on-xxxBSD'? If that's the case, I'm working on a FreeBSD
port right now, and anogher fellow here have some other intresting ports...

---
 Turbo_ /// If there are no Amigas in heaven, send me to HELL!
 ^\\\/
 Unix _IS_ user friendly - it's just selective about who its friends are !
 Turbo Fredriksson Tel: +46-704-697645
 S-415 10 Göteborg[EMAIL PROTECTED]
 SWEDEN www5.tripnet.se/~turbo
   My PGP key can be found at: 'www5.tripnet.se/~turbo/pgp.html'
 Key fingerprint = B7 92 93 0E 06 94 D6 22  98 1F 0B 5B FE 33 A1 0B 
---


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: writev questions - epic maintainer speaks

[ioannis]

On Thu, Dec 18, 1997 at 10:15:00AM +0200, Kai Henningsen wrote:
> >
> > @chimchim [~] $ nc -l -p 4000
> > /dev/ttyp6
> >
> > There is a newline, it's transmitted fine, but, here is the tcpdump:
> 
> Umm - TCP? I'm not the TCP expert, but I understand that TCP doesn't ever  
> guarantee where it's going to put packet boundaries. That's supposed to be  
> a stream, and packet boundaries are supposed to be invisible to the upper  
> layers, except for timing.


  The default behavior of TCP is to send the segment when the output-socket-
buffer gets filled. The socket flag IPPROTO_TCP,TCP_NODELAY alters this 
behavior, and I suspect that the problem is probably not with writev
but with libc6 not understanding this flag. Two months ago I was having
trouble with locating this flag in the libc6 headers, though, lib5 
understood it fine.

  In my application was sending tiny interactive packets and did not notice
anything unusual with writev. I would be most surprised if this is not
the case.



-- 

Ioannis Tambouras
[EMAIL PROTECTED], West Palm Beach, Florida
Signed pgp-key on key server.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

apache 1.2

[Hamish Moffatt]

The apache 1.3 package doesn't seem to have the mod_auth_dbm
module which we need on our web server (I find it easier
to manage the crypted passwords with dbmmanage than in text files),
but the apache 1.2.4 package is nowhere to be found. Does anybody
have a copy on their mirror that they could send me?

thanks,
Hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Recompiling elisp files (Re: Taking over production of emacs20 package.)

[Christian Lynbech]

> "Manoj" == Manoj Srivastava <[EMAIL PROTECTED]> writes:

Manoj> Hi,
>>> "Christian" == Christian Lynbech <[EMAIL PROTECTED]> writes:

Christian> I am not quite so pessimistic about the possibilities of
Christian> recompiling installed elisp files.

Manoj>  Please, people, do download the sources for tm and compile a
Manoj> local copy before you display such unwarranted optimism
Manoj> ;-). 

I know both hyperbole and tm, since I maintain both at the local emacs
installation. Communicatin with the tm build process is close to being
the most complicated thing I have encountered as an emacs hacker :-)

Manoj>  I am including the Makefile in the tm/ subdirectory
Manoj> below. Running make in that directory triggers recusive makes
Manoj> in all sibling directories, and the make run is modified by
Manoj> elisp in several *-CONFIG files.

Sure thing, but once the files are installed, it should be possible
(save for ordering) to recompile the stuff file-by-file without going
through the large procedure of the real build process.

Manoj>  Umm, hyperbole and tm both have multidirectory complex make
Manoj> relationships; and unless we ship the make files in the
Manoj> distribution (/usr/lib/emacs/site-lisp/tm/Makefile?), it is
Manoj> difficult indeed to compile them in a postinst hook (it can be
Manoj> done, at the expense of potentially having to re-craft the
Manoj> compiler on upstream upgrades).

Well, I'm still optimistic. Working recursively through directories is
not difficult (byte-recompile-directory already does this), so if I am
correct that we "only" need to compile in the right order (and that we
can do that), it is doable.

Manoj>  Debian does not use the concatenated elc files option; we do
Manoj> use the little files. 

I used it mainly as an example, since this is the one package that I
know of that will produce an .elc file which does not correspond to an
.el file.

Manoj> But the little files are not generated in random order;

No, but I claim we can fix this, in the sense that we either can
record the order and supply it to the process (simpler than having to
supply a fullblown makefile; for instance tm uses files that are not
part of the installed set) or deduce it automatically. It should be
straightforward (allthough not trivial) to walk a set of elisp files,
recording which files defines what functions and where these functions
are used, and then do a topological sort to detemine the compilation
order.

Manoj>  Quassia Gnus, vm, tm, bbdb, w3, hyperbole,  (need I go
Manoj> further?). The problem maybe masked for red gnus if an older
Manoj> version of the el/elc files is installed in the standard path;
Manoj> I do not think that bbdb and hyperbole compile with older
Manoj> versions.

I do not think things are that bad. I did a quick test on our
w3-2.2.26 installation (doing `emacs -batch -q -f batch-byte-compile *.el') 
and the only error I got was from w3-xemac.el, since I have not
installed w3-toolbar. And as said, one can do the alphabetical
recompile on the standard lisp/ directory without problems.

Ok, enough hot air. I'll go back and do some more thinking and
testing. I will have a look at the compilation order analyzer and try
to check some of the packages for these ordering problems.


---+--
Christian Lynbech  | Computer Science Department, University of Aarhus
Office: R0.32  | Ny Munkegade, Building 540, DK-8000 Aarhus C
Phone: +45 8942 3218   | [EMAIL PROTECTED] -- www.daimi.aau.dk/~lynbech
---+--
Hit the philistines three times over the head with the Elisp reference manual.
- [EMAIL PROTECTED] (Michael A. Petonic)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Xfree86 3.3.1

[Rainer Dorsch]

I am wondering, if there is a bo version of Xfree86 3.3.1? This seems extremly 
important to me, since so many new (low end) computers come with ATI 3D 
charger graphics adapter, which requires 3.3.1.

I think Debian should have a stable version, which installs smooth on a new 
computer. Is there a plan to release 1.3.1.r7 with the new server or is there 
already a resonable stable hamm system for these systems, which _can_ be 
installed from scratch without installing 1.3.1 and upgrade using the (several 
pages long) MINI-HOWTO.

Thank you (could you include a CC to me, because I am reading only the archive 
of the mailing list).

-- 
Rainer Dorsch
Abt. Rechnerarchitektur  e-mail:[EMAIL PROTECTED]
Uni StuttgartTel.: 0711-7816-215



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: apache 1.2

[Hamish Moffatt]

Package: apache
Version: 1.3b3-6

On Fri, Dec 19, 1997 at 08:28:40PM +1100, Hamish Moffatt wrote:
> The apache 1.3 package doesn't seem to have the mod_auth_dbm
> module which we need on our web server (I find it easier
> to manage the crypted passwords with dbmmanage than in text files),
> but the apache 1.2.4 package is nowhere to be found. Does anybody
> have a copy on their mirror that they could send me?

As far as I can tell from the bug index (the bugs themselves
have expired), dbm in Apache is obselete and has been removed.
Despite this, the package still provides mod_auth_dbm.info, .html,
and the dbmmanage script. Also, there is no indication on
www.apache.org that mod_auth_dbm is obselete, and the page
for it is marked Apache 1.3.

I have converted our dbm files to GNU db with a perl script I wrote
and it now works fine. The dbm situation is confusing though.

hamish
-- 
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome.   http://hamish.home.ml.org


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Recompiling elisp files (Re: Taking over production of emacs20 package.)

[Milan Zamazal]

Two further small reasons against install time .el compilation of large
packages:
1. I have to install .el sources even when I don't need them.
2. Slow installation.

The first is a problem on computers with limited disk space (e.g. my
laptop).

The second is the problem when I perform major upgrade.  I can go to get
some koffee during unpacking packages, but then I have/want to answer
some installation questions.  If things like gnus was compiled during
this procedure, I'd be angry (things like texhash and menu/manpage
updates on background are annoying enough already).

Milan Zamazal


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: Moving topics from debian-private

[Milan Zamazal]

> "AY" == Alex Yukhimets <[EMAIL PROTECTED]> writes:

AY: Nothing strange. After a couple of _years_ of struggling in
AY: attempts to learn emacs (I made about 6 attempts total) I found
AY: a *great* relief in...  vi (vim actually). I was able to get
AY: used to it only after 2-nd attempt.

:-) Oh, I hope vim handles followups correctly, so we have a solution
for non-Emacs people too. ;-)))

BTW, I have all public Debian lists merged into a single nnml group in
Gnus.  So I can't use `reply-to' group parameter simply.
Does anybody know, how to (simply) followup only to the appropriate list
(I delete other addresses manually now :-( )?

Milan Zamazal


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Perl installation problem

[Robert D. Hilliard]

 While testing the upgrading of rex to hamm I have discovered
several problems or possible bugs.  I will post each of these as
separate messages, and ask if anyone else has encountered them, and if
they should be reported as bugs.

 While updating perl 5.003.07-10 using perl_5.004.04-3.deb, I first
installed perl-base_5.004.04-3.deb, then perl_5.004.04-3.deb. This
resulted in the following error:

dpkg: error processing perl (--install):
 subprocess post-installation script returned error exit status 123

 The perl.postinst script was examined, and the effects of the
commands in this script were checked.  The symlinks and directories to
be created by this file existed, and the directories to be removed
were not there.  A dummy perl.postinst was prepared, and perl
configured successfully by dpkg.

 I am using bash 2.01-5, and a custom compiled kernel 2.0.27.
This problem is reproducible, at least on my system.  I have 

 The problem appears to be in the last command in perl.postinst:

"   find /usr/lib/perl5/i486-linux -type d -links 2 -print0 | xargs -r0
rmdir -p 2> /dev/null
fi
# the last will remove all the directories that are now empty or will 
be empty when the empty subdirs disappear"

  This command is intended to remove any empty subdirectories
in /usr/lib/perl5/i486-linux.  On my system, this find command returns
three non-empty directories, which the rm command properly refuses to
remove.  So far so good.  However, since the script is set -e, this
causes it to exit immediately with a non-zero exit status [1].  IMHO,
the -e option should be unset prior to this command, and another error
trapping approach used that does not cause the script to fail when the
rm command acts properly.

 As a test, I have removed the output redirection from this script
and inserted echo statements before and after the find command in
question.  The echo statement immediately before the find command is
executed, but the script exits before executing the second echo
command.

 Has anyone else encountered this failure in perl?

 Should it be reported as a bug against perl?

[1] The -e option does not cause a script to exit "if the command that
fails . . . is part of an if statement".  I am not sure if this means
part of an if . . . then construct, or just part of the conditions of
the if statement, but I believe it is the latter.

Bob


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: 2.0.32, XNvidia, Vtk

[Arto Astala]

manoj: 
> >>"Arto" == Arto Astala <[EMAIL PROTECTED]> writes:
[...]
> 
>   Oh.

I know, I was daring, I wanted to try it out and, 
essentially, nothing very bad happened, since I was 
able to recover with reasonable amount of work.

> Arto> [...]
> 
>   The reason that the script asks about using superformat stems
>  from the days when superformat was newly introduced; and it had
>  problems. If that has indeed changed, I shall make the script not
>  ask. 

Since somewhere recently devices were changed fdformat 
no longer works for me. 

> 
>   Actually, embarrasingly enough, niether seems to work for me:
> [...]
>   I think I may well remove this option of formatting the
>  floppy. It has aways given me problems.

Probably just ask user to ensure that there is formatted
(but not necessarily empty) floppy, switch to another vc
if needed to do it.

> 
> Arto> [...]
> [...]
>   And it does ask you if you want to run lilo.

My mistake. I was writing this from memory, 2 days after the fact.

> 
>   The process does stop, and inform you about failure to write a
>  boot floppy. You have to hit return to proceed. It warns about not
>  being able to reboot the system.
> 
>   At this point, unless lilo is run, the system is
>  unbootable. Not running lilo is wrong, IMHO.

If *no files (other than lilo.conf)* that lilo knows about 
are changed in any way *then* lilo boots as before. That is,
if map file and all files recorded in it are present in the
same physical locations as before. 

> 
> Arto> [...]
> 
>   What was the error? was the new lilo.conf incorrect? in what
>  way? 

line
  boot=/dev/hda5
since hda5 is logical partition and not easily bootable

Running lilo with this config might have updated map
file, thus rendering old boot inoperable. On the other 
hand it was that already, since location of second stage 
loader had changed with lilo version upgrade.

Lilo 20 seems to have a QuickInstall (or QuickSomething 
other), it might be useful to use that, when available.

> Arto> ( Aside from possible lilo version problem [...]

I now think that all other problems might be explainable
by lilo version upgrade and not having run lilo at right 
moments during it, especially at end. It seems that
lilo now has some means to verify that lilo.conf
generates a bootable config, I have to examine it further.
 
> Arto> [...]
> [...] [about creating a new vs. appending old conf]
>   If one has a valid
>  lilo.conf, the dafault is to use it. 

Not that difficult to append, usually. But, yes, there 
are cases where it will not work. I usually do not use 
symbolic links in my lilo.conf, since changing things
outside the conf may change the meaning of the conf.
E.g. installing another kernel makes /vmlinuz point
to another place. A matter of taste only, but if I 
install another kernel and rerun old lilo.conf where
no links are used I get the same boot configuration
as before.

>   
> Arto> If lilo 20 is installed then no symlinks should be used or
> Arto> changed.
> 
>   Why?

Can't remember now, thought I had a reason. Should have 
spelled it out. I'll try to think one whe I'm home.

> Arto> Maybe that should be the case anyway, since the real
> Arto> lilo.config may reside in some other place in multi boot
> Arto> machines?
> 
>   On my multiboot machine, it does not. If people are changing
>  the Debian conventions, I think they should be capable of dealing
>  with the consequences.

If I have several root partitions, for different linux
installations, I usually have only one full lilo.conf,
but I might update kernels in other installations also, 
sometimes. On such partitions I might never had done 
the work to make a working lilo.conf for booting that
partition alone. I have 4 ide disks + ide cdrom & a 
couple of dosses. Haven't yet added NT, tho' (but will, 
in time).

> Arto> [...]
> [...] 
> Arto> If no links have been broken then not running lilo does not
> Arto> break anything, only new kernel is not yet used.
> 
>   Links are not broken, they are updated. 

Yeah, my mistake, sloppy with the words. Links are valid,
just not what was originally intended. This is probably
a question a certain view of multibooting anything else.
A matter of taste, no real harm either way.

> Arto> The generated lilo.config file was broken, since my partition,
> Arto> /dev/hda5, was a logical one, and lilo gave error for that. Is
> Arto> there a way of detecting the partition type? )
> 
>   I do not know. Anybody?

/usr/doc/lilo/examples/QuickInstall.gz for lilo 20 seems 
to test some partition related things with dd. I also seem
to remember now that all hdaX with X>4 are logical.

> Arto> [...]
> [...][about: do not upgrade kernel and lilo at the same time]

> Arto> Is it necessary or even possible to coordinate upgrades of
> Arto> kernel and bootloader so that their upgrades are not
> Arto> interleaved?
> 
>   This should be a question for the Deity list.

Are you on it

libc5

[Michael Meskes]

Is anyone working on a new release? I might take a look at it and do a
non-maintainer release unless someone else is willing.

Michael
-- 
Dr. Michael Meskes, Project-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


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

ports system (Re: Paranoia, "pristine sources", turnkeys, compiling, configuration)

[Fumitoshi UKAI]

From: Steve Dunham <[EMAIL PROTECTED]>
Subject: Re: Paranoia, "pristine sources", turnkeys, compiling, configuration
Date: 18 Dec 1997 17:19:58 -0500

> Ahh, but judging from recent posts to USENET, "ports" seems to be more
> of a system for "source package" management than package management.
> And our source packaging could use some revamping anyways. (I'd like
> multiple .tar.gz files and multiple diff files, for example.)
> 
> (As far as I can tell from USENET, their binary packages are similar
> to Slakware.)
> 
> If anyone decides to work on a better source packaging system for
> Debian, they probably should look at "ports" for some ideas.

It is not better source packaging system, but I introduce "ports"
like system for Debian.  [EMAIL PROTECTED], one of the Debian 
JP developers, has made a experimental package, debian-ports. 
You can get it from
 ftp://ftp.debian.or.jp/pub/linux/debian-jp/project-jp/experimental/
and sample "ports" file in its subdirectory 'ports/'.
However its documentation is Japanese only, sorry.

This package provides only Makefile for pmake like *BSD ports system.
To install "ports",
  get tar.gz of original package file and put it in /usr/src/ports/distfiles/.
  extract "ports" in /usr/src/ports/.
  run "pmake" in the extracted directory and you can get "deb" file.
  install its "deb" file.

If you are interested in it, you may use it as the start point.
-- 
Fumitoshi UKAI / Debian JP Project


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Orphaning ftnchek and ratfor77.

[Emilio Lopes]

Hi,

After some years in the Debian project, although not so active as I
wished, I do not have the time and the motivation anymore to maintain
my packages:

* ftnchek: A semantic checker for Fortran 77 programs.
   Good shape. Just needs to be upgraded to newest upstream
   version and recompiled for libc6.

* ratfor77: A ratfor preprocessor.
Needs some work. It still uses the *OLD* package format.
The original author is unknown and the person who was
maintaining this program doesn't have any interest on it
anymore. Too bad because my patches to integrate ratfor
with the GNU Fortran compiler (G77) where released in
g77 version 0.5.21. g77 should suggest ratfor77 when the
later gets fixed.
I have made some changes to ratfor77 that were not still
released. The next maintainer of this package (if any) can
contact me for these.

If you have some question about these, please send me a private
e-mail. I'm not subscribed to the Debian mailing lists anymore.

Also, whom should I write to, in order to have my account at
debian.org canceled? I wrote an e-mail to new-maintainer, hope this
was the right thing.

Emilio.

-- 
 [EMAIL PROTECTED]

 MULE is not the answer. MULE is the question and the answer is nil.


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: New package: makeports

[Elie Rosenblum]

And thus spake Turbo Fredriksson, on Fri, Dec 19, 1997 at 08:10:19AM +0100:
> On Fri, 19 Dec 1997, Elie Rosenblum wrote:
> > When you enter the directory for a package you can run make
> > with several options, to build .deb's, just build binaries, or just get
> > the latest version of the source packages.
> 
> Do you meen 'Debian-on-xxxBSD'? If that's the case, I'm working on a FreeBSD
> port right now, and anogher fellow here have some other intresting ports...

No, I mean a package to simulate *BSD's /usr/ports tree in Debian.

-- 
Elie Rosenblum <[EMAIL PROTECTED]>   That is not dead which can eternal lie,
 <[EMAIL PROTECTED]>  And with strange aeons even death may die.
Developer / Mercenary / System Administrator - _The Necromicon_


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

dselect features request

[hollen]

While I had been a devoted Slackware fan, trying Debian convinced me
that it is far superior a distribution.  However, in the process of
installing Debian 1.3.1 at least 15 times (several computers and
several different plans on how to install them all) it occurred to me
that two features in `dselect` would be WONDERFUL!!!

1)  Once all packages are selected, be able to dump the selections to
a file that could be later read in for subsequent identical
installations. 

2)  Once all packages are selected, don't skip packages that are
deselected, just ignore them.  Dselect for ftp install works this
way, why can't the disk based dselect as well?  It looks like much
time is spent "skipping" packages that do not need to be
installed. 

Thanks much for all the good work.  Debian 1.3.1 is a pleasure to work
with.  I have been using Linux for about 4 years now at home and at
work. 

dion

-- 
Dion Hollenbeck (619)597-7080x164 Email: [EMAIL PROTECTED]
 http://www.vigra.com/~hollen
Sr. Software Engineer - Vigra Div. of Visicom Labs  San Diego, California


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: dselect features request

[Rob Browning]

[EMAIL PROTECTED] writes:

> 1)  Once all packages are selected, be able to dump the selections to
> a file that could be later read in for subsequent identical
> installations. 

Try

  $ dpkg --get-selections > foobar
[ move foobar to another machine ]
  $ dpkg --set-selections < foobar

> 2)  Once all packages are selected, don't skip packages that are
> deselected, just ignore them.  Dselect for ftp install works this
> way, why can't the disk based dselect as well?  It looks like much
> time is spent "skipping" packages that do not need to be
> installed. 

I think that the dpkg-mountable package might eliminate this problem
if you use it as the access method, but I haven't tried it yet.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: dselect features request

[Chris Walker]

[EMAIL PROTECTED] writes:

>While I had been a devoted Slackware fan, trying Debian convinced me
>that it is far superior a distribution.  However, in the process of
>installing Debian 1.3.1 at least 15 times (several computers and
>several different plans on how to install them all) it occurred to me
>that two features in `dselect` would be WONDERFUL!!!
>
>1)  Once all packages are selected, be able to dump the selections to
>a file that could be later read in for subsequent identical
>installations. 

It would be nice to do this from dselect, but for the moment you can
quit dselect, and use:

dpkg --get-selections 

to get the list of selected packages, and

dpkg --set-selections to set them.

dpkg --help mentions these two.

I've not actually used these though. 

dpkg and dselect could do with better man pages, I agree. 

There is a project "Deity" to produce a dselect replacement, but I'm
not sure how near to release they are.

Chris





--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

potential mayhem with trial libc6 package and kernel-headers

[Rob Browning]

I recently installed the new libc6 experiental pacakges which also
wants you to install kernel-headers.  The problem is that
kernel-headers thinks it "owns" /usr/src/linux.  For users using the
kernel-package (or whatvever) to build their own kernels, this may be
a problem.  It was at least surprising.

In my case, I didn't even notice that kernel-headers added the
/usr/src/linux link, and since I normally don't ever have a
/usr/src/linux on my machine, I can just assume that it's safe to
untar a new kernel in /usr/src and then "mv linux linux-"
[1].  However, when the kernel-headers package is installed, this
means I'm unpacking my new kernel source into the kernel-header
package's directory -- not good.

Now I'm happy to just change my behavior, and unpack the kernels I
download somewhere else, but I think you're going to see some mayhem
when this pair of packages is released and other people doing
something similar suddenly have to treat /usr/src/linux as read only
without being warned.

[1] Why Linus has linux-.tar.gz unpack linux rather than
linux- has never made much sense to me.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: dselect features request

[Scott Ellis]

On Fri, 19 Dec 1997 [EMAIL PROTECTED] wrote:

> While I had been a devoted Slackware fan, trying Debian convinced me
> that it is far superior a distribution.  However, in the process of
> installing Debian 1.3.1 at least 15 times (several computers and
> several different plans on how to install them all) it occurred to me
> that two features in `dselect` would be WONDERFUL!!!
> 
> 1)  Once all packages are selected, be able to dump the selections to
> a file that could be later read in for subsequent identical
> installations. 

dpkg --get-selections
dpkg --set-selections

> 2)  Once all packages are selected, don't skip packages that are
> deselected, just ignore them.  Dselect for ftp install works this
> way, why can't the disk based dselect as well?  It looks like much
> time is spent "skipping" packages that do not need to be
> installed. 

Unfortunatly, that is because of the way dselect runs dpkg (dpkg -iGROBE),
which then goes through the directorys and checks every package.  I've
solved the problem by mounting my CD info ftpable space and using
dpkg-ftp.  The package dpkg-mountable will also provide a method that
doesn't do this.

-- 
Scott K. Ellis <[EMAIL PROTECTED]> http://www.gate.net/~storm/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: potential mayhem with trial libc6 package and kernel-headers

[Manoj Srivastava]

Hi,
>>"Rob" == Rob Browning <[EMAIL PROTECTED]> writes:

Rob> I recently installed the new libc6 experiental pacakges which
Rob> also wants you to install kernel-headers.  The problem is that
Rob> kernel-headers thinks it "owns" /usr/src/linux.  For users using
Rob> the kernel-package (or whatvever) to build their own kernels,
Rob> this may be a problem.  It was at least surprising.

All the products of kernel-package (and that includes
 kernel-source-xxx and kernel-headers-xxx) have always behaved as if
 they own /usr/src/linux ;-(. So this ain't new behaviour; things have
 always behaved that way. Just as /usr/local is not under vendor
 control, /usr/src/should be assumed to be, right?

I genrally unpack into /usr/src/local and mv things one level
 up, personally. 

Rob> In my case, I didn't even notice that kernel-headers added the
Rob> /usr/src/linux link, and since I normally don't ever have a
Rob> /usr/src/linux on my machine, I can just assume that it's safe to
Rob> untar a new kernel in /usr/src and then "mv linux
Rob> linux-" [1].  However, when the kernel-headers package
Rob> is installed, this means I'm unpacking my new kernel source into
Rob> the kernel-header package's directory -- not good.

Hmm, right.

Rob> Now I'm happy to just change my behavior, and unpack the kernels
Rob> I download somewhere else, but I think you're going to see some
Rob> mayhem when this pair of packages is released and other people
Rob> doing something similar suddenly have to treat /usr/src/linux as
Rob> read only without being warned.

What do you sugggest, modulo maintaining backward
 compatibility to people who have old kernel-source packages
 installed? 

manoj
-- 
 "No man steps in the same river twice, for it's not the same river,
 and he's not the same man." Heraclitus
Manoj Srivastava  <[EMAIL PROTECTED]> 
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: potential mayhem with trial libc6 package and kernel-headers

[Rob Browning]

Manoj Srivastava <[EMAIL PROTECTED]> writes:

>   I genrally unpack into /usr/src/local and mv things one level
>  up, personally. 

That seems reasonable.  I guess I had just sort of always treated
/usr/src/ as if it was local, even though I probably shouldn't have.

> Rob> Now I'm happy to just change my behavior, and unpack the kernels
> Rob> I download somewhere else, but I think you're going to see some
> Rob> mayhem when this pair of packages is released and other people
> Rob> doing something similar suddenly have to treat /usr/src/linux as
> Rob> read only without being warned.
> 
>   What do you sugggest, modulo maintaining backward
>  compatibility to people who have old kernel-source packages
>  installed? 

I don't really have a good suggestion, but I think that this should
be somehow *widely* advertised with the new libc6 arrangement.  I
don't know if I'd go so far as an actual pause in the postinst, but
this could be a fairly serious problem. 

People who weren't using kernel-headers before (because they never
needed it), may be in for a shock.

-- 
Rob Browning <[EMAIL PROTECTED]>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94  53 2B 97 F5 D6 4E 39 30


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: dselect features request

[Jeff Sheinberg]

> From: Rob Browning <[EMAIL PROTECTED]>
> Date: 19 Dec 1997 10:51:29 -0600
[snip]
> Try
> 
>   $ dpkg --get-selections > foobar
> [ move foobar to another machine ]
>   $ dpkg --set-selections < foobar

Yes, but what about standard packages that I have de-selected?

39 root ~ # dpkg -s elm
Package: elm
Status: purge ok not-installed
Priority: standard
Section: mail

40 root ~ # dpkg -l elm
Desired=Unknown/Install/Remove/Purge
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ NameVersionDescription
+++-===-==-
pn  elm  (no description available)
41 root ~ # dpkg --get-selections | grep elm
42 root ~ # echo $?
1

-- 
Jeff Sheinberg  <[EMAIL PROTECTED]>


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .

Re: potential mayhem with trial libc6 package and kernel-headers

[Bart Schuller]

On Dec 19, Rob Browning wrote
> People who weren't using kernel-headers before (because they never
> needed it), may be in for a shock.

Particularly if they happened to have a fully unpacked and configured
kernel source tree in /usr/src/linux .

* Poof *

It's only a slight inconvenience, but I'd rather have known beforehand,
so that I might have saved my .config

-- 
Bart Schuller  [EMAIL PROTECTED] At Lunalabs, where the
Lunatech Research  http://www.lunatech.com/  future is made today..
Partner of The Perl Institute  http://www.perl.org/Linux http://www.li.org/


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .