Source package format - a simple proposal

[Ian Jackson]

While this discussion was going on, I posted a list of requirements
for our source format.  I think that there is a very simple way we can
support most of these requirements without many problems.  Firstly,
the requirements (summarised):

 1. Single file, unpacked using 1 command to make debianised src.
 2. Single file, unpacked using 1 command to make upstream src.
 3. Consistent naming schemes for unpack directories.
 4. Patches for different arch's [1].
 5. Can be manipulated on non-Debian systems using standard tools.
 6a. No unnecessary up/down-loading by maintainers.
 6b. No unnecessary disk space usage on archive sites.
 7. No execution of parts of source package when unpacking.
 8. Sensible way to rebuild source from unpacked tree(s).

I propose that the source package for `foo', version 1.2 revision 5,
would be a gzipped tarfile with the following structure:

  foo-1.2-5.debian-diff
  foo-1.2.orig/foo.c
  /foo.h
  &c

The directory foo-1.2.orig would contain the original source package's
files; the only changes would be to make the directory name consistent
(and to possibly to make the permissions in the source tree sensible
if they aren't in the upstream source).

We can easily provide a script (the dpkg package would be the right
place for it) that turns this into
   foo-1.2/debian.*
  /foo.c
  &c
   foo-1.2.orig/foo.c
   &c
and another that turns that back into a source package without
disturbing the directories.

For a source package that comes as more than one file (tarfile or
otherwise) we can provide a debian.* script in the debianised version
of the source that takes the files downloaded from the package's FTP
site and turns them into the directory structure in our source
package.

A user who gets the .tar.gz and just unpacks it will see the obvious
thing.  They can rename foo*.orig to foo* and apply the diff manually
if that's all they want to do.

This meets requirements 1, 2, 3, 5, 7, 8.

Maintainers who change only the control file or something still have
to upload a new source tree, unfortunately, but we can if we like
avoid this by having them submit only a new diff and reconstructing
the .tar.gz on the distribution site using a simple script.  That
supports 6a and 6b.

[1] The scheme is easily extended to support item 4 (per architecture
patches), but I still think this is a bad idea.

Ian.

Re: Returned mail (fwd)

[Ian Jackson]

Karl Ferguson writes ("Returned mail (fwd)"):
> Forwarded message:
> > No matching or similar name in the people
> > database for 'jasonbramsden'.
> 
> Can someone take this guy off the debian-changes list please?  He's not 
> getting the email.

I've mailed various postmasters, without any response.  I phoned the
Technical Contact for attgis as listed in whois, and got an
answerphone saying they would be away until Tuesday (tomorrow, that
is).

I'll give it a few days and then prod them again.

Let me know if the problem clears up :-).

Ian.

Bug#1912: Perl (a.out) dbmopen causes Perl to exit silently with code 0

[Ian Jackson]

Package: perl
Version: 5.001-6

-chiark:~/junk> ls -al u.db*
/bin/ls: u.db*: No such file or directory
-chiark:~/junk> cat t.pl
warn 1; dbmopen(Z,"u.db",0600); warn 2;
-chiark:~/junk> perl t.pl
1 at t.pl line 1.
-chiark:~/junk> echo $?
0
-chiark:~/junk> cat t2.pl
warn 1; dbmopen(%Z,"u.db",0600); warn 2;
-chiark:~/junk> perl t2.pl
1 at t2.pl line 1.
-chiark:~/junk> echo $?
0
-chiark:~/junk> ls -al u.db*
/bin/ls: u.db*: No such file or directory
-chiark:~/junk>

I haven't tried ELF because my ELF libc isn't in /lib yet.

Ian.

Bug#1911: Perl postinst is unecessarily slow

[Ian Jackson]

Package: perl
Version: 5.001-6 (a.out)

While running `top' to see how the Perl postinst was getting on I saw:

