Bug#1928: usr/lib/cvs incomplete

[Bill Mitchell]

I think I figured a way to get the /usr/lib/cvs/contrib stuff
installed as intended by the upstream maintainer without fiddling
with all the contrib stuff in the package file by file to separate
the wheat from the chaff.

I'm closing this bug and will be uploading a new cvs package tonight.
Please let me know if there are still problems.

[EMAIL PROTECTED] (Bill Mitchell)

Bug#1927: no /usr/include/linux/errno.h

[aij!jlarkin]

> >Package: libc5-dev
> >Version: 5.2.9-2
>
> >The headder file /usr/include/errno.h has this line:
> >#include
> >but there is no 'linux' directory.
>
> Egads!  There should be a symlink, if memory serves, from
> /usr/include/linux to /usr/src/linux/include/linux.  Go ahead and
> create that symlink with the command
>  ln -s /usr/src/linux/include/linux /usr/include/linux
> if you've got 'source' installed; I don't know what the procedure is if
> you've got 'includes' installed.
>
> Meanwhile, I'll check up on libc5, et al and see what the problem is.
> (I'm missing the same link, and I'm *sure* that's recent!)

Well, I just used dpkg to re-install libc5-dev and libc5 and the symlink is
now there.  I had just updated to elf from a.out (last night) in one dselect
session.  I don't know why the sym-link didn't stay around I don't
suppose any packages would have the authority to remove symlinks? I
did just remove the old a.out package; is there some way that dpkg
would have removed the symlink after libc5-dev had created it?  Strange.

--
- John Larkin
- [EMAIL PROTECTED]
- http://aij.st.hmc.edu/~jlarkin

Re: Bug#1911: Perl postinst is unecessarily slow

[Darren/Torin/Who Ever...]

Ian Jackson spoke onto the world and said:
>[EMAIL PROTECTED] writes ("Re: Bug#1911: Perl postinst is unecessarily slow"):
>> If it's acceptable that all the files will have the same permissions as
>> the files under /usr/include and /usr/local/include, then there is no
>> problems.
>
>Huh ?  Perl should install its files in /usr, not /usr/local, surely ?
>Those files should be 644 root.root (directories 755 root.root).  This
>applies to the files in /usr/include too.  /usr/local/include is 664
>(2775) root.staff, deliberately.

Oops.  I didn't type clearly enough.  postinst grabs all the files in
/usr/include/**/*.h and /usr/local/include/**/*.h and turns them into
*.ph files under /usr/lib/perl5/i486-linux/5.002.  If the *.h files in
the original include directories are the correct permissions, then the
*.ph files will be correct also.

Darren
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C and Perl programmer and tutor. @

Re: Bug#1916: perl: wrong entries in Config.pm

[Darren/Torin/Who Ever...]

Manoj Srivastava spoke onto the world and said:
>   You see, there are a number of add-ons (or extensions) to Perl
> that are very useful, (the perlTk stuff, the CGI modules, and libwww
> come to mind), and these use MakeMaker and Config.pm to determine
> where to put the files on install.  
>
>   If such an extension is acquired by a user of the system, then
> things should point to /usr/local, (since users should not normally
> add things to /usr/{bin,lib}, and we should not set it up in a manner
> that such is the default).  

I've changed the install* to /usr/ but it wouldn't be that difficult.
I'd also need to change the site directories but again that wouldn't be
difficult.  The /usr/lib/perl5/site_perl is where perl currently wants
to put stuff.  Shall I change that to /usr/local/lib/perl5/site_perl or
just /usr/local/lib/perl5?

Darren
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C and Perl programmer and tutor. @

Bug#1915: Perl doesn't like the number 0

[Darren/Torin/Who Ever...]

Peter Tobias spoke unto the world and said:
>Darren/Torin/Who Ever... wrote:
>> I've not been able to duplicate this anywhere using a.out under linux or
>> any other machines that I have access to.
>
>Strange, I get the same results on every linux system where I installed
>the perl-5.002-1.deb.aout package.

If you have the time, could you run "debian.rules build" from the perl
source package and see what happens when you run that script.  Right
now, the only thing that I can figure is that it is related to having
a.out as the secondary object format.

Darren
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]> 
<[EMAIL PROTECTED]>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire.  C and Perl programmer and tutor. @

Bug#1929: aliasinclude and forwardinclude directors missing

[Richard Kettlewell]

Package: smail
Version: 3.1.29.1-13

There are no aliasinclude and forwardinclude directors in Debian's
smail.  This stops one from doing mailing lists.

