Bug#669041: dhelp: 404 Not Found
On Mon, 16 Apr 2012 19:41:35 +0200, A. Costa agco...@gis.net wrote: Package: dhelp Version: 0.6.20 Severity: normal Dear Maintainer, Plain old 'httpd' dependent 'dhelp' isn't working on my system. When run, 'dhelp' launches a browser, which says: 404 Not Found doc/HTML/index.html: This item has not been found 'dhelp -f' works correctly. My current web server 'bozohttpd' works correctly with 'dwww'; but perhaps bozo dhelp don't get along? May be. I thought that, by default, all scripts under /usr/lib/cgi-bin should work out of the box with any web server supporting CGIs (which seems to be the case for bozohttpd). Or maybe it's a different problem. What's the URL in the browser when the above error message is shown? -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650438: O: libcommandline-ruby -- Transitional package for ruby-commandline
Package: wnpp Severity: normal I'm going to retire from Debian, so I'm orphaning all packages. I guess you can keep this package unmaintained until Wheezy or something. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650439: O: libihelp-ruby -- Ruby console contextual help
Package: wnpp Severity: normal I'm going to retire from Debian, so I'm orphaning all packages. Maybe you can just drop this package. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650440: O: picalib -- Set of PICA helper scripts and configuration files
Package: wnpp Severity: normal I'm going to retire from Debian, so I'm orphaning all packages. This package can probably be removed. It has been dead upstream for *many* years, and I'm not even sure it has any users at all anymore. See also my request to orphan pica. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650442: O: pica -- System administration program similar to PIKT
Package: wnpp Severity: normal I'm going to retire from Debian, so I'm orphaning all packages. This package can probably be removed. It has been dead upstream for *many* years, and I'm not even sure it has any users at all anymore. See also my request to orphan picalib. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630816: [DRE-maint] Bug#630816: Please convert the package to gem2deb
On Fri, 17 Jun 2011 18:41:12 +0200, Lucas Nussbaum lu...@lucas-nussbaum.net wrote: On 17/06/11 at 17:17 +0200, Ondřej Surý wrote: Package: libtext-format-ruby Version: 1.0.0-2 Severity: wishlist Tags: sid, wheezy Dear maintainers, could you please convert the libtext-format-ruby package to a new package format as described here: http://wiki.debian.org/Teams/Ruby/RubyInWheezy Or you can just ping me and I can do it for you. I am member of debian-rem, but I this is a big change, so I would like to here ack from you before making the switch. Hi, With my member of pkg-ruby-extras hat, please go ahead and do it if you feel like it. Sure, go ahead. Actually, you can even remove me from the maintainers, I'm not really doing any Ruby packaging anymore :-/ -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615900: indexing rewrites whole index file for each package
On Wed, 23 Mar 2011 13:58:32 +0100, Thomas Koch tho...@koch.ro wrote: Esteban Manchado Velázquez: On Mon, 28 Feb 2011 22:31:42 +0100, Thomas Koch tho...@koch.ro wrote: [...] I monitored /var/lib/dhelp and saw that the file documents.index (~150MB) is rewritten for each invocation of index++. The Swish search engine should have some support to merge index files instead of rewriting the index every time. Re-reading your previous mail, I just realised you say your index is around 150Mib. I just had a look at mine, it's only 4.5Mib. Do you have any idea what documentation takes so much space? I wonder what's the average size of people's indices. However I know from Lucene, that there are other ways how indexers can handle incremental updates. Lucene writes indexes in so called segment files. Every time one commits a number of documents to the index, a new segment file is added to the index but no old file is changed. Occassionally some smaller segment files are merged to one bigger segment file to keep the total number of files low. If Swish-e is not capable of this incremental update and merge pattern, then you should rather use another indexer. Besides lucene (which has also an implementation in C) there are also Xapian and Sphinx, but I don't know whether they support merging segments. The main problem for me is, I don't have that much time for this, I'm not sure how big of an issue it is (eg. how many people it affects), and changing indexer is kind of a big deal: I'll have to check that everything keeps working in the same way, that the support the same input formats, that there aren't encoding problems, etc. So it's a lot of work, and I don't even know how the performance will compare to the current one :-( Of course, patches and benchmarks are welcome, but I don't think I'll work on this anytime soon... Sorry. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615900: indexing rewrites whole index file for each package
On Mon, 28 Feb 2011 22:31:42 +0100, Thomas Koch tho...@koch.ro wrote: [...] I monitored /var/lib/dhelp and saw that the file documents.index (~150MB) is rewritten for each invocation of index++. The Swish search engine should have some support to merge index files instead of rewriting the index every time. I'm not sure I understand your point. IIRC the index file is written from scratch in a temporary file and then moved to its final location, but that doesn't mean that all content is re-indexed. Only the new files are indexed, while the rest is, I assume, just taken from the existing index. The --incremental switch does that. So if that's what you meant, I don't think I can do much about it :-( Unless I change to another indexer, that is :-) -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602862: I don't think I can really solve this without a web server
close 602862 tag 602862 +wontfix thanks Hi Yaroslav, I've been thinking about it, and I can't find any good way to do it that doesn't require a web server. Any solution I could think of would require either some kind of local server (it seems much easier to just install Apache or similar than writing and maintaining a specific server just for this functionality), or writing potentially very complicated Javascript. The second case is probably much worse, as the solution would probably depend on the browser, so they seem like pretty bad ideas. I'm closing this for now. If you can think of alternative solutions, feel free to propose them and I'll give them a thought. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602862: I don't think I can really solve this without a web server
On Sun, 09 Jan 2011 17:43:26 +0100, Yaroslav Halchenko deb...@onerussian.com wrote: [...] python-sphinx uses it, thus many sphinx generated -doc's depend/use on jquery, thus it should be fairly stable Right, I forgot about the Sphinx reference. jQuery in itself doesn't solve much, but it's true that you could do what Sphinx does (generate *another* index only for the Javascript searches and use that if there's no web server installed). However, unless I'm missing something that would imply writing fairly complex indexing code to create Sphinx-compatible indices from our currently-supported documentation formats (PDF, Postscript, HTML). That sounds like a lot of work and potential issues to me :-( -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#602862: dhelp: ability to search offline (i.e. without running webserver)
Hey! First of all, thanks for your report. On Mon, 08 Nov 2010 23:40:36 +0100, Yaroslav Halchenko deb...@onerussian.com wrote: [...] which suggests that I could use search without running WWW server... [...] Search edit box results in: File not found Iceweasel can't find the file at /cgi-bin/dsearch?search=sci. Yes, I'm not sure how to solve that. I'm not even sure it's possible at all. The problem here is that in the end, either a CGI or a local command has to be executed, and I don't think that can be done in a reliable way without having a web server installed. That said, you *can* search without running a web server, you just have to do it from the command-line, not the browser. You can just use the command dhelp from a terminal, like so: dhelp searchterm1 searchterm2 Which incidentally doesn't seem to work for me now for some reason, does it work for you? I'll have a look. NB Similar thing happens even if I try to browse man or info pages, which is even more surprising. Yes, unfortunately showing man or info pages needs some conversion, so that's done by some CGI. I'll have a look and see if I can come up with some good solution for it. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534268: SVN::Web bug - configuration
On Thu, 05 Aug 2010 16:37:52 +0200, Dean Hamstead d...@fragfest.com.au
wrote:
I have discovered the source of this bug (no i havent spent the last 6
months on it)
in sub crack_url
...snip.8...
# This is used as the key in to the hash of configured repositories.
# It may be the empty string, in which case the action to run is
# the 'list repositories' action.
if($location eq $filename) {
$repo = ''; # No repo, show repo list
$action = 'list';
} else {
...snip.8...
this $location eq $filename doesnt factor in superfluous trailing
slashes. for example /var/www/svn/repos/svnweb is equal to
/var/www/svn/repos/svnweb/ even though perls |eq| function doesnt agree
with that.
If I'm not mistaken, that should be trivial to solve by adding use Cwd
qw(realpath); at the top and changing the condition of that if to:
if(realpath($location) eq realpath($filename)) {
HTH,
--
Esteban
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584262: NMU in DELAYED-7 queue
Hi, FYI, yesterday I uploaded a new package to the DELAYED-7 queue. I've tried to contact the maintainer but haven't gotten any reply, so as I think this bug is quite important, I uploaded to DELAYED-7 after waiting for a couple of days. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584262: Upstream patches for sqlalchemy compatibility
tags 584262 +patch thanks Hi, In case you haven't seen them, these seem to be the commits fixing the issue (not sure if the second is needed): http://github.com/dae/libanki/commit/a1d3f13f0a694e079be196bb2eb4ee6b67799f45 http://github.com/dae/libanki/commit/f69d946f8355af9ca19c5e90e1056c01a3722bf5 I imagine applying these fixes would be better than upgrading to an unreleased version. If you need any help testing them, I'd like to see this fixed so I'm willing to help. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583349: ++ (as in C++) is not well handled by dhelp
On Thu, 27 May 2010 11:12:58 +0200, John Gruenenfelder jo...@as.arizona.edu wrote: The ++ characters are not properly handled by dhelp in a couple of places. The first is in the document index. I have The C++ Annotations, a C++ primer, installed. I used dhelp to browse to it, but this failed when my browser attempted to access http://localhost/doc/c++-annotations/html/index.html and could not find the files. This is because ++ is parsed by the browser and the resulting URL looks something like .../c -annotations/... which doesn't exist. The fix is, I suppose, to use the correct HTML element for the + character. Yes, my bad. I was calling a function to escape the URL, but it didn't escape all characters it seems :-( Now it should be fixed. I have just uploaded dhelp 0.6.19 addressing this. The other problem is rather minor, but dsearch, which *does* handle ++ properly, has a string limit which requires the search string to be at least four characters in lengths. This prevents anyone for looking for all C++ documentation on the system. I realize it is on the main index, but the search string length should probably be lowered to three characters. I don't think I've ever found a way to lower that limit. Actually, looking at index++'s source code, it seems that the limit is hardcoded in config.h. If you know or find a way to lower the limit, tell me and I'll change it. It's something that sort of bugs me too. Thanks, -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534268: SVN::Web bug - configuration
Hi, I'm not the package maintainer, just trying to help with RCs. I can't really reproduce your bug, and I can't think of a way to trigger that problem. How are you configuring SVN::Web? Are you accessing directly through svnweb-server or are you configuring some independent web server like Apache? In any case, which URL are you visiting to trigger that error? Do you really have one or more SVN repositories inside /var/www/svn/repos, or is that path itself an SVN repository? Also, about the FreeBSD port patches, I don't think they're relevant for this problem, and it seems they were applied in the next package revision (0.53-3) anyway (which I assume has the same problem?). -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577082: More information
Hi, I'm not the maintainer, just trying to help with RC bugs. I can't reproduce the bug. I had the package installed and I can import it just fine in unstable. That package ordered_dict is actually part of python- simplejson, so it's not a problem of missing dependencies it seems. Are you sure you haven't fiddled with /usr/share/python/debian_defaults or that you didn't abort the package configuration or something? What are the contents of your directory /usr/lib/pymodules/python2.5/simplejson/ ? You should have a ordered_dict.py symlink in there. -- Esteban -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562947: Wrong path for sqlr-stop
Hi,
I've investigated this for a couple of minutes and it seems that the path is
wrong. I'm not sure _why_ is wrong, or what will happen when/if you fix the
path (when sqlr-stop starts working, who knows what will happen).
In any case, the fix seems to be changing preinst to read (instead of
/usr/sbin/sqlr-stop):
su - ${ADMIN} -c /usr/bin/sqlr-stop
If you check the versions in sid, lenny and even etch, sqlr-stop is always
shipped in /usr/bin, never in /usr/sbin. That's why I don't understand how
this bug hasn't been found before (at least Lenny's and Sid's versions have
the wrong path in the preinst, so I assume it hasn't changed since).
--
Esteban
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575067: Anyone working on this ohai bug?
Hi,
It seems that the culprit is /usr/lib/ruby/1.8/ohai/plugins/ruby.rb. If no one
is working on this bug, I can try to prepare a patch for it (I'll be away the
whole next week, so it will take a while). It's probably as easy as changing
line 25 to read:
cmd = ruby1.8 -e \require 'rbconfig'; #{command}\
--
Esteban
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561883: dhelp: Illegal character ')'
On Monday 21 December 2009 01:11:48 you wrote: Package: dhelp Version: 0.6.18 Severity: normal When /etc/cron.weekly/dhelp runs each week, I get the following error message: Error (383685): Illegal character ')' Error (383687): Dictionary key must be a name object /etc/cron.weekly/dhelp invokes some ruby scripts, so I'm not sure how to proceed with further debugging. I guess the bug must be in /usr/lib/ruby/1.8/dhelp.rb somewhere. As I didn't know that error message, I Googled a bit... and I found this: http://bugs.debian.org/559897. So it seems it's not a dhelp bug. Do you have drawxtl installed? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#469191: Splitting control files over multiple binary packages
reassign 469191 docbook-xsl-doc-html
tag 469191 +patch
thanks
Hi there!
Yesterday I found by chance that doc-base already supports it, and
dhelp doesn't have to do anything to make it work: it's the package
maintainers who have to specify the same document id, as explained in the
doc-base documentation:
http://localhost/doc/doc-base/doc-base.html/ch-interface.html#s2.5.3
So, the solution is as simple as using the same document id
(docbook-xsl-doc?) for all three doc-base files in
docbook-xsl-doc-{html,pdf,text}. You should probably also depend on
doc-base (= 0.8.7).
--
Esteban Manchado Velázquez z...@demiurgo.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521910: dhelp: Binary-only NMU will FTBFS
tag 521910 pending thanks On Mon, 30 Mar 2009 22:29:33 +0200, Daniel Schepler schep...@math.berkeley.edu wrote: Package: dhelp Version: 0.6.15 Severity: important From my pbuilder build log, with a hook installed to create a dummy entry with version 0.6.15+pb1: [...] Now I'm just taking the debian/changelog version as the master in the Makefile. I'll test that and other changes I have and upload the new revision soon. Thanks for the heads up, -- Esteban Manchado Velázquez z...@demiurgo.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#162631: This should be closed as wontfix
Hey there, I just noticed this bug, and it doesn't make sense anymore. Dhelp has been using the original doc-base files for a while. Those old .dhelp files don't exist anymore, so there's no need to tweak the output (I don't think they're generated at all from doc-base anymore even). -- Esteban Manchado Velázquez z...@demiurgo.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#469191: Different formats from different Packages
Hi there, I'm sorry it's been more than one year and I haven't commented on the bug :-S I actually think it's a great idea :-) At the time there was some discussion abou it, IIRC, between me and Robert (doc-base maintainer, Cc'ed). I seem to recall that he said it would be solved in doc-base, or at least that there would be some support, and I was kind of hoping that Robert would remind me after he did his part of the work. Unfortunately I became inactive (again) so I completely lost track of dhelp and its bugs. TBH I don't even remember the status of that anymore, but hopefully Robert can shed some light on it and we can work together again to find a solution to this :-D -- Esteban Manchado Velázquez z...@demiurgo.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515115: dhelp: documentation links stop working when lighttpd is installed
On Tue, 17 Feb 2009 14:48:45 +0100, Teemu Ikonen tpiko...@gmail.com
wrote:
On Mon, Feb 16, 2009 at 11:09 PM, Esteban Manchado Velázquez
emanch...@demiurgo.org wrote:
Which browser does it open when you execute dhelp? I have tried a
bit,
and when using lighttpd it seems that Konqueror fails. All the rest
(Opera,
Firefox and even links) seem to work like a charm.
I'm using Firefox.
Experimenting a bit, it seems that lighttpd somehow gets confused by
Konqueror and thinks that it's not connecting from the same host. If you
comment this line (and the closing brace) at the end of the lighttpd
configuration, it works:
$HTTP[remoteip] =~ 127.0.0.1 {
Commenting this does not solve the problem for me, but...
Hm, that's strange. I never touched the default lighttpd configuration,
so I guess I didn't have CGIs enabled... and yet it worked for me using
Firefox. Oh, well.
Keep me in the loop if you want/need help reproducing the bug and such.
Good luck! :-)
--
Esteban Manchado Velázquez emanch...@demiurgo.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515115: dhelp: documentation links stop working when lighttpd is installed
Hi Teemu,
On Fri, 13 Feb 2009 18:23:06 +0100, Teemu Ikonen tpiko...@gmail.com
wrote:
The 'dhelp' command opens a web browser window with an index to the
doc-base based documentation. When I have no web-server installed,
the links to the actual documentation files in this index page are in
the form 'file:///usr/share/doc/...', and work perfectly.
If I install lighttpd, dhelp opens an index page with the links in
the form 'http://localhost/doc/...'. None of these links work, i.e. all
of them give a 404 - Not Found error.
Which browser does it open when you execute dhelp? I have tried a
bit, and when using lighttpd it seems that Konqueror fails. All the rest
(Opera, Firefox and even links) seem to work like a charm.
Experimenting a bit, it seems that lighttpd somehow gets confused by
Konqueror and thinks that it's not connecting from the same host. If you
comment this line (and the closing brace) at the end of the lighttpd
configuration, it works:
$HTTP[remoteip] =~ 127.0.0.1 {
In any case, it does sound like an issue in lighttpd (maybe Konqueror), so
you might want to reassign the bug, or at least check with the
maintainers. Any web server should make /usr/share/doc/ available as per
Debian Policy 11.5
(http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl),
so it seems that dhelp is doing the right thing. Another problem that
looks like a bug in the lighttpd default configuration (as per the same
policy section) is that apparently lighttpd doesn't make available the
CGIs under /usr/lib/cgi-bin. That is also needed by dhelp (when you called
it like dhelp search-term search-term2).
--
Esteban Manchado Velázquez z...@demiurgo.org
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502813: dhelp: /etc/cron.weekly/dhelp fails to rebuild index
On Mon, Oct 20, 2008 at 11:11:03AM +1100, Andrew Vaughan wrote: Package: dhelp Version: 0.6.13 Severity: serious Hi /etc/cron.weekly/dhelp fails to rebuild /var/lib/dhelp/documents.index, after deleting it. Running it manually produces no error message. Severity serious since this a significant regression from 0.6.12. Downgrading to 0.6.12 fixes the problem. (As an aside 0.6.12 /etc/cron.weekly/dhelp now takes 8m 44sec to rebuild the index. This is the same machine where 0.6.12 was taking 150 mins a month ago. This may render the changes that 0.6.13 introduced unnecessary). I wonder how I didn't realise this myself. I'm investigating it, thanks a lot for the report. About shipping 0.6.12 or 0.6.14, I haven't changed anything in dhelp that could speed up the index rebuilding (OTOH it doesn't depend that much on me), so if anything it must have been a change in pdftotext or pstotext. Are you sure you had the same packages installed? -- Esteban Manchado Velázquez [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#487722: Unblock request for dhelp
On Sun, Sep 28, 2008 at 05:05:30PM +0200, Luk Claes wrote:
Esteban Manchado Velázquez wrote:
As I haven't received any response, I'm trying with a more evident subject,
just in case the mail went unnoticed :-)
There is a bug in dhelp (#487722) that makes dhelp wait for hours when
upgrading packages that have a lot of documentation. That might be just
doc-linux-html or similar, or possibly a combination of other packages that
together contain many document files registered through doc-base. That means
that many people (for some definition of many) will have to wait for hours
if/when they upgrade to Lenny, because of this bug.
The proposed fix (not uploaded yet) is to drop indexing documentation on
package installation/upgrade. The documentation, then, would only be indexed
once a week. It's a suboptimal solution, but the patch is very small and
safe,
and I don't want to risk going for a better solution (indexing in the
background or whatever) if that could mean shipping a broken dhelp.
Yes, that would be acceptable. Though it would be good to add something
to README.Debian about it to explain how one can avoid waiting on the
weekly cronjob and run the index update manually.
I have uploaded dhelp 0.6.13 with that change.
I'm sending the diff attached (the diff between both _source_ packages,
for review if you're interested). Don't worry about the two missing files at
the end of the diff, they're cruft that shouldn't have been there in the first
place. They dissappeared because I cloned the repository to make this change,
so I didn't get them in the new, clean one.
--
Esteban Manchado Velázquez [EMAIL PROTECTED]
diff -ur dhelp-0.6.12/Makefile dhelp-0.6.13/Makefile
--- dhelp-0.6.12/Makefile 2008-07-20 20:26:08.0 +0200
+++ dhelp-0.6.13/Makefile 2008-09-16 23:00:13.0 +0200
@@ -17,7 +17,7 @@
# Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
PACKAGE = dhelp
-VERSION = 0.6.12
+VERSION = 0.6.13
PREFIX_ = $(if $(PREFIX),$(PREFIX),/usr/local)
DESTDIR_ = $(DESTDIR)/$(PREFIX_)
RHTML_TEMPLATES = *.rhtml
Only in dhelp-0.6.13/debian: README.Debian
diff -ur dhelp-0.6.12/debian/changelog dhelp-0.6.13/debian/changelog
--- dhelp-0.6.12/debian/changelog 2008-07-23 01:50:12.0 +0200
+++ dhelp-0.6.13/debian/changelog 2008-10-02 00:51:04.0 +0200
@@ -1,3 +1,11 @@
+dhelp (0.6.13) unstable; urgency=low
+
+ * Not index documents on upgrade, to prevent dhelp blocking the
+upgrade for hours (Closes: #487722).
+ * Add some small utilities to index by hand, because of the above change.
+
+ -- Esteban Manchado Velázquez [EMAIL PROTECTED] Thu, 02 Oct 2008 00:50:47 +0200
+
dhelp (0.6.12) unstable; urgency=low
* Switch from pstotext to pdftotext from xpdf-utils for PDF files. It
diff -ur dhelp-0.6.12/debian/rules dhelp-0.6.13/debian/rules
--- dhelp-0.6.12/debian/rules 2007-11-18 16:34:37.0 +0100
+++ dhelp-0.6.13/debian/rules 2008-10-02 00:52:31.0 +0200
@@ -5,5 +5,6 @@
DEB_MAKE_INSTALL_TARGET= install DESTDIR=$(DEB_DESTDIR) PREFIX=/usr
DEB_INSTALL_MANPAGES_dhelp = man/dhelp*
+DEB_INSTALL_EXAMPLES_dhelp = examples/*
include /usr/share/cdbs/1/rules/debhelper.mk
include /usr/share/cdbs/1/class/makefile.mk
Only in dhelp-0.6.13: examples
diff -ur dhelp-0.6.12/lib/dhelp.rb dhelp-0.6.13/lib/dhelp.rb
--- dhelp-0.6.12/lib/dhelp.rb 2008-02-13 23:46:49.0 +0100
+++ dhelp-0.6.13/lib/dhelp.rb 2008-09-16 22:59:11.0 +0200
@@ -404,10 +404,15 @@
end
doc_dir_db.close
- indexer_opts = @opts.reject {|k,v| !([:index_file,
-:indexer_config_file].include? k)}
- indexer = Indexer.new(indexer_opts)
- indexer.index(index_paths, :incremental = !register_opts[:regenerate_index])
+ # Only index documentation when we're reindex everything in the
+ # background (see bug #487722). Not refactoring to keep the differences
+ # as small as possible
+ if register_opts[:register_opts]
+indexer_opts = @opts.reject {|k,v| !([:index_file,
+ :indexer_config_file].include? k)}
+indexer = Indexer.new(indexer_opts)
+indexer.index(index_paths, :incremental = !register_opts[:regenerate_index])
+ end
end
end
Only in dhelp-0.6.12: registered_dir_list.rb
Only in dhelp-0.6.12: swish++.index
signature.asc
Description: Digital signature
Bug#487722: Unblock request for dhelp (was: Re: Bug#487722: 487722: dhelp still getting hung up)
As I haven't received any response, I'm trying with a more evident subject, just in case the mail went unnoticed :-) There is a bug in dhelp (#487722) that makes dhelp wait for hours when upgrading packages that have a lot of documentation. That might be just doc-linux-html or similar, or possibly a combination of other packages that together contain many document files registered through doc-base. That means that many people (for some definition of many) will have to wait for hours if/when they upgrade to Lenny, because of this bug. The proposed fix (not uploaded yet) is to drop indexing documentation on package installation/upgrade. The documentation, then, would only be indexed once a week. It's a suboptimal solution, but the patch is very small and safe, and I don't want to risk going for a better solution (indexing in the background or whatever) if that could mean shipping a broken dhelp. Leaving part of the thread below to give more context... On Tue, Sep 16, 2008 at 02:26:01PM -0700, Ross Boylan wrote: On Tue, 2008-09-16 at 23:04 +0200, Esteban Manchado Velázquez wrote: Cc'ing debian-release, seeking advice... It would be very interesting to hear what they have to say, and whether testing has turned up this problem. Intro for debian-release: this bug makes dhelp wait for potentially *hours* when upgrading (many packages). That means that if someone upgrades from Etch to Lenny, they will have to wait for a couple of hours for the dhelp postinst, while it's asking index++ to reindex all documents for all installed packages. I'm not sure how widespread the problem will be. For example, I have a lot of linux documentation and standards files installed; maybe people without that will not have long to wait. I just did another upgrade (within testing) that took about 2 hours because of this problem. Ross This will happen to virtually everyone having dhelp installed if they dist-upgrade to Lenny. Or anyone doing any reasonably big upgrade for that matter. -- Esteban Manchado Velázquez [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#487722: 487722: dhelp still getting hung up
On Fri, Sep 19, 2008 at 09:18:29AM -0700, Ross Boylan wrote: On Fri, 2008-09-19 at 15:02 +1000, Andrew Vaughan wrote: I actually think that the best work-around for Lenny would be Esteban Manchado Velázquez's suggestion in bug 497139 of *not* reindexing documentation (just register the documents) when doc-base calls dhelp with more than, say, 20 files. (There is a cron.weekly job that should rebuild the index). What are the implications of having the index either absent (for initial installs) or out of date? In particular, if someone installs some documents they may want to see them right away. Weekly seems a little infrequent to fix things up. The only implication is that user wouldn't be able to *search* in the search box in dhelp (i.e. any search would yield no results/obsolete results). They would appear in the documentation directory and they would be perfectly viewable. It's just that, when searching for keywords, the would not be any results, or they would be obsolete. In another email Ross Boylan wrote I just did another upgrade (within testing) that took about 2 hours because of this problem. I'm guessing that would have been the recent update of doc-linux to 2008.08-1? I don't have the records anymore, but it's quite possible. Ross -- Esteban Manchado Velázquez [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#487722: 487722: dhelp still getting hung up
Cc'ing debian-release, seeking advice... Intro for debian-release: this bug makes dhelp wait for potentially *hours* when upgrading (many packages). That means that if someone upgrades from Etch to Lenny, they will have to wait for a couple of hours for the dhelp postinst, while it's asking index++ to reindex all documents for all installed packages. This will happen to virtually everyone having dhelp installed if they dist-upgrade to Lenny. Or anyone doing any reasonably big upgrade for that matter. On Tue, Sep 16, 2008 at 09:36:12AM -0700, Ross Boylan wrote: On Tue, 2008-09-16 at 14:32 +0200, Miguel Aguado wrote: Ross Boylan is right in that indexing should not stop the upgrade of other packages. Originally I thought it was hung up; however the problem seems to be that it takes a long time, like several hours. It is possible the slow speed is a result of a bug in one of the indexing packages. The operation seems to me to take too long to be part of the regular upgrade process; I think many people will just decide something is broken. If delays of several hours happen while tracking testing, it seems likely the situation will be even worse for people upgrading from stable to the next release. Yes. I hadn't realised this last paragraph myself, sorry. It should be run in the background after a prominent warning for the user, along the lines of: This proposal might be inconsistent with how debconf is supposed to be used. It also has the problem that if someone interrupts it, for example by shutting the system down, it will not resume. Perhaps an anacron job would be an appropriate solution. That leaves open the question of what to do before or while the index is updating. I think it is too late to try a correct solution. My proposal is to simply _not_ reindex when installing. This has the downside that people won't be able to search for documentation in dhelp's search engine until the next cron.weekly run, but I think that's fair enough compared to the current problem. I'm going to provide a new revision of the package without indexing on package installation/upgrade. The diff is really small (enclose four lines in a clean if statement). Release managers, what do you think? Can this revision end up in Lenny? Should I upload it ASAP after testing it? The bug has right now severity normal, but with this information, I think it should be at least important. dhelp: Indexing documentation in the background. **Please note that this process may take HOURS on bulky doc upgrades.** Documentation will not be fully accessible until indexing is complete. (if a further upgrade happens while /usr/bin/index++ is still running, of course, duplicates should be avoided.) I am aware that users of the stable release need not upgrade as often as those of testing or unstable. However, please consider raising the severity of this bug This does appear to be a problem that could effectively break upgrades to lenny, at least for systems with significant documentation installed. True. Feel free to upgrade to important. -- Esteban Manchado Velázquez [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#497139: doc-base's trigger seems to sometimes cause dhelp to reindex the entire cache
On Sun, Sep 14, 2008 at 04:34:50AM +1000, Andrew Vaughan wrote:
[cc-ed to dhelp's maintainers in case they have any suggestions as to how to
debug this/what might be causing this].
I don't really know the doc-base source code, but I was having a quick
look now, and this seems like it can help debugging (run after something like
that has happened; probably running it now it could help):
sudo install-docs --dump-db files.db | perl most_recent.pl
# Show 100 most recently changed documents
sudo install-docs --dump-db files.db | perl most_recent.pl 100
most_recent.pl being:
-- 8 --
#!/usr/bin/perl
use strict;
use warnings;
my $how_many = shift || 50;
my $ignored_first_line = ;
my $content = ;
eval \$content = .join(, );
my @most_recent = reverse sort { $a-{CT} = $b-{CT} }
map { $content-{$_} }
keys %$content;
print join(\n, map { $_-{ID} ($_-{CT}) } @most_recent[0..$how_many-1]),
\n;
-- 8 --
Apparently, in your case, doc-base thinks that all documents have changed, and
AFAICS it's based on the ctime of the files. The ctime, however, is stored in
files.db (in /var/lib/doc-base/info/files.db). This script will tell you which
are the most recent files, with their timestamps. Maybe that will give you an
idea of why that is happening (maybe the timestamps will have a very high
value, or you will see some document ids that will ring a bell).
Or maybe it some problem with the clock?
In any case, please keep me in the loop. I've had similar problems with
dhelp before, and I'm starting to think that I should just *not* reindex
documentation (just register the documents) when doc-base calls dhelp with
more than, say, 20 files. The rationale: I still want people to be able to
search for documentation for things that they just installed (instead of
having to wait a whole week), but then if someone installs more than 20
packages, it's probably some upgrade or something that she doesn't really want
documentation for (in the next couple of days anyway).
Good luck,
--
Esteban Manchado Velázquez [EMAIL PROTECTED]
signature.asc
Description: Digital signature
Bug#475655: PDF converter
Hi, Initially I used pstotext for both PS and PDF to try to cut down dependencies. However, that's giving problems with some documents as you say, so for the moment I'm just going to use a more robust PDF converter (from poppler-utils as you suggest), even if that means more dependencies for dhelp. I have been trying a couple of times with it, and it seems to behave better. I'm going to upload a new dhelp version very soon with that fix (and using a private temporary directory). Thanks for reporting and for all the tips! -- Esteban Manchado Velázquez [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#487722: Indexing time
Hi, If you're upgrading many packages, probably what is happening is indeed that index++ takes a long time to reindex all that. If there are enough documents registered in those upgraded packages (and I see a reference to HOWTOs, so that might well be the case), I guess it can take a very long time. One hour seems way too much, yes, so it might not be a normal indexing case after all. The next time you upgrade, if it takes a long time again, can you have a look at the parameters index++ is being called with? If it's changing file from time to time, it might be that index++ is terribly slow on your machine for some reason. If it seems to get stuck in one document, it might be a index++ (or ghostscript or pdftotext or...) bug. Thanks! -- Esteban Manchado Velázquez [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#487722: libruby1.8: ruby hangs installation of all packages
Hi, The stacktrace seems to be some problem in some doc-base files. I have made dhelp more robust to that, and now it handles those without complaining. I have just uploaded 0.6.10 fixing that. However, I'm not sure that's the problem you're experiencing. What is happening there is that when you register some documentation in dhelp, it indexes the contents so you can search for it. In some cases that can mean indexing a lot of documentation (in some upgrade with many packages, where install-docs calls dhelp_parse with many packages at once). So it's expected behaviour that many index++ processes are spawned. Of course, one might argue that in those cases you prefer not indexing at all, or maybe indexing in the background, but I'm not completely sure how to handle the situation. Maybe only index when registering a single document? Maybe disable the indexing on install completely, and only index weekly? I don't like that very much because it means that when you install some package, you can't search for its documentation until the next week (and I guess you're likely to want to search for the documentation of a package a couple of days after installing it). I'm open to suggestions :-) -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#482807: .dhelp not supported anymore
reassign 482807 doc-linux-html thanks Hi, This bug is totally my fault, I'm sorry. For some reason I assumed that nobody was calling dhelp_parse directly, I thought the only dhelp_parse client was install-docs, so I talked to the doc-base maintainer and we decided to make some changes to simplify and improve documentation in Debian. The result is that .dhelp files are not supported anymore, dhelp now just uses the doc-base format. Because of that, the calling convention for dhelp_parse changed, that's why it's choking with doc-linux-html. The documentation wasn't even updated (I'm going to upload now, with updated manpage), so I'm the only one to blame here. The good thing is, to fix you only have to remove the dhelp_parse call from doc-linux-html's postinst, because install-docs will call dhelp_parse automatically, and dhelp will know about the documentation :-) Sorry for the inconvenience. Can you please fix, Frank? -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#475655: Ghostscript Error message
Hi Laurent, I'm afraid it's a bit hard, because I just call index++ with all the paths, and it's index++ the one that gives you that error... The only thing you can do is collecting all the PS and PDF files in your system (grep -i format:\ p /var/lib/doc-base/documents/* will give you the files that contain such documents), and calling index++ for each one of them, like this: index++ -c /usr/share/dhelp/swish++.conf path -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#471558: WordThreshold for swish++
Hi, How much memory does your machine have? According to swish++.conf sample file (see /usr/share/doc/swish++/examples/swish++.conf.gz), the default is 25, and that should work fine for a 64Mib RAM machine (in a SPARC running Solaris, but still). I see that the default for man2html is indeed 5 as you say, but I'd like to understand better the consequences of the change before doing it. How will that impact performance/memory in newer machines (i.e. virtually all of them)? About swish++.conf being overwritten, I didn't consider it to be part of the dhelp configuration, and it seems that dwww and man2html maintainers thought the same. I wonder if it would be a good idea to move it to /etc. In the mean time, you could divert it I guess. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#472290: Bug in swish++ (vowel definition)
reassign 472290 swish++ thanks Hi, After investigating this issue a bit, I think the issue is actually in swish++. The problem is that swish++ actually skips (both when indexing and when searching) words with less than Word_Min_Vowels vowels, and considers y to be a consonant: * Word_Min_Vowels seems to be a compile-time definition, not possible to override with configuration files; and, * The definition of y as a consonant is hardcoded in the source code. Please see Word Determination in index++(1). So I guess the swish++ maintainer should have a look. Thanks for your bug report! Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#466263: German dhelp translation update
Hi Helge, There are two strings still pending to translate in dhelp. I'm insisting just in case you missed my mail to debian-i18n. Sorry for adding two strings right after receiving for translation, it was my mistake (I had them already, I just didn't realise they weren't on dhelp.pot). So, if you have time, it would be great to have the complete German translation before re-uploading. Thanks in advance! -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#458836: Dhelp French translation and call for translations
On Sat, Feb 16, 2008 at 03:52:33PM +0100, Helge Kreutzmann wrote: Hello, On Sat, Feb 16, 2008 at 01:01:07PM +0100, Esteban Manchado Velázquez wrote: A had some problems with string updating, but they are solved now, so please translate the current strings if you feel like it! For those like me who have no idea what you refer to could you briefly say which strings you are talking about and where I could obtain them? (Debconf, package, ...). Gah, sorry. I forgot *again* :-) I'm talking about the dhelp package (it's a Debian native package), in particular the strings contained in po/dhelp.pot in the source file (see http://darcs.debian.org/~zoso/dhelp/po/dhelp.pot , I just setup the public Darcs repo). The French translation is at http://darcs.debian.org/~zoso/dhelp/po/fr.po . Just send me a Darcs changeset, or a diff, the file, or whatever is easier for you. The strings themselves are used in the (new) HTML interface: it's the directory of available documentation (the one registered with doc-base) and the documentation search interface. There's no debconf, and I don't think I will add it anytime soon. And finally, is there anything I could/should do to make it easier for translators to track changes in the package, or to know when I have frozen some strings so they can start translating? Just mail this list? -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#458836: Dhelp French translation and call for translations
Hi all, A had some problems with string updating, but they are solved now, so please translate the current strings if you feel like it! A couple of comments: There is no need to get defensive Christian! It's not that I opposed including the translations or anything. It was just that I received (to my surprise; I don't remember having asked for them) a translation for the dhelp strings, but: * It had only four strings translated, and when I received it I already had around 15. * When I tried to merge, two of them were marked fuzzy and the other two were not there anymore, which makes a grand total of two strings translated. * Also, more importantly, I had problems with rmsgmerge (I was using that instead of msgmerge), and when trying to update the translations, it just resulted in every string (including the Spanish ones) being commented out. I just thought that at that moment it wasn't worth figuring out what the problem was, just for two strings. Anyway, I just tried with msgmerge, and it seems to work OK, so I'll include whatever strings I have, and please send updates for the rest of them (and any other language!). Best regards, and sorry for the misunderstanding! -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#458836: Outdated translation
Hi, I haven't included your translation because it's outdated (when I received it in the BTS I had already lots of changes; not sure if already released, but anyway). I have added *lots* of strings now (I think now it should be reasonably safe to translate), so it was kind of pointless to add just a few translations. So, can you please update your translation and send again? Thanks a lot! -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#455731: unkillable process?
Hi, Wow, I have *never* seen an unkillable index++ process. Is it in state D? Anyway, that seems to be a problem with index++ (part of swish++), or perhaps a problem in Ghostscript or something similar (used by index++, as per my configuration, to extract the text of PS and PDF files). Frankly, I don't know what to do about it. FWIW, I have tried installing cupsys (the version I tried was 1.3.5-1+b1, though), and it worked OK. It just indexed the file, I can search for it, etc. At least with my internal version, which I'll upload soon, but I don't think it would change for the currently public version. In any case, I think you should file it as a separate bug, I don't think it belongs to this one (#455731). Probably reassign #461349 to swish++ or ghostscript? Perhaps you can try again with the new version, when I upload it, and see it that helps? -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#458353: Indexing errors
Hi Noel, It's hard to say, really. I have made a couple of tests, and I seem to be able to find the text in the document, even the words appearing in the last pages, so it seems that most, if not all, the indexing is actually performed. Perhaps the error is produced at the end of the document? In any case, that sounds like a ghostscript bug... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#459611: setrlimit
reassign swish++ thanks Hi Norman, Please note that index++ is part of swish++, not part of dhelp. I'm going to reassign the bug to swish++. If the author doesn't want to add that functionality to index++, he can always reassign again to pstotext, ghostscript or something similar... Thanks! -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#459611: WFM. Bug in gs?
Hi, Thanks for your report. I'm afraid I can't do much about the bug. That call is most probably pstotext, which is called by index++, which is called by dhelp. So the bug is probably either in gs or perhaps in pstotext. In any case, I can't even reproduce, it works for me (takes around 1 minute and lots of CPU, but not much memory). I'd reassign to gs, probably. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#458353: More information?
Hi, I see I have the same problem, I'll have a look. However, probably that just means that one file couldn't be parsed for some problem, because the index file, /var/lib/dhelp/documents.index, is created correctly (at least in my system) and you can search normally. Or do you have any other problem? -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#455731: Corrupted doc-base file?
Hi,
Thanks for your report. For some reason I'm not receiving the e-mails for
new bugs :-(
That seems like a problem in some doc-base file in your system. Of course
dhelp shouldn't fail in any case, I'm going to fix that, but I'd like to know
which file is causing the problem.
Can you add the following before line 387 in /usr/lib/ruby/1.8/dhelp.rb ?
puts processing files for #{doc.document}'s format #{format.format}
Run the weekly cron job again, and tell me the last processing files...
line you get.
To fix the problem until the next release, modify line 130 to read:
@files.to_s.strip.split(/\s+/)
That is, add to_s to @files.
--
Esteban Manchado Velázquez [EMAIL PROTECTED]
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Help spread it through the Net in signatures, webpages, whatever!
signature.asc
Description: Digital signature
Bug#389913: thttpd problem?
tag 389913 wontfix thanks Hi, I don't think I can do much about this bug. According to: http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl Web servers are supposed to support /doc/ to access /usr/share/doc/ . It doesn't say they *have* to (so I'm not reassigning the bug to thttpd), but I guess I can assume http://localhost/doc will work if I depend on httpd. I'm marking the bug as wontfix. If you have further questions, comments or ideas, please make a new comment to the bug. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#454517: Rationale?
tag 454517 pending thanks Hi, What's the rationale of adding firefox to the Recommends, if iceweasel is already there? firefox depends on iceweasel and it's just a transitional package now anyway... People who have an up-to-date firefox will have iceweasel already installed... I'll bump debhelper, thanks! -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#453734: Fixed?
Hi, For some reason I'm not receiving the bug mail. I just saw this bug, and I think it should be fixed in the current release, 0.6.5. I removed the DirectorySet class, which had that reported bug. Can you please try to reproduce again, and close the bug if it's OK now? -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#452873: Temporary fix
tag 452873 pending thanks, Hi Philipp, It seems you have some package installed that doesn't specify abstract in one of its documents... I thought it was mandatory (actually, perhaps it is), sorry about that. I'll fix it for the next revision. In the meantime, you can modify line 178 of /usr/lib/ruby/1.8/dhelp.rb to read: @abstract.to_s.strip That is, you have to add a call to to_s to make sure that the abstract is always defined as a string. That should solve your problem. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#449578: Duplicate and already fixed
merge 447789 449578 thanks Hi, This bug is actually #447789. It was a bug in libcommandline-ruby, and it's now fixed with 0.7.10-9 upload. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#447789: Clarification
Just a quick clarification: The initial patch was wrong, it wasn't a complete fix. That's why I marked as pending and made that comment *after* closing the bug. Now I just uploaded 0.7.10-9, which should be (finally) fine... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#447789: Tag 'pending'
tag 447789 pending thanks I already have a patch, the upload is pending and will hopefully be done soon... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#429233: Moving dhelp files to /var/cache/doc-base/dhelp
Hi Robert, Thanks for your interest. Actually I think it's a pretty good idea, but I'd like to change a couple of things: 1) First, I'd like to use dhelp instead of .dhelp for the files. If they're going to be in a special directory in /var/cache/* anyway, I don't see any reason to hide them. 2) Second, I'd also like to close #81405 (Add sources), so instead of harcoding the directories, I'll simply search for dhelp files in a (configurable) directory list, defaulting to /usr/share/doc and /var/lib/doc-base/dhelp (and looking for both .dhelp and dhelp files in both cases). Is that OK with you? Also, how are we going to manage the dependencies? Are you going to update the Conflicts to point to the new version? And finally, you said you also checked for the validity of the arguments, but I don't find anything for that in your patch, did you forget to include it? Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#447789: Examples?
Hi, Can you give me the output of this command? ls /usr/share/doc/*/.dhelp I'll add some debugging/verbose mode to dhelp_parse in the next version :-D Do you mind if I send you a modified version of dhelp_parse to test? -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#102393: Still valid bug
This bug is still valid. You just have to go to /usr/share/doc/HTML/tools/index.html If you have bzip2 installed, you'll see the title: bzip2 and libbzip2: a program and library for dat Which is exactly 49 characters. I have rewritten dhelp_parse in Ruby, and I can easily raise this 49 characters limit to, say, 100 or more easily. Hopefully I'll take over dhelp and upload a new version (with the rewritten dhelp_parse) soon... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#429233: .dhelp files are created by install-docs
tags 429233 wontfix thanks Hi Emil, Those .dhelp files are created by the packages themselves, in a install-docs call in their postinst (dh_installdocs creates that call usually). So, they don't really belong to dhelp. I'm tagging the bug as invalid, please untag if you don't agree or have more comments... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#368035: Recommends: doc-base
Hi Teemu, Bug #314733 already asks dhelp to depend on doc-base. Hopefully I'm going to take over dhelp, and upload a new version soon-ish. This new version will depend on doc-base... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#430474: Merge bugs
merge 158792 430474 thanks More duplicates... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#185215: Can't reproduce
tag 185215 unreproducible thanks Hi Geordie, I can't reproduce this bug, does it still happen to you? -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#401217: backup-manager: typo in spanish debconf translation
On Fri, Dec 01, 2006 at 09:13:28PM +0100, David Gil wrote: Package: backup-manager Version: 0.7.5-1 Severity: minor Tags: patch l10n There's a typo in the spanish debconf translation: --- es.po.orig 2006-12-01 21:07:40.0 +0100 +++ es.po 2006-12-01 21:07:48.0 +0100 @@ -470,7 +470,7 @@ #. Choices #: ../backup-manager.templates:20001 msgid weekly -msgstr sedmanalmente +msgstr semanalmente #. Type: select #. Choices Oops, thanks. I have searched a little, and have found KBabel. It has a spell check option ;-) I hope to use it and never again have these stupid typos :-) Thanks! -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#374203: First patch
Package: www.debian.org
Followup-For: Bug #374203
I have made a patch which _seems_ to at least make the situation better.
However, I'm not sure how to make the tests (I have tried a couple of things
in gluck, but I haven't been able to get the page published in
w.d.o/devel/people with the CVS version), so I don't know what will the
patched script output, when given the correct arguments.
How can I find out how to call the script, so I get the published output and
start doing real tests?
Meanwhile, can you review the patch or make any comments?
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16-2-686
Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored:
LC_ALL set to [EMAIL PROTECTED])
--- people.pl.orig 2006-08-21 07:31:07.0 -0600
+++ people.pl 2006-08-21 07:58:42.0 -0600
@@ -483,11 +483,13 @@
sub process_homepages {
my $filename = @_;
- my (%uid, %page, $name);
+ my (%uid, %page, $name, $homepageurl);
my ($ldap_cn, $ldap_sn);
# get the stuff from the LDAP database
+ my $line_n = 0;
foreach (`ldapsearch -x -h db.debian.org -b dc=debian,dc=org uid=\* cn mn sn
labeledURI`) {
+$line_n++;
chomp; my $line = $_;
if ($line =~ /^(dn: )?uid=(.+),.+$/) { $name = $2; }
elsif ($line =~ /^cn(=|: )(.+)$/) { $ldap_cn =
from_utf8_or_iso88591_to_sgml($2); }
@@ -505,9 +507,15 @@
# warn had to decode: $worddata\n;
}
elsif ($line =~ /^labeledURI(=|: )(.+)$/) {
- my $homepageurl = $2;
+ $homepageurl = $2;
$homepageurl =~ s,^www,http://www,;
+}
+elsif ($line eq or $line =~ /^((version|search|result):|#)/) {
# warn $ldap_cn. .$ldap_sn. .$homepageurl.\n;
+ unless (defined $ldap_cn) {
+ print STDERR Skipping data, as cn appears to be empty (line
$line_n)\n;
+ next;
+ }
my $has_package = 0;
foreach my $person (keys %People) {
if ($person =~ /(.*):(.*)/) {
@@ -532,8 +540,9 @@
$People{$person}{homepage} = $homepageurl;
# warn Adding $person even though they don't have any
packages\n;
}
+
+ $homepageurl = $name = $ldap_cn = $ldap_sn = ;# Reset
data
}
-elsif ($line eq or $line =~ /^((version|search|result):|#)/) { next; }
else { die Error: unknown format on line $.:\n$_\n; }
}
Bug#358979: Any news?
Hi Bastian, Any news on pyvnc2swf? I could check your package, and probably sponsor... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#360986: Experimental fix
Hi Sjoerd, I already committed the $(strip ...) fix to SVN, thanks. But, I'm still not sure about the other change (not using $(DESTDIR), so the _generated_ Makefile variables are used, and using local $(DEB_DESTDIR) instead). My initial intention was just that, using $(DESTDIR) from the generated Makefile, because I thought it would be better to use the information already contained in the generated Makefile. Moreover, it seemed to work OK for me, but I'm not sure, as the package FTBFS for me (not recent enough libraries, I think). So, can you please tell me what's the rationale behind using $(DEB_DESTDIR)? And, does it work for you with $(DESTDIR) _at all_, or do you simply _need_ $(DEB_DESTDIR)? TIA. Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es signature.asc Description: Digital signature
Bug#374203: Bug in people.names generation
Package: www.debian.org Severity: minor In http://www.us.debian.org/devel/people, my name appears twice. The first time, it appears at Manchado Velázquez, Esteban, which is the correct one, but I appear as having no packages, and my homepage appears as http://superduper.net/, which isn't correct either. The second time, I appear as Velázquez, Esteban Manchado, which is wrong (in Spain we use _two_ surnames), but my packages are there (no homepage appears, though, and I have demiurgo.org as my homepage in LDAP). I couldn't find any documentation in people.wml [1] as of how people.names is generated, so I haven't actually tried to find the bug. Some information would be appreciated, so I can help fixing it myself. [1] http://cvs.debian.org/webwml/english/devel/people.wml?rev=1.13root=webwmlview=auto -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED])
Bug#341756: About Debian package relevation bug
On Wed, Jun 14, 2006 at 05:45:23PM -0700, Johannes Graumann wrote: Go ahead and close this bug. Didn't have any issues with the more recent packages. OK, thanks. It seems you can close the bug, Stefan :-) On Saturday 10 June 2006 11:17, you wrote: Hi Johannes, Did you try the last suggestion from Stefan Völkel (see http://bugs.debian.org/341756 for details)? We would like to chase down the bug and definitely close it, if possible... TIA. Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es signature.asc Description: Digital signature
Bug#360986: Experimental fix
Hi Sjoerd, I've made an ugly hack to try to fix this bug. Could you please try it out? It seems to work for me, but... I'm sending attached the new ruby-extconf-rb.mk. Please put it in /usr/share/ruby-pkg-tools/1/class/, after making a backup of the original file, just in case. Let me know if it works for you... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! # -*- mode: makefile; coding: utf-8 -*- # Copyright © 2006 Thierry Reding [EMAIL PROTECTED] # Description: # ifndef _cdbs_bootstrap _cdbs_scripts_path ?= /usr/lib/cdbs _cdbs_rules_path ?= /usr/share/cdbs/1/rules _cdbs_class_path ?= /usr/share/cdbs/1/class endif ifndef _cdbs_class_ruby-extconf-rb _cdbs_class_ruby-extconf-rb := 1 include /usr/share/ruby-pkg-tools/1/class/ruby-common.mk DEB_RUBY_SETUP_RUBY_ARGS = -rglobal.rb DEB_RUBY_SETUP_CMD = extconf.rb DEB_RUBY_SETUP_ARGS = cdbs_pkgdir = $(CURDIR)/debian/$(cdbs_curpkg) cdbs_ruby_libdir_ver = $(cdbs_pkgdir)$(strip $(DEB_RUBY_LIBDIR))/$(cdbs_ruby_ver) DEB_RUBY_INSTALL_ARGS = DESTDIR=$(cdbs_pkgdir) \ sitelibdir=$(cdbs_ruby_libdir_ver) # Build simple packages. $(patsubst %,build/%,$(DEB_RUBY_SIMPLE_PACKAGES)) :: build/% : cd $(DEB_SRCDIR) echo '$$extout = $$(DESTDIR)/$(DEB_RUBY_LIBDIR)/$(cdbs_ruby_ver)' global.rb /usr/bin/ruby $(DEB_RUBY_SETUP_RUBY_ARGS) $(DEB_RUBY_SETUP_CMD) $(DEB_RUBY_SETUP_ARGS) $(MAKE) # Install simple packages. $(patsubst %,install/%,$(DEB_RUBY_SIMPLE_PACKAGES)) :: install/% : cd $(DEB_SRCDIR) $(MAKE) install $(DEB_RUBY_INSTALL_ARGS) # Install regular library packages. $(patsubst %,install/%,$(DEB_RUBY_REAL_LIB_PACKAGES)) :: install/% : cd $(DEB_SRCDIR) -$(MAKE) distclean echo '$$extout = $$(DESTDIR)/$(DEB_RUBY_LIBDIR)/$(cdbs_ruby_ver)' global.rb /usr/bin/ruby$(cdbs_ruby_ver) $(DEB_RUBY_SETUP_RUBY_ARGS) $(DEB_RUBY_SETUP_CMD) $(DEB_RUBY_SETUP_ARGS) $(MAKE) $(MAKE) install $(DEB_RUBY_INSTALL_ARGS) clean:: -$(MAKE) distclean rm -f $(DEB_SRCDIR)/global.rb endif signature.asc Description: Digital signature
Bug#368035: dhelp doesn't show any help
On Sat, Jun 10, 2006 at 11:54:26PM +0200, Emil Nowak wrote: [...] 2) Can you send your index.html to the bug report, so we can inspect its contents? oki. It's attached to this message. Thanks. The debian link in HTML/index.html works, right? What about the contents of HTML/debian/index.html? Are there links in that file? Do they work? 3) Can you run dhelp_parse -r, as root, and paste here the output? Are there any errors? Is there anything in /usr/share/doc/HTML now? there was no error, and /usr/share/doc/HTML is still empty. OK. Do you have doc-base installed? If not, can you try installing it and checking the HTML directory. If it's still empty, just run again dhelp_parse -r and check again. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#372074: ocamlopt not in s390 version of ocaml-nox. Why?
Hi, [CC'ing ocaml-nox maintainers] I was browsing the bug list, and found #372074 (assigned to cameleon). It's a FTBFS bug in s390 (probably others), because it can't find the ocamlopt program. A quick check revealed that the program is usually available in the ocaml-nox package (see [1]), but it's _not_ there for s390 (see [2]). I don't know if that's a bug on ocaml-nox or what. So, the question is, why isn't ocamlopt in the ocaml-nox package for s390? Is there any workaround, or simply cameleon won't work in that architecture? -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! [1] http://packages.debian.org/cgi-bin/search_contents.pl?word=ocamloptsearchmode=searchfilescase=insensitiveversion=unstablearch=i386 [2] http://packages.debian.org/cgi-bin/search_contents.pl?word=ocamloptsearchmode=searchfilescase=insensitiveversion=unstablearch=s390 signature.asc Description: Digital signature
Bug#368035: dhelp doesn't show any help
Hi Emil, A couple of questions concerning you bug report: 1) Is /usr/share/doc/HTML empty, apart from index.html? 2) Can you send your index.html to the bug report, so we can inspect its contents? 3) Can you run dhelp_parse -r, as root, and paste here the output? Are there any errors? Is there anything in /usr/share/doc/HTML now? TIA, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es signature.asc Description: Digital signature
Bug#347980: Help categories
package dhelp merge 347980 334789 thanks Hi, We should really make an official document category list, and enforce it with the appropriate tools. See #19076 for more details... For now, we can always lowercase the categories... Dan: I don't think no bug is worth duplicating _on purpose_. It bugs the maintainers and makes the bug list longer and thus harder to manage. Please don't do that again. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#372530: ITP: libhighline-ruby -- High-level interactive IO Ruby library
Package: wnpp Severity: wishlist Owner: Esteban Manchado Velázquez [EMAIL PROTECTED] * Package name: libhighline-ruby Version : 1.2.0 Upstream Author : James Edward Gray II [EMAIL PROTECTED] * URL : http://highline.rubyforge.org/ * License : Ruby's and GPL Programming Lang: Ruby Description : High-level interactive IO Ruby library High-level IO library that provides validation, type conversion, and more for command-line interfaces. HighLine also includes a complete menu system that can crank out anything from simple list selection to complete shells with just minutes of work. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED])
Bug#358014: Fixed bug in libcommandline-ruby 0.7.10-6
Hi, The bug was fixed in libcommandline-ruby 0.7.10-6, I just forgot to close it in the changelog... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#362828: Missing Depends: on python-gnome2
Package: blogtk Version: 1.1-1 Severity: normal Tags: patch blogtk needs to depend on python-gnome2 to work. Right now, it depends on python-gnome2-extras | python-gnome2, but it really needs to depend on python-gnome2. Else, the following error is spit out: - 8 - [EMAIL PROTECTED]:~/tmp$ BloGTK Traceback (most recent call last): File /usr/bin/BloGTK, line 28, in ? import preview File /usr/lib/blogtk/preview.py, line 11, in ? import gnome ImportError: No module named gnome - 8 - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-d610 Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED]) Versions of packages blogtk depends on: ii python2.3.5-5An interactive high-level object-o ii python-glade2 2.8.2-3GTK+ bindings: Glade support ii python-gnome2 2.12.3-2 Python bindings for the GNOME desk ii python-gnome2-extras 2.12.1-2.1 Python bindings for the GNOME desk ii python-gtk2 2.8.2-3Python bindings for the GTK+ widge Versions of packages blogtk recommends: ii aspell0.60.4-3 GNU Aspell spell-checker -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#358897: ITP: libtext-format-ruby -- Ruby library for text formatting
Package: wnpp Severity: wishlist Owner: Esteban Manchado Velázquez [EMAIL PROTECTED] * Package name: libtext-format-ruby Version : 1.0.0 Upstream Author : Austin Ziegler [EMAIL PROTECTED] * URL : http://rubyforge.org/projects/text-format/ * License : Ruby's/Artistic Description : Ruby library for text formatting Text::Format is provides the ability to nicely format fixed-width text with knowledge of the writeable space (number of columns), margins, and indentation settings. Text::Format can work with either TeX::Hyphen or Text::Hyphen to hyphenate words when formatting. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-d610 Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED])
Bug#358014: [Pkg-ruby-extras-maintainers] Bug#358014: libcommandline-ruby1.8: CommandLine::Application requires 'text/format'
Hi, On Tue, Mar 21, 2006 at 10:45:39AM +0100, Paul van Tilburg wrote: On Mon, Mar 20, 2006 at 08:37:41PM +0100, stefan kersten wrote: Package: libcommandline-ruby1.8 Version: 0.7.10-4 Severity: grave Justification: renders package unusable /usr/lib/ruby/1.8/commandline/application.rb requires 'text/format' which is not made available by the package's dependencies. I could only find one instance of this library anywhere in Debian: --- usr/share/rails/actionmailer/lib/action_mailer/vendor/text/format.rb - web/rails --- Besides the fact that IMHO rails needs to be split up a bit more, we need to either package text/format (which is a vendor sublibrary of action_mailer) or make it work without it. What do you think, Esteban? It seems it's getting it from /usr/lib/ruby/gems/1.8/gems/text-format-1.0.0/lib/text/format.rb on my system (i.e., a gem). I've just filed an ITP for libtext-format-ruby, to have it packaged and make libcommandline-ruby depend on it. I don't have the bug number yet... Sorry I didn't notice myself before uploading. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#335082: Really reassigning
reassign 335082 libtabe-dev thanks -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#133218: Merge error
unmerge 133218 thanks The bug is wrongly merged: #133218 is not the same as #114588. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#151649: Merging bugs
merge 151649 102393 thanks It seems it's the same... -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#335082: Reassigning bug to libtabe
reassign 335082 libtabe-dev thanks This bug is in libtabe-dev, which provides /usr/share/doc/libtabe-dev/.dhelp, which in turn links to the non-existent file libtabe.html: -- 8 -- item directorydevel linknamelibtabe Manual filenamelibtabe.html description This manual gives thorough description of libtabe and its structure /description /item -- 8 -- Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#19076: More information on sections
Hi, It seems that dhelp has another (?) section list. Quoting /usr/share/doc/dhelp/dhelp.html (The .dhelp file section): 8 directory Defines in which section of the index the document should be linked. I suggest that you use the same names like in Section: in control. For example for a game you would use games. A German document should linked to de/games and so on. You can find all supported sections in .dhelp. You can create additional sections if necessary. 8 So it seems dhelp uses the debian/control section list, not the doc-base one, which is weird. Shouldn't doc-base and dhelp use the same conventions? In fact, I think there should be some kind of validation on the section field :-/ -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#193428: Clarification
usertag 193428 + ignore thanks Hi, Sorry for the previous message, we _are_ still using the .dhelp format, although perhaps not directly (doc-base generates a .dhelp file automatically and then uses dhelp_parse, AFAICT), so the bug still apply in that sense. But, if the new dhelp_parse version, in Ruby, is finally included in a next version of the dhelp package, the segmentation fault problem will go away. I just tested the first of your files with the Ruby version, and it seems to work fine, but the documents have the wrong path (they are incorrectly linked, then, in the generated HTML), and some of them seem to not be there anymore... Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#341904: ITP: libjson-ruby -- JSON library for Ruby
Package: wnpp Severity: wishlist Owner: Esteban Manchado Velázquez [EMAIL PROTECTED] * Package name: libjson-ruby Version : 0.4.0 Upstream Author : Florian Frank [EMAIL PROTECTED] * URL : http://json.rubyforge.org/ * License : GPL Description : JSON library for Ruby This library implements the JSON (JavaScript Object Notation) specification in Ruby, allowing the developer to easily convert data between Ruby and JSON. You can think of it as a low fat alternative to XML, if you want to store data to disk or transmit it over a network rather than use a verbose markup language. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14 Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED])
Bug#340376: libcommandline-ruby1.8: incomplete doc-base files break installation
Hi Aaron, On Wed, Nov 23, 2005 at 09:52:04AM -0500, Aaron M. Ucko wrote: [...] OK. In fact, I'm not sure what's the best place to put the documentation. I think I'm going to move the documentation to the dummy package and perhaps create symbolic links in the rest. Anything against that? The problem with that is that the dummy package won't necessarily be installed -- unless you set up circular dependencies, but we're trying to cut down on those. Yes, I know it it's necessarily installed, but I thought that it was a good enough compromise (for simplicity and don't get repeated files). I never thought about circular dependencies, don't worry ;-) Given that the documentation is still pretty small in an absolute sense, it should be okay to leave it as it is and just rename the doc-base files as I suggested. Alternatively, you could split it out into a new -common or -doc package, but the ftpmasters might consider that to be overkill. We're currently discussing how to package Ruby libraries in [EMAIL PROTECTED], that's why I haven't uploaded a new version yet. I think I'm going to fix the doc-base thing, and in another upload, when we have the proposal for the new Ruby policy, I'll fix it completely. -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#340376: libcommandline-ruby1.8: incomplete doc-base files break installation
Hi Aaron, On Tue, Nov 22, 2005 at 08:56:10PM -0500, Aaron M. Ucko wrote: Package: libcommandline-ruby1.8 Version: 0.7.10-1 Severity: serious Justification: Policy 9.10 (doc-base section 2.3) [...] It is mandatory to specify Files even if the only relevant file is the one already specified as the Index; could you please do so? Oops, sorry, I shouldn't have uploaded the package in its current state. Fixed in SVN. I will upload soon. Incidentally, it would probably also be wise to give the doc-base files versioned names (say, by appending -1.8) so that you won't run into trouble if you add support for other Ruby versions down the road. OK. In fact, I'm not sure what's the best place to put the documentation. I think I'm going to move the documentation to the dummy package and perhaps create symbolic links in the rest. Anything against that? Thanks for caring, and sorry for uploading the package as is :-( -- Esteban Manchado Velázquez [EMAIL PROTECTED] EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es Help spread it through the Net in signatures, webpages, whatever! signature.asc Description: Digital signature
Bug#338634: ITP: libcommandline-ruby -- Ruby library to building a command
Package: wnpp Severity: wishlist Owner: Esteban Manchado Velázquez [EMAIL PROTECTED] * Package name: libcommandline-ruby Version : 0.7.10 Upstream Author : Jim Freeze * URL : http://rubyforge.org/projects/optionparser/ * License : BSD-style Description : Ruby library for building command-line applications This library greatly simplifies the repetitive process of building a command line user interface for your applications. It's 'ruby-like' usage style streamlines application development so that even applications with numerous configuration options can be quickly put together. CommandLine automatically builds friendly usage and help screens that are nicely formatted for the user. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: [EMAIL PROTECTED], LC_CTYPE=ISO_8859_1 (charmap=ISO-8859-15) (ignored: LC_ALL set to [EMAIL PROTECTED])
Bug#336052: preinst fails if tetex-bin not installed
Package: lilypond Version: 2.6.3-9 Severity: important Tags: patch lilypond doesn't Depends: on tetex-bin, which makes it uninstallable: 8 hunter:/home/zoso# apt-get install lilypond Leyendo lista de paquetes... Hecho Creando rbol de dependencias... Hecho Se instalarn los siguientes paquetes NUEVOS: lilypond 0 actualizados, 1 se instalarn, 0 para eliminar y 65 no actualizados. 1 no instalados del todo o eliminados. Se necesita descargar 0B/1175kB de archivos. Se utilizarn 2904kB de espacio de disco adicional despus de desempaquetar. (Leyendo la base de datos ... 119852 ficheros y directorios instalados actualmente.) Desempaquetando lilypond (de .../lilypond_2.6.3-9_i386.deb) ... /var/lib/dpkg/tmp.ci/preinst: line 19: /usr/bin/kpsewhich: No existe el fichero o el directorio dpkg: error al procesar /var/cache/apt/archives/lilypond_2.6.3-9_i386.deb (--unpack): el subproceso pre-installation script devolvi el cdigo de salida de error 1 Se encontraron errores al procesar: /var/cache/apt/archives/lilypond_2.6.3-9_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) 8 Sorry for the Spanish, the important line (translated) is: 8 /var/lib/dpkg/tmp.ci/preinst: line 19: /usr/bin/kpsewhich: No such file or directory 8 AFAICT, the problem is lilypond not depending on tetex-bin: 8 hunter:/home/zoso# dpkg -S /usr/bin/kpsewhich tetex-bin: /usr/bin/kpsewhich 8 Of course, installing tetex-bin makes lilypond's preinst happy. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages lilypond depends on: ii guile-1.6 [guile] 1.6.7-1.1 The GNU extension language and Sch ii guile-1.6-libs1.6.7-1.1 Main Guile libraries ii libc6 2.3.5-7GNU C Library: Shared libraries an ii libfontconfig12.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-3 GCC support library ii libglib2.0-0 2.8.3-1The GLib library of C routines ii libguile-ltdl-1 1.6.7-1.1 Guile's patched version of libtool ii libpango1.0-0 1.8.2-3Layout and rendering of internatio ii libqthreads-121.6.7-1.1 QuickThreads library for Guile ii libstdc++64.0.2-3The GNU Standard C++ Library v3 ii lilypond-data 2.6.3-9LilyPond music typesetter (data fi ii python2.3.5-3An interactive high-level object-o ii zlib1g1:1.2.3-6 compression library - runtime Versions of packages lilypond recommends: ii lilypond-doc 2.6.3-9LilyPond Documentation in HTML, PS -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#19076: More info on #19076
Hi all, I'm looking at this bug, but I don't know what to do. If the only problem is lowercasing sections, it's already done (it seems). However, I've found a couple of empty titles myself: 8 [EMAIL PROTECTED]:~/src/debian/dhelp/dhelp-0.5.21$ egrep -r TITLE /usr/share/doc/HTML /usr/share/doc/HTML/standards/index.html:TITLE/TITLE /usr/share/doc/HTML/web/w3c/index.html:TITLE/TITLE 8 I wondered, then, if standards and web/w3c were valid sections, so I looked for the canonical doc-base section list. What I found was: 8 Section Section where the document belongs; this should follow the sections outlined in The Debian Menu sub-policy. 8 (in /usr/share/doc/doc-base/doc-base.txt.gz) But the Debian Menu sub-policy section list (http://www.us.debian.org/doc/packaging-manuals/menu-policy/ch2.html) doesn't seem to be used everytime. I have a couple of packages installed, right now, with documentation registered in sections not in the Menu sub-policy. So, what's the canonical list? And, if it's the Debian Menu sub-policy one, why doesn't doc-base give a warning or some hint? Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Bug#162518: Solved by the patch for #146002
Hi, This feature is implemented by the patch attached to #146002. Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Bug#158792: Add patch
tag 158792 +patch
thanks
Hi,
I was able to easily reproduce the bug. You only have to:
-- 8 --
velutha:/home/zoso/src/debian/dhelp/dhelp-0.5.21# umask
0022
velutha:/home/zoso/src/debian/dhelp/dhelp-0.5.21# umask 0077
velutha:/home/zoso/src/debian/dhelp/dhelp-0.5.21# /usr/sbin/dhelp_parse -r
velutha:/home/zoso/src/debian/dhelp/dhelp-0.5.21# ls /usr/share/doc/HTML/ | head
total 68
drwx-- 2 root root 4096 2005-09-03 20:41 admin/
drwx-- 2 root root 4096 2005-09-03 20:41 debian/
drwx-- 2 root root 4096 2005-09-03 20:41 graphics/
-rw--- 1 root root 2782 2005-09-03 20:41 index.html
drwx-- 2 root root 4096 2005-09-03 20:41 math/
drwx-- 2 root root 4096 2005-09-03 20:41 misc/
drwx-- 2 root root 4096 2005-09-03 20:41 net/
drwx-- 2 root root 4096 2005-09-03 20:41 programming/
-rw--- 1 root root 144 2005-09-03 20:41 README
velutha:/home/zoso/src/debian/dhelp/dhelp-0.5.21# ./dhelp_parse -r # Patched
velutha:/home/zoso/src/debian/dhelp/dhelp-0.5.21# ls /usr/share/doc/HTML/ | head
total 68
drwxr-xr-x 2 root root 4096 2005-09-03 20:42 admin/
drwxr-xr-x 2 root root 4096 2005-09-03 20:42 debian/
drwxr-xr-x 2 root root 4096 2005-09-03 20:42 graphics/
-rw-r--r-- 1 root root 2782 2005-09-03 20:42 index.html
drwxr-xr-x 2 root root 4096 2005-09-03 20:42 math/
drwxr-xr-x 2 root root 4096 2005-09-03 20:42 misc/
drwxr-xr-x 2 root root 4096 2005-09-03 20:42 net/
drwxr-xr-x 2 root root 4096 2005-09-03 20:42 programming/
-rw-r--r-- 1 root root 144 2005-09-03 20:42 README
velutha:/home/zoso/src/debian/dhelp/dhelp-0.5.21# umask
0077
velutha:/home/zoso/src/debian/dhelp/dhelp-0.5.21#
-- 8 --
Find attached a micro-patch to set a sane umask before proceeding. It works
for me (TM).
Regards,
--
Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
--- dhelp_parse.c-orig 2005-09-03 20:33:44.652199016 +0100
+++ dhelp_parse.c 2005-09-03 20:38:35.120041192 +0100
@@ -786,6 +786,10 @@
return (1);
}
+ /* set a sane umask, as we're probably going to generate system-wide files
+ * that must be readable (documentation and all of that) */
+ umask(0022);
+
if (!strcmp (argv[1], -r))
{
remove (DBNAME); /* loesche db, um alte/falsche Eintraege
Bug#146002: Incomplete patch
Hi,
The patch I attached is incomplete: you also have to remove the debconf
references to the /etc/dhelp/www-browser-{x,console} files.
For that, I think it's enough applying the attached patch and removing
altogether debian/config and debian/po (sorry for the translators :-( ).
Regards,
--
Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
--- debian/postinst-orig2005-09-03 20:17:04.880187464 +0100
+++ debian/postinst 2005-09-03 20:22:32.247420080 +0100
@@ -17,9 +17,6 @@
# Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA.
-# source debconf library
-. /usr/share/debconf/confmodule
-
# create configuration directory if necessary
if [ ! -d /etc/dhelp ]; then
mkdir /etc/dhelp
@@ -30,12 +27,6 @@
mkdir /var/lib/dhelp
fi
-# store debconf configuration values in files there
-db_get dhelp/www-browser-console
-echo $RET /etc/dhelp/www-browser-console
-db_get dhelp/www-browser-x
-echo $RET /etc/dhelp/www-browser-x
-
# remove /usr/doc/HTML2 if upgrading from old dhelp package
if [ $1 = configure -a -d /usr/doc/HTML2 ]; then
rm -rf /usr/doc/HTML2
--- debian/rules-orig 2005-09-03 20:24:25.349225992 +0100
+++ debian/rules2005-09-03 20:24:38.898166240 +0100
@@ -38,7 +38,6 @@
mkdir -p $(R)/usr/lib/cgi-bin
cp dsearch $(R)/usr/lib/cgi-bin
- dh_installdebconf
dh_fixperms
dh_shlibdeps
dh_strip
--- debian/control-orig 2005-09-03 20:24:27.834848120 +0100
+++ debian/control 2005-09-03 20:24:34.586821664 +0100
@@ -6,7 +6,7 @@
Build-Depends: libdb3-dev, debhelper (= 4.1.16)
Package: dhelp
-Depends: ${shlibs:Depends}, debconf, perl-modules
+Depends: ${shlibs:Depends}, perl-modules
Recommends: mozilla-firefox | www-browser
Suggests: httpd, swish++, info2www, man2html
Architecture: any
Bug#115306: Obsolete bug
usertag 115306 + ignore thanks Hi, I think this bug is obsolete: - 8 - [EMAIL PROTECTED]:~/src/debian/dhelp/dhelp-0.5.21$ glark -r bgcolor . [EMAIL PROTECTED]:~/src/debian/dhelp/dhelp-0.5.21$ glark -r bgcolor /usr/share/doc/HTML/ [EMAIL PROTECTED]:~/src/debian/dhelp/dhelp-0.5.21$ - 8 - What bgcolor??? -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Bug#102393: Obsolete?
Hi, I don't know what to do to reproduce this bug. Perhaps it's obsolete? Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Bug#151649: Should probably be merged with #102393
Hi, I think this bug is the same as #102393, but I'm not merging them, just in case... Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Bug#193428: Obsolete bug
Hi, This bug is obsolete, right? Now we're finally using the doc-base format, so the .dhelp thing doesn't apply, or does it? Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Bug#217162: Obsolete
Hi, If we begin to use sensible-browser (see #146002), this doesn't make sense anymore. Perhaps we should forward the bug to debianutils, if it doesn't already have that feature (I think it doesn't). Regards, -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Bug#155054: Fixable in dhelp?
Hi, I don't think this can be fixed in the dhelp package... I'm not even sure that a technical section still exists... close bug? -- Esteban Manchado Velázquez [EMAIL PROTECTED] - http://www.foton.es EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