root  8507 11.4  0.8  105  160 v02 S01:57   0:03 find 
/usr/lib/perl5/i486-linux -type f -exec chmod 644 {} ;

Two questions come to mind:

1. Can't you arrange to create them with the right permissions to
start with ?

2. Why not use xargs ?  That would be _much_ faster.  Use find -print0
combined with xargs -0 if it is important that files with newlines in
their names are treated correctly.

Ian.

Re: bogo-1.2-1 released

[Ian Jackson]

Bill Mitchell writes ("Re: bogo-1.2-1 released"):
> From a user/installer point of view, it seems unhelpful to combine them.
> It sounds like this would hide theinfo for each small package which would
> be available as Description/Extended description if each was packaged
> separately.

I disagree.  I think that with something like this it would be better
to say in the description that the package was a set of miscellaneous
utilities in the application area X and then give a list in the next
paragraph.

Packing these very small program separately doesn't buy us very much -
they're so small that the dpkg per-package overhead is nearly as much
as the files inside them.  People probably won't object to installing
a few tens of K of scripts to get the one 3K script they want.

>Also, presuming that it's possible to identify one of the
> included items in the digest package as desired, it sounds like this
> would make it necessary to all the undesired items in the digest
> package to get one which is desired.

Yes, but they're small and inoffensive, so it doesn't matter.

> > I know they're distributed separately as upstream source, but having
> > many of these small packages is really going to clutter up the
> > installation procedure.
> 
> That's certainly true, though.  More clutter in dselect for the user
> to sort through, more packages to be added to the long list which
> dselect churns through every time it's asked to install a package.
> It's a problem, but this doesn''t sound like an effective solution.

I'm confused.  Here you're making my point for me.

If this is more of your file-granularity stuff I don't want to hear
it, I'm afraid.

Ian.

Re: [miguel@nuclecu.unam.mx: New Linux/SPARC snapshot] (fwd)

[Matthew Bailey]

On Tue, 28 Nov 1995, Ian Jackson wrote:

> 
> I didn't realise the libc had been hacked so far from the GNU one
> (which has a sophisticated built-time configuration mechanism).
> 
> Are the two libcs being maintained (upstream) separately ?  If so they
> should probably have different source packages.
> 
Currently the only LIBC is  SUN LIBC which is running in binary compat mode.
The GNU LIBC is being ported by the sparclinux people as fast as they 
can. They have just made "userland" in the last two weeks

But they have SCSI/NFS/EXT2FS Running already so they are not all that 
far off.
--
Matthew S. Bailey
107 Emmons Hall
Central Michigan University
Mt. Pleasant, MI 48858

[EMAIL PROTECTED]

... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.  Any
resemblance between the above and my own views is non-deterministic.
The question of the existence of views in the absence of anyone to hold
them is left as an exercise for the reader.  The question of the
existence of the reader is left as an exercise for the second god
coefficient.  (A discussion of non-orthogonal, non-integral polytheism
is beyond the scope of this article.)

Bug#1906: inittab(5) error

[Ian Jackson]

David Scowcroft writes ("Bug#1906: inittab(5) error"):
>   (1) Update inittab(5), then hack the power daemon to write to
>   /var/log/powerstatus rather than /etc/powerstatus

Surely this file ought to be in /var/run ?  It's more like a pid file;
it's certainly not a log file.

*sigh*

Ian.

Re: Multi-Platform Support

[Ian Jackson]

(This discussion moved to debian-devel, because I think that's where
it belongs.)

brian white writes ("Multi-Platform Support "):
> Since it seems that Debian will soon start supporting other platforms,
> should we add another level to the directory tree to support this?  I'd
> reccommend putting it between "debian" and "debian-" since it must
> also encompass the "non-free" tree which sits outside of "debian-".
> 
> eg:  /debian/i386/debian-1.0  and  /debian/sparc/debian-1.0

For most (nearly all?) packages the source will be the same.

