27 Jun
2006
27 Jun
'06
10:29 p.m.
Hello,
a miror question about / problem with the Release: number:
In the specfile, I have to set a release number:
Release: 42
(If I don't, rpm complains and the build fails.)
The build service edits this number when building the package and sets
it to 1.42 then 2.42 then 3.42 etc.
This makes the release number in the specfile quite useless because it's
only on the second position.
The behaviour can also cause problems when someone imports a package to
the build service.
Say I have released a manually built foobar-1.0-42 package, then move to
the build service and do some small changes without changing the
version number. The build service will compile a foobar-1.0-1.42
package which looks "older" to RPM :-(
Are there any plans to change the behaviour regarding the release
number?
Regards,
Christian Boltz
--
Was hat ein Revolver mit Windows 98 gemeinsam?
Solange sie nicht geladen sind, sind sie harmlos.
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
17 Aug
17 Aug
3:30 p.m.
Am Thursday 17 August 2006 11:08 schrieb Dmitry Mishin:
This is an open topic to be discussed atm.
In general I do see two possibilities:
1. declare such dependencies to %release as illegal. Because a rebuild does
not make a package (kernel) incompatibel.
2. support release number copies via build service links.
I am atm in favour of solution 1., but our kernel people needs to agree ...
bye
adrian
--
Adrian Schroeter
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
email: adrian(a)suse.de
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
AFAIK,
Mandriva uses a macro called %mkrel, which instructs their build
server to auto create the release number.
Release: %mkrel
If the packager doesn't want this to be automatic, then he can force the
number in one of the two ways:
Release: %mkrel 1
or
Release: 1
Do you plan to implement something like this?
I have an issue with OpenVZ suse kernels because of the auto release
assign. kernel-source packages have different from binary packages release
number. This follows in nightmare while building unsupported modules over
this kernels because of the wrong symlinks. 
11:08 a.m.
AFAIK, Mandriva uses a macro called %mkrel, which
instructs their build
server to auto create the release number.
Release: %mkrel
If the packager doesn't want this to be automatic, then he can force the
number in one of the two ways:
Release: %mkrel 1
or
Release: 1
Do you plan to implement something like this?
I have an issue with OpenVZ suse kernels because of the auto release assign.
kernel-source packages have different from binary packages release number.
This follows in nightmare while building unsupported modules over this
kernels because of the wrong symlinks.
--
Thanks,
Dmitry.
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice+help(a)opensuse.org
28 Jun
28 Jun
11:45 a.m.
Em Ter, 2006-06-27 às 22:29 +0200, Christian Boltz escreveu:
Are there any plans to change the behaviour regarding
the release
number?
AFAIK, Mandriva uses a macro called %mkrel, which instructs their build
server to auto create the release number.
Release: %mkrel
If the packager doesn't want this to be automatic, then he can force the
number in one of the two ways:
Release: %mkrel 1
or
Release: 1
In the past, (also AFAIK) the spec files for Conectiva (which has merged
with Mandrake to form Mandriva) didn't need to have the release tag,
since the specs were commited to an SVN server and their build server
automatically created the release number based on the SVN revision
number. That way the release number would always be a sequential number
no matter what the version is (so, for example, you could have 1.0-55
and 1.1-78 two weeks later).
Jus my 2c to help you making the decision... :)
--
% Mauricio Teixeira (netmask)
% mteixeira{a}webset{d}net <> Maceio/AL/BR
% http://mteixeira.webset.net <> http://pmping.sf.net
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
10:43 a.m.
On Wed, Jun 28, 2006 at 10:04:49AM +0200, Robert Schiele wrote:
On Wed, Jun 28, 2006 at 09:47:17AM +0200, Michael
Schroeder wrote:
Yes, we could do that. Sounds like a good idea to me.
(I'll have to pare the specfile on the upload for this, though.)
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
Currently the build service ignores the value you
put in the
release tag and replaces it with a value it maintains internally
(number of checkins . number of rebuilds).
There should be a way to specify a *minimum* value, though.
Why not just using the specified as a minimum? 
10:04 a.m.
On Wed, Jun 28, 2006 at 09:47:17AM +0200, Michael Schroeder wrote:
Currently the build service ignores the value you put
in the
release tag and replaces it with a value it maintains internally
(number of checkins . number of rebuilds).
There should be a way to specify a *minimum* value, though.
Why not just using the specified as a minimum?
Robert
--
Robert Schiele Tel.: +49-621-181-2214
Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de
"Quidquid latine dictum sit, altum sonatur."
9:47 a.m.
On Tue, Jun 27, 2006 at 10:29:53PM +0200, Christian Boltz wrote:
Hello,
a miror question about / problem with the Release: number:
In the specfile, I have to set a release number:
Release: 42
(If I don't, rpm complains and the build fails.)
Currently the build service ignores the value you put in the
release tag and replaces it with a value it maintains internally
(number of checkins . number of rebuilds).
There should be a way to specify a *minimum* value, though.
Cheers,
Michael.
--
Michael Schroeder mls(a)suse.de
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
27 Jun
27 Jun
11:09 p.m.
hi,
i usually leave the release number at 0
than you get:
x.y
where X is the number of commits to your package
and y the number of rebuilds, either from clicking this trigger rebuild
or due the rebuilding of a package in your buildrequires.
and yes this is required to have properly incrementing release numbers.
just my 2 cents.
darix
--
openSUSE - SUSE Linux is my linux
openSUSE is good for you
www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
11:01 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Christian Boltz wrote:
a miror question about / problem with the Release:
number:
In the specfile, I have to set a release number:
Release: 42
(If I don't, rpm complains and the build fails.)
Indeed, Release: is a mandatory spec file tag.
The build service edits this number when building the
package and sets
it to 1.42 then 2.42 then 3.42 etc.
This makes the release number in the specfile quite useless because it's
only on the second position.
Ummm... I'm pretty sure this is supposed to be done on the *second*
field, not the first one.
Adrian ?
The behaviour can also cause problems when someone
imports a package to
the build service.
Say I have released a manually built foobar-1.0-42 package, then move to
the build service and do some small changes without changing the
version number. The build service will compile a foobar-1.0-1.42
package which looks "older" to RPM :-(
Are there any plans to change the behaviour regarding the release
number?
Either something is misconfigured or it's a bug, because from what I
know, it is actually meant to be performed on the second part of the
Release: (behind the dot).
I would doubt it's a bug because quite a few builds have already been
done with the Build Service.
Maybe a regression that has been introduced today ?
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser(a)skynet.be> <guru(a)unixtech.be>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEoZyxr3NMWliFcXcRAo7pAJ4k48xjoOuNiUXij9+na4E1UQTdXACguyDh
/8zZrl6KZGuCrnWZV3eRq6E=
=5HPn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: opensuse-buildservice-unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-buildservice-help(a)opensuse.org
5267
days inactive
5318
days old
buildservice@lists.opensuse.org
8 comments
8 participants
participants (8)
-
Adrian Schröter -
Christian Boltz -
Dmitry Mishin -
Marcus Rueckert -
Mauricio Teixeira (netmask) -
Michael Schroeder -
Pascal Bleser -
Robert Schiele