Re: our broken man package
On Thu, Jan 04, 2001 at 09:04:50AM +, Lars Wirzenius wrote: Ethan Benson [EMAIL PROTECTED]: OpenBSD took another tack on this problem and just did away with cached man pages altogether. (no suid or sgid man) They always re-format a manual page? This might be reasonable, actually. and some of them filter all the pages through tbl even if only 1/6 of them needs it. Groff is pretty fast, and most manual pages are short, so it shouldn't take too long even on older hardware. but some are soo big. Bash and perl* are good examples. And, anyway, caching might be done in a cronjob: look at the pages in manpath every night, check which ones have been accessed since the past run, and format those. Then delete anything older than N days in the cache. When displaying, use the cached version only if it is newer than the source. Lars, this is exactly the way it works today. Apart from your strange idea to cache what has been accessed during the day. As caching is done at access time, they are already cached! The actual cron.daily removes them after 6 days. And the cached version is used not only if it's newer then the source, but also if the you specifyed the same preprocessor options. This info is stored in the db. While makewhatis only collects name+description, mandb also stores timestamp, formatting options and type of file. I'm planning to add caching not only for ascii formatted pages, but also for html output (which is now available directly from groff). In this case preformatting all pages would be interesting. On the other hand, we might want to copy the OpenBSD version instead of maintaining our own man. But I leave that to whoever maintains the packages. I would prefere the man in plan9. It's the cleaner and simpler I've ever seen. fab -- | [EMAIL PROTECTED][EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
[fpolacco@debian.org: [ man-db_2.3.15_i386.changes INSTALLED]]
As anybody has reported problems with this version or the followers, I presume that the problem was inside that package (I unpacked it and rebuild and I got a .deb with two bytes of difference in size, so something had happened during that build). I'm closing those bugs. fab - Forwarded message from Fabrizio Polacco [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] X-Envelope-Sender: [EMAIL PROTECTED] Date: Thu, 23 Mar 2000 16:25:04 +0200 From: Fabrizio Polacco [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: debian-devel@lists.debian.org Subject: [ man-db_2.3.15_i386.changes INSTALLED] User-Agent: Mutt/1.0i Hi! I recompiled man-db as it was (no change) and reuploaded. As someone made me notice, the pure rebuild had few bytes of difference, so maybe we get a different result. Can people try the upgrade from 2.3.13 ?? And can that people that got the error try to downgrade to slink version and then upgrade to the new one? This is the real upgrade that bother me. If nobody will report any problem, I'll close the bugs. fab - Forwarded message from Debian Installer [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] Date: 23 Mar 2000 12:24:17 - From: Debian Installer [EMAIL PROTECTED] To: Fabrizio Polacco [EMAIL PROTECTED] Subject: man-db_2.3.15_i386.changes INSTALLED Installing: man-db_2.3.15.tar.gz to dists/potato/main/source/doc/man-db_2.3.15.tar.gz replacing man-db_2.3.14.tar.gz man-db_2.3.15.tar.gz to dists/woody/main/source/doc/man-db_2.3.15.tar.gz replacing man-db_2.3.14.tar.gz man-db_2.3.15.dsc to dists/potato/main/source/doc/man-db_2.3.15.dsc replacing man-db_2.3.14.dsc man-db_2.3.15.dsc to dists/woody/main/source/doc/man-db_2.3.15.dsc replacing man-db_2.3.14.dsc man-db_2.3.15_i386.deb to dists/potato/main/binary-i386/doc/man-db_2.3.15.deb replacing man-db_2.3.14.deb man-db_2.3.15_i386.deb to dists/woody/main/binary-i386/doc/man-db_2.3.15.deb replacing man-db_2.3.14.deb Changes: man-db (2.3.15) frozen unstable; urgency=high . * Just recompiled, with an upgraded potato system. Let's see if this wipes away the grave installation problem listed in bugs #60339, #60399, #60411, #60515. In that case, I'll close these bugs by hand :-) Announcing to debian-devel-changes@lists.debian.org Closing bugs: If the override file requires editing, reply to this email. Thank you for your contribution to Debian GNU/Linux. - End forwarded message - -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - End forwarded message - -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: ITP: manpages-da
On Fri, Mar 24, 2000 at 11:58:39AM +0100, Peter Makholm wrote: In SSLUG (swedish/danish LUG) we have begun translating man-pages to danish. when we have finished a nice set (like file-utils) I will make a debian package out of it. Great! Please, as some of these people tend to use RedHat (yes, not anybody knows that Debian is better :-), there is a marked tendency to find manpages for man,whatis,apropos or even makewhatis which are translated from that distro. As Debian is shipping a different man program, please remove those pages from your package. Instead, ask the translators to translate also the Debian pages (man-db ships 9 manpages) and the po file. That would be wonderful. When done, ship them to me so I'll include them in man-db. Thanx, fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Bug#49962: Old and new man pages - clean solution possible.
On Wed, Mar 29, 2000 at 10:50:07PM +0200, Andreas Krüger wrote: Closing Bug 49962, Raphael Hertzog [EMAIL PROTECTED] writes: Everything has been said, and there's no clean solution. It would be a crude hack to make (all or most of the) packages conflict with an old man-db simply because the man page moved. That'd be a crude hack indeed. But aren't there any smarter ways to go about this? Here is an attempt at a clean solution: Provide a new package port-man-db. This package is very small, mainly consisting of one single shell - script /usr/sbin/port-man-db . This script checks wether man-db is installed on the system at all. If it isn't, the script does nothing. If the script finds the old man-db, the neccessary tweaking is done to get it to accept new pages. When the script runs a second time on an old man-db system, it finds its own tweaking in place and does nothing more. If the script finds the new man-db, nothing is done, either. check /usr/lib/man-db/chconfig on potato: # tool to convert the man-db configuration file to the FHS. # it slurps the file in argument (default /etc/manpath.config) and, # it tries to make the changes to comply with FHS. it is called by postinst: if [ -x $(which perl) -a -x $chconfig ] then$chconfig $conffile ... You can put this script in an essential package like Guy's debianutils (like in /usr/lib/debianutils/chconfig ) and run it in postinst. It is idempotent, so having it also in man-db does no harm. If you decide to go and NMU debianutils (is Guy still around?) then this would be the right moment to put undocumented(7) in it, and stop another series of boring bugs :-) fab, wearing its hat of man-db maintainer. PS.: if it was not yet clear, I repeat it here: you don't need a new man program to read FHS pages, just to change the configfile. -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: ITP: bnc
On Wed, Mar 22, 2000 at 08:31:16PM +0100, Marco d'Itri wrote: I'm packaging the bnc IRC bouncer. too late Marco! I did it one month ago. :-P It's sitting in Incoming (dunno why?) and there is also a slink-compiled version (I needed to run on slink). fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
[ man-db_2.3.15_i386.changes INSTALLED]
Hi! I recompiled man-db as it was (no change) and reuploaded. As someone made me notice, the pure rebuild had few bytes of difference, so maybe we get a different result. Can people try the upgrade from 2.3.13 ?? And can that people that got the error try to downgrade to slink version and then upgrade to the new one? This is the real upgrade that bother me. If nobody will report any problem, I'll close the bugs. fab - Forwarded message from Debian Installer [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] Date: 23 Mar 2000 12:24:17 - From: Debian Installer [EMAIL PROTECTED] To: Fabrizio Polacco [EMAIL PROTECTED] Subject: man-db_2.3.15_i386.changes INSTALLED Installing: man-db_2.3.15.tar.gz to dists/potato/main/source/doc/man-db_2.3.15.tar.gz replacing man-db_2.3.14.tar.gz man-db_2.3.15.tar.gz to dists/woody/main/source/doc/man-db_2.3.15.tar.gz replacing man-db_2.3.14.tar.gz man-db_2.3.15.dsc to dists/potato/main/source/doc/man-db_2.3.15.dsc replacing man-db_2.3.14.dsc man-db_2.3.15.dsc to dists/woody/main/source/doc/man-db_2.3.15.dsc replacing man-db_2.3.14.dsc man-db_2.3.15_i386.deb to dists/potato/main/binary-i386/doc/man-db_2.3.15.deb replacing man-db_2.3.14.deb man-db_2.3.15_i386.deb to dists/woody/main/binary-i386/doc/man-db_2.3.15.deb replacing man-db_2.3.14.deb Changes: man-db (2.3.15) frozen unstable; urgency=high . * Just recompiled, with an upgraded potato system. Let's see if this wipes away the grave installation problem listed in bugs #60339, #60399, #60411, #60515. In that case, I'll close these bugs by hand :-) Announcing to debian-devel-changes@lists.debian.org Closing bugs: If the override file requires editing, reply to this email. Thank you for your contribution to Debian GNU/Linux. - End forwarded message - -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: Bug#60399: crashes on installation
[can anybody with knowledgs of the internals of dpkg/apt take a look at this?] On Thu, Mar 16, 2000 at 10:13:52AM +1100, Brian May wrote: Fabrizio If you downgrade man-db (I'm reuploading 2.3.13 so Fabrizio you'll find it in Incoming or Incoming/REJECT) and then Fabrizio re-apt it, will it fail? Anyway, have a look at the following: lyell:~# apt-get upgrade .. Unpacking replacement man-db ... dpkg-deb: subprocess paste killed by signal (Broken pipe) dpkg: error processing /var/cache/apt/archives/man-db_2.3.14_i386.deb (--unpack): subprocess dpkg-deb --fsys-tarfile returned error exit status 2 Building manual page index in background. Errors were encountered while processing: /var/cache/apt/archives/man-db_2.3.14_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) We have success! Problem duplicated! Great. As you already have the old deb, can you please repete the test, but using dpkg -i instead of apt-get (to re-upgrade I mean ... I don't think apt-get can downgrade). That is just to narrow the search of the package to reassign the 4 bugs :-) But seriously, it's quite clear that something in this man-db package it's triggering this ugly behaviour. So, what's changed between 2.3.13 and 2.3.14 ? -rwsr-xr-x root/root 82752 ./usr/lib/man-db/man -rwxr-xr-x root/root 82752 ./usr/lib/man-db/man --- -rwsr-xr-x root/root 66012 ./usr/lib/man-db/mandb -rwxr-xr-x root/root 66012 ./usr/lib/man-db/mandb --- -rw-r--r-- root/root 9008 ./usr/share/man/man1/man.1.gz -rw-r--r-- root/root 9006 ./usr/share/man/man1/man.1.gz --- -rw-r--r-- root/root 9986 ./usr/share/man/it/man1/man.1.gz -rw-r--r-- root/root 9984 ./usr/share/man/it/man1/man.1.gz --- -rw-r--r-- root/root 14485 ./usr/share/doc/man-db/changelog.Debian.gz -rw-r--r-- root/root 14617 ./usr/share/doc/man-db/changelog.Debian.gz size 332058 bytes: control archive= 4325 bytes. size 332200 bytes: control archive= 4320 bytes. --- 792 bytes,20 lines control 816 bytes,20 lines control --- Version: 2.3.13 Version: 2.3.14 --- Depends: groff ( 1.15-2) | jgroff ( 1.15), libc6 (= 2.1.2) Depends: groff ( 1.15-2) | jgroff ( 1.15), libc6 (= 2.1.2), libdb2 (= 1:2.4.14-7) --- Another thing that is changed is inside the md5sum file: a79d0fb7542beef4281c7d754707bac0 usr/bin/wrapper bc5ae3db0572b49aa938538f37c4147b usr/bin/man bc5ae3db0572b49aa938538f37c4147b usr/bin/mandb f9b7b6014efe84c9cea791c6e2b2f568 usr/bin/wrapper f9b7b6014efe84c9cea791c6e2b2f568 usr/bin/man f9b7b6014efe84c9cea791c6e2b2f568 usr/bin/mandb In version 2.3.13 the md5sum of /usr/bin/man and /usr/bin/mandb is the md5sum of the shell scripts files that are in the .deb and are removed inside postinst, while in the 2.3.14 md5sum its listed the digest of the files that are installed after the postinst (hardlinks to /usr/bin/wrapper), and not the digests of the files shipped inside the .deb. Does anybody know if this could be the trigger for this ugly stuff? fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: man tr segfault
On Sat, Mar 11, 2000 at 05:57:32PM -0500, Ajit Krishnan wrote: hi, man segfaults when formatting tr. I've tried to include all relevant information below. I'm sorry if this is a known bug. I'm running woody updated late last night from the .us mirror. Cheers, bash-2.04$ man tr Reformatting tr(1), please wait... groff: troff: Segmentation fault ||/ Name Version +++-=-== ii groff 1.15-3.ja.2 groff_1.15-3.ja.3 in Incoming fixes it. Try it. thanx, fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED] | pgp: 6F7267F5 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Packages for adoption: dip, sliplogin
HI, due to absolute missing of dial up abilities (I don't even have a fixed line any more :-) I have to orphane two of my packages: dip - I'm crying in orphaning this, as I was putting a lot of care. It's the tool to handle SLIP/PPP connection (both sides), and it was the only one available for a long time. Now its fortune is slipping down, partly for the absolute dominance of PPP (I corrected PPP stuff on it) and the hostility of one HOWTO author. It has 4 bugs, two of them were due to the transition to glibc2, but I'm unable to see if they're gone. I also have a patch that I'm unable to test (it's not in the bts). sliplogin - Tool to attach a serial line network interface This tool is used to turn the terminal line on standard input into a Serial Line IP (SLIP) link to a remote host. Sliplogin can be used to setup SLIP dialin connections. Need a maintainer with good knowledge of modems and one to do test :-) Cheers, fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
man-db and FHS: please test.
Hi all, man-db 2.3.10-69j is hitting the mirrors. I consider this as a pre-2.3.12 , which I want to release before the freeze. It contains a relevant change from the previous versions as /etc/manpath.config is no more a conffile. A script will upgrade it to FHS leaving the previous file as /etc/manpath.config.orig , but without overwiting it if it exists (later run will add a tilde; but the script won't run twice on the same file). * created perl script /usr/lib/man-db/chconfig that scans the file in argument (the man confile) and upgrade it to FHS. Its call from postinst is checked also against perl presence. * removed /etc/manpath.config from conffiles; added in postinst automatic copy of it if the existing one isn't being modified, or using the new script to validate it and upgrade to FHS. Treat correctly absence of the config file (??) and allow insertion of keyword NOFHS in /etc/manpath.config to avoid its update. In case the existing file was unmodified, it simply overwrite it (as it would have done if it were still a conffile). It should (note the ??) behave correctly in absence of the config file. I have checked the script with many strange things in the config file, but ... there's no limit to strangeness. So please, if you have a modified /etc/manpath.config, compare the two files after the installation of this version, to see if the changes were reasonable. To do further tests, you can execute the script /usr/lib/man-db with a filename as argument. Beware that the trigger to avoid further re-processing id the comment inserted in the first line. Raise bugs at will, and cheers! fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: Alternate versions of the same shared library?
On Wed, Sep 22, 1999 at 12:36:17AM -0400, Camm Maguire wrote: Greetings! Is there any way to maintain alternate versions of the same shared library on a Debian system? (i.e. same soname) One can have two packages which conflict with each other, but I was thinking about some run-time switching functionality, like in the 'alternatives' system, so that one could choose between an experimental but fast shared lib, and the trusted but slower one, at runtime. I've tried several things, but lintian disallows most of them. You can install the alternate lib (using the same name and soname) in another directory, and have the loader find this only if you set the env var LD_LIBRARY_PATH to the dir containing it. Have a look at packages liblockdev*-dbg and/or libdb2*-dbg which installs debugging shared libs in /usr/lib/debug. In /usr/lib/debug/README.debug you find clear (I hope :) instructions even on how to run gdb on setuid binaries. fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: An 'ae' testimony (suggestion)
On Wed, May 26, 1999 at 04:00:00PM +0200, EXT Martin Kahlert wrote: Quoting Sven LUTHER ([EMAIL PROTECTED]): Will try at home, if it works fine, i could package it. Do you have any idea about the license of this stuff ? there seem to be no mention of it in the sources. Sorry, no. You will have to ask the author for it. From the manpage: Copyright (c) 1982-1997 David L Parsons All rights reserved. Redistribution and use in source and binary forms are Linux 29 August 1998 17 LEVEE(1) Mastodon Linux LEVEE(1) permitted provided that the above copyright notice and this paragraph are duplicated in all such forms and that any documentation, advertising materials, and other mate rials related to such distribution and use acknowledge that the software was developed by David L Parsons ([EMAIL PROTECTED]). My name may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PRO VIDED AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED WAR RANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WAR RANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 (0)40 707 2468
Re: Source-depends?
On Wed, May 26, 1999 at 02:04:47PM +0200, EXT Josip Rodin wrote:
On Wed, May 26, 1999 at 01:46:41PM +0200, Sven LUTHER wrote:
So it would be nice to have a some kind of wrapper library that patches the
open and such function from glibc, and log the accessed files (the one that
are
not in the build directory naturally) after that you just have to run some
kind
of dpkg -S on these files, and you get all packages needed for building this
package.
you would need something a bit like what fakeroot does for it, so it is not
impossible.
The dpkg -S part would be quite slow i think, and produce a very big number
of
packages, but you could reduce them by providing a standard debian compiler
metapackage (or whatever it is named this days) including stuff like make
and
gcc. or maybe various of them for lets say perl-devel, gcc-devel, text-only,
etc, ...
Of course, these are all very nice ideas... but we currently don't
have any PLACE to put the list (where it'll get used by dpkg* tools),
whether it is manually or automatically generated!
IIRC Ben Collins had made a functional patch to dpkg package about
this a few months ago, though it wasn't very featurful it did the
job (dpkg-source would check the list, and warn if you don't have
a listed package installed).
Th epatch you're talking about was to use the list or to generate
it?
I did some experiments a few days ago and got a good result while
building last man-db (whose source include a list of the output of
dpkg -l on its source-dependencies:
:r!cat /home/work/man-db/man-db-2.3.10/debian/source-depends
(yes I use vim to write my email :-)
sudo strace -f -etrace=file -o ../trace.69h -q -a80 debian/rules binary 21 | \
tee ../log.69h
cat ../trace.69h | grep -v ' = -1 ' | awk -F\ '{ print $2 }' | grep -v
'^/tmp/' | \
grep -v '^/dev/' | grep '^/' | grep -v ^$PWD | grep -v
'/var/lib/dpkg' | \
sort -u ../trace.filt.69h
for j in `cat ../trace.filt.69h`;do test -f $j realpath $j;done | \
xargs dpkg -S 2/dev/null | awk -F: '{ print $1 }' | sort -u | xargs
dpkg -l
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
+++-===-==-
ii autoconf2.12-13automatic configure script builder.
ii base-files 2.1.0 Debian Base System Miscellaneous Files
ii bash2.01.1-4.1 The GNU Bourne Again SHell
ii binutils2.9.1.0.19a-2 The GNU assembler, linker and binary utiliti
ii bsdmainutils4.4.0.1More utilities from 4.4BSD-Lite.
ii cpp 2.7.2.3-7 The GNU C preprocessor.
ii debianutils 1.10 Miscellaneous utilities specific to Debian.
ii diff2.7-18 File comparison utilities
ii dpkg1.4.0.34 Package maintenance system for Debian Linux
ii dpkg-dev1.4.0.34 Package building tools for Debian Linux
ii fileutils 3.16-5.3 GNU file management utilities.
ii findutils 4.1-33 utilities for finding files--find, xargs, an
ii flex2.5.4a-3 A fast lexical analyzer generator.
ii gcc 2.7.2.3-7 The GNU C compiler.
ii gettext 0.10.35-7 GNU Internationalization utilities
ii grep2.2-1 GNU grep, egrep and fgrep.
ii groff 1.11a-7GNU troff text-formatting system.
ii gzip1.2.4-28 The GNU compression utility.
ii hostname2.04 A utility to set/show the host name or domai
ii ldso1.9.10-1 The Linux dynamic linker, library and utilit
ii less332-4.1A file pager program, similar to more(1)
ii libc6 2.0.7.19981211 GNU C Library: shared libraries
ii libc6-dev 2.0.7.19981211 GNU C Library: Development libraries and hea
ii libdb2 2.4.14-5 The Berkeley database routines (run-time fil
ii libdb2-dev 2.4.14-5 The Berkeley database routines (development
ii libgdbmg1 1.7.3-25 GNU dbm database routines (runtime version).
ii libncurses4 4.2-3 Shared libraries for terminal handling
ii libreadlineg2 2.1-12 GNU readline and history libraries, run-time
ii libstdc++2.92.91.60-5 The GNU stdc++ library (egcs version)
ii locales 2.0.7.19981211 GNU C Library: National Language (locale) da
ii m4 1.4-9 a macro processing language
ii make3.77-4 The GNU version of the make utility.
ii mawk1.3.3-2a pattern scanning and text processing langu
ii perl5.004.04-7 Larry Wall's Practical Extracting and Report
ii perl-base 5.004.04-7 The Pathologically Eclectic Rubbish Lister
Re: Intent to package manpages-fi
Teemu Hukkanen wrote: from the README: -8-clip-8- This package contains a first, fixed release of Linux man pages in Finnish. There are 132 pages from sections 1 and 6. If you want to contribute, point your browser to www.redhat.sot.com/Man-pages-fi.shtml Copyrights: These man pages are under GPL. -8-clip-8- upstream package at http://www.redhat.sot.com/usr/man/RPMS/man-pages-fi-0.1-2.noarch.rpm only as .rpm. I'm still trying to get them to distribute also as something else than .rpm Please, pay attention that on redhat some programs are different from those on debian. For example, debian has man-db instead of man, so the manpages for man, whatis, apropos, makewhatis shouldn't go into debian. Instead the man-db program installs all its translations (manpages and messages), so you should get its source and translate them. thank you. fab
dpkg port to HP-UX
[please reply to me or to debian-devel, as I am subscribed only to it] Hi everybody, If I remember well, some time ago someone posted his results on a port of dpkg to HP-UX. Now I have to evaluate packaging systems for that platform, and I would like to push a Free solution, a debian one specifically (because it's the best :-). If someone has hints or examples, please contact me, as it would help me greatly if I can present real cases and/or working code. Thank you, fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | [EMAIL PROTECTED] gsm: +358 40 707 2468
Re: France and Cryptography
Sven LUTHER wrote: (This becomes slightly off-topic on debian-devel) no it is not, this means i (living in france) can sign debia npackages without becoming a dangerous terrorist or whatever, hey in the past i could have been put in jail for that ... Not at all. Restriction was only for encription of text, not for signing it. fab
Re: Debian goes big business?
David Welton wrote: On Tue, Jan 19, 1999 at 04:55:29PM -0600, John Hasler wrote: Shawn writes: I am all for a for-profit business forming as a value-added seller of Debian products. Such a business could focus on pre-installations, packaging and marketing, and user support. I would think a very successful business could be built on such a model, and there would be no necessary control flowing either way between said business and the Debian organization. The Debian community would control the software, such a business (and there could be many of them) would control its own marketing, packaging, support program, etc. Exactly! This is just the sort of company I would love to participate in. This is what Prosa (www.prosa.it) is, for the record. It is something more, for the record. It's the only company (a ltd for the precision) that has carved into stone (in its statute, I mean) the obligation to comply with the open-source definition. That means that if an employee installs Windows on a company PC it can be fired. No, can is not the right verb; must is. :-) Alessandro Rubini (who wrote Linux Device Drivers, as well as the Kernel Corner column for the Linux Journal) is one of their employees. One of the founders, for the record, and beloved President. fab --
Re: Bug#23522: man-db installs foreign language manpages
On Mon, Jun 15, 1998 at 10:59:13AM +0200, Peter Maydell wrote: Fabrizio Polacco wrote: If you don't reassign this bug to dpkg or apt, I will close it in two days (as later I will be busy). rant Oi! I'm an end user (OK, so I browse debian-devel :-). I'm not supposed to have to know how to manipulate the bug tracking system. I agree that man-db might not be the right place for this bug report, but I wasn't sure where to file bugs against programs that don't exist (our hypothetical language management tool) so I picked the only package on my system with multiple-language manpages. If you don't think it's filed against the right package, it's *your* responsibility as a developer to reassign it to the right place. /rant Sorry for the nasty lines. Please read them as: If you are interested in reassigning this bug to dpkg, do it within the next two days as I don't want to leave this bug in man-db as I will take a plane on thursday :-) I myself am not interested to do the reassignement because there are already bugs opened and apt has promised to solve this question. When apt will be released, if it will not solve that, you'll hear my voice. [In fact, I probably could reassign it, if I read the BTS documentation; but as a point of principle you shouldn't ask me to :-] Well the BTS is there to be used by debian users (as I am too) and is not private territory of developers. It's simply a way of discussiong in front of a working recorder. I personally consider each bug as a personal note coming from a user, and I usually ask them if they prefere to do changes to the bug by themselves. The docs are not so plain (text only and in reference format only), but they are already on your box, under /usr/doc/debian . fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E PROSA srl - la prima azienda commerciale esclusivamente open-source PROSA ltd - the first commercial firm enterely open-source oriented | support the open-source initiative! http://www.opensource.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#23522: man-db installs foreign language manpages
[This (harsh) reply is CCed to debian-devel, as I think it's the place to discuss about the issue.] On Sun, Jun 14, 1998 at 11:10:13PM +0200, Peter Maydell wrote: Package: man-db Version: 2.3.10-65 man-db installs Spanish, Italian and German versions of its manpages, as well as English ones. This is one of the goals of Debian. It is surely the main reason for *my* partacipation to the project. When I find a package wich doesn't install all the translations available in its sources, I raise a bug asking to do so. It ought to ask the sysadmin which languages to install rather than installing them all without prompting. If every package would prompt for this, installation would become a nightmare. If I do this, I'm sure someone else would raise a bug against unnecessary prompting, and I would agree with him. Therefore I will not do this. [Actually, this ought to be a system-wide setting...] You're right here. So the problem is not in man-db (or any other package installing all the available languages), but in the insatallation tools. I think this is a long awaited enhancement in dpkg's todo list. Last year Ian was too busy for this, now we've been promised that apt (it was deity before) will do that, and I hope he will do this ASAP. But I think it would be important to have a way to change your mind later, to let you add another language. This might not seem like a significant disk usage for this package (it's about 25K extra for each language), but consider if every program installed four versions. Then the necessity to have such decision tool will become urgent, and the tool will be done. If I drop translations, this will never be done. My /usr/man/man?/ tree is about 5MB, and I would certainly object if Debian installed an unnecessary extra 15MB of man pages I would never read. Your opinion that translations are unnecessary extras is only your opinion. My aim is to create a multilingual distribution. My preferred example for this is a shell machine in a ISP in Europe, in Bozen or Brussels, or even here in Turku, places where people speaks more than one language, and you cannot know in advance which language will be used by every user. If you don't reassign this bug to dpkg or apt, I will close it in two days (as later I will be busy). fab -- | [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E PROSA srl - la prima azienda commerciale esclusivamente open-source | support the open-source initiative! http://www.opensource.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What's Debian's /usr/src policy
On 8 Jan, Guy Maor wrote: Fabrizio Polacco [EMAIL PROTECTED] writes: I recently managed to add some sources in my -dbg shared lib packages, to make them easily debuggable. (See bug#16038 on 30 Dec) I rather liked your solution to the problem of debuggable shared libs, but you need to figure out a way to not need to be root to build it. (maybe you already did?) Maybe we could start a thread on debian-policy about the best way to do -dbg packages? Good idea. I posted a long summary to debian-policy. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E more than 35 months are needed to get rid of the millennium. [me] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Is there a maintainer for the install doc?
On 7 Jan, Igor Grobman wrote: Is anyone maintaining the Debian installation manual? I know that Sven is no longer doing it. If not, we will need a volunteer. I'd like to maintain it. I plan to be active on the testing front, so I should be aware of all the quirks with the installation and upgrading. Igor, are you planning to take only the installation manual or all the docs in boot-floppies? Now that we are going to add translations to the installation disks, we need to add also the translated manual; this needs coordination. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E more than 35 months are needed to get rid of the millennium. [me] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Isaac Asimov and the millenium bug [offtopic]
On 7 Jan, Juan Cespedes wrote: On Tue, 6 Jan 1998, Fabrizio Polacco wrote: Continuing off-topic, I remember that when I was young (very young) I read a nice proposal for a reform of the calendar, made by Isaac Asimov. Isaac Asimov suggests that we should always use the decimal system, with one day as the base, and forget about hours, minutes, seconds, weeks, months, years and so on. For example, the actual date would be 10227.4042 (10227 days since Jan 1 1970, 0.4042 days since 12 AM (UTC)). Using 4 decimals will give us a precision of 8.6 seconds. Humm, the one that I recall was to divide the year in 4 seasons and count days per season instead than month (91), plus one spare day to be used as a foolish-day. The peculiarity was that in that proposal the sequence of days, weeks, seasons was the same on every year, that is to say that (I guess) the 3rd of spring was thursday on every year ... He calculated the savings of all the economic activities because of a highly prevedible calendar. Fabrizio, flying highly offtopic :-) -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E more than 35 months are needed to get rid of the millennium. [me] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
On 5 Jan, Christian Schwarz wrote: On Mon, 5 Jan 1998, Ian Jackson wrote: I think that /usr/src should the be domain of the local admin. I disagree. /usr/local/src is for local admin. This may be the case if you look at all packages, but I have never installed any packages that did this, and if I had I would have reported it as a bug. A few packages currently install into /usr/src: awe-drv, debian-cd, etc. add liblockdev0g-dbg and libdb2-dbg to that list. I recently managed to add some sources in my -dbg shared lib packages, to make them easily debuggable. (See bug#16038 on 30 Dec) Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] pgpJd15FBTjm3.pgp Description: PGP signature
Re: What warrants a non-maintainer release number?
On 6 Jan, Remco Blaakmeer wrote: I think the general opinion was let the others take care of not conflicting with us. So, the people on debs.fuller should make sure that the version numbers they use will not be taken by 'official' .deb packages. This sounds nonsense. People at deb.somewhere will not care at all of our policies and package as they like (as KDE is doing); Debian's maintainer will get the complaints. You cannot expect that the _others_ will do in the right way. Ask Murphy. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 6 Jan, Kai Henningsen wrote: [EMAIL PROTECTED] (Fabrizio Polacco) wrote: On 6 Jan, Remco Blaakmeer wrote: So, the people on debs.fuller should make sure that the version numbers they use will not be taken by 'official' .deb packages. This sounds nonsense. It's the only option we have. The only option we have is to find a way to say if a package is official or not (and it cannot be its presence in the ftp site). Simple example: someone grabs a source package and rebuilds it without any changes. He will now have a different .deb (and it _will_ be different - different time stamps, maybe he used a different gcc, different debmake version ...) with the exact same version number as the original. Yes, and therefore, as Christian has just recalled, we need to add an origin field somewhere _inside_ the binary package. It cannot be included by the maintainer, because not all the packages that a maintainer build will become official, and also a maintainer can step out from the project (and still use his own pgp key). My suggestion was that dinstall will unpack the .deb , insert some signature in it (for example a md5sum list of the files in the control.tar.gz, pgp-signed with an official key), and repack it just before installation in the ftp hierarchy. (If the control.tar.gz contains the md5sums of the files installed by the package, then installing also this signed list into dpkg/info would add a way to check if a single file is the one distributed by us.) pgp-signing the Packages file could be another way to achieve this (the origin field), but will be too easily broken on rearranged distributions (e.g: your own mirror, or a custom CD), and the signature will be lost when updating the available list (that is to say: _before_ installation). Just close bug reports referring to non-project .debs with not our package, not our problem. The problem is knowing when a bug refers to a non-project package. When the user is sending us such bugs, probably he didn't notice or remember that the package wasn't build by us. Without a trusted origin field you will be prosecuted by the suspicion if the package is original or not. If the signature (that certifies that a package is debian-original), is installed in the dpkg database then we could have the bug command (or else) add automatically this information to the report. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
On 6 Jan, Kai Henningsen wrote: Remember that the last calendar reform was made at an actual difference of about 10 days (and some countries took a long time after that to implement it, thus increasing the difference even more), so I'd expect people won't touch that until the difference is again in that ballpark - around AD 31000-32000, that is. Continuing off-topic, I remember that when I was young (very young) I read a nice proposal for a reform of the calendar, made by Isaac Asimov. I cannot find it anymore and, for some strange but human reason, I'm no more in the possibility to ask Isaac himself. Did anybody read it and can tell me where I could find it? Thanks, Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E more than 35 months are needed to get rid of the millennium. [me] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 5 Jan, Christian Schwarz wrote: How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. What about: The version number of a previously uploaded package must be incremented on every change in one of the md5sums listed in the .changes file, even in absence of other modifications to the package's contents. or: After a package has been uploaded (even if not installed), you must always increment the debian version number before uploading it again if any of the md5sums in the .changes file has changed. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E pgp1HNuAtTOhF.pgp Description: PGP signature
Re: How to detach debug symbols from libraries
Yann Dirson wrote: Correction: it works now (probably a compilation option that wasn't used at the time). Problem: it's really a mmap image (thus works only for executables, not libs), and includes the libs symbols: aha, but shared libs are executable files, so I succeeded building a shared lib with debug symbols (just ar -x and cc -shared) and then I gdb -batch -nx -mapped -readnow sharlib it builds sharlib.syms that gdb can load with -s. The problem is that gdb refuses to debug a shared lib, maybe needs some flag. But the real problem is that the sizes are ... unmanageable the shared lib is half the size of the static one, while the .syms file is double! -rw-r--r-- 12242044 Dec 13 19:20 libdb2.a -rwxr-xr-x 11129332 Dec 13 19:18 libdb2.so -rw-r--r-- 15246976 Dec 15 13:26 libdb2.so.syms A quick scan of gdb info let me suppose that debugging of shared libs is not easy under Intel platforms. So I loose all interest in using .syms files instead of unstripped static libs. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: unstripped stuff in /usr/lib
[EMAIL PROTECTED] wrote: We could let the -dev versions of packages have diversions of the libraries to unstripped versions, and have the runtime versions have stripped versions. Since most of the times -dev packages are needed to compile only (headers and the symlink from lib.so), I think it'd be better to put unstripped libraries on a separate -dbg package (as lib_d.a). Those libs are easily 10 times the size. Usually we have: runtime pkg:shared lib stripped with --strip-unneeded develop pkg:static lib stripped with --strip-debug debug pkg: static lib unstripped I'm not sure on what to do for shared unstripped libs (are they supported by gdb, now?) Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: bo-updates packages
Hamish Moffatt wrote: You've won me over. I've backported a couple of my packages, but only one (guavac) is not new for hamm, or even vaguely well known. However I think that fixing bugs in hamm should probably take priority, but I don't have outstanding here. Right. It's only a recompilation. If one package doesn't work we don't recompile it. It's only a kind offer to our bo users instead of harshly say get the source from hamm and recompile yourself!. No more. Therefore should be done only for new or improved packages (both from upstream than bugs fixing). Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
How to package a JAVA library?
Hello Java folks! My absolute ignorance of java is causing me trouble. I'm building a set of library packages that includes a java shared library. After a failed try with guavac (but I don't giveup), I succeded in MAKEing the shared lib using javac. The make stage creates a lot of '.class' files and a lib_java.so object. Now the trouble: * What files should be put in the java binary package? * Where those files should be located? (/usr/lib, /usr/include ?) * Should I make a pair of packages (runtime + develop)? * What is the naming convention for java packages? Thank you for the help, Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
How to build a C++ library?
Hello C++ folks! I need a little help in building a C++ library. I'm building a set of library packages that include C and C++ static and shared libs. The original makefile builds the C++ ones linking the full set of C and C++ object files. The C++ packages will depend anyway from the C shared runtime package, so I was wandering if I could build the C++ shared lib using _only_ the C++ objects. Would this be a good or a bad thing? In case, how can I force an internal dependance on the shared C lib? If you want to give a glance to a pre-release version of the packages, you'll find them in ftp://ftp.icenet.fi/private/fpolacco/temp/db2 Thank you, Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
How to detach debug symbols from libraries
Hi folks! I remember someone suggesting to tetach debugging symbols from libraries to package them separately on a -dbg binary package. * What is the way to do that? * How can a detached symbol table be used to debug a program? * Can such table be used both for shared and static libs or should I build 2 tables (or only the static one)? Thank you for your help, Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: bo-updates packages
Hamish Moffatt wrote: So, I think if somebody really wants to run some newer software (which isn't necessarily stable in our terms), then the choices are: 1. compile it from sources -- ugly, but workable. Even to the extent of making your own packages, which I gather youve done. 2. upgrade to the unstable package, and in the case of hamm, install enough of hamm to run it. This isn't actually that much; new ldso, libc6, new libc5 I think, and some libraries. With such a system, you can run libc6 binaries but compilation is done for libc5, etc. I have such a system and it works fine. (3. try to backport the package yourself.) The right answer is 3. Answer 2. is the wrong one. Remember that we are now speaking of people who _cannot_ upgrade their systems to hamm, because they are production machines, and/or their sites have a policy to not install unstable software unless it's absolutely necesssary. Often these people are urged to get latest version of some important software, for direct request or because of embedded dependency. The problem with answer 3. is that it embeds answer 1., plus the load to debianization. Therefore people goes for 1. and then complains because they lose the advantage of using dpkg, and/or the encounters problems that had been solved previously in the debian packages. They feel that those are debian's fault. We need very little to do offer 3. to our customers. Most maintainers have a double boot machine (like me), or have a bo machine on their net, and launching recompilation of latest packages (after a small change in the changelog file) is a little waste of time (and gives more benefits). I remember of one developer who couldn't upgrade his only machine to hamm; he could only help doing non-maintainer uploads of new packages. Pay attention: nobody here is proposing to create a debian-1.4 libc5 based release! That would be a waste of energies. Only new packages and security fixes should be libc5-recompiled, not everything. Doing this, we will also establish a policy on _how_ should be handled releases for stable. It's my opinion that we should never move directly packages from unstable to stable, but in case recompile them on a stable-based machine (we had plenty of bugs because of that). Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Duplicate messages on this list
Manoj Srivastava wrote: Personally, I still think that reply-to is a bad solution; I agree. The people with sad mail software and lazy fingers are penalizing the people with low bandwidth. Don't break conforming software to cater to broken software. Are we sure that we giving the right answers to Gonzalo's problem? I received his post about Re: linux/unix to NT twice (only his): one had the headers: Received: (from [EMAIL PROTECTED]) by templinux.bucknell.edu (8.8.5/8.8.5) id VAA07482; Tue, 2 Dec 1997 21:19:26 -0500 Resent-Date: Tue, 2 Dec 1997 21:19:26 -0500 Date: Tue, 2 Dec 1997 18:13:06 -0300 Message-Id: [EMAIL PROTECTED] Resent-Message-ID: y-M46C.A.OzB.lGMh0@templinux X-Mailing-List: debian-devel@lists.debian.org archive/latest/513 while the other: Received: (from [EMAIL PROTECTED]) by newton.nowhere.cl (8.8.5/8.8.5) id SAA01886; Tue, 2 Dec 1997 18:13:06 -0300 Resent-Date: 3 Dec 1997 02:12:33 - Date: Tue, 2 Dec 1997 18:13:06 -0300 Message-Id: [EMAIL PROTECTED] Resent-Message-ID: V_NgkD.A.M7B.RAMh0@debian X-Mailing-List: debian-devel@lists.debian.org archive/latest/11843 That messages took two different paths and were distributed by two different servers (is templinux.bucknell.edu our list backup or is a NNTP/SMTP gateway ? ) Has Gonzalo a newsfeed serving debian-devel? fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: new kde package
Andreas Jellinghaus wrote: new debian versions of kde are available: beta2-2libc6 beta2-2.1 libc5 libc5 version is greater than libc6 ? That way dselect would automatically upgrade libc6 version with a libc5 based. if a beta2-1 libc6 exists, you should name the libc5 version -0.2 or better 0bo2, where the last number should match libc6 version. libc6 libc5 beta2-2 beta2-0bo2 beta2-3 beta2-0bo3 beta2-4 beta2-0bo4 Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: be careful with Replaces, please
Yann Dirson wrote: Greg Stark writes: We've got be be a little more careful with the Replaces header. I just installed the libc6 version of comerr, and dpkg helpfully deinstalled e2fsprogs. That's perfectly normal if you previously had e2fsprogs = 1.10-6, which does contain libcom_err ! Package: comerr2g Version: 1.10-8 Replaces: e2fsprogs, comerr2 (= 1.10-7) Depends: libc6 Conflicts: e2fsprogs, comerr2 (= 1.10-7) You should probably install e2fsprogsg to replace e2fsprogs. The behaviour you're wanting is provided by Replaces _without_ Conflits. Having listed e2fsprogs in the Conflicts, you're removing automatically it without forcing the install of the new e2fsprogsg. If you must Conflict with e2fsprogs, then you should add e2fsprogsg to the Depends to force installation of it (if it conflicts with its libc5 version, you don't need to Conflict with it). Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Future security problem (was Re: be careful with Replaces, please)
Christian Schwarz wrote: I suggest that we add a new control field to our packages called Origin: (or similar). This could either be set to SPI or Debian, for example. Then, all Debian packages should be signed with some PGP key (either only one key for the whole system or by the maintainer's key). dpkg could have its own keyring. Whenever dpkg installs a package, it checks the key against its keyring. If the key is not found in the keyring, dpkg stops installing (this can be overriden by some --force option). The default keyring would probably be the developers keyring. The sysadmin could then add new keys of persons/organziations which he/she trusts to that keyring. Comments? Just to repeat what we already said on a different list, with the actual scheme we have m packages signed by n developer's keys, but only one sign per package. On average, the number of keys to be revoked each year depends on the number of developers. Considering that users are installing from CD that are usually 3/4 months old (but this time we have a 6 month delay), so you can see how one developer key, which is privately handled by the developer, can be kept active as a trusted key because of all the packages signed with that key that are on all the CDs, even if the developer has leaved the project, maybe after a nasty flame (you see how this could easyly happen). He can maybe start signing his own packages with the same key he used on debian, and putting them on sunsite. Developers keys should be used only to make sure that the upload came from the developer in that very moment of the upload itself. To trust packages on a CD we need a scheme that woudn't be seriously affected by normal accidents in the life of the distribution. I proposed that a number of highly trusted people (senior developers, for example) create a certain number of _new_ keys that they will use (one per person) only to create detached certificates to distribute close to the packages. Three to five certificates per package would be enough. (detached because this way the certificates can be done in parallel, on different machines, and _not_ on some public host.) Then dpkg must check all the certificates of each package that it installs, and accept only those who have some level of trust (for example at least 3 out of five, or two out of three) maybe displaying warnings for different levels of trust (all user definible). Users then should be able to add keys from other people, but the keyring we supply should also contain some sort or keys-to-be-rejected, so we can add to that list the keys that we discover have been used to build trojan horses or such things. With this scheme the need to urgently revoke one key would have low possibility to happen, as dpkg could trust packages even when one key is compromised, because the possibility that _all_ keys from different _expert_ people (wo is more likely to follow all the rules for correct handling of private keys) would be compromised at the same time is quite close to zero. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E Just because Red Hat do it doesn't mean it's a good idea. [Ian J.] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Man-Db and Man both in Frozen???
John Goerzen wrote: Hi, There appears to be a package man in frozen that shouldn't be there since man-db is the new name for that package. Somebody needs to take it out; otherwise, it is confusing to users. John Where is it? I've just looked both in ftp.debian.org and in master, but man_ is only in rexx . Or maybe it has been just removed? Fabrizio -- +--+ | [EMAIL PROTECTED] [EMAIL PROTECTED] - Using Debian GNU/Linux ! | | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | La Liberta' non e' uno spazio libero, Liberta' e' partecipazione.[gg]| +--+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: May I remove a feature from man? [was: Bug#10039]
Bruce Perens wrote: From: Fabrizio Polacco [EMAIL PROTECTED] Bug#10039 exposed a problem with the feature of man to index all the 'man' and 'MAN' subdirectory it finds in the HOME and current directory, when it is invoked. Is this is consequence of your $MANPATH or is it in the man program? Well, the feature hardcoded in the program is that for each entry in the PATH, it looks for a man subdir and, if not already present in the MANPATH, index it. The code (which is ugly written IMO) has a bug with the entry for the current directory: if the PATH lists the current dir as the empty entry, all search is done using a null string (which does nothing), but if the current dir is listed as . , the dot is compared with the MANPATH entries (and fails because /usr/man != /usr/./man) I can easily correct the bug in two different ways: to make man searches the current dir even when the empty entry is used in PATH (and correct the compare with MANPATH) or remove the feature for the current directory. I would prefere the latter because I was really annoyed of it (had to remove all index.bt in clean: target of debian/rules). Anyway, the whole feature seems strange to me, because usually man hierarchies are at the same level of binary dirs, not under them. Is $HOME automaticaly in the MANPATH? If so, that's not bad. I was over-hasty in saying that (happens often on late evenings :-) because of a comment in the source code. But it is true if $HOME is in PATH. The current directory should not be in MANPATH and should not be indexed. Well, if someone put it in the MANPATH ... should man ignore it? Thanks, Fabrizio -- +--+ | [EMAIL PROTECTED] [EMAIL PROTECTED] - Using Debian GNU/Linux ! | | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | La Liberta' non e' uno spazio libero, Liberta' e' partecipazione.[gg]| +--+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
May I remove a feature from man? [was: Bug#10039]
Hi folks! Bug#10039 exposed a problem with the feature of man to index all the 'man' and 'MAN' subdirectory it finds in the HOME and current directory, when it is invoked. This feature is of incredibly annoyance because it leaves a file index.bt in those subdirectories. I think that many of you have encountered this when invoking man working in a source package to be debianized (dpkg-buildpackage fails because of the presence of such a binary file). I am tempted to remove such a feature from the sources (upstream development stopped in August 95), but I'm not sure if this could be a good idea. Does anyone find this feature usefull, or thinks that it must be kept in the program? Thank you, Fabrizio -- +--+ | [EMAIL PROTECTED] [EMAIL PROTECTED] - Using Debian GNU/Linux ! | | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E | La Liberta' non e' uno spazio libero, Liberta' e' partecipazione.[gg]| +--+ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: manpages depends on man?
David Frey wrote: And also, the /var/catman hierarchy cannot be purged although it is used only by man, because of the indexes and the subdirectories that are built in it after the installation. How can I tell to the man package that these are safe to be removed? Each package should purge it's own directories. So man has nothing to do with it. You could consider to run a mandb in the postrm script. The situation is complex: /var/catman is in the man package, but other packages add their subdirs and also mandb builds indexes thar aren't listed in the man package. If a user decide to purge man because he uses only xman or something new that will come, dpkg complains that /var/catman is not empty and doesn't remove the hierarchy. The user has no reason to purge the manpages, because he needs them. removing the /var/catman from man's postrm can solve this, but I think it will harm manpages that lists those dirs as installed. What if I build the /var/catman subdirs in the postinst of manpages (if man is installed) and remove all the /var/catman hierarchy in prerm of man? Only man uses the catman mechanism. My xman insists on reformatting the manpages, even if there are cached catman pages around... The xman program that comes in xcontrib doesn't understand locales. Should I raise a bug? Unsure about that. Yes? Maybe it's a configuration problem. What could I do, installing manpages, to let automatically xman find the pages in the new subdirs? Fabrizio -- +-+ | e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] | | http://megabaud.fi/~fpolacco/ Join the UKI Linux Project! | | fingerprint 70 1A 72 2D 2B C8 A5 63 7A C2 CC E0 2A 54 AE DA | | finger: [EMAIL PROTECTED][EMAIL PROTECTED] | +-+
Re: Size difference (big) between .orig.tar.gz and .deb: why?
Sven Rudolph wrote: [EMAIL PROTECTED] writes: What can explain this 72kb difference in size? I suppose the original packages tar file ontains the documentation files uncompressed whereas the .deb package installs these files as compressed. So they are compressed in one gzip run in the .tar.gz, whereas in the .deb case all files are compressed individually and then compressed again by dpkg --build. This makes the overall compression less efficient. I also experienced a 10% increase of the size in the manpages-it package. I was wandering if I could package the man pages uncompressed and compress them in debian/rules during installation. This would create a dependency to gzip package, but I think that this already exists when we package the pages zipped! Is it possible that a debian system be without gzip? ciao Fabrizio -- +-+ | e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] | | http://megabaud.fi/~fpolacco/ Join the UKI Linux Project! | | fingerprint 70 1A 72 2D 2B C8 A5 63 7A C2 CC E0 2A 54 AE DA | | finger: [EMAIL PROTECTED][EMAIL PROTECTED] | +-+
manpages depends on man?
Hei! I have some problems in packaging the italian manpages, and I would like to hear your suggestion. I'm sorry, it's a lot of stuff, but I'm new ... I hope that these are not old questions. I have created the package following what joey has done with german and spanish ones, including suggesting the user to modify /etc/manpath.config Now I want to add a rule to make this simple update automatically. The file /etc/manpath.config belongs to package man. Is there any constraint against doing this automatic update from another package? The man package also builds the /var/catman hierarchy to store indexes and formatted pages. Formatted pages in other languages will not be cached if you don't create a complete hierarchy under /var/catman/locale or any other dirpath used in /etc/manpath.config Do you think I should add this hierarchy to the package? And what do you think I should do if the man package is not yet installed? (ignore the error|complain|create a dependency) And also, the /var/catman hierarchy cannot be purged although it is used only by man, because of the indexes and the subdirectories that are built in it after the installation. How can I tell to the man package that these are safe to be removed? Anyway also the man package should do this (for the indexes). Could it be worth to split the man package creating a new one for the catman (later cache, when Quinlan will release HFS) and create appropriate dependencies to it? The xman program that comes in xcontrib doesn't understand locales. Should I raise a bug? ciao Fabrizio -- +-+ | e-mail: [EMAIL PROTECTED][EMAIL PROTECTED] | | http://megabaud.fi/~fpolacco/ Join the UKI Linux Project! | | fingerprint 70 1A 72 2D 2B C8 A5 63 7A C2 CC E0 2A 54 AE DA | | finger: [EMAIL PROTECTED][EMAIL PROTECTED] | +-+