How about having binary directories named after the architecture ?

Ian.

Re: [miguel@nuclecu.unam.mx: New Linux/SPARC snapshot] (fwd)

[Ian Jackson]

Matthew Bailey writes ("Re: [EMAIL PROTECTED]: New Linux/SPARC snapshot] 
(fwd)"):
> LIBC will cause a major concern here considering the port is HUGE to make 
> it all work. The kernel Source tree is not a big deal since it can 
> configure most of itself.

I didn't realise the libc had been hacked so far from the GNU one
(which has a sophisticated built-time configuration mechanism).

Are the two libcs being maintained (upstream) separately ?  If so they
should probably have different source packages.

Ian.

Movement :/ OK OK :)

[Matthew Bailey]

Over the next weekish or so I will be rebuilding the ftp server.
The amount of downtime should be minimal since I will use my "PERSONAL" 
machine while I rebuild the FTP/WEB server so that I can forget about it 
for the next 6 months

I will be moving WWW from the apache server over Netscape's NetSite 
server during this move. This will allow for a few nice features that I 
didn't have before.

I will not be bringing ftp.debian.org OFFLINE until I am ready to make 
the move. I will however be shadowing ftp.debian.org on ftp.cps.cmich.edu 
while I am making this happen. If you have problems with ftp.debian.org 
try ftp.cps.cmich.edu this will hopefully make things go a bit smoother.

Ian M. : If you want to make sure time stamps are preserved PLEASE PLEASE 
get a stamps.tar and place it somewhere :) I have no clue how you are 
able to recontruct these so if you would be so kind as to keep a copy.

I am also under the impression that uploads are rather inmaterial as far 
as timestamps are concerned. 

By default mirror (from src.doc.ic.ac.uk) just updates the time stamps 
and does not re-retrieve the files...

So Starting sometime tommorow I will be at play..
Thanks

--
Matthew S. Bailey
107 Emmons Hall
Central Michigan University
Mt. Pleasant, MI 48858

[EMAIL PROTECTED]

... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.  Any
resemblance between the above and my own views is non-deterministic.
The question of the existence of views in the absence of anyone to hold
them is left as an exercise for the reader.  The question of the
existence of the reader is left as an exercise for the second god
coefficient.  (A discussion of non-orthogonal, non-integral polytheism
is beyond the scope of this article.)

Bug#1764: bin/kill segfaults

[Austin Donnelly]

On Wed, 25 Oct 1995 15:40:09 +1000 (EST), Herbert Xu
<[EMAIL PROTECTED]> wrote:

>Package: bsdutils
>Version: 1.3-1
>
>It is trivial to make /bin/kill segfault:
>$ /bin/kill -l
>INT QUIT ILL TRAP ABRT UNUSED FPE KILL USR1 SEGV USR2 PIPE ALRM TERM STKFLT 
>CHLD
>Segmentation fault (core dumped)
>
>The appended patch fixes the bug.  I suspect the person who wrote the code
>has had some bad memories about Pascal :)
>
>PS NSIG is the largest valid signal number + 1.
[...patch snipped...]

The appended patch was very helpful, thanks.

A new kill, hopefully with the bugs fixed, is in bsdutuils-1.4-1,
which I am about to upload to the uk upload site.


Austin

Re: convenience script for building a.out packages

[Scott Blachowicz]

Ian Jackson <[EMAIL PROTECTED]> wrote:

> I agree.  But, now you see that we have a script called /usr/bin/aout
> and a potential directory called /usr/bin/aout.  Hence my suggestion
> that it ought to be called something else.  with-aout perhaps.

