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
> >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 symli
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
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.
>
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: 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/
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
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
> 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
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
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 <[E
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 semantic
>> 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)
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
-
14 matches
Mail list logo
