Re: How package a binary library with unversioned soname?
Nikolaus Schulz [EMAIL PROTECTED] writes: I am packaging printer drivers from Canon, see [1] for the ITP and some notes about that very peculiar, awkward beast. These drivers are only partly free software, they come with non-free, binary-only libraries. While this is bad enough, unfortunately the libraries have unversioned sonames, and I see zero chance to have upstream (Canon) fix this. So, one cannot produce valid shlibs files for these libraries. But these are required by policy. That is, as Steve Langasek has pointed out in [2], the policy de-facto requires libraries to have versioned sonames. Policy doesn't require valid SONAMEs for private shared libraries specific to a particular application. The SONAME requirement is to allow reasonable handling of library changes and upgrades of packages that built against the libraries, which only applies if the libraries are in a separate package from the programs that use them. If you have a program that contains some binaries linked with private libraries, Policy doesn't really care what those libraries are like provided that they're self-contained within that package and are installed in a subdirectory of /usr/lib. See Policy 10.2, specifically: Shared object files (often .so files) that are not public libraries, that is, they are not meant to be linked to by third party executables (binaries of other packages), should be installed in subdirectories of the /usr/lib directory. Such files are exempt from the rules that govern ordinary shared libraries, except that they must not be installed executable and should be stripped. It sounds like you should try to treat these upstream shared libraries under this exception as private libraries for the binaries built by this package rather than trying to use them as first-class shared libraries. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: daloRADIUS - Advanced RADIUS Web Management Application
Hey guys, On 9/25/07, Kumar Appaiah [EMAIL PROTECTED] wrote: On Tue, Sep 25, 2007 at 10:47:19AM +0200, liran tal wrote: I'm asking because I think that having the orig.tar.gz makes dpkg-source think that it's suppose to copy it over to the daloradius-0.9.3/debian dir but I'm not entirely sure. Actually, the recommended way to copy files from your upstream source location to the debian/package directory would be to use dh_install. Even better than calling dh_install directly from rules would be to use an install file in the debian/ directory which has things of the form upstream file/directory destination I still need help with the source package issue, to resolve this problem of a native package. (As I understand that this is indeed a problem)... I have done what Kumar proposed - I've put an install file - daloradius-0.9.3/debian/install which contains: usr usr/ (the contents of the package to be copied is in daloradius-0.9.3/usr) I have also used the original tarball package and renamed it to daloradius_0.9.3.orig.tar.gz and put it outside the daloradius-0.9.3/ directory, then while running dpkg-buildpakage inside daloradius-0.9.3/ I am receiving the following output: dpkg-buildpackage: source package is daloradius dpkg-buildpackage: source version is 0.9.3 dpkg-buildpackage: source changed by Liran Tal [EMAIL PROTECTED] dpkg-buildpackage: host architecture i386 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp configure-stamp # Add here commands to clean up after the build process. # -/usr/bin/make clean dh_clean dpkg-source -b daloradius-0.9.3 dpkg-source: building daloradius using existing daloradius_0.9.3.orig.tar.gz dpkg-source: building daloradius in daloradius_0.9.3.diff.gz dpkg-source: cannot represent change to usr/share/daloradius/images/daloradius_logo.jpg: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/images/sidebarh2.jpg: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/images/nav.jpg: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/images/daloradius_small.jpg: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/images/sidebarright.jpg: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/images/content.jpg: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/images/innerwrapper.jpg: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/images/body.jpg: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/library/libchart/images/PoweredBy.png: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/library/libchart/fonts/DejaVuSansCondensed-Bold.ttf: binary file contents changed dpkg-source: cannot represent change to usr/share/daloradius/library/libchart/fonts/DejaVuSansCondensed.ttf: binary file contents changed dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/LineChart.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/Point.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/VerticalChart.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/Color.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/Chart.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/Axis.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/Text.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/BarChart.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/libchart/classes/Primitive.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/library/javascript/productive_funcs.js has no final newline (either original or modified version) dpkg-source: cannot represent change to usr/share/daloradius/library/js_date/calendar.gif: binary file contents changed dpkg-source: warning: file usr/share/daloradius/library/googlemaps.php has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/FAQS has no final newline (either original or modified version) dpkg-source: warning: file usr/share/daloradius/menu-mng-rad-groupcheck.phphas no final newline (either original or
Re: RFS: gimmix
Hi, IANADD but anyway some comments: On Sun, Sep 30, 2007 at 12:48:36PM +0200, Vincent Legout wrote: It builds these binary packages: gimmix - Graphical music player It appears to be inappropriate to speak a about a music player as it would be a standalone music player, if in reality gimmix is *just* a frontend to mpd. So I think you should change your description. debian/menu: gimmix is a graphical application so it makes sense to have menu entries. You lack an appropriate menu file, which is (IMHO) essential because update-menus handles other window managers then those supporting the .desktop file properly, while currently those users may have to search for your application. Regards, Patrick signature.asc Description: Digital signature
Same source package, differents targets
Hi, I'm sorry if the question is a bit silly, but I have a conceptual doubt. I would like to package a soft that with the _same_ source, provides different packages but, this packages have different build dependencies and incompatibles. How is this solved? Regards, Leo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Same source package, differents targets
On Mon, Oct 01, 2007 at 04:02:32PM +0200, Leopold Palomo-Avellaneda wrote: Hi, I'm sorry if the question is a bit silly, but I have a conceptual doubt. I would like to package a soft that with the _same_ source, provides different packages but, this packages have different build dependencies and incompatibles. I think you mean that you have multiple binary package, and the build deps for one of them conflict with the build deps of the other. Neat! Can you give specific detail of the package and dependencies? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Same source package, differents targets
A Dilluns 01 Octubre 2007 16:28, Justin Pryzby va escriure: On Mon, Oct 01, 2007 at 04:02:32PM +0200, Leopold Palomo-Avellaneda wrote: Hi, I'm sorry if the question is a bit silly, but I have a conceptual doubt. I would like to package a soft that with the _same_ source, provides different packages but, this packages have different build dependencies and incompatibles. I think you mean that you have multiple binary package, and the build deps for one of them conflict with the build deps of the other. Neat! Can you give specific detail of the package and dependencies? yes. The software is orocos-rtt [1]. Trying to help to the main developer, I have found that the main core lib depends on specific kernel packages: one for use with rtai, one or xenomai, one gnulinux, ...) The same source could create the orocos-rtt lib, but for example if you want to build the rtai version you need the rtai kernel headers version and then the kernel image a is in conflict with the xenomai soft, etc. The gnulinux version is more or less in common with the rest of the packages. I can understand that using the same sources, create several packages, but with the same source, create several incompatible builds I don't understand how (pbuilder in mind) That's all, Leo [1] http://www.orocos.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: sysadmin-guide-es
Dear mentors, I am looking for a sponsor for my package sysadmin-guide-es. * Package name: sysadmin-guide-es Version : 0.8-1 Upstream Author : Rafael Ignacio Zurita [EMAIL PROTECTED] (translator) Lars Wirzenius [EMAIL PROTECTED] Joanna Oja [EMAIL PROTECTED] Stephen Stafford [EMAIL PROTECTED] Alex Weeks [EMAIL PROTECTED] * URL : http://www.ibiblio.org/pub/Linux/docs/LDP/system-admin-guide/translations/es/ * License : GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. Section : doc It builds these binary packages: sysadmin-guide-es - Spanish translation of The Linux System Administrators' Guide The package appears to be lintian/linda/pbuilder clean. The upload would fix these bugs: 17 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/sysadmin-guide-es - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/sysadmin-guide-es/sysadmin-guide-es_0.8-1.dsc I would be glad if someone uploaded this package for me. Kind regards, -- Krzysztof Burghardt [EMAIL PROTECTED] http://www.burghardt.pl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
eastland racial breakpoint ;
As a business you have been preapproved to receive 58062 USD TODAY! No hassle at all, completely unsecured. There are no hidden costs or fees. Worried that your credit is less than perfect? Not an issue. Give us a ring, now.. 877~292~6894 Turn your dream into a reality. 877~292~6894 Misery wore not a stitch of clothing, yet Geoffrey thought that even the most prudish church-thrice-a-week village biddy could not have faulted her for indecency. His work did not suffer, but his mood did; he felt more and more that he was living in a cloud chamber, breathing an atmosphere thick with uncoalesced electricity. Grace Lyon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITP bugs
Among my 5 packages waiting at mentors.d.n, only the two more recents close ITP bugs. Would it be better practice if I issue a new Debian revisions for the 3 others after opening an ITP bug, with a changelog closing the latter? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: ITP bugs
Pierre THIERRY [EMAIL PROTECTED] (01/10/2007): Would it be better practice if I issue a new Debian revisions for the 3 others after opening an ITP bug, with a changelog closing the latter? Yes, although you don't need a new revision, just put the Closes: in the current revision (I think m.d.n supports overwritting already existing packages). Cheers, -- Cyril Brulebois pgpWCAI6C1SNy.pgp Description: PGP signature
RFS: mt19937, bordeaux-threads, salza-png, cl-vectors, vecto
Hi, As an interesting Common Lisp library was published some days ago, I packaged it with its dependencies that are not yet in Debian. The library itself is Vecto, a high-level lbrary for vector drawing based on CL-Vectors (low-level vector drawing) and Salza-PNG (PNG writer), its other dependencies being already in Debian, including my only package in Debian (ZPB-TTF). A sponsor already uploaded CL-Vectors previously, but it was rejected because license information was missing, which is now corrected. I also took the time to package a new version of Bordeaux Threads, a Common Lisp portability layer for multihreading, as upstream now included a patch from me with accurate license notices. My package of MT19937, a portable Mersenne Twister PRNG for Common Lisp, is still waiting for a sponsor. ITP: http://bugs.debian.org/444729 * Package name: vecto Version : 1.0.1-2 Upstream Author : Zachary Beane [EMAIL PROTECTED] * URL : http://www.xach.com/lisp/vecto/ * License : BSD Section : libs It builds these binary packages: cl-vecto - Simple Vector Drawing with Common Lisp The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vecto - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vecto/vecto_1.0.1-2.dsc * Package name: cl-vectors Version : 0.1.3-3 Upstream Author : Frédéric Jolliton [EMAIL PROTECTED] * URL : http://projects.tuxee.net/cl-vectors/ * License : LLGPL Section : libs It builds these binary packages: cl-vectors - Rasterizer and paths manipulation library The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cl-vectors - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cl-vectors/cl-vectors_0.1.3-3.dsc ITP: http://bugs.debian.org/444778 * Package name: salza-png Version : 1.0-2 Upstream Author : Zachary Beane [EMAIL PROTECTED] * URL : http://www.xach.com/lisp/salza-png.tgz * License : BSD Section : libs It builds these binary packages: cl-salza-png - Common Lisp package to write PNG The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/salza-png - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/salza-png/salza-png_1.0-2.dsc * Package name: bordeaux-threads Version : 0.0.2-1 Upstream Author : Greg Pfeil * URL : http://common-lisp.net/project/bordeaux-threads/ * License : MIT Section : libs It builds these binary packages: cl-bordeaux-threads - Portable shared-state concurrency for Common Lisp The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/bordeaux-threads - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/bordeaux-threads/bordeaux-threads_0.0.2-1.dsc * Package name: mt19937 Version : 1.1-1 Upstream Author : Douglas T. Crosher and Raymond Toy * URL : http://www.cliki.net/MT19937 * License : Public Domain Section : libs It builds these binary packages: cl-mt19937 - Common Lisp portable Mersenne Twister random number generator The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mt19937 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mt19937/mt19937_1.1-1.dsc Regards, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
[HELP] New Debian-native package
Hi all, I've created a little software in Gambas which lets users query the Debian BTS via LDAP. Now, since it's a Debian-specific package (maybe some time later other BTS will be supported, but that's not for sure), I wanted to package it as a Debian-native one. It's different from reportbug-ng (I believe someone might report this package as a counterpart) because it's possible (at least in theory, since I don't have KDE anywhere here) to switch the toolkit used on-the-fly. I mean, on my Xfce it works with GTK libraries, on KDE boxes it should use Qt ones. My question is: should I do anything special to upload it as a Debian-native? Obviously I'll send an RFP (and also an ITP if needed -- I don't know though), but besides this, is anything else needed? Kindly, David -- . ''`. Debian maintainer | http://snipurl.com/qa_page/ : :' : Linuxer #334216 | http://www.hanskalabs.net/ `. `'`GPG: 1392B174 | http://www.debianizzati.org/ `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature
Re: RFS: mt19937, bordeaux-threads, salza-png, cl-vectors, vecto
Now my five packages close their ITP bug: vecto - http://bugs.debian.org/444729 cl-vectors - http://bugs.debian.org/444910 salza-png - http://bugs.debian.org/444778 bordeaux-threads - http://bugs.debian.org/444911 mt19937 - http://bugs.debian.org/444912 Documentally, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: How package a binary library with unversioned soname?
On Sun, Sep 30, 2007 at 11:08:22PM -0700, Russ Allbery wrote: Nikolaus Schulz [EMAIL PROTECTED] writes: I am packaging printer drivers from Canon, see [1] for the ITP and some notes about that very peculiar, awkward beast. These drivers are only partly free software, they come with non-free, binary-only libraries. While this is bad enough, unfortunately the libraries have unversioned sonames, and I see zero chance to have upstream (Canon) fix this. So, one cannot produce valid shlibs files for these libraries. But these are required by policy. That is, as Steve Langasek has pointed out in [2], the policy de-facto requires libraries to have versioned sonames. Policy doesn't require valid SONAMEs for private shared libraries specific to a particular application. The SONAME requirement is to allow reasonable handling of library changes and upgrades of packages that built against the libraries, which only applies if the libraries are in a separate package from the programs that use them. If you have a program that contains some binaries linked with private libraries, Policy doesn't really care what those libraries are like provided that they're self-contained within that package and are installed in a subdirectory of /usr/lib. [snipped policy section] It sounds like you should try to treat these upstream shared libraries under this exception as private libraries for the binaries built by this package rather than trying to use them as first-class shared libraries. Upstream has provided about half a dozen, separate utility packages, and at least two link against the said libraries. One could argue if these packages *should* be separate, but they are. So I guess the libraries aren't private package-wise, and this isn't possible, right? Also, it would be nice to package the libraries separately, since this allows to have as much of the GPL licenced code[1] go into contrib, and only the libs themselves go into non-free. But this runs into the shlibs problem... I suspect there is no clean solution here; but I wonder what's best. What do you think? Nikolaus [1] There is no legal conflict here, since the licence includes an exception allowing to link against the binary libraries. signature.asc Description: Digital signature
RFS: pangzero (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.3-1 of my package pangzero. It builds these binary packages: pangzero - action game that involves popping balloons with a harpoon The package appears to be lintian clean. The upload would fix these bugs: 444918 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pangzero - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pangzero/pangzero_1.3-1.dsc I would be glad if someone uploaded this package for me. -- Marco Rodrigues http://Marco.Tondela.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
awuka
CWTE: C'Watre International, Inc Trade Alert. CWTE just announced trading on the OTC. CWTE has the potential to return 5 times your money with this tight capital structure. This means the stock can see $1.50 when news is realesed. CWTE has a womens line of ageless cosmetics that is overwhelming the celebrity industry. Keep an eye for news to hit the market and create a frenzy in this stock. When investors find out who's using it, the stock could go well beyond our target. debian-mentors, contact your broker NOW for CWTE! baelte baki azzilitu ayiihsin ayaksteb balkers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: pangzero (updated package)
Hi, On Mon, 01 Oct 2007 21:32:34 +0100 Marco Rodrigues [EMAIL PROTECTED] wrote: Dear mentors, I am looking for a sponsor for the new version 1.3-1 of my package pangzero. Uploaded, thanks for your work. It builds these binary packages: pangzero - action game that involves popping balloons with a harpoon The package appears to be lintian clean. You probably should consider using Build-Depends-Indep when building an arch all package. According lintian is entry 7.6 here [0]. regards, [0] http://www.debian.org/doc/debian-policy/ch-relationships.html -- Ricardo Mones http://people.debian.org/~mones «There is no distinctly native American criminal class except Congress. -- Mark Twain» signature.asc Description: PGP signature
Re: How package a binary library with unversioned soname?
Nikolaus Schulz [EMAIL PROTECTED] writes: Upstream has provided about half a dozen, separate utility packages, and at least two link against the said libraries. One could argue if these packages *should* be separate, but they are. So I guess the libraries aren't private package-wise, and this isn't possible, right? While with non-free software you can't really change the binaries, you definitely *can* change the packaging structure however you'd like. Does it make sense to have six different packages? Or is this really one thing that should be shipped as a single package? Also, it would be nice to package the libraries separately, since this allows to have as much of the GPL licenced code[1] go into contrib, and only the libs themselves go into non-free. But this runs into the shlibs problem... Eh, I can see why this would be nice but I don't think it's a particularly important feature. There isn't that much difference between contrib and non-free in practice. I suspect there is no clean solution here; but I wonder what's best. What do you think? I'm not sure I understand the situation well enough to really recommend something. How big are each of these packages? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