[For what it's worth... :-))]

Actually, I would argue that the _directory_ be someWHERE else.  Just a
pet peave of mine, but I hate it when people stick non-"bin"s in bin/
directories.  Some of the $PATH lookup code in places will stumble upon a
directory in $PATH and try to execute it.  You could argue that the code
that does that is wrong, but it just rubs me the wrong way, aesthetically,
to have subdirs of bin/ directories.

Scott BlachowiczPh: 206/283-8802x240StatSci, a div of MathSoft, Inc.
1700 Westlake Ave N #500
[EMAIL PROTECTED]   Seattle, WA USA   98109
[EMAIL PROTECTED]

Bug#1513: bin/kill segfaults if invoked instead of killall

[Austin Donnelly]

>Package: bsdutils
>Version: 1.3-1
>
>chiark:~> /bin/kill -HUP syslogd
>Segmentation fault (core dumped)
>chiark:~>
[...core dump snipped...]

There were a number of bugs in /bin/kill, most due to the poor code
quality making loops difficult to decipher.

A large number of signals were missing from the signal list, and a
variety of out-by-one errors were liberally sprinkled around :)

This is fixed in bsdutils-1.4-1, out now.

Austin

Bug#1902: manpage for wtmp wrong

[Raul Miller]

Martin Schulze:
   So the bugreport can be closed, right?

http://www.eg.bucknell.edu/~quinlan/fsstnd/1.2/fsstnd-5.6.html";>
No, wtmp goes in /var/log.


--
Raul

Re: [miguel@nuclecu.unam.mx: New Linux/SPARC snapshot] (fwd)

[Ian Jackson]

Mail Archive writes:
> You know this is where pristine(SP?) sources would be nice that way we 
> can apply debian-platform-specific patches to0 the source tree that way 
> we only hve to have a so-called-distfiles-directory that is NON platform 
> specific. This will make porting MUCH easier...

I disagree.  IMO there should be no platform-specific patches.

In the rare situations where the source code can't be written
to work correctly on all platforms then debian.rules script should
handle giving the compiler the right -D flags or whatever.

If we provide a mechanism for platform-specific source code trees
then:
* We can't see and edit all of the source code to a package at once.
* Patches will get put into the wrong diff.
* We lose focus on portability issues.
* We have to think of a sensible way to allow our diff-generation
  scripts to decide whether an edit we're making belongs in the
  platform-specific of the generic diff.

In this day and age there are very few programs that need to have
different source code to compile on different CPUs.

Lest anyone think that I speak as someone who doesn't have to deal
with this problem, I'd like to point out that I'm the maintainer of
PGP, which has assembler routines for some architectures.

Ian.

Bug#1908: Top and tabs

[brian (b.c.) white]

Package: procps
Version: 0.97-4
Program: top

It seems that when "top" displays parameter lists, it does not properly
truncate the list to fit on one line if there are tab characters
embedded within the parameters.

It should be a simple matter to parse this string and convert '\t' to ' '.

Brian
 ( [EMAIL PROTECTED] )

---
In theory, theory and practice are the same.  In practice, they're not.

Re: bogo-1.2-1 released

[Bill Mitchell]

Ian Jackson <[EMAIL PROTECTED]> said:

> Karl Ferguson writes ("bogo-1.2-1 released"):
> > Well, it's a tough job, but someone's got to be low enough to do some
> > small Debian packages :-)  One day when I feel more confident I'll do
> > some real packages 
> 
> Does anyone else think it would be a good idea to combine some of
> these very small packages together into a somewhat larger one ?

>From a user/installer point of view, it seems unhelpful to combine them.
It sounds like this would hide theinfo for each small package which would
be available as Description/Extended description if each was packaged
separately.   Also, presuming that it's possible to identify one of the
included items in the digest package as desired, it sounds like this
would make it necessary to all the undesired items in the digest
package to get one which is desired.

> I know they're distributed separately as upstream source, but having
> many of these small packages is really going to clutter up the
> installation procedure.

That's certainly true, though.  More clutter in dselect for the user
to sort through, more packages to be added to the long list which
dselect churns through every time it's asked to install a package.
It's a problem, but this doesn''t sound like an effective solution.

