RFS: docbook-defguide -- DocBook: The Definitive Guide - HTML version
Hello all, I would like to ask for a sponsor for my docbook-defguide package. The reason why I ask on this list: I need a sponsor with a big box - fast enough and with at least 1GB RAM (more is better). On my system the package needs 16 hours to build and the maximum heap size for Java is set to 1GB (otherwise GIJ fails with OutofMemory). You can read more about it at [1]. So my sponsor and me would like to ask, if someone else could sponsor this (lintian-clean) package. NOTE: The .orig.tar.gz is prepared via the get-orig-source target in debian/rules. Don't hesitate to ask, if you have questions. x-posted to related lists Regards, Daniel [1] http://www.wgdd.de/?p=31 Here an RFS-template like package description: - * Package name: docbook-defguide Version : 2.0.17+svn7549-1 Upstream Author : Norman Walsh and others * URL : http://docbook.org/tdg/ * License : GFDL 1.1 (no invariant sections, ...) Description : DocBook: The Definitive Guide - HTML version * Bugs closed : 135296 173710 208031 248364 257715 280485 280740 295579 The official reference manual for the DocBook 4.x SGML and XML DTD, by Norman Walsh, Leonard Muellner, and Bob Stayton. This version is an evolution of the book of the same name published by O'Reilly (which documented DocBook 3.1). . This is a work in progress, which attempts to fully document DocBook 4.5, but may be inconsistent in some places. - Get the source via dget: http://debian.wgdd.de/debian/incoming/packages/docbook-defguide_2.0.17+svn7549-1.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MIME support in Debian.
Am Samstag, den 22.12.2007, 23:34 +0900 schrieb Charles Plessy: > The Debian mime policy requires packages register through update-mime, > which according to its manpage uses /etc/mailcap and > /usr/lib/mime/packages. However, I noticed the /usr/share/mime and > /usr/share/mime-info directories that also seem to contain relevant > informations. You missed /usr/share/mimelnk :) /usr/share/mime : freedesktop.org shared MIME info database /usr/share/mime-info : GNOME MIME data (IMHO mostly obsolete) /usr/share/mimelnk : KDE 3 Current GNOME and the upcoming KDE 4 both uses the shared-mime-info database in /usr/share/mime. Old KDE3 and GNOME systems are not well described, but the link collection in my next paragraph contains a few information links for these systems too. > Is there a documentation somewhere that explains what is necesary and > sufficient to be done so that a Debian package provides MIME support > that "just works" ? Hm, I'm not aware of some Debian specific documentation. However, I collect such information for a project. Look at http://sourceforge.net/docman/?group_id=159685 > Basically the goal is that the relevant program will > be used by mail readers and web browsers. IMHO you should only try to support the mailcap/metamail and the fd.o shared-mime-info systems. > Also, if there are two such > programs installed, is there something that can be done through MIME so > that the user has a chance to chose the program ? Not directly through MIME (the MIME RFCs just describe the so called Internet Content type, e.g. "text/plain" - association with programs is AFAIK not part of the MIME standard). This has been described in the fd.o standard: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s07.html > Or will it be a "last > installed is the default" situation, like with the alternative system ? You could check yourself: Take a ook at /usr/share/applications/mimeinfo.cache and check, if maybe the first mentioned application for a MIME type s used. I'm not sure. The old GNOME system IIRC had some special way (special keys) to handle this via .keys files. But the docs are not verbose about this. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MIME support in Debian.
Am Montag, den 24.12.2007, 01:39 +0900 schrieb Charles Plessy: > Le Sat, Dec 22, 2007 at 11:01:21PM +0100, Daniel Leidert a écrit : > > > > Current GNOME and the upcoming KDE 4 both uses the shared-mime-info > > database in /usr/share/mime. > > > > IMHO you should only try to support the mailcap/metamail and the fd.o > > shared-mime-info systems. > > many thanks for your answer, I will do what you suggest : > mailcap/metamail and fd.o support. If I understood correctly, to do so, > I need to: > > - Have a MimeType entry in the .desktop file. - Add MIME tyopes to the shared-mime-info database if necessary via dh_installmime and a .sharedmimeinfo file (or similar). These two things belong to the fd.o system. > - Have a debian/packagename.mime file in the source package and call >dh_installmime. This is metamail/mailcap. > I did not find the way to associate a file suffix to the program. This is done via the MimeType entry in .desktop files. Check out /usr/share/applications. This file contains the information, which file/MIME types can be opened/processed by an application. > Is MIME the way to go ? MIME just gives you a way to classify content via the Internet Content Type aka MIME type. So tell the system, that the suffix belongs to a MIME type (several systems: libmagic, /usr/share/mime, /usr/share/mime-info/*.mime + /etc/gnome-vfs-mime-magic, /usr/share/mimelnk + /etc/kde3/magic/*.magic) and associate your program with this MIME type (also several systems: /usr/share/applications, /usr/share/applnk (obsolete), /usr/share/mimelnk/*.keys (obsolete), /etc/mailcap). > The goal would be that mail user agents and MUAs like evolution use the shared-mime-info database to determine the MIME type of an attachment. I guess that Kmail uses the KDE3-database of MIME types (a mixture of .desktop files in /usr/share/mimelnk and an old version of libmagic, that may be used to determine content pattern for file types). I don't know, what Mutt uses. AFAIK it does not use libmagic. But I may be wrong. > webservers This is a question of configuring the web-server. You can use the mime-support (/etc/mime.types) and/or libmagic (man 5 magic) system for .g. the apache web server. Both cannot be extended easily during a package installation. So it's more or less the system administrators job. > would use the right mime type with attached/downloaded files, > and that doubleclicking on local files would make them opened by a > relevant program. The MIME type (often used to represent the file type) of local files is determined depending on the desktop used. KDE 3 has its own system. XFCE4 and current GNOME AFAIK both use the shared-mime-info database (KDE 4 will use it too and drop its own solution). > I have another question: can subcategories starting by x- created > freely? The `x-' in e.g. $primary_type/x-foo means, that this is not an official/registered MIME type. See RFC 2045 and 2048. > The program I am working on is Treeview X, a phylogenetic tree > viewer that can read Clustal W format. It is text based, so David > Paleino, our collaborator from the Debian-Med packaging team, suggested > text/clustalw-tree. If it is unofficial use text/x-clustalw-tree or application/x-clustalw-tree (depends). To define this MIME type, add an entry to the shared-mime-info database by writing a file similar to those found in /usr/share/mime/packages (dh_installmime/.sharedmimeinfo). The syntax is described in the related fd.o specification, also shipped with the shared-mime-info packages. Then associate your program via a .desktop file in /usr/share/applications. Put the created MIME type in the MimeType filed in the .desktop file and call dh_desktop in your debian/rules. The MIME type detection should now work on current GNOME and XFCE desktops. The program<->MIME type association should work on GNOME, XFCE and KDE. However, KDE 3 uses its own way to add MIME type definitions to the system. Say you called your MIME type application/x-clustalw-tree, then install a file x-clustalw-tree.desktop into /usr/share/mimelnk/applications (the directories under /usr/share/mimelnk follow the syntax of MIME types). To support this MIME type via libmagic, add your entries to /etc/magic(.mime). To associate your program via /etc/mailcap, use dh_installmime/.mime. > But maybe I can submit a wishlist bug on > chemical-mime-data to have chemical/clustalw-tree from your namespace ? Well, chemical is not a registered primary type. It just spread all over the world after it had been suggested in 1995. However, it has never been registered and we had some discussions about the future of chemical/* in the past. It would be better to use one of the official primary types like text/ or application/ if possible. But I don't know the content of this file type, so I cannot suggest an
Re: MIME support in Debian.
CC to Charles, because his mails are e week old. Am Montag, den 24.12.2007, 22:18 +0900 schrieb Charles Plessy: > To summarise our discussion, I have created the following wiki page: > > http://wiki.debian.org/MimeTypesSupport Ok, I will take a look at it. [snip] > There are still two things I am wondering: > > - Do the packages need to depend on mime-support and shared-mime-info ? No. For shared-mime-info, packages can put their stuff into /usr/share/mime/packages even if shared-mime-info is not installed. When it gets installed, everything in the mentioned directory is processed. It is some nice-to-have for many/most? users, but nothing that must be installed. You could discuss, if the package should be part of every desktop-task (dselect and similar), if it is not yet. > - If two programs can open files with a given suffix, they have to ship the > same .sharedmimeinfo file. You mean the following case: A MIME type is not defined in the shared-mime-info database (/usr/share/mime/packages/freedesktop.org.xml) but two programs can process it. These two programs can be installed independent from each other und you want both programs to install the file to define/detect the MIME type, right? The solution to this problem is, to request an addition of this MIME type to the shared-mime-info package. The other working solution is to use a diversion and move the file from the already installed package out of /usr/share/mime/packages. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DocBook documentation format
Gilles Filippini wrote: > My upstream has just included localized documentation in DocBook format. > I'm not sure how I should deal with this doc. > > According to [1], documentation should be in HTML and the XML DocBook > format should stay in the source package. > > But looking for similar documentation, I've stumbled across some KDE > packages - such as showimg - which provide only the DocBook file and no > HTML. Yes, but this solution requires some tools, that parse the XML files and create e.g. HTML (by applying a XSLT stylesheet to the XML files). AFAIK both KDE and GNOME ship such tools, but require to put the docs into special directories and also sometimes require some registration of the XML files. > Which is the best option? If you just want to provide documentation, then neither of these: > a) provide only the DocBook files just like showimg does > b) provide the DocBook files plus the generated HTML files is a good choice. But this one is: > c) provide only the generated HTML files and leave the DocBook files in > the source package. Build depend on - xmlto (currently broken for PDF/PS/DVI output, but this will be fixed soon) or alternatively (depending on the features the source needs): - xsltproc, docbook-xsl - java (gij), libsaxon-java(-gcj), docbook-xsl, docbook-xsl-saxon(-gcj) (enables the usage of some extensions, like line-numbering ... the docbook-xsl-saxon package ships a sample file that makes use of these extensions) If you need some advice, please don't hesitate to ask. There is also some related list: debian-sgml. Regards, Daniel -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian: outdated-autotools-helper-file
Am Sonntag, den 10.02.2008, 17:30 -0200 schrieb Henrique de Moraes Holschuh: > On Sun, 10 Feb 2008, David Paleino wrote: > > I'm packaging gnome-translate (ITP #292909), and everything builds fine. A > > lintian check on the .changes file throws: > > > > E: gnome-translate source: outdated-autotools-helper-file config.guess > > 2003-07-02 [..] > Read autotools-dev's README file, it has recipes for what you want (that > won't even increase diff size). I wrote a report against lintian to add a reference to the README in the long description. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian: outdated-autotools-helper-file
Am Montag, den 11.02.2008, 14:17 +0100 schrieb Daniel Leidert: > Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino: > > Il giorno Mon, 11 Feb 2008 10:53:48 +0100 > > Bas Wijnen <[EMAIL PROTECTED]> ha scritto: > > > > > I suggest to mandate "remove all generated files in the clean target" > > > (formulated in a way which includes "generated by upstream", not only > > > "generated by the build target), which implies "rebuild everything in > > > the build target". > > > > I fully agree with you here: the build target should also build Makefile.in > > from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the > > clean > > target. > > The files you mention belong to the maintainer-clean target. To remove > them in the debian/rules clean target you would often have to repackage > the source tarball, which often includes patching, because many > autotools-based build environments do not fully implement > maintainer-clean. Otherwise you would need to duplicate maintainer-clean > in the debian/rules clean target (good luck with large source archives, > maybe including even sub-projects!). You further need to build depend on > the whole autotools chain + additional tools like gnome-doc-utils or > intltool or I even forgot some point: The scripts (often: autogen.sh) to (re-)create the build environment are normally only part of the upstream VCS but are not shipped with the source tarball. So even if the project fully implemented maintainer-clean, you would need to copy this file from the upstream VCS or write it yourself to recreate the build environment. But these scripts are sometimes more complicated than a simple call to autoheader, aclocal, autoconf and automake. I think the idea to use the pure VCS source without any autotools-generated file creates much more issues than it maybe solves. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFC: Exclude config.sub and config.guess from
Am Montag, den 11.02.2008, 14:45 +0100 schrieb David Paleino:
> Il giorno Mon, 11 Feb 2008 14:17:54 +0100
> Daniel Leidert <[EMAIL PROTECTED]> ha scritto:
>
> > We simply copy config.sub and config.guess into the build directory for
> > some years now and I never observed any problem with this.
> >
> > I'm really wondering why you want to make the situation complicated?
>
> And if the config.{sub,guess} copied are different from those provided
> upstream, isn't this difference going to pollute the .diff.gz? I'd like to
> take
> the .diff.gz the most clean possible; i.e. only keep debian/ in it.
I fully agree. But you already have a possibility to achieve this:
Copy the config.* scripts after the clean target has been called (e.g.
in the config.status target) then they are simply not part of the
diff.gz. Of course they would be after a second build run. If you care
and if you want to avoid this: preserve the original config.* scripts
and put them back in the clean-target. This increases the whole
debian/rules file for around 4 lines.
This *is* much more easier than any other suggestion I read in this
thread.
A possible alternative could be to exclude config.sub and config.guess
creating the .diff(.gz). But this can lead to problems, if you patched
one of these files. IIRC I saw this during the introduction of
kfreebsd-i386, but I'm not sure.
Regards, Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian: outdated-autotools-helper-file
Am Montag, den 11.02.2008, 10:54 +0100 schrieb David Paleino: > Il giorno Mon, 11 Feb 2008 10:53:48 +0100 > Bas Wijnen <[EMAIL PROTECTED]> ha scritto: > > > I suggest to mandate "remove all generated files in the clean target" > > (formulated in a way which includes "generated by upstream", not only > > "generated by the build target), which implies "rebuild everything in > > the build target". > > I fully agree with you here: the build target should also build Makefile.in > from Makefile.am, for example. Thus we clean *.in, *.sub, *.guess, in the > clean > target. The files you mention belong to the maintainer-clean target. To remove them in the debian/rules clean target you would often have to repackage the source tarball, which often includes patching, because many autotools-based build environments do not fully implement maintainer-clean. Otherwise you would need to duplicate maintainer-clean in the debian/rules clean target (good luck with large source archives, maybe including even sub-projects!). You further need to build depend on the whole autotools chain + additional tools like gnome-doc-utils or intltool or We simply copy config.sub and config.guess into the build directory for some years now and I never observed any problem with this. I'm really wondering why you want to make the situation complicated? > And, as a sidenote, I've just faced this. I patched a Makefile.am, and wasn't > seeing any result. This project very probably used the AM_MAINTAINER_MODE macro. Enable the maintainer-mode with --enable-maintainer-mode. > I also had to patch Makefile.in. That's non-sense to me. Why do you patch Makefile.am? It just makes sense, when you manipulate or change macros (e.g. make libraries convenience libraries). If you just change a path or if you want to remove a binary from installation ... then simply patch Makefile.in directly. There is often no reason to patch Makefile.am. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Howto exclude config.sub and config.guess updates from .diff.gz
Sorry, I broke the subject with my last post. I wanted to adjust it, but forgot finish the subject line. Really sorry. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help with watch file -- pre-release upstream versions
Am Montag, den 11.02.2008, 02:23 +0100 schrieb Székelyi Szabolcs: > What's the usual way of handling "preX" upstream version numbers in > watch files? I'm having trouble because uscan considers 1.0pre3 newer > than 1.0. IMO you have two options: 1) Ignore the pre-versions by a rule like http://domain.tld/foobar-([\d.]+)\.tar\.gz if you are not going to package pre-releases. This will exclude all versions including a "pre" term after the version number. 2) Use a uversionsmnagle: opts=uversinmangle=s/pre/~pre/ \ http://domain.tld/foobar-(.+)\.tar\.gz Regards, Daniel
Re: RFC: Howto exclude config.sub and config.guess updates from .diff.gz
Am Montag, den 11.02.2008, 19:48 +0100 schrieb Bernhard R. Link: > * Daniel Leidert <[EMAIL PROTECTED]> [080211 15:21]: > > If you care > > and if you want to avoid this: preserve the original config.* scripts > > and put them back in the clean-target. This increases the whole > > debian/rules file for around 4 lines. > > much easier: just delete in the clean target and put there at the > beginning of the configuring target. This had been suggested earlier in this thread: http://lists.debian.org/debian-mentors/2008/02/msg00220.html http://lists.debian.org/debian-mentors/2008/02/msg00225.html Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: docbook2X (0.8.8-6), docbook-defguide (2.0.17+svn7549-2), xmlto (0.0.20-1)
Hi, Unfortunately my usual sponsor is busy atm and I have some packages waiting to be uploaded. So I'm looking for one-time sponsor(s) for the following packages: http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/docbook-defguide_2.0.17+svn7549-2.dsc http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/docbook-defguide_2.0.17+svn7549-2_i386.changes Closes: http://bugs.debian.org/459043 debdiff attached http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/docbook2x_0.8.8-6.dsc http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/docbook2x_0.8.8-6_i386.changes Closes: http://bugs.debian.org/439214 debdiff attached http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/xmlto_0.0.20-1.dsc http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/xmlto_0.0.20-1_i386.changes Closes: http://bugs.debian.org/263243 http://bugs.debian.org/270433 http://bugs.debian.org/293453 http://bugs.debian.org/299461 http://bugs.debian.org/311354 http://bugs.debian.org/327551 http://bugs.debian.org/353829 http://bugs.debian.org/366707 http://bugs.debian.org/413632 http://bugs.debian.org/415353 no debdiff attached (major update), but 0.0.20 is a release, where many of our patches have been merged upstream, so the patch-set decreased a lot - just take a look if you want NOTE: xmlto needs a -v0.0.18-5.1 for the .changes creation. See also http://debian.wgdd.de/debian/incoming/packages/. All 3 package are of course lintian clean (to my knowledge ). I'm in the DM keyring and all 3 packages set DM-Upload-Allowed. If you have questions, don't hesitate to ask. CCed the debian-xml-sgml group and the debian-sgml mailing list Regards, Daniel diff -u docbook2x-0.8.8/debian/patches/00list docbook2x-0.8.8/debian/patches/00list --- docbook2x-0.8.8/debian/patches/00list +++ docbook2x-0.8.8/debian/patches/00list @@ -4,0 +5 @@ +05_fix_439214_error_on_missing_refentry diff -u docbook2x-0.8.8/debian/changelog docbook2x-0.8.8/debian/changelog --- docbook2x-0.8.8/debian/changelog +++ docbook2x-0.8.8/debian/changelog @@ -1,3 +1,19 @@ +docbook2x (0.8.8-6) unstable; urgency=low + + * debian/compat: Raised to v5. + * debian/control: Added DM-Upload-Allowed for DM status. +(Build-Depends): Raised debhelper to v5. +(Standards-Version): Raised to 3.7.3. + * debian/copyright: Fixed typo. Thanks to lintian. + * debian/docbook2x.doc-base (Document): Fixed uppercase letter. Thanks to +lintian. + * debian/patches/05_fix_439214_error_on_missing_refentry.dpatch: Added. +- xslt/man/docbook.xsl: Print a warning if no refentry element can be + found (closes: #439214). + * debian/patches/00list: Adjusted. + + -- Daniel Leidert (dale) <[EMAIL PROTECTED]> Wed, 13 Feb 2008 18:08:08 +0100 + docbook2x (0.8.8-5) unstable; urgency=low * debian/control: Homepage field transition. diff -u docbook2x-0.8.8/debian/control docbook2x-0.8.8/debian/control --- docbook2x-0.8.8/debian/control +++ docbook2x-0.8.8/debian/control @@ -3,12 +3,13 @@ Priority: optional Maintainer: Debian XML/SGML Group <[EMAIL PROTECTED]> Uploaders: Ardo van Rangelrooij <[EMAIL PROTECTED]>, W. Borgert <[EMAIL PROTECTED]>, Rafael Laboissiere <[EMAIL PROTECTED]>, Daniel Leidert (dale) <[EMAIL PROTECTED]> -Build-Depends: debhelper (>= 4.2), cdbs (>= 0.4.21), dpatch, libxml-sax-perl, opensp, sp, texinfo, xml-core, xsltproc +Build-Depends: debhelper (>= 5), cdbs (>= 0.4.21), dpatch, libxml-sax-perl, opensp, sp, texinfo, xml-core, xsltproc Build-Conflicts: libxml2-utils, tidy -Standards-Version: 3.7.2 +Standards-Version: 3.7.3 Homepage: http://docbook2x.sourceforge.net -XS-Vcs-Browser: http://svn.debian.org/wsvn/debian-xml-sgml/packages/docbook2x/trunk/ -XS-Vcs-Svn: svn://svn.debian.org/svn/debian-xml-sgml/packages/docbook2x/ +Vcs-Browser: http://svn.debian.org/wsvn/debian-xml-sgml/packages/docbook2x/trunk/ +Vcs-Svn: svn://svn.debian.org/svn/debian-xml-sgml/packages/docbook2x/ +DM-Upload-Allowed: yes Package: docbook2x Architecture: any diff -u docbook2x-0.8.8/debian/compat docbook2x-0.8.8/debian/compat --- docbook2x-0.8.8/debian/compat +++ docbook2x-0.8.8/debian/compat @@ -1 +1 @@ -4 +5 diff -u docbook2x-0.8.8/debian/docbook2x.doc-base docbook2x-0.8.8/debian/docbook2x.doc-base --- docbook2x-0.8.8/debian/docbook2x.doc-base +++ docbook2x-0.8.8/debian/docbook2x.doc-base @@ -1,4 +1,4 @@ -Document: docbook2X +Document: docbook2x Title: docbook2X user documentation Author: Steve Cheng <[EMAIL PROTECTED]> Abstract: docbook2X converts DocBook documents into man pages and diff -u docbook2x-0.8.8/debian/copyright docbook2x-0.8.8/debian/copyright --- docbook2x-0.8.8/debian/copyright +++ docbook2x-0.8.8/debian/copyright @@ -59,7 +59,7 @@ dealings in this Software without prior written authorization from the individuals in question. - Any stylesheet derived from
[DONE] RFS: docbook-defguide (2.0.17+svn7549-2)
Am Mittwoch, den 13.02.2008, 18:27 +0100 schrieb Daniel Leidert: > http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/docbook-defguide_2.0.17+svn7549-2.dsc > http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/docbook-defguide_2.0.17+svn7549-2_i386.changes > Closes: http://bugs.debian.org/459043 > debdiff attached Done. Thanks to Lucas for the upload. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: docbook-xsl (1.73.2.dfsg.1-3)
Hi, Because my usual sponsor is still busy, I would like to request a one-time sponsorship for my docbook-xsl package. The version 1.73.2.dfsg.1-3 closes: http://bugs.debian.org/445901 http://bugs.debian.org/447958 http://bugs.debian.org/449582 http://bugs.debian.org/464708 http://bugs.debian.org/465820 and is lintian clean. Get the source via dget from http://debian.wgdd.de/debian/incoming/packages/debian-xml-sgml/docbook-xsl_1.73.2.dfsg.1-3.dsc For questions, just ask. CCing the Debian XML/SGML groups list and debian-sgml. PS: It would be nice if this person could also sponsor the xmlto and docbook2x updates. See http://lists.debian.org/debian-mentors/2008/02/msg00329.html Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Writing get-orig-source targets to conform with policy
Am Samstag, den 16.02.2008, 23:10 -0500 schrieb Andres Mejia: > I have two questions. First question is; > > Is it at all possible to write a get-orig-source target that calls an > external > script to handle generating the orig tarball? Of course. > The problem I'm facing is when the get-orig-source target is written like: >get-orig-source: > debian/external-script > > It works fine under the package's top directory, but fails under any other > directory, for instance, /tmp. I've looked over the GNU make documentation > hoping to find a special parameter for finding the name of the make script > ran, just how a shell script has "$0", but I've been unable to find one. Work in the current directory or in /tmp using mktemp. I have written get-orig-source targets for almost all docbook* packages [1] I maintain (where uscan isn't enough). Maybe they are useful examples. > Second question is regarding a get-orig-source target I have for the package > mediatomb. It goes like: > > # Common variables used to ease maintenance of the get-orig-source target. > MEDIATOMB_TARBALL = mediatomb-0.10.0.tar.gz > MEDIATOMB_VERSION = 0.10.0 > CORRECT_CHECKSUM = 2436c73de4ac5f3ba1575f7ee93a0430 > # Haven't found a way to use this without running it twice > COMPUTED_CHECKSUM = $(shell md5sum $(MEDIATOMB_TARBALL) | cut -d ' ' -f 1) > get-orig-source: > [ -e $(MEDIATOMB_TARBALL) ] || \ > wget > http://downloads.sourceforge.net/mediatomb/$(MEDIATOMB_TARBALL) The checksum is computed before you download the tarball. Compute it after this step. [1] http://svn.debian.org/wsvn/debian-xml-sgml/packages/?rev=0&sc=0 (docbook, d-xml, d-xsl, d-xsl-saxon, d-simple, d-ebnf, d-defguide) Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Writing get-orig-source targets to conform with policy
Am Sonntag, den 17.02.2008, 23:58 +0100 schrieb Bas Wijnen: [..] > The get-orig-source target specifies that it must work from anywhere. Where do you read this? The policy says, that it "[..] may be invoked in any directory [..]". To my understanding, this is not a "must work from anywhere". I agree, that script-calls should work from any directory. But I expect the user to run the target at a place, where the user has write permissions. I don't want to add tests and checks for this. But this would be necessary to fulfill the requirement you state. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The get-orig-source target as stated in Policy 4.9
Am Montag, den 18.02.2008, 11:54 -0500 schrieb Andres Mejia: > I've been told that the policy for the get-orig-source target states that > it "...fetches the most recent version of the original source package...". > However, I've seen others using the get-orig-source target to regenerate the > orig tarball for their packages at a particular version. I've been doing this > as well. Some packages doing this are warsow, ogre, fretsonfire, bulletml, > and warzone2100. > > So my question is, when Policy states "the most recent version", is it "the > most recent version _in Debian_" or "the most recent version _upstream_"? > > Even if it doesn't mean "the most recent version _in Debian_", I think it's > important to supply a target or some other implementation to generate an orig > tarball for packages at a particular version where upstream doesn't supply a > clear upstream source package. Packages in experimental and packages whose > source comes from svn, git, etc. are examples of when some implementation > should be supplied. Look at warzone2100 for an example. Well, overwrite the related variables in debian/rules via command line: debian/rules get-orig-source VERSION=x.y SVNVER= to get a source package for a given point. And determine these variables for the current version in Debian e.g. via hardcoding the variables in debian/rules or (IMO much better) by parsing debian/changelog (dpkg-parsechangelog). So you can get an older version, the one in Debian or even the "most recent". Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#466550: Please clarify the get-orig-source target stated in Policy 4.9
Am Dienstag, den 19.02.2008, 15:16 +0100 schrieb Alexander Schmehl: > Package: debian-policy > Version: 3.7.3.0 > Severity: wishlist > X-Debbugs-CC: debian-mentors@lists.debian.org, [EMAIL PROTECTED] > > Dear policy team, > > recently the get-orig-source target of debian/rules has been discussed > on the debian-mentors list (see the threads starting with [1] and [2]). > > It seems the get-orig-source specific paragraph of section 4.9 should be > improved to a bit more clearly and answer some open questions, too. > > Basically it boils down to two or three open questions: > > The first one being, if get-orig-source is intendedn to fetches the most > recent version of the original source upstream wise or if it should > fetch the most recent version debian wise. That should be done by uscan invoking "debian/rules get-orig-source" as suggested several times. This won't make the situation more complicated. It just requires that any variables necessary to create the tarball (e.g. upstream version, svn version number, ...) can be overwritten by uscan (already explained it in this thread) > If the later is the case and of a package has a version in > experimentatl, should get-orig-source fetch the version of experimental > or from unstable? It should IMO fetch the version by parsing debian/changelog. That's simple and logical. uscan can overwrite these variables. > And last questions: Where should tools used in get-orig-source (e.g. > bzip2 or unzip to repacke a tarball) be declared? As Build-Dependency? > Anywhere else? I don't think, they should be declared in Build-Depends, because they are simply not necessary to build the package. No target in debian/rules invokes get-orig-source during a build and people invoking this target should be able to check debian/rules, if something goes wrong. But to be honest: This target normally requires only bzip2/gzip/tar, wget (maybe we can drop this, if uscan invokes get-orig-source) and rm + sometimes $VCS-command. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help needed for packaging a library
Am Freitag, den 28.03.2008, 00:41 +0100 schrieb Georgi Chulkov: > I'm trying to package a very simple hello world library, before I move to > more > complex things. The problem is that dpkg will not include the most important > files in the finished package. Here's what I did, step by step (on a Kubuntu > 7.10 system): [snip] > libnonsense1.install > - > usr/lib/lib*.so.* > - [snip] > libnonsense-dev.install > --- > usr/include/* > usr/lib/lib*.a > usr/lib/lib*.so > usr/lib/pkgconfig/* > usr/lib/*.la It is IMHO a better idea to drop the libtool .la files. > usr/share/pkgconfig/* /usr/share/pkgconfig contains .pc (pkg-config) files for architecture independent packages. Your library is architecture-dependent (and you list /usr/lib/pkgconfig/), so you can drop this here. > --- > > 6. I run dpkg-buildpackage -rfakeroot > > The result is two deb files, among other things. The problem is that they do > not contain the library! Read the manpage for dh_install and consider to use the --sourcedir=debian/tmp switch (for multi-binary packages, files are normally installed to debian/tmp/ and then copied or moved into the packaging directories debian/$(binary_PACKAGE)/ - only the content of the latter is put into the resulting binary packages (except you request a different behaviour). Otherwise you would need to list source *and* destination in the .install file. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing .pl extension in files from a package using debhelper and CDBS.
Am Dienstag, den 15.04.2008, 15:30 +0900 schrieb Charles Plessy: > I am preparing a very simple pacakge (mage2tab) that uses CDBS and > debhelper: > > anx159《mage2tab》$ cat trunk/debian/rules > #!/usr/bin/make -f > include /usr/share/cdbs/1/rules/debhelper.mk > > I would like to keep this file as simple as possible, but the programs > in the pacakge are perl scripts whose name finishe in .pl, so I have to > rename them at some point. My problem is that apparently, > configure/mage2tab:: or install/mage2tab:: are too early rules if I want > to rename after using dh_install: they are not in > $(CURDIR)/debian/mage2tab/usr/bin yet. > > Is there a simple and elegant way to do file renaming with CDBS ? Use dh_install to install the .pl file and then: binary-fixup/mage2tab:: mv $(CURDIR)/debian/$(PACKAGE)/... ... Regards, Daniel
Re: Examples
Am Montag, den 05.05.2008, 14:50 +0200 schrieb Sveinung Kvilhaugsvik: > When there are two packages, packagename (that contains a library) and > packagename-doc (that contains documentation and examples), do the > documentation and examples go in /usr/share/doc/package or > /usr/share/doc/packagename-doc? If it goes in /usr/share/doc/package, > are there a way to make dh_installexamples use /usr/share/doc/package > even if the files go in packagename-doc? You could install the documentation into /usr/share/doc/package/html and ship it with the packagename-doc package. Further ship a symlink /usr/share/doc/packagename-doc/html to /usr/share/doc/package/html with the same package. So you avoid a dangling symlink, if you don't want to add a strong dependency on package for packagename-doc. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
Am Donnerstag, den 26.06.2008, 09:18 +1000 schrieb Trent W. Buck: > Charles Plessy <[EMAIL PROTECTED]> writes: > > > while working on an update to the `proda' package, I realised that a > > compilation option, DVERSION="\"1.00\"", was discarded during the build > > of the Debian binary package. The reason is very simple: > > > > OTHERFLAGS = -DVERSION="\"1.00\"" > > CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS) > > Why can't you simply change = to +=, thereby appending these flags to > whatever is supplied by the user? Overriding CXXFLAGS makes all '=', '+=' etc. useless. You will need the `override' directive! override CXXFLAGS += $(OTHERFLAGS) However, there are better (and non-GNU-make specific) solutions: DEFS, CPPFLAGS, _CPPFLAGS, ... Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
Sorry for the CC. I was away and missed the discussion :) Am Mittwoch, den 25.06.2008, 13:24 +0900 schrieb Charles Plessy: > while working on an update to the `proda' package, I realised that a > compilation option, DVERSION="\"1.00\"", was discarded during the build > of the Debian binary package. The reason is very simple: > > OTHERFLAGS = -DVERSION="\"1.00\"" > CXXFLAGS = -g -W -Wall -pedantic $(OTHERFLAGS) Talk to the upstream author to use e.g. (GNU make specific): override CXXFLAGS += $(OTHERFLAGS) or tell him to better use one of the following: DEFS += -DVERSION="\"1.00\"" AM_CPPFLAGS += -DVERSION="\"1.00\"" foo_CPPFLAGS += -DVERSION="\"1.00\"" ... These are normnally not overwritten by the user and the correct place to leave a -D switch. There is enough documentation out there to find the correct solution. [..] > My problem is that I do not know the contents of the implicit rule > building the .o files from the .h files, nor how I can tell to make to > add $(OTHERFLAGS) to this implicite rule. [..] > Any idea ? Read /usr/share/doc/make-doc/. There you find all built-in rules. (Sorry, if you already got this information - I'm still receiving/processing mails). Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
Am Freitag, den 27.06.2008, 10:16 + schrieb Yavor Doganov: > В Thu, 26 Jun 2008 23:14:55 +0200, Daniel Leidert написа: > > > or tell him to better use one of the following: > > > > DEFS += -DVERSION="\"1.00\"" > > This won't work. The objects are built by make's built-in implicit > rules, and this variable is not used there: Ok. I didn't recognize, that it doesn't use autotools. > COMPILE.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c > > Maybe it is OK for other make implementations automake uses it. I think, then the override directive is the only choice left from my suggestions. Unfortunately, freebsd-make will probably not recognize it. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binary-without-manpage
Jeffrey Ratcliffe wrote: > It is probably because I'm trying to hack past midnight, but I can't > get dh_installman to install my manpage properly, meaning that lintian > report binary-without-manpage. > > If someone could tell me what I am doing wrong, I'd be grateful. You simply don't install debian/ocroscript.1. Read dh_installman(1) and install it by a ocropus.manpages debhelper file or by adding it to the dh_installman call in debian/rules. > The respective dsc file can be found at: > http://mentors.debian.net/debian/pool/main/o/ocropus/ocropus_0.2-1.dsc > > Additionally, I also get: > > dpkg-shlibdeps: warning: debian/ocropus/usr/bin/ocroscript shouldn't > be linked with libSDL-1.2.so.0 (it uses none of its symbols). > dpkg-shlibdeps: warning: debian/ocropus/usr/bin/ocroscript shouldn't > be linked with libz.so.1 (it uses none of its symbols). Nothing serious. > I've tried using --as-needed, but ocropus then FTBFS. Can you at least quote, with which error it fails (e.g. to [1])? [1] http://paste.debian.net/ Regards, Daniel -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Need help writing watch file for unusual, troublesome case.
Am Dienstag, den 02.09.2008, 16:31 -0700 schrieb Brandon: > Creating a separate script wouldn't really make much sense in my case. > I was only fixing the watch file as a formality. Upstream is dead, so I > wouldn't be using it, but it would satisfy projects like dehs, and my > QA page warns me about my broken watch file. > > I think I will just use the watch file that I mentioned in my original > post. This one: > version=3 > http://www.xevil.com/xevil/dev/download.html (.*)/download_stable.shtml This is a good starting point. Using filenamemangle and downloadurlmangle you can use the above for a working watch file. I attached it. As long as upstreams stays with this scheme (besides it is a dead project), this should work. Regards, Daniel watch Description: application/fluid
Re: Peer review of copyright files.
Am Donnerstag, den 11.12.2008, 00:15 +0900 schrieb Charles Plessy: > Although it should never happen, sometimes a new package we submit to our > archive managers is rejected because the description of the copyright status > of > its files is either incorrect or lacunar. This is waste of precious time for > everybody. In order to ameliorate the quality of our submissions, I propose to > introduce a dose of optional pre-submission peer review. > > One may wonder why not reviewing all QA aspects of a package? One reason is > that this requires skills that are not evenly distributed, Well, licensecheck(1) exists. Maybe many packagers don't know it? [..] > PS: and of course, consider using the machine-readable format if you have not > tried yet: http://wiki.debian.org/Proposals/CopyrightFormat Would be nice to have a licensecheck mode to compare debian/copyright to the checked source. Regards, Daniel -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: How to debug problems in postinst using debconf / dbconfig common
Andreas Tille wrote: > I try to build a package from mlstdbnet for Debian Med. The > packaging stuff is available here: [..] > If I build the package I get an error message but failed > to track down the problem: > > ~> sudo dpkg -i mlstdbnet_2.0.0-1_all.deb > (Reading database ... 341999 files and directories currently installed.) > Preparing to replace mlstdbnet 2.0.0-1 (using mlstdbnet_2.0.0-1_all.deb) > ... > Unpacking replacement mlstdbnet ... > Setting up mlstdbnet (2.0.0-1) ... > dpkg: error processing mlstdbnet (--install): > subprocess post-installation script returned error exit status 128 > Errors were encountered while processing: > mlstdbnet `set -ex' in your scripts (you can do the same in the debconf scripts). I further found an echo to stdout in your postinst. debconf cannot handle this very well [1] and it may lead to make the script fail. Echo to stderr instead. The same goes for any other output to stdout created by the commands in your postinst script. [1] http://lists.debian.org/debian-devel/2008/10/msg00790.html Regards, Daniel -- NUR NOCH BIS 31.01.! GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 EURO/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Display upgrade note
Am Montag, den 25.07.2005, 18:40 +0200 schrieb Roland Gruber: > probably this has been asked before but my searches did not give proper > results. > > I want to display a message to the user via debconf. The message should > only appear if the user upgrades from a version below a special value > (0.5.0 in my case). Maybe you want to think about these two alternatives: - add a NEWS.Debian so users with apt-listchanges installed will see the advice (the advice should of course also be mentioned in README.Debian or a similar file) - this is IMO the most common way for upgrade/update notes - add the debconf message to the package in general (a note like: If you are upgrading from a version below ..." ) and done Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autotools during build
Am Freitag, den 12.08.2005, 02:12 -0700 schrieb Steve Langasek: > On Fri, Aug 12, 2005 at 10:15:41AM +0200, Bas Wijnen wrote: > > I have some packages which use autotools. I thought it would be good to > > compile as much as possible, so it is clear all the sources are correct. > > That > > means including autoconf, of course. > > > However, linda doesn't agree with that: > > W: gfpoken; Package Build-Depends on automake* or autoconf. > > This package Build-Depends on automake* or autoconf. This is almost > > never a good idea, as the package should run autoconf or automake on > > the source tree before the source package is built. > > > lintian doesn't consider this to be a problem. > > > My question is: is linda correct and should I not run autoconf from > > rules.make? Extrapolating that would mean that compilation is not needed at > > all, if a precompiled version of the program is packaged in the source > > tarball. That doesn't seem right to me. So if linda is right, then where > > is > > the limit? Generated files which are included for portability reasons > > (such as > > configure) are ok, but others are not? > > The limit is between autogenerated sources that upstream ships in the > tarball, and autogenerated sources that are expected to be built at build > time. > > If you rerun autoconf/automake/libtool at package build-time, when you don't > need to, what you get are large diffs against upstream every time a new > version of the autotools becomes available. The advantage: If the autotools package maintainers do a good job (and I believe they do), you will always have up-to-date and working autotools stuff/macros/scripts in the package. The disadvantage: It surely increases the diff's size. > Aside from wasting (a little) > space in the archive, that makes it harder for NMUers or passing developers > to see what's going on in your package. In this case, you could use dpatch to change things and then it is not harder to see, what is going on. > The autotools-dev README.Debian is a good guide to these issues. But it does not recommend a special way. It also explicitly mentions the way, the OP asks for. - just my 2 cents - Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autotools during build
Am Freitag, den 12.08.2005, 06:12 -0700 schrieb Steve Langasek: > On Fri, Aug 12, 2005 at 01:50:33PM +0200, Daniel Leidert wrote: > > > Aside from wasting (a little) > > > space in the archive, that makes it harder for NMUers or passing > > > developers > > > to see what's going on in your package. > > > In this case, you could use dpatch to change things and then it is not > > harder to see, what is going on. > > No, it just makes it hard to examine the differences between two versions > using debdiff, rather than making it hard to look at the diff for a single > version. Ok, now I understand. But IMHO this is always hard to examine when changes become bigger. So this is IMO not an absolute killer argument. But in general ACK. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adding own Software?
Am Dienstag, den 16.08.2005, 01:00 +0200 schrieb Dirk Nolting: > During my PhD thesis I started to develop a program to calculate the > isotopic distribution of a molecule. AFAIK there is no program within > debian to do this. Therefore I would like to contribute this program to > debian. Do it. Now! :) > I'm not sure what you think about people contributing their own software > or about such a program which is only of use for a small group of users. There are a lot of programs for a small group of people. Build a package for your software and provide it. > So would it make sense to contribute a debian package Yes, of course. > and if yes how to proceed best? If you want to build the package yourself, you should open an ITP bug-report against wnpp, read the Debian New Maintainers Guide, build your package, upload your (source) package (maybe to mentors.debian.net) and discuss the result with experienced packagers/developers (e.g. at mentors mailing list). If everything is ok, search for a sponsor (read the mentors faq) or become a DD (described somewhere at debian.org) to officially get your package into Debian. If you don't want to package the software yourself, you should open a RFP bug-report against wnpp and search for someone, who wants to build the package. BTW: Please advertise a cross-post. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pkg-config
Am Samstag, den 03.09.2005, 20:24 +1000 schrieb skaller: > On Fri, 2005-09-02 at 22:11 -0700, Steve Langasek wrote: > > > > > Er... that's certainly not enforceable. > > > > > Sure it is. If they're not provided, then lintian fails > > > the package, and the sponsors refuse to upload it, > > > same as other policies. > > > > No, it's not. > > Quite clearly it is perfectly *possible* > as I claimed to enforce it. > > > The .pc names are set by upstream and we should not > > diverge from them, > > The .pc names can be set by the Debian maintainer, > and the original .pc file ignored even if upstream provides it. > > You may well be right this is not a good idea, Sorry, but this is an IMO absolutely silly idea. Then you have to adjust configure scripts, which run tests for these libs/applications. And a lot of programs test for apps using pkg-config. Your idea breaks with them. > I'm not arguing it is. However a policy could > be made and be enforced. No. The only thing you maybe could do is to make a symlink, which follows the Debian package name but links to the .pc file provided by upstream. But I cannot see an advantage doing this. A configure script using these .pc files will be specific to Debian. So this is IMO useless. > In particular, at present, pkg-config is plain useless > because it isn't consistently supported. I cannot agree. Can you give an example? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Change version number only for a different build.
Am Montag, den 05.09.2005, 15:06 +0200 schrieb Antonio Ospite: > Hallo, > > I'm learning something about debian packages, policy and repository, and > I'm trying to make an automatic repository (hence with a "pool" > directory), but i have a question. Can you help me, please? > > Since my packages are "unofficial" I want them to be built for sarge and > sid (i use pbuilder for that), but in the same upstream version; is that > allowed by the policy. No problem. Your packages are unofficial. Builds for Sarge are only backports (see backports.org). I do the same for my packages. > What i have to do? Normally it is the best idea to show that an package is unofficial. A lot of people therefor add their initials to the Debian revision. I suggest the following (xy are the initials): Sid 0xy1 Sarge 0xy0(.)sarge(.)1 To still upload the sources use the dpkg-buildpackage option -sa. > I tought i can use a different package version for binary packages > targeted to different distribution, does something like package_x.x-1 > for sid and package_x.x-1sarge for sarge sound reasonable to you? I do not suggest to use -1, -2 ... for unofficial packages. > And how do i have to report the different builds in the changelog? > Is it an acceptable practise to add a changelog entry only for a build > on a different distribution? Have a look at the backports.org packages. I think, this is a good solution. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adding new mime-types
Am Freitag, den 09.09.2005, 12:54 +0200 schrieb vud1: > Hi all. > > I am doing a debian-package for a program that i am writing. My program > is an diagram-tool that saves files *.cgt (xml files that i have > invented specially for my application). > > I would like to integrate my program with gnome, so i would like to make > a deb package that would insert the new mime-types and asociated the > *.cgt extension with my program. > > At this moment i have create a program.keys and a program.mime files in > /usr/share/mime-info Obsolete since GNOME 2.8 (really used only for GNOME <= 2.4) and AFAIK not longer used. To associate your program with your MIME-type you need to create a .desktop-file and install it into /usr/share/applications. See [1]. > I have create too a program file in > /usr/lib/mime/packages You need to create a new entry for the shared-mime-info database in /usr/share/mime/packages. See [2]. The above mentioned directory contains the entries for metamail's /etc/mimecap. > but the system dont recognize my *.cgt files yet... When i right-click > over my *.cgt file nautilus said me that this is a text/xml content, and > not application/x-program :( Did you run update-mime-database (to recognize the new MIME type) and update-desktop-database (to update the MIME<->Application database)? > So.. i think that a need any more configurations.. I have reeding > documentation and i think that i must use the update-mime comand in my > debian/postinst script.. but it is not enought. The postinst script is ok, but you run update-mime-database without installing the necessary entry to /usr/share/mime/packages. [1] http://standards.freedesktop.org/desktop-entry-spec/latest/ [2] http://standards.freedesktop.org/shared-mime-info-spec/latest/ Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: managing my packages with svn
Am Donnerstag, den 13.10.2005, 11:59 +0200 schrieb Bastian Venthur: > Fathi Boudra wrote: > > > Le Jeudi 13 Octobre 2005 10:53, Bastian Venthur a écrit : > >> Hi mentors, > >> In order to keep track of my changes in the development of my packages > >> I've decided to put my "debian" folder with all the packages and sources > >> inside into a svn repo. > >> > >> My question is simple: Are there common pitfalls I should look out for? I > >> could imagine, that all the new .svn dirs in every folder could cause > >> some trouble, when building new packages. > > > > take a look at http://workaround.org/moin/SvnBuildpackage > > Thanks for pointing me to SvnBuildpackage. Allthough I think it provides a > good way of keeping track of your changes, I'm afraid the whole > buildprocess becomes too complicated -- especially for New Maintainers (me > included). I don't use/know svn-buildpackage, but cvs-buildpackage and I can tell you, it is very easy to use (so I think, svn-buildpackage is too if you know svn). > I think I still prefer the easy way by just putting the debian-dir (where > all my packages are stored) under svn control or maybe an own repo for > every package. If you want to have a look at a cvs-repo for Debian packages have a look at http://cvs.wgdd.de/cgi-bin/cvsweb/?cvsroot=debian. So if you want, you can also test cvs-buildpackage with anonymous checkout. If you really want to give it a try, I suggest to use "cvs-buildpackage -C'debuild ...'". > This way I just have to deal with two seperate problems: > (1) ci/co > (2) building the package as usual > > Does anything speak against my method? BTW: how do I make pdebuild and > debuild to ignore the .svn dirs? Make an export, not a checkout. But normally debuild/pdebuild should not complain about .svn dirs. Do you mean linda/lintian? In this case, you need to add a short ignore-warning hint for linda/lintian. BTW: I suggest to use DEBUILD_LINTIAN=yes DEBUILD_LINDA=yes DEBUILD_LINTIAN_OPTS="-i -I" DEBUILD_LINDA_OPTS="-i" in /etc/devscripts.conf (runs linda and lintian automatically after every debuild run and it further outputs some more info). just my 2 cents Regards, Daniel
Re: managing my packages with svn
Am Donnerstag, den 13.10.2005, 15:32 +0300 schrieb Damyan Ivanov: > Daniel Leidert wrote: > > Am Donnerstag, den 13.10.2005, 11:59 +0200 schrieb Bastian Venthur: > >>Does anything speak against my method? BTW: how do I make pdebuild and > >>debuild to ignore the .svn dirs? > > > > Make an export, not a checkout. But normally debuild/pdebuild should not > > Explicit export is not necessary. Use -i argument for debuild. I cannot find such an option for debuild, but for dpkg-buildpackage, where it is followed by a regex-pattern. Do you really mean this option? > Use pdebuild --- --debbuildopts -i > or put DEBBUILDOPTS="-i" in /etc/pbuilderrc for pbuilder/pdebuild. > > > complain about .svn dirs. Do you mean linda/lintian? In this case, you > > need to add a short ignore-warning hint for linda/lintian. > > I strongly advice against this. linda/lintian warnings about revision-control > files in source are there for purpose. Ignorimg them "for convenience" leads > to > uploading source packages with .svn in them. I am sorry. It was not my intention to say, that it is ok to ignore these warnings - therefor I also tried to give the hint about export. It was only the advice, that it can be only ignored with a special file. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Overriding over Linda/Lintian
Am Dienstag, den 18.10.2005, 14:13 -0400 schrieb -.JavaManiac.-: > Im packaging urlgfe,an some others,when i run Linda over the package > it gives me 2 warnings about shared libraries,here is the output > > > linda -Di *.changes > W: urlgfe; Shared object /usr/bin/urlgfe is linked with version 0.9.8 > and 0.9.7 of libcrypto. [..] > how can i override the warnings,and/or add the override to the package?? Why do you want to override this warning? Is it a wanted feature or a false positive? To override a warning, you need to add a special file. Have a look at the files in /usr/share/linda/overrides/ and /usr/share/lintian/overrides/. You need to create such files and copy them to you build-path, so they become part of the package. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Menu problems
Am Samstag, den 19.11.2005, 20:51 -0500 schrieb Daniel Milstein: [update menu from .desktop file] > Nevermind; I figured it out. > > For those searching through the archives, the problem was that KDE did not > have all of the menu categories listed at freedesktop.org in its system. In > addition, KDE needed "Applications" to be in Categorie. AFAIK that's wrong. Which KDE version needs this? AFAIK GNOME used the Application-Category in it's old .desktop files. But both do not longer need this obsolete category. You need to run update-menus to update any menu. update-desktop-database updates /usr/share/applications/mimeinfo.cache - a database, which applications can handle a MIME-type. It does not update a menu. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Move config-files from /etc into /etc/foobar during package upgrade
Hello, I'm currently preparing an update for a package. Until now, the configuration file(s) was/were located in /etc. Now there are changes, which make it more useful to have the configuration files inside /etc/foobar. The configuration files look like foobar.conf*. Are there special things I need to care of? Does anyone know a package, where the configuration files moved? I already added a NEWS file. But not every user installed apt-listchanges, so I should also inform him during update. Is it enough, do this on command-line or should I better use a debconf-dialog? Is it enough to only inform the user or should I better ask him [1], if his configuration files should be moved? What would you do? [1] If the files are not moved, the package breaks. Alternatively I could (re)add /etc as search-path for the config-files, but moving the files is really recommended. Would you add this backwards compatibility "option"? PS: I know, these are very generic information. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Move config-files from /etc into /etc/foobar during package upgrade
Am Samstag, den 31.12.2005, 08:15 -0500 schrieb Justin Pryzby: > On Sat, Dec 31, 2005 at 12:42:06PM +, Mark Brown wrote: > > On Sat, Dec 31, 2005 at 03:37:03AM +0100, Daniel Leidert wrote: > > > > > Are there special things I need to care of? Does anyone know a package, > > > where the configuration files moved? I already added a NEWS file. But > > > not every user installed apt-listchanges, so I should also inform him > > > during update. Is it enough, do this on command-line or should I better > > > use a debconf-dialog? Is it enough to only inform the user or should I > > > better ask him [1], if his configuration files should be moved? What > > > would you do? > Well I *did* send a mail about this last night, but it seems to have > been eaten by the mailer demon of 2006. I got your mail and read the content of the link (thanks for that). Maybe you didn't send it to the list. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Extra debian repository
Am Samstag, den 14.01.2006, 06:05 +1100 schrieb Matthew Palmer: > On Fri, Jan 13, 2006 at 08:04:01PM +0200, Mugurel Tudor wrote: > > - the repository created is a trivial one (something like "deb > > http://server/dir1/dir2 dir3/"), and dir3 containes the packages > > involved and the Packages.gz (created with dpkg-scanpackages) > > Hint: use apt-ftparchive. It's a lot tidier. Or have a look at http://wiki.debian.org/HowToSetupADebianRepository for a list of solutions to prepare a Debian repository. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Lintian Warnings and Modifying Upstream Source
Am Samstag, den 21.01.2006, 13:15 -0800 schrieb Cameron Dale: > I'm trying to create a new package for Debian, and I have some Lintian > warnings that I'm not sure how to deal with. [..] > > W: torrentflux: extra-license-file var/www/torrentflux/adodb/license.txt > > The first 4 are easily fixed by removing the files. The last one is a > little more problematic, but I asked on debian-legal, and as the > license file is for the LGPL, then the package can redistribute it > under the GPL, and I think that means I can remove the license file. > > I've asked upstream to remove these files, but no response yet. debian/copyright is the file which should contain all license information. So add the related information (which part of the package is affected, under which license this part is released, the short license and a link to /usr/share/common-licenses/LGPL) to debian/copyright and remove license.txt from the resulting binary package, but not from the source. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do if the upstream keeps debian directory in original tarball?
Am Dienstag, den 24.01.2006, 13:14 -0800 schrieb Stan Vasilyev: > I have a situation with a Debian package xdialog: > http://packages.qa.debian.org/x/xdialog.html > > The upstream author, Thierry Godefroy <[EMAIL PROTECTED]>, insists on keeping > the debian changes inside the upstream tarball, orig.tar.gz. This complicates > the development process. First of all, when he makes a new version of > xdialog, he sends it to the Debian maintainer (me). I then have to make > changes to the debian directory and send him the changes. Finally, he > releases the new upstream with Debian changes already included. > > What do I do with the Debian .diff.gz? Because of the above, it's hard to see > what's going on in .diff.gz to check the quality of the package. Also, it > makes it even harder to release incremental changes to the Debian package. > > I tried convincing the upstream to remove the debian directory, but so far he > refused. His argument is that a user should be able to download his tarball > and build it from source, build an rpm package or build a deb package. The user can do an "apt-get source" from the Debian archives. I don't see his point. As long as upstream ships _your_ Debian packaging files, the user can use the source of the official Debian package and upstream really doesn't need to ship the packaging files. Maybe you should also tell him, that not every user getting the upstream sources may be happy with your packaging files (e.g. because of your decision of (build-)dependencies and configure options, different available library versions in different Debian-based distributions, the usage of a special patch- or build-system, ...). So shipping the Debian packaging files may be more offending and annoying then not shipping them. > I sent > one more e-mail to him where I presented an argument that his strategy slows > down the development process and introduces more problems than it solves. > > If Thierry refuses to remove the debian directory, would it be OK for me to > remove it myself and repackage pristine source without it? What else can I > do? There are possibilities and also alternatives you can suggest. But first try discussion. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Update] Re: What to do if the upstream keeps debian directory in original tarball?
Am Donnerstag, den 26.01.2006, 19:30 -0800 schrieb Stan Vasilyev: > On Tuesday 24 January 2006 13:14, Stan Vasilyev wrote: > > I have a situation with a Debian package xdialog: > > http://packages.qa.debian.org/x/xdialog.html > > > > The upstream author, Thierry Godefroy <[EMAIL PROTECTED]>, insists on > > keeping > > the debian changes inside the upstream tarball, orig.tar.gz. This > > complicates the development process. First of all, when he makes a new > > version of xdialog, he sends it to the Debian maintainer (me). I then have > > to make changes to the debian directory and send him the changes. Finally, > > he releases the new upstream with Debian changes already included. > > From the last e-mail I got from Thierry it looks like he wants to make a > compromise. Since I annoyed him so much with my e-mails, he proposed to start > releasing Xdialog in two versions: Xdialog-version.tar.bz2 file with debian > directory and Xdialog-version.orig.tar.gz without the debian directory. Is > that such a good idea? It's a compromise with more work for him. > At this point he thinks that Debian developers are a bunch of political > fanatics who only care about the holy Debian Policy Manual and don't care > about other distros. Why we "don't care about other distros"? The Debian packaging files you wrote are based on your decisions for Debian _only_, not for all Debian based distributions. So forcing others to use your packaging files is what I call "don't care about other distributions". Or whyy should the source package on RedHat or Mandriva contain the Debian packaging files? They are completely useless there but they increase the archive size. I really don't understand this position. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to dpatch a file inside a tarball inside an .orig.tar.gz?
Am Sonntag, den 12.02.2006, 20:01 +0100 schrieb Marc Haber: > The eximdoc4 source package is built from two upstream tarballs, one > with the texinfo docs and one with the html docs. To massage this into > Debian source package format, the two upstream .tar.bz2 tarballs are > tar.gz'ed together to form eximdoc4_foo.tar.gz. > > It has now shown to be necessary to apply patches to the upstream > docs. I would like to use dpatch for that. Could you also write a bug-report for dpatch? This is a feature I also miss and I would of course support such a request. > Which approach is the most promising and least ugly? > > (1) > Have a 01_unpack.dpatch file which doesn't patch, but unpack the > upstream tarballs? IMO a possible workaround. > (2) > Transform the "Debian upstream tarball" (which is locally built anyway > to include the two upstream tarballs in unpacked form? The tar.gz will > be much bigger then since bz2 compression is rather effective on the > text docs. That's of course a solution that works with dpatch. > (3) > Modify debian/rules to first unpack, second patch, third build? Does work in the real build process, but not for dpatch-edit-patch,w hich does not work like this. It only makes a copy of the working directory, then runs the clean target in this copy and then makes again a copy, which is your new work-directory. You would have to add an unpack target to the clean target, which is probably not a good idea. > Is there a package which does this and can be taken as a template? patch. Then you can move it to dpatch format. The only problem is, that you cannot create patches with dpatch-edit-patch. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to dpatch a file inside a tarball inside an .orig.tar.gz?
Am Montag, den 13.02.2006, 01:24 -0600 schrieb Peter Samuelson: > [Daniel Leidert] > > Am Sonntag, den 12.02.2006, 20:01 +0100 schrieb Marc Haber: > > > It has now shown to be necessary to apply patches to the upstream > > > docs. I would like to use dpatch for that. > > > > Could you also write a bug-report for dpatch? This is a feature I also > > miss and I would of course support such a request. > > Well, note that (1) is already possible and not even all that hard. Of course, but it's a "useless" patch. You better remove that patch from the source when making the final package, because the patch would increase the package-source size. But if you then make a new package revision, you have to re-add this patch again. There should be an easier solution. Maybe only add a possibility to define one or more targets to run after creating the clean workspace. That's IMHO a clean and easy to use/implement solution. > That is, to have a .dpatch file whose purpose is to unpack the tarball > on 'patch' and delete the tree on 'unpatch'. But as I said: Such a patch would be big and it should not stay inside the package-source. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[linda] W: A binary links against a library it does not use symbols from
Hello all, I need some help trying to fix the following linda warning: W: winefish; A binary links against a library it does not use symbols from This package contains a binary that links against a library that is not in the Depends line. This may also be a bug in the library which does not have a shlibs file. My problem: How can I determine the library the warning is about? I build the package in my environment and in a pbuilder environment. Both show the same 'Depends:' line. And there is no FTBFS. So how could I determine the library? There are IIRC graphical tools to build a diagram with dependencies for a package, right? This could be one way. Do you know a better way? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to create a Release file
Am Freitag, den 21.04.2006, 17:28 +0200 schrieb Tomas Davidek: > Hello, >I am having troubles when creating the Release file for my "private" > repository. According to > http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pack-sign > I create the file via > > $ rm -f dists/testing/Release > $ apt-ftparchive release dists/testing > dists/testing/Release > $ gpg --sign -ba -o dists/testing/Release.gpg dists/testing/Release > > Then, when trying apt-get update, I get the following error message: > > Failed to fetch > http://www-ucjf.troja.mff.cuni.cz/~davidek/debian/dists/testing/Release > Unable to find expected entry main/binary-i386/Packages in Meta-index file > (malformed Release file?) > Reading package lists... Done > W: Conflicting distribution: http://www-ucjf.troja.mff.cuni.cz testing > Release (expected testing but got ) ^ This is important. Your Release-file does not contain a Suite: (nor a Codename:) field. I don't know, what the first part of the error means. > > Well, I don't understand it - the file main/binary-i386/Packages does > not exits, there is only main/binary-i386/Packages.gz. Is that ok ? I guess this should not be a problem. > I rather suspect that there is something wrong with the Release file > itself, it seems some header is missing. My Release looks like: > -- > Date: Fri, 21 Apr 2006 13:45:27 UTC > MD5Sum: > d41d8cd98f00b204e9800998ecf8427e0 Release > 44a11d9ba1cc5fe28646ca9b9e3c 1269 > main/binary-amd64/Packages.gz > ab29d796accdd96e9f700399d1f70ef9 925 > main/binary-amd64/Sources.gz > a7a653a9884509b6f6612cab71047ab9 1269 > main/binary-i386/Packages.gz > -- > while the Debian ones have a header in the beginning: > --- > Origin: Debian > Label: Debian-Security > Suite: testing > Codename: etch > Date: Mon, 17 Apr 2006 08:35:59 UTC > Architectures: amd64 alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 > sparc > Components: updates/main updates/contrib updates/non-free > Description: Debian testing Security Updates > MD5Sum: > 5c8b4d953e776a92ca7d6da9edcb7196 7914 main/binary-alpha/Packages > 927ab0a52245a0be815c50f5fdb58ca5 1867 > main/binary-alpha/Packages.gz > > Is that important ? Yes. One error you always got. But these entries are also necessary to allow a user to pin your repository. > If so, is there any script to generate the header or do I have to do > it myself ? You can put the information into a "configuration" file and run apt-ftparchive with this file. The content of the file would look like this: APT::FTPArchive::Release::Origin "..."; APT::FTPArchive::Release::Label "..."; APT::FTPArchive::Release::Description "..."; APT::FTPArchive::Release::Suite "testing"; APT::FTPArchive::Release::Codename "etch"; APT::FTPArchive::Release::Architectures "..."; APT::FTPArchive::Release::Components "..."; Alternatively you can use the '-o' option on command line for every entry: apt-ftparchive \ -o APT::FTPArchive::Release::Origin="..." \ -o APT::FTPArchive::Release::Label="..." \ -o APT::FTPArchive::Release::Architectures="..." \ -o APT::FTPArchive::Release::Components="..." \ -o APT::FTPArchive::Release::Description="..." \ -o APT::FTPArchive::Release::Codename="etch" \ -o APT::FTPArchive::Release::Suite="testing" \ release dists/testing > dists/testing/Release.tmp mv Release.tmp Release There is an issue directly outputting Release with the above command (not using Release.tmp). The problem is, that in this case the Release file contains a 0-entry for itself (you can verify this with your own Release file). > Maybe the problem could be that I am running sarge on the system where > I generate the packages and all the files for repository ? (i.e. > older version of apt-utils ?) That shouldn't be a problem. I run debarchiver from Sid on my Sarge system to generate a valid repository for Experimental, Sid and Sarge. And there are no problems. > Thanks a lot for any hint, Maybe this can help you too: http://wiki.debian.org/HowToSetupADebianRepository Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to create a Release file
Am Dienstag, den 25.04.2006, 10:34 +0200 schrieb Tomas Davidek: > Damyan Ivanov wrote: > > >apt-ftparchive(1) gives: > > release > > The release command generates a Release file from a directory > > tree. It recursively searches the given directory for Packages, > > Packages.gz, Packages.bz2, Sources, Sources.gz, Sources.bz2, Re‐ > > lease and md5sum.txt files. It then writes to stdout a Release > > file containing an MD5 digest and SHA1 digest for each file. > > > > Values for the additional metadata fields in the Release file > > are taken from the corresponding variables under APT::FT‐ > > PArchive::Release, e.g. APT::FTPArchive::Release::Origin. The > > supported fields are: Origin, Label, Suite, Version, Codename, > > Date, Architectures, Components, Description. > > > >See second paragraph. Perhaps a couple of "-o APT::FTPArchive::Xyz=Foo" > >options could help? > > > > > Thanks for the answer, unfortunately it does not work (at least not in > stable release). Any option I specified is not taken into account (no > error messages on the output either!), the Release file still begins > only with: > -- > Date: Tue, 25 Apr 2006 08:30:22 UTC > MD5Sum: > ... > -- Would you please be so kind to post your exact command and where you run it? > Maybe upgrading to testing solves the problem ?? No. As I already said in my other mail: the version in Sarge can create those files. > Another question - > where the Release file should be located ? According to docs I placed it > into dists/, but when looking at the debian mirrors I see also > some Release files in dist//main/binary-i386 etc > > Can anyone comment on it, please ? Goswin von Brederlow already did. Just a minor addition: Only Sarge uses the Release files e.g. dists/sid/main/binary-i386/Release for pinning. Testing and unstable use the file e.g. dists/sid/Release. AFAIK the other files are not longer downloaded. Regards, Daniel
doc-base and sub-directories
Hello, A short question about the doc-base control files. I have a package, where the documentation contains several sub-directories in the form doc/*.html doc/app-part1/*.html doc/app-part2/*.html ... Now what is the right for the doc-base control file (I looked into the doc-base docs and also through the files I have in /usr/share/doc-base)? Does the following example: Format: HTML Index: /usr/share/doc/package/doc/index.html Files: /usr/share/doc/package/doc/*.html /usr/share/doc/package/doc/*/*.html (I found this in /usr/share/doc-base/libxml2-doc) index all files in the sub-directories? Or does Format: HTML Index: /usr/share/doc/package/doc/index.html Files: /usr/share/doc/package/doc/*.html automatically index all *.html files in sub-directories too (I guess not)? Thanks in advance and regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doc-base and sub-directories
Am Samstag, den 20.05.2006, 13:26 +0200 schrieb Daniel Leidert: > A short question about the doc-base control files. I have a package, > where the documentation contains several sub-directories in the form > > doc/*.html > doc/app-part1/*.html > doc/app-part2/*.html > ... > > Now what is the right for the doc-base control file (I looked into the > doc-base docs and also through the files I have in /usr/share/doc-base)? > Does the following example: > > Format: HTML > Index: /usr/share/doc/package/doc/index.html > Files: /usr/share/doc/package/doc/*.html > /usr/share/doc/package/doc/*/*.html > > (I found this in /usr/share/doc-base/libxml2-doc) > > index all files in the sub-directories? An interesting issue I found using exactly this "code": Linda complains about "File not found for field Files in doc-base file /usr/share/doc/package/doc/*.html". When I remove the linebreak (newline) in the Files field, the linda warning disappears. Is this intended? In every case, this should be documented somewhere. CC to debian-doc mailing list Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: doc-base and sub-directories
Am Samstag, den 20.05.2006, 07:43 -0700 schrieb Russ Allbery: > Daniel Leidert <[EMAIL PROTECTED]> writes: > > Am Samstag, den 20.05.2006, 13:26 +0200 schrieb Daniel Leidert: > > >> Now what is the right for the doc-base control file (I looked into the > >> doc-base docs and also through the files I have in /usr/share/doc-base)? > >> Does the following example: > >> > >> Format: HTML > >> Index: /usr/share/doc/package/doc/index.html > >> Files: /usr/share/doc/package/doc/*.html > >> /usr/share/doc/package/doc/*/*.html > >> > >> (I found this in /usr/share/doc-base/libxml2-doc) > >> > >> index all files in the sub-directories? > > > An interesting issue I found using exactly this "code": Linda complains > > about "File not found for field Files in doc-base > > file /usr/share/doc/package/doc/*.html". When I remove the linebreak > > (newline) in the Files field, the linda warning disappears. Is this > > intended? In every case, this should be documented somewhere. > > Sounds like a bug in linda. Maybe it doesn't support wrapped fields? Thanks for both answers. I filed a bug-report against linda. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Closing bugs tagged as $oldstable
Hello, Short question, because I wasn't successful to find the answer myself: How are bugs treated, that are tagged as $oldstable (currently woody)? When these bugs can be closed? Or do they have to stay open for all the time? How do you treat such bugs? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Closing bugs tagged as $oldstable
Am Montag, den 31.07.2006, 11:19 -0400 schrieb Justin Pryzby: > On Mon, Jul 31, 2006 at 04:36:24PM +0200, Daniel Leidert wrote: > > Hello, > > > > Short question, because I wasn't successful to find the answer myself: > > How are bugs treated, that are tagged as $oldstable (currently woody)? > Since version tracking is implemented [0], all the "distribution tags" > mean "this bug should get fixed here (so don't archive the bug)" > instead of "this bug applies here". Following the BTS, it reads: | This bug particularly applies to the woody|potato distribution. I oversaw, that it was changed for sarge, etch and sid. > > When these bugs can be closed? > When $oldstable gets a fixed package, or the maintainer no longer > intends to persue such a fix. $oldstable is no longer supported, right? So this means, I could close those bugs? > > Or do they have to stay open for all the time? > I suppose so (*wonders if there will be an $etch+1 tag*). You mean for the next testing? > > How do you treat such bugs? > I'll note that many times these distribution tags may have been set > before the version tracking was implemented (or before the person > setting the tag knew how to use it). So, if there's reason to believe > this, and reason to believe that the maintainer doesn't actually > intend to support woody, then the tag could be removed. ... and the bug closed, when it is already solved or not longer reproducible in >= Sarge? The reason, why I ask: I have 2 bugs open in a package and both only apply to Woody, but not to Sarge, Etch or Sid. So I want to know, when or under which circumstances I can close or "drop" them. Thanks and regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging non-compiled files
Am Mittwoch, den 02.08.2006, 11:13 -0400 schrieb Kit Peters: > I asked a similar question on debian-user, and was recommended to come > here instead. > > At my job, we would like to use apt to distribute certain packages, > such as WWW applications written in PHP, to certain other of our > machines. The way I had been doing this was to write a simple > Makefile with an empty 'all' target and having an 'install' target > that installs the various files in the application to their proper > locations. This works, for the most part, but I'm wondering if > there's a better way to do it. If you just want to put some files into special dirs, you can use dh_install (man dh_install) in debian/rules. So you can avoid writing long Makefiles or complicating debian/rules. The are other dh_install* (and dh_*) debhelper scripts, which can help you to install special filetypes (e.g. dh_installexamples, dh_installdocs, dh_installcatalogs, dh_installman, ... etc.). Have a look at their manpages to find out, how to use these scripts. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to write a good manpage ?
Am Donnerstag, den 17.08.2006, 14:20 +0200 schrieb Marco Bertorello: > Hi Mentors, > > I always used help2man to generate a manpage for those packages that > hasn't one. > > But now, I'm working on a package that has a non useful help output: > > $ gcstar --help > Usage: /usr/bin/gcstar [[-u|--update [-a|--all] [-c|--collection] > [-w|--website] [-i|--import] [-e|--export] [-l|--lang]] | [FILE]] > > How can I write a manpage good for debian? I always use DocBook XML and then I process the XML sources the current docbook-xsl stylesheets (make sure to use the latest version available in Sid - the version in Sarge is buggy). If you want to have a look at some examples: http://debian.wgdd.de/temp/fglrx_man/ (sources: http://cvs.wgdd.de/cgi-bin/cvsweb/fglrx_man/) the manpages for xmllint, xsltproc and xmlcatalog (but they miss the '|' in the commandsynopsis, because they were created using an older version of the stylesheets) http://cvs.savannah.nongnu.org/viewcvs/gchemutils/docs/man/?root=gchemutils&only_with_tag=gchemutils-0-6 These are a few manpages, which I wrote with DocBook XML. IMO apt and aptitude also use XML to write the manpages. So you can also have a look at their sources. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to write a good manpage ?
Am Donnerstag, den 17.08.2006, 15:46 +0300 schrieb Damyan Ivanov: > Marco Bertorello написа: > > I always used help2man to generate a manpage for those packages that > > hasn't one. > > > > But now, I'm working on a package that has a non useful help output: > > > > $ gcstar --help > > Usage: /usr/bin/gcstar [[-u|--update [-a|--all] [-c|--collection] > > [-w|--website] [-i|--import] [-e|--export] [-l|--lang]] | [FILE]] > > > > How can I write a manpage good for debian? > > /usr/share/doc/man-db/examples/manpage.example > /usr/share/debhelper/dh_make/debian/manpage.xml.ex In the case of using this example, please note the following tips when working with the latest docbook-xsl packages in Sid: - the mail address belongs into the author tag and you should add the contrib tag, if the term "Author." does not fit, what you did - the self-written AUTHOR section should be removed - the section conflicts with -> the automatically created AUTHOR section with the info from the authorgroup|author|editor|othercredit elements -> the automatically created license and copyright section with the info from the copyright|legalnotice elements - the varlistentry/term elements should be used as follows -h --help and the output should be controlled via the variablelist.term.separator and variablelist.term.break.after parameters > /usr/share/debhelper/dh_make/debian/manpage.sgml.ex > /usr/share/debhelper/dh_make/debian/manpage.1.ex > > (last three from dh-make package) > > Except for the synopsis above, you should describe each option's > meaning and what the program does. Write in the manpage whatever you'd > expect to read if you face the program for the first time :) http://www.tldp.org/HOWTO/Man-Page/q3.html The howto is a good reference, what is at least expected to be found in the manpage. Regards, Daniel
Re: Huge private Debian repository...
Am Montag, den 28.08.2006, 14:08 +0200 schrieb Michelle Konzack: > since I am Debian GNU/Linux Consultant I have many customized packages > or Customer specific Applications. I run my ownRepository and a devel > server andnow it give me problems with the administration, because I > have too much packages... and releases. > > I need an archive system like the Debian FTP's for woody, sarge, etch > and sid. I was searching the Debian website and the Internet but have > not found any HOWTO's or documentations HOWTO install such system. > > Can anyone point me to the approprieted resources please? I guess, when you talk about an "archive system", you are looking for http://wiki.debian.org/HowToSetupADebianRepository and you want dak or reprepro. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: n00b lib packaging question
Am Dienstag, den 29.08.2006, 12:44 -0400 schrieb Jean-Sebastien Pilon: > I am trying to create packages from sources for libpcap compiled with > the libpfring library. This compiles no problem. When I am packaging > though... there are the issues coming up Wink > > # fakeroot debian/rules clean > # debian/rules build > # debian/rules binary > till now it's ok > > i have 2 .debs which contains only the documentation... > > so edited debian/rules and uncommented dh_install Wink > > after another complete run, still nothing else than the docs in the > packages... > > > # ls debian/ > changelog compat control copyright dirs docs libpcap-ring1.dirs > libpcap-ring1.install libpcap-ring-dev.dirs libpcap-ring-dev.install > rules [snip] > 3 new folders... tmp libpcap-ring1 libpcap-ring-dev [..] > i guess debian/binary is looking in those 2 directories since it wants > to create 2 packages In compat level 4, the files to package are expected in debian/$package. > am i right? does it make sense? hehe > > how can i fix this ? What's inside libpcap-ring1.install and libpcap-ring-dev.install? You need to "copy" the files from debian/tmp to debian/$package to split the files into separate packages. Normally I would expect at least debian/tmp/usr/lib/*.so.* usr/lib for the library- and debian/tmp/usr/lib/*.la usr/lib debian/tmp/usr/lib/*.so usr/lib for the dev-package. See also /usr/share/debhelper/dh_make/debianl/*.install. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: n00b lib packaging question
Am Dienstag, den 29.08.2006, 15:54 -0400 schrieb Jean-Sebastien Pilon: [..] > > What's inside libpcap-ring1.install and libpcap-ring-dev.install? You > > need to "copy" the files from debian/tmp to debian/$package > > > # cat debian/libpcap-ring1.install > usr/local/lib/lib*.so.* > > # cat debian/libpcap-ring-dev.install > usr/local/include/* > usr/local/lib/lib*.a > usr/local/lib/lib*.so > usr/local/lib/pkgconfig/* > usr/local/lib/*.la > > Should I normally expect dh_install to put the files at the right place? I guess, you need to add '--sourcedir=debian/tmp' to your dh_install call in debian/rules. Refer to dh_install's manpage. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Huge private Debian repository...
Am Donnerstag, den 31.08.2006, 13:02 +0200 schrieb Antonio Ospite: > On Thu, 31 Aug 2006 12:24:08 +0200 > "Andreas Fester" <[EMAIL PROTECTED]> wrote: > > > Antonio Ospite wrote: > > [...] > > > debpool is also a handy alternative for a private repository: > > > > > > http://packages.debian.org/experimental/devel/debpool > > > > > > with some improvement debpool can be _the_ debian repository > > > manager for mortals :) > > > > I made some improvements to debpool (not forwarded to "upstream" yet), > > see http://littletux.homelinux.org/debian/pool/main/d/debpool/ > > > > Among them are FAM support for a more responsive incoming queue > > and support for multi arch repositories (especially handy for > > i386/amd64). > > > > Things on my todolist are alignment with 0.2.3, optional GAMIN-support > > instead of FAM and discussing my modifications with the original > > author ;-) > > > > Well, since debpool wants to keep dependencies at minimum I do not know > if upstream author will accept your FAM support, let's try. > > As for multi arch repository I think it is a really good thing. > > Other features I miss from debpool are: > - minimal pool tree (patch in BTS) > - use of gpg-agent instead of keeping passphrase on fs (patch in BTS) > - a command to delete packages from the repository >(e.g.: debpool -d package_name) > > With those little changes it will be perfect for me :) Short question: Do you know, that debarchiver and debpool developers and users had a private discussion round initiated by Andreas Paculat about the missing features and differences between both programs, which would perfectly round out each other? If you were not part (which seems, when I look at the thread), do you want a copy (I can send you the thread)? I would really love to see a product, which includes the advantages of both applications. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Huge private Debian repository...
Am Freitag, den 01.09.2006, 10:27 +0200 schrieb Antonio Ospite: > On Thu, 31 Aug 2006 14:30:46 +0200 > Daniel Leidert <[EMAIL PROTECTED]> wrote: > > > > > [...] > > > > > > With those little changes it will be perfect for me :) > > > > Short question: Do you know, that debarchiver and debpool developers > > and users had a private discussion round initiated by Andreas Paculat > > about the missing features and differences between both programs, > > which would perfectly round out each other? If you were not part > > (which seems, when I look at the thread), do you want a copy (I can > > send you the thread)? I would really love to see a product, which > > includes the advantages of both applications. > > > > Regards, Daniel > > > > Yes please, if you can, make us aware of the discussion. Done. > If it can be found on the web it will be of interest for others, too. AFAIK it cannot be found on the web. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Huge private Debian repository...
Am Montag, den 04.09.2006, 19:13 +0200 schrieb Antonio Ospite: [..] > To put package descriptions on my site [1] I use a combination of > dctrl2xml [2] and a xslt stylesheet to produce the html code, very > little scripting needed. If you want more details you can ask. > > dctrl2xml can produce a useful xml file starting from the a Packages > file in your repository. > > [1] http://www.studenti.unina.it/~ospite/section/it/dev/debian.html > [2] http://frank.thomas-alfeld.de/download/debian/dctrl2xml/ There is also the parse-apt-files.inc PHP script [1][2]. I e.g. use if for my private repository [3]. [1] http://alioth.debian.org/projects/php-apt-parser [2] http://svn.debian.org/wsvn/php-apt-parser [3] http://debian.wgdd.de/debian/ Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
binNMU safe and ${binary:Version} or ${source:Version}
Hello,
I currently try to understand, what I need to do to make my packages
binNMU-safe (I package several libraries). For a package I want to put
into Debian soon, I'm now trying to make it binNMU-safe. But what's
behind this? I tried to find documentation that explains the phrase (I
understand, wthat an binNMU is, but not, what binNMU exactly means for a
package). But I didn't find anything. I e.g. saw the bug-report against
xchat. But I don't understand, when I should use ${binary:Version}
(gnome-vfs2) or ${source:Version} (suggested in the bug-report). So
where can I find documentation about this?
Regards, Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMU safe and ${binary:Version} or ${source:Version}
Am Dienstag, den 12.09.2006, 15:56 +0200 schrieb Daniel Leidert:
> Hello,
>
> I currently try to understand, what I need to do to make my packages
> binNMU-safe (I package several libraries). For a package I want to put
> into Debian soon, I'm now trying to make it binNMU-safe. But what's
> behind this? I tried to find documentation that explains the phrase (I
> understand, wthat an binNMU is, but not, what binNMU exactly means for a
> package). But I didn't find anything. I e.g. saw the bug-report against
> xchat. But I don't understand, when I should use ${binary:Version}
> (gnome-vfs2) or ${source:Version} (suggested in the bug-report). So
> where can I find documentation about this?
Hmm. I think, I now understand it a bit better (I read the
EvolutionPackagingNotes in the Debian Wiki). But Im still wondering,
where I can find the documentation.
Regards, Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building a program with the library shipped in Debian, not in orig.tar.gz
Am Freitag, den 15.09.2006, 09:46 +0900 schrieb Charles Plessy: > I am preparing Debian packages for EMBOSS (the European Molecular > Biology Software Suite, www.emboss.org), and I run in the following > problem: > > EMBOSS is shipped and built with its own copy of libpcre. As a result, > the EMBOSS Debian package contains some files wich are also in the > libpcre Debian package, and they conflict together. > > I would like to try to build EMBOSS with the libpcre from Debian, but I > could not figure out how to do. Can somebody give me hints? > > EMBOSS uses the auto(make|conf) system - I do not understand the > difference yet. I guess, it will be more problematic to begin to change the Makefile.am/.in or configure.ac/.in files in the Debian package, than just making the custom changes to use Debian pcre-package. If EMBOSS compiles with a common libpcre-version, upstream should add the necessary checks for an libpcre installation and prefer this version, instead of the shipped pcre-version. But for you, this will be overkill I guess (you know, where the libpcre-header files are installed, so you don't need such checks). > The files for libpcre such as pcre.h are in the same > directory as the files for a core EMBOSS library. I need to tell the > program to use /usr/include/pcre.h and so on, but I have no clue on how > to do this (I never programmed in C). In short: Change #include "pcre.h" to #include and see 'man pcre-config' for the compilation arguments (you only need, what --libs tells you in the linking step, IIRC). > Is there a documentation for solving that kind of problem? I beleive it > should be recurrent in Debian... HTH and regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMU safe and ${binary:Version} or ${source:Version}
Am Dienstag, den 12.09.2006, 15:56 +0200 schrieb Daniel Leidert: [Questions about binNMU and new variables] Thanks to all, who answered. This helped a lot to understand better binNMUs and the related packaging requirements. I started a new Wiki site, that currently only contains a link to this thread: http://wiki.debian.org/binNMU. But the site-content will be exteneded later. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weired things creating packages
Am Freitag, den 15.09.2006, 01:19 +0200 schrieb Michelle Konzack: [..] > Architecture: all [..] > After building I get this: > > 8<-- > -rw-r--r-- 1 73132 2006-09-12 15:38 > xmms-skin-debian-4.0-etch_0.1.0-1_all.deb > -rw-r--r-- 1837 2006-09-12 15:38 > xmms-skin-debian-4.0-etch_0.1.0-1.diff.gz > -rw-r--r-- 1626 2006-09-12 15:38 xmms-skin-debian-4.0-etch_0.1.0-1.dsc > -rw-r--r-- 1 1168 2006-09-12 15:38 > xmms-skin-debian-4.0-etch_0.1.0-1_i386.changes > -rw-r--r-- 1536 2006-09-14 18:54 > xmms-skin-debian-4.0-etch_0.1.0-1_i386.upload > -rw-r--r-- 1 2680 2006-09-15 00:52 > xmms-skin-debian-4.0-etch_0.1.0-2_all.buildlog > -rw-r--r-- 1 73200 2006-09-15 00:52 > xmms-skin-debian-4.0-etch_0.1.0-2_all.deb > -rw-r--r-- 1887 2006-09-15 00:52 > xmms-skin-debian-4.0-etch_0.1.0-2.diff.gz > -rw-r--r-- 1648 2006-09-15 00:52 xmms-skin-debian-4.0-etch_0.1.0-2.dsc > -rw-r--r-- 1 1058 2006-09-15 00:52 > xmms-skin-debian-4.0-etch_0.1.0-2_i386.changes > -rw-r--r-- 1 432513 2006-09-12 15:38 > xmms-skin-debian-4.0-etch_0.1.0.orig.tar.gz > 8<-- > > Aha, xmms-skin-debian-4.0-etch_0.1.0-1_all.deb is there but > WHY does dpkg-buildpackage create a *_i386.changes ? Because it creates a file $arch.changes, where $arch is the architecture of the system, the package was build on. AFAIK never a file all.changes is created. Where is the problem? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS to fix RC bug: rssreader.app
Am Mittwoch, den 20.09.2006, 22:41 +0300 schrieb Yavor Doganov:
> James Westby wrote:
[..]
> > * Please switch to ${binary:Version} in debian/control.
>
> Done.
Don't forget to also add the build-dependency 'dpkg-dev (>= 1.13.19)'
then. See the thread
http://lists.debian.org/debian-mentors/2006/09/msg00223.html.
Regards, Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to request binNMUs?
Hello, I would like to know, how a binNMU can be requested? I ran into http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=375868 and found, that e.g. libgoffice-0-dev, libgoffice-0-3, libgoffice-1-2, gthumb contain .la-files, that contain references to libgnomeprint-2-2.la. IMHO a binNMU should fix this issue, but I don't know, how I shall request them. I can of course file bug-reports against these packages (which I will do, if the issue is not solved via binNMU). Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to request binNMUs?
Am Sonntag, den 24.09.2006, 23:30 +0200 schrieb Daniel Baumann: > Daniel Leidert wrote: > > I would like to know, how a binNMU can be requested? > > by asking on -release. Thanks. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: knetstats
Am Dienstag, den 14.11.2006, 16:28 +0530 schrieb Ritesh Raj Sarraf: > Dear mentors, > > I am looking for a sponsor for my package "knetstats". Just one more minor issue. There is a formatting bug in the manpge. The whole phrase "knetstats is a network activity status program that sits in KDE's" is bold, because you missed a newline after .B knetstats or you should try \fBknetstats\fR instead. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple upstream changelog files
Am Dienstag, den 30.01.2007, 01:54 +0100 schrieb Magnus Holmgren: > I better ask this once and for all... > > I maintain a package where the upstream author has two changelog files: A > brief one called Changes, summarizing the changes, and a detailed one called > ChangeLog, which contains a detailed list of changes made to the various > source files. Which one should be installed as "changelog"? > > I'd guess the brief one, since it's the one users are most likely to want to > read first, but on the other hand it looks a bit confusing with both a > changelog(.gz) and a ChangeLog. I agree to this. I normally prefer to install the NEWS file (release changelog) instead of the ChangeLog file (file changelog). It's shorter and easier to understand. File changelogs are often very detailed and important information is hard to find. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple upstream changelog files
Am Dienstag, den 30.01.2007, 00:35 -0500 schrieb Justin Pryzby: > On Tue, Jan 30, 2007 at 02:44:00AM +0100, Daniel Leidert wrote: > > Am Dienstag, den 30.01.2007, 01:54 +0100 schrieb Magnus Holmgren: > > > I better ask this once and for all... > > > > > > I maintain a package where the upstream author has two changelog files: A > > > brief one called Changes, summarizing the changes, and a detailed one > > > called > > > ChangeLog, which contains a detailed list of changes made to the various > > > source files. Which one should be installed as "changelog"? > > > > > > I'd guess the brief one, since it's the one users are most likely to want > > > to > > > read first, but on the other hand it looks a bit confusing with both a > > > changelog(.gz) and a ChangeLog. > > > > I agree to this. I normally prefer to install the NEWS file (release > > changelog) instead of the ChangeLog file (file changelog). It's shorter > > and easier to understand. File changelogs are often very detailed and > > important information is hard to find. > I would prefer to have both available to me, with the detailed changelog as > changelog.gz and the summary as NEWS.gz. dh_installchangelogs handles this > with ./debian/package.NEWS. Dumb question: How this? debian/package.NEWS is (from man-page reading) just a different form for debian/NEWS and this file is installed as /usr/share/doc/package/NEWS.Debian.gz, which is not intended to contain the upstream NEWS file. Am I wrong? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building docbook manpages (Re: RFS: crotch)
Am Donnerstag, den 01.02.2007, 09:12 +0900 schrieb Charles Plessy: > Le Wed, Jan 31, 2007 at 11:00:48PM +, Paul Cager a écrit : > > > > I thought docbook2man (or docbook-to-man) would be the best way to do > > it, but it can't handle the XML produced by doclifter (it only really > > works for SGML). xmlto works, though: > >xmlto man thing.1.xml > > xsltproc does also the job... I frequently have that kind of things in > my debian/rules... > > xsltproc -o debian/ -''-nonet > /usr/share/xml/docbook/stylesheet/nwalsh/manpages/docbook.xsl > debian/themanpage.1.xml This command will lead to problems with special characters. Have a look at /usr/share/doc/docbook-xsl/examples/foo.1.example_manpage.xml.gz. for an up-to-data example and the recommended command. The latest release (1.72.0, currently preparing the package) also adds support for dh_installman features (see the upcoming documentation of man.output.lang.in.name.enabled or bug #310895). > Actually, maybe this is just what xmlto does. Using xmlto would > therefore protect me from changes in the layout of the directories > containing xsl pages. Which changes? Could you explain or give an example? > I think I will switch to xmlto. > > Any opinion on this ? AFAIK xmlto simply uses the docbook-xsl stylesheets (but it uses the already removed the passivetex extension to create PDF, which is not a good idea). Not sure, if you can overhand parameters to xmlto via command line (maybe with the [-m xsl_fragment] option?). Regards, Daniel
Re: Building docbook manpages
Am Samstag, den 03.02.2007, 17:04 +0900 schrieb Charles Plessy: > Le Thu, Feb 01, 2007 at 01:57:21AM +0100, Daniel Leidert a écrit : > > > > > > xsltproc -o debian/ -''-nonet > > > /usr/share/xml/docbook/stylesheet/nwalsh/manpages/docbook.xsl > > > debian/themanpage.1.xml > > > > This command will lead to problems with special characters. Have a look > > at /usr/share/doc/docbook-xsl/examples/foo.1.example_manpage.xml.gz. for > > an up-to-data example and the recommended command. The latest release > > (1.72.0, currently preparing the package) also adds support for > > dh_installman features (see the upcoming documentation of > > man.output.lang.in.name.enabled or bug #310895). > > > > I think I will switch to xmlto. > > > > AFAIK xmlto simply uses the docbook-xsl stylesheets (but it uses the > > already removed the passivetex extension to create PDF, which is not a > > good idea). Not sure, if you can overhand parameters to xmlto via > > command line (maybe with the [-m xsl_fragment] option?). > > Thank you very much for the example manpage. I was wondering wether > xmlto would be a nice way to factorise some code across debian/rules and > debian/control files, but if I understand correctly, calling xsltproc > directly is better because it is needed to set parameters. It depends. I could imagine (but didn't test it), that the [-m xsl_fragment] option can do this. The alternative is to write you own small xsl stylesheet to set parameters. But if I understand your intentions correctly, this is what you want to avoid. > By the way, > where are these parameters documented, The parameters are described in the documentation provided with docbook-xsl-doc (and upcoming docbook-xsl-doc-(html|pdf|text)). Just start a browser and view file:///usr/share/doc/docbook-xsl/doc/index.html -> "Manpages Parameter Reference". > and where can I get the relevant > informations for "those who care about xml manpages"? IMO there is only some general information in http://www.docbook.org/tdg/en/html/docbook.html and probably in http://www.sagehill.net/docbookxsl. The rest is learning by doing :) Regards, Daniel
RFS: docbook-xsl 1.72.0.dfsg.1-1 and docbook2x 0.8.7-1
Hi, My regular sponsor seems to be in vacation, so I ask for someone else, who uploads the following packages to Debian (experimental): docbook-xsl 1.72.0.dfsg.1-1 http://debian.wgdd.de/debian/incoming/packages/docbook-xsl_1.72.0.dfsg.1-1_i386.changes docbook2x 0.8.7-1 http://debian.wgdd.de/debian/incoming/packages/docbook2x_0.8.7-1_i386.changes This package needs some more love, but I will do this for the next release. BCC to Rafael Laboissiere, the original maintainer of docbook2x. Both packages can be built using cvs-buildpackage and the debian-xml-sgml Alioth CVS repository too. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: docbook-xsl 1.72.0.dfsg.1-1 and docbook2x 0.8.7-1
Am Dienstag, den 27.02.2007, 23:27 +0900 schrieb Charles Plessy: > Le Tue, Feb 27, 2007 at 02:01:52PM +0100, Daniel Leidert a écrit : > > Hi, > > > > My regular sponsor seems to be in vacation, so I ask for someone else, > > who uploads the following packages to Debian (experimental): > > > > docbook-xsl 1.72.0.dfsg.1-1 > > http://debian.wgdd.de/debian/incoming/packages/docbook-xsl_1.72.0.dfsg.1-1_i386.changes > > Hi Daniel, > > One of the many things which distinguishes Debian compared to other > projects is that we write manpages when the upstream package does not > contain some. > > I never was brave enough to monitor the dockbook-xsl package to see if > there are important changes relevant to the manpages I wrote in > dockbook. > > Do you think that you could write a "For those who care about manpages" > mail from time to time ? There is an example in /usr/share/doc/docbook-xsl/examples/ based on the large example of the Man-page howto and extended to show some more features, docbook and docbook-xsl provide. I normally update this example if there are really interesting changes (I normally follow upstream changes). ATM these changes are only mentioned in the Debian changelog (Bug #310895 and #386580 are fixed). I will update the example for the next package version (for the moment it will wait in NEW, because I split the documentation). Where would you expect a mail-version? BTW: There are also open bug-reports for dh-make to update the manpage template for dh-make (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=383495). If you want to see some large examples, you can check aptitude or my own fglrx man-pages (there I make heavy use of the possibilities, docbook and docbook-xsl provide). IMO I included almost everything I used in these man-pages also in the example. But as I said: If the example misses something or if you want to see something special there, just drop me a hint. Regards, Daniel
Re: RFS: docbook-xsl 1.72.0.dfsg.1-1 and docbook2x 0.8.7-1
Am Sonntag, den 04.03.2007, 10:25 +1100 schrieb Aníbal Monsalve Salazar: > On Tue, Feb 27, 2007 at 02:01:52PM +0100, Daniel Leidert wrote: > >docbook-xsl 1.72.0.dfsg.1-1 > >http://debian.wgdd.de/debian/incoming/packages/docbook-xsl_1.72.0.dfsg.1-1_i386.changes > > Uploaded. Thanks. > Next time, please document how you create the .orig.tar.gz or > include that information in the RFS message. ;) I will add a note with the next upload. Regards, Daniel
Where to mention, when several tarballs are merged into one .orig.tar.gz
Hello, For docbook-xsl I merge two tarballs together docbook-xsl-x.y.z.tar.gz and docbook-xsl-doc-x.y.z.tar.gz. Where should I mention this? debian/README.Debian or better debian/copyright? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to mention, when several tarballs are merged into one .orig.tar.gz
Am Sonntag, den 04.03.2007, 01:32 + schrieb Paul Cager: > Daniel Leidert wrote: > > Hello, > > > > For docbook-xsl I merge two tarballs together docbook-xsl-x.y.z.tar.gz > > and docbook-xsl-doc-x.y.z.tar.gz. Where should I mention this? > > debian/README.Debian or better debian/copyright? > > > > Regards, Daniel > > Definitely README.Debian; probably a good idea in "copyright", where you > mention the download location. > > Have you considered adding a "get-orig-source" target to rules? Yes. I now heard about it several times. I should really give it a try. Do I understand it correctly, that it is only invoked, if run fakeroot debian/rules get-orig-source Or is it also invoked in a different case (if e.g. the .orig.tar.gz is missing)? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: docbook-xsl 1.72.0.dfsg.1-1 and docbook2x 0.8.7-1
Am Dienstag, den 27.02.2007, 23:27 +0900 schrieb Charles Plessy: > Le Tue, Feb 27, 2007 at 02:01:52PM +0100, Daniel Leidert a écrit : > > Hi, > > > > My regular sponsor seems to be in vacation, so I ask for someone else, > > who uploads the following packages to Debian (experimental): > > > > docbook-xsl 1.72.0.dfsg.1-1 > > http://debian.wgdd.de/debian/incoming/packages/docbook-xsl_1.72.0.dfsg.1-1_i386.changes > > Hi Daniel, > > One of the many things which distinguishes Debian compared to other > projects is that we write manpages when the upstream package does not > contain some. > > I never was brave enough to monitor the dockbook-xsl package to see if > there are important changes relevant to the manpages I wrote in > dockbook. > > Do you think that you could write a "For those who care about manpages" > mail from time to time ? I'm currently writing a make-snippet to be included into debian/rules (similar to dpatch.make) to allow easier processing and inclusion of manpage XML sources into Debian packages. If you are interested in the results, contact me (it is not yet in the Debian XML/SGML group's CVS repository). I'm open for any suggestions (e.g. how to enable support for both, DocBook XML and SGML - manpage.xml, manpage.sgml, foo.1.xml, foo.1..xml and similar). ATM the snippet support DocBook XML and xmlto and xsltproc (docbook2x-man will be supported soon, after having a feature like the one enabled with man.output.lang.in.name.enabled). Regards, Daniel
How to put a license (question) in preinst/debconf
Hi, I have a package for a software, that is provided under an academic license - free for non-profit organisations and academic use, not free for profit organisations. So I want to put a debconf template into preinst, so the user MUST accept the license, before he installs the package (and of course: to install the package). What is the better alternative: (a) putting the whole license into the debconf template, so the user can read the whole license OR (b) just leave a pointer where to find the license and only ask, if the user accepts the license (AFAIK flashplugin-nonfree uses this way). What would you choose and why? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: From local source tree to Debian package
Am Dienstag, den 20.03.2007, 11:32 +1100 schrieb Ben Finney: [..] > Writing a bunch of 'cp' or 'install' commands in the 'debian/rules' > file seems like drudgery and is certainly prone to error. What tools > are there to assist Debian packagers in making this task more > automated? dh_install, dh_movefiles Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: From local source tree to Debian package
Am Dienstag, den 20.03.2007, 10:00 +0900 schrieb Charles Plessy: [..] > I am sometimes wondering what is the best approach for packages with no > makefiles : > > a) dh_install, IMHO the perfect tool for this approach. > b) Write a Makefile, submit it to Upstream, and ship it in the debian >directory in the meantime. (as a patch ? as a file to be moved in at >the begining of the install rule in debian/rules ?). You don't need to move it. You can use the -f switch of make and put it, wherever you want :) > The advantage of b) is that it then contributes to trivialise the > packaging rules, especially if it is incorporated upstream. But upstream probably wrote his package for more than Debian. And a Makefile, that shall cover many Linux/Unix distributions + MacOSX is often more complicated, than a simple Makefile you write just for Debian packaging. That's the problem I see with putting such Makefiles into upstream, especially if the upstream author doesn't have much experiences with Makefiles. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: manpage tools
Am Mittwoch, den 28.03.2007, 17:01 +0200 schrieb Magnus Holmgren: > What tools do you prefer for writing manpages (e.g. for commands that lack > one > from upstream)? DocBook XML/XSL > A DocBook XML file is modern, maintainable, can be converted to other formats > as well, and is suggested by dh-make. But I don't quite like the output of > the docbook-xsl template: for example, the spaces on either side of the > vertical bar between s in s can't readily be omitted. Moreover, > you have to write a *lot* of tags due to, IMHO, unnecessary limitations as to > which elements can be contained in which, and the autogenerated Authors > section clashes with the common "This manual page was written ... for the > Debian ..." Authors section. There is already a bug-report open about this issue, asking for an updated template. The docbook-xsl package contains an example for a manpage: /usr/share/doc/docbook-xsl/examples/foo.1.example_manpage.xml.gz I'm currently working on better support for making manpages from XML/SGML (and a small Makefile, that can be included in debian/rules is already ready, but not uploaded yet). Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: manpage tools
Am Mittwoch, den 28.03.2007, 17:01 +0200 schrieb Magnus Holmgren: [manpage creation] > So what other alternatives are there, not counting help2man and pod2man? I forgot: gmanedit, manedit Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: manpage tools
Am Donnerstag, den 29.03.2007, 11:00 +0900 schrieb Charles Plessy: [docbook-xml/xsl for writing manpages] > - The copyright statements are grouped together, so it its not obvious > which one is for the manpage and which one is for the software. I opened a feature request. I think about something like ... ... ... ... and then process them after each other. Feel free to comment on this at http://sourceforge.net/tracker/index.php?func=detail&aid=1690539&group_id=21935&atid=373750. BTW: There is AFAIK no recommendation to include any copyright/legal notice information in the manpage. I also have a feature request open, to only put the copyright and legal notice into the groff source as leading comment, not into the manpage as separate section. > - If there are multiple upstream authors, it may look like that I am > part of their team as there is no clear separator. Where is the problem? You can use Charles Plessy whatever Wrote this manpage The comment is a clear separator, that you are not involved in the upstream software. I don't understand, how this should look like you are involved? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: manpage tools
Am Donnerstag, den 29.03.2007, 20:41 +0900 schrieb Charles Plessy: > Le Thu, Mar 29, 2007 at 01:30:02PM +0200, Daniel Leidert a écrit : > > > - If there are multiple upstream authors, it may look like that I am > > > part of their team as there is no clear separator. > > > > Where is the problem? You can use > > > > > > Charles > > Plessy > > whatever > > Wrote this manpage > > > > > > The comment is a clear separator, that you are not involved in the > > upstream software. I don't understand, how this should look like you are > > involved? > > Hi, > > first of all, thanks a lot for the feature request. About the author list: > > > Paul Miller: Wrote the main program > John Jackson : Implemented the foo funcion in Bar.app > Joe Smith : Did the artwork > Charles Plessy : Wrote the manpage > > I just feel a bit shy to risk to suggest that I am the manpage writer > in a group of upstream developpers. I don't think, there is a need to feel "shy" here. The contrib-elements clearly states, what people have done. I also know several manpages, that even list _only_ the manpage author and the manpage license. Even dh-make' manpage.xml.ex does this. There is no comment about the upstream license and/or copyright. Maybe even a See /usr/share/doc/$PACKAGE/copyright for the programs license and copyright. could be enough in the legalnotice element to tell the user, where to find the license and copyright information for the program/library/file itself. > But maybe if I write "Wrote the > manpage for the Debian operating system" it is more obvious that I am > not upstream. That's, what manpage.xml.ex says too (I will check, if the suggested update contains this sentence for contrib too). And probably I should add the above sentence too. > Alternatively, having: > > Upstream authors: > Paul Miller: Wrote the main program > John Jackson : Implemented the foo funcion in Bar.app > Joe Smith : Did the artwork > > Other contributions : > Charles Plessy : Wrote the manpage > > Would be even clearer. But maybe a bit heavy ? This should be discussed on the docbook-apps list. But to be honest, I don't see a strong need to add sub-titles to the AUTHOR(S) section. The next one then wants sub-titles for contributors (general), documenters, graphic artists, IMHO the element gives everything you need to state, what one has done. IIRC Michael Smith said a few words about the AUTHOR(S) section (design), when the update to this section was done (IIRC updated with 1.70.0 release). Regards, Daniel
Re: manpage tools
Am Donnerstag, den 29.03.2007, 20:41 +0900 schrieb Charles Plessy: > Le Thu, Mar 29, 2007 at 01:30:02PM +0200, Daniel Leidert a écrit : > > > - If there are multiple upstream authors, it may look like that I am > > > part of their team as there is no clear separator. > > > > Where is the problem? You can use > > > > > > Charles > > Plessy > > whatever > > Wrote this manpage > > > > > > The comment is a clear separator, that you are not involved in the > > upstream software. I don't understand, how this should look like you are > > involved? > > Hi, > > first of all, thanks a lot for the feature request. About the author list: > > > Paul Miller: Wrote the main program > John Jackson : Implemented the foo funcion in Bar.app > Joe Smith : Did the artwork > Charles Plessy : Wrote the manpage > > I just feel a bit shy to risk to suggest that I am the manpage writer > in a group of upstream developpers. I don't think, there is a need to feel "shy" here. The contrib-elements clearly states, what people have done. I also know several manpages, that even list _only_ the manpage author and the manpage license. Even dh-make' manpage.xml.ex does this. There is no comment about the upstream license and/or copyright. Maybe even a See /usr/share/doc/$PACKAGE/copyright for the programs license and copyright. could be enough in the legalnotice element to tell the user, where to find the license and copyright information for the program/library/file itself. > But maybe if I write "Wrote the > manpage for the Debian operating system" it is more obvious that I am > not upstream. That's, what manpage.xml.ex says too (I will check, if the suggested update contains this sentence for contrib too). And probably I should add the above sentence too. > Alternatively, having: > > Upstream authors: > Paul Miller: Wrote the main program > John Jackson : Implemented the foo funcion in Bar.app > Joe Smith : Did the artwork > > Other contributions : > Charles Plessy : Wrote the manpage > > Would be even clearer. But maybe a bit heavy ? This should be discussed on the docbook-apps list. But to be honest, I don't see a strong need to add sub-titles to the AUTHOR(S) section. The next one then wants sub-titles for contributors (general), documenters, graphic artists, IMHO the element gives everything you need to state, what one has done. IIRC Michael Smith said a few words about the AUTHOR(S) section (design), when the update to this section was done (IIRC updated with 1.70.0 release). Regards, Daniel
Re: Encoding a manpage in unicode ?
Am Samstag, den 31.03.2007, 12:35 +0900 schrieb Charles Plessy: > I wanted to encode some of the manpages I wrote in Unicode, > but although xsltproc converts them fine, nroff is not able to pipe > something correct to less, and french accents or chinese characters > are not correctly displayed. Is there something to do, or is nroff > simply not unicode compliant? >From what I read (and know), you are converting a DocBook refentry into groff. Read file:///usr/share/doc/docbook-xsl-doc-html/doc/manpages/man.charmap.use.subset.html and use `--param man.charmap.use.subset 0' with xsltproc. This will replace _all_ unicode characters with their groff code and probably solve your problem. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
.changes file over several package releases
Hello, Some time ago (just a few weeks) I saw a .changes file, that contained entries for several package releases: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=373770;msg=21 Which "trick" is used to create such package releases, so the .changes file contains the entries for several releases? Thanks and regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: .changes file over several package releases
Am Samstag, den 21.04.2007, 22:42 +0300 schrieb Kari Pahula: > On Sat, Apr 21, 2007 at 09:36:56PM +0200, Daniel Leidert wrote: > > Some time ago (just a few weeks) I saw a .changes file, that contained > > entries for several package releases: > > dpkg-buildpackage -v$VERSION Thanks. I thought, it might be something like this, but didn't find it directly. Just grepping without a good keyword isn't really useful. Thanks to all who answered. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing an obsolete symlink
Am Dienstag, den 24.04.2007, 11:38 +0200 schrieb Thijs Kinkhorst: > I could use some advice on how to handle the following situation. > > I adopted a web application package that used to set a symlink under > /var/www: /var/www/phpmyadmin -> /usr/share/phpmyadmin. This was not good: > we shouldn't touch /var/www and not enable phpmyadmin without asking. Why? What is so bad with this symlink? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the right place for pkgconfig files ?
Am Montag, den 14.05.2007, 17:11 +0200 schrieb picca: > On my debian testing system I have .pc files in /usr/lib/pkgconfig/ > and /usr/share/pkgconfig/ > > Which one is the right one ? /usr/lib for pkg-config files of arch-dependent packages /usr/share for files of arch-independent packages (these files shouldn't contain a libdir value, instead you can add a datadir value) Both are recognized by pkg-config (see PKG_CONFIG_PATH explanation in pkg-config(1)). Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the right place for pkgconfig files ?
Damn. Please forget the other mail (hit the wrong key). I found some
reference from 2003.
Am Montag, den 14.05.2007, 20:20 +0200 schrieb Daniel Leidert:
> Am Montag, den 14.05.2007, 16:54 +0100 schrieb Neil Williams:
[${datadir}/pkgconfig]
> > Is this documented explicitly somewhere
>
> AFAIK no. It was discussed somewhere in the past:
http://lists.freedesktop.org/archives/xdg/2003-September/000799.html
And there are other mails discussing this.
Regards, Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the right place for pkgconfig files ?
Am Montag, den 14.05.2007, 16:54 +0100 schrieb Neil Williams: > On Mon, 14 May 2007 17:29:00 +0200 > Daniel Leidert <[EMAIL PROTECTED]> wrote: > > > /usr/lib for pkg-config files of arch-dependent packages > > /usr/share for files of arch-independent packages (these files shouldn't > > contain a libdir value, instead you can add a datadir value) > > I didn't know that - it makes sense, just I haven't seen it before, > hence my other email. > > Is this documented explicitly somewhere AFAIK no. It was discussed somewhere in the past: IIRC the gtk-doc or gnome-icon-theme guys began with this and discussed it somewhere. I read a few mails some time ago, but I do not remember, where. I'm sorry. > or is it just an extension > of the rule of /usr/lib/ for architecture-dependent stuff > and /usr/share/ for architecture-independent stuff? IMO it is. But today it's AFAIK seen as a recommendation. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
uscan: Filename pattern missing version delimiters ()
Hi, I wanted to add a watch file for docbook-ebnf. The related files are found at http://www.oasis-open.org/docbook/xml/ebnf/. Unfortunately the whole package only consists of the dbebnf.dtd files in the version sub-directories. So I thought, I could use something like the following for debian/watch: version=3 opts=dversionmangle=s/~([\w]+)$/$1/ \ http://www.oasis-open.org/docbook/xml/ebnf/([\w\.]+)/dbebnf.dtd The dversionmangle should rewrite the epoch version number (e.g.) 1.2~cr1 to 1.2cr1. But uscan complains: uscan warning: Filename pattern missing version delimiters () Any idea how to workaround this? Or do I have to file a wishlist report for uscan to support directory-only lookups? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
