Re: pbuilder create problem
Hi, I had the same problem. I followed the instructions at http://groups.google.de/group/linux.debian.devel/browse_thread/thread/f353a6a4b73b6a81/ where it sais to create a sarge image and update it to sid with pbuilder create --distribution sarge pbuilder update --distribution sid --override-config which worked well. Best regards, Andreas Kevin Coyner wrote: pbuilder create I've tried this on 3 different sid boxes and still get the same thing each time. libstdc++.so.6 links to /usr/libstdc++.so.6.0.5, so the file is present. [...] I: Configuring console-tools... I: Configuring libtextwrap1... I: Configuring console-common... W: Failure while configuring base packages. This will be attempted 5 times. [...] -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://littletux.homelinux.org ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: autotools during build
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 this is one of the things where you definitely get different answers, depending on whom and where you ask ;-) I agree with Martin that autoconf and automake should not be run from rules, and that upstream should provide a configure script. ./configure; make; make install is what I expect to do as a user of a (original upstream) package, and IMHO the need to run autoconf makes the whole autotools approach questionable; configure *is* the platform independant configure script, so why ever should I need to create it on my specific platform? Best regards, Andreas 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? Thanks, Bas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
An excellent point. I imagine that it would also be permissible to repackage the .orig.tar.gz file so that it is gone from there as well. ? orig.tar.gz should be as it says - the original. not necessarily. It must be the original, but it must not be pristine. One reason could be to remove autotools dependencies, another could be to remove files which would otherwise be removed by the "clean" target and would end up in a huge diff.gz. IMHO this such things should of course be reported to upstream and hopefully be fixed in the next upstream version. Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
Hi,
Thomas Viehmann wrote:
[...]
not necessarily. It must be the original, but it must not be pristine.
One reason could be to remove autotools dependencies, another could be
to remove files which would otherwise be removed by the "clean" target
and would end up in a huge diff.gz.
Sorry, but I have to point out that your recommendation describes the
very opposite of Debian best packaging practices.
I am just not sure how "strong" this practice should be seen. My
personal opinion is that the .orig should be as original as possible
(with the benefit that its really easy to verify if its identical
to the upstream tarball with some MD5 sum), but there are a lot of
opposite opinions.
[...]
- Specifically, if you need to update autotool output, this belongs 100%
in the diff.gz (directly or via dpatch et al).
Especially regarding autotools output, many other maintainers think
different. You end up with a rather huge .diff.gz, and for a lot
of people this is reason enough to repackage the upstream tarball.
[...]
Also note that deletion of files is ignored for diff.gz creation.
Yeah, but you get a huge amount of warnings so if you have to
repackage anyway, you could also remove those files, even though
it might not be good practice to repackage for that reason *only* ...
1. http://sam.zoy.org/lectures/20050910-debian/img17.html
Thanks for the pointer to those cool slides :-)
Best Regards,
Andreas
--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Packaging question (synopsis and its libraries)
Hi,
I am currently adopting synopsis, a source code documentation
tool specially suited for python, but also useable for
C and C++. I created a first package from the new upstream
version which is available at http://www.littletux.net/debian.
The package is not yet lintian clean, and this leads to my question:
The package contains some python extension modules written in
C/C++, which all depend on a common library, libSynopsis, which is
also part of the package. By default, libSynopsis is installed below
/usr/lib, but without correct SONAME. So I decided to install
it below some private library directory, BUT this included adding
the private library search path to the python extension modules'
RPATH, which I learned is a Bad Thing(TM) (lintian also tells
me about that). I also do not want to fiddle with /etc/ld.so.conf,
so I think the following possibilities exist:
1) Leave it as it is, and add a lintian override. This might
be a proper solution, as it seems that rpaths are not regarded
*that* bad if they point to a "non-public" lib directory, which
would be the case here.
2) Add a proper SONAME to the library and install it
below /usr/lib, from the same binary package.
3) Create separate libsynopsis and libsynopsis-dev packages.
This would have the advantage that the library can be used
by other applications as well (which is also the intention
of the upstream developer, at least in the future). Possible
issue could be that the API is not that stable yet which might
result in many SONAME changes.
4) Some great (and simple :-) ) solution which I dont know yet...
Number 3) is currently my preferred solution, IMHO this would end
up with a package layout similar to
- synopsis The main package. Installing this is sufficient to
use synopsis.
- [optionally: synopsis-doc,
containing information on how to use synopsis itself.
Not yet sure about this.]
- libsynopsis The C++ library.
- libsynopsis-dev The development files
- libsynopsis-doc The API documentation
The upstream author argued that these are too many packages, but
IMHO this is the proper solution if the library is packaged
separatly.
Any comments appreciated :-)
Thanks & Best Regards,
Andreas
--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
Joey Hess wrote: Andreas Fester wrote: not necessarily. It must be the original, but it must not be pristine. That's self-contradictory. And wrong. That's what I learned from other developers during my first packaging experience :-), and its difficult to argue if you are a novice I also thought that .orig *is* what it says, but I have the impression that often people tend to repackage for this or that reason which could also easily be fixed in debian/rules (just reading a similar discussion on d-d). Anyway: I still had the previous version of the developers reference, and the new chapter 6.7.8 talks exactly about this topic, which should help clarifying it when there are doubts. Best Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: synopsis -- Source code documentation tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I adopted synopsis (http://synopsis.fresco.org), a source code documentation tool, especially suited for (but not limited to) creating documentation from python code. The package I created from the latest upstream version is available on mentors.debian.net (http://mentors.debian.net/debian/pool/main/s/synopsis). The package is linda and lintian clean, with an override though; hope that someone nevertheless is willing to sponsor me ;-) Thanks and best Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDSrxUZ3bQVzeW+rsRAs7zAKCTxTTP6PI897N5hwrw/ebm5u9WtwCeOA9H EX+7cLQnAjLXLZAtGD7lC6M= =2D2L -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: *** GMX Spamverdacht *** Re: KChmViewer debian package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>I've created my very first debian package of kchmviewer-1.1. I'm total >>newbie in debian packaging system, but I was missing this program so I've >>created package myself. Is anyone interested in this? Is anyone willing to >>help me to bring this package to "uploadable" state? note that there is already an ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312700 Jorge Salamero Sanz wrote: > please put your work somewhere so we can get what you have done :) > > i'll try to help you as much as i can :) Same for me :-) Currently I have this package installed in /usr/local, so having a debian package would be great... Best Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFDZ10rZ3bQVzeW+rsRAtvGAKDKRnWfHX6k11DakJTV5OVfZJAbhgCY+Kgx 0706r6G3wSVSKRsmVGiNtQ== =2rCf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: KChmViewer debian package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > great ... take a look here: http://linny.kte.sjf.stuba.sk/~misko/kchmviewer/ pbuilder says: checking whether i486-linux-gnu-g++ supports -O0... yes checking whether i486-linux-gnu-g++ supports -Wl,--no-undefined... yes checking whether i486-linux-gnu-g++ supports - -Wl,--allow-shlib-undefined... yes checking for X... no configure: error: You need to have the X11 libraries and headers installed make: *** [config.status] Error 1 pbuilder: Failed autobuilding of package -> Aborting with an error Seems that some build-depends are missing ;-) Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDZ2KQZ3bQVzeW+rsRAlhVAKDodL/oa1qDhLFJBkKuvz94UF6ONwCePrEG FdPf8fWqR3zsS5E3HjduiAY= =7KpW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: default man page
Adriaan Peeters wrote:
> Hello,
>
> I am packaging sysinfo [1,2]: a simple Gtk program which can display
> some computer/system information. Upstream does not provide a man page,
> but the program has no useful command line parameters, except the
> default gtk options. Does there exist a default man page for these
> cases, should I create an almost empty man page or can I just leave it
> out?
See section 12.1 of the debian policy, especially the footnote
which refers to http://www.schweikhardt.net/man_page_howto.html
IMHO, you should at least describe the purpose of the program
in the man page, to enable a user to examine what the program
does before executing it.
The simplest approach might be to use a man page from an
existing Debian package as a template, and simply replace
the various sections with your text.
Regards,
Andreas
--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: qcad -- A professional CAD System
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am looking for a sponsor for the QCad Community Edition: * Package name: qcad Version : 2.0.5-1 Upstream Authors: Andreas Mustun * URL : http://www.ribbonsoft.com/qcad.html * License : GNU/GPL Section : graphics The package is already in Debian. I have packaged the new upstream version and fixed some of the open bugs. The package is available at http://www.littletux.net/debian/pool/main/q/qcad/ Thanks & Best Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEr6ywZ3bQVzeW+rsRAvpoAKCW09w2jckTxiXzisPJdIbV9c3FqACg9oLj iTI8xTPJsW/tTC6hgeKRdCU= =24Sn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: qcad -- A professional CAD System
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Baumann wrote:
> Andreas Fester wrote:
>> The package is available at
>> http://www.littletux.net/debian/pool/main/q/qcad/
>
> the upstream-tarball is missing.
*Now* its there. debpool could not handle the upstream
version number (with the dash) correctly and deleted
the .orig file after upload :-/
Regards,
Andreas
- --
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEr+iQZ3bQVzeW+rsRAoiMAJ92chgHa6KTBgKQHvsH9VbsXfaZ7QCgtqBk
iRVg4zpTHS8itctq+ZdJx9k=
=ejYn
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: subcommander -- qt based multiplatform subversion client, diff & merge tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am looking for a sponsor for subcommander, a graphical client for subversion: * Package name: subcommander * Description : Subcommander supports most subversion features. Its tight integration of repository browser and working copy status view allows to switch quickly between a working copy view and the repository view. Subcommander also contains submerge, a visual diff and merge tool for text files. * Version : 1.1.0 * Upstream Authors: Martin Hauner * URL : http://subcommander.tigris.org * License : GNU/GPL * Section : devel The preliminary package is available at http://www.littletux.net/debian/pool/main/s/subcommander/ it is linda&lintian clean and installs properly. Thanks in advance & Best Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEw+DlZ3bQVzeW+rsRAikyAJ92YYxFvb18eEWXp9oyMN5/eSIGPACgv5SM Bdqhodsi9cUs3/+WffEOR1Y= =jJRD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS (dget optimized): subcommander -- qt based multiplatform subversion client, diff & merge tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I am looking for a sponsor for subcommander, a graphical client for subversion: * Package name: subcommander * Description : Subcommander supports most subversion features. Its tight integration of repository browser and working copy status view allows to switch quickly between a working copy view and the repository view. Subcommander also contains submerge, a visual diff and merge tool for text files. * Version : 1.1.0 * Upstream Authors: Martin Hauner * URL : http://subcommander.tigris.org * License : GNU/GPL * Section : devel The preliminary package is available at http://littletux.homelinux.org/debian/pool/main/s/subcommander/ dget copy&paste line: dget http://littletux.homelinux.org/debian/pool/main/s/subcommander/subcommander_1.1.0-1.dsc The package is linda&lintian clean and installs properly. Thanks in advance & Best Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExe2dZ3bQVzeW+rsRAg+kAJ9AiujYqV4u/V32Kp6PVli+dmfjGQCfcgoC 7X7fMq1H7aNtwSwN2/t2oPE= =nlPP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS (dget optimized): subcommander -- qt based multiplatform subversion client, diff & merge tool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Bas, Bas Wijnen wrote: [...] > compiler". There is no such thing as "GNU/GPL". Ok; I suppose I simply copy&pasted that from another RFS ... > The copyright file doesn't contain this error, so that's fine. However, it > also doesn't contain the recommended paragraph from the GPL itself (the thing > which should also be at the top of every source file). You mean the three stanzas "... is free software; you can redistribute it ...", "... is distributed in the hope that it will be useful ..." and "You should have received a copy of ..." ? I thought that it is sufficient to include a link to the license when it is one of the common free licenses... > The source files instead point to doc/COPYING, which contains it, so I suppose > that is fine. However, you should have the full contents of it in > debian/copyright as well, because it is installed in the binary package so > users know the copyright without first getting the source. In particular, > there is an exception for linking to Qt, which you don't even mention in > debian/copyright. Such mistakes can easily be avoided by copy+pasting the > contents into debian/copyright. Ok. I will do that. There is another COPYING file, doc/COPYING.CollabNet; since subversion is licensed under this license I think this should not be a problem, other than also adding this file to debian/copyright (even though this license only applies to two files which are needed for the build on a specific other OS ...) Thanks, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFExpxjZ3bQVzeW+rsRAq1VAKCd5CdGHE00vBG5Dp6mZxlx8cZiYACgoC27 ZeLPzVQJybemJwQgqGRh2a8= =Ezh0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: subcommander - Graphical client for subversion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package "subcommander". * Package name: subcommander Version : 1.1.0-1 Upstream Author : Martin Hauner * URL : http://subcommander.tigris.org * License : GPL Section : devel It builds these binary packages: subcommander - Graphical client for subversion subcommander-doc - User guide for subcommander The package is lintian clean. The upload would fix these bugs: 322340 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/s/subcommander - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/s/subcommander/subcommander_1.1.0-1.dsc I modified the debian/copyright file as proposed by Bas Wijnen in a reply to the initial RFS. I would be glad if someone uploaded this package for me. Kind regards Andreas Fester - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEySC6Z3bQVzeW+rsRAlmYAKDlRDt84ys27wQzEfnpQ18IFHrRSACgwr4P Qn5kEdROgXpc93ajYFMcG90= =lY91 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: crossvc (updated package)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, my usual sponsor for the lincvs package seems to be MIA already for some weeks now. Therefore I am looking for a sponsor for the new version 1.5.0-1 of my package "crossvc" which is the new upstream name for the earlier "lincvs" application. It builds these binary packages: crossvc- graphical CVS frontend lincvs - transitional dummy package The package is lintian clean. The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/non-free/c/crossvc - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/non-free/c/crossvc/crossvc_1.5.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards Andreas Fester - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE4in+Z3bQVzeW+rsRAmbrAJ9PoG5QbjEqR51iv/+FoRDAuwI+cACff9va BdV08etG+a0yMQJIeLv8/9I= =5Ifu -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Huge private Debian repository...
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 ;-) Best Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Huge private Debian repository...
Antonio Ospite wrote: [...] >> 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. I know; FAM support is of course optional :-), so unless you explicitly specify the --fam option debpool does not depend on the perl fam package. An appropriate Recommends: or Suggests: is missing though... Best Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Huge private Debian repository...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Leidert wrote: [...] >> 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 Sure, I would be interested in that; I just wanted to clean up some of the stuff I did before contacting the author of debpool, but probably its now a good chance to dig further into it ... Thanks, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9xTnZ3bQVzeW+rsRAh8iAJ9TAlTbEWLVtxLEUrcBalbr/pmU7wCgiYKG oG1iEZv5fwF2vt1QSS49YYg= =zlc2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Huge private Debian repository...
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Michelle,
Michelle Konzack wrote:
> Hello Andreas,
[...]
>> Among them are FAM support for a more responsive incoming queue
>> and support for multi arch repositories (especially handy for i386/amd64).
>
> Genial, but I have to support additionaly powerpc and ia64.
Should not be an issue; simply configure it ;-)
The thing I fixed was that, when there was already a package for one
architecture in the pool, and the same package was uploaded for
a different architecture, some meta data from the already existing
package was overwritten so that only the latter one was visible.
Best Regards,
Andreas
- --
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFE/G8xZ3bQVzeW+rsRApy0AKCMijS/ILVPECBvF8wigilHp/vLOQCgw2ej
X1BOLUxN7Z/KU/pIzT8OHc4=
=wz++
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMU safe and ${binary:Version} or ${source:Version}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Daniel, Daniel Leidert wrote: > 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 [...] I started to document binNMUs in the Debian Wiki when I also tried to understand it some time ago: http://wiki.debian.org/NonMaintainerUpload Maybe there are additional things you can add from what you learned ... Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFCFD3Z3bQVzeW+rsRAvRrAKDi1JQy8JZF+41IDwETcaboVn/+2gCg4QS9 4+oPXgFz65WJMtfJognJ9sM= =hMIf -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help regarding package with shared objects
Hi Paul, you should definitely read http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html It should answer most of your questions, including package layout and the role of -dev packages. Regarding the install location: does your package use autoconf? You then probably simply need to pass a --prefix=/usr parameter to the configure script to install it in the proper places. Otherwise you might need to further examine the build and install mechanism of your package ... Don't know about your general Debian packaging knowhow, but some other "must reads" are: http://www.debian.org/doc/devel-manuals#maint-guide http://www.debian.org/doc/devel-manuals#devref http://www.debian.org/doc/debian-policy/ Regards, Andreas Paul Cager wrote: > If you are able to help me with some problems I am having packaging an > application with some shared objects (.so libraries), I would be very > grateful. I know very little about SOs, and even after a bit of research [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library sonames and unstable libraries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Justin Pryzby wrote:
>> ./libgnomevfs-pthread.so
>> [...]
> No. *.so are linker symlinks used at compiled time. The compile flags -lfoo
Not this one:
$ ls -la /usr/lib/libgnomevfs-pthread.so
- -rw-r--r-- 1 root root 34624 2005-09-02 01:53 /usr/lib/libgnomevfs-pthread.so
So this must be a special case ...
> Too, there are actually two forms of library soname file naming used:
> libfoo.so.1.2.3
> and
> libfoo-1.2.3.so
Only the first one is mentioned in the various packaging guides,
so I suppose that the format libfoo-1.2.3.so only exists for historical
reasons, right? IMHO new packages have to use the form libfoo.so.1.2.3 ?
Best Regards,
Andreas
- --
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFoSuEZ3bQVzeW+rsRAog+AJ9nbSq6VtK9/fRMEW6jPW1JqXMz0ACgvLnM
ChRW1AmUSK7SF4yo9K94s6A=
=pWUx
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Library sonames and unstable libraries
Hi, Junichi Uekawa wrote: >>> Too, there are actually two forms of library soname file naming used: >>> libfoo.so.1.2.3 >>> and >>> libfoo-1.2.3.so >> Only the first one is mentioned in the various packaging guides, > > hmmm ? excluding this? > > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#shldevpackagecontents Right; I should read the documents I refer to more carefully ;) >> so I suppose that the format libfoo-1.2.3.so only exists for historical >> reasons, right? IMHO new packages have to use the form libfoo.so.1.2.3 ? > > That's not quite the case. Yes, Steve already said that; so, if I understand it correctly, none of the two formats is preferred over the other one, i.e. if upstream uses either of them, both would be valid for Debian, right? Thanks, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: makefiles
Another good manual regarding autoconf and automake (that is, makefiles.am and makefiles.in) is http://sources.redhat.com/autobook/ It is also in english though Best Regards, Andreas On 7/7/05, PY LUYTEN <[EMAIL PROTECTED]> wrote: i try to learn a bit as it seems i am not ready to develop any package. I tryed the maintener guide but need more docs about makefiles, makefiles.am and makefiles.in and could not find it - "man" being not enough for me. Did i miss a good doc (especially in french) ? [...] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: makefiles
Hi,
kamaraju kusumanchi wrote:
[...]
>> http://sources.redhat.com/autobook/
[...]
> The above autobook contains information about very old tools. Though the
> concepts might remain same, I have difficulty reading it. Every time I
> try something and if it does not work, I keep wondering whether it is
> due to the new version or whether it is my mistake?
>
> Is there any upto date version of it? If not, then IMHO it is not that
Indeed, there is one really nearby ;-)
$ apt-cache policy autobook
autobook:
Installiert:(keine)
Mögliche Pakete:1.4.3-unofficial-1
Versions-Tabelle:
1.4.3-unofficial-1 0
500 http://ftp.tu-graz.ac.at stable/main Packages
990 http://ftp.de.debian.org testing/main Packages
500 http://ftp.de.debian.org unstable/main Packages
This is the version I used recently to get involved with
autotools, and most of the things worked quite well. The
package contains both HTML and PDF versions.
If you have specific problems with any of the examples in the book,
feel free to ask.
Best Regards,
Andreas
--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://littletux.homelinux.org
ICQ: 326674288
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#303794: ITA: log4cpp -- A C++ library for flexible logging
Hi, Fathi Boudra wrote: > the project restarted, current version is log4cpp-0.3.5rc2 (dated 2005-06-01) > Only the homepage of the project wasn't updated. > So what should i do ? prepare an updated package or drop it ? the primary reason for me to package log4cxx instead of ITA log4cpp was that log4cpp was not actively developed anymore since three years or so, so I also suggested to replace it with log4cxx (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=303892). But, if log4cpp is now really active again, I see no reason why to drop it, instead of having both log4cpp and log4cxx in Debian. Both of them might have pros and cons, so I suggest to simply keep them both :-) Best Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: log4cxx - A logging library for C++
Hi, I am looking for a sponsor for the log4cxx package which I debianized. Log4cxx is the C++ port of log4j, a widely used logging library for Java. See http://logging.apache.org/ for more information. log4cxx attempts to mimic log4j usage as much as the language will allow and to be compatible with log4j configuration and output formats. Since log4j is already in Debian its natural to also include its C++ port. Additionally this could close Bugs #288336 and #288337 in the long term because log4cpp is orphaned and the upstream is not maintained anymore. I found at least one other debian user who also asked to replace log4cpp with log4cxx some time ago (see http://groups.google.de/groups?selm=2K3ou-3X1-11%40gated-at.bofh.it). So we should at least start with adding log4cxx, and maybe deprecate log4cpp. This is my first approach with creating a debian package, and I am absolutely aware of the fact that I violated two basic rules of the NMG, not to create a library and not to create multiple binary packages; I hope that the result is not *that* bad though ;-) A preliminary version of the package can be found at http://littletux.homelinux.org/debian/log4cxx There is only one warning reported from lintian about a missing man page for an included binary. Since the upstream package does not include a man page either I still will have to fix this. Thanks and best Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://littletux.homelinux.org ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: log4cxx - A logging library for C++
Hi Laszlo, thanks for examining the package :-) I fixed the issues you mentioned, and the new preliminary packages are again available at http://littletux.homelinux.org/debian/log4cxx Yes, please write a basic manpage for it at least. Fixed. Some quick notes: - please remove unneeded, commented out lines from debian/rules, Fixed. - in debian/changelog you should close your ITP request, Fixed. - your package was unbuildable: dh_installchangelogs ChangeLog dh_installdocs cp: cannot stat `debian/tmp/usr/share/log4cxx/html': No such file or directory dh_installdocs: command returned error code 256 make: *** [binary-arch] Error 1 debuild: fatal error at line 765: Ups... there was a missing build dependency on doxygen and graphviz. Fixed. - also /usr/share/log4cxx/ should be /usr/share/doc/log4cxx/ as I know. Currently the packages install into the following directories: log4cxx_0.9.7-1_i386.deb: /usr/bin /usr/lib /usr/share/doc/log4cxx /usr/share/man/man1 log4cxx-dev_0.9.7-1_i386.deb: /usr/include/log4cxx /usr/lib /usr/share/doc/log4cxx-dev log4cxx-doc_0.9.7-1_all.deb: /usr/share/doc/log4cxx-doc /usr/share/doc/log4cxx-doc/html The directories /usr/share/doc/ contain the usual README etc, but /usr/share/doc/log4cxx-doc/html contains the log4cxx manual. Here I am not sure if this directory needs to go below /usr/share/doc/log4cxx-doc (as it is now) or below /usr/share/doc/log4cxx... Thanks & best Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://littletux.homelinux.org ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New maintainer checklist
Hi Ben, Ben Finney wrote: Howdy mentors, I'm attempting to start my long slide into package maintainership :-) Welcome :-) I also started this journey some weeks ago, maybe some hints can help you: - In addition to the documents below, reading the New Maintainers Guide: http://www.debian.org/doc/maint-guide/ is a must - You should subscribe to debian-devel; this is where development and packaging issues are discussed - The next step in becoming the maintainer for the package is probably to issue an ITA (Intent to Adopt) request. - You can of course already start with creating the debian package, put it on a public URL and give that URL in your ITA so that others can review it (listening on debian-devel for a while should give you an idea how the process works) - From my own experience: Use a chroot environment like pbuilder to check if all build dependencies are met before you provide your package for review :-) HTH, Andreas - Pick an itch (package) to scratch: lojban-common (bug #302297) - Read the Developer's Reference (still going) - Read the Debian Policy (slowly going) - Read the BTS and PTS documentation - Join debian-mentors What else should I be doing before I embark on getting a package ready? Does an overall checklist like the above already exist, that I should be following? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a library.
Hi, Probably someone to help you, actually. See if you can get a sponsor for the library (have you done an ITP for the library?), see if there is an existing maintainer who might help you. I am working on debian packages for log4cxx for some time, and this is also my first package; learned a lot through it, so if you have any specific questions do not hesitate to contact me. Basically, the descriptions in the New Maintainers Guide should be enough as a starting point, and you should at least read the Debian Library Packaging guide you mentioned because it contains some important information about naming conventions. You could apt-get source some other simple library to see how other libraries are built. You could have a look at my work-in-progress at http://littletux.homelinux.org/debian/log4cxx. And you could browse the CVS repository at http://littletux.homelinux.org/cgi-bin/viewcvs.cgi/ to view the path I was following while working on the package :-) Once you have the package done, provide it somewhere so that others can have a look at it. Best Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://littletux.homelinux.org ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Question about packaging a library.
Hi, The library, I'd like to package is FMOD (fmod.org), and it's a "proprietary" library, it's free to use in a non-commercial software. I had a look into it; since they only seem to provide the library in binary format, this changes some things significantly: The library itself can only go in the non-free section of debian, and since your package depends on it it can only go in the contrib section of debian. Please read Chapter 4.6.1 of the Debian Developers Reference. And i don't think the developers will give me their code to package it. So, i don't really know how to start. For my soft, I ran dh_make which help me a lot. So maybe, I could do all the necessary things manually,is it a good idea according to you ? No, its not; I dont know though how the process is when creating packages for the non-free section. Maybe others can jump in here :-) I download the package you mentioned, and i will have a look in the afternoon, thanks a lot for your help. Regards, Sylvain Ps: What does ITP means ? ITP means "Intent To Package" and is meant to notify others that you will create debian packages for some piece of software. Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://littletux.homelinux.org ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Help request] packaging pyne 1.0.3 - build problem
Hi,
[...]
RuntimeError: could not open display
configure: error: GTK+ version >= (2,0,0) required
make: *** [config.status] Error 1
[...]
My guess is that you are logged in as a normal user and running debuild as
root, am I right? In that case, it appears to be complaining about being
unable to connect to an X server.
But I could be wrong :)
your guess is absolutely right, but its not only a security issue: the
DISPLAY variable is also not set. I could build the package by granting
access to the XServer (xhost) *and* setting the DISPLAY variable to :0.0
in the configure script (export DISPLAY=:0.0).
But, you still need a running X-Server, so this is probably no solution
for the build environment.
The X-Server connecton is needed by the checks for the gtk and the pygtk
version, starting with "import gtk" in configure.in . Maybe you could
rewrite these checks so that they do not need the X-Server connection.
BTW: Your package depends on autoconf and you also call autoconf
when building the package; usually this should not be necessary,
the proper configure script should be provided, i.e. if you need
to rebuild the configure script then add the diff for the script
to your already existing 01_fix_build_issues.dpat.
Best Regards,
Andreas
--
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://littletux.homelinux.org
ICQ: 326674288
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