Re: [miguel@nuclecu.unam.mx: New Linux/SPARC snapshot] (fwd)

[Matthew Bailey]

On Mon, 27 Nov 1995, Ian Jackson wrote:

> 
> In this day and age there are very few programs that need to have
> different source code to compile on different CPUs.
> 
> Lest anyone think that I speak as someone who doesn't have to deal
> with this problem, I'd like to point out that I'm the maintainer of
> PGP, which has assembler routines for some architectures.
> 
LIBC will cause a major concern here considering the port is HUGE to make 
it all work. The kernel Source tree is not a big deal since it can 
configure most of itself.



-- Matthew S. Bailey
107 Emmons Hall
Central Michigan University
Mt. Pleasant, MI 48858

[EMAIL PROTECTED]

... Any resemblance between the above views and those of my employer,
my terminal, or the view out my window are purely coincidental.  Any
resemblance between the above and my own views is non-deterministic.
The question of the existence of views in the absence of anyone to hold
them is left as an exercise for the reader.  The question of the
existence of the reader is left as an exercise for the second god
coefficient.  (A discussion of non-orthogonal, non-integral polytheism
is beyond the scope of this article.)

Bug#1902: manpage for wtmp wrong

[Martin Schulze]

Hallo Andrew Howell!

}> Package: manpages
}> Version: 1.8-1

}> (I'm being picky, but...)
}> According to the Contents file, wtmp is located in /etc - which it is.  
However,
}> the wtmp manpage says it's in /var/adm.  I'd say this would be a manpages
}> problem rather than a base problem...  Oh while I'm at it, I'm not sure but 
it
}> could be the same error for the utmp.
}
}/var/adm is linked to /var/log, wtmp is in /var/adm.
}utmp is in /var/run
}
}wtmp is not in /etc on my system

So the bugreport can be closed, right?

Regards,

Joey

--
   / Martin Schulze  *  [EMAIL PROTECTED]  *  26129 Oldenburg /
  / +49-441-777884  *  Login&Passwd: nuucp  *  Index: ~/ls-lR.gz  /
 / The MS-DOS filesystem is nice for removable media /
/ -- H. Peter Anvin /

Bug#1906: inittab(5) error

[David Scowcroft]

Package: sysvinit
Version: 2.57b

Debian:  0.93
Kernel:  1.2.13
libc:4.6.27

The man page for inittab(5) specifies that init looks at the file
/etc/powerstatus to determine why init received a SIGPWR (either FAIL if
a UPS signals a power outage or OK if a UPS signals that power is back).
Hence, daemons that monitor a UPS write FAIL or OK to /etc/powerstatus
before sending init a SIGPWR.

In fact, sysvinit (2.57b) looks at the file /var/log/powerstatus to
determine the nature of a SIGPWR.

Therefore, the following things could be done to "fix" this.

EITHER

(1) Update inittab(5), then hack the power daemon to write to
/var/log/powerstatus rather than /etc/powerstatus

OR

(2) Hack sysvinit to look at /etc/powerstatus rather than
/var/log/powerstatus (edit paths.h in the sysvinit source)
and then recompile init.

Option (1) is probably the easier of the two.

Cheers, David.

Re: bogo-1.2-1 released

[Karl Ferguson]

> Karl Ferguson writes ("bogo-1.2-1 released"):
> > Well, it's a tough job, but someone's got to be low enough to do some
> > small Debian packages :-)  One day when I feel more confident I'll do
> > some real packages 
> 
> Does anyone else think it would be a good idea to combine some of
> these very small packages together into a somewhat larger one ?
> 
> I know they're distributed separately as upstream source, but having
> many of these small packages is really going to clutter up the
> installation procedure.
> 
> Ian.

I had the same thoughts - perhaps the miscutils package or something like
that?  A 3k package is pretty small :)

...Karl

