Re: Adding symbols files to the tango package.
On Mon, 01 Aug 2011, Michael Tautschnig wrote:
Indeed symbol ordering may vary, but also there is no reason for
dpkg-gensymbols
to guarantee a particular ordering.
Well, dpkg-gensymbols does sort the symbols files. Precisely so that
diff are meaningful. Otherwise they would be useless.
Code extract:
foreach my $sym (sort { $a-get_symboltempl() cmp
$b-get_symboltempl() } @symbols) {
What this means is that the symbols files provided by the package is not
properly sorted...
That said the generated diff should not always be applied as is. In many
cases if you have used tags and patterns in your symbols files, adding a
new symbol requires some post-processing to make it fit with the way the
symbols file is managed.
For example deactivating a symbol on a specific architecture requires fiddling
with an arch tag rather than removing the symbol...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110803062605.gc28...@rivendell.home.ouaza.com
Re: RFS: l2tp-ipsec-vpn
Hi Werner, On Tue, Aug 02, 2011 at 07:20:27AM +0200, Werner Jaeger wrote: thank you so much for this review. I addressed and solved all the issues and uploaded the changes to mentors.debian.net. BTW I'm still looking for a sponsor to upload this package. http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.0-1.dsc Having another look at this updated version I see that your depends still lists l2tp-ipsec-vpn-daemon which has an ITP (now RFP) but no package in Debian. Apart from that the construction with nbproject in debian/rules looks a bit unusual but still ok. Yet as you're upstream I wonder why this dependency is not put into upstream makefiles. If you want we can put l2tp-ipsec-vpn into NEW first, but it won't be installable withtout l2tp-ipsec-vpn-daemon. How far is your ITP w.r.t. actually producing a package? -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: smarty
Hi, thanks for your interest in smarty. On Mon, 01 Aug 2011, Wojciech Szaranski wrote: The package appears to be lintian clean. The upload would fix these bugs: 514305 Have you read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=514305#10 ? Because: 1/ you have not taken care of the case where other packages install files in /usr/share/php/smarty/libs/plugins (i.e. no preinst, no conflicts, nothing for this) $ apt-file search /usr/share/php/smarty/libs | cut -d: -f1 | uniq collabtive smarty smarty-acl-render smarty-gettext smarty-validate 2/ you have not informed me 3/ you have not contacted any other maintainer of a reverse-dependency asking them to test with your updated package (and warning them that a new upstream version will land shortly in Debian) (but before doing so, let's fix this package) $ apt-cache showpkg smarty Reverse Depends: piwigo,smarty 2.6.26 moodle,smarty smarty-acl-render,smarty gosa,smarty smbind,smarty smarty-validate,smarty smarty-gettext,smarty slbackup-php,smarty serendipity,smarty piwigo,smarty 2.6.26 phpgacl,smarty 2.6.9 ojs,smarty moodle,smarty kolab-webadmin,smarty gallery2,smarty 2.6.26 collabtive,smarty Maitaining a library requires more care than the usual package, please pay attention to everything. My motivation for maintaining this package is: I would like to share packages that I'm using :) Great, but you should make it work for everybody and not only you. :-) A few remarks: - you should not package it as a Debian native package but as 3.0 (quilt) mkdir debian/source echo 3.0 (quilt) debian/source/format - you should indicate in the changelog which security issues are fixed by this upload by incorporating all the corresponding CVE numbers http://security-tracker.debian.org/tracker/source-package/smarty - you should update it to the latest Standards-Version (verify that it follows the latest policy with /usr/share/doc/debian-policy/upgrading-checklist.txt.gz) - the package does not even build currently because make invokes make install as that's the only target and debian/rules build does not have the required root rights There's lots of work left as you can see. You should really also check your package with lintian on Debian unstable, there are lots of issues: W: smarty source: native-package-with-dash-version I: smarty source: missing-debian-source-format W: smarty source: out-of-date-standards-version 3.8.4 (current is 3.9.2) W: smarty: wrong-name-for-upstream-changelog usr/share/doc/smarty/change_log.txt.gz W: smarty: debian-changelog-line-too-long line 2 E: smarty: helper-templates-in-copyright W: smarty: symlink-is-self-recursive usr/share/php/smarty/libs . I: smarty: package-contains-empty-directory usr/share/doc/smarty/demo/cache/ I: smarty: package-contains-empty-directory usr/share/doc/smarty/demo/templates_c/ Obviously W: smarty: symlink-is-self-recursive usr/share/php/smarty/libs . can't be fixed, you have to override it and document the reason for this override. Please CC me for a secound review once you have fixed everything reported here. Feel free to ask questions as well if you don't understand something. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803065527.gd28...@rivendell.home.ouaza.com
Re: RFS: smarty
On Wed, 03 Aug 2011, Raphael Hertzog wrote: Because: 1/ you have not taken care of the case where other packages install files in /usr/share/php/smarty/libs/plugins (i.e. no preinst, no conflicts, nothing for this) Just to clarify, you should add versioned conflicts on all those packages so that they are upgraded/removed before smarty is upgraded. Of course the other packages have to provide new versions with the files moved for this to work. Thus you have to coordinate with those maintainers. The postinst should have some code to drop the directory /usr/share/php/smarty/libs and replace it with a symlink because the simple upgrade will not replace it properly (dpkg does not replace dir by symlinks and vice-versa, per policy). On a unrelated note, it would be a good idea to maintain this package in a public VCS repository on collab-maint (my preference goes to git): http://wiki.debian.org/Alioth/PackagingProject Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803070518.gf28...@rivendell.home.ouaza.com
Re: RFS: nullidentd (adopting package)
Hello Michael, On Sat, Jul 30, 2011 at 12:00:58AM +0100, Michael Tautschnig wrote: Thanks a lot for stepping up as new maintainer of this package. I've briefly reviewed your changes over the previous package and it all looks good. Built and uploaded. For a future upload, however, it would be nice to see an update to the copyright file: it doesn't say that this is GPL v2, and using DEP-5 format would be a plus. Thank you for reviewing and sponsoring this package. Updating debian/copyright is on my todo list. Regards, -- Jeroen Schot -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803070107.ga1...@a-eskwadraat.nl
Re: RFS: eviacam
Hi Cesar, On Wed, Aug 03, 2011 at 05:23:43AM +0200, Cesar Mauri wrote: Thanks for your comments. I have (hopefully) addressed all the issues you pointed out. I have uploaded an updated version to the mentors site which appears to be lintian clean and pbuilds fine for sid. See below for additional details. Thanks for your work! [...] or so and move the SUID bit setting including creating a group to postinst so that you limit the impact to an acceptable minimum. Having an open root access for everybody on a system is quite a bit too generous IMHO. I don't like also having a SUID binary but it is the only way I found to raise the priority of the process. I've moved the chmod to the postinst script but I couldn't create a group to setuid to because the nice system call (see nice(2)) needs superuser privileges. I seem to have not expressed my idea correctly: - Have your binary chmod 4750 - with uid 0 (thus the setUID) and - group whateveryournewgroupname In debian/postinst that would look like: chmod 4750 $BINARY chown 0:$GID $BINARY where $GID is the group id of the group you create in postinst. That will make sure it gets the UID 0 correctly so that nice(2) will work ok and also will make sure that only users of the group are allowed to execute it. Does that make sense for you? -- Best regards, Kilian signature.asc Description: Digital signature
Re: Doubt about library version
Hi, if one application has two packages in debian (Z and libZ), but in the new upstream release, the library does not exists, what's happend with the package libZ in debian? we need to close the library package? What do you mean by close here!? Furthermore, are you asking this question as the maintainer of the application or a user of libZ? Best, Michael PS.: I guess it would be helpful if you could name the package. pgp7SQ3iphrgU.pgp Description: PGP signature
Re: RFS: smarty
hi, On Mon, Aug 1, 2011 at 3:23 PM, Wojciech Szaranski loq...@gmail.com wrote: * Package name : smarty Version : 3.0.8-5 There is a smarty3 package with the same version http://packages.debian.org/sid/smarty3 . Best Regards, -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFFwCaSXzqgJdP+c5Z6d3dy80svsbb8NK=DKL=qo8hbftdm...@mail.gmail.com
Re: Doubt about library version
On Wed, 3 Aug 2011 09:27:30 +0100, Michael Tautschnig wrote: Hi, if one application has two packages in debian (Z and libZ), but in the new upstream release, the library does not exists, what's happend with the package libZ in debian? we need to close the library package? What do you mean by close here!? Furthermore, are you asking this question as the maintainer of the application or a user of libZ? Best, Michael PS.: I guess it would be helpful if you could name the package. Thanks Michael, the wmaker package includes some libraries in the upstream source. One of this libraries includes some files (WMaker.h and libMaker.*). This files are not in the source tree now (were removed from the git because they are not longer needed). Therefore, the package libwmaker0-dev doesn't include any files (only the documentation files README.debian,...), and then the package should not be included in future versions. I need to do something in the debian folder files? Best Regards, kix. -- ||// //\\// Rodolfo kix Garcia ||\\// //\\ http://www.kix.es/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/6d60074bc09b50e2234d7e6de9664...@kix.es
Re: Doubt about library version
Hi, [...] the wmaker package includes some libraries in the upstream source. One of this libraries includes some files (WMaker.h and libMaker.*). This files are not in the source tree now (were removed from the git because they are not longer needed). Therefore, the package libwmaker0-dev doesn't include any files (only the documentation files README.debian,...), and then the package should not be included in future versions. I need to do something in the debian folder files? As a very first step you need to check for reverse depends, for instance by doing apt-cache showpkg libwmaker0-dev (on a sid system!). If no Reverse Dependencies are reported, you can remove the package from your control file, upload a new version, and then file a removal request. For much more information please see http://wiki.debian.org/ftpmaster_Removals Best, Michael pgpzUDeJAUQsq.pgp Description: PGP signature
Re: Doubt about library version
On 2011-08-03 11:28, Michael Tautschnig wrote: Hi, [...] the wmaker package includes some libraries in the upstream source. One of this libraries includes some files (WMaker.h and libMaker.*). This files are not in the source tree now (were removed from the git because they are not longer needed). Therefore, the package libwmaker0-dev doesn't include any files (only the documentation files README.debian,...), and then the package should not be included in future versions. I need to do something in the debian folder files? As a very first step you need to check for reverse depends, for instance by doing apt-cache showpkg libwmaker0-dev (on a sid system!). If no Reverse Dependencies are reported, you can remove the package from your control file, upload a new version, and then file a removal request. For much more information please see http://wiki.debian.org/ftpmaster_Removals Best, Michael $ build-rdeps libwmaker0-dev [...] Reverse Build-depends in main: -- wterm fsviewer Found a total of 2 reverse build-depend(s) for libwmaker0-dev. [...] Btw, I am not certain an explicit removal request is needed if the package will still build at least one binary. The ftp-masters have an auto-decrufter should catch this case. ~Niels -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e39155c.4060...@thykier.net
Re: RFS: smarty
Hi, On Wed, 03 Aug 2011, Thierry Randrianiriana wrote: On Mon, Aug 1, 2011 at 3:23 PM, Wojciech Szaranski loq...@gmail.com wrote: * Package name : smarty Version : 3.0.8-5 There is a smarty3 package with the same version http://packages.debian.org/sid/smarty3 . And you are the maintainer of it... can you elaborate why you packaged it under a new package name? We certainly don't want 2 versions of this package in the long term in Debian. Please ensure we have some sort of upgrade plans to get back to 1 version only. In particular given the number of security issues that have affected it. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110803093546.gj28...@rivendell.home.ouaza.com
Re: RFS: wizznic
El Tue, 02 Aug 2011 09:21:23 +0200 Ansgar Burchardt ans...@debian.org escribió: Adam Borowski kilob...@angband.pl writes: Right, I missed the .o and .dll files, counting only wizznic-x86-precompiled and tools/releaser/data/win/curl/curl.exe (the ones mentioned by lintian). The dlls are libjpeg, zlib, libogg, SDL, openssl -- all DFSG free with source already in main. The source would need to be included in the same (source) package to make sure that it is the same version and that we will still include source even if another package is removed from the archive. Ansgar I get a little confused about what I do with the dfsg, I should remove the binaries or add a the source of them? Also, I need to modify the d/copyright, d/changelog, d/watch make README.debian-source, orig.tar.bz2 and add a rule get-orig-source to d/rules to make a _good_ dfsg repackage? -- .''`. Tony Palma. : :' : PGP/GPG Key ID: 258FFB1A `. `' identi.ca: xbytemx `-Debian GNU/Linux signature.asc Description: PGP signature
Re: RFS: eviacam
Hi Kilian, [...] or so and move the SUID bit setting including creating a group to postinst so that you limit the impact to an acceptable minimum. Having an open root access for everybody on a system is quite a bit too generous IMHO. I don't like also having a SUID binary but it is the only way I found to raise the priority of the process. I've moved the chmod to the postinst script but I couldn't create a group to setuid to because the nice system call (see nice(2)) needs superuser privileges. I seem to have not expressed my idea correctly: - Have your binary chmod 4750 - with uid 0 (thus the setUID) and - group whateveryournewgroupname In debian/postinst that would look like: chmod 4750 $BINARY chown 0:$GID $BINARY where $GID is the group id of the group you create in postinst. That will make sure it gets the UID 0 correctly so that nice(2) will work ok and also will make sure that only users of the group are allowed to execute it. Does that make sense for you? Got it! Before creating a new group, is there any previously existing group that would be suitable for such a job (i.e. that a common desktop user would be part of)? I think that if we need to create a new group may be some non-expert users won't be able to run eviacam properly (i.e. they might fail to add their username to such group). Other options include: i) ask the user whether to make eviacamloader SUID and explain that a new group is needed and such and such. ii) completely get rid of the SUID thing at the expense of less responsiveness. What do you think? Thanks. Regards, César -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e392f7e.4000...@crea-si.com
Re: RFS: eviacam
Hi Cesar, On Wed, 2011-08-03 at 13:22 +0200, Cesar Mauri wrote: [...] or so and move the SUID bit setting including creating a group to postinst so that you limit the impact to an acceptable minimum. Having an open root access for everybody on a system is quite a bit too generous IMHO. I don't like also having a SUID binary but it is the only way I found to raise the priority of the process. I've moved the chmod to the postinst script but I couldn't create a group to setuid to because the nice system call (see nice(2)) needs superuser privileges. I seem to have not expressed my idea correctly: - Have your binary chmod 4750 - with uid 0 (thus the setUID) and - group whateveryournewgroupname In debian/postinst that would look like: chmod 4750 $BINARY chown 0:$GID $BINARY where $GID is the group id of the group you create in postinst. That will make sure it gets the UID 0 correctly so that nice(2) will work ok and also will make sure that only users of the group are allowed to execute it. Does that make sense for you? Got it! Before creating a new group, is there any previously existing group that would be suitable for such a job (i.e. that a common desktop user would be part of)? None that would fit the requirements we have here IMHO. I think that if we need to create a new group may be some non-expert users won't be able to run eviacam properly (i.e. they might fail to add their username to such group). Other options include: i) ask the user whether to make eviacamloader SUID and explain that a new group is needed and such and such. Can be done with debconf quite easily as: a) Ask whether SUID should be activated b) which users should be added to the group interactively Please set sensible defaults so that you can also work with DEBCONF_FRONTEND=noninteractive ii) completely get rid of the SUID thing at the expense of less responsiveness. If that's possible and doesn't limit core functionality it sounds like a valid option. What downsides would that bring? I think debconf as explained above together with properly adding a new group and importing users through debconf would be a good thing. -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
Re: looking for sponsor for my package jscribble
Dear Niels, I am not too sure on the `...` quoting-style. I think ... is better, but I could be wrong, so I am hoping to get a second opinion from the list. :) I suppose it is related to the use of 10 as 10 inch? The `...` style is Markdown's way to get monospace, but I assume that ... is preferred in package descriptions. I can change it if that is the default. I think the me should be them, but I am also thinking it might be better to re-word the entire paragraph. I changed it to third person already since it does not sound too good in first person. When uploading to Debian unstable, yes. You do not have to install Debian to do this though; a sid chroot will suffice for the common cases (pbuilder/cowbuilder can be of use here). That is what virtual machines are for, I am just setting up a Debian unstable machine for packaging. I noticed there is an empty field (Source) in d/copyright; is that intentional? I put a place where one can download the sources there now. d/docs can be removed (as it is now an empty file). :) I deleted that file. It should be uploaded to mentors again. Martin signature.asc Description: OpenPGP digital signature
Re: RFS: l2tp-ipsec-vpn
Hi Kilian, you should be able to find l2tp-ipsec-vpn-daemon package at http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=l2tp-ipsec-vpn-daemon Repository URL is http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn-daemon So far, this package has got now review yet. If you find the l2tp-ipsec-vpn-daemon package to be o.k. I'd be happy if some one could put both packages into NEW. thanks Werner On 08/03/2011 08:46 AM, Kilian Krause wrote: Hi Werner, On Tue, Aug 02, 2011 at 07:20:27AM +0200, Werner Jaeger wrote: thank you so much for this review. I addressed and solved all the issues and uploaded the changes to mentors.debian.net. BTW I'm still looking for a sponsor to upload this package. http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.0-1.dsc Having another look at this updated version I see that your depends still lists l2tp-ipsec-vpn-daemon which has an ITP (now RFP) but no package in Debian. Apart from that the construction with nbproject in debian/rules looks a bit unusual but still ok. Yet as you're upstream I wonder why this dependency is not put into upstream makefiles. If you want we can put l2tp-ipsec-vpn into NEW first, but it won't be installable withtout l2tp-ipsec-vpn-daemon. How far is your ITP w.r.t. actually producing a package? -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e39590c.9060...@web.de
Re: RFS: l2tp-ipsec-vpn
Hi Werner, On Wed, 2011-08-03 at 16:19 +0200, Werner Jaeger wrote: you should be able to find l2tp-ipsec-vpn-daemon package at http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=l2tp-ipsec-vpn-daemon Repository URL is http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn-daemon So far, this package has got now review yet. If you find the l2tp-ipsec-vpn-daemon package to be o.k. I'd be happy if some one could put both packages into NEW. the postinst, postrm, prerm aren't used. You may want to delete them. debian/rules reads: make -f nbproject/qt-Release.mk dist/Release/GNU-Linux-x86/L2tpIPsecVpnControlDaemon -(snip)- Why hard code the arch here? Will this be a problem on any Debian arch including the kFreeBSD ones? As I already said for the GUI - the construction with the extra nbproject looks a bit weird as you are both upstream and Debian maintainer. I'm not sure you aren't overcomplicating the debian/rules file. Regarding the test target in debian/rules you've put it for the daemon and for the GUI yet both times without content. Any reason to add this line here? Are you planning on adding tests (which would be great) but they aren't ready despite your 1.0.0 version number? I'm not too sure whether /usr/lib/l2tp-ipsec-vpn-daemon/L2tpIPsecVpnControlDaemon is the best path to put your deamon. I'd see /usr/sbin somewhat more appropriate. Other than that good to go IMHO. -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
RFS: aescrypt
Dear mentors, I am looking for a sponsor for my package aescrypt. * Package name: aescrypt Version : 3.05-1 Upstream Author :Glenn Washburn cr...@berlios.de Paul E. Jones pau...@packetizer.com Mauro Gilardi galva...@gmail.com * URL : http://www.aescrypt.com/ * License : gpl3 Section : utils It builds these binary packages: aescrypt - Simple tool for encrypt and decrypt files using AES The package appears to be lintian clean. The upload would fix these bugs: 609505 My motivation for maintaining this package is: [fill in]. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/aescrypt - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/aescrypt/aescrypt_3.05-1.dsc I would be glad if someone uploaded this package for me. Kind regards Ali MEZGANI -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
Re: RFS: mpd-sima (updated package)
Hi Geoff, On Mon, Aug 01, 2011 at 04:42:15PM +0200, Geoffroy Youri Berret wrote: I gentle ping on this package :) I moved the packaged to Debian Multimedia Maintainers. git://git.debian.org/pkg-multimedia/mpd-sima.git I believe the package to be in pretty good shape now. Thanks for your work. From a first look: 1.) You build-depend on bash-completion. What for? Moreover you build-depend on python-all which huge compared to what you will actually need IMHO. Why not limit that more to what is actually required? 2.) You should leave the new upload at 0.8.0-1 because your changelog entry never made it into unstable as a package. (Your sponsor would need to build with -sa and -v etc. etc. which is nasty) 3.) You drop debian/html from the docs without mentioning in the changelog 5.) http://sima.codingteam.net seems no longer valid. New homepage is at...? 6.) /usr/share/common-licenses/GPL in debian/copyright should rather be the versioned reference (GPL-3) 7.) lintian proposes to enhance simadb_cli.1.gz: allows to should be allows one to I would be glad if someone uploaded this package for me. Please comment the above and I'll put it in. -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: aescrypt
On Wed, Aug 03, 2011 at 04:16:23PM +, mezgani ali wrote: * License : gpl3 No, it's GPL2+ for aes.c and sha256.c and non-free freeware license (not explicitly allowing modification) for other files. -- WBR, wRAR signature.asc Description: Digital signature
Re: Adding symbols files to the tango package.
Le Wed, 3 Aug 2011 08:26:05 +0200,
Raphael Hertzog hert...@debian.org a écrit :
On Mon, 01 Aug 2011, Michael Tautschnig wrote:
Indeed symbol ordering may vary, but also there is no reason for
dpkg-gensymbols
to guarantee a particular ordering.
Well, dpkg-gensymbols does sort the symbols files. Precisely so that
diff are meaningful. Otherwise they would be useless.
Code extract:
foreach my $sym (sort { $a-get_symboltempl() cmp
$b-get_symboltempl() } @symbols) {
What this means is that the symbols files provided by the package is not
properly sorted...
What do your mean exactly by sorted ?
sorted using the 'sort' program ?
sorted like the un-mangled symbols ?
That said the generated diff should not always be applied as is. In many
cases if you have used tags and patterns in your symbols files, adding a
new symbol requires some post-processing to make it fit with the way the
symbols file is managed.
Yes I understood, that this patch should not be applyied as it.
Maybe the patch should add MISSING and ADDED symbols.
then it would be the maintainer responsability to properly tag thoses
new/missing symbols.
For example deactivating a symbol on a specific architecture requires fiddling
with an arch tag rather than removing the symbol...
It means also that if I use #include it is no more possible to use the patch
right ?
See you
Frederic
--
GPG public key 4096R/4696E015 2011-02-14
fingerprint = E92E 7E6E 9E9D A6B1 AA31 39DC 5632 906F 4696 E015
uid Picca Frédéric-Emmanuel pi...@synchrotron-soleil.fr
GPG public key 1024D/A59B1171 2009-08-11
fingerprint = 1688 A3D6 F0BD E4DF 2E6B 06AA B6A9 BA6A A59B 1171
uid Picca Frédéric-Emmanuel pi...@debian.org
signature.asc
Description: PGP signature
Re: RFS: mpd-sima (updated package)
Hi Kilian, Thanks for your review :) Le 03/08/2011 18:29, Kilian Krause a écrit : On Mon, Aug 01, 2011 at 04:42:15PM +0200, Geoffroy Youri Berret wrote: I gentle ping on this package :) I moved the packaged to Debian Multimedia Maintainers. git://git.debian.org/pkg-multimedia/mpd-sima.git I believe the package to be in pretty good shape now. […] 1.) You build-depend on bash-completion. What for? Moreover you build-depend on python-all which huge compared to what you will actually need IMHO. Why not limit that more to what is actually required? [bash-completion] I need bash-completion because it provides dh_bash-completion. It'll handle debian/mpd-sima.bash-completion properly. [python-all] Well, I think need python 2.6 and python 2.7, I guess then I could save python 2.5 setting a build depends on python2.6 instead of python-all. But isn't “python-all (= 2.6.6-3~)” similar? 2.) You should leave the new upload at 0.8.0-1 because your changelog entry never made it into unstable as a package. (Your sponsor would need to build with -sa and -v etc. etc. which is nasty) Indeed your right. I bumped the package version when I included latest reviews. I wasn't sure of the right move back then, I understand now I should have appended them to ease uploaders work. 3.) You drop debian/html from the docs without mentioning in the changelog That was actually a dummy entry within debian/mpd-sima.docs which never provided html documentation. That was an attempt to build html docs when working on package for 0.8 branch that I forgot to clean up… Since it was not in in previous packages uploaded to Debian I did not mentioned it in the Changelog “4.)” somehow disappeared ^^ 5.) http://sima.codingteam.net seems no longer valid. New homepage is at...? Damn!! You're right! The forge hosting the project did actually move to a new server and lost that feature during the migration. Thanks for noticing! I'll switch to a more robust URL. 6.) /usr/share/common-licenses/GPL in debian/copyright should rather be the versioned reference (GPL-3) Done 7.) lintian proposes to enhance simadb_cli.1.gz: allows to should be allows one to This has been fixed upstream :) I don't want to push a patch in the package for that, I prefer to keep things simple :) I would be glad if someone uploaded this package for me. Please comment the above and I'll put it in. I've uploaded a new version, tagged 0.8.0-1, to mentors. I haven't pushed to the git repo yet. http://mentors.debian.net/debian/pool/main/m/mpd-sima/mpd-sima_0.8.0-1.dsc Thanks Geoff -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e39a5e3.9000...@azylum.org
Re: RFS: eviacam
Hi Kilian, [...] - Have your binary chmod 4750 - with uid 0 (thus the setUID) and - group whateveryournewgroupname In debian/postinst that would look like: chmod 4750 $BINARY chown 0:$GID $BINARY where $GID is the group id of the group you create in postinst. That will make sure it gets the UID 0 correctly so that nice(2) will work ok and also will make sure that only users of the group are allowed to execute it. [...] I think that if we need to create a new group may be some non-expert users won't be able to run eviacam properly (i.e. they might fail to add their username to such group). Other options include: i) ask the user whether to make eviacamloader SUID and explain that a new group is needed and such and such. Can be done with debconf quite easily as: a) Ask whether SUID should be activated Done. Package uploaded. b) which users should be added to the group interactively I would need some help here. Can you point a good document (or better, an example) on how to interactively add users to a group using debconf? Please set sensible defaults so that you can also work with DEBCONF_FRONTEND=noninteractive The default option is to *NOT* use SUID. ii) completely get rid of the SUID thing at the expense of less responsiveness. If that's possible and doesn't limit core functionality it sounds like a valid option. What downsides would that bring? The core functionality is exactly the same. The only downside is that eviacam won't work as smooth as if it were running in high priority (i.e. the user might notice that the mouse pointer is less responsive when CPU load is high). I think debconf as explained above together with properly adding a new group and importing users through debconf would be a good thing. Agreed. But some help needed :-). Thanks. Regards, César -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e39af06.9070...@crea-si.com
Re: acsccid (Updated)
Hi Godfrey, On Tue, Aug 02, 2011 at 11:53:45AM +0800, Godfrey Chung wrote: I just updated debian/copyright. Please have a look. Thanks! Thanks for your work. Having a first look myself at your package I find: 1. You build-depend on autotools-dev but don't use it in debian/rules' dh call. Please add it to dh. 2. Your patch lacks a DEP-3 header indicating where this patch came from and whether upstream was notified of this to support their development in case it wasn't pulled from there. 3. Your override_dh_auto_install target in debian/rules lacks a tab (to make syntax highlighting happy) and more importantly you override override_dh_makeshlibs without any rationale I could see. Please put a comment why this is needed or remove the override. 4. Regarding the mv and symlink you may want to talk to upstream about supporting sysconfdir in a proper way. I think they will find it helpful to learn that FHS doesn't foresee /usr writeable and thus suitable for config files. 5. The debian/rules template header can be omited too. 6. The name libacsccid does not follow the recommended naming scheme for libraries. It should be libacsccid102 or something alike. See [1] for details. 7. Building your package I still see: udev support:no This seems not to be the intended output looking at the udev rules file. There is no Depends on udev too however. Are you sure that the built package works ok if built in a clean pbuilder? 8. The upstream changelog is not shipped in the binary package. Please consider adding it too. [1]: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: mpd-sima (updated package)
Hi Geoff, On Wed, Aug 03, 2011 at 09:47:47PM +0200, Geoffroy Youri Berret wrote: Thanks for your review :) Le 03/08/2011 18:29, Kilian Krause a écrit : On Mon, Aug 01, 2011 at 04:42:15PM +0200, Geoffroy Youri Berret wrote: I gentle ping on this package :) I moved the packaged to Debian Multimedia Maintainers. git://git.debian.org/pkg-multimedia/mpd-sima.git I believe the package to be in pretty good shape now. […] 1.) You build-depend on bash-completion. What for? Moreover you build-depend on python-all which huge compared to what you will actually need IMHO. Why not limit that more to what is actually required? [bash-completion] I need bash-completion because it provides dh_bash-completion. It'll handle debian/mpd-sima.bash-completion properly. Right. See that now. ;-) [python-all] Well, I think need python 2.6 and python 2.7, I guess then I could save python 2.5 setting a build depends on python2.6 instead of python-all. But isn't “python-all (= 2.6.6-3~)” similar? Ok, in that case I guess I can consider your solution a good solution. I was hoping that you only need some few modules to build and reducing to only these modules with reducing the amount of build-depends (looking at the whole tree) in mind would make sense. I'll have your word for it that this isn't an option. [...] “4.)” somehow disappeared ^^ Yes, that was a criticism that didn't sustain a second look. ;-) [...] I've uploaded a new version, tagged 0.8.0-1, to mentors. I haven't pushed to the git repo yet. http://mentors.debian.net/debian/pool/main/m/mpd-sima/mpd-sima_0.8.0-1.dsc Very good. Built, Signed, Uploaded. Please don't forget to update your git (including retagging the 0.8.0-1 and deleting a eventually existing -2 tag). -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: wizznic
Hi Edgar, On Wed, Aug 03, 2011 at 04:53:44AM -0500, Edgar Antonio Palma de la Cruz wrote: El Tue, 02 Aug 2011 09:21:23 +0200 Ansgar Burchardt ans...@debian.org escribió: Adam Borowski kilob...@angband.pl writes: Right, I missed the .o and .dll files, counting only wizznic-x86-precompiled and tools/releaser/data/win/curl/curl.exe (the ones mentioned by lintian). The dlls are libjpeg, zlib, libogg, SDL, openssl -- all DFSG free with source already in main. The source would need to be included in the same (source) package to make sure that it is the same version and that we will still include source even if another package is removed from the archive. Ansgar I get a little confused about what I do with the dfsg, I should remove the binaries or add a the source of them? There seems to be somewhat different oppinions on this. Mine is: remove all binary files whether they can be compiled from source or not and strip the source down to the largest set of source files that can still reliably build your binaries. Problem with the binary files is that it's close to impossible to reliably know how and by whom they were built and what license they come with. The problem of people being able to run potentially malicious code is another (usually for this conext minor) problem. If you can - with respect to ensuring a DFSG-free license - leave them in the tarball and document them (and potentially put a check into d/rules looking after them not being tainted - how ever that may look like) that'd be an option. Yet as said IMHO it's practically close to impossible to debug a windows binary set with regards to libraries linked into there etc. at build time of a Debian package. Also, I need to modify the d/copyright, d/changelog, d/watch make README.debian-source, orig.tar.bz2 and add a rule get-orig-source to d/rules to make a _good_ dfsg repackage? Yes, that should do it. -- Best regards, Kilian signature.asc Description: Digital signature
RFS: ndpmon
Dear mentors, I am looking for a sponsor for my package ndpmon, * Package name : ndpmon Version : 1.4.0-1 Upstream Author : frederic.b...@loria.fr * URL : http://ndpmon.sourceforge.net/index.html * License : LGPL 2.1+ Section : net It builds these binary packages: ndpmon - IPv6 Neighbor Discovery Protocol Monitor The upload would fix these bugs: 635975 My motivation for maintaining this package is: We are starting to implement IPv6 at Penn State Harrisburg, and I wanted a tool like arpwatch to monitor IPv6 workstations. I think this tool will be useful to others who need to implement IPv6. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/n/ndpmon - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/n/ndpmon/ndpmon_1.4.0-1.dsc I would be glad if someone uploaded this package for me. -- John R. Baskwill, jr...@psu.edu Systems Analyst, Information Technology Services Penn State Harrisburg W303 Olmsted Building 777 West Harrisburg Pike Middletown, PA 17057-4898 Phone: 717-948-6268 Fax: 717-948-6535
Re: RFS: autotrace (updated package)
Hi Edgar, On Thu, Jul 28, 2011 at 05:23:04AM -0500, Edgar Antonio Palma de la Cruz wrote: I am looking for a sponsor for the new version 0.31.1-16 of my package autotrace. - dget http://mentors.debian.net/debian/pool/main/a/autotrace/autotrace_0.31.1-16.dsc Thanks for your work. Cleaning up is a good thing yet the oldpatches.patch looks like it catches more than it should: AUTHORS |2 Makefile.am |4 Makefile.in | 914 - README|2 aclocal.m4| 8966 +-- autotrace.1 |4 autotrace.h |4 autotrace.pc.in |4 config.h.in |3 configure |25257 +- configure.in | 91 curve.c |4 fit.c |3 ltmain.sh | 3665 +-- main.c| 10 output-pdf.c | 16 output-pstoedit.c |2 output-pstoedit.h |2 18 files changed, 28530 insertions(+), 10423 deletions(-) Especially the configure, aclocal.m4 and ltmain.sh look like a too large change. Can you see if really *ALL* of this is required and cut that patch down to a more readable size? If you want to you can also plit it apart into logical units with individual explanations why they are (still) needed. There may also be parts of this which still need to be pushed back upstream. Reviewing it in this shape is quite teadious however. And documenting even more so if they satisfy different motivations. In some respect it may even be more helpful to add dh-autoreconf (even though I quite dislike its use in general). Even more so when I see the old d/rules had pretty much a full autoreconf run as part of the default packaging which makes me guess this was causing the updates we now see in the diff making them totally irrelevant to the bugfix the original author had in mind. Thanks! -- Best regards, Kilian signature.asc Description: Digital signature
