Re: limitations of reportbug and BTS
Frans Pop <[EMAIL PROTECTED]> wrote: > On Wednesday 15 February 2006 20:56, Marco d'Itri wrote: >> On Feb 15, kamaraju kusumanchi <[EMAIL PROTECTED]> wrote: >> > This kind of thing is not possible currently. Do you think it is a >> > good implement such a feature? Currently bugs.kde.org allows this >> > (searching for strings in the bug reports without worrying about >> > package names etc.,). >> >> You use google groups to search the linux.debian.bugs.dist newsgroup. > > Maybe we should document that on the bugs.debian.org main webpage. Can't we include a form where you put in your search text, click search, and the complete thing is transferred to Google? One can still click on "Advanced Search" later on. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: limitations of reportbug and BTS
#include * Frank Küster [Thu, Feb 16 2006, 09:06:06AM]: > >> You use google groups to search the linux.debian.bugs.dist newsgroup. > > > > Maybe we should document that on the bugs.debian.org main webpage. > > Can't we include a form where you put in your search text, click search, > and the complete thing is transferred to Google? One can still click on > "Advanced Search" later on. Or the search machine of the choice for those who do not thrust Google. Eduard. -- verwendet ihr irgendein web-ding zum speichern von dokus? wenn ja - welches? pluesch: google? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
On Fri, Feb 10, 2006 at 02:54:09PM +0200, Lars Wirzenius wrote: > Thus the thing to do is to provide HTML. I disagree, the thing to do is to provide HTML *and* an easy to print format, that is PS or PDF. > It would be nice to be able to ship, say, HTML and SGML, and then have a > quick and easy way to generate other formats (PS/PDF for various paper > sizes, at least) from the SGML, and anyone who creates the tools to do > that will get a lot of goodwill. It is much better if the binary package provides a ready to use PS/PDF version than force the user to do it since there have been known issues in which the PDF generation (specially for some languages) is not as robust as it should be. If the package generates a PS/PDF (and the maintainer reviews that it is correct) it saves the user from having to struggle through the generation of a PS/PDF version if he encounters an issue when generating it (which might be due to a local issue, a bug in the sgml toolchain, a font issue or whatever). That saves the maintainer bug reports and saves the users the hassle of handling (obscure) documentation formats. Providing the SGML source is (IMHO) akin to saying that packages should provide source code and compile it on the user's systems (think Gentoo). It is *much* more flexible, but much more open to bugs. Moreover, I know of *no* -doc packages that provide SGML format so there is not that much experience (or tools) on how to automatically do what others suggest (dwww integratin). Check out the documents from the DDP (that is, the FAQ, the d-i manual, the Debian reference, the Securing Debian Manual) and the formats provided in their binary packages, they are, usually, three formats: text, HTML and PDF. Best regards Javier signature.asc Description: Digital signature
Re: limitations of reportbug and BTS
Eduard Bloch <[EMAIL PROTECTED]> writes: > Or the search machine of the choice for those who do not thrust Google. I think most of those types are holed up in a bunker cradling a machine gun. -miles -- `Suppose Korea goes to the World Cup final against Japan and wins,' Moon said. `All the past could be forgiven.' [NYT] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353117: ITP: libphp-xajax -- A PHP library to develop Ajax applications
Package: wnpp Severity: wishlist Owner: David Gil <[EMAIL PROTECTED]> * Package name : libphp-xajax Version : 0.2 Upstream Authors : Jared White <[EMAIL PROTECTED]> J. Max Wilson <[EMAIL PROTECTED]> * URL : http://www.xajaxproject.org/ * License : LGPL Description : A PHP library to develop Ajax applications xajax is a PHP library that you can include in your PHP scripts to provide an easy way for Web pages to call PHP functions or object methods using Ajax (Asynchronous Javascript And XML). Simply register one or more functions/methods with the xajax object that return a proper XML response using the supplied response class, add a statement in your HTML header to print the Javascript include, and run a request processor prior to outputting any HTML. Then add some simple Javascript function calls to your HTML, and xajax takes care of the rest! xajax includes a Javascript object to facilitate the communication between the browser and the server, and it can also be used as a Javascript library directly to simplify certain DOM and event manipulations. However, you can definitely choose to use a dedicated Javascript "engine" of your liking and integrate it with xajax's client/server communication features in a number of ways. More tightly-coupled integration will be forthcoming in a future version of xajax. The official xajax Web site is located at: http://www.xajaxproject.org Visit the xajax Forums at: http://community.xajaxproject.org to keep track of the latest news and participate in the community discussion. There is also a wiki with documentation, tips & tricks, and other information located at: http://wiki.xajaxproject.org -- 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.15-1-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Security update modifies (inofficial) ABI and hidden API
Hi Joey, On Sat, Feb 11, 2006 at 09:02:37PM +0100, Martin Schulze wrote: > We could use some advice and help with the GnuTLS / libasn1 update > that would fix the vulnerabilities reported recently. > The fix for libasn1 adds arguments to exported function. However, > these functions are named _asn_* and should not be used outside of > this library. > Unfortunately GnuTLS is doing exactly this, using these functions. > Other packages "should" not be affected. > GnuTLS is also problematic as it seems to use both its internal copy > of libasn and is linked about the libasn package. > The officially supported ABI+API hasn't been changed by the security > update. > We'll have to update libasn and GnuTLS at the same time anyway. > However, does the security update need to bump the soname as well? If > so, is somebody willing to dig into its packaging and bump it? > What about GnuTLS? Does GNUTLS get the prototypes for these "internal" functions from public headers in libtasn1-2-dev? If so, it sounds like a complete audit of all reverse-deps would be needed. :( If not, and upstream says that gnutls is the only package that should be using them, I think it should be ok to rebuild without changing the package name -- just adding a conflicts w/ old versions of libgnutls11. Yes, the _asn1_* functions aren't exported in the libtasn1.h header, so I would say it's ok to make this change without renaming the package. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
Miles Bader <[EMAIL PROTECTED]> writes: > Jari Aalto <[EMAIL PROTECTED]> writes: >> The Perl syntax is elegant, efficient and Python's regexp handling is >> nowhere as intuitive as needed for day-to-day tasks where the poer is >> needed. > Efficient, perhaps, but _elegant_?!? HAhahahahah1hahah3$I17-e87 > > Perl is an utter mess, with a few nice bits here and there. I know that religious wars about programming languages are all fun and give you the warm and fuzzy feeling around the head you love SOOO much, but we had our share. So unless you have *anything* to say about the actual topic of the discussion, just shut up. Thanks! Marc -- BOFH #15: temporary routing anomoly pgpiYRfSRpEUa.pgp Description: PGP signature
Re: Size matters. 7zip. Again.
"rzip is not for everyone! The two biggest disadvantages are that you can't pipeline rzip (so it can't read from standard input or write to standard output), and that it uses lots of memory. A typical compression run on a large file might use a couple of hundred MB of ram. If you have ram to burn and want the best possible compression rate then rzip is probably for you, otherwise stick with bzip2 or gzip." I'm not sure whether not being able to pipeline it might be a problem, but needing that huge amount of RAM might, at least in my oppinion. I'm not sure if they're refering just to compression or both to compression and decompression anyway. Decompression doesn't take more memory than bunzip2 (in fact: less). I've tested the openoffice orig.tar from sarge and just watched top to get an idea. The only big issue is the needed memory for compression. My 256 MB machine needed very much swapping to finish the execution. The compression rate is not neccessarily better for rzip compared to bzip2: (The uncompressed tar file as about 1.2 MB) 170374 logwatch_7.2.1.orig.tar.bz2 218476 logwatch_7.2.1.orig.tar.gz 173941 logwatch_7.2.1.orig.tar.rz If you want to test this file, it's available from http://pkg-logwatch.alioth.debian.org/apt/pool/main/l/logwatch/ another example where rzip performes better: 141769841 openoffice.org_1.1.3.orig.tar.bz2 122258088 openoffice.org_1.1.3.orig.tar.rz 165M for the tar.gz the uncompressed archive has about 610 MB My conclusion is that rzip is not suitable for debian (source) packages, binary would one testing) because the compression for bigger is not feasable on machines with low ram (and even 256MB seem to be low RAM for rzip) and the compression rate is not so impressing. Willi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353141: ITP: libio-capture-perl -- Abstract Base Class to build modules to capture output.
Package: wnpp Severity: wishlist Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]> * Package name: libio-capture-perl Version : 0.05 Upstream Author : Mark Reynolds sgi.com>, Jon Morgan sgi.com> * URL : http://search.cpan.org/~reynolds/IO-Capture-0.05/ * License : Perl: GPL/Artistic Description : Abstract Base Class to build modules to capture output. The IO::Capture Module defines an abstract base class that can be used to build modules that capture output being sent on a filehandle such as STDOUT or STDERR. . Several modules that come with the distribution do just that. I.e., Capture STDOUT and STDERR. Also see James Keenan's IO::Capture::Stdout::Extended on CPAN. . See IO::Capture::Overview for a discussion of these modules and examples of how to build a module to sub-class from IO::Capture yourself. If after reading the overview, you would like to build a class from IO::Capture, look here for details on the internals. NOTE: I need this package to close: #329561 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
Am Donnerstag, 16. Februar 2006 10:04 schrieb Javier Fernández-Sanguino Peña: > On Fri, Feb 10, 2006 at 02:54:09PM +0200, Lars Wirzenius wrote: > > Thus the thing to do is to provide HTML. > > I disagree, the thing to do is to provide HTML *and* an easy to print > format, that is PS or PDF. > > > It would be nice to be able to ship, say, HTML and SGML, and then have a > > quick and easy way to generate other formats (PS/PDF for various paper > > sizes, at least) from the SGML, and anyone who creates the tools to do > > that will get a lot of goodwill. > > It is much better if the binary package provides a ready to use PS/PDF > version than force the user to do it since there have been known issues in > which the PDF generation (specially for some languages) is not as robust as > it should be. If the package generates a PS/PDF (and the maintainer reviews > that it is correct) it saves the user from having to struggle through the > generation of a PS/PDF version if he encounters an issue when generating it > (which might be due to a local issue, a bug in the sgml toolchain, a font > issue or whatever). That saves the maintainer bug reports and saves the > users the hassle of handling (obscure) documentation formats. > > Providing the SGML source is (IMHO) akin to saying that packages should > provide source code and compile it on the user's systems (think Gentoo). It > is *much* more flexible, but much more open to bugs. Ok, then you choose HTML and PDF. And the next user asks why he cannot get it in the format provided by docbook2xyz (substitute xyz with any possible value). If Debian may have problem with the SGML toolchain, then fix the toolchain instead of needlessly shipping hundreds files that all contain the same text and only differ in the format. Policy says to ship HTML, else I wouldn't. It would be great to have a new debhelper package that creates the previously chosen documentation formats from the provided SGML file on installation. This would save MUCH more in download size than any of the previously discussed compression formats (may it be bzip2, 7zip or whatever). And if the administrators choice is to not want any automatically created formats, he may use a docbook program that displays it from the SGML or XML source. Why not, such a tool may exist at one time or maybe does already. HS
Re: Chao ban ve may bay
Xin chao , Toi viet mail nay de muon biet gia ve di tu TP Ho Chi Minh den Paris , Phap danh cho mot doan khach khoang 15-20 nguoi se la bao nhieu? Ngay khoi hanh se la khoang 15 thang 7 nam 2006 va ngay tro ve la 22 thang 7 nam 2006. Rat mong thong tin cua quy vi. Xin cam on. QUELEN Guillaume
Free'ing documentation: How to include doc sources missing in the orig.tar.gz
Hello, teTeX contains a couple of documentation files that are definitely non-free (#345604) and need to be removed, but there are others that can be "made free"[1]. In other words, either they are licensed under a DFSG-compliant license, but the source is missing, or we manage to convince the authors to relicense them (and get the sources). I'm wondering what the correct way would be to make the source available. There are a couple of options: 1. Simply include a README file that tells users where the source for each document can be retrieved. 2. Collect all missing sources and release them as a separate source package, and informing about this in the original package. 3. Collect all missing sources and include them in the original source package. Naturally, 1 is less work for the teTeX maintainers than 2 and 3; the advantage of 2 over 3 is that the diff.gz is not bloated by adding text that is not in fact Debian-specific (but that's only a minor point, since we can collect everything in one directory). What do you think - would option 1 be acceptable? And a related question: I understood that there's no need to recreate documentation files that are included in the orig.tar.gz from their sources, it's enough that the sources are present. But now when the sources were not present in the beginning and we only add them, - Do we have to verify that the source actually can be "compiled" to a document? (I guess yes) - Do we have to verify that the generated document and the included document actually match? That would be hard manual work, at least in the case of LaTeX-generated files as most of ours are. In case that you think one of the questions, or your answer, is more appropriate to -legal, feel free to move there; but I think that these are in fact rather technical issues. TIA, Frank [1] note that we produce the tetex-doc binary package with Installed-Size: 64784 so this is not just one or two files... -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#353117: ITP: libphp-xajax -- A PHP library to develop Ajax applications
Le Jeu 16 Février 2006 11:21, David Gil a écrit : > Package: wnpp > Severity: wishlist > Owner: David Gil <[EMAIL PROTECTED]> > > * Package name : libphp-xajax should be : php-xajax. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpnY3LHmGfab.pgp Description: PGP signature
Re: limitations of reportbug and BTS
On Wed, Feb 15, 2006 at 08:14:53PM +, Brian M. Carlson wrote: > It searches for bugs on the source package, which in this case is > kdebase. You can change this behavior with --no-query-source. My guess > for the reason that --query-source is that quite frequently, especially > with libraries, bugs will be filed on the package in which someone has > found a bug, but the bug will also be present in other packages from the > same source. > > For example, see #145786, filed on libarts1 over 3 and one-half *years* > ago (and still not fixed). This bug is still present in libarts1c2a, > but because they are from the same source package, it can be assumed > that the maintainers know about this. It might make more sense to reassign those bugs to the current binary package in unstable in that case, maybe. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#353193: ITP: sqlitemanager -- Multilingual web based tool to manage SQLite databases
Package: wnpp Severity: wishlist Owner: Stefani Banerian <[EMAIL PROTECTED]> * Package name: sqlitemanager Version : x.y.z Upstream Author : Name <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : (GPL, LGPL, BSD, MIT/X, etc.) Description : Multilingual web based tool to manage SQLite databases SQLiteManager is a way to manage sqlite databases via the web. Some of its features: - Management of several databases (Creation, access or upload) - Create, edit and delete tables and indexes. - Insert, edit, delete records in these tables - Management of views, and ability to create a view from a SELECT - Management of triggers - Management of user-defined functions, as in the form of insertion/modification of data - Queries, either manual, or from filel; possible to define the format of the requests, sqlite or MySQL, with conversion in order to with conversion in order to directly import a MySQL database into SQLite. - Import of records from a formatted text file - Export of the structure and the data - Choice of several display skins -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-vs Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
On Fri, Feb 10, 2006 at 01:47:11PM +0100, Remi Vanicat wrote: > Well, i personally like very much to have all (well a lot of) my > documentation accessible, and searchable by dwww. For this I would want > the html to be already generated, and I'm probably not the only > one. Why not just create a -doc package that contain the tree of them, > or may be only pdf and html (but there will be people to disagree with > me on this). Hello Remi. Question please, for you and anyone else who cares to comment. I happen to maintain some documentation which has lots of mathematical formulas, geometrical diagrams, etc. I also happen to be upstream for this document. Docbook and other generic markups have always seemed to me a poor solution for the document, which currently is marked up only in LaTeX---but this also means that no general html/dhelp/dwww version of the document exists, and furthermore that the document's text is hard to grep. Regrettably but naturally, it also means that (unless the user is an odd sort who likes reading raw LaTeX source) the user cannot view the document on the console. At present the document is installed as a *.ps.gz and a *.pdf.gz only (there is a manpage, too, but it is brief and has no formulas or diagrams). Is this right in your view? Or would you advise maintainers like me to do otherwise? If there existed a better solution which did not greatly increase the labor of maintaining such documentation, I would be interested to learn of it. Maybe MathML is the answer---I have not tried it so I am not sure---but when it comes to numbering equations, stacking subscripts, formatting formulas too long to fit on one line, tracking citations, referring to figures, specifying vector graphics in diagrams, etc., one gets the impression that MathML and the associated tools may not quite be up to the job. In fact it is hard for me to imagine that any generic markup could do the job right. But I don't know and would be pleased to hear contrary advice in the matter. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: documentation types
"Thaddeus H. Black" <[EMAIL PROTECTED]> writes: > On Fri, Feb 10, 2006 at 01:47:11PM +0100, Remi Vanicat wrote: >> Well, i personally like very much to have all (well a lot of) my >> documentation accessible, and searchable by dwww. For this I would want >> the html to be already generated, and I'm probably not the only >> one. Why not just create a -doc package that contain the tree of them, >> or may be only pdf and html (but there will be people to disagree with >> me on this). > > Hello Remi. Question please, for you and anyone else who cares to > comment. I happen to maintain some documentation which has lots of > mathematical formulas, geometrical diagrams, etc. I also happen to be > upstream for this document. Docbook and other generic markups have > always seemed to me a poor solution for the document, which currently is > marked up only in LaTeX---but this also means that no general > html/dhelp/dwww version of the document exists, and furthermore that the > document's text is hard to grep. Note that you could try hevea/latexhtml to transform you documentation to html. It might even lead to good result. Just try (it might not be very good, but it might be good, hevea do a lot of good work for such translating). > Regrettably but naturally, it also means that (unless the user is > an odd sort who likes reading raw LaTeX source) the user cannot view > the document on the console. > > At present the document is installed as a *.ps.gz and a *.pdf.gz only > (there is a manpage, too, but it is brief and has no formulas or > diagrams). Is this right in your view? Or would you advise maintainers > like me to do otherwise? If there existed a better solution which did > not greatly increase the labor of maintaining such documentation, I > would be interested to learn of it. Maybe MathML is the answer---I have > not tried it so I am not sure---but when it comes to numbering > equations, stacking subscripts, formatting formulas too long to fit on > one line, tracking citations, referring to figures, specifying vector > graphics in diagrams, etc., one gets the impression that MathML and the > associated tools may not quite be up to the job. In fact it is hard for > me to imagine that any generic markup could do the job right. But I > don't know and would be pleased to hear contrary advice in the > matter. Well, when i wrote mathematical formula, it is in latex. I've heard of latex to MathML translator for formula that give you the possibilities to do wrote mathematical formula using the good old latex way, then translating it to MathML. -- Rémi Vanicat -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
On Thu, Feb 16, 2006 at 09:37:38PM +0100, Remi Vanicat wrote: > "Thaddeus H. Black" <[EMAIL PROTECTED]> writes: > > > On Fri, Feb 10, 2006 at 01:47:11PM +0100, Remi Vanicat wrote: > >> Well, i personally like very much to have all (well a lot of) my > >> documentation accessible, and searchable by dwww. For this I would want > >> the html to be already generated, and I'm probably not the only > >> one. Why not just create a -doc package that contain the tree of them, > >> or may be only pdf and html (but there will be people to disagree with > >> me on this). > > > > Hello Remi. Question please, for you and anyone else who cares to > > comment. I happen to maintain some documentation which has lots of > > mathematical formulas, geometrical diagrams, etc. I also happen to be > > upstream for this document. Docbook and other generic markups have > > always seemed to me a poor solution for the document, which currently is > > marked up only in LaTeX---but this also means that no general > > html/dhelp/dwww version of the document exists, and furthermore that the > > document's text is hard to grep. > > Note that you could try hevea/latexhtml to transform you documentation > to html. It might even lead to good result. Just try (it might not be > very good, but it might be good, hevea do a lot of good work for such > translating). In fact the recent version of HeVeA (1.08) largely improves over the previous versions when it comes to rendering of mathematical formulas, so I suggest you give it try. -Ralf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
On Thu, Feb 16, 2006 at 10:04:25AM +0100, Javier Fernández-Sanguino Peńa wrote: > Moreover, I know of *no* -doc packages that provide SGML format so there > is not that much experience (or tools) on how to automatically do what others > suggest (dwww integratin). IMHO SGML is losing ground in favor of XML. GNOME Help files are already DocBook/XML (AFAIK KDE Help also). So there is definitely precedence, and providing soma automatic, user-selectable DocBook/XML -> HTML translation would have meaning for dwww integraton. The other option is to say that GNOME/KDE can already display DocBook/XML without the HTML conversion phase, so allow DocBook/XML as an alternative of HTML in the policy. Maybe this is just wishful thinking. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
On Thu, Feb 16, 2006 at 04:43:11PM +0100, Hendrik Sattler wrote: > Ok, then you choose HTML and PDF. And the next user asks why he cannot get it > in the format provided by docbook2xyz (substitute xyz with any possible > value). The user always has the *source* package available to do as he pleases. Your solution does not provide a way to generate any format from the SGML sources, the front-end will still be limited. > If Debian may have problem with the SGML toolchain, then fix the toolchain > instead of needlessly shipping hundreds files that all contain the same text > and only differ in the format. The problem is that the toolchain might be ok, but having all the tools properly configured to, for example, compile proper PDF versions for some languages (like Japanese) is not inmediate. Compiling SGML sources to some formats require not just a proper toolchain but also proper configuration which the user might not have done (and cannot be automated) > Policy says to ship HTML, else I wouldn't. Policy is somewhat out of date with respect to documentation. There's actually a (draft) DDP policy which covers this already. I know, I've written it. > It would be great to have a new debhelper package that creates the previously > chosen documentation formats from the provided SGML file on installation. Debhelper? You are aware that debhelper is used on package *building* not on package installation, right? > This would save MUCH more in download size than any of the previously > discussed compression formats (may it be bzip2, 7zip or whatever). If you don't want a big package don't install it, go for the source. Actually, you can just locally compile the documentation packages if you don't want to download the -doc (binary) packages providing PDF, HTML or whatever other format. > And if the administrators choice is to not want any automatically created > formats, he may use a docbook program that displays it from the SGML or XML > source. Why not, such a tool may exist at one time or maybe does already. It does not exist, before going into a useless discussion, show me some code. Without a tool being available to do this all this is wishful thinking. The current best practice is to provide a grepable/searchable format (txt), an offline viewing format integrated with dwww (HTML) and a printable format (PS or PDF, at maintainer's discrection). As I said, if somebody doesn't like this, write something on the lines of your suggestions and show it here. I don't believe somebody is going to write because, you know, we've been doing it like this for *years* and nobody complained (at least not loud enough) about bulky documentation packages (and a few years back bandwidth was not as affordable). Regards Javier signature.asc Description: Digital signature
Re: documentation types
On Thu, Feb 16, 2006 at 11:03:37PM +0100, Gabor Gombas wrote: > On Thu, Feb 16, 2006 at 10:04:25AM +0100, Javier Fernández-Sanguino Pe?a > wrote: > > > Moreover, I know of *no* -doc packages that provide SGML format so there > > is not that much experience (or tools) on how to automatically do what > > others > > suggest (dwww integratin). > > IMHO SGML is losing ground in favor of XML. GNOME Help files are already > DocBook/XML (AFAIK KDE Help also). So there is definitely precedence, > and providing soma automatic, user-selectable DocBook/XML -> HTML > translation would have meaning for dwww integraton. The other option is > to say that GNOME/KDE can already display DocBook/XML without the HTML > conversion phase, so allow DocBook/XML as an alternative of HTML in the > policy. Maybe this is just wishful thinking. Docbook/XML or SGML conversion to HTML is easy. Proper PS / PDF generation is not that easy (depends on toolchain and local configuration) and that's what your average user typically asks for when handling large documents (manny prefer printing bulky documents than reading them offline or online). Regards Javier signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
"Marc 'HE' Brockschmidt" <[EMAIL PROTECTED]> writes: > actual topic of the discussion, just shut up. Oh get a life. It's perfectly relevant to talk about the qualities of the languages involved. Thanks! -miles -- = (^o^; (())) *This is the cute octopus virus, please copy it into your sig so it can spread. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
need help with minc
Hello, I made the mistake of adding "make check" to debian/rules. Now minc won't build on certain architectures. It builds on i386 (my architecture), ia64, s390, and powerpc. It fails on alpha, sparc, mips, hppa, arm, and mipsel. I poked around on a few of the debian machines (vore, paer, caballero) but none of them had the build-deps for minc. So I need help from a kind soul. The best would be if someone would install all the build dependencies for minc and then let me log in to poke around. Alternatively; someone could build minc, step through the failing script as follows, and send me the output of each command. 1 cd testdir 2 dd if=/dev/zero | ../rawtominc -vector 3 -byte -clobber _grid.mnc 8 8 8 3 ../mincinfo _grid.mnc 4 ./create_grid_xfm _grid.mnc _t1.xfm 5 cat _t1.xfm 6 ../mincinfo _t1_grid_0.mnc 7 ./create_grid_xfm _grid.mnc _t2.xfm 8 cat _t2.xfm 9 ../mincinfo _t2_grid_0.mnc 10 ../xfmconcat _t1.xfm _t2.xfm _t3.xfm 11 cat _t3.xfm 12 cmp _t1_grid_0.mnc _t3_grid_0.mnc 13 cmp _t2_grid_0.mnc _t3_grid_1.mnc Thanks, -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: documentation types
pe, 2006-02-17 kello 01:10 +0100, Javier Fernández-Sanguino Peña kirjoitti: > Docbook/XML or SGML conversion to HTML is easy. Proper PS / PDF generation is > not that easy (depends on toolchain and local configuration) and that's > what your average user typically asks for when handling large documents > (manny prefer printing bulky documents than reading them offline or online). As a hypothesis, I propose that many people prefer to print PS/PDF files rather than reading them from the screen because PS/PDF tend to be unpleasant to read from the screen. It doesn't, for example, reformat itself to the display/window/font size combination. HTML does that better. Anyway, I'm not opposed to providing a PDF version in a package, but I really, really hope we're not going to switch away from HTML as the primary format. -- Code is cheap to write. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: need help with minc
On Fri, Feb 17, 2006 at 12:10:09AM -0500, Steve M. Robbins wrote: > I made the mistake of adding "make check" to debian/rules. Now minc > won't build on certain architectures. It builds on i386 (my > architecture), ia64, s390, and powerpc. It fails on alpha, sparc, > mips, hppa, arm, and mipsel. > I poked around on a few of the debian machines (vore, paer, caballero) > but none of them had the build-deps for minc. So I need help from a > kind soul. Well, it really sounds like you need help from debian-admin, who can install the necessary build-deps for you on each of the project machines... :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
pe, 2006-02-17 kello 10:58 +0900, Miles Bader kirjoitti: > "Marc 'HE' Brockschmidt" <[EMAIL PROTECTED]> writes: > > actual topic of the discussion, just shut up. > > Oh get a life. It's perfectly relevant to talk about the qualities of > the languages involved. A comparative discussion about languages might be useful and productive. A discussion with arguments like "Efficient, perhaps, but _elegant_?!? HAhahahahah1hahah3$I17-e87"[1] is not such a discussion. The point of this thread has, at least in theory, been whether Python (in full or in part) should become an essential package so that various packaging scripts could be written in it. I suspect that all constructive arguments have been made already and that the consensus is "no, not now, maybe later when it's OK to make the set of essential packages bigger". In other words, status quo continues, the same one that Debian has had for a decade or so. Now can we please not perpetrate this thread anymore? [1] http://lists.debian.org/debian-devel/2006/02/msg00539.html -- Communication via acronyms is rfs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Work-needing packages report for Feb 17, 2006
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 219 (new: 27) Total number of packages offered up for adoption: 92 (new: 1) Total number of packages requested help for: 20 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: asciijump (#352436), orphaned 5 days ago Description: Small and funny ASCII-art game about ski jumping Installations reported by Popcon: 56 aspectj (#352521), orphaned 4 days ago Description: A seamless aspect-oriented extension for Java Installations reported by Popcon: 25 barrage (#352439), orphaned 5 days ago Description: Rather violent action game Installations reported by Popcon: 145 blackbook (#352437), orphaned 5 days ago Description: GTK+ Address Book Applet Installations reported by Popcon: 13 cpanel (#352557), orphaned 4 days ago Description: A configuration tool for Chinese desktop environment Installations reported by Popcon: 12 crank (#352532), orphaned 4 days ago Description: A classical CRypto ANalysis toolKit Installations reported by Popcon: 46 eclipse-nls-sdk (#352511), orphaned 4 days ago Description: localized message catalog for eclipse Installations reported by Popcon: 45 freqtweak (#352540), orphaned 4 days ago Description: Realtime audio frequency spectral manipulation Installations reported by Popcon: 32 ftplib (#353128), orphaned today Description: Library of callable ftp routines (development) Reverse Depends: vdr-plugin-weather vgrabbj ftplib-dev coriander Installations reported by Popcon: 302 icheck (#352431), orphaned 5 days ago Description: C interface ABI/API checker Installations reported by Popcon: 43 libbusiness-onlinepayment-tclink-perl (#352663), orphaned 3 days ago Description: TrustCommerce backend for Business::OnlinePayment Installations reported by Popcon: 5 libnet-tclink-perl (#352664), orphaned 3 days ago Description: Perl interface to the TrustCommerce payment gateway Reverse Depends: libbusiness-onlinepayment-tclink-perl Installations reported by Popcon: 10 mctools-lite (#352538), orphaned 4 days ago Description: A CD player and audio mixer for X Installations reported by Popcon: 163 mrtgutils (#352553), orphaned 4 days ago Description: Utilities to generate statistics for mrtg Installations reported by Popcon: 335 php4-tclink (#352661), orphaned 3 days ago Description: TrustCommerce TCLink module for php4 Installations reported by Popcon: 8 python-tclink (#352665), orphaned 3 days ago Description: TrustCommerce credit card processing for Python 2.3.x Reverse Depends: python-tclink Installations reported by Popcon: 10 rosegarden (#352543), orphaned 4 days ago Description: An integrated MIDI sequencer and musical notation editor Installations reported by Popcon: 144 rosegarden2 (#352537), orphaned 4 days ago Description: An integrated MIDI sequencer and musical notation editor Reverse Depends: rosegarden Installations reported by Popcon: 170 sfront (#352542), orphaned 4 days ago Description: MPEG 4 Structured Audio decoder Installations reported by Popcon: 59 ssystem (#352709), orphaned 3 days ago Description: 3D solar system simulator Installations reported by Popcon: 143 tapiir (#352539), orphaned 4 days ago Description: A tool for real time audio delay and feedback effects Installations reported by Popcon: 29 tclxml (#352330), orphaned 5 days ago Description: Tcl library for XML parsing Installations reported by Popcon: 10 tdfsb (#352441), orphaned 5 days ago Description: A 3D filesystem browser Installations reported by Popcon: 70 wmget (#352435), orphaned 5 days ago Description: Background download manager in a Window Maker dock app Installations reported by Popcon: 76 xenophilia (#352593), orphaned 4 days ago Description: Customisable GTK+ engine with a plain look Installations reported by Popcon: 360 xexec (#352708), orphaned 3 days ago Description: Run a simple arbitrary command from X Installations reported by Popcon: 26 xgdipc (#352550), orphaned 4 days ago Description: GnuDIP GTK client Installations reported by Popcon: 5 192 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: cppopt (#352710), offered 3 days ago Reverse Depends: libcppop
Draft DDP policy (was: documentation types)
Javier Fernández-Sanguino Peña <[EMAIL PROTECTED]> wrote: >> Policy says to ship HTML, else I wouldn't. > > Policy is somewhat out of date with respect to documentation. There's > actually a (draft) DDP policy which covers this already. I know, I've written > it. Where can we look at the draft? TIA, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