--
 
 | PO Box 828   Office: (09)316-3036 Fax: (09)381-3909
 |OWER INTERNET SERVICES   Canning Bridge   After Hours:  015-779-828
   WA, 6153 Sales Support: [EMAIL PROTECTED]
Internet Service Providers   
 and Networking Solutions   

Bug#1910: minor bugs in X, perl, dlltools

[Juhana K Kouhia]

Package: X, perl, dlltools, mt, tar
Version: ?, 5.001-5, 2.17-3, ?, ?


I have debian 0.93R6 (stable), all installed last week to empty disk.

About X: I change the link
  /usr/X11R6/bin/X -> /etc/X11/X
to
  X -> XF86_S3   (in /usr/X11R6/bin/)
since /etc/X11/X no exists (still not there).


About perl-installing: installation gave error messages about missing
/usr/local/include directory. Following helped:
  mkdir /usr/local/include
BTW. /usr/local/include misses man/man*, man/cat*, src/ directories too.


About dlltools: I had to make following link because the compilation
of Dore (graphics software) needs '/usr/bin/jump':
  ln -s /usr/bin/jumpas /usr/bin/jump


About 'mt': 'mt' manual page does have two 'eof' commands listed.
And 'eom' is missing entirely even from the program; 'eom' is
mentioned in ftape documents.
BTW. missing 'eom' is not a big thing, since there is 'fsf'.


About 'tar': tar manual page is missing


Juhana Kouhia

Re: bogo-1.2-1 released

[Peter Tobias]

Ian Jackson wrote:
> Karl Ferguson writes ("bogo-1.2-1 released"):
> > Well, it's a tough job, but someone's got to be low enough to do some
> > small Debian packages :-)  One day when I feel more confident I'll do
> > some real packages 
> 
> Does anyone else think it would be a good idea to combine some of
> these very small packages together into a somewhat larger one ?

Yes, that's a good idea. There could be separate packages for system
tools (memtest, bogomips, ...), for console tools (open, vlock, ...)
and for other tools.


Peter

-- 
 Peter TobiasEMail:
 Fachhochschule Ostfriesland [EMAIL PROTECTED]
 Fachbereich Elektrotechnik und Informatik   [EMAIL PROTECTED]
 Constantiaplatz 4, 26723 Emden, Germany

Bug#1907: program ld got fatal signal 6

