Re: Shared libs dependencies
Charles Plessy ple...@debian.org writes: Le Fri, Sep 23, 2011 at 01:54:51PM +0200, Gergely Nagy a écrit : zlib uses versioned symbols, a similar, but more... advanced thing. Perhaps the manual should be updated to point to a simple package that does use shlibs still. Actually, symbols files are really easy to use with Debhelper. One thing to remember is to create an empty symbols file before runnign dh_makeshlibs, otherwise it will not produce a patch. It's easy to use when you know what they're for, and understand them. If you don't, it's a recipe for disaster. Just because getting something out of dh_makeshlibs is easy, it does not mean that it's definitely correct and can be used as-is (for simple cases, it could, but it's not always so). Eg, if a library has different symbols on different architectures, the above method will not work. If a symbol is removed in a later version (and the soname is not bumped, due to a mistake), the above method will result in a library that, when installed, will break any app using the old, removed symbol. So, unless one understands how and why symbols files (and shared libraries in general) work, and what they're good for, and what to pay attention to when packaging, I would strongly recommend against blindly trying to get it work. It will break, sooner or later, and you'll have to clean up the mess. -- |8] -- 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/877h4y8ief@luthien.mhp
Re: Shared libs dependencies
On 2011-09-23 15:18, Jakub Wilk wrote: * Ole Streicher debian-de...@liska.ath.cx, 2011-09-23, 15:08: I have the feeling, that lintian is quite lazy about shared libs; at least it does not complain about a missing shlibs file. Of course it does. dh_makeshlibs generates such a shlibs file for you in your build if you do not have one, which is probably why you do not see a complaint from Lintian. ~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/4e7d964f.8060...@thykier.net
Re: Shared libs dependencies
On 2011-09-24 10:16 +0200, Gergely Nagy wrote: If a symbol is removed in a later version (and the soname is not bumped, due to a mistake), the above method will result in a library that, when installed, will break any app using the old, removed symbol. Erm, this will also happen if you don't have symbols files. In fact, using symbols files together with dpkg-gensymbols -c4 catches this kind of mistake. Sven -- 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/87ehz6ib5h@turtle.gmx.de
Re: Shared libs dependencies
Sven Joachim svenj...@gmx.de writes: On 2011-09-24 10:16 +0200, Gergely Nagy wrote: If a symbol is removed in a later version (and the soname is not bumped, due to a mistake), the above method will result in a library that, when installed, will break any app using the old, removed symbol. Erm, this will also happen if you don't have symbols files. In fact, using symbols files together with dpkg-gensymbols -c4 catches this kind of mistake. Yes. And you will catch it if you know what you're doing. If you don't, you won't, simple as that. I'm not saying you can't catch things like that, I'm saying that if you don't know this can happen, it's very likely you won't catch them. And if one just blindly follows whatever dh_* stuff spews out, without understanding what and why they do, the chances increase. That's all I'm saying: use the tools, but don't blindly trust them. -- |8] -- 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/87y5xe71vd@luthien.mhp
Re: Shared libs dependencies
Not using symbols files will give you almost always too strict dependencies,
usually forcing users to also upgrade libraries without need, but
everything dpkg will not complain about will work (assuming a sane
upstream not breaking ABI without changing sonames).
Using symbols files means the dependencies are less tight, one gets some
basic checks against upstream failing to keep ABI, but the burden is on
the maintainer to know when the ABI changed backward-compatible but not
forward-compatible in existing symbols.
* Sven Joachim svenj...@gmx.de [110924 10:43]:
Erm, this will also happen if you don't have symbols files. In fact,
using symbols files together with dpkg-gensymbols -c4 catches this
kind of mistake.
The real problem with using symbol files without understandin them is
something like the following examples:
--- example 1
liba 1.0.0:
/usr/include/a.h:
enum command {
command_start,
command_stop
};
extern void do(enum command);
liba 1.1.0:
/usr/include/a.h:
enum command {
command_start,
command_stop,
command_restart
};
extern void do(enum command);
someprog:
checking for command_restart in configure and then in the source
#ifdef HAVE_COMMAND_RESTART
do(command_restart);
#else
do(command_stop);
do(command_start);
#endif
There is no symbol changed in liba, so the symbols file for liba 1.1.0
will still say 1.0.0 for do. But if you compile someprog with the newer
liba, it will give 2 to do, which the older liba does not understand,
so the symbols file is incorrect.
--- example 2
I think I've already seen a scheme like the following somewhere:
libb 1.0.0:
/usr/include/b.h:
struct data {
size_t size;
void *value;
};
#define init_data(d) ({ d.size = sizeof(d); d.value = NULL; })
void do(struct data *);
libb 1.1.0:
/usr/include/b.h:
struct data {
size_t size;
void *value;
bool reverse;
};
#define init_data(d) ({ d.size = sizeof(d); d.value = NULL; d.reverse =
false })
void do(struct data *);
A scheme like this (the #define is only here to show how it is used,
that might also be part of documentation) is a nice way to support
adding fields without breaking the ABI: a program compiled against the
old value gives the old size, the new library can cope with that and
does not need to change the soname. But of course if something is
compiled with the new version, it gives a value the old version cannot
handle.
But again dpkg-symbols can see no difference, so if just applying the
patches dpkg-symbols generates means the symbols file will still think
libb 1.0.0 is enough when only calling do.
Bernhard R. Link
--
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/20110924100441.gb...@server.brlink.eu
Re: Package separation/naming conventions
Charles Plessy ple...@debian.org writes: Le Fri, Sep 23, 2011 at 04:13:42PM +0200, Ole Streicher a écrit : the wcslib exists under this name already for some years, and is always referenced under this name. Changing the name to libwcs would confuse people with the older libwcs library (which is incompatible). Dear Ole, although it looks ugly, perhaps you can consider calling your binary packages libwcslib4, libwcslib-dev, libwcslib-doc and wcslib-util. The first problem is that the library package should be called after its SONAME, and I dont want to change the SONAME because I would break the linking of existing programs. This is the reason why the library package is going to be called libwcs4. For the -dev and -doc packages, I see no reason to add a second lib to their name: why libwcslib is better than wcslib? These names differ from the library SONAME anyway. As you noted, users are unlikely to have to install libwcslib by hand. Developers will find libwcslib-dev easily with apt-cache, and the description of your package will present its contents clearly. Yes, that's why it may be not so ugly to have a different name for the library. Best regards Ole -- 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/874o02nst4@news.ole.ath.cx
Re: Shared libs dependencies
On Sat, Sep 24, 2011 at 6:04 PM, Bernhard R. Link wrote: The real problem with using symbol files without understandin them is something like the following examples: Do you know if the abi-compliance-checker program/package copes with this case? -- bye, pabs http://wiki.debian.org/PaulWise -- 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/caktje6fgz3fc0atxbmh72bqi81bwea6n7uhvh9sdqdm4uuv...@mail.gmail.com
Re: Package separation/naming conventions
Le Sat, Sep 24, 2011 at 12:22:31PM +0200, Ole Streicher a écrit : Charles Plessy ple...@debian.org writes: although it looks ugly, perhaps you can consider calling your binary packages libwcslib4, libwcslib-dev, libwcslib-doc and wcslib-util. The first problem is that the library package should be called after its SONAME, and I dont want to change the SONAME because I would break the linking of existing programs. This is the reason why the library package is going to be called libwcs4. For the -dev and -doc packages, I see no reason to add a second lib to their name: why libwcslib is better than wcslib? These names differ from the library SONAME anyway. I think I am confused in what names you want to avoid, for which packages. In summary: * The name given at http://www.atnf.csiro.au/people/mcalabre/WCS/wcslib/ is wcslib. That is a good name for your source package. * If libwcs4 matches the SONAME of your library, this is good. If you think that the confusion with the other libwcs will induce people in wasting their time with the wrong package, then alternatives based on the source package's name, like wcslib or libwcslib, are possible. The naming policy is a should that is to be everybody's advantage. There can be good reasons to disregard a recommendation (but I would recommend to documment them somewhere). * I think that it will make things simpler if the -dev package is named after the runtime package. For instance libwcs4 / libwcs-dev. This helps to quickly understand the relationship between a source package's build dependancies, and a binary package's depandancies. I would find it confusing if building against barfoobaz-dev results in depending on libbarf instead of barfoobaz. * For -tools or -docs, I think that the choice for the names isopen, but the best choices would be to append these suffixes to either the library's binary package name or the source package name. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20110924112225.ga21...@merveille.plessy.net
E helper-templates-in-copyright
Dear list, when I tried uploading my package, the server's lintian gave me an error that I did not have on my local system http://mentors.debian.net/package/wcslib: E: libwcs4: helper-templates-in-copyright The help text suggests that the copyright file is still (almost) a template. However, I think that I changed it according to the package's needs: 8 This work was packaged for Debian by: Ole Streicher deb...@liska.ath.cx on Wed, 14 Sep 2011 16:31:30 +0200 It was downloaded from http://www.atnf.csiro.au/people/mcalabre/WCS/ Upstream Author(s): Mark Calabretta mcala...@atnf.csiro.au Copyright: Copyright (C) 1995-2009, Mark Calabretta License: LGPL-3 WCSLIB 4.4 - an implementation of the FITS WCS standard. Copyright (C) 1995-2009, Mark Calabretta WCSLIB is free software: you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. WCSLIB is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with WCSLIB. If not, see http://www.gnu.org/licenses/. Correspondence concerning WCSLIB may be directed to: Internet email: mcala...@atnf.csiro.au Postal address: Dr. Mark Calabretta Australia Telescope National Facility, CSIRO PO Box 76 Epping NSW 1710 AUSTRALIA The Debian packaging is: Copyright (C) 2011 Ole Streicher deb...@liska.ath.cx and is licensed under the GPL version 3, see `/usr/share/common-licenses/GPL-3'. 8 What is wrong with this copyright that the server's lintian doesn't accept it? Best regards Ole -- 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/87zkhuma3s@news.ole.ath.cx
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/23/2011 03:54 AM, Daniel Kauffman wrote:
On 09/22/2011 02:38 AM, Thomas Goirand wrote:
On 09/22/2011 03:32 PM, Daniel Kauffman wrote:
I didn't see a reference to quilt in the Debian Policy Manual and the
Debian New Maintainers' Guide section 2.9 seems to suggest that a
native package is ok where there is no upstream.
No. It's ok to do so when the software is intended only for
Debian (like, the Debian installer for example... I'm not even
sure that's the case, just an example), which isn't your case.
Thanks for the clarification regarding native vs. quilt, rebuilt using
quilt. The updated package can be downloaded from:
http://socketpolicyserver.com
Hi Daniel,
Since I reviewed once your package, I feel like I have to do it again,
and continue the mentoring process. So let me do again, this time
more deeply.
1/ debian/changelog
Since your package has never reached Debian yet, your changelog
should be only:
libapache2-mod-socket-policy-server (0.0.1) unstable; urgency=low
* Initial release. (Closes: #642282)
-- Debian Packaging Team
debian-packaging-t...@socketpolicyserver.com Tue, 20 Sep 2011
21:25:00 -0800
So please remove all other entries.
We don't really care what upstream version you use, so it could be
0.0.4-1 if you feel like it, and if it's more convenient for you to not
downgrade in your repository.
Also, it seems that your /changelog is the same as what's in the
debian/changelog, and you are packaging it twice!!! My advice
here: write things in /changelog that are only for upstream code,
and in debian/changelog only things that concerns the packaging
itself and nothing else.
2/ debian/copyright
It's basically not respecting the specifications. It should be
something like:
header paragraph
files paragraph
[license paragraph]
Your copyright file doesn't have a header. Also, I think that
something like this:
License: Other
For alternate licensing arrangments, please contact:
.
licens...@rocksolidinnovations.com -OR- sa...@rocksolidsolutions.org
isn't appropriate and doesn't fit the spirit of DFSG (I may be wrong
here, I have never been really good with licenses, but I just feel
it isn't right). Especially, on the Apache 2.0 license, it says:
THIS SOFTWARE MAY NOT BE USED EXCEPT UNDER LICENSE,
then just later, you are writing that alternate licensing arrangments
could be made...
Just leaving the Apache 2.0 license, which give a
very big amount of freedom, seems enough to me. I fail to see
how it could be more free than with the Apache 2.0 license! :)
3/ debian/patches/debian-changes
Don't you think that a Debian specific patch could be avoided?
Basically, there's only 2 things that are done in the debian-specific
Makefile: build and install. These could easily be put in your
debian/rules by overriding the dh install and build target (namely,
if I'm not mistaking, dh_auto_install and dh_auto_build). That
would be a lot more simple than having to manage a patch like this.
Not that this is just a suggestion, what you did works also, I just
think it's a bit over-engineered, and that overriding the dh rules
targets would be more simple to maintain.
4/ debian/postinst
While it's fine to automatically install a site in sites-available,
and install and activate a .load Apache module, actually activating
the default vhost that you created might not be appropriate,
especially since what you are doing is activating a policy with
site-control permitted-cross-domain-policies=none / in it.
Am I right that basically, it will do the same as if nothing was
done at all, and make it completely restrictive?
5/ Your package doesn't build twice
That's the worst issue of your package. Running dpkg-buildpackage
twice in a raw fails with some error: cannot represent change.
This most of the time happens when the clean target is wrong.
Please fix this.
6/ debian/watch file
Please add a watch file. It would be quite easy to write, since
you are using Apache directory listing. Something like this
will do the trick:
version=3
http://socketpolicyserver.com/downloads/libapache2-mod-socket-policy-server_(.*).orig.tar.gz
7/ debian/control
Are you sure that this is accurate:
Maintainer: Debian Packaging Team
debian-packaging-t...@socketpolicyserver.com
And don't you think that just:
Daniel Kauffman debian-packaging-t...@socketpolicyserver.com
wouldn't be better? I mean, is there really a team behind this
Debian packaging? I'm not saying this is bad to write what you
did, just that it's always better to have something that reflects
reality (and this is just a suggestion, nothing really bad).
I can read:
Depends: ${misc:Depends}, ${shlibs:Depends}, apache2 | apache2-mpm,
apache2.2-common
But apache2 depends on apache2.2-common, and so are all
the apache2.2-mpm-* packages that are providing apache2.2-mpm,
so I guess that depending on apache2.2-common is useless here
(if you don't think so, feel free to correct me).
I think that's it for the moment. Let me know when you've
Re: E helper-templates-in-copyright
Hi, Le samedi 24 sept. 2011 à 13:51:51 (+0200 CEST), Ole Streicher a écrit : Dear list, when I tried uploading my package, the server's lintian gave me an error that I did not have on my local system http://mentors.debian.net/package/wcslib: E: libwcs4: helper-templates-in-copyright The help text suggests that the copyright file is still (almost) a template. However, I think that I changed it according to the package's needs: 8 This work was packaged for Debian by: Ole Streicher deb...@liska.ath.cx on Wed, 14 Sep 2011 16:31:30 +0200 It was downloaded from http://www.atnf.csiro.au/people/mcalabre/WCS/ Upstream Author(s): ^ If there's only one author, why keep this? Maybe it is not the only thing to be changed to fix this lintian error, but that should already help. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- 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/20110924115652.ga14...@kirya.net
Re: E helper-templates-in-copyright
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 24.09.2011 13:56, Julien Valroff wrote:
Upstream Author(s):
^
Yes, that's the problem. Lintian checks the following patterns:
if (m,\fill in (?:http/)?ftp site\,o or
m,\Must follow here\,o or
m,\Put the license of the package here,o or
m,\put author[\'\(]s\)? name and email here\,o or
m,\Copyright \(C\) Name OfAuthor\,o or
m,Upstream Author\(s\),o or
m,\years\,o or
m,\special license\,o or
m,\Put the license of the package here indented by 1 space\,o or
m,\This follows the format of Description: lines in control file\,o or
m,\Including paragraphs\,o or
m,\likewise for another author\,o) {
tag 'helper-templates-in-copyright';
}
Its not exactly obvious, the Author(s) shall be replaced though, I admit.
Moreover you eventually want to use DEP-5 instead, please see [1]. DEP-5
is required for many sponsored maintainers from their sponsors, but no
global Debian requirement.
[1] http://dep.debian.net/deps/dep5/
- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJOfcaBAAoJEMcrUe6dgPNtazIQAJKiRsSSxX0+7VrmM0aCRNrv
djsLiAM9SHRBfLcA6GAxDRyylhEfb7s3xvHZjI02IYaiXFyL9BkKy45CJydsjJM6
oKu8xE9pbMK8d2vSo9RQOZdkU/nMRrrUimAIiAeXsk/jSEId0x3v/h8HBvjHhPF9
PL2NEf/T1Y+SQdpKcboRWPUBxUpfSuk9xCN5cfZXVtjv9xyJRA2YTMTRErpQ207w
DOKYCt6iIdkvHt+bIo8zCebkkAbIGsEkTSekZCmH1+NBQgCqj7+C/Ynzhi4kh+6t
SeTWuHWcvQgDonAeugBHMQo3iY+aGtaztUhNq0ycta1q3c2XUmG0Mxei1Nlf9YUW
Y/GVfqL3+T64pAVtWD5ND7MX25RDUoYWcX5QaA8/PYxyuaIprTSOwleF58OWG0ML
pjUaM2dlpudcPNa147Q+BEFVvoBhRMTMpR4fd2WltWtTknLIhIHPSpNhZIm+uCWf
5r4CdJuZYDQH7uf0Wtgn+YFN3w338YymtG8kx35awe1thP9dvTObhyWBe+swO4Dk
AGxn7U0OOSZCTTFIqbOp7ngEj8loUGcVwOgYvBNQVO/l+m+DsKbmGeN9AbdWIGHQ
rMlDubXTovZVTS7tPabOOucKrPgzTV6CnnHSVeWNjpgvfouZRZxU2tHe2f3le1iN
gZ/jKSJN71FWV08Ycdf9
=t+b+
-END PGP SIGNATURE-
--
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/4e7dc682.6090...@toell.net
Re: E helper-templates-in-copyright
Arno Töll deb...@toell.net writes: Moreover you eventually want to use DEP-5 instead, please see [1]. DEP-5 is required for many sponsored maintainers from their sponsors, but no global Debian requirement. OK, I am changing the copyright to this file. This looks better to me than the pseudo-freetext that it was before. Best Ole -- 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/87vcsim928@news.ole.ath.cx
RFS: wcslib
Dear mentors, I am looking for a sponsor for my package wcslib. * Package name: wcslib Version : 4.8.1-1 Upstream Author : Mark Calabretta mcala...@atnf.csiro.au * URL : http://www.atnf.csiro.au/people/mcalabre/WCS/ * License : LGPLv3+ Section : science It builds those binary packages: libwcs4- Implementation of the FITS WCS standard wcslib-dev - Header files and static library for wcslib wcslib-doc - API documentation for wcslib wcslib-tools - Command line tools utilizing wcslib To access further information about this package, please visit the following URL: http://mentors.debian.net/package/wcslib Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/w/wcslib/wcslib_4.8.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Ole Streicher -- 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/87r536m8ns@news.ole.ath.cx
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
Thomas Goirand z...@debian.org writes: That's the worst issue of your package. Running dpkg-buildpackage twice in a raw fails with some error: cannot represent change. This most of the time happens when the clean target is wrong. Please fix this. You can use ‘pbuilder --build --twice’ to test this on your own machine. Please install and learn the ‘pbuilder’ tool to have a good way of performing many useful build tests. Please add a watch file. It would be quite easy to write, since you are using Apache directory listing. Something like this will do the trick: version=3 http://socketpolicyserver.com/downloads/libapache2-mod-socket-policy-server_(.*).orig.tar.gz The current recommendations tighten the regex for the version string, to be sure not to match an empty string: version=3 http://socketpolicyserver.com/downloads/libapache2-mod-socket-policy-server_(.+).orig.tar.gz Are you sure that this is accurate: Maintainer: Debian Packaging Team debian-packaging-t...@socketpolicyserver.com And don't you think that just: Daniel Kauffman debian-packaging-t...@socketpolicyserver.com wouldn't be better? Even if it is a team, please use the actual name of the team; “Debian Packaging Team” is clearly not helpful to distinguish which team is being referenced. -- \ “Whenever you read a good book, it's like the author is right | `\ there, in the room talking to you, which is why I don't like to | _o__) read good books.” —Jack Handey | Ben Finney -- 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/8762ki13jx@benfinney.id.au
Re: Shared libs dependencies
* Paul Wise p...@debian.org [110924 12:42]: On Sat, Sep 24, 2011 at 6:04 PM, Bernhard R. Link wrote: The real problem with using symbol files without understandin them is something like the following examples: Do you know if the abi-compliance-checker program/package copes with this case? I don't know, but I'd rather be suprised. If it is good, it will most likely report a compatible extension of the library's ABI in those cases (i.e. the same with those changes that dpkg-symbols handles perfectly automatically). To distinguish this case (a compatible extension of ABI where just applying the patch suggested by dpkg-gensymbols can lead to incorrect dependencies) from the case where dpkg-gensymbol's output is enough, I guess it would explicitly have some tests written with dpkg-symbols' case in mind. (Otherwise I see no reason to warn louder about those changes not adding symbols in a path to use them than against those that do). Bernhard R. Link -- 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/20110924175312.gc2...@server.brlink.eu
I can not register.
I tried to register as described in: http://mentors.debian.net/intro-maintainers I filled out the form at: http://mentors.debian.net/register/register Then it sent me an email. but when I visited the page indicated by the email it said: Internal error 404 Help I need to register to send my package so people can find fault with it! -- Paul Elliott 1(512)837-1096 pelli...@blackpatchpanel.com PMB 181, 11900 Metric Blvd Suite J http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117 signature.asc Description: This is a digitally signed message part.
Re: I can not register.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Paul, On 24.09.2011 21:29, Paul Elliott wrote: Help I need to register to send my package so people can find fault with it! Could you forward me your registration mail? Please don't post the full URL publicly though as it contains your double-opt-in activation string. (Would you trust me, if I claim it is ok to forward me the mail though?) - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOfkE/AAoJEMcrUe6dgPNty/IQAMtllhXoHMxsnS/S5QJEUY57 4iEShwovIRqwifkCtZ0IFcwEqQWIAwPKj2tjHej8nrw4nVSCIHdGoGQy4n29zhuE BoPuh3DdzUchoJBN+qtaLHOj3RtfIuXxK7s1puK7z3BHsm/4XbywDvTSZoqA67cz jNdHa89AhPbS4Vr8t8Vp8lgaJs65aDbtnCjCy+Xdi1vC65zn+V9XsReJi9F1wIpH C+NfiVo9+U6vmzgDkwDZHTcdt7Rg0iMpjzqkXXAxU5/jeZWK98tDoY8aimgST4t2 RDXxIWa3SPuj85aDeS6dVYVhpoi9gKlNNhGmg6z6eRibGNAS5Ywrkcu3RDNQ5Ew2 PycFVQAD6EhLqZRnK574B6jyHCnJrOgIfaRtb9R+TClVk/hMxoLEklFfexxaCk1a Dt8q3oLRR738BI3zlAYJjQAqLMkAHob0cZzzpShNgsLahBUWYDD7QXYl8o8/QwjW vt9ymkIAx/EezTdrdPlhPQJkszCszAPH0wDDXxCMUL79VjmaWG9zaTo9soYZOwIc uw1CFhi7K02Ac4R+Gzvk6UapUjgNdS4VHiIwUrTiND9vy+gVtqnxdouJb5D9F3iq 8loNPes5MfYSAQ3psG4Jd2gf8oGWBnopwo2avYFEpCP4eKbU3f6cc8T3i+jfNWpC ctbyo9VNmFbie/4H02Mo =7XnV -END PGP SIGNATURE- -- 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/4e7e4140@toell.net
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/24/2011 04:37 AM, Thomas Goirand wrote:
Since I reviewed once your package, I feel like I have to do it again,
and continue the mentoring process. So let me do again, this time
more deeply.
Thanks Thomas, I appreciate your input.
1/ debian/changelog
please remove all other entries.
Done.
My advice
here: write things in /changelog that are only for upstream code,
and in debian/changelog only things that concerns the packaging
itself and nothing else.
Done.
2/ debian/copyright
I believe format is now proper DEP-5.
I fail to see
how it could be more free than with the Apache 2.0 license! :)
I agree that the Apache 2.0 license is a great license! However, I fail
to see how the spirit of the DFSG -- giving people freedom and choice --
is in any way violated by offering alternate licensing to those for whom
a particular license is unacceptable, for whatever reason. Personally, I
feel that the Apache 2.0 license is perfectly acceptable, but others are
free to disagree, and I don't see an issue with making the software
available to them as well. But I could be wrong here about the DFSG, and
would appreciate clarification if I am.
Meanwhile, I removed the alternate licensing stanza.
3/ debian/patches/debian-changes
overriding the dh rules
targets would be more simple to maintain.
Makes sense. Thanks. Done.
4/ debian/postinst
While it's fine to automatically install a site in sites-available,
and install and activate a .load Apache module, actually activating
the default vhost that you created might not be appropriate,
especially since what you are doing is activating a policy with
site-control permitted-cross-domain-policies=none / in it.
Am I right that basically, it will do the same as if nothing was
done at all, and make it completely restrictive?
The default configuration activates a policy that is slightly more
restrictive than the default policy in Flash.
The benefits are that:
* The configuration is secure by default.
* The default configuration gives the system administrator a working
configuration out-of-the-box. Testing a non-standard protocol can
be difficult, and this eases entry.
The drawbacks are that:
* A VirtualHost is enabled by default. I'm not sure if this is a
comparable situation, but the default Apache2 install configures
and enables a default site.
I think that the drawbacks are mitigated in that:
* The VirtualHost is enabled only for port 843.
Any ideas for a better approach? I think is important to be able to
easily verify a working configuration, before modifying that
configuration. Any thoughts?
5/ Your package doesn't build twice
Fixed. Tested with pbuilder --twice
6/ debian/watch file
Please add a watch file.
Done. Tested with uscan
7/ debian/control
Are you sure that this is accurate:
Maintainer: Debian Packaging Team
debian-packaging-t...@socketpolicyserver.com
My thought here is that I want this address to be useful for maintaining
the project long-term. The business is responsible for the project, not
me personally, and I thought it best to reflect that in the maintainer
field.
Depends: ${misc:Depends}, ${shlibs:Depends}, apache2 | apache2-mpm,
apache2.2-common
But apache2 depends on apache2.2-common, and so are all
the apache2.2-mpm-* packages that are providing apache2.2-mpm,
so I guess that depending on apache2.2-common is useless here
(if you don't think so, feel free to correct me).
I agree is duplicated and would likewise prefer the simpler form... I
included apache2.2-common per the guidelines on:
http://wiki.debian.org/Apache/PackagingModules
Do you know if would be better to remove the dependency or to defer to
those guidelines?
I think that's it for the moment. Let me know when you've
processed all the above issues, and I'll review your package
once more.
Alright, will upload an updated package as soon as have clarification
about the default configuration. Meanwhile, in case it would be helpful,
I uploaded a package reflecting the changes so far.
Then I'd prefer if another DD that did some apache module
packaging had a last look before I sponsor the package for you
(because I may well have missed something).
Sounds good, extra eyes are always appreciated, especially when dealing
with network services.
Cheers,
Thomas Goirand (zigo)
--
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/4e7e72b0.8060...@rocksolidsolutions.org
Re: RFS: libapache2-mod-socket-policy-server (an Apache2 module for serving Adobe socket policy files)
On 09/24/2011 06:18 AM, Ben Finney wrote: You can use ‘pbuilder --build --twice’ to test this on your own machine. Please install and learn the ‘pbuilder’ tool to have a good way of performing many useful build tests. Thomas Goirand pointed out the pbuilder tool to me, is quite helpful, and thank you for the tip about the --twice flag, I am now using that as the default for my local build script. Please add a watch file. The current recommendations tighten the regex for the version string, to be sure not to match an empty string: version=3 http://socketpolicyserver.com/downloads/libapache2-mod-socket-policy-server_(.+).orig.tar.gz Done. Maintainer: Debian Packaging Team debian-packaging-t...@socketpolicyserver.com Even if it is a team, please use the actual name of the team; “Debian Packaging Team” is clearly not helpful to distinguish which team is being referenced. I re-read the Debian Policy Manual section 3.3 and I'm not sure how to make this any better, since: Debian Packaging Team debian-packaging-t...@socketpolicyserver.com Is accurate and unique globally, and: Debian Packaging Team Is accurate and unique within the business. -- Daniel Kauffman Lead Developer Rock Solid Solutions, LLC 877.239.9195 toll-free 208.699.9699 mobile -- 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/4e7e7330.3050...@rocksolidsolutions.org
