packages which are links to bo
I put a copy of the local debian mirror on a couple of CDs to install for a friend, and I had problems with the following packages, because they were links into bo, which I hadn't included on the CD. I don't know if this is a problem or not, but it certainly caught me out. doc-linux-it_97.02-1.deb gclinfo_2.2-4.deb python-wpy_0.41-1.deb iamerican_3.1.20-0.1.deb ibritish_3.1.20-0.1.deb ppd-gs_1.1-1.deb psptools_1.2.2-2.deb konfont_0.1-3.deb motifnls_2.1-1.1.deb ilu-base_2.0.0.8-2.deb ilu-dev_2.0.0.8-2.deb ilu-doc_2.0.0.8-2.deb ilu-elisp_2.0.0.8-2.deb libnatali-dev_1.10-3.deb objpak-dev_1.1.1-1.deb doc-linux-it_97.02-1.deb alias_2.3-1.deb gclinfo_2.2-4.deb python-wpy_0.41-1.deb lapack_2.0.1-1.deb tclx76-dev_7.6.0-3.deb tclx76_7.6.0-3.deb perlsgml_1996Oct09-6.deb ppd-gs_1.1-1.deb psptools_1.2.2-2.deb konfont_0.1-3.deb www-search_1.007-1.deb motifnls_2.1-1.1.deb -- Tim Bell - [EMAIL PROTECTED] - Dept of Comp Sci - Uni of Melbourne, Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tetex: symlink "loop"
I've just installed the latest versions of the tetex packages from my local mirror, i.e.: ii tetex-base 0.9-5 basic teTeX library files ii tetex-bin 0.9-4 teTeX binary files ii tetex-doc 0.9-5 teTeX documentation ii tetex-extra 0.9-5 extra teTeX library files ii tetex-nonfree 0.9-5 non-free teTeX library files and I find that /etc/texmf/dvips/config is a symlink to /etc/texmf/dvips. This causes the following to appear in /var/lib/texmf/ls-R: ./dvips/config: config config.ams config.amz config.cm config.cmz config.dfaxhigh config.dfaxlo config.dvired config.epsf config.ps config.ps.dpkg-dist config.www ./dvips/config/config: config [etc.] ./dvips/config/config/config: config [etc.] and so on, until a line with 584 "config/"s, after which it stops. This can't help the lookup speed for finding input files: the ls-R file is 1324kb, compared with 34kb on a machine with tetex-base version 0.4pl8-7. Has anyone else seen this? I can't see any bug reports for it. -- Tim Bell - [EMAIL PROTECTED] - Dept of Comp Sci - Uni of Melbourne, Australia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Fwd: Bug#63511 acknowledged by developer(Bug#63511: fixed in glibc 2.2-7)]
* Nicolás Lichtmaier ([EMAIL PROTECTED]) wrote: > > But the worrying thing is that this bug should have been tagged as "more > info", and the originator should have been contacted to provide that info. I > don't think that a maintainer should close a bug report if he doesn't > understand it, or he feels that some information is missing. > > This makes me wonder how many bugs in the recent libc > mega-changelog-entries were really fixed. My case is similar in some respects, so I thought I'd mention it. The symptoms of bug #77170 (which I've mentioned on this list previously) are still exhibited, even though the bug's been closed. I've exchanged some email with Ben (see the bugreport log) on this subject. His last comment was that he thought it was pthread-related. I countered with an example which wasn't, and the conversation stopped there, with the bug not re-opened. As I commented in the last message, I wouldn't like this to make it into stable with this bug, which prevents apache+php+ldap from running. Now I'm sure Ben is plenty busy with libc6 and whatever else he does, and I don't mean to blame him for this slipping through. But the thought that bugs are getting closed without being fixed is worrying. In this case, if the bug isn't with the particular package it's reported to, it should be reassigned to the correct package (if known), or put somewhere where it will be found again. Losing bug reports for problems which still exist is not going to help with quality assurance. Oh, that all should have been prefixed with IANADD... Tim. -- Tim Bell - [EMAIL PROTECTED] - System Administrator & Programmer Trinity College, Royal Parade, Parkville, Victoria, 3052, Australia
