Bug#1063793: ITP: libstring-interpolate-named-perl -- Interpolated named arguments in string
Package: wnpp Owner: Roland Rosenfeld Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libstring-interpolate-named-perl Version : 1.03 Upstream Author : Johan Vromans * URL : https://metacpan.org/release/String-Interpolate-Named * License : Artistic or GPL-1+ Programming Lang: Perl Description : Interpolated named arguments in string String::Interpolate::Named provides a function to interpolate named arguments by target texts in a template string. The target texts are provided to the function via a hash, where the keys correspond to the named argument to be replaced, or a subroutine that performs the lookup. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1063794: ITP: chordpro -- lyrics and chords formatting program
Package: wnpp Owner: Roland Rosenfeld Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: chordpro Version : 6.050 Upstream Author : Johan Vromans * URL : https://www.chordpro.org/ * License : Artistic or GPL-1+ Programming Lang: FIXME Description : lyrics and chords formatting program ChordPro will read one or more text files containing the lyrics of one or many songs plus chord information. chordpro will then generate a photo-ready, professional looking, impress-your-friends sheet-music suitable for printing on your nearest printer. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1063792: ITP: libtext-layout-perl -- Pango style markup formatting
Package: wnpp Owner: Roland Rosenfeld Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtext-layout-perl Version : 0.032 Upstream Author : Johan Vromans * URL : https://metacpan.org/release/Text-Layout * License : Artistic or GPL-1+ Programming Lang: Perl Description : Pango style markup formatting Text::Layout provides methods for Pango style text formatting. Where possible the methods have identical names and (near) identical behavior as their Pango counterparts. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1063791: ITP: libfile-loadlines-perl -- Load lines from files and network
Package: wnpp Owner: Roland Rosenfeld Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libfile-loadlines-perl Version : 1.045 Upstream Author : Johan Vromans * URL : https://metacpan.org/release/File-LoadLines * License : Artistic or GPL-1+ Programming Lang: Perl Description : Load lines from files and network File::LoadLines provides an easy way to load the contents of a text file into an array of lines. It is intended for small to moderate size files like config files that are often produced by weird tools (and users). It will transparantly fetch data from the network if the provided file name is a URL. File::LoadLines automatically handles ASCII, Latin-1 and UTF-8 text. When the file has a BOM, it handles UTF-8, UTF-16 LE and BE, and UTF-32 LE and BE. Recognized line terminators are NL (Unix, Linux), CRLF (DOS, Windows) and CR (Mac) -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1063790: ITP: libjavascript-quickjs-perl -- Run JavaScript via QuickJS in Perl
Package: wnpp Owner: Roland Rosenfeld Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libjavascript-quickjs-perl Version : 0.19 Upstream Author : Felipe Gasper (FELIPE) * URL : https://metacpan.org/release/JavaScript-QuickJS * License : Artistic or GPL-1+ Programming Lang: Perl Description : Run JavaScript via QuickJS in Perl JavaScript::QuickJS embeds Fabrice BellardâÂÂs QuickJS engine into a Perl XS module. You can thus run JavaScript directly in your Perl programs. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1058490: ITP: libdbd-multi-perl -- failover and load balancing of DBI handles
Package: wnpp Severity: wishlist Owner: Roland Rosenfeld X-Debbugs-Cc: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libdbd-multi-perl Version : 1.02 Upstream Author : Dan Wright * URL : https://metacpan.org/release/DBD-Multi * License : Artistic or GPL-1+ Programming Lang: Perl Description : failover and load balancing of DBI handles DBD::Multi manages multiple database connections for failovers and also simple load balancing. It acts as a proxy between your code and your database connections, transparently choosing a connection for each query, based on your preferences and present availability of the DB server. DBD::Multi is intended for read-only operations (where some other application is being used to handle replication). The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#912407: ITP: mailfromd -- General-Purpose Mail Filter
Package: wnpp Severity: wishlist Owner: Roland Rosenfeld * Package name: mailfromd Version : 8.6 Upstream Author : Sergey Poznyakoff * URL : https://puszcza.gnu.org.ua/software/mailfromd/ * License : GPL Programming Lang: C Description : General-Purpose Mail Filter Mailfromd is a general-purpose mail filtering daemon. It is able to interact with any MTA that supports milter or pmilter protocol, such as Sendmail, Postfix and MeTA1. It is able to filter both incoming and outgoing messages using criteria of arbitrary complexity, supplied by the administrator in the form of a script file. (Include the long description here.) I use this program in my job and like to have a package there, so I can publish it for others, too. I'll maintain it as all my packages in salsa. signature.asc Description: PGP signature
Re: apparently-corrupted-elf-binary lintian problems on recent sid and amd64
Enrico Zini <[EMAIL PROTECTED]> wrote: > I have a package that built fine in June 2006 but when I rebuild it > now in my up to date pbuilder sid chroot gives me the lintian error > "apparently-corrupted-elf-binary". I noticed the same problem here with several packages. The problem seems to be lintian on a etch system in combination with amd64. Everything is okay when I compile on my etch amd64 system or on my sid i386 system. When I use the i386 sid pbuilder the packages are okay, too. But when I use pbuilder amd64 sid, the packages seem to be broken: W: xfig: apparently-corrupted-elf-binary ./usr/bin/xfig E: xfig: statically-linked-binary ./usr/bin/xfig If I run the etch objdump on the sid compiled binary I get: $ objdump -T /tmp/xfig objdump: /tmp/xfig: File format not recognized So I entered the pbuilder amd64 sid chroot and there objdump -T works correct. I installed lintian in the chroot and it doesn't return any error. So amd64 etch objdump doesn't seem to be compatible with amd64 sid compiled binaries. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: allow new upstream into stable when it's the only way to fix security issues.
W. Borgert <[EMAIL PROTECTED]> wrote: >> (1) keep vulnerable packages in stable, >> (2) remove affected packages from distribution, >> (3) allow new upstream into stable. > I'ld "vote" for (2), maybe with the goal of creating pressure > towards upstream to take security more serious. But how do you push the users to remove the package from their systems? In reality they will keep the broken version installed and so you have (1) again :-( Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No german umlauts in console and xterm
Florian Hinzmann <[EMAIL PROTECTED]> wrote: > I tried to fix an old problem with my Debian system (woody) > today, but failed. An old problem with a quite old answer: German-HOWTO You'll find this in doc-linux-text and doc-linux-html packages. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: strange behavior of dh_dhelp
Marco Budde <[EMAIL PROTECTED]> wrote: > Ok, then Debian 2.2 will be broken. No. There are not many packages which quickly switched to /usr/share/doc without the symlinks. The maintainers of these packages quickly changed, so they are alive and the should be able to add the symlink to their next versions of the packages as quickly as they uploaded before. So why should 2.2 be broken? Potato _is_ broken at the moment, but this can be fixed. > And the next releases will have the same problems, because we still > allow policy 2.4 packages without any symlinks. The next (potato+1) requires all documentation in /usr/share/doc _and_ Symlinks in /usr/doc. > So it won#t be possible to install Debian 2.2 and 2.3 packages on > one system with a working documentation. So there is no problem with 2.2+2.3. Then 2.4 will remove the symlinks but now all packages from 2.3 placed their docs in /usr/share/doc, so you can use packages from 2.3+2.4 together with all docs in /usr/share/docs. > Wrong. Symlinks don#t work with http. What does the HTTP protocol have to do with the Unix file system? It depends on the HTTP server, whether it follows symlinks or not. Apache handles this without problems for ages and FollowSymlinks is activated in the default configuration for /usr/doc. I think that other HTTP servers will do the same, and if one doesn't do so, it's more likely that they support to follow symlinks instead of _not_ to follow symlinks. BTW: I think that it is a bug, if an HTTP server isn't configurable in this case. And don't forget that we already have many symlinks in /usr/doc for ages, which are explicitly allowed by policy: /usr/share/doc/ may be a symbolic link to a directory in /usr/share/doc only if two packages both come from the same source and the first package has a "Depends" relationship on the second. These rules are important because copyrights must be extractable by mechanical means. > If you ask me: > (1) All packages of Debian 2.2 must use /usr/share/doc. Then the release date of 2.2 will be at the end of 2000 or later. That's simply unrealistic. If you personally want to upload 2000 NMUs (for each architecture!), this may be able sooner, but > Otherwise we will have the same problems in Debian 2.3, when > the user reads the documentation via /usr/share/doc. No. Read the time table above or in one of my last mails. > (2) All packages provides /usr/doc links. That's right for 2.2 and 2.3. > (3) http://localhost/doc/ points to /usr/share/doc, the user > use /usr/share/doc instead of /usr/doc. That's wrong. http://localhost/doc/ points to /usr/doc in 2.2 and 2.3. This will change in 2.4. > This is a clean solution It is clean if all Debian maintainers update all their packages in all architectures and if every user upgrades the complete system from 2.1 to 2.2 and not only parts. If you cannot be sure that these requirements are resolved, it is not clean. > and not such a hack like the descripted decision. Yes, the decision is a hack. But it works and offers a smooth transition. We have to release potato soon (slink is very old and our users want a new release, otherwise the may use a different distribution) and potato should be as consistent as possible. The hack gives us a consistent potato (all doc available via /usr/doc), your proposal does not. Anyway, the decision was made, like it or hate it but stop discussing it again and again. This doesn't help and won't change anything. Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
On Wed, 29 Sep 1999, Peter S Galbraith wrote: > Your example implies that doc-base's install-docs is at fault for > creating files under either /usr/doc/HTML or /usr/share/doc/HTML > instead of files in a single place, with a /usr/doc/HTML -> > /usr/share/doc/HTML symlink. Am I correct? Or did I miss something? As far as I see, you are talking about the dhelp support in doc-base. This is done in two steps: 1. convert the doc-base file to a .dhelp file. While the doc-base file uses a full path, the .dhelp file doesn't include a path. 2. add the documentation defined in the .dhelp file to the indexes in HTML using dhelp_parse. It shouldn't be a big problem, to add such a .dhelp file to the /usr/doc/HTML index, but dhelp doesn't support this at the moment, when called with /usr/share/doc//.dhelp. Another problem in combination with this is, that dhelp_parse scans all directories under /usr/share/doc (dhelp_parse_fsstnd does the same for /usr/doc), but both programs don't follow symlinks, which is a problem, because symlinks from /usr/doc/ to /usr/share/doc/ should be followed... > In that case, shouldn't the bug go against doc-base? The problem is somewhere between doc-base and dhelp, but both authors doesn't seem to have much interest in solving it... Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
On Wed, 29 Sep 1999, Daniel Burrows wrote: > > > This may work sometimes but not always -> hack. > > ctte decided, that this has always to work. If it doesn't, this > > is a bug in the package. > I assume that I can't start filing bugs against the ~116 packages > on my system (eg, libc6) that moved to /usr/share/doc without > leaving a symlink behind until this becomes part of policy. Any > idea how long that'll be? No idea. But have a look at http://www.debian.org/Bugs/db/45/45561.html, there is consensus about the change, it seems that it only has to be formulated and uploaded. I just filed a proposal for the text. Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
Marco Budde <[EMAIL PROTECTED]> wrote: > ROTFL, why should I change dhelp to support a broken file format? Can you give a short summary where the doc-base format is broken? Sorry, I didn't read debian-doc so I didn't know what the problem is. > Please tell me what for do we need doc-base? We need a file format > and not a converter! As far as I can see, the doc-base format described in /usr/doc/doc-base/doc-base.html/ch2.html#s2.1 is a file format. Okay, it could be specified more accurate, but it seems that most people understand what is meant (on my system I find 2 packages supporting dwww and dhelp directly, 7 packages supporting dhelp only, 17 packages supporting dwww only, and a great majority of 64 packages supporting doc-base). So the package maintainers have spoken: doc-base is an accepted "standard". > Of course the first solution is a lot of better. But how should we > solve problems when the authors are not interested to find one file > format :(? That's a bad situation, sure. Maybe you could write an alternate documentation and offer it to debian-policy? I think, that the policy should define the "official" format. The actual situation is somewhat problematic, because everybody does what he personally prefers. That's why doc-book (the only definition, which looks like a standard) is used as the standard. > Why is doc-base a generic format? It#s as generic as the dhelp/dwww > formats. doc-base supports other formats than HTML. > In fact the format has got a lot of disadvantages. What explicitly? > RR> > Why is dhelp broken? > RR> Because it doesn't support /usr/doc symlinks in the /usr/doc > RR> tree when the .dhelp file (created by a doc-base file) mentions > RR> the real (/usr/share/doc) path. > Example, please. Take xfig-doc. This package comes with documentation in /usr/share/doc/xfig-doc/html/ and a symlink /usr/doc/xfig-doc pointing to /usr/share/xfig-doc. /usr/share/doc-base/xfig-doc says: Document: xfig-doc Title: XFIG Users Manual Author: T.Sato and Brian V. Smith Abstract: This manual explains the interactive drawing tool xfig, which runs under the X Window System. It explains how to start and use xfig, helps you with some examples and informs you about the technical issues of this program. Section: Graphics Format: html Index: /usr/share/doc/xfig-doc/html/index.html Files: /usr/share/doc/xfig-doc/html/*.html This creates the following /usr/share/doc/xfig-doc/html/.dhelp: graphics XFIG Users Manual index.html This manual explains the interactive drawing tool xfig, which runs under the X Window System. It explains how to start and use xfig, helps you with some examples and informs you about the technical issues of this program. And adds this document to /usr/share/doc/HTML/graphics/index.html: XFIG Users Manual This manual explains the interactive drawing tool xfig, which runs under the X Window System. It explains how to start and use xfig, helps you with some examples and informs you about the technical issues of this program. But it doesn't add the document to /usr/doc/HTML/graphics/index.html which is the primary documentation path for potato (according to ctte). > RR> Why do you mix the speed of install-docs and dwww here? > Because install-docs slows down the speed of dhelp :(. What speed are you talking about: speed of installation or speed of browsing? > RR> > Because some authors are not interested to solve problems > RR> > :(. We don#t need something like doc-base. > RR> When I read the second sentence, it seems that you're talking > RR> about yourself in the first one =;-) > Why? What for do we need doc-base? I'm not sure, whether we need doc-base or any similar format, but doc-base is there, and most packages use it. So I don't see why we should stop using it now. You can see on /usr/share/doc which problems are implied by changing standards, so if you want to change from doc-base to something other, give us a smooth migration way first. > RR> So why not use doc-base as this one file format? > Why? doc-base has been developed later that dhelp/dwww So why use dhelp, it was developed later than dwww. This is no argument. > and it#s useless. It is heavily used. So it isn't completely useless. > So why should we move to it#s file format? This makes no sense. Maybe you missed the facts. We already moved to doc-base format, so if you don't like it, you have to give us a way to move to some different format now. Maybe it was a fault to change to doc-base, but that's history. If you want to change this now, you have to give use some migration path. > RR> As far as I can see doc-base is a little bit more flexible than > RR> dhelp (the latter only supports HTML and no other > dhelp supports all formats. I cannot see this in /usr/share/doc/dhelp/dhelp.html. There you are only talking about HTML: This short text appears as link text in the index. This is typical the filenam
Re: strange behavior of dh_dhelp
Marco Budde <[EMAIL PROTECTED]> wrote: > RR> It is always a good idea to use a generic format which can > RR> automatically converted to all useful formats instead of using > RR> one special format. > No, sorry, but this is wrong. Why should we convert files during the > installation process? There#re two better solutions: 1) All programs use > the same file format. Okay, simply change dhelp to use the doc-base directly and were are done. > 2) You can convert the files during dpkg-buildpackage offline. That's a bad idea, because this restricts you from adding new documentation systems which use another new format. Have a look how many packages still only support dwww and not dhelp. So you see, that creating these files at build time is a bad idea, while using a generic format like doc-base is much more flexible, because you only have to extend install-docs to support new formats and you're done (okay when installing the new documentation system the first time, you will have to run the new install-docs for all existing doc-base files once, but this shouldn't be a problem). > RR> documentation system next to dwww and dhelp (both are horribly > RR> broken at the moment, so another one may be a good idea) without > RR> changing all the packages. > Why is dhelp broken? Because it doesn't support /usr/doc symlinks in the /usr/doc tree when the .dhelp file (created by a doc-base file) mentions the real (/usr/share/doc) path. > RR> If you think, that install-docs is too slow and dhelp-parse in > One reason to write dhelp was the speed of dwww. Why do you mix the speed of install-docs and dwww here? The first one is run at install time, while the latter one is run at documentation browsing. As far as I can see one has nothing to do with the other. > RR> combination with dhelp2dwww.pl is so much faster, why don't you > RR> simply rewrite install-docs in C? Then we have a generic and > RR> fast solution. > Because some authors are not interested to solve problems :(. We > don#t need something like doc-base. When I read the second sentence, it seems that you're talking about yourself in the first one =;-) > We need only a small shell script, that calls dwww and > dhelp_parse. And we need *one* file format for dwww and dhelp. So why not use doc-base as this one file format? All file formats (doc-base, dhelp, menu,...) will have advantages and disadvantages. As far as I can see doc-base is a little bit more flexible than dhelp (the latter only supports HTML and no other formats) and doc-base is widely used and supported by debhelper and dh_make for a long time now. So doc-base may be a good compromise as the "one file format". > RR> I just installed it, but as far as I can see this doesn't > RR> integrate FHS and FSSTND > Right, because this is not possible. I think that it is possible, proposed that all packages which use only /usr/share/doc at the moment, will soon add a symlink in /usr/doc, to follow the technical committee decision. Than you only have to support /usr/doc with one problem: the doc-base and .dhelp files point to the real location in /usr/share/doc, while the files are also accessible via the symlink as /usr/doc/. There needs to be some work around for this, but this should be possible with some Perl or Shell knowledge. > There#s no solution for this problem, because dhelp supports reading > documents via the local file system and via the http protocol. No problem when you see /usr/doc as the one and only directory for accessing the files. The documentation of every package should be available as /usr/doc/ in potato (this will change in the far future, but now we are working on potato). > RR> possible for most packages, because the tech-ctte decided that every > Were can I read this? In the debian-ctte and debian-policy mailing lists and in the Debian weekly news as of September 7th, 1999: The technical committee has [8]spoken: /usr/doc/ will be provided as a symlink in FHS compliant packages. This started an avalanche of updated, FHS compliant packages. For implementation details, see [9]this message (debhelper will handle most of this automatically). 8. http://www.debian.org/Lists-Archives/debian-ctte-9909/msg00023.html 9. http://www.debian.org/Lists-Archives/debian-ctte-9908/msg00038.html > I#ve found nothing about this in the latest policy. The policy 3.0.1 is broken in this point. It was a fault to change the complete policy to FHS without thinking about how to handle the migration from /usr/doc to /usr/share/doc. We couldn't find a compromise in debian-policy so the technical committee had to decide and they decided to create a farm of symlinks in /usr/doc to make every package documentation available as /usr/doc/ in potato. The symlinks have to be created and deleted by postinst and prerm, because otherwise dpkg will have problems with this. We are all waiting for the new policy, which will realize this decision. Maybe you noticed, that
Re: strange behavior of dh_dhelp
On Mon, 27 Sep 1999, Peter S Galbraith wrote:
> > There were some rumors, that Apache would be able to handle both
> > directories as http://localhost/doc/ (use /usr/share/doc/ and
> > if the file/directory isn't available fall back to
> > /usr/doc/), but I don't know enough about Apache to realize
> > this myself and I didn't see an example how to do this, so it
> > seems to be only a rumor but not reality :-(
> Have you tried the mod_rewrite solution posted late in July?
It seems that I missed this. But I found it in the archive and it
works really great now. Maybe others have the same problem, so here's
the solution again (with /usr/doc as the primary directory and
/usr/share/doc the secondary, which I prefer):
In httpd.conf:
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
In srm.conf:
RewriteEngine on
# For requested files beginning with /doc/, try looking for the
# document in /usr/doc.
RewriteCond %{REQUEST_FILENAME} ^/doc/
RewriteCond /usr%{REQUEST_FILENAME} -f [OR]
RewriteCond /usr%{REQUEST_FILENAME} -d [OR]
RewriteCond /usr%{REQUEST_FILENAME} -l
RewriteRule ^(.+) /usr$1 [L]
# Next, try looking for the document in /usr/share/doc.
RewriteCond %{REQUEST_FILENAME} ^/doc/
RewriteCond /usr/share%{REQUEST_FILENAME} -f [OR]
RewriteCond /usr/share%{REQUEST_FILENAME} -d [OR]
RewriteCond /usr/share%{REQUEST_FILENAME} -l
RewriteRule ^(.+) /usr/share$1 [L]
# Attempt to deal with directory listings.
RewriteCond %{REQUEST_FILENAME} ^/doc/?$
# Just list /usr/doc for now.
RewriteRule ^(.+) /usr/doc/ [L]
# Neither worked. Just pass through to do whatever we would have
# done before.
RewriteRule ^(.+) - [PT]
# mod_rewrite isn't available, so fallback to a simple Alias.
Alias /doc/ /usr/doc/
Maybe this should be added to the defaults of apacheconfig
(/usr/share/doc/apache/examples/*)?
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
On Mon, 27 Sep 1999, Peter S Galbraith wrote: > > > P.S.: The latest dhelp 0.3.14 supports FHS *and* FSSTND :). > > I just installed it, but as far as I can see this doesn't > > integrate FHS and FSSTND in any way but creates two completely > > incompatible trees one next to the other. Now I can read parts of > > the documentation as http://localhost/doc/ (which points to > > /usr/doc/) and others as http://localhost/fhs/ (which points to > > /usr/share/doc/). > I have a recent potato install and dhelp 0.3.14 and _don't_ have > http://localhost/fhs/ support. Simply add Alias /fhs/ /usr/share/doc/ to /etc/apache/srm.conf and you will have it. I added this line by hand, too. Yes, I know that this isn't an elegant solution, but it seems to be the only way to access both directories. There were some rumors, that Apache would be able to handle both directories as http://localhost/doc/ (use /usr/share/doc/ and if the file/directory isn't available fall back to /usr/doc/), but I don't know enough about Apache to realize this myself and I didn't see an example how to do this, so it seems to be only a rumor but not reality :-( > Am I doing anything wrong? That's what I also am asking myself when I see dhelp, but I fear, that dhelp is simply broken and that's the secret behind all these problems. > [I also agree that it would be annoying to have two distint > directories to point a browser at (if it worked at all for me).] That's why we should simply follow the tech-ctte and make all documentation available as /usr/doc/ where /usr/doc/ may be a symlink to /usr/share/doc/. But dhelp doesn't support these symlinks at the moment, as far as I can see. Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
ITP: xcut
Source: xcut
Section: x11
Priority: optional
Maintainer: Roland Rosenfeld <[EMAIL PROTECTED]>
Standards-Version: 3.0.1
Package: xcut
Architecture: any
Depends: ${shlibs:Depends}
Description: Manipulate X cut buffers from command line
xcut is a small but useful program which can take standard input and
store it in the X cut buffer, and also work in reverse by writing the
X cut buffer onto standard output.
There is a homepage of this program at
http://acsys.anu.edu.au/~tpot/xcut/, it is under GPL.
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: strange behavior of dh_dhelp
Marco Budde <[EMAIL PROTECTED]> wrote: > Why? What is the advantage of using doc-base? You may want to read the documentation of doc-base... It is always a good idea to use a generic format which can automatically converted to all useful formats instead of using one special format. doc-base gives us the chance to add some other documentation system next to dwww and dhelp (both are horribly broken at the moment, so another one may be a good idea) without changing all the packages. If you think, that install-docs is too slow and dhelp-parse in combination with dhelp2dwww.pl is so much faster, why don't you simply rewrite install-docs in C? Then we have a generic and fast solution. > P.S.: The latest dhelp 0.3.14 supports FHS *and* FSSTND :). I just installed it, but as far as I can see this doesn't integrate FHS and FSSTND in any way but creates two completely incompatible trees one next to the other. Now I can read parts of the documentation as http://localhost/doc/ (which points to /usr/doc/) and others as http://localhost/fhs/ (which points to /usr/share/doc/). But I would prefer these two trees to be merged. This should be possible for most packages, because the tech-ctte decided that every package that uses /usr/share/doc/ has to create a symlink /usr/doc/ pointing to /usr/share/doc/. So all documentation should be available as /usr/doc/. The only problem is, that dhelp doesn't support those links at the moment. My packages which follow the tech-ctte decision (using debhelper and dh_installdocs) are only visible in http://localhost/fhs/HTML/ but not in http://localhost/doc/HTML/. In the past we had two places where the user had to look for documentation on programs: http://localhost/doc/HTML/ and http://localhost/dwww/menu.html You new version of dhelp splits this to three places: http://localhost/doc/HTML/, http://localhost/fhs/HTML/ and http://localhost/dwww/menu.html and all three include different doc, see for example section graphics: - Sketch User's Guide dhelp/FHS dwww - Sketch Developer's Guide dwww - Imlib Programmer's Guide dhelp/FHS dwww - XFIG User Manual dhelp/FHS dwww - TIFF Software dhelp/FSSTND - pstoeditdhelp/FSSTND Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: Too many kernels in unstable
Herbert Xu <[EMAIL PROTECTED]> wrote:
>> Maybe I don't see all the problems, but why don't we name the packages
>> kernel-{doc,headers,image,source}-2.0 2.0.38-
>> kernel-{doc,headers,image,source}-2.2 2.2.12-
> This stops people from having multiple versions of 2.? kernels installed.
Ooops, you're right. Please forget my above proposal. I still hate
this package name inflation, but there seems to be no way around it :-(
Tscho
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: Too many kernels in unstable
On Fri, 17 Sep 1999, Edward Betts wrote:
> My suggestion would be:
>
> kernel-{doc,headers,image,source}-2.0.38
> kernel-{doc,headers,image,source}-2.2.12
>
> Can anybody provide arguements against just having two kernels?
Maybe I don't see all the problems, but why don't we name the packages
kernel-{doc,headers,image,source}-2.0 2.0.38-
kernel-{doc,headers,image,source}-2.2 2.2.12-
which would reduce the effort of the ftp maintainer and speed up
upgrading our ftp archive from 2.2.12 to 2.2.13. The dependencies
between the kernels and the kernel depending modules could be realized
using versioned dependencies, couldn't they?
Maybe we should add an unstable kernel to the stable versions above:
kernel-{doc,headers,image,source}-2.3 2.3.18-
Ciao
Roland
--
* [EMAIL PROTECTED] * http://www.spinnaker.de/ *
PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Intend to package: gsfonts-x11
Package: gsfonts-x11 Priority: optional Section: x11 Maintainer: Roland Rosenfeld <[EMAIL PROTECTED]> Version: 0.1 Depends: gsfonts, xbase-clients Description: Make Ghostscript fonts available to X11. This packages makes the 35 Postscript fonts from the gsfonts package available to your X server under their "urw" names and via fonts.alias with the official "adobe" names, too. . This package does not contain any fonts itself but allows to reuse the ghostscript fonts as X11 screen fonts. There was always the problem, that the graphics program xfig needs some X11 fonts to represent the postscript fonts, which are used when printing. At the moment this uses the 75dpi or 100dpi screen fonts, but there are some of the standard postscript fonts missing and the pixel fonts aren't available for big font sizes. I think that the above package is a good way to make the ghostscript fonts available for xfig and other package which need scalable screen fonts (for example xpdf and others). Tscho Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: Packages to give away
On Sun, 09 May 1999, Edward Betts wrote: > xfig and transfig maintainer here. > I am not really sure what the question is, but as the poster points > out, there are unfixed bugs for xfig and transfig. I have exams > coming up (it is that time of year again). I can work on Debian > after June, but I am going to have to leave it for now. > I am afraid that xfig and transfig are not really the right packages > for me. I hardly use X anymore, and I do not know enough X code to > understand all of the xfig code. > So if somebody wants theses packages they can have them. On a side > note, somebody is working on a portuguese translation of xfig. I don't really "want" them (I also don't know much about X internals and I'm writing on my diploma thesis, which reduces my available time very much), but I regularly use xfig, so I could take this over, if nobody else volunteers. But I cannot promise to close all bug reports in the next days. I had a look at the list and there are some, which can be closed or simply fixed, but there are many others, which aren't trivial to reproduce or which should be forwarded to the upstream author (after checking, that they aren't fixed already by the actual upstream versions). Ciao Roland -- * [EMAIL PROTECTED] * http://www.spinnaker.de/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF pgpxJ6rXh2WD2.pgp Description: PGP signature
Re: bug? with file-rc
Jonathan P Tomer <[EMAIL PROTECTED]> wrote: > ii file-rc 0.4.3 Alternative one-configfile boot mechanism This version has many errors, some of them are fixed in the actual 0.4.7. > i don't know if this is supposed to be the case or not, but contrary > to file-rc's documentation, scripts are not run in reverse order for > shutting down. is this a debian-specific thing or merely a bug? file-rc is based on a program (nowadays called r2d2) written by Winfried Trümper. This program run the "stop" scripts in reverse order. But this isn't the way, rc from sysvinit works and file-rc should be fully compatible to sysvinit-rc. Because of this someone patched file-rc not to stop the scripts in reverse order but to insert two lines (using update-rc.d) into runlevel.conf, one that starts the process and another one that stops it. The file is always read from top to bottom. It seems that /usr/doc/file-rc/README.gz is simply copied from Winfrieds original program and the person who patched it for debian didn't change this README. > are the etc/rcN.d/Kmm* scripts run in descending order when file-rc > is not used? No, they are run in ascending order as well as the runlevel.conf is always run top down. > i find it rather strange, especially since not reversing shutdown > scripts makes it necessary to double the number of lines in > /etc/runlevel.conf (and have the numbers of start/stop links in > /etc/rcN.d differ) in those cases where order does matter. I fully agree with you! I asked what other people think about this some weeks ago, but the only answer I got was a cry for "compatibility" and the variant with stopping in reverse order is not 100% compatible to sysvinit-rc... So at the moment (0.4.7) we have a file-rc which isn't as elegant as the original file-rc/r2d2 but which should be compatible to sysvinit-rc. If someone (like you and me) wants a more elegant, but incompatible variant, it may be a good idea to create another package (for example with the name r2d2) which has status "eXtra" and presents a big warning on install that update-rc.d will behave not exactly like the one of sysvinit and as it is described in the policy (see section 3.3). Tscho Roland -- * [EMAIL PROTECTED] * http://www.rhein.de/~roland/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Intent to package bsmtpd
BSMTP mailer for Sendmail completely written in C This package supplies a new "mailer" to sendmail, which allows to use batched SMTP a protocol. BSMTP is used in UUCP environments and allows to transport many mails as a (compressed) batch instead of transporting every single mail. So bsmtp is an alternative to rmail. Special features of this sendmail bsmtp version: - Completely written in C. - Configurable batch size (automatically sends batch to uux when a defined size is reached). - Creates backups of all outgoing batches (and removes them regularly) The author told me, that the program stands under the GPL. Ciao Roland -- * [EMAIL PROTECTED] * http://www.rhein.de/~roland/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: No intend to package vbox
Paul Slootman <[EMAIL PROTECTED]> wrote: > I'm planning to split up isdnutils sometime into separate parts; > there are many sites where for example vbox isn't used at all, so > having it installed isn't useful. Sound reasonable. > isdnvbox vbox Hmmm, maybe this should be split into two packages, the vboxgetty and vboxd on the one hand and the vbox client on the other hand. What I want to say is, that there should be some chance to install only the vbox client on a machine without the need to install a complete isdn subsystem. Tscho Roland -- * [EMAIL PROTECTED] * http://www.rhein.de/~roland/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: No intend to package vbox
Martin Schulze <[EMAIL PROTECTED]> wrote: >> here at work we are going to use vbox. Since there is no Debian >> package already I wonder if somebody has interest in packaging it. >> I don't feel much interest but need for it so I would appreciate if >> s/o else would step forward. > As Ruud reminded me isdnutils contains a vbox, but a quite old > version. What we need is vbox 2 beta 4. As far as I can see isdnutils-3.0-8 includes vbox 2.0.0 beta 5, which is a little bit newer than vbox 2 beta 4 with the following changes: | ** | Changes since 2.0.0 Beta 4 | ** | | 31-Mar-98 | = | | [Rel] 2.0.0 beta 5 released. | | 26-Mar-98 | = | | [New] src/libvbox.h | src/modem.c | src/modem.h | src/voice.c | src/voice.h | src/vbox.c | |SUSPEND support for newer Hisax (only 2.1.X kernel in the moment) > PS: It seems to be included in SuSE 5.2 And it is included in Debian 2.1 ;-) Tscho Roland -- * [EMAIL PROTECTED] * http://www.rhein.de/~roland/ * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Re: moving mutt-i from non-us to main
Alexander Koch <[EMAIL PROTECTED]> wrote: > Some time ago (can't remember any version numbers) the PGP version > was hacked by Thomas Roessler <[EMAIL PROTECTED]> right after the > normal version came out. > Right now Michael Elkins has a job enslaving (sp?) him to use a > Mickeysoft OS any he doesn't have the time for much of the former > codings any more. > Thomas Roessler is the keeper of the source at the moment. I don't understand, what the Author (Michael Elkins) or the current Maintainer of the upstream version (Thomas Roessler) have to do with us (Debian) offering their program on our US ftp servers. IMHO only those people are responsible for export from US to the free world, who put it on the FTP servers without restriction. So if a Debian mutt in main is illegal according to US law, than Debian (or the owner of the FTP servers) are responsible, not the author of the program. It's another question, whether exporting a program, with simply calls pgp (and parses the PGP keyring), breaks the US exporting laws. When we mean, that this is illegal, we should move dpkg-buildpackage to non-US, because this calls pgp, too... Tscho Roland -- * Internet: [EMAIL PROTECTED] * Fido: 2:2450/42 * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Intend to package: memstat
memstat - Identify what's using up virtual memory. memstat lists all the processes, executables, and shared libraries that are using up virtual memory.
Intend to package: lbdb
I intend to pack the Little Brother's Database package, an add-on for the Mutt mail reader which collects mail addresses of received mails and offers these addresses, the output of the finger command etc. to Mutt's external query feature. Tscho Roland -- * Internet: [EMAIL PROTECTED] * Fido: 2:2450/42 * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
Intend to package emil
Emil v2 is a filter for converting Internet Messages. It supports three basic formats: MIME, SUN Mailtool and plain old style RFC822. It can be used with sendmail, as a mailer, or as a prefilter or backend program with a mail client program, or as a plain filter. Source can be found at ftp://ftp.uu.se/pub/unix/networking/mail/emil/emil-2.1.0-beta9.tar.gz Tscho Roland -- * Internet: [EMAIL PROTECTED] * Fido: 2:2450/42 * PGP: 1024/DD08DD6D 2D E7 CC DE D5 8D 78 BE 3C A0 A4 F1 4B 09 CE AF
