On Sun, Jun 24, 2012 at 11:29:56AM +0100, Lars Wirzenius wrote:
> On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote:
> > CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
> > believe was introduced by Autoconf
>
> I don't know the history of CPPFLAGS. It's possible it
On 27/06/12 14:20, Ben Hutchings wrote:
> On Wed, 2012-06-27 at 14:09 +0300, Serge wrote:
>> 2012/6/25 Ben Hutchings wrote:
>>
BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
and they use it in CFLAGS/CXXFLAGS.
>>>
>>> Presumably as a workaround for build systems that
On Wed, 2012-06-27 at 14:09 +0300, Serge wrote:
> 2012/6/25 Ben Hutchings wrote:
>
> >> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
> >> and they use it in CFLAGS/CXXFLAGS.
> >
> > Presumably as a workaround for build systems that do not respect
> > CPPFLAGS.
>
> I actual
2012/6/25 Ben Hutchings wrote:
>> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
>> and they use it in CFLAGS/CXXFLAGS.
>
> Presumably as a workaround for build systems that do not respect
> CPPFLAGS.
I actually noticed that because it's "-Wp,-D...", not "-D...". But I guess
* Ben Hutchings [120625 19:21]:
> GNU make's implicit rules use CPPFLAGS. If other build systems or
> overriden rules don't use it, it's a bug. This can of course be
> worked around in debian/rules.
I'd not call it a bug. It's just some stranger behavior. Not more strange
than not using make bu
On Mon, Jun 25, 2012 at 06:55:53PM +0300, Serge wrote:
> 2012/6/24 Guillem Jover wrote:
>
> >> Why? Just to have it autotools-compatible? If I was writing a custom
> >> build system I would be thinking about using -Wp option, since that's
> >> exactly why it's there for — to pass some options to t
2012/6/24 Guillem Jover wrote:
>> Why? Just to have it autotools-compatible? If I was writing a custom
>> build system I would be thinking about using -Wp option, since that's
>> exactly why it's there for — to pass some options to the preprocessor
>> (or, being honest, I would ignore CPPFLAGS unl
* Russ Allbery [120624 23:13]:
> When integrating with a build system that uses only one variable for
> compilation flags, just pass the concatenation of CFLAGS and CPPFLAGS into
> it. This is trivially done in debian/rules without modifying the upstream
> source.
Build systems not doing CPPFLAG
"Bernhard R. Link" writes:
> * Lars Wirzenius [120624 12:30]:
>> On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote:
>>> CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
>>> believe was introduced by Autoconf
>> I don't know the history of CPPFLAGS. It's possible i
* Lars Wirzenius [120624 12:30]:
> On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote:
> > CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
> > believe was introduced by Autoconf
>
> I don't know the history of CPPFLAGS. It's possible it was introduced by
> Autoconf.
On Sat, Jun 23, 2012 at 03:27:07PM -0700, Russ Allbery wrote:
> CFLAGS is an old, long-standing make thing. CPPFLAGS is newer and I
> believe was introduced by Autoconf
I don't know the history of CPPFLAGS. It's possible it was introduced by
Autoconf. However, it is now embedded into the implicit
On Sun, 2012-06-24 at 11:07:05 +0300, Serge wrote:
> 2012/6/24 Russ Allbery wrote:
> >> If you do, then... How should they do that? I.e. if I specify:
> >> CPPFLAGS="blablabla hehehe hohoho"
> >> How should build system run gcc? Like that?
> >> gcc blablabla hehehe hohoho -c -o test.o test.c
>
2012/6/24 Russ Allbery wrote:
>> If you do, then... How should they do that? I.e. if I specify:
>> CPPFLAGS="blablabla hehehe hohoho"
>> How should build system run gcc? Like that?
>> gcc blablabla hehehe hohoho -c -o test.o test.c
>
> Yes.
Why? Just to have it autotools-compatible? If I was
Serge writes:
> Or you mean that they should run `gcc`/`g++` with CPPFLAGS?
Yes.
> If you do, then... How should they do that? I.e. if I specify:
> CPPFLAGS="blablabla hehehe hohoho"
> How should build system run gcc? Like that?
> gcc blablabla hehehe hohoho -c test.o test.c
Yes.
> Is the
2012/6/23 Adam Borowski wrote:
>> Correct me if I'm wrong, but IIRC the CPPFLAGS have nothing to do with C++.
>> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
>> So as far as I understand cmake (and every other build system) MUST ignore
>> the CPPFLAGS, right?
>
> They SH
Serge writes:
> 2012/6/23 Andrey Rahmatullin wrote:
>> Do you say that cpp(1) is not used in the build process of C and C++
>> software?
> Yes, unless you actually call `cpp` directly by your build scripts somewhy.
> Gcc uses internal preprocessor by default.
Same thing in different packaging.
2012/6/23 Andrey Rahmatullin wrote:
>> They're for `cpp` tool which is "The C PreProcessor" (check `man cpp`).
>> So as far as I understand cmake (and every other build system) MUST
>> ignore the CPPFLAGS, right?
>
> Do you say that cpp(1) is not used in the build process of C and C++
> software?
On Sat, Jun 23, 2012 at 11:08:50PM +0300, Serge wrote:
> 2012/6/19 José Luis Segura Lucas wrote:
> > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> > referred by lintian-info too. Using it I only need to define "export
> > DEB_BUILD_HARDENING=1" on my debian/rules and it adds
On Sat, Jun 23, 2012 at 11:08:50PM +0300, Serge wrote:
> > (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> > referred by lintian-info too. Using it I only need to define "export
> > DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> > CFLAGS and CXXFLAGS (C
2012/6/19 José Luis Segura Lucas wrote:
> (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> referred by lintian-info too. Using it I only need to define "export
> DEB_BUILD_HARDENING=1" on my debian/rules and it adds the CPPFLAGS to
> CFLAGS and CXXFLAGS (Cmake ignores CPPFLAGS)
On Tue, Jun 19, 2012 at 04:04:31PM +0200, José Luis Segura Lucas wrote:
> repository but not still in a numbered version, so, I tried to use the
> latest known version and add a ~TIMESTAMPgit... to the minor version
> number, but debuild warns me about the version 0.1.0~2012..git-1 is
> less th
On Tue, Jun 19, 2012 at 05:04:46PM +0200, José Luis Segura Lucas wrote:
> > I see several solutions there, and the hardening-wrapper one is in my
> > opinion the worst one: it adds a build dependency and it uses own set of
> > configuration variables, not compatible with dpkg-buildflags ones.
> Yes
El 19/06/12 16:56, Andrey Rahmatullin escribió:
> I see several solutions there, and the hardening-wrapper one is in my
> opinion the worst one: it adds a build dependency and it uses own set of
> configuration variables, not compatible with dpkg-buildflags ones.
Yes, it adds a build-dependency...
On Tue, Jun 19, 2012 at 04:42:33PM +0200, José Luis Segura Lucas wrote:
> > Why do you need hardening-wrapper? You should use flags set by
> > dpkg-buildflags.
> Because that
> (http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
> referred by lintian-info too. Using it I only need to
El 19/06/12 16:10, Andrey Rahmatullin escribió:
> Why do you need hardening-wrapper? You should use flags set by
> dpkg-buildflags.
Because that
(http://wiki.debian.org/Hardening#Notes_for_packages_using_CMake),
referred by lintian-info too. Using it I only need to define "export
DEB_BUILD_HARDENIN
t.
>
> What's the problem with this?
You should read http://bugs.debian.org/673112 mentioned in the lintian tag
description and use hardening-check --verbose on binaries reported. If
only memcpy and memmove are printed by hardening-check, you should ignore
the warning.
> My another q
till present.
What's the problem with this?
My another question is about the version numbering: the software is
still in development and they make a new minor version each week
(approximately). Sometimes I need to package something that is in their
repository but not still in a numbered v
Package: debian-policy
Version: 3.8.3.0
Severity: wishlist
User: debian-pol...@packages.debian.org
Usertags: normative issue
Hi,
Currently, there is some ambiguity in the areas of version
numbering, debian_revision, native packages, and requirement for a
diff.gz/orig.tar.gz files in a
ible with Debian's ordering.
>
> > The version numbers go like
> 4.1
> 4.12 -> 4.1.2
> 4.2rc -> 4.2~rc
> 4.2
> 4.21 -> 4.2.1
> (maybe 4.3)
>
> Mostly upstream compliant, modulo adding a period, no epochs, no
> willing upstream required -
.2rc -> 4.2~rc
4.2
4.21 -> 4.2.1
(maybe 4.3)
Mostly upstream compliant, modulo adding a period, no epochs, no
willing upstream required -- as long as upstream does not suddenly
change version numbering midstream.
manoj
--
If at first you don't succeed, you're doin
ee it there are three ways to fix this:
>
> - persuade upstream to change the version numbering
> - add an epoch each time a new major release comes out (but policy
> discourages this - see note at the bottom of 5.6.12)
> - package 4.3, if/when it comes along, as 4.30 instead.
On Wed, 2008-08-27 at 12:51 +0100, Dominic Hargreaves wrote:
> - package 4.3, if/when it comes along, as 4.30 instead.
and continue to assume a '0' suffix if one is not present, so that 4.4
is actually 4.40 etc.
However, are you sure that getting upstream to use 4.3.0 isn't
achievable? 4.3.1 woul
-> 4.2~rc
> 4.2
> 4.21
-> 4.2.1
> (maybe 4.3)
> - persuade upstream to change the version numbering
Usually the best version, because most of the distributions have some
version comparision which will break on that versioning.
> - add an epoch each time a new major release comes o
age 4.21, but I'm aware that this leads the way
> to problems for 4.3.
>
> As I see it there are three ways to fix this:
>
> - persuade upstream to change the version numbering
> - add an epoch each time a new major release comes out (but policy
> discourages this - se
Hi,
On Wed, Aug 27, 2008 at 08:51, Dominic Hargreaves <[EMAIL PROTECTED]> wrote:
> I'm asking now in case there is another option which would require me
> doing something different for 4.21.
I'd add zeroes to the right, to have always two digits after the
point, which can be done automatically
package 4.21, but I'm aware that this leads the way
to problems for 4.3.
As I see it there are three ways to fix this:
- persuade upstream to change the version numbering
- add an epoch each time a new major release comes out (but policy
discourages this - see note at the bottom of 5.6.12)
On 2008-03-16, Adam D. Barratt <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote:
>> The current binNMU numbering scheme was selected explicitly to allow
>> security uploads to sort later by numbering as
>> +; e.g., 1.2-5.1+etch1.
>
> That makes sense, although do
Gunnar Wolf <[EMAIL PROTECTED]> writes:
> At some point in 2006, a serious flaw is addressed via a NMU, so
> it sits at 1.0+sarge1. I still cannot be bothered to take a look at
> the damn package. Time passes. In March 2008 it (again) shows it needs
> to be taken care of, and you kindly prepare a
Gunnar Wolf <[EMAIL PROTECTED]> writes:
> Russ Allbery dijo [Wed, Mar 19, 2008 at 12:05:53PM -0700]:
>> 1.0-1sarge1 >> 1.0-1etch1. We don't have this problem currently
>> because 1.0-1etch1 << 1.0-1lenny1, but we will again at some point in
>> the future, and it would be nice to resolve it once a
Russ Allbery dijo [Wed, Mar 19, 2008 at 12:05:53PM -0700]:
> >> Yes, sorry. I forgot that those exist as well. :-)
>
> > Why are we bothering to make something up if everyone is using etch
> > etc?
>
> 1.0-1sarge1 >> 1.0-1etch1. We don't have this problem currently because
> 1.0-1etch1 << 1.0-1
On Wed, Mar 19, 2008 at 07:54:46PM +0100, Luk Claes wrote:
> Bas Wijnen wrote:
> > On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
> >> Bas Wijnen <[EMAIL PROTECTED]> writes:
>
> >> We have other ways of tracking that information than the version, though.
> >
> > Yes, and I don't re
Luk Claes <[EMAIL PROTECTED]> writes:
> Bas Wijnen wrote:
>> Yes, sorry. I forgot that those exist as well. :-)
> Why are we bothering to make something up if everyone is using etch
> etc?
1.0-1sarge1 >> 1.0-1etch1. We don't have this problem currently because
1.0-1etch1 << 1.0-1lenny1, but we
Bas Wijnen wrote:
> On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
>> Bas Wijnen <[EMAIL PROTECTED]> writes:
>> We have other ways of tracking that information than the version, though.
>
> Yes, and I don't really care, I just think going from +s1+nmu1 to +s2
> seems to be doing th
On Wed, Mar 19, 2008 at 11:37:07AM -0700, Russ Allbery wrote:
> Bas Wijnen <[EMAIL PROTECTED]> writes:
>
> > You can base security uploads on NMUs, so I think you could get
> > +s1+nmu1+s1+nmu1, etc. Or should it go from +s1 to +s1+nmu1 to +s2 to
> > +s2+nmu1?
>
> I was assuming the latter.
>
>
Bas Wijnen <[EMAIL PROTECTED]> writes:
> You can base security uploads on NMUs, so I think you could get
> +s1+nmu1+s1+nmu1, etc. Or should it go from +s1 to +s1+nmu1 to +s2 to
> +s2+nmu1?
I was assuming the latter.
> I prefer the longer versions in this case. When a package gets too many
> se
On Mon, Mar 17, 2008 at 04:46:54PM +0100, Vincent Danjean wrote:
> Bas Wijnen wrote:
> > Ok, that makes sense. However, with +nmu1, there still is the problem
> > of how to name security uploads. With +s1, they sort after +nmu1, which
> > I think is wrong.
> >
> > But we're talking about uploads
Bas Wijnen <[EMAIL PROTECTED]> writes:
> Ok, that makes sense. However, with +nmu1, there still is the problem
> of how to name security uploads. With +s1, they sort after +nmu1, which
> I think is wrong.
There's no reason why we have to stick to one suffix. +s1+nmu1 for an NMU
after a securit
Bas Wijnen wrote:
> On Sun, Mar 16, 2008 at 06:40:25PM +, Adam D. Barratt wrote:
>> On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
>>> "Adam D. Barratt" <[EMAIL PROTECTED]> writes:
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
>> [...]
> Good idea. Even better, IMO, wou
On Sun, Mar 16, 2008 at 06:40:25PM +, Adam D. Barratt wrote:
> On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
> > "Adam D. Barratt" <[EMAIL PROTECTED]> writes:
> > > On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
> [...]
> > >> Good idea. Even better, IMO, would be to use a syste
Bas Wijnen wrote:
> This does break versions which go from 1 to 1.1 to 1.2 to 2 to 2.1, etc,
> but we're talking about native packages, which means we can expect
> upstream not to be so crazy.
People do this all the time, for completly sane reasons.
--
see shy jo
signature.asc
Description: Di
On Sun, 2008-03-16 at 11:22 -0700, Russ Allbery wrote:
> "Adam D. Barratt" <[EMAIL PROTECTED]> writes:
> > On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
[...]
> >> Good idea. Even better, IMO, would be to use a system which is in
> >> line with non-native packages. How about this rule:
> >
"Adam D. Barratt" <[EMAIL PROTECTED]> writes:
> On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
>> [Adding bug #437392 to Cc, which deals with this issue for normal
>> NMUs, because I'm making a suggestion about them.]
>>
>> On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
>>
On Sun, Mar 16, 2008 at 08:23:43PM +0900, Charles Plessy wrote:
> Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit :
> >
> > This could also lead to a problem in very rare cases: If a program has
> > the same version in stable and testing, and gets a security update, then
> > they both
On Sun, 2008-03-16 at 09:06 +0100, Bas Wijnen wrote:
> [Adding bug #437392 to Cc, which deals with this issue for normal
> NMUs, because I'm making a suggestion about them.]
>
> On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
> > devscripts 2.10.19 (soon to be uploaded) will modif
Le Sun, Mar 16, 2008 at 12:10:13PM +0100, Bas Wijnen a écrit :
>
> This could also lead to a problem in very rare cases: If a program has
> the same version in stable and testing, and gets a security update, then
> they both get a similar version. For the example, say 1.2-5.1+sarge1 in
> stable a
On Sun, 2008-03-16 at 03:47 -0700, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.
That makes sense, although doesn't seem to match current practice. Was
any consideration given
On Sun, 16 Mar 2008, Thijs Kinkhorst wrote:
> On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> > We're aware that the Developers Reference specifies that the latter
> > format should be used, but it is problematic as -0.1 sorts before +b1
> > and, as such, the NMU will not supersede any prev
On Sun, Mar 16, 2008 at 03:47:56AM -0700, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.
This could also lead to a problem in very rare cases: If a program has
the same version
On Sunday 16 March 2008 11:47, Steve Langasek wrote:
> The current binNMU numbering scheme was selected explicitly to allow
> security uploads to sort later by numbering as
> +; e.g., 1.2-5.1+etch1.
Ah, I wasn't aware of that (and no-one seems to be using it currently). The
release managers know
On Sun, Mar 16, 2008 at 11:36:20AM +0100, Thijs Kinkhorst wrote:
> On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> > We're aware that the Developers Reference specifies that the latter
> > format should be used, but it is problematic as -0.1 sorts before +b1
> > and, as such, the NMU will n
On Sunday 16 March 2008 00:52, Adam D. Barratt wrote:
> We're aware that the Developers Reference specifies that the latter
> format should be used, but it is problematic as -0.1 sorts before +b1
> and, as such, the NMU will not supersede any previous binNMUs of the
> same package version.
>
> Whil
* Adam D. Barratt:
> Currently, debchange will produce a version number of X-0.1 in such
> cases which suffers from the problem described above. It has been
> suggested that either one of +s1 / +sec1 / +security1 or 1
> should be used to avoid the issue.
For stable and oldstable, we need 1. But
[Adding bug #437392 to Cc, which deals with this issue for normal NMUs,
because I'm making a suggestion about them.]
On Sat, Mar 15, 2008 at 11:52:55PM +, Adam D. Barratt wrote:
> devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of
> "debchange --nmu" to version an NMU of a n
[nutshell version for those who can't be bothered to read the full
mail :-) - what version number should a security upload of a native
package have]
Hi,
devscripts 2.10.19 (soon to be uploaded) will modify the behaviour of
"debchange --nmu" to version an NMU of a native package as X+nmu1 rather
t
also sprach David Nusinow <[EMAIL PROTECTED]> [2005.08.22.1728 +0200]:
> > debian-changelog-mode automatically increments the version numbers for
> > me, including the epoch, so it is no burden -- even the poor vi using
> > sods can just do cut and paste
>
> dch -i
Ssssh. Don't expect Manoj to us
On Mon, Aug 22, 2005 at 10:15:12AM -0500, Manoj Srivastava wrote:
> debian-changelog-mode automatically increments the version numbers for
> me, including the epoch, so it is no burden -- even the poor vi using
> sods can just do cut and paste
dch -i
- David Nusinow
--
To UNSUBSCRIBE, email t
On Mon, 22 Aug 2005 10:13:23 +0200, Henning Makholm <[EMAIL PROTECTED]> said:
> Scripsit Wouter Verhelst <[EMAIL PROTECTED]>
>> On Sun, Aug 21, 2005 at 05:31:34PM -0600, Bob Proulx wrote:
>>> An example where an epoc would be needed would be if 0.7.3.3 was
>>> uploaded as 7.3.3 instead. The epo
Scripsit Wouter Verhelst <[EMAIL PROTECTED]>
> On Sun, Aug 21, 2005 at 05:31:34PM -0600, Bob Proulx wrote:
>> An example where an epoc would be needed would be if 0.7.3.3 was
>> uploaded as 7.3.3 instead. The epoc is designed to handle this
>> problem and allows 1:0.7.3.3 to be later than 7.3.3 t
On Aug 18, Lars Bahner ([EMAIL PROTECTED]) wrote:
>
> Hi,
>
> Please CC: me as I am not on this list!
>
> As I upgraded rscheme today to the final non-beta version I ran into
> problems with the version numbering.
>
> Eg:
> old version (0.7.3.3.b30
On Sun, Aug 21, 2005 at 05:31:34PM -0600, Bob Proulx wrote:
> An example where an epoc would be needed would be if 0.7.3.3 was
> uploaded as 7.3.3 instead. The epoc is designed to handle this
> problem and allows 1:0.7.3.3 to be later than 7.3.3 to fix that
> situation. But that is not the case h
also sprach Robert Collins <[EMAIL PROTECTED]> [2005.08.22.0053 +0200]:
> I think the ~ is the Right Way.
> 0.7.3.3~b1 < 0.7.3.3~b30 < 0.7.3.3
This will not yet work with the Debian archive scripts. It will be
the right way, but not yet.
--
Please do not send copies of list mail to me; I read th
Robert Collins wrote:
> martin f krafft wrote:
> > Lars Bahner wrote:
> > > Please CC: me as I am not on this list!
> >
> > > Upstream names the betas for 0.7.3.3 as 0.7.3.3.b1-b30 - as you no
> > > doubt already guessed.
> ...
> > > So now that there is no beta-versioning, the installer sees this
On Fri, 2005-08-19 at 00:52 +0200, martin f krafft wrote:
> also sprach Lars Bahner <[EMAIL PROTECTED]> [2005.08.18.2346 +0200]:
> > Please CC: me as I am not on this list!
>
> Please consider setting Mail-Followup-To accordingly.
>
> > Upstream names the betas for 0.7.3.3 as 0.7.3.3.b1-b30 - as
martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Lars Bahner <[EMAIL PROTECTED]> [2005.08.18.2346 +0200]:
>> Please CC: me as I am not on this list!
>
> Please consider setting Mail-Followup-To accordingly.
>
>> Upstream names the betas for 0.7.3.3 as 0.7.3.3.b1-b30 - as you no
>> doubt a
also sprach Hamish Moffatt <[EMAIL PROTECTED]> [2005.08.19.0332 +0200]:
> > This is why we now have the ~ operator.
>
> Is that ready for use?
http://lists.debian.org/debian-devel/2005/06/msg01482.html
AFAICT, this is still the case. So no. Not yet.
--
Please do not send copies of list mail t
On Fri, Aug 19, 2005 at 12:52:41AM +0200, martin f krafft wrote:
> also sprach Lars Bahner <[EMAIL PROTECTED]> [2005.08.18.2346 +0200]:
> > Upstream names the betas for 0.7.3.3 as 0.7.3.3.b1-b30 - as you no
> > doubt already guessed.
> This is why we now have the ~ operator.
Is that ready for use?
also sprach Lars Bahner <[EMAIL PROTECTED]> [2005.08.18.2346 +0200]:
> Please CC: me as I am not on this list!
Please consider setting Mail-Followup-To accordingly.
> Upstream names the betas for 0.7.3.3 as 0.7.3.3.b1-b30 - as you no
> doubt already guessed.
This is why we now have the ~ operato
Hi,
Please CC: me as I am not on this list!
As I upgraded rscheme today to the final non-beta version I ran into
problems with the version numbering.
Eg:
old version (0.7.3.3.b30-1) in unstable >= new version (0.7.3.3-1)
Upstream names the betas for 0.7.3.3 as 0.7.3.3.b1-b30 - as you
This follows up a debian-bugs posting with the Subject
"Re: Bug#1712: Tex has no version number texbin does"
Erick Branderhorst <[EMAIL PROTECTED]> said:
> It might be usefull to let the provides packages have the same version
> number as the providing package, or if a specific version number is
79 matches
Mail list logo