/usr/doc/smail-admin-guide/* provides examples.

--
Richard Kettlewell  [EMAIL PROTECTED]  http://www.elmail.co.uk/staff/richard/

Re: Bug#1916: perl: wrong entries in Config.pm

[Manoj Srivastava]

Hi,
I think that Config.pm handling should meet the following
 requirements: 

 1) The perl-5.XXX-Y package should install correctly (that's
the whole point, right? ;-)
 2) The user should be able to install any extensions into
   /usr/local by default,
 3) there should be an easy way for any developer to change the
default in order to package an extension such that it installs
into /usr, without having to hack Config.pm (which would need to
be done programmatically in debian.rules:build)

One possible way of doing this is:

 a) set up debian.rules:build/config.over in perl-5.XXX-Y such that
the prefix is /usr, and files install into /usr/bin and
/usr/lib/perl5/, and anything else that needs to meet requirement
1 (which you have been doing already, of course).  Make the site
directory /usr/local/lib/perl5, to facilitate b) below.
 b) In debian.rules:binary, after doing make install, add in rules
that 
i)  mv debian-tmp/usr/lib/perl/{arch}/Config.pm \
debian-tmp/usr/lib/perl/{arch}/Config.pm.dev 
ii) change all occurrences of ='/usr/bin to ='/usr/local/bin
in debian-tmp/usr/lib/perl/{arch}/Config.pm.dev, and also all
occurrences of ='/usr/lib/perl5 to ='/usr/local/lib/perl5,
and send the output to
debian-tmp/usr/lib/perl/{arch}/Config.pm.user. (I'd give
the sed script, by I don't have access to my linux box at
the moment.
iii) cd debian-tmp/usr/lib/perl/{arch}; 
 ln -s Config.pm.user Config.pm
 {arch} is, of course, something like i486-linux/5.002, (I haven't
 yet installed 5.002 on my linux box)

This meets requirement 2) above; also, any developer need only 
 change the Config.pm link, and would be all set to install in /usr,
 this meets requirement 3) above.

Also, by making the site directory /usr/local/lib/perl5 in
 step a, we ensure that perl would search /usr/local/lib/perl5 for
 anything installed by the user. 

How does this sound?

manoj

-- Refreshed by a brief blackout, I got to my feet and went next
 door. Martin Amis, _Money_

Manoj Srivastava  Systems Research Programmer, Project Pilgrim,
Phone: (413) 545-3918   A143B Lederle Graduate Research Center,
Fax:   (413) 545-1249University of Massachusetts, Amherst, MA 01003
<[EMAIL PROTECTED]>  http://www.pilgrim.umass.edu/~srivasta/>

Debugging programs with debian elf?

[Rob Browning]

I got gcc-2.7.1 and all (I think) the libs installed properly, and I
have successfully compiled some elf shared libraries, but gdb seems
unable to debug any funcions contained in these shared libraries.  I
did compile the libraries with -g.

Anything I'm missing?

Thanks
--
Rob

Re: Debugging programs with debian elf?

[David Engel]

> I got gcc-2.7.1 and all (I think) the libs installed properly, and I
> have successfully compiled some elf shared libraries, but gdb seems
> unable to debug any funcions contained in these shared libraries.  I
> did compile the libraries with -g.

You currently need a patched gdb to do this.  The patches which
supposedly allow this are available at susix.jura.uni-sb.de in
/pub/linux/source/compile/gdb-4.15.dif but I haven't tried them yet.
Updating gdb is on my list of things to do, but it's not a very high
priority right now.

David
-- 
David EngelOptical Data Systems, Inc.
[EMAIL PROTECTED]  1101 E. Arapaho Road
(214) 234-6400 Richardson, TX  75081

Bug#1930: metamail wants xloadimage

[Raul Miller]

Package: metamail
Version: 2.7
Revision: 1

metamail's mime.types file specifies a program called xloadimage.  This
program is not on my machine, and the control file for metamail doesn't
suggest any optional packages that might have this program.

--
Raul

packages delegated

[Bruce Perens]

There are new maintainers for the following packages:

bash - David P. Boswell <[EMAIL PROTECTED]>
chfn - Jeff Noxon <[EMAIL PROTECTED]>
fdflush - Joe Kirby <[EMAIL PROTECTED]>
fileutils - David P. Boswell <[EMAIL PROTECTED]>
shellutils - David P. Boswell <[EMAIL PROTECTED]>
textutils - David P. Boswell <[EMAIL PROTECTED]>

Thanks

Bruce
--
Pixar: Symbol PIXR on NASDAQ
Visit the "Toy Story" Web Page! http://www.toystory.com

Bug#1931: "less" doesn't work on /proc files

[Bruce Perens]

Package: less

I'm redirecting this to debian-bugs.

Note that "ls" lists the length of /proc/filesystems
as "0", but read() will get more than 0 data. Less doesn't know that
/proc files are special in this way, and treats them as a 0-length file.

You could argue that this is a bug in the semantics of the proc filesystem.
For now, I think we should fix "less" to not abandon any attempt to read a
file when stat() says it's 0-length.

Thanks

Bruce
--
Pixar: Symbol PIXR on NASDAQ
Visit the "Toy Story" Web Page! http://www.toystory.com

Bug#1928: usr/lib/cvs incomplete

[Joel Ray Holveck]

>> It appears that the cvs binary installation does not install several
>> files in /usr/lib/cvs that are necessary to create the repository.
>> This causes cvs to have incorrect assumptions about the state of the
>> repository when it is first created (per instructions for CVS's
>> documentation).  It appears that /usr/doc/cvs contains all the files
>> that /usr/lib/cvs is supposed to have.  A temporary fix is to change
>> debian.postinst to 'cp -r /usr/doc/cvs/* /usr/lib/cvs'.
>Thanks for the info.  I'm not a CVS user, and it'll take me a while
>to sort out what's required to run the basic distribution and what's
>optional user-contributed stuff.  My intention was to install the
>basic CVS stuff as the default and put the user-contrib stuff in
>/usr/doc/cvs.  If you can help me sort this out, it'll speed up
>a fix to the package.

What, is this just a straight package from the GNU CVS distribution
then?  I've got a fair amount of RCS and CVS experience; I wouldn't
mind taking up that package and forming it to the Debian filesystem.

--
http://www.wp.com/joelh --- Joel Ray Holveck --- [EMAIL PROTECTED]

Fourth law of computing:
  Anything that can go wro
.signature: segmentation violation -- core dumped

Bug#1932: Debian GNU/Linux FAQ (html version) bug

[Alexander S A Kjeldaas]

The index to the html version of the FAQ points to wrong sections of the
faq. Typically selecting a question will go to the question below..

astor
-