RFS: jigzo (updated package)
Dear mentors, I am looking for a sponsor for the new version 0.6.1-3 of my package "jigzo". It builds these binary packages: jigzo - Photo puzzle game for children jigzo-data - data of Photo puzzle game for children The package appears to be lintian clean. Changelog: * debian/watch: Updated. * Rewrote the build system with debhelper and quilt. * Menu icon updated. * Use the quilt system patch. * Made two packages: jigzo and jigzo-data. * debian/control: Updated Standards-Version to 3.8.2. * debian/jigzo.6: Updated. I hope that once uploaded, complete renaming process (http://www.debian.org/doc/manuals/developers-reference/pkgs.html#s5.9.3) Because, its previous name was: glpuzzle. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/jigzo - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/j/jigzo/jigzo_0.6.1-3.dsc I would be glad if someone uploaded this package for me. Kind regards Elías Alejandro
dependencies of a library-dev package
Hi, I'm packaging a program which needs libgearman-dev to build. The libgearman source includes event.h, but the libgearman-dev package does not depend on libevent. Should my program build-depend on libevent-dev or is it the responsibility of libgearman-dev to depend on libevent-dev? Is it a bug or not? Thomas Koch, http://www.koch.ro -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: dependencies of a library-dev package
Thomas Koch wrote: > Hi, > > I'm packaging a program which needs libgearman-dev to build. > The libgearman source includes event.h, but the libgearman-dev package does > not depend on libevent. > Should my program build-depend on libevent-dev or is it the responsibility of > libgearman-dev to depend on libevent-dev? > > Is it a bug or not? If the header files in libgearman-dev do include event.h, the libgearman-dev should have a dependency on libevent-dev. If not, it's indeed a bug in libgearman-dev. Another good way to check the dependencies of dev package is to inspect its pkg-config file, if it ships one. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
RFS: backup-manager (adopted package, RC bug fix)
Dear mentors, I am looking for a sponsor for the new version 0.7.8-2 of my package "backup-manager". It builds these binary packages: backup-manager - command-line backup tool backup-manager-doc - documentation package for Backup Manager The detailed descriptions follow: ,[ backup-manager ] | This is a backup program, designed to help you make daily archives of | your file system. | | Written in bash and perl, it can make tar, tar.gz, tar.bz2, and zip | archives and can be run in a parallel mode with different configuration | files. Other archives are possible: MySQL or SVN dumps, incremental | backups... | | Archives are kept for a given number of days and the upload system can | use FTP, SSH or RSYNC to transfer the generated archives to a list of | remote hosts. | | Automatically burning archives to removable media such as CD or DVD is | also possible. | | The configuration file is very simple and basic and gettext is used for | internationalization. ` ,[ backup-manager-doc ] | Backup-manager is a backup program, designed to help you make daily | archives of your file system. | | This package provides the Backup Manager User Guide in different | formats: HTML, plain text and PDF. ` Apart from one overridden warning, the package appears to be lintian clean. The upload would fix these bugs: 499667, 516060, 518956, 528161, 532976, 535372, 536155. #516060 is an RC bug (missing build dependencies) that is present in testing, so I've chosen to upload with medium severity. There are quite a few other changes (see debian/changelog), and a debdiff would be too huge to be useful. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/backup-manager - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/backup-manager/backup-manager_0.7.8-2.dsc I would be glad if someone uploaded this package for me. Regards, Sven pgpnzf9q8Fysi.pgp Description: PGP signature
RFS: symlinks (updated package)
Dear mentors,
I am looking for a sponsor for the new version 1.2-6 of my package
"symlinks".
It builds this binary package:
symlinks - scan/change symbolic links
Detailed description:
,
| Symlinks scans directories for symbolic links and lists them on
| stdout. Each link is prefixed with a classification of relative,
| absolute, dangling, messy, lengthy or other_fs.
|
| Symlinks can also convert absolute links (within the same filesystem)
| to relative links and can delete messy and dangling links.
`
There is one overridden lintian warning and two remarks shown at the
"pedantic" level.
The upload would fix bug 61140, a bug that is more than nine years old.
I have also switched to using quilt as a patch system; the attached diff
shows the changes against the previous version after the patches have
been applied.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/s/symlinks
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/s/symlinks/symlinks_1.2-6.dsc
I would be glad if someone uploaded this package for me.
Regards,
Sven
pgpCp4F2bh1c8.pgp
Description: PGP signature
Only in symlinks-1.2: .pc
Only in symlinks-1.2/debian: README.source
diff -ur symlinks-1.2.old/debian/changelog symlinks-1.2/debian/changelog
--- symlinks-1.2.old/debian/changelog 2009-07-22 16:58:13.0 +0200
+++ symlinks-1.2/debian/changelog 2009-07-22 16:58:27.0 +0200
@@ -1,3 +1,15 @@
+symlinks (1.2-6) unstable; urgency=low
+
+ * Use get_current_dir_name() instead of getcwd() to ensure correct
+shortening if the path “symlinks” operates on contains itself a
+symlink (Closes: #61140). Thanks to Michael Schuerig.
+ * Use quilt as a patch system, add debian/README.source as
+recommended by Policy §4.14.
+ * Bump Standards-Version to 3.8.2, no further changes needed.
+ * Add Vcs-Browser and Vcs-Git fields to debian/control.
+
+ -- Sven Joachim Sat, 18 Jul 2009 16:36:17 +0200
+
symlinks (1.2-5) unstable; urgency=low
* New maintainer (Closes: #486001).
diff -ur symlinks-1.2.old/debian/control symlinks-1.2/debian/control
--- symlinks-1.2.old/debian/control 2009-07-22 16:58:13.0 +0200
+++ symlinks-1.2/debian/control 2009-07-22 16:58:27.0 +0200
@@ -2,8 +2,10 @@
Section: utils
Priority: optional
Maintainer: Sven Joachim
-Build-Depends: debhelper (>= 7)
-Standards-Version: 3.8.0
+Build-Depends: debhelper (>= 7), quilt (>= 0.40)
+Standards-Version: 3.8.2
+Vcs-Browser: http://git.debian.org/?p=users/joachim-guest/symlinks.git
+Vcs-Git: git://git.debian.org/users/joachim-guest/symlinks.git
Package: symlinks
Architecture: any
Only in symlinks-1.2/debian: patches
diff -ur symlinks-1.2.old/debian/rules symlinks-1.2/debian/rules
--- symlinks-1.2.old/debian/rules 2009-07-22 16:58:13.0 +0200
+++ symlinks-1.2/debian/rules 2009-07-22 16:58:27.0 +0200
@@ -2,7 +2,9 @@
# export DH_VERBOSE=1
-CFLAGS = -Wall -g
+include /usr/share/quilt/quilt.make
+
+CFLAGS = -Wall -g -D_GNU_SOURCE
ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
else
@@ -11,12 +13,12 @@
build: build-stamp
-build-stamp:
+build-stamp: patch
dh_testdir
$(MAKE) CFLAGS="$(CFLAGS)" prefix=/usr
touch $@
-clean:
+clean: unpatch
dh_testdir
$(MAKE) clean
dh_clean
@@ -44,4 +46,4 @@
binary: binary-indep binary-arch
-.PHONY: binary binary-arch binary-indep clean checkroot
+.PHONY: binary binary-arch binary-indep build clean patch unpatch
Only in symlinks-1.2/debian: stamp-patched
diff -ur symlinks-1.2.old/symlinks.c symlinks-1.2/symlinks.c
--- symlinks-1.2.old/symlinks.c 2009-07-22 16:58:13.0 +0200
+++ symlinks-1.2/symlinks.c 2009-07-22 16:58:56.503014120 +0200
@@ -303,7 +303,12 @@
int main(int argc, char **argv)
{
+#ifdef _GNU_SOURCE
+ static char path[PATH_MAX+2];
+ char* cwd = get_current_dir_name();
+#else
static char path[PATH_MAX+2], cwd[PATH_MAX+2];
+#endif
int dircount = 0;
char c, *p;
@@ -312,8 +317,13 @@
else
progname++;
+#ifdef _GNU_SOURCE
+ if (NULL == cwd) {
+ fprintf(stderr,"get_current_dir_name() failed\n");
+#else
if (NULL == getcwd(cwd,PATH_MAX)) {
fprintf(stderr,"getcwd() failed\n");
+#endif
return (1);
}
if (!*cwd || cwd[strlen(cwd)-1] != '/')
RFS: vera (updated package)
Dear mentors, I am looking for a sponsor for the new version 1.19-1 of my package "vera". It builds these binary packages: dict-vera - Dictionary of computer related acronyms -- dict format vera - Dictionary of computer related acronyms -- info format The detailed descriptions are as follows: ,[ dict-vera ] | The free version of V.E.R.A. - Virtual Entity of Relevant Acronyms - is | a comprehensive dictionary of computer related acronyms with more than | 11000 entries. This package contains the dictionary formatted for use | by the dictionary server in the dictd package. | | Note that this version is usually older than the one that is run on the | V.E.R.A. homepage. ` ,[ vera ] | The free edition of V.E.R.A. - Virtual Entity of Relevant Acronyms - is | a comprehensive dictionary of computer related acronyms with more than | 11000 entries. This package contains the dictionary formatted as a | single info file. | | Note that this version is usually older than the one that is run on the | V.E.R.A. homepage. ` There is one major change in the packaging, I have switched to using quilt as a patch system. This has been slightly complicated by the fact that I have to patch a file that upstream ships with CRLF endings in this release and that has to be converted to Unix LF. I had to put some extra targets into debian/rules to avoid failure of the patch/unpatch targets in some cases. Anyway, lintian does not seem to recognize that quilt and tofrodos are actually needed for the clean target, but I have not added an override for that (it only warns with the -i switch). In any case, the debdiff to the previous version is probably too large to be useful, so I omitted it. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/vera - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/vera/vera_1.19-1.dsc I would be glad if someone uploaded this package for me. Regards, Sven pgpqVKla0vyfm.pgp Description: PGP signature
Nomeclator of plugins
Hi, I think I have not seen it in the Debian policies. I have a dual role in one application: developer and co-maintainer. I would like to ask one question that fits in both. I'm in the bulmages project. It's a big piece of software with several applications with libs and plugins. It's a cmake build project. The plugins we have are lib.so. I add the properties (soname and version) to the plugins as the project main properties. The packages consist in several packages, etc. Now, we have a guy that it's packaging in Suse. First of all, he had to make some patch because the suse robot builders was more strict and didn't let him to build the package if some warning were done. We never receive any messages from that king [2]. The second, and it's my main question is about the nomenclature of the plugins. The guy says that the Suse force to create a package -dev if you have this kind of things (.so and symbolic links -.so.x.y.z). But I did a package for some .so (-dev) of the software, but not for all. Do we have a similar rule? Regards, Leo [1] http://developer.berlios.de/projects/bulmages/ [2] now the package is broken and I'm working in a new version with upstream ... -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Nomeclator of plugins
In <200907221847.44193@alaxarxa.net>, Leopold Palomo-Avellaneda wrote:
>I think I have not seen it in the Debian policies. I have a dual role in
> one application: developer and co-maintainer. I would like to ask one
> question that fits in both.
>
>I'm in the bulmages project. It's a big piece of software with several
>applications with libs and plugins. It's a cmake build project. The
> plugins we have are lib.so. I add the properties (soname and version)
> to the plugins as the project main properties. The packages consist in
> several packages, etc.
>
>The second, and it's my main question is about the nomenclature of the
>plugins. The guy says that the Suse force to create a package -dev if you
>have this kind of things (.so and symbolic links -.so.x.y.z). But I did a
>package for some .so (-dev) of the software, but not for all. Do we have a
>similar rule?
Something like that.
(IANADD)
A library package should install lib$SO_NAME.so.$SO_VERSION and be called
lib$SO_NAME$SO_VERSION.
The -dev package for that library should Depend on the library package,
install lib$SO_NAME.so as a symlink to the actual library (provided by the
library package), and be called lib${SO_NAME}-dev.
This allows multiple (major) versions of the library package to be
installed, so that package with binaries that haven't made the transition
can still run and Depend on the only version.
You might even consider making the SO_VERSION part of the lib*-dev package
name.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: Nomeclator of plugins
On Wed, Jul 22, 2009 at 03:02:19PM -0500, Boyd Stephen Smith Jr. wrote: > In <200907221847.44193@alaxarxa.net>, Leopold Palomo-Avellaneda wrote: > >I think I have not seen it in the Debian policies. I have a dual role in > > one application: developer and co-maintainer. I would like to ask one > > question that fits in both. > > > >I'm in the bulmages project. It's a big piece of software with several > >applications with libs and plugins. It's a cmake build project. The > > plugins we have are lib.so. I add the properties (soname and version) > > to the plugins as the project main properties. The packages consist in > > several packages, etc. > > > >The second, and it's my main question is about the nomenclature of the > >plugins. The guy says that the Suse force to create a package -dev if you > >have this kind of things (.so and symbolic links -.so.x.y.z). But I did a > >package for some .so (-dev) of the software, but not for all. Do we have a > >similar rule? > > Something like that. No, nothing like that. > (IANADD) > > A library package should install lib$SO_NAME.so.$SO_VERSION and be called > lib$SO_NAME$SO_VERSION. Except that these aren't regular shared libraries, they're dynamically loaded plugins. Leopold: no, Debian has no requirement that every shared object have a -dev package associated with it (see the many and various Apache module packages -- I wonder how SuSE deals with that hoary chestnut). However, you MUST NOT put your plugins directly into /usr/lib (or any other ld.so search path); instead, place them in something like /usr/lib//plugins and have the application look for them in there. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
different debian/symbols for 32 and 64 bit system?
Hi all, I am upgrading library package here and it seems that dpkg-gensymbols asking different debian/symbols file for my 32bit system and different for 64bit one. Working debian symbols files are in attachments. (they are different in the end of them) Can someone advise me how such issue solve please? regards mira libclxclient.so.3 libclxclient3 #MINVER# _z17clxclient_versi...@base 3.6.1-1~ _zn10x_callbackd...@base 3.6.1-1~ _zn10x_callbackd...@base 3.6.1-1~ _zn13x_scale_style5limi...@base 3.6.1-1~ _zn13x_scale_style7calcpi...@base 3.6.1-1~ _zn13x_scale_style7calcva...@base 3.6.1-1~ _zn5edestd...@base 3.6.1-1~ _zn5edestd...@base 3.6.1-1~ _zn5esyncd...@base 3.6.1-1~ _zn6x_draw10drawpointseip6xpo...@base 3.6.1-1~ _zn6x_draw10drawstringep...@base 3.6.1-1~ _zn6x_draw12drawsegmentseip8xsegm...@base 3.6.1-1~ _zn6x_draw7movepixei...@base 3.6.1-1~ _zn6x_draw7setclipei...@base 3.6.1-1~ _zn6x_draw9drawlineseip6xpo...@base 3.6.1-1~ _zn6x_draw9textwidthe...@base 3.6.1-1~ _zn6x_drawc1ep9_xdisplaymp4_xgcp8_xftd...@base 3.6.1-1~ _zn6x_drawc2ep9_xdisplaymp4_xgcp8_xftd...@base 3.6.1-1~ _zn7x_hints4size...@base 3.6.1-1~ _zn7x_hints5grou...@base 3.6.1-1~ _zn7x_hints5inpu...@base 3.6.1-1~ _zn7x_hints5stat...@base 3.6.1-1~ _zn7x_hints7maxsize...@base 3.6.1-1~ _zn7x_hints7minsize...@base 3.6.1-1~ _zn7x_hints7sizeinc...@base 3.6.1-1~ _zn7x_hints8position...@base 3.6.1-1~ _zn7x_meter12handle_eventep7_xev...@base 3.6.1-1~ _zn7x_meter6exposeep12xexposeev...@base 3.6.1-1~ _zn7x_meter7set_re...@base 3.6.1-1~ _zn7x_meter7set_va...@base 3.6.1-1~ _zn7x_meter8plotsecteiii...@base 3.6.1-1~ _zn7x_meter9plotmarkse...@base 3.6.1-1~ _zn7x_meterc1ep8x_windowp13x_meter_stylep13x_scale_stylei...@base 3.6.1-1~ _zn7x_meterc2ep8x_windowp13x_meter_stylep13x_scale_stylei...@base 3.6.1-1~ _zn7x_meterd...@base 3.6.1-1~ _zn7x_meterd...@base 3.6.1-1~ _zn8h_threadd...@base 3.6.1-1~ _zn8h_threadd...@base 3.6.1-1~ _zn8h_threadd...@base 3.6.1-1~ _zn8itc_ip1q13put_event_try...@base 3.6.1-1~ _zn8itc_ip1q7ipflus...@base 3.6.1-1~ _zn8itc_ip1q9put_eventejp8itc_m...@base 3.6.1-1~ _zn8itc_ip1q9put_event...@base 3.6.1-1~ _zn8itc_ip1qd...@base 3.6.1-1~ _zn8itc_ip1qd...@base 3.6.1-1~ _zn8x_button12handle_eventep7_xev...@base 3.6.1-1~ _zn8x_button6bpressep12xbuttonev...@base 3.6.1-1~ _zn8x_button6exposeep12xexposeev...@base 3.6.1-1~ _zn8x_button6redra...@base 3.6.1-1~ _zn8x_button7releas...@base 3.6.1-1~ _zn8x_button8breleaseep12xbuttonev...@base 3.6.1-1~ _zn8x_button8set_sta...@base 3.6.1-1~ _zn8x_buttonc1ep8x_windowp10x_callbackp14x_button_style...@base 3.6.1-1~ _zn8x_buttonc2ep8x_windowp10x_callbackp14x_button_style...@base 3.6.1-1~ _zn8x_buttond...@base 3.6.1-1~ _zn8x_buttond...@base 3.6.1-1~ _zn8x_buttond...@base 3.6.1-1~ _zn8x_enumip12handle_eventep7_xev...@base 3.6.1-1~ _zn8x_enumip4_x...@base 3.6.1-1~ _zn8x_enumip5cbke...@base 3.6.1-1~ _zn8x_enumip5spkeyep9xkeyev...@base 3.6.1-1~ _zn8x_enumip6bpressep12xbuttonev...@base 3.6.1-1~ _zn8x_enumip6exposeep12xexposeev...@base 3.6.1-1~ _zn8x_enumip6redra...@base 3.6.1-1~ _zn8x_enumip6selec...@base 3.6.1-1~ _zn8x_enumip7set_in...@base 3.6.1-1~ _zn8x_enumip8keypressep9xkeyev...@base 3.6.1-1~ _zn8x_enumip8remfocusep17xfocuschangeev...@base 3.6.1-1~ _zn8x_enumip8setfocusep17xfocuschangeev...@base 3.6.1-1~ _zn8x_enumip9_utf8ma...@base 3.6.1-1~ _zn8x_enumip9textwidth...@base 3.6.1-1~ _zn8x_enumipc1ep8x_windowp10x_callbackp14x_textln_stylep11x_enip_itemp8x_linked...@base 3.6.1-1~ _zn8x_enumipc2ep8x_windowp10x_callbackp14x_textln_stylep11x_enip_itemp8x_linked...@base 3.6.1-1~ _zn8x_enumipd...@base 3.6.1-1~ _zn8x_enumipd...@base 3.6.1-1~ _zn8x_enumipd...@base 3.6.1-1~ _zn8x_hmeter5pmarkep4_x...@base 3.6.1-1~ _zn8x_hmeter5psectep4_xg...@base 3.6.1-1~ _zn8x_hmeterc1ep8x_windowp13x_meter_stylep13x_scale_style...@base 3.6.1-1~ _zn8x_hmeterc2ep8x_windowp13x_meter_stylep13x_scale_style...@base 3.6.1-1~ _zn8x_hmeterd...@base 3.6.1-1~ _zn8x_hmeterd...@base 3.6.1-1~ _zn8x_hscale12handle_eventep7_xev...@base 3.6.1-1~ _zn8x_hscale6exposeep12xexposeev...@base 3.6.1-1~ _zn8x_hscalec1ep8x_windowp13x_scale_stylei...@base 3.6.1-1~ _zn8x_hscalec2ep8x_windowp13x_scale_stylei...@base 3.6.1-1~ _zn8x_hscaled...@base 3.6.1-1~ _zn8x_hscaled...@base 3.6.1-1~ _zn8x_linkedd...@base 3.6.1-1~ _zn8x_linkedd...@base 3.6.1-1~ _zn8x_mclist12handle_eventep7_xev...@base 3.6.1-1~ _zn8x_mclist4bac...@base 3.6.1-1~ _zn8x_mclist4for...@base 3.6.1-1~ _zn8x_mclist4itemepk...@base 3.6.1-1~ _zn8x_mclist4mov...@base 3.6.1-1~ _zn8x_mclist4sho...@base 3.6.1-1~ _zn8x_mclist4sor...@base 3.6.1-1~ _zn8x_mclist6bpressep12xbuttonev...@base 3.6.1-1~ _zn8x_mclist6exposeep12xexposeev...@base 3.6.1-1~ _zn8x_mclist6resize...@base 3.6.1-1~ _zn8x_mclist6updateei...@base 3.6.1-1~ _zn8x_mclistc1ep8x_windowp10x_callbackp14x_mclist_styleiii...@base 3.6.1-1~ _zn8x_mclistc2ep8x_windowp10x_callbackp14x_mclist_styleiii...@base 3.6.1-1~ _zn8x_mclistd...@base 3.6.1-1~ _zn8
Re: different debian/symbols for 32 and 64 bit system?
On Thu, Jul 23, 2009 at 05:06:54AM +0200, Jaromír Mikeš wrote: > Hi all, > > I am upgrading library package here and it seems that dpkg-gensymbols asking > different debian/symbols file for my 32bit system and different for 64bit one. > Working debian symbols files are in attachments. (they are different in the > end of them) > > Can someone advise me how such issue solve please? > see the dpkg-gensymbols manpage. it explains how to use different symbols files for different architectures. -- _ Ryan Niebur ryanrya...@gmail.com signature.asc Description: Digital signature
Re: Re: different debian/symbols for 32 and 64 bit system?
> Od: Ryan Niebur > see the dpkg-gensymbols manpage. it explains how to use different > symbols files for different architectures. I see it now Thank you.. mira -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
