RFS: fsprotect (try #2)
Dear mentors, A month ago I sent the following RFS without anyone offering to sponsor it. I'm resending it as a reminder. I am looking for guidance and a sponsor for my package fsprotect. * Package name: fsprotect Version : 1.0.1 Upstream Author : Stefanos Harhalakis v...@v13.gr (me) * URL : http://www.v13.gr/proj/fsprotect/ * License : GPL Section : admin It builds these binary packages: fsprotect - Helper scripts to make filesystems immutable The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fsprotect - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/fsprotect/fsprotect_1.0.1.dsc This is a set of scripts that combine aufs and tmpfs and make the root and other filesystems immutable. Existing filesystems are re-mounted as read-only and all changes are written to tmpfs and are lost at the next reboot. It is ideal for: * Public computers. It keeps all files intact, no matter what the user does. * Testing. i.e. KDE3 - KDE4 upgrade * Security (also requires adequate paranoia) Fsprotect can be seen as an opensource alternative to deepfreeze for linux. Kind regards Stefanos Harhalakis -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fsprotect (try #2)
Hello, 2009/4/21 Stefanos Harhalakis v...@v13.gr: Dear mentors, A month ago I sent the following RFS without anyone offering to sponsor it. I'm resending it as a reminder. I am looking for guidance and a sponsor for my package fsprotect. * Package name : fsprotect Version : 1.0.1 Upstream Author : Stefanos Harhalakis v...@v13.gr (me) * URL : http://www.v13.gr/proj/fsprotect/ * License : GPL Section : admin It builds these binary packages: fsprotect - Helper scripts to make filesystems immutable The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/fsprotect - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/fsprotect/fsprotect_1.0.1.dsc This is a set of scripts that combine aufs and tmpfs and make the root and other filesystems immutable. Existing filesystems are re-mounted as read-only and all changes are written to tmpfs and are lost at the next reboot. It is ideal for: * Public computers. It keeps all files intact, no matter what the user does. * Testing. i.e. KDE3 - KDE4 upgrade * Security (also requires adequate paranoia) Fsprotect can be seen as an opensource alternative to deepfreeze for linux. feedback 1. why this package is a native package? i think a normal package should be better 2. one lintian warning: W: fsprotect source: out-of-date-standards-version 3.8.0 (current is 3.8.1) 3. can you explain why you override the following lintian warnings $ cat debian/fsprotect.lintian-overrides fsprotect: non-standard-toplevel-dir fsprotect/ fsprotect: virtual-package-depends-without-real-package-depends fsprotect: package-contains-empty-directory fsprotect/system/ fsprotect: package-contains-empty-directory fsprotect/tmp/ especially any good reason to override this warning: virtual-package-depends-without-real-package-depends? thanks. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: slv2
Od: Free Ekanayaka fr...@debian.org JM I would like to do it, but having problem to log in. JM Should I create new account or try pkg-ml email + passwd? I think you have to create a new account: http://wiki.debian.org/DebianMultimedia/DevelopPackaging?action=newaccount Hi there, Problem creating account: Username; JaromirMikes passwd: any email:mira.mi...@seznam.cz Having error: global name 'name' is not defined cheers mira -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: slv2
On Tue, Apr 21, 2009 at 10:33 PM, Jaromír Mikeš mira.mi...@seznam.cz wrote: Problem creating account: ... Having error: global name 'name' is not defined Woops, my fault (typo). Should be fixed now. -- 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
Re: RFS: kcometen4
Hello, On Tue, Apr 21, 2009 at 07:18, John Stamp jst...@users.sourceforge.net wrote: Dear mentors, I am looking for a sponsor for my package kcometen4. * Package name : kcometen4 Version : 1.0.4-1 Upstream Author : John Stamp jst...@users.sourceforge.net * URL : http://www.mehercule.net/staticpages/index.php/kcometen4 * License : GPL-2+ Section : kde It builds these binary packages: kcometen4 - An OpenGL KDE screensaver with lightning and comets The package appears to be lintian clean. The upload would fix these bugs: 441351 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/k/kcometen4 - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/k/kcometen4/kcometen4_1.0.4-1.dsc I would be glad if someone uploaded this package for me. +1 sounds good, also lintian clean. any other sponsor can have a double check? thanks. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fsprotect (try #2)
Hello, On Tuesday 21 April 2009, LI Daobing wrote: 2009/4/21 Stefanos Harhalakis v...@v13.gr: I am looking for guidance and a sponsor for my package fsprotect. 1. why this package is a native package? i think a normal package should be better It was also mentioned on the last thread so I omit that: fsprotect is 100% tied to a distribution. It cannot be an independent program that is packaged for debian or other distributions. The core functionality of fsprotect is provided by one init script and one initramfs script/hook and those are depending *very* much to the distribution. I.e the init script must run immediately after the filesystems are mounted and before anything else is ran. 2. one lintian warning: W: fsprotect source: out-of-date-standards-version 3.8.0 (current is 3.8.1) Thanks. I'll fix this. 3. can you explain why you override the following lintian warnings $ cat debian/fsprotect.lintian-overrides fsprotect: non-standard-toplevel-dir fsprotect/ fsprotect: virtual-package-depends-without-real-package-depends fsprotect: package-contains-empty-directory fsprotect/system/ fsprotect: package-contains-empty-directory fsprotect/tmp/ fsprotect needs a directory under the root filesystem to preexist. Most probably it won't be used by normal users, so this won't be common. In IRC it was mentioned that it could should use /lib/fsprotect, but this directory is already used to store a helper script: -rwxr-xr-x 1 root root 1786 2009-03-22 17:32 /lib/fsprotect/fsprotect-protect and perhaps (in the future) hold other helper scripts too. the /fsprotect directory will be used to mount filesystems inside it. 2 mounts per protected filesystem will exist in there. The /fsprotect/system and /fsprotect/tmp directories are required to pre-exist at the time initramfs mounts the root filesystem. Until now I didn't have a definitive answer regarding the proper location of that directory. I've also asked debian-devel some time ago about that but got no answer. especially any good reason to override this warning: virtual-package-depends-without-real-package-depends? Yes.fsprotect uses aufs. It isn't a good idea to depend on packages like this one: aufs-modules-2.6.29-v2-v (which for example, is the module compiled for the custom kernel of my system). I've made fsprotect depend on aufs-modules which is provided my aufs-modules-* packages. I believe you understand that it isn't possible to depend on a specific modules version. Thanks for the immediate feedback. If you don't have any other comments, I'll upload the new version (with standards 3.8.1) to mentors. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fsprotect (try #2)
2009/4/21 Stefanos Harhalakis v...@v13.gr: fsprotect needs a directory under the root filesystem to preexist. Most probably it won't be used by normal users, so this won't be common. In IRC it was mentioned that it could should use /lib/fsprotect, but this directory is already used to store a helper script: -rwxr-xr-x 1 root root 1786 2009-03-22 17:32 /lib/fsprotect/fsprotect-protect and perhaps (in the future) hold other helper scripts too. What about using /lib/fsprotect/mount/ (or similar) instead? The /fsprotect/system and /fsprotect/tmp directories are required to pre-exist at the time initramfs mounts the root filesystem. Could they be created from a script in the initramfs? -- 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
About symbol versioning, soname bumps and symbols files.
[not sure if debian-mentors is the right list, but I try anyway]
Hi,
I maintain the lksctp-tools package, which builds the libsctp1 binary package.
The package so fare has been fairly straight forward and for version 1.0.9 I
used a symbols file for libsctp1 which looks like this:
libsctp.so.1 libsctp1 #MINVER#
sctp_bi...@base 1.0.6.dfsg
sctp_conne...@base 1.0.6.dfsg
sctp_freelad...@base 1.0.6.dfsg
sctp_freepad...@base 1.0.6.dfsg
sctp_getaddr...@base 1.0.7.dfsg
sctp_getlad...@base 1.0.6.dfsg
sctp_getpad...@base 1.0.6.dfsg
sctp_opt_i...@base 1.0.6.dfsg
sctp_peel...@base 1.0.6.dfsg
sctp_recv...@base 1.0.6.dfsg
sctp_s...@base 1.0.6.dfsg
sctp_send...@base 1.0.6.dfsg
Now, I started packaging the new upstream version 1.0.10. There were some API
incompatible changes to sctp_connectx in 1.0.10 (an additional function argument
was added). Instead of simply bumping the soname, upstream did the following:
1.) he added a version script
VERS_1 {
global:
sctp_getpaddrs;
sctp_freepaddrs;
sctp_getladdrs;
sctp_freeladdrs;
sctp_getaddrlen;
sctp_bindx;
sctp_connectx;
sctp_opt_info;
sctp_peeloff;
sctp_recvmsg;
sctp_sendmsg;
sctp_send;
local:
*;
};
VERS_2 {
global: sctp_connectx;
} VERS_1;
2.) In the source code, he added
__asm__(.symver __sctp_connectx, sctp_connectx@);
__asm__(.symver sctp_connectx_orig, sctp_conne...@vers_1);
__asm__(.symver sctp_connectx_new, sctp_connectx@@VERS_2);
...
int __sctp_connectx(int fd, struct sockaddr *addrs, int addrcnt)
...
extern int sctp_connectx_orig (int)
__attribute ((alias (__sctp_connectx)));
...
int sctp_connectx_new(int fd, struct sockaddr *addrs, int addrcnt,
sctp_assoc_t *id)
This was done, to avoid bumping the soname while still allowing older
applications linking against the old interface afaiui. [1]
The generated, new symbols file looks something like:
libsctp.so.1 libsctp1 #MINVER#
ver...@vers_1 1.0.10+dfsg
ver...@vers_2 1.0.10+dfsg
sctp_bi...@vers_1 1.0.10+dfsg
sctp_conne...@base 1.0.10+dfsg
sctp_conne...@vers_1 1.0.10+dfsg
sctp_conne...@vers_2 1.0.10+dfsg
sctp_freelad...@vers_1 1.0.10+dfsg
sctp_freepad...@vers_1 1.0.10+dfsg
sctp_getaddr...@vers_1 1.0.10+dfsg
sctp_getlad...@vers_1 1.0.10+dfsg
sctp_getpad...@vers_1 1.0.10+dfsg
sctp_opt_i...@vers_1 1.0.10+dfsg
sctp_peel...@vers_1 1.0.10+dfsg
sctp_recv...@vers_1 1.0.10+dfsg
sctp_s...@vers_1 1.0.10+dfsg
sctp_send...@vers_1 1.0.10+dfsg
Note, the three different versions of sctp_connectx (Base, VERS_1, VERS_2).
Now, I've never seen this technique used like this before.
So I'd very much appreciate any advice.
My questions are:
1.) Is it fine to use symbol versioning like this to avoid bumping the soname or
is this crack? Does this approach have downsides?
2.) Why are *there* different versions of sctp_connectx (Base and VERS_1 being
and alias). I would have understood if there are two, VERS_1 and VERS_2.
3.) Should I just update the symbols file as shown above and not worry?
TIA for your advice,
Michael
[1] http://sourceware.org/binutils/docs/ld/VERSION.html#VERSION
--
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
Re: RFS: fsprotect (try #2)
On Tuesday 21 April 2009, Paul Wise wrote: 2009/4/21 Stefanos Harhalakis v...@v13.gr: fsprotect needs a directory under the root filesystem to preexist. Most probably it won't be used by normal users, so this won't be common. In IRC it was mentioned that it could should use /lib/fsprotect, but this directory is already used to store a helper script: -rwxr-xr-x 1 root root 1786 2009-03-22 17:32 /lib/fsprotect/fsprotect-protect and perhaps (in the future) hold other helper scripts too. What about using /lib/fsprotect/mount/ (or similar) instead? Everything works as-long-as it is in the root filesystem. If /lib/fsprotect/mount/ is acceptable and /lib/fsprotect/mount/system /lib/fsprotect/mount/tmp /lib/fsprotect/fs/var/orig /lib/fsprotect/fs/var/tmp ... etc ... are acceptable mountpoints, then OK. My personal opinion is that it will be ugly, but I'll change it to that if you agree. The /fsprotect/system and /fsprotect/tmp directories are required to pre-exist at the time initramfs mounts the root filesystem. Could they be created from a script in the initramfs? / is mounted read-only. An initial /fsprotect dir is created inside the initramfs / (which is tmpfs at that point). Latter, the root fs is merged with a tmpfs using aufs. At that point it is possible to create the directories under the new root (which is aufs) and those will be actually created in tmpfs and will be lost latter. The questions are: a) Isn't this somehow hackish? b) Is it better and/or different at all? Still /fsprotect will exist, even if it is created by an initramfs hook and even if it resides in tmpfs. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fsprotect (try #2)
Excerpts from Stefanos Harhalakis's message of mar abr 21 12:12:02 -0300 2009: I am looking for guidance and a sponsor for my package fsprotect. 1. why this package is a native package? i think a normal package should be better It was also mentioned on the last thread so I omit that: fsprotect is 100% tied to a distribution. It cannot be an independent program that is packaged for debian or other distributions. The core functionality of fsprotect is provided by one init script and one initramfs script/hook and those are depending *very* much to the distribution. I.e the init script must run immediately after the filesystems are mounted and before anything else is ran. Anyway, it shouldn't be a native package, native packages need a new release to fix anything (packaging, typos, etc), also need a full upload for every change. It can be argued if there is any use for native packages anymore, and probably there isn't. So, please, don't upload a native package. 3. can you explain why you override the following lintian warnings $ cat debian/fsprotect.lintian-overrides fsprotect: non-standard-toplevel-dir fsprotect/ fsprotect: virtual-package-depends-without-real-package-depends fsprotect: package-contains-empty-directory fsprotect/system/ fsprotect: package-contains-empty-directory fsprotect/tmp/ fsprotect needs a directory under the root filesystem to preexist. Most probably it won't be used by normal users, so this won't be common. In IRC it was mentioned that it could should use /lib/fsprotect, but this directory is already used to store a helper script: -rwxr-xr-x 1 root root 1786 2009-03-22 17:32 /lib/fsprotect/fsprotect-protect and perhaps (in the future) hold other helper scripts too. Why is the script in /lib/fsprotect? Shouldn't it be better if its simply inside /sbin? Why fsprotect needs to break the FHS? the /fsprotect directory will be used to mount filesystems inside it. 2 mounts per protected filesystem will exist in there. The /fsprotect/system and /fsprotect/tmp directories are required to pre-exist at the time initramfs mounts the root filesystem. Then you might prefer to create those directories from a initramfs script. Is it posible to make fsprotect run only as a script of initramfs? -- Saludos, Maxy -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Templates for README.source
Hi, I'm searching for some standard templates for README.source about: - DFSG changes - Quilt usage (reference to /usr/share/doc/quilt/README.source ?) - Other files removed from the original tarball for various reasons Were can I find those informations (wiki...) ? Thank you, -- Laurent Léonard signature.asc Description: This is a digitally signed message part.
Naming recommendation for quilt-managed patches
Hi, Is there a naming recommendation for patches when using quilt in a Debian package ? patch-name.diff ? patch-name.patch ? 0X-patch-name.diff ? 0X-patch-name.patch ? 000X-patch-name.diff ? 000X-patch-name.patch ? an other ? The quilt man page uses patch-name.diff in the examples, but I see various naming styles in Debian packages. -- Laurent Léonard signature.asc Description: This is a digitally signed message part.
Re: Templates for README.source
On Tue, 21 Apr 2009 18:45:39 +0200, Laurent Léonard wrote:
I'm searching for some standard templates for README.source about:
- DFSG changes
- Quilt usage (reference to /usr/share/doc/quilt/README.source ?)
- Other files removed from the original tarball for various reasons
For packages using quilt we have the following template in the
pkg-perl group:
#v-
This package uses quilt to manage all modifications to the upstream
source. Changes are stored in the source package as diffs in
debian/patches and applied during the build.
See /usr/share/doc/quilt/README.source for a detailed explanation.
#v-
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Beatles: Don't Pass Me By
signature.asc
Description: Digital signature
Re: Naming recommendation for quilt-managed patches
2009/4/22 Laurent Léonard laur...@open-minds.org: Is there a naming recommendation for patches when using quilt in a Debian package ? patch-name.diff ? I don't use this because of the extension. patch-name.patch ? I personally prefer this. 0X-patch-name.diff ? 0X-patch-name.patch ? 000X-patch-name.diff ? 000X-patch-name.patch ? I don't use these because the series file specifies the order, not the patch file name. an other ? Some packages have a prefix indicating if the patch is suitable for upstream and what the status is. Ultimately, it doesn't matter which of the above styles you use, just pick one. -- 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
Re: RFS: fsprotect (try #2)
Hello, On Tuesday 21 April 2009, Maximiliano Curia wrote: Excerpts from Stefanos Harhalakis's message of mar abr 21 12:12:02 -0300 2009: fsprotect is 100% tied to a distribution. It cannot be an independent Anyway, it shouldn't be a native package, native packages need a new release to fix anything (packaging, typos, etc), also need a full upload for every change. It can be argued if there is any use for native packages anymore, and probably there isn't. So, please, don't upload a native package. This is a 100% debian specific utility. Shouldn't it be a debian native package? Not making native means that I'd have to do two releases for each actual release (!) and maintain two trees for something that is debian specific. The source code is small and the most part of it is inside debian/. Have a look at the du: $ du -sk fsprotect/* 264 fsprotect/debian 156 fsprotect/doc 56 fsprotect/initramfs-tools 20 fsprotect/lib 20 fsprotect/sbin The fsprotect/initramfs-tools directory contains 100% debian specific scripts. If this is to become a non-native package, all debian-specific parts should go to debian/ dir which would be almost everything (!). Only the fsprotect/sbin and fsprotect/lib dirs aren't debian specific and they just contains two small helper scripts. It just isn't reasonable (and even possible) to split the debian and non- debian stuff. /lib/fsprotect/fsprotect-protect and perhaps (in the future) hold other helper scripts too. Why is the script in /lib/fsprotect? Shouldn't it be better if its simply inside /sbin? It's not a user-usable script. It's just a helper script. Just like /lib/udev/*, /lib/lsb/*, /lib/init/*, etc. Why fsprotect needs to break the FHS? Based on /lib/init/rw and the directories that I mentioned above, I thought that this was the correct place to put it. If not, please suggest another location for it. the /fsprotect directory will be used to mount filesystems inside it. 2 mounts per protected filesystem will exist in there. The /fsprotect/system and /fsprotect/tmp directories are required to pre-exist at the time initramfs mounts the root filesystem. Then you might prefer to create those directories from a initramfs script. I did that and it seems to work OK. However I thought of one catch: Currently fsprotect doesn't protect non-root filesystems when the root fs isn't protected. In the future this may change. In that case it will either need those directories to pre-exist or will need to create them on-the-fly but they will be created inside the real root fs. This means that they will be preserved in later boots and will need to be removed by -rm scripts. For now I don't think there is any use in just protecting non-root filesystems, so I don't plan to add it unless there is a request for that. In other words: This approach is OK for now. Is it posible to make fsprotect run only as a script of initramfs? No. It has an init script that runs after non-root filesystems are mounted. I've uploaded version 1.0.2 to mentors. It includes the /fsprotect directory removal and adds a documentation pdf which I planned to include in the next release. I also removed the duplicate ChangeLog file. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: fsprotect (try #2)
On Tue, 21 Apr 2009 13:21:18 -0300 Maximiliano Curia m...@gnuservers.com.ar wrote: It was also mentioned on the last thread so I omit that: fsprotect is 100% tied to a distribution. It cannot be an independent program that is packaged for debian or other distributions. The core functionality of fsprotect is provided by one init script and one initramfs script/hook and those are depending *very* much to the distribution. I.e the init script must run immediately after the filesystems are mounted and before anything else is ran. Anyway, it shouldn't be a native package, native packages need a new release to fix anything (packaging, typos, etc), also need a full upload for every change. That is a marginal effect - Arch:any packages still need to be rebuilt whether it's native or non-native. The main reason for native packages is functionality, not upload convenience. It can be argued if there is any use for native packages anymore, and probably there isn't. So, please, don't upload a native package. On what basis? apt and dpkg are definitely native packages, as are most other packages that use apt and dpkg directly (like emdebian-*). Packages that use .deb files in explicit manners are often native too - unless they also work with .rpm etc. Packages that are explicitly tied to a single distribution are native to that distribution. What level of tie is deemed to be above a threshold sufficient to make the package native is a subject of ongoing case-by-case discussion. Other packages that are justifiably native include debhelper and the like. I'm not particularly interested in fsprotect per-se, but I don't see that it cannot be deemed native by those who know more about the kinds of things it needs to do. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpU8t3qb89vn.pgp Description: PGP signature
dch multi-maintainer mode
Dear all Is it still allowed as per 3.8.1 policy to use multi maintainer style changelogs? (Asking because of the explicit statement of one type of changlelog and new upgrade to must) Eg. foobar (1.5.11-1) unstable; urgency=low [ Joe Plow Mber ] * New upstream release [ Vasja Pupkin ] * debian/patches - added patch descriptions -- Vasja Pupkin v...@g.net Sat, 04 Apr 2009 23:09:16 -0700 -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: About symbol versioning, soname bumps and symbols files.
On Tue, Apr 21, 2009 at 5:40 PM, Michael Biebl bi...@debian.org wrote:
[not sure if debian-mentors is the right list, but I try anyway]
Hi,
I maintain the lksctp-tools package, which builds the libsctp1 binary package.
The package so fare has been fairly straight forward and for version 1.0.9 I
used a symbols file for libsctp1 which looks like this:
libsctp.so.1 libsctp1 #MINVER#
sctp_bi...@base 1.0.6.dfsg
sctp_conne...@base 1.0.6.dfsg
sctp_freelad...@base 1.0.6.dfsg
sctp_freepad...@base 1.0.6.dfsg
sctp_getaddr...@base 1.0.7.dfsg
sctp_getlad...@base 1.0.6.dfsg
sctp_getpad...@base 1.0.6.dfsg
sctp_opt_i...@base 1.0.6.dfsg
sctp_peel...@base 1.0.6.dfsg
sctp_recv...@base 1.0.6.dfsg
sctp_s...@base 1.0.6.dfsg
sctp_send...@base 1.0.6.dfsg
Now, I started packaging the new upstream version 1.0.10. There were some API
incompatible changes to sctp_connectx in 1.0.10 (an additional function
argument
was added). Instead of simply bumping the soname, upstream did the following:
1.) he added a version script
VERS_1 {
global:
sctp_getpaddrs;
sctp_freepaddrs;
sctp_getladdrs;
sctp_freeladdrs;
sctp_getaddrlen;
sctp_bindx;
sctp_connectx;
sctp_opt_info;
sctp_peeloff;
sctp_recvmsg;
sctp_sendmsg;
sctp_send;
local:
*;
};
VERS_2 {
global: sctp_connectx;
} VERS_1;
2.) In the source code, he added
__asm__(.symver __sctp_connectx, sctp_connectx@);
__asm__(.symver sctp_connectx_orig, sctp_conne...@vers_1);
__asm__(.symver sctp_connectx_new, sctp_connectx@@VERS_2);
...
int __sctp_connectx(int fd, struct sockaddr *addrs, int addrcnt)
...
extern int sctp_connectx_orig (int)
__attribute ((alias (__sctp_connectx)));
...
int sctp_connectx_new(int fd, struct sockaddr *addrs, int addrcnt,
sctp_assoc_t *id)
This was done, to avoid bumping the soname while still allowing older
applications linking against the old interface afaiui. [1]
The generated, new symbols file looks something like:
libsctp.so.1 libsctp1 #MINVER#
ver...@vers_1 1.0.10+dfsg
ver...@vers_2 1.0.10+dfsg
sctp_bi...@vers_1 1.0.10+dfsg
sctp_conne...@base 1.0.10+dfsg
sctp_conne...@vers_1 1.0.10+dfsg
sctp_conne...@vers_2 1.0.10+dfsg
sctp_freelad...@vers_1 1.0.10+dfsg
sctp_freepad...@vers_1 1.0.10+dfsg
sctp_getaddr...@vers_1 1.0.10+dfsg
sctp_getlad...@vers_1 1.0.10+dfsg
sctp_getpad...@vers_1 1.0.10+dfsg
sctp_opt_i...@vers_1 1.0.10+dfsg
sctp_peel...@vers_1 1.0.10+dfsg
sctp_recv...@vers_1 1.0.10+dfsg
sctp_s...@vers_1 1.0.10+dfsg
sctp_send...@vers_1 1.0.10+dfsg
Note, the three different versions of sctp_connectx (Base, VERS_1, VERS_2).
Now, I've never seen this technique used like this before.
So I'd very much appreciate any advice.
My questions are:
1.) Is it fine to use symbol versioning like this to avoid bumping the soname
or
is this crack? Does this approach have downsides?
2.) Why are *there* different versions of sctp_connectx (Base and VERS_1 being
and alias). I would have understood if there are two, VERS_1 and VERS_2.
3.) Should I just update the symbols file as shown above and not worry?
TIA for your advice,
Michael
[1] http://sourceware.org/binutils/docs/ld/VERSION.html#VERSION
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Maybe you've already looked at them but just in case:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id293373
http://people.redhat.com/drepper/dsohowto.pdf
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dch multi-maintainer mode
On Tue, 21 Apr 2009 20:06:23 +0100 Dmitrijs Ledkovs dmitrij.led...@gmail.com wrote: Dear all Is it still allowed as per 3.8.1 policy to use multi maintainer style changelogs? Yes. (Asking because of the explicit statement of one type of changlelog and new upgrade to must) The important lines are: foobar (1.5.11-1) unstable; urgency=low -- Vasja Pupkin v...@g.net Sat, 04 Apr 2009 23:09:16 -0700 -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpGue4rZwkyh.pgp Description: PGP signature
Re: dch multi-maintainer mode
Neil Williams a écrit : Is it still allowed as per 3.8.1 policy to use multi maintainer style changelogs? Yes. And what was the prevous style of changelog allowed, by the way? -- Stéphane -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: rhino: New debian package prepared (2nd try)
I'm uploading rhino and tomcat-native now Matt -- Matthew Johnson signature.asc Description: Digital signature
Lintian question
Dear Mentors, While looking at http://lintian.debian.org/tags/gz-file-not-gzip.html I noticed this lintian warning about my package ampache. W gz-file-not-gzip The given file ends with .gz, which normally indicates it is compressed with gzip. However, it doesn't seem to be a gzip-compressed file. gzip will fail with an error on such files. Normally this indicates a mistake in the installation process of the package. Severity: normal, Certainty: possible The file that lintian is complaining about is usr/share/ampache/www/modules/getid3/module.archive.gzip.php As you can see the file clearly does not end with .gz but instead it ends in php. This file is not compressed with gzip but instead adds gzip functionality to the app. Is this a bug with Lintian as it is clearly reporting a false positive? Would an override of this Lintian warning be appropriate? Or both? Thanks Charlie Smotherman porthose signature.asc Description: This is a digitally signed message part
Re: Lintian question
On Tue, Apr 21, 2009 at 04:54:12PM -0500, Charlie Smotherman wrote:
W gz-file-not-gzip
The file that lintian is complaining about is
usr/share/ampache/www/modules/getid3/module.archive.gzip.php
As you can see the file clearly does not end with .gz but instead it
ends in php. This file is not compressed with gzip but instead adds
gzip functionality to the app.
Is this a bug with Lintian as it is clearly reporting a false positive?
It's a false positive and should be reported as a bug, if there is not
one open for it already. The attached patch should fix it by only
matching filenames that end in the string .gz, not merely contain it.
You may add it to your bug if you wish, though lintian maintainers may
have a better way to fix it.
Would an override of this Lintian warning be appropriate?
At your discretion a temporary override would make your package look
clean, but when the bug is fixed the warning will go away anyway and you
will have to upload again to remove the override. There's no harm in
just ignoring the warning.
--
Jonathan Wiltshire
PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52
--- lintian-2.2.9/checks/files~ 2009-04-21 23:40:26.0 +0100
+++ lintian-2.2.9/checks/files 2009-04-21 23:41:20.0 +0100
@@ -761,7 +761,7 @@
}
# .gz files
- if ($file =~ m/\.gz/) {
+ if ($file =~ m/\.gz$/) {
my $info = $info-file_info-{$file} || '';
if ($info !~ m/gzip compressed/) {
tag gz-file-not-gzip, $file;
signature.asc
Description: Digital signature
Re: Naming recommendation for quilt-managed patches
Laurent Léonard laur...@open-minds.org writes: Hi, Is there a naming recommendation for patches when using quilt in a Debian package ? […] 0X-patch-name.patch ? 000X-patch-name.patch ? I use names similar to these. 01.foo-bar-baz.patch 02.spim-spam-spom.patch The full-stop ‘.’ makes a slightly more clear distinction between the sequence number and the descriptive patch name. Then running ‘(cd debian/patches/ ls -1 *.patch series)’ creates the series file with the correct sequence. That way, I'm managing the patch file names with normal file management commands, and I don't have to also manage them with Quilt. If I need to re-sequence the patches (and not just add one on the end) after they're in version control, my VCS tool has good renaming support. The quilt man page uses patch-name.diff in the examples, but I see various naming styles in Debian packages. Quilt assumes you will be using Quilt to create, sequence, and manage the patch files, which may be a reasonable assumption in the Quilt documentation but is never true for me. -- \ “Judge: A law student who marks his own papers.” —Henry L. | `\ Mencken | _o__) | Ben Finney pgpnJOII8FOcN.pgp Description: PGP signature
Re: dch multi-maintainer mode
Dmitrijs Ledkovs dmitrij.led...@gmail.com writes: Is it still allowed as per 3.8.1 policy to use multi maintainer style changelogs? (Asking because of the explicit statement of one type of changlelog and new upgrade to must) That type of changelog allows anything at all following the two space indent for entries, so yes, policy still allows your chosen style. -- \“I washed a sock. Then I put it in the dryer. When I took it | `\ out, it was gone.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dch multi-maintainer mode
On Tue, Apr 21, 2009 at 09:22:49PM +0200, Stéphane Glondu wrote: Neil Williams a écrit : Is it still allowed as per 3.8.1 policy to use multi maintainer style changelogs? Yes. And what was the prevous style of changelog allowed, by the way? Originally, the debian changelog format was supposed to be pluggable, where people would write parsers for different changelog formats that would extract the necessary information (package name, version, changed-by, etc) from the changelog file. As it turns out, the current standard format works entirely sufficiently, and I doubt that anyone's ever used a different style, so that misfeature has been removed and the standard format everyone uses is now the One True And Only Format. - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian question
Charlie Smotherman cj...@cableone.net writes: The file that lintian is complaining about is usr/share/ampache/www/modules/getid3/module.archive.gzip.php As you can see the file clearly does not end with .gz but instead it ends in php. This file is not compressed with gzip but instead adds gzip functionality to the app. It's a bug in Lintian (already reported, will be fixed in the next release). Would an override of this Lintian warning be appropriate? We (the Lintian developers) would rather you not add overrides for Lintian bugs, since you'll just have to remove the override again and in some cases it can hide other problems that are real. We in turn try to fix bugs quickly, although I've been swamped lately so the pace of releases has dropped. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lintian question
On Tue, 2009-04-21 at 17:02 -0700, Russ Allbery wrote: Charlie Smotherman cj...@cableone.net writes: The file that lintian is complaining about is usr/share/ampache/www/modules/getid3/module.archive.gzip.php As you can see the file clearly does not end with .gz but instead it ends in php. This file is not compressed with gzip but instead adds gzip functionality to the app. It's a bug in Lintian (already reported, will be fixed in the next release). Would an override of this Lintian warning be appropriate? We (the Lintian developers) would rather you not add overrides for Lintian bugs, since you'll just have to remove the override again and in some cases it can hide other problems that are real. We in turn try to fix bugs quickly, although I've been swamped lately so the pace of releases has dropped. Russ, Thanks, and I agree about overrides, thus the reason for posting to this list, to gain the knowledge of others who are much wiser in such matters than I. This is good to know as I have a new upstream release due out soon, and I'm sure my DD sponsor will be asking me about this issue. Thanks again for your assistance. Cheers Charlie Smotherman signature.asc Description: This is a digitally signed message part
Re: RFS: fsprotect (try #2)
Excerpts from Neil Williams's message of mar abr 21 14:53:13 -0300 2009: On what basis? apt and dpkg are definitely native packages, as are most other packages that use apt and dpkg directly (like emdebian-*). Packages that use .deb files in explicit manners are often native too - unless they also work with .rpm etc. I think that a new package shouldn't be native. There are packages that are native projects as the ones you mention, but even if they gain the name by being a development that Debian depends on, there is little gain, if any, in treating them as special cases. Packaging and coding are, after all, different tasks, so using the non-native version numbering that makes explicit the release version and packaging revision gives a greater degree of flexibility. In cases like giving support to stable, NMUs are easier and cleaner for non-native versioned packages. Or in a derivative distribution, if they need to change a native package, should they build another native or should they make them non-native one? (for example, ubuntu considers apt as native, with version 0.7.20.2ubuntu6) For all these reasons, and many others, even for Debian programs, I think we shouldn't use native packages. Packages that are explicitly tied to a single distribution are native to that distribution. What level of tie is deemed to be above a threshold sufficient to make the package native is a subject of ongoing case-by-case discussion. Other packages that are justifiably native include debhelper and the like. I'm not particularly interested in fsprotect per-se, but I don't see that it cannot be deemed native by those who know more about the kinds of things it needs to do. Neither do I really, but I failed to see what's the gain to use the native versioning packaging. Let's assume fsprotect is a wonderful project, and works perfectly in Debian. I'm sure others would notice and some might choose to use Debian for that reason, but some would prefer to port fsprotect to their systems. Should we then encourage a fork to their particular system, or help them make fsprotect more system independant? Benefiting both systems from mutual improvement is something I would look forward to. While tagging it too specific for my system, you can't use it is not. I hope this won't create a huge discussion. -- Saludos, Maxy -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: New Developer Request
Hi Deepak, I went over the currently open buglist to see if I could contribute by fixing some of them to start with. One of the questions I had is some bugs are platform specific / hardware specific. For eg: BUG: soft lockup - CPU#3 stuck for 61s! (AMD Phenom 9600 Quad-Core) To reproduce the problem, fix test it - you need to have access to this specific processor? or are there machines out there owned by specific project groups with a serial access to work on such problems? The reason am asking this is that quite obviously not everyone will have access to specific hardware, in such case how developers fix such specific problems?? Thanks Ramesh On Wed, Apr 1, 2009 at 9:07 AM, Deepak Tripathi apenguinli...@gmail.com wrote: Hi Ramesh , Please read the debian help[0] page and see at which area you can able to contribute for example documentation, man pages , coding etc . [0] = http://www.debian.org/intro/help Thanks Deepak On Wed, Apr 1, 2009 at 8:50 PM, Ramesh rrame...@gmail.com wrote: Hello, I wish to contribute to debian as a developer. I got my keys signed by one of the existing developers. I am looking for a mentor /advocate to guide /help me contribute to debian (may be to start with fixing bugs in (networking or embedded area) in the kernel tree. Thanks /Ramesh -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- Deepak Tripathi E3 71V3 8Y C063 (We Live By Code) http://deepaktripathi.blogspot.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (QA update of the package) (fwd) (fwd)
On Tue, Apr 21, 2009 at 11:22, Matthew Palmer mpal...@debian.org wrote: Hi Rogério, On Mon, Apr 20, 2009 at 07:32:46PM -0300, Rogério Brito wrote: Probably this was missed the past few times that I posted to the list. Please, could anybody sponsor it? I've started looking at this package, but got caught up with other things. At the very least, you'll need to properly adopt the package before I'll upload it. I don't sponsor NMUs, and it's quite obvious you're keen to be the maintainer, so stake your claim. already uploaded by me. Rogério Brito said he will adopt this package and package the new upstream version (on IRC). Thanks. -- Best Regards LI Daobing -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