[Dirk . Eddelbuettel]

  Juhana K Kouhia writes:
  Juhana> /usr/bin/gcc -c -g -O -I. -I.. -I.././tools -I.././libtiff
  Juhana> .././tools/gif2tiff.c
  Juhana> /usr/bin/gcc -o gif2tiff -g -O -I. -I.. -I.././tools -I.././libtiff
  Juhana> gif2tiff.o ../libtiff/libtiff.a -lm
  Juhana> ld: Output file requires shared library `libc.so.4' gcc: Internal
  Juhana> compiler error: program ld got fatal signal 6 make[1]: ***
  Juhana> [gif2tiff] Error 1

If you compile and link with '-g' for debugging (or '-pg' for profiling'),
you now need to add '-static' at the link stage. This is a new feature that
isn't very well documented AFAIK.

--
[EMAIL PROTECTED]  http://qed.econ.queensu.ca/~edd

Re: bogo-1.2-1 released

[Karl Ferguson]

> > As I said in my reply too, I think it'll be a good idea as well.  I'll make
> > a systool package and encorporate the utilities I've just released in it.
> > Sound good?
> 
> Yes :-).
> 
> 
> Peter

Ok, that's settled then.

IanM: Could you delete the procinfo, memtest and bogo packages before moving
them into the distribution please?  I'll upload one combined package with
all 3.

In the future when I find some other small utilities I'll also release them
in the sysutil package.

...Karl

--
 
 | PO Box 828   Office: (09)316-3036 Fax: (09)381-3909
 |OWER INTERNET SERVICES   Canning Bridge   After Hours:  015-779-828
   WA, 6153 Sales Support: [EMAIL PROTECTED]
Internet Service Providers   
 and Networking Solutions   

Re: bogo-1.2-1 released

[Karl Ferguson]

> > Does anyone else think it would be a good idea to combine some of
> > these very small packages together into a somewhat larger one ?
> 
> Yes, that's a good idea. There could be separate packages for system
> tools (memtest, bogomips, ...), for console tools (open, vlock, ...)
> and for other tools.

As I said in my reply too, I think it'll be a good idea as well.  I'll make
a systool package and encorporate the utilities I've just released in it.
Sound good?

Regs

...Karl

--
 
 | PO Box 828   Office: (09)316-3036 Fax: (09)381-3909
 |OWER INTERNET SERVICES   Canning Bridge   After Hours:  015-779-828
   WA, 6153 Sales Support: [EMAIL PROTECTED]
Internet Service Providers   
 and Networking Solutions   

Bug#1904: dpkg-name

[Erick Branderhorst]

>
> Package: dpkgname
> Version: 0.4-0
>
> In the man page, there is no mention of what you are renaming Debian
> packages /from/.  I suspect you are renaming from ms-dos filenames, but
> the documentation should specify.
>
dpkg-name might move into dpkg package, if so the doc will be specified.
> Thanks,
> --
>   David H. Silber [EMAIL PROTECTED] Project: Debian GNU/Linux 
> (dbackup)
>    Wanted:  Spare time.
>
>Programmer for hire.
>
>


--
Erick [EMAIL PROTECTED] +31-10-4635142
Department of General Surgery (Intensive Care) University Hospital Rotterdam NL

Bug#1907: program ld got fatal signal 6

[Juhana K Kouhia]

Package: gcc
Version: 2.6.3-4

I have debian 0.93.R6 installed to empty disk at last week.
In tiff-library (v3.4beta018) compilation I got following error.
Previously I had debian 0.93R5 and tiff-library compiled on it ok.

 ./configure
 make

/usr/bin/gcc -c -g -O -I. -I.. -I.././tools -I.././libtiff .././tools/gif2tiff.c
/usr/bin/gcc -o gif2tiff -g -O -I. -I.. -I.././tools -I.././libtiff gif2tiff.o 
../libtiff/libtiff.a-lm
ld: Output file requires shared library `libc.so.4'
gcc: Internal compiler error: program ld got fatal signal 6
make[1]: *** [gif2tiff] Error 1

# dir /lib/libc*
lrwxrwxrwx   1 root root   14 Nov 25 01:11 /lib/libc.so.4 -> 
libc.so.4.6.27
-rwxr-xr-x   1 root root   634880 Sep 13 05:17 /lib/libc.so.4.6.27

Juhana Kouhia

Bug#1905: netstd

[David H. Silber]

Package: netstd
Version: 1.21-1

Two problems:

The first is really my own fault, but for the benefit of those of us who get
around to upgrading our systems at 23:45 could you insert some kind of reminder
or warning message to the effect that installing netstd will require a short-
term shutdown of the networking services.

The usage message in /etc/init.d/netstd_nfs is incorrect.  Someone has added
a reload option.  What is this supposed to do, anyway?

Thanks,
--
  David H. Silber [EMAIL PROTECTED] Project: Debian GNU/Linux (dbackup)
   Wanted:  Spare time.

 Programmer for hire.

Bug#1909: autoconf.h missing

[Juhana K Kouhia]

Package: autoconf, ftape
Version: 2.4-1, 2.03-1

I have debian 0.93R6 (stable) installed to empty disk at last week.

When compiling ftape I got error messages about missing linux/autoconf.h.
I have package 'source', not 'includes' if that matters.
Following did help:

   ln -s /usr/lib/autoconf/acconfig.h /usr/include/linux/autoconf.h

