Long double alignment test
Mentors,
This may be a full-on d-devel question, but I'll start out here.
I'm maintaining GNU Smalltalk, which is having problems building on
most 64-bit platforms. I'm having difficulty tracking these problems
down, so I'm asking for some assistance from anyone who has access to
these platforms (any DD, I believe).
The issue is with a test for long double alignment which reports an
incorrect value on ia64 (and probably other archs). On a RedHat
mailing list I have found the following code which is claimed to
correctly detect long double alignment:
http://sources.redhat.com/ml/autoconf/1999-07/msg2.html
struct foo {
union align {
double d;
long l;
void *p;
} u;
char c;
};
int main() {
struct foo f[2];
printf("sizeof(foo)=%ld\n", (long) sizeof(struct foo));
printf("sizeof(align)=%ld\n", (long) sizeof(union align));
printf("sizeof(f2)=%ld\n", (long) sizeof(f));
if( 2*sizeof(union align) != sizeof(f) ) {
printf("union may be aligned on %ld byte boundaries.\n",
(long)(sizeof(struct foo) - sizeof(union align)));
return 1;
}
printf("union must be aligned on %ld byte boundaries.\n",
(long)sizeof(union align));
return 0;
}
Anyone know if this works? Could someone please run this on each of
the archs we support (particularly ia64) and report the results to me?
Does anyone have any better code for discovering alignment? I'm
surprised this isn't common enough that there would be a stock
solution.
Thanks in advance,
-- Brett
signature.asc
Description: Digital signature
Re: Long double alignment test
Brett Cundal wrote: > This may be a full-on d-devel question, but I'll start out here. > I'm maintaining GNU Smalltalk, which is having problems building on > most 64-bit platforms. This should probably go to the appropriate arch-specific mailing lists (e.g. debian-ia64).
Long double alignment test
Brett Cundal writes:
> The issue is with a test for long double alignment which reports an
> incorrect value on ia64 (and probably other archs).
> [...]
> Anyone know if this works?
The code which was posted doesn't use the long double type, which
makes the idea of it giving the alignment of that type somewhat
doubtful. A processor could have special alignment issues to do with
long doubles which don't show up in long, double or void* (due to a
weird floating point unit).
I believe that the "if" condition is never false because "f" contains
two unions and two chars, so its size is greater than that of two
unions (by at least two chars) and therefore not equal. As a result,
it seems to give the alignment of the union, which is the maximum
alignment of the three types inside.
I prefer the code below. Enjoy!
Cheers, Neil.
#include
#define ALIGN_OF(t) \
((int)(sizeof( \
struct { \
char c; \
t x; \
}) \
- sizeof(t) ))
int main()
{
printf("char: %d\n", ALIGN_OF(char));
printf("short: %d\n", ALIGN_OF(short));
printf("int: %d\n", ALIGN_OF(int));
printf("long: %d\n", ALIGN_OF(long));
printf("long long: %d\n", ALIGN_OF(long long));
printf("void*: %d\n", ALIGN_OF(void*));
printf("float: %d\n", ALIGN_OF(float));
printf("double: %d\n", ALIGN_OF(double));
printf("long double: %d\n", ALIGN_OF(long double));
return 0;
}
Re: Long double alignment test
Brett Cundal <[EMAIL PROTECTED]> writes:
> Mentors,
>
> This may be a full-on d-devel question, but I'll start out here.
>
> I'm maintaining GNU Smalltalk, which is having problems building on
> most 64-bit platforms. I'm having difficulty tracking these problems
> down, so I'm asking for some assistance from anyone who has access to
> these platforms (any DD, I believe).
>
> The issue is with a test for long double alignment which reports an
> incorrect value on ia64 (and probably other archs). On a RedHat
> mailing list I have found the following code which is claimed to
> correctly detect long double alignment:
>
> http://sources.redhat.com/ml/autoconf/1999-07/msg2.html
>
> struct foo {
> union align {
> double d;
> long l;
> void *p;
> } u;
> char c;
> };
>
> int main() {
> struct foo f[2];
>
> printf("sizeof(foo)=%ld\n", (long) sizeof(struct foo));
> printf("sizeof(align)=%ld\n", (long) sizeof(union align));
> printf("sizeof(f2)=%ld\n", (long) sizeof(f));
>
> if( 2*sizeof(union align) != sizeof(f) ) {
> printf("union may be aligned on %ld byte boundaries.\n",
> (long)(sizeof(struct foo) - sizeof(union align)));
> return 1;
> }
>
> printf("union must be aligned on %ld byte boundaries.\n",
> (long)sizeof(union align));
> return 0;
> }
>
> Anyone know if this works? Could someone please run this on each of
> the archs we support (particularly ia64) and report the results to me?
>
> Does anyone have any better code for discovering alignment? I'm
> surprised this isn't common enough that there would be a stock
> solution.
Debian-amd64:
sizeof(foo)=16
sizeof(align)=8
sizeof(f2)=32
union may be aligned on 8 byte boundaries.
>
> Thanks in advance,
>
> -- Brett
MfG
Goswin
Re: Long double alignment test
Neil Turton <[EMAIL PROTECTED]> writes:
> Brett Cundal writes:
> > The issue is with a test for long double alignment which reports an
> > incorrect value on ia64 (and probably other archs).
> > [...]
> > Anyone know if this works?
>
> The code which was posted doesn't use the long double type, which
> makes the idea of it giving the alignment of that type somewhat
> doubtful. A processor could have special alignment issues to do with
> long doubles which don't show up in long, double or void* (due to a
> weird floating point unit).
>
> I believe that the "if" condition is never false because "f" contains
> two unions and two chars, so its size is greater than that of two
> unions (by at least two chars) and therefore not equal. As a result,
> it seems to give the alignment of the union, which is the maximum
> alignment of the three types inside.
If the alignment of the union is bigger than the union itself the char
can be merged into the alignment of the union and not take any space
at all. In that case the size of the union would be the alignment.
> I prefer the code below. Enjoy!
>
> Cheers, Neil.
>
> #include
>
> #define ALIGN_OF(t) \
> ((int)(sizeof( \
> struct { \
>char c; \
>t x; \
> }) \
>- sizeof(t) ))
>
> int main()
> {
> printf("char: %d\n", ALIGN_OF(char));
> printf("short: %d\n", ALIGN_OF(short));
> printf("int: %d\n", ALIGN_OF(int));
> printf("long: %d\n", ALIGN_OF(long));
> printf("long long: %d\n", ALIGN_OF(long long));
> printf("void*: %d\n", ALIGN_OF(void*));
> printf("float: %d\n", ALIGN_OF(float));
> printf("double: %d\n", ALIGN_OF(double));
> printf("long double: %d\n", ALIGN_OF(long double));
> return 0;
> }
Nice.
MfG
Goswin
How to get package in main with the same version to upgrade over a mentors.debian.net version?
Hello, I am preparing an updated package with an unsolved security bug. I would like to upload it to mentors.debian.net, but when it gets uploaded to main it will have the same version number as the one on mentors. I would to know if there is a way to upload to mentors and be sure it gets upgraded when it enters main. I had this problem before, but now it is worse because of the security bug. I looked at the policy and the reverse problem seems to be solved by using epochs. An negative epoch is not the way right? And how do I apply an epoch? Yada complains when I try to put an Version: field somewhere. Is there an other way to do it without having to bump the debian version? Or is that exactly what I should do? Cheers, Remco.
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > I am preparing an updated package with an unsolved security bug. > I would like to upload it to mentors.debian.net, but when it > gets uploaded to main it will have the same version number as the > one on mentors. I would to know if there is a way to upload to > mentors and be sure it gets upgraded when it enters main. > > I had this problem before, but now it is worse because of the security > bug. > > I looked at the policy and the reverse problem seems to be solved > by using epochs. An negative epoch is not the way right? And how do > I apply an epoch? Yada complains when I try to put an Version: field > somewhere. > > Is there an other way to do it without having to bump the debian version? > Or is that exactly what I should do? Hmm... but why don't you want to simply bump this version? IMHO 1.2.3-4 looks much better than 1:1.2.3-3. And in fact I think the proper way would be to add exacly bumped version, and in changelog set urgency=high (due to security bug). Or maybe your problem is that you don't want to "start" in official archives with for example -2 version? If yes then I have no idea why ;) regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
Remco Seesink wrote: > I am preparing an updated package with an unsolved security bug. I > would like to upload it to mentors.debian.net, but when it gets > uploaded to main it will have the same version number as the one on > mentors. I would to know if there is a way to upload to mentors and be > sure it gets upgraded when it enters main. If the new package is different from the package on m.d.n, then you should add a new changelog entry and increment the Debian version number. Users will automatically be upgraded to the newer version. > I looked at the policy and the reverse problem seems to be solved by > using epochs. An negative epoch is not the way right? And how do I > apply an epoch? Yada complains when I try to put an Version: field > somewhere. An epoch should rarely be used. It is not appropriate or necessary in this case. (Epochs are usually used when the upstream versioning scheme changes, like when Mozilla upgraded from version M18 to version 0.6.) > Is there an other way to do it without having to bump the debian > version? Or is that exactly what I should do? Yes, you should bump the debian version. Use "dpkg-buildpackage -v" when uploading the package to the archive to include all of the relevant changelog entries in the uploaded "changes" file (including changes from versions that were uploaded to m.d.n only).
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > Hello, > > I am preparing an updated package with an unsolved security bug. > I would like to upload it to mentors.debian.net, but when it > gets uploaded to main it will have the same version number as the > one on mentors. I would to know if there is a way to upload to > mentors and be sure it gets upgraded when it enters main. > > I had this problem before, but now it is worse because of the security > bug. > > I looked at the policy and the reverse problem seems to be solved > by using epochs. An negative epoch is not the way right? And how do > I apply an epoch? Yada complains when I try to put an Version: field > somewhere. > > Is there an other way to do it without having to bump the debian version? > Or is that exactly what I should do? The proper way is to simply not upload to mentors.d.n with 'official' debian revision numbers. Assuming the offical version will be 1.0-1, use for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by one, append a mentor-specific part). This way, there is never a clash, you can see from the version number it's an unoffical version. Two alternative approaches: - simply increment debian revision, and use -v appropriately, it doesn't matter certain debian-revisions are never uploaded. Disadvantage: changelog cluttering, usually people won't have those unofficial intermediate versions, and the differences among those are not very interesting usually. If you merge the topmost changelog entry every time, you seemingly have gaps in version numbering according to changelog, not very nice either. - Don't care about m.d.n, simply have your fixed version uploaded with the same version number. m.d.n is unoffical anyway, you in no way have to take care of proper upgrade paths at all. Disadvantage: in bugreports with reportbug, and for the user itself, it's hard to see whether the user/reporter has an unoffical version, or the official one. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Long double alignment test
Brett Cundal wrote: > I'm maintaining GNU Smalltalk, which is having problems building on > most 64-bit platforms. I'm having difficulty tracking these problems > down, so I'm asking for some assistance from anyone who has access to > these platforms (any DD, I believe). > Anyone know if this works? Could someone please run this on each of the archs we support (particularly ia64) and report the results to me? Here's another 64-bit arch to compare to, I was curious about the answer myself. [EMAIL PROTECTED]:~/tmp$ uname -a Linux moltar 2.4.26-sparc64 #1 Sat Apr 24 01:43:10 EDT 2004 sparc64 GNU/Linux [EMAIL PROTECTED]:~/tmp$ ./longalign # your code sizeof(foo)=16 sizeof(align)=8 sizeof(f2)=32 union may be aligned on 8 byte boundaries. [EMAIL PROTECTED]:~/tmp$ ./longalign2 # Neil's code char: 1 short: 2 int: 4 long: 4 long long: 8 void*: 4 float: 4 double: 8 long double: 8 - David A. Riggs
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 12:09:53PM -0700, Matt Brubeck wrote: > > Is there an other way to do it without having to bump the debian > > version? Or is that exactly what I should do? > > Yes, you should bump the debian version. > > Use "dpkg-buildpackage -v" when uploading the package to the archive to > include all of the relevant changelog entries in the uploaded "changes" > file (including changes from versions that were uploaded to m.d.n only). And "-sa" switch to include sources with upload other than -1 ;) regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Request For Sponsor : NWS - Grid monitoring infrastructure
Hey dudes, I have packaged the NWS, a computational grid monitoring infrastructure (ITP #167891, which I just enhanced), and I'm not seeking for a sponsor. == me: == In the NM process, maintainer of quilt (advanced patch management tool, which NWS build-depend on). Active member of Debian since years, coordinator of the debian french translation effort. === Package description: === Package: nws Description: Grid monitoring infrastructure (executables and man pages) The Network Weather Service is the de facto standard of the emerging Grid community to monitor the system availability. (the grid usually denotes any platform formed by the federation and aggregation of local resources between several organizations like universities). . Once you've deployed the relevant processes on each platform node, you can ask it for several metrics: . - about each host: - available CPU (both for incoming process and for already started ones) - free memory - free disk - about each host couple: - TCP connexion time, bandwidth and latency . Moreover, the NWS can predict future tendencies using statistical treatements on previous measurements. . This package installs the library, utilities and user documentation. Package: libnws-dev Description: Grid monitoring infrastructure (headers and devel documentation) [same blurb about NWS itself cutted from this mail for clarity] . This package contains the files you need to compile programs which use this library. === Licence: (BSD-like) === Copyright (c) 2002, The Regents of the University of California All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the names of the University of California, nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. === package: === The package is linda clean, beside of the following points: W: libnws-dev; Executable /usr/include/nws_api.h with perms 0755 is not an ELF file or script. W: libnws-dev; Executable /usr/include/nws_forecast_api.h with perms 0755 is not an ELF file or script. I provided a patch for debhelper to solve that point. That's #252492, opened today. The package uploaded does not have this warning, since I compiled it on my own box with a modified debhelper. E: nws; No manual page for binary nws_add_forecast. E: nws; No manual page for binary nws_ctrl_activity. E: nws; No manual page for binary nws_ctrl_mem. E: nws; No manual page for binary nws_insert. E: nws; No manual page for binary nws_setup. Reported upstream. They are not critical elements of the infrastructure. This is my fault for nws_ctrl_activity and nws_setup (debian specific parts). Lintian also reports: E: nws: shell-script-fails-syntax-check ./usr/bin/nws_hostadmin Reported upstream. I'll drop it soon, I guess. It is available from my web page: http://graal.ens-lyon.fr/~mquinson/grid.html#nws deb http://graal.ens-lyon.fr/~mquinson/grid unstable deb-src http://graal.ens-lyon.fr/~mquinson/grid unstable and also from mentors.d.n: http://mentors.debian.net/debian/pool/main/n/nws/ Thank you for your time and I am looking forward to reading your suggestions on how to improve the package and/or offers for sponsorship! Bye, Mt. -- I don't care whichever programming language we choose, as long as it's C. signature.asc Description: Digital signature
Deals come once in a lifetime
G E TY O U R U N I V E R S I T Y D I P L O M A Do you want a prosperous future, increased earning power more money and the respect of all? Call this number: 1 775 490 9881 (24 hours) There are no required tests, classes, books, or interviews! Get a Bachelors, Masters, MBA, GED and Doctorate (PhD) diploma! Receive the benefits and admiration that comes with a diploma! No one is turned down! Call Today 1 775 490 9881 (7 days a week) Confidentiality assured! 226.37.121.228 130.25.30.70 60.82.68.77 222.36.120.220 190.2.57.86 156.16661.195 64.161.80.160 239.96.16.202 163.227.0.8 184.165.72.6 Nicholas 120.46.32.43 105.226.188.180 Stroud 188.96.152.74 Nicholas Stroud 0.103.233.184 140.96.157.182 14.214.66.64 218.207.103.128 192.130.242.28 180.20.46.106 44.220.169.138 Nicholas Stroud 228.222.224.44 69.232.158.67 225.160.208.216 Nicholas Stroud 68.163.108.12 Nicholas Stroud 11.83.159.201 crutch knutson lobo beryllium kiwi cry cessna cottrell cage less Nicholas chieftain mineralogy Stroud sunshade Nicholas Stroud chill seminal somatic tidbit brig buss rhombi Nicholas Stroud boycott galvanic paz Nicholas Stroud doormen Nicholas Stroud pulpit 128.92.24.144 40.200.10.94 188.124.54.52 144.53.91.208 223.180.116.4 188.206.206.218 106.240.240.222 15.180.112.82 60.100.104.9 132.172.188.210 Nicholas 128.35.162.138 174.98.145.48 Stroud 89.238.145.119 Nicholas Stroud 252.248.64.44 10.64.156.20 245.45.176.130 84.152.96.176 210.42.12.119 192.64.52.155 24.220.0.184 Nicholas Stroud 52.233.136.210 202.244.216.114 88.255.110.148 Nicholas Stroud 124.24.80.120 Nicholas Stroud 29.51.55.80 Nicholas Stroud rotate chieftain bud Nicholas Stroud pretoria Nicholas Stroud rydberg midshipman nikolai sylvester attack chaw idaho covary lighten shopkeep brakeman Nicholas immigrate dactylic Stroud stool Nicholas Stroud jangle ludicrous cytology insufficient calisthenic transversal carbonyl Nicholas Stroud apport additive brooke Nicholas Stroud crises Nicholas Stroud baseplate crook infect Nicholas Stroud fount introspect pigpen carmela practise ackley decal osteology rosenberg myosin blackwell supervene dumpty Nicholas shawl automaton Stroud teethed Nicholas Stroud wink shea gist workforce prosopopoeia chop avertive Nicholas Stroud quadrant trapezium clonic Nicholas Stroud jitter Nicholas Stroud brandywine
RFS: dmalloc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I'm looking for a sponsor for dmalloc. The package is DFSG free. It consists of following binary packages: Package: dmalloc Description: Debug memory allocation library - transition package ~ This is an empty package which depends on libdmalloc4, to provide for ~ smooth upgrades. It can safely be removed. Package: libdmalloc4 Description: Debug memory allocation library ~ Drop in replacement for the system's `malloc', `realloc', `calloc', `free' ~ and other memory management routines while providing powerful debugging ~ facilities configurable at runtime. ~ . ~ These facilities include such things as memory-leak tracking, fence-post ~ write detection, file/line number reporting, and general logging of ~ statistics. ~ . ~ This package contains only the shared libraries, the development files and ~ documentation is in the -dev-package. Package: libdmalloc4-dev Description: Debug memory allocation library - development files and docs ~ Drop in replacement for the system's `malloc', `realloc', `calloc', `free' ~ and other memory management routines while providing powerful debugging ~ facilities configurable at runtime. ~ . ~ These facilities include such things as memory-leak tracking, fence-post ~ write detection, file/line number reporting, and general logging of ~statistics. ~ . ~ This package contains the static libraries and the documentation. The package can be obtained from mentors.debian.net or deb-src http://zeus.ugent.be/~luk pool/ Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAv4dS5UTeB5t8Mo0RAi24AJ4wRJWSkFH2CE4xUEwh5kJWRQSJQACgnbMq m+nnQPeWp57Av9n9gQA0pYc= =D4is -END PGP SIGNATURE-
Re: Long double alignment test
Hi Brett! You wrote: > Anyone know if this works? Could someone please run this on each of > the archs we support (particularly ia64) and report the results to me? Ok. alpha: your code: sizeof(foo)=16 sizeof(align)=8 sizeof(f2)=32 union may be aligned on 8 byte boundaries. Neal's code: char: 1 short: 2 int: 4 long: 8 long long: 8 void*: 8 float: 4 double: 8 long double: 8 ia64: your code: sizeof(foo)=16 sizeof(align)=8 sizeof(f2)=32 union may be aligned on 8 byte boundaries. Neal's: char: 1 short: 2 int: 4 long: 8 long long: 8 void*: 8 float: 4 double: 8 long double: 16 -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 09:19:43PM +0200, Jeroen van Wolffelaar wrote: > On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > > Hello, > > > > I am preparing an updated package with an unsolved security bug. > > I would like to upload it to mentors.debian.net, but when it > > gets uploaded to main it will have the same version number as the > > one on mentors. I would to know if there is a way to upload to > > mentors and be sure it gets upgraded when it enters main. > > > > I had this problem before, but now it is worse because of the security > > bug. > > > > I looked at the policy and the reverse problem seems to be solved > > by using epochs. An negative epoch is not the way right? And how do > > I apply an epoch? Yada complains when I try to put an Version: field > > somewhere. > > > > Is there an other way to do it without having to bump the debian version? > > Or is that exactly what I should do? > > The proper way is to simply not upload to mentors.d.n with 'official' > debian revision numbers. Assuming the offical version will be 1.0-1, use > for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version > numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by > one, append a mentor-specific part). Gee, I real need to find back that document that wrote to use 1.0-0.1, 1.0-0.2, 1.0-0.3 etc for non official debian packages. > > This way, there is never a clash, you can see from the version number > it's an unoffical version. > > Two alternative approaches: > - simply increment debian revision, and use -v appropriately, it doesn't > matter certain debian-revisions are never uploaded. Disadvantage: > changelog cluttering, usually people won't have those unofficial > intermediate versions, and the differences among those are not very > interesting usually. If you merge the topmost changelog entry every > time, you seemingly have gaps in version numbering according to > changelog, not very nice either. > - Don't care about m.d.n, simply have your fixed version uploaded with > the same version number. m.d.n is unoffical anyway, you in no way have > to take care of proper upgrade paths at all. Disadvantage: in > bugreports with reportbug, and for the user itself, it's hard to see > whether the user/reporter has an unoffical version, or the official > one. > > --Jeroen > > -- > Jeroen van Wolffelaar > [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) > http://Jeroen.A-Eskwadraat.nl Cheers Geert Stappers pgpYowj6HYsku.pgp Description: PGP signature
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
Geert Stappers wrote: > > The proper way is to simply not upload to mentors.d.n with > > 'official' debian revision numbers. Assuming the offical version > > will be 1.0-1, use for example 1.0-1~mentors1 (if mentors.d.n > > accepts ~ in version numbers), or alternatively 1.0-0mentors1 > > (decrease debian-revision by one, append a mentor-specific part). > > Gee, I real need to find back that document that wrote to use > > 1.0-0.1, 1.0-0.2, 1.0-0.3 etc for non official debian packages. I don't think this is a good idea, because those numbers are used for non-maintainer uploads. You could have different versions with the same number, one uploaded to m.d.n and the other uploaded to the main archive as an NMU. It's also confusing because it looks like an NMU. I think numbers like 1.0-0test1 (where "test" can be any string) are best, if you need to create separate testing versions that will not be uploaded to the archive. This method is used by other Debian developers including the XFree86 maintainers (c.f. xfree86 4.3.0-0pre1v3). I use normal versions like 1.2.1-1 when uploading to m.d.n, and this hasn't caused any problems. If no bugs are found in the m.d.n package, I send it to my sponsor to be uploaded with no further changes.
Письмо
Самое эффективное средство защиты от бродячих и агрессивных собак. http://www.DAZER2.ru/?rgiFv8p (095) 258-0083 бересту, то есть верхнюю кожу
Re: Request For Sponsor : NWS - Grid monitoring infrastructure
also sprach Martin Quinson <[EMAIL PROTECTED]> [2004.06.03.2220 +0200]: > I have packaged the NWS, a computational grid monitoring > infrastructure (ITP #167891, which I just enhanced), and I'm not > seeking for a sponsor. You're not? If you are... then I'd be willing... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
[EMAIL PROTECTED] (Geert Stappers) writes: > On Thu, Jun 03, 2004 at 09:19:43PM +0200, Jeroen van Wolffelaar wrote: >> On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: >> > Hello, >> > >> > I am preparing an updated package with an unsolved security bug. >> > I would like to upload it to mentors.debian.net, but when it >> > gets uploaded to main it will have the same version number as the >> > one on mentors. I would to know if there is a way to upload to >> > mentors and be sure it gets upgraded when it enters main. >> > >> > I had this problem before, but now it is worse because of the security >> > bug. >> > >> > I looked at the policy and the reverse problem seems to be solved >> > by using epochs. An negative epoch is not the way right? And how do >> > I apply an epoch? Yada complains when I try to put an Version: field >> > somewhere. >> > >> > Is there an other way to do it without having to bump the debian version? >> > Or is that exactly what I should do? >> >> The proper way is to simply not upload to mentors.d.n with 'official' >> debian revision numbers. Assuming the offical version will be 1.0-1, use >> for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version >> numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by >> one, append a mentor-specific part). > > Gee, I real need to find back that document that wrote to use > > 1.0-0.1, 1.0-0.2, 1.0-0.3 etc for non official debian packages. That would be a NMU of a non native debian package. 1.0-0.0.1 would be a recompile binary only NMU of a non-native debian package. See policy. 1.0-0.0.0.1 would be free but 1.0-0mentors1 or 1.0-1~mentors is nicer. MfG Goswin
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
Hi all, Thank you all for the suggestions. I am uploading new firebird packages right now with this method: > or alternatively 1.0-0mentors1 (decrease debian-revision by > one, append a mentor-specific part). I wanted to prevent confusion in main when debian revisions are missing, and to keep the changelog clean. I like to document all my mistakes on mentors and get a clean version in main when I am ready. In case you were wondering, the unsolved security bug is: #251458 Urgh. I just noticed it didn't upload the original source: -- [EMAIL PROTECTED]:~/packaging/firebird/uploaded$ dput mentors firebird_1.0.3-0mentors1_i386.changes Checking Signature on .changes gpg: Signature made Fri 04 Jun 2004 03:59:11 AM CEST using DSA key ID 954F5EC7 gpg: Good signature from "Remco Seesink <[EMAIL PROTECTED]>" Good signature on /mnt/data/remco/packaging/firebird/uploaded/firebird_1.0.3-0mentors1_i386.changes. Checking Signature on .dsc gpg: Signature made Fri 04 Jun 2004 03:59:05 AM CEST using DSA key ID 954F5EC7 gpg: Good signature from "Remco Seesink <[EMAIL PROTECTED]>" Good signature on /mnt/data/remco/packaging/firebird/uploaded/firebird_1.0.3-0mentors1.dsc. Enter passphrase for key '/home/remco/.ssh/id_rsa': firebird_1.0.3-0mentors1.dsc 100% 881 0.9KB/s 00:00 firebird_1.0.3-0mentors1.diff.gz 100% 1086KB 15.7KB/s 01:09 firebird-examples_1.0.3-0mentors1_i386.deb100% 259KB 28.8KB/s 00:09 firebird-dev_1.0.3-0mentors1_i386.deb 100% 83KB 82.6KB/s 00:00 firebird-utils_1.0.3-0mentors1_i386.deb 100% 638KB 18.2KB/s 00:35 firebird-server-common_1.0.3-0mentors1_i386.deb 100% 468KB 18.7KB/s 00:25 libfirebird-c32_1.0.3-0mentors1_i386.deb 100% 667KB 16.7KB/s 00:40 libfirebird-s32_1.0.3-0mentors1_i386.deb 100% 142KB 35.4KB/s 00:04 libfirebird-c64_1.0.3-0mentors1_i386.deb 100% 667KB 17.1KB/s 00:39 libfirebird-s64_1.0.3-0mentors1_i386.deb 100% 142KB 35.4KB/s 00:04 firebird-c32-server_1.0.3-0mentors1_i386.deb 100% 180KB 44.9KB/s 00:04 firebird-s32-server_1.0.3-0mentors1_i386.deb 100% 833KB 16.0KB/s 00:52 firebird-c64-server_1.0.3-0mentors1_i386.deb 100% 180KB 45.0KB/s 00:04 firebird-s64-server_1.0.3-0mentors1_i386.deb 100% 833KB 16.0KB/s 00:52 firebird_1.0.3-0mentors1_i386.changes 100% 3423 3.3KB/s 00:00 Successfully uploaded packages. Not running dinstall. - The manpage of dput doesn't help me with that. Any suggestions how to get firebird_1.0.3.orig.tar.gz uploaded? Many thanks, Remco. On Thu, 3 Jun 2004 21:19:43 +0200 Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > > Hello, > > > > I am preparing an updated package with an unsolved security bug. > > I would like to upload it to mentors.debian.net, but when it > > gets uploaded to main it will have the same version number as the > > one on mentors. I would to know if there is a way to upload to > > mentors and be sure it gets upgraded when it enters main. > > > > I had this problem before, but now it is worse because of the security > > bug. > > > > I looked at the policy and the reverse problem seems to be solved > > by using epochs. An negative epoch is not the way right? And how do > > I apply an epoch? Yada complains when I try to put an Version: field > > somewhere. > > > > Is there an other way to do it without having to bump the debian version? > > Or is that exactly what I should do? > > The proper way is to simply not upload to mentors.d.n with 'official' > debian revision numbers. Assuming the offical version will be 1.0-1, use > for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version > numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by > one, append a mentor-specific part). > > This way, there is never a clash, you can see from the version number > it's an unoffical version. > > Two alternative approaches: > - simply increment debian revision, and use -v appropriately, it doesn't > matter certain debian-revisions are never uploaded. Disadvantage: > changelog cluttering, usually people won't have those unofficial > intermediate versions, and the differences among those are not very > interesting usually. If you merge the topmost changelog entry every > time, you seemingly have gaps in version numbering according to > changelog, not very nice either. > - Don't care about m.d.n, simply have your fixed version uploaded with > the same version number. m.d.n is unoffical anyway, you in no way have > to take care of proper upgrade paths at all. Disadvantage: in > bugreports with reportbug, and for the user itself, it's hard to see > whether the user/reporter has a
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Fri, Jun 04, 2004 at 04:26:05AM +0200, Remco Seesink wrote: > The manpage of dput doesn't help me with that. Any suggestions how to get > firebird_1.0.3.orig.tar.gz uploaded? -sa on dpkg-buildpackage (or debuild) See dpkg-buildpackage(1) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Long double alignment test
Mentors,
This may be a full-on d-devel question, but I'll start out here.
I'm maintaining GNU Smalltalk, which is having problems building on
most 64-bit platforms. I'm having difficulty tracking these problems
down, so I'm asking for some assistance from anyone who has access to
these platforms (any DD, I believe).
The issue is with a test for long double alignment which reports an
incorrect value on ia64 (and probably other archs). On a RedHat
mailing list I have found the following code which is claimed to
correctly detect long double alignment:
http://sources.redhat.com/ml/autoconf/1999-07/msg2.html
struct foo {
union align {
double d;
long l;
void *p;
} u;
char c;
};
int main() {
struct foo f[2];
printf("sizeof(foo)=%ld\n", (long) sizeof(struct foo));
printf("sizeof(align)=%ld\n", (long) sizeof(union align));
printf("sizeof(f2)=%ld\n", (long) sizeof(f));
if( 2*sizeof(union align) != sizeof(f) ) {
printf("union may be aligned on %ld byte boundaries.\n",
(long)(sizeof(struct foo) - sizeof(union align)));
return 1;
}
printf("union must be aligned on %ld byte boundaries.\n",
(long)sizeof(union align));
return 0;
}
Anyone know if this works? Could someone please run this on each of
the archs we support (particularly ia64) and report the results to me?
Does anyone have any better code for discovering alignment? I'm
surprised this isn't common enough that there would be a stock
solution.
Thanks in advance,
-- Brett
signature.asc
Description: Digital signature
Re: Long double alignment test
Brett Cundal wrote: > This may be a full-on d-devel question, but I'll start out here. > I'm maintaining GNU Smalltalk, which is having problems building on > most 64-bit platforms. This should probably go to the appropriate arch-specific mailing lists (e.g. debian-ia64). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Long double alignment test
Brett Cundal writes:
> The issue is with a test for long double alignment which reports an
> incorrect value on ia64 (and probably other archs).
> [...]
> Anyone know if this works?
The code which was posted doesn't use the long double type, which
makes the idea of it giving the alignment of that type somewhat
doubtful. A processor could have special alignment issues to do with
long doubles which don't show up in long, double or void* (due to a
weird floating point unit).
I believe that the "if" condition is never false because "f" contains
two unions and two chars, so its size is greater than that of two
unions (by at least two chars) and therefore not equal. As a result,
it seems to give the alignment of the union, which is the maximum
alignment of the three types inside.
I prefer the code below. Enjoy!
Cheers, Neil.
#include
#define ALIGN_OF(t) \
((int)(sizeof( \
struct { \
char c; \
t x; \
}) \
- sizeof(t) ))
int main()
{
printf("char: %d\n", ALIGN_OF(char));
printf("short: %d\n", ALIGN_OF(short));
printf("int: %d\n", ALIGN_OF(int));
printf("long: %d\n", ALIGN_OF(long));
printf("long long: %d\n", ALIGN_OF(long long));
printf("void*: %d\n", ALIGN_OF(void*));
printf("float: %d\n", ALIGN_OF(float));
printf("double: %d\n", ALIGN_OF(double));
printf("long double: %d\n", ALIGN_OF(long double));
return 0;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Long double alignment test
Brett Cundal <[EMAIL PROTECTED]> writes:
> Mentors,
>
> This may be a full-on d-devel question, but I'll start out here.
>
> I'm maintaining GNU Smalltalk, which is having problems building on
> most 64-bit platforms. I'm having difficulty tracking these problems
> down, so I'm asking for some assistance from anyone who has access to
> these platforms (any DD, I believe).
>
> The issue is with a test for long double alignment which reports an
> incorrect value on ia64 (and probably other archs). On a RedHat
> mailing list I have found the following code which is claimed to
> correctly detect long double alignment:
>
> http://sources.redhat.com/ml/autoconf/1999-07/msg2.html
>
> struct foo {
> union align {
> double d;
> long l;
> void *p;
> } u;
> char c;
> };
>
> int main() {
> struct foo f[2];
>
> printf("sizeof(foo)=%ld\n", (long) sizeof(struct foo));
> printf("sizeof(align)=%ld\n", (long) sizeof(union align));
> printf("sizeof(f2)=%ld\n", (long) sizeof(f));
>
> if( 2*sizeof(union align) != sizeof(f) ) {
> printf("union may be aligned on %ld byte boundaries.\n",
> (long)(sizeof(struct foo) - sizeof(union align)));
> return 1;
> }
>
> printf("union must be aligned on %ld byte boundaries.\n",
> (long)sizeof(union align));
> return 0;
> }
>
> Anyone know if this works? Could someone please run this on each of
> the archs we support (particularly ia64) and report the results to me?
>
> Does anyone have any better code for discovering alignment? I'm
> surprised this isn't common enough that there would be a stock
> solution.
Debian-amd64:
sizeof(foo)=16
sizeof(align)=8
sizeof(f2)=32
union may be aligned on 8 byte boundaries.
>
> Thanks in advance,
>
> -- Brett
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Long double alignment test
Neil Turton <[EMAIL PROTECTED]> writes:
> Brett Cundal writes:
> > The issue is with a test for long double alignment which reports an
> > incorrect value on ia64 (and probably other archs).
> > [...]
> > Anyone know if this works?
>
> The code which was posted doesn't use the long double type, which
> makes the idea of it giving the alignment of that type somewhat
> doubtful. A processor could have special alignment issues to do with
> long doubles which don't show up in long, double or void* (due to a
> weird floating point unit).
>
> I believe that the "if" condition is never false because "f" contains
> two unions and two chars, so its size is greater than that of two
> unions (by at least two chars) and therefore not equal. As a result,
> it seems to give the alignment of the union, which is the maximum
> alignment of the three types inside.
If the alignment of the union is bigger than the union itself the char
can be merged into the alignment of the union and not take any space
at all. In that case the size of the union would be the alignment.
> I prefer the code below. Enjoy!
>
> Cheers, Neil.
>
> #include
>
> #define ALIGN_OF(t) \
> ((int)(sizeof( \
> struct { \
>char c; \
>t x; \
> }) \
>- sizeof(t) ))
>
> int main()
> {
> printf("char: %d\n", ALIGN_OF(char));
> printf("short: %d\n", ALIGN_OF(short));
> printf("int: %d\n", ALIGN_OF(int));
> printf("long: %d\n", ALIGN_OF(long));
> printf("long long: %d\n", ALIGN_OF(long long));
> printf("void*: %d\n", ALIGN_OF(void*));
> printf("float: %d\n", ALIGN_OF(float));
> printf("double: %d\n", ALIGN_OF(double));
> printf("long double: %d\n", ALIGN_OF(long double));
> return 0;
> }
Nice.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to get package in main with the same version to upgrade over a mentors.debian.net version?
Hello, I am preparing an updated package with an unsolved security bug. I would like to upload it to mentors.debian.net, but when it gets uploaded to main it will have the same version number as the one on mentors. I would to know if there is a way to upload to mentors and be sure it gets upgraded when it enters main. I had this problem before, but now it is worse because of the security bug. I looked at the policy and the reverse problem seems to be solved by using epochs. An negative epoch is not the way right? And how do I apply an epoch? Yada complains when I try to put an Version: field somewhere. Is there an other way to do it without having to bump the debian version? Or is that exactly what I should do? Cheers, Remco. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > I am preparing an updated package with an unsolved security bug. > I would like to upload it to mentors.debian.net, but when it > gets uploaded to main it will have the same version number as the > one on mentors. I would to know if there is a way to upload to > mentors and be sure it gets upgraded when it enters main. > > I had this problem before, but now it is worse because of the security > bug. > > I looked at the policy and the reverse problem seems to be solved > by using epochs. An negative epoch is not the way right? And how do > I apply an epoch? Yada complains when I try to put an Version: field > somewhere. > > Is there an other way to do it without having to bump the debian version? > Or is that exactly what I should do? Hmm... but why don't you want to simply bump this version? IMHO 1.2.3-4 looks much better than 1:1.2.3-3. And in fact I think the proper way would be to add exacly bumped version, and in changelog set urgency=high (due to security bug). Or maybe your problem is that you don't want to "start" in official archives with for example -2 version? If yes then I have no idea why ;) regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
Remco Seesink wrote: > I am preparing an updated package with an unsolved security bug. I > would like to upload it to mentors.debian.net, but when it gets > uploaded to main it will have the same version number as the one on > mentors. I would to know if there is a way to upload to mentors and be > sure it gets upgraded when it enters main. If the new package is different from the package on m.d.n, then you should add a new changelog entry and increment the Debian version number. Users will automatically be upgraded to the newer version. > I looked at the policy and the reverse problem seems to be solved by > using epochs. An negative epoch is not the way right? And how do I > apply an epoch? Yada complains when I try to put an Version: field > somewhere. An epoch should rarely be used. It is not appropriate or necessary in this case. (Epochs are usually used when the upstream versioning scheme changes, like when Mozilla upgraded from version M18 to version 0.6.) > Is there an other way to do it without having to bump the debian > version? Or is that exactly what I should do? Yes, you should bump the debian version. Use "dpkg-buildpackage -v" when uploading the package to the archive to include all of the relevant changelog entries in the uploaded "changes" file (including changes from versions that were uploaded to m.d.n only). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > Hello, > > I am preparing an updated package with an unsolved security bug. > I would like to upload it to mentors.debian.net, but when it > gets uploaded to main it will have the same version number as the > one on mentors. I would to know if there is a way to upload to > mentors and be sure it gets upgraded when it enters main. > > I had this problem before, but now it is worse because of the security > bug. > > I looked at the policy and the reverse problem seems to be solved > by using epochs. An negative epoch is not the way right? And how do > I apply an epoch? Yada complains when I try to put an Version: field > somewhere. > > Is there an other way to do it without having to bump the debian version? > Or is that exactly what I should do? The proper way is to simply not upload to mentors.d.n with 'official' debian revision numbers. Assuming the offical version will be 1.0-1, use for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by one, append a mentor-specific part). This way, there is never a clash, you can see from the version number it's an unoffical version. Two alternative approaches: - simply increment debian revision, and use -v appropriately, it doesn't matter certain debian-revisions are never uploaded. Disadvantage: changelog cluttering, usually people won't have those unofficial intermediate versions, and the differences among those are not very interesting usually. If you merge the topmost changelog entry every time, you seemingly have gaps in version numbering according to changelog, not very nice either. - Don't care about m.d.n, simply have your fixed version uploaded with the same version number. m.d.n is unoffical anyway, you in no way have to take care of proper upgrade paths at all. Disadvantage: in bugreports with reportbug, and for the user itself, it's hard to see whether the user/reporter has an unoffical version, or the official one. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Long double alignment test
Brett Cundal wrote: > I'm maintaining GNU Smalltalk, which is having problems building on > most 64-bit platforms. I'm having difficulty tracking these problems > down, so I'm asking for some assistance from anyone who has access to > these platforms (any DD, I believe). > Anyone know if this works? Could someone please run this on each of the archs we support (particularly ia64) and report the results to me? Here's another 64-bit arch to compare to, I was curious about the answer myself. [EMAIL PROTECTED]:~/tmp$ uname -a Linux moltar 2.4.26-sparc64 #1 Sat Apr 24 01:43:10 EDT 2004 sparc64 GNU/Linux [EMAIL PROTECTED]:~/tmp$ ./longalign # your code sizeof(foo)=16 sizeof(align)=8 sizeof(f2)=32 union may be aligned on 8 byte boundaries. [EMAIL PROTECTED]:~/tmp$ ./longalign2 # Neil's code char: 1 short: 2 int: 4 long: 4 long long: 8 void*: 4 float: 4 double: 8 long double: 8 - David A. Riggs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 12:09:53PM -0700, Matt Brubeck wrote: > > Is there an other way to do it without having to bump the debian > > version? Or is that exactly what I should do? > > Yes, you should bump the debian version. > > Use "dpkg-buildpackage -v" when uploading the package to the archive to > include all of the relevant changelog entries in the uploaded "changes" > file (including changes from versions that were uploaded to m.d.n only). And "-sa" switch to include sources with upload other than -1 ;) regards fEnIo -- _ Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | IRC:fEnIo _|_|_ 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Polska (0 0) phone:+48602383548 | Slackware - the weakest link ooO--(_)--Ooo http://skawina.eu.org | JID:[EMAIL PROTECTED] | RLU:172001 signature.asc Description: Digital signature
Deals come once in a lifetime
G E TY O U R U N I V E R S I T Y D I P L O M A Do you want a prosperous future, increased earning power more money and the respect of all? Call this number: 1 775 490 9881 (24 hours) There are no required tests, classes, books, or interviews! Get a Bachelors, Masters, MBA, GED and Doctorate (PhD) diploma! Receive the benefits and admiration that comes with a diploma! No one is turned down! Call Today 1 775 490 9881 (7 days a week) Confidentiality assured! 226.37.121.228 130.25.30.70 60.82.68.77 222.36.120.220 190.2.57.86 156.16661.195 64.161.80.160 239.96.16.202 163.227.0.8 184.165.72.6 Nicholas 120.46.32.43 105.226.188.180 Stroud 188.96.152.74 Nicholas Stroud 0.103.233.184 140.96.157.182 14.214.66.64 218.207.103.128 192.130.242.28 180.20.46.106 44.220.169.138 Nicholas Stroud 228.222.224.44 69.232.158.67 225.160.208.216 Nicholas Stroud 68.163.108.12 Nicholas Stroud 11.83.159.201 crutch knutson lobo beryllium kiwi cry cessna cottrell cage less Nicholas chieftain mineralogy Stroud sunshade Nicholas Stroud chill seminal somatic tidbit brig buss rhombi Nicholas Stroud boycott galvanic paz Nicholas Stroud doormen Nicholas Stroud pulpit 128.92.24.144 40.200.10.94 188.124.54.52 144.53.91.208 223.180.116.4 188.206.206.218 106.240.240.222 15.180.112.82 60.100.104.9 132.172.188.210 Nicholas 128.35.162.138 174.98.145.48 Stroud 89.238.145.119 Nicholas Stroud 252.248.64.44 10.64.156.20 245.45.176.130 84.152.96.176 210.42.12.119 192.64.52.155 24.220.0.184 Nicholas Stroud 52.233.136.210 202.244.216.114 88.255.110.148 Nicholas Stroud 124.24.80.120 Nicholas Stroud 29.51.55.80 Nicholas Stroud rotate chieftain bud Nicholas Stroud pretoria Nicholas Stroud rydberg midshipman nikolai sylvester attack chaw idaho covary lighten shopkeep brakeman Nicholas immigrate dactylic Stroud stool Nicholas Stroud jangle ludicrous cytology insufficient calisthenic transversal carbonyl Nicholas Stroud apport additive brooke Nicholas Stroud crises Nicholas Stroud baseplate crook infect Nicholas Stroud fount introspect pigpen carmela practise ackley decal osteology rosenberg myosin blackwell supervene dumpty Nicholas shawl automaton Stroud teethed Nicholas Stroud wink shea gist workforce prosopopoeia chop avertive Nicholas Stroud quadrant trapezium clonic Nicholas Stroud jitter Nicholas Stroud brandywine
Request For Sponsor : NWS - Grid monitoring infrastructure
Hey dudes, I have packaged the NWS, a computational grid monitoring infrastructure (ITP #167891, which I just enhanced), and I'm not seeking for a sponsor. == me: == In the NM process, maintainer of quilt (advanced patch management tool, which NWS build-depend on). Active member of Debian since years, coordinator of the debian french translation effort. === Package description: === Package: nws Description: Grid monitoring infrastructure (executables and man pages) The Network Weather Service is the de facto standard of the emerging Grid community to monitor the system availability. (the grid usually denotes any platform formed by the federation and aggregation of local resources between several organizations like universities). . Once you've deployed the relevant processes on each platform node, you can ask it for several metrics: . - about each host: - available CPU (both for incoming process and for already started ones) - free memory - free disk - about each host couple: - TCP connexion time, bandwidth and latency . Moreover, the NWS can predict future tendencies using statistical treatements on previous measurements. . This package installs the library, utilities and user documentation. Package: libnws-dev Description: Grid monitoring infrastructure (headers and devel documentation) [same blurb about NWS itself cutted from this mail for clarity] . This package contains the files you need to compile programs which use this library. === Licence: (BSD-like) === Copyright (c) 2002, The Regents of the University of California All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. Neither the names of the University of California, nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. === package: === The package is linda clean, beside of the following points: W: libnws-dev; Executable /usr/include/nws_api.h with perms 0755 is not an ELF file or script. W: libnws-dev; Executable /usr/include/nws_forecast_api.h with perms 0755 is not an ELF file or script. I provided a patch for debhelper to solve that point. That's #252492, opened today. The package uploaded does not have this warning, since I compiled it on my own box with a modified debhelper. E: nws; No manual page for binary nws_add_forecast. E: nws; No manual page for binary nws_ctrl_activity. E: nws; No manual page for binary nws_ctrl_mem. E: nws; No manual page for binary nws_insert. E: nws; No manual page for binary nws_setup. Reported upstream. They are not critical elements of the infrastructure. This is my fault for nws_ctrl_activity and nws_setup (debian specific parts). Lintian also reports: E: nws: shell-script-fails-syntax-check ./usr/bin/nws_hostadmin Reported upstream. I'll drop it soon, I guess. It is available from my web page: http://graal.ens-lyon.fr/~mquinson/grid.html#nws deb http://graal.ens-lyon.fr/~mquinson/grid unstable deb-src http://graal.ens-lyon.fr/~mquinson/grid unstable and also from mentors.d.n: http://mentors.debian.net/debian/pool/main/n/nws/ Thank you for your time and I am looking forward to reading your suggestions on how to improve the package and/or offers for sponsorship! Bye, Mt. -- I don't care whichever programming language we choose, as long as it's C. signature.asc Description: Digital signature
RFS: dmalloc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi I'm looking for a sponsor for dmalloc. The package is DFSG free. It consists of following binary packages: Package: dmalloc Description: Debug memory allocation library - transition package ~ This is an empty package which depends on libdmalloc4, to provide for ~ smooth upgrades. It can safely be removed. Package: libdmalloc4 Description: Debug memory allocation library ~ Drop in replacement for the system's `malloc', `realloc', `calloc', `free' ~ and other memory management routines while providing powerful debugging ~ facilities configurable at runtime. ~ . ~ These facilities include such things as memory-leak tracking, fence-post ~ write detection, file/line number reporting, and general logging of ~ statistics. ~ . ~ This package contains only the shared libraries, the development files and ~ documentation is in the -dev-package. Package: libdmalloc4-dev Description: Debug memory allocation library - development files and docs ~ Drop in replacement for the system's `malloc', `realloc', `calloc', `free' ~ and other memory management routines while providing powerful debugging ~ facilities configurable at runtime. ~ . ~ These facilities include such things as memory-leak tracking, fence-post ~ write detection, file/line number reporting, and general logging of ~statistics. ~ . ~ This package contains the static libraries and the documentation. The package can be obtained from mentors.debian.net or deb-src http://zeus.ugent.be/~luk pool/ Cheers Luk -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAv4dS5UTeB5t8Mo0RAi24AJ4wRJWSkFH2CE4xUEwh5kJWRQSJQACgnbMq m+nnQPeWp57Av9n9gQA0pYc= =D4is -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Long double alignment test
Hi Brett! You wrote: > Anyone know if this works? Could someone please run this on each of > the archs we support (particularly ia64) and report the results to me? Ok. alpha: your code: sizeof(foo)=16 sizeof(align)=8 sizeof(f2)=32 union may be aligned on 8 byte boundaries. Neal's code: char: 1 short: 2 int: 4 long: 8 long long: 8 void*: 8 float: 4 double: 8 long double: 8 ia64: your code: sizeof(foo)=16 sizeof(align)=8 sizeof(f2)=32 union may be aligned on 8 byte boundaries. Neal's: char: 1 short: 2 int: 4 long: 8 long long: 8 void*: 8 float: 4 double: 8 long double: 16 -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 09:19:43PM +0200, Jeroen van Wolffelaar wrote: > On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > > Hello, > > > > I am preparing an updated package with an unsolved security bug. > > I would like to upload it to mentors.debian.net, but when it > > gets uploaded to main it will have the same version number as the > > one on mentors. I would to know if there is a way to upload to > > mentors and be sure it gets upgraded when it enters main. > > > > I had this problem before, but now it is worse because of the security > > bug. > > > > I looked at the policy and the reverse problem seems to be solved > > by using epochs. An negative epoch is not the way right? And how do > > I apply an epoch? Yada complains when I try to put an Version: field > > somewhere. > > > > Is there an other way to do it without having to bump the debian version? > > Or is that exactly what I should do? > > The proper way is to simply not upload to mentors.d.n with 'official' > debian revision numbers. Assuming the offical version will be 1.0-1, use > for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version > numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by > one, append a mentor-specific part). Gee, I real need to find back that document that wrote to use 1.0-0.1, 1.0-0.2, 1.0-0.3 etc for non official debian packages. > > This way, there is never a clash, you can see from the version number > it's an unoffical version. > > Two alternative approaches: > - simply increment debian revision, and use -v appropriately, it doesn't > matter certain debian-revisions are never uploaded. Disadvantage: > changelog cluttering, usually people won't have those unofficial > intermediate versions, and the differences among those are not very > interesting usually. If you merge the topmost changelog entry every > time, you seemingly have gaps in version numbering according to > changelog, not very nice either. > - Don't care about m.d.n, simply have your fixed version uploaded with > the same version number. m.d.n is unoffical anyway, you in no way have > to take care of proper upgrade paths at all. Disadvantage: in > bugreports with reportbug, and for the user itself, it's hard to see > whether the user/reporter has an unoffical version, or the official > one. > > --Jeroen > > -- > Jeroen van Wolffelaar > [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) > http://Jeroen.A-Eskwadraat.nl Cheers Geert Stappers pgpg0tzjGzgcR.pgp Description: PGP signature
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
Geert Stappers wrote: > > The proper way is to simply not upload to mentors.d.n with > > 'official' debian revision numbers. Assuming the offical version > > will be 1.0-1, use for example 1.0-1~mentors1 (if mentors.d.n > > accepts ~ in version numbers), or alternatively 1.0-0mentors1 > > (decrease debian-revision by one, append a mentor-specific part). > > Gee, I real need to find back that document that wrote to use > > 1.0-0.1, 1.0-0.2, 1.0-0.3 etc for non official debian packages. I don't think this is a good idea, because those numbers are used for non-maintainer uploads. You could have different versions with the same number, one uploaded to m.d.n and the other uploaded to the main archive as an NMU. It's also confusing because it looks like an NMU. I think numbers like 1.0-0test1 (where "test" can be any string) are best, if you need to create separate testing versions that will not be uploaded to the archive. This method is used by other Debian developers including the XFree86 maintainers (c.f. xfree86 4.3.0-0pre1v3). I use normal versions like 1.2.1-1 when uploading to m.d.n, and this hasn't caused any problems. If no bugs are found in the m.d.n package, I send it to my sponsor to be uploaded with no further changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Письмо
Самое эффективное средство защиты от бродячих и агрессивных собак. http://www.DAZER2.ru/?rgiFv8p (095) 258-0083 бересту, то есть верхнюю кожу
Re: Request For Sponsor : NWS - Grid monitoring infrastructure
also sprach Martin Quinson <[EMAIL PROTECTED]> [2004.06.03.2220 +0200]: > I have packaged the NWS, a computational grid monitoring > infrastructure (ITP #167891, which I just enhanced), and I'm not > seeking for a sponsor. You're not? If you are... then I'd be willing... -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
[EMAIL PROTECTED] (Geert Stappers) writes: > On Thu, Jun 03, 2004 at 09:19:43PM +0200, Jeroen van Wolffelaar wrote: >> On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: >> > Hello, >> > >> > I am preparing an updated package with an unsolved security bug. >> > I would like to upload it to mentors.debian.net, but when it >> > gets uploaded to main it will have the same version number as the >> > one on mentors. I would to know if there is a way to upload to >> > mentors and be sure it gets upgraded when it enters main. >> > >> > I had this problem before, but now it is worse because of the security >> > bug. >> > >> > I looked at the policy and the reverse problem seems to be solved >> > by using epochs. An negative epoch is not the way right? And how do >> > I apply an epoch? Yada complains when I try to put an Version: field >> > somewhere. >> > >> > Is there an other way to do it without having to bump the debian version? >> > Or is that exactly what I should do? >> >> The proper way is to simply not upload to mentors.d.n with 'official' >> debian revision numbers. Assuming the offical version will be 1.0-1, use >> for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version >> numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by >> one, append a mentor-specific part). > > Gee, I real need to find back that document that wrote to use > > 1.0-0.1, 1.0-0.2, 1.0-0.3 etc for non official debian packages. That would be a NMU of a non native debian package. 1.0-0.0.1 would be a recompile binary only NMU of a non-native debian package. See policy. 1.0-0.0.0.1 would be free but 1.0-0mentors1 or 1.0-1~mentors is nicer. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
Hi all, Thank you all for the suggestions. I am uploading new firebird packages right now with this method: > or alternatively 1.0-0mentors1 (decrease debian-revision by > one, append a mentor-specific part). I wanted to prevent confusion in main when debian revisions are missing, and to keep the changelog clean. I like to document all my mistakes on mentors and get a clean version in main when I am ready. In case you were wondering, the unsolved security bug is: #251458 Urgh. I just noticed it didn't upload the original source: -- [EMAIL PROTECTED]:~/packaging/firebird/uploaded$ dput mentors firebird_1.0.3-0mentors1_i386.changes Checking Signature on .changes gpg: Signature made Fri 04 Jun 2004 03:59:11 AM CEST using DSA key ID 954F5EC7 gpg: Good signature from "Remco Seesink <[EMAIL PROTECTED]>" Good signature on /mnt/data/remco/packaging/firebird/uploaded/firebird_1.0.3-0mentors1_i386.changes. Checking Signature on .dsc gpg: Signature made Fri 04 Jun 2004 03:59:05 AM CEST using DSA key ID 954F5EC7 gpg: Good signature from "Remco Seesink <[EMAIL PROTECTED]>" Good signature on /mnt/data/remco/packaging/firebird/uploaded/firebird_1.0.3-0mentors1.dsc. Enter passphrase for key '/home/remco/.ssh/id_rsa': firebird_1.0.3-0mentors1.dsc 100% 881 0.9KB/s 00:00 firebird_1.0.3-0mentors1.diff.gz 100% 1086KB 15.7KB/s 01:09 firebird-examples_1.0.3-0mentors1_i386.deb100% 259KB 28.8KB/s 00:09 firebird-dev_1.0.3-0mentors1_i386.deb 100% 83KB 82.6KB/s 00:00 firebird-utils_1.0.3-0mentors1_i386.deb 100% 638KB 18.2KB/s 00:35 firebird-server-common_1.0.3-0mentors1_i386.deb 100% 468KB 18.7KB/s 00:25 libfirebird-c32_1.0.3-0mentors1_i386.deb 100% 667KB 16.7KB/s 00:40 libfirebird-s32_1.0.3-0mentors1_i386.deb 100% 142KB 35.4KB/s 00:04 libfirebird-c64_1.0.3-0mentors1_i386.deb 100% 667KB 17.1KB/s 00:39 libfirebird-s64_1.0.3-0mentors1_i386.deb 100% 142KB 35.4KB/s 00:04 firebird-c32-server_1.0.3-0mentors1_i386.deb 100% 180KB 44.9KB/s 00:04 firebird-s32-server_1.0.3-0mentors1_i386.deb 100% 833KB 16.0KB/s 00:52 firebird-c64-server_1.0.3-0mentors1_i386.deb 100% 180KB 45.0KB/s 00:04 firebird-s64-server_1.0.3-0mentors1_i386.deb 100% 833KB 16.0KB/s 00:52 firebird_1.0.3-0mentors1_i386.changes 100% 3423 3.3KB/s 00:00 Successfully uploaded packages. Not running dinstall. - The manpage of dput doesn't help me with that. Any suggestions how to get firebird_1.0.3.orig.tar.gz uploaded? Many thanks, Remco. On Thu, 3 Jun 2004 21:19:43 +0200 Jeroen van Wolffelaar <[EMAIL PROTECTED]> wrote: > On Thu, Jun 03, 2004 at 08:48:55PM +0200, Remco Seesink wrote: > > Hello, > > > > I am preparing an updated package with an unsolved security bug. > > I would like to upload it to mentors.debian.net, but when it > > gets uploaded to main it will have the same version number as the > > one on mentors. I would to know if there is a way to upload to > > mentors and be sure it gets upgraded when it enters main. > > > > I had this problem before, but now it is worse because of the security > > bug. > > > > I looked at the policy and the reverse problem seems to be solved > > by using epochs. An negative epoch is not the way right? And how do > > I apply an epoch? Yada complains when I try to put an Version: field > > somewhere. > > > > Is there an other way to do it without having to bump the debian version? > > Or is that exactly what I should do? > > The proper way is to simply not upload to mentors.d.n with 'official' > debian revision numbers. Assuming the offical version will be 1.0-1, use > for example 1.0-1~mentors1 (if mentors.d.n accepts ~ in version > numbers), or alternatively 1.0-0mentors1 (decrease debian-revision by > one, append a mentor-specific part). > > This way, there is never a clash, you can see from the version number > it's an unoffical version. > > Two alternative approaches: > - simply increment debian revision, and use -v appropriately, it doesn't > matter certain debian-revisions are never uploaded. Disadvantage: > changelog cluttering, usually people won't have those unofficial > intermediate versions, and the differences among those are not very > interesting usually. If you merge the topmost changelog entry every > time, you seemingly have gaps in version numbering according to > changelog, not very nice either. > - Don't care about m.d.n, simply have your fixed version uploaded with > the same version number. m.d.n is unoffical anyway, you in no way have > to take care of proper upgrade paths at all. Disadvantage: in > bugreports with reportbug, and for the user itself, it's hard to see > whether the user/reporter has an unoffical ver
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Fri, Jun 04, 2004 at 04:26:05AM +0200, Remco Seesink wrote: > The manpage of dput doesn't help me with that. Any suggestions how to get > firebird_1.0.3.orig.tar.gz uploaded? -sa on dpkg-buildpackage (or debuild) See dpkg-buildpackage(1) --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Request For Sponsor : NWS - Grid monitoring infrastructure
* Martin Quinson <[EMAIL PROTECTED]> [2004-06-03 13:20:32 -0700]: > > I have packaged the NWS, a computational grid monitoring infrastructure (ITP > #167891, which I just enhanced), and I'm not seeking for a sponsor. Hi Martin, I'm Mats from ISI, and I know Larry at UCSB has tried to introduce us earlier. As you probably already know, I'm very familiar with NWS and will be happy to sponsor it. If you are interested, we can talk about details off-list. -- Mats Rynge ,''`. Got Woody? : :' :http://www.debian.org `. `' `- signature.asc Description: Digital signature
Re: How to get package in main with the same version to upgrade over a mentors.debian.net version?
On Thu, Jun 03, 2004 at 03:30:12PM -0700, Matt Brubeck wrote: > Geert Stappers wrote: > > > > The proper way is to simply not upload to mentors.d.n with > > > 'official' debian revision numbers. Assuming the offical version > > > will be 1.0-1, use for example 1.0-1~mentors1 (if mentors.d.n > > > accepts ~ in version numbers), or alternatively 1.0-0mentors1 > > > (decrease debian-revision by one, append a mentor-specific part). > > > > Gee, I real need to find back that document that wrote to use > > > > 1.0-0.1, 1.0-0.2, 1.0-0.3 etc for non official debian packages. > > I don't think this is a good idea, because those numbers are used for > non-maintainer uploads. You could have different versions with the same > number, one uploaded to m.d.n and the other uploaded to the main archive > as an NMU. It's also confusing because it looks like an NMU. Relax. Offical Debian package numbers start with x.y.z-1, never as x.y.z-0 There is no harm that it _looks_ like a NMU, it does mean no official Debian status. Please assume smart users that can tell the difference between zero and non zero. About: > You could have different versions with the same > number, one uploaded to m.d.n and the other uploaded to the main archive > as an NMU. What a b..ls..t, main archive wouldn't have a x.y.z-0.1 And when will happen x.y.z-1.1, a NMU on a mentors.debian.net package? > > I think numbers like 1.0-0test1 (where "test" can be any string) are > best, if you need to create separate testing versions that will not be > uploaded to the archive. This method is used by other Debian developers > including the XFree86 maintainers (c.f. xfree86 4.3.0-0pre1v3). Yes, there are situations where it makes sense to have x.y.z-0pre1v3 > > I use normal versions like 1.2.1-1 when uploading to m.d.n, and this > hasn't caused any problems. If no bugs are found in the m.d.n package, > I send it to my sponsor to be uploaded with no further changes. This conversation is about having _different_ package numbers in m.d.n. and main archive, plus upgrade path to the offical package. Do you and your users a favour, and use a way where you can have several unofficial packages and smooth upgrade to the official package. Say x.y.z-0.1, x.y.z-0sss1 or x.y.z-0whatever1. It is up to you to choose, dpkg --compare-versions doesn't care. Cheers Geert Stappers -- sss : stupid short string pgpPpBD0szIvp.pgp Description: PGP signature