Ftape had another failure which caused me to add
  #define NR_FTAPE_BUFFERS 3
to the beginning of the file ftape-rw.h

Juhana Kouhia

Bug#1904: dpkg-name

[David H. Silber]

Package: dpkgname
Version: 0.4-0

In the man page, there is no mention of what you are renaming Debian
packages /from/.  I suspect you are renaming from ms-dos filenames, but
the documentation should specify.

Thanks,
--
  David H. Silber [EMAIL PROTECTED] Project: Debian GNU/Linux (dbackup)
   Wanted:  Spare time.

 Programmer for hire.

Re: bogo-1.2-1 released

[Ian Jackson]

Karl Ferguson writes ("bogo-1.2-1 released"):
> Well, it's a tough job, but someone's got to be low enough to do some
> small Debian packages :-)  One day when I feel more confident I'll do
> some real packages 

Does anyone else think it would be a good idea to combine some of
these very small packages together into a somewhat larger one ?

I know they're distributed separately as upstream source, but having
many of these small packages is really going to clutter up the
installation procedure.

Ian.

Re: inline-math-1.7 (fwd)

[Andrew D. Fernandes]

> Version 1.7 of inline-math has been uploaded to sunsite:
> /pub/Linux/libs/inline-math-1.7.tar.gz.

I think that these would be a *great* thing to include in debian. Having 
a good, solid linux release (debian) with *good* math libs will encourage 
commercial developers to build mathematical software for linux.

-Andrew. <[EMAIL PROTECTED]>

Bug#1896: fsck won't go because of elf?

[Andrew D. Fernandes]

done

Bug#1770: xntp dumps core with kernel 1.3.35

[Andrew Howell]

Austin Donnelly writes:
> Package: xntp
> Version: 3.4x-1
>
> The 'struct timex' structure has changed in the newser 1.3.x kernels
> (for x approx > 28 or so, I'm told).
>
> This means that xntpd binaries compiled agains old kernels dumps core
> on startup.
>
> I'm told that version 3.4t has support for the latest linux, but I
> haven't tried it.

I haven't been able to find 3.4t, it's not on louie.udel.edu. If it does
exist I'd be happy for someone to point me to it :)

>
> Also, there is the problem that there would need to be _2_ xntp
> packages, one for old kernels, one for new kernels.  Eugh!!
>
> Can anyone think of a better idea ?

I've fixed this core dumping problem in xntp-3.4x-2. It seems to run fine
under 1.2.x kernels as well.

Andrew

--
Dehydration - 34%, Recollection of previous evening - 2%, embarrassment
factor - 91%.  Advise repair schedule:- off line for 36 hours, re-boot
startup disk, and replace head - wow, what a night!
-- Kryten in Red Dwarf `The Last Day'

Andrew Howell  [EMAIL PROTECTED]
Perth, Western Australia  [EMAIL PROTECTED]

Bug#1656: etc/ntp.drift should be somewhere in /var (FSSTND)

[Andrew Howell]

Marek Michalkiewicz writes:
>
> Andrew Howell:
> > There is already a /var/log/ntpstats directory, but I don't think it's
> > really the right place for it, it's not really a log file. Unless someone
> > really objects I think I'll just leave it in /etc
>
> According to fsstnd-1.2, "application state information" (I think ntp.drift
> is such a file) belongs in /var/lib.  So I suggest /var/lib/ntp/ntp.drift
> or something like this.  I don't really object to /etc but we are supposed
> to conform to fsstnd...

Okay I've done this in xntp-3.4x-2

Andrew

--
Dehydration - 34%, Recollection of previous evening - 2%, embarrassment
factor - 91%.  Advise repair schedule:- off line for 36 hours, re-boot
startup disk, and replace head - wow, what a night!
-- Kryten in Red Dwarf `The Last Day'

Andrew Howell  [EMAIL PROTECTED]
Perth, Western Australia  [EMAIL PROTECTED]